The worst advice I was ever given by a professor is that Gang of Four is the only programming book worth reading. After that, its just a matter of practice 🙃
he is one of the founders of bandcamp, actually. they were just starting it at the time, and then it blew up, so ofc I took his advice seriously.
same guy who was adamant that C and C++ are the only serious programming languages, which I took as a simple fact until ~7 years ago, unfortunately.
once he threw a house party, and there was a half-finished bowl of Fruity Loops in his bathroom on the toilet mantel.
> same guy who was adamant that C and C++ are the only serious programming languages,
The error is thinking that there can be only one programming language. Obviously, it is better reducing the number of PL and paradigms, but one is not the optimal 🙂
There are successful commercial software analysis tools written in Prolog. Many theorem provers are written in FP languages. Many workflow jobs that run on the cloud are written in Go. Rust is used for multithreading code with manual memory. Ada and Spark are used in operational software where there must be some proofs. Erlang is used for distributed services. Etc...
These are serious systems, used in production. If you try to rewrite them in C++, probably you will fail, because the task is enormous without using the proper PL for the specific domain.
> The error is thinking that there can be only one programming language.
There can, but it's definitely not C++; despite attempts of the committee to ape from every language in existence.
you can use one PL, but not one paradigm and not one run-time. At a certain point you had to introduce Actor semantic if you want to manage complex distributed systems, or logical programming if you want to specify complex business rules, and so on. In the end you have many PL paradigms, using more or less the same syntax. It is the Common Lisp approach.
@mzan
are you saying that Basically The Good Algorithm Here mostly has one, or a few quite analogous approaches to implementation? But I'm supportive of DSLs and the MOP in common lisp. Or [I forgot the punny name of Kiczalez' implementation of MOP for schemes] for rml and ramin
@hayley @ramin_hal9001 @rml
@screwtape @mzan @hayley @rml for what it's worth, I don't like the idea of using lots of runtimes, it increases complexity, attack surface, opportunities for bugs. But I do agree that you can't just use one. There are times when you really do need an interpreter, and times when you really do need good single-threaded performance without garbage collection, and times when you really do need massive networks of objects with asynchronous object passing, and times when you need good performance measurements and instrumentation, and so on.
That said, I see no reason why all of these different runtimes couldn't be implemented in a version of Lisp that used Rust-like memory management, with the higher level parsing and intermediate language representation implemented in an ordinary garbage collected Lisp.
> That said, I see no reason why all of these different runtimes couldn't be implemented in a version of Lisp that used Rust-like memory management,
The concept of run-time is wider than a Rust-like "minimum common denominator".
A DBMS with its index types and its query plans is a "run-time". It offers various operations with specific cost-models.
The BEAM with its fine-grained concurrency is a run-time minimizing latency, but with rather limited bandwidth (they are working on a JIT). If you try to call C libraries into BEAM code, you increase bandwidth but you can ruin totally the latency aspects, and you can block services. So, you had to implement the BEAM in Rust, instead of C, but it will be a BEAM run-time, not a Rust run-time.
Linux kernel BPF code is an ad-hoc high-level managed language that can be compiled to efficient code, taking in account also all other submitted BPF fragments submitted by various applications. If you give to this language all the power of Rust, the kernel cannot check and optimize it.
GPU has its specific run-time, and the code must follow a certain paradigm.
The run-time can be affected by the characteristics of the hardware and/or of the problem domain. For the programmer, it is usually a simplified model from which you can derive the approximate cost of operations; the error that are signaled; etc...
We live in a multi-paradigm and multi-runtime world. We cannot escape this.
@screwtape @hayley @rml
@mzan I had Erlang BEAM specifically in mind when I mentioned that there are "times when you really do need massive networks of objects with asynchronous object passing".
I mentioned features of a few vastly different language runtimes by their characteristics (C, BEAM, Petite Chez), and you mentioned a few others (SQL, Cuda, Linux BPF), and I will say again that I agree with you that we live in a multi-paradigm, multi-runtime world.
But what I meant to say, when I said:
> "I see no reason why all of these different runtimes couldn't be implemented in a version of Lisp that used Rust-like memory management."
was that there are many paradigms and many language runtimes, but since it is possible to implement a runtime in any language at all, it is theoretically possible that all language runtimes be implemented in just one language, for example Rust or Pre-Scheme. It does not even need to have a Rust-like borrow checker, just that when you construct a runtime for a programming language, it is usually better to write the runtime in a language without garbage collection so that you don't force the garbage collection into the language you are implementing (which may not want it), rather you leave it as an optional feature.