Companies that use Lisp extensively(github.com)
github.com
Companies that use Lisp extensively
https://github.com/azzamsa/awesome-lisp-companies
163 comments
The ex-MIT people who started the company were really good at robotics, and with MIT being a Lisp powerhouse the choice was perhaps natural.
But thing is if you are good at Lisp you can move really, really fast. I also do embedded development (mostly with C) but the last project I had an opportunity to do in Common Lisp. It was a fantastic experience with perfect commercial outcome. It feels like you move mountains.
But thing is if you are good at Lisp you can move really, really fast. I also do embedded development (mostly with C) but the last project I had an opportunity to do in Common Lisp. It was a fantastic experience with perfect commercial outcome. It feels like you move mountains.
> The ex-MIT people who started the company were really good at robotics
and Lisp.
Rodney Brooks worked on S1 Lisp and Lucid Common Lisp. He was a co-founder of Lucid, Inc. and wrote the book 'Programming in Common Lisp' (Wiley, 1985).
See for example: "Design of an Optimizing, Dynamically Retargetable Compiler for Common Lisp", 1986. The authors (incl. Rodney Brooks) worked for Lucid, Inc.
https://www.researchgate.net/publication/221252387_Design_of...
and Lisp.
Rodney Brooks worked on S1 Lisp and Lucid Common Lisp. He was a co-founder of Lucid, Inc. and wrote the book 'Programming in Common Lisp' (Wiley, 1985).
See for example: "Design of an Optimizing, Dynamically Retargetable Compiler for Common Lisp", 1986. The authors (incl. Rodney Brooks) worked for Lucid, Inc.
https://www.researchgate.net/publication/221252387_Design_of...
Does the Roomba's Lisp use an incremental garbage collector?
I saw a great paper on their dialect a while ago. Will try and find it and edit this with a link.
Check out passage 3.4; it goes into detail on their garbage collector.
L – A Common Lisp for Embedded Systems
Rodney A. Brooks and Charles Rosenberg
IS Robotics [now iRobot Corporation, the famous floor vacuum company]
1995
https://web.archive.org/web/20041031144839/http://www-2.cs.c...
Check out passage 3.4; it goes into detail on their garbage collector.
L – A Common Lisp for Embedded Systems
Rodney A. Brooks and Charles Rosenberg
IS Robotics [now iRobot Corporation, the famous floor vacuum company]
1995
https://web.archive.org/web/20041031144839/http://www-2.cs.c...
Whoosh :)
I got the joke, but I still find the dialect fascinating enough that I will pretend to take one of the many jokes of Don Hopkins literally to get an excuse to post that paper.
IIRC I saw a comment on lambda-the-ultimate years ago that said that this paper was great but there are no hints of any implementation or anything since it was swept up by irobot.
It wasn't swept up (ha!) by iRobot. IS Robotics changed their name to iRobot. If you're skeptic, check Wikipedia for the first author on that paper.
That's the sound the garbage collector makes! ;)
Mark and sweep
I really don't get the feeling that iRobot uses Lisp anymore, and espeically not extensively. Most of their robotics software engineer jobs advertise C/C++. On the rare occasion I've seen Lisp mentioned, it was for a junior role and sounded like it was only to use the existing dialect (I'm assuming for older robots).
My gut feeling is that they have a dialect but no longer actively develop it and potentially no longer use it for newer robots. Plus, it's probably more of a C-like Lisp.
A lot of these companies on this list do not actively use Lisp or even exist anymore.
One company that is left off the list is 2Is Inc. They use Common Lisp for everything and actively do so.
My gut feeling is that they have a dialect but no longer actively develop it and potentially no longer use it for newer robots. Plus, it's probably more of a C-like Lisp.
A lot of these companies on this list do not actively use Lisp or even exist anymore.
One company that is left off the list is 2Is Inc. They use Common Lisp for everything and actively do so.
> One company that is left off the list is 2Is Inc. They use Common Lisp for everything and actively do so.
Anything recent you can point at to authoritatively show they still use Common Lisp?
I do see their site says:
> programming using Lisp and object database technology.
https://2is-inc.com/common-positions.html
But they also don't have this position open at the moment. And saying "Lisp" is a little vague.
I see Franz Inc news about 2Is Inc from as recent as 2015 but no more recent than that that clearly shows 2Is Inc still uses Common Lisp.
Anything recent you can point at to authoritatively show they still use Common Lisp?
I do see their site says:
> programming using Lisp and object database technology.
https://2is-inc.com/common-positions.html
But they also don't have this position open at the moment. And saying "Lisp" is a little vague.
I see Franz Inc news about 2Is Inc from as recent as 2015 but no more recent than that that clearly shows 2Is Inc still uses Common Lisp.
I interviewed there a few years ago (one of the most enjoyable interviews I've had). For example, I was asked, by the CEO, "what are signs that we'll know you're stressed?". They definitely use Allegro Common Lisp for everything they can except for some JavaScript frameworks for new front end work, if I remember correctly on the latter part. There were zero hints they'd move away from Common Lisp.
They don't mind if you don't know Lisp or even programming, so that's probably why it's understated in their job description. They prefer just hiring smart people and training them. A lot of people there studied math, physics, and even liberal arts. This is the right way that very few do.
The thing with this list is that it is just extremely outdated. It misses a few that actually use a Lisp and lists a lot that just isn't up to date.
I've tried very hard to get a Lisp job. They are exceedingly rare and nearly nonexistent. There's much better chances with Clojure and Elixir.
They don't mind if you don't know Lisp or even programming, so that's probably why it's understated in their job description. They prefer just hiring smart people and training them. A lot of people there studied math, physics, and even liberal arts. This is the right way that very few do.
The thing with this list is that it is just extremely outdated. It misses a few that actually use a Lisp and lists a lot that just isn't up to date.
I've tried very hard to get a Lisp job. They are exceedingly rare and nearly nonexistent. There's much better chances with Clojure and Elixir.
Lisp seems like it’s incredibly powerful in the hand of a wizard but once the company gets past a certain size they’ve hired every lisp programmer in the world and move to a more mainstream language.
I experienced this in the Smalltalk world years ago as well. Languages/environments are tools. They amplify what an individual can do when creating. High powered languages allow high powered people to write cooler code. Average programmers just write more average programs. Spaghetti programmers just make more spaghetti.
And many of the new languages are designed around removing footguns for the spaghetti chefs I feel.
Of course everyone thinks they’re a superstar, but they’re probably not. I know I ain’t.
Of course everyone thinks they’re a superstar, but they’re probably not. I know I ain’t.
I don’t think I’m a superstar. I do find the complexities created by the “foot gun inhibitors” limit creativity and simplicity.
Every time Kotlin/Swift add a new “feature” I feel like I’m living in a sort of Harrison Bergeron (https://en.m.wikipedia.org/wiki/Harrison_Bergeron) for programmers. I spend the same time fixing bugs in these “safer” languages as I do/did in Python/Smalltalk/Elixir.
Every time Kotlin/Swift add a new “feature” I feel like I’m living in a sort of Harrison Bergeron (https://en.m.wikipedia.org/wiki/Harrison_Bergeron) for programmers. I spend the same time fixing bugs in these “safer” languages as I do/did in Python/Smalltalk/Elixir.
I (and it turns out a lot of other people) used to use "do they code in Python?" as a heuristic for "are they a smart self motivated programmer"
A similar metric you could apply to companies "are they engineering influenced enough to pick a "weird" language". In other words has the company chosen a language on the basis of "we can hire more Java programmers easily" - an awful mindset that suggests all other engineering decisions are a bust.
So yes I agree with your baseless speculation- it's probably less baseless than you are worried about
A similar metric you could apply to companies "are they engineering influenced enough to pick a "weird" language". In other words has the company chosen a language on the basis of "we can hire more Java programmers easily" - an awful mindset that suggests all other engineering decisions are a bust.
So yes I agree with your baseless speculation- it's probably less baseless than you are worried about
In which Paul Graham served to popularize the idea in August of 2004: http://www.paulgraham.com/pypar.html
> I (and it turns out a lot of other people) used to use "do they code in Python?" as a heuristic for "are they a smart self motivated programmer"
Really? It's like asking if something is in the middle of a bell curve, getting an affirmative, and then treating that like an outlier.
Really? It's like asking if something is in the middle of a bell curve, getting an affirmative, and then treating that like an outlier.
Thats where "used to" makes a huge difference. I remember when the industry standard was to use c++ or java. Using a language like python meant that you were "edgy" or "hip." This was back when Paul Graham really started pushing for acceptance of "hacker" languages (like common lisp or python) when ycombinator was just getting started. He did A lot to increase acceptance of languages outside c,c++, java
Now that python is mainstream, other languages stand in to say "I like to learn languages for reasons other than earning a paycheck" examples coming to my mind include Haskell, rust or elixir.
Now that python is mainstream, other languages stand in to say "I like to learn languages for reasons other than earning a paycheck" examples coming to my mind include Haskell, rust or elixir.
This quote was from almost 20 years ago. Python wasn't that popular in the early 00s, although it wasn't exactly obscure.
At the very least, the school I went to in the early 00s didn't have any classes that used Python. And none of my friends learned it from their schools either. The language exposure I got was Java, C, C++, Prolog, Scheme, Perl, Fortran, and ASM. That includes AI and programming paradigms classes.
Nowadays, Python wouldn't be the bar you use.
At the very least, the school I went to in the early 00s didn't have any classes that used Python. And none of my friends learned it from their schools either. The language exposure I got was Java, C, C++, Prolog, Scheme, Perl, Fortran, and ASM. That includes AI and programming paradigms classes.
Nowadays, Python wouldn't be the bar you use.
I (and it turns out a lot of other people) used to use "do they code in Python?" as a heuristic for "are they a smart self motivated programmer"
Well Peter Norvig switch from lisp to Python.., as also others googlers did when they saw that their teammates writing python where as productive or more than themselves using lisp.
Well Peter Norvig switch from lisp to Python.., as also others googlers did when they saw that their teammates writing python where as productive or more than themselves using lisp.
> Peter Norvig here. I came to Python not because I thought it was a better/acceptable/pragmatic Lisp, but because it was better pseudocode.[0]
[0] https://news.ycombinator.com/item?id=1803815
[0] https://news.ycombinator.com/item?id=1803815
Choosing python as your interview language seems like just an unfair advantage at this point.
And then choosing python for complex high performance work seems like asking for a headache at this point.
And then choosing python for complex high performance work seems like asking for a headache at this point.
and then:
In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice.
In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice.
[deleted]
Unless it is and will forever be a very small dev team, choosing a language based on popularity is a great idea. But maybe it depends on what you consider popular. I think Python would qualify.
[deleted]
Python does now, but that particular phrase goes back to a time when python wasn't even close to where it is now.
Choosing a language based on hiring ease is not completely awful. For example where I’m at now we use Go, which is relatively popular, and we’re having an insane time even getting applicants.
I strongly disagree.
Software engineering has changed dramatically over the past 20 years.
Choosing a non-mainstream uses an innovation token on something that does not contribute business value.
That’s a huge red flag.
Software engineering is now a team sport.
Future maintainability and readability is now orders of magnitude more important than nifty tricks when writing the code.
See http://boringtechnology.club/
Software engineering has changed dramatically over the past 20 years.
Choosing a non-mainstream uses an innovation token on something that does not contribute business value.
That’s a huge red flag.
Software engineering is now a team sport.
Future maintainability and readability is now orders of magnitude more important than nifty tricks when writing the code.
See http://boringtechnology.club/
Software engineering has always been a team sport, even though we've known since The Mythical Man Month that throwing more programmers at a problem just slows the work down.
Choosing a non-mainstream language can absolutely contribute business value. For example, toy or tool, making your creation extensible adds value. Multiple businesses have spawned from this, and Lisp and Lua are prime candidates of non-mainstream languages that billion dollar companies have decided to choose to build substantial portions of their products around so that users could extend.
Even someone who doesn't know AutoLISP can look at an AutoLISP script from decades ago and get it within an hour.
For another example, after being scolded for using Unicode to write my overstrikes, I wanted to see how difficult it would be to extend Arc's markdown to add DHTML overstrikes (DHTML and Unicode both have their own ways of doing them). This wasn't hard, despite not being intensely familiar with Arc and pg's programming style being relatively off-beat (Arc is essentially sillyScheme, and he takes full advantage of writing things and defining them later, which is normally easy to cope with but part of the design philosophy of Arc was to minimize syntax, so it sometimes takes longer than you would see in a less holistically-cultivated Scheme). I checked
Choosing a non-mainstream language can absolutely contribute business value. For example, toy or tool, making your creation extensible adds value. Multiple businesses have spawned from this, and Lisp and Lua are prime candidates of non-mainstream languages that billion dollar companies have decided to choose to build substantial portions of their products around so that users could extend.
Even someone who doesn't know AutoLISP can look at an AutoLISP script from decades ago and get it within an hour.
For another example, after being scolded for using Unicode to write my overstrikes, I wanted to see how difficult it would be to extend Arc's markdown to add DHTML overstrikes (DHTML and Unicode both have their own ways of doing them). This wasn't hard, despite not being intensely familiar with Arc and pg's programming style being relatively off-beat (Arc is essentially sillyScheme, and he takes full advantage of writing things and defining them later, which is normally easy to cope with but part of the design philosophy of Arc was to minimize syntax, so it sometimes takes longer than you would see in a less holistically-cultivated Scheme). I checked
(def markdown
... )
> Software engineering is now a team sport.
"Now" meaning since the 1960s (and probably before)?
> See http://boringtechnology.club/
There are plenty of "weird" (in the sense of the parent comment) "boring" (in the sense of the essay you linked [1]) languages out there. Common Lisp and Erlang spring to mind. They are old technologies, and their capabilities and failure modes are well-understood. Maybe not by me and you and the average programmer off the street, but after decades of use, the knowledge is available.
There's also an argument to be had about how much you should value the personal familiarity your team and the people you hire have with the technology. Certainly there's a cost to using unfamiliar technology, and there's a trade-off when choosing between an old, battle-tested, highly capable, but unfamiliar technology and something that is less capable but nearer to hand.
[1] "the capabilities of these things are well understood. But more importantly, their failure modes are well understood" https://mcfunley.com/choose-boring-technology
"Now" meaning since the 1960s (and probably before)?
> See http://boringtechnology.club/
There are plenty of "weird" (in the sense of the parent comment) "boring" (in the sense of the essay you linked [1]) languages out there. Common Lisp and Erlang spring to mind. They are old technologies, and their capabilities and failure modes are well-understood. Maybe not by me and you and the average programmer off the street, but after decades of use, the knowledge is available.
There's also an argument to be had about how much you should value the personal familiarity your team and the people you hire have with the technology. Certainly there's a cost to using unfamiliar technology, and there's a trade-off when choosing between an old, battle-tested, highly capable, but unfamiliar technology and something that is less capable but nearer to hand.
[1] "the capabilities of these things are well understood. But more importantly, their failure modes are well understood" https://mcfunley.com/choose-boring-technology
> Future maintainability and readability is now orders of magnitude more important than nifty tricks when writing the code.
Explain npm, then.
Explain npm, then.
[deleted]
Something poetic about this is that Lisp was the original "AI language", back when AI was more about reasoning and decision trees.
One of the classical books - Artificial Intelligence: A Modern Approach - even uses a robot vacuum cleaner navigating a grid as one of its toy scenarios :)
One of the classical books - Artificial Intelligence: A Modern Approach - even uses a robot vacuum cleaner navigating a grid as one of its toy scenarios :)
How ironic then, because I personally found Roomba robots extremely dumb, until quite recently at least, most of their models roamed randomly, with almost no planning. On the other hand Neato Robots are so much better, they cover the surface width planification and mechanical precision.
Now baseless speculation: I wouldn’t be surprised to learn that a large part of this difference is due to the fact that a company used Lisp because of ideology, while the other company used a language which is actually leading currently in robotics, (c++ or Python) because of practical reasons: they could harness the massive ecosystem to make stuff that are actually useful instead of recoding a robot OS in lisp.
Now baseless speculation: I wouldn’t be surprised to learn that a large part of this difference is due to the fact that a company used Lisp because of ideology, while the other company used a language which is actually leading currently in robotics, (c++ or Python) because of practical reasons: they could harness the massive ecosystem to make stuff that are actually useful instead of recoding a robot OS in lisp.
This isn't just some list someone created once and done. I've been following it for a while and it gets updated regularly every few months with new submissions.
I'd recommend you to follow the repo too if you want to keep up to date.
I'd recommend you to follow the repo too if you want to keep up to date.
Harmonix Music Systems uses a bespoke Lisp-ish language for their game scripting that we call DataArray (or DTA for short) in the Guitar Hero II modding community. It's very powerful to be able to put script in almost any place where a variable or constant is used.
Do people decide to go to work for a company based on the language they'll be working in? Seems like something that should be very far down the priority list?
Yeah, I currently do. I only work with companies who can ensure I get to write and maintain Clojure/ClojureScript projects, or any other lisp-like languages.
Just like I'm sure many people would reject jobs that would force you to write assembly code now when we have higher abstraction languages, I reject jobs that are requiring me to work with inferior languages and ecosystems like Rust, Go or JavaScript. It's simply not worth the frustration anymore.
In the beginning of my career I didn't have the flexibility to choose what languages to work with though, but nowadays I am that lucky.
Just like I'm sure many people would reject jobs that would force you to write assembly code now when we have higher abstraction languages, I reject jobs that are requiring me to work with inferior languages and ecosystems like Rust, Go or JavaScript. It's simply not worth the frustration anymore.
In the beginning of my career I didn't have the flexibility to choose what languages to work with though, but nowadays I am that lucky.
I haven chosen to work for companies where a significant amount of my development output will, in theory, be in Clojure. I do work on private projects where Clojure is less ideal, and avail myself of the breadth available to the python ecosystem for example, but when there the multitudinous shortcomings do not take long to manifest.
> python ecosystem for example, but when there the multitudinous shortcomings do not take long to manifest.
What type of shortcomings? Can you provide some examples?
(The question is coming from someone who wrote a Scheme interpreter in the past, but have been using Python for the last 8 years and haven't touched Lisp in long time).
What type of shortcomings? Can you provide some examples?
(The question is coming from someone who wrote a Scheme interpreter in the past, but have been using Python for the last 8 years and haven't touched Lisp in long time).
How are mentioned three inferior to Clojure and Clojurescript? What if you need performance or a bit less of maximalism in the community... Or even a community at all and libraries and support?
> How are mentioned three inferior to Clojure and Clojurescript?
They are not lisps :)
> What if you need performance
Choose a lisp that gives you performance. Clojure gets you about 80% on the way there, for the rest you can use Common Lisp if you really require performance. I've found that Clojure usually does the trick if you optimize it a bit.
> Or even a community at all
Clojure does have a community, not sure what you mean? There are forums, chats, Q&A sites, blogs, people on Twitter.
> libraries and support?
Plenty of battle-tested libraries with stable APIs, and loads of companies that offer Clojure support (not to mention the great public community that can also help with most if not all questions).
Have you actually used Clojure in any capacity? These points seems to be coming from someone who haven't actually tried to get involved.
They are not lisps :)
> What if you need performance
Choose a lisp that gives you performance. Clojure gets you about 80% on the way there, for the rest you can use Common Lisp if you really require performance. I've found that Clojure usually does the trick if you optimize it a bit.
> Or even a community at all
Clojure does have a community, not sure what you mean? There are forums, chats, Q&A sites, blogs, people on Twitter.
> libraries and support?
Plenty of battle-tested libraries with stable APIs, and loads of companies that offer Clojure support (not to mention the great public community that can also help with most if not all questions).
Have you actually used Clojure in any capacity? These points seems to be coming from someone who haven't actually tried to get involved.
Do you ever miss static typing?
I did, in the beginning. But then I learned better ways of achieving the same guarantees, other methodologies to "prove" (not as in "formal proofs") that my program works as it should. Once Clojure.Spec appeared it was a no-brainer to start using it, and now I want Clojure.Spec in all languages, much rather than static typing.
Go and Lisp have polar opposite philosophies; it makes sense that some developers who like one will be eager to avoid the other.
Clojure has a very strong software community, and find it to be near an ideal size. Tooling is in flux at the moment in the community, and so it has begun to show some of the lack of uniformity that is easy to find in larger ecosystems like python, java, and Appleland etc.
Is lisp really that good? I'm a novice 'tutorials and duct tape' programmer and I've been eyeing SICP lately as a way to hopefully gain confidence in knowing wtf I'm doing.
The heart of it is that you can manipulate the AST as you use it - the structure of the language is itself data which can be acted upon. It makes for good metaprogramming which some people really like.
It's way better than Python (type warnings, speed, expressivity, stability, ease of deployment…). You won't build a web app as fast though. But if you plan to build a software that lasts and is easy to maintain, I'd recommend to give it a try.
It won't give you any magic wand if that's what you expect but SICP is highly recommended.
I also choose to work for companies that use Clojure/Clojurescript. I'm not debating about languages that are better or not, but I get annoyed working in most others.
It may be true that for most high level development a high level programming language will suffice but don't just write off any other languges, because you don't like their ecosystem and/ or design. Languges like C++ or Rust are in no way competing with Clojure since their aims and target market are vastly different. Nobody should write a kernel in clojure, but maybe in rust (Redox) or C++ (Linux).
Please note I said "Clojure/ClojureScript projects, or any other lisp-like languages". I'm in no way limiting myself to just Clojure, any lisp-like language will do, say Common Lisp if performance is needed, ulisp if it has to run on a microcontroller, Babashka/Fennel/Janet if fast startup time is required and so on.
As long as it's s-expressions and interactive development oriented, I'm probably fine with it.
But for the last 4-5 years, I have literally not found a single use case where I'm forced to use C++ or Rust since multiple other (lisp-like) languages has the same target market and the ergonomics are just so much better.
As long as it's s-expressions and interactive development oriented, I'm probably fine with it.
But for the last 4-5 years, I have literally not found a single use case where I'm forced to use C++ or Rust since multiple other (lisp-like) languages has the same target market and the ergonomics are just so much better.
> I have literally not found a single use case where I'm forced to use C++ or Rust
I use C++ to write realtime audio processing applications, especially DAW plug-ins. This is hardly C++'s primary market, but AFAIK there are no lisp-like langauges that can compete with C++ here. I'd be happy to learn something new if this isn't the case!
I use C++ to write realtime audio processing applications, especially DAW plug-ins. This is hardly C++'s primary market, but AFAIK there are no lisp-like langauges that can compete with C++ here. I'd be happy to learn something new if this isn't the case!
Common Lisp performance can be about the same as C++, so performance considerations won't stop you there at least. Common. You can also call C and C++ functions from Common Lisp, so the ecosystem shouldn't stop you either.
It would help if you outlined what's missing from for example Common Lisp in order for it to compete with C++, then maybe I'll be able to give more helpful suggestions that will help you.
It would help if you outlined what's missing from for example Common Lisp in order for it to compete with C++, then maybe I'll be able to give more helpful suggestions that will help you.
Fast is unimportant -- latency and determinism are paramount. It's true that GC'ed languages have been used in realtime applications but it's always an uphill battle. There are also low-latency GCs that are being rolled out. I think there's patent issues there but whatever. Might as well just do resource management at compile time.
The reason people use C/C++ for audio is because a kind of 'soft realtime' performance is required. The thread producing audio cannot block for an unbounded amount of time, ever. If you are late to produce an audio buffer, a nasty audible glitch will be the result. This means no file access, no waiting for mutexes, and certainly no garbage-collection pauses.
This is why managed languages like Lisps are rarely (if ever) used for the DSP in audio applications. I am an audio programmer who loves all things lispy, so believe me, I wish this weren't the case.
This is why managed languages like Lisps are rarely (if ever) used for the DSP in audio applications. I am an audio programmer who loves all things lispy, so believe me, I wish this weren't the case.
I don't understand why you gave the example of C++ (Linux)
Linux is written in C, and, perhaps someday, Rust.
Linus doesn't like C++ and has explicitly objected to, among other things, its enthusiasm for implicit allocation. Rust's implicit allocation all lives in libraries and so the Rust for Linux project ripped that out.
Linux is written in C, and, perhaps someday, Rust.
Linus doesn't like C++ and has explicitly objected to, among other things, its enthusiasm for implicit allocation. Rust's implicit allocation all lives in libraries and so the Rust for Linux project ripped that out.
low_common(2)
preseinger(1)
I seek out companies using niche languages not because I necessarily care about that specific language, but because I find that companies that are willing to work with niche tech tend to be more fun to work for. Typically if you're a Haskell or F# developer, then you probably are at least a little interested in theory and mathematics. Since I'm also interested in theory and math, there's a selection bias of "folks I am extremely likely to get along with".
With a more mainstream language like Java, you're not necessarily going to select for that trait. This isn't to knock Java engineers, since I know a ton of Java engineers much smarter than me, but that fact that Java (JavaScript/Python/C#/any-other-mainstream-language) is popular means that a lot of people learn it because there's a lot of jobs in it and/or it pays well. There's nothing wrong with using a language that makes you money obviously, and there's nothing wrong with liking Java, but as a perpetual-geek I am certainly less drawn to "Java Shops".
With a more mainstream language like Java, you're not necessarily going to select for that trait. This isn't to knock Java engineers, since I know a ton of Java engineers much smarter than me, but that fact that Java (JavaScript/Python/C#/any-other-mainstream-language) is popular means that a lot of people learn it because there's a lot of jobs in it and/or it pays well. There's nothing wrong with using a language that makes you money obviously, and there's nothing wrong with liking Java, but as a perpetual-geek I am certainly less drawn to "Java Shops".
At 62, I'd probably work for free for a company that used Common Lisp and had half a clue.
I'll bite! Drop me a note. Let's find out if I have a clue.
I hope that you'll pay him. If you don't it will be an indication of lack of clues
But of course. I realize the use of "probably work for free" should not be taken literally. It does show that he(?) places value on other aspects of work rather than making a high salary performing joyless tasks
I have been in the fortunate position of being able to provide employment to others (and myself) in several companies. I don't exploit people, I offer wages as competitive as possible, I hire people from non-traditional backgrounds and mentor employees who probably would not get the attention of other large tech companies.
I am not a saint and admit I may be clueless about some things. Providing a workplace that is safe, free of discrimination, rewards people for hard work and supports those who are in need of help are areas I think I do have a clue about.
I have been in the fortunate position of being able to provide employment to others (and myself) in several companies. I don't exploit people, I offer wages as competitive as possible, I hire people from non-traditional backgrounds and mentor employees who probably would not get the attention of other large tech companies.
I am not a saint and admit I may be clueless about some things. Providing a workplace that is safe, free of discrimination, rewards people for hard work and supports those who are in need of help are areas I think I do have a clue about.
Hello -- I did just send an email. I would enjoy a relaxed discussion.
[deleted]
Why? The things people often list above language are table stakes. I wouldn't give up a high salary to work in Clojure for a low salary, but that's not a choice you have to make. I wouldn't give up interesting problems, fully paid insurance, a good team, 4+ weeks of vacation, etc but again I don't have to give up any of those to work in Clojure. The choice isn't some ideologically pure Clojure startup scraping by versus proper pay + benefits at a large enterprise.
If you're doing application development, it's nice to have a language that truly cares about backwards compatibility and interoperability with a common platform. It means I can focus on solving problems and not incidental complexity. I can easily hack Clojure from the comfort of a pom.xml if necessary.
I'm not working in Clojure right now because I found interesting work outside of application development, but when I was last looking in 2018, I could get roughly all of the things I wanted from a job and still hack Clojure from a CIDER REPL in Emacs all day.
If you're doing application development, it's nice to have a language that truly cares about backwards compatibility and interoperability with a common platform. It means I can focus on solving problems and not incidental complexity. I can easily hack Clojure from the comfort of a pom.xml if necessary.
I'm not working in Clojure right now because I found interesting work outside of application development, but when I was last looking in 2018, I could get roughly all of the things I wanted from a job and still hack Clojure from a CIDER REPL in Emacs all day.
Yes, people want to work with technologies they enjoy, therefore doing work they enjoy.
Yes, I do. Just because I know how to speak/write some language I don't have to love it. And I rather do something I enjoy than dragging myself to work every day. Increased productivity is just a corollary. (I'll still accept a java gig, but the salary must make up for the daily misery).
They certainly can decide where not to work based on this. Many years ago I had a conversation with IMDB and ran for the hills when I found out the used Perl.
Yup, I applied to and worked for one of the companies on this list purely because they were using Common Lisp.
fairly high up the list for me. If there were more/any F# jobs around here I'd happily apply. Come to like the language a lot.
yes. in fact, startups use this property to their advantage in recruiting by adopting a niche technology stack to hire talented engineers that want to solve problems using that tech stack.
I once did the opposite: I thought that technology details don't matter if the company is good in other ways. Did the mature thing, so to speak.
I was wrong and the company was the worst professional experience of my ~20 year career. Now I vet my future employers' tech stack before signing any papers. It doesn't have to perfect (that's what I often come there to improve) but it has to be not shit, and they have to accept that fundamental problems need to be fixed.
I was wrong and the company was the worst professional experience of my ~20 year career. Now I vet my future employers' tech stack before signing any papers. It doesn't have to perfect (that's what I often come there to improve) but it has to be not shit, and they have to accept that fundamental problems need to be fixed.
Tangentially. Every job posting is about "5+ years experience in language x, y, and z"
So it's very hard to land a job in a language I don't know. It's all pretty stupid, for the most part any software engineer can pick up any new language pretty quickly when working 9 hours a day on it. The language is the easy part of comp sci.
I'd love to take a job in Android or web development but I just don't have experience so I don't get interviews.
So it's very hard to land a job in a language I don't know. It's all pretty stupid, for the most part any software engineer can pick up any new language pretty quickly when working 9 hours a day on it. The language is the easy part of comp sci.
I'd love to take a job in Android or web development but I just don't have experience so I don't get interviews.
I may have passed up on an opportunity because a company used Perforce instead of Git at some point, though memories that old are unreliable at best.
> Seems like something that should be very far down the priority list?
Not entirely. It's a proxy - and a window - on the company culture.
Not entirely. It's a proxy - and a window - on the company culture.
When you start a job, you are a noob from the perspective of processes, frameworks, paradigms, and current codebase.
You're most susceptible to intellectual bullying in this stage. It's really what makes switching jobs the worst part in programming: you look like an idiot no matter what the first week or two, and are completely at the mercy of your manager and team culture to sink or swim.
Add a new language as ammunition to be intellectually bullied? No thanks.
You're most susceptible to intellectual bullying in this stage. It's really what makes switching jobs the worst part in programming: you look like an idiot no matter what the first week or two, and are completely at the mercy of your manager and team culture to sink or swim.
Add a new language as ammunition to be intellectually bullied? No thanks.
I do. I’m trying to transition out of development and into management. The last thing I want to do is leave behind the place I’ve called home for the last 10 years, abandoning all the headaches from the language’s subtleties in the process. I’m proficient in enough and have contributed (reasonably) to production-level systems in many, but that doesn’t mean I enjoyed them as much as I do my mainstay.
[deleted]
Functional fanatics are totally the kind of people who seek out teams or spaces for a specific language.
I stay away from those people, not going to lie.
I stay away from those people, not going to lie.
It's my only priority...
Every place I've worked at, I only applied after asking a) what language do they use b) is it technically cool.
Every place I've worked at, I only applied after asking a) what language do they use b) is it technically cool.
I think there's a little-discussed connection between dev happiness and motivation/productivity. I for one am much more driven when I feel good about the thing I'm producing, and the language it's written in has a big impact on that.
If I was offered a job with great pay, benefits, and company culture, but all of my programming would need to be done in brainfuck, I'd probably turn it down.
Eh, surely you'd just build a brainfuck transpiler in lisp and coast
(parody) Ugh, nobody would want to touch that unreadable machine-generated crap...
What programming languages do you know? Do you prefer any one of them?
many companies require certain expertise in a specific language
just seems like a promising avenue to one day actually getting a job!
No, it is a warning sign if Lisp, VB6, Cobol or similar is used. ;)
Edit: Just to clarify, the comment was a joke but yes, devs for sure reject jobs at prominent workplaces because of tech. I myself know a highly attractive workplace that want me to join but I won't because I don't believe in their tech stack.
Edit: Just to clarify, the comment was a joke but yes, devs for sure reject jobs at prominent workplaces because of tech. I myself know a highly attractive workplace that want me to join but I won't because I don't believe in their tech stack.
does clojure count?
if so, nubank (brazilian fintech) would be one of the biggest one.
they even bought cognitect https://www.cognitect.com/blog/2020/07/23/Cognitect-Joins-Nu...
if so, nubank (brazilian fintech) would be one of the biggest one.
they even bought cognitect https://www.cognitect.com/blog/2020/07/23/Cognitect-Joins-Nu...
How much commercial use do Prolog or other logic programming languages see these days? The impression I seem to get is that Prolog, while never exactly mainstream, had a much more significant commercial foothold 30 or even 20 years ago than it does now; but I don't know if that's accurate.
It is a very short list. I wonder why Lisp has completely failed to be successful given the usual fan claims that it is more powerful, more productive, more everything than any other languages? The usual claim by Lisp fans that only a few blessed people are smart enough to understand and use Lisp is beyond ridiculous. I learned Common Lisp, Scheme and Clojure just for fun, and implemented my own Lisp variations (including macros) in both C++ and Haskell. Lisp languages are easy to learn and use. However I would never use a Lisp for production work. I absolutely could. However I simply prefer languages like C++, Typescript and Haskell. So my guess is that people are different, people’s brains work differently, and for whatever reasons Lisp appeals to certain personality types and not others. And it just happens to be that the personally/brain types that prefer Lisp is a minority. It could have been the other way around of course but it just isn’t. I haven’t been able to come up with any other explanation that seems to be even remotely plausible.
My personal thought on the why it isn't popular is the fact Common Lisp has multiple implementations. Which one do I pick? What are the differences? What's the compatibility like should I decide to switch to another implementation? Experienced common lisp users will know the answer but try and get a manager or leader with no experience to spend time trying to understand/read about all these things when simpler/easier choices that work the traditional way exist. This can apply to scheme to some extent as well.
I really like Lisp. I also have the impression that the people talking about Lisp a lot are writing far more prose than code. There are maybe 10 exceptions to this, those being Nikodemus, Shirakumo, Stylewarning, Christian Schafmeister, Borodust, and some others. It's a really cool group -- everyone is super nice and very productive and generally helpful.
That said, there's a nostalgia for this language that I wish we could do away with. If people would just shut up and write Lisp and so we can have a healthier library ecosystem, or just shut up and not, I think we'd be in a better place. If it's so productive, where's all the fruits of that productivity (outside of the list of people I mentioned?)
Also FFS, and I rant about this once every 4 months, LispWorks pricing structure just makes me angry every time I think about it -- and I've heard all the excuses, some make more sense than others, but they do nothing to make me less angry.
That said, there's a nostalgia for this language that I wish we could do away with. If people would just shut up and write Lisp and so we can have a healthier library ecosystem, or just shut up and not, I think we'd be in a better place. If it's so productive, where's all the fruits of that productivity (outside of the list of people I mentioned?)
Also FFS, and I rant about this once every 4 months, LispWorks pricing structure just makes me angry every time I think about it -- and I've heard all the excuses, some make more sense than others, but they do nothing to make me less angry.
I am pretty sure there is no "UmeÃ¥" or "UmeÃ¥ University" in Sweden. It does look like a mojibake of Umeå, which does have a university.
HexstreamSoft probably shouldn't be there. I don't think it is a registered company
HexstreamSoft is one guy who decided to piss off just about everyone he could in the Lisp community, then his Twitter account got locked and everyone stopped caring.
yes he engaged in some unwarranted personal attacks. i actually hope he is ok though. he seemed like a passionate guy just very misguided. my point about raising this is just to have a high barrier for appearing in that list. i otherwise enjoy the list alot
Is Clojure not considered a true lisp?
It's kind of a boring and tired point, but for another perspective on "is X a Lisp?" it's worth reviewing the Lisp 1.5 manual from 1962: http://www.softwarepreservation.org/projects/LISP/book/LISP%...
Consider the program at the bottom of page 29 that calculates the length of a list. What's the delta to get it to run in X? In Clojure, quite a lot of modification is needed. Scheme, slightly less. Common Lisp though, all you have to do is change the archaic top-level "DEFINE (( (LENGTH ..." to "(defparameter LENGTH...", and "ADD1" to "1+", and to call it change "LENGTH ((A B C D))" to "(LENGTH '(A B C D))", similar for "LENGTH (((X . Y) A CAR (N B) (X Y Z)))". The features of cons cell lists (including the syntax (X . Y)), lambdas, PROG, setq, labeled gotos, and even being able to use SHOUTING names if you want, have all been retained throughout the decades.
The program from 48-51 works as an example too. Here's a small driver someone wrote in CL to run it without having to modify it: http://www.informatimago.com/develop/lisp/com/informatimago/... One notable feature is that of being able to TRACE a function, which is quite handy, and is retained in modern Lisp systems. You could write such a driver in any language, sure, but it wouldn't be as small and simple in anything but Common Lisp, because so many of the functions in Appendix A have been carried forward through history with many Lisps until Common Lisp, so you can just pass them through to the base Lisp, no need to remap and wrap things/write a small interpreter like you would in Clojure/Scheme. A language that just ignores all of that history and makes no attempt to be backwards compatible with any of it can't be considered a "true Lisp", even if it shares other Lispy features.
But again, it's a tired argument, and whether someone disagrees isn't very important. To me, Clojure is a Lisp-inspired language (like so many others, e.g. Julia), and is attractive on its own merits, without having to crib the good name of Lisp.
Consider the program at the bottom of page 29 that calculates the length of a list. What's the delta to get it to run in X? In Clojure, quite a lot of modification is needed. Scheme, slightly less. Common Lisp though, all you have to do is change the archaic top-level "DEFINE (( (LENGTH ..." to "(defparameter LENGTH...", and "ADD1" to "1+", and to call it change "LENGTH ((A B C D))" to "(LENGTH '(A B C D))", similar for "LENGTH (((X . Y) A CAR (N B) (X Y Z)))". The features of cons cell lists (including the syntax (X . Y)), lambdas, PROG, setq, labeled gotos, and even being able to use SHOUTING names if you want, have all been retained throughout the decades.
The program from 48-51 works as an example too. Here's a small driver someone wrote in CL to run it without having to modify it: http://www.informatimago.com/develop/lisp/com/informatimago/... One notable feature is that of being able to TRACE a function, which is quite handy, and is retained in modern Lisp systems. You could write such a driver in any language, sure, but it wouldn't be as small and simple in anything but Common Lisp, because so many of the functions in Appendix A have been carried forward through history with many Lisps until Common Lisp, so you can just pass them through to the base Lisp, no need to remap and wrap things/write a small interpreter like you would in Clojure/Scheme. A language that just ignores all of that history and makes no attempt to be backwards compatible with any of it can't be considered a "true Lisp", even if it shares other Lispy features.
But again, it's a tired argument, and whether someone disagrees isn't very important. To me, Clojure is a Lisp-inspired language (like so many others, e.g. Julia), and is attractive on its own merits, without having to crib the good name of Lisp.
Clojure is a lisp-1, but its design favors immutable data structures and attendant functional forms. These design choices do have detractors in the various lisp communities.
Scheme shares the attributes you mentioned.
Or even more so, Racket.
There are purists who don't consider Racket or even Scheme to be Lisps, either. FWIW, I do not agree with them (I also consider Clojure a Lisp), but they exist.
There's a certain highly vocal contingent of Lisp fans who consider the Common Lisp spec to be some kind of sacred document, and that anything that's been invented in the past 37 (!) years is useless.
IMO, those people have done far more harm than good for Lisp and Lisp-like languages.
And yeah, there's a lot of the same religion-like purity around Rust nowadays.
There are purists who don't consider Racket or even Scheme to be Lisps, either. FWIW, I do not agree with them (I also consider Clojure a Lisp), but they exist.
There's a certain highly vocal contingent of Lisp fans who consider the Common Lisp spec to be some kind of sacred document, and that anything that's been invented in the past 37 (!) years is useless.
IMO, those people have done far more harm than good for Lisp and Lisp-like languages.
And yeah, there's a lot of the same religion-like purity around Rust nowadays.
Same thing with Haskell, in the last month I had a few people argue with me that if a language isn't Haskell, it's not functional programming.
I've talked to several people who equate fp with "advanced type system" and not "programming by function composition" (which for me is the correct definition).
Composition is table stakes now, I’d say pure functions (no side effects) are what make FP important with or without types.
I think the focus on "pure functions" is a bit Haskell-centric, as those are the guarantees that Haskell gives easily, but that's it. For example, Koka has total functions (https://koka-lang.github.io/koka/doc/book.html#why-effects), which gives more guarantees that pure functions. Lack of side effect is, I think, a side effect of searching for greater function composition. The goal of purity is to make functions easier to compose after all.
Well, you can still have pure functions without having an effects system. It just isn't checked. I think that's generally part of the mark of functional programming. If you do have side effects in some parts of the program then that part would be not functional.
That could be useful. Does Koka reject a total function that might not always terminate, or trust the author?
From what I understand, Koka relies on inference, so for example a function with a "while" or a recursive call will be marked as "div". I think the goal is to have the precision of Haskell, and even better, but without forcing the use of monads or something like that.
Most important distinction - out of all Lisps, only in Clojure it is encouraged to use primitive types directly. Higher level abstractions, "inventing your own languages" are considered as a bad style.
yeah but this list was started for CL. At that time we only had http://pchristensen.com/blog/lisp-companies/, and people giving the same 3 examples. Clojure always had good promotion and it already has https://clojure.org/community/companies
[deleted]
Great idea! Would love to see a list of companies using Smalltalk extensively. :)
I actually saw one of the few commercial Smalltalk vendors hiring a while back. Though, it seemed like it was less writing smalltalk and more building the underlying platform.
maybe this https://nyxt.atlas.engineer/ could belong there ?
Odd that AutoDesk isn't on here, since I got into programming Lisp when trying to automate AutoCAD.
No mention of GOAL, Naughty Dog's Lisp dialect used for game scripting?
I feel like Clojure companies should be on here too as it is very much a LISP
> This list intended only for company with Common Lisp and Scheme usage
Debate aside, this group seems to be fairly explicit about their intent.
Here's an issue where they discussed the decision recently: https://github.com/azzamsa/awesome-lisp-companies/issues/43.
Debate aside, this group seems to be fairly explicit about their intent.
Here's an issue where they discussed the decision recently: https://github.com/azzamsa/awesome-lisp-companies/issues/43.
> This list intended only for company with Common Lisp and Scheme usage
I remember reading somewhere that user-generated tags were a good idea, even if there are some "synonims", because people that talk about "films" and people that talk about "cinema" clearly don't want to spend time together. I think it's the case here. People that want to exclude anything that's not Scheme or Lisp aren't going to be convinced.
I remember reading somewhere that user-generated tags were a good idea, even if there are some "synonims", because people that talk about "films" and people that talk about "cinema" clearly don't want to spend time together. I think it's the case here. People that want to exclude anything that's not Scheme or Lisp aren't going to be convinced.
If you hang around here long enough, you get to see people insisting on pretty much anything being a Lisp.
[deleted]
There are a lot of people who would debate that point. There are even some fairly common macros that are used when this comes up. My favorite is this one:
«I find Clojure revolting.
It is the most explicit to date abandonment of the age-old Lispers' Dream, "Lisp All The Way Down." Clojure is the antithesis of the Lisp Machine. Instead of a crystalline pyramid of comprehensible mutually-interlocking concepts, behind every Clojure primitive there lurks Black Magic. The Clojure user who is missing some routine or other will run crying to Java for help, rather than implementing the feature himself correctly - that is, as a natural part of the entire language, built on the same concepts. Clojure pisses on everything I've ever loved about Lisp.
Clojure is the False Lisp, which Reeketh of the Cube Farm. A Lisp unworthy of the name; one which encourages users to pepper their code with calls to opaque routines having no underlying Lispiness. A Lisp which barfs Java stack traces. It promotes - no, mandates - the use of undigestable foreign matter in Lisp code: primitives on which you cannot pop the hood to reveal intelligible innards.
The cult of Good Enough which seems to pervade all of modern computing has finally chewed its way through to the Lisp community, with Clojure as the result. I am tired of this abomination being hailed as the future of Lisp. Aficionados of real Lisps, such as myself, will keep hoping, dreaming, and working on systems which do not betray the original virtues of the language.»
«I find Clojure revolting.
It is the most explicit to date abandonment of the age-old Lispers' Dream, "Lisp All The Way Down." Clojure is the antithesis of the Lisp Machine. Instead of a crystalline pyramid of comprehensible mutually-interlocking concepts, behind every Clojure primitive there lurks Black Magic. The Clojure user who is missing some routine or other will run crying to Java for help, rather than implementing the feature himself correctly - that is, as a natural part of the entire language, built on the same concepts. Clojure pisses on everything I've ever loved about Lisp.
Clojure is the False Lisp, which Reeketh of the Cube Farm. A Lisp unworthy of the name; one which encourages users to pepper their code with calls to opaque routines having no underlying Lispiness. A Lisp which barfs Java stack traces. It promotes - no, mandates - the use of undigestable foreign matter in Lisp code: primitives on which you cannot pop the hood to reveal intelligible innards.
The cult of Good Enough which seems to pervade all of modern computing has finally chewed its way through to the Lisp community, with Clojure as the result. I am tired of this abomination being hailed as the future of Lisp. Aficionados of real Lisps, such as myself, will keep hoping, dreaming, and working on systems which do not betray the original virtues of the language.»
All: please let's not do programming language flamewar here. I realize this is just a quote, but such things are activating and we all need to just not take the bait.
This sort of hyper-rant did years' worth of damage to the CL community and I'd especially not like to see HN be a vehicle for its return. As for Clojure, Rich knows at least as much as the rest of us do about the design tradeoffs it took to get a viable Lisp on the JVM.
This sort of hyper-rant did years' worth of damage to the CL community and I'd especially not like to see HN be a vehicle for its return. As for Clojure, Rich knows at least as much as the rest of us do about the design tradeoffs it took to get a viable Lisp on the JVM.
Even pg participated in Lisp flaming; what he said about newLISP on LtU, for example. It's tradition!
But yes, Lisp flamewar is not very productive. I do think there's a debate to be had as to whether or not Clojure is a Lisp, though, and the quote was offered to give a humorous example of a macro posted by people who are against Clojure in it, since stelcodes seemed to be unaware.
But yes, Lisp flamewar is not very productive. I do think there's a debate to be had as to whether or not Clojure is a Lisp, though, and the quote was offered to give a humorous example of a macro posted by people who are against Clojure in it, since stelcodes seemed to be unaware.
Nice to see software language purists who are not assembly-line stamped Haskellteers fresh out of college. But the fact that they appear unable to see the beauty implied by `/usr/bin/env bb` or `shadow-cljs publish`, suggests to me that they don't recognize the implications of clojure and deep, modern software ecosystem interoperability.
I think most of the people who spam the macro are Emacs Lisp and CL users, so while in the Emacs case they might not understand modern software ecosystem interoperability, they definitely understand deep software ecosystems.
But the fact that they appear unable to see the beauty implied by `/usr/bin/env bb` or `shadow-cljs publish`
lol, what beauty are you referring to with those two?
Sorry but you aren't any different.
lol, what beauty are you referring to with those two?
Sorry but you aren't any different.
Can you clarify what number you mean by “a lot” and/or cite some research to corroborate this claim?
You quote one article [0], which has been received by the Clojure community with almost unanimous disagreement, as the author himself acknowledges (in less than friendly words).
That article in turn contains little factual information and lots of expressive verbiage. In my experience, this opinion is very much in the minority, albeit a vocal one.
[0]: http://www.loper-os.org/?p=42
You quote one article [0], which has been received by the Clojure community with almost unanimous disagreement, as the author himself acknowledges (in less than friendly words).
That article in turn contains little factual information and lots of expressive verbiage. In my experience, this opinion is very much in the minority, albeit a vocal one.
[0]: http://www.loper-os.org/?p=42
I quoted a macro that gets spammed on discussion forums. Of course it isn't popular with Clojurists, it mocks them. The origin article is irrelevant. If you copy and paste that paragraph into a search engine, you'll find it on multiple discussion forums.
Go to just about any Lisp forum that isn't explicitly for Clojure, and you'll find people hating on Clojure. Hating on Clojure and hating on newLISP are the only two things that Lisp users can agree on. I like both of them (though I like Clojure a lot less), but I find the slander hilarious and can understand why people disagree that they're real dialects.
Go to just about any Lisp forum that isn't explicitly for Clojure, and you'll find people hating on Clojure. Hating on Clojure and hating on newLISP are the only two things that Lisp users can agree on. I like both of them (though I like Clojure a lot less), but I find the slander hilarious and can understand why people disagree that they're real dialects.
Wow that’s fascinating. I’m glad I care more about building software than language purity
Heh
The impression I gathered from last decade's flirtations with Lisp is that the choice between Clojure and Common Lisp is mostly a choice between whether the code you ultimately call that Gets Stuff Done will be C or Java
The impression I gathered from last decade's flirtations with Lisp is that the choice between Clojure and Common Lisp is mostly a choice between whether the code you ultimately call that Gets Stuff Done will be C or Java
whoever wrote that has never finished or contributed substantially to a project.
This is exactly the kind of closed thinking that is luckily absent from Clojure and the Clojure community and one of the reasons I'd prefer it over any lisp.
[deleted]
How irritating, when people want to talk about things made in Lisp-the-language, and people instead come around to debate Lisp-the-religion.
I think it's hilarious, personally, and I'd disagree that the two are meaningfully distinct.
Acting like any language that makes use of parentheses is a Lisp is similar to the Diogenes plucked chicken allegory. There are a lot of ways in which Clojure clucks like a chicken, to put it in terms of the metaphor. There is definitely room for a debate.
It's like calling Postscript meaningfully a Forth just because the syntax is superficially the same. There's certainly someone in this thread who could give a good thousand word comment on that.
Acting like any language that makes use of parentheses is a Lisp is similar to the Diogenes plucked chicken allegory. There are a lot of ways in which Clojure clucks like a chicken, to put it in terms of the metaphor. There is definitely room for a debate.
It's like calling Postscript meaningfully a Forth just because the syntax is superficially the same. There's certainly someone in this thread who could give a good thousand word comment on that.
The almost total lack of large, accomplished companies in this list is the biggest red flag anyone needs.
Bit chicken and egg -- nobody uses it because nobody writes it. I think once in a while a small team of aficionados will write a project in it and then eventually rewrite as it becomes evident that it's too hard to hire for. At least this is what Reddit did.
If you're the one person responsible for the project and are not super worried about people picking CL up, then I think CL fans will go for it. That's what Robert/stylewarning did at HRL and Rigetti and he says it's worked well.
If you're the one person responsible for the project and are not super worried about people picking CL up, then I think CL fans will go for it. That's what Robert/stylewarning did at HRL and Rigetti and he says it's worked well.
All quantum computing companies, Google, Boeing, big industry players… besides, this list is fan-cooked. We add one when we see a job announce or a word on social media.
BTW, nothing stops me from enjoying Lisp's powers for my small business even if my favorite big company doesn't use it.
BTW, nothing stops me from enjoying Lisp's powers for my small business even if my favorite big company doesn't use it.
Possibly relevant: https://blog.gardeviance.org/2015/03/on-pioneers-settlers-to...
Is it relevant that it’s written in a lisp? Probably not. But then, maybe. Baseless speculation: mine pre-dates their internet connected models, which means it’s 100% plug and play. The only possible config is the system clock and the startup schedule, and I’m just using what the prior owner had already set. Had the OS been written in a more traditional language perhaps the engineers would have been tempted to include all the modern IOT features from the start and the result would be the complex app-driven network-needing mess that so many products tangle themselves up in (including perhaps the modern Roombas).
Again, that’s all baseless speculation, but I do see a potential connection between folks who choose to code a robot in lisp and folks who eschew “sugar” features in favor of the most pure “do one thing and do it better than anything else” implementation.