A programmer that understands assembler and understands how the cpu works will always have a competative advantage to one that doesn't in any language.
Can you give me an example of the benefits such knowledge has when programming in a high level language such as, say, Python or Ruby? I can't think of any significant benefits, but perhaps you can?
First, I'd like to express thanks at what has become a rather pleasent and certainly very interesting discussion. To my mind, arguments are only useful if you learn something from them.
My assertion was simply that C++ is more powerful than most people expect.
I agree with you here. I'll also look into templates a little further; I confess there are probably parts of templating of which I am entirely ignorant. With regards to Boost:Lambda, I was rather impressed. The implementation is a little clunky, and limited to expressions rather than full closures, but it's remarkedly neat and clever for what it does. I rather suspect that macros are used exensively and to rather good effect.
Maybe I don't get it, but until someone hits me with a brick until I do, I can't really comment. I don't know what runtime metaprogramming actually is, in any useful sense.
As far as partial functions and higher level functions, those are easily faked in C++ through overloadings of the call operator (for example, functors.)
Functors do replicate the functionality somewhat, but can be rather unwieldly to create in comparison. The complexity only increases with functors when you deal with creating classes (or a good impersonation of), rather than functions. I can't, off the top of my head, think of a very neat way of injecting default values into a class (rather than an object) via a function.
I don't really count myself as knowing Python. A quick google search on python "class constructor" "object initializer" returns only one result, and that result isn't particularly useful. What would you suggest is the difference between the two?
Your search was fruitless probably because I'm ignorant of the exact technical names. The theory, though is rather simple. In Python, the constructor returns an object (which is almost always an instant of the containing class), whilst the initializer is applied to an object the moment after it is created. An example is probably the best way to convey the difference. Take the following code:
fb = Foobar("test")
In code not dissimilar to C++, this is Python code that constructs a new object from the class Foobar. If we expand this code out, the difference between the constructor and the initializer should become obvious:
fb = Foobar.__new__("test") fb.__init__("test")
The __new__ method is the constructor. The __init__ method is the initialiser. __new__ is applied before the object is created, and __init__ is applied directly after. Both receive the same arguments. I prefer this method, because it clearly differentiates between creating a new object, and setting the default values.
I confess that I know more about constructors in Java than I do constructors in C++. In the JVM based language Nice, the very subject of constructors verus initializers comes up in the Wiki. To quote the relevant parts:
One thing that might be wrong about Java constructors is that they serve two purposes. One is to assign values to the fields of the class. The other is to do any operation that needs to be done when an object is constructed. Let's call the first aspect construction, and the second initialization (are there clearer names, or are those clear?).
The problem with mixing these two purposes arises when you start calling methods from the constructor, before the fields are set. In other words, from a Design by Contract point of view, if you call a method before the invariant is valid. This means that the method called cannot assume the invariant is true. Worse, that method can call others.
There was a better article on this, which went into specific details of why the Java constructor was flawed, but I can't for the life of me find it. Thus, in absence of such fi
The first mistake: Confusing "compile" performance with execution performance. The job of maping C/C++ code to machine code is trivial.
I've designed compilers before, and I wouldn't class constructing a C/C++ compiler as "trivial":)
If computer science isn't about computers, what is it about? I haate that students coming out of universities, when asked about registers and how would they write a multiply routine if they only had shifts and adds, ask "why do I need to know this?"
One could also make the opposite argument. Many computer courses teach languages such as C++, C# and Java, which all have connections to low level code. C# has its pointers and gotos, Java has its primatives, C++ has all of the above. There aren't many courses that focus more heavily on highly abstracted languages, such as Lisp.
And I think this is more important, really. Sure, there are many benefits to knowing the low level details of the system you're programming on; but its not essential to know, whilst it is essential to understand how to approach a programming problem. I'm not saying that an understanding of low level computational operations isn't important, merely that it is more important to know the abstract generalities.
Or, to put it another way, knowing how a computer works is not the same as knowing how to program effectively. At best, it's a subset of a wider field. At worst, it's something that is largely irrelevant to a growing number of programmers. I went to a University that dealt quite extensively with low level hardware and networking, and a significant proportion of the marks of my first year came from coding assembly and C for 680008 processors. Despite this, I can't think of many benefits such knowledge has when, say, designing a web application on Ruby on Rails. Perhaps you can suggest some?
Software sucks today because software engineers don't understand computers, and that's why languages and environments like Java and.NET will make software worse.
I disagree. I think software sucks because software engineers don't understand programming
I just don't agree. C++'s syntax is so powerful that many major language features have been implemented directly in native syntax, something I've never seen in any other language except Lisp and Lisp descendants, including aspects, properties, the lambda calculus, closures, compile-time metaprogramming, coroutines, inline lexing, message-based concurrency and so on.
I assume you're including the functionality of specialist preprocessors in that list, but even so you have listed a few items of which I was previously unaware. A quick Google search for lambda expressions in C++ brings up preprocessors such as Clamp, which seem rather interesting indeed.
That said, I have to be careful here. A while ago, I pointed out that one of the advantages of Python over Java was its mutable classes (which could also potentially be a disadvantage as well, but I digress). The person I was discussing this pointed out this wasn't the case, informing me that one could dynamically alter a class at runtime by altering the JVM bytecode. Whilst this was technically true, there's a large difference in practicality between a single line of "Foobar.new_method = method_impl", and a page of Java code manipulating the bytecode of a class.
I'm interested in the compile-time metaprogramming you mention. Perhaps you could point me toward some resources? I'm aware of the capabilities of templates, but like Java bytecode manipulation, more complex stunts tend to get complicated. Do you know of many more preprocessors like Clamp? I'm something of a language nut, and learning something new about a language I thought I was reasonably familiar with is always very interesting.
That all said, I still disagree with your assertion. Runtime metaprogramming can be very useful, especially with higher level functions (or partial functions, as some people apparently refer to them). Brevity is another advantage; languages such as Python and Ruby tend to be very concise and informatically compact. C++, in my experience, is verbose and frequently deals with information that is beyond the scope of the problem. Or, to put it another way, if I were to translate a function from Python to C++, I'd have more things to worry about.
I also don't see anything on your list which Ruby cannot handle (or indeed Python, with the exception of anonymous closures and coroutines, the latter of which will only appear in Python 2.5).
Er. How many times have you actually replaced a rapid-development web toolkit with a fully statically compiled application? I don't mean to seem rude, but this is experience that almost nobody has in the first place.
No times, I'm afraid. I thought you were speaking more generally. I have translated C++-based programs into equivalent Python-based programs.
C++ wielded properly is stricter than any language you've yet named.
How so?
C++ is a remarkably strict language; that's why we have things like explicit constructors.
That's reminded me of another thing I prefer about Python. The concepts of class constructors and object initializers are seperate, whilst in languages like Java, and I believe C++, the concepts are (to my mind) messily intertwined.
Nonetheless, at no point in the parent message did I say "C++ is the only language that would give these benefits." I just used it as an example of possible benefits above and beyond Rails, because C++ is the lingua franca of programming, so it's a good language to make explanations that reach a lot of people at once. I'm not sure why you're trying to turn this into a Java argument.
You did avocate writing a web application in C++, though. Java's the usual choice for such things, so I was merely wondering why you chose C++ over Java. However, this was adequately answered in your third sentence:
Try writing a large-scale web application in C++ sometime. Sure, it takes a while to nail down some simple text parsing stuff, but the long term maintainability makes most other languages look positively silly by comparison.
What advantage does C++ have over, say, Java for programming web applications in? The only benefits I can think of is improved efficiency (which isn't necessary for the vast majority of websites), and some additional language constructs such as operator overloading. Neither of these would be sufficient enough to entice me to use C++ for such a use, so I was wondering why you find it so attractive.
The other difficulty I have with C++ is that it's not particularly powerful, in terms of syntax and control structures, as some other languages, such as Python or Ruby. When you don't particularly need the efficiency that C++ offers, why favour a more syntaxically restrictive language?
It's remarkable how many bugs disappear with real, strictly compiled languages.
In my experience, very few bugs disappear. However, if you find that this is the case, why use dynamically typed languages such as PHP and Erlang? And there are surely languages that have stricter rulesets than C++; Eiffel, for instance, which is compiled, and strongly and statically typed, with design-by-contract built in. Or the JVM-based Nice, which again is strongly and statically typed, with optional preconditions and postconditions. C++'s weak static typing looks somewhat ineffectual by comparison.
The biggest problem is there is buy in by PROGRAMMERS (the professionals who are suppossed to know better) that the TOOL MATTERS.
This is simply not true.
I've read your post several times, and I'm unsure quite what you mean. To what extent do you think tools do not matter? For instance, is it your assertion that there is no benefit to designing a website with RoR over programming it in assembly? Does it matter how large the program is? Or are you claiming that tools don't matter at all?
Study after study has shown that when talking about anything that matters (does the delivered solution resolve the problem, is the cost of delivery of a working solution in line with the intial budget estimate, TOC, etc.) the tool is irrelivant to the discussion.
You haven't referenced any sources to support this sentence. What studies, exactly?
Ruby on Rails is not designed for the software engineer. It's designed for the Glue Master who wants/needs an application developed as quickly as possible with as much power as possible. The applications are "quick and dirty" one-offs that will be "refined" by being rewritten...
... PHP/Python/VB is not designed for the software engineer. It's designed for the programmer who wants/needs an application that is maintainable and will last longer than a RonR app - but is is not going to last indefinately.
You don't appear to have much experience with Ruby on Rails, if you consider it less maintainable and more "quick and dirty" than an application developed in PHP. Rarely is it a good idea to start an argument from a position of ignorance. A good engineer, software or otherwise, should know this.
I would invest time and money in Ruby on Rails, except that it is obviously a passing fad. This is because Rails is designed to solve a specific problem (serving web pages), and we know for sure that the serving web pages won't be a problem for all time.
This is one of the strangest reasons I've ever heard for not learning Ruby on Rails. Whilst the web may eventually be replaced by another system, I see no indication that this will happen any time soon. Certainly a number of firms believe it will be around long enough to invest heavily in web-based applications.
And surely your argument applies to any technology. Any library, language or framework can become obsolete. Would you advocate not learning at all, for fear that any knowledge learned becomes passe and useless?
Firefox actually has a worse adblock implementation then Opera, did you know that?
Is there an equivalent system to Filterset.G in Opera? It doesn't matter how technically sophisticated Opera's adblocking system is, if you have to manually configure it, and manually update it, it's not as convenient as Adblock + Filterset.G under Firefox.
Unless you are implying that Ruby developers are superhumans that never commit mistakes, I think you should review your opinions.
Firstly, Ruby has class permissions the same as Java. This isn't anything to do with Ruby.
Secondly, there are mistakes, and there are mistakes. If I decided to stick a electrical cable in my mouth without checking if it's live or not, then I suspect people wouldn't go around saying, "Well, he's only human". Instead, I rather suspect they'd say, "What a moron!", and rightly so. Likewise, if a programmer ignores a big fat warning and attempts to overload an undocumented, internal method of some hidden class, then they shouldn't be surprised if they screw something up.
Screwing around with undocumented internal functions is not something any experienced programmer would do lightly. Nor is it really something you can do by accident. You have to deliberately set out to screw with the internals, and if you don't know the problems that could result in, then quite frankly you deserve what's coming to you.
Accidents happen. Thank God you don't work in civil construction:
"What? Using these security equipments, what for? If you think your workers are so dumb to fall off the window of the 3rd floor or let a brick fall on their heads then your problems are so widespread a simple rope and a helmet won't help".
That's not a very accurate analogy. A better one would be, "Should we plaster this support pillar with warning signs saying 'Do not destroy', and trust our workers not to take a jackhammer to it, or should we construct an elaborate cage around it to prevent any mishaps?". In construction, warning signs are used more often than physical barriers, since the construction firms expect their employees to have some idea about workplace safety. I see no reason why software development should be any different.
People want to hire individuals that KNOW THE TECHNOLOGY they are supposed to use, not to learn as they use. In what planet do you live?
Not all firms take this approach. I once had a job offer from a company who worked mainly with C#, a language which I had no prior experience in. The difficulty was not learning C#, but learning the architecture and internal APIs of the large software package they sold. They presumably knew this, otherwise they wouldn't have offered me the job.
BTW, you are considering only the language. Using a platform for development is not only that! It's about learning the platform, the libraries, the paradigms, and it takes time in order for a person to produce good code in that, i.e., code without duplication from the libraries, code using paradigms correctly, code taking advantage of the features.
Paradigms and patterns are often cross-language. Syntax usually has a lot of overlap with existing languages.
You are right, however, with your mention of libraries. But if you stop and think about it, programmers don't need to know that much about the standard libraries of a programming language to code effectively. For instance, I've worked with Python for a long time. But if you asked me to name all the modules in the standard library, I could only manage about six, and I'd be able to tell you even less about the functions in those libraries. I have a similar experience with Java; I can recall only a dozen standard classes off the top of my head.
But the thing is, I don't need to know the specifics. All I need to know is general capabilities. If I know that Java, or Python, has a regular expression library, then the documentation is a two second Google away. I don't need to know the details of the library; I just need to know what to search for. This reduces the task considerably, not only because the problem is now abstracted, but also because there's a lot of overlap between standard libraries, much as there is with syntax. Most languages nowadays, for instance, include regular expressions as standard.
Because you might work in the same company as this other person works, or even worse, in the same team, and if he screws up you get screwed too?
Someone with that level of incompetance would find a way to screw things up even with strict class permissions. I'd also be leery about working for a company who would employ people without a technical interview to determine if they knew what they were doing.
Security is never enough.
Sure, for untrusted users. But if you consider the programmers in your team to be incompetant enough to screw up that badly, then I'd contend your problems are too widespread to be solved by class permissions.
Have you realized that we are also users? We use other people's code everyday, in tools, in libraries, in frameworks. We need protection in the code too, from other users.
Again, if you have an imbecile hiding somewhere in the chain of development, class permissions aren't going to solve much. If you're using a piece of third-party software, be it a library, framework or whatever, you place a degree of trust in the developers not to have completely FUBARed the code. If you don't trust them, or have reason to suspect that the software was developed by people with a room temperature IQ, then why on earth are you using the software in the first place?
Class permissions are not adequate protection from incompetant developers. To believe otherwise is to give yourself a false sense of security.
Yes, there is. Easy replacement of employees if needed is one example. Tools, libraries, support, evolution are others.
Easy replacement of employees? As I said before, any skilled developer will be able to pick up a language in a far shorter time than they could get to grips with any reasonably complex software product. Also, those developers who are familiar with less popular languages, tend also to be some of the most competant. You don't learn Ruby to improve your prospects of employment; you do it because you enjoy programming for the sake of programming.
As for tools and libraries, if the language you use has all the necessary tools for the product you're developing, then Java has no inherent advantage. Indeed, once one moves away from Java, it's limitations rapidly become apparent. Contrast Java's Hibernate with Python's SQLObject. If you need to handle large volumes of database queries, then Hibernate's clustering and efficienty ORM mappings become rather essential. But if you aren't dealing with that level of traffic, then the less CPU efficient, but far more concise SQLObject starts to look terribly tempting.
This isn't just a problem with a specific library. Java can't emulate SQLObject in any meaningful way, as it lacks the syntax capabilities to do so. Thus, in some respects, other languages can offer better libraries than Java, as they're not subject to the same restrictions.
That may be, at your home as a hobby, but it's not always feasible in real world, especially when some pressing bug occurs and it must be fixed yesterday. Would you like to hunt it in an environment you know or in a complete alien one?
Besides, ALL developers are supposed to know it, at least in the same team, in case of vacation, days off, sick days, etc. It's not so simple.
You have that problem whatever language is used. If only one programmer is working on a large, critical piece of software, then you're clearly going to have problems if they bugger off. That's why you ensure beforehand that other developers have the necessary knowledge about the system to fix any problems, or to continue work after the main developer leaves.
Yes, there's a need beyond documentation. You can't guarantee who will work with your software and ANYTHING may happen
Sure, and why should that be a problem? Once my library is in the hands of a developer, what he does with it is completely up to him. If he attempts to extend an undocumented internal function, what happens is not my problem. Warrenty void if opened.
ignoring that is like saying "Ok, let's not use encryption, transmit it in plain text because a bad person would always find ways of cracking it" or "Ok, let's not lock the house door because a thief would always find a way in" or "Firewall? What for? A hacker would always find a way of breaking into your system".
Of course it isn't. The examples you give deal with protecting data and hardware from other users. Class permissions are designed to protect the developer from themselves. I'm of the opinion that programmers should be given more than enough rope to hang themselves with; you never know when those extra feet of rope could come in handy.
You may argue that one is "better" than the other in a given task, but that alone is not enough to use it.
You've lost me. If a language is clearly more suited to a particular task than another, surely that's reason enough to use it?
It's good to keep to a minimum the number of languages inside of a company, but why? Because they are all "lame developers"? NO, BECAUSE IT'S EASIER TO REPLACE DEVELOPERS THEN.
A significant proportion, perhaps even the majority, of software companies specialise either on a single product, or on an set of similar products. In such cases, there isn't so much of an advantage to using a "Jack of all trades" language such as Java.
Besides, any new developer will likely as not have to get to grips with the company's software and internal libraries anyway. For an experienced programmer (and would you want to hire any other kind?), learning a new programming language is trivial in comparison. There's much more overlap between programming languages than there is between libraries and frameworks; it's just a case of mapping familiar constructs to a new syntax.
What if your developer found a new opportunity somewhere else and you need to replace him? Would it be better if he used 8 different languages depending on the case or if he used only one? This kind of thinking of yours only proves that Ruby developers, and opensource developers in general, always miss the BIG PICTURE.
So long as the languages are chosen wisely, I fail to see the problem. As I pointed out earlier, learning a new language is trivial compared to trying to understand the source code and architecture of a complex application you yourself have not worked on before, even with extensive documentation.
Realistically though, I can't see a business needing eight different languages. I've never found myself using much more than three regularly.
You forgot to mention Unicode support, internationalization and decent documentation that are expected even in the smallest projects.
That's why I prefer Python, myself;)
It's not difficult to see idiotic over-generalizations around like "RoR is better than the whole Java", or "Java is dead". Sorry, but Ruby isn't better than Java, not today.
Gah! You decry over-generalisations, then make one of your own!
I have some experience with scripting languages and would like to protest against the notion that "less lines of code = better". So did the Perl developers always get it right? Taking every possible shortcut in order to make the code smaller?
To an extent, you're correct. A one line hack in Perl is often not maintainable in the future.
But you're only addressing part of what I wrote. I said, "You can often do more in a shorter space of time, and in a smaller amount of code". Both parts of the sentence are important. Code in Ruby is not concise in the same way a one liner of Perl is concise. For instance:
class Folder < ActiveRecord::Base
acts_as_tree
has_many:files end
The above code is concise, yet understandable. You can see that this is an ActiveRecord called Folder, which acts as a tree, and that each Folder has many files.
Incidentally, this concise readbility is made possible only through Ruby's support of mutable classes. The two functions, acts_as_tree and has_many, alter the class that they exist in. Incidentally, because Java cannot easily alter class behaviour, so this technique is beyond Java's capabilities. This means that often, Ruby can be more readable than the equivalent Java code.
The most absurd things I have heard lately from such people is "deprecate final" or "everything should be open because the developer knows what he is doing" or some other security stupidity.
This is largely unrelated to Ruby, as Ruby supports class permissions. However, I disagree with you about this. If a developer wishes to shoot his foot off, let him. So long as you make it clear in your documentation that overloading this particular function is not something that should be done, there's no need to go any further. A stupid developer will always find ways to break things; there's no point in nannying the programmer.
We don't need only a "featureset", we need to the complete package (language, tools, IDE, libraries, technologies), and Java does it. Java is not good because "it's the best language with the best features" but because it provides a good balance of good stuff in ALL THOSE AREAS.
A good balance? I don't understand your argument. Okay, sure, if you had a choice of one language, and one language only, to use for every project from now 'till doomsday, then Java might be your man. But individually, some programming projects are rather specific. You don't need a "good balance" of features and libraries; you need the features and libraries that are best for that particular job. Sometimes Java will fulfil that need best, and sometimes other languages will.
You said it yourself: 'Java is not good because "it's the best language with the best features"'. Follow that chain of logic forward and you'll come to the conclusion that Java is not the best language for every possible problem. Nor, for that matter, is Ruby, or Python, or Scheme, or Haskell, or whatever else you might happen to come across. Your choice of language should be dictated by the problem you face.
Also, if you're so stuck on libraries, then a JVM-based language such as Nice might be just up your street.
That's because you are ignoring what most people choose to ignore in such comparisons. For developing software you way more than just the language! You need tools, libraries, opensource software, etc and Java has them in a much more quantity (and quality) than Ruby.
Obviously. I program in Java for a living. I'm quite aware of amount and quality of libraries available for Java.
However, in terms of general web development, Ruby's featureset is fairly complete. There isn't much it lacks. I mean, sure, if you want a complete business solution that involves messaging, job scheduling, customisable rulesets, clustering and goodness knows what else, then Java's probably the better choice. But if you just want a web framework with ORM, templating system, unit testing, AJAX integration and search engine, then Ruby has it covered.
And once you start to develop custom code, Ruby's featureset is its advantage. You can often do more in a shorter space of time, and in a smaller amount of code, in Ruby than in Java. Indeed, some programming techniques are so cumbersome in Java, that it's rarely advantageous to go near them; JIT class construction, for instance. In Ruby, many of these techniques are standard ammunition in the programmer's arsenal.
BTW, Ruby is older than Java, isn't it curious how Java developed itself and Ruby didn't?
Not really. Java had a multibillion dollar corporation pushing it. That often helps.
There are other reasons. To get the most out of Ruby, you need to understand the more exotic concepts available in it. This requires a certain level of skill that may not be available to every programmer. In which case, many of the advantages to using Ruby over Java are lost.
Virtual machine dfficiency, familiarity and product visibility all also play a part in Java's success.
Since the claim that "it's better than Java" was made by him, the obligation of proving it belongs to him. Otherwise my assumption holds true since the use of Java is widespread and no company would use it if it were bad.
That's not quite what I asked. As a presumably experienced programmer, you will doubtless know that some languages are more suitable for some tasks than others. One would not construct a web application in assembly, for instance.
The claim that "Ruby is not a match for Java" reeks of generalities. Ruby is clearly a rather different language to Java, and has disadvantages and advantages to use. The most obvious disadvantage of Ruby is that it's slow. An advantage is that Ruby is a syntaxically more flexible and concise language than Java. The list goes on. To claim that Java exceeds Ruby under all circumstances, which is what your original quote appears to suggest, seems patently false.
Every text editor I know and use can match braces. Where does this block end? By clicking one or two keys I immediately know. I have no idea (and I really don't want to know) how do you match a generic "end" with the corresponding block opener in Ruby.
Why would you need to? Your methods should be short enough to tell at a glance where the end is. Any class or module of sufficient length should live in their own file. This isn't C. A method in Python or Ruby that has a dozen lines is approaching the limit of acceptable length. If your methods span pages and pages, you're simply not programming very well.
C and Perl are for professional programmers. Ruby and Python are for people who need to write short programs from time to time, better than VB, of course, but no substitute for professional quality tools.
Frankly, you don't have the experience necessary to make such an assertion. Your uninformed opinions make you sound like an idiot. Before you criticise something, ensure you understand it well beforehand. Ignorance is rarely a good position to start an argument from.
Insightful? Good god. Opera may well be closed source but it's a far better browser than Firefox
Surely this is a personal point of view? You might very well argue that Opera is better programmed, or more efficient, or does a better job of rendering pages, but just "better" is a subjective assertion.
I'm impressed with Opera, but until it supports the same level of extensions, I personally wouldn't class it as "better" (as otherwise, I'd be using it!)
I often find it helpful to read and understand a person's post before replying to it. Obviously, you don't adhere to this particular philosophy.
If you had read my post, you'd discover that I did not once refer to the performance of Rails as "impressive". Indeed, I did not mention the word even once. Instead, I said, "I consider half a dozen machines to be a fairly modest hardware requirement for handling such large volumes of traffic." This is quite different from the statement you appear to think I said.
In my previous post, I merely pointed out that for a website that handles several million potential customers a day, six servers is a modest requirement to keep everything running, both financially, and in terms of support.
Further, your figures are idiotic. In March this year, Google handled around 91 million searches a day. That's around 1000 searches per second. Why, that's not even 10% of the capacity of your one hypothetical machine, and Google have over 200'000 servers. 10'000 request per second might be more realistic if one was only serving static content, but hardware requirements rapidly increase once you start to factor in dynamic content, such as is produced by RoR.
I, btw, question your claim that ruby can maintain "several million hits per day" (or did you mean cache hits?) on "modest" hardware.
According to Wikipedia, Penny Arcade handles 2 million page requests daily with Ruby on Rails. On the forums there, it's been mentioned that Penny Arcade runs off a cluster of 5 machines.
If Penny Arcade's content is too static for your tastes, then the Robot Co-op family of sites, which consists largely of AJAX web applications such as 43places, manages 2.5 million daily page requests with 6 machines.
I consider half a dozen machines to be a fairly modest hardware requirement for handling such large volumes of traffic. You may disagree.
Sorry but it's a bit naive to assume that hardware can simply be replaced every two years.
You misunderstand me. What I'm saying is that, in general, the average increase of CPU requirements for server applications is likely less than a 100% increase every two years. Given this initial premise, the logical conclusion is that, in overall, the number of server applications that use Java will tend toward an increase, and correspondingly, the number of C++ server applications will decrease.
Obviously most server-side systems last for longer than two years, but what matters is the rate of increase. For instance, if the average lifespan of a C++ server system is ten years, then unless resource requirements have increase a thousandfold in that time, then it makes more sense for the replacement to be programmed in Java (or Python, or Ruby), than in C++.
I have first hand expirience that sloppy programming does indeed almost always imply the other two.
Most of the time, I'll agree with that. My point was more that inefficient programs (in terms of computer resources being used) does not imply sloppy coding, nor an unscalable system. A program need only perform up to spec with the resources it has; efficiency gains beyond that point will be increasingly less useful and more costly.
Well, that's a common myth which holds true for small to medium installations but kicks back horribly in larger
setups (>20 machines). Rackspace and power are cheap but not free. Maintenance overhead is expensive.
Which is why Google use C++ for their performance intensive systems, but a very small percentage of software projects need that level of computational efficiency. Modern computers are fast. Even Ruby, which can be as much as 300 times slower than C++, can maintain a web application that gets several million hits per day with fairly modest hardware requirements.
Put it another way: how many systems will have their CPU requirements double every two years? Anything less than that rate of growth, and the pace of progress rapidly outstrips the resources necessary to use the system. The efficiency of C++ simply isn't required for the majority of server-side applications.
Besides, if efficiency is that important, why not use C or even write parts in assembly?. At some point, the benefits of programmer efficiency outweigh the benefits of CPU efficiency, and a higher level language becomes more advantageous than a lower level one.
Encouraging sloppy programming is the
last thing you want to do because it leads not only to poor scalability but also to misguided design decisions
that will quickly eat up and reverse your dream of "increased productivity".
Inefficiency, poor scalability and sloppy programming are three separate things. One does not automatically imply either of the others.
I sort of regret writing what I did, it was at the end of the work day in haste.
My apologies too, if my writing caused any offense. It wasn't intended.
Almost any problem you could create have had libraries written to solve them in almost every language, just utilize them and be done.
I've come across many, many problems where this simply isn't true. Whilst almost every language has libraries that handle regular expressions, graphics, network access and so forth, once you get into specifics, the difference between the libraries for languages becomes far more apparent. Java, for instance, has some very mature XMPP libraries, whilst in Python, all the equivalent libraries are in a much earlier stage of development. And as I've mentioned before, C++ doesn't have an equivalent to the Turbogears framework.
However, let's put the library issue to one side, and concentrate on whether the syntax of a language has any significant benefits for the programmer.
That said, the custom back-end business code to that webpage could be in almost any language and it would take nearly the same amount of development time. VB, C, anything.
I disagree with this as well, but for reasons that are less easily explained. I'll let a quote from Paul Graham's Beating the Averages essay start my argument:
But I think I can give a kind of argument that might be convincing. The source code of the Viaweb editor was probably about 20-25% macros. Macros are harder to write than ordinary Lisp functions, and it's considered to be bad style to use them when they're not necessary. So every macro in that code is there because it has to be.
Lisp macros are a good example of high level syntax that C++ does not possess. In Lisp, macros are used to manipulate code in the same way functions are used to manipulate data, or, to put it another way, Lisp macros enable you to make local changes to the syntax of the language. They are very different from the macros found in C or C++.
Given that the programmers in the startup Graham was involved in were writing so many macros, one has to wonder why. If programming in Lisp has no significant advantages over C++, why use a language construct like macros that has no direct analogy in C++?
There are two conclusions you can draw: either Lisp has no significant advantage over C++, and the programmers were using macros pointlessly. Or, that macros did serve a purpose, and thus Lisp does indeed offer advantages over C++. Given the success of the company, they must have been doing something right.
Indeed, one can see this same theme with many other libraries. Turbogears uses high level functions and metaclasses throughout its systems. Again, these are language constructs that C++ lacks, but are used often enough that one has to wonder about the benefits of these features, even if one knows nothing about them first hand. If Python offers no significant advantage over C++, why are these constructs put to use so commonly?
If 100% is not a significant overhead to you then, well, lucky you.
In many common server-based applications, which is where Java mainly excels, the amount of resources required is proportional to the number of requests made. A good example of this would be a website, or a database. This form of problem lends itself to parallisation; it's not uncommon to have heavy-use websites or databases running off multiple machines.
Generally speaking, it's far cheaper to buy another server than it is to employ a programmer for any significant period of time. A 100% overhead means nothing, if it saves the programmer some time.
For GUI applications too, 100% inefficiency means very little. If it takes 10ms instead of 5ms to complete an operation, the user is not going to notice. The only set of applications where this level of efficiency would be a problem, would be a CPU-intensive, single user application.
You've gotta be kidding me. Whatever. Listen, if you suck so bad that you can't just jump into a language and write, you should go back to school.
Your ignorance of the limitations of programming languages demonstrates that you're young, and still have a lot to learn. Your ability to devise a coherant argument is also somewhat lacking.
Again, I'm being rather blunt, which, admittedly, may not be the most diplomatic approach.
Consider this tutorial. It demonstrates how, in 20 minutes, you can construct a simple wiki using Turbogears and Python. If there is no disadvantage to using C++ in any programming task, then it should be a relatively simple task to achieve the exact application in C++ in the same time period.
I'll be honest with you: I couldn't write a wiki that fast in C++. It would take me 20 minutes just to get to grips with CGICC and the MySQL C++ API. I'd be lucky if I got it saving a single page, let alone an all-singing, all-dancing, AJAX-enabled wiki.
This example is loaded, in that C++ doesn't, to my knowledge, have a rapid-development MVC framework like Turbogears. However, it's loaded for a point; a programming language is more than the sum of its syntax. The worth of a programming language is also determined by many external factors, such as the libraries and frameworks written for it, the speed of the compiler, what IDEs support it, and so forth.
That's not to say syntax isn't important, but it's easier for me to demonstrate the worth of libraries than it is to go into the more abstract benefits of metaclasses and higher level functions.
If you want to argue your case, come up with a decent argument against the points I've raised. If you can't, then at least consider the possibility that you may be incorrect.
Are you directly addressing me in your statement or am I reading into it wrong?
I was. Bluntly, perhaps, but my statement holds true, nevertheless. You assert that "there's no reason C/C++ development has to take longer than Java/Python/Ruby". This is, frankly, uninformed nonsense. Again, I'm being blunt, but sometimes the direct approach is necessary in a discussion.
Slashdot Mirror
Can you give me an example of the benefits such knowledge has when programming in a high level language such as, say, Python or Ruby? I can't think of any significant benefits, but perhaps you can?
First, I'd like to express thanks at what has become a rather pleasent and certainly very interesting discussion. To my mind, arguments are only useful if you learn something from them.
I agree with you here. I'll also look into templates a little further; I confess there are probably parts of templating of which I am entirely ignorant. With regards to Boost:Lambda, I was rather impressed. The implementation is a little clunky, and limited to expressions rather than full closures, but it's remarkedly neat and clever for what it does. I rather suspect that macros are used exensively and to rather good effect.
Functors do replicate the functionality somewhat, but can be rather unwieldly to create in comparison. The complexity only increases with functors when you deal with creating classes (or a good impersonation of), rather than functions. I can't, off the top of my head, think of a very neat way of injecting default values into a class (rather than an object) via a function.
Your search was fruitless probably because I'm ignorant of the exact technical names. The theory, though is rather simple. In Python, the constructor returns an object (which is almost always an instant of the containing class), whilst the initializer is applied to an object the moment after it is created. An example is probably the best way to convey the difference. Take the following code:
In code not dissimilar to C++, this is Python code that constructs a new object from the class Foobar. If we expand this code out, the difference between the constructor and the initializer should become obvious:
The __new__ method is the constructor. The __init__ method is the initialiser. __new__ is applied before the object is created, and __init__ is applied directly after. Both receive the same arguments. I prefer this method, because it clearly differentiates between creating a new object, and setting the default values.
I confess that I know more about constructors in Java than I do constructors in C++. In the JVM based language Nice, the very subject of constructors verus initializers comes up in the Wiki. To quote the relevant parts:
There was a better article on this, which went into specific details of why the Java constructor was flawed, but I can't for the life of me find it. Thus, in absence of such fi
I've designed compilers before, and I wouldn't class constructing a C/C++ compiler as "trivial" :)
One could also make the opposite argument. Many computer courses teach languages such as C++, C# and Java, which all have connections to low level code. C# has its pointers and gotos, Java has its primatives, C++ has all of the above. There aren't many courses that focus more heavily on highly abstracted languages, such as Lisp.
And I think this is more important, really. Sure, there are many benefits to knowing the low level details of the system you're programming on; but its not essential to know, whilst it is essential to understand how to approach a programming problem. I'm not saying that an understanding of low level computational operations isn't important, merely that it is more important to know the abstract generalities.
Or, to put it another way, knowing how a computer works is not the same as knowing how to program effectively. At best, it's a subset of a wider field. At worst, it's something that is largely irrelevant to a growing number of programmers. I went to a University that dealt quite extensively with low level hardware and networking, and a significant proportion of the marks of my first year came from coding assembly and C for 680008 processors. Despite this, I can't think of many benefits such knowledge has when, say, designing a web application on Ruby on Rails. Perhaps you can suggest some?
I disagree. I think software sucks because software engineers don't understand programming
I assume you're including the functionality of specialist preprocessors in that list, but even so you have listed a few items of which I was previously unaware. A quick Google search for lambda expressions in C++ brings up preprocessors such as Clamp, which seem rather interesting indeed.
That said, I have to be careful here. A while ago, I pointed out that one of the advantages of Python over Java was its mutable classes (which could also potentially be a disadvantage as well, but I digress). The person I was discussing this pointed out this wasn't the case, informing me that one could dynamically alter a class at runtime by altering the JVM bytecode. Whilst this was technically true, there's a large difference in practicality between a single line of "Foobar.new_method = method_impl", and a page of Java code manipulating the bytecode of a class.
I'm interested in the compile-time metaprogramming you mention. Perhaps you could point me toward some resources? I'm aware of the capabilities of templates, but like Java bytecode manipulation, more complex stunts tend to get complicated. Do you know of many more preprocessors like Clamp? I'm something of a language nut, and learning something new about a language I thought I was reasonably familiar with is always very interesting.
That all said, I still disagree with your assertion. Runtime metaprogramming can be very useful, especially with higher level functions (or partial functions, as some people apparently refer to them). Brevity is another advantage; languages such as Python and Ruby tend to be very concise and informatically compact. C++, in my experience, is verbose and frequently deals with information that is beyond the scope of the problem. Or, to put it another way, if I were to translate a function from Python to C++, I'd have more things to worry about.
I also don't see anything on your list which Ruby cannot handle (or indeed Python, with the exception of anonymous closures and coroutines, the latter of which will only appear in Python 2.5).
No times, I'm afraid. I thought you were speaking more generally. I have translated C++-based programs into equivalent Python-based programs.
How so?
That's reminded me of another thing I prefer about Python. The concepts of class constructors and object initializers are seperate, whilst in languages like Java, and I believe C++, the concepts are (to my mind) messily intertwined.
You did avocate writing a web application in C++, though. Java's the usual choice for such things, so I was merely wondering why you chose C++ over Java. However, this was adequately answered in your third sentence:
What advantage does C++ have over, say, Java for programming web applications in? The only benefits I can think of is improved efficiency (which isn't necessary for the vast majority of websites), and some additional language constructs such as operator overloading. Neither of these would be sufficient enough to entice me to use C++ for such a use, so I was wondering why you find it so attractive.
The other difficulty I have with C++ is that it's not particularly powerful, in terms of syntax and control structures, as some other languages, such as Python or Ruby. When you don't particularly need the efficiency that C++ offers, why favour a more syntaxically restrictive language?
In my experience, very few bugs disappear. However, if you find that this is the case, why use dynamically typed languages such as PHP and Erlang? And there are surely languages that have stricter rulesets than C++; Eiffel, for instance, which is compiled, and strongly and statically typed, with design-by-contract built in. Or the JVM-based Nice, which again is strongly and statically typed, with optional preconditions and postconditions. C++'s weak static typing looks somewhat ineffectual by comparison.
I've read your post several times, and I'm unsure quite what you mean. To what extent do you think tools do not matter? For instance, is it your assertion that there is no benefit to designing a website with RoR over programming it in assembly? Does it matter how large the program is? Or are you claiming that tools don't matter at all?
You haven't referenced any sources to support this sentence. What studies, exactly?
You don't appear to have much experience with Ruby on Rails, if you consider it less maintainable and more "quick and dirty" than an application developed in PHP. Rarely is it a good idea to start an argument from a position of ignorance. A good engineer, software or otherwise, should know this.
This is one of the strangest reasons I've ever heard for not learning Ruby on Rails. Whilst the web may eventually be replaced by another system, I see no indication that this will happen any time soon. Certainly a number of firms believe it will be around long enough to invest heavily in web-based applications.
And surely your argument applies to any technology. Any library, language or framework can become obsolete. Would you advocate not learning at all, for fear that any knowledge learned becomes passe and useless?
Is there an equivalent system to Filterset.G in Opera? It doesn't matter how technically sophisticated Opera's adblocking system is, if you have to manually configure it, and manually update it, it's not as convenient as Adblock + Filterset.G under Firefox.
Firstly, Ruby has class permissions the same as Java. This isn't anything to do with Ruby.
Secondly, there are mistakes, and there are mistakes. If I decided to stick a electrical cable in my mouth without checking if it's live or not, then I suspect people wouldn't go around saying, "Well, he's only human". Instead, I rather suspect they'd say, "What a moron!", and rightly so. Likewise, if a programmer ignores a big fat warning and attempts to overload an undocumented, internal method of some hidden class, then they shouldn't be surprised if they screw something up.
Screwing around with undocumented internal functions is not something any experienced programmer would do lightly. Nor is it really something you can do by accident. You have to deliberately set out to screw with the internals, and if you don't know the problems that could result in, then quite frankly you deserve what's coming to you.
That's not a very accurate analogy. A better one would be, "Should we plaster this support pillar with warning signs saying 'Do not destroy', and trust our workers not to take a jackhammer to it, or should we construct an elaborate cage around it to prevent any mishaps?". In construction, warning signs are used more often than physical barriers, since the construction firms expect their employees to have some idea about workplace safety. I see no reason why software development should be any different.
Not all firms take this approach. I once had a job offer from a company who worked mainly with C#, a language which I had no prior experience in. The difficulty was not learning C#, but learning the architecture and internal APIs of the large software package they sold. They presumably knew this, otherwise they wouldn't have offered me the job.
Paradigms and patterns are often cross-language. Syntax usually has a lot of overlap with existing languages.
You are right, however, with your mention of libraries. But if you stop and think about it, programmers don't need to know that much about the standard libraries of a programming language to code effectively. For instance, I've worked with Python for a long time. But if you asked me to name all the modules in the standard library, I could only manage about six, and I'd be able to tell you even less about the functions in those libraries. I have a similar experience with Java; I can recall only a dozen standard classes off the top of my head.
But the thing is, I don't need to know the specifics. All I need to know is general capabilities. If I know that Java, or Python, has a regular expression library, then the documentation is a two second Google away. I don't need to know the details of the library; I just need to know what to search for. This reduces the task considerably, not only because the problem is now abstracted, but also because there's a lot of overlap between standard libraries, much as there is with syntax. Most languages nowadays, for instance, include regular expressions as standard.
Someone with that level of incompetance would find a way to screw things up even with strict class permissions. I'd also be leery about working for a company who would employ people without a technical interview to determine if they knew what they were doing.
Sure, for untrusted users. But if you consider the programmers in your team to be incompetant enough to screw up that badly, then I'd contend your problems are too widespread to be solved by class permissions.
Again, if you have an imbecile hiding somewhere in the chain of development, class permissions aren't going to solve much. If you're using a piece of third-party software, be it a library, framework or whatever, you place a degree of trust in the developers not to have completely FUBARed the code. If you don't trust them, or have reason to suspect that the software was developed by people with a room temperature IQ, then why on earth are you using the software in the first place?
Class permissions are not adequate protection from incompetant developers. To believe otherwise is to give yourself a false sense of security.
Easy replacement of employees? As I said before, any skilled developer will be able to pick up a language in a far shorter time than they could get to grips with any reasonably complex software product. Also, those developers who are familiar with less popular languages, tend also to be some of the most competant. You don't learn Ruby to improve your prospects of employment; you do it because you enjoy programming for the sake of programming.
As for tools and libraries, if the language you use has all the necessary tools for the product you're developing, then Java has no inherent advantage. Indeed, once one moves away from Java, it's limitations rapidly become apparent. Contrast Java's Hibernate with Python's SQLObject. If you need to handle large volumes of database queries, then Hibernate's clustering and efficienty ORM mappings become rather essential. But if you aren't dealing with that level of traffic, then the less CPU efficient, but far more concise SQLObject starts to look terribly tempting.
This isn't just a problem with a specific library. Java can't emulate SQLObject in any meaningful way, as it lacks the syntax capabilities to do so. Thus, in some respects, other languages can offer better libraries than Java, as they're not subject to the same restrictions.
You have that problem whatever language is used. If only one programmer is working on a large, critical piece of software, then you're clearly going to have problems if they bugger off. That's why you ensure beforehand that other developers have the necessary knowledge about the system to fix any problems, or to continue work after the main developer leaves.
Sure, and why should that be a problem? Once my library is in the hands of a developer, what he does with it is completely up to him. If he attempts to extend an undocumented internal function, what happens is not my problem. Warrenty void if opened.
Of course it isn't. The examples you give deal with protecting data and hardware from other users. Class permissions are designed to protect the developer from themselves. I'm of the opinion that programmers should be given more than enough rope to hang themselves with; you never know when those extra feet of rope could come in handy.
You've lost me. If a language is clearly more suited to a particular task than another, surely that's reason enough to use it?
A significant proportion, perhaps even the majority, of software companies specialise either on a single product, or on an set of similar products. In such cases, there isn't so much of an advantage to using a "Jack of all trades" language such as Java.
Besides, any new developer will likely as not have to get to grips with the company's software and internal libraries anyway. For an experienced programmer (and would you want to hire any other kind?), learning a new programming language is trivial in comparison. There's much more overlap between programming languages than there is between libraries and frameworks; it's just a case of mapping familiar constructs to a new syntax.
So long as the languages are chosen wisely, I fail to see the problem. As I pointed out earlier, learning a new language is trivial compared to trying to understand the source code and architecture of a complex application you yourself have not worked on before, even with extensive documentation.
Realistically though, I can't see a business needing eight different languages. I've never found myself using much more than three regularly.
That's why I prefer Python, myself ;)
Gah! You decry over-generalisations, then make one of your own!
To an extent, you're correct. A one line hack in Perl is often not maintainable in the future.
But you're only addressing part of what I wrote. I said, "You can often do more in a shorter space of time, and in a smaller amount of code". Both parts of the sentence are important. Code in Ruby is not concise in the same way a one liner of Perl is concise. For instance:
The above code is concise, yet understandable. You can see that this is an ActiveRecord called Folder, which acts as a tree, and that each Folder has many files.
Incidentally, this concise readbility is made possible only through Ruby's support of mutable classes. The two functions, acts_as_tree and has_many, alter the class that they exist in. Incidentally, because Java cannot easily alter class behaviour, so this technique is beyond Java's capabilities. This means that often, Ruby can be more readable than the equivalent Java code.
This is largely unrelated to Ruby, as Ruby supports class permissions. However, I disagree with you about this. If a developer wishes to shoot his foot off, let him. So long as you make it clear in your documentation that overloading this particular function is not something that should be done, there's no need to go any further. A stupid developer will always find ways to break things; there's no point in nannying the programmer.
A good balance? I don't understand your argument. Okay, sure, if you had a choice of one language, and one language only, to use for every project from now 'till doomsday, then Java might be your man. But individually, some programming projects are rather specific. You don't need a "good balance" of features and libraries; you need the features and libraries that are best for that particular job. Sometimes Java will fulfil that need best, and sometimes other languages will.
You said it yourself: 'Java is not good because "it's the best language with the best features"'. Follow that chain of logic forward and you'll come to the conclusion that Java is not the best language for every possible problem. Nor, for that matter, is Ruby, or Python, or Scheme, or Haskell, or whatever else you might happen to come across. Your choice of language should be dictated by the problem you face.
Also, if you're so stuck on libraries, then a JVM-based language such as Nice might be just up your street.
Obviously. I program in Java for a living. I'm quite aware of amount and quality of libraries available for Java.
However, in terms of general web development, Ruby's featureset is fairly complete. There isn't much it lacks. I mean, sure, if you want a complete business solution that involves messaging, job scheduling, customisable rulesets, clustering and goodness knows what else, then Java's probably the better choice. But if you just want a web framework with ORM, templating system, unit testing, AJAX integration and search engine, then Ruby has it covered.
And once you start to develop custom code, Ruby's featureset is its advantage. You can often do more in a shorter space of time, and in a smaller amount of code, in Ruby than in Java. Indeed, some programming techniques are so cumbersome in Java, that it's rarely advantageous to go near them; JIT class construction, for instance. In Ruby, many of these techniques are standard ammunition in the programmer's arsenal.
Not really. Java had a multibillion dollar corporation pushing it. That often helps.
There are other reasons. To get the most out of Ruby, you need to understand the more exotic concepts available in it. This requires a certain level of skill that may not be available to every programmer. In which case, many of the advantages to using Ruby over Java are lost.
Virtual machine dfficiency, familiarity and product visibility all also play a part in Java's success.
That's not quite what I asked. As a presumably experienced programmer, you will doubtless know that some languages are more suitable for some tasks than others. One would not construct a web application in assembly, for instance.
The claim that "Ruby is not a match for Java" reeks of generalities. Ruby is clearly a rather different language to Java, and has disadvantages and advantages to use. The most obvious disadvantage of Ruby is that it's slow. An advantage is that Ruby is a syntaxically more flexible and concise language than Java. The list goes on. To claim that Java exceeds Ruby under all circumstances, which is what your original quote appears to suggest, seems patently false.
Java has its uses, as does Ruby.
How is this unfounded statement any better than what's written in the article?
Why would you need to? Your methods should be short enough to tell at a glance where the end is. Any class or module of sufficient length should live in their own file. This isn't C. A method in Python or Ruby that has a dozen lines is approaching the limit of acceptable length. If your methods span pages and pages, you're simply not programming very well.
Frankly, you don't have the experience necessary to make such an assertion. Your uninformed opinions make you sound like an idiot. Before you criticise something, ensure you understand it well beforehand. Ignorance is rarely a good position to start an argument from.
Surely this is a personal point of view? You might very well argue that Opera is better programmed, or more efficient, or does a better job of rendering pages, but just "better" is a subjective assertion.
I'm impressed with Opera, but until it supports the same level of extensions, I personally wouldn't class it as "better" (as otherwise, I'd be using it!)
I often find it helpful to read and understand a person's post before replying to it. Obviously, you don't adhere to this particular philosophy.
If you had read my post, you'd discover that I did not once refer to the performance of Rails as "impressive". Indeed, I did not mention the word even once. Instead, I said, "I consider half a dozen machines to be a fairly modest hardware requirement for handling such large volumes of traffic." This is quite different from the statement you appear to think I said.
In my previous post, I merely pointed out that for a website that handles several million potential customers a day, six servers is a modest requirement to keep everything running, both financially, and in terms of support.
Further, your figures are idiotic. In March this year, Google handled around 91 million searches a day. That's around 1000 searches per second. Why, that's not even 10% of the capacity of your one hypothetical machine, and Google have over 200'000 servers. 10'000 request per second might be more realistic if one was only serving static content, but hardware requirements rapidly increase once you start to factor in dynamic content, such as is produced by RoR.
According to Wikipedia, Penny Arcade handles 2 million page requests daily with Ruby on Rails. On the forums there, it's been mentioned that Penny Arcade runs off a cluster of 5 machines.
If Penny Arcade's content is too static for your tastes, then the Robot Co-op family of sites, which consists largely of AJAX web applications such as 43places, manages 2.5 million daily page requests with 6 machines.
I consider half a dozen machines to be a fairly modest hardware requirement for handling such large volumes of traffic. You may disagree.
You misunderstand me. What I'm saying is that, in general, the average increase of CPU requirements for server applications is likely less than a 100% increase every two years. Given this initial premise, the logical conclusion is that, in overall, the number of server applications that use Java will tend toward an increase, and correspondingly, the number of C++ server applications will decrease.
Obviously most server-side systems last for longer than two years, but what matters is the rate of increase. For instance, if the average lifespan of a C++ server system is ten years, then unless resource requirements have increase a thousandfold in that time, then it makes more sense for the replacement to be programmed in Java (or Python, or Ruby), than in C++.
Most of the time, I'll agree with that. My point was more that inefficient programs (in terms of computer resources being used) does not imply sloppy coding, nor an unscalable system. A program need only perform up to spec with the resources it has; efficiency gains beyond that point will be increasingly less useful and more costly.
Which is why Google use C++ for their performance intensive systems, but a very small percentage of software projects need that level of computational efficiency. Modern computers are fast. Even Ruby, which can be as much as 300 times slower than C++, can maintain a web application that gets several million hits per day with fairly modest hardware requirements.
Put it another way: how many systems will have their CPU requirements double every two years? Anything less than that rate of growth, and the pace of progress rapidly outstrips the resources necessary to use the system. The efficiency of C++ simply isn't required for the majority of server-side applications.
Besides, if efficiency is that important, why not use C or even write parts in assembly?. At some point, the benefits of programmer efficiency outweigh the benefits of CPU efficiency, and a higher level language becomes more advantageous than a lower level one.
Inefficiency, poor scalability and sloppy programming are three separate things. One does not automatically imply either of the others.My apologies too, if my writing caused any offense. It wasn't intended.
I've come across many, many problems where this simply isn't true. Whilst almost every language has libraries that handle regular expressions, graphics, network access and so forth, once you get into specifics, the difference between the libraries for languages becomes far more apparent. Java, for instance, has some very mature XMPP libraries, whilst in Python, all the equivalent libraries are in a much earlier stage of development. And as I've mentioned before, C++ doesn't have an equivalent to the Turbogears framework.
However, let's put the library issue to one side, and concentrate on whether the syntax of a language has any significant benefits for the programmer.
I disagree with this as well, but for reasons that are less easily explained. I'll let a quote from Paul Graham's Beating the Averages essay start my argument:
Lisp macros are a good example of high level syntax that C++ does not possess. In Lisp, macros are used to manipulate code in the same way functions are used to manipulate data, or, to put it another way, Lisp macros enable you to make local changes to the syntax of the language. They are very different from the macros found in C or C++.
Given that the programmers in the startup Graham was involved in were writing so many macros, one has to wonder why. If programming in Lisp has no significant advantages over C++, why use a language construct like macros that has no direct analogy in C++?
There are two conclusions you can draw: either Lisp has no significant advantage over C++, and the programmers were using macros pointlessly. Or, that macros did serve a purpose, and thus Lisp does indeed offer advantages over C++. Given the success of the company, they must have been doing something right.
Indeed, one can see this same theme with many other libraries. Turbogears uses high level functions and metaclasses throughout its systems. Again, these are language constructs that C++ lacks, but are used often enough that one has to wonder about the benefits of these features, even if one knows nothing about them first hand. If Python offers no significant advantage over C++, why are these constructs put to use so commonly?
In many common server-based applications, which is where Java mainly excels, the amount of resources required is proportional to the number of requests made. A good example of this would be a website, or a database. This form of problem lends itself to parallisation; it's not uncommon to have heavy-use websites or databases running off multiple machines.
Generally speaking, it's far cheaper to buy another server than it is to employ a programmer for any significant period of time. A 100% overhead means nothing, if it saves the programmer some time.
For GUI applications too, 100% inefficiency means very little. If it takes 10ms instead of 5ms to complete an operation, the user is not going to notice. The only set of applications where this level of efficiency would be a problem, would be a CPU-intensive, single user application.
Your ignorance of the limitations of programming languages demonstrates that you're young, and still have a lot to learn. Your ability to devise a coherant argument is also somewhat lacking.
Again, I'm being rather blunt, which, admittedly, may not be the most diplomatic approach.
Consider this tutorial. It demonstrates how, in 20 minutes, you can construct a simple wiki using Turbogears and Python. If there is no disadvantage to using C++ in any programming task, then it should be a relatively simple task to achieve the exact application in C++ in the same time period.
I'll be honest with you: I couldn't write a wiki that fast in C++. It would take me 20 minutes just to get to grips with CGICC and the MySQL C++ API. I'd be lucky if I got it saving a single page, let alone an all-singing, all-dancing, AJAX-enabled wiki.
This example is loaded, in that C++ doesn't, to my knowledge, have a rapid-development MVC framework like Turbogears. However, it's loaded for a point; a programming language is more than the sum of its syntax. The worth of a programming language is also determined by many external factors, such as the libraries and frameworks written for it, the speed of the compiler, what IDEs support it, and so forth.
That's not to say syntax isn't important, but it's easier for me to demonstrate the worth of libraries than it is to go into the more abstract benefits of metaclasses and higher level functions.
If you want to argue your case, come up with a decent argument against the points I've raised. If you can't, then at least consider the possibility that you may be incorrect.
I was. Bluntly, perhaps, but my statement holds true, nevertheless. You assert that "there's no reason C/C++ development has to take longer than Java/Python/Ruby". This is, frankly, uninformed nonsense. Again, I'm being blunt, but sometimes the direct approach is necessary in a discussion.