He is promoting an "actor language" to replace JavaScript. https://www.crockford.com/misty/
Douglas Crockford on JavaScript
131–140 of 202 posts
Re: Douglas Crockford on JavaScript
#132Earlier quoted context omitted.
> All of this has made the language worse. Just accreting features doesn't make the foundation less broken. I see this view a lot - what I rarely ever see is a concrete discussion about what exactly is wrong with the "foundation" of javascript. Because to me... Javascript is actually a decent-ish solution to the UI space (it nicely balances reactivity and code complexity by presenting an event driven, single threaded…
I might not have the best take since don't have a huge grudge against javascript but I definitely think there are some concrete problems in its foundations. Specifically js has very unusual attitudes to basic syntax operations that are at this stage undoable without breaking an insane amount of existing code. For some examples: - Use of == does not do what it does in almost every other language, but won't flag an err…
But none of those are actual issues with shops that are writing JS today (Literally: Zero items on that list).
> Use of == does not do what it does in almost every other language, but won't flag an error if a user thinks if does. Instead very difficult to track bugs will be introduced.
"==" does basically what it should... (I also avoid it, but it makes a perverted kind of sense for easing into programming) and the bugs introduced aren't difficult to track at all: literally find and replace "==" with "===" resolve places that became too strict, then make it a lint rule.
>Calling nonexistent object keys won't flag an error but return None. I've seen this lead to weird errors that are hard to find a lot of times.
This... is basic dictionary behavior across SO MANY LANGUAGES. Frankly - having worked with languages that make a missing key an exception (looking at you C#/C++) I'd take the JS route any day.
> - Duck typing in a lot of operators like + and - can create unexpected results.
Yes. This is programming. Have you seen Ruby (or python - or god help you custom operator implementations in c++)? Because holy fuck is JS reasonable as all get here when compared to some other popular languages.
----
> I obviously can't speak for anyone else, but I think those are the kind of things most people are referring to when they talk about js having problematic foundations.
Basically - Look: I agree JS has some warts. Literally every language does. I just really don't see those warts as deserving of FUD around foundational problems that so many people talk about.
Re: Douglas Crockford on JavaScript
#133> It used to be that we’d get new computer languages about every generation. […] And then it kind of stopped. There are still people developing languages, but nobody cares. I think this is false. We can see great interest in new languages, and I feel like languages like Rust and Go have achieved to move the ball forward significantly for backend / system software development. It's just that noone has been able to rep…
> It's just that noone has been able to replicate that kind of success [of Rust's and Go's achievements] in the web-based frontend space. While it's easy to dog on Javascript, it's also necessary to consider what Javascript does right. The main thing that comes to mind is JS' async-everything, async-by-default, and first class async abstractions (like the Promise). Not necessarily something you want all the time, but…
Async in interface by default was a mistake and led to a ton of pain. Actually-async-under-the-hood is fine.
See: how much JS is rightly and justifiably littered with "await" on seemingly almost every line, now that that's an option. It's downright comical to look at, and as clear a sign of mis-design in a language/runtime as you can get. Nine times out of ten (maybe more...) you just need to treat all that async stuff as synchronous, from the perspective of the current block of code. "Await" or something like it should have been the default behavior of async calls. A great deal of the mess in Javascript over the last couple decades has been due to going the other direction with that default.
Re: Douglas Crockford on JavaScript
#134Languages are validated by their use. All other interpretations of their value are abstractions from the only real metric, that people use it and it is alive in that way. We don’t speak dead languages and we don’t adopt them either.
Re: Douglas Crockford on JavaScript
#135He is obviously right about the stagnation but he does not seem to be connecting the dots (at least in this video) about why this is so - which in turn might inform us as to when to except some change. Languages and their tooling ecosystems express how computing is concretely embedded and used by society. People adopt the tools to get jobs and to get the job done, whatever the "job" is. In turn the available remunera…
> quirky projects of the Web 1.0 era still trusting php Disagree with the dig at PHP. PhpStorm+Psalm doesn't give you perfection, but a perfectly respectable development environment. Using PHP isn't anachronistic, these shallow dismissals are. If anyone out there hasn't seen PHP 8 and Psalm yet, it's worth a look. All languages and ecosystems have trade offs, PHP is no exception, it is a good fit for many scenarios.
While I applaud the recent-ish improvements to PHP, the biggest issue is still unresolved: the standard library is a mess. It is inconsistent as a rule -- in terms of function naming, argument order, error behaviors, etc.
I think this issue is probably intractable unless PHP wants to go the Python route and have a hard fork.
Re: Douglas Crockford on JavaScript
#136Earlier 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/...
The second you remove threading and SIMD from those examples, they get rather close to JS. At most, you are making the argument that killing JS-SIMD for WASM and not adding native threading support was a mistake.
> The second you remove threading and SIMD
Anything else?
Re: Douglas Crockford on JavaScript
#137Languages are validated by their use. All other interpretations of their value are abstractions from the only real metric, that people use it and it is alive in that way. We don’t speak dead languages and we don’t adopt them either.
[deleted]
Re: Douglas Crockford on JavaScript
#138Languages are validated by their use. All other interpretations of their value are abstractions from the only real metric, that people use it and it is alive in that way. We don’t speak dead languages and we don’t adopt them either.
By this logic, the Imperial System is the best measurement system for the US (pick whatever entrenched system you want). Whether you agree or disagree with it, it's the most widely used in US so its superiority there is self-evident.
Re: Douglas Crockford on JavaScript
#139He says that a new language used to pop up every generation -- and that seems to me like it's been the case -- Elixir, Rust, and Go all seem to have arisen during the last 15 years.
Re: Douglas Crockford on JavaScript
#140Earlier quoted context omitted.
What exactly is "broken" about the foundation of JS? I hear this all the time and people can never back it up. It is extremely performant for a scripting language, it is easy to debug, and it works in many scenarios. People try too hard to be contrarian. Same thing happened with PHP and many other languages.
Have you ever read JavaScript: The Good Parts ? It does a great job of describing lots of broken bits. More specifically, a few things that I think are pretty bad off the top of my head: - Implicit type coercion - Confusing scope binding, i.e. , `this`, `bind`, etc . - Inconsistent Array API — some methods return a new value; some methods mutate the value! [0] - `['1', '7', '11'].map(parseInt)` …lol?! Maybe you shoul…
> Maybe you shouldn't be so quick to jump to this conclusion that any criticism of your pet technology comes from a place of ignorance or pretension.
Maybe your argument just isn't that great?
I mean - look, I've worked in a LOT of languages now in the 25 years I've been writing code. Js is certainly no bastion of language perfection, but it's also sure as fuck not on shaky foundations.
Almost all of your criticism basically boil down to: JS won't break backwards compatibility for me! WAHHHHH!
Because none of your examples are really issues:
- Implicit type coercion.
happens in a lot of languages - keep a table around if you need it.
- Confusing scope binding, i.e., `this`, `bind`, etc.
this is literally core to the language - it's not any more confusing than learning about the difference between class definition vs an object instance.
- Inconsistent Array API — some methods return a new value; some methods mutate the value![0].
This is a fair complaint - but all the functions that mutate have non-mutating versions now - JS just won't break compatibility for you by removing the old ones... "WAH!")
- `['1', '7', '11'].map(parseInt)` …lol?!
You know damn well what you're doing Mr radix. Variadic languages have some edge cases. If you don't like it, use Number like a sane person:
['1', '7', '11'].map(Number)
ParseInt is usually not what you want, but again... JS won't break compatibility for you - that doesn't mean the foundation is shaky...
It just means that some parts are older than others.