Hacker News Reader

Comment by codehero | Hacker News Reader

When I work on an embedded system, I want as few layers between my code and the assembler as possible. Even your C compiler can produce undesirable code if you don't put the proper const, volatile qualifiers on your pointers.

The last thing I want is a layer of software and an IDE developed by a team that I can only assume has 0 embedded experience (judging by team page they are all architects or academics).

Secondly, if I handed off a work for hire implemented in this language I would not get a next assignment. There is no room for fad modelling in the established engineering trade and unfortunately I don't have the pull to start the disruption if I truly believed in it.

View on HN

There are two problematic types of engineers out there, some have no clue what they do and some have too much clue and wave their flags all over the place. You are in the second group and have probably been doing too much C for too long.

Clearly a hero.

I have to say that the sequence "errordevelopper" responding to "codehero" is quite funny. :)

So true

I really appreciate your succinct criticism of my points, you didn't need to qualify with anything but "you have been doing C for too long." I consider that a compliment.

Ask my clients how much of a problem I am and then ask them how many problems I solve. And no, I don't solve them all with C.

That's good for you! I don't personally find the tool in question exactly the most appealing to me personally, but what I am excited about is that the industry is moving on, as C is far too dated as a language and even C14 doesn't give much hope. So, as you suggested that you don't appreciate the abstarction this tool adds, would you consider Rust, as it compiles right down to machine code? Essentially Rust is much C-like in terms of basic syntax, but has expressivenes of a functional language, safety-aware compiler and a ton of other features, including the fact that it's aimed at system-level applications and one should be able to write a kernel in Rust.

We differ on our opinions of C. It may be dated for you but I can I know how to manipulate the syntax to get the desired result. Rust has been on my list of things to check out, but not use for clients. Right now all roads (from Javascript, C++, Objective-C and Java) lead to C. So when I write a library in C, I know I can use it my iOS, Android, node.js and C++ projects. I cannot say the same for Rust. I do not want to be on the Rust journey quite yet because I am still smarting from node.js. And in 2012 when I was using node.js to solve problems was when I was close to becoming a problem engineer, as you believe I am.

Rust does allow you to write a dependencyless C-abi library, without requiring any runtime or such. Hope we'll see you around at some point. :)

(It seems errordeveloper is doing exactly the same flag waving they originally unfairly lambasted you for...)

Lol, supposedly mine wasn't of the same origin. To be fair, you just broke my whole idea of the two groups of people, which indeed was a very poor attempt that by itself will fall into another group. I am going to asume codehero is a nice guy and walk away from this incredibly amusing discussion. Thank you, dbaupp, for pointing this out.

Pattern matching looks cool but I have some concerns. What is the best forum for Rust discussion? I get the feeling HN would rake me over the coals for bringing up switch, falling through case labels and of course, goto.

reddit.com/r/rust is probably the best place to have exploratory discussions.

Although, our pattern matching is a strict superset of C's switch (other than fall-through). But yeah, fall-through and goto aren't supported yet, and if we were to get them (in safe code), they may have to be restricted to preserve memory safety.

For whatever reason, CASE tools come and go but 'C' tends to be forever.

Funny you should say that because his team was hired to develop all the tools and IDEs for Siemens and their industrial systems. The tools you see on that page were developed jointly by the BMW embedded development team and I think a few government agencies. So I'm a little puzzled by your comment and your reaction to an obviously better way of developing correct and verified software using C.

Name dropping does not mean a thing and I doubt they developed ALL the tools and IDEs for Siemens' industrial systems. If they did, then they would be wise not to mention the numerous SCADA faults found in Siemens control systems. There is absolutely no way you would roll out a system like that and have every industrial product line using it. So I am little puzzled by your claim.

The thing about these systems is they attempt to prevent you from shooting your own foot by not letting you aim. Some operations (such as erasing and writing flash) require you to do dangerous things like relocating code to SRAM and running from there while your flash operation completes. The details of each platform vary: ARM code is generated in a position dependent fashion; MSP430 is not.

I am certainly not calling C the end-all be all, but it's a tough system to beat. You could convince managers that mbedder may be the way to go, but it would be an absolute boondoggle to get existing engineers to use it. (They couldn't even convince the Park-o-matic folks to rewrite their code to use it). To a "C simpleton" like me, I would not call mbedder obviously better.

I think you fear learning something new more than anything else and calling yourself a C simpleton doesn't really help your argument. Like I said in another comment when assemblers were being developed the same exact arguments were thrown around so if history is a guide then these tools are the future and the sooner you learn them the better position you'll be in.

You're as judgmental as errordeveloper; let me do the namedropping this time. I have timestamped when I started playing with certain technologies:

SVG: 2001 AJAX/Javascript: 2002 Windows CE: 2005 DirectFB: 2005 FLTK: 2006 SCons: 2007

I have been learning new things my entire career. I have wasted tons of time trying to support the "better" technology. mbedder presents a very weak case in my mind.

My question to you is how has your experience with mbedder been so far? You seem to understand its superiority. Does the code size and RAM consumption live up to your expectations?

You don't have to prove anything to me but your reaction is not rational. I don't think anyone will argue that a tool that integrates unit testing and model checking into a coherent experience is an overall win. As for code size and other matters it depends on your use-case and in this day and age I think a few MBs here and there is not going to make or break an embedded product offering especially if whoever is making that product can deliver it with less bugs.

> As for code size and other matters it depends on your use-case and in this day and age I think a few MBs here and there is not going to make or break an embedded product offering especially if whoever is making that product can deliver it with less bugs.

This statement alone disqualifies you from making any comment about embedded development and automotive embedded development in particular.

Agree

You just keep sounding that way, which doesn't neccesarly means you are that bad. It's just how you came across with your original comment ;)

Reply on news.ycombinator.com