Why C Is Obsolete(softdevtube.com)
softdevtube.com
Why C Is Obsolete
http://www.softdevtube.com/2011/12/27/why-c-is-obsolete/#.TvsbHrIzPSI.hackernews
74 comments
If you now wanted to have polymorphism, you'd have to do even more work in the function, which would probably involve looking up a function pointer in a table and invoking that (i.e. Linux VFS). If you didn't start out wanting polymorphism, but then wanted to add it, C++ is way less work to do it.
Why code this all by hand when the language can do it for you at no penalty? The only penalty I see in C++ for using classes or polymorphism is that it produces longer symbol names (w/ the type mangling)
You also get destructors that let you have convenient clean up of locally-allocated data (boost scoped_ptr), which helps make sure you don't leak memory/reduces bugs/reduced thinking required.
That's all possible without pulling out massive standard libraries or using slow-compiling/hard-to-diagnose template-based libraries (merits of those I leave undiscussed).
My biggest problem with C++ is a lack of a standard ABI (perhaps this has been addressed by know, it's been a while). C libraries are dead easy to link to. You know what you're getting. C++--not at all, unless you live entirely in the same compiler ecosystem.
One of the biggest perceived problems with C++ is that people start thinking: "well, now that I am using an OO language, it's time to write some classes!" Of course, just because you're using classes doesn't mean you're doing any useful object-oriented programming.
If you're attempting your next project in C++, coming from C: only use those features of C++ that directly benefit you. Follow YAGNI. If most of your program is in flat procedures, alongside some objects, so be it.
Side rant: Consider that C++'s real uptake was in mid-90's, just as UML-ish diagrams began taking hold along with a massive rise of overdesign and no culture of agility. This led to massively overdesigned C++ apps. I'm sure the C developers were sitting there and wondering "Why the hell do I need all these classes? This used to be so much simpler." (I know I was.) Think about the horror that was J2EE--the same kind of thinking that led to J2EE also permeated C++ development at the time.
Right now, you'd have to do a lot of convincing to get me to write native code in straight C again.
Why code this all by hand when the language can do it for you at no penalty? The only penalty I see in C++ for using classes or polymorphism is that it produces longer symbol names (w/ the type mangling)
You also get destructors that let you have convenient clean up of locally-allocated data (boost scoped_ptr), which helps make sure you don't leak memory/reduces bugs/reduced thinking required.
That's all possible without pulling out massive standard libraries or using slow-compiling/hard-to-diagnose template-based libraries (merits of those I leave undiscussed).
My biggest problem with C++ is a lack of a standard ABI (perhaps this has been addressed by know, it's been a while). C libraries are dead easy to link to. You know what you're getting. C++--not at all, unless you live entirely in the same compiler ecosystem.
One of the biggest perceived problems with C++ is that people start thinking: "well, now that I am using an OO language, it's time to write some classes!" Of course, just because you're using classes doesn't mean you're doing any useful object-oriented programming.
If you're attempting your next project in C++, coming from C: only use those features of C++ that directly benefit you. Follow YAGNI. If most of your program is in flat procedures, alongside some objects, so be it.
Side rant: Consider that C++'s real uptake was in mid-90's, just as UML-ish diagrams began taking hold along with a massive rise of overdesign and no culture of agility. This led to massively overdesigned C++ apps. I'm sure the C developers were sitting there and wondering "Why the hell do I need all these classes? This used to be so much simpler." (I know I was.) Think about the horror that was J2EE--the same kind of thinking that led to J2EE also permeated C++ development at the time.
Right now, you'd have to do a lot of convincing to get me to write native code in straight C again.
> Why code this all by hand when the language can do it for you at no penalty? The only penalty I see in C++ for using classes or polymorphism is that it produces longer symbol names (w/ the type mangling)
There are other penalties which people who write C++ are oblivious to. For example, switching the class of an established object in runtime:
Suppose you have two compatible class layouts (same field order and types, different methods). When you implement dispatch yourself, switching the behavior is a simple matter of replacing the vtbl pointer from one class to the other (I'm not sure Linux VFS does this, but it's common enough in C object systems).
Whereas if you use C++, the standard solution is to break this into a dataless "strategy" object (which can be changed independently of the data) and a data object which contains the state. If you never had the luxury of doing something like "if (obj->class == Living) obj->class = Zombie", you don't miss it, but it doesn't mean you're not missing out on some flexibility.
> Of course, just because you're using classes doesn't mean you're doing any useful object-oriented programming.
Furthermore, just because you are doing object-oriented programming doesn't mean it is useful. (And a purist would say, just because you are doing programming, doesn't meant it is useful)
> Right now, you'd have to do a lot of convincing to get me to write native code in straight C again.
I've switched to C++ in 1993 and back to C in 2004 when compile times with boost started to measure on a geological time scale and single error messages spilled onto my 2nd screen -- and haven't looked back. When a write GUIs, I do use FLTK which is C++ (very effective, but not idiomatic), because I haven't seen a GUI toolkit as good that's native C -- but other than that, I don't miss anything, and I'm not less productive.
C++, the language, has a lot of useful tools, but C++, the ecosystem, guarantees that in any nontrivial project you'll be thrown into the tarpit. In my experience, the overall effect of C++ on a project is negative. YMMV.
There are other penalties which people who write C++ are oblivious to. For example, switching the class of an established object in runtime:
Suppose you have two compatible class layouts (same field order and types, different methods). When you implement dispatch yourself, switching the behavior is a simple matter of replacing the vtbl pointer from one class to the other (I'm not sure Linux VFS does this, but it's common enough in C object systems).
Whereas if you use C++, the standard solution is to break this into a dataless "strategy" object (which can be changed independently of the data) and a data object which contains the state. If you never had the luxury of doing something like "if (obj->class == Living) obj->class = Zombie", you don't miss it, but it doesn't mean you're not missing out on some flexibility.
> Of course, just because you're using classes doesn't mean you're doing any useful object-oriented programming.
Furthermore, just because you are doing object-oriented programming doesn't mean it is useful. (And a purist would say, just because you are doing programming, doesn't meant it is useful)
> Right now, you'd have to do a lot of convincing to get me to write native code in straight C again.
I've switched to C++ in 1993 and back to C in 2004 when compile times with boost started to measure on a geological time scale and single error messages spilled onto my 2nd screen -- and haven't looked back. When a write GUIs, I do use FLTK which is C++ (very effective, but not idiomatic), because I haven't seen a GUI toolkit as good that's native C -- but other than that, I don't miss anything, and I'm not less productive.
C++, the language, has a lot of useful tools, but C++, the ecosystem, guarantees that in any nontrivial project you'll be thrown into the tarpit. In my experience, the overall effect of C++ on a project is negative. YMMV.
>In my experience, the overall effect of C++ on a project is negative. YMMV.
Curious: What's your domain?
In video games where there are a lot of "objects" floating around that can really benefit from polymorphism, the type checking that C++ can do that C can't really gives you a huge development bonus.
Of course I'm saying this having moved past C++ for 99% of the development into an elegant and tiny scripting language called Lua, where you can do just about anything (including having an object system that you can change an object from one type to another trivially if that's what you want).
Curious: What's your domain?
In video games where there are a lot of "objects" floating around that can really benefit from polymorphism, the type checking that C++ can do that C can't really gives you a huge development bonus.
Of course I'm saying this having moved past C++ for 99% of the development into an elegant and tiny scripting language called Lua, where you can do just about anything (including having an object system that you can change an object from one type to another trivially if that's what you want).
> Curious: What's your domain?
I switch every couple of years. Most recently: Image analysis; previously: Big data analysis; Before that: financial mathematics ("quant") and trading systems. If I go back long enough to '91-95: Game programming (SNES and PC); although I've been somewhat involved in game programming and related projects as late as 2008.
> In video games where there are a lot of "objects" floating around that can really benefit from polymorphism, the type checking that C++ can do that C can't really gives you a huge development bonus.
Only if your logic is written in C++ as well. In the projects I was involved with, most of the logic was actually data driven or scripted, and C++ contributes much less in that scenario.
I don't deny C++ has its uses. But it also has a lot of drawbacks. Whether or not the net is gain or loss compared to $LANGUAGE, is subjective. For me with $LANGUAGE=C, it is negative. YMMV.
I switch every couple of years. Most recently: Image analysis; previously: Big data analysis; Before that: financial mathematics ("quant") and trading systems. If I go back long enough to '91-95: Game programming (SNES and PC); although I've been somewhat involved in game programming and related projects as late as 2008.
> In video games where there are a lot of "objects" floating around that can really benefit from polymorphism, the type checking that C++ can do that C can't really gives you a huge development bonus.
Only if your logic is written in C++ as well. In the projects I was involved with, most of the logic was actually data driven or scripted, and C++ contributes much less in that scenario.
I don't deny C++ has its uses. But it also has a lot of drawbacks. Whether or not the net is gain or loss compared to $LANGUAGE, is subjective. For me with $LANGUAGE=C, it is negative. YMMV.
Hmm, a friend of mine from Criterion said that in two of the last games they did, they had to re-write the Lua parts (fairly significant) in C++ to get the framerate high enough as it's memory fragmentation was just too much.
They went from ~34 fps to ~60 fps for 4 developer weeks re-writing the Lua code.
They went from ~34 fps to ~60 fps for 4 developer weeks re-writing the Lua code.
Ask them if they were using LuaJIT2; they probably didn't -- it's relatively new (only been stable enough for real work for less than a year).
It is ludicrously fast. It usually loses to optimized C / C++, but by no more than 10-20% -- and you have essentially no restrictions whatsoever on the Lua features you use; Furthermore, it's FFI makes interoperating with C / C++ a superfast breeze, dropping the FFI overhead to zero.
And even ignoring LuaJIT2 -- they probably took less time and got higher quality overall by going through Lua (assuming programmers were equally versed in Lua and C++, and the infrastructure was reasonable) -- it's easier to iterate and debug with Lua than it is with C++.
It is ludicrously fast. It usually loses to optimized C / C++, but by no more than 10-20% -- and you have essentially no restrictions whatsoever on the Lua features you use; Furthermore, it's FFI makes interoperating with C / C++ a superfast breeze, dropping the FFI overhead to zero.
And even ignoring LuaJIT2 -- they probably took less time and got higher quality overall by going through Lua (assuming programmers were equally versed in Lua and C++, and the infrastructure was reasonable) -- it's easier to iterate and debug with Lua than it is with C++.
LuaJIT2 is awesome, but it still uses the Lua 5.1.4 garbage collector, so if the problem was GC related (i.e., memory fragmentation), then LuaJIT2 wouldn't help much.
OTOH, changing how you do things in Lua CAN be a big help in not generating garbage. I love the ability to ignore memory allocation in Lua, and I'm annoyed that I have to deal with thinking about it, but at least it's pretty straightforward.
Also, depending on the game, you can nuke your Lua allocation every level/section/other segment, allocating Lua memory from a memory pool. That can also help a lot with fragmentation.
But if you're doing a game that's one continuous experience, you have no choice but to be careful with managing memory. Again, it CAN be done from within Lua (think object pools), and that could be easier than porting to C++. And with LuaJIT 2, it would likely be fast enough in that case.
OTOH, changing how you do things in Lua CAN be a big help in not generating garbage. I love the ability to ignore memory allocation in Lua, and I'm annoyed that I have to deal with thinking about it, but at least it's pretty straightforward.
Also, depending on the game, you can nuke your Lua allocation every level/section/other segment, allocating Lua memory from a memory pool. That can also help a lot with fragmentation.
But if you're doing a game that's one continuous experience, you have no choice but to be careful with managing memory. Again, it CAN be done from within Lua (think object pools), and that could be easier than porting to C++. And with LuaJIT 2, it would likely be fast enough in that case.
You can of course implement the same functionality using either C or C++. I agree - the two implementations would be very similar. But I don't think this is the point Bjarne is trying to make.
C++ challenges you to think in terms of types instead of functions. This is in my opinion often a more natural way to approach and solve problems and thus produces more elegant code. Because of that, C++ is a very powerful tool for library developers - you can design libraries that allow domain-specific developers to write expressive code that performs as if you had written more verbose C code. And this C++ code is not only more expressive for your fellow co-workers to read and understand but also in some cases for the compiler. This is the reason why C++ code can sometimes be compiled to faster machine code: you can give the compiler more information about what you actually try to accomplish (keyword: template meta-programming).
As with most things there is no definite answer. C code can be quite elegant and appropriate as well.
C++ challenges you to think in terms of types instead of functions. This is in my opinion often a more natural way to approach and solve problems and thus produces more elegant code. Because of that, C++ is a very powerful tool for library developers - you can design libraries that allow domain-specific developers to write expressive code that performs as if you had written more verbose C code. And this C++ code is not only more expressive for your fellow co-workers to read and understand but also in some cases for the compiler. This is the reason why C++ code can sometimes be compiled to faster machine code: you can give the compiler more information about what you actually try to accomplish (keyword: template meta-programming).
As with most things there is no definite answer. C code can be quite elegant and appropriate as well.
I think the point he was trying to make is that a good language allows a library to be a "domain specific embedded language", in which an expert in some domain who is not an expert in the host language can do meaningful work. The matrix example is a particularly flattering one for C++, since a good matrix library in C++ will provide syntax that is quite close to the notation that one would use on paper for matrices.
The matrix example is a particularly flattering one for C++, since a good matrix library in C++ will provide syntax that is quite close to the notation that one would use on paper for matrices.
And it either (a) creates and destroys many intermediate structures or (b) templates everything by exposing the entire implementation to the user, resulting in slow compilation time and error messages that the domain expert couldn't hope to decipher.
And it either (a) creates and destroys many intermediate structures or (b) templates everything by exposing the entire implementation to the user, resulting in slow compilation time and error messages that the domain expert couldn't hope to decipher.
It's almost as if everything has tradeoffs, and engineers have to make them consciously!
Optimize when necessary. Until then, no need to mutilate expressiveness if the language allows it.
Optimize when necessary. Until then, no need to mutilate expressiveness if the language allows it.
Yeah, I'm not a big fan of C++, really. That said, (a) is mostly solved in 11 with rvalue references, isn't it?
[deleted]
I think the matrix example is particularly unflattering, and highlights the fundamental issues with the language. For once, there is no agreed-upon matrix library in C++, but many different ones. They are only "compatible" at a very low-level (a contiguous memory buffer), and the promises of performances often broken. The only one I know of that has been delivering on the performance front is eigen3, but I think the difficulty of the approach to become slightly ridiculous. When you need some "dynamic" optimization as done by eigen, C++ and templates are rather crude tools IMO.
> He explains that the languages should have been merged into one, so that C would have been a subset of C++ instead of nearly a subset of C++.
Thank the stars this didn't & won't happen!
Bjarne has been stuck in "C++ is the best & only language anyone needs" long after the world has moved on to Java, C#, Python, Ruby, JavaScript, etc.
C occupies a sweet spot combination of:
- low-level with "no magic"
- small enough for most people to "hold in your head"
C++ matched these conditions for a brief time in it's life - the early 90s aka "Stroustrup 2nd edition" - when the only "magic" was basic virtual functions, and templates where just a promising experiment in an appendix.
Thank the stars this didn't & won't happen!
Bjarne has been stuck in "C++ is the best & only language anyone needs" long after the world has moved on to Java, C#, Python, Ruby, JavaScript, etc.
C occupies a sweet spot combination of:
- low-level with "no magic"
- small enough for most people to "hold in your head"
C++ matched these conditions for a brief time in it's life - the early 90s aka "Stroustrup 2nd edition" - when the only "magic" was basic virtual functions, and templates where just a promising experiment in an appendix.
Here we go again...
C++ is used heavily from everything from Games, VFX programs (modellers, renderers/raytracer, compositors, paint programs), autopilot and control systems (cars, fighters (JSF), SpaceX are using it for their systems on their rockets), database systems, webservers, etc, etc.
There's a reason it is used a lot - in the real world it gets jobs done well by people who know what they're doing with it.
Saying "the world has moved on to Java, C#, etc, etc" is pushing it, given that the base system for many of those things are written in C++ (most of the native JNI stuff is C++, most Javascript compilers/interpreters are C++, many databases (Oracle, MySQL, MongoDB) are written in C++.
You may not like C++, and it might be difficult, and it may have worts, but thousands of people are using it very successfully for things no other language can do to the same degree overall.
C++ is used heavily from everything from Games, VFX programs (modellers, renderers/raytracer, compositors, paint programs), autopilot and control systems (cars, fighters (JSF), SpaceX are using it for their systems on their rockets), database systems, webservers, etc, etc.
There's a reason it is used a lot - in the real world it gets jobs done well by people who know what they're doing with it.
Saying "the world has moved on to Java, C#, etc, etc" is pushing it, given that the base system for many of those things are written in C++ (most of the native JNI stuff is C++, most Javascript compilers/interpreters are C++, many databases (Oracle, MySQL, MongoDB) are written in C++.
You may not like C++, and it might be difficult, and it may have worts, but thousands of people are using it very successfully for things no other language can do to the same degree overall.
My bad - "the world has moved on" was too strong.
I meant something like: other languages have risen in popularity because they are better than C++ for many types of projects.
I meant something like: other languages have risen in popularity because they are better than C++ for many types of projects.
Then again, browsers are written in C++ and so are almost all GUI apps. We spend most of our time with software that is developed in C++, probably for a good reason
so are almost all GUI apps
This claim is clearly false on Mac OS X and X Window platforms, and disputable on Windows, with the increasing share of .NET apps.
This claim is clearly false on Mac OS X and X Window platforms, and disputable on Windows, with the increasing share of .NET apps.
Please, name a .NET app that is widely used on Windows.
[deleted]
"""This claim is clearly false on Mac OS X and X Window platforms, and disputable on Windows, with the increasing share of .NET apps."""
Actually it is not.
On OS X tons of programs, and especially the very largest, most popular ones, are in C++ (think: Photoshop and the Creative Suite, MS Office, and lots of Apple's own: Safari (webkit) is C++, Final Cut and Logic are C++, etc. Don't confuse the front-end UI code (Cocoa) with the backend. C++ is a first class language in XCode, and you can mix it with Obj-C as Objective-C++.
On X Window platforms: besides KDE, some of the most important apps are C++, including Firefox, Thunderbird and Open Office.
On Windows there are almost no .NET apps that people actually use --people as end users, as opposed to corporations. Most of the popular stuff, from games, to office suites, to design suites, to browsers, etc are C++.
Actually it is not.
On OS X tons of programs, and especially the very largest, most popular ones, are in C++ (think: Photoshop and the Creative Suite, MS Office, and lots of Apple's own: Safari (webkit) is C++, Final Cut and Logic are C++, etc. Don't confuse the front-end UI code (Cocoa) with the backend. C++ is a first class language in XCode, and you can mix it with Obj-C as Objective-C++.
On X Window platforms: besides KDE, some of the most important apps are C++, including Firefox, Thunderbird and Open Office.
On Windows there are almost no .NET apps that people actually use --people as end users, as opposed to corporations. Most of the popular stuff, from games, to office suites, to design suites, to browsers, etc are C++.
You just proved the claim that there are many GUI apps written in C++ on OS X and X Window platforms, which is, incidentally, not the claim I find false. What I find false is the claim that almost all GUI apps are written in C++.
Can you find one app on your computer that is not written in c++?
Why, of course. What's more interesting, I can find only one GUI app on my computer that is (probably) written in C++, the web browser I use.
Why do you ask?
Why do you ask?
His argument is that if he's using a Mac, a lot of them are written in Objective-C.
And if he's using Gnome in Linux, most are written in C.
But for Windows apps, commercial apps, cross platform and games, C++ leads by far.
And if he's using Gnome in Linux, most are written in C.
But for Windows apps, commercial apps, cross platform and games, C++ leads by far.
> long after the world has moved on to Java, C#, Python, Ruby, JavaScript, etc.
I don't think this is true for everyone. In fact I believe recently we have seen a renaissance of native code. C++ is the number one language for that. Those higher level languages waste a lot of cycles. You pay the warm and fuzzy feeling during development with performance and/or energy.
I don't think this is true for everyone. In fact I believe recently we have seen a renaissance of native code. C++ is the number one language for that. Those higher level languages waste a lot of cycles. You pay the warm and fuzzy feeling during development with performance and/or energy.
I used this argument for Java, but it's the same with C++.
If I can deliver a first version 2 months before the C++ version gets ready, I'll have two months to optimize market-tested algorithms before you hit the market. I may even have time to rewrite the sensitive parts in C.
If we are talking gadgets with embedded software, you may use a less powerful hardware and offer a cheaper product, but you'll have to amortize higher development costs and deal with a longer time to market.
For many things the world really moved on. C and C++ are still important, just not as important as they were a decade or two ago.
If I can deliver a first version 2 months before the C++ version gets ready, I'll have two months to optimize market-tested algorithms before you hit the market. I may even have time to rewrite the sensitive parts in C.
If we are talking gadgets with embedded software, you may use a less powerful hardware and offer a cheaper product, but you'll have to amortize higher development costs and deal with a longer time to market.
For many things the world really moved on. C and C++ are still important, just not as important as they were a decade or two ago.
"""I used this argument for Java, but it's the same with C++. If I can deliver a first version 2 months before the C++ version gets ready, I'll have two months to optimize market-tested algorithms before you hit the market. I may even have time to rewrite the sensitive parts in C."""
Yeah, the only problem with that logic is that it never happens.
(Except in the server space, where it doesn't matter what language you're using to make your web app, and you can throw more server boxes at it to make it go faster).
1) Very few commercial programs are made with some dynamic language as opposed to C/C++, and none in the fields where performance matters (games, video, multimedia) etc.
2) Some do incorporate a scripting language, but for non critical layers (Lightroom for example uses Lua for its UI scripting, but all image crunching is in C/C++).
3) It's not like time to market matters that much. You're not building Facebook, you're building a desktop app. Chances are a lot more exist in the same section of the market.
4) """For many things the world really moved on.""" --care to give some examples of successful desktop apps not written in C/C++?
I'm sure you'll find 10.
I doubt you'll find 20.
Yeah, the only problem with that logic is that it never happens.
(Except in the server space, where it doesn't matter what language you're using to make your web app, and you can throw more server boxes at it to make it go faster).
1) Very few commercial programs are made with some dynamic language as opposed to C/C++, and none in the fields where performance matters (games, video, multimedia) etc.
2) Some do incorporate a scripting language, but for non critical layers (Lightroom for example uses Lua for its UI scripting, but all image crunching is in C/C++).
3) It's not like time to market matters that much. You're not building Facebook, you're building a desktop app. Chances are a lot more exist in the same section of the market.
4) """For many things the world really moved on.""" --care to give some examples of successful desktop apps not written in C/C++?
I'm sure you'll find 10.
I doubt you'll find 20.
Desktop apps are becoming a niche. I used to have an e-mail client, a spreadsheet, word processor, groupware, project management and an IDE installed on my machine. Now all I need is a browser and a text editor (although it's Emacs).
It still makes sense to use C/C++/hand-tuned assembly for high-performance things like game engines, 3D modeling, audio/video processing and so on. While my current OS is written mostly in C, I am old enough to remember (and have used) technically successful OSs written in things like Smalltalk, Lisp, PL/M and Algol.
Like I said, C makes sense for a lot of things. It's just not as important as it was 20 years ago.
It still makes sense to use C/C++/hand-tuned assembly for high-performance things like game engines, 3D modeling, audio/video processing and so on. While my current OS is written mostly in C, I am old enough to remember (and have used) technically successful OSs written in things like Smalltalk, Lisp, PL/M and Algol.
Like I said, C makes sense for a lot of things. It's just not as important as it was 20 years ago.
"""Desktop apps are becoming a niche. I used to have an e-mail client, a spreadsheet, word processor, groupware, project management and an IDE installed on my machine. Now all I need is a browser and a text editor (although it's Emacs)."""
People say that, but I don't see it. The Mac App Store has sold millions of apps already. And the iTunes App Store has sold a BILLION native (non browser) mobile apps.
If you only need is "a browser and a text editor" good for you. I need: a media player, a text editor, a word processor, an IDE, a chat client, Evernote, Dropbox, Skitch, Photoshop, VMWare Fusion, and some other stuff besides...
People say that, but I don't see it. The Mac App Store has sold millions of apps already. And the iTunes App Store has sold a BILLION native (non browser) mobile apps.
If you only need is "a browser and a text editor" good for you. I need: a media player, a text editor, a word processor, an IDE, a chat client, Evernote, Dropbox, Skitch, Photoshop, VMWare Fusion, and some other stuff besides...
> People say that, but I don't see it.
It all depends on where you look at. I can't remember the last corporate software piece I saw being delivered as a desktop application.
Stand-alone software for iOS has one advantage over web applications in that users sometimes face lack of connectivity. The Facebook app, IIRC, is delivered as a standalone app, but, in reality, is nothing but a web application. It's not alone and there are definite advantages to their approach. Most software appears to be entertainment - games, social thingies etc. They are the kind of games one would expect to be delivered as a Flash application within a brorser on a desktop.
I am not familiar enough with the Mac App Store, but, while there are some more "serious" offerings, in line with the desktop apps I mentioned, most of them appear to be, again, games and other entertainment related stuff. That and front-ends to net-centric applications such as Evernote.
It all depends on where you look at. I can't remember the last corporate software piece I saw being delivered as a desktop application.
Stand-alone software for iOS has one advantage over web applications in that users sometimes face lack of connectivity. The Facebook app, IIRC, is delivered as a standalone app, but, in reality, is nothing but a web application. It's not alone and there are definite advantages to their approach. Most software appears to be entertainment - games, social thingies etc. They are the kind of games one would expect to be delivered as a Flash application within a brorser on a desktop.
I am not familiar enough with the Mac App Store, but, while there are some more "serious" offerings, in line with the desktop apps I mentioned, most of them appear to be, again, games and other entertainment related stuff. That and front-ends to net-centric applications such as Evernote.
> when the only "magic" was basic virtual functions
What's "magic" about structs of function pointers? This is a classic idiom in C, just given a specialized syntax in C++.
What's "magic" about structs of function pointers? This is a classic idiom in C, just given a specialized syntax in C++.
With that argument you could invalidate any high-level language construct. They're all just "specialized syntax" of classic idioms in Assembly.
Exactly. And nobody thinks that for loops are "magic".
No, but for loops are simple. Classes are not that simple. Of course, no feature really is "magic". But there are a lot of features that may be easy to use but hard to deeply understand. Take for example the attr_accessor method that Ruby uses to make variables pseudo-public. Most beginners coming from Java think that it is a language keyword, similar to "public". In fact, it just writes getters and setters for you. Of course, everyone could just write their getters and setters themselves, but this is just what language is: A way to abstractly tell a machine what to do. And if you don't know how it works (and maybe even don't need to know), you can call it "magic".
I agree on Bjarne's opinion here -- it would be nice if C and C++ had merged at some point.
Unfortunately, the reason why this hasn't happened is inherent: C++ is so utterly complex (the C++11 standard contains more than 1300 pages of highly compressed language legalese) that especially in the embedded systems domain many vendors just don't have the time and resources to build a C++ compiler. And being caught in this vicious circle, embedded developers still aren't (and probably won't be for still quite some time) accustomed to programming at higher abstraction levels than what C offers. This also allows myths like C++ being too inefficient for embedded systems programming to live on in industry.
Unfortunately, the reason why this hasn't happened is inherent: C++ is so utterly complex (the C++11 standard contains more than 1300 pages of highly compressed language legalese) that especially in the embedded systems domain many vendors just don't have the time and resources to build a C++ compiler. And being caught in this vicious circle, embedded developers still aren't (and probably won't be for still quite some time) accustomed to programming at higher abstraction levels than what C offers. This also allows myths like C++ being too inefficient for embedded systems programming to live on in industry.
"This also allows myths like C++ being too inefficient for embedded systems programming to live on in industry."
You just proved that it is too inefficient... too complex to efficiently implement dev tools for use with (some) embedded device's to-market development cycles in a timely fashion.
You just proved that it is too inefficient... too complex to efficiently implement dev tools for use with (some) embedded device's to-market development cycles in a timely fashion.
C++ could have been so much . . . less.
Any language that takes the better part of a year to develop an adequate parser for is NOT to be trusted.
I had a long rant on RTTI, templates, the positively miserable experience around exceptions, and so on. But you've heard it before.
C++ should have /started/ with a string class and a set of collection classes, rather than having them be bolted on a decade later. This would have driven the language in much more useful directions.
I don't know if it's possible to remove features, but I've seen three groups independently come up with essentially the same C++ coding guidelines (the Google C++ guidelines are a great example), all deprecating large swaths of the language because they are dangerous, fragile or make bugs.
My experience with OS-level development is that you get a better code with vanilla C.
Any language that takes the better part of a year to develop an adequate parser for is NOT to be trusted.
I had a long rant on RTTI, templates, the positively miserable experience around exceptions, and so on. But you've heard it before.
C++ should have /started/ with a string class and a set of collection classes, rather than having them be bolted on a decade later. This would have driven the language in much more useful directions.
I don't know if it's possible to remove features, but I've seen three groups independently come up with essentially the same C++ coding guidelines (the Google C++ guidelines are a great example), all deprecating large swaths of the language because they are dangerous, fragile or make bugs.
My experience with OS-level development is that you get a better code with vanilla C.
Every person uses a different subset of C++, but that subset varies from a group to the other. You cannot therefore "remove features from C++".
A lot of people use C++ to code as they would in Java or C#, generally their experience is terrible. Exceptions don't work the way you think they do (in C++ exceptions should be exceptional). Polymorphism is more verbose, it's not introspective, etc. There's much to say about it.
I've found you enjoy the language much more when you go generic/functional full speed. You also understand why some arcane features of the languages are there (such as the .* operator).
A lot of people use C++ to code as they would in Java or C#, generally their experience is terrible. Exceptions don't work the way you think they do (in C++ exceptions should be exceptional). Polymorphism is more verbose, it's not introspective, etc. There's much to say about it.
I've found you enjoy the language much more when you go generic/functional full speed. You also understand why some arcane features of the languages are there (such as the .* operator).
"""Every person uses a different subset of C++, but that subset varies from a group to the other. You cannot therefore "remove features of C++""""
Actually you can. You don't remove them from the existing language that is, you make a better language with bs/redundant removed.
While "every person uses a different subset of C++" is true, it's not like everything someone uses is equally beneficial to have in a language. As the parent said, what is useful and what is not is not that controversial:
"I've seen three groups independently come up with essentially the same C++ coding guidelines (the Google C++ guidelines are a great example), all deprecating large swaths of the language"
Actually you can. You don't remove them from the existing language that is, you make a better language with bs/redundant removed.
While "every person uses a different subset of C++" is true, it's not like everything someone uses is equally beneficial to have in a language. As the parent said, what is useful and what is not is not that controversial:
"I've seen three groups independently come up with essentially the same C++ coding guidelines (the Google C++ guidelines are a great example), all deprecating large swaths of the language"
I cannot access the article so I am only able to respond to the title at this time. I'm not a big fan of such sweeping generalizations. I am biased- I write in C all day long. C's basics are fairly easy to learn, it's an incredibly fast language and more than anything it is still in use! It may not be "elegant" nor mimic the style the author would prefer to write in but it certainly has a purpose and just because that purpose may not match his coding style that does not mean /everyone/ should jump ship and declare it as being "obsolete."
It is my basic belief there should be many tools in a developers toolbox and you should not always use the hammer on a screw or a very precise scalpel when trying to remove a sliver when a pair of tweezers will get the job done.
If you want to declare a language obsolete I recommend we discuss a language that is not in the top three!
It is my basic belief there should be many tools in a developers toolbox and you should not always use the hammer on a screw or a very precise scalpel when trying to remove a sliver when a pair of tweezers will get the job done.
If you want to declare a language obsolete I recommend we discuss a language that is not in the top three!
"In this video, Bjarne Stroustrup explains why he thinks C is obsolete. He explains that the languages should have been merged into one, so that C would have been a subset of C++ instead of nearly a subset of C++. And then people could have used whatever parts of the C++ tool set they needed. "
Yeah right, a language/platform is a bag of fun toys out of which you can pick whichever ones you want, and all is well and everyone is happy. How can a programmer who has any experience claim something so ridiculous? When you decide on a platform, you have to live with whatever is there, the good and the bad. You can't tell people to use some feature but not touch this library, or not include that other package but write yours instead.
Yeah right, a language/platform is a bag of fun toys out of which you can pick whichever ones you want, and all is well and everyone is happy. How can a programmer who has any experience claim something so ridiculous? When you decide on a platform, you have to live with whatever is there, the good and the bad. You can't tell people to use some feature but not touch this library, or not include that other package but write yours instead.
Bjarne knows damn well that you can have a Matrix interface in C instead of "an array and a whole bunch of arrays". This is not a new concept. I would have hoped he was above spreading such disinformation.
He means an actual Matrix interface, with operators and all, as opposed to a bunch of functions that just hide the arrays under the carpet.
C is a beautiful language. I agree that with the assertion that it doesn't do abstraction. It only does two things:
* group code into functions * group primitives into structures.
However, it's simplicity is it's strength. You can write clean, standardised code in it. It's clean and simple. It's obvious. It's far too easy to make mistakes in C++ from bad type conversion or bad inheritance models (e.g. forgetting to virtualise something) to confusing subtly broken operator overloading that's counter-intutative.
C++ does render a C a little bit redundant. The abstractions it provides not only make programs more maintainable, but that additional intent allows compilers to potentially generate faster and more portable multithreaded code. We hit a point where C programs compile to faster/better assembly than a human can write. I expect that soon we'll hit a second wall where the C++ compilers can write faster/better multithreaded code than a C programmer could write or optimise and a C compiler couldn't support that directly "intent" as the language doesn't facilitate describing it.
However that point hasn't come yet. C still benefits from being clean, easy to interpret (from a human perspective) and is a demonstration of how to design a new language.
C++ is a federation of languages but writing pure C with gcc is better than g++ with all warnings enabled IMHO.
* group code into functions * group primitives into structures.
However, it's simplicity is it's strength. You can write clean, standardised code in it. It's clean and simple. It's obvious. It's far too easy to make mistakes in C++ from bad type conversion or bad inheritance models (e.g. forgetting to virtualise something) to confusing subtly broken operator overloading that's counter-intutative.
C++ does render a C a little bit redundant. The abstractions it provides not only make programs more maintainable, but that additional intent allows compilers to potentially generate faster and more portable multithreaded code. We hit a point where C programs compile to faster/better assembly than a human can write. I expect that soon we'll hit a second wall where the C++ compilers can write faster/better multithreaded code than a C programmer could write or optimise and a C compiler couldn't support that directly "intent" as the language doesn't facilitate describing it.
However that point hasn't come yet. C still benefits from being clean, easy to interpret (from a human perspective) and is a demonstration of how to design a new language.
C++ is a federation of languages but writing pure C with gcc is better than g++ with all warnings enabled IMHO.
Grrrr, I dislike C++ - my current preference for a development environment is C with a scripting engine stuck on top, but I nevertheless have to agree with Bjarne on this one. There are enough libraries out there in C++ now that the pain point of having to write wrappers so that they are accesible from C needs to disappear.
It would be so easier if the only difference between compiling for C or C++ was whether or not symbols were mangled or not. Someone writing C code that nevertheless calls C++ code could still compile with the C compiler, instead of today's solution, specifically - wrap the file in #ifdef __cplusplus extern "C" { #endif
and compile with the C++ compiler.
Plus, no more need to deal with all of the different flags leading to CFLAGS, CPPFLAGS, CXXFLAGS, no more worrying if a bool is a bool or a _Bool etc etc etc
Of course, care would need to be taken to not needlessly drag in the C++ runtime if it is not used.
It would be so easier if the only difference between compiling for C or C++ was whether or not symbols were mangled or not. Someone writing C code that nevertheless calls C++ code could still compile with the C compiler, instead of today's solution, specifically - wrap the file in #ifdef __cplusplus extern "C" { #endif
and compile with the C++ compiler.
Plus, no more need to deal with all of the different flags leading to CFLAGS, CPPFLAGS, CXXFLAGS, no more worrying if a bool is a bool or a _Bool etc etc etc
Of course, care would need to be taken to not needlessly drag in the C++ runtime if it is not used.
I think he's a little biased.
can't access the article for some reason, but i'm not sure if i agree with the title--there are still a shedload of fairly significant applications and software written in c (not c++): linux kernel, nginx, apache, etc.
c is still one of the most efficient languages out there next to assembly languages, you have complete control over memory management, most of the compilers produce highly optimized native code across multiple platforms, and there are a wealth of system level libraries to do some really significant things, i.e. it's as close as you can get to bare metal without having to deal with machine code.
i want to be clear here because i have been on both sides of the fence writing enterprise software in c as well as more recently in java, python, ruby, etc, so i know the advantages (and disadvantages) of OO versus a procedural language like c which i'm guessing is the major argument of the article. having libraries and frameworks like ruby on rails will significantly increase productivity and time for development, which in itself is a major win, but when you're talking about maximum performance, c is probably your best choice.
in general i think that writing software in the 21st century is still too complicated and error prone. if i want to write a web app, why do i still need to parse strings, perform database queries and such? why can't i have higher level abstractions or frameworks/libraries that give me this functionality. that's why i like django and rails, they seem to be moving in that direction (convention over configuration), though at the end of the day, you're still working with strings, arrays, and such. we should have software systems that provide even higher level abstractions than components and frameworks, for example, i want to create a social networking website that stores billions of 140 byte character messages, these messages should be searchable, this needs to run on iphone, chrome browser for windows, linux, etc. it would be great if the focus was on the features described like above and functionality rather than having to deal with SQL, arrays, strings, templates, css, ajax, etc. maybe the closest thing to this is like packaged software where everything is pretty standard and you customize only the portions that are necessary (maybe like twiki). i should never have to deal with SQL or even ActiveRecord (even though it's a nicer abstraction over SQL), all this logic should be taken care of for me, i should only have to define the high level stuff. when we get to that point, that's when i believe that we'll have achieved 6GL.
7GL would be where the software would have enough intelligence to figure out that it needs what features and have those implemented automatically.
c is still one of the most efficient languages out there next to assembly languages, you have complete control over memory management, most of the compilers produce highly optimized native code across multiple platforms, and there are a wealth of system level libraries to do some really significant things, i.e. it's as close as you can get to bare metal without having to deal with machine code.
i want to be clear here because i have been on both sides of the fence writing enterprise software in c as well as more recently in java, python, ruby, etc, so i know the advantages (and disadvantages) of OO versus a procedural language like c which i'm guessing is the major argument of the article. having libraries and frameworks like ruby on rails will significantly increase productivity and time for development, which in itself is a major win, but when you're talking about maximum performance, c is probably your best choice.
in general i think that writing software in the 21st century is still too complicated and error prone. if i want to write a web app, why do i still need to parse strings, perform database queries and such? why can't i have higher level abstractions or frameworks/libraries that give me this functionality. that's why i like django and rails, they seem to be moving in that direction (convention over configuration), though at the end of the day, you're still working with strings, arrays, and such. we should have software systems that provide even higher level abstractions than components and frameworks, for example, i want to create a social networking website that stores billions of 140 byte character messages, these messages should be searchable, this needs to run on iphone, chrome browser for windows, linux, etc. it would be great if the focus was on the features described like above and functionality rather than having to deal with SQL, arrays, strings, templates, css, ajax, etc. maybe the closest thing to this is like packaged software where everything is pretty standard and you customize only the portions that are necessary (maybe like twiki). i should never have to deal with SQL or even ActiveRecord (even though it's a nicer abstraction over SQL), all this logic should be taken care of for me, i should only have to define the high level stuff. when we get to that point, that's when i believe that we'll have achieved 6GL.
7GL would be where the software would have enough intelligence to figure out that it needs what features and have those implemented automatically.
To be fair, the interviewer used the provocative word "obsolete" when he asked the question. Dr. Stroustrup answered it honestly and use the words "merged" and "more compatible" and said there is no technical reason for the few existing differences today.
He also pointed out that he worked closely with the late dmr (office was just three doors down the hall) and still has strong ties to other famous and well-known C gurus (dinner with Brian Kernighan) and that C and C++ coexisted w/o issue in their world.
His final point was the best though... he pointed out how programmers argue and fight about which is better, not the designers and researchers themselves.
Edit: Also, the new C11 standard brings C closer to being a complete subset of C++ and subsequent standards will continue doing this until they are merged, but this won't make C obsolete.
He also pointed out that he worked closely with the late dmr (office was just three doors down the hall) and still has strong ties to other famous and well-known C gurus (dinner with Brian Kernighan) and that C and C++ coexisted w/o issue in their world.
His final point was the best though... he pointed out how programmers argue and fight about which is better, not the designers and researchers themselves.
Edit: Also, the new C11 standard brings C closer to being a complete subset of C++ and subsequent standards will continue doing this until they are merged, but this won't make C obsolete.
It seems to me that what Bjarne likes about C++ over C is its provision of copious quantities of syntactic sugar - turning things that are perfectly expressible in C into supposedly more 'natural' formulations. I suppose if you like cancer of the semicolon, C++ may be the right place for you, but in my opinion if you really want abstraction you should be using lisp (the simple, unbound syntax makes every function you implement act like an extension of the core language), and otherwise you should use C.
Of course, I'm atypical - when I'm not writing in C it's because I'm writing asm.
Of course, I'm atypical - when I'm not writing in C it's because I'm writing asm.
I don't think C will be obsolete as long as it is hard to do C++-ish things in it.
The problem is C is "good enough" and C++ is "complex".
The only serious alternative system programming languages have been offered up by Niklaus Wirth and associates. Not much traction among developers...
The only serious alternative system programming languages have been offered up by Niklaus Wirth and associates. Not much traction among developers...
If only there were some extension of C which added the ability to more easily work with abstractions (say, particularly, object-oriented abstractions) that was a strict superset of C.
Actually, after having used it for ten years, I think C++ is the language which should be deemed obsolete. We don't need such a complex language anymore.
Long live C!
Long live C!
I hate this superset/subset idea -- those are just different languages, with separate philosophies and totally incompatible practice sets. Merging is an equal madness as merging Haskell with Python.
On the other hand, from a fully practical view, even after omitting all incompatibilities a C code compiled with C++ compiler will be bloated with C++ standard lib, and will have screwed symbols.
On the other hand, from a fully practical view, even after omitting all incompatibilities a C code compiled with C++ compiler will be bloated with C++ standard lib, and will have screwed symbols.
Better not tell the embedded systems engineers, electronic engineers, os developers .....
I feel like starting a Movement in Defense of Small Languages.
So, all we're going to do is nerdrage about C vs. C++ here. There will be diehard architecture astronauts on the one side, and crufty neckbeards on the other. We've all seen this thread before.
~
Instead, let's talk about things that C++ got right that aren't super obvious! :)
For me, one of the coolest things about C++ is having destructors. The neat thing about them is that they are based on the scope of an object, and tie directly into when the object leaves scope in the language (as determined at compile time). Any code there gets run when the object is deleted or leaves scope, and this is guaranteed to happen immediately.
So, I know exactly when an object is no longer "needed", and if I'm careful I can use things like smart pointers and reference counting to guarantee that a shared resource gets removed when it needs to. I can also override new/delete and do some magic to have a reliable "hey, come free me from the heap later" behavior--when the destructor is called, have the class append itself to a list of things to be GC'ed when the time is right.
Java, for example, doesn't do this--a request to finalize may be fulfilled, one day, when the VM feels like it. This makes smart handling of things like system resources really clunky, and can force me to write C-ish code like freeSystemResources() or something. Having an ability to explicitly know when lexical scope has been left is pretty cool.
What other cool things have you seen in C++ (or C)?
~
Instead, let's talk about things that C++ got right that aren't super obvious! :)
For me, one of the coolest things about C++ is having destructors. The neat thing about them is that they are based on the scope of an object, and tie directly into when the object leaves scope in the language (as determined at compile time). Any code there gets run when the object is deleted or leaves scope, and this is guaranteed to happen immediately.
So, I know exactly when an object is no longer "needed", and if I'm careful I can use things like smart pointers and reference counting to guarantee that a shared resource gets removed when it needs to. I can also override new/delete and do some magic to have a reliable "hey, come free me from the heap later" behavior--when the destructor is called, have the class append itself to a list of things to be GC'ed when the time is right.
Java, for example, doesn't do this--a request to finalize may be fulfilled, one day, when the VM feels like it. This makes smart handling of things like system resources really clunky, and can force me to write C-ish code like freeSystemResources() or something. Having an ability to explicitly know when lexical scope has been left is pretty cool.
What other cool things have you seen in C++ (or C)?
and of course, everybody needs to know Linus Torvalds thoughts about C++: http://thread.gmane.org/gmane.comp.version-control.git/57643...
insane
it's not.
What about Operating System?
What about it? There are several OSs written in C++. BeOS was one.
C++ is as ridiculous as Bjarne's hair.
in C++, you'd have a Matrix class with a getter. To get an element of the matrix you'd do
whereas in C you'd typedef a Matrix structure type and have an accessor function
Looking inside the functions, they'do pretty much the same thing. In both of these functions you'd be basically accessing either element i+imax * j of your data array if you are implementing the matrix as a single array, or the j-th element of the i-th row if you were using a pointer to pointer structure. the C version would work on the provided matrix structire whereas the C++ would use the implicitly provided this structure. C++ would allow your matrix class to override some operator to make this look cooler - but operator overloading being a good thing is not really a consensus AFAIK.
I dont see anything more than a syntactic difference here. The abstract reasoning behind the structures/classes is exactly the same.
C may be obsolete, but this is hardly a justification.