Al Boldi ha scritto:
Giuliano Colla wrote:
I've been earning my bread and butter developing computer applications
for 40 years now (my God, how old I've become! :-) )
Wow, that's impressive.
Maybe you could share some of your experience regarding these question:
What languages did you use?
Compiled languages:
1) Assembler from HP minicomputers to IBM mainframes (including an
incredible Siemens computer, which at start-up was typing an obscure
message in german: if you just typed return, it would take the default
action, i.e. assume a new installation and reformat its hard disks! :-)
) , and then micros for all the Intel Family, from 4004 (it was a
nightmare, three instructions to read a memory location but with good
macros you could get away) to nowadays Pentium
2) Fortran (different flavors in time)
3) Algol 60
4) Intel's PLM's: PLM48 PLM51 PLM80 PLM86 PLM386
5) C
6) C++
7) Delphi Pascal
8) Free Pascal
Interpreted Languages:
9) Basic
10) Visual Basic
11) Python
12) Tcl/Tk
Possibly I've left out some, but that's more or less the picture.
Which one is the best?
Among non OOPL PLM was certainly the best, both in terms of code
efficiency and in clean syntax, with the best way I've ever met to deal
cleanly with typed pointers (nothing to do with the C mess). It made
almost possible to make it become an OOPL, with a minimal extra work.
Among OOPL doubtlessly Pascal.
However it's a matter of goal. You always end up with native computer
instructions: the best language is the one which gives you the best
compromise in terms of development costs, maintenance costs, and
performance. If the language is good, but the compiler fails to provide
efficient code, then it's not the right choice. That's why IBM's PL1 was
a failure.
How does OOP affect development (pros/cons)?
Well designed objects provide the two features of reusability and hidden
implementation, which strongly reduces development/debug time.
But you must be careful. The clean syntax of Pascal, the clean
separation between Interface and implementation encourages to provide
good objects. Can't say the same for C++. Bad C habit of making public
whatever isn't declared static, or to let through implicit declarations
can lead to strange bugs very hard to detect.
The con's are that it may encourage lazyness. You may end up using an
object because it's ready made, taking advantage of a minimal part of
its features, and making your code bigger and slower, and maybe harder
to debug, when a small subroutine could have served the same purpose.
Is there a better dev-approach than OOP?
There's never a "best for all" approach. If I need to test a formula,
Basic is still the best language. If I need a device driver, I may find
out that I get the required efficiency only by assembler. Each problem
requires the appropriate tools. Tombstones are made of stone. It's a
stone-age technology, but it's the most appropriate to cover a grave.
What has OOP missing?
Well, standard C++ misses the property assignement, unless you go
through the chore of overloading the '=' operator. For the rest I'm
quite happy with it.
When is it wrong to use OOP?
Whenever it's not appropriate.
How can OOP be misused?
Using it when not appropriate.
Thanks for shedding some light!
Go and be content, my young friend. Study, when you've learned start
coding, and don't sin any more. (I can detect sarcasm at least since as
long as I have been programming, but your questions deserved a reply
nonetheless).
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
