Maybe? I think _understanding_ code is the ultimately goal, so that you can direct the effort of AI (and humans).
There's an assumption that writing code is the only way to truly understand it. That may be true... but maybe not. I think writing code is still part of the journey, but it might be a lot less writing and a lot more reading.
Either way, I think there's a bias of us gray hairs we need check at the door.
I believe humans learn by thinking through the problem, making implementations, and iterate on them. Maybe some smart guys can implement once and get a perfect result —- for example Dave Cutler famously said that he always ran the code in his head a few times before he actually ran the code on the machine.
However, for the majority of us, the common people, thinking through a problem usually doesn’t work like that. I wrote a shadow casting algorithm a few years ago and that took me half of a night to get it right. I did think through before every implementation, but each “thinking through” actually left some gaps which were only discovered by actually writing and running the code.
Now that I admit that I’m not smart enough and do not have a very big short term memory pool as some of the top guys. I have to write, run and debug the code even after thinking through the problem, and I believe that’s true for most of us out there.
And that’s why I think what OP said makes sense —- especially for juniors —- you can’t expect juniors just sit there, think through the problem, write down some pseudo code and call it a day.
It's the personal blog for a well-known Rubyist (i.e., a person who programs in the Ruby programming language). Rubyists teld to be a bit more colorful than your typical software developer (in a good way... most of the time).
I wanted to switch to Rust for new embedded project. I was looking for native RTOS, and embassy came up. But i always feel like it's hacky to me. What i want is RTOS that is similar to FreeRTOS or Zephyr.
It's not about features, i believe i am not that advance user. It's just different from the RTOS i used to work on. Most of exist C RTOS work quite similar(FreeRTOS, Zephyr, ThreadX), the difference is mostly in API and Software support arround the core kernel.
But Embassy, with different task switching mechanism, mean i need to learn another new concept, understanding the pros/cons. That is not what i want to do when busy adapting to Rust.
In my experience unless you're really at the edge you can basically just treat it like regular threads, and you'll probably run into fewer concurrency issues than you would with threads. Probably the bigger problem is just the rough edges in async rust, though they are getting filed down over time.
Personally I'm excited about these sorts of experiments. We all learn in different ways, and these sorts of techniques allow us to create "on-demand" syllabuses and lessons that fit our learning style and learning level.
It's not perfect, but I'm optimistic this will be a useful way to teach/learn in the future.
And, to be clear, I think this will be best utilized within a group/community setting. I don't think it will replace teachers or classrooms.
> Nvidia selling more GPU's at the cost of it's datacenter business is pretty close to Kodak selling digital cameras at the cost of film.
This assumes a) AI is a zero-sum game, and b) we're actually talking about on-prem AI will replace cloud-based AI. I think neither statements are true.
AI is like compute: we'll need all sorts of it, in various sizes, everywhere. I'm sure Nvidia whats to own all the workloads.
On the other hand, I do think open weight, like open source, will win in general.
It will take about 35 years for digital camera sales to reach Kodaks profit margins.
The market growing and companies raising the economy are not zero-sum. Nvidia/Kodak killing the golden goose is zero-sum. When the difference is your valuation crashes that's zero sum for the company, just not for everyone else.
My only concern is if we can limit the economic impact from lowering investments and causing a 40% market collapse circa 2008/9.
Maybe? I think _understanding_ code is the ultimately goal, so that you can direct the effort of AI (and humans).
There's an assumption that writing code is the only way to truly understand it. That may be true... but maybe not. I think writing code is still part of the journey, but it might be a lot less writing and a lot more reading.
Either way, I think there's a bias of us gray hairs we need check at the door.