Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Steel Bank Common Lisp version 2.6.7

sbcl.org

Post reply on HN
Print view View original

131–140 of 172 posts

Re: Steel Bank Common Lisp version 2.6.7

#131

Post by vindarel »

dmux wrote: post #127
maleldil wrote: post #110

Earlier quoted context omitted.

It still uses Arc. The original implementation was written in Racket, then rewritten in Common Lisp and run on SBCL.

I know Racket was reworked to build upon Chez Scheme several years ago. If the HN migration to CL was due to performance reasons, I wonder if sticking it out and waiting for the Chez version of Racket would have paid off.

here:

    I’m curious: was Arc running Racket BC or CS? I understand it got a big performance boost after switching to Chez Scheme.

    dang: It was running BC. I had high hopes for switching to CS because I'd heard the same thing you had, but when I tried it, HN slowed to a crawl. This stuff is so unpredictable.
https://news.ycombinator.com/item?id=47140657

Re: Steel Bank Common Lisp version 2.6.7

#132

Post by jhgb »

p_l wrote: post #106
guenthert wrote: post #98

Earlier quoted context omitted.

It is my understanding that easing bootstrap was the original motivation of the fork of CMU CL. I'm a bit confused about that, since CMU CL supports compilation to byte-code (which should make a port to a new architecture comparatively easy), a feature which was dropped in SBCL.

The sane bootstrap is not about porting to new architecture, but about building the compiler from source in the first place. CMU CL effectively requires that you use the same version of CMU CL to build it, IIRC, which in practice meant you had to first load the changes into older CMU CL image - overwriting core components, and then use that image to compile new version. The difference with SBCL is that it can compile…

> As for the bytecode, as far as I recall CMU CL did not have bytecode compiler at all

The byte code compilation option is described in CMUCL documentation, section 5.9 Byte Coded Compilation: https://cmucl.org/docs/cmu-user/html/Byte-Coded-Compilation....

Re: Steel Bank Common Lisp version 2.6.7

#133

Post by igouy »

galaxyLogic wrote: post #92
baq wrote: post #12

I wonder sometimes how the world would look like if lisp won and the unit of deployment was a lisp machine image, if that makes sense. How would a kubernetes optimized for lisp look like? How would AWS EC2 look like? etc.

That would be a bad idea. In Smalltalk the "image" was the main thing and I think that was one thing that led to the commercail demise of Smalltalk. You can not combine two (or more) images. You can not build new things by using "images" as components. Instead as we know source-code modules with well-defined interfaces between them is what keeps productivity hhigh. At least before AI.

> You can not combine two (or more) images.

Depends what you mean. Details matter.

> You can not build new things by using "images" as components.

Depends what you mean. Details matter.

Re: Steel Bank Common Lisp version 2.6.7

#134

Post by igouy »

goatlover wrote: post #94
galaxyLogic wrote: post #92

Earlier quoted context omitted.

That would be a bad idea. In Smalltalk the "image" was the main thing and I think that was one thing that led to the commercail demise of Smalltalk. You can not combine two (or more) images. You can not build new things by using "images" as components. Instead as we know source-code modules with well-defined interfaces between them is what keeps productivity hhigh. At least before AI.

Images can be saved out as files, so I don't see why not. Also, I recall it was the expensive commercial licensing along with the rise of cheap PCs as competition to Lisp and ST machines. That and Java being free with a focus on networking and the web was the final nail in squashing Lisp or ST popularity.

March 7, 1988 — "Smalltalk/V 286 is available now and costs $199.95, the company said. Registered users of Digitalk's Smalltalk/V can upgrade for $75 until June 1."

https://books.google.com/books?id=CD8EAAAAMBAJ&lpg=PA25&dq=d...

September 1991 — "Smalltalk/V code is portable between the Windows and the OS/2 versions. And the resulting application carries no runtime charges. All for just $499.95."

(Advert on the last page of "The Smalltalk Report")

https://rmod-files.lille.inria.fr/Archives/TheSmalltalkRepor...

Re: Steel Bank Common Lisp version 2.6.7

#135

Post by igouy »

goatlover wrote: post #94
galaxyLogic wrote: post #92

Earlier quoted context omitted.

That would be a bad idea. In Smalltalk the "image" was the main thing and I think that was one thing that led to the commercail demise of Smalltalk. You can not combine two (or more) images. You can not build new things by using "images" as components. Instead as we know source-code modules with well-defined interfaces between them is what keeps productivity hhigh. At least before AI.

Images can be saved out as files, so I don't see why not. Also, I recall it was the expensive commercial licensing along with the rise of cheap PCs as competition to Lisp and ST machines. That and Java being free with a focus on networking and the web was the final nail in squashing Lisp or ST popularity.

Java being free-as-in-beer.

Re: Steel Bank Common Lisp version 2.6.7

#136

Post by fuzztester »

klibertp wrote: post #58
ivxvm wrote: post #23

Earlier quoted context omitted.

Anywhere is where exactly? I've been thinking of where I could use it for like 10 minutes, and I couldn't come up with anything. Maybe a game engine or web services. It wouldn't make much sense for any kind of desktop software or command line utilities that are supposed to start really fast and have minimal runtime.

On the contrary, CLI, TUI, and desktop GUI apps are basically the only kinds of apps that benefit from CL and can live with its shortcomings. The startup time of a tool written in CL is short: you just need to load the image into RAM, run some hooks (if configured), and you're good to go. If you don't include loads of dependencies, the dumped image is also not too big, so loading it from an SSD is almost instantaneou…

>For hobby stuff, I found an even more niche solution that is more enjoyable to work with in the GUI/TUI/CLI space.

What is that solution?

Re: Steel Bank Common Lisp version 2.6.7

#137

Post by klibertp »

fuzztester wrote: post #136
klibertp wrote: post #58

Earlier quoted context omitted.

On the contrary, CLI, TUI, and desktop GUI apps are basically the only kinds of apps that benefit from CL and can live with its shortcomings. The startup time of a tool written in CL is short: you just need to load the image into RAM, run some hooks (if configured), and you're good to go. If you don't include loads of dependencies, the dumped image is also not too big, so loading it from an SSD is almost instantaneou…

>For hobby stuff, I found an even more niche solution that is more enjoyable to work with in the GUI/TUI/CLI space. What is that solution?

GToolkit[1] - a Smalltalk environment that's based on Pharo but replaces the UI framework and some other parts of the stack. It uses Rust through FFI to interface with and bundle native dependencies.

I don't remember the exact numbers, but when I checked, the GT+Pharo ecosystem (available packages, number of people in Discord, tools with support for the language, etc.) was ~2x smaller than Common Lisp's. It also comes with its own problems, some of which CL doesn't suffer from (the GIL, performance, startup time). But it's very fun to use and play with, which is the most important quality for me in my hobby/side-projects. :)

[1] https://gtoolkit.com/

Re: Steel Bank Common Lisp version 2.6.7

#138

Post by groundzeros2015 »

pfdietz wrote: post #121
groundzeros2015 wrote: post #82

Earlier quoted context omitted.

You can configure (read) to be safe for this purpose. It’s not a hack.

Yes, there's a specific standard special variable controlling it, *read-eval*.

You can also configure a read table to disable any other data structure features you want.

inb4 DoS attack. That is a universal parsing problem and should be solved by configuring OS limits for your process.

Re: Steel Bank Common Lisp version 2.6.7

#139

Post by Archit3ch »

peri-cl wrote: post #101
wk_end wrote: post #3

* the SB-SIMD contrib now supports ARM64. (Thanks to Sylvia Harrington) * AVX512 instructions are now supported on X86-64. (Thanks to Robert Smith and Arthur Miller) * additional support for SIMD instructions on ARM64 and X86-64. (Thanks to Arthur Miller) These seem like pretty awesome additions. Does anyone know how SIMD works in SBCL? Is this at the codegen layer? i.e. can it auto-vectorize or anything like that? O…

> "AVX512 instructions are now supported on X86-64" This is the first news I've seen on HN in weeks that I am genuinely excited about! I have several AVX-2 hobby projects in Common Lisp, and an AVX-512 machine. It's an unexpected surprise to read this morning that this very useful ISA is suddenly unlocked. I'll be trying it out right away. (edit: Looks like they mean *compiler* support for AVX-512, but not SB-SIMD de…

> I much prefer it to writing intrinsics in C (and the results are just as good). It's an interactive, exploratory, coding: I write small modular functions, SBCL compiles them on the fly, I glue them together with high-level language constructs.

Same here, but in Julia instead. Sometimes I drop down to LLVM intrinsics (e.g. to force lop3.lut on GPUs).

Re: Steel Bank Common Lisp version 2.6.7

#140

Post by tyromaniac »

neutronicus wrote: post #124
tyromaniac wrote: post #111

Earlier quoted context omitted.

https://guix.gnu.org/

Yeah, I mean, I know it exists, but the mythology of Lisp is built around "I can drop into a REPL and execute arbitrary code on a production system and that is a good thing"

As opposed to our wonderful world where everyone does the same with unchecked binaries or obfuscated/minified JS?

To me the mythology of lisp (from my mostly outsider perspective) is more like "make everything a interoperable DSL" (although if this is what you were describing with your sentence then thats fair enough)

Post reply on HN