4 ms·
> The main issue is that Lisp, for all its inherent "power", has very limited tools for enforcing modularity boundaries in code and "programming in the large"
by throw10920 5y ago
> The main issue is that Lisp, for all its inherent "power", has very limited tools for enforcing modularity boundaries in code and "programming in the large"
I don't see any mention of "modular" or "boundaries" in the post you linked, so I'm assuming that it doesn't add extra context to your point.
You say "very limited tools for enforcing modularity boundaries", which I'm going to assume means that you believe that Lisps have constructs for creating modularity boundaries (e.g. unexported symbols in Common Lisp), and just don't enforce them (e.g. I can still use an unexported symbol in CL by writing foo::bar), in which case - I don't think that this is actually an issue.
Programmers are capable of doing all kinds of bad things with their code, and shooting themselves in the foot, yet I've never seen an indication that the ability to shoot yourself in the foot with a language noticeably contributes to its popularity (see: C, C++, Perl, Ruby).
Moreover, specializing to Common Lisp, it's not like CL allows you to accidentally access an unexported symbol in a package - you have to either deliberately use :: (which is bad style, and takes more effort than typing :) or you get a hard crash. This is opposed to the above listed languages, which allow you to shoot yourself in the foot in a large number of extremely diverse and interesting manners, often without giving you advance warning - and yet are still far more successful.
------------
I don't believe that the lack of success of Lisps are due to technical deficiencies.
- johnny22 5y agoWhat do you think it is?
- db48x 5y agoMarketing. Too focused on AI, followed by more than a decade of breathless hype for C++ and Java.
- throw10920 5y agoNailed it. More generally: "non-technical cultural factors". I would also add some minor incidental technical factors (e.g. early Lisp implementations were far less efficient than C implementation during the time when efficiency really mattered, and then cultural/marketing factors kept C as the dominant language far after the technical balance tilted in favor of Lisp).
- wvenable 5y agoLisp is clever and also a but inhumane. It only ever appeals to the small subset of the population that likes that. Lisp has some niceties that are fundamentally inherent to its design but it's just not enough to overcome how awful it is for people. But this is not a technical deficiency of Lisp, it's more of a technical deficiency of humans.
- throw10920 5y agoWhat? How is Lisp (either the family of design decisions or even a specific language/implementation) "inhumane"? What does that even mean?
- wvenable 5y agoInhumane is the wrong word; brutalist is a better word. Brutalist architecture is characterized by minimalist constructions that showcase the bare building materials and structural elements over decorative design. Human's are not logical/mathematical machines and all the irregular and decorative parts of programming languages are often for our benefit even if they're inconsistent, verbose, and limiting.
- kazinator 5y agoLisps are fairly "decorative". It just doesn't combine a pin-striped blazer over a plaid shirt with leopard patterned pants, like many languages. Here are some traditional notations found in Common Lisp: "string" symbol :keyword-sym #:gensym package:sym `(static content ,inserted ,@spliced) (l i s t) (im pro per li . st) #(v e c t o r) 6.18e+23 13/17 ;; comment #*100111101101 #1=(1 2 3 #1#) ;; circular structure #S(point :x 35 :y 44) Various dialects have various notations. There is syntax highlighting support in editors, too. Lisp is not just (this (and that)).
- wvenable 5y agoAnd you imagine this is a contraction to what I said?