151–160 of 243 posts
Foul English is far, far worse in my eyes at least than JavaScript.
Earlier quoted context omitted.
> this looks like a really broken implementation over weak typing No dammit, javascript does not coerce numbers to strings when comparing them, a "weak typing" implementation would behave exactly as he wants. > What OP was probably annoyed by was the typical excuse the JS community offers for this behaviour: "it's weakly-typed so you can treat the arguments as anything you want". That makes OP fractally wrong instead…
> No dammit, javascript does not coerce numbers to strings when comparing them, a "weak typing" implementation would behave exactly as he wants. Please note that I wrote it's a broken implementation over weak typing, not of weak typing. The typing system is fine, at least as far as this matter is concerned, but the standard library is badly applied over it.
But weak typing is a complete red herring, as I noted previously the behaviour of the default sort function is independent from the typing system, you could have a default sort function doing more or less the same thing in a very strict statically typed system.
Haskell's `sort` is defined (more or less) as
sort :: Ord a => [a] -> [a]
sort = sortBy compare
sort :: Show a => [a] -> [a]
sort = sortBy (comparing show)
Earlier quoted context omitted.
Safari/Chrome: SyntaxError: Unexpected token '>' Firefox: SyntaxError: syntax error In a discussion about Javascript maybe it would be a good idea to give examples of Javascipt that actually run in a Javascript console?
Firefox Nightly [1,10,5,-15,-2,4].sort ((a, b) => a-b).toString(); "-15,-2,1,4,5,10"
> They are not solvable by making a new ECMA spec. As it turns out, many of the issues outlined are not only very much solvable by making a new ECMA spec but either already solved in ES5 or solved in ES6. > JS has callable attributes > This is a shitty design decision I strongly recommend not following the provided link, which is basically inane, uses the term "slots" in a rather disturbing manner and makes completel…
ES6 has not been finished yet as far as I know.
It sucks, but it's not quite as bad as the impression you get from "ES6 isn't done."
Earlier quoted context omitted.
CoffeeScript was obviously inspired by Ruby. While CS is great, I've never gotten over the usage of "->" or "=>" to signify a function. To me, Ruby's "def" or "do" reads so much better. Especially with "end", to signify a barrier, as opposed to whitespace. Have you considered porting Ruby directly to JavaScript? By the way, thanks for your work on _ & Backbone!
> Have you considered porting Ruby directly to JavaScript? No. It's been attempted before, and it doesn't turn out to be terribly useful in the end, because of the vast semantic mismatch between the two languages. See: https://github.com/jashkenas/coffee-script/wiki/List-of-lang... > I've never gotten over the usage of "->" or "=>" to signify a function. Give it a try, perhaps. It's critical not to use "def" and "do"…
[1] http://www.nczonline.net/blog/2013/09/10/understanding-ecmas...
I have always wondered why so many people like dynamically types languages... I mean, if I have a variable I ALWAYS know what kind of data I expect in it. If I try to use different kinds of data in the same variable then something is clearly wrong - either with me (for wanting that) or with the way I use the variable (and I would appreciate some warning about it). The problem is that you hardly have a choice nowadays…
The reason alot of people like dynamicly typed languages is that they don't have to babysit the compiler. Small example, in JS, if you have a function that works on a "age" property of an object, it doesn't matter what kind of object you send in, as long as it has an "age" property. You can do this easily in staticly typed languages as well, but you have to write more code (generics, class/struct-definitions, interfa…
Shouldn't you just pass the 'age' property then?
Earlier quoted context omitted.
The "syntax" of promises in JS and Dart isn't really a syntax. They are library features in the form of fluent method chaining. This is merely a library pattern, it is not a syntax. A syntax would be something like the async/await support in C#. Or the async and let!, do! etc along with pipelines in F#.
Are there any compile-to-JavaScript languages out there, which do this? I read about function* and yield, but this seems to require all functions to be rewritten. Also I don't quite understand how this accomplishes to run 2 functions in parallel, if they are async.
Saltarelle - C# to JS compiler:
http://www.saltarelle-compiler.com/documentation/supported-c...
Funscript:
Earlier quoted context omitted.
Silencing an error like that is catastrophic. Silencing an error would be a problem, but in JS, it's not an error , because there's no concept of "wrong numbers of function arguments" built into the language. That's not to say you can't inspect the number of arguments yourself and throw an error, if some situation warrants it. But you don't have to do this. It's a very flexible, dynamic language. In some ways this fl…
It's still a programmer error when they accidentally call a function with 2 arguments when they meant to call it with 3. The fact that the language can't inform them of the error doesn't change that.
Earlier quoted context omitted.
Do you mean lexical scope? Scheme has it and it is awesome. If you think it is not a good feature you should grab a SICP and see the magical stuff you can do with it.
He is asking what other sane language does not have lexical scope, as that was listed as one of JavaScript's advantages.
Earlier quoted context omitted.
> I've been playing around with it a bit... Tell us more!
I'm afraid that there's not much to show yet, apart from some little prototype scribblings, and the basic idea: The web that we build for today is a rich, almost entirely backwards-compatible stew of nearly two decades of browser development and standards work, resulting in a triumvirate of very different languages that need to come together in order to make a web application happen: HTML + CSS + JS. Two of them are…
You can accomplish this pretty effectively with a clojure/clojurescript stack, though it takes some work to get going and isn't perfectly seamless. Code-as-data seems really well suited to unifying the declarative and procedural.
Personally, I love the ideas behind clojure, but I prefer the experience of writing coffeescript to clojurescript. I think it would be very cool to see you combine your penchant for pragmatism and nimble syntax with the solid engineering principles of functional languages.