Long time no see Friend:- "hey dude what do you do for a living"

Me:- "I suffer in silence"

Ltnsf:- " but what exactly do you do"

Me:-"I stare at a rectangular space hoping to find enlightenment"

Working in the embedded systems industry for most of my life, I can tell you methodical testing by the software engineers is significantly lacking. Compared to the higher level language development with unit tests and etc, something i think the higher level abstracted industry actually hit out the of park successfully.

The culture around unit testing and testing in general is far superior in java and the rest.

Down here in embedded all too often I hear “well it worked on my setup... it worked at my desk”.. or Oh I forgot to test that part.. or I didn’t think that perticular value could get passed in... etc I’ve heard it all. Then I’ve also heard, you can’t do TTD or unit tests like high level on embedded... HORSESHIT!

You most definitely can! This book is a great book to prove a point or use as confirmation you are doing things correctly. My history with this book was I gonna as doing my own technique of unit testing based on my experience in the high level. Was it perfect no but I caught much more than if I hadn’t done the testing. THEN I found this book, and was like ohh cool I’m glad I’m on the right thought process because essentially what they were doing in the book is what I was doing just slightly less structured and missing a few things.

I’ve seen coworkers immediately think it’s impossible to utilize host testing .. wrong.

Come to find out most the of problems actually are related to lack of abstraction or for thought out into software system design by many lone wolf embedded developers.. either being alone, or not having to think about repercussions of writing direct register writes in application or creating 1500 line “main functions” because their perception is “main = application”. (Not everyone is like this) but it seems to be related to the EEs writing code ( they don’t know wha the CS knows) and CS writing over abstraction and won’t fit on Embedded... then you have CEs that either get both sides or don’t.. the ones to understand the low level need but also get high level concepts and pariadigms and adapt them to low level requirements BOOM those are the special folks.

ANYway..the book is great because it’s a great beginner book for those embedded folks who don’t understand what TDD is or Unit testing and think they can’t do it because they are embedded. So all they do is AdHoc testing on the fly no recording results no concluding data very quick spot check and done....

If your embedded software engineers say they can’t unit test or do TDD or anything other than AdHoc Testing...Throw the book at them and say you want the unit test results report by next week Friday and walk away.

Lol

Learning Go. How I didn't learned it before? It has the efficiency of a low level language with the beautiful syntax and abstraction of a high level one.

This will definitely trigger many but the truth regardless of how you feel is the greatest programmers are those who understand both the hardware level and software .. only then are you more than a dev or programmer.. you are an engineer...

I challenge the devs who dis believe to go out and learn to build circuits, write optimized, efficient bare metal code.: no sdk.. no api... no drivers ..remove the unneeded abstraction layers that have blinded you...build it yourself, expand your potential and understanding..

Not only will you become more valuable overall, but you will write better code as you are more conscious of performance and space and physics of the physical layer.

I’m not talking about Arduino or raspie

Those who stand strong that high level abstraction languages and use of third party apis is a sufficient sustainable platform of development are blind to reality.. the more people who only know those levels, the less people pushing the industry of the low level.., which is the foundation of everything in the industry.. without that low level software the high level abstractions and systems cannot run

Why did we have huge technology advancements from 70s to early 2000s.... because more people in our industry understood the hardware layer..: wrote the software at the less abstracted layers..

Yeah it takes longer todo things at that low level abstraction.. but good robust products that change the world and industry don’t take a few week or months to build.....

Take this with what you will... I’m just trying to open the eyes of the blind developers to the true nature and reality of our industry

More high-level stuff, sweet libs, awesome frameworks and the next generation of devs complaining about bad performance and too much abstraction.

I'm thinking about what language to dive into next.
I already have a pretty good knowledge of Go and mediocre knowledge of C and Java.

So far I thought about...
1. CPP, as I need it for school and it runs on literally anything.
2. Rust, as is seems to spread and the combination of low-level, memory-safety and abstraction seems pretty appealing to me.
3. Kotlin, specifically kotlin-native, is it combines java-like high-level programming with native speed.
4. Nim, as it combines high-level techniques with c-like freedom.

What do you people recommended, or something completely else?

According to my university lecture you have clean and good code if every tiny little functionality is split into 5+ files. Gotta have an interface, factory, low level implementation, high level implementation, and at this point I don't even know what purpose the other abstraction levels have. Just end me already...

Sometimes I think of how much great and useful stuff you could learn at an university if they used time efficiently. But instead you spend years mostly just studying theoretical or very abstract topics. Whereas 80%+ of useful knowledge and skills you learn on your own.

Urgh... No exceptions in Rust annoys me. Now you only have the choice between "this didn't work please handle this error, thank you ^-^" and "you fool, prepare for annihilation". So basically if anything remotely serious happens your programs dead and there's nothing you can do about it. I don't get why people have this hate for exceptions. Everytime a new language gets made it's always either "ew it has exceptions" or "it's so nice it doesn't even have exceptions". NOOO! They can deal with serious situations in the best possible way and they can be statically checked (so no "but they're so complex and unpredicable" stuff please). If you can expect an exception they shouldn't be used in the first place (eventhough they are absolutely no less good than Option returntypes or whatever, just different) but in cases when it's impossible to predict an error they really shine. And not having them makes your language worse. If a device driver accesses illegal memory it should throw an exception, so instead of the computer shitting the bed, first the offending function has a chance to resolve the problem at it's root, then a few functions up the call stack, the general control functions of the device drivers can handle it and restart the operation if applicable, and even if the driver fails to handle it, the OS can jump in and restart the driver, log an error and do whatever. It's absolutely beautiful: This hierarchical ramp from near the accident site to more high level operations code ensures the error can be caught at the right level of abstraction without introduction a lot of boilerplate. If everything fails and nobody can handle it *then* the program or kernel or whatever can panic.

Let's do a story mapping session! Ok cool. PO asks the team: so guys what do you think? *silence*... *more silence*.... PO: come on guys, please respond. *silence*.... Then someone finally responds.

I'm starting to hate this big time. It's almost always like that, no matter the type of session (story mapping, refinement) And there's someone in the team that thinks he always knows best, so if ever someone speaks up, it will always be challenged and lead to useless discussions. He always wants the perfect solution. A good solution is good enough, it doesn't have to be perfect. PO is happy with a good solution (good = maintainable, scoring at least x on our code quality tooling), so why the fuck would you want to go for the 'perfect' solution, which may score just slightly higher in regard to quality, cost much more to develop and people have a hard time maintaining it due to the high level of abstraction? He's always refactoring stuff because it's not future proof. Well, why completely reimplement parts that have been working properly for 2 years and have a very very small chance of needing a change, which then still only needs to be done in just 1 place?

And you know what? All these fancy structures, patterns etc are in there but will their flexibility ever really be used? In my 20 years experience haven't seen such flexibility being really used. Some exceptions of course.

Once it's built, it will keep running, yes, changes will need to be made, but in most cases they never touch all these expensive fancy structured components. Just because most changes are in content or small changes in functionality.

Rubber ducking your ass in a way, I figure things out as I rant and have to explain my reasoning or lack thereof every other sentence.

So lettuce harvest some more: I did not finish the linker as I initially planned, because I found a dumber way to solve the problem. I'm storing programs as bytecode chunks broken up into segment trees, and this is how we get namespaces, as each segment and value is labeled -- you can very well think of it as a file structure.

Each file proper, that is, every path you pass to the compiler, has it's own segment tree that results from breaking down the code within. We call this a clan, because it's a family of data, structures and procedures. It's a bit stupid not to call it "class", but that would imply each file can have only one class, which is generally good style but still technically not the case, hence the deliberate use of another word.

Anyway, because every clan is already represented as a tree, we can easily have two or more coexist by just parenting them as-is to a common root, enabling the fetching of symbols from one clan to another. We then perform a cannonical walk of the unified tree, push instructions to an assembly queue, and flatten the segmented memory into a single pool onto which we write the assembler's output.

I didn't think this would work, but it does. So how?

The assembly queue uses a highly sophisticated crackhead abstraction of the CVYC clan, or said plainly, clairvoyant code of the "fucked if I thought this would be simple" family. Fundamentally, every element in the queue is -- recursively -- either a fixed value or a function pointer plus arguments. So every instruction takes the form (ins (arg[0],arg[N])) where the instruction and the arguments may themselves be either fixed or indirect fetches that must be solved but in the ~ F U T U R E ~

Thusly, the assembler must be made aware of the fact that it's wearing sunglasses indoors and high on cocaine, so that these pointers -- and the accompanying arguments -- can be solved. However, your hemorroids are great, and sitting may be painful for long, hard times to come, because to even try and do this kind of John Connor solving pinky promises that loop on themselves is slowly reducing my sanity.

But minor time travel paradoxes aside, this allows for all existing symbols to be fetched at the time of assembly no matter where exactly in memory they reside; even if the namespace is mutated, and so the symbol duplicated, we can still modify the original symbol at the time of duplication to re-route fetchers to it's new location. And so the madness begins.

Effectively, our code can see the future, and it is not pleased with your test results. But enough about you being a disappointment to an equally misconstructed institution -- we are vermin of science, now stand still while I smack you with this Bible.

But seriously now, what I'm trying to say is that linking is not required as a separate step as a result of all this unintelligible fuckery; all the information required to access a file is the segment tree itself, so linking is appending trees to a new root, and a tree written to disk is essentially a linkable object file.

Mission accomplished... ? Perhaps.

This very much closes the chapter on *virtual* programs, that is, anything running on the VM. We're still lacking translation to native code, and that's an entirely different topic. Luckily, the language is pretty fucking close to assembler, so the translation may actually not be all that complicated.

But that is a story for another day, kids.
And now, a word from our sponsor:

<ad> Whoa, hold on there, crystal ball. It's clear to any tzaddiq that only prophets can prophecise, but if you are but a lowly goblinoid emperor of rectal pleasure, the simple truths can become very hard to grasp. How can one manage non-intertwining affairs in their professional and private lives while ALSO compulsively juggling nuts?

Enter: Testament, the gapp that will take your gonad-swallowing virtue to the next level. Ever felt like sucking on a hairy ballsack during office hours? We got you covered. With our state of the art cognitive implants, tracking devices and macumbeiras, you will be able to RIP your way into ultimate scrotolingual pleasure in no time!

Utilizing a highly elaborated process that combines illegal substances with the most forbidden schools of blood magic, we are able to [EXTREMELY CENSORED HERETICAL CONTENT] inside of your MATER with pinpoint accuracy! You shall be reformed in a parallel plane of existence, void of all that was your very being, just to suck on nads!

Just insert the ritual blade into your own testicles and let the spectral dance begin. Try Testament TODAY and use my promo code FIRSTBORNSFIRSTNUT for 20% OFF in your purchase of eternal damnation. Big ups to Testament for sponsoring DEEZ rant.