stakhanov

IMO, PRs were never the right process to use in tightly-collaborating teams such as most companies. PRs got popular because orgs started using GitHub, and GitHub had made that workflow to fit the needs of open source (and modeled it after what open source was already doing in the days when patches got sent around via mailing lists).

I'm old enough to remember using CVS and then subversion in companies. People would commit straight to main (which was then called "trunk"), because making feature branches and merging them was cumbersome. And, on regular intervals, the person responsible for some corner of the codebase would do a show-and-tell presenting it to peers, but without the sharply defined boundaries of what the code looked like before vs. after some recent set of changes. People might remember some things from the previous show and tell or from first hand experience with that code, but that kind of memory is necessarily fuzzy, and diffs weren't an artefact that was typical to look at. So, these reviews didn't block people, and any comments that came from reviews defined a direction that things should go from here on out. If a corner of the codebase was deemed to be in a bad shape, the blame around that was equally fuzzy.

LLMs do this to communicate with their future selves to avoid retracing what turned out to be the garden path.

Another pattern is where they put comments in multiple places in the code to say that those need to be kept in sync in a very particular way ...that sort of thing has always been considered a code smell, but seems to be the post-AI "new normal": it's cheaper for the AI to leave it to its future self to have to make every change in multiple places than it is for its present-day self to do the refactor.

Before AI, writing code that worked was costly and structuring it well, while you were at it, didn't increase your cost all that much. Now, AI has reduced the cost of writing badly-structured but working code, while it hasn't reduced the cost of writing well-structured code all that much. Since no one who decides about this sort of thing has given two craps about structure, ever, bad structure is just what we're left with now.

The day will come when codebases will be completely unintelligible to humans. The best example is when AI actually refers to code in comments with actual line numbers. No human would ever do that or find that useful if another human did it, because it would be next to impossible for a human to keep the line numbers properly updated after edits and they would soon all be wrong and meaningless.

You'd have to go very far back in computing history to get to where we learned not to do that. Was there ever programming with goto's referencing line numbers instead of named labels? If so, this would be that.

It's so friggin' transparent what they're up to: "Hey government: This is a really dangerous technology if it were allowed to get out there without proper policing. Fortunately, we are the stand-up guys who can be trusted as the new AI-police, but it's only going to work if you help us out a little by eradicating the competition on our behalf."

Hey Anthropic: You're a bunch of thieves crying foul because other thieves and thieving from you. Now, go live in the dystopian nightmare you've created and don't expect help from anyone. I, for one, will happily continue using Kimi and DeepSeek, and think of it as a good deed, if it helps with keeping us all from becoming your serfs.

> People who haven't used Perl to its full power have little how idea just how magical a language it was/is.

...why would you prefer to reach for the "no true scotsman ...", rather than read in any one of two other places in this thread that you are dealing with fellow scotsmen here?

I can't debate Raku with you, because I don't know any Raku, because, why should I? Life is short. I do know Perl 5, and the only context where a discussion of Raku even makes sense is as an upgrade path for Perl 5. Upgrade path doesn't mean that a program written in Perl 5 should run with unaltered syntax and semantics in Raku and not panic. Providing an upgrade path for Python 2 was one of the primary purposes of Python 3, and they didn't understand it that way either. Upgrade path simply means: Leverage syntax and semantics and mental models already in programmers' minds and change them where necessary to trade off short term pain for long term gain. (But it's less pain than learning a different language altogether with completely different syntax and semantics and mental models).

I can give you a list of grievances I have with Perl 5. Maybe Raku addresses some of those. Maybe it doesn't. I don't know, but also, it doesn't matter. The late arrival of Raku means decades' worth of people using Python and other languages as an upgrade path for Perl 5 instead, so Raku addressing any of those grievances is now closing the barn doors after the horse has bolted. Any Perl 5 codebases still out there are run by people who are so allergic to the idea of having to touch their code, that Raku isn't an option for those folks either.

Having said all of that: Some of my grievances with Perl 5:

* No separate types of bytestrings versus sequences of unicode codepoints. Wherever there's strings in any non-trivially-sized real-word Perl 5 project, there is utter irreversible and irredeemable mojibake. This includes databases backing Perl applications, where they themselves don't have enforcement, so even if you threw away all of your code and started from scratch and just wanted to keep your data, Perl 5 would still haunt you from its grave. -- Having strings not be mojibake is easy as hell in 2026. Perl 5 makes this easy thing impossible, so I really don't share your idea of "make easy things easy"

* No canonical way to do object-orientation. (cf. blessed objects, Moo in different versions, and different conventions around how to use them) -- This stuff should be easy in 2026. Perl makes this easy thing really hard.

* Regexes suck. Their brevity is a nice circus stunt for a computer science audience, but unless you follow very particular patterns for composing them from ergonomically named constants, etc. etc. (which "in the wild" I rarely see), they are very unergonomic.

* Perl one-liners, and RSA decryption written in the form of a camel, make for nice t-shirts, but the same argument as above applies to them. There is no purpose today (but probably never was) in one-linerism because an LLM will knock out 10 lines of Python just as fast as 1 line of Perl, and reading those 10 lines of Python (which is the part that actually still matters) is more ergonomic than reading the Perl one-liner.

* The Perl 5/CPAN ecosystem has been left to rot and is no longer safe for consumption.

> The goal of programming languages is to execute instructions on the machine.

The goal of a general purpose programming language is to communicate a program from one human to another, and from one human today to the same human tomorrow, while understanding that a program is only written once, but read many times. -- In that goal it is no different from a natural language. -- This goal needs to be optimized for within the constraint that programs must also compile and execute in the way and with the outcomes that a human reading the code would expect.

Your observation about Brainfuck makes my point for me: If the execution was the actual goal, then Brainfuck would be as good a programming language as Rust, Zig, or Nim; but that clearly isn't the case.

3.5 years of using Perl5 for 8 hours a day every day. I'd like to take the other side on more of your bets please ;-)

> Python programmers would [...] bad mouth Perl all over the internet [...]

I am one of those, and I disagree with the moral connotation of that framing.

When you're in the know and give advice to someone who isn't, or when you're the previous generation passing on your lessons learned to the next, then you have two paths. You can either be honest about things that don't/didn't work, so mistakes won't be repeated. Or you can make it seem as if pixie dust covers everything you have expertise in that others don't and everything that your generation did that the next one will never know, so you look good. -- I don't think that the former path is the more morally reprehensible one at all. "Bad mouthing" is the wrong analogy here.

Not everything, but languages do serve a purpose tied to how many (and which) people speak them, and that's true for general purpose programming languages in the same way as for human languages. If learning Klingon is someone's "thing" then, well, everyone can judge for themselves whether the predicate "true weirdo" applies or not, but it's descriptive enough.

What if it had taken Nintendo 35 years to release the next GameBoy, and they now came along and said: "Listen up, everybody! We finally did it! It has a 16 bit processor now instead of 8 and 4 bit shades of green instead of 2, but it won't play any of your GameBoy games; you'll have to write new ones." -- If they did that, then being a hobby for a small number of true weirdos is the only way they could hope to fit into 2026. That's what Raku feels like to me.

I'm curious: What software is driving this? Is it a re-skin of the lobste.rs or HN open source software, or is it its own thing?

EDIT: ...just realized that's in the FAQ.

> Is it open source?

> Not yet. Maybe someday.

SuSE/openSuSE is innovating plenty of stuff which other distros find it worth to immitate, e.g. CachyOS and omarchy as Arch-derivatives felt that openSuSE-style btrfs snapshots were pretty cool.

It's a rock-solid distro, and if I had a use for enterprise support, I'd probably look into SLES as a pretty serious contender.

The breadth of what they're doing seems unparalleled, i.e. they have rolling release (Tumbleweed), delayed rolling release (Slowroll) which is pretty unique in and of itself, point release (Leap), and then both Tumbleweed and Leap are available in immutable form as well (MicroOS, and Leap Micro respectively), and all of the aforementioned with a broad choice of desktops or as server-focused minimal environments with an impressively small footprint without making unreasonable tradeoffs. ...if you multiply out all of those choices it gives you, it turns into quite a hairy ball of combinatorics, but they're doing a decent job supporting it all.

As far as graphical tools for system administration go, YaST is one of the most powerful and they are currently investing in properly replacing it, now that its 20-year history makes for an out-of-date appearance. I tried their new Agama installer just today, and was very pleased with the direction they're taking.

...so, not quite sure what you're getting at with your "Back in the day..." I, too, remember the days of going to a brick-and-mortar store to buy Linux as a box set, and it was between RedHat and SuSE. Since then, I think they've lost mindshare because other options became numerous and turned up the loudness, but I think they've been quiety doing a pretty decent job all this time and are still beloved by those who care to pay attention.

Always reminds me of the quote "I think there is a world market for maybe five computers." by T. J. Watson Sr.

The quote is usually delivered as a punchline of sorts, but we're rapidly approaching a world where there truly will be only five computers. If you define a computer as a system capable of truly general purpose computing, and if you count the computers as systems each capable of operating truly independently of the others. The term "general purpose" needs the further qualification, that a great deal of power and political capital will be needed to have any say in what purpose one of these five computers will be put to, and it will then be forced on the other people who are forced to work with that computer.

I agree. I'm not sure about "toy", but something that gives the child zero agency definitely falls hort of the definition of "play".