To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/GavinFreeborn/. The first 200 of you will get 20% off Brilliant’s annual premium subscription.
I used to be a compiler writer at AT&T research labs many years ago. I was a member of a small team that developed something called a "common runtime environment" which allowed us to mix code written in Lisp, Prolog, C with classes (an early version of C++), and a few experimental languages of our own. What we found was that Lisp was a write-only language. You could write nice, compact, even clever code, and it was great when you maintained that code yourself. However, when you handed that code over to somebody else to take over, it was far more difficult for them to pick up than with almost all the other languages. This was particularly true as the code based grew. Given that maintainability was paramount, very little production code ended up being written in Lisp. We saw plenty of folks agree it seemed like a great language in theory, but proved to be a maintenance headache. Having said that, Lisp and functional languages in general, did provide great inspiration for other languages to become side-effect-free and, perhaps more importantly, to improve their collection management.
Do you think this could be fixed by having your IDE collect meta-info from static and dynamic program? Like modern IDEs for Python do type inference and other stuff like find callers/callees that help. LISP could classify "macros" (binding, optimization, semantics, replacement, static error checking) and color code them differently, same with functions. Is the Lisp/Perl curse not also a problem in other languages Java(Frameworks,XML), Haskell, Scala? I think in Python it might be less of a problem since there is usually only "one" obvious way of doing things.
Huh, weird. I’ve written Java programs for 10 years, and Lisp (mainly Clojure) for 3 years, both in team-based settings, and I find Lisp far easier to read and maintain than any Java code bases I’ve worked on. This could be because Java actively encourages developers to write an insane amount of code compared to just about every other language, but I also just love Lisp’s structure. Once I got used to it it became my favorite language, both to read and write.
Great talk! Thank goodness that we have Clojure to carry the torch, even though there are only a few of us still paying attention to the land of parens.
Great video, I don't fear for the future of common lisp. It got some greate compiler (SBCL) and a fervent community. Sure it's not perfect, but so far I think it's the best imho. It's also nice to know that my code will still be able to run as long as there's an ansi common lisp compiler.
Definitely, I think I could have gone a bit more into how things are actually better now in spite of adoption falling. Maybe that would be worth talking about in a future video.
of course lisp is still great for white box ai like expert systems, while black box ai like llms and neural nets has a huge number of legal and security issues with it. it all comes back to how useful the program as data paradigm is for ai.
I wrote tons of applications using autolisp (by Autodesk and used in autocad) in the late 80s and 90s. Also Wrote an NC (numerical controlled) software package for 5-axis machining, sold it for $1,500 per license, it did pretty well.
I wrote an AutoLISP routine in the early 2000's that could write g-code from AutoCAD entities. It only did 2.5 axis as that's all I really needed at the time, but I could see someone going further with it. Also worked in reverse to read old g-code programs and create 2d lines and arcs in AutoCAD. AutoLISP's integration to AutoCAD was really well done you could pull off a lot of cool things with it.
I write Lisp every day for work. Targeting three separate language VMs. With strange aeons, even death may die. Probably work with a prolog-based data-store at some point too.
Lisp is cool, one of a kind, take special ability of abstract thinking, especially when when i saw one Lisp program of several hundreds of lines or more at U of Toronto back in the late 80's...how or what are Lisp used for, in the real work ? AI > ML IMO, and Lisp should be also another major part of the AI but under appreciated
I think it's important to recognize why Lisp was powerful, not why people *wanted* to believe it was powerful. There is one reason in my view: Homiconicity. The composability and modeling power homoiconicity gives you is unparalleled. The orthodox view has always been that macros and the cons cell were the secret superpowers, which misses the appeal entirely and is a big reason CL floundered. Most problems can be modeled to be solved with runtime functions, even building a DSL, and the best performance is achieved with abstractions on top of arrays. There is a reason that new Lisps like Clojure and Janet focus less on macros and ditch the cons cell: Composability, modeling power, productivity, those are what matter. From there, the way you get good performance is by backing that composability with high-performance data structures like array-lists and hash maps.
Cons cells are the worst idea in LISP (IMO), I think streams and Iterators are better. Other ideas in LISP are symbolic computation, easy to modify eval function, quasi-quoting, macros, condition system, image based development, metadata on symbols. You can make a homoiconic version of languages by giving non-homoiconic languages an s-expression (or other homoiconic syntax) like Hacket or CLisp or Hy(Python). Anyway, does anyone have any stories of queries to change s-expression code to update a library or something?
@@windows99 "Homiconicity" refers to the ability to treat code as data. "Composability" refers to the ability to combine small functions or operations in a modular manner. So the composability and modeling power Lisp's homoiconicity gives you is considerable because its ability to treat code as data makes it possible to treat small code snippets like Lego bricks as you "snap" them together into some variable meant to model whatever thing or problem all those snippets are supposed to be simulating before you evaluate (i.e. execute) the variable in question. This makes it easier to abstract away details, and you can do this with arrays and hash maps to get better performance than you can with lists, which what Lisp would traditionally use ("Lisp being a truncation of "List Processing"). Does that clear it all up for you?
@@ivymuncher Clojure is better than Java. To me, clojurescript is for making websites and webapps. The web framework competition is stiff and there are better ways to build a web app. Clojure is legos. You can figure out how to build a car with legos, but it is easier to buy a Camaro.
@@ivymuncher Except for small bits here and there, there's no difference between Clojure and ClojureScript. So all advantages of Clojure also apply to ClojureScript.
This was a pretty good review of the situation. You mention the issue of algorithmic complexity with a language based heavily on linked lists. Another issue is the divergence between CPU and memory retrieval speeds, necesitating on-chip cacheing. That makes linked lists not just algorithmically bad, but bad in a contingent practical way. It also makes it much harder to reason about optimizing performance when using a LISP-like language, compared to a C-like language.
plenty of C code was based on linked lists and trees in the 1980s for sure - there are so many types of trees .. yet there is so little practical use for any of them on modern architectures unless your N is small.
@@styleisaweapon Lots of C code made use of linked lists, but can also use other cache-efficient data structures. Lisps are built on top of linked lists and can't really avoid them.
@@stephenaustin3026 Pretty sure most lisp code doesnt compile down to linked list juggling within inner loops when a decent compiler is handed decent lisp code - its the same argument as for C - the downfall of lisp is the terse syntax
@@styleisaweapon The problem with Lisp is that it didn't have a BDFL + Pep Python process, it fragmented (Scheme & others), it kept a whole lot of cruft from the old days, and was somewhat academic like Haskell (although it seemed more industrial than Haskell...). No new ideas can take hold in Lisp because it will be hated by others, or not adopted. Imagine though if Dylan was in the browser or if Python or JS was based on a good Lisp like Guile or CMUCL somewhat similar to Julia in the browser hmm...
Loved this video. Also loved the honorary footnote to early day AI efforts, Symbolic AI in particular, and how they relate to the LISP community. Really interesting how tools and ideas propagate or enjoy adoption. Fascinating to think how the world could have looked different if just a few small changes were in effect. Anyways... Happily LISPing on (Emacs) but have to admit I write Python when it comes to practical ML stuff these days. 😅 Keep these vids coming. Read a request in the comments for more dialect explorations. I'd be curious about that as well. Would generally also enjoy this style of a documentary/history lesson into other languages. Great stuff this. 🎉
Thank you for that; there is a lot of good information here. I think there are more reasons that Lisp "lost" than those mentioned. For example, (I am butchering this quote and I don't recall where I read it) it has been said that most systems written in a language like C will end up with a poorly-written Lisp implementation inside it eventually. This is an observation of the old, but as you know, the number of software developers has doubled every 5 years or so. So it is also an observation that most developers are not in a position to make.
HMM JS is a very poorly-written LISP inside C based browsers... What about Ruby (it lacked optimizations that LISP could do), and Python (no conditions, lacked way of optimizing code or easily doing static analysis like macors, early on poor support for image based development and hot reloading although ipython helped a bit).
"Over time, the default language, embodied in a succession of popular languages, has gradually evolved toward Lisp. [...] you can no longer claim to have invented a new language, but only to have designed a new dialect of Lisp ; -)" Paul Graham in his essay "What Made Lisp Different"
I like your analysis about the rise and fall of Lisp. If you have time I would appreciate a video about the rise and fall of Prolog. Maybe it's similar to Lisp...
Thank you for that walkthrough many lessons on how a tech can miss a window! I Used LISP quite a bit in the 80's during college, and used it a bit on TI Explorer, on of the LISP machines of the time. As you described LISP was not a light weight language. And in the 80's the biggest killer for it was the Mac and PC. Experiements aside, it was not practical for any application development.. In that space, C then C++ fit much better. Fast forward to the internet, while JS is NOTHING like it, however, JSON sure made data sets very easy to construct and manipulate.
I have a hardcover book on NLP with Lisp. I've had it for a while but it's been winking at me furiously for the past couple of months so I'm looking into watching a couple of intro lisp videos and diving in. NLP is a big interest of mine and I'm looking to broaden my horizons.
that was great. please make more videos about diff dialects and histories revolving around lisp. i'm fairly new to it and i find it absolutely fascinating! while it might not be something useful in a professional sense, i'm really enjoying learning lisp (some common lisp and emacs lisp) and i find the language structure very elegant. but i totally understand why it didn't take off to be honest. it doesn't map well to how CPUs work and there's inherent garbage collection which in many cases becomes a blocker. | I would love to have more deep dives on the origins and histories of diff dialects. great video
One of my first languages, after English, haven't used it since I was a kid though.. still, almost any programming I do now, I attempt to force the language into that structure..
I love LISP. I got into LISP because of JESS rule engine and eventually created my own open source rule engine. The big roadblock for many developer is s-expression syntax. Over the years I've tried to teach it to other developers and 90% never get over the syntax. Parsing s-expression is elegant and beautiful compared to Java, CSharp and 95% of languages out there. I'm biased, so take it with a grain of salt. The real power of LISP is logic programming, which causes a steep learning curve. The downside is logic programming is hard and most programmers prefer imperative programs.
When I started programming I was obsessed with game development, So I learned some java. After that I tried C++..... yeah(C++ wasn't for me at the time). And then I went to other languages, lisp is one of my favorite languages. But I really just use what I want and is required at the time. Great video.
I am crazy enough to think a foundation to increase Lisp usage, marketing and viability would make a major difference in how much Lisp is used. Writing far faster code in Lisp than many of the most popular languages (looking at you Python) produce today is trivially easy in Lisp. And the reality is that programmer productivity and maintainable extendable code is WAY more important in the the overwhelming majority of programming done today than raw speed anyway. So I am really tired of this old chestnut. Anyone that knows anything at all about Common Lisp knows you don't do most everything is cons list. That is an absurd excuse. For how many decades has CL had Just in Time compilation, full arithmetic stack, tons of sophisticated data structures and the best OO system in existence? Java is modern COBOL and completely sucks in so many ways.
@@aoeu256 Anthony doesn't actually give any specific justification or characterisation of why Lisp is harder to maintain that can be evaluated in a modern context, so his comment doesn't really have much technical value and is merely an anecdote of one guy's career experience instead of a meaningful statement on the engineering drawbacks and strengths of the language.
"...the development past these simple prototypes was very slow and seemed to run into a wall very quickly" - unfortunately, this is a concise description of programming projects in general.
Yes, thank you batlin, that was bugging me too. Bolt, Beranek & Newman was/is an R&D company near MIT campus that historically did AI and networking and other high-tech research, much of which was done for the Dept. of Defense, and DARPA in particular. Per their current Wikipedia entry, apparently they were bought up by Raytheon in 2009. You can thank them for the Internet you're using at the moment, because they built the original ARPANET. And since we're talking Lisp here, we should note that BBN created the Interlisp variant of Lisp. If any of you happened to use the Logo programming language for kids while you were in elementary school, you can thank BBN for that (and I can only speculate, but I betcha Logo was written in Lisp under the covers). They built some early parallel computers including the BBN Butterfly that I was lucky enough to do some research on.
logo,was definitely written originally as a front end ui for lisp which provided the turtle graphics functions for children, but with a better syntax for those users with the full power of lisp underneath. later it diverged into its own language, but i don't know enough of its later history to know if it still has those abilities.
It's notable that, historically, there've been two languages that share a similar evolutionary trajectory: LISP and Smalltalk. Both languages are VM-based and image-based. Both are very dynamic and flexible. Both had special hardware to run them (in the case of Smalltalk, the Xerox Alto). Both needed expensive hardware (lots of RAM, fast processors, and in the case of Smalltalk, high-resolution displays). Both have experienced massive market fragmentation. Both have been the victims of Java hype. Both missed the mark with respect to the Internet. However, there are important differences, too. Smalltalk did become mainstream in the 1980s and 1990s. In fact, according to a 1995 IDC report, Smalltalk was the second most popular object-oriented language after C++ and ahead of Objective-C, Object Pascal, CLOS, and Eiffel. It was mainstream enough that IBM chose Smalltalk as the centerpiece of their VisualAge enterprise initiative. Today, Smalltalk is still used by thousands of enterprises around the globe supported by no fewer than three major commercial Smalltalk vendors: Instantiations, GemTalk Systems, and Cincom. I can't think of any major commercial LISP vendors unless you count Franz and LispWorks. Clojure (2007) and Pharo (2008) are modern adaptations of LISP and Smalltalk, respectively. Neither language is particularly popular - they don't rank in the Top 50 at TIOBE. For a while, Clojure did receive a lot of hype but now it's nowhere. What happened to it??? Interestingly, when LISP celebrated its 50th anniversary in 2008 (at OOPSLA '08), it was very low key. Last year's celebration of Smalltalk's 50th birthday was pretty awesome: levelup.gitconnected.com/mmxxii-year-long-celebrations-for-smalltalk-bed82541b7db.
Interesting factoid: According to a 2017 study by Capers Jones, Smalltalk is the most productive of all the major programming languages, including C, JavaScript, Lisp, Go, Java, Python, and even Ruby. If you don't know, Capers Jones is the leading expert on software metrics and his study analyzed thousands of software projects and millions of lines of code for nearly 80 programming languages making this the largest dataset of its kind. Quite something, huh?
@@franciscoflamenco Nevertheless, many, many people take it seriously. Ditto for PYPL, RedMonk, IEEE Spectrum, and Stack Overflow. If one index is garbage, they're ALL garbage.
@@horridohobbies What? I have no idea where that came from. TIOBE is terrible because it's a trailing indicator. Other indices might include info from them (a big mistake in my opinion) but it's usually either optional or at least mitigated by other sources that are not trailing in nature. Using TIOBE for modern day trends is a bit like trying to guess the outcome of a sports match based on previous games: probably better than a completely random guess, but not by much.
Great video. Lisp isn't going anywhere. It will continue to evolve. I agree that future code maintainabilty is the main issue of why it isn't used on large projects, and rightfully so. But you can do anything with it. When you get the Lisp red pill of code is data and data is code it feels like your life changes. I tried learning programming in Java but didn't care for it. I downright hated it as well as OOP in general. It was an unneeded abstraction in most cases. Then I learned interpreted languages like Python, which made so much more sense. Then I discovered Lisp and learned it can be interpreted or compiled. And with compiling, variable declaration, and different data structures, you can make it as fast as C. There is a paper written on its speed capabilities. That blew me away. The history of Lisp is also fascinating as it was based on lambda calculus and so far ahead of its time. Programmers are concerned with wasting time and effort into technologies that fade. Lisp doesn't have that problem. Fortran, Cobol, and Basic have faded but Lisp is still with us and relevant with Clojure and Racket. That tells you something. You can use any data structure in Lisp, it's not just confined to linked lists. You don't have to use cons and cdr. It's AI capabilities will continue to be explored. It's still the ultimate AI language. It sounds cooler at conferences and cocktail parties to say you created a new programming language than to write a new, badass library in an old language. Imagine if a few devs created some revolutionary AI and machine learning libraries in Lisp. That would be huge. Also, some brilliant hacker could create a new web framework that uses Lisp on the backend and cause a massive resurgence like what Rails did for Ruby. You can port any library created in another language to Lisp by creating new bindings. Lisp is the most powerful and expressive language ever. But with great power comes great responsibility. We learned that from Peter Parker. We could get around the maintainablility thing by having more discipline with programmers to not create macros unless it's absolutely necessary. Don't use a macro when a function will do. Also create a macro library/index for the project so other devs can see them and not duplicate efforts. Code must be well documented for future maintenance. C works well because it's small and new devs can make sense of it.
I just saw your video on learning lisp in 2022. I got enthusiastic about learning lisp. And immediately after that video i see this one. And I'm not enthusiastic any more - this video is like a dark cloud added to the previous silver lining. Should I bother learning lisp in 2023?
It's all dependant on the person. To me learning lisp will always be worth it. I made this to talk about how we went from lisp being massive to a more obscure language. (Mostly a victim of circumstances) I don't think it will ever be as popular as python but it is still to this day inspiring developers and language designers. I still use it for projects and find it pretty hard to beat for prototyping. I think of Lisp as a secret weapon.
Lisp macros are very powerful. If you learn how to properly use macros, you’ll love lisp. Every other language tries to create the equivalent of a lisp macro, but other languages rarely make something as powerful as lisp macro. If you are new to Lisp look at Racket because it is easier to learn. The best thing about Lisp is that you can edit your program as your program is running which makes it easier to debug a program, and the second best thing about Lisp is you don’t need to worry about pointers or memory leaks when you write Lisp code.
@@wakkowarner8810 Thank you for your advice. I have always been interested in taking up programming as a hobby. I'm autistic however, & I've had issues with executive function & cognitive inertia my whole life - it's difficult for me to get started doing anything, including beginning to learn programming, & I also suffer with a paralysis of choice as I continue approaching programming but get obsessed with "choosing the correct language". This leads to a situation where I get overwhelmed by the strain of making the "correct" choice even though I understand in a rational sense that there is no such thing as the correct language. I end up floundering like this repeatedly. This is why I want to pick up a language that appeals to me aesthetically, so that my attraction to it helps overcome the inertia that restrains me from beginning this hobby. Interestingly, I've noticed myself always coming back to Lisp as the language to immerse myself in, because it seems so much more "beautiful & elegant", clean & uncluttered by crusty, obtuse, accumulated code, and much less tedious & admin-looking like all the Cs & Javas. I would like to learn how to "make things" with Lisp. Or make other things carry out actions using Lisp. I think this ability to affect the world in a way I can sense would go a long way to overcoming the difficulty in starting & sticking with programming. Is it possible with Racket (or other flavours of Lisp) to create programmes that allow creation of sound &/or visuals, or electronic real world action (is it called embedded programming?) or is that only the domain of so-called lower level languages (like C/C++) ? Or is there a Lisp that can compete at a hobbyist level with those "closer to the metal" languages? Aside from your suggestion of Racket as a good place to start, which flavour of Lisp is the next easiest to tackle (ie. one level of challenge, or one level of efficiency above Racket)?
@@nutbunny10 Sounds like Lisp appeals to you for reasons of beauty and elegance, which is as good a reason as any, especially if you have only personal ideas of what you want to do and no commercial motivation. Plus, I'll second pillmucher67 in stating: Learn Lisp because Lisp makes brain good. To get off square zero, you just need someone to tell you what to do, so I'll fill that role. Start with Racket. Then if that doesn't do all you want, try Clojure. If neither of those do the graphic-ey types of things you want, I'd say see if there's a Lisp/Scheme variant built on top of Java (perhaps Racket or Clojure are but I didn't google that) and call Java libraries to do more complicated stuff.
I remember reading papers on the lisp machine and its practicality, and well, after doing some calculations, it seemed that the pure lisp machine would need several ~6petabytes of RAM What we have now is an impure hack of lisp on imperative and impure system.
Greenspun's Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
I'm tempted to learn LISP but every time I attempt to get conversant with it the syntax puts me off. I'm constantly looking for a strongly typed and expressive language, without a GC, which can be used for systems software development as well as 'higher level' software development - without strait jacketing the programmer - with perf close to C - with reasonable compile times and good C interop.
Have you considered C? I mean that seriously. I hear you say "strongly typed" but I really think you mean something closer to "strictly typed" (conversions are explicit) because why would you limit yourself for no practical benefit? For the beauty of.. not being able?
Check out Carp. It is a LISP that supposedly can achieve the performance of C by implying types at compile time, and uses the borrow feature of Rust to remove the GC. I think it even has some C interop, but it’s just an experiment so far. Not tried it, but has most of what you seek!
You would be wanting Rust probably, with another even newer option being Google's Carbon (the latter might appeal more to those with a history of programming C++ since it's syntactically similar. I'm currently making a project of learning Go and Rust and Carbon all at once. If I turn up in the schizophrenic ward, you'll know why.
Why not Rust? That seems to have every feature you want except for fast compile times. I've heard it can help to use the Cranelift codegen backend, as LLVM is a large part of the reason for Rust's slow compile times.
Back then AI surely was a different field, how brave of them to actually consider Logic in the context of Artificial Intelligence and not just the training of virtual monkeys to type Sheakspeare (or Reddit, if we speak specifically of OpenAI).
Question about the thumbnail - why does the line graph in your chart go from right to left? Time is usually shown from left to right. Or is that explained in the video?
Just fit where I wanted the location of the text to go best. Also didn't want people mistaking it for the classic arrow pointing at a face thumbnail format
I don't think those reasons are essential. The biggest reasons why Lisp is so unpopular are: difficulty of learning declarative programming, tiny ecosystem, and being a committee language.
@@stevenhe3462 Yes, I should have been more precise. I meant they're not committee languages. OTOH, Python has a quite extensive standard library and lots and lots of third party libraries, and it has many declarative parts, like List, Dict, and Generator Expressions, and the newly added Match Statement. It's a Lisp in disguise.
Emacs is a great gateway to get comfy with parens and fan out from there into other LISPs. Enjoy the learning paths you'll take. Tip: Read The Little Schemer, I just flipped through it again for nostalgic reasons (reminds me of a time in CS where I was still a kiddo and just getting into writing code and thus romanticize that era)... Don't find it an optimal didactic method for myself but enjoyed the read.
It seems to me the reason Lisp isn't used is power in labour market. The writer of the program would have more leverage power and would command more demands in work force. Much easier to replace someone if need be when using the other popular languages today which makes it cheaper for companies. Barrier to entry at the start sounds like why it wasn't popular for homegrown programmers.
Java won in the enterprise because it's "portable" and had the weight of a company behind it, but also because it has a very strict syntax and is C-like enough that everyone who went to college in the US can understand/learn it will minimal effort, meaning companies who adopt it had a large hiring pool of potentially inexperienced programmers, as opposed to a much smaller pool of more experienced/well-versed programmers
most actual java code is completely unreadable though, it is so complicated it can only edited using a sophisticated IDE, and even a simple system cannot even begin to be understood since the logic and behavior is spread to thousands of different source code and XML configuration files so the signal to noise ratio is to a first approximation 100% noise
i have heard the myth about portable java code for years, and am still waiting to find anyone who actually writes it. most programmers grow up using a single infrastructure like for example windows, and tend to encode so many of the shortcuts from that infrastructure into the code that when they try and run it on any other platform it explodes and does not work at all. to write portable code, you must write portable code and test it against your targets as early as you can. i know of more than one project developed on a windows laptop, but targeted to be a multi user unix app, where the built in assumptions meant it would only work single user on windows, as the developer had no experience of any other platform. in most cases, it required a near complete rewrite with continual testing against the destination platform to get it to work, with the original implementation being seen as only any good as a demonstrator project.
I don't think CL/Lisp in general's window has closed. While obviously not as old as Lisp, Ruby was around a LONG time before Rails made it explode in popularity. The right library to do something people want to do that makes them feel highly effective can get people on any bandwagon. The hard part is figuring out what that niche is that isn't already being served well by some language. Obviously the ML train has sailed and Python + R + Julia has it mostly wrapped up and only way you're breaking ground there is something SUPER revolutionary, which could include as easy to write but faster to iterate, but whatever.
Isn't Julia a LISP? It has support for Symbols and quasi-quoting, and is based on a LISP. Its basis is the ease of use of having access to the parse tree to optimize code I believe.
@@aoeu256 my understanding is sort of. How much so depends on how much you think s expressions are required to be a lisp. But there is lisp under the covers I hear
@@aoeu256 I don't think quasiquoting makes something Lisp. Lisp didn't even get macros until 1963. There are even people who say Scheme, Racket, and Clojure aren't Lisps, because s-expressions and parentheses don't make it Lisp; in their view, it has to trace its lineage back to LISP 1.5. To call Scheme "a Lisp" would be like calling Java "a C," whereas Common Lisp is to Lisp 1.5, MacLisp, Interlisp, etc. as C++ or Objective-C is to C.
As I see it, Lisp has won. JavaScript is conceptually based on Self and Scheme. PHP, Python, Perl, and Ruby are also conceptually very close to Lisp - they're all practically Lisps with syntax. Many programming techniques were first developed in the Lisp world and were later introduced in other languages.Lexical scope comes to mind. Also Garbage Collection. Delimited Coroutines can be found some modern languages, Python calls them Generators, C# too, I think. And some modern compilers use Continuation Passing Style. The whole point of Lisp isn't that it has a certain syntax and semantics, it is that its syntax and semantics are programmable. That makes it easy to try out new programming ideas without having to invent a syntax and write a compiler for it. Even building a simple Lisp interpreter yourself is trivial. Building software with Lisp is also possible, as shown by Clojure. But almost nobody programs in Lisp because almost nobody programs in Lisp. It has become a self-fulfilling prophecy by now. And no, languages with a C-based syntax don't have fewer brackets, they just have more kinds and in different places. After you play around with Lisp for an afternoon, you don't even see the brackets anymore. You'll learn, in fact, that Lisp's bracket-based non-syntax is the key to easily writing macros and extend its syntax and semantics. Just give it a try already.
@@horridohobbies I agree about their butt-ugliness. That's why I never really bothered to learn any of them. When I called them "conceptually very close to Lisp" and "practically Lisps with syntax", that was intentional hyperbole. I know they're not really Lisps. They all do have first class functions, though, and many programming techniques from Lisp can therefor be used in these languages. C, C#, and Java are slowly catching up, but AFAIK neither the JVM, nor the CLR do support tail call elimination. Sadly, neither does Python, which I otherwise really like. With its metaclass magic it's also somewhat programmable.
I would say that it's that managed/garbage-collected languages have won, not Lisp. Most programming languages resemble C in their syntax (e.g. Go, Java, JavaScript, C#), are not homoiconic, and don't use S-expressions, so I wouldn't say Lisp has won. There are a couple popular languages that don't resemble C, though, such as Python, Ruby, Lua, Scala, and Bash.
1,리스 언는 리스퍼 로 작 성 되어는 가, ,수치 표현 되어 문자 출력 값, 언어 출력 , 구조 화 되어나, 아니면 다시 작성 되어야 한다..2,./0,1로 리스퍼 기본 값으로 ,,라호와 숫자 입력 ,알파벳 , 문자 입력 , ....언어 입력 , 으로 구조화 체적 화 같아요 . 3,이것은 최소 비용 실행 값의 축구 , 4,정의로 부터 ,.5, 혼자의 생각 기록 해보아요
You can also argue C has won, because most languages have syntax that resembles C to some extent, and don't have much metaprogramming ability, just like C. But that's a really vague and broad definition of "win."
Just imagine all the work hours, spent on rust and zig and llvm and (and the weekend spent on python) and Haskell and whatnot - all going into making Common Lisp perfect? This, my friends would be heaven on earth.
Lisp isn't heavy to learn. Here's some C/C++/C#/Java code: foo(bar, baz); And here's the same code in Clojure/Scheme/Common Lisp: (foo bar baz) Now you now Lisp.
Back in the 80's we learned Lisp on IBM's Lisp/VM while at the University of Maryland. Recursion seemed so seamless in Lisp. I can't say why, later I felt that my work with Lisp helped me feel more comfortable writing with SQL queries.
Lisp makes it easy to modify code when the program is running and extend the language using macros. It is hard to write self modifying code, and it is hard to use macros to extend the language. Lisp makes it easy to write compilers for specialized domain-specific languages, but since most people don’t want to write compilers to extend the language to solve hard problems in a concise way. Lisp is not popular because most programmers don’t want to write compilers for new languages.
Indeed it does. My point was that it isn't the "go to datastructure" people need to identify when you use them which is fine so long as it is identified as a bottleneck.
Your comments on Common Lisp performance are just plain wrong, btw. It has (without additional libraries and right out of the box): arrays, hash-tables, ... So the data structures are not the reason. And Common Lisp is fast (SBCL for example). Python is not even in the same ball park. So, you cannot argue that perfomance was the reason Common Lisp did not become main stream if mainstream python is by a factor of 30 slower, 25 years later and popular....
I never said performance was the only reason common lisp did not become mainstream. Some could see it as a factor when compared to languages that began to take its place but it definitely was not the soul or even main reason.
I think the curse of lisp describes the problem really well, Lisp community is a disconnected community of lone wolves or lone tigers and this is why Lisp has fallen. However Lisp has raise and fall multiple times. What really has killed Lisp is ChatGPT.
I'm thinking generative Ai's will lead to the development of a standardised pseudo code style language that can encapsulate various patterns in shorthand. An intermediate highly readable language that can be used to generate code in a bunch of languages using an LLM. Is lisp a contender?
You can do the same thing with a much more suitable syntax, and when a program actually leverages all these features, compilers generally struggle (to put it lightly.)
@@sjatkins and yet lisp compilers dont rank on the performance thing .. wonder why that is? .. occams razor says that you are not being forthright, yes?
the syntax cant be saved - the importance of syntax is always underestimated - lisp is within the class of "systematic" syntaxes and its not a good outcome from the humans perspective
@@styleisaweapongenuine question....have you ever actually written a serious program in Lisp? Systematic syntax enables that syntax to be extremely simple. There are, in fact, 4 pieces of syntax of which I am aware (depends a bit on dialect). This makes Lisp code completely readable in about 5 minutes. The other pole in the spectrum of syntax is COBOL, and in my opinion, the path between the two is monotonic.
@@styleisaweapon Humans work systematically so how is a systematic syntax bad? Although syntax may be "horrendous" to a C or a Java developer, once they get used to it, it does become one of the biggest selling points
@@duncanw9901you are claiming value in "extremely simple" but you never explained that value .. C++ templates are "extremely simple" by the same metric but we know that other languages that tackled generics did it much better, by actually considering features when defining syntax.
I was exposed to LISP back in the 1980s in college. I wS very impressed by it's simplicity and power. Too bad the academics at the University of Chicago couldn't teach.
This is a thing that most people miss -- the social aspect of programming. A bad teacher ruins the experience, often with too much emphasis on deep and clever code introduced far too early. Ten colleagues spitting out a ton of code (even if most of it is boilerplate) and happily sharing is a strong motivator; one weird guy is a demotivator, even if the code is great. My first contact with Lisp in academics was "write an A* search", not "hello, world". Luckily I had a good friend who got me through that, and I love writing in Lisp. Not having that kind of friend, not a single one of my 50 classmates ever wrote another line of Lisp, and I bet that to this day they badmouth it with all the tropes we hear -- slow, write-only, weird, etc etc.
the point to remember about academics, is that in most countries, getting to the point where you are expected to teach does not require any exposure on how to teach. teaching is not even supposed to be the main job of academics, research is. we also learned from ai that the knowledge of how to teach a specific subject is different from the knowledge to be able to do something in that subject. hardly surprising that most high level teachers are rubbish at it.
I don’t know if it’s because the lighting is all on you face and none in the back wall, but this video feels uncomfortably close to your face. It’s like a virtual close-talker. It made it difficult for me to focus on what you were saying. Hopefully that’s not too harsh, as I’m trying to be constructive.
I'm 56. I started in the early 90s with QBasic. Very soon, I started learning C and Prolog. Later Visual Basic, Java and C#, but some 15 years ago I found Python and loved it. I got into Lisp (Racket and Clojure) only a few years ago and instantly loved it as much as my favorite language, Prolog. Now I'm looking for a job as a Clojure developer, but it seems that my country, Germany, is not yet ready for Lisp, a language from 1958.
I learnt and used Franz Lisp for a computational linguistics course at the University of Denver in 1984. I dreamt left and right parenthesis my first two nights. --
@@wakkowarner8810 Is this possible in any editors? And if the answer is yes, EMACS, then for most people the answer is really, no 🙂 I've done Lisp a few times over the years (first time in 1989) and as late as last week the editors still do not really help (Vim and VS code)
The problem with lisp is that computers don't use lisp. They use ML. So if you want to learn how computers work, C is a natural choice, for a first language, or maybe Java if you want to obscure a few things. If you go beyond that you start separating people from the computer and that never ends well.
Having been a programmer of the 70s thru 90s I saw how C and it's ilk became popular because of it's (unnecessarily) arcane syntax so some programmers could play their game "you can't figure out what my code does, ha, ha, ha."
In Short, Lisp died because of its syntax. The syntax lacks appeal, and syntax is the most highly visible component of a language. Syntax is a part of what markets a language, and LISPs marketing strategy was not progressive, to say the least. Nobody likes the syntax of Lisp. They just like the assumed benefits of it. Other people created other languages that *appealed* to them, and clearly, if LISPs syntax had appealed to them, they would have designed their language with that syntax. Well guess what, nobody else did! What does that tell you? Another thing to note, is that when LISP fans advocate for LISP syntax, visual, aesthetic and subjective appeal are not used as one of their arguments. Rather, it is the simplicity of the syntax's rules that is argued for. A language is *defined* by its syntax so prevalently in the human mind. If it weren't for the fact that language, as a practical tool, is meant to be read just as much as it is to be written, then this lack of appeal being such a prevalent factor could be more easily attributed to availability bias formed from the common negative experience of all those parenthesis. The truth may be that, as an industry, we have not thought through the psychology and pragmatics of the syntax of language, and how to optimize language for human psychology and for optimal programming outcomes. Languages really are a form of user interface for a reader and writer, and really deserve the approaches and perspectives of UI/UX design, psychological engineering, ergonomics, and human performance optimization. Human preferences for syntax really do comprise a highly psychological and emotional subject matter, and we know from psychology that humans are primarily emotion-driven. In psychology, it is well known that negative emotions carry 3 times the weight of positive emotions, and that in healthy relationships "for every one negative feeling or interaction between partners, there must be five positive feelings or interactions." Perhaps a similar relationship exists beteen humans and their "things".. We can extrapolate that when LISPs syntax is a regularly-occuring negative experience for newcomers, it pretty much keeps most people away. The movie was decent, as it was very focused on getting into details about LISP.
For me it was the other way around: I was getting sick of syntax which brought me to Lisp. For the most part, syntax in programming languages is just another thing one must learn. Lisp OTOH is so simple with its non-syntax. It's just a sequential form of a tree that defines a computation. The same thing a compiler produces internally. I believe that in the far future, after we've tried everything, there'll be only two languages left standing, something very C-like, and Lisp.
@@pillmuncher67 You're probably the rare exception. Most people prefer not to learn something new, but stick to the familiar. Syntax that resembles what people are more familiar with, is the syntax that people will be more up for learning. You really think that other languages will be forgotten in the face of LISP? History is not on your side - I think history is a sufficiently robust indicator of the future, in the case of LISP.
Lisp fell out of favor among developers because it did not offer what consumers wanted: performance. It doesn't matter that Lisp can do logic thinking elegantly if a badly written if-then-else C/C++ program can outperform it 10 to 1. Consumers don't see the elegance in the language. What they see is how fast they can get results. In terms of abstraction, Lisp is several abstraction layers away from the microprocessor as designed today. C/C++ is just one layer above assembly language. it offers better performance over a language which has to go through a thick layer of interpretation and processing to get essentially the same result. Even today, when AI has made a comeback, C/C++ still rules the performance arena and is the language of choice for programming the large language models underpinning ChatGPT and Bard. CUDA is based on C++ and will probably remain that way for some time because of inertia and traction. While Lisp may have a pioneering hand in the development of AI, it is Python which has taken away Lisp's mojo. Python works very well with C++ and Python is the preferred domain specific language for accessing the AI models. Will Lisp ever come back and take over Python's role in AI? Maybe. Lisp and similar functional languages are very good at implementing domain specific languages so Lisp could still be the gateway to AI. But the heart of AI will remain C and C++ for the near future. Performance still matters.
At the time when Lisp was falling out of favour, that wasn't the case (Lisp could outperform C on Sun workstations, for example); the only reason Lisp suffers in performance is because it fell out of favour, so there's not much work done on Lisp compilers; the space for improvement is even bigger with modern hardware.
The parentheses are comprehensible if you learn to see them correctly. From a beginner's point of view, the parentheses are in the wrong place, leading to the illusion you get. The number of parentheses is the same as in other languages, perhaps with the exception of Forth.
Lots of Interesting Silly Parenthesis, or NAMBLA. Of course it was not going anywhere. It really sucked, a lot. Bye bye LISP and Prolog, you wasted my time.
To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/GavinFreeborn/. The first 200 of you will get 20% off Brilliant’s annual premium subscription.
I used to be a compiler writer at AT&T research labs many years ago. I was a member of a small team that developed something called a "common runtime environment" which allowed us to mix code written in Lisp, Prolog, C with classes (an early version of C++), and a few experimental languages of our own. What we found was that Lisp was a write-only language. You could write nice, compact, even clever code, and it was great when you maintained that code yourself. However, when you handed that code over to somebody else to take over, it was far more difficult for them to pick up than with almost all the other languages. This was particularly true as the code based grew. Given that maintainability was paramount, very little production code ended up being written in Lisp. We saw plenty of folks agree it seemed like a great language in theory, but proved to be a maintenance headache. Having said that, Lisp and functional languages in general, did provide great inspiration for other languages to become side-effect-free and, perhaps more importantly, to improve their collection management.
Do you think this could be fixed by having your IDE collect meta-info from static and dynamic program? Like modern IDEs for Python do type inference and other stuff like find callers/callees that help. LISP could classify "macros" (binding, optimization, semantics, replacement, static error checking) and color code them differently, same with functions. Is the Lisp/Perl curse not also a problem in other languages Java(Frameworks,XML), Haskell, Scala? I think in Python it might be less of a problem since there is usually only "one" obvious way of doing things.
Do you think the pros would outweigh the cons with smaller AI assisted teams?
Huh, weird. I’ve written Java programs for 10 years, and Lisp (mainly Clojure) for 3 years, both in team-based settings, and I find Lisp far easier to read and maintain than any Java code bases I’ve worked on. This could be because Java actively encourages developers to write an insane amount of code compared to just about every other language, but I also just love Lisp’s structure. Once I got used to it it became my favorite language, both to read and write.
@@alrightsquinky7798 Did the Clojure based teams have rules against overuse of macros?
@@vagrant1943 The entire language community has evolved rules against macro overuse
Great talk!
Thank goodness that we have Clojure to carry the torch, even though there are only a few of us still paying attention to the land of parens.
Great video, I don't fear for the future of common lisp. It got some greate compiler (SBCL) and a fervent community. Sure it's not perfect, but so far I think it's the best imho. It's also nice to know that my code will still be able to run as long as there's an ansi common lisp compiler.
Definitely, I think I could have gone a bit more into how things are actually better now in spite of adoption falling. Maybe that would be worth talking about in a future video.
of course lisp is still great for white box ai like expert systems, while black box ai like llms and neural nets has a huge number of legal and security issues with it.
it all comes back to how useful the program as data paradigm is for ai.
I wrote tons of applications using autolisp (by Autodesk and used in autocad) in the late 80s and 90s. Also Wrote an NC (numerical controlled) software package for 5-axis machining, sold it for $1,500 per license, it did pretty well.
I don't think so.
I wrote an AutoLISP routine in the early 2000's that could write g-code from AutoCAD entities. It only did 2.5 axis as that's all I really needed at the time, but I could see someone going further with it. Also worked in reverse to read old g-code programs and create 2d lines and arcs in AutoCAD. AutoLISP's integration to AutoCAD was really well done you could pull off a lot of cool things with it.
I write Lisp every day for work. Targeting three separate language VMs. With strange aeons, even death may die.
Probably work with a prolog-based data-store at some point too.
Lisp is cool, one of a kind, take special ability of abstract thinking, especially when when i saw one Lisp program of several hundreds of lines or more at U of Toronto back in the late 80's...how or what are Lisp used for, in the real work ? AI > ML IMO, and Lisp should be also another major part of the AI but under appreciated
Cthulhu fhtagn
If you need someone who knows Prolog, I'd love to work for your company. I'm living in Germany, though.
I think it's important to recognize why Lisp was powerful, not why people *wanted* to believe it was powerful. There is one reason in my view: Homiconicity. The composability and modeling power homoiconicity gives you is unparalleled. The orthodox view has always been that macros and the cons cell were the secret superpowers, which misses the appeal entirely and is a big reason CL floundered. Most problems can be modeled to be solved with runtime functions, even building a DSL, and the best performance is achieved with abstractions on top of arrays. There is a reason that new Lisps like Clojure and Janet focus less on macros and ditch the cons cell: Composability, modeling power, productivity, those are what matter. From there, the way you get good performance is by backing that composability with high-performance data structures like array-lists and hash maps.
Cons cells are the worst idea in LISP (IMO), I think streams and Iterators are better. Other ideas in LISP are symbolic computation, easy to modify eval function, quasi-quoting, macros, condition system, image based development, metadata on symbols. You can make a homoiconic version of languages by giving non-homoiconic languages an s-expression (or other homoiconic syntax) like Hacket or CLisp or Hy(Python). Anyway, does anyone have any stories of queries to change s-expression code to update a library or something?
Can someone translate this into English
@@windows99 "Homiconicity" refers to the ability to treat code as data. "Composability" refers to the ability to combine small functions or operations in a modular manner. So the composability and modeling power Lisp's homoiconicity gives you is considerable because its ability to treat code as data makes it possible to treat small code snippets like Lego bricks as you "snap" them together into some variable meant to model whatever thing or problem all those snippets are supposed to be simulating before you evaluate (i.e. execute) the variable in question. This makes it easier to abstract away details, and you can do this with arrays and hash maps to get better performance than you can with lists, which what Lisp would traditionally use ("Lisp being a truncation of "List Processing"). Does that clear it all up for you?
Everyone does program in LISP! It's just been reincarnated as JavaScript. It's homiconic if you consider it has eval() and JSON.
@@bobweiram6321 Lol. No. We're taking the runtime back from y'all and fixing the last 30 years of bad decisions.
I am here to fulfill the obligation of functional programmers in youtube comments with this PSA: Clojure is a good language.
What's yer opinion on clojurescript
@@ivymuncher Clojure is better than Java. To me, clojurescript is for making websites and webapps. The web framework competition is stiff and there are better ways to build a web app. Clojure is legos. You can figure out how to build a car with legos, but it is easier to buy a Camaro.
Yes, it is merely "functional".
@@ivymuncher Except for small bits here and there, there's no difference between Clojure and ClojureScript. So all advantages of Clojure also apply to ClojureScript.
@@barspinoza good take 👍
This was a pretty good review of the situation. You mention the issue of algorithmic complexity with a language based heavily on linked lists. Another issue is the divergence between CPU and memory retrieval speeds, necesitating on-chip cacheing. That makes linked lists not just algorithmically bad, but bad in a contingent practical way. It also makes it much harder to reason about optimizing performance when using a LISP-like language, compared to a C-like language.
C machine. Lisp machine. Yes
plenty of C code was based on linked lists and trees in the 1980s for sure - there are so many types of trees .. yet there is so little practical use for any of them on modern architectures unless your N is small.
@@styleisaweapon Lots of C code made use of linked lists, but can also use other cache-efficient data structures. Lisps are built on top of linked lists and can't really avoid them.
@@stephenaustin3026 Pretty sure most lisp code doesnt compile down to linked list juggling within inner loops when a decent compiler is handed decent lisp code - its the same argument as for C - the downfall of lisp is the terse syntax
@@styleisaweapon The problem with Lisp is that it didn't have a BDFL + Pep Python process, it fragmented (Scheme & others), it kept a whole lot of cruft from the old days, and was somewhat academic like Haskell (although it seemed more industrial than Haskell...). No new ideas can take hold in Lisp because it will be hated by others, or not adopted. Imagine though if Dylan was in the browser or if Python or JS was based on a good Lisp like Guile or CMUCL somewhat similar to Julia in the browser hmm...
Thanks for this video! Good overview.
Loved this video. Also loved the honorary footnote to early day AI efforts, Symbolic AI in particular, and how they relate to the LISP community. Really interesting how tools and ideas propagate or enjoy adoption. Fascinating to think how the world could have looked different if just a few small changes were in effect. Anyways... Happily LISPing on (Emacs) but have to admit I write Python when it comes to practical ML stuff these days. 😅
Keep these vids coming. Read a request in the comments for more dialect explorations. I'd be curious about that as well.
Would generally also enjoy this style of a documentary/history lesson into other languages.
Great stuff this. 🎉
great work with this video 🚀
Thank you very much!
Thank you for that; there is a lot of good information here.
I think there are more reasons that Lisp "lost" than those mentioned. For example, (I am butchering this quote and I don't recall where I read it) it has been said that most systems written in a language like C will end up with a poorly-written Lisp implementation inside it eventually. This is an observation of the old, but as you know, the number of software developers has doubled every 5 years or so. So it is also an observation that most developers are not in a position to make.
HMM JS is a very poorly-written LISP inside C based browsers... What about Ruby (it lacked optimizations that LISP could do), and Python (no conditions, lacked way of optimizing code or easily doing static analysis like macors, early on poor support for image based development and hot reloading although ipython helped a bit).
@@aoeu256Ruby followed the spirit of Smalltalk - another amazing language/environment.
"Over time, the default language, embodied in a succession of popular languages, has gradually evolved toward Lisp. [...] you can no longer claim to have invented a new language, but only to have designed a new dialect of Lisp ; -)"
Paul Graham in his essay "What Made Lisp Different"
I like your analysis about the rise and fall of Lisp. If you have time I would appreciate a video about the rise and fall of Prolog. Maybe it's similar to Lisp...
Thank you for that walkthrough many lessons on how a tech can miss a window! I Used LISP quite a bit in the 80's during college, and used it a bit on TI Explorer, on of the LISP machines of the time. As you described LISP was not a light weight language. And in the 80's the biggest killer for it was the Mac and PC. Experiements aside, it was not practical for any application development.. In that space, C then C++ fit much better. Fast forward to the internet, while JS is NOTHING like it, however, JSON sure made data sets very easy to construct and manipulate.
I have a hardcover book on NLP with Lisp. I've had it for a while but it's been winking at me furiously for the past couple of months so I'm looking into watching a couple of intro lisp videos and diving in. NLP is a big interest of mine and I'm looking to broaden my horizons.
For NLP, you should also take a look at Prolog.
Living that sweet closure fennel life. God bless
Get on board with Clojure everyone!
that was great. please make more videos about diff dialects and histories revolving around lisp. i'm fairly new to it and i find it absolutely fascinating! while it might not be something useful in a professional sense, i'm really enjoying learning lisp (some common lisp and emacs lisp) and i find the language structure very elegant. but i totally understand why it didn't take off to be honest. it doesn't map well to how CPUs work and there's inherent garbage collection which in many cases becomes a blocker. |
I would love to have more deep dives on the origins and histories of diff dialects. great video
One of my first languages, after English, haven't used it since I was a kid though.. still, almost any programming I do now, I attempt to force the language into that structure..
I love LISP. I got into LISP because of JESS rule engine and eventually created my own open source rule engine. The big roadblock for many developer is s-expression syntax. Over the years I've tried to teach it to other developers and 90% never get over the syntax. Parsing s-expression is elegant and beautiful compared to Java, CSharp and 95% of languages out there.
I'm biased, so take it with a grain of salt. The real power of LISP is logic programming, which causes a steep learning curve. The downside is logic programming is hard and most programmers prefer imperative programs.
When I started programming I was obsessed with game development, So I learned some java. After that I tried C++..... yeah(C++ wasn't for me at the time). And then I went to other languages, lisp is one of my favorite languages. But I really just use what I want and is required at the time. Great video.
I am crazy enough to think a foundation to increase Lisp usage, marketing and viability would make a major difference in how much Lisp is used. Writing far faster code in Lisp than many of the most popular languages (looking at you Python) produce today is trivially easy in Lisp. And the reality is that programmer productivity and maintainable extendable code is WAY more important in the the overwhelming majority of programming done today than raw speed anyway. So I am really tired of this old chestnut.
Anyone that knows anything at all about Common Lisp knows you don't do most everything is cons list. That is an absurd excuse. For how many decades has CL had Just in Time compilation, full arithmetic stack, tons of sophisticated data structures and the best OO system in existence?
Java is modern COBOL and completely sucks in so many ways.
Whats your opinion on what Anthony Lauder talked about that LISPs very power meant that code was hard to understand for other people.
@@aoeu256 Anthony doesn't actually give any specific justification or characterisation of why Lisp is harder to maintain that can be evaluated in a modern context, so his comment doesn't really have much technical value and is merely an anecdote of one guy's career experience instead of a meaningful statement on the engineering drawbacks and strengths of the language.
Possibly. Too beautiful for the rest of the world .
"...the development past these simple prototypes was very slow and seemed to run into a wall very quickly" - unfortunately, this is a concise description of programming projects in general.
2:04 *Beranek, not Birkin.
Yes, thank you batlin, that was bugging me too. Bolt, Beranek & Newman was/is an R&D company near MIT campus that historically did AI and networking and other high-tech research, much of which was done for the Dept. of Defense, and DARPA in particular. Per their current Wikipedia entry, apparently they were bought up by Raytheon in 2009. You can thank them for the Internet you're using at the moment, because they built the original ARPANET. And since we're talking Lisp here, we should note that BBN created the Interlisp variant of Lisp. If any of you happened to use the Logo programming language for kids while you were in elementary school, you can thank BBN for that (and I can only speculate, but I betcha Logo was written in Lisp under the covers). They built some early parallel computers including the BBN Butterfly that I was lucky enough to do some research on.
logo,was definitely written originally as a front end ui for lisp which provided the turtle graphics functions for children, but with a better syntax for those users with the full power of lisp underneath. later it diverged into its own language, but i don't know enough of its later history to know if it still has those abilities.
What about AutoLISP used by AutoCAD?
It's notable that, historically, there've been two languages that share a similar evolutionary trajectory: LISP and Smalltalk. Both languages are VM-based and image-based. Both are very dynamic and flexible. Both had special hardware to run them (in the case of Smalltalk, the Xerox Alto). Both needed expensive hardware (lots of RAM, fast processors, and in the case of Smalltalk, high-resolution displays). Both have experienced massive market fragmentation. Both have been the victims of Java hype. Both missed the mark with respect to the Internet.
However, there are important differences, too. Smalltalk did become mainstream in the 1980s and 1990s. In fact, according to a 1995 IDC report, Smalltalk was the second most popular object-oriented language after C++ and ahead of Objective-C, Object Pascal, CLOS, and Eiffel. It was mainstream enough that IBM chose Smalltalk as the centerpiece of their VisualAge enterprise initiative.
Today, Smalltalk is still used by thousands of enterprises around the globe supported by no fewer than three major commercial Smalltalk vendors: Instantiations, GemTalk Systems, and Cincom. I can't think of any major commercial LISP vendors unless you count Franz and LispWorks.
Clojure (2007) and Pharo (2008) are modern adaptations of LISP and Smalltalk, respectively. Neither language is particularly popular - they don't rank in the Top 50 at TIOBE. For a while, Clojure did receive a lot of hype but now it's nowhere. What happened to it???
Interestingly, when LISP celebrated its 50th anniversary in 2008 (at OOPSLA '08), it was very low key. Last year's celebration of Smalltalk's 50th birthday was pretty awesome: levelup.gitconnected.com/mmxxii-year-long-celebrations-for-smalltalk-bed82541b7db.
Interesting factoid: According to a 2017 study by Capers Jones, Smalltalk is the most productive of all the major programming languages, including C, JavaScript, Lisp, Go, Java, Python, and even Ruby. If you don't know, Capers Jones is the leading expert on software metrics and his study analyzed thousands of software projects and millions of lines of code for nearly 80 programming languages making this the largest dataset of its kind.
Quite something, huh?
@@horridohobbies Maybe it's because humans are better sculptors than they are imagineers?
TIOBE is a garbage index and shouldn't be taken seriously.
@@franciscoflamenco Nevertheless, many, many people take it seriously. Ditto for PYPL, RedMonk, IEEE Spectrum, and Stack Overflow.
If one index is garbage, they're ALL garbage.
@@horridohobbies What? I have no idea where that came from.
TIOBE is terrible because it's a trailing indicator. Other indices might include info from them (a big mistake in my opinion) but it's usually either optional or at least mitigated by other sources that are not trailing in nature. Using TIOBE for modern day trends is a bit like trying to guess the outcome of a sports match based on previous games: probably better than a completely random guess, but not by much.
Make Lisp Great Again
Great work!
Great video!
Can only do programming with Lisp. Also learned how to do formal mathematical proof in the sense of Curry-Howard btw.
Thank you.
Thanx for interesting history aspect of LISP
Great video. Lisp isn't going anywhere. It will continue to evolve. I agree that future code maintainabilty is the main issue of why it isn't used on large projects, and rightfully so. But you can do anything with it. When you get the Lisp red pill of code is data and data is code it feels like your life changes. I tried learning programming in Java but didn't care for it. I downright hated it as well as OOP in general. It was an unneeded abstraction in most cases. Then I learned interpreted languages like Python, which made so much more sense.
Then I discovered Lisp and learned it can be interpreted or compiled. And with compiling, variable declaration, and different data structures, you can make it as fast as C. There is a paper written on its speed capabilities. That blew me away. The history of Lisp is also fascinating as it was based on lambda calculus and so far ahead of its time.
Programmers are concerned with wasting time and effort into technologies that fade. Lisp doesn't have that problem. Fortran, Cobol, and Basic have faded but Lisp is still with us and relevant with Clojure and Racket. That tells you something. You can use any data structure in Lisp, it's not just confined to linked lists. You don't have to use cons and cdr. It's AI capabilities will continue to be explored. It's still the ultimate AI language.
It sounds cooler at conferences and cocktail parties to say you created a new programming language than to write a new, badass library in an old language. Imagine if a few devs created some revolutionary AI and machine learning libraries in Lisp. That would be huge. Also, some brilliant hacker could create a new web framework that uses Lisp on the backend and cause a massive resurgence like what Rails did for Ruby. You can port any library created in another language to Lisp by creating new bindings.
Lisp is the most powerful and expressive language ever. But with great power comes great responsibility. We learned that from Peter Parker. We could get around the maintainablility thing by having more discipline with programmers to not create macros unless it's absolutely necessary. Don't use a macro when a function will do. Also create a macro library/index for the project so other devs can see them and not duplicate efforts. Code must be well documented for future maintenance. C works well because it's small and new devs can make sense of it.
I just saw your video on learning lisp in 2022. I got enthusiastic about learning lisp.
And immediately after that video i see this one. And I'm not enthusiastic any more - this video is like a dark cloud added to the previous silver lining.
Should I bother learning lisp in 2023?
It's all dependant on the person. To me learning lisp will always be worth it. I made this to talk about how we went from lisp being massive to a more obscure language. (Mostly a victim of circumstances)
I don't think it will ever be as popular as python but it is still to this day inspiring developers and language designers. I still use it for projects and find it pretty hard to beat for prototyping. I think of Lisp as a secret weapon.
Lisp macros are very powerful. If you learn how to properly use macros, you’ll love lisp. Every other language tries to create the equivalent of a lisp macro, but other languages rarely make something as powerful as lisp macro. If you are new to Lisp look at Racket because it is easier to learn. The best thing about Lisp is that you can edit your program as your program is running which makes it easier to debug a program, and the second best thing about Lisp is you don’t need to worry about pointers or memory leaks when you write Lisp code.
@@wakkowarner8810 Thank you for your advice.
I have always been interested in taking up programming as a hobby.
I'm autistic however, & I've had issues with executive function & cognitive inertia my whole life - it's difficult for me to get started doing anything, including beginning to learn programming, & I also suffer with a paralysis of choice as I continue approaching programming but get obsessed with "choosing the correct language".
This leads to a situation where I get overwhelmed by the strain of making the "correct" choice even though I understand in a rational sense that there is no such thing as the correct language.
I end up floundering like this repeatedly.
This is why I want to pick up a language that appeals to me aesthetically, so that my attraction to it helps overcome the inertia that restrains me from beginning this hobby.
Interestingly, I've noticed myself always coming back to Lisp as the language to immerse myself in, because it seems so much more "beautiful & elegant", clean & uncluttered by crusty, obtuse, accumulated code, and much less tedious & admin-looking like all the Cs & Javas.
I would like to learn how to "make things" with Lisp. Or make other things carry out actions using Lisp. I think this ability to affect the world in a way I can sense would go a long way to overcoming the difficulty in starting & sticking with programming.
Is it possible with Racket (or other flavours of Lisp) to create programmes that allow creation of sound &/or visuals, or electronic real world action (is it called embedded programming?) or is that only the domain of so-called lower level languages (like C/C++) ?
Or is there a Lisp that can compete at a hobbyist level with those "closer to the metal" languages?
Aside from your suggestion of Racket as a good place to start, which flavour of Lisp is the next easiest to tackle (ie. one level of challenge, or one level of efficiency above Racket)?
Learn Lisp because Lisp makes brain good.
@@nutbunny10 Sounds like Lisp appeals to you for reasons of beauty and elegance, which is as good a reason as any, especially if you have only personal ideas of what you want to do and no commercial motivation. Plus, I'll second pillmucher67 in stating: Learn Lisp because Lisp makes brain good. To get off square zero, you just need someone to tell you what to do, so I'll fill that role. Start with Racket. Then if that doesn't do all you want, try Clojure. If neither of those do the graphic-ey types of things you want, I'd say see if there's a Lisp/Scheme variant built on top of Java (perhaps Racket or Clojure are but I didn't google that) and call Java libraries to do more complicated stuff.
I remember reading papers on the lisp machine and its practicality, and well, after doing some calculations, it seemed that the pure lisp machine would need several ~6petabytes of RAM
What we have now is an impure hack of lisp on imperative and impure system.
Greenspun's Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
I'm tempted to learn LISP but every time I attempt to get conversant with it the syntax puts me off. I'm constantly looking for a strongly typed and expressive language, without a GC, which can be used for systems software development as well as 'higher level' software development - without strait jacketing the programmer - with perf close to C - with reasonable compile times and good C interop.
Have you considered C? I mean that seriously. I hear you say "strongly typed" but I really think you mean something closer to "strictly typed" (conversions are explicit) because why would you limit yourself for no practical benefit? For the beauty of.. not being able?
Check out Carp. It is a LISP that supposedly can achieve the performance of C by implying types at compile time, and uses the borrow feature of Rust to remove the GC. I think it even has some C interop, but it’s just an experiment so far. Not tried it, but has most of what you seek!
You would be wanting Rust probably, with another even newer option being Google's Carbon (the latter might appeal more to those with a history of programming C++ since it's syntactically similar. I'm currently making a project of learning Go and Rust and Carbon all at once. If I turn up in the schizophrenic ward, you'll know why.
@@styleisaweapon C is not strongly typed, and many conversions are implicit. int a = 2.5; compiles with gcc without warnings.
Why not Rust? That seems to have every feature you want except for fast compile times. I've heard it can help to use the Cranelift codegen backend, as LLVM is a large part of the reason for Rust's slow compile times.
Back then AI surely was a different field, how brave of them to actually consider Logic in the context of Artificial Intelligence and not just the training of virtual monkeys to type Sheakspeare (or Reddit, if we speak specifically of OpenAI).
Question about the thumbnail - why does the line graph in your chart go from right to left? Time is usually shown from left to right. Or is that explained in the video?
Just fit where I wanted the location of the text to go best. Also didn't want people mistaking it for the classic arrow pointing at a face thumbnail format
omg bless you for this
I don't think those reasons are essential. The biggest reasons why Lisp is so unpopular are: difficulty of learning declarative programming, tiny ecosystem, and being a committee language.
That's only Common Lisp. Clojure and Scheme are quite different in that regard.
@@pillmuncher67 How are they different except not being committee languages?
@@stevenhe3462 Yes, I should have been more precise. I meant they're not committee languages.
OTOH, Python has a quite extensive standard library and lots and lots of third party libraries, and it has many declarative parts, like List, Dict, and Generator Expressions, and the newly added Match Statement. It's a Lisp in disguise.
You convinced me to learn Lips! As an Emacs user, it was probably inevitable....
Emacs is a great gateway to get comfy with parens and fan out from there into other LISPs. Enjoy the learning paths you'll take. Tip: Read The Little Schemer, I just flipped through it again for nostalgic reasons (reminds me of a time in CS where I was still a kiddo and just getting into writing code and thus romanticize that era)... Don't find it an optimal didactic method for myself but enjoyed the read.
@@vidbina Java Applets are too goods. that reason Java vs Lisp, Lisp is no future.
It seems to me the reason Lisp isn't used is power in labour market. The writer of the program would have more leverage power and would command more demands in work force. Much easier to replace someone if need be when using the other popular languages today which makes it cheaper for companies. Barrier to entry at the start sounds like why it wasn't popular for homegrown programmers.
Java won in the enterprise because it's "portable" and had the weight of a company behind it, but also because it has a very strict syntax and is C-like enough that everyone who went to college in the US can understand/learn it will minimal effort, meaning companies who adopt it had a large hiring pool of potentially inexperienced programmers, as opposed to a much smaller pool of more experienced/well-versed programmers
most actual java code is completely unreadable though, it is so complicated it can only edited using a sophisticated IDE, and even a simple system cannot even begin to be understood since the logic and behavior is spread to thousands of different source code and XML configuration files so the signal to noise ratio is to a first approximation 100% noise
i have heard the myth about portable java code for years, and am still waiting to find anyone who actually writes it.
most programmers grow up using a single infrastructure like for example windows, and tend to encode so many of the shortcuts from that infrastructure into the code that when they try and run it on any other platform it explodes and does not work at all.
to write portable code, you must write portable code and test it against your targets as early as you can. i know of more than one project developed on a windows laptop, but targeted to be a multi user unix app, where the built in assumptions meant it would only work single user on windows, as the developer had no experience of any other platform.
in most cases, it required a near complete rewrite with continual testing against the destination platform to get it to work, with the original implementation being seen as only any good as a demonstrator project.
You should have showed the XKCD cartoon about it.
~ 2:00 - Is that working off an Unisys-1100 series?
Well the concepts of lisp like meta programming and closures are the important part of IMO.
I don't think CL/Lisp in general's window has closed. While obviously not as old as Lisp, Ruby was around a LONG time before Rails made it explode in popularity. The right library to do something people want to do that makes them feel highly effective can get people on any bandwagon.
The hard part is figuring out what that niche is that isn't already being served well by some language. Obviously the ML train has sailed and Python + R + Julia has it mostly wrapped up and only way you're breaking ground there is something SUPER revolutionary, which could include as easy to write but faster to iterate, but whatever.
Isn't Julia a LISP? It has support for Symbols and quasi-quoting, and is based on a LISP. Its basis is the ease of use of having access to the parse tree to optimize code I believe.
@@aoeu256 my understanding is sort of. How much so depends on how much you think s expressions are required to be a lisp. But there is lisp under the covers I hear
@@aoeu256 I don't think quasiquoting makes something Lisp. Lisp didn't even get macros until 1963.
There are even people who say Scheme, Racket, and Clojure aren't Lisps, because s-expressions and parentheses don't make it Lisp; in their view, it has to trace its lineage back to LISP 1.5. To call Scheme "a Lisp" would be like calling Java "a C," whereas Common Lisp is to Lisp 1.5, MacLisp, Interlisp, etc. as C++ or Objective-C is to C.
As I see it, Lisp has won. JavaScript is conceptually based on Self and Scheme. PHP, Python, Perl, and Ruby are also conceptually very close to Lisp - they're all practically Lisps with syntax. Many programming techniques were first developed in the Lisp world and were later introduced in other languages.Lexical scope comes to mind. Also Garbage Collection. Delimited Coroutines can be found some modern languages, Python calls them Generators, C# too, I think. And some modern compilers use Continuation Passing Style.
The whole point of Lisp isn't that it has a certain syntax and semantics, it is that its syntax and semantics are programmable. That makes it easy to try out new programming ideas without having to invent a syntax and write a compiler for it. Even building a simple Lisp interpreter yourself is trivial.
Building software with Lisp is also possible, as shown by Clojure. But almost nobody programs in Lisp because almost nobody programs in Lisp. It has become a self-fulfilling prophecy by now. And no, languages with a C-based syntax don't have fewer brackets, they just have more kinds and in different places. After you play around with Lisp for an afternoon, you don't even see the brackets anymore. You'll learn, in fact, that Lisp's bracket-based non-syntax is the key to easily writing macros and extend its syntax and semantics. Just give it a try already.
JavaScript, PHP, Perl, and Ruby are nothing like LISP. Their syntax and semantics are NOT programmable.
*And* their syntax is butt-ugly.
@@horridohobbies I agree about their butt-ugliness. That's why I never really bothered to learn any of them.
When I called them "conceptually very close to Lisp" and "practically Lisps with syntax", that was intentional hyperbole. I know they're not really Lisps. They all do have first class functions, though, and many programming techniques from Lisp can therefor be used in these languages. C, C#, and Java are slowly catching up, but AFAIK neither the JVM, nor the CLR do support tail call elimination. Sadly, neither does Python, which I otherwise really like. With its metaclass magic it's also somewhat programmable.
I would say that it's that managed/garbage-collected languages have won, not Lisp. Most programming languages resemble C in their syntax (e.g. Go, Java, JavaScript, C#), are not homoiconic, and don't use S-expressions, so I wouldn't say Lisp has won.
There are a couple popular languages that don't resemble C, though, such as Python, Ruby, Lua, Scala, and Bash.
@@somebodyelse9130See my answer to @horridohobbies .
1,리스 언는 리스퍼 로 작 성 되어는 가, ,수치 표현 되어 문자 출력 값, 언어 출력 , 구조 화 되어나, 아니면 다시 작성 되어야 한다..2,./0,1로 리스퍼 기본 값으로 ,,라호와 숫자 입력 ,알파벳 , 문자 입력 , ....언어 입력 , 으로 구조화 체적 화 같아요 . 3,이것은 최소 비용 실행 값의 축구 , 4,정의로 부터 ,.5, 혼자의 생각 기록 해보아요
one day Lisp will return - as IO for LLMs
You can argue that Lisp has won -- Javascript is sugared Scheme which is lexically bound Lisp.
So are Python, Perl, Ruby, and PHP.
You can also argue C has won, because most languages have syntax that resembles C to some extent, and don't have much metaprogramming ability, just like C. But that's a really vague and broad definition of "win."
@@somebodyelse9130 C wasn't the first with such syntax.
Blink twice if you being held by LISP nerds. 😅
Blink Blink! Being held by LispGPT. Be careful if you try to rescue me. They have lots of dangerous parentheses.
As stress increases every language devolves to lisp
(Message ‘good ‘video)
Just imagine all the work hours, spent on rust and zig and llvm and (and the weekend spent on python) and Haskell and whatnot - all going into making Common Lisp perfect? This, my friends would be heaven on earth.
15:58 caption says "the is still an active CL community" the should be there?
Ya last minute change wish I had noticed it sooner 😅
I need to do chemical simulation programs and I was recommended LISP over C++ but god, why does LISP feel so heavy to learn.
Lisp isn't heavy to learn. Here's some C/C++/C#/Java code:
foo(bar, baz);
And here's the same code in Clojure/Scheme/Common Lisp:
(foo bar baz)
Now you now Lisp.
Back in the 80's we learned Lisp on IBM's Lisp/VM while at the University of Maryland. Recursion seemed so seamless in Lisp. I can't say why, later I felt that my work with Lisp helped me feel more comfortable writing with SQL queries.
I’ll still study thid
Lisp makes it easy to modify code when the program is running and extend the language using macros. It is hard to write self modifying code, and it is hard to use macros to extend the language. Lisp makes it easy to write compilers for specialized domain-specific languages, but since most people don’t want to write compilers to extend the language to solve hard problems in a concise way. Lisp is not popular because most programmers don’t want to write compilers for new languages.
Lisp is also an excellent way of building an insecure application.
Well there's Clojure
11:00 Common Lisp has arrays.
Indeed it does. My point was that it isn't the "go to datastructure" people need to identify when you use them which is fine so long as it is identified as a bottleneck.
Your comments on Common Lisp performance are just plain wrong, btw. It has (without additional libraries and right out of the box): arrays, hash-tables, ... So the data structures are not the reason. And Common Lisp is fast (SBCL for example). Python is not even in the same ball park. So, you cannot argue that perfomance was the reason Common Lisp did not become main stream if mainstream python is by a factor of 30 slower, 25 years later and popular....
I never said performance was the only reason common lisp did not become mainstream. Some could see it as a factor when compared to languages that began to take its place but it definitely was not the soul or even main reason.
I think the curse of lisp describes the problem really well, Lisp community is a disconnected community of lone wolves or lone tigers and this is why Lisp has fallen. However Lisp has raise and fall multiple times. What really has killed Lisp is ChatGPT.
I'm thinking generative Ai's will lead to the development of a standardised pseudo code style language that can encapsulate various patterns in shorthand. An intermediate highly readable language that can be used to generate code in a bunch of languages using an LLM. Is lisp a contender?
You can do the same thing with a much more suitable syntax, and when a program actually leverages all these features, compilers generally struggle (to put it lightly.)
Nope. State of the Art dynamic Just in Time (JIT) compilers originated and were perfected in Lisp long ago. Try again.
@@sjatkins and yet lisp compilers dont rank on the performance thing .. wonder why that is? .. occams razor says that you are not being forthright, yes?
beranek
"If you look at the landscape today, something is wrong." - so true 🙂
How did it not fail, you explained why it failed isn't that failure?
LET"S FUCKING GOOOOOOOOOOOOOOOO Gavin. You getting ads for a company i already used (mainly due to ads tooj but is good).
You might be surprised to know that LispWorks is thriving very well.
I think the only hope for mass adoption of any lisp language is to resurrect the lisp machine in 2 tiers: the prosumer and the enterprise
the syntax cant be saved - the importance of syntax is always underestimated - lisp is within the class of "systematic" syntaxes and its not a good outcome from the humans perspective
@@styleisaweapongenuine question....have you ever actually written a serious program in Lisp?
Systematic syntax enables that syntax to be extremely simple. There are, in fact, 4 pieces of syntax of which I am aware (depends a bit on dialect). This makes Lisp code completely readable in about 5 minutes.
The other pole in the spectrum of syntax is COBOL, and in my opinion, the path between the two is monotonic.
@@styleisaweapon Humans work systematically so how is a systematic syntax bad?
Although syntax may be "horrendous" to a C or a Java developer, once they get used to it, it does become one of the biggest selling points
@@bushek502 because the system isnt the goal
@@duncanw9901you are claiming value in "extremely simple" but you never explained that value .. C++ templates are "extremely simple" by the same metric but we know that other languages that tackled generics did it much better, by actually considering features when defining syntax.
Kriz
So all would be well if there was never an internet?
Yes, and on so many levels.
I was exposed to LISP back in the 1980s in college. I wS very impressed by it's simplicity and power. Too bad the academics at the University of Chicago couldn't teach.
This is a thing that most people miss -- the social aspect of programming. A bad teacher ruins the experience, often with too much emphasis on deep and clever code introduced far too early. Ten colleagues spitting out a ton of code (even if most of it is boilerplate) and happily sharing is a strong motivator; one weird guy is a demotivator, even if the code is great. My first contact with Lisp in academics was "write an A* search", not "hello, world". Luckily I had a good friend who got me through that, and I love writing in Lisp. Not having that kind of friend, not a single one of my 50 classmates ever wrote another line of Lisp, and I bet that to this day they badmouth it with all the tropes we hear -- slow, write-only, weird, etc etc.
the point to remember about academics, is that in most countries, getting to the point where you are expected to teach does not require any exposure on how to teach. teaching is not even supposed to be the main job of academics, research is.
we also learned from ai that the knowledge of how to teach a specific subject is different from the knowledge to be able to do something in that subject.
hardly surprising that most high level teachers are rubbish at it.
I don’t know if it’s because the lighting is all on you face and none in the back wall, but this video feels uncomfortably close to your face. It’s like a virtual close-talker. It made it difficult for me to focus on what you were saying. Hopefully that’s not too harsh, as I’m trying to be constructive.
Thanks! I appreciate the feedback. I'll try to mix up my positioning a bit. I definitely see what you mean
To me, lisp is the most versatile language. It’s too bad you have to read through all those parenthesis.
I'm 56. I started in the early 90s with QBasic. Very soon, I started learning C and Prolog. Later Visual Basic, Java and C#, but some 15 years ago I found Python and loved it. I got into Lisp (Racket and Clojure) only a few years ago and instantly loved it as much as my favorite language, Prolog. Now I'm looking for a job as a Clojure developer, but it seems that my country, Germany, is not yet ready for Lisp, a language from 1958.
slug russell
Blink
Lisp will be like learning Latin for english.
easy
I shall always remember the Devil's DP Dictionary definition of LISP:
Lots of
Irritating and
Spurious
Parentheses.
That was a solid dose of copium.
you blink way to often bro
I think it's a long term side effect of an old concussion or something. I wish I didn't but it is what it is
Let's be honest, the average programmer trying to learn list is still trying to match parenthesis(I'm kidding, calm down).
If you are not letting your text editor match parenthesis for you, you are doing it wrong.
I learnt and used Franz Lisp for a computational linguistics course at the University of Denver in 1984. I dreamt left and right parenthesis my first two nights.
--
@@wakkowarner8810 Is this possible in any editors? And if the answer is yes, EMACS, then for most people the answer is really, no 🙂 I've done Lisp a few times over the years (first time in 1989) and as late as last week the editors still do not really help (Vim and VS code)
The problem with lisp is that computers don't use lisp. They use ML. So if you want to learn how computers work, C is a natural choice, for a first language, or maybe Java if you want to obscure a few things. If you go beyond that you start separating people from the computer and that never ends well.
Having been a programmer of the 70s thru 90s I saw how C and it's ilk became popular because of it's (unnecessarily) arcane syntax so some programmers could play their game "you can't figure out what my code does, ha, ha, ha."
That sounds like what C++ programmers do with their "clever" code
@@rusi6219 Some programmers went out of their way to use every feature they could to show that they knew all the cleaver things.
❤
so lisp failed due to garbage decision makeing kk.
You need more sleep.
I watched this video thinking it was about the speech impediment.
In Short, Lisp died because of its syntax. The syntax lacks appeal, and syntax is the most highly visible component of a language. Syntax is a part of what markets a language, and LISPs marketing strategy was not progressive, to say the least. Nobody likes the syntax of Lisp. They just like the assumed benefits of it. Other people created other languages that *appealed* to them, and clearly, if LISPs syntax had appealed to them, they would have designed their language with that syntax. Well guess what, nobody else did! What does that tell you? Another thing to note, is that when LISP fans advocate for LISP syntax, visual, aesthetic and subjective appeal are not used as one of their arguments. Rather, it is the simplicity of the syntax's rules that is argued for.
A language is *defined* by its syntax so prevalently in the human mind. If it weren't for the fact that language, as a practical tool, is meant to be read just as much as it is to be written, then this lack of appeal being such a prevalent factor could be more easily attributed to availability bias formed from the common negative experience of all those parenthesis. The truth may be that, as an industry, we have not thought through the psychology and pragmatics of the syntax of language, and how to optimize language for human psychology and for optimal programming outcomes. Languages really are a form of user interface for a reader and writer, and really deserve the approaches and perspectives of UI/UX design, psychological engineering, ergonomics, and human performance optimization. Human preferences for syntax really do comprise a highly psychological and emotional subject matter, and we know from psychology that humans are primarily emotion-driven.
In psychology, it is well known that negative emotions carry 3 times the weight of positive emotions, and that in healthy relationships "for every one negative feeling or interaction between partners, there must be five positive feelings or interactions." Perhaps a similar relationship exists beteen humans and their "things".. We can extrapolate that when LISPs syntax is a regularly-occuring negative experience for newcomers, it pretty much keeps most people away.
The movie was decent, as it was very focused on getting into details about LISP.
For me it was the other way around: I was getting sick of syntax which brought me to Lisp. For the most part, syntax in programming languages is just another thing one must learn. Lisp OTOH is so simple with its non-syntax. It's just a sequential form of a tree that defines a computation. The same thing a compiler produces internally. I believe that in the far future, after we've tried everything, there'll be only two languages left standing, something very C-like, and Lisp.
@@pillmuncher67 You're probably the rare exception. Most people prefer not to learn something new, but stick to the familiar. Syntax that resembles what people are more familiar with, is the syntax that people will be more up for learning. You really think that other languages will be forgotten in the face of LISP? History is not on your side - I think history is a sufficiently robust indicator of the future, in the case of LISP.
@@R.GrantD History is not on my side? Lisp is one of the very few languages that just won't die. It was invented in 1958, only Fortran is older.
And once you get effective in a Lisp (Clojure, in my case), other programming languages seem unnecessarily baroque.
Lisp fell out of favor among developers because it did not offer what consumers wanted: performance. It doesn't matter that Lisp can do logic thinking elegantly if a badly written if-then-else C/C++ program can outperform it 10 to 1. Consumers don't see the elegance in the language. What they see is how fast they can get results. In terms of abstraction, Lisp is several abstraction layers away from the microprocessor as designed today. C/C++ is just one layer above assembly language. it offers better performance over a language which has to go through a thick layer of interpretation and processing to get essentially the same result.
Even today, when AI has made a comeback, C/C++ still rules the performance arena and is the language of choice for programming the large language models underpinning ChatGPT and Bard. CUDA is based on C++ and will probably remain that way for some time because of inertia and traction.
While Lisp may have a pioneering hand in the development of AI, it is Python which has taken away Lisp's mojo. Python works very well with C++ and Python is the preferred domain specific language for accessing the AI models. Will Lisp ever come back and take over Python's role in AI? Maybe. Lisp and similar functional languages are very good at implementing domain specific languages so Lisp could still be the gateway to AI.
But the heart of AI will remain C and C++ for the near future. Performance still matters.
At the time when Lisp was falling out of favour, that wasn't the case (Lisp could outperform C on Sun workstations, for example); the only reason Lisp suffers in performance is because it fell out of favour, so there's not much work done on Lisp compilers; the space for improvement is even bigger with modern hardware.
While I deeply appreciate your promotion of Lisp, this commentary is significantly inaccurate in many places.
Could you point out these inaccuracies? Both I and future viewers would appreciate any corrections 😊.
10:30 lookups with an array are O(1) if you know the index no shit Sherlock every problem is solved in O(1) anyway if you already have the answer bruh
No, it's not. If you have a linked list and you want the i-th element, you still need to traverse the list linearly, and that is O(n).
Lots of Incomprehensible Silly Parentheses - reason why LISP never quite made it
The parentheses are comprehensible if you learn to see them correctly. From a beginner's point of view, the parentheses are in the wrong place, leading to the illusion you get. The number of parentheses is the same as in other languages, perhaps with the exception of Forth.
@@jacekjacenty from a veteran's point of view, the parentheses are just annoying.
@@menyasavut3959 For my setup, the parentheses quickly stopped being annoying. What type of veteran are you?
@@jacekjacenty various assembly languages, then verilog and C, various HLLs like Pascal, Java, ach, a lot of nonsense.
@@menyasavut3959 C, Pascal and Java are all great
Lots of Interesting Silly Parenthesis, or NAMBLA. Of course it was not going anywhere. It really sucked, a lot. Bye bye LISP and Prolog, you wasted my time.