Hacker News new | past | comments | ask | show | jobs | submit login


No matter what you're replying to, uncivil, name-calling dismissals and personal attacks are not OK on Hacker News. Please stop.


Sorry dude, I'm going to have to step in; you're being too strong in your counter attitude. I've been writing and teaching JavaScript professionally for many years, and while I don't hate the language, I don't blame those who do. After learning and using a statically typed language, it becomes absurd how much effort you have to put in to debug a JavaScript type error – a problem that is amplified by the language design.

What happens when you add 1 + undefined? Other dynamic languages make the sane choice of throwing an error immediately. JavaScript, however, silently gives you back NaN and continues chugging along. By the time a "real" error happens, you're stack traces away from the cause.

What happens when you call a function f with one argument when it expects two? Other languages would throw immediately. Instead, JavaScript silently sweeps in an undefined and continues chugging along. Combine that with the other flaw I mentioned, and your runtime error will, again, be distant from the true cause.

There's a reason TypeScript is getting insanely popular. It's the only way to code large JavaScript projects and stay sane.

(just going' down this rabbit hole with you all)

The problem I have with static typing (as widely implemented) is it solves little problems at the cost of arbitrary inflexibility which ends up rippling through a code base.

And the little problems are better solved in other ways. E.g., unit tests and the like catch type errors on the way to validating that your code actually does what you think it should do.

Static typing also isn't useful when dealing with data that moves through distributed systems. You know, like pretty much all the data. The static types you had at compile time are fundamentally not related to the data you are processing at run time and static types don't equip you to deal with that very well. Systems map "wild" incoming data to the internal static types but the static type environments strongly encourage this to happen early, which is often not the right place.

> The problem I have with static typing (as widely implemented)

Mainstream type systems are best ignored. If it doesn't have sum types, it's not a good type system. If it doesn't have generics, it's not a good type system.

More flexible static type systems can help, but they don't address the fundamental problem that they are trying to make a strong statement at development time about something that isn't known until runtime.

This pushes dealing with the problem (of what if something isn't the expected type/is malformed/is missing/is incomplete) to the wrong place, causing unnecessary complexity, dependencies and bugs.

Give me an example of a correct program you actually want to write, that a decent static type system. I do have examples of correct programs that almost no static type checker will accept, but I don't want to write those programs. For instance:

  if true then 1 else "one"
This is an expression of type int, that yields the value 1. But I don't want to write such crap, because of (i) dead code, and (ii) mismatched types between the the branches (one is an int, the other is a string).

I don't often feel constrained by static typing but perhaps we are just working on different kinds of problems.

As for distributed systems, it's true that static typing doesn't solve that on it's own, but combined with something like protobuf, it should right? Admittedly I've only recently learned of protobufs so feel free to correct me.

I hadn't heard of protobufs before now. But if I understand it correctly, I don't think it addresses (what I think is) the fundamental problem with static typing in a distributed system.

It's that the your static types that exist at development/compile time aren't really strongly related to the runtime data. Meaning, the strong guarantees that static types make aren't actually true.

Systems deal with this by recreating the relationship: they convert incoming data to instances of the static types. But you have to note, this code exists to satisfy the static type system. If you didn't have a static type system, you don't need that code: you don't have to write it, test it, maintain it, etc.

protobufs looks like one way to recreate the relationship between your runtime data and the static types. It looks pretty nice, but it has its own complexities -- another language to learn on top of anything else you're doing, another tool to install and learn with its own quirks (I notice the generated C++ code files have a .cc extension), a code generation step to integrate into your build, new versions of protobuf to be integrated to get new features). Stuff you don't need to deal with if you don't have a static type system.

But it's not just that its wasteful. It also encourages you to deal with changes to your data model early, in a generic way (because your inflexible static type system pervades the entire code base... you can't do anything with the data until you wrestle it into an instance of a static type). But that's often not the best place to do it because at that point, the system doesn't know what will be done with the data.

Not that static types don't have their place. They certainly have their uses, but I think it's in small, inner-boxes, not throughout a codebase. E.g., let's make it something you have to opt-in to on a case-by-case basis, not a pervasive assumed default. Sure, provide a mechanism for type hinting to drive helpful static code analysis, like auto-complete and refactoring tools.

Perhaps provide some kind of flexible dynamic-type/static-type bridge that helps you solve dynamic-type/static-type issues rather than encourage them. E.g., something that at run time keeps track of the difference between runtime data and the static type it is supposed to be according to the type hinting.

you are entitled to your opinion, and i appreciate that you offer it. and those are legitimate gripes. ive written it professionally for many years as well. there are alot of nice things about javascript as well, so in general i like the language. alot of what i read in the initial answer is a guy who wants to show he is a member of the cool kids club by hating on javascript. its so lame.

Try to be more charitable by seeing it from their point of view. Imagine being used to a language that helps you be rapidly productive and shields you from a huge catalog of mistakes. But one day you're forced to use JavaScript, and suddenly you've got nothing. It'd be like driving in a doorless jeep with no seatbelts on a high rise highway with no guard rails. Sure you can do what you want, and even in some nice, clever ways. But there are so many ways to hurt yourself, and no natural protections to prevent it.

To put it another way, it's like throwing a frontend developer into the world of C. Suddenly you have to be aware of and correctly manage your memory explicitly, whereas before you were safely protected from having to think about it.

Lastly, not everyone can voice their opinions so well. Communication is a difficult thing, and understanding what you're trying to communicate more so. If someone says they hate something, it's not always baseless. Instead of jumping to name-calling, have more patience in trying to understand why.

this is a good characterization of what causes people confusion, and i think the parallel with people going to c from js is totally right. i experienced that myself. its a great way to put it and i will probably use it, thanks!

the second point about being more understanding surely applies more to the person proudly hating a language with no constructive support about why, and little evidence of an effort to overcome the language's obstacles. sure, i dont know everything about this person, but i take the comment at face value, which seems to be the norm. maybe calling them out on it isnt helpful? i dont know, but it didn't seem that bad.

If the hate were towards a person, I would completely agree with you. But OP is only hating JavaScript-the-tool, so I have no contempt towards his opinion.

In contrast, if OP were hating on JavaScript programmers, then your indignation would be completely justified. But he's not, and I admit to holding a similar position: I hate C++ and prefer to never lay eyes on it again, but I have nothing against C++ programmers :) The difference between C++ and JS is C++ is less forced upon someone's career as the only language to work with.

thats a good distinction, and i suppose its defensible. but imagine you are a trumpet player, and a pianist walks by and says "i hate that non-instrument trumpet" unprovoked. no one is wrong to hate the trumpet. but saying it to a trumpet player, and then saying they aren't even a musician (implied by "non-language"), is going to catch heat.

and its undeniably true that javascript has got loads of warts. i mean, look no further than "javascript: the good parts" as perhaps the most recommended book. (i guess you already know this, but for the maybe 1 other person reading this...) but despite that, i enjoy the hell out of writing good js, and love that people can use what you make by going to web page. and w/r/t the warts, i feel that if they were corrected, my js life woulnd't change much at all. so when people point to the warts as evidence that its a bad language, all i can say is that while they are obviously bad, they dont end up mattering to me. thats clearly not true of everyone, but id bet its true alot. because of this, i find it pretty easy to spot people who are excited to hate js because they are pretty sure its a safe thing to hate and it will make them look in the know. i mean, i was guilty of this when i was younger with mysql and php.

and yes, people being "forced" to use js is surely contributing to the hate, probably the same way people hate having to use css. they look at them as afterthoughts, but its funny because in a lot of cases, its like the main thing that needs work. i just wonder why people cling to the idea that "real programming" has a certain look, when being good at js and css is super helpful and important to good web projects.

i suppose we are arguing for the same thing- basically open-mindedness and willingness to learn.

Two days after you two posted this thread of comments, and I must thank you for it.

The analogy of musical instruments may be appropriate here; I feel that my ability or failure to be productive with a particular set of tools to be an aspect of my identity.

Set me to debugging a C++ or Java class library and I can get to work, but these may not be the tools I would prefer to start with.

Am I a bad programmer? Hmm. Identity can be a fragile thing.

> its so obvious that people are just looking for reasons to hate javascript

Why would anyone have the motivation to do that? Either it has given them reasons to dislike it, or it hasn't. Why do you think anyone is predisposed to looking for those reasons?

its just a kind of hipster thing to do, to hate things. i did it with mysql and php. its like a way to show that you are cool.

Even worse though,is to have your personal identity tied up in the language you work in. If you are actually Brendan Eich, then I get you taking it personally, otherwise, who cares?

yea, i guess i shouldnt care as much.

the_cat_kittles I think you don't get the point of my answer or simply my answer was confusing, sorry for that. I did not wanted to start a big discussion here and just throw a controversial, stupid example. But it very clearly shows my main point. The point is that it is easily to write a code in Javascript that looks ok, but is not. The lack of good type system, legacy of how it was implemented on the beginning and everything connected to lack of general safety leads to this conclusion.

I disliked it myself up until ES6 when it started to be "enjoyable" or..should I say less annoying. I program in 6 languages (it may not be much but enough to draw a conclusion from a sample) and I can't say I have one without it's list of wtf's.

By placing big keywords in your bio like "Serial enterpreneur, haskeller, programming languages design freak, former senior R&D technical director in the biggest film studios in Europe" + "hates java script" and keeping your flag up here makes it look very unprofessional. Of course, who are we to judge if not...your target audience for a "functional programming language", visual or not.

I remember when RoR came out and some [1] "cool dudes" decided to mock everything else on the planet. RoR vs php, RoR vs this and that. It made me feel sick even though RoR was a big step up from everything else back then. It took me 2 - 3 years to even consider it because of that.

[1] https://www.youtube.com/watch?v=EnnpbVW7Yb8

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact