5 ms·

I feel like I understand what the author is trying to say, because I remember feeling that "click" in my head when I finally understood why LISP syntax was the

I feel like I understand what the author is trying to say, because I remember feeling that "click" in my head when I finally understood why LISP syntax was the way it was, and why it was the best possible syntax. (It was at the same time that I realized that RPN was the best possible mathematical syntax, if that makes any sense). It's hard to explain this to other people, however. It's doubly hard trying to explain it to people who have spent their careers building up high levels of skill and knowledge in other languages. I'm not a professional coder-- I'm a hobbyist. I can program badly in many different languages. But I find that with LISP, I am much more productive and happier. I feel like I can "punch above my weight" using LISP, achieving things that would take a lot more skill and effort to do in other languages. I sometimes wish I could explain it better to other people, but other times I'm just happy to work on my own in my "obscure" language with the all the silly parentheses.

vanderZwan 12y ago
I hear you. I've recently enlisted to a course in program design on coursera[1] as a quick and easy entry to Racket (I've been hobby programming for years) and it struck me how consistent the syntax is, and how little explanation it needed beyond the first few videos on how evaluation works. Is there something as easy and small as Processing[2] in LISP form? Because the biggest criticism of Processing is also it's strength: download it, run it, and you have notepad with a compile-and-run button. You need something as un-intimidating as that for beginners of non-technical backgrounds. That's part of why we're using it as the first language in our design programme in Malmö University (apart from the fact that it's also a gateway language into Java proper, which is a useful language to become familiar with because of its widespread adoption). EDIT: Here's a short blog post comparing the two languages and IDEs: http://www.hive76.org/processing-and-racket http://www.hive76.org/processing-and-racket [1] https://www.coursera.org/course/programdesign https://www.coursera.org/course/programdesign [2] https://processing.org/ https://processing.org/
- moron4hire 12y ago
  Heh, wow, I actually wrote that blog post. That's kind of a weird feeling :) That post led to a big discussion on the Racket mailing list. And the suggestion for this came up: http://www.pawfal.org/fluxus/ http://www.pawfal.org/fluxus/ A 3D game engine for livecoding worlds into existence. Fluxus is a rapid prototyping, playing and learning environment for 3D graphics, sound and games. Extends the Racket language with graphical commands and can be used within it’s own livecoding environment or from within the DrRacket IDE. I've not used Fluxus, but I think this is probably the closest thing to what you want. There is the Turtle graphics API that comes with Racket, but it's not really meant for animation.
  - vanderZwan 12y ago
    Hah, what are the odds? Pretty favourable, probably - the nerd pool isn't that big. Thank you for the Fluxus suggestion! I'll give it a try - although development seems to have stagnated, lacking the critical mass needed to keep the project going (for now). (also, they should have followed your advice on websites. So many artsy open source initiatives seem hell-bent on being inaccessible to outsiders with their presentation)
    - moron4hire 12y ago
      At the time, I had notions that I would do the work that I described needing done. But my work changed quite a bit after that, I got dragged back into the .NET world, started screwing around with Node on the side, and just never got back around to Racket. I'm a bit disappointed in myself for it, actually, but such is life. As for Racket's website, it's significantly better now then what it was when I wrote that blog post. I don't know if it was based off of my recommendations, but it definitely improved things quite a bit. Ruby's site has also dramatically changed and I'm not sure it's been for the better. It looks like a generic WordPress theme now.
      - vanderZwan 12y ago
        I was actually talking about the Fluxus website ;)
superobserver 12y ago
Is Lisp anything like Lambda Calculus? If so, then I should get in on that, since I taught myself LC in a day. I saw the sheer power and beauty of it when I had "programed" ternary logic operators on paper with it. The only issue I had was the excessive use of parentheses. If there is a way to structure LC like Python (replacing the syntactical function of parentheses with space/indents), then I'd be sold on that for sure.
- jerf 12y ago
  In addition to other people's comments, I'd suggest Haskell is closer to being lambda calculus, due to aspiring to support "equational reasoning". It isn't "just lambda calculus" when you get right down to it, but then I don't know anything that is.
  - superobserver 12y ago
    I've tried getting into Haskell, but nothing out there that shows me how to tinker with functional code. I am the sink or swim type, just show me the kiddie pool first!
    - tjradcliffe 12y ago
      This is the first useful thing I've found on Haskell: http://en.wikibooks.org/wiki/Haskell http://en.wikibooks.org/wiki/Haskell The beginner track is very nice, taking you through the weird syntax, introducing pattern-matching with examples, and is relatively light on falsehoods.
      - superobserver 12y ago
        Hey, thanks!
- franek 12y ago
  > If there is a way to structure LC like Python There is Wisp (Whitespace to Lisp): https://bitbucket.org/ArneBab/wisp https://bitbucket.org/ArneBab/wisp http://draketo.de/light/english/wisp-lisp-indentation-preprocessor http://draketo.de/light/english/wisp-lisp-indentation-prepro... (I have never tried it.)
barrkel 12y ago
Some time as a professional coder in a team with developers of varying ability, and working with legacy code bases, and you might learn to appreciate a less malleable, more predictable language with more universal idioms.
- aaronem 12y ago
  You’d think, wouldn’t you? But I’ve worked professionally with codebases in something like a half-dozen languages by now, and I’m here to tell you that you’d be wrong. The lower bound of code quality is limited not by choice of language, but only by what a given compiler or interpreter will flatly refuse to put up with — there’s always a better fool. The upper bound, on the other hand, is highly susceptible to such limitation.
  - barrkel 12y ago
    A whole half-dozen, eh? :) You haven't been around long. Specific code quality is not what I'm talking about. I think you've misunderstood me. Let me try and be more specific and concrete. The degree to which code written by different authors at different times can gel together depends on the idioms they have in common. In languages without common collection libraries, code needs to communicate at the level of arrays and custom iterators. Languages without a single common memory allocator need have libraries negotiate who owns what memory, and have custom free functions specific to routines and libraries. Languages without lambdas typically reinvent the concept a half-dozen different, incompatible ways. The amount of friction when trying to compose code or integrate with existing code is proportional to its divergence from the lowest common denominator of all code written in that language. The higher-level a language is, the larger a standard library it has, the more concepts that are shared between libraries and codebases and don't need to be reinvented in each individual code silo. Go back to C in the dark days of Windows 95. Merely getting a string out of the OS was an ordeal; you could choose to allocate a buffer, send it to the OS, but always prepared to react to a failure and reallocate the buffer when the string turns out bigger than expected. C has no universal string type nor a common memory allocator (you might rely on glibc's malloc on Linux, but you're relying on non-portable convention). This directly resulted in a substantial amount of friction simply interoperating between two binary libraries. The same thing follows through with higher-level concepts. When higher-level concepts are concrete in the language or available in standard libraries rather than composed out of simpler primitives a half-dozen times in slightly different ways, you lose a bunch of composability. You spend more time writing shims and adapters to smooth away the differences between interfaces. And code isn't the only interface; your mind is too, especially in a larger legacy codebase. You may understand iterators, lambdas, functors, monads and so on, but in a language without first-class support and standard definitions for these things, you'll find them reinvented over and over again, to varying degrees of fidelity, sometimes under obscure names, which you'll need to discover and research as you dig into code nobody still in the organization has ever had to dig through themselves. None of this has anything to do with code quality possible in a language. I've had to maintain some extremely high quality assembly. But it wasn't mentally cheap to get into, and a lot of concepts had to be reverse engineered from the code before they could be modified and transformed back down. The risk with something like Lisp is that you use it as a language construction toolkit. With a closely knit team that grows a codebase amongst themselves, this can be a huge productivity win. But I don't think it scales. And I think history agrees. Excessively malleable languages (including Smalltalk) have not outcompeted less expressive languages, for one reason or another.
agumonkey 12y ago
I love lisp syntax (or the lack thereof), especially with non-text editors (paredit et al.). That said, applicative and ml languages made me rethink non sexp ones. (let ((...)) (f (g (h u v))) or let u = ... in f g (h u v) I'll take any of these two any day.
- sparkie 12y ago
  The difference between these two is that the first one describes a tree in an extremely consistent form whereby parens represent children and spaces represent siblings. The latter represent a tree only by means of a special "parser", which converts this sequence of characters into the tree. What's special about the former one is that it composes perfectly with any other tree structure using the same textural representation of trees, where the latter one is only useful in isolation - one cannot use this representation inside some other arbitrary character sequences which is to be converted to trees, because the means by which it is parsed into a tree does not compose well (unambiguously) with other means of parsing sequences of characters into trees. Perhaps the cleverest thing about S-expressions is that they were invented before we even had a theory of parsing unambiguously followed by a proof that we cannot compose multiple of these unambiguous parsers in a way which produces another unambigous parser.
  - agumonkey 12y ago
    It's a bit over my head, not sure I get what you said. But IIRC, Terence Parr wrote an article about composable parsers still being open research problem. But I'll add one delightful trait: sexps split usually complex parsing stage in two simple separate ones: - chars -> sexp - sexp -> meaning (special forms / anticipated mental evaluation). It's like a catalytic system.
    - sparkie 12y ago
      Composible parsers are indeed an open research problem, but it'd be wise to consider them more like the philosophers stone. Even humans find unambiguity in their languages which are quite well structured, yet some people are hanging onto the hope that a machine will be able to take arbitrary combinations of partially structured clauses and produce some kind of unambiguity. It isn't going to happen. At least not with plain text. There's some terrfic research in composing languages - currently the best is Tratt and Diekmann's Language Boxes, which enable arbitrary syntax composition by means of the programmer specifying the syntax boundaries explicitly - which requires a more sophisticated editor than out plain text notepad variants. With language boxes, and their prototype editor Eco, in the end, they're ultimately storing a tree of data in their own custom format - it doesn't matter what encoding is used, just as it doesn't matter whether lisp uses parens, braces or whitespace - what really matters is that you encode things deterministically into trees which can be easily reasoned about without requiring some "magic" (AI) which attempts to create a tree from a sequence of characters unambiguously, when the programmer knows and can specify exactly what he means.

vanderZwan 12y ago

I hear you. I've recently enlisted to a course in program design on coursera[1] as a quick and easy entry to Racket (I've been hobby programming for years) and it struck me how consistent the syntax is, and how little explanation it needed beyond the first few videos on how evaluation works. Is there something as easy and small as Processing[2] in LISP form? Because the biggest criticism of Processing is also it's strength: download it, run it, and you have notepad with a compile-and-run button. You need something as un-intimidating as that for beginners of non-technical backgrounds. That's part of why we're using it as the first language in our design programme in Malmö University (apart from the fact that it's also a gateway language into Java proper, which is a useful language to become familiar with because of its widespread adoption). EDIT: Here's a short blog post comparing the two languages and IDEs: http://www.hive76.org/processing-and-racket http://www.hive76.org/processing-and-racket [1] https://www.coursera.org/course/programdesign https://www.coursera.org/course/programdesign [2] https://processing.org/ https://processing.org/

moron4hire 12y ago
Heh, wow, I actually wrote that blog post. That's kind of a weird feeling :) That post led to a big discussion on the Racket mailing list. And the suggestion for this came up: http://www.pawfal.org/fluxus/ http://www.pawfal.org/fluxus/ A 3D game engine for livecoding worlds into existence. Fluxus is a rapid prototyping, playing and learning environment for 3D graphics, sound and games. Extends the Racket language with graphical commands and can be used within it’s own livecoding environment or from within the DrRacket IDE. I've not used Fluxus, but I think this is probably the closest thing to what you want. There is the Turtle graphics API that comes with Racket, but it's not really meant for animation.
- vanderZwan 12y ago
  Hah, what are the odds? Pretty favourable, probably - the nerd pool isn't that big. Thank you for the Fluxus suggestion! I'll give it a try - although development seems to have stagnated, lacking the critical mass needed to keep the project going (for now). (also, they should have followed your advice on websites. So many artsy open source initiatives seem hell-bent on being inaccessible to outsiders with their presentation)
  - moron4hire 12y ago
    At the time, I had notions that I would do the work that I described needing done. But my work changed quite a bit after that, I got dragged back into the .NET world, started screwing around with Node on the side, and just never got back around to Racket. I'm a bit disappointed in myself for it, actually, but such is life. As for Racket's website, it's significantly better now then what it was when I wrote that blog post. I don't know if it was based off of my recommendations, but it definitely improved things quite a bit. Ruby's site has also dramatically changed and I'm not sure it's been for the better. It looks like a generic WordPress theme now.
    - vanderZwan 12y ago
      I was actually talking about the Fluxus website ;)

superobserver 12y ago

Is Lisp anything like Lambda Calculus? If so, then I should get in on that, since I taught myself LC in a day. I saw the sheer power and beauty of it when I had "programed" ternary logic operators on paper with it. The only issue I had was the excessive use of parentheses. If there is a way to structure LC like Python (replacing the syntactical function of parentheses with space/indents), then I'd be sold on that for sure.

jerf 12y ago
In addition to other people's comments, I'd suggest Haskell is closer to being lambda calculus, due to aspiring to support "equational reasoning". It isn't "just lambda calculus" when you get right down to it, but then I don't know anything that is.
- superobserver 12y ago
  I've tried getting into Haskell, but nothing out there that shows me how to tinker with functional code. I am the sink or swim type, just show me the kiddie pool first!
  - tjradcliffe 12y ago
    This is the first useful thing I've found on Haskell: http://en.wikibooks.org/wiki/Haskell http://en.wikibooks.org/wiki/Haskell The beginner track is very nice, taking you through the weird syntax, introducing pattern-matching with examples, and is relatively light on falsehoods.
    - superobserver 12y ago
      Hey, thanks!
franek 12y ago
> If there is a way to structure LC like Python There is Wisp (Whitespace to Lisp): https://bitbucket.org/ArneBab/wisp https://bitbucket.org/ArneBab/wisp http://draketo.de/light/english/wisp-lisp-indentation-preprocessor http://draketo.de/light/english/wisp-lisp-indentation-prepro... (I have never tried it.)

barrkel 12y ago

Some time as a professional coder in a team with developers of varying ability, and working with legacy code bases, and you might learn to appreciate a less malleable, more predictable language with more universal idioms.

aaronem 12y ago
You’d think, wouldn’t you? But I’ve worked professionally with codebases in something like a half-dozen languages by now, and I’m here to tell you that you’d be wrong. The lower bound of code quality is limited not by choice of language, but only by what a given compiler or interpreter will flatly refuse to put up with — there’s always a better fool. The upper bound, on the other hand, is highly susceptible to such limitation.
- barrkel 12y ago
  A whole half-dozen, eh? :) You haven't been around long. Specific code quality is not what I'm talking about. I think you've misunderstood me. Let me try and be more specific and concrete. The degree to which code written by different authors at different times can gel together depends on the idioms they have in common. In languages without common collection libraries, code needs to communicate at the level of arrays and custom iterators. Languages without a single common memory allocator need have libraries negotiate who owns what memory, and have custom free functions specific to routines and libraries. Languages without lambdas typically reinvent the concept a half-dozen different, incompatible ways. The amount of friction when trying to compose code or integrate with existing code is proportional to its divergence from the lowest common denominator of all code written in that language. The higher-level a language is, the larger a standard library it has, the more concepts that are shared between libraries and codebases and don't need to be reinvented in each individual code silo. Go back to C in the dark days of Windows 95. Merely getting a string out of the OS was an ordeal; you could choose to allocate a buffer, send it to the OS, but always prepared to react to a failure and reallocate the buffer when the string turns out bigger than expected. C has no universal string type nor a common memory allocator (you might rely on glibc's malloc on Linux, but you're relying on non-portable convention). This directly resulted in a substantial amount of friction simply interoperating between two binary libraries. The same thing follows through with higher-level concepts. When higher-level concepts are concrete in the language or available in standard libraries rather than composed out of simpler primitives a half-dozen times in slightly different ways, you lose a bunch of composability. You spend more time writing shims and adapters to smooth away the differences between interfaces. And code isn't the only interface; your mind is too, especially in a larger legacy codebase. You may understand iterators, lambdas, functors, monads and so on, but in a language without first-class support and standard definitions for these things, you'll find them reinvented over and over again, to varying degrees of fidelity, sometimes under obscure names, which you'll need to discover and research as you dig into code nobody still in the organization has ever had to dig through themselves. None of this has anything to do with code quality possible in a language. I've had to maintain some extremely high quality assembly. But it wasn't mentally cheap to get into, and a lot of concepts had to be reverse engineered from the code before they could be modified and transformed back down. The risk with something like Lisp is that you use it as a language construction toolkit. With a closely knit team that grows a codebase amongst themselves, this can be a huge productivity win. But I don't think it scales. And I think history agrees. Excessively malleable languages (including Smalltalk) have not outcompeted less expressive languages, for one reason or another.

agumonkey 12y ago

I love lisp syntax (or the lack thereof), especially with non-text editors (paredit et al.). That said, applicative and ml languages made me rethink non sexp ones. (let ((...)) (f (g (h u v))) or let u = ... in f g (h u v) I'll take any of these two any day.

sparkie 12y ago
The difference between these two is that the first one describes a tree in an extremely consistent form whereby parens represent children and spaces represent siblings. The latter represent a tree only by means of a special "parser", which converts this sequence of characters into the tree. What's special about the former one is that it composes perfectly with any other tree structure using the same textural representation of trees, where the latter one is only useful in isolation - one cannot use this representation inside some other arbitrary character sequences which is to be converted to trees, because the means by which it is parsed into a tree does not compose well (unambiguously) with other means of parsing sequences of characters into trees. Perhaps the cleverest thing about S-expressions is that they were invented before we even had a theory of parsing unambiguously followed by a proof that we cannot compose multiple of these unambiguous parsers in a way which produces another unambigous parser.
- agumonkey 12y ago
  It's a bit over my head, not sure I get what you said. But IIRC, Terence Parr wrote an article about composable parsers still being open research problem. But I'll add one delightful trait: sexps split usually complex parsing stage in two simple separate ones: - chars -> sexp - sexp -> meaning (special forms / anticipated mental evaluation). It's like a catalytic system.
  - sparkie 12y ago
    Composible parsers are indeed an open research problem, but it'd be wise to consider them more like the philosophers stone. Even humans find unambiguity in their languages which are quite well structured, yet some people are hanging onto the hope that a machine will be able to take arbitrary combinations of partially structured clauses and produce some kind of unambiguity. It isn't going to happen. At least not with plain text. There's some terrfic research in composing languages - currently the best is Tratt and Diekmann's Language Boxes, which enable arbitrary syntax composition by means of the programmer specifying the syntax boundaries explicitly - which requires a more sophisticated editor than out plain text notepad variants. With language boxes, and their prototype editor Eco, in the end, they're ultimately storing a tree of data in their own custom format - it doesn't matter what encoding is used, just as it doesn't matter whether lisp uses parens, braces or whitespace - what really matters is that you encode things deterministically into trees which can be easily reasoned about without requiring some "magic" (AI) which attempts to create a tree from a sequence of characters unambiguously, when the programmer knows and can specify exactly what he means.