n/a wrote:
switch tack in the middle as my IT capablity is not a full time activity,
but more of a support 4 my main one–finance.
of course, learning curve is to be taken into consideration as well…
'd love some comments that might help me consider my options and pick a
path (c++, java or ruby) w/ a higher level of confidence… i know that
people here will be biased towards Ruby, but that is fine: i want to hear
about it…
So, for my two cents.
For the sake of all that’s good and holy, use “you” instead of “u”, same
for “wd” etc. You write to communicate ideas to others, do so that
they’ll be comprehensible by anyone, not just someone able to decrypt
your specific array of preferred abbreviations.
'd b hard 2 undrstd ppl if evr1 tlks n rites like ths.
This whole post was, if unintentional flamebait, having more information
on your requirements as opposed to going on about your and someone
else’s personal tastes would have helped.
Now, for the more objective (I hope) bits.
As for performance, well-written C++ outperforms well-written Java,
well-written Java outperforms well-written Ruby. The comparisons get
hairier as problem domain complexity increases.
For graphics, both Java and Ruby use / let you use native libraries for
the heavy lifting, and as long as a database is involved, as the weight
in DB queries increases, the overhead of the language used to do
processing gets negligible compared to DB connection / query execution
lag.
Most of Java’s bad performance rap is due to Swing from versions 1.4 and
easier. It’s a well-deserved bad rap. SWT is usually snappier, and works
reasonably well on Windows. On 1.5, IDEA - using Swing tends to be more
responsible for me than Eclipse, using SWT. This doesn’t say much about
the relative qualities of the toolkits, rather that by now, they’re both
mature enough for their use to be negligible overhead in applications of
sufficient complexity. The above of course presumes the GUIs are
well-written, both those toolkits are quite daunting, and often make
concessions GUI designers - layout managers that are intended to be
targetted by code generators rather than handcoding, which usually draw
much whining from mainly .NET fanboys. (I personally feel much
resentment towards anyone confused by options.)
I admit to not having used Ruby-based GUIs extensively. From what I can
recall about my brief forays into FreeRIDE, FOX seemed to be quite
responsible, and Gtk is fairly mature and native too, and tends to
perform rather well. (On Windows, both look horrible to me though.) On
the question of GUIs, I’d call things even from the performance point of
view. From the programming point of view, all toolkits mentioned make
use of callback functions, where all the languages mentioned need to
emulate functional programming capabilities with varying levels of
verbosity (with roughly Java > C++ > Ruby, greater = more verbose).
With your requirements, I think you’re understating data source
integration. For database connectivity, every product exposes a C / C++
API. Also, more or less every product save very, very legacy databases
will provide you with a JDBC driver, which in addition to ubiquity gives
you some measure of uniform access. With Ruby, the situation is mildly
less stellar, and you’d better try and scout out if bindings to what you
need are available. For major DB vendors, they should be at usable
levels of maturity, but it’s a point worth checking.
Your programmer friend has a rather narrow way of looking at things.
Both C++ and Java have their well-established niches, which means
they’ll in some way matter for a long time still. I personally see no
shame in having a CV entry with good representation on the job market
even though it’s not the shiny new kid on the block. That said,
depending on how much decision power you expect to wield about choice of
technology you’ll use to program, this might be irrelevant to you and
your choice.
As for the fear of switching tacks in the middle, as others have pointed
out, this is unavoidable, and learning to switch is a valuable (and
easy) skill. There is no silver bullet, there is no “best” language, and
if you’ve got the right brain pathways, you’ll notice that all the
class-based OO languages (the major family these days) are essentially
identical in enough of the fundamental concepts for programming in one
you don’t know to be a matter of two hours of reading through a syntax
tutorial and having an API reference open in a browser window.
From the learning curve perspective, It Depends. C++, C#, or Java are
easier if you have skill with using a high-level IDE, Ruby if you don’t.
On that note, I’d be more in favour of Python than Ruby; since a lot of
learning a language well involves reading code, and Python forcing you
to express using more clear and basic concepts (e.g. no eval
metaprogramming, global namespace / class definition clobbering, or
other manners of witty hacks), it’s more likely you’ll find Python
material more didactic. That said, Ruby code not using features beyond
your current level of comprehension is on par with Python’s, and the
latter language has its idiosyncracies too - notably the functional -ish
features.
Summarising the language curve bits, I don’t have a problem with either
side of the fence, but scripting languages, Ruby and Python more so than
Perl / Tcl (for me at least) are more approachable in general, and their
libraries seem to be more oriented towards solving the most common tasks
very simply, instead of solving all cases consistently - which means
problems are expressed in a straightforward, more understandable way.
David V.
Some of the Scheme dialects