Tony Garnock-Jones

IMO, Smalltalk-the-system is best thought of as an OS, yes. (Remember how everyone ridiculed the idea of Smalltalk's images right up until virtual machines became a thing?) It has a runtime and a systems programming language, too: the Smalltalk VM, and Smalltalk-the-language. Analogously, Unix has its kernel and C, respectively. The global variables of Smalltalk are analogous to Unix files. Smalltalk processes to Unix processes. It's not a perfect analogy but I found it surprisingly useful once I stumbled across it. Preferable, though? Not sure. Certainly, as Marcel notes, a flat file system isn't the best idea; but then, is a hierarchical strict tree? (Related: https://eighty-twenty.org/2011/05/08/weaknesses-of-smalltalk-strengths… https://eighty-twenty.org/2016/05/05/unix-is-incorrectly-factored) I think you'd have to burn the disk packs (ie: neither Smalltalk nor Unix as they stand make a suitable foundation), but out of the ashes I think something largely based on Smalltalk taking into account lessons from the forty (!) years that followed it could definitely end up being preferable. Coming back to OP, and viewing Smalltalk as an operating system on equal footing with Unix: Different operating systems interact best via networks. Which neither Smalltalk-the-OS, Smalltalk-the-language, Unix-the-OS nor C-the-language support particularly well.

> Of particular interest is Henderson’s paper “Purely Functional Operating Systems” which was difficult to find the last I checked. Find it here: https://eighty-twenty.org/2022/06/23/henderson-functional-operating-sy…

It should be noted that Mendeley encrypts user database, presumably to lock in its users: https://eighty-twenty.org/2018/06/13/mendeley-encrypted-db

Mendeley is owned by Elsevier so they’re likely to continue user-hostile things like locking down your data to prevent interoperability: https://eighty-twenty.org/2018/06/13/mendeley-encrypted-db

They're using SEE, see https://eighty-twenty.org/2018/06/13/mendeley-encrypted-db

loop/recur is good for replacing structured loops but tail recursion is more general, since it can replace arbitrary gotos. One example is given by Guy Steele in "Why Object-Oriented Languages need Tail Calls". Basically, tail recursion lets you keep O(1) stack space even in the face of opaque method dispatching in OO code. https://eighty-twenty.org/2011/10/01/oo-tail-calls Another required reading are the "Lambda the Ultimate" papers, if you haven't read them yet. The "GOTO" one is particularly relevant here. http://library.readscheme.org/page1.html

It's kind of interesting that TCO goes together with FP, because logically it makes at least as much sense for OOP, as Guy Steele pointed out at http://www.eighty-twenty.org/2011/10/01/oo-tail-calls.html

> You could pass around explicit dictionaries with all your values or some such, … if you have an extremely low-overhead way of doing so A lot of that plumbing could be hidden from the user given the right dynamic features. http://www.eighty-twenty.org/2015/01/25/monads-in-dynamically-typed-la…

mirror of the post by Guy Steele: http://www.eighty-twenty.org/index.cgi/tech/oo-tail-calls-20111001.htm…

monads if the language is functional Monads are not a functional concept. For example an imperative language like Scala (which, being in the ML family of languages has a powerful and first-class functional sublanguage) has monads that work perfectly fine with imperative computation. Indeed, I find it a good programming style to let trivial, ubiquitous monads, like printing / IO / global state, be handled by the built-in primitives, while higher-level, unusual, application-dependent effects are implemented explicitly using monads. Monads are essentially a form of overloading / re-defining composition operators, e.g. the semicolon operator in traditional imperative languages. In languages like Haskell and Scala, types (and higher kinds) are used for this purpose, hence it is often though that monadic programming is restricted to statically typed languages with powerful types, and don't make sense for dynamically typed languages. Nothing could be further from the truth. All we need is a 'hook' into the sequencing mechanism(s) the language provides, at least in principle. Admittedly, the outcome is not nearly as pretty as in statically typed languages. See [1, 2] for discussions. [1] T. Garnock-Jones, Monads in Dynamically-Typed Languages. https://eighty-twenty.org/2015/01/25/monads-in-dynamically-typed-langu… [2] O. Kiselyov, Monadic Programming in Scheme. http://okmij.org/ftp/Scheme/monad-in-Scheme.html