Companies that use Lisp extensively
github.com
github.com
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.
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...
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
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.
Explain npm, then.
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
... )
"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
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.
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.
And then choosing python for complex high performance work seems like asking for a headache at this point.
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.
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.
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.
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 :)
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.
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...
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.
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.
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.
Of course everyone thinks they’re a superstar, but they’re probably not. I know I ain’t.
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.
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.
I'd recommend you to follow the repo too if you want to keep up to date.
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.
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.
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.
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 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!
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.
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.
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.
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).
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.
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".
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.
I stay away from those people, not going to lie.
Not entirely. It's a proxy - and a window - on the company culture.
Every place I've worked at, I only applied after asking a) what language do they use b) is it technically cool.
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.
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 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.
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...
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.
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.
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.
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.
«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.»
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.
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.
lol, what beauty are you referring to with those two?
Sorry but you aren't any different.
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.
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.
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.
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
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'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.
BTW, nothing stops me from enjoying Lisp's powers for my small business even if my favorite big company doesn't use it.