Ask HN: Production Lisp in 2020?

If you need a low memory consumption then Clojure is also not a great choice.

We've built an ecommerce site on Clojure though and it's been great. :)

It's kinda fine if every library you use is _slightly_ different if you can have a unified interface for how to use them (spacemacs layers system for me).

It is annoying figuring out which invocation of variables sets the tab-width for _this_ new language though...

Also, most libraries in the emacs ecosystem have become more standardised in their interfaces, so things aren't too different nowadays.

But the global variable thing is interesting; Does regular lisp differ a lot wrt snippets having broad, global effects?

There's a perceptual litmus test here. Some people see life on earth and see God. Others see the faintest exploration of the design space, an impoverished code base that made it impossibly far. A miracle, perhaps, but not what we'd see in a billion runs of the simulation.

Same with Lisp macros. Their few variants look bolted on. We haven't begun to explore the design space, yet the best macro systems in other languages are copies of what lisp has figured out so far.

There's an 80:20 rule for language emergence. Ecosystem questions aside, a Turing-complete language needs to start by getting one thing right. APL leveraged multidimensional array handling into a general purpose language. Scripting languages gain much of their leverage from nested hash tables.

Concise versions of monadic parsing are exhilarating in their power and expressiveness. If a language was designed so parsing and manipulating itself was its sweet spot, generalizing this parsing to typed trees would be easy, and we'd invent many new programming paradigms. A general purpose language would follow.

Lisp, an implementation of the lambda calculus, is not this language. Lisp is a machine language precursor to this idea, with various macro systems bolted on.

Haskell, an implementation of typed category theory, is not this language either. At the expression level, Haskell is stuck at a few hard-wired pattern matching primitives. Haskell does not make the assumption that everyone has learned to compose arbitrary parsing operators.

Clojure?

Or a non-lisp language instead?

Also, quicklisp didn’t exist/wasn’t as widely used then: I’ve done all sorts of Lisp projects now and never had serious issues finding good libraries for standard web development tasks.

What do you mean by this ?

I don't think that the fundamental flaw with that essay is the arrogance so much as the assumption that "language power" lies on a continuum in the first place.

You are right, though, that the Lisp community read the essay and internalized that all other languages are Blub. In my opinion this led them to collectively dismiss, for far too long, Dictionary Literals in every dynamic language which has eaten Lisp's lunch in the marketplace in the last two decades. Objections were raised ("you need homoiconicity for macros!") and everyone assumed they were valid and stuck with Common Lisp's woeful hash table interface and the loop macro keywords, insisting all the while "oh, that's a DSL, you could implement that with Macros"[0].

And then Clojure implemented Map literals and - what do you know - Clojure still has Lisp Macros!

[0] Efforts in this direction thankfully forthcoming: https://github.com/inaimathi/clj

With regards to Steve's issues: ask yourself whether they apply to you.

    USER> (yason:parse "{\"null\" : null, \"false\" : false, \"empty\": []}"
                       :object-as :plist
                       :json-arrays-as-vectors t
                       :json-booleans-as-symbols t
                       :json-nulls-as-keyword t)
    ("null" :NULL "false" YASON:FALSE "empty" #())

All those options defaults to special (dynamically scoped) variables, so you don't have to pass them everytime.

Encoding prints to the standard output (you can redirect it to an http stream, if you want), so you don't see double-quotes being escaped, but the string is equivalent (modulo spaces):

    USER> (yason:encode-plist *)
    {"null":null,"false":false,"empty":[]}

See https://phmarek.github.io/yason/

That's his opinion. We have a lot of JSON libs, maybe too many. I use "jonathan" and i'm happy with it.

EDIT: He wrote: "JSON support in Common Lisp is a god damn mess. There are an absurd number of JSON libraries and I don't really like any of them."

He doesn't like any of them, but I do like more than one.

The point is complex configurations tend to grow into a poor programming language. They would be far better as a lisp DSL.

So I think GP is correct.

> - There is no built in map or reduce function. You're expected to use for loops everywhere because it is more explicit

Go is an imperative language, where no implicit magic happens on the background, like auto creation of resources on runtime, every sequence needs to be manually defined by the programmer. "With imperative code, you’re telling your program how to do something. And with declarative code, you’re telling your program what you want to do. - Tyler Mcginnis, React Fundamentals", depends on the programmer, but I like to be in control.

With Lisp, you can create a "Hello World" program in variety of multiple ways. Sure you can refactor it, starting with how to print the letter "H", throw UTF-16 support there as well. At the end of the day, you wasted precious time and resources printing "Hello World".

Doing things in variety does not mean value.

Doing it right the first time means value, now imagine if it's a team.

If you want a full blown Common Lisp experience, with a GUI based REPL, GUI debugger with edit-and-continue, and all the nice stuff you see from Xerox PARC, TI and Genera demos, they are the ones to get.

For builds and dependency management: Leiningen, boot or deps.edn

For the front-end (clojurescript): Shadow-cljs + reagent

For the backend (clojure): Nrepl and nrepl.cmdline, Ring, jetty + compojure for a REST API

Frontend and backend can share code with .cljc files that work on all clojure dialects. https://clojure.org/guides/reader_conditionals

Both nrepl and shadow-cljs support code reloading through the REPL connection.

You can compile to a jar file and deploy that, build a docker image, or compile to a native executable with graalvm, or deploy on Aws lambda with Cljs+Lambada. Lots of options.

I liked and admired Larry. I considered him a friend. Once I sat with Steve Jobs in my office at NeXT and argued about Larry's virtues. I took the pro-Larry position.

Your lunch was probably around the time I was working on that Lisp OS at Apple. That was Larry's idea, too.

If you don't hear from me, it's not because I don't want to talk with you; it's because I'm forgetful (one reason I like email better than synchronous calls. Inboxes remember things that I forget.)

Knowledge Graph Navigator sort of intersects with some of my running interests--particularly knowledge representation and frame stores.

Ralph used prefix notation, dylan infix notation. Here you can find an implementation of ralph:(2)

From (2): Ralph is a Lisp-1 dialect that compiles to JavaScript. It is heavily inspired by an early version of Dylan (also known as "Prefix Dylan"), as described in Dylan – An object-oriented dynamic language.

Also (3) is about a Lisp to Dylan translator. There is also norvig lisp to dylan translator cited in (3).

(1) https://en.wikipedia.org/wiki/History_of_the_Dylan_programmi...

(2) https://github.com/turbolent/ralph

(3) https://tim.pritlove.org/2003/11/10/converting-lisp-to-dylan...

The surface language was basically Scheme, with some special forms removed and others added or renamed. The type system was basically a simplified Common Lisp Object System; all values were instances of CLOS classes.

The compiler, runtime, and development environment were built on Macintosh Common Lisp. Ralph inherited MCL's design and aesthetics.

Like Common Lisp, it was designed for writing software by interacting with it and modifying it as it ran. That's the essential point.

The project I worked on, bauhaus, was running basically all the time we worked on it. We worked on it by interrogating and hot-modifying the running system, in the time-honored tradition of old-fashioned Lisp and Smalltalk systems.

Later Dylan was not like that. It evolved into just another batch-compiled application language. You edit some files. You batch-compile them. You run the resulting artifact for testing. Rinse and repeat.

That's how OpenDylan is today. That's why it lost me.

It's also what's wrong with some newer Lisps, from my point of view. They aren't designed for building programs by modifying them from inside while they run. They don't know how to handle existing data in the presence of redefined types. They don't provide interactive debuggers and inspectors that can be used to rummage through the memory of the running program, edit it while it runs, and conitnue execution.

Common Lisp provides these features, and has done for decades. Ralph provided them. Smalltalk does, too. If all the Common Lisp implementations in the world suddenly evaporated, I could get along fine with Smalltalk, after a brief period of adjustment. It's probably purely an accident of history that I'm a Lisper rather than a Smalltalker, anyway.

But Dylan doesn't have those essential features anymore, and nothing that lacks them is likely to win me over--not OpenDylan, not Julia, not Clojure or Haskell, or F#. I like all of those languages, but not nearly as much as I like my livecoding.

I'd probably use SBCL or CCL for everything, if Lispwork' CAPI or something equivalent worked on them. I do use them when I don't need to build a GUI that I can easily port among platforms.

When I wrote a WYSIWIG text editor years ago, I did it with CCL because it was for my own use, and I didn't need it to run on platforms other than macOS. If I wrote a new version of it, I'd try to find a way to make it work across Windows and Linux, as well. (I can't use Lispworks for that because it's violates their license restrictions on distributing something that can be used as a Lisp development environment.)

I use other languages when I'm paid to, or when I want to do something that is a lot easier to do in another language. For example, I recently wrote a prototype of a web-based collaborative editor and publishing platform for shared documents. I chose Couchbase for storage, because it solves the sync problem reasonably well, and I used Clojure and Clojurescript with React and Reframe, because it worked well with the Couchbase Java SDK.

I've been paid to build prototypes, apps, tools, and system software with Lisp, Icon, ML, C, C++, Objective-C, Java, Python, Swift, Prolog, Haskell, Scheme, and other things. If I had a modern version of Ralph, I'd most likely use that. Failing that, Common Lisp is what I like best.

To be expected, I suppose. It really was my favorite working language ever.