Ok show me another language which has near native performance, gradual typing (thinking TypeScript here), and lets me do lightweight functional and lightweight OO programming.
> has near native performance what do you mean by this? https://github.com/niklas-heer/speed-comparison https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Douglas Crockford on JavaScript
21–30 of 202 posts
Re: Douglas Crockford on JavaScript
#22Re: Douglas Crockford on JavaScript
#23Ok show me another language which has near native performance, gradual typing (thinking TypeScript here), and lets me do lightweight functional and lightweight OO programming.
And its poor concurrency story compared to other languages e.g. Scala means that it's hard to push the runtime in real-world situations.
Re: Douglas Crockford on JavaScript
#24Ok show me another language which has near native performance, gradual typing (thinking TypeScript here), and lets me do lightweight functional and lightweight OO programming.
Typescript is very nice, just need to get rid of the javascript underneath.
and that's why it should never happen.
Re: Douglas Crockford on JavaScript
#25> "[...] we are crushing ourselves with the accumulated complexity we’ve piled on top of bad foundations [...]" The same could be said about plain HTML/CSS though. I think the author is correct overall and I don't really see improvement on the horizon. WebAssembly, while great that it exists, can morph browsers into some poor mans virtual operating system and this can lead to a less open web. We already see more clos…
> The same could be said about plain HTML/CSS though. Genuine question: How much of the complexity of working with HTML/CSS is unnecessary and how much is inherent to the problem they solve? Is it as bad as with Javascript? I would say that we, for the most part, have a very clear idea of how we could (theoretically) replace Javascript with something much better. I don't know of alternative layout languages, so I don…
Re: Douglas Crockford on JavaScript
#26Earlier quoted context omitted.
I forgot to add "not controlled by a single corporation" to my list of requirements. Also not gradually typed, I think? But I would consider it if it weren't all tied into Google and had a larger ecosystem.
Isn't Typescript "controlled" by Microsoft?
Re: Douglas Crockford on JavaScript
#27Pretty much sums up everything :(
Re: Douglas Crockford on JavaScript
#28Wouldn't it be nice if we could start over and apply all the lessons we've learned over the generations? The world would be a much better place!
Or would it?
We'd end up with yet another mess. It'll be a different mess but it'll be a mess nonetheless. Or worse - we'll end up with two big messes instead of one big mess!
Re: Douglas Crockford on JavaScript
#29[flagged]
Very much. :) We have a javascript interpreter parked at the L2 Lagrange point.[1] As far as the preservation of human made artefacts go that is basically one of the safest places it can be. When us and all of our earthly possessions have long crumbled to dust that thing is still going to be out there. (Albeit very likely drifting without power around the sun.)
1: Event-driven James Webb Space Telescope Operations - https://arc.aiaa.org/doi/pdf/10.2514/6.2006-5747
Re: Douglas Crockford on JavaScript
#30Earlier quoted context omitted.
> has near native performance what do you mean by this? https://github.com/niklas-heer/speed-comparison https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Much faster than Python or almost any non-native-compiled language (except Java)
And there are a number of languages on the JVM e.g. Java, Scala, Kotlin, Clojure as well as countless compiled ones which are near-native.