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

[degibson]

From another thread...

At any rate though, I think the difference between C and C#/Java is being understated by an order of magnitude. Managed memory is a huge improvement in usability, and really....C syntax is arcane. Not quite assembly "We're only doing it this way to make sure the plebes can't understand our magic rites" arcane, but sure as hell not created with ease of comprehension in mind.

Lets discuss this.

1. What is it about C syntax that is arcane, and more importantly, what does C# and/or Java do to improve it?
2. What are the inherent advantages of the runtime, beyond memory management? (after all, there are garbage collectors for C)
3. Whatever else this discussion spirals into...

 

[Train]

Meh, this is the sort of discussion that's been beaten to death on a million forums all over the internet.

Basically it comes down to the speed of development for little or no cost to performance. (or at least thats the MAJOR factor, IMHO) Yes, C/C++ will live on and still have uses, but for the majority of development out there, managed languages offer a lot.

EDIT: sorry I'll try to address your numbered questions too:
1) nothing really wrong with the syntax, but it is OLD and has sorta been hacked over the years. Java/C# add simplicity.
2) The runtime is another layer of abstraction. It makes it easier to run the same code on different machins with different settings, different CPU's (32 vs 64 vs 128 bit), and in a lot of cases, even different OS's without needing to recompile.
3) Simplicity, Code Readability, Code Reuse, are all underated features of Java/C#

 

[Cogman]

From another thread...



Lets discuss this.

1. What is it about C syntax that is arcane, and more importantly, what does C# and/or Java do to improve it?
2. What are the inherent advantages of the runtime, beyond memory management? (after all, there are garbage collectors for C)
3. Whatever else this discussion spirals into...

1. I can't, for the life of me, see how C is arcane and C#/Java is so much better. They use essentially the same style of syntax. Heck, the standards committees have done a lot of work to ensure this (seriously). Just the other day I was watching a video about the upcoming C++0x standard, and one of the big issues they were discussing is the fact that volatile does different things in Java and C/C++. They can't change it because of its widespread usage in C/C++.

2. Really, platform independence and a large built in library are the two biggest advantages of having a runtime. Other then that... not much.

3. I would argue that platform independence is a moot issue. So what if you have to recompile your software to run it on the ARM architecture, most people don't develop for both anyways.

A runtime also introduces tons of issues, such as, getting to predict which version of the runtime platform x has. And if it doesn't have the correct version, happily installing the 25mb+ file for your 200kb program (Not such a big deal now-a-days, it was a big issue for me when I was younger and weighing the advantages/disadvantages of VB6 or C++). Or worse, the platform having a non-standard compliant runtime.

Heck, the development of the runtime is a huge issue in-and of itself. Look at how long it took Linux to get C# support (through mono). And it still isn't 100% compatible, you still often have to recompile with mono to get the program to work in a linux environment because the kernel doesn't support reading PE files (Where is the benefit if the user has to recompile anyways?)

I'm not saying that C# or java are terrible languages. They aren't. The both certainly support RAD much better then C or C++ can. However, the benefits of a runtime is often overstated IMO. A lot of the problems it is supposed to fix, aren't really big issues, and aren't always fix.

 

[Shilohen]

1. What is it about C syntax that is arcane, and more importantly, what does C# and/or Java do to improve it?

I'd say C++ is way more arcane than C. I find C syntax quite clean. One improvement that Java has over it is the lack of explicit pointer however. C# also limit pointer usages making it a bit simpler as well.

2. What are the inherent advantages of the runtime, beyond memory management? (after all, there are garbage collectors for C)

Multiplatform. As for memory management, you also have SoftReference in Java which is linked to the garbage collection, but something I have yet to see in C or other language. SoftReference is pretty much a pointer that automatically goes to null and its reference collected if memory is lacking, it's very nice for memory sensitive caches. Of course, you could always code that in C since the JVM is itself coded in C++.

3. Whatever else this discussion spirals into...

Not much else to say really, but I wouldn't discount C so fast, it does not target the same software needs. C/C++ is great for system programming and I don't see it going anywhere anytime soon, unless http://golang.org/ magically become über popular.

 

[lozina]

java/c#

it's great for business applications - especially large projects collaborated on by many developers of varying degrees of skill and who may rotate frequently.

it sucks for games

 

[Cogman]

http://golang.org/ magically become über popular.

Go makes me laugh
"..resulting programs run nearly as quickly as comparable C or C++ code."

Java produces code that runs "nearly as quickly as comparable C or C++". Heck, even python can produce code that is arguably "nearly as quickly as comparable C or C++".

 

[PhatoseAlpha]

From another thread...



Lets discuss this.

1. What is it about C syntax that is arcane, and more importantly, what does C# and/or Java do to improve it?
2. What are the inherent advantages of the runtime, beyond memory management? (after all, there are garbage collectors for C)
3. Whatever else this discussion spirals into...

Eh...right, I screwed this one up. It's C++ that's the arcane bit, though I can't say I like how you need to declare a class function in C separate from it's implementation. And the whole */&/./::/-> referencing system is awfully on the convoluted side. Removing the whole of pointers, and thus getting rid of the . vs -> dichotomy is an improvement.

 

[ObscureCaucasian]

And the whole */&/./::/-> referencing system is awfully on the convoluted side. Removing the whole of pointers, and thus getting rid of the . vs -> dichotomy is an improvement.

Right but if you want to have optimal performance you need to have fine control over your memory, which means pointers.

 

[Markbnj]

I honestly don't think some of you guys get the big picture. In that other thread there was just a little hint of elitism beginning to show it's head, and I was feeling the need to whack it with a mallet. Then I logged in and saw this post, so I'll swing my club here .

I taught C++ in the early 90's at a time when the comparison was to C. In every class there were one or two old guys who scoffed at the advantages of the higher levels of abstraction possible with the new language tools ("we can do all that in C" == "there are garbage collectors for C" - apologies to degibson).

I thought the reference to "mcprogrammers" in the other thread was inadvertently enlightening. Ray Kroc was successful because wherever you went, when you visited one of his stores, you reliably got what you asked for, at a good price.

Most of what might be characterized as "powerful" features of C/C++ are universally Bad Things from the perspective of every other consumer of programming tools/services except for the person who revels in knowing how to perform those gymnastics at the keyboard. If I am buying a house I don't value a bid higher if it comes from a guy who rips his own boards and extrudes his own piping.

The entire evolution of computer programming has progressed from lower levels of abstraction to higher, and everyone has reaped the rewards. Software is more reliable and more maintainable today than ten years ago. Games are more reliable, desktop apps are more reliable, server software and distributed systems are more reliable, and all types of software are easier to design and write. The reason for all of that improvement is the evolution of higher-level language tools and robust, standard frameworks.

Some of you are looking back a full generation (you could argue it's two) and asking "wait, is this new stuff really better?" The answer is "Yeah, it is."

 

[Markbnj]

Right but if you want to have optimal performance you need to have fine control over your memory, which means pointers.

And if you aren't in one of the very rare situations where optimal memory performance matters you're wasting time and money trying to achieve it.

 

[ObscureCaucasian]

And if you aren't in one of the very rare situations where optimal memory performance matters you're wasting time and money trying to achieve it.

Oh I definitely agree.... I do most of my programming in Java/C#, but calling C/C++ convoluted because it supports these things is just silly.

I do think the majority of Application programming can and should be done with these managed environments.

 

[Train]

java/c#

it's great for business applications - especially large projects collaborated on by many developers of varying degrees of skill and who may rotate frequently.

it sucks for games

I never really agreed with the "for business applications" or "it sucks for games"

sure maybe if your making the next Crysis, you could benifit from C/C++, but in most cases, well written Java or C# would do just fine. There were several articles on some gaming sites (GameDev maybe? cant remember) dispelling the myth that game studios prefer C/C++ for its speed. Basically they still use it because they have been using it for years, and are slow to migrate.

My company does pretty heavy graphics work. We don't do games, our apps are industrial, but we basically use game engines for the rendering. Being able to move from unmanaged DirectX to the managed versions (MDX, XNA, and now SlimDX) has increased productivity 100 fold. Do our rendering speeds suffer? Nope, actually our old C++ renderer which is still running, gets the circles run around it by our C# engines. The built in multithreading in .Net has let us do more renders, in less time, with less hardware. The old engine sucked at multithreading, the coder thought best if he had "fine grained control" pfft.

 

[KIAman]

1. In terms of syntax, Java/C# is verbose and easier to read which makes it harder to make mistakes. In terms of platform, Java/C# brought along some really good IDEs, which is a great gateway to programming and teaching tool.

2. A large existing library built by experts in their respective fields who constantly maintain (I hope) and optimize their tools. Simplicity in coding. A lot of modern coding is slapping together existing components to function how you want. Some say this leads to lazy programmers, I say lazy programmers are lazy programmers.

3. I like Marks response but I think he didn't follow through enough on why languages has progressed through higher levels of abstraction. Money drives everything, including software development. Several generations ago, storage, memory and CPU cycles were VERY expensive so it was advantageous to write very small, very efficient and fast code at the expense of long development time. Nowadays, storage, memory and CPU cycles are relatively cheap and it is advantageous to write small enough, efficient enough, fast enough code while cutting development time. The costs shifted from hardware to labor. The scale of software projects has also grown exponentially as newer hardware allowed even more possibilities. There are some really interesting books that go into detail on this, lean programming.

 

[Markbnj]

3. I like Marks response but I think he didn't follow through enough on why languages has progressed through higher levels of abstraction. Money drives everything, including software development. Several generations ago, storage, memory and CPU cycles were VERY expensive so it was advantageous to write very small, very efficient and fast code at the expense of long development time. Nowadays, storage, memory and CPU cycles are relatively cheap and it is advantageous to write small enough, efficient enough, fast enough code while cutting development time. The costs shifted from hardware to labor. The scale of software projects has also grown exponentially as newer hardware allowed even more possibilities. There are some really interesting books that go into detail on this, lean programming.

Absolutely true. We can afford managed languages because we can afford so much ram and disk and CPU, and that curve may be shallower than 20 years ago, but it's still there and still headed up.

 

[EagleKeeper]

One has to look at the platforms that are being written for.

As previously stated; the business as certain needs.
Embedded systems themselves can be split out based on capability of the hardware.

If the HW can support the overhead of the .NET and/or runtime layers; and the tools are there to use without a performance hit that is a problem; use them

The closer that something has to run to the HW for performance and speed; then the lower the language will be used.

Costs of a 32bit system are a lot higher than a 16bit system or 8bit system when comes production time. So the system designers must look at the trade offs of functionality vs cost, etc.

 

[Cogman]

One has to look at the platforms that are being written for.

As previously stated; the business as certain needs.
Embedded systems themselves can be split out based on capability of the hardware.

If the HW can support the overhead of the .NET and/or runtime layers; and the tools are there to use without a performance hit that is a problem; use them

The closer that something has to run to the HW for performance and speed; then the lower the language will be used.

Costs of a 32bit system are a lot higher than a 16bit system or 8bit system when comes production time. So the system designers must look at the trade offs of functionality vs cost, etc.

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)

 

[Kirby]

I'd be curious to see the break of embedded versus application programming, and then break down the embedded into frameworks. I would think there many non-GUI systems out there without the resources for a runtime (I know mine don't, 40MHz max and 4K of RAM, not to mention only a C compiler). Also, I wouldn't think McLanguages would be suitable for a RTOS. Memory and instruction optimization are important, thus the need for C/C++ or ASM.

 

[Train]

I'd be curious to see the break of embedded versus application programming, and then break down the embedded into frameworks. I would think there many non-GUI systems out there without the resources for a runtime (I know mine don't, 40MHz max and 4K of RAM, not to mention only a C compiler). Also, I wouldn't think McLanguages would be suitable for a RTOS. Memory and instruction optimization are important, thus the need for C/C++ or ASM.

One of the original applications of Java was to run on embedded platforms. I'm pretty sure it still has a foothold there on a lot of low powered (non Real Time) devices.

 

[Kirby]

One of the original applications of Java was to run on embedded platforms. I'm pretty sure it still has a foothold there on a lot of low powered (non Real Time) devices.

I know it does on phones, but I know the average cell phone can run circles around some of the stuff I work with.

Isn't it something like 98% of computing devices are embedded? Surely most of those aren't whiz-bang phones running Java.

 

[degibson]

... I taught C++ in the early 90's at a time when the comparison was to C. In every class there were one or two old guys who scoffed at the advantages of the higher levels of abstraction possible with the new language tools ("we can do all that in C" == "there are garbage collectors for C" - apologies to degibson). ...

While it is true that I tend to take a more C/C++-centric view than some of the other forum participants, I genuinely fail to understand the appeal of certain languages. I mean no genuine disrespect -- I call them McProgrammer languages in jest. I say again: I genuinely do not understand what is so inherently better about them.

As I said in the other thread, Turing complete languages are functionally equivalent. Therefore, we must judge them based on other criteria, e.g., ease of programming, level of abstraction, etc. That's fine -- and I'm interested to hear what others think of 'higher level' languages.

Contrast that with what others think about libraries, APIs, and frameworks. Sure, a lot of the newest and best are language-specific. Thats an artifact of where those libraries/APIs/frameworks come from.

I entirely understand how languages that are much higher languages than C/C++ are more productive. Python, Ruby, etc., put amazing power into very few lines of code -- as part of the language. What I don't understand is how slightly higher languages are perceived as more productive languages. From my meager understanding of them (a tiny bit of Java, no C# except debugging one application to get it to compile), the nicest features seem to come from libraries -- not inherent parts of the language.

... which leads to my comment about garbage collection. That is an inherent part of the language. Its swell, too. But is that the difference? I've simply never been bothered by free() and delete. I actually found it a lot more reassuring when I switched from Java to C, to actually know what the heck was going on.

Lastly, addressing the cross-platform appeal, I tend to agree with the pessimistic side of that argument. The idea is great, but the reality of differing versions of the runtime or VMM, inconsistent optimizations across targets, etc., starts to make the cross-platform argument lose its luster.

 

[Markbnj]

I entirely understand how languages that are much higher languages than C/C++ are more productive. Python, Ruby, etc., put amazing power into very few lines of code -- as part of the language. What I don't understand is how slightly higher languages are perceived as more productive languages. From my meager understanding of them (a tiny bit of Java, no C# except debugging one application to get it to compile), the nicest features seem to come from libraries -- not inherent parts of the language.

Did you consider C++ a slightly higher-level version of C? I suspect I know what your answer would be, and I think that's where we disagree. I believe you're focusing too much on similarities of syntax and usage.

In my view C++ represented a seismic shift in the level of abstraction available to people already familiar with the syntax of C, but that shift was incomplete. We didn't have the resources that we have today, and so it was taken for granted that C++ should build on the foundations of C. That worked great for a long time, but even when it was working great we all knew that it was too hard to write correct C++. As software expanded into more and more markets, with the developer base growing by orders of magnitude worldwide, and as the software itself grew ever more complex, that situation became untenable.

Java and C# are both attempts to take that same family of syntaxes (if you will) to the next stage of development, and I think they are both once again seismic shifts in the toolset. I have done Java development, but I can't really speak to that world. There are a lot of key differences between C++ and C# syntax, obviously, and we could discuss those all night, but in the end it's essentially what Java is: C-like syntax and superficially C++-like structure, with all the unmanaged messy bits removed. No multiple inheritance, no declarations in static or global scope, no separation of declaration and definition, etc.

Those things are a step in the right direction, as I think most people who've had to maintain other people's production C++ code would agree. But here's where I think you can't just focus on the language. It's meaningless. The real power of using C# is the power of CIL running on the CLR. It's RTTI and reflection, dynamic binding of assemblies, better support for localization and version control, and finally and perhaps most importantly, the .NET framework itself. As much of a mess as it is in places, and as weird as the choice of name obviously was, it represents a really pretty damn brilliant strategy for moving development for 100 million+ systems off a creaky old procedural API and onto a managed framework.

It makes writing good Windows programs easier, and that's the bottom line. I don't know how C# or Java can be evaluated without taking the whole foundation on which they rest into account, because it's that foundation that provides all the capabilities, not the symbols and rules. And in that sense you can hardly say that C# on the CLR/Framework is "slightly higher" than C++. As a package it's a big deal.

 

[Train]

I know it does on phones, but I know the average cell phone can run circles around some of the stuff I work with.

Isn't it something like 98% of computing devices are embedded? Surely most of those aren't whiz-bang phones running Java.

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?

 

[scootermaster]

Debates like this always crack me up because you have, like, IT people talking about how C sucks and programmers are lame, and then you have software dev. people talking about how C sucks and, but occasionally it's useful, but really we should use Java, and then you have old-timers talking about how "back in my day, we programmed with 0s and 1s, so I love C" and then you have tech geek/snobs talking about how anyone who doesn't use Emacs is lame, regardless of what they program in, and then you have....

And most of the time, each group's representative has no clue the other groups exist, or, at best, will make some cursory nod to them -- solely in order to look "enlightened" -- and then go on acting like they don't know they exist ("Well, I'm sure somebody needs explicit memory control, but these days....").


A CHALLENGER APPEARS!

No really...allow me to enter a discussion I know little about and care about even less, because it provides a welcome respite from trying to decipher arcane C++ syntax (while we're on the subject, go here http://forums.anandtech.com/showthread.php?p=29954908&posted=1#post29954908 and help me sort through templates, macro expansion, and a bunch of other stuff I "learned" 12 years ago but don't remember).

I'm an academic.

(And yes, I can hear you groaning now)

Not only am I an academic, I work in the HPC world. So, yeah, you can guess where I'm going to toss my hat here.

I program in Fortran, occasionally. And not the friendly kind; the "OMFG YOU DIDN'T PUT THAT IN THE RIGHT COLUMN I'M GOING TO KILL YOUR FIRSTBORN" kind.

In my world, RAM is the devil. If you can't find what you're looking for in the cache, you already lost. Now, obviously my world has nothing to do with Windows or database management, it has nothing to do with MVC design, it has nothing to do with x86 assembly and it has nothing to do with programming a virtual girlfriend in Python.

So, frankly, as far as I'm concerned, you're ALL crazy.

But really...the high performance computing world doesn't even know what C# is, and thinks Java is something Al Gore invented between inventing the Internet and global warming.

Personally, however, I'm all for abstraction. Hell, I once had to program a lambda calculus interpreter in ML. Ever do that? If you haven't, here's a reasonable facsimile: Take a sledgehammer, and whack yourself upside the head with it. When you awake from your coma, 2 months later, you will have accomplished approximately as much as someone who's programming a lambda calculus interpreter in ML.

The reality [for me and my universe] is that any sort of language that doesn't allow for a highly optimized compiler (a HA! His true colors shine!) isn't really interesting or worth worrying about. So regardless of whatever syntax you have, if you can't get your point across enough to the compiler so it can do its strange and wonderful voodoo, then what you're doing must not be all that important, and you could program it with Napier's bones and it'll probably run okay. Which isn't a bad thing. There's nothing wrong -- in fact, there are plenty of very right things -- with code that can be quickly written, modified and distributed/maintained, even if it can't be highly optimized.

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.

Sometimes this is okay, and sometimes it's not, it's a simple as that.

 

[dinkumthinkum]

Please. If you can't program a lambda-calculus interpreter in ML, then you barely deserve to call yourself a programmer. And an academic? Seriously? That's pathetic. I hope you don't mean Computer Science. Java-monkeys at least have some excuse.

Lambda-calculus is the simplest system that could be called a programming language, and ML is quite nearly the ideal language to write things like interpreters and compilers in short order. It's the most trivial exercise. And you could learn a thing or two about how functional programming makes parallel and distributed programming easy. Google certainly has learned that.

I have a hypothesis that FORTRAN destroys the brain, and you are a data-point in favor of it.

 

[scootermaster]

Please. If you can't program a lambda-calculus interpreter in ML, then you barely deserve to call yourself a programmer. And an academic? Seriously? That's pathetic. I hope you don't mean Computer Science. Java-monkeys at least have some excuse.

Lambda-calculus is the simplest system that could be called a programming language, and ML is quite nearly the ideal language to write things like interpreters and compilers in short order. It's the most trivial exercise. And you could learn a thing or two about how functional programming makes parallel and distributed programming easy. Google certainly has learned that.

I have a hypothesis that FORTRAN destroys the brain, and you are a data-point in favor of it.

For the record, I've never called myself a programmer. In fact, I hate programming. I'm exceedingly poor at it. What I am, however, is a scientist.

Yes, a computer scientist.

And yes, for whatever reason, that seems to make techies/IT people/codemonkeys/Software Engineers and just about everyone else uncomfortable at best, and bitter or upset at worst. I'm not sure which you are, but I'm sure it makes you infinitely more qualified to discuss the topic than I. Which was kinda my point. Not that things like "points" are particularly germane here.

Moving on....

I'm not sure what's pathetic about me being an academic, but I'm going to guess you're referencing my poor programming skills/knowledge (?). Assuming that's true, I wouldn't worry so much about it. I know brilliant biologists who barely can work a microscope. Or, better put, and at the risk of putting too fine a point on things, I know brilliant computer scientists who don't really know how to program. I don't quite count myself among them [yet], but hey, the night is still young.

My point about ML, which I guess I didn't make very well was that a). languages have their uses, and b). something as silly as making a lambda calc interpreter can be done [easily?] in something like ML, which leads me back to point a). Doing it in, say, Prolog might be a little more difficult. Or maybe it wouldn't be. Can't say I've ever tried.

Now, listen...I'm sure you're a great guy (?) and all, but forgive me here for a sec: What exactly do I need to learn about functional programming making parallel and distributed programming easier? And what does google learning this lesson have to do with anything? Did I say something about functional languages hampering, um, parallel and distributed programming? Or, uh, while we're here: did I say anything about parallel and distributed programming? Maybe I did...I don't have the quote handy, so if so, forgive my ignorance.

Regardless, I was more commenting on -- ahem -- how crazy this debate gets. Now clearly I'm not talking about you. You're quite level headed about all of this. I'm talking about all those other nutjobs who get dogmatic about things like which programming language is "better", and which can be appropriately used to do things like build interpreters for the lambda calculus, and teach lessons about parallel and distributed programming.