Embedded Programming in decline

you're the one calling this thread a hashtag "holy war"
You definitely got this wrong.

I am the only person in this thread using the phrase "holy war", and that was in jest when referencing the classic holy war topics of tabs versus spaces and vi versus emacs.
 
I think C# does them well
I haven't worked with C#, not being someone who's in the Microsoft ecosystem, so I have no opinon.

if I wanted to learn a more systems-oriented/"native" language I'd choose Rust over Go for the reasons I outlined above

I don't think they're inherently bad, but it's pretty self-evident that for that type of development they aren't necessarily desirable for reasons of performance, which another poster also mentioned. A miscommunication isn't an affront to you.
What does "systems-oriented" even mean? Work on a large enough code base, in a language without garabage collection or its own heap allocation, and you eventually end up writing a custom heap allocator and garbage collector because it's necessary. Having done that, I'm reasonably happy with how Go has implemented GC and perfectly okay handing that part of software development life over to the runtime where other people can work on that problem. This is all in the context of financial technology systems (credit card processing, risk assessment, dashboards for transactions) if you need it to better understand my opinons.
 
Last edited:
I'm not really that old... But my understanding of some of the early computers is that memory bits were magnetic "doughnuts" that flipped polarity depending on whether they were 0 or 1.
True. Back in the '60s, magnetic core memory was king. You could look at a plane and see the donut that represented an individual bit. But I'm taking late '70s. We had solid-state RAM then. A whopping 4 KB of it.
 
You ducked my question and started to take a swipe at me. Not cool. GCs are the future, get used to liking them or get used to writing C. Or try answering my question as to why you think GCs are bad?

As for generics, they are rarely implemented well in a language. Java being the real scourge of the generics impelementations these days. And they're often misused by naive programmers who think they need to build the most extensible system first rather than the most performant system. Better to avoid them altogehter in my experience and opinion.

GC is really for inexperienced developers who don't know much about memory use. You could still get into trouble with memory use by have reference loops or otherwise hang on to data you don't need to latch to bloating the VM size. Check out Rust's memory use model, they thought long and hard about the rules and if you learn those you start thinking like a real programmer concerning memory use.

Generics are very useful, you avoid writing the same code over, and over, and over. And over. They used to be bloat with C++ until we finally got LLVM and similar systems instead of CFront.
 
For example, Google (Pike/Thompson) has close to zero interest to make the language useful for UI development. It fits their model of rewriting large chunks of the Google infrastructure in Go. In Google's case they want to focus on Flutter/Dart instead as the UI framework/language.

Kind of interesting that a large part of Fuchsia is written in C, not Go.
 
GC is really for inexperienced developers who don't know much about memory use.
Mmmkay. Going to disagree with you on that.

you start thinking like a real programmer concerning memory use.
Wow. I don't even know where to start. "Real programmer"? Okay.

I want to use a language that helps me generate code that provides value to my organization. If that's C? Great. If it's Go. Great. If it's Node. Great. Real programmers get past the language and on to building things of value. You can wax poetic about generics and garbage collection and the decline of having to track your mallocs untll the cows come home. If you aren't building software that sells, it doesn't matter if you're writing it in assembly or SmallTalk.

I'm out. Can't take the arrogance in this thread.
 
Last edited:
Mmmkay. Going to disagree with you on that.


Wow. I don't even know where to start. "Real programmer"? Okay.

I want to use a language that helps me generate code that provides value to my organization. If that's C? Great. If it's Go. Great. If it's Node. Great. Real programmers get past the language and on to building things of value. You can wax poetic about generics and garbage collection and the decline of having to track your mallocs untll the cows come home. If you aren't building software that sells, it doesn't matter if you're writing it in assembly or SmallTalk.

I'm out. Can't take the arrogance in this thread.

Memory is not free. Memory could be misused, if you don't know much about memory allocation and misuse in programs GC will not save your from bad performance. I always ask memory allocation questions when hiring SW engineers as I think it's one of the key issues all SW engineers should be aware of. Some do not even know the difference between stack and heap allocation....

Lots of commercial code out there is not using GC, Windows 10, MacOSX, Linux, Apache and so on and so on. Everything is not written in Node.js/Javascript.

As for someone thinking about using GC with realtime embedded systems................
 
Last edited:
Dumb embedded programmer here. I've worked on satellite equipment, cellphone chips, audio hardware, and now robotics. I've done some C++ stuff in the past, but I spend my days on bare metal most of the time. We do everything in house. Board design, layout, assembly, and it gets passed down to a couple of us to make it dance. It's fun enough. It is hard to find people though. It's usually some grisled old dude that is way too set in his ways to be of a lot of use. They'll print out reams of everything they can find, then mess with it for six months, and then we let them go because all they did was re-write stuff that was already working. Very difficult to find a college grad that has any knowledge of hardware.
 
Last edited:
You ducked my question and started to take a swipe at me. Not cool. GCs are the future, get used to liking them or get used to writing C. Or try answering my question as to why you think GCs are bad?

GCs are awesome. For LOB apps and anything that didn't have any hyper performance issues, I'll always go for a managed platform. But no matter how good they are, they come at a performance cost. In many (or even most) cases the trade off is worth it these days.

But the project I'm working on has very substantial parts that cannot accept a performance cost. We already have runtimes that exceed 24 hours on beefy machines and we're just getting started. We've got algorithmic work to do to improve things for sure but every improvement we make is absorbed by the project design advancing and consuming the gains. Our project designs are expected to get at least 100x more "involved". No GC platform can touch C/C++ for this. With some pretty trivial custom block allocators and placement operator new() we can partition memory very efficiently and avoid heap contention and fragmentation.


As for generics, they are rarely implemented well in a language. Java being the real scourge of the generics impelementations these days. And they're often misused by naive programmers who think they need to build the most extensible system first rather than the most performant system. Better to avoid them altogehter in my experience and opinion.

Generics are fantastic. Not sure what the hate is for them. I don't know about Java's generics - the last time I wrote a Java program, the language didn't have generics. But I've used generics in C++ and C#. In some of the early C++ compilers they did a crap job with code generation but that hasn't been true for a long time at least for the Microsoft tool chain. With link time code generation and so much refinement and specialization in the current STL libraries, the code generation is surprisingly good. I've only recently started using gcc again but it seems to do a good job with emitting good code for templates as well. With compile time expressions, templated code can generate much better stuff than if you had non-templated code with all the same capabilities. Then there's the fact that you can get type safety with generics that you cannot get type casts all over the place unless you write specializations of everything.

C# generics are very well down and extremely easy to use and get right. In addition, C# has extension methods that allow for extremely expressive type-safe code and they support generics as well. I'm not shy about calling out things I don't like that we do but I have to say that C# is really pretty fantastic.
 
Perl is great for Sys Admin work.

I've written a lot of tools, data mungers, log scrapers, web backends, etc in Perl.

Hell, back in the day before in-car MP3 players or iPods, I built my own with a motherboard, a 4MB IDE "flash disk" (it plugged right into the IDE port), a fanless 80586 chip (aka, Pentium),a 10-key pad and 3-line "smart" LCD display running on a micro Linux distro (made for running a firewall) and Perl.

Anytime I need to sift through data, it is definitely my tool of choice - the regular expression engine is fantastic.

laziness, impatience, and hubris.... I really got into perl because the humour of the camel book just made me laugh. And that you could write poetry with it and tools :)
 
laziness, impatience, and hubris.... I really got into perl because the humour of the camel book just made me laugh. And that you could write poetry with it and tools :)
Larry Wall is a trained linguist. His goal with Perl was to create a programming language with as many possible expressions such as modern English -- good or bad.
PS: interesting, didn't realize Larry Wall and I worked in the same company for a while (Unisys) in the mid-eighties.
 
Back
Top Bottom