Slashdot Mirror
Ruby Off the Rails
An anonymous reader writes "IBM DeveloperWorks has an interesting writeup on Ruby that takes a look at the programming language as a stand-alone solution rather than defining it in terms of Rails. From the article: 'Ruby on Rails is just one facet of what makes Ruby great, just like EJB is only part of the Java enterprise platform. Andrew Glover digs beneath the hype for a look at what Java developers can do with Ruby, all by itself. Ruby's syntax is quite different from that of the Java language, but it's amazingly easy to pick up. Moreover, some things are just plain easier to do in Ruby than they are in the Java language.'"
I love it how the Rails fanatics always take great personal insult at even the mere suggestion that code generation isn't its strong point. Even though, surprise surprise, the infamous tutorial video advertises just this very feature throughout pretty much the entire clip. It's like watching a little kid cry and stamp their feet at a grocery store trying to get their parents to buy them cereal.
Why was this modded up? The article doesn't even mention code generation. It compares Ruby and Java as generic development languages.
If speed and memory usage is your only criteria when choosing a language, why not use C or assembly?
ikkibr is a robot that looks for similar past articles and reposts highly-modded comments from those articles. See http://ask.slashdot.org/comments.pl?sid=171820&cid =14310500
they can't be arsed to rtfa, nor can I...
Why bother RTFA? The post title is Ruby Off the Rails. Which means Ruby without Ruby on Rails. So why did you even take the effort to copy-and-paste a post completely about Ruby on Rails?
Ruby is useless to me because it has no unicode support.
e st=all&lang=java&lang2=ruby&sort=fullcpu
In this shootout it was found that Ruby had lower memory consumption, but also ran much more slowly than Java:
http://shootout.alioth.debian.org/benchmark.php?t
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.
You just have to love java programmers making the easy more difficult. What I have learned in managing developers is that you have to constantly fight their desire to make things more complicated without a valid reason for doing so.
He's correct that certain tasks are easier in Ruby than in java, not to mention that the code is more readable. But he is missing in my opinion the most important part of Rails and that the ORM. Use scaffolding or don't use it. But if you bypass Active Record you're just making more work for yourself.
Man Holmes
Congratulations Java, you've finally proven yourself as the new Benchmark(TM). Enjoy a lifetime of groundless belittlement.
By the way, if moreover isn't on this list, it sure ought to be. Over.
Before I even consider Ruby: is it faster and less memory hungry than Java.
Yes on both counts. It's faster for you to write programs, and requires less of a learning curve.
Yes on both counts
No on both counts. There is as yet no high-performance VM for Ruby, and it's memory use is not optimised.
Having said that, Ruby is a wonderful language.
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?
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?
...is a good guy to write this sort of thing since he's been programming Java for a long time and has also branched out into "dynamic Java" things like Groovy. He's done a bunch of stuff on dbUnit (including a dbUnit chapter in Java Testing Patterns), too. So he's had enough experience with Java to know what's what.
I'm probably biased, though, since Andy also wrote the CPD Ant task.
The Army reading list
Why? The speed of C and C++ are hardly needed for most applications
This is the same excuse I have heard for decades when fans of a language try and 'justify' it's lack of performance. Sooner or later a lack of performance really does become a problem - if it wasn't then many Ruby developers would not be working on high-performance VMs for the language.
There are situations where performance doesn't matter, but this is not true for 'most' applications.
I really like Ruby, but I will find much wider use for it when it is truly fast.
I guess that if everything was coded in C/C++ we would have better performance because of those "platforms" and languages that are slow as hell.
There are a lot to choose from, but all those options are barely optimized unlike C/C++ compilers.
why spend more time developing a program in Java, when you could develop it faster in Ruby?
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.
There are alternatives - you can use both Ruby and Java together (JRuby works on the JVM). I think this 'mix and match' approach will be more widely used in the future.
That goes for any sane modern language.
I am trolling
As for Shakespeare, he couldn't even spell his own name, so he didn't care.
I've often heard comparisons of .Net to Java and for a while there it seemed to me like they were two separate but somewhat equal development environments. Now it seems that several languages/environments have been coming up (PHP/Ruby) and many articles I see compare it to Java or explain how it's competing with Java.
.Net doesn't seem to have such competition?
What does the future hold in terms of what environment will "come out on top" when Java seems to be compared to or even competing against so many languages while
I'm a big tall mofo.
The ruby crowd positions themselves as none other than mortal enemies of Java and anyone stupid enough to still be using that pathetic excuse for a language!
Ruby could be just an also-ran if it didn't have Java to kick around. After ten years of spotlight, it's not hard to find detractors. The real question is, can ruby be defined on its own terms, and not Java's? Doesn't seem like it so far, which isn't good news for longevity.
Also, what you're forgetting is that some programmers like the clarity of a well-defined class hierarchy, and Java's got that. Ruby has got some pretty muddy classes that try to do too much.
O lord, bless this thy holy hand grenade, that with it thou mayest blow thine enemies to tiny bits, in thy mercy.
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.
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.
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?
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).
Most of the things I love about Ruby are qualities that it inherits from the Smalltalk programming language. Typing objects instead of variables, everything is an object, object-based encapsulation, blocks as objects, polymorphic collections with enumerators, and the overall style of programming. Ruby is the first language since Smalltalk that I could really grow to love. It adds a lot that Smalltalk doesn't have, like regular expression syntax and better case statements, modues and mixins, and easier access to metaprogramming.
In some ways Ruby is a bit too dynamic - one of the strengths of Smalltalk is its simplicity and the predictability of your code. With Ruby it's easy to adopt a programming style that makes it difficult to predict what will happen when you do something in your code. Experienced programmers should be able to avoid those pitfalls, but I worry that some of the features will ecourage neophytes to create code that is difficult to maintain or understand.
There's no high performance JVM either -- of course, that depends on your definition of "high performance". For me it's "doesn't slow my machine to a crawl and use all the RAM" -- so in my case, no, there's definitely no high performance JVM.
Considering there has been a new release of Quake written in Java that is very much the same speed as the C version I feel it is reasonable to disagree.
With insufficient memory, almost any application (especially GUI apps) will slow to a crawl.
It is like arguing that C++ is slow because KDE is unusable on a 64MB linux box.
It does everything every other language
does but some things are easier and some things are harder.
Because its relatively new you get to rewrite a bazillion
lines of library code and API's that already exists in other languages.
Furthermore you will become even more multilingual than you used
to be so you can raise language critique to an even higher (f)art
form. One profound difference, for example, is that Booby uses braces
but they are reversed from C++ and Java i.e. the open brace is } instead of {.
I expect to see a whole book on the ramifications
of that alone.
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?
Actually, I am.... These applications contain things like image handling, grammar checking, spell checking, file parsing and transfer, and many sophisticated GUI features.
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.
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.
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.
Sure, as long as the IM is the only software running on your client's PC. However, most computers today are running multi-tasking OSes, and resources your inefficient software steals aren't available for other applications that might need them.
We just rejected a software upgrade at work, worth thousands to the vendor for our office alone, on the basis that while it ran fine in isolation, it wouldn't play nicely with other software on the machines under some indeterminate circumstances. That would stop us doing our jobs as well as we were before, so bye bye upgrade.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
How about the fact that Java apps are slow on a machine with 512Mb of RAM? How's that grab you, Java boy?
This is simply not a fact at all. I am using the Java NetBeans development evironment in 64MB. Works fine and fast. I am using Java games on my mobile phone.
How much RAM would recommend burning up on shitty apps that are still slow even when you do have gigs of RAM?
I guess that is why the newly-released PC game Tribal Trouble (written entirely in Java) runs on a 700MHz pc with 128MB memory.
Sorry, but the evidence suggests that whatever your personal experience, in general you are mistaken.
> Sooner or later a lack of performance really does become a problem
my limited history of languages says, a lack of performance is taken care of by compiler/VM writers when a market for such comes about.
C was unacceptable, and is now the standard for speed. C++ was way too slow now their are 100's of optimizers to turn off all the features that cause it to be slower than C.
Java started out with horrible performance, but this story talks many times about how fast it is, it has compilers now, and a hundred different optimized VM venders to speed it up.
I see no reason why Ruby would be slower as a language, except the lack of optimizers, perhaps due to the lack of time in the spotlight, and thus the lack of a market requesting it.
...the basic definition of being derailed?
I like Rails, but I love Ruby. The hardest part of learning Rails was (for me, an experienced Ruby coder) learning all of the things that you lose when you go to Rails. (One example out of many: in Ruby when you create a Hash you can provide a default function (rather than just a default value) to be used when an element is missing; with Rails, this generally doesn't work since the functions don't serialize).
Conversely, if you like Rails you really should explore standalone-Ruby to see what you are missing.
--MarkusQ
The chosen language is one of the things that the Consumer (maybe they not think the same, but, whatever) is most aware of. Let's see... The Consumer wants programs that are:
1 - Efficient (memory, processor, net, and disk usage,...)
2 - Bug-free
3 - Cheap
A low level language leads to 1, but not to 2 and 3. A good hight level language leads to 2 and 3, but not to 1. How well received your programs is depends only on how well it fits the Consumer's expectations (and how fat is your marketing bill), so the language matters.
Also, Ruby + Java doesn't lead to a nice combo. The ideal combinations are with languages of different abstraction levels, like Ruby + C, or Ruby + some excelent hight level framework for web pages, aka Rails. So bad Java doesn't combine well with low level languages.
Rethinking email
Oh, and BTW: you are lying about Quake.
Not just me; take a look at the recent 'Quake 2 ported to Java' thread posted on Slashdot.
I've seen the Java version... with hardware gfx acceleration, it runs about as fast as it used to on a pentium. Sure, you can run Quake in Java, now that we have several gigahertz of CPU power and a gig of RAM and a gfx hardware acceleration.
Sorry, but I saw a demo version years ago on much less that that.
Woo fucking hoo.
Well, you could post this, or perhaps discuss bencharks.
nor does it make Java suitable for 3d games... unless you happen to be a disingenuous Java fanatic.
Which is odd, considering new 3D games written in Java are being released all the time. here is a new one:
http://tribaltrouble.com/
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.
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 see no reason why Ruby would be slower as a language
True. Languages often do tend to speed up with time. But is if often hard to predict which languages do this. I used to use Smalltalk, and was constantly waiting for really fast cross-platform implementations. These never appeared.
Dyanamic type checking.
C/C++ is all static type checking.
Java is also static type checking (mostly).
Ruby/Perl/etc are dyanamically typed. This == slow(er).
In addition, Java/Ruby/Perl like to sandbox your program in (with good reason) so you cant go and fly off the end of the stack (or any other low level data structure) and explode into a million pieces. This also makes it slower.
Optimization can only do so much when you dont know what it is you are going to be getting.
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.
Also, Ruby + Java doesn't lead to a nice combo.
I don't understand why you said this, as they are already being used together, with JRuby on the JVM. Ruby has access to the features of the JVM (efficient threading) and Java class libraries and Java has access to the Ruby classes you produce.
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.
Ruby's conciseness is a by-product of its power.
In some respects, I agree.
The entire project could have done in days what had been done in weeks using Java tools.
I disagree. With some areas of a simple web project this is probably the case, although using visual design of JSF pages with JavaStudio Creator allows the production of data-linked web pages in seconds. There are also many new Java approaches to web development and data access that are far faster and more elegant than the traditional struts/JDBC approach.
With the right tools and a good IDE, Java web development can be fast. Not as fast as getting the initial pages up with Rails scaffolding, sure (although projects like Trails come close), but still fast.
Then I respectfully submit that you, sir, should have worked an opinion on Lisp and Haskell into your answer.
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.
I said insisting, not insulting :)
Then whose experience are you basing this upon?
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
http://groups.google.com/group/comp.lang.ruby/brow se_thread/thread/71e50a25544210a9/
I too like Python, but let's put this into perspective. This is an article about Ruby and Java, not about Python.
But that is a bit odd. To my mind, Python, Perl and Ruby are a pretty close family of similar languages. Java is rather different (mostly because of all the strict type checking, and the idea that putting everything in classes makes a language OO). Stuff like duck typing is central in both Ruby and Python.
Either compare different types of apple, or apples and oranges. But why would you compare one specific apple with one specific orange :-)
I believe posters are recognized by their sig. So I made one.
www.rubyholic.com
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.
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?
I believe posters are recognized by their sig. So I made one.
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.
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.
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.
I work as a java developer, but I still still have plenty of other languages in my toolbox. I have just started with experimenting with Ruby. The biggest thing I see is that Ruby fills gap for me between perl and Beanshell.
The programming hierarchy I tend to think of for my work,
1. Shell- Basic scripting. Glueing commands together.
2. Perl- More powerful sripting features, but not really OO.
3. Ruby- Still a scripting language, but designed around OO.
4. BeanShell- Good for quick glueing of java classes together
5. Java- When I need a full compiled application environment.
For me each language has its purpose and I use them where it best gets
the job done.
But again it comes down to personal experience, not just of yourself, but of the people you have met and worked with. With all due respect, my own personal experience contradicts your assertions.
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?
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.
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.
Java's JVM is on the RISC side of the spectrum, whereas languages like Ruby are not.
Typically a Ruby program will have fewer lines of actual Ruby code, and the rest of the work will be done in a C library. So, Ruby has less work to actually do.
Typically a Java program will be written in Java to much lower levels, and so have more actual Java code, so the JVM has to do more work.
In your example, the JVM isn't doing the 3D processing, so it's kind of irrelevent how fast the JVM is.
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.
Implementing libraries in C is seemingly much less common in Java.
Social scientists are inspired by theories; scientists are humbled by facts.
I mean, it isn't ALL about performance. Maintainability is probably the #1 coding related issue I hear about. Performance always matters. It just isn't always the primary concern. As a developer in internal and B2B IT systems to 8 years, performance is usually far down on the list. The hired help can wait an extra second for a system response to save development and maintenance costs.
Blar.
This may be more active and more complete: http://rubygarden.org/ruby?RubyUserGroups.
Java is the blue pill
Choose the red pill
Python better add the features that Ruby hypers won't shut up about or risk getting left in the popularity dust. It is not that Ruby is better, but if people keep talking about certain features then people will *expect* them because they hear about them, not necessarily because they really are a Silver Bullet. Hype works, I am sorry to say.
Table-ized A.I.
But that still doesn't solve the problem of repetition when parsing DOM elements. Java's introspection is too unwieldly to be used often, and I'm unfortunately constrained by Java 1.4 - no generics for me! Perhaps I should look for, or design, a program that will generate Java code from templates.
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.
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?
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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. If, in my experience, Ruby proves to be a far faster development language than Java, I'm not going to hum and say, well, what about those project managers who decided language wasn't a deciding factor.
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.
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?
Rails as has been said, is a framework. Ruby is the language, and all rails is just ruby with a design in place to make it easier. Some great tools for using rails are becoming available though, due to its increasing user-base. A lot of people are still "trying it, and going back to php" but its got a core user group now and that's what counts.
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?
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.
False.
Shop as usual. And avoid panic buying.
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!
Agreed. The main reason that Rails's limitations don't sink it for me is how easy Ruby makes it to extend / modify the base to suit your needs. I didn't like the way ActiveRecord serialized some objects--so I wrote my own serialization in a few dozen lines of code.
--MarkusQ
It's faster for you to write programs, and requires less of a learning curve.
Uhh, we're talking about computer memory, not developer memory.
Next!
There: Something at a specific location.
Their: Owned by someone.
Please make sure your english compiles.
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 the benchmark you site uses Ruby 1.9 which is unreleased, unfinished, unoptimized and not even beta yet. It was compared to a fully optimized Java release: Java HotSpot(TM) Server VM (build 1.4.2_05-b04, mixed mode).
Attacking a set of benchmarks based on softare versions is not helpful unless you supply measurements that support your point. And please note that Java 1.4.2 is not current. Scientific evaluation rather than hand waving, please.
When I say that Ruby drastically improves programmer productivity compared to Java
I'd accept this based on my experiences with Python. However I think you give that up in testing - especially as the size of the programmer team grows. Dynamically typed languages are subject to more runtime errors than statically typed languages, and run time errors are more expensive to test for and to catch.
I have not yet detected a single memory leak in my c++ apps using runtime tracers after I started using smartpointers (boost) and a c++ lint checking.
That contravales most opinions regarding smart pointers - while they reduce memory management problems in C++, reference miscounts and circular references in smart pointer based code still leave C++ programs more vulnerable to memory leaks than programs with built-in GC implementations that are more robust in handling these conditions.
At my university we currently have a software project running. Or rather, it's part of the curriculum that during basic studies every CS student has to do a one-year project, which changes every year. Our assignment is to redesign the IEEE Reengineering Bibliography (how fitting) using Java. The best solution is to be used by the IEEE - no wonder, since the old site was put together by the lecturer responsible for the project (he also maintains it and is responsible for 90% of the entries. It's not a very popular site). Put together rather badly, I might add - the site went live in 1995, wasn't updated design-wise a single time (do you remember what passed as good site design back in 1995? The site barely lives up to that) and on the server side is a horrible hodgepodge of awk, sed, CGI/C++ and Bourne shell scripts. Using CVS to backup the database, which happens to reside in two text files, one being a BibTeX document and the other one apparently in a custom format.
I'm not saying that awk, sed, the Bourne shell, C++, CVS and BibTeX are bad, but mixing them in a live application creates something vaguely resembling a Rube Goldberg device. Ugh.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
No, verbosity like this serves no purpose whatsoever. It's just like writing: if you want those that come after you to understand it, write clean, spare code with useful symbol names and use comments on the non-obvious parts, for chrissake - that's what they're for. In fact, verbosity does just the opposite - it encourages vast amounts of cut-and-paste monkeywork, and all the attendant bugs and inefficiencies that come with it.
I've seen enough cryptic, overterse code that was incomprehensible, but I've seen just as many 2000 line monster modules that took a week of tracing through to understand what was going on. What's worse, the more verbose the code, the harder it is to modify and extend it, or - god forbid - try to use it for something else.
It's not elitist to want to write as little code as possible - it should be your goal. I have a lot of work to do and not a lot of time, and I do not want to write 20 lines where 3 will do. If you have to resort to tools to autogenerate gobs of code to use your language, you're doing something very wrong.
Excessive verbosity is great if you're a) overly anal retentive, b) not really a very imaginative programmer, or c) getting paid by the hour.
Oh, and Sun's primary contribution seems to be shovelloads of methodolgies and APIs starting with the letter 'J', thrown aperiodically at the community in the hopes that some of them will stick, most of which are deprecated or outright disappeared when some new strained coffee metaphor comes out saying "No, *this* is the Right Way To Do It!"
What if life is just a side effect of some other process and God has no idea we exist?
This is the same excuse I have heard for decades when fans of a language try and 'justify' it's lack of performance.
:: Pot:Kettle
Java:Ruby
I just googled for a Haskell implementation in Java. I'm in the development team of an (admittedly comatose) project to create a Java-based game RAD environment (we are (were) aiming for something like the RPG Maker XP, if you happen to know it) and one of the key features is "script in any language you please (as long as it's on the list)". Java interpreters for script languages like Rhino or JRuby would plug into a defined interface and the scripts would be saved with metadata indicating dependencies like the interpreter version. This vening I thought how cool (although mostly impractical) it would be to script a game in Haskell.
Although, of course, for math-heavy games (economy simulations?) Haskell would suddenly turn into the epitome of elegance. I think that Haskell only really shines when it's used to do stuff that would be expressed as formulae anyway. But it really does shine, then.
I'm sorry that I can't offer deeper insight into Lisp, but I could make a generic comment about parentheses.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
" 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."
But when ran on a machine already bogged down (say, a K6-2 350mhz like my parents run, with some spyware thrashing resources enough as is, then that becomes the difference between a tollerable 1second and an intollerable 40 seconds.
Just because it doesn't matter to you doesn't mean it doesnt matter.
For the record, I do most things in perl, but most of what I do is not desktop apps, its stuff ran on a server where I know if its taking too long or not. Desktop apps are a whole different ballgame. Some would say eclipse is slow but because of how fast modern machines are it doesnt matter. They say the same about azureus. Now try running them both and see what happens to usability. Just because you have the resources doesn't mean you should throw them away.
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
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++!
;)
Someone better tell the Gentoo guys to redo Portage in C++. Obviously the current implementation does not have the performance neccessary for the critical job of zero-latency package management.
Of course I'm kidding. No one would develop in a language like C++, which was developed for schools in order to make learning real languages like PHP, Visual Prolog or Objective-Befunge easier.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Also, Java is semi-compiled while Ruby is purely interpreted, making it even slower. However, if computers keep getting faster as they have been I doubt that Ruby's performance will be much of an issue in the future.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
At least he provided an interesting fact about Shaecspir.
Its on par with C for speed.
I love Ruby and Python, but in the general discussion of dynamic languages, be sure to mention Tcl. Tcl was heavily supported by Sun, until Sun decided to throw its full weight behind Java. Between Sun, AOL, and several other companies over the years, the language had enough development money poured into it to make it easily in the same league as Python, Perl, Ruby, and even Java. I realize that the topic here is Ruby, but since the general discussion has drifted to dynamic languages in general, Tcl should also be mentioned. If anyone is interested in learning more, I think the best place to start is the Tcl'ers Wiki: http://wiki.tcl.tk
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?
Social scientists are inspired by theories; scientists are humbled by facts.
Can someone mod this thread +5 Friendly?
/. - perhaps it's the holiday spirit.
Most civil discussion I've ever seen on
"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."
Then why are you developing in java and its huge memory and cpu costs? To do anything in such limited language, you have to load tons of class libraries, running in the same runtime. By constrast, ruby has many good specialised data types and operators builtin, which do away with many uses for libs, and its libraries are thin wrappers to C compiled stuff running natively...
"There are alternatives - you can use both Ruby and Java together (JRuby works on the JVM)."
It sounds stupid to me to build a runtime on top of another runtime, if the goal is performance.
If your users demand performance above anything else, i suggest you deliver your software without a slow, bulky runtime and have good, experienced programmers who can recognize bottlenecks and fix them, rather than rely on stupid compiler optimizations for things that can't be optimized (i.e: bad algorithms ). Of course, you have all the time in the world in your hands, since performance comes above all...
I don't feel like it...
True, although thats only on startup. Once its parsed the whole program its all binary anyway.
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.
Come again? This might be true for a rather small percentage of software, but I don't think it applies even for a majority.
What I find funny is that I remember these same arguments being made about C because it was so inefficient and "high level", and how assembler was the way to go for performance reasons.
Most software development is for fixed-function, limited, internal use by a company, organization, or small niche marketplaces. In these environments, getting feature N to work quickly is very important, getting it to work rapidly is marginally important, and the language or platform is irrelevant.
High-level languages like Ruby, Perl, and PHP (and possibly Java) allow developers to focus on getting the job done quickly, without spending as much time worrying about things like memory management. They allow you to switch types dynamically, so that adding 5 to a character '3' results in an 8.
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. In this space, all that matters is that it works, and is developed as quickly and cheaply as possible. The cost of development is typically much, much higher than the cost of the total hardware involved - so who cares if it takes a $10,000 server to make it work, if it saves $120,000 in labor expenses for development, and gets to implementation 4 months earlier?
Where's your smart money going to go?
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Managers like Java because Java was a language designed to be impressive to managers. 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.
You know what I want out of a language and application framework? I want to be able to repeat myself as little as possible, have a simple codebase with built-in hooks for unit testing, be able to run my code anywhere, and be able to produce a working program in a rapid fashion. Java doesn't give me this, and I'm not sure if Ruby does just yet, but it seems a lot nicer.
I've just started looking at Ruby, and insofar, I'm impressed -- it feels like a mix of Perl and Python, with a dash of Lisp thrown in. It could certainly be faster (and the next VM looks very nice), but overall, the language has a very good design, and it is a joy to work with. I feel the same way I did when I discovered Perl (4), only now I get all the OO goodness that feels so hacked-on and kludgy in Perl, but without the indentation madness of Python.
--
I Hit the Karma Cap, and All I Got Was This Lousy
You're thinking of the "Take a ride on the Reading" Chance card. I instead find myself humming "Going off the rails..." line from Ozzy Osbourne's "Crazy Train" when reading about this subject.
I grade homework, people who 'write comments on the non-obvious parts' are always lacking enough comments for me to quickly understand what they did (even though I wrote the assignment!).
You should be documenting at least once per method/function, and I tend to find it a good idea to put a comment above every block larger than 3 lines long.
Sean
I live in a giant bucket.
I'm sorry. I've probably written 200kloc of Java in my life. I have never noticed this painful repitition? Where is it?
Thanks,
Sean
I live in a giant bucket.
Given the number of posts in java.net and slashdot on how Ruby is the greatest thing of all (and no mention at all of any negative side) I start wondering why is Ruby desperate to move Java programmers from Java to Ruby
Personally I do not trust a language that has no negatives sides (or at least the Ruby people seems to think so), until it becomes clear what is the other side of Ruby I am not going to use it.
(Yes, I have visited the Ruby website)
Miranda has a more readable syntax than Haskell. Haskell also has the largest mandatory toolchain of any language other than the .NET family.
StringTokenizer st = new StringTokenizer(s);
Free Java games for your phone: Tontie, Sokoban
What it means is if that you restrict the memory allowed to Java to 64MB, Netbeans will run fine.
Thank you for reminding me of one thing I just don't understand about Java.
Back in the nineties, I converted from CP/M to become a Mac-fanboi. There, I admit it. (I have since recovered. Now I'm a NetBSD-weenie.) At that time, we Mac-folk where often teased with a particular working mode which seemed ridiculous to Windows and Unix people alike. (And in retrospect, they were right. Of course, at the time I would never have admitted that.)
Every Mac-application had two "static" configuration parameters: The minimum memory size it could work with, and the maximum it was allowed to use. If for some reason the max was too low, say, if you suddenly wanted to create a large image in PhotoShop, then you would be told, "sorry not enough memory", and then you could quit, fix the Max-size, and start again. If you had a suite of programs running at all times, you might also have to adjust the sizes of those to fit in your available memory.
Today, Java VMs come with the same usage pattern. Recently we had to set -Xmx=1536M for our J2EE web portal at work. Naturally that causes downtime. Before that it would thrash under heavy load, and die with heapdumps due to the garbage collector giving up. (Now, I know that this is typically an indication of a problem in the application, but that is not the point here: the machine had enough memory, but the JVM just wouldn't use it beyond the 1024M it was previously allotted, and it works fine today with 1.5G.)
I wonder why we have to live with that in this century. It was already a bad idea in the last.
Oh, to be on-topic: I suppose Ruby, like Perl, will happily consume all the memory you have, no questions asked.
+1 for Ruby on this assumption.
-Lasse
Ah, well, we're in agreement there! I'm a firm believer in using the right tool for the right job, and as you say, sometimes Ruby isn't the right tool for the job. Java does have some neat libraries and APIs, and alternative languages for the JVM like Nice, Groovy or Scala, can make one's life quite a bit simpler. You also get the performance advantage, which is always nice.
Here too. Merry Christmas! :)
Ah. The joys of previewing and still missing silly mistakes. And although English isn't my native language, I don't think that counts for much of an excuse.
"where often teased with": read "were often teased about". Or something like that anyway.
-Lasse
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.
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. I'm not saying that is a bad thing, on the contrary. It also has a strong precedent, for instance using yacc generated parsers with C. I can think of two negative things to say about it, though:
1. The language you use is probably not portable beyond the IDE, by definition. If I were to edit your code in vi or emacs, I would not be able to use your language. At the end of the day, it's just a hack to circumvent Java's (and Java beans') design flaws.
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. Of course that is the original SmallTalk toolbox idea, illustrated in the Taj Mahal cartoon in the August 1981 issue of Byte Magazine, and with open-source IDEs like NetBeans and Eclipse it becomes a possibility. (Of course some lisp weenies will tell us that they have been doing exactly that since forever, or at least since lisp was invented. But I don't lisp, although I am known to st-st-stutter sometimes.)
-Lasse
However, don't take my word for it. Paul Graham (et al) suceeded in his startup because of this very thing. He thinks (and I tend to agree) that programmer time is worth more than computer time.
Jeremy Logan's Website.
Still, the loading time can be annoying. It is when you're working with many small scripts. At least Ruby isn't as bad as PHP, which I currently use as a shell scripting language (and which suffers from a hearty delay between the issuing of the command and the starting of the script).
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
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.
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.
If I have a web app with thousands of clients, wouldn't I need performance? Some apps need performance, some don't. The process of a language maturing takes years, and speed of development is the most important criterion, but performance shouldn't be ignored.
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.
OK, so you forgot to tell the JVM how much memory it could use on the machine... Should I start to cry now?
It's still so much better then having the JVM kill the whole machine because someone forgot to let objects get out of scope.
Look at it this way: at least your machine was still running fine.
Suppose you only had the 1G to spare and it went to 1.5Gb: your application wouldn't be running anymore either. Do you know what trashing is? It's not very nice!
-1 for the script kiddy languages as far as I'm concerned: bad behaving processes should go way, not hang around.
Just my 2 cents,
Matt
News about the Kettle Open Source project: on my blog
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.
> I can still do that in Java with reflection:
Right, you can do everything in Java that you can do it in Ruby; they're both Turing complete. But you're fighting the static typing when you do it in Java - which is why calling a method in Ruby is just foo.send("bar"), and in Java it's 40 lines of method lookup and exception catching.
The Army reading list
Actually in an array (it doesn't work so well in a hash) you can just do this:
puts array
That's it.
Well in Python you can just do
print array
Oh, wait, that's 1 character more. That's it, I'm switching to Ruby.
Unless the user is letting the instant messenger run in the background while he does something else. Multitasking means that the IM program can't just assume that it has the machine all for itself, since the chances are that it doesn't.
The user might not notice if a function takes 40 milliseconds instead of 1 millisecond when that's the only program running - but if he will most certainly notice if he has 10 background applications doing this while he's trying to do 3D modelling in the foreground. Now, replace CPU power with memory, and consider the difference between 10 applications taking a megabyte each, and 10 applications taking 40MB each ;).
If anything, the latest 3D game might get away with worse performance problems than IM applications, since no one runs multiple 3D games in parallel, people expect anything but newest machines to choke on new games, and the furious competition between processor and 3D manufacturers ensures that pretty much anything will run acceptably after a while.
People expect games to take lots of horsepower. On the other hand, no one expects an IM application to take a 100MB of memory and 100% of 1GHz Athlon...
Someone mentioned a Quake engine reimplementation made with Java; I quess I'll go look it up and test it.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Sit down and actually USE any of the following:
/*** do not edit **/ blocks and such. Except for jbuilder. It rouddtrips swing. ) For example... you add your object attributes and then rightmouse -> refactor -> 'generate accessor methods'. And blink... you have properly formatted, commented, and scoped getters and setters. Need to change the name of your attribute? Just rightmouse -> refactor -> rename. Change it's name and the accessor methods are changed and all uses of them in your code are changed. Refactor a class name? Same deal.
JBuilder (for Swing apps), eclipse, netbeans, intelliJ, etc.,etc. etc....
They all have built in refactoring and code generation utils that do NOT mark up the source in any unusual way. ( The main exception is the UI tools. Most have
Now of course this is a feature of the IDE and could/should be applied to any language your using. But the fact that the IDE handles this sort of thing means that I don't care about the verbosity of any language I might work with. I don't care about saving keystrokes when writing code since a good ide will save me that effort and come on... most of your time coding is NOT typing.. it's thinking about the problem.
The article is the first time I've actually seen any Ruby. Looks nice... but some of the examples are quickly turning into code soup on the level of perl or c++. I don't want to be the compiler and have to decipher some compact syntax.... verbosity is not necessarily a bad thing. I would argue that for code maintenance it's better to be more explicit than not.
Of course java has it's faults... But the notion that the syntax of a language needs to be super efficient for people using vi and emacs is kinda missing the point of what makes good maintainable code.
Seconded. Took them long enough to put it in, though :(
Agreed to an extent, but there are limitations to what code generation to achieve. Simple templates are trivial to accomplish via code generation, but code generation doesn't offer the power of the macros in Lisp, nor the dynamicness of Python and Ruby's metaprogramming functionality. It's also somewhat more unwieldly, though I do suppose a good IDE can make code generation usage transparent to the user (just a shame I've got used to using Vim; the text editors of IDEs always seem too basic in comparison).
For most problems, such power isn't needed. But for complicated situations, it can prove to be quite a boon. I suspect it rather depends on what you're developing; certainly there are situations where Java is the preferred language (though I'd prefer to create my class files in Nice, myself), but I'd argue that there are also a lot of situations where Ruby or Python would be ideal for the job in hand.
Depends if you run into a C fallback or not, most of the times you do not. Here is an example, PHP is the perfect example of what you mentioned, now the Caucho guys have moved PHP onto resin into a JVM it got a speed boost of 6x over a plain lamp configuration on the code level. (Most of the performance of the typical webapp goes down the drain during db access)
> Java is semi-compiled while Ruby is purely interpreted
when I started working with java, it was all interpreted (well, I would consider the byte code format to be interperted.) Their is nothing stopping Ruby from following the same path as java. IE. could be used to write stand-alone applications, that may or may not be called from a web browser (again the same path as java.) to get = to > performance at a simular footprint, and to be a language used to build compiled librarys to be called from self.
Sheesh... xMx 1563 for your portal, you guys should seriously check your code, I have been running a portal server on plain 128m for years with no downtime at all.
To comment on this even more, most of the java needs so much ram situations I have seen the last few years came from the typical we allocate as much as we need without a second though patterns, and then everything was blamed on Java. Reading a 500 meg data file into ram before dumping it into the DB and then blaming it on java was such a typical situation! Those patterns often are very similar, and often are caused by some whiz guy who thinks he knows everything better than the rest of the world!
class Hello { public static void Main(String[] arg) { System.out.println("Hello World"); }
versus:
print "Hello World\n"
Of course it's a trivial, useless example - except it only gets worse from here. It doesn't matter if the IDE generates everything for me and can manipulate the AST correctly and transparently when refactoring - I don't want to see that mess.
Interestingly enough, many people seem to prefer C syntax if(){}else{} for blocks, because it saves a few keystrokes, although many studies have shown that Ada-like "if then else endif" syntax (or the variant used in Ruby) is less error-prone, and IMO more readable. (And don't give me any crap about how noone makes mistakes with that anyway, so it doesn't matter, and the IDE prettyprints your statements and does everything for you etc. I have seen mistakes happen from this too.)
As for using IDEs: I'd like to, but for some reason despite being written in Java and therefore allegedly portable, at least Eclipse seems to come with a platform-native startup-program that I haven't had much success with on NetBSD so far, despite having compiled working native NetBSD versions of Sun JDK 1.4 and 1.5 myself. I will get around to it eventually.
Oh, and could you please show me an example of one of those "properly formatted, commented, and scoped getters [or] setters." I somehow strongly doubt that an IDE can automatically generate any meaningful comment for a getter or setter. The best I can come up with is this piece of garbage (carefully adapted from this):Please be an honest, intelligent person and admit that that's just silly!
-Lasse
I haven't explored Ruby much, but as I read through each of the features touted the article, one thing that came to mind was how similar many of them are to Perl both in syntax and in usefulness. (Background: generally I use Java at work and LAMP(erl) for managing my own websites.) So let's do a little closer comparison of the three languages. If any Ruby experts want to jump in and correct anything, I'd be interested in hearing it.
Syntactically, Ruby seems to be much closer to Perl than Java - this feels like a apples-and-oranges article. I know Java and Perl both compile to bytecode, both approach native speed in practice, and both have a extensive set of libraries. I would only assume that Ruby is the same.
I'm sure I'm missing many of the intermediate-to-advanced features of Ruby, but what would make me choose Ruby over Perl? Anyone else feel like diving in?
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.
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.
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.
Managers like Java because Java was a language designed to be impressive to managers.
Bullshit. Managers like Java because it helps their team achieve their business objectives better than the other languages you describe.
On your own dime, go jump in leaf piles, run through a field of flowers, play with Python, Ruby or whatever is good for your spiritual wellbeing, but when you're working to pull a paycheck, you don't get to put your own flights of fancy before things which make your team (not you as an individual performer, but your team as a whole) more effective in achieving business objectives.
Ruby is nothing like Java! Granted, the two languages to both have frameworks for web applications, but this article, of course, has nothing to do with web applications. Ruby as a language should be compared with Perl, Python, Smalltalk, etc. Java was designed for completely different things. It's apples to oranges.
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.
The article is the first time I've actually seen any Ruby. Looks nice... but some of the examples are quickly turning into code soup on the level of perl or c++. I don't want to be the compiler and have to decipher some compact syntax.... verbosity is not necessarily a bad thing. I would argue that for code maintenance it's better to be more explicit than not.
If you think Ruby looks nice, but is too much of a "code soup", you definitely should take a look at Python. It has most of the advantages, but is IMHO, considerably more clean. Creator or Ruby likes Perl, and it shows.
I must conclude that you don't think
/* increment i */ is silly either.
i++;
Let's just leave it there, then.
-Lasse
I must conclude that you don't think
/* increment i */ is silly either.
i++;
Let's just leave it there, then.
Why conclude that? That statement (at least in a language which does not have operator overloading) is self-evident.
However, in the example of a setter or getter, what happens is not self-evident, as the method may end up doing more than just setting or getting.
So, simple comments at a method level, even if they indicate that somethings is just a setter or getter, are certainly not redundant.
Bullshit. Managers like Java because it helps their team achieve their business objectives better than the other languages you describe.
Hmmm, this attitude sounds somewhat familiar. Oh yeah, Paul Graham has written about it at length in this essay:
The pointy-haired boss miraculously combines two qualities that are common by themselves, but rarely seen together: (a) he knows nothing whatsoever about technology, and (b) he has very strong opinions about it.
Suppose, for example, you need to write a piece of software. The pointy-haired boss has no idea how this software has to work, and can't tell one programming language from another, and yet he knows what language you should write it in. Exactly. He thinks you should write it in Java.
Why does he think this? Let's take a look inside the brain of the pointy-haired boss. What he's thinking is something like this. Java is a standard. I know it must be, because I read about it in the press all the time. Since it is a standard, I won't get in trouble for using it. And that also means there will always be lots of Java programmers, so if the programmers working for me now quit, as programmers working for me mysteriously always do, I can easily replace them.
On your own dime, go jump in leaf piles, run through a field of flowers, play with Python, Ruby or whatever is good for your spiritual wellbeing, but when you're working to pull a paycheck, you don't get to put your own flights of fancy before things which make your team (not you as an individual performer, but your team as a whole) more effective in achieving business objectives.
Horseshit. Python and Ruby and Lisp are real-world workhorses that don't need tens of millions of dollars in hype to be successful. For instance I have tens of thousands of lines of Python code out on the field doing real work, 24 hours a day, seven days a week for really demanding clients, including governments and advertising agencies. In one case, I finished a project in a third of the time it took three Java programmers - and mine was smaller, faster and more maintainable for the guys who took it over. Time is money and succinctness is power in software development and Java doesn't make the cut on either. Oh sure, it's a great tool to allow development by the lowest common denominator (money quote from James Gosling) but the really smart teams I know despise it for the ugly hack it really is. When I expressed this opinion in a column for a local computing mag, I was assailed with all kinds of outraged squeals from the local Java gurus. But none of them could answer my points honestly.
If readers disagree, answer honestly with words rather than modpoints. I've tried Java. I really have. I found it ugly, slow, anal and seriously limiting to work with. And I don't seem to be allowed to fix flaws in it either. That's not good.
--- Hot Shot City is particularly good.
Because it wasn't done at the time XP was released (2001). Since it was released, they have, however, made it available as an optional component via Windows Update. They will of course be including it with every new operating system: the Compact Framework has already been included since Pocket PC 2003, it's in Server 2003 and it sure as hell will be in Vista.
As a developer of consumer software, I'm loath to burden my 6 MB download with the 20MB millstone of the .NET framework
Many of the smaller Java applications don't bundle the JVM either (although some include it as an option), and it's worked out just fine for them. If a user can download your software (if you're on a slow modem, 6MB is nothing to sneeze at), they sure as hell can download one (1) executable file and go through the painful process of double-clicking it to install the framework. I'm pretty sure if you can't walk your grandmother through that, you won't walk her through installing your software, either.
Oh. It occurs to me that you may have missed that we are talking about automatically generated accessor functions:
... }
... }
For example... you add your object attributes and then rightmouse -> refactor -> 'generate accessor methods'. And blink... you have properly formatted, commented, and scoped getters and setters.
I agree that a nontrivial accessor might benefit from a comment, just as a nontrivial statement, but it doesn't follow that therefore all accessors or all statements (including my increment example) deserve comments.
Please explain to me how an automatically generated (thus presumably trivial) accessor function can have automatically generated comments that are not absolutely trivial. I agree that an accessor function could be bestowed with additional functionality, but then:
- It might cross the border where it ceases to be just an accessor function, and should be named according to its behaviour, rather than getFoo/setFoo.
- You provide the behaviour and the comment yourself.
Perhaps in Java 6 we'll see something like:
class Foobar { public Foo foo;
being taken as shorthand for:
class Foobar { private Foo foo; public Foo getFoo() { return foo; }; public void setFoo(Foo newfoo) { foo = newfoo; }
and of course permitting you to make foo private in a subclass if you provide public accessor functions. (Presumably with additional behaviour.)
Also, naturally, accessing foobar.foo would be understood as foobar.getFoo(), and foobar.foo = bar as foobar.setFoo(bar).
If I remember correctly, Dylan does accessor functions more or less like this. Probably other languages do too. Ruby is arguably one of them. +1 for Ruby.
BTW, I have read too much buggy, badly commented code, to trust any comment. Semantically significant annotations - such as Eiffel invariants, pre- and postconditions - would be a different matter.
-Lasse
Oh. It occurs to me that you may have missed that we are talking about automatically generated accessor functions
... }
... }
No, I hadn't.
Please explain to me how an automatically generated (thus presumably trivial) accessor function can have automatically generated comments that are not absolutely trivial.
It can't, but that is not the point. The trival comments indicate that the method is doing something trivial, as against something non-trivial (see below).
I agree that an accessor function could be bestowed with additional functionality, but then:
- It might cross the border where it ceases to be just an accessor function, and should be named according to its behaviour, rather than getFoo/setFoo.
I don't like this idea, as it breaks encapsulation - it is perfectly acceptable for a Java class 'bean property' (indicated by the presence of setXXX or getXXX methods) to not actually exist as an instance variable in the class. What may look like a simple accessor is actually getting a value by some other mechanism. However, to the code that uses this class (or looks at its properties by introspection) this is nicely hidden. This allows things like proxy instances to work neatly - the apparent accessor functions actually divert to another instance to retrieve or store values.
Perhaps in Java 6 we'll see something like:
class Foobar { public Foo foo;
being taken as shorthand for:
class Foobar { private Foo foo; public Foo getFoo() { return foo; }; public void setFoo(Foo newfoo) { foo = newfoo; }
I really hope not, as it would prevent things like I have mentioned above working.
If I remember correctly, Dylan does accessor functions more or less like this. Probably other languages do too. Ruby is arguably one of them. +1 for Ruby.
This is potentially limiting, as it tries to make accessor functions limited and special in what they do.
Using accessor functions only as ways to access instance variables in this way is far too restrictive. I think Java's more general use of these functions is more powerful, and this explains why you do need comments - to explain that this really is only a simple variable accessor!
Aside from the common and seemingly unavoidable tasks of generating HTML and SQL, why would one need to generate code in a high-level, multiparadigm language? I've seen very few instances of this need that didn't result from either a weakness in the language or toolset (*cough* old-style VB) or a design issue. It's the job of the toolset to allow you to express business logic in a clear, readable, and maintainable way. It's the job of the developer to do so. And frankly I have to agree that usually the tools do a better job of allowing expressive code than average developers do to actually write it.
Nonaggression works!
Care to name any examples of the advantages of Python over Ruby, or just rely on sweeping statements with nothing to back them up? I said that Ruby has a readability advantage over Perl and a writability one over Python. Being able to format your code how you want is a good thing.
I wasn't advocating it for all-around use. If I were doing any of the things you mentioned (image processing and the like) it simply would not make sense to do it this way. However my argument wouldn't apply. It'd (more than likely) actually take longer to develop this type of software in what is, essentially, a scripting language designed for rapid web development.
I wasn't claiming that that Ruby (or RoR) is an end-all language/framework... just that in certain instances rapid development is worth a lot more than a few clock cycles. In this case I CAN use Paul Graham as an example because though he may be a "highly specific case" that's exactly the user-base that RoR is for... people who want to develop web apps really quickly.
As far as the comparrison to LISP (LISP being a "mature" language)... they all had to start somewhere. Ruby was released in 1995 (aka. the same year as Java's first public release) and has grown a lot since then. In fact it borrows a lot from LISP and Smalltalk (which also borrows a lot from LISP).
Anyhow... considering that you posted about 20 posts on this one topic and all of them (well, all that I read) were talking about how Java was good and Ruby (and Rails) was bad I don't think we'll ever agree. One theme I noticed was an apparent misunderstanding of what Rails is. It isn't just ActiveRecord... it's a whole MVC architecture. If you think that MVC is a bad idea you might want to let a whole list of popular / sucessful projects know that they can stop waisting their time.
Jeremy Logan's Website.
May Peace Prevail On Earth
I think that a crucial point that either of you has failed to notice or point out is that the autogenerated comment in question is a Javadoc comment. If we take only the perspective of somebody reading the source code of the class, then lahi is right that the comment is absolutely worthless. If we take the perspective of somebody reading the Javadocs, on the other hand, having the comment does convey some information.
Still, I think that the stated reason you provide for having such comments ("to explain that this really is only a simple variable accessor") is no good. If I'm reading the Javadocs, why should I care at all whether the code for the getter is just a trivial return statement, or something more complicated? What I care about is the conceptual model that the class provides, not its implementation. The class models some kind of object within a problem domain; those objects have such-and-such properties, and these are the operations that one can perform on them.
If on the other hand I'm reading the source code, then lahi's point applies--I can just see that the method is a trivial instance field access.
This is potentially limiting, as it tries to make accessor functions limited and special in what they do.
No, you've failed to understand the feature here. There's no limitation at all. In the case of Ruby, for example, there are no publicly accessible instance fields at all. All interaction with an object must be through method invocations. If you need trivial getters and setters, there's a class method that uses the language's dynamic features to define them for you on the fly--you just say attr_accessor :foo, :bar, and voilà, you've got yourself getters and setters for foo and bar. If you need non-trivial getters or setters, you just write them by hand.
And what's even neater is that this is not a hardcoded feature of the language--attr_accessor is just a method that exploits Ruby's dynamicity; namely, the ability to generate code and extend a class at runtime. You can write attr_accessor in Ruby itself. Which means that (a) you can write your own custom boilerplate runtime method generation code just as easily, (b) you don't need a separate tool (i.e., an IDE) that knows how to parse your code and potentially decipher intent ("hmm, these two methods must be a getter/setter pair"), and most importantly, (c) the logic that decides what it means for something to be an accessor pair, and the implementation thereof, reside in just one place, instead of all over the damn code.
It also follows that you hardly ever need to write proxy classes. You can trivially write a function that takes a class, and spits out a delegate class; and the standard library already provides such code. You subclass this latter one with a constructor that sets the object that you're delegating to, and override whichever methods are different, and you're done.
[...] it is perfectly acceptable for a Java class 'bean property' (indicated by the presence of setXXX or getXXX methods) to not actually exist as an instance variable in the class. What may look like a simple accessor is actually getting a value by some other mechanism. However, to the code that uses this class (or looks at its properties by introspection) this is nicely hidden. This allows things like proxy instances to work neatly - the apparent accessor functions actually divert to another instance to retrieve or store values.
You can't really reconcile encapsulation and documenting trivial implementations. If the point of getters and setters is to encapsulate access to conceptual "properties" of objects, then whether a particular getter/setter pair is trivial is exactly the sort of thing we're trying to hide from the clients, and thus, it's not relevant information for the comment.
As to proxies: I've had to write proxy implementations of the JDBC interfaces. Ugh, that is hell.
Are you adequate?
Anyhow... considering that you posted about 20 posts on this one topic and all of them (well, all that I read) were talking about how Java was good and Ruby (and Rails) was bad I don't think we'll ever agree.
I really, really like Ruby. It is a beautiful language and I use it a lot, often along with Java. But this does mean that I don't recognise it's disadvantage. Lack of speed is one of them.
One theme I noticed was an apparent misunderstanding of what Rails is. It isn't just ActiveRecord... it's a whole MVC architecture.
I know that - I have used it, and I have been using MVC architectures since the 80s (in Smalltalk).
If you think that MVC is a bad idea you might want to let a whole list of popular / sucessful projects know that they can stop waisting their time.
Of course it is not a bad idea! When did I ever say that? I use MVC all the time these days - both in Swing and in JSF.
What I dislike is Rails' implementation of it.
If we take the perspective of somebody reading the Javadocs, on the other hand, having the comment does convey some information.
:foo, :bar, and voilà, you've got yourself getters and setters for foo and bar. If you need non-trivial getters or setters, you just write them by hand.
Exactly - I think you are finally starting to get the point.
No, you've failed to understand the feature here. There's no limitation at all. In the case of Ruby, for example, there are no publicly accessible instance fields at all. All interaction with an object must be through method invocations. If you need trivial getters and setters, there's a class method that uses the language's dynamic features to define them for you on the fly--you just say attr_accessor
Of course I understand the feature. I use it.
If the point of getters and setters is to encapsulate access to conceptual "properties" of objects, then whether a particular getter/setter pair is trivial is exactly the sort of thing we're trying to hide from the clients, and thus, it's not relevant information for the comment.
You are missing the point. The information does not need to be hidden from the client - it needs to be hidden from tools and APIs that use the 'accessor' methods. There is no harm in letting a client (or other developer who uses your code) know that a getXXX method does something more complex; that is the point of comments.
As to proxies: I've had to write proxy implementations of the JDBC interfaces. Ugh, that is hell.
You may want to take a look at Spring (www.springframework.org) - it provides libraries that can hugely simplify JDBC use.
OK fine... comment templates. We all know a good way to argue your point is to pick out a little mistake in my hastily written post and construe that I was saying that ides could magically write meaningful comments.
RE Verbosity:
My point is that if the IDE can generate and maintain the 'boilerplate' code then it doesn't matter if the language is concise or not. The IDE has effectively removed that feature of the language from consideration. All the ides will fold the code up so you don't even have to look at it if you don't want to.
I'm not saying java is 'better' or that it couldn't use some cleaning up. Or for that matter that some of the new language features in 1.5 are not just way to complex. I am saying that a good IDE can smooth out the rough areas enough that you no longer have to worry about them. This is especially true for the IDEs that constantly compile the code while you edit it so that you immediately see compile time errors. HUGE time saver.
I'm not the one to help with using eclipse on netbsd. If you're not used to using an IDE I wouldn't start with eclipse. Try jbuilder foundation or netbeans. They both are swing based and quite a bit more user friendly. And for that matter try them out on linux or os x. You'll be a lot happier with them.
I've done all my java dev with jbuilder/eclipse on os x for the past 3 years and deploy to linux, solaris, aix, and win with little trouble. That is the portable part. The UI stuff requires dealing with the subtle window/event handling on different platforms and can get really funky.
The user's application domain should indicate the need for performance. Ruby on Rails is a great tool for simple, easy to build and use web interfaces to back-end databases. Other stuff, like multi-processing on quantum devices trying to fathom the "grand challanges", should probably be based upon some other development process. Now, once your solution to the grand challanges produces some relation data, you could inform the public using Ruby on Rails, and you'd be happy becuase it wouldn't take very much time to do so.
Software freedom...I love it!
As with C++, Java owes far more to Simula-67 than Smalltalk.
I'm not going to change your sheets again, Mr. Hastings.
"largest mandatory toolchain" ... the Debian package for ghc6 is 62.2 MB. GCC is 4.2 MB plus 8.8 MB for libc6-dev, or about 1/5 the size to get up and running. Also, Miranda's syntax is easier to read than Haskell's, IMHO (to which I am entitled).
It's not that you contradicted my statement - it's that you apparently ignored it entirely. That said, you are free to name something that is easier to do in Python than in Ruby. I couldn't think of anything - maybe you, the Python advocate, can. If not, then I'm the only one here who has backed up his statement with anything at all. It is impossible to prove a negative - but if you can provide a counterexample I will gladly concede the point.
Sorry, but that _was_ what you wrote, wasn't it? ;-)
Actually, we probably agree to a large extent. Whether you use a preprocessor that generates Java or an IDE doesn't matter much. Effectively, you are programming in a language that is not quite Java, but hides some of its less fortunate properties. I just personally would prefer the language to be different, rather than having its rough edges smoothed over by an IDE. But viewed through the spectacles of semiotics, an IDE is not that different from any other language.
I am certainly not complaining about Java portability. My homebanking works fine, and in the past I have had BEA WebLogic 6 running on NetBSD. But perhaps I will start with giving NetBeans a try.
-Lasse
I'm finding netbeans 5 beta to be really nice when it's not barfing exceptions at me. Until that gets sorted out i've defaulting to eclipse. But again.. you're not going to have much fun with it on slower hardware or a slightly less used desktop os.
I think that a crucial point that either of you has failed to notice or point out is that the autogenerated comment in question is a Javadoc comment. If we take only the perspective of somebody reading the source code of the class, then lahi is right that the comment is absolutely worthless. If we take the perspective of somebody reading the Javadocs, on the other hand, having the comment does convey some information.
You are right, I viewed the comment as a code comment, not as API documentation, which javadoc is supposed to be. As I stated in my other comment, it is my understanding that accessors are conceptually corresponding to public attributes, and should be documented as such. If there is a public side-effect, it should not be done as an accessor. The API docs of a public attribute should document the meaning of the attribute, without regard for whether it is a synthetic attribute (for instance through proxying) or a real attribute. After all the status as a real or synthetic attribute could change in a subclass.
The only contrived trivial example I can think of at the moment is geometric points, where you could choose to have an interface with both polar and cartesian attributes. The cartesian implementation would have the polar coordinates as synthetic attributes and vice versa. Of course in practice you wouldn't make such a type mutable.
In any case, the comment is as useless as documentation as it is as a code comment.
Still, I think that the stated reason you provide for having such comments ("to explain that this really is only a simple variable accessor") is no good. If I'm reading the Javadocs, why should I care at all whether the code for the getter is just a trivial return statement, or something more complicated? What I care about is the conceptual model that the class provides, not its implementation. The class models some kind of object within a problem domain; those objects have such-and-such properties, and these are the operations that one can perform on them.
Those well-intended IDE-autogenerated javadoc comments pave the road from here to Hell. I look at them almost every day, and they are useless, to the point that I don't bother with javadoc. You could argue that it is the fault of the programmers whose code I am reading, but I really think javadoc has to share the blame. Documentation is difficult, and good documentation is a lot harder than good code, and trying to fix this by adding a special type of comment to your code solves very little. Autogenerating such comments OTOH is plain offensive, because real documentation cannot be generated. If the IDE could tell you why you wrote the code, it could just as easily write the code itself. By putting parrot-talk in those comments by default, you give the lazy programmer (= any intelligent programmer) a good enough bad excuse not to fill in something meaningful.
Having an IDE that could tie the documentation, and indeed the whole process from requirements, use cases and unit tests, together with the coding process would be a marvellous thing. Writing some documentation in a word processor, some in a UML tool, possibly interacting through some simple generation with the IDE and the code is not optimal, though.
I am suffering from lots of code which may or may not be out of sync with documentation, so I'd love to see a solution.
Meanwhile, I am very cautious about anything in a source file except actual live code. Even so, I sometimes look at what appears to be live code only to find out that it is dead, superseded by something else, but not thoroughly documented. Comments may be used as hints, but they can't be trusted. Period.
Executable comments, in the form of invariants, pre- and postconditions, like in Eiffel, are different. They are part of the code, and necessarily up to date.
-Lasse
Sorry, but it is my understanding that an accessor function provides an interface which conceptually is identical to a public attribute, only with the option to override with a method in a subclass. If you add behaviour to an accessor function, it should not be of any concern to the user of the class, and therefore whether you use it as foobar.setFoo(42) or foobar.foo = 42 shouldn't matter at all. OTOH, if your accessor has publicly known side-effects then it's not really just an accessor, and it is IMO wrong to write it as an accessor. Write a real method, with an appropriate name indicating the intended behaviour and side-effects.
My suggested scheme for implied accessor functions does not prevent you from having things work as you like, though. If you don't provide the public Foo foo attribute, but write the accessors yourself, you would get precisely what you want. It's similar to the way Java provides a default constructor. You can add your own instead. There's no restriction, it just works by default without you having to write anything. Of course I don't suppose you would be bothered by having to write (or have your IDE write) trivial constructors for your classes.
Being able to use plain assignment rather than calling the accessor methods is of course just nice glukosyntax.
Having just recently achieved the dubious title of Java Certified Programmer I understand that public attributes are considered as breaking encapsulation. So, instead of doing it the way I suggested, Java requires you to add accessors in all cases where you would want to use a public member, because of the few cases where you might want non-default behaviour of accessors. I believe that is a case of language design being ruined by bad and wrong priorities. And I think this should be fixed in the Java language itself rather than swept under the carpet by a "helpful" IDE.
My comments on comments come in another comment.
-Lasse
What can I say - you're absolutely right of course. But as I said, I already knew that the memory problem was indicating a problem in the code. That wasn't my point. My point was that in the past, I have used a platform where having to state memory demands explicitly was the norm, and that platform (Macintosh pre-OS X) was ridiculed by some for that reason. Yet noone seems to think that it is a problem now with the Java platform. I wonder why.
When I *want* to limit resources available to my programs on Unix, I would use ulimit.
-Lasse
Calling NetBSD a "slightly less used desktop os" must be the understatement of the year! That's very kind of you! :-)
:-)
However, I am confident that with some effort, things can be made to work. It's only a question of finding the time. If I were really desperate, I'd just use the Linux version with NetBSD's Linux compatibility layer, but where's the fun in that?
-Lasse
Sorry, but it is my understanding that an accessor function provides an interface which conceptually is identical to a public attribute, only with the option to override with a method in a subclass. If you add behaviour to an accessor function, it should not be of any concern to the user of the class, and therefore whether you use it as foobar.setFoo(42) or foobar.foo = 42 shouldn't matter at all. OTOH, if your accessor has publicly known side-effects then it's not really just an accessor, and it is IMO wrong to write it as an accessor.
/**
This is a good point. Java does not have accessor functions - it has bean properties which is a far more powerful concept.
Write a real method, with an appropriate name indicating the intended behaviour and side-effects.
This breaks the use of bean properties where those properties aren't simple variable accessors.
In my view, this is the appropriate way to indicate additional behaviour:
* Retrieve the value of X from the database
* @return x
*/
public Object getX() {...}
Not
public Object getXFromDatabase() {...}
If you use the latter, you can't do useful things like have all sorts of tools handle the property.
And.. this breaks encapsulation - the the user of the class should neither know or care whether or not X comes from a database! The method that implemements that sort of functionality should be private.
Good OOP design implies that classes should be 'black boxes' with as little as possible of the internal mechanisms and states visible. Expressing the details of what goes on in terms of public method names is a bad idea.
I believe that is a case of language design being ruined by bad and wrong priorities. And I think this should be fixed in the Java language itself rather than swept under the carpet by a "helpful" IDE.
I think it is a step forward, showing how a language can encourage good coding practise and encapsulation. 'Fixing' it would make Java phenomenally less useful - in almost every Java project I develop, I use encapsulated bean properties like this in so many ways.
Documentation is difficult, and good documentation is a lot harder than good code, and trying to fix this by adding a special type of comment to your code solves very little.
Javadoc is not trying to solve the problem of documentation - it is only trying to provide a way that method- and class-level documentation in code can be indexed, cross-indexed and collated as web pages. Nothing more.
I agree that there could be better ways to do things and keep things up-to-date, but to say that JavaDoc solves little is, in my view, way too harsh.
Autogenerating such comments OTOH is plain offensive, because real documentation cannot be generated
Autogeneration is simply there to create a skeleton comment with boiler-plate stuff filled in (parameter names, return types etc.). It is not intended as a replacement for real documentation - just as a time-saver for producing such documentation.
Ruby, IMHO, have the simplest model to do extensions on C/C++.
So, is very easy to make a prototype on Ruby, profile, and speedup the bottlenecks with C
I have been down this route with other languages. There can come a point where a significant part of your code ends up in C or C++ (at least the key parts that do most of the work). You therefore lose many of the benefits of the language you start of with.
With a language like Java (or some of the faster Smalltalks or LISPs) this sort of messy compromise is unecessary.
Now, I really don't like Ruby (Python is the king of the hill), but this is a gross understatement. More appropriate would be every fucking thing .
.. just to name a few.
Apart from things like high-performance numerics, portable multi-threading, secure networking, secure class loading
So not 'every fucking thing' then......
I never understood why Java is considered a language and not a stripped-down C with a bloated vendor-API.
Because C doesn't have classes, unicode, built-in portable threading, a standard GUI library, exception handling, automatic stack tracing on error, a security manager, binary portability across different processors and word lengths, generics, standard APIs for portable relational database persistence and distributed code, internationalization, standard APIs for web page generation, standard APIs for high-performance image processing, standard APIs for high-performance 2D and 3D graphics, built-in datatypes for unlimited precision numerics....
Oh - and most of the common APIs (Hibernate, Spring etc) used with Java don't come from a commercial
vendor.
Oh - and those APIs mentioned above aren't Vendor APIs - they are provided by all organisations that provide Java, not just Sun.
Apart from that you are correct.
Also, Java is semi-compiled while Ruby is purely interpreted, making it even slower.
Java is fully compiled. The Hotspot optimiser translates the Java byte code to highly optimised machine code.
However, if computers keep getting faster as they have been I doubt that Ruby's performance will be much of an issue in the future.
I have heard this kind of excuse for slow languages for decades. The fact is that the demands made by users is continually increasing - speed always has been and always will be important. More interestingly, what will be important is multi-threaded performance when the new multicore CPUs become common on the desktop. Java was designed to be easily multi-threaded from the start.
Actually, if Ruby can be effectively multi-threaded it may end up more efficient even interpreted than some single-threaded C/++ apps.
Afaik, Simula-67 had no JIT and Virtual Machine (or did it?), while Smalltalk did. And JIT and Virtual Machine is the basis of Java's success. I meant not just the language itself but more a solution here.
May Peace Prevail On Earth
My comment was based on the Java language rather than how certain implementations of it work (not all Java compilers target byte code for a VM -- some directly emit native codes).
And in any case, Smalltalk was far from being the first language to use a VM. LISP and some COBOL systems had them in the late 1950s, and a wide variety appeared during the 1960s and 1970s. Note that I am not talking about interpreters here, but compilers that emitted byte codes which are run by a "software CPU" that is then implemented on a variety of platforms. As for JITs, those found their way into some Smalltalk implementations _after_ they appeared for Java, not before.
I would therefore contend that Java owes little if anything to Smalltalk. Its syntax and semantics are based on C++, which in its turn was heavily influenced by Simula-67; its use of a VM can be traced back to systems that predate Smalltalk by decades; and it uses a traditional "edit in any text editor, save the file, compile it, repeat" cycle rather than the Smalltalk method of programming by environmental extension.
I'm not going to change your sheets again, Mr. Hastings.
"This is the same excuse I have heard for decades when fans of a language try and 'justify' it's lack of performance."
:: Pot:Kettle
:: Pot:Kettle
Java:Ruby
It has got to the stage where Slashdotters making flippant comments about Java's apparent lack of performance are making themselves look ignorant, not cool - as part being cool is understanding technology and being up-to-date, not keeping hold of ancient language prejudices.
Just to give one example - last year someone wanted to do XML processing in Ruby. They could not believe how slow it was. Java's XML processing was about the speed of good C-based libraries. Ruby was about 50 times(!) slower.
So, comments like
Java:Ruby
Are an old, out-of-date joke told badly.
And if Ruby or Python needed that much memory and CPU power to run an IM, then I'd agree with you. But they wouldn't, because for IMs and other similar network applications, the bottleneck is most often not in the processor, or the RAM, but in the bandwidth and latency of the network connection. Bittorrent runs perfectly happily on my old machines, and what do you think that's programmed in? If my hacked NSLU2 with a 133MHz processor and 32M of RAM can run Bittorrent without trouble, then a 1GHz Intel processor isn't going to have any problems with it.
Remember also that Python and Ruby farm out a lot to binary libraries. The GUI, socket handling and algoritms like SHA1 aren't implemented in Ruby or Python, they're accessed through libraries programmed in C and C++.
Close, but no cigar. Metaclasses are to classes what classes are to objects. Python and Ruby have metaclasses because they're dynamically typed. Java is statically typed, and I don't believe it's possible for a statically typed language to have complete metaclass functionality without compromising type safety.
Python and Ruby have mutable objects; it's possible to alter the behaviour, methods and variables held in an object at runtime. In the example I gave, I needed to create several classes that reflected certain attributes and descendants of an XML DOM Element. In Java, I had to create the getters and setters and the DOM parsing logic for each class. In Ruby, I could automatically create the getters and setters and DOM logic from a metaclass template, given certain arguments.
Thus, 50 lines of code could be reduced to 4 through appropriate use of metaclasses. Metaclasses are useful for reducing types of redundancy that functions and inheritance can't eliminate on their own.
Java's objects are immutable, so this level of abstraction is beyond the scope of the language. It has reflection, which can be useful, but to be frank, Java's reflection is pretty damn awful when compared to other languages :)
And.. this breaks encapsulation - the the user of the class should neither know or care whether or not X comes from a database! The method that implemements that sort of functionality should be private.
If you believe that, then why do you put that very information in the docs? Make up your mind, should the user know about this or not? If yes, then it is relevant to put it in the docs and in the name; if no, then the property behaves for all intents and purposes as a public member variable and should be accessible as such, even if internally to the class it is represented differently.
If it is relevant for the user to know that X comes from the DB, then it should be in the name. If you choose to give it a standardized, but meaningless name because of tools, then IMO your tools are broken.
-Lasse
Tsk tsk. You're taking this way too personally.
I'm sure it's easy to copypaste some strawman argument containing hilarious phrases such as "pointy-haired boss" which the children will find irresistible, since they know nothing about the actual merits of the arguments, having never managed anyone, let alone a group of people who work together to achieve objectives such as saving people's lives, or even less noble objectives such as creating a software platform to aid the collective research efforts of thousands of researchers.
I rest my case. The above paragraph is one sentence! Obviously working with Java's crufty verbosity has affected your writing. I'd suggest taking a course in a more pithy language. By the way, Graham's argument is not a strawman: he's made it clear over a few different essays that because programming languages vary in power, smart coders who use more powerful languages can code circles around those using Java. Also if you're going to drag in logical fallacies then I need to point out yours too: "saving people's lives" and "aiding
I have used hundreds of thousands of dollars on Python code which the author believed to be really maintainable and work really well, but in the reality-based world turned to be such crap that the whole team, including me, had to work a breakneck pace to rewrite it in Java, which has such incredible features as working threading support, no Global Interpreter Lock, actual Oracle and LDAP support that doesn't leak memory like anything, and isn't 20 times slower than the Oracle and LDAP support in other languages, no monkey patches (oh yeah, Python coders seem to think that it's SUCH a good idea to monkeypatch others' code, since after all, SMART people should know without any documentation what's going on, and documentating code is useless anyway, people should just go in and read all of those millions of lines of code if they want to know what's going on) and, you know, clear and accurate documentation and HORDES of pre-existing components which make your life so much easier, if only you're not infected with the dreaded Python community NIH disease.
Sheesh, I thought the previous sentence was bad but this one takes the cake. Full stops are your friend. So is coherence. Some answers:
Java does have an additional useful feature: because of its mandatory coding practises and standards it's pretty easy to spot when an amateur has written something really broken, and contain the problem to those components which the amateur has touched. Perhaps this is what has happened to you?
Entirely possible. But I've seen good Java - really top of the line guru-doing-an-exercise-proposed-by-Martin_Fowler-s tandard type Java - and it was just plain ugly because the language is just plain ugly.
I've used, in production, Python, Perl, C, C++, Pascal, Java, x86 assembly, a little AutoLisp, and so on. Hundreds of thousands of lines. (The C code I have out there is pretty crappy, for which I apologise, but I was an amateur and thought of my work much as you seem to think now.)
Can't recall making any comments about your work or even you personally. *Checks* - nope. You
--- Hot Shot City is particularly good.
I know this is a bit a of a flame, but Java is anything but fast. I've seen too many bloated Java app servers to know of its 'speed'. If you have fast box and gobbs of memory, then Java runs adequately. Im sure Ruby is not a speed burning language either, but I would accept the tradeoff of easier and quicker development. I would like to see some examples of some larger scale Ruby web apps however.
So, comments like
:: Pot:Kettle
Java:Ruby
Are an old, out-of-date joke told badly.
You misunderstood the point. I wasn't knocking Java's speed from its 1.[01].x days.
I am simply pointing out that knocking Ruby's speed now, given its abilities, is akin to dismissing Java in 1995 given what it brought to the table. And for a Java enthusiast to make a general statement about performance as a primary reason to avoid a language/platform is selective amnesia at its finest.
And for a Java enthusiast to make a general statement about performance as a primary reason to avoid a language/platform is selective amnesia at its finest.
Not at all. Firstly, I was not a Java enthusiast in 1995 because it was slow, so no hypocrisy here. Secondly, many of the comments here about Ruby aren't saying 'well it might get faster' - they are saying 'it is fast enough now'. Thirdly, it is difficult to predict which languages end up fast. A decade ago it looked like Smalltalk was on that route, but it failed and Java succeeded.