6 ms·

PG is coming from the "flip this app to yahoo" perspective, not the "i will own this shit forever and have to hire a dozen outsiders to maintain it" one. Peopl

PG is coming from the "flip this app to yahoo" perspective, not the "i will own this shit forever and have to hire a dozen outsiders to maintain it" one. People in those spaces standardized on imperative structure, classes, stronger typing, etc for good reasons. HETERO-iconicity, boilerplate, structure... helps the new hires find their bearings in the codebase. Being able to catch a type or signature mismatch at compile-time instead of run-time is another HUGE advantage when extending or re-factoring (i.e. typescript vs javascript). Aaaron Schwartz was no blub-brain, but quickly realized that pg's kool-aid was the wrong flavor for his party, so pivoted from lisp to python in the early reddit days. I occasionally come back to lisp code i wrote years ago, and it takes about twice as long to regain my bearings there than in any other language--even assembly!

refulgentis 2y ago
That's only because True Lisp hasn't been tried yet </s>
anonzzzies 2y ago
> and it takes about twice as long to regain my bearings there than in any other language Is that CL, Clojure, a std Scheme or something? I really don’t have any issues jumping in either of these 3 even after a decade or more, but maybe if something obscure is used? And I wonder about the difference in naming and commenting as well then.
- hello_computer 2y ago
  A lot of it boils down to types--the difference between a labeled and an unlabeled cadaver. One has a little tag next to the vein with "blood, to heart" written on it, the other is just an empty tube. What was in the tube? Which way did it flow? I'll have to probe it with the REPL to find out. While with rust, or go, or even c, i have a type instead of another list, i can browse to its definition in a click--a lookup instead of an investigation. The cultists are all crying, "you suck at naming! you suck at comments!" And maybe I do! But those 12 people who will have to maintain it are going to suck even more. That's where a more "blub-like" language shines. It is enforcing a standard. And the cultists cry again, "i'm so smart i don't need blub to hold my hands!" Ok, if you say so... but where is your Minecraft (blub)? where is your Excel (blub)? where is your Facebook or your Google (blub)? maybe we can just accept that lisp is nice in some places, but not so nice for others?
  - anonzzzies 2y ago
    So you mean to say; it takes 2x as long to get into not statically typed lang code? Asm? I mean sure it’s typed but… And we are pro static types, it’s just easier to add them after I am done experimenting. Not upfront. And we do via various (backward compat) custom CL constructs and provers.
    - hello_computer 2y ago
      types are just an example. structure (modules/classes/keywords/constructs) is also a big win for organization and assisted code navigation. even with dynamic types, i find it far easier to grep a python codebase than a lisp one. is it code? is it data? python syntax makes it fairly clear.
      - anonzzzies 2y ago
        Fair enough; can’t say I have this experience but that’s fine; I am not religious. Although I would say, unless you are doing a lot of things with macros (hint; you shouldn’t and where you do, it should be clearly indicated; Ruby suffers from this as well when reading code imho) otherwise it seems very strange the code/data barrier isn’t immediately clear. But maybe I don’t hang as much on syntax as others do (we our own k3 to lisp to CUDA for some things and I don’t find it different/more difficult to read).
  - g00z 2y ago
    I'm curious if these problems are more about flexibility. Because I find with any well designed and flexible program in a statically typed language, you end up with the same "tube of something" as you have in your dynamic language examples. Take any large generic framework in rust, the types are extremely generic, dispatching on more generic traits. It's hardly a tag that says: "blood, to heart" unless it is highly coupled and working in one area.
    - hello_computer 2y ago
      > generic framework Yet at some point, the template is instantiated--in the text!--and you can fill-in-the-blank by reading instead of having to do a runtime probe. For large systems that have a lot of preconditions, the "runtime probe" approach can be a thick fat time-waster (i.e. caressing the program into a state where something is even in the tube).
ungamedplayer 2y ago
How did python help, I always just assumed it was chosen to allow the hiring of more programmers, not that it provides any technical benefit above lisp.
- hello_computer 2y ago
  The man is dead, yet his words live: http://www.aaronsw.com/weblog/rewritingreddit http://www.aaronsw.com/weblog/rewritingreddit "The others knew Lisp (they wrote their whole site in it) and they knew Python (they rewrote their whole site in it) and yet they decided liked Python better for this project. The Python version had less code that ran faster and was far easier to read and maintain."
  - BeautifulSynch 2y ago
    Something was bugging me about this article the first time I read it, so I made a mind map. Turns out, not once does the author actually give a reason why Python was better than Lisp for Reddit. The only references to that connection at all were claims that some “X” (all among the set that are oft-refuted by Lisp programmers) wasn’t the reason! It reads more like a PR justification (“oh, there’s not much difference really, we even asked unspecified engineers who agreed with the change, and our code is working better and better!”) than an actual explanation.
    - hello_computer 2y ago
      "less code that ran faster" seems fairly clear-cut to me. Why would he lie about that?
      - BeautifulSynch 2y ago
        As I understand his claims, “less code that ran faster” was after switching from existing web frameworks to web.py, a from-scratch web framework he wrote himself to ‘do the right thing, simply’ (as all the best frameworks do). The decision to write web.py instead of web.lisp was not elaborated on, however. As mentioned above, the closest point I see to him discussing that decision is saying that ‘Python uses objects to make frameworks somewhat like the syntactic constructs Lisp allows you to make’, ie ‘you can do the same things as Lisp less easily in Python, so that’s not an advantage of Lisp’. Which is both incoherent as a refutation of the referenced reason to keep Lisp, and not a reason for the change to Python.
classified 2y ago
> HETERO-iconicity, boilerplate, structure... helps the new hires find their bearings in the codebase. But only in theory. The shit that I keep seeing of incomprehensible spaghetti code in C and C++ disproves that theory on a daily basis.
- iLemming 2y ago
  Yup. I've seen programmers whose first language was Clojure. Later, when they tried to get into Java or Typescript, their first reaction was almost always, "WTF is all this shit? How do people even look at this stuff all day long? How do you make sense here, why everything feels so needlessly tangled?"
  - classified 2y ago
    Languages enforcing a questionable structure or boatloads of boilerplate are one thing, but it's also that writing comprehensible code is a skill in and of itself. If you don't have that (yet), no language on earth is going to save you.
    - iLemming 2y ago
      True. Writing beautiful code that is easy to reason about is a skill. Just like writing prose, it comes with experience. One can try multiple programming languages and still suck at it; It is not language-dependent art. I've seen horrible code in languages I know well, and I've seen beautiful code in PLs I have no idea how to write idiomatic structures in.
Jach 2y ago
If you only learned Common Lisp from skimming PG's On Lisp, it's forgivable that you never really learned it. PG doesn't like OOP, but like, approximately all the big Lisp systems I've seen make use of it, and it helps with understanding quite a bit. Same thing with using more namespaces (defpackage) instead of throwing everything into cl-user. One reason I prefer CL to Clojure or Scheme is indeed the compile-time warnings about things like type mismatches. It's a trivial problem (it didn't really bother me when I did lots of Python) but it's nice to not worry about it. Similarly, I can do a lot of code navigation with vim, I don't need to learn emacs though it can do the same navigation, as can vs code or whatever. If I'm coming back to a piece of code, or investigating something new for the first time, it's rather easy to get my bearings, more so than a C program. I hacked my PDF viewer (atril) recently to show estimated time left while auto-scrolling a doc, it took me longer than I bet it would have if it was written in Lisp. Typing being optional is not a problem. Like, if I'm looking at some function, and for some reason it's not clear what type of argument it's expecting, with one command I can pull up a cross-reference of other code that calls that function, and jump to it, and jump to the definition of the argument. If it's an object, I can jump to the definition of the class. This isn't really any more burdensome than jumping to the class in the first step, especially because in static langs I'll occasionally need to look at uses in context via cross-references anyway. I don't get your dismissal of runtime probes. In large static systems, runtime probing is necessary for me to orient myself, the types don't really help. "How does the execution thread even get here?" is easily answered by sticking a break point there and running the thing, then you can inspect the stack. Common Lisp also has a very nifty "trace" function built-in, with a keyboard stroke I now get output every time the function is called along with what its arguments were and what its return values were. I can do this for any function, even built-ins, no instrumentation setup necessary or modifying the code or stopping/restarting the program. The full interactivity also means I can just jump to the definition even in some library-of-a-library code and if it pleases me rewrite it to add some prints or other info or just fix a bug and move that redefinition to my project. It's much easier for me to investigate a large Lisp system than a large Java system even though I've probably had more experience with the latter. Even grepping stuff is rather simple because of naming conventions.
- hello_computer 2y ago
BeautifulSynch 2y ago
That’s not a matter of the language; and I don’t mean that in the “No True Scotsman” way either. Lisp definitely allows you to write code that is very easy to come back to and understand. I’ve written code like that, and I’ve seen code like that in eg certain sections of the SBCL internals, among many other projects. However, there’s a reason we don’t write all our code in Python or Assembly. The fundamental semantic restrictions of one and the simple functionality of the other are both traded off against horrible scaling relative to a technical project’s complexity and scope. If you write a project with complex stages/components in those kinds of languages (or mimic their styles in Lisp code, for that matter), either you have to split those components into parts that don’t make sense separately (making the code base significantly more complicated than eg an equivalent Lisp codebase), or you have to write extremely long and convoluted programs to accomplish conceptually simple functions (making the code base significantly more complicated than eg an equivalent Lisp codebase). Similarly, if you use the Python or Assembly coding paradigms for large projects, you quickly get lost in a sea of individually simple-seeming code segments, unable to grok the connections between said segments just because of how many things need to be kept track of. In contrast, for Lisp languages: A) The default style used by Lisp programmers is highly functional, using many higher-order functions, using macros that solve their problem-domains without explicitly exposing the code doing the solving (objects also fall into this general role, btw, which is apropos given the Common Lisp Object System was defined purely with macros), and clearly delineating code / systems with mutating effects. While this style is admittedly harder to grok than Python/Assembly for simple cases, it has almost no reduction in reading-complexity as code scale/complexity increases. Complexity gets naturally encapsulated and automated by functions/macros/objects (as opposed to either a restricted subset of those or simply the developer’s own head, which are the 2 approaches most other languages offer for complexity management) (algebraic type systems are a very cool exception to the prior note, but a pervasive object system (like CLOS) paired with macros allows you to make a type system (like Coalton) without feature/ergonomics loss). B) Interactive development and ergonomic DSL creation are objective wins for complex or large programs; the former significantly reduces iteration time for both cases, while the latter makes it easy to just write code once that addresses the complexity/scale of the domain and then never deal with that complexity again (or at least not with the full complexity, even if you don’t understand the domain well enough to obviate the irrelevant complexity entirely in your DSL). Sure, hot-reloading in a few other languages gives us most of the former (although things like CL conditions, debugging REPL-layers, access to object contents & stack-frame inputs (only addressed by some debuggers, and only in a restricted way), and some other features still lack equivalents) and other languages generally use objects alone to address (most instances, though not all, of) the latter (rather than Lisp’s mix of macros/objects/higher-order-functions) (we’re ignoring the text-templating macros in languages like C++ because everyone agrees they’re more trouble than they’re worth). But Lisp is still by far the most featureful and ergonomic offering of both of these facilities.
BaculumMeumEst 2y ago
Based comment and it's sad that common sense gets pushed to the bottom of the thread. You are dead on.

refulgentis 2y ago

That's only because True Lisp hasn't been tried yet </s>

anonzzzies 2y ago

> and it takes about twice as long to regain my bearings there than in any other language Is that CL, Clojure, a std Scheme or something? I really don’t have any issues jumping in either of these 3 even after a decade or more, but maybe if something obscure is used? And I wonder about the difference in naming and commenting as well then.

hello_computer 2y ago
A lot of it boils down to types--the difference between a labeled and an unlabeled cadaver. One has a little tag next to the vein with "blood, to heart" written on it, the other is just an empty tube. What was in the tube? Which way did it flow? I'll have to probe it with the REPL to find out. While with rust, or go, or even c, i have a type instead of another list, i can browse to its definition in a click--a lookup instead of an investigation. The cultists are all crying, "you suck at naming! you suck at comments!" And maybe I do! But those 12 people who will have to maintain it are going to suck even more. That's where a more "blub-like" language shines. It is enforcing a standard. And the cultists cry again, "i'm so smart i don't need blub to hold my hands!" Ok, if you say so... but where is your Minecraft (blub)? where is your Excel (blub)? where is your Facebook or your Google (blub)? maybe we can just accept that lisp is nice in some places, but not so nice for others?
- anonzzzies 2y ago
  So you mean to say; it takes 2x as long to get into not statically typed lang code? Asm? I mean sure it’s typed but… And we are pro static types, it’s just easier to add them after I am done experimenting. Not upfront. And we do via various (backward compat) custom CL constructs and provers.
  - hello_computer 2y ago
    types are just an example. structure (modules/classes/keywords/constructs) is also a big win for organization and assisted code navigation. even with dynamic types, i find it far easier to grep a python codebase than a lisp one. is it code? is it data? python syntax makes it fairly clear.
    - anonzzzies 2y ago
      Fair enough; can’t say I have this experience but that’s fine; I am not religious. Although I would say, unless you are doing a lot of things with macros (hint; you shouldn’t and where you do, it should be clearly indicated; Ruby suffers from this as well when reading code imho) otherwise it seems very strange the code/data barrier isn’t immediately clear. But maybe I don’t hang as much on syntax as others do (we our own k3 to lisp to CUDA for some things and I don’t find it different/more difficult to read).
- g00z 2y ago
  I'm curious if these problems are more about flexibility. Because I find with any well designed and flexible program in a statically typed language, you end up with the same "tube of something" as you have in your dynamic language examples. Take any large generic framework in rust, the types are extremely generic, dispatching on more generic traits. It's hardly a tag that says: "blood, to heart" unless it is highly coupled and working in one area.
  - hello_computer 2y ago
    > generic framework Yet at some point, the template is instantiated--in the text!--and you can fill-in-the-blank by reading instead of having to do a runtime probe. For large systems that have a lot of preconditions, the "runtime probe" approach can be a thick fat time-waster (i.e. caressing the program into a state where something is even in the tube).

ungamedplayer 2y ago

How did python help, I always just assumed it was chosen to allow the hiring of more programmers, not that it provides any technical benefit above lisp.

hello_computer 2y ago
The man is dead, yet his words live: http://www.aaronsw.com/weblog/rewritingreddit http://www.aaronsw.com/weblog/rewritingreddit "The others knew Lisp (they wrote their whole site in it) and they knew Python (they rewrote their whole site in it) and yet they decided liked Python better for this project. The Python version had less code that ran faster and was far easier to read and maintain."
- BeautifulSynch 2y ago
  Something was bugging me about this article the first time I read it, so I made a mind map. Turns out, not once does the author actually give a reason why Python was better than Lisp for Reddit. The only references to that connection at all were claims that some “X” (all among the set that are oft-refuted by Lisp programmers) wasn’t the reason! It reads more like a PR justification (“oh, there’s not much difference really, we even asked unspecified engineers who agreed with the change, and our code is working better and better!”) than an actual explanation.
  - hello_computer 2y ago
    "less code that ran faster" seems fairly clear-cut to me. Why would he lie about that?
    - BeautifulSynch 2y ago
      As I understand his claims, “less code that ran faster” was after switching from existing web frameworks to web.py, a from-scratch web framework he wrote himself to ‘do the right thing, simply’ (as all the best frameworks do). The decision to write web.py instead of web.lisp was not elaborated on, however. As mentioned above, the closest point I see to him discussing that decision is saying that ‘Python uses objects to make frameworks somewhat like the syntactic constructs Lisp allows you to make’, ie ‘you can do the same things as Lisp less easily in Python, so that’s not an advantage of Lisp’. Which is both incoherent as a refutation of the referenced reason to keep Lisp, and not a reason for the change to Python.

classified 2y ago

> HETERO-iconicity, boilerplate, structure... helps the new hires find their bearings in the codebase. But only in theory. The shit that I keep seeing of incomprehensible spaghetti code in C and C++ disproves that theory on a daily basis.

iLemming 2y ago
Yup. I've seen programmers whose first language was Clojure. Later, when they tried to get into Java or Typescript, their first reaction was almost always, "WTF is all this shit? How do people even look at this stuff all day long? How do you make sense here, why everything feels so needlessly tangled?"
- classified 2y ago
  Languages enforcing a questionable structure or boatloads of boilerplate are one thing, but it's also that writing comprehensible code is a skill in and of itself. If you don't have that (yet), no language on earth is going to save you.
  - iLemming 2y ago
    True. Writing beautiful code that is easy to reason about is a skill. Just like writing prose, it comes with experience. One can try multiple programming languages and still suck at it; It is not language-dependent art. I've seen horrible code in languages I know well, and I've seen beautiful code in PLs I have no idea how to write idiomatic structures in.

Jach 2y ago

If you only learned Common Lisp from skimming PG's On Lisp, it's forgivable that you never really learned it. PG doesn't like OOP, but like, approximately all the big Lisp systems I've seen make use of it, and it helps with understanding quite a bit. Same thing with using more namespaces (defpackage) instead of throwing everything into cl-user. One reason I prefer CL to Clojure or Scheme is indeed the compile-time warnings about things like type mismatches. It's a trivial problem (it didn't really bother me when I did lots of Python) but it's nice to not worry about it. Similarly, I can do a lot of code navigation with vim, I don't need to learn emacs though it can do the same navigation, as can vs code or whatever. If I'm coming back to a piece of code, or investigating something new for the first time, it's rather easy to get my bearings, more so than a C program. I hacked my PDF viewer (atril) recently to show estimated time left while auto-scrolling a doc, it took me longer than I bet it would have if it was written in Lisp. Typing being optional is not a problem. Like, if I'm looking at some function, and for some reason it's not clear what type of argument it's expecting, with one command I can pull up a cross-reference of other code that calls that function, and jump to it, and jump to the definition of the argument. If it's an object, I can jump to the definition of the class. This isn't really any more burdensome than jumping to the class in the first step, especially because in static langs I'll occasionally need to look at uses in context via cross-references anyway. I don't get your dismissal of runtime probes. In large static systems, runtime probing is necessary for me to orient myself, the types don't really help. "How does the execution thread even get here?" is easily answered by sticking a break point there and running the thing, then you can inspect the stack. Common Lisp also has a very nifty "trace" function built-in, with a keyboard stroke I now get output every time the function is called along with what its arguments were and what its return values were. I can do this for any function, even built-ins, no instrumentation setup necessary or modifying the code or stopping/restarting the program. The full interactivity also means I can just jump to the definition even in some library-of-a-library code and if it pleases me rewrite it to add some prints or other info or just fix a bug and move that redefinition to my project. It's much easier for me to investigate a large Lisp system than a large Java system even though I've probably had more experience with the latter. Even grepping stuff is rather simple because of naming conventions.

hello_computer 2y ago

BeautifulSynch 2y ago

That’s not a matter of the language; and I don’t mean that in the “No True Scotsman” way either. Lisp definitely allows you to write code that is very easy to come back to and understand. I’ve written code like that, and I’ve seen code like that in eg certain sections of the SBCL internals, among many other projects. However, there’s a reason we don’t write all our code in Python or Assembly. The fundamental semantic restrictions of one and the simple functionality of the other are both traded off against horrible scaling relative to a technical project’s complexity and scope. If you write a project with complex stages/components in those kinds of languages (or mimic their styles in Lisp code, for that matter), either you have to split those components into parts that don’t make sense separately (making the code base significantly more complicated than eg an equivalent Lisp codebase), or you have to write extremely long and convoluted programs to accomplish conceptually simple functions (making the code base significantly more complicated than eg an equivalent Lisp codebase). Similarly, if you use the Python or Assembly coding paradigms for large projects, you quickly get lost in a sea of individually simple-seeming code segments, unable to grok the connections between said segments just because of how many things need to be kept track of. In contrast, for Lisp languages: A) The default style used by Lisp programmers is highly functional, using many higher-order functions, using macros that solve their problem-domains without explicitly exposing the code doing the solving (objects also fall into this general role, btw, which is apropos given the Common Lisp Object System was defined purely with macros), and clearly delineating code / systems with mutating effects. While this style is admittedly harder to grok than Python/Assembly for simple cases, it has almost no reduction in reading-complexity as code scale/complexity increases. Complexity gets naturally encapsulated and automated by functions/macros/objects (as opposed to either a restricted subset of those or simply the developer’s own head, which are the 2 approaches most other languages offer for complexity management) (algebraic type systems are a very cool exception to the prior note, but a pervasive object system (like CLOS) paired with macros allows you to make a type system (like Coalton) without feature/ergonomics loss). B) Interactive development and ergonomic DSL creation are objective wins for complex or large programs; the former significantly reduces iteration time for both cases, while the latter makes it easy to just write code once that addresses the complexity/scale of the domain and then never deal with that complexity again (or at least not with the full complexity, even if you don’t understand the domain well enough to obviate the irrelevant complexity entirely in your DSL). Sure, hot-reloading in a few other languages gives us most of the former (although things like CL conditions, debugging REPL-layers, access to object contents & stack-frame inputs (only addressed by some debuggers, and only in a restricted way), and some other features still lack equivalents) and other languages generally use objects alone to address (most instances, though not all, of) the latter (rather than Lisp’s mix of macros/objects/higher-order-functions) (we’re ignoring the text-templating macros in languages like C++ because everyone agrees they’re more trouble than they’re worth). But Lisp is still by far the most featureful and ergonomic offering of both of these facilities.

BaculumMeumEst 2y ago

Based comment and it's sad that common sense gets pushed to the bottom of the thread. You are dead on.