October 6, 2006
Nick Hodges has started a very interesting thread and is receiving many responses based on facts, but also many based on myths.
Delphi's Product Manager, Nick Hodges, has started a very relevant discussion asking Delphi users: why aren't you upgrading? The same discussion is happening also on the non-tech newsgroup. First of all, I think this is a very important move: listen to users, including potential and past users. And show you are listening. Second, most of the posts have been relevant and sincere, more than the average for a similar topic. If you haven't done so, go to Nick's blog or the above newsgroup thread and add your voice.
I have to say that I agree with many reasons expressed. While I mostly use Delphi 2006, I have a copy of Delphi 7 installed for programs I had problems porting over, mostly because of third party components or web services-related troubles. On the other hand, I see in many replies the echo of myths that I feel relevant to try to rectify. But let's start with the positive first. Here is a list of reasons not to upgrade I find relevant (even if they don't all apply to me):
- "The Help file provides less information". Yes, this is very annoying. Most links among pages are gone (including some obvious propetrty type to type description links). However, keep in mind that if you disable portions of the help (like C++ and .NET areas), you won't have to pick Win32 every now and then. I wonder if the process of adapting the help to users needs should not be improved, beside fixing the relevant content problems. If my project is Delphi for Win32, why in the world would I want to know about C++ and/or .NET topics when pressing F1?
- "Lack of upgrades for some third party components", including those originally in the box like Quick Reports. Upgrading from old versions of Indy can cause a lot of changes in your code, as well. For many third party components, you have to pay for the upgrade... and maybe you get something new and not fully compatible.
- "BDS reputation, particularly the IDE stability and memory consumption, is awful". And for some good reasons, even if patch after patch it is now fairly good... but it takes much less effort to throw away your reputation than it takes to build it. Two attempts in a row (D8, D2005) and things get out of control.
- "Lack of native 64-bit compiler". Although I wonder how many people are running Win64 these days, it is a relevant issue with a too vague commitment in the roadmap. Anyway, I'd really love a 64-bit compiler from DevCo: Kylix 64 (most of my servers, which would benefit of 64-bit addressing, run on Linux).
- "My development is in .Net 2.0" (not mine... but fully understandable).
- "If you follow too closely behind Microsoft, your customer base will continue to erode" (not stribly an upgrade issue, but fully agreed: either leapfrog them, or take a different road!)
- "I'm still waiting for Kylix4": me too! On the same topic: "True cross-platfom compiler."
- "I do not like the fact that the new Delphi IDE requires/uses dotnet."... I wonder if this decision cannot be reversed, but it it probably too late now.
- "Unicode for ex. is covered by freeware 3rd party libraries"... while the VCL doesn't support it (if not at the database level in Delphi 2006). A Unicode VCL would be a great reason to upgrade for most European and Far East developers, at least.
- "I will miss CodeRush."
- "Well written textbooks and reference book are absolutely required"... relevant for my perspective!
- "Because D7 is the best product that Borland ever made, after Turbo Pascal 7 of course." Good point!
- ".NET framework. Most of the Delphi users never needed this framework anyway." Interesting point of view... I partially second it.
- "Price is definitely an issue"... in particular outside of the US, where Delphi is mostly sold.
- "I would like to see Delphi not only as a language and IDE but more like a platform of its own"... very interesting appraoch.
- "No new Object Relational Mapping tool for Win32 in the product" and supported by the IDE... unelss you install InstantObjects. ECO is for .Net only, what about promoting a Win32 framework as well? (unless you want to build another one, which seems a waste of time to me)
- "A subscription based model with shorter release cycles", probably not a reason to upgrade... but a way to make more people upgrade, if the price is not too high.
On the other hand, this is a list of myths I wish to address (although I don't have time to cover each of them in details):
- "Delphi 6 is so good". The IDE was certainly very stable, but the compiler has a couple of relevent bugs. String concatenation is broken in Delphi 6, for large strings it takes about 100-times Delphi 5 and or 7. Null variant operations, even if partially fixed in the Update 2, are troublesome and have been fixed in later versions.
- "There is nothing new in Delphi 2006 for Win32 programmers". I'm sorry, I don't buy this. There is a lot of new stuff. There are many new language features, relevant improvements in the RTL and core VCL libraries, not the mention the IDE (editor, form designer, much improved debugger...). There might not be enough new features for some users, for sure. But my impression is that many new features are not well know. Reading my Delphi 2006 free ebook might benefit a few...
- On a similar tone: "Lack of new modern language features (try-catch-finally, generics)". Yes, it it lacking those, but Delphi 6/7 are lacking also class data, for-in, static methods, nested types, records with methods and operator overloading... so I'm not sure this is a real reason not to upgrade. For example, I'm sure people would have said "Delphi lacks operators overloading" if this was the case. Now the Win32 language has the feature and you here "nothing new in the compiler". Taking excuses?
- Again, someone mentions "Improved compiler optimizations for generating faster code" failing to notice that inline do exactly that. It is the most relevant optimization since Delphi 2, as far as I know.
- "BDS 2006 for Win32 doesn't produce executables that remarkably different from Delphi 7". This is true only if you install a better memory manager than the native one in Delphi 7!
- "The old IDE was extremely productive"... and it certainly takes time to get used to the new one, but Live Templates or the new Palette, after you've got used to them, can make you much faster. Getting used to a new system takes a while, I hope people are not rejecting the idea altogether. I really don't want the old Component Palette back, it was almost impossible to find the components there. Someone said "Bring back the OLD IDE"... I'd say, "no please!".
- "Lean IDE": just remove from BDS the stuff you don't use/need and it becomes way faster to start, way more stable (in particular without Together), and also takes less memory. Truly, the Turbo versions could have been more "aggressive" on this side, cutting features but providing a more responsive IDE. MAybe DevCo should provde a default installation/registry setting with a super-fast IDE, and then let users add/activate extra features at the cost of a slow-down. This will change the perception...
I hope this helps the positive discussion I've seen so far, and helps DevCo concentrate on both improving the product and telling the world how good it is! Because it is true recent versions of Delphi have now been shining in quality (quite the opposite!) but my perception is that there is also a lack of knowledge of the new features. This summer I gave a 4 days calss at a company. They were looking to advanced topics, but the class included a one day Delphi 2006 introduction (Win32 only). At the end of the day, they decided to upgrade...
posted by
marcocantu @ 3:04AM | 31 Comments
[0 Pending]
31 Comments
Why aren't you upgrading Delphi? Reasons and myths.
"many new language features"? Mmmm... Lesse Operator
Overloading and For-in and inline procedures are all
that jump to mind.
Nothing else really jumps to mind, maybe that's part
of the problem, Except that you have to pay more than
is remotely comfortable to upgrade from the previous
version to get it.
Records with methods attached? Not new, just a
different way to create old style objects, probably
identical plumbing in fact.
Improvements to RTL and memory manager? Third party
work, available for free for D7 if you are willing to
do a little work. Hardly an incentive to upgrade
there, and certainly not an incentive to PAY for it.
The templates are cool, but again, not at that price.
If you are looking at updating any level above pro,
it quickly starts to get uncomfortable paying for
what meger benfits exist...
Comment by Xepol on October 6, 05:54
Why aren't you upgrading Delphi? Reasons and myths.
There's also inlining. Not a big deal, but worth
mentioning.
Under the cover the VCL has also received some pretty
nice updates. The more I dig in the more stuff I find.
The margins and padding is really great when making
GUIs. The guidelines are also great.
Advanced records are a bit more than records with
methods attached. They also have bugs that bit me on
several occasions, so I now stay away from them as
much as possible. Advanced records seem to be on their
way to become more like structures in C++.
As for templates, I would like them more if I could
edit them. After saving a file 2 or 3 times the IDE
becomes slower and slower until it crashes.
Having used Delphi 7 since its release and really
loved the product, I couldn't go back now that I've
used BDS 2006 for several months. Code folding and
refactorings are two things I couln't live without,
and I have yet to try a 3rd party product that could
do a good "simple" rename on my code.
But the stability and speed... Boy, do I miss those!
Comment by Eric Fortier
[http://www.tlnewsreader.com]
on October 6, 10:29
Why aren't you upgrading Delphi? Reasons and myths.
>> The old IDE was extremely productive"... and it
certainly takes time to get used to the new one, but
Live Templates or the new Palette, after you've got
used to them, can make you much faster. Getting used
to a new system takes a while, I hope people are not
rejecting the idea altogether. I really don't want the
old Component Palette back, it was almost impossible
to find the components there. Someone said "Bring back
the OLD IDE"... I'd say, "no please!".
Yes, it was really productive. Everything was simple,
easy to access, and beautiful. Those new features like
Live templates, new component palette etc, might have
been provided as an optional feature, but Borland made
it default, and wiped out previous one. If the
previous one lacks some features, this is where
"innovation" term comes out, right? Borland choose to
create it from scratch, instead of making some new
stuff to make it more usable.
Comment by Excessive on October 6, 11:48
Why aren't you upgrading Delphi? Reasons and myths.
People always tried to knock down demand for the
64-bit with "who is using 64-bit".
However (and I had this problem myself), is that the
absence of this possible scalability option is already
a problem in language selection, when the C++ and/or
C# people _DO_ have this scalability. (in e.g. an app
that uses a lot of mem).
Even the fact that you can already contain morein 3GB
in native Delphi than in .NET doesn't help then. The
manager writes off Delphi as 'NOT SCALABLE" in a
qualitative judgement, even if it is
technically(quantitatively) way more complicated.
(e.g. not realising desk x86_64 they are talking about
can't have more than 4GB of mem etc)
I also second the inlining remark. For me a major
feature. It allowed to inline some iterator functions
used in our framework, which really boosted speed.
Moreover I would like to see more small RTL utils in
the future. The little stuff that started in D6/D7
with strutils, dateutils etc is not spectacular at
first sight, but really cuts in the amount of 3rd
party units that might not be supported in a while,
and avoid every department to have a sizable "own"
library, which is usually half assed (e.g. the string
routines are not encoding safe etc)
Comment by Marco van de Voort on October 6, 12:48
Why aren't you upgrading Delphi? Reasons and myths.
1) FastCode/FastMM: free stuff that work in D7 too.
Should I pay Borland for it? <G>
2) New language features. Most of the introduced due
to .NET compatibility needs. Not all of them worth
an upgrade - operator overloading is ok, but records
with methods?
3) Inline is the only new generated code
optimization - but the compiler still generates
plain old 386 code - to be run on dual core Xeons...
4) VCL: some new GUI components (but TTrayIcon
should have appeared in D3 or D4), but grids still
do not support themes and Win32 core technologies
like Datasnap, remoting and localization didn't see
any improvement. The new controls didn't add
anything not already available in good 3rd
libraries, and most of advanced Delphi user were
forced in the past year to use them, making and
upgrade more expensive - upgrade the library or
modify the application.
5) The IDE: some new features are nice, but I hate
some others. Someone could find the IDE a reason to
upgrade, others can find it a reason *not to
upgrade*.
Comment by Kent Morwath on October 6, 14:21
Why aren't you upgrading Delphi? Reasons and myths.
About Win64: we are just about to order fifty blades
server with dual core 64 bit Xeons. The four-nodes
Oracle RAC will run Oracle 64bit on Win64. Our
application (a memory intensive data processing app)
would run on Win64 too if only we could port it to
64 bit easily.
I agree there could be not many reasons to write
desktop or web Win64 applications right now, but
again DevCo. does not understand Delphi is not only
used to build database frontends like VB or a bunch
of ASP.NET pages.
They have customers who use it for far more complex
applications. And they are losing them to compete in
the MS dominated frontend/webapp market... smart
move.
Comment by Luigi D. Sandon on October 6, 14:36
Why aren't you upgrading Delphi? Reasons and myths.
A Question:
Is inline implicite in the code or how do you use it?
Comment by Adrián Avila... on October 6, 16:39
Why aren't you upgrading Delphi? Reasons and myths.
The dbgrid looks so old and outdated, the VLC team
have done nothing there while in .NET the datagrid has
been remodeled.
Comment by Adrian Avila... on October 6, 16:41
Operator Overloading overvalued?
Kent: First: I agree 100%. The new features are not
really geared towards win32 needs. If you don't have
.NET codebase to be compat with it is useless
syntactic sugar.
Maybe operator overloading is in a sense also .NET
centric. While we usually don't put it in that
category (e.g. C++ has it, and is not .NET), it is not
that useful on Delphi since Delphi has no GC (like
.NET) or static objects (like C++) to make OpOvl on
objects useful.
This leaves the usual complex number example as pretty
much the only important application. (though a hack
using refcounted interfaces might be possible too, or
using TP objects, if they still work)
Or am I missing something here?
Comment by Marco van de Voort on October 6, 17:31
Why aren't you upgrading Delphi? Reasons and myths.
Adrián Avila: AFAIK you declare a
function/procedure/method as "inline" and the
compiler decides if to inline it or not, depending
on size, number of calls, etc.
Comment by Kent Morwath on October 6, 18:28
Why aren't you upgrading Delphi? Reasons and myths.
"Well written textbooks and reference book are
absolutely required... relevant for my perspective!"
Marco, do you plan to sell books and maybe write new
ones and publish them via services like lulu.com or
the like?
It could be interesting to have some "gurus" to work
on something alike a up-to-date version of
the "Delphi Developer's Handbook" to cover advanced
topics.
DevCo. in turn could advertise them on its site.
IIRC, I never saw anything about Delphi books on
Borland site...
Comment by Luigi D. Sandon on October 6, 18:45
Why aren't you upgrading Delphi? Reasons and myths.
I am sorry to say that, but from outside it looks like
they just don't have a capable team anymore.
I'm not just talking about the last couple Delphi IDEs.
But what about those issues where an outsider fixes a
long standing bug without even having the source code?
An outsider "hacking" the IDE a couple hours after the
release so that you can use more than one personality,
after DevCo says there are >>technical<< reasons for
not being able to do this? An outsider maintaining
Kylix, so that it runs on newer Kernels?
What's up with that company? How many programmers are
left there?
Comment by Fritz on October 6, 19:18
Why aren't you upgrading Delphi? Reasons and myths.
D7 that I am using for my current development has
more features that I can say grace over. Sure it's
problems but I live with them.
But, mostly prior to the Turbo Delphi release I
really had no need to upgrade as my target customer
base could care less about .Net; so why bother with
all of the extra .Net functionality (Bulk) in D2005
and D2005 when I had no need for it.
Now that Turbo Delphi is out; I have a reason to
upgrade. So what issues are keeping me from making
the switch:
1. In the middle of development - I never make major
changes in tools mid-stream unless there is no other
way.
2. Waiting for the 3rd Party vendors to upgrade their
tools.
3. Waiting for the 1st or 2nd round of updates to be
released.
I've downloaded the Explorer product and I am looking
forward to loading it into a VM and give it a go in
the next few days.
Comment by Bernard Simmons on October 7, 00:31
Why aren't you upgrading Delphi? Reasons and myths.
Why they are selling such a poor quality product is
a mystery.
Comment by Someone on October 7, 14:53
Why aren't you upgrading Delphi? Reasons and myths.
"I really don't want the old Component Palette back,
it was almost impossible to find the components there."
I assume that means you didn't realize you could
customize the palette in D7? Investing a minute of
your time to sort and shorthand the tabs could make a
world of a difference, like being able to access
200-300 components in *at most* two clicks, while on a
800x600 resolution.
The new palette is *utterly* unable to offer this
convenience, finding anything requires multiple mouse
and keyboard clicks... and if you don't already know
the component name, your chance of finding it in less
than 30 seconds are minute. And don't get me started
on the 16x16 component icons, while traditionnally
component icons have been 24x24 or 32x32, even with
larger icons, the old palette offers access to more icons.
Comment by Eric on October 7, 20:48
Why aren't you upgrading Delphi? Reasons and myths.
I mentioned this over at Nick's blog, but I'll put it
here as well...
I personally would like to see more cross-platform (
oooo dirty word ) support. I have even started looking
into using the opensource FreePascal (
http://www.freepascal.org ) compiler because it works
on Win32, MacOS X, Linux and a host of other Operating
Systems as well as generating 64bit native code. The
downside is that they are only Delphi 5 compatible,
but it FPC itself has other language enhancements. I'm
really starting to think that this is a small price to
pay for such a wide variety of OS support. Heck they
even managed to get the compiler to create Game Boy
Advanced executables (
http://itaprogaming.free.fr/tutorial.html )
I would rather use a DevCo product, but since .NET
cross-platform capability is the only option I may
have to say no thanks and look at FreePascal and their
fledgling RAD IDE called Lazarus ( which also works on
MacOS X and Linux ). Sure the IDE is no where near as
feature complete as Delphi, but it does not have the
same number of dedicated IDE developers that
DevCo/Borland does either. Also since it's OpenSource
anyone can help out and make the IDE better, if they
so desire, rather than waiting for Inprise/Borland/ or
DevCo to implement a specific feature. Same goes for
the compiler.
Comment by Dominique Louis
[http://www.SavageSoftware.com.au]
on October 8, 22:39
Why aren't you upgrading Delphi? Reasons and myths.
> Why they are selling such a poor quality
> product is a mystery.
Agreed. However, it's not just about the quality. I
like to believe that in life you get what you pay for.
You pay $100 for a lower quality HOME printer and
$1,000 for a higher quality OFFICE printer.
DevCo, say sorry. Apologise to "all" those who you
alienated with D8 and D2005. Intelligent people use
Delphi and a huge majority will warm to your sincere
apology. Tell them you are not going to release
another major update until you get D2006 "fixed".
Alternatively, admit you are no longer the quality
software house you used to be and drop your prices.
Sell your product as a "not bad" development suite
rather than pretending to deliver the "worlds best".
Comment by Hobby on October 9, 07:03
Why aren't you upgrading Delphi? Reasons and myths.
"A Unicode VCL would be a great reason to upgrade for
most European and Far East developers, at least."
And a lot of other people. Australia, for instance,
despite having more than 500 local languages[1] and a
heap more non-local ones in use, suffers from
English-only software. Delphi is a great hindrance to
those of us trying to work in a multilingual market.
Simple stuff, like (in D7) the + operator not being
overloaded to allow WideString = WideChar + WideChar,
through to the hassle of working out when silent
down-conversion to narrow strings is taking place. I
mean, even declaring widestring constants currently
eludes me. Basic, basic stuff. Forget full UTF32
support (blank look?), even UTF16 is not supported.
</rant>
I'm currently struggling to teach myself i8n while
helping supervise an outsourced i8n project, and it's
really hard going. Upgrading to D2006 would be much
more realistic if it would help with that, but it
doesn't seem to so the 3rd party problems mean we're
still usng D7.
[1] only about 50 of them are the first language of
more than a few people any more. But traditional
Australia makes pre-unification Europe look
monocultural in comparison.
Comment by Moz on October 9, 11:02
Why aren't you upgrading Delphi? Reasons and myths.
Hi Marco
I was the one who said:
"Improved compiler optimizations for generating
faster code"
You have this under "Myths", when my comment was
intended to be a suggestion for additional things
that would make me upgrade outright. That's a little
unfair.
I absolutely agree that inlining is a very worthwhile
upgrade feature in D2006. It is maddening in D7 to
watch the FPU clear its stack for every log(), sin()
and so forth in the midst of long formulas :) Come
to think of it, I don't know if the math functions
have been inlined in D2006 - will have to check up on
that.
Operator overloading is too a Good Thing. There are
those that don't like operator overloading from
design principles because they have implicit, rather
than explicit behaviour--I used to be one of these
people--but there are problem domains (complex math
and interval arithmetic, for example) where it makes
a compelling difference to expression. I think I
would have preferred the FreePascal approach to
operator overloading, but I have no personal
experience with the D2006 approach, so I will need to
investigate that.
The reason for my "faster code" question was related
to the fact that C, and especially FORTRAN, tend to
produce faster code for math applications. Since
Delphi too produces native code, I imagine there is
some remaining scope for improvement in the
optimization. Though many people would consider
improvement in the code generation as unimportant,
e.g. "it's fast enough aleady", I would not, as I
write scientific and engineering applications that
are usually CPU-limited. I realise I might be in a
small minority.
The present situation is actually /very good/ for
Delphi:
http://dada.perl.it/shootout/delphi.html
and the shootout shows Delphi is no slouch for number-
crunching, where it regularly appears in the top 5
(will people be surprised by this?). But, there are
some benchmark tests in which Delphi is not in the
top group and I am willing to pay (upgrade) if it's
code generation improves, even from the great
performance it already provides.
btw, I enjoy your blog :)
Caleb Hattigh
Comment by Caleb Hattingh
[]
on October 9, 11:33
FPC myths + shootout + Fortran/C math.
FPC targets D7 as compat goal, not D5. Some features
(like inline, operator overloading) were later also
implemented by D2005+).
Shootout, newer episodes of the language shootout are at
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1&xmem=0.1&xloc=0&binarytrees=1&chameneos=1&message=1&fannkuch=1&fasta=1&knucleotide=1&mandelbrot=1&nbody=1&nsieve=1&nsievebits=1&partialsums=1&pidigits=1&recursive=1®exdna=1&revcomp=1&spectralnorm=1&hello=1&sumcol=1
but are Linux centric. However the fpc/delphi speed
quotient is close enough to 1 to assume them to be the
same. Also the defects in optimization (no typical
benchmark/numeric optimizations that e.g. help in the
benchmarks that are numeric+recursive in nature) are
pretty much the same.
In particular, note how FPC rises in the ratings if
you increase the importance of memoryfootprint. Even
if only from 0.1 to 0.2. (and FPC is more memory
hungry than Delphi, due to a bit lower RTL asm content)
I don't agree with of the above posters about numeric
speed. Delphi is about userfriendliness and
production. If you really want to improve performance,
you'd have to create additional compiler modes with
specific optimizations, apart from the RAD model.
A very simple issue is e.g. fwait. One needs a fwait
after each copro instruction to be able to properly
convert FPU exceptions into language (RTL) exceptions.
Change this for the hand full of numerical people, and
half of the business apps won't work anymore, with FPU
exceptions popping up on the next instruction, due to
e.g. handcrafted pre D6 strtofloatdef's)
My personal top 2 feature list is:
#1 improving of the container types. (generics, but
also the scalability of the current types sucks)
#2 unicode
#3 a decent header conversion tool/conversion kit.
(FPC's h2pas and Bob Swarts headconv/darth are nice
stopgaps, but still not productive enough. I doubt
this is solvable with a single universal tool, so
probably it will be more a very
configurable/overridable parser thing) I'm close to
hardware, and translating SDKs is tedious, and
ActiveX's often suck, both in quality and performance.
#4 a vast expansion of utility routines and units.
Standarization, and removing/reducing the need for
maintaining custom utility libs. D6/D7 were a good
step in that direction. Continue. E.g. a POS and POSEX
variants that search from the end etc.
(don't know what later 2k Delphi's add in this category)
In previous jobs I have worked nearly everywhere with
custom object persistance frameworks. And while I
despise the term in general, this was a bit the old
story about "reinventing the wheel". Both DB as
client-server related. I'd like a nice not too big or
complicated OOP persistance framework, with Indy
integration. For initial prototyping, small apps etc.
Don't try to do everything at once. Stay focused,
performant, and to the point.
Comment by Marco van de Voort on October 9, 15:41
Why aren't you upgrading Delphi? Reasons and myths.
I'm not really interested in the supposed new things
that have been put in the compiler. All I know is this,
the floating point stuff has not been touched since
98-99.
I think the main reason is lack of understanding and/or
talent at Borland or DevCo or whatever it is they call
themselves now. The floating point code is a black hole
for them people delve into it and are never heard of
again. There are manymeasures for what consitutes a
modern compiler, one of the more prevelent and major
metric is the floating point capabilities of the compiler.
Don't fool yourself, Delphi isn't just about VB users
wanting to look cool, or people hacking DBs.
The following code when compiled with 2006 and D5 produce
pretty much equivelent assembly with optimizations turned
on the same results.
function Orientation(const
x1,y1,x2,y2,Px,Py:double):Integer;
var
Orin : double;
begin
Orin := (x2 - x1) * (py - y1) - (px - x1) * (y2 - y1);
if Orin > Zero then
Result := LeftHandSide
else if Orin < Zero then
Result := RightHandSide
else
Result := CollinearOrientation;
end;
(* End of Orientation *)
Why oh why oh why are 6 8-byte memory blocks being pushed
onto the stack, when it is made insanely clear through
const correctness that the user expects the method not to
change the parameters values and that the function is
guarenteeing to the user it wont change anything.
Why wont the compiler just push references around? why
oh why oh why?
Comment by Arash Partow
[http://www.partow.net]
on October 10, 04:00
Why aren't you upgrading Delphi? Reasons and myths.
Arash: why? Because it's the documented behaviour.
Comment by Luigi D on October 10, 23:38
Why aren't you upgrading Delphi? Reasons and myths.
Aresh: why? Because it's the documented behaviour.
Read the help, "parameter passing":
"Value and constant (const) parameters are passed by
value or by reference, depending on the type and
size of the parameter: ...
A real parameter is always passed on the stack."
While "Variable (var) parameters are always passed
by reference".
I guess this choice may have a reason behind.
PS: please Marco, delete my previous partial post.
Thanks.
Comment by Luigi D. Sandon on October 10, 23:43
Why aren't you upgrading Delphi? Reasons and myths.
Luigi (see I spelled your name correctly),
This "documented behavior" was documented over 7 years
ago.
Modern compilers as in compilers written today for today's
architectures and applications do this optimization very
readily and easily.
mmmmm...
now that I think about it, turbo pascal 6.0 and borland
pascal 7.0 did it too with what was known as Real!
if anything its a regression in Delphi.
Just because a document says something, doesn't mean it
has to be set in stone forever.
Comment by Arash Partow
[http://www.partow.net]
on October 12, 03:28
Why aren't you upgrading Delphi? Reasons and myths.
In regards to compiler optimizations and numeric
performance, it would be really very nice if the
compiler used modern features like MMX, 3DNOW,
3DNOW+, SSE, SSE2, SSE3 in its code generation.
Comment by Joe on October 12, 22:04
Why aren't you upgrading Delphi? Reasons and myths.
Arash: sorry for mispelling your name in my second
post - it was correct in the first :)
I mean, if the behaviour is documented there could
be a good reason for its choice. From documentation
is clear that "const" is not "var" with non-mutable
parameters. Interger behave the same way. Why? I do
not know, we should ask in the Delphi compiler
newsgroup. Maybe because it allows the compiler to
optimize code better. Maybe just because they were
sloppy :)
Comment by Luigi D. Sandon on October 12, 22:44
CrossKylix
I do use a lot the CrossKylix Crosscompiler, which
run the original ELF Kylix compiler in the Win32-
Delphi IDE.
With this tool, you can use some cross-platform
widgets both under Win32 and Linux, from the stable
Delphi IDE:
MSEGUI
A great implementation of an IDE (using FPC as a
compiler) and a cross-platform GUI light widgets
hierarchy.
http://mypage.bluewin.ch/msegui/
LPTK
Less advanced. But source code interesting to read.
http://lptk.sourceforge.net/
Both are tree Unicode, of course!
But the object hierarchy is new: if you want to
retrieve the VCL behaviour, just use the LCL (and
Lazarus).
Comment by Arnaud B.
[http://crosskylix.untergrund.net/]
on October 14, 01:19
Why aren't you upgrading Delphi? Reasons and myths.
I am a college educator, not a professional
developer like most of you out there. Years ago, I
learned programming with Turbo Pascal. I then
started with D3, and upgraded to D4, D5, and D6.
Did not get D7, but got D2005 and D2006. I am sad
to say that I was terribly disappointed with D2005.
D2006 is much better, but in the time it takes the
IDE to fully load, I can load D6, modify code,
recompile, and be on to another task. And at least
for my needs, I have yet to come across a feature in
D2006 that is not in D6. So most of my development
is still done with D6. I will continue to upgrade
to newer versions for the sake of supporting Borland
(the educational discounts allow me to do so), but
Borland (or the new company) will have to give
serious attention to product quality, or they will
eventually lose even the most loyal followers.
Another note. Borland will have to again establish
a presence on college campuses. Most of my
colleagues in the computer science department do not
even know anything about Delphi! How did this
happen? Wasn't Turbo Pascal the number one tool at
some point?
Comment by Mac on October 19, 01:04
Why aren't you upgrading Delphi? Reasons and myths.
Arash: it could be that you indeed hit on some TP
legacy there. Mostly the "on-the-stack" behaviour
being needed for coprocessor emulation. However,
despite archaic reasons, it wouldn't surprise me if a
significant percentage of users apps would break if
you change it. (e.g. because they directly blockwrite
a float param or so).
This is a big dilemma for Borland. If they change
something that makes sense performance wise, there is
a whole range of users whose apps will after 7 working
versions (at least in their perspective) break, and
just cry "Borland broke my app" and not upgrade. A few
tweakers twisting out the last ounce won't make up for
that.
One of the origins of this problem is that Borland
never made a difference between language/library
definition and implementation details. IMHO they
should have marked more as "can change in the future",
at least they could say "we warned you" if they really
_have_ to change something (something that could have
been useful during .NET and Kylix transition times too).
When they plan something, they could reprogram TeamB
to start bringing out the message that the next
version won't do "xxx", and get maybe a certain
percentage to clean up prerelease.
Or use the warning system a release earlier (like the
D7 unsafe warnings)
Joe: MMX, 3DNOW etc hardly bring anything. You need
code rewrites for that (e.g. use special MMX/SSE
datatypes).
The only thing they could do is what FPC has done,
optionally use SSE2 as registered (RISC-ky)
coprocessor, for e.g. graphical uses, while retaining
the old copro mode for stuff that needs a very exact
definition (IEEE) of the copro actions.
Comment by Marco van de Voort on October 30, 13:07
Why arent you upgrading Delphi? Reasons and myths.
Hi,
I'm currently TRYING to update to Delphi 2007. I have
to take over a D5 project and while I use D7, I told
the client to do it directly to Delphi 2007 so 'they
are set for the future'.
It uses xmlpartner (xml partner) xml component. VERY
good xml component. Yet with the changes in widechar
from Delphi 7 to delphi 2007 I get 'invalid XML
character found'. And the component is rendered
useless.
I've started to try to fix it myself, but it is a lot
of ground (code) to cover. And maybe there is an
easier fix then rewrite a lot of code.
So that's why I would not upgrade.
the xml partner is found @
http://sourceforge.net/projects/tpxmlpartner/
Should anyone got this working on delphi 2007, I
would be glad to hear it!.
Thanx.
Comment by mtjs on March 13, 00:42
Why arent you upgrading Delphi? Reasons and myths.
Very simple,
I am using Delphi 2007 for Win32, and i've bought it
2-3 months before and then CodeGear announced Delphi
2009, up to here everything is ok but CodeGear says
that if you want to buy 2009 (for new user -
Electronic license) you pay 1,092.73USD but if you
want to plan to buy Delphi 2007 you pay 1,092.00USD
(difference is 0,73 USD = 73 Cents) but if you paid
1,092.00USD to Delphi 2007 and you want to upgrade to
2009 you must pay 467.27USD (nearly half of its total
value :) ) ok, what are the new features? Full Unicode
support, Natively PNG Support, Ribbon, Resource Editor
and many VCL and other developments. OK now, what are
the value of these improvements? 0,73USD OR 467.27USD
? If 0,73USD then let me pay 5USD and start to use
Delphi 2009, but if it is 467.27USD, the price of
Delphi 2009 should be 1,092.00USD (price of Delphi
2007) + 467.27USD (Total value of price of
improvements as CodeGear aid ;) ) isn't it??????
Best regards to everyone...
Comment by Alper on September 26, 04:55
Post Your Comment
Click
here for posting
your feedback to this blog.
There are currently 0 pending (unapproved) messages.