For performance, write it in C - Part 2, comparing C, Ruby and Java

[Chad Perrin]

Uh, you start your interpreter/jvm/whatever, get everything started,
then time an operation. it's certainly not "impossible"

. . and of course, in Perl (for instance), things like BEGIN blocks
have no relevancy, runtime compilation doesn't occur . . .

(sarcasm collision imminent)

 

[Peter Hickman]

Not bad, really, but not even as good as the bogus Java numbers below.

The Java numbers are what was genuinely produced by the Java system on
my computer. What grounds do you have to call them bogus? State clearly
how to time a Java program in such a way that you will not call it bogus
that can also be applied to the other languages here. Remember the Perl
interpreter must be loaded and the source compiled each time the Perl
version is run, somehow I don't recall you saying that the Perl numbers
were bogus.

Second, you're not a very good Java programmer if you didn't know
about this
limit. Perhaps they didn't teach you this in Java class in 1992? (a
response
troll, admittedly)

I have never encountered this limit before, but then again I have never
had the urge to do this sort of program in Java, I used it to do ALife
and other simulations. How about you submit your version of the problem
in Java, I can then run it on my system in the manner you will describe
so that you wont call it 'bogus' and we use those timings. If you are
going to question someone's programming prowess then we can only ask
that the master himself teaches us how to to it properly.

Some versions of Java have taken as much as 15 seconds to start up on
certain platforms, and the startup time on Linux is frequently slower
than
on other platforms. Java 5 on Windows takes perhaps a second to start up
now, primarily because they do use a shared-memory cache of much of the
static data loaded at startup. Of course, it's not a startup cost of
zero,
but people simply don't use Java for command-line tools.

Where are you coming from? We use plenty of command line tools that are
written in Java here. Tools to parse, validate and transform XML. Schema
and RelaxNG checkers. There are plenty of command line tools written in
Java that are used daily by people all over the world, where you pulled
the 'people simply don't use Java for command-line tools' from?

I look forward to seeing your code.

 

[Mark Guzman]

So what is the source of "fear of C?"

I'm pretty sure it's manual memory management. Pointers are fun and
dangerous. C is a great language, it gives you enough power to shoot
yourself in the foot.

In addition, I hear it eats babies.
--mark

 

[Alexandru Popescu]

Sorry to jump into discussion, but I am wondering once again (I cannot
remember the real number) what is the purpose of this "benchmark"?

Showing that your special algorithm is better implemented/run in a
native executable? I could have told you so from the beginning. Have
you tried also with compiled Pascal? (or I don't know what else).

Or is it the fact that after working in Java since '92 (???) you have
find out about the JVM startup penalty and that any decent benchmark
would not account for that (only in case you are compairing JVM
startup times)? Should I also tell you that the JVM can be configured?
Or that you must run the code a couple of times before, because the
JVM will optimize the bytecode?

However, I must agree, I may have sound rude. Way too rude, for this
completely unuseful thread. Sorry.

/alex

 

[William James]

This is the follow up to my "Write it in C post" and is intended to
report the timings for the Java implementation that I said I would write
for Charles O Nutter and the Ruby version by Simon Kroeger. First let us
deal with the Ruby version.

The program differs from the Perl and C versions in that the various
values it requires are not precomputed. Simon's program is completely
self contained.

[Latin]$ time ruby latin.rb 5 > r5

real 0m35.793s
user 0m32.081s
sys 0m0.843s

real 0m4.703s
user 0m0.015s
sys 0m0.000s

(this is a 2.13GHz PentiumM, 1GB RAM, forget the user and sys timings, but
'real' is for real, this is WinXP)

Why is it so much slower on Peter Hickman's machine?

 

[Isaac Gouy]

The Java numbers are what was genuinely produced by the Java system on
my computer. What grounds do you have to call them bogus? State clearly
how to time a Java program in such a way that you will not call it bogus
that can also be applied to the other languages here. Remember the Perl
interpreter must be loaded and the source compiled each time the Perl
version is run, somehow I don't recall you saying that the Perl numbers
were bogus.

I have never encountered this limit before, but then again I have never
had the urge to do this sort of program in Java, I used it to do ALife
and other simulations. How about you submit your version of the problem
in Java, I can then run it on my system in the manner you will describe
so that you wont call it 'bogus' and we use those timings. If you are
going to question someone's programming prowess then we can only ask
that the master himself teaches us how to to it properly.
Where are you coming from? We use plenty of command line tools that are
written in Java here. Tools to parse, validate and transform XML. Schema
and RelaxNG checkers. There are plenty of command line tools written in
Java that are used daily by people all over the world, where you pulled
the 'people simply don't use Java for command-line tools' from?

I look forward to seeing your code.

Perhaps you could post the 5x5 Java and C programs on your website then
folk like Charles O Nutter can satisfy themselves that the numbers are
not bogus.

 

[pat eyler]

Perhaps you could post the 5x5 Java and C programs on your website then
folk like Charles O Nutter can satisfy themselves that the numbers are
not bogus.

And the Ruby version please.

 

[William James]

In my younger days, I did a lot of development in assembler languages,
and for many years my main high-level language was FORTRAN. Towards the
end of my FORTRAN days (about 1990) I was still dropping into assembler
for speed, even though the (FORTRAN) compilers were quite good by that
time. C compilers really sucked, especially for numerical applications.

So you know only clunky, crude, archaic languages, the newest
of which dates back to 1973 or earlier. Someday you ought
to move out of the dark ages and program in Ruby.

Now here's where I'm going to put on my asbestos suit. I think the
difficulty of C development is *vastly* exaggerated by the fans of
"dynamic/scripting/interpreted" languages! In addition, I think the
difficulty of *assembler* development is vastly exaggerated

(Note that Eddie is no fan of Ruby.)

One or more of these is true:

1. You don't program in Ruby.
2. You're not thinking.
3. You're not being honest.
4. You're simple-minded.

Compared to Ruby, programming in assembly language is very
tedious, very error-prone, very time-consuming, and laden
with a multitude of miniscule details. To a lesser degree,
the same is true of C. And assembly code, of course, is not
portable to another processor.

 

[Chad Perrin]

And the Ruby version please.

While the Ruby version (assuming it's the same version) was posted to
the list, it would be nice to have them all in the same place. While
you're at it, you could post the Perl version and whatever other
versions we've discussed. I'd do it myself, but for the lack of
availability of the Java version here.

 

[Chad Perrin]

(Note that Eddie is no fan of Ruby.)

One or more of these is true:

1. You don't program in Ruby.
2. You're not thinking.
3. You're not being honest.
4. You're simple-minded.

Compared to Ruby, programming in assembly language is very
tedious, very error-prone, very time-consuming, and laden
with a multitude of miniscule details. To a lesser degree,
the same is true of C. And assembly code, of course, is not
portable to another processor.

It might be more accurate to say that he's just reformulated the same
situation those of us who are Ruby fans have described differently --
but in doing so, he doesn't realize it's a reformulation, and thinks
he's correcting us.

foo = :ruby_fan
bar = :eddie
baz = :chad_perrin

foo.says('Ruby's easy to use. C is harder. Assembly is much worse.')
bar.says('Assembly's okay. C is easy. You just have to be careful.')
baz.says('I guess it depends on your perspective.')

The problem is:
bar.says('You're all wusses.').also

 

[Keith Gaughan]

You can time it inside java by fetching the system clock before and after.


It makes sense to do that for long running applications but in this
case it doesn't. If what you really wanted to do was calculate this
latin squares thing then the startup time matters. Are there any JVMs
around that keep a shared daemon running for all processes to share so
as to avoid some of the startup time?

It also makes sense to run the algorithm a few times to ensure the JIT
compiler gets the hint that it's supposed to convert the bytecode to
native code. Otherwise you're only getting how quickly the bytecode
interpreter can interpret the code rather than the raw speed of the
code.

--
Keith Gaughan - (e-mail address removed) - http://talideon.com/
TAURUS (Apr.20 - May 20)
Take advantage of this opportunity to get a little extra sleep,
because you're going to miss the bus again today anyway. You will
decide to lose weight today, just like yesterday.

 

[M. Edward (Ed) Borasky]

M. Edward (Ed) Borasky wrote:



So you know only clunky, crude, archaic languages, the newest
of which dates back to 1973 or earlier. Someday you ought
to move out of the dark ages and program in Ruby.

Well ... I'm certainly moving towards Ruby. I just need to unlearn Perl.
I know other languages -- Java, C, Forth, Lisp, and Perl -- but most
of the programming I do these days is in R. R is hardly a clunky, crude
or archaic language.

Now here's where I'm going to put on my asbestos suit. I think the
difficulty of C development is *vastly* exaggerated by the fans of
"dynamic/scripting/interpreted" languages! In addition, I think the
difficulty of *assembler* development is vastly exaggerated


(Note that Eddie is no fan of Ruby.)

Note the asbestos suit. I *am* a fan of Ruby, relative to Perl,
Python, PHP and Java. Ruby is a younger language, so it's learned from
the mistakes of Perl, Python, PHP and Java. But I don't get paid to
write Ruby -- I get paid to write R and maintain Perl.

Now R versus Ruby is a tough call.

One or more of these is true:

1. You don't program in Ruby.

I do as a hobby, but not for a living.

2. You're not thinking.

No ... I wanted to challenge some assumptions that have been promulgated
for a *long* time. In the olden days, it was "assembler for speed,
higher level languages for portability and ease of use." Now it's "C for
speed, scripting languages for ease of use." The portability argument is
gone -- C runs everywhere -- more places than Java.

3. You're not being honest.

About what?

4. You're simple-minded.
About what?
Compared to Ruby, programming in assembly language is very
tedious, very error-prone, very time-consuming, and laden
with a multitude of miniscule details.

I never found it tedious or error prone relative to the high order
languages available to me at the time, and that included FORTRAN, C,
Lisp and Forth. Programming in *any* language is tedious, error prone,
time consuming and laden with a multitude of minuscule details.

In most cases, assembly language typing is as dynamic as Ruby's. Most
decent macro assemblers let you do things like meta-programming, parsing
of expressions, domain-specific languages, and a fair amount of
syntactic sugar. As far as I'm concerned, the only *legitimate* argument
against assembly language is that it is tied to a specific machine
architecture. It isn't portable.

 

[Chad Perrin]

Well ... I'm certainly moving towards Ruby. I just need to unlearn Perl.

Wait -- what? Why? Learning Ruby is making me a better Perlist, and
knowing Perl is helping in my learning of Ruby. Both languages have
their advantages and disadvantages, and both have their place in my
toolkit.

I've never subscribed to the "one language" philosophy of programming,
and I don't get it when people talk as though they do. Was that a joke?

Note the asbestos suit. I *am* a fan of Ruby, relative to Perl,
Python, PHP and Java. Ruby is a younger language, so it's learned from
the mistakes of Perl, Python, PHP and Java. But I don't get paid to
write Ruby -- I get paid to write R and maintain Perl.

Perl has learned from the mistakes of Perl, Python, PHP, Java, and even
Ruby. Wow. You really seem to have it in for Perl.

I'd actually be less inclined to take it amiss if you just disliked
(modern-day standards) high level languages than this pick-and-choose
thing where you like Ruby and hate Chevy -- er, I mean Ford. No, wait,
Perl. Seriously, though, reading that email of yours was a bit like
reading those Chevy vs. Ford bumper stickers.

 

[M. Edward (Ed) Borasky]

It might be more accurate to say that he's just reformulated the same
situation those of us who are Ruby fans have described differently --
but in doing so, he doesn't realize it's a reformulation, and thinks
he's correcting us.

foo = :ruby_fan
bar = :eddie
baz = :chad_perrin

foo.says('Ruby's easy to use. C is harder. Assembly is much worse.')
bar.says('Assembly's okay. C is easy. You just have to be careful.')
baz.says('I guess it depends on your perspective.')

The problem is:
bar.says('You're all wusses.').also

Well, no ... I'm simply saying that when I was doing it, I did not find
assembly language programming more difficult than programming in a
higher-level language. The last time I wrote assembly code for money was
in 1990, and for fun in 1995. For those Rubyists who say, "Ruby has made
programming fun *again*," well, it's always been fun when I got paid and
my code got used, or when I was building something for myself. The
language has never mattered.

Ruby is a very well-designed higher-level language -- one of the best
I've seen. Which is why I'm learning Ruby and not Python or PHP or Lua
or C#. If my boss came to me Monday and said, "We just bought a company
that wrote a killer app in Lua, and we want you to maintain it," well,
I'd learn Lua.

 

[M. Edward (Ed) Borasky]

Wait -- what? Why? Learning Ruby is making me a better Perlist, and
knowing Perl is helping in my learning of Ruby. Both languages have
their advantages and disadvantages, and both have their place in my
toolkit.

I've never subscribed to the "one language" philosophy of programming,
and I don't get it when people talk as though they do. Was that a joke?

Well ... let's just say I think Ruby is a vast improvement on Perl. I learned Perl when Perl 4 was the reigning standard. I don't particularly like the way Perl 5 does objects and references. I wrote a lot of code in Perl 4 and I still maintain it, but I wouldn't write *new* code in Perl now that I have Ruby.


Most of what I have written in Perl is stuff that Perl (4) is good at.
Regular expressions, extracting numerical data from miscellaneous text
files, arrays and hashes. Ruby has all of that, plus a coherent object
model, a coherent "Enumerable" model, lambdas, blocks, continuations ...

I've never subscribed to the "one language" philosophy either, although
I've worked places that do. Right now I have two main languages, Perl
and R. But I don't want to write new code in Perl.
I'm simply tired of it ... it lacks "elegance". It's useful ... it's
been around longer than Ruby, so there are more libraries and packages
for it. It's not going away. It's evolving. But Ruby's not going away
either. Ruby is evolving.
I haven't seen them ... I have a Ford if it matters. I pick on Perl
because I know more Perl than the others. I don't know enough about
Python or PHP to pick on them. There appear to be lots of folks here
that will pick on Python and Java anyway.

 

[Chad Perrin]

Well ... let's just say I think Ruby is a vast improvement on Perl. I
learned Perl when Perl 4 was the reigning standard. I don't particularly
like the way Perl 5 does objects and references. I wrote a lot of code in
Perl 4 and I still maintain it, but I wouldn't write *new* code in Perl now
that I have Ruby.

I pretty well loathe the Perl object model, and the syntax for
references could use some work, but object oriented programming isn't
the whole world of programming -- and Perl handles a lot of things with
more elegance than most other languages (such as lexical closures, which
are, frankly, slightly less clunky than Ruby's closures). Ruby does a
lot of things better than Perl, but there are some significant
shortfalls, too.

The notable thing that jumped out at me about Ruby when I discovered it
is this: Between Perl and Ruby, I don't need to learn Python at all.
I'm awfully glad for that, since Python basically makes my eyes bleed.
Call it a personal failure if you like -- it is definitely at least
mostly personal bias -- but that's the way it is.

Most of what I have written in Perl is stuff that Perl (4) is good at.
Regular expressions, extracting numerical data from miscellaneous text
files, arrays and hashes. Ruby has all of that, plus a coherent object
model, a coherent "Enumerable" model, lambdas, blocks, continuations ...

Perl's unnamed blocks/lambdas/subroutines/functions/whatever are
actually more consistent, syntactically, than Ruby's -- though for many
purposes, Ruby's implementation is slicker. It's a trade-off that
provides a net win or net lose depending on what I'm doing.

I'm simply tired of it ... it lacks "elegance". It's useful ... it's
been around longer than Ruby, so there are more libraries and packages
for it. It's not going away. It's evolving. But Ruby's not going away
either. Ruby is evolving.

It doesn't lack elegance. It doesn't encourage it the same way as Ruby,
but it certainly enables it. In fact, I'd say it enables it more fully
than Python, though encourages it less. Again, a trade-off (though Ruby
does seem to avoid having to trade away much in this case, from what
I've seen so far).

I haven't seen them ... I have a Ford if it matters. I pick on Perl
because I know more Perl than the others. I don't know enough about
Python or PHP to pick on them. There appear to be lots of folks here
that will pick on Python and Java anyway.

PHP's just too easy to pick on. Seriously. It's an anemic syntax
wrapped 'round an enormous bucket of functions that seem to have been
chosen for native implementation by way of a dart board. No challenge
in picking on that one.

Frankly, I think one of the biggest reasons Java and, to a slightly
lesser extent, Python get picked on more often than any other
non-Microsoft languages in almost all programming communities is that
both languages' communities tend to have sort of a "God's Chosen
Language" sense of entitlement -- not universally, but just prominently
enough that people tend to generalize. Stereotyping both Java and
Python, each in its own way, as inspiring a community of zealots is just
an obvious thing to do when looking for a language to disparage. It's
probably quite unfair in both cases, of course. In any case, I see
hints of one-true-language-ism in every language community, sometimes
more obnoxiously than at other times (including here).

Python's a great language, in principle, and is reportedly a great
language in practice for those whose proclivities it suits. It doesn't
suit mine, so I'll stick to Ruby and Perl. Java . . . well, let's just
say that as far as I can tell it's not nearly as great a language as
some seem to think. I'd rather use Java than Visual Basic, but beyond
that there isn't much competition with Java for its low ranking in my
hierarchy of preferred languages.

I'm sure there are some here who'll use that statement as an excuse to
dismiss anything I say about Java or Python from here on out, of course,
and I'm not entirely sure I won't catch some flak up front but, hey,
full disclosure an' all.

Despite my thorough dislike and the negative language "features" that
inspired it, I acknowledge that Java has its uses too. Rather than
disparage it as the wrong language for everything I do, I just choose to
avoid doing the things for which it's the right language as much as I
can manage.

I think that's quite enough off-topic rambling for one email. The point
of this last bit of nattering on, if it can be said to have a real
point, is that every (reasonable) language has its advantages and
disadvantages. I happen to mesh well with those of both Perl and Ruby,
but not those of Python or Java. Nearly categorical dismissals of Perl
such as yours (implying, it seems, that with Ruby around Perl is
useless except insofar as it gets you employment) are pretty much
valueless, just as similar treatments of the language I don't like would
be.

 

[M. Edward (Ed) Borasky]

I pretty well loathe the Perl object model, and the syntax for
references could use some work, but object oriented programming isn't
the whole world of programming -- and Perl handles a lot of things with
more elegance than most other languages (such as lexical closures, which
are, frankly, slightly less clunky than Ruby's closures). Ruby does a
lot of things better than Perl, but there are some significant
shortfalls, too.

I don't think I've ever needed lexical closures. The structure of most
of the code I write comes from the application domain rather than the
language. My main application domain is extracting performance data from
various text files and making coherent analytical models from it. A
combination of Perl 4, R, and relational databases is what I've evolved
over the years to do that, and that's the code I write and maintain on a
daily basis.

Given the available libraries for Perl, Ruby and R, I _could_ do the
entire job with any one of the three languages, at least on Linux. I
might have trouble making Ruby do it all under Windows, but I haven't
tried it.

The notable thing that jumped out at me about Ruby when I discovered it
is this: Between Perl and Ruby, I don't need to learn Python at all.
I'm awfully glad for that, since Python basically makes my eyes bleed.
Call it a personal failure if you like -- it is definitely at least
mostly personal bias -- but that's the way it is.

But I already know Perl ... my original comment was that I needed to
unlearn it to learn Ruby. It's mostly syntactic -- curly braces,
semicolons, scalars beginning with dollar signs, etc. I *never* liked
the Perl dollar sign/at sign/percent sign syntax convention.

And I need to learn at least to read Python, because some of the
software I use is written in it. I don't think I'd need to write Python
code though.

Frankly, I think one of the biggest reasons Java and, to a slightly
lesser extent, Python get picked on more often than any other
non-Microsoft languages in almost all programming communities is that
both languages' communities tend to have sort of a "God's Chosen
Language" sense of entitlement -- not universally, but just prominently
enough that people tend to generalize. Stereotyping both Java and
Python, each in its own way, as inspiring a community of zealots is just
an obvious thing to do when looking for a language to disparage. It's
probably quite unfair in both cases, of course. In any case, I see
hints of one-true-language-ism in every language community, sometimes
more obnoxiously than at other times (including here).

Actually, there *is* one true language. It's called the "formal
semantics of programming languages". But more to the point, I think
there are far too many "general purpose" programming languages.

A working programmer needs to know C, plus whatever languages are used
in his or her shop. Regardless of what the designers and communities for
those other languages intend(ed) them to be, they are in fact occupying
an economic niche. They are special-purpose languages by that definition.

In this sense, Ruby is on the edge of becoming a special-purpose
language as the engine underneath Rails. I don't have strong opinions
about whether that's good or bad, but I do have a strong opinion that it
is the economic niche that Ruby will occupy for the foreseeable future.

Python's a great language, in principle, and is reportedly a great
language in practice for those whose proclivities it suits. It doesn't
suit mine, so I'll stick to Ruby and Perl. Java . . . well, let's just
say that as far as I can tell it's not nearly as great a language as
some seem to think. I'd rather use Java than Visual Basic, but beyond
that there isn't much competition with Java for its low ranking in my
hierarchy of preferred languages.

I once wrote a program in Java. This was in 1996 or thereabouts, and my
reasons for using Java were:

1. It would run on Windows and all the flavors of UNIX that I was
dealing with at the time. Visual Basic only runs on Windows.
2. It had hashes, garbage collection, a reasonable object model, and
useful compile-time error checking.
3. It was faster than Perl for number crunching.

Java was a new language at the time -- I think it was Java 1.1. It was
certainly before Swing, Java 2, etc. I've never had an opportunity to do
any more Java programming, so I don't know how it is to the folks who
use it for a living. What I *do* know, however, it that there are a
*lot* of high-quality applications written in Java.

I think that's quite enough off-topic rambling for one email. The point
of this last bit of nattering on, if it can be said to have a real
point, is that every (reasonable) language has its advantages and
disadvantages.

Even macro assembler? This *is* about performance, right?

 

[Chad Perrin]

I don't think I've ever needed lexical closures. The structure of most
of the code I write comes from the application domain rather than the
language. My main application domain is extracting performance data from
various text files and making coherent analytical models from it. A
combination of Perl 4, R, and relational databases is what I've evolved
over the years to do that, and that's the code I write and maintain on a
daily basis.

That's kind of a specious argument. Similarly, one never really needs
switch/case statements -- you could always do it with if/else. In fact,
you don't need if/else either -- you could just do it with a series of
carefully crafted if statements. If that ends up being too ugly for
you, there's always the option of creating a block from which you use
break statements (or equivalent for your language of choice) to
approximate elses.

. . but it's awfully convenient to have else and, occasionally,
switch/case statements.

But I already know Perl ... my original comment was that I needed to
unlearn it to learn Ruby. It's mostly syntactic -- curly braces,
semicolons, scalars beginning with dollar signs, etc. I *never* liked
the Perl dollar sign/at sign/percent sign syntax convention.

. . and my point is that you shouldn't have to "unlearn Perl", and I
find it shortsighted and narrow to make that kind of statement with any
seriousness.

Actually, there *is* one true language. It's called the "formal
semantics of programming languages". But more to the point, I think
there are far too many "general purpose" programming languages.

That sounds vaguely similar to the ridiculous arguments I hear from
Microsoft-fanboys who disparage the variety of GUIs available for Linux,
and the number of distros. You're welcome to pretend you live in a
monoculture world, but please don't do anything to convince anyone else
to agree with your fewer-choices-is-better approach to programming while
I'm in the world. I like having options. What's to stop Python from
winning the choice-elimination war? I'd find programming considerably
less enjoyable.

A working programmer needs to know C, plus whatever languages are used
in his or her shop. Regardless of what the designers and communities for
those other languages intend(ed) them to be, they are in fact occupying
an economic niche. They are special-purpose languages by that definition.

Really? Funny, I've known quite a few excellent professional
programmers who never learned more C than is taught in a Programming 101
course, and a few that didn't even learn that much. They seem to get by
just fine. Perhaps you should define your use of "working programmer".

In this sense, Ruby is on the edge of becoming a special-purpose
language as the engine underneath Rails. I don't have strong opinions
about whether that's good or bad, but I do have a strong opinion that it
is the economic niche that Ruby will occupy for the foreseeable future.

I don't see that happening. I see Rails getting a lot of attention, and
many people being attracted first to it then, by way of Rails, to Ruby
in general. Ultimately, people seem to be getting enamored with the
language, with Rails as merely the "gateway drug". The number of people
I've run across who do one project in Rails, then go on to use Ruby
without ever touching Rails again, outnumbers the people who come to
Rails and don't continue to use Ruby for anything else.

I once wrote a program in Java. This was in 1996 or thereabouts, and my
reasons for using Java were:

1. It would run on Windows and all the flavors of UNIX that I was
dealing with at the time. Visual Basic only runs on Windows.
2. It had hashes, garbage collection, a reasonable object model, and
useful compile-time error checking.
3. It was faster than Perl for number crunching.

Those are good reasons.

Java was a new language at the time -- I think it was Java 1.1. It was
certainly before Swing, Java 2, etc. I've never had an opportunity to do
any more Java programming, so I don't know how it is to the folks who
use it for a living. What I *do* know, however, it that there are a
*lot* of high-quality applications written in Java.

That's true, too. I still don't like it -- and, in many cases, I think
Java was chosen for those applications because of the excellent
marketing Java has received, rather than because Java was the Right Tool
For The Job. Some of those applications might have been better written
using other languages. That doesn't mean they're bad apps, though.

Even macro assembler? This *is* about performance, right?

Yeah, even macro assembler. I'll leave that work for someone else, for
the time being: it's not my cup of tea.

 

[M. Edward (Ed) Borasky]

That's kind of a specious argument. Similarly, one never really needs
switch/case statements -- you could always do it with if/else. In fact,
you don't need if/else either -- you could just do it with a series of
carefully crafted if statements. If that ends up being too ugly for
you, there's always the option of creating a block from which you use
break statements (or equivalent for your language of choice) to
approximate elses.

. . . but it's awfully convenient to have else and, occasionally,
switch/case statements.

I can't remember the last time I used a case statement. It was probably
in the mid 1970s in FORTRAN. And R programmers don't tend to use as many
control structures as other language programmers do, favoring instead
the built in vector logical and indexing operators.

. . . and my point is that you shouldn't have to "unlearn Perl", and I
find it shortsighted and narrow to make that kind of statement with any
seriousness.

No ... I don't have to unlearn the parts of Perl that are common to
Ruby. I do have to unlearn putting semicolons at the end of every
statement, using curly braces for blocks, using tabs for indentation
instead of spaces, and starting an ordinary scalar working variable with
a dollar sign. I have to unlearn taking a string like "3.56" to an
integer power and getting a double precision value back. I have to
unlearn "$a{'Sep'} = 3;" and replace it with "a['Sep'] = 3", etc.

I don't see that happening. I see Rails getting a lot of attention, and
many people being attracted first to it then, by way of Rails, to Ruby
in general. Ultimately, people seem to be getting enamored with the
language, with Rails as merely the "gateway drug". The number of people
I've run across who do one project in Rails, then go on to use Ruby
without ever touching Rails again, outnumbers the people who come to
Rails and don't continue to use Ruby for anything else.

Well, I downloaded Rails ... I bought the book(s) ... I worked through
half of the tutorial ... and decided I wasn't interested in building
that kind of web application. And until David Black's book came along,
there really was no sense at all I could make from Rails. I could take
someone else's Rails code and edit it without breaking it too badly,
re-implement something like the demo apps, etc., but I couldn't actually
sit down, say, "I want my web application to do this, this, this and
this ...", and then sit down and make it happen. I simply didn't have a
reading knowledge of Ruby.

Now I think I could do that; I'm just waiting for an excuse to build a
web app. Meanwhile, I'm building something else, and I'm building it in
pure Ruby. And I'm doing it in pure Ruby against the advice of folks who
think I should drop into C for the number crunching or use an existing
number crunching library written in C.

That's true, too. I still don't like it -- and, in many cases, I think
Java was chosen for those applications because of the excellent
marketing Java has received, rather than because Java was the Right Tool
For The Job. Some of those applications might have been better written
using other languages. That doesn't mean they're bad apps, though.

Well ... some of the Java applications I like are "Compendium",
"DBDesigner4", Protege, the PEPA Workbench, the GUI wrapper on PRISM,
and a couple of audio applications I haven't used in a while. In those
cases, I think Java was chosen for its portability and for its
convenient GUI. It's really being used as a "scripting language" in the
case of PRISM ... the underlying application is in C for speed. The PEPA
Workbench was originally written in ML, but I don't think the ML version
had a GUI. All the rest are "pure Java".

They're all GUI applications, and I suspect the only alternative to Java
would have been Tcl/Tk (or some other language with a Tk GUI) at the
time these applications were conceived. There are more choices now --
everybody has a Tk GUI, nearly everybody has a GTK, QT, Fox, and wx GUI
toolkit, and nearly everybody can do all this on Windows, Linux, Mac and
Solaris. Does Java still run on a Mac?

Yeah, even macro assembler. I'll leave that work for someone else, for
the time being: it's not my cup of tea.

The macro assembler programmers I know drink coffee ... a lot of coffee.
Do Ruby programmers drink Ruby Mist?

 

[Chad Perrin]

No ... I don't have to unlearn the parts of Perl that are common to
Ruby. I do have to unlearn putting semicolons at the end of every
statement, using curly braces for blocks, using tabs for indentation
instead of spaces, and starting an ordinary scalar working variable with
a dollar sign. I have to unlearn taking a string like "3.56" to an
integer power and getting a double precision value back. I have to
unlearn "$a{'Sep'} = 3;" and replace it with "a['Sep'] = 3", etc.

Why? Why not just remember that it's a separate language? I've
experienced a little negative transferrence of knowledge between Ruby
and Perl because of their similarities, but once I got past that minor
hurdle my growing knowledge in each language has only helped with my
ability to learn more about the other. If you aren't doing the same,
you're doing something wrong.


[ snip ]

Now I think I could do that; I'm just waiting for an excuse to build a
web app. Meanwhile, I'm building something else, and I'm building it in
pure Ruby. And I'm doing it in pure Ruby against the advice of folks who
think I should drop into C for the number crunching or use an existing
number crunching library written in C.

Thanks for making my point for me.

Well ... some of the Java applications I like are "Compendium",
"DBDesigner4", Protege, the PEPA Workbench, the GUI wrapper on PRISM,
and a couple of audio applications I haven't used in a while. In those
cases, I think Java was chosen for its portability and for its
convenient GUI. It's really being used as a "scripting language" in the
case of PRISM ... the underlying application is in C for speed. The PEPA
Workbench was originally written in ML, but I don't think the ML version
had a GUI. All the rest are "pure Java".

They're all GUI applications, and I suspect the only alternative to Java
would have been Tcl/Tk (or some other language with a Tk GUI) at the
time these applications were conceived. There are more choices now --
everybody has a Tk GUI, nearly everybody has a GTK, QT, Fox, and wx GUI
toolkit, and nearly everybody can do all this on Windows, Linux, Mac and
Solaris. Does Java still run on a Mac?

Yeah, you can still run Java on a Mac. Of course, for the purposes you
describe, I suspect Smalltalk would have been a better choice for those
applications in most cases. Smalltalk is underrated and marginalized to
the point that almost nobody thinks of it when choosing a language for a
project, though, unfortunately.

The macro assembler programmers I know drink coffee ... a lot of coffee.
Do Ruby programmers drink Ruby Mist?

I'll let you know when I'm a "Ruby programmer", I guess. I'm just a
Ruby hobbyist for the most part, right now. In fact, I'm really kind of
a Perl and PHP programmer, and a lots-of-other-languages hobbyist. I
also get paid more for my english writing than my Perl, PHP, Ruby, et
cetera, writing -- so I guess I'm an English programmer, in a sense.

Hey, whatever pays the bills.