Numpy Clone in Common Lisp
github.com
github.com
The MACLISP compiler was as good and in some cases better than its contemporary FORTRAN competition. But FORTRAN tech has moved on since then.
https://developer.ibm.com/recipes/tutorials/watson-iot-with-...
I have been working on Latplan [AAAI-2018, 2,3,4,5,6], a neural-symbolic classical planning system that learns symbolic representations of noisy images and perform efficient symbolic planning in the latent space. Later, several other groups have started working in this field, like [7].
The problem with python is the lack of sequential execution speed, which is necessary for solving symbolic tasks, e.g. SAT solver, classical planning, theorem prover. At the same time, traditional languages like C++, typically used for writing solvers, are too inflexible to accommodate the workflow in machine learning. For a neural-symbolic task, personally, Lisp is best in this space (I don't try to repeat why, because there are plenty of articles on it.), with Julia being a contender.
I am also interested in adding the compile time type/shape checking on the deep learning code, since python debugging is painful (just a personal opinion -- not intending to start a war here).
By the way, I made the first prototype of this lib in 3 days, and am working on improving it for 3 month (for other ML projects).
[1] https://medium.com/@MITIBMLab/the-shared-history-and-vision-... [2] https://github.com/guicho271828/latplan [3] AAAI18 presentation at : https://asai-research-presentation.github.io/2018-2-5-aaai/ [4] AAAI18 paper : Classical Planning in Deep Latent Space: Bridging the Subsymbolic-Symbolic Boundary, https://arxiv.org/abs/1705.00154 [5] Follow-up papers (ICAPS2019) : https://arxiv.org/abs/1903.11277 [6] Follow-up papers (ICAPS2019), extension to first order logic : https://arxiv.org/abs/1902.08093 [7] Learning Plannable Representations with Causal InfoGAN, https://arxiv.org/abs/1807.09341v1
C header files also have a ready analogy in Lisp: they are like Lisp files that provide macros and constants.
Where the LGPL says "The object code form of an Application may incorporate material from a header file that is part of the Library." we can understand this "header file" to refer to a Lisp file that provides macros that generate code within the Application's file.
The LGPL doesn't define what is a "header file"; it doesn't say that it's a C thing with typedefs and #defines. In that regard it has a flaw whether we apply it to a C shared library to a collection of Lisp object files.
The answers depend on the Lisp implementation used. There is a good reason that Franz decided to augment the LGPL (at their time version 2) with a license preamble to clear up the ambiguities in the context of Common Lisp.
You are a lawyer? You are a professional Lisp programmer? How does the LGPL deal with Common Lisp macros?
"Franz did LLGPL" is not by itself a good enough reason to suspect there are or to use LLGPL.
As Franz is the most prominent Lisp vendor, employing some of the greatest Lisp programmers and undoubtfully having a good legal department, I see no reason why I shouldn't take their legal opinion seriously. Especially as it is not part of any commercial offerings of theirs, but just provided as a clearer license for Lisp libraries. It also coincides with everything I heard from my lawyers at the company I work for.
Here is my stance on this: https://common-lisp.net/project/ecl/posts/ECL-license.html.
TL;DR if someone wanted to have Lisp code to be licensed under GPL terms they would license it that way. I'm a professional Lisp programmer and I've spend a fair share of hours on reading licenses and analyzing them.
If you had read the post you'd have my answer to that question.
There is no need to spread fear and uncertainty about LGPL and other copyleft licenses, I've seen too much of that over last few years (and I have a strong intuition that it is not an accident).
P.S. "are you a lawyer?" argument is very cheap (and often happening on threads about copyleft licenses) given it is HackerNews not LawyerNews -- I know of lawyers working for corporations who say that they wouldn't touch anything with GPL in the license name with a five-meter pole (not knowing a difference between LGPL, GPL and AGPL) -- there goes your "in-depth legal analysis". Same lawyers doesn't bat an eye when they give a green light for eula-crippled code from their "technical partners". Cargo cult is present everywhere, not only in software development.
I have read your post, and just reread it, and I don't see where you answer that question. How does an SBCL user deploy a program with an LGPL library so that the reciever of the program can relink it as required by the license.
P.S. "are you a lawyer?" argument is very cheap
I used this question on a post where the poster just makes a claim, not supporting it by any reasoning or linking to supporting documents. The question must be allowed how he justifies his statement. So for legal questions, this would be: are you a lawyer? as I would ask a random poster making definitely medical statements: are you a doctor?
And yes, I know, beeing a lawyer per se doesn't guarantee a correct evaluation, I have worked with far too many corporate lawyers, which are usually not experts on open source licenses. But I also had no doubts on the competence of those, who looked into the details of the licenses in question. I have been able to get their OK on LLGPL software for example, though GPL is of course limited to very isolated usages.
Rather, shared-library mechanisms are platform-specific. ELF shared libraries are different from Windows DLL's, for instance. The LGPL covers both, because it's mum on implementation details.
The abstraction is basically the same. The application has some symbolic references satisfied dynamically by the library, and possibly vice versa.
> The LLGPL is an easy amendment to make those intentions clear.
I wouldn't use it because it's a rare license, and I'm not a lawyer. It's best to use one of the top five or so popular licenses. Licenses aren't programming languages; it's okay to use the popular thing.
Furthermore, bosses and customers don't want to hear that Lisp is so weird that it needs a modified version of a license that everyone else uses in stock form.
The LLGPL contains dubious, superfluous clauses like: "It is permitted to add proprietary source code to the Library, but it must be done in a way such that the Library will still run without that proprietary code present."
w...hy? The LGPL doesn't allow that, and there is no reason to do that in a Lisp library.
Code is not added to libraries in Lisp; it is added to the image. We can add the proprietary application into the image and we can load the library into the image. That's all the mixture of proprietary and LGPL that is needed; the proprietary sources don't have to appear to be mixed into the library in the project tree. Keep it in a separate directory, which contains a copy of the LGPL which applies to every source file in it. No brainer.
Rather, shared-library mechanisms are platform-specific. ELF shared libraries are different from Windows DLL's, for instance. The LGPL covers both, because it's mum on implementation details.
The abstraction is basically the same. The application has some symbolic references satisfied dynamically by the library, and possibly vice versa.
Shared libraries are not limited to C, but in the context it should have been clear what I was talking about. Most importantly, most Common Lisp systems are not using shared libraries in the way C and languages using C style bindings do.
> The LLGPL is an easy amendment to make those intentions clear.
I wouldn't use it because it's a rare license, and I'm not a lawyer. It's best to use one of the top five or so popular licenses. Licenses aren't programming languages; it's okay to use the popular thing.
I also am strongly advocating not using rare licenses. But they are still preferrable to licenses which do not work as intended for technical reasons. LLGPL is one thing, I would rather recommend a BSD style license, as it is very well known, has no technical problems involved and is actually the license of the original Numpy code. Why choose a different license for a reimplementation of Numpy?
LGPL offers significant protections that can not be found in BSD.
In this case, the author could choose LGPL even if it were derived on the numpy code. So yes, technically the author is free to choose about the license. However, unless specific and significant reasons require this, I would find it just appropriate to choose the same or a similar license.
LGPL offers significant protections that can not be found in BSD.
Well, I asked the author - without ever getting an answer - whether there would be specific reasons, why the LGPL would be needed. For example, because of requirements by his employer or other specific reasons. Other than that, yes, people always claim that the GPL style license offers especial "protections". But one has to look at the environment. We are talking about a port (derived or not) of the BSD licensed Numpy, intended to run e.g. on the BSD licensed SBCL. So if the library would require special "protections", one could name them.
It says the Library provides "header files" which deposit executable code into Application.
"Header file" is C jargon, but it's not given any definition in the license.
Lisp files that provide macros can be construed as "header files". They can be compiled (but C headers can be "compiled" also).
Nothing in the license seems to be sensitive to the technological/qualitative difference between C and Lisp macros.
(FWIW, I've written a Lisp implementation that has compile-file and load, similar to Common Lisp.)
A Lisp-ified LGPL might seem perfect, but on the other hand there are some good reasons not to introduce derivative versions of de facto standard licenses.
https://ja.reddit.com/r/lisp/comments/9gjd0m/lisping_copylef...
Even so,this article has shown that the clarifications made by the LLGPL to the original GNU license are largely unnecessary, and that the LGPL would probably be interpreted in a similar fashion withoutthe clarifications proposed by the LLGPL.
The useage of the words "largely" and "probably" would make me less confident of the verdict, that the LGPL is enough.
On a different angle: I checked Numpy and it is using a BSD-license. What was your motivation to license your library differently? Is your library derived from Numpy or just implementing the same api? A BSD-style license would make any technical issues - both legal and actual distribution of the product - just go away.
Multiple people have told you that there are no technical issues with LGPL applied to Lisp programs but of course you may persist in thinking so. Do not expect others to share your anxieties though, particularly when it comes to deciding which license to use for their code.
I suggested a BSD-style license, as it would resolve any possible legal problems and is actually the license of the library that was cloned. I asked the author, whether he could name a concrete reason why he switched his work to a different license than the original library, which I would find an appropriate default.
Multiple people have told you that there are no technical issues with LGPL applied to Lisp programs but of course you may persist in thinking so. Do not expect others to share your anxieties though, particularly when it comes to deciding which license to use for their code.
How many of those people are lawyers? Law isn't decided by a majority vote. I am a professional programmer working with far too many lawyers to do my work. Calling my concerns about the legal technicalities of a licence "anxieties" is quite inappropriate.
Common Lisp (as does Clojure and Julia to a lesser extent) has unparalleled interactivity (besides maybe smalltalk), you can make it as concise as you want, ultimate hackability and really good performance. Research (not deployment) is the one area CL could probably surpass every other, but unfortunately it lacked a concentrated effort (by a company or community) in this current AI resurgence (maybe because of the Lisp Curse). Though there will always be other opportunities.
Or fortran, where there is no stupid overhead in "for" loops. Or C. Hell, or even luajit if you do not need fancy stuff.
Honestly, python/numpy is possibly the slowest and less convenient way to do math (assuming that you only want to do math, and no need any strings/dictionaries and other useless data structures).
Edit: I'm asking as I teach this stuff to undergrads and need to understand potential obstacles.
Then, there are a few issues when you get past non-trivial indexing of 1D arrays like a[3:]. For matrices, the semantics of numpy says that a 2D array is a 1D array of 1D arrays. So if A is 2D array, then A[3] is the 4th row of the array. Not great.
Another is that given 2D array A, and indexing vectors r and s, A[r,s] returns a 1D array while Matlab returns a 2D array with completely different semantics.
Another is negative indices.
Then you have things like A[(1,2)] being different from A[[1,2]]] and the whole concept of slices objects like Ellipsis, np.newaxis, and their combinations like (Ellipsis, 1, np.newaxis).
Another is that indexing returns a view and not a copy.
This is just indexing. There are tons of other issues with numpy like the multiply operator, the seemingly random way that they split methods (as in A.sum()) and applicable functions (as in np.sum(A)), and other nonsense.
Numpy is basically a library stuck on top of Python with Python not being away of numpy or multi-dimensional arrays at all. It's ridiculous that numerical and scientific programming has devolved into working with numpy.
This! So much this!
Many people have lived through different phases of numpy appreciation. First, when it appeared, it was amazing to be able to access huge arrays from within a script. Then when it evolved, there was a slight suspicion that things were going a bit out of hand. Later it became a caricature of itself when it began to replace matlab. Today, we are in the tragic state where many young people think that "the only possible way to multiply two matrices on a computer is by using numpy.dot".
Of course, if you want to do stuff that is not implemented, all those others will do better since you're using the native types and everything works with it (which is the same with this CL Numpy Clone). And I can't see how C is a good interface for numerics.
For information of anyone who doesn't know about performance of level 3 BLAS: It doesn't come just from vectorization, but also cache use with levels of blocking (and prefetch). See the material under https://github.com/flame/blis. Other levels -- not matrix-matrix -- are less amenable to fancy optimization, with lower arithmetic density to pit against memory bandwidth, and BLIS mostly hasn't bothered with them, though OpenBLAS has.
It's long been the case that compilers generate adequate vector code for five-year old cores. A large part of the wins for hand-vectorization (and assembly) come from targeting cores that haven't even been released yet, or were just made available.
Also, 2/3 is ... significantly worse than I would expect, actually. My experience writing GEMM (I did it professionally for a decade) is that getting to 80% of peak is mechanical, and the remaining 10-15% is where all the real work is.
It's also a mistake to ignore L1 and L2 BLAS; for data that fits in the cache hierarchy, these become important, and you can absolutely squeeze out significant gains from hand optimization. For the HPC community, such small problems are uninteresting, but for everyday consumer computing, you can reap huge benefits here.
If it's not not good enough, there are a few CL bindings and wrappers around BLAS and LAPACK.
A good one is Matlisp, which is available in QuickLisp.
Current generations tends to be unaware that once upon a time C compilers only generated turtle code, it was the investment into optimizing compilers and abuse of UB that made current compilers able to generate fast code.
On today's machines, I think you can expect to get more than 50% of performance from trivial compilation, compared to optimized code. Depending on workload you it can be 80-90%. (I have a small amount of experience, based on my own very shitty compiler, to back up that claim).
Even on machines from "once upon a time", where performance was more directly correlated with code size, it couldn't have been that bad, assuming the factor of 5. And also seeing the fact that C was used for systems development from the start.
And that's still ignoring (or at least contradicting) the common lore that "once upon a time", LISP was comparatively more inefficient than C than it is today!
And I don't believe that abuse of UB is important to generate fast code. After all, fast code doesn't necessarily contain UB.
Once upon a time Common Lisp compilers were already good enough versus Fortran.
https://people.eecs.berkeley.edu/~fateman/papers/lispfloat.p...
As for C's performance on the old days,
"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."
-- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming
Nobody doubts that you can efficiently compile high-level LISP programs for certain specific problem domains. In some cases, you can even get an edge over the equivalent, ugly, C program.
But empirically, for general systems programming, C is second only to assembly in performance, the only problem being pointer aliasing (which you can easily avoid in many cases by using global data instead of doing overabstracted OOP).
That's not because C is perfect, but because it gives you the right mindset, and gives you control in a very accessible way. (And yes, of course you can write C-like systems code in LISP, too... If you're masochistic enough).
The benchmarks game should be enough of a proof here (and it's not even for complicated problems). Why don't you try improving SBCL times there and then come back?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
(Not that I care for performance factors of 4 that much by default. These are simple programs. And at least they refute the ludicrous claim that C is slow, right?).
Alright, but to what degree is the latter the cause of the former? The OP has already noted that C used to not be very fast, and that it became fast through the rise of sufficiently smart compilers. Do you dispute this claim?
>Why don't you try improving SBCL times there and then come back?
What good would that do? You have already seceded that you can write a C-like program in Common Lisp. This is especially true in SBCL, where you could write a Lisp program to generate the correct assembly code for the program.
I wasn't alive at that time... But as described I'd wager to dispute it. You need much more sufficient-smartness to make LISP fast. Isn't it obvious? Or is that somehow counter to any history you've read, except when cherry-picked and reinterpreted by some HN commenter?
> The OP has already noted that C used to not be very fast
Not very fast, compared to what? It's just not extremely fast when compared to numerical Fortran code (not: systems programming) or when compared to Assembly. Right? In my book this is just the worst kind of cherry picking.
If it was a reasonable claim, then would someone name the production OS from the early 70s written in LISP, and explain how it's better?
Better or more performant for some measure of performance? I mean, you can always read the UNIX hater's handbook if you're interested in qualities that UNIX did not possess decades ago.
>You need much more sufficient-smartness to make LISP fast. Isn't it obvious? Or is that somehow counter to any history you've read, except when cherry-picked and reinterpreted by some HN commenter?
If you want to make a pedantic argument, then no, it's not difficult to make Common Lisp potentially as fast as C. This is because I can very easily drop down to a level of safety which is on the same level as C. This is, of course, unsafe and I would never recommend it.
I don't understand why numerics performance is cherry-picking, but "systems programming" (what does that mean? OS dev. only?) is not.
This would be a much simpler discussion if you concisely describe in a semi-formal manner why C has a larger potential to be fast than CL. If you did so, it probably would be a lot more difficult for me or anyone else to refute your claims.
That's stating the obvious, which I had already stated in advance if you care to read it. (Don't miss the extra "If you're masochistic enough"). What you're presenting is a Turing tarpit kind of argument - totally irrelevant to anybody with a sense for practicality.
> Better or more performant for some measure of performance? I mean, you can always read the UNIX hater's handbook if you're interested in qualities that UNIX did not possess decades ago.
From what I remember, the Unix hater's handbook is half satire (based on good understanding), and half wrong. Yes, UNIX is the worst useable OS, except all the alternatives.
> I don't understand why numerics performance is cherry-picking, but "systems programming" (what does that mean? OS dev. only?) is not.
Because most programs aren't numerics programs, but every software system needs "systems programming". And coincidentally, C was made for systems programming. Unlike Fortran, it was not made specifically for numerics / scientific programming.
> This would be a much simpler discussion if you concisely describe in a semi-formal manner why C has a larger potential to be fast than CL. If you did so, it probably would be a lot more difficult for me or anyone else to refute your claims.
I suggest actually reading my comments, because I've written all that I have to say. In one sentence, the other side's arguments are all either of the sufficiently-smart-compiler kind, or the performance equivalent of the Turing Tarpit fallacy.
Just a last comment, we're kind of off the rails here. I'll read your reply but I won't answer, I hope you're OK with that!
> What you're presenting is a Turing tarpit kind of argument - totally irrelevant to anybody with a sense for practicality.
Not really, it requires very little to do so. Here's how to make fixnum arithmetic go wroom-wroom: https://plaster.tymoon.eu/view/1380#1380
Does that look like a Turing tar-pit to you? Scroll down to the assembly.
I mean, I do think that C-level safety is unacceptable though.
> [...] and half wrong. Yes, UNIX is the worst useable OS, except all the alternatives.
You happen to be misinformed regarding this. It's true today regarding Linux perhaps, but not back then.
>I suggest actually reading my comments, because I've written all that I have to say. In one sentence,
Didn't you just say that empirical evidence points towards C being fast? That's not enough.
And on 8 and 16 bit systems, any junior Assembly programmer could easily outperform code generated by C compilers.
It would surprise and nudge expectations in a positive way.
> You have already seceded that…
?
conceded ?
http://www.iaeng.org/IJCS/issues_v32/issue_4/IJCS_32_4_19.pd...
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/ It's already available in the QuickLisp libary as "readable". You can then use {1 + 2} with macros, quasiquoting, and so on.
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.
They learned that stuff because they are either basic methods in the field that have demonstrated value, or what they're actually doing research on.
The syntax buys them power that they wouldn't otherwise have, and they can smell it.
S-expressions? Not so much - the notation is more or less and arbitrary choice unless you're going to leverage the metalanguage capabilities to the hilt, and there are many other programming approaches available.
A mathematician who really wanted to jump into the deep end with programming syntax/structure would much more likely pick up Haskell (categories, yay!) or AVL rather than Lisp.
We could sit here and grumble about how silly it is that people cannot overcome such an irrational response (indeed I often do), but that won't change the fact that people have these responses. If we did that, we'd be doing the same thing that GUI designers did in the 90's. "Why, the widget for $x is right here. Any reasonable user will RTFM, know that $x can be checked there, and behave perfectly rationally." (And it happened just so, as decreed from developer's rolling chair, right?) Of course, we know now how misguided this is as a method for UX design: all users are in a sense irrational, and systems need redundant strategies for saving the user from themselves.
The similarity here is that we cannot will away intellectual blemishes in users, we can only accommodate them. That is Lisp's challenge if it is ever to get big. For GUI's, the solution was to take seriously users' need for visually attractive interfaces, redundant display of information, and guardrails/handholding for actions commensurate with their risk, to name a few strategies. For Lisp, it's hard to know what might be the right approach. As klibertp writes in a sibling comment, maybe the solution needs to come from outside the language itself.
It's really strange to me. Imagine if people did that outside of software. I can already walk so I must be able to ride a bike. I can speak English, so I must be able to speak French. The same goes for software. I spent years trying to understand infix notation and learning the precedence rules. Why would it not take time and effort to learn prefix notation?
Nope, it happens with EVERYTHING. If it doesn't work like something they've used before, they have to really, really need it to use (as in, be forced to use it), otherwise, into the trash it goes.
Consistent, long-term, highly visible propaganda put everywhere. Paid ads, people proselytizing in the streets, billboards with posters repeating the same message over and over.
In general, to get popular, you either need to luck out and be at the right place at the right time, or you can force it with propaganda. I don't see any other way. Rational arguments are useless if no one is aware they exist. Plus, rational arguments tend to require thinking on the receiving end, which is hard for people who just glance at something in passing. Simple message hammered into people's heads over and over is the only thing that seems to work.
If I ever become a billionaire, I will fund such a campaign. It's so disheartening to see a great technology being left in the dust due to historical accidents and resistance to any change that's intrinsic in most people. We can't do anything about the AI Winter or Lisp-machines demise, but - as many successful ad campaigns show - we can convince people to change their ways. It's just incredibly expensive, time-consuming, and hard to do right - as many failed ad campaigns show.
And even for solo programmers, it's easier to find an answer on stackoverflow for a popular language than an unpopular one.
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.
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.
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.