61–70 of 94 posts
Earlier quoted context omitted.
Because it's kind-of a mish-mash, and syntactic elements imported from other languages (I know) tend to behave differently in subtle ways, usually making them worse or weird. Also having a single token change so much meaning (fat vs thin arrow) feels icky and hard to read/notice.
You've obviously never used CoffeeScript.
CoffeeScript is popular and there is Dart. Instead of using another language and translate to JavaScript, what are the hindrances to improve JavaScript so that the "bad parts" are removed? Maybe a 'half-clean' break from existing javaScript? Sorry for my ignorance.
Work has not stopped, but it's basically about cat-herding, and each player does his own additions. As an example, Mozilla has kept working on core Javascript with "internal" versions:
1.6 added Array Extras and String and Array generics (array extras have since then been adopted by everybody else) as well as E4X (literal XML syntax in JS) and a `for each` loop.
1.7 added generators and iterators, array comprehensions (listcomps), let definitions, statements and expressions and destructuring assignments
1.8 added a function shorthand (function (foo) { return bar; } => function (foo) bar), generator comprehensions (lazy listcomps) and two missing array extras (left and right folds)
1.8.1 and 1.8.5 mostly added ES5 and draft APIs (e.g. the Object.* stuff and the Proxy type)
CoffeeScript is popular and there is Dart. Instead of using another language and translate to JavaScript, what are the hindrances to improve JavaScript so that the "bad parts" are removed? Maybe a 'half-clean' break from existing javaScript? Sorry for my ignorance.
Earlier quoted context omitted.
That's a fair perspective, although what you call a "mish-mash" I'd call borrowing the best syntax for every feature :) The syntax came out of a community effort over the course of many months, and a lot of thought went into the decisions that were made. (And of course it's still under development!) Since you mentioned the => operator in particular, I'll defend it briefly-- it's a feature JavaScript sorely needs, and…
> Since you mentioned the => operator in particular, I'll defend it briefly-- it's a feature JavaScript sorely needs, and in the situations where it's useful it's a godsend, turning a pile of ugly JS into a single operator. Oh I understand the need for it, my issue is not with the fat arrow in and of itself, but in the fat arrow and the thin arrow. > It does seem like a small difference, but do you mix up == and -= m…
You can say that, but in practice it doesn't really happen. They look somewhat different, they do somewhat different things. It's programming, ya know?
Not that I'm trying to make you like it or anything-- of course you have the right to your own aesthetic sensibility.
Earlier quoted context omitted.
>> I doubt that the creators of ruby did not put any thought into this, and I'd be interested in their justification. I don't know what Matz's thinking was, but it may just be that Ruby owes a great deal to Perl. Interpolation in double-quoted strings is present in Perl (and used constantly).
I think the bad part of string interpolation is that it encourages to use it constantly, in place, instead of extracting it to method. Gluing strings together is the weak point of application, and should be hard to do, to encourage people to wrap it in functions, that can also validate input, escape what needs to be escaped, etc. Maybe that's my "discipline and bodage" part talking :)
Having said that, my first language was Perl, and I'm still a fan of TMTOWTDI and making common things easy.
Earlier quoted context omitted.
Because it is badly designed? Or because it is too different from js?
Because it's kind-of a mish-mash, and syntactic elements imported from other languages (I know) tend to behave differently in subtle ways, usually making them worse or weird. Also having a single token change so much meaning (fat vs thin arrow) feels icky and hard to read/notice.
Earlier quoted context omitted.
Because it is badly designed? Or because it is too different from js?
Because it's kind-of a mish-mash, and syntactic elements imported from other languages (I know) tend to behave differently in subtle ways, usually making them worse or weird. Also having a single token change so much meaning (fat vs thin arrow) feels icky and hard to read/notice.
Earlier quoted context omitted.
I think it would be slightly more consistent to re-use the multi-line quite like Python does: var foo = /* Hello there How are you? */; But less typing is good too.
So does that string literal include the spaces between "/ * [space]" and "Hello", and "you?" and "[space] * /", or not? By the fact that you included spaces in your example, does that imply it doesn't include the surrounding spaces in the string? Maybe your example implies that spaces are not included, but maybe they are or maybe they aren't, since comments don't require them, but usually have them and look ugly with…