It's not the spammers who are really getting hurt here. The collateral damage caused by MAPS' brain-dead sledgehammer approach is not justified.
Hear, hear.
There are numerous problems with the usual RBL approach that are understood in most other contexts:
collective responsibility with people you've never met (if you happen to share the same ISP)
damaging misrepresentation (if the RBL claims you're a spammer because your ISP gets blacklisted and important communications are blocked as a direct result, or through outright damage to your reputation)
failure to provide an adequate means of clearing up a problem caused with good intentions (a common issue with many services, particularly beloved of government departments)
and the list goes on.
I've recently dealt with RBL types twice, in completely separate incidents. My employer's entire network got blocked on one occasion, along with a few thousand others. The original spam was genuine, but when you've got an ISP with 100,000s of subscribers, expecting no-one to ever abuse them by sending spam from their servers is rather optimistic. The best they can realistically do is close down whoever is doing it promptly, and they have to be careful not to be abusive in doing that since damaging an innocent customer faced with a malicious accusation (e.g., someone who sends out a genuinely opt-in mailing list and has the records to prove it) is equally unacceptable.
The other one was even better: my home ISP, a popular and generally fairly sensible lot, got their mail servers blocked. Following the information in the "you've been blocked" bounce message showed that the RBL claimed to have sent notification to the ISP's abuse address some several days before blocking them. Then, of course, "we don't reply to mails sent to this e-mail address" kicked in on both sides. The abuse address auto-replied acknowledging the message and saying it would receive a reply from a real person within five days. This was apparently ignored by the RBL systems, which activated the block sooner than that without further warning. In any case, that was all from the RBL site; the ISP staff claimed they didn't have anything more than about six hours before the block went active and half a million customers started ringing their support lines.
As I see it, there are two morals to this story:
ISPs should be compelled, through regulations that are very expensive to violate, to monitor and act on abuse mails promptly. If an ISP can't afford to take this simple step to protect the on-line world, perhaps it can't afford to be in the business?
RBLs should be compelled to follow-up any reasonable replies to their abuse notifications before instituting a block. Perhaps if they don't have the resources to make sure a complaint is genuine before they act on it, they shouldn't act on it at all?
RBLs should not be allowed to block large numbers of innocent users just to take out small numbers of spammers without providing an adequate means for innocent users to get their systems cleared promptly. If such a simple requirement not to harm innocents is incompatible with the RBL provider's business model, perhaps that business model is inappropriate?
IMHO, all of the above should be subject to sufficiently draconian penalties that staying in the ISP RBL business is outright financially unviable if the rules are repeatedly broken. Stuff not regulating the Internet; this is a simple solution to a major problem that affects everyone using it. When an industry demonstrates clearly that it can't regulate itself effectively and the public suffers as a result, official regulation is required for the good of everyone concerned.
The "negative hype" regarding XP SP2 comes from one source: advocates of other OSes (namely Linux and OSX).
I speak critically of SP2 because I've personally seen it mangle numerous machines. My OS preferences have nothing to do with it: my main home PC is a WinXP box anyway, and I use something like a dozen different OSes routinely at work since I develop cross-platform software for a living.
When it first came out, many sources gave a breakdown that was roughly as follows. Obviously the exact numbers varied depending on whose article you read, and since most of them were based on feedback to "Should you upgrade?" type web pages, the problems are probably significantly inflated.
1/2 installed with no more than minor problems.
1/4 installed with major problems, but were fixable with some work. (This includes the various apps that broke but could be fixed by downloading a patch from the vendor, etc.)
1/4 effectively took out the system permanently, requiring a reinstallation of Windows.
I don't know what the current stats are. However, with my software engineering hat on, if it was ever as bad as that to start with, I'm never installing it on a working system. Given that the experience of family, friends, work colleagues, etc. hasn't been good overall, I'm going with the devil I know.
actually, the only things it allows by default are remote assistance, remote desktop, and file and printer sharing.
So the only things this firewall allows through by default are the tools that allow... wait... yeah, that's it... complete control of your computer! It's genius, with those protocols obviously being completely immune to any sort of malicious attack.
And AU isn't doing them much good anyway, because most patches coming down the pipe depend on SP2 anyway.
No, your first claim there was the FUD. My employer's policy is currently to ban SP2, yet to date, I have installed every other MS update that has been sent out for my WinXP box.
We did back out one change (KB885250) that broke Samba. However, AFAIK that was just a bad update (and an excellent example of why businesses shouldn't automatically install everything that comes down automatically without checking it out first). I suspect that particular update may since have been withdrawn, since WU stopped offering to install it again a few days later, and a known issue (KB895900) is now recorded.
And yes, I expect an airline pilot to know exactly what every damn light on the cockpit panel means. I even expect them to be able to make reasonable guesses as to what most of the diagnostic lights might mean in the engine compartment when the jet is undergoing inspection down on the ground.
This is not unreasonable.
No, it's not. Then again, that pilot is (a) a full-time, highly-trained professional, and (b) directly responsible for the lives of their passengers.
If your Windows XP machine has trouble, everyone on the net pays for your stupidity, just as if your 747 crashes into a populated area.
Analogy failure at line 1.
A closer analogy would be if a car dealer were selling cars with a MTBF of 20 hours, and everyone on the road paid for the resulting accidents. If you're using a shoddy product in a sensitive environment, that's your problem right there. Seeking to repair it every time it goes wrong might mask the symptoms a bit, but it doesn't remove the underlying cause of the danger.
The OSS movement that intends to bring down M-icrosoft will instead be raped by it.
I wish people wouldn't abuse words with such serious connotations, but since it's there: it's not rape if you bend over and ask to be taken hard and fast. If you build a business model around giving your work away for free, don't bitch when someone takes your work and doesn't pay you for it.
It's clearly not - a lot of us earn our livings doing exactly that.
Well, you earn your living doing that. A few guys working on things like Linux distros, OpenOffice.org, etc. also earn their living doing that. Whether a lot of people earn their living doing that is a different question.
Right now, I wouldn't be surprised if any big software corp employed more full-time development staff than all the major FOSS projects put together. So while you certainly can make money writing FOSS, whether it's likely is another matter. For most pros, it will simply be easier to work with the usual closed-source model, whether you're developing products or offering services.
The logical extreme of the "all apps must be as fast as possible" argument is to code in ASM. I suggest that anybody who pushes this argument write every app in ASM.
I'd settle for making them all watch the first couple of lectures from a decent data structures and algorithms course. That alone would shatter the illusions of the McProgrammers who don't understand the different performance characteristics of a list, an array and a map. Just getting that simple choice right would do a lot to fix the pathetically slow code we see everywhere today.
That tells you, at most, what languages people who choose languages think are better (not just fast) for mathematical/scientific/engineering applications. It's not really an objective test of what languages are actually fast.
That's true, of course.
However, you're unlikely ever to get a study that produces the same large-scale, professional-standard development in two different langugages with development teams of controlled experience levels etc., just to see which one works better. The cost overhead would be terrible. The closest approximation I can think of is to consider the view of a whole community with huge amounts of experience and a genuine willingness to try new approaches if they look beneficial. In the absence of one of those, I suggest that the scientific software community is again the closest realistic approximation. Right now, that community is pretty heavily pro-C and C++ (with a bit of FORTRAN, but not much new work in it these days).
This is a pretty heavy chain of assumptions, but what more authoritative study would you suggest, given what's ever likely to happen in practice?
'Ambassador Kosh' certainly isn't the only one to have observed that the C and C++ community tends to measure speed based on microbenchmarks, and not on real-world applications.
On the contrary; in my experience, the low-level guys are happy to take on whatever benchmarks are around. It's the high-level language guys, who are always trying to demonstrate that their pet language is "as fast as C" (or more likely "within a factor of N of the speed of C") that frequently cite microbenchmarks like the Programming Language Shoot Out.
Using mostly (or only) imperative programming techniques seems to be the current favourite tactic here. After all, you can easily show that Language L is comparable in performance to C if you write lots of simple programs using L's imperative features, which probably compile down to pretty much the same machine code as the equivalent C would generate. This conveniently avoids using other features that Language L advocates cite as its big improvements, and thus it also avoids the horrible possibility that they might actually suck when it comes to speed.
IMHO, a much more interesting study that the PLSO is to look at the structure of the high-performing entries in the ICFP competition, where skilled developers are writing non-trivial code in many languages according to their own preferences. The overall results there have been reasonably consistent over the years, and support many held perceptions very strongly: in particular, it really is the algorithm that matters most in practice, and the community's ideas of relative speeds of languages are actually pretty accurate.
Thanks for the link. I think I see where he's coming from now, even if I don't agree with him (for reasons not dissimilar to those in the comments at the end of the page you linked to).
C/C++ show up very fast in these micro optimization benchmarks. However I have not seen them show up that fast on large codebases. Probably because it takes so much time and effort to optimize them.
It sounds like you're basing that purely on your own experience. Perhaps you simply haven't encountered that much C and C++ code, or you know some particularly good Python programmers?
Here's a more objective test for you: which languages underlie the vast majority of high-performance mathematical/scientific/engineering applications developed in the past decade? If you need a clue, look for software developer job ads from scientific companies.;-)
...if I see blocks of code spanning page boundaries I'll start wondering what kind of idiot wrote the code...
Possibly someone who's better informed than you. The idea that a "good" function size is a function that fits on a single screen is a popular one, but rarely backed up by evidence when objective studies are done. See, e.g., Steve McConnell's Code Complete for a fuller survey of the research.
Now try to describe how basic I/O operations work in Haskell to a non-PhD.
I can't see your problem. We just use the normal side-effects to communicate with the outside world, and... Oh, did you say Haskell was lazy? You did? Oh, dear.
Seriously, monads aren't such a difficult concept if you're familiar with the basics of functional programming already. The main argument against them is similar to those often used against "design patterns" for OO languages: they get the job done, but other languages can do it all so much more neatly that they seem like a pointless over-complication to anyone who's used to the languages with native support for the feature. Forcing that level of over-complication to maintain conceptual purity or to permit occasionally elegant techniques like lazy evaluation is fine in academia, but a dead end in the real world.
In fact, any algorithm that you can implement at all using recursion can also be implemented iteratively, assuming we're talking about a sane computation model.
You're right that everything has pros and cons, I just feel that C++'s cons began to outweigh its pros a while back, and it just seems more evident today.
It all depends on your application domain. For applications that are predominantly UI/database driven, as obviously many are, C++ has few advantages over something like Java. However, in anything scientific (where performance is often paramount) or in huge markets like embedded or instrument-control applications (where tight code and/or low-level control are often required), languages like C and C++ are still far ahead of the competition IME. Java is making some inroads into the embedded space, but it's barely a blip in the graph right now.
I'm also extremely unconvinced that any of the languages you mention have less "reasoned design decisions" than C++.
I think that's a little harsh. If there's one thing you can fairly say about C++, it's that Stroustrup and the standards committee take their time and try to reach good, practical decisions. It takes forever to make changes as a result, but with a few exceptions (the designed-by-committee string functionality, for example) the underlying design decisions of C++ are really very robust. Stroustrup's oft-cited book, The Design and Evolution of C++, provides some fascinating insights into how a serious computer scientist designs a language, and the factors that weigh into that decision. Even where I disagree with a decision that's been made, not that that often happens with this particular programming language, I can at least understand the rationale behind the decision.
Compare this with Java's almost amateur development process, and the design weaknesses that have resulted. For ages, the Powers That Be dictated that generics/templates/whatever weren't useful, and wouldn't be included. Lo and behold, a few years later, they concede that they were wrong and retrofit them (but still in a feeble way that misses half the point and 90% of the power). More seriously, although Java has a vast standard library, much of it is a joke compared to the high-quality, often peer-reviewed work found in things like Boost, CPAN, and so on. For example, AWT was so bad they had to invent Swing, and that's still not a patch on serious GUI libraries like Qt or wxWidgets in their various forms.
In fairness, the less formal processes (a.k.a. benevolent dictatorships in most cases) that underlie many scripting languages (notably Perl and Python in relation to the current discussion) tend to be rather more flexible. Even so, how can a language that doesn't even have a specifcation apart from a compiler that its own author couldn't rewrite from scratch possibly be considered to have an industrial-strength design process? (That would be Perl, and indeed the reason for all the completely rewritten underlying mechanics for Perl 6.)
The advantage of these newer languages is that their programming is, in general, more "safe" than predecessors like C++
That is indeed a compelling advantage. C++ has always been written for "good programmers", the craftsmen who take their craft seriously enough to learn the details and avoid the obvious mistakes. Unfortunately most programmers aren't like that, and most companies are going to be employing "most programmers" most of the time. It is therefore a sensible management decision to go with technology that mitigates "most programmer" errors.
The only problem is that sometimes, you actually need finer control (and to accept the attendant risks) in order to get a good result, and if you need to hire some geeks to use that control, so be it. If you have a language that actually won't let them bend or even outright break the rules when they know damn well that it is safe to break them in the particular circumstances they're working under, then that's a serious liability to some kinds of project. If you're going to fall back on linking to C functions, using JNI, or whatever every time you need performance, you might as well write in a language like C++ in the first place, and just hire enough good people to write safe, high-performance wrappers for the low-level code...
Do you have a reference, please? I've seen various excerpts attributed to Guido, but without seeing the context they weren't worth much.
In particular, a simplicity argument in a programming language is compelling, whatever the target market for the language. However, I find it hard to believe that anyone competent enough to design a successful language like Python doesn't appreciate the power of lambda and related concepts.
What is being tested here is how efficiently the language handles recursion.
OK, if that's your take on it, then yes, of course C is "slower" at dealing with recursion than languages designed to pick up lots of optimisations in recursive code. Whether this is actually a useful comparison to do if you're considering which is the more useful programming language is a different question.
Both [quicksort and insertion into a binary tree] are highly sensitive to memory access latency, cache size, caching strategy, etc.
I'm not entirely convinced that's true, unless either you have a language where the implementation of data structures really sucks or you're working with data sets so small that algorithmic performance isn't really an issue. I write high performance mathematical algorithms, many of them operating over very large graph-like data structures, for a living, BTW. I'm more than a little familiar with profiling this type of code and identifying the performance bottlenecks, on something like 20 different compiler/OS/hardware combinations.
In any case, these are considerably more realistic comparisons to make between programming languages, since it's likely that in practice a programmer would actually implement the same basic recursive algorithm in both languages.
But aren't we left with things like list comprehensions instead? I'm not sure that's an improvement: you've removed concepts that are perhaps unfamiliar to many programmers, but powerful once you understand them (a lambda construct, closures, etc.) and replaced them with what are essentially watered-down special cases with some neater (to some eyes, at least) syntactic sugar, but without the underlying power. That might make learning the language easier initially, but it reduces its effectiveness as a serious programming tool.
How is testing say, a recursive-descent parser, going to be a more valid test of recursion than a recursive solution for fibonacci numbers?
Because using recursion to calculate Fibonacci in the obvious way is a hideously inefficient algorithm. In languages designed to support recursive programming styles, such as most functional programming languages, this will be dealt with. In low-level languages like C, it won't, but then in C you would never implement the algorithm that way in the first place. It's not a fair test of the ability to implement a real world algorithm efficiently in different programming languages, which is the only useful metric you're going to get out of that sort of test set-up.
Compare this with a divide-and-conquer algorithm like quicksort, or an algorithm over a recursive data structure like an insertion on a binary tree, where the use of recursion to implement the algorithm is natural and need not introduce these arbitrary overheads.
I don't see how making you put everything in an object makes it any harder to do simple programs.
And therein lies the problem.
Not everything is an object, and there are many powerful design concepts that do not have the word "object" in their names. As other posters have pointed out, if you can't even do simple things simply, you're never going to do complex things even close.
You wrote in your previous post:
just having OO as a new feature, like C++
OO isn't a new feature in C++; it's simply not the only design feature in C++. This is an advantage. Trying to force everything into objects artificially is not.
And from this post:
A class is an object.
Not necessarily. In general classes are types, while objects are instantiations of types. It certainly is possible for classes to be instances of some higher order type themselves, but this is not a necessary requirement to support OO as it's usually defined.
Many programmers like to whip something out now. A quick "one off". Instead, often, with a little more time and more ground work, they can make something that is reusable.
We should change the Fundamental Law of Software Development to "premature attempts at reusability are the root of all evil".
If it takes you five lines of code and seven abstractions just to read a value from an input stream, just because you can then share a couple of those abstractions across different types of value, is that really more readable, maintainable or efficient than simply writing one-liner versions to deal with different input types?
Well, you've repeated the same entire expression twice in just one line of code. Moreover, the syntax contains redundant elements even without that. That's hideously verbose compared to, say,
Slashdot Mirror
Hear, hear.
There are numerous problems with the usual RBL approach that are understood in most other contexts:
- collective responsibility with people you've never met (if you happen to share the same ISP)
- damaging misrepresentation (if the RBL claims you're a spammer because your ISP gets blacklisted and important communications are blocked as a direct result, or through outright damage to your reputation)
- failure to provide an adequate means of clearing up a problem caused with good intentions (a common issue with many services, particularly beloved of government departments)
and the list goes on.I've recently dealt with RBL types twice, in completely separate incidents. My employer's entire network got blocked on one occasion, along with a few thousand others. The original spam was genuine, but when you've got an ISP with 100,000s of subscribers, expecting no-one to ever abuse them by sending spam from their servers is rather optimistic. The best they can realistically do is close down whoever is doing it promptly, and they have to be careful not to be abusive in doing that since damaging an innocent customer faced with a malicious accusation (e.g., someone who sends out a genuinely opt-in mailing list and has the records to prove it) is equally unacceptable.
The other one was even better: my home ISP, a popular and generally fairly sensible lot, got their mail servers blocked. Following the information in the "you've been blocked" bounce message showed that the RBL claimed to have sent notification to the ISP's abuse address some several days before blocking them. Then, of course, "we don't reply to mails sent to this e-mail address" kicked in on both sides. The abuse address auto-replied acknowledging the message and saying it would receive a reply from a real person within five days. This was apparently ignored by the RBL systems, which activated the block sooner than that without further warning. In any case, that was all from the RBL site; the ISP staff claimed they didn't have anything more than about six hours before the block went active and half a million customers started ringing their support lines.
As I see it, there are two morals to this story:
IMHO, all of the above should be subject to sufficiently draconian penalties that staying in the ISP RBL business is outright financially unviable if the rules are repeatedly broken. Stuff not regulating the Internet; this is a simple solution to a major problem that affects everyone using it. When an industry demonstrates clearly that it can't regulate itself effectively and the public suffers as a result, official regulation is required for the good of everyone concerned.
I speak critically of SP2 because I've personally seen it mangle numerous machines. My OS preferences have nothing to do with it: my main home PC is a WinXP box anyway, and I use something like a dozen different OSes routinely at work since I develop cross-platform software for a living.
When it first came out, many sources gave a breakdown that was roughly as follows. Obviously the exact numbers varied depending on whose article you read, and since most of them were based on feedback to "Should you upgrade?" type web pages, the problems are probably significantly inflated.
I don't know what the current stats are. However, with my software engineering hat on, if it was ever as bad as that to start with, I'm never installing it on a working system. Given that the experience of family, friends, work colleagues, etc. hasn't been good overall, I'm going with the devil I know.
So the only things this firewall allows through by default are the tools that allow... wait... yeah, that's it... complete control of your computer! It's genius, with those protocols obviously being completely immune to any sort of malicious attack.
Once OSX what?
Blockquoth the AC:
No, your first claim there was the FUD. My employer's policy is currently to ban SP2, yet to date, I have installed every other MS update that has been sent out for my WinXP box.
We did back out one change (KB885250) that broke Samba. However, AFAIK that was just a bad update (and an excellent example of why businesses shouldn't automatically install everything that comes down automatically without checking it out first). I suspect that particular update may since have been withdrawn, since WU stopped offering to install it again a few days later, and a known issue (KB895900) is now recorded.
No, it's not. Then again, that pilot is (a) a full-time, highly-trained professional, and (b) directly responsible for the lives of their passengers.
Analogy failure at line 1.
A closer analogy would be if a car dealer were selling cars with a MTBF of 20 hours, and everyone on the road paid for the resulting accidents. If you're using a shoddy product in a sensitive environment, that's your problem right there. Seeking to repair it every time it goes wrong might mask the symptoms a bit, but it doesn't remove the underlying cause of the danger.
I wish people wouldn't abuse words with such serious connotations, but since it's there: it's not rape if you bend over and ask to be taken hard and fast. If you build a business model around giving your work away for free, don't bitch when someone takes your work and doesn't pay you for it.
Well, you earn your living doing that. A few guys working on things like Linux distros, OpenOffice.org, etc. also earn their living doing that. Whether a lot of people earn their living doing that is a different question.
Right now, I wouldn't be surprised if any big software corp employed more full-time development staff than all the major FOSS projects put together. So while you certainly can make money writing FOSS, whether it's likely is another matter. For most pros, it will simply be easier to work with the usual closed-source model, whether you're developing products or offering services.
I'd settle for making them all watch the first couple of lectures from a decent data structures and algorithms course. That alone would shatter the illusions of the McProgrammers who don't understand the different performance characteristics of a list, an array and a map. Just getting that simple choice right would do a lot to fix the pathetically slow code we see everywhere today.
That's true, of course.
However, you're unlikely ever to get a study that produces the same large-scale, professional-standard development in two different langugages with development teams of controlled experience levels etc., just to see which one works better. The cost overhead would be terrible. The closest approximation I can think of is to consider the view of a whole community with huge amounts of experience and a genuine willingness to try new approaches if they look beneficial. In the absence of one of those, I suggest that the scientific software community is again the closest realistic approximation. Right now, that community is pretty heavily pro-C and C++ (with a bit of FORTRAN, but not much new work in it these days).
This is a pretty heavy chain of assumptions, but what more authoritative study would you suggest, given what's ever likely to happen in practice?
On the contrary; in my experience, the low-level guys are happy to take on whatever benchmarks are around. It's the high-level language guys, who are always trying to demonstrate that their pet language is "as fast as C" (or more likely "within a factor of N of the speed of C") that frequently cite microbenchmarks like the Programming Language Shoot Out.
Using mostly (or only) imperative programming techniques seems to be the current favourite tactic here. After all, you can easily show that Language L is comparable in performance to C if you write lots of simple programs using L's imperative features, which probably compile down to pretty much the same machine code as the equivalent C would generate. This conveniently avoids using other features that Language L advocates cite as its big improvements, and thus it also avoids the horrible possibility that they might actually suck when it comes to speed.
IMHO, a much more interesting study that the PLSO is to look at the structure of the high-performing entries in the ICFP competition, where skilled developers are writing non-trivial code in many languages according to their own preferences. The overall results there have been reasonably consistent over the years, and support many held perceptions very strongly: in particular, it really is the algorithm that matters most in practice, and the community's ideas of relative speeds of languages are actually pretty accurate.
Thanks for the link. I think I see where he's coming from now, even if I don't agree with him (for reasons not dissimilar to those in the comments at the end of the page you linked to).
It sounds like you're basing that purely on your own experience. Perhaps you simply haven't encountered that much C and C++ code, or you know some particularly good Python programmers?
Here's a more objective test for you: which languages underlie the vast majority of high-performance mathematical/scientific/engineering applications developed in the past decade? If you need a clue, look for software developer job ads from scientific companies. ;-)
Possibly someone who's better informed than you. The idea that a "good" function size is a function that fits on a single screen is a popular one, but rarely backed up by evidence when objective studies are done. See, e.g., Steve McConnell's Code Complete for a fuller survey of the research.
I can't see your problem. We just use the normal side-effects to communicate with the outside world, and... Oh, did you say Haskell was lazy? You did? Oh, dear.
Seriously, monads aren't such a difficult concept if you're familiar with the basics of functional programming already. The main argument against them is similar to those often used against "design patterns" for OO languages: they get the job done, but other languages can do it all so much more neatly that they seem like a pointless over-complication to anyone who's used to the languages with native support for the feature. Forcing that level of over-complication to maintain conceptual purity or to permit occasionally elegant techniques like lazy evaluation is fine in academia, but a dead end in the real world.
In fact, any algorithm that you can implement at all using recursion can also be implemented iteratively, assuming we're talking about a sane computation model.
It all depends on your application domain. For applications that are predominantly UI/database driven, as obviously many are, C++ has few advantages over something like Java. However, in anything scientific (where performance is often paramount) or in huge markets like embedded or instrument-control applications (where tight code and/or low-level control are often required), languages like C and C++ are still far ahead of the competition IME. Java is making some inroads into the embedded space, but it's barely a blip in the graph right now.
I think that's a little harsh. If there's one thing you can fairly say about C++, it's that Stroustrup and the standards committee take their time and try to reach good, practical decisions. It takes forever to make changes as a result, but with a few exceptions (the designed-by-committee string functionality, for example) the underlying design decisions of C++ are really very robust. Stroustrup's oft-cited book, The Design and Evolution of C++, provides some fascinating insights into how a serious computer scientist designs a language, and the factors that weigh into that decision. Even where I disagree with a decision that's been made, not that that often happens with this particular programming language, I can at least understand the rationale behind the decision.
Compare this with Java's almost amateur development process, and the design weaknesses that have resulted. For ages, the Powers That Be dictated that generics/templates/whatever weren't useful, and wouldn't be included. Lo and behold, a few years later, they concede that they were wrong and retrofit them (but still in a feeble way that misses half the point and 90% of the power). More seriously, although Java has a vast standard library, much of it is a joke compared to the high-quality, often peer-reviewed work found in things like Boost, CPAN, and so on. For example, AWT was so bad they had to invent Swing, and that's still not a patch on serious GUI libraries like Qt or wxWidgets in their various forms.
In fairness, the less formal processes (a.k.a. benevolent dictatorships in most cases) that underlie many scripting languages (notably Perl and Python in relation to the current discussion) tend to be rather more flexible. Even so, how can a language that doesn't even have a specifcation apart from a compiler that its own author couldn't rewrite from scratch possibly be considered to have an industrial-strength design process? (That would be Perl, and indeed the reason for all the completely rewritten underlying mechanics for Perl 6.)
That is indeed a compelling advantage. C++ has always been written for "good programmers", the craftsmen who take their craft seriously enough to learn the details and avoid the obvious mistakes. Unfortunately most programmers aren't like that, and most companies are going to be employing "most programmers" most of the time. It is therefore a sensible management decision to go with technology that mitigates "most programmer" errors.
The only problem is that sometimes, you actually need finer control (and to accept the attendant risks) in order to get a good result, and if you need to hire some geeks to use that control, so be it. If you have a language that actually won't let them bend or even outright break the rules when they know damn well that it is safe to break them in the particular circumstances they're working under, then that's a serious liability to some kinds of project. If you're going to fall back on linking to C functions, using JNI, or whatever every time you need performance, you might as well write in a language like C++ in the first place, and just hire enough good people to write safe, high-performance wrappers for the low-level code...
Do you have a reference, please? I've seen various excerpts attributed to Guido, but without seeing the context they weren't worth much.
In particular, a simplicity argument in a programming language is compelling, whatever the target market for the language. However, I find it hard to believe that anyone competent enough to design a successful language like Python doesn't appreciate the power of lambda and related concepts.
OK, if that's your take on it, then yes, of course C is "slower" at dealing with recursion than languages designed to pick up lots of optimisations in recursive code. Whether this is actually a useful comparison to do if you're considering which is the more useful programming language is a different question.
I'm not entirely convinced that's true, unless either you have a language where the implementation of data structures really sucks or you're working with data sets so small that algorithmic performance isn't really an issue. I write high performance mathematical algorithms, many of them operating over very large graph-like data structures, for a living, BTW. I'm more than a little familiar with profiling this type of code and identifying the performance bottlenecks, on something like 20 different compiler/OS/hardware combinations.
In any case, these are considerably more realistic comparisons to make between programming languages, since it's likely that in practice a programmer would actually implement the same basic recursive algorithm in both languages.
But what if, as is often the case, reading a value from an input stream is all I want to do?
But aren't we left with things like list comprehensions instead? I'm not sure that's an improvement: you've removed concepts that are perhaps unfamiliar to many programmers, but powerful once you understand them (a lambda construct, closures, etc.) and replaced them with what are essentially watered-down special cases with some neater (to some eyes, at least) syntactic sugar, but without the underlying power. That might make learning the language easier initially, but it reduces its effectiveness as a serious programming tool.
Because using recursion to calculate Fibonacci in the obvious way is a hideously inefficient algorithm. In languages designed to support recursive programming styles, such as most functional programming languages, this will be dealt with. In low-level languages like C, it won't, but then in C you would never implement the algorithm that way in the first place. It's not a fair test of the ability to implement a real world algorithm efficiently in different programming languages, which is the only useful metric you're going to get out of that sort of test set-up.
Compare this with a divide-and-conquer algorithm like quicksort, or an algorithm over a recursive data structure like an insertion on a binary tree, where the use of recursion to implement the algorithm is natural and need not introduce these arbitrary overheads.
And therein lies the problem.
Not everything is an object, and there are many powerful design concepts that do not have the word "object" in their names. As other posters have pointed out, if you can't even do simple things simply, you're never going to do complex things even close.
You wrote in your previous post:
OO isn't a new feature in C++; it's simply not the only design feature in C++. This is an advantage. Trying to force everything into objects artificially is not.
And from this post:
Not necessarily. In general classes are types, while objects are instantiations of types. It certainly is possible for classes to be instances of some higher order type themselves, but this is not a necessary requirement to support OO as it's usually defined.
We should change the Fundamental Law of Software Development to "premature attempts at reusability are the root of all evil".
If it takes you five lines of code and seven abstractions just to read a value from an input stream, just because you can then share a couple of those abstractions across different types of value, is that really more readable, maintainable or efficient than simply writing one-liner versions to deal with different input types?
Well, you've repeated the same entire expression twice in just one line of code. Moreover, the syntax contains redundant elements even without that. That's hideously verbose compared to, say,
or any number of similarly concise and more readable variations in other languages.
Really, if you're going to support Java, you shouldn't have argued in favour of one of its worst attributes! :-p