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

[Fox5]

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.

What's optional in C++ or requires a bunch of imported libraries may be part of the language in Java. Raising the lowest common denominator of programming capabilities is needed to take it from a few whiz bang programmers to an engineering field where manpower overcomes intimacy with the code.

Besides, it's ultimately all about the libraries anyway. High quality libraries are better than what most people could do on their own, and ideally those should be the highly optimized, performance critical sections of the code. If you're doing something that can't build on those existing libraries, then maybe C or C++ is the right choice for you.

However, I'm basically an embedded programmer (at this point in time) where space is critical, so C and assembly are just about the only languages used. Java and C++ makes an appearance in the apps that interface with the hardware though, as does Python. But even if the embedded hardware was more capable, I don't think our choice of language would change.

But really, most programmers are going to be "mcprogrammers" no matter what, and the environment/organizational structure should adapt to take advantage of that. Put the smart guys on frameworks and backend stuff, and leave the "I'm an app developer, I use app libraries to make complex programs in 20 lines of code" to the mcprogrammers.

 

[Markbnj]

That which you described above is all well and good, but if you had the right team of coders doing the same thing in C or C++ you could probably get the same level of performance on less hardware.

I could what? Where did I mention how much hardware we use? Hardware is dirt cheap. Cycles are dirt cheap. Disk space is dirt cheap. Bandwidth is dirt cheap. You know what isn't dirt cheap? Time and talent.

You come off as being very complacent, like you are sold on the whole idea of C# being "good enough" whereas my idea is "how can we make this better/faster/more efficient".

It's more than good enough. It's a perfect fit for what we needed to build. Your question of "how can we make this better/faster/more efficient" is not a bad question to ask, but you're creating the question to justify your preexisting answer. So I'll repeat myself: nothing about this system would have been "better/faster/more efficient" in any meaningful way if it had been written in an unmanaged language. Nothing. Yet, you would have decided to use the unmanaged language in the beginning, without even considering whether the project required it, because you assume it will be better.

 

[IHateMyJob2004]

hammer, nail, bueller?

 

[degibson]

What's optional in C++ or requires a bunch of imported libraries may be part of the language in Java. Raising the lowest common denominator of programming capabilities is needed to take it from a few whiz bang programmers to an engineering field where manpower overcomes intimacy with the code.

I completely, 100% understand the general argument: the language provides more essentials, so it is more productive. What is missing for me are the particulars: what does (e.g.) Java provide that you would normally need/want to get from "a bunch of imported libraries" in C++? My own ignorance: I know of no examples besides managed memory.

 

[EricMartello]

But really, most programmers are going to be "mcprogrammers" no matter what, and the environment/organizational structure should adapt to take advantage of that. Put the smart guys on frameworks and backend stuff, and leave the "I'm an app developer, I use app libraries to make complex programs in 20 lines of code" to the mcprogrammers.

Yeah you're right about what you said...I have no qualms using tried and true libraries, so long components of the libraries can either be embedded or included with the program. I do not like any type of "platform" that requires a framework to be installed on the client system...i.e. .NET runtime.

I could what? Where did I mention how much hardware we use? Hardware is dirt cheap. Cycles are dirt cheap. Disk space is dirt cheap. Bandwidth is dirt cheap. You know what isn't dirt cheap? Time and talent.

Yes, your response here is entirely expected. Let's not worry about efficiency or optimization because we have "abundant resources". I believe this same mentality was used back in the day, when they were hunting bison in the midwest. So many of them so may as well keep hunting them...oh but then what, most of them were killed off and then all those "McHuntards" who were content with "good enough" suddenly found themselves out of work and out of luck. Whenever you stop trying to be better, you stop being good...and when you stop being good you become useless. It's really up to you to decide if that's how you want to go down.

You don't need to mention how much hardware you use, because if is a simple fact that without the bloat required for a C# app to operate you could do with less than you have right now...not only that but you'd have portability. You can port a C/C++ app to linux from windows and vice versa, but C# is windows only.

It's more than good enough. It's a perfect fit for what we needed to build. Your question of "how can we make this better/faster/more efficient" is not a bad question to ask, but you're creating the question to justify your preexisting answer. So I'll repeat myself: nothing about this system would have been "better/faster/more efficient" in any meaningful way if it had been written in an unmanaged language. Nothing. Yet, you would have decided to use the unmanaged language in the beginning, without even considering whether the project required it, because you assume it will be better.

Sure, it may fit your needs today but if you plan to grow how well is it going to scale. Scalability is a leading buzz-word in the industry these days...you need it. You said time and talent are not cheap...but I have to ask, how expensive is it going to be when you reach a point that C# cannot effectively meet the your needs OR your needs would be better served by a higher performing language like C or C++, and then you have to redo the app from scratch?

As for your statement about there being no meaningful improvement if your app was in C/C++...are you THAT good that you can make a statement like that? How do you know and what are you basing that assumption on? I doubt you can say that with certainty...after all you're still afraid to step out of the sandbox.

 

[EricMartello]

I completely, 100% understand the general argument: the language provides more essentials, so it is more productive. What is missing for me are the particulars: what does (e.g.) Java provide that you would normally need/want to get from "a bunch of imported libraries" in C++? My own ignorance: I know of no examples besides managed memory.

I think what nobody has mentioned yet, or has clearly explained, is how these managed languages work. They're like toys...they live in a sandbox and cannot go beyond those constraints. The compiled apps produced by C#, VB or Java all require some sort of pre-installed framework to run, and they're only as good as, as secure as and as efficient as said framework (aka sandbox).

This allows "McProgrammers" to write a program in 20-50 lines of code that would normally require maybe 2-3 times that if done in C or C++...but the benefits are quite clear in either case (as are the drawbacks). C# is a good "add on" to VB, but it's never going to be more than what it is...a small shovel and bucket in a turtle-shaped sandbox.

Java, on the other hand, has one benefit that C# and VB both lack - it is cross-platform. It uses a virtual machine sandbox (which must be installed on any system that you plan to run the app on) to execute...but you java application does not need to be ported to each OS and can run with similar performance on many different systems. In my opinion, Java has more of a reason to exist than C# does...but I'm sure Markbnj will happily disagree and tell us how he built an OS in C# with minimal time and no need for talent.

 

[dinkumthinkum]

I don't think Markbnj works on it, but check out http://singularity.codeplex.com/ from MS Research.

OS development in a high-level language is an interesting topic that is much more feasible nowadays. It would certainly be nice to avoid some of the security problems that plague large programs written in unsafe programming languages. I'm not going to claim that Singularity is the answer, it's just one project out of many.

 

[degibson]

I think what nobody has mentioned yet, or has clearly explained, is how these managed languages work. [followed by explanation of runtimes, VMs, etc.]

It is my belief that I understand managed languages quite well, with a couple of exceptions. I'm well aware of how the software stacks work, advantages, disadvantages, etc., except for the one point I've been asking about: Is there anything beyond garbage collection that makes programmers (Mc or otherwise) want to use "managed languages"? ... or is it just the thats-my-hammer-so-your-problem-is-a-nail effect?

I'm looking for examples of hard language features, here. E.g., Markbnj mentioned reflection and RTTI earlier. Is this fundamentally easier in managed code? I really want to know what it is about managed languages that enables the hoi polloi of programmers to use them productively (as well as experts, of course).

 

[pdusen]

This allows "McProgrammers" to write a program in 20-50 lines of code that would normally require maybe 2-3 times that if done in C or C++

I know this wasn't your overall point, but for the record: I hear this a lot, but I have seen no indication that it is really true. As long as you have competent programmers and intelligent library selection, you can develop fairly rapidly in C++, or any other language.

With bad programmers in, say, C#, you'll definitely gain speed over having those same bad programmers use C++, but then you still have deal with all of the other caveats of having bad programmers...

 

[sourceninja]

I think what nobody has mentioned yet, or has clearly explained, is how these managed languages work. They're like toys...they live in a sandbox and cannot go beyond those constraints. The compiled apps produced by C#, VB or Java all require some sort of pre-installed framework to run, and they're only as good as, as secure as and as efficient as said framework (aka sandbox).

This allows "McProgrammers" to write a program in 20-50 lines of code that would normally require maybe 2-3 times that if done in C or C++...but the benefits are quite clear in either case (as are the drawbacks). C# is a good "add on" to VB, but it's never going to be more than what it is...a small shovel and bucket in a turtle-shaped sandbox.

Java, on the other hand, has one benefit that C# and VB both lack - it is cross-platform. It uses a virtual machine sandbox (which must be installed on any system that you plan to run the app on) to execute...but you java application does not need to be ported to each OS and can run with similar performance on many different systems. In my opinion, Java has more of a reason to exist than C# does...but I'm sure Markbnj will happily disagree and tell us how he built an OS in C# with minimal time and no need for talent.

This is how I feel. There have been hundreds if not thousands of great software developers before me. They have probably solved most of those common problems a billion times over and have come with the general best solution for them. So why I am continually forced to write those same solutions over and over? If a billion people constantly have to do the same thing over and over why not include it in the language so each time it is done properly? It's like writing your own basic setters and getters in objective-c. It was trivial, there was only one really good way to do it so it got included in the language spec. Now I don't need to worry about writing a setter/getter and it's release/retain counts. Obj-c takes care of it for me (in 90% of the cases).

 

[degibson]

This is how I feel. There have been hundreds if not thousands of great software developers before me. They have probably solved most of those common problems a billion times over and have come with the general best solution for them. So why I am continually forced to write those same solutions over and over? If a billion people constantly have to do the same thing over and over why not include it in the language so each time it is done properly? It's like writing your own basic setters and getters in objective-c. It was trivial, there was only one really good way to do it so it got included in the language spec. Now I don't need to worry about writing a setter/getter and it's release/retain counts. Obj-c takes care of it for me (in 90% of the cases).

Would you mind elaborating on this? Objective-C provides (default?) get/set methods for member variables? Can the behavior be overwritten later for compatibility (the usual motivation for a getter/setter in the first place)?

 

[EricMartello]

I know this wasn't your overall point, but for the record: I hear this a lot, but I have seen no indication that it is really true. As long as you have competent programmers and intelligent library selection, you can develop fairly rapidly in C++, or any other language.

With bad programmers in, say, C#, you'll definitely gain speed over having those same bad programmers use C++, but then you still have deal with all of the other caveats of having bad programmers...

Embarcadero (Borland) C++ Builder comes to mind...they actually did a good job of making C++ into a RAD by including a lot of commonly used libraries and functions, including code for creating and manipulating Win32 API elements with a few clicks. You can very quickly put together a full-fledged Win32 app in C++ Builder. And before anyone says it, it's not another version of MS Visual C++ even it does have a graphical editor for forms and such.

 

[Markbnj]

As for your statement about there being no meaningful improvement if your app was in C/C++...are you THAT good that you can make a statement like that? How do you know and what are you basing that assumption on? I doubt you can say that with certainty...after all you're still afraid to step out of the sandbox.

I'm basing it on what I understand of the system's requirements after working on every aspect of it for two years. There is nothing that is too slow that would be faster. There is nothing that is too large that would be smaller. That is not the same thing as saying nothing could be made faster or smaller.

As for stepping out of the sandbox, unless you're a lot older than you seem I was probably writing C++ before your genome was instanced. I've been programming since way before there was a sandbox.

 

[beginner99]

No, it's disgust and disdain. McProgrammers do not have a real understanding of programming. They have a working knowledge, which is enough to produce a program...but ask them how to tune it, optimize it, make it more efficient, cut down the executable size...they're mostly clueless. This isn't an issue with the role they play in the grand scheme of things, it's simply that their existence diminishes the overall quality of software being produced.

The "good enough" mentality is wasteful and with each generation of programmers who adopt this "eh, I have a quad core i7...it runs fast...no need to waste time optimizing this program" the general bloating effect is amplified. Then there is also the complete misuse of a platform, when a platform is being used to support things it was never originally intended to...Adobe Flash comes to mind...perfect example of a McPlatform gone awry.

Optimized software is not necessarily better quality software. Code optimized for speed is mostly much harder to read and much harder to really understand what's going on and hence maintenance becomes a pain.
Nothing is for free and hence there is no perfect solution the way you make it sound.
(I'm not saying you never should do it, rather that is also has downsides)
Everything is a compromise in the end and there is no affordable perfect solution.

IMHO every "platform" as it's scope were it is meant to be used. You would not use your 1000 hp race car to drive to work as you won't use C# only to build an OS or RDBMS.
But it also seems stupid to use C to write a local baseball clubs "CRUD" Web-App.

You also won't hire Mario Botta to create your house as you won't hire a "super Assembly guru programmer" to code a simple web-app for the simple reason that the normal McGuy does the job good enough for your needs and you can actually afford him.
All professions have differents levels of expertise not only programmers.
Meaning both have the right to exist and IMHO they don't even compete for the same customers.

 

[ObscureCaucasian]

I think anyone who tries to shoehorn one language into any scenario is being overly close minded. I believe that the performance overhead or a managed language like C# is negligible in many situations. The convenient thing is that this overhead is static and it has payoffs in many situations. Portability is a large plus to a managed runtime; although Microsoft doesn't put out run-times for other platforms, the open source community will build their own stable platform soon enough. Even on the Windows front, writing in C# allows Microsoft more freedom in changing the underlying OS architecture without breaking compatibility with older software. IMO managed programs are much stabler because they are easier to debug and uncaught exceptions are much easier to debug than a random crash from a seg fault.

Like it or not, managed run-times are the future of application software and you're only shooting yourself in the foot to not become familiar at all with them (unless you work in embedded/system software). I cringe to hear the word "bloat" overly used when often times productivity features are misclassified as such. Just because you're not actively managing the allocation of memory does not mean that you are somehow inferior as a programmer.

 

[Barnaby W. Füi]

Portability is a large plus to a managed runtime; although Microsoft doesn't put out run-times for other platforms, the open source community will build their own stable platform soon enough.

It's already around, actually. A number of popular Linux desktop apps run on Mono/C#. C# is a pretty pragmatic and productive language to develop apps in. It doesn't necessarily have to carry Microsoft baggage with it.

 

[SunnyD]

It has probably been mentioned, but without C there would literally be no Java or C#. Sure, you could probably write their runtimes with pure ASM, but I'm willing to bet their initial implementation were done in C.

 

[ObscureCaucasian]

It's already around, actually. A number of popular Linux desktop apps run on Mono/C#. C# is a pretty pragmatic and productive language to develop apps in. It doesn't necessarily have to carry Microsoft baggage with it.

The downside is that updates to mono will always lag those of the microsoft platforms. As the platform matures I'd expect the development to slow down a bit though.

 

[TheLonelyPhoenix]

I've been lurking this thread for awhile, but I feel I can no longer hold back.

Higher level languages are wonderful for solving problems quickly when there is no need to go into the basics. I remember reading a comparison of a simple program being coded in multiple languages and then analyzing the differences in size/complexity - the C coded program was the longest and the Perl program was the shortest at something like 20% the length. I'll go find my source if anyone actually cares, don't have it on hand.

I do somewhat agree with the argument that higher level languages could encourage a "lazier" brand of programming and general computer science skills - I advise people to start off in a procedural language when they are newbies and move up to object-oriented concepts and so on as their knowledge grows. I really feel that the lower level the language he/she starts off in, the better their grasp of fundamentals of data structures/algorithms/etc. Nothing drives home a concept of a linked list or whatever than spending an evening rolling your own in C.

That said, once you know the basics, there's nothing wrong with picking up those higher level languages to save time/money/effort so you can move onto the next program faster. Yes, these languages are meant to make things faster for the programmer, not the computer, but saying that they are awful because they aren't "basic" enough or encourage "McProgramming" is like saying the wheel should be reinvented for every car a company builds. The advantages of slightly faster code are offset by the disadvantages of time and knowledge required, which is almost always the REAL limiting factor in business and industry.

Also,

I could what? Where did I mention how much hardware we use? Hardware is dirt cheap. Cycles are dirt cheap. Disk space is dirt cheap. Bandwidth is dirt cheap. You know what isn't dirt cheap? Time and talent.

This might be my favorite quote ever regarding programming. :-D

 

[PhatoseAlpha]

Hm. One of the thoughts that has occurred to me is that a 'lazier' brand of program may actually be a necessity, not a sin.

Higher levels of understanding the underlying theory and mechanism may be good for the craft, but they imply a higher level of education and experience for the programmer. And thus, a higher wage. This means that unless the greater efficiency is genuinely helpful to the company - and it may not be - it's just a greater expense. Hardly universally good for our employers.

But what about us? Well...the thing is that an awful lot of code - I'll go as far as to say the majority of code that actually needs to be written - is boring. Just plain boring - business rules in a given scope just aren't exciting to anyone. A programmer with a high level of skill is going to find this even more boring then an typical programmer (McProgrammer, to use the pejorative.) I doubt that being bored is going to really count as a plus from the programmers side.

Kind of looks to me like embracing the principle that a programmer needs to know more ends up hurting the businesses we work for (through higher wages) and us (through decreased job satisfaction). Then you end up with the problem of the bored, high level programmer - in particular, their habit of increasing efficiency through tricks which though effective, are difficult to comprehend and thus a pain to maintain.

This seems like it's screwing everyone on the practical side for the sake of philosophy.

 

[Barnaby W. Füi]

This seems like it's screwing everyone on the practical side for the sake of philosophy.

Which tells you that the proponent of that philosophy is probably better at arguing on the internet then they are at doing their job in the real world.

Lower level languages like C don't just require more skilled programmers; they require more TIME, regardless of the skill of the programmer. Time is money, and writing a business app in C is usually a poor choice in that respect. Which is why hardly anyone does it.

Deriding higher level languages as "Mc"-anything is simply out of touch with reality and childish.

 

[Cogman]

Which tells you that the proponent of that philosophy is probably better at arguing on the internet then they are at doing their job in the real world.

Lower level languages like C don't just require more skilled programmers; they require more TIME, regardless of the skill of the programmer. Time is money, and writing a business app in C is usually a poor choice in that respect. Which is why hardly anyone does it.

Deriding higher level languages as "Mc"-anything is simply out of touch with reality and childish.

There are SOME higher level languages that are, IMO, "Mc" languages that are overused/hyped. Python is the clearest example of this. IMO, python should be relegated to the realm of easy administrator tasks. However, people want to try and use it for things that languages like C# and Java are better suited for. Python is painfully slow. Switching to C# or Java gives a fairly noticeable speed increase.

 

[Barnaby W. Füi]

Python is painfully slow. Switching to C# or Java gives a fairly noticeable speed increase.

Writing Java is painfully slow. Comparing it to Python on performance alone is silly. They're in completely different niches. Most websites aren't CPU-bound anyway. Python's performance is more than adequate much of the time.

 

[zebano]

It seems to me you're best off realizing that there isn't one "Greatest Language EVER", because everything is about context. To go from different extremes, Assembly is great if you want/need extremely fine control over what instructions are being executed. On the flip side, Java/C# (or even higher level languages such as Python) are great if you have plenty of speed and need to do something quickly an easily.

I would always pick the highest level language that I know and that will do the job sufficiently. Over time you will most definitely see that average point move to higher and higher levels of abstraction.

This is absolutely correct. At work I debug existing drivers for ARM processors. They're written in c/c++ so naturally that's what I use. Test apps are written in C++ per our standard. At home I'll write either in C# if I need a GUI or PERL if I'm doing some simple data/parsing (usually scraping a website and aggregating the data so I can theorycraft for various video games). When I get really bored, I pull out my old Chess engine that I wrote in C++ and try to optimize it. I'm not really attached to any one language.

 

[Scali]

I'm not sure which is better, really.
I think I've 'transcended' languages over the years.
I started in assembly, moved on to C, then C++, Java and C# (and a lot of obscure other stuff in between).

While we primarily use C# at work now, I find myself using other languages still.
I'll use C/C++ for certain low-level or performance-critical stuff, or even assembly when required, and wrap it in .NET, so it can be used from a C# user interface.

Trying to decide which language is best is useless. They all have their weak and strong points, and when used correctly, they can co-exist and complement eachother very nicely.