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

Dotcl: Common Lisp Implementation on .NET

github.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Dotcl: Common Lisp Implementation on .NET

#31

Post by pjmlp »

Pay08 wrote: post #29
pjmlp wrote: post #27

Earlier quoted context omitted.

UNIX was only cheap because AT&T was forbidden to profit from it, had it not been the case, it would have been a proprietary closed source OS, exactly at similar price points. The proof being the graphical UNIX workstations from Cray, SGI, Sun, NeXT that came later into the market.

The dimension you're missing here is that most of the Lisp OSs were single-user (AFAIK initially all of them were but some gained multi-user support later) in a period when timeshare was king. Not to mention that the hardware itself cost multiple times more to manufacture.

How many UNIX graphical workstations from Cray, SGI, Sun, NeXT do you think were multiuser in practice?

As for price, they were also not cheap to get.

Re: Dotcl: Common Lisp Implementation on .NET

#32

Post by jjtheblunt »

jksmith wrote: post #24
djha-skin wrote: post #17

I have recently blogged that AI and Common Lisp don't mix, but I've come to the opposite conclusion lately. AI evens the playing field between large teams and single developers. Now all the lone wolves in cl will be able to do large things, like a .net implementation or a yaml parser. I heard one guy say he was using AI to write a c complete in common lisp. I wonder if AI was used here or not.

Use python or whatever to build the llm, use lisp to explore and infer from the edges of what the llm has to offer. I don't do anything but lisp these days. Been waiting my whole career to be at this point. I'll never "write" a line of C# again. Just my taste and pref.

may i ask which lisp variant you are using?

Re: Dotcl: Common Lisp Implementation on .NET

#33

Post by jksmith »

jjtheblunt wrote: post #32
jksmith wrote: post #24

Earlier quoted context omitted.

Use python or whatever to build the llm, use lisp to explore and infer from the edges of what the llm has to offer. I don't do anything but lisp these days. Been waiting my whole career to be at this point. I'll never "write" a line of C# again. Just my taste and pref.

may i ask which lisp variant you are using?

Franz Allegro toolchain.

Re: Dotcl: Common Lisp Implementation on .NET

#34

Post by arikrahman »

jonnytran wrote: post #26
Syzygies wrote: post #23

Any benchmarks? I have a combinatorial enumeration comparison project where the .NET jit optimized my hot loops for F# to in some cases matching Rust performance. F# is inspired by OCaml, and for me F# runs twice as fast. Scala got a face lift where indentation replaces syntax, a modern poetry look many of us can't live without. It is entirely practical to eliminate most parentheses from Lisp (I have written thousand…

Have you tried Clojure?

This has been the best grounded approach of introducing Lisp to the masses, myself included. Rich Hickey made a language that is the most well positioned in this new LLM era.

Re: Dotcl: Common Lisp Implementation on .NET

#35

Post by arikrahman »

jksmith wrote: post #24
djha-skin wrote: post #17

I have recently blogged that AI and Common Lisp don't mix, but I've come to the opposite conclusion lately. AI evens the playing field between large teams and single developers. Now all the lone wolves in cl will be able to do large things, like a .net implementation or a yaml parser. I heard one guy say he was using AI to write a c complete in common lisp. I wonder if AI was used here or not.

Use python or whatever to build the llm, use lisp to explore and infer from the edges of what the llm has to offer. I don't do anything but lisp these days. Been waiting my whole career to be at this point. I'll never "write" a line of C# again. Just my taste and pref.

Likewise, I would never have thought to be daily driving Elisp on Emacs and Clojure in production, but here we are.

Re: Dotcl: Common Lisp Implementation on .NET

#36

Post by Blackthorn »

jonnytran wrote: post #26
Syzygies wrote: post #23

Any benchmarks? I have a combinatorial enumeration comparison project where the .NET jit optimized my hot loops for F# to in some cases matching Rust performance. F# is inspired by OCaml, and for me F# runs twice as fast. Scala got a face lift where indentation replaces syntax, a modern poetry look many of us can't live without. It is entirely practical to eliminate most parentheses from Lisp (I have written thousand…

Have you tried Clojure?

Clojure isn't known for performance.

Re: Dotcl: Common Lisp Implementation on .NET

#37

Post by Jach »

Syzygies wrote: post #23

Any benchmarks? I have a combinatorial enumeration comparison project where the .NET jit optimized my hot loops for F# to in some cases matching Rust performance. F# is inspired by OCaml, and for me F# runs twice as fast. Scala got a face lift where indentation replaces syntax, a modern poetry look many of us can't live without. It is entirely practical to eliminate most parentheses from Lisp (I have written thousand…

This project? https://github.com/Syzygies/Compare

If Dotcl does have good performance, it would be interesting to try running Coalton on top of it too. Coalton syntax is probably not unusual if you are familiar with OCaml and F#: https://github.com/coalton-lang/coalton (Though I'd expect the performance of the typical use case of running on top of SBCL to still be better.)

From the same project there's the recently released mine editor that's trying to be a friendlier gateway into trying Common Lisp (and/or Coalton) than emacs: https://coalton-lang.github.io/mine/ Time-to-first-SHOUTING is still once you start a REPL though -- it tells you that your package (namespace) is CL-USER. I sort of think it's one of those things that grows on you, or at least isn't annoying after a while (until you need to deal with certain foreign function interfaces anyway), and it's an interesting possible convention to use SHOUT-CASE in docstrings to call out specific parameters or other function names instead of some @param, \param, @link, or what have you.

Re: Dotcl: Common Lisp Implementation on .NET

#38

Post by Syzygies »

jonnytran wrote: post #26
Syzygies wrote: post #23

Any benchmarks? I have a combinatorial enumeration comparison project where the .NET jit optimized my hot loops for F# to in some cases matching Rust performance. F# is inspired by OCaml, and for me F# runs twice as fast. Scala got a face lift where indentation replaces syntax, a modern poetry look many of us can't live without. It is entirely practical to eliminate most parentheses from Lisp (I have written thousand…

Have you tried Clojure?

I admire Clojure, and Rich Hickey's deep experience and knowledge of languages that he brought to the table. Clojure bottomed out for my comparison.

Perhaps an expert could strike a better balance, but it struck me and my various agents that we'd be fighting the language to make it faster.

https://github.com/Syzygies/Compare

Re: Dotcl: Common Lisp Implementation on .NET

#39

Post by Syzygies »

Jach wrote: post #37
Syzygies wrote: post #23

Any benchmarks? I have a combinatorial enumeration comparison project where the .NET jit optimized my hot loops for F# to in some cases matching Rust performance. F# is inspired by OCaml, and for me F# runs twice as fast. Scala got a face lift where indentation replaces syntax, a modern poetry look many of us can't live without. It is entirely practical to eliminate most parentheses from Lisp (I have written thousand…

This project? https://github.com/Syzygies/Compare If Dotcl does have good performance, it would be interesting to try running Coalton on top of it too. Coalton syntax is probably not unusual if you are familiar with OCaml and F#: https://github.com/coalton-lang/coalton (Though I'd expect the performance of the typical use case of running on top of SBCL to still be better.) From the same project there's the recently r…

Yes, that project. I keep thinking I'm done, but it's so much fun being a language tourist.

Re: Dotcl: Common Lisp Implementation on .NET

#40

Post by arikrahman »

Blackthorn wrote: post #36
jonnytran wrote: post #26

Earlier quoted context omitted.

Have you tried Clojure?

Clojure isn't known for performance.

It has very good throughput since it's targeting the JVM. JEP 514 and JEP 515 are also making AOT a real thing, reducing warmup times. This means user will not even have to use the awesome Babashka project for scripts or drop in GraalVM.
Post reply on HN