reikonomusha

2 months agodiscuss

Packaging software for Linux users is a nightmare. Unless

- your program is extraordinarily simple

- you can manage to statically link libc

- you can ship (or statically link) all .so files

- you can ensure your app can run in a sandbox

- you limit the distros you build for

- your app can be built by whatever is on flathub

etc., most solutions to shipping software simply don't work out-of-the-box. Despite the kernel being reasonably stable, userspace APIs are a mess of incompatible.

reikonomusha

2 months agodiscuss

The problem is that the intersection between your business's interests and the interests of the small pool of available developers is usually very small.

Building banking apps? Well, even if it's Haskell, the Haskellers were dreaming of GPU compiler jobs, not banking front ends. So you're probably down to literally 5 qualified people on earth who want your job.

But then 3 of those 5 don't want to relocate or have other operational desires that require you to re-think how you run your team, and 2 of those 5 believe so strongly in supply-demand that their salary should be 3x the industry average.

Many companies, including Jane Street, come to the same conclusion: If you really want developers of a niche language, you have to be very good at finding smart people who don't know the language and training them.

reikonomusha

2 months agodiscuss

Haskell is typically terse in addition to expressive. So "tight" seems more apt.

Lisp is traditionally not so terse, but still expressive.

reikonomusha

2 months agodiscuss

For a brief period of time over 60 years ago, yes. :)

reikonomusha

2 months agodiscuss

What evolution in particular do you think? The developers use it for commercial products in quantum computing and defense [1]. That doesn't mean it's done in some complete language ecosystem sense (which is discussed in [1], and one could argue Haskell also never feels "finished"), but it also doesn't seem like an unfinished hobby project. Given that it's embedded in Common Lisp, there's always a way to fill in the library gaps, sort of like how if a "native" library doesn't exist in Clojure, one can always reach for Java.

[1] From Toward Safe, Flexible, and Efficient Software in Common Lisp at the European Lisp Symposium, "[Coalton] has been used for the past 5 or so years [...] first in quantum computing and now a serious defense application." https://youtu.be/xuSrsjqJN4M&t=9m14s

reikonomusha

2 months agodiscuss

For all practical purposes, the syntax of Lisp isn't just a cosmetic choice, though.

reikonomusha

3 months agodiscuss

reikonomusha

3 months agodiscuss

What you say is entirely true in theory. An editor can have whatever it wants. Anything is possible—but somebody needs to do the work. If your favorite code editor is Zed, chances are nobody wrote proper Lisp indentation in it or any sort of Lisp interaction mode.

Why has it stuck with Emacs and its derivatives? I don't know. It seems interest in investing time to make a good Lisp environment for a non-Emacs editor fizzles out once it gets to the difficult part of productionizing it, which is why Emacs continues to be the #1 no-cost choice.

reikonomusha

3 months agodiscuss

"It should be easy enough for" sets a UX bar, not a target audience. Kind of like the English phrase "X is so easy that even a toddler could do it," regardless of whether such a statement is figurative or literal.

reikonomusha

3 months agodiscuss

For historical interest, Lem did used to advertise itself as a Common Lisp development tool specifically, but that has changed relatively recently (past year?). From my distant vantage point, it looks like general interest in it grew, and Lem itself evolved in general-purpose directions, so they pivoted the messaging to be about it serving as a general-purpose editor instead of one just for Common Lisp.

reikonomusha

3 months agodiscuss

Something like SLIME isn't essential to execute Lisp code, you're right, but it is essential in order to understand the efficiencies afforded by interactive development, which may as well be one of the pillars of the language, since "garbage collection" and "an object system" aren't in and of themselves differentiators anymore*. Using something like SLIME also takes a lot of the pains that people have with Lisp away, namely balancing parens and indenting code correctly. People who do the "I'll use my own editor" approach to beginning Lisp usually write things that look like:

    (defun myfun(x)
        (let (x)
             (setq x 5)
              (when (eq x 6)
                  (print "6")
             )
         )
     )

Which is absolutely not what Lisp code should look like. Emacs-and-kin don't outright stop that, but the defaults are such that it's less likely.

____

* Of course, technically, CLOS is something to behold. But you won't sell someone on Lisp because it can do "OOP".

reikonomusha

3 months agodiscuss

Coalton is also a full-featured embedded language of Lisp that is sufficiently paradigmatically different than run-of-the-mill Lisp code you'd see in a Common Lisp textbook, since it has a complete, Haskell-like static type system and Lisp-1 naming. Coalton also sees active development because aspects of the language continue to evolve.

The consequence is that an integration with SLIME would have to be a very extensive contrib [1] that is shipped with the Coalton version the user is using, and updated whenever Coalton is updated. No doubt the contrib would have to be very elaborate—it would have to hook in to basically every aspect of SLIME and SWANK if it should be "Coalton-native", from the display of type errors to how auto-complete is handled. Unless the contrib author is very meticulous about backward compatibility, then version mismatches would make everyone involved unhappy. The contrib author would get annoyed at constant bug reports about things not working (even if there's a nice "your Coalton or contrib are out-of-date" error), and users would get annoyed they have to keep a Lisp library in sync with an Emacs add-on.

None of this gets to the matter that Emacs simply isn't a popular text editor, and it's not really the one people are rushing to learn, even if it has substantial merit. I don't know how trustworthy this source is [2], but it claims that Emacs represents a fraction of a percent of the developer community. Even if it's off by 10x, it's still 1-in-50 developers at best.

[1] There's a basic one that shows Coalton type hints, but not much more: https://github.com/slime/slime/blob/master/contrib/slime-coa...

[2] https://pypl.github.io/IDE.html

reikonomusha

3 months agodiscuss

Not that I've seen.

reikonomusha

3 months agodiscuss

It is not known, and the model problem for this is Hilbert's 13th [1].

Nonetheless, "elementary function" is a technical term dating back to the 19th century; it's very much not a general adjective whose synonym is "basic".

[1] https://en.wikipedia.org/wiki/Hilbert%27s_thirteenth_problem

reikonomusha

3 months agodiscuss

You can calculate, measure, draw, construct, write a power series for, express as hypergeometric function, etc. the Bring radical too.

All of these concepts, from sine to real numbers, Bring radicals to complex exponentials, can all be defined in different, equivalent ways. What is interesting are the properties invariant to these definitions.

It still doesn't seem to me that a square root should be any more or less contrived than a Bring radical. Maybe we should call it a ultraradical instead?

reikonomusha

3 months agodiscuss

The Bring radical has a great geometric interpretation: BR(a) is where the curve x^5 + x + a crosses the x axis.

Like sine or exp, it also has a nice series representation:

    sum(k = 0 to inf) binom(5k,k) (-1)^(k+1) a^(4k+1) / (4k+1)

We can compute its digits with the very rapidly convergent Newton iteration

    x <- x - (x^5 + x + a)/(5x^4 + 1)

and so on.

Why not invite it to the table of functions?

Ellipses are simple and beautiful figures known to every child, but why do we rarely invite the elliptic integrals to the table too?

I guess my point is that "nice geometric interpretation" is a little subjective and hasn't led to much consistency in our choice of which functions are popular or obscure.

reikonomusha

3 months agodiscuss

Not a typo! Think of f(x) = x as a seed function that can be used to build other functions. It's one way to avoid talking about "variables" as a "data type" and just keep everything about functions. We can make a function like x + x*exp(log(x)) by "formally" writing

    f + f*(exp∘log)

where + and * are understood to produce new functions. Sort of Haskell-y.

reikonomusha

3 months agodiscuss

To be fair to Spivak, he did say it was comprehensive introduction. :)

reikonomusha

3 months agodiscuss

EML can represent the real absolute value, so long as we agree with the original author's proviso that we define log(0) and exp(-∞), by way of sqrt(x^2) as f(x) = exp((1/2)log x). Traditionally, log(0) isn't defined, but the original author stipulated it to be -∞, and that all arithmetic works over the "extended reals", which makes

    abs(0)
    = f(0)            ; by defn
    = exp(1/2 log 0)  ; by defn
    = exp(-∞/2)       ; log 0 rule
    = exp(-∞)         ; extended real arith
    = 0               ; exp(-∞) rule

If we don't agree with this, then abs() could be defined with a hole punched out of the real line. The logarithm function isn't exactly elegant in this regard with its domain restrictions. :)

reikonomusha

3 months agodiscuss

This fundamental "cheat" gave rise to some of the most important pure and applied mathematics known.

Can't solve the differential equation x^2 - a = 0? Why not just introduce a function sqrt(a) as its solution! Problem solved.

Can't solve the differential equation y'' = -y? Why not just introduce a function sin(x) as its solution! Problem solved.

A lot of 19th century mathematics was essentially this: discover which equations had solutions in terms of things we already knew about, and if they didn't and it seemed important or interesting enough, make a new name. This is the whole field of so-called "special functions". It's where we also get the elliptic functions, Bessel functions, etc.

The definition of "elementary function" comes exactly from this line in inquiry: define a set of functions we think are nice and algebraically tractable, and answer what we can express with them. The biggest classical question was:

    Do integrals of elementary functions give us elementary functions?

The answer is "no" and Liouville gave us a result which tells us what the answer does look like when the result is elementary.

Risch gave us an algorithm to compute the answer, when it exists in elementary form.

reikonomusha

Submissions

Dotcl: Common Lisp Implementation on .NET

Almighty Lisp

comments