Hacker News Reader

Comment by shrimp_emoji | Hacker News Reader

I'd argue Lisps are worse today. They encourage a thing that's generally discouraged in C: macro programming and typedefs. You're coding in Lisp, but you're actually coding in your own dialect of Lisp, eventually, with lots of idiosyncratic code that's difficult to reason about. That doesn't scale well in collaborative environments, where many people are touching a vast codebase (which I don't think was really a thing back in the '70s).

That's when you want the uniformity and clarity of static type declarations and C++'s <algorithm> header functions. With Rust, you're just adding modernity and safety on top of that. Great! Lisp is crazy lone wizard shit.

View on HN

sorry but nah, nobody encourages anyone, let alone newcomers, to write macros. You don't even need to. You can chain function calls and get the job done.

BTW you get many static type checks at compilation with SBCL, instantly, and see Coalton for more (Haskell-like on top of CL).

I think a domain-specific dialect is the best way to unlock the potential of a team of handpicked experts, but a lot of companies seem to hire an army of devs they don’t trust enough.

You can code your own dialect of ANYTHING. OOP does this all the time (anyone for Enterprise Fizzbuzz).

C considers macros as bad because they are dangerous and have all kinds of weird side effects that break things. If they had all the capabilities of lisp macros, you wouldn't be hearing all the complaints.

That is the biggest problem I have with LISP which is why I think a lot of it is historical to some degree. I do like LISP to dabble in, but yea, there are tons of different dialects, it makes it harder to approach. Because while there is 'Common' LISP, there are implementations that can vary slightly between compilers, which compiler do you use? And some of the more popular compilers are sort of dead? There is SBCL, which does get some development, but not much I think? I don't think newer version of SBCL run on most of the BSDs? And yea, you also end up creating your own dialect in the process.

Which some of those same problems could have occurred in C at some point, but C eventually converged. I can be confident my fairly simple C programs will compile just fine whether I use GCC/Clang/TCC, etc. If LISP could have converged like C did, it could be a completely different story, I wonder.

> There is SBCL, which does get some development, but not much I think?

Quoth the website*:

> New SBCL versions are usually released at the end of each month

Also, the only BSD which has even in the single digits of market share, Darwin, is only 1 point release behind.

* <https://sbcl.org/all-news.html>

Half of the phones in the US run BSD. Good luck getting SBCL on it though.

The 'BSD' on phones would be iOS and tons of languages don't mostly due to the platform.

I think a better example would be, the amount of embedded/appliances that ship forks of FreeBSD, OpenBSD, or NetBSD. Think of like routers. While Linux is the 1,000 pound gorilla in server space, there is still A LOT of BSD servers also. The person dimising BSD usage is only taking into account desktop share not realizing some OSs run on more than just consumer devices.

SBCL is a Common Lisp implementation with:

* a runtime in-memory native code compiler (-> COMPILE)

* a file native code compiler (-> COMPILE-FILE)

* and a runtime native code loader (-> LOAD)

Apple forbids providing compiled languages on (I'm talking about "ON THE DEVICE") iOS. Good luck getting those onto iOS. Their own Javascript runtime JIT is allowed, others are not. Common Lisp runtime native compilers are not. Thus one can't move a development Lisp, which includes (!) a native compiler, onto an iOS device and bring that into the Apple iOS/iPadOS/... Appstore. The Lisps which run on iOS (ECL, LispWorks), are compiled outside of iOS. They may include some kind of interpreter (source or bytecode), without a native code compiler component.

Thus: Other languages are not allowed (by Apple) to compile code to native code on (!) an iOS device. On can compile code outside of iOS and move the code to iOS (as a developer). But one can't use a language which compiles to native code ON the device.

There are other restrictions. LispWorks for example runs on iOS, but provides a special runtime with less capabilities than on macOS, also with a different garbage collector. Without the runtime native code compiler.

There might be some BSD in iOS, but different & less form an actually BSD.

To bring SBCL to iOS one thus would need to remove runtime native code compilation/loading and provide a specialized runtime with a different garbage collector. Then this would be needed to be integrated into some other application as a library, or one would need to implement a new GUI for it...

> Good luck getting those onto iOS.

That's what I said, yes.

Although as long as you're not distributing the code these restrictions don't apply. Depending on what you're doing that's either a technicality or that's how you intend to proceed, there's a reasonable amount of iOS code out there which pays no attention to Apple's rules whatsoever, and which you can't download binaries from the App Store of.

Reply on news.ycombinator.com