Re: Verbose functional languages?

Ingo Menger <quetzalcotl@xxxxxxxxxxxxxx> writes:

And how exxctly would it help you if the language looked like english,
but wasn't actually english?

The same way knowing a smattering of Bulgarian helps me listen to
Russian, Czech, and Polish dialogue (all Slavic languanges, but each
distinct enough that speaking one does not let one *speak* another).

Some words are cognates and they help--especially since they are all
languages suited to the same purposes. One forms a thesis with the
words one recognizes (or thinks one recognizes), and looks up unknown
words to see what they mean. Eventually, if the two sides are *trying
to communicate*, they find a pigeon language with a subset of the
meanings that both can understand that gets across the barrier and
conveys the intended meaning. If the meaning is all tied up in subtle
declensions, inflections, word order tricks, homonyms, puns, etc., it
will get lost--so jokes don't generally translate well. And that's
the spoken equivalent of enigmatic notation. If you want to speak to
just a closed group, use a complex notation. If you want to address a
wide audience, use simple forms and simple concepts and let the
message carry itself.

"Ich bin ein Berliner." was incorrect, but it got the message across.
I don't speak enough Deutsch to correct it, but if I saw a similarly
short and correct version of the sentence, I would understand it.
And, so all reading goes. If the writer is attempting to communicate,
the reader needs to know less of the subtleties of the language to
understand. But if one hides the meaning in subtleties, e.g. if the
statement would have been correct as "Ich werde ein Berliner" or "Ich
wunsch ein Berliner" and then written "IWEB" and "IweB", you are
quickly likely to lose ones readers.

BergwachtVereinigungsVorsitzendenEntschädigung
BergwachtVereinigungsVorsitzendenEntscheidung

I *can* look up Entschädigung and Entscheidung. I cannot look up BVVE
and know which of those two you mean. If it makes a difference, and
you wish to communicate, you make the difference clear and obvious.
If it doesn't make a difference, then no one cares.

I don't think this will work. This is my opinion only, of course.
On the ground of each PL lie exactness and formal rigor as well as
certain fundamental concepts. I doubt the possibility to make the
required understanding easier through relaxed syntax.

As Rainer Joswig understood:

R> He does not want relaxed syntax. He wants explicit code with
R> named constructs that appear in the code.
R> Not syntax by white space or cryptic letter combinations.

Yes, I do not want to abandon formality. Formality is good. I would
much rather communicate in grammatically correct sentences, because
doing so helps me convey my meanings better. Moreover, I like
explicitness. I often have to correct my wife when she uses a pronoun
in a sentence with no obvious referent "that???, that what?, what
'that' are you talking about?". I know she knows her topic, but I
don't know the stuff in her mind and if she doesn't tell me, I'm lost
in the conversation.

An illsutration: Take for example cooking receipts. If it were so that
merely use of natural language does the trick, we all could be great
cooks by just working down the receipt. Yet, the fact is that many of
us are miserable cooks (or do not cook at all), despite having access
to the finest receipts.

Perfect example. You right we are all not natural cooks, never will
happen. I don't expect everyone to "write" fp programs. However, a
good French cook can read a recipe for a Chinese dish and probably
make a passable rendition, despite not being familiar with the
cuisine. That's the reading skill I'm interested in. The French cook
is unlikely to succeed if the Chinese recipe hides its assumptions,
e.g. when I say chicken, everyone knows I mean hang the chicken out in
the window with these spices for three days before starting.
Especially if that is encoded as "Chicken" as opposed to "chicken".

Is this so? How about anonymous functions with two arguments?
"function (x) is function (y) is" perhaps? And for what reason do we
need the () parentheses?

Because a naive reader will expect them, a naive reader may never have
seen a function without the arguments enclosed in parenthesis.
Removing the parenthesis is excessive terseness in my book. Making
them optional, allows those of us who want to communicate with a wide
audience put them in, and that's ok in my book. I want to be able to
write verbose programs so that I can reach an audience who may not
understand my field. You may not have that goal.

I personally think that especially the Haskell syntax is so terse
because it abandons lots of braces, semicolons and parens that
dominate the look of program texts in other languages. And I think
it's a good thing.

Good for you. Not good for me.

I don't see that. The "more verbose notation" would still have to
convey the exact meaning.

Yes, the exact smae meaning.

From our experiments here in this thread we
know, that expressing functional programs in "natural" like languages
is not per se promoting understanding.

We do not "know" this, and I reject this claim. In fact, the
axiomatic basis of this thread is that verbose languages have a use.
You may not need that use, but I do.

You'll have to have some formal notation anyway.

Formal is good. Terse is what is not good in my book.

Once we realise this, we can as well choose one that
is consistent and easy in itself, i.e. governed by few rules only. (I
know this is vague, for this also applies to languages like brainf*ck
or unlambda. Perhaps in the latter cases there are too few rules.)

Consistent is good too. Simple in general is good. Simple is not
necessarily terse. More characters is not necessarily more complex.

Yet, I admit, such a program reader could be a useful tool for
beginners.

Or those of us who just want to read a text in a language we don't
know.
.

Loading