laarcnew | comments | discord | tags | ask | show | place | submitlogin

From the benchmarks I've seen https://ecraven.github.io/r7rs-benchmarks/ Chicken did not seem to fare that well (and it seems they tested both the interpreted and compiled version). It has an amazing community and set of modules, though. Guile 2.9.1 just had a JIT included https://www.gnu.org/software/guile/news/gnu-guile-291-beta-released.html, but it's still behind the rest.

In terms of pure performance, you probably heard about Stalin, with the approach outlined in the "Flow-Directed Lightweight Closure Conversion" paper by its author https://engineering.purdue.edu/~qobi/papers/fdlcc.pdf.

Gerbil http://cons.io based on Gambit, caught my attention. It has a really interesting and rich API and includes what looks like fairly advanced meta-programming facilities. I haven't use it yet, but I found it

It's funny how diverse Scheme implementations are, and how they each have different strength and weaknesses. Even Lisps seem more consistent in comparison!




Thanks for the benchmarks. Daaaamn, Chez is dominating them! That's gotta be some great engineering behind that compiler. Ok, nevermind, and will just look into Chez, Stalin, and Gerbil. Thanks for the paper: I missed it somehow.

"It's funny how diverse Scheme implementations are, and how they each have different strength and weaknesses. "

Such adaptability was a strength of the Schemes and LISP's. Also their weakness. People could arbitrarily change the languages so much that the software was hard to maintain at a team level. It's why I advocate for simpler, consistent forms for the default way to program with the macros and stuff being use really selectively. And with it clear they're macros. I remember reading from a few people that they did something similar in LISP shops. I don't have much data on that, though.

-----

3 points by sebastien 486 days ago

That paper is not obvious to find, it's not usually mentioned along Stalin Scheme, but it probably should be. I've updated the Wikipedia page as it didn't mention it https://en.wikipedia.org/wiki/Stalin_(Scheme_implementation)

Back in 2005 I went to the Montréal Scheme User Group and met people who were using Lisp professionally for NLP applied to telecom (voice-controlled automata). A few years later I bumped into one of them again and asked what happened: they were hiring Java engineers. The guy told me that the problem with Lisp is that the code was getting more difficult to understand as layers of abstractions were piled onto one other (people were creating new vocabularies to adapt the system to evolving requirements). He said that although the Java version was architecturally less elegant and more verbose, it was also more straightforward and allowed for less qualified developers to maintain and expand the application.

From my personal experience I find that Lisp, and more particularly Scheme is an amazing way to prototype high-level concepts. Instead of starting off coding right away, I now spend time expressing concepts and structures as S-Expr and pseudo-Scheme as part of the documentation, with the intention of creating a simple Scheme runtime to validate them. However, I probably would not create a production system with Scheme -- I use Python for prototyping implementation, and would probably use Rust now for a production version (as opposed to C).

BTW, you might enjoy this podcast http://www.se-radio.net/2008/01/episode-84-dick-gabriel-on-lisp/ -- there's plenty of interesting anecdotes and a really funny song at then end.

-----


"He said that although the Java version was architecturally less elegant and more verbose, it was also more straightforward and allowed for less qualified developers to maintain and expand the application."

That's why I was saying maybe we should treat commercial Lisp like any other language with the macros just handling weird situations. Maybe giving us new constructs, optimizing something with obvious meaning, handling portability, and so on. You could say kind of like how D, Rust, and Nim use them.

Boring, predictable code is better in long-term in businesses. So, we make Lisp's boring until boring solution is too painful. Then, we get it clever with clear docs about what's going on. Should prevent their problem, yeah?

"BTW, you might enjoy this podcast"

I'll check it out later.

-----




Welcome | Guidelines | Bookmarklet | Feature Requests | Source | Contact | Twitter | Lists

RSS (stories) | RSS (comments)

Search: