On Monday, 16 December 2019 at 11:33:32 +1000, Robert Brockway wrote: Interesting overview, but I have my doubts about its accuracy. Lisp seems to have been too popular in the mid-1980s, and at the same time he claims that Ada was the most popular language. Both seem highly unlikely to me. And then JavaScript got off to a flying start: over 4% in Q2 1995, quite an impressive for a language that was introduced in Q3 1995. So without much more proof I'd take it with a pinch of salt. Greg -- Sent from my desktop computer. Finger grog(a)lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA _______________________________________________ COFF mailing list COFF(a)minnie.tuhs.org https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff

On Sun, 22 Dec 2019, Arthur Krewat wrote: 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). -- Dave _______________________________________________ COFF mailing list COFF(a)minnie.tuhs.org https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff

You and me, both, brother, you and me both ;)

> you are right. However take into consideration that py is very popular

So is Taylor Swift ;)

I work in Python for my day job. Every day I use PyPi, the third-party package repository, and every time I do I miss CPAN. Sure, there was a lot of crap in CPAN but the repository itself was well organized.

Thomas Paulsen <thomas.paulsen(a)firemail.de> writes: The package system may have been good, but what I remember most clearly from working with it is how the dependencies would always get in each others' way. "This package depends on version 0.0.3a of pl-foo, but also on this other package, which in turn depends on version 0.0.3b of pl-foo, and of course 0.0.3a and 0.0.3b have completely incompatible APIs, so you're screwed." That's probably the start of the path leading to Docker, right there. -tih -- cpan. cpanic. cpandemonium. _______________________________________________ COFF mailing list COFF(a)minnie.tuhs.org https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff

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

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 ;)