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

Proposal: JavaScript Structs

github.com

Post reply on HN
Print view View original

361–370 of 371 posts

Re: Proposal: JavaScript Structs

#361

Post by usrusr »

wiseowise wrote: post #176
usrusr wrote: post #118

Earlier quoted context omitted.

Not just half of it, the central part of it. Javascript did not grow into something huge, it started that way. A prototype based wannabe Java that accidentally (?) shipped with a full scheme included alongside. The latter of which remained mostly dormant until "the good parts" came along and put them into the (deserved) spotlight, relegating the prototype stuff from idiomatic to niche, for when you are doing somethin…

> shipped with a full scheme included alongside Sorry, what? https://journal.stuffwithstuff.com/2013/07/18/javascript-isn...

The "scheme inside" might be missing the mark in any number of features, but in the end the resulting effect it had have been profoundly, well, effective. It's there.

People have been going all SICP (Abelson/Sussman) on JS ever since Crockford exposed the hidden scheme (or hidden not-scheme-at-all, if you insist) and moved JS far, far away from the humble prototype OOP it started as. And that had little to do with any language extensions that had been creeping in very slowly given the lowest common denominator nature of web development, and everything with the funky scope binding tricks that generations of programmers had been taught in the memorable "let's make Scheme OOP" drills of SICP and the MIT course (that so many other universities based their teaching on)

Re: Proposal: JavaScript Structs

#362

Post by n_plus_1_acc »

lelanthran wrote: post #355
n_plus_1_acc wrote: post #51

Earlier quoted context omitted.

How can you teach C when there's no list of UB, there's sometimes no agreement on how to read the standard, and loads of non-standard-compliant compilers.

> How can you teach C when there's no list of UB, there's sometimes no agreement on how to read the standard, and loads of non-standard-compliant compilers. Right. Becuase no one ever learned C as a first language ever, and those that paradoxically did were worse programmers for it!

Are you saying people who learned C as their first programming language are better programmers or worse?

Re: Proposal: JavaScript Structs

#363

Post by n_plus_1_acc »

bobthepanda wrote: post #60
n_plus_1_acc wrote: post #51

Earlier quoted context omitted.

How can you teach C when there's no list of UB, there's sometimes no agreement on how to read the standard, and loads of non-standard-compliant compilers.

Plenty of universities teach C every day even if that means specifying a compiler, and usually it’s a very boring compiler that gets chosen

Right, but all C courses I've done had UB in examples without mebtioning it. There teachers just didn't know what they are teaching.

Re: Proposal: JavaScript Structs

#364

Post by johnfn »

xpe wrote: post #313
johnfn wrote: post #29

Earlier quoted context omitted.

Let me know when WASM has a dev workflow that gets a change to your browser 1/10th as fast as Vite + TypeScript + React.

I will grant that fast iteration is beneficial. But for me, under 10 seconds is usually fast enough. (For example, I don't think I would care too much when comparing 0.5 vs 5 second builds.) I personally care a lot more about having a confidence-inspiring language and ecosystem. In my experience with Rust and WASM (with various tools such as Dioxus), I find myself caring a lot more about the WASM ecosystem and browse…

The reason I bring it up is because web-dev often ends up being an extremely long sequence of small tweaks. "Hmm, did that make the modal go on top of the sidebar? [save] no? [save] did that? [save] how about that? [savesavesavesavesavesave]" Iterate that process 1000 times and you have my typical workflow. This is why even a 10 second build time, which is pretty fast for most domains, is actually pretty mind-numbing in web-dev.

I'm all for having a confidence-inspiring language and ecosystem, don't get me wrong, but it's kind of a non-starter if I can't build at the same pace in Rust as I can in typical web technologies.

Re: Proposal: JavaScript Structs

#365

Post by klysm »

ericmcer wrote: post #303
klysm wrote: post #160

Earlier quoted context omitted.

Typescript is the best thing to happen to JavaScript since ES6

Yeah I was almost gonna say it makes this proposal feel redundant. I can enforce object shape pretty well using TS, not sure why we need another OOP like thing that tries to do the same.

Typescript doesn’t tell the JS runtime anything about what it knows

Re: Proposal: JavaScript Structs

#366

Post by whizzter »

rezonant wrote: post #227
whizzter wrote: post #202

Earlier quoted context omitted.

How long ago was this? TypeScript v1 and v2 definitely had a class-based stink to it since the typing system only handled those scenarios somewhat well. Right around when I started using it (mid 2019) there was a bunch of V3 releases that each on it's own might've not seemed like much but they all improved small parts of the engine that made it easy to get typing on most of your code if using a functional style witho…

I'm all for people writing functional code with Javascript-- but when people eschew classes because of their "stink" and proceed to use all of the stateful prototypal archaic features of JS instead of classes, I have to protest. If you are using this and function binding and state extensively in your "functional" JavaScript, you are reinventing classes poorly. And classes are a part of JS itself, not something added…

My point was rather that a functional style with plain old data was always preferable, the "stink" was that early TS versions _favored_ non-functional OO style that suited the TS type system at a time when most modern JS code already had a functional approach, so you ended up writing non-idiomatic JS because the TS type system wouldn't handle idiomatic code (this also contributed to a lingering distrust in TypeScript that persists to this day despite the upgrades to the typing system).

Personally I prefer neither prototypal or classes, 90% of the time you just want the interfaces, unions or inferred types and the few places where you actually want inheritance and/or object methods you really are just better off with a factory method that then creates a literal that is used or suits an interface.

Re: Proposal: JavaScript Structs

#367

Post by bobthepanda »

n_plus_1_acc wrote: post #363
bobthepanda wrote: post #60

Earlier quoted context omitted.

Plenty of universities teach C every day even if that means specifying a compiler, and usually it’s a very boring compiler that gets chosen

Right, but all C courses I've done had UB in examples without mebtioning it. There teachers just didn't know what they are teaching.

Unless you are writing a compiler and code specifically tailored to take advantage of UB, there’s not much to say about it other than “be careful about UB cause it can make your program buggy from your POV.”

Re: Proposal: JavaScript Structs

#368

Post by spease »

sensanaty wrote: post #309
pjc50 wrote: post #220

Earlier quoted context omitted.

> continually deprecate small parts of the language Did you see https://news.ycombinator.com/item?id=41788026 ? "My concern, and IMO what should be the overwhelming concern of the maintainers, is not the code that is being written, or the code that will be written, but all the code that has been written, and will never be touched again. A break like this will force lots of python users to avoid upgrading to 3.17, jet…

But they can simply continue using whatever version of Python works for them, right? I never got this argument, personally. Sure, having to rip out a bunch of code because of lang-level changes can suck, but you also only really need to do that if you're starting a new project anyway or for whatever reason want to keep being pinned to @latest version of the lang. If you're a researcher who uses Python 2 as a means to…

No, because features get added to new versions of Python, and libraries they need to use may depend on those features. “Just don’t upgrade Python” is advice that’s only going to last a finite amount of time before introducing pain points and/or risk.

Re: Proposal: JavaScript Structs

#369

Post by egeozcan »

maxdamantus wrote: post #334
LegionMammal978 wrote: post #301

Earlier quoted context omitted.

Thanks for the history! Reading through the issues, I agree with you that some of the motivations against objects in records seem pretty strange. Mostly they seem to be around existing JS-written 'membranes' (related to the SES stuff mentioned above?) getting confused by primitives-containing-objects, depending on which permutation of typeof checks they use. Out of curiosity, do you think that the Shadow Realms propo…

> Out of curiosity, do you think that the Shadow Realms proposal they refer to will ever go anywhere? I haven't really been following the Shadow Realm proposal (I'm not part of TC39, so only familiar with certain proposals), but I don't think it should conflict with R/T. If R/T values are allowed to be passed between realms, they should effectively be "transformed" such that eg, `f(#[v])` is equivalent to `f(#[f(v)])…

Thank you so much for the insight!

Re: Proposal: JavaScript Structs

#370

Post by lelanthran »

n_plus_1_acc wrote: post #362
lelanthran wrote: post #355

Earlier quoted context omitted.

> How can you teach C when there's no list of UB, there's sometimes no agreement on how to read the standard, and loads of non-standard-compliant compilers. Right. Becuase no one ever learned C as a first language ever, and those that paradoxically did were worse programmers for it!

Are you saying people who learned C as their first programming language are better programmers or worse?

> Are you saying people who learned C as their first programming language are better programmers or worse?

That's both a false dichotomy and irrelevant as well.

My message is "There are multiple excellent (even legendary) developers in the short history of our field that learned programming in C. There are many more who primarily used C".

This refutes your point completely.

Post reply on HN