Slashdot Mirror
Are C and C++ Losing Ground?
Pickens writes "Dr. Dobbs has an interesting interview with Paul Jansen, the managing director of TIOBE Software, about the Programming Community Index, which measures the popularity of programming languages by monitoring their web presence. Since the TIOBE index has been published now for more than 6 years, it gives an interesting picture about trends in the usage of programming languages. Jansen says not much has affected the top ten programming languages in the last five years, with only Python entering the top 10 (replacing COBOL), but C and C++ are definitely losing ground. 'Languages without automated garbage collection are getting out of fashion,' says Jansen. 'The chance of running into all kinds of memory problems is gradually outweighing the performance penalty you have to pay for garbage collection.'"
But does Netcraft confirm it?
C/C++ will always be there. Period. Just look at all of the C/C++ projects on SourceForge. New languages will come and go, but C/C++ are just too stable to go so quickly.
Need an automatic screenshot taker? Try here.
But did anyone else find Visual Basic rising two spots to #3 past PHP & C++ to be a sure sign of the apocalypse? (Visual) Basic 11.699% +3.42% A Could someone reassure me that's a mistake before I go home to sit down with a bottle of Jack Daniels and a revolver with a single bullet in it?
My work here is dung.
I haven't written a line of code in C or C++ since I started with C# - C/C++ syntax with no tracking of memory (I detest tracking memory!!) except in the more obscure situations. Both .NET and Mono allow for C#, so you're not stuck on one platform.
For simple tasks that I used to do in C I'm now doing in python... But I did start programming more in Objective-C so in my world C have morphed not necessarily gone away.
Sheldon
Of course C++ is losing ground. But does it matter? No.
If you still need optimum performance at any cost--like for OS's, many games, simulations, etc.--you must use the C's. If you don't, then your Java or favorite scripting language will give you faster development time and easier deployment.
So it just doesn't matter. I still don't consider someone a proper coder unless they know C++, though.
expandfairuse.org
I know I am gonna get flamed for this, but they said web programming, like its the only game out there. Sure its not web 2.0 friendly, and sure most web script kiddies don't use it...mainly because it don't hold their hand, but its far from dead when your are needing to squeeze every last ounce of power out of your hardware, or even that other 25-30% of it.
I develop desktop application software. Right now I wouldn't think about using anything else but C++.
Almost as bad as Jeff Atwood and Joel Spolsky calling them "dead languages" on their new podcast.
The cake is a pie
I really want to know if professional programmers out there think what shows up on the web is an accurate sample set of what is going overall in the programming community.
When I ran a Video Production shop, I was always explaining that what you saw on TV was only a very small portion of the market share of Video Production. There's a lot of things that just aren't for public consumption.
when we have internet that is as fast as cpu response times c and c++ will go the way of the dinosaur and the internet will be your main application platform and gaming platform, meaning game over for c and c++.
For image processing (film/video), real-time audio or any serious signal processing, the overhead of anything but C/C++ is killer. It'll be news when Adobe After Effects or Autodesk Flame is rewritten in python.
Besides, measuring the popularity of a language by the size of its web presence is the worst kind of fallacious reasoning.
...I say. If reference counting or basic allocation deallocation coupling is something you cannot do, you're in the wrong business. However, educating students in the art (c.i.t. I know) of programming with Java calls for these kinds of problems.
C and C++ are entrenched, but it was never their stability which caused it. Computer languages are theoretical; one valid language is just as 'stable' as another. The real issue of stability lies in the implementation, and that is language-independent.
Anyway, C is going to stick around because it is the most superb assembly language developed by man. C++ will of course stay around as well, but by modern standards it fails as a "high-level" language. The ceiling got a lot higher in the intervening 20 years; other languages reach much higher in a very useful way. I'd be happy to see less C++.
Cretin - a powerful and flexible CD reencoder
I could actually see C++ slowly going away over the next decade as it is replaced by other languages that fill the same needs but better. C on the other hand is probably going to be around for a long, long time.
Measuring by internet web pages mentioning it? Can you say, "worthless statistic," kids? I write code that controls hardware. You bet it's C++. I write code that's IN the hardware. An interpreted language? Are you out of your damn mind? Do I blog about it? Don't be absurd. Am I generating "web presence" for it? Only on slashdot. Go away useless statistic.
Well Java proves that by sitting solidly at number 1.
C's greatest strength is speed, and it's clear from the fact that Java (which is slow as hell) ranks higher that speed is not the primary consideration. Neither one of them are exactly a joy to develop in.
Just as well; I don't trust most people to program in C. It's great if can do it well, but for every person who CAN do it well there are 3 who only think they can.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
"C++ is dying". Next!
C/C++ won't be going anywhere fast.
* There's too much code written in both languages.
* There's NO CHANCE (imo) that anyone is going to write a kernel with code the plays with the memory behind the scenes. That's what the kernel's there for.
* "If it works, don't fix it." See old FORTRAN, COBOL, Pascal, and other "dead/dying" languages that are still being used in industries because it'd cost more to replace everything than it's worth to update it ~ and in downtime & support costs more than direct dev costs.
* "Fashionable" languages may affect the language choice, but do not affect task requirements. Construction workers don't wear hard hats because it's fashionable to do so.
+1. Modern C++ is way different from the old day paradigms. Just look at the boost library.
I can see cases in which I'd want to write an application primarily in C++, but it would be a pretty rare thing now. Mostly I see C and C++ as ways to make Python faster when it needs to be.
The garbage collection is nice, yes. But what really draws me to interpreted languages is how easy it is to build programs in tiny little scraps that you independently test along the way. And after that, how some of them allow you to have great economy of expression without being hopelessly obscure.
Need a Python, C++, Unix, Linux develop
I've noticed this trend as well, however it seems to me as though these languages are specializing rather than dying.
For example, it seems to me that C has a long future ahead of it as the de-facto low-level language. C++ is evolving in many ways, while trying to be true to the 'as close to the hardware' as possible roots. Many of the changes that have been outlined in the C++0x specification are rather interesting indeed.
I've spent the past year of my life using Python every day, and I'll admit that it has excellent utility as a general purpose programming language. However I do not see it replacing C in kernel development, nor do I see systems libraries being re-written in Python. I do however see many opportunities for rapid application development, web development, and other application-centric development in Python.
To be fair, there hasn't been anything earth shattering from the systems level programmers in some time, although the call has gone out to 'fix' threading, and if anyone takes that seriously I am certain that we'll see an increasing number of lines of code written in C and C++ again.
Finally, number of lines written doesn't mean one language is better than another. Frankly that's really silly, and it doesn't hold up to marketability either. I was recently in the job market, and many many people had no clue what Python was. Then again, I live in Seattle.
Cheers
-b
What I love about such studies is that they can confirm any theory you want.
Truth remains that every particular market has requirements which dictate selection of languages.
I doubt that telecom industry (as it is right now) would ever get over C or C++. Just like kernel or system libraries in anything else but C.
If you look at rise of Web - and pleiades of supporting it languages - then both C/C++ are out of question of course. Though again I can hardly imaging Apache or MySQL or PHP being written in anything else but C or C++.
Market for system and telecom programming is definitely shrinking - and consequently their languages. Other markets are now blooming - and their languages are becoming more popular.
My point is that the languages are complementing - they are not competing. After all you have to write hardware, firmware and OS first. Only then your beloved automated garbage collection has possibility to kicks in.
All hope abandon ye who enter here.
those who can code in binary and those who cant code.
OK, kidding aside.
There are those who write code so that a person can do something on a computer. In which case the users are comparatively slow and the high level languages give you a distinct advantage in development.
Then there are those who write code to make the computer do something, in which case the low level languages give you the ability to more effectively optimize how the computer interacts with itself, this is where languages like C, C++ really come into their own.
In the early days of computing it was all about the later, now its much more about the former, but the later will never go away. So the decrease is reasonable and IMHO does not represent a failing of the language, just a shift in the way computers are being used. I will be very surprised if the high level languages ever get widespread acceptance in the areas that require computational efficiency, ala computational physics, protein folding, etc.
-- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
GC is available for C++, but IMHO inappropriate. One of the great advantages of C++ is that the construction/destruction mechanism, along with automatic variables, gives you absolute control of the lifetime of every single resource. Whereas a garbage collected language like Java gives you absolutely no control over when (if ever) an object is destructed. I think it is a little wacky to give up this total control of object lifetimes in return for such a puny benefit, a benefit which could easily be achieved through C++ resource management techniques like RAII.
And anyway, garbage collection is irrelevant if you never "new" anything in the first place.
Fortran has been dead for ages but we still use it everyday on a variety of architectures. I know we're not the only ones. Many scientists still use it.
Which is why most of the "new kids" -- Python, Perl, Ruby (though Perl is getting kind of old now) -- support C extensions.
Would I actually write h.264 encoding/decoding in Ruby? No, not really.
Would I write a video app in Ruby? Absolutely -- just call out to the existing h.264 library (and mjpeg, etc) when I need to do the performance-intensive (and also boring) stuff.
Don't thank God, thank a doctor!
C may lose a little ground now and then but don't expect it to go away anytime soon. C is a cross-platform macro-assembler and a cross-platform macro-assembler is such an astoundingly useful thing that C has managed to be widely used since the reign of Henry III. Expecting C to die is like expecting Microsoft to open-source Windows.
In fact, along with ViceGrips and duct tape, C is one of the Three Most Useful Things In The Universe. (BTW, I didn't make that up. It's in The Book)
Bjarne! Get off your ass!
Memory management needs to be addressed as part of the language, not as a library call. That this has not been effectively addressed I lay directly at your feet. Don't give me that garbage about memory management being a job for the programmer. If that were the case then why did you even bother with explicit typing? Expecting us to keep the track of where to release memory is just as bad as expecting us to remember the type of every variable in the system. And then you went and added exceptions.
IMO garbage collection is an ugly solution to a general problem that wasn't solved by the compiler. It ruins real-time performance and still doesn't solve the other half of the memory allocation problem: not releasing memory.
Oh and that half-assed new/delete junk you gave us just a friendly wrapper, it doesn't go anywhere near solving the problem.
They ARE out to get you simply because They are in it for themselves and they don't care about you.
C++ is going "out of fashion"? What industry is this again? Who cares what is "in fashion."
C and C++ let you do things that you *cannot* no matter how hard you try in other languages. Java and Python have their place, and that place has expanded over time, but there are areas that they cannot tread.
No matter how much you improve the JVM, you will *never* be able to write a video codec in java (when the jvm compacts, it has to stop the world, and thus the video too). Nor will you be able to write kernel modules. Nor will you be able to write a large commercial video game. The list goes on and on...
Garbage collection is *great* when you can use it. However, garbage collection has some fundamental performance and memory usage characteristics that aren't going to go away, and thus GC languages will always be precluded from certain domains.
Scheme, ruby, python, lua, and lots of other languages come and go, but C++ is a powerful tool that is here to stay.
Yet you can do more true OOP in C then in C++... OOP in C is easy, you just don't have the 'work done for you' that you get in other languages. But C's runtime polymorphism is lighter and more powerful then Java or C++.
I do most of my work in Python and Java now. However, I often need to write in C/C++ to create JNI modules for Java or extension modules for Python. Wrapping low level (use 3rd party library) and performance intensive stuff for control via a higher level language is very productive. (C++ is handy for JNI, C is better for Python.) Furthermore, I even occasionally write small functions in assembler for C - usually to utilize a specialized instruction.
C++ isn't all it's cracked up to be.
It isn't? Let me give a little example of what you can do in C++. The task is this: 1. Transform all the strings in a vector of strings to uppercase. 2. Remove all the strings whose length is a multiple of 3. 3. Sort the resulting vector. 4. Print the strings on the screen.
Here's how I do it:
(cat(stringvec) | transform(strupper) | grep(bind(size, _1) % 3 != 0) | sort() | print())();Yes, that is actual C++ code, using a powerful generics language implemented with metaprogramming techniques. Now imagine writing entire systems like this. Looks kind of like shell code, doesn't it? Except with the total efficiency of C++.
Don't care for this little language? Invent your own. C++ has the capacity to express an infinite number of such "little languages." Metaprogramming is not a joke. It is probably the most powerful feature of C++. The problem is, few people are genuinely good at it. The boost project collects most of the experts in one place, so we can all make use of their techniques.
But, I suppose, this insanely powerful ability is not "progress." Hrm.
(In case you are wondering, the assembler code generated by the compiler from that single line is very similar to the code I would have written, had I written in assembler myself.)
With the help of the Standard Template Library (thank you vector and string!), I am 4 to 6 times more productive in C++ than in C. How is it that C is more "popular" than C++?
Perhaps this study isn't showing what they think it is. As long as we can't count lines of production code directly, such a conclusion will be somewhat suspicious.
"We think people rightly feel that once they buy something, it stays bought," --Suw Charman, Open Rights Grp
Just a friendly bit of advice.
Javascript + Nintendo DSi = DSiCade
Wow. I'm amazed that D made the list. Could this really replace C++ given more time?
Yes, but on the bright side, they lose ground about 1.5x faster than Java in most applications.
I notice in the data that unstructured programming has been making a big leap forward. I guess I need to update my skills here. It also appears that spaghetti code is becoming more common.
don't cut it off www.mgmbill.org
Transparent garbage collection sure is nifty but it's not the real world. Start talking to the physical world & you have to think in terms of addresses & memory again. Most of today's software doesn't talk to the physical world. It's database management, document formatting, user interface design. If the big thing changes to talk to the real world, the language ratings could change real fast.
We have certainly replaced C/C++ with Python wherever we can. This is about 90% of our software. Except where C is absolutely needed (which is mostly just in our kernel/device driver stuff), the 10x faster Python development and far easier code maintenance just outweighs everything else. That the Python is much less prone to crashing for programs beyond tiny one-offs is another big positive (yes, yes, if you write perfect C/C++ and don't use glib you'll never crash either, but in practice this never happens).
In practice the speed difference doesn't matter for almost every application we've run into - we have a high speed network load tester in Python, which sounds ridiculous, but it works and it makes it insanely easier to add new tests or behaviors. If we ever hit a bottleneck, we just write a small C extension module and call that from the Python.
I'm saying Python here, but insert your higher level language of choice.
The number of pages pointing to this comment is rising with certainty over the foreseeable future. Popular? Perhaps. Valuable stat? No.
I wouldn't say C or C++ is losing ground. They both continue to serve well in the niches they established.
Meanwhile, other segments of the pie are expanding, and few of these new applications are coded in C or C++. Does that mean C and C++ are losing ground?
There is no language out there that serves as a better C than C, or a better C++ than C++. The people who carp about C++ reject the C++ agenda, which is not to achieve supreme enlightenment, but to cope with any ugly reality you throw at it, across any scale of implementation.
For those who wish to gaze toward enlightenment, there is always Java. Enlightenment is on the other side of a thick, protective window, but my isn't the view pretty? I've yet to encounter an "enlightened" language that offers a doorway rather than a window seat. I would be first in line if the hatch ever opened.
The problem with C/C++ has long been that the number of programming projects far exceeds the number of people who have the particular aptitudes that C/C++ demand: those of us who don't need (or wish) to be protected from ourselves (or the guy programming next to us).
It's not economically practical to force programmers who don't have that temperament to begin with to fight a losing battle with self-imposed coding invariants. I'm glad these people have other language choices where they can thrive within the scope of their particular gifts. I don't feel my role is diminished by their successes.
For those of us who have gone to the trouble to cultivate hardcore program correctness skills, none of the supposed problems in the design of C or C++ are progress limiting factors, not within the zone of applications that demand a hardcore attitude toward program correctness.
It's the natural order of things that hardcore niches are soon vacated by those unsuited to thrive there, leaving behind a critical core of people who specialize in deep-down nastiness.
For example, it's not just anyone who maintains a root DNS server. I can say with some assurance that the person who does so did not earn his (or her) grey hairs by worrying about whether the implementation language supported automatic GC.
Let's take a metaphor from the security sector. Ten years ago, a perimeter firewall was considered a good security measure. This measure alone eliminated 99% of TCP/IP based remote exploits.
These days, most exploits are tunneled through http, or maybe I'm behind the times, and the true threat is now regarded to be some protocol tunneled within http.
Then some genius comes along and says "in the security sector, TCP/IP defenses are losing ground". Quoi? Actually, no one is out there dismantling their TCP/IP based perimeter firewall. It's continuing to do the same essential job as ever.
It's only the bandwagon that has picked up and moved camp. Yes, garbage collection and deep packet inspection are now all the rage. So it goes.
Why not go around saying that sexual reproduction is all the rage these days? Would that imply we could eliminate all the organisms that reproduce asexually, and the earth's ecology would continue to function? Hardly.
These new languages are soaking up much of the new code burden because these language are freed from having to cope with the nastiness at the extremes (small and large) that C/C++ have already taken care of.
I would almost say that defines a success criteria for a programming language: if it removes enough nastiness from the application space, that the next language that comes along is free to function on a higher plane of convenience. C/C++ have both earned their stripes. Which of these new languages will achieve as much?
C is is great for being a very readable language that compiles fairly directly into assembly, but it is by no means the last word in performance. There are still systems for which even optimized C is too bloated. In the shop where I currently work, there are a lot of gray-haired, mainframe sages who still argue over which instruction is more appropriate. (They do not, of course, go to google for that kind of information.) The remarkable thing about it is that those choices sometimes make measurable differences. Those people scoff at C the way the C zealots posting here scoff at java.
I couldn't help but notice that there were no assembly languages in the list. Let's not lose site of the fact that this survey measures flow through the intertubes, not actual usage or utility. Let's also not loose site of the fact that each language has its purpose, however humble.
Even the mainframers agree, though, that you shouldn't program in COBOL if you can possibly avoid it.
Hi,
Yes, some things need to be done in assembly or C in order to `stay competetive' or even just to remain within the realm of the possible. How much that is depends on your application and your platform.
So, systems programmers, you need not worry, your skills are always going to be needed for something.
But let's be honest here, 80% of the applications you can code entirely in Haskell or Prolog or Python or whatever fancy high-level language you may personally have come to love. And of the remaining 20%, you can usually still code 80% of the application in your favourite language and optimise the core 20% in C. (After profiling. Let me repeat that, AFTER profiling.)
Will it run faster and in less memory if you do it all in C? If you do it properly, sure. But that's not the question to ask. If you work commercially, ask for `what will be most profitable in the long run, while remaining ethical'. If you work free software projects, ask for `what will benefit people the most'.
Don't confuse the above questions with `what will satisfy my C(++) hacker ego the most'. And remember that it's not just about getting the code working and making it fast, it's about making the code robust; and in many cases it's also about making the code readable for whoever will maintain it after you.
Apologies for this rant; feel free to mod it down if you so desire, but you, dear fellow programmers, have had it coming for quite a while, as did I.
It's not too quite unpossible... But
http://lyrics.learnithere.org/lyrics-category-e/eurythmics-lyrics/
Well, maybe that's like asking if having a duo of Annie Lennox and Barbara Steisand, or Annie and Celine Dion would be losing musical ground...
Let's ask Annie...
DOUBLE plusgood....
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
How big and slow are C++ compilers? The language itself is enormous and unwieldy. Look at all the add-on libraries you had to use to achieve your example?
You'd have written assembler to do that yourself?
You truly are a god. I bow down and worship at your divine feet, unworthy that I am.
Stick Men
While Vista-64 is fine on powerful workstation (my WS has 24 GB RAM and 8 cores, I do a lot of math), the OS clearly sucks on "normal" PC.
Now, I overheard that a lot of Vista code was written on C#. And that they redo it in C/C++.
Hmmmm
FORTRAN, Lisp, and Cobol have all lost ground. BASIC and Pascal used to be the big dogs instead of also-rans, and if Ada ever had any ground in the first place, it lost that.
Even Perl isn't as popular as it used to be, now that other languages have started to fill its niche.
Times change, and it should be unsurprising that the dominant programming languages change along with it. Some day, Java, PHP, Visual Basic, Python, and Ruby will all be obsolescent as well. Thirty years ago, computers were vastly different than they are now. In another thirty years, there will have been another quantum leap (intended) in computing. Why should the languages we program them with remain the same?
what what what?
Another year and I'll finally be able to throw away my Ada generics.
Who's going to bother listening to my "back in my day, we programmed uphill in the snow both ways" stories when I don't even bother to use a monospaced font!
And before I started up my 80x25 terminal window, I tied an onion to my belt, which was the style at the time.
Yeah. Much better.
What? SymStream and SuperSleuth aren't on the list??!? Man, I gotta update...
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
I use C/C++, Java, and Python. Java is not "slow as hell". The language itself is fairly close to C. What makes certain applications slow with the Sun VM is things like the default GC using twice as much memory, and very bloated environments like EJB. Even the startup time is reasonable beginning with Java 5 (the standard library is precompiled, and you can add your own libs).
GNU Java compiles to native and uses a C++ compatible conservative collector (Boehm). It is fast. I loved Sun JDK 1.1 - I could run a network daemon in 256K. Even in 1.1, lowlevel benchmarks showed Java nearly as fast as C. Slowness was caused by the environments built on top of it (EJB). The modern JVMs are so bloated in comparison to 1.1 - good thing 2G is entry level memory. But their performance in incrementally better given enough memory.
The fastest language for many problems seems to be Lisp, not C. I could never handle all those parens, and alternate syntaxes (Lisp is very flexible that way) just get me sneered at by the Lisp experts.
It's just slightly higher level. A C compiler outputs assembly code - that's the whole point of a C compiler. Think of C as the worlds greatest macro processor for assembly.
That's why most compilers have some sort of ASM pragma - so you can inject your assembly into the code if you feel the compiler is doing a poor job of it.
That's also why you'll never find a faster language. And that's why it'll never go away.
Weaselmancer
rediculous.
vtables are often implemented via a symbolic lookup table rather then offsets so calling a function can often involve traversing the list to find the right one. Even with delegates and interfaces, true you can get some degree of runtime polymorphism, but these add some non-trivial redirections and can clog up both your call stack and symbol table. I admit there are not huge gains in C OOP nor are they things that can't be done in other languages with some work around, but they do require some significant additional complexity to do it.
There's nothing to stop you from exclusively using reference-counted smart pointers and garbage collection in C++, for some or all of a project, if that's really your thing.
For me, C++ destructors (each object responsibe for it's own storage) remove most of the hassle of freeing storage, and I've never hankered after garbage collection.
As someone said the need to utilize C because of the 8Mhz computers are long gone. The problem is that he failed to realize that the 8Mhz computers are just working in a different place. For example most people probably have a bunch of them in their car and the only way to program them is with C, C++, or Assembler.
Ooo man the floppy drive is broken. No wait. The computer is just upside down.
I meant to write 8Mhz desktop computers.
Ooo man the floppy drive is broken. No wait. The computer is just upside down.
I doubt that legacy C++ code will ever be rewritten in the D programming language, but D can easily replace C++ for new projects. You can do the same things in D as in C++, it's just a lot easier.
There seems to be two flaws if a language's "popularity" is measured solely by its web presence and activity... First, proprietary/closed/corporate software development generally occurs off the public/web radar, so if the goal is to evaluate trends in a language's use and popularity, we need to be looking at more than what's on sourceforge, public support forums, and so on. Second, more activity in, say, a C# forum only means that more questions were asked questions about C# than in a C++ forum. The other day someone was insisting to me that Apple rightfully is killing Carbon and going with Cocoa b/c of how much more activity the Cocoa mail list sees than the Carbon mail list (the implication that activity equals popularity *and* quality). I replied that *may* be the case, but it *could* be the case that Cocoa is inherently harder to learn and more a pain than Carbon (thus resulting in more mail list activity and questions).
I head what amounts to high performance desktop graphics (think desktop video gaming), and most of our stuff has to be in C/C++ for performance, legal portability, and embedded/platform portability. So, we're basically no different than companies like EA (codebase wise), so I feel confident and qualified in saying that the whole discussion of what language is the most "popular" is just silly.
It amazes me that people still spend time with these kind of language popularity estimates, as if an X% difference of "usage" actually means anything useful. Even if it were possible to add up and know how many hours the world spent using each language in a year's time, what would that accomplish? I suppose the big discovery would be that it's all about finding the right tool for the job. Of course, the joke here is that any developer or manager worth anything already knows this.
G-Force music visualization
That says nothing about those languages. All that says anything about is your job.
I write drivers, so I could make the opposite statement. Doesn't say anything about the relative merits of one language versus another though. All it says is that I'm in an environment where C makes more sense.
In summary: A hammer is best when your problem is a nail, and a screwdriver is best when your problem is a screw.
Weaselmancer
rediculous.
I, for one, sincerely hope that C++ is indeed losing ground. The language started already on the wrong foot (making it backwards compatible with C was a terrible mistake) and has since become the ultimate cathedral of rococo horror.
(Have you noticed how most (relatively) sane C++ developers tend to use only a subset of the language? And how C++ dev teams inevitably run into problems when the subsets mastered by different programmers are disjoint?)
Note that I did dabble in C++ for a number of years. But now, I only regret not having discovered Ocaml sooner. Though a functional programming language, it isn't one useful only for academic wankery. Quite on the contrary; it's very pragmatic in its design, supporting also imperative and object oriented programming. And by virtue of its very expressive and strong type system, it makes programming far safer than in C++ or even Java (no "null pointer exceptions" or that sort of runtime failure). Moreover, it is a very fast language (comparable to C++ in terms of speed) and has an excellent coverage in terms of available libraries.
So you will pardon me if I don't shed a tear on news of C++'s impending demise...
I've been in the "real world" for about six years now, after graduating with a computer science degree. I'm currently in Chicago, Illinois, USA. I've spent the past several months looking for a good software engineering job, both in the Chicago and Milwaukee (Wisconsin) areas. Just from this experience, my take is that Java and C#/.NET technologies are hottest right now.
My first job was using C and C++. This was partly due to historical reasons (the application was about 12 years old), but also because the API for the platform was only in C. Shortly before I came in, and during my tenure there, we were trying to move more towards C++ and build a more object-oriented framework. My current position is at a high-frequency trading firm. All our software is custom and mostly C++ (some C here and there, and a handful of Perl to glue things together).
So based on this experience, when I was looking for a job, I was focusing on C/C++ positions. What I found is that there aren't a lot of people looking for C/C++ developers. In Milwaukee, virtually all of the demand for C/C++ programmers was for embedded systems. In Chicago, there was little demand for experience in those languages outside of embedded systems and the finance industry (which I was/am trying to get out of!).
This is just my casual observation of a relatively small portion of the software engineer landscape as a whole.
On top of a diminishing demand for C/C++ programmers, I found that quite a few companies who were looking for Java/C# programmers wouldn't even consider C/C++ people. The languages aren't all that different, and the concepts should definitely be portable. I think knowing concepts, understanding programming ideas/patterns, problem solving, etc, are more important that knowing the specifics of a particular language. Shrug.
All you young bucks, let me tell you somethig. Back in the good ol' days when I was a programmer, we didn't have all these fancy "windows" and "icons". All we had were 1's and 0's. And sometimes we didn't have any 1's. Once I wrote a database using only 0's. And we liked it.
The thing about having GC is not that it makes it easier to avoid memory problems, it is that it makes writing code more enjoyable. Contrast writing something in Python, say, with writing it in C. In Python you can concentrate on the job at hand. In C you spend all your time doing the book keeping. Obviously there's a place for C and C++, and Java, C#, Python, Ruby, Fortran, Delphi etc. etc. etc., but people will work with what they enjoy. And that means that when you get to choose between C/C++ and a higher level language then the HLL will win.
And as time marches on, that ratio will only get worse. People who pick up a primary language that has garbage collection will be seriously handicapped if they ever need to write in a language that doesn't have it.
That means people who do down-to-the-wire systems work will someday become as rare as hen's teeth. And it will always be necessary to have these folks around.
Weaselmancer
rediculous.
I was surprised to see that as well. I coded in Pascal for a company a long time ago and have never encountered it again. I can't ever think of something I would choose Pascal for now. C# is what I mainly use now and after programming for years under QNX ANSI C I'm loving .Net and C#.
Developers that cannot manage their own memory are not real developers. Period. Try threading sometime.
With the iPhone SDK coming out and being 100% Objective C (v2.0) and Apple development in general being mostly Objective C (v2.0 in Leopard, v1.x in Tiger and earlier), I wonder how long it will be before it shows up on the list.
And in case you are wondering, Objective C v2.0 introduced optional Garbage Collection to this language, designed to be somewhat backwards compatible (GC can be required or optional, if optional it will run on Objective C 1.x systems).
DEMETRIUS: Villain, what hast thou done?
AARON: Villain, I have done thy mother.
Shakespeare invents 'your mom'
First off, let me say that I agree with you about Java not being slow. It's quick enough to write emulators on that run reasonably well. And those are notoriously computation and speed intensive. But I have to take exception with this statement:
All the benchmarks are showing Java exceeding C++ performance and giving C a run for its moneyJava can never give C a run for its money. C takes in C files and outputs assembly code. Java takes in java files and outputs java bytecode, which is interpreted by a virtual machine. It can never approach C in terms of speed.
The only thing that has a chance of being faster than C is hand-crafted assembly. And that being done by someone who knows more optimizations than the compiler. Possible, but unlikely.
Good examples of people who could pull off this feat are the demo-scene folks from the 1980's in the Amiga scene. They were better than compilers. Other than that, I don't know of any others.
Weaselmancer
rediculous.
[quote]"Languages without automated garbage collection are getting out of fashion"[/quote]
We have had so much trouble with GC taking our application down that we implemented our on measures to handle this. We run a real-time application that would come to a stand-still while GC was in process. All because some suit decided we needed to add some Buzz words to our Marketing, e.g. Java
I'm not really sure why C++ is so ill-favored lately. It may not be fully OO, but there are many times when a fully OO solution is counterintuitive. Instead, C++ allows the developer to choose whether they want an OO solution or not. I also see a lot of complaints about C++ performance in comparison to C performance, but really, when properly implemented there is little difference. The same goes for garbage collection. Granted you have to write it yourself, but program-specific garbage collection will ALWAYS be more efficient than automatic garbage collection.
I think it's generally agreed that C and C++ aren't going anywhere anytime soon, since a lower-level programming language will always be needed. However, sidelining C++ in favor of C is definitely not a good idea, as C++ does offer many advantages that C lacks. (Yes, even for kernel development.)
I'd go into more depth, but this article really does a good job of explaining it:
http://unthought.net/c++/c_vs_c++.html
PowerShell is its own .NET language.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
...it just smells that way.
1. Java.....20.5% - runtime written in C
...somehow I doubt C or C++ are going anywhere. The good news is if they DO die at least they'll take PHP with them.
2. C........14.7% - duh
3. VB.......11.6% - who cares
4. PHP......10.3% - written in C++
5. C++.......9.9% - duh
6. Perl......5.9% - written in C
7. Python....4.5% - written in C
8. C#........3.8% - who cares
9. Ruby......2.9% - written in C
10. Delphi...2.7% - no idea
REM Old programmers don't die. They just GOSUB without RETURN.
D also offers syntax and ease of writing comparable to C#/Java, but is faster, doesn't require VM and compiles to native code linkable with C.
i agree that C++ needs to be updated for auto GC. Perhaps like a C# version of C++ without the vendor-tie-in.
C will *always* have its place in OS and systems-level programming. The high-level of abstraction in modern languages are preventing them from being an effective C replacement (which wants the lowest-level and no abstraction).
Now, why is Pascal and FoxPro growing so fast?? I didn't know there's such a huge demand for those 2?? Or have I been living in a cave through the Web 2.0 era?
ps : can someone explain the pros and cons of Ruby v. Python? I haven't programmed in either.
I'm shocked and pleased that D is even on the top2 0 list, much less at #12 already. I guess going 1.0 last year really helped with adoption. Now it just needs a lot of dev tools to really send it into the top ten. If you want to replace C with something C-like, I can't think of anything better than D as far as the language itself goes; we just need those supporting tools.
No where in the paragraph that starts off with c and c++ is loosing ground does he mention why, then he goes off and talks about automated GC, come on if any language were NOT to have GC it would be the likes of c or c++. I don't believe he has much clue as to what is going on, and the way his org collects and interprets data is flawed to say the least.
Arash Partow's Philosophy: Be a person who knows what they don't know, and not a person who doesn't know.
Until a language comes along that can outperform C or C++, there will always be a use for them.
It's still right-tool-for-the-job. I don't use Ruby to write audio DSP plugins, and I don't use C/C++ to code a web application.
I'll keep both in my tool box, along with lisp,
In the work I do--scientific calculations with a lot of fast numerics, , python + fortran seems like nirvana, as each overcomes the shortcomings of the other. One could just as well use C except the efficient numeric libs and memory layout give fortran an edge.
This of course is not the match made in heaven for everyone but numerical scientists should look hard.
What's so good?
Utility:
Well there's a strong base of numeric libraries in Python that are fortran array freindly so there's a good base to grow off of.
Second F2PY, which creates python modules out of fortran subs works so well it's almost transparent and painless. Even cooler is that because fortran compiles are ludicrously fast compared to C++, you can generate fortran code in the python compiler at run time and compile it one the fly for creating modules optimized to your problem.
Given you are wrapping in python, the availability of groovy C++ libs is not really very enticing at all given the pain you will pay for having to write the whole program in C++.
Practical:
Fortran as a stand alone language kinda blows for versatility and modern program architectures. But if all you are doing is writing a function then it's a sweet language because it's language syntax is so tight that it's harder to make a syntax error that compiles, and hard to logic errors seem to be less evasive than in C. (e.g. using i++ instead of ++i or doing I=4 instead of i==4 are not possible in fortran's limited syntax).
Thus you write functions and let python deal with all the memory management, human interface, file management, command line arg parsing and all the messy bits that end up being a lot bigger than the function where the program spends all it's time.
Fortran is also very optimization friendly since things like matrix multiplies and out-of-order loops are part of the core language.
This is debatable but I find that fortran seems to have a more logical memory order in 2-d arrays. Namely if you take a sub-array you get elements that are consecutive in memory and thus for most microprocessors will all get pulled into the cache on the same page. Slices of C-arrays have consecutive elements spaced by the row width apart in memory. One can of course find cases where one is preferred over another.
I do however which python had some way of optionally typing variables that was less cumbersome and slow than decorators or explicit run-time type checking. I virtually never write python that takes advantage of introspection or dynamic typing so the ability not to have some protection--optionally and just to debug--by type checking is annoying.
But If I were starting from scratch and did not have a compelling need for all those wonderful fortran numeric libs, I think the optimal choice in the future is going to be
Java+ Groovy.
basically you learn one syntax and get the best of both interpreted and compiled languages. Develop it in groovy then migrate the slow bits to JAVA. import all the great JAVA libs.
And since it's nearly the same syntax it's easy to read.
Some drink at the fountain of knowledge. Others just gargle.
can I borrow it to clean my cat's litter box?
To spoil the joke, but to explain it to you:
1) The speed of the internet has fuckall to do with the programming language used to code the processing parts of it.
2) A hard drive connected to a terabit internet won't do jack shit; -something- at your end needs to receive and interpret the stuff coming down the tubes. Or do you think magic fairies will do that?
3) Even a hard drive has software inside it, which will still need to be programmed, which means some language will be in use.
You're getting flamed because your statement makes about as much sense as: "Because TV will be digital next year, everybody will wear lederhosen with rabid gerbils stuffed down the front."
And anyway, garbage collection is irrelevant if you never "new" anything in the first place.
True, but your program is pretty trivial if it never needs to dynamically allocate a memory resource.
The enemies of Democracy are
That study seems pretty crappy to me.
Java, C, VB and PHP in the top spots seem reasonable. But Delphi, Pascal, Lisp, FoxPro and ColdFusion gaining ground? Mainly the latter 3? Come on. There is probably more Fortran code out there than the five combined. Also, Javascript going away?
The currently 'en vogue' languages from this list are Java, PHP, Python, C#, Ruby, Javascript and maybe VB - no matter what any study tells you. C and C++ are going to stay for a *long* time - probably just as long as COBOL and Fortran did.
It's abysmally slow running Python to do everything.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
heh, in the 90's my first web application was written in C.
It was damn fast.
The Kruger Dunning explains most post on
These results seem pretty obvious to me.
C (and C++) are great when speed, efficiency, and close mapping to the native processor are essential, such as for operating systems (scheduling, I/O, device drivers, need to be *Fast*), embedded systems, and a few other cases where CPU performance is the bottleneck. (Final Cut Pro won't be rewritten in Java, any time soon.)
For most other tasks, a higher level language with garbage collection allows far more rapid development, and with processor speeds such as they are, these other languages are more than fast enough, and becoming more so as CPU speeds and number-of-cores increase.
The odd time you do need some serious crunching, doing a "native method" (or equivalent, depending upon your higher level language of choice) is a great way to tweak up the 10% of your app that takes of 90% of the time, while spending most of your coding time in a higher level world.
More and more apps are becoming web-based; chewing up web requests and spitting back the resulting data, in relatively short-lived processes is a perfect place for garbage collecting higher languages with powerful string manipulating features.
C and C++ won't be going away soon, as long as we have operating systems in their current form. But the percentage of the apps requiring their specialties will indeed be decreasing.
Love many, trust a few, do harm to none.
I think you should learn how to use a pointer before you learn a class. It's really sad that a lot of programmers out there don't even know what a register is. I prefer knowing how something works before I use it. Garbage collection is great, but if you can understand how it works you're only hurting yourself.
I agree with just about everything you've said. I question the above, though. Is it really that bad?
Powershell != VBscript. VBscript is one of the Windows Script Host languages. Powershell is a scripting front-end to the .NET CLI. Very different beasts.
What's purple and commutes? An Abelian grape.
Exactly my point. A huge fraction of AE and Flame (and Avid, etc.) are the signal processing algorithms, realtime disk access and I/O (to hardware and screen), thread management for avoiding dropped frames and so on -- what you classify as "extensions". Sure, you could write the non-critical parts in python, but you'd be switching into extension-land so often, and most of the meaty code is in the algorithms, it's not clear what you'd gain.
I'm just saying, not everything is a web app or a word processor or a single clever algorithm wrapped in a huge GUI. And those hard realtime and performance-critical apps are still the sweet spot for C/C++, as they always have been and will continue to be.
Programs which use STL containers instead of manual memory management are "trivial?" This is news to me.
Avoiding the use of "new" is not the same as avoiding dynamic allocation. You simply let the containers handle it for you. Yes, there are pointers flying around, but they are out of sight, and managed by code that actually does things properly for you.
As a cross-platform desktop application developer I simply see no other option than to use C++.
I'd _like_ to stop using C++, frankly, but I don't seem to have a choice. A lot of my work depends on real-time capability, the kind of speed that is still only really possible on natively compiled languages that don't do dynamic typing.
I don't even mean hardcore real-time mechanical nano-second control of knife-wielding deathbots, just simple, This Must Run As Fast or Faster Than The Rate At Which It Will Be Converted To Analog. Python and Java still don't replace C in this area. (Mainly audio, video, and high-speed mechanical control.) And when it gets complex and you need to get into object oriented models to simplify the programming, there is unfortunately no real alternative other than C++. Combine this with that fact that there are a bunch of great libraries out there written in C++ that would be very difficult to replace, and you're stuck with it.
(I sort of oscillate between liking C++ and hating it, but I'm preferring straight C more and more these days. But like I said, I don't always have the luxury of choice, depending on what libraries I need to use.)
All these other languages mentioned (Java, Python, Ruby, PHP, Perl, etc) do not compile to native code, and all do dynamic memory management. Hell, that's exactly what makes them *good*. But unfortunately they're not so good for real-time tasks.
For real-time, you need deterministic memory management, and native speed. I've been looking at some other languages that compile to native code these days, like D, or Vala, but I haven't really decided yet whether I can start using them on serious projects.
I'd really like to learn more about functional programming in this area, too, but there seem to be very few functional languages that are designed for real-time. FAUST is one, but it's only for audio.
Anyone know any other good natively-compiled languages that actually have well-implemented modern features?
I wish it were possible to have a compiled version of Python, for example, but there are many dynamic features it depends on. (Some stuff could be done in Pyrex, which is a pretty cool little project, but so far I've only used it to make bindings to C libraries.)
Some drink at the fountain of knowledge. Others just gargle.
What framework is that? Is it cross-platform and/or OSS? I might want to use it.
vi ~/.emacs # I'm probably going to Hell for this.
Bwahahahaha! Good one... thanks.
On a related note: people still take benchmarks seriously? Seriously?! After all this time? Do we never learn? *sigh*
"Convictions are more dangerous enemies of truth than lies."
The current generation of managed code VMs clearly have some benefits. But but they fall far short on some of the key properties that make C and C++ so powerful. Even if I grant you that the JVM and
C and C++ are the only game in town for getting the best performance and a small memory footprint and the ability to have the lowest possible latency.
.NET communities, because they have empirically demonstrated that they culturally have no regard for small memory footprint, low overhead, short startup time, etc. They just don't consider huge memory footprint or ridiculous startup times a problem. This is not to ment
That said, I think that C and C++ are becoming harder to justify when you consider the havoc that memory errors can wreak. It's highly embarrassing to vendors and damaging to their customers when a buffer overflow exploit is discovered. malloc and free, even when used correctly, can still have some forgotten downsides like the memory fragmentation that was discovered in Firefox 2, and took some very smart people a lot of work to address.
What I would like to see is a language that gives the benefits of C and C++ (extremely fast, extremely small memory footprint, and no GC pauses) but that is also immune to C and C++'s weaknesses (memory corruption, memory leaks, memory fragmentation). Yep, I pretty much want to have my cake and eat it too. Why do I think this is possible? I think that the future is to have a fully concurrent, compacting GC. Everyone's telling us we're going to have more cores than we know what to do with soon, right? Well why not use all those extra cores to do GC in the background? Even if it's more expensive on the whole, we barely know what to do with all those extra cores as it is. With this strategy, you could get the performance guarantees and low overhead of C and C++ (on the real, non-GC thread, that is) without having to give up GC or suffer from memory fragmentation.
I'm also not willing to give up the option of dropping to C or C++ (or even assembly language) when it's justified. Mention JNI in a room of Java people and observe them reel in horror -- it's culturally shunned to deviate from "100% pure Java." Maybe this is a good value when you're on a big team of people writing a web app, but for systems and multimedia programming this is silly -- inner loops are inner loops, and some of them can benefit from machine-specific optimization.
Theoretically you could experiment with the fully concurrent GC using an existing language/runtime like Java, but I've sort of given up on the JVM and
How on earth are Prolog and Logo so high up on the list (after getting past the top 20?) Who uses them for any practical applications? I had always seen them as instructional tools or toys rather than functional languages (no pun intended, Prolog.) It's kind of embarrassing as an Objective-C programmer to see Prolog and Logo doing better than Obj-C or Smalltalk.
If you extrapolate the charts you can see that it won't be long until Python overtakes PERL... Ah, there is justice in this world.
And the recent Google App Engine initiative is going to add to the momentum.
Python Troll
You didn't say what kind of software you're writing. Personally, I think using Python for large codebases is shooting yourself in the foot (I've seen it tried several times and the results were never pleasant).
Problems Python has that C++ doesn't (imho) - Python is oddly easier to write than read in my experience, because it's so dynamic. The result is that it's a lot of fun to write and really no fun at all to try and figure out when you're new to a codebase, because you can'
Python doesn't even try and be efficient. Fans of Python tend to say that it doesn't matter because either performance doesn't matter for their application, or because they can write the hot-spots in C. Well, for a lot of apps there aren't really any well defined hotspots after some optimisation. Instead the app just chugs. Look at the fate of Chandler or Sugar for instance. You can't fix that kind of thing by jucidiously rewriting the bottlenecks in C because there isn't one bottleneck - it's death by a thousand cuts. This is especially true of memory-constrained environments like desktop software. I've seen way too many apps where the developers clearly thought they'd "make it fast later" and then discovered that they didn't understand performance like they thought ...
It's rather hard to distribute Python apps without distributing a giant runtime with them as well. For many apps that doesn't matter, but if you want people to download your app, it's going to hurt. Any consumer desktop app for instance ...
the C++ language is tiny, not "enormous". As for add-on libraries, look at all the other languages, you may not notice the libraries as they come bundled but languages like Java and C# have deprecated more library features than ever existed in C++
I think he had to use 1 add-on library, and may have been better off writing it using the stl instead.
Just to add to the "film video/audio" field. Banking people use quite a lot of C++. In fact, if you are looking for a quant. developer or something similar in banks you *MUST* C++, and some scripting language (python usually do).
And, then we go to games. The majority of games are done in C/C++. And I am not only talking about PC games, but Nintendo/PS/Microsoft console games.
Can anyone think of other industry aside of those three (movies, banking, games) big enough to make a dent by using another "major" language?
Ubuntu is an African word meaning 'I can't configure Debian'
Oh, you literally meant only explicit calls to operator new() in non-constructor code. Okay.
I view having to call erase() to free up the memory consumed by an object in an stl structure that is no longer needed to be a form of manual memory management. If you never have to do that, and only ever deallocate stl objects by letting them go out of scope, then that does to me constitute a trivial example, at least from a memory management point of view.
The enemies of Democracy are
Java and Visual Basic are mostly in-house business apps.
Top shelf apps that are getting installed on lots of machines are C++ (your office suite, browser, tools, etc.) If there's no danger of cpu bound tasks, C#.
Web stuff, PHP, isn't installed everywhere but is used by many browsers.
The #'s of installs are not reflected in the methodology.
If you need text styles to communicate then you don't have a message.
The list itself proves it - they're the only two low-level, compiled languages in the top 10. Garbage collection is nice if you're lazy or don't really need to be bothered with it, but they're different tools for different scenarios and they all have their place. Even when seeing VB and PHP up there hurts me in my stomach.
And no, JIT and bytecode execution is not compiling. Get over it.
(Oh, sure, there's a Boost library that offers STL-like containers that can manage pointers to polymorphic objects for you, but by the time you find out about that, you've already written reams of code that's totally broken in subtle ways...)
80x25?! You young'uns has the easy life! We thought we were living in luxury when we got our 40-column displays after having been forced to eek out on 22-columns for years. And that's when we even HAD monitors! Try editing your code when your "display" is a printer!
(Wow, flashback -- I actually did use computers connected to printers with no monitors at one time, and wonderful phones that you actually dialed and put the handset over the acoustic coupler to connect to the MECC system. Ah, those were the days. Funny how we get nostalgic for things that, honestly, really sucked.)
"Convictions are more dangerous enemies of truth than lies."
Forgive my humble intrusion, VGPowerLord, but I believe your ministers of knowledge have mislead you.
But many assemblers emit object code that must be linked.
(By the way, does the VG stand for Video Game?)
The chance of running into all kinds of memory problems is gradually outweighing the performance penalty you have to pay for garbage collection
It's a myth that there is a performance penalty for garbage collection; garbage collection usually has less overhead than doing the same kind of memory management with malloc/free.
The reason that garbage collection has a reputation for being slower is that once people have garbage collection, they get sloppy and wasteful. And languages using garbage collection often just aren't designed for efficiency (e.g., Java).
It would be nice to have a safe, garbage collected systems language, and such languages are possible. Unfortunately, all we get is Java and C#, two bloated languages that make writing efficient programs harder than eating tomato soup with chopsticks.
Troll?
Annoyed, enflamed perhaps, but Troll?
Sorry but it's a pet hate of mine that here on slashdot, which is supposed to be a forward looking tech board, that people still regularly espouse the view that threaded programming is something either still in development, too complex for ordinary mortals, or only applicable in a few scientific arenas.
It's just thoroughly incorrect. Industry and open source have been doing threading for years. Please can we lose this myth.
And to bring the post back on topic - pthreads in C will do it all nicely. Hell, even MS VC++ 6.0 (almost 10 years old?) will compile your multithreaded Windows C app.
I'd also lik to express suprise at the title of this article. C is losing popularity at the same position as last year, number 2? OK, it'll fizzle out any day now, I believe you.
I think my job's safe for now.
We could have had that today, if the idiots controlling Plan9 and Inferno hadn't put such ridiculous licensing restrictions on them.
They were so worried about their precious IP they ensured that no one would ever use it for anything.
Clear, Dark Skies
Why separate C and C++? I use them both in projects I work on and if you combine them you get 25% which is higher than Java. That study overall is pretty silly with questionable basis. I would argue there is more C/C++ code in the world than any other language; that doesn't mean it is the right language for every job. I use it when I need performance and control over how memory is managed (along with many other reasons). I also use java when performance is probably not an issue. When I need a script I use python. It's all about knowing the right tool to use and foreseeing where the project will go.
Statistics are 63% of the time wrong and 51% of the time partially right...
Heh. Very true. I use to have the old "C: God's Programming Language" as my desktop wallpaper. I still consider it my favorite language. But I was struck the other day by the fact that I haven't actually used C for anything in the last three years. I used to bang out quick C programs for many little tasks, but these days I usually end up using whatever scripting language best suits the need, and for larger projects, whatever has the best libraries and support for the needs. If I were going to do it all from scratch, I'd want to start from C, but I've long since gotten over the "not invented here"/"not written by me" syndrome.
I wonder if it's related to my slowly changing attitude where I went from viewing coding as a calling and an art form to viewing it as a means to get a job done.
But "cynical old man?" Ouch...
"Convictions are more dangerous enemies of truth than lies."
Right up until the moment that you need to use inheritance, and suddenly you realise that you're screwed, because the only way you can use an STL container with C++'s broken OO is if you're sticking pointers in that container.
boost::shared_ptr. Problem solved.
I'm curious what the list looks like for embedded programming - particularly at the low end. For my money, C is hard to beat on small systems - it's a good compromise between efficiency and manageability. If you know how the compiler works, it's not hard to write code that's nearly as efficient as hand-optimized assembly.
I'm sure Java ranks high there, too, but I don't consider it to be in the same class. Native Java hardware is relatively expensive, and running a VM takes a significant amount of memory and processing power.
My latest project is pure C (aside from about 100 lines of assembly for a firmware upgrade bootloader), around 30 pages of source code at present, and it compiles to about 9k of object code. It's targeted for a $2.50 processor, and I'm able to do things like simultaneous Bell 202 and DTMF decoding in software because I know exactly how C arithmetic is implemented on the processor and can take advantage of that without having to actually do the implementation in assembler. Doing the same thing in Java would cost a lot more. And when $5 saved on the bill of materials means an extra $5-10k in my bank account at the end of the year, that's a big deal.
So what other languages can compete in that space?
>You don't know jack shit about garbage collection.
>You think malloc() and free() have zero cost?
Well, first of all, in C and C++ you often *don't have* to use malloc and free if you don't want to. Apache, for instance, uses memory pools. Hell, you can even plug a garbage collector into C and C++ if you want, like Boehm gc. The point of C++ is that it can do *anything* and doesn't force you into a particular model.
Also, before you swear at me, please look up the term "amortized complexity" and compare it to worst case complexity.
Many algorithms have low amortized, or average complexity, but extremely high worst case. Garbage collection has decent is an algorithm that has good amortized time an atrocious worst case complexity for memory allocation.
Whereas in comparison, malloc and free are not cheap, but their worst case complexity can be made reasonable.
What is the worst case for a java garbage collector? When you try to allocate memeory on the heap, but can't because the heap is full. Then, java has to stop the world (freeze *all* threads) and free whatever memory it can on the heap. This operations time is proportional to the *total memory* your program uses, so it can easily make your app hang for a few seconds. Obviously, if you are processing video this will cause unavoidable stuttering.
GC implementations use a number of techniques to reduce the number of compactions, but there's no way to avoid them completely, which is part of why java desktop applications always have a sluggish UI experience, even if they work fine for things like web sites or batch jobs where the subjective interactivity of the process doesn't really come into play.
``The chance of running into all kinds of memory problems is gradually outweighing the performance penalty you have to pay for garbage collection.''
Moreover, automatic memory management makes for more elegant and workable APIs, and some things (I think closures are among those) need automatic memory management.
Also, automatic memory management is not necessarily slower than manual memory management. In fact, garbage collection can be faster than malloc/free, and has been demonstrated to be so in some cases. (One obvious case where a collector outperforms manual memory management is when the collector never has to run.)
Please correct me if I got my facts wrong.
Pascal is actually a pretty useful language for some tasks. I use it a lot for string processing utilities and such where I need speed. Modern implementations are nearly as powerful as C or C++, and a good bit easier to read.
C is my lanugage of choice for image processing, where pointers and low-level pixel manipulation in minimum time are critical.
explaining why GC has to halt the world periodically, which causes stutter in applications with user faces UI's like video.
>You can write an OS in a garbage collected language.
>(The Lisp machines did it)
The kernel would be a really bad place to put a garbage collector, because that would mean the entire system would halt on a compaction.
I don't know for a fact, but I doubt the LISP machines used garbage collection in the kernel. Even if the kernel source was some variation of LISP, it doesn't mean it was garbage collected LISP.
It would be incredibly stupid to try to write drivers with garbage collection. I'm not saying it is impossible, I'm just saying that the performance would be unusably bad even on modern hardware.
Comment removed based on user account deletion
And if you're really lucky, you can log in today and rez something to put a script in! :p
I actually used to hate LSL, and I still hate many things about it, but it's got a few adorable quirks, especially if you like state-machines -- you can write them in any language, but when the language explicitly supports them, it can clean up and beautify a lot of code.
Now if only we had arrays, hashtables, and structs... or even decent list syntax (I don't care if it'd just be syntactic sugar, I want my sugar!) And boolean ops that short circuit. Grr. I hate LSL...
"Convictions are more dangerous enemies of truth than lies."
C and C++ should not be lumped together. C is very, very good at being what it's supposed to be (a half-decently-portable hemi-demi-semi-assembly language that lets you finesse/{screw up} the heap) and C++ has always struck me as being neither fish nor flesh nor fowl, and master of none. Being neither hot nor cold, I spit it out.
Note that their results of (a whole!) two years seems to bear this out---C is close to holding steady, C++ is slipping a bit more (though still de minimus).
So it could also be considered a niche on the scale of all the situation at which you can throw the other languages. C could be found on anything electronic that can run code between small embed micro-controllers up to package running on huge mainframes or cluster.
It's not bad, its very useful indeed. Just hasn't seen as many different usages as the other languages yet.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
C/C++ will be dead when there is not one .c, .cpp, .h, or other C/C++ file extension in the /usr/src folder! If an entire OS is made with it, it's still alive to me!
But not in response to what I typed. I think the reason why you disagree with my post so much is that you didn't read it very closely.
This statement shows an extreme ignorance of how the Virtual Machine functions.I made no claims about the virtual machine - I only made claims about the compiler:
Java takes in java files and outputs java bytecode, which is interpreted by a virtual machine.And this:
THAT is why hotspot is capable of kicking C++ up between its ears.Has nothing to do with my post you responded to. Find a single instance of me mentioning C++.
Weaselmancer
rediculous.
What are you going to use to write the compilers?
I for one, am glad to see both Delphi and Pascal are on the rise (albeit very little - and personally I think they should be taken together).
:)
Delphi was great in it's day (up to version 7) as an IDE and RAD environment. But ofcourse, leave it to Borland to destroy a good product. Their track record says enough
Either way, Object Pascal is a great development language and I still use it daily. Compared to C++ it's a breeze to work with and you can do pretty much anything you can do with C++ with OP (and it'll still compile it all in a fraction of a second). I know for a fact Delphi 5 & 7 are still heavily used in large (and government) projects, btw.
Delphi may be dead, but FreePascal+Lazarus is still very much alive and useful. Providing a RAD environment largely compatible with Delphi, but compiling to many many different platforms. From Linux to Windows, from Windows Mobile to NDS, sporting various GUI toolkits, etc.
I still develop many small tools for Windows in Delphi and crossplatform or 'weirdplatform' stuff in FreePascal+Lazarus.
The language is easy to learn (but beware, the 'last mile' is not so easy) and you can make use of all the C/C++ goodness out there. You may need to translate a header or two, but that's it. It compiles natively and it's damned fast.
I'd go so far as to say that developing in Pascal is at least twice as fast as developing in C++ - and yes I also develop in C++ when necessary (ie, client requirement).
A little known fact about OP is that it actually does support garbage collection if you do some smart coding ('abusing' scope-dependant reference counted variables). It's not 'built in' like in C# and Java, but after doing it for a day or two it comes natural. Actually this trickery is also very useful for debug logging and such, as you're able to perform operations both when variables are declared and when it goes out of scope. I can just see you thinking "smart coding, that must be a lot of code then". It isn't. It takes about 3 or 4 lines of code per class to add this functionality.
Something that's more interesting though is Windows Mobile development. You might be interested to know that one of the most tricky and 'undocumented feature abusing' application available for Windows Mobile is written in FreePascal (I'll not spam the program itself) and I'm quite sure it would've taken a lot more time to write in C++.
----
As for PHP, I'm also a happy user of that. Yes, it's a language that invites abuse from the users who start with scripting languages, and not always as elegant as for example Python (should spend more time on that one) and Ruby (overhyped not really useful IMHO), but again, if you use it correctly you can do amazing things with it. Well structured, large, maintainable, scalable and code-wise intuitive applications are definitely something PHP shines at, if used correctly.
If there's one thing getting me down in this list it's JavaScripts fairly low rating. In todays web development world, knowing JavaScript, and knowing it well, is definitely a requirement. I wouldn't hire a web developer (not a designer!) who doesn't know all the JS basics and at least a fair share of the more advanced stuff. Knowing your way around jQuery (or Dojo, ExtJS, whatever) is good, but if you don't WHY and HOW it works, you're still no good, and you WILL run into problems you will not be able to solve.
Though webdevelopment used to be a bit of a small brother to 'real software development', the complexity of it is rising rapidly. Combining really advanced/complex designs (functionality-wise as well as visual) into HTML and CSS operating correctly cross-browser is something that already requires a lot of quirk-knowledge. JavaScript isn't implemented very consistently across browsers either. Enter the complexities of making it a full extensive AJAX application, it's not a small feat.
Especially if you realise that many of todays 'webcoders' are expected to do the server side (PHP/ASP/
Previous generations have shown similar shift of burdens for example regarding low-level optimisation between hand-written assembler and C-code optimised by the compiler.
The problem is that we are currently light years away from this. For now, functional languages are in their infancy. But still there's already some work being done on auto-parallelising Haskell.
Until then, during the next few decades, we will have to put up with thing such as CUDA (C code. With some extension to distinguish what runs on the CPU and GPU. And a fucking weird library of function to setup and control GPU execution, and which is a little bit too low-level and dependent on the architecture for what I would expect from a high-level language), Brook (C-like language for GPU. With nice syntactic sugar for setup/control. But lacks some fundamental functions (like integer math and scatters) that I would expect from a C-like language) and OpenMP (basically, just tags that you add to tell the compiler : Hey the following loop could be processed in parallel instead of sequentially)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
True, but your program is pretty trivial if it never needs to dynamically allocate a memory resource.
Not at all. Embedded applications often have maximum sizes that they allow for strings, buffers, and caches, and they set aside this space in advance, so they never have to do dynamic allocation.
i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
Thanks for the post. RAII looks like a really nice concept. I'm going to try and work it into my current project :-)
Actually, I do. But it's hard to explain to people that Java performs BETTER than C and C++ in the real world because Real-World Programmers(TM) suck. Even the best programmer lacks the time to write his code as efficiently as he wants unless the difference makes a huge impact on performance. As a result, both Java and C programmers write inefficient code. The key is that the Virtual Machine makes inefficient code fast through runtime analysis and optimization, while the C compiler just takes a best-guess up front.
Javascript + Nintendo DSi = DSiCade
Just use C and Lua and the world's problems will come to an end! No more headaches from reading C++, no more back pain from replacing servers with continually slowing down C# code! Besides, once you turn your company's network into a perfect C+Lua setup, and 20 years from now if the world is headed in its current direction noone will likely know the languages and you can get more raises since you are the only one who can maintain their network!
Strong typing. Garbage collection. Native code generation.
Lack of OO and a current up to date machine code generating compiler would be a detriment though
to a rollout anytime soon of this old language.
http://en.wikipedia.org/wiki/ALGOL_68/
H.
I view having to call erase() to free up the memory consumed by an object in an stl structure that is no longer needed to be a form of manual memory management.
I agree. However, erasure of objects is tightly coupled to the actual algorithm being implemented. It is of course always possible to get the algorithm wrong. Nobody, including me, writes flawless code.
You may want to take a look at C--. It's got some good justifications for claiming to be a better assembly language than C.
Although the amount of programmers programming in C/C++ might be decreasing as a a percentage of all prgogrammers; they still build the underlying foundations of all our software.
(Note: I've mainly been programming in python the past 5 years)
Virtual machines; interpreters; device drivers etc... are all implemented in C / C++.
without those wizards who know how to handle memory and hardware at a basic level, merely competent people like me would be a whole lot slower...
Hajo Monogamy: Belief so strong that millions of people end perfectly good relationships in order to start a new one.
There's exactly nothing that you can do with RAII that you can't with a try {} finally {} block, finalisers, and GC.
I don't know what you Java folks are smoking, but it must be good shit when you think that three different concepts replacing a single simple concept is somehow an improvement.
Cool. If that happens, what will its name be? I'll be Googling / searching Sourceforge for it :)
vi ~/.emacs # I'm probably going to Hell for this.
Sorry, but I wonder if anyone of you have heard about things like "hotspot" and "jit" compilers. Server applications that are "performance-critical" like currency-exchange systems are actually built in Java (not J2EE mind you). Java Applications that run for a long time can outperform C applications, simply because the vm can use runtime information to make optimizations. C compilers can only make conservative optimizations because they rely solely on static analyses...
Breakfast served all day!
As Sterling Hanenkamp notes the TIOBE index is a bit flawed. It doesn't measure popularity - it measures hype, and not all of it too. That put aside, it is true that C and C++ are not used as much as they once used to, and that's because there are alternatives that are better for many uses. However, there are still many tasks for which they are still the best choice (warning - a link to my own article), and should be used. A lot of open-source code is written in ANSI C and C++, and usually for very good reasons.
While I expect the use of C and C++ to diminish, I wouldn't say they are "dying" or "losing ground". They just become more established and more "niche" languages. Another fact to note is that usually the virtual machines for higher-level languages are C-hosted - perl5, CPython, ruby, php, Tcl, the various Java VMs, Mono (and probably Microsoft's .NET too), Lua, Io, etc. are all written in ANSI C, and can normally be extended using it. Some languages are self-hosting and usually can be bootstrapped by compiling themselves to C, and then compiling the C code.
Every programmer worth his salt, should still learn ANSI C, because not knowing it leads to lack of good understanding of computer architectures and portable programming that is bound to lead to inefficient code, and improper use of any programming language. I wouldn't recommend learning ANSI C as the first programming language (another link to an article of mine), but it's still an essential skill.
We have two eyes and ten fingers so we will type five times as much as we read. http://www.shlomifish.org/
"But computers are getting faster!"
I just read Slashdot for the articles.
which measures the popularity of programming languages by monitoring their web presence
Web presence doesn't equal much; it certainly doesn't equate to popularity. Nor do these numbers bear much resemblance to the mix of programming openings I see on job boards. C is number two? Really? Or are they just counting the number of times C shows up in the meaningless expression C/C++ ? Outside of the DSP and embedded devices niche, the appearance of "C/C++" in a job listing means they're looking for a C++ programmer, and it's generally followed by a list of C++ APIs that the successful candidate will be familiar with. And please, C fans, keep your flames low. C is my favorite language, but if it was really the second most popular programming language, I wouldn't spend eight to ten hours a day programming in C++ and PHP.
Anyway, the bit about the lack of garbage collection in C++ is a crock. There are a number of easy to learn and use GC libraries available for C++, and a number of them can be used in most cases with little to no code changes simply by linking them in. If the popularity of C++ is declining over GC, it's because people have gotten too lazy to type "c++ garbage collector" into Google. There are plenty of reasons to dislike C++, but that's just not one of them.
Proud member of the Weirdo-American community.
There's nothing good to program in. This is a serious problem.
We have C. C isn't a bad language, but the "pointer=array" concept, while it provided some performance gains in the PDP-11 days, continues to cause millions of crashes and intrusions every day. The fundamental problem is that you can't even express the size of an array in the language. Given that, the odds of consistently getting subscripts right is low. This could be fixed, but it will never happen.
There's C++. C++ has lost its way, as I've pointed out before. The C++ committee is off in template la-la land, putting in features that few will use and fewer still will use correctly. (Coming soon: "concepts"). The real problem with C++ is that it's no safer than C, but hides more.
There were once better languages. Delphi is better, but it's Borland. Modula 3 was a good systems programming language, but it died with DEC. Various attempts at improvement, from Ada to Eiffel to Sather, have almost died off. Amazingly, "D", which is Walter Bright's successor to C++, has a measurable market share.
Some progress is being made on numeric issues, like compiling Matlab to efficient code for parallel hardwware. But that doesn't help systems programming much. Hard-compiled Python would have potential, if Guido wasn't against it. (Python has a speed penalty of about 10x to 60x over C/C++. Maybe at some point Google management will decide that a hard-compiled Python system would be cheaper than building additional data centers at former aluminum-smelter sites.)
As for garbage collection, it's a headache. "Finalizer" and "destructor" semantics get weird. (See "Managed C++") Reference counting leads to saner semantics and repeatable timing, but is inefficient unless the compiler knows how to hoist reference count updates out of loops. (Incidentally, about 90% of subscript checks can be hoisted out of loops, and you can almost always hoist them out of inner FOR loops. So subscript checking is almost free if done right.) Note that Perl is reference-counted, and Perl programmers don't spend much attention on memory management. If you have strong and weak pointers, reference counting, and treat cycles as errors, you don't really need garbage collection.
Best advice: purchase the numpy users guide. very brief intro to f2py but you also get to learn the data types in python that work with fortran calls.
:: c
A program to add to 1-D arrays to each other element by element might look like this:
from numpy import *
import f2py
f = """
Subroutine foo(a,b,c,N)
integer N
real a(N),B(N),C(N)
cf2py intent(out)
integer i
do i=(1,N)
c(i) = a(i)+b(i)
enddo
return
"""
f2py.f2py(f,module="bar")
import bar
a = arange(5) # dummy array, size 5
b = sin(a) # the sine of this array's elements
c = bar.foo(a,b) # the sum of a and b, executed in fortran
when you run this it compiles the fortran at runtime and creates the python module bar.so that can be imported into any python program (on the same kind of computer). In this example, the fortran is embedded as a string in the python and recomplied every run. One could just run f2py at the command line on the fortran file one time and then just import the module.
flourishes that make fortran more pythonic:
f2py is smart enough to figure out that N is just a dummy length argument equal to the array size, and so it will drop it from the required arglist (or you can supply it if you want to as an extra arg).
if you use f90 it will also figure out which variable are purely output variables and move those to the lefthand side. if you use f77 like above you can either leave them on the righthand side or you can add comments to the program that hint to f2py to move it to the left side. (see above code for example)
Thus c = foo(a,b) has no need to specify N, and the output is on the right hand side.
I can if I want to make foo() a method inside of a class. Thus I hold multiple instances of the data structures in python and use them to call the single instance of foo()
also try googling performance python.
Some drink at the fountain of knowledge. Others just gargle.
I have news for you however. Statistically and historically, CS-related work was mostly a big trail of failures. Virtually no project, aside a select few with insane ressources backing em, and a couple of lucky shots, actually ended up giving out more value than they required.
In this day and age, maybe its inefficient, maybe its not quite CS, maybe its not "cool", but it gets the job done, it saves money, it makes things work, its enabling. Its still not good enough in its current state, but its going in the right direction. We're leaving the "how" behind, and changing it with the "what". People have ideas, and they make those ideas a reality, and it "works".
It may not be as badass to implement an enterprise management system, as opposed to the first ethernet network, but you don't spend 3 years on a project to be left empty ended 90% of the time either.
Your argument used to go thusly:
For performance critical processing, the overhead of anything but assembly language is killer. It'll be news when After Effects of Flame is rewritten in C.
As time goes by, C# will be to C++ what C++ currently is to assembly language.
"Whereas a garbage collected language like Java gives you absolutely no control over when (if ever) an object is destructed."
That is the single biggest miss-conception that hurts java programs everywhere. The fact is, to write large high performance java programs you still have to be conscious of what is actually going on. That is why some JVM's have tuning parameters for the types of garbage collection as well as other aspects of the JVM your code is running in.
Garage collection happening automatically in no way, shape, or form implies any level of performance, good or bad.
http://java.sun.com/performance/reference/whitepapers/tuning.html
Saying that C++ is losing ground because it lacks garbage collection makes me fear for the future of the "general programmer". If you use C++ for any length of time beyond a week it becomes second nature to manage your memory. Hell, I programmed in C++ for 2 days and caught on to situations in which a memory leak would even be possible. It's scary how easy it is to do... it's even scarier to think that people would drop a language because they may have to be mindful of memory when they code.
Those who know, do not speak. Those who speak, do not know. ~Lao Tzu
I work at a very large telecom on their enterprise level network routers. Our code base is almost entirely C. I, and a few others, have been moving parts over to C++ mostly for what C++ and Boost can offer. There is a standard Red-Black binary tree library in VxWorks(probably all Unixes: rbtLib.h). Needing two or more sets of ordering on the same data is a hack. You create two binary trees and cast different structs before dereferencing it. I've done it. I then tried the multi index set in Boost and you know what? Each entry takes up EXACTLY the same amount of data as when I hand coded it in C. What's great about C++ is you can use it as a better C. Define all your types and use the implicit constructor calls to range check all with assert() when you develop.
I've also interviewed at Redback and they are entirely a C shop. Some of it is old entrenchment, but some of it is needing to know exactly what happens in their code. I have mixed feelings about that.
On the other hand, C is the lowest you can get across processor architectures. You have complete confidence knowing exactly how much memory a structure will take up, with knowledge of boundary alignemnt of course. Saving it to disk and loading it back is straight forward. Have one virtual function in a C++ class or structure and doing that will cause trouble as the compiler will put a pointer to a vtable at the beginning. From a simple debug shell I've had to debug a chip vendor's function by calling malloc and passing the address back to the API function to DMA a hardware table into memory. Have you seen what function overloading causes the compiler to do with the entries in the symbol table? My whole point is that abstraction leaks will always occur, and when someone has to go to the lower level to debug, these higher level constructs cause more confusion.
C isn't going anywhere, at least not in the some what niche area of network software programming.
The day we get 2ghz 128 cores in a tiny usb stick for $40, will be the day we program in flow chart/gui thingos.
Just like stargate, have a rack full of usb3 slots, and 2inch long crystal shaped usb sticks with crystal CPUs at 128 to 4096 core cpus, just plug in live and bingo
new speed ups in real time.
Maybe computers will be just a skeleton, IO back plane with ports/plugs/sockets, no cpus, no ram, everything is plugin and go, ala HAL 2001
4x10 matrix of usb slots, 2x10 matrix of microSD slots, 5x hdmi sockets, 10 optical sockets.
Liberty freedom are no1, not dicks in suits.
Coming from an embedded systems background, I can say that C is still king here. Nothing else comes close to C - the number of platforms you can write code for, the close relationship with the hardware, IO, drivers, etc. We use C for tiny 8-bit microcontrollers, all the way through to powerful ARM9 processors with tons of RAM.
"giant runtime"? As compared to what exactly? The desktop Python runtime is tiny compared to the desktop .Net or Java runtimes.
Software Inventor
From http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9020942&pageNumber=1 "ColdFusion. This once-popular Web programming language -- released in the mid-1990s by Allaire Corp. (which was later purchased by Macromedia Inc., which itself was acquired by Adobe Systems Inc.) -- has since been superseded by other development platforms, including Microsoft Corp.'s Active Server Pages and .Net, as well as Java, Ruby on Rails, Python, PHP and other open-source languages. Debates continue over whether ColdFusion is as robust and scalable as its competitors, but nevertheless, premiums paid for ColdFusion programmers have dropped way off, according to Foote. "It was really popular at one time, but the market is now crowded with other products," he says"
So, it is counterintuitive with these new stats!
Who should one believe?
It's good that C++ can do that, but that doesn't make it special.
Advanced users are users too!
Well, since Java has absolutely no support for true generic programming or template metaprogramming, there is zero chance of writing a library that outperforms C++ stuff like Blitz++. People are quick to mention run-time analysis, but fail to recognize C++'s true power, which are the above two. Hell, I can write domain-specific languages in C++ whose expressions are computed at compile-time and the result applied lazily at run-time.... try to do THAT in Java. Try to mimic expression templates in Java.
// used in library A
// used in library B
Java's main performance problem is that there is a lot of stuff that shouldn't be done at runtime at all. Polymorphism fully known and determined at compile-time is a good example; in C++, I can use specialization here. In Java, the VM has to figure out somehow that this one object is NEVER recast as one of its bases. Note that C++ without generic&metaprograms has the same problem, but the key difference is that in C++, I can SOLVE this.
Also, it is appaling to see how often the type system is erroneously used to do concept-checking. "Does type X fulfill the requirements of concept Y" is reduced to "is X of type Y or a derivative of Y". An example where this is bad:
struct vector { float x, y; }
struct Vec2f { float x, y; }
I can't simply use a vector given by library A for API calls used in B, even though the semantics are identical. In C++, this IS possible without dangerous casting.
If Java >=7 gets true generics (and not this sad joke that internally casts to Object, or the bound type in case of bound generics), then it will be much more interesting. Until then...
This sig does not contain any SCO code.
I wonder if anyone else caught it... This should be:
"with C... just about every advantage it has over more modern languages are advantages that assembly has over C itself."
Don't thank God, thank a doctor!
Obviously you fail to understand key differences between RAII and the Java GC. The fact that you mix in try/finally only adds up to this.
... do stuff ...
RAII ensures the destructor is ran once the scope is left. The Java GC does not guarantee this. This is ok for simple memory blocks, but very bad for resources that must be freed instantly, like some locks/handles on devices. In Java, I have to use finally. In C++, RAII not only takes care of cleaning up, it also ensures exception safety.
D got it right; destructors are executed when the scope is left, but the used memory is freed up whenever the GC wants.
Additionally RAII *does* allow stuff that cannot be done with your replacements. Just try this:
mutex m;
{
scoped_lock lock(m);
}
Exception-safe mutex locks that are automatically freed once the scope is left. Do THIS in Java.
Also, finalizers are amusing stuff: http://www-128.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html
This sig does not contain any SCO code.
Yes, in an even match, Lisp vs. C++, Lisp would almost always win. I agree.
... but no one did it so far. Also, is compile-time generic programming possible in CL currently? Compile-time compiler checking or the like? A very strong argument for C++ is that this stuff is never done at runtime...
But in the real world, Lisp toolchains are a PITA compared to whats there for C++, especially regarding optimization (well, Scheme's Stalin is nice, but I suppose we are talking about Common Lisp here). Also, I've yet to see a Lisp that allows me to do bare metal coding and high-level stuff like the GP's in one source. It certainly is possible
So maybe a slightly updated CL, with a much better toolchain, would be the ultimate.
This sig does not contain any SCO code.
To what does that leave python as fcgi replacement for PHP?
does the locking issue present disadvantages to Python after all?
because i was thinking, suggesting people to make their webpages in python rather than PHP was a good idea, not just in performance, but also in code maintabality. AFAIK in fcgi only one instance of the interpreter is running, so this would cause slowdowns after all?
or as scripting language for servers?
given you have an online server for a lot of users (around 300, like the game server for a mmog), and needs to be scripted, and could be written in C# or in C++/Python, which would be the choice here? would thread-lock make it slower in python?
my experience is, that a software written in C# is hell of a fast in allocating a lot of "items" (objects) and dont cause "server slowdowns" in complex operations, however, it is constantly slower than the C++/python counterpart at the first glimpse.
it would honestly interest me, even if the question seems weird.
Before you start: Yes, I know you are a seasoned coder, and did lots of work. It is no excuse for not understanding the "template la-la land". You can argue against them all you want (you won't hear any disagreement about C++'s crappy template syntax from me for example), but please use some VALID arguments.
This sig does not contain any SCO code.
As for NBL - I think the NBL will provide support/semantics for development methodologies and components - Abstractions built in for defining components, instantiating them from repositories, support for testing .. I think all the current focus on things like dynamic vs static typing, closures, functional languages, dsl, are all things that are at too low a level - it is analogous to assembly language programmers arguing over instruction set design when out of left field comes compiled high level languages (ie. fortran ) So I think the guy saying he doesn't see any new paradigms showing up is correct if your "domain" is limited to what we know so far.. I mean take C vs Ruby - how much do their paradigms differ ? Compare the difference in paradigms between assembly and fortran - that is big difference. I think the NBL will be the NBL exactly because it will force us to think about programming in an entirely new way - in my opinion it will need to address the fundamental problem that alot of software engineering (despite 20 years of OO) involves re-inventing the wheel. .. I think Parnas in the 70s or something delivered a speech on this...so the NBL will enable components ...Software development is hard (re Brooks - mythical man month - essential vs accidental complexity) that is true..but it doesn't follow that we are doomed to repeating the essential (hard parts) ad infinitum....okay sorry for rambling... good night.
Take the hottest web dev framework - Ruby on Rails...what is pathetic is how much functionality each web dev team is duplicating all over the world...user management, logging, session management, on and on, not to mention higher level domain stuff like shopping carts.. so there is lots of re-inventing the wheel going on. Software needs components - this is not a new idea
After all, with a userbase of ten million, the nation of Azeroth explicitly using LUA in their 3d Webbrowser it should count for something!?
I expected a lot of books written about it for now, with about 100 pages and 40 pages of them containing high-performance graphs screenshotted from "the game" itself, adressing important scientific issues like:
"Increase Output and Minimize Input - A Warriors Guide"
"The Right Array Management and Database Access for Spambots"
"Multiple Transfer and Transaction Management for Traders" (with chinese intro)
"Hardware Process Automation to optimize a Pointing Device"
"Colored Interface Design for Orcs"
"Nightelves Guide to Arithmetic Trees - Solving the Bagpack Problem" (with an approach to world travel solutions)
"Developing Daemons" (with an example of a cronjob to remind you to go to sleep before you die)
I write C for a living, and enjoy it, but then I do systems level stuff. I would hate to write a modern application in C. It'd be crazy. Java or C# would be pushing it too, they're just not high-level enough.
Take for instance a "modern application" like gtk-gnutella. It is developped in C. Other Gnutella clients exist that are developped in Java. I claim that it is because gtk-gnutella is in C that it is more efficient for the end-user (in terms of memory footprint, CPU usage).
True, a Gnutella client can be seen as "low-level" because it essentially runs close to the system: it manipulates sockets and files (I/Os), and implements network protocols (with the need to construct and decompile complex binary packets).
However, being written in C is not a burden, it's a breeze.
"C and C++ becoming less popular with web developers" != "C and C++ becoming less popular in general". After all, Python, Ruby, Perl and other interpreted languages are all written in things like C or C++, I assume. And the convenience of automatic garbage collection is offset not only by the system overhead it causes, but also by the diminished of control over what goes on in your system, memorywise.
Printer? Luxury!!!! When I were a lad, we punched 'oles in our own palms, as we didn't even 'ave punchcards yet.
Most people use the STL just for dynamic arrays and maps. If you're a half decent programmer its not too hard to role your own (though admittedly a nuisance to have to do so). So no , I wouldn't say knowing the STL is a minimum requirement for programming in C++, in fact for many years before the STL came along C++ chugged along quite happily without it.
".I know it can be done, but C is hard to program for a single core"
I think the translation of that is "I find C hard to program" since single core processors have been the default for most people using C for the last 20 or so years!
"Multicore support may take it over the edge."
Err why? You think programming multicore in C is hard , try it in assembler. At least with C you can always take the easy option and use threading libraries.
"At the moment, the C language standard is simply broken for multithreading"
Total BS. The pthreads library works and it works well and so do the equivalent libs on MS Windows. Just because you might find it hard means nothing.
"suitable language for multithreading. It's built into the language itself, like garbage collection is."
You mean it makes it easy for novices. Oh incidentaly , what language do you think the Java VM is written in? Java? Bzzzt , wrong. Its C and assembler. So how do they manage to get the threads working then? It must be magic!
Something else you might want to note is that some problems are best solved by multiprocess rather than multithread , and for that , really Java sucks badly.
Yeah, exactly. They're too large as well :)
you're forgetting that knowing C isn't the same as knowing all the library calls. Knowing C (or PERL/Java/Python/PHP/...) means knowing how to program in it. Knowing the way to approach it properly (you can write C code in Perl, practically. It's not really Perl then, though, and does things in a wasteful way), knowing when you have to do something and what that something is is knowing the language.
You have different ways of doing loops, different ways of defining things (C is a strongly typed language, as is Java [though it doesn't have unsigned...] but perl isn't). And each language does it differently.
"I have not coded a memory leak or buffer overrun in C++ in over six years."
That you know of.
"The best way to avoid overflowing raw buffers is to not use raw buffers. Use the containers. When you think you can't, think harder."
yes , nice soundbite , but in the real world things arn't always that simple. For example in network data processing you might have to read a packet header , check the size then allocate enough memory for the packet and read it in mapping a number of structure pointers onto the character buffer. Try doing that in any efficient way using the STL.
I know of at leat one VB6 app that is still in production. They need to split the VB6 from the VB.NET stats to make things clearer.
Every little niche language has its fanboys, especially in the web development world (no idea why , maybe the sort of people who do web development are more excitable than other coders) and ColdFusion is no exception. So there will be lots of "noise" about it on the internet and this is what this guy is picking up with his stats.
I feel C++ isn't quite as prominent as it once was. For UI development, I'm using Objective-C (AppKit) on the Mac and some Windows guys are C# fans. Quite a lot of older Windows code is MFC and the old Mac code is PowerPlant. It's always a case of the tool for the job. Here we write a lot of cross-platform code, well Windows and Mac, so C++ is the common denominator *and* the developers are familiar with it. It works... and if it aint broken, don't fix it!
It's unbelievable this company get's any attention with this index. Just some quick and easy points which have been glaring mistakes for years now: Vb is a combination of Basic, VB.NET, Visual Basic.NET, Visual Basic .NET, Visual Basic 2005, VB 2005, Visual Basic 2003, VB 2003, Visual Basic 2002, VB 2002.
Some of these, especially the .net variants are totally different languages with only superficial similarities with the rest. Including this in the index is nonsense. Secondly one has to wonder why .net in general is so underrepresented versus java. This can be explained an their data gathering method. They google for terms like +c# programming. This ommits an entire group of articles only targetting .NET This is because of the language independant nature of the platform. Some numbers to put this 'index' in some much needed perspective:
+java programming 8.320.000
+.net programming 13.500.000
+c# programming 1.260.000
+vb programming 618.000
+vb +.net programming 664.000
This is the only meaningful way to look at the relative popularity of java & .net. Java is not only a language but also a platform, so is .net. Furthermore the majority of programming (judging from these numbers i'd say about double) in .net is done in c#. You'd have to conclude that c# should at least be up there with java.
That is if you think counting the number of search engine results is a meaningful way to get an index, which I don't.
I think TIOBE is flawed. For real statistics I use indeed.com. It's the mother of all job sites, and it also does trending. http://www.indeed.com/jobtrends?q=%22C%2B%2B%22%2C+%22C%23%22%2Cjava%2C+Perl%2CPython&l= thats the view of the current job market. Perhaps C/C++ is slipping in some areas, but it will not go away. I work on Wall Street, and fast trading systems are written in either Java or C/C++. There will always be a need for speedy software. As for Perl/Python. Sure there are people using Python out there. I'm sure its a great language, but I haven't really found a reason to move off or Perl yet. Every systems engineer I know uses Perl. A while back some twit said that anything more then 100 lines of Perl becomes difficult to manage. This quote has gotten lots of publicity, but I don't agree with it. I've actually seen entire Quantitative Trading Systems written in Perl (thousands and thousands of lines of code) that were quite easy to maintain. The real issue with maintaining code is writing good code and commenting the code where it needs to be commented to begin with. Its really quite simple. As for not having a new release of Perl .. I fail to see why so many people make an issue of it. It works .. really well as a matter of fact. I could see getting my underwear in a bunch if it didn't work well; but it does.
I would be surprised, too, if they chose Python. Lightroom is already 40% Lua.
What is the problem on deciding what needs optimizing at design time? Really, unless you are using a very weard programming environment (like Bash or MathLab) you should have a very good grasp of what needs optimizing BEFORE you write any piece of code. At least, you should have as good grasp as are your requisites, what for code that needs to be optimized tend to be very good.
And don't come with "The Arth of Unix Programming says so". That is not an acceptable answer.
Rethinking email
Use STL for data storage (std::vector, std::string, etc.) and you'll never have to worry about malloc()/free() for that.
Use reference counted pointers for keeping track of objects and you'll never have to worry about remembering to call 'delete' when you've finished with them.
In short, don't ever use a raw C pointer for managing resources. Let the compiler do the work for you.
No sig today...
Pretty much, yes.
... not much else.
I use delete when I use the 'pimpl' idiom, and
I never use delete[] - because std::vector is *always* superior to new[]. new[] and delete[] could be removed from C++ with no harm done.
Doing It Right means a reference counted pointer whenever you use 'new' to make an object, STL for data storage (arrays, lists, strings).
If you do it The Right Way, C++ memory management becomes a dim memory of evils past.
No sig today...
Personally I don't think a second place for C is anything to complain about, but if you want to explain why Java is bigger, that's easy: Java is the language of choice for web development, and there really is a lot of webdevelopment out there.
That's where the growing market is.
C is becoming a niche language. It's the prime language for drivers, OSs, libraries and other low level technical stuff, but most programmers don't write their own drivers or libraries. They write applications, and preferably in a slightly higher-level language than C.
But C is still going surprisingly strong, considering its second place. And in its niche, it will probably survive for a very long time.
80x25?! You young'uns has the easy life! We thought we were living in luxury when we got our 40-column displays after having been forced to eek out on 22-columns for years.
Funny because although I'm only 21 I learnt to code in BASIC on a 20x2 screen. Yup, 20x2, on my little sister's V-Tech Genius 2000. That was in 1999.
You just got troll'd!
Besides the study being useless, it fails to make sense. All these high level languages, excepting lisp, can't be written in themselves. Everything underneath the web page (interpreters, web server, databases, OS, web browser) are all written in C or C++. For those winers that complain about working with memory, please stay away from C and C++, just admit your limitations. I don't want to have to come and fix the problems you amateurs cause.
Sorry my bullshit sensor overloaded.
For image processing (film/video), real-time audio or any serious signal processing, the overhead of anything but C/C++ is killer.
As a signal processing programming hobbyist (see link in my sig), I've gotta say, C is not just faster, it's ideal. Basically when it comes to C people grieve about lots of things, like poor text string handling or whatever. But when all you do is crunch numbers on big ass arrays using more or less advanced mathematical concepts and formulas in a fairly linear way, C is ideal and doesn't suffer any real flaw. Well that's coming from someone who learnt C through making signal processing programs, so YMMV.
You just got troll'd!
The GNU Ada compiler (GNAT) is self hosted [1]. Also I think there are several self hosted Pascal compiler.
Martin
[1] "self hosted": a compiler compiles itself when creating the next generation - of corse this is detail for the the particular implementation and not a programming language in general. And, ahh, version 0.0.0 is never self hosted - if push comes to shove it needs to be written in assember or hex code.
The last time I took a CS class in the 90s, the biggest problem the students had with programming was the concept of the pointer. The instructor really wasn't doing a good job at describing it, and none of the students were happy. What a blood bath come practical test time. No wonder these kids like to use managed languages.
There is no point in learing ANSI C (apart from academia) because one one minor compiler vendor has a full features ANSI C compiler to offer.
// do something
Don't belive me? then try this an despair:
void f (int *restricted a, int size, int c[size])
{
return;
}
Note: since I don't have an ANSI C compiler so I could not test the code, fix typos as needed.
Note 2: Both Ada and ISO Pascal (not Turbo Pascal) define var-arrays and all Ada compilers and at least one Pascal compiler have a working implementation.
Martin
Since the IDE tools were spun off into a separate company (CodeGear). Things have gotten more and more focused. We use D2007 as our primary delevelopment tool where I work and although from a documentation quality standpoint, it really was released prematurely, things have really improved, with regular updates to both the IDE and help system. It is at a level now where I feel completely comfortable committing to developing with this tool for our future applications.
At the same time CodeGear has released adaptations of their IDE to much hyped languages like PHP and Ruby. The company seems to have a sence of direction again finally.
Ada would be just as well suited for the task of low level programming.
Besided both smalltalk and lisp are implemented in, well, smalltalk and lisp. And yes, there was even a lisp operating system.
Martin
The problem with reference-counting pointers like boost::shared_ptr is that they introduce additional memory and computation overhead.
This is true. But in an argument about C++ squaring off against some other language, the other language usually also has an equivalent level of overhead. For instance Java GC is not "free."
And of course, no reference-counted solution can ever solve a memory allocation problem that avoids cycles (although I generally try to avoid circular data structures to begin with).
When I use cyclic data structures (which is not often) I just use weak pointers between the objects -- the objects themselves are owned by a supervisor container.
And of course, it's always possible to "leak memory" by simply forgetting to lose a reference to something that you don't need anymore. That's possible in any language.
Well Ada has been designed for embedded system programming in an high integrety environment.
Martin
Maybe you want to have a look at it:
http://www.adaic.org/standards/05rm/html/RM-D.html
Martin
and it has a damm side more features the Pascal. Have a look:
http://www.adaic.org/standards/05rm/html/RM-TTL.html
http://en.wikibooks.org/wiki/Ada_Programming
Martin
There's at least one gaping hole in the RAII paradigm: What if you want to throw an exception during destruction? (Not all resources can be freed without failure.)
This is a valid point. I'm not sure I understand how finally{} can solve it, though -- can you elaborate?
As far as resources which might fail to be freed, these things seem few and far between, and I just try to accept that dealing with those kinds of resources is more complex and error prone than other resources. Not everything is cake, but most of it is.
I would think that a modern Fortran or Ada compiler would be just as fast for the task you described. I fact they could be faster since the have propper arrays which can be optimised much better.
And just because K&C could not a write compiler optimiser it does not mean no one can.
Martin
Surprises are actually language-independent. Any complex construction may show up "surprising" behaviour. In C++, the syntax sometimes makes it even worse; typos may result in valid code (like an unintended invocation of the comma operator) that crashes at run-time.
I'm not saying C++ is the zenith of programming. I am saying, however, that there is absolutely nothing that can replace its entire range. Subsets? Sure, Java and C# are subsets of C++' expressiveness. But the entire range? You have to glue several languages somehow, and this is awful and often very inefficient.
I think the future of programming languages (which is actually a blast from the past, like 90% of all programming "novelties") is actually present in C++ already, but in an ugly fashion: languages that adapt themselves in a metalayer to the problem. C++ can do this, although its a huge PITA because of the template syntax and error messages. Lisp is king there, but AFAIK cannot do this at compile-time. Python, too, can do this. Java and C# lose here. This is why many features that need to be built-in in Java/C# are often realized by writing a library in C++, Python, Lisp.
As of "by design", I fully reject "dumbing down by design". Java isn't a sane subset of C++, it threw away key advantages. Thanks to missing real generics, it is absolutely impossible to write truly generic stuff in Java. You could never ever write something like Adobe's GIL or Antigrain with the same efficiency. Example: two vector classes that both have 3 floats, xyz; they are identical, but thanks to missing true generics, I have to write glue code, or agree on a base class, which is very problematic. In C++, I don't NEED glue code at run-time; I may need some at compile-time, but it is optimized away. People keep shouting at the JIT compile stuff and forget important things like this. Well, hopefully Java 7, 8, whatever, will include them.
This sig does not contain any SCO code.
The problem is that you can't tell the system when to collect garbage. So you may find that during a critical section your VM stops everything and starts collecting up the garbage and throwing it out.
That is completely false. Even with a regular garbage collector, you can disable the garbage collector when you want/need to. Concurrent garbage collectors don't stop the system at all. And real-time garbage collectors give you precise upper limits for every memory allocation.
If you manage memory yourself, you can prove that your system will not do this.
That, too, is false, in two ways.
First, having a garbage collector doesn't prevent you from doing manual storage management.
Second, malloc/free and new/delete can have arbitrarily high latencies, and they do in practice.
Thanks.
Stick Men
Yeah, optimizing at design time only works if you are solving a problem you understand completely. That means, you have all the requisits (you don't need to implement it to understand it).
Conveniently, most software that deserves being optimized (games being an exception) have quite strict requisits.
Rethinking email
Java beats C++ only if you have to create every single object in C++ with the new operator. I have to concede that the JVM memory allocator is amazing, and the new operator in C++ is not as good as it should be. But I also have to note that the benchmarks I have seen use C++ like if the stack was not there.
If you can put all those objects in the stack, C++ easily outperforms Java by a factor of 20-60.
So it actually depends on how many objects you need to create in the heap and how many can reside in the stack. In other words it depends on the program you're writing.
We are Turing O-Machines. The Oracle is out there.
*FURIOUS* Firstly, don't buy into the hype about GC ... managing memory isn't rocket science if you know what you are doing, which I am sure most of the haters don't know / care about - all they can do is throw in snippets of crap from time to time and not actually DO anything about it (i.e. pick up a book and RTFM) - when is the last time they have used smart pointers? ... (ask them what a pointer is - they will just say I DON'T NEED TO KNOW ABOUT IT) ... no you don't need to know about economics of software/hardware either
With the release of C++0x there is more standardization of stuff (like threading) that is already available (look @ boost.org) ... most people who bitch about C/C++ never could finish their 101 programming assignments.
meh!
more on pointers:
http://chemivar.blogspot.com/2007/12/do-not-fear-for-smart-pointers-are-here.html
also that list is rather bs, it doesn't factor in the importance of the projects, take a look around - everything runs on C/C++ developed code.
It's true, and I was impressed with Delphi for PHP. Admittedly, I've only tried it for a few minutes, but I was expecting an absolutely useless mockery of an IDE, instead I got the impression this thing could actually build a web app on short notice.
If I weren't drowning in CF filth, I might actually take Delphi/PHP for a spin one of these days.
-Billco, Fnarg.com
It isn't? Let me give a little example of what you can do in C++.
There's this concept called, "Turing complete."
Stick Men
You can write bad code in any language. You can also write code that is difficult to maintain in any language. In the long term, C as used in Unix wasn't the cleanest or most reliable,
When Microsoft and Intel decided programmers couldn't be trusted to write native code, it was a sad day indeed, and dot net seems to me to be about keeping the programmer away from the iron. That is especially bad for someone like me who was most comfortable close to the iron. In my experience, the projects I worked on that were complete failures, happened because of changes to underlying software interfaces, and not problems with my understanding of hardware I was trying to control. Take for example my attempt to implement Concurrent DOS 386 on an Altos server. After years of successful implementation of XIOS code controlling hardware, the XIOS for the Altos had to interface with buggy software supplied by a hostile group at Altos. In the middle of the project, Altos lost the source code of their part and redesigned and re-implemented the software layers controlling the hardware, and the basis of my adaptation changed out from under me with no notice.
When youj write code with dot net and it doesn't run right, who is at fault. Is it you, or the compiler, or the runtime implementation. At least with the real hardware, you could use debugging tools, logic analysers, and in-circuit emulators to get to the bottom of problems. When you write programs that are complied into pseudocode that is executed by runtimes implemented by a closed source single source vendor and you have problems, you are screwed.
For me, programming is about writing code that manipulates data and produces results. Someone familiar with the problem domain should be able to read the code.
At the point where Microsoft outlawed real programming, I bought a big Macintosh workstation with lots of cores, a huge amount of memory, lots of hard disk, a Unix compliant operating system with a nice GUI on top. It has an assembler, and a C compiler for classic computing. It has Cocoa and objective-c for Apple specific application work. Vista and all future Microsoft operating systems will not appeal to me as computing platforms, since what they really are, are execution platforms for Microsoft products.
What turned out to be important for me was efficient reliable platforms with efficient reliable language tools to create and run software that solved problems in a way that could be relied upon for business and personal use. Every time I look, Microsoft has broken something I need for business, and in the last ten years, it has most often been the development software and it's interfaces to the operating systems services.
Is that you Jesus? No people I know claim that level of perfection in the real world. Someone is in denial. I can only hope the programming skill exceeds the skill with the English language since I cannot tell whether the above posting is a joke or a serious remark.
I have read here that languages with garbage collection are becoming more popular than languages without. I can only interpret this to mean that keeping track of your program's allocations is considered too much work.
Real programming is not simple, or effortless. It is necessary to learn, to think, to design, to improve.
People who like to program in BASIC should not be given the task of deciding what is a good programming language. If all the programming left for us to do by Microsoft can be done in BASIC, our job as software engineers is over and we might as well retire.
There's always going to be a need for things like algorithm research, so I'm not convinced that what you refer to as the "how" should be left behind. I don't doubt that it's happening at many schools. I just don't think it's a good idea. CS should be CS--a primarily mathematical pursuit. Programs which teach other things, which I freely grant are just as valuable, should have other names.
There's certainly a lot of "what" going on right now, if I have your meaning right. Witness the seemingly endless creation of frameworks, and even nested frameworks. If I really have your meanings right, I'd have to say that mistakes are being made in lowering the CS bar, while simultaneously failing to teach exactly what is involved in creating and using good frameworks, libraries, and other pragmatic programmer's toolbox items.
I'm not saying that there shouldn't be commonality. If I were to formally describe Kerberos, for instance, I'd want a programmer to be able to implement it, not depend upon being able to do calls into a lib, which may not exist. I'd want that programmer to be able to know how to sanely construct that lib, if it didn't exist.
I've seen a couple of recent grads who could do neither of these things. One of them didn't really seem to know much about Big-O notation, so there were basic communication problems. That was scary enough that I'm glad I don't have to work with them as a day-to-day thing. Neither seemed particularly interested in learning, either; they apparently saw themselves as some sort of 9 to 5 meat IDE-driver, and would do nothing but increase my workload.
I certainly don't agree with everything in the GP. I could completely get my rant on, about portions of that post. But I don't entirely disagree with it, either, and I don't think it should have been modded flamebait.
What you do with a computer does not constitute the whole of computing.