Anyone esp key contributors to node js caring to comment on CoffeeScript, Harmony etc?

[Loot]

I'm a little concerned about the direction of Harmony, the next
version of JS. Brendan Eich keeps pushing for things that are very
CoffeeScripty which is great if you like CoffeScript. But I code in
JavaScript because I like JavaScript :-) I wont get into it here but I
am in the process of laying out a few arguments in my developing blog
post about it over at http://www.andrewluetgers.com/2011/09/07/coffescript-fanboyism-rampant/
Please comment here or on that post.

or

if not that please, PLEASE make your feelings known to anyone who will
listen especially anyone on the ECMA Script committee. I don't care
what you feel about it but the ECMA Script committee needs to hear
from and be driven by actual developers not just speakers and language
designers.

Here is Brendan's blog, I would highly recommend everyone here read it
and comment on it.
http://brendaneich.com/

we need to be aware of these proposals and have direct input into the
process, not just blindly accept whatever if handed to us.

[David Goehrig]

Having just built a large project using about a half dozen types node servers with all the code in Coffeescript, my biggest complaint is that it doesn't go far enough.

JS has some pretty serious warts, and the standards process is dangerously flirting with ideas like class systems that would derail JavaScript's evolution.

Eich's viewpoint is actually pretty in line with making JS a 100 year language. He's pushing to avoid making big mistakes by mandating language features to make current implementations easier (weak refs anyone?) but make long term evolution doomed to failure.

Coffeescript doesn't really change JS in any fundamental way. It adds some sugar for things good programmers were already doing. But it doesn't go so far as to fix the things that really need fixing:

* first class message sending (no more event observers, and silly Ajax hacks)
* macros (you can do it but Function.prototype.constructor doesn't cut it)
* multiple prototypes and proper traits (see Self for details)
* distributed programming methods and remote message sends (not this XHR crap)

Instead, we're fighting battles about how to build class systems into a prototype based language. (see Smalltalk implemented in Self and JavaScript and stop talking about it already).

Node being so callback heavy really benefits from -> notation. Also if you've done what I've done and extended it to have a messaging syntax (ala Erlang) you can further simplify building distributed software. What you get with multiprototype traits (and not hacked chains) gives you mixins and more reuse. And once you add these and proper message sends you can start building distributed apps for real (and all web apps have at least 2 nodes in their graph and are already distributed, but takes too much work)

Dave

-=-=- da...@nexttolast.com -=-=-

> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

[Joe Developer]

Re your post:

I think the first you should do is succinctly outline exactly what 'coffee-scripty' changes are being considered - not everyone has time to keep up with the proposals. 

Then you can go on and rant about it, its hard to decipher where you are talking about coffee-script and where you are talking about actual Harmony proposals.

[Loot]

What make you of the first argument that the intent of -> is
productivity which is a false premis and that -> can be obtuse
visually making scanning code more work.

Also the problem with callback soup is not the function keyword but
the multiple levels of nesting. Eich hase specific suggests for this
but the community has also addressed it with async controll flow
functions like https://github.com/creationix/conductor

[Loot]

thanks for the feedback much appreciated :-)

[R. Mark Volkmann]

What I make of it is that whether -> is good is very much personal opinion. Many languages are going with -> or =>. I believe the list at least includes C#, Groovy, CoffeeScript, and Java 8. I don't feel it is obtuse or hard to scan.

---
R. Mark Volkmann
Object Computing, Inc.

[Joe Developer]

What strikes me as odd about -> and also what I noted from Newspeak ( see thread about google's Dart ) where they use ^ for "return" is how non-ergonomic they are on QWERTY keyboards, I certainly don't believe that they are significantly faster to type for touch typists but they do force a wider range of movement than their traditional counterparts. 

Ultimately I find it hard to believe that the savings in characters by themselves is a significant productivity factor, seriously. Lets pretend you write 'function' 100 times in a day, hell, lets say 500 - further, lets assume that it takes you 1 second to type 'function' while only 0.5 second to type -> that is a whopping 4 minutes of time saved over an 8 hour day. Even if -> was magically instant and somehow not an invitation to forearm tendonitis, this still only saves you 8 minutes of your '1 function per minute, every minute' day. 

I also hear that there are might be text editors which support something called macros or expandTriggers or search and replace - pretty wild stuff there. 

In terms of reading code I am also somewhat doubtful - the biggest cost with reading code strikes me as stemming from ambiguity, where you need to rescan and consciously participate in the parsing. 

The overall cost can be reduced with bits of grammar such as { scope signifiers } and statement delimiters;

Overall though, I would imagine that the issue is with re-training more than anything - I would be surprised if the majority of people who seem challenged by { scope signifiers } and semi-colons are not simply used to different conventions from languages that they have spent more time with. There is an increasing number of people who likely got one of their early rushes from Rails, this is somewhat exacerbated by the fact that Rails is slow as limp dying dog and many outfits are looking to offset that by technologies like Node.js and being smarter about their front-end code.

It is the 'un-familiar' which forces context shifts between reading 'characters' and meaning. 

As for deep nesting, that seems entirely optional to me - if you don't like it, stop. 

Just because you *can* define inline functions doesn't mean that you *have to*, if you really need stuff in a surrounding closure then write code that expressly passes or binds it.  

[Mark Volkmann]

I think one person's noise is another person's useful syntax. I'm
confident developers will never reach a consensus on this. Some people
find beauty in concise code that they feel contains minimal noise.
Other people find beauty in more verbose syntaxes that in their mind
make code easier to read. CoffeeScript is the least noisy language I
have encountered and I value that. I understand though that for many
developers, that is not a compelling feature. Evidence of this is the
fact that there are actually people that like the syntax of
Objective-C. Thank goodness JavaScript isn't nearly as noisy as that!

--

[Mark Hahn]

I find that the more code I can fit in a window, the easier it is to read the overall logic.  So I don't use many blank lines or line comments and I really appreciate the 33% reduction in line count that I get from coffeescript.

Even though I took classes taught by Knuth, I've never believed in the "literate programming" concept.  I read code directly. Noise is just noise to me.

[Joe Developer]

At the risk of topic-shopping:

  1. Even if Harmony gets the -> construct, I assume that it has not 'gone far enough' to abandon 'compile to js' projects like coffeescript for the majority of its current ( and future ) adopters, a perceived benefit remains, so ultimately these changes to JS are unlikely to be leveraged directly by those who find them attractive. 

The main satisfaction will be 'we are on the right path', does that sound like a correct assumption?

2. Given Google's push for a wholly different language which will likely constitute a paradigm shift compared to JS, why not go the whole hog? By instead making a concerted effort to convince 'the deciders' to make it possible to expose a standardized bytecode interface we could have the best of most possible worlds in terms of expressive freedom. 

That would truly 'democratize' web development - though sadly at the likely cost of source code transparency.

On Sun, Sep 11, 2011 at 3:34 PM, Mark Hahn <ma...@boutiquing.com> wrote:

I find that the more code I can fit in a window, the easier it is to read the overall logic.  So I don't use many blank lines or line comments and I really appreciate the 33% reduction in line count that I get from coffeescript.

Even though I took classes taught by Knuth, I've never believed in the "literate programming" concept.  I read code directly. Noise is just noise to me.

[R. Mark Volkmann]

On Sep 11, 2011, at 3:34 AM, Mark Hahn <ma...@boutiquing.com> wrote:

> I find that the more code I can fit in a window, the easier it is to read the overall logic. So I don't use many blank lines or line comments and I really appreciate the 33% reduction in line count that I get from coffeescript.

Very good points! That's exactly why I never liked this style of Java coding.

if (condition)
{
// do this
}
else
{
// do that
}

[Joe Developer]

I can certainly agree with that :)

}

[Christophe Eymard]

I'm going to make a little more noise in this whole troll, but my whole reason to use Coco (Coffeescript's little brother : https://github.com/satyr/coco) is to avoid braces ({ }) and generally having to close chunks of code.

Indentation rules.

And yes, I think the argument about productivity is a stupid one. You're more productive if you know how to code better, not because you type a character less.

And about readability, you're generally more readable when you code in an intelligent way. A fancy language will not make your code magically readable (it can help though ; I have yet to read readable code written in PHP :) ).

In the end, those languages are a purely esthetic choice.

[Loot]

Yeah, so one of my main points is basically if you have one of the
most popular programming languages around I think you need a better
argument to change its syntax than esthetic choice.

On Sep 11, 10:15 am, Christophe Eymard

<christophe.eym...@ravelsoft.com> wrote:
> I'm going to make a little more noise in this whole troll, but my whole
> reason to use Coco (Coffeescript's little brother :https://github.com/satyr/coco) is to avoid braces ({ }) and generally having
> to close chunks of code.
>
> Indentation rules.
>
> And yes, I think the argument about productivity is a stupid one. You're
> more productive if you know how to code better, not because you type a
> character less.
>
> And about readability, you're generally more readable when you code in an
> intelligent way. A fancy language will not make your code magically readable
> (it can help though ; I have yet to read readable code written in PHP :) ).
>
> In the end, those languages are a purely esthetic choice.
>

> On Sun, Sep 11, 2011 at 15:10, Joe Developer <joe.d.develo...@gmail.com>wrote:
>
>
>
>
>
>
>
> > I can certainly agree with that :)
>
> > On Sun, Sep 11, 2011 at 7:58 PM, R. Mark Volkmann <

> > r.mark.volkm...@gmail.com> wrote:

[Christophe Eymard]

Well, there I'll disagree with you.

Javascript is the leader thanks to its historical context, not a lot thanks to its merits.

It is certainly deeply flawed, and in fact, developing in it is painful to me.

I like a lot the syntactic sugar provided by Coco and would certainly not consider going back to javascript.

I like having more code in fewer lines. Also, in the case of coco, I like chaining callbacks vertically without wondering whether I closed them damn braces or not.

(err) <- writeFile file, "utf-8"

console.log "my file is written"

is to me more appealing than

writeFile(file, "utf-8", function(err) {

console.log("my file is written");

});

In fact, I find code is more readable when it contains less noise.

Braces are noise, since they are avantageously replaced by indentation (and any clean coder would indent his code, whether there were braces or not), and ";" are useless when you know you won't put more instructions in one line.

I like when I can express stuff with less characters, since it pollutes less the visual space. I like how some constructs are handled for me

for stuff of array  

   ...

- vs -

for (var i = 0; i < array.length; i++) { 

    var stuff = array[i]; ... 

}

I think that this is way more elegant than the javascript idiom, and certainly not unreadable (in fact, it is more readable, and there is no chance of actually writing your for expression badly, like a i <= length that bugs).

I do agree, though, that too much syntactic sugar kills syntactic sugar and makes your code cryptic. But this is more a matter of applying clear rules to yourself. And too much syntactic sugar is always better than too little, because then you have choice.

And this is especially useful for idioms widely used ; *you gain in productivity because you make a lot less trivial bugs*.

[Srirangan]

I think the problem isn't syntax's and semantics. One's personal preference can be for coffeescript or javascript. I like a bit of both.

Code gets ugly when there is a lot of code in a single file and the code base isn't properly organized in "packages" and classes. And this can happen with both coffeescript and javascript.

Node.js solves this problem for server side JS but not for client side JS. Multiple <script> includes is the only solution, unfortunately. 

Will the new version of javascript support packages (namespaces), classes, creation of bundled components (js + html markups) etc. That's what I'm more interested in.

JS as of now makes it tricky to organize code neatly. Not saying it isn't possible, its just quite a bit harder to do so than Java, Python, Scala or even client side Flex (mxml / as).

- Sri

Srirangan  |  About  Blog  GitHub  LinkedIn  Twitter

[R. Mark Volkmann]

On Sep 11, 2011, at 12:58 PM, Srirangan <srir...@gmail.com> wrote:

> I think the problem isn't syntax's and semantics. One's personal preference can be for coffeescript or javascript. I like a bit of both.
>
> Code gets ugly when there is a lot of code in a single file and the code base isn't properly organized in "packages" and classes. And this can happen with both coffeescript and javascript.
>
> Node.js solves this problem for server side JS but not for client side JS. Multiple <script> includes is the only solution, unfortunately.

There are client-side solutions. See require.js for one.

[Joe Developer]

On Mon, Sep 12, 2011 at 12:58 AM, Srirangan <srir...@gmail.com> wrote:

I think the problem isn't syntax's and semantics. One's personal preference can be for coffeescript or javascript. I like a bit of both.

Code gets ugly when there is a lot of code in a single file and the code base isn't properly organized in "packages" and classes. And this can happen with both coffeescript and javascript.

Node.js solves this problem for server side JS but not for client side JS. Multiple <script> includes is the only solution, unfortunately. 

Will the new version of javascript support packages (namespaces), classes, creation of bundled components (js + html markups) etc. That's what I'm more interested in.

JS as of now makes it tricky to organize code neatly. Not saying it isn't possible, its just quite a bit harder to do so than Java, Python, Scala or even client side Flex (mxml / as).

- Sri

There are a rich set of libraries available to help with that in the browser, such as Dojo or YUI3 - YUI3 in particular is putting a fair bit of effort into ensuring that developers have good infrastructure for clean code structure.

[Srirangan]

Ah.. new things for me to learn.. ;-)

[Joe Developer]

But wouldn't it be better then to open the door for writing 'close to the metal' languages rather than compile-to-js? Especially if people are going to be using compile to JS no matter what changes come with Harmony?

[Joe Developer]

On Mon, Sep 12, 2011 at 12:58 AM, Srirangan <srir...@gmail.com> wrote:

I think the problem isn't syntax's and semantics. One's personal preference can be for coffeescript or javascript. I like a bit of both.

Code gets ugly when there is a lot of code in a single file and the code base isn't properly organized in "packages" and classes. And this can happen with both coffeescript and javascript.

Node.js solves this problem for server side JS but not for client side JS. Multiple <script> includes is the only solution, unfortunately. 

Will the new version of javascript support packages (namespaces), classes, creation of bundled components (js + html markups) etc. That's what I'm more interested in.

Bundled js + html markup is quite easy to do as it is, as simple as sending <script> + <markup> as a request response, though I prefer to load markup templates separately.

[Mark Hahn]

> ... if people are going to be using compile to JS no matter what changes come with Harmony?

I am an avid coffescript user as you can tell from my posts here.  I would drop coffeescript and go to pure harmony if it had half the features of coffeescript.  There is a definite advantage to using a real standard and not having a compile phase.  Of course that can't happen until harmony is supported on all browsers.

[Ricardo Tomasi]

Aren't you thinking too much about it? Just try it for once and see
how it goes.

Personally I find CS to be much more enjoyable to write, and it makes
for more readable and structured code. The extra features (loops and
comprehensions, range literals, destructuring assignments, existential
operator) are well worth the (small) learning curve.

> > functions likehttps://github.com/creationix/conductor

[Joshua Kehn]

Language “features” will be the death of JavaScript. CoffeeScript has a very nice syntax sugar, but it is only sugar. Not magical optimizations that produce better code.

People who complain about the time it takes to type `function` are probably in the wrong profession.

Regards,

-Josh
____________________________________
Joshua Kehn | @joshkehn
http://joshuakehn.com

[R. Mark Volkmann]

Don't forget that the strong typing enthusiasts say that about you. If you can't take the time to enter types for all your variables, parameters and functions ...

---

R. Mark Volkmann
Object Computing, Inc.

[Joshua Kehn]

I might be one of the few people who loved Java for forcing me to specify the types on all my variables. I don't think that has a place in JavaScript's dynamic world, but it sure wouldn't be a very bad thing.

Regards,

-Josh
____________________________________
Joshua Kehn | @joshkehn
http://joshuakehn.com

[Isaac Schlueter]

Regarding CoffeeScript and Harmony changes, I have only an emphatic "meh".

The syntax of the language is not the biggest obstacle to writing good
programs. Let's solve the hard problems first.

[Justin]

I think Mark is probably right: we probably can't reach consensus. But
I can't help but add my thoughts.

I'm right in the middle of this argument. (At least right at this
minute. I find myself on either side of it at various times.)

My primary argument for CoffeeScript is that it is generally more
concise and readable than its JavaScript counterpart. I know this is
subjective, but once I've indented a map, it's hard to argue that the
commas are doing anything for readability. Having everything be an
expression makes a lot of one-liners possible without resorting to
semicolons. It's a lot easier to do a presentation for fellow
developers when I can jam more code on a single slide. (Decreasing the
font size is not an alternative.) I can imagine making fairly elegant
DSLs in CoffeeScript given the lack of noise. Note that I do think a
lot of CoffeeScript supporters are not playing fair in their version
of this argument. I don't write JavaScript like CoffeeScript
generates. I use libraries like underscore to compress my JavaScript
code. But I can't use a JavaScript library to fundamentally alter the
syntax. (As much as some people hate that idea, I personally wish we
could.)

I have two main arguments against CoffeeScript:

The first argument is that it fractures the community. (See this
discussion as an example.) Sure, libraries fracture the community as
well. (See JSGI vs Connect as an example.) But, syntax is an
especially strong division. I already had to worry about finding
node.js developers. Now, I've got to find node.js developers that also
happen to know CoffeeScript. Or I have to train them, and I already
have enough other training to worry about. I have to expect my
developers to sometimes look at JavaScript code (such as in the
node.js docs) and then translate it into CoffeeScript. As others have
pointed out, a lot of energy is being spent on this that could
otherwise be used elsewhere.

The second argument is that it is no longer trivial to debug
CoffeeScript. Please don't tell me to unit test my code. That's not
really solving the problem. Please don't tell me to look at the code
that CoffeeScript generates. That's also not really a solution. Please
don't tell me that someone is working on a solution for this. If it
doesn't exist right now, it's impacting my current work.

I guess after having written this, I feel myself pragmatically pulled
a little bit more towards just using JavaScript. But, I'm still open
to other arguments. I'm especially interested in hearing more about
David's message-passing changes.

[Nick]

As someone who deals with the entire spectrum of typing (Javascript,
Groovy++, Java), I've found Groovy's "use a type if you want to, it's
probably better that way" to be the most effective way to keep a
complex chunk of code readable.

I would be a much happier coder if I could apply type information to a
complex or performance-sensitive algorithm. Not only would I gain the
advantages of fail-fast, typed code is way easier for an interpreter
to optimize.

I, personally, would also welcome the proposed "class" spec in Harmony
(http://wiki.ecmascript.org/doku.php?id=harmony:classes). It's
basically coffeescript-style sugar for what you can already do with
the language. The concept of a class is a powerful one, and
javascript's constructor-prototype mechanism can be used in some very
novel ways.



On Sep 11, 8:59 pm, "R. Mark Volkmann" <r.mark.volkm...@gmail.com>
wrote:

> Don't forget that the strong typing enthusiasts say that about you. If you can't take the time to enter types for all your variables, parameters and functions ...
>
> ---
> R. Mark Volkmann
> Object Computing, Inc.
>

[tjholowaychuk]

noobs will be noobs, syntax is not the problem with js, at all.

[Nick]

If syntax is irrelevant, we should all be writing in assembly. ;)

Syntax provides a level of abstraction that can unlock powerful
concepts that would otherwise be mired in unnecessary complexity. You
can do something that's functionally equivalent to object-oriented
programming in ANSI C, but you'll spend so much time writing in a
contrived box that you'll never see why you should *want* to use OOP.

Good syntax also allows programmers to manage the complexity of large
projects; it makes code easier to reason about, test, instrument, and
refactor. Currently, refactoring javascript is a class-A nightmare;
it's usually easier to write functional tests, then junk whole swaths
of the application and start from scratch. This is less true of typed
(or partially-typed) languages, and far less true of languages with
syntax around building large applications (such as packages, modules,
or enforced namespaces).

[Isaac Schlueter]

On Mon, Sep 12, 2011 at 08:32, Nick <nhu...@gmail.com> wrote:
> If syntax is irrelevant, we should all be writing in assembly. ;)

Ugh. Can we stop with this tired old reductio ad absurdem about
writing in assembly?

The difference between assembly and C, or between C and JavaScript, is
not simply one of syntax, but of semantics. The tokens *mean
different things*, and there is an order of magnitude difference in
expressiveness at each level.

When a compiled-to-JS lets you write the same program with 10% as many
tokens, I'll be impressed. So far, however, all high-level languages
are roughly equivalent in terms of expressiveness, so it doesn't make
much sense (in my opinion) to get overly excited about one over
another. JS is what we've got, it's entrenched enough to be a part of
the stack pretty much forever (like C), so it pays to know it well.

CoffeeScript is not an order of magnitude more expressive than JS.
It's cute, and people like it, and that's cool. It's an interesting
science experiment and testbed for future Harmony features. But it's
not a leap.

I predict that our grandchildren and great-grandchildren will still
recognize the JavaScript language we write, because it will still be
around. JavaScript is going with humanity out into the stars.

[Rasmus Wikman]

On 12 sep 2011, at 19.15, Isaac Schlueter wrote:

> I predict that our grandchildren and great-grandchildren will still
> recognize the JavaScript language we write, because it will still be
> around. JavaScript is going with humanity out into the stars.

Ah, you almost brought a tear of joy to my eye. Thank you!

http://en.wikipedia.org/wiki/Where_no_man_has_gone_before

[Nick]

Apologies, I was responding to a snark with a snark, hence the winking
smilie; Declaring that the problem with javascript is the users of the
language is at least as reductive, and somewhat insulting. It's a bit
like blaming the user for the bad user interface.

My point, which I elaborated on in the following paragraphs, is that
syntax *is* relevant, and that it has a huge impact on the kinds and
quality of the programs we might write, and how we maintain those
programs in perpetuity. I think you're right that we're going to have
JS forever--if only by virtue of its insane reach. It's also a
language that requires a lot of bootstrapping to get to a comfortable
coding environment; if some of that work can be folded into the
language, I think JS will be a much stronger, easier-to-maintain
language in the next few decades.


On Sep 12, 12:15 pm, Isaac Schlueter <i...@izs.me> wrote:

[Nick]

Also, I would never board any spacebound vehicle with primary system
software written in javascript. What an acutely terrifying idea.

[Elijah Insua]

> Also, I would never board any spacebound vehicle with primary system
> software written in javascript. What an acutely terrifying idea.

Surely there are advantages... for instance, who the hell knows what is going to happen on your journey; having a hackable system, to some extent, would allow you to change stuff while in flight. Seems like a _much_ better option than trying to flash a chip buried somewhere deep in the bowels of your craft or just straight up dying.

node in space, yes please.

-- Elijah

[Joshua Holbrook]

> node in space, yes please.

Anyone wanna make a node.js-enabled cubesat?
(http://en.wikipedia.org/wiki/CubeSat) You know it would be awesome.

--Josh

[Joshua Holbrook]

> Also, I would never board any spacebound vehicle with primary system
> software written in javascript. What an acutely terrifying idea.

I did some research, and I found that the Language of Choice at NASA
for probes is HAL/S:

http://en.wikipedia.org/wiki/HAL/S

THIS looks terrifying. XD I'd prefer javascript for the less
mission-critical hackable parts anyway. Maybe Ada/ravenscar would be a
good fit for the mission-critical systems.

--Josh

[Mark Hahn]

 > I use libraries like underscore to compress my JavaScript code.

I also use underscore heavily with CS to get a double bonus.

I think many people who have not tried coffeescript think it is only sugar.  Soaks and comprehensions go way beyond sugar.

[Mikeal Rogers]

comprehensions in coffeescript are the very definition of sugar.

i think you're having a hard time understanding peoples opinion about all this.

node.js is trying to solve a problem. it's an important problem. 

how do we quickly build fast, scalable, highly concurrent, applications and debug them effectively. 

that's the problem.

the language is not our problem. syntax is not our problem.

people wanna use something that compiles to javascript, fine, that's their problem. we don't consider the language or syntax a problem. if you do, go ahead and take on the extra effort of using a different language and a javascript compile target.

one thing you can say of node.js is that it's focused. we wouldn't be iterating this quickly if we took on your syntax problem, we owe it to ourselves and the community to simply not care about it.

mostly the same goes for Harmony. there are some things we *need* (binary, weak refs) and some stuff that we'd love to have (lexical scoping) but the rest of it we're unlikely to use simply because it would be a distraction from the problem we're actually trying to solve. when you hear about Harmony features being added to solve "problems" we have ("callback soup" for instance) they aren't solving our problems, they are trying to add a feature to the language they like that in their opinion is a superficial issue they have with some node.js code they saw once. 

we are solving our problems, everything else is just noise.

-Mikeal

[Dean Landolt]

No, soaks and comprehensions are the very essence of sugar. Coffeescript is, by definition, pure cane sugar, and this is intentional. Features are rejected if they venture too far outside of a strait source-to-source mapping (see the `defer` feature: https://github.com/jashkenas/coffee-script/issues/241).

[Dean Landolt]

On Mon, Sep 12, 2011 at 3:58 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:

comprehensions in coffeescript are the very definition of sugar.

i think you're having a hard time understanding peoples opinion about all this.

node.js is trying to solve a problem. it's an important problem. 

how do we quickly build fast, scalable, highly concurrent, applications and debug them effectively. 

that's the problem.

the language is not our problem. syntax is not our problem.

people wanna use something that compiles to javascript, fine, that's their problem. we don't consider the language or syntax a problem. if you do, go ahead and take on the extra effort of using a different language and a javascript compile target.

one thing you can say of node.js is that it's focused. we wouldn't be iterating this quickly if we took on your syntax problem, we owe it to ourselves and the community to simply not care about it.

mostly the same goes for Harmony. there are some things we *need* (binary, weak refs) and some stuff that we'd love to have (lexical scoping) but the rest of it we're unlikely to use simply because it would be a distraction from the problem we're actually trying to solve. when you hear about Harmony features being added to solve "problems" we have ("callback soup" for instance) they aren't solving our problems, they are trying to add a feature to the language they like that in their opinion is a superficial issue they have with some node.js code they saw once. 

Meh. AFAICT you can only be referring to generators, and they're being added to the language because they're an orthogonal primitive with a number of use cases -- a construct proven by years of prior art (in an assortment of languages), and one that cannot be otherwise accomplished without a source transform step. Yes, they open the door to some novel alternative event loop approaches, but to say this is the only reason they're being added to the language is myopic at best.

Apologies if I'm a broken record on this point, but it drives me nuts to continue seeing generators characterized this way. I don't care if node-core uses them, but dammit, I want to use them -- they solve some interesting problems that have little if anything to do with control flow. So forgive me if I selfishly continue to try and correct this myth...

But yeah, +1 to everything else Mikeal said :)

[Marco Rogers]

Other people are kind of slamming you on this. But I want to hear more explanation. What's your definition of sugar? When does a particular construct "go beyond" sugar? In my mind if you can take a construct and create the exact same semantics with more code in the same language, it is sugar. I think that's the definition lots of people have. This is a little different because CS is technically another language. But it's semantically equivalent to a subset of javascript so it still fits for the most part.

I've been a CS hater in the past. Now I' more mellow and just like to needle people about it. But what I keep trying to get out of CS users is why do you feel that it's "better" than plan javascript? Most people who argue for it are careful to mention in passing that it's "just personal preference". But that's not how you come across at all. You seem to think the rest of us are a bunch of saps because we don't like significant whitespace, prefer punctuation like braces and semis or feel like higher LOC is not synonymous with lower readability. Yes javascript has lots of warts and yes CS papers over a lot of them nicely. But not in that I want. It trades one set of annoyances for another. That's a fact. The only debate is how much you care about this new set of annoyances vs. the old ones.

:Marco

[Mikeal Rogers]

If you want to use them, fine, but know that generators won't be how we solve data flow in node-core, we use Streams. Because 1) they exist already and 2) pipe() can propagate back pressure messages and errors.

That means that if you write an abstraction that *pushes data* with generators you're break back pressure and errors. You might not care, most frameworks break this already anyway, but it's something to keep in mind.

Now, there are plenty of things that aren't pushing data from one file descriptor to another that you may want to use generators for and there isn't a good reason in node.js not to.

Again, i don't object to the feature so much as the idea that it's "for us", which it isn't because it won't actually solve the problem they claim it will in node.js, we have a solution, it's called a Stream :)

-Mikeal

But yeah, +1 to everything else Mikeal said :)

we are solving our problems, everything else is just noise. 

[Marco Rogers]

Man I really gotta start proof-reading more.

"Yes javascript has lots of warts and yes CS papers over a lot of them nicely. But not in the way that I want."

[Mark Hahn]

> You seem to think the rest of us are a bunch of saps 

Of course not.  I consider myself below average compared to this lot.  I am trying to be an evangelist.  I must not be a very good one.  

I evangelize for a selfish reason.  The more people use CoffeeScript, the better it is supported.

[Joe Developer]

Why / How do you need it to be supported better? 

The problem that I have is not with the existence of coffee-script, but with the risk of deleterious ( opinion ) changes to the existing JS which I personally have no major beef with.

[Mark Hahn]

> Why / How do you need it to be supported better? 

Not having to pre-compile would be a great improvement.  There are also advantages of something being a de-facto standard like jQuery.

> The problem that I have is not with the existence of coffee-script, but with the risk of deleterious ( opinion ) changes

Every change to a language has people for and against the changes.  That is a fact of life.  I would be for the proposed coffeescript changes and you would be against them.

[Mikeal Rogers]

On Sep 12, 2011, at September 12, 20112:42 PM, Mark Hahn wrote:

> > Why / How do you need it to be supported better?
>
> Not having to pre-compile would be a great improvement.

this is exactly what we won't do.

again, syntax is *not* our problem.

caring about your issues with js syntax and your need for coffeescript would be a distraction from the real problems we're actually trying to solve.

you need to become comfortable with us being indifferent if you continue to use coffeescript.

if you have an issue related to coffeescript/node.js integration, it's on *you* to do something about it on your end. just like it's on *us* to make node.js debugging better and is *not* the responsibility of some third part like ECMA.

we're taking responsibility for our problems, and we're focused on them, which means saying "no" to all kinds of things that aren't our problem, like syntax.

-Mikeal

[Mark Hahn]

> again, syntax is *not* our problem.

I assume by *our* you mean Node?  I would never suggest that.  Node will always stick with standard javascript.

I meant Javascript itself.  If harmony adopted parts of Coffeescript and then that was adopted by ecma, then I would not have to live with pre-compiling any more.  It would not be coffeescript any more but that is ok with me.  I would happily switch back to standard JS if it included many coffeescript features.

I know I am not going to personally affect ecma's decisions.  But every little bit helps.

[Joe Developer]

On Tue, Sep 13, 2011 at 4:42 AM, Mark Hahn <ma...@boutiquing.com> wrote:

> Why / How do you need it to be supported better? 

Not having to pre-compile would be a great improvement.  There are also advantages of something being a de-facto standard like jQuery.

The relative advantage of standards depends on the quality of the standard, I find your example of jQuery to be a deeply unfortunate one for that reason. The reason that people with limited or low quality exposure to 'app scale' development in JS cry out for changes to the languages is because they haven't been using frameworks which support the kinds of activities that they sought to do. To my mind the popularity of jQuery has done more harm to the webdev community than the lack of any language feature that JS may have. 

  

> The problem that I have is not with the existence of coffee-script, but with the risk of deleterious ( opinion ) changes

Every change to a language has people for and against the changes.  That is a fact of life.  I would be for the proposed coffeescript changes and you would be against them.

This is why I would prefer pushing for full Bytecode standardization where Coffee-script, Erlang-script and EcmaScript etc could be equal peers, then you wouldn't feel compelled to piss in my soup. 

[Mark Hahn]

> To my mind the popularity of jQuery has done more harm to the webdev community

I love jQuery and it has saved me man-years of coding. It is no surprise that you dislike CS if you dislike jQuery.  You obviously don't mind typing long lines of code with functions like getElementById.

> I would prefer pushing for full Bytecode standardization

I would love that if it meant Coffeescript could get on an equal footing with JS.  I would still be arguing in the threads though when people object to seeing sample code in CS instead of JS.

There is no discussion of bytecode in harmony or ecma, is there?  It is a cool idea.

[Joe Developer]

On Tue, Sep 13, 2011 at 5:07 AM, Mark Hahn <ma...@boutiquing.com> wrote:

> To my mind the popularity of jQuery has done more harm to the webdev community

I love jQuery and it has saved me man-years of coding. It is no surprise that you dislike CS if you dislike jQuery.  You obviously don't mind typing long lines of code with functions like getElementById.

Of course I do, but I have clue enough to do var gbid = document.getElementById;

 

> I would prefer pushing for full Bytecode standardization

I would love that if it meant Coffeescript could get on an equal footing with JS.  I would still be arguing in the threads though when people object to seeing sample code in CS instead of JS.

There is no discussion of bytecode in harmony or ecma, is there?  It is a cool idea.

I agree that it has some intriguing potental. 

[Mikeal Rogers]

On Sep 12, 2011, at September 12, 20112:59 PM, Joe Developer wrote:

On Tue, Sep 13, 2011 at 4:42 AM, Mark Hahn <ma...@boutiquing.com> wrote:

> Why / How do you need it to be supported better? 

Not having to pre-compile would be a great improvement.  There are also advantages of something being a de-facto standard like jQuery.

The relative advantage of standards depends on the quality of the standard, I find your example of jQuery to be a deeply unfortunate one for that reason. The reason that people with limited or low quality exposure to 'app scale' development in JS cry out for changes to the languages is because they haven't been using frameworks which support the kinds of activities that they sought to do. To my mind the popularity of jQuery has done more harm to the webdev community than the lack of any language feature that JS may have. 

i would put that in different terms.

there were a collection of frameworks that tried to solve *many* problems (dojo, yui, etc). they solved some of those problems better than others, but at the end of the day they created large incompatible stacks. if you used dojo, you wrote everything in dojo. you couldn't use somebodies yui code without taking their whole stack with it.

jquery did not do this. jquery picked one problem (DOM) and solved it well. it was focused, and it won.

jquery is compatible with the rest of the world of javascript because it's only solving one problem, that's great. 

we can learn a lot from that.

sure, javascript still has problems that dojo or yui might have solved but that's not jquery's fault.

  

> The problem that I have is not with the existence of coffee-script, but with the risk of deleterious ( opinion ) changes

Every change to a language has people for and against the changes.  That is a fact of life.  I would be for the proposed coffeescript changes and you would be against them.

This is why I would prefer pushing for full Bytecode standardization where Coffee-script, Erlang-script and EcmaScript etc could be equal peers, then you wouldn't feel compelled to piss in my soup. 

there are lots of es-discuss threads about why bytecode standardization isn't going to happen.

[Dean Landolt]

On Mon, Sep 12, 2011 at 4:28 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:

On Sep 12, 2011, at September 12, 20111:19 PM, Dean Landolt wrote:

On Mon, Sep 12, 2011 at 3:58 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:

comprehensions in coffeescript are the very definition of sugar.

i think you're having a hard time understanding peoples opinion about all this.

node.js is trying to solve a problem. it's an important problem. 

how do we quickly build fast, scalable, highly concurrent, applications and debug them effectively. 

that's the problem.

the language is not our problem. syntax is not our problem.

people wanna use something that compiles to javascript, fine, that's their problem. we don't consider the language or syntax a problem. if you do, go ahead and take on the extra effort of using a different language and a javascript compile target.

one thing you can say of node.js is that it's focused. we wouldn't be iterating this quickly if we took on your syntax problem, we owe it to ourselves and the community to simply not care about it.

mostly the same goes for Harmony. there are some things we *need* (binary, weak refs) and some stuff that we'd love to have (lexical scoping) but the rest of it we're unlikely to use simply because it would be a distraction from the problem we're actually trying to solve. when you hear about Harmony features being added to solve "problems" we have ("callback soup" for instance) they aren't solving our problems, they are trying to add a feature to the language they like that in their opinion is a superficial issue they have with some node.js code they saw once. 

Meh. AFAICT you can only be referring to generators, and they're being added to the language because they're an orthogonal primitive with a number of use cases -- a construct proven by years of prior art (in an assortment of languages), and one that cannot be otherwise accomplished without a source transform step. Yes, they open the door to some novel alternative event loop approaches, but to say this is the only reason they're being added to the language is myopic at best.

Apologies if I'm a broken record on this point, but it drives me nuts to continue seeing generators characterized this way. I don't care if node-core uses them, but dammit, I want to use them -- they solve some interesting problems that have little if anything to do with control flow. So forgive me if I selfishly continue to try and correct this myth...

If you want to use them, fine, but know that generators won't be how we solve data flow in node-core, we use Streams. Because 1) they exist already and 2) pipe() can propagate back pressure messages and errors.

That means that if you write an abstraction that *pushes data* with generators you're break back pressure and errors. You might not care, most frameworks break this already anyway, but it's something to keep in mind.

Oh, no doubt. I'm not advocating at all for node to use anything but streams :)

Just to clarify, if you're trying to use a generator as a stream replacement, back-pressure will be the least of your concerns. For starters your stream will be blocking -- AFAIK there's no way for a generator alone to both yield values and control flow, so you'd need an additional construct (something like a Task as it exists in Dave Herman's task.js lib). Given it's weightier than even promises there's way this would fly in node core :D

 

Now, there are plenty of things that aren't pushing data from one file descriptor to another that you may want to use generators for and there isn't a good reason in node.js not to.

 

Absolutely. That's all I wanted to point out. Thanks Mikeal.

 

Again, i don't object to the feature so much as the idea that it's "for us", which it isn't because it won't actually solve the problem they claim it will in node.js, we have a solution, it's called a Stream :)

Amen.

[colinta]

I know this "to coffee script, or not to coffee script" debate will
rage whether I pontificate or not, but I'd like to toss another ball
into the court, see if anyone picks it up.

If we were programming in python, when we weren't patting our backs
about Just How Great python is at Everything (i kid, but really, it is
pretty *dang* great), we would never, in anyone's wildest dreams,
entertain the idea of placing *another* language syntax ON TOP OF
PYTHON.

The python community wouldn't even argue about it, it would guffaw at
the idea, many would assume you were joking. You wouldn't even be
remembered as "that guy", the thread would just die a quick and
painless death.

I think there is a similar sentiment among those javascript developers
who feel comfortable and totally at-home working in javascript. Why,
for the love of all that is holy, would you put something IN THE WAY
of writing Javascript?

But python, thankfully, is NOT javascript. It already has things like
array comprehensions, multiple inheritance, library standardization/
consistency, and so on. A lot of people who code in javascript come
from that happy, bouncy, fluffy, wonderful world and think "Dang, i
sure would like to have array comprehensions. they're nifty wow!"
and then they find coffee script and are oh-so-happy. Maybe they use
it, maybe not, they are *definitely* happy to hear about Harmony (and
personally, i'm REALLY glad he's keeping the braces. but I'm a coffee-
with-half-and-half kinda guy)

There're the two sides of the fence, as I see it.

On the one side, people who already think Javascript is great, or at
least good enough to not mess with. On the other are those who learn
javascript and see holes of functionality big enough to drive the .NET
framework through (now there's a ZING we can all agree with, am I
right folks!?)

Here's one last caveat, something people can disagree with me about:
if the *creator of javascript* is publicly blogging about javascript's
deficiencies, and dreaming of a Harmony that in many ways resembles
coffee script, I think that we owe it to him to nod and show some
modicum of humility. Because maybe... probably... he knows what he's
talking about.

[Mikeal Rogers]

I too spent a lot of time with Python.

Python's problem is syntax, that's the problem they want to solve. They are, probably, more obsessed than any community on the planet on matters of syntax.

They broke the language to make print a function rather than a statement.

JavaScript is in the rare position of broadly winning. It's in *all* the browsers. That makes it a very attractive compile target for people who think syntax is their problem to solve and don't like JavaScript's.

That's never going to change. JavaScript will continue to be an attractive compile target so people will continue to treat it as such.

Just wait until there is a good lisp to js compiler :) Everyone who used to program lisp wishes they still did :)

We are node.js, we don't care about syntax, we only barely care about the language. We must remain indifferent to the people who use us as a compile target.

Their experience being good or bad is on them to solve, not us.

It's the only way we'll stay focused enough to succeed.

Python being as obsessed as it is with syntax and not with, say, concurrency, or performance, is one of the reasons I, and many other, have had to leave. It a pretty language, I can't deny it, but it simply fails at building the applications I want to build.

-Mikeal

[Dean Landolt]

On Mon, Sep 12, 2011 at 7:50 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:

I too spent a lot of time with Python.

Python's problem is syntax, that's the problem they want to solve. They are, probably, more obsessed than any community on the planet on matters of syntax.

They broke the language to make print a function rather than a statement.

JavaScript is in the rare position of broadly winning. It's in *all* the browsers. That makes it a very attractive compile target for people who think syntax is their problem to solve and don't like JavaScript's.

That's never going to change. JavaScript will continue to be an attractive compile target so people will continue to treat it as such.

Just wait until there is a good lisp to js compiler :) Everyone who used to program lisp wishes they still did :)

We are node.js, we don't care about syntax, we only barely care about the language. We must remain indifferent to the people who use us as a compile target.

Their experience being good or bad is on them to solve, not us.

Well put. I'd carve out one small but important exception: there are some edges around using node as a compile target that are node's domain to solve -- particularly around hooking require. Node already provides decent facilities but there are gaps. I don't have a specific proposal yet but I'd love to see more thinkin' done around this some time before something half-baked gets baked into 1.0.

[Isaac Schlueter]

On Mon, Sep 12, 2011 at 17:22, Dean Landolt <de...@deanlandolt.com> wrote:
> Well put. I'd carve out one small but important exception: there are some
> edges around using node as a compile target that are node's domain to solve
> -- particularly around hooking require. Node already provides decent
> facilities but there are gaps. I don't have a specific proposal yet but I'd
> love to see more thinkin' done around this some time before something
> half-baked gets baked into 1.0.

I can't speak for the rest of the node-core team, but it's on my
radar, at least.

This is definitely something we need to think about carefully. It's
better to do something right that we'll be happy about in years to
come, rather than something that'll make people happy today.

[Ricardo Tomasi]

> Of course I do, but I have clue enough to do var gbid =
> document.getElementById;

That doesn't actually work, since you lose the call context. It should
be a function:

gbid = function(id){ return document.getElementById(id) }

Which, by coincidence, is exactly what jQuery and similar frameworks
provide. I think you just proved Mark's point here.

[Ricardo Tomasi]

If you'll allow me, I'll refrain (as I did before) from discussing
typing, or fitness for one profession or another.

I wouldn't call them "magical", but they do produce better code, in my
opinion. Repetitively writing nested for loops and chains of
conditionals is what doesn't make my code any better.

There's no need to get defensive, we don't bite. It's just javascript.

On Sep 11, 9:50 pm, Joshua Kehn <j...@kehn.us> wrote:
> Language “features” will be the death of JavaScript. CoffeeScript has a very nice syntax sugar, but it is only sugar. Not magical optimizations that produce better code.
>
> People who complain about the time it takes to type `function` are probably in the wrong profession.
>
> Regards,
>
> -Josh
> ____________________________________
> Joshua Kehn | @joshkehnhttp://joshuakehn.com
>
> On Sep 11, 2011, at 8:41 PM, Ricardo Tomasi wrote:
>
>
>
>
>
>
>
> > Aren't you thinking too much about it? Just try it for once and see
> > how it goes.
>
> > Personally I find CS to be much more enjoyable to write, and it makes
> > for more readable and structured code. The extra features (loops and
> > comprehensions, range literals, destructuring assignments, existential
> > operator) are well worth the (small) learning curve.
>
> > On Sep 11, 12:49 am, Joe Developer <joe.d.develo...@gmail.com> wrote:
> >> What strikes me as odd about -> and also what I noted from Newspeak ( see
> >> thread about google's Dart ) where they use ^ for "return" is how
> >> non-ergonomic they are on QWERTY keyboards, I certainly don't believe that
> >> they are significantly faster to type for touch typists but they do force a
> >> wider range of movement than their traditional counterparts.
>
> >> Ultimately I find it hard to believe that the savings in characters by
> >> themselves is a significant productivity factor, seriously. Lets pretend you
> >> write 'function' 100 times in a day, hell, lets say 500 - further, lets
> >> assume that it takes you 1 second to type 'function' while only 0.5 second
> >> to type -> that is a whopping 4 minutes of time saved over an 8 hour day.
> >> Even if -> was magically instant and somehow not an invitation to forearm
> >> tendonitis, this still only saves you 8 minutes of your '1 function per
> >> minute, every minute' day.
>
> >> I also hear that there are might be text editors which support something
> >> called macros or expandTriggers or search and replace - pretty wild stuff
> >> there.
>
> >> In terms of reading code I am also somewhat doubtful - the biggest cost with
> >> reading code strikes me as stemming from ambiguity, where you need to rescan
> >> and consciously participate in the parsing.
>
> >> The overall cost can be reduced with bits of grammar such as { scope
> >> signifiers } and statement delimiters;
>
> >> Overall though, I would imagine that the issue is with re-training more than
> >> anything - I would be surprised if the majority of people who seem
> >> challenged by { scope signifiers } and semi-colons are not simply used to
> >> different conventions from languages that they have spent more time with.
> >> There is an increasing number of people who likely got one of their early
> >> rushes from Rails, this is somewhat exacerbated by the fact that Rails is
> >> slow as limp dying dog and many outfits are looking to offset that by
> >> technologies like Node.js and being smarter about their front-end code.
>
> >> It is the 'un-familiar' which forces context shifts between reading
> >> 'characters' and meaning.
>
> >> As for deep nesting, that seems entirely optional to me - if you don't like
> >> it, stop.
> >> Just because you *can* define inline functions doesn't mean that you *have
> >> to*, if you really need stuff in a surrounding closure then write code that
> >> expressly passes or binds it.
>
> >> On Sun, Sep 11, 2011 at 8:57 AM, Loot <andrew.luetg...@gmail.com> wrote:
> >>> What make you of the first argument that the intent of -> is
> >>> productivity which is a false premis and that -> can be obtuse
> >>> visually making scanning code more work.
>
> >>> Also the problem with callback soup is not the function keyword but
> >>> the multiple levels of nesting. Eich hase specific suggests for this
> >>> but the community has also addressed it with async controll flow
> >>> functions likehttps://github.com/creationix/conductor

[Joe Developer]

I think you have helped prove mine, that an over reliance on abstractions can leave you ignorant of the underlying and alternative possibilities. I haven't had occasion to map getElementById manually for years. 

[Yoandy Rodriguez]

Hello:
I'm not much of a JS developer, actually coming from a Java and Python
background JS has always looked a bit odd to me. On the other hand
Coffee provides a certain level of abstraction I as a newbie find very
useful, currently I'm learning how to use jQuery with CS and in the way
I'm actually learning JS for the first time. So if anything I can say is
that CS is in my experience a great tool for beginners.
BTW abstraction is **not** a bad idea, and it **doesn't** turn you into
a lazy programmer, if you don't believe me ask any C# developer how they
feel about LINQ.

[Nicolas Chambrier]

I think learning a language starting with his abstract alternatives is the worst idea ever. ORMs should be used only when you know SQL very well, as CS should be learnt when you already master JavaScript, and jQuery only if you made DOM yours...

I hope I'm wrong but honestly I'm afraid it's bad advice for beginners...

[Mark Hahn]

> I think learning a language starting with his abstract alternatives is the worst idea ever.

I disagree totally. I have no idea how to use the dom directly from Javascript and my jQuery code is excellent (just ask me).  I learned using jQuery from the beginning.

All of coding is abstraction.  You have to pick some level of abstraction to use.  You don't have to always know the lower levels.  By induction you would have to know all the turtles all the way down.

[Yoandy Rodriguez]

I partially agree with you. I work as a Introduction to Programming
professor at the UCI (that's Universidad de las Ciencias Informáticas,
Cuba, not to be confuse with University of California,Irvine) so it's my
job to teach basic algorithms and data structures to people that know
little or nothing about programming. But I also believe that once you
know your way with programming languages you can skip a few steps when
learning a new one.

[Marco Rogers]

All of coding is abstraction.  You have to pick some level of abstraction to use.  You don't have to always know the lower levels.  By induction you would have to know all the turtles all the way down.

Do you really believe this last statement, or can you just not help trotting out this argument? Please stop.

I had written a really snarky reply to this. Then I caught myself and realized, it's late and I'm irritated about something else. Let's not be patronizing.

:Marco

[Dave Clements]

On Sep 13, 7:23 am, Mark Hahn <m...@boutiquing.com> wrote:
> > I think learning a language starting with his abstract alternatives is the
>
> worst idea ever.
>

> I disagree totally. I have no idea how to use the dom directly from
> Javascript and my jQuery code is excellent (just ask me).  I learned using
> jQuery from the beginning.

yeah, jquery basically drew me into javascript, I knew some before but
found it irritating especially for the dom. now, in node I'm currently
coding without jquery, but jquery was what gave me a better
understanding and got me interested in the inner workings.

[Bruno Jouhier]

Catching up, a bit late...

I see Javascript as some kind of modern assembly language (a really
cool one compared to traditional assembly languages). Some people are
using it directly to deal with the metal (the node core team) and JS,
even with its known deficiencies, does the job well for them. Other
people are using preprocessors (Coffeescript, CPS transforms, DSLs)
because they deal with higher level stuff and they want a lighter
syntax, less noise, etc. And they seem pretty happy with their fate
too (even if everything is not perfect, the debugging experience for
example).

I think that this is perfectly fine and that we should try to keep
Javascript this way.

There is a push to introduce lots of bells and whistles (higher level,
friendlier syntaxes) into the language, (borrowing ideas from
CoffeeScript). I don't like this because what I like most about JS is
its simplicity (already too hairy to my taste because of redundant
features).

So I'd be very selective when it comes to new features and only go
with things that make it a more efficient and practical "modern
assembly language" (things that are really hard, if not impossible, to
implement efficiently outside of the language).

My short list:

* a decimal type (top priority - emulation is not a long term solution
for 'decimal-intensive' apps)
* a yield operator (to make pseudo-synchronous DSLs easier to
implement and more efficient).
* anything that improves the situation with immutability.
* features to support tools that compile to JS. For example, a markup
to inject source file names and line number information that would be
recognized by debuggers would be a nice first step.

I'm all for new languages (like Coffeescript), but I don't want their
features to get dragged into Javascript unless they are really
essential. We need to make it easier for people to build compilers and
debuggers that target JS, not try to turn JS into a bloated, do-it-all
language. Same thing for node.js: keep it small and focused. Core
technologies should only be catalysts for creative solutions, they
should not try to swallow them.

My 2 cents.

Bruno

On Sep 11, 2:44 am, Loot <andrew.luetg...@gmail.com> wrote:
> I'm a little concerned about the direction of Harmony, the next
> version of JS. Brendan Eich keeps pushing for things that are very
> CoffeeScripty which is great if you like CoffeScript. But I code in
> JavaScript because I like JavaScript :-) I wont get into it here but I
> am in the process of laying out a few arguments in my developing blog
> post about it over athttp://www.andrewluetgers.com/2011/09/07/coffescript-fanboyism-rampant/
> Please comment here or on that post.
>
> or
>
> if not that please, PLEASE make your feelings known to anyone who will
> listen especially anyone on the ECMA Script committee. I don't care
> what you feel about it but the ECMA Script committee needs to hear
> from and be driven by actual developers not just speakers and language
> designers.
>
> Here is Brendan's blog, I would highly recommend everyone here read it
> and comment on it.http://brendaneich.com/
>
> we need to be aware of these proposals and have direct input into the
> process, not just blindly accept whatever if handed to us.

[Mikeal Rogers]

if you want to get features in to the next version of the language, or you take issue with the direction the next version is taking, you should direct your feedback to https://mail.mozilla.org/listinfo/es-discuss

this list is not where we design the JavaScript language :)

[Bruno Jouhier]

If you go this way this whole thread is off topic and it should have
been redirected earlier!

On 14 sep, 20:48, Mikeal Rogers <mikeal.rog...@gmail.com> wrote:
> if you want to get features in to the next version of the language, or you take issue with the direction the next version is taking, you should direct your feedback tohttps://mail.mozilla.org/listinfo/es-discuss

[Mikeal Rogers]

i don't think so, the thread has mostly been about how node people feel about languages that use javascript as a compile target and what the support looks like in node.

there has also been a lot of discussion about what features in the language we might use in node. we have, mostly, stayed away from critiquing or asking for features directly in the next version of ECMAScript.

my comment wasn't intended to be "get this off the list!", it was more of an encouragement to get people who feel strongly about the language to start putting some of this where people designing the language will actually see it, es-discuss. i'm on there, isaacs is on there sometimes, but for the most part the opinions of node.js people, and people heavily *using* the language in general, is underrepresented.

-Mikeal

[Bruno Jouhier]

Ok. I was more on the post that started all this. I'll follow up on es-
discuss.

Bruno