If I had the willpower or time to go through a multi-thousand line (not including the html templates) legacy Angular 6 codebase where almost every property is typed 'any' then I assure you I would have, it's driving me insane 🙃, also why I prefer backend

[–] 0xSim@fedia.io 54 points 11 months ago (1 children)

The boy scout technique: fix your types when you're working on a bug or a feature, one file at a time. Also try to use unknown instead of any for more sensitive parts, it will force you to typecheck.

[–] WhatAmLemmy@lemmy.world 24 points 11 months ago (2 children)

The fuck the lemons technique: resign and seek an employer that didn't fail at the most basic level of engineering management and development culture for years and years — because life is short and we're all running out of time... always.

When life hands you lemons, just say fuck the lemons and bail

[–] DudeDudenson@lemmings.world 15 points 11 months ago* (last edited 11 months ago)

resign and seek an employer that didn't fail at the most basic level of engineering management and development culture for years and years

So basically change careers

[–] Hupf@feddit.de 8 points 11 months ago

combustible lemon

[–] roadrunner_ex@lemmy.ca 15 points 11 months ago (2 children)

I kinda feel your pain. A project that I helped launch is written in Typescript technically, but the actual on-the-ground developers were averse to using type safety, so any is used everywhere. So, it becomes worst of both worlds, and the code is a mess (I don't have authority in the project anymore, and wouldn't touch it even if I could).

I'm also annoyed at some level because some of the devs are pretty junior, and I fear they are going to go forward thinking Typescript or type safety in general is bad, which hurts my type-safety-loving-soul

[–] Lowpast@lemmy.world 7 points 11 months ago

One file at a time. Make strong pre-commit eslint rules (that way you don't impact existing code), eventually update tsconfig. You'll get there :)

[–] Zangoose@lemmy.world 2 points 11 months ago (2 children)

In theory I'm a fan of the inferred but static typing systems that most modern languages use (kotlin, rust, TS, etc.) where most local variable types can be inferred and only return types/object fields/parameters need explicit types.

I just despise typescript because it feels more like someone put a bandaid over JavaScript and all of its oddities instead of making a properly fleshed out language, and allowing the option for an 'any' type to be used freely by default emphasizes that.

[–] Zikeji@programming.dev 8 points 11 months ago (1 children)

Based on your description it sounds like you haven't given it a fair shake. I'll take TS over JS any day, at least there is room for improvement. I will say however I personally haven't been unlucky enough to run into projects that abuse the any type. The worst I've run into is a JS library with no typings I have to manually type.

[–] Knusper@feddit.de 2 points 11 months ago (1 children)

I imagine what they mean is e.g. that TypeScript can tell you something is a Date, but it doesn't attempt to fix some of the confusing, quirky behaviour with that: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#interpretation_of_two-digit_years

So, yes, it's generally better than JS, but it doesn't actually make it good/attractive, if you're used to the sanity of backend languages. It very much feels like lipstick on a pig.

[–] Zangoose@lemmy.world 2 points 11 months ago

Exactly this. I'd rather use TypeScript than regular JS, but I enjoy using almost any other statically-typed language more (except maybe C++) because TS has the potential to be just as bad as JS for codebases where it isn't being used correctly (this is true for other languages as well but it's usually a lot more obvious).

Not that it isn't possible to have good typescript code, but rather that code becomes a lot harder to maintain because of problems that could've been prevented at a language level (truthy/falsey logic, 'any' type being allowed by default rather than 'unknown,' etc)

[–] Traister101 1 points 11 months ago

TypeScript is JavaScript and not in the literal it's compiled to JS sense but in the think of TS as a linter not a language sense.

[–] walter_wiggles@lemmy.nz 13 points 11 months ago

Print the code out and burn it

[–] Anders429@programming.dev 55 points 11 months ago (2 children)

I've seen this same thing happen with Python's type hints. Turns out giving an "escape hatch" type for devs who have no clue what the type actually is leads to a lot of useless type hints.

[–] vzq@lemmy.blahaj.zone 15 points 11 months ago (1 children)

/me laughs in void*

[–] magic_lobster_party@kbin.social 12 points 11 months ago (1 children)

Laughs in Object

[–] RandomDevOpsDude@programming.dev 7 points 11 months ago

Laughs in object

[–] Knusper@feddit.de 4 points 11 months ago

Yeah, it's especially bad, when a library doesn't provide type hints itself. It can be comically difficult to find out what the return type of a function is, because every if-else-branch might have a different return value, so you may need to read the function body in full to figure out what the type might be.

Add to that, that lots of the tooling around type hints isn't as fleshed out / useful as it is in fully typed languages and I can definitely understand why someone might not immediately feel like it's a valuable use of their time.

[–] GissaMittJobb@lemmy.ml 8 points 11 months ago

It's all bits in registers at the end of the day, and they all have the only type a bit can have