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

Treating JavaScript like a 30 year old language

jeremyckahn.github.com

Post reply on HN
Print view View original

61–70 of 99 posts

Re: Treating JavaScript like a 30 year old language

#61

Post by ufo »

orangecat wrote: post #23
MatthewPhillips wrote: post #9

Earlier quoted context omitted.

Some people think that library consumers shouldn't have to use new. Instead they should call a factory function (which itself calls new).

And I agree with that. "new" exposes too much implementation detail: it always allocates an object, and it's exactly the type specified, neither of which callers should normally care about. I much prefer how Python does it.

Actually, in Javascript you can preemptively return a value of a different type from the constructor instead of relying on the implicit `return this` at the end.

That said, I agree that the way "new" specifies the concrete type of the returned value is pure evil. In OO things should be typed according to their interfaces, not according to their concrete implementations.

Re: Treating JavaScript like a 30 year old language

#62

Post by ufo »

shawndumas wrote: post #25
AjJi wrote: post #8

AFAIK, using 'new' is not a matter of preference. Omitting the keyword leads to different results. Am I missing something?

if (!(this instanceof arguments.callee)) { return new arguments.callee(/* parms */); }

You can't use arguments.callee when in strict mode. So far the only alternative is to manually encode the class name and argument list:

    if(!(this instanceof MyClass)){
        return new MyClass(a,b,c)
    }

Re: Treating JavaScript like a 30 year old language

#63

Post by wickedchicken »

greggman wrote: post #31

I use the Google style guide as well since it's required by my job and while I have learned somethings from it I'm not a fan. 80 characters? I never had that limit for the 27 years of programming proceeding using the Google style guide and it never caused me any grief. I find that naming things descriptively and an 80 character limit are at odds. I'd rather read maxCombinedUniformVectors = maxFragmentUniformVectors +…

> 80 characters? I never had that limit for the 27 years of programming proceeding using the Google style guide and it never caused me any grief.

I didn't think that way until very recently, and then something occured to me: limiting things to 80 characters means you can fit more vertical strips of code on your screen without line breaks. On a 1920x1080 screen with a 6x13 font[1], I can split vim into 4 vertical strips each of which are 79 characters wide. It's not perfect, but it means that my screen is filled with code instead of whitespace. Keeping code width low is like dyanmic-range compression[2] for code.

[1] -Misc-Fixed-Medium-R-SemiCondensed--13-120-75-75-C-60-ISO10646-1 (I have yet to find a more readable font with those metrics, and I've looked hard) [2] http://en.wikipedia.org/wiki/Dynamic_range_compression

Re: Treating JavaScript like a 30 year old language

#65

Post by ricardobeat »

jerbils wrote: post #56
ricardobeat wrote: post #46

Those are all fairly standard practices (except for the compile step which brings portability issues). I got the impression that the author has some underlying reason for this post that went unexplained. If the lack of default parameters and style consistency are your main peeves with Javascript, it's faring quite well :) Ironically, those are problems that CoffeeScript solves, yet it seems this guy would be the last…

Article author here: I'll get into CoffeeScript when I feel that it solves more problems than it creates (it's very important for me to be able to debug raw source code in a language). My goal as a programmer is to reduce complexity, and I think it will take about 10 years for CoffeeScript to let me do that. EDIT: Forget to mention, there's nothing in particular that caused me to write this. I just realized that, mor…

Hi Jeremy. Dmitry's argument you mention, for instance, is questionable and not very popular. I think I can't point to what you're going against (vs "old style" coding), maybe some examples in the post could help.

On CS: you are already using a compile step that dynamically changes code, how more complex can it get? I have thousands of lines of CS in production and it never caused any more problems than JS. If you think of CoffeeScript as a tool to write Javascript, not a separate language, things go much smoother (you want to debug the javascript output, not the cs source).

Re: Treating JavaScript like a 30 year old language

#66

Post by coldarchon »

1 var sum = addNumbers('5', 10); 2 console.log(sum); // -> 510

"Whoops. If the client of this code assumes that addNumbers will do any typecasting for them, they will get unexpected results."

This is not an unexpected result as variables in JavaScript need to be defined as numbers or they are treated as strings. Therefor 5+10 is a concatenation and 510 of type string is an expected result. If you don't know this basic stuff?

Re: Treating JavaScript like a 30 year old language

#67

Post by nfm »

greggman wrote: post #31

I use the Google style guide as well since it's required by my job and while I have learned somethings from it I'm not a fan. 80 characters? I never had that limit for the 27 years of programming proceeding using the Google style guide and it never caused me any grief. I find that naming things descriptively and an 80 character limit are at odds. I'd rather read maxCombinedUniformVectors = maxFragmentUniformVectors +…

On a related note, breaking statements into multiple lines can screw with your VCS workflow immensely.

It's not a problem if you're doing something sensible like extracting nested function calls, but inserting newlines into simple statements will make tools like `git blame` a lot less useful.

Re: Treating JavaScript like a 30 year old language

#68

Post by adrusi »

wickedchicken wrote: post #63
greggman wrote: post #31

I use the Google style guide as well since it's required by my job and while I have learned somethings from it I'm not a fan. 80 characters? I never had that limit for the 27 years of programming proceeding using the Google style guide and it never caused me any grief. I find that naming things descriptively and an 80 character limit are at odds. I'd rather read maxCombinedUniformVectors = maxFragmentUniformVectors +…

> 80 characters? I never had that limit for the 27 years of programming proceeding using the Google style guide and it never caused me any grief. I didn't think that way until very recently, and then something occured to me: limiting things to 80 characters means you can fit more vertical strips of code on your screen without line breaks. On a 1920x1080 screen with a 6x13 font[1], I can split vim into 4 vertical stri…

yeah, I didn't adhere to a column limit until I moved to vim, then I realized as you said that it lets me view code side-by-side

Re: Treating JavaScript like a 30 year old language

#69

Post by SoftwareMaven »

jerbils wrote: post #55
josephg wrote: post #24

The google javascript style is overly verbose and really awkward. Javascript isn't a typed object-oriented language. If you fight javascript until it looks like C++, you make an awful mess. Most of the javascript I've read from google is overly verbose, takes ages to compile(!!) and it avoids javascript's best features - anonymous functions (closures), object literals and dynamic typing. If the author writes his java…

Article author here: It's a matter of practicality. JavaScript can do some really cool things, but if it makes the code harder to read/follow/maintain, it's not very useful. From what I've seen, a lot of the JavaScript techniques that have gained popularity over that last couple years make code less grokkable for a project newcomer. My goal is to write code that anyone can understand. I get much more enjoyment out of…

Project newcomers or JavaScript newcomers? Because if you are optimizing for the latter under the pretense of optimizing for the former, you are building code that experienced people won't want to interact with.

FWIW, I'm with you on wanting to write readable, usable code. But my Python code does take advantage of functional aspects and meta programming at time, because I can write far fewer lines of code, which means fewer bugs and less time spent mentally parsing code later.

Re: Treating JavaScript like a 30 year old language

#70

Post by FuzzyDunlop »

SoftwareMaven wrote: post #69
jerbils wrote: post #55

Earlier quoted context omitted.

Article author here: It's a matter of practicality. JavaScript can do some really cool things, but if it makes the code harder to read/follow/maintain, it's not very useful. From what I've seen, a lot of the JavaScript techniques that have gained popularity over that last couple years make code less grokkable for a project newcomer. My goal is to write code that anyone can understand. I get much more enjoyment out of…

Project newcomers or JavaScript newcomers? Because if you are optimizing for the latter under the pretense of optimizing for the former, you are building code that experienced people won't want to interact with. FWIW, I'm with you on wanting to write readable, usable code. But my Python code does take advantage of functional aspects and meta programming at time, because I can write far fewer lines of code, which mean…

Agreed, also on the count that writing idiomatic code is, in my opinion, much more beneficial than having to refer to a third party style-guide to grok a non-idiomatic flavour of it.

The obvious benefit is that knowledge can then be applied to any other project using the language idiomatically, and not as if it were 30 years old. Conversely, code to the third party style guide, and struggle to understand the many things that don't adhere to it.

Post reply on HN