this post was submitted on 08 Sep 2023
541 points (94.1% liked)

Programmer Humor

19623 readers
96 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 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[โ€“] jpeps@lemmy.world 43 points 1 year ago* (last edited 1 year ago) (2 children)

RoR will always have a special place in my heart, but yeah... DHH sure does have opinions. What possible justification is there for removing it when it's already there? Guess someone could just shift the types out to DT.

Edit: So I read his blog post about it. He's dropping it because he just doesn't like it and he's allowed to not like it. Okay then ๐Ÿคท

[โ€“] zebbedi@lemmy.world 16 points 1 year ago (1 children)

His blog to me sounds like he did it because it was too difficult for him to understand a few errors. Says it all.

[โ€“] jpeps@lemmy.world 8 points 1 year ago (1 children)

I wasn't going to say it, but yes, 100% ๐Ÿ˜‚

[โ€“] zebbedi@lemmy.world 8 points 1 year ago

You only have to read the PR comments with people asking how you know if something is optional when there is absolutely zero jsdoc to know it was idiotic.

[โ€“] Pipoca@lemmy.world 4 points 1 year ago

From his blog post:

While you may compile dialects into it, you still have to accept the fact that running code in the browser means running JavaScript. So being able to write that, free of any tooling, and free of any strong typing, is a blessing under the circumstances.

By his logic, JS linters are bad because they're tooling that restricts your access to all of Javascript. But linters mean you don't have to read PRs with a fine tooth comb to make sure there's no footguns like using == instead of ===.

Also, you could use that same logic to advocate for writing JVM bytecode directly instead of Java/Kotlin/Scala/Clojure/etc.

The question is really whether tooling pays its way in terms of lower bug rates, code that's easier for coworkers to read, and code that's easier to reason about.