#ObjectOriented
11 messages in this thread
To programm in the OO way is much more than just using hidden procedures. That
was one time called modularization. Any Amiga programmer use it in a way like
he uses the Libraries of the ROM Kernel. But the OO way is to use the same exec
list every time and add to it some own vars and structs and even methods. Thats
in its own way some way of simplines like no other system can give you, just
the amiga (and next of course).
My programms got real faster, to run and to design and to create and to
program, and they got not so huge like before and they stop becoming buggier
allready during the desing.
So all your arguments doesn't seem to fit with my experience. Think it over and
try it for yourself!
Matthias Nagy
Haha!
You are talking about the Amiga and you got me! The trouble is that, with the
Amiga and only with the Amiga my experience is the same!
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
>You are talking about the Amiga and you got me! The trouble is that, with the
>Amiga and only with the Amiga my experience is the same!
That on the Amiga, only, OO is better????????
>>That on the Amiga, only, OO is better????????<<
No, of course not. What I meant is that the Amiga OS is so well written that
you don't need an OO language to program efficiently.
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
>What I meant is that the Amiga OS is so well written that
>you don't need an OO language to program efficiently.
IMO, that simply does not follow.
They are disjoint issues, how could they not be?
>>They are disjoint issues, how could they not be?<<
Are they?
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
At this point I'd like to jump in and mention (as if you didn't know) that the
reason the Amiga's exec is so good is _because_ it is programmed in an
Object-Oriented style, although not in an object-oriented language….
However, it could be replicated fairly quicly in -say – C++ without too much
loss of performance, in fact, I think such a library alsready exists
somewhere…
To my mind what's important is the OOP style, NOT the language, and that is
something which has to be learnt.
OOP languages simply try to make it more natural.
IMHO, advising against OOP because it isn't efficient, miises the point:
Firstly, it is efficient, and the Amiga exec proves it. As does Wirth's new
Oberon (FN?) framework environment. Both provide services that normally seem
to require ten times the memory, in a fast and elegant way. OOP does have a
sizeable overhead for small programs, however its great advantage is to enable
sensible and easy management of large to huge projects, by imitating a
"real-life" architecture. Critical code can still be written in assembler
without making the program one jot less object oriented.
I have programmed in OOP for about two years now, and the thought of managing
any project in any other way now gives me the creeps.. If assembler were the
solution there would be scores of fast lean Operating systems out there for us
to choose from instead of the behemoths we see. However, you may have noticed
that all talk of future OSs is OOP. So the Amiga will be a historic first, I
think!
Secondly, it is poor coding that is the cause of inefficiency, and also,
possibly, the use of an OOP language in a non-OOP way… a common problem!
Cheers
Alex
I agree with nearly everything you state. HOWEVER: it remains un undisputable
truth that, at least in principle (and as far as I am concerned, in reality),
assembler will produce the most efficient programs of them all. If I were to
translate a text from english to flemish, I wouldn't think of translating it
into russian and then into flemish. Same thing goes for programming.
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
Bart,
>If I were to translate a text from english to flemish, I wouldn't think of
translating it into russian and then into flemish. Same thing goes for
programming.<<
But, consider: a Russian likes to write or speak to english, scandinavian,
french, german, of course flemish, and lots of other languages people. Which
language will he use ??? Possibly the one which will _all_ understand ??
Why do we use english in this fora 😕 Btw, imnsho, using russian or chinese
may be more advantagous in other – e.g. eastern europe or asian – networks.
>>Same thing goes for programming.<< same thing…:-)
>>I took over the responsibility for the department I am working for<<
Congratulations 😀
Dieter Goettmann jetting on AP1.80 \/ 11 /\
from Karlsruhe, Germany /\ || on /==\MIGA
>>assembler will produce the most efficient programs of them all.
Absolutely correct. I have been using assembler for years, in fact most of my
Amiga programs are in it. But the problem is that the larger projects get, the
more impossible it is to manage them. I can't even figure what the hell is
going on in AddPower anymore, and I am writing parts of it over again in C.
Managing several programs of even moderate size just gets to be impossible, and
then you come up against the comparisons.
AddPower written in assembly is about 18K in size. Wow, pretty small for all
it does. The same thing (with a much improved interface, and a few more
features) is about 100K in C. So I solved the problem by making the
preferences editors separate programs, so the master patch program that's
always in memory is only 20K again. The whole thing may be a lot bigger… but
the "efficiency" advantage of the assembly version is meaningless. The
preferences programs spend all their processing time WAITING for YOU to click
checkboxes. There is NO efficiency advantage to the (slightly) faster assembly
versions… because they are not CPU intensive, nor are most multitasking
programs that wait for input. And how relevant is 20K compared to 100K when
you have a hard drive 2000 times that size anyway?
Assembler code produces the most efficient programs. It is NOT the most
efficient programming language… the language that allows you to create the
most powerful software in the least time with the least bugs and the easiest to
go back and change later is the most efficient… and that is an OOP
programming language.
This little piece of advice comes from one of the few (1 percent?) of Amiga
programmers that actually writes software in assembly language, and I'd switch
over to C++ completely if I had a reasonably decent compiler. SAS/C++ is
slower than snot form a bad cold.
Ian,
>> AddPower written in assembly is about 18K in size. Wow, pretty small
>> for all it does. The same thing (with a much improved interface, and
>> a few more features) is about 100K in C
well, I solved this kinda problems by
(1) not linking with c.o, but wrote my own startup code (derived from
the C= provided startup.asm routines),
(2) not using any C math, but linking with my own (assembly) routines,
(3) not linking with sc.lib or whatsoever (using amiga.lib only),
(4) using Printf() instead of printf() and the like,
(5) not using any global variables (only constants),
(6) … (more the like)
I write modules that need a lot of local variables in C (because of the benefit
of automatic variable adressing), and write those that are critical for speed
in ASM (using the link/unlk scheme for local variables).
For the need of global variables (that have to be accessible by all the
modules), I define a global data structure, and allocate memory space for it in
the startup code. This also makes the code reentrant and pure.
The pointer to this global data structure, is kept in the Task.tc_UserData
field, and can be easily found by FindTask(NULL)->tc_UserData.
So, in my projects, I combine the benefits of both C and ASM.
>> >>assembler will produce the most efficient programs of them all.
>>
>> Absolutely correct.
Well, some of my routines that I ported from ASM to C, compiled into more
effictive code. When I looked at it later with a disassembler, I sometimes
found some tricky optimations as well as stack and register usage I didn't even
think of when I developed it using ASM.
– wkc – … via AP from Hamburg, Germany