this post was submitted on 08 Sep 2023
546 points (94.2% liked)

Programmer Humor

19817 readers
66 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
(page 3) 50 comments
sorted by: hot top controversial new old
[–] [email protected] 4 points 1 year ago (1 children)

I haven't managed to break into the JS-adjacent ecosystem, but tooling around Typescript is definitely a major part of the problem:

  • following a basic tutorial somehow ended up spending multiple seconds just to transpile and run "Hello, World!".
  • there are at least 3 different ways of specifying the files and settings you want to use, and some of them will cause others to be ignored entirely, even though it looks like they should be used.
  • embracing duck typing means many common type errors simply cannot be caught. Also that means dynamic type checks are impossible, even though JS itself supports them (admittedly with oddities, e.g. with string vs String).
  • there are at least 3 incompatible ways to define and use a "module", and it's not clear what's actually useful or intended to be used, or what the outputs are supposed to be for different environments.

At this point I'm seriously considering writing my own sanelanguage-to-JS transpiler or using some other one (maybe Haxe? but I'm not sure its object model allows full performance tweaking), because I've written literally dozens of other languages without this kind of pain.

WASM has its own problems (we shouldn't be quick to call asm.js obsolete ... also, C's object model is not what people think it is) but that's another story.


At this point, I'd be happy with some basic code reuse. Have a "generalized fibonacci" module taking 3 inputs, and call it 3 ways: from a web browser on the client side, as a web browser request to server (which is running nodejs), or as a nodejs command-line program. Transpiling one of the callers should not force the others to be transpiled, but if multiple of the callers need to be transpiled at once, it should not typecheck the library internals multiple times. I should also be able to choose whether to produce a "dynamic" library (which can be recompiled later without recompiling the dependencies) or a "static" one (only output a single merged file), and whether to minify.

I'm not sure the TS ecosystem is competent enough to deal with this.

load more comments (1 replies)
[–] [email protected] 3 points 1 year ago (1 children)
load more comments (1 replies)
[–] [email protected] 3 points 1 year ago

Keen to see how this one turns out. Maybe it'll light the fire under people's asses and we'll get native types in JS finally

[–] [email protected] 3 points 1 year ago

All the stuff I write is personal tools anyways so I do the same. They're small anyways.

[–] [email protected] 3 points 1 year ago

I've always felt it doesn't solve the problem people think it's solving.

[–] [email protected] 3 points 1 year ago

I’m idealistically/philosophically committed to a Purescript Halogen front end with a Haskell Servant backend, biatch. Maybe someday I’ll get WASM in there. One thing I will not do is use TS or JS.

[–] [email protected] 3 points 1 year ago

I'm with the guy sitting at the table

[–] [email protected] 3 points 1 year ago

To be perfectly frank, I've only seen the drama on social media platforms. Outside of this one library Ive hardly seen anyone trying to fight typescript in the professional community.

[–] [email protected] 2 points 1 year ago

well, I mostly create SPAs, with big projects a type system is a necessity...

load more comments
view more: ‹ prev next ›