6 ms·

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

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

bayesianhorse 13y ago
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.
- ChrisAntaki 13y ago
  TypeScript & Dart are offering optional typing. ASM.js is seeing big performance gains through utilizing the numeric types, and avoiding the GC monster.
- jashkenas 13y ago
  > 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.
  - bayesianhorse 13y ago
    Exactly.
erokar 13y ago
Very intriguing. I hope you pursue this, if anyone I think you're the right man for the job.
curtis17 13y ago
"but to do so with a much more radical design." Now this is interesting. Working on anything!
bambax 13y ago
> I've been playing around with it a bit... Tell us more!
- jashkenas 13y ago
  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...
  - danso 13y ago
    ActionScript!
    - knowtheory 13y ago
      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.
antris 13y ago
> 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.
- jashkenas 13y ago
  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 ;)
  - ryanatkn 13y ago
    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 https://github.com/Gozala/wisp
ChrisAntaki 13y ago
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!
- jashkenas 13y ago
  > 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-languages-that-compile-to-JS#ruby 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
  - ChrisAntaki 13y ago
    >> 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!
rmrfrmrf 13y ago
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!
- danso 13y ago
  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
- elwell 13y ago
  I very much agree. Now, I only touch raw JavaScript when I absolutely have to.

bayesianhorse 13y ago

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.

ChrisAntaki 13y ago
TypeScript & Dart are offering optional typing. ASM.js is seeing big performance gains through utilizing the numeric types, and avoiding the GC monster.
jashkenas 13y ago
> 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.
- bayesianhorse 13y ago
  Exactly.

erokar 13y ago

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

curtis17 13y ago

"but to do so with a much more radical design." Now this is interesting. Working on anything!

bambax 13y ago

> I've been playing around with it a bit... Tell us more!

jashkenas 13y ago
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...
- danso 13y ago
  ActionScript!
  - knowtheory 13y ago
    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.

antris 13y ago

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

jashkenas 13y ago
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 ;)
- ryanatkn 13y ago
  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 https://github.com/Gozala/wisp

ChrisAntaki 13y ago

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!

jashkenas 13y ago
> 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-languages-that-compile-to-JS#ruby 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
- ChrisAntaki 13y ago
  >> 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!

rmrfrmrf 13y ago

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!

danso 13y ago
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
elwell 13y ago
I very much agree. Now, I only touch raw JavaScript when I absolutely have to.