Hacker News Reader

Comment by thanatropism | Hacker News Reader

I might be biased because I'm from the hordes that are moving from Stata and Matlab to Python (but then there are the hordes attracted to data analysis now), but that was never really Python's strong suit, nor its target market.

I mean, I was always into little scripts, but I used Tcl and then Perl.

View on HN

Back in the 1990s, Python was promoted as a web programming language. This was back in the days when everyone used CGIs. Python came with an cgi module, while in Perl you had to download cgi-lib.pl. I even helped maintain a Python web application that was all CGI-based.

So I can assure you that at one point Python was trying to be in the "short run applications" space. They may have given up since then, but that's a different issue.

As for me, I do write little scripts in Python. I don't like how most of my run time is spent waiting for Python to get ready.

What I really don't like is using NumPy. I tend to re-implement features I want rather than reach for NumPy because that 0.2s import time irks me so much. And it's because the NumPy developers want people to do "import numpy; numpy.reach.into.a.deep.package", so they import most of its submodules.

They used to also eval() some code at import, causing even more overhead. I don't know if that's gone away.

Ah, the days when I knew quite some people doing Zope consulting.

Apparently it is still around.

Ah, Zope. I remember when the IPC Python conference seemed to double in size (I think it was the DC one). 1/2 the people were seemingly there because of Zope.

Both Tcl and Perl are dead languages walking these days, and it's Python that's displaced them. It absolutely competes in that market.

Markets are a funny thing. Both "dead" languages are thread safe and can easily run separate interpreters per thread.

See: "THREADS DONE RIGHT... WITH TCL"

https://www.activestate.com/blog/2016/09/threads-done-right-...

I do have to wonder if Tcl would have gained significantly greater mindshare if the syntax had been more Algol-like.

> Markets are a funny thing. Both "dead" languages are thread safe and can easily run separate interpreters per thread.

Perl threading is officially recommended against IIRC? In either case, "threads" in either of them don't share memory (except explicitly and manually), at which point what you have is multiprocessing by a different name.

In Perl 5 threading things are only "shared" semantically. In reality, there is an extra interpreter running where the "shared" variables live, and any value fetches and stores are handled with the `tie` interface (see http://www.perlmonks.org/?node_id=288022 for more information).

In Perl 6 on the other hand, everything is always shared and you can use high level constructs such as atomic increments, supplies, taps, `react` and `whenever` so you don't have to think about any (dead)locking issues as a developer.

Tcl has an "easy" threading mode where each thread runs its own interpreter, and a "hold my beer" mode where you can spawn threads within a single interpreter.

Tcl also has synthetic channels, so you can stay in easy mode but open a bi-directional read/write channel with the two ends in separate threads, with readable/writable events assigned, so you can do automatic event-driven information sharing between threads.

I don't know any other language that gives you options like that.

Quite a few sysadmins around here have a different point of view regarding Perl.

Dream on.

Reply on news.ycombinator.com