jackling
Joined 5 years ago
Joined 5 years ago
What's wrong with that? Appeasing people is part of what being a community is. That's the human element. I could write a grand novel for the fun of it, but I still want people to read it and talk about it. To give me feedback, to discuss its themes. If that's taken away due to technological advancement, it's a sad thing.
It is not a binary between doing what you like because you enjoy the craft or being happy that people engage with your output. Both of those things feed into each other. An old neighbour of mine used to craft bracelets and give them away around the neighborhood. Why would she spend the additional time to walk to my apartment and hand me a bracelet? Did she only make the bracelet to get the neighbourhood's approval and didn't actually enjoy making it? Of course not. She made it cause she likes doing crafts, AND she likes people enjoying what she made.
The unfortunate part is that LLMs are addictive and they remove a lot of the complex thinking one has to do (in many cases), which lowers that community engagement that occurs in software circles.
LLMs have disrupted this. It's much easier for people to silo themselves off and fix any problem that appears, without the need of a community. It's easier for people to discuss topics via copy/pasting from an LLM versus actually having a deep understanding of the material.
You see this at work too. If I find a problem I want to solve for some personal motivation, I can no longer share with my coworkers what that problem is. Since when I do, inevitably, senior+ engineers and managers vibe code a solution. Often that solution is hacky and they expect others to fix the fundamental problems that exist.
I've come to the realization that AI code bases are effectively AI-only code bases, unless one is using AI as just a code-autocomplete, then that seems mostly fine. But most devs are using it as an end2end implementation tool, having it 1-shot full features, and then iterating on them with the agent afterwards. The amount of churn and terrible code stops the manual coder from doing anything effectively.
In my own team's codebase, I'm confident that we would actually be further along without AI, and that AI coding is a hindrance (although AI debugging seems to be a pretty good tool). It is made worse that everyone does code reviews with AI now, and it constantly gets things wrong, and when its right, it's usually for the most basic, unimportant issues (again with the overly defensive coding style). This waste the manual coder time trying to figure out if the issue its requesting a fix for is an actual problem or not.
There is a big difference IMO between someone who wants to code traditionally and one that uses AI when it comes to developing software. And this difference illustrates what's a software developer to a programmer.
I think you're right that manually transcribing to their own notebook would be better for learning, but I question how many students would actually do that. Having in a notebook at the start allows for better interactivity I think.
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.
Real world is messy. Lowering the sim2real gap is challenging. The sim above doesn't model actuator dynamics, overheating, probably doesn't model inertia correctly, joint friction, delays, etc.