Why C is terrible, and Java/C# are Great

[Kirby]

Back when Java came out, only drug dealers had cell phones The Java books I was reading in the mid 90's spoke of your microwave, refridgerator and oven timer running Java. Not exactly high powered CPU's.

The idea was why should an interface as simple as a microwave require a PHD to program? (ok thats an exageration but you get the idea) I could throw together a desktop replica of a microwave controller in a managed environment in minutes. Why not build a light weight framework that allows RAD for those machines as well?

Haha, I didn't know that. I was in elementary school in the mid 90's.

So what are microwaves, fridges, and oven timers running on now? I work for the Army, and C++ is the whiz-bang new language for a lot of people. C, ASM, Ada are the prominent languages in my group (guidance and embedded stuff), and probably COBOL and FORTRAN floating around. I personally use C# for any GUI apps, but no one here uses Java for any embedded work, at least that I know of.

 

[Cogman]

Haha, I didn't know that. I was in elementary school in the mid 90's.

So what are microwaves, fridges, and oven timers running on now? I work for the Army, and C++ is the whiz-bang new language for a lot of people. C, ASM, Ada are the prominent languages in my group (guidance and embedded stuff), and probably COBOL and FORTRAN floating around. I personally use C# for any GUI apps, but no one here uses Java for any embedded work, at least that I know of.

I was under the impression that most REALLY embedded systems run on C (microwaves, ovens) as they mostly use PIC processors. I could be wrong though.

 

[tatteredpotato]

I was under the impression that most REALLY embedded systems run on C (microwaves, ovens) as they mostly use PIC processors. I could be wrong though.

I would say most are in C, however there are implementations of JVMs in hardware that allow you to program an embedded device directly in Java. I have experience with the Java SunSPOT platform that does just that; combines a Zigbee radio with a Java Processor and allows you to connect various sensors to it. All the coding for the actual device (smaller than a deck of cards) is done in Java.

 

[Train]

...snip...

Thats was one big wall of text without a point. Do I get a lecture credit for that?

 

[Cogman]

I would say most are in C, however there are implementations of JVMs in hardware that allow you to program an embedded device directly in Java. I have experience with the Java SunSPOT platform that does just that; combines a Zigbee radio with a Java Processor and allows you to connect various sensors to it. All the coding for the actual device (smaller than a deck of cards) is done in Java.

Seems like that would be something for more expensive applications. IE car braking system. I couldn't see it being the general case for most microcontroller. Though, I guess if a hardware JVM becomes cheap enough, why not?

 

[Ancalagon44]

A hardware JVM? Uh.... do you know what the VM part of JVM stands for? Ie, virtual machine? Hence, their is no physical counterpart to it.

 

[Train]

A hardware JVM? Uh.... do you know what the VM part of JVM stands for? Ie, virtual machine? Hence, their is no physical counterpart to it.

Was that a joke?

 

[tatteredpotato]

A hardware JVM? Uh.... do you know what the VM part of JVM stands for? Ie, virtual machine? Hence, their is no physical counterpart to it.

Well that's why it is no longer a JVM, but rather a Java Processor... The Java Bytecode make the instruction set of the hardware processor. I said it was an implementation of a JVM, not a JVM itself.

http://en.wikipedia.org/wiki/Java_processor

 

[Markbnj]

Anyway, this short version of all of this is what I'm sure people say every time this "debate" comes up: [Certain] people need speed. Speed requires a compiler that's smarter than you are. If your language makes you talk dumb, your compiler can't understand you, and you don't stand a chance.

It's another consistent feature of these debates that people who work in certain specialized niches with legitimate needs throw out their experiences to invalidate the general trends. I think the trends are clear and hold up in light of those specific counter-examples, and that those examples are really of vertical specializations that lag behind the leading edge of language/tool development for understandable reasons. Drivers and embedded systems were once all written in assembler. Now they are mostly written in C, and some are written in Java. High performance computing in engineering, scientific, and academic settings will eventually follow the same course.

 

[scootermaster]

It's another consistent feature of these debates that people who work in certain specialized niches with legitimate needs throw out their experiences to invalidate the general trends. I think the trends are clear and hold up in light of those specific counter-examples, and that those examples are really of vertical specializations that lag behind the leading edge of language/tool development for understandable reasons. Drivers and embedded systems were once all written in assembler. Now they are mostly written in C, and some are written in Java. High performance computing in engineering, scientific, and academic settings will eventually follow the same course.

"Eventually"? Sure.

But it'll be compiler technology that drives it, not language design.

And we're going on 50 years for HPC and scientific computing, and most of that code hasn't even been ported to C yet. So the idea it's going to suddenly be in C# any time soon isn't really realistic. "Eventually", sure, but that could mean anything.

What I don't get is why people take it so personally. Could HPC code be ported to Java? Sure. Will there reach a point where that makes sense? Maybe. Is it going to happen any time soon? No. The first two questions are opinions. The third one is -- if you know the lay of the land -- pretty much a fact. So if you accept it as a fact (if perhaps a misguided one) then you need to realize these [multi-billion dollar] "niche" markets aren't going away anytime soon, and once you accept that, then you realize that Fortran, C, whatever [still] certainly have their place.

 

[Markbnj]

What I don't get is why people take it so personally. Could HPC code be ported to Java? Sure. Will there reach a point where that makes sense? Maybe. Is it going to happen any time soon? No. The first two questions are opinions. The third one is -- if you know the lay of the land -- pretty much a fact. So if you accept it as a fact (if perhaps a misguided one) then you need to realize these [multi-billion dollar] "niche" markets aren't going away anytime soon, and once you accept that, then you realize that Fortran, C, whatever [still] certainly have their place.

I don't disagree there. I consider it to my benefit to spot trends, not defend a religious position. I doubt that any of the languages ever used since the dawn of the information age have ever really gone away.

 

[TecHNooB]

C and matlab are the only languages I can actually do significant work in...

 

[EagleKeeper]

Honestly though, You can buy a PIC32MX460F256L-80I/PT (32bit MCU) for ~$8, less for bulk.

The reason you would choose C/C++ for it any more is for the shear fact that you really don't care about creating a gui interface for your pic processor.

Now, if you are talking phone embedded systems. Thats another story. Most of them run on ARM processors. As well, they are starting to come pre-packaged with a hardware JVM. In that circumstance, Java makes perfect sense. In fact, with the android OS Java is amazing because multi platform capabilities is actually a big issue (Android isn't just for ARM processors)

What type of GUI exists in automotive and avionics systems and appliances?
Look at the amount of processors vs the number of UI in most items.
Those that have a UI are usually very sparse, text driven in most cases.
There is no need for a fancy UI and the cost of implimenting the hardware for the GUI video is not cheap compared to the CPU itself.

Embedded systems are designed based on cost and power requirements

 

[Cogman]

What type of GUI exists in automotive and avionics systems and appliances?
Look at the amount of processors vs the number of UI in most items.
Those that have a UI are usually very sparse, text driven in most cases.
There is no need for a fancy UI and the cost of implimenting the hardware for the GUI video is not cheap compared to the CPU itself.

Embedded systems are designed based on cost and power requirements

Where did I say they had to have guis? java isn't just for gui creation, it has a wide range of applications beyond making pretty guis. Because of the wide range of libraries built into java, RAD is possible without having to fiddle with extremely low level stuff.

If you have a processor that is capable of interpreting bytecode from a high level language, why not use that high level language?

[edit]I guess reading my response, it does sound like java is mainly for gui creation. And that isn't so true. The intent I was trying to get at is "Why include all the java bloat when you can just use c/c++" and then want to say that if the system already supports reading java byte code, then that is a good reason to use java for that application. [/edit]

 

[Cogman]

I just want to go on and say, that for embedded systems, java doesn't always make a lot of sense. That is simply because they are usually pretty basic (IE Microwave timer, dumb remote controls, ect) However, when the system gets complex, java starts to become more appealing.

 

[tatteredpotato]

Pretty much it comes down to if your application and platform can handle the overhead of a language like Java/C#. IMO if that's not an issue I don't see any reason NOT to use those languages.

 

[Markbnj]

Pretty much it comes down to if your application and platform can handle the overhead of a language like Java/C#. IMO if that's not an issue I don't see any reason NOT to use those languages.

That's exactly it, and that's what has been driving the trends for years. There are some specific situations where programming in a lower level language is necessary and thus more productive, but for the majority of applications now and in the future higher level languages will provide a growing advantage. Eventually all code will be managed code running in a virtual execution environment, and no code will be native and compiled to machine-specific instructions. It doesn't matter how far along that evolutionary path we are now, the career-minded programmer has to be aware of where things are headed.

 

[Cogman]

That's exactly it, and that's what has been driving the trends for years. There are some specific situations where programming in a lower level language is necessary and thus more productive, but for the majority of applications now and in the future higher level languages will provide a growing advantage. Eventually all code will be managed code running in a virtual execution environment, and no code will be native and compiled to machine-specific instructions. It doesn't matter how far along that evolutionary path we are now, the career-minded programmer has to be aware of where things are headed.

Well, You still need SOME code that is natively compiled. As well, some applications do care completely about performance those will still be natively compiled. I agree that the vast majority of applications will eventually go to a C#/Java esq system, I just don't agree that all will.

 

[Markbnj]

Well, You still need SOME code that is natively compiled. As well, some applications do care completely about performance those will still be natively compiled. I agree that the vast majority of applications will eventually go to a C#/Java esq system, I just don't agree that all will.

Eventually is a long time. You could argue that there will always be some native code creation going on at the core of future systems, but I could as easily argue that future developments in processor technology will make that obsolete as well.

I don't agree that performance sensitive applications will always need native code. Eventually they will run managed code as well. But eventually is getting closer at a somewhat slower pace these days, due to a drop-off in gains in processor throughput, memory/bus speed, etc. Some of what I envision might not happen until the next breakthrough in fundamental processor technology... but unless we nuke ourselves it will happen.

 

[Oyster]

Well, You still need SOME code that is natively compiled. As well, some applications do care completely about performance those will still be natively compiled. I agree that the vast majority of applications will eventually go to a C#/Java esq system, I just don't agree that all will.

Is that really hard to imagine though? The biggest example being Windows Phone 7 - sure, Microsoft has dealt with most of the "native" code internally, but you and I, as developers, can only target the platform using XNA and Silverlight. Will it be surprising if Windows 8 or 9 take the same path?

I am just saying...

 

[Cogman]

Eventually is a long time. You could argue that there will always be some native code creation going on at the core of future systems, but I could as easily argue that future developments in processor technology will make that obsolete as well.

I don't agree that performance sensitive applications will always need native code. Eventually they will run managed code as well. But eventually is getting closer at a somewhat slower pace these days, due to a drop-off in gains in processor throughput, memory/bus speed, etc. Some of what I envision might not happen until the next breakthrough in fundamental processor technology... but unless we nuke ourselves it will happen.

I just don't see the x86 architecture evolving to the point where it executes .net bytecode natively (I could be wrong here of course). It seems like a feature that nobody really wants.

But who knows. I'll still keep my assembly skills either way, if for no other reason then to taunt new programmers who will never learn it.

 

[Cogman]

Is that really hard to imagine though? The biggest example being Windows Phone 7 - sure, Microsoft has dealt with most of the "native" code internally, but you and I, as developers, can only target the platform using XNA and Silverlight. Will it be surprising if Windows 8 or 9 take the same path?

I am just saying...

I was just trying to point out that it is hard to see the windows OS stuff being written in a high level language (IE no native code, even at the OS level)

This is all very speculative though. If I'm wrong, it wouldn't be the worst thing in the world to happen to the computer world.

 

[tatteredpotato]

I just don't see the x86 architecture evolving to the point where it executes .net bytecode natively (I could be wrong here of course). It seems like a feature that nobody really wants.

You will most likely see assembly and C/C++ at some of the very lowest levels, however it's possible to write a surprising amount of code managed. Microsoft's Singularity research project is a good example of how future computer systems could be designed.

http://en.wikipedia.org/wiki/Singularity_(operating_system)

 

[Crusty]

I just came across a link to a post by Linus where he talks about C, C++ and those 'other' languages. I think he's pretty spot on in regards to the topic.

http://www.realworldtech.com/forums/index.cfm?action=detail&id=110618&threadid=110549&roomid=2

 

[Cogman]

I just came across a link to a post by Linus where he talks about C, C++ and those 'other' languages. I think he's pretty spot on in regards to the topic.

http://www.realworldtech.com/forums/index.cfm?action=detail&id=110618&threadid=110549&roomid=2

IDK, he seems somewhat overly attached to C over C++. The need for context should be present in file names, class names, and namespaces, not in function names IMO. So what if two classes have a "connect" function. So long as that function is in a logic spot, I don't see the issue.

Heck, he attacks the "new" keyword. Seriously, whats wrong with new? It is the best way to do automatic OOP.