John Passaniti wrote:
> On Jul 6, 11:01 am, John Doty
whispertel.LoseTheH.net> wrote:>>> In your language, you force the user
>> The *coder* has to come up with that. The *reader* benefits.
>
> I'm trying to resolve your apparent cognitive dissonance. You seem to
> believe that injecting a needless level of indirection is a good thing
> because it helps the reader. Okay, if you believe that, then one
> would expect that given that guiding principle, you would apply it to
> other code you write. But when I go through the LSE64 code, I see you
> gleefully using anonymous blocks throughout the code. So please
> explain why in C code you find anonymous blocks permissible, but in
> LSE64, you don't.
C is a language. It has a grammar. LSE64 is closer to traditional Forth:
it is effectively a macro assembler for a Forth VM. This is a
fundamental difference, and it *should* affect coding style.
>
> It would be refreshing if you just admitted what is really going on
> here. The person who benefits isn't the coder and it isn't the
> reader. It's the implementor of LSE64.
>
>>> through the distraction of coming
>>> up with a name for these two blocks of code, even if they occur nowhere
>>> else in the code. Can you point to a linguistic basis for this?
>> Not in natural language. LSE64 isn't much of a language. But in
>> mathematical exposition, short lifetime things often crop up ("dummy
>> variables", "lemmas", etc.). Readers find it useful to have names
>> encapsulate ideas even here.
>
> So LSE64 is an example of designing a language around linguistic
> patterns and insights-- except when it isn't.
Mostly not. The design of LSE64 reflects my thinking of about 5 years
ago, and my need to recover capabilities lost about 15 years ago without
expending too much effort. In that it has been modestly successful.
LSE64 is still a Forth macro assembler. It's a cleaner, simpler one than
traditional Forth, but it's still not a real language. Aleksej's
criticism applies to it too. I'm not interested in defending its
weaknesses, and given what the future looks like, I'm unlikely to find
the time to work much in the Forth world anytime soon (although I just
now received a request to give a few people at MIT an LSE64 tutorial
next month).
>
>> You need to read some Hemingway. You don't seem to understand usage of
>> short sentences.
>
> Nice way to evade the point. The point isn't the verbosity. The
> point is the structure, which if we follow LSE64's lead requires two
> definitions (action for buying cookies, action for buying ice cream)
> followed by a statement using those definitions.
>
>> Most English speakers would find "If they have my favorite cookies at
>> the store buy then them else ice cream." difficult (although most could
>> also puzzle it out). It's easier on the listener to speak grammatically.
>
> Weird. I wrote a perfectly grammatical sentence, but instead of using
> it in your reply, you offer that nonsense.
Weird. You advocate a lack of grammar when programming, yet an
ungrammatical English sentence bothers you. Whose cognition is dissonant
here?
> Really, there are better
> ways to win an argument than falsely quoting others.
Argument? Is that all you care about? Argument is useless. But you can
learn from discussion: you might note that my thinking has evolved
considerably over the last few years.
>
>> Do we want to write code to be read or to be puzzled out?
>
> It's interesting that your take on readability (in this specific case)
> is to force the user to *add* abstraction when none is needed or
> desired. What I think would be the test here is actual code from
> *users* of your language. I fearlessly predict that if we could step
> through source from your users, we would find definitions like this:
>
> : a-b a b
> condition if a-b
>
> Forgive any syntax error. In other words, I'll bet your users have
> code where they have named a definition not with some evocative name,
> but with a concatenation of the words of that definition. And they
> did this because of two reasons-- because they couldn't come up with
> an evocative name, and more importantly because a name didn't help
> them do what they wanted.
Could be. Still, breaking things down has advantages. It's nice to have
a nice, clean, instantly recognizable container for an anonymous block.
C accomplishes this grammatically with { and }. Successful languages
have found it nice for the grammar to modestly constrain what can go
into the block.
>
> Funny, when I last looked at the source code for LSE64, I didn't have
> much problem "puzzling out" your anonymous blocks. Why is that?
Because C has grammar. That's extremely helpful.
> Could it be that readability isn't just about slapping a name on
> something, but includes other aspects-- visual proximity to control
> structures for one.
Study successful programming languages that have anonymous blocks. They
don't normally need anything analogous to a "stack comment". Structured
macro assemblers exist, but are little used.
A need for formal comments to elucidate what the code is doing at a low
level seems to me to be largely restricted to two special circumstances:
1. Assembly code.
2. Languages applied outside their normal domain, e.g. parsers in Fortran.
Informal comments describing usage, background, motivation, etc. are of
course always desirable.
--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
History teaches that logical consistency is neither sufficient nor
necessary to establish practical, real world truth. Those who attempt to
use logic for that purpose are abusing it.
