6 ms·
I have the same response to this as I do to every other lisp article. It’s cool, but how have you personally leveraged this advantage that everyone talks about?
by gaze 5y ago
I have the same response to this as I do to every other lisp article. It’s cool, but how have you personally leveraged this advantage that everyone talks about? What big lisp project has the author contributed to, such that they have enough data to sing it’s praises?
- HeyLaughingBoy 5y agoI follow that up with knowledge of a large project that was started in Lisp (actually Scheme) that had to be converted to C# because the difficulty of finding experienced Scheme developers for the years of maintenance that would be expected was far more than the cost of converting to a language that's more "usable." Still remember all the meetings that generally always included someone complaining "what the $#&^%! were they thinking and why didn't their Management stop it before it got this far."
- closeparen 5y agoAs long as “hire experienced X engineers” is a non-negotiable requirement, you better choose a popular value of X. In parts of the community we do not so much think of the tools as part of the identity of the engineers. We’re looking for general intelligence/capability and train specific technologies on the job.
- seibelj 5y agoI know a startup that hired a Marxist-collective group of programmers. I was told this story years ago, and they were acquired, so I’ll just name the firm - “White Ops”. This story is so absurd that I’m naming the firm in hopes someone can verify the accuracy of this, although I trust the person that told me the tale. The programmers were based in Canada and only wrote in Haskell. The CTO of White Ops had apparently hired them previously as contractors at a prior company without issue. In hindsight, it turned out the purpose of Haskell was specifically because it was very difficult to hire anyone to replace them, and they wrote in a strange manner that left even experienced Haskell developers confused, especially without their customized IDE extensions. After a couple rounds of funding, the Marxists went on strike and demanded huge amounts of equity from White Ops to continue working. Ultimately the company wound up rewriting everything in a more popular language than acquiesce to their demands. I heard the Marxist group also had tons of drama because the leader made everyone live onsite in shared housing.
- HeyLaughingBoy 5y agoI loved every word of that!
- bitwize 5y agoYou can do that in almost any language, though. There was a furry who worked as a web developer for a small firm. He had built their back-end runtime in MUCK scripting language. (A MUCK is like a MUD, but without the statistics and stuff, so it's much less a role-playing game than it is simply role-playing.) Eventually he was fired, probably because he spent more time pretending to be a highly sexualized female fox on MUCKs than doing his job, but the back end to all their web apps was written in MUCK code -- and few non-furries even knew what a MUCK was let alone how to program one. So the befuddled engineers who remained had to figure out how to modify the code without their vulpine-in-his-own-mind former colleague. They uh, also didn't notice the backdoor he put into the web server that allowed him to spy on their activities, even though he was gone from the company...
- librarian42 5y agoI can't even. Did they use the one that's basically Forth with a string stack (No, not Postscript, Forth with a string stack) or the one that's basically m4 (the higher level of the two sendmail scripting languages) implemented in Forth with a string stack?
- bitwize 5y agoI think they used MPI (the m4-like one) because it is much easier to retrofit as a sort of templating language for use in web pages back in the 90s when that was a thing, as opposed to the modern practice of maintaining an entire parallel-universe DOM which is then transformed into the real DOM. MUF (the Forth-like one) was a bit too low-level for the application, though I do seem to recall a story this same furry wrote in which a fantasy CPU is mentioned that runs MUF natively, like a Lisp machine but for furry roleplay environments. I won't get into the uses to which it was put.
- deleted 5y ago[deleted]
- vindarel 5y agoFor a happier note, in this interview they tell how they managed to train non-lisp engineers on their internal browser-based Lisp system: https://lisp-journey.gitlab.io/blog/lisp-interview-kina/ https://lisp-journey.gitlab.io/blog/lisp-interview-kina/
- codr7 5y agoI wrote this to try and show how that could happen in a realistic enough way to make sense: https://github.com/codr7/whirlisp https://github.com/codr7/whirlisp
- TurboHaskal 5y agoI don’t consider myself a Lisp wizard and mostly stick to pretty simple code but to name a few cool things that would have been tedious or impossible in another language: - A desktop application for a bank in which not only the gui’s content but the look and structure was generated or changed on the fly mimicking the status of a database. - An interpreter in which most of its classes and methods were automatically generated. The Java rewrite took pretty nasty code generation hacks, visitor pattern madness and way more LOC. - Some program with a huge cache (glorified hash table) that was not catching simple strings or objects as keys but actual code as s-expressions. I always thought that was pretty cool. Most if not all of my Lisp (and Perl) projects have been eventually rewritten in Java, and not exactly due to technical issues. I mostly put up with Go these days which is great most of the time but of course makes me yearn for a more powerful language or wished I never dabbled with those.
- mbrodersen 5y agoI have implemented pretty much all of that in C++. It wasn’t hard or tedious. Using declarative data structure to runtime generate the UI from (for example) is something I do all the time. In C++, C# and Typescript. And evaluating expressions at runtime is just using an AST. Something I have also done a lot.
- TurboHaskal 5y agoThe GUI application was particularly elegant because the program would detect the changes in the database, change the class structure and attributes of screens and widgets at runtime with all runtime instances being updated. Note that this was written decades ago, way before people got excited at Swift UI, Qt QML or Javascript web apps. As for "just using AST", it is tedious to me, that's why I don't bother with it in other languages, and judging by the code that I've seen, it is for the average programmer as well.
- mbrodersen 5y agoYep nothing that I haven’t done in other languages. I learned Typescript and wrote a 52 page business application from scratch in a few months using the declarative approach. I used JSON to declare everything the same way you would declare it in Lisp and had all the same advantages. Parsing JSON in Typescript is a single line of code. The same as calling read in Lisp. And a college of mine took the application and easily made a version for another customer in less than a day. Changing most of the 52 pages to match the other customer. The look, the page layout, some of the logic etc. He never looked at the source code. And mind you I have written my own Lisp dialects just for fun, and have written code in Common Lisp and Scheme. I like the simplicity of Lisp the same way that I like the simplicity of Forth. But I just prefer other languages. Not having types is tedious to me.
- georgikeith 5y agoI'm not a hardcore LISPer anymore, but I worked on a ~600K LISP system in my first job out of college for 4 years. I'm many years away from it, but I still remember it fondly. We were working on a DoD project to feed relatively large amounts of logistics data in and out of a bunch of simulation models written for different contracts for different branches of the military. The inputs/outputs were all relatively large/complex files, with different formats and different units, and some values had to be repopulated in the output-files before being fed into the next simulation, and the input/output formats of many of these things were often being changed. The whole environment we lived in was more dynamic than you'd ever really want, yet I remember it feeling really easy to describe what I wanted to do in code; more than any language I've worked in since, stuff tended to Just Work the first time. Some of the cooler things one could do in LISP that were difficult/impossible to do in other languages: - Running in an interpreter from your editor (emacs, of course) allowed you to write editor code that could read/rearrange/fix your application code in the running image making the tweak/reload/test cycle trivially fast, even in really complicated systems (Python comes close, but not quite there). - If it made sense, you could write lisp code in your editor that helped you write/manage the LISP code for your project, create patches automatically, etc. - Writing a refactoring script in your editor was often better than trying to do it by hand. Decades later, I have yet to see an IDE or a refactoring tool that works as cleanly. - The LISP macro system made it "easy"[1] to avoid writing boilerplate code. It was often more practical to write a boilerplate-generator, rather than thousands (on 10k) lines of boilerplate. - Since classes/objects could be redefined on the fly almost arbitrarily, it was possible to redefine object data members as static class-members, and subclasses with overridden member-data, depending on the contents of your dataset AFTER loading it (at the time, I think this had a RAM savings of ~30%?) - CLOS is the cleanest, most flexible object-oriented language I've ever seen, with a sensible multiple-inheritance system and all sorts of tools (like "before", "after", and "around" methods) you could use if you had a good reason to. - The metaobject stuff in LISP is deep, dark magic; but sometimes you actually need deep, dark magic. Not often, but sometimes. In the end, I think LISP is still a great choice for really complicated, dynamic problems (the kind that take years and millions of lines of code to solve). If you find yourself working on the sort of problem that makes you feel a need to build a domain-specific language to solve it, that's the sort of problem that LISP is REALLY good for. While I'm not a manufacturing engineer, LISP feels a bit like the programming language equivalent of a CNC mill/lathe that you can use to build out a factory that might require building bigger/better CNC mill/lathes. [1] "easy" in that the non-boilerplate code was easy to read and understand its intent, but often it was much harder to debug, as macros often called macros which called macros. Debugging code that writes code is a whole different level of brain-hurt, but sometimes it's still better than the alternative.
- deterministic 5y agoAgree. There seems to be a lot more articles praising how awesome Lisp is than there is awesome code developed with Lisp.