What are the disadvantages of Ruby?
On Apr 29, 3:29 pm, tenxian [email protected] wrote:
What are the disadvantages of Ruby?
It’s not the fastest.
tenxian wrote:
What are the disadvantages of Ruby?
Relative to what and for what purposes?
tenxian wrote:
What are the disadvantages of Ruby?
Hello tenxian:
I came to Ruby from Delphi (and to a lesser extend C/C++, Visual Basic,
Python and various other languages) and find the following, in my
opinion, to be the greatest issues:
-
For my situations Ruby has been between 2 and 80 times slower than
Delphi (Delphi is roughly equivalent to C++ in speed). Loop,
calculation and in-memory data processing intensive operations (like
calculating prime numbers, reading XML files, and image processing) are
closer to the 80 times and programs that call out to optimized libraries
(like OpenGL) for heavy-lifting are closer to 2 times. Most of the Ruby
programs I’ve written use more optimal algorithms than in Delphi because
Ruby’s flexibility and richness but the speed difference is still
noticeable in all the situations I’ve come across (i.e. in one situation
I used Ruby’s powerful reg expressions to avoid looping which made the
Ruby program only 32 times slower instead of 80 times slower than
Delphi). Previous discussion on this forum have suggested complimenting
Ruby with C routines for the speed-sensitive parts. Speed may not be an
issue for you depending on your target application type. For example,
DB applications often do their heaving lifting in the DB itself via SQL
or procedural SQL. -
GUI applications are much harder/slower to write in Ruby than in
platform specific (i.e. Windows) RAD environments like Delphi. Ruby’s
GUI agnostic (note: Ruby does come with support for TK but I don’t
consider that a serious option) approach is an “advantage” but it also
means that you don’t get an “out-of-the-box” visual GUI building
environment like with Delphi, .NET or Java. There are some tools to
make GUI building a little easier for Ruby but they aren’t, in my
experience, close to the same ease and productivity as those other
environments. However, having said that… I use wxRuby for GUI and
like a lot of its object model much better than the Windows equivalents.
This is particularity evident in components like the wxGrid. -
Ruby can’t build stand-alone compiled single file executables like
Delphi (or C/C++). This becomes a concern if you write programs /
utilities that you carry around with you from desktop to desktop and
want to run with a double-click without an install or want to minimize
concerns about incompatible library/API versions across different PCs.
It also becomes a concern for protecting your intellectual property or
when trying to make it difficult for someone to crack your security,
authentication, encryption, or game scoring system. Another concern
along these lines is that you never really know on a given platform what
exact version of a library / component is going to be pulled into your
program the Ruby “require” statement because it’s platform and install
specific dependent. In Delphi the many libraries are “compiled” into
the EXE so it’s rare that I hit incomparability on different PCs.
Everyone’s mileage will vary and you’ll need to balance issue like the
above with the richness and productivity that Ruby provides in its
syntax, cross-platform and cross-GUI capabilities. These may not be
issues for you, particularly if you’re writing server side code with
ties to other stable services/APIs that do heavy lifting for you.
I love Ruby… it’s made coding fun again and I’ve generally been
writing non-GUI stuff in Ruby 3 to 5 times faster than the equivalent
Delphi programs. However, the issues I’ve mentioned make it difficult
for me to consider releasing software outside a server or single desktop
environment or into a “commercial” setting with the same ease /
confidence that I’d release equivalent Delphi or C/C++ programs.
Ruby 2.0 should minimize many of these issues. In addition, JRuby and
the .NET flavors of Ruby address most of these issues in various ways.
Just my thoughts… Don’t take my comments as gospel. You’ll need to
research these topics for yourself and listen to feedback from others to
decide which things are real concerns for you.
Michael
On Tue, Apr 29, 2008 at 10:50 PM, Michael B.
[email protected]
wrote:
In Delphi the many libraries are “compiled” into the EXE so it’s rare that
I hit incomparability on different PCs.
Delphi really forces static compilation all the time? That sucks.
–
“Hey brother Christian with your high and mighty errand, Your actions
speak
so loud, I can’t hear a word you’re saying.”
-Greg Graffin (Bad Religion)
What are the disadvantages of Ruby?
That too many people still use perl. Especially old, but smart C
hackers, who could help out more with ruby than riding the dead horse
perl. 
There are some tools to make GUI building a little easier for Ruby
but they aren’t, in my experience, close to the same ease and
productivity as those other environments.
I dont so much agree or disagree with you about your note above 
but
I fully agree with this statement. Actually I think the GUIs in itself
are kinda too “powerful”, and at the same time suck too much.
My proof of concept are the solutions in the www world. No GUI really
has incorporated such many ideas. (If one knows any toolkit
that easily supports something like this
http://lipidity.com/fancy-form/demo/
let me know. Yes most things are doable but the question really is
how much work it would be.)
Ruby exactly bridges the gap between “professionals” and
“non-professional coders”.
And this is what I see the www being good at - it can be complex, but
in essence it is still somewhat easy to build fancy stuff with it,
which kinda works on every plattform (just compare that to most GUIs out
there)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marc H. wrote:
| My proof of concept are the solutions in the www world. No GUI really
| has incorporated such many ideas.
And is yet so uniquely unsuited to, say, data entry. Try to do
tab-sequence ordering on the web. And make sure that all your UI works
on major OS/browser combinations…
It’s a trade off.
| (If one knows any toolkit
| that easily supports something like this
| http://lipidity.com/fancy-form/demo/
| let me know. Yes most things are doable but the question really is
| how much work it would be.)
wxWidgets should, GTK+ will, as well as Qt (which uses CSS for
themeing).
And probably as much work as getting the JavaScript required to work on
different browsers.
And: The desktop app will keep working, since you can redistribute your
app and dependencies, in exactly the way you intended, on all systems
supporting your choice of language and dependencies.
| And this is what I see the www being good at - it can be complex, but
| in essence it is still somewhat easy to build fancy stuff with it,
| which kinda works on every plattform (just compare that to most GUIs out
| there)
Yeah, tell that the IE, FF, Webkit, and Opera teams, will you?
Two words regarding the world wide web:
‘quirks mode’
'nuff said.
Mind you, I’m not saying the web is bad. But it is a different problem
domain than desktop apps.
Try writing something like NetBeans or Visual Studio, or Quake, or a
full blown office suite (Google’s ‘office’ suite is a joke, comparable
to MS Works, rather than MS Office) for the web.
The web is only good at, in its current form, for CRUD.
And that doesn’t even touch on the issue of graceful downgrading.
Silverlight/Moonlight or Flash would make that possible. But those are
much more virtual machines like the JRE or .NET (especially
Silverlight), than than a HTML rendering engine.
Phillip G.
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com
10 years old is a good age to get stuck at.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgYnegACgkQbtAgaoJTgL8gZwCgj6JcH/Vi305V0ip7QAMKgtLc
7eYAniexsVlxM6RHrDWhTzex1BnWbMGY
=nfLD
-----END PGP SIGNATURE-----
On 30 Apr 2008, at 17:27, Phillip G. wrote:
The web is only good at, in its current form, for CRUD.
And that doesn’t even touch on the issue of graceful downgrading.
Silverlight/Moonlight or Flash would make that possible. But those are
much more virtual machines like the JRE or .NET (especially
Silverlight), than than a HTML rendering engine.
Much of the problem is that a Web Browser is not suited to being an
application platform, even though the major browsers have grown into
such. Beyond a certain level of application complexity a choice has to
be made between a hardline REST approach with minimal markup and
styling, or a lightweight client delivered as Flash, Silverlight of
Java Applet content inside a browser page. Both approaches have their
problems and for many kinds of applications such as casual games I can
see an argument for developing dedicated clients and ignoring the
browser altogether.
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
raise ArgumentError unless @reality.responds_to? :reason
/Au contraire/ - I tend to code very fast in Ruby. Of the 20-odd
languages I have used professionally, it provides the highest developer
productivity.
I mean like processing speed. A C program will probably outrun a ruby
program, all else being equal.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John wrote:
| I mean like processing speed. A C program will probably outrun a ruby
| program, all else being equal.
Not that this matters in non-embedded environments, and given how
absurdly cheap processing power is, especially in comparison to the cost
a developer commands (doubly so if the developer is any good).
Phillip G.
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com
~ “That’s the problem with science. You’ve got a bunch of empiricists
trying to describe things of unimaginable wonder.” -Calvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEUEARECAAYFAkgX3hkACgkQbtAgaoJTgL+4PwCXSq0bcyhdVRDs1lWBcStZS4HR
uACfU2po9bJPyOejkN9mFXrhuOXlT0U=
=E+ZC
-----END PGP SIGNATURE-----
Regarding GUI/user interfaces. There are many ways in which Ruby can be
provided with a snazzy front-end. To take two examples which I’ve used
myself.
- Link Ruby to some other language/framework. That’s what our free Ruby
Connector does. You can write and design all the user interface stuff in
.NET (C#, say, or VB) and run Ruby at the back-end…
http://www.sapphiresteel.com/SapphireSteel-Downloads
- Or if you want a cross-platform GUI, how about Adobe Flex/Flash? I’
ve just put a simple tutorial online explaining the basics of Flex+Ruby
On Rails. This is a web app but in principle I can’t see why you
couldn’t use Flex as a front-end for either an embedded Flash app (i.e.
Flash embedded into an app written in a compiled language such as C#,
Delphi etc.) or as a cross-platform standalone using Adobe’s new AIR…
http://www.sapphiresteel.com/Ruby-On-Rails-With-Flex
best wishes
Huw C.
SapphireSteel Software
Ruby and Rails In Visual Studio
http://www.sapphiresteel.com
Marc H. wrote:
What are the disadvantages of Ruby?
That too many people still use perl. Especially old, but smart C
hackers, who could help out more with ruby than riding the dead horse
perl.
I managed to bypass C and went straight from Fortran to Awk and then
Perl. I recently was “asked” to port a Perl program to C for “speed”.
Ick.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Huw C. wrote:
|
| 2) Or if you want a cross-platform GUI, how about Adobe Flex/Flash? I’
| ve just put a simple tutorial online explaining the basics of Flex+Ruby
| On Rails. This is a web app but in principle I can’t see why you
| couldn’t use Flex as a front-end for either an embedded Flash app (i.e.
| Flash embedded into an app written in a compiled language such as C#,
| Delphi etc.) or as a cross-platform standalone using Adobe’s new AIR…
Adding to this: Monkeybars makes it a breeze to grab the Swing UI from
Java with JRuby, for a really cross platform solution (and the MVC
pattern :P). 
(Adobe is slow in supporting non-Windows, non-Apple products.)
Phillip G.
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com
~ Calvin : I think we have got enough information now, don’t you?
~ Hobbes : All we have is one “fact” that you made up.
~ Calvin : That’s plenty. By the time we add an introduction, a few
~ illustrations and a conclusion, it’ll look like a graduate
thesis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgZRQoACgkQbtAgaoJTgL+3swCePPaO5lV8hA5YnuWV2R+kyH2o
eTAAnjeLq3v690ORJubpRsLjXRphgduR
=9p/H
-----END PGP SIGNATURE-----
On 30/04/2008, Eleanor McHugh [email protected] wrote:
Much of the problem is that a Web Browser is not suited to being an
application platform, even though the major browsers have grown into such.
Beyond a certain level of application complexity a choice has to be made
between a hardline REST approach with minimal markup and styling, or a
lightweight client delivered as Flash, Silverlight of Java Applet content
inside a browser page. Both approaches have their problems and for many
kinds of applications such as casual games I can see an argument for
developing dedicated clients and ignoring the browser altogether.
I have written a data entry application in PHP (+JS)(because it is the
only supported relatively secure scripting solution on our server). It
was a port of a DOS FoxPro (or whatever is the ‘engine’ called)
application. Admittedly the forms are as crude as they were in DOS,
and the tab order is linear. But you get UTF-8, and relatively fast
searches (especially if the result is small). And it works in both FF
and IE so it is quite portable, but I had to implement some parts of
the JS separately for each browser.
As the amount of data entered is small (a few records per day) the
portability is a win. If I had a dedicated server I could write the
application in Ruby but it is not the case. Still for more intensive
use the response times of a web application would be unacceptable.
I don’t like stuff like flash for anything important. The renderer is
not free and therefore does not work on many ‘more exotic’ platforms,
at least not easily. Flash games or cool demos are OK, they either
happen to work or you find something else. But there the usefulness
ends.
GUIs are quite hard to do programatically from scratch, and GUI
builders aren’t the easiest thing to work with. One that is quite
acceptable is distributed with DeveloperTools for OS X. Using that
you can make flexible dialogs (or windows with multiple controls) that
expand and contract reasonably with some effort.
It is not very clever by itself but you can specify which parts should
be fixed, and which extensible, and there are many alignment options
to keep stuff together. So far I have not seen any GUI builder that
would do that for me.
And seeing that most dialogs on other platforms are fixed size and
don’t react properly when they are localized (changing text length),
the font size changes, or the dialog is forced to expand It would seem
that most GUI builders do not allow to make reasonably flexible
dialogs.
There is another question if dialogs are the desirable communication
tool at all but these are “state of the art”, and most users won’t
accept any experimental GUI solution anyway.
The most interesting thing for Ruby is probably Shoes right now. It is
supposed to focus on simplicity for both users and programmers using
well known UI elements. I have tried some experimental demo some time
ago. It looked interesting but there were still some rough edges.
Thanks
Michal
Marc H. wrote:
My proof of concept are the solutions in the www world. No GUI really
has incorporated such many ideas. (If one knows any toolkit
that easily supports something like this
http://lipidity.com/fancy-form/demo/
let me know. Yes most things are doable but the question really is
how much work it would be.)
Marc, although I haven’t looked at it closely, this looks like the kind
of thing Shoes sounds like it can handle (yes, I know there are a couple
of implicit disclaimers in that sentence).
Cheers,
Mohit.
5/2/2008 | 1:07 PM.
On Apr 29, 2008, at 8:20 PM, John wrote:
/Au contraire/ - I tend to code very fast in Ruby. Of the 20-odd
languages I have used professionally, it provides the highest
developer
productivity.I mean like processing speed. A C program will probably outrun a ruby
program, all else being equal.
don’t forget - ruby is a c program. thus, if you are leveraging
this fact by staying inside native ruby functions or using extensions,
it should be roughly equal. this is especially true if you consider
using a gc in c to prevent leaks and writing complex programs in c,
where you often end up using naiive implementations to maintain your
sanity. a perfect example is narray, you can to extremely fast
operations using it. i’ve personally replaces server pure c and
fortran programs of 1000s of lines with 100 or so lines using narray
carefully and ended up with smaller memory footprints and faster
execution.
in the end it’s about understanding precisely what you are doing with
ruby: a great c program to extend.
On 30/04/2008, Huw C. [email protected] wrote:
- Or if you want a cross-platform GUI, how about Adobe Flex/Flash? I’
Flash is NOT cross-platform. Where is the player for, *BSD, PPC
Linux, ARM LInux, qtopia, Palm OS, just about anything?
Thanks
Michal