Hacker News Reader

Comment by jksmith | Hacker News Reader

Now that I'm out of the corporate tyranny and have my own company, I use lisp for everything. There's certain satisfaction in writing config files and persisting data directly in s-expressions. Any json requirements are triggered by exports to foreign systems.

View on HN

That JSON prohibits trailing commata makes it an absolute pain to work with in practice.

I also like how in Haskell:

   something =
     { element
     , element1
     , element2
     , element3
     }

Is an actually idiomatic way to deal with the lack of trailing commata.

I did something like that in C++ circa 1998, before seeing it anywhere else:

  MyClass::MyClass(foo bar, int arg1, int arg2)
  : Base(bar)
  , member1(arg1)
  , member2(arg2)
  {
  }

You see that style in SQL too.

Commata?

Not really? A linter/formatter takes care of it.

Welcome to https://jsonc.org

Which Lisp, out of interest?

Does it really matter? There's a point in every Lisper's life, a threshold after which the question becomes immaterial - you'd stop thinking about intricacies of whatever Lisp and focus on the platform specifics instead. Any given day I might program in three-four different Lisp dialects, e.g. Clojure/Clourescript, Fennel, Elisp, Janet, etc. and it practically feels like I'm using the same PL. While switching between TS and JS (same family) never feels even close - there's always some mental burden.

> Does it really matter?

not philosophically, but certainly practically. To double down, if all lisps are roughly equivalent from a language POV, then you'd want to pick the one or two that will give you the most practical advantage (libraries, documentation, dev environment, etc.)

I don't want to be a gatekeeper, but Clojure, Janet and similars doesn't even have cons cells; that's hardly 'the same programming language'.

I would call these different dialects of Lisp. The data doesn’t have to be a function. It’s illustrative. The patterns of application still work. What’s the difference if delimiters are different or if you are calling JVM libraries? The high-level ideas are still right there. Consider JavaScript. It is definitely not a Lisp, but if you model it as Lisp in C’s clothes, then all of a sudden IIFEs make total sense. The point is that it’s a helpful mental model for languages other than Lisp.

Is the lack of cons cells a significant limitation?

Limitation is the wrong way to think about things when computational equivalence is in play. It's about mental foundation. Lisp at its core is like driving a Turing machine, Clojure is not.

If the difference didn't matter, we wouldn't have so many different lisps. Obviously the difference mattered enough to the people that created Common Lisp when Scheme already existed. Rich Hickey thought it mattered when he created a completely new Lisp instead of just porting Scheme to the JVM.

> If the difference didn't matter, we wouldn't have so many different lisps

Literally the opposite. We can make and use so many, because writing them is more or less the same. We can quickly throw together a new lisp for a new platform or such and use it without problem.

Why is it necessary to throw together a new lisp and not just use an existing one?

Technically when you write in the domain, you are effectively making your own Lisp and then using it. It’s one of the amazing things that macros can do.

Even the Lisps have Lisps. Like Clojure with ClojureScript, CLR, ClojureDart, Jank... etc.

Yes though they're trying to be effectively the same lisp

I do love that I learnt Clojure once like 5-7 years ago and more and more dialects keep expanding the choice of runtime I can target

It's the mustard seed that keeps growing! And without the fragmentation other PL's suffer from, which are reminiscent of the Tower of Babel, conversely.

I use the Franz Allegro toolchain exclusively.

Reply on news.ycombinator.com