6 ms·
Sympathetic, but as long as lisp requires one to write math as function composition it won't catch on with computational types. Of course, I imagine that sort o
by noobermin 8y ago
Sympathetic, but as long as lisp requires one to write math as function composition it won't catch on with computational types. Of course, I imagine that sort of thing could be a set of macros away...then that would be awesome, familiar infix mathematical expressions with common lisp in the rest of the code.
- dreamcompiler 8y agoI've been doing serious math with common lisp for 30 years. For me, the convenience of having automatic bignums and complex numbers, n-ary functions, and true rationals means I can think about math rather than about the limits of computers. The prefix notation became a non-issue in about a day.
- dwheeler 8y ago"Prefix notation is a non-issue" is true for a tiny minority of software developers and mathematicians. The world has already spoken: infix is a minimum requirement for the vast majority of people doing math. Bignums, true rationals, and many other constructs are already available in Python. Numpy is too. Most importantly, infix is available in Python. The funny thing is that it's already possible to do infix in Common Lisp. My "readable Lisp" approach has been supporting infix in standard Common Lisp: https://readable.sourceforge.io/ https://readable.sourceforge.io/ It's already available in the QuickLisp libary as "readable". You can then use {1 + 2} with macros, quasiquoting, and so on.
- dtornabene 8y agothe 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 8y agoYeah, 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 8y agoI 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 8y agoI 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 8y agoThanks for bringing up another benefit of s-expressions - paredit and friends!
- lgessler 8y agoLet 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.
- dreamcompiler 8y ago> Bignums, true rationals, and many other constructs are already available in Python. Numpy is too. The difference is that these things all run dramatically faster in CL than in plain Python, because CL is compiled AOT. In CL, a C library for math is optional. In Python, Numpy is mandatory. > Most importantly, infix is available in Python. Infix is certainly available in CL too, as other posters in this thread attest. I just don't feel any need for it.
- yarrel 8y agoI'm an art student. Prefix notation is a non-issue. If people want an infix Lisp, Dylan is awesome and doesn't add yet another flow-breaking set of different parantheses to the syntax.
- reikonomusha 8y agoYou can use CMU-INFIX: https://github.com/rigetti/cmu-infix https://github.com/rigetti/cmu-infix
- linguae 8y agoI'm not 100% sure about this. A counterexample is the popularity of RPN. HP's RPN calculators with postfix notation are well-loved among some engineers, scientists, and accountants, precisely because of the benefits of RPN over infix notation. I have a HP-48SX calculator, and I regularly use the `dc` command on Unix machines and in WSL whenever I need access to a calculator while I'm on a computer. Of course, I am proficient in prefix, infix, and postfix notation, but I like postfix notation the most. Of course, though, the marketshare of TI's infix calculators is much higher than HP's RPN calculators, and I haven't heard of much recent developments regarding HP's calculator line (the last I heard was HP had a limited-edition re-release of the famous HP 15c model sometime back in 2011, and also earlier this decade HP released a graphing calculator with a color display). But nevertheless there are people who prefer RPN to infix.
- darkpuma 8y agoThose TI calculators are real cool, I cut my teeth as a programmer on a TI-83+ learning z80 assembly, but the truth is they're considered by many to be devices for teenagers. HP calculators seem far more popular in industry.
- mcabbott 8y agoThe thing about RPN is that it worked well as a sort-of "spoken not written" language. It's a clear and usable way to give instructions one-at-a-time to a calculator with a 1-line display. But written out on paper, it's very hard to see what's going on at a glance, which is why nobody does this on paper. Almost anyone programming in mathematical expressions of reasonable complexity today will spend much more time reading (and triple-checking!) these expressions than typing them. That's a strong reason to like infix notation, and in general notation close to what you would use on paper.
- lgessler 8y agoWhat exactly do you mean by function composition? If you mean you can't have long chunks of purely imperative code in CL, I'm pretty sure that's not true: CL is multi-paradigm and supports imperative style. I think you might be referring to its S-expression syntax, which is prefix?
- ken 8y agoHave you seen numeric code (like SIMD intrinsics, BLAS, or LAPACK) in C or Fortran? It's all prefix function calls, anyway, even in those languages.
- kyllo 8y agoRight on, now we're only arguing about whether the open paren goes before or after the function name :)
- vnorilo 8y agoI'm not saying you are wrong, but the oft-cited challenge of prefix is a meme. It's not really a big deal. It's trivially easy to add infix syntax to lisps via macros, but almost no one bothers. By the time you know enough to do it, you're also already used to prefix.