Ruby vs Java vs c++

[EB]

I have been thinking, and talking, about this quite a bit lately. Here
is my take...

Learn Ruby and C. With Ruby you can write programs fast, with C you can
write fast programs,

I like this summary, I'll already used it today

 

[David Kastrup]

So Muhammad used C? He wrote down the rules for Ramadan, and that may
be called a fast program.

 

[gregarican]

Not when the vendor can kill it. Microsoft killed Visual Basic. Q.E.D.

Not to belabor the topic, but how is Microsoft killing off VB? I
understand that VBA is being retired, but VB seems to be alive and
kicking through .NET in the 2005 version
(http://msdn2.microsoft.com/en-us/vbasic/default.aspx). Did I miss
something? I know that VB 6.0 is formally losing support as of 2008 but
the .NET implementation is still alive, correct? Even if Microsoft
formally retired VB there are other one-off alternatives that could
take its place. RealBasic for example
(http://en.wikipedia.org/wiki/REALbasic).

 

[Charles D Hixson]

I'm also giving a bit of consideration to Gambit Scheme with
Termite. (To be honest, the Scheme thing is probably on indefinite
hold...but Termite sounds quite interesting for a few years from now
when more than two processors/CPU becomes common. [Currently I have
an SMP system with two processors, so this wouldn't buy me much, but
how many CPU slices with my next computer have?])

If you want a "core language", Gambit Scheme/Termite is a good choice.
For small/agile production, it's probably adequate. But if you want an
industrial strength large-product software development environment
with the same underlying concurrency semantics (more or less), you
should probably be looking at Erlang/OTP. It's open source (but
standardized by Ericksson) and has lots of infrastructure (compilers,
interpreters, correctness analysis tools, databases, etc.)

There's one (1) text on Erlang, and it's out of print. There's so
little documentation of it that when I first encountered it on the web I
thought it was a new language.

Erlang seems to have a lot of good features, but to me it feels
moribund. Even Eiffel appears to have a more vibrant community. (I'll
grant that this may be appearance only.) If I compare that with, say,
Ada... I don't like the way Ada is headed, but it DOES appear to have a
community, and well maintained compilers (plus commercial development
environments that I know nothing about).

If Erlang is to succeed, it needs more examples and more tutorials.
OTOH, the version I installed this year didn't crash on the example
programs I tried, unlike the one that I installed last year. (In both
cases using the standard Debian repository.)

I don't really like Scheme. I find Ruby (and Erlang) to be nicer
languages. But I may go that way anyway merely because it feels like a
more enduring distributed environment. (I'm not sure about termite.
Apparently it only works with Gambit Scheme, and this seems to imply
that it's significantly non-standard in very limiting ways. So I'll
wait until there's at least a "second source" before committing myself.)

Well, this won't be significant for a few years yet. Perhaps something
newer and better will pop up in the meantime. Or perhaps something will
happen to change my perception of the current players. Eventually I'll
need to decide. It would be nice if whatever I decided worked well with
Ruby code.

 

[Charles D Hixson]

Excel itself has a long and painful history of mathematical
incorrectness. To be fair, some of it came from the need to be upward
compatible from Lotus 1-2-3, which in turn needed to be upward
compatible from VisiCalc. A simple example is the belief in Excel that
1900 was a leap year. I'm not sure what Google query you can use to
hunt down this stuff, but I would not make business decisions based on
anything done with Excel. I use it as an X-Y plotter when I'm in a
hurry, but when I actually care about the numbers, I do things in R.

I'm talking about something on the level of 17 + 3 => 21
I could GUESS that internally it was represented as 17.45 as an integer
3.45 as an integer => 20.9 as an integer, so round up to display it...
But the numbers WERE integers. There would be no reason to represent
them as floats, much less as floats near the rounding point.

Mind you, this wasn't the only problem. My favorite one was the program
that had been working and stopped. The only way to easily fix it was to
export the routine as a text file, delete the original, and then import
the text file. My guess was that MS was storing the code mixed in with
the text of the code, and it somehow corrupted the compiled text. So
what I was doing was forcing the entire thing to be recompiled. But I
didn't make that guess until considerably after I discovered how to fix
it, so I just continued doing what worked. Using MSBasic is largely
black magic rather than programming anyway.

Glad I'm free of THAT now!

 

[M. Edward (Ed) Borasky]

There's one (1) text on Erlang, and it's out of print. There's so
little documentation of it that when I first encountered it on the web
I thought it was a new language.

Actually, the open source install package contains the entire
documentation set in machine-readable form. It's *way* too big to commit
to paper.

Erlang seems to have a lot of good features, but to me it feels
moribund. Even Eiffel appears to have a more vibrant community.
(I'll grant that this may be appearance only.) If I compare that
with, say, Ada... I don't like the way Ada is headed, but it DOES
appear to have a community, and well maintained compilers (plus
commercial development environments that I know nothing about).

Erlang is in a very real sense like Java, in that it is both an open
source community project *and* a commercial venture by a large
corporation, Ericksson. There was an Erlang workshop here in Portland in
September. There were about fifty people there, with the largest
contingent coming from Amazon. I haven't seen a bunch of Amazon people
at the Ruby meetings, so I'm assuming they've made a decision to go with
Erlang.

If Erlang is to succeed, it needs more examples and more tutorials.
OTOH, the version I installed this year didn't crash on the example
programs I tried, unlike the one that I installed last year. (In both
cases using the standard Debian repository.)

I have the utmost respect for the Debian people, but when I'm trying to
learn a new package, I almost always download the upstream source and
build it myself, rather than taking a packaged version. Of course, with
Gentoo, that's pretty much how the distro works -- just about everything
that *can* be built from the upstream source is built that way.

I don't really like Scheme. I find Ruby (and Erlang) to be nicer
languages.

I have a very fond spot in my heart for Lisp 1.5. Common Lisp is
bloated, and Scheme has different semantics. But I think Scheme is much
closer to the *spirit* of Lisp 1.5, and it's a heck of a lot easier to
implement/hack on than Common Lisp. So I'm becoming a Schemer, although
I doubt if it's really as much fun as Forth.

But I may go that way anyway merely because it feels like a more
enduring distributed environment. (I'm not sure about termite.
Apparently it only works with Gambit Scheme, and this seems to imply
that it's significantly non-standard in very limiting ways. So I'll
wait until there's at least a "second source" before committing myself.)

Well, this won't be significant for a few years yet. Perhaps
something newer and better will pop up in the meantime. Or perhaps
something will happen to change my perception of the current players.
Eventually I'll need to decide. It would be nice if whatever I
decided worked well with Ruby code.

Well ... of the "current players" I think Erlang is your best bet, but
download the latest full Erlang/OTP source and build it yourself, rather
than taking the Debian package(s). But in a "few years" I'm sure Ruby,
given the backing of Sun and Microsoft that exists today, will have what
it needs if the JVM and CLR support the primitives.

 

[David Vallner]

--------------enig145A651D17B46B0F7B1FAD03
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

=20
Boy, you are going to love this (frightening development, IMHO):
=20

The NZQA being hapless muppets is a new development?

*runs for the hills*

David Vallner


--------------enig145A651D17B46B0F7B1FAD03
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFZNALy6MhrS8astoRAqGMAJsGTq9GqYFdAuYao6FXvH2gohPXbQCeI9DY
Q71gNjxGzH/HycXNyUspTZQ=
=EjYH
-----END PGP SIGNATURE-----

--------------enig145A651D17B46B0F7B1FAD03--

 

[Daniel Schausser]

hi, newbie so please be tolerant....

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.

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.)

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++.

And that would be the best choice. If you want efficiency you should
definitely use C++/Visual C++. If you ask me, it's the best programming
language around, when you want efficiency, power with a resonable amount
of work when writing code.
However, Java would more suited when you want to make things fast and
not care very much about efficiency. For example, if you like to split
up a mail address like (e-mail address removed) and you want to do it
fast, you have to allocate buffers, use strtok and so on and so forth.
With java, that's piece of cake

 

[M. Edward (Ed) Borasky]

For finance programming, am not so sure. You may want to make sure you
are
good with R/Matlab and Mathematica.

R if you want free software, Matlab or Mathematica if the boss is buying.

Or you may want to learn APL, if you
want to be an arcane master dazzling the operator-overloading gang
(both pro
and con sides) with your sheer conciseness and power. Well, I don't know
APL, but that is how I imagine it to be. All kinds of crazy symbols,
where
you need a *special* keyboard.

Do finance types still use APL? I thought Matlab and Mathematica had
pretty much supplanted APL and its successors. I think you can still buy
a J license, though, and there is a fairly inactive open source APL-ish
package called A+ (aplus in Debian).

Actually, though, I think APL is the solution to global warming. For one
thing, you can write the climate model in one line of code, which uses
much less electricity than the hundreds of lines of FORTRAN the other
models use.

<ducking>

 

[Damphyr]

It seems that questions of this type always degenerate into a pro/contra
between programming languages for various application domains.

There is always going to be a difference of opinion as to which language
is suited for a particular task with majorities agreeing on specific
languages.

What I miss in these discussions, especially when someone new to
programming is asking is something that is obvious for me:
If you want to be a programmer (or a software engineer) you *have* to
now more than one language.
If you want an analogy, take painting:
Sure you can paint using color markers, but in order to be a painter you
should know how to paint with coal, oil paints, temperas, pencils etc.

Knowing a set of languages gives you the choice of the right tool for
the right job but more importantly it gives you the knowledge and
different perspectives to know which tool is the right one.
It is my belief that to get a good grasp of software design and the
principles behind good, solid software you need to learn more than one
language.

So I would say start learning C++ *and* Ruby, throw in C# to get to know
the world of strong statically typed objects and don't stop.
There's C (someone finally separate C from C++ in the minds of
programmers. I've seen too many C programs claiming to be C++ just
because they used cout) and Pascal, Visual Basic (bliach! although VB9
promises to resemble a proper language), Perl, Python (although for some
people it's a mutialy exclusive relationship between Python and Ruby),
Lua and lots more.

Cheers,
V.-

 

[Guido Sohne]

Do finance types still use APL? I thought Matlab and Mathematica had
pretty much supplanted APL and its successors. I think you can still buy
a J license, though, and there is a fairly inactive open source APL-ish
package called A+ (aplus in Debian).

I would agree with your assertion that APL has been supplanted.
Because it may have been too powerful. And too unmaintainable.

A frequently heard argument against APL is that 80% of computer programming is maintenance, and APL programs are unmaintainable: Even from the beginning, no one but the author can understand the code, and, after some time has passed, even (s)he can no longer understand it.

In most computer programming languages, the challenge might be to solve the puzzle in the fewest lines of code. In APL, it is generally a given that the solution will be one line of code: The challenge is to solve the problem in the fewest characters!

So if I were asked to bet between an APL adept and a Matlab adept, I
would probably pick the APL guy but I would also make sure to never be
in a position to have to maintain any of the APL code.

Actually, though, I think APL is the solution to global warming. For one
thing, you can write the climate model in one line of code, which uses
much less electricity than the hundreds of lines of FORTRAN the other
models use.

APL will increase global warming by taking us all straight to hell.
But yes, when they boast of characters of code, instead of lines of
code, when there isn't even an IF statement (which BTW is very common
in programming languages).

You can calculate all prime numbers with a less than 20 character
program. So each character counts quite heavily. My gut instinct tells
me that anyone who masters this language should be the one the wise
person will bet on if it comes to finance stuff.

How very off topic! But we have the New Zealand folks to keep it fair

-- G.

 

[M. Edward (Ed) Borasky]

I agree with your point, but the OP is quite obviously planning to amend his
knowledge base with a small bit of programming, just enough to accomplish
some specific objectives in a particular field.

This is actually a rather common personal goal, and in such a case I try to
think of a single language that will meet the requirement ad well as convey
good programming notions.

For someone intent on learning programming in depth, yes, multiple
languages. For someone who just wants to add to his knowledge of computers
and write a few very specific applications, that's a different story, and a
more difficult choice.

IIRC the original poster specified a domain (financial modeling and
graphics). Aside from the obvious "use the language your colleagues know
best" advice, I recommended R, because there's a lot of existing
software already in R for that specific domain, and because the
underlying runtime is very efficient on that type of problem.

But in the *absence* of a domain -- just someone who wants to "learn
programming" -- I would recommend the following:

1. Go to a good bookstore's programming section. It doesn't have to be
Powells Tech Books, but if you live in Portland, Oregon ...
2. Find a bunch of beginners' books and pick the one you think would be
the easiest to work with. Most of them are language-specific, so that
will dictate the language.

Certainly for Ruby, Chris Pine's "Learn to Program" would be at the top
of my list. I don't know about similar books for Python or Perl, but I'm
sure they exist. I'd recommend sticking with one of the "big three"
dynamic languages, Ruby, Python or Perl. Any language that requires
something more complicated that

$ ruby -e 'puts "Hello, world!"'

is not suitable for a beginner.

--

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

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

 

[Henry Maddocks]

How does C++ deliver "seriously performance critical" applications
where C can't?

It doesn't and I never said it did.

I would think a pure C code would have *better* performance, simply
because the language is simpler and easier to optimize.

I am sure you are correct, but it just seems that when writing large
fast applications people tend to choose c++ rather than c these days.
My point was that when writing large slow programs they seem to be
preferring something else. C++ is going 'niche' so why bother going
through the grief of learning it.

 

[Henry Maddocks]

And conversely, what's the problem with using C++ instead of C for
performance-critical Ruby extensions or any "fast code"?

Don't know. Just seems that most prefer c when writing extensions
etc. I haven't found the need yet so until I give it a go I'm just
going by what I see.
rubyinline looks pretty interesting. Does that support c++?

It's not THAT
much overhead compared to pure C, and I'd bet money on that it'll be
less than the cost of interpreter callouts (in doing data structure
marshalling or manipulating Ruby objects as opposed to not having
to for
a straight C++ app) is. The heaps and piles (I know, I can get
cream for
that) of inconsistency inside C would make that overhead worth it for
me, as well as the fact that doing robust code is horrible busywork.

Don't get what you mean? Are you saying C++ is less complicated then
c for writing ruby extensions or just fast code in general? Either
way that's quite a statement.

Also, for gaming, .NET seems to be gaining hold recently, if the
(sometimes amusingly tangled) dependencies new stuff has on it are a
reliable hint, although I can't tell which of the C# syntax
flavours it
is that's being used, obviously.

That's true but not all games are THAT performance critical. I've
written several 3D games in ruby without any performance problems but
then you're not going to use ruby to write Doom 3.

 

[Ryan Davis]

It's very C-ish but the libraries make the difference. However others
have written C-Interpreters also:
Eic (now abondoned)
Cint http://root.cern.ch/root/Cint.html
and another one which name I forgot...

There's tcc[1]. It's a C compiler for linux and (maybe) now windows
that is fast enough to use for scripting. This is not quite OT. It
would be great to use libtcc[2] with inline C code when compile
time is more critical than run time. And you don't have to muck
with tempfiles.

[1] http://fabrice.bellard.free.fr/tcc/
[2] http://fabrice.bellard.free.fr/tcc/tcc-doc.html#SEC22

Looks really neat. Zed pointed me at it a few weeks ago. I'd love to
play with it to experiment with an Uber::Inline::C, but it doesn't
compile on OSX and I only have so much patience for linux's quirks to
keep it running in parallels for a short amount of time.

 

[Phil Tomson]

It doesn't and I never said it did.


I am sure you are correct, but it just seems that when writing large
fast applications people tend to choose c++ rather than c these days.
My point was that when writing large slow programs they seem to be
preferring something else. C++ is going 'niche' so why bother going
through the grief of learning it.

In the past I've sometimes not been too fond of C++. However after
working a recent job where we used the Boost libs extensively I got to
liking C++ again. The next C++ standard will contain several of the
Boost libs - that'll be nice. Also, take a look at the book 'Template
Metaprogramming', it's amazing what they're able to do with templates
(functional-style pattern matching, for example). And template-based
polymorphism is much faster than the traditional use of inheritance
and virtual methods.

I don't think C++ is going away anytime soon.

Phil

 

[David Kastrup]

In the past I've sometimes not been too fond of C++. However after
working a recent job where we used the Boost libs extensively I got
to liking C++ again. The next C++ standard will contain several of
the Boost libs - that'll be nice. Also, take a look at the book
'Template Metaprogramming', it's amazing what they're able to do
with templates (functional-style pattern matching, for example).
And template-based polymorphism is much faster than the traditional
use of inheritance and virtual methods.

Well, that is a problem source in my book. Template programming is an
entirely different beast to code writing in C++, in patterns, syntax,
possibilities and skillsets. That's simply not a good state for a
programming language to be in.