This is a screenshot of a Go project I'm working on. But sure, #Lisp expressions are bad because they have too many parenthesis… And of course you cannot manipulate Go expressions the same way as Paredit.
after a nuclear war, the remaining people will probably not be able to spin up a modern operating system on their improvised chips. How do you build a simple, reliable, legacy-free OS from scratch? What ideas 💡 and techniques should be passed down to those people?
If we think hard enough about this, I think we’ll agree that closed-source systems are basically designed to be almost impossible for people outside the sponsoring organization to reproduce (for an example, consider [ReactOS](https://reactos.org/), which launched as [a project to produce a system compatible with Windows 95](https://reactos.org/wiki/FreeWin95) and [then changed to focus on Windows NT](https://reactos.org/wiki/ReactOS/History), and after more than 25 years, is still not capable of being a daily use system.
But we may also determine that most open-source systems are likewise not designed in such a way that reconstruction is viable. The Linux kernel is *huge* these days.
Additionally, in my opinion, they’d probably want to use programming languages designed for readability, ease of learning, and error-reduction first (that is, more like #COBOL than #C, more like #Java than #CPlusPlus, more like !Smalltalk and #Lisp / #Scheme than #Perl / #Raku and #JavaScript) and then performance and low-level access.
I think it is a mistake to assume that one could start with a modern version of #gcc or #llvm or #msvc … because it is not a given that the software itself and someone who knew how to use it (and update, modify, and adapt it) would still exist.
I am going to vacationarily livestream RIGHT NOW! The usual blunderings in #lisp, #guix, #guile, and digital rights gossip, this time from my back garden in San Francisco. Watch at https://codetherapy.space/
This account will be dedicated (or at least try) to display a broad view of the scheme world at large this includes but is not limited to the following hashtags #lisp#racket#guile#guix#clojure and #ai.
Best effort will be put to create new and original toots, that is information that you will not find by following the hashtags mentioned previously.
@cwebber I think other than initially looking a bit funny or being unfamiliar to people who learned programming with non-Lispy languages, #Lisp#parentheses have more advantages than disadvantages. I mentioned to Matthew Flatt (re: paren-less Racket langs) that I think the parens could make Racket/Lisp potentially easier for getting #linguistics students into non-trivial programming than other langs, since linguists are used to dealing with #trees and bracket-notation for trees.
tfw you use cond when you could have used if in places where the body clauses are large because it's easier to read but then you feel weird about that #lisp
I have been looking for a Lispy replacement to #Python for a year now. #Racket is batteries-included like Python. You can also create executable binaries. I'm not looking for efficiency here, since it's just for scripts I run on my desktop.
Though I prefer to use Emacs over DrRacket, I can see how it can bring down the barrier to entry significantly.
"uLisp® is a version of the Lisp programming language specifically designed to run on processors with a limited amount of RAM. It currently supports the ATmega-based Arduino boards, SAM/SAMD-based Arduino boards, BBC Micro Bit, and MSP430-based LaunchPad boards. You can use exactly the same uLisp program, irrespective of the platform. …"