systemd discussion

[夜神 岩男]

On Wed, 2011-06-15 at 20:15 -0700, Joe Zeff wrote:
> On 06/15/2011 04:19 PM, 夜神 岩男 wrote:
> > This sort of
> > developer often can't tell you who Fred Brooks, Eric Raymond, Donald
> > Knuth, Ken Thompson, or anyone similar are
> 
> And let's not forget the sane genius, Daniel J. Alderson.  JPL is still 
> using his programs to navigate space probes 25 years after his death, 
> but except for a few SF fans, nobody's ever heard of him.  We've all 
> heard about people who could write FORTRAN in any language, but Dan was 
> the only person I ever knew who could write PL/1 programs in FORTRAN. 
> He also knew how to turn off array bounds checking and do pointer 
> arithmetic in FORTRAN by addressing an array out of bounds.  I know; I 
> helped him do it back in the early '80s.

OK, you got me with the pointer arithmetic in FORTRAN trick. That is
precisely the sort of thing that the word "hack" was originally intended
to indicate and the sort of wizardry only available to those who have a
complete understanding of what is going on in the code, compiler and
hardware.

Which brings me to a point I haven't spelled out but hinted around that
Tim-of-the-famously-ignored-mailbox hit on "... not keen on... having
[the] computer staggering under the burden of a behemoth desktop." If
you take a look at the actual functionality inherent in the new desktop,
there is no solid reason for it to be so heavy, other than the choice of
implementation platform. Scripting some functionality in a high-ish
language (JavaScript, if I'm not mistaken) saves development time, but
it is a burden to all forever once developed. I would move that with
something as basic as the desktop this may be a good initial protoyping
model, but moving the desktop code closer to the metal would be a sound
solution.

But the discipline (and it is a discipline) of refactoring is lost on
many these days. On the other hand, consider the success Gnote had over
Tomboy. One required Mono and C#, the other was a faithful refactoring
in C++ that turned into a smashing success, blowing away the original
(tomboy was just orphaned, I believe). Despite the supposed benefits of
C#/Mono portability (or rather, "supposed portability of C#/Mono"),
standards-compliant C/C++ code can be recompiled to run (nearly)
anywhere. But doing it right (e.g. standards compliant and with as much
correct use of standard libraries as practical) is hard. And people
don't like that. In any case, by the end tomboy acted as a prototype for
what became the more mainstream app, Gnote. (Please note that I am not a
fan of overoptimization in code -- much evil lies down that tricky
path.)

We could probably lighten the system considerably if we backed down a
bit from the en vogue languages and spent some time refactoring the
good-but-heavy ideas and injected a bit more of the Unix philosophy into
those refactoring projects.

Another way of saying the above is that scripting used to be utilized
primarily for one-shot tasks, personal functions and prototyping, while
things like C and Lisp tended to wind up in production code. Scripting
provides great glue -- its awesome glue -- and it gives a developer of a
custom project a way to show the customer/world/himself in a jiffy "This
is what the thing will do/look like -- and if you like it we'll refactor
this in a real language and have it industrial strength in a few
months". Today, however, entire desktop managers and ERP systems are
written on interpreted language platforms in pure script (and I don't
mean bash). This is not, I think, what was originally intended when
higher languages were invented. All those layers introduce a lot of
overhead that I find a little awkward (and mystifying sometimes, to
uncover where a problem is occurring -- is it the interpreter, the
kernel, the virtualization layer, the script itself; what stack where is
host to a bug?).

And anyway, there are so many highly individualized vanity
languages/platforms now that you have to learn a whole new API just to
get under the skin of any new project now -- because the guy who had a
good idea for a new mail client learned Python in school but the guy who
had a good idea for a new MTA learned Ruby On Rails and the guy who
wrote the latest SPA you want to use on your new experimental mail
machine did it in Eiffel -- or whatever. This is not that odd of a
situation. I love languages, but this proliferation is getting a bit
ridiculous. One of the benefits Unix used to enjoy was its fairly
standardized (not so much in comittee, just de facto standardized) set
of development features and the omni-presence of bash and C. Once that
became bash, C and, sat, GTK we were really in business... but its just
gotten out of hand now, and that is not where Unix was originally meant
to go in my opinion.

But it certainly allows a single author to re-write ten versions of the
same book which all amount to "Basic problem solving and deconstruction
in [Some language]". If that author teaches at a community college he
looks like a genius too, and might land a real book deal eventually with
O'Reilly if he blogs enough and annoys the right folks at a convention
or two... but I digress.

Blah blah. The whole post was digression. I'm going to crawl back in my
hole of email silence and write something terribly complicated. In ed. I
feel that I need to get back in touch with my roots -- one character
change at a time.

And now I resume my mailing list coma for another 10 years.

-Iwao