From my quick skim, the book is quite light on proofs, which I think is a big mistake for intro calculus classes. Proofs are usually what you need to get a solid feel for the material, at least at the start. Developing intuition on how things work by playing around with Julia, and using that to inform exploration to come up with theorems, and using that data to help develop a proof would be a more interesting approach. Maybe they do this in later chapters. For example, when teaching eulers method for integrating the ODE, visually graphing the error compared to the actual as step size changes could give the reader some intuition about the order of the method.

Also arrays aren't pointers in C, they decay into pointers. You can see this since sizeof will work differently in the function that instantiates the array versus one that takes in the pointer as a parameter.

I hope they take a look at using a penalty based solver in the future, especially for their GPU sim, could really contend with MuJoCo/Genesis as the robotics sim engine.

They believe this despite the fact that there are a million different textbooks, all explaining the same concepts in different ways, or different branches that specify the same structures with unique methods. It's really strange when I read threads like this. I'm not the greatest at math either, but that's because it's a hard thing to be good at.

To learn math is an exercise in humility. You must struggle hard, do hundreds of problems, spend years refining your understanding, redoing proofs, finding counter examples, just to be at a good undergraduate level. Much harder than pretty much all CS classes, except maybe Theory of Computation, which is pretty much math.

I agree that Canada and the EU should've been more responsible for their own defense. Hope going forward they are and cut out the USA as much as possible.

Will the Canadian job market improve or suffer here? Does anyone know of any research that will determine if this would be beneficial for Canadians? Naively, I think it'll be harder to compete with Europeans for jobs.

Yea that's why I started my comment with "it depends on the person", in response to you asking what's not fun about having AIs do what you tell them. For many, coercing a tool to do something you can likely do yourself better isn't ideal, and at least for me, is just inefficient use of time (in the long run) and a headache. It also zaps the fun out of any task since now you move from searching for a good solution using your priors, to now validating that the LLM has a solution that works, even if it's not optimal. The searching for a good solution is for some, the fun part, which is eliminated by agentic coding, since that search inherently relies on you writing code and seeing what works IMO. The coding is an essential part of the thinking here. An analogy would be doing a math problem by hand versus reading the solution in a textbook. I can give concrete examples if you'd like.

For your SVG examples, I have used AI for a similar use case, the construction of 3D scenes for robotics via a text prompt and an asset catalog. I wish I could get the same richness as your SVG examples, the LLMs fail too hard on all 3D tasks given, even after spending a high amount of engineering effort on a suitable harness + tools. Also like your SVG example, it often doesn't give a realistic, or even nice output, and coercing it to do so, likely takes longer than just creating the image/3D scene yourself.

Depends on the person, I never really had fun telling someone else what I wanted built or drawn. I've always enjoyed the process more than just the results, and having the results without the intellectual activity is boring.

For software, the increase usage of AI code makes my team move much faster, but our software isn't robust anymore and I fear that our longterm mission is being compromised by the endless slop. Favoring quick implementations that AI can make versus good implementations, and lazily relying on AI makes my teammates not develop a deep understanding of the work, which ultimately limits the solutions they can develop. YMMV.

Also, I don't understand what's funny about your image? Is it that it's bad?

The statement implies that the company has some secret hardware that can, or at least, is close to doing that. That would blow my mind, but the author seems to believe it.

As an aside, I believe the author is a she.

Some issues I've encountered recently at work:

- Routinely encounter bugs with the python language server, it's particularly slow when compared to using VSCode. All that snappiest disappears when finding symbols after the '.' is considerably slower than my typing speed.

- I found similar issues with C++ code bases.

- It's also so hard to debug when something goes wrong. I was trying to find out why pyright keep spinning on startup, but the "LSP logs" never show anything.

- Connecting via SSH always opens the repo in restricted mode, even though I check the "Trust all projects in" checkbox. Never happened before.

- Debugger UI is a mess. Make a run, stop the run, edit the task.json, try running again, and 2 tasks show up. One for the old and one for the new.

--

I stuck with it because I really do like the UI, the performance, and initially it seemed to be an improvement from VS Code for my workflows, but lately I've been moving back to code as it seems more stable. I don't really use agent features, so I don't think I'm the target customer for this or other priority Zed features.

I do see the usefulness of something like this, I'm interested to see if the new agentic style of programming will result in the "code" part of editors becoming second class (for the better) and will allow for more rapid development. Although I'm not looking forward to read my coworker's "threads" of how a feature was made, I have a feeling that it will be more difficult to read than the raw code, as from my experience, LLMs don't really employ terse and effective communication (might not be entirely fair, I found ChatGPT /study mode pretty good.)

--

Anyone know of a good replacement editor that might meet my usecase? I'm really a batteries included type of developer.

If the author was purposely mischaracterizing what clean code was advocating for, arguing against the weakest version of what Martin was saying was clean code, I can see that being an issue. But he took a section of the code that Martin claimed was clean code, and arguing against the provided example being good code despite it fitting Martin's idea of clean.

The book says to pick the best version, and maybe it was improper for the author to omit the other version, but even the other version has issues that the article addresses. You can use the more performant switch case version and see how omitting other principles of clean code cause gains from even that version.

Again, the claim in the article was not purely vTables vs Switch statements, there several other claims that have nothing to do with that, for example the reliance on not using internal details of a class, or DRY which appear in both the OO and procedural versions of Martin's code IIRC.

The book actually makes a stronger claim than the author's IMO. The books claim is that there are principles that make clean code, and a person should follow in order to make their code clean. The implication being that not following these rules makes your code unclean (but Martin doesn't explicitly say this iirc, so this may be too strong of a statement). Martin doesn't really provide useful metrics to back up this claim either, so its hard to tell what parts of it to take as sage advice, and what really doesn't work. The author of the article at least provides empirical data to back up the thesis, which is that this "Clean Code" has terrible performance. It doesn't matter if Martin doesn't argue that it is performant, the fact (as proven by the data shown) that the code has worse performance than other methods is enough to prove the author's claim, and is not a strawman.

He also could have showed the if-statement version, and it wouldn't have some of the performance impacts, but there's a big chunk of the article that's independent of that. There would still be performance benefits, since the article isn't purely switch statements vs vtables. It went through a series of clean-code tenets that were shown to cause performance problems. That's the authors point, performance deteriorates when following those principles. Even in real world examples this will happen, are you claiming otherwise?

I feel like everyone is just talking over the article, unless you disagree with the actual thesis, that the clean code tenets listed cause bad performance, then you don't really disagree with the author here right? You can argue in spite of the performance decrease, the clean code method is better for real systems, which is fine and I have no issues with that, but that's a separate claim you should prove, and state clearly to who ever is working on the code you're writing.

> but it was not meant as an example of high-performance code

That's part of the point, the clean-code version can't be high-performance. The tenets of it contradict how the hardware works, and causes slows down (not necessarily all the time, but it does typically.)