[HN Gopher] Embracing Common Lisp in the modern world
___________________________________________________________________
Embracing Common Lisp in the modern world
Author : joaogui1
Score : 120 points
Date : 2024-01-24 15:27 UTC (7 hours ago)
(HTM) web link (www.juxt.pro)
(TXT) w3m dump (www.juxt.pro)
| reikonomusha wrote:
| Common Lisp has bad marketing (even OCaml has Twitch streamers
| and "influencers" now), and bad support for general editors, both
| of which make it a non-starter for most curious people who have
| an afternoon to try something. But behind all that is magnificent
| activity for those who got over the initial potential energy
| barrier. Just to give some examples:
|
| 1. SBCL, the most popular open source implementation of Lisp, is
| seeing potentially two new garbage collectors, one of which is
| merged and open to beta testing. One of them is a parallel
| collector written by a university student (!!) which blows my
| mind.
|
| 2. SBCL has better and better support for deploying Lisp as a
| C-compatible shared library, using SBCL-LIBRARIAN. It makes it
| play nicer with other applications in C and Python, without the
| baggage of process wrangling and thick RPC (IPC/servers,
| serialization, ...).
|
| 3. Coalton is another exciting development that allows a Haskell
| type system and "Lisp-1" functional programming in Common Lisp.
| That means type classes (or traits), something Lisp hasn't really
| had a proper notion of, and full type inference. Persistent
| sequences based off of RRB-trees were recently merged [1], and
| interestingly, they're implemented purely in Coalton [2]. That
| means Clojure-like seqs.
|
| It's interesting to see _users_ of Lisp generating the above
| ideas and libraries, not a special in-group of committees,
| "official" developers, etc.
|
| [1] https://coalton-lang.github.io/reference/#seq-type
|
| [2] https://github.com/coalton-
| lang/coalton/blob/main/library/se...
| posix_monad wrote:
| Isn't Clojure the most mainstream Lisp at this point?
| reikonomusha wrote:
| I'd say so, but for many, it's "dead on arrival" for a
| variety of reasons: Java-centric, unabashedly dynamically
| typed (favoring instead a slightly more eccentric way of
| enforcing contracts), etc. Unfortunately, a lot of Scheme and
| Common Lisp people don't like Clojure a whole lot because it
| gave up on a variety of things that group has treasured.
| 7thaccount wrote:
| It also assumes significant Java knowledge, so I kept
| finding myself at a dead end where it assumes I know the
| Java library way to do something and can just call it. I
| tried Clojure for the Brave and True and Living Clojure. I
| kept thinking that I wasn't getting anything I couldn't
| already do in Python (at least for my uses), but there's a
| lot of baggage like emacs + cider...etc.
| ryanobjc wrote:
| The gap between the clojure libs and the java libs and
| actually calling java is a jarring experience and really
| isn't a plus. While in theory the java interop is a
| selling point, if you don't need that it ends up being
| extra syntactical complexity.
|
| Now I haven't coded extensively in clojure, so a lot of
| it stylistic unfamiliarity. It does hold back people from
| adopting clojure.
|
| One reason why I'm excited never to use the JVM again is
| the huge memory footprint it uses. The best practices for
| production java is to figure out how much ram your
| process will need max under normal (not leaking) usage...
| and set both max and min ram to that (Xmx and Xms). It's
| a real hog on ram, and when running under clustered tools
| like k8 with can do memory overcommits it really reduces
| your flexibilty.
|
| I'm super psyched for all these tiny go and rust programs
| that run and use like 50 mb ram or even less. Running a
| cluster of 50 containers is really no heavier than a
| single Xmx1g java process!
| koito17 wrote:
| > It also assumes significant Java knowledge
|
| For interop? Yes. For debugging a JVM in production?
| That, too. But the same can be said about ClojureScript
| and ${JAVASCRIPT_HOST}.
|
| I picked up Clojure after a few years of using Common
| Lisp. Everything I know about Java and the JVM is thanks
| to using Clojure and deciding to make use of Java
| libraries when the ecosystem lacks a good library for
| something I need (e.g. WebAuthn).
|
| My complaints about Clojure usually boil down to lack of
| performance (when writing idiomatic Clojure as opposed to
| "Clo-java") and lack of static typing (most Common Lisp
| compilers do a way better job here). Although I complain
| a lot about performance, it's ironic many Clojure users
| will point out to me that Clojure is still faster than
| Python, Ruby, etc., because I never use those languages
| and beating them in performance IMO is a very low bar to
| clear, unless you consider alternative implementations
| like Truffle Ruby (but then most of the Python/Ruby/etc.
| ecosystem is incompatible with your implementation).
|
| With that said, Clojure is the only language I know with
| something like clojure.spec out of the box, and every
| time I use other languages, I miss being able to treat
| schemas as data and run transformations on them,
| especially when dealing with data that has a lot of
| optional fields (but they are optional only subject to
| specific conditions). Avoids a lot of repeated subtypes
| and keeps code concise. I also have an easier time
| testing Clojure code compared to other languages, in the
| sense that I rarely have to maintain intricate
| hierarchies of mock objects and state. Most of my Clojure
| code tends to be small, pure functions, and stateful
| things happen at the boundary between e.g. backend and
| database. So the most complex fixtures I usually have to
| write is setting up a database.
|
| > there's a lot of baggage like emacs + cider...etc.
|
| I think you were trying to use Clojure in its very early
| days, when people were still hacking atop of inferior-
| lisp-mode in order to provide basic Emacs support. While
| Emacs is still the majority of editor usage in Clojure,
| the next significant chunk is VS Code users with the
| Calva plugin. There is also an IntelliJ plugin and it
| offers (IMO) the best experience for Java interop.
| lemming wrote:
| (disclaimer: I develop Cursive, the IntelliJ option for
| Clojure).
|
| In the recent 2023 survey, Cursive and Calva are pretty
| much neck and neck, and between them just edge out Emacs.
| So it's pretty much an even split these days between
| Emacs and more "modern" options.
|
| https://www.surveymonkey.com/stories/SM-_2BH3b49f_2FXEkUl
| rb_...
| rpeden wrote:
| It assumes knowledge of the host platform, which isn't
| necessarily the JVM.
|
| I've been working on a library that targets the JVM,
| JS/TS, and the .NET CLR. Clojure has let me share about
| 85% of the code across the three, though to your point
| the remaining 15% required quite a bit of platform
| specific knowledge. I'm fortunate to have worked with all
| the over the years, so Clojure has been a nice power tool
| that has let me accomplish a lot while working solo. It's
| not the right tool for every person or every project,
| though.
|
| Since you've worked with Python, you might enjoy
| Basilisp. It is essentially Clojure with Python as the
| host platform.
| nescioquid wrote:
| My chief recollection of the Clojure mailing list was
| countless explanations of what a stack trace is to
| countless people who had never worked with Java and who
| had no interest in learning about Java.
|
| That was also around the time people had started hyping
| the JVM as a general language host. Seeing how people
| struggled on the Clojure mailing list made me rethink
| that proposition.
| sesm wrote:
| "Clojure is the gutted and zombie-reanimated corpse of a
| dream" (:
| uxcolumbo wrote:
| Why so?
|
| And where is this quote from?
| sesm wrote:
| The quote is from an old blog post: http://www.loper-
| os.org/?p=42#:~:text=Clojure%20is%20the%20g....
|
| The blog post itself is not very informative, but the
| quote is poetic, memorable and perfectly captures the
| sentiment of some Common Lisp enthusiasts towards
| Clojure.
| beders wrote:
| This is only partial true nowadays.
|
| There are at least 4 different options for Clojure fans
| that dislike Java. BB, ClojureScript in node and browser,
| ClojureCLR (.NET), ClojurERL. (and a few more).
|
| If you love static types, use TypedClojure.
|
| It is like many things in Clojure a la carte.
| natrys wrote:
| You have to define mainstream, and it's hard to quantify
| things when there is no data. If you use statistics from
| Github[1], there is a strong argument to be made that the
| most mainstream Lisp is actually .... Emacs Lisp.
|
| [1] https://madnight.github.io/githut/#/pushes/2023/4
| aidenn0 wrote:
| That's going to be biased a bit by people putting their
| dotfiles in github.
|
| It shows Clojure with 4x the share of CL though. Lisp-1's
| hurt my brain though, so I haven't dabbled in it much.
| koito17 wrote:
| > Lisp-1's hurt my brain though
|
| No worries! (defn cl-funcall [function &
| args] (apply function args))
|
| Jokes aside, I've written a significant amount of
| software in Common Lisp and Clojure. The Lisp-1 vs Lisp-2
| distinction isn't something that bothers me. It used to,
| as a beginner with strong opinions on everything. But
| nowadays? I don't even remember the last time I've heard
| Lisp-n before reading this comment.
| aidenn0 wrote:
| I'm just too used to naming variables things like "list"
|
| Having variables that shadow functions, that are later
| used somewhere causes rather inscrutable jvm backtraces
| to appear in Clojure.
| koito17 wrote:
| If you use the CIDER debugger then this doesn't appear to
| be a big issue. Try step debugging the following
| function. I get an IFn related exception right as the
| call to (list name) is made. (defn f
| [name list] #dbg (concat list (list
| name))) (f 'alice '(bob))
| natrys wrote:
| That's true, although my 10k loc elisp config will be the
| last thing I will ever put on Github. Way too personal ;)
|
| Incidentally elisp does a lot better in new Issue count
| too, although clojure narrowly beats it PR count. On the
| whole though, I think if you define mainstream to be
| _number of people_ using it, then elisp probably edges
| clojure.
| behnamoh wrote:
| > Isn't Clojure the most mainstream Lisp at this point?
|
| Calling Clojure a Lisp triggers some people.
| vindarel wrote:
| > bad support for general editors
|
| side note: only two years ago we were complaining about the
| _lack_ of support for VSCode or the Jetbrains suite, now we
| have working plugins for them:
| https://lispcookbook.github.io/cl-cookbook/editor-support.ht...
| in addition of Emacs, Vim, Atom/Pulsar (very decent support),
| Jupyter notebooks, Sublime, Eclipse (simple support), Geany,
| enhanced terminal REPLs, Lem (multi-language editor built in
| CL)...
| aidenn0 wrote:
| > Geany
|
| I wrote that support mostly over a weekend, and judging by
| the lack of bug reports, either my code is flawless
| (doubtful) or nobody uses it.
| reikonomusha wrote:
| People like to cite supposed VS Code support. I tried it.
| It's buggy and easy to make crash/spin/not respond/etc. even
| under casual use. Like... single Lisp file development. This
| is not to mention the absence of necessities such as correct
| indentation and paredit-like support. The latter we can get
| by without, but the former has worked in other editors for
| 30+ years.
|
| Don't get me wrong, it's a _great_ start, and I hope it gets
| polished. But as of 3 months ago, it still doesn 't work
| well, so much so I'd never actually recommend it seriously to
| someone who wants to learn Lisp.
|
| Have you tried using VS Code (or any other editor you
| mentioned) for any "serious" full-cycle Lisp development
| before, and do you believe it passes the minimum bar of
| stable and recommendable to another professional programmer
| or enthusiastic hobbyist? Do I need to try again?
| vindarel wrote:
| +1. No, VS Code is an unusable resource hog for me, I don't
| think you would gain sthg in trying the plugin again, the
| last releases were not full of changes.
|
| Lem is remarkably featureful and usable for CL development
| though! Both its ncurses and SDL2 frontends. I only miss a
| couple keys from Slime: C-c C-y (print the function the
| cursor is on to the REPL), C-c ~ (sync the REPL with the
| current package (namespace)), then a better imenu, and
| that's it. Simple git support is available for power users
| too 8-)
| reikonomusha wrote:
| Lem is cool! But doesn't address what I consider a
| fundamental problem for Common Lisp adoption: lack of no-
| nonsense support for a familiar IDE. Lem feels like an
| Emacs, so the same people that won't use Emacs also won't
| use Lem... which is a _lot_ of potential users.
| jonathankoren wrote:
| I've tried SBCL in Atom/Pulsar and Emacs. I found the
| debugger confusing as hell. The whole thing felt super janky
| compared to a properly integrated debugger.
|
| What I want -- what I really really want -- is an Allegro CL
| experience. Unfortunately, nothing provides it, nor does it
| look like anyone has any interest in providing such an
| experience.
|
| This isn't just a CL problem. Janky debugger integration is
| widespread. It's the pathetic that only commercial developers
| provide a polished debugging experience. Everyone else is
| satisfied with a basically a CLI tool running separately in a
| window. That's like. 80% solution. We can do better. We
| _should_ do better.
| pasc1878 wrote:
| There is an exception to only commercial developers provide
| a polished debugging environment and that is the various
| non GNU open source Smalltalks.
|
| Eclipse can also produce reasonable debugging for Java at
| least.
|
| But yes other than that poor debuggers do limit the choice
| of languages.
|
| Unfortunately PHP is better served than most interesting
| languages.
| fuzztester wrote:
| interesting that you say this. have you also tried out
| Franz Lisp? it is another commercial one.
| jonathankoren wrote:
| Franz was too expensive :) Allegro had an academic
| license.
| vindarel wrote:
| Do you say so for Emacs and Slime's debugger too? It's
| certainly weird at first, but powerful and integrated.
| Although it isn't graphical like LispWorks' (and probably
| Allegro's), so I agree it could be even better. (for
| readers: Slime's debugger is _not_ a separate CLI tool
| running in a window)
|
| (ps: see slime-breakpoints for a nice graphical addition:
| https://github.com/mmontone/slime-breakpoints)
| macmac wrote:
| I don't understand this. Are you saying that SLIME/SLY
| debugging of SBCL in Emacs is "basically a CLI tool running
| separately in a window"? It is arguably the most powerful
| debugging experience available for any programming
| language. There is ton of documentation and tutorials
| available and it is far from janky as you can possibly get.
| Buttons840 wrote:
| What's good about the new garbage collectors? You've only said
| they're new, but what makes them better? How do they compare to
| other languages?
| hayley-patton wrote:
| One is parallel, using multiple cores to make collection
| happen faster, which increases GC throughput and shortens GC
| pauses. The other is concurrent and avoids pauses entirely,
| though it requires more bookkeeping from the application and
| might reduce throughput.
|
| I joke that the parallel GC is bringing SBCL to 2000s Java.
| It seems comparable enough to Java's Parallel, though SBCL
| aims for less space overhead by default, so you need to
| adjust either GC to have a fair comparison. The concurrent
| one is based off a collector for SML#, Haskell has a similar
| low latency "Alligator" collector too.
|
| (Disclaimer: I wrote the parallel collector, and I want to be
| clear that latency and throughput differ here, because
| someone didn't before.)
| medo-bear wrote:
| I think common lispers should just accept that they are lone
| wolf programmers and get on with our lonely lives. Jokes
| asside, I dont think energy should be spent on editor support.
| Too much work and little to gain. Instead what needs to be done
| is to study the so many great libraries and writing the damn
| documentation (and make it fun). Documentation problem is THE
| low hanging fruit toward improving the cl ecosystem and
| attracting new loners. I think once people get the confidence
| to read and write lisp codebases are much easier to digest than
| other languages. Which I think is partly responsible for the
| crap doc situation. But if you think about it this also makes
| lisp in some sense the perfect open source language.
|
| Kudos to things like the cookbook tho !
| tmtvl wrote:
| Oh man, look up switch in the Alexandria docs, I really need
| to sit down and fix that.
|
| The documentation culture is the one thing I miss from Perl
| when I go to... well, any other language. Considering CL has
| DESCRIBE it's really something we need to get serious about.
| tnecniv wrote:
| I used to hang out in an IRC channel, and the big CL
| proponent there was a Norwegian that would disappear for long
| periods and go boat / hang out in the woods on his own.
| Apparently those are common hobbies in Scandinavia but it
| also makes a lot of sense for a CL lover in hindsight.
| hayley-patton wrote:
| > One of them is a parallel collector written by a university
| student (!!) which blows my mind.
|
| I didn't let schooling interfere with my education.
| harperlee wrote:
| Interestingly it seems that there was no (extended?) mention of
| Common Lisp on the JVM: Armed Bear Common Lisp. It is not central
| to the argument, but if one were to decide to migrate from
| clojure to common lisp, I'd say that one low risk path would be
| to first validate that you are capable of working with common
| lisp, and only then start preparing to forego / replace all of
| your dependencies, which is one of the strong parts of clojure:
| the ability to leverage everything under the sun that exists in
| the java / jvm world.
| vindarel wrote:
| I also hear good things about LispWork's Java interop
| (commercial).
| aidenn0 wrote:
| Last time I looked into it, ABCL was less performant than more
| recent JVM hosted languages. I am far from a JVM expert, but I
| was told that this is due to most development work on ABCL
| predating JVM enhancements for dynamism.
|
| There is also FOIL, which runs JVM (or CLR) in a separate
| process and provides a bridge for calling into JVM from lisp.
| It was written by Rich Hickey (the future author of Clojure),
| who observed that the reflection overhead was similar in
| magnitude to the serialization overhead!
| whartung wrote:
| Is there a "Common Lisp Electron" thing floating around?
|
| The GUI situation of the free lisps is pretty much a non-started
| for anything portable, just curious if there's a project bundling
| Common Lisp with a browser window, like Rust Taurus.
|
| At this level, there's no reason to fret about download sizes
| anymore if you're comparing to something like Electron, so no
| real need to "shake the tree" or really limit the lisp image
| size. Modern lisps aren't that big compared to most anything else
| anyway.
| vindarel wrote:
| I am exploring this atm. Basically once you build your CL web
| app as one binary, containing the HTML and other static assets,
| it is straightforward to open it in an Electron window. So is
| it with Tauri, Neutralino or another webview. How to
| communicate between the CL app and Electron I didn't have a
| look yet.
| floren wrote:
| I just wish McCLIM was a little more... ready. I've had some
| success writing a McCLIM application that works on Linux, but
| they only support the X backend for now meaning anyone on
| Windows would have to install an X server. It's a fascinating
| way to write a GUI, though.
| rjsw wrote:
| One of the SBCL developers wrote a McCLIM backend that
| generated HTML, had been meaning to ask what state it was in.
| jinwoo68 wrote:
| See https://github.com/rabbibotton/clog.
| aidenn0 wrote:
| Ceramic does this: http://ceramic.github.io/
|
| [edit]
|
| Maybe not... see vindarel's reply
| vindarel wrote:
| Ceramic is a wrapper around simple commands and while I
| wished it worked, it's broken and unmaintained. One can get
| to a working state with a couple npm commands (npm init
| electron-app@latest my-app ; ... ; npm run make)
| KerrAvon wrote:
| Lisp should be able to do much better than Electron. It could
| support a really nice take on declarative UI like SwiftUI,
| where it's abstract enough to be platform native on multiple
| platforms, but allows for specialization where needed.
| dannyobrien wrote:
| It's not quite a match to what you're looking for, but I think
| Nyxt's long-term plan is to build something similar
| (essentially, be a Common Lisp environment for a browser window
| in the same way that Emacs is an lisp environment for a text
| editor).
|
| https://nyxt.atlas.engineer/
| behnamoh wrote:
| > our planet and the technology we use. By embracing Common Lisp
| over Clojure and the JVM, we're not only choosing a powerful
| programming language but also making a greener choice for the
| environment.
|
| Wait what?! When was the last time programmers chose a language
| because it was "green"? What does it even mean for a language to
| be "greener" than the others?
| packetlost wrote:
| Presumably execution efficiency, but tbh I don't think I've
| ever seen any compelling numbers. The inefficiencies from extra
| _human_ time would likely offset any potential gains from the
| pennies you 'd save on CPU costs.
| behnamoh wrote:
| > Presumably execution efficiency, ...
|
| Yeah, in that case Assembly/C is the greenest language but
| should we switch to them?
|
| > The inefficiencies from extra human time would likely
| offset any potential gains from the pennies you'd save on CPU
| costs.
|
| I'm not sure I follow what you mean here.
| kazinator wrote:
| > _Yeah, in that case Assembly /C is the greenest language
| but should we switch to them?_
|
| We've not switched _away_.
| packetlost wrote:
| The electricity gains to be had are likely very small.
| Minuscule, even. Humans are not ecologically neutral, we
| consume food that has environmental impacts. Depending on
| diet and other lifestyle (physical activity, for example)
| factor into a humans ecological impact. By _increasing_ the
| amount of time a human spends on something, you
| proportionally increase the ecological impact of the task
| the human is performing. The idea is that duplicating or
| redoing work _may_ be more costly in aggregate, but
| absolute terms to the environment than the small offset in
| energy to be had by making the code more efficient.
|
| The point isn't about the absolute numbers, it's just
| trying to illustrate that the numbers are so small that it
| might as well be a rounding error unless you're talking
| about industry or society-levels of impact, which Clojure
| does not really have.
| brabel wrote:
| > The electricity gains to be had are likely very small.
| Minuscule, even.
|
| That's just wrong. Electricity used by data centers today
| add up to the whole consumption of a largish country.
|
| If you can save even just 5% of that, it's an enormous
| difference. Companies like Google and Netflix spend
| millions to save much less than that in computing.
| graemep wrote:
| > Wait what?! When was the last time programmers chose a
| language because it was "green"? What does it even mean for a
| language to be "greener" than the others?
|
| It means more energy efficient.
|
| May be we should, at least for some things. For code that runs
| a very large number of times the energy savings will add up.
| Data centres do use a lot of energy. So do client machines in
| aggregate.
| nsm wrote:
| (I only read the pdf outline)
|
| As someone who is neither a Common Lisp nor a JVM programmer,
| I'm genuinely curious to hear from experts whether the old
| trope of "JVM is slow and bloated" is even remotely true any
| more. Based on hearsay, the JVM often competes in language
| performance closer to C++, and has probably the best garbage
| collectors in the world as well as the best developer and
| operational tooling. How much do other platform developers
| leave on the table by ignoring the JVM these days?
|
| As an aside, even the trope about us running out of energy, or
| energy usage directly corresponding to planetary destruction is
| becoming less and less true. With solar PVs and the sun, we
| truly do have a shot at a future with limitless energy and
| resources.
| brabel wrote:
| > Based on hearsay, the JVM often competes in language
| performance closer to C++, and has probably the best garbage
| collectors in the world as well as the best developer and
| operational tooling. How much do other platform developers
| leave on the table by ignoring the JVM these days?
|
| I am mostly a Java developer, but have had the opportunity to
| play with Common Lisp and many other languages.
|
| While it's true the JVM is very performant, its performance
| actually comes at a cost: it has a JIT, Garbage Collector, a
| whole lot of machinery for Threads/VirtualThreads, JMX etc.
| all of which comes at a cost... thanks to multicore
| processors and lots and lots of RAM being available, this
| translates in really fast performance for Java
| applications... so that cost may be advantageous to you.
|
| Common Lisp applications are much lighter than Java
| applications from what I've actually measured given its
| simpler model... it basically compiles Lisp code to machine
| code directly and then runs that (Java runs bytecode, and
| then at runtime the JIT selects which code to optimise, which
| continues to happen for the lifetime of the application). I
| would bet money on any application written in Common Lisp
| being significantly lighter, and hence "greener", than the
| equivalent Java application, while still running at nearly
| the same speed, or even faster.
|
| For short running programs, Common Lisp is incredibly fast at
| starting up and getting stuff done - it competes with C and
| Rust in that regard, not with Java.
|
| > How much do other platform developers leave on the table by
| ignoring the JVM these days?
|
| Common Lisp tooling is integrated into the language itself.
| You can inspect the machine code it generates, ask it to
| instrument every function so you can profile, and so on
| without even needing any external tools - it's all built-
| in... but of course, using it from SLIME or SLY (in emacs)
| makes it a lot more pleasant. If you think Java tools are
| better, I believe you may not know Common Lisp very well.
| tmtvl wrote:
| As someone who has done a bit of both Java and CL (and Perl,
| and C, and Free Pascal, and Guile Scheme, and Raku, and... oh
| my, where does the time go?) Java is entirely fine. A bit
| heavy on the ol' RAM, and if you really want to get it fast
| you need to know which knobs to push and which settings to
| turn various dials to, but it's fine. I haven't tried that
| new Graal VM thing, hearsay is that it makes Java run real
| good, but with plain old OpenJDK it's fine.
| packetlost wrote:
| To me, the most compelling aspect of Clojure is it's very well
| designed standard library and ecosystem access via Java. Pretty
| much everything else is a negative.
|
| Even then, the ecosystem is a Faustian bargain.
| wk_end wrote:
| Can you elaborate? As an outsider, most of the time I hear
| people say some variation on "Clojure would be great but I stay
| away because of Java".
| shrimp_emoji wrote:
| That was what drove me away.
|
| The bloat of the JVM, and the implication of Java down the
| road, made me nauseous.
| uticus wrote:
| Time to again link to "The Rise and Fall of Lisp at the Jet
| Propulsion Lab" (2002)
|
| https://flownet.com/gat/jpl-lisp.html
| onyno wrote:
| Lisp Flavoured Erlang (lfe.io) needs more love, from what I've
| seen and tried with it - it could give clojure a run for its
| money.
| uxcolumbo wrote:
| How so? Can you share more details?
| gibsonf1 wrote:
| Our TrinPod Server with conceptual AI and space-time digital twin
| is all in Common Lisp (and incredibly easy to work with and
| evolve): https://graphmetrix.com/
|
| I'm not sure if the recursive hierarchical conceptual inference
| as well as many other things would have been possible without
| Common Lisp.
___________________________________________________________________
(page generated 2024-01-24 23:00 UTC)