I wonder if Lisp would gain in popularity if it targeted non-programmer programmers. e.g. my experience with Python is it pulls in people who might not identify themselves as Computer Science people -- until they use Python so much that one day they realize they actually are programmers.
I don't think that lisp would become popular again, even if targeted for non-programmers, I also believe python wasn't specifically targeted for non-programmers, it just caught on. Everyone started making a video or a tutorial for it and so it became more easy to learn. It has relatively bit easier syntax and it resembles pseudocode a bit, or "english" as the memes say and then it started becoming popular among people as the good first programming language to learn. Most people who use python are the ones that want to do the task be done with it, as compared to lisp they would need get the past the parenthesis for the first 2-3 months and also learn recursive thinking, which is counter intuitive to as we humans think. It also doesn't help that python has more tooling support and bigger community which just makes it easier to get into. Honestly even for lisp beginners they can't understand how powerful it is until they get into the good parts, like code is data and data is code which just makes it easier and fun to create language abstractions in, functions as first-class citizens and macros.
Racket/Scheme & Clojure are easy for non-programmers to learn but they have to get over the parens and they need access to libraries which there are not many... Maybe if Lisp was the prefix "view" version of C, Ruby, Idris, Haskell, Ocaml, Python, and Smalltalk and code can be used in between each other whether or not they used S-expressions or infix expressions then you don't get the competing libraries problem.
@@syedkumailhussainsherazi3871 Lisp is not forcing anyone into "recursive" thinking. It has many powerful ways to do loops and it even has goto, aka (tagbody ...). And once you read the ca. 5 pages of "loops for blackbelts", it becomes easy soon to write (defun total (values) (loop for v in values summing v)) or do loops with control variables (loop for i below 10 do (print i))... Scheme is the Lisp dialect which tries to force people into a specific way of doing things - not Common Lisp.
@@ruffianeo3418 Oh, sorry but I haven't used Lisp and just assumed Scheme and Lisp are very similar. Also do you have the link for the paper you mentioned??
Lisp will never work for “non-programmer” programmers. Its syntax is weird enough to put off even those who consider themselves “hotshot” programmers (well, “hotshot” in the Java/C♯/C++ league). This syntax is a direct result of the fact that a program can be represented as a data structure built out of objects in the language itself. In other words, it’s a self-referential language in the most fundamental way.
@@पापानटोले Which Common Lisp runtime? It's a language specification, but their are at least 10 implementations use. Most are written in Common Lisp not C or C++, including SBCL which the most commonly used implementation. There are usually little bits of C to talk to the OS (which is usually written in a C language of some kind) or assembler for the compiler. Some of them have early versions that ran on Lisp Machines (a type of computer where everything including the operating system was in Lisp, and even the CPU used an assembly code that was basically Lisp-as-assembly-codes) and only added the little bits of C after Lisp Machines died out and they were forced to talk to operating systems written in C.
Every good Lisper will have his own Code style with his macros, therefore it’s hard to share their source code to beginners, so it’s not easy to learn it well
The atmosphere of lisp has always been very free spirited, casual, hacky, etc. The language is standardized, but otherwise everybody does what they feel like, and the language makes it easy to do crazy stuff. This may be bad for professional development, but it is perfect for people who want to truly express themselves on their code.
if that is the case, then you are using Lisp wrong, you are falling into this curse of lisp. YOU NEVER WRITE YOUR OWN MACROS. Macros are meant for libraries or frameworks, so they allow reusability and avoid application specific macros.
In my experience, it is mainly the quick-to-judgement and dismissive attitude of people which prevent (Common) Lisp from gaining more popularity. It goes a bit like this: A: "Why not CL?"" B, C, D giggling in unison. "All those parenthesis!" Topic over. 95% of people hearing about CL will not look any further. Of the remaining 5%, the statement "Slow - it is interpreted!" discourages another chunk. While it is wrong for now about 40 years. LISP is usually a compiled language and typically can reach like 90% of the speed of C. But the damage is done - After only 3 minutes of thinking about it, the majority of people dismiss it without even knowing, what makes LISP powerful. And there is no cure. Python is the living proof. While really slow compared to LISP, while it has really cryptic syntax, while being a mere shadow of LISP in terms of language power, it is now rank 3 or 4 on TIOBE index. In spite of the fact, that there are a lot of languages, which are faster and have better syntax than python, like for example OCAML/F#. People get what they deserve, I guess ;)
Pretty much my own experience... most just laugh at the parens it then takes an hour of talking like they are a child to get them to look passed the parens.
i learned lisp in 2013 at UC Berkeley....it was a great way for beginners to understand algorithms and data structures. I always show lisp to HS students so they can better understand recursion. Great vid!
LISP is more than a beginner language... Conditions, higher-order functions, closures, metaobject protocol, multimethods, optional return values, quasiquotes, macros, it has the ULTIMATE set of abstraction powers that many languages still don't even learn about.
Lisp via Clojure is relatively popular. I think at the ‘enterprise’ level there is a design for n-many people and Java is the lowest common denominator. In addition, Lisp is beautiful if looking at your own code; someone else’s …. A type system helps reason about code you’ve never seen before, written years ago… by possibly less experienced/capable teams.
As someone who was only briefly understood and been introduced to Lisp, I was stuck not understanding why it feels so off and why most Lisp projects are dead. This helps a lot and I know if I want to use Lisp, what it is I'm getting myself into.
To wit: Common LIsp has staying power. I have written CL 20 years ago that compiles with no errors to this day. Dead projects don't exist in Lisp (mhh..), they are just finished. Remember that CL is the expression of fundamental Lambda Calculus. That math is tight and correct.
"And you know how I know how I know that I'll prosper? 'Cause I stand here beside you today" - Ren (from Hi Ren)... about something quite different, but might be relevant here. Lisp is still around some 66 years after its initial creation... will it ever become comparatively popular? I don't know... but I kinda hope it does, and I certainly hope that people (including myself) put time in to collaborating on well-documented, welcoming, rich libraries, etc...
I looked at the Common LISP spec, and it’s full of baggage for maintaining compatibility with non-Unix-like operating systems, like VMS for goshsakes. If you strip out all the legacy junk, you could have a more modern language that could be a really good basis for future development.
Except all of that garbage turned out to be useful for maintaining compatibility with the most popular desktop operating system, which happens to be a VMS-like and not a unix-like. I for one like file paths being cross platform
Does being able to do anything force a programmer to determine, at a fundamental level, what they’re asking if their own work? I’ve only programmed in auto lisp, but I could author and maintain business processes, PLM, file version control and vaulting, with automatic email notifications to those needing stays updates along the way through the BPs. But keep a computer running at all times with a CAD session running to manage inputs/outputs from member users? Surely this can be done better in other languages. If not, then might LISP be used for business, product and process management?
The problem is the homoiconicity, the fact that program and data is the same type structure. When I learned programming on a mainframe I wondered which one of the big boxes was the compiler. That the compiler itself was a piece of data blew my mind, or rather, it didn't blow it at all, it was incomprehensible. A compiler, it seemed to me and seems to many, is a subject, doing something to an object, a thing being at the same time a subject and an object would be a categorial mistake, until you discover homoiconicity.
I've heard that lisp was in the browser before javascript but for Sun's money getting dumped into Java ... community followed the money, to its detriment. Javascript is fine but lisp would have been better. Maybe there is room for a lisp extender to browsers??
Also the self language was doing very good with its VM and using Smalltalk's elegance, for some reason Ruby and Python just had to be developed... Python is *VERY VERY* elegant, but its just not as elegant as Smalltalk. Ruby is only slightly more elegant than Python, but it didn't have that VM that Self and later JavaScript is known for...
Brendan Eich, the creator of Javascript, was in his own words "lured" to Netscape with the promise of being able to create Scheme (a LISP dialect) in the browser. But than his superiors said the syntax had to be closer to Java, that it should be called Javascript (it was Livescript before) and gave him only 10 days to finish it.
I agree with you that certain languages (MOSTLY LISP's and I'd argue the other one's are actually just LISPS that are not quite as "good" as the original but more re-statements of the same thing) are cursed, I might even agree with a few of your points regarding "individualism" but having worked in far far more diverse computing environments at every level from coder to system programer to giant project executive that you miss the mark in a big way with your conclusions. Contrary to common belief most "programmers/developers/whatever is the current term for people making computers do stuff" I'd say 90% are really not wired to be that good at it. This is a FACT that's not isolated to computer programming in any way, it's mostly that way with just about any profession and the observable difference becomes far more obvious the higher the complexity of the endeavor. I've had to contend with this in a million different ways. There are some problems that is far far far better handled with just a couple of really great programmers that for arguments sake each is literally 1000x more productive starting at zero and getting to the end. Which I'd personally prefer to be working on. Let's just say you can get maybe 5 of those people working on "that thing" so you have a capacity of 5000 units of productivity per unit time. What happens when you have a job that needs to be done that will take 5,000,000 units of effort? This is typically the case in a lot of real world settings. I'll take this full circle and even agree/support that the 1000x more productive small group could potentially redefine the problem and make that 5,000,000 units of effort be more like 500,000 or even 50,000 or possibly even 500... In the real world you don't get to redefine the problem because of risk management and unknown-unknowns because the upside any way you measure it with $$$$ it is in NO WAY going to take away even a slight downside unknown risk of not getting it done or done exactly the way the primary objective is defined from a business perspective. Lets say you have a group of technical employees that cost 1000 units of expense. Lets also say that any subdivision of those into 100 mixed in with 900 other generic parts can generally produce the same results of why they are there from a business perspective. That business perspective produces 1000000000000 of revenue/value. Would you prefer a group of 1 that could produce the same results? Even if that 1 were 10x "faster" in time to market as well? Probably not especially if that 1 was very difficult to replace or virtually impossible to replace because the population of those people are extremely small. In the real world you do you best to leverage each one of those "1"'s in the best possible way to make everything else marginally better/more productive/etc. A very difficult thing to do as most of them "understand" the notion but really don't like the solutions in terms of their hideous inefficiencies and inherent "wrong way" to go about doing whatever the endeavor is. I have managed that sort of thing very effectively after leaning how to do it over decades but only because I found a way to rationalize it myself via compartmentalizations of "my stuff" and "their stuff". At the end of it most "languages" actually all of them are just ways of given "other people" ways of doing things that they can "understand" and most of the people I consider to be in the group of "1";s don't really give a hoot which particular language as it's all the same to them, in fact most people that use LISP's or any other tool is so that they can construct something to solve the problem akin to a DSL for that problem. All languages in terms of computer languages are in essence "DSL's" so that people that have less of a clue as to how it all works can produce any result at all. The reason many of the "1"'s latch on to LISP's or LISP like things is because of it's orthogonality (IE take a look at the original EVAL function in McCarthy's paper vs say the fairly pedantic far more complicated Turing machine in terms of elegance) in other words LISP's were purpose built (even if a happy accident) for manipulating symbols in a very elegant and orthogonal way and tada.... lambda's... which at the end of the day any of those developers/programmers etc that I would consider wired in a certain way the makes them actually good at it have done the same exact thing no matter if it was on the bare metal/c or whatever... function pointers, lamdas, and some sort of way to succinctly state general algorithms across a wide variety of dynamic data and combinations. LISP was/is a fantastic and elegant general purpose statement of what computing formule and recipes actually do and how to think about them We've seen this semi-re-invented 800000000 times with various languages and ta-da we have Haskell/functional languages which is a few of these concepts done exactly wrong due to far far too much influence of "math guys" which have always lagged behind even the comprehension of computing algorithms as a formalized problem because it never fit their out-dated model of representational models (yes just because a lot of great math guy's happened also to be great computing guys doesn't mean the math academic establishment is the same) Ps. I am not crapping on Haskell as opposed to anything else but it's fairly obvious if you're not religious about it that a few stakes in the ground are absolutely WRONG given how inelegant it is to control lazy vs eager evaluation and what sort of bad behavior that causes in real world use. LISP's on the other hand can do either fairly elegantly... power with elegance.
We need a LISP plug-in living resident within an office suite (like the one in a common CAD program). Then LISP will take off from problem solvers everywhere.
I think some people really hate s-expression syntax, maybe, if there was a "thin" wrapper above s-expressions like Mathematica it could help a bit and many others aren't very good at using emacs。
I think it is because in Lisp dialects you program using the syntax tree from the get go, and in other languages it is normally the next abstraction from the code syntax and so it does not have a rigid structure and together with macros every Lisp programmer basically program in his own Domain Specific Language (DSL). PS: My two cents about the curse: It's an economical effect, if to hire a time of 100 people is a must and it is really expensive, it will drive away the competition with less capital, its the same effect that government regulation do, the big companies love them because they drive smaller companies away from the market.
Lisp is very more popular than you think it is, all modern languages have useful lispy bits in them, and productive programmers use those bits every single day in lots of languages. The curse is: a powerful language requires less investment (time, manpower, financial) and it's that lack of investment in software development that produces unfinished projects.
Thanks for your video Eric! As an enterprise Java refugee learning Haskell, I never thought about the point you mentioned, of companies preferring replaceable programmers.. Sadly makes all sense. I guess i will have to futurely seek a functional dev company, or start my own :)
8:21 - No, ANTLR is NOT a 100% solution to parsing. The fact that it's hard to use is because of all the stuff it leaves unsolved. The complexity of doing that stuff is dumped into every single application that uses ANTLR, making those applications more complex, which reinforces the need to have a giant team to maintain it. Most big frameworks in mainstream languages are 80% solutions or less. True 100% solutoins require a lot of knowledge. You have to know what problems others are running into, and your language has to allow you to solve _all_ the problems, even the ones that users unconsciously just endure without complaining. An example of a 100% solution would be CLOS with the MOP included. Or Common Lisp's condition system. A ton of research went into those. Mainstream solutions are just built ad-hoc using the easiest approach given the tools already available. Then the inevitable limitations are addressed if it's easy to do so. The real curse of Lisp is that since Lisp is so powerful and you only need a few developers, those developers end up being critical to an organization, because they're the equivalent of a big team. Therefore, firing and replacing one of those developers is like laying off an entire department and rebuilding it from the ground up. Clojure escaped the "Curse of Lisp" by being an 80% Lisp. The reason you need all those Java libraries is because Clojure is relatively weak. Common Lisp has pretty good C interop, but it's not used anywhere near as frequently as Java is in Clojure programs.
To Common Lisp: Is there any way to build a standardized set of the most commonly needed tasks, to provide a single body of work as a common touchstone?
There are several attempts, such as awesome-cl. As with any such thing in any language, it depends upon a critical mass -- enough programmers who like the functionality and/or style that other programmers look at them and feel safe spending the time to learn it. One issue is the loner mentality of a lot of Lispers, many of whom say things like "why have a library for THAT when you can just write it in a few hours?" or "I'm doing hard problems -- I don't want to write utilities for a website." Other languages have less of that.
The curse of powerful languages in general is that they require powerful brains to be programmed and understood, and that is a scarce/expensive resource. If someone invented a language that monkeys could program in, it would be far more popular than java.
Could part of the answer be that functional programming is harder to understand? Perhaps it's just me--and perhaps because I'm not a professional programmer--but I spent a couple of weeks trying to learn clojure and it never made that much sense to me. It never clicked, and the more I learned, the more I hated it and just wanted to go back to Python. Clojure was so much more difficult to read, and even simple stuff took me a while to figure out because of the inside-out way I had to look at functions, i.e. find the inner core inside all the nested parentheses and then work your way out, instead of a straightforward reading that other languages like Python would give me. Maybe I just needed to stick with it a little longer, but it felt like someone learning Python, as an example, could be productive on day one, whereas with clojure I spent days learning and never even got to the point of accepting user input. It was a huge learning curve and I never hit that lightbulb moment where I understand why it was worth the time. i'm sure if I could see it, I'd be more motivated to learn it. I'm also sure this is a personal limitation and not a general problem with LISPs.
There's usually quite a steep learning curve for many with functional programming. I've heard many people say it's just a different mindset but I think it's a bit exaggerated. I'm willing to gamble that Python is a lot easier to teach a child than Lisp, e.g. But I think that's true of very powerful stuff in general. For example, consider FL Studio vs. Reason in the digital audio workstation world, or Houdini/Maya vs. Modo in the VFX world, or Solidworks vs. Rhino3D in CAD/CAM, or oil paints vs. watercolor, etc.
@@darkengine5931 I'm sure you're right. For me, the learning curve was too steep. My interest in learning the language was not strong enough to keep me motivated to get over that initial hump. It was sort of a chicken and egg problem. Without knowing the language, it was difficult for me to understand why it would be worth it to learn the language. Even after many days of learning, I still hadn't gotten to basic input/output and simple stuff that you learn day one in just about every other language course. It was very odd. I've written plenty of Python, and in the past dabbled in C, C++, Go, assembly, Fortran, Pascal, and various flavors of BASIC. None of them were remotely as difficult to grasp as clojure for me. I really struggled to wrap my brain around it.
For Lisps you need to dim the parenthesis so your going by indentation, its similar to python in that way. Code is data, and data is code requires a collection of insight to understand it fully, but you can probably there by looking at eval written in Lisp, imagine yourself editing the eval function to change the semantics of Lisp, learning about quasiquotes and macros (which are compilers/transpilers), imagining SQL, HTML, C in s-expressions and what the eval functions FOR THOSE would look like. Next imagine creating your own version of defun, cond, let, set, progn/do but would a slight twist your own version of defun would statically check things at compile time, or add logging. Next thing about functions operating in data. Your data is also in S-expressions, but unlike the turing complete code in Lisp eval, it has your data has a fixed shape. Any functions that operate on your data are really other forms of eval. So there is a graduation between data and code and a function and an eval function depending on how many cases you support.
Maybe expressiveness causes also that it is harder to read and reason about what code do? In other words it is easy to write own thoguths to lisp, but importing other people thoughts from lisp code is quite hard despite expressivnes?
It's interesting that Clojure programs eschew small, local identities in favor of large ones, while the Clojure community consists of small, individual identities and eschews large ones.
I would like to learn Lisp in the future but I don't really see any practical use for it. There's also N variations to choose from, and each seems to be doing its own thing, so it's hard to pick one. There's also the weirdness of the tooling around Lisp, which feels very alien to someone who's used to just open an editor and start typing some code.
Hey why not make a program to "unroll" all the macros in a src file so that you can read someone else's lisp in a more standard way? Here's why not: if you can read someone else's code, then you might have to.
So is this why Python is so popular? Because it is so hard to do anything serious in a language that features structure for the sake of structure like COBOL?
Scheme fractured into lots of different languages that weren't compatible, and Scheme itself fractured the Lisp community? Scheme could have made it in the browser as JavaScript, but C/C++ programmers didn't want to learn any new syntax so they ended up creating the unholy evil language that is JavaScript.
Tried lisp before , not having an editor built for lisp , makes it a pain to code in. Many of the function names and syntax are wierd. Simple printing has this wierd function. Why use car cdr when first and last is more intuitive. The cli is painful to work in. How dyu run a program or get thru a screenful of errors? What about documentation to lookup function names etc there's a reason some languages succeed more than others. Some are simply more usable.
Give DrRacket a whirl. All the problems mentioned are addressed and then some! Excellent editor, with two windows, one for developing incrementally and one for running. Complete documentation. Great plotting and graphics for testing things on the fly. A shedload of support at many, many levels: community, books, tutorials. Amazing abilities once you get a bit more familiar. And that's not the only one! There are so many excellent systems and environments, no one should have to suffer with unmanageable command lines. The one I mentioned above is just the easiest, but you can get stuff in VS Code, in Emacs and all sorts of other environments and language flavours. Clojure gives you pretty neat interop with the whole JVM ecosystem. A teeny bit of research will reward you richly...
I have experienced this curse too. I have coded an e-commerce website myself, and I could do so much more myself than a team of people. Now, the question is, when I want to make a startup out of what I have done, I have to look for people who can take care of the code I have written, add more to it and enhance it, so that, I can look into the business aspects. But, I am not finding anybody who can do it. Software development is a community effort to get successful and even more to maintain it. I totally agree with the 1) commercial aspects of companies looking for people who can be fired, go on maternity leaves, etc. Basically, people who are replaceable. And that, you get with the not so powerful languages. 2) Personal aspect of common lisp giving boost to individualism or the ego. If common lisp can solve these issues, it can still thrive, I believe.
Its not a problem, it is what it is. You dont complain to a wizard about how they write their spellbook. Imagine a world that every wizard now has to write their spell in a particular way
I love Lisp, but it suffers from the same types of problems that Python does. As it scales, it's just too easy to break things with mismatched types, number of arguments, etc... you have to exercise all code paths at runtime to have confidence in it. Compare that to Rust where if it compiles, it typically just works. If I was starting a company that needed to innovate very quickly, I'd use Lisp. But if I was a company that had mission critical systems that must work, but could take a little more time to get there, I'd likely use Rust.
I haven't written one meaningful app in Lisp yet I'm reading Lisp docs like a maniac trying to understand as many things as possible - now that's a curse. I think the quote form and pattern matching on s-expressions are the most powerful features of any lisp. Not many programming languages give you that power, with the exception of Julia, Nim and maybe Rust? It allows you to invent your own notations for the domain you're working in. But other than that...Lisps are just another family of programming languages.
Java and Python are popular. They allow us to build websites with server based data validation and controllers (as in MVC design pattern). They allow us to work with MS Excel documents, encryption, DTDs, file zipping, emails, etc. I feel that I would find these things harder in Lisp. Otherwise I would be interested in trying Lisp.
Lisp is great, but the barrier to entry is much higher than let's say python. You can get used to parenthesis, but how do you give real business value quick enough? How do you ask millenials and gen-z to invest in a language that is 50yrs old. Software engineers won't understand this, computer scientist's will.
Only people that like Python are those that didn't have to do Fortran. I was so happy that Fortran died, it was awful. Can't stand the format dependancy, this is a blocker for me. I'd rather use Swift than Python.
My submission to the question: I think it's because recursive thinking is not intuitive and it never clicks for most people, which shuts off most of the advantages of Lisp for most people.
Those people should not be programming should they? I have delivered a commercial project almost entirely implemented in Common Lisp with C bits to interface with telco hardware. It is still being used in production without any issues.
> My submission to the question: I think it's because recursive thinking is not intuitive I'd question that. I would suggest that recursive thinking is *way* more intuitive, we seem to have hypnotized ourselves into thinking the opposite... Therein the problem lies. Not enough good quality teachers teaching the basics. A historic problem.
Lisp and its dialects are not popular because it is not people centric (close to english) rather are compiler-parser friendly, which discourages people to get involved in the first place. Maybe more important was speed back then (1960's) but now not so much (clojure is quite fast). Finally OO models the world "better" than Functional which played a big role in adoption. Modern languages that are now succesfull take a hybrid approach (OO + Functional) and combine the best of the 2 major programming paradigms i.e Python, Java, Javascript, C#, Scala,Rust,Swift even C++20.
very interesting video!... now i do not have much time right now... so i can not elaborate on this in any detail... but i think you may find it worthwhile to ponder the following... 1. how powerful an instrument / tool is a stradivari? 2. how important is the quality of a piano played in a lively wild west type saloon? 3. why did will smith have such a hard time selling those superior bone density scanners in the pursuit of happyness? 4. why are there so very few people out there conversing in latin... when the language has clearly so much to offer!?... ( ... i mean... simply pick at random a text written in english and one in latin... the difference in quality and depth of thought should be obvious... ) 5. ... the list goes on... but i will not.... since i gotta run now :-).... but thx again for taking the time to make the video!
Truth seeking developers are forced to either be entrepreneurs or work for startups if they want to work with highly motivated minds and/or maximize productivity.
@@Bizmonger ...so... couple of things :-).... first of all, not knowing anything about you but the fact that you wrote this reply to my comment, i would be perfectly willing to assume you are either an entrepreneur or working for a startup... or both...:-).... second of all, my intent was really to point out how one could quite easily miss the wood for the trees, especially if there is some sort of vested interest / bias involved... just talk to any classics-scholar and she is sure to explain to you why we should teach more latin / greek etc. in school.... etc. etc..... and there's nothing wrong with that! ... now it has been i while since i watched the video, but if i recall correctly one of the main lines of the argument went something like.... programming in lisp makes you orders of magnitude more productive than programming in a mainstream language like java.... i really can not remember the exact wording / numbers used in this particular clip.... and it doesn't even matter.... for you will find people making ridiculous claims about programming-languages and increased / decreased productivity everywhere and all of the time... and again that's really cool... in the sense that people sell stuff.... so obviously you wanna have promotion.... i guess the reason why i wrote that comment was, because this really did not feel like an attempt to spread the lisp gospel, but rather he seamed to really be puzzled by the fact that people / companies would not immediately want to hop off the java and onto the lisp wagon..... and finish the work that previously took them 150 days to get done in an afternoon... :-).... or whatever.... so basically my intent was to point out that.... well obviously! there is a huge cost involved in making a change like that... ( ... suppose i was to tell you that thinking in japanese instead of english will increase your productivity / mental capabilities :-)... oh lets say... by two orders of magnitude :-).... well.... then... not only are the numbers involved downright outrages...BUT!... that claim also fails completely to take into consideration / account the ENORMOUS investments that will be required in order for you to be able to master the japanese language in the first place!... ) ... bottom line... picking up a new language ( programming or otherwise ) is a serious challenge, and for a run of the mill problem the difference in productivity will be nowhere near large enough to justify it... ...hmmm... note sure if i explained myself well enough.... does this make sense?
Languages which empower the lone hacker are traditionally undervalued due to corporate influence. But the complexity of today's computing problems are forcing corporations to turn to technologies they once tried to overshadow. EDIT :: {side_note, clarification} :: The biggest competition of corporations is lone hackers. Corporations aren't going to fund the technology which disproportionately help their biggest competitor, UNLESS THEY ABSOLUTELY HAVE TO! That is why it has taken so long for these superior technologies to make a comeback!
What would the massive amount of work taken for a tool like Antler say be equivalent to with the same 'massive amount' of work undertaken on a LISP project? AI prolly.... Lol jk xP
watched on 1.5x. I always have been a guy who wants the most modern languages - Scala, Julia and now Rust. Now interested in what happened to LISP. For mentioned langs there is similar curses - they're all better than their predecesors, but not so many people use them because they're new (self enforcing loop) note: although Rust grows exponentially according to it's github stars history. Another curse is the curse of Esperanto - it is an artificial auxiliary language created in XIX century to be the language that everybody in the world knows (sort of). As you may realize that is not the case which makes me think that humanity is doomed - we build freaking AI systems that allow for translating one language into another (and also may eventually kill us) "faster" than learn a language that is like 1 to 3 month to learn.
As soon as you give up the ability to handle time, the language becomes a pain in the ass for practical applications generally. There were Lisp machines and Lisp operating systems with tagged memory.... but x86 and windows just kind of steam rolled because Intel way better at making transistors.
Yes, I think it sounds like it. Lispers describing the Lisp curse use the power of Lisp as an excuse but other dynamic languages like Perl, Python, or Ruby are similarly powerful. Much like Lisp they make it possible to write a prototype very fast, and solve a lot of problems in small teams. The difference is that they established a culture of sharing code, and from that a culture of thinking the code design through in terms of interface, documenting it, putting it out there, looking for solutions that are already out there. There is however an underappreciated aspect of this 'curse'. Lisp is so old that in its beginning many users were isolated because they had intermittent network connectivity or none at all, sharing code was not as easy as it is today. When you come into an environment where for every problem you get dozens of libraries that each solve a different 60% of it you stop looking after a while, and miss even libraries that really would work. Also when network connectivity became more common Lisp has become fragmented into numerous mutually incompatible dialects which again made sharing code hard. If anything making the syntax computer-centric (easy to parse) rather than human-centric (easy to read) made writing Lisp interpreters really easy enabling the explosion of various dialects.
Average human is too dumb. And, on top of it, culturally we watch mikey mouse and catoons when we are kids. The people who could understand it, they do not. Because the rest of the world is using java. Clojure is a workaround that. Let's hope we make the shift
*CORRECTION:* "Man hours" is not the "sexist" version of anything. "Man hours" is simply the *correct* way of communicating the notion of work hours in the English language. Nothing more, nothing less. There is no need to apologize for using English correctly. It's heartbreaking to have to watch an adult human being actually *apologize* for conveying his thoughts because he was browbeaten, brainwashed and shamed into it. It's Man hours. It's Mankind. It's Salesman. It's Spokesman. It's Chairman. If a cult of misandrists disapproves of that, too bad. The effort to control and subvert language and how people communicate in all areas of life is not carried out by chance. It is tendentiously carried out by said cult to normalize its pathological misandry and slowly instill their false consciousness in all of us: one that denies human males their human status. One that denies human males their basic human rights. One that pathological misandrists hold. Do not ever apologize. Defy authoritarian cults pretending to be righteous, virtuous and noble. They are not. They will control your language and will proceed to control you, because power over other is all they seek.
We need a LISP plug-in living resident within an office suite (like the one in a common CAD program). Then LISP will take off from problem solvers everywhere.
Thumbs up if you're using Common Lisp in 2021.
2024 ✋
“Alone we go faster,
Together we go further”
like octopus intelligent , dont have social life
I wonder if Lisp would gain in popularity if it targeted non-programmer programmers. e.g. my experience with Python is it pulls in people who might not identify themselves as Computer Science people -- until they use Python so much that one day they realize they actually are programmers.
I don't think that lisp would become popular again, even if targeted for non-programmers, I also believe python wasn't specifically targeted for non-programmers, it just caught on. Everyone started making a video or a tutorial for it and so it became more easy to learn. It has relatively bit easier syntax and it resembles pseudocode a bit, or "english" as the memes say and then it started becoming popular among people as the good first programming language to learn. Most people who use python are the ones that want to do the task be done with it, as compared to lisp they would need get the past the parenthesis for the first 2-3 months and also learn recursive thinking, which is counter intuitive to as we humans think. It also doesn't help that python has more tooling support and bigger community which just makes it easier to get into. Honestly even for lisp beginners they can't understand how powerful it is until they get into the good parts, like code is data and data is code which just makes it easier and fun to create language abstractions in, functions as first-class citizens and macros.
Racket/Scheme & Clojure are easy for non-programmers to learn but they have to get over the parens and they need access to libraries which there are not many... Maybe if Lisp was the prefix "view" version of C, Ruby, Idris, Haskell, Ocaml, Python, and Smalltalk and code can be used in between each other whether or not they used S-expressions or infix expressions then you don't get the competing libraries problem.
@@syedkumailhussainsherazi3871 Lisp is not forcing anyone into "recursive" thinking. It has many powerful ways to do loops and it even has goto, aka (tagbody ...). And once you read the ca. 5 pages of "loops for blackbelts", it becomes easy soon to write (defun total (values) (loop for v in values summing v)) or do loops with control variables (loop for i below 10 do (print i))... Scheme is the Lisp dialect which tries to force people into a specific way of doing things - not Common Lisp.
@@ruffianeo3418 Oh, sorry but I haven't used Lisp and just assumed Scheme and Lisp are very similar. Also do you have the link for the paper you mentioned??
Lisp will never work for “non-programmer” programmers. Its syntax is weird enough to put off even those who consider themselves “hotshot” programmers (well, “hotshot” in the Java/C♯/C++ league).
This syntax is a direct result of the fact that a program can be represented as a data structure built out of objects in the language itself. In other words, it’s a self-referential language in the most fundamental way.
The curse of Lisp is that it's too good.
But Common Lisp run time is made in C/C++ , right ?
Uhuh?
@@पापानटोले Which Common Lisp runtime? It's a language specification, but their are at least 10 implementations use. Most are written in Common Lisp not C or C++, including SBCL which the most commonly used implementation. There are usually little bits of C to talk to the OS (which is usually written in a C language of some kind) or assembler for the compiler. Some of them have early versions that ran on Lisp Machines (a type of computer where everything including the operating system was in Lisp, and even the CPU used an assembly code that was basically Lisp-as-assembly-codes) and only added the little bits of C after Lisp Machines died out and they were forced to talk to operating systems written in C.
@@harryhenrygebel3506
Thanks for clarification.
@@पापानटोले wow a conversation that didnt end with someone insulting lisp saying it had too much parentheses
Every good Lisper will have his own Code style with his macros, therefore it’s hard to share their source code to beginners, so it’s not easy to learn it well
In other, more successful, language ecosystems, programmers who write code that others cannot understand are considered mediocre.
New to lisp, wouldn't the macros standerdize over time?
The atmosphere of lisp has always been very free spirited, casual, hacky, etc. The language is standardized, but otherwise everybody does what they feel like, and the language makes it easy to do crazy stuff.
This may be bad for professional development, but it is perfect for people who want to truly express themselves on their code.
@@vegai yeah, you fundamentally misunderstood what was said. Other languages have stronger abstraction, and the macro would be imported as a library.
if that is the case, then you are using Lisp wrong, you are falling into this curse of lisp.
YOU NEVER WRITE YOUR OWN MACROS.
Macros are meant for libraries or frameworks, so they allow reusability and avoid application specific macros.
As a Java programmer of over twenty years, I think you're on to something here.
Fennel and Janet are modern Lisps that are pretty nice. I use Fennel for configuring NeoVim and making games in Love2D.
FENNEL NEOVIM MENTIONED 🎉🎉🎉
In my experience, it is mainly the quick-to-judgement and dismissive attitude of people which prevent (Common) Lisp from gaining more popularity.
It goes a bit like this:
A: "Why not CL?""
B, C, D giggling in unison. "All those parenthesis!"
Topic over. 95% of people hearing about CL will not look any further.
Of the remaining 5%, the statement "Slow - it is interpreted!" discourages another chunk.
While it is wrong for now about 40 years. LISP is usually a compiled language and typically can reach like 90% of the speed of C.
But the damage is done - After only 3 minutes of thinking about it, the majority of people dismiss it without even knowing, what makes LISP powerful.
And there is no cure. Python is the living proof. While really slow compared to LISP, while it has really cryptic syntax, while being a mere shadow of LISP in terms of language power, it is now rank 3 or 4 on TIOBE index.
In spite of the fact, that there are a lot of languages, which are faster and have better syntax than python, like for example OCAML/F#.
People get what they deserve, I guess ;)
Pretty much my own experience... most just laugh at the parens it then takes an hour of talking like they are a child to get them to look passed the parens.
i learned lisp in 2013 at UC Berkeley....it was a great way for beginners to understand algorithms and data structures. I always show lisp to HS students so they can better understand recursion. Great vid!
Very cool!
LISP is more than a beginner language... Conditions, higher-order functions, closures, metaobject protocol, multimethods, optional return values, quasiquotes, macros, it has the ULTIMATE set of abstraction powers that many languages still don't even learn about.
@@aoeu256 But the minimal syntax and _list processing_ capabilities do make it pretty easy to get a hang of the basics using LISP
Lisp not popular because we dont have enough memer of lisp. We need more memes.
THIS.
We don't need that many memes when we have xkcd:
imgs.xkcd.com/comics/lisp.jpg
Lisp via Clojure is relatively popular. I think at the ‘enterprise’ level there is a design for n-many people and Java is the lowest common denominator. In addition, Lisp is beautiful if looking at your own code; someone else’s …. A type system helps reason about code you’ve never seen before, written years ago… by possibly less experienced/capable teams.
As someone who was only briefly understood and been introduced to Lisp, I was stuck not understanding why it feels so off and why most Lisp projects are dead. This helps a lot and I know if I want to use Lisp, what it is I'm getting myself into.
To wit: Common LIsp has staying power. I have written CL 20 years ago that compiles with no errors to this day. Dead projects don't exist in Lisp (mhh..), they are just finished.
Remember that CL is the expression of fundamental Lambda Calculus. That math is tight and correct.
"And you know how I know how I know that I'll prosper?
'Cause I stand here beside you today" - Ren (from Hi Ren)... about something quite different, but might be relevant here. Lisp is still around some 66 years after its initial creation... will it ever become comparatively popular? I don't know... but I kinda hope it does, and I certainly hope that people (including myself) put time in to collaborating on well-documented, welcoming, rich libraries, etc...
I looked at the Common LISP spec, and it’s full of baggage for maintaining compatibility with non-Unix-like operating systems, like VMS for goshsakes. If you strip out all the legacy junk, you could have a more modern language that could be a really good basis for future development.
Except all of that garbage turned out to be useful for maintaining compatibility with the most popular desktop operating system, which happens to be a VMS-like and not a unix-like. I for one like file paths being cross platform
"Constraints liberate, liberties constrain" - Runar Bjarnson
That's a great quote, thank you
You could always do what RMS did. Have your Lisp code spit out the C source code and pretend to be a C programmer.
I have a generator that spits out Golang code. Ha! All the devs thought I was a Guru; but those macros.. come on its simple guys!
Does being able to do anything force a programmer to determine, at a fundamental level, what they’re asking if their own work? I’ve only programmed in auto lisp, but I could author and maintain business processes, PLM, file version control and vaulting, with automatic email notifications to those needing stays updates along the way through the BPs. But keep a computer running at all times with a CAD session running to manage inputs/outputs from member users? Surely this can be done better in other languages. If not, then might LISP be used for business, product and process management?
The problem is the homoiconicity, the fact that program and data is the same type structure. When I learned programming on a mainframe I wondered which one of the big boxes was the compiler. That the compiler itself was a piece of data blew my mind, or rather, it didn't blow it at all, it was incomprehensible. A compiler, it seemed to me and seems to many, is a subject, doing something to an object, a thing being at the same time a subject and an object would be a categorial mistake, until you discover homoiconicity.
I've heard that lisp was in the browser before javascript but for Sun's money getting dumped into Java ... community followed the money, to its detriment. Javascript is fine but lisp would have been better. Maybe there is room for a lisp extender to browsers??
You can use clojurescript and compile to js if you want Lisp on the web
Also the self language was doing very good with its VM and using Smalltalk's elegance, for some reason Ruby and Python just had to be developed... Python is *VERY VERY* elegant, but its just not as elegant as Smalltalk. Ruby is only slightly more elegant than Python, but it didn't have that VM that Self and later JavaScript is known for...
Brendan Eich, the creator of Javascript, was in his own words "lured" to Netscape with the promise of being able to create Scheme (a LISP dialect) in the browser. But than his superiors said the syntax had to be closer to Java, that it should be called Javascript (it was Livescript before) and gave him only 10 days to finish it.
The curse of lisp is that there are no videos on "CONS Should not CONS its Arguments part II: Cheney on the M.T.A." on TH-cam.
I agree with you that certain languages (MOSTLY LISP's and I'd argue the other one's are actually just LISPS that are not quite as "good" as the original but more re-statements of the same thing) are cursed, I might even agree with a few of your points regarding "individualism" but having worked in far far more diverse computing environments at every level from coder to system programer to giant project executive that you miss the mark in a big way with your conclusions.
Contrary to common belief most "programmers/developers/whatever is the current term for people making computers do stuff" I'd say 90% are really not wired to be that good at it. This is a FACT that's not isolated to computer programming in any way, it's mostly that way with just about any profession and the observable difference becomes far more obvious the higher the complexity of the endeavor. I've had to contend with this in a million different ways.
There are some problems that is far far far better handled with just a couple of really great programmers that for arguments sake each is literally 1000x more productive starting at zero and getting to the end. Which I'd personally prefer to be working on. Let's just say you can get maybe 5 of those people working on "that thing" so you have a capacity of 5000 units of productivity per unit time. What happens when you have a job that needs to be done that will take 5,000,000 units of effort? This is typically the case in a lot of real world settings. I'll take this full circle and even agree/support that the 1000x more productive small group could potentially redefine the problem and make that 5,000,000 units of effort be more like 500,000 or even 50,000 or possibly even 500... In the real world you don't get to redefine the problem because of risk management and unknown-unknowns because the upside any way you measure it with $$$$ it is in NO WAY going to take away even a slight downside unknown risk of not getting it done or done exactly the way the primary objective is defined from a business perspective.
Lets say you have a group of technical employees that cost 1000 units of expense. Lets also say that any subdivision of those into 100 mixed in with 900 other generic parts can generally produce the same results of why they are there from a business perspective. That business perspective produces 1000000000000 of revenue/value. Would you prefer a group of 1 that could produce the same results? Even if that 1 were 10x "faster" in time to market as well? Probably not especially if that 1 was very difficult to replace or virtually impossible to replace because the population of those people are extremely small.
In the real world you do you best to leverage each one of those "1"'s in the best possible way to make everything else marginally better/more productive/etc. A very difficult thing to do as most of them "understand" the notion but really don't like the solutions in terms of their hideous inefficiencies and inherent "wrong way" to go about doing whatever the endeavor is. I have managed that sort of thing very effectively after leaning how to do it over decades but only because I found a way to rationalize it myself via compartmentalizations of "my stuff" and "their stuff".
At the end of it most "languages" actually all of them are just ways of given "other people" ways of doing things that they can "understand" and most of the people I consider to be in the group of "1";s don't really give a hoot which particular language as it's all the same to them, in fact most people that use LISP's or any other tool is so that they can construct something to solve the problem akin to a DSL for that problem. All languages in terms of computer languages are in essence "DSL's" so that people that have less of a clue as to how it all works can produce any result at all. The reason many of the "1"'s latch on to LISP's or LISP like things is because of it's orthogonality (IE take a look at the original EVAL function in McCarthy's paper vs say the fairly pedantic far more complicated Turing machine in terms of elegance) in other words LISP's were purpose built (even if a happy accident) for manipulating symbols in a very elegant and orthogonal way and tada.... lambda's... which at the end of the day any of those developers/programmers etc that I would consider wired in a certain way the makes them actually good at it have done the same exact thing no matter if it was on the bare metal/c or whatever... function pointers, lamdas, and some sort of way to succinctly state general algorithms across a wide variety of dynamic data and combinations. LISP was/is a fantastic and elegant general purpose statement of what computing formule and recipes actually do and how to think about them
We've seen this semi-re-invented 800000000 times with various languages and ta-da we have Haskell/functional languages which is a few of these concepts done exactly wrong due to far far too much influence of "math guys" which have always lagged behind even the comprehension of computing algorithms as a formalized problem because it never fit their out-dated model of representational models (yes just because a lot of great math guy's happened also to be great computing guys doesn't mean the math academic establishment is the same)
Ps. I am not crapping on Haskell as opposed to anything else but it's fairly obvious if you're not religious about it that a few stakes in the ground are absolutely WRONG given how inelegant it is to control lazy vs eager evaluation and what sort of bad behavior that causes in real world use. LISP's on the other hand can do either fairly elegantly... power with elegance.
Corporations prefer flocks of sheep over a lone wolf.
We need a LISP plug-in living resident within an office suite (like the one in a common CAD program). Then LISP will take off from problem solvers everywhere.
We have one it’s called emacs
And AutoLISP in AutoCAD
I think some people really hate s-expression syntax, maybe, if there was a "thin" wrapper above s-expressions like Mathematica it could help a bit and many others aren't very good at using emacs。
I think it is because in Lisp dialects you program using the syntax tree from the get go, and in other languages it is normally the next abstraction from the code syntax and so it does not have a rigid structure and together with macros every Lisp programmer basically program in his own Domain Specific Language (DSL).
PS: My two cents about the curse: It's an economical effect, if to hire a time of 100 people is a must and it is really expensive, it will drive away the competition with less capital, its the same effect that government regulation do, the big companies love them because they drive smaller companies away from the market.
Lisp is very more popular than you think it is, all modern languages have useful lispy bits in them, and productive programmers use those bits every single day in lots of languages.
The curse is: a powerful language requires less investment (time, manpower, financial) and it's that lack of investment in software development that produces unfinished projects.
Thanks for your video Eric! As an enterprise Java refugee learning Haskell, I never thought about the point you mentioned, of companies preferring replaceable programmers.. Sadly makes all sense. I guess i will have to futurely seek a functional dev company, or start my own :)
8:21 - No, ANTLR is NOT a 100% solution to parsing. The fact that it's hard to use is because of all the stuff it leaves unsolved. The complexity of doing that stuff is dumped into every single application that uses ANTLR, making those applications more complex, which reinforces the need to have a giant team to maintain it. Most big frameworks in mainstream languages are 80% solutions or less.
True 100% solutoins require a lot of knowledge. You have to know what problems others are running into, and your language has to allow you to solve _all_ the problems, even the ones that users unconsciously just endure without complaining. An example of a 100% solution would be CLOS with the MOP included. Or Common Lisp's condition system. A ton of research went into those. Mainstream solutions are just built ad-hoc using the easiest approach given the tools already available. Then the inevitable limitations are addressed if it's easy to do so.
The real curse of Lisp is that since Lisp is so powerful and you only need a few developers, those developers end up being critical to an organization, because they're the equivalent of a big team. Therefore, firing and replacing one of those developers is like laying off an entire department and rebuilding it from the ground up.
Clojure escaped the "Curse of Lisp" by being an 80% Lisp. The reason you need all those Java libraries is because Clojure is relatively weak. Common Lisp has pretty good C interop, but it's not used anywhere near as frequently as Java is in Clojure programs.
To Common Lisp: Is there any way to build a standardized set of the most commonly needed tasks, to provide a single body of work as a common touchstone?
There are several attempts, such as awesome-cl. As with any such thing in any language, it depends upon a critical mass -- enough programmers who like the functionality and/or style that other programmers look at them and feel safe spending the time to learn it. One issue is the loner mentality of a lot of Lispers, many of whom say things like "why have a library for THAT when you can just write it in a few hours?" or "I'm doing hard problems -- I don't want to write utilities for a website." Other languages have less of that.
The curse of powerful languages in general is that they require powerful brains to be programmed and understood, and that is a scarce/expensive resource. If someone invented a language that monkeys could program in, it would be far more popular than java.
Well Racket/Scheme and Haskell (well at least Elm) is in many ways EASIER than Python, but the marketing and libraries are not there.
C++ is bad too is this aspect. I see way too many solutions today... I have really hard time to decide even library for logging in 2022...
Could part of the answer be that functional programming is harder to understand? Perhaps it's just me--and perhaps because I'm not a professional programmer--but I spent a couple of weeks trying to learn clojure and it never made that much sense to me. It never clicked, and the more I learned, the more I hated it and just wanted to go back to Python. Clojure was so much more difficult to read, and even simple stuff took me a while to figure out because of the inside-out way I had to look at functions, i.e. find the inner core inside all the nested parentheses and then work your way out, instead of a straightforward reading that other languages like Python would give me.
Maybe I just needed to stick with it a little longer, but it felt like someone learning Python, as an example, could be productive on day one, whereas with clojure I spent days learning and never even got to the point of accepting user input. It was a huge learning curve and I never hit that lightbulb moment where I understand why it was worth the time. i'm sure if I could see it, I'd be more motivated to learn it. I'm also sure this is a personal limitation and not a general problem with LISPs.
There's usually quite a steep learning curve for many with functional programming. I've heard many people say it's just a different mindset but I think it's a bit exaggerated. I'm willing to gamble that Python is a lot easier to teach a child than Lisp, e.g. But I think that's true of very powerful stuff in general. For example, consider FL Studio vs. Reason in the digital audio workstation world, or Houdini/Maya vs. Modo in the VFX world, or Solidworks vs. Rhino3D in CAD/CAM, or oil paints vs. watercolor, etc.
@@darkengine5931 I'm sure you're right. For me, the learning curve was too steep. My interest in learning the language was not strong enough to keep me motivated to get over that initial hump. It was sort of a chicken and egg problem. Without knowing the language, it was difficult for me to understand why it would be worth it to learn the language. Even after many days of learning, I still hadn't gotten to basic input/output and simple stuff that you learn day one in just about every other language course. It was very odd. I've written plenty of Python, and in the past dabbled in C, C++, Go, assembly, Fortran, Pascal, and various flavors of BASIC. None of them were remotely as difficult to grasp as clojure for me. I really struggled to wrap my brain around it.
For Lisps you need to dim the parenthesis so your going by indentation, its similar to python in that way.
Code is data, and data is code requires a collection of insight to understand it fully, but you can probably there by looking at eval written in Lisp, imagine yourself editing the eval function to change the semantics of Lisp, learning about quasiquotes and macros (which are compilers/transpilers), imagining SQL, HTML, C in s-expressions and what the eval functions FOR THOSE would look like. Next imagine creating your own version of defun, cond, let, set, progn/do but would a slight twist your own version of defun would statically check things at compile time, or add logging. Next thing about functions operating in data. Your data is also in S-expressions, but unlike the turing complete code in Lisp eval, it has your data has a fixed shape. Any functions that operate on your data are really other forms of eval. So there is a graduation between data and code and a function and an eval function depending on how many cases you support.
@@aoeu256 great explanation. Thanks
Maybe expressiveness causes also that it is harder to read and reason about what code do? In other words it is easy to write own thoguths to lisp, but importing other people thoughts from lisp code is quite hard despite expressivnes?
It's interesting that Clojure programs eschew small, local identities in favor of large ones, while the Clojure community consists of small, individual identities and eschews large ones.
20:00 yes i think not that many people are actually using lisp at all, it might boom one day thanks to the network effect tho
What do you say about clojure? Now
I would like to learn Lisp in the future but I don't really see any practical use for it. There's also N variations to choose from, and each seems to be doing its own thing, so it's hard to pick one. There's also the weirdness of the tooling around Lisp, which feels very alien to someone who's used to just open an editor and start typing some code.
Hey why not make a program to "unroll" all the macros in a src file so that you can read someone else's lisp in a more standard way? Here's why not: if you can read someone else's code, then you might have to.
macro-expand and family can do that
I believe Lisp will gain in popularity
So is this why Python is so popular? Because it is so hard to do anything serious in a language that features structure for the sake of structure like COBOL?
Python is popular because its for brainlets its the bigmac of the programming world.
Could you do a video on Scheme? Pros, cons, why more ppl are not learning it, and whatever other insights you'd like to share.
Scheme fractured into lots of different languages that weren't compatible, and Scheme itself fractured the Lisp community? Scheme could have made it in the browser as JavaScript, but C/C++ programmers didn't want to learn any new syntax so they ended up creating the unholy evil language that is JavaScript.
@@aoeu256 now we have clojurescript, at least.
Tried lisp before , not having an editor built for lisp , makes it a pain to code in. Many of the function names and syntax are wierd. Simple printing has this wierd function. Why use car cdr when first and last is more intuitive. The cli is painful to work in. How dyu run a program or get thru a screenful of errors? What about documentation to lookup function names etc there's a reason some languages succeed more than others. Some are simply more usable.
(defun _p (a) (format t "~A" a))
Now that print function is only: (_p "What!?!")
Although you are right. Documentation was the most difficult hurdle.
Give DrRacket a whirl. All the problems mentioned are addressed and then some!
Excellent editor, with two windows, one for developing incrementally and one for running.
Complete documentation.
Great plotting and graphics for testing things on the fly.
A shedload of support at many, many levels: community, books, tutorials.
Amazing abilities once you get a bit more familiar.
And that's not the only one! There are so many excellent systems and environments, no one should have to suffer with unmanageable command lines. The one I mentioned above is just the easiest, but you can get stuff in VS Code, in Emacs and all sorts of other environments and language flavours. Clojure gives you pretty neat interop with the whole JVM ecosystem. A teeny bit of research will reward you richly...
I have experienced this curse too. I have coded an e-commerce website myself, and I could do so much more myself than a team of people. Now, the question is, when I want to make a startup out of what I have done, I have to look for people who can take care of the code I have written, add more to it and enhance it, so that, I can look into the business aspects. But, I am not finding anybody who can do it. Software development is a community effort to get successful and even more to maintain it. I totally agree with the
1) commercial aspects of companies looking for people who can be fired, go on maternity leaves, etc. Basically, people who are replaceable. And that, you get with the not so powerful languages.
2) Personal aspect of common lisp giving boost to individualism or the ego.
If common lisp can solve these issues, it can still thrive, I believe.
How to install lisp on windows, and use it inside visual studio?
Install ANSI CLISP from the web and Install it!
Listening on 2x ...
He has so peaceful voice, I'm relaxing now
3.5x
Its not a problem, it is what it is. You dont complain to a wizard about how they write their spellbook. Imagine a world that every wizard now has to write their spell in a particular way
Very much agree on the individualism.
Even eMacs ends up not using lisp tree sitter for eMacs is c not lisp
I love Lisp, but it suffers from the same types of problems that Python does. As it scales, it's just too easy to break things with mismatched types, number of arguments, etc... you have to exercise all code paths at runtime to have confidence in it. Compare that to Rust where if it compiles, it typically just works. If I was starting a company that needed to innovate very quickly, I'd use Lisp. But if I was a company that had mission critical systems that must work, but could take a little more time to get there, I'd likely use Rust.
Mission Critical.. ITA Flight scheduling software is written is Common Lisp.
JPL uses Lisp extensively.
I haven't written one meaningful app in Lisp yet I'm reading Lisp docs like a maniac trying to understand as many things as possible - now that's a curse. I think the quote form and pattern matching on s-expressions are the most powerful features of any lisp. Not many programming languages give you that power, with the exception of Julia, Nim and maybe Rust? It allows you to invent your own notations for the domain you're working in. But other than that...Lisps are just another family of programming languages.
a guy that is familiar with Julia and writing in Rust 'ere.
Java and Python are popular. They allow us to build websites with server based data validation and controllers (as in MVC design pattern). They allow us to work with MS Excel documents, encryption, DTDs, file zipping, emails, etc. I feel that I would find these things harder in Lisp. Otherwise I would be interested in trying Lisp.
What are those things on the walls.
acoustic mufflers. _zero_echo. radio studio quality sound.
Lisp is great, but the barrier to entry is much higher than let's say python. You can get used to parenthesis, but how do you give real business value quick enough? How do you ask millenials and gen-z to invest in a language that is 50yrs old. Software engineers won't understand this, computer scientist's will.
Only people that like Python are those that didn't have to do Fortran. I was so happy that Fortran died, it was awful. Can't stand the format dependancy, this is a blocker for me. I'd rather use Swift than Python.
My submission to the question: I think it's because recursive thinking is not intuitive and it never clicks for most people, which shuts off most of the advantages of Lisp for most people.
Those people should not be programming should they? I have delivered a commercial project almost entirely implemented in Common Lisp with C bits to interface with telco hardware. It is still being used in production without any issues.
> My submission to the question: I think it's because recursive thinking is not intuitive
I'd question that. I would suggest that recursive thinking is *way* more intuitive, we seem to have hypnotized ourselves into thinking the opposite...
Therein the problem lies.
Not enough good quality teachers teaching the basics. A historic problem.
Lisp and its dialects are not popular because it is not people centric (close to english) rather are compiler-parser friendly, which discourages people to get involved in the first place. Maybe more important was speed back then (1960's) but now not so much (clojure is quite fast). Finally OO models the world "better" than Functional which played a big role in adoption. Modern languages that are now succesfull take a hybrid approach (OO + Functional) and combine the best of the 2 major programming paradigms i.e Python, Java, Javascript, C#, Scala,Rust,Swift even C++20.
very interesting video!... now i do not have much time right now... so i can not elaborate on this in any detail... but i think you may find it worthwhile to ponder the following...
1. how powerful an instrument / tool is a stradivari?
2. how important is the quality of a piano played in a lively wild west type saloon?
3. why did will smith have such a hard time selling those superior bone density scanners in the pursuit of happyness?
4. why are there so very few people out there conversing in latin... when the language has clearly so much to offer!?... ( ... i mean... simply pick at random a text written in english and one in latin... the difference in quality and depth of thought should be obvious... )
5. ...
the list goes on... but i will not.... since i gotta run now :-).... but thx again for taking the time to make the video!
Truth seeking developers are forced to either be entrepreneurs or work for startups if they want to work with highly motivated minds and/or maximize productivity.
@@Bizmonger ...so... couple of things :-).... first of all, not knowing anything about you but the fact that you wrote this reply to my comment, i would be perfectly willing to assume you are either an entrepreneur or working for a startup... or both...:-)....
second of all, my intent was really to point out how one could quite easily miss the wood for the trees, especially if there is some sort of vested interest / bias involved... just talk to any classics-scholar and she is sure to explain to you why we should teach more latin / greek etc. in school.... etc. etc..... and there's nothing wrong with that!
... now it has been i while since i watched the video, but if i recall correctly one of the main lines of the argument went something like.... programming in lisp makes you orders of magnitude more productive than programming in a mainstream language like java.... i really can not remember the exact wording / numbers used in this particular clip.... and it doesn't even matter.... for you will find people making ridiculous claims about programming-languages and increased / decreased productivity everywhere and all of the time... and again that's really cool... in the sense that people sell stuff.... so obviously you wanna have promotion.... i guess the reason why i wrote that comment was, because this really did not feel like an attempt to spread the lisp gospel, but rather he seamed to really be puzzled by the fact that people / companies would not immediately want to hop off the java and onto the lisp wagon..... and finish the work that previously took them 150 days to get done in an afternoon... :-).... or whatever.... so basically my intent was to point out that.... well obviously! there is a huge cost involved in making a change like that... ( ... suppose i was to tell you that thinking in japanese instead of english will increase your productivity / mental capabilities :-)... oh lets say... by two orders of magnitude :-).... well.... then... not only are the numbers involved downright outrages...BUT!... that claim also fails completely to take into consideration / account the ENORMOUS investments that will be required in order for you to be able to master the japanese language in the first place!... )
... bottom line... picking up a new language ( programming or otherwise ) is a serious challenge, and for a run of the mill problem the difference in productivity will be nowhere near large enough to justify it...
...hmmm... note sure if i explained myself well enough.... does this make sense?
What is the curse of APL?
Languages which empower the lone hacker are traditionally undervalued due to corporate influence. But the complexity of today's computing problems are forcing corporations to turn to technologies they once tried to overshadow. EDIT :: {side_note, clarification} :: The biggest competition of corporations is lone hackers. Corporations aren't going to fund the technology which disproportionately help their biggest competitor, UNLESS THEY ABSOLUTELY HAVE TO! That is why it has taken so long for these superior technologies to make a comeback!
Right on the money, tragically.
Thanks
What would the massive amount of work taken for a tool like Antler say be equivalent to with the same 'massive amount' of work undertaken on a LISP project? AI prolly.... Lol jk xP
watched on 1.5x. I always have been a guy who wants the most modern languages - Scala, Julia and now Rust. Now interested in what happened to LISP. For mentioned langs there is similar curses - they're all better than their predecesors, but not so many people use them because they're new (self enforcing loop) note: although Rust grows exponentially according to it's github stars history.
Another curse is the curse of Esperanto - it is an artificial auxiliary language created in XIX century to be the language that everybody in the world knows (sort of). As you may realize that is not the case which makes me think that humanity is doomed - we build freaking AI systems that allow for translating one language into another (and also may eventually kill us) "faster" than learn a language that is like 1 to 3 month to learn.
As soon as you give up the ability to handle time, the language becomes a pain in the ass for practical applications generally.
There were Lisp machines and Lisp operating systems with tagged memory.... but x86 and windows just kind of steam rolled because Intel way better at making transistors.
Cool talk. How popular is Common Lisp?
1.25 x please
Man years.
What is the Curse of Lisp? the history of my life.
I tried using Lisp. I tried. I tried. I nearly walked out of my job because of lisp's crazy syntax, etc. Back to Java. LOL
The best languages are never in mainstream :/
speed: 2*
David Blaine of Coding
The worst tool always wins.
It almost seems like you are speaking of an issue with the culture surrounding it, rather than any problems with the language itself.
Yes, I think it sounds like it. Lispers describing the Lisp curse use the power of Lisp as an excuse but other dynamic languages like Perl, Python, or Ruby are similarly powerful. Much like Lisp they make it possible to write a prototype very fast, and solve a lot of problems in small teams. The difference is that they established a culture of sharing code, and from that a culture of thinking the code design through in terms of interface, documenting it, putting it out there, looking for solutions that are already out there.
There is however an underappreciated aspect of this 'curse'. Lisp is so old that in its beginning many users were isolated because they had intermittent network connectivity or none at all, sharing code was not as easy as it is today. When you come into an environment where for every problem you get dozens of libraries that each solve a different 60% of it you stop looking after a while, and miss even libraries that really would work.
Also when network connectivity became more common Lisp has become fragmented into numerous mutually incompatible dialects which again made sharing code hard.
If anything making the syntax computer-centric (easy to parse) rather than human-centric (easy to read) made writing Lisp interpreters really easy enabling the explosion of various dialects.
Average human is too dumb. And, on top of it, culturally we watch mikey mouse and catoons when we are kids. The people who could understand it, they do not. Because the rest of the world is using java.
Clojure is a workaround that. Let's hope we make the shift
You talk a lot without saying much
Comedy!!!
The word "man" is sexist?
*CORRECTION:* "Man hours" is not the "sexist" version of anything. "Man hours" is simply the *correct* way of communicating the notion of work hours in the English language. Nothing more, nothing less.
There is no need to apologize for using English correctly. It's heartbreaking to have to watch an adult human being actually *apologize* for conveying his thoughts because he was browbeaten, brainwashed and shamed into it.
It's Man hours. It's Mankind. It's Salesman. It's Spokesman. It's Chairman. If a cult of misandrists disapproves of that, too bad.
The effort to control and subvert language and how people communicate in all areas of life is not carried out by chance. It is tendentiously carried out by said cult to normalize its pathological misandry and slowly instill their false consciousness in all of us: one that denies human males their human status. One that denies human males their basic human rights. One that pathological misandrists hold.
Do not ever apologize. Defy authoritarian cults pretending to be righteous, virtuous and noble. They are not. They will control your language and will proceed to control you, because power over other is all they seek.
Not sure you're old enough to know what back in the day means.
ok boomer. (sorry had to say it)
We need a LISP plug-in living resident within an office suite (like the one in a common CAD program). Then LISP will take off from problem solvers everywhere.