nocman

purposeless dumb challenges and difficulty

While I agree that for some people games with a time limit are not fun, I don't think the challenges and difficulty should be classified as "purposeless" and "dumb". For many the challenge/difficulty IS the fun part, and they serve a genuine purpose. If you don't like that, then play a different game, but that doesn't mean the game you don't like is useless.

it most certainly is NOT available at a reasonable cost in many places.

Yeah, DEC Alpha was the first thing to come to my mind. I guess some might argue it wasn't a "PC" - if you don't include what used to be called "workstations". This is largely because PC meant "personal computer", and very few people could afford their own DEC Alpha - they were very pricey ($20k at some point in the 90's, I believe).

It's been mostly dead all morning.

I don't think it is overreach since its fairly simple to implement and non obtrusive

Those two things have absolutely nothing to do with one another. Something being easy to implement is completely unrelated to whether forcing its implementation is overreach.

It's weird to see people in tech taking this stance. They've been riding the same wave of exploiting the average person through economies of scale for the last 20+ years, but now that it affects them, it's suddenly catastrophic.

That's an awfully wide swath you are cutting there. I can't think of a single tech person that I've worked closely with in the last 20 years that I would describe as "riding the same wave of exploiting the average person through economies of scale". The majority of tech workers do not work for FAANG, or anything close to it.

Yeah, because someone who is trying to sell you something would NEVER try to convince you that you can't possibly hope to compete without buying their product. /s

"old days of PHP and Apache" ...

Apache still runs about 23-28% of websites (with some measurements suggesting it is pretty close to equal with nginx). PHP is still in use by 70-80% of websites (numbers vary depending on where you look).

You make it sound like both pieces of tech are irrelevant. Nothing could be further from the truth.

some quick googled examples (like I said other sites' numbers vary, but you get the general idea):

https://www.wappalyzer.com/technologies/web-servers/ https://kinsta.com/php-market-share/

Got an idea that you'd need assembly language for - now you can do it instead of..... never doing it because it would have been impossible for you in any practical way

If you are having an LLM generate the assembly language for you, that is not even remotely close to writing the assembly language yourself.

I don't find it exciting even in the slightest. I can think of nothing more boring and unsatisfying than having an LLM generate all of your code for you.

I mean, I understand why some think this could be exciting from a "I can get something done fast because the LLM generates it for me" standpoint -- because their excitement stems from something getting done at all instead of just sitting in the pool of ideas forever. However, you will never know the code generated by an LLM like you know the code you wrote yourself. Also you will never gain the same satisfaction of finishing a project where the code was written by an LLM that you gain from finishing a project where you wrote the code yourself.

If you are a person that doesn't care about coding or doesn't like to code at all, I could totally see why you'd find this exciting - to you it's all about avoiding work you don't care for or want to do yourself anyway. Also, a high percentage of people who do love coding have zero interest in writing assembly language, so if they were required to write some for a project, I could also see them being happy with having an LLM generate that part of the project for them.

However, I think for people who genuinely love to write code, the situation is the opposite of what you said -- it is far more sad than it is exciting. In fact, for many of them it has already reached the point of depressing for many reasons. I don't think it is primarily because the LLMs have gotten significantly better at generating code (which they have). I think some of the bigger reasons are that so many people who now pay people to produce code have:

1) got a very short-sighted and "rose-colored-glasses" view of what LLM-produced code will do for their company.

    and

In the long run I think most (if not close to all) of those businesses are going to be sorry if they over-indulge in replacing human-produced code with LLM-produced code. I think the ones who lean too heavy on the LLM side are going to eventually collapse into a heap of unmanagable dumpster-fire code that they can't understand nor maintain. A whole new world of incidental complexity will consume every project, and in the long run it will just eat them alive (figuratively speaking, of course :-D ).

I mourn the death of a human artform.

The artform only dies if you let it. Even if your employer is so idiotically myopic as to forbid you to ever write your own code, you can still continue the art on your own time. I for one don't care how "good enough" any AI-lableled technology gets at writing code. I will continue to hone my craft until the day I either die, become too unwell to do it, or some other creative endeavor consumes all of my personal time.

Yeah :-(

Here I was hoping that somehow IBM had decided to open source it. That would have been fun. But I don't think that will ever happen.

nothing awkward about it.

IMHO, It's a better time than ever to develop a new IDE. Just make one that cares deeply about performance (i.e loads instantly, and always has a snappy response). Make features easy to control. Allow me to turn on only the things I care about and to shut the rest off.

I can't even remember the last time I was impressed by the speed of an IDE, though we have more computing power now than ever. I'd love to see someone new come in and wipe the floor with all of the current contenders.

I don't think the likelyhood of "electricity and Internet, running water grocery stores" being pulled out from underneath you (either by long term failure or prohibitive cost changes) is anywhere near as high as it is for subscription-based AI tools (at least not in the US).

I think you are making far too wide-sweeping statements. I think most people here probably agree that if Anthropic drops Claude Code from the Pro plan after people have paid with the understanding that it is part of the package, that would be wrong, and they deserve to lose business over it. However, there are plenty of situations where A/B testing is entirely benign, and I would not have any problem with a company doing that testing without getting consent first. Every form of A/B testing is not done just for the gain of the company doing the testing.

No one has ever made a purchasing decision based on how good your code is.

absolutely false.

The general public does not care about anything other than the capabilities and limitations of your product.

also false.

People may not know that the reason they like your product is because the code is so good, but everyone likes software that is mostly free from bugs, performs extremely well, helps them do their work quickly, and is obviously created by people the care deeply about the quality of the product they produce (you know, the kind that acutally read bug reports, and fix problems quickly).

The longer your product exists the more important the quality of the code will be. This obsession so many have with "get it out the door in 5 seconds" is only going to continue the parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks.

You don't have to pick on camp over the other. In my opinion, if you want to make a good product for a user, you should also treat the code you produce for them as your craft. There is no substitute for high quality work.

I came here to say something similar.

I somehow doubt there's a team at Google dedicated to roleplaying the nightmares of all living people :-D

When I saw your user name, I was like "I wonder if that's the C++ s11n guy", and sure enough, confirmed it by viewing your profile.

Glad to see you're still alive and kickin' -- hope you are doing well, despite life's challenges.

Yeah, I've never really been at all offended by the "eating your own dogfood" phrase, because I always saw that as being the point also.

I must admit, however, that the title of this article was too crass for me. I came very close to not reading it at all just because of the title. In my opinion, the article would be better served by something else, but I'm just not a big fan of bathroom humor in general.

There's absolutely nothing wrong with the word picture that was used. I'd advise against assuming the worst possible interpretation of someone else's words (especially online). Most of us probably do that at least sometimes (present company included), but it would be much better to give people the benefit of the doubt. In this case, I think it is fair to assume that the original poster was just saying that he wouldn't let them try to get away and not actually deal with the problem -- much as a border collie prevents other animals from straying from the group, keeping them where they need to be.

There is no need to assume that they meant that the others in the meeting were less important or less intelligent, or whatever. They were, perhaps, just less interested in dealing with the problem.

they bother to have a Klingon language consultant on staff

I realize there's a fair bit of money to be made, and also that many people are super invested in their favorite science fiction series, but the fact that "a Klingon language consultant" is a real thing still makes me think "wow!".

I think it is worth noting that Richard P. Gabriel wrote the forward to the book in question, and he quotes Guy L. Steele in that forward -- from the paper that you are suggesting the author might like.

- Every day that passes, the gulf between Lisp's tooling and what a typical user expects grows wider. It needs to escape Emacs and SLIME to something that feels complete and polished.

Can you give specific examples of "what a typical user expects" that are missing from Emacs-based programming environments (SLIME, and/or others)? I'm not suggesting there aren't any, I'd just like to know your list.

Who are making these claims? script kiddies? sr devs? Altman?

AI agents, perhaps? :-D

sounds similar to rdiff-backup ( https://rdiff-backup.net ).

I know some folks that have been using that for a very long time as well.

Good one - made me and a coworker both LOL (in the literal sense) :D

Yeah, I didn't notice where the article was located at first, and I thought that's what it was going to be about also.

Um, please let your comment be sarcastic. It is ... right?

sed is not "stream editor" as it says above, it's "stream ed"

Well, according to the man page, it is indeed "stream editor":

https://man.cat-v.org/unix_8th/1/sed

I was already aware of its relation to 'ed' (having had to actually use 'ed' in ancient times). However that doesn't change the fact that it does stand for "stream editor".

After reading your post, I thought "That doesn't seem right, I remember it specifically being referred to as 'stream editor'", so I went looking.

There was strong cultural pressure to be able to write perl in as few bytes as possible

Hard disagree. Many Perl programmers enjoyed engaging in code golf (always just for fun, in my experience), but in my nearly 30 years of programming Perl, I never encountered anything that I would call pressure to do so -- not from anyone.

I don't think in this case that most people who know what Arduino is would be at all mislead by the title. Being "dead" doesn't have to mean that a company ceases to exist. There are plenty of what I would call "dead" companies that still make money every year. "Dead" can be used figuratively. In this case, meaning that though the company continues to exist, the reason for which many people bought their products is now gone.

And Randall deserves EVERY single one of them, IMHO!