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.
C-what-what?
The CB App. What's your 20?
I realize companies can't be jumping to the next big thing overnight, but really, the tradeoff was in favour of garbage collection 10 years ago.
I am trolling
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++.
C programmers are a bunch of cynical old men. We don't have an irrational love of our favourite language. It's simply a tool for a job.
If python or Ruby or Java does the job better, or faster, or more easily, then use that language. They're just programming languages.
Almost as bad as Jeff Atwood and Joel Spolsky calling them "dead languages" on their new podcast.
The cake is a pie
I wonder how much of the Visual Basic and C++ are the .NET variety?
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.
C++ manages memory for you, simply use boost shared_ptr/weak_ptr. Also, GC's are available for C++ (and C).
Too bad so many people can't use _modern_ c++
It's turing complete, after all. And there are myriads of scripts around in the (virtual) world. ;-)
Nerdy by Nature!
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.
As long as there is such a thing as an embedded computer, C and C++ are here to stay. Or tell me - do you have a plan to make your eight core Mac control the anti-lock brakes and airbag in your car?
...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.
>Are C and C++ Losing Ground?
I sure hope so. Honest, I'm not trolling here, I'm just tired of C's religious zealots refusing to consider alternatives. C is a fine replacement for assembly language, but why the hell would you write a web server is assembly? Then why the hell would you write one in C? It's *good* that some languages make it easier to write good code, and harder to write bad code.
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.
"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.
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
C is a systems language, and it's very good at it. Gone are the days of 8MHz desktop computers when we needed C for writing applications.
C has its place, and C++ isn't all it's cracked up to be.
I hope they are becoming proportionally less popular than other languages, because otherwise we aren't making progress.
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.
Stick Men
For 99.9% of applications out there, you do not need C. Nor ASM. For the uttermost techy stuff, like, say, the gurus working on OS kernels or hypervisors, then ASM and C still rule the day. Any day.
;)
But once again, for 99.9% of apps out there, what is really needed is: a bullet-proof virtual machine (it's 2008 and I'm pissed off by all these buffer overrun exploits/null exploits/you-name-it that are simply a thing of the past in a good VM) and great libraries.
It's obvious that this discussion is at the 3GL level, so pick Java, pick C#, pick Scala or any language targetting a bullet-proof VM and you're good to go (that said not too sure about C#/.Net being as robust as Java/JVM... Last time I checked the Real World [TM] --as in bank transaction etc.-- wasn't running on MS technology
I think there's no excuse today to produce something, say in Java or Scala, that runs under a JVM, that is notably slower than the C counterpart.
It's even less forgivable to spout "but Java applets failed" and "Java makes my browser crash" nonsense in 2008.
Did you write a Webapp that comes even close to GMail? What is GMail written in yet? Did you write something that comes close to GWT? What language do you need to use to interface the GWT API yet? Did you write several of the planet's very best IDEs ? What are these written in yet? What is the language that is going to be used by independant developer to port apps to the new Android phones (LG, Samsung, Motorola phones etc.) ?
Can I do remote profiling of your app as easy as 1-2-3 ?
Really guys, wake up. What language/VM is powering the Real World [TM] ?
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.
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.
Yet another reason not to use a web server written in Java.
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.
The Next 50 Programming Languages
The following list of languages denotes #51 to #100. Since the differences are relatively small, the programming languages are only listed (in alphabetical order).
I guess that we HDL guys have our work cut out. Mark my words-- we will catch up to C/C++.
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.
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
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'm curious how it is lighter, exactly.
* In C you would set up an array of function pointers to represent your virtual methods.
* In C++ the compiler would set up an array of function pointers (maybe we'll call it a 'virtual table', if you will?) to represent your virtual methods.
Also, what sort of additional capabilities are possible with C OOP? Changing methods at runtime? That is the only thing I can think of off the top of my head, and that is covered by delegates/interfaces in C++ and Java, respectively.
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"
...though I'm having a hard time taking it seriously:
Logo (that thing with the turtles?!) is more popular than either Bash and Awk, both of which are apparently less popular than Fortran. At the top end of the list, Pascal beats all of these hands down, whilst the more popular C++ gets a good hammering by Visual Basic.
WTF?
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
It says Pascal jumped from #21 to #15. That seems pretty dubious to me. I've got nothing against Pascal - that's almost all I used in college. I just can't imagine that many projects deciding it was just what they needed.
It's simple: I demand prosecution for torture.
Hopefully someday we will have hardware that allows us to write the OS in a higher level language. I still have an old ChineUal so I know that it can be done.
C and C++ are nothing more then portable assembler. Applications developers have no reason to get so close to the hardware.
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?
Another year and I'll finally be able to throw away my Ada generics.
Okay I took a look at that list. All I can say is what!!!!! .77%
C++ fell
C is still number two.
And list rates what? Search engine hits?
D is ranked 12???? who the heck uses D?
As to garbage collection vs manual memory management I have to say that I do like managed languages but feel there is room for both.
But if you want grabage collection in c and c++ you can get it.
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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.
I was interested to see D rated 12th. Is anyone here using D for real projects? If so, do you like it? Do you see any chance of it gaining traction?
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.
I knew the c/c++ flamers would come out to my comment but no one can see beyond a local computer doing their processing? think 20-30 years from now, you will not have the desktop operating system you know today running c and c++. you will be using the internet as a medium for every bit of your computing needs; centralized computing requiring 1 big ass server that might run on the underlyings of c/c++ but no desktop nodes will be needed, just an internet connection with a hard drive making c/c++ very minimal for any useful task at that point.
:)
mark my words haters
PS. the irony of my captcha: dinosaur
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.
Oh, not another one of these. (sigh)
Fine. I'll throw this in: Most stuff runs on or is implemented in C or C++. Adoption rate != deployment rate != growth rate != use rate != "ground".
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.
The article misses the latest trend, which is programming directly in binary by flipping switches back and forth.
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...
If you notice the numbers, C and C++ combined outdo Java.
:) ). So when they (ahem, we) find something better, I'll definitely use it. But not until then.
I'll switch from C when the UNIX/Linux kernel is rewritten in something else. Kernel engineers tend to be the best programmers around (sorry, that's not intended as a troll - just extreme personal bias
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.
C is not going anywhere, nor is C++, nor perl. Java and C# are both terrible implementations that fulfill the same need (badly).
Posts from this one keep getting modded troll and flamebait.
Stick Men
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.
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...
Apache, Perl, Python, Ruby, MySQL, etc... are ALL written in C or C++. What a stupid, uninformed claim to make!
...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."
in what, now?
hmm
The Kruger Dunning explains most post on
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?
Surveys like this can't tell which languages are used for serious, valuable code vs. cookie-cutter crap. That explains why VB keeps bobbing to the top.
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.
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.
To paraphrase our master, the late prof. Edsger Dijkstra:
.NET/Java) can be just as painful as tracking memory leaks in a C++ program.
"It is practically impossible to teach good programming to students that have had a prior exposure to [edit] garbage collected languages [/edit]: as potential programmers they are mentally mutilated beyond hope of regeneration."
Garbage collected languages are pretty nice tools for the professional programmer. As a learning tool for students they are a disaster. You really need to be able roll your own memory management etc., before getting the go-ahead for C#, Java or what not. But that's one thing.
Garbage collection isn't a silver bullet that automagically kills all memory management worries in real-world systems. Far from it. And I'm not talking about the performance aspect at all.
Debugging memory (exhaustion) problems (yes, there is such a thing, even in
The major difference here is that the garbage collector is, unfortunately, a Black Box and to get on top of things you need to infer things about its workings and your problem _indirectly_, from system statistics (performance counters, anyone?). It is not unheard of that in order to really get to the source of the problem, you just might have to analyze an IIS/ASP.NET core dump with WinDBG.
At that point, all that Java/VB/C# mastery is worth nothing. One needs to grow a pair of good old-fashioned programmer's balls.
C and C++ aren't going anywhere. The post-Web 2.0 world will still need expert programmers.
Nothing more. This is basically a list of languages getting the most press coverage. You know, people making blog entries and all that.
I can tell because there is no way in hell D would be on there if it wasn't. It's a curiosity with a bunch of people making a lot of noise. It is not being used all that often for serious applications.
Meanwhile the C/C++ programmers are silently hacking away. See, C and C++ have been around so much that it's just taken for granted. Tons and tons of people use it but there isn't much noise because it is what it is. It is the base of practically everything running your computer right now. If you're using Python, Perl, Java, and C# then you're using code written by C and/or C++ programmers. (Lua is by far the best scripting and extension language available by the way)
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 ...
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'
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.
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.
My high-level language of choice is pretty much anything other than Python. I like the whitespace thing, but I can't use a language with such broken scoping rules.
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.
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...
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.
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
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.
In the past, people used to use C to write desktop programs.
Today, people use C to write embedded programs and high-level languages for desktop programs.
Tomorrow, people will use C to write program for nano-scale devices and high-level languages for embedded.
After tomorrow, who knows?
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 ]
There is no XML, CSS on the list. This list can't be serious!
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!
A list of fashionable languages is about as stupid as cars that honk their horns when you lock the doors.
All it says is that, as usual, operating systems, languages, drivers, and other serious software are still written in C, and all the silly-ass shit is written in whatever the kids find exciting this week.
If more silly-ass shit is being written than operating systems, then C moves down the list. So what?
Would you want an operating system written in Ruby? What is Ruby written in? (Hint: the answer starts with the letter 'C'".)
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.
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.
python => c => asm
different layer do different things
no one for all
sorry
'The chance of running into all kinds of memory problems is gradually outweighing the performance penalty you have to pay for garbage collection.'
Always benchmark before making assumptions about performance. Here the benchmark is pretty simple: in a garbage collected language, allocate N objects in a loop, making N big enough so that several gc's are performed. Then do "free(malloc(sizeof whatever))" or "delete new whatever" in C and C++.
I find common (Windows, Unix, Linux) implementations of free/malloc are ten times slower than gc-based memory management.
I do not expect the myth to go away, of course. Too many people like obsessing about object destruction and RAII. Like back when compilers weren't very good with register allocation, people liked obsessing with register declarations.
It takes too long to compile a large C++ project.
No reflection.
Poor error messages.
For a long time, non-standard compiler implementations.
Lack of garbage collection was never an issue.
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.
Why people prefer "garbage collector" than manage by themselves it? Some of them have a deep knowledge about what they are saying and have technical arguments to defend languages like Java and so forth.
.Net and similar, the programming profession is so bad payed. Everyone can code. And even code is bad, hardware is strong enough to make the illusion the application is running properly.
Other, and sadly it's the biggest one, prefer GC because they are literally incapable to code as a professional. Java brings to the programming scene the possibility that many people without a strong background, now are able to code.
That's too bad and that's why, due technologies like that, Java,
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.
How much serious software is written in an interpreted language compared to the ones in C/C++ ?
As far as I know all the major OS kernels are done in some variant of C/C++ including: Linux, BSD, Windows, Plan9, OS/2, OSX...
What was the last graphics intensive game you had that was done in something other than C/C++?
What heavy traffic Web site hosts their pages with a Web server written in an interpreted language?
Which X11 server is done with an interpreted language?
Last I checked the top 5 database engines aren't programmed in interpreted languages.
I can't help but get the impression that only toys are done in something other than C/C++ while anything significant is done with the Cs. Yeah, most software we use today are toys and can be handled with interpreted languages. You want to connect to a database, grab some query results and show it on the screen, no biggie. You don't need C/C++ to do that.
It's irritating to see people whine and try to drive away things they don't understand. Seriously? You can't handle allocating memory and managing it yourself? I'm thankful that the mechanical engineering industry isn't as lax as the software industry is with all the ignorant developers out there. Why ignorant and not lazy? Lazy developers are fine, they're the ones that know to work smarter not harder.
Use the right tool for the job. If most software in use today can be done well with an interpreted language then by all means use one. That also probably means that most developers out there aren't developing anything really serious. Quick trumpeting the death of a toolset that you have little experience with.
Come back when your fancy language tool chain doesn't rely on good ole' C/C++ at some stage. I think C/C++ will start to die when the operating systems are done in something other than C/C++. At that stage, people will want to talk to the kernel in its native language and switch accordingly.
You think the C folks are shaking in their boots because they might have to learn Java, C# or the language du jour? I don't think so, for them it's just a shift in paradigm and syntax. One the other hand, watch the other guys give you the deer in the headlights look when you want to do something outside their little sandbox.
Just like in the real-world, languages evolve and some become obscure dialects with only a few pockets of the population using them on a daily basis. And just like the real-world there will always be many languages each with it's own distinctive flare. I know some people that can speak five languages and I also know some people that haven't mastered their own native language.
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.
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?
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!
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.
I don't think it was ever popular to write web sites of any kind in C. With the traditional and ever popular 3-tier/database centric web enabled approach there are many choices avaliable. Queues and query languages, browser langauges, web frameworks and associated scripting languages. Utilizing the right combination of the set ususally yields good results in a given web project because separation of concerns is promoted by the environment itself.
Now if you look at each tier in your stack chances are most or all of it was written in C.
I think the problem with these surveys is theres a heck of a lot more people doing web sites and scripting nowadays than working in the commercial application space as full time developers.
Unfortunately the existance of 'jad -p' outright disqualifies many really nice but interpreted languages from concideration in the commercial space.
In the real world "memory leaks" are the least of your problems. The technology does not exist to garbage collect expensive items such as connections, transactions, synchronization objects...etc in any manner that approaches sane and reasonable. Until this changes GCs appeal while useful will remain limited.
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)
There must be an error. I cannot find Fortran in the list. Please try to correct. I guess Fortran should be at least in the first 5 places.
"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.
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.
If you manage memory yourself, you can prove that your system will not do this.
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 believe that, if, as a programmer, you don't find joy in the low-level languages and workings of computer systems, you either aren't properly educated or are in the wrong field completely.
Programming expertise is not a bag of tricks type of thing. It is a way of thinking and understanding. This is applied mathematics.
Visual Basic was the single largest blow to undermine the foundations on which the programmer's profession is built. By dumbing down the tools, you're dumbing down the average programmer. I think there is an inherent complexity to programming that should be appreciated by all practitioners.
Programmers trained only in Java/C#/VB lack the way of thinking part. Given a problem these people search google for a copy-paste solution or a godsend tutorial, a "trick" to make the problem go away and then move along.
Deep understanding and broad knowledge are a prerequisite for effective problem solving skills.
A true programmer isn't happy with a code snippet. He wants the parts of the problem specified. He wants to understand the solution before using it. Well-written and detailed API references are enjoyed by the this type of programmer. He knows the devil is always in the details and if the specification is low on details, he won't be happy. Exactness and correctness are appreciated.
I think the correct way of thinking part needs to be grown from the bottom up, starting with lower-level languages and lower-level problems. After you appreciate the complexity of it all and know your way around, you're ready to cut corners, save time and use Java, VB or C#. And.. what's important, you're ready to solve the problems you WILL face in production systems written in these languages.
Hating the details, the complexity of C/C++ programming is hating the soul of computing.
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...
So it's blindingly obvious. Anything that you can do in C++ or Python or any other language is very possible in C.
The Linux kernel is huge project, worked on my thousands of individual programmers, hundreds of corporations. They have a average of around seven _thousand_ lines of code change (additions and deletions) PER DAY.
And on top of that its all hugely object oriented Seriously. OBJECT ORIENTED with not a lick of C++ or any other object oriented language.
Does (not yelling at fyngyrz) THAT COMPUTE, people?
Object oriented programming and code base without using a object oriented programming language? (OMG)
Over and over again people will quite happily tell you that 'Java' or 'C++' or C# is what you need if you want to do 'enterprise' work. Also you _need_ big IDEs and all sorts of stuff.
HELL NO YOU DON'T.
Your organization may require it because of politics or management requirements.. but it certainly has ZERO to do with any technical or practical requirements.
The deal here is that high level languages are used because _they_are_easier_to_READ_.
Get it, people? Easier to read.
High level languages are quicker to prototype applications.
You WRITE YOUR APPLICATION FIRST. DO PLANNING SECOND. And high level languages are there to facilitate that and make this painful step as fast as possible.
The problem is is that unless you write your application first you don't know what the technical requirements are going to be for that application.
You can guess, but your going to be wrong and if you establish a application design without knowing what that application is going to require then your going to end up wasting all your time force feeding a square application into a round design document.
So ideally you write your app first, quick-n-dirty. It'll be slow and buggy and in a high level language. Then you write your design and planning based on the lessons you learned from that.
Then you rewrite it with the better design and use a mixture of languages or whatever is most appropriate.
The most important part is making your program easy to read. If it's easy to read then it's easy to understand and programmers working on your code are much less likely to introduce bugs. It should all be programmed in a as straight forward as a manner as possible. Optimizations should be avoided unless they can be proven that they will have a substantial impact on performance.
This is why I like Python. Easy to program, easy to read, easy to profile. Makes things quick to prototype and even if it's 70 times slower then C it doesn't matter because if you need speed Python loves working with lower-level languages. It's not like Java were everything needs to be 'java' in order for you to use in your apps.
It's a practical language, not a idealistic or uber-OO one.
For example: Cython/Pyrex. Lets you mix and match C programming with Python programming without the bullet plate code normally required to make modules.
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...
thanks
The problem with deciding what to optimize at design time, is that this only works if you are solving a problem that you understand completely (likely because you have solved it before).
For many problems, you will not have that sort of perspective until the application has been fielded for a while. Therein lies the benefit of deferring optimization until you have done profiling. When you optimize profiled code, you know what to optimize. When you optimize at design time, you're guessing that the optimization is appropriate. It may or may not be.
This article is such troll bait.
C. There is nothing competing with it. Period.
C++. Colleges that did chrun out VC++ grads will now chrun out C# and Java grads.
kthbi
typedeaF
There is another way to interpret this, which i think is much more valid. C is not losing ground, but it is being used by a smaller PERCENTAGE of coders.
Why?
For every systems programmer, there are a billion high level programmers working on business/communications-oriented projects. The applications for (and number of) high level programmers have exploded, which is reflected in the presence of php in this list.
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
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
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
Even so, Adobe has its dark side. Judging from the Adobe Flash *player* Linux implementation, it feels like they wrote it in the slowest imaginable way and upped the Minimum Software Requirements instead. Any SWF, especially when with embedded video, displays slower than Mplayer, and you DO notice that on millibarebones (no more than 1.2 GHz). -- Most likely no accelerated video decoding (e.g. SSE/SSE2), no display acceleration (should be Xv at the least, though XvMC would be better)...
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
We have two "camps" in our company: the "server guys" who are programming in C++, and the "application guys" who are programming in C#.
The C# people scoff at us "legacy programmers" (very sneaky subconscious marketing by Microsoft), but the interesting thing is that they come to us for advice when their C# applications leak memory or have hideous performance.
Here's what I think about C#: http://www.curly-brace.com/favorite.html
By the way: TIOBE is hired by our company and their product "TICS" is used to track software quality ("quality" as in "conformance to coding guidelines").
*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
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.