in reply to Re^2: Some Insights from a Traveler Between Languages
in thread Some Insights from a Traveler Between Languages

Well, it's easy to come up with egregious examples and show how English could have been better designed, but you overgeneralize. The fact is that we rely on multimethod dispatch all the time in any natural language, and it's just a minor lexical miracle that you don't even notice that you're using homophones with different meanings:
The chicken is ready to eat.
The children are ready to eat.
In short, you're relying heavily on MMD yourself when you use overloaded words like:
appreciate well clear product clumsy combination course as makes life handle buy should use kind argument
MMD is useful because it lets you express metaphorical correspondences. To trot out the Inkling's favorite example, a "piercing sweetness" may be neither piercing nor sweet, literally speaking, but your MMD dispatcher is even smart enough to autogenerate missing methods and dispatch to them.
  • Comment on Re^3: Some Insights from a Traveler Between Languages

Replies are listed 'Best First'.
Re^4: Some Insights from a Traveler Between Languages
by skyknight (Hermit) on Apr 23, 2005 at 22:18 UTC
    Yes, we humans do manage to deal with the vagaries of natural language, but I don't really see this fact as being a good defense of similar issues cropping up in artificial languages. Why do we have programming languages for developing software at all? It's because specifying the solutions to engineering problems is damned near impossible in English, at least when it comes to the nitty-gritty details. We need programming languages for the precision with which they allow us to specify the operation of systems. Anything that goes against this end ought to be considered a misfeature.
      skyknight wrote:
      Yes, we humans do manage to deal with the vagaries of natural language, but I don't really see this fact as being a good defense of similar issues cropping up in artificial languages. Why do we have programming languages for developing software at all? It's because specifying the solutions to engineering problems is damned near impossible in English, at least when it comes to the nitty-gritty details. We need programming languages for the precision with which they allow us to specify the operation of systems. Anything that goes against this end ought to be considered a misfeature.
      I would ask a different question: why do we have multiple programming languages at all? Rather than one, clear, precise way of specifying an algorithm, we have hundreds of them. Many people seem to think that this makes some sort of sense, that different languages do a better job on different problems and/or with different people.

      Would there be any point in having multiple programming languages if all of them were essentially the same with only minor syntactical variations between them?

      The opinion that computer languages should be based on some concept of mathematical elegance is pretty common... perl and perl alone is pursuing a different path, focusing on "expressiveness" in analogy with natural languages.

      My personal opinion is that there isn't really any proof whatsover that one approach is better than the other: demonstrating that "mathematical elegance" is best would require some very difficult social science experiments, and the guys who are proponents of "mathematical elegance" not coincidentally just want to do mathematical proofs. So instead people fall back on introspection, and it seems that some people like one way, and some like another.

      Some issues to consider (though they might be side issues):

      • The standard of writing (books and documentation) in the perl world is very high... programmers who like thinking "linguistically" also make eloquent writers?
      • The pearl at the center of perl culture is the spirit of collaboration: CPAN, perlmonks, comp.lang.perl.*, and so on. Is there a reason that this particular language has inspired this?
      • Occasionally the "mathematical" crowd take a stab at designing a language to replace "natural language". The result never seems to catch on. Look up Loglan/lojban. And maybe: "sapir-whorf", "general semantics", and "babel-17".
      I don't really see this fact as being a good defense of similar issues cropping up in artificial languages.

      The reason it is a "good defense" is because it shows that context can successfully resolve a lot of ambiguity that would otherwise have to be resolved in different ways. The advantage in artificial langauges is the same as it is in natural languages. It makes a lot of things easier to say.

      We need programming languages for the precision with which they allow us to specify the operation of systems. Anything that goes against this end ought to be considered a misfeature.

      If being explicit and long-winded is your cup of tea, that's fine. But it certainly doesn't seem to be part of the Perl culture, and I don't see it changing drastically any time soon. If you think that results in a loss of utility and is the source of misfeatures, well, all I can say is I disagree.