Re: Python, Perl, Lua, Ruby -- anybody??
- From: Rugxulo <rugxulo@xxxxxxxxx>
- Date: Fri, 12 Jun 2009 20:13:54 -0700 (PDT)
On May 22, 5:04 pm, Rugxulo <rugx...@xxxxxxxxx> wrote:
On May 18, 9:46 pm, "A. Wik" <r...@xxxxxxxxxxxxxxxxxxx> wrote:
Perl 5.6.1 was like half the size of 5.8.8. I don't like it when
things double in size in such a relatively short time.
That is, of course, because unlimited disk & memory sizes, not
to mention unlimited CPU speed and unlimited just-about-
everything-else have spoilt programmers into not even trying to
control quality of existing code, but rather adding new features
so that they can list the latest buzzwords among the supported
features of the latest release presented on their frontpages,
thus luring bloatware Linux distributions like Red Hat into
downloading and including it in their package systems, so that
*they* can list the latest buzzwords on *their* frontpages.
Well, some new things I've discovered (corrections welcome):
Red Hat just released Fedora 11, which supposedly crams OpenOffice and
Java on one CD thanks to compression. And they use GCC 4.4.0 to host
everything. If all that's true, that's quite a feat, because a lot of
other distros don't include half that and yet still use a full CD
(which is annoying, even with a fast connection).
Is it just me or is Linux very media-oriented these days? When every
distro tries to include MPlayer, XMMS, Firefox, Flash, etc., no wonder
they all top out at huge sizes.
say, XP/Vista support is essential for maximum popularity of
any software, and given the native size of those systems, users
hardly notice a few GBs more.)
Compression sucks, or at least nobody uses decent tools. And it's true
that nobody cares, sadly.
Well, even the just-released Linux 2.6.30 now supports LZMA
compression of the kernel ("33% smaller"). I wonder how that compares
to UPX. Of course, removing write support for VFAT probably slimmed it
a bit too. ;-)
Even FreeBSD or NetBSD kernels are like 10 MB (or 5 MB gzip'd) while
OpenBSD is 6.5 MB or so. And that's not counting modules (although I
think OpenBSD doesn't use any)! Weird, I tell ya, just plain weird.
They say you can strip it down a bit (and some even claim *BSD is much
much easier to recompile, but I wouldn't know), but for a floppy dude
like myself it won't ever be small enough, at least not without lots
of manual tweaking and size optimizing.
Perl has been quite useful for a long time (although my
experience is limited to using and fixing the perlscripts of
others with mixed success) and perhaps even too useful... Perl
is the "Practical Extraction and Reporting Language" and it's a
suitable tool for that purpose, in those cases where grep, cut,
sort, uniq, join, sed, awk, tr, find, xargs, etc. are
insufficient or otherwise unsuitable.
I don't know why people use grep, tr, expand, etc. when sed will do
the job for them. In other words, there is some overlap that could be
condensed a bit. I guess that's one argument for using Perl instead.
At one time, there were efforts towards a microPerl or TinyPerl, even
for use in place of the autoconf and pals. It does bug me when you
need twenty different utils just to bootstrap something simple. Of
course, it also bugs me when "ztouch" (very very very small script)
requires the big, bloated Perl just to run. :-P
Look at this:
[ Vista ] - Fri 06/12/2009 >upx --best --lzma --all-filters perl.exe -
307614 -> 105988 34.45% dos/exe perl.exe
Now, granted, it's "4.0.18 patch level 36" from 1993, but still, now
THAT's small. At that time I can see how Perl would be considered
useful. But nowadays with all the bloated extras, it seems like
overkill, esp. when all the tools it's supposed to replace still exist
(and get bigger and bigger, ahem GNU).
I would probably benefit
from using it myself in many such situations, as I'm prone to
start (but rarely finish) a real program instead after finding
the basic tools (and vim) unsatisfactory. The opposite problem
seems far more prevalent, however, and scripts that should
serve, at best, as prototypes, proofs of concepts, or
quick-and-dirty fixes for occasional problems are frequently
taking the place of proper compiled programs designed with speed,
compatibility, reliability, good resource management, and other
noble goals in mind. (Although I suppose it must be acknowledged
that scripts may have advantages such as portability, once the
interpreter has been ported.)
Well, Perl can byte compile (or compile with GCC via "perlcc" although
that apparently doesn't work with the DJGPP version or else I did it
incorrectly). And while "s2p" is a cool hack and potentially useful if
you need to do "real" programming, I can't imagine too many urgent
scenarios for that (will have to play with it some more). Maybe if you
couldn't guarantee that sed would work as promised or wanted to slurp
the whole file in for better speed or needed stronger regex support. I
dunno, even Perl isn't quite ubiquitous in every OS by default (e.g.
NetBSD), so that hurts its odds a bit.
Every Linux distro advertised for "old computers" these days really
only targets PII w/ 128 or 256 MB of RAM. They don't know minimal. It
must be really hard, even with 2.4.x, I dunno. Even DeLi Linux (using
uClibc) had to up its requirements when they switched to Unicode for
There is a minimal DeLi 0.8.0 console-only version that runs in very
small amounts of RAM, but I'm unsure what exactly it can do. And of
course the new TinyCore (off-shoot of DamnSmallLinux?), and it's
little brother MicroCore, seem promising, at least regarding size.
But anyways, FreeDOS will always have lower requirements. (And 2038
final was just released like yesterday, finally, see Sourceforge.)
Viva la DOS! ;-)
- Re: Python, Perl, Lua, Ruby -- anybody??
- From: Rugxulo
- Re: Python, Perl, Lua, Ruby -- anybody??
- Prev by Date: Re: problems with gnu configure on djgpp
- Next by Date: Re: problems with gnu configure on djgpp
- Previous by thread: problems with gnu configure on djgpp
- Next by thread: Re: Python, Perl, Lua, Ruby -- anybody??