Righ, somebody. Reminds me of the old Divorced Man's exposition of what
"First, you get a ring. Then you give it away. Then, you get a house. And
Subject: Re: SF Weekly's Ultimate SF Date lineup :-)
Living aboard a Cessna 172 would be challenging, but I did meet a
couple at an airshow in Point Mugu in 1995 or so that had converted an
old seaplane (it was a bit larger than a PBY, I think) to something of a
floating, flying RV.  They visited a lot of airshows and covered a lot of
miles.  I'm sure maintenance (on a 50+ year old airframe), fuel (for two
large radial engines) insurance and other costs were out of my price
On a more realistic note, the flight to Half Moon bay was probably 2
hours of flight time at about  $75/hour in the Cessna.  Not exactly a
cheap date, but that's nothing compared to the money I've spent on her
since.  (And loved every minute of it, Darling!!)
> Subject: Re: SF Weekly's Ultimate SF Date lineup :-)
> > Proving, once again, that aviators get all the chicks...
> Just as long as they have the wherewithal
> I think Turpin once calculated that one
> could do a decent amount of messing about
> for about $30K of boat and $12K/year in
> What are the equivalent figures for live
> (How difficult would it be to find the
> harbormaster, after mooring to the top

On Wed, 2002-08-28 at 09:58, Gary Lawrence Murphy wrote:
>
> And a Java program, due to the extensive class libraries, will weigh
> in at 10% the number of lines of the equivalent C program.  QED.
My typical Java-to-C conversion doesn't increase the lines of code by
more than 20%, and a fair portion of that is the implementation of
additional features that drove us to do the conversion in the first
place.  Some things are substantially more succinct when written in C
than in Java.  C and most other mature languages have an endless
collection of libraries.  I personally don't use anything beyond the
core libraries of any language that much though.
On a tangent, I find libraries nearly useless for a great many things
due primarily to the fact that most of them are so general that a given
non-trivial API almost always has a context in which it will function in
a pathological manner.  Code reuse is wonderful and all that, but
libraries frequently make design trade-offs that won't work for me even
if they theoretically do exactly what I need.  Unfortunately, it isn't
particularly easy nor does it make a nice simple API to design a library
that really is optimizable to a wide range of design cases.  I've built
a small collection of flexible psuedo-polymorphic APIs over the years
that I tend to use, but it is a pretty ugly solution for code reuse when
you get right down to it.
-James Rogers
jamesr@best.com