Mail Archives: djgpp/2009/05/22/18:15:05
Hi,
On May 18, 9:46=A0pm, "A. Wik" <r DOT DOT DOT AT dynamite DOT narpes DOT com> 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.
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.
> (Other distributions of Linux, such as Slackware, are
> significantly, but not satisfactorily better.) =A0
Slackware 13.0 supposedly will have a new package format (lzma) and
optional 64-bit support.
> (Needless to
> 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.
> 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... =A0Perl
> 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. =A0
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
There should be a contest to port certain apps to Perl 4 from Perl 5.
Maybe it's already been done, who knows. Maybe I'll finally bother to
learn Perl 6 when they get to 9 or so. (And rant and rave of
course.) ;-)
> 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. =A0The 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. =A0(Although I suppose it must be acknowledged
> that scripts may have advantages such as portability, once the
> interpreter has been ported.)
Well, Python is said to be powerful and easy to learn. But it's also
supposedly slow, definitely slower than even some other common
interpreters, and slower than compiled code too (of course). But you
can lessen that with bytecode or else the lack of a compile-edit cycle
makes up for it when developing.
> Interestingly, it's not DOS/Win9x that has the worst problems
> with the above trends, but aging Unix systems. =A0A shining
> example follows (in spite of the fact that objdump is at least
> a compiled executable rather than a perl or python script (but
> maybe we'll get there?), and it can be quite useful at times,
> but not this time):
>
> =A0 =A0 =A0 =A0 # objdump -m vax -b binary --start-address=3D0xd4e7e -D /=
kmem-page80000plus.dump|more
>
> =A0 =A0 =A0 =A0 objdump: Can not allocate 33296384 bytes after allocating=
30504 bytes
Originally, I think GNU tools were just clones of *nix tools, but they
officially allowed improvements too, as long as they didn't use more
than 1 MB of RAM. Even C++ originally worked on such an old machine.
Ah, the good ol' days.
> I bet it was planning to read the whole dump of all 32 MB of
> memory the machine has into... memory? =A0...before starting to
> disassemble the 13 bytes or so that I needed [1];
"RAM is cheap, buy more!" So much for "free" software! :-P Plus,
your motherboard can only handle so much anyways (e.g. 2 GB for this
laptop here), so you can only upgrade so much. :-/
I could rant on and on about this, but it's more the programmer's
fault than C or portability (although those don't always help, heh).
> fortunately,
> the error caused it to abort the plan before wasting too much
> of my time. =A0
Yeah, you're lucky it didn't swap you to death!
> I'm pretty sure that a real mode DOS or a PDP/11
> programmer wouldn't even think about doing something so
> ridiculous
"But C iz teh portablah!" Doesn't mean they have to code so blindly!
(Yes, it's apparently true, assembly programmers care more about
performance than C guys, I guess.)
> > 207,202 =A0 =A0 =A0 =A0lua-5.1.4.tar.gz
>
> > Now I know why Lua is so popular, it's tiny!!
>
> I was discouraged from trying it a few years ago, because
> they wrote that they don't support integers, only floating
> point, and integers (of which pointers are a special type,
> as far as I'm concerned) are what I need almost exclusively.
> However, the surprisingly reasonable size suggests that
> there may be something good about Lua as well (and maybe
> they fixed the data types?).
I'm not sure, but I think it still has that same problem. However, I
don't know how much that affects things. Anyways, it must be easier to
compile, so that's a big advantage right there!
> > Why they didn't just use that instead of Python for
> > GDB 7.0 I'll never know.
>
> Python is indeed heavy stuff... the Mailman mailing list
> management system that I used to run on a Pentium 60 MHz [2]
> was written in Python and had an appetite for resources
> like no other process on the system; for comparison, the
> SMTP and web servers easily handled their parts of the
> job (of running the list) with quick response times.
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
0.8.0, sadly.
> Returning to the topic of scripting languages (although
> the language I'm going to mention can also be compiled) -
>
> What about Forth? =A0It's a language I've heard great things
> about, but I haven't looked into it sufficiently to confirm
> its excellence.
Yes, Forth is quite nice although I don't really know it (tried once,
gave up). However, I'm not sure which ones can be embedded, certainly
a few, but I can't remember. Anyways, the last GNU Forth to be
precompiled for DJGPP was 0.5.0, and later (when I asked) Bernd
couldn't compile for 0.6.2 or so because he only had an x86-64 box
around (although I guess nowadays is better with DOSEMU supporting
that). Now it appears they've even released 0.7.0 (!), but I'm highly
skeptical, so I don't even want to bug them about compiling it (or
even waste my own time). I guess 0.5.0 is "good enough" for now.
http://www.jwdt.com/~paysan/gforth.html
http://www.complang.tuwien.ac.at/forth/gforth/
http://groups.google.com/group/comp.lang.forth/topics?lnk=3Dsrg
- Raw text -