Treating JavaScript like a 30 year old language • Hacker News Board

Re: Treating JavaScript like a 30 year old language

#21

Post by Xcelerate » Wed, Jul 04, 2012, 4:59 PM UTC

Maybe I'm an exception, but I generally find code with LESS syntax to be more readable.

    var makeAdder = function(x) {
        return function(y) {
            return x + y;
        };
    }

vs

    makeAdder = (x) -> (y) -> x + y

Is anyone else like this? Do you think people are hard-wired to prefer one form of syntax to another, or do you think it's a "whichever you have more experience with" kind of thing?

Re: Treating JavaScript like a 30 year old language

#22

Post by ThePherocity » Wed, Jul 04, 2012, 5:07 PM UTC

mattdeboard wrote: post #15

watt wrote: post #13

I disagree with the point about 80 chars limit. If the line consists of boilerplate code, I will allow it to go over 120-160 chars most of times. The idea is to just get that code out of sight, as nobody should have to read it anyway. If it's important, I will break the line up. If not - like a long exception message that gets constructed with bunch of context information - I'll let it grow out of window. It's not so…

We're so different, you and I. "Getting code out of sight because it's ugly" is such a foreign concept. If a code block is that ugly, it either needs to be made not ugly or put directly in the line of sight with plentiful comments. "Shouldn't have to read it" !== "won't ever have to read it."

I agree completely with this, all code should be visible, but I still go well over 80 personally because I'm don't, nor will anyone likely edit my code on a 80 char terminal. When I was hacking on an IBM mainframe through a 3270 terminal, the 80 character limit made a lot of sense.

Why use the 80 char rule because of an edge case of some throwback editing javascript in a term that only allows for 80 characters? I mean, who does that?

Re: Treating JavaScript like a 30 year old language

#23

Post by orangecat » Wed, Jul 04, 2012, 5:08 PM UTC

MatthewPhillips wrote: post #9

AjJi wrote: post #8

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

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.

Re: Treating JavaScript like a 30 year old language

#24

Post by josephg » Wed, Jul 04, 2012, 5:09 PM UTC

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 javascript as if it were C++, its really no wonder he hates the language. Javascript is a wonderful little language - but its not C, and if you pretend it is, you're going to have a miserable time.

Re: Treating JavaScript like a 30 year old language

#25

Post by shawndumas » Wed, Jul 04, 2012, 5:09 PM UTC

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 */);
    }

Re: Treating JavaScript like a 30 year old language

#26

Post by frugalmail » Wed, Jul 04, 2012, 5:15 PM UTC

Have you taken a look at http://haxe.org ? Seems like a good solution against javascript's flaws.

Re: Treating JavaScript like a 30 year old language

#27

Post by Roboprog » Wed, Jul 04, 2012, 5:15 PM UTC

Semicolons: it's too bad Netscape didn't choose to use colons instead (but then it wouldn't sorta look like C, would it).

As opposed to common dogma as this is, JavaScript is essentially a line oriented language, like Ruby, Shell Script, BASIC, Groovy or dBASE. OK, so it's more like Ruby, where the line will continue if it doesn't look done.

Had they used colons instead of semicolons, it would have been obvious that "oh, I'm using this punctuation to add another statement to this line", but of course, it's usually the null statement in JavaScript.

It's a shame JavaScript (and Ruby) didn't adopt the line continuation character convention (e.g. - backslash or ampersand) for incomplete lines. As it is, one might be best served by learning what incomplete statements look like, just in case, and alternately, where the parser might think your statement is shorter than you intended.

Yes, I add the semicolons at work to avoid the > contest.

Re: Treating JavaScript like a 30 year old language

#28

Post by luriel » Wed, Jul 04, 2012, 5:19 PM UTC

skrebbel wrote: post #14

> I would contend that readability generally has more impact on the success of a project than micro-optimizations and stylistic experimentation. If that means writing like a C coder in the 80’s, then so be it. Excellent attitude. I need to keep reminding myself of this when I come up with them fancy oneliners again.

I'm sorry to sound like a fanboy, but this is one of the reasons I love Go: is the most readable language I know.

It is expressive, but free of magic, code says what it does, there is no hidden magic tricks, this annoys people used to other languages with more "features", but to me it is Go's greatest feature.

Re: Treating JavaScript like a 30 year old language

#29

Post by Roboprog » Wed, Jul 04, 2012, 5:20 PM UTC

Xcelerate wrote: post #21

Maybe I'm an exception, but I generally find code with LESS syntax to be more readable. var makeAdder = function(x) { return function(y) { return x + y; }; } vs makeAdder = (x) -> (y) -> x + y Is anyone else like this? Do you think people are hard-wired to prefer one form of syntax to another, or do you think it's a "whichever you have more experience with" kind of thing?

I think I could get used to the second, but I'm not yet. At a glance, it looks like Erlang or Haskell, but that just shows you how little I know about those languages.

It's tough to strike a balance between brevity and familiarity sometimes.

Re: Treating JavaScript like a 30 year old language

#30

Post by anuraj » Wed, Jul 04, 2012, 5:20 PM UTC

I have always felt that scripting languages should stay clear of OO syntax largely. Try to do small files which are procedural. OO is for large monolithic modules - good to collabarate and manage complexity - scripting should stay where it needs to be - simple and standalone, no threading, but asynchronous where possible. This makes life easier for everybody.