Mike Lucek:

<Not only the US, where I don't reside, but in other countries and probably
Europe. Not every company in every country is embracing .NET but a lot are.
You would have to have a massive amount of clients in Europe if you can
categorically state that Europe is slow in adapting this technology.>

It depends on the market you're working for. It's the big companies that
switch to .NET, but if you work for relatively small business, I don't thing
there's a need to switc to .NET development overnight. And the big companies
it will take many years before they really switched - the investment is
simply too big to do it quickly. None of my customers - large multinationals
among them, have asked me to develop for .NET yet. For the next few years I
expect to have sufficient work to be done on existing Win32 apps. Apart from
that, the .NET vs. J2EE race hasn't been run and I feel many companies are
waiting for Longhorn to appear before investig heavily in .NET. Despite of
Microsoft calling it "old technology", practice shows that Win32 and COM are
NOT dead and not even deadly ill.

As for now, I stick to D6 and Win32 development and it works fine for me.

<A decent developer would make sure that they don't write slow code
irrespective of the programming language or platform.>

Isn't that a bit easily said? We professional developers are expected to
produce quality software in a short time. I don't want the handicap of a
slow platform that requires me to spend hours optimizing code, if I don't
necessarily have to.

<Or going out to lunch waiting for "Hello World" to compile.>

I haven't seen D2005 yet, but with D6, even "Hello Universe" compiles fast!

Cameron Cole:

<Yes and it is a HUGE improvement, but there are still things that need to
be
fixed.  If you don't know the command you are looking for, it can often be
very hard to dig through MSDN help trying to find the answer.  I don't even
try anymore, I just pop into google news.  Also the endless clicking and
closing of windows is annoying.  I like the grid at the bottom, but the
navigation from it needs work.  Apparently Whidbey addresses these issues as
well as adding some cool new features like searching alternate websites for
help.>

I never use the MSDN search engine, because it doesn't take me anywhere. I
always use Google search with "site:msdn.microsoft.com", and that works
fine. Apart from that, I think the documentation is still quite poor, many
SDK functions have undocumented side effects (or is that a problem with the
functions themselves), they never document possible return codes, they don't
document the EXACT workings of a function, but only what it does
"moreless",...

<My fears are reverse actually.  I fear that when version 5 of the
architecture is installed it will screw up stuff that was working in version
2 and thus force at best a recompile of the app so that it can run with the
latest architecture.  Also, you know MS is going to remove functions and
commands as the architecture grows causing some pain when devs have to
upgrade their apps in this fashion.>

Yes. One company will do that, others won't. So they leave all the dirty
version management to you! What was the credo a few years ago? "Zero
installation"!! And then comes the .NET CLR. Theoretically .NET promised to
solve the "DLL hell", but what hell did it introduce?

Charlie wrote:

<One on the things that bothers me is, Will Microsoft become the present day
IBM? What I mean by that is IBM would bring out a computer/os model only to
abandon it two years later (mainframe and/or PC). Thus far Microsoft has
kept OS's backwards compatible; but are we on the verge of that no longer
being the case?>

Maybe. I think that http://www.joelonsoftware.com/articles/APIWar.html is
still valid. It seems Longhorn will break a tradition of backward
compability. It's not even sure that .NET is safe. And if MS expect the
whole world to reinvent their wheels again, they must realize that it'll be
the perfect moment for alternatives too. MS presently may be a kind of
"Roman Empire" in the IT world, but even the Roman Empire fell.

Darren McBride:

<The case for what you want to do in two years is down to operating systems.
Will Longhorn be a major platform shift, removing the viability of the
Windows API ? Will Linux make inroads into the desktop. Personally I think
the Windows API will still be here in two years, and anything I write now
can be ported to the new operating system. If I write a utility now for a
customer, that customer should still be able to use it in two years time,
providing I do not have to give them the source.>

The problem is: nobody knows. I'm a bit conservative in this respect and I
like to keep all options open. So, I don't want to depend to heavily on the
selected platform, by attempting not to use too many very OS specific
functions. And where I need to do that (for example, using Win32 Shell
functions), I isolate it from the rest of the code and I try to define a
standard interface to it. Hopefully I won't have to go over all of the code
when porting.
What I don't do, is to believe the hype and go for. I might end up nowhere.
Finally, the risk shouldn't be exaggerated. Since we all don't now, nobody's
in advantage. So if thinks turn different than what we expected, we all have
to adapt and the winners will be those who didn't sell themselves out to a
specific platform, either Win32, .NET, or whatever.

<Finally, the career. This is the major decider for most people on this
list.
The most unfortunate thing is that people are rarely lucky enough to do this
purely as a hobby. The companies paying us to do our jobs are continually
being sold change, and managers are afraid to change too quickly or be left
behind. Microsoft just adds to everyones fears by changing things to suit
their own requirements of the market and to ensure that their shareholders
are kept happy.>

Here again, since this is everybody's problem, it's not that big a problem.
The only thing we can do is to keep our eyes and ears wide open, in order to
change direction in time. Don't forget that your strong point should be your
product's functionality and not the platform it runs on. If your product has
a strong market, customers will want and allow you to adapt it to platform
changes. If they don't, the problem is probably not in the platform, but in
the lack of need for the application itself.

Peter Laman
Senior Software Engineer
Lance ICT Group
Roermond, the Netherlands
http://www.lance.nl

----
----

__________________________________________________
Delphi-Talk mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi-talk

Reply via email to