Haha indeed. At work suddenly documentation and APIs are important, but it's all for/behind "skills". Before it was always "sure, that would be nice"...
I do welcome the improvements to doc and APIs this brings though!
At least in Belgium it's quite common for a lot of students to fail the first year (partly due to the difficulty, partly due to partying instead of studying). But it's not like it's really free, the tuition is cheap but the accomodation is expensive. I also don't think it's particularly difficult on purpose to filter out students, it's just that it's not overly expensive and a lot of people are unsure about what to study.
If you're porting a library, you can use the original implementation as an 'oracle' for your tests. Which means you only need a way to write/generate inputs, then verify the output matches the original implementation.
It doesn't work for everything of course but it's a nice way to bug-for-bug compatible rewrites.
Indeed, the Tcl implementation does this so e.g. `set d [dict] ; dict set d key value` can modify d in place instead of creating a copy (since everything is immutable).
While I see the usefulness of lazy imports, it always seemed a bit backward to me for the importer to ask for lazy import, especially if you make it an import keyword rather than a Python flag. Instead I'd expect the modules to declare (and maybe enforce) that they don't have side effects, that way you know they can be lazily imported, and it opens the door for more optimizations, like declaring the module immutable. That links to the performance barrier of Python due to its dynamic nature as discussed in https://news.ycombinator.com/item?id=44809387
Of course that doesn't solve the overhead of finding the modules, but that could be optimized without lazy import, for example by having a way to pre-compute the module locations at install time.
I've always thought it would be great for the government to provide a free domain name for every citizen. There's really not much you can do without DNS.
For logic in Python this project looks pretty neat, it encodes facts as typed objects and rules as functions, then allows you to run the model using a solver like soufflé: https://py-typedlogic.github.io/
I haven't found an excuse to really use it though!
I was always surprised that NixOS doesn't have a better story there, the main install instructions are to do manual partitioning, generate a config, edit it, etc. What I had expected at first would be that you'd write the config first and then deploy it, like in the article. But even with the method presented here you have the imperative step of running nixos-anywhere. Having something like the ignition system of Fedora CoreOS where you'd point at an existing config and it would install everything would make more sense IMO. Or pre build an iso which installs itself.
I was also thinking about this use case when reading the announcement. Let's say you have a bunch of parquet files already (on local FS, HTTPS, S3, ...) that you can assume are immutable (or maybe append-only). It would be great if you could attach them to the DuckLake without copying them! From the design doc, it seems it should essentially work, you would read those parquet files to compute the metadata, and insert a reference to the parquet file instead of copying them to the storage you manage. Basically you want to create the catalog independently from the underlying data.
True, I believe I mostly worked around that limitation by splitting off quoted from unquoted code into separate commands. So in your example "[cmd $bar]" would be in a separate unquoted command, probably putting it in a temporary variable, which can cause problems as it's hard to have a private scope when doing metaprogramming. You can also use "[list]" in the middle of code, but it gets more error prone, for example "set foo \[[list cmd \$bar]\]"
For sure there is a lack of proper "code as data" constructs in Tcl, like you would find in Lisp.
I implemented something very similar a while ago, it's indeed too bad it's not built-in. I don't think you need such a "quasiquote" function, [list {*}$args] can escape a single command, and then it's a matter of joining multiple commands using a newline. IIRC that's how I did it.
I also had further fun with wrapping "proc" by implementing a "pyproc" which called out to Python while looking like a normal Tcl proc.