Personally, I disagree. I find JavaScript to be the most "write-able" language, and switching to Node + frontend JS as my main language (I've done Python, Ruby, PHP, Java and C++ as jobs) has been the best thing I've done in a long time. Express and Angular are amazing. Sure, it has a bunch of quirks. Sure, it's not good for everything (I do mostly relatively simple CRUD apps). Sure, in the browser, it gets slow when…
I see this all the time. JS is slow because of the dom. No. JS is slow because JS is slow. Yes, I know V8 makes it faster than it used to be. Yes I know it is neck and neck for computation, but because of the way memory is handled it is slow for loading large dictionaries. But I could forgive all of that. JavaScript is not well designed for work in a team environment, nor is it well designed for Large Code Bases. But…
For modern development Javascript indeed is a shit language
121–130 of 243 posts
Re: For modern development Javascript indeed is a shit language
#122Earlier 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…
> ... in other ways it necessitates more manual checking (or slower debugging). There's no catastrophe, just design differences. See, there's the problem. Glossing over issues by explaining them away as "design differences". Nothing about an expressive language necessitates making life hard for the programmer. If your function call doesn't match the signature then it is very likely to be in error, and instead of fail…
Depending on what constitutes function signature. I agree with “design difference” argument. Someone has to make design decisions, even if someone else doesn't agree with them.
Re: For modern development Javascript indeed is a shit language
#123Earlier 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…
Re: For modern development Javascript indeed is a shit language
#124Earlier quoted context omitted.
> The correct answer is it has to do with weak types. No, it does not. You could define the exact same default function in Java, Haskell (requiring that the sorted type be a Show instance) or Python (hell, getting the exact same behavior in Python could hardly be simpler: `ar.sort(key=str)`. There, I broke it. That is near literally how the ECMAScript spec very explicitly defines the default comparison function. The…
> No, it does not. You could define the exact same default function in Java, Haskell (requiring that the sorted type be a Show instance) or Python (hell, getting the exact same behavior in Python could hardly be simpler: `ar.sort(key=str)` I don't use JavaScript but to me this looks like a really broken implementation over weak typing. Of course, this isn't a trait of the typing system per se as it is a trait of the…
list(-3, 4, 10, 6, 1, 2) sort
==> list(-3, 1, 2, 4, 6, 10)
And to show that you can implement the Javascript behaviour in a language without implicit type conversions: list(-3, 4, 10, 6, 1, 2) map(asString) sort
==> list(-3, 1, 10, 2, 4, 6)
Javascript merely defines the standard sort function to be the latter.One difference between Io and Javascript is that
"10" > 2
throws an exception in Io (argument 0 to method '>' must be a Sequence, not a 'Number') so you can't sort a list that is a mixture of strings and numbers without explicitly converting them first (or using a custom comparator), since the standard sort function won't convert things for you (how would it know what you wanted to convert them to?). However that code is valid in Javascript, and actually returns 'true'. So the amusing thing here is that the > operator in Javascript actually does what you want (converts to numbers rather than strings) and if you sort with a custom comparator using the greater than operator then I presume it would give the correct result for an array of numbers. Something like this (disclaimer I'm not a Javascript developer, following code may be wrong): [7, -3, 6, 10, 1].sort(function(a, b){return a > b ? 1 : -1;});
[-3, 1, 6, 7, 10]
For whatever bizarre reason the standard sort function is defined to convert to strings first.Re: For modern development Javascript indeed is a shit language
#125Earlier quoted context omitted.
I see this all the time. JS is slow because of the dom. No. JS is slow because JS is slow. Yes, I know V8 makes it faster than it used to be. Yes I know it is neck and neck for computation, but because of the way memory is handled it is slow for loading large dictionaries. But I could forgive all of that. JavaScript is not well designed for work in a team environment, nor is it well designed for Large Code Bases. But…
> JS is slow because JS is slow. JS is the fastest dynamic language next to SBCL's Common Lisp implementation. > JavaScript is not well designed for work in a team environment, nor is it well designed for Large Code Bases. Why is this a problem? Most web problems don't need a large code base. A small, dynamic language is suited to web problems. And judging by the amount of things being built with Javascript, enough p…
This is demonstrably false the second you start to use JS on the backend. Just because most of the problems you've seen require only tiny codebases does not mean that they all do.
Re: For modern development Javascript indeed is a shit language
#126Earlier quoted context omitted.
What are other runtime options? - Flash? That's almost the same as JavaScript and it's getting obsolete. - Java? No one enables it on the client, thanks to security problems. - Asm.js/LLVM? These are immature and can't be used for production.
- GWT - Dart - ClojureScript
(Dart has a native VM in Chromium, but AFAIK it is a long way off from the real world)
Re: For modern development Javascript indeed is a shit language
#127> 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…
> All runtimes but MSIE (unless they've added it in IE11) already implement `const`, and it's standardized in ES6. const implemented currently is very weird thing. It's more or less a read only variable, which silently ignores updates var i = 0; for (var j = 0; j This is not something one would expect of constants honestly. > You mean, something like ES6's yield? yield is shallow, caller must be ready to cope with yi…
TFA invokes C#'s `await` which is also cooperative and "shallow". Granted in C# there are APIs available for a synchronous function to "block on" an asynchronous one, but aside from that it's equivalent (the limitations are those of the underlying platforms, core.async loses the same features when doing from Clojure/JVM to ClojureScript/JS).
> so it's not really a good replacement to proper coroutines that can pause arbitrary deep stacks.
I agree, but I foremost went with the examples of "doing it better" which TFA provided, and TFA used `await` (if he'd used gevent or Erlang, I'd have been hosed)
Re: For modern development Javascript indeed is a shit language
#128Despite 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, rea…
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 ev…
Re: For modern development Javascript indeed is a shit language
#129As someone who maintains old 1000+ KLOC projects I have to agree. Have look at some large old Perl projects to see how JS code will look&feel in 10 years. But on other side I see JS bytecode as great alternative to Java and JVM. Modern languages usually include JS as compilation back-end.
Exactly how is javascript a better byte code than JVM byte code?
Re: For modern development Javascript indeed is a shit language
#130Earlier quoted context omitted.
I'm pretty sure that the parent comment's author is aware of this. It does not change the fact that it's broken.
I don't know - it's just a default general API, obviously it's not going to match everyone's use case. I would say that even relying on sort made by someone else is already not fit for many use cases. If such a petty and trivial "problem" is what you have against Javascript, then you are basically saying it's a good language :--)