4 ms·

> In my experience, this is the main problem with choosing an off the beaten path language/database/library X. It increasingly is also the case with regular li

by mhd 3y ago

> In my experience, this is the main problem with choosing an off the beaten path language/database/library X. It increasingly is also the case with regular libraries and programming languages. This was somewhat accepted for the former outside of the most static of enterprise environments or OS standard libraries, but somewhat new for programming languages. Mostly because they're now managed like products and actually are - singular implementation, no standardization effort attempted. Thuse "move fast and break things" and an ever-increasing scope creep are part of the deal. If you aren't adding some feature, you seem dead. Granted, within that "late stage PL design" area you've got different degrees of severity, especially given how all those new features relate to backwards compatibility. TypeScript and Rust never got the bad reputation that D had, for example (mostly relating to the old debates, where it was still in an earlier dev stage and GC vs non-GC was a big issue, for example; can't say anyting about this recent debate).

Waterluvian 3y ago
> It increasingly is also the case with regular libraries and programming languages. Let me posit this, without actually feeling sure that this is correct: As a rough example, say there’s 100 hardened libraries and languages that meet the reliable and slow and steady sensibilities. Now consider that programming becomes less and less niche, and in addition to those 100 libraries, we also have 500 libraries of dubious dev attitude and quality. People will feel that quality is falling off a cliff when they experience it as a whole. But really there’s just more choice, most of which you can just ignore. I think I wonder the same thing about people’s feelings of how programmers are getting worse or everyone’s just a web dev these days. I’m gonna guess there’s more “”serious programmers”” than ever before. They just make a smaller slice of the pie. So I wonder if this is actually true and can be measured beyond a handful of anecdotes, or if we’re just being biased by a growing selection of “move fast / I’m not too serious about this” libraries?
- mhd 3y ago
  So, basically Sturgeon's law, where 80% of everything is crud, and now we got a huge crud heap, but also lot's of shining gems besides it? I'm not that sure about that, mostly because I'd say that the actual quality of something is orthogonal to the featuritis exhibited quite often. For one, all the shiny new features of something might actually be very good. And a change breaking compatibility might be the good design choice - getting it right the first time or having to drag Sisyphos' rock along for eons shouldn't be the two possible outcomes. It's a trade-off, especially when you consider the other 80/20 split here, where 80% use only 20% of features, but different 20%... In our days of easy release cycles (just tag a release, finish a sprint etc.) and easier communication (issue trackers, emails, social media) and contribution (open source, pull requests), we're just upstreaming more workarounds and library additions that would've happened in your local projects. I have an easier time accepting this in libraries. They're malleable, maybe even ephemeral objects you handle when working on your project. Maybe a bit loosey-goosey these days, never mind the tendency to hop between frameworks/libraries, but well, we never got our true component system where you can just extend existing libraries that then remain untouched. But languages operating in the same way still rubs me the wrong way. I'd prefer to have a more solid foundation, not mutating turtles all the way down. But after C++ unleased the feature genie, it's hard to put it back into the bottle again.
pjmlp 3y ago
> Mostly because they're now managed like products and actually are - singular implementation, no standardization effort attempted. Thuse "move fast and break things" and an ever-increasing scope creep are part of the deal. If you aren't adding some feature, you seem dead. That has always been the case, even more so when all programming languages were commercial products and newer versions had to be sold.
- mhd 3y ago
  Well, you still had to ship floppies, which kinda limits your pace. And with heavily fragmented platforms, standards – informal or formal – helped as one vendor didn't cover everything. And thus compatibility to someone's else Pascal/Cobol/C compiler actually helped sales.

by mhd 3y ago

Waterluvian 3y ago

> It increasingly is also the case with regular libraries and programming languages. Let me posit this, without actually feeling sure that this is correct: As a rough example, say there’s 100 hardened libraries and languages that meet the reliable and slow and steady sensibilities. Now consider that programming becomes less and less niche, and in addition to those 100 libraries, we also have 500 libraries of dubious dev attitude and quality. People will feel that quality is falling off a cliff when they experience it as a whole. But really there’s just more choice, most of which you can just ignore. I think I wonder the same thing about people’s feelings of how programmers are getting worse or everyone’s just a web dev these days. I’m gonna guess there’s more “”serious programmers”” than ever before. They just make a smaller slice of the pie. So I wonder if this is actually true and can be measured beyond a handful of anecdotes, or if we’re just being biased by a growing selection of “move fast / I’m not too serious about this” libraries?

mhd 3y ago
So, basically Sturgeon's law, where 80% of everything is crud, and now we got a huge crud heap, but also lot's of shining gems besides it? I'm not that sure about that, mostly because I'd say that the actual quality of something is orthogonal to the featuritis exhibited quite often. For one, all the shiny new features of something might actually be very good. And a change breaking compatibility might be the good design choice - getting it right the first time or having to drag Sisyphos' rock along for eons shouldn't be the two possible outcomes. It's a trade-off, especially when you consider the other 80/20 split here, where 80% use only 20% of features, but different 20%... In our days of easy release cycles (just tag a release, finish a sprint etc.) and easier communication (issue trackers, emails, social media) and contribution (open source, pull requests), we're just upstreaming more workarounds and library additions that would've happened in your local projects. I have an easier time accepting this in libraries. They're malleable, maybe even ephemeral objects you handle when working on your project. Maybe a bit loosey-goosey these days, never mind the tendency to hop between frameworks/libraries, but well, we never got our true component system where you can just extend existing libraries that then remain untouched. But languages operating in the same way still rubs me the wrong way. I'd prefer to have a more solid foundation, not mutating turtles all the way down. But after C++ unleased the feature genie, it's hard to put it back into the bottle again.

pjmlp 3y ago

> Mostly because they're now managed like products and actually are - singular implementation, no standardization effort attempted. Thuse "move fast and break things" and an ever-increasing scope creep are part of the deal. If you aren't adding some feature, you seem dead. That has always been the case, even more so when all programming languages were commercial products and newer versions had to be sold.

mhd 3y ago
Well, you still had to ship floppies, which kinda limits your pace. And with heavily fragmented platforms, standards – informal or formal – helped as one vendor didn't cover everything. And thus compatibility to someone's else Pascal/Cobol/C compiler actually helped sales.