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

[Tomasz Rola]

On Mon, Dec 23, 2019 at 08:36:07AM +1100, Dave Horsfall wrote:
> On Sun, 22 Dec 2019, Arthur Krewat wrote:
> 
> >Define "popular" - what's actually in use, versus what people want
> >to use. And job listings versus research. Both of those would lead
> >to different results ;)
> 
> I've been keeping a list of all the languages that I've ever used
> since I was a stripling; it's up to 48, and that's counting all
> assembly languages as one etc.  That's about one language for every
> year that I've been a
> programmer :-)
> 
> Yes, I try and teach myself a new language whenever possible; I'm
> currently looking at Ruby as a lightweight replacement for Perl (I
> run screaming from Python and its silly indentation), and Perl/Tk
> for a GUI for some scripts that I wrote (mostly puzzle solvers).

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 at bigfoot.com             **