[reikonomusha]

I'm as big of a Lisp fan as can be. I'm a proud owner of Symbolics and TI hardware: a MicroExplorer, a MacIvory, two 3650, and two 3620. Not to mention an AlphaServer running OpenGenera.

Today, we have computers that run Lisp orders of magnitude faster than any of those Lisp machines. And we have about 3–4 orders of magnitude more memory with 64-bits of integer and floating point goodness. And Lisp is touted to have remained one of the most powerful programming languages (I think it's true, but don't read into it too much).

Yet, it appears the median and mean Lisp programmer is producing Yet Another (TM) test framework, anaphoric macro library, utility library, syntactic quirk, or half-baked binding library to scratch an itch. Our Lisp programming environments are less than what they were in the 80s because everybody feels the current situation with SLIME and Emacs is good enough.

We don't "need" Lisp machines. We "need" Lisp software. What made a Lisp machines extraordinary wasn't the hardware, it was the software. Nothing today is impeding one from writing such software, except time, energy, interest, willpower, and/or money.

Don't get me wrong, there are some Lisp programmers today developing superlative libraries and applications [1], but the Lisp population is thin on them. I'd guess that the number of publicly known, interesting (by some metric), and maintained applications or libraries that have sprung up in the past decade probably fits on one side of a 3"x5" index card. [2]

Though I won't accuse the article's author of such, sometimes, I find, in a strange way, that pining for the Lisp machines of yore is actually a sort of mental gymnastic to absolve one for not having written anything interesting in Lisp, and to excuse one from ever being able to do so.

[1] Just to cherry-pick a recent example, Kandria is a neat platformer developed entirely in Common Lisp by an indie game studio, with a demo shipping on Steam: https://store.steampowered.com/app/1261430/Kandria/

[2] This doesn't mean there aren't enough foundational libraries, or "batteries", in Lisp. Though imperfect, this is by and large not an issue in 2022.

[zozbot234]

> We don't "need" Lisp machines. We "need" Lisp software. What made a Lisp machines extraordinary wasn't the hardware, it was the software. Nothing today is impeding one from writing such software, except time, energy, willpower, and/or money.

Discussed here https://news.ycombinator.com/item?id=30800520 The main issue is that Lisp, for all its inherent "power", has very limited tools for enforcing modularity boundaries in code and "programming in the large". So everything ends up being a bespoke solo-programmer project, there is no real shared development. You can see the modern GC-based/"managed" languages, perhaps most notably with Java, as Lisps that avoided this significant pitfall. This might explain much of their ongoing success.

[reikonomusha]

I think many people have conjectures, such as this one, but I don't think it's a tech problem, or a "Lisp is too powerful for its own good" problem. It's a "people aren't writing software" problem. History has demonstrated umpteen times that developing large, sophisticated, maintained, and maintainable projects in Lisp is entirely and demonstrably possible. Modern Common Lisp coding practices gravitate toward modular, reusable libraries through proper modules via ASDF packages ("systems") and Common Lisp namespaces ("packages").

[SulphurCrested]

The obvious answer as to why people aren't writing software is that almost all of the people able to write good software don't like the language and are writing software in some other language or for some other platform.

I know Lisp enough to have written programs of a few thousand lines in it. I'm not even slightly fazed by functional programming and (tail-)recursion instead of loops. I've read Steele's Common Lisp book from cover to cover. Someone even tried to get me to interview for a job writing Lisp (I politely told them I thought their system could not practically be implemented in Lisp and was, several years and tens of millions of dollars later, eventually proven right).

And I don't think the language has any redeeming features other than garbage collection and documentation, neither of which is notable in 2022. I'm someone familiar with the language who could quickly become productive in any decent Lisp, and that's what I think of Lisp. Can you imagine what a person new to the forest of parentheses, weird identifiers and rejection of 500 years of operator precedence notation thinks?

[drekipus]

> I politely told them I thought their system could not practically be implemented in Lisp.

I'm curious to what that was, it sounds like a challenge more than anything.

I'm off a younger generation of programmers, and I've recently found lisp after coming from python. I still adore python and I can understand python's success, but I also adore lisp and its syntax, and I feel like I get the "powerful" argument for it.

For me, for what it's worth, I think the difficulties for lisp to join mainstream is really the thousands of little differences and gotchas that there's no single standard body looking after the users of the language. Princ instead of print, mapcars everywhere, etc. Trivial examples sure, but there's a lot that prevented me from making a few programs without doing through a book.

I'm not saying it's wrong, or it should be such and such a way. I am just simply comparing it to python and pointing to the first big elephant I come across.

Fwiw I also think that clojure is a lang that is capable of capturing more love because it's capable of tying in with Java ecosystem.. but it java is old and slow*; jobs in Java are slowing down, and clojure isn't filling in the gap, kotlin might be.

I take common lisp with me to holidays, because I like to learn it and all the funny words for things, but by far the lisp I use the most in day to day stuff is fennel, which is a lisp that compiles to Lua, and allows me to write plugins for neovim as well as a few other things that uses Lua.

TLDR: yes lisp needs software to be popular but it's not just a case of "make more applications" nor is the problem parents or operator precedence. People like sensibly named keywords.

I personally think things would be a little better if there was a CL to JavaScript transpilier, then you'd start to get some of the js crowd, same with python.

[taneq]

> History has demonstrated umpteen times that developing large, sophisticated, maintained, and maintainable projects in Lisp is entirely and demonstrably possible.

The thing is, developing maintained, maintainable projects is work, and everything I see about Lisp seems to have an undertone of being done, to some degree, for fun. It’s a language that scratches a specific itch; people feel clever about writing elegant code in it.

But the sad truth is that 99% of real application code doesn’t need to be clever or elegant. It needs to be simple and cheap and maintainable by anyone.

[sterlind]

the 1% is extremely important though, and the tools for it look very different.

I do algorithm design, a lot of which is seeing what's possible/feasible before committing. I prototyped a classical AI planning system for orchestrating maintenance. there's no battle-tested standard library to reach for here. I needed prolog, I chose picat because it had a good planning engine.

before this, I worked on an NP-hard graph problem that involved tons of topological transformations for heuristics. I wrote the damn thing in C#. it was a nightmare. it's so hard to iterate and experiment in a language like that. even using something like Python/Jupyter, nested loops and horrible messes of bidirectional maps and indices bog you down. I should have done functional. nobody touched my code for two years because it was pure math. I think using C# made it much harder to understand - too much scaffolding obscured the semantics.

now I'm doing another NP-hard graph problem. this time I'm using MiniZinc. because it's concise, because it's powerful enough that I can at least figure out how to specify my problem and see where scale falls down.

so I'm in this position of using a menagerie of bizarre languages not because I'm a hipster obsessed with pretty code, but because my problem domains are really weird and maintainability doesn't matter when you're not sure if what your goal is even possible. something like Lisp - a lingua franca for weird DSLs - would be great, for my very niche use case.

[taneq]

Absolutely true, and it sounds like you're doing really interesting stuff where the language and the way it maps to the problem are more important than the factors I listed above.

Do you stick with the same (maybe-)esoteric language for the production implementation? And if so, does this then drag the rest of the production implementation into that language as well, or do you do the hard bit in one language and the routine stuff in another more common language?

[sterlind]

I do the hard bit in the esoteric language, then the glue in a traditional language. for instance, I made a tool that exhaustively steps an implementation through every possible state of a TLA+ model. I wrote "serializers" to parse TLA+ expressions into C# classes and vice-versa, and used this to build a bridge. Parser combinators work great for this stuff, though that's another reason I'd be happier with a Lisp representation for everything.

[coryrc]

> people aren't writing software

Maybe not OSS, but somebody is keeping Lispworks and Franz in business.

[copperx]

I'd love to know who. The example apps in Lispworks site aren't commercial successes, as far as I know.

[kristopolous]

Looks like it's just a small unit in an office park in the tech center in Cambridge: http://www.lispworks.com/contact.html

It doesn't really take many contracts to scrap together office park rent and a staff of a few people. We're talking like < $1 million/year in revenue.

Good on them. Not every company needs to try to be the next Amazon

[lispm]

Already in the 80s the Lisp Machine OS had > 1 MLOC code lines with support for programming in the large. The development environment was networked from the start. A server keeps the definition of things on the network: machines, users, file systems, networks, gateways, printers, databases, mailers, ... The source code and documentation is usually shared in the team and versioned via a common file server.

Nowadays, there are large applications written by groups/teams, which are worked on for three or more decades. For example the ACL2 theorem prover has its roots in the 70s and is used/maintained until today for users in the chip industry.

Common Lisp was especially designed for the development and production use of complex programs. The military at that time wanted to have a single Lisp dialect for those - often applications came with their own Lisp, which made deployment difficult. A standard language for projects was then required.

These were usually developed by teams in the range of 5 - 100 people. Larger teams are rare.

[zozbot234]

"Designed for complex programs in the 1980s" is not really up to current standards. Moore's law means that complexity of overall systems can grow by multiple orders of magnitude in the 01980 -to- 02022 timeframe.

[lispm]

That was not the point. Lisp applications were already a team sport back then. That all or even most Lisp software is written by single person teams is just wrong.

[zozbot234]

Modern agile development is far more complex than even that: you need entire loosely-coupled teams of developers to be able to seamlessly cooperate with one another, so there are multiple scales of cooperation. Tightening the semantics of interface boundaries is a necessary support for that kind of development and is what's largely meant today by programming "in the large". Highly dynamic "scripting" languages get in the way of this, and that's essentially what Lisp is too.

[lispm]

Lisp isn't essentially a scripting language. Common Lisp was designed as an application language, in rare case it's also a systems language. On a Lisp Machine, for example the whole networking stack was written in it.

[mvc]

Never heard of Javascript?

[throw10920]

> The main issue is that Lisp, for all its inherent "power", has very limited tools for enforcing modularity boundaries in code and "programming in the large"

I don't see any mention of "modular" or "boundaries" in the post you linked, so I'm assuming that it doesn't add extra context to your point.

You say "very limited tools for enforcing modularity boundaries", which I'm going to assume means that you believe that Lisps have constructs for creating modularity boundaries (e.g. unexported symbols in Common Lisp), and just don't enforce them (e.g. I can still use an unexported symbol in CL by writing foo::bar), in which case - I don't think that this is actually an issue.

Programmers are capable of doing all kinds of bad things with their code, and shooting themselves in the foot, yet I've never seen an indication that the ability to shoot yourself in the foot with a language noticeably contributes to its popularity (see: C, C++, Perl, Ruby).

Moreover, specializing to Common Lisp, it's not like CL allows you to accidentally access an unexported symbol in a package - you have to either deliberately use :: (which is bad style, and takes more effort than typing :) or you get a hard crash. This is opposed to the above listed languages, which allow you to shoot yourself in the foot in a large number of extremely diverse and interesting manners, often without giving you advance warning - and yet are still far more successful.

------------

I don't believe that the lack of success of Lisps are due to technical deficiencies.

[wvenable]

Lisp is clever and also a but inhumane. It only ever appeals to the small subset of the population that likes that. Lisp has some niceties that are fundamentally inherent to its design but it's just not enough to overcome how awful it is for people.

But this is not a technical deficiency of Lisp, it's more of a technical deficiency of humans.

[throw10920]

What? How is Lisp (either the family of design decisions or even a specific language/implementation) "inhumane"? What does that even mean?

[wvenable]

Inhumane is the wrong word; brutalist is a better word. Brutalist architecture is characterized by minimalist constructions that showcase the bare building materials and structural elements over decorative design. Human's are not logical/mathematical machines and all the irregular and decorative parts of programming languages are often for our benefit even if they're inconsistent, verbose, and limiting.

[_19qg]

That's not the experience a Lisp programmer has.

One is not looking at dead code, instead one is working with it interactively.

Lisp is not brutalist concrete, Lisp is wet clay in the programmer's hands.

The main way to program software in Lisp is extending it while it is running and with the development tools as much integrated as possible. Thus a Lisp program has maximum information about itself, there is no separate debug mode, no long build times, no static code.

[kazinator]

Lisps are fairly "decorative". It just doesn't combine a pin-striped blazer over a plaid shirt with leopard patterned pants, like many languages.

Here are some traditional notations found in Common Lisp:

  "string"
  symbol
  :keyword-sym
  #:gensym
  package:sym
  `(static content ,inserted ,@spliced)
  (l i s t)
  (im pro per li . st)
  #(v e c t o r)
  6.18e+23
  13/17
  ;; comment
  #*100111101101
  #1=(1 2 3 #1#) ;; circular structure
  #S(point :x 35 :y 44)

Various dialects have various notations. There is syntax highlighting support in editors, too.

Lisp is not just (this (and that)).

[throw10920]

> Brutalist architecture is characterized by minimalist constructions that showcase the bare building materials

This definitely doesn't describe the semantics of most Lisps, which operate at the higher levels of abstraction and conceal many implementation and hardware details from you by default.

It also doesn't describe the syntax of most Lisps, including all of the major ones. Common Lisp, in particular, has extensive syntactic sugar, as shown in kazinator's post.

> structural elements over decorative design

I mean, Lisps don't usually go out of their way to look "pretty", but neither do they actively attempt to look ugly. Most Lisps' syntax has had design effort put into it - the authors strive for consistency and ergonomics.

Taste is subjective, and I personally strongly prefer the syntax of Common Lisp to C or Python - both in terms of aesthetic appearance, and in terms of ergonomics.

Furthermore, very few programming languages (excluding most Lisps and all major languages) are intentionally designed to be "decorative". Whitespace, for instance, is added into languages for readability and parsing determinism, not beauty or decorative appeal.

I don't think that this metaphor is accurate at all. There are many criticisms that you can make of both the Lisp family and specifically of Common Lisp, but I don't think that "brutalist" is a valid one.

[johnny22]

What do you think it is?

[db48x]

Marketing. Too focused on AI, followed by more than a decade of breathless hype for C++ and Java.

[throw10920]

Nailed it. More generally: "non-technical cultural factors".

I would also add some minor incidental technical factors (e.g. early Lisp implementations were far less efficient than C implementation during the time when efficiency really mattered, and then cultural/marketing factors kept C as the dominant language far after the technical balance tilted in favor of Lisp).

[syngrog66]

agreed, and well said

in broadstrokes, imo, Lisp's endless plasticity of infinitely nested parentheses is both its greatest strength and... its greatest weakness

I love it at Write time. hate it at Read/Maintain time. why I've avoided it for serious work. Python, Java, Go Rust etc are all easier for my brain & eyes to quickly parse on the screen

which is unfortunate. because I still drool at Lisp's linguistic power

[reikonomusha]

Lisp at "read/maintain" time in a good environment is probably the most enjoyable time for me working with Lisp, assuming it's on a code base that followed some sort of coding standards. Introspection, debugging, and navigation in a Lisp environment are incredible.

[lanstin]

Still the average function written by a smart lisp programmer is going to make me sigh, take three deep breathes, and set aside some time to focus, while the average function by a smart Go programmer, I can just read.

This readability loss does counteract the ability to reload forms into a running core. Especially now when i am trying so hard to make everything running be immutable and derived from various git repos.

[throw10920]

I don't think this is a Lisp thing, though - you get this same problem with Haskell and C++ and Perl as well, because the cultures of all of those languages normalize and encourage writing clever, difficult-to-read code.

Similarly, if you're working by yourself, or in a team with shared norms, you care far less about average function written by a random smart Lisp/Haskell/C++/Perl programmer, and more about what (a) you/your team writes and (b) the ergonomics of the language itself.

In fact, I argue that Lisp is slightly better than the above languages because much of its fanciness comes from macros, which you can trivially expand inline to simplify the code - which you can't do with fancy category theory constructs in Haskell, and is only barely possible with boost:: templates in C++, for instance.

(that isn't to say that I disagree with your point "the average function written by a smart lisp programmer..." - I completely agree with your assessment, I just don't think it's either as big of a problem as it could be, nor is it unique to Lisps)

[Turing_Machine]

> . You can see the modern GC-based/"managed" languages, perhaps most notably with Java, as Lisps that avoided this significant pitfall.

An interesting perspective. From my POV, it's hard to think of a less Lisp-like language than Java. COBOL, maybe.

[metroholografix]

The greatness of Lisp -at least when it comes to end-user empowerment- and (I think) the only differentiating factor that most other languages have still not caught up to, is the cybernetic philosophy with its roots in Licklider (man-computer symbiosis) and Engelbart.

Building an environment that strongly and uncompromisingly expresses this philosophy at its core is a serious undertaking in terms of time investment. Emacs has been in continuous development for 37 years and while it is still not as good as Genera, it's certainly "good enough" for lots of people and definitely captures the spark of this philosophy.

In the Common Lisp world, we've had plenty of tries (MCL, Hemlock, McCLIM) but they've all failed to get people to coalesce and generate progresss.

Maybe the fact that Emacs exists is a curse in that people realize the barrier they'll have to clear to make something substantially better and decide to devote their energies into more easily realizable efforts.

[GregorMendel]

Anyone interested in the computing holes that can be filled by lisp machines should check out Urbit. There is an vibrant and growing community of people building a network of personal servers running a lisp-like functional OS. It uses an identity system secured by the Ethereum blockchain and it has created a bottom up economic incentive for developers to participate. They are starting to solve unique problems that couldn't be addressed on currently prevalent platforms. Urbit is an affirmation; we can ditch the nihilism.

[convolvatron]

i associate lisp machines with power, simplicity, and a delightfully shallow learning curve.

urbit to me is exactly the opposite

[Gollapalli]

And it's 4x more expensive than it was supposed to be to buy a planet.

Ethereum was a mistake.

[olah_1]

Since they moved to Layer 2 it has been amazing. No eth fees anymore.

They should just move to their own chain entirely. Maybe this is a baby step towards that. Each Galaxy/Star is already basically a staker in a Proof of Stake network.

[mvc]

Always be griftin

[olah_1]

if they were on their own POS chain, they wouldn’t need to charge anything. it is just in the galaxy/stars best interest to maintain the ledger of activity.

galaxies/stars can just charge for services provides like an ISP basically

[TacoT]

It's $3. www.azimuth.shop

[chevill]

>They are starting to solve unique problems that couldn't be addressed on currently prevalent platforms.

Got any examples?

[lonjil]

> Yet, it appears the median and mean Lisp programmer is producing Yet Another (TM) test framework, anaphoric macro library, utility library, syntactic quirk, or half-baked binding library to scratch an itch. Our Lisp programming environments are less than what they were in the 80s because everybody feels the current situation with SLIME and Emacs is good enough.

I don't think this is true. Not anywhere close. Most such examples are small, and probably only took a small number of hours to produce. While "superlative" stuff takes very many man hours to create. So just by seeing that there are many throwaway testing frameworks or whatever, you cannot tell where most of the work hours actually go. A half baked binding library takes 20 minutes to make, while a proper high quality rendering engine takes hundreds if not thousands of hours.

The Lisp population is thin on people making cool shit because the Lisp population in general is thin.

[agumonkey]

I'd say it's both. It seems most lisping is done high on the stack. Some are doing assembler level lisp (or scheme) but less bare metal / OS / system oriented lisp.

I wonder what the lisp os guy are thinking about OS / UI these days.

[13415]

Personally, I think the problem is that CommonLisp is just another programming language, whereas Lisp really shines when it provides a full-fledged programming environment. Nowadays, it would seem best to create such an environment on top of commodity hardware as a "virtual machine" that abstracts away from the hardware in a general, portable way. However, a good environment (1) needs a purpose, and (2) somebody needs to write it. Lisp currently fails on both points. The purpose used to be symbolic AI and NLP among other things. Nowadays it could be the same, or a web framework with integrated distributed computing and database, or scientific computing, or a server for certain business services, etc. There are many application domains for which a virtual "Lisp machine" would be beneficial but it needs to be developed for one of those real world applications, not just as a toy like existing attempts of building Lisp machines. And in my opinion the problem really is (2), developer power / size of the community. If you exclude super-expensive legacy Lisps, the current Lisp community doesn't even have a fully supported Lisp-native editor (portable Hemlock is not good enough) and also doesn't have good enough object persistence / native Lisp-based databases. Both are the foundations of any integrated Lisp machine.

People sometimes claim CL+Emacs+Slime provides the full interactive experience. I just can't agree with that at all. I have tried, and the experience was not substantially different from Go development and development in any other fast-compiling language with Emacs. In some respects, it's even worse than with various modern languages, even though most of those languages are strictly inferior to CL from a pure language perspective. If editing files in Emacs is all there is to the allegedly great Lisp experience, and developers at the same time have to deal with all those idiosyncrasies of CL such as CL's filesystem path handling, ASDF, and tons of poorly documented libraries, then I can't really see the advantages of CL. The language is powerful, don't get me wrong, but a truly interactive experience is totally different. Smalltalk managed to keep this experience but for some reason the Lisp community seems too have lost this vision. I guess the developer community is just not large enough.

Anyway, before someone tries to build another "close to metal" Lisp machine or tries to revive any old Lisp machine, I'd rather wish the community would focus on creating truly integrated development environments that abstract away from the host system and are fully hackable and editable from the ground up while maintaining security and multi-user access. A "virtual Lisp" machine with virtual OS, so to say. If that's developed for a certain purpose like building and deploying extremely portable web applications, I believe it can have a great future.

Sorry for the long rant. This is just my impression after having programmed in various Lisp dialects for the past three decades.

[coryrc]

> the experience was not substantially different from Go

I think the (a?) reason for that is a (otherwise good) shift to production being immutable. When you aren't allowed to interact and change code in a running system, you lose a massive advantage of CL over simpler languages. When the answer to every error is "send a 4xx or 5xx to the client" then having a powerful error-handling system is similarly pointless. When you only write CRUD programs like everyone else, you're just plugging together other's libraries and not creating novel techniques or fancy math. In this world all CL's advantages are negated.

[metroholografix]

Common Lisp on Emacs via SLIME is not competitive with Smalltalk, re: "interactive experience" since Emacs is not the native substrate of CL, but essentially an out-of-process experience. If you want to experience CL at its best, you need to run Symbolics Genera.

Emacs with Emacs Lisp on the other hand offers a great interactive experience that also manages to easily surpass every modern Smalltalk incarnation in practicality and size of development community. So if running Genera isn't easily doable, this will give you a taste of what Lisp interactivity is all about.

[thorondor83]

To me development with SLIME is much better than with a fast-compiling language.

- Debugger is always ON.

- I can inspect the data I'm working with.

- I can redefine things without starting everything all over, avoid losing current context. Fast restart is not the same.

- I can evaluate pieces of code without the need of a REPL. Point to an s-expression and evaluate that piece of code, inspect the result.

I don't see how Smalltalk is much more interactive. It is more powerful at graphics and tools integration, but SLIME provides an interactive enough experience IMO, and it is significantly better to any fast compiling + restart language.

[johnisgood]

I prefer Factor for that.

[jodrellblank]

> "We don't "need" Lisp machines. We "need" Lisp software."

Nobody goes into Java because their self identity is "a Java programmer" to gather a team of people to create a Java machine running Java software to unleash the power of Java for the masses by enabling them to do everything in Java for the sake of doing everything in Java, By Java, With Java, For Java. And if they do talk like that they would be a Sun Microsystems marketing pamphlet from 1999, or a joking reference to Zombo.com, or suspected of having zero interesting ideas and defaulting to Ouroboros-naval-gazing.

Adobe Photoshop Lightroom is C++ and Lua. Blender is C++ and Python. Excel is C++ and Visual Basic for Applications. LibreOffice Calc is C++ and Python. These are large, popular, programmable systems which exist today and are good enough; good enough for people to spend lots of money on them, good enough for people to spend years skilling up in them, good enough that once they existed people wanted them to keep existing and they haven't faded into the past.

The added allure of an imaginary rebuild of them like "if you took the lid off Excel you'd see VBA inside so you could rework the way it handles multiple sheets using only a skill you have and software design skills and Excel-internals knowledge you don't have" would get a hearty side-eye and slowly backing away from most Excel users. "Everything inside looks the same" is as attractive as "if you open your car trunk you'll see leather seats and plastic dashboard components making it move" or "if you sit in this car you're sitting on engine parts because the top priority is that a welder in a scrapyard can build the entire car without leaving their comfort zone". There are certainly people who want that, but the way the world hasn't developed that way suggests it isn't particularly desirable. Even when such things have been built, people can today use a Smalltalk, an APL, save their running work in a memory-dump and reload it and rewrite parts of it in itself, people flocked to Jupyter notebooks instead.

> "[1] Kandria is a neat platformer developed entirely in Common Lisp"

https://cdn.akamai.steamstatic.com/steam/apps/1261430/ss_a3f...

Without mocking a team who has built, developed, polished and planned to release a project, because that is respectable, it also looks like computer gaming of the early to mid 1990s Intel 386/486 era; remeniscent of Prince of Persia, Gods, Lemmings, Monkey Island. But it needs an Intel i5, 4GB RAM and 1GB storage. It's not even released yet and has no reviews, but you describe it as 'superlative' ("Of the highest order, quality, or degree; surpassing or superior to all others") - are you rating it so highly based on it being written in Lisp or what?

[reikonomusha]

I don't know how to respond to the whole "Lisp programmer identity" stuff; it doesn't seem relevant to anything I said. I also didn't suggest anybody rewrite anything in it. The success of Lisp doesn't depend on the existence of fancy machines, it depends on people choosing to write software in it. That's basically all I meant to say.

As for Kandria, did you play the demo, or did you just look at screenshots and system requirements and make your brazen judgment? I don't think Kandria is at all amateur or sloppy, regardless of to which aesthetic era you think it belongs. Many have claimed that it's not even possible to write a game that doesn't blow because Lisp is dynamically typed and garbage collected. Now the goalposts have moved to, "well, it takes 1GB of memory and doesn't even look like it's from 2022."

I commend anybody who ships.

[jodrellblank]

It's relevant in the sense of being a reply to "we need software written in Lisp" and how, if you substitute Java and say "we need software written in Java", people would just shrug and ask "why do we?". People are saying "we need sofware written in Rust" and other people are asking "why?" and one answer is "to avoid the memory and race condition problems we have from C and C++ code". Maybe correct or not, maybe compelling or not, but it's a practical, outward-looking concrete reason. The answer for Lisp from your comment is "The success of Lisp doesn't depend on the existence of fancy machines, it depends on people choosing to write software in it" and that's the kind of self-referential Ouroboros loop I mentioned. "OK but why?". The success of COBOL depends on people choosing to code in COBOL, but nobody uses that as a reason to support COBOL. People who identify as "Lisp programmers" are going to care about that because if it dies, their identity dies (which is daft because as you say, anyone can choose to write a LISP environment at any time).

> "Many have claimed that it's not even possible to write a game that doesn't blow because Lisp is dynamically typed and garbage collected. Now the goalposts have moved to, "well, it takes 1GB of memory and doesn't even look like it's from 2022.""

JavaScript appeared, took over the world, demonstrated good games in a dynamically typed and garbage collected language at least a decade ago. Goalposts move, time moves on. Some AI people complain "once you wanted AI to beat chess, now that's not good enough? Stop moving goalposts!". Software today can recognise people, generate images from text descriptions, complete sentences, describe photos, self-drive cars over constrained environments, walk robots over rough terrain and jump onto ledges, steady cameras on flying drones following a person. DeepBlue beating Kasparov was impressive in 1996, it's not impressive now. There are AI experts today who were born after that.

Especially contrasted with "it's the best language", "superlative applications", linking something which looks like software of 25 years ago on 10,000x less powerful computers is a big difference in expectations. (It may actually be an amazing game, hence me asking what it was that made you say it is, before it's released). Years ago a company writing Transport Tycoon in assembler was very impressive. Now a single person can write a math animation video generator in Python as a hobby side-project while being a double-major student.[1] Expectations ramp up, year on year, and "coding on the libraries of giants" is a real effect. Pythagoras calculating the length of a hypotenuse was impressive. A school student doing it today isn't.

Hacker News is written in Arc. It's impressive to build a language and build a forum in that language, even though forums existed years ago. But if someone claimed it was the best language which needs to be preserved because it can do the best things, and then used HN as the example, anyone who has used a modern forum with all the trimmings would do the "yes, Grandpa, everything was better in the old days" polite smiling and nodding.

Electron isn't bad because it lacks Lisp, it's bad because it's sluggish and ramps up fans and drains battery life. WhatsApp isn't great because it was written in Erlang, it's great because it connected hundreds of millions of people on all kinds of featurephones and early smartphones. Visual Studio Code isn't very customisable because it's written in JavaScript, it's customisable because they built it to have lots of extension points. The answer to why we need software written in Lisp is like the answer to why we need software written in APL or Prolog: we don't. We also don't need softwre written in Java or C# or Python or Ruby. We may need software written in C, x64 Assembler, because of hardware lock-in. Tools are for doing things with, not for falling in love with.

[1] https://www.3blue1brown.com/about

[reikonomusha]

I think we are talking past each other, and I think it's because you're fixated on and aggravated by a premise I did not stipulate, which is that Lisp is superior to other languages, and as such, you're interpreting "superlative" as "the best software ever written", instead of how you're supposed to interpret it, which is "the best software written in Lisp in the past 10 years", which is precisely what I referred to.

In isolation and without context: We do not need software written in Lisp. Nothing compels us to choose Lisp as a language to express programs that solve problems.

If we want a non-UNIX, non-C ecosystem, then what we need is software, not hardware. Lisp is one type of previously proven ecosystem that works. So it is reasonable to discuss that as a potential option, which is partly the topic of the article we both are posting comments to. I argue that if we want a Lisp ecosystem, we need better and more comprehensive software written in Lisp.

If we don't want a non-UNIX, non-C ecosystem, then we needn't discuss writing software in Lisp (or Smalltalk or ...) as a possible solution to that (non-)problem.

In any case, I simply argue that old hardware or even obsolete operating systems aren't really a productive thing to talk about in this context, except on a case-by-case basis.

Again, regarding "superlative", the word is in reference to last-decade Lisp software alone, which I contend describes Kandria. I don't even attempt to compare software written in Lisp to the entire universe and history of software, which it seems you're doing, but doesn't seem pertinent to the discussion. (Though, to be clear, even when comparing to all of that, I still think you're wrong. But we can argue to no end about our own subjective opinions.)

[chevill]

>anyone who has used a modern forum with all the trimmings would do the "yes, Grandpa, everything was better in the old days" polite smiling and nodding.

HN could have indeed been written in many languages, but IMO the simplicity is a strength. I'd rather be here than twitter, reddit, or any other forum. There's no dark patterns, no recommendation engines or other annoying nonsense trying to game "engagement", no ads, basically none of the things that make the modern Internet an awful user experience.

[p_l]

Regarding Kandria:

You might have heard of this thing called "Art", and that it has styles, and that not only one of them is called "pixel art" for celebrating that kind of limitations, Art as a whole is often talked in terms of self-imposed limits used in creation of a work.

That said, a game can deliberately target such style, and yet hide considerable richness of implementation (consider: Noita, Dwarf Fortress).

Another thing with Shinmera and his team is that they produce both interesting stories, interesting games, but also code I'd argue is art too.

[jodrellblank]

> "That said, a game can deliberately target such style, and yet hide considerable richness of implementation (consider: Noita, Dwarf Fortress)."

It definitely can, and Monkey Island and other SCUMMVM games are examples of having lots of gameplay and comedy, despite constrained graphics. As are card games and board games, for that matter. Fancy 3D isn't the be-all, end-all. In more recent years SpeedRunner[1] isn't pixel art but it's quite simply styled, and is fun for leaning so heavily on a single game mechanic.

I'm not meaning to diss Kandria which might very well be a great game. I meant to call out the gulf between Lisp as "the best language" and "superlative applications" being developed with it then linking to Kandria might set one up to think of the "best games" of recent years, by popularity or profitability or ambitiousness or multiplayability, or replayability, or storyline, or VR support, e.g. Pokemon Go, Grand Theft Auto series, Dark Souls series, Fortnite, Fifa, Half Life Alyx, Tony Hawks Pro Skater remakes, Spiderman PS5, Elite Dangerous, Roblox and Minecraft, Final Fantasy series. Which all seem to have done alright without Lisp, and no game development houses have done the Paul Graham "Lisp as secret weapon" to make a game nobody else can make with other tools.

[1] https://steamuserimages-a.akamaihd.net/ugc/58020036161797293...

[p_l]

Well, the end effect was that your post seemed to concentrate on dissing Kandria, not the way the article went about it (which wasn't the best honestly).

As for games where Lisp was secret sauce, Uncharted series would count, I think ;) It was a return to GOOL-style programming (like in Crash Bandicoot) instead of full engine written in Lisp (like GOAL was for Jak&Dexter), however for narrative-heavy game the tooling used for making that narrative should count as secret weapon.

BTW, a huge underappreciated thing about why Kandria can't fit into less RAM is simple fact that today games generally render at much higher resolutions, and I believe Kandria does have multiple buffers and passes involved (like most game rendering engines these days, though I will have to read Shinmera's paper about shader composition system to verify)