Lisp and the foundations of computing

Posted Feb 12, 2019 16:17 UTC (Tue) by rweikusat2 (subscriber, #117920)
In reply to: Lisp and the foundations of computing by Cyberax
Parent article: Lisp and the foundations of computing

>> And that's the precise reason why I keep writing a lot of Perl 5 code.
> Perl 5 is typically used in short-lived processes where memory leaks don't bother anybody. Long-lived Perl 5 code is a recipe for a
> disaster.

Even short-lived processes may sometimes need a lot of memory (or file descriptors). As I already mentioned, there are also other kinds of resources where "exhaust and [try to] recover from that" often cannot be used (locks). As opposed to "long-lived Java processes" which are a recipe for "club to death with a blunt instrument and restart" (to free up memory), perl handles long-lived processes just fine. As opposed to a popular superstition, programming languages don't write code, programmers do :-). Perl isn't particularly concerned with forcing people to code sensibly and combined with the mindset which begat the gets-using fingerd, this is a recipe for disaster. But the disaster is duly going to be repated in any other kind of programming language as "human ingenuity" can beat any kind of automated safety measure.

> First, plenty of architectures have tagged memory so pointers are explicitly treated NOT as data. Even Intel tried to move
> that way with MPX.

"Plenty of recent CPU designs" have some sort of support for "tagged pointers" because it's conjectured that this will be useful for something (in addition to making certain people less uncomfortable). Whether this will lead to anything in the real world remains to be seen. On mainstream Linux (etc) pointers are 'just data'.

> Second, simply not exposing the raw pointer arithmetic to the underlying language is enough so that compiler/runtime can
> always enumerate all the live pointers.

It's always possible to write another IBM 704 emulator in software. But why?

Lisp and the foundations of computing

Posted Feb 13, 2019 1:00 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> Even short-lived processes may sometimes need a lot of memory (or file descriptors). As I already mentioned, there are also other kinds of resources where "exhaust and [try to] recover from that" often cannot be used (locks).
That's why most languages these days have some kind of try-with-resource blocks: "with" in Python, "defer" in Go, "try(...)" in Java and so on. And unlike the leak-prone Perl code it works reliably.

> perl handles long-lived processes just fine
Yeah, by leaking tons of memory and eventually crashing.

> "Plenty of recent CPU designs" have some sort of support for "tagged pointers" because it's conjectured that this will be useful for something (in addition to making certain people less uncomfortable).
These designs are definitely more secure, they eliminate possibility for a whole class of vulnerabilities. Unfortunately, gung-ho C/C++ programmers have contaminated pretty much everything with unsafe pointer arithmetic crap that can't utilize tagged memory efficiently.

> It's always possible to write another IBM 704 emulator in software. But why?
Because GC is more reliable than refcounting done by gung-ho programmers.