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

191–200 of 202 posts

Re: Douglas Crockford on JavaScript

#191

Post by bilalq »

consilient wrote: post #180
bilalq wrote: post #178

Earlier quoted context omitted.

Sure, ifError rejects, but I don't think the behavior here is surprising or strange at all. This is exactly how one would want it to work. If you wanted to await it, you could do that. Is the concern you're raising that people may accidentally orphan floating promises? That can be addressed with linter rules. [1][2] [1]: https://github.com/typescript-eslint/typescript-eslint/blob/... [2]: https://github.com/typescrip…

> but I don't think the behavior here is surprising or strange at all. Tell that to my junior coworkers. It's probably the single most common cause of async bugs in our codebase.

Are you running those two lint rules I mentioned? They should completely remove cases of accidental floating promises.

Re: Douglas Crockford on JavaScript

#192

Post by yakshaving_jgt »

horsawlarway wrote: post #140
yakshaving_jgt wrote: post #104

Earlier quoted context omitted.

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

And on the seventh day He finished his work that he had done, and he rested on the seventh day from all his work that he had done.

Re: Douglas Crockford on JavaScript

#193

Post by scotty79 »

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…

Personally I feel like having functions and closures as first class objects is the killer feature. Without that, even dynamic languages feels unnecessarily restrictive when you tried JS.

Re: Douglas Crockford on JavaScript

#195

Post by horsawlarway »

JBits wrote: post #149
horsawlarway wrote: post #144

Earlier quoted context omitted.

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

I know - I just keep getting older... hard to believe that was nearly 20 years back now, and not 20 months.

Re: Douglas Crockford on JavaScript

#196

Post by hombre_fatal »

sajex wrote: post #148
bilalq wrote: post #113

Earlier quoted context omitted.

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.

Well, I wouldn't put it like that. Async can trivially cash out into parallel work like if you're just sending queries to a database or ffmpeg or ImageMagick or, frankly, most common use cases which are going to do work in parallel out of process.

All of your I/O work could even be happening in parallel in a run of the mill JS app. Workers just give you parallelism with your sync JS code which is a more narrow claim.

Re: Douglas Crockford on JavaScript

#197

Post by consilient »

bilalq wrote: post #191
consilient wrote: post #180

Earlier quoted context omitted.

> but I don't think the behavior here is surprising or strange at all. Tell that to my junior coworkers. It's probably the single most common cause of async bugs in our codebase.

Are you running those two lint rules I mentioned? They should completely remove cases of accidental floating promises.

Yes, but the floating isn't the issue: throwing in my example was just a concrete stand in for promise side effects in general. Running queries you only need in one not so common branch before the conditional gets checked, for instance.

Re: Douglas Crockford on JavaScript

#198

Post by bourneavent »

hajile wrote: post #120
bourneavent wrote: post #110

Earlier quoted context omitted.

>He might be right on some fronts, JS was designed in a week. He's completely right, it's just poorly designed. Javascript will always be around because of technical debt and habit. But that doesn't change the fact that Douglas is right. Also nobody really uses javascript anymore. It's completely insane. We compile Typescript into javascript then run javascript. That should tell you something about javascript.

TS is literally JS with a few unsound type hints. If you're writing TS, you are already writing JS.

I mean I could say C++ is just python with memory management macros.

We're getting into the domain of opinion here. I would say TS is different enough such that it's two different languages.

Programming with type checking and programming with plain JS is really different. A programmer without experience in types (ie plain JS) won't be able to pick up types that that quickly on average. Things like enums, Generics, sum types, product types, recursive types, really change the game by restricting what functions can do.

Re: Douglas Crockford on JavaScript

#199

Post by planede »

WorldMaker wrote: post #82
planede wrote: post #18

Earlier quoted context omitted.

Isn't Typescript "controlled" by Microsoft?

Typescript is completely open source (Apache 2.0 licensed) and all of its roadmap, planning, issue tracking, peer reviewing, is also out in the open (in GitHub Issues). It's about as "controlled" by Microsoft as Linux is "controlled" by Red Hat at this point.

OK, but the point of comparison was Dart/Flutter, which I suppose is similarly open.

Open source does not mean that it's not controlled by a single person or organization. It's not meant as a critique though, as the alternative I guess is a language designed by committee, which has its own problems.

Re: Douglas Crockford on JavaScript

#200

Post by hajile »

bourneavent wrote: post #198
hajile wrote: post #120

Earlier quoted context omitted.

TS is literally JS with a few unsound type hints. If you're writing TS, you are already writing JS.

I mean I could say C++ is just python with memory management macros. We're getting into the domain of opinion here. I would say TS is different enough such that it's two different languages. Programming with type checking and programming with plain JS is really different. A programmer without experience in types (ie plain JS) won't be able to pick up types that that quickly on average. Things like enums, Generics, su…

Typescript's devs define it as simply JS with types to the point that they even have a proposal to add those type constructs into JS at which point the syntactic difference would be very small indeed.

> Things like enums, Generics, sum types, product types, recursive types, really change the game by restricting what functions can do.

If only that were true. The reality is that if you can write it in JS, you can add TS types no matter how horrible or anti-pattern the code happens to be. The constructs you mention don't restrict what functions can do in any way at all.

> A programmer without experience in types (ie plain JS) won't be able to pick up types that that quickly on average.

The average JS dev seems to have a Java/C# background where types exist. Further, they seem bent on slowly transforming JS into one of those languages.

Post reply on HN