Instead of using a vague term like "power", perhaps the LISP fans should promote the concept "leverage", whereby you can talk about getting a task done with the fewest words of code. Small LISP programs can be incredibly clever, and transformation languages like LISP and FORTH are well known to win every program-shortness contest. However Assembler has always been more powerful in the sense that you can do things in Assembler that you can't do in higher level languages, because there is no direct mapping from a higher level language to many of the special instructions that exist on modern chips. So using "power" is a lamentable word choice. LISP does have problems though, many consider it a "write-only" language which transfers very poorly to other programmers. You can measure transferability of a codebase by assigning a new person to it, giving them a task, and seeing how long it takes, and how much is broken in the process. LISP is avoided by most large companies for this reason alone. Leverage and other factors are heavily outweighed in overall cost to the organization by the difficulty of transferring a code base among people.
I like "power." It's evocative, and it maps to the feeling you get with a good language - when your intent is made manifest with little effort, you feel powerful (and _are_ powerful).
I get your point but it seems unnecessary to optimize verbage like "power" or "leverage" if there's a popular view that the language isn't easily readable. If you can't convince people the language is readable it seems like it isn't going to get use outside of hardcore fans or trivial applications anyway.
I came in here hoping for more information on developing games in Lisp/Scheme. I liked the recommendation for implementing old games. I might take a swing at the original StarCraft (just for kicks).
I've been poking around trying to sort out how to bind Chicken Scheme [0] to the Godot [1] C API.
The idea is to work in Godot using C files compiled by Chicken. This should work, in theory. The engine can handle the important timing stuff (mentioned in the article), and Scheme can be used for actual game-logic and algorithms.
I know a Scheme binding for Godot exists, but it hasn't been updated in quite a while.
> I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub.
> As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down.
> But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages.
Other posters have given serious answers. I would add my own: its an excuse for a language superiority complex. It assumes that everyone using "less powerful" languages do so because they just don't understand "more powerful" languages while excluding the idea that they might just find that language X is the right fit for their domain. (e.g.: asm is probably more "powerful" than python, but I'd rather do string manipulation in the latter)
It comes from a mistaken argument in an essay by Paul Graham. Others have explained the idea a bit. I'm going to explain why I think it is mistaken.
The essay says that Lisp is at the top of the power curve. Lisp programmers, looking at Haskell, are sure that they are looking down. They say, "How can you get anything done in Haskell? It doesn't even have (Lisp-style) macros."
But the Haskell types (pun intended) are also sure that they're at the top of the power curve. When they look at Lisp, they're also sure that they are looking down. "How can you get anything done in Lisp? It doesn't even have a decent (Hindley-Milner) type system."
Here you have proponents of two different languages, both sure that they're at the top of the power curve, and both sure that the other language is beneath their language. Something's wrong here...
What's wrong is the idea that languages can be placed on a one-dimensional axis labeled "power". That idea is mistaken.
To see why, think about hardware. We know what we mean by power in hardware - MIPS. But then someone says, "Well, we've got that floating point code, so we have to care about FLOPS. And then there's that data set that won't fit in cache, so we have to care about main memory bandwidth... except that sometimes you can trade off MIPS for larger cache size...." Now you've got at least four axes - MIPS, FLOPS, memory bandwidth, and cache size.
Then some psychopath comes into the room and says, "What I mean by 'power' in hardware is battery life." That is, their definition of power is something like 1/watts, which, for battery-operated hardware, is not as clearly unreasonable as the physical units might lead you to think.
Back to software. "Power"? Power for what? For writing programs. OK, which programs? For "general programming"? But I've never written a general program in my life. I've written a bunch of specific ones, though. So what I actually care about is power for writing this program. For this program, I have to ask what makes it hard to write the program, and pick the language that goes the furthest toward solving those problems for me.
High performance computing (or, as the article says, games)? I might need something that gives me control of memory layout. I don't want to try to deal with that in either Lisp or Haskell. Real-time computing? Let's skip garbage collection, thanks. (Yes, I know, it can be done. It sure doesn't make the problem of deterministic response time easier, though.) Let's also skip recursion and laziness.
On the other hand: Anytime we can, let's skip manual memory management.
Pick the language based on the characteristics of the problem. Don't blindly pick any language because it's "the most powerful".
Except for the the Clojure branch of the family tree.
Eg: there was this vaguely clojurey statically typed non-GC language, being targeted for games, presented at a recent Clojure conf: https://github.com/carp-lang/Carp
Honestly, I can't do anything but put blame for this on people like Paul Graham.
Some people come to Lisp and expect to discover a magic wand to abolish all blub languages that was prophecised by the legendary almighty Lisp Prophet, and they rush out to seek it.
Then they realize that Lisp is just another programming language equivalent to all others by means of Turing completeness, with particular features, strengths and weaknesses they feel cheated and disenchanted, and go wing our their frustrations by means of articles like that.
Which is directly why articles like Baggers' happen.
The question is: why do people actually consider Lisp to be the Holy Grail By Which All ALGOL-Like Languages Must/Shall/Will Die? And the answer that instantly comes to my mind is all the unfair PR people like Graham give it. Calling Lisp a magical all-fixing wand is all fun and games until someone actually believes in it (who wouldn't believe The Y-Combinator Guy? after all), and then discovers that the reality doesn't really look that straightforward, and writing Lisp doesn't suddenly mean that you get to do less work than you'd otherwise do. As pointed out in Shinmera's response, https://reader.tymoon.eu/article/370 :
I believe Lisp allows me to be quicker about developing these tools than other languages, but making an actual game would be even quicker if I didn't have to make most of these tools in the first place.
The lisp community has a nice history about not being a very welcoming place, with a lot of people looking up to the nice attitude of people like Erik Naggum.
GOAL wasn't just scripting, it was the main language for the engine. In the one example I've ever seen of GOAL code, you can clearly see inline ASM for instance.
Interestingly Halo used Lisp for scripting, and that rarely comes up.
That isn't really Lisp -- no cons, no garbage collection, no dynamic typing. It's closer to C than it is to Lisp, at least in terms of language semantics.
I haven't programmed in Lisp yet, but I love the idea: it seems very directly inspired by lambda calculus. However, I tend to think of it as the opposite pole of expressiveness from ASM. Lisp excels at abstraction, but is not good at bit-twiddling, or (from my limited perspective) interacting with anything that isn't Lisp.
That said, I know that my perspective is incomplete at best, so I would listen very attentively to anyone who might disagree with it.
I made a Lisp dialect called TXR Lisp. I gave it a nice, ergonomic FFI. I took the MSDN "Your First Windows Program" which is a C sample, and translated it expression for expression:
Lisp dialects tend to be close-to-the-metal languages whose workings can be explained using bits and bytes (even if such an explanation is not always accurate due to issues of optimization and whatnot).
When I'm debugging Lisp, I think of word-sized arguments on a stack, and pointers and all those same kinds of things like when debugging a C program.
Historic Lisp implementations were bootstrapped from assembly code. Lisp primitives were written as a library of machine language routines. With that, plus I/O and memory management, you just need an eval routine for interesting things to start happening. The car and cdr terms are inspired by machine instructions, and they help keep us grounded in reality.
This was, hands-down, the single best article I have ever read about Lisp, after three decades of reading all kinds of stuff. It so far outclasses anything Paul Graham ever wrote on the subject that he (Paul) would best never mention Lisp ever again.
If only it were not ("just") a reply to a shitpost, I would print it out (yes, some of us old-timers still do that) and hang it on the wall, so I can point to it when somebody mentions Lisp and say "read that first -- if you disagree, then take it up with him, and don't mention Lisp to me ever again".
What? I don't think the majority of people interested in lisp are going into work looking down their noses at people. They're probably mostly people who like to try different tools and learn new things. I don't use lisp but I loved reading through PG's ANSI Common Lisp book because it really challenged me to think about programming and problem solving in a way I never had before. I think I write better code because I did learn lisp.
This sort of "lispers are hipsters", "haskellers are hipsters" comments are very destructive to our community yet I see them in every single lisp thread. Very unfortunate. I only wish this will stop one day.
[+] [-] magicmouse|7 years ago|reply
[+] [-] nradov|7 years ago|reply
(~R∊R∘.×R)/R←1↓ιR
[+] [-] warbaker|7 years ago|reply
[+] [-] tdb7893|7 years ago|reply
[+] [-] all2|7 years ago|reply
I've been poking around trying to sort out how to bind Chicken Scheme [0] to the Godot [1] C API.
The idea is to work in Godot using C files compiled by Chicken. This should work, in theory. The engine can handle the important timing stuff (mentioned in the article), and Scheme can be used for actual game-logic and algorithms.
I know a Scheme binding for Godot exists, but it hasn't been updated in quite a while.
[0] https://www.call-cc.org/ [1] https://godotengine.org/
[+] [-] FigBug|7 years ago|reply
What does 'blub' mean?
[+] [-] namelosw|7 years ago|reply
> I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub.
> As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down.
> But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages.
[+] [-] peterashford|7 years ago|reply
[+] [-] AnimalMuppet|7 years ago|reply
The essay says that Lisp is at the top of the power curve. Lisp programmers, looking at Haskell, are sure that they are looking down. They say, "How can you get anything done in Haskell? It doesn't even have (Lisp-style) macros."
But the Haskell types (pun intended) are also sure that they're at the top of the power curve. When they look at Lisp, they're also sure that they are looking down. "How can you get anything done in Lisp? It doesn't even have a decent (Hindley-Milner) type system."
Here you have proponents of two different languages, both sure that they're at the top of the power curve, and both sure that the other language is beneath their language. Something's wrong here...
What's wrong is the idea that languages can be placed on a one-dimensional axis labeled "power". That idea is mistaken.
To see why, think about hardware. We know what we mean by power in hardware - MIPS. But then someone says, "Well, we've got that floating point code, so we have to care about FLOPS. And then there's that data set that won't fit in cache, so we have to care about main memory bandwidth... except that sometimes you can trade off MIPS for larger cache size...." Now you've got at least four axes - MIPS, FLOPS, memory bandwidth, and cache size.
Then some psychopath comes into the room and says, "What I mean by 'power' in hardware is battery life." That is, their definition of power is something like 1/watts, which, for battery-operated hardware, is not as clearly unreasonable as the physical units might lead you to think.
Back to software. "Power"? Power for what? For writing programs. OK, which programs? For "general programming"? But I've never written a general program in my life. I've written a bunch of specific ones, though. So what I actually care about is power for writing this program. For this program, I have to ask what makes it hard to write the program, and pick the language that goes the furthest toward solving those problems for me.
High performance computing (or, as the article says, games)? I might need something that gives me control of memory layout. I don't want to try to deal with that in either Lisp or Haskell. Real-time computing? Let's skip garbage collection, thanks. (Yes, I know, it can be done. It sure doesn't make the problem of deterministic response time easier, though.) Let's also skip recursion and laziness.
On the other hand: Anytime we can, let's skip manual memory management.
Pick the language based on the characteristics of the problem. Don't blindly pick any language because it's "the most powerful".
[+] [-] DubiousPusher|7 years ago|reply
[+] [-] Semiapies|7 years ago|reply
[+] [-] fulafel|7 years ago|reply
Eg: there was this vaguely clojurey statically typed non-GC language, being targeted for games, presented at a recent Clojure conf: https://github.com/carp-lang/Carp
[+] [-] phoe-krk|7 years ago|reply
Some people come to Lisp and expect to discover a magic wand to abolish all blub languages that was prophecised by the legendary almighty Lisp Prophet, and they rush out to seek it.
Then they realize that Lisp is just another programming language equivalent to all others by means of Turing completeness, with particular features, strengths and weaknesses they feel cheated and disenchanted, and go wing our their frustrations by means of articles like that.
Which is directly why articles like Baggers' happen.
The question is: why do people actually consider Lisp to be the Holy Grail By Which All ALGOL-Like Languages Must/Shall/Will Die? And the answer that instantly comes to my mind is all the unfair PR people like Graham give it. Calling Lisp a magical all-fixing wand is all fun and games until someone actually believes in it (who wouldn't believe The Y-Combinator Guy? after all), and then discovers that the reality doesn't really look that straightforward, and writing Lisp doesn't suddenly mean that you get to do less work than you'd otherwise do. As pointed out in Shinmera's response, https://reader.tymoon.eu/article/370 :
I believe Lisp allows me to be quicker about developing these tools than other languages, but making an actual game would be even quicker if I didn't have to make most of these tools in the first place.
[+] [-] bjoli|7 years ago|reply
Things have gotten a lot better though.
[+] [-] alyssaphacker|7 years ago|reply
[+] [-] MrEldritch|7 years ago|reply
[+] [-] petermcneeley|7 years ago|reply
[+] [-] monocasa|7 years ago|reply
Interestingly Halo used Lisp for scripting, and that rarely comes up.
[+] [-] kayamon|7 years ago|reply
[+] [-] sethrin|7 years ago|reply
That said, I know that my perspective is incomplete at best, so I would listen very attentively to anyone who might disagree with it.
[+] [-] kazinator|7 years ago|reply
https://rosettacode.org/wiki/Window_creation#Win32.2FWin64
The C original is here:
https://docs.microsoft.com/en-us/windows/desktop/learnwin32/...
The Lisp program recreates all of the needed C structure definitions, and binds to the needed functions from user32.dll and other libraries.
Here is another TXR Lisp program which parses TCP/IP packets right out of the "pcap" style output from tcpdump:
https://unix.stackexchange.com/a/379759/16369
Lisp dialects tend to be close-to-the-metal languages whose workings can be explained using bits and bytes (even if such an explanation is not always accurate due to issues of optimization and whatnot).
When I'm debugging Lisp, I think of word-sized arguments on a stack, and pointers and all those same kinds of things like when debugging a C program.
Historic Lisp implementations were bootstrapped from assembly code. Lisp primitives were written as a library of machine language routines. With that, plus I/O and memory management, you just need an eval routine for interesting things to start happening. The car and cdr terms are inspired by machine instructions, and they help keep us grounded in reality.
[+] [-] mepian|7 years ago|reply
The FFI of Common Lisp is on par with more mainstream languages like Python.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] xupybd|7 years ago|reply
Sounds like they make niche games I'd love to try some out. Any recommendations?
[+] [-] etiam|7 years ago|reply
I'm not up to date on actual games from him.
He's pretty active writing public source code https://github.com/cbaggers
Sometimes publishes cool video tutorials live coding 3D graphics. https://www.youtube.com/playlist?list=PL2VAYZE_4wRKKr5pJzfYD...
[+] [-] failrate|7 years ago|reply
[+] [-] ncmncm|7 years ago|reply
If only it were not ("just") a reply to a shitpost, I would print it out (yes, some of us old-timers still do that) and hang it on the wall, so I can point to it when somebody mentions Lisp and say "read that first -- if you disagree, then take it up with him, and don't mention Lisp to me ever again".
My Hat Is Off To You, sir.
[+] [-] 21|7 years ago|reply
[deleted]
[+] [-] dang|7 years ago|reply
[+] [-] DubiousPusher|7 years ago|reply
https://www.amazon.com/exec/obidos/ASIN/0133708756
[+] [-] gnulinux|7 years ago|reply