Why Pascal for Delphi?
h_kraus
wondering if people in this group may shed some light on why
Borland would have chosen Pascal for Delphi, as opposed to
the big "heavyweights" in the commercial environment, namely
BASIC and C/C++.
Or why not Smalltalk if they wanted something other than the
two "big" guys?
Thanks, Harold
hkr...@accessone.com
Janos Szamosfalvi
: I haven't used Pascal, and have no bias for or against, but I was
: wondering if people in this group may shed some light on why
: Borland would have chosen Pascal for Delphi, as opposed to
: the big "heavyweights" in the commercial environment, namely
: BASIC and C/C++.
First, both Visual Basic and Visual C are already well estabilished
products. Second, Borland already has a C++ compiler for Windoze.
Third, Pascal is superior to both C/C++ and Basic. (this is my opinion
and not a flamebait, so please don't start a holy war). Lastly, I
think Turbo Pascal is/was Borland's flagship product.
: Or why not Smalltalk if they wanted something other than the
: two "big" guys?
Borland wasn't very successful with languages other than Pascal
and C.
Ron Loewy
Janos Szamosfalvi <sza...@saul3.u.washington.edu> wrote:
>HKraus wrote:
>: I haven't used Pascal, and have no bias for or against, but I was
>: wondering if people in this group may shed some light on why
>: Borland would have chosen Pascal for Delphi, as opposed to
>: the big "heavyweights" in the commercial environment, namely
>: BASIC and C/C++.
>
>First, both Visual Basic and Visual C are already well estabilished
>products. Second, Borland already has a C++ compiler for Windoze.
>Third, Pascal is superior to both C/C++ and Basic. (this is my opinion
>and not a flamebait, so please don't start a holy war). Lastly, I
>think Turbo Pascal is/was Borland's flagship product.
>
Borland "owns" pascal and could implement a lot of language structures
that were needed for a system as Delphi (Just as MS "owns" basic and
added all the stuff they wanted in VB).
When Borland tried to add stuff to the C++ language (Remember OWL 1?) the
market did not follow and Borland was criticized for using non-standard
language.
This is just my $0.02
Ron.
--
Ron Loewy, Author of HLPDK/PA, PASTERP and Interactive Help |
rlo...@panix.com
Len Freedman
: I haven't used Pascal, and have no bias for or against, but I was
: wondering if people in this group may shed some light on why
: Borland would have chosen Pascal for Delphi, as opposed to
: the big "heavyweights" in the commercial environment, namely
: BASIC and C/C++.
Probably because Pascal is easier to learn from scratch--nobody learns C
as a first language! I think Visual Basic came about for the same
reason. I know people who never programmed in DOS, only in Windows,
starting from square one with Visual Basic.
: Or why not Smalltalk if they wanted something other than the
: two "big" guys?
Hahahaha. That's a good one. 8^) Actually, Borland had a Prolog once,
but dropped it, presumably because it didn't sell well enough. Who uses
Smalltalk? Lots of people use Pascal.
It might be that Ver. 7 will be the last Borland/Turbo Pascal; perhaps
making Pascal the base language for Delphi is Borland's way of holding on
to us Pascal adherents. You might not expect to see C/C++ users flocking
over to Delphi when they have so many commercially available toolkits and
object classes, but old Pascal addicts (like me) and new programmers
might be more likely to try it.
--
Len Freedman (le...@netcom.com)
Janos Szamosfalvi
: >> Pascal is superior to both C/C++ and Basic <<
: This is probably where I am most "in the dark". Not having used
: Pascal I was wondering what fans of the language like better
: about it versus the C/BASIC steamroller.
Pascal vs. Basic: Basic has no pointers and variables can be declared
on the fly, which means if you have a typo, Basic assumes it's a new
variable. Once it took me almost a day or so to "debug" InPort and
Inport, or something silly like this in Verilog.
Pascal vs. C: just read this group and you'll know more than enough
about it. One major thing that Pascal is typesafe while C is not.
John N. Hodges
I think there are two main reasons -- first, compiling speed.
Delphi is constantly compiling your app in the background to
allow for the environment to work. C simply can't compile fast
enough to keep up and provide the kind of development environment
that Delphi does.
But more importantly, Borland in effect -- and I'll get flamed
for this, too -- owns the Pascal language. Delphi requires some
definite changes and enhancements to the language. C must,
because of market forces, stay stucj to the ANSI standard.
Borland doesn't feel that pressure in the Pascal arena.
And finally, if you get a look at Delphi, you'll see. It just
works right. C wouldn't fit this paradigm, IMHO. (Flame away
for that last one!)
Bob Fabiszak
>In article <3i8s8l$p...@news.u.washington.edu>,
>Janos Szamosfalvi <sza...@saul3.u.washington.edu> wrote:
>>HKraus wrote:
>: I haven't used Pascal, and have no bias for or against, but I was
>: wondering if people in this group may shed some light on why
>: Borland would have chosen Pascal for Delphi, as opposed to
>: the big "heavyweights" in the commercial environment, namely
>: BASIC and C/C++.
I believe another reason was that the Pascal group was the one that came up with
the idea and began to implement it. Plus, from my own experience of having used
several flavors of Basic, Borland's Pascal, and C++, Pascal is much more powerful
than Basic, but only marginally more difficult to lear, and Pascal is only
marginally less powerful than C++ and much easier to learn and use.
ANOTHER CO
literally millions of programmers familiar with C. Not as many as BASIC,
perhaps, but BASIC has some holes which are hard to fill.
Also, PASCAL is simpler, less variation in structure allowed, less
synonyms (actually, smaller stock libraries, yet same or even better out
of the box functionality), so it is easier to learn, and faster to
compile. As an example, Borland's standard Pascal libraries include
functions to return the size of a file, to insert a substring into a
string, and many other totally useful ones, which you have to write
yourself in C/C++. Watch and watch and watch your C compiler sort through
huge libraries containing essentially variations of the same thing such as
strcmp(), strcmpi(), strstr() and you'll see what I mean.
There are some features of Borland's traditional implementation of
Pascal which are hard to beat. For instance, no need to make header files
and include prototypes in every module. Declare a function once, and it
is available throughout your program.
- Jeff Napier, d.b.a. Another Company -
RGDawson
>I haven't used Pascal, and have no bias for or against, but I was
>wondering if people in this group may shed some light on why
>Borland would have chosen Pascal for Delphi, as opposed to
>the big "heavyweights" in the commercial environment, namely
>BASIC and C/C++.
This question was asked at a demo of Delphi in Denver I was at a while
back. The answer was:
"'cause the the guy the wrote Delphi knows Pascal." The audience chuckled
but there is at least a little trith to that story, since, according to
the Borland reps at the demo, The same guy that does Pascal for Borland
did Delphi.
The more serious reason cited by Borland at the conference was the
ability/freedom to adapt the language to suite them. They claimed C++
just wouldn't work and they have no plans to ever create a C++ Delphi
-Greg Dawson
Blofelt
>Agree about the holy war. I'm not wanting a "tastes great/less filling"
>war to break out, just actual users preferences and reasons. Been
>in the business too long to have any vendor or platform "loyalty";
>just want the best tool for the task at hand.
>
>Thanks, Harold
>hkr...@accessone.com
>
Other than the neat type checking and pointers, Turbo pascal is a very
good implementation of a true OO language, that isn't too hard to get to
grips with.
Kosten
spe...@dircon.co.uk
Bryan Slatner
>Seriously though, I think they chose Object Pascal because they could
>mould it to work with Windows. C and C++ are hidebound by standards
>and cannot be changed without an enormous hubbub. Borland have extended
>their Pascal with Object in a most tasteful way in order to supply
>what may be the next big event after the Ninja Turtles. I honestly
>believe this is the most significant program since Windows 3.1.
>Pascal as the language is not an really an issue.
Actually, one of the primary reasons for the choice of Pascal is that the
underlying compiler has to be lightning fast. Delphi includes a fault
tolerant compiler which is constantly parsing your source code in the
background to keep data in the Object Inspector up to date. It would be near
to impossible to have a real-time fault-tolerant compiler of this nature based
on BASIC or C/C++.
Later,
Bryan Slatner
+---------------------------------------------------------------+
| The opinions expressed | "Of COURSE you can read from |
| herein are not | a read-only file." |
| necessarily the opinions | --Me, to an actual customer |
| of TurboPower Software. | |
+---------------------------------------------------------------+
Mario
>This question was asked at a demo of Delphi in Denver I was at a while
>back. The answer was:
>"'cause the the guy the wrote Delphi knows Pascal." The audience chuckled
>but there is at least a little trith to that story, since, according to
>the Borland reps at the demo, The same guy that does Pascal for Borland
>did Delphi.
>The more serious reason cited by Borland at the conference was the
>ability/freedom to adapt the language to suite them. They claimed C++
>just wouldn't work and they have no plans to ever create a C++ Delphi
I think the main reason Borland went with Delphi was 1) Speed 2) They already
had a stable optimizing compiler for it (in BP7)
Tim
Mario
>I think there are two main reasons -- first, compiling speed.
>Delphi is constantly compiling your app in the background to
>allow for the environment to work. C simply can't compile fast
>enough to keep up and provide the kind of development environment
>that Delphi does.
>But more importantly, Borland in effect -- and I'll get flamed
>for this, too -- owns the Pascal language. Delphi requires some
>definite changes and enhancements to the language. C must,
>because of market forces, stay stucj to the ANSI standard.
>Borland doesn't feel that pressure in the Pascal arena.
>And finally, if you get a look at Delphi, you'll see. It just
>works right. C wouldn't fit this paradigm, IMHO. (Flame away
>for that last one!)
Are you sure that Delphi does compilation in the background. I am aware that
it is capable of incremental compilation (it recompiles only the parts you
have changed) but I never heard of its background compilation feature. Perhaps
you would like to clarify.
Another reason I think Pascal was used is that Pascal was expressly designed
to allow single pass compilation, whereas C was not. Besides Pascal is so much
more predicatable and readable.
tim
John R. Reagan
In article <3iapd1$j...@nps.navy.mil>, jnho...@nps.navy.mil (John N. Hodges) writes...
>But more importantly, Borland in effect -- and I'll get flamed
>for this, too -- owns the Pascal language.
Here's your flame:
Borland DOES NOT OWN the Pascal language. The Pascal Standards Comittee
does! If Borland desires to add their own EXTENSIONS to make their product
more productive and more usable in certain environment, that is their
choice. However, you cannot treat Borland's Pascal product as THE Pascal
anymore than I can treate Digital's Pascal as THE Pascal.
---
John Reagan
Application Compilers and Environments
Digital Equipment Corporation
rea...@hiyall.enet.dec.com
Disclaimer: The opinions and statements expressed by me are not
necessarily those of Digital Equipment Corporation.
---
Jerry Gardner
>Here's your flame:
>
>Borland DOES NOT OWN the Pascal language. The Pascal Standards Comittee
>does! If Borland desires to add their own EXTENSIONS to make their product
>more productive and more usable in certain environment, that is their
>choice. However, you cannot treat Borland's Pascal product as THE Pascal
>anymore than I can treate Digital's Pascal as THE Pascal.
I beg to differ. While, technically, nobody really "owns" Pascal, Borland
has probably the largest market share of any Pascal compiler vendor. I'm
even willing to bet that Borland's market share is one or more orders
of magnitude larger than their nearest competition.
Even if some standards committee agrees on a "Standard Pascal", the Borland
implementation will continue to be the defacto industry standard.
John N. Hodges
>Are you sure that Delphi does compilation in the background. I am aware that
>it is capable of incremental compilation (it recompiles only the parts you
>have changed) but I never heard of its background compilation feature. Perhaps
>you would like to clarify.
Well, that's what Anders and Charlie Calvert said at Software Development '95, and they ought to know....
>
>Another reason I think Pascal was used is that Pascal was expressly designed
>to allow single pass compilation, whereas C was not. Besides Pascal is so much
>more predicatable and readable.
>
>tim
These are obviuosly part of the reason as well.
---
* LT Nick Hodges, USN Naval Postgraduate School *
* jnho...@nps.navy.mil Information Technology Management *
* CIS: 71563,2250 AOL: NHodges Monterey, CA *
* "A man's gotta know his limitations...." - Clint Eastwood *
* Visit my homepage: http://vislab-www.nps.navy.mil/~jnhodges *
John N. Hodges
>Here's your flame:
>
>Borland DOES NOT OWN the Pascal language. The Pascal Standards Comittee
>does! If Borland desires to add their own EXTENSIONS to make their product
>more productive and more usable in certain environment, that is their
>choice. However, you cannot treat Borland's Pascal product as THE Pascal
>anymore than I can treate Digital's Pascal as THE Pascal.
>
>---
Ok. here's my return flame! <g>
Who cares?
Oh boy, here it comes now.....
John N. Hodges
>I beg to differ. While, technically, nobody really "owns" Pascal, Borland
>has probably the largest market share of any Pascal compiler vendor. I'm
>even willing to bet that Borland's market share is one or more orders
>of magnitude larger than their nearest competition.
>
And people complain about MS dominating the market! <g>
David Emami
>From: sza...@saul3.u.washington.edu (Janos Szamosfalvi)
>HKraus wrote:
>: I haven't used Pascal, and have no bias for or against, but I was
>: wondering if people in this group may shed some light on why
>: Borland would have chosen Pascal for Delphi, as opposed to
>: the big "heavyweights" in the commercial environment, namely
>: BASIC and C/C++.
>First, both Visual Basic and Visual C are already well estabilished
>products. Second, Borland already has a C++ compiler for Windoze.
>Third, Pascal is superior to both C/C++ and Basic. (this is my opinion
>and not a flamebait, so please don't start a holy war). Lastly, I
>think Turbo Pascal is/was Borland's flagship product.
Also, due to the much greater compile time for C/C++, the "always
compiling in the background" part of Delphi would be intolerably slow.
Besides, for me the fact that Delphi uses Pascal instead of C is a major
reason in *favor* of using it. And I'm sure I'm not the only one who
holds that sentiment.
And if you haven't seen it yet: Delphi RULES! Delphi KICKS ASS!!
Huh huh, huh huh, huh huh...
(Beavis&Butthead mode off)
Ron Loewy
John R. Reagan <rea...@hiyall.enet.dec.com> wrote:
>
>In article <3iapd1$j...@nps.navy.mil>, jnho...@nps.navy.mil (John N. Hodges) writes...
>>But more importantly, Borland in effect -- and I'll get flamed
>>for this, too -- owns the Pascal language.
>
>Here's your flame:
>
>Borland DOES NOT OWN the Pascal language. The Pascal Standards Comittee
>does! If Borland desires to add their own EXTENSIONS to make their product
>more productive and more usable in certain environment, that is their
>choice. However, you cannot treat Borland's Pascal product as THE Pascal
>anymore than I can treate Digital's Pascal as THE Pascal.
>
For all practical reasons when people say pascal they refer to Borland's
implementation. This is not true for C++. Microsoft owns Basic for all
practical reasons.
No one will make a fuss if Borland adds something to Pascal, but a lot of
people made a lot of noise when OWL1 required the DMT extensions in C++.
When people look at pascal compilers on non-Dos/Windows versions they
usually look for Borland compatability, the only exception is the
Macintosh where Think is the "standard".
Let's not argue on who really owns Pascal, I think that what the original
post claimed - that Borland can do what they want with Pascal and the
majority of people will accept it, is true.
Jon Mundsack
: I haven't used Pascal, and have no bias for or against, but I was
: wondering if people in this group may shed some light on why
: Borland would have chosen Pascal for Delphi, as opposed to
: the big "heavyweights" in the commercial environment, namely
: BASIC and C/C++.
A valid question. I personally say it's about damn time! C is
over-rated and tempermental, VB is clunky. I happen to find Pascal a
happy medium between the two.
--
Jon Mundsack
mund...@netcom.com
Janos Szamosfalvi
: I think the main reason Borland went with Delphi was 1) Speed 2) They already
: had a stable optimizing compiler for it (in BP7)
Speed? Yes.
Stable? Yes.
Optimizing? Well, TP does some simpler (obvious) optimizations,
but in comparison with some other compilers it doesn't fare very well.
Duncan Murdoch
>Optimizing? Well, TP does some simpler (obvious) optimizations,
>but in comparison with some other compilers it doesn't fare very well.
... except in sales. I think BP chooses a good compromise between speed of
compiling and speed of executable, and I think its market position relative
to competing compilers proves that.
IMHO, the last 15 years of PC history prove that optimizing compilers can't
match a good assembler programmer (at least on a CISC platform like the x86).
The way to get fast executables isn't to buy a better compiler, it's to buy a
profiler, and rewrite the critical sections in assembler.
Duncan Murdoch
Janos Szamosfalvi
: In article <3ijh6o$a...@news.u.washington.edu> sza...@saul3.u.washington.edu (Janos Szamosfalvi) writes:
: >Optimizing? Well, TP does some simpler (obvious) optimizations,
: >but in comparison with some other compilers it doesn't fare very well.
: ... except in sales. I think BP chooses a good compromise between speed of
: compiling and speed of executable, and I think its market position relative
: to competing compilers proves that.
Market position is heavily influenced by many other things.
A good contemporary example would be OS/2 vs. Windows.
: IMHO, the last 15 years of PC history prove that optimizing compilers can't
: match a good assembler programmer (at least on a CISC platform like the x86).
: The way to get fast executables isn't to buy a better compiler, it's to buy a
: profiler, and rewrite the critical sections in assembler.
True, but this is likely to become more and more difficult as procerssors
get more complicated.
Berend de Boer
>Optimizing? Well, TP does some simpler (obvious) optimizations,
>but in comparison with some other compilers it doesn't fare very well.
DM> IMHO, the last 15 years of PC history prove that optimizing
DM> compilers can't match a good assembler programmer (at least
DM> on a CISC platform like the x86). The way to get fast
DM> executables isn't to buy a better compiler, it's to buy a
DM> profiler, and rewrite the critical sections in assembler.
To add some experience with so-called optimizing compilers: whenever
you experience something strange in your program, just recompile with
all optimizations off... One stumbles to often on errors caused by
optimizing compilers. Note, these are real bugs, confirmed by Microsoft
for example. And in every C compiler they have a few, unknown,
undocumented...
I rather have a compiler I can trust and Borland's Pascal compiler are
very trustworthy, there is only one case I know of in which it fails.
Groetjes,
Berend (-:
fido: 2:281/527.23
email: ber...@beard.nest.nl
SEEN-BY: 1/1 60/0
Allen J. Friedman
[...]
: IMHO, the last 15 years of PC history prove that optimizing compilers can't
: match a good assembler programmer (at least on a CISC platform like the x86).
: The way to get fast executables isn't to buy a better compiler, it's to buy a
: profiler, and rewrite the critical sections in assembler.
: Duncan Murdoch
IMHO, the last 15 years of PC history prove that execution speed of an
applicaton has little to do with success in the market. The real factors
that matter are functionality, ease of use/learning, and getting to market
first.
Speed of development matters. Speed of execution only matters to
programmers.
Allen Friedman
Lou Duchez
ber...@beard.nest.nl (Berend de Boer) wrote:
>
> To add some experience with so-called optimizing compilers: whenever
> you experience something strange in your program, just recompile with
> all optimizations off... One stumbles to often on errors caused by
> optimizing compilers. Note, these are real bugs, confirmed by Microsoft
> for example. And in every C compiler they have a few, unknown,
> undocumented...
Tell me about it! I tell ya, much as I love Borland's Pascal offerings,
I wouldn't use Borland C++ on a dare. I have sections of code that,
when compiled under Power C, work like a charm, but are guaranteed to
hang up every time under BC++. Real complicated stuff too, like if I
turn off the cursor BEFORE calling malloc() ... Not that BC++ optimizes
heavily, but it tries harder than Power C and I suspect an optimization
is biting me on the butt.
> I rather have a compiler I can trust and Borland's Pascal compiler are
> very trustworthy, there is only one case I know of in which it fails.
What? WHAT? Oh great, now I'm going to be all edgy about TP until you
tell us ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A DOS C compiler for only $19.95? Yes, it's Power C, by Mix Software.
Full-featured; comes with an excellent manual. Great for the beginner
and the experienced programmer. (In my experience, much more sensible
than Borland too.) Contact:
Mix Software
1132 Commerce Dr.
Richardson, TX 75081
1-800-333-0330
Duncan Murdoch
>IMHO, the last 15 years of PC history prove that execution speed of an
>applicaton has little to do with success in the market. The real factors
>that matter are functionality, ease of use/learning, and getting to market
>first.
>Speed of development matters. Speed of execution only matters to
>programmers.
I think speed of development is more important than speed of execution, but I
think you're underestimating the importance of speed of execution. I doubt if
there are many commercially successful x86 programs that don't include some
sections written in assembler, and I don't think it's there just because the
programmers like it.
Duncan Murdoch
Malcolm Coulter
>From: sza...@saul4.u.washington.edu (Janos Szamosfalvi)
>Subject: Re: Why Pascal for Delphi?
>Date: 27 Feb 1995 09:30:16 GMT
>Malcolm Coulter (m...@zeus.hsrc.ac.za) wrote:
>: But RISC also - especially for piplined processors (most now). In critical
>: sections the time spent on re-ordering one's statements and branches to suit
>: th optimization algorithm could be better spent writing assembler. You just
>: cannot give the compiler enough information for it to produce complete
>: optimization, but with assembler one can look at the code and see how the CPU
>: will handle it.
>Actually, the kind of optimization needed for deeply pipelined RISC's,
>maybe even with multiple execution units, can be easily done with a
>compiler. Compilers usually fell short with CISC CPU's where they can't
>really use some of the more complicated instructions that can really
>speed up/shorten code.
-----------------------------------------------------
I'm sure that local code optimization is very easy on RISC (in fact the
processors should eventually handle that themselves)- the sort of thing I was
thinking of was more macro structural: writing loops to fit in cache, keeping
used-together data located-together. Registers, like anything used for caching
have a mapping philosophy and assembler level coding can change (or ignore)
this whenever needed. I must admit that I have little knowledge of how the
optimizing compilers are written, I only know how I would design one myself
and how hard it would be to design algorithms that would apply to all types
of code.
Malcolm Coulter
>From: dmur...@mast.queensu.ca (Duncan Murdoch)
>Subject: Re: Why Pascal for Delphi?
>In article <3ijh6o$a...@news.u.washington.edu> sza...@saul3.u.washington.edu
>(Janos Szamosfalvi) writes:
>>Optimizing? Well, TP does some simpler (obvious) optimizations,
>>but in comparison with some other compilers it doesn't fare very well.
>... except in sales. I think BP chooses a good compromise between speed of
>compiling and speed of executable, and I think its market position relative
>to competing compilers proves that.
>IMHO, the last 15 years of PC history prove that optimizing compilers can't
>match a good assembler programmer (at least on a CISC platform like the x86).
>The way to get fast executables isn't to buy a better compiler, it's to buy a
>profiler, and rewrite the critical sections in assembler.
>Duncan Murdoch
--------------------------------------------------------
Spot on!
But RISC also - especially for piplined processors (most now). In critical
sections the time spent on re-ordering one's statements and branches to suit
th optimization algorithm could be better spent writing assembler. You just
cannot give the compiler enough information for it to produce complete
optimization, but with assembler one can look at the code and see how the CPU
will handle it.
Within a functional grouping of statements BP's optimization is almost perfect
but it is limited by being a one-pass compiler and its inability to allow
capitalization on availible processor capabilities. Tracing the code execution
also indicates a tendency to "play it safe" by doing tests that may be
redundant (and how many latent bugs result from mistaken assumptions about
redundancy?).
C programs tend to be much smaller than Pascal - until you add a reasonable
user interface when the difference drops to a few percentage points. C++
programs often appear to be bloated and could be much bigger than the Pascal
equivalents (I don't have data to say for certain). Structural scans of C++
executables show vast amounts of repeated code and even litterals. It would
seem that either it is difficult to set a balance between speed and size
optimization, or that there is a cultural bias to speed-above-all-else, or the
programmers just get so bored by slow compile times that they turn off all
optimization. Also, what BP object code lacks in compactness after the
compiler pass may be more than compensated for by the smart linker.
Malcolm Coulter
Malcolm Coulter
Janos Szamosfalvi
: But RISC also - especially for piplined processors (most now). In critical
: sections the time spent on re-ordering one's statements and branches to suit
: th optimization algorithm could be better spent writing assembler. You just
: cannot give the compiler enough information for it to produce complete
: optimization, but with assembler one can look at the code and see how the CPU
: will handle it.
Actually, the kind of optimization needed for deeply pipelined RISC's,
Devin Cook
Duncan Murdoch <dmur...@mast.queensu.ca> wrote:
>IMHO, the last 15 years of PC history prove that optimizing compilers can't
>match a good assembler programmer (at least on a CISC platform like the x86).
>The way to get fast executables isn't to buy a better compiler, it's to buy a
>profiler, and rewrite the critical sections in assembler.
>
>Duncan Murdoch
Actually, looking at the software that has come out lately, this problem
seems to be solved by most vendors by telling their clients to buy a faster
computer!
--
| They told us of a second coming,
| So we keep looking towards the sky. ----------------
| But its not a Savior that we want, | |
| Just someone else to crucify. -- New Model Army | Devin Cook |
Len Freedman
: Actually, looking at the software that has come out lately, this problem
: seems to be solved by most vendors by telling their clients to buy a faster
: computer!
I first learned programming in connection with a course on digital
electronics, and this was about the time of the 8080, one of the first
8-bit microprocessors, in the mid-70s. The book I had on the 8080 said
that at one time optimization for size and speed had been very important in
programming, but that nowadays, with 8-bit microprocessors now running
at a whole MEGAHERTZ, it was no longer important. 8^)
--
Len Freedman (le...@netcom.com)
Berend de Boer
> I rather have a compiler I can trust and Borland's Pascal compiler are
> very trustworthy, there is only one case I know of in which it fails.
LD> What? WHAT? Oh great, now I'm going to be all edgy about
LD> TP until you tell us ...
I think it is documented in Duncan Murdoch's bug list. It has to dow
with a double type cast from word to byte and vice versa or something
like that. Something like:
longint(ord('a'))
or so. I don't remember it exactly, maybe Duncan does?
Larry Kilgallen, LJK Software
> In article <3iibh1$5...@jac.zko.dec.com>,
> John R. Reagan <rea...@hiyall.enet.dec.com> wrote:
>>
>>In article <3iapd1$j...@nps.navy.mil>, jnho...@nps.navy.mil (John N. Hodges) writes...
>>>But more importantly, Borland in effect -- and I'll get flamed
>>>for this, too -- owns the Pascal language.
>>
>>Here's your flame:
>>
>>Borland DOES NOT OWN the Pascal language. The Pascal Standards Comittee
>>does! If Borland desires to add their own EXTENSIONS to make their product
>>more productive and more usable in certain environment, that is their
>>choice. However, you cannot treat Borland's Pascal product as THE Pascal
>>anymore than I can treate Digital's Pascal as THE Pascal.
>>
>
> For all practical reasons when people say pascal they refer to Borland's
> implementation. This is not true for C++. Microsoft owns Basic for all
> practical reasons.
>
> No one will make a fuss if Borland adds something to Pascal, but a lot of
> people made a lot of noise when OWL1 required the DMT extensions in C++.
>
> When people look at pascal compilers on non-Dos/Windows versions they
> usually look for Borland compatability, the only exception is the
> Macintosh where Think is the "standard".
No, when I look for Pascal on a platform I look for ANSI/ISO compatibility.
I have used a lot of non-standard DEC Pascal features, but I try to restrain
myself for the sake of portability. I know that at any time I can use the
DEC Pascal qualifiers to force compilation of my programs according to
ANSI/ISO standards.
I would expect Pascal compilers for other platforms to have similar abilities
to restrict themselves to ANSI/ISO features. I have not tried Unix systems,
but on Macintosh there is a whole subculture of Pascal which does not even
include all the ANSI/ISO features. They have taken it upon themselves (at
least 3 vendors) to track each others features rather than the standards,
making it very difficult for those who try to port code between platforms.
This is certainly an aspect where C seems to be better than Pascal these
days -- the vendors implement the ANSI/ISO standards. (There is not much
else I have for favorable comments regarding C.)
I have not tried Borland Pascal products, but I gather then have their _own_
dialect peculiar to the Microsoft operating systems and not a proper
superset of ANSI/ISO Pascal. Unless someone came from a background on
Microsoft operating systems, I see no reason they would evaluate Pascal
compilers by comparing them to Borland.
I realize the new (or is it pending?) Object Pascal standard drew from
innovation Borland, Symantec, etc. had done with their own object-oriented
Pascal extensions, but when standards have been achieved vendors should
provide support for compliant programs. This is especially true of
vendors like Borland who choose to focus on a single operating system
family rather than make their unique language variation widely available.
Larry Kilgallen
Duncan Murdoch
> longint(ord('a'))
>or so. I don't remember it exactly, maybe Duncan does?
This is one of the 7.00 bugs that was fixed in 7.01, I think:
37. The expression "Word(hi(wordvar))" doesn't zero-extend the high byte
of wordvar to give a word, it gives the word from memory starting at the
location of the high byte of wordvar, i.e. the high byte plus the low
byte of the next variable. The same sort of thing happens with expressions
like "Longint(ord(charvar))" and "Longint(length(stringvar))".
Duncan Murdoch
Len Freedman
: >
: > When people look at pascal compilers on non-Dos/Windows versions they
: > Macintosh where Think is the "standard".
: No, when I look for Pascal on a platform I look for ANSI/ISO compatibility.
: I have used a lot of non-standard DEC Pascal features, but I try to restrain
: myself for the sake of portability. I know that at any time I can use the
: DEC Pascal qualifiers to force compilation of my programs according to
: ANSI/ISO standards.
: I would expect Pascal compilers for other platforms to have similar abilities
: to restrict themselves to ANSI/ISO features. I have not tried Unix systems,
: but on Macintosh there is a whole subculture of Pascal which does not even
: include all the ANSI/ISO features. They have taken it upon themselves (at
: least 3 vendors) to track each others features rather than the standards,
: making it very difficult for those who try to port code between platforms.
: This is certainly an aspect where C seems to be better than Pascal these
: days -- the vendors implement the ANSI/ISO standards. (There is not much
: else I have for favorable comments regarding C.)
In a way you're right and in a way wrong. If portability is an issue,
then the ANSI standard becomes important. In C it is more of an issue
than in Pascal, mostly because (I think) Pascal is used more in MS DOS
than anywhere else.
Once you give up the issue of portability, the whole balance changes. The
ANSI standards become irrelevant--the committee looks like a room full of
bald men who are not in touch with the real world (sort of like Congress
8^) ). Borland does market research to see what people want and every
version of their Pascal is much better and more useable than the last.
When other companies put out a Pascal compiler (like Microsoft Quick
Pascal) they emulate Borland, making Borland a de facto standard.
I took a class in C, taught by a guy who never worked on an MS DOS machine
in his life. His background was in Unix and VMS, and he did the classroom
demonstrations on a Mac. I used Turbo C, and, though he grudgingly
admitted that it conformed to the standard, he lost no opportunity to bash
it. His biggest complaint was the IDE and the editor which used cursor
moves based on Wordstar, which he thought was inconvenient and stupid. I
cut my teeth on Wordstar, I told him, back in the CP/M days, and when
Turbo Pascal ver. 1 came out, I thought 'Hey! This works just like
Wordstar! Neat!' It's just a matter of what you're used to.
: I realize the new (or is it pending?) Object Pascal standard drew from
: innovation Borland, Symantec, etc. had done with their own object-oriented
: Pascal extensions, but when standards have been achieved vendors should
: provide support for compliant programs. This is especially true of
: vendors like Borland who choose to focus on a single operating system
: family rather than make their unique language variation widely available.
If Borland had waited for a standard, we wouldn't have Pascal with Objects
now, would we? I don't know if there is an ANSI/ISO standard out yet, but
if not, then when it does come out, I bet it will look suspiciously like
Borland. It's not like Microsoft and Symantec have are competing for a
defacto standard in Object Pascal.
--
Len Freedman (le...@netcom.com)
Paul Sleigh
handle exceptions and the heap oriented class system. They can't do that
with C++ cos it's standardised, nor with Basic cos it's too limited in its
basis. Yes, I know Pascal is theoretically standardised, but Borland
Pascal is NOT Pascal - if you think it is you're like a man who beats his
wife but still wants to have sex occasionally (OK, maybe it's not so
serious, but I DO like dramatic similes...). Either acknowledge Pascal as
different from Borland and stop using Borland to justify your claim that
Pascal is useful for real world programming, or pretend Borland Pascal is
Pascal and stop going on about how rude Phillipe was for ignoring the
Standard. Turbo was only called Turbo Pascal cos Pascal _used_to_be_ a
popular language and Borland wanted in on the educational market.
Flame me if you will. You know I'm right!
(Sound of Fruitbat donning asbestos pyjamas...)
- Fruitbat.
Duncan Murdoch
>If Borland had waited for a standard, we wouldn't have Pascal with Objects
>now, would we? I don't know if there is an ANSI/ISO standard out yet, but
>if not, then when it does come out, I bet it will look suspiciously like
>Borland. It's not like Microsoft and Symantec have are competing for a
>defacto standard in Object Pascal.
Unless there have been drastic changes since the Sept 93 draft, the standard
will be very different from BP 7. From what I've seen, Delphi's Object Pascal
moves somewhat closer to it, but Delphi doesn't include multiple inheritance,
implements deferred class definitions differently, uses different rules for
Abstract, has a different root to its class hierarchy, etc.
Duncan Murdoch
Michael Taylor
Only if you'r a Pascal programmer. For a C/C++ programmer Pascal
is much less readable than C or C++. (IMO, of course)
Michael Taylor
Jeff Miller
>do i detect a troll here? (g)
>anyone who considers
>{
>}
>more readable than
>begin
>end
>i wonder about....
Indeed! Why use two keystrokes when eight will do! :-)
Jeff Miller
jxm...@gonix.com
"Performing random acts of
moral ambiguity."
Marc Palmer
>
> mich...@asymetrix.com (Michael Taylor) wrote:
> >
>
> anyone who considers
>
> {
> }
>
> more readable than
>
> begin
> end
>
> i wonder about....
Yeah. I used to program Borland Pascal, but for the last year I've become
pretty fluent in C++ as my development took me that way. I'm now purchasing delphi,
and can't wait to stop having C syntax bugs like using = instead of == (VERY nasty)
and having to specify the type of EVERY function argument INDIVIDUALLY ! To pascal
programmers this seems insane:
'C' code...
void MyFunction( int a, int b, int c, int d, int e, int f, int g);
Pascal code...
MyFunction( a,b,c,d,e,f,g : int); // If memory serves me right!
I kid you not, you have to do that in C!
********************************************************************
* Marc P. E-Mail me for PGP 2.6 key *
* *
* "Most of the ideas I have at the moment have to do with things *
* that are completely impossible, so I am wary about sharing them. *
* They are, however, the only thoughts I have." - Dirk Gently *
********************************************************************
Marc Palmer
>
> mich...@asymetrix.com (Michael Taylor) wrote:
> >
Some other reasons I can think of:
1) C compiles quickly, but to a novice is like giving someone
an axe to cut celotape, they'll almost definitely hurt themselves
or break something!
2) C++ compiles VERY slowly and is complex (but VERY flexible), Some C++
bugs are absolutely bizarre, resulting for repurcussions of overriding
operators etc. Being able to define what + means for a user-defined object
is cool, but things soon get out of hand.
3) BASIC sucks. Yeah, novices can use it, but there is little structure.
4) There aren't really any other languages that could be considered, as they're
all kind of 'fringe'. Besides, Borland already had compilers for C/C++/Pascal,
so why start from skratch.
IMHO VB is screwed unless they make it compile the code instead of pseudo-interpreting
at run time. There is absolutely no way they can make the EXEs as fast as Delphi's
unless they a) compile rather than interpret or b) change the language AND compile.
B) is not an option because it would not be Visual BASIC anymore. MS don't have a pascal
compiler (as far as my memory serves me - at least not one with OOP). They have C/C++ (but
not full ANSI C++) but for reasons a) and B) these should be ruled out.
I found it incredible that MS introduced the VBX technology (when 32-bit Windows was in
the pipeline) and then said 'Sorry - VBXs will not work on 32-bits'. For this very reason
I did not use VBXs in my Borland apps. Now, BRILLIANT Borland have added 32-bit VBX
support to C++ ! I expect this is/will be in Delphi. I must say I laughed heartily when I
saw what a smart move that was by Borland. In short Borland don't leave you out in the
cold, MS.......it's a bit chilly here in Windows development world......
Now, for the next brilliant step, Borland should make a VB->Delphi source converter.
That, along with $50 loyalty switch price, really would be the Visual Basic Killer.
Go for it Borland.
********************************************************************
* Marc P. E-Mail me for PGP 2.6 key *
********************************************************************
Noel Cosgrave
jnho...@nps.navy.mil "John N. Hodges" writes:
> In article 9...@netcom.com, jgar...@netcom.com (Jerry Gardner) writes:
> >I beg to differ. While, technically, nobody really "owns" Pascal, Borland
> >has probably the largest market share of any Pascal compiler vendor. I'm
> >even willing to bet that Borland's market share is one or more orders
> >of magnitude larger than their nearest competition.
> >
>
> I think Borland said that 98% of Pascal compilers are Borland compilers.
>
> And people complain about MS dominating the market! <g>
Have you used MS Pascal? :-)
/\/oel
--
The Green Meddler
do i detect a troll here? (g)
anyone who considers
{
}
more readable than
begin
end
i wonder about....
GM
The Green Meddler
>
> Now, for the next brilliant step, Borland should make a VB->Delphi source converter.
> That, along with $50 loyalty switch price, really would be the Visual Basic Killer.
>
> Go for it Borland.
>
third-party sources.
and believe it or not, microsoft actually tried to compete
with borland in the early "object wars" with TP5.5 came out
with objects. they (MS) lost so badly microsoft pascal
vanished and has not been heard from since.
GM
The Green Meddler
> >anyone who considers
>
> >{
> >}
>
> >more readable than
>
> >begin
> >end
>
> >i wonder about....
>
> Indeed! Why use two keystrokes when eight will do! :-)
>
> Jeff Miller
> jxm...@gonix.com
> "Performing random acts of
> moral ambiguity."
at 2 am in a coffee hangover and understand it....
when ELSE does real programming get done..? (G)
GM
Janos Szamosfalvi
: and believe it or not, microsoft actually tried to compete
: with borland in the early "object wars" with TP5.5 came out
: with objects. they (MS) lost so badly microsoft pascal
: vanished and has not been heard from since.
Actually, that was Quickpascal. MS Pascal was a completely
different product, abandoned a little earlier.
Larry Kilgallen, LJK Software
> In a way you're right and in a way wrong. If portability is an issue,
> then the ANSI standard becomes important. In C it is more of an issue
> than in Pascal, mostly because (I think) Pascal is used more in MS DOS
> than anywhere else.
>
> Once you give up the issue of portability, the whole balance changes. The
Whether or not portability is important is _highly_ application dependent.
My original commercial application required no portability between operating
systems, due to the nature of the product. It was written in Ada.
My latest commercial application requires extreme portability between
operating systems, and there is just no compromising that issue.
> : I realize the new (or is it pending?) Object Pascal standard drew from
> : innovation Borland, Symantec, etc. had done with their own object-oriented
> : Pascal extensions, but when standards have been achieved vendors should
> : provide support for compliant programs. This is especially true of
> : vendors like Borland who choose to focus on a single operating system
> : family rather than make their unique language variation widely available.
>
> If Borland had waited for a standard, we wouldn't have Pascal with Objects
> now, would we? I don't know if there is an ANSI/ISO standard out yet, but
> if not, then when it does come out, I bet it will look suspiciously like
> Borland. It's not like Microsoft and Symantec have are competing for a
> defacto standard in Object Pascal.
As I said, the standard drew from Borland and Symantec, but once the
deal is signed, it is time for vendors to pull in behind it and support
either the Standard ways of doing things or their Proprietary ways of
doing things, at the option of the user. This is especially true of
single-platform vendors like Borland and Symantec, and less important
for vendors like Rational (who seem to have aspirations of selling
their Ada compilers on anything that moves bits).
Larry Kilgallen
The Green Meddler
remember it that late at night.
what's more interesting to me is that initially, bill gates
thought that pascal would be the development language for the
pc, and that's why early windows code was written in pascal.
thus the need for the "pascal" keyword in windows declarations...
GM
Jeroen Pluimers
Sunday February 26 1995 21:43, Wilbert van Leijen wrote:
>> I think there are two main reasons -- first, compiling speed.
>> Delphi is constantly compiling your app in the background to
>> allow for the environment to work.
> It would mean that Delphi could catch syntax errors while I'm editing -
It really does background compiling. However, it does not tell you about any
syntax errors it finds - it is quite intelligent to remember where correct
pieces of code were and continues from there to find out for instance new
methods that can be used as event notifications.
Anders demonstrated this during the Delphi introduction in Amsterdam on
februari 23rd.
So, the backgound compiler does not generate code, only intermediate
information used by the object inspector and code synchronizing system.
Jeroen
The Green Meddler
> >thought that pascal would be the development language for the
> >pc, and that's why early windows code was written in pascal.
> >thus the need for the "pascal" keyword in windows declarations...
>
> for efficiency. Actually, it's hard to say that Windows does *anything*
> for efficiency, but that is another story.
hmmm. i read the pascal reference in a book by Tom Swan on
programming for windows 3.0, and i believe charles petzold
mentioned it too..
GM
David L. Shang
If you ask why not C++, I don't see any significant advantage in using C++ as
far as the language ITSELF is concerned.
If you ask why not SmallTalk or any other dynamic language, I see two
significant advantages over pascal: (1) rapid prototyping, and (2) dynamic
typing; But I also see two disadvantages (sometimes, depending on situiations)
in product finalization: (1) run-time quality, and (2) run-time efficeincy.
For many applications that Delphi is going to handle, the requirement of rapid
prototyping and dynamic typing outweighs bit-byte efficeincy.
For example, if the language does not support dynamic typing, any application
that requires dynamic model designing and building shall not be possible to use
the system that provides this language as an ADL (application development
language) to support the dynamic model development, unless the application
develops its own dynamic language (e.g. script) for its users.
For most GUI applications, we need the following for rapid prototyping:
(1) dynamically add a new method to a existing model
(2) dynamically derive new classes from existing base classes
And afther the protyping is established and tested, we need to "freeze" the
above model to static classes in order to get a run-time efficeincy without the
overhead of the run-time interpreter.
When required, a part of the static classes can also be melt into dynamic
environment for development.
"interpreter + incremental compiler" technique as applied in Eiffel's
environment is a one-step close to the above requirement. Eiffel, like pascal,
does not support dynamic typing. Therefore, it is impossible to given a true
dynamic programming environment: new classes cannot be created at run-time
without recompilation.
Creating new classes at run-time is especially important for client/server
application. Often, when a new client is added with a new type, the server may
be required to generated a new composite type based on the client new type.
For example, let a server provide a QUEUE service. When a client with a new
type T is plugged into the system, the server must be able to create a new type
QUEUE[T] for itself or for the client, and the client should be able to use the
new type QUEUE[T] without being bothered to add a derived static class of QUEUE
(which causes lot of problems for client developers to figure out whether the
queue element type should be covariantly redefined or use invariance with
painful type casting!)
One the goals of Cluster-2, a new obejct-oriented programming language based on
Pascal syntax, is deigned to meet the above requirement.
David Shang
Jeff Miller
>what's more interesting to me is that initially, bill gates
>thought that pascal would be the development language for the
>pc, and that's why early windows code was written in pascal.
>thus the need for the "pascal" keyword in windows declarations...
That's not quite correct. Windows uses the Pascal calling convention
Ron Schwarz
In a previous article, kilg...@tde.com (The Green Meddler) says:
>and believe it or not, microsoft actually tried to compete
>with borland in the early "object wars" with TP5.5 came out
>with objects. they (MS) lost so badly microsoft pascal
>vanished and has not been heard from since.
QuickPascal was developed by a team in France -- it didn't look
bad, and I suspect the developers had high hopes for it. However,
it's purpose in life was not to compete. It existed *solely* as
a gun to the head of Borland.
Borland got the message, and fast. Turbo Basic quickly disppeared,
and the original developer has been struggling with it ever since,
and it is *no* threat to MS any longer. And, the deal being done,
MS holstered *its* weapon (QuickPascal) which has never been seen
since.
--
"...last minute maneuvers in congress can make a mockery of
presidential decrees." ..Dan Rather, CBS Evening News, 3-3-95
Duncan Murdoch
>As I said, the standard drew from Borland and Symantec, but once the
>deal is signed, it is time for vendors to pull in behind it and support
>either the Standard ways of doing things or their Proprietary ways of
>doing things, at the option of the user. This is especially true of
>single-platform vendors like Borland and Symantec...
This assumes that the vendor wants to support the standard. It is sometimes
in a vendor's interest to support standards-making, because that gives
them access to the wider audience of users of other compliant compilers.
However, I think it would not be in Borland's interest to support the
standard. They already have an overwhelming share of the DOS and Windows
markets for a Pascal compiler. By following the standard, they would increase
their potential market only by a small amount. On the other hand, they'd be
giving their own users the option of switching to many other vendors.
As it is, if someone wants to compete with Borland on the DOS or Windows
platforms, they pretty much have to adopt Borland's definition of the language
to do so. Since Borland changes it every two or three years, this isn't easy.
I'm not sure if this is a good or bad thing overall. It's certainly very bad
from the point of view of people like you who need portability. On the other
hand, Borland has been free to create some very useful compilers and
libraries for them; if they had spent the time implementing all the features
of Extended Pascal with the object extensions (which looks to me like a *much*
larger language than Borland's Pascal), they may not have written TurboVision,
Turbo Pascal for Windows, or Delphi, all of which have been useful to a large
number of programmers.
Duncan Murdoch
Duncan Murdoch
>what's more interesting to me is that initially, bill gates
>thought that pascal would be the development language for the
>pc, and that's why early windows code was written in pascal.
>thus the need for the "pascal" keyword in windows declarations...
I've never heard that any of Windows was written in Pascal. The "pascal"
keyword in windows declarations is there because the standard C calling
convention is less efficient (in code size) than the Pascal convention. The C
convention makes variable length parameter lists easier to implement, but most
of the Windows API doesn't need those.
One thing I do remember reading: P.J. Plauger wrote that the 8086 was
designed on the assumption that Pascal would be the main high-level language
for it. The segment registers cause C programmers trouble, but are natural in
Pascal where the code, stack, static data, and heap are clearly separated.
Duncan Murdoch
Janos Szamosfalvi
: from the point of view of people like you who need portability. On the other
: hand, Borland has been free to create some very useful compilers and
: libraries for them; if they had spent the time implementing all the features
: of Extended Pascal with the object extensions (which looks to me like a *much*
: larger language than Borland's Pascal),
Kinda interesting to see that languages with many features (ie: Ada,
Algol, PL/1) weren't very successfull, while languages that started
out small (ie: Pascal, C) fared a lot better.
In this case less is more, IMHO.
Peter Gruhn
And Borland already had a fast compiler for Pascal.
... Boku wa hon desu.
___ Blue Wave/QWK v2.12
Eric W. Mitchell
: Now, for the next brilliant step, Borland should make a VB->Delphi
: source converter. That, along with $50 loyalty switch price, really
: would be the Visual Basic Killer.
There is already such a tool available from a third party. It is advertised
in Software Development (conveniently located within the Delphi review).
I can't recall the name offhand...
Eric
--
=========================================================================
# Eric Mitchell | If HAL ran Usenet: "I'm sorry Dave. #
# Systems Engineer | I'm afraid I can't post that." #
# MacDonald Dettwiler & Assoc. |----------------------------------------#
# Email: e...@mda.ca | Standard disclaimers apply. #
=========================================================================
Jeroen Pluimers
Sunday March 05 1995 16:32, kilg...@tde.com wrote:
kc> what's more interesting to me is that initially, bill gates
kc> thought that pascal would be the development language for the
kc> pc, and that's why early windows code was written in pascal.
Windows code uses the Pascal calling convention becuase of several reasons.
First of all, most of the times it is faster than C calling convention. Second,
the called procedure is responsible for clean up which is generally a much
clearer environment. Third, the Pascal calling is more natural for programming
and debugging purposes as parameters are being pushed the same order as they
are declared.
Jeroen
Lars Fosdal
>Marc Palmer (Ma...@landscap.demon.co.uk) wrote:
>: Now, for the next brilliant step, Borland should make a VB->Delphi
>: source converter. That, along with $50 loyalty switch price, really
>: would be the Visual Basic Killer.
>There is already such a tool available from a third party. It is advertised
>in Software Development (conveniently located within the Delphi review).
>I can't recall the name offhand...
- I'll fill in for you:
Conversion Assistant - Enables developers to migrate MS Visual Basic
applications to Borland's visual high performance application development
environment, Delphi. $79
EarthTrek 7 Mountain Rd., Burlington, MA 01803
Tel: (617) 273-0308
Fax: (617) 270-4437
- Also worth mentioning :
Visual Basic Compatibility Layer - Shareware tool mimics interface and
functionality of standard VB controls so that there is less to learn when
you're migrating to Delphi.
- No source mentioned :-/
JFTR: I have not tried any of them.
Lars F.
--
/ Mr.Lars Fosdal / Falcon AS (a REUTERS company) / Tel.+47 22831310
/ lfo...@falcon.no / Stranden 1, N-0250 OSLO, Norway / Fax.+47 22831290
Bruce S. Tobin
: For many applications that Delphi is going to handle, the requirement of rapid
: prototyping and dynamic typing outweighs bit-byte efficeincy.
: "interpreter + incremental compiler" technique as applied in Eiffel's
: environment is a one-step close to the above requirement. Eiffel, like pascal,
: does not support dynamic typing. Therefore, it is impossible to given a true
: dynamic programming environment: new classes cannot be created at run-time
: without recompilation.
Have you used Delphi? The compiler is unbelievably fast. It feels much
more like an interpreted environment (albeit a very fast one) than a
compiled environment. The recompiles take less time than loading the
code into the interpreter takes in many environments.
Jim Fleming
I would like to point out that all modern OO development environments
should exhibit this same characteristic. If you are not doing single
method recompilation and update, you are not at the leading edge. If
a reasonable size class does not compile and reload in about the time
it takes to redraw a menu, then you are not at the leading edge.
Some might point out that speed is not a characteristic of a language
but rather the development and/or execution environment. I would
suggest that, if the language is designed with some idea of what it
will be used for, as well as some idea of who will be using it, then
development environment speed can be taken into account *before* the
fact and not after the fact. To this extent, speed is an attribute
of the language definition.
The folks at Borland have done a wonderful job with Delphi. Fortunately,
now that processor speed is less of an issue with mini-crays on everyone's
desks, Delphi enters the market with speed and elegance. They clearly
had (or have) people that understand language design and the importance
of making a language usable. It will be via their highly usable system
that they will encourage reuse. Reuse is one of the primary reasons for
anyone spending any time investigating the merits of OO.
If people are not concerned about reuse, and are willing to continue
programming (and reprogramming) the same libraries year after year, then
they should not be that concerned about choosing a language born in the
70's. Those people are destined to relive the 80's in the 90's. Borland
is clearly giving people a chance to prepare for the next century with
Delphi. The only people that will be able to *afford* to be around in
the year 2000 will be those that encourage and practice reuse.
--
Jim Fleming Unir Corporation Unir Technology, Inc.
%Techno Cat I One Naperville Plaza 184 Shuman Blvd. #100
Penn's Landing Naperville, IL 60563 Naperville, IL 60563
East End, Tortola 1-708-505-5801 1-800-222-UNIR(8647)
British Virgin Islands 1-708-305-3277 (FAX) 1-708-305-0600
Allan Lochert
>: Now, for the next brilliant step, Borland should make a VB->Delphi
>: source converter. That, along with $50 loyalty switch price, really
>: would be the Visual Basic Killer.
>There is already such a tool available from a third party. It is advertised
>in Software Development (conveniently located within the Delphi review).
>I can't recall the name offhand...
>Eric
There is a add in Dr. Dobbs april issue from EarthTrek (607 273 0308).
They sell a VB to Delphi conversion tool.
Standard edition:
Converts VB projects to Delphi incl. .frm, .bas and .mak files.
Database edition:
automate database converion from access or odbc to Delphi format (paradox?)
features are supposed to include:
-code translation to pascal
-VBX mapping of common built-in cotrols
-object placement ad sizing
-form conversion
-automatic creation of Delphi proj. files
-Fully or optional parial translation allowin for reusable pascal units.
-completely handles VB control arrays
Also to come is a PowerBuilder to Delphi converter!
prices Stand. Ed. $79, Database Ed. $149, PowerBuilder Ed. $99
--
__
/ 7 / / __ _
/ / / / / 7 / 7
\_/\/\/\/\_/\/ \
Al...@u9.oslohd.no
David Koosis
>Marc Palmer (Ma...@landscap.demon.co.uk) wrote:
>: Now, for the next brilliant step, Borland should make a VB->Delphi
>: source converter.
That product would be Conversion Assistant from:
EarthTrek
7 Mountain Road
Burlington MA 01803
(617) 273-0308
fax: (617) 270-4437
//dk
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ISC Consultants, Inc. 14 East 4 Street Ste 602
New York City 10012-1141
"Technical Consulting & Training Since 1973" 212 477-8800 fax:477-9895
Scott McLoughlin
> If people are not concerned about reuse, and are willing to continue
> programming (and reprogramming) the same libraries year after year, then
> they should not be that concerned about choosing a language born in the
> 70's. Those people are destined to relive the 80's in the 90's. Borland
> is clearly giving people a chance to prepare for the next century with
> Delphi. The only people that will be able to *afford* to be around in
> the year 2000 will be those that encourage and practice reuse.
Howdy,
This is pure crappy hype. Gobs of code written in C and Fortran
have been successfully reused for _DECADES_. OOP has no special
monopoly on software reuse at all.
I often tell clients that if they formerly did not/could not
take advantage of the library building facillities offered by
non OOP languages, then it is rather unlikely that they will
reap whatever reuse bennies OOP has to offer solely by virtual
whoops, virtue, of switching to an OOP language. SOMEONE has
to tell the truth straight to their face. Building reusable
code has MORE to do with technical ability and process maturity
than it has to do with language selection. Hells bells, there
are giant packages of TROFF MACROS that have been reused
profitably by millions.
Whenever I point out these simple facts, my clients almost
universally wizen up and readily agree. It may not make them
happy -- everyone hopes for a silver bullet. But it allows them
to focus on the real problems in their software development
practices. It amazes me that perfectly intelligent people
who have been fighting the good fight to build good software
for years suddenly are drawn in by the hype.
That said, various OOP languages offer different facillities
that can be helpful for writing reusable libraries of code.
The issues and trade offs and flexibility differ from
language to language. C++ is an OOP language the designers
of which have been recently placing more emphasis on other
code reuse mechanisms, namely templates -- once again, to
emphasize that OOP is _NOT_ the last word in code reuse,
library building, or any other aspect of programming for
that matter.
We should all be grown ups by now and impervious to the
hawkers in the marketplace. There is no silver bullet.
=============================================
Scott McLoughlin
Conscious Computing
=============================================
Jeff Miller
>jim.f...@bytes.com (Jim Fleming) writes:
>> If people are not concerned about reuse, and are willing to continue
>> programming (and reprogramming) the same libraries year after year, then
>> they should not be that concerned about choosing a language born in the
>> 70's. Those people are destined to relive the 80's in the 90's. Borland
>> is clearly giving people a chance to prepare for the next century with
>> Delphi. The only people that will be able to *afford* to be around in
>> the year 2000 will be those that encourage and practice reuse.
>Howdy,
>This is pure crappy hype. Gobs of code written in C and Fortran
>have been successfully reused for _DECADES_. OOP has no special
>monopoly on software reuse at all.
Bingo!
This is such a rare sentiment these days, that it is a joy to
actually hear someone state it.
Code re-use is not a technology issue! It in a organizational
issue. Period.
I would dare to speculate that no organization using non-OOP
tools a few years ago was realizing even 10% of the code reuse
that such tools made available. What reason is there to predict
a huge leap in code reuse based on OOP, given the obvious
presence of non-technological limitations to reuse under the
previous paradigm?
Jeff Miller
jxm...@borg.mnet.uswest.com
Jeffrey W. Stulin
jxm...@borg.uswc.uswest.com (Jeff Miller) wrote:
>
> Code re-use is not a technology issue! It in a organizational
> issue. Period.
Wrong. Inheritance in OOP allows code to be reused more easily then a
simple library structure.
Jeffrey W. Stulin
The Green Meddler
i would like to jump in here
(asbestos underwear ON)
i used to be a (yuk) basic programmer (yes, good old turbo basic!)
who went into pascal and C. then c++ came out, and i said huh? then
turbo pascal 5.5 came out, and i began working with it, and..
i had my aha!
when i read someone bash OOP as has been done in the two previous
posts, i simply suspect that these people have not had their aha!
until the metaphor unlocks in your own mind, OOP really is more
of a nuisance than a help. but once you understand where the
process originates and is going, and unfortunately i can't put
that into words right now, the benefits are amazing!
anyone who doubts this, study the source to the VCL. that's OOP
at its finest.
GM
ps sorry, i meant to put this up front. I think saying OOP is about
code reuse is like saying computers are about word processing. it's
true, but far and away not the whole story. OOP is, properyly used,
a whole new *way* to program, both mentally and in the machine. the
code reuse aspects of it are in many ways secondary.
to that degree, the posters are right. a badly designed OOP program
is no more likely to save effort, etc, than a badly written C or
fortran program.
(asbestos underwear OFF)
Kennel
> This is such a rare sentiment these days, that it is a joy to
> actually hear someone state it.
> Code re-use is not a technology issue! It in a organizational
> issue. Period.
> I would dare to speculate that no organization using non-OOP
> tools a few years ago was realizing even 10% of the code reuse
> that such tools made available. What reason is there to predict
> a huge leap in code reuse based on OOP, given the obvious
> presence of non-technological limitations to reuse under the
> previous paradigm?
The technology makes the result more profitable and the cost lower?
Jeff Miller
>Jeff Miller (jxm...@borg.uswc.uswest.com) wrote:
The race car analogy is very apt here. The 'average' street driver
can drive, for example, a Corvette faster than a Formula 1 race car.
Why? Because the F1 is too much to control.
The point is that having a faster car, or theoretically superior
reuse technology, will not improve the result unless is represents
an improvement on the fundamental limiting factor. My experience in
large, corporate development environments has convinced me that
the obstacles to reuse are *not* technology based.
Don't think this means that I am not a user/advocate of OOP. I am.
But I don't think it is reasonable to expect a meaningful increase
in reuse, based solely on OOP, if no reuse existed before.
Jeff Miller
jxm...@borg.mnet.uswest.com
Sundial Services
>The point is that having a faster car, or theoretically superior
>reuse technology, will not improve the result unless is represents
>an improvement on the fundamental limiting factor. My experience in
>large, corporate development environments has convinced me that
>the obstacles to reuse are *not* technology based.
An excellent point. In the business world, two very significant non-tech
obstacles to re-use are:
(1) Re-using the component of one application in a second application, in the
literal sense (rather than cut-and-paste), introduces a fairly significant
dependency between the old and the new application. However, both apps will
grow from this point, possibly in separate and incompatible directions.
(2) If there is a serious attempt to build a shared collection of objects
and/or base-code, then changes to the base-code or objects can have
unforseeable ripple-effects throughout the applications which use them. In
the real world, many different and loosely-connected teams can work on the
various apps, and not be aware of the incompatible change until their appli-
cations suddenly start crashing. Deriving classes is one thing. Changing a
base-class after classes have been derived from it and are in production is
quite another!
The limiting issues I've seen are: unwanted interdependencies, unforseeable
interactions, and the general, pervasive concern of *risk.*
/mr/
Jeff Miller
>j...@seeker.tiac.net (Jeffrey W. Stulin) wrote:
>>
>> jxm...@borg.uswc.uswest.com (Jeff Miller) wrote:
>>
>> > Code re-use is not a technology issue! It in a organizational
>> > issue. Period.
>>
>> Wrong. Inheritance in OOP allows code to be reused more easily then a
>> simple library structure.
>i used to be a (yuk) basic programmer (yes, good old turbo basic!)
>who went into pascal and C. then c++ came out, and i said huh? then
>turbo pascal 5.5 came out, and i began working with it, and..
>i had my aha!
>when i read someone bash OOP...
I am not 'bashing' OOP. Quite the contrary.
OOP has clear benefits. That's why I use it.
But my point is still valid.
In a large organization, code reuse is not limited by technology.
If it were, then even non-OOP tools would exist in an environment
of vast reuse. Standard, ANSI C presents enormous opportunities for
reuse, but very little occurs in most corporations.
Why?
Well, to answer that question would take hundreds of pages of
analysis of organizational dynamics and structure. But the point is
the answer to 'Why is there very little code reuse in today's typical
corporate development environment?' has almost nothing to do with
the nature of the technology being used, and everything to do with
the nature of large organizations of people.
In less theoretical terms, where is the reuse today in those organizations
that have adopted OOP? There are a handful of examples where corporations
have made a focused effort to promote, encourage and reward reuse as
a component of their shift to OOP. They have, for the most part, had
good results.
But there are still way too many companies for whom the shift to OOP
means sending 25% of their COBOL programmers to two weeks of C++ class,
then sitting back and waiting for the huge savings to materialize.
Furthermore, those companies who 'correctly' adopted C++ (meaning, they
made the correct structural changes at the same time as the paradigm
shift) would have gotten the majority of the benefit they currently
attribute to OOP had they made the structural changes alone.
OOP can, and in some cases does, deliver tremendous results. But in a
lot of ways, OOP represents computer science's answer to an MBA's
problem.
Jeff Miller
jxm...@borg.mnet.uswest.com
Scott McLoughlin
> Don't think this means that I am not a user/advocate of OOP. I am.
> But I don't think it is reasonable to expect a meaningful increase
> in reuse, based solely on OOP, if no reuse existed before.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Howdy,
Exactly. This is the point that clients will understand
if you patiently point it out to them.
Nat Pryce
In my experience, inheritance most definately does *not*
immediately (automagically) bring about reusable code. Code must be
designed to be reusable whether it uses inheritance or not. In fact
I have found that compositional approaches to reuse are just as
likely to succeed as inheritance based approaches, are easier to
understand and document, and can be realised with any form of
language technology.
Inheritance seems to make it easier for a single person or team to
reuse code *within* the software component they are building but
does not bring significant benefits to those *using* the component.
Encapsulation and good design help in that respect, and can be
realised in any language.
Cheers,
Nat.
Larry Morgenweck
>But there are still way too many companies for whom the shift to OOP
>means sending 25% of their COBOL programmers to two weeks of C++ class,
>then sitting back and waiting for the huge savings to materialize.
soon IBM will or have OOCOBOL or at least Rapid developemet tools
Larry
Mark Collins
From: jxm...@borg.uswc.uswest.com (Jeff Miller)
Newsgroups: comp.object,comp.lang.pascal
Date: 14 Mar 1995 09:04:08 -0600
Organization: U S WEST Communications
m...@jt3ws1.seas.ucla.edu (Kennel) writes:
>Jeff Miller (jxm...@borg.uswc.uswest.com) wrote:
>> This is such a rare sentiment these days, that it is a joy to
>> actually hear someone state it.
>> Code re-use is not a technology issue! It in a organizational
>> issue. Period.
[stuff deleted]
> The point is that having a faster car, or theoretically superior
> reuse technology, will not improve the result unless is represents
> an improvement on the fundamental limiting factor. My experience in
> large, corporate development environments has convinced me that
> the obstacles to reuse are *not* technology based.
I agree and disagree. In agreement, I think the organization sets the goals
and can choose to reward or ignore the effort it takes to achieve significant
reuse. This is not a technology issue. See the thread on 'Measuring reuse'
for this topic. I think it's a very important and overlooked aspect.
> Don't think this means that I am not a user/advocate of OOP. I am.
> But I don't think it is reasonable to expect a meaningful increase
> in reuse, based solely on OOP, if no reuse existed before.
On the other hand (it's about as hard to find a one-handed software engineer as
to find a one-handed economist), there is a social impact of introducing the
technology. There is a (sometimes brief) period of time when OOP is being brought
in that people look beyond 'the way we've always done it' and look for better
techniques. The fact that these people have been sold on reuse as one of the
prime goals of OO may actually make them believe it is now possible to do what
they have never done before. This is not a technology issue, but it is a potential
impact of introducing OOP. From this standpoint it is somewhat reasonable to
expect a meaningful increase in reuse. If you want to have any meaningful
probability of this happening, change your metrics (or create some metrics or
other form of incentive) to encourage the change.
I do think that the ability to reuse at a higher level (classes and hierarchies
instead of procedures) is beneficial, but you're right: this is mostly an
organizational issue.
> Jeff Miller
> jxm...@borg.mnet.uswest.com
Mark Collins. If you quote me on any of this, I'll deny everything.
ma...@alpha.bld.bdm.com
Michael Wright
>Code re-use is not a technology issue! It in a organizational
>issue. Period.
>I would dare to speculate that no organization using non-OOP
>tools a few years ago was realizing even 10% of the code reuse
>that such tools made available. What reason is there to predict
>a huge leap in code reuse based on OOP, given the obvious
>presence of non-technological limitations to reuse under the
>previous paradigm?
> Jeff Miller
> jxm...@borg.mnet.uswest.com
> "Performing random acts of
> moral ambiguity."
"Build it and they will come", before OPP there was no need or desire..........
With OPP there is bound to be resistance to change..........
John Buehler
>In a large organization, code reuse is not limited by technology.
>If it were, then even non-OOP tools would exist in an environment
>of vast reuse. Standard, ANSI C presents enormous opportunities for
>reuse, but very little occurs in most corporations.
This is a point which should be advertised as a Surgeon General's
Warning to the reuse claim of the OO universe. Straightforward
layering of software using good old 3GLs could give the industry a
huge amount of reuse of software. It *does* happen to a certain
extent - as evidence, windowing systems, network software, operating
systems, etc. Pick a pile of software that you call into and you've
got reuse. Some might call it pure and simple 'use', but if two
people are using it, it's been reused. OO simply gives us a different
way to reuse code.
The layering approach isn't as neato-whizbang as inheritance,
polymorphism and what-not, but it gets the job done. Actually, I'm of
the opinion that a talented software engineer can do a heck of a lot
more with a 3GL than with an OO language (I can follow OO where it
suits me and violate it as much as I want when I want).
JB
--
John Buehler
Template Software
13100 Worldgate Drive, Suite 340
Herndon, VA 22070-4382
email: bue...@template.com voice: 703-318-1000 fax:703-318-7378
"Inertia is nature's default"
Scott McLoughlin
> The layering approach isn't as neato-whizbang as inheritance,
> polymorphism and what-not, but it gets the job done. Actually, I'm of
> the opinion that a talented software engineer can do a heck of a lot
> more with a 3GL than with an OO language (I can follow OO where it
> suits me and violate it as much as I want when I want).
Howdy,
Has anyone done a study of reuse comparing OO languages. I don't
want to weight in on 3GL vs. OOPL or OOPL-X vs. OOPL-Y, but Lisp's CLOS
looks like it would be a big reuse contest winner. Multi-arg dispatch,
first class functions and function constructors (e.g., LAMBDA) from
the base language, EQL specializers (specializers on values, not just
types of values), etc. look to me like a powerful reuse toolkit.
Anyway, correct factoring (to use a Forth'ish term) has
always been hard. I think it's naive to expect teams of Aristotles
to magically appear in development teams (although it does happen
from time to time) to make the correct type hierarchies. This _is_
the analysis/design approach being promoted by many writers and
tool vendors.
Have any studies been done comparing the success/failure
(with regard to reuse) of implementation technology motivated
designs vs. problem modeling motivated designs (sorry if this is a
fuzzy distinction). I would think the success factor would be
greater for the former, as a great deal of classification and
analysis has already been done for various data structures and
algorithms.
I'd love to read something really _good_ on the topic.
Even "real life" reports are hard to judge. It's near impossible
to separate out "working hard" factors from "working smart"
factors. In my experience, I see alot of the former but with
the latter being reported to management.
Jeff Miller
>>I would dare to speculate that no organization using non-OOP
>>tools a few years ago was realizing even 10% of the code reuse
>>that such tools made available. What reason is there to predict
>>a huge leap in code reuse based on OOP, given the obvious
>>presence of non-technological limitations to reuse under the
>>previous paradigm?
>"Build it and they will come", before OPP there was no need or desire..........
>With OPP there is bound to be resistance to change..........
Replace "OOP" with "object code libraries" in the above sentence and
you will see my point.
Jeff Miller
jxm...@borg.mnet.uswest.com
Dan Luther
cyc...@primenet.com (Michael Wright) wrote:
>
>>Code re-use is not a technology issue! It in a organizational
>>issue. Period.
>
>>I would dare to speculate that no organization using non-OOP
>>tools a few years ago was realizing even 10% of the code reuse
>>that such tools made available. What reason is there to predict
>>a huge leap in code reuse based on OOP, given the obvious
>>presence of non-technological limitations to reuse under the
>>previous paradigm?
I take it you've never heard of Ada? 1983, very rudimentary OO concepts
(operator overloading etc.) but heavy on code reuse.
But here's a thought for you: Can you produce a program that makes any uses of
OOP and is smaller and faster than a procedural counterpart?
(o) (o) Dan Luther Black Gold BBS
--oOO--(_)--OOo--------------------------------------------------------
INTERNET: dan.l...@bgbbs.com Oklahoma's Biggest and Best!
FIDO: 1:170/309 (918) 272-7779
It's sad to live in a society where an entire
family can be torn apart by something as simple
as a pack of wild dogs...
Robb Nebbe
|> Any response to my point that includes reference to a particular language
|> and/or that language's features by definition misses the mark. My point
|> is that reuse is not technology driven. It is driven by the organization,
|> by the management structure.
I missunderstood your earlier post (but did avoid responding and sticking
my foot in my mouth :-) but now I agree with you. Reuse isn't something
that just happens, you have to make it happen. Languages can help a lot
but they are usually not what is holding people back.
Robb Nebbe
Jeff Miller
>>>Code re-use is not a technology issue! It in a organizational
>>>issue. Period.
>>
>>>I would dare to speculate that no organization using non-OOP
>>>tools a few years ago was realizing even 10% of the code reuse
>>>that such tools made available. What reason is there to predict
>>>a huge leap in code reuse based on OOP, given the obvious
>>>presence of non-technological limitations to reuse under the
>>>previous paradigm?
>I take it you've never heard of Ada? 1983, very rudimentary OO concepts
>(operator overloading etc.) but heavy on code reuse.
I am starting to feel like I am beating a dead horse here, but I suppose
that is what USENET is for!
Any response to my point that includes reference to a particular language
and/or that language's features by definition misses the mark. My point
is that reuse is not technology driven. It is driven by the organization,
by the management structure.
I am not talking about theoretical, academic reuse capability. All the OOP
stuff (overloading, inheritance, etc) is wonderful, and I use it constantly.
I *am* talking about real-world, corporate america reuse. In this environment,
reuse is not limited by technology (ie, the lack of OOP). Instead, reuse
is (IMHO) limited by:
- The fact that management has not implemented a system that
rewards individual projects for developing reusable classes
or libraries which can be submitted to a centralized class/
library repository.
- The fact that no mechanism exists to communicate what classes/
libraries are available for reuse.
- The fact that management has not invested in a 'class/library
building' team that could scour the corporation, looking for
opportunities for reuse and building appropriate classes/libraries.
- The fact that the average application programmer is incapable
or unwilling to invest the incremental effort required to make
his/her classes/libraries applicable beyond the immediate project.
- etc, etc, etc.
And yes, I have indeed heard of Ada.
>But here's a thought for you: Can you produce a program that makes any uses of
>OOP and is smaller and faster than a procedural counterpart?
I don't know, actually, but I disagree with the premise. In my environment,
smaller and faster are quite secondary to 'on-time', 'functionally
correct', 'maintainable by whatever associate degree recent graduate
happens to get stuck with the job in five years', and 'flexible enough to
accommodate whatever the users decide they need' . So long as size and speed
are within reasonable bounds, incremental improvement in those areas is not
relevent. Of course, YMMV, and there are obviously environments where
size/speed are critical.
Jeff Miller
jxm...@borg.mnet.uswest.com
Chad Z. Hower
__>|> Any response to my point that includes reference to a particular
__>|> and/or that language's features by definition misses the mark. My point
__>|> is that reuse is not technology driven. It is driven by the
__>|> by the management structure.
__>
__>I missunderstood your earlier post (but did avoid responding and sticking
__>my foot in my mouth :-) but now I agree with you. Reuse isn't something
__>that just happens, you have to make it happen. Languages can help a lot
__>but they are usually not what is holding people back.
One of the BIGGEST obstacles in resuse, is distribution of source
code. The VBX idea has done VERY well, and I expect precompiled
objects in Delphi to do the same.
___
* UniQWK #50 * PA will be beautiful, if they ever finish it!
== IntJet: QWK, UK, USA, Windows, GUI, OLR, Color, CU 267
'[1;35;40m-=> Delphi Internet Jet SST v3.003B (Beta) - (C) PBE
Duncan Murdoch
> One of the BIGGEST obstacles in resuse, is distribution of source
>code. The VBX idea has done VERY well, and I expect precompiled
>objects in Delphi to do the same.
I would *strongly* recommend that you not touch a precompiled Delphi object
with a ten foot pole. The object code format that Borland uses for Pascal
(.TPU in the old days, now .DCU) is *not* portable between versions. If you
get a precompiled unit now and upgrade Delphi to version 1.1 sometime later,
there's a very good chance that you'll also need to get a new copy of the
unit. If your supplier has gone out of business or has lost interest in it,
you're SOL.
This is an ancient complaint about the .TPU format that goes back to the
release of TP5 six or seven years ago. The reasons for it have been endlessly
rehashed; in summary they are:
- The .TPU format doesn't contain symbolic links to other units, it contains
hard links to particular offsets in the interface part of other .TPU files.
If those other units change their interface, the .TPU is made obsolete and
needs to be recompiled.
- Any reasonable update beyond a minor bug fix release is likely to change
the interface of some commonly used units like SYSTEM. This makes everything
obsolete.
- Borland chose to do things this way because it leads to drastic speedups in
linking. Essentially all the work involved in linking a unit to the units it
uses gets done during compile time, and doesn't need to be repeated again when
the program is linked.
Sorry to everyone who has heard all this before and to everyone in comp.object
who doesn't really care about it, but I think it's important to discourage
precompiled Delphi components right from the start.
Duncan Murdoch
Chad Z. Hower
__>> One of the BIGGEST obstacles in resuse, is distribution of source
__>>code. The VBX idea has done VERY well, and I expect precompiled
__>>objects in Delphi to do the same.
__>
__>I would *strongly* recommend that you not touch a precompiled Delphi object
__>with a ten foot pole. The object code format that Borland uses for Pascal
__>(.TPU in the old days, now .DCU) is *not* portable between versions. If
__>get a precompiled unit now and upgrade Delphi to version 1.1 sometime
__>there's a very good chance that you'll also need to get a new copy of the
__>unit. If your supplier has gone out of business or has lost interest in
EGAD! Are you sure Borland did not fix this MAJOR oversight in
Delphi? If not, I would hope there is some way to address this. I
would hope that if it has not already been addressed, future versions
of Delphi would be backward compatible.
After all, VBX's address this.
Worst case (Not a pleasant thought though) is to write a wrapper
in the version that used it, to be included as a DLL or something into
the newer compiler.
__>- The .TPU format doesn't contain symbolic links to other units, it
__>hard links to particular offsets in the interface part of other .TPU files.
Could the DPU be different?
__>Sorry to everyone who has heard all this before and to everyone in
__>who doesn't really care about it, but I think it's important to discourage
__>precompiled Delphi components right from the start.
If nothing has changed, than I certainly agree.
How will 3rd party vendors sell objects? This could SERIOUSLY hurt Delphi.
If speed is the issue, why could they not hadd an option for each
object? Vendors could use the alternative one.
___
* UniQWK #50 * Pennsylvania: Constructionwealth of Pennsylvania
Duncan Murdoch
writes:
>Dmur...@mast.queensu.ca,
>__>I would *strongly* recommend that you not touch a precompiled Delphi object
>__>with a ten foot pole. The object code format that Borland uses for Pascal
>__>(.TPU in the old days, now .DCU) is *not* portable between versions. If
>__>get a precompiled unit now and upgrade Delphi to version 1.1 sometime
>__>there's a very good chance that you'll also need to get a new copy of the
>__>unit. If your supplier has gone out of business or has lost interest in
> EGAD! Are you sure Borland did not fix this MAJOR oversight in
>Delphi? If not, I would hope there is some way to address this. I
>would hope that if it has not already been addressed, future versions
>of Delphi would be backward compatible.
I don't know for sure, but superficially the compiled units look like the
older ones. By the way, this isn't an oversight: it's a conscious design
decision.
> After all, VBX's address this.
> Worst case (Not a pleasant thought though) is to write a wrapper
>in the version that used it, to be included as a DLL or something into
>the newer compiler.
VBXs are DLLs. You could use the same approach with Delphi too.
> How will 3rd party vendors sell objects? This could SERIOUSLY hurt Delphi.
Presumably some will sell them as .DLLs. Others will take the approach of
most vendors for Turbo Pascal: they'll sell you the source code.
> If speed is the issue, why could they not hadd an option for each
>object? Vendors could use the alternative one.
People have asked for .OBJ files from Turbo Pascal for a number of years. I
guess Borland has never seen it as a high enough priority. In any case, they
would need to make some other changes to the compiler/linker: .OBJ files are
definitely second-class in TP/BP/Delphi. For example, you can't make calls to
any functions in the System unit from one. (The system unit calls are all
compiled by means of special hooks to the compiler. There's no way for the
.OBJ file to see the hooks, or the support routines used to implement them.)
Duncan Murdoch
Rune Moberg
CZ_H...@Delphi.com (Chad Z. Hower) wrote:
> __>I would *strongly* recommend that you not touch a precompiled Delphi object
> __>with a ten foot pole. The object code format that Borland uses for Pascal
> __>(.TPU in the old days, now .DCU) is *not* portable between versions. If
> __>get a precompiled unit now and upgrade Delphi to version 1.1 sometime
> __>there's a very good chance that you'll also need to get a new copy of the
> __>unit. If your supplier has gone out of business or has lost interest in
>
> EGAD! Are you sure Borland did not fix this MAJOR oversight in
> Delphi? If not, I would hope there is some way to address this. I
> would hope that if it has not already been addressed, future versions
> of Delphi would be backward compatible.
>
> After all, VBX's address this.
No, it doesn't!
When you're investing in third-party VBX's, your app will look silly when
you find lots of bugs in the VBX and the supplier is no longer supporting
the product... I.e. you face the same problem as with unsupported DCU's.
Both VBX's and (most likely) DCU's will have to be updated when we'll
start using 32bit apps. Atleast the DCU's will at most only require a
recompile, while the VBX's face a complete rewrite into 32bit OCX's.
=\
*=- R.Moberg, author of CD-Player Pro! ftp.cica.indiana.edu:
=/ /win3/sounds/cdppro45.zip
Paul Johnson
> sm...@sytex.com (Scott McLoughlin) writes:
> >This is pure crappy hype. Gobs of code written in C and Fortran
> >have been successfully reused for _DECADES_. OOP has no special
> >monopoly on software reuse at all.
> This is such a rare sentiment these days, that it is a joy to
> actually hear someone state it.
> Code re-use is not a technology issue! It in a organizational
> issue. Period.
Half right. Code reuse is possible in a procedural language, and it
is also an organisational issue. However OO languages create many
more opportunities for code reuse.
Procedural languages only allow what I call "top-down" reuse. You can
write and reuse a library by calling down into it and getting it to do
its thing.
With an OO language, I can take some existing client code which
performs some action on a class "FOO", and create a new class "BAR"
with the same interface. The existing code will then perform this
action on objects of type "BAR" as well as on "FOO" without
modification. Thus I have reused the client software from below.
This is "bottom-up" reuse.
The only way to do bottom-up reuse in a procedural language is to
re-invent inheritance using function pointers. See the X Intrinsics
library for a good example of this.
Paul.
--
Paul Johnson | GEC-Marconi Ltd is not responsible for my opinions. |
+44 245 473331 ext 3245 +-----------+-----------------------------------------+
Work: <p...@gec-mrc.co.uk> | You are lost in a twisty maze of little
Home: <Pa...@treetop.demon.co.uk> | standards, all different.
Len Freedman
: I would *strongly* recommend that you not touch a precompiled Delphi object
: with a ten foot pole. The object code format that Borland uses for Pascal
: (.TPU in the old days, now .DCU) is *not* portable between versions. If you
: get a precompiled unit now and upgrade Delphi to version 1.1 sometime later,
: there's a very good chance that you'll also need to get a new copy of the
: unit. If your supplier has gone out of business or has lost interest in it,
: you're SOL.
This is true, but in practice I've found that the advantages of quicker
compile/linking time far outweigh the disadvantages. I've been using
canned routines in DOS TP for years, and a few of the packages I bought
for ver 4 or 5 I am still using with ver 7. In almost every case the
source code is provided with the package, so when a new version of TP/BP
comes out you just recompile everything.
The only exception that I've used was Topaz from Software Sciences, a
network-aware relational database package. They wanted an extra $100 for
the source code, and I took a gamble and didn't get it. When TP7 came out,
they released a $30 upgrade which _included_ the source code!
--
Len Freedman (le...@netcom.com)