Array of struct And to And onto and ...

Scott Raney raney at metacard.com
Tue May 28 11:50:01 EDT 2002


Jean-Michel Lekston <jm.lekston at idvector.com> wrote:

> There is common mistake to think that computer language must be as near as
> possible to human pratical language.

It's also a common mistake to forget to take into account the
operation of the human brain, which remembers things tied to everyday
language far better than it remembers abstract symbols.  The advantage
to having an English-like language is that it's easy to remember
things like the names of commands and the order of parameters so you
don't have to spend all your time looking these things up like you do
with most other languages.

> A computer language is more formal
> (mathematic) than natural (english). In french we have two words to
> distinguish this two practises:
>  Natural language  are "Langues" or tongue if you want and  formal are
> "Langage" or language.

> They are very differents.(shortly) Formal is used to express logical
> assertion. Natural language is used to express evrything else
> (shopping, poetry,football narrator,...) , due to this king of
> pollution natural language is not adapt to express logical
> assertion, this is why one developped formal language. Physics law
> (mecanics law, electronic law) seems to fit this kind of language,
> so computer , wich are an electronic state of nature, are well
> discribe by formal language.

Right, which is why users manuals for all types of devices from cars
to consumer electronics are written in this "formal" language (no
wonder no one can program their VCR ;-)

Wouldn't it be better if the language was more intuitively obvious?

> But for human interface, one try to build "advanced" language
> (modular, human readable ...) to describe algorithm. C,Java,python,
> perl ... Are samples of powered formals languages (easy to read,
> short expression, reuse, portable ...) and they are not necessarly
> near to a particular natural language.

I love the one about Perl being a "write only" language.  Six months
after you write something, you come back and can't figure out what the
hell it does.  If your argument were valid, we'd all be programming in
Forth or APL, both of which are even more elegant and "formal" than
any of the languages you mentioned.  But as it turns out, formality is
far less important than things like learnability, usability,
portability, reliability, and productivity.

> The readablity of a code source depend more on write convention,
> documentation and words  choose  than on the grammar.

Perhaps, but only if you're a complete master of language and all its
idioms (i.e., many, many years of experience).  For anyone with less
experience, grammar, and more importantly freedom from idiom, makes a
huge difference even for readbility, though productivity is influenced
even more by this.

> I said that X-talk (aka hyper-talk) is poor (not powered computer language)
> because it is very constrained one.
> What about structure ? (Or Class in object point of view)
> What about references
> What about memory managing?
> What about Multi-threading ?
> What about paradigm (event-drive, procedural, GUI oriented.
>  why stacks, groups, cards are fixed => Closed API...  ?

I think Geoff answered these specifically well enough, but I'd like to
add that making a feature-based comparison at this level is
horse-and-buggy thinking.  It's as if you wanted to know how many
spokes or what kind of wood was in used to make the buggy's wheels or
what shape the nails in the horseshoes are when everybody else is
driving around in something with completely different concerns (like
"how fast can it get me from point A to point B").

> Is - there a well defined grammar rules (as we can find for most of
> language) ?

Yes.  There's one in the back of "HyperTalk 2.2" with the bulk of the
language in it.  I've also seen one posted electronically (maybe from
the freecard/opencard group?)  That I could dig up if you really need
one.

> In fact i preferred said that x-talk (hyper-talk) is a simple
> script/macro language for event call-back of a GUI RAD

I disagree: xTalk is a high-level language well suited to most
application development, if not for bit-fiddling with low-level OS and
hardware features.  While it's true that you give up some performance
and flexibility using a high-level language, you more than make up for
this with increased productivity.  Note that I'm not criticising C/C++
here: I think it's a great language and that everyone should learn it.
But even if you know it, you still will end up writing most of your
application in xTalk because you'll find, as we have, that that's the
best way to do it.
  Regards,
    Scott

> JML

********************************************************
Scott Raney  raney at metacard.com  http://www.metacard.com
MetaCard: You know, there's an easier way to do that...





More information about the use-livecode mailing list