4 ms·

This fork brings some up deep issues, perhaps intractable, around about the development of syntax-y languages. Useful source transformations require marginalize

This fork brings some up deep issues, perhaps intractable, around about the development of syntax-y languages. Useful source transformations require marginalized forks of the compiler and all the development burden and risks that entails. In some sense CoffeeScript inherits the actual problem with JavaScript - a select few determine the introduction of language features. Perhaps these language features are best shipped as libraries? Maybe it doesn't matter. Perhaps most users don't need it. Or perhaps as we continue to develop software we'll find that we'd rather defer work to the compiler / macros and the high cost of syntax is simply not worth it. I'm looking forward to see how 3 languages I immensely enjoy (JavaScript, CoffeeScript, ClojureScript) co-evolve :)

btipling 15y ago
> the actual problem with JavaScript - a select few determine the introduction of language features. What language exists in which this is not the case? Language by committee sounds terrible.
- pufuwozu 15y ago
  ClojureScript (which swannodette works on). You can invent your own language features in a Lisp.
- jberryman 15y ago
  Haskell was designed by committee.
- masklinn 15y ago
  > What language exists in which this is not the case? Languages which have very little "own shape" (syntax) and let you transform it easily (via macros) or provide high flexibility. Mostly concatenative languages and Lisps, but e.g. Smalltalk or IO can probably be fit in that category as well, they have a minuscule syntactic core and that core is used to build abstractions and structures putting both the language's designers and the language's users on a level ground. Of course that creates other issues, where every developer or organization has its own lingo and structures, making even going from one codebase to the next more expensive. It's a tradeoff. Still, realizing that you have pretty much the same power as the language builders themselves when it comes to creating abstractions and datastructures and control flows... is an enjoyable feeling. > Language by committee sounds terrible. Can end horribly, and can end pretty well. Haskell was designed by a committee over ~10 years (FPCA '87 to the release of "The Haskell 98 Report" in 1997). It does generally end baldy.
- swannodette 15y ago
  I'm not talking about language design by committee. For example, ClojureScript is far more restrictive in its design than either JavaScript or CoffeeScript. I'm simply questioning where the line is drawn concerning what constitutes language extension and what is perhaps best served as a library.
6ren 15y ago
Regarding development burden, if ICS is implemented as additions to the language, then it can get all updates to the rest of CoffeeScript from "underneath" - the only proviso is that CoffeeScript syntax doesn't change incompatibly with it. And as ICS can be seen as a simple macro (plus libraries it uses), I would guess it is implemented this way (simple source transform on top of CoffeeScript, not hacking at the Jison grammar). This is one way around the issue you raise. Regarding the whether it's part of the language or a library as a distribution issue, it depends on what benefits users. For syntax, there's some benefit in uniformity (other developers can read it). I'm seeing ICS as a suggestion of a new feature in CoffeeScript. If it's really good (meets a need; bugs and design mistakes are fixable and fixed; it doesn't break other things), it could be back-integrated into CoffeeScript proper. Whether to do so can be better decided once data exists. :-) It's a great forking model for exploring new syntax, IMHO. EDIT but it breaks the CoffeeScript philosophy of readable JavaScript, and (eg) addes debug line numbers in to the source code (see "load" on the sample code). Also, other examples and more details on ICS here https://github.com/maxtaco/coffee-script/blob/iced/iced.md https://github.com/maxtaco/coffee-script/blob/iced/iced.md
apgwoz 15y ago
IcedCoffeeScript works through a CPS transformation, not sure how you could do that as a library in CoffeeScript...?

btipling 15y ago

> the actual problem with JavaScript - a select few determine the introduction of language features. What language exists in which this is not the case? Language by committee sounds terrible.

pufuwozu 15y ago
ClojureScript (which swannodette works on). You can invent your own language features in a Lisp.
jberryman 15y ago
Haskell was designed by committee.
masklinn 15y ago
> What language exists in which this is not the case? Languages which have very little "own shape" (syntax) and let you transform it easily (via macros) or provide high flexibility. Mostly concatenative languages and Lisps, but e.g. Smalltalk or IO can probably be fit in that category as well, they have a minuscule syntactic core and that core is used to build abstractions and structures putting both the language's designers and the language's users on a level ground. Of course that creates other issues, where every developer or organization has its own lingo and structures, making even going from one codebase to the next more expensive. It's a tradeoff. Still, realizing that you have pretty much the same power as the language builders themselves when it comes to creating abstractions and datastructures and control flows... is an enjoyable feeling. > Language by committee sounds terrible. Can end horribly, and can end pretty well. Haskell was designed by a committee over ~10 years (FPCA '87 to the release of "The Haskell 98 Report" in 1997). It does generally end baldy.
swannodette 15y ago
I'm not talking about language design by committee. For example, ClojureScript is far more restrictive in its design than either JavaScript or CoffeeScript. I'm simply questioning where the line is drawn concerning what constitutes language extension and what is perhaps best served as a library.

6ren 15y ago

Regarding development burden, if ICS is implemented as additions to the language, then it can get all updates to the rest of CoffeeScript from "underneath" - the only proviso is that CoffeeScript syntax doesn't change incompatibly with it. And as ICS can be seen as a simple macro (plus libraries it uses), I would guess it is implemented this way (simple source transform on top of CoffeeScript, not hacking at the Jison grammar). This is one way around the issue you raise. Regarding the whether it's part of the language or a library as a distribution issue, it depends on what benefits users. For syntax, there's some benefit in uniformity (other developers can read it). I'm seeing ICS as a suggestion of a new feature in CoffeeScript. If it's really good (meets a need; bugs and design mistakes are fixable and fixed; it doesn't break other things), it could be back-integrated into CoffeeScript proper. Whether to do so can be better decided once data exists. :-) It's a great forking model for exploring new syntax, IMHO. EDIT but it breaks the CoffeeScript philosophy of readable JavaScript, and (eg) addes debug line numbers in to the source code (see "load" on the sample code). Also, other examples and more details on ICS here https://github.com/maxtaco/coffee-script/blob/iced/iced.md https://github.com/maxtaco/coffee-script/blob/iced/iced.md

apgwoz 15y ago

IcedCoffeeScript works through a CPS transformation, not sure how you could do that as a library in CoffeeScript...?