o_nate

I think there are two ways to interpret this question, not sure which one you meant.

Question one: if you don't remember being conscious, were you actually conscious?

Seems the answer should be yes. Just because you don't remember something doesn't mean it didn't happen.

Question two: can you be conscious without something like memory?

This one I think may depend on future understanding of what consciousness is. It seems like consciousness without any memory would be consciousness without anything like perception.

There's a lot of wisdom in this. In addition to reserving some capacity for when true high-value work comes along, I think software engineering is not the type of job that you can do well if you're constantly busy. Trying to write some code as quickly as possible seldom yields the best design. This article doesn't get into another important aspect of this, which is how to get away with working at 80% capacity without getting in trouble with your manager. This takes a bit of care around communication and estimation of work. One of the first good pieces of advice that I got from older seasoned developers when I started my first real programming job has stayed with me to this day: take your estimate of how long it will take to do something and double it before communicating to your manager/users. As you get more experienced that ratio can come down to maybe 1.5x instead of 2x, but the principle still applies.

If students are allowed to use AI to accomplish their goals, then I think the real question is why should they go to an expensive university for four years to learn how to ask AI to do something?

The title may be needlessly aggressive. I think Rovelli could have framed this better by acknowledging there is a hard problem and then arguing that we have a better chance of resolving that problem by seeking a better understanding of conciousness as a physical process before drawing metaphysical lines in the sand. Or as Rovelli memorably puts it: "How can we know now what we would understand if we were to understand something we do not currently understand?" His point is that science is inextricable from subjective experience and subjective experience is inextricable from the physical world - a point made over 100 years ago by William James.

I'm currently reading (and enjoying) "How Life Works: A User's Guide to the New Biology" by Philip Ball. It proceeds from the bottom up: the first half is all about cells and smaller structures. Pretty readable but doesn't gloss over complexity.

Yeah, I guess what goes around comes around. Bad if true though.

I don't think the author is missing this distinction. It seems that you agree with him in his main point which is that companies bragging about LOCs generated by AI should be ignored by right-thinking people. It's just you buried that substantive agreement at the end of your "rebuttal".

Between this and the debate about ideal method length with Ousterhout, my respect for Uncle Bob is plumbing new depths.

This is a cool idea. I wish something like this existed for C#.

Lots of good observations in this article. I think that barring the possibility that LLMs become able to generate perfect, bug-free code, the question of how AI-generated code can be integrated with TDD is an important one. And as the author correctly points out, simply having the AI generate tests in addition to code is not the answer.

It's not a paradox, because there is nothing logically inconsistent in my definition, unlike the Berry paradox.

Whatever largest number you can express in your system, I can represent a larger one in only one bit, using the following specification.

0=your largest number 1=your largest number + 1

Feels like the answer is probably uncertainty about inflation?

It depends on the specifics of what was said. As the complaint states, OpenAI has yet to release the full transcripts.

Encouraging someone to commit a crime is aiding and abetting, and is also a crime in itself.

Perhaps it would be useful to define what we mean by "commoditization" in terms of software. I would say a software product that is not commoditized is one where the brand still can command a premium, which in the world of software, generally means people are willing to pay non-zero dollars for it. Once software is commoditized it generally becomes free or ad-supported or is bundled with another non-software product or service. By this standard I would say there are very few non-commoditized consumer software products. People pay for services that are delivered via software (e.g. Spotify, Netflix) but in this case the software is just the delivery mechanism, not the product. So perhaps one viable path for chatbots to avoid commoditization would be to license exclusive content, but in this scenario the AI tech itself becomes a delivery mechanism, albeit a sophisticated one. Otherwise it seems selling ads is the only viable strategy, and precedents show that the economics of that only work when there is a near monopoly (e.g. Meta or Google). So it seems unlikely that a lot of the current AI companies will survive.

I guess I'm lucky not to have worked at a place with a role for software architects who don't actually write code. I honestly don't know how that would work. However, I think I can appreciate the author's point. Any sufficiently complex piece of existing software is kind of like a chess game in progress. There is a place for general principles of chess strategy, but once the game is going, general strategy is much less relevant than specific insights into the current state of play, and a player would probably not appreciate advice from someone who has read a lot of chess books but hasn't looked at the current state of the board.

Inheritance is not necessary, but then very few programming constructs are absolutely necessary. The question is does it help program clarity or not. I think that in some cases, used sparingly, it can. The main danger of inheritance is not that it is OO, but that it is not OO enough. It breaks encapsulation by mixing properties and methods between base classes and derived classes without clear boundaries. Composition is safer because it preserves encapsulation. In general, I think that protected abstract methods are a code smell, because they usually indicate close coupling of details that should be kept separate between the base and derived classes. But used correctly, inheritance can be more succinct and convenient.

Two of the three Starbucks locations in my home town removed all of the seating. Across the street from one of them, an independent coffee shop opened up with lots of seating. Whenever I walk by the Starbucks is empty and there are a lot of people inside the independent shop. I have to wonder about their strategy.

The Starbucks near me doesn't even brew coffee any more. They switched to these automatic machines that "brew" a cup in about 15 seconds (ie. vending machine quality). Its undrinkable now. In future would only order espresso drinks or cold brew.

I had a similar issue recently. I used the Windows Photo app to import & delete photos from my iPhone. When it finished, I realized that a significant fraction of the photos had been corrupted. Not sure where in the pipeline it happened, or if they were already corrupted on the phone.

It would be interesting to explore further why this topic is still so sensitive for a lot of people, and why the metaphorical talk is still so appealing. I feel like the reasons given in this article couldn't alone explain its enormous staying power (even to this day).

The problem itself is at least centuries old, if not millennia. In his "Essay Concerning Human Understanding" (1689), John Locke phrased the same problem clearly, using different words:

"How any thought should produce a motion in Body is as remote from the nature of our Ideas, as how any Body should produce any Thought in the Mind. That it is so, if Experience did not convince us, the Consideration of the Things themselves would never be able, in the least, to discover to us." (IV iii 28, 559)

What with this and your previous post about why sometimes incompetent management leads to better outcomes, you are quickly becoming one of my favorite tech bloggers. Perhaps I enjoyed the piece so much because your conclusions basically track mine. (I'm a software developer who has dabbled with LLMs, and has some hand-wavey background on how they work, but otherwise can claim no special knowledge.) Also your writing style really pops. No one would accuse your post of having been generated by an LLM.

Exactly. In many organizations this is a coordination problem at the organizational level, not an individual lack of initiative. I imagine if someone looked at an army, they would say, hey these guys are just polishing their boots, and filling out paperwork and doing meaningless tasks, why does the military pay their salaries? Well, you need those people there to be ready when the war breaks out. The same thing often happens in corporations.

If you click through to the breakdowns by gender, you'll see the despair numbers are actually higher in young women than in young men. So this isn't a male-only issue.

Well, it's an interesting question. I'm not sure we really know what "thinking" is. But where the rubber meets the road in the case of LLM agents is whether they can achieve the same measurable outcomes as a human agent, regardless of how they get there. And it seems not at all clear how to build those capabilities on top of an admittedly impressive verbal ability.

I don't want to blame Alan Turing for this mess, but his Turing Test maybe gave people that idea that something that can mimic a human in conversation is also going to be able to think like a human in every way. Turns out not to be the case.

Maybe it's too soon to say that autonomous LLM agents are the wave of the future and always will be, but that's basically where I'm at.

AI code completion is awesome, but it's essentially a better Stack Overflow, and I don't remember people worrying that Stack Overflow was going to put developers out of work, so I'm not losing sleep that an improved version will.

Hard to justify the valuations of these companies based on the potential market for what is essentially an IDE plugin.