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

121–130 of 172 posts

Re: Steel Bank Common Lisp version 2.6.7

#121

Post by pfdietz »

groundzeros2015 wrote: post #82
g9550684 wrote: post #61

Earlier quoted context omitted.

in at least Common Lisp world slinging s-expressions is considered to be a hack, at best something you do in a development environment, like swank/slime wire protocol. one of the reasons is that a readtable is both powerful, user extendable, and has all kinds of default ways in which a malicious input would be detrimental. you can remove all kinds of reader macros like #.(xyzzy), but to make a truly bulletproof s-exp…

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*.

Re: Steel Bank Common Lisp version 2.6.7

#122

Post by pfdietz »

whyenot wrote: post #86
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.

The worst thing that ever happened to Common Lisp was its ANSI standardization, which for many years killed almost all language innovation and improvement.

On the other hand, standardization enabled Common Lisp implementations to actually be tested, so programs became much more portable across time and between different implementations.

What stopped further development of the standard was the collapse of the market for Common Lisp.

I should note that many of the things that need changes to the language definition in other languages are just libraries in Common Lisp.

Re: Steel Bank Common Lisp version 2.6.7

#123

Post by pfdietz »

jorams wrote: post #43
WalterGR wrote: post #14

If memory serves, traditionally, CCL (Clozure Common Lisp [0]) had better support for Windows but SBCL was unbeatable for speed. Is that still the case? [0] https://ccl.clozure.com/

SBCL works fine on Windows. It used to display a warning about fragility at startup, but that was removed in version 2.0.3, 6 years ago, after already being obsolete for quite a while. CCL isn't very actively maintained and currently doesn't have an ARM64 port, but otherwise continues to work fine. I believe one reason people use it is that it compiles a bit faster than SBCL, at least in part by doing less optimizati…

Using two implementations also helps identify portability issues coming from places the standard doesn't specify behavior sufficiently.

Re: Steel Bank Common Lisp version 2.6.7

#124

Post by neutronicus »

tyromaniac wrote: post #111
neutronicus wrote: post #15

Earlier quoted context omitted.

> Personally I think/hope they would have earlier discoveries / more broad usage of the deterministic systems like nix etc, which are built upon functional principles of immutability etc. Yeah, that, uh, doesn't sound like Lisp

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"

Re: Steel Bank Common Lisp version 2.6.7

#125

Post by iLemming »

Zak wrote: post #74
kscarlet wrote: post #63

Earlier quoted context omitted.

So does the community of every other dialect (Common Lisp, at least). Write a function if you don't have to write a macro, and maybe declaim the function to be inlined. The "Lisp Curse" is a ridiculous and tired myth that can only be invented by people who have looked at the language for 5 seconds and went straight to finding an excuse to not learn it.

Is it? I saw macros and went mad with power. I wrote a macro that could have been a function today . But seriously, I think Clojure has a particularly strong tradition of writing clean, readable code.

Clojure is actually an interesting case here, because it is hosted. So, you can write a Clojurescript macro that runs at compile time on the JVM, but emits code that runs at runtime in Javascript, e.g. instead of blindly loading and executing some JS lib code, your macro can first parse it, analyze it, and conditionally emit Cljs that changes the runtime behavior.

Use-cases for code that writes code across a host boundary are rare, yet enormously useful and really difficult to achieve without homoiconic nature of the language.

Hyperfiddle/Electric is a nice project that effectively utilizes the idea.

Re: Steel Bank Common Lisp version 2.6.7

#126

Post by GalaxyNova »

jorams wrote: post #43
WalterGR wrote: post #14

If memory serves, traditionally, CCL (Clozure Common Lisp [0]) had better support for Windows but SBCL was unbeatable for speed. Is that still the case? [0] https://ccl.clozure.com/

SBCL works fine on Windows. It used to display a warning about fragility at startup, but that was removed in version 2.0.3, 6 years ago, after already being obsolete for quite a while. CCL isn't very actively maintained and currently doesn't have an ARM64 port, but otherwise continues to work fine. I believe one reason people use it is that it compiles a bit faster than SBCL, at least in part by doing less optimizati…

But CCL is very stable and works very well on the platforms it supports, sometimes in a much more compliant way than SBCL.

Re: Steel Bank Common Lisp version 2.6.7

#127

Post by dmux »

maleldil wrote: post #110
SeanLuke wrote: post #108

Earlier quoted context omitted.

I recall HN originally using Arc. Is there a history available regarding its development and redevelopment?

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.

Re: Steel Bank Common Lisp version 2.6.7

#128

Post by dmux »

reddit_clone wrote: post #64
joshmarlow wrote: post #42

Earlier quoted context omitted.

I've often thought that s-expression diff-viewers would be very nice tooling. I've also often wondered how easy it would be to just sling s-expressions across the wire to execute in another environment. What would modern infrastructure look like if you could just have lambdas running lambdas?

Not sexps, but better. Quite a while back I have read about a system based on Scheme , called termite (I don't remember which scheme that was) that can actually sling live running code/closures across network and execute them remotely.. Boggles my mind even today.

Tcl has a library called "comm" [0] that lets you expose an interpreter over a socket and since everything in Tcl has a string representation, there's no need for a serialization/deserialization step.

[0] https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tclli...

Re: Steel Bank Common Lisp version 2.6.7

#129

Post by dmux »

whyenot wrote: post #86
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.

The worst thing that ever happened to Common Lisp was its ANSI standardization, which for many years killed almost all language innovation and improvement.

But _worse is better_.

Re: Steel Bank Common Lisp version 2.6.7

#130

Post by rprospero »

zellyn wrote: post #68
blubber wrote: post #16

Earlier quoted context omitted.

Common lisp isn't functional in that sense.

When I learned (Common) Lisp at Georgia Tech in the summer of 1995, we were encouraged to make as many functions as possible purely functional, and if mutation was needed, to try to hide it within the bounds of a function. So while Lisp may not be purely functional, the culture hewed that way.

That's interesting, because I had the opposite experience. I started getting into Lisp around 2004, but bounced off of the community because the culture I was experiencing hewed heavily toward imperative code and global variables in the name of efficiency.

I specifically remember the breaking point being third-party library where none of the functions had any parameters. Instead, everything was controlled by using dynamic binding to adjust the variables within the functions. Various forum members kept praising its beauty and elegance, but I found it needlessly confusing.

I have a soft spot for the Lisp family of languages. I've been using Emacs for almost thirty years and have used both Scheme and Clojure in production. However, my experiences back in 2006 have left me with a permanent bias against Common Lisp.

Post reply on HN