Well, I feel that lot of code is written again and again, just in different languages. If we could automatically compare and translate different implementations, I think it would be beneficial for finding bugs.
Everytime somebody comes up with a new programming language, I am like, yeah, so you added these abstraction, just in a different syntax. I think people who come up with new languages should implement the primitives on top of lambda calculus (which really is the simplest logical system we know), then we could potentially have automated translators between languages, and that way we could cater to everyone's preferences, and expand a standard library across different languages.
So in short, yes, I think proliferation of programming languages without formal understanding of their differences is detrimental to interoperability of our computer systems.
It would also allow wider notion of metaprogramming - automated manipulation of programs. For example, let's say I need to upgrade my source code from one interpreter version to another. If both interpreters are represented as a set of terms in lambda calculus, I can see how express one in the other, and formalize it as some kind of transformation. No more manual updates when something changes.
It would also allow to build a library of universal optimizations, etc. So I think programmers would benefit from having a single universal language.
> Everytime somebody comes up with a new programming language, I am like, yeah, so you added these abstraction, just in a different syntax.
I got this feeling too, until I started to explore languages outside of the C/Algol-like syntaxes. There is a wide range of languages out there, from array languages to lisps, and they don't give me the feeling of "just a different syntax" but actually changed the way I think.
So yeah, I love lisp now and spend most of my days writing it, but it also comes with the downside that now Java, C# and Golang look more similar than different to each other.
> It would also allow to build a library of universal optimizations, etc. So I think programmers would benefit from having a single universal language.
I think assuming everyone would use the same hardware, same environment and same workflows to solve the same problems, this would make a lot of sense and would be hugely beneficial!
But in reality lots of problems need different solutions, which has to be made in different ways, by different people who think differently. So because the world is plural, we need many programming languages too. Overall I feel like that's a benefit.
> they don't give me the feeling of "just a different syntax" but actually changed the way I think.
Not only that, but languages that enable more concise expression of an idea (without losing clarity for readers) reduces the error rates of programs written in them.
It's been proven that when not accounting for constraints imposed by a compiler/interpreter (like the Rust borrow checker), the average error rate per unit size of programs across widely varying languages is constant. So reducing the number of lines/expressions required to express ideas reduces the number of errors by the same factor. Brevity pays when readability isn't sacrificed.
> assuming everyone would use the same hardware, same environment and same workflows
They don't have to. I would ideally represent HW, OS and compiler in the LC as well. Then primitives of the language that could be proven to be HW/OS/compiler independent could be abstracted and readily translated. For the ones that could not - well you have exact description of what the differences are.
Racket is at least related to the kind of metalanguage system you're talking about. I've never actually done it, but to implement a new "#lang" in Racket, your job is essentially to write a "reader" for it that transliterates it to the classic Schemey Racket language. Libraries written in one #lang can then be called from one another (or not, if that's what you want -- a lot of the point of this in Racket is building little restricted teaching languages that have limited capabilities).
That's a rather cheap retort. I am not saying everybody should use raw untyped lambda calculus for their programming, just that we would all benefit if we could translate languages we use to and from it, because then we could interoperate with any other code, refactor it, etc.
A CIL to LC compiler is effectively an emulator of CIL in LC. That is, every primitive of CIL has a corresponding LC term, which operates on the CIL execution state. So then you can express functions from .NET standard library as terms in LC.
Now let's say you do the same for JVM. Now you can start looking at all these lambda terms and search for some similarities. For example, you might notice that some list functions are equivalent if you transform the representation in a certain invertible way. This gives you a way to express functions from one standard library in the other.
In general, I think we should try to translate wide variety of human programs into lambda calculus and then try to refactor/transform the lambda terms to spot the common patterns.
That sounds very thankless, but on the other hand we have very fast computers and maybe "the bitter lesson" of just throwing more compute at finding patterns can be applied here, as well.
It divides effort, spreads it too thinly among too many disparate projects with essentially the same goals, and as a result, they all advance much more slowly.
Examples: how many successors to C are there now? Hare, Odin, Joy, Zig, Nim, Crystal, Jai, Rust, D... And probably as many again that are lower-profile or one-person efforts.
For a parallel example, consider desktop environments on FOSS xNix OSes.
I have tried to count and I found about 20.
A "desktop" here meaning that it provides a homogenous environment, including things like a file manager and tools to switching between apps, plus accessories such as text editors, media viewers, and maybe even an email client, calendar, and/or address book. I am trying to explicitly exclude simple window managers here.
The vast majority are simply re-implementations of the Windows 9x desktop. Taskbar along 1 edge of the screen, with buttons for open apps, start menu, system tray, hierarchical file explorer, a Control Panel app with icons for individual pages, etc.
This includes:
* KDE Plasma (and Trinity)
* GNOME Flashback (AKA GNOME Classic, including the Consort fork)
* Cinnamon
* Xfce
* Budgie
* MATE
* LXDE (including Raspberry Pi PIXEL)
* LXQt
* UKUI (from Ubuntu Kylin, openKylin, etc.)
* DDE (from Deepin but also UOS, Ubuntu DDE and others)
* Enlightenment (and Moksha etc.)
* ChromeOS Aura
And more that are now obsolete:
* EDE
* XPde
* Lumina
That's about 15, more if you count variants and forks. There are more.
The main differences are whether they use Gtk 2, 3 or 4, or Qt. That's it.
It's easier to count the ones that aren't visibly inspired by Windows >= 95:
Arguably: GNUstep (whose project lead angrily maintains is not a desktop after all), and the long-dormant ROX Desktop...
So, arguably, 3 you can run on a modern distro today.
CDE is older than Linux or Free/NetBSD so doesn't count. I only know 1 distro that offers it, anyway: Sparky Linux.
MAXX Interactive Desktop looks interesting but it's not (yet?) FOSS.
All that effort that's gone into creating and maintaining 8-10 different Win9x desktops in C using Gtk. It's tragic.
And yet there is still no modern FOSS classic-MacOS desktop, or Mac OS X desktop, or GEM desktop, or Amiga desktop, or OS/2 Workplace Shell... it's not like inspiration is lacking. There are at least 3 rewrites of AmigaOS (AROS, MorphOS, AmigaOS 4.x) but despite so much passion nobody bothered to bring the desktop to Linux?
Defenders of each will vigorously argue that theirs is the best and there are good reasons why it's the best, I'm sure, but at the end of the day, a superset of all of the features of all of them would not be visibly different from any single one.
> There are at least 3 rewrites of AmigaOS (AROS, MorphOS, AmigaOS 4.x) but despite so much passion nobody bothered to bring the desktop to Linux?
The passion is there for the whole AmigaOS, of which the desktop metaphor, Workbench, is just a part. What fun is AmigaOS without Exec, Intuition and AmigaDOS? The passion is to see AmigaOS run, not to see Linux wearing its skin.
GUIs for manipulating files a-la Workbench are readily available, nobody seems to have built an Amiga-skinned one when a Win95 one will do. DOpus is already a clone of Midnight Commander, and there are clones of that aplenty, the most DOPus-like one I've seen is Worker (http://www.boomerangsworld.de/cms/worker/)
Given this visible interest in running Amiga stuff on Linux and integrating AmigaOS (and AROS) I am very surprised that in ~30 years, nothing has progressed beyond a simple window manager.
Intuition isn't that big or complicated. It's already been recreated several times over, in MorphOS and in AROS.
I am so tired of seeing Linux desktops that are just another inferior recreation of Win95.
I want to see something different and this seems such an obvious candidate to me.
I think you can categorise Amiga enthusiasts in various ways, this is my taxonomy:
1. Hardware enthusiasts who specifically love the Amiga's original hardware, its peripherals, and the early post-Commodore direction (PowerPC accelerators), and/or modding all of the above. These sort of people used WarpOS back in the day and probably use MorphOS or AmigaOS 4 today. The question is whether, for these people, modern single-board computers "count" as Amigas or not.
2. Nostalgic enthusiasts of the system that the Amiga was, who are happy with a real Amiga, or with an emulated one, or an emulated one running on some board in a box shaped like an Amiga. Possibly with a non-Amiga UI to boot some classic games. These enthusiasts may enjoy fake floppy drive sounds that remind them of booting disks in their youth.
3. Software enthusiasts of the Amiga's OS, and the directions it took that were different from its contemporaries, and the software ecosystem that came from it. These people have a longer user-startup than startup-sequence. They probably have most of Aminet downloaded. These people might be interested in other alternative OSes, e.g. QNX or BeOS. If they're still using Amiga hardware, or emulators, they'd be interested in AmigaOS 3.5/3.9 and 3.1.4/3.2. This can also include AROS and the work to get it running on native hardware, not just m68k but also x86 and arm... but it's unlikely that it will ever support as broad a range of hardware that Linux does, which limits how many people would want to use it, because it's unlikely to be able to drive a random modern laptop.
4. The reverse of 3, Amiga users that were big UNIX fans, e.g. Fred Fish, the sort of people who ran GeekGadgets and replaced their AmigaShell with pdksh. They probably just moved wholesale to Linux and didn't look back.
There are probably other categories, but I think the one you're looking for is 5: enthusiasts of the Amiga's look and feel, but not its broader OS or its software. If they did care about that, they'd be in groups 2 and 3, and emulators or alternative AmigaOSes would satisfy them most.
I can't say why there aren't many alternative desktops for Linux. Probably because it takes a lot of resources to build a full desktop environment for linux - a Window Manager, or even just an existing Window Manager theme is not enough. A file browser is not enough. Ultimately it takes the applications themselves to play along, which only works when have the clout to make people write software in your style (e.g. KDE, GNOME, Windows, macOS, Android, etc.).
The only alternative UI taken from retro machines to Linux, that I can think of, is ROX Desktop (https://en.wikipedia.org/wiki/ROX_Desktop) with its ROX-Filer... and even that doesn't look entirely like RISC OS, which you could be running instead of Linux.
You say a WM isn't enough, and I agree, but in this case, amiwm is still right there.
I own an Amiga and I'm interested and I try to cover Amiga news, but back in the 1980s, I was an Archimedes owner. I loved RISC OS and I never mastered AmigaOS. This is not something I personally want, although I'd love to write about it.
I feel the same, too many people doing similar stuff in slightly different syntax, too few people looking at how things are similar and could be unified.
I think it's time to look beyond syntax in programming and untyped lambda calculus is the simplest choice (that is universal and can easily express new abstractions).
Mathematics suffers to some extent from a similar problem, but recent formalization efforts are really tackling it.
The thing is, the most fundamental obstacle to unification, is that unification is a very hard feature to obtain. Even in an LC formalization, do you expect that two "text editor" programs would be interchangeable? Would only a canonical text editor be allowed? Does the LC facilitate arbitrary extensions, that perhaps follow some rules at the interface/boundary? While I also lament what is, on the whole, wasted work and interest, I think the alternative is not some much simpler solution, but rather to offer something that is better. https://xkcd.com/927 is a warning, as true as it is annoying. We gravitate towards variety because it is simpler and natural to how we act; how will your proposal fundamentally improve on this? You call out misguided "defenders", and again I note the same problem, but you seem to be calling for One True Way with no significant realizable improvement.
Sometimes you can prove mathematically that two different approaches are equivalent, but differ only in name or some parameter, and that's a unification of sorts, without proliferation of standards.
In case of UIs, this is still an open problem and will be for many years, but I suspect we could do it by defining, in some kind of fuzzy logic for example, what a good UI does look like. Then we could transfer elements from one UI into another.
Or we could just start at the edge. For example, we can unify what a "user input" is, and what a "widget on the screen" is. Formalizing everything would allow us to do such transformations on programs, for example, universal input/output remapping. And then we could continue to unify into more specific logic of what input is being read and how things are drawn on the screen.
Untyped lambda calculus (and its sibling combinatory logic) is just language for expressing logic, nothing more. And it already exists (arguably it's one of the first programming languages, predates Forth and Lisp by at least two decades) and is among the simplest ones we know. I actually became interested in LC so much recently because, believe it or not, expressing things in classical logic is often more complicated than expressing things in LC.
> Sometimes you can prove mathematically that two different approaches are equivalent, but differ only in name or some parameter, and that's a unification of sorts, without proliferation of standards.
Certainly, but that would already be supposing most of the work to unify at the source level is done, unless an extremely strong normalization is possible.
> Untyped lambda calculus (and its sibling combinatory logic) is just language for expressing logic, nothing more. And it already exists (arguably it's one of the first programming languages, predates Forth and Lisp by at least two decades) and is among the simplest ones we know. I actually became interested in LC so much recently because, believe it or not, expressing things in classical logic is often more complicated than expressing things in LC.
(Personally, I prefer combinators slightly more)
I don't deny the power of LC for some uses, but taking one program, reducing it down to an LC equivalent, and then resurfacing as another program (in a different language, but otherwise equivalent), or some other program transformations you may desire, would certainly be elegant in some sense, but very complex. It's like programming in Brainfuck; the language itself is very simple, and making mechanistic tooling for it is very simple, but I don't think the tooling we could invent in 50 years would be sufficient to make Brainfuck simple to read or write. Moreover, formalizations of, say, "button" are not a problem, but scaling to different screens, devices, use cases, and so on will greatly increase the scope. This OS represents input events this way, this hardware provides that sort of data. I think this is the same problem as to why people, everyday, don't bother to make formal arguments almost all of the time. It's not that a formal argument along the lines of "you didn't take out the trash today, so I have reason to be frustrated with you" can't be formulated or proven, but rather that the level of rigor is generally considered both fatiguing and unnecessary.
Any time someone suggests something that should make things much simpler, I'm skeptical. There are things that have essential complexity too great to be made simple, and then humans maybe have an inherent overhead of accidental complexity, above and beyond the accidental complexity we accidentally add. I'm still interested to see where your efforts lead, but I'm not expecting to see cheap nuclear fusion for another 10 years at least, so.
What exactly do you mean with this? That the amount of programming languages available isn't actually helpful, it's detrimental?