4 ms·

the idea that prefix notation is some kind of serious hold up for anyone thats mastered, or is even semi-competent at the kind of mathematics you would use this

the idea that prefix notation is some kind of serious hold up for anyone thats mastered, or is even semi-competent at the kind of mathematics you would use this for is so strange to me. Programming and math are (almost) nothing if not the ability to learn new rules of syntactical manipulation in all kinds of different domains. I say this as some one who is both a lisper and has severe dyslexia. It just seems like a totally made up hangup for a programmer to have. Its also weird to say "the world has spoken" when 60 years ago there were all of three or four non-assembly programming languages, and only 30 years ago prefix was still highly represented in serious industrial and research computing. Things change. Even five years ago doing "functional" programming in javascript was the fringe of the fringe of front end web development.

fiddlerwoaroof 7y ago
Yeah, function notation and much other math notation is already prefix: f(x), etc. the complications arise because for historical reasons we have the notion of infix operators, that complicate everything by forcing people to think about associativity and precedence.
vnorilo 7y ago
I think the reason infix feels "nice" is that you can sometimes write dataflows from leafs to roots, whereas with prefix you work from the root up. But then you use a lisp threading macro which lets you do that consistently, with any set of functions/operators.
- antepodius 7y ago
  I find I can still go leaf-to root, at least eith my editor (vim with the slimv plugin)- You can press ,W to 'wrap' a lisp expression in another set of parentheses, which means for something like (a + b) * (c + d) You can write the '(+ a b)' first, then wrap it in a (* [...])
  - vnorilo 7y ago
    Thanks for bringing up another benefit of s-expressions - paredit and friends!
lgessler 7y ago
Let me tell you my perspective as a Lisp enthusiast and ex-software engineer who now works in academia. I think the problem is that most people who write software in the world (even many professional software engineers) just want to solve their problem and will resist if at all possible having to learn anything difficult (such as S-expression syntax), even if it is promised that their hard work will pay off. The academics I work with, for instance, prefer Python, tolerate Java, do OK with JavaScript, but run for the hills when they see Lisp. When I tell them that ClojureScript not only has semantics with consistency that will elicit sobs of joy, but is also historically the most stable and concise way of targeting JS in the browser, maybe a few of them will be interested, but as soon as I show them a code snippet it's all over. They turn their heads sideways, they frown so that their lips are like the parentheses that splay before them, they mutter something about parentheses, and they go back to tripping over themselves in JavaScript trying to remember which Array functions are mutating or pure. Learning a new syntax makes you feel dumb, even if you know how to program. And if you're feeling dumb while you're working on something that isn't even strictly related to the problem you're supposed to be solving before your deadline, it starts to get really hard to justify it. Most people only know something with a Python-like syntax, so most people will only ever work with languages which look like Python or Java since it's what they learned in their programming curriculum. It's ALGOL's world, and Lisp's just living in it. Who does learn Lisp, then? I'd say, from what I've learned about the people in the Lisp world: mathematicians and computer scientists with intrinsic interest in PL's or the mathematical underpinnings of Lisp, old school symbolic AI researchers, and grizzled software engineering veterans who believe Lisp-family languages are engineering weapons of choice. All of these people have motivations (interest in mathematics and PL's per se, an academic interest with an historical connection to Lisp, and an insatiable itch for an ever more comfortable hammock even if it means getting out of the one you're in right now) that do not apply to the larger class of programmers that I just described. I wish it weren't so. I wish more people would take the time to learn Lisp or an editor like Vim or EMACS: we, ahem, enlightened ones, know what a pittance the upfront investment will come to seem when the benefits of a superior tool are reaped over a lifetime, but people do not listen or do not believe when we tell them so. (Maybe they're right.) Perhaps we should ask ourselves what could make the promise of our salvation more credible.
- 7y ago

fiddlerwoaroof 7y ago

Yeah, function notation and much other math notation is already prefix: f(x), etc. the complications arise because for historical reasons we have the notion of infix operators, that complicate everything by forcing people to think about associativity and precedence.

vnorilo 7y ago

I think the reason infix feels "nice" is that you can sometimes write dataflows from leafs to roots, whereas with prefix you work from the root up. But then you use a lisp threading macro which lets you do that consistently, with any set of functions/operators.

antepodius 7y ago
I find I can still go leaf-to root, at least eith my editor (vim with the slimv plugin)- You can press ,W to 'wrap' a lisp expression in another set of parentheses, which means for something like (a + b) * (c + d) You can write the '(+ a b)' first, then wrap it in a (* [...])
- vnorilo 7y ago
  Thanks for bringing up another benefit of s-expressions - paredit and friends!

lgessler 7y ago

Let me tell you my perspective as a Lisp enthusiast and ex-software engineer who now works in academia. I think the problem is that most people who write software in the world (even many professional software engineers) just want to solve their problem and will resist if at all possible having to learn anything difficult (such as S-expression syntax), even if it is promised that their hard work will pay off. The academics I work with, for instance, prefer Python, tolerate Java, do OK with JavaScript, but run for the hills when they see Lisp. When I tell them that ClojureScript not only has semantics with consistency that will elicit sobs of joy, but is also historically the most stable and concise way of targeting JS in the browser, maybe a few of them will be interested, but as soon as I show them a code snippet it's all over. They turn their heads sideways, they frown so that their lips are like the parentheses that splay before them, they mutter something about parentheses, and they go back to tripping over themselves in JavaScript trying to remember which Array functions are mutating or pure. Learning a new syntax makes you feel dumb, even if you know how to program. And if you're feeling dumb while you're working on something that isn't even strictly related to the problem you're supposed to be solving before your deadline, it starts to get really hard to justify it. Most people only know something with a Python-like syntax, so most people will only ever work with languages which look like Python or Java since it's what they learned in their programming curriculum. It's ALGOL's world, and Lisp's just living in it. Who does learn Lisp, then? I'd say, from what I've learned about the people in the Lisp world: mathematicians and computer scientists with intrinsic interest in PL's or the mathematical underpinnings of Lisp, old school symbolic AI researchers, and grizzled software engineering veterans who believe Lisp-family languages are engineering weapons of choice. All of these people have motivations (interest in mathematics and PL's per se, an academic interest with an historical connection to Lisp, and an insatiable itch for an ever more comfortable hammock even if it means getting out of the one you're in right now) that do not apply to the larger class of programmers that I just described. I wish it weren't so. I wish more people would take the time to learn Lisp or an editor like Vim or EMACS: we, ahem, enlightened ones, know what a pittance the upfront investment will come to seem when the benefits of a superior tool are reaped over a lifetime, but people do not listen or do not believe when we tell them so. (Maybe they're right.) Perhaps we should ask ourselves what could make the promise of our salvation more credible.

7y ago