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

Re: Treating JavaScript like a 30 year old language

#81

Post by mhansen » Thu, Jul 05, 2012, 3:49 AM UTC

greggman wrote: post #49

mkmcdonald wrote: post #47

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). > Another nit, Google Style guides disallow formatting for readability except for comments?!?! > Allowed > [regularly formatted variable declarations] > Not allowed > ["pretty" formatted variable declarations with indent…

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

Nowhere are abbreviations forbidden by the Google Style Guide.

Re: Treating JavaScript like a 30 year old language

#82

Post by roguecoder » Thu, Jul 05, 2012, 4:10 AM UTC

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 find that long variable names are usually a sign of design that needs improvement. For example, those names are highly repetitive and don't actually tell me how each of those variables is different from the other, which is the information I care about right that moment. By putting them into a function or prototype who's name communicates the commonality, say "getAllMax" on UniformVectors it could be just as communicative to say something like:

combined = fragment + original

Re: Treating JavaScript like a 30 year old language

#83

Post by roguecoder » Thu, Jul 05, 2012, 4:22 AM UTC

tikhonj wrote: post #50

Roboprog wrote: post #29

Earlier quoted context omitted.

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.

In Haskell you could actually just do adder = (+) because operators are just normal functions which happen to be infix by default. I think this is great--it's consistent, flexible and elegant at the same time. Not treating operators as something special makes the language simpler.

And to me that means absolutely nothing at first glance. It's much harder to read because I have to do all the work of translating it into the first example myself, and I have to do it when I was presumably trying to figure out what the code means. By the time I do I could have just written it that way in the first place.

The difference in style is similar to how the invention of punctuation, spaces, capitalization and paragraphs made writing much easier to read, and shorthand is annoying as all get out. It is certainly possible to misuse punctuation, spacing and paragraph breaks to the point where they make writing harder to read, but most often the writing wouldn't be good without them either.

Re: Treating JavaScript like a 30 year old language

#84

Post by icebraining » Thu, Jul 05, 2012, 9:30 AM UTC

mhd wrote: post #40

kemiller wrote: post #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 chara…

Especially when a tab isn't 8 spaces worth and you don't have a near useless level of indentation from the start (e.g. Java's "class" scope), I rarely found a problem with 80 (or 78) character limits. Quite the opposite, usually there's something "wrong" with code that exceeds that limit (a "code smell", as the hip kids like to say). Granted, quite often it's a "language smell", like Java or earlier C++'s verbose ini…

I don't know; I think it's fairly easy to hit that limit with some constructs like list comprehensions, particularly if they're inside a method (which cuts 12 characters with indention), yet remain readable. Something like:

    [person.name for person in people if person.country_of_origin == 'Netherlands' and person.age > 30]

That's well above the limit, yet I still find it more readable than either a for loop that appends to a list or a map/filter (which would also have go through the list twice).

Re: Treating JavaScript like a 30 year old language

#85

Post by jerbils » Thu, Jul 05, 2012, 2:11 PM UTC

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…

I meant that I optimize for project newcomers, preferably ones who are comfortable in the finer points of JavaScript.

It's not that I don't take advantage of JavaScript's strengths. I get the sense that people interpreted my article as a glorification of the Google Style Guide, that it should be followed precisely. I suppose I should have worded it better. My personal style is heavily inspired by Google's, but I freely deviate where I feel it is practical. For instance, I use closures and functional approaches when I feel it will make for faster/more readable code. It's mainly the annotations and and line limit that I follow religiously.

Re: Treating JavaScript like a 30 year old language

#86

Post by Roboprog » Thu, Jul 05, 2012, 2:17 PM UTC

tikhonj wrote: post #50

Roboprog wrote: post #29

Earlier quoted context omitted.

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.

In Haskell you could actually just do adder = (+) because operators are just normal functions which happen to be infix by default. I think this is great--it's consistent, flexible and elegant at the same time. Not treating operators as something special makes the language simpler.

What about the currying in the previous example? It made a function that had some value of X pre-bound to the addition operation, requiring only 1 operand/argument when called.

Re: Treating JavaScript like a 30 year old language

#87

Post by jerbils » Thu, Jul 05, 2012, 2:27 PM UTC

ricardobeat wrote: post #65

jerbils wrote: post #56

Earlier quoted context omitted.

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

Debugging compiled code is absolutely unpleasant. Fortunately, I only have to do it rarely. From what I can tell, debugging JavaScript that was compiled from CoffeeScript is a standard practice, and I simply don't want to pursue that. It's interesting how you describe CoffeeScript as a tool rather than a language, but in my opinion it is still a very leaky abstraction.

As I mentioned, I look forward to revisiting it when a standard toolset has matured.

Re: Treating JavaScript like a 30 year old language

#88

Post by jerbils » Thu, Jul 05, 2012, 2:32 PM UTC

hackNightly wrote: post #2

I thoroughly enjoyed this article. I'm always looking for ways to improve the readability and "share"ability of my code, and the author has provided several tips that I'll be taking forward. The part on strict-ish typing is brilliant. Very good read.

Thanks! :)

Re: Treating JavaScript like a 30 year old language

#89

Post by mjwalshe » Thu, Jul 05, 2012, 2:33 PM UTC

orangecat wrote: post #44

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 find that naming things descriptively and an 80 character limit are at odds. Agreed. 80 columns made a lot more sense in the FORTRAN days where variable names couldn't be more than 6 characters. Even in this article's example code, after doing the "right" thing of creating intermediate variables (debatable, as discussed in other comments), he still has to break the function call which harms rather than helps readab…

80 cols is to fit on a punched card and has nothing to do with the variable name length limit on old versions of FORTRAN.

Re: Treating JavaScript like a 30 year old language

#90

Post by sur » Thu, Jul 05, 2012, 3:44 PM UTC

Roboprog wrote: post #86

tikhonj wrote: post #50

Earlier quoted context omitted.

In Haskell you could actually just do adder = (+) because operators are just normal functions which happen to be infix by default. I think this is great--it's consistent, flexible and elegant at the same time. Not treating operators as something special makes the language simpler.

What about the currying in the previous example? It made a function that had some value of X pre-bound to the addition operation, requiring only 1 operand/argument when called.

Functions are curried by default in Haskell.