Doesn't this ignore the need to work together and build on each other's work? To me, that's not about companies being able to treat programmers as interchangeable, but about us collectively building higher, i.e. building towers of Babel rather than suffering from the curse of that story.
When that happens, I can go all in with Lisp because I care about my personal productivity (I have always been a lone wolf programmer) yet still being able to use code written by anyone in their comfy language.
As I get older, I find I just want to mold and bend the computer to my every will, and Lisp is the tool to do so. That the resulting code is hard to understand for a junior engineer is not my concern.
But one thing is for sure: I want to be able to create any abstraction, and I am done writing glue code, writing yet another PostgreSQL library for yet another language. How many date/time libraries have been written since the invention of UNIX? Imagine the amount of wasted time, money and effort. Then multiply by the number of languages that have been invented because the syntax of the previous one is too inflexible.
I stand by the Lindy effect: the longer something has been around, the longer it will survive.
Looking forward to Wasm Components to use a language from 1960 to its full potential. Then the goal is to have a WASM-native Lisp that can dynamically load any other WASM library, and I don't have to write yet another date/time library ever again nor care about junior engineers getting confused by crazy macros in my code.
(I have been suffering from the Lisp curse for 6 months and counting. Please send help.)
He'll code it in C or Java or Javascript and that'll be it thank you very much, so that we can maintain it forever.
I just said that, where I have complete control (i.e. on personal projects, or companies I bootstrap) I will choose Lisp because I wouldn't have to care for junior employees.
This forum is so preoccupied by only considering something that could be understood by a team of thousand average-skilled engineers, and only the easiest to understand languages matter, which is why all Lisp discussions devolves into mentioning how hard it is to adopt in large corporate teams.
The power of Lisp is inversely proportional to the headcount, and sometimes you're the only one working on a project, so you want max velocity and flexibility. Not everything has to be optimised for a FAANG development model.
However, re-reading sph's comment above and seeing their response below, this truth table may help fill in context for me (thinking aloud and all that):
A: Running Lisp stuff for personal
and/or own startup
B: Embedding the libs as a B2B solution
C: Maintenance overhead
A B C A & B & C
T T T SkyMarshal and xwolfi's comment
T T F* I agree there would be a cost
T F* T sph using for own stuff or biz
T F* F Same as above
F* T T N/A
F* T F N/A
F* F T N/A
F* F F N/A
So then B is where things went one way or the other. And admittedly, I must have assumed B.
Nevertheless, I am cheering sph on :)
Indeed. This service (especially the time zones) should be part of the standard operating system API.
I really am hyped for WASM components.
Unfortunately, making a new isa is the easy part. The hard part is defining the abi.
.net came closest. Wasm is focusing on the wrong problem.
These are things that businesses have to deal with every day. The fact that we don't have those things, standard, as a part of a programmer's toolkit is a great failure of language and OS designers.
https://web.archive.org/web/20180223094826/http://www.xent.c...
I've also released them with a Boost license, so anyone can use them for any purpose.
We (sadly) rarely see languages that target binary (whether x86 or ARM or just LLVM) sharing libraries. Partly it's because the .so and .dll interfaces only support the C ABI, and the absence of a rich well-defined OOP abstraction.
But, yea, I'm not totally sure if a low level WASM ABI would lead to a rich ecosystem of multi-language libraries, unless the WASM ABI is at a high enough level that it defines higher-order functions, classes, etc.
Imagine a .so library with a native concept of high level objects that can be understood and passed between libraries written in different languages.
Take two: Working in the best fit for your brain is not incompatible with working with others -- enough companies are Java shops, why can't there be CL shops? (There are assuredly Clojure shops at the very least.)
Take three: Not everything has to be about work. Programming is a skill, not an occupation; there are lots of ways to apply programming as a skill that don't require you to build large edifices in teams.
Yes, you may think better in lisp than c++, but that doesn't help your team when you created something and moved right along. Better to speak the same language.
But to your very specific point: I have in the past developed prototypes in Rust whilst on a Java-only team. It's actually a good thing: these prototypes were meant to be thrown away, so working in a different language (and one that helped me model things effectively) meant we were forced to throw it away then write it right in Java once we knew what we were doing.
(We did the same thing for another feature, but it was someone else and they preferred Python. Again, we were able to prototype more rapidly and then implement a solid solution in Java once we knew how things should shake out.)
I've reimplemented a few side projects more than once, using common data back-ends because I can. I find it helps for say, messing with a new programming language, because I can apply it to a task I'm already familiar with.
All being equal, it's better to have a team writing code that is useful to the system or project or whatever ASAP.
If an individual insists on prototyping in a language that nobody else can use, then they should either carry that prototype into the team's ecosystem, or start prototyping in that ecosystem and learn to be productive that way.
If option A, let's hope that "write twice" is fast enough that they are productive. If option B, they may take a productivity hit but will probably catch up.
The third option of "I'll do lisp you do <teams ecosystem>" is not very pro-social. Come integration and debugging and maintenance time, that Lisp-er is not in a position to help. That's an undue burden in the rest of the team.
I can't count the number of times someone published their open source project and inevitably people in the comments started questioning their language choices, because they wouldn't be able to use it in their "team", and how that choice is ultimately harmful for "the community". Now, you're not doing that exact thing here. I'm just thinking about how all that focus on "the team" and "the community" often goes too far.
Personally, I'm not going to do anything in Common Lisp, but I'm always happy seeing other people doing their projects in that language (and many others).
That's fair.
> I can't count the number of times someone published their open source project and inevitably people in the comments started questioning their language choices, because they wouldn't be able to use it in their "team", and how that choice is ultimately harmful for "the community".
Yep - not paying means not entitled to anything. I agree there.
Or it's thrown away. But if it's thrown away because nobody else on the team knows that language, that's pretty wasteful. And if you make someone on the team learn a new language just to maintain that one program that's also wasteful. The person who insisted on using their language is optimizing for their own programming, but actually slowing down the team as a whole. We have words for that kind of behavior; they aren't compliments.
Now, in any given instance, it could be that the program is much easier to write in one language, and more difficult (or even impossible) to write in others. But even in that case, if you're in an organization, you need to get buy-in from the team or management or both, rather than just doing your own thing because you can make it work. Otherwise, your program may work, but it's an orphan. You need the organization to be willing to maintain your special program, or it dies.
[Edit: A programmer should be able to Reverse Polish Notate, nested-paren a tree, reduce some arrays, make references in nested scopes, evaluate without mutation, send a message, spin up a fail-fast supervision tree, produce finite answers from infinite graphs, synchronously react, rendezvous with logic variables, combine the above. "Specialization is for insects."]
And I say this as someone whose full time job was to do research prototypes of robotics libraries for a while.
This is my personal opinion, but I think that domain expertise is a much stronger component of bus factor than language choice is. You can write unmaintainable code in any language. But good code often still has prerequisites to understanding. Meanwhile, if you have the domain expertise, you can get quite far in understanding semi-bad code just by pattern matching on manifestations of your domain.
(But I was pretty serious about that list: I would hope a programmer just out of school would have heard of all of them, and expect anyone experienced to have done most of them, if not necessarily in the languages that make each one easy. Similarly, from Heinlein's original list, I currently lack only practical experience in planning invasions [though I have theoretic hex-board experience], butchering hogs [though I have a friend who has offered to teach me], and dying gallantly [though I have "I am just going outside and may be some time" as an example to follow should the occasion arise])
Though there are tradeoffs (and assuming 10x programmers exist) a ten-ex programmer can replace a team of ten one-ex programmers and eliminate mechanisms facilitating intra-team efficiency from the process.
Anyway, to me the Tower of Babel is a metaphor of collective action...building construction requires teamwork. Icarus is better for lone wolves.