A close friend of mine was "inspired" to write a song by my series of blog articles called "Emacs Fulfills the Unix Philosophy" (actually I think he is busting my chops a bit for being an annoying Emacs evangelist, but anyway...) I thought it was pretty funny and worth sharing here.

He wrote the lyrics and used one of those Large Language Models like Stable Diffusion (or something like it) to make the actual music, and settled on a few different renditions of the song. You can listen to them on his website: https://www.extrema.is/blog/2024/04/29/emacs-philosophy

(This is an extended version of one of the most widely re-shared post I have ever written on Mastodon.)

The new "Threads" app by Meta (Facebook) is just the old 4-E strategy strategy to destroy Mastodon:

1. Embrace:

   (what they are doing now) launch a competing but compatible service with that of Mastodon. The vast majority of users, most of whom don't care about the privacy and intimacy of the Mastodon network, will go with the brand with the most name recognition. The number of users already signed up for Threads shows this to be true.

2. Extend:

   make their service appear to be better with features like search, which they have the resources to do, but the rest of the Mastodon network does not. Also include features for tracking and advertising, sell this as a good thing, "a better place to grow your personal brand, your business." When people think about joining either Facebook Threads or some other Mastodon instance, which will they choose? "Oh, Threads users can also talk with Mastodon users so they are basically the same? Well, why not just use Threads then?" The one with the most name recognition will always win.

   Then comes the blogs and YouTube videos about, "I tried Threads, Bluesky, Mastodon, Pixelfed, each for 1 month, here is what I learned" type videos in which the author decides Threads or Bluesky is best because they have better features and you don't have to decide which instance to join.

3. Extinguish:

   after attracting a critical mass of users large enough to decimate the user base of the competing Mastodon network, and temporarily making appear to have better features like search, quietly remove compatibility with the Mastodon network.

   This might effect only 10% of Mastodon users because the other 90% will be on Threads. Then people will think, "who cares if we lose contact with that tiny minority of old Mastodon users, they should have just joined Threads by now anyways, they still can. It has search, and more people voted for it with their patronage. And you don't have to think about what instance to join, its easier!"

   At this point, people begin to wonder what the point of Mastodon even is.

4. Enshittification:

   without any real competition to keep people from leaving for an alternative, start exploiting users for more and more content for ad revenue, while also exploiting advertisers with ever-increasing costs of ad revenue, while also cutting costs on the quality of their service until it becomes unusable. But at this point it is too late for Mastodon, the momentum it once had is now long gone and no longer a threat to the Meta corporation. Their investment paid off.

Meta is one of the worlds largest corporations that has made most of its money not just through advertising but from gathering and selling people's personal information. They are scared to death about losing control over the Internet that they had gained over the past 15 years or so, and they are fighting to take that control back for themselves.

We built this, but now a corporation like Meta/Facebook feels they have the right to exploit it for all its riches until it is destroyed. Don't let it happen. Join the Fediblock cause, it is the only way to protect our home-grown community from corporate take-over.

Eugene Rochko thinks Threads is good, he is wrong

Eugene Rochko who developed Mastodon as a Twitter-like app based on the ActivityPub protocol, has a blog post explaining why he thinks federating with Threads is good for Mastodon.

We have been advocating for interoperability between platforms for years. The biggest hurdle to users switching platforms when those platforms become exploitative is the lock-in of the social graph, the fact that switching platforms means abandoning everyone you know and who knows you. The fact that large platforms are adopting ActivityPub is not only validation of the movement towards decentralized social media, but a path forward for people locked into these platforms to switch to better providers. Which in turn, puts pressure on such platforms to provide better, less exploitative services. This is a clear victory for our cause, hopefully one of many to come.

No, Threads will get people to leave Mastodon in droves. Really all Facebook is doing here is leaching users away from Mastodon. The average user doesn't know or care about the “perks” of non-Facebook Mastodon instances that Eugene is talking about. They will go with the service with the most name recognition every time, rather than trust an independent, small-time instance operator.

Threads is just Facebook with ActivityPub compatibility and extended Facebook's ads and tracking. The goal is to pull people away from decentralized networks and back to being under their control. Then the network effects Eugene is talking about will kick in, but moving people away from Mastodon and toward Threads.

History repeats itself again

We have seen all this before. Google did something similar when they first embraced support for the open and federated XMPP protocol in their Google Talk (GChat) app, and exactly the situation I described above happened. Eventually Google shut it down, and started calling the original XMPP apps "unauthorized third-party apps," although in fact Google was itself originally a third-party to the existing XMPP services that existed before GChat was invented.

People can and do still use XMPP, and I would encourage you to use it as well for video/voice/text chat. But all that momentum and popularity was extinguished, and was never really regained, at least not in the 9 years since Google extinguished it. So Google was successful in destroying a community of federated services using a popular communication protocol that made it difficult for Google to track and control people on the Internet.

We know for sure what Facebooks goal is not: they do not want to do something good for the various communities of people that have organically sprung-up around Mastodon and the other ActivityPub-based federated social networks. Mastodon does not need to make this mistake with Facebook Thraeds.

Mastodon and ActivityPub are important

Mastodon became most popular in the wake of Elon Musk buying out the Twitter corporation. Calling himself a "free speech aboslutist," which sounds as though he believes everyone should have a voice online no matter how unsavory that voice might be, quickly proved to be anything but a proponent of free speech, quietly censoring his critics and the political groups he hated, while giving a voice to everyone else, including (seemingly enthusiastically) giving a voice to racists and hate speech.

This happens every so often, although not always with the amount of drama churning around a single central figure such as Elon Musk. People see how dangerous it is that the communities we form over the Internet can only actually exist at the whims of an impersonal corporation that might at any point go insane and destroy their communities. When an Elon Musk event happens, then the problem becomes clear to everyone: they had been putting their faith into a monarch and/or despot like Twitter, and now it has turned against them.

The solution to this is, and always has been, the democratic approach, which in this case is Mastodon. Do not allow any one authority to have aboslute control over the plane of existence. Allow people to opt-in, and give them a say in how their community is run. Trust that people are smart enough to understand what is in their own best interest, and allow them to make their own decisions and cast their own votes. This is how ActivityPub and Mastodon work. But if a democracy is not careful, it can easily be overwhelmed and elimitated by the well-equipped armies competing for their resources.

Another bit of gold from ICFP 2023 by Pjotr Prins of the University of Tennessee.

The actual title of the talk is "Why code in Python+C if you can code in Lisp+Zig?" but the "Lisp" in this case is actually Guile Scheme. I didn't know this, but Zig uses the C ABI so it binds to any language that can do FFI bindings to C, including most Scheme and Common Lisp implementations. But why don't I just post the abstract here:

"Most bioinformatics software today is written in Python and for performance C is used. Lisp has been around for over half a century and here I don’t have to tell how or why programming Lisp is great. I will talk about Zig as a minimalistic new language that is unapologetically focused on performance, tellingly with a blazingly fast compiler. It is advertised as a replacement for Thompson, Ritchie, and Kernighan’s C, but it may even replace C++ in places. Zig uses the C-ABI and does not do garbage collection, so it is ideal for binding against other languages. In this talk I will present combining GNU Guile Lisp with Zig. I’ll argue that everyone needs two languages: one for quick coding and one for performance. With Guile and Zig you get both at the same time and you won’t have to fight the Rust borrow checker either."

Note: this was originally a comment I wrote on Lemmy in answer to the question “what type of problems do you solve using Lisp?”. The post got to be a bit too long, and I am re-publishing it here as a proper blog post. I am also including some of a post I wrote on Mastodon which touched on some of these same issues.

So to answer the question: I have known about Common Lisp and Scheme for years, but only recently started using them. This is the story of the 3 Lisp dialects that I use.

Emacs Lisp

I use Emacs and Emacs Lisp to manage my tens of thousands of text files, I write Emacs Lisp scripts to automate simple tasks like searching for pieces of information, formatting it, and outputting it to a report that I might publish on my blog or send in an e-mail. I also use Emacs to help with data cleaning before running machine learning processes. Emacs helps with navigating CSV and JSON files, it also is a really good batch file renamer.

Scheme

I have recently started using Guile Scheme to do some personal projects. I went with Guile over the myriad other Scheme dialects because it is the implementation used for the Guix package manager and operating system.

• Also, there the Goblins, which is a distributed object-capability programming system is officially supported on the Guile platform, and I have been really wanting to write applications using this programming style ever since I first learned about it.

• Also, there is the G-Golf foreign interface layer allows Guile to automatically use an C library that implements the GObject Introspection interface. So through Guile, like with Python, you can use any C code library used to create of all native apps in the Gnome, MATE, Cinnamon, or (my personal favorite) the Xfce desktop environments. This potentially makes Guile a viable alternative to Python scripting across all of those Linux desktop environments.

Of all the Lisp dialects, Scheme is my favorite, for a few reasons:

• It is absolutely tiny. Guile is relatively large (not as big as Common Lisp), but other implementations are unbelievably small. for example the Chez Scheme “petite” interpreter is fully compliant with the R5RS standard, and the executable is like 308 kilobytes on a 64-bit Linux computer system.

• Hygienic macros with syntax-case

• Recursive functions over using the loop macro of Common Lisp. When writing algorithms, I personally find it easier to reason about recursive functions than loops. Scheme also provides me the ease-of-mind that comes with knowing the optimizing Scheme compiler will ensure recursive loops will never overflow the stack.

• Pattern matching is well supported by most Scheme implementation.

• It is a "Lisp-1" system, meaning there is only one namespaces for variables and functions, as opposed to Common Lisp (a "Lisp-2 system") which allows a name to be either a variable, a function, or both. I personally find it easier to reason about higher-order functions in Lisp-1 systems.

• Support for Delimited Continuations, which is a fairly recent discovery of computer language theory (first being discussed back in the 1990s), but is available across a few Scheme implementations.

Common Lisp

That said, I am also starting experimenting with Embedded Common Lisp (ECL) because it is a lightweight standards compliant Common Lisp implementation that compile your program into C++ code, and this is useful to my professional work.

The modern software industry, especially in the realm of big data and machine learning, has mostly settled on a pattern of using C++ for creating performance critical libraries, and creating Python binding to the C++ libraries for scripting. I was hoping languages like Haskell and/or Rust might come along and change all this, but it will take decades (if ever) for the software industry to turn in that direction.

The problem with Python, in my experience (and I believe many other software engineers would agree) is that it does not scale well to larger applications at all, whereas Common Lisp does. This is for various reasons, but mostly due to how Lisp does strong dynamic typing, and also the CLOS implementation of the meta-object protocol. Yet too many companies waste time writing large applications in Python — applications that are much larger than the scripting use cases that Python was originally intended to be used. I believe this is time and money better spent on other things.

So I see Common Lisp, and the ECL compiler, as a potentially viable alternative to the sub-optimal status quo of Python as a scripting layer around C++ code libraries, at least perhaps for my day job, if not being more generally true industry-wide. Mostly, ECL would allow me to write a program in Common Lisp instead of Python, but deliver to my clients the C++ code that ECL generates to be used in their machine learning projects. (I have not actually done this yet, I am still investigating whether this would be a viable solution to any of my projects).

ECL makes it easy to use C++ libraries through Lisp instead of Python. And there are so many good C++ libraries out there: Qt, OpenCV, Tensorflow, PyTorch, OpenSceneGraph, FreeCAD, Godot game engine, Blender. And it compiles easily on Linux/Unix (GCC), Windows (MSVC), and MacOS (via Clang++), so good for cross-platform development.

Conclusions

So in spite of Lisp being such an old family of languages (its earliest incarnations dating all the way back to 1958), and being superseded in popularity and widespread use by languages like Python and JavaScript across the software industry, Lisp is still a modern, relevant, evolving, and very useful family of programming languages. At the same time, a Lisp such as Scheme or Common Lisp would even be a better choice of programming language in many applications where Python is currently used.

I just hope I eventually find the time to try out all of these Common Lisp and Scheme related ideas I have. I especially hope ECL turns out to be a profitable technological choice for the professional work that I do. But only time will tell.

Please feel free to comment here, or on Mastodon

Here is my latest blog post on a method of using a laptop equipped with an X11 server as a KVM or graphical dumb terminal (not to be confused with "kernel virtual machine") to display an entire desktop environment on one of the virtual terminals of the laptop. You might be familiar with running an X11-compatible program over SSH, seeing a remote GUI app displayed on your local machine. You could also run a whole desktop environment such as "xfce4-session" over SSH and attach it to a virtual terminal (which you switch between using Ctrl-Alt-F1 through Ctrl-Alt-F7, usually, on Debian-based systems).

This is nice if you have a few always-on Raspberry Pis laying around, and you usually use SSH to remote login and control them, but you would like to have a full desktop environment, not just one app, show up on your local computer.