I've been using Common Lisp for over 15 years. I'm a musician and write Lisp software to help me with composition and synthesis. The SBCL implementation has gotten so fast, especially with math, that I'm currently toying with the idea of writing a full blown digital audio workstation in Common Lisp. Aside from Lisp the only other language I now use is C. Simply because of the need to interface with audio hardware, and certain real time kernel issues. But the vast majority of my code is in Lisp. It's just so flexible and fast to code in, and is definitely the best language ever for tinkering and trying out crazy ideas. I reckon that there will be a boom of Lispers in the future. It's a shame that Lisp machines stopped being developed. A Common Lisp OS would be awesome!
Similarly, I'm right now toying with the feasibility of writing DSP cores in SBCL. There's a lot of hackery in the type annotations and declarations, but some pretty neat stuff can be obtained. This is all to facilitate IQ modulation and demodulation for RF baseband signals, but ultimately not all that different from normal audio either ;-).
Have you seen uLisp for micro-controllers? It sounds like what you are describing. I haven't used it yet as I am just getting started in LISP but the idea of not having to do a restart to change code (such as was done to update the LISP images on spacecraft) is intriguing.
You can get very similar action in Squeak/Smalltalk, editing a running instance. What enables this is late-bound dispatch. Any language could do this, but very few do. One reason is it's difficult to implement efficiently, because every single step in a program has to do a lookup inside an in-memory database of code at run-time. With the design of processors we have, it's easier/more efficient to bind logic early, but that makes engineering of good software more difficult. Also, the reason you don't "feel" the edit->compile->run cycle is each expression is compiled incrementally. You don't compile your code all at once, like in most compiled languages.
The actual keys to interactive programming are three things: an interactive interface (in Lisp this would be a REPL, a read eval print loop), resident development tools (compiler, interpreter, loader, ... are a part of the interactive language) and a way access them via names (-> symbols and symbol tables in Lisp). For example a function to do output can be registered under the name PRINT-LINE. Then one can reassign this symbol to a new function, which might be an improvement to the earlier one. All global function calls (even in compiled code) go through this symbol table, so changed definition get automatically used on the next call. This allows one build up named functionality piece by piece and update it incrementally. The "image" (-> a snapshot of the system state, like a dump of the heap memory) is a tool to get faster to the state of Lisp system (restoring all the code and data which has been loaded into Lisp). Dumping and restoring images has been introduced in the very first Lisp implementation 60 years ago, because restoring the Lisp system state otherwise was very slow. Note that a bunch of Lisp implementations can't save/restore images - for example ECL (a Common Lisp implementation) and Clojure (a Lisp-derived language for the Java Virtual Machine) - but they still support interactive development.
The lack of syntax - or probably better said, the uniformity of S-expressions - means that one can express any (ANY) problem or domain as a composition of expressions; effectively, constructing a DSL bottom-up which describes the processing of a given problem. It’s declarative, composable, and often functional. Arbitrary features can be added in no time, usually as simple functions. It’s the most powerful abstraction in programming; it becomes clear after Lisp that *enforcing* syntax is *reducing* flexibility, composability, and thus power. You begin having to wrestle the syntax instead of having it work for you.
Lisp really has no syntax once you get over simple parens. That is part of its beauty. There is a minimum of stuff defined as syntax and built-ins and keywords and other cruft to have to bang on to say what you really mean. And there is no limit on the problem patterns I can capture and make reusable or ugly hackery needed to do so.
Thanks for the videos, you're the one that got me started on vanilla emacs. I copied your few lines of your config and grew it since into a massive 10,000+ line emacs config lol. I'm counting the lines in my modules (require 'my-module) as well.
What really blows my mind about LISP is how it's written in itself. I can write every inbuilt function myself if I want, or look at the code it's written in. Or write new lisp code while im running a pre written script. In python for example, as a relative novice to programming, when I use say the map() function, its written in C and i just trust it does what I want. In LISP i can write my own map function. I've even found a macro on stack overflow that creates a list comprehension function with almost the same syntax as Python. I feel learning lisp has made me better at python too. Except now I have this urge to write lambda functions and pass them around lol which is hardly optimal, but it's a lot of fun :D Also the parentheses aren't that bad! Once you get used to it the syntax feels very elegant and natural, at least for me.
I understand now why Emacs is so extensible. I am even beginning to understand why one would want such a tool that is so extensible, although being able to extend it in any kind of way takes a lot of skill.
Had that noted down but must have forgotten to mention it. Smalltalk in particular takes the whole idea of an OS image to another level. At least from my knowledge of pharo which I assume is very similar to how smalltalk was
Indeed, if you not define or loosely define the word "productive" and do not use objective metrics, for any you can make a video titled "Why Is The Most Productive Programming Language"
Scala and Clojure map to Lisp and Haskell, respectively. - **Clojure** is a modern Lisp dialect that emphasizes immutability and functional programming within the JVM ecosystem. - **Scala** combines object-oriented and functional programming paradigms, aligning with Haskell's strong type system and functional nature. This mapping highlights the influence of Lisp and Haskell on these contemporary languages.
It's hard to convey the Lisp REPL in a cycle diagram. Lisp is always running, and compilation is usually instantaneous, so it's as if you're only writing and running code and instantly seeing the results of the changes. Not having to constantly restart your entire programming environment is rare and a game changer.
Plus, the ""Lots of Irritating Single Parentheses" are actually a great plus for very fast navigation/evaluation (w/o mouse) while editing/evaluating (meaning C-x -C-e, C-M-a, C-M-u ...), but hard to describe/convey ...
@@stevenpe781 I'm trying to put together ideas to express that in a video, as it seems there's something fundamentally important about having semantics closely mapped to syntax, which is what assembly, Lisp, and many functional languages like Haskell have but something that other languages like C/C++, Java, Fortran, & Python fail to capture. So since their syntax is a convoluted version of semantics, it's very difficult to enable semantic navigation & editing of code, to the point where incomplete statements can't even be interpreted due to the ambiguity. Where Lisp seems to stand out above strictly functional languages that lack S-expressions is that specific point about semantic navigation given incomplete statements. With Lisp, you can easily navigate up, down, and around incomplete statements, but if e.g. a Haskell function definition is missing its `=` sign then it's likely that an editor would not be able to figure out what the rest of the code is supposed to mean. In Lisp that would be equivalent to e.g. forgetting to close a set of parentheses, but that's much easier to detect.
Your perspective can be restated as: - **GANs** in AI teach about competition through the adversarial relationship between the generator and discriminator. - **Lisp** can teach programming applicable to languages like COBOL, JavaScript, Python, and Java. - **Haskell** remains separate and provides valuable insights into mathematics. This emphasizes Lisp's foundational role in teaching programming while highlighting Haskell's unique contributions. Drafted by AI
Man, I would love coding in the kind of environment where you were just printing simple values to a screen, as opposed to deploying to a canary, or live-updating a webpage, or any of the things that we have been doing for over a decade.
I think of LISP dialects as a good output language from programs written in a higher level language that already has static typing in it. You got a simple problem you need to solve? Create a language with custom syntax that is only built to solve the problem even if it's a very small problem. Doesn't have to be the next Rust or Haskell, but it needs to be simple enough to solve the problem and no more problems than that. If the problem genuinely encompasses multiple paradigms, use an existing general purpose language for that. 4:14 I might be a little confused here, but interactive programming implies some kinds of hot swap from a prompt/running daemon while live programming implies that procedures are sent to data via a queue holding processes/closures to run on the data (Peter Alvaro has a few talks on this concept, including the blue sky OS). Both of these concepts imply that you have a way of looking inside of the program's internal state/data AFAIK.
This makes the language too fragmented and also makes people new to your software having to learn a new language essentially. I'm not sure this is the best way for software engineering.
..3 minutes in, and I feel I have absolutely no idea what you're talking about >< ..I'll have to write some lisp programs to wrap my head around it :-)
I like CL, but it's far from the most productive language. It suffers from the same issues as all dynamic languages that make them more of a pain as the project grows. Static typing and analysis are far more productive on larger code bases. The last project I tried to do in CL hit a brick wall because the DB libraries don't support blobs with mysql and I kept hitting a bug in hunchentoot caused by them not mutex locking around the socket correctly. So, yeah, I haven't found it very productive for anything significant.
I really wanted to add some talk about forth and small talk to the video but the runtime got a little out of hand. Happy to see others mentioning them!
FORTH was useful decades ago, when memory was measured in double-digit K and a system that could cross compile cost as much as a car. Now that we can write C++ for an Arduino that costs less than a pack of cigarettes, or run Linux for less than what we used to pay for a good keyboard, it belongs in a museum next to the flint tools.
Oh, well, I had a great teacher (!) at the university. He was a Russian-French-American. He was also a poet-computer scientist. I just loved LISP when I first met her ;o) However, I have been using C/C++/C# ever since. Because I was the only one who was into LISP in my hood ;o)
There are multiple. The first one and quickest one is when projects use a packages.lisp file to define all their packages. This gives a file you can look at to get a general idea of the projects layout. Next would be simply running the program and poking at it from the repl. Most large applications use some form of logging so I can usually set that to it's most verbose when looking for what code controls what feature. If I need more details I can use (trace function-name-here :methods t). All in all I find exploring new projects relatively straightforward.
Is there a way of easily restarting the entire state of the application back to the init state without killing it completely, so that we still stay within this workflow you demonstrated?
I've written some small personal stuff but my 2 most substantial projects where written during my last job. I can't speak too deeply on their purpose just due to the NDA I'm still held under but it was a service manager with an interactive service manager service. If you have any questions I'd be happy to answer (within reason)
@@GavinFreeborn What I mean is "the most productive programming language" is the bold statement to make. Probably could be proven if you have built something big in a reasonable amount of time. My first impression when I see such claims is "sure nobody bothered to prove it". It might be the best programming language in the world but how should I believe it, if I don't see you program something really cool in it?
It can and has been used as a scripting language for video games and Infact has been used to create entire games. The Jak games are pretty famous for being written in a lisp dialects that allows for the exact workflow shown in this video. The game Kandria is in development write now written 100% in common lisp. As far as why Lisp is better than python it all comes down to usecase really. Python has more libraries and tons of modern tooling that common lisp just doesn't have. Common lisp has the advantage of supporting multiple threads, much much faster code execution, and the language is much much more powerful (my why Lisp video kinda gets into this) meaning that if there is a language feature you need chances are high you can implement it on top of lisp.
It really depends how you use it. I find it works fine so long as I am trying to keep the source code in sync with the image. If I start loading code without actually having any form of backup it can be an issue. I try to reuse some of the code used in the repl to develop tests so I don't have to worry as much on if I forgot to commit some code that is in the image but not in the repository.
Smalltalk is also image-based and offers all the same benefits. However, there are several important differences... First, Smalltalk is much, much easier to learn for newcomers, especially young people. In fact, Smalltalk was *literally* designed for teaching programming to young people by Alan Kay, Dan Ingalls, and Adele Goldberg at Xerox PARC. Second, its syntax is much more readable like conventional programming languages. This is especially true for arithmetic expressions. (Reader macros are a goofy workaround.) Third, Smalltalk is the most productive of all the major languages, according to a 2017 study by Capers Jones. Lisp is one of the least productive! I suspect a large part of the reason is Smalltalk's elegant graphical IDE. It's so easy to use, even a child can use it! (Emacs is a nightmare for beginners.) Fourth, Smalltalk is extremely flexible, adaptable, and extensible without the need for macros (whether hygienic or not). Smalltalk is practically its own DSL (domain-specific language)! Fifth, Smalltalk is purely and consistently object-oriented. OOP is the most widely used paradigm in the industry. There are object-oriented add-ons for Lisp but they're not standard and not widely used. Smalltalk celebrates its 50th anniversary this year: ua-cam.com/video/MDgbUCtCKak/v-deo.html. Also, ua-cam.com/video/TQQ1oXM7Nms/v-deo.html.
Unfortunately, Smalltalk never quite achieved that goal of teaching young people to program. It just got too complex. Even Goldberg _et al_ admit in some of their writings that it can take several months to become _au fait_ with the extensive library. Otherwise, you will likely end up reinventing parts of it while trying to write your own code. LOGO was an example of a language which was much more successful at teaching children to program. Probably because it was rather less ambitious.
@@lawrencedoliveiro9104 True. It does take time to acclimate to the class library. But time doesn't make it difficult; time requires patience. Smalltalk was built for *exploration* as Alan Kay et al. will tell you. And exploration takes time. In general, all *practical* programming languages require you to study the "standard" library without which you can't do much. This applies to C, Java, Python, etc. Smalltalk and Lisp are no exceptions.
Lordie, I took LISP language in college one semester in the late 80's (thanks to Lisp being installed on the university's AT&T 3B15 minicomputer) under the guise of "this could be an important AI language". At the time I really loved it. Now some-odd years later, I can't imagine trying to learn it again. We affectionately understood LISP to be an acronym for "Lots of Irritating Single Parentheses" lol.
@@viacheslav1392 I actually started my coding journey with Doom emacs on Windows. It was eye opening. It gave me the impetus to start really developing and move away from tutorial hell and to live in the editor. I eventually switched to linux (minimal arco linux + dwm), but I started using neovim with a lot of plugins and customizations. felt it was easier to configure for what I wanted and I didn't get weird breaking errors. recently switched to a full lua config and though it's not as intuitive to me as Elisp and Vimscript it's working well. I'm not counting Emacs out, in fact, I'm installing it as I write this, but I don't think I'll be going back to it for now sinve I've fallen into a groove. Already saw he has a video on a repl plugin so I'll check that out.
@@defnlife1683 By the way, There are two Lisp flavors that compile to Lua: Fennel and Urn, So maybe you can check them out for configuring your Neovim environment.
As Chaz said, dumping the code is not necessary. The amount of information included would be on par with what you'd get doing a disassembly with C++/C#
@@acebulf So which one it is then, C++ or C#? Because for c++ it's basically impossible to regenerate original code especially under release mode, but for C# even without debug information it's trivial to get the original source code, variable and function names included. I've decompiled a whole ass C# video game before, changed an algorithm in it, and it recompiled and ran successfully on the first try
First off, the whole K&R style was a mistake since day one. Allman makes hierarchies so much clearer, where braces line up. People that stubbornly cling to K&R feel that it's good to save vertical space, but it makes reading it slower. It's much easier to scroll through code where Allman style is used. I know this is a bit of a religious issue, but to me, it's people refusing to accept facts. This applies to Lisp also. Writing a bunch of open braces at the end of a line and then closing them down below, you can't visually pair up the open and close of lists. It's a great example where K&R fails. Writing all the parenthesis to line up the opening and closing of each segment, will already improve Lisp's readability. True that the amount of vertical space will go up seemingly absurdly so. However, we could fold sub segments. I see it as a hierarchy like a gui tree control, where you can press little + buttons that expands a node where you can then reveal its children. I think we could attract new attention to Lisp by changing how its code is organized / displayed. And then also, perhaps the language could be changed to make it so that a node itself states the instruction, and then *its* children its (optional) list, instead of writing the instruction inside the list. And then lastly, the whole notion of parser combinators can be done so much nicer in lisp. Lips is all about hierarchies. You could define languages inside languages inside languages.
You definitely make some good points. While I like the current standard lisp formatting I think lots could change to provide a better user experience. The biggest problem I see day to day with the current way is the messy git diff output. Often minor refractors can make for huge diffs and I feel like there are plenty of opportunities to improve it.
You sound literally insane saying this 🤪 Who wants to visually pair up parentheses? (What parentheses? Lisp is made of trees of objects, there are no parentheses)
Something that I find a bit confusing in the world of Lisp is what exactly is meant by compilation. I'm doing a bit of Lisp these days thanks to Emacs, but I feel much more at home in the world of C and C++. So when I hear compile, I'm thinking that I'll get an actual binary exectuable. But is this really the case when "compiling" Lisp as described here? From some quick googling, I found something which basically seems to say that compilation in the world of Lisp means to expand all macros, so that the macro expansion is not done at run-time. The resulting "compiled" Lisp code would still be Lisp(not assembly or binary) and would then be run by what I would call a Lisp interpreter which happens to have been integrated into the "compiled" Lisp exectuable, thus making it a stand-alone exectuable file but not a binary executable. Am I understanding it correctly or am I lost? If my understanding is right then I find it hard to believe that the fact that Lisp can be "compiled" makes it a performant laguange, since it wouldn't really be compiled in the sense of actual compiled languages. Would be interesting to see some performance benchmarks. I found somebody who had done some benchmarks, comparing rust, Java and "compiled" Lisp. In those tests rust is far worse than both Java and Lisp, which seems odd. Other benchmarks showing compiled languages to fall far behind interpreted ones often make the mistake of compiling for debug not release, and I suspect that something similar happened here. Anyway, as of now my confusion about compilation in the world of Lisp remains..
> compilation in the world of Lisp means to expand all macros That is false, compiling in lisp usually means the same thing as in the world of C/C++, except the output of the compilation is in-memory as opposed to, say, an object (.o) file. When you want to create an executable, you compile all the code in the same process and then "dump the image" as an executable. But! The reality is more nuanced than that. Implementations like sbcl always compile the code, but some implementation are pure interpreter, others use a VM (like abcl that runs on the JVM). I hope this helps P.S. The macro expansion is part of the compilation process, but it's not the whole thing.
Lisp has never been interpreted. It does incremental compilation at the expression level, which ends up acting as hot loading. The compiler and runtime are the same thing, there's no separation. When you give it new code, it compiles it into the running image.
Nobody in their right mind literally works this way. Lisp people put code into files that are in version control like Git, just like everyone else and can reproduce the application build from scratch. In some situations it's useful to have a running image and reload updated version of that code from those files, without stopping and restarting the image. This is very important if the code maintains a lot of state that you don't want to lose (e.g. because a bug has been reproduced after much effort or whatever, or it simply takes long to get the application into a certain state where you want to be testing your change). But, Lisp programmers aren't stark raving lunatics, just building up a complex program via side effects inside some running image that are not recorded anywhere else. And I should mention that good Lisp coders write test cases like everyone else; they don't just type things into a session, manually test things, and ship the image. That's massively counterproductive.
I did not intended to give the impression that people shouldn't record their changes in version control. I agree with the majority of what you said. The intent was to give an example of how this could assist a programmer during development.
ub for FORTH projects. I found a lot of people who had done their own FORTH implementations, but nobody seemed to go on to use them for anything productive.
It's fine to say you like lisp or think it's cool, but if you're going to say "it's the most productive programming language" you should at least back it up with evidence of your own extreme productivity in it.
Agreed. This did not look very productive. We had a convoluted talk about a dynamic runtime/dev environment and then some weird error handling exercise and alteration of the port.
Completely valid criticism. I actually have a video recorded and edited covering the process of developing a production level CL application. I never got the official ok to publish the video. I've been holding off on publishing it for almost 4 months now so I should follow up and see.
It will always be anecdotal, but here's my anecdote: Started a nuclear physics PhD. Used the standard tools C++ and the CERN ROOT library to write programs to run in batches on a remote computer cluster. Some people started using Python to speed up post processing but they still relied on the usual batch structure, one script/program per pass over the data, possibly using a massive monolithic program with lots of control parameters to simplify their interface. I was learning Common Lisp because I'd heard how great macros were. Ultimately in a few months I built an analysis framework that was essentially a DSL for doing data analysis with Makefile/spreadsheet-like dependency propagation built-in. So instead of writing a monolith or multiple programs for each pass over the data, I defined individual targets, e.g. a histogram, scatter plot, fit function for data, subset of data etc., and the system automatically generated programs to submit to the cluster, monitor progress, resubmit jobs that timed out, and downloaded & merged results to my workstation computer. If I needed a change, I edited the target(s), hit an Emacs combo, and the system submitted new batch jobs just for what minimally needed updates. It didn't even lose efficiency due to me adding a plugin that generated C++ code to compile for certain operators in the DSL. Having worked with Python after the doctorate, I can imagine building a similar system, but not without costing much more time and likely lacking many features.
Lisp is torture for the eyes. And no it’s not like an operating system. At least most aren’t. Most don’t start bare metal (if any) and control hardware. Forth and MUMPS generally are.
It’s surprising that people still love CL nowadays to use over other scripting languages. Problem with lisp is often about its ecosystem and the maintainable issues.
I'm a ferm believer in a third option: if it compiles, it works. In a properly designed language (such as Eiffel or Elm/Haskell) that's how works for a lot of the development cycle.
@@zackradisic6684 I have the same issue. I'm currently working on a game in Rust and I would love to use CL but I just feel naked without types and static analysis.
@@freesoftwareextremist8119 just in general they’re behind. Haven’t even updated http libraries to 2.0. They just tell you “just use nginx!” It’s just more so the culture, they’re stuck OR PRIVATE. I know people have written their own modern web servers from scratch but they’re for their company. Not open source.
BTW, how cum there isn't a free, open-source, easy-to-use, graphical IDE for Lisp? If you want a nice graphical IDE, you have to pay through the nose for a commercial one.
@@GavinFreeborn I have no doubt there are good efforts out there. But none of them are "universal" like Emacs. Smalltalk's IDE is "standard" in its overall design and philosophy (there are variations among different implementations). This universality is another Smalltalk strength.
@@horridohobbies it's less so emacs and more so slime. With pretty minimal effort another editor could support slynk (slimes backend). E.g. that's what alive, conjure (for neovim), and Lem
I'm not sure how special this is comparing to modern languages. For example, I've heard from my friends who develop in js that they can do pretty similar stuff as well. They have a repl, and even hot reloading.
I think you may have missed a few key differentiators. First the experience with interpreted languages is pretty similar. However, that's only in the sense that you can interact with the running program. Common Lisp is a compiled language that allows you to modify the compiled program. JavaScript both in the browser and in nodejs. You only get what you called hot reloading in the sense that you can regenerate a page but for that to happen you can't be using those JavaScript resources. That's why there is an event loop and why JavaScript used on sites can become unresponsive. That's not the case with common lisp since most of these features can be handled on a seperate thread the updating of symbols can happen asynchronously. E.g. I could have compiled a larger common lisp file into the project and used the browser without any delay. While nyxt isn't a great example for that I've done a stream where I worked on a video game and modified individual functions without any delay in the actual running game session. Thanks for your comment and input!
@@GavinFreeborn we can get similar hot loading while developing using low level languages like c and c++. i don't know if lisp can do more, like hook into an application out in the wild and manipulate at will. if it can do that, it will have something over c/c++ etc. ... but then you still have to put up with that awful syntax. not something i could convince myself to ever like (i've tried).
Another underwhelming wide-eyed intro to a lisp repl that does nothing interesting. And the comment section is full of drones praising s-expr and how they can do a lot more with a lot less or something. Or maybe the whole thing is satire. In any case, this just makes me want to stay *far* away from any kind of lisp. Waste of time.
Here's the problem with languages endorsed by the intellectual elite... It usually takes an intellectual elite to use that language properly. Haskell OCaml Lisp Rust...even C++ The above is a small example of what I call ego languages. Languages that the average person trots out to brag to the other average types..
I've been using Common Lisp for over 15 years. I'm a musician and write Lisp software to help me with composition and synthesis. The SBCL implementation has gotten so fast, especially with math, that I'm currently toying with the idea of writing a full blown digital audio workstation in Common Lisp. Aside from Lisp the only other language I now use is C. Simply because of the need to interface with audio hardware, and certain real time kernel issues. But the vast majority of my code is in Lisp. It's just so flexible and fast to code in, and is definitely the best language ever for tinkering and trying out crazy ideas. I reckon that there will be a boom of Lispers in the future. It's a shame that Lisp machines stopped being developed. A Common Lisp OS would be awesome!
i am trying to learn Common Lisp. May i know about your environment? I downloaded Portcle. which is SBCL+emacs+qlisp.
@@टिरंजननकले I normally use SBCL within Emacs. Sometimes ECL.
Brett Buddin, i think, wrote a DAW for the terminal that uses a lisp for live editing.
Similarly, I'm right now toying with the feasibility of writing DSP cores in SBCL. There's a lot of hackery in the type annotations and declarations, but some pretty neat stuff can be obtained. This is all to facilitate IQ modulation and demodulation for RF baseband signals, but ultimately not all that different from normal audio either ;-).
Have you seen uLisp for micro-controllers? It sounds like what you are describing. I haven't used it yet as I am just getting started in LISP but the idea of not having to do a restart to change code (such as was done to update the LISP images on spacecraft) is intriguing.
You can get very similar action in Squeak/Smalltalk, editing a running instance.
What enables this is late-bound dispatch. Any language could do this, but very few do. One reason is it's difficult to implement efficiently, because every single step in a program has to do a lookup inside an in-memory database of code at run-time. With the design of processors we have, it's easier/more efficient to bind logic early, but that makes engineering of good software more difficult.
Also, the reason you don't "feel" the edit->compile->run cycle is each expression is compiled incrementally. You don't compile your code all at once, like in most compiled languages.
The actual keys to interactive programming are three things: an interactive interface (in Lisp this would be a REPL, a read eval print loop), resident development tools (compiler, interpreter, loader, ... are a part of the interactive language) and a way access them via names (-> symbols and symbol tables in Lisp). For example a function to do output can be registered under the name PRINT-LINE. Then one can reassign this symbol to a new function, which might be an improvement to the earlier one. All global function calls (even in compiled code) go through this symbol table, so changed definition get automatically used on the next call. This allows one build up named functionality piece by piece and update it incrementally.
The "image" (-> a snapshot of the system state, like a dump of the heap memory) is a tool to get faster to the state of Lisp system (restoring all the code and data which has been loaded into Lisp). Dumping and restoring images has been introduced in the very first Lisp implementation 60 years ago, because restoring the Lisp system state otherwise was very slow. Note that a bunch of Lisp implementations can't save/restore images - for example ECL (a Common Lisp implementation) and Clojure (a Lisp-derived language for the Java Virtual Machine) - but they still support interactive development.
The lack of syntax - or probably better said, the uniformity of S-expressions - means that one can express any (ANY) problem or domain as a composition of expressions; effectively, constructing a DSL bottom-up which describes the processing of a given problem. It’s declarative, composable, and often functional. Arbitrary features can be added in no time, usually as simple functions. It’s the most powerful abstraction in programming; it becomes clear after Lisp that *enforcing* syntax is *reducing* flexibility, composability, and thus power. You begin having to wrestle the syntax instead of having it work for you.
I like to put it this way: it's actually easier to communicate when there's only one way to say a thing.
Lisp really has no syntax once you get over simple parens. That is part of its beauty. There is a minimum of stuff defined as syntax and built-ins and keywords and other cruft to have to bang on to say what you really mean. And there is no limit on the problem patterns I can capture and make reusable or ugly hackery needed to do so.
Thanks for the videos, you're the one that got me started on vanilla emacs. I copied your few lines of your config and grew it since into a massive 10,000+ line emacs config lol. I'm counting the lines in my modules (require 'my-module) as well.
What really blows my mind about LISP is how it's written in itself. I can write every inbuilt function myself if I want, or look at the code it's written in. Or write new lisp code while im running a pre written script. In python for example, as a relative novice to programming, when I use say the map() function, its written in C and i just trust it does what I want. In LISP i can write my own map function. I've even found a macro on stack overflow that creates a list comprehension function with almost the same syntax as Python. I feel learning lisp has made me better at python too. Except now I have this urge to write lambda functions and pass them around lol which is hardly optimal, but it's a lot of fun :D
Also the parentheses aren't that bad! Once you get used to it the syntax feels very elegant and natural, at least for me.
I understand now why Emacs is so extensible. I am even beginning to understand why one would want such a tool that is so extensible, although being able to extend it in any kind of way takes a lot of skill.
Indeed, Lisp is the most poweful programming language. Great video as always.
Smalltalk and Self are very similar to this
Had that noted down but must have forgotten to mention it. Smalltalk in particular takes the whole idea of an OS image to another level. At least from my knowledge of pharo which I assume is very similar to how smalltalk was
I wanted to learn Self but it's so hard to find good info about it..
Indeed, if you not define or loosely define the word "productive" and do not use objective metrics, for any you can make a video titled "Why Is The Most Productive Programming Language"
You most definitely can. This is just a workflow I've found to be productive at least when it comes to develop new and extending existing software.
Thanks for sharing this! I’ve been looking for a way to explain the workflow, and you just provided! ❤
3:20 doesnt REPL of all these languages (python, julia) etc do the same thing?
Scala and Clojure map to Lisp and Haskell, respectively.
- **Clojure** is a modern Lisp dialect that emphasizes immutability and functional programming within the JVM ecosystem.
- **Scala** combines object-oriented and functional programming paradigms, aligning with Haskell's strong type system and functional nature.
This mapping highlights the influence of Lisp and Haskell on these contemporary languages.
on par with Pharo Smalltalk
It's hard to convey the Lisp REPL in a cycle diagram. Lisp is always running, and compilation is usually instantaneous, so it's as if you're only writing and running code and instantly seeing the results of the changes.
Not having to constantly restart your entire programming environment is rare and a game changer.
Plus, the ""Lots of Irritating Single Parentheses" are actually a great plus for very fast navigation/evaluation (w/o mouse) while editing/evaluating (meaning C-x -C-e, C-M-a, C-M-u ...), but hard to describe/convey ...
@@stevenpe781 I'm trying to put together ideas to express that in a video, as it seems there's something fundamentally important about having semantics closely mapped to syntax, which is what assembly, Lisp, and many functional languages like Haskell have but something that other languages like C/C++, Java, Fortran, & Python fail to capture. So since their syntax is a convoluted version of semantics, it's very difficult to enable semantic navigation & editing of code, to the point where incomplete statements can't even be interpreted due to the ambiguity.
Where Lisp seems to stand out above strictly functional languages that lack S-expressions is that specific point about semantic navigation given incomplete statements. With Lisp, you can easily navigate up, down, and around incomplete statements, but if e.g. a Haskell function definition is missing its `=` sign then it's likely that an editor would not be able to figure out what the rest of the code is supposed to mean.
In Lisp that would be equivalent to e.g. forgetting to close a set of parentheses, but that's much easier to detect.
It’s not rare Forth and MUMPS come to mind
Your perspective can be restated as:
- **GANs** in AI teach about competition through the adversarial relationship between the generator and discriminator.
- **Lisp** can teach programming applicable to languages like COBOL, JavaScript, Python, and Java.
- **Haskell** remains separate and provides valuable insights into mathematics.
This emphasizes Lisp's foundational role in teaching programming while highlighting Haskell's unique contributions.
Drafted by AI
Hey thanks, and great video! Have you heard about Urbit and hoon? It is an overlay OS, and Hoon is similar to lisp, it is also homoiconic
chad spotted ~
Man, I would love coding in the kind of environment where you were just printing simple values to a screen, as opposed to deploying to a canary, or live-updating a webpage, or any of the things that we have been doing for over a decade.
Great video as always!
u da best bru. I wanted to look at a language that is like a scripting + fast compiled code so common lisp might be a thing for me at work.
Symbolics. Yeah, I'm that old.
I think of LISP dialects as a good output language from programs written in a higher level language that already has static typing in it. You got a simple problem you need to solve? Create a language with custom syntax that is only built to solve the problem even if it's a very small problem. Doesn't have to be the next Rust or Haskell, but it needs to be simple enough to solve the problem and no more problems than that.
If the problem genuinely encompasses multiple paradigms, use an existing general purpose language for that.
4:14 I might be a little confused here, but interactive programming implies some kinds of hot swap from a prompt/running daemon while live programming implies that procedures are sent to data via a queue holding processes/closures to run on the data (Peter Alvaro has a few talks on this concept, including the blue sky OS). Both of these concepts imply that you have a way of looking inside of the program's internal state/data AFAIK.
This makes the language too fragmented and also makes people new to your software having to learn a new language essentially. I'm not sure this is the best way for software engineering.
I’m in such a hype for Ocaml and Lisp now. I’m learning algorithms in Haskell. I’m leaving my OOP root into the FP world!!!
..3 minutes in, and I feel I have absolutely no idea what you're talking about >< ..I'll have to write some lisp programs to wrap my head around it :-)
I like CL, but it's far from the most productive language. It suffers from the same issues as all dynamic languages that make them more of a pain as the project grows. Static typing and analysis are far more productive on larger code bases. The last project I tried to do in CL hit a brick wall because the DB libraries don't support blobs with mysql and I kept hitting a bug in hunchentoot caused by them not mutex locking around the socket correctly. So, yeah, I haven't found it very productive for anything significant.
Build a typed DSL on top then. See Shen for example.
Write a typed Lisp.
Are the bugs you're referring to even related to static typing though?
Awesome content, love you
Nice. Makes me wanna learn Lisp.
Let me add Forth to the list of languages that can carry the entire base around in the final product. Mind you, I much prefer using Lisp.
I really wanted to add some talk about forth and small talk to the video but the runtime got a little out of hand. Happy to see others mentioning them!
FORTH really isn’t worth using any more. If you want an RPN language
, PostScript had some interesting ideas, and at least you can build a more modern language along the same lines.
FORTH was useful decades ago, when memory was measured in double-digit K and a system that could cross compile cost as much as a car. Now that we can write C++ for an Arduino that costs less than a pack of cigarettes, or run Linux for less than what we used to pay for a good keyboard, it belongs in a museum next to the flint tools.
@@lawrencedoliveiro9104 Like what (ideas)?
Oh, well, I had a great teacher (!) at the university. He was a Russian-French-American. He was also a poet-computer scientist. I just loved LISP when I first met her ;o) However, I have been using C/C++/C# ever since. Because I was the only one who was into LISP in my hood ;o)
For mature projects, does lisp has a way to organize code and prevents us having to read everything while on boarding?
There are multiple. The first one and quickest one is when projects use a packages.lisp file to define all their packages. This gives a file you can look at to get a general idea of the projects layout. Next would be simply running the program and poking at it from the repl. Most large applications use some form of logging so I can usually set that to it's most verbose when looking for what code controls what feature. If I need more details I can use (trace function-name-here :methods t). All in all I find exploring new projects relatively straightforward.
Is there a way of easily restarting the entire state of the application back to the init state without killing it completely, so that we still stay within this workflow you demonstrated?
No, you have to restart your Lisp. But you can restore from saved images.
So how do I use Lisp directly on HW? Linux doesn't seem to be of any use. BareMetal OS seems promising.
Have you used Forth, Gavin? You'd have the same experience, but in stack RPN notation. Lisp and forth; two of the most enjoyable languages imaginable.
Only done the basics. Haven't used it long enough to get used to manipulating the stack. One day I'll have the free time to dig into it
Hi, great vid! Would you be able to do a video on sly stickers?
lisp images remind my of the Java VM in some strange way.. but with more access to the "VM"
I am strongly recommend you to read the article "Clojure" in the Wikipedia.
Did you write something substantial in Lisp?
I've written some small personal stuff but my 2 most substantial projects where written during my last job. I can't speak too deeply on their purpose just due to the NDA I'm still held under but it was a service manager with an interactive service manager service. If you have any questions I'd be happy to answer (within reason)
@@GavinFreeborn What I mean is "the most productive programming language" is the bold statement to make. Probably could be proven if you have built something big in a reasonable amount of time.
My first impression when I see such claims is "sure nobody bothered to prove it".
It might be the best programming language in the world but how should I believe it, if I don't see you program something really cool in it?
Can list be used as a scripting language inside your own game engine code ?
How it's better than python?
It can and has been used as a scripting language for video games and Infact has been used to create entire games. The Jak games are pretty famous for being written in a lisp dialects that allows for the exact workflow shown in this video. The game Kandria is in development write now written 100% in common lisp. As far as why Lisp is better than python it all comes down to usecase really. Python has more libraries and tons of modern tooling that common lisp just doesn't have. Common lisp has the advantage of supporting multiple threads, much much faster code execution, and the language is much much more powerful (my why Lisp video kinda gets into this) meaning that if there is a language feature you need chances are high you can implement it on top of lisp.
is "an" operating system.
How well does image based development like shown here work with Git? 🤔
It really depends how you use it. I find it works fine so long as I am trying to keep the source code in sync with the image. If I start loading code without actually having any form of backup it can be an issue. I try to reuse some of the code used in the repl to develop tests so I don't have to worry as much on if I forgot to commit some code that is in the image but not in the repository.
@@GavinFreeborn aha I think I can work with that 😊
Could you please do a video on sic irc client and bitlbee?
What really matters more than anything is....documentation!
Smalltalk is also image-based and offers all the same benefits. However, there are several important differences...
First, Smalltalk is much, much easier to learn for newcomers, especially young people. In fact, Smalltalk was *literally* designed for teaching programming to young people by Alan Kay, Dan Ingalls, and Adele Goldberg at Xerox PARC.
Second, its syntax is much more readable like conventional programming languages. This is especially true for arithmetic expressions. (Reader macros are a goofy workaround.)
Third, Smalltalk is the most productive of all the major languages, according to a 2017 study by Capers Jones. Lisp is one of the least productive!
I suspect a large part of the reason is Smalltalk's elegant graphical IDE. It's so easy to use, even a child can use it! (Emacs is a nightmare for beginners.)
Fourth, Smalltalk is extremely flexible, adaptable, and extensible without the need for macros (whether hygienic or not). Smalltalk is practically its own DSL (domain-specific language)!
Fifth, Smalltalk is purely and consistently object-oriented. OOP is the most widely used paradigm in the industry. There are object-oriented add-ons for Lisp but they're not standard and not widely used.
Smalltalk celebrates its 50th anniversary this year: ua-cam.com/video/MDgbUCtCKak/v-deo.html.
Also, ua-cam.com/video/TQQ1oXM7Nms/v-deo.html.
I've taken a look at Pharo but I've never truely dug into it. Maybe if I find a little extra time I can dig a little deeper
@@GavinFreeborn You should. It's truly a lovely language. But one needs an open mind. I find too many programming bigots.
Unfortunately, Smalltalk never quite achieved that goal of teaching young people to program. It just got too complex. Even Goldberg _et al_ admit in some of their writings that it can take several months to become _au fait_ with the extensive library. Otherwise, you will likely end up reinventing parts of it while trying to write your own code.
LOGO was an example of a language which was much more successful at teaching children to program. Probably because it was rather less ambitious.
I still use Squeak for Smalltalk.
@@lawrencedoliveiro9104 True. It does take time to acclimate to the class library. But time doesn't make it difficult; time requires patience.
Smalltalk was built for *exploration* as Alan Kay et al. will tell you. And exploration takes time.
In general, all *practical* programming languages require you to study the "standard" library without which you can't do much. This applies to C, Java, Python, etc. Smalltalk and Lisp are no exceptions.
Lordie, I took LISP language in college one semester in the late 80's (thanks to Lisp being installed on the university's AT&T 3B15 minicomputer) under the guise of "this could be an important AI language". At the time I really loved it. Now some-odd years later, I can't imagine trying to learn it again. We affectionately understood LISP to be an acronym for "Lots of Irritating Single Parentheses" lol.
Time to add a repl plugin to neovim. :p
What’s the best way to learn any flavor of lisp?
the best way to get started with lisp is using Emacs.
@@viacheslav1392 I actually started my coding journey with Doom emacs on Windows. It was eye opening.
It gave me the impetus to start really developing and move away from tutorial hell and to live in the editor.
I eventually switched to linux (minimal arco linux + dwm), but I started using neovim with a lot of plugins and customizations.
felt it was easier to configure for what I wanted and I didn't get weird breaking errors. recently switched to a full lua config and though it's not as intuitive to me as Elisp and Vimscript it's working well.
I'm not counting Emacs out, in fact, I'm installing it as I write this, but I don't think I'll be going back to it for now sinve I've fallen into a groove.
Already saw he has a video on a repl plugin so I'll check that out.
@@defnlife1683 By the way, There are two Lisp flavors that compile to Lua: Fennel and Urn, So maybe you can check them out for configuring your Neovim environment.
As far as repl plugins for neovim there are multiple but the most recent one that gained traction is conjure
@@astroid-ws4py which do u prefer?
Does it mean one can never have proprietary code in lisp since everything is readable?
When most people say proprietary they mean a non free licence. The ability to read the code does not affect the license of the code.
As Chaz said, dumping the code is not necessary. The amount of information included would be on par with what you'd get doing a disassembly with C++/C#
So the answer is no. You can ship compiled binary files in which the source codes are not accessible to the end users.
@@acebulf So which one it is then, C++ or C#? Because for c++ it's basically impossible to regenerate original code especially under release mode, but for C# even without debug information it's trivial to get the original source code, variable and function names included. I've decompiled a whole ass C# video game before, changed an algorithm in it, and it recompiled and ran successfully on the first try
First off, the whole K&R style was a mistake since day one. Allman makes hierarchies so much clearer, where braces line up. People that stubbornly cling to K&R feel that it's good to save vertical space, but it makes reading it slower. It's much easier to scroll through code where Allman style is used. I know this is a bit of a religious issue, but to me, it's people refusing to accept facts.
This applies to Lisp also. Writing a bunch of open braces at the end of a line and then closing them down below, you can't visually pair up the open and close of lists. It's a great example where K&R fails. Writing all the parenthesis to line up the opening and closing of each segment, will already improve Lisp's readability. True that the amount of vertical space will go up seemingly absurdly so.
However, we could fold sub segments.
I see it as a hierarchy like a gui tree control, where you can press little + buttons that expands a node where you can then reveal its children.
I think we could attract new attention to Lisp by changing how its code is organized / displayed.
And then also, perhaps the language could be changed to make it so that a node itself states the instruction, and then *its* children its (optional) list, instead of writing the instruction inside the list.
And then lastly, the whole notion of parser combinators can be done so much nicer in lisp. Lips is all about hierarchies. You could define languages inside languages inside languages.
You definitely make some good points. While I like the current standard lisp formatting I think lots could change to provide a better user experience. The biggest problem I see day to day with the current way is the messy git diff output. Often minor refractors can make for huge diffs and I feel like there are plenty of opportunities to improve it.
You sound literally insane saying this 🤪 Who wants to visually pair up parentheses? (What parentheses? Lisp is made of trees of objects, there are no parentheses)
Something that I find a bit confusing in the world of Lisp is what exactly is meant by compilation. I'm doing a bit of Lisp these days thanks to Emacs, but I feel much more at home in the world of C and C++. So when I hear compile, I'm thinking that I'll get an actual binary exectuable. But is this really the case when "compiling" Lisp as described here? From some quick googling, I found something which basically seems to say that compilation in the world of Lisp means to expand all macros, so that the macro expansion is not done at run-time. The resulting "compiled" Lisp code would still be Lisp(not assembly or binary) and would then be run by what I would call a Lisp interpreter which happens to have been integrated into the "compiled" Lisp exectuable, thus making it a stand-alone exectuable file but not a binary executable. Am I understanding it correctly or am I lost? If my understanding is right then I find it hard to believe that the fact that Lisp can be "compiled" makes it a performant laguange, since it wouldn't really be compiled in the sense of actual compiled languages. Would be interesting to see some performance benchmarks. I found somebody who had done some benchmarks, comparing rust, Java and "compiled" Lisp. In those tests rust is far worse than both Java and Lisp, which seems odd. Other benchmarks showing compiled languages to fall far behind interpreted ones often make the mistake of compiling for debug not release, and I suspect that something similar happened here. Anyway, as of now my confusion about compilation in the world of Lisp remains..
> compilation in the world of Lisp means to expand all macros
That is false, compiling in lisp usually means the same thing as in the world of C/C++, except the output of the compilation is in-memory as opposed to, say, an object (.o) file. When you want to create an executable, you compile all the code in the same process and then "dump the image" as an executable.
But! The reality is more nuanced than that. Implementations like sbcl always compile the code, but some implementation are pure interpreter, others use a VM (like abcl that runs on the JVM).
I hope this helps
P.S. The macro expansion is part of the compilation process, but it's not the whole thing.
What program is that you are writing on?
excalidraw
Lisp is compiled and not interpreted? Since when?
There have been compiled versions of common lisp for decades now.
Lisp has never been interpreted. It does incremental compilation at the expression level, which ends up acting as hot loading. The compiler and runtime are the same thing, there's no separation. When you give it new code, it compiles it into the running image.
Curiously, the links I left to lisp interpreters have disappeared/
@@tswdtx Clisp is an interpreter implementation. If you count bytecode interpreters. Well I guess in that case, Abcl is also an interpreter...
The first Lisp compiler able to compile Lisp code to assembler appeared ca. 1962. It also could compile itself.
I like your explanation: run -> write -> comile.
It's like Forth in that way.
Nobody in their right mind literally works this way. Lisp people put code into files that are in version control like Git, just like everyone else and can reproduce the application build from scratch. In some situations it's useful to have a running image and reload updated version of that code from those files, without stopping and restarting the image. This is very important if the code maintains a lot of state that you don't want to lose (e.g. because a bug has been reproduced after much effort or whatever, or it simply takes long to get the application into a certain state where you want to be testing your change). But, Lisp programmers aren't stark raving lunatics, just building up a complex program via side effects inside some running image that are not recorded anywhere else. And I should mention that good Lisp coders write test cases like everyone else; they don't just type things into a session, manually test things, and ship the image. That's massively counterproductive.
I did not intended to give the impression that people shouldn't record their changes in version control. I agree with the majority of what you said. The intent was to give an example of how this could assist a programmer during development.
Lisp Is AN Operating System, sir.
More videos on hacking on nyxt please. As a student I think I can get a lot out of this.
The average JavaScript/TypeScript/Rust code block has more brackets than lisp 😉 But 🤐 don't tell anyone 😂
I'm in a laptop rn.
Forth is even better :)
I've actually been playing with it recently. Though I haven't gotten all that into it. Only gone through some basics.
I had a look on GitH
ub for FORTH projects. I found a lot of people who had done their own FORTH implementations, but nobody seemed to go on to use them for anything productive.
It's a fun language, and if you ever pressed L1-a on a Sun, you dropped into forth.
It's fine to say you like lisp or think it's cool, but if you're going to say "it's the most productive programming language" you should at least back it up with evidence of your own extreme productivity in it.
Agreed. This did not look very productive. We had a convoluted talk about a dynamic runtime/dev environment and then some weird error handling exercise and alteration of the port.
Completely valid criticism. I actually have a video recorded and edited covering the process of developing a production level CL application. I never got the official ok to publish the video. I've been holding off on publishing it for almost 4 months now so I should follow up and see.
It will always be anecdotal, but here's my anecdote: Started a nuclear physics PhD. Used the standard tools C++ and the CERN ROOT library to write programs to run in batches on a remote computer cluster. Some people started using Python to speed up post processing but they still relied on the usual batch structure, one script/program per pass over the data, possibly using a massive monolithic program with lots of control parameters to simplify their interface.
I was learning Common Lisp because I'd heard how great macros were. Ultimately in a few months I built an analysis framework that was essentially a DSL for doing data analysis with Makefile/spreadsheet-like dependency propagation built-in. So instead of writing a monolith or multiple programs for each pass over the data, I defined individual targets, e.g. a histogram, scatter plot, fit function for data, subset of data etc., and the system automatically generated programs to submit to the cluster, monitor progress, resubmit jobs that timed out, and downloaded & merged results to my workstation computer. If I needed a change, I edited the target(s), hit an Emacs combo, and the system submitted new batch jobs just for what minimally needed updates. It didn't even lose efficiency due to me adding a plugin that generated C++ code to compile for certain operators in the DSL.
Having worked with Python after the doctorate, I can imagine building a similar system, but not without costing much more time and likely lacking many features.
Checkout what the founder of Y combinator says about the subject.
While at it learn about the Y combinator hint lambda calculus
👍👍
((yes))
Lisp is torture for the eyes. And no it’s not like an operating system. At least most aren’t. Most don’t start bare metal (if any) and control hardware. Forth and MUMPS generally are.
Average Lisp Enjoyer
Buddy, you are 50 yrs late!
It’s surprising that people still love CL nowadays to use over other scripting languages.
Problem with lisp is often about its ecosystem and the maintainable issues.
I'm a ferm believer in a third option: if it compiles, it works. In a properly designed language (such as Eiffel or Elm/Haskell) that's how works for a lot of the development cycle.
I like the Lisp languages a lot, but after being exposed to Haskell and Rust I really can't go back to an existence with no types
@@zackradisic6684 I have the same issue. I'm currently working on a game in Rust and I would love to use CL but I just feel naked without types and static analysis.
If it's productive, shouldn't it produce stuff?
Unfortunately CL people are more interested in extending the language than actually producing products.
*an
I love lisp but cl angers me. They’re so far behind web wise and don’t seem to care. Clojure gets me by…
What specifically do you think it lacks?
@@freesoftwareextremist8119 just in general they’re behind. Haven’t even updated http libraries to 2.0. They just tell you “just use nginx!” It’s just more so the culture, they’re stuck OR PRIVATE. I know people have written their own modern web servers from scratch but they’re for their company. Not open source.
BTW, how cum there isn't a free, open-source, easy-to-use, graphical IDE for Lisp? If you want a nice graphical IDE, you have to pay through the nose for a commercial one.
What about Emacs?
@@asmewilliams7117 Emacs is not graphical. Emacs is not easy to use. Emacs has an enormously large and complicated command set.
You could take a look at Alive the lisp plugin for vscode. It seems to be getting lots of development lately
@@GavinFreeborn I have no doubt there are good efforts out there. But none of them are "universal" like Emacs. Smalltalk's IDE is "standard" in its overall design and philosophy (there are variations among different implementations). This universality is another Smalltalk strength.
@@horridohobbies it's less so emacs and more so slime. With pretty minimal effort another editor could support slynk (slimes backend). E.g. that's what alive, conjure (for neovim), and Lem
I'm not sure how special this is comparing to modern languages. For example, I've heard from my friends who develop in js that they can do pretty similar stuff as well. They have a repl, and even hot reloading.
I think you may have missed a few key differentiators. First the experience with interpreted languages is pretty similar. However, that's only in the sense that you can interact with the running program.
Common Lisp is a compiled language that allows you to modify the compiled program. JavaScript both in the browser and in nodejs. You only get what you called hot reloading in the sense that you can regenerate a page but for that to happen you can't be using those JavaScript resources. That's why there is an event loop and why JavaScript used on sites can become unresponsive.
That's not the case with common lisp since most of these features can be handled on a seperate thread the updating of symbols can happen asynchronously. E.g. I could have compiled a larger common lisp file into the project and used the browser without any delay. While nyxt isn't a great example for that I've done a stream where I worked on a video game and modified individual functions without any delay in the actual running game session.
Thanks for your comment and input!
@@GavinFreeborn we can get similar hot loading while developing using low level languages like c and c++.
i don't know if lisp can do more, like hook into an application out in the wild and manipulate at will. if it can do that, it will have something over c/c++ etc. ... but then you still have to put up with that awful syntax. not something i could convince myself to ever like (i've tried).
The difference is the LISP can edit itself as it is running. You can define a new DSL as you're developing. You can't do that with JS.
No, it isn't. It is a Programming System
Mmmm ... let's have a look at the job market ... I see lots of wanted java, php, c++ .... don't see lisp ... still good for fanboy talk on patreon
I need to cut my hair
Another underwhelming wide-eyed intro to a lisp repl that does nothing interesting. And the comment section is full of drones praising s-expr and how they can do a lot more with a lot less or something. Or maybe the whole thing is satire. In any case, this just makes me want to stay *far* away from any kind of lisp. Waste of time.
@@teenspirit1 another? Didn't know there were that many of these. Idk why you keep watching them if you don't care for them 😅
Here's the problem with languages endorsed by the intellectual elite... It usually takes an intellectual elite to use that language properly.
Haskell
OCaml
Lisp
Rust...even C++
The above is a small example of what I call ego languages. Languages that the average person trots out to brag to the other average types..
Being salty and feeling pity for yourself is not going to help you learn anything.
Where did you get feeling sorry for myself from my post? I'm just posting a fact about programmers (myself included ).
Then just stick to your JavaScript as I play with Coq, Agda, Lean and Idris ;-))
@@astroid-ws4py And yet JS is the worlds most used language! Why 'play' when you can actually do something constructive (and relatively easily).
@@jimiscott It is the most used because of the Web standard, Not because it is the best.