On 5 Dez., 16:50, Chris F Clark
shell01.TheWorld.com> wrote:> Ingo Menger
consultant.com> writes:>> On 4 Dez., 22:27, Chris F Clark
shell01.TheWorld.com> wrote:>
>> And that's exactly why the code is better *readable*, but reading and
>> understanding are different things, so it's not better understandable.
>> On the contrary, IMHO.
>
> Yes, but I suspect you don't read a lot of code in languages you don't
> know. These days I spend most of my life reading and correcting
> programming in languages I have never learned.
And how exxctly would it help you if the language looked like english,
but wasn't actually english?
> My experience is most code is actually trivial and the only problem
> with it is that it is obfuscated by overly terse names and enigmatic
> notations.
Have you ever considered the possibility that longer names can be more
easily confused? As I get older, it happens more often to me, that I
stumble across some compiler message saying that some name is unknown,
and sometimes I need quite some time to figure out that I actually
switched 2 letters somwehere in a long name.
The notion that longer names make programs more readable is
fundamentally mistaken, IMHO. I hope you'll never have to maintain a
program written by someone that believes in the blessings of long,
"speaking" names, for speaking are they only if you know the langugae.
Assuming you're not a german speaker, what do you think do the
following names mean?
DonauSchiffahrtKapitänsWitwenPension
DonauSchiffahrtsInspektionsIntervall
BergwachtVereinigungsVorsitzendenEntschädigung
BergwachtVereinigungsVorsitzendenEntscheidung
>
>> But, if you really like to read such stuff, one could write a Haskell
>> (OCaml, Lisp or whatever) reader, that reads a program to you. Would
>> be nice to have when one can't get sleep :)
>
> I think that is actually part of the solution. But, you have to
> remember the title of this thread "verbose functional languages".
> There are those of us who want functional languages: higher-order
> functions, immutable data structures, garbage collectors, closures,
> tail-recursion support, etc., but we want it in a notation that we can
> take to audiences who are not mathematically adept (and perhaps not
> even particularly programming literate).
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.
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.
>
> I don't want to deny those who desire a terse notation their options,
> but we already have plenty of terse fp languages. I'm looking for an
> fp that I can take to the "unwashed" masses and which is subversively
> simple, so that they start getting the advantanges without being
> frightened off. For example, closures are trivial for "normal" people
> to understand, but introducing them with "\x ->" (presumably meaning
> lambda x maps to) is scary and off-putting for most people not
> previously exposed to those notations, whereas "function (x) is" just
> seems a lot less so.
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?
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.
>
> A truly greatly language would transparently convert between the more
> terse and more verbose notation. That way, when I'm reading code
> where I don't understand some part of the notation I can expand it to
> something that I can study without being a member of the internal
> notational cabal.
I don't see that. The "more verbose notation" would still have to
convey the exact meaning. From our experiments here in this thread we
know, that expressing functional programs in "natural" like languages
is not per se promoting understanding. You'll have to have some formal
notation anyway. 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.)
Yet, I admit, such a program reader could be a useful tool for
beginners.
