Re: Dvorak on Microsoft and .NET

Jolyon Smith wrote:

That's my original point: .net sets the limits in a way that the
previous API (Win16/Win32) did not.

As Win32 set limits Win16 did not have and Win16 set limits DOS did not
have, and DOS set limits the CPU does not have?

There are always limits, the issue is only whether those limits are
reasonable or whether they stop you from doing something that is crucial and
cannot be done effectively another way.

AIUI that would happen naturally when debugging a project comprising
code from both languages, e.g. a C# app that uses a control authored
in Delphi. It's a feature/benefit of .net, isn't it?

Fair enough. If debugging from Delphi, this probably works, though I have
not tried it, so I'm not certain (but if not yet then likely will in
future - reasonable feature IMO). If debugging from VS, then no, but you
will then be debugging directly in the IL - it's not going to generate C#
code and put you somewhere in that. Essentially this is the same as
debugging code in Win32 you do not have the source for - you can still do
it, but you're going to be looking at assembler code.

Right, but lets pretend that .net didn't support sets. Then Delphi -
couldn't- have them and still be a .net language. This level of
dependency between language and platform is new (in the Wintel world
at least).

Delphi could still *emulate* sets so that we could still use them, as long
as it was able to *resolve* them into something that was compatible with
..Net - and we would still not need to care from a Delphi POV - there'd be no
semantic difference. If you debug without source, then as above you will
then be into the IL and will have to figure out what it's doing and that the
code you see there represents Delphi "sets". Once again the analogy with
Assembler applies.

Having established that sets are supported by .net, lets instead
contemplate some hypothetical new language feature "X":

.net doesn't have "X", therefore no .net language can offer "X" either
as an extension to or improvement of .net, unless and until Microsoft
choose to permit that feature by extending .net itself.

Unless that language feature can be implemented in a way that allowed it to
resolve to something compatible.

Basically, there is nothing that is really off-limits to any language at all
as long as it can be implemented in a way that is acceptable to .Net.
Another actual example: In .Net *all* variables require a type, but yet
Delphi still allows untyped parameters as per prior Delphi versions, and it
resolves just fine into safe, managed, verifiable, .Net code. The answer was
simply to compile that parameter as TObject. It still works *exactly* as it
always has in Delphi, yet is compatible.

So a language can choose to add, and express, a feature any way it likes.
It's just a matter of how it is implemented under the covers. Thinking that
language expression is somehow limited by .Net would be the same as saying
no Win32 language can have OO features because the CPU doesn't support it.
The point is it doesn't *have* to support it - OO is handled by the
*compiler*.

--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"Bandwagons are like streetcars, there'll be another along in a few
minutes."


.

Relevant Pages

  • Re: The War On HLA
    ... Take a look at the HLA compile-time language. ... Macros can be abused just like any other language feature. ... I find it amusing, however, that HLL programmers (e.g., Delphi, ... > feature is left to the programmer to invent his own uses for. ...
    (alt.lang.asm)
  • Re: Delphi Product Manager questioned
    ... year lag for framework support is a successful strategy. ... Then things like Delphi & VCL.NET support come along in another update ... to 'supercharge' the language and libraries to take advantage of the ... 'me-too' language that feature for feature is just a variant of ...
    (borland.public.delphi.non-technical)
  • Re: BDS 2007 ETA? - Software Assurance gets a no vote here
    ... Ive read this message many times, and I suspect its a simple language ... MS have some very good tools and more feature with .Net 3.0- than ... Delphi but none of these tools or feature can satisfy some of my ...
    (borland.public.delphi.non-technical)
  • Re: Dvorak on Microsoft and .NET
    ... feature is compatible with the .Net CLS. ... Delphi sets still work fine in Delphi for .Net ... couldn't- have them and still be a .net language. ...
    (borland.public.delphi.non-technical)
  • Re: Over 100 Microsoft MVPs Have Signed Online Petition - Give Us Back VB!!
    ... My prime interest is *language* stability. ... "VB data controls" are com controls, ... > I wouldn't ever want to use them in Delphi - or in VB; ... My code is core to the app, business logic that is focused on the market I ...
    (borland.public.delphi.non-technical)