reikonomusha

No language magically solves the problem of organizing code without leadership. Python, C++, etc. all suffer just as much, if not more.

Modern LLMs have absolutely no issue with writing reasonably good Common Lisp without a kilometer of prompts. It's true that you did need this a year or two ago, but not anymore. In fact, LLMs can even write Coalton pretty well if you prefer strong, static typed all the way through.

Lisp isn't some language wild west lacking style and idioms—regardless of whether there's a "go fmt" for it or not. Most open source Lisp code is quite standard and "boring": functions and classes/structs following canonical indentation.

Ah, that makes sense. I read the original comment, "you can define them," as meaning one can add static types to Common Lisp programs. But designing and building entirely new systems, at least ones that should work for a large class of practical programs, is not easy. I agree with you then.

I don't consider it "technically true".

1. Common Lisp has a whole system for defining and declaring types, and implementations do actually use this information to produce safer and higher performing code, including some amount of static, compile-time verification (e.g., you can get "expected an INTEGER but got a STRING" styles of compile-time errors). Fast, competitive-with-C floating-point math is achieved this way. DEFTYPE/DECLARE work.

2. If you prefer a system that doesn't feel like a 1980s barebones type system (i.e., Common Lisp's), then you can use Coalton [1] which adds types to a Scheme-like DSL within Common Lisp, but has a type system like Haskell's (similar to stock GHC + common extensions). Multi-parameter type classes, monomorphization, functional dependencies, etc. Yet it's still fully interoperable with Lisp code, uses the same Lisp toolchain, same Lisp compilers, same Lisp editors, etc. so it really isn't just a language atop Lisp, but something that's integrated within it.

[1] https://coalton-lang.github.io/manual/

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.

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.

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

Lisp is traditionally not so terse, but still expressive.

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

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

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

<meta>I've noticed this more recently on HN. Either the top comment has to be some negative sentiment even if seemingly good-faith, or a comment on something completely tangential (like the color of the website), or a comment on their own project that's related to the thing posted but it feels more like look-at-me advertising rather than earnestly engaging with the submission. Some of these go against the guidelines, but maybe my own comment here does as well.

As of writing, the top comment is "Why?" like the project has to defend itself, on a website that's notionally about curious, interesting, and insightful discussions.</meta>

I used Notepad++ way back when, sort of before I "graduated" to Emacs and the like. I don't know how it's evolved over the past two decades (I presume, intentionally, not much) or what attracts its fanbase anymore. I know I liked it because it felt like a substantial jump from notepad.exe without feeling bloated and slow. At the time, some of the competition felt sluggish while Notepad++ felt nimble.

What do people love about Notepad++ that still isn't really addressed by the "less humble" editors out there?

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.

"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.

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.

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".

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

Not that I've seen.

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

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?

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.

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.

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

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. :)

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.

You are correct, it is undecidable by Richardson's theorem [1].

[1] https://en.wikipedia.org/wiki/Richardson%27s_theorem

Arnold (as reported by Goldmakher [1]) does prove the unsolvability of the quintic in finite terms of arithmetic and single-valued continuous functions (which does not include the complex logarithm). TFA's result is stronger, which is something about the solvability of the monodromy groups of all EML-derived functions. So it doesn't seem to be a "rehash", even if their specific counterexample could have been achieved either in fewer steps or with less machinery.

[1] https://web.williams.edu/Mathematics/lg5/394/ArnoldQuintic.p...

Wikipedia says:

> More generally, in modern mathematics, elementary functions comprise the set of functions previously enumerated, all algebraic functions (not often encountered by beginners), and all functions obtained by roots of a polynomial whose coefficients are elementary. [...] This list of elementary functions was originally set forth by Joseph Liouville in 1833.

which seems to be what the blog post references.

As is usual with these kinds of "structure theorems" (as they're often called), we need to precisely define what set of things we seek to express.

A function which solves a quintic is reasonably ordinary. We can readily compute it to arbitrary precision using any number of methods, just as we can do with square roots or cosines. Not just the quintic, but any polynomial with rational coefficients can be solved. But the solutions can't be expressed with a finite number of draws from a small repertoire of functions like {+, -, *, /}.

So the question is, does admitting a new function into our "repertoire" allow us to express new things? That's what a structure theorem might tell us.

The blog post is exploring this question: Does a repertoire of just the EML function, which has been shown by the original author to be able to express a great variety of functions (like + or cosine or ...) also allow us to express polynomial roots?

Combinations of the NAND gate can express any Boolean function. The Toffoli (CCNOT) or Fredkin (CSWAP) can express any reversible Boolean function, which is important in quantum computing where all gates must be unitary (and therefore reversible). The posited analog is that EML would be the "universal operator" for continuous functions.

The definition of "elementary function" typically includes functions which solve polynomials, like the Bring radical. The definition was developed and is most fitting in algebraic contexts where algebraic structure is meaningful, like Liouvillian structure theorems, algorithmic integration, and computer algebra. See e.g.

- Page 2 and the following example of https://billcookmath.com/courses/math4010-spring2016/math401... (2016)

- Ritt's Integration in Finite Terms: Liouville's Theory of Elementary Methods (1948)

It's not frequent that analysis books will define the class of elementary functions rigorously, but instead refer to examples of them informally.