Hacker News Reader

Comment by jmercouris | Hacker News Reader

I'm using Lisp in production, our browser and all of our infrastructure is in Lisp https://github.com/atlas-engineer/next.

TO address some of your points;

poor ecosystem of libraries: many great libraries, some incomplete. you must not be afraid to look at the source code to understand and edit

poor community coordination: true, there are few large scale community lisp projects. be the change you want to see

dependency limitations with quicklisp: like what? quicklisp works great. if you are talking about loading several versions of the same library at the same time in a single image, this is being researched and developed

poor support for json: no, there is good support

have to restart the server every 20 days: not familiar, I have had lisp servers running for years now

hack to tune GC: no

if I had to redo my project would I choose Lisp? I would choose lisp, yes. there is no more powerful language than this, and believe me, I have tried many

View on HN

The post [1] (though old) - hints at no good libs for json (mentions a workaround for one he picks)

  > For me, the most important quality 
  I need in a JSON library is an unambiguous, 
  one-to-one mapping of types. For example: some libraries 
  will deserialize JSON arrays as Lisp lists, 
  and JSON true/false as t/nil. But this means [] and false
  both deserialize to nil, so you can't reliably round trip anything!

Although this post is from 2018, wondering if it has improved since then.

[1] https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#s4...

I've been using `jsown` for all my Common Lisp JSON needs. There are more JSON libraries and I think JSON support for Common Lisp is good, not perfect, but no worse than most other popular languages.

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

This just works:

    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" #())

Null is mapped to the :null keyword, false to a symbol named false in the yason package, and the empty vector to an empty lisp vector (in Lisp #(1 2 3) denotes a vector, whereas (1 2 3) is a linked-list). All threes can be distguinshed from the others.

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":[]}

The defaults in Yason just returns list for vectors, and map both null and false to nil, but this is not a problem: if you expect your field "items" to be a vector, then nil will denote the empty list, if you expect another field "enable-debug" to be a boolean, nil be good enough too. But in cases where you need to handle them differently, the library can help you distinguish among all kinds of value.

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

That part of the post was wrong even in 2018. There were two libraries that had a one to one mapping out-of-the-box, and at least two others that could be configured to work that way.

>The post [1] (though old) - hints at no good libs for json

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.

Have you tried Haskell? What was your experience?

I've tried Haskell, my experience was mostly that of confusion :-)

Reply on news.ycombinator.com