Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Javascript Constructors and Prototypes

tobyho.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Javascript Constructors and Prototypes

#31

Post by andypants »

wrboyce wrote: post #8
pests wrote: post #5

Earlier quoted context omitted.

Did you see the article he linked about why he doesn't use them? http://mislav.uniqpath.com/2010/05/semicolons/ Not reading an article because of that would be like not reading other code because it uses 2 spaces for tabs instead of 4. Makes no difference to the language, only to you.

The article (justifying not using semicolons) seems like a rant with not real aim, beside "I am right, semicolons are wrong - and I have all these half-baked ideas to back me up". The author was actually annoying me by the time I reached "It's good coding style". One example: > My advice on JSLint: don’t use it. Why would you use it? If you believed that it helps you have less bugs in your code, here’s a newsflash; o…

> only people can detect and solve software bugs, not tools

Stupid compilers, they've been doing it wrong this whole time.

Re: Javascript Constructors and Prototypes

#32

Post by raju »

I wrote a similar (2 series) article a while back that attempts to explain the same thing, but with a few diagrams. I know sketching out what was going on really helped me ...

http://www.looselytyped.com/blog/2012/08/18/on-prototypal-in...

http://www.looselytyped.com/blog/2012/08/22/on-prototypal-in...

Re: Javascript Constructors and Prototypes

#33

Post by derefr »

lmm wrote: post #30
derefr wrote: post #23

Earlier quoted context omitted.

Oddly, > Also, a lot of the weird ambiguous cases are disambiguated by including parenthesis, so if you're unsure just include the parens and you should be ok. this is exactly the parallel I was going to make to the discussion we're currently having here. People who want semicolons on every line, even when they don't matter, are the same people who want to parenthesize every infix operation, even when the natural pre…

Some programmers are good at remembering large numbers of arbitrary rules. Others aren't, and I've worked with good and bad programmers of both kinds. So yes, I'm worried that a colleague might read the code and not know what the precedence is, and they will have to waste their time looking it up (thankfully some IDEs now have an command to add parentheses quickly, but it's still a distraction from their actual task)…

Why would they be looking up the precedence?

If the code currently works, then they can read it, and infer that whatever precedence the operators have is the correct one for producing the result the code produces. If "a + b * c" is producing 17 where (a=2,b=3,c=5), then you know that your language makes multiplication precede addition.

If the code doesn't currently work, then they'll have to figure out via some external method (looking up the original formula used in the code, say) what the precedence needs to be, in order to parenthesize to make it work.

On a separate note,

> it would be better if e.g. "a && b || c" were a syntax error until bracketed properly.

this reminds me of the horribly-confusing practice of using "a && b || c" to mean "a ? b : c" in shell-scripting. It almost works, too... unless (a=true,b=false), in which case you unintentionally get the side-effects of c.

Re: Javascript Constructors and Prototypes

#34

Post by andypants »

marrs wrote: post #22
mradmin wrote: post #15

Earlier quoted context omitted.

It's hipster because it goes against the accepted standard way of writing Javascript. See https://news.ycombinator.com/item?id=1547647&utm_source=twit...

My interpretation of "hipster" is being different because you think it's cool to be different. Being different because you think it's a better approach is called "making progress", either because you'll be proven right or proven wrong. I've thought about the de-facto standard way a lot and I think that it does nothing to avoid bugs while potentially misleading a coder about the language. Therefore I think it's worse.…

Nobody has any good reasons that apply to most people, both for and against semicolons. There really isn't a huge difference in either style except in rare cases.

> The only reason I follow the de-facto standard is because the time spent arguing about it with my peers is better spent getting work done.

Which is why that is an excellent reason. Standards are useful, so if there is one, stick to it. If there is no reason to go against the standard, then don't.

> I think that it does nothing to avoid bugs while potentially misleading a coder about the language. Therefore I think it's worse.

Not seeing any semicolons can also potentially mislead about the language. It is not worse, they are both misleading until you realise ASI exists.

Omitting semicolons also does nothing to avoid bugs, and introduces a different (additional?) set of edge cases where bugs may appear.

Re: Javascript Constructors and Prototypes

#35

Post by mdigi »

GeneralMayhem wrote: post #27

This article does two things that are very dangerous, and never mentions the reasons why they're dangerous. * Messing with Function's prototype is very strongly frowned upon. It's tantamount to setting global variables. At the very least, give that definition an if (!Function.new) guard to prevent redefining another implementation that another script (or the browser!) has already given. * Adding methods in the constr…

"In the first version, each time you create a person, a new sayHi function will be created for him, where as in the second version, only one sayHi function is ever created, and is shared amongst all persons that are created - because Person.prototype is their parent. Thus, declaring methods on the prototype is more memory efficient."

Re: Javascript Constructors and Prototypes

#36

Post by esailija »

GeneralMayhem wrote: post #27

This article does two things that are very dangerous, and never mentions the reasons why they're dangerous. * Messing with Function's prototype is very strongly frowned upon. It's tantamount to setting global variables. At the very least, give that definition an if (!Function.new) guard to prevent redefining another implementation that another script (or the browser!) has already given. * Adding methods in the constr…

Since this is usually downplayed because the "code is shared", to be more specific, for example in V8 in x64 (node.js, Google Chrome), the theoretical minimum memory used by a function object is 72 bytes:

- Map pointer: 8

- Properties pointer: 8

- Elements pointer: 8

- Code entry pointer: 8

- Initial Map/prototype pointer: 8

- SharedFunctionInfo pointer: 8

- Context pointer: 8

- Literals/Bindings pointer: 8

- Weak fields pointer: 8

So if you have a Person class with 30 methods, the methods are taking 30 * 72 = 2160 bytes at the very least. The actual data for a person might take 200 bytes, if we store e.g. full name, age and address so in this case there is like 10x overhead. If you print the details of 200 people per page request and there are 100 people connecting to your server, you are wasting 200 * 100 * 2160 =~ 40 megabytes on memory on storing all these useless function objects at that moment. That is just crazy.

And in GC language it's never just memory, a GC will eat exponentinally more CPU time when the amount of memory you use reaches closer and closer to limits.

Re: Javascript Constructors and Prototypes

#37

Post by lmm »

derefr wrote: post #33
lmm wrote: post #30

Earlier quoted context omitted.

Some programmers are good at remembering large numbers of arbitrary rules. Others aren't, and I've worked with good and bad programmers of both kinds. So yes, I'm worried that a colleague might read the code and not know what the precedence is, and they will have to waste their time looking it up (thankfully some IDEs now have an command to add parentheses quickly, but it's still a distraction from their actual task)…

Why would they be looking up the precedence? If the code currently works, then they can read it, and infer that whatever precedence the operators have is the correct one for producing the result the code produces. If "a + b * c" is producing 17 where (a=2,b=3,c=5), then you know that your language makes multiplication precede addition. If the code doesn't currently work, then they'll have to figure out via some exter…

>If the code currently works, then they can read it, and infer that whatever precedence the operators have is the correct one for producing the result the code produces. If "a + b * c" is producing 17 where (a=2,b=3,c=5), then you know that your language makes multiplication precede addition.

By that logic why bother using a font in which * and + look like different symbols? Heck, why read the code at all? If the code is working you can infer what it must be doing by observing what comes out when you feed it different inputs.

You read code precisely because you don't know what it does for every input, or don't know how it implements the algorithm; you want to be able to look at a line and see what it does, without having to fire up a repl and run through several examples. I mean, the idea that code should be readable - i.e. that you should be able to tell what a given line of code does without having to run it or look it up - is about as fundamental a good coding principle as it gets.

Re: Javascript Constructors and Prototypes

#38

Post by [deleted] »

esailija wrote: post #36
GeneralMayhem wrote: post #27

This article does two things that are very dangerous, and never mentions the reasons why they're dangerous. * Messing with Function's prototype is very strongly frowned upon. It's tantamount to setting global variables. At the very least, give that definition an if (!Function.new) guard to prevent redefining another implementation that another script (or the browser!) has already given. * Adding methods in the constr…

Since this is usually downplayed because the "code is shared", to be more specific, for example in V8 in x64 (node.js, Google Chrome), the theoretical minimum memory used by a function object is 72 bytes: - Map pointer: 8 - Properties pointer: 8 - Elements pointer: 8 - Code entry pointer: 8 - Initial Map/prototype pointer: 8 - SharedFunctionInfo pointer: 8 - Context pointer: 8 - Literals/Bindings pointer: 8 - Weak fi…

[deleted]

Re: Javascript Constructors and Prototypes

#39

Post by derefr »

lmm wrote: post #37
derefr wrote: post #33

Earlier quoted context omitted.

Why would they be looking up the precedence? If the code currently works, then they can read it, and infer that whatever precedence the operators have is the correct one for producing the result the code produces. If "a + b * c" is producing 17 where (a=2,b=3,c=5), then you know that your language makes multiplication precede addition. If the code doesn't currently work, then they'll have to figure out via some exter…

>If the code currently works, then they can read it, and infer that whatever precedence the operators have is the correct one for producing the result the code produces. If "a + b * c" is producing 17 where (a=2,b=3,c=5), then you know that your language makes multiplication precede addition. By that logic why bother using a font in which * and + look like different symbols? Heck, why read the code at all? If the cod…

There is a fundamental difference.

When you read "a + b * c"--and then test your assumption of what it does in a REPL--the result is a learning moment where that knowledge now sticks to you; from then on, you know which of the two operators come first. You only have to do it once.

On the other hand, "using a font in which * and + look like [the same symbol]" means never being able to recognize the pattern, which means never learning anything and having to check every time.

Also,

> the idea that code should be readable - i.e. that you should be able to tell what a given line of code does without having to run it or look it up - is about as fundamental a good coding principle as it gets.

I would agree that that is a good coding principle for low-level C/C++/Java code; in these languages, you can't separate the abstract meaning of code from its implementation, so it's better to just keep the two things together.

But on the other hand, the equivalent coding principle for Lisp is "create a set of macros which form a DSL to perfectly articulate your problem domain--and then specify your solution in that DSL." The equivalent for Haskell is "find a Mathematical domain isomorphic to your problem domain; import a set of new operators which match the known Mathematical syntax of that domain; and then state your problem in terms of that Mathematical domain by using those operators." In either of these cases, nobody can really be expected to just jump in and read the code without looking something, or a lot of somethings, up.

This isn't because the code is "objectively bad", but rather that it has externalized abstractions which in a lower-level language like C would have to be written explicitly into the boilerplate-structure of your code. These are just two different cultures.

Post reply on HN