Jean-Michel Lekston <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://www.metacard.com MetaCard: You know, there's an easier way to do that... _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution