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 ).

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.

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.

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.

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 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.

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 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.

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!".

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.

AI agents, perhaps? :-D

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

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.

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.