85% languages (was Re:Linux fat/bloated)

Sy Ali sy1234-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Thu Apr 6 23:03:45 UTC 2006


On 4/6/06, Paul Nash <paul-fQIO8zZcxYtFkWKT+BUv2w at public.gmane.org> wrote:
>
> >It is unfortunate that these new languages like Perl came out .. that
> >we can't all use one single good old language like Ruby.  But that'll
> >never happen.  All that choice nonsense people keep going on about.
> >Everyone wants to do their own half-assed thing so the world is full
> >of 85% quality stuff.
>
> Minor point, but Perl has been around for longer than I care to admit
> knowing about.  Certainly much longer than relative newcomers like Ruby,
> PHP, python or even TCL.

Ruby is a lot older than you realise.  =)


> Different languages for different uses:
<snip>
> ... and so on.

> There's a *nix tradition of building lots of small tools that do one thing,
> and do it well.  I remember the flames when ls(1) had a 'sort' option
> added, as this turned it into a tool that did two things and duplicated
> what another tool did.

I always thought the unix philosophy of specializing and splintering
applications into unique tasks made the learning curve quite a bit
steeper.

For me, it's still so steep that I'm not willing to bother with
chaining tools together when I can find one tool which can do things
passably well.

But even in cases where it's best to chain tools together, it's so
very very frustrating to have to learn something new completely from
scratch and have to figure out how the extra pieces fit together. 
Usability varies between tools.  They all work differently and so one
needs to learn new skills for each new application.

For example, take rsync over ssh.  Two tools that taste great
together.  But for a user, they just want the ability to synchronize
in a few common ways.. but one must learn to work with the two of them
separately and then together.

This isn't a strong argument, since there is good documentation out
there.  Well, sortof good documentation.  Well.. lots of mediocre
HOWTOs.  The answers are there and I found them easily enough.  Still,
this isn't always the case.


Even now I don't understand why I can't pass more parameters to an
application to have it do additional things.

I mean.. if the other application exists, then have the first
application use it transparently.


> As for the rest, they have their places (I suppose).  If you think that
> something is half-arsed and only 85% there, either don't use it (and the
> tools that depend on it) or roll up your sleeves and provide the missing
> 15%.

I still argue that it's not possible to be handed anything at 100%
because every developer is off working on their own 85%.

As a user, I think that I would end up learning the tool and bending
it to my uses instead of working on the remaining 15.


> My own personal peeve is the number of projects that start at version 0.01,
> and somehow stabilise at version 0.9.  If it works and is usable, call it
> version 1, for god's sake!

I think it's funny when a project reaches the .9 and goes belly up,
and somehow everyone who's anyone is using it like it's stable..
because it's been around for so long.

I also think it's morbidly funny when spectacularly cool applications
sit around at the "almost usable" stage and never make their way to
completion.  Somehow, the logic that another interested developer will
swoop in and take over just doesn't happen in the real world.
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list