Board index » delphi » Re: Ping Nick Hodges

2006-08-30 09:48:46 AM
delphi240
In article <44f4db1f$XXXX@XXXXX.COM>, Nick Hodges
(Borland/DTG) says...
Rather he is asking if a feature isn't being added for .net, are there
circumstances where would it never-the-less be added to Win32 anyway if,
for example, the community of Win32 only developers were sufficently
interested?
Of course, maintaining source compatability is a highly significant
issue that muddies the waters slightly.
would either not be added to the .net compiler at all or added in a way
that is independent of (and pre-dating) any .net framework support for
that feature in .net in order to deliver that feature more quickly than
would otherwise be the case?
It's been done to death in another thread, but I do find it slightly
incredible that if, as I have been assured, generics is something that
was on the wish-list for Delphi for years, it is pure coincidence that
when generics support in .net 2.0 appeared on the horizon, suddenly the
scales fell from the eyes of the compiler engineers and the way to make
it all happen became clear.
Synchronicity with the support in .net framework being, naturally,
_entirely_ coincidental.
(fwiw I really have no particular desire to see generics, but their
introduction to the language, or rather the lack there-of, provide a
useful examplar)
32/net hybrid.
When I suggested that this fact was itself might be _seen_ as sending
some kind of message I got short shrift.
So if you are going to hold up a Win32 application as evidence of
committment to Win32 development you really should pick a Win32
application, not a hybrid.
;)
Seriously, you can not tell us we shouldn't see X as any kind of message
and then turn it around and tell us that "_inaccurate_ X" _is_ a
message.
Well, you can if you like. What the heck, while you're at it, just go
right ahead and declare anything/everything said to the contrary as
"false".
;)
--
Jolyon Smith
 

"Nick Hodges (Borland/DTG)" <XXXX@XXXXX.COM>writes
Second, I'd say that the most common thing I hear from you when people
say Win32 has been neglected is that all of the IDE functionality that's
been gained in last couple versions benefits Win32 Delphi just as much as it
does other languages. Like I said, that doesn't really go far in convincing
people that you're dedicated to rejuventating Win32 Delphi. So far as that
IDE functionality goes, it seems to me that Borland just sort of let Win32
Delphi "tag along" for the ride; Win32 Delphi was not the focus.
Third, yes, I'd say function inlining, operator overloading, records
with methods do count. (But didn't those all come about two years ago in
D2005?) In any case, yes, I think it would be helpful to have list of
Win32-specific compiler enhancements and bug fixes on web page that you
could refer people to. Also have list of proposed or pending additions and
bug fixes. Python is an example of a living, growing language that is
constantly being improved; there is a Python Enhancement Proposal list at
www.python.org/dev/peps/ that lets you view substance and status of
what's going on in Python language core. Some kind of transparency like
that might be helpful for Win32 Delphi (and for all the other DevCo
languages.) For example of what I mean about transparency you can read an
article by your new friend Eric Sink:
software.ericsink.com/bos/Transparency.html
leveraged across multiple languages that doesn't instill any confidence
about a focus on Win32 Delphi going forward. Impression I get when you
focus on leveraged enhancements is that Win32 Delphi seems to be just
tagging along. Instead, what would be better would be to create a web page
to refer people to that focuses on recent Win32-only enhancements and bug
fixes, along with upcoming enhancements and bug fixes and their expected
dates. Feature matrix is much too bloated and doesn't focus on new stuff.
What I am thinking of would be a page that distills recent improvements and
upcoming improvements to Win32 in an easy to read and compact format..
isn't enough. A web page that gives a simple account of recent and planned
updates to Win32 Delphi compiler and VCL would be helpful. You could then
just refer people to that page rather than wasting time on newsgroups in
threads with people like me. ;)
I should say I think the new Turbo editions are great new marketing idea.
I'm impressed at the simple grass-roots, guerilla style of marketing that
devco is bringing to them.
More and more of the transparency that Eric Sink talks about in that article
and other places on his weblog would be good, in my opinion. There's
nothing wrong with admitting mistakes. In fact, it is a good thing. There's
nothing wrong with saying that you're sorry, but you just can not please
everybody all the time. There's no need to win every argument, or respond
with a winning retort whenever people complain about something or criticize
devco. Don't try to beat people into submission in defending actions of
devco. Admit that there are things that devco could do better. Tell people
you're listening to them. Make sure people know you're trying.
I would say that the tone I get from a lot of your posts is of extreme
defensiveness that sometimes feels amost combative. I realize there's a lot
of criticism of devco, and that a highly defensive tone is probably the
natural reaction for someone on the inside. But I really think that sort of
tone is wrong way to go for a company dealing with its customers. Customers
don't want to feel like their tools vendor is arguing with them. They want
a tool vendor who listens, understands, tries hard to please, admits
mistakes. If a vendor does that, it is much easier to take the
disappointment when the vendor says that it is sorry, but it just isn't going
to be able to please everybody.
As Eric says in that article (I think), having a high degree of transparency
can be frightening for a business. But in my mind it is main thing that
would differentiate devco from other tool vendors. Delphi developers for
some crazy reason seem somewhat more loyal to their tool than other
developers are. A high degree of transparency in devco would make those
same developers more loyal to their tool vendor. People don't get warm
fuzzies about Borland anymore. If devco plays it right developers could get
the warm fuzzies about devco. But it will take transparency, admitting
devco is sometimes wrong, not taking defensive or combative stance when
criticized by developers. Easier said than done, I am sure. But I do
believe that.
All this isn't meant to say that I think you or devco are doing a bad job.
But you can always do better. I do have more confidence that devco is
headed in right direction now than I did, say, 6 months ago. But I could
have more. Time will tell, I guess.
-- Herb Sitz
 

In article <44f4db1f$XXXX@XXXXX.COM>, Nick Hodges
(Borland/DTG) says...
I like dotted unit names. Never mind that they were only added in Delphi 7 to
support .net that was coming down the pipeline (wonders: would we have
dotted unit names if it wasn't for .net? is this something that would
never have seen the light of day in Win32 if .net hadn't demanded it?
hmmmmm....)
But seriously, if you want an example of how Win32 might be seen to have
been/continues to be "neglected", follow the steps in QC 32444 for a
Win32 package and the IDE doesn't like it.
The same steps for a .net Package seem not to suffer the same problem.
Some might call it a limitation.
Win32 and .net treated as equal partners.....?
--
Jolyon Smith
 

Jolyon Smith writes:
I'm all ears if you can think of one that would be of benefit Win32
only.
;-) Instead, the way it went was that it became clear that
parameterized types were going to be part of the .Net spec, and thus
there was little point in doing generics in Win32 until they had been
firm and released in .Net. That way, the spec, the semantics, etc.,
could all function properly together for both platforms. You can
search for messages by Chuck J that say exactly that.
can look it up.
--
Nick Hodges
Delphi/C# Product Manager - Borland DTG
blogs.borland.com/nickhodges
 

Herbert Sitz writes:
enhancements, VCL enhancements, RTL enhancements, and compiler
enhancements. it is not right to just refer to the IDE enhancements.
Believe me.
providing all kinds of updates and enhancements for Win32 developers.
We deliver those enhancements. We tout those enhancements. I say
publicly over and over and over that Win32 developers are a vital part
of our plan going forward. We do all that, and you still feel like
it's all "tagging along". Forgive me for feeling a bit frustrated by
that. ;-)
is frustrating to hear what you are saying, and then have a lot of hard
work dismissed as tagging along. you will have to forgive me for that, I
suppose.
I for one am trying hard to please. We are all here working really
hard to improve the offerings for native developers. Most of the R&D
engineers spend their entire day writing native code.
I'll say it again -- Win32 development is key to our business.
--
Nick Hodges
Delphi/C# Product Manager - Borland DTG
blogs.borland.com/nickhodges
 

Herbert Sitz writes:
*only* make sense to Win32 just so they can say they've enhanced Win32
without regard to .Net? That makes no sense. The best case is *always* an
enhancement that helps *both* side. That doesn't *preclude* the possibility
of certain enhancements that only make sense to Win32 but it should not be
any kind of priority or special focus.
If Win32 developers fail to feel "special" because they didn't get an
enhancement all their own that .Net programmers don't get, then I suggest
those programmers have an emotional problem (craving the envy of others) and
should seek help.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"Those who disdain wealth as a worthy goal for an individual or a
society seem not to realize that wealth is the only thing that can
prevent poverty." - Thomas Sowell
 

"Nick Hodges (Borland/DTG)" <XXXX@XXXXX.COM>writes
to be involved in.
By my understanding, devco has more or less admitted that Borland neglected
Win32 Delphi over the last few years, that it hasn't been focus of Borland
and that it was being milked as a "cash cow". Is that not right?
So don't you see a contradiction in devco trying to argue that there has
been plenty of attention paid to Win32 Delphi over the last few years? Just
admit that focus on Win32 Delphi over last few years was too weak, and that
devco plans to increase its development in future. Isn't that the proper
response?
No, it is not like there has been nothing done for Win32 Delphi in last few
years. But there could have been, probably _should_ have been, much more.
It would make me feel more comfortable if devco admitted that. As it is, I
hear devco doing same song-and-dance Borland's been doing for last few
years. That doesn't instill confidence.
-- Herb Sitz
Do you now see the contradiction in trying to defend the last few years of
progress in Win32 Delphi.
 

Herbert Sitz writes:
pointing out that the view that it has been /negelected/. It hasn't.
I'll gladly concede that more could have been done. Of course more
could have been done. But clearly something well beyond 'neglect' was
done.
--
Nick Hodges
Delphi/C# Product Manager - Borland DTG
blogs.borland.com/nickhodges
 

In article <44f50685$XXXX@XXXXX.COM>, Nick Hodges
(Borland/DTG) says...
that the .net one can?
See other post re: QC32444
delivery in Win32, where the implementation details are nobody's
business but Borland's.
Surely the only thing that had to be the same for both versions was the
syntax understood by each compiler - they didn't necessarily have to
both understand it at the same time though.
<shrug>
(the shoulders are much better now, thanks) lol
--
Jolyon Smith
 

"Wayne Niddery [TeamB]" <XXXX@XXXXX.COM>writes
where your "best case" is an option.
.NET has unicode, .NET has generics, .NET has Win64, .NET has ECO, .NET now
has closures, .NET has all sorts of stuff that native Delphi doesn't have.
I'd like to see native Delphi brought up "even" with .NET. Obviously that's
going to require focusing on native Delphi to provide enhancements that
aren't going to benefit the .NET side, since .NET has them already. Doesn't
that make sense? My understanding is that all of these are in the works for
native Delphi. So why does devco not just stress that they're going to
devote the special attention needed to native Delphi to restore it to
equality with .NET? Maybe they do, but not well enough. More often they
slide into unhelpful explanation that they're leveraging IDE changes across
all languages. that is not really relevant to the core language and library
stuff that native Delphi developers are concerned about.
The worry is that native Delphi has become a weak stepsister to .NET, that
Borland/devco will provide enhancements to native Delphi so long as it can
leverage them across the .NET languages at same time (mostly IDE stuff), but
that the effort to actually raise native Delphi to position of rough
equality with .NET -- which will require focusing on enhancements that
benefit only native Delphi -- is never going to happen.
-- Herb
 

In article <44f5089e$XXXX@XXXXX.COM>, Wayne Niddery [TeamB]
says...
also supported in Delphi.32? Have you tried installed a package with a
dotted name in the Win32 personality recently?
It didn't work in Delphi 7 - I could live with that. Dotted unit names were
not officially supported then anyway, being introduced in anticipation
of future enhancements for D8.
But (according to QC 32444 at least) they still don't work in BDS
either.
;)
--
Jolyon Smith
 

"Nick Hodges (Borland/DTG)" <XXXX@XXXXX.COM>writes
Here's a question for you: In your mind, _should_ Borland have focused more
resources on on native Delphi over the last few years?
If your answer is "No, I think Borland gave plenty of focus to native
Delphi" then I am fearful for the future of devco.
If your answer is, "Yes, Borland should have focused more on native Delphi"
then I think we can conclude that there was at least some level of neglect
of the product. Maybe it was minimal neglect. In any case it is something
that devco should try to remedy in the future.
And you can quibble about use of word "neglect", but really that sort of
quibbling coming from my tool vendor is exactly what I don't want to hear.
I don't want to hear tapdancing, I want straight talk; I want
accountability. Borland's neglect of native Delphi over last few years is
at least a small problem. Please don't deny the obvious. As Eric Sink
said, "Companies that try to hide their product's problems are usually the
ones that never fix them."
-- Herb Sitz
 

In article <44f50c4b$XXXX@XXXXX.COM>, Herbert Sitz says...
and you can address that for free with alternatives (TNTWare e.g).
that the stuff that _both_ have generally work better in .net (where
there is any difference at all).
--
Jolyon Smith
 

Jolyon Smith writes:
exception safety. You cannot *safely* construct an object type in the
presence of the possibility of an exception being raised. So rather
than try and retrofit them, the class types were introduced.
Because of the way classes are constructed and an exception is raised
in the constructor, you can detect a partially constructed object when
the destructor runs.
--
Allen Bauer
Developer Tools Group
Chief Scientist
Borland
blogs.borland.com/abauer
 

Jolyon Smith writes:
have a strong suspicion that if the implementations were /different/,
you'd be complaining about that. ;-)
--
Nick Hodges
Delphi/C# Product Manager - Borland DTG
blogs.borland.com/nickhodges