(are (arguments for (using lisp)) (still valid?))
-
Lisp has been just a bit below the
cut line for me for a long time. I wonder if the arguments about it's awesomeness are still valid in face of today's programming languages. I think it probably doesn't, most currently popular stuff are much more powerful than what we had when Paul Graham wrote that blub thing
-
@sockpuppet7 said in are arguments for using lisp still valid?:
Lisp has been just a bit below the
cut line for me for a long time. I wonder if the arguments about it's awesomeness are still valid in face of today's programming languages. I think it probably doesn't, most currently popular stuff are much more powerful than what we had when Paul Graham wrote that blub thingHomoiconicity (a program can manipulate its own source in a meaningful way) remains interesting, but Lisp hasn't been unique that way for a long time. The key nice thing is being able to make custom control idioms... but you definitely don't need Lisp for that. Such trickery does scare some lesser programmers, but it is both powerful and useful.
Lisp users have been blubbed by readable syntax for decades, and they're still seething like mad that computers ended up optimising hardware for FORTRAN and C instead of their beloved.
-
@dkf said in are arguments for using lisp still valid?:
Homoiconicity (a program can manipulate its own source in a meaningful way)
Translating from academic to English: do you mean metaprogramming?
-
More like the program can generate structures at runtime that it can then execute as code. An eval() without the wildly unsafe "build a string and put it through the interpreter" hilarity.
-
@homoBalkanus said in are arguments for using lisp still valid?:
@dkf said in are arguments for using lisp still valid?:
Homoiconicity (a program can manipulate its own source in a meaningful way)
Translating from academic to English: do you mean metaprogramming?
He probably does. Metaprogramming is very useful, and we have much better ways to do it today. Homoiconicity, on the other hand, is basically unique to Lisp, and for as much as Lisp fanatics proclaim it a powerful feature, it really isn't. It's an ancient relic, a workaround for Lisp being invented before the Chomsky Hierarchy provided the theoretical foundation needed to build good parsers.
So the implementors threw out a fair bit of the syntax that was in the original Lisp papers and dumbed it down to the simplest thing they could come up with, where the entire language is a list of lists that's entirely trivial to parse with some basic recursion. And since it's a LISt Processor, with lists of lists being the language's primary data structure, the symbols ("icons") of the syntax are the same as ("homo") the language's native data structure.
At first glance, this may look useful. But one of the most fundamental rules of language design is, "useful features get reused," and the simple fact is that no language outside of the Lisp family has implemented homoiconicity. (And no, it's not due to Paul Graham's smirking assertion that once you do so, your language necessarily becomes a new dialect of Lisp!) There's a good reason why rich syntaxes and more complicated parsers have taken over the world: punting on parsing means that a lot of the interpreting of the program's meaning which is otherwise done by the compiler now has to be done by the program. (One of the more infamous examples: Lisp has no built-in
if/then/elseconstruct. You need to build your own!)Useful features get reused. Lisp came up with some good ideas, and they are commonplace now. The things that remain unique to Lisp didn't get reused because they are garbage, an evolutionary dead-end from very, very early in the primordial history of computer programming.
-
@Mason_Wheeler that's a great answer, I think you convinced me.
there are things like eval on JavaScript and c# expressions thing that should solve whatever homoiconystuff solves. c# used it to make linq translate c# to SQL
there is nothing like linq on java, so I think it is a useful feature
-
@Watson said in (are (arguments for (using lisp)) (still valid?)):
More like the program can generate structures at runtime that it can then execute as code. An eval() without the wildly unsafe "build a string and put it through the interpreter" hilarity.
A straight eval() also counts for homoiconicity. But you can sort of get close in, say, C by generating code, invoking an in-process tcc or LLVM to make machine code, and then running that. Which is also a great way to horrify many coders.
-
@Mason_Wheeler said in (are (arguments for (using lisp)) (still valid?)):
no language outside of the Lisp family has implemented homoiconicity
Nice writing, but with a basically false premise. 5 GPTs out of 4. (
) There are quite a few homoiconic languages, though most of those don't flaunt the fact. The real key characteristic of a homoiconic language is the fact that it can make entirely new control constructs without changes to the language itself. This goes a bit beyond what you can achieve with lambdas, with, or RAII; I'm talking new basic patterns.
-
@dkf said in (are (arguments for (using lisp)) (still valid?)):
@Mason_Wheeler said in (are (arguments for (using lisp)) (still valid?)):
no language outside of the Lisp family has implemented homoiconicity
Nice writing, but with a basically false premise. 5 GPTs out of 4. (
) There are quite a few homoiconic languages, though most of those don't flaunt the fact.Fair enough. Toby Faire, though, most of them are massively obscure. Of that list, the only ones I've heard of anyone ever actually writing programs in are APL (long ago; it's basically dead today,) Elixir, Prolog, and XSLT — the only non-obscure one of the bunch, but it's been slowly dying for a decade now as JSON takes over the role that XML used to play.
The real key characteristic of a homoiconic language is the fact that it can make entirely new control constructs without changes to the language itself. This goes a bit beyond what you can achieve with lambdas,
with, or RAII; I'm talking new basic patterns.No, that's metaprogramming, which does not require homoiconicity.
-
@Mason_Wheeler you missed @dkf's favorite, TCL was reasonably common in it's time, usually with tk
-
@Mason_Wheeler said in (are (arguments for (using lisp)) (still valid?)):
@dkf said in (are (arguments for (using lisp)) (still valid?)):
@Mason_Wheeler said in (are (arguments for (using lisp)) (still valid?)):
no language outside of the Lisp family has implemented homoiconicity
Nice writing, but with a basically false premise. 5 GPTs out of 4. (
) There are quite a few homoiconic languages, though most of those don't flaunt the fact.Fair enough. Toby Faire, though, most of them are massively obscure. Of that list, the only ones I've heard of anyone ever actually writing programs in are APL (long ago; it's basically dead today,) Elixir, Prolog, and XSLT — the only non-obscure one of the bunch, but it's been slowly dying for a decade now as JSON takes over the role that XML used to play.
Julia is pretty big these days in some circles.
-
@boomzilla Really? What are people using it for?
-
@sockpuppet7 said in (are (arguments for (using lisp)) (still valid?)):
Lisp has been just a bit below the
cut line for me for a long time. I wonder if the arguments about it's awesomeness are still valid in face of today's programming languages. I think it probably doesn't, most currently popular stuff are much more powerful than what we had when Paul Graham wrote that blub thingLisp doesn't have much practical value, and I'd say it never really did, but it does have a learning value, and that won't go away with newer languages, because it lies in it being simple.
Being very minimal—not just in syntax, but also in the constructs—means it's good for learning how abstractions are built from the really fundamental blocks. Where high level languages have many different constructs they make absolutely no connection between, in Lisp almost everything boils down to a bunch of lambdas, and that shows you how all those things are actually just variations of the same theme.
-
@Mason_Wheeler said in (are (arguments for (using lisp)) (still valid?)):
@boomzilla Really? What are people using it for?
Mainly scientific calculations I believe.
-
@Bulb said in (are (arguments for (using lisp)) (still valid?)):
@Mason_Wheeler said in (are (arguments for (using lisp)) (still valid?)):
@boomzilla Really? What are people using it for?
Mainly scientific calculations I believe.
Scientific computing and engineering[edit]
...
Pharmaceuticals and drug development
...
Economics, finance, and political science
-
@sockpuppet7 said in (are (arguments for (using lisp)) (still valid?)):
TCL was reasonably common in it's time, usually with tk
TCL is still common in certain circles. Almost all of the major EDA tools use TCL for their internal scripting language. The scripts aren't compatible, because the functions defined by the tools differ, but they're all TCL.
-
@HardwareGeek said in (are (arguments for (using lisp)) (still valid?)):
The scripts aren't compatible, because the functions defined by the tools differ
Now I’m imagining if
iforwhileall worked incompatibly between every file, because thesimpleanemic language didn’t define them, so every “clever” user does it themselves ad hoc.
-
@HardwareGeek said in (are (arguments for (using lisp)) (still valid?)):
@sockpuppet7 said in (are (arguments for (using lisp)) (still valid?)):
TCL was reasonably common in it's time, usually with tk
TCL is still common in certain circles. Almost all of the major EDA tools use TCL for their internal scripting language. The scripts aren't compatible, because the functions defined by the tools differ, but they're all TCL.
It's also used extensively for console program automation, especially in sysadmin circles. It's an area where doing custom control constructs helps a lot, because you quite frequently need to watch for several different patterns at once and, for some of them only, go back to waiting after twiddling things a bit. (Think optionally supplying a password.) As with all such things, you can do it without custom control, but it is really annoying.
-
@sockpuppet7 said in (are (arguments for (using lisp)) (still valid?)):
there are things like eval on JavaScript and c# expressions thing that should solve whatever homoiconystuff solves. c# used it to make linq translate c# to SQL
there is nothing like linq on java, so I think it is a useful featureI've been flirting with the idea of creating my own Linq provider just because I can. In fact, I have an open tab right now: https://github.com/mattwar/iqtoolkit/blob/master/docs/blog/building-part-05.md (but then again, I have many tabs).
-
@Mason_Wheeler said in (are (arguments for (using lisp)) (still valid?)):
Of that list, the only ones I've heard of anyone ever actually writing programs in are APL (long ago; it's basically dead today,) Elixir, Prolog, and XSLT — the only non-obscure one of the bunch, but it's been slowly dying for a decade now as JSON takes over the role that XML used to play.
I hear about Clojure fairly often. Though I wouldn't call it popular, I wouldn't call it obscure either.
-
@topspin said in (are (arguments for (using lisp)) (still valid?)):
@HardwareGeek said in (are (arguments for (using lisp)) (still valid?)):
The scripts aren't compatible, because the functions defined by the tools differ
Now I’m imagining if
iforwhileall worked incompatibly between every file, because thesimpleanemic language didn’t define them, so every “clever” user does it themselves ad hoc.You can do that. It isn't illegal per se. But you can also dig your eyeballs out with rusty sporks. It isn't recommended.
The things that are truly incompatible between the different EDA tools are effectively a pre-loaded library layer on top of the base language. You'd have that sort of thing when embedding any other language too; the tool makers don't compare notes and have no incentive to make anything interoperable. (It could be worse; they could all be using nasty little custom half-assed languages, just like how games used to be before that sector adopted Lua.)
-
@Bulb said in (are (arguments for (using lisp)) (still valid?)):
Where high level languages have many different constructs they make absolutely no connection between, in Lisp almost everything boils down to a bunch of lambdas, and that shows you how all those things
are actuallycan be implemented as just variations of the same theme if you have no better alternatives.
-
@Zecc said in (are (arguments for (using lisp)) (still valid?)):
@Mason_Wheeler said in (are (arguments for (using lisp)) (still valid?)):
Of that list, the only ones I've heard of anyone ever actually writing programs in are APL (long ago; it's basically dead today,) Elixir, Prolog, and XSLT — the only non-obscure one of the bunch, but it's been slowly dying for a decade now as JSON takes over the role that XML used to play.
I hear about Clojure fairly often. Though I wouldn't call it popular, I wouldn't call it obscure either.
Context. The discussion at that point was about the non-Lisp languages on that list. Clojure is definitely a dialect of Lisp.
-
@Mason_Wheeler Fairy nuff.
-
@boomzilla said in (are (arguments for (using lisp)) (still valid?)):
Julia is pretty big these days in some circles.
And the "Wolfram Language" is fairly common in the circles that use Mathematica.
Nim pops up every now and then, mostly in indie gamedev. That said, it's probably more obscure than Julia or Mathematica.
-
@Mason_Wheeler said in (are (arguments for (using lisp)) (still valid?)):
@Bulb said in (are (arguments for (using lisp)) (still valid?)):
Where high level languages have many different constructs they make absolutely no connection between, in Lisp almost everything boils down to a bunch of lambdas, and that shows you how all those things
are actuallycan be implemented as just variations of the same theme if you have no better alternatives.No. The point is learning concepts, not actually implementing anything. Because most likely you won't be implementing them. It's about learning how they are related, because when you know things are related, you can apply things you know about one to the other.
There are no alternatives. You either pull an abstraction out of a hat, or you build it from the previous abstraction.
Take for example methods methods. Object oriented languages like Java pulled methods out of a hat and said they are totally not functions. So whatever you know about functions may not apply. But Common Lisp added them as functions that switch on the types of arguments. Making them totally functions, so now you know what you know of functions does apply, and what the difference is. And you can apply that knowledge even in Java even though it pulled them out of a hat.
That's the value of learning a simple language like lisp. The fact that for this particular example, Perl is probably a better one, notwithstanding. But Perl is also a simple language, despite being buried under some complex syntactic sugar.
-
@Bulb said in (are (arguments for (using lisp)) (still valid?)):
Object oriented languages like Java pulled methods out of a hat and said they are totally not functions. So whatever you know about functions may not apply.
Virtually everything I knew about functions from C and Pascal applies perfectly well in C# and Delphi. The major difference, the implicit
this/selfparameter, is only ever even relevant at all when you start getting into really low-level stuff. I don't think I ever heard anyone say anything along the lines of "methods are totally not functions." Where did you hear this
-
@Mason_Wheeler Well, yes, it does. Because you know C and you've probably seen how object oriented programming is done in it. But the early proponents of object-oriented languages pretended that it's something completely new and different.
It's not like Lisp is the only language from which you can learn how things fit together. It's rather that knowing more languages, and more of the simple ones in particular, gives you the concepts that you can then apply everywhere.
-
@Bulb said in (are (arguments for (using lisp)) (still valid?)):
@Mason_Wheeler Well, yes, it does. Because you know C and you've probably seen how object oriented programming is done in it. But the early proponents of object-oriented languages pretended that it's something completely new and different.
Dude. "Object-oriented languages" != "Java." Many of "the early proponents of object-oriented languages" were venerable graybeards by the time Sun's contribution to the genre arrived on the scene. The first proto-OO language, Simula, was an ALGOL variant developed in 1962. The follow-up five years later, Simula 67, introduced classes, inheritance, and virtual methods, among other common features we are familiar with today. Encapsulation in the form of
public/protected/privatewas added in a branched version during the 70s, and integrated into the main Simula standard in 1986. C++ and Delphi both took these ideas and implemented them (in very different ways!) on top of C and Pascal, respectively, and were enjoying a great deal of mainstream success at the time Java burst on the scene.OO was nothing new when Java came around, and no one thought it was. I was there, OK? The big selling point that Sun was trying to get everyone all excited about wasn't its object-oriented nature at all; it was WORA, which was also a decades-old concept, albeit one that was a bit more obscure.
It's not like Lisp is the only language from which you can learn how things fit together. It's rather than knowing more languages, and more of the simple ones in particular, gives you the concepts that you can then apply everywhere.
Good simple vs. bad simple. Lisp is definitely on the "simplistic" (bad simple) side of this, which explains its consistent lack of success in the marketplace of ideas about as well as anything else. Things like C# and Python are the type of high-complexity "simple languages" people actually enjoy, and lo and behold, they're massively popular!
-
@Mason_Wheeler said in (are (arguments for (using lisp)) (still valid?)):
I was there, OK?
OK, ringlord.
-
@Bulb said in (are (arguments for (using lisp)) (still valid?)):
Lisp doesn't have much practical value, and I'd say it never really did,
It had a lot of application in early AI work, when everyone thought the secret was in building planners and expert systems instead of massive stochastic word predictors. Turned out those weren't enough, the AI Winter set in, and took most of Lisp with it; a few diehards kept going, but the big bucks from DARPA went elsewhere. (Curiously, those sorts of capabilities are much of what is missing from modern AI.)
-
-
@dkf said in (are (arguments for (using lisp)) (still valid?)):
You'd have that sort of thing when embedding any other language too; the tool makers don't compare notes and have no incentive to make anything interoperable. (It could be worse;
It is worse. Sometimes they're not even compatible with other versions of their own tools. One of the tools I use, like all logic simulators, has a window in which you can examine how variables (signals in the chip simulation) change values over time. You can save the format of the window so you can make a change, run another simulation, and look at the same variables to see what changed, or even create a standard list of "I always want to look at these variables when I'm testing foo". The file that saves the format is a TCL script that adds the variables to the window, zooms to whatever region you were looking at, adds cursors at whatever points you had them, etc.
The tool has two GUIs, a "classic" and a "new and improved" version. The commands are not the same. E.g., one uses "add wave" and the other uses "wave add".
-
@Mason_Wheeler said in (are (arguments for (using lisp)) (still valid?)):
I was there, OK?
"Do not cite the Deep Magic to me, Witch! I was there when it was written."
-
@HardwareGeek said in (are (arguments for (using lisp)) (still valid?)):
@Mason_Wheeler said in (are (arguments for (using lisp)) (still valid?)):
I was there, OK?
"Do not cite the Deep Magic to me, Witch! I was there when it was written."
Fair enough, but the
thread is 
-
@dkf do lions eat belt onions? What about Turkish Delight?
-
@Arantor Are you going to tell the lion "no"?
-
@dkf said in (are (arguments for (using lisp)) (still valid?)):
@Arantor Are you going to tell the lion "no"?
I wasn't going to suggest it find the
thread either though...
-
@Mason_Wheeler said in (are (arguments for (using lisp)) (still valid?)):
@Bulb said in (are (arguments for (using lisp)) (still valid?)):
@Mason_Wheeler Well, yes, it does. Because you know C and you've probably seen how object oriented programming is done in it. But the early proponents of object-oriented languages pretended that it's something completely new and different.
Dude. "Object-oriented languages" != "Java." Many of "the early proponents of object-oriented languages" were venerable graybeards by the time Sun's contribution to the genre arrived on the scene. The first proto-OO language, Simula, was an ALGOL variant developed in 1962. The follow-up five years later, Simula 67, introduced classes, inheritance, and virtual methods, among other common features we are familiar with today. Encapsulation in the form of
public/protected/privatewas added in a branched version during the 70s, and integrated into the main Simula standard in 1986. C++ and Delphi both took these ideas and implemented them (in very different ways!) on top of C and Pascal, respectively, and were enjoying a great deal of mainstream success at the time Java burst on the scene.
What is this blakeyrant about, how is this relevant? Java is actually the language from Simula / C++ family, where methods were just functions with special thisparameter. Or, rather, function pointer.The "methods are absolutely nothing like function" is a trademark of Smalltalk (and maybe Objective C) crowd. And I dare to say that is what @Bulb have run into if he studied on one particular university
Although TBH there was some overlap in 90s (I was there, too) and Sun tried to pander to Smalltalk crowd (but then again, Sun tried to pander to pretty much everyone).
-
@Kamil-Podlesak said in (are (arguments for (using lisp)) (still valid?)):
The "methods are absolutely nothing like function" is a trademark of Smalltalk (and maybe Objective C) crowd.
It's kinda-true in the advanced OO systems; a method invocation logically sends a message to the object and the object decides how it wants to farm that out to the method implementation codes (which typically look just like functions with an extra
thispointer). For C++, apart from the shuffling around ofthis, a method call is literally just a function call (or an indirect call via the vtable, for virtual methods). Java and C# have a bit more complexity because of proxies and delegates, and those sorts of things become much more dominant in Objective C and Simula, where it is possible for objects to define a method to handle unrecognised method invocations. (This sort of thing is very useful for building stuff like webservice clients, where calls on methods get diverted over the network.) The resolution of what to do in response to a method call is really complicated, but can be cached very effectively as people rarely change an instance's class identity from call to call; you don't take a significant performance hit for it in the normal case.I don't know CLOS well enough to comment on what it does. What I know of Perl and Ruby indicates that they're probably doing the sophisticated thing in a way that makes them far slower than they should be. Python is probably also in that situation despite almost none of its users knowing it; Python's internals are nauseating.
-
@dkf said in (are (arguments for (using lisp)) (still valid?)):
Python's internals are nauseating.
How dare you? Pythonistas (I hate that word with a passion) around the world will tell you that it is the next best thing after sliced bread.
Someone once told me that Perl's VM is emulating the inner workings of Forth or Fortran. Not sure what to make of it.
-
@HarryTuttle said in (are (arguments for (using lisp)) (still valid?)):
@dkf said in (are (arguments for (using lisp)) (still valid?)):
Python's internals are nauseating.
How dare you? Pythonistas (I hate that word with a passion) around the world will tell you that it is the next best thing after sliced bread.
Doesn't make it not true. Ever see the infamous "mindblowing Python GIL" video?
-
@HarryTuttle said in (are (arguments for (using lisp)) (still valid?)):
@dkf said in (are (arguments for (using lisp)) (still valid?)):
Python's internals are nauseating.
How dare you? Pythonistas (I hate that word with a passion) around the world will tell you that it is the next best thing after sliced bread.
Someone once told me that Perl's VM is emulating the inner workings of Forth or Fortran. Not sure what to make of it.
Yes but Pythonistas tend not to look under the hood… how the sausage is made may well upset them.
-
@dkf said in (are (arguments for (using lisp)) (still valid?)):
I don't know CLOS well enough to comment on what it does.
The thing that makes CLOS different is that it came up with the concept of multimethods, that is it dynamically dispatches on types of all arguments, not only the designated invocant.
While many statically typed languages do that statically, including C++ and Java, the only other language that I know of that does dynamic dispatch on multiple argument types is Julia.
What I know of Perl and Ruby indicates that they're probably doing the sophisticated thing in a way that makes them far slower than they should be.
As dynamic languages, they need to do by-name lookup for most of these operations. And nobody spent the time writing optimizers for them that was spent on JavaScript.
Python is probably also in that situation despite almost none of its users knowing it; Python's internals are nauseating.
Python somehow managed to make itself particularly difficult to optimize.
@HarryTuttle said in (are (arguments for (using lisp)) (still valid?)):
Someone once told me that Perl's VM is emulating the inner workings of Forth
or Fortran.Well, it's a stack machine, but that's most of them, actually (including JVM and CLR). They started writing a register VM (with ‘infinite’ number of registers by using dynamically sized frames) for Perl 6, called Parrot, but it was replaced by MoarVM for which I couldn't quickly find whether it is stack- or register-based.
-
@Mason_Wheeler said in (are (arguments for (using lisp)) (still valid?)):
Ever see the infamous "mindblowing Python GIL" video?
No, link pls. Youtube suggests a whole lot of videos when I search for "mindblowing Python GIL".
To get back on topic: I have a suspicion that the name LISP is an inside joke, the language is based on a shitload of brackets. Even if not true, it always makes me smile.
-
@Bulb said in (are (arguments for (using lisp)) (still valid?)):
@dkf said in (are (arguments for (using lisp)) (still valid?)):
I don't know CLOS well enough to comment on what it does.
The thing that makes CLOS different is that it came up with the concept of multimethods, that is it dynamically dispatches on types of all arguments, not only the designated invocant.
While many statically typed languages do that statically, including C++ and Java, the only other language that I know of that does dynamic dispatch on multiple argument types is Julia.
I definitely recommend getting acquainted with CLOS.
It used to be so much fun to pull it out in a discussion with a proponent of the "OOP modeling"cultphilosophy and see how the removal of "method belongs to object" melts his brain.
Ah, good times.Btw, to make my point clear: I blame Simula and strongly object to the usual "it's a Java fault", when in fact Java just jumped into already established mainstream bandwagon.
-
@Kamil-Podlesak said in (are (arguments for (using lisp)) (still valid?)):
I blame Simula and strongly object to the usual "it's a Java fault", when in fact Java just jumped into already established mainstream bandwagon.
Smalltalk and Simula are the real culprints, but are you sure the banwagon was mainstream when Java jumped into it? Because I've never encountered Simula except for a silly joke¹ in a programming textbook, and Smalltalk only when OO fundamentalists rhapsodized about it. Even back at the end of last millennium when Java was still hot from the oven.
¹ Silly joking advertisement for Simula: Are you missing a blast furnace? In Simula you simply write
new BlastFurnace()and you have blast furnace.
-
@Bulb said in (are (arguments for (using lisp)) (still valid?)):
Silly joking advertisement for Simula: Are you missing a blast furnace? In Simula you simply write
new BlastFurnace()and you have blast furnace.
How does that make sense or is funny?
-
@topspin Not sure, but it's definitely memorable enough that I remember it 26 years later.
-
@HarryTuttle
https://www.youtube.com/watch?v=Obt-vMVdM8sNote: this is from 2010. It's quite out of date, and I understand some improvements to the GIL were made as a direct result of this presentation. Still, it's a very interesting look at how it used to be implemented and how terribly it all worked.
Julia (programming language) - Wikipedia
