Javascript's type system really doesn't stand up well to scrutiny. That's more crucial than you'd think - the type system is the foundation the rest of the language is built upon.
I suspect this is partly why javascript cycles through technologies so often. The foundations are shaky.
Small wonder, then, that the Node.js ecosystem tends to very good at iterating quickly and testing out many alternative approaches to solving a problem, and pretty bad at communicating invariants to other programmers or providing a stable API for other programs to build off. You tend to get what you ask for.
If you're about to say one of SmallTalk/Lisp/Python/Ruby, then no, they are good at prototyping but have all the pitfalls of Javascript when used on large teams. If you're about to say one of Java/Go, then no, you give up a lot of prototyping flexibility for their explicitness.
No, they absolutely don't.
>>> "1" + 1
Javascript: 11
Perl: 2
This is the kind of approach works ok for small programs. Where the code that does these implicit type casts isn't too buried.
When it's buried 3 layers down in a dependency used by a dependency used by a dependency, you want this to happen instead:
Python/Ruby: Type error
It does nothing to communicate invariants or guide API usage at design-time.
Consider PHP, which does have some of those bizarre and frustrating conversions, yet at the same time it also has stuff like type-hints and interfaces that can be used for design-time checking.
Literally what this entire thread is all about.
Lots of languages have this issue and it manifests in the instability and indeterminacy of large scale applications in Perl and PHP much as it does in javascript.
Type hinting is, honestly, a pretty poor way of dealing with the problem of turning "1" + 1 into 2, but that's a separate issue.
No it isn't, that's just what you've been fixated on. Please re-read nostrademons' post, because you aren't actually addressing the issues they brought up, namely:
> It's dynamic typing with a prototype-based object model. This type system [...] tends to be pretty bad at communicating invariants to other programmers or nailing down APIs for other subsystems to build off.
While it's true that Python "fails nicer" than JS, it addresses neither of those two issues about preventing failures.
I find that the big benefit of types are in documentation. They are executable, explicit, compiler-checked documentation of the programmer's intended usage. Without this, it becomes much harder to read through and comprehend a large codebase that was mostly written by other people. It becomes even harder to change it.
I like Python, I like Javascript - but they have their uses, and those uses don't include large-scale mature software engineering. I actually argued otherwise for my first couple years at Google (where both are used extensively, though the JS is largely statically typed), but eventually saw the wisdom of more experienced engineers in this, and relegated my Python to exploratory coding.
I guess companies should stop using Java for big enterprise applications with tons of dependencies. Or this isn't a problem because programmers usually know the basics of the language they are using. And if they don't, then that is the problem, not the language.
btw, Python: '1' * 3 -> '111'
But that's not really the point, crdoconnor seems to think that languages should throw an error in cases like this, not just keep the type of the first argument.
Main.java:17: error: incompatible types: String cannot be converted to int
int z = x + y;
In theory I agree with this but in practise I see this so rarely used it barely matters.
see here: https://repl.it/Cqeq/0
What concrete examples were you thinking of? (You didn't mention any strongly-typed-dynamic languages in your replies to the others.)
JS has unfortunate implicit type coercions, bad scoping rules (not type system related but still crappy), and annoying tri-value silliness (NaNning all over).
I'm a big fan of prototype OO. JS not so much.
Javascript cycles through technologies quickly because web developers cycle through technologies quickly, and they do that because they get to work on greenfield projects with minimal expectation for them to be around in 5 years a lot. Check out all the different server side frameworks and infrastructure components that have been in vogue with web developers over the last decade.
In comparison, people who aren't writing consumer-facing websites and webapps tend to have much more clearly-defined goals, longer lifespans of their apps, and don't often get the choice to use anything but industry standard technology. Because of the slower cycle, there's less opportunity to redesign frameworks and core technologies even when it's allowed.
There's plenty more nonsense where that came from. That's just an easy to understand, concrete and obviously stupid example.
>Check out all the different server side frameworks and infrastructure components that have been in vogue with web developers over the last decade.
In python it's mainly been django and flask for a decade. In Ruby it's mainly been Rails.
Why do they have sticking power? It's partly cultural but it's largely because they were built on far more stable foundations.
In deployment, we've gone from SFTP scripts to Fabric-like software to PaaS to configuration management software to Docker, and then it seems every 6 months there's a different preferred way to make Docker do something useful. And of course there's the eternal argument over whether to deploy to VPSes, cloud platforms, or bare-metal hardware.
The "hip" web companies at any given moment - the ones who need the latest and greatest components to impress investors and attract "rockstar" "10x" developers - aren't tied to any specific language. They'll pick whatever was the most popular at the time they needed to pick something. Hence, right now, you have a whole lot of companies building on Golang and node.js, where they'd've been building on RoR five years ago.
> with Babel you can use TypeScript
To clarify, I'm certainly not implying this person is an idiot. I'm saying, they lean toward thinking that the typing system is more of a bad idea (idiocy) than a valid tradeoff.
I don't think typescript is necessarily the answer though. You don't fix the problems caused by weak implicit type casts with static typing, you do it by turning off weak implicit type casting and raising a lot more type errors.