5 ms·
Speaking impersonally, and not directly to OP, you can program in Common Lisp in industry, you just don’t want to that badly, and then you justify why you can’t
by reikonomusha 5y ago
Speaking impersonally, and not directly to OP, you can program in Common Lisp in industry, you just don’t want to that badly, and then you justify why you can’t by making up reasons about not being able to hire, not being mainstream, not finding jobs, etc. etc.
Somehow, I’ve been able to keep stable employment as a programmer that writes Lisp for over a decade. I’ve written Lisp at startups. I’ve written Lisp at Facebook. No, I haven’t been a consultant on some weird legacy Lisp project either. The difference between me and someone who doesn’t have a career in Lisp is:
- I choose Lisp for projects that benefit from Lisp;
- I make the case to technical and non-technical people that I can solve their problem cheaply and efficiently, often with a concrete demo and without any of the vague promises of Lisp’s power;
- I put in extra effort to make sure we can hire for Lisp, train for Lisp, and integrate with Lisp.
If you want to write Lisp in industry, and if you’re a senior-or-greater engineer (whatever that means), then get some buy-in and write it. Learn the language backwards and forwards, and be responsible and accountable for your choice.
Unless you’re writing the world’s most boring software that needs 5,000 Java programmers all working on it at the same time, I can assure you, there is no issue with writing and maintaining Lisp, unless everybody you work with, including yourself, likes to pass the buck.
- bitwize 5y agoHow about if your company decides the approved languages are X, Y, and Z, and Lisp is not among them? Such companies exist. I work for one. (They are currently discussing removing JavaScript from the approved languages list because its dynamic typing makes it unsafe at any speed. TypeScript is the approved substitute.) If you cannot get higher-up buy-in to support your chosen language and train new programmers in it, then it doesn't matter how much of a practical advantage your solution in that language provides -- continuing to code in that language is a fast track to getting PIP'd.
- reikonomusha 5y agoIf you can’t get buy-in, you can’t get buy-in. Some companies won’t allow you to write whatever you want, Lisp or otherwise. I don’t suggest writing Lisp is possible anywhere, just that it’s perfectly attainable and within one’s power to have a career of which Lisp is a significant part if you decide that should be a priority. If working at $COOL_COMPANY that only allows Python due to CTO-mandated policy is your priority, then there’s not much that can be done to accomplish that and writing Lisp. Sometimes, also, you have to be more persuasive than “let’s use lisp it’s cool”. Implement a piece of code as a side project that solves a real problem that people care about at your company. Don’t shove it in people’s faces or rogue commit it to production. Ask people about it and have a plan to integrate it and support it. Sometimes it works. Sometimes it doesn’t. As professional software engineers, our job is to solve technical software problems in exchange for a wage. Some of these technical problems come in the form of giant pieces of software that you’re asked to chip away at. Others come in the form of greenfield implementation work. Some are somewhere in between. Some of these projects have 2 programmers, and others 2,000. Where on these spectra you’re being paid to contribute makes a lot of difference in how much sway you have for foundational technological choices on specific projects.
- bitwize 5y ago> Implement a piece of code as a side project that solves a real problem that people care about at your company. Yeah, been there, done that, got in trouble for it. I suspect it's that way at most companies.
- deleted 5y ago[deleted]
- parafactual 5y agoWhy did you get in trouble? (That is, what was the stated reason)
- kingaillas 5y agoA colleague implemented a small utility in Clojure (~50 lines long) that worked great. It led to a mandate that allowable languages are: C/C++, C#, Python. The colleague left 4-5 years ago for an external job. Part of the problem was the utility needed some enhancements/extensions and nobody wanted to continue it in Clojure. I think it was rewritten as an overhaul/revamp of the larger project it was part of. I also left but for a different internal position where I can write C/C++, Java, Rust, Python (no C# in new group because new job is writing software to run on linux, and our IT does not support dotnet core - in addition there is no demand from us because we have a zillion lines of code all written before any dotnet on linux existed). EDIT: Old group can use C# because that work was on Windows (just to clarify C# wasn't dropped company wide). Anyway, some orgs might be more receptive to "exotic" languages but I know where I work you'd have to fight really hard to do it. I was pleasantly surprised to see Rust got the thumbs up.
- nuclearnice3 5y agoInspiring stuff. What is the favorite Lisp platform of the moment? Say you want to integrate with a Linux-Python-AWS shop if that matters. Any external API -- crypto, aws, json -- we'd love to have it in Lisp natively, but whatever we'll wrap the c lib via FFI.
- reikonomusha 5y agoFor the work I do, I use - SBCL as the compiler - Emacs and SLIME for the editor/IDE - Quicklisp for package management - SBCL’s built-in static executable compiler for deployment, or sometimes docker if that happens to be more convenient - Practical Common Lisp for training; Paradigms in AI Programming for taking a trained Lisp programmer “minting” a better Lisp programmer For individual libraries, there are too many to name. I like yason for JSON, Hunchentoot for web servers, Postmodern for Postgres/SQL, cl-sqlite for SQLite, fiasco for testing, etc.
- sillysaurusx 5y agoYou could go the opposite route, and run Lisp in your favorite language. Here's a Lisp in JavaScript and Lua: https://github.com/sctb/lumen https://github.com/sctb/lumen Integration is easy because there's no integration. You can just call whatever functions you'd normally call.
- gilch 5y agoHere's a Lisp in Python: https://github.com/gilch/hissp https://github.com/gilch/hissp
- nuclearnice3 5y agoThis embedding idea has potential. On a related note, I enjoyed these Peter Norvig essays on writing a LISP in Python. https://norvig.com/lispy2.html https://norvig.com/lispy2.html
- reikonomusha 5y agoIt’s really a shame that “lisp” is such a generic term, because different lisp dialects have wildly different programming experiences. Common Lisp, which is what I generally mean when I say “Lisp” can be embedded in any language that speaks C with Embeddable Common Lisp.
- nnadams 5y ago> I choose Lisp for projects that benefit from Lisp Are there any examples you have of projects or types of problems that benefit from Lisp? I've been "learning" Lisp on and off for a while, but I always end up going back to more familiar languages.
- reikonomusha 5y agoIt’s hard to be categorical but for me: compilers, mathematical software, autonomous or long-running software, high-performance code, data structure-heavy code. Some of my former colleagues might try to convince you Lisp is a great choice as a backend language. I agree that it’s a great choice in isolation, but I don’t have tons of experience using other tech to build extensive APIs with tons of layers. A little more meta, but Lisp can be a great choice if a project can only afford a handful of developers. Lisp can give you the “bang for buck” in terms of code output/productivity and comprehensiveness of the solution to a problem.
- agumonkey 5y agosome quantum computing lab made a lisp thing for their needs to me the value of lisp is that everything is almost fully open beyond the primitive bits (if, cons, atoms, native types ...) all the rest is customizable so if you need something deeply new and deeply alien .. you'll have near zero resistance from lisp
- Kototama 5y agoYou must have really good rhetorical skills besides your technical skills. How many managers are apriori opened to use a tech that they think stopped in the 80s?
- canadianfella 5y ago> apriori opened *open
- mikelevins 5y agoI generally agree, though I would highlight a remark you made in another comment that sometimes you just can't get buy-in. I'd go a little further: sometimes you're working with a team whose leaders are dyed-in-the-wool anti-Lispers. But if you really want to work in Lisp, then you can. This is my thirty-fourth year of work as a programmer and technical writer. Of those years, I've been paid to work in Lisp for about twenty of them, so it can certainly be done--though you have to be patient and work in something else sometimes. If you want to be a Lisp hacker, learn another language well for those times when you're waiting for the right opportunity. C is generally a good choice; among other things, it's a common compilation target or kernel-implementation language for Lisps. I also agree that you can teach Lisp to capable programmers without much trouble, but with the caveat that they have to want to learn it. Not all of them do. If you get someone who really just doesn't want to learn it, then no amount of effort or inspiration will hurdle that obstacle.
- lovelyviking 5y ago> C is generally a good choice I would really appreaciate your opinion about Rust here. What do you think having your lisp background and knowledge?
- mikelevins 5y agoAs a Lisper, your primary consideration when choosing another language to learn well is that it should be a language that enables you to easily find work when Lisp jobs are scarce. Secondary considerations (that are nevertheless important) are whether it's pleasant to work with and whether it's likely to be useful in your Lisp work. Whether a language is pleasant to work with is a matter of personal taste. The other secondary consideration--whether it'll be useful in your Lisp work--is more objective. The language will be useful in your Lisp work if it's used in implementing Lisp, or if it's a common compilation target for Lisp, or if Lisp programs are commonly called upon to interoperate with it. C hits the first two criteria: there are several Lisp compilers that compile to C, and several Lisp implementations with kernels written in C. C, C++, Java, Python, and Javascript hit the second criterion: there are many applications of Lisp that need to interoperate with programs written in those languages. Rust doesn't fit any of these criteria particularly well at the moment. The number of open Rust jobs doesn't seem to be particularly greater than the number of open Lisp jobs, which makes it a poor candidate as a fallback language. There aren't yet a lot of applications of Lisp in which it's important to interoperate with Rust code, either. Rust is high on my list of languages to learn next, but because it's interesting in its own right, not because it's a particularly good fallback language for a Lisper.