Ruby vs Java vs c++

Hi!
As a developer who wrote programs in C++ & Java & Ruby and as a man who
trained young programmers,
I surely recommend Ruby for a newbie :slight_smile:

If you’re a beginner it’s certainly better to have the fastest startup
with some OO language - and Ruby here is the best choice:
it’s easy to learn and it suggests the ‘proper’ way of OO thinking.
It’s more important first to get more experience in OO design and
programming, leaving for the future your thoughts of possible app’s low
speed…
After a while you may want to learn Java or / and C++ ('cause a
programmer have to know more than 1 language)
and with happy Ruby experience it’ll be much easier.

The questions of speed and efficiency of financial / economical
applications should be treated from the point of view
of the architecture & framework, not merely the programming language -
considering all the DBMS, client-server and Web-interface stuff.
Ruby on Rails offers a fine solution for database-centric applications.

Mike S.
(Mikhail Shokhirev)

On 11/19/06, El Gato [email protected] wrote:

However, it seems to me that you’re looking for the expressiveness of
Ruby and the speed of C++. Welcome to the club. Strangely enough,

I’m learning OCaml for just that reason :slight_smile: Some of the Scheme dialects
get some impressive performance figures too, but I haven’t really
looked into them as much.

martin

n/a wrote:

hi, newbie so please be tolerant… :wink:

Only if you promise to read every danged post you inspired.

i need to start to learn a programming language to be able to develop
custom aps to be applied to a variety of purposes but mainly 1) financial
data modeling–including graphics and data handling via database queries,
etc.; and 2) more general business-type aps.

All non-trivial applications, these days, are multi-lingual. For
example,
many applications use a markup language (HTML, RC, etc…) to paint
their
GUIs. Then they use an OO language for their high-level
command-and-control
code (such as Ruby). Then they use a declarative language, such as SQL,
to
interface with their systems, such as OSs and database engines written
in a
C language.

my feeling is that i hate BLOATED sluggish programs (like some Java
program running on older JVM’s and perhaps not written in an optimal
way…u get the idea.)

That’s because Java was invented to take market share from C++,
allegedly
without introducing new risks. The actual result was a language that’s
harder to compile, and harder to program. Java strongly resists
high-level
abstractions, forcing you to write line after line and page after page
of
cruft just to get anything done. (No wonder the book /Refactoring/ uses
Java!!:wink:

Java is hostile to both the CPU and the programmer. Hence, the user
suffers
too.

if i need to make a choice between fancy and efficient,
speed, etc., then it’s an easy choice 4 me of efficient.
which is why i have just started w/ c++.

No prob. Just remember that C++ is “portable OO assembler”, and it is
CPU-friendly and programmer-hostile.

Ruby, by contrast, is the ultimate in programmer-friendliness. At
considerable expense to the CPU!

however, speaking to one my programmer friends who is a top level Java
programmer (the stuff he writes is very efficient and fancy as
well–great balance),

Oh, I love it when they start lecturing you on how awesome that
peesashit
language is! Ay-yi-yi!

he is telling me that 1) c++ is being phased out
(except 4 real low level stuff like drivers, etc.) in favor of languages
such as Java or Ruby.

Incorrect. C++ is a systems language (per Bjarne Stroustrup, its
author).
Systems are large and long-lived. Nobody is phasing them out.

C++ is strongly represented in the database, videogames, operating
systems,
scientific, and research spaces. Also, all those spaces typically
“alternate
hard and soft layers”, by augmenting their C++ with a soft OO language.
Videogames use LUA, OSs often use Perl, databases use at least SQL if
not
more, and so on. Ruby makes an exquisite soft-layer, to provide the
high-level features for a C++ application.

he recommends i switch from learning c++ to learning
Java or Ruby. i wd hope to be able to choose the best path and not have to
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.

Learn to learn languages. I could write a program in Java if you forced
me
to (and with steady access to Google). Then learn all of them. You don’t
have to worry about running out of room in your brain!

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…

You will never miss anything (except lots of entry-level jobs that
nobody
should want) if you avoid Java like the plague, and stick with languages
that are technically superior. Put another way, the simple motivation of
having a boss order you to use Java is not good enough. The motivation
itself will not magically make Java more productive. It will slow you
down.
Some people work by the hour, so that’s okay for them. If you want to be
rewarded for productivity, go with the most technically advanced system
you
can.

I work to the story-point. That means I estimate for my client each
feature
in “ideal hours”, and then I charge to those point, not the actual
hours
spent researching and coding. I don’t actually give a darn what that
time is
(and it usually includes lots of bizarre interruptions from my
females!).

If I did that using any system besides Ruby (on Rails, and pure Test
Driven
Development), I would be absolutely screwed. Instead, I am able to fix
the
cost of each iteration, while keeping the quality as high as possible,
without excessive delays.

David K. wrote:

really looked into them as much.
them consequently were removed from the stack.

This basically made continuations rather easy to implement.
Impressive.

I haven’t dug into Scheme implementation benchmark shootouts recently,
but for now, my money is on Gambit, mostly because of the “Termite”
package implementation of Erlang-like lightweight processes.


M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC§
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

“Martin DeMello” [email protected] writes:

On 11/19/06, El Gato [email protected] wrote:

However, it seems to me that you’re looking for the expressiveness of
Ruby and the speed of C++. Welcome to the club. Strangely enough,

I’m learning OCaml for just that reason :slight_smile: Some of the Scheme
dialects get some impressive performance figures too, but I haven’t
really looked into them as much.

I have looked through several compilers. I have to say that one of
the most appealing Scheme->C compiler ideas I have seen was to drop
the distinction between heap and compiler stack: functions were called
with an appropriate continuation data structure, and no function ever
properly returned at the C level. Data was allocated using alloca.

When the heap/stack combination overflowed, it was garbage-compacted
in its entirety. All continuations without a pending reference to
them consequently were removed from the stack.

This basically made continuations rather easy to implement.
Impressive.

Paul L. wrote:

QTDesigner on Linux, plus a command-line utility called “rbuic”, makes
creating GUI interfaces very easy (“rbuic” translates the GUI interface
specification into a Ruby source file). These may also be available on
Windows.

This was discussed recently, they aren’t. Yet (maybe).

David V.

“M. Edward (Ed) Borasky” [email protected] writes:

dialects get some impressive performance figures too, but I haven’t
pending reference to them consequently were removed from the stack.

This basically made continuations rather easy to implement.
Impressive.

Chicken URL:http://www.call-with-current-continuation.org/index.html

I haven’t dug into Scheme implementation benchmark shootouts
recently, but for now, my money is on Gambit, mostly because of the
“Termite” package implementation of Erlang-like lightweight
processes.

Well, it would be my guess that in typical applications continuations
are more important, and it looks from
URL:http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#SEC133 as
though they are implemented in a manner that basically incurs O(n^2)
copying overhead where the n is the number of call-with-continuation
calls not yet garbage-collected.

I find Chicken’s approach to continuations more appealing, but of
course performance hinges on more than just that detail.

Stalin is also said to be a good Scheme compiler.

On Sun, 19 Nov 2006 08:38:21 +0000, Phlip wrote:

Java is hostile to both the CPU and the programmer. Hence, the user
suffers too.

Being reasonably experienced in developing both C++ and Java
applications,
I would suggest that a modern JVM is not slow by any means:

http://www.kano.net/javabench/data

You will never miss anything (except lots of entry-level jobs that
nobody should want) if you avoid Java like the plague, and stick with
languages that are technically superior. Put another way, the simple
motivation of having a boss order you to use Java is not good enough.
The motivation itself will not magically make Java more productive. It
will slow you down. Some people work by the hour, so that’s okay for
them. If you want to be rewarded for productivity, go with the most
technically advanced system you can.

Ruby is great; I clearly wouldn’t be on this newsgroup if I thought
otherwise. However, at this point in time Java is far more mature,
performs better, and enjoys a much greater market penetration than Ruby,
meaning that your Java skills, should you choose to develop them, could
prove the more useful.

I agree with Philip in that you should “learn to learn languages”;
that’s
the advice of a seasoned software engineer. But what I would add to that
is that since Java borrows so much from C++ (and is borrowed even more
heavily from in C#), learning to “think in Java” is an especially good
starting point from which to proceed to other languages. That might be
something worth keeping in mind, especially if you think that you might
do
work on .NET some day.

There certainly are flaws in Java, particularly in the language itself.
Many tasks must be approached with an unnecessary verbosity of code:
launching a new thread, for example, requires more writing than it
should.
I get the feeling that Gosling et. al. originally intended this very
explicit syntax in order to make the exact behavior of the code more
apparent to the programmer (a decision which may have contributed to
Java’s popularity in academic circles). However, when comparing Java to
its extremely similar - yet more concise - counterpart, C#, it is clear
which approach is more appropriate from the standpoint of a pragmatic
software developer. Java began to add some much-needed syntactic sugar
in
Java 5, and I would expect to see further improvements in this area in
upcoming relases.

All things considered, the Java environment (and the vast ecosystem that
has grown up around it) is quite powerful. Coupled with the close
ideological relationship that the Java language shares with other
popular
programming languages, I would think this makes Java very much worth
your
consideration.

Good luck,
Mark

About 20 years ago, when I graduated from University of Illinois’
with a BS in Computer Science / Engineering,
the department’s philosophy was for students to acquire an
understanding of computers and programming
from the ground up. That meant from the electronic circuit level, to
the logic level (NAND and NOR gates),
to assembly programming, and on up. My answer to the original
question is based on this philosophy.
I recommend starting at the C/C++ level simply to gain a fundamental
understanding of the bits & bytes,
pointers, pointer arithmetic, structure layouts, byte ordering,
structure member alignment, dynamic memory
allocation on the heap as opposed to the stack, etc. Understanding
this gives you a good idea
as to what’s going on “under the hood” with higher-level
languages. Things won’t be so mysterious.
It’ll pay off in the long run.

-Matt

Phlip wrote:

however, speaking to one my programmer friends who is a top level Java
programmer (the stuff he writes is very efficient and fancy as
well–great balance),

Oh, I love it when they start lecturing you on how awesome that peesashit
language is! Ay-yi-yi!

[snip]

If I did that using any system besides Ruby (on Rails, and pure Test Driven
Development), I would be absolutely screwed. Instead, I am able to fix the
cost of each iteration, while keeping the quality as high as possible,
without excessive delays.

I am so glad to see the ranting preaching zealot was refuted with a
factually supported statement based on experience with comparable
problems.

David V.

Chilkat S. wrote:

I recommend starting at the C/C++ level simply to gain a fundamental
understanding of the bits & bytes,
pointers, pointer arithmetic, structure layouts, byte ordering,
structure member alignment, dynamic memory
allocation on the heap as opposed to the stack, etc. Understanding
this gives you a good idea
as to what’s going on “under the hood” with higher-level languages.
Things won’t be so mysterious.
It’ll pay off in the long run.

While my experience was notably shorter, I never, ever saw a problem
where understanding that would be in any way relevant. The whole point
of higher-level languages is that they separate the world into the
language’s developers, who do care about what’s under the hood, and the
users, who care bugger all about it. Your mileage may vary, but in my
opinion claiming knowing implementation details is important to using
some software isn’t in any way essential (and surprisingly enough, this
notion holds in the even higher levels of software design, which is all
about information hiding and complexity reduction). Enlightening, maybe,
definitely useful if you’re doing peephole hand-optimisations your C
compiler misses, but not essential for understanding.

Speaking of which, about half of the concepts you mentioned I can’t see
how are relevant to implementing higher-level languages. Byte-ordering
is more or less a network / filesystem driver issue, pointer arithmethic
a hack around C not having introspection on array bounds, structure
member alignment and layouts an issue of implementing a C compiler or OS
kernel (its ABI), a cross-language low-level integration issue. Bits and
bytes are utterly irrelevant outside device drivers, they’re just not a
meaningful unit of data after you leave hardware. And pointers
complicate C’s type system in order to make it more compatible with
assembly and indirect memory adressing, all high-level languages (save
for maybe Perl and PHP) go out of their way to hide the fact that they
even exist and present a more orthogonal and clearer type system.

David V.

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.

Chilkat S. wrote:

understanding of the bits & bytes,
pointers, pointer arithmetic, structure layouts, byte ordering,
structure member alignment, dynamic memory
allocation on the heap as opposed to the stack, etc. Understanding
this gives you a good idea
as to what’s going on “under the hood” with higher-level
languages. Things won’t be so mysterious.
It’ll pay off in the long run.

The OP is not trying to become a programmer qua programmer. He wants to
be
able to write some very specific kinds of software in a particular a
field.
In such a case I recommend that the student learn a language that
conveys
the essence of programming, without necessarily conveying the essence of
the underlying hardware.

For such a person, understanding a bit-flip is far below the priority of
understanding encapsulation and top-down design.

On 11/18/06, Hal F. [email protected] wrote:

Well, Dave T. is, and many others… Austin Z is (only recently).

I don’t think Daniel B. is, or myself, or Matz.

Although I admit I’ve thought about it…

I’m really proud of myself for actually trying a Mac, finding out it
wasn’t for me, and going back to GNU/Linux (ArchLinux)

Though I will say that if TextMate was cross platform, I might
consider at least trying to get over my cult-like affection towards
vim :slight_smile:

stef wrote:

/ …

efficient–which will then afford me the time to learn more, etc. if i
get bogged down in the mechanical details before ever having a chance to
be productive, that we be a problem. i say this w/ out really kowing what
i am getting into or the complete relevance of it but u get my
meaning…

Sure, I get your meaning, after a little help from my Perlish IRC cruft
filter:

s/ paul / Paul /g

s/ u’r / you are /g

s/ italy / Italy /g

s/ i / I /g

s/ u / you /g

s! w/ out ! without !g

No pure regexp for the rule “Sentences begin with a capital letter”, but
since this is a Ruby newsgroup:

message.gsub!(%r{(^|.\s+)(\w)}) { |c| c.upcase }

If this seems anal, remember that computers are unashamedly anal, fully
ten
times worse than a human OCD sufferer.

On Sun, 19 Nov 2006 10:36:51 -0800, Paul L. wrote:

understanding of the bits & bytes,
essence of the underlying hardware.

For such a person, understanding a bit-flip is far below the priority of
understanding encapsulation and top-down design.

paul i think u’r correct in the sense that u can be a great driver w/
out
understanding all the ins and outs of the engine, etc. in italy, they
still have driving students learn all about the engine, how it works,
etc.; as opposed to teaching them how to drive right away and leave the
mechanical part for the mechanically inclined. sure it’s great to know
more; and i do want to know more but i also have to be productive and
efficient–which will then afford me the time to learn more, etc. if i
get bogged down in the mechanical details before ever having a chance to
be productive, that we be a problem. i say this w/ out really kowing
what
i am getting into or the complete relevance of it but u get my
meaning…

David K. wrote:

“M. Edward (Ed) Borasky” [email protected] writes:

Chicken URL:http://www.call-with-current-continuation.org/index.html

Yeah, I’ve got Chicken (and DrScheme and Guile and Gambit and a couple
others).

though they are implemented in a manner that basically incurs O(n^2)
copying overhead where the n is the number of call-with-continuation
calls not yet garbage-collected.

I find Chicken’s approach to continuations more appealing, but of
course performance hinges on more than just that detail.

Stalin is also said to be a good Scheme compiler.

Sheesh … at the risk of introducing a terribly inside joke, now I need
to design a language called Shostakovich. :slight_smile:

But seriously, to bring this back to Ruby, you’ve pointed out that the
Scheme community, which worships continuations, has proved to the Ruby
community that they can be implemented efficiently. So once again, I
will step on my soapbox and beg with Matz and Koichi to keep
continuations in Ruby >=1.9 if at all possible.

Sunday is the day they do the soapbox thing at Hyde Park in London,
right? :slight_smile:


M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC§
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

On Sun, 19 Nov 2006 16:13:31 +0900, M. Edward (Ed) Borasky wrote:

when my algorithm became extremely heavy iteration, the result was
i have to say that o/all i have seen java slower than c++ but NOT always

Then again, for pure number crunching, there’s no reason in the world
Ruby’s NArray can’t run at full floating point speed on at least a
modern x86-32 platform. This stuff is what we call “embarrassingly
parallel”. :slight_smile:

sounds good to me :wink:

Gregory B. wrote:

I’m really proud of myself for actually trying a Mac, finding out it
wasn’t for me, and going back to GNU/Linux (ArchLinux)

Though I will say that if TextMate was cross platform, I might
consider at least trying to get over my cult-like affection towards
vim :slight_smile:

Quick quiz – how many vim users actually donate money to the orphanage
in Uganda?

Actually, what made Vim my editor of choice was the GVim implementation
on Windows, not the Unix/Linux versions. After all, they already had vi,
and for those with enough memory, emacs. But the ability to do both “vi”
keystroke editing and Notepad-like cut and paste in GVim was what made
it indispensable to me.

ArchLinux, eh? I’ve forgotten – is that a Debian derivative?


M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC§
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

Chilkat S. wrote:

understanding of the bits & bytes,
pointers, pointer arithmetic, structure layouts, byte ordering,
structure member alignment, dynamic memory
allocation on the heap as opposed to the stack, etc. Understanding
this gives you a good idea
as to what’s going on “under the hood” with higher-level languages.
Things won’t be so mysterious.
It’ll pay off in the long run.

-Matt
Well, speaking of bachelors’ degrees from the University of Illinois,
about 44 years ago I got an AB in math there. Computers were just then
starting to become available to undergraduates, and I certainly learned
the logic design as well as programming on machines of that era. Would
you believe the IBM 650 and ILLIAC I? Hell, these gizmos didn’t even
have hardware floating point – you had to be a grad student to get your
paws on one of those!

I’m glad to see they were still teaching that 20 years ago. But you know
what? I would hope that the people coming out of the U of I in CS/EE
with a BS today would have had all of that in high school or even
junior high! I would hope by the time they got their BS, they’d know
stuff that didn’t exist 20 or 44 years ago!

To give you an example, I graduated right around the time such advances
as the Fast Fourier Transform, Lisp, the notions of computational
complexity and NP-completeness, disk operating systems, etc. were just
starting to make it into commercial application. The stuff that makes
Google and Microsoft and PlayStations and BlueGenes and iPODs tick
today is what undergrads should be learning about. And that means, as
far as I’m concerned, Ruby or Smalltalk or Erlang over Forth or
C/C++/Java or Lisp/Scheme.


M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC§
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs