4 ms·

I can't speak to the trend, but it's worth considering where these "Javascript people" came from. For example, I'm currently a Javascript dev. I learned rudim

I can't speak to the trend, but it's worth considering where these "Javascript people" came from. For example, I'm currently a Javascript dev. I learned rudimentary C, C++, Pascal, and a couple of Assembly languages in high school/college, but quickly got into Perl (and the Web) for my job. After several years of developing in Perl I learned Java to show the execs looking to do "enterprise" development that I was a team player. I hated Java, and when the chance came to switch, it was going to be either Python or Javascript, and Javascript was something I had picked up some experience with, so it was the first one to get me hired. I'd consider my experience to be fairly familiar to most full-stack or backend developers. In contrast, I run into a lot of frontend developers that came from the opposite direction: HTML, then CSS, then Javascript. Their relationship to different languages and how it can be useful to their skillset is completely different from mine. If they are uninterested in learning any other language, it's likely because: * They have no experience to say it will be useful to them, since they are planning to continue to develop in Javascript for the foreseeable future. * The other "languages" they know (HTML & CSS) are NOT helpful in their JS skillset. So by extension, they have experience teaching them that learning other "languages" isn't helpful. I'd be skeptical too if someone that didn't code in my language of choice was saying that I should expend effort when my experience says otherwise: it sounds too much like an ivory tower someone speaking pompously. Now, in my case, I DO know other languages and I know how they can benefit me. (Even language experiences I hated, such as my 5 years as a Java dev, were certainly instructional and useful in my current practices). But that's BECAUSE of my experiences, not DESPITE them. So I can see how someone with a different experience would respond differently. (Heck, I tend to look down on all strict-typing languages because of my Java experience, despite hearing from others that Java is not a great example to learn from).

brian-armstrong 10y ago
I hope you can get past your aversion to nicer type systems. As someone who has watched things break in production too many times, the math is very clear to me that a little time spent pleasing the type system saves MUCH more time that would have been spent debugging something in production that a simple compilation pass would have caught.
- ergothus 10y ago
  I don't recall single a production bug in my code caused by a type issue (excluding null/undefined cases, where typing is rarely helpful), whereas I've lost countless hours to teaching a compiler what it should already know. (And I have plenty of bugs, they just tend to be logical rather than type based). That said, I also try to use a lot of unit tests, so there HAVE been more than a few pre-prod issues having to do with types. I just view the time spent on these as still less than what a strictly-typed language would require. Fixing the 1 in a 100 situation that is quickly exposed in a test is less effort than being verbose 100 times. I will admit that there are some test cases that typing would make much easier - but not enough to yet sway me. I'll also say that strong typing (ala Python) is far less painful to me than static typing (ala Java). I'll try to keep an open mind, but until I start seeing production bugs that make it worth more development pain, it's unlikely to occur. * I'll also note that I think my web experience makes me prefer coercion, because everything has to keep switch to/from strings. Though I'm sure the strict-typing crowd will see that as evidence that typing has all the more need to be enforced :)
  - sa1 10y ago
    Dealing with null and undefined cases is a significant practical advantage of a modern type-system. Compilers can catch most of them. Also you can encode your logic in types - The Curry-Howard Correspondence (https://en.wikipedia.org/wiki/Curry–Howard_correspondence https://en.wikipedia.org/wiki/Curry–Howard_correspondence) says this is always possible in sufficiently advanced type-systems. While this goal hasn't been realized in mainstream programming languages, we have been moving towards it for a long time. So when you say that you only have logical errors, not type errors and can't recall any type issues, do keep in mind that those are exactly the kind of things type-systems aim to solve. But I can't blame you since Java and similar languages provide the only mainstream experience of static types.

brian-armstrong 10y ago

I hope you can get past your aversion to nicer type systems. As someone who has watched things break in production too many times, the math is very clear to me that a little time spent pleasing the type system saves MUCH more time that would have been spent debugging something in production that a simple compilation pass would have caught.

ergothus 10y ago
I don't recall single a production bug in my code caused by a type issue (excluding null/undefined cases, where typing is rarely helpful), whereas I've lost countless hours to teaching a compiler what it should already know. (And I have plenty of bugs, they just tend to be logical rather than type based). That said, I also try to use a lot of unit tests, so there HAVE been more than a few pre-prod issues having to do with types. I just view the time spent on these as still less than what a strictly-typed language would require. Fixing the 1 in a 100 situation that is quickly exposed in a test is less effort than being verbose 100 times. I will admit that there are some test cases that typing would make much easier - but not enough to yet sway me. I'll also say that strong typing (ala Python) is far less painful to me than static typing (ala Java). I'll try to keep an open mind, but until I start seeing production bugs that make it worth more development pain, it's unlikely to occur. * I'll also note that I think my web experience makes me prefer coercion, because everything has to keep switch to/from strings. Though I'm sure the strict-typing crowd will see that as evidence that typing has all the more need to be enforced :)
- sa1 10y ago
  Dealing with null and undefined cases is a significant practical advantage of a modern type-system. Compilers can catch most of them. Also you can encode your logic in types - The Curry-Howard Correspondence (https://en.wikipedia.org/wiki/Curry–Howard_correspondence https://en.wikipedia.org/wiki/Curry–Howard_correspondence) says this is always possible in sufficiently advanced type-systems. While this goal hasn't been realized in mainstream programming languages, we have been moving towards it for a long time. So when you say that you only have logical errors, not type errors and can't recall any type issues, do keep in mind that those are exactly the kind of things type-systems aim to solve. But I can't blame you since Java and similar languages provide the only mainstream experience of static types.