Re: introspection in SML

Jon Harrop <usenet@[EMAIL PROTECTED]
> writes:
> Stephen J. Bevan wrote:
>> Jon Harrop <usenet@[EMAIL PROTECTED]
> writes:
>>> You don't seem to be acquainted with the state-of-the-art in IDEs
>>> and debuggers. Try developing C# in Visual Studio, for example, and
>>> you will quickly see that it automates a lot of this very tedious
>>> work that you are currently doing by hand in SML.
>> 
>> Until and unless C# and Visual Studio can compile, build and debug the
>> Linux kernel it makes no difference to my work how state-of-the-art
>> Visual Studio is.  How is that relevant?
>
> Visual Studio is an example of functionality that you could have.

The only way I could have it is if it could compile the Linux kernel.
So let's imagine a world where Visual Studio can compile the Linux
kernel.  Now which features of Visual Studio would I benefit from?
Or a simpler test, which features of Visual Studio would help me
writing a IMAP server or an IKE daemon?


>> I use the same development environment (Emacs) to write C code and
>> SML, thus any argument you are making against SML applies to C in my
>> domain.  Perhaps the work I do lies outside of "the majority of
>> practical applications"?
>
> Definitely, yes. C and SML are hopelessly inadequate for the majority of
> practical applications and Emacs is a very poor development environment
> compared to something like Eclipse or Visual Studio.

F# is hopelessly inadequate for 100% of the practial applications I
work on.  I don't extrapolate from there to claim that F# is
hopelessly inadequate for the majority of practical applications
because firstly I have no idea how one would determine what
constitutes the majority of practical applications.  If I were to try
I'd start with the guess that the majority of Windows programs are
written in C or C++ and that going through a Linux or BSD distribution
or looking at Sourceforce and Freshmeat would show that the majority
of code is written in C or C++.  However, that would immediately
invalidate your claim.  Thus I assume you have some way of triming
away most of those programs.  Perhaps they aren't "practical
applications" or despite being written in C/C++ the language was
nevertheless "hopelessly inadequate"?