Yes, because no one conflates an engineer with a compiler. But there are people making the argument that we should treat natural language specs/prompts as the new source and computer language code as a transient artifact.
No, for the reasons given in the sibling comments: you won't want to be locked into a single model for the rest of time and, even if you did, floating point execution order will still cause non-determinism.
I'm not sure what the high-level point of the article is, but I agree with the observation that we (programmers) should generally prefer using AI agents to write correct, efficient programs to do what we want, to have agents do that work.
Not that everything we want an agent to do is easy to express as a program, but we do know what computers are classically good at. If you had to bet on a correct outcome, would you rather an AI model sort 5000 numbers "in its head" or write a program to do the sort and execute that program?
I'd think this is obvious, but I see people professionally inserting AI models in very weird places these days, just to say they are a GenAI adopter.
Thank you. I had to scroll way down to find anyone defending using SI prefixes to mean what they mean everywhere else. A decade ago, I decided to alias "du" to "du --si" and not look back. Entire countries have switched from imperial to metric units. Switching to using base 10 for RAM is really just fine.
I use the phrase "drive-by review" frequently too. As a senior engineer, I worry about doing drive-bys myself. Sometimes my gut tells me something is not quite right about the project, but I just don't know enough about the problem domain or technology/architecture choices to advise definitively.
In this case, I try to question the project owners on their assumptions and whether they have validated them. Usually this line of questioning reveals whether they have "done their homework".
This article resonates with me a lot, but as a senior engineer I would not share it in a big team setting. Even though it's correct, it's too cynical for big team morale. I think it would be worth sharing with peers or managers when discussing whether and how to intervene on a bad project.
Yes, I think this is what seems to be missed by everything I've read about Gehry in the mainstream. As I said in another post, I worked in the Stata Center at MIT for five years. It was indeed a fun space to walk around in and explore, but it failed to satisfy as a workspace.
I worked in the Stata Center for the first five years and it was just a very poor office building to work in. Even setting aside the leaks and other construction defects, individual working spaces, traffic paths, and communal spaces were not well-separated leading to a lot of distraction. There was also various useless corners due to sharp angles.
I much preferred working in the previous building, CS and AI lab building, NE43. It looked like a punch card from the outside, but had a very nice design with small offices (with closing doors) ringing a common space. The primary downside is the square footage per worker was decadent by today's standard.
Oh wait, we were talking about Frank Gehry, right? His museums looks cool but he should never have been allowed to design an office building.
Two random anecdotes: when the concept drawing were first shown to the graduate students, someone asked what the swooping walkways above the main corridor were for. The answer they gave was "lightsaber battles".
When we first moved in, there was a seminar room that made some people physically nauseous due to its sloping walls. For a time, they were trying to use masking tape on the walls to make the effect less pronounced. Some of the grad students tried to name it the "vomitorium", but the name never stuck. Fortunately,, once the room had a full compliment of chairs, furniture, and a projector screen the effect seemed to be much less pronounced.
This is yet another very good critique, but it's long past time that we stop paying attention to Uncle Bob.
Not only are his ideas about how to write software patently bad, but he is willfully obtuse when asked to provide nuance or discuss trade-offs. John Ousterhout's dialog with him, published as "A Philosophy of Software Design vs Clean Code" gave him every opportunity to think critically about his own suggestions and he just doubles down.
reply