Hi. I haven't been writing SN articles for a while because I felt like a poser talking all the time and building nothing. However, my current programming skillset doesn't really allow me to contribute that well. Ruby code template generation or source to source compilers or LLM translation or name a bunch of other ways to take my ruby or python and make it into a language people code Bitcoin projects with, is cool and everything, but at the end of the day, if you're contributing to a project, you really need to speak the language of the project.
For other reasons than just Bitcoin, I'm trying to learn embedded rust and math for programmers. The old heads tell me that simple programming like this can set you far ahead of the vibe coders of this era.
So, I was reading the rust documentation line for line, which didn't really work for me. You see, I operate by almost the exact opposite principles of what they tell you to do to make something "user friendly" or "beginner friendly" To demonstrate why, lets start with how we create a variable in rust
in ruby
varible_name = ["a name", 0, 0.5, [other arrays], etc]in rust
let mut a = 5;See, as far as I know, the ruby example doesn't hide anything. The rust example hides SO MANY THINGS and I absolutely must discover them all. I want a course on JUST creating a variable in verbose detail. I do not like unexplained behaviors, I do not like things being obscured.
Anyway, my goal for a toy project to help me learn rust is basically just get to the point of making my first switch statement. It would be an "AI" or at least what we used to call AI, a finite state machine.
However, and this is the tldr; I lost a little study motivation so I need you guys to tell me how much I suck so I can back with a vengeance lol.
You Suck!
... but you're awesome too because you're asking good questions that many devs don't even think of asking.
Did you try "The Rust Programming Language"?
It goes into some deeper detail on how variable assignments work, eg Variables and Mutability
"The Rust Programming Language" is what I was reading page by page, but my mind wanted answers to certain questions.
I suppose I could skip to whatever chapter seems appealing rather than reading page by page...
I do this on these types of books, which causes me to miss stuff and be an ignorant coder, because I am also too lazy to scroll back.
So honestly, if you have the discipline to keep a list of open items and work through it sequentially, that's probably better in the end. Saves trial & error later.
Layers of abstraction are a good thing, actually.
Humankind would have never come as far as we did if we were still punching holes into paper cards because assembly is an evil layer of abstraction that hides too many things
Not when your goals are "run as fast and efficiently as possible" and you're trying to squeeze as much performance as possible out of code.
Mass manufacturing to keep with your example, is great at making clothes. However, mass manufacturing has not replaced tailors.
In the era of mass code manufacturing, I'm trying to be a code tailor.