I understand the general job market, but what about lisp prevents you from pursuing personal ventures with it?
GNU/Lisp Enthusiast!
I understand the general job market, but what about lisp prevents you from pursuing personal ventures with it?
Yeah Clojure is like the monkey’s paw of Lisp weenies. It adds many modern day niceties that are lacking in standard Scheme or Common Lisp, but also changes enough things to make it feel very un-lispy. I go back and forth as to whether or not I even consider it Lisp (Richard Stallman doesn’t).
But I do know that I’d rather write Clojure than any other non-lisp language.
I’d also recommend people try ABCL, which is Common Lisp on the JVM , or Parenscript which is Common Lisp that compiles to Javascript.
Lisp
It solves so many problems new languages have been invented to try and solve, while being simultaneously simpler than most
Look up what?
Source?
Thanks for the update!
That sounds roughly correct, though I don’t see the connection with the article? Unless you’re saying that “products” (like Signal) will always exist, which is probably true but is orthogonal to whether or not other models will succeed.
As for email, I think posteo does a pretty good job, but you’re right options are few and far between. But self hosting email is just as viable as ever? Perhaps less so since e.g. gmail will instantly flag your incoming mail as spam if you’re sending it from randomsite.tld, but honestly that issue hasn’t gotten that bad (yet). Yes, whenever there’s a protocol like email or xmpp, companies will create gmails and signals and turn them into walled gardens, but that doesn’t spoil the protocol for everyone else. It just causes frustration that companies build closed products on top of open technologies, but not much to be done about that.
There are two different immutable OS models hot on the table in the linux space I see: The Nix[1] way and the Silverblue[2] way.
Both have immutable filesystems which deviate from the FHS, provide atomic updates, and support the creation of more-or-less isolated environments at the user level. But the way the two models implement these features is very different.
The Nix way takes inspiration from the world of functional programming, while the Silverblue way takes inspiration from the containerized, cloud native technologies which are used so widely in the industry.
I believe the idea that these two approaches share is the future of linux on both the server and the desktop, and it is only a matter of time before some (if not all) of these advantages become mainstream. However, I am uncertain of which approach is superior.
I have personal experience with Guix and enjoyed it greatly and even recommend others try it or Nix out for themselves, but there are some complexity issues. It is not clear to me whether these issues are growing pains, or symptoms of a fundamentally overcomplicated system to solve a seemingly simpler problem.
The Silverblue way I have no experience with, but seems like a more grounded approach to tackling the specific problems laid out. The big area where Silverblue seems to lack in comparison to Nix/Guix is declarative, reproducible system configuration. With Nix/Guix you can just throw your system config file up in a repo, and anybody else can pull it down and install that system bit-for-bit, including future you! With home manager this extends to a large extent to user configuration as well. Of course with Silverblue you can create images, but that is less straightforward and powerful (at least for now).
What are ya’ll’s thoughts on immutable OS’s?
I have never used nix or nixos. I liked their shared idea (functional, atomic, reproducible systems), and so when I looked at their differences they seemed to all be pros for guix:
The only bittersweet aspect of guix compared to nix was the foss only stuff, as I do need some proprietary drivers, but nonguix is so easy it hasn’t been a practical issue. And of course I am big advocate of free software so I like that guix is pushing that forward.
There’s also a theoretical issue that guix has less packages, but the standard channel + nonguix has had everyhing I use.
Alternatively if price is an issue (NEVER use a “free” VPN) you could torrent over I2P, which is free and very safe (at least as safe as tor, if not moreso).
Also the next release of qbittorrent is about to have built in I2P support (but also standard I2P comes with its own torrenting software).
I quite enjoy it!
Being able to rollback any change I make to the system, either package changes or system configuration, makes it completely unbreakable and provides great peace of mind. It means I can fully enjoy its rolling-release nature without worrying.
Having my entire system configuration declared in a single, robust programming language (Guile) across a small number of files makes it very easy to understand and just stick into source control to reproduce.
Being able to hack on it in a lisp (scheme) is the cherry on top, along with the great emacs integration. I would highly recommend it to any lisp/emacs/gnu enthusiasts.
Common Lisp “solves” most language-level problems by providing metaprogramming capabilities via lisp-style macros. (Almost) any language feature you would want can be implemented with lisp macros, and many such features already have been. So you don’t have to worry whether or not lisp has “for i in…” loops, or pattern matching, or generics, or virtually anything else, because if it doesn’t, you can write it! Plus if it’s really a good feature somebody has probably already made a library for it (if it’s not already part of the standard).
One of the most extensive examples of this is Coalton, which is an ML-style statically typed EDSL for Common Lisp.
There are metaprogramming features in a few other languages: template haskell, C pre-processors, even macros in Rust or Julia. But these all fall very short of lisp-style macros because those languages are not (truly) homoiconic, which makes the macros awkward to write and integrate into the language. This kind of metaprogramming is rarely employed, and when it is only for heavy duty tasks, and even then is generally discouraged as a last resort/special circumstance. But lisp macros are very easy to write because it’s the same as writing any other piece of lisp code. This results in macros being used often for smaller lightweight abstractions in the same way you write a small function.
The other big pro of lisp is image based development. But that’s not so much solving a problem in other languages as it is simply a feature that they don’t (and pretty much can’t) have.
And all of this is done in a language with less syntactic and semantic primitives than almost any other language, including the other “simple” ones like Python, Ruby, Elixir, etc.