X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f Newsgroups: comp.os.msdos.djgpp Date: Tue, 19 May 2009 02:46:17 GMT From: "A. Wik" Subject: Re: Python, Perl, Lua, Ruby -- anybody?? In-Reply-To: <61f9fc90-2d0d-4db9-baa0-0a26ef663ce3@g20g2000vba.googlegroups.com> Message-ID: References: <7705c9030905132340u49a2fd15ke564b9ce930c09db AT mail DOT gmail DOT com> <61f9fc90-2d0d-4db9-baa0-0a26ef663ce3 AT g20g2000vba DOT googlegroups DOT com> Organization: DOS Research Labs Mail-To-News-Contact: abuse AT dizum DOT com To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sat, 16 May 2009, Rugxulo wrote: > Hi, > Hi, Here come a few rants inspired by your observations on the ever increasing software sizes. (Also, I have rants about glibc2 threads, UTF-8, and an interesting comparison of gzip - compress - bzip2 and cat, but I'm saving those for another day.) I do, however include a little bit of conspiracy theory right away (well, not really right away: you may have to skip some paragraphs to get there)... enjoy, while I catch some sleep! > On May 14, 1:40 am, Blair Campbell wrote: > > > > I recently compiled perl 5.10.0 with DJ-ELF and it sometimes comes in > > handy to have perl with some modules for configure scripts. > > 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. Not saying Perl > isn't useful, but it bothers me that everything was Perl 5 forever > (why? was Perl 4 useless?). Perl 6 has been in planning for a long > time, several rough implementations exist, but it's incompatible > (another rewrite). > > perl561 exe 1,192,448 Dec,15,2003 11:03:24pm A... > perl588 exe 4,330,496 May,11,2007 03:03:20am A... 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. (Other distributions of Linux, such as Slackware, are significantly, but not satisfactorily better.) (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.) 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 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.) Interestingly, it's not DOS/Win9x that has the worst problems with the above trends, but aging Unix systems. A 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): # objdump -m vax -b binary --start-address=0xd4e7e -D /kmem-page80000plus.dump|more objdump: Can not allocate 33296384 bytes after allocating 30504 bytes I bet it was planning to read the whole dump of all 32 MB of memory the machine has into... memory? ...before starting to disassemble the 13 bytes or so that I needed [1]; fortunately, the error caused it to abort the plan before wasting too much of my time. I'm pretty sure that a real mode DOS or a PDP/11 programmer wouldn't even think about doing something so ridiculous (I know I don't; and yes, I am sporadically working on both a VAX disassembler and a x86 one): or in other words, memory barriers have a positive influence on programming habits and resulting code. > 3,920,947 Python-2.0.1.tgz > 6,410,852 Python-2.2.3.tgz > 8,154,677 Python-2.4.6.tar.bz2 > 11,156,901 Python-2.6.2.tar.bz2 > > bloated as it looks. Python 2.0's main addition was Unicode, and then > came 2.2, 2.4, 2.6.2 is latest "compatible" with a few backported > features while 3.1b1 (beta) is the incompatible branch. Just like Perl > 6, they will support some automatic translation between old 2.x and > new 3.x, but it just seems like such a moving target, I just wonder > how useful something is if it gets deprecated so quickly. "Deprecated"... Could that be a conspiracy to force you to "up"grade to the latest bloatware, because older code will no longer work (as it's too full of "deprecated" stuff)? > 207,202 lua-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?). > 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. (I wonder if DJ has similar reasons for writing and running his own flavour of list management system...?) Returning to the topic of scripting languages (although the language I'm going to mention can also be compiled) - What about Forth? It's a language I've heard great things about, but I haven't looked into it sufficiently to confirm its excellence. Among other things, it's used in some boot loaders and console firmwares (ie. BIOS-like systems that support early stages of hardware initialisation and booting), and if my recollection is correct, the Sun Sparc is one example of such a system, but it may be used in some other "alternative" alternative architectures too. -aw [1] ... 13 bytes or so, which I needed In order to decide precisely what and where to patch. It all turned out all right in the end, after copying a 32 byte chunk out of the memory dump with "dd" and using objdump on that. Patching was then a matter of looking up instruction bytes to assemble (from a book or data sheet) and using printf "\x8F\x00,,,etc", piping its output into "dd" with the right parameters to specify the target file offset within the kernel image file, and last (as well as least), rebooting. (Just remember "conv=notrunc" also, or dd will truncate the kernel.) [2] Yes, the one with the FDIV bug!