An Unfettered Language

From: Dennis Landi (none[at]none.com)
Date: 10/13/03 

Date: Sun, 12 Oct 2003 18:26:47 -0400

"Bob Dawson" <RBDawson@prodigy.net> wrote in message
news:3f89c4c5$1@newsgroups.borland.com...
> "Dennis Landi" wrote

> are going to be the required and determinate skills, not just syntax
> mastery.
>

Syntax mastery will always be required , regardless of the syntax.
Framework mastery will be required for any given framework. Pretty obvious.
I certainly didn't say otherwise.

Ever look at BCB? Already having the VCL memorized makes it a synch to do
the syntax switch from Pascal to C++. But if I can use C++/Pascal/VB/C#
syntax to manipulate the .NET framework just as well as any other syntax,
then choice of syntax is a non-issue. I think this theory that you can do
some things in one syntax that you can't do in others is nonsense for
syntaxes of equal capablilities, especially on .NET since that is supposed
to be the ENTIRE POINT.

Or do you state otherwise? And what evidence to you have for that?

Interestingly enough, VCL.NET is only accessible thru DfN, right? Now that
could be an edge for Delphi developers. We'll see. It might also just be a
marginalizing factor... (I hope not.)

However, being able to use the same syntax to write for .NET, WinApi or
natively for any other OS, is unassailable IMO. Apart from special cases
like VCL.NET, ... C++ is at least as capable as Object Pascal. This is
because they were both originally developed for general purpose programming.
The fact that Object Pascal can no longer be used for anything except
"managed code" in a single framework, means that Object Pascal Programmer
has lost something in the real world. On 64-bit windows the Delphi
programmer will be technically equal to his fellow VB programmer. But he
will never be the technical equal of his VC++ counter-part, since his rival
will be capable of so much more.

> > no technical reason why we cannot have a 64-bit native Delphi compiler
> > to compliment "managed OP".
>
> Agreed. Whether it makes sense to write one from an economic point of view
> is a separate issue.
>

Well, lets hope "it doesn't make sense from an economic point of view" to
stop supporting Delphi for .NET as well.... As far as
*natively*compiled*languages* go, C++ will never be killed because a single
vendor has unilaterrally decided it no longer is economically feasible to
keep developing it. In fact since C++ is based on an open standard and
guided by a standards body; and that all operating systems are written in
C/C++, pretty much means that it is immortal. A far cry from a language
living at the arbitrary whim of single vendor more interested in its bottom
line than the fact that more than one to two million programmers have have
placed their trust and code-base (not to mention careers) in that
proprietary language...

I envy your rosy outlook on the future of your development language.

Hey, here's a thought. Borland could open up Object Pascal to an
international standards body. Maybe the international community of Object
Pascal developers could independently port Delphi to the Win64 API.... and
other places...

What does the the international community of Delphi Developers say? (not
that they are represented here in these forums.....no, of course not...)

-dennis

-
"Oh my god! They killed Kylix!, You B*st*rds!"
  -Mike Swaim, October 9, 2003

Relevant Pages

  • Re: C++CLI and STL.NET and clrsafe
    ... > syntax every version, incompatibilities, framework issues, installation ... > issues, framework security patches, getting farther abstracted from what's ... market your language to management, ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Conformance
    ... Note that "long double" (extended precision) is a relatively ... that FRAMEWORK and not the individual applications. ... Do you then have a syntax for specifying syntax extensions for constant ... implementation were open source. ...
    (comp.std.c)
  • Re: The Object Pascal Language standard
    ... >to worry about than the syntax differences between the two languages. ... but there might be cases where code needs to be ported or understood a common syntax can help. ... Also I am talking about basic syntax not framework specific functions or API functionality. ...
    (borland.public.delphi.non-technical)
  • Re: Does MC++ have foreach?
    ... Framework (in new syntax). ... if there is a workaround or template function? ...
    (microsoft.public.dotnet.languages.vc)
  • Re: In need of .NET advocacy
    ... >> finds a different reason for the productivity gains of .Net. ... > I am not familar with the intricacies of the framework. ... >> average developers on them, if not now, then later during maintenance. ... programmer helping programmers. ...
    (microsoft.public.dotnet.general)