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.
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
(minor correction, :: 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 chinese instead of 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
i'm guessing that #() (the only weird part) is analogous to ${} in `-strings in javascript or "-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.
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.
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.
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')
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'
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'.
(By the way, any talk by Rich Hickey is worth watching)
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.
do what? write programming languages that you don't already know?
>> do what? write programming languages that you don't already know?
> Investing so much creativity into obfuscation of meaning.
that's just saying the same thing in different words. of course the meaning is obfuscated to you, you don't know how to read it.
I can still read ruby code, because it's still readable. Same with Lisp, which I never bothered to sit down and learn until about a year ago. Prior to that, I still had no problem reading and understanding it (perhaps not as intuitively as someone who writes it regularly).
The quoted example is, for all intents and purposes, gibberish to me. And I have worked with CoQ.
Ruby still has algol-like structure, like most common languages. And basic lisp syntax is "normal" function calls with the parens moved around.
Of course, some things are objectivly more complex than others, but making that argument here requires a bit more evidence.
My advice to any language designer aiming to mainstream status is to copy some curly braces language (Java, JS, C++) or Python. Then do any weird thing to them, but don't scare away millions of developers with your hello world.
Another aspect / problem: humans vocalize (well, adults, usually, using their "inner voice") anything they read. This is why, for example, people deaf from birth struggle more with reading comprehension. So, when programmers read programs they use some made up language to read it out loud to themselves. When a language is just a string of punctuation / non-typographical symbols it's a struggle for any human to read it to themselves in any way that they could process it.
Try it yourself:
Pipe underscore increment dollar pie colon colon hash open paren...
Probably, with some experience, it will be more like
Pipe unimportant list-add variable pie namespace hashtable with arithmetic expression?
In other words, this is not a language anyone would use in a setting where they just need a computer to write useful programs. This is a crypto-arithmetic puzzle for people with too much time on their hands.
Not necessarily, e.g.:
> Hurlburt … estimates that inner monologue is a frequent thing for 30 to 50 per cent of people. [https://www.cbc.ca/news/canada/saskatchewan/inner-monologue-...]
For myself, I rarely read out Haskell code ‘literally’ (to the extent that I read any code literally at all; I’m not sure I have much of an internal monologue). Instead I tend to perceive it at a higher level: say, ‘modify a state variable s to fromMaybe s (f s)’ for ‘modify $ \s -> fromMaybe s (f s)’. Reading it out character-by-character would be as pointless as reading an ordinary word that way, like reading ‘cee-aye-tee’ instead of ‘cat’.
His research convinced me that any tool that wants to parse any spoken language absolutely has to incorporate vocalization information. Also, it convinced me that while it's possible that some people (esp. deaf from birth) can learn alternative ways of reading that don't involve vocalization, these are unnatural for humans, hard to learn and have poorer yield.
So, yeah, maybe some people don't read their code out loud to themselves, but most do, and for most of those who do this makes things easier. So, even if there's a way around it, it's not worth considering when we are talking about ease. People who don't do it are "playing with a handicap", they aren't in the competition for the easiest way to do things.
Also, I'm not convinced that having an internal monologue is the same as reading text using inner voice. Most people learn to read by first reading out loud, and only later learning to use inner voice. Only few people continue on to learn advanced reading techniques which allow to skip selectively and to perform some other mental manipulations on the text, but these techniques also often involve some internal vocalization, but it wouldn't produce the equivalent of speech. More like how people who have to control their computer with voice commands learn all kinds of shortcuts / ways to invoke functionality hard to describe using regular speech elements with clicking noises, whistles etc.
The question of "useful" is good. Useful for what? There are lots of different needs and purposes in the world.
Now CAR and CDR don't convey a lot of meaning I agree. But that's just a matter of poor naming. They should (in my opinion) be called 'first' and 'rest', or something similarly meaningful and descriptive.
Of course short-hands and aliases are good for most often used functions. But I would prefer those to be aliases, with a proper descriptive name available as well.
And operator precedence, that makes code in a different language really hard to understand. Parenthesis make it explicit. Keep it simple. That makes code more verbose but then you can use macros to make it less so.
Some Lisps do that, but I think it's important to remember what CAR and CDR actually do, which isn't always related to lists: They access what's being pointed to by the pointers in a cons cell, which can be used to create multiple data structures in a given Lisp, so keeping the names abstract prevents the code from having the wrong names all over the place. For example, if I'm using cons cells to construct a key-value store, CAR isn't "head of list" it's "key" and CDR isn't "tail of list" it's "value" especially if the cons cell looks like this: (a . b) such that the CDR isn't a list of any kind.
In Common Lisp, of course, there are more efficient data structures for a lot of what older Lisps used cons cells for, so this is less of a concern, but I still think it's important to prevent confusion.
But I do think using a natural-language name like CAR even if very specialized, is better than using single-char symbols as function names.
My point is that they can be used in many different ways, and are, such that any mnemonic name would be misleading in some contexts.
Without working in in Lisp solidly for a good 6 months, you don't know where the actual pain points are.
Mainly people sometimes report things lacking in the ecosystem. The number of people doing any kind of Lisp are relatively small.
If you're doing FOSS, you might find it hard to get collaborators and pull it solo.
When you see car, cdr and other related functions in Lisp code, it communicates that the code has strictly a physical interpretation, using well-known, decades-old idioms. You know exactly what it's doing with what kind of structure, and you know not to try to read any meaning into it. As to what that structure represents, what it's being used for, you have to look elsewhere; those names don't give that away. But to a Lisp hacker, spots in a program littered with car/cdr/cons/caddr/... are comfort zones.
It's good to have one set of names for this "just structure, no meaning" stuff and stick with them, than to go inventing new ones. That's more important than their specific choice. There is no end to what a cons-cell-based structure can mean, and so no end to the potential sets of better names for its parts; it's best to leave that to individual programs.
It's good that the names are short. MacCarthy saved us from awful ones. Before Lisp, there was a project called FLPL: Fortran List Processing Language. The names came from that, but in that project, for some inexplicable reason, they had XC ... RF prefixes and suffixes: XCARF, XCDRF, ... MacCarthy had the presence of mind to shorten the insane naming scheme, but not all the way to just A, D.
Mainstream Lisp dialects like Common Lisp have first and rest. Plus other names like second, third, as well as numeric indexing into a list. These names are still meaningless with regard to what a list is used for. first is no more informative than car about what is expected to be first; it's only clearer to complete neophytes who haven't gone through the 15 minute tutorial on car and cdr.