Re: [COFF] Gnu Smalltalk or...? [was: Most Popular Programming Languages 1965 - 2019]

On Dec 23, 2019, at 3:13 PM, Tomasz Rola &lt;rtomek(a)ceti.pl&gt; wrote: On Mon, Dec 23, 2019 at 08:36:07AM +1100, Dave Horsfall wrote: This question is not addressed to you only: I am considering Gnu Smalltalk for such role (Perl & Python replacement). I knew Python 1 and 2 once, but since they made a (what appears to me as) botched[1] move to Python3 I decided I wanted to try something else. This includes rewriting few scripts I had made in Python into this newly choosed language, as I am also moving into new OS installation (perhaps OpenBSD) and I guess there will be no Python2 when I finally make the move. Or if there is Python2 now, it is going to go during one of upgrades which is scheduled (by design) to happen twice a year or so. The scripts are nothing hard, stuff like filtering lines of input etc. Sometimes filtering bytes. Python is nice as long as one stays inside the "batteries included" limits, i.e. as long as one makes use of libraries provided as part of the language. I was rather happy with those standard libraries. As of Perl, I have to relearn it every time I make attempt to use it and it just cannot stick. AWK does not have things like built-in stat function and checking exit status of command in child sh process seems to be a bit cumbersome. I wrote few simple scripts with it after I finally learned I should not write those in Perl. But it is far from perfect for overall scripting. I am yet to teach myself GSmalltalk, but after skimming the docs it seems to have the right classes for such scripting which I would like to do - UNIX/Posix type of environment, text files, maybe some bin<->uuencode mingling. This kind of things could be also done in sh, but I deteste starting thousands of processes just to grep stuff in files and then do something to thousand(s) of matched files (or process a mailbox of 10000 messages and do something to 40% of them). I guess it could be a bit faster to do it all inside one process (and a bit less stressing for sys accounting database). Some of those use cases might be nicely addressed with AWK, but some of them would be better written in Perl (which cannot stick in my head) or Python (which I would rather not use too much). Another nice choice for me is some Scheme dialect with extensions for systems programming - Chicken and Gauche seem to fit (but I have to read the manual). Surprisingly, Elisp is quite well equipped with plethora of nice functions (calling external command, finding files in dir etc) but the need to parse output in buffers and inability to read files in chunks disqualifies Emacs as (standalone) scripting engine. I consider using Common Lisp (no need to learn it, so one problem off my head), but I would not say it is perfect for scripting. Albeit some scripts I wrote in it (sbcl) and I liked the experience. As I am changing my default scripting language and OS, I would like to kill one more bird. I would like to be able to compile it from sources on a system which had been just installed from CD. In case of *BSD, it means I choose a pack/set with sources and compiler (dev tools), the installer unpacks it onto empty disk, there is no net connection. Then I put a pendrive with my stuff, unpack a source code of said scripting interpreter, call make; make install and only after this I go online (or not). So in this last case, if, for example, I chose sbcl, I would have to: 1. install base system 2. compile+install clisp (should compile with "any C") 3. compile+install sbcl (it wants a CL already installed to compile from source) A bit strange, but should be doable. I did 2+3 on my current system more than once. I am yet to try to compile GSmalltalk from sources and see how it goes. So the language should be compilable with as little external dependecies as possible, and with just the tools which either can be found on bare install, or can be recompiled from USB with my sources - the sources need not be the newest and glamourest ones, just usable for my purposes. I can easily make a sh script to automate such "compilation chain", and it can take an hour or a week, no problem. I would appreciate any words of wisdom from those who went this/similar path and could comment or hint a different choice. [1] Overally, maybe my sentiment against Python as such grew over a decade and it was not really related to the 2->3 transition. Maybe rewriting some parts of the code is not that big deal really, but I feel aversion to rewriting which is not linked to introducing new features or bugs. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola@bigfoot.com ** _______________________________________________ COFF mailing list COFF(a)minnie.tuhs.org https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff