dkfellows · HackerTrans

3 года назадdiscuss

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.

dkfellows

3 года назадdiscuss

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.

dkfellows

3 года назадdiscuss

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.

dkfellows

3 года назадdiscuss

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.

dkfellows

3 года назадdiscuss

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

dkfellows

3 года назадdiscuss

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.

dkfellows

4 года назадdiscuss

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.

comments