Hacker News Reader

Comment by clircle | Hacker News Reader

Lisp, like linux, might actually benefit from fewer choices

That is short-term thinking for both linux and lisp. In the long-term, we need more experimentation, more creativity, and more risk-taking. Always. And what better place for that than on HN (at least for discussion purposes).

How long is "long-term"? 10 years? 20 years? Lisp has been around for over 50 years. How long do we still have to experiment with Lisp before we're happy we've found the "ideal" Lisp?

Carpenters are still experimenting with hammers and other tools. Carpentry has been around a little longer than Lisp (except of course the Ur-Lisp the gods used to create the universe).

There is always a need for both short-term and long-term thinking. If I am running a company, I am thinking short-term (at least when it comes to tooling). If I am dreaming or doing cutting edge research, I am thinking long-term.

I think we are still just babies in the history of programming. 50 years is nothing.

I wonder how much the existence of the "a lisp" concept/term affects this.

We don't have top-level terms that cover Java, C# and Kotlin, or TypeScript and JS, or C/Objective-C/C++.

Lisp programmers often call these algol-like languages or c-like languages.

Curly-Braced Cruft

  int main() { }

  \begin{document}

  cp ${srcdir}/x ${tgtdir}/y

  .foo p { border: 0px; }

  /m { newpath moveto } def

1) C-syntax languages

2) JavaScript family languages

3) C family languages

It's actually how lisp plans to take over.. Enough implementations and before you know it you have enough lispers to eclipse all other programmers

I think I'll call my next Lisp implementation Eclispe.

Then, conquer the web with ecljspe.

All of them writing code that doesn't work for the other's little islands.

It sounds like the Discordian battle cry: united we fall, divided we stand!

and then one day, a Lisp will be created amongst all Lisps

One Lisp to rule them all, One Lisp to find them, One Lisp to bring them all, and in the darkness bind them.

I think we'll be led by a programmer from another language who comes and unites the tribes against the languages that now dominate, a voice from the outer world. The "Lispan al-Gaib", if you will.

The vast array of Schemes available is part of what made me eventually land at Tcl and just dig in there.

Interestingly I've had a similar experience. I used Chicken Scheme for a number of years after programming in Tcl for a long time. Tcl always seemed to be a kind of Lisp, an impression that only increased over time. Eventually I resumed using Tcl when I realized the language had been steadily improved over several years. With Tcl 9.0 on the horizon I see no reason to look elsewhere for accomplishing most programming tasks.

Tcl offers metaprogramming capability that rivals Lisp's, but they way it goes about doing it is... kinda nuts. I don't particularly care to stare into that yawning abyss for too long, so it sits well behind Scheme in terms of languages I'd reach for.

Tcl/Tk is still an unrivalled way to prototype a GUI -- and with Snit megawidgets, it's almost like programming a modern JavaScript component framework like React.

Yes, you're right, Tcl suffers from lack of Scheme-like macros. While a lot can be done using procedures, methods and introspection "tricks", often enough it's far from elegant. However I haven't been stymied all that often. Missing functionality can sometimes be provided by C-API extensions which I've gotten pretty good at writing.

Completely agree about the utility of Tk. I remember reading somewhere that HTML/CSS widgets were influenced by Tk. Don't know how true that is but I can see how it could be.

Fun thing is that Tcl was relegated to the role of gateway drug to Common Lisp, in my case. I still use it when I want a more modern stdlib or its well-integrated event loop.

(I actually tried to retrofit some of CL in Tcl, heh; https://wiki.tcl-lang.org/page/q3cpma)

Hasn't worked for Common Lisp.

I think the wording of the article title helps push people to this conclusion. My first thought was "we're 24 years into the 21st century, I'm sure we already have one of those".

We love variance.

I think you meant to say variety.

Maybe they meant deviation.

Yes, I actually meant variety.

Hard disagree on all counts.

Seriously, how many Lisps for the 21st century do we really need? Especially considering that we are almost a quarter into that century already.

There's newLISP http://www.newlisp.org/ which takes a fresh look at lisp and has plenty of libraries.

Lately, I'm going back to what I used years ago: Common Lisp. There are great books describing it, and implementations like SBCL https://www.sbcl.org/ are solid.

p.s. Plenty of time to come with the lisp for the 22nd century!

Yep, I regularly try new ones but sbcl and emacs/slime are hard to beat.

I know it's a bit of an oddball in these discussions, but I find that I still have the most fun with Clojure. It's fast enough, relatively easy to get anything I want done, with proper functional data structures built in, with the entire JVM ecosystem to play with if I need it.

I got pretty into Chicken Scheme a few years ago, and I did a quick breakout clone in Racket as well, and I think they're pretty cool, but Clojure is the only one that has ever evolved past "toy" for me.

> the entire JVM ecosystem to play with if I need it.

Do you ever need it?

Keep in mind, I'm almost always in the engineering world more than the pure CS world, and yeah, it's often pretty useful.

The Apache tools are the biggest things for me; I do a lot of work with Apache Kafka, so being able to directly use the first-party libraries like Kafka Streams is useful. If I need to do any kind of distributed processing stuff, I have Apache Spark or Apache Flink when I need it. It's kind of falling out of favor now, but I still occasionally have a need for Apache Zookeeper as well.

Now, I'm sure that there's Clojure-first versions of these things, but the sad truth of the software landscape for me is that a lot of it is still powered by Java. I can either be tasked with reinventing a lot of the infrastructure myself by using a language that doesn't have good Java interop, or I can use a JVM language. I think that Clojure is the least-bad of the latter category.

In some ways, Clojure is an even better Java than Java; it's easy to compose together arbitrary java methods, without any kind of fancy fluent interface or anything, for example, and there's lots of helper macros that I think really do smooth over the Java-ness of certain interfaces.

This is how I feel about Kawa Scheme. It has very good Java interop without all the... Clojurisms which are like pebbles in my shoe while I'm working. It's what I'd reach for if I wanted to author, say, a large web service from scratch.

Clojure was the first Lisp I learned, and I started using specifically for its concurrency support, not the fact that it was Lisp. I later grew to love Lisp and played with other ones.

I bring this up, because I am curious which “Clojurisms” annoy you? I probably didn’t notice them because I wasn’t used to other lisps when learning it.

Common Lisp and Scheme are built on s-expressions which are lists of symbols and other atoms. All of the core syntactic constructs are based on this. Clojure decided to add in other syntax for things like arrays and maps. Which, okay, fine, other Lisps have syntax for those things too but Clojure built syntactic constructs out of these and that just messes with my Lisper brain. The way let, fn, and defn work... ugh.

A lot of Clojure people might be like "I don't see anything wrong with it, in fact I prefer things the Clojure way." Whatever. You do you, man. I just can't with that. Kawa Scheme for me every time if I want to Lisp with Java libraries. Second place, ABCL.

As someone that learned Lisp in the 1990's, starting with The Little LISPer, all the way to classics like The Art of the Metaobject Protocol, dusty digital copies of Xerox and Genera manuals, with a little XEmacs Elisp on the side, I am perfectly fine with Clojure's design decisions, and is also the only Lisp like language I still reach for.

The discussion about parenthesis is a bit ridiculous, but unfortunely their visual distribution does matter, and Clojure is more appealing to folks without Lisp/Scheme background.

i totally agree; personally (similar apache tools situation) i've been moving to Rust, an old scheme / C person myself (and lots of mathematica).

thanks for explaining.

For the records Apache Kafka defines a fairly sophisticated write protocol: request and responses, message formats etc. This is the only way any client interacts with a Kafka broker. The Kafka Java library uses that, and so is librdkafka (offering a low level C API). The latter is used by non JVM based clients -- Python Common Lisp: via FFI.

Yeah, I knew all that, I've actually used librdkafka.

If my goal were as simple "read and write and commit to Kafka", the vanilla clients like rdkafka would be fine. However, most of my personal projects for the last year have made pretty liberal use of the Kafka Streams library, which as far as I'm aware only exists in JVM land.

Slight topic shift, but did you try https://nats.io and its streaming?

We've used it and it worked well.

I have not heard of this. I'll try and play with it tonight or tomorrow, cuz it looks pretty neat.

Newlisp actually revives ancient mistakes in Lisp history. For example, there is no lexical scoping -- and "contexts" are not a substitute for lexical scoping. Lexical scoping ensures that bindings introduced within a scope cannot leak outside the text of that scope, avoiding subtle bugs that may manifest with dynamic scoping. Hence, Newlisp's lambda isn't really lambda, like Lisp 1.5's but very unlike Common Lisp or Scheme (absent side effects).

Newlisp's default (and most used) FFI is also... dangerous. You simply import a symbol from a shared lib and it gets bound to a procedure corresponding to a C call to that shared lib. No specifying of parameter types -- and most platforms do not encode parameter type information in shared libraries in a standard universal way. (Things like C++ name mangling, and COM, only apply to libraries written within their respective ecosystems.) But don't worry. Newlisp trusts you to get the parameter types right, because Newlisp is for the practical Lisp programmer. Woe betide you if you don't, though!

Guile's (system foreign) module provides a similarly dangerous FFI, but at least you can (and must) specify parameter and return types when you import a foreign procedure from a shared lib that way, allowing for checks for parameter correctness at the call site, if not the import site.

If 10 people deciding to make a language invent different new syntaxes, they don't show up on the same radar at once.

If they each make it a Lisp: oh no, how many Lisps do we need?

All these toy lisps aren't really advancing the state of the art. It's dog bites man at this point, there really isn't much new to talk about.

There's nothing wrong with that, but , oh, look, a new scheme, yea. None of the previous 70 changed my life in any meaningful way.

Functional programming is easily available in almost any modern lang, virtually all of which have better tooling (and no, I have zero interest in using emacs) and ecosystems.

gerbil is hardly a toy lisp!

What major real world systems that people actually use are implemented in scheme? Lisp programming environments don’t count. I’m talking general use software.

https://www.lambdanative.org/#apps off the top of my head

a bit of googling also came up with https://www.quora.com/How-has-Scheme-been-used-in-real-world...

That post is from years ago, and even then almost all of it is past tense. (Used not use). The three things that I actually spot checked were form the 80s. Yeah, lots of companies were throwing money at lisp during the original AI boom, not news.

not sure why you are so convinced scheme is a useless toy language that you won't even bother looking for examples. but here is a list of active projects built in chicken: https://wiki.call-cc.org/Software

Clojure? VSCode? Neovim?

It seems some people really don't like you not liking new Lisp implementations, even though nothing you said is wrong: there are already lot of Lisps, the non-toy ones have roughly the same performance characteristics across the platforms they run on, and most non-Lispers don't care about them.

I think some people may take umbrage at TylerE's statement of:

> virtually all of which have better tooling (and no, I have zero interest in using emacs) and ecosystems

Anyway, there are a lot of Lisp-like (for a given value of like) language implementations indeed, but then there are also a lot of recordings of various orchestras performing Beethoven's 6th Symphony.

Whereas those 10 languages that are not lisps are advancing syntax! Where there is syntax there's semantics, clearly. Therefore it follows that whenever there's advancement in syntax there's advancement in semantics.

No? That's not at all what I said. Come on, comment in good faith. It's not even a unique lisp, it's just yet another R<SOMETHING>RS Scheme.

Sorry, right. What I mean is that those 10 languages with new syntaxes can disguise that they're not actually new better than 10 lisps (can disguise the same). In the programming world at large most people are duped by syntax.

Someone making just a RNRS Scheme, with nothing new in it compared to other Schemes is at least honest.

Well, choice has its charms, but a non fragmented experience, with the wider combined adoption, and all the now scattered resources devoted to it, has more actual benefits.

including the implication that scheme is a lisp

Reply on news.ycombinator.com