Code Generation

From: Jules Richardson <julesrichardsonuk_at_yahoo.co.uk>
Date: Wed Sep 29 05:36:37 2004

On Tue, 2004-09-28 at 21:53 -0400, David V. Corbin wrote:
> >>>
> >>> Doesn't Perl have something along these lines? I'd be
> >>> surprised if not.
> >>>
>
> I am taling about features build into the run-time of the language, not
> access to external tools [such as what ships with Unix and many other
> environments].

Sorry, I meant built into the language too, not a bolt-on :-)

> The difference is that these languagages are to some degree interpreted,
> they do not normally compile down to native executable code. However these
> types of constructs do perform roughly equivilant functions.

Hazy memory, but I thought .net was typically C# in a distributed
environment - in other words, Microsoft's rip-off of Java and JINI with
the added "benefit" of vendor lock-in :-)

I thought C# was *usually* interpreted, just with the option of
compilation if needs be (just as Java bytecode can be compiled to native
code if desired). Fair call on the compiler included with the OS though.

Aside: it's funny how typical developers don't seem to care about
application footprint or efficiency these days, yet they often throw
their arms up in protest when it comes to mention of interpreted code
over native (I don't mean you David, just a general observation)

> With the dynamic assembly you can go from source code to native instruction
> and even persist [save] the results between runs in many different ways.

I've certainly seen that for other langauges - not as you say included
as part of the OS though.

> Also the code generator is capable of supporting different .Net languages.
> This means that a C# program can write and excute Cobol code, or a Visual
> Basic program could write Fortran code and execute it.

Now that is interesting. A developer's nightmare, but interesting :-)

> The general truth is that a
> Microsoft environment is the most convient way to make a living developing
> software.

I hope that MS don't go the same route as Sun did with Java and try to
enforce the way that developers work. Keeping it (relatively) simple
(and therefore flexible) is the key - as soon as a vendor tries to
impose a style of working upon the language it starts going downhill, as
there are always going to be scenarios where there are exceptions to the
way they see things.

seeya,

Jules
Received on Wed Sep 29 2004 - 05:36:37 BST