The same is true for programming languages. Sure, anybody can read Python. But it's fairly verbose and attempts to mirror English. On the other hand, Haskell is somewhat terse and attempts to mirror mathematical notation. I've found that, after about the same amount of time with either language (about a year of off-and-on use for both), Haskell becomes far easier to read than Python.

So just because something is easier immediately does not mean it is any more readable. It could, in fact, be less readable and merely more familiar!

Other examples that highlight how understanding of mathematical research involves much more than just reading: https://docs.google.com/viewer?a=v&q=cache:5NM3XjxAWfUJ:... http://math.stackexchange.com/questions/13460/how-to-read-a-...

Experts don't take time to read notations. They take time to understand the full scope of consequences embedded in a line composed of such a condensed and readable notation, within the frame of an otherwise complex proof.

> Mathematical notation is not readable, no.

I beg to differ. You mention the recent possible proof of the ABC conjecture, and I happened to browse through various materials on the subject. While I am far from being able to understand the crux of the proof, I can perfectly read the various components of it. In fact the notation system is so readable it actually helps tremendously in grasping concepts previously unknown to me.

It's also as bad as natural language for ambiguity and informality.

I don't think either English text or mathematical notation is a magic wand for readable programming language; It's more about reducing accidental ambiguity and the amount of mental context needed for parsing 'natural' constructs in the language.

I don't think that's completely true. If you're used to algol or C-style, Lisps tend to be hard to read. Concatenative languages even more so. Not necessarily because they're hard to read in and of themselves, but because the "shape" of the code is "all wrong" compared what you're used to, and your usual anchors (keywords, binary operators, infix assingment, ...) are nowhere to be found.

I mean Arabic or Korean are not necessarily harder to read than English, but you've got to know them and how they work before you even recognize patterns in the squiggly lines and little squares.

They author's point is that Coffeescript is hard to read because it has too many edge cases which are not easily understood under a smalla and consistent set of rules. I have not programmed with CS, but it sounds like a convincing argument.

The point TFA raises is that people who're familiar with CoffeeScript syntax may still make mistakes resulting in completely erroneous but valid code. Yikes. And the inherent nature of whitespace or indentation makes the problem harder to detect by cursory inspection.

I have no strong opinions about CoffeeScript, myself. I just thought this was an interesting distinction, and a rare case where syntax makes a significant difference.

This isn't specific to Lisp, either. I posit that if you took your average C-like and removed indentation from any reasonably sized function or method (one or more loops, one or more if/else), you would have a hard time counting brackets.

i recall the days when i was thrown into a project where the requirement was to use mootools, rather than jquery. even though they are both "javascript" in nature, it severely limited my productivity. i can see the same thing happening to companies trying out coffeescript, it may seem like you are doing the better thing long-term wise, but in reality, it is not so much. it's better to just stick to standards and you'll be more productive down the line, i can almost guarantee it.

So you had jQuery experience and were inhibited by working on a MooTools project. I get that, makes total sense.

But then you say that switching to CoffeeScript may seem like a better long term choice but "in reality it is not so much."

Surely MooTools would've been fine for you as a long term choice.

Yes, there is a penalty to switching. Whether it's jQuery to MooTools, JS to CS, whatever. But that doesn't make it a bad long term choice.

Also, CoffeeScript is more than just saving keystrokes. That makes it seem like it's all about initial up-front cost savings. Instead, it's about having shorter, more expressive code. That pays dividends for the life of a project.

yes, but at the expense of a lot of other negative baggages that comes along with it. by having it's own compiler rather than leaving that to the browser seems like it's opening a can of worms.

and just reading from the comments, i can see how we could soon see a birth of "another language", that's supposed to be solve all problems coffeescript'ers face.

for one, i guess readability seems to be the common problem, which isn't good for productivity.

Don't you find it a little odd that you have such strong opinions on something you've never even tried?

That's called incremental progress a d most people see it as a good thing. Others yell, "Get off my lawn!"

Maybe saying it's widely accepted isn't entirely appropriate, but it certainly is gaining a lot of traction.

Once you are releasing things outside of your controlled/team environment using anything but JS is just a loop for others to jump through.

Considering that, releases would be in JS, as they should be.

if you now switch to coffeescript, something not remotely close to javascript or any other languages fwiw, you'll experience un-productivity. it's akin to having your top developers walking in eggshells and doing nearly nothing close to what he is capable of.

i think coffeescript is great in the sense that we are trying to create a better language. but i also sense how much damage it can bring to budding startups who can't find talented coffeescript'ers to fill the void when their lead developer moves on to other things.

a one off go project, i'd say it's fine. but anything more complex, i think you'll see programmers wishing they had gone back to what they were familiar with.

That's true for any tool/language/platform/whatever, everything has a learning curve (and coffeescript's is quite short). Going by your words we shouldn't ever learn anything.

And you shouldn't switch to a language if your developers are not comfortable with it. Do some experiments, try it out on a smaller project, then you might switch if you see good results.

What? What language can you read without knowing it first?