|
Thread: Comments for: "Real men program in C"
|
|
|
Posts:
2
Registered:
08/06/09
|
|
|
|
Re: Comments for: "Real men program in C"
Posted:
Aug 6, 2009 2:31 PM
in response to: Caprica
|
|
|
|
Brad,
Nope - I just go there to integrate instruments and watch them launch. NASA (wisely, IMHO) chose a bunch of Arizona desert rats to go to Mars and find the water.
|
|
|
Posts:
1
Registered:
08/10/09
|
|
|
|
Re: Comments for: "Real men program in C"
Posted:
Aug 10, 2009 1:03 PM
in response to: Caprica
|
|
|
|
I can also see where DaveArmour is coming from but the days of an embedded application being programmed,shipped and never heard from again are coming to an end. Be it changing settings or calibrating what equals nicely browned on that toaster more and more embedded applications need to have some communication with the outside world. For me that means also having to know and use higher level languages like C# a Java (among others) to easily (as compared to a pc app in C) develop a GUI to interact with the device.
|
|
|
Posts:
2
Registered:
03/17/08
|
|
|
|
Re: Comments for: "Real men program in C"
Posted:
Aug 10, 2009 4:09 PM
in response to: Caprica
|
|
|
|
I think part of the reason a younger generation of software engineers is not attracted to embedded software (and hence C) is the lack of money/prestige. I have been stunned to see some job postings lately that require years of embedded software expertise/medical device control expertise/etc. and the pay rate is $30/hr! If a software engineer coming out of school can go to Google et. al. and get a hefty salary, a very cool reputation and stock options, why are they going to go into a more meticulously demanding job that requires embedded design skills? Companies that need embedded software engineers need to value them appropriately and make these jobs more attractive.
|
|
|
Posts:
11
Registered:
12/05/08
|
|
|
|
Re: Comments for: "Real men program in C"
Posted:
Aug 10, 2009 4:31 PM
in response to: Caprica
|
|
|
|
It appears my earlier comment got lost, so if this is just reiteration, please forgive me!
My comment was that we might want to consider adding a new termo the embedded universe, something like, "Complex Embedded" to describe systems or applications that require (or uses) processors or other sufficiently complex logic that require or are best programmed by higher-level, perhaps OO languages. For example - my Atmel 8-bit designs are all done in C, not because it's the only language available for the Atmel AVR's (assembler & Forth are others of which I'm aware)but because it's readily available, has a high-enough level of abstraction to make many functions easy to write, but enough hardware manipulation to handle the basic peripherals of the device. When I wrote a Windows GUI-based configuration application for one of our electronic advance ignition systems, I used C#, because it was a good fit for that kind of system. I think that we have reached the point where we need to start differentiating the complexity/memory/cpu aspects of embedded systems before asking the question about what language we use in writing the software. New terms, anyone?
|
|
|
Posts:
2
Registered:
07/17/08
|
|
|
|
Re: Comments for: "Real men program in C"
Posted:
Aug 10, 2009 5:13 PM
in response to: Caprica
|
|
|
Interesting article!
I've some points to make -
1. How did you arrive at the Figure-3? Could you provide the sources?
2. "Unfortunately, on-the-job learning is also poorly organized in embedded software."
- I strongly believe this point. When I joined the embedded domain as a fresher, I was throwed in to this domain, asked to write some drivers in VxWorks; then I moved into other RTOS's & finally into Firmware without any OS, mainly 802.11 MAC firmware. I never got a chance to work on Linux. I know I could have (& should have) learned a lot about the Linux kernel if I had the zeal. But somewhere I missed it. Recently during a job interview I got a feedback that meant something like this - "9 yrs of experience & you don't know Linux kernel?? Man .. you're a piece of you-know-what!". So, I've lately installed Linux on my PC & started writing a driver from scratch.
I wish somebody advised me to have a peek inside Linux kernel, back when I started in this field.
3. "Although they are smart and talented computer scientists, my younger friends don't know how to competently program in C. And they don't care to learn."
- I don't quite agree with this. As time has progressed, customers are demanding higher throughput, better stability. Based on the hardware design, you (as a software developer) are expected to deliver a certain amount of performance in your driver/firmware. If you can't do that, you lose your job to someone who can. This barely leaves any scope for "not caring to learn" your language - C.
Also, going by your statement, code written some 10 years back were better than code written in new products running in the market now? No offense meant but I don't quite agree to that. |
|
|
Posts:
1
Registered:
04/09/09
|
|
|
|
Re: Comments for: "Real men program in C"
Posted:
Aug 11, 2009 8:29 AM
in response to: Caprica
|
|
|
|
Michael Barr raises a good point. Teaching Java/Python/Ruby/TCL,etc. does not teach computer engineering. They may be useful for many tasks, but they let the student avoid really understanding what the computer is doing. They teach how to get something working quickly by trading off speed and size. In this day an age when nearly every technical professional can program (Astronomers/Astrophysicists, Structural Engineers, Civil Engineers, Mathematicians, Chemists, Biologists, Cryptographers, etc.) computer professionals need to do better than hack out code in "some high level language" to earn their daily bread. As a profession all about the tool (computer) they need to be experts in the tool and able to write the foundation that makes efficient use possible for others. They also need to be able to go as deep as necessary when things go badly with all those nice abstractions. So, if you aren't a deep expert in computers then how are you in any way more than just an assistant to those professionals who have a deep knowledge of their own expert field, plus can do your job too? IMHO, if you can't explain in detail what happens from 'printf("Hello, world\n")", all the way down to "fetch, decode, execute", then you either need to find it out, or accept the fact that your job may vaporize as soon as someone figures out how to encapsulate your limited knowledge into a GUI builder or wizard. Remember all those folks with degrees in English and Art getting $150K a year in 1998 doing html coding? Remember how they talked about the "old" economy and how they were part of the "new wave of computer scientists"? Remember how they got canned in 2001 as soon as decent web design software came out and the economy took a dip? Get ready to update your resume.
I phone screened 110 "Senior Embedded Software Engineers" to get 5-6 who could competently answer "A 'C' Test: The 0x10 Best Questions for Would-be Embedded Programmers". Note that it shouldn't be possible to graduate from a reputable CS curriculum without being able to answer these questions.
|
|
|
Posts:
11
Registered:
08/11/09
|
|
|
|
Re: Comments for: "Real men program in C"
Posted:
Aug 11, 2009 11:09 AM
in response to: Caprica
|
|
|
People don't use C because it's a good language, people use C because it is the least evil option. For embedded realtime systems you really only have the choises listed: C, C++ or assembler.
Assembler will of course be used at some extent "inline", but to write whole programs in it is not an option if you want portable code. At the escalating pace in which the silicon industry plops out new processors, one can almost be certain that the program will live longer than the processor. Portable code is a must in the embedded world, therefore we need high-level languages. Private encapsulation is another good reason why.
I can come up with a few advantages of C++ over C in embedded systems, namely stronger type enforcement, exception handling, standardized inline asm, standardized inlining (C does not have this because nobody but the ISO C committee programs in C99).
But the disadvantages weight heavier in my opinion:
- Horrible, unnecessarily complex syntax. C++ is perhaps the least readable programming language of them all. Compare the syntax to Java or C# and you will grimace at the C++ syntax.
- Potential for very inefficient programs through inheritage, templates, STL etc. STL classes will enforce a heap when we don't need/want one.
- Utterly few fully compliant C++ compilers for embedded systems exist. Many claim they follow the standard, but they almost certainly forgot to implement one detail or another (who can blame them, there are so many unnecessary features). But because of this, C++ programs are very hard to port. Wasn't portability why we wanted a high-level language in the first place?
Object orientation is no good argument. The only part of object orientation that is a must-have in embedded systems is private encapsulation.
C supports this nicely enough with static variables declared at file scope. Initialization through constructors is not something you desire, in fact you will want to avoid this for security reasons and for reduced bootup time.
Also, the most moronic ingredients of C, like for example macros and the way integers are implemented, are not fixed in C++. So stick with C til something better comes up. Maybe some day there will be a deterministic language with fixed integer sizes. |
|
|
Posts:
8
Registered:
03/20/08
|
|
|
|
Re: Comments for: "Real men program in C"
Posted:
Aug 12, 2009 1:56 AM
in response to: Caprica
|
|
|
|
Bit funny but it is true. Often I love to program in C when I start a new algorithm development project. Few days might go on how to create data flow and kind of things and start coding in Scilab instead of C. When I code in Scilab, I love to keep C like code flow such that my fellow friends does not have problem when they take my Scilab script and move on to C. Some one ask why do I do this kind of long way journey?. Yes often world is not the one we like to have. For example, C is good language and gives option to write efficient code that can run on multiple hardware platforms. But look at headache it provides to fellow developer. To start with it does puts brake on fast thinking brain when they want move along algorithm development with more concentration on data flow rather then issues to keep track of things in C language. Another one which is very painful headache for Algorithm developers is that “till today there does not exist good development environment IDE in which Data flow debugging can be done with ease by using graphs and other associated mechanisms” . In Scilab, we don’t have the above two headaches ( not fully zero but tending to zero) and makes algorithm development person very efficient in terms of time and obtained result. Thus, in my view we need brand New Tool that can provide Scilab like easy and C like efficiency. Shall we fund a new company to create such a tool?. May be we need to name that as AlgoC.
|
|
|
Posts:
1
Registered:
08/13/09
|
|
|
|
Re: Comments for: "Real men program in C"
Posted:
Aug 13, 2009 6:49 PM
in response to: Caprica
|
|
|
|
Real men only program in two languages and they both begin with A, Assembler and Ada. Why don't you see more non-military systems developed in those languages? Cause there aren't enough real men out there to go around.
|
|
|
Posts:
8
Registered:
11/29/07
|
|
|
|
Re: Comments for: "Real men program in C"
Posted:
Aug 17, 2009 8:15 AM
in response to: WJT
|
|
|
|
I see a Bell Curve forming.
|
|
|
Posts:
1
Registered:
08/17/09
|
|
|
|
Re: Comments for: "Real men program in C"
Posted:
Aug 17, 2009 5:54 PM
in response to: Caprica
|
|
|
|
I'm saddened to see an article effectively saying programming in C is no place for a woman (clearly she should stick to the home!)
With a bit of though the title could have read "Real People Program in C" and the phrase 'That "real men program in C" is part of a lingo he and his fellow computer science students developed'
should have read:
'That "real men program in C" is part of a sexist lingo he and his fellow computer science students developed to keep women out of the profession'
|
|
|
Posts:
65
Registered:
10/25/07
|
|
|
|
Re: Comments for: "Real men program in C"
Posted:
Aug 18, 2009 12:54 PM
in response to: Dave2112
|
|
|
|
The "real men" isn't intentionally sexist. It's tongue-in-cheek. Ever heard of 1982 book "Real Men Don't Eat Quiche" (http://en.wikipedia.org/wiki/Real_Men_Don%27t_Eat_Quiche) or the famous article "Real Men Don’t Use Pascal" (http://practical-tech.com/entertainment/real-men-dont-use-pascal/ )?
|
|
|
Posts:
1
Registered:
08/18/09
|
|
|
|
Re: Comments for: "Real men program in C"
Posted:
Aug 18, 2009 1:17 PM
in response to: Caprica
|
|
|
|
Dear Mr. Barr, I am an embedded software developer for the Canadian Space Agency. C is our language of choice. I am not sad to see Assembly go, but it will always remain useful in certain situations. The only reason we won't go for C++ is as D_Lundin mentioned: lack of fully-compliant compilers.
Just wanted to say I appreciated reading your article.
|
|
|
Posts:
2
Registered:
08/20/09
|
|
|
|
Re: Comments for: "Real men program in C"
Posted:
Aug 20, 2009 8:54 PM
in response to: D_Lundin
|
|
|
|
I disagree that "macros .. are not fixed in C++."
Template functions take care of the vast majority of cases where one would be forced to use a macro in C,
in both a more typesafe manner and without the dreaded namespace pollution of macros.
As for efficiency, you generally don't pay for what you don't use - although you may need to tell the compiler to not generate code for exception handling and/or RTTI if you truly can't afford them. That said, I've found that it's the programmer, not the implementation language that drives an application's ultimate efficiency.
I'm curious about the reference to security as a potential downside of constructors. On the flip side, I'd argue that C++ features such as constructors can increase the safety of code see http://hissa.nist.gov/sw_develop/ir5769/ir5769.l.html, to ensure that variables are initialized to a reasonable state. And C++'s destructors allow one to implement RAII, virtually eliminating the chance of resouce leaks - here I'm referring to not just memory leaks, but "leaks" of mutexes as well.
|
|
|
Posts:
11
Registered:
08/11/09
|
|
|
|
Re: Comments for: "Real men program in C"
Posted:
Aug 21, 2009 8:35 AM
in response to: Bill E
|
|
|
Regarding macros:
While there are better ways to solve things in C and C++, macros are still allowed. The only reason to use macros in ISO C 9899:1990 is portable inlining of functions, a minor concern as modern compilers handle this automatically.
In C99 and C++ I can't think of a single reason to use them. Yet people use them a lot, because they don't know better. There is a tendency of thinking "the language allows it so it can't be bad", or worse: "the language allows it so I'm gonna use some alien, impossible-to-interpret syntax to show off my syntax knowledge".
Regarding constructors:
In safety-critical systems, it is considered poor practice to rely on initialization values. This isn't because of the language, but because of the unreliable nature of RAM. In such systems, there could be days, weeks or years from the point of initialization to the point where the variable is used. If you rely on the initialization values, you leave the safety in the hands of the RAM manufacturer. If you instead leave the initialization constants in NVM as long as possible and set variables in runtime, before they are used, you get increased safety.
Also, in typical safety-critical systems you have no memory leaks at all, as dynamic allocation and heap usage is completely banned. Mutex leaks aren't too common either, as threads/processes tend to exist during the whole program execution. Anything getting created & deleted dynamically is a potential hazard.
In non-critical systems, there are typically no policies for the above and programmers are left to goof around with the RAM as they see fit. Hence the need of various design patterns, smart pointers etc in such systems. I would whole-heartedly agree that constructors/destructors will increase safety drastically in any system allowing dynamic resources. |
|
|
|
|
|
|
