From: "W. Kent Starr" <elderburn@...>
Date: 2001-03-11T11:46:26+09:00
Subject: [ruby-talk:12399] Re: Java on Ruby, Ruby on Java, JRuby? where?

On Saturday 10 March 2001 15:30, Samantha Atkins wrote:
> Kent,
>
> > I think this is reasonable. It should be noted however, that Ruby is
> > developed and used _primarily_ in unix environments and there is some
> > feeling within the unix communities that Java is "evil". This may be more
> > politically motivated than technical
> ><snipped>
>
> The problem with the position that Java is evil is that Java is also,
> for better or worse, ubiquitous.  
> <snipped>
> environments.  These environments are not simply machine-0S but
> machine-OS-language and so on.  I want tools that allow me to
> effectively use pieces of code written in whatever language together.
>

Of course, this is a very good point. In his recent writing ESR brings up the 
point that "glue" (this is not in his words) is an essential construct within 
the unix environment. So is component based architecture. Programs are 
written (often in C) to do a single task and do it well. When the results of 
multiple tasks are required, these components are "glued" together and 
sometimes piped through to other components that are "glued" together and so 
forth until the desired end result is effected.

With shell, the "glue" can be powerful, and far more so with languages such 
as Perl and Ruby. By contrast, the original batch language in Dos was quite 
weak, although a number of utilities were developed to expand it. Batch was a 
"glue" language of sorts, as well, although not nearly on the level of Ruby, 
Perl or even Bash.

> I am not sure about a statement that Ruby is mostly for the 'nix
> environment when I read what seems like (I haven't taken an exact count)
> many hundreds of past posts about using Ruby on Windoze, with COM and so
> on.  Surely windoze/COM environments are no less evil and proprietary
> than Java!

Well, the way the language is stuctured is somewhat telling of its birthplace 
and heritage. :-)  But most of matz has stated he works in unix and most of 
the established Ruby gurus to date seem to be of the same fold, judging by 
their postings. What you are seeing, perhaps, is the result of the fact that 
Ruby is gaining a great deal of attention with the publication of the book 
and articles. In today's world, notoriety of any sort throws you into a 
Windows world, and you begin to attract larger numbers of interested parties 
whose primary experience and environment is a Windows one. And, of course, if 
we are to address the issue of "ubiquitous", Windows has more or less coined 
the term in the software industry. :-)


> > The corporate community OTOH appears to have swung to the opposite
> > extreme and views Java as _the_ "magic bullet". Everything seens to be
> > "Java this. Java that", which you have noted by stating that your
> > curren't paying gigs are heavily Java-oriented. Personally, I feel that
> > both extremes are wrong; Java definitely has its place, but that place
> > isn't everywhere for everything. I also believe, especially among
> > corporate recruiters and outsourcers that too much emphasis is placed
> > upon the _how_ of a project and not enough upon the result. These things
> > are MO only, though.
>
> You are at least partially correct.  And I certainly will agree that
> Java is a miserable language to code in. 

Which means the outcome is frequently miserable code. As careful, 
conscientious and thorough as _you_ may be,  despite your misery, there are 
ten others whose main goal is to get that #$@&! out the door and go home, sit 
back with a beer or whatever and gain respite from their day spent in "java 
hell" (or whatever one's particular concept of hell may be). If, as has been 
discussed in other threads here, code is expressive, then where one is 
uncomfortable or miserable, that discomfort will, in some way, be expressed, 
often subconsaciously in subtle ways. As a general rule, "happy people" build 
solid things upon firm foundations; "unhappy people" cobble together whatever 
is necessary to get them out of the situation for at least the moment, and 
gain some short-term respite. "Do what you love" is more than a truism; it is 
a basis for a major reinvention of economcs theory that IMO merits serious 
consideration. In our own culture, a majority of those who are "rich and 
famous" didn't start out to become that way; rather, they started out doing 
what they love (whether sports or computer programming, or entertainment), 
and doing it well (out of respect for what they love.) Again, "happy people" 
build "happy things" which many "unhappy people" will buy so they, too, can 
become "happy".

> Every day I write it in I get
> ticked by how difficult it is to express things elegantly, cleanly and
> without a lot of donkey typing work to satisfy and extremely lazy and
> moronic compiler.  

Have you thought of trying Ruby? ;-)

> But this also makes the point that we need tools that
> aid in using code produced in whatever environment and weaving these
> together well.  

I totally agree here. Which is why I harp on unix from time to time. Unix, 
from the standpoint of those involved in the computer industry, is more than 
a collection of OS's.  In ESR's words it is a "way of thinking".  

> C is not a very good candidate for such a glue
> language.  C is too low level and notorious machine/OS tied and
> compiled.
>

Well, compiled throws C/C++ out of the "glue language" category anyway, by 
definition. Part of the raison for interpreted languages is that shortcutting 
the write-compile-debug cycle set speeds development. Immediate feedback 
enhances understanding. And minor tweaks are easily made. (If you have a 
large project with a four hour compile time this is very important!)  BTW I 
get reports of these, the example is not an exaggeration. Also there is the 
fact that C/C++ code can be very buggy, partly as a result of the above and 
where shortcutting is attempted with something for which shortcutting can be 
very dangerous. The last I read, the "industry rule of thumb" for _released_ 
product was one bug for every 55 lines of code. For one 55 line utility this 
is not such a big deal, even 5500 lines is reasonably addressable. But when 
you get into hundreds of thousands of lines, it becomes potentially 
disasterous, either for the end-user or the manufacturer or both. The 
"secret", of course, is to write only 54 lines of code for each module and 
avoid that bug altogether! :-)
 
(Ok, I am being facetious, kind of; there may be some wisdom in adopting that 
sort of practice, but it would require major restructuring of standard design 
paradigms)

> > Pesonally,  am not overly fond of Java as, again IMO only, it is not as
> > trim, mean and lean as is, say, C and it lacks the expressiveness of,
> > say, Ruby. I have used, and in some cases customized (where source was
<snipped>

> Includes are a nightmare
> that should not be inflicted on future generations. :-)  

Well, the concept is a good one -- bundle frequently and commonly used 
constructs into a single file and write to that. And, almost everybody has 
them...whether they are called "include"s, "require"s or whatever.  The 
problem comes when my code is writtern to a later version of myinclude.h 
which is different from the version of myinclude.h you have on your system 
(and you didn't know that one of of the several thousand include files from 
various libraries, distros, etc. has been functionally changed) and you try 
to compile Dave's "superguy.cpp" and, well, it doesn't compile (or worse, 
compiles and feeds back subtle, erroneous results. And it's not just a 
programmers' headache, either. Many Windows end-users find program A stops 
working because the just-installed program B overwrites MSWHATEVER.DLL! But 
the only feedback _they_ get is a GPF or blue screen of death when they try 
to run A again. Not a pretty sight!

But, the converse is also a headache. But the alternative, rebuild the wheel 
into everything, is also a headache (and very inefficient). 

And, frankly, I don't know what the answer to this should be :-(

> someone who has used C/C++ for 17 years.  I am very very good at it but
> it wastes a lot of brain cycles.

Personally, I find C a special kind of "fun", sort of like cooking over an 
open fire instead of throwing something into the microwave. :-)

But, in a production situation, the microwave may be necessary (both as an 
allegory and as a literal event *smile*)

> > > In any case, I really want a good Java <-> Ruby story bad.  Is there
> > > any such thing out there?  Is someone working on such?  If not, why
> > > not?
> >
> > Hopefully the above files will get your going in the right direction.
> > Maybe _you_ will become _the_ Ruby <=> Java spark of inspiration. Who
> > knows? :-)
>
> I am surprised if it is true that noone is working hard on this
> problem.
>
> - samantha


Well, I was sorta hoping that you would check out the Ruby/Java files (which 
I haven't yet) and report back to the list so we would _all_ know where to 
start looking and working to make Ruby and Java, if not friends, at least 
afunctional team. You see, if somebody else does the work, then I get to have 
the fun! :-)

Anyway, I am sure there is an answer, or the beginnings of one. I totally 
agree with you that a Ruby/Java cooperation would help advance Ruby. Java 
doesn't need any help in that regard, but, hey, parasitism work for me! :-)

Regards,

Kent Starr
elderburn@mindspring.com