Board index » delphi » Re: Turbo questions

Re: Turbo questions


2006-08-24 06:00:39 AM
delphi26
Jolyon Smith writes:
Quote
Microsoft determine what the CLR can and can not do.
Microsoft determines what the Win32 API can and can not do.
Quote
But now language features are part of the platform to an extent that
they weren't before.
Right -- but that is no different than before. Object Pascal had to
adapt to use the Win32 API.
--
Nick Hodges
Delphi/C# Product Manager - Borland DTG
blogs.borland.com/nickhodges
 
 

Re: Turbo questions

"Bryce K. Nielsen" <XXXX@XXXXX.COM>writes
Quote
My fear is going to be exactly what a lot have already said. I download
(or even buy Pro) TurboD and use it a lot. Then I have some free/spare
time that I can start tinkering with DotNet. I really like my Delphi
experience, so I want to try Turbo C#. After the lengthy download, the
installation starts and then informs me that in order to install, I need
to uninstall Turbo Delphi. I don't think so! I use Delphi too much to
uninstall just to "tinker" with dotNet. On the other hand, there's this C#
Express from Microsoft, I bet that can sit on the same machine as my
Delphi. So I download that and start using, learning C#, etc.

I fear that that scenario will become all too common with the current
technilogical installation problem...

It is easy to complain about any given solution, as you've proven.
What would you do to limit the turbo versions that would get
less complaining about the restrictions?
Seems to me that it *has* to be something that people don't like
or they are not going to upgrade.
My problem is that I don't think there are *enough* restrictions.
Including the VCL source for free?!?! that is just crazy.
But, I have to trust that they know what they are doing.
Didn't I read somewhere that courage was required to be
successful these days?
--
Thanks,
Brad.
 

Re: Turbo questions

Quote
It is easy to complain about any given solution, as you've proven.
What would you do to limit the turbo versions that would get
less complaining about the restrictions?

Seems to me that it *has* to be something that people don't like
or they are not going to upgrade.
Who's complaining? I am just worried that here's a company that produces a
product I love using and I want to see it succeed in every shape an form.
With the techincal limitations, then this can be a problem and I am worried
that that will spell bad news for DevCo, bad news that could be avoided if
this limitation didn't exist. This is a rather silly restriction that was
not by design, rather it is by accident, and could hurt DevCo...
-BKN
 

Re: Turbo questions

In article <44ecd007$XXXX@XXXXX.COM>, Nick Hodges
(Borland/DevCo) says...
Quote
Jolyon Smith writes:

>Microsoft determine what the CLR can and can not do.

Microsoft determines what the Win32 API can and can not do.
And the Win32 API determines language features? Nope.
Ok, maybe "determines" is too strong a word for the influence that the
CLR exerts. See below.
Quote
>But now language features are part of the platform to an extent that
>they weren't before.

Right -- but that is no different than before. Object Pascal had to
adapt to use the Win32 API.
Yes, but how it adapted was entirely in the purview of Borland. You
didn't have to wait for Microsoft to deliver any changes or enhancements
to Win32 that would allow you to adapt Object Pascal in an acceptable
way.
As I said, it is true to a large extent that you don't have to for .net
either, but if you do things in a non-CLR compliant fashion that is now
more likely to be perceived as a negative differentiator rather than a
positive one.
"Hey Bob, you wanna be careful using feature X in Delphi.Net - it is not
directly supported by the CLR so you might find it difficult to move to
a different codebase in the future or to use Delphi components that use
it from C# or vice versa"
So perhaps the CLR exerts an influence over language features that Win32
didn't (couldn't - it was in no position to).
Just maybe?
--
Jolyon Smith
 

Re: Turbo questions

In article <44ecd7e7$XXXX@XXXXX.COM>, says...
Quote
But, I have to trust that they know what they are doing.
Didn't I read somewhere that courage was required to be
successful these days?
Courage is also required to leap from a tall building with no parachute,
safety net or other arrest mechanism.
If you do so you will be _very_ successful at making a wet, sticky mess
on the pavement below.
There is a fine line between courage and stupidity.
;)
--
Jolyon Smith
 

Re: Turbo questions

Jolyon Smith writes:
Quote
And the Win32 API determines language features? Nope.
No, but it requires a certain level of features, most notably PChars.
Quote
So perhaps the CLR exerts an influence over language features that
Win32 didn't (couldn't - it was in no position to).

Just maybe?
That may be true, sure. But the point remains: it is always been that
way.
--
Nick Hodges
Delphi/C# Product Manager - Borland DTG
blogs.borland.com/nickhodges
 

Re: Turbo questions

In article <44ece65f$XXXX@XXXXX.COM>, Nick Hodges
(Borland/DevCo) says...
Quote
Jolyon Smith writes:

>And the Win32 API determines language features? Nope.

No, but it requires a certain level of features, most notably PChars.
C'mon, gimme a break.
Not supporting PChar that would mean not supporting pointers and not
supporting a char type, neither of which are specific to Win32.
Object Pascal has special handling for PChar as a convenience, not as a
requirement.
Quote
That may be true, sure. But the point remains: it is always been that
way.
And here we go again. "It is because I say so".
You may not agree with me, but I do at least try and substantiate my
p.o.v. Just once in a while the same courtesy in return would be
appreciated.
If it is "always been that way" it should be a trivial exercise for you
to give an example of an Object Pascal _language_ feature that
_couldn't_ be implemented until there was a change in Win32 to support
it.
--
Jolyon Smith
 

Re: Turbo questions

Jolyon Smith writes:
Quote
In article <44ece65f$XXXX@XXXXX.COM>, Nick Hodges
(Borland/DevCo) says...
>Jolyon Smith writes:
>
>>And the Win32 API determines language features? Nope.
>
>No, but it requires a certain level of features, most notably
>PChars.

C'mon, gimme a break.

Not supporting PChar that would mean not supporting pointers and not
supporting a char type, neither of which are specific to Win32.

Object Pascal has special handling for PChar as a convenience, not as
a requirement.
Interfaces (COM compatible), Variant, WideString (BSTRs) are some other
examples of Win32 more or less dictating a language feature and a
specific implementation of said feature. Of course we took those
features and made them, IMO, much easier to use and work with than
using some raw mechanisms. Exceptions are also another language
feature where the implementation was dictated by the underlying OS
execption architecture. Of course, Delphi had its own implementation
of exception support in Delphi 1 for Win16, and another implmentation
for Kylix, so I guess that one could be argued away ;-).
--
Allen Bauer
Developer Tools Group
Chief Scientist
Borland
blogs.borland.com/abauer
 

Re: Turbo questions

In article <XXXX@XXXXX.COM>, Jolyon
Smith says...
Quote
Not supporting PChar that would mean not supporting pointers and not
supporting a char type, neither of which are specific to Win32.
...
and both of which existed in object pascal _before_ Win32.
We didn't sit around twiddling our thumbs waiting for Win32 to support
PChars before getting them added to Object Pascal. that is the type of
influence I am referring to.
--
Jolyon Smith
 

Re: Turbo questions

Jolyon Smith writes:
Quote
If it is "always been that way" it should be a trivial exercise for
you to give an example of an Object Pascal language feature that
couldn't be implemented until there was a change in Win32 to support
it.
That seems rather arbitrary, but what Allen says, pretty much addresses
it.
--
Nick Hodges
Delphi/C# Product Manager - Borland DTG
blogs.borland.com/nickhodges
 

Re: Turbo questions

"Jolyon Smith" wrote
Quote

So perhaps the CLR exerts an influence over language features that
Win32 didn't (couldn't - it was in no position to).
Certainly the CLR and CTS exert an influence on languages that aspire to
interoperability, and does so in a way that win32 did not.
But I do think it is a mistake to push that point very far. No existing
language (C# included) surfaces all that the CLR makes possible, any more
than any language implemented on win32 had direct concepts for all things
possible with win32. In a way it is like mentioning that human anatomy
constrains vocalization. Yes, it does, but that hasn't prevented 1,000s of
different languages from emerging, each distinctively expressive of its
cultures needs.
For a good sense of how wide the possibilities are, Bertrand Meyer is an
excellent source:
archive.eiffel.com/doc/manuals/technology/bmarticles/sd/dotnet.html
bobD
 

Re: Turbo questions

In article <44ecf9e5$XXXX@XXXXX.COM>, Allen Bauer says...
Quote
Interfaces (COM compatible), Variant, WideString (BSTRs) are some other
examples of Win32 more or less dictating a language feature and a
specific implementation of said feature.
"more or less" is a key phrase, and calling these language features is a
bit of a stretch.
But never mind that, this is the opposite of what I mean. In these
cases Win32 delivered these things and they had to be supported, and in
the light of that, it made sense to implement them according to the
spec.
We weren't banging on Borlands door demanding an "interface" keyword and
being told: "No, sorry, you will have to wait until Microsoft have
delivered interface support in Win32".
But by "language features" I don't mean "wrappers around platform or OS
services". Unless I am mistaken, you could have worked with Win32/COM
interfaces and variants without any language changes, it just wouldn't
have been as pleasant.
:)
But take, as an example, function overloading. Introduced in Delphi 4
iirc.
Why not in Delphi 1, 2 or 3? Was Borland waiting for function
overloading support to be added to Win32? ;P
Now let us imagine that we didn't actually get function overloading in
Delphi 4.
Let us imagine further that in this nightmarish vision of the past <g>
even Delphi.net didn't have that language feature, simply because (in
this pre-apocalyptic vision) .net itself didn't support it, because in
this case the language can not provide this feature unless and until the
platform does.
Now do you see what I mean?
--
Jolyon Smith
 

Re: Turbo questions

Jolyon Smith writes:
Quote
In these
cases Win32 delivered these things and they had to be supported, and
in the light of that, it made sense to implement them according to
the spec.

We weren't banging on Borlands door demanding an "interface" keyword
and being told: "No, sorry, you will have to wait until Microsoft have
delivered interface support in Win32".
I thought the point was that Borland has always been chasing MS' tail,
eg MS had COM objects, but if you wanted it in Delphi, you'd have to
wait til they add support for it (in this case, via interfaces).
Granted, there were probably very few language/compiler changes
required to support Win32 (and subsequent additions to Win32). That
might be the case in the future for .NET.
--
Dave Nottage [TeamB]
 

Re: Turbo questions

Michael C. writes:
Quote

I don't think that is the primary reason Borland lags behind in .NET
development. The primary reason is because Microsoft owns and develops
.NET
"technology". Microsoft will always get out their .NET development
products first
because they own the .NET platform. Borland will always have to play
catch up if this trend continues.
By this logic, Borland and Delphi should never have been successful *at
all*. Of course MS is always going to have an advantage in being able to
release things before Borland can, that has always been true from DOS days
through Win32 and now .Net.
For the OS and .Net, MS is apparently very cooperative with Borland, after
all, Delphi and the products we create with it help sell Windows. Borland
does not have to wait for MS to make a final release before they can start
working, Borland gets all the beta builds from the start, and can consult
with MS people. Borland *does* have to wait until final release before
finalizing their own releases because the new OS or .Net version can change
right up to the last. If the resources are available then all that is left is
testing and tweaking against those final builds.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"Democracy, without the guarantee of liberty, is merely a method of
selecting tyrants." - Alan Nitikman
 

Re: Turbo questions

Jolyon Smith writes:
Quote

And the Win32 API determines language features? Nope.

Ok, maybe "determines" is too strong a word for the influence that the
CLR exerts. See below.
The CLR provides an *extremely* comprehensive specification. Even C# does
not surface everything that the CLR allows. The idea that the CLR is going
to cripple language developers is nonsense. It also does not prevent
language-specific features, all that is requires is that those features
generate valid IL code. Certainly there was work involved in figuring out
the best way to compile Delphi code into IL, and not everything was
necessarily easy, and that will continue, but while it may differ
technically from an API, it really is no different in principle.
Also, the idea that Borland has to wait for .Net is wrong - again no
different than the API - Borland has access to all the betas and to MS
personnel as well, so they can be developing in parallel with MS
development. MS can change things right up to their final build (as they can
and did with Win32 releases and various APIs), so there's always a little
work left for Borland after that before they can get their products out, but
that's all.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"A man is likely to mind his own business when it is worth minding,
when it is not, he takes his mind off his own meaningless affairs by
minding other people's business." - Eric Hoffer