Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Douglas Crockford on JavaScript

digest.browsertech.com

Post reply on HN
Print view View original

141–150 of 202 posts

Re: Douglas Crockford on JavaScript

#141

Post by jononomo »

preordained wrote: post #138
baerrie wrote: post #134

Languages 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.

I agree that the Imperial System is superior to the Metric System just from the point of view of human usability.

Re: Douglas Crockford on JavaScript

#142

Post by jerf »

hombre_fatal wrote: post #65
sspiff wrote: post #46

> 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…

"But consider something like this (JS) using WaitGroups in Go:"

Sure, though if this is something you're doing a lot of it's not hard to abstract out.

However, let me put on the other side of the balance the sheer staggering quantity of code there is out there that just "await"s everything in line as if they were writing some version of Go that required you to specify every function that could potentially be async, because Promise.all and friends are quite uncommon.

Before you jump up to protest to the contrary, go run a grep over your code base and count the "await"s that are simply awaiting the next thing in sequence versus doing something less trivial. Even those of you who write this code fluently will probably discover you have a lot of things just getting directly awaited. The exceptions, being rare, are cognitively available; the number of times you almost unthinkingly type "await" don't register because they are so common. Only a few of you doing something fairly unusual will be able to say with a straight face that you are using Promise.whatever abstractions all the time. Even fewer of you will be able to say you use all different kinds and construct your own and couldn't solve the lack of some particular abstraction in Go in just a few minutes of writing some function.

Re: Douglas Crockford on JavaScript

#143

Post by tedivm »

gsk22 wrote: post #135
user3939382 wrote: post #94

Earlier quoted context omitted.

> 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.

I say this as someone who hasn't professionally used PHP in about a decade, but still has a few open source projects: the arguments against PHP are silly at best, especially this particular argument. With modern IDEs it's easy to work around these quirks in the language.

Re: Douglas Crockford on JavaScript

#144

Post by horsawlarway »

toastercat wrote: post #83
horsawlarway wrote: post #74

Earlier 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 don't even mind the classes - just because it makes Crockford and the other enterprise java folks shut up This is the second time I've seen in this thread that people lump Crockford in with Java enterprise folks, but Crockford routinely says `class` was the worst addition to JS. > What I do find particularly impressive is how flexible JS is, and how much support can be added without actually changing the runtime…

> This is the second time I've seen in this thread that people lump Crockford in with Java enterprise folks, but Crockford routinely says `class` was the worst addition to JS.

Because Crockford was one of the people advocating for a particular style of initialization of objects that mirrored classes, but was not directly a class before classes existed in JS. (see: https://crockford.com/javascript/inheritance.html)

It is utterly enterprise and classlike in nature though, and not my cup of tea. Mainly - I just wanted enterprise folks to stop trying to re-invent classes in the language, and the class keyword stopped that behavior.

Big net win for the language in my opinion - even though I personally still don't use classes all that often.

---

His modern take is fairly reasonable, though.

Re: Douglas Crockford on JavaScript

#145

Post by baerrie »

preordained wrote: post #138
baerrie wrote: post #134

Languages 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.

You are free to pick up the better system in your opinion but if you want interoperability and consistency with other US measurers then you may have issues.

Re: Douglas Crockford on JavaScript

#146

Post by treis »

horsawlarway wrote: post #74
yakshaving_jgt wrote: post #61

Earlier quoted context omitted.

> ES6+ introduced a slew of features like arrow functions, template literals, async/await, destructuring, classes, enhanced object literals and native modules. This is the problem. All of this has made the language worse. Just accreting features doesn't make the foundation less broken.

> 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 see this view a lot - what I rarely ever see is a concrete discussion about what exactly is wrong with the "foundation" of javascript.

The things that were added mostly were to fix problems of JS:

arrow functions => because of "this" shenanigans

template literals => I'd say a basic part of a language

async/await => Promise/future hell

destructuring, classes, enhanced object literals => These are all syntactic sugar/nice to haves. Nothing really was broken here.

native modules => Another time I'd say that it's a basic part of a language

Re: Douglas Crockford on JavaScript

#147

Post by ptx »

tedivm wrote: post #143
gsk22 wrote: post #135

Earlier quoted context omitted.

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.

I say this as someone who hasn't professionally used PHP in about a decade, but still has a few open source projects: the arguments against PHP are silly at best, especially this particular argument. With modern IDEs it's easy to work around these quirks in the language.

OK, but are there any good arguments for PHP? Why not use something less quirky instead?

Re: Douglas Crockford on JavaScript

#148

Post by sajex »

bilalq wrote: post #113
arp242 wrote: post #99

Earlier quoted context omitted.

I think async-by-default was an interesting idea and well worth trying, but I don't really think it was a good idea. Turns out that most things you want to do are synchronous, and "sync-by-default unless mentioned otherwise" makes a lot more sense. This includes I/O by the way, because most of the time you want to wait until an operation has finished. Or to put it in another way: JavaScript makes the uncommon case ea…

I disagree. I'd take JS-style promises over trying to manage Futures in ForkJoinPools or thread pools any day. Being able to write async expressions in parallel by default means even junior devs take advantage of parallelism. I've seen plenty of code written in Java and Ruby where multiple network and DB requests are made in serial despite having no dependency on each other. The usual reason is that there's just a lo…

Async doesn't give you parallelism by default though, you just get concurrency. You don't get parallelism without using Workers.

Re: Douglas Crockford on JavaScript

#149

Post by JBits »

horsawlarway wrote: post #144
toastercat wrote: post #83

Earlier quoted context omitted.

> I don't even mind the classes - just because it makes Crockford and the other enterprise java folks shut up This is the second time I've seen in this thread that people lump Crockford in with Java enterprise folks, but Crockford routinely says `class` was the worst addition to JS. > What I do find particularly impressive is how flexible JS is, and how much support can be added without actually changing the runtime…

> This is the second time I've seen in this thread that people lump Crockford in with Java enterprise folks, but Crockford routinely says `class` was the worst addition to JS. Because Crockford was one of the people advocating for a particular style of initialization of objects that mirrored classes, but was not directly a class before classes existed in JS. (see: https://crockford.com/javascript/inheritance.html ) I…

His modern take, advocating prototypes, has been around since 2006 (https://crockford.com/javascript/prototypal.html).

Re: Douglas Crockford on JavaScript

#150

Post by hajile »

datadeft wrote: post #136
hajile wrote: post #100

Earlier quoted context omitted.

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?

AsmJS coercion hints still work, so not really. Monomorphic code and some optimization can take you a surprisingly long way toward good performance. You certainly won’t find that in most untyped languages.
Post reply on HN