It's hard to argue with that, but I'm not sure what point you're trying to make. Should we stop striving for better programming languages, because the status quo is good enough? Or just stop for lisp languages but try to innovate in C-like languages?

Common lisp is flexible enough that it's reasonable for projects to stay within the immutable standard, so only library progress happens.

Scheme has given up on the minimal side to the design and become over-obsessed with complicated macros and static compilation. I suppose that's change, if not progress.

Clojure I can't say much about. I like the hashed trie and do not consider the JVM connection a feature. Maybe that is still changing over time.

Racket is still doing its thing, but the current push (Rhombus) seems to mostly be about removing S expressions.

Kernel is a different lisp. Tragically we lost the author too young. Kernel deletes most of the limitations and cruft of _scheme_. It would benefit from a sbcl-level of development effort which doesn't seem to be happening.

I'm interested anything else strange from the lisp world if people have references.

Innovating in the C derivatives continues at pace of course.

The latter one I point to often is the problem of efficiently compiling a dynamic language, where (for example) the offsets of slots in objects can be changed at run time, or (another example) where the set of methods for a generic function can change at run time.

See Robert Strandh's paper in https://european-lisp-symposium.org/static/proceedings/2021.... (page 72)

https://clasp-developers.github.io

"Clasp is a new Common Lisp implementation that seamlessly interoperates with C++ libraries and programs using LLVM for compilation to native code. This allows Clasp to take advantage of a vast array of preexisting libraries and programs, such as out of the scientific computing ecosystem. Embedding them in a Common Lisp environment allows you to make use of rapid prototyping, incremental development, and other capabilities that make it a powerful language."

There doesn't seem to be any way to feed C++ headers into clasp and get out template instantiations accessible to lisp. It looks like SWIG or pybind but you write the shims yourself, and it's function pointer based so templates are wrapped one instantiation at a time.

Garbage collection in the docs is a one paragraph stub which suggests you're on your own for lifetime management across the languages.

Cool thing to exist. Seamless interoperation is either overselling it or the docs are out of date.

Hissp just released version 0.4.0. It compiles Python tuples to Python expressions and has multiple readers with different characteristics, not all of which are based on S-expressions.

https://github.com/gilch/hissp/discussions/182

Quite the contrary, I believe that the world of programming is constantly evolving and not revolving solely around whether Lisp is the best. There is a plethora of new languages being generated that are designed to solve problems in unique, innovative ways. For example, languages like Rust, Elixir, Go, and Haskell are much younger than Lisp and are great in their respective fields.

You know, in some ways, the situation often seems reversed. Some Lisp enthusiasts treat non-Lispers as if they are yet to grasp 'the truth', implying that with enough effort and enlightenment, they too will understand and embrace Lisp. While I recognize the merits of Lisp and the passion of its community, it's important to remember that the technological world isn't static; it continues to evolve and innovate.

The reality is this: The world has moved on. A multitude of new languages, paradigms, and methodologies have emerged, each excelling in its unique way and suited to specific problems or contexts.

From where, to where? You're saying nothing really.

Most movement I've seen in the last 25 years has been because of price, ease of use for beginners, learning materials, marketing and tooling. Intrinsic qualities of the language matters only to a handful of enthusiastic early adopters that I would put in the marketing category.

IMHO Lisp lacks ease of use for beginners and tooling, it's not about the language at all.

We have come a long way from a time when dynamic languages like Perl, Python, and others were not yet prevalent. Back then, Lisp stood out as a unique problem-solving tool compared to languages like Pascal or C. However, today we live in a world where we have highly capable lisps and dynamic languages that allow us to explore problems quickly and with less verbosity. In this newer world, it seems that younger generations are not inclined to deal with s-expressions. I don't believe it's solely the marketing of other tools that has made them the go-to choices.

When talking about programming languages, these type of comments are equivalent to those you describe being made by some lispers claiming to know "the truth". Plenty of languages have their evangelists and their detractors. Common Lisp is no different. Use the tool that suits you. Religious attitude toward anything is likely to be counter productive

The points you make sound like you're assuming that newer == better, and 'moving on' is innovation. I'm not sure our current batch of fast fashion languages are significant improvements, they would need to provide a feature that lisp does not, and if so, what is it ?

If you're going to construct commenters taxonomy, you should include yourself in it, because "I really like lisp, but surely we can rationally agree that the world/we/commercial shops/society has moved on to C" balanced and measured meta-commenter has existed since at least usenet comp.lang.lisp lisp days.

oddly enough this kind of meta-commenter primarily appears in lisp threads. possibly because lisp is one of the few languages that started in 1950s and is being used still, to the utter confusion and dismay of the balanced lisp skeptic.

this meta-comment fundamentally has a faulty premise, that the single dominant language development paradigm is the exclusive one. this was not true in the 90s, when it seemed all but inevitable that the computing world is going to standardize on c++ or java, but it's particularly faulty now, when heterogenous stacks are significantly more popular and the overall number of developers, with varied interests and preferences has increased.

the second faulty premise is that the mass of development and corporate preferences somehow matter in viability, particularly in such an individualistic field as computer programming. personally I reach for Common Lisp when I need to solve a problem where I understand neither the problem nor the solution, what's known as explorative programming. having established the parameters of the solution, I can then communicate the architecture to senior programmer team. the solution then will be communicated by people like you as "success story for Java", ignoring the fact that the successful architecture might have not even materialized without a lisp prototype. many lisp success stories are like that.

if you already understand your solution space, then the value of lisp is equivalent to any other dominant language, and things like library support and easy development availability become core differentiator. lisp is not the only language in this space, smalltalk come to mind, Julia, and to a lesser degree mathematica and Matlab.

so we're going to continue to use lisp in our special and mysterious ways to the utter dismay and confusion for people like you "but guys guys we've moved ooon!"

It's not about moving "on" from Lisp as if it's outdated, but about moving "with" the ever-evolving field of programming where different languages serve different purposes. Despite Lisp's strengths in exploratory programming, its steep learning curve, and a relative lack of widely used libraries and tools compared to languages like Python or Java, can make it a less practical choice in certain environments.

Moreover, attributing a project's success solely to its initial Lisp prototype overlooks the fact that many different languages could be used to prototype effectively. The successful completion and deployment of any software involve various factors beyond the choice of initial prototyping language.

There's room for a multitude of languages in the programming world, each with their strengths and weaknesses. Dismissing those who choose other languages as simply not understanding Lisp's value is an oversimplification and fails to account for the complex factors that influence language choice in different scenarios.

1. Lisp is a single language, with one fixed set of trade-offs, rather than a large family.

2. Lisp has been around for a long time, and isn't developed any more and has only historic significance. People who work with Lisp are essentially retro-computing hobbyists, not keeping up with what is going on.

With regard to (1) Lisp is a fairly large family, and the members are different from each other. The strength and weaknesses of, say, Gauche Scheme are not the same as those of Armed Bear Common Lisp (to pick a random pair).

There are Lisps that give you general purpose programming on Unix or Windows: multiple programming paradigms and access to the entire platform. Anything the system is capable of doing, you can do it through Lisp.

With regard to (2), there are certainly some people who are into retro-computing in regard to Lisp. For instance, a few people have revived the historic Interlisp iplementation from the 1970. They have it running with its windowing system and all. There is an active trading market for old Lisp hardware like Lisp machines of various kinds. Sure.

By and large though, people who are working with Lisp of any kind for real work are using something contemporary that is being developed. Just like people working with C (also an old language by now) are likely on a recent Clang or GCC, and not Borland Turbo C 2.0 for MS-DOS. Lisp people move on from old Lisp implementation, like they do from old C or Python implementations.

You're dismissing the existence of new Lisp dialects, and of continuing development of existing older implementations.

You're also dismissing the possibility that contemporary Lisp programmers might actually know Python, Go, C# and so on. Including ones who work on maintaining implementations.

People who knows those other things and some kind of Lisp or two probably make better informed decision in regard to whether or not they use Lisp, that those who don't know any Lisp.

However, despite the ongoing development and evolution of Lisp, it seems that its adoption in commercial settings may still be limited due to factors such as maintainability, developer availability, and the robustness of language ecosystems. I’d be interested to hear your thoughts on how these factors might be addressed to increase Lisp’s adoption in these environments.

I also agree that those who are knowledgeable in both Lisp and other programming languages likely make better-informed decisions regarding language choice. In your experience, how do these programmers navigate the choice between Lisp and more mainstream languages in different scenarios? I look forward to your insights.

Without specifics about what its you're talking about, I have no idea what you're talking about.

What do you understand as Lisp? Does it include Clojure, Janet or Hy?

Every project has its unique struggles.

The adoption of absolutely everything outside of some half dozen popular things is virtually nonexistent. It has nothing to do with their syntax, because the field is full of wannabes striving for popularity of their project, by means of deliberately imitating the syntax of what is popular. It's not working; they're only ruining their project with garbage ideas for nothing.

Most of what is not popular is non-Lisp. Making a non-Lisp is as good a path to unpopularity as making a Lisp.

Some Lisp-likes are integrated into popular run-times and can use their ecosystems. Robustness of the ecosystem is obviously a non-issue for them. They can be used gradually; like a few files of some project written in another language can be in the Lisp-like. That counts as a valid use.

However, it's also important to understand that the purpose of discussions like these is to exchange perspectives and understandings about the different tools we use. The objective is not to declare one language as the 'holy grail' and demean the rest, but rather to acknowledge that each language, Lisp included, has its strengths and weaknesses, and is more suitable for certain tasks than others.

While Lisp is excellent for certain tasks such as exploratory programming, other languages like C, Go, or Python might be better for others due to factors like their robust libraries, wider community support, or greater ease of readability and maintenance.

Extremely popular languages like Python and Javascript aren't C-type. Neither is Java particular C-type (besides a few syntactic features).

They also don't get bothered about the viability of their languages every time they're mentioned.

Just mentioning you had a project in Lisp would get you questions like "isn't it interpreted and slow?" - fortunately good business clients rarely care about language something is written in...

I’m not going to say Lisp got everything right. Everything was mutable until Clojure came along, lack of type checking and inference hurts, and the condition system was so complicated that it’s been mostly ignored. But it’s still unrivaled in backing the domain-specific languages we should graduate to.

Personal note: I much prefer to maintain a long-living software in Common Lisp rather than in Python, thank you very much. May all the new programmers learn easily and all the teams have lots of ~~burden~~ work with Python, good for them.

That said, it feels so good to think in Lisp sometimes. It’s just elegant. When I write Python, I see code manipulating data. When I write Lisp, I see data flowing through code.

I think you are focusing on the trees and so not seeing the size and the shape of the forest.

Most organisations use C and languages implemented in C, on OSes implemented in C, because they do the job, the people are cheap and readily available, and the dominant OS is free and costs nothing to deploy.

Which can be reduced to:

Most people use the tools most people use.

That's not a very useful observation, but it poses an interesting question:

Why?

That's easier.

Here is the shape of the outside of the answer:

They use them not because they are good -- they aren't very good, measured objectively -- but because they are ubiquitous and cheap.

Other tools are better, and just as free, but then the people cost more, and the associated tooling costs more. (Frameworks, supporting libraries, deployment costs, whatever. E.g. it's very cheap to deploy Javascript because all you need is a reasonably modern browser, and those are free and almost all OSes have them.)

Those are the externalities, in a manner of speaking.

But the other side of the answer is the inside: the area, not the shape.

The mainstream, conventional, software industry is huge, and hugely lucrative.

Writing just-barely-good-enough apps, minimum viable products, gets you out there and making money. Then you can put a share of your revenues into incrementally improving it.

Every now and then you can push out a big new version, with disruptive changes. You can charge for getting the new major releases, but more to the point, once an old version is officially obsolete, you can charge for continued fixes to the now-obsolete versions.

It makes money. It's an ecosystem, a food chain or more accurately a web. Some members are predators, some are prey, but they all work together and if you just eliminate either predators or prey, the system collapses.

In other words:

Most people use the tools most people use, because most people use them, because you can make big money from volume of cheap junk.

But there is another model of making and selling stuff: make small volumes of really good products, using highly skilled workers, and sell those high-quality products in very small volumes but for very high prices, to discerning customers who know they're buying something built to last and who may not come back to you for new versions every couple of years, but that's fine if you made a couple of decades' revenue from them on the original sale.

Because cars are a long standing metaphor in computers and computing:

If you have a mass market for cars, then you get cheap cars, and everyone's cars are much the same because they are built down to a price and mass produced.

These car consumers can be upsold some extra buttons and minor features, and a lot of those combined may double the price of the car.

(This is how different Linux distros survive. Some have more buttons. Some have A/C. Some are fully automatic, others have fully manual controls. Some have power steering, some don't.)

But such a market also supports hand-made sports cars (and, inevitably, superficially similar cheaper sports cars from the mass-producers). It also supports vast tanklike cars that weigh as much as 10 normal cars, but produce 10x the engine power of those cars so they still perform.

Very different products, but they cost an order of magnitude more than the mass-produced cars... and do the same job. Some owners of mass-produced cars aspire to own fancy sports cars, and some aspire to own luxury behemoths. Most never will.

People who don't care much for cars and just see them as a tool for getting from A to B do not see why anyone would pay for fancier cars. That's OK, too.

Some people live in other countries and see more clearly, because for them trains and bicycles are a perfectly viable way of getting from A to B, and are both cleaner, healthier, use less resources and create less waste.

Tools like Lisp are the artisanal hand-made cars compared to the mass market. People who've never used anything but cheap mass-produced tin boxes can't even imagine that there are things that are so much better, let alone that in the long run, you might be better off using them.

As Terry Pratchett put it:

« “The reason that the rich were so rich, Vimes reasoned, was because they managed to spend less money.

Take boots, for example. He earned $38 a month plus allowances. A really good pair of leather boots cost $50. But an affordable pair of boots, which were sort of OK for a season or two and then leaked like hell when the cardboard gave out, cost about $10. Those were the kind of boots Vimes always bought, and wore until the soles were so thin that he could tell where he was in Ankh-Morpork on a foggy night by the feel of the cobbles.

But the thing was that good boots lasted for years and years. A man who could afford $50 had a pair of boots that'd still be keeping his feet dry in ten years' time, while the poor man who could only afford cheap boots would have spent a $199 on boots in the same time and would still have wet feet.

This was the Captain Samuel Vimes 'Boots' theory of socioeconomic unfairness.” »

Some of us live in countries with really good public transport, and know that it's possible to replace the entire category of personal automobiles with something better for everyone...

But try telling that to an American. They won't even try to understand; they will instead earnestly explain why they need cars, and their country is better because everyone has cars.

More wild generalisation:

In the late 20th century, there was another model of software construction, an alternative to the "Worse is better" model. The WIB model is that one type of software fits all, and build one (or a very few) minimum viable operating systems, from minimal viable programming languages, and make them cheap or give them away for free.

The artisanal software model was more common in Europe and Japan: pick the best language for the job, and build tiny bespoke OSes for each category of device. Have multiple whole incompatible families of desktop OSes, and families of totally different unrelated server OSes, and families of different OSes for handhelds and games consoles and school computers for teaching kids, and so on.

Unify them, minimally, with some standard formats: network protocols, disk and file formats, maybe some quite similar programming languages in lots of weird little nonstandard dialects.

iTron, RISC OS, SiBO/EPOC/EPOC32/Symbian, QDOS/Minerva/SMSQe, Con-Tiki, Symbos, GEOS, Novell Netware.

Keep the complexity are the market level, in which multiple radically different products compete for sales in their market segments. Lots of overlap, lots of duplication... but also competition, evolution, rivalry, advancement.

The software remains small and relatively simple. This aids development, but mainly, it keeps the resource requirements low, so the devices are cheaper. Human brainpower is cheap: spend it on clever software to enable cheap hardware.

The approach I am calling WIB is of vast general-purpose OSes which can do anything, so you only need a handful of them... but you need massive hardware to run it, so devices powered by WIB software are expensive, and very complicated, and the software is vastly complicated, so you need armies of programmers to maintain it, meaning frequent updates, so you need lots of storage and fast connections.

And there is no overview, because it's much too big to fit into a single human head, so improvement is incremental, not radical.

The end result is a handful of vast monoliths, full of holes and leaks, but a vast economic machine that generates continuous income and lots of jobs.

When you live in one of these monoliths, the fact that there are happy accomplished people working in weird tools making weird little products for tiny markets seems incomprehensible. Why would they?

Most people use the standard tools, meaning the ones most people use. So obviously they are good enough: look at these trillion-dollar corporations that use them!

So obviously, there isn't really any point to the weirdoes.

Public transport is not monolithic. Public transport is a complex evolving system of trains, busses, ferries, car sharing systems, car leasing, on demand mobility, etc. This is coordinated, integrated and has a various forms of innovation: technically and service.

The most recent radical innovation is a nation-wide public transport ticket (as a subscription) for all of Germany.

Public transport is a good thing to have, but extolling it as a desirable-in-itself, convenient way to travel as compared to personal transport is simply not viable.

> Public transport is a good thing to have, but extolling it as a desirable-in-itself, convenient way to travel as compared to personal transport is simply not viable.

Mobility is an important need of people. Public transport provides a large part of the mobility needs in Germany and Cities compete by providing good services. Whether people prefer it to "personal transport" is their choice. If you personally have problems using mobility services together with "strangers", that's your thing and there are alternatives for you. Many people don't have these problems, which can be seen by the amount of people using public transport. There should now be more than ten million owners (10m was reached after one month of availability) of a Deutschlandticket (which is a subscription ticket) - out of a population of 80+ million. Additionally people use public transport with other tickets. The public transport is also not there in isolation. It is meshed with car usage, flights, long-distance trains, ... people walk and bike...

Another fallacious argument.

It is desirable in itself.

It results in human-scale cities, more accessible for all regardless of disabilities.

It makes more efficient use of resources. It uses less energy, emits less pollution, means less space must be devoted to roads and to parking.

It makes streets more pleasant places to be, so one might choose to eat or drink on the street, free of traffic fumes.

It means one can drink alcohol and not have to pay a lot for a taxi home, and thus, reduces the motivation to drunk drive.

Car-free streets are better for cycling, which is better for public health, which is better for healthcare infrastructure.

In fact, there is no real disadvantage to it, as your rather ridiculous attempts to construct negatives show:

> a (logistically) complex system

That's a good thing. More options. E.g. one can choose step-free routes when moving luggage or infants in prams, or if a wheelchair user, versus faster alternatives when travelling unencumbered.

You may not have noticed but most people have smartphones now, which can do the routing for you.

Your claimed disadvantage is in fact a win.

> waiting for vehicles to arrive,

Better than waiting in traffic jams.

> unload & reload

False; cars must do this too.

> transporting large or heavy items

You make it increasingly clear you've no experience of this and the biases of someone to whom it is alien and scary.

I've moved furniture this way. I've moved rackmount servers and 21" CRT monitors this way.

It's cheap.

> where you're exposed to hundreds of strangers' behaviors & germs

You sound like the increasingly deranged and irrational Elon Musk, whom I once admired.

> enforcedly generic environment

Utter lunacy. American cities, covered in freeways, and still congested, are the ultimate example of this.

You seem to think you are making a logical case.

You are not. You are making it plain you are a bigot who lacks experience of the thing they are attacking, though.

Please, can you separate "religious " issues from the discussion if sofrware. Thank you.

Genuinely dismayed to hear that.

I put it to you that it's one of these things the depends entirely on your personal background, specifically including the country (or countries) that you grew up in.

I have been told, to my face, that it is absolutely impossible to live life in a modern American city using a bicycle as your only form of transport. (Let alone as a pedestrian!) This may be true; I don't know, I've never lived in America.

But as an adult, I've lived in London, Brno, and Prague, with bicycles as my only regular form of vehicle, used in combination with public transport, and it's been absolutely fine. Not even inconvenient, not tolerable, not bearable, but pleasant, easy, cheap, convenient, and fun.

I didn't get a car driver's license until I was 37 years old. I never needed one. (I did have a motorcycle license from the age of about 22.)

I have often faced out right incredulity when I told people this but it is not exaggeration.

Similarly, I have often been told that life as a vegetarian is inconceivable. People have cited a multitude of reasons, from lack of ingredients, the lack of culinary skills, the lack of availability of restaurants where they live, to simple inability to face the prospect of life without eating meat... but I've been a vegetarian for over 40 years now. It is not some miserable, puritan, ascetic life of self-denial. I've travelled to many dozens of countries, and never had a real problem, and I've never ever, not once, let it lapse for any reason, especially not because I was abroad. It doesn't mean austere self-denial. I love my food, as my waistline shows, unfortunately.

When I say that somebody's national background is probably a motivating factor in their lack of belief that, for example, designing entire nation states around public transport as the primary way of getting around, that is not an ad hominem attack. It is a plain and simple statement of fact.

Sometimes, people's lifestyles and background mean that they cannot imagine a life that is so radically different to their own… and that can mean even people that have travelled extensively in their own country. I don't think that it is rude to point that out.

The reverse is in fact true, as @lispm points out.

It's complex, it's diverse, it's tailored to each individual town and city. Big cities have urban rail or light rail or both, smaller ones have trams or trolleybuses, smaller ones may have just buses. To get to and from the stops, some cities have footpaths, some private bicycles, some public cycle sharing schemes.

And any combinations of the above, of course.

Every system bespoke to that city. Every city's system totally unique.

Outlier cities, such as very mountainous ones, integrate cable car systems into the mix, such as La Paz:

https://en.wikipedia.org/wiki/Mi_Telef%C3%A9rico

And Medellín:

https://en.wikipedia.org/wiki/Metrocable_(Medell%C3%ADn)

Chongqing has a remarkable system because the city spans a set of mountain ranges and valleys:

https://en.wikipedia.org/wiki/Chongqing_Rail_Transit

The exact reverse of your statement is the case.

The simplistic one-size-fits-all answer is: "get everyone to drive, give them loads of big roads and pave half the city for parking."

https://oldurbanist.blogspot.com/2011/12/we-are-25-looking-a...

Straw man argument. Nobody is saying they do.

> the personal transport choices made by individuals

Also fallacious; people's choices are constrained by the options available to them. If you live somewhere with excellent public transport, as I have most of my life in the 3 major cities I've inhabited and indeed most of those I've visited for work or pleasure, you have more choice. You can choose to drive, or to ride a bike, or to ride pubtrans.

If there is no pubtrans, or little and inconvenient, then you are being deprived of choice, deprived of diversity of options: the result is a car monoculture.

You are attempting to argue the inverse of the position you claim. I don't know why.