Re: Pointers to "why C behaves like that ?"

On 1 Dec 2002 22:41:27 -0500, Fergus Henderson wrote:
>"Roman Shaposhnick" <vugluskr@unicorn.math.spbu.ru> writes:
>
>>On 24 Nov 2002 18:38:19 -0500, Joachim Durchholz wrote:
>>>Hindley-Milner typing is simple and efficient.
>>
>> So, what I'm really saying is, that while dynamic typing is great
>> in theory, I have yet to see a nice practical implementation,
>> suitable for big software projects.
>
>Firstly, your terminology is confusing -- Joachim was talking about
>languages which support automatic compile-time type inference, such as
>Haskell, Ocaml, and Mercury, not about languages with dynamic
>(run-time) typing, such as Lisp, Perl, and Prolog.


  For one thing, we were talking not about specific languages, but
  Hindley-Milner typing. And, somehow, until proven otherwise
  I still consider it to require run-time support. But I could
  be wrong here. So, let's put Haskell, Ocaml, and Mercury aside
  for a moment -- I wasn't talking about them.


>Secondly, I don't understand what you mean by Oberon or Java making
>themselves a lowest common denominator. Are you unsatisfied with the
>ability of these languages to interface with other languages?


  Yes, but that's not it. I'm not satisfied by the fact that they require
  an "environment" to be run in, like JVM for example. Now, consider, for
  example debugging a web service written in Java, that calls native
  methods. To make things even more exiting let's say that the server
  itself is written in Java. Here, you have threee layers of different
  environments stacked together, and when you're trying to flow with
  the code in a debugger, you feel like a tourist who is constantly crossing
  borders of the mutually hostile countries. Not much fun, believe
  me. Sadly, than in 21st century this setup still requires printf()-style
  debugging.


  Now, if everything was written in languages that has no "environment"
  and have "hardware" as a lowest common denominator, I'd have no problems
  jumping from one component to another. And I'd feel much more comfortable,
  realizing that I understand what's going on. Compare this with Java,
  where you have virtually no control over such components as garbage
  collector and we all know how this can play dirty tricks one unsuspected
  program.


>IMHO languages like Haskell, Ocaml, and Mercury are very suitable for
>big software projects. These languages all have module systems and
>have implementations with at least some degree of support for separate
>compilation. Furthermore, they have quite sophisticated mechanisms for
>code reuse, which is invaluable for big software projects. The support
>for automatic type inference in these language scales well.


    I do not have extensive knowledge of Haskell and I don't know
    Ocaml and Mercury at all, so I can't really comment on that,
    plus I'm still waiting for an original article of Milner.


    It would be nice to continue this discussion sometime, when I feel
    more acquainted with these languages but for now, my comments are
    still valid for the languages I have an experience with.


Thanks,
Roman.

Return to the comp.compilers page.
Search the comp.compilers archives again.