Again, I disagree. Even coding of the web application is a minor part of the project except for the very smallest projects. Most reasonable web projects involve careful storyboarding of the web pages, design and testing of database schemas and lots and lots of CSS work.
I suggest we agree to disagree. It's clear that this is coming down to personal experience, something that is a little difficult to base an argument upon, without degenerating to each of us blindly insisting the other is wrong.
Actually, I am.... These applications contain things like image handling, grammar checking, spell checking, file parsing and transfer, and many sophisticated GUI features.
If your text editor truly takes up as much processing power and memory as the latest 3D chart-topper, then perhaps you should look for a piece of software with a little less weight?
Having developed with a range of programming languages for 30 years, I just don't believe that this sort of speed different exists between languages. Unless you are using something really awful or verbose, then any competent developer truly familiar with any modern language and it's libraries will be productive. Ruby may well be at least 3x as consise as Java, but raw coding time does not make up that much of the development time of any significant project.
Ruby's conciseness is a by-product of its power. Working around Java's limitations often isn't a trivial task, and Ruby's powerful syntax makes it possible to design some very flexible frameworks. For instance, one commerical java project I was involved in required a web-based file storage system. When I look back on it, Ruby on Rails would have made the job infinitely easier; once the user and file database tables were set up, Rails would have automagically generated class and html interfaces for them. A login helper would have created the login, and then it would have only required a few lines of code to connect in Rail's file upload handling. The entire project could have done in days what had been done in weeks using Java tools.
From my own experience, Ruby has been considerably faster than Java.
I really don't believe it will. Ruby is a wonderful language I agree, but actual language coding is not a major part of any project. Design, testing and debugging are. In these areas, in my opinion, there is little difference between the language (in fact, Java has a wider range of high-quality IDEs and debugging tools).
I must disagree here. I can think of several commercial Java web-based projects that I know could have been done in at least the third the time in Ruby on Rails. And the programmer and author Paul Graham holds his startup's use of Lisp as the major factor in their resulting success. In my experience, the choice of language is far more significant than you make it out to be.
Because not getting the best performance out of hardware, no matter how old or new it is, puts your application at a disadvantage compared to your competitors. No matter how much you may try and justify things, your users don't care about the language you use to develop - they care about performance.
But if your product comes out 6 months before your competitors, and is developed at three times the rate, who's going to have the advantage then? People don't care about performance as much as they do features and capabilities. Further, performance loss is only noticable by the human eye up to a point. If your product responds within 100ms, then it isn't going to matter whether it returns in 5ms or 50ms.
There are situations where performance doesn't matter, but this is not true for 'most' applications.
I find this rather hard to believe. The resources needed to run Halflife 2, and the resources required to run a Instant Messenger application, are on a quite different scale from one another. Clearly, therefore, you can afford more inefficiencies in an IM application, than you could in the latest 3D game. Are you claiming that this isn't the case? That we need the latest graphics cards and processors to run text-editors, personal organisors or IM programs?
Performance matters up to a point, but it's important to realise that there is a point where it ceases to matter. Where this point is depends on your application. A user isn't going to care whether a function takes 1 millisecond or 40 time as long. So long as it is below the barrier at which the inefficiencies become noticable, these inefficiencies don't matter.
Programming languages like Ruby, are less efficient from the computer's point of view, but more efficient from a programmer's perspective. If you can develop your product and push it out into production 3 times faster than your competitors, with little noticable performance loss, then you're going to make more money. If you can add more features and adapt to the market 3 times faster, then you're going to make more money. Sometimes the advantages of using a language like Ruby or Python outweigh the disadvantages.
If you're programming for older hardware, or for mobile devices, then I could understand your use of Java. Likewise, if you're developing a large application, I could understand your use of Java. But if you don't need such efficiency from your code, why spend more time developing a program in Java, when you could develop it faster in Ruby?
As a side note, why is it the people so quickly forget what these languages are really for. They are Rapid Application Development(RAD) and prototyping languages. You're not supposed to ship products developed with these languages! You're supposed to prototype the application and if it looks viable, develop it in a real language like C or C++!
Why? The speed of C and C++ are hardly needed for most applications, and languages like Ruby and Python can leverage GUI toolkits like Qt and GTK. If your Qt Ruby application is indistinguishable from your Qt C++ application, why waste time developing in C++ if you don't have to?
I too like Python, but let's put this into perspective. This is an article about Ruby and Java, not about Python. Just because someone starts talking about Ruby doesn't mean they're mandated to mention the alternatives.
Claude Shannon and Information Thoery would tend to disagree.
Not at all; note my use of the term 'a defined sequence'. Random noise is not defined when an analogue signal is processed, otherwise it would merely be a case of subtracting what you know to be the noise from the transmitted signal in order for you to perfectly retrieve the original message. Shannon talks of randomness as an undefined function that cannot be predicted, a barrier to the communications signal you wish to transmit.
On the other hand, DNA is a predefined sequence, and one cannot distinguish between noise and signal; genes that don't do anything one generation, may turn out to be beneficial several thousand generations down the line. So, if anything, the randomness in DNA adds to the information content. It's been a while since I've covered Information Theory, but couldn't one make the argument that the randomness that exists in DNA actually reduces the entropy? A perfectly random sequence of numbers cannot be compressed, by definition, so the greater the element of randomness in DNA, the less it can be compressed and thus the lower its overall entropy.
I know this, but in simple cases map is a neater and more concise option, and one can always implement it locally, even if it is removed as a builtin function:
items = map(Item, elements) items = [Item(elem) for elem in elements]
Any Python programmer can tell you at a glance what that means. Indeed, most functional programmers could tell you what it means as well. The 'map' function is standard in quite a few languages, as is 'filter'. In essense, it iterates through a list of values, passing them to the function supplied (in this case, the object constructor), and returning the resulting list.
One could make it even more clearer by splitting it up on two lines:
But this isn't really necessary. I think it's clear enough without it. Java can't do things like this, because it has an incomplete object model. Unlike Python or Ruby, methods aren't first class objects in Java, so you can't pass them directly as arguments; you need to rely on complex object wrappers instead, which aren't convinient for functions such as 'map'.
Damn, I love it when people type a bunch of stuff, that as I'm reading it sounds like it might be generally true, and then they end it with an imbecilic statement from evident ignorance tanking their credibility and casting into doubt everything else that was said.
Notice I said VB, and not VB.NET; though even VB.NET doesn't compare well with Python or Ruby.
There is never an excuse to copy and paste. I have worked on extremely large (millions of loc) systems and have never had to copy and paste (yes we actively monitored for this bad practice).
I think you misunderstand me; I'm not talking about using copy and paste to produce identical code (although sometimes interfaces make this unavoidable to an extent), I'm talking about using copy and paste to produce similar code. Getters and setters are a big causer of this, along with interfaces and the unwieldly introspection Java has.
For instance, here's an example that's similar to a problem I recently faced. I need to convert a group of xml Elements to custom objects:
NodeList elements = element.getElementsByTagName("item");
items = new Items[elements.getLength()];
for (int i = 0; i < items.length; i++) { items[i] = new Item( (Element)elements.item(i) ); }
This same code appears in several methods, but because each method uses a different custom class, it can't be easily put into a method. I thought about creating a method that took in a NodeList and Class object, but that would take more time than simply copy and pasting code and changing the class names, which would rather defeat the point.
In Python, the entire code above can be represented in just one line:
My point was that, yes, String s = new String() has redundant type information in it, but that's not the only type that will ever be assigned a String object. Object s = new String() does not have any redundant type information in it.
This is true, which is why I proposed making the type optional, defaulting to the type returned by the constructor:
However, I cannot think of a single situation where explicitly declaring the type would be useful anyway, since subtypes can be implicitly defined on method arguments:
In java, the type of the object and the type assigned to it can be different. In a real program, I might create an object with the interface type, and get a reference to a type based on a factory class that may choose from a number of classes that implement that interface. It's a common practice when dealing with database engines, logging engines, etc, that have mostly the same interface, but can be used generically if you only use the interface's public interface. The compiler will tell you immediately if you're using a member that's not part of the interface, in this case, and you can avoid some very annoying bugs. You can't do this with dynamically typed languages at compile time, which means you can get unexpected results at runtime.
Yes, I know this. Type safety isn't available in dynamically typed languages (though dynamically typed langauges have the advantage of mutable objects, which can be very useful).
But why mention dynamically typed languages at all?! I've been talking about statically typed languages, like Java or C#. Nice is also a statically typed language. This can be demonstrated quite easily:
// foo is initialised with type Foo var foo = new Foo();
// This line will throw a compiler error, because we are trying to assign // a Bar object to foo, which we've just defined as being of type Foo. foo = new Bar();
See? Statically typed. The above is no different to the following Java code:
Foo foo = new Foo();
// Next line throws a compiler error, because Bar is not a subclass of Foo foo = new Bar();
That's worth mentioning again. Nice is statically typed, the same as Java.
I think this may be an issue with size of codebase: you claim you'd look at pmd, but wouldn't it be easier just to check by hand. To which i'd say: not in 40,000 source files, no it wouldn't. When I first ran PMD against our 40,000 source files I turned up four bad semi-colons, three of which were real bugs (one had no side effect).
Probably. Generally the projects I've been involved in have between 10 to 300 source files. I'd be rather hesitant about using Python for a project that needed 40'000 source files! I might be tempted to try Scala for such a task.
I correct myself - I am talking about strongly statically typed languages as opposed to dynamic. Correct me if I'm wrong, but since java is strongly, statically typed, how could:
foobar = SomeClass()
as a declaration possible work w/o changing basis of the entire language? There is no type for foobar.
But there is! Consider the following code in plain Java:
String foobar = new Integer(3);
When I try to compile it, it comes up with an error:
Test.java:7: incompatible types found : java.lang.Integer required: java.lang.String String foobar = new Integer(3); ^ 1 error
From the above, it should be clear that Java knows that "new Integer(3)" returns an Integer object. Java's smart enough to figure out that a constructor of class Integer, returns an object of type Integer. It also knows that this Integer object is incompatable with the String type; hence the type error.
So in Nice:
var foobar = new Integer(3);
The Nice compiler knows that "new Integer(3)" returns an Integer, and that "var foobar =" is a declaration, so it assigns the type Integer to the variable foobar. The above Nice code is directly equivalent to the following code in Java:
Integer foobar = new Integer(3);
And that's why it's redundant to write the type of the variable twice over.
I'll take a look at pmd, though I suspect that errors from extra semicolons are significantly rare enough for it to be more trouble to download and use pmd than it would be to check through by hand. The javac 1.4.2 compiler didn't catch the above bug, though perhaps 1.5 would.
Regardless, for me, it is easier to spot the mistake here (indentation represented by "_"):
if x == 1:<br/> ____ y = 2 return y
#more code
Than here:
if (x == 1) { ____ y = 1; } ____ return y
# more code
Nor can I think of a single time when Python's indentation has caused a bug for me. Maybe I've just been extremely lucky for two years, but I can't say I think it's a tenth the problem that you say. Also, I've spent more time on errors with semicolons and bracket in Java, than I have had with Python whitespacing.
I think we are coming from different backgrounds here - strongly-typed(Java,C#,Ada,etc) vs weakly-typed (many scripting languages, assembly, etc) languages...
Quite a few modern scriping languages, such as Python and Ruby, are strongly typed, just as Java and C# are. The difference between these is that Python and Ruby are dynamically typed, and Java and C# statically typed. This all said, I'm a professional Java developer with a couple of qualifications in C++ as well, so I do know a little about statically typed languages.
for example your code:
foobar = SomeCustomClassName()
is that a declaration or a reassignment? what object type is foobar? By declaring a variable, I am referring to declaring its type, which the above doesn't do, adding a 'var' in front doesnt remedy this. Declaring the variable type at compile time can drastically reduce the amount of runtime errors that occur, as they are caught at compile time instead.
The above is a valid compile time declaration. In answer to your question, the above is a declaration iff the variable 'foobar' has not been previously definied. As to working out what object type foobar is - that's the whole point of strong typing! The foobar variable is assigned the type that SomeCustomClassName() returns.
To give you an idea of what I mean, the code below would generate a type error at compile time:
foobar = SomeClass()
// foobar hasn't been defined before, so the above assignment // is a declaration, not a reassignment. The type that SomeClass() // returns is 'SomeClass', so foobar is assigned the type // 'SomeClass'
foobar = AnotherClass()
// the above causes a compile time error, because foobar has // already been defined as type 'SomeClass' by the previous line // of code, and AnotherClass() returns type 'AnotherClass', // which is not compatable with 'SomeClass'
If you're still not convinced, take a glance at the following code:
var foobar = new FooBar();
This is valid Nice code, a language that compiles into Java class files and is totally compatable with the JVM and Java library. If a small Open Source project can achieve this, there's no reason Sun cannot.
Slashdot Mirror
Then I respectfully submit that you, sir, should have worked an opinion on Lisp and Haskell into your answer.
I suggest we agree to disagree. It's clear that this is coming down to personal experience, something that is a little difficult to base an argument upon, without degenerating to each of us blindly insisting the other is wrong.
If your text editor truly takes up as much processing power and memory as the latest 3D chart-topper, then perhaps you should look for a piece of software with a little less weight?
Ruby's conciseness is a by-product of its power. Working around Java's limitations often isn't a trivial task, and Ruby's powerful syntax makes it possible to design some very flexible frameworks. For instance, one commerical java project I was involved in required a web-based file storage system. When I look back on it, Ruby on Rails would have made the job infinitely easier; once the user and file database tables were set up, Rails would have automagically generated class and html interfaces for them. A login helper would have created the login, and then it would have only required a few lines of code to connect in Rail's file upload handling. The entire project could have done in days what had been done in weeks using Java tools.
From my own experience, Ruby has been considerably faster than Java.
I must disagree here. I can think of several commercial Java web-based projects that I know could have been done in at least the third the time in Ruby on Rails. And the programmer and author Paul Graham holds his startup's use of Lisp as the major factor in their resulting success. In my experience, the choice of language is far more significant than you make it out to be.
But if your product comes out 6 months before your competitors, and is developed at three times the rate, who's going to have the advantage then? People don't care about performance as much as they do features and capabilities. Further, performance loss is only noticable by the human eye up to a point. If your product responds within 100ms, then it isn't going to matter whether it returns in 5ms or 50ms.
I find this rather hard to believe. The resources needed to run Halflife 2, and the resources required to run a Instant Messenger application, are on a quite different scale from one another. Clearly, therefore, you can afford more inefficiencies in an IM application, than you could in the latest 3D game. Are you claiming that this isn't the case? That we need the latest graphics cards and processors to run text-editors, personal organisors or IM programs?
Performance matters up to a point, but it's important to realise that there is a point where it ceases to matter. Where this point is depends on your application. A user isn't going to care whether a function takes 1 millisecond or 40 time as long. So long as it is below the barrier at which the inefficiencies become noticable, these inefficiencies don't matter.
Programming languages like Ruby, are less efficient from the computer's point of view, but more efficient from a programmer's perspective. If you can develop your product and push it out into production 3 times faster than your competitors, with little noticable performance loss, then you're going to make more money. If you can add more features and adapt to the market 3 times faster, then you're going to make more money. Sometimes the advantages of using a language like Ruby or Python outweigh the disadvantages.
If you're programming for older hardware, or for mobile devices, then I could understand your use of Java. Likewise, if you're developing a large application, I could understand your use of Java. But if you don't need such efficiency from your code, why spend more time developing a program in Java, when you could develop it faster in Ruby?
Why? The speed of C and C++ are hardly needed for most applications, and languages like Ruby and Python can leverage GUI toolkits like Qt and GTK. If your Qt Ruby application is indistinguishable from your Qt C++ application, why waste time developing in C++ if you don't have to?
I too like Python, but let's put this into perspective. This is an article about Ruby and Java, not about Python. Just because someone starts talking about Ruby doesn't mean they're mandated to mention the alternatives.
If speed and memory usage is your only criteria when choosing a language, why not use C or assembly?
Not at all; note my use of the term 'a defined sequence'. Random noise is not defined when an analogue signal is processed, otherwise it would merely be a case of subtracting what you know to be the noise from the transmitted signal in order for you to perfectly retrieve the original message. Shannon talks of randomness as an undefined function that cannot be predicted, a barrier to the communications signal you wish to transmit.
On the other hand, DNA is a predefined sequence, and one cannot distinguish between noise and signal; genes that don't do anything one generation, may turn out to be beneficial several thousand generations down the line. So, if anything, the randomness in DNA adds to the information content. It's been a while since I've covered Information Theory, but couldn't one make the argument that the randomness that exists in DNA actually reduces the entropy? A perfectly random sequence of numbers cannot be compressed, by definition, so the greater the element of randomness in DNA, the less it can be compressed and thus the lower its overall entropy.
So if something has not been observed, it cannot happen? Interesting philosophy. Stupid; but interesting nevertheless.
What have explosions got to do with anything?
Technically speaking, a defined sequence is information, even if it is random.
Except creationism doesn't match the criteria of a scientific theory, so it rather fails at the first hurdle, doesn't it?
No it doesn't; it just assumes that an intelligent designer doesn't directly interfere with natural selection.
"Scientifically proven" is an oxymoron. No scientific theory has ever been proved. Ever.
My definition of 'big' wasn't quite as large as yours :)
Any Python programmer can tell you at a glance what that means. Indeed, most functional programmers could tell you what it means as well. The 'map' function is standard in quite a few languages, as is 'filter'. In essense, it iterates through a list of values, passing them to the function supplied (in this case, the object constructor), and returning the resulting list.
One could make it even more clearer by splitting it up on two lines:
But this isn't really necessary. I think it's clear enough without it. Java can't do things like this, because it has an incomplete object model. Unlike Python or Ruby, methods aren't first class objects in Java, so you can't pass them directly as arguments; you need to rely on complex object wrappers instead, which aren't convinient for functions such as 'map'.
Notice I said VB, and not VB.NET; though even VB.NET doesn't compare well with Python or Ruby.
I think you misunderstand me; I'm not talking about using copy and paste to produce identical code (although sometimes interfaces make this unavoidable to an extent), I'm talking about using copy and paste to produce similar code. Getters and setters are a big causer of this, along with interfaces and the unwieldly introspection Java has.
For instance, here's an example that's similar to a problem I recently faced. I need to convert a group of xml Elements to custom objects:
This same code appears in several methods, but because each method uses a different custom class, it can't be easily put into a method. I thought about creating a method that took in a NodeList and Class object, but that would take more time than simply copy and pasting code and changing the class names, which would rather defeat the point.
In Python, the entire code above can be represented in just one line:
A language like Python is powerful enough to avoid repetition in almost all cases. Java, unfortunately, isn't.
This is true, which is why I proposed making the type optional, defaulting to the type returned by the constructor:
See the ancestor post, here
However, I cannot think of a single situation where explicitly declaring the type would be useful anyway, since subtypes can be implicitly defined on method arguments:
Yes, I know this. Type safety isn't available in dynamically typed languages (though dynamically typed langauges have the advantage of mutable objects, which can be very useful).
But why mention dynamically typed languages at all?! I've been talking about statically typed languages, like Java or C#. Nice is also a statically typed language. This can be demonstrated quite easily:
See? Statically typed. The above is no different to the following Java code:
That's worth mentioning again. Nice is statically typed, the same as Java.
Understand now?
Probably. Generally the projects I've been involved in have between 10 to 300 source files. I'd be rather hesitant about using Python for a project that needed 40'000 source files! I might be tempted to try Scala for such a task.
But there is! Consider the following code in plain Java:
When I try to compile it, it comes up with an error:
From the above, it should be clear that Java knows that "new Integer(3)" returns an Integer object. Java's smart enough to figure out that a constructor of class Integer, returns an object of type Integer. It also knows that this Integer object is incompatable with the String type; hence the type error.
So in Nice:
The Nice compiler knows that "new Integer(3)" returns an Integer, and that "var foobar =" is a declaration, so it assigns the type Integer to the variable foobar. The above Nice code is directly equivalent to the following code in Java:
And that's why it's redundant to write the type of the variable twice over.
I'll take a look at pmd, though I suspect that errors from extra semicolons are significantly rare enough for it to be more trouble to download and use pmd than it would be to check through by hand. The javac 1.4.2 compiler didn't catch the above bug, though perhaps 1.5 would.
Regardless, for me, it is easier to spot the mistake here (indentation represented by "_"):
Than here:Nor can I think of a single time when Python's indentation has caused a bug for me. Maybe I've just been extremely lucky for two years, but I can't say I think it's a tenth the problem that you say. Also, I've spent more time on errors with semicolons and bracket in Java, than I have had with Python whitespacing.
Quite a few modern scriping languages, such as Python and Ruby, are strongly typed, just as Java and C# are. The difference between these is that Python and Ruby are dynamically typed, and Java and C# statically typed. This all said, I'm a professional Java developer with a couple of qualifications in C++ as well, so I do know a little about statically typed languages.
The above is a valid compile time declaration. In answer to your question, the above is a declaration iff the variable 'foobar' has not been previously definied. As to working out what object type foobar is - that's the whole point of strong typing! The foobar variable is assigned the type that SomeCustomClassName() returns.
To give you an idea of what I mean, the code below would generate a type error at compile time:
If you're still not convinced, take a glance at the following code:
This is valid Nice code, a language that compiles into Java class files and is totally compatable with the JVM and Java library. If a small Open Source project can achieve this, there's no reason Sun cannot.