C++ in Coders at Work
gigamonkeys.com
gigamonkeys.com
And then C++ implements several programming paradigms (object oriented, generic, etc) without compromising that machine model.
Plus Bjarne was truly correct when he said: "there are languages people complain about, and there are languages nobody uses."
I think this is very true, what it says literally is that popularity and attracting ire are correlated.
However, my interpretation is that the reason why this is true is that (1) all languages involve design trade-offs, (2) every trade-off pisses someone off for at least a moment, and (3) popularity attracts eyeballs, therefore more popular languages have more people pissed off.
I am not suggesting you say this, but I have heard the (strawman?) argument that it is possible to design a nice, pure language that is above reproach but that it can't be popular, and thus his quote expresses the thought that there is an inverse relationship between elegance and popularity. I don't think this is the case.
However, I agree that his main point is more that you will never be able to design a language that is useful to a large number of people without making compromises, and with any compromise there will be at least one person for which it is not the optimal solution.
I don't want to say the relationship between elegance and popularity is strict though. There is simply a good correlation.
For my money, developers are better off knowing two tools (c + some very high level language) rather than the spork which is C++.
If 'C' would have had a decent native string type I think C++ might not have happened ;)
std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*,
const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>,
_Alloc = std::allocator<char>]
I can see why they chose to omit it, but in retrospect I think it was a mistake. The problem they were faced with was that the language didn't include any 'runtime' at all the way they wrote it, a string package would have made it a must to have some runtime.
Everything that is 'runtime' in C is in libraries, and everything that is 'core' is in the compiler.
This constructor lets you customize the way the string class allocates memory. Now I would like to see the equivalent constructor in your favorite language :)
It is funny how everybody really seems to have their own favorite subset of C++.
I'd say the justification for all of the large languages (like C++ and Common Lisp) is the same. You may not need all of it, but the features you do need will at least be standardized, compared to using a small language with ad-hoc extensions to achieve the same.
[ I here include the standard library as part of the language, for languages with extensive meta-programming support like C++ and Common Lisp, it makes little sense to distinguish. ]
I think Objective C is a better object oriented C than C++. It's simpler, makes a syntactic distinction between message passing and "traditional" C, and has a more dynamic run time. I'm surprised no one else has brought up Objective C as a better solution to the "make C object oriented" problem.
Aside from C compatibility, C++ also allows one to create simple structures and procedures when such simple beasts are appropriate.
I currently suspect one should have either "full" object orientation plus weak typing OR weak object orientation plus strong typing. Strong typing plus full OO = Bondage and Discipline language, where the size of the code itself starts to really drag your development and debugging time down.
While Ruby or Python allows compact but slow code, Java and C#, among other excesses, force one to create a full class for every two-field data-structure. Thus C++ is more compact than C# and Java and faster than Python and Ruby, winning for race for a desktop application language (oddly enough, desktop apps need a fast language because they must compensate for desktop windowing systems being more bloated and users expect more from their machine each).
I'm sure Haskell or Lisp are excellent for some things but I don't think their paradigm is very compatible with GUI programming - I'd be interested if someone has a counter-example.
AutoLisp is just a thin scripting layer.
See <a href="http://www.fourmilab.ch/autofile/www/autofile.html>the autodesk file</a>.
Anyway, some more examples then:
Yes, I've seen people work wonders with AutoLisp. There was - probably still is - an application used for designing clothes. The designer creates, I think, a "size 8" and a lisp script generates the other sizes.
AutoLisp being lisp-like is really a happy accident. The Autodeskers chose Xlisp IIRC because it was free and embeddable. If they could have embedded a C-like language interpreter, they would have.
In fact later, AutoDesk introduced other languages and tried to push users onto them. But AutoLisp already had huge momentum.
var simple = new { Field1 = "foo", Field2 = "bar" };You're missing a crucial part of the equation: type inference. OCaml does what you want :-)
I someone is coming up with a type-infering variant of Ruby called Juby which could do the trick once it is work.
Now, has anyone coded a GUI with Ocaml?
Now, whether the types should be dynamic or static, is entirely up to the situation and what kind of system you are building.
* You have to actually run the dynamic runtime, which even OS X's XNU doesn't do.
* The dynamic runtime also obscures what's going on with the hardware, which can be a problem in embedded environments.
I like Objective C but it's always felt like voodoo to me. I'm always more comfortable in Ruby+C than I am in ObjC.
To the degree that C represents this reality, it is through exploits: e.g. buffer overflows, overwriting the stack and return address, and executing arbitrary code supplied by attackers. C itself does not represent the reality very well, since it does not lend itself to writing code that writes code at runtime.
The ones that do not are actually pretty rare.
Most of those use the 'harvard architecture' and are DSP style machines.
And then there are vector processors and SIMDs, but even those can be seen as many von Neumann machines running in lock-step.
i don't even know on what kind of hardware my java or python programs run. neither google (appengine) nor our IT apartment tell me.
so for most app developers "a computer" is not really something they work with. of course someone must write those abstractions (python, etc), and they do it in C/C++ :)
That's exactly the point, if your machine is anywhere near 'standard' (as in not a SIMD or something exotic) then C is as close as you can get to it without going to assembler.
Not any longer. I don't know how C models the kind of massive parallelism that is becoming mainstream right now.
The only reason you know what the C you write will end up doing on the machine is because you are generally not doing much when you're working in C.
If you want to get productive work done, you'll be leveraging lots of libraries written by third parties, and you have no more insight into how they are working when you're invoking them with C than Ruby, Python, Java, C#, or any other language.
A C program that accesses the memory will do so in an extremely predictable way, if I lay out a memory structure, a piece of code and an access pattern then I can be very sure about how that will interact with things like the caches.
In other languages where there is more 'under the hood' that is a lot harder.
Libraries don't enter in to the problem, that's another level altogether.
While it's true that library code written by third parties might be less (or more) efficient than the code you wrote, even those libraries will have the luggage of the underlying implementation of the language.
In C there is no implementation underneath, it is a 1:1 correspondence with machine instructions.
That is the reason that kernel code tends to be written in C.
In C, you deal with so many trees, it sure feels like you're right there in the woods. But actually, if you're dealing with things on a tree by tree basis, you're not getting much done. And you can pretty lose your way by focusing on navigating territory efficiently at that level, but not keeping track of the overall goal.
As to whether kernel code should be written in C, that is a different matter. C is not a good map to von Neumann architectures because it doesn't model shared code and data in memory - C doesn't have a good representation for writing code at runtime. Most code written in C will not be the most efficient possible code for this reason.
Modern developers have gotten so used to the fact that C is "low level" that they tend to forget how low really low level coding is. There's a ton of "high level" language features in every 3GL, and that includes C. The abstractive distance from machine code to a language like C or Pascal is far, far higher than it is between C and Python.
[1]: http://yosefk.com/c++fqa/
The answer then is obvious : we should change the hardware, so it is not C/C++ optimized, but Lisp/Python/Haskell optimized. Then, these languages are easier and more practical.
But I didn't start this: "Lovely languages like lisp, python, haskell" (sic).
However, even that is dying -- it is being replaced by the thumbEE, which is a more generic instruction set designed for efficient code generation from intermediate dynamic code.
http://en.wikipedia.org/wiki/Azul_Systems
I don't know how successful they are economically though.
edit: found it:
I think the strategy of objective-C is much cleaner, since they better separate the concerns of "writing fast code" and "writing high level OO abstractions".
I think C++ totally failed at being high level. So, this "success" being highly controversial doesn't surprise me.
C (the PDP-11 assembler that thinks it's a language)
C++ (the PDP-11 assembler that thinks it's an object system)
C isn't really a portable assembler. It was designed to be sufficiently efficient on a specific processor (the PDP11, a register based CPU), while providing basic abstractions (function, structures…).
C was an overwhelming success. And so were CPUs fast at running compiled C programs. As far as hardware optimization is concerned, the main characteristics of C are pointer arithmetic, manual memory management, and a relatively low ratio of function calls (in C programs). These are pretty big constraints. So, we ended up with C optimized CPUs. Now what if Unix has been implemented in Forth? All mainstream processors would have been stack based, and optimized for a very high ration of function calls.
C++, by extending C, also have this "portable assembler" nature. It also have a number of incredibly low-level mechanisms which can be used to build pretty high-level abstractions, but it's still an extension of C.
C++ is C, except that it doesn't completely suck for higher-level projects.
a.) you get direct access to your linear address space
b.) gcc targets so many instruction sets that you don't have to worry about your backend unless you have a custom platform.
C++ is the thing that screams "__gxx_personality_v0" at me because I always start off using gcc instead of g++.
C changed that dramatically and helped to cut down on porting effort tremendously.
The comments that really drop my jaw are the people who seem to hold up Java as a "better" C++. Java is okay, but from its sketchy real-world performance, to its crappy generic programming support and poor ability to enforce such type-safety basics as const-correctness, I've never been impressed. Take the time to learn C++ for what it is, instead of "C with objects" and you'll find that it's far more elegant than the backlash would suggest.
I think that what most people really hate about C++ stems from the widespread use of legacy compilers that incorrectly implement the spec, or implement older versions of the spec. This problem exists for every programming language in the universe (e.g. Ruby 1.8.6 vs. Ruby 1.8.7 vs. Ruby 1.9), but since C++ is widely implemented by multiple vendors, the problem appears worse. If Python or Java were implemented by Microsoft and GNU and four other smaller companies, you'd see the same horrible compatibility problems with those languages, too.
My professional experience outside C++ is limited, but I had always assumed this was the same for other languages as well. Is C++ really that much of a different animal from other languages?
The big differences come into play with frameworks. Depending on whether you're using Struts/JSF/Hibernate/Spring/etc your code may look completely different.
In avionics software, the ternary operator and multiple returns are often avoided to help ensure better code coverage during verification.
There are a lot of Java implementations, and I am not aware of serious compatibility problems between them.
Zawinski and Thompson are good, but they are not 90% of Zawinski, Thompson, Bloch, Eich, Ingalls, Armstrong and Steele. You're completely misrepresenting the gist of the article.
The comments that really drop my jaw are the people who seem to hold up Java as a "better" C++.
http://www.paulgraham.com/icad.html
but from its sketchy real-world performance
Oh please, don't start that flamewar with these kinds of uninformed, one sided utterances. Java performance has been more than fine for at least five years.
a few months ago i was working on a project that involves amazon ec2 and s3. amazon gives you a bunch of command-line utilities, written in java, to perform various stuff. every one of them takes a second or two to start up, which really annoyed the heck out of me. that certainly wouldn't have happened if they were written in c++.
I personally still use C++ because of the libraries and tools. With Boost, Qt, WebKit, valgrind, gdb, and others I am simply too productive in C++.
If someone told me I could only use the c++ standard library and no other libraries I could probably switch languages pretty quick. I can only imagine what it must have been like before when you got nothing.
I was once listening to RMS speak at a conference. One guy got up and said that this was one of the n great talks he had been to.He mentioned that Stroustrup as another speaker who had impressed him upon which RMS said "You need to get your head checked".
Sometimes a great hacker community can help overcome the shortcomings of a language. Trevor Blackwell makes that point here: http://www.tlb.org/faq.html.
"Besides their intrinsic characteristics, languages define commmunities of programmers. You want to choose one that lets you communicate with good programmers, because you'll learn from them. They tend to prefer powerful languages like Python, Lisp, and C++. So for example, although Visual Basic is actually a powerful and complete language, few good programmers use it. C++, on the other hand, is a rather poorly designed language, but for historical reasons a lot of smart people use it so at least you'll be in good company."
> And he said “no” to no one.
And that is the core of the problem.
I don't really see this. Most of C++'s complexity emerges naturally from three things:
1. Lack of GC.
2. Direct support for user-defined types on the stack.
3. The desire to implement every feature as efficiently as the corresponding C idiom.
There actually aren't very many controversial features in C++: multiple inheritance, operator overloading, templates, and exception handling are the ones that come to mind. With the exception of multiple inheritance, none of these is particularly heinous. Implementing them under the three restrictions above is where things get complicated.
In most languages my preferred view in the debugger is the source code of the language, in C++ I almost always just looked at the assembly. It seemed the more 'clear' language :)
Lack of GC never bothered me much by the way, that's no different in C, and that's where I really learned how to code, so keeping an eye on memory leaks and the opposite, double frees is somehow a built-in feature (of the programmer, not the language).
C++ is definitely a language where you can get screwed by "clever" programmers who would rather be reading TC++PL than actually coding, but it's not so bad if the people you work with exercise good judgment. I've never had to deal with multiple inheritance in real production code, for instance.
It gives you an excellent overview of the various ways in which things can go wrong, and C++ figured quite prominently in the 'gotcha' department.
C has it's share of issues, double frees, failure to initialize (but most compilers catch that one nowadays), and stale pointers. With a good discipline you can work around those.
C++ can obscure the bugs in such a way that it takes you a long long time before you can 'nail' them. The biggest problem I have with the language is that the code tends to obscure what is going on at the machine level.
I guess that's a 'feature' too, but I prefer to have a more direct correspondence between program code and what goes on below the surface. That's a problem with OO in general by the way, and I think that this is part of what makes software so terribly inefficient these days.
Gigabytes of ram are barely enough to accomodate a single user os, it's really pretty weird.
Which totally defeats the purpose of being backward compatible with C.
If it had been D instead, an actual new version of C designed to incorporate new features, instead of C++, additional features on top of C, it probably would be less reviled but there would have been a lot more resistance to adoption.
In general, there is at least the linearizing (Common lisp) multiple inheritance with a well defined method lookup semantics (even though there are good ways to shoot one into the foot there), and the C++-local-hackity-multiple inheritance (where the programmer has to resolve lookup ambiguities, resulting in unpredictable semantics). And this even avoids the discussions of traits, mixins and such.
Also, note that there is also a semantic difference here between C++ (and Java) and most other languages. In C++ multiple inheritance, if classes A and B define method foo, and A and B have no inheritance relationship, then A::foo and B::foo are entirely unrelated methods -- just as if they were named A::foo and B::bar. The fact that they have the same name does not automatically create a relationship between them, as it would in CLOS or in duck-typed languages like Python. That means that a call to foo in a class that inherits from A and B is just as ambiguous as if the programmer had typed "foo, or maybe bar." This unrelatedness is inherent to C++'s type system. It would make no sense to a C++ programmer to treat A::foo and B::foo as being alternative dispatch targets for the same method call.
Even if you allow the compiler to gloss over this unrelatedness, I still think it is a matter of taste whether it is simpler to require programmer disambiguation or to have a well-defined algorithm for resolving ambiguous names. C++ usually takes heat for providing powerful more-than-meets-the-eye mechanisms that allow programmers to "hide" program semantics inside language features. Here C++ takes the opposite approach and requires the programmer to explicitly resolve ambiguous names, and it takes heat from a CLOS programmer, who could write an entire operating system using a single family of generic functions all having the same name ;-) Damned if you do, damned if you don't.
I sense an upcoming challenge! ;)
Oh, absolutely. I just meant that it adds some incidental complexity to operator overloading that doesn't exist in other languages.
Can you give an example of a "pet construct" (aside from major features like multiple inheritance and exception handling) that could have been left out?
The times that I ran in to examples where it was used properly and elegantly I think it could have been done just as nice with a properly named function call.
I think the way it workd came from the DSL camp arguing that you should be able to make it look as though certain bits where native to the language, even if they weren't, and then the only uses we get are things that have nothing to do with DSLs but everything with children handling power tools (as in: bad idea).
Show me a single example of where operator overloading was necessity to make a function work, and I'll show you a more cleanly coded version using a function call.
The interesting thing is that after the compiler is done with it you'll be calling ::operatorX anyway.
Plenty of times there are naming issues as well, what does it mean to add two items of 'X' together, most times such a statement would be meaningless in the real world, but if you were forced to use a named function instead of an operator that function would have a name that matched what really happens.
Naming stuff is one of the great powers of computer languages, use of operators should be reserved to those situations where the outcome is predictable, and where operator precedence rules are the same as they would be when adding numbers.
So, it's fine to add an instance of a class called 'area' to another instance of that class, but you can't add one instance of 'boat' to another. That one should be done using:
cargospace = add_carcospace(boat1,boat2);
So what's stopping you? That's exactly the way I do it. In my C++ career I've only overloaded math operators for math types, * and -> for smart pointers, [] for container-like types, and () for callable objects. At least in production code... I did some crazy and irresponsible things in college, just like everyone else.
If there's one point I've been wanting to make over and over again in this discussion, it's that misuse of language features is a much smaller problem than people think. (In practice, it is even negligible next to the overhead of reading poor error messages from the STL.) C++ is a very bad programming language for people who fear their coworkers, but so are C, Ruby, and any Lisp with macros. Even Java isn't protection against stupidity: a bad Java programmer on your team can't confuse you, but he can bury you.
Just think of defmacro as implicitly adding an infinite number of infinitely complex language features to Lisp. If you can deal with defmacro in a responsible way, operator overloading shouldn't bother you at all.
Same with language features. If all you have is bicycles then nobody is going to hurt anybody badly. But if we're all driving rocket cars at 1000 MPh then the resulting pile-ups will be spectacular.
You use operator overloading in a disciplined fashion, because you understand fully what the consequences are when you are using them improperly. If a situation is a 'natural' for overloading then you'll use it, otherwise you'll use a function with a descriptive name.
Unfortunately that is not the norm. You'd almost want an '--expert' flag given to the compiler before you are allowed to use those features, and every time you want to use it you get this trick question about some obscure bug that you have to answer :)
The best little C bug I saw in some forum somewhere by the way was this one:
int x,y;
x = 0; /* initialize both x
y = 0; and y to 0 */
domorestuff(x,y);
And as the below(above?) poster said - there is syntax highlighting. It's not the greatest example of failure.
So instead of view = projection * model; you would prefer.
view.SetVector(Multiply3x3matrixWith3x1Vector(projection.GetMatrix(),model.GetVector());
Should we allow floats an doubles to be multiplied with a'*' or should that use properly named classes
How does someone looking at the code know which parts of projection and model get multiplied here ?
At least make it:
view.setVector(projection.getMatrix() * model.getVector());
By making it explicit what gets multiplied the code is less clear than it could be.
If they're simple arrays without further fields attached to them then you could do:
view = matvecmul(projection,model);
Multiplying matrices is no more weird than multiplying a float by an int or a positive and negative number.
It's a DSL that is similar to EBNF that generates parsers. It would be considerably more difficult to use without operator overloading.
Unfortunately its use is not quite limited to code like that.
IMHO, C++ is an amazing extension to C which managed to increase productivity for those tasks for which C would have been the right choice (modulo non-standard compilers).
If I were writing a performance-critical system-level program today, using C++ would be no brainer. You can fake a lot of what C++ offers with macros and function pointers in C, but lose type-safety and/or performance. I am very thankful to all the people who have brought C++ to the state it is in today.
Now I clearly understand what some of the veterans in "Coders at Work" really meant by "Very little progress, if any, has been made in the Programming space".
Now you need "two hammers" to get a single job done. Your current programming language of choice and a data expression language.
For example: In C, C++, Java, or related, you "first" have to build you structure to represent a Person with first_name and last_name and then you have to write it to JSON:
Java:
class Person { String firstName; String lastName; }
var names = [{"firstName": "John", "lastName": "Smith"}, {"firstName": "Bob", "lastName": "Jones"}]
eval("(" + names + ")");
Lisp ver:
(defvar names '((:firstName "John" :lastName "Smith") (:firstName "Bob" :lastName "Jones")))
(eval names)Not if you're using Protocol Buffers, which is essentially a version of JSON that has "batteries included."
> Lisp ver:
Lisp is not the only programming language around. How am I going to consume that data from another language? Embed an entire Lisp interpreter?
Well, at least for that particular set of cases I think you've just solved the halting problem ;)
But this isn't just a problem with the core language itself, but with the compilation model and linkage model - and the compilers and linkers. You need include guards on the top of your header files to make sure the code doesn't get re-included. You have to aggressively forward declare to work around declaration dependencies. And you have to trim the files that you include to keep compile times under control, because here's the fun thing about C++: For every .cpp file in your project, you will end up reading in and parsing the same damn header files again and again. In a large project, that might mean recompiling the same header files 1000s of times. Precompiled headers aren't a good solution, either - because when you have to touch the header, you pay a huge cost in recompiling the PCH.
In every other language I've used, I haven't had to worry about carefully restructuring code (sometimes at a cost in performance) to reduce compile times - because the core include and dependency mechanism sucks so badly.
Finally, C++ as a language is very poorly extensible. By this, I mean in compared to languages like LISP (with macros), or Ruby / Scala, which both make writing DSLs very easy. This is especially unfortunate, given that is so heavily used in a lot of very specific domains. And don't get me started on templates - I couldn't dream up a more backwards and awkward way of doing generics if I tried.
Problem is, every shop is inventing their own subculture. When programmers who haven't worked together look at each other's C++, they're basically learning a new language.
I do think this has changed a bit in the last few years. The whole 'design pattern' meme exists primarily to create nexuses of style that programmers can gravitate to. It just seems like such a slow way home, especially in comparison to a language like Python, which goes out of its way to restrict the number of ways you can skin the cat.
Has any serious programmer ever looked at a Python file and said "wtf?" for more than a minute or two? And, has any experienced programmer not had the experience of looking at a new batch of C++ (say at a new job) and thought to him/herself, jeez, this is going to be a lot of work just to understand the basics of what they're doing?
I think the book might have worked better if it was organized topically, instead of by person.
Yet for some reason people still use it. The question is 'why'. For many cases (not all though), I think the reason is largely just institutional inertia - you stick with the devil you know rather than the devil you don't know.
When I program in C++ (and sometimes you have to) there are features that I'll avoid like the plague, once bitten, twice shy.
In fact, my subset of C++ was usually try to stay as close as you can to C and use C++ when you have to. That seemed to be a pretty safe route.
Most of my C++ stuff was using Borland C++ Builder or Microsoft visual C++, I'm happy to say I no longer have to support software for the windows platform, so no more C++ for me.
http://google-styleguide.googlecode.com/svn/trunk/cpplint/cp...
I'm digging scala's design, but have yet to really compare it for number crunching, and big library building.
By the way, the article didn't really dig into any specifics besides saying there was feature bloat in C++. Which languages don't have feature bloat? How much use can I get out of them?
If Google, Mozilla and many others can productively use C++ why other people can't? They even published guidelines how to use stable and portable subsets of language.
Also, they make fairly specific criticisms, and they have a track record of being right about such things.
Java seems to be the C++ replacement of the future, with C# pulling the other way.
Care to elaborate (I'm legitimately unsure what you mean, not being snarky)?
They're competing for the same space, so a business that wants to implement some functionality from scratch basically has these two solutions to choose from.
In the 'web' domain there are many many more choices, but for places like banks and such that were first dominated by COBOL, then reluctantly moved to C or C++, for the most part they are either looking at Java or C#.
It would be a more honest opening to just say "lots of smart people hate C++", and then proceeded with the examples.
Instead, it pretends like it is going to answer the question of why it is so popular in spite of being widely reviled, but then never touches on that.
edit: grammar
And while they're busy bitching and hating and pontificating, humble unknowns are getting things done and making the world a better place. C++ is to systems programming what PHP is to web programming: the loyal packhorse that the A-list wouldn't be seen dead on.
PHP, Python and perl are rarely seen at corporations that existed before the web came around. Their whole IT department is set up around a different kind of environment.
I think this is in part why the web is so disruptive, because it enables all these upstarts using very light and nimble stuff to challenge the big and established companies directly.
You can pretty much tell what is enterprise stuff and what is 'quick & dirty but does the job' by comparing hourly rates for programmers.
It also has everything to do with the length of time before someone can be productive in a new environment. If that length of time is very short then there is not a very high barrier, which tends to create a lot of 'wannabe' programmers in that language.
By raising the bar you only end up with people that are willing to invest a large amount of time in a platform, that tends to favour people that get paid for their work, which in turn is found mostly in enterprise locations.
Not sure if this is true in general. I work at a bank. We use a lot of Perl. Banks existed long before "the web", and our Perl stuff is not a web application either. All the internal web apps are Java.
It is kind of weird, actually -- Java for stuff like the HR apps, and Perl for the stuff that makes us money. (If it were my decision, I would use Perl for the web apps and Haskell for the algorithmic stuff... but it's not.)
That's interesting! That's the last thing I would expect from a bank actually, wonder how common that is.
But then again, is there even an 'enterprise scripting language' ?
> All the internal web apps are Java.
That's what I would expect. Sun really did some good marketing in that sphere.
>That's interesting! That's the last thing I would expect from a bank actually, wonder how common that is.
I've seen a lot of Perl used in banking/finance. It really is the "Practical Extraction and Reporting Language" and certainly seemed to have almost completely replaced shell scripting in the last place I worked at. One interesting anecdote about Perl was that a group I worked in originally chose ADA as their language when they were just starting out but eventually gave up and went with Perl just because of it's relative power and simplicity. That company also has a major initiative to replace alot of what was written in Perl (and runs the company to this day) with a system written in Java. That system is still not doing any serious production work and is at least a couple years late. I don't think it has as much to do with the Java language as the "this will be the mother of all systems" approach they tried to take with it in the beginning though.
Yours and gcheong's comment just above makes me wonder if someone missed the boat in getting an enterprise level scripting language out the door. It looks like there never was a 'natural' successor to stuff like JCL.
While I know who most of the people in the article are and respect their contributions to the world of software engineering, day to day real world pressures of delivery aren't the same as an example in a book.
A hammer isn't an elegant tool, but it gets the nail into the wood.
The problems usually come when people start to use all those nifty features in combinations, especially 'newbie' programmers going wild on all that high level sugar.
C/C++ is performance wise also as good as unbeatable, if you know what you're doing, which is another reason why it has such staying power.
An example is Google. They had to create a huge document to describe what part of the language their developers can use: http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...
- Only very rarely is multiple implementation inheritance actually useful. We allow multiple inheritance only when at most one of the base classes has an implementation; all other base classes must be pure interface classes tagged with the Interface suffix.
- Do not overload operators except in rare, special circumstances.
- Make all data members private, and provide access to them through accessor functions as needed. Typically a variable would be called foo_ and the accessor function foo(). You may also want a mutator function set_foo().
- All parameters passed by reference must be labeled const.
- Do not use function overloading to simulate default function parameters.
- We do not allow variable-length arrays or alloca().
- Be very cautious with macros. Prefer inline functions, enums, and const variables to macros.
The only thing that struck me when reading this that I do different is the use of ++p, I would avoid that at all costs.
Pre-increment is a great way to confuse people. I can see why they would use it though, another similar source of confusion (stemming from C really) is the difference between
*p++
(*p)++;You can bet that behind each and every feature that they decided to rule 'against' was some pretty solid thinking and possibly some very hard-won experience.
There's a guide for:
C/C++
R
Objective-C
Python
Don't give up exceptions; give up naked pointers. Use shared_ptr and scoped_ptr, and you won't have memory leaks due to exceptions. Use RAII consistently, and you'll find it's actually easier to handle resource management in C++ than in Java. Java's resource management is superior for memory but inferior for every other resource.
I think that is what such lists have in common :)
> For example, without GC exceptions are almost always going to cause leaks without the team being all C++ experts.
That is something I rarely have had trouble with, but I never worked much in teams. I did notice that the double-free and never-freed pointers are a good portion of the problems you encounter in live code though.
And every time firefox goes EWOL I'm fairly sure that somewhere deep down someones code just tried to reference a stale pointer or something like that.
Even in Java exceptions are not all that wonderful, I think they are just a way to say "I don't feel like coding the stuff required to handle this situation properly, let's thrown an exception".
You end up with more exception handling code sometimes than functional code and that isn't the right balance either.
Now, this doesn't stop empty catch blocks or other horrible coding practices, but professional software engineers should never let that happen in their code (and there are lots of people who do, and they shouldn't be getting paid to write code!)
Checked exceptions wouldn't fix the memory leak issues in C++, I routinely use the shared_ptr template to fix that, but it would be a good step forward.
> Now, this doesn't stop empty catch blocks or other horrible coding practices,
Exactly...
> professional software engineers should never let that happen in their code
I could show you some horror stuff I'm dealing with right now that does exactly that.
The bigger problem is that it works and that I'm having a hard time convincing other people that that is not how it is done.