Hey, some people don't use, don't want to use, and will not ever use
.NET. They will move to another OS if they are forced to use .NET.
I use .NET, but that doesn't mean everyone wants to. I don't think
calling people dotnetophobes (or whatever) just because they have a
viewpoint is proper.
Just my 2 cents.
mr_organic wrote:
> .NET is the official forward direction of Microsoft's development model.
> If Borland/DevCo wants to compete in the software development arena (on
> Windows, anyway), they have to support .NET development. Period. Full
> stop.
The problem most people have with BDS and dotNET is not that is supports
writing programs for dotNET but that it requires dotNET even if the user
only installs the Delphi for Win32 or C++ personality.
MfG
twm
.NET is the official forward direction of Microsoft's development model.
If Borland/DevCo wants to compete in the software development arena (on
Windows, anyway), they have to support .NET development. Period. Full
stop.
Whether you or anyone else *likes* that direction is immaterial -- if you
don't like it, move to a Mac or Linux, or just keep on writing C/C++ or
Java code. No one is stopping you.
That said, everyone knows that WIN32 is going to be around for a long,
long while yet. Those .NET-phobes can safely ignore it for as long as
they are financially able to.
mr_organic
> Hey, some people don't use, don't want to use, and will not ever use
> .NET.
And that is totally cool. To each his own.
--
Nick Hodges
Delphi/C# Product Manager - Borland DTG
http://blogs.borland.com/nickhodges
TurboDelphi.NET is for that purpose. But I don't see why TurboDelphi has
to *need* .NET.
> Whether you or anyone else *likes* that direction is immaterial
I disagree, even with MS having a grip on computer manufacturers that
doesn't make people's *likes* immaterial. People can always just figure
Windows as an investment loss and delete it from the machines they buy
and install a different OS. ReactOS is binary compatible with Win
software and that is all you need to run Win based apps.
> -- if you
> don't like it, move to a Mac or Linux, or just keep on writing C/C++ or
> Java code. No one is stopping you.
True. And many people do that. I use the MS IDEs for .NET development.
> Those .NET-phobes can safely ignore it for as long as
> they are financially able to.
Apparently they can financially ignore it forever. Open-source (and/or
free) software has been around for a long time and just keeps growing. I
would rather see people charging for their work, but it's their choice.
> But I don't see why TurboDelphi has to need .NET.
It didn't /have/ to need .Net. We could have written all that
functionality ourselves, I suppose. But we chose to leverage an
existing library. Makes perfect sense to me.
Thanks Nick. The idea is to have choice.
BTW, you're an inside player in something fun and exciting. Enjoy the ride.
Technically yes.
But, I really think (just my view) there are many people who don't want
anything to do with .NET and they perceive TurboDelphi as the way out,
while moving forward with DevCo products.
Remember, it's all about perception not reality.
You're right. Name calling is not cool.
--
Anders Ohlsson - http://blogs.borland.com/ao/
Borland Developer Tools Group ("DevCo")
"Golf is a terrible game. I'm glad I don't have
to play again until tomorrow." - Anonymous
That's because .NET is used in parts of the BDS. Just because you
hate .NET and will "never" use it doesn't mean that the DevCo people
have to feel the same way.
--
Brandon Staggs
http://www.swordsearcher.com
http://www.studylamp.com
http://www.brandonstaggs.com
The problem isn't with then having a viewpoint, it's because their viewpoint
is irrational. Before you explode, I'll tell you why.
.Net is invisible to the end user of the application*. It neither improves
nor worsens the experience for the end user. Therefore, for an end user to
say "I don't want anything to do with .NET" is simply irrational - by
definition.
The same thing applies to developers like us. The fact that Delphi uses
.NET for some of the IDE functionality is irrelevant to us. I don't know or
care whether Delphi itself has been written in Pascal, .NET, Visual Basic or
Forth. All I care about is how well it works. Again, to take a different
view is simply irrational.
The one area where we DO have a legitimate concern is whether we want the
code we develop to use .NET or W32. There are legitimate reasons to avoid
.NET (such as the need for W95 compatibility, or to get the fastest possible
run speed), so this is the one place where we CAN have a rational viewpoint.
And that is where Delphi scores, because the DEVELOPER has the choice
whether to write .NET code or W32 code.
Is anyone here silly enough to think that their colleagues shouldn't even be
offered that choice?
In summary, everyone has a right to their viewpoint, but if they arrive at
that viewpoint by prejudice and irrational thinking, they've got to expect
to have their viewpoint challenged!
Colleagues - we are computer programmers, for goodness' sake: we should lead
everyone else when it comes to logical, rational thinking and freedom from
prejudice!!
Thack
*I accept that .NET code runs slower than pure W32, but how often does that
matter? On those rare occasions it does, you have a rational reason to
avoid .NET. Likewise, you sometimes have to make a rational decision to
code in assembler. No-one should be 'anti-Delphi' just because
hand-optimised assembler is usually faster, nor should they be 'anti-.NET'
just because W32 is usually faster.
> .NET is the official forward direction of Microsoft's development
> model. If Borland/DevCo wants to compete in the software development
> arena (on Windows, anyway), they have to support .NET development.
> Period. Full stop.
Yep and while like you go on to say, I have no intention of leaving my
beloved win32 for a good while to come, I dont *hate* .Net, I have no
interest in it, I see it as no worse than java apps, they require a big
enough ol' runtime, the first time (with java most times) you run it,
its slow to start, but once it has got going its ok.. and what its
written in doesnt really matter. If it does the job, doesnt hack me
off, it will do me.
Tollerance is the key, no ones asking people to love .net, but, MS are
trying to drag everyone on to .Net one way or another.. and while other
OS' are in use, (My daytime job is a linux admin after all) the
predominant OS in work places will be for the forseeable future, be an
MS windows variant. So..
--
Liz the Brit
Delphi things I have released: http://www.xcalibur.co.uk/DelphiThings
Many people are demaning that DevCo moves to .NET2.0 and even .NET3.0.
It's hard to maky everyone one happy at 100% level.
Saludos
Sebastian
> I dont hate .Net, I have no
> interest in it
The .Net Framework has a HUGE amount of objects that do for you what
you before maybe had to write yourself.
To me, that is interesting :-)
--
Ingvar Nilsen
http://www.ingvarius.com
> The problem most people have with BDS and dotNET is not that is
> supports writing programs for dotNET but that it requires dotNET even
> if the user only installs the Delphi for Win32 or C++ personality.
Question is why this is a problem. I am sure most developers have an
ocean of available space on their machines. Expect space
considerations, I cannot see any other "problems".
Please note, I am not sarcastic or harassing, I am honest, I don't see
the problem.
Of course, one may wonder why it is like that, why Borland has mixed
.Net into the old trustworthy environment - Win 32 - and therefor
dislike Borland/BDS..
But apart from that..?
> But, I really think (just my view) there are many people who don't
> want anything to do with .NET
What if they don't want to have anything to do with GDI.EXE?
That's another library in Windows.
Having irrational points of view is a *problem*? Honestly, I don't
necessarily see it as a problem, I see that as part of the human condition.
Part of the passion I have for Delphi is irrational; so is my love for
my wife. ;)
[...]
> In summary, everyone has a right to their viewpoint, but if they arrive at
> that viewpoint by prejudice and irrational thinking, they've got to expect
> to have their viewpoint challenged!
Prejudice is not the same thing as irrational thinking.
"Brand Loyalty" can be viewed as positive prejudice; certainly from the
perspective of the company that owns the brand. This kind of prejudice
is typically rational based on good experiences with that brand.
Although very difficult, I try not to have any expectations. But I'm
pretty sure that I'll have my viewpoints challenged regardless of how
rational/irrational they are...especially on non-tech.
> Colleagues - we are computer programmers, for goodness' sake: we should lead
> everyone else when it comes to logical, rational thinking and freedom from
> prejudice!!
We are also human beings that are persuaded by emotions, preferences,
likes/dislikes, quirks, fears, uncertainty, doubts, etc. Many of which
are irrational and/or prejudicial.
--
Brian Moelk
Brain Endeavor LLC
bmo...@NObrainSPAMendeavorFOR.MEcom
And there are even IDEs purely written in .NET ! :-)
These "I'll never use XY" statements are rather funny. Nobody is forcing
developers to use the technology for writing applications (yet <g>) but from
the perspective of development tools companies (= DevCo) I understand they
have chosen the best technology to achieve the functionality with no
additional cost.
As for the installation it would be better to use standard bootstrapper to
have all the prerequisites in single setup and provide an ISO image for
download.
As for never-ending "The IDE is slow because .NET is slow" comments I would
only recommend to learn and try to use the technology. You would be very
surprised how the performance is. Blaming something new (means unknown) is
easy but most of the time premature and inaccurate.
Petr
> The .Net Framework has a HUGE amount of objects that do for you what
> you before maybe had to write yourself.
> To me, that is interesting :-)
It would be interesting if I did not have 99% of the objects I wanted,
bar one which still isnt in .net (the ability to display vt100
compatible data in a terminal type component), to me, win32 has been
around long enough that the majority of anything I think to want is
available, however, if it can achieve something for people they would
have had to do more work to do without.. well kudos to it.. but much
like giving me a car that does 200mph, our speed limit is 70.. my old
cortina could do 115.. why change it if its still good?
However, programming is not my main job any more, I went to the
darkside and do tech support.
> What if they don't want to have anything to do with GDI.EXE?
> That's another library in Windows.
I, for one, want nothing to do with comctl32.dll. It looks at me funny.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
How to ask questions the smart way:
http://www.catb.org/~esr/faqs/smart-questions.html
Many people consider the installation of the 230M prerequisit an worsening experience. Many people also consider the slower startup time and larger memory footprint compared to D7 an worsening experience. Of course, it may be a problem with D2006 itself not .NET.
>Is anyone here silly enough to think that their colleagues shouldn't even be
>offered that choice?
>
The guy was actually arguing that developers should have the choice, a choice of staying free from .NET.
>In summary, everyone has a right to their viewpoint, but if they arrive at
>that viewpoint by prejudice and irrational thinking, they've got to expect
>to have their viewpoint challenged!
>
Very well put. The challenges themselve too should not be arrived by prejudice and irrational thinking.
>*I accept that .NET code runs slower than pure W32, but how often does that
>matter?
It always matters. It matters everytime I run the program. It stops to matter when I quit using the program.
-- CB
> ou would be very surprised how the performance is.
I'm starting to believe that many people who think .Net apps run slow
simply don't have enough experience with .Net apps.
That's exactly what I was trying to point out.
Petr
Huh? A lot of us have had sufficient experience with D2005 and D2006.
-- CB
Do you use them yourselve in your work? Or do you use VS.NET? Go check out their memory footprint and startup time. I tried one but I soon went back to VS.NET.
>I understand they
>have chosen the best technology to achieve the functionality with no
>additional cost.
>
Sounds familiar. I think I heard something like this in an MS seminar.
-- CB
>
> That's exactly what I was trying to point out.
Yes -- and you pointed it out well. ;-)
Do you only code in hand-optimised assembler, then? Are you running the
fastest PC money can buy, then? If 'no' to either, you are acknowledging
that run speed is just one factor that has to be balanced with others, such
as development/maintenance time, etc.
Sun with Java, and Microsoft with .NET, have both acknowledged that the
extra runtime layer introduces more processor loading, but they believe the
benefits outweigh the disbenefits most of the time.
Their view is no different from yours when you choose to code in Delphi
instead of assembler. The benefits outweigh the disbenefits most of the
time.
Thack
That's what they've been saying about Java since 1999 or so.
I think people who think .NET is fast have had a major hardware upgrade.
Prejudice means 'prejudging' - arriving at a view without consideration of
all the facts. It is one example of irrational thinking.
Thack
I am hearing that .NET 2.x is much faster than 1.x
In fact, that's what I have noticed with a lot of .NET apps, using the same hardware.
Regards,
Sarah
I agree. Especially if the program dies afterwards. Like my Turbo-CBuilder
installation for example. AAAAARRRGHHH!!!
>>*I accept that .NET code runs slower than pure W32, but how often does
>>that
>>matter?
>
> It always matters. It matters everytime I run the program. It stops to
> matter when I quit using the program.
>
To me it only matters for stuff I constantly use and work with - like IDEs.
True, you want to weigh the benefits vs the cost. But what benefits? I
havent done much .net coding, but as an end user I've installed plenty of
.net and java apps. The only 'benefits' they seem to have over native code
apps is a slow startup time, sluggish operation, and an extra download to
get the runtime. Ok, Java is cross platform, so at least you get something
in trade there. There may be a few benefits to .net _for coders_, but the
end user doesnt care. All they'll think is 'damn, this program takes
forever to run'.
This is not my case though. Not sure whether it has anything to do with having both 1.1 and 2.0 installed.
-- CB
> "Staiger" <Sta...@nowhere.net> wrote in message
> news:44ff...@newsgroups.borland.com...
>> Sun with Java, and Microsoft with .NET, have both acknowledged that
>> the extra runtime layer introduces more processor loading, but they
>> believe the benefits outweigh the disbenefits most of the time.
>
> True, you want to weigh the benefits vs the cost. But what benefits?
> I havent done much .net coding,
...which, IME, pretty much invalidates any criticisms you make....
> but as an end user I've installed
> plenty of .net and java apps. The only 'benefits' they seem to have
> over native code apps is a slow startup time, sluggish operation, and
> an extra download to get the runtime.
And of course, not having programmed in either environment, you don't
know much about the automatic garbage-collection, rich type system,
enhanced security frameworks, "safe" execution of binaries (to eliminate
stack-smash and buffer overruns), native Unicode support, and so on.
There are *lots* of reasons why programming paradigms are moving to
managed environments. Those reasons might be *debatable* among people who
understand the benefits and drawbacks of the approach, but to dismiss the
whole concept because it's "slow" is just lame and uninformed.
mr_organic
I don't believe they think of what benefits *me*. I believe they only
think what benefits *them*. What benefits them is to continue to sell.
You can not sell something that all people already have, you must
change it. Sometime change is good. Sometime change is bad. Is that
simple.
More processor loading means among other things we have to upgrade
computers every year, not only our IDEs and OS-es. Go figure who
benefits most. I for that matter will stick with W2k pro until my pc
will rust :-)
Not normally unless when my product performs poorly than my competitor's. In those cases, I would do a profiling and fine tune the part with inline assembler. I suppose Borland had done this with D2006 already.
> Are you running the
>fastest PC money can buy, then?
No because I can't afford it. So, for every program I pay for, I want to get the most out of it.
> If 'no' to either, you are acknowledging
>that run speed is just one factor that has to be balanced with others, such
>as development/maintenance time, etc.
>
You are making an assumption here that the development/maintenance time would be reduced by using .NET.
>Sun with Java, and Microsoft with .NET, have both acknowledged that the
>extra runtime layer introduces more processor loading, but they believe the
>benefits outweigh the disbenefits most of the time.
>
I bet they surely want you to believe that.
>Their view is no different from yours when you choose to code in Delphi
>instead of assembler. The benefits outweigh the disbenefits most of the
>time.
>
In fact, I wouldn't concern whether the IDE is on .NET or not as long as it (the IDE) performs as good as its predecessor.
-- CB
> I'm starting to believe that many people who think .Net apps run slow
> simply don't have enough experience with .Net apps.
All of our development at work is now done in VS 2005 and it definitely
runs slower then D6 apps. Startup time is much slower (even with NGEN)
as is the visual drawing. A prime example of this is Reporting
Libraries. Just compare any of the Delphi ones (yes, even QR) to the
.NET ones and notice the performance differences. The non-visual stuff
is a different story.
Cheers
Dean
I'm not going to explode, it does me no good. Your argument however is moot.
It is about opinion (I said viewpoint). Remember the saying: "Opinions
are like assholes everybody has one."
I'm saying that people have an opinion. To you it is irrational. To them
it makes perfect sense. There is no reason to argue it.
I can't see inside their head to know why they come to the conclusions
they do. All I can do is listen to them and be glad they can think for
themselves, whether or not I like their opinion.
So, I for one hope DevCo pursues a pure Win32 (and inherently other
Win32 based OS's) TurboDelphi. I would like to see it exist in the
marketplace. There are other IDEs (Lazarus) that I can use, but I want
DevCo to succeed technically and financially.
Actually even more important than comparing whether performance of platform
X is better than Y (assuming having the right method for it and well written
code for both of them) is whether both platforms are able to communicate
with each other effectively.
Which reminds me, there still isn't any code to transform TClientDataSet
DATAPACKET xml format to .NET DataSet diffgram, right ? :-) That would be
TRUE cross-platform support. Server written in .NET with Delphi Win32
clients communicating via web service is quite typical scenario.
Petr
There are surely *lots* of reasons. But to the end-users, poor is poor.
-- CB
Not to me it doesn't. I want feedback from non-programmer types also.
Please everyone post your feedback.
> It didn't /have/ to need .Net. We could have written all that
> functionality ourselves, I suppose. But we chose to leverage an
> existing library. Makes perfect sense to me.
A funny kind of "sense"
Are we talking (at least in part) about the CodeDOM? (aiui all the
other .net dependencies, apart from the help viewer!?!!, are subsystems
that really could/should be optional components in the install)
As far as CodeDOM is concerned, it seems to me if you had chosen to
write your own you could:
a) have ended up with something that did the job better than CodeDOM
(from the authoratative blogs on the matter there were big holes that
needed plugging - no parsers - and some basic shortfalls in modelling
abstractions - e.g. lack of interface/implementation discrimination - so
my guess is there was a significant amount of work required, despite
"leveraging" the existing library)
b) added even more value to the IDE (Win32 developers have to jump
through hoops to make use of CodeDOM - an "inhouse" CodeDOM equivalent
would have been available to all BDS languages, no?)
Other than that I must presume that the CodeDOM is 100% rock solid
stable, fixed and immutable and never likely to need to change for any
reason what-so-ever.
Of course, if that isn't the case, and you need more than the CodeDOM
currently provides, you _can't_ leverage the library unless you are
happy (and expect your custoemrs to be happy) to hang around waiting for
MS to update it.
Funny thing: A common mantra in commercial softdev is "don't use any
components for which you don't have the source".
The reasons are pretty self-evident and curiously also "make a lot of
sense".
;)
--
Jolyon Smith
>
> Are we talking (at least in part) about the CodeDOM?
A very small part, yes. The other parts we'd need would be, oh, you
know, large chunks of the .NET framework like reflection, web services,
etc.
> Funny thing: A common mantra in commercial softdev is "don't use any
> components for which you don't have the source".
Don't write a Windows app, then. ;-)
> ) That would be TRUE cross-platform support. Server written in .NET
> with Delphi Win32 clients communicating via web service is quite
> typical scenario.
What a great idea. ;-)
> I am hearing that .NET 2.x is much faster than 1.x
> In fact, that's what I have noticed with a lot of .NET apps, using
> the same hardware.
Well, it all compiles down to machine code, so I'm not sure how it
could be faster. I suppose the JIT compiler for 2.0 could produce more
efficient code.
> I think people who think .NET is fast have had a major hardware
> upgrade.
It's all relative, of course.
They are obviously experiencing bottlenecks in the IDE and are looking to
blame the "what's new" element. The fact that the whole IDE is new seems to
escape them.
Not really. ReactOS is Alpha stage, not even Beta.
If you want to change your OS, better to install Linux.
Or buy a Mac.
> Apparently they can financially ignore it forever. Open-source (and/or
> free) software has been around for a long time and just keeps growing.
Amen to open source!
><SNIP>
>
> Don't write a Windows app, then. ;-)
>
The mind boggles. Based on the kind of logic on display here, we should be
writing our own OS from scratch each time just to be able to run our
programs on it!
Eesh.
mr_organic
WinForms apps generally have much slower GUIs (than native Win32 ones) in
my experience.
> The same thing applies to developers like us. The fact that Delphi uses
> .NET for some of the IDE functionality is irrelevant to us. I don't know or
> care whether Delphi itself has been written in Pascal, .NET, Visual Basic or
> Forth. All I care about is how well it works. Again, to take a different
> view is simply irrational.
What is your argument? Since you don't care, it's irrational to care?
I don't believe you've substantiated your claim that it's irrational to
care that Win32 Delphi uses .NET. If you have a counter-argument to mine
(MID: <i8o4wlqp...@tjb.invalid.invalid>), let's hear it.
<...>
No really. Move the .NET part to 2.0 or 3.0
But keep the Win32 part Win32.
It probably does, then some of the implementation is probably better too,
and to top it off the garbage collector is probably also much better (it
certainly is in the compact framework!)
>That would be TRUE cross-platform support. Server written in .NET with
>Delphi
>Win32 clients communicating via web service is quite typical scenario.
It would also be helpful if the TRemoteDataModule component was
implemented in VCL.NET. Or the DataBkr unit.
Apart from improved JIT and GC the answer is ... generics :-)
Petr
What you need to do is re-read what I wrote instead of jerking your knee, as
nothing in my post is 'invalidated' due to my not having done a lot of .net
programming. The point of my previous post (I'll type slower for you) was
that while there may be perceived benefits to coders (and to vendors, of
course, who get to sell to coders), the end user really doesnt care. What
they care about is not having their app take so long to load. To the end
user, there's no real benefit to .net. There's nothing that can be done in
.net that cant be done in a native app - usually faster, to boot. About the
only 'end users' who seem to care if an app is written in .net or not are IT
directors who read too many free IT magazines, and insist on it because its
the 'new' thing.
> And of course, not having programmed in either environment, you don't
> know much about the automatic garbage-collection, rich type system,
*sigh*
I never said I hadnt programmed in Java..
> There are *lots* of reasons why programming paradigms are moving to
> managed environments.
And few of those reasons have anything to do with helping the end user.
Which to me, is the ultimate goal.
>>>Funny thing: A common mantra in commercial softdev is "don't use any
>>>components for which you don't have the source".
"Nick Hodges (Borland/DTG)" wrote:
>>Don't write a Windows app, then. ;-)
mr_organic wrote:
>The mind boggles. Based on the kind of logic on display here, we should be
>writing our own OS from scratch each time just to be able to run our
>programs on it!
It was Jolyon's logic, not Nick's. Jolyon said don't use any components
for which you don't have the source.
How many Windows controls (a specific type of component) do you have the
source for? According to Jolyon, you shouldn't write Windows apps unless
you have the source to every Windows control (and API call, I presume)
that you use.
GUI applications are only small subset of application type you can write in
.NET in general. I can demonstrate that particular web service server
written in Delphi Win32 is about 100 times slower than similar ASP.NET web
service.
Is such comparison transformed into "Delphi Win32 is slower than .NET"
valuable ? I don't think so.
I can agree that Delphi 2005 and 2006 IDE's were visually slower (although
I haven't used them) but I bet the problem is anything but .NET code. VS
hosts the same designer and many other .NET code via COM interop while it is
fast enough.
BTW As for real-world WinForms 2.0 application performance try this one:
http://www.getpaint.net/
Petr
> I, for one, want nothing to do with comctl32.dll. It looks at me
> funny.
<phew!>
I thought it was only me. I also suspect that User32.dll has been
stealing beer from my fridge.
--
Cheers,
David Clegg
dcl...@gmail.com
http://cc.borland.com/Author.aspx?ID=72299
QualityCentral. The best way to bug Borland about bugs.
http://qc.borland.com
"I can't believe it! Reading and writing actually paid off!" - Homer
Simpson
Because the CLR/framework is itself faster? I'm only a bear of little
brain but it would seem to be an obvious place to achieve performance
gains.
http://asptoday.com/images/columns/A0289/Image3.jpg
Or for the full article:
http://asptoday.com/Content.aspx?id=2368
> I suppose the JIT compiler for 2.0 could produce more
> efficient code.
Yes, that would be another (and NGen is supposed to be much better
apparently).
--
Jolyon Smith
If someoen doesn't want to use .NET they may as well start moving to
another OS now. No point in fighting it.
Cheers,
Diego
>>
>>...which, IME, pretty much invalidates any criticisms you make....
>
>
> What you need to do is re-read what I wrote instead of jerking your knee, as
> nothing in my post is 'invalidated' due to my not having done a lot of .net
> programming. The point of my previous post (I'll type slower for you) was
> that while there may be perceived benefits to coders (and to vendors, of
> course, who get to sell to coders), the end user really doesnt care. What
> they care about is not having their app take so long to load. To the end
> user, there's no real benefit to .net. There's nothing that can be done in
> .net that cant be done in a native app - usually faster, to boot. About the
> only 'end users' who seem to care if an app is written in .net or not are IT
> directors who read too many free IT magazines, and insist on it because its
> the 'new' thing.
>
Well said. The goal isn't to write code using the latest fashionable
coding paradigm; the goal is to solve a problem for the end user. The
very fact that so many delphinauts are still *successfully* using older
versions of Delphi to produce programs for use on the latest Windows
incarnations is proof that using the latest MS "Me Too!" toolset isn't
necessary to produce a good, robust end-user solution. I still contend
that the only reason Java has made such in-roads is that it is free and
that Sun almost went bankrupt promoting it.
>
>>And of course, not having programmed in either environment, you don't
>>know much about the automatic garbage-collection, rich type system,
>
>
> *sigh*
> I never said I hadnt programmed in Java..
>
I've programmed in Java. It is a quaint little language :-). In 1998, I
went so far as to schedule the Sun Certified Java Programmer exam and
proceeded to studied my *ss off. After a while I threw up my hands and
declared that if that was the way of the future, I would just get a job
at McDonalds.
>
>>There are *lots* of reasons why programming paradigms are moving to
>>managed environments.
>
>
> And few of those reasons have anything to do with helping the end user.
> Which to me, is the ultimate goal.
>
>
Ditto.
I don't hate .net. I'm just not convinced that it is worth moving to.
.net and Java are the modern rehashing of the P-Code System that has
been around since computing began.
(http://en.wikipedia.org/wiki/P-Code_machine) The arguments for and
against are the same. The outcome for .net and Java is the same as it
has always been for P-Code systems; slow, bloated code that never offers
anything better than native development.
<Flame suit on> Mark
>
> I'm saying that people have an opinion. To you it is irrational. To them
> it makes perfect sense. There is no reason to argue it.
>
There's an old saying: "You can't reason a person out of a position that
he didn't reason himself into".
Mark
> GUI applications are only small subset of application type you can write in
> .NET in general. I can demonstrate that particular web service server
> written in Delphi Win32 is about 100 times slower than similar ASP.NET web
> service.
>
100 times slower!? I would like to see that and then I'd like to see the
code. That has to be some really sloppily written Delphi for natively
compiled code to be 100 times slower than CLR code.
Mark
> The problem most people have with BDS and dotNET is not that is
> supports writing programs for dotNET but that it requires dotNET even
> if the user only installs the Delphi for Win32 or C++ personality.
>
Personally I don't see what's the big deal. So install it. It takes
only a few moments. Once its installed, forget about it. And then
enjoy your new Turbo product.
All this "It requires .Net...blah blah" sounds like a bunch of useless
whinning for no good reason AFAIC
--
> Personally I don't see what's the big deal. So install it. It takes
> only a few moments.
Oh do tell...
"A few moments"
Here's how it plays if your installer doesn't have the pre-reqs
(obtained from someone that didn't need them, see?)
1. Try and install in the background while working
Can't do that - BDE is in use (even though I have no intention of
installing any BDE support)
2. Stop work and restart the install
3. Need to request activation file. Ok, submit email address
picked up by browser (BDN community account details I guess)
4. Wait for activation file by email (it told me to continue once
I'd "done that"). Keys only, I already have the installer, right?
5. Wait.
6. Keep waiting.
7. Try re-requesting (maybe I didn't hit the button quite right)
Can't do that - request already being processed for that
account.
8. Ok, keep waiting....
(24 hours later)
9. Decide I'm not going to get an activation file. Thinks: maybe
it was because it was a hotmail address. Not been a problem before,
but you never know....
10. Change BD account information.
11. Re-Request activation file.
12. BINGO!
13. Right. Start Install.
Can't do that. .net pre-requisites not installed.
14. Find the install folder on my HD, take a look inside (300+ MB -
they must be in there somewhere!), try to find pre-reqs installer.
Can't seem to find them, but there is some util that appears pre-req
related (prereqs.exe), try running that...
15. prereqs.exe tells me what I already know - I don't have the
pre-reqs. Thanks a lot. But there's a "NEXT >" button that
looks promising....
16. Press "Next >"... Do I want to install pre-reqs? Yes I do.
(getting somewhere at last).
BLERT! Can't do that. I need Borland Developer Studio 2006
CD apparently. Funny thing - I thought this was "Turbo"?
17. Thinks....... (this takes a while).... try and figure out how
to get the pre-reqs installer.......
18. How about we start from the beginning but this time we'll pretend
that we don't have an installer (given that its non-functional in
its current state, it may as well be true).
19. Go to download site.
Can't do that. Too busy it would seem.
20. Wait.
(time passes)
21. Try again.
22. Request ANOTHER activation file.
23. Woohoo!!!! Here I am, with an option to download the full pre-reqs
installer.
24. Click to download.
Can't do that, need a download manager.
25. Install download manager.
26. Woohooo!! Here we go, downloading.....
Can't do that. Error - try again. You bet.
Can't do that. Error - try again. You bet.
Can't do that. Error - try again. Forget it, I'll try later.
(time passes)
28. Start the "Resume download" shortcut that was put on my desktop
Can't do that - direct linking not allowed. Click here....
29. Click there. Ok, from all these download areas - choose the
Turbo section.
30. (this looks familiar....) click on Turbo Delphi
31. REQUEST ANOTHER FRIKKIN ACTIVATION FILE!!!?!?
Can't do that. Key already sent.
I CAN'T INSTALL A WIN32 DEVELOPMENT TOOL BECAUSE IT WONT HELP ME GET THE
!!! .NET !!! FRAMEWORK INSTALLED
__THIS__ is the new Delphi Spirit???
> All this "It requires .Net...blah blah" sounds like a bunch of useless
> whinning for no good reason AFAIC
Yep. No good reason. Just a bunch of whining ninnies.
--
Jolyon Smith
If only a small part of Turbo Delphi Win32 is based on .NET, why should
this part be responsible for a bad performance ?
Not that I want to say that it has a bad performance anyway.
It has much more functionality, which needs more performance.
The discussion itself is somewhat irritating for me. Developers who are
programming for Windows and want to avoid .NET, even installed on their
computer, must stay on Windows XP or stop development, since Windows
Vista will have it preinstalled. Same as Windows 2003 Server.
> -- CB
Andre
> "Brandon Staggs" <"[bstaggs]{AT}[swordsearcher]{DOT}[com]"> wrote in
> message
> > That's because .NET is used in parts of the BDS. Just because you
> > hate .NET and will "never" use it doesn't mean that the DevCo people
> > have to feel the same way.
>
> And there are even IDEs purely written in .NET ! :-)
>
> These "I'll never use XY" statements are rather funny. Nobody is
> forcing developers to use the technology for writing applications
> (yet <g>) but from the perspective of development tools companies (=
> DevCo) I understand they have chosen the best technology to achieve
> the functionality with no additional cost.
And yet since Delphi 8 we have seen a decline in the quality of
Delphi/BDS products with various crashes bugs and totally broken help.
So I have to question the idea of "best technology".
> As for the installation it would be better to use standard
> bootstrapper to have all the prerequisites in single setup and
> provide an ISO image for download.
>
> As for never-ending "The IDE is slow because .NET is slow" comments I
> would only recommend to learn and try to use the technology. You
> would be very surprised how the performance is. Blaming something new
> (means unknown) is easy but most of the time premature and inaccurate.
Maybe I should do some benchmarks for myself to see which is faster:
pure WIN32 or .NET.
--
Pete Goodwin
> Craig Stuntz [TeamB] wrote:
>
> > I, for one, want nothing to do with comctl32.dll. It looks at me
> > funny.
>
> <phew!>
> I thought it was only me. I also suspect that User32.dll has been
> stealing beer from my fridge.
No no, that is the ctl3d32.dll!
Remove it immediately!
--
Ingvar Nilsen
http://www.ingvarius.com
| Maybe I should do some benchmarks for myself to see which is faster:
| pure WIN32 or .NET.
But be sure to test .NET 2.0 generic lists against .NET 1.1 ArrayList
implemented lists. I would say that generics has to be a major factor in
speed increase in the many apps as it removes the need for casting and
boxing.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
That's not what I'm saying at all. I'm saying that, given that WinForms
apps are generally a lot more sluggish, it is not the case that .NET is
invisible to the end user.
| I CAN'T INSTALL A WIN32 DEVELOPMENT TOOL BECAUSE IT WONT HELP ME GET THE
| !!! .NET !!! FRAMEWORK INSTALLED
Quick fix.
Read what the prereqs include.
Download them from Microsoft (no registration required)
Install .NET and J#, etc
Start Turbo installer.
> "Pete Goodwin" <goodwin...@TO.REPLY.imekon.org> a icrit dans le
> message de news: 44ff...@newsgroups.borland.com...
>
> > Maybe I should do some benchmarks for myself to see which is
> > faster: pure WIN32 or .NET.
>
> But be sure to test .NET 2.0 generic lists against .NET 1.1 ArrayList
> implemented lists. I would say that generics has to be a major factor
> in speed increase in the many apps as it removes the need for casting
> and boxing.
>
> Joanna
Since BDS 2006 Delphi.NET doesn't support .NET 2.0 I'll stick with .NET
1.1
--
Pete Goodwin
| Since BDS 2006 Delphi.NET doesn't support .NET 2.0 I'll stick with .NET
| 1.1
In that case, don't be surprised at some slowness compared with some Win32
operations, but not all; it really does depend on what you do with it.
e.g. Don't try multiple string concatentations without using StringBuilder;
this is one area where .NET 1.1 is a dog but .NET 2.0 has really improved..
The .NET 1.1 runtime is universally acknowledged as slow so, IMO, it really
is not worthwhile to compare Win32 with .NET 1.1 as most serious .NET
development is already on its way to .NET 2.0.
Having said that, using BDS with .NET 1.1 will prove a useful learning
experience to get used to what .NET has to offer in the *gigantic* CLR
libraries :-)
> Install .NET and J#, etc
and C# and Java SDK and Firefox and IE 7 Beta and and and... ;-)
Funny, you think, but it's reality, of course it should only show in an
exaggerating way, but the prerequisites are enormous "just" for a "simple",
in my case, Win32 IDE.
--
cu,
Michael
Have you tried the Paint.NET or SharpDevelop IDE ?
Petr
> "Pete Goodwin" <bdn.R...@TO.REPLY.imekon.org> a icrit dans le
> message de news: 44ff...@newsgroups.borland.com...
>
> > Since BDS 2006 Delphi.NET doesn't support .NET 2.0 I'll stick with
> > .NET 1.1
>
> In that case, don't be surprised at some slowness compared with some
> Win32 operations, but not all; it really does depend on what you do
> with it.
>
> e.g. Don't try multiple string concatentations without using
> StringBuilder; this is one area where .NET 1.1 is a dog but .NET 2.0
> has really improved..
>
> The .NET 1.1 runtime is universally acknowledged as slow so, IMO, it
> really is not worthwhile to compare Win32 with .NET 1.1 as most
> serious .NET development is already on its way to .NET 2.0.
>
> Having said that, using BDS with .NET 1.1 will prove a useful
> learning experience to get used to what .NET has to offer in the
> gigantic CLR libraries :-)
>
> Joanna
My impression so far of .NET was not good - no real windows library
anything like VCL. Still nothing in .NET 2.0
--
Pete Goodwin
Yes.
> That has to be some really sloppily written Delphi [...]
Coming from Petr I very much doubt it. Look at his published code and
see what you think.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Want to help make Delphi and InterBase better? Use QC!
http://qc.borland.com -- Vote for important issues
Don't get me wrong. I didn't say that .NET is responsible for a bad performance. Instead, I wouldn't care what BDS is on as long as it has good performance. It is Borland's job to tune up the performance of BDS, not Microsoft's.
>The discussion itself is somewhat irritating for me. Developers who are
>programming for Windows and want to avoid .NET, even installed on their
>computer, must stay on Windows XP or stop development, since Windows
>Vista will have it preinstalled. Same as Windows 2003 Server.
Developers who are programming for Windows doesn't have to buy in all the things Microsoft promotes. This is entirely a matter of choice. This is why many people ask to have their pre-installed IE removed while many live happily with their pre-installed IE.
-- CB
It has been discussed here many times. It is due a purely optimized code and
using improper XML parser model (DOM instead of SAX) for Delphi Win32 SOAP
implementation.
Of course one could rewrite it from a scratch to get better result. But .NET
delivers me better implementation (and feature set) and that's what count.
I believe that WinForms painting performance is basically the same problem.
It is much better in version 2.0.
Petr
I was very surprised. Paint.NET starts in 0.5 sec and SharpDevelop in two
seconds (second start). I haven't noticed any painting slowness comparing to
native Win32 application. This is imho major improvement to 1.1 version.
My machine is Athlon64 3.2 GHz, 1GB RAM, SATAII HDD.
But as I said, I don't think that one particular platform is best for every
kind of application. Currently I wouldn't use anything else than .NET 2.0
for robust server side applications (Windows Services, Web Services etc..)
While the native Win32 clients still has some advantages.
That's why I'd like to see DevCo focusing on REAL cross-platform support
(which does not means ideas like pinvokinged VCL.NET) especially the Win32
SOAP implementation and conformance allowing you to communicate with other
platforms.
Petr
> This is entirely a matter of choice.
Agreed (somewhat). Though BDS/Turbo Delphi doesn't force you do use
.NET, it depends only on it. Since Microsoft will continue to push .NET
it might be hard to avoid it generally, even in a Win32 only IDE.
> This is why many people ask to have their pre-installed IE removed
> while many live happily with their pre-installed IE.
>
> -- CB
Sure. But if you cannot rely on a certain installation basis, you must
ship all dll's which can be only optionally installed in Windows by
yourself. On Vista you can assume .NET 3.0 to be installed, so if you
use .NET and ship a Vista only program you don't have to ship .NET 3.0.
The same may be true for other optional modules. E.g. if IE is not
installed, can you assume the XML parser to be part of Windows ? Can you
assume anything to work but pure Win32 API ? (kernel, user dll) ?
If the media player is not installed, can you assume any direct show
modules to work ?
(Shouldn't be a discussion pro IE / Media player).
We only have gone through that "modularization" hell with Windows XP
embedded. We removed some modules - one time USB didn't work, then
Direct Show didn't work and ..... We ended with installing all modules -
generally.
Andre
>
> My impression so far of .NET was not good - no real windows library
> anything like VCL. Still nothing in .NET 2.0
>
Quick example:
Replace all 'a' with 'b' in a file.
In .NET 2.0:
File.WriteAllText(File.ReadAllText('file.txt').Replace('a', 'b'));
And I'm still missing some generic lists in the VCL.
E.g. a sorted list which maps a string to an integer:
In .NET 2.0:
SortedDictionary<string, int> list;
list['frank'] := 100;
Andre
That's the reason why I won't even try the "decoupling .NET" tricks given by the other guys in this NG. I just respect the others' viewpoint/request on Win32 only IDE.
-- CB
Boxing maybe, but surely casting has 0 overhead? It's compiler sugar,
not runtime tricks (with the exception of "magic" casts like String
(PChar), but these aren't generally anything to do with generics)
And comparing 2.0 and 1.1 muddies things as you are also involving two
different runtimes. aiui For some reason, even though .net was just as
fast as native code, the .net 2.0 runtime benefited from some
performance improvement work......
;)
--
Jolyon Smith
you need reflection to write the IDE refactorings?
i'm really confused why Borland chose to buy their refactorings as opposed to roll their own. after all Borland knows their language better than anyone else. they /must/ considering there is no official spec for the language.
the thing that pains me is that what the compiler knows about my source code is not available to me, as an expert writer.
for example, in order to write a refactoring here's a simple thing i need:
for a given identifier, where are all the places where this identifier is being referenced according to the rules of scope.
does CodeDom provide this? not that i can see from what i've read on MSDN.
can you imagine the kinds of experts that could be written if this information was readily available to expert writers? ever hear of CodeRush?
> you need reflection to write the IDE refactorings?
The .Net framework is needed for a lot more in the IDE than just the
refactorings.
--
Nick Hodges
Delphi/C# Product Manager - Borland DTG
http://blogs.borland.com/nickhodges
> Boxing maybe, but surely casting has 0 overhead? It's compiler sugar,
> not runtime tricks (with the exception of "magic" casts like String
> (PChar), but these aren't generally anything to do with generics)
All .NET casts are checked casts; they make sure that the object
really is what you say it is. This is not particularly expensive, but
it's not free, either. For example, TabPage descends from Panel which
descends from ScrollableControl which descends from Control which
descends from Component which descends from MarshalByRefObject which
descends from System.Object ... so when you are casting a TabPage from
Object to Control, the `is` test has to go from TabPage to Panel to
ScrollableControl before it gets to Control.
(Just like native Delphis, really, except for the "all casts are
checked casts" part.)
--
.NET 2.0 for Delphi Programmers www.midnightbeach.com/.net
Delphi skills make .NET easy to learn Great reviews & good sales.
i guess no reason except time and money right? <g>
So in .net TControl(X) is _always_ effectively (X as TControl) ?
Is this really a .net thing or just a C# thing?
--
Jolyon Smith
Yes.
> Is this really a .net thing or just a C# thing?
a .NET thing.
--
Brian Moelk
Brain Endeavor LLC
bmo...@NObrainSPAMendeavorFOR.MEcom
| Boxing maybe, but surely casting has 0 overhead? It's compiler sugar,
| not runtime tricks (with the exception of "magic" casts like String
| (PChar), but these aren't generally anything to do with generics)
Casting could involve an implicit or explicit operator :-)
| And comparing 2.0 and 1.1 muddies things as you are also involving two
| different runtimes. aiui For some reason, even though .net was just as
| fast as native code, the .net 2.0 runtime benefited from some
| performance improvement work......
I think one of the problems with peoples' perception of .NET is swayed by
bad design and coding decisions that have produced bloated, slow code.
e.g. My frameworks had calls to Activator.CreateInstance(...) in several
places, something that can really slow things down if overused. I have now
discovered different coding techniques which have completely eliminated the
requirement for Activator.
Many people see reflection and use it everywhere. I have learned to cache
reflected information after the first call, thus saving even more time than
would have been saved just taking post-JIT speed increases.
> i guess no reason except time and money right? <g>
Yeah, as reasons go, that is a pretty good one. ;-)
> i'm curious now what other features require .net?
It's not like you can point to anyone feature and say "That one
requires .Net, this one doesn't." It's pretty much imbued throughout
the product. More and more, the IDE itself leverages .Net, and so
there's not particular features that depend on it.
.Net is a powerful, full-featured framework. We'd be nuts not to
leverage it instead of writing the functionality ourselves. No need to
reinvent the wheel if a wheel is sitting right there.