Live data from Hacker News

Treating JavaScript like a 30 year old language

jeremyckahn.github.com

11–20 of 99 posts

Re: Treating JavaScript like a 30 year old language

#11
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).

Here's an argument in favor of not requiring library consumers to use new by the author of the Raphäel library: http://dmitry.baranovskiy.com/post/something-new

Re: Treating JavaScript like a 30 year old language

#12
Totally aside, but interesting: 80 characters was not an arbitrary limit, at least not directly. It was the size of the IBM standard punched card, and the terminals that succeeded them. Famously, versions of COBOL (FORTRAN too?) well into the 1990s would not even recognize input past column 80 even though it had long since graduated to text files.

http://en.wikipedia.org/wiki/Punched_card

I still like to use 80 characters even today because it means I can fit two or even three pages of code side-by-side without wrapping. Great for merging.

Re: Treating JavaScript like a 30 year old language

#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 something you will need to look at, read and grok every day. And I am happy to have it out of sight most of time.

I break up lines when thinking about stepping through them in debugger (though javascript debuggers seem to be able to step statement by statement, not line by line).

Re: Treating JavaScript like a 30 year old language

#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.

Re: Treating JavaScript like a 30 year old language

#15
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."

Re: Treating JavaScript like a 30 year old language

#16
"At some point in computer history, somebody (arbitrarily?) created an 80 character line limit for code. ... I’ve been writing JavaScript for three-ish years"

For a couple decades, and not ending until the late 90s, most text terminals and text modes for graphics cards were 80 characters wide[1], and dot matrix printers also had an 80 character line length (plus margins) dating back to 80 characters per line punch cards from 1928[2]. If a line was longer, you had to scroll that individual line. To let your code be read easily anywhere including your own screen, you stuck to that line length.

1. http://en.wikipedia.org/wiki/Text_mode#PC_common_text_modes

2. http://en.wikipedia.org/wiki/Punched_card#IBM_80-column_punc...

Re: Treating JavaScript like a 30 year old language

#18
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…

The only way I can know that the code is boilerplate and "nobody should have to read it anyway" is by reading it.

Why make me scroll horizontally?

Re: Treating JavaScript like a 30 year old language

#20
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…

I had a manager once who would seriously write 250-500 character lines of VB6. When I see code disappear off the right margin I get very nervous. You can hide a lot of functionality that way, especially if your language supports multiple statements on a single line.
Post reply on HN