Live data from Hacker News

For modern development Javascript indeed is a shit language

live.julik.nl

121–130 of 243 posts

Re: For modern development Javascript indeed is a shit language

#121
post #17

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…

I like JavaScript, and I don't really know what was wrong with Visual Basic either.

Re: For modern development Javascript indeed is a shit language

#122

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…

> ... 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…

> If your function call doesn't match the signature

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

#123
post #65

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…

ActionScript!

Re: For modern development Javascript indeed is a shit language

#124
post #68

Earlier 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…

Well as masklinn says this is a standard library function; the bad design is a property of that API and not inherent to the type system. It does perhaps reflect the 'philosophy' of Javascript, as evidenced by all the people in this thread defending this awful behaviour. Take the example of Io, which has a lot of similarities to JS but has stronger typing and syntax that I hope is fairly self explanatory:

  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

#125
post #76
post #17

Earlier 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…

> Why is this a problem? Most web problems don't need a large code base. A small, dynamic language is suited to web problems.

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

#126

Earlier 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

Every single one of these compile to the JavaScript runtime.

(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…

> yield is shallow, caller must be ready to cope with yielding explicitly

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

#128

Despite 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…

This is how I learned Angular and CS, by writing the todo apps in CS...after a bit, it was much easier to think and reprocess the concepts in my head as coffee script, especially when it came to test writing. I think the must-have for me is te bevy of ways to do auto compilation these days

Re: For modern development Javascript indeed is a shit language

#129
post #26

As 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.

>But on other side I see JS bytecode as great alternative to Java and JVM.

Exactly how is javascript a better byte code than JVM byte code?

Re: For modern development Javascript indeed is a shit language

#130

Earlier 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 :--)

Or you're saying that you know so little about it you don't know of its real problems.
Post reply on HN