Re:The Egison Programming Language
by throwawayjava on Friday July 13, 2018 @03:32PM
(#17525974)
> It's a what? Can someone ELI5 this for a lowly Python and JS dev - why would I want this?
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...
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...