Slashdot Mirror
Bjarne Stroustrup on the Problems With Programming
Hobart writes "MIT's Technology Review has a Q&A with C++ inventor Bjarne Stroustrup. Highlights include Bjarne's answers on the trade-offs involved in the design of C++, and how they apply today, and his thoughts on the solution to the problems. From the interview: 'Software developers have become adept at the difficult art of building reasonably reliable systems out of unreliable parts. The snag is that often we do not know exactly how we did it.'"
...at a university I know, they start teaching you programming in...Visual Basic. I can imagine the effect that has on the poor confused heads here who never eventually grasp other languages (including VB).
Maybe if they started with something like Pascal or something...but thats just not 'modern' or cutting edge nowadays...
I think this is the case in many institutions leading to low quality coders.
So he doesn't remember how he created C++ huh? That explains a ~lot~!
Agile Artisans
I wouldn't take programming advice from a guy who overloads the bit-shift operator to perform I/O.
It's important to choose one that is elegant and easy to work with on a day to day basis. C++ would probably be a bad choice. Lisp, however...
Crack - Free with every butt and set of boobs
Now that is just ridiculous. I'm using IE7 to post this article, and have been using it since its release, and I can say
This is only my second favorite Stroustrup interview. The first is here: http://www.chunder.com/text/ididit.html (Yes, I know it's a hoax.)
Which university is it that teaches Visual Basic? Please let us know the name and location of this university, so we can avoid hiring employees who studied there.
... who claims he developed C++ to make programming more "fun."
Am I having fun yet, Bjarne? AM I You #$@#$$@#@#$*% +++NO CARRIER
FTFA: "My brief definition is, correct, maintainable, and adequately fast. Aesthetics matter, but first and foremost a language must be useful; it must allow real-world programmers to express real-world ideas succinctly and affordably."
Sounds like Lisp to me.... It's a mystery to me why anyone would voluntarily program in a language that makes the things that should be easy difficult, and makes things like segfaults, which should be pretty darn hard to do, easy enough to accomplish by accident. Yet so many people do it.
"...looking at "average" pieces of code can make me cry. The structure is appalling, and the programmers clearly didn't think deeply about correctness, algorithms, data structures, or maintainability."
Maybe it's because the average programmer is enslaved in company business. They don't have the
time to create masterpieces or art in programming. Instead of that they are forced to create
something adequate in a given time. Happens almost everytime, when science becomes business.
I don't like that, you don't like that, no one likes that, but that's the way commercial industries
are working (at the moment).
Nothing personal, but Bjarne Stroustrup comes real short in the real world department. He has not been in the position of solving real world problems with C++. Someone like James Coplien has. I would be much more interested in the commentary of a front line warrior, than I would from a theoretical preacher.
"To those who are overly cautious, everything is impossible. "
The Firefox codebase is indeed a mess. Don't take my word for it, view it yourself: http://lxr.mozilla.org/seamonkey/source/.
Part of the problem is the severe over-architecturing. This over-architecturing has added much unnecessary complexity to the overall design of Gecko and Firefox. Much of it is "justified" in the name of portability. But then we find that other frameworks, including wxWidgets and GTK+, do just fine without the overly complex and confusing architecture of Gecko and Firefox.
It's just not easy for most developers to become up-to-date with the Mozilla codebase because of all this added complexity. Unless a volunteer developer has literally months to spend learning even the small portion of the code they're interested in working on, it's basically inaccessible to most programmers.
The constraints of the real-world often come into play, and we have developers modifying code they don't necessarily understand fully. And so we get the frequent crashes, glitches, memory leaks and security problems that Firefox 1.5.x and 2.x have become famous for.
It's likely that Mozilla should ideally rewrite a vast portion of their code, keeping simplicity in mind. That likely won't happen, and thus we will most assuredly still run into problems with Firefox and Gecko, problems caused directly by the overcomplication of the Mozilla architecture.
I see him almost everyday and I just want to hit him after taking ENGR 112 at Texas A&M which is supposed to be a basic intro course to programming and it is hell on earth...
More like accretion.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
PIC microcontrollers in particular. Not only do you know exactly what the chip will do, but since it's programming on a reasonably small scale, you can have complete control -- right down to the actual bits -- of everything on the chip. Small, efficient, fast -- and with a bit more effort, you can do a quick mathematical proof that the software is airtight.
I realize this is completely impractical on a level of an operating system -- but TFA is right; if we could put a little less emphasis on having the shiny new gadget right now (and I know, I'm as bad as anyone), we could have much more reliable software. Do enough people want it that badly? Maybe not.
Paleotechnologist and connoisseur of pretty shiny things.
It's a mystery to me too, but at least they're not using perl!
The good thing about working in software-centric companies (besides understanding the programmer psyche) is that they often don't balk as much at being told something can't be done in a timeframe. Blizzard doesn't blink an eye when it has to delay a game by a year (probably more like 2 or 3 years when compared to internal, non-public set dates). Microsoft finally decided to nuke WinFS once they finally conceded that you're not going to get it within this decade, no matter how much they throw chairs. Google apparently has almost no schedules.
To all those people saying C++ is too dangerous/prone to errors and Java/C## is the way ahead:
Stop blaming the tools and look to yourselves.
C++ is like a sharp scalpel. Yes you can hurt yourself if you're unskilled, inexperienced or sloppy.
Java and C# are like those scissors with rounded ends for kids. Totally inefficent but safe for beginners.
Unfortunately it seems that there are a lot of people out there who like to call themselves programmers but have no actual ability. Java/C## does a good job of removing their need to think and hiding their inate lack of skill which is why they prefer it.
But there's a reason why surgeons don't use plastic scissors. The same applies to good software engineers.
Well, one good reason to accept the possibility of segfaults is speed. C and C++ allow you to get down as close as you want to the underlying hardware, which (if the programmer is sufficiently skilled) can produce much faster code. Obviously this doesn't matter much in your average desktop software, but there are are any number of application types (3D games, simulations, animation/rendering systems, system libraries) where speed is still very much a concern.
Anyway, the typical unsophsticated (software development-wise) customer can't tell the difference between the two. This is made worse when many managers who were supposedly professional programmers themselves can't tell the difference. As far as I can tell, the only way for a programmer to deal with this is to simply BE great and be ready to move on if the customer can't see that greatness. Eventually they'll get somewhere that will appreciate it.
I also cover some of this in another reply.
is the last person I want to hear comments from about programming languages.
From the article: "Technology Review: Why is most software so bad?"
Come on Bjarne, be honest. It is at least in part, because most software is written in that awful language you foisted on the world. I think the state of programming today would be vastly more advanced if C++ had given way to Objective C.
The KISS principle is totally lost on that guy.
The moment you have 2 people doing C++ on 1 project, at least 1 person will be faced with code written using features they just don't understand. C++ has features to spare.
Think you know C++? No, you don't. Heck, the compiler developers are often unsure.
This is a recipe for disaster, as we often see.
C was hard enough. Few people truly understood all the dark corners. (sequence points, aliasing rules, etc.)
C++ is addictive. Everybody wants one cool feature. C code is somewhat easy to convert. Soon you're using enough of C++ that you can't go back, and hey, more is better right? The next thing you know, some programmer on your team got the wise-ass idea to use Boost lambda functions (for no good reason) and you find yourself with 14 different string classes and... you have a mess that no one single developer can fully deal with.
It is possible to get similar speed and memory efficiency without giving up safety:
Ada vs. C++
D vs. C++
Eiffel vs. C++
OCaml vs. C++
(and just for comparison)
Java vs. C++
Craft Beer Programming T-shirts
Of course surgeons don't use plastic scissors. But how often do you need a surgeon? Most of the time you need a cheap tailor to make you a suit. And that's when scissors come in handy.
C++ can do wonders when used by highly experienced people. But most of the time, it is more cost effective to get entry level coders and use PHP/Java/C#/whatever. You will get a (somewhat) working product cheaper and possibly faster. And time to market and cost is often more important than maintainability/quality.
And don't get me started on 3rd party C++ libraries. You'll need tons of them to move a finger, and you'll spend more time finding/eavluating libraries than coding. This problem is getting worse for other languages too...
--Coder
The problem with C++ is Stroustrup. Specifically, it's that, as what's now called "C++0x", the next revision, got underway, Strostrup insisted that C++ had no major problems - it just needed some cleanup. This was after a decade of trouble with buffer overflows and related safety issues.
C++ is unique in that it has hiding without safety. No other major language is in that space. C has neither hiding nor safety; Java has hiding with safety, as do almost all languages which postdate C++. This is not fundamental to a compiled language; Modula 2 and 3, and Ada, had hiding with safety. Nor is it related to garbage collection, inherent problems of an efficient, compiled language, or the needs of systems programming. Providing backwards compatibility with C while bolting objects onto the language led to safety issues that were never overcome.
Most of the problems with C stem from the "pointer equals array" model, the basic source of buffer overflow bugs. C doesn't even have a way to talk about the size of array arguments (well, C99 does). Dangling pointers are also a problem but a secondary one. C++ tries to paper this problem over with collections, but far too often, collections have to expose a C pointer to get something done. At that point, size information is lost. Right there is the biggest single problem with C and C++.
The C++ revision committee is dominated by people who want to do l33t things with templates, things nobody will ever do in production code but, they think, are really cool. There's a whole "generic programming" cult of abusing the template mechanism to do computation at compile time. Millions of users suffer from unnecessary program crashes, and the US is more vulnerable to malware and cyber-terrorism because of this focus. It's as if the IEEE committee on power transmission standards was dominated by people who were into making big sparks.
Stroustrup could have insisted on actually fixing the safety problems. But he didn't.
(I'm writing this as someone with over ten years of experience in C++, doing everything from protocol stacks to game physics engines to real-time programming. And after ten years, I'm fed up with the mess. This should have been fixed years ago.)
Sounds like Lisp to me.... It's a mystery to me why anyone would voluntarily program in a language that makes the things that should be easy difficult, and makes things like segfaults, which should be pretty darn hard to do, easy enough to accomplish by accident. Yet so many people do it.
To at least a large extent, probably inertia. People know imperative languages, they know "traditional" ALGOL derivatives, so that's what they use, either because they don't see the grass on the other side is greener or because they decide that they don't have time to make it to the bridge and across it before running out of food, because while there is grass where you are, there's nothing until the other side of the bridge if you go for it. (Okay, that analogy got really unwieldy quickly, but I think there's something to it.)
For instance, the ML compiler is written in ML. Do I have any flipping clue at all how you would write a piece of software anywhere near as complex as the ML compiler with ML? Heck no! At least not well at all. If I were to attempt it, I'd end up with ! and ref everywhere because I don't know how to do it any better. I don't know how you would really take advantage of the fact that ML provides first-class functions or stuff like that. Sure, I can write little toy programs in ML, but nothing of that scale. Lisp is even worse; I don't have ANY clue how to go about it there. But could I write an ML compiler in C++? I think I could. It'd take me a while, and I couldn't guarantee performance, but I think I would wind up with something reasonable.
(BTW, in case you can't really tell, I'm sorta in the second group in the analogy. I think Lisp holds at least a lot of promise for helping development (though I'm not totally convinced), it's just that I don't have time to learn not only a new language but in some sense a new paradigm right now.)
The problem with programming is that too many people that lack the talent are in the programming business. I know because I work with many of them. They are not detail oriented, they don't think strategically, long term, etc and just make a mess of code. They only want to fix the problem they need to fix without worrying about the effect it will have on the system, etc. This is what causes bad programs. Programming is easy enough that any moron can make something work, but to make something continue to work requires an engineering understanding, and this is something most people don't have. It's unfortunate.
Every time one of these articles come around the self-proclaimed experts who have completed no project bigger than their fucking graduation requirements break out their worn soap box and lament about the poor coders produced by the University system. Universities don't 'make' good engineers or scientists. If it is a good University it will provide the resources and direction to succeed at these endeavors if you're sufficiently motivated. And nobody can reasonably ask for more than that.
...Here! :)
Those benchmarks look fairly artificial. I'm not sure it makes sense to generalize such results up to an entire application.
Meh. There's absolutely no reason why a compiler couldn't put a check for NULL on every pointer dereference and throw a NullPointerException these days. We're talking one or two machine instructions here. Modern cpu-based branch prediction can easily make this essentially free. Is there a single C++ compiler out there that does it? Even as a compiler-specific extension? Not that I'm aware of (please, correct me if I'm wrong). Even if it was only for debug builds this would be beneficial, it's where 99% of segfaults come from in C++ code and it is what results in C++ code being so damn crusty:
Foo *f = somefunc();
if (f) {
f->blah();
}
is just pointless. somefunc should never return NULL. I should never have to check for it. But that's my opinion, I don't wanna get into a whole "exceptions are for exceptional circumstances, not errors" argument.
How we know is more important than what we know.
If Bjarne rewrites the C++ I/O libraries one more time I'm going to hunt him down like a job and stick my C++ Reference Collection (with bookends) up his ass.
Some of us have real work to do, you know...
And for that, I thank you. One of the things I love about C++ is one of the very things many people complain about--the freedom to create damn near any data structure in completely unique and novel ways. This freedom, however, is born out of complexity, and yet, that complexity isn't a major performance bottleneck or resource hog.
Posted anonymously because I already modded here.
That just makes things too hard.
This doesn't help much, either way the program will probably have to close, I suppose catching the exception means it exits a little more gracefully. Even if it was only for debug builds this would be beneficial, it's where 99% of segfaults come from in C++ code and it is what results in C++ code being so damn crusty: Both gdb and visual studio catch dereferenced pointers in debug builds and provide a stack trace.
I found this particular sentence very insightful:
``These dichotomies (between efficiency versus correctness, efficiency versus programmer time, efficiency versus high-level, et cetera.) are bogus.''
I don't believe C++ gets it completely right, but it's certainly true that some languages let you write code that is succinct, elegant, correct, and efficient. I think it all depends on offering the right primitives, powerful enough abstraction methods, and a good optimizing compiler.
Please correct me if I got my facts wrong.
Unfortunately it's not a named exception that visual studio throws, so you can only catch "all exceptions" and try to figure out what exactly happened. As long as you can get a stacktrace though, that's the important thing. I've had dozens of segvs that obliterate the stack.. that's just crazy.
How we know is more important than what we know.
Ok, then please explain why Open Source projects are full of flaws just like commercial products. Are all the geniuses exclusively employed by companies that stifle greatness and everyone else is doing Open Source? Please. Programming greatness is rarely achieved... anywhere. The problem developing for profit is that you need a product to profit from. That means you have to ship something that is imperfect just to stay in business and make a living. The problem developing on your own for free is, again, that you need to make a living and really don't have the kind of time to produce greatness (assuming your are capable). Either way, it comes down to resources. One can rarely get enough outside of work and one can rarely get enough AT work. Same problem. Business drives development just as much as it stifles it.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
No benchmark is ever going to be a definitive measure, the best they can ever do is give you an idea or the general qualitative differences. I think you'll find, however, if you were to actually try Ada, Eiffel, D, or OCaml for an entire application, that they do, in fact, compare very well with C++ - it's not like there aren't any significant large applications written in those languages (well, possibly not D): they get plenty of use in various industries and are well known for their efficiency.
Craft Beer Programming T-shirts
That must mean that Duke Nukem Forever is going to ROCK!! ;)
(Less than 5 months until Apr 27 2007, the 10-year anniversary of the initial announcement)
Why doesn't the gene pool have a life guard?
You can probably start with Dylan. It has similarities to Common Lisp and Scheme, but it uses a traditional infix notation. Paradigm-wise, it starts out a lot like C + structs, and you can explore out from there.
i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
Many of the points in the interview implied that software was simply soaking up all the hardware performance, and perhaps we could squeeze more out of the software. I completely agree, except ...
s /NoSilverBullet.html
http://www-inst.eecs.berkeley.edu/~maratb/reading
The problem is that the software is an order of magnitude slower than it needs to be because the hardware has increased in performance by 2 and 3 and 4 orders of magnitude. If we had held the software to the same standards as we used to back when the hardware cost more than the programmers, it would be more efficient - but would only be able to make use of a couple megabyte of RAM and disk. The looseness of current software is part and parcel of harnessing the hardware. The hardware didn't just allow us go loose with the software we wrote - it allowed us to use abstractions which were measurably less efficient, but which had the side effect of allowing us to harness the hardware in the first place.
As a pair of trivial examples, take arrays and dictionaries. When I ask interview questions like "Design a hashtable" or "Reverse a linked list", many candidates have to actually step back and think about the question! 30 years ago, designing a good hashing function was the mark of true talent, and gains were to be had by selecting the linked-list scheme which best suited the problem at hand. These days, many people don't really know why you'd use a map versus a hash_map, or a vector versus a deque. And, for the most part, they don't really need to.
Buffers overflows are caused by bad programmers, not C++.
C++ defines container classes which cannot overflow. Try using them next time you write some C++ code.
No sig today...
Because "Worse is Better".
That is all.
Wouldn't that be called D?
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
The problem with programming are books like Bjarne Stroustrup's "The C++ Programming Language."
I mean, just because a computer language was hard to write, doesn't mean it should be hard to read about.
--- have you healed your church website?
Which means you learn nothing other than a new syntax to program your same old style in (i.e, nothing worthwhile). Not to mention that Dylan's macro system will leave you crying because computational macro systems in a syntax heavy environment just suck. If you're really short of time, you're better off using it to learn Erlang, Prolog, or Smalltalk. With the first two, you'll learn new ways to think about programming; with the second, you'll at least get better tools and have more fun. Either is more useful than Dylan.
That is all.
What a name! Sounds like a distant cousin of G.Threepwood. I mean, you can even start a law firm with those names. Imagine a big plaque with the sign "Stroustrup & Threepwood" slapped on it.
:)
Boy that sounds expensive.
Or silly (me).
You are ever so right. If we had kept on hand-crafting our software in assembly, it would be able to squeeze out ever single last clock-cycle out of the CPU and use it. However, writing an application-server in assembly isn't anyone's idea of fun -- and it takes too friggin' long.
There are too many things that need to be automated with software for us to be able to keep on doing everything in assembly. Using higher-level languages has two advantages: it gets easier to express abstract concepts, and there is less technical knowledge needed to write software.
The price we pay is the inefficiencies introduced by interpreters, compilers and virtual machines. With raw CPU power still increasing, that's not so much of a problem -- all this time, we've been riding the wave of Moore's Law, writing software in languages with more and more abstract features.
That is not to say that there is no merit in being able to design a linked list, and surely loads of programmers stand to benefit from some additional lectures on data structures. But squeezing the last drop of performance out of the hardware is not an issue anymore.
More than that, when you write in a language that doesn't have as much needless complexity as C++, then you have time debugging, and performance tuning that you don't have if you're using Stroustrup's Great Train Wreck.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
After all these years, I have my doubts this interview was really a hoax.
I've never encountered a more overrated programmer than Stroustrup, nor a worse technical writer. The examples in his books would make any decent programmer cry, and the text would do the same to anyone who likes clear prose. Worthless crap.
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
I was at Ken Thompson's retirement bash at Bell Labs when Rob Pike was giving the speech mentioning all the great things that had been built at the labs. Bjarne was there too. Rob said "....., oh and some C++ language that no-one here uses...". Well you know those guys had the intelligence _not_ to use that OO on top of assembler idea. Shame the rest of the industry wasn't that smart.
C++ can do wonders when used by highly experienced people. But most of the time, it is more cost effective to get entry level coders and use PHP/Java/C#/whatever. You will get a (somewhat) working product cheaper and possibly faster. And time to market and cost is often more important than maintainability/quality.
... Thought so.
Sorry, but you're an Arrogant Assh*le.
I mostly do webstuff for a living right now and have been programming for 20 years. I use PHP for webstuff because the available pipeline and it's toolset are mature and I don't want to compile every 2 minutes. I'd use Java if I needed a GUI-app that is cross-platform. Which are the exact reasons for most people using PHP or Java. With you bullshitting about the o-so-experienced C++ programmers and the o-so-n00b PHP and/or Java people I doubt that you have the knowlege or experience to judge who's experienced and who's not. Show me the equivalent of jEdit in C++/QT or the equivalent of Typo3 in C++. Until then I suggest you change your tone of voice towards people choosing other PLs than your favorite.
P.S.: Just the other day I heard of this guy who wants to build a complex browsergame in C++. For performance reasons. LOL! We all know where that's going to end. Talking about choosing the right tool for the job. Now who's the unexperienced developer? Me or he who uses C++?
We suffer more in our imagination than in reality. - Seneca
You want Lisp. Hear me out.
Of course, the character syntax is superficially different. Operators use infix notation ("(+ 1 2)" is analogous to "1 + 2"), and have identical character syntax as function calls ("+", an operator in Lisp jargon, may be implemented as a function).
If you can sleep at night after that, your can define own higher-level language syntax that looks exactly like any other Lisp syntax. Lisp is extremely flexible in its naming of functions and variables (symbols). If you'd like, you could define an operator named .= as a function: (.= string new-character-strings ...) would modify the given string object, string , in-place, appending each specified new-character-string to the end.
Recognizing the downside to modifying random strings in-place, perhaps you'd rather have your .= operator assign a newly-instantiated string to the variable referenced by string . You could, by writing the operator as a macro. The macro would act like a function, taking as input each "raw" argument—symbols and lists, the structure as they appear in your program, before evaluation—and returning as output replacement Lisp code to evaluate in its place. So that your .= operator form of (.= out "lalala") is semantically equivalent to (setf out (concatenate 'string out "lalala")) (like out = out . "lalala"; in other languages).
It's not just simple textual substitution. You can use any function or macro in your macro definition to transform your input arguments into whatever replacement code you'd like. I'm using macros in Common Lisp to generate recursive-descent parsers based on a grammar production expression: the following form defines a function named obs-text that takes a string as input and returns a list of matches found as output:
(defproduction obs-text :* CR :* (obs-char LF :* CR :*) :*))
(LF
This function is defined in place and evaluated and compiled immediately by the Common Lisp implementation.
Macros can be abused, but they add a tremendously powerful capability of abstraction not possible with many other languages.
The problem with arrays has been fixed in the D programming language, http://www.digitalmars.com/d/, which is a reengineering of C++.
...right click on the project in VS2005 choose refactor -> refactor as c++. Problem solved in like 2 or 3 clicks :)
Destroy, erase, improve
cout > operators as I/O operators was a very poor decision , though I guess that fits in with the rest of the abortion that is C++
Time pressures and price are fundamentally incompatible with quality engineering. It's called a trade-off. It's nothing new. People always want to spend the least amount of money for the highest quality product developed in the shortest amount of time. Expecting anything else is naive.
Executive summary of article: The creator of C++ now works for Texas A&M, an educational institution, and he thinks the solution to the problems of software is more education.
The origin of C++
The way I started, was to learn every instruction set of a 6502 from a book, and virtual know half the op codes
of hand in hex. This without a computer, just paper and pen. Write some small functions on paper too. Like for loops
and atoi converters, and maybe sin(x) lookup calls.
Then once you can convert hex/dec/bin in your head and know half the opcodes in hex, you can start proper assem coding
on a computer to do cool funky stuff.
Once you see you are repeating stuff often, you get to appreciate the concept of library functions and you build yourself
a person toolkit api, micro libc hmmmmm. Then you implement half the apis in macros/functions.
Once you see the high level of things, jumping to C/C++ is a piece of cake and you understand it all.
Liberty freedom are no1, not dicks in suits.
This is the third time I discover that a language I know (the existence of, at least) was created by a fellow dane. The two others were Turbo Pascal (Anders Hejlsberg) and PHP (Rasmus Lerdorf).
So now I have to ask:
Have other danes created widely used languages, which I do not know of?
(I know that Hejlsberg have made a few more languages. I am counting persons, not languages.)
This article is a bit dates, I saw it a few weeks ago. Is Slashdot getting behind? In any case back on topic, in High School i had the pleasure of taking a IBM Basica course. Fortunately I had a brilliant math teacher in it, but unfortunately it was a bore. I learned most of what i needed by reading through the book in its volume in a couple of weeks. However, the most important things I learned from the class to this day include how to build an algorithm. When I got to college, they threw all the engineers in a Engineering 2 class that was supposed to teach all engineers C. Unfortunately we were taught by a Civil Engineer and he didn't have much understanding. This became apparent when they guy's idea of a sort algorithm required three separate arrays: One for the original data, one to mark that it was moved, and the final one. Using what I had learned in High School I decided that I'd show this professor what a real sort looks like. I think i implemented it three different ways and also did it his way. (His way was much more convoluted if memory serves). Anyhow, when the professor saw the work, the next day I saw my three examples circulating the room as examples. SO what is my point? I don't think its the syntax, or even basic concepts that our college programs are lacking. What is lacking is how to think critically and create algorithms for the situations we encounter. In one of my upper level courses we talked all class about the concepts of TCP/IP, but when it came to the programming projects were somewhat thrown to the wind. Now I'm not faulting this professor for that (it turns out the class was mislisted and should have required C++ as a prerequisite in the catalog. Too bad for me though. Once i got into actual CS classes they threw me into ada, which despite all its critiques was a GREAT language to learn on. I think all beginning programmers should be taught on a strong typed language. That way the can develop good habits.
I use C++ for my work, and I've been programming in C++ for many years. It's definitly a flawed language, in that even skilled experienced and careful programmers find themselves spending weeks tracking down bugs caused by memory overwrites and buffer overflows. Things that _will_ bite you with C++ are overloads of virtual methods (if someone changes the type of a parameter in the base class to be const, then suddenly your derived class is declaring a new overload not an override because it's not const ...) forgetting to declare a destructor virtual so you leak some resource where you delete through a pointer with the base class type, and the list just goes on and on.
Add to this the build dependency nightmare that causes a simple change (say, adding a member to a class that's used a lot) to take 10-15 minutes to compile and you have a language that simply takes you longer to get the job done. And the most expensive side of software development is the man-hours it requires, not that you have to buy a newer faster computer to run the software - so programming in an 'efficient' language like C++ is just not the way to go for most projects. In fact the time you save writing in C# (or Java or Haskell for that matter) instead, can be used for performance profiling and finding better algorithms - so in the end you probably end up with a more efficient program anyway.
The interactive way to Go -- http://www.playgo.to/iwtg/en/
Because they often don't have what it takes either: time, discipline and ability. Just because one kind of software doesn't have it doesn't mean that open source software has to have it. Making high quality code is often not as fun, and when I code for myself it's usually for fun. Just because I'm making something for myself doesn't mean that I don't have time pressure, or that I'm inclined to be more disciplined than I am when I'm coding for work. If I'm only a mid level programmer at work, I don't magically get smarter when I program for myself at home.
The real, core, problem behind bad software is a requirements issue.
There are several things that come to play here:
- People don't know what they want until they have it.
- Mass market products (office, browsers) use an averaging effect of either focus groups or "representative guessing" to determine requirements for people that won't know what they want til they have it.
- Users and developers don't want to talk to each other.
- If someone makes them get in a room, users and developers tend to talk in different directions, having different mental models of the domain space.
I'm sure there are more. That's the top few without writing a book.
There are a few elements in his answers that have some truth about them -- the constant panic and rush causing lower quality -- but they all tie back to these. The panic and rush are there because everyone is trying to patch over the problems and miscommunications several steps too late.
Additionally, the sorts of things that wouldn't make an academic or intellectual cry when reading code are artistic fluffery. Brilliantly clever "pretty" algorithms end up being unreadable and incomprehensible either at 3 in the morning or by the guy that's really just a coach at heart and is in your code. ("I'm in ur code, coaching ur variables")
maintainability and readability ftw.
If it should never be null, you should be using a reference anyway.
Decent C++ code is a lot less crusty than java [although the custiness
of java decreased a lot when they introduced generics].
http://rareformnewmedia.com/
"...The snag is that often we do not know exactly how we did it.'" Anyone seen my missing sledgehammer?
i submitted this article last week, with nearly the exact same summary, and it got shot down in seconds.
Lisp has a habit of appearing rather messy at times, and some standard libraries (such as CLOS) are not particular elegant or aesthetically pleasing, at least to my eyes. I suspect that Lisp suffers from a lot of historical cruft in it's standard libraries - CDR anyone?
I prefer the aesthetics of Haskell, myself, though it would be rather interesting to see how elegant and expressive one could make a Lisp dialect.
std:: libraries that concentrates on _practical_ application development instead of spending forever defining the language in terms of cosmetic perfection and pure computer science and data structure.
A lot of us are tired of choosing a database library, a threading library, an XML parser, RPC mechanism, network libraries, etc. etc. etc. even at the *prototyping* stage.
That's why many developers flocked to Java/C# and never looked back. Not because of complexity, pointers, etc. Heck, I'm sure a lot of Java devs migrated from C++ understand all the C++ concepts, even the newer ones like Policy-based design.
We went away because we don't want to spend time choosing or reinventing the same things over and over when we make a prototype of mock up and learning too much non-transferable knowledge about customized libraries. If C++ were like Java where the std:: API is constantly updated with common, basic, high level constructs (no, NOT vectors and stacks, I'm talking about portable network stacks , FIFO mutex locks and XML parsers) many of us wouldn't have left.
C++'s problem is that it's too restrictive on how std:: should be updated.
Ladies and gentlemen, there are practically NO hairy old idiots banging on about how great LISP is in this thread! Well done, all!
To address the cosmic imbalance caused by this sudden attack of maturity, though, let me do the job myself:
Lisp is great because it is functional (except for some stuff they had to bolt on).
Lisp is great because it is not functional (except for some old stuff from the early times).
Lisp is great because it is the 'classic' hacking language, free of new-fangled gubbins.
Lisp is great because it contains exciting new features.
Lisp is great because it is easy and intuitive, because it is so pure and orthogonal.
Lisp is great because it forces you to think to get anything done, because it is so pure and orthogonal.
Lisp is great because it would be easy to write a worthwhile application in, because it is so pure and orthogonal.
Lisp is great because as nobody has ever written an important application in it (editor macros and 1970s random story generators are not important), it's free to be pure and orthogonal.
Lisp is great because it uses tail recursion instead of silly old 'iteration', because recursion is really pure and functional and orthogonal.
Lisp is great because it can almost nearly manage plain ordinary iteration, by using a weird hack called 'tail recursion'.
Lisp is great because of the Fourth Rule of the Internet:
"The smaller and more specialized a fan community is, the more fanatical and argumentative they are."
Whence? Hence. Whither? Thither.
That's a good question. The purpose of a programming language is much the same of that of mathematical notation, which is to allow you to think at the level of abstraction of your problem while not wasting time with irrelevant details. Modern calculus notation gives university freshmen the ability to solve problems in a few hours that baffled the greatest minds of history for thousands of years.
Note that this doesn't mean that you don't have to think when learning a mathematical language. The concepts of limit, derivative, and integral are difficult to grasp at first, but once you understand them, they offer powerful mathematical methods that allow you to think about the problem at hand and not the notation you're using.
Can computer science make similar claims? The jump from assembly to FORTRAN was a tremendous improvement in productivity, but FORTRAN to C or C to C++ produced small to no productivity improvements, perhaps in part because you have to think more and more about the language. We should be looking for a language that may require thinking to learn, but that once when learned offers powerful methods at a high level of abstraction that allow you to think about the problem without being distracted by the language.
I would suggest that we look at languages like Haskell, Scheme, or Smalltalk, which do require that we learn concepts like currying, higher-order functions, monads, and type classes, but which offer a higher level of abstraction and greater consistency than languages like C++ or Java.
>Same goes for VB. You make something that works the way
:)
>you expect, then you make it work in a real language.
Or, if it actually works, you could just, like, use it
Bjarne, is that you?
Not enough is made of the sheer obfuscatory nature of C++. C was already somewhat cryptic, but at least it was small. C++ is cryptic and large, and that's really a bad combination. At one point in the interview Stroustrup recounts that half the programmers he polled who said they disliked C++ then admitted they had never programmed an application using C++. He calls that prejudice. I call it perfectly normal human behavior; if you begin to study a language and quickly discover it to be a load of tailings, then you will be disinclined to program applications using it.
That was my experience anyhow. I began studying C++, and at some point I stopped and asked myself, "Why must I endure this? Surely there must be better options." And I was right.
I really have to grit my teeth when Stroustrup talks about C++ "winning" against competing languages. C++ is successful for the same reason that COBOL and Microsoft Windows have been successful: because they happened to appear in the right place at the right time, and were promoted by the right people, to become entrenched. Once entrenched, the world was saddled with them for decades to come. It has nothing to do with their inherent qualities or advantages, it's little more than random chance.
Sounds like Lisp to me.... It's a mystery to me why anyone would voluntarily program in a language that makes the things that should be easy difficult, and makes things like segfaults, which should be pretty darn hard to do, easy enough to accomplish by accident. Yet so many people do it.
.asd and the .lisp with the defpackage form) that must be kept in sync with the source too. I would much rather have "(import my.lisp.packagename)" and have it Just Work.
I've been converting to Lisp since last January, and a few weeks ago I had a sore temptation to give up and spend more time on C++. Yes, I LOVE Lisp macros, CLOS is pretty powerful, and closures, and in general the "completeness" of the spec is astounding. HOWEVER:
1) The packaging blows. The CL's have settled on ASDF, which requires two files in addition the the source (the
2) Like Java, Lisp is both a language and a VM. In this case, multiple VMs that are all extended in incompatible ways to provide the functions that we need that aren't in the HyperSpec. The current OSS leader SBCL has rendered defconstant absolutely useless in flat violation of the accepted practice. A couple months ago I got CMUCL to segfault on an invalid pure-Lisp form. GCL doesn't yet support CLOS. I haven't yet bothered with CLISP, but I'm sure my code will expose other issues.
3) Also like Java, Lisp is too far away from the underlying OS. Case in point: pathnames. My first project in Lisp was to iterate my MP3s and call stat() to get their size. Imagine my surprise when I discovered that it was possible for (directory #P"foo") to return a pathname whose (namestring) could not be passed to (unix:unix-stat) (this is CMUCL). CMUCL had taken the OS-specific filename and munged it to a Lisp filename that was at that point useless to me. So I had to write my own pathname that would actually work on Unix just so that I could get file sizes without having to open files.
4) Performance really does matter. I've got Lisp code whose purpose is to read 30-100MB of floats, do some trivial manipulation, and write a few KB of output. The first version of the code took 5 minutes. After several DAYS of testing -- and learning that CMUCL has no decent profiler -- I finally figured out that the bottleneck was parsing floats. I dug into c.l.l and saw some code to improve parsing: CMUCL already had implemented that. I found two different libraries for parsing numbers, each improved performance significantly. I'm now down to about 1MB/second of processing speed. ON A 2.4GHZ PROCESSOR. My next step is to use UFFI to wrap strtod() and see if that makes things any faster.
I'm staying with Lisp through another round. Maybe another year will give me the skillz to make Lisp on par with Java and then within 1.5x of C. I like the VM, I like the macros, I like the language and syntax. I may even volunteer to help with maintaining a CL and REALLY dig deep. But these humps are ridiculous and I can only hope the next generation of Lisp hackers fixes them for the future.
Holy ego alert, batman! Has BS ever worked in a modern, high-level language?
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Personally I don't think starting off with "easier" languages is the answer, and I'll explain why. I started programming in VB3 and continued to do so awhile after the release of VB6. When I attempted to learn C it was very difficult at first. It was tougher and more of a bare bones and "do-it-all-yourself" language. It's when I really got heavy into C and assembly that I really learned about computer programming. Now, I think that if I were to start all over or teach someone to be a computer programmer, I'd have to say I would first teach them the basics of true computer programming in assembly. I wouldn't expect them to be an expert, but I would want that person to be able to atleast read and understand assembly and what a computer can do with data at that level. If you have a decent understanding of that, you can pick up any language a lot easier and quicker. Going from ASM to C would not be tough, hell, you'd welcome it and love it. And as your mind develops the "how things came to be" and structured thought of programming, learn something like C++ or anything with OOP. Once you have that knowledge you have a good sound understanding of programming in general which will make life a lot easier as you learn different languages, but having that sound foundation is the most important.
I disagree. Stroustrup's "The C++ Programming Language" [TCPL] is one of a small set of computer books I am willing to reread.
The first time I read TCPL, I thought it was a horrible book. I was trying to learn the language details and there appeared to be a significant amount of cruft and useless information. (For example, his discussion of how containers could have been object based.) It didn't simply detail how the language actually worked (to my dismay).
Over the years, though, I've often found that the very sections I most disliked had the most useful information. If I'd paid more attention and thought a little harder about what Stroustrup was discussing, I would have avoided a number of programming pitfalls---and not just in C++.
FWIW, I find the animosity toward Stroustrup in some of the posts very odd. Is it a pissing contest? My set of programming gods sit higher than yours?
AC
I always see the comment that most bugs are from memory mismanagement and pointers. I've been writing large C++ applications for 10 years. The most common bugs I see are usually fall into two groups. One group is very simple isolated logic errors and typos. The next group are from unknown side-effects from calling libraries/modules the programmer is not familiar with.
C++ is amazingly good at hiding these side-effects. Frequently, even though code is broken up into different modules, a programmer needs to have a full understanding of all the other modules the module they are working on uses or is used by.
This problem seems to be compounded with the increasing popularity of "event-driven" programming. I've worked on two systems that use event-driven programming and it is a pain to code for and really a pain to debug. I've seen some nasty hard to fix bugs from circular event cycles. The reason for these was because the programmer did not have a full understanding of all the modules that sent and received events from the module he was working on.
A recent application I worked on used QT slots and signals for ALL communication between classes. I had to spend a large amount of time understanding the whole system and figuring out what classes received what signals just to fix something that turned out to be a 2 line code change. The signal was propagated through several classes before it got to the class that really did the work.
It seems that programmers are trying to take things that work well in GUIs and forcing them on the code that does the algorithm code behind the GUI. Object-oriented and event-driven is really nice for GUI programming, it can make programming non-GUI elements of an application very difficult. Some problems just aren't OO, yet when a program is determined to be OO, everything is forced down that path no matter how ugly the OO design is.
What we need is an easier way to use the methodology that best fits the current problem. The problem is that no language allows you to use different methodologies effectively. Some problems map very well to the functional methodology, yet it is not easy to do using C++.
If different languages could work together easier, it would help. Then the proper language and methodology could be used for the given module. Managers would then complain that they would need to find programmers that knew more than one language, so it won't happen. I'm waiting for C++HaskLog. Then programmers will be able to use procedural, OO, functional or logic programming all in one language.
0) flow chart a ring buffer ...
1) write a program to calculate something using shell script. 'something' might be pi, the area of a triangle, the volume of a cone,
2) flow chart a two pass compiler
it's not-so-strongly-typed variables, funny rounding rules and so on
I know they're like [pagan] Gods to an awful lotta people in the CS community, but The Founders of The Art, guys like Kernighan, and Ritchie, who had the chance to insist that a declaration actually mean something, but hesitated, and hemmed and hawed, and got all wishy-washy, and finally decided [really deferred a decision until it was too late to make a decision] that a declaration could mean any-damned*-thing that the implementor wanted to interpret it to mean, well those guys, those pagan Gods of the Founding Arts, seriously - someone should take them out behind the toolshed and whip their asses** [if not shoot them outright].
So now, fast forward 30 or 40 years, and we've got:
And then you go to do something in VB, or in Javascript, and you get shit** like
or, what's even worse,
and you end up having to write shit**** like
and you scream at your computer, "YES, THESE ARE NUMBERS, NOT CHARACTER STRINGS, YOU GOD-DAMNED***** COMPILER/INTERPRETER/SYNTAX/PARADIGM/NIGHTMARE OF A SACK OF SHIT******!!!!!"
PS: There is a special circle in Hell******* for the sonuva bitch******** who dreamed up the idea of interpreting variable types on the fly...
*Pardon my French.
**Pardon my French a second time.
***Pardon my French a third time.
****Pardon my French a fourth time.
*****Pardon my French a fifth time.
******Pardon my French a sixth time.
*******Pardon my French a seventh time.
********Pardon my French a final time.
From the article:
How often have you worked on a prototype or demo, only to have the time/expense budget slashed because management decided you must be almost finished when they see a demo GUI?
How often have you encountered copy-paste-edit code replicated throughout a system because no one had the time to refactor the replicated code into a reusable module?
When did you last have the time and budget to clean up that rushed prototype via refactoring before the next phase was in crunch mode?
How often were you told you can't refactor code because it's already been tested and put into production?
How many "silver bullet" tools have you tried over the decades, only to find that they're marketing hype and often increase the total workload instead of saving time? (e.g. Now you have to maintain UML models as well as the code and database schemas.)
As long as the "push" is to get it done faster regardless of long-term costs, crap code will continue to churn.
I do not fail; I succeed at finding out what does not work.
So what you are saying is that the quality of commercial code has very little to do with business pressure and is mostly just a result of unskilled and/or unmotivated programmers.
Anyway, I'm tired of programmers complaining about how their company stifles their greatness... as if they were producing greatness outside of work (or would given the chance).
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
Time pressures and price are fundamentally incompatable with code quality, even amongst the best programmers.
This is summarized in an old engineering saying. Not just software development, but pretty much all design and construction and engineering has the same issue.
Good.
Fast.
Cheap.
Pick any two.
This ignores other things that contribute, like how good the people involved are. But it is still a very valid saying.
This is my sig. There are many like it but this one is... Oops. Frank, I've got your sig again! Where's mine?
I don't agree that "the earth would be a better place without this plague," but I'd like to see it replaced by something better, such as a pair or family of languages (with easy, natural, logical interoperation) that cover the same ground covered by C++.
The main problem with programming is caused by the lack of education. A lot of schools are spending more time teaching a programming language (usually a higher level language like python or java) rather then teaching concepts of computer science. Of course the kid who has only programmed in java is gonna find concepts like pointers and such more difficult, making C++ seem much more difficult.
Klingon Software is not released, it escapes, inflicting terrible damage onto the enemy as it does
Are you kidding? That's the best-written book on C++ on the market, and one of the best computing books, period. Most of the books on the shelves at Barnes and Noble are written for idiots with years of experience -- all they know how to do is appeal to ill-fitting concepts you've already learned in another domain. The best books, like TC++PL, are the ones that clearly and logically teach concepts, which requires a bit of intelligence on the reader's part but saves him from sloppily carrying over inapplicable concepts from one domain to another.
The "down close as you want to the underlying hardware" that you do in C is simply bit-twiddling in random locations in memory.
C compiler technology is good not because C necessarily maps well to modern instruction set architectures and real machines, but because C is so popular that people have invested a great deal of time in optimization to make up for the poor mapping of automatic and register variables to the stack and machine registers of real processors, and the order of operations in the source to an efficient order of processor instructions, among many other things.
A number of functional programming languages have even better compiler technology available to them, but because of the huge popularity of C and its descendents, few people are even aware of that, and those that are tend to resist moving from a C (or C with objects) mindset to a functional programming one.
Most of these FP languages can call out to standard libraries written in other languages, either directly through a native FFI or through some sort of bridge. Some also have native primitives that allow for the same sort of arbitrary and unmediated memory manipulation that is done in C, if you really want to do that.
Moreover, a handful of interesting ones allow C to invoke libraries written in these FP languages, making mixing-and-matching language/compiler to the computational tasks they're good at fairly easy.
Writing everything in C or C++ just because the compiler is pretty good at generating object code is silly, since speed is rarely globally critical within a program. The speed-requiring bits can be coded in C (as a sort of portable assembly) while the rest can be coded in something that trades speed for greater safety or greater expressiveness or both. As you say, "this doesn't matter much in your average desktop software". So why resort to C or C++ all the time?
Indeed, many speed-critical sections of applications written in C or C++ actually include inline assembly, especially when a vector processing unit is available. Examples can be found in "3D games, simulations, animation/rendering systems [and] system libraries". That's because despite the ease of manipulating arbitrary bits in memory in C, often the language and compiler end up producing results which simply aren't as fast as one can do by hand in an even lower level language (like a macro assembler).
I would actually say teaching functional and procedural would be good too. When I was at university they started teaching functional (Miranda) and procedural ( C ). Then they added object based (Ada) and assembly. If a suitable OO language was available then they would have taught it. Smalltalk was available, but most of the VMs were a fortune.
My point is that I think a good CS course should include a wide variety of programming languages, so people learn to be flexible. Given how fast things change in IT learning flexibility of mind is important IMHO.
Jumpstart the tartan drive.
Rightly or wrongly, many people assume that there are only a limited number of "side-effect" from operators other than the "="/ASGN and "++" and "--" operators because it looks a little bit like "algebra" instead of an evaluation expression.
Some of the original design features of C make this a little bit more unlike most people's experience with algebra (e.g., the use of "=" instead of ":=" and other keystroke savings shortcuts often confuses people with expression like "i=i+1") and reduces the visual cues for side effects.
Later on C/C++ introduced "const" functions to between functions and procedures, but there aren't any syntactic visual cues for the person reading the code and at least for me, that is why I try to steer clear from operators that have "user-visible" side-effects to promote code readability...
Also, binary operators often have a visual ambiguity problem with precidence and are generally poor candidates for overloading (because people don't always remember the precidence orders of the operators on inspection in an arithmetic context, it's even worse when you lose the aritmetic context and have to remember them explicitly).
Of course, it's probably a losing battle with C++, but personally, I think it's worth trying to mitigate to the extent we can. It's too late for bit shift on I/O, but at least we can avoid it going forward. Just because operator is meaningless, we assign it some meaning might be okay, but only if it fits in the semantic framework that most people have. If it doesn't fit the framework that most people have, it's just another barrier to learning and it's a bad pattern/example to set for people to emulate. Remember it isn't technically part of the language, but the library, and people are writing new libraries all the time (and making more overloaded operators at the top scope of their programs all the time for the new objects they create).
Following your logic would argue that multiply doesn't mean anything on pointers, so it is okay to make it an overloaded operator to increase the reference count and make a backup of the underlying object in a log file (multiply like rabbits). I think that would be a totally broken use of the multiplication operator myself.
Which means you learn nothing other than a new syntax to program your same old style in (i.e, nothing worthwhile)....If you're really short of time, you're better off using it to learn Erlang, Prolog, or Smalltalk.
You missed the part where I said "explore out from there." Erlang, Prolog, and (to a lesser extent) Smalltalk have steep initial learning curves. It's hard to ease into those language and do something useful right away. With Dylan, the o.p. can program in a style he is used to, but gradually adapt newer techniques as he becomes comfortable with them.
The o.p. had already mentioned LISP, and said he didn't have the time to deal with learning so much new stuff all at once. My suggestion was for an advanced language with less to initially learn.
i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
Stroustrup did not consider the scope for misuse by stupid people.
Agree. Plus there is the issue of how much time you need to get proficient. There is almost no way taking a CS class and doing a few assignments will give you enough practice to be really fluent in any computer language. It will get you semi-competent at best and you'll be a danger if let loose on a real-world project. But if you spend some extra time outside of class coding something you care about you may have a chance at proficiency. It is like the difference between someone who's going to a guitar lesson once a week vs. the guy who has has own band (however bad) and is spending all his spare time on it. Which is not to say some book knowledge and assistance won't help but practice is a big part of it, in my experience.
Fixing the "safety problem," as you call it, would involve an increase in execution time.
That's a common belief, because the safe languages we have now are mostly inefficient ones, but it's wrong. Subscript checking is cheap if done right, in the compiler with appropriate optimization, because most subscript checks can be hoisted out of inner loops. This was done in a British Pascal compiler in the 1980s, but I don't have the reference handly.
The problem in C and C++ is that there are too many cases where the compiler doesn't even know how big an array is, so the compiler can't check. If you try to do subscript checking in collection classes, the checking is inefficient because the compiler doesn't know enough to optimize it.
Here's the general idea of how to do it right:
That code implies a test for i < n at tab[i]. That would seem to add overhead. But if we allow the compiler to hoist checks upwards, that test floats to the top of the FOR statement. We then have the test of the FOR statement, i < n. So we have "i < n implies i < n, as the test, which symbolically evaluates to TRUE at compile time and can be eliminated. The compiler can thus this do this subscript check with zero overhead.
That's how you get safety without overhead.
Certainly there are situations where the checks can't be performed entirely at compile time, but usually, they can be pulled out of an inner loop by standard compiler hoisting and strength reduction techniques. So the overhead is quite low in code hot spots, where it matters.
Note the syntax float sumarray(size_t n, float tab[n]). That's C99 variable array syntax. Instead of writing float tab[], or worse, float* tab, you actually give the array length. This doesn't cost anything, because the length isn't actually being passed. It just tells the compiler where the length information is to be found, should it be needed.
At a call to sumarray, checking is also possible. Consider
The compiler has the declaration of "sumarray" available, as float sumarray(size_t n, float tab[n]). So, given this, the compiler can check the call. It needs to check that lengthof(tab) >= 1000. No problem there; that can be evaluated at compile time.I've suggested that C99 array syntax be generalized to give parameters the scope of the entire declaration, allowing float sumarray(float tab[n], size_t n), where n is referenced before its declaration. This allows standard C idioms like int write(int fd, char buf[n], size_t n).
Microsoft R&D is working in this direction for C#. Check out the "Spec#" effort. The trouble with C++ is that the language is so broken that you can't use such technologies.
We had much of this technology working in the early 1980s, but machines were too slow back then to tolerate the compile times. With the 3000x improvement in CPU speed since then, that's no longer a problem.
The Design and Evolution of C++
as
The Design Rationalization and Evolution^WMutation of C++
for just that reason.
To a Lisp hacker, XML is S-expressions in drag.
Garbage collection isn't well matched to C++, because C++ has destructors. Reference counting, like Perl and Python, is more appropriate. Microsoft did retrofit garbage collection to C++, in their "Managed C++ for .NET", but the result is horrible. Calling destructors from the garbage collector results in concurrency problems, locking problems, and indeterminism in otherwise deterministic programs. There are even some awful cases in Managed C++ where "re-animation" occurs and a destructor is executed twice.
With reference counts, you get consistent behavior. You do need weak pointers (in the Perl sense, not the Java sense) to make it work. There are "smart pointer" classes for C++ which attempt to do all this, but they all flounder on the problem that at some point, you have to expose a raw pointer to use the object properly. This makes the reference counting system too fragile.
Take two type-inferring languages and call me in the morning.
(That said, the general sentiment that a standard should strictly define everything that is important is a great one. The problem is determining what's important. When your language is one that is meant to sit directly on top of machine code (like C), the size of a numeric type is important. Grr.)
I [may] disapprove of what you say, but I will defend to the death your right to say it.
C++ is successful for the same reason that COBOL and Microsoft Windows have been successful: because they happened to appear in the right place at the right time, and were promoted by the right people, to become entrenched.
You're half-right. C++ "won" the application development language contest for these empty reasons. However, part of its staying power comes from the fact that, sooner or later, you need a "low-level" language to actually write fast code behind a well thought-out interface, once, and call it a library. These are two vastly different purposes, and I'd agree that C++ is as ill-suited to large-scale application development as VB is to efficient library development. However, the folks out there who need fast linear algebra routines, or lean, memory-efficient text searching, or [insert well-defined write-once problem here] often choose C++ for the right reasons.
Now, there's a legion of people that will shout "use C for that!", while trotting out the same application-level arguments they always use against C++. If there are any doubts in your mind about the advantage in expressiveness C++ has over C, take a look at the Blitz scientific computing package. C++, in some cirumstances, grants a pretty magical ability to create useful abstractions with essentially no abstraction penalty. Even if the code behind the abstraction is a template swamp, the code in front of it (the application code, the code that will be read and rewritten much more often) reads clear as day, without sacrificing performance. No, it's probably not the best language it can be, but for creating powerful, ruthlessly efficient, reusable abstractions, I don't see it as having any competition whatsoever.
If other reasons we do lack, we swear no one will die when we attack
You are of-course correct.
On the other hand... On the 5th of October I had a first draft of a design document for a new system, I didn't quite understand yet on my hands. The deployment was scheduled on the 12th of November. The deadline was pushed down onto the development team from the absolute powers above. By the 10th of October I finally had an idea and a first draft of a design document, which actually made some sense. The system was supposed to be 'flexible', 'maintainable' and 'extendable'.
Now, I take those three requirements with a grain of salt, especially given the deadline and the subjective nature of the words like 'extendable'. I didn't have a choice of deadline, I didn't have a choice of functionality but something had to give, so I talked to the manager asking for overtime permission and I got it. From the 10th of October until the 1st of November I put a few hundred hours into the project, by mid-October I had 2 more people start on the project. I kept the back-end framework, another developer kept the front-end framework and the third developer had to translate the business requirements into the framework. We deployed on the 12th, the system is extendable in form or interface implementations and database data setup. The system is fully documented and unit/integration tested (we wrote all of the unit and integration tests, no QA time was allocated except for the very last week before deployment) So we delivered the system by the 12th, the users are happy enough but obviously the next releases had functionality changes. However in the process of delivering this, we sacrificed our lives completely to the project.
After the 12th, some of the new requirement came and we were able to deliver them (tested) within hours, since the original framework is sound.
My thinking is that it always pays to build the project to the best of your abilities and to think of the design, it will pay off at the end,
BUT only do it if you are getting paid for each hour of the work, preferably as a contractor.
Cheers.
You can't handle the truth.
Computer Science is a gigantic field, yet most colleges seem to think they can teach it as one big, coherent major (that usually requires a load of credit hours to complete). My idea for Computer Science curriculum, with reasoning (sorry if this is off-topic):
CS101 (core): Scheme: Basic Algorithms and Data Structures Introduction to computer science. Scheme is a minimalistic language, and is a great one to slowly introduce concepts to a class. The general premise of the language is simple, and easy to teach in stages. It's also an interpreted, declarative language, which will provide a contrast to those learned later on. CS102 (core): RISC Assembly: Advanced Algorithms and Data Structures Introduction to computer programming. Assembly (imperative, hardware-dependant) is as far as you can get from Scheme (declarative, hardware-independant). This exposes students to the far reaches of their discipline, giving them some basic knowledge of what computer science is about. It also allows students to figure out early if they want to stick it out, or go into an engineering major (or business, for that matter). CS103 (elective): Overview of Declarative Languages Prolog, Lisp, etc. Prerequisite: CS101. CS104 (elective): Overview of Imperative Languages C, Java, etc. Prerequisite: CS102. CS201 (core): Products of Software Engineering Overview of the big systems. This class doesn't have a language attached to it because it won't have programming assignments. The idea is to take a look at the four wonders of the programming world: operating systems, database management and other large, integrated systems, compilers and interpreters, and artificial intelligence and expert systems. This is an introduction-type class, presenting the general ideas and concepts present in the major types of software. The field is a large one, and this major is not meant to produce experts at all parts of it. CS202 (core): Practical Software Engineering Team-based programming. This is a project-based class. The purpose of it is to take the class through the process of designing, constructing, and releasing a (small) project. Introduce source control, unit testing, and automation. Language and project up to the professor or (at best) the class itself. Scope must be small enough to complete in one quarter/semester. CS203 (core): Ethics in Computer Science What responsibilities do programmers have? To their clients? To themselves? To the general public? Less of a presentation or prescription than a discussion. Discuss open source/proprietary licenses, military/intelligence software, etc.After sophomore year, all classes are electives (except for one, see below). A student must take so many 3xx level and so many 4xx level to graduate. Choosing an emphasis (on the research - development axis, perhaps) determines the electives, or the student might talk to their adviser and create a custom/general major. Electives at the 300 level include expanded treatment of the topics in CS201 (systems programming and OS development, DBMS and web server development, programming language concepts and development, artificial intelligence and expert system concepts and development), and branch to more specific areas by the 400 level.
The one other required class is a 400 level project class. It is taken independently, with few requirements: student(s) present a proposal to the CS faculty at the beginning of their junior/senior year, who accept or reject it based on its scope and perceived difficulty. Once a proposal is suggested
I [may] disapprove of what you say, but I will defend to the death your right to say it.
While you can bash the tools as much as you want, the point remains that the majority of the fault for bad programs lies with the programmer.
.S files created by your compiler? Do you even know what they are? Could you load an object file into a disassembler?
Just as an adept sculptor can build a beautiful (though somewhat rough) art piece using a chainsaw, so can a good programmer make do in situations where he is forced to use the wrong tool for the job.
Namespaces can be simulated with a good naming convention.
OO can be accomplished in a procedural language.
Technologies can be married together, and even replaced in part with other technologies at a later date (it's called refactoring, folks!)
I currently program exclusively in Java. I learned from the ground up (Analog electronics -> Digital logic -> Machine code & Assembly -> C -> C++ -> other OO languages & scripting languages, AOP etc)
I'd love to have multiple inheritance in Java, but I hate the fact that you can't rebind a reference in C++.
I'd love to have real properties and closures supported by the Java language proper, but I make do with standardized boilerplate code in the meantime.
I love the quick UI building you can do in VB, but I certainly wouldn't want to write business logic with it!
Access is great for building quick and simple systems, and does its job well, but I'm not going to store 10 million records in it!
Nothing beats the speed of a library written in assembler, but I'm certainly not going to write database access code in it!
Perl is a great tool in the right hands. In the wrong hands, it is the worst disaster ever, and the first thing I get rid of when I take over support of a project (except for 10% of the time when the previous programmer was competent).
I've seen horrendous code in every language I've ever encountered, and it's always a result of the programmer not understanding what he's working with. My personal opinion is that you shouldn't be programming unless you understand at least one layer below where you're working.
Do you know how to examine a core dump? How about interpreting a Java HotSpot dump?
Do you understand how the technology you're working with interacts with the operating system?
Do you know how the auto-code generator deep within the script overlay you're using actually works? Have you even once looked at the intermediate output?
How about the
What will you do when something goes wrong with it? Give up?
Do you follow the generally accepted practices used in your domain? Do you even know what they are?
Do you know what domain driven design is?
Do you understand when it's a bad idea to use inheritance? (Answer: most of the time)
I could go on forever. The point is that good programmers find the right tool for the job because they understand how it all works. Hackers do it fast, but forget to make it readable or maintainable. Bad programmers just plain do a bad job and make things shitty for everyone.
I'm not trying to get into a flame war but why should it never return null? Returning null can be a way of saying whatever your function wanted to do couldn't be done. Eg, the function is part of a class factory and the class could not be created with the parameters passed in.
meh
I'm of the school of thought that errors should be represented by exceptions. So, to use your example:
Foo *FooFactory::create() throws(OutOfMemoryException) {
Foo *f = new Foo();
if (f == NULL)
throw OutOfMemoryException();
return f;
}
Now the caller to create() has a guarentee that create() will return a pointer to a Foo, or it won't return at all. It also means you can call multiple functions that throw this exception and do all your out-of-memory handling in one place.
How we know is more important than what we know.
Its a huge, bloated, slow loading, memory hogging pile of crap. Its painfully obvious from trying to use it that the code must be awful, or they endless parade of stupid bugs would actually get fixed.
It's not about languages, it's about people. Sure, C will make you track bits and bytes and jiggle with pointers. Everyone should try that and deal with mysterious crashes, etc. And one day switch to Java and track indices in arrays and null pointers and hash codes. But at the end of the day, it's all about people, not languages. If the people are smart, and if they love the field, they will advance no matter what they're taught at school. Very few are those go that far as to learn every new language, and one day reach the level when they just don't care about the tools they use, and cat get any job done with any language at hand.
So, it's about people. We all make errors, we all over-enginner or under-engineer, we all write too complex code because of design errors. We all learn and advance. And not all of us make the best of choices.
So what? This is not just with programming though. Just programming is the most complex task humans do.
http://www.digitalmars.com/d/
Ok, then please explain why Open Source projects are full of flaws just like commercial products.
There are a multitude of reasons. Some of them:
1. Most open source is written to fulfill the developer's requirements. It may not perform so well for other people's requirements, largely because that's not something the developer has bothered with.
2. Most commercial software is professionally tested. Most open source software is tested by amateurs.
3. Open source software is usually released before its ready in order to attract a wider range of developers. This is often fatal, because the new developers are more concerned about adding nifty new features than fixing the existing flaws. This is what has happened to Firefox, IMO.
If you're having problems reading Bjarne's books, you're simply having probems reading. Or programming. Or both.
Sorry, but they're among the best and clearest programming books around.
no taxation without representation!
That's a stupid progression to take. First of all, they'll likely never use Pascal. It hasn't been used on the Mac in well over a decade. Delphi is basically dead. It really doesn't offer anything over C.
When you get them studying so many languages, they'll never become competent with any of them. You'll end up with a shitty C programmer, a shitty Perl programmer, a shitty Pascal programmer, a shitty Common Lisp programmer, and a shitty Java programmer.
It's better just to stick with C++ and Common Lisp (or Scheme). C++ will give them a real-world language that is suitable for a wide range of embedded to desktop applications, while Common Lisp will expose them to functional programming and other critical concepts missing from C++. So now you end up with a well-rounded student who has had the time to focus only on a small number of languages, thus becoming proficient (hopefully) in both. At that point, they should be able to pick up languages like Java, Objective-C and Python within a day or so.
Open up D so we can use it! What good is making a sane replacement for C++ and then only releasing binaries for a few platforms? We use solaris on ultrasparc, openbsd on amd64 and ultrasparc, and some old IBM junk running AIX. Why don't you want us to use D? What benefit are you getting from turning potential D users and contributers away?
"Following your logic would argue that multiply doesn't mean anything on pointers, so it is okay to make it an overloaded operator to increase the reference count and make a backup of the underlying object in a log file (multiply like rabbits). I think that would be a totally broken use of the multiplication operator myself."
No, folowing my logic would argue that multiply doesn't mean anything on pointers, so it is okay to use the same operator (asterix) in a unary mode to mean "dereference". Thanks, that's a great example of how using the same operator to mean entirely different things can be perfectly reasonable is the right circumstances.
We're not talking about features. We're talking about quality. If business stifles software greatness, the implication is that without the demands of business, you tend to get better quality code. And it isn't the case, so I quesiton the original assertion that business stifles programming greatness.
Where is the software development utopia?
So in this sense, business actually IMPROVES overall quality. This is the opposite of the claim I was responding to.
Firefox seems pretty feature-slim to me. What is included in the base Firefox install that shouldn't be there? Without extensions, it is pretty basic. I guess maybe you could take out the popup blocker. But who DOESN'T want a popup blocker? Spell checker? Don't want spell checking on text inputs?
I think the Firefox team has done a pretty good job of keeping the feature bloat down. One could even argue that FF 2.0 isn't even worthy of a major version jump. Should be FF 1.6.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
I am quite willing to excuse your potty mouth.
However, for "shouting" in upper case and for your use of excessive exclamation marks, you shall surely be darned to heck.
Ahh - My eye!
The doctor said I'm not supposed to get Slashdot in it!
You are completely off-path, young grasshopper. When you get some experience under your wings, you will see that good programmers do indeed have a lot of will both in thinking and writing, but great programmers have that and extensive theoretical knowledge.
You see, the more theory you know, the less figuring-out you have to do on already-beaten footpaths. Then you can expend your precious, priceless, mental power on new problems. Of course, it may happen that you are forced to re-implement a B-tree or a Q-sort function, but if you don't have to think through it's intricacies it's just implementation; if you have to think and then write, you are wasting time and will probably not make it.
This is all a part of the "standing on the shoulder of giants" template. If you ignore or don't know about the concepts, then you try to re-do the work of really clever people that already have ironed out the problem and it's solution.
You're not old until regret takes the place of your dreams.
Hey, any code base that includes a "libpr0n" module can't be all bad.
--- All I ask is a chance to prove that money can't make me happy.
Actually, you want Haskell. Haskell offers arbitrary infix operators. Just enclose any two-argument function in backquotes (`) and it becomes an infix operator. You can also define new operators using any combination of legal symbols.
For example, if you had a function concat a b that concatenated the strings a and b, you could write:
concat 'Hello ' 'World' -- The usual way to call concat
Or you could write:
'Hello ' `concat` 'World' -- the backquotes make concat an infix operator
But best of all you can define the exact operator you want like so:
(.=) :: String -> String -> String .= b = concat a b
a
Now you can write:
'Hello ' .= 'World' -- Voila!
you have to admit, almost everything has been packaged in libraries and stuff already. I also appreciate the nitty-gritty of coding myself, but I find that more and more, it's going to become somewhat irrelevant doing everything all over again. If something's been done already, why re-do it? But yes, in an academic environment this shouldn't be the case. Students should have to get down to understanding it all in detail.
I think the internet ofcourse, fuels the progress (or not) of programming in general. It's like a java class I was in a while ago. One project pupils were asked to do was to make a 'hang-man' game. I thought that would be a real challenge for people...it turns out all it took was less than a minute of googling to get the exact source code from somewhere.
Monty Python, that is. I'll start. Use an abacus? Oo, the luxury. In our days, ...
It must have been quite an experience to be taught C++ by Stroustrup himself! But I imagine he may have spent half his time defending the mechanics of the language versus 'safer' implementations....but on the other hand, he seemed to have been somewhat an open-minded person judging from his interview with TechReview.
No, I'm saying that commercial code quality is poor (mostly) because of business pressure and open source code quality is poor for (mostly) other reasons.
I thought that might be the idea.
My only problem with that is I've always taken exceptions as something to be used when there is a error condition of some sort. Returning null from a function does not necessary imply that there is an error.
For example if you are querying for the existance of something and it doesn't exist, throwing an exception seems like a bad idea. It seems to me if you take the not null returns to its logical conclusion then you end up overusing exceptions.
There are also some people who just flat out dislike exceptions. I'm not one of them, but the view does exist.
meh
N/T
No, it's just that Stroustrup is neither a good programmer nor a good language designer. Imagine trying to design a OO language without garbage collection! What a twat.
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
For those of us working in the "gutters" - embedded systems stuffed into the sometimes gludgy real world - only a language like C++ will do. A polished user-level GUI app running atop layer after layer of abstraction can be written in something slick and aloof like Java, Lisp, or some nifty obscure language. ...but for those of us writing specialized critical apps running on minimal hardware and dealing directly with the real world, we need something that has only the thinnest layer of abstraction, is comprehensible and predictable, and will reliably affect reality.
Sneer at "gutter"s as you like. Your house/apartment has them, your business/school has them, you don't notice them when they work, but they are quietly everpresent and designed by someone who had to think about them and use specialized tools to make them - and life would be less pleasant without them. Ditto for lots of C++ apps. You don't really expect a Java VM running on your toaster, do you?
Can we get a "-1 Wrong" moderation option?
students should really be studying computer science, not programming. They shouldn't learn how to do a binary search, they should learn why it's such a powerful technique. The implementation falls out naturally from the description. Likewise for trees of various flavors. Teach them how to identify the language features that best support the algorithms they need, and let them figure out which language is most appropriate for themselves.
Lisp is incredibly simple, it dumps almost nothing on your poor brain. It only takes a long time to understand how much power the simple language offers you, as you figure out how to use it in new ways.
And saying ML dumps too much on you, and then giving nemerle as an example is just plain retarded. Nemerle has all the same complexities as every other ML implementation, it just has C style syntax. The semantics are all the same, there's just as much to learn, and it all works the same.
Good languages don't get popular because most of the world doesn't want good languages. They want a large pool of replacable, base competance programmers. If you add the good things from good languages into bad languages like C#, they will end up just as complex and just as difficult for the mediocre to grasp as the good languages those features came from.
And of course, why does popularity matter? The grandparent asked for a better alternative to C++. Ocaml is one of many such better alternatives. He didn't ask for an "industry standard", PHB approved alternative.
> Bjarne Stroustrup: Google! Can you even remember the world before Google? (It was only five years ago, after all.)
Does he mean when Google became more publicly known or since they bought Deja.com? Or is he just talking rubbish... I find that hard to believe since its Stroustrup himself.
I for one used Google back in 1999 and I'm sure most other geeks. I remember it totally blew me away compared to the old crappy Altavista.
I'm confused. Are you disputing the existence of hash tables thirty years ago (which would be silly) or that the year 1976 existed at all (which would be slightly sillier)? I suppose that you might be disputing the present existence of people from this long forgotten era, which would be slightly less silly but vastly more insulting. We do in fact exist.
--MarkusQ
P.S. And yes, people really did dress like they show on TV. We thought it was normal then. Don't ask me why.
No answer, huh? Looks like that dude owned you.