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.
@ramin_hal9001
I can't see that rust-like memory management could be important. You mean you want a compile time garauntee from the compiler that no consing is happening in this block? I don't think it's that hard to write sbcl code that doesn't cons: But garbage collection is fundamentally good.
@mzan @hayley @rml
@screwtape @mzan @hayley @rml garbage collection is good, except when you want to write operating system kernels, especially for real time applications. I think it is better for the compiler be able to provide some guarantees that memory isn't just being allocated on the heap without being able to prove some programmatic path exists to the end of life of that allocation.
I haven't tried playing with it yet, but I understand that PreScheme which was a subset of Scheme used to compile the Scheme48 compiler, is a non-garbage collected Scheme.
@ramin_hal9001 @screwtape @mzan @hayley @awkravchuk
what do you think about the ephemeron-guardian-weak pairs trifecta for manually managing memory in a garbage collected language? I've just started playing with it in chez, but havent thought of a good test case for it yet.
also how does SBCL memory management work? for some reason I think I recall that much of its tooling for bare bones bit twiddling resides on the FFI side of things, but its quite sophisticated, with FFI not specifically being tied to interfacing with other languages.
you are lucky: @hayley worked on the SBCL GC, so she can answer.
My 2cents are that, apart the GC, CL gives you a lot of power for optimizing memory management because: with MOP you can customize the memory layout of CLOS objects; if performances are important, you can work on big-chunk of data, stored in arrays, and here CL can give you a lot of options for specifying their format. In both cases, you are reducing the work for the GC, because you have less objects, and you can control (at least partially) how they are stored.
It is a lot of power, that few PL offers.
