SBCL is an implementation I love working with because updates are steady and the software is stable.
But the real superpower, in my opinion, is that, because the compiler and standard library are written in Common Lisp, you can reach in into the internals of SBCL for your own projects—as if SBCL were just another Lisp library. Is it advised to use unsupported APIs? Definitely not. But it's nice to be able to have seamless access to the same facilities and optimization tools (e.g., DEFTRANSFORM, DEFINE-VOP) that the SBCL uses for its own implementation. You can build impressively clear and highly efficient code this way, essentially by extending the compiler "in userspace".
I wanted to get last modified dates from some files, and I tried to use OSICAT-POSIX, but it didn't work because it was missing a non-CL dependency, so I used SB-POSIX instead, and it worked as expected, no issues. I was glad to have that option, and for that particular code, cross-compatibility with other implementations wasn't a concern.
Most Common Lisp implementations have one or more compilers integrated into it. Most of them are written in itself. Thus, when the implementation provides the source for the compiler, you can explore/change the compiler like any other part of the Lisp code.
> SBCL derives most of its code from CMU CL, created at Carnegie Mellon University. ... it's appropriate to acknowledge the descent from the CMU hackers (and post-CMU CMU CL hackers) who did most of the heavy lifting to make the system work. So the system is named Steel Bank after the industries where Andrew Carnegie and Andrew Mellon, respectively, made the big bucks.
Note that SBCL forked from CMUCL 23 years ago. There's been a great deal of turnover in the code since then. I'm sure you could find some remnants of the original code, but overall it's very much its own thing now.
In the same way that a version of SBCL 23 years in the future is a clear descendent of the current version, so is the current version a direct descendent of CMU CL, 23 years ago.
CMU CL in turn has it's lineage from Spice Lisp: a dialect that originated 40+ years ago on pdp-10. It's even less chance to have residual code of that still around though.
I see there are still comments attributing to Spice project in CMUCL source. But it's hard to make how much of the code is still original. E.g. reader is one of those files but it certainly seen major rework, seeing all the unicode support and whatnot.
> Sure but it wasn't even a Common Lisp initially.
Right, initially it started as a Maclisp derivative.
They morphed it gradually into Common Lisp, while defining Common Lisp. The Spice Lisp project was actively involved in defining & implementing Common Lisp. Two of the five members of the original designers of CL were at CMU: Steele and Fahlman. The others were Moon, Weinreb, Gabriel.
I "(declaim)" the types of my exported functions (at least) which makes life much easier when consuming the library's API, and when you make a mistake (either in the caller or the implementation) you'll get either an error or a warning when you compile the function. The types also show up in the documentation in SLIME and can (but is not guaranteed to, you can check with (time) and (disassemble) and (sb-profile)) make code much faster... specially if you need a lot of numeric computation, declaring the types of the numbers as `fixnum` or `single-float` (you may need to explicitly restrict the range of the numbers too to get the best Assembly) your code can run much faster as that will let it compile to basically what C would do, as it avoids the Lisp numerical tower slowing things down.
Nope, Common Lisp is strongly typed, however the implementations are a bit flexible in how they handle it - the minimum required is that they serve as asserts (essentially, types for safety).
CMUCL Python compiler (not to be confused with the much younger language of the same name), which is also used by CMUCL's descendants like SBCL, is famous for the amount of type-guided optimisation it performs. If it can subtype, or you can inform you of appropriately narrow type, it will happily replace more generic arithmetic and with (safety 0) elide all safety checks.
Also, the soft typing it does to allow the type-guided optimization also allows it to detect many type errors at compile time. These become warnings; it's considered proper to eliminate all such warnings from your code before considering it to "compile".
Opposite of strongly typed is weakly typed or loosely typed.
Opposite of static typing is dynamic typing.
Both CL and Python are strongly and dynamically typed by default. Their values have well defined types, variables don't.
C/C++ are statically and weakly typed. Haskell and Java is statically and strongly typed. Many shell and scripting languages are weakly or loosely and dynamically typed.
Calling C/C++ "weakly typed" is just functional/academic language snobbery. They have some automatic type conversions (more than some languages, less than others) and they have casts that allow programmers to circumvent the type system (but so does Ocaml with its Obj.magic, and Haskell with its unsafeCoerce).
The strong/weak distinction isn't particularly valuable in the first place, but it becomes especially useless if you try to shoehorn C/C++ into the "weak" category.
Firstly, Ability to circumvent type system means it's a weak type system. In in C and C++ you can take pointer to anything and cast it into anything. The memory model in both languages is just one or more contiguous sequences of bytes. https://en.cppreference.com/w/cpp/language/memory_model
Secondly, What you call "functional/academic language snobbery" is accurate language that every software engineer benefits from using and understanding. Being professional is not snobbery or elitism.
You're issuing a correction for your original post, then? Haskell can circumvent the type system with unsafeCoerce and cast anything into anything else, therefore it (by your definition) is weakly typed. Same thing with Ocaml and Obj.magic. Practically every strongly typed language has a mechanism for circumventing the type system:
C: (type) casts
C++: reinterpret_cast and friends
Haskell: unsafeCoerce
Ocaml: Obj.magic
Golang: unsafe.Pointer
Rust: std::mem::transmute
SML: MLton doesn't provide one, but SML/NJ provides
Unsafe.cast. So I guess MLton's flavor of SML
is strongly typed, but SML/NJ's is weakly typed.
Any definition of "weakly typed" which excludes Haskell and Ocaml is farcical, inaccurate, and doesn't benefit any software engineer, especially the professional ones.
> Any definition of "weakly typed" which excludes Haskell and Ocaml is farcical, inaccurate, and doesn't benefit any software engineer, especially the professional ones.
Here is a definition: a language is weakly typed if and only if it has implicit type conversion. JavaScript is weakly typed:
> "3" * "4"
12
Haskell is not:
ghci> "3" * "4"
<interactive>:1:5: error:
• No instance for (Num String) arising from a use of ‘*’
• In the expression: "3" * "4"
In an equation for ‘it’: it = "3" * "4"
Neither is OCaml:
utop # "3" * "4";;
Error: This expression has type string but an expression was expected of type
int
C++ is weakly typed:
#include <iostream>
int main() {
int x = 7;
bool y = x;
std::cout << x << "\n";
std::cout << y << "\n";
return 0;
}
which prints
7
1
Haskell and OCaml are not weakly typed:
ghci> let x = 7 in let (y :: Bool) = x in print y
<interactive>:4:32: error:
• No instance for (Num Bool) arising from a use of ‘x’
• In the expression: x
In a pattern binding: (y :: Bool) = x
In the expression: let (y :: Bool) = x in print y
utop # let x = 7 in let (y : bool) = x in Printf.printf "%B\n" y;;
Error: This expression has type int but an expression was expected of type bool
> does operator overloading turn c++ and others into the weakly typed language?
Polymorphism is not the same as implicit type conversion. For example, in Haskell, `*` is defined for both integers and doubles so 3 * 4 and 3.0 * 4.0 both work without type conversion. But JavaScript converts strings to numbers in "3" * "4".
> does typescript-like type checking (which barks on 1+”1”) with “disallow emit on error” turn javascript into the strongly typed one?
I think so. And this is not surprising. TypeScript is a different language from JavaScript (even if it’s a superset of it).
Pointer arithmetic pulls C and C++ into the realm of weakly typed languages.
Pointer arithmetic is a core part of the language.
On the other hand, Haskell's unsafeCoerce or OCaml Obj.magic are usually not considered to be part of the language, since they are "normal" functions, but it is impossible to implement them inside the language.
> both are dynamic languages with types added later in?
Common Lisp has always had types and type declarations (e.g. `the` in the hyperspec[1]) as it's part of the specification. It was not added later as far as I know.
However, `declaim` and `declare` were left very underspecified so they tend to be very implementation-specific, though there are libraries that make types more portable[2][3].
I used SBCL for a decent chunk of my college coursework. It was a joy to use and made programming fun and exciting in a way I hadn't experienced before.
Kinda was hoping that it was developed by a Bank of some sort, but no. Imagine a bank investing time and effort into creating a Lisp implementation.
> The name "Steel Bank Common Lisp" is a reference to Carnegie Mellon University Common Lisp from which SBCL forked: Andrew Carnegie made his fortune in the steel industry and Andrew Mellon was a successful banker.
Goldman Sachs famously has a proprietary-everything dev environment that works rather well for the kind of applications they need: https://calpaterson.com/bank-python.html
Whenever a post about Lisp graces the front page of Hacker News, I typically observe two main categories of commenters. The first group is composed of devout Lisp enthusiasts who have either applied it to solve problems in the past or continue to utilize it in their personal and professional projects. They are well-versed in the numerous advantages of Lisp over many contemporary programming languages. Their familiarity with the language extends to its versatility in writing DSLs using its macro system, its adaptability in altering running programs, and its debugging prowess. They value the ability to scrutinize the internals, apply multiple programming paradigms, and appreciate various other benefits.
The second group, conversely, is characterized by its perennial question whenever a Lisp-related article surfaces: "Does anybody use Lisp these days?" In response, the first group can usually cite a small collection of projects that still use Lisp, including Clojure shops, a Brazilian startup, and the Hacker News website, which is written in Arc, among others.
This dichotomy serves as an apt illustration of how one's perspective can be distorted, causing them to overlook the broader reality. As much as I admire and appreciate Lisp (and I genuinely do!), it's hard to ignore that the technological world primarily operates on languages such as C, Java, JavaScript, Python, C#, and a handful of others. The communities surrounding these languages seldom feel the need to prove their viability by listing projects that use them.
The undeniable truth is that the world has largely embraced C-type languages, and in doing so, has achieved remarkable feats. The "absolute best" programming language was not a requirement for this progress.
Management professor and esteemed writer Peter Drucker offered valuable insight in his book "The Effective Executive." He stated that effective executives don't become preoccupied with the tools they use; instead, they employ whatever tools are necessary to accomplish their tasks. This notion, I believe, is applicable not only to management but also to the realm of programming languages.
> The undeniable truth is that the world has largely embraced C-type languages, and in doing so, has achieved remarkable feats. The "absolute best" programming language was not a requirement for this progress.
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?
My impression is that language innovation in lisp dialects is largely stagnant at present.
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.
There is language innovation in Common Lisp, but it's either things that need to be in the standard (example: package local nicknames) or in improved implementation of things in the standard.
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.
There are also innovations in implementations. A recent one was the development of CLASP, a Common Lisp implementation with deep C++ / LLVM integration.
"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."
That description sounds great but the docs are less compelling. The integration is you can write a C++ file that exposes individual functions to lisp, https://clasp-developers.github.io/clbind-doc.html.
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.
There is a bit more to it. It allows one to create mixed C++ / Lisp projects with memory management, CLOS methods for C++ classes, CLOS subclass of C++ classes, Lisp and C++ gets compiled to LLVM-IR, debug source output mixing compiled C++ and Lisp frames, ...
The only innovations in the C languages are in making it more like Lisp or working around the deficiencies of a syntax with no macros by adding more syntax on top.
Clojure innovation seems to have largely slowed down, at least from the language maintainers. The last few years have seen lots of little bug fixes, expanding the CLI tool, and better interop with later versions of Java, but nothing major.
> I'm interested anything else strange from the lisp world if people have references.
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.
I'm not suggesting we should stop striving for better programming languages or even that the status quo is good enough. My point was not to discourage innovation in Lisp or in any other language.
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.
I don't think the syntax of Lisp has a damned thing to do with its uptake. Syntax complaints are the shallowest of things and objections of junior programmers are completely unimportant. What kept Lisps out are deeper issues.
> 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.
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 world hasn't moved on though, Isn't clojure, racket and more showing we're just going to keep re-inventing lisp.
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 ?
oh look, it's the balanced and measured lisp skeptic.
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!"
While your defense of Lisp and its historical significance is admirable, I believe your critique oversimplifies the realities of software development and unfairly caricatures those who favor more mainstream languages. The adoption of a language in commercial settings isn't a dismissal of Lisp's merits, but a pragmatic choice driven by considerations such as maintainability, developer availability, and the robustness of language ecosystems.
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.
You've been repeatedly making a number of fallacious points here, which can be summarized as:
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.
I see your points about the wide variety of Lisp languages and their ongoing development (SBCL, Clojure, Racket, Emacs Lisp, for instance). My intention was not to oversimplify Lisp or its significance, but rather to highlight some challenges that may hinder its widespread adoption. I agree that Lisp continues to evolve and that many modern programmers use contemporary versions of the language for real work.
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.
The main factor that influences language choice is not knowing anything else. For large numbers of new programmers, that narrows it down to one, and all other factors become moot. For most others, there is some additional reasoning regarding which of two or three to select.
It's just weird how people like to show up in threads about niche languages specifically to tell people that their language is dead and/or that C or Go is better. Let people use the tools that they like.
I absolutely agree with you that everyone should be allowed to use the tools they prefer. My intention is not to denigrate Lisp or to suggest that it is 'dead.' I appreciate its role in computer science history and its unique strengths.
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.
Beautiful (parenthese tree), powerful, energy efficient (http://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pape...), standardized, battle-tested, and with a glorious past, Lisp reminds me of Gollum's "the precious" ring in Peter Jackson's "The Hobbit" series, and just like the ring, it can make one invisible just by using it too. Maybe it's one of those "precious" tools out there, being the best or not.
In my experience this happens because people tend to react with skepticism when you tell them you used Lisp for something. You can't just tell someone about a neat thing you made without a high probability of being asked to justify why you didn't just use Javascript. So, Lisp people tend to develop some stock answer when they're inevitably asked about it.
Back in 2008... In a world where Facebook was eating social media in PHP, Google was famous regarding its python use, Ruby on Rails was the startup darling (and that was before byte compilation!)...
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...
Hardware has drastically improved. We should have used the extra capacity wisely to catch serious mistakes and automate away our low-value grunt work. Instead we deliver systems that still randomly blow up only faster, and I do largely blame that on the languages we use.
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.
I write mostly Python at work. I do some Rust and a smattering of JS for personal stuff. Those are good languages with huge ecosystems and are very practical choices for productive work.
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.
> it's hard to ignore that the technological world primarily operates on languages such as C, Java, JavaScript, Python, C#, and a handful of others.
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.
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 transportation is obviously WIB: one solution "fits" all, monolithic, logistically complex, not amenable to rapid & piecemeal innovation, good enough for basic function but doesn't & can't offer excellent function either in UX or non-core use cases. Advocating for the superiority of public transport in the same comment as you're espousing the virtues of bespoke software is cognitively dissonant.
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.
Amazing, Germany has radically innovated a way for people to travel throughout the country via a (logistically) complex system requiring multiple stops, transfers, waiting for vehicles to arrive, unload & reload, where transporting large or heavy items or managing children is extra hassle & stress, where you're exposed to hundreds of strangers' behaviors & germs and the enforcedly generic environment that has to accommodate everyone by not being particularly well-suited to anyone.
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.
Most Deutschlandticket owners use it in their region, not for "travel throughout the country". When people travel beyond their region, it does not mean they are traveling throughout the whole country.
> 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...
> extolling it as a desirable-in-itself, convenient way to travel as compared to personal transport is simply not viable.
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.
Mr lproven, at this moment I regret upvoting your previous quite interesting reasonings about Lisps and software, because you so easily went into zealotry and ad personam, just because someone disagreed with you about a public transport.
Please, can you separate "religious " issues from the discussion if sofrware. Thank you.
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.
Thus speaks someone unfamiliar with it, it would appear.
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:
Cities don't use public transport,people do. The public transport system for a given city, as compared to the personal transport choices made by individuals, is Worse Is Better in all the ways I said.
> 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.
It comes across a little dismissive (like "all due respect but <disrespect>") to me, as if Lisp programmers are not making good choices by going against the grain of the strong network effects of mainstream languages. I agree that trying to constantly justify why we choose one thing over another (how many times can we point out that Naughty Dog used Lisp for Crash Bandicoot and Jack and Daxter??) is not a good use of time, though, unless of course you're trying to get someone to give you money. Why do I use Lisp? The vibe is good and I'm usually happy when I'm hacking.
Classic example of "cherry-picking" or "selection bias." The reality is this: Many of the technologies we use daily operate on C, through Unix/Linux/Windows, and the whole web runs on JavaScript, among other languages. Yet, we don't see constant mentions or braggings about these accomplishments.
I don’t see it as cherry picking, rather, a celebration of what is possible. We’re all just having fun here, enjoying the different ways to do things in an interesting industry. It’s important to remember that quantity and quality are not the same thing.
Before I moved on to Clojure, SBCL was what I used. Rock solid, open-source and debuggable (I also used commercial lisps: AllegroCL and Lispworks, and was not happy with them), actively developed.
If you use Common Lisp, this is a really good implementation.
common Lisp has such great implementations and tooling, it's a bummer that it's hamstrung by its ecosystem.
as an example I was working on a project that needed to use active directory for auth. i found a kerberos CL lib that someone had made just for that purpose years ago, but the windows KDC no longer accepted the encryption algorithm that the CL lib used.
meanwhile i was able to get up and running with clojure by leaning on java's builtin security packages, which include kerberos support. and i know that code will not break in the future.
i considered it but i was iffy on the prospect because i wasnt sure how well its maintained, and many libraries are written against sbcl
lispworks was an appealing option actually, it has java interop too and i could maybe get support on library issues, but i ran into the heap limit on the personal edition with my tiny exploratory project, and i didnt want to waste taxpayer dollars if it didnt pan out
At the time, I was mostly impressed by the concurrency support in Clojure. But over time I understood that there is no single silver bullet. It's multiple small niceties that accumulate. These days I can't imagine going back to mutable data structures, or to programming without transducers. Also, the fact that I can use a single language for server and client side, and that works so well that most of my model code is shared, means that I can tackle a large application all by myself.
It's also nice to be able to use Java and ClojureScript libraries :)
Check out ocicl as an alternative to quicklisp if you are concerned about security. Code is distributed using the OCI ecosystem (https by default, proxies work, sigstore integration, etc). https://github.com/ocicl/ocicl
Quicklisp, ironically, only updates once a month. It's managed like a Linux distro. That means the client has a full index of every library in the registry, and knows the hash of every file it may download.
I am pretty sure quicklisp checks the hashes it downloads. Hence, the only security issue with using HTTP seems to be that middleman can see what you've downloaded... if they try to change it in any way, the quicklisp client will reject the download as far as I know (though I haven't checked the code).
What kind of mitm? The attacker cannot modify what you get. You leak the list of packages you download, but I don't think https by itself would have helped — host and filesize would be known, and that should be enough.
https also provides secure authentication, not merely encryption. The encryption part also guarantees the authentication part by proving that the stream can not have been modified.
In order to meet this guarantee for the scheme you're discussing, the hashes themselves need to have a tamper evident. What is this tamper evident?
I recently found out that most Nix fetchers use https, but do not actually do verification (`curl --insecure` or equivalent libcurl settings). Channel updates do verify and include hashes, so the overall chain is authenticated.
My guess is Common Lisp has the most usage in industry, its just quiet compared to the latest dog food sharing app built in Clojure. Racket seems the most enthusiastic and fun community, and has some great learning tools. And Emacs Lisp secretly runs all of it.
As measured by what? Clojure is pretty popular, as is Racket in other circles. Common Lisp is robust, standardized, and "decentralized" with both free and commercial implementations. It and Python power a few quantum computing technologies.
My impression is that part of the problem is that Emacs Lisp is a large language (lots of data types and functions implemented in C) and one without any formal specification, which makes duplicating it correctly in another system very difficult. By contrast, Scheme is a smaller language and has a reasonably clear spec.
Which makes me wonder – instead of trying to port GNU Emacs to run on top of Scheme, might it be easier to produce a Scheme implementation that ran on top of Emacs Lisp? Possibly Emacs Lisp is missing some of the primitives required to implement Scheme efficiently, but the amount of code required to add those primitives will likely turn out to be less than that required to reimplement the whole of GNU Emacs in Scheme – and adding those new primitives may make Emacs Lisp a better language, thus benefitting even those users who aren't interested in Scheme in itself.
Guile has a generic VM and extensible compiler tower, so a bug for bug port of elisp was proving to be an effective method. Unfortunately, the project did not interest the Emacs devs so there just wasn't the buy-in necessary to work through the finer details and make it happen for real. You can open a Guile REPL today and switch the language from Scheme to Elisp and hack away. What makes the whole thing so appealing is that the Elisp compiler simply lowers the code to Guile's "tree intermediate language" (Tree-IL) and gets a free ride the rest of the way through optimization and bytecode emission. The biggest impact Elisp support had on core Guile was that a new immediate type had to be added to represent 'nil'. Soon it won't even be much of a stretch to compile Elisp to WebAssembly (would be funny!) once that backend is ready for Scheme. Guile is undervalued as a platform for language implementation and Emacs missed out on a cool opportunity.
And now thanks to the JIT patch elisp outperforms Guile considerably. Emacs dev is very much motivated by pragmatism, jokes about Emacs being a tool created to write Emacs config notwithstanding.
One measure is git pushes on GitHub. By that measure[0], in Q1 2023, we have Emacs Lisp (2995 pushes) > Clojure (2135) > Scheme (1350) > Common Lisp (236) > Racket (below detection; latest in Q1 2022: 102).
It's not clear what "dominant" means in an already-niche language, but while Guile isn't very popular you still find little snippets of it everywhere from back when it was GNU's official extension language. Even GNU make embeds a guile interpreter, though I think most packagers turn that off at this point, sadly.
> while Guile isn't very popular you still find little snippets of it everywhere from back when it was GNU's official extension language
Your use of past tense here seems to imply it is no longer GNU's official extension language. GNU's own website still says [0] "Guile is the GNU Ubiquitous Intelligent Language for Extensions, and the official extension language of the GNU project."
And it's all of the infrastructure in the official GNU Linux distribution, so I guess you're right, but it was supposed to be the scripting language for the GNU desktop, and to the extent that's still Gnome, that didn't happen. Also the Guile team itself keeps toying with writing a (shudder) Javascript front-end.
The ecmascript frontend is more of a toy than something you could write production code in, but it's a fun example of Guile's extensible compiler tower. No one has seriously worked on it in a long time.
I used SBCL with Vim back in the day. (I have joint problems that make emacs keybinds literally painful). It worked fine, though I missed out in some features.
EMACS was always used for Lisp programming, since day zero. It had always a mode for Lisp programming. Later GNU Emacs became popular and it was partly written in Lisp. Thus it was not unusual for Lisp users to provide Emacs modes for hacking other Lisp dialects than Emacs Lisp, because they could easily program it. Before SLIME, there was an integrated extension, then ILISP and ELI (from Franz). Nowadays SLIME and SLY are mosly used as IDE extensions for GNU Emacs..
imagine python, but you can add more types in order to compile python code into machine code. So you have some slow tight loop, add types, add a decorator and it runs thousands of times faster. Now imagine being able to do this since early 2000s.
the language was outcompeted by java and never recovered. it is less aligned for enterprise development
lisp code often takes advantage of lisp’s language features to define DSLs in their projects and don’t document them well. it can be more challenging to figure out how lisp code works than java, which prioritizes predictability and standardization
Java is much easier to pick up and be productive with for C++ programmers, which were a major target audience
and Oracle put out absolutely insane amounts of marketing at the time
java’s built in libraries are extensive and cover more real world needs than what is specified by CL
so CL fell to the wayside and lost market share. and with fewer people using it, there have been fewer libraries available for common programming needs
My naive guess is lack of a good package repository. CPAN made Perl great, even if the language was not to everyone’s taste. Node/npm made javascript huge. Pypi picking up binary wheels made python the obvious choice for any data-heavy project.
Is there even a central common lisp package repository?
They missed a trick when they didn't call it Rich Friend Common Lisp
(Originally based on Carnegie Mellon University Common Lisp. Carnegie got rich in steel, Mellon in banks, but both were rich, and Mellon is Elvish for Friend. Rich Friend Common Lisp. There. A bilingual pun about a Common Lisp implementation, where one of those languages is a conlang from a fantasy novel. Geekiest joke you'll hear all day.)
But the real superpower, in my opinion, is that, because the compiler and standard library are written in Common Lisp, you can reach in into the internals of SBCL for your own projects—as if SBCL were just another Lisp library. Is it advised to use unsupported APIs? Definitely not. But it's nice to be able to have seamless access to the same facilities and optimization tools (e.g., DEFTRANSFORM, DEFINE-VOP) that the SBCL uses for its own implementation. You can build impressively clear and highly efficient code this way, essentially by extending the compiler "in userspace".