X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Rugxulo Newsgroups: comp.os.msdos.djgpp Subject: Re: Python, Perl, Lua, Ruby -- anybody?? Date: Fri, 22 May 2009 15:04:21 -0700 (PDT) Organization: http://groups.google.com Lines: 167 Message-ID: <8ea89a75-ac4b-4235-b372-b7a8ffc51945@z19g2000vbz.googlegroups.com> References: <7705c9030905132340u49a2fd15ke564b9ce930c09db AT mail DOT gmail DOT com> <61f9fc90-2d0d-4db9-baa0-0a26ef663ce3 AT g20g2000vba DOT googlegroups DOT com> NNTP-Posting-Host: 65.13.115.246 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1243029862 26486 127.0.0.1 (22 May 2009 22:04:22 GMT) X-Complaints-To: groups-abuse AT google DOT com NNTP-Posting-Date: Fri, 22 May 2009 22:04:22 +0000 (UTC) Complaints-To: groups-abuse AT google DOT com Injection-Info: z19g2000vbz.googlegroups.com; posting-host=65.13.115.246; posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO User-Agent: G2/1.0 X-HTTP-UserAgent: Opera/9.64 (Windows NT 6.0; U; en) Presto/2.1.1,gzip(gfe),gzip(gfe) To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Hi, On May 18, 9:46=A0pm, "A. Wik" 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