dkfellows

There are a very few truly global entities there, most notably the current working directory and the environment variables. They're global because the underlying concept leaks through into C code you link in and subprocesses you launch, and changing that would be really quite nasty. The Tcl interfaces to those things are internally protected against multithreaded access, of course, but you can still get yourself into a mess that way.

The bit I really like about Tcl is how easy it makes asynchronous I/O across all its supported platforms. This doesn't sound significant to Linux users, but on Windows that's a very very big deal...

Long term, the Cisco router support became the non-recursive execution engine (of Tcl 8.6) which stopped things from blowing up on the tiny stack sizes that Cisco equipment is configured with.

And which gives us tailcalls and coroutines.

There's no macros because there's uplevel (and upvar) instead. It's a different way to do homoiconicity. And the variable binding rules are quite different, which makes for quite a different language in practice.

The current main project for Tk, targeting the 9.2 release next year, is porting to work on Wayland. (But not dropping support for X11, Windows or macOS.) Apparently, the widget demo is now working (i.e., you could probably build some applications on it) but advanced features like accessibility support are still in progress.

You need tools adequate to the task, but the task isn't necessarily what other people think it is. In this case, I'd bet the tasks are to learn what's going on inside a database and become better at programming in Python, not to write a high-performance production-ready database implementation.

Almost all quoting for non-trivial cases comes down to the [list] command. It does the Right Thing, especially in the critical cases where you're generating a command to call later. Pretty much everything else is either much simpler to the point of needing no thought at all, or complex enough that you're best off writing a command to do it properly (e.g., because you're generating JSON or CSV or some other language like that) as you'll want to test it thoroughly too.

It's hard to be much more specific than that without talking detailed examples.

The main issue with supporting those IDEs is that the Language Server Protocol is vast and really quite complicated. More than a weekend's work to go to doing the interesting bits so life gets in the way...

The IDE tools for Tcl have tended to be commercial and to not see much general adoption. Never understood why.

Python has nothing at all like safe interpreters (I've looked). You just can't prevent things from leaking, it isn't designed for it at all. You can do a half-hearted approach by specifying the globals dictionary to eval(), but you can't really count on safety because the builtins do the leaking and you can't really stop anyone from finding a way to get back to that; the language is just too deeply interlinked for a proper security boundary to be erected anywhere inside it.

Well, there are classes and objects in there now. They're designed for modelling pretty heavyweight entities like widgets instead of lightweight things like linked lists.

It was a fun OO system to write. It's much more dynamic than it appears to be at first glance; it's first glance looks much like many other languages object systems with a few slight oddities (no new operator, but rather classes have a new method).

Technically, all values are considered subtypes of strings, but the notion of types is quite different to those of many other languages. In particular, Tcl's types do not describe the memory storage model of their values. (They're implemented with 64-bit words and buffers and arrays and so on, but that's not what the value model describes.)

It works well as long as your goal isn't to totally eliminate boxing of values.

Tcl uses a memory model internally where each piece of memory belongs strictly to the thread that allocated it, with this enforced in lots of places. There are a few loopholes past it (for process-wide concepts such as the current working directory cache, or for inter-thread messaging) but by and large you write what appears to be single-threaded code.

There's support for deep coroutines and non-blocking I/O so it isn't limiting. You only really need multiple threads when dealing with compute-heavy code or a particularly crufty API.

That's an excellent question!

It's not at all like IP. The basic message size is (IIRC) 64 or 96 bits, comprising a system control word, an application header word, and an optional payload word. The application header word describes what the identity of the sender of the message is (well, in theory it could describe the destination too, but then we'd not have enough space to address much at all) and is used in the routing of the messages. Each chip has a very fast masked CAM (the key IP of SpiNNaker) that is used to convert from the application header word to the destinations to deliver that packet to, which is one channel to each core on the chip and one channel to each direction in the logical triangular mesh in which the chips are connected. The router is very fast indeed, and very low power, so we can generally count on routing a packet right to the opposite side of the machine in a few milliseconds, and I'd have to look up the energy cost of a packet (we've published it, but I forget where). I believe our route planning software takes this delay into account. It also tries to put neurons that communicate with each other close together.

For greater delays than that, we also have a delay slot system (for up to 16 simulation timesteps, which is approximately 16ms) in our synapse model, and specialized pseudo-neurons that implement longer delays than that on cores that we set aside for the purpose (and which, because they only handle delays, are much easier to make scale).

We do source routing mainly because this was hardware designed from the beginning to do neural simulation; source routing is a natural way to implement (an abstraction of) axons, as each axon is capable of connecting to many different dendrites. This is very much an abstraction of what happens in reality, but it has worked well for us. Also yes, our routing algorithms most definitely do try to limit the amount of traffic going down each communication link. Since communication during execution is pretty predictable (at least statistically) this is far more practical than with IP, where the dominating factors relate far more to being able to manage the network without knowing its total state.

It's basically very different in approach to many modern computers. The cores are slow and low-powered, but the interconnect is very fast for routing small packets to multiple destinations, which means that computational tasks that would otherwise be utterly dominated by communication costs (e.g., neural simulations) become a lot more tractable.

But since it's all done in soft realtime with very low level code (and no hardware floats in the current hardware generation) and not much of an OS, it's a very unusual platform for people to work with. Much more like programming used to be like in the 1980s, if my memory serves me right. (One of the key distinguishing things about SpiNNaker in the field of neuromorphic systems is that actually has an OS at all. Most competitor systems are purely bare metal, as they're put together by deep hardware hackers without consulting software engineers.)

It really depends on whether you include the memory in that count, as memory uses masses of transistors without being very interesting as most of those transistors spend their time just sitting there in a stable state. It's the transistor count (more properly, the gate count; gates can be thought of as multiple transistors fused together, yet they're truly a single thing in terms of manufacturing and layout) in the computational parts of the processor that is really interesting.

SpiNNaker is built using old ARM968 cores on an ancient process (because that was cheap, for various reasons). The SpiNNaker2 hardware (under design; I can't remember if it is next year or the one after when it is finalized) will be on a modern process that will let us pack ten times as many cores on per chip, with those cores being quite a lot more powerful. Which isn't bad; we're not a commercial outfit here…