4 ms·

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

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.

tmtvl 3y ago
> 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 https://sbcl.org/all-news.html>
- samatman 3y ago
  Half of the phones in the US run BSD. Good luck getting SBCL on it though.
  - tcmart14 3y ago
    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.
  - lispm 3y ago
    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...
    - samatman 3y ago
      > 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.
      - deleted 3y ago
        [deleted]

tmtvl 3y ago

> 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 https://sbcl.org/all-news.html>

samatman 3y ago
Half of the phones in the US run BSD. Good luck getting SBCL on it though.
- tcmart14 3y ago
  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.
- lispm 3y ago
  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...
  - samatman 3y ago
    > 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.
    - deleted 3y ago
      [deleted]