I can guarantee that RoR isn't enough slower to demand that much more hardware.
Why does everyone assume that a lightweight web framework is a useful illustration of general purpose coding? I have many apps that run client-side. They do things like present geographical information and do image processing. RoR helps with this how?
Paul Graham (et al)
It is easy to pick one well-known and highly specific case, but that does not mean it applies generally.
Also, picking the views of someone who is encouraging the use of LISP (a very fast and mature language) to support the use of RoR (a very immature framework) does not help.
If you pick a slow language (no matter how nice) for general development your applications you will eventually lose out in the end. You are helping processor manufacturers and PC salesmen, and not your users and customers. Such applications have a tendency to grow and gain complexity and functionality. Sooner or later they hit a performance issue, and some at least partial re-write in something faster is required.
Think of it this way (unscientific, numbers merely illustrate my point):
It is totally unrealistic to think that the coding speed in a language is generally a major factor in the time for completion of any significant project. There are many, many more factors - designs, testing, feedback from users. If you are doing extensive testing of complex code, then the speed of a language can be pretty important in time-to-market.
Cost of extra hardware required by Ruby is pennies for every dollar saved in development cost.
I disagree. It depends entirely on the deployment situation. Having to potentially upgrade client workstations because someone has chosen an inefficient language for development is unacceptable.
It is also easier to maintain because when you revisit code a year later, you have to wade thru substantially fewer lines of code to remember what you were doing.
This is not always the case. Sometimes more lines of code can be more explicit about what is going on, so makes code easier to revisit. For example, it is well established that some apparently useful abbreviations (such as operator overloading) can potentially lead to serious problems understanding code later.
Managers like Java because Java was a language designed to be impressive to managers.
No. Java was designed to be safe for developers.
Writing Java code is painful, because you have to do so much repetition, and because Java goes absolutely apeshit if you don't play ball.
With a modern IDE, you don't have to repeat yourself. The point of Java is that, unlike C or C++, it does not go apeshit if you don't play ball. It safely shows you where you have gone wrong.
Then don't. Most good IDEs have 'folding editors' that can hide this sort of detail.
Please be an honest, intelligent person and admit that that's just silly!
But it isn't. It says exactly what the method does, and what it returns. This is a good thing, as not all methods that look like accessors need do only this.
The biggest thing I see is that Ruby fills gap for me between perl and Beanshell.
Then why not try Groovy? It runs on the JVM, has great integration with Java, is a lot like Ruby and has far more features than BeanShell (like closures).
When looking at who is "positioning" Ruby that way, it seems to be mostly Java users, actually - at times to belittle Ruby (there seems to be a few developers that feel threatened by the Rails framework) but mostly, it seems, as a basis from which to highlight shortcomings in Java. Ruby developers don't seem all that interested in these comparisons.
Sounds like you have not been following Slashdot much. Java developers aren't belittling Ruby. Many of us love it - in fact ruby runs on the JVM as JRuby. The noise seems to be coming from the Rails people who have 'rediscovered' ORM and use it in ways which some of us think has limitations and can give rise to problems. However, if you criticise Rails you are told you simply don't 'get it'. The fact that many of the ways Rails works have been been already tried before in Java and other languages and have been discovered to be less than perfect seems to be of no consequence.
The JVM was designed around the notion of Java as a language, whereas.NET was designed as a platform for multiple languages. That difference in approach changes how.NET competition and comparisons are formed.
This is, I feel, misleading, as can be seen by the fact that there are far more languages for the JVM (>200, including Ruby, Python, TCL, Smalltalk, Prolog, LISP...) than for.NET (20-30?)..NET looks like it was designed for multiple languages, but that is a bit of a marketing spin. In practice, it is tailored for procedural java-type languages - J#, C#, VB.NET. This is why Visual Basic 6 had to change so much before it could be a.NET languages. Languages that don't work in this way don't run that efficiently on.NET - just like with the JVM.
Re:Loving complexity for complexity's sake
on
Ruby Off the Rails
·
· Score: 3, Informative
2) Java needs a lot of RAM. If you try to run a java app on a smallish box, chances are it will start swapping. 3) Swing is Slow, it makes Java GUIs feel cluncky. SWT is much better for the user, it "feels" more responsive.
Both these are now way out of date. Java memory handling has been tidied up. As even a 'smallish box' these days is more than 128MB, memory really is not going to be a problem at all.
Swing is hugely faster these days, to the extend where it is often reported to be more responsive than SWT on some platforms (such as Linux). Swing is now by default OpenGL or DirectX accelerated.
Thank you for reminding me of one thing I just don't understand about Java.
It is nothing to do with Java. Java as a language does not deal with this. The memory options start with -X which means that they are specific to individual implementations of the VM.
Note that this does not mean that Java does grab all this memory - all it means is that it is not allowed to grab more. Modern VMs can release portions of this limit back to the OS while it is not being used by Java.
What you are doing is telling the VM that it is not allowed to interfere with the rest of the OS by grabbing more than a certain amount of maximum memory - this is a good thing.
So you're telling me that Java3D doesn't use the GPU? How could it possibly get any performance at all if it doesn't use the routines in the graphics card?
This is an interesting point. Java 3D implementations can use the GPU, but can also do most of the work themselves. It depends on the implementation. The point is that Java is perfectly fast enough to do most of the work itself if necessary.
I agree mostly with what you are saying, because I agree that languages need things like range checking and garbage collection.
Come again? This might be true for a rather small percentage of software, but I don't think it applies even for a majority.
I disagree. An example - I have written some software that prepares reports for printing through XML processing. Java can do this fast; Ruby can have speed problems in this area. The difference means an acceptable wait of a minute or two, or an unacceptable delay. I find this sort of thing turns up all the time.
They allow you to switch types dynamically, so that adding 5 to a character '3' results in an 8.
I would argue that this is the kind of thing that can lead to real problems later on with confusing code. Even Ruby won't allow such a horror!
What I disagree with somewhat is that getting things up and running as fast as possible is that important especially for internal use. I have seen far, far to many examples of where this approach was taken and the results were unsupportable. What matters for internal use where applications can be required to be up and supported for years is software engineering and design, not just a quick development cycle.
Also, I believe that what is involved in software development is so much more complex than just the development language that the differences between (say) Java and Ruby are not going to let you get to market 4 months early - both are good languages for reasonably fast development, but Java has the advantage of speed of execution which gives you a margin of safety for the future when it turns out your website actually has to do something substantial at some point.
If a total of 200 people are using the software, it's very reasonable to expect that the software would perform nicely on commodity software, even if it's not particularly efficient.
Depends what you mean by efficient. In the XML example I showed above, Java outperforms Ruby by more than an order of magnitude. With another example of software I have set up (Image processing) the difference is probably even greater.
I suppose that is becoming common. However, I would argue that you are then not actually programming in Java. You are programming in a variant language, which happens to be close to Java, and which generates Java.
This is good point, but it is wrong and in a way which I think is interesting. It used to be that code generation and manipulation in Java was indeed done in ways which required non-standard and editor-specific code. An example is GUI development, where special markup (usually embedded in Java comments) would be recognised by a specific IDE and would be useless in any other.
Things are mostly different now. Properties of Java classes such as getters and setters can be automatically handled by any modern IDE, and you can also manually edit them in, say, VI, without losing the ability to automatically process them. Code altered by one IDE is usable by any other. The same things works for persistence (EJB 3.0) - the information about code is stored in standard portable ways in Java code (annotations) that can be both hand-edited and are recognisable and changeable by any IDE.
2. The language you use can be viewed as a kind of domain-specific language. However it does not go all the way, and you are confined to whatever the IDE-makers decide to give you, unless you modify the IDE yourself.
So, as I explained above, Java has evolved (especially with the addition of annotations in Java 5.0) so this is usually not the case.
In your example, the JVM isn't doing the 3D processing, so it's kind of irrelevent how fast the JVM is
You should take a look at the Java3D technology White Paper which describes how this works. It contradicts you.
From the Java 3D FAQ:
"The initial Java 3D implementations are written mostly in the Java programming language but also take advantage of native methods to provide maximum performance."
One of the strengths of languages like perl/python/ruby is that they have simple interfaces to C, and many libraries are already written in C. So, a few simple lines of ruby code can do a lot of calculation very fast, even if Ruby itself is slow.
But again, this raises problems. One of my development areas is numerical work. The last thing I want to do is to have to mix languages. In Java I can do the whole thing (GUI, I/O, calculations) in one language.
But if I find that a project done in Rails is N times faster than a Java project of a similar nature I've done in the past, I'm hardly going to discount it based on the unseen evidence of someone on Slashdot.
Absolutely not! I wouldn't.
However, my point is that this may not be a general advantage.
Add to this the fact that there are many experienced developers who take the opposite of your position; Paul Graham, as I've already mentioned, and quite a few of the chaps at Google. I'd dig up more examples, but it's Christmas Eve and decidedly late.
Yes - I had heard of the Graham article. Where I am it is time to say Merry Christmas!
In my opinion, people should try out both languages and decide for themselves based on the results, rather than rely upon the experience of others. Wouldn't you agree?
Absolutely. All I get concerned about is the idea that because some projects are far faster with Ruby alone or with Rails, then this is a general advantage that this sort of development technique will have over Java in all circumstances for all scales of project. Time-to-market can involve a lot more than just coding speed. In some projects I have seen, CSS development was a key aspect - in that case the base language used would have been totally irrelevant!
Java's introspection is too unwieldly to be used often, and I'm unfortunately constrained by Java 1.4 - no generics for me!
I find Java 1.5 features to be enormously useful.
True; for simple problems code generation can be a solution, but it's a solution that does have limitations, and one that strikes me as horribly inelgant. Perhaps, though, it warrents some further investigation on my part.
To be honest, I find that code generation is actually best for more complex problems - the more that is automatically handled by the IDE the better, as the IDE can keep track of so much. Java code generation is usually not subject to the limitation of systems like Rails - it is not one-shot - it can be two way and adaptable. I agree it is not that elegant, as it is not a feature of the language itself.
if you don't need to maintain a public interface is there any reason not to just use the fields directly and only change them into getters/setters if you need to add a sideeffect given that modern ides (at least eclipse) make doing that change painless?
The thing is that so many useful Java APIs and tools want to have the ability to look at a field and even modify them on the fly (as in the fields of components in GUI tools). They do this using the getters and setters. As adding getters and setters is as simple as adding a field using a modern IDE, where is the harm?
Simply not true. 95% of software is developed in-house, by small development teams that don't exactly have time to spare.Managers care about productivity, about getting more features implemented in the same time. An extra server costs what, the same as hiring a programmer for a single month?
Performance is unrelated to development time and features.
Also, not all projects are server-side and can have performance boosted by additional central hardware.
But again it comes down to personal experience, not just of yourself, but of the people you have met and worked with.
No. It is based on actual evidence of how long projects take, not experience, not opinions.
With all due respect, my own personal experience contradicts your assertions.
You can say that your experience is different, but it doesn't invalidate my evidence. My evidence is based on the study of a large number of projects from many people.
I'm doubtful. I bump up against the limitations of Java every other day, and it seems like the only way you could get around such things is with an awful lot of code generation.
What you get with modern Java tools is not code generation as such, but generation of non-Java stuff. For example JSF generates JavaScript and high-quality HTML. JDO generates high-quality SQL, and JDO tools allow automated generation of schemas from Java classes (and the other way around). IDEs like Eclipse and Netbeans allow these things to be plugged together and handled in an automated way.
For instance, I was recently writing a Java class to convert an XML DOM into a custom object tree. This largely involved writing getters and setters, and for loops to iterate over NodeLists to pull out descendant elements. I couldn't help thinking that with Ruby, I could have written "has_attributes" and "has_descendants" methods, and generated the getters and setters and DOM handling automatically. Instead of my classes being 50 lines apiece, they could have just been 4. It would have taken me far less time in Ruby than I did in Java, because Java hasn't got metaclass-like abilities like Ruby or Python.
Good example; and in this case I would use code generation. I almost never write getters or setters in Java - my IDE does it (and then manages them) for me. If I look at the class properties in NetBeans, I only see the variables ('bean properties') - the code is all hidden and managed for me.
Don't get me wrong - I think Ruby is beautiful and I use it a lot. I just don't think that with the right tools Java is that much less productive for substantial projects.
You are right - it may be 'getting around' limitations in Java, but if it gets the job done in a maintainable way - why does this matter?
That's amusing... so if I take all but 64mb of RAM out of my PC and try to run netbeans... it'll be nice and fast?
Of course not! Where do you expect the operating system and GUI to reside?
What it means is if that you restrict the memory allowed to Java to 64MB, Netbeans will run fine.
Funny that, because I've tried it on several machines ranging from 256mb to a gig of RAM and they've all been slow enough to make me sit there grinding my teeth while the PC thrashes (and that's "thrashes" in the CS definition). I guess we just have radically different definitions of "slow" -- which where I came in.
Well of course it will thrash! Even a modern Linux running GNOME or KDE alone will have some trouble with less than 256MB.
As for thrashing on a Gig, I am sorry, but I simply don't believe it at all.
I have Oracle + NetBeans + Open Office running on a machine with only 512MB, and I have no performance problems. The same setup works fine on other machines - it is not just restricted to one specific set of hardware.
For me - slow means unusable - having to wait for compilations or GUI. I don't have problems.
Re:Loving complexity for complexity's sake
on
Ruby Off the Rails
·
· Score: 2, Insightful
Just recently I saw the project that was basically just a few web pages and it was realized as a tasty soup of custom MVC framework, JSPs, JSP tag libs, Velocity (by itself and (horror) inside taglibs), Spring and XML/XSLT thrown in for a good measure.
Just because some developers make bad choices does not mean that this is any fault of the language, or is a general fault of all developers in this language. Such messes can occur in any language - I have seen some real VB horrors.
Heh - sorry - a combination of not wearing my glasses and assuming usual slashdot comment standards:)
Then whose experience are you basing this upon?
Both my experience and the experience of many others whose projects I have had to review - how using different languages and technologies have worked for them. They have used a range of technologies, including.NET, JSF, PHP, PERL etc.
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.
I have no intention of insulting:)
I am not basing on personal experience - part of my job is to understand and review web (and other) development processes, and I have seen projects at a range of scales.
Slashdot Mirror
I can guarantee that RoR isn't enough slower to demand that much more hardware.
Why does everyone assume that a lightweight web framework is a useful illustration of general purpose coding? I have many apps that run client-side. They do things like present geographical information and do image processing. RoR helps with this how?
Paul Graham (et al)
It is easy to pick one well-known and highly specific case, but that does not mean it applies generally.
Also, picking the views of someone who is encouraging the use of LISP (a very fast and mature language) to support the use of RoR (a very immature framework) does not help.
If you pick a slow language (no matter how nice) for general development your applications you will eventually lose out in the end. You are helping processor manufacturers and PC salesmen, and not your users and customers. Such applications have a tendency to grow and gain complexity and functionality. Sooner or later they hit a performance issue, and some at least partial re-write in something faster is required.
Think of it this way (unscientific, numbers merely illustrate my point):
It is totally unrealistic to think that the coding speed in a language is generally a major factor in the time for completion of any significant project. There are many, many more factors - designs, testing, feedback from users. If you are doing extensive testing of complex code, then the speed of a language can be pretty important in time-to-market.
Cost of extra hardware required by Ruby is pennies for every dollar saved in development cost.
I disagree. It depends entirely on the deployment situation. Having to potentially upgrade client workstations because someone has chosen an inefficient language for development is unacceptable.
It is also easier to maintain because when you revisit code a year later, you have to wade thru substantially fewer lines of code to remember what you were doing.
This is not always the case. Sometimes more lines of code can be more explicit about what is going on, so makes code easier to revisit. For example, it is well established that some apparently useful abbreviations (such as operator overloading) can potentially lead to serious problems understanding code later.
Managers like Java because Java was a language designed to be impressive to managers.
No. Java was designed to be safe for developers.
Writing Java code is painful, because you have to do so much repetition, and because Java goes absolutely apeshit if you don't play ball.
With a modern IDE, you don't have to repeat yourself. The point of Java is that, unlike C or C++, it does not go apeshit if you don't play ball. It safely shows you where you have gone wrong.
Rails does not have all the answers and rails freaks always remind me of Microsoft employees promoting .NET
Absolutely. There is an attitude that if Rails doesn't do something you obviously don't need it, and 'don't get it' if you think you do.
I don't want to see that mess.
Then don't. Most good IDEs have 'folding editors' that can hide this sort of detail.
Please be an honest, intelligent person and admit that that's just silly!
But it isn't. It says exactly what the method does, and what it returns. This is a good thing, as not all methods that look like accessors need do only this.
The biggest thing I see is that Ruby fills gap for me between perl and Beanshell.
Then why not try Groovy? It runs on the JVM, has great integration with Java, is a lot like Ruby and has far more features than BeanShell (like closures).
When looking at who is "positioning" Ruby that way, it seems to be mostly Java users, actually - at times to belittle Ruby (there seems to be a few developers that feel threatened by the Rails framework) but mostly, it seems, as a basis from which to highlight shortcomings in Java. Ruby developers don't seem all that interested in these comparisons.
Sounds like you have not been following Slashdot much. Java developers aren't belittling Ruby. Many of us love it - in fact ruby runs on the JVM as JRuby. The noise seems to be coming from the Rails people who have 'rediscovered' ORM and use it in ways which some of us think has limitations and can give rise to problems. However, if you criticise Rails you are told you simply don't 'get it'. The fact that many of the ways Rails works have been been already tried before in Java and other languages and have been discovered to be less than perfect seems to be of no consequence.
The JVM was designed around the notion of Java as a language, whereas .NET was designed as a platform for multiple languages. That difference in approach changes how .NET competition and comparisons are formed.
.NET (20-30?). .NET looks like it was designed for multiple languages, but that is a bit of a marketing spin. In practice, it is tailored for procedural java-type languages - J#, C#, VB.NET. This is why Visual Basic 6 had to change so much before it could be a .NET languages. Languages that don't work in this way don't run that efficiently on .NET - just like with the JVM.
This is, I feel, misleading, as can be seen by the fact that there are far more languages for the JVM (>200, including Ruby, Python, TCL, Smalltalk, Prolog, LISP...) than for
2) Java needs a lot of RAM. If you try to run a java app on a smallish box, chances are it will start swapping.
3) Swing is Slow, it makes Java GUIs feel cluncky. SWT is much better for the user, it "feels" more responsive.
Both these are now way out of date. Java memory handling has been tidied up. As even a 'smallish box' these days is more than 128MB, memory really is not going to be a problem at all.
Swing is hugely faster these days, to the extend where it is often reported to be more responsive than SWT on some platforms (such as Linux). Swing is now by default OpenGL or DirectX accelerated.
Thank you for reminding me of one thing I just don't understand about Java.
It is nothing to do with Java. Java as a language does not deal with this. The memory options start with -X which means that they are specific to individual implementations of the VM.
Note that this does not mean that Java does grab all this memory - all it means is that it is not allowed to grab more. Modern VMs can release portions of this limit back to the OS while it is not being used by Java.
What you are doing is telling the VM that it is not allowed to interfere with the rest of the OS by grabbing more than a certain amount of maximum memory - this is a good thing.
but the JVM just wouldn't use it beyond the 1024M
well, it wouldn't by default. So you change it.
So you're telling me that Java3D doesn't use the GPU? How could it possibly get any performance at all if it doesn't use the routines in the graphics card?
This is an interesting point. Java 3D implementations can use the GPU, but can also do most of the work themselves. It depends on the implementation. The point is that Java is perfectly fast enough to do most of the work itself if necessary.
I agree mostly with what you are saying, because I agree that languages need things like range checking and garbage collection.
Come again? This might be true for a rather small percentage of software, but I don't think it applies even for a majority.
I disagree. An example - I have written some software that prepares reports for printing through XML processing. Java can do this fast; Ruby can have speed problems in this area. The difference means an acceptable wait of a minute or two, or an unacceptable delay. I find this sort of thing turns up all the time.
They allow you to switch types dynamically, so that adding 5 to a character '3' results in an 8.
I would argue that this is the kind of thing that can lead to real problems later on with confusing code. Even Ruby won't allow such a horror!
What I disagree with somewhat is that getting things up and running as fast as possible is that important especially for internal use. I have seen far, far to many examples of where this approach was taken and the results were unsupportable. What matters for internal use where applications can be required to be up and supported for years is software engineering and design, not just a quick development cycle.
Also, I believe that what is involved in software development is so much more complex than just the development language that the differences between (say) Java and Ruby are not going to let you get to market 4 months early - both are good languages for reasonably fast development, but Java has the advantage of speed of execution which gives you a margin of safety for the future when it turns out your website actually has to do something substantial at some point.
If a total of 200 people are using the software, it's very reasonable to expect that the software would perform nicely on commodity software, even if it's not particularly efficient.
Depends what you mean by efficient. In the XML example I showed above, Java outperforms Ruby by more than an order of magnitude. With another example of software I have set up (Image processing) the difference is probably even greater.
I suppose that is becoming common. However, I would argue that you are then not actually programming in Java. You are programming in a variant language, which happens to be close to Java, and which generates Java.
This is good point, but it is wrong and in a way which I think is interesting. It used to be that code generation and manipulation in Java was indeed done in ways which required non-standard and editor-specific code. An example is GUI development, where special markup (usually embedded in Java comments) would be recognised by a specific IDE and would be useless in any other.
Things are mostly different now. Properties of Java classes such as getters and setters can be automatically handled by any modern IDE, and you can also manually edit them in, say, VI, without losing the ability to automatically process them. Code altered by one IDE is usable by any other. The same things works for persistence (EJB 3.0) - the information about code is stored in standard portable ways in Java code (annotations) that can be both hand-edited and are recognisable and changeable by any IDE.
2. The language you use can be viewed as a kind of domain-specific language. However it does not go all the way, and you are confined to whatever the IDE-makers decide to give you, unless you modify the IDE yourself.
So, as I explained above, Java has evolved (especially with the addition of annotations in Java 5.0) so this is usually not the case.
In your example, the JVM isn't doing the 3D processing, so it's kind of irrelevent how fast the JVM is
You should take a look at the Java3D technology White Paper which describes how this works. It contradicts you.
From the Java 3D FAQ:
"The initial Java 3D implementations are written mostly in the Java programming language but also take advantage of native methods to provide maximum performance."
One of the strengths of languages like perl/python/ruby is that they have simple interfaces to C, and many libraries are already written in C. So, a few simple lines of ruby code can do a lot of calculation very fast, even if Ruby itself is slow.
But again, this raises problems. One of my development areas is numerical work. The last thing I want to do is to have to mix languages. In Java I can do the whole thing (GUI, I/O, calculations) in one language.
But if I find that a project done in Rails is N times faster than a Java project of a similar nature I've done in the past, I'm hardly going to discount it based on the unseen evidence of someone on Slashdot.
Absolutely not! I wouldn't.
However, my point is that this may not be a general advantage.
Add to this the fact that there are many experienced developers who take the opposite of your position; Paul Graham, as I've already mentioned, and quite a few of the chaps at Google. I'd dig up more examples, but it's Christmas Eve and decidedly late.
Yes - I had heard of the Graham article. Where I am it is time to say Merry Christmas!
In my opinion, people should try out both languages and decide for themselves based on the results, rather than rely upon the experience of others. Wouldn't you agree?
Absolutely. All I get concerned about is the idea that because some projects are far faster with Ruby alone or with Rails, then this is a general advantage that this sort of development technique will have over Java in all circumstances for all scales of project. Time-to-market can involve a lot more than just coding speed. In some projects I have seen, CSS development was a key aspect - in that case the base language used would have been totally irrelevant!
Java's introspection is too unwieldly to be used often, and I'm unfortunately constrained by Java 1.4 - no generics for me!
I find Java 1.5 features to be enormously useful.
True; for simple problems code generation can be a solution, but it's a solution that does have limitations, and one that strikes me as horribly inelgant. Perhaps, though, it warrents some further investigation on my part.
To be honest, I find that code generation is actually best for more complex problems - the more that is automatically handled by the IDE the better, as the IDE can keep track of so much. Java code generation is usually not subject to the limitation of systems like Rails - it is not one-shot - it can be two way and adaptable. I agree it is not that elegant, as it is not a feature of the language itself.
if you don't need to maintain a public interface is there any reason not to just use the fields directly and only change them into getters/setters if you need to add a sideeffect given that modern ides (at least eclipse) make doing that change painless?
The thing is that so many useful Java APIs and tools want to have the ability to look at a field and even modify them on the fly (as in the fields of components in GUI tools). They do this using the getters and setters. As adding getters and setters is as simple as adding a field using a modern IDE, where is the harm?
depends whose fun and morale you are talking about. I know many IT people who's morale is improved by allowing them to make others have less fun....
Simply not true. 95% of software is developed in-house, by small development teams that don't exactly have time to spare.Managers care about productivity, about getting more features implemented in the same time. An extra server costs what, the same as hiring a programmer for a single month?
Performance is unrelated to development time and features.
Also, not all projects are server-side and can have performance boosted by additional central hardware.
But again it comes down to personal experience, not just of yourself, but of the people you have met and worked with.
No. It is based on actual evidence of how long projects take, not experience, not opinions.
With all due respect, my own personal experience contradicts your assertions.
You can say that your experience is different, but it doesn't invalidate my evidence. My evidence is based on the study of a large number of projects from many people.
I'm doubtful. I bump up against the limitations of Java every other day, and it seems like the only way you could get around such things is with an awful lot of code generation.
What you get with modern Java tools is not code generation as such, but generation of non-Java stuff. For example JSF generates JavaScript and high-quality HTML. JDO generates high-quality SQL, and JDO tools allow automated generation of schemas from Java classes (and the other way around). IDEs like Eclipse and Netbeans allow these things to be plugged together and handled in an automated way.
For instance, I was recently writing a Java class to convert an XML DOM into a custom object tree. This largely involved writing getters and setters, and for loops to iterate over NodeLists to pull out descendant elements. I couldn't help thinking that with Ruby, I could have written "has_attributes" and "has_descendants" methods, and generated the getters and setters and DOM handling automatically. Instead of my classes being 50 lines apiece, they could have just been 4. It would have taken me far less time in Ruby than I did in Java, because Java hasn't got metaclass-like abilities like Ruby or Python.
Good example; and in this case I would use code generation. I almost never write getters or setters in Java - my IDE does it (and then manages them) for me. If I look at the class properties in NetBeans, I only see the variables ('bean properties') - the code is all hidden and managed for me.
Don't get me wrong - I think Ruby is beautiful and I use it a lot. I just don't think that with the right tools Java is that much less productive for substantial projects.
You are right - it may be 'getting around' limitations in Java, but if it gets the job done in a maintainable way - why does this matter?
That's amusing... so if I take all but 64mb of RAM out of my PC and try to run netbeans... it'll be nice and fast?
Of course not! Where do you expect the operating system and GUI to reside?
What it means is if that you restrict the memory allowed to Java to 64MB, Netbeans will run fine.
Funny that, because I've tried it on several machines ranging from 256mb to a gig of RAM and they've all been slow enough to make me sit there grinding my teeth while the PC thrashes (and that's "thrashes" in the CS definition). I guess we just have radically different definitions of "slow" -- which where I came in.
Well of course it will thrash! Even a modern Linux running GNOME or KDE alone will have some trouble with less than 256MB.
As for thrashing on a Gig, I am sorry, but I simply don't believe it at all.
I have Oracle + NetBeans + Open Office running on a machine with only 512MB, and I have no performance problems. The same setup works fine on other machines - it is not just restricted to one specific set of hardware.
For me - slow means unusable - having to wait for compilations or GUI. I don't have problems.
Just recently I saw the project that was basically just a few web pages and it was realized as a tasty soup of custom MVC framework, JSPs, JSP tag libs, Velocity (by itself and (horror) inside taglibs), Spring and XML/XSLT thrown in for a good measure.
Just because some developers make bad choices does not mean that this is any fault of the language, or is a general fault of all developers in this language. Such messes can occur in any language - I have seen some real VB horrors.
I said insisting, not insulting :)
:)
.NET, JSF, PHP, PERL etc.
Heh - sorry - a combination of not wearing my glasses and assuming usual slashdot comment standards
Then whose experience are you basing this upon?
Both my experience and the experience of many others whose projects I have had to review - how using different languages and technologies have worked for them. They have used a range of technologies, including
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.
:)
I have no intention of insulting
I am not basing on personal experience - part of my job is to understand and review web (and other) development processes, and I have seen projects at a range of scales.