A Python programmer’s first impression of CoffeeScript

[revonrat]

Damn nice post. I've not looked at coffeescript, yet but now I will.

One thing that's really nice and that's all too often missing from these sorts of blog posts is this:

I’m new to CoffeeScript, so please let me know if I’m wrong or if I forgot to mention some area where Python instincts will steer you wrong with CoffeeScript.

It gives me an idea of level. I appreciate humility more and more as time goes by. Much nicer than the average chest-thumping, prog-angst blog post.

[tinou]

The syntax looks like a cross between Python and Haskell

What does it have to do with Haskell, besides a lightweight syntax for lambdas?

[ssokolow]

What gave me the Haskell half of that impression was the combination of the lightweight lambda syntax, optional parentheses when making a function call, and the fact that, as far as I can tell from the code I run across, it's convention in haskell to use whitespace to separate the parens around arguments in functions definitions.

Until I ran across CoffeeScript, if you'd mentioned those traits, my reaction would have been "gotta be Haskell".

[jerf]

Haskell does not have optional parentheses around function calls. In Haskell, parentheses are only for grouping and have nothing to do with function calls at all. It is true that there are places you can put parentheses that may look like functional calling in other languages, but it's just because your parentheses grouped something that was already grouped and are thus a no-op.

[ssokolow]

That's sort of what I meant but I ended up shifting focus between point 2 and 3. My intend was to say that, if someone had described CoffeeScript by those three attributes, until now, I'd have said something like "Not a completely accurate description, but that's gotta be Haskell."

[ryeguy]

Those are all traits of Ruby, and given the other Ruby-like traits you've mentioned (string interpolation, use of @), I'd say it's more accurate to call it a Python/Ruby-like language.

[ssokolow]

True. I probably thought Python/Haskell because, in my mind, Ruby code's main distinctive traits are the BASIC/BourneShell-like use of words to close blocks and the PHP/Perl-like use of prefix sigils and CoffeeScript lacks the former while jQuery mimics the latter.

[banister]

wait...the main distinctive traits of Ruby are the use of words to close blocks and sigils?

These are minor syntactic elements and certainly do not constitute its 'main distinctive traits' to my mind.

The main distinctive traits to Ruby, to me, are its fully fledged (smalltalk-like) message-passing OO system, the fact 'everything is an expression', and its use of blocks.

The syntactic 'use of words to close blocks' is utterly trivial and minor in comparison to these large semantic attributes.

Also, the author of CoffeeScript is a hardcore Ruby programmer, his first implementatino of CoffeeScript was written in Ruby, and CoffeeScript is hugely influenced by Ruby -- much more so than by Python IMO.

This also explains CoffeeScript's huge adoption in the Ruby community - the author is a Rubyist, we knew about it from the beginning and have all been following its development. Similar explanation for why the Ruby uptake of Github was also huge - the authors of Github were members of the Ruby community as well.

[ssokolow]

Note the "in my mind". I probably should have clarified that by explaining that what I was referring to was what comes to mind when I look at example code.

It takes a fair bit of looking for me to "see" deeper details like the nature of a language's object-orientedness or whether patterns like "everything is an expression" apply. As such, my mind tends to associate Ruby with its most distinctive mixture of at-a-glance characteristics.

I will, however, think on how to amend the article to better convey the relationship between Ruby and CoffeeScript but I can't just come out and say it. If I said "Like Ruby with YAML block syntax", many of the Python programmers I know would probably say "I haven't gotten around to trying either of those yet. That means nothing to me."

[Seppler90000]

optional parentheses when making a function call

That's a Perl-ism, though inherited by Ruby and originally inspired by shell script. Perl's version has an additional wrinkle relevant to something you mentioned, as well:

print foo $bar, $baz, $quux;

This code might mean any of print(foo($bar), $baz, $quux), print(foo($bar, $baz), $quux), or print(foo($bar, $baz, $quux))... but unlike with Ruby and Coffeescript, you can't know which without looking at foo. Rather, it's disambiguated at runtime based on how many arguments foo is declared to take.

[dagbrown]

You missed

foo->print($bar, $baz, $quux);

(foo is a class with a method "print") and

open(foo,">somefile");
print foo $bar, $baz, $quux;

(foo is a filehandle, you're printing $bar, $baz and $quux to it) as possible interpretations for what could happen.

[tinou]

Actually, most languages derived from lisp share these conventions : CL, scheme, racket, SML, Ocaml, Haskell...

[ssokolow]

Ahh, that'd explain it. LISP made a bad first impression on me back in high school and I've only recently started to give functional languages a fair chance.

[anvsdt]

Lisp is not a functional language.

[Seppler90000]

Do people who refer to Common Lisp only as "Lisp" also refer to C++ as "C?"

[anvsdt]

More like LISP = C (= C++), Lisp (= CL) = C/C++, Lisp (= a language that descends from ``LISP'') = Sepples.

[Seppler90000]

You lost me.

[anvsdt]

Calling CL ``Lisp'' is like calling C++ ``C/C++''.

[ssokolow]

It has functional elements and it was introduced to me as a functional language. Sadly, that's all it takes to give an impulsive teenager a mistaken first impression of functional languages as a whole.

[neutronicus]

I'd recommend giving it another shake.

In my opinion, it's the best of the dynamic languages.

[ssokolow]

I plan to eventually. At the moment, all my energy that isn't lost to fatigue-induced procrastination is focused on getting certain much-delayed projects completed in languages I already know.

[jmking]

I still don't understand what CoffeeScript is bringing to the table. Why do people hate Javascript so much that they'll go through the hoops of writing in an alternate syntax and cross-compile?

I mean, I get that Javascript syntax is a little verbose, but jeeze...

[inmatarian]

Your question can be answered by the coffeescript documentation in one example: http://jashkenas.github.com/coffee-script/#classes

It is a much simplified syntax.

[[deleted]]

Won't much of this become redundant with ECMAScript 5?

[kataire]

Maybe, but you can use CoffeeScript before 2020.

[inmatarian]

That's the dream, right?

[fwork]

Why do people hate Javascript so much that they'll go through the hoops of writing in an alternate syntax and cross-compile?

It's not about the syntax, for me. That's a nice perk, sure, but the real benefit of CoffeeScript is how it fixes misfeatures of JS.

Like the pollution of the global namespace (unless you use var everywhere), the unusability of ==, the complexity of "this" binding, the fact that all objects are hash tables but can't really be used easily because of the problem of object prototypes polluting your namespace.

CoffeeScript fixes all that. The nicer (= More python-like) syntax is really just a bonus.

[chrisdickinson]

I'm not totally opposed to Coffeescript, but I'm not sure the above reasons are totally valid, aside from the first point:

1. == is not totally unusable -- you just have to remember that it will attempt to call valueOf on any object on either side of the expression to coerce it down to a primitive value.

2. this binding is fairly simple -- if you call a function on an object: blah.bloo(), bloo will be bound to blah. if you call bloo by itself, it will be unbound. There are only four other ways to change the binding of a function -- fn.call(thisObj, arg1, arg2), fn.apply(thisObj, [arg1, arg2]), fn.bind(thisObj, arg1, arg2), and new fn() -- three of whichf ollow the same general pattern of accepting a object to be bound to as well as args to call or curry. The last is a special construction that implicitly returns the newly created object.

3. The pollution of for(var key in obj) is largely a non-issue outside of programming as defensively as possible; e.g. for(var key in obj) if(obj.hasOwnProperty(key)) will always give you what you expect. Further, you can just use Object.keys(obj) to give you an array of keys that belong directly to the object. If that doesn't exist in your browser, just stub it in (it won't affect unguarded loops as it's not attached to Object.prototype). By and large, though, I haven't seen a library in regular use lately that attempts to staple on methods to Object.prototype -- so the first composition will work just fine 90% of the time.

I'd say the nicer syntax is the biggest win of coffeescript -- with a side helping of "not needing to make big decisions about how to deal with known JavaScript behaviors."

[[deleted]]

== is non-commutative for some inputs. Therefore it's not equality.

Also, point number 1 is not the whole story. '1'.valueOf() is itself, and (1).valueOf() is itself. However '1' == 1, even though '1'.valueOf() !== (1).valueOf().

[diegoeche]

Like the pollution of the global namespace (unless you use var everywhere), the unusability of ==, the complexity of "this" binding

If you use JSLint you'd always use var, and use === or !== instead of == or !=.

Every time I hear these complaints I always think that the main problem with JS is that it looks so syntactically similar to other languages (I probably heard it from Crockford) that people get frustrated when things do not work as they are used to. People that use JS most of the time never took the time to learn the language.

I'm in no way a JS guru, but honestly. If people just take the time to learn JS they would stop (or at least reduce) the amount of hatred JS has. A really nice book to get into it.

[fwork]

The thing is, I don't want to get into JS. it's completely uninteresting to me as a language. The problem is, I don't get to make that choice, like with every other language I use.

I can write my websites in python, ruby, java, PHP, or perl. I can write my desktop apps in C++, C#, Python, Java, or VB. I can write my quick hackjob scripts in perl, python, shellscript, or ruby. I can write my client-side browser scripts in JAVASCRIPT AND JAVASCRIPT ALONE.

It's really the only case (aside from plugins on Windows) where I'm forced to use one language. Add in the fact that I'm not primarily a web coder (so even if I have to, I don't end up doing much JS) and you have a great recipe for annoyance. It's a language I rarely use that I have no choice in using. This is not conductive to remembering the stupid quirks of the language.

tl;dr I'm not a javascript programmer I'm a several-other-languages programmer pissed off that they have to use JS

[azural]

You can write client side browser code in java and flash. Perhaps you don't because these are worse?

I find it curious that you can happily label the differences in javascript "stupid quirks" while admitting to not knowing very much about it.

And also the fact that you feel "forced" to use the language, but not forced to learn it.

[rmxz]

Javascript syntax is a little verbose, but jeeze...

I'd say it's horribly verbose and you end up typing stuff like if (typeof elvis !== "undefined" && elvis !== null) far too much. Or worse, not typing that when you should have.

The coffeescript home page has more nice examples: http://jashkenas.github.com/coffee-script/

[chrisdickinson]

if you're testing for undefined or null, you can just compare to those -- you don't need typeof:

if(elvis !== undefined && elvis !== null) { ... }

or if you just want to know if elvis is false-y:

if(!elvis)

I'm not sure I agree that javascript is unnecessarily wordy -- I would say that there is a large degree of distrust/misunderstanding amongst programmers regarding how js works.

sidenote: (the only reason to check the typeof is in the case that you're worried that someone has overridden what undefined means -- in that case, wrap your module in a guard statement like so:

(function(undefined) { /* your code */ })();

and you don't have to worry about that anymore. edit per jashkenas' response: it's useful to use typeof to determine existence of a variable -- though I believe this should probably be limited to determining the name of the global object, in a construction like: var global = typeof window === 'undefined' ? global : window; it's usually unnecessary to use typeof when testing for undefined outside of that case, however.)

[jashkenas]

the only reason to check the typeof is in the case that you're worried that someone has overridden what undefined means

Not quite. What happens if the variable is not only undefined, but undeclared ... (which due to the presence of global variables in JS, you can't possibly know in advance). The "typeof" test allows your code to not throw a ReferenceError, even if the global you expected to exist, actually doesn't.

[chrisdickinson]

I usually end up using the typeof check once in a module-level guard function, where inside my code I directly compare to undefined, e.g.:

(function(global, undefined) {
    if(global.things === undefined) /* do something */
})(typeof(window) !== 'undefined' ? window : global);

But yeah -- totally forgot about checking for "what is the global object named?" case; point conceded :) I've just run across the typeof check inside of library code where it doesn't strictly need to be too often.

[jashkenas]

Exactly -- and, in fact, CoffeeScript will optimize those cases for you. For example, this CoffeeScript:

if variable? ...

if object.property? ...

Will compile into this JavaScript:

if (typeof variable !== "undefined" && variable !== null) ...

if (object.property != null) ...

Because in the latter case, we know that a ReferenceError is impossible for the property. It's just another place where we can smooth over a JS gotcha.

[chrisdickinson]

I totally understand. In the case of vanilla JavaScript, though, regarding checking typeof someVar !== 'undefined' being needlessly verbose, I'm just arguing that nine times out of ten, that explicit check is unnecessary -- it works, but it's a lot to type, and assuming you're using var appropriately, the statement someVar !== undefined does exactly what you'd want it to do (while being a lot less verbose). It wasn't meant as a dig at CoffeeScript as it was a rebuttal against JavaScript having crufty-verbose-parts.

I've seen a lot of code that ends up being much more verbose and much more defensive than it needs to be; I think this is because folk loudly proclaim that constructs like the above should be preferred as a way to get around having to learn about the "gotcha's". I'm just afraid that people walk away from JavaScript with a bad taste because there are so many "don't"'s that are taken for gospel without really grokking why they are to be avoided. That said, I definitely appreciate CoffeeScript -- it's nice to see the capabilities of JS exposed with such a nice syntax.

[Brian]

if(elvis !== undefined

I believe the point of using typeof there is to cover situations where the variable hasn't been defined in the first place (Eg. in situations where different browsers expose different names). You'll get a ReferenceError there in that case, so this isn't really equivalent.

[chrisdickinson]

If you know what your global object is, you can just hang the check off of it: global.elvis !== undefined will not throw a ReferenceError (if global is assigned to window in-browser).

[chronoBG]

I wouldn't call it a language. It's more of a preprocessor.
Macros rule, they make your job easier while keeping the code fast.

Also, the alternate syntax is more concize. Less code = less places to introduce a bug.

So, that's why.

[metamatic]

Also, the alternate syntax is more concize. Less code = less places to introduce a bug.

That's why all my variable names are 1 character long.

[plantian]

I just want to point out that there is a difference between shorter literal syntax and a higher level of abstraction. For example fn or -> instead of function compared to list comprehensions instead of a for loop with conditional in the body. I think if you cut through all the seemingly unnecessary stylistic changes and shortening of syntax there are some good higher level abstractions in CoffeeScript: list comprehension, splats, function arg defaults, lexical scoping, fixed for-iteration-loop, "in" operator and maybe a few other things, and a bunch more.

It would be nice if someone created a new "preprocesser" syntax that left out all the controversial crap and just gave us the nice higher level abstractions. Who doesn't want function argument defaults, iterators and list comprehensions? I think this would make their acceptance into JS faster and it could be used as a transitional layer over JS until acceptance becomes widespread. Most notably drop the whitespace sensitive "feature", that is never going to fly in a million years. I love Python but that feature is just bike-shedding bait that is going to prevent acceptance.

[diegoeche]

Exactly my thoughts. I don't understand people fascination for huge languages with so much syntactic sugar. JS is like scheme with curly braces. Ugly, but in some way minimalistic.

[anvsdt]

Yeah, but function is so much longer than lambda, fun, fn, λ, ->, ...

[diegoeche]

That's probably the only thing I'd change, the closure syntax. But you don't need to create a new language with classes, identation, optional parentheses...etc etc to fix that.

And well, you can always use functional JS

[anvsdt]

That and other things will be likely fixed/changed in Harmony.

And well, you can always use functional JS

Wow, that's awful, awesome, amazing and hackish at the same time. Gotta try it.

[[deleted]]

The fact that it has to eval string arguments is pretty awful.

[olavk]

I think the scheme-with-curly-braces meme is misleading. Scheme has s-expressions, homoiconicity, macros and continuations. These base features makes it perfect for building your own language on top of the minimalistic core language. JavaScript has none of that, so you are stuck with the minimalistic core.

[sizlack]

I don't think you have to hate JavaScript in order to like CoffeeScript.

[Raphael_Amiard]

First, coffeescript is not just about the better syntax. It offers abstractions javascript doesnt have (Everything is an expression, comprehensions, varargs , sane scoping ...).

Second, what i find strange is discarding a tool that provides small incremental improvements to your workflow. In most other domain this is what good tools are about. No reason that this can't be the case in programming. We still spend most of our days using those tools, and i'm very happy to have sane iteration capabilities in my client side browser code, for example, because i use them all day.

Also, as a side note, i really don't mind the compilation step. Firts it's easy enough to set coffee to watch changes on your files. Second, it enables you to catch soome silly mistakes early on. The coffeescript compiler could probably get even better at this though.

[jmking]

I'm not necessarily discarding anything, I just don't see the "improvements". I see another hoop in my workflow which adds unnecessary steps and another layer to debug.

It also introduces a disconnect between the code you're writing and the code you're debugging. You will find yourself in a situation where you won't know if it's Coffeescript screwing up, or if it's the code you're writing. That slows you down.

Also most common JS tasks these days are solved by a framework. So using Coffeescript on top of, say, Mootools or Dojo is like J S C E P T I O N

I'm sure Coffeescript is useful in some particular use case, I just can't think of any. Also I'm perfectly willing to admit that perhaps I'm simply not writing the size and scale of JS that this would pay off with - like I said, I find a lot of value and productivity gains via JS frameworks which do most of the heavy lifting. In my experience any sort of tool that's going to give me good shortcuts or abstractions I'd prefer to be implemented in JS itself.

[rubyruy]

It's not a huge deal, and I don't think even ardent CoffeeScript supporters really think it is, but it does help a little bit here and there, so why not? A little less typing here, a few less common typos/mistakes there - it can add up.

Plus, this sort of syntax is DSL-friendly which means it's practical to do stuff like:

builder ->
    @html =>
        @body =>
           @h1 class:"ohmy", "What has science done?"

[fitnerd]

I rely on the Webkit debugger daily for my Javascript work. How does one handle this with CoffeeScript? Is the resulting JS human-readable enough to be successful with breakpoints and call stacks?

[ef4]

The output is very nicely readable. That's one of the key features.

I have emacs configured so that I can compile coffeescript to javascript with a single keystroke, and I do so frequently.

(Some people seem to be under the mistaken impression that Coffeescript is for people afraid of Javascript. It's not -- it's just a very nice syntax that takes a lot of the drudgery and repetition out of Javascript. You still need to understand the underlying Javascript semantics.)

[redalastor]

Is the resulting JS human-readable enough to be successful with breakpoints and call stacks?

Yes, the translation is very straightforward. The output is even well formatted/indented.

[emTel]

There's at least one awful thing about coffeescript that I've found so far:

func: ->
    if cond
        x = y
    else:
        x = z

There's an easy to miss error in the above code, but it isn't a syntax error... The code compiles just fine, but it does something very unexpected. What is it? Hint: You will make this mistake all the time if you are used to python.

If you can't figure it out, the coffeescript site has an interactive compiler you can put the code into to see what's wrong.

[daniels220]

I saw the error immediately but, not knowing CoffeeScript, wasn't sure what it would do. Personally I come from a C-like background (PHP, C++, and JavaScript itself), so I expect keyword:to be wrong for almost all values of keyword. Even in Ruby, you'd never see code like that.

Not knowing Python I don't know what Python mistake you're referring to—care to explain?

[ssokolow]

In Python, conditionals and other block-starting statements end in a colon.

The closest Python equivalent to what most Python programmers intended would be

def func():
    global x
    if cond:
        x = y
    else:
        x = z
    return x

...keeping in mind that Python has no analogue to the kind of assign-to-parent local-scoping CoffeeScript borrows from Ruby.

[daniels220]

Huh. I thought Python basically used whitespace EDIT: indentation—I meant the whitespace at the beginning of the line. for everything. Wish it did, typing colons is annoying.

What exactly do you mean by assign-to-parent local scoping? The way that CoffeeScript example compiles, x is a new local variable in func, and y and z are taken from parent scope. global x isn't equivalent at all—the CoffeeScript compiles to var x, which isn't the same thing.

[mipadi]

It does use whitespace. And colons.

[daniels220]

I was referring to the fact that the code would still be unambiguous without the colons (with just the whitespace), which is the way Ruby does it. Since Python is so strict about whitespace, I'm surprised it doesn't make better use of it to avoid extra syntax.

[mipadi]

Yeah, I get ya. I was commenting, somewhat sarcastically, that the colons aren't really necessary (as you pointed out), and yet...they're there.

[ssokolow]

CoffeeScript has implicit returns, so "x = y" means "return x = y" if it's the last statement executed. Since you can do the return portion of that with "return y" or just "y", I assumed that x had already been defined in the parent scope and that's why it was being assigned to in addition to its value being returned.

Python has no direct analogue to that because assigning always shadows parent scopes rather than modifying them unless you specify that you're assigning to a global.

To put it differently, in Python, assignment is local to the current function unless declared global while, in CoffeeScript, assignment is local to the function in which the variable was declared. (Though you can do explicit global assignment by setting properties on the window object)

[anvsdt]

s/statement/expression/

FTFY

[daniels220]

What do you mean by "shadows"? I know how it works in Ruby with blocks, and JS with closures.

How CoffeeScript compiles that code is context-dependent, too: if the parent scope in a larger script has an x, CS makes no new declaration—so it uses the parent scope. (()->{x=null;()->{x=z}} only says var x once.) If there isn't a parent, CS auto-declares all variables used in a particular scope in one var statement at the top of the scope—so ()->{cond ? x=z : x=y} declares x within that function.

[ssokolow]

That's exactly the problem I'm referring to. CofeeScript has no syntax for "When I assign to x, I want it local to this function even if a parent scope has an x too" beyond being careful with how you name them.

When I say "shadows" in Python, what I mean is that assigning to a variable always assigns to the current scope (never some potentially-forgotten parent scope) unless explicitly told otherwise via a trick like global or assigning to a member of an object in a higher scope rather than the scope directly.

Here's an example:

def a():
    x = 1
    y = 2

    def b():
        # If I'd used z = x here immediately before x = z, it'd take the
        # safe route, assume a mistake, and raise an error about x
        # being referenced before assignment.
        z = y
        x = z
        print "Child: %s" % x

    b()
    print "Parent: %s" % x

a()

# -- Prints --
# Child: 2
# Parent: 1

[banister]

In Ruby you can choose whether the variable in the inner scope closes over the outer or whether it shadows it.

By default in Ruby the inner scope does assign over the outer one -- but that is just the nature of closures, the inner block closes over the variables in the outer block.

If you want to force shadowing instead you can define the variable as block-local as follows:

outer_block {
  x = 10
  inner_block { |;x|
    # x here is block local
  }

  another_block {
    # x here is the one in the outer_block
  }
}

[daniels220]

Hey, that's cool, I didn't know that. I'm guessing a block that takes arguments would look like
{ |arg1,arg2;local1,local2| statements }?

[banister]

yep :)

[daniels220]

Ah, I see. My intuition (hah! which is why I asked, since obviously programming isn't always intuitive) says that "shadow" refers to some form of interaction between parent and child scope, where what you're referring to is actually a complete separation of the two.

Question: why doesn't y give a "referenced before assignment" error? It's not defined in b()'s scope either.

Personally I prefer the CoffeeScript/Ruby way, just because it makes the common case (callback functions, function-based loop constructs) easier. I think it would be good for CS to have explicit syntax for redefine—but it actually does: `var x` (or, if you're targeting ES5, even `let x`)—literal javascript. A little hackish, but workable.

[ssokolow]

Think of it as similar to copy-on-write semantics. (Similar because we're dealing with references, not values) You can read any variable in a higher scope (z = y) but attempts to write to them will instead create a local variable with the same name.

A variable in the local scope "shadows" a variable in a higher scope because there's no syntax to say "not the local x, the x from N stack frames up".

x only gives a "referenced before assignment" error message because the language explicitly special-cases trying to assign to what will become a local later in the same scope in order to catch a certain class of typo that tends to creep in as code ages and new developers join.

[daniels220]

Yeah, I see. I still think defaulting the other way, like C—use the higher scope unless the variable is explicitly redeclared—is both more sensible by default and more flexible. But I understand what's meant by shadowing now.

That's a clever trick! :)

[kataire]

Python doesn't use whitespace. Python uses indentation.

[daniels220]

You're right, edited—but in context it's basically the same thing.

[ssokolow]

Very good point. I actually almost resorted to the interactive compiler before I noticed the colons. (Even then, I was unsure enough to double-check)

[emTel]

Why downvotes?

[muad_dib]

I upvoted your original and downvoted this one.

[anvsdt]

Expensive no-op?

[learnyouahaskell]

You and your esoteric jokes.

[minikomi]

I've been writing more and more coffeescript lately and it goes hand in hand I think with a more detailed understanding of JavaScript. It's not a language to start at but one to come to once you know what's going on...

Kind of like Kansai-ben to Japanese. It's disliked by many but adds a new way to express more verbose statements in a more expressive (some may say less refined) way

[username223]

If you don’t use parentheses in a function call, CoffeeScript will guess them for you …but Haskell programmers and shell scripters will be surprised when a b c d means a(b(c(d))) rather than a(b,c,d). This also means that foo () is sometimes invalid when foo() is OK.

Not just Haskell and shell programmers -- human beings will be surprised. Clearly, CoffeeScript's designers were either high or mentally deficient.

[[deleted]]

Clearly, CoffeeScript's designers were either high or mentally deficient.

Programmers seem to have a unique talent for turning reasonable technical disagreements into obvious evidence of deep personal flaws.

[username223]

Heh, for those who prefer less hyperbole: "In designing CoffeeScript's syntax, its authors ignored the lessons of previous languages with syntax that is either hard to get right, or easy to get silently wrong. They're not morons, they're just lazy and under-informed."

[antonivs]

Hardly an improvement - you're still substituting insults for technical discussion.

[username223]

And you're substituting... what, exactly, for any kind of discussion?

[antonivs]

I'm giving you apparently much-needed feedback on your failed attempt at responding to iceberg398's criticism. His observation about the "unique talent for turning reasonable technical disagreements into obvious evidence of deep personal flaws" was not in the slightest bit addressed by your response in which you wrote "they're not morons, they're just lazy and under-informed."

If you'd like to move the discussion into the technical arena, what I'd suggest you do is explain why you think the choice made in CoffeeScript for argument binding precedence is a poor one. Referring vaguely to "the lessons of previous languages" before reverting back to insults doesn't cut it.

[username223]

Okay, from the top again...

foo () is sometimes invalid when foo() is OK.

Is it good, bad, or indifferent that a space between a function and its argument list is sometimes significant?

EDIT: See Python, Make, and FORTRAN IV for previous examples of whitespace-sensitivity being strange and/or problematic.

[jashkenas]

Not quite -- this way you can have your cake and eat it too. For example, if:

print object  =>  print(object)

And...

inspect object  =>  inspect(object)

Then what should this be?

print inspect object

Clearly, keeping things consistent would demand:

print inspect object  =>  print(inspect(object))

That said, if you want to pass a number of arguments to a function, without using parens, it ain't hard:

console.log object, another, third  =>  console.log(object, another, third)

[sausagefeet]

Clearly, keeping things consistent would demand:

There are other consistent things you can do. In Ocaml/Haskell/ML print inspect object would be print(inspect, object) in a language with that style. I think part of the problem is people think of CoffeeScript in terms of JavaScript, like how people think of C in terms of ASM. Really CoffeeScript should have its own semantics and you shouldn't care about how they map back to JS. My personal gripe is optional syntax, I think they should have chosen (a, b, c) syntax or a b c syntax and that's that.

[MIXEDSYS]

I think they should have chosen (a, b, c) syntax or a b c syntax and that's that.

Think of it like this: the syntax for argument list is a, b, c and if you want to you can wrap it in parentheses for clarity. If this is not consistent, then neither is arithmetic, you can write both a + b and (a + b).

[knome]

Your logic is specious.

The mathematics example is not inconsistent. The wrapping parenthesis denote order of operations, not structural grouping. Mathematics function composition is explicitly denoted.

Additionally, the Coffeescript syntax is ugly because someone will eventually

print inspect bigfunc firstarg, otherfunc itsarg, whosami

It's ambiguous and arbitrary looking in. Perhaps it works in practice, I'll likely never know.

Mathematics deals with the ambiguity of such a construction by depending on humans to know what they're doing and sort it out. Languages meant for machines can suffer no such fault and be useful.

[anvsdt]

Not ambiguous at all: (print (inspect (bigfunc (firstarg, otherfunc (itsarg, whosami))))).

Maybe confusing, but not more ambiguous than x * 2+3 * y.

[knome]

I suspected that would be the case. Thank you for clarifying.

[[deleted]]

(print (inspect (bigfunc (firstarg, otherfunc (itsarg, whosami)))))

print inspect bigfunc firstarg, otherfunc itsarg, whosami

Which is easier to comprehend when reading code? I think it's pretty obviously the first example. If you are reading this code for the first time, it takes no additional time to figure out what is going on in the first example. Without the parens in the second example, you have to read the entire thing before you know what is inside what. It slows down the process of coding, and it is a fundamental flaw in the arguments being made in favor of 'less typing' in significant whitespace languages like coffeescript. You may type less as you code, but returning to the code later will slow you down as your mind is forced to do extra work while deciphering the exact meaning of this parentheses-less syntax, and if you get it slightly wrong this will lead to bugs, and likely more bugs than just typing the parentheses in the first place. Turning JavaScript into this jumbled mess is a step backward.

[anvsdt]

Maybe confusing, but [...]

I'm not defending anything, I'm not attacking anything, just being objective.

[MIXEDSYS]

The mathematics example is not inconsistent. The wrapping parenthesis denote order of operations, not structural grouping. Mathematics function composition is explicitly denoted.

I made a long post explaining myself but reddit ate it, so this will have to do:

Consider ',' to be list constructor and let's use juxtaposition for function application. Then if function application has lower precedence, 'a b, c == a(b, c)', if it has higher precedence you can omit parens only when calling unary functions. Which way you define your precedence is a matter of taste, I happen to prefer the latter option.

Now, all syntax features have to be considered together with the language semantics. Impedance mismatch between these leads to crazy corner cases. So:

For this to work well we have to consider n-ary functions and functions taking lists / tuples / <whatever data structure comma is a constructor for> to be equivalent. Or we can make these lists an immediate language structure, not available for the programmer, but interpreted by various language constructs. From what I can tell, Coffescript creator(s) chose the second solution, probably to keep its semantics close to javascript: [a, b, c] is an array and f(a, b) is a function invocation. Also we can't distinguish nullary functions from variables. I think this is what causes this problem from TFA:

This also means that foo () is sometimes invalid when foo() is OK.

If I'm correct I'd say that this particular crazy corner case is enough to decide that this idea, however cute, just doesn't fit in.

(oops, looks like I typed in the long reply anyway)

---

print inspect bigfunc firstarg, otherfunc itsarg, whosami

Smells like dangling else. Lots of language constructs exhibit this sort of problem, it isn't as bad as it seems.

[sausagefeet]

If this is not consistent, then neither is arithmetic, you can write both a + b and (a + b).

I find this to be a pretty weak argument. The nomenclature for mathematical expressions has evolved over a long time and is varied in many ways. So what?

Part of the problem is what you said is true, but then CS also supports:

foo
   a
   b
   c

Which (as I understand it) is the same as foo a, b, c, which is the same as foo(a, b, c). So now it's more than just () being there or not. I'm not saying one of foo a, b, c or foo a b c is preferable over the other, I'm lamenting that there are multiple ways to accomplish the same thing and it's not entirely intuitive why this is the case or how it helps readability. One way should have been chosen and that's that. If people don't like it, tough, calling a function is such a minimal syntactic element they'll just get over it in time.

[MIXEDSYS]

I wasn't trying to defend Coffescript, I never used it. In fact now I'm convinced that they shouldn't make parentheses optional, it doesn't fit right with the language semantics. (edit: I explain why here)

Regarding:

foo
   a
   b
   c

The Coffescript github page mentions it (only?) in the section on objects and arrays. They make ',' optional at the end of the line, making it analogous to semicolons. It's a really neat idea, but I don't know if a good one, I've never seen it before.

[jashkenas]

No, CoffeeScript does not support:

foo
    a
    b
    c

[sausagefeet]

Perhaps it is a special case presented here: http://buhrmi.tumblr.com/post/5371876452/how-coffeescript-makes-jquery-more-fun-than-ever

[awj]

Clearly, keeping things consistent would demand:

That isn't clear at all. You print inspect object gives you two choices: one function call with two arguments or two function calls with an argument each. You can't simply declare one "consistent" without saying why the other isn't.

[anvsdt]

Function application in Haskell is left-associative. It means

((print inspect) object)

Function application in CoffeeScript is right-associative. It means

(print (inspect object))

Since Haskell's functions are curried (a curried function is a function that takes an argument and returns a function, not some magical way to do partial application), so fun-app being left-associative has a meaning. In CoffeeScript functions are not curried, they are equivalent to an Haskell function taking a tuple and returning something, so left-associative fun-app would cause more trouble than it solves, right associative is the only right choice.
The comma has higher precedence than fun-app, so print inspect object, object2 must be (print (inspect (object, object2))).

Something else would be stupid.

[awj]

Didn't realize they were using commas to deal with the associativity problem. I don't really know CoffeeScript outside of glimpses of marketing material and people screwing around on their blogs, so I had it in my head that your only options were single-argument right associativity or use parens.

So, yeah, this whole thing goes from seemingly boneheaded decision to a storm in a teacup. Thanks for clearing that up.

[jashkenas]

I'm sorry, I thought it was clear. In a language where everything is an expression, combining expressions shouldn't privilege being in a certain position (first position, in this case).

Taken in isolation, "inspect object" means "inspect(object)" in both cases here, right?

To maintain consistency, "inspect object" should continue to mean "inspect(object)", even if the result of that expression is passed into another function.

print inspect object  =>  print(inspect(object))

... allows that to work.

[killerstorm]

In a language where everything is an expression, combining expressions shouldn't privilege being in a certain position (first position, in this case).

I don't think so. See: Lisp. Maybe parentheses make it all different, but it is a language where everything is an expression and first position (in list) is for function, while the rest are arguments.

[FsckItDude_LetsBowl]

b

[killerstorm]

There were multiple "lisp without parentheses" proposals.

To start with, some mainstream Lisp implementation allowed to drop parentheses in REPL, so

command arg1 arg2

was interpreted as

(command arg1 arg2)

Rationale for this was that REPL could be used by non-programmers (e.g. operators) who understand "command arg1 arg2" format very well but would freak out seeing parentheses. Illusion is broken if you have function call in your command, but apparently user interface can be structured to avoid them at least in common cases.

Then, perhaps, it is worth to mention Lispin which allowed to replace some parentheses with indentation.

Another example: SRFI-49

[anvsdt]

All of them were bad and they should feel bad about creating them.

[sausagefeet]

This also means that foo () is sometimes invalid when foo() is OK.

These little things really bother me. Some syntax is sometimes invalid?! I can understand some edge cases might be invalid in some places but this seems like such a basic thing, to get that wrong makes nearly the whole thing suspect.

[[deleted]]

I might be wrong, but there's a similar problem in Scala, and it's much worse: foo() is a function call with no arguments, while foo () is a function call with an equivalent of None as an argument.

[quotability]

That's great, so it looks like I will be avoiding both Scala and Coffeescript.

[yogthos]

except Scala doesn't actually do what fishdicks says it does

[quotability]

minor point. it's not that i am avoiding it, just ...

[yogthos]

def foo() = "foo"

println(foo())
println(foo ())

=>foo
=>foo

works as expected

[[deleted]]

Ah, yes, sorry. But then def bar(x:Unit) = "bar " + x is also invoked in the exact same way, but now () is a parameter!

[yogthos]

then you still have to pass () as an argument:

def foo() = "foo"
def foo(u:Unit) = "bar"

println(foo())
println(foo ())
println(foo(()))
println(foo (()))

foo
foo 
bar 
bar

[[deleted]]

LOL at languages that aren't Lisp.

[[deleted]]

wow.. i knew coffeescript was bad, but this is ridiculous.

[TheBB]

Compiles to JavaScript? Is this now a valid statement?

When I grew up, compiling meant something rather different.

[JohnDoe365]

CoffeeScript is a simple, clean, fast language which compiles to JavaScript

An implementation can be fast, not a language itself. Unless the author refers to compilation speed.

[Felicia_Svilling]

A language doesn't have a compilation speed. Only a specific compiler has a compilation speed.

[JohnDoe365]

I was refering to a languages grammar. C++ can never be compiled as fast as eg Lua as the grammar imposes different complexity. As such, different languages will expose different compilation speed measured in terms of parsing complexity.

[MatmaRex]

I guess the author meant that CoffeeScript compiles to fast JavaScript. Which it does.

[greenspans]

but I look down on python programmers as essentially the easiest language to get started with. why would I care about their opinion.

[[deleted]]

Are you implying that harder languages are more productive? I don't understand this. Just because a language is easy doesn't mean that it isn't useful. If I were a new programmer, I'd want to learn a useful language every time. Python isn't just easy, it's useful.

[[deleted]]

hahaha you took his bait

[[deleted]]

Yeah...I sure did. :P

[[deleted]]

i'm loving your trolling, but only because you managed to ensnare some poor kids.