Hacker News Reader

Comment by jashkenas | Hacker News Reader

Despite most of the points in this post being debatable — there's one bit that caught my eye:

    "Being nice will not help it, and CoffeeScript is not radical enough."

As the guy who started CoffeeScript, I agree. It's an intentionally very conservative approach. But there's more than one good way to skin the JavaScript cat. I think it would be fun to take another run at the same problem — attempt to find a minimal, readable, and easier-to-learn language that fits in the same role as JavaScript — but to do so with a much more radical design. Whereas previously such a thing would have been unusable in practice, having good sourcemap support in most browsers these days makes it viable, perhaps. I've been playing around with it a bit...

View on HN

I have no idea why, but CoffeeScript gives me a "kid on Christmas" feeling when I code in it. I never realized how much mental load went into counting braces and curly brackets, how many times I've tried randomly copy-pasting a variable assignment into different parts of a script until I stopped getting an error, etc. This weekend, I decided to pick up Node, and, to kill 2 birds with one stone, I've been rewriting every tutorial I've used as CoffeeScript just to test myself.

I've tried to think about potential improvements to CoffeeScript, but I have to say that I'm completely satisfied with the language now. Many of the things that I think would sweeten the language even more are easily achieved by simply including 3rd party JavaScript libraries.

Thank you so much for contributing 3 great pieces of work to the community!

This is how I learned Angular and CS, by writing the todo apps in CS...after a bit, it was much easier to think and reprocess the concepts in my head as coffee script, especially when it came to test writing. I think the must-have for me is te bevy of ways to do auto compilation these days

I very much agree. Now, I only touch raw JavaScript when I absolutely have to.

> I think it would be fun to take another run at the same problem — attempt to find a minimal, readable, and easier-to-learn language that fits in the same role as JavaScript — but to do so with a much more radical design.

Do you think ClojureScript could fit this category? We have teams that use it in production without any significant problems at all.

It certainly could, and particularly so if you come from a Lisp background.

But it also connects to a larger universe of Clojure libraries and practices, and a vast history of Lisp tradition — most probably for the best. In that sense, it might be more of a maximalist approach than what I'm looking for. (And (of course) readability is in the eye of the beholder ;)

Have you seen Wisp? [1] It's a minimalist approach with Clojure syntax. For me it may be the next step after CoffeeScript, which I believe has subtly brainwashed me into loving the lambda.

[1] https://github.com/Gozala/wisp

Keep up the good work!

I still think the main point around javascript is the type system or the lack thereof. I don't mind dynamic typing, but the javascript data types are central to all HTML5 APIs and most existing libraries. CoffeeScript gets this right, many others don't.

TypeScript & Dart are offering optional typing. ASM.js is seeing big performance gains through utilizing the numeric types, and avoiding the GC monster.

    > CoffeeScript gets this right, many others don't.

I'm not sure what you mean by that — as CoffeeScript's "type system" has no difference from JavaScript's.

Exactly.

CoffeeScript was obviously inspired by Ruby. While CS is great, I've never gotten over the usage of "->" or "=>" to signify a function. To me, Ruby's "def" or "do" reads so much better. Especially with "end", to signify a barrier, as opposed to whitespace. Have you considered porting Ruby directly to JavaScript?

By the way, thanks for your work on _ & Backbone!

    > Have you considered porting Ruby directly to JavaScript?

No. It's been attempted before, and it doesn't turn out to be terribly useful in the end, because of the vast semantic mismatch between the two languages. See: https://github.com/jashkenas/coffee-script/wiki/List-of-lang...

    > I've never gotten over the usage of "->" or "=>" to signify a function.

Give it a try, perhaps. It's critical not to use "def" and "do" when your functions are first-class values that can be passed as arguments, or assigned to variables. It's for this reason that Ruby 1.9 has a new lambda syntax that looks a great deal similar to CoffeeScript's. For example:

    request(url, def callback(response) do
      ...
    end)

... that kinda thing is no good.

The reason it's an arrow is because in any decent function, the input determines the output, eg. input points to output. And therefore, the CoffeeScript syntax: (input) -> output

>> it doesn't turn out to be terribly useful in the end

True, I'd chose CoffeeScript over Opal.

>> Give it a try, perhaps.

Oh, I dig it, especially the fat arrow.

>> It's critical not to use "def" and "do" when your functions are first-class values that can be passed as arguments, or assigned to variables.

Still, I find "def" to be more `readable` than arrow symbols. I'm not sure how JavaScript's first class status for functions would deter a keyword containing letters. Considering JavaScript itself uses function as its.

>> The reason it's an arrow is because in any decent function, the input determines the output, eg. input points to output. And therefore, the CoffeeScript syntax: (input) -> output

That definitely makes logical sense. Still, I feel the readability might be increased by using words, which the mind is more attuned to quickly applying meaning to.

Edit: Great job, on CoffeeScript, regardless!

Also worth pointing out that the fat arrow lambda expression is coming in ES6 [1] so you will see it in vanilla JS soon!

[1] http://www.nczonline.net/blog/2013/09/10/understanding-ecmas...

> Especially with "end", to signify a barrier, as opposed to whitespace.

But in any programming language you're already indenting blocks for humans. Why repeat the same work? Especially when it allows for inconsistency between how a human and how a machine would read the code.

To increase the clarity, for future collaborators.

People HAVE written Ruby -> Javascript compilers. Check out Opalrb, Redscript, Coldruby, Hotruby, Webruby...

The -> comes from Haskell's lambda syntax (\x -> x+1). It's a nice solution. 'Def' doesn't really work for lambdas, do does, but curly-brace blocks are nicer in Ruby if you put them everwhere {|x| x+1}... Keep in mind that Javascript is alot like Scheme in that there isn't really a difference between named and anonymous functions. You can write Scheme and Javascript pretty much the same way...

Great points! I really want to check out Scheme now.

The arrow is standard mathematical notation for function definition

That's a good point, it has historical significance.

> Have you considered porting Ruby directly to JavaScript?

It's been done. Check out Opal. I can't say I miss Ruby's ends in CS.

Opal is cool. I prefer CoffeeScripts approach to adding functionality though, without including an entire new standard library.

> I've been playing around with it a bit...

Tell us more!

I'm afraid that there's not much to show yet, apart from some little prototype scribblings, and the basic idea:

The web that we build for today is a rich, almost entirely backwards-compatible stew of nearly two decades of browser development and standards work, resulting in a triumvirate of very different languages that need to come together in order to make a web application happen: HTML + CSS + JS. Two of them are weak, data-description languages, one is strong and general-purpose. You have to learn all three, and learn about the quirks and sunspots accumulated over the years.

So, as a thought experiment, imagine what it would be like to work with a single language that was general-purpose, but also excellent at describing data, especially the trees (HTML) and property lists (CSS) that make up web documents. Perhaps it knows about the intended lifecycle of your HTML in a more structured way. Perhaps other flatly descriptive parts of your application can be merged with the "flat" styling of your CSS descriptions. Perhaps the idea of "binding" is built-in.

After that, there's technical hoopla. If it's interpreted in the browser, you need to be light and parse quickly, you need to be able to "JIT" chunks of code into optimized JavaScript when necessary, and you need to be able to dynamically generate the appropriate source maps, so that it feels closer to a seamless experience.

Is such a unifying language possible? I don't know. But imagine how much more fun it might be to work with — and more importantly, how much more accessible it could be for folks just getting started.

But when there is something to show, y'all will be the first to know...

"So, as a thought experiment, imagine what it would be like to work with a single language that was general-purpose, but also excellent at describing data, especially the trees (HTML) and property lists (CSS) that make up web documents."

You can accomplish this pretty effectively with a clojure/clojurescript stack, though it takes some work to get going and isn't perfectly seamless. Code-as-data seems really well suited to unifying the declarative and procedural.

Personally, I love the ideas behind clojure, but I prefer the experience of writing coffeescript to clojurescript. I think it would be very cool to see you combine your penchant for pragmatism and nimble syntax with the solid engineering principles of functional languages.

I've been prototyping a HTML CSS javasxript all in one language to do exactly this, in particular great support for in-code representation of the data structures common in HTML. Hopefully you'll beat me to it so I can stop spending time on it and use yours instead =D

How do you feel about CoffeeCup + (CCSS or AbsurdJS)? Not unified enough?

ActionScript!

Yeah, the hilarious part of that being that Adobe, even prior to Steve Jobs's "flash sux" response, had begun to wander away from a purely ActionScript model into declarative markup via Flex.

I'm not 100% certain that declarative is wrong for presentational information. It just sucks that HTML + CSS are so messy. I'd even go for something that had a more parsimonious (note: not coupled tho) relationship between presentation/structure.

so basically YAML and/or Jade + SASS + CoffeeScript. I dig it.

Very intriguing. I hope you pursue this, if anyone I think you're the right man for the job.

"but to do so with a much more radical design."

Now this is interesting. Working on anything!

Reply on news.ycombinator.com