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.'"
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.
That goes for any sane modern language.
I am trolling
Wasn't Java itself once defined mostly in terms of C++, and isn't C# now defined in terms of Java?
VKh
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.
> 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.
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.
StringTokenizer st = new StringTokenizer(s);
Free Java games for your phone: Tontie, Sokoban