Even the advantages in comfort don't really change much, because your expectations just adjust to whatever level of luxury and effort you are used to.
The truth is, functions, variables, and loops are an extraordinary form of magic. Being able to use those forms of magic well is an infinitely deep space of learning and growth. Maybe your language feature helps you solve a problem better, but compared to the opportunities available to you in terms of just becoming a better programmer, it's a comparatively small opportunity.
For example, knowing when to put away your primary language and use a special purpose one (and when not to) is an ability that can improve your productivity 1000x. I don't think there are any language features that can come close to it.
Compounding this, every time you use a unique language feature, you incur readability costs, and portability costs. The more control structures you put into your toolbox, the more choices you have to consider every time you read and write code. That cuts into whatever wins these fancy control structure provide.
Because Common Lisp isn't a better language anymore.
When Lisp was big in the early 80's, assembly, COBOL, FORTRAN, C and some Pascal pretty much ruled the day. Compared to any of those, Lisp is deeply magical.
So, the real question is why did such a magical language lose to the upstarts that all appeared in the late 80's and early 90's: Perl, Python, Tcl, Lua, etc.
Answer: files, strings, and hash tables. All of those languages make mangling text pathetically easy. Perl is obviously the poster-child for one-liners, but all of those make that task pretty darn easy.
Lisp makes those tasks really annoying.
Just take a look at the Common Lisp Cookbook for strings: http://cl-cookbook.sourceforge.net/strings.html
Why should any beginner willingly subject themselves to that kind of verbosity?
Fair point about strings, not sure about files and hash tables. But you've mentioned a bunch of scripting languages, and CL was never competing with these. Why it lost to Java and later to Python and Ruby in webdev is a different question. But string handling - you need to notice that as an industry, we shot ourselves seriously in the foot with Unix and proliferation of unstructured text. The unstructured text-oriented philosophy is frankly insane, and lisps are older than it - so for better or worse, they didn't follow.
People now are slowly rediscovering why adding structure to your text is better than having each program implement its own incompatible, bug-ridden regex-based parser. And surprise surprise, structured data is something lisps excel at since before most of us were born.
Except that it WAS. Programmers have a limited amount of mindspace. So, the question as a programmer in the late 1980's/early 1990's is how I'm going to allocate that space:
1) Systems language--C is pretty much your only option at that point unless you are in assembly (God help you). Anything bashing hardware (graphics, audio, networking, etc.) goes straight for C.
2) Many programmers are also system administrators in this time frame. So, I'm going to use a language that mangles text well--Perl wins here. People transition to other languages only once they get fed up with Perl.
3) Operating system specific languages. Unix pushes you toward C. Windows was C or Visual Basic (that ecosystem was huge at one point). Mac was C or Pascal.
So, in this time frame: Lisp is painful for system programming on small systems (fails 1). Lisp manipulates strings badly (loses on 2). Lisp is not tied to an architecture that would drive adoption (loses on 3).
So, as a programmer, Lisp is, at best, at slot 3 or 4 in terms of programming languages for daily use. Is it any wonder Lisp never got real traction?
You also have to consider how knowledge got disseminated in this time frame. The web doesn't exist. Email is actually scarce unless you are at a university or a big technology company. Netnews is something that soaks up enormous amounts of disk space so sysadmins hate carrying it in useful ways.
It is hard to appreciate, in this era of instantaneous, ubiquitous information, just exactly how much the pink camel Programming Perl book with its cookbook section singlehandedly drove adoption of Perl. I had 3 copies of that book that I used until they disintegrated. Can you think of ANY other programming language book for which that is the case? (Actually, I can, but I'm the odd duck. My workbook copy of The Little Lisper got the same level of abuse to disintegration).
> The unstructured text-oriented philosophy is frankly insane
It is NOT insane when memory and disks are small--which defines most of the time when Lisp was popular. Structured text requires lots of extra overhead that simply wasn't going to fly when RAM, disk, and bandwidth were very restrictive.
The main reason is that the LISP community is just not paying attention to the modern world.
Back in its days, LISP was revolutionary and ahead of its time. It gathered a bunch of followers who could reasonably be justified in thinking their language of choice had something unique about it.
And then, they made a major mistake: they stopped paying attention.
The tech world moved on and passed them. And they ignored it, confident that nothing new or interesting could ever be invented after Lisp.
It's the ultimate hubris: thinking that programming language science can ever reach an end.
Nah, the funding just dried up after Cold War ended and symbolic-based AI turned out to be a failure.
> Back in its days, LISP was revolutionary and ahead of its time. It gathered a bunch of followers who could reasonably be justified in thinking their language of choice had something unique about it.
Those "bunch of followers" actually invented half of the programming you use today, and also there were quite a lot of them during the Cold War. The history of computing is not like what C/Java books would like you to believe.
> The tech world moved on and passed them. And they ignored it, confident that nothing new or interesting could ever be invented after Lisp.
Maybe a bit, but for a good reason too. The tech world made a huge step backwards with introduction of Unix and C, and we're only slowly recovering and beginning to pay attention to the things people did before.
> It's the ultimate hubris: thinking that programming language science can ever reach an end.
I agree. But it's also hubris to believe it can not take steps in the wrong direction and enter blind alleys.
When I discovered UNIX via Xenix, I already had ZX Spectrum (48K, 128+2A, 128+3), SAM Coupé, Amiga 500, Windows 3.x experience, so the world of UNIX OS architecture seemed quite interesting.
When I got to learn C, that experience already had showed me there were other means to make use of all computer capabilities.
So the time spent on UNIX land, meant I was initially one of those renegades trying to use C++ instead of C like everyone else.
Eventually the introduction to Smaltalk and Native Oberon spiked my interest to delve into their history, as I was specializing in compiler design.
That showed me a world much more interesting that what AT&T has ever produced.
A saner mentality regarding what computer safety and developer productivity should actually be like, but sadly failed in the market, because UNIX was initially available for free.
I would dare to say that the OS architectures and development stacks from Apple, Google and Microsoft are much closer to those ideas than whatever exists in the pure UNIX world.
Ofcourse I long for some of the revolutionary stuff the Lisp community was known for once; particularly a better unified GUI library (I find GUI programming painful because of all the libraries which all do something else 'right'; no-one is doing real revolutionary stuff there) and a better concurrency library. With the knowledge within the community it 'feels' possible to make something for this modern age aka run the same code on AWS Lambda or on a Greenarrays ga144 without changing it.
I don't think that you've been paying attention to recent Common Lisp libraries or recent lisps. Lisp has never stopped evolving and continues to take ideas from other languages.
C.A.R. (Tony) Hoare said of Algol 60 that it was such a good language that it was not only an improvement on its predecessors, but an improvement on nearly all its successors as well. The spirit of that statement rings true for me[1], and I feel that the same could equally be said of many Lisps, especially when I think of things like read/write, CLOS, streams, conditions, (delimited) continuations, hygienic macros, etc. Common Lisp has been virtually static for over 30 years[2] not because it's "behind the times", but because it was so far ahead of the times that everything else is still playing catch-up!
[1]: I feel as though Algol 60 was, with few exceptions, the best language available until around the mid-to-late 80s.
[2]: Not to mention that it really hasn't been totally static: now we've got ASDF, QuickLisp, {U,C}FFI, CLIM, SLIME, etc. And loads of libraries.
Algol 60 was largely superseded in the mid-1960s.
But much larger companies are using it also, nearly exclusively.
As far as macros go, the most popular Clojure library for routing web requests on a server is Compojure, and it wraps a lot of low-level stuff up in a tight lisp macro set that makes it trivial to functionally compose your http requests. It's pretty nifty and is used extensively in industry.
Also this web site you are interacting with right this moment as you read this is built on lisp.
That's a really weak argument. Java is used orders of magnitude more in enterprise, and you don't see anyone proclaiming that as the pinnacle of language design.
And didn't they at one time have to reset the server every few weeks because HN would use up all the RAM or something? That's not something other forums built in lesser languages have to do.
I mean, it obviously works, but would anyone say it works particularly well, even as a Lisp implementation of a web forum?
Also, as a side note, one would be quite surprised how frequently will known companies solve memory problems by restarting processes frequently.
I don't know how Arc does it but Clojure's resources are no different than any of the millions of Java web servers running; just a much better language to run on vs Java for that platform.
It reminds me of Esperanto a bit, it might have some nice ideas but it will never take off. I've yet to hear a succinct, practical argument as ot why I should take the dozens of hours to learn lisp or any of its derivatives as someone working as a non-academic.
If you want to increase your productivity in orders of magnitude, if you want to be able to complete projects on your own that otherwise large teams would struggle to do, you must learn Lisp or any other meta-language suitable for DSL construction. Luckily, now there is quite a few of them, so if you don't like Lisp in particular there is a number of alternatives available.
I've seen this claim a few times in this thread. What makes this possible? If you can increase productivity so drastically, why isn't everyone using it all the time? It seems utterly irrational not to.
Take a look at what kind of power DSLs can give you:
http://www.moserware.com/2008/04/towards-moores-law-software...
If you use this methodology consistently, all of your code (including the DSL compilers themselves) is just as readable as this. Imagine, all your code reads as just an English specification of a problem you're solving, with some tables and diagrams where needed.
> why isn't everyone using it all the time?
I do not have an answer to this question.
Yet, given that I never managed to convince anyone who was not already doing this stuff that macro-based DSLs are a way to go, apparently, there is a huge cultural problem and a huge stigma attached to macros (likely because of the C preprocessor and some really bad Lisp examples - think of the stuff like LOOP macro).
I personally use this approach exclusively, and I cannot understand those who prefer to write 1000x more code.
In my experience, most people who are so in love with macros/DSL's work on solo projects.
Are you working on a team? If yes, ask your coworkers what they think about your macros and it should be more obvious to you why macros/DSL's should be used much more sparingly than what you recommend.
> I cannot understand those who prefer to write 1000x more code.
You're setting up a false dichotomy. It's possible to not use macros and still keep the amount of code down to a reasonable level.
Yes, but not because it's hard to cooperate when you use DSLs (it's in fact far easier to work in a team this way). It's more because scale of the projects shrink to such an extend that you don't need a team. One person can do with macros an equivalent of what a team of many people would do in a much longer time without macros.
> If yes, ask your coworkers what they think about your macros and it should be more obvious to you why macros/DSL's should be used much more sparingly than what you recommend.
Yes, I work in a team, and most often worked in teams. Yes, DSLs were always the greatest performance boost available. No, your beliefs about DSLs being somehow incompatible with team work are entirely wrong and unfounded.
> It's possible to not use macros and still keep the amount of code down to a reasonable level.
Mind naming a single viable alternative?
Most of the links in that article are dead.
That's exactly what's wrong with this thoroughly broken industry. They should not have learned this awful religion in the first place. Now it's much harder to unlearn and re-learn from scratch than learn it without ever being exposed to the wrong ways.
This methodology is far, far easier than anything OOP (the latter cannot even be defined comprehensively), and if you learn it first you can become productive much quicker than if you go the typical OO way.
And the most important feature of this methodology is that it's far more accessible. You don't need to be smart to use it. No need to memorise dozens of "design patterns" and all that. No need to invent complex twisted designs, trying to cram as many patterns as possible into a trivial task. DSL-based approach is very straightforward and mechanical, and can be executed by practically anyone who managed to learn how to read and write (i.e., around 95% of the population).
I mostly agree with your comments, but here I think you're underestimating the difficulty of creating a good DSL way too much.
It's like saying that anyone who managed to learn to read and write can create Esperanto.
Also, being able to read and write does not guarantee the ability of clearly expressing one's thoughts. Without this crucial skill inventing a DSL is an exercise in frustration, both for the original author and later for the poor users of such a DSL.
And one more thing: you can create (internal) DSLs in almost all existing languages, by (ab)using their syntax and semantics. Smalltalk and Ruby are quite happy with their many DSLs, despite being an OO language.
As for GP:
> How would you suggest a typical run-of-the-mill object-oriented programmer go about learning such a methodology?
See Avail: https://klibert.pl/output/avail-and-articulate-programming.h...
Then learn Scala, Ruby, Elixir, Racket, Smalltalk, F#, Elm, Haskell. They all make use of DSLs and contain many examples of well-designed eDSLs. After that, go read a bit on language design and compiler construction and you're done.
I'm doing this for living, and I can't stop wondering at how laughably easy it is.
The method is very simple:
* describe the problem in plain English (maybe with some diagrams)
* iterate it a few times until you have a syntax you think is unambiguous enough
* strip this syntax from all the sugar you just introduced in order to define an AST
* find DSLs in your toolbox that are potentially close to the one you're building and cherry-pick the necessary language components from them
* write a sequence of very simple transforms that would lower your source AST into a combination of the parts of the ASTs of the target DSLs of your choice
* Done. An efficient DSL compiler is ready, with a language designed as closely to your current view of the problem domain as possible.
* If you later find that your DSL is inadequate and your understanding of the domain was insufficient, than just start over again, this entire process is so cheap and simple that it does not really matter.
> ability of clearly expressing one's thoughts.
This is crucial indeed, but not having such a skill is a functional illiteracy. Current estimation of the functionally illiterate population in the first world countries is from 5 to 10%. The remaining numbers are sill much higher than the percentage of people who are capable of understanding OOP.
> you can create (internal) DSLs in almost all existing languages, by (ab)using their syntax and semantics.
But in order to do this you need to be smart (or smart-assed). It's a hack, and hacks are bad.
OTOH, macro-based DSL implementation is purely mechanical and does not involve any thinking at all.
(and sounds totally intuitive and obvious, not like a trick, but like a proper methodology, proper approach, never had this feeling of before)
thank you for info! will try to dig in
>If you have seven primitive operators (quote, atom, eq, car, cdr, cons, and cond) then you can define in terms of them another function, eval, that acts as a Lisp interpreter.And so any language that contains these seven operators is a dialect of Lisp, whether it was meant to be or not.
So Lisp is hard to understand and use but what happens when you try to modify/make languages which handle the situations that Lisp can,you end up with Lisp.And as a Lisp Dev, when you have seen this cycle.You really do not feel the need to defend every attack against Lisp.
PS:I am not a Lisp dev,but i am trying hard to learn Lisp.
https://www.youtube.com/watch?v=ydyztGZnbNs
It's on racket (scheme dialect). There are no language which can make you more efficient. But some languages open your mind. Just read SICP and find out what makes language EPIC. Many big projects are in Php. But surely no one would claim that it makes php "the EPIC" or even great.
IMO, the true advantage of lisp nowadays is that of an abstract syntax tree algebra ripped clean of cruft (well, that's scheme, but...). It's much more useful as a way of thinking rather than as a language. "Structure and interpretation of computer programs"is great because if one goes through the entire book and especially implements the scheme interpreter in e.g. C++ or whatever living language it gives you this fantastic general normalized thought model of programming languages which makes it much easier to learn new languages and concepts. That's anyway my experience.
So, to me, Lisp is useful similarly as say, relational theory is useful in software designed (having a relational model is wonderful for complex systems even with a lack of SQL database as a part of the system - if there is more than one 'thing' screw objects and rather use explicit tables and maps).
The point isn't that LISP is a great language. I think it is, but that's mostly personal opinion. The important part is to understand the concepts that LISP introduced and/or popularized.
EDIT: Also, https://www.youtube.com/watch?v=8X69_42Mj-g for a recent example of Common Lisp pushing the limits of science and computing in chemistry.
Irony. Using HN to say this. [0]
[0] Arc ~ https://en.wikipedia.org/wiki/Arc_(programming_language)
The only types of areas where this is even remotely the case are things where the rest of the field consistently undervalued a certain concept/category of problems. That's why there is really no language that can do concurrency as easily as Erlang.
The only way to figure out whether a language is good for you or not is to use it for whatever you can think of. Trying to be convinced by an Internet forum that a language is good because someone else made something in it is pointless. People have made whatever you can think of in almost every language older than a few years. Their successes say nothing about whether or not the language is good or not or whether or not it was a painful process to make it.
HN the site, looks deceptively simple. It solves a number of problems simultaneously [0] yet seems to work at scale [1] without bugs. [2]
The success of Arc, a Lisp derivative is in the everyday usage of the site and the hard problems it solves. [3] The original comment stands.
[0] http://paulgraham.com/hackernews.html
[1] "1.6 million page views and 200,000 unique visitors on a given weekday" 2013 ~ http://techcrunch.com/2013/05/18/the-evolution-of-hacker-new...
[2] In fact almost 10 years ago I reported a bug, pg actually responded it was a server reset. https://flickr.com/photos/bootload/406590838/
[3] Submitting high quality links, with high quality discussion while increasing users. That is a hard problem.
latent/dynamic typing and also macros work very poorly when the codebase is large and there are many people involved, or when we're talking about decade plus code-base lifespans. It's that simple. If you're one or three noticeably smart dudes building a system from start to ultimate finish (financial exit in four years?), why not go with LISP or something like it. If you're a team of one or two I advise you do go with lisp or perl or python or erlang or whatever.
But that's not the systems anybody builds or maintains much anymore. We make things that a rotating cast of 100 might touch over 30 years. We need static typing.
> latent/dynamic typing and also macros work very poorly when the codebase is large and there are many people involved, or when we're talking about decade plus code-base lifespans.
Lisp is one of the few languages that can say it actually doesn't age; Common Lisp code that was written 20+ years ago is often used today without a single change. You can't say that about most of the popular languages.
RE many people on the team - I see a lot of talk about how macros can be unreadable and all, but frankly, IMO that's totally backwards. Readable code is not about using a subset of language that you can find in "X for Dummies" book. Readability is about structuring your code to express intent, to be logically consistent, and about all the other things that transcend the syntax of the language. Macros are an ultimate tool for increasing readability, because you can keep recursively eliminating boilerplate, cruft and repetitions, bringing your code closer and closer to the intent it's meant to communicate.
> But that's not the systems anybody builds or maintains much anymore. We make things that a rotating cast of 100 might touch over 30 years. We need static typing.
Static typing is cool and all (I like it), but RE systems - no, it was in Lisp age people actually cared about buildings systems that would live for decades. Today, people build temporary systems that get thrown away or rewritten every couple of years at most.
Examples?
This is certainly false for most languages in use today: C, C++, Java, even C#: code written in these languages 15-20-30 years ago can still be compiled and run fine today.
I'm not sure what this proves much, though.
> I see a lot of talk about how macros can be unreadable and all, but frankly, IMO that's totally backwards.
Why?
Macros are basically syntax defined for a specific task. Why is it so hard to see that this can lead to an explosion of unreadable code if left unchecked? Wouldn't you be concerned if you had to work on a huge code base where most of the code is written using macros?
I would run away, personally.
> it was in Lisp age people actually cared about buildings systems that would live for decades.
We still care about this today. Even more than in "Lisp age" because we know how long code will be around. Which is one of the reasons why we have been moving at an accelerated pace toward statically typed languages.
Half of the libraries in the Lisp ecosystem? They were done once, polished over years, and pretty much did not age with time.
> Why is it so hard to see that this can lead to an explosion of unreadable code if left unchecked? Wouldn't you be concerned if you had to work on a huge code base where most of the code is written using macros?
Because again, readable code is not about using the same small subset of programming language constructs and design patterns everyone knows. It's about clear communication. Macros done right let you express your ideas more clearly, and hide/remove unnecessary boilerplate that makes code hard to read. Think about e.g. Java or C++ codebases, where 50%+ code is scaffolding and otherwise irrelevant to what the program is meant to do / communicate. Lisp macros let you hide all that.
Now if you do macros wrong, then of course code will be unreadable. But the same is when you design your API wrong using functions, or using classes.
Moreover, whining about macros being hard reminds me of whining about ternary operator in C++/Java/PHP world, where many people say not to use them because "juniors don't understand it". The solution isn't to ban ternary operators - it's for the juniors and the whiners to get their shit together and spend 5 minutes learning about it.
> Even more than in "Lisp age" because we know how long code will be around. Which is one of the reasons why we have been moving at an accelerated pace toward statically typed languages.
Do we? All I see is throwaway code. Especially on the Web, everything is ephemeral, and nobody honestly expects stuff to last more than few years (most startups are actually based on this assumption).
Anything can lead to an explosion of unreadable code if left unchecked. Any language feature, with no exceptions. Variables, loops, functions, types - you name it. Anything can go wrong if used with a bit of imagination.
Macros, on the other hand, provide an exclusive way of eliminating this complexity. A way of eliminating degrees of freedom of what can go wrong. Nothing else is capable of doing it.
> Wouldn't you be concerned if you had to work on a huge code base where most of the code is written using macros?
I'd be extremely happy to be able to work on such a well designed project.
> I would run away, personally.
It only means that you don't know how to use macros. Nothing else.
You really think the project is well designed just because they use macros, without even looking at the code or knowing the engineers?
Now I really think you're not for real and just messing with us.
Any comments on any other points I made?
Clojure attempted to add static typing with the core.typed projects, but high-profile exits [0] from that framework have made clear that this is a problem that can only properly be implemented at the language level.
If I could have a lisp with static types, I might not use anything else again.
[0] https://circleci.com/blog/why-were-no-longer-using-core-type...
(lambda (x)
(unless (minusp (if x 0 1))
(error "Oops")))
In OCaml, exceptions are not visible by the type system and you can write:
let f x = raise (Failure "NO")
So the kind of analysis that make sense in a language, as well as their soundness, is relative to the properties you want to check. Would you say that OCaml type system is unsound because it allows you to run code that can raise exceptions at runtime? I would love to see more precise type checking in OCaml, for example, and it probably already exists (I'am interested, if anybody has an example). But it probably makes little sense over there.
The same goes for parametric polymorphism in Lisp. The most in-depth approach to bring parametric polymorphism in CL is LIL (https://common-lisp.net/~frideau/lil-ilc2012/lil-ilc2012.htm...), but since it is dynamic, people who view dynamic typing as a deficiency might see that as a restriction.
You also claim that the type system is "unsafe". On the contrary, types being checked at runtime is a safe approach (buffer overflow, etc.) and plays well with the fact that everything can be redefined at runtime (maybe you don't like this aspect). In SBCL, type declarations are assertions. With the default optimization levels, that means that if they cannot be proved, they are checked at runtime (with the few caveats listed in SBCL man page). So if your input variable X is type as NUMBER and the function terminates normally, then you know that X effectively was of type NUMBER (that's a guarantee instead of an assumption). That result can be used in the following calls so that checking the type of X is not necessary anymore (if it is not modified in the meantime). The only case where types are trusted blindly instead of being checked, when necessary, is when you set the safety level to zero. This can be changed locally, not necessarily as a global switch.
1) You can compile or run the program fine even if there are type errors.
2) An existing type error may never be caught if that particular block of execution never runs. Then you can have unexpected surprised later when you finally do something to trigger that block.
3) They are slower than static type checking due to the runtime costs of checking types. Statically-typed compilers can do enormous optimizations once they know exactly what the types are.
If I need to do smart things in Lisp ahead-of-time, I may want to use a DSL and prove whatever I want to prove on it, and generate correct-by-construction code that does not check things at runtime. I could use ACL2, too. Please note also that I can work in a different language when it makes sense.
3) Statically typed compilers include Lisp ones. My code is sometimes underlined in orange like yours, because I made some dumb typo or because types do not match. Likewise, optimizations are done too, in particular inside functions, where things are more static than in the global environment.
What about efficiency? Look at the postal system: you have to wrap letters and objects in enveloppe or packages (except postcards, which are like fixnum), put a label on it with many informations... what a waste of time and space! Yet, each object has a type now and can be dispatched reliably and efficiently. If you put your letter in the wrong box, you will have enough information to recover and perform your job. Once letters are all filtered out from packages, you can avoid checking that they are letters and gain some efficiency. You can build a new kind of service (drone-delivery?) with a special label and dedicated rules and integrate it within a running system without restarting the world. If anything goes wrong, you can have a generic error handling mechanism that does not crash everything. Static types are more like pipes: clean water here, used water there, and they never mix in a wrong way thanks to pipe calculus. So while I agree that static analysis can be great for doing crazy optimizations, there are use-cases where dynamic typing shines, and generally people replicate that using tagged objects anyway: think about game entities which are "typed" dynamically, or frameworks when you can load custom scripts (and those are generally not typed-checked, unlike Lisp).
2) You plan for failure. Even in a statically-type language, you'll have runtime bugs. Only in a mission-critical system are errors fatal. If you place restarts or error handlers accordingly, you'll have the opportunity to fix your stuff. Ask Erlang people about reliable systems.
1) Worse, you compile your code, the compiler complains but you can still run the produced code! Then you can test your error-handling code.
Seriously, this is not a problem in practice. Coding and testing are interleaved because the environment is right here awaiting orders. If you look at the end-result, I am doing the job of the static type checker by fuzzying input in a way that makes sense for that particular function. I also have a global view of the system and more context to decide what will happen at runtime, or not. When I fail (I am not proud of it, like most static analyzers), the runtime is here to catch it.
Even though the Apple System9/OSX platform has been around a long time, the Apple ecosystem got really popular with the iPhone & iOS in 2007. From 2007 to 2014, the official SDK for that was Objective-C. Obj-C is dynamic, and as a consequence, people happened to program in a dynamic language. ("When in Rome do as the Romans...")
Same situation for web browsers. The only "sdk" for adding interactivity and actions to web pages was Javascript -- which happened to be "dynamic".
In other words, "dynamic" was something programmers had to live with rather than something they chose for architectural superiority.
In both cases (Swift, TypeScript), the desire for static typing became apparent.
Some sources and excellent documentation are on the bitkeeper.
There is also the MIT Scheme, as seen on TV in the Wizards Lectures (1986 Abelson & Sussman SICP lectures).
BTW, the guys who designed and developed early lisps, up to 80s, were bright people heavily influenced by discoveries of "modern science" of the time, which were genome and protein structures, basics of cell biology, signaling pathways, early genome sequencing techniques etc. Their designs has been based on right principles. Erlang is another example.
Another obviously successful project is called (surprise, surprise!) GNU Emacs. Non surprisingly it is a continuum of early emacses, such as Zmacs.
Recently, Eitaro Fukamachi (a true hero, in my opinion) have bootstrapped a few remarkable projects, which should mark the beginning of the Common Lisp renaissance, but these projects also went unnoticed by packers. Why Clack when we have PHP or Java Server Faces?
As for Erlang syntax - the pattern-matching on receive with variable binding for simple, terms-based protocols is, again, too good for mediocrity to grasp
{ok, Val} | {error Why}
I don't think Gosling, Stallman or Armstrong ever mentioned any basis in genetic science to justify their language. And seriously, think about it... It's completely absurd.
I'm also not sure why you think that returning error codes is "too good for mediocrity to grasp", because in the 21st century, it's considered a very bad practice that leads to extremely unsafe coding practices, which is one of the many reasons why it's been deprecated in most modern languages invented in this century (except Go ;-)).
https://groups.csail.mit.edu/mac/users/gjs/6.945/readings/ro...
As for protocols, there is, for some obvious reasons, still nothing better than asynchronous, out of order message-passing over a packet-based networks, with fixed-size header (upon which one could patter-match in a single pass) and adjustable size payloads, which could adapt to a physical channel by adjusting to its frame-size, so, the stdlib and OTP is good-enough and well-balanced and just works.
It is also not a coincidence that Erlang is pure-functional - so is the world of proteins and enzimes.
There is a bit more universality in a chunked linear structures and stateless asynchronous message passing of type-tagged binary data with feed-back loops co-regulation that it seems.)
Source?
> It is also not a coincidence that Erlang is pure-functional - so is the world of proteins and enzimes.
That world is mostly driven by mutations, which are the exact opposite of functional purity.
I really have no idea where you get all these broken metaphors.
Is nanopass typed? I'd like to see some good examples of typed Racket.
There are practical limitations. If everyone else is using C, it will be more difficult to introduce LISP.
Of course, making a push for Lisp usage would gain users and, therefore, tutorials and make it more practical but probably only among those same scientists and engineers due to the nature of Lisp itself and how you think when using it.
1) The purpose of HN posts on Lisp is to fellate pg, nothing more.
2) One of the big reasons Lisp has failed commercially is that expert programmers create their own personal libraries, which cannot be taken to the next employer for legal reasons. So all that effort is wasted.