Live data from Hacker News

For modern development Javascript indeed is a shit language

live.julik.nl

201–210 of 243 posts

Re: For modern development Javascript indeed is a shit language

#201
post #7

Earlier quoted context omitted.

How do you handle Javascript ignoring wrong numbers of function arguments? Do you use a linter to catch this sort of thing? This part of Javascript sounds the most absolutely insane to me: Silencing an error like that is catastrophic.

It's just never been a problem for me, I guess? I know how it works in JS, so I either ignore it or use it to my advantage (the JS equivalent of overloading). You seem to come from a more strongly-typed background, but I've never once found the way JS handles it to be "catastrophic".

How do you ignore it? Ignoring it means accepting cryptic bugs that result from signature changes.

You say "use to your advantage", but what's the advantage? You could have a "*args" like Python, and get the benefits without the (huge) drawback.

The typing debate is mostly about how much effort we should exert to catch errors at compile time rather than run time. In JS, it is much worse: It defers error catching forever, and never even catches them at all! It converts them to silent bugs, instead :(

Re: For modern development Javascript indeed is a shit language

#202
post #78
post #67

Earlier quoted context omitted.

In JS, sending the "wrong" number of arguments is frequently a feature. There's no concept of language-level function overloading, and it allows for the authorship of functions that take a variable or unbounded number of arguments (useful when coding in a functional paradigm).

That "feature" would be better with an explicit language construct such as *args or params args[], though. As with so many complaints about JavaScript, it's the default behaviour that is a problem.

I'd say it's worse than a default behavior, since there's no sane way to reverse the default. Are explicit arg list checks really an option, when you want to opt out of the default? I'd say that's not practical at all -- so it's really worse, as there's no practical opt out of this.

Re: For modern development Javascript indeed is a shit language

#203
post #180

Earlier quoted context omitted.

> Why not just avoid making this mistake in the first place by reading the code? We're talking about programming errors . Are you suggesting the solution to human error is to just not make errors?? Note, of course, that wrong arguments will frequently not arise from a function call you just wrote -- but from changes in the code. Say you merge in a trivial merge of some code, which changed a function's signature/param…

> We're talking about programming errors. Are you suggesting the solution to human error is to just not make errors?? Not at all, I'm simply suggesting that people take care to acknowledge and operate within the rules of the language. If you're making changes to a function signature in JS without assessing the impact for code elsewhere, then you're doing a bad job - and that's all there is to it. JS allows you to do…

> If you're making changes to a function signature in JS without assessing the impact for code elsewhere, then you're doing a bad job - and that's all there is to it.

Given that other people are working on the same code base and may have added calls to this function, this is not even possible.

Also, dynamic languages all require you to fix calls to changed functions. But at least, when you test that code, it won't accidentally seem to work when it is broken.

Also, humans cannot do a perfect job every time. We will all make mistakes, and our tools shouldn't give us hell over those mistakes for miniscule to no benefit at all as in this case.

Out of thousands of changes to function signatures, do you think none would ever forget to fix a caller?

> So JS has a (potentially) higher maintenance cost

This doesn't sound potential at all. It sounds like you either lose a huge amount of reliability, or add a huge burden to development.

> it's just a trade-off

What do you gain here? You save an asterisk in the syntax when you want to overload?

> This is just a case for good documentation and release notes. Don't merge in changes that you don't understand.

In a collaborative environment, we merge work with each other every single day. Do you have documentation and release notes for every commit you publish? Do you go and check the commit's release notes every time you pull?

Re: For modern development Javascript indeed is a shit language

#204

Earlier quoted context omitted.

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

Yet somehow it works just fine out of the box in plenty of other languages, including Python, Erlang, Clojure, Ruby, etc.

Yeah, plus it's not just thing one thing, but there is a good amount of seemingly little things like this that add up.

Re: For modern development Javascript indeed is a shit language

#206
post #126

Earlier quoted context omitted.

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)

Right and ClojureScript, for example, has full goroutines in it (i.e. core.async) if doing standard callback based async in JS isn't your thing. Functionally, it makes little to no difference whether you're writing something that compiles down to JS or writing something that compiles down to its own runtime (assuming you turn source maps on your browser).

That doesn't change the fact they use the JavaScript runtime, which was the question the parent was trying to address.

Re: For modern development Javascript indeed is a shit language

#208
post #150
post #111

Earlier quoted context omitted.

I have always wondered why so many people like dynamically types languages Because you don't have to write a lot of boilerplate to tell the language things that it should be able to figure out for itself. I mean, if I have a variable I ALWAYS know what kind of data I expect in it. But that data might not always be of the same type. For example, in Python, I might want a variable to hold strings but also None, so that…

> Because you don't have to write a lot of boilerplate to tell the language things that it should be able to figure out for itself. This is exactly my point; compiler can't figure out what kind of data I want, at least not in general. A good example is jQuery $.data() which tries to guess what kind of data you have in your HTML tag attribute. Guess what happens if you have a MongoDB ObjectId (as string), for instance…

Guess what happens if you have a MongoDB ObjectId (as string)

But that's a matter of semantics, not static typing. You're going to have to do type conversion on the string regardless, because "MongoDB Objectid" isn't a native type for the compiler. But with static typing, you need to tell the compiler the type of the variable in addition to telling it how to do the type conversion: for example, in C++, you might have to say...

    var MongoObjectid id = new MongoObjectid("somestring");
..whereas in Python, for example, you could just say...

    id = MongoObjectid("somestring")

Re: For modern development Javascript indeed is a shit language

#210
post #158

Earlier quoted context omitted.

So do some error checks. The first unit test I write for any function is that it handles arguments correctly.

But you do see why people are complaining, right? You are having to manually write thousands of tests to check something that is trivial for a compiler to check.

This is just an absurd complaint, it's a dynamic language, if you want compiler forced type checking, use a static language. Dynamic languages are not broken because they don't behave like static languages.
Post reply on HN