Egison seems to introduce some kind of advanced pattern-matching syntax with $ and #. I can't figure out what it is, or how it works; but I imagine it's quite simple once you actually know what it means.
Maybe this language is simple to write if you know the rules. It won't be easy to read, ever, not even if this is the only language you have ever learned and practiced for decades.
The first part isn't notable. Olympian athletes, for example, do the most baffling of intricate movements in grace and simplicity. Instead it's the amount of effort and context to get to the understanding that's at play.
Maybe this syntax is intuitive for a mathematician, formal logician or some other specialist, but as just a mere every day programmer, it looks like nothing I'm familiar with.
This is fine. Just let's not pretend that it's low effort to get onboard
The lack of requirement of mechanically verifiable proofs and adherence to common standards of expression of mathematical concepts is a huge drawback of what happens in this area of academia.
People who come up with languages like Haskell (which this one certainly is) are people who want the absurdity of languages created w/o system or any general design to spill over into the programming land. Solely based on the fact that they've been exposed to this cuneiform during their apprenticeship and learned to associate it with the actually valuable stuff it's meant to convey.
(minor correction, as tromp points out, :: is evidently list construction, as in ocaml or haskell, not a type annotation)
you asked what `matchAll primes as list integer with` meant ('what is the second line, a comment?') but apparently the person who answered you didn't understand that you didn't understand. it means 'evaluate the expression `primes`, which should have the type `list integer`, and then attempt to match the value resulting from that evaluation against each of the following expressions in order'
deep math isn't simple to do even when you know what it means; it isn't just a matter of learning what all the symbols mean. this is just a matter of learning what all the symbols mean, like reading english instead of chinese. so to me your complaint reads like someone saying (in chinese) 'just a mere every day reader of novels, it looks like nothing I'm familiar with' because some text is written in english
however, the situation is not quite so symmetric as with chinese and english. with a good notation, cramming lots of symbols onto a line is a really good lever to empower your reasoning ability. consider trying to explain how to play the seventeenth measure of pachelbel's canon in words. or writing assembly instead of c, even though they're both at pretty much the same level of abstraction
pattern-matching really significantly improves the clarity of certain kinds of code, and you're missing out if you don't know what that's like
i'm guessing that #() (the only weird part) is analogous to ${} in `-strings in javascript or #{} in ""-strings in ruby: it embeds an expression to be evaluated in a context where you wouldn't normally expect expression evaluation, in this case a pattern for pattern-matching
(disclaimer, i don't actually know haskell, though i've implemented my own programming language featuring pattern-matching)
I just happened to agree with the sympathies of the first person and was trying to rephrase things in a more productive and positive manner.
I appreciate the response not only for myself but for others who may be reading it as well. Thank you for taking the time.
They aren't.
(=<`#9]~6ZY327Uv4-QsqpMn&+Ij"'E%e{Ab~w=_:]Kw%o44Uqp0/Q?xNvL:`H%c#DD2^WV>gY;dts76qKJImZkj
Look at how compact that is! Must be simple!
You can't claim simplicity by using character or line count.
It's the reason Haskell has remained a niche language.
> I can't figure out what it is, or how it works; but I imagine it's quite simple once you actually know what it means.
You can't figure it out but you're sure it must be simple?
Newsflash: if you, a 1 in a 500 programmer who knows Haskell syntax cannot figure it out just by context, it's nowhere near simple.
Simple is when 9 out of 10 programmers understand the thing.
(By the way, any talk by Rich Hickey is worth watching)
it's true that using a word with multiple meanings gives rise to ambiguity, and avoiding that by choosing a different word is desirable
unfortunately there isn't a better term for 'simple' in the sense of 'not possessed of much detail' or 'composed of very few parts'; saying 'non complex' doesn't really help because 'complex' is often used to mean 'difficult' for the same reason 'simple' is often used to mean 'easy'
except in hucksters' advertising brochures, i don't agree with your implicit assertion that all the polysemic complexity of 'simple' is merely historical, leaving only 'easy' as a live meaning; i think all the meanings i listed above except for 'harmless' have some currency today, even merely in english
https://en.wiktionary.org/wiki/simple#Adjective lists nine main meanings of which seven are current, though i admit i just added the 'easy' one myself; it wasn't listed previously (i think because of confusion induced by the polysemy of 'complicated')
Look at this comment thread and count all the instances where people are complaining that 'simple' is being used to describe difficult things:
https://news.ycombinator.com/item?id=35759449
I'm not the only one who thinks that 'simple' should mean, in technical docs, 'easy'.
But there are some things that are just simple, like a Bankers Box.
we could try defining a new word for specifically this sense of 'simple'. for example, 'fivous', 'blorsy', 'bonatchy', 'jatomurous', or 'wislous'. the problem is that if the word gets adopted, it's likely to undergo the same sense shifts as its synonym 'simple'