Shlee messed around &Sep 14, 2023

CVE-2023-4863 is going to require patching everything that renders WebP images. Every browser/electron apps/mobile apps like telegram/Flutter apps/etc etc

Welcome to the modern software supply chain!

Show threadLisPiSep 14, 2023

@shlee All of this could've been avoided if it was written in the OG #MemorySafe #Ada / #SPARK (normally I'd say #CommonLisp, but on very resource-constrained platforms it performs a bit worse, such hosts do call for Ada) like it should've been.

Writing any new non-toy #software in C or similar #MemoryUnsafe languages is gross #negligence, nothing else.

#programming #security

Show threadNot a Spring OnionSep 14, 2023

@lispi314 @shlee

Which is why we need a tiny, standardized Lisp that can, if necessary, be transpiled into a language for which we have to happen a compiler at hand.

I mean, "reading/writing an image" has "pure functional" written all over it.

Show threadLisPi

@wakame @shlee I wouldn't mind such a standard showing up.

Unfortunately for the very resource-constrained, even Scheme can be a bit chonky.

It has been tested in the past (with pretty promising results) that a small #embeddable #bytecode VM can actually do that job relatively well (while minimizing porting effort).

But even then, aggressive tree-shaking is basically mandatory.

I'm curious to see where #Guile and #WASM will go, for this reason among others.

Sep 14, 2023 at 11:52pmWeb
Show threadLisPiSep 14, 2023

@wakame @shlee It's possible to have CL implementations running on <=1MB hardware, CCL was an example.

It was also utterly unportable as most of it was written in platform-specific assembly.

Show threadNot a Spring OnionSep 14, 2023

@lispi314 @shlee

From my perspective, functional languages are description first and programming languages only second.

Concepts like "tree-shaking" exist because for a long time it wasn't obvious to remove code you don't need.

And the question if something is needed depends on the "expressivity" of a language.

Therefore, it is IMHO easy with proper functional languages, nearly impossible with C.

[Btw: This is a bit of a pseudo-religious topic for me, sry ​]

Show threadLisPiSep 15, 2023

@wakame @shlee It also depends on the purpose/paradigm of the language.

Lisp systems are inherently dynamic systems you're supposed to be able to reprogram live, which means keeping most of the implementation & compiler around.

So static deployment removes a lot of that and represents a special case (hence tree-shaking).

Also, #Ada & #GNAT support dead-code elimination (https://gcc.gnu.org/onlinedocs/gcc-7.5.0/gnat_ugn/Reducing-Size-of-Executables-with-Unused-Subprogram_002fData-Elimination.html#Reducing-Size-of-Executables-with-Unused-Subprogram_002fData-Elimination).

GNAT User’s Guide for Native Platforms: Reducing Size of Executables with Unused Subprogram/Data Elimination

GNAT User’s Guide for Native Platforms: Reducing Size of Executables with Unused Subprogram/Data Elimination

Show threadNot a Spring OnionSep 15, 2023

@lispi314 @shlee

For me, it seems like the original idea of Lisp was lost along the way:
An alternative description of computation (instead of Turing machines).

Which would lead to something that current languages fail at:
The ability for the computer to reason about the program. In a way, "understanding" the program.