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.'"
Before I even consider Ruby: is it faster and less memory hungry than Java.
If the answer is no, then I'm not going to waste any effort on it.
Rails is _not_ a code generation framework. Note the period on that sentence. Rails may provide the some simple scaffold generation, but that's only there if you _want_ to use it, and it happens to fit the way you'd like a particular part of your app to work. The code produced is concise, easy-to-follow, and thus easy-to-maintain. For my own applications, I barely ever use scaffolding. It works well for simple admin screens where I just want 'something' that works for now, then will spend some effort on designing it a little better, later. Rails is as maintainable as you make it. If you're a poor programmer, you're likely to write unmaintainable code, no matter what language or framework you have to help you. Rails helps point you in the right direction, but in the end, it's up to the _developer_ how maintainable his/her code is.
Why was this modded up? The article doesn't even mention code generation. It compares Ruby and Java as generic development languages.
This is a generic resonse, which has nothing to do with the article. The guy who posted it posted at least one other generic "Rails" response, having absolutely zilch to do with the article.
they can't be arsed to rtfa, nor can I...
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?
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.
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?
Wow, they have Ruby off the Rails now?
With apologies to Homer Simpson...
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 =14310517
...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.
That goes for any sane modern language.
I am trolling
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.
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.
Robot or no robot, you're still copying highly-modded posts from previous threads and passing them off as your own, which is reprehensible.
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.
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.
> 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
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.
Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
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.
The language was created by Yukihiro "Matz" Matsumoto, who started working on Ruby on February 24, 1993 and released it to the public in 1995.
g uage
That is about the same time Java took off.
http://en.wikipedia.org/wiki/Ruby_programming_lan
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
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.
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.
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?
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.
How come whenever someone mentions Ruby on Rails a get a picture of the Monopoly Guy hanging out of a train on that "Goto Pacific Railroad" (or whatever) chance card?
Ruby is an interesting language and I'll look at it again some time, however I'd go back to writing CGI's in C before adopting rails, it really does suck that much!
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
I've worked on enough jobs where the previous author wrote in shorthand and didn't follow good coding practices. The end result is the next person writing the code has to spend a lot of timer figuring out exactly what the heck the code does. Dynamic languages are great and they provide a lot of ways of saving typing, but what a programmers goals are is different than a company. A company wants the code well documented and easy for someone new to understand. This makes sure the company isn't at the mercy of a single programmer. Should a programmer leave, a company wants to make sure someone else can pick up the code and be productive quickly.
For all those eletist who think, "I want to write a few lines as possible", the reason why managers and executives like Java is the verboseness + strong emphasis on good coding practices. That is the primary contribution of Sun to the programming world.
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.
I used Ruby for a while a few years ago, enough to fall in love with it and wish I had more uses for it. I was unable to think of anything that I could do in Perl and not do more readably in Ruby, or anything I could do in Python and not do more easily in Ruby.
Then again, I like Common Lisp and my Christmas list this year included an open-source Miranda compiler.
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
Furthermore, he gives Ruby an attaboy for allowing him to define both classes in one file. I'm not sure why that would be terribly important to him, but it can be done rather simply in java too. The rule is one public class per file. There's nothing wrong with multiple package classes in the same file, so if you aren't producing a library for others to use, write your whole darned program in one file if that floats your boat. He could even do multiple public classes by making them inner classes of the named class. But honestly, I don't understand why packing two classes into one file qualifies as a major achievement. Finally, when he gets into the filtering code, I notice a glaring omission; Import statements of some kind. Am I to understand it's back to C style name collisions with Ruby?
Aside from showing how 'terse' Ruby can be, about the only praise he has for the language is that it is dynamically typed. In other words, you don't need a Java interface to call a method. I can still do that in Java with reflection: java.lang.reflect.Method Strong typing isn't the huge PITA a lot of people try to make it out to be. Casting and RTTI gets old sure. If you're doing a lot of casting and RTTI though, then it's a pretty good sign that you need to refactor your code.
I'm not trying to pooh pooh Ruby here guys, but this doesn't seem like a very persuasive sermon to convert all the Java programmers of the world. In short, I still fail to see what all the fuss is about.
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)
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)
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
"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.
In Python, to loop through an array:
for item in array
print item
Can Ruby do this in 2 lines?
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)
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
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.
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.
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.
> 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.
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.
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.
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.
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!
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?
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.
some things are just plain easier to do in Ruby than they are in the Java language
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 .
I never understood why Java is considered a language and not a stripped-down C with a bloated vendor-API.
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.
if by "metaclass-like abilities" you mean " a way to iterate over a class's members" Java already got it, it's called reflection and I used it before to traverse a generated parse tre e, which sounds similar than what you were doing :)
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
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.
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
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.
What about JRuby, Ruby written in java so you can call the java stuff from it.