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

71–80 of 99 posts

Re: Treating JavaScript like a 30 year old language

#71

Post by scottschulthess »

ubernostrum wrote: post #6
scottschulthess wrote: post #3

Doesn't even mention coffescript

I am debating starting up a bot which just scans for stuff like this and auto-posts a reply of "Yes, this article didn't mention your favorite buzzword, and you must be incredibly perceptive and intelligent to have noticed this and pointed it out."

Why refer to CoffeeScript as a buzzword in this context? Coffeescript has gained popularity recently because it addresses some of the concerns about writing javascript raised in the post.

Coffeescript is not a buzzword, it's a relevant technology. Just because it's popular doesn't mean you should dismiss it, it's popular for a reason.

Re: Treating JavaScript like a 30 year old language

#72

Post by scottschulthess »

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…

There are lots of people who feel it (CoffeeScript) does indeed solve more problems then it creates.

If it actually does create more problems then it solves then a lot of people are just plain making a mistake by using it :) which I don't think is the case.

Plenty of programmers I know had a similar knee jerk reaction to the idea of CoffeeScript and have since decided it is a worth-while trade off.

You never know, you might be one of them!

Re: Treating JavaScript like a 30 year old language

#73

Post by cabalamat »

crazygringo wrote: post #54

I'm a huge fan of an 80-character limit. But more importantly, of having a rigorously-defined limit. It has nothing to do with history. Horizontal scrolling is a usability nightmare, and in programming, word-wrapping introduces ambiguities. Code should be designed to be read. You should be able to set your editor to the width defined by your project standards, and know that the code will always look the same to every…

Another advantage of an 80-char limit is that you can display two pieces of code side by side in separate windows.

Re: Treating JavaScript like a 30 year old language

#74

Post by cabalamat »

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 +…

I'd rather read:

    maxComb = maxFrag + maxUniform;
Or some other shortish variable names.

Re: Treating JavaScript like a 30 year old language

#75

Post by rbanffy »

mkmcdonald wrote: post #45

I'm pleased that someone else favours a sensible line limit. I stick to 72 columns for width and 20 lines per function body. The result has been very concise code that's easy to follow. Only exceptional cases such as heavy recursion have eluded the line limit. If popular JavaScript projects wrote code with cleanliness in mind, maybe more people would take the language seriously.

When so many text editors let you collapse blocks of code, it's hard to persuade programmers to keep line-count sane.

Isn't 72 columns a little bit restrictive?

Re: Treating JavaScript like a 30 year old language

#76

Post by shawndumas »

ufo wrote: post #62
shawndumas wrote: post #25

Earlier quoted context omitted.

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) }

Correct. But, like John Resig, I am gonna miss it...

    "Personally, I’m going to miss arguments.callee,
     I used it in a number of places in my code."

     -- John Resig (May 22, 2009 at 7:26 am) [1]
----

[1]: http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more...

Re: Treating JavaScript like a 30 year old language

#77

Post by [deleted] »

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 +…

[deleted]

Re: Treating JavaScript like a 30 year old language

#78

Post by jacobolus »

mundizzle wrote: post #58
greggman wrote: post #49

Earlier quoted context omitted.

>> I find that naming things descriptively and an 80 character limit are at odds. > I don't. I use descriptive names for functions and short, concise words for variables (sometimes clear abbreviations) That might work. Unfortunately abbreviations are forbidden by the Google Style Guide. > As for lining up my point still holds. Either lining up helps or it doesn't. If it doesn't help then lining up comments should not…

i generally avoid putting all properties of an object in one the same line in the name of readability and also to avoid the 80 char limit. instead i do something like this. (incorrect trailing commas removed from the previous example) var infos = [ { name: "red", value: [255, 0, 0, 255] }, { name: "green", value: [0, 255, 0, 255] }, { name: "blue", value: [0, 0, 255, 255] } ];

How’s this then, for another example:

    M_CAT02 = new Matrix3([
         .7328,  .4296, -.1624,
        -.7036, 1.6975,  .0061,
         .0030,  .0136,  .9834])
    M_HPE = new Matrix3([
         .38971,  .68898, -.07868,
        -.22981, 1.18340,  .04641,
         .00000,  .00000, 1.00000])
Without lining those all up, it becomes a real pain in the butt to read the matrix.

Re: Treating JavaScript like a 30 year old language

#79

Post by vorg »

> an 80 character line limit for code [...] eliminates the need to horizontally scroll

There's other ways fit your first example within 80 chars:

    setTransformStyles(context, buildTransformValue(this._transformOrder, _.pick(state, transformFunctionNames)));
How about?...

    放改型(势, 做改值(这._改订购, _.挑(态, 改函数名)));

Re: Treating JavaScript like a 30 year old language

#80

Post by kiwidrew »

vorg wrote: post #79

> an 80 character line limit for code [...] eliminates the need to horizontally scroll There's other ways fit your first example within 80 chars: setTransformStyles(context, buildTransformValue(this._transformOrder, _.pick(state, transformFunctionNames))); How about?... 放改型(势, 做改值(这._改订购, _.挑(态, 改函数名)));

The (crazy but awesome) "unicode literals" feature in Python 3 means that your example is actually a valid statement:

  Python 3.2.3 (default, May  3 2012, 15:51:42) 
  [GCC 4.6.3] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> 放改型(势, 做改值(这._改订购, _.挑(态, 改函数名)))
  Traceback (most recent call last):
    File "", line 1, in 
  NameError: name '放改型' is not defined
Of course I didn't actually define a function named 放改型...
Post reply on HN