#Threads is #Meta / #Facebook using 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."

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 will 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 it, 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, exploit advertisers with ever-increasing costs of ad revenue.

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. #Fediblock is the only way to protect our home-grown community from corporate take-over.

(EDIT: spelling, grammar, minor clarifications)

I have been giving MIT/GNU Scheme a try

TL;DR it is pretty amazing!

According to the Ecraven's Scheme benchmarks, MIT/GNU Scheme is the 6th fastest major Scheme implementation (Guile is the 7th), and I have found it has several incredibly nice, ergonomic features unique to it. It even has its own text editor built-in (Edwin) which is a clone of Emacs 18, so it is quite archaic, but still gets the job done when you need to debug your Scheme programs. MIT/GNU Scheme is also quite minimal, which is good, but it unfortunately does not have as big a package ecosystem as Guile, Racket, or Chez.

I wrote a library for Functional Lenses in Guile Scheme, and I was going out of my way to stick to the R7RS standard, and to only use SRFIs (official Scheme language extensions), and not use absolutely any feature specific to Guile or the Guile namespaces. Then I tried to port my library to MIT/GNU Scheme, putting in the necessary "cond-expand" expressions... and it didn't work at all, even though MIT/GNU Scheme is in fact R7RS compliant. To be fair, I could probably make it work with a little more effort, for example, I have not yet learned how to use the debugger, and without the debugger, MIT/GNU Scheme tells you nothing when an error occurs.

I am just a little disappointed with how much effort it takes to make a R7RS compliant Scheme program work across just two different implementations. I hope I might have more luck building it with Larceny, Gambit, Racket/CS, Loko, and STklos. If I ever get my Lens library to work across all of the R7RS compatible implementations listed at docs.scheme.org, I'll report on what steps I had to take in order to make my R7RS Scheme code truly portable.

#Scheme #GuileScheme #R7RS

Why Program in C+Python when you can program in Zig+Scheme?

Another bit of gold from #ICFP2023 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."

#Scheme #Guile #GuileScheme #Zig #CProgramming #CPlusPlus #FunctionalProgramming

C++ is everywhere, that makes ECL very valuable.

The software industry, especially in the realm of free software, 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 Rust might come along and change all this, but it will take decades.

In the mean time, if you want to use C++ but not actually write C++, you can make use of the ECL Common Lisp compiler, which can compile Lisp to C++ code. This gives you all the best features of Common Lisp for programming with the universe of C++ code libraries available to you. You can use a C++ library and still have Common Lisp macros, garbage collection, high-level scripting, S-expressions as serialization, domain specific languages, a proper meta-object protocol that wraps C++ classes nicely, and wealth of choices for functional programming systems from the untyped lambda calculus all the way up the lambda cube to System-F and the Calculus of Constructs. This not only makes ECL a viable alternative to Python for scripting and app development, but objectively better than Python since you can actually turn your Common Lisp scripts into code that gets compiled into a larger C++ application.

With ECL I would have all sorts of C++ libraries available to me:

- game engines like Unreal and Godot
- 3D modeling: FreeCAD, OpenSCAD, Blender
- Machine learning, big data, and HPC with PyTorch, TensorFlow, OpenCV, OpenCL
- Cross-platform GUIs with Qt, KDE on Linux, native MS Windows programming with Universal Windows Platform (UWP) and MSVC.

I will continue to contribute to the Scheme and Haskell communities as much as I can. I will continue to pursue my dream of an Xfce-like desktop environment written in Scheme. I will continue to use Guile and Guix for package management and software development. But no matter how I look at it, I am going to be more productive in the long run using ECL and C++.

I was hoping that the software industry would gradually shift over to better, more functional languages like Rust and Haskell. And I would love it if Scheme languages could ever begin to seriously replace Python as a scripting language. But realistically, I think I am going to change tack and meet the industry half way. I think I should probably start using ECL as my language of choice, as much as I would prefer Scheme or an ML-family language like Haskell.

#Cpp #CommonLisp #ECL #cplusplus #python #scheme #rust

Common Lisp vs. Racket and Scheme, in terms of developer experience

This is a public Gist document on which you can comment if you have experience with both #CommonLisp and #Racket or #Scheme . The consensus is that the Common Lisp debugging and interactive "image based development" experience in a REPL (in particualr, using Emacs and SLIME) is by far the most reliable, robust, and user-friendly. Also, the fact that CLOS is standard, and there is no standard Meta-Object Protocol implementation for Scheme or Racket, really makes things so much easier.

I can't really disagree, but the reason I like Scheme is more for it's minimalism than it's developer experience. That said, if I were developing Lisp software professionally, I would probably prefer Common Lisp.

Wow, the Nanopass Compiler Framework used in the Chez Scheme compiler, which is the compiler that produces the fastest native binary programs of all Scheme implementations, is available as a separate library that you can use in any compiler.

> The nanopass framework provides a tool for writing compilers composed of several simple passes that operate over well-defined intermediate languages. The goal of this organization is both to simplify the understanding of each pass, because it is responsible for a single task, and to simplify the addition of new passes anywhere in the compiler.

(define-language L0
  (terminals
    (variable (x))
    (primitive (pr))
    (datum (d))
    (constant (c)))
  (Expr (e body)
    x
    pr
    c
    'd
    (begin e* ... e)
    (if e0 e1)
    (if e0 e1 e2)
    (lambda (x* ...) body* ... body)
    (let ([x* e*] ...) body* ... body)
    (letrec ([x* e*] ...) body* ... body)
    (e0 e1 ...)))

You can install it from the Akku repo.