OpenEuphoria

Re: About .NET

• Posted by Jonas Temple <jtemple at yhti.net> Jul 29, 2004
• 610 views

David wrote:
> 
> Philip Deets wrote:
> 
> > I thing there are over 65 programming
> > languages that can create .NET applications.
> 
> And oddly enough, they all look exactly like C#. That is, all .NET languages 
> tend to have the same datatypes, control structures, and so on. The .NET 
> framework works well with compiled languages, but rather poorly with 
> interpreted languages that have dynamic datatypes.
> 
> There are two approaches you can take with .NET: compile to the .NET 
> intermediate language, or create an interpreter that runs under .NET.
> 
> In the first scenario (compile to .NET), you have the advantage of the 
> language being able to run as a "first class citizen" and having full access 
> to the .NET library. That's sort of the point of .NET: all languages get 
> equal access to the same libraries, so they are equally powerful.
> 
> In the second (create an interpreter), you end up with a language that runs 
> under .NET, but doesn't necessarily have any of the advantages of .NET, other 
> than running under .NET.
> 
> I don't see any reason why Euphoria wouldn't be able to work under either 
> scenario.
> 
> -- David Cuny
> 
> 
I just took a quick glance at the IL that all .NET languages translate
into.  I don't think it would be difficult to come up with a program
that would translate a Euphoria program into IL.  However, here's some
things to consider:

1. It would force us to switch from our favorite Windows API library
to a standard coding for using .NET services.  The "standard" could be
anything we want but it would have to be agreed upon.  Trying to come up
with a program that would translate all the available Windows API 
libraries would be a nightmare.  This doesn't rule out someone coming up
with, for example, a win32lib.ew file that would use the Euphoria.NET
coding standard.  This would also apply to any other user contributed 
library.
2. Euphoria.NET would be a Windows only variant, moving away from the 
cross-platform compatability (but of course, isn't this what MS wants?).
3. Euphoria.NET programs would run slower than Euphoria programs coded 
to the API.

I also ran a dependency walker against one of the .NET windows form
.dlls and not to my surprise, the dll was linked to comctl32.dll,
kernel32.dll, advapi32.dll, gdi32.dll, user32.dll, comdlg32.dll, etc.
So it would seem that .NET is similar in concept to OWL and MFC in that 
it tries to shield the programmer from the Windows API and throws in some
additional services to boot.  The reality is that .NET is still based on 
the traditional Windows API so seemingly there's no worry that MS might
one day throw away the APIs.

My feeling is that we can continue to code Windows Euphoria programs
for quite some time and they should run fine when MS moves to a ".NET
only" programming environment.  Unless I've misinterpreted the signs, I
can't really see any compelling reason to go to all the trouble of
creating Euphoria.NET.

Jonas

The opinions expressed are not necessarily those of this station or
it's affiliates.