7 ms·
The real shame about C++ is that it's the only mass market C-level language with advanced features built on top of it. Don't get me wrong: I agree with the auth
by cletus 16y ago
The real shame about C++ is that it's the only mass market C-level language with advanced features built on top of it. Don't get me wrong: I agree with the author and his interviewees. I think C++ is a horrible language for the very reasons described: everyone uses a different subset of it and it's hideously complicated.
For a more current view, see Linus Torvalds' comments [1] [2].
What I would like to see is a language very much like C (being low-level) with a few features built on top. What those features are I guess is the real trick.
One thing I like about C++ is the constructor/destructor mechanism. It's very explicit. The trend now is towards garbage collection (which, admittedly, you can implement in C++). This is a trend I largely agree with. It's quicker and cheaper to write software that way (IMHO). But there is still a place for simper schemes as all GCs I've come across have issues.
One thing I think such a language shouldn't be is object-oriented. To quote Joel Spolsky [3]:
> A lot of us thought in the 1990s that the big battle would be between procedural and object oriented programming, and we thought that object oriented programming would provide a big boost in programmer productivity. I thought that, too. Some people still think that. It turns out we were wrong. Object oriented programming is handy dandy, but it's not really the productivity booster that was promised.
Or at least such objects should be very limited in scope. Linus addresses some of the reasons for this, such as knowing which function is being called by simply looking at a code snippet (typically a patch in his case).
When writing low-level code I certainly do much prefer C over C++. But having the tools to build automatic reference counting into C would be really nice at times.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918 http://thread.gmane.org/gmane.comp.version-control.git/57643...
[2]: http://www.realworldtech.com/forums/index.cfm?action=detail&id=110618&threadid=110549&roomid=2 http://www.realworldtech.com/forums/index.cfm?action=detail&...
[3]: http://www.joelonsoftware.com/articles/APIWar.html http://www.joelonsoftware.com/articles/APIWar.html
- gms 16y agoPerhaps Google's Go will end up being the answer.
- masklinn 16y agoNo. And thank science for that.
- sausagefeet 16y agoI think many people were hoping for it but Go fell fatally short in 2 key areas IMO: 1 - Error handling - Go doesn't have any powerful mechanism for error handling. The code I have seen is rather inconsistent and it doesn't solve the main problem from C of forcing people to handle errors. 2 - Polymorphism - They left any kind of generics out. I think this could go a long ways for (1) too, just look at Either or Maybe type in Haskell. Combine this with some pattern matching and you have a really powerful way to enforce error handling and have polymorphic data structures and functions. IMO this is the biggest failing of Go. I think the failure to provide those two things also makes Go a future mess. Adding them later either breaks a lot of outstanding code or it means you have to versions of Go, the original and new which is a mess.
- dchest 16y agoAdding them later either breaks a lot of outstanding code or it means you have to versions of Go, the original and new which is a mess. Actually, the creators of Go are still not afraid of breaking things. For example, recent release (2011-02-01.1¹) changed the syntax of non-blocking channel operations, and it broke code. [1] https://groups.google.com/d/topic/golang-nuts/uHfjRyO1Q6c/discussion https://groups.google.com/d/topic/golang-nuts/uHfjRyO1Q6c/di...
- sausagefeet 16y agoThat is good to see. But I would argue that the change described here is a rather small change while the 2 missing features I described have a larger effect on how you design your application.
- jbooth 16y agoWell, adding generics shouldn't break working code.. it's an additive change. It says something that for the built-in collection types, Slice and Map, they had to hack around their own API and implement this-case-only ad hoc generics. Slice and Map should be fully implementable within the language.
- X-Istence 16y agoPeople keep bringing up Linus' C++ in git rant, and I don't understand why it is used as an example, as it contains no real substantive reasons as to why to dislike it. There is no real argument made one way or another. If we look at the linked article there are real arguments as to why people don't like C++. Templates, multiple inheritance, and a whole other range of stuff. All Linus is yelling is "I hate C++, I hate STL, them Boost guys aren't worth anything" with absolutely no reasoning what so ever. As a project leader it is okay for him to disagree about using C++ within his source code base, and within context it is a perfectly valid email, but to use as an example as to why C++ is bad, it is a very bad email to quote.
- grammaton 16y agoFrom my impressions of how he conducts himself, Linus is usually yelling with no reasoning what so ever.
- beagle3 16y agoHe explained it more than once: Nuances are lost in the internet on one hand, and (apparently) Finnish culture is very in-your-face with everything made more extreme for dramatic effect. You may not like it, but it is extremely effective, and Linus _is_ herding thousands of developers, he has to be effective.
- alexk7 16y agoI'm designing such a language. It's called C³. I would like some feedback on my design "rules of thumb"[1]. I'm literally still at the whiteboard! [2] [1]: http://blog.c3lang.org/aims-and-rules-of-thumb-for-the-design-of-c-a http://blog.c3lang.org/aims-and-rules-of-thumb-for-the-desig... [2]: http://c3wife.com/?p=523 http://c3wife.com/?p=523
- cageface 16y agoJust a tip - the superscript makes googling for or talking about your language a hassle.
- steipete 16y agoYou are talking about Objective-C.
- zeugma 16y agoAbout constructor/destructor: in C++ you call allocate object on the stack, destructor will be called when you get outside the scope of the variable. That feature, dumbed RAII in C++ lingo, may be the simple GC your looking for : no explicit delete, good locality of the destruction. It also allow correct handling of exception.
- barrkel 16y agoIronically, it's copy constructors which show up to break exception safety horribly if you're trying to be ultra-safe - cf. no stack<T>::pop() that returns the value popped. What C++ adds with one hand, it takes away with two more hands that popped up out of nowhere like mutant growths.
- dzorz 16y agoC++0x solves that issue by introducing rvalues.
- barrkel 16y agoI strongly reject the idea that object orientation hasn't provided a big boost to programmer productivity. In my view, it's enabled building systems that are orders of magnitude larger and more complex because of the discipline it enforces in modularity and the discoverability it lends to APIs. I mean, do you remember the C written in the 80s? Often, the only unit of modularity in common use was the translation unit, with static globals used freely, structures with no visibility protection, having their inner guts manipulated by different modules, frequently by manually tweaking the pointers etc.? If you had an API that protected structural guts, you were almost always essentially programming to an object oriented style, only with no help from the language and compiler.
- dkersten 16y agoI agree. I'm not a big fan of OO, preferring functional approaches in most cases, but I usually use some kind of OOP either to tie things together or to provide easy to use interfaces to the system, as I find constructing and passing objects to modules is often a natural way of interfacing with them, especially if the system is complex and the objects are used to "insert" code into the system (eg, algorithmic skeleton style). So even though I dislike OO as a whole, I think it has a very useful and important role in programming and it certainly helps us bring ever-more complex problems to a level we can reasonably deal with. Having said that, there are some things OO is bad at, eg concurrency.
- georgieporgie 16y agoHow does OO have any effect on concurrency? I'm genuinely curious here.
- barrkel 16y agoMutable state. OO prioritizes encapsulation ahead of immutability as a way of making the problem of a mutable struct tractable. Most OO programs are graphs (picture as a complex web) of mutable objects holding references to one another, synchronously passing control from one object's method to the next (picture as a spider travelling around the web, making modifications). Concurrency means there is more than one logical point of control flowing around the graph, making modifications. To ensure modifications are consistent, one must now fight against the interconnected nature of this graph, and make certain areas mutually exclusive; that means you need to set up gates on all the edges leading into those areas (often called semaphores or mutexes). But OO gives you precious little help in setting aside these areas, and guaranteeing internal consistency in the face of multiple mutating points of control. Programs in a functional style are different, with their heavy emphasis on immutability. In this case, the web, as it were, is fixed and cannot be changed; instead, if there is to be a modification, a new copy is created (possibly only of the local area of change, and the unchanged portion included via references). Since there is no way to change data, there can be as many points of control performing operations as desired. (Actually, one of the models of computation used for functional programs is that of graph reduction, which pictures the program as a web of expressions rather than structures; and that big expression is iteratively made smaller by calculating different parts of it. In principle, the more points of control you have doing these calculations, or reductions (in the same way as '1 + 2' can be reduced to '3'), the better.) Programs written in an agent / actor style are also different. Here, there is no single point of control flowing from one node in the graph (web) to the next; instead, each node has its own little point of control, and it reacts to messages coming in from each edge, and sends out messages along edges in response. This makes the program locally single-threaded, but globally concurrent.
- suraj 16y agoI am keeping my eye on Clay http://tachyon.in/clay/ http://tachyon.in/clay/
- jdf 16y agoSimilarly, I've been hoping that Rust (which is somewhat run by Mozilla labs folks) would turn out well: https://github.com/graydon/rust/wiki/ https://github.com/graydon/rust/wiki/
- spitfire 16y agoIt's funny because back in the 80's we had a language that was already at where c++ and java were going. It's called Ada. Back in 83 it had built in concurrency, generics, etc. The problem was, back in 83 the compiler was the size and complexity of a C++ or java compiler from 1995. Couple that with some horrible implementations and Ada never took off much beyond Avionics/security/life critical applications. Which is a shame, because comparing ada to C++ or java today and imnsho Ada wins hands down. The compilers are faster, the code very nearly as fast (In Ada you get things like runtime array checking which slows you down). Unfortunately the programming language wars aren't about technical merit (Java would never have been popular otherwise) and more about social popularity contests/network effects. EDIT: I might add that at this point ada is /far/ simpler than both c++ anda java. Jean Ichbiah thought carefully about what was needed for large, long lived projects (millions of lines, 30+ years life) and it shows. They got pointers right the first time - access types. verifiability - testing your code is all the rage now, 27 years late. etc. Best yet, the ecosystem around the language is mature. That is unlike c++ you don't have a dozen different approaches taken (template hell), and unlike Java you don't have bureaucratic overload.
- Jach 16y agoI like your comment overall, though I don't find Linus' C++ rants all that useful. Also, no, you can't implement a GC in C++. (Which in turn makes its operator overloading and exception handling defective and throws reflection out the window.) http://yosefk.com/c++fqa/heap.html#fqa-16.26 http://yosefk.com/c++fqa/heap.html#fqa-16.26 "C++ does not feel pain. It can't be reasoned with. Starting a fight is a big mistake. If you want to use C++, you must learn to love it the way it is, in particular, manage your memory manually."
- Stormbringer 16y agoThe thing that OO does, and does really well, is that it makes handling special cases really easy. Anybody who has come across 'business logic' (a beast related to 'military intelligence') knows that special cases are going to be the bane of your existence. Ta da! Problem solved. Why then, you might complain, have we not seen the benefits of OO? Because the majority of programmers (usually by their own admission) suck at design.