Nah, but I can ELI a person with some programming experience.

Pattern matching is super useful for writing code that spends a lot of time building and deconstructing syntactic data structures.

Non-linear pattern matching is useful when de-constructing large-ish expressions that might contain multiple occurances of the same sub-term.

Nonfree datatypes allow you to encode some constraints about your datatypes; e.g., "lists that are equal modulo permutation".

Supporting type-checked non-linear matching over nonfree datatypes allows you to encode a lot of constraints in the type system and syntax that would otherwise be encoded with lots of nested if-statements and only checked by tests, not by static type checking.

This combination of features could be very useful when implementing a lot of mathematical code that operates over algebraic structures. Which is why the language's homepage mentions the implementation of (features for) computer algebra systems as a sort of killer app.

> this is not a business pain, this is an academic interest

Not all innovation is motivated by the business pains of today's engineering managers. And often the solutions to those pains are not recognizable; e.g., thousands engineering manager in 1950 could've beneifted from CAD software but I bet very feew were sitting around saying "I could really use a good piece of CAD software right now".

Scala is another good example of that, despite a marketing complaints about messaging. No one asked for FP+OO, but Scala took off because the combination of FP and OO solved a lot of the pain caused by Java.

Substantially improving the ease of implementing new types of computer algebra systems could easily create a lot of business opportunities e.g. in providing improved analysis/synthesis tools for all sorts of CAD tools.

that said, I don't think this language hits the target. See the hodge operator example...

Egison appears to be a self-consciously academic language, which strikes me as a perfectly legitimate.

In particular, the goal seems to be to provide a more intuitive way of writing algorithms using extensible pattern matching. Now, I have worked on commercial software that has highly algorithmic parts (graph traversals, etc.) written in Erlang (a language that supports a powerful, but not extensible, form of pattern matching). I found the pattern matching facilities to be quite helpful in producing readable, concise, correct code.

The use case is narrow, but strikes me as real nonetheless.

It's a bit subtler than that. Scala is an industry programming language perfectly suited to business applications, but with a big academic and research input (remember that Odersky, its creator, was a big contributor to Java, an industry language) and with an initial emphasis on research. The mentioned talk is criticizing Scala's marketing blurb because it was written almost entirely from a research angle, and doesn't accurately and convincingly portray Scala's benefits for business. See the revised blurb at the end of the talk [1]. It's a question of being clever about marketing.

----

[1] revised blurb: "Scala is an open source programming language that helps you write correct code and modify code safely, while seamlessly reusing existing JVM libraries."

Egison features a customizable pattern-matching facility. Pattern-matching methods for each data type and pattern can be customizable by users. There might be a possibility that you thought syntax sugar is not syntax sugar.

This language is clearly an academic endeavor.

Disclaimer: I don't know what non-linear pattern matching on non-free data means either, but the fact that it's not explained to me is proof enough they aren't meaning to cater to non-academic users.