Comment by mjr00

Comment by mjr00 9 days ago

> If the code works, passes all relevant tests, is reasonably maintainable, and can be fitted into the system correctly with a well defined interface, does it really matter?

You're not wrong here, but there's a big difference in programming one-off tooling or prototype MVPs and programming things that need to be maintained for years and years.

We did this song and dance pretty recently with dynamic typing. Developers thought it was so much more productive to use dynamically typed languages, because it is in the initial phases. Then years went by, those small, quick-to-make dynamic codebases ended up becoming unmaintainable monstrosities, and those developers who hyped up dynamic typing invented Python/PHP type hinting and Flow for JavaScript, later moving to TypeScript entirely. Nowadays nobody seriously recommends building long-lived systems in untyped languages, but they are still very useful for one-off scripting and more interactive/exploratory work where correctness is less important, i.e. Jupyter notebooks.

I wouldn't be surprised to see the same pattern happen with low-supervision AI code; it's great for popping out the first MVP, but because it generates poor code, the gung-ho junior devs who think they're getting 10x productivity gains will wisen up and realize the value of spending an hour thinking about proper levels of abstraction instead of YOLO'ing the first thing the AI spits out when they want to build a system that's going to be worked on by multiple developers for multiple years.

bcoates 9 days ago

I think the productivity gains of dynamic typed languages were real, and based on two things: dynamic typing (can) provide certain safety properties trivially, and dynamic typing neatly kills off the utterly inadequate type systems found in mainstream languages when they were launched (the 90s, mostly).

You'll notice the type systems being bolted onto dynamic languages or found in serious attempts at new languages are radically different than the type systems being rejected by the likes of javascript, python, ruby and perl.

Reply View 0 replies

nottorp 9 days ago

> those small, quick-to-make dynamic codebases ended up becoming unmaintainable monstrosities

In my experience, type checking / type hinting already starts to pay off when more than one person is working on an even small-ish code base. Just because it helps you keep in mind what comes/goes to the other guy's code.

Reply View 5 replies

lolinder 9 days ago

And in my experience "me 3 months later" counts as a whole second developer that needs accommodating. The only time I appreciate not having to think about types is on code that I know I will never, ever come back to—stuff like a one off bash script.

Reply View | 3 replies
- wesselbindt 8 days ago
  
  > "me 3 months later" counts as a whole second developer
  A fairly incompetent one, in my experience. And don't even get me started on "me 3 months ago", that guy's even worse.
  
  Reply View | 2 replies
  
  nottorp 8 days ago
  
  "How has that shit ever worked?"
  Me, looking at code 100% written by me last year.
  
  Reply View | 1 reply
  
  baq 8 days ago
  
  It gets worse with age and size of the project. I’m getting the same vibes, but for code written by me last month.
  
  Reply View | 0 replies
guskel 9 days ago

Yep, I've seen type hinting even be helpful without a type checker in python. Just as a way for devs to tell each other what they intend on passing. Even when a small percent of the hints are incorrect, having those hints there can still pay off.

Reply View | 0 replies

dheera 8 days ago

> You're not wrong here, but there's a big difference in programming one-off tooling or prototype MVPs and programming things that need to be maintained for years and years.

Humans also worry about their jobs, especially in PIP-happy companies; they are very well known for writing intentionally over-complicated code that only they understand so that they are irreplaceable

Reply View 9 replies

XorNot 8 days ago

I'm not convinced this actually happens. Seems more like somthing people assume happens because they don't like whatever codebase is at the new job.

Reply View | 7 replies
- SkyBelow 8 days ago
  
  The challenge is that sufficiently bad code could be intentional or it could be from a lack of skill.
  For example, I've seen a C# application where every function takes in and outputs an array of objects, supposedly built that way so the internal code can be modified without ever having to worry about the contract breaking. It was just as bad as you are imagining, probably worse. Was that incompetence or building things to be so complicated that others would struggle to work on it?
  
  Reply View | 1 reply
  
  mistrial9 8 days ago
  
  but that is literally how the browser window DOM works, no? It depends on how diligent the maintenance is IMHO
  
  Reply View | 0 replies
- baq 8 days ago
  
  If your TC is 500k-1M and you don’t feel like job hopping anymore, you’d certainly not want to get hit by a random layoff due to insufficient organizational masculinity or whatever. Maintaining a complex blob of mission critical code is one way of increasing your survival chances, though of course nothing is guaranteed.
  
  Reply View | 3 replies
  
  LtWorf 8 days ago
  
  People doing layoffs have no idea of who works and who's warming the chair.
  
  Reply View | 2 replies
- dheera 8 days ago
  
  Oh, I'm convinced, I've seen it first hand.
  
  Reply View | 0 replies
mistrial9 8 days ago

hmm I have seen conda env with far too many packages and maybe a lot of current version bumping, and the dev says "who cares" and it naturally gets a bit more.. Intentionally complicated is more like an accusation of wrongdoing.

Reply View | 0 replies

triyambakam 8 days ago

The ML world being nearly entirely in Python, much of it untyped (and that the Python type system is pretty weak) is really scary.

Reply View 1 reply

ramesh31 8 days ago

>The ML world being nearly entirely in Python, much of it untyped (and that the Python type system is pretty weak) is really scary
I think this has a ton to do with the mixed results from "vibe coding" we've seen as the codebase grows in scope and complexity. Agents seem to break down without a good type system. Same goes for JS.
I've just recently started on an Objective-C project using Cline, and it's like nirvana. I can code out an entire interface and have it implemented for me as I'm going. I see no reason it couldn't scale infinitely to massive LOC with good coding practices. The real killer feature is header files. Being able to have your entire projects headers in context at all time, along with a proper compiler for debugging, changes the game for how agents can reason on the whole codebase.

Reply View | 0 replies

ManuelKiessling 8 days ago

I'm certainly extremely happy for having an extensive type system in my daily driver languages especially when working with AI coding assistance — it's yet another very crucial guard rail that ensures that keeps the AI on track and makes a lot of fuckups downright impossible.

Reply View 0 replies