"W. Kent Starr" wrote:
> 

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

I find that writing in Java I spent even more time creating more decent
foundational constructs to do the rest of my work in because I can't
stand what is there than I do in languages like C++.  C is low-level
enough that I can code Scheme or something and weave everything else on
top of that.  Just kidding, but it is a thought.  :-)

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

Well, when I get unhappy I start ignoring what I am "supposed to" be
doing and start writing better foundations.  But it is frustrating.  


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

Mostly.  I find I need just a bit of pressure to meet a modest schedule
to be both happy in my sandbox and productive.  
 
> > 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? ;-)
> 

Sure, sure.  Which is why I want to have enough intermingling with the
Java world to sneak into the project as well respected and well
integrated tool and go from there.  


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

I know.  I've been there.  Which is one of the reasons I talk about
things like include file hell.

> 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! :-)
> 

It is too low-level and provides almost no real tools for managing
programming in the large (or even the medium).  The notion of more or
less manually hacking out a bunch of include files to stand in for
interfaces and throwing in a very weak macro facility and #defines
everywhere to try to get around some of the weakness of the language, is
a travesty that has been around for over 20 years that I personally know
of.  It is a a huge waste of time.  What is wrong with having an
environment that knows about all the classes, functions and modules that
you can draw from and aids you directly in organizing, browsing,
documenting and using them?  What is wrong with making it a standard
part of the tools available that I can see immediately all the callers
in some environment of a method and all the implementers?  Stuff like
this has been around in Lisp and Smaltalk environments for 15 or more
years.  It is a travesty that so much coding is done with almost no
support or decent tools.  Ok, getting down from the soapbox.

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

I very rarely code any method that is longer than a couple of dozen
lines and even my classes are usually small.  I am a lazy woman.  Why
write pages of code that I will later have to wade through if I can
express what is needed in a few well crafted lines?   I hate mumbling
and fumbling about in real life.  I hate it even worse in code.
 
> > > 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. 

Except the variety of constructs is very limited so only data struct /
class declarations, general constants and a very weak sort of macro can
be defined. Just enough to make it next to impossible to cleanly express
even that little, much less what it would be good to have.  And the
hierarchy of includes in a project and the hacks used to manage not
including things twice and attempting to call an include that has a
dependency on something not yet fully included and so on wastes all
sorts of mental energy fighting with a stupid file-based implementation
of trying to satisfy the real needs.  It is time we gave this junk up
imho.   Combine this with static typing and you get your four hour
projects where promoting good reusue or refactoring something nasty so
everyone on the project can benefit results in the entire project
recompiling yet again.  Who has incentive to do good software when they
pay that can of price in lost productivity every day?


>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!

At least a dll is a reuseable component (or a hack at making one a level
above includes).  Some of the component issues are themselves quite
subtle (like callback interactions and time order dependencies across
modules for instance).  But a few more tools would make it a lot easier
to straighten such puzzles out.  What amazes me is that we spend so much
of our career automating and writing tools for everything but our own
work.  

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

A truly bright system knows what you @require.  It presents alternatives
and dependencies as you go.  It tracks the choices made and keeps the
configuration information for the resulting system and flags unexpected
environment changes it was not designed to handle.  We don't have it yet
but it isn't that difficult.  The really hard thing is capturing the
semantics of modules well and computationally working with them.  But we
can make many tools two orders of magnitude better than what many are
working with now without solving that problem. 

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

I have some ideas.  Now I just need some time (without going broken or
making dependents destitute).
 
> > 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. :-)
>

Dunno.  I think it is for producing something better than it is or for
as has been said, a high-level machine language.  Although I can
actually write better optimizing code in Lisp.  
 
> >
> > I am surprised if it is true that noone is working hard on this
> > problem.
> 
> 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! :-)
>

I may get to it soon.  Unfortunately/fortunately there are a lot of
other things on my plate.  One thing I am tempted by is to take the Kawa
(Scheme on Java) foundation and use that to implement Ruby on Java.  In
other words, implement Ruby in Scheme and then compile it using Kawa
into very efficieint JVM byte codes.  Kawa was nicely layered to provide
a basis for implementing multiple language on the JVM not just Scheme.  

Of course, that is the whole hog sort of approach.  In the meantime it
would be good to simply be able to manipulate Java world constucts (most
through reflection) really well from Ruby and call Ruby scripts from
Java with Java parameters and such.  There are probably a set of levels
of interaction that could be acheived more quickly.  But often doing it
this way ends up with a structure that is not conceptually clean and has
to be reworked or discarded for the next layer of needs.  But I haven't
really had a chance to look into it yet.

- samantha

 
> 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