#Oberon-2
44 messages in this thread
I'm using the A+L Ag AmigaOberon Compiler from Friedtjof Siebert. I'm using it
now for around five years and I'm working on a OO-Database for my
Videocassettes.
I'm searching for help with BOOPSI programming.
Matthias
There is a chapter on BOOPSI in the ROM Kernal Libraries book third edition but
I haven't come across anything else about it.
Do you find OO to be a good method for desingning programs? I am supposed to be
getting some OO trainning in a few months. From what I have seen reading about
it so far it doesn't look much different from good structured programming.
Peter Wade
Autopiloting from London, England
>>Do you find OO to be a good method for desingning programs? I am supposed to
be getting some OO trainning in a few months. From what I have seen reading
about it so far it doesn't look much different from good structured
programming.<<
As far as I am concerned, OO makes programs slower, bigger, more buggy, …
than plain good (not too structured) programming.
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
> As far as I am concerned, OO makes programs slower, bigger, more buggy,
> … than plain good (not too structured) programming.
I suppose it is the same trade off between low level efficiency and fast
development that has been going on since programming began. I miss programming
in Assembler, these days I use a so called Fourth Generation Language at work,
they get worried if I use C. But I would expect OO to make programs less buggy.
Peter Wade
Autopiloting from London, England
>>I suppose it is the same trade off between low level efficiency and fast
development that has been going on since programming began. <<
Agreed.
>>I miss programming in Assembler,<<
I don't. Not programming in assembler has cost me a few years of my life in
solving compiler bugs. This is why I returned to it. I assure you: it was a
REAL pain in the ass being used to the comfort of high languages BUT I have
fewer bugs now AND they are much much easier to find.
There is one, extremely important advantage to programming in assembler instead
of other languages: all the bugs are YOURS!
>>But I would expect OO to make programs less buggy.<<
In principle, I won't disagree with this. BUT! Isn't it LOGICAL to speak the
language of the computer instead of learning another language that is
ultimately translated to machine language anyway?
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
"… all the bugs are YOURS!"
..unless, of course, there's a bug in the assembler. 🙂
"Isn't it LOGICAL to speak the language of the computer instead of learning
another language that is ultimately translated to machine language anyway?"
Not necessarily. For example, I can program in Java, and it works cross
platform immediately. It works on my Solaris SPARCstation, and it runs on
Windows 95. Two completely different architectures, no recompile of the Java
code I wrote.
There are some cases where it makes sense to program in assembler, there are
many more where it does not.
>>"… all the bugs are YOURS!"
>
>..unless, of course, there's a bug in the assembler. 🙂
I've met many of them. Make that 🙂 a 🙁
>>"Isn't it LOGICAL to speak the language of the computer instead of learning
>>another language that is ultimately translated to machine language anyway?"
>
>Not necessarily. For example, I can program in Java, and it works cross
>platform immediately. It works on my Solaris SPARCstation, and it runs on
>Windows 95. Two completely different architectures, no recompile of the Java
>code I wrote.
Agreed. Assembler is no panacea, and this is just one of a plethora of
reasons why. (Note: this does not imply a HLL is a panacea either).
>There are some cases where it makes sense to program in assembler, there are
>many more where it does not.
I'd prefer to s/many more/others/. Those goals, needs, costs, and
compromises never go away!
>>..unless, of course, there's a bug in the assembler. :-)<<
True of course, and I have met one or two. The big advantage, even then, is
that assembler errors are generally very much easier to track down and
circumvent than compiler errors. In my experience at least.
>>"Isn't it LOGICAL to speak the language of the computer instead of learning
another language that is ultimately translated to machine language anyway?"
Not necessarily. For example, I can program in Java, and it works cross
platform immediately. It works on my Solaris SPARCstation, and it runs on
Windows 95. Two completely different architectures, no recompile of the Java
code I wrote.<<
I see your point and I agree. In theory at least, writing portable code is good
programming practice. However this also depends on what levels of quality you
want to achieve. If you write portable code you'll never get the most of the
two different platforms. A chain is never stronger than its weakest link. I
don't know Java and maybe I should look into it. I had an extremely bad
experience years ago. I decided to write an accounting package that worked on
the Amiga, PC, Atari and Mac. It never really worked. Different bugs in all the
compilers made the project impossible. An example: the program for the client
database needed 2Megs of internal memory. Now, in assembler, it needs about
100K and it does more than the old one.
I am not against an easy high level language. I love that for prototyping. As a
programmer, however, I consider it to be my deontology to feel responsible for
every bug in my programs. Therefore I feel compelled to do everything in
assembler.
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
>>..unless, of course, there's a bug in the assembler. :-)<<
>
>True of course, and I have met one or two. The big advantage, even then, is
>that assembler errors are generally very much easier to track down and
>circumvent than compiler errors.
I see your use of generally, and do agree the translation to machine code
is simpler, and I hate to keep saying this, but that simply does not follow.
Even if we quality better exactly what "an assembler" means, I still think
we cannot necessarily get at this except for a case by case review of the
error. If it is a doozie, then it is a doozie. Some are obvious, some are
not. Assembler might be too low and involved to see some things. And so
on. A bug is a bug and it's the skill of the person to get at it.
Some bugs are easier, ditto for the predicaments. I won't deny this.
But that alone doesn't seem to suffice to me. Further, I think you are
leaving out significant things, like: macro assemblers, assemblers that
actually have HLL constructs, etc.
>In my experience at least.
"One is often best at what one does best."
This implies habits, savvy, the whole pot.
IOW, perhaps you are an assembler expert and have never quite put your
mindset wholeheartedly into other approaches et al. For sure then,
you might find program, compiler, OS, etc bugs in assembler faster and so on
that in a HLL language. Just like I will probably do so in C and C++ than
in Ada.
>In theory at least, writing portable code is good programming practice.
I don't see it as a good (or bad) issue. I see it as a decision made on an
educated slate.
>However this also depends on what levels of quality you
>want to achieve. If you write portable code you'll never get the most of the
>two different platforms. A chain is never stronger than its weakest link.
Your point is not invalid per se, but don't push it either.
Assembler definitely does not solve this problem. In fact, hardly at all.
Indeed, it is possible to obtain quality code that is very portable.
Where the links become not perfect is more say with different GUI's,
and generic frameworks atop of them, or where perhaps sizeof int might be
important, etc. Many can be coded, or arranged, for.
>I had an extremely bad
>experience years ago. I decided to write an accounting package that worked on
>the Amiga, PC, Atari and Mac. It never really worked. Different bugs in all the
>compilers made the project impossible.
I'm beginning to wonder if you've really ever allowed yourself the proper
exposure and getting used to to HLLs. I know some people who always seems
to purchase a lemon car, no matter how good the model seems to currently be
rated. Perhaps, Murphy was not on your side with this experience and it has
left an (improper and hence unfortunate) sour taste in your mouth?
>An example: the program for the client database needed 2Megs of internal
>memory. Now, in assembler, it needs about 100K and it does more than the
>old one.
That's an order of magnitude of 20. Unless you were running some sort of
debugging interpreter for the language in question, I cannot accept that the
language alone was the reason for this.
>I am not against an easy high level language.
But what is 'easy'?
>I consider it to be my deontology to feel responsible for
>every bug in my programs. Therefore I feel compelled to do everything in
>assembler.
I don't understand you technical decision,
but I find this noble, and wish everybody felt this same way.
>>assemblers that actually have HLL constructs<<
I must confess my ignorance here. I never saw such a thing. Sounds more or less
like C to me?
>>For sure then, you might find program, compiler, OS, etc bugs in assembler
faster and so on that in a HLL language. Just like I will probably do so in C
and C++ than in Ada.<<
Right, absolutely. However, I was not referring exclusively to bugs I make but
also to bugs in the compiler or the assembler itself.
>>I don't see it as a good (or bad) issue. I see it as a decision made on an
educated slate.<<
Agreed.
>>Your point is not invalid per se, but don't push it either. Assembler
definitely does not solve this problem. In fact, hardly at all. Indeed, it is
possible to obtain quality code that is very portable.<<
Agreed, totally. Assembler does indeed not solve this problem. The point was
that portable code can (more or less) only be written in HLL's but that you
then loose many, if not most of the specific advantages of the systems you
write for.
>>That's an order of magnitude of 20. Unless you were running some sort of
debugging interpreter for the language in question, I cannot accept that the
language alone was the reason for this.<<
It was.
>>But what is 'easy'?<<
Hard to define. I meant “easy to learn''. If a language is very hard to learn
then the language itself will nearly “cause'' errors. Of course, the simpler a
language is the more complicated your program becomes (as a rule) this can also
be a reason for errors. But since large programs are always complex this is
hardly an issue.
>>I don't understand you technical decision, but I find this noble, and wish
everybody felt this same way.<<
The decision is based on the fact that an assembler is easier to write than a
HLL and that you *may* thus presume that there are less errors in an assembler
than in a compiler. Furthermore, since the assembled code is much closer to the
source language than is the case with an HLL, chances are that those errors are
easier to track down and, hopefully, correct or circumvent.
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
PMFJI,
But did you say Java runs under Windows 95? Windows 95??? Are you sure?
I am a whisker away from installing NT in order to get Java, but I have been
put off temporarily by some horror stories, which imply I would need a new
H/D..
I am very keen to get Java. The Amiga port looks like its a long way away yet
. I do not have Solaris. I will consider any of the following. OS/2, Linux,
FreeBSD, Windows 95. AFAIK, the only versions currently out are Solaris and an
NT alpha. Has something changed? Any info appreciated…
(My Web software has been on the blink for some days now, and I can't access
the Sun Java site.)
TIA
Alex
Alex,
HotJava (for Windows) is only up to Alpha version 3 — it is extremely
unstable.
However, that said, it runs fine under Win95 — "fine" meaning that it'll
crash no more often under 95 than it does under NT. At work I run it under
both 95 and Solaris. I can't wait for an Amiga version!
-Steve Ahlstrom
Hey, cool! I didn't know you were messing around with Java these days. Have
anything on your web site yet?
Try:
http://www.vectorman.com/
with your HotJava browser, for a pretty impressive applet.
Yup, I'm sure. I run it on Win95 every day, along with Java on Sun
workstations. It's been out for weeks. I do my Java development on the Sun,
though.
The last I heard a Linux version exists, but it's very very unstable and needs
a lot of work. (That's from the guy who was doing the port). I'm really
anxious to see that port too.
Check out: http://java.sun.com
for more info!
> There is one, extremely important advantage to programming in assembler
> instead of other languages: all the bugs are YOURS!
This is very true! High level languages can be very useful but when a compiler
goes wrong it can be very tricky to get round. This afternoon at work two of us
were going through a 4GL program that was causing the compiler to crash (no
error message from the compiler, just a segmentation fault and core dump). We
did track that down, it was a syntax error that was causing the compiler to go
crazy, although we have no idea why. I am still working on another 4GL program
that compiles fine but core dumps when you run it. Now this particular language
has no way of accessing memory apart from using variables declared in the
program, and no way of making system calls, you have to stick to the built in
functions of the language. The compiler does not produce machine code but an
intermediate code which is run by a low level interpreter. So the 4GL debugger
cannot tell you anything about what memory accesses or system calls are going
on, and you can't run the code under a normal debugger that does know about
these things because it isn't machine code. So I'm back to putting display
statements in the program just like I used to do with 8 bit Microsoft Basic!
>>But I would expect OO to make programs less buggy.<<
> In principle, I won't disagree with this. BUT! Isn't it LOGICAL to speak
> the language of the computer instead of learning another language that is
> ultimately translated to machine language anyway?
I don't think it is more logical to program closer to the machine. A good high
level language allows you to think in terms of the problem you are trying to
solve. But it must be a GOOD language and a GOOD compiler. I find C a good
compromise, it allows me to structure a program as I like but it doesn't make
me feel as if I am no longer in control like some languages do.
I have a tendency to collect languages. As well as the serious tools (SAS C/C++
and Devapc) I've got more freeware compilers on this system than I have time to
use, not to mention the three versions of Amos given away by different
magazines and the nice Forth compiler that was really quite cheap… Maybe if I
spent less time looking for the perfect compiler I would get more done.
Peter Wade
Autopiloting from London, England
>>So I'm back to putting display statements in the program just like I used to
do with 8 bit Microsoft Basic!<<
Isn't that great! 🙂
>>A good high level language allows you to think in terms of the problem you
are trying to solve.<<
Of course. This is the reason that I am not really “against high level
languages''. I am against the use of HLL's by programmers making commercial
programs if they didn't program the HLL themselves because of the errors. AND I
am against HLL's altogether in many cases because of the speed disadvantage
when compared to assembler. I see that people are apparently prepared to pay
double for a computer with a speed difference of 20% so why not program in
assembler and get programs that are two, three times faster than their C
equivalents?
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
>>So I'm back to putting display statements in the program just like I used to
>>do with 8 bit Microsoft Basic!<<
>
>Isn't that great! 🙂
Frankly, I sincerely believe this kind of thing should always have its
place.
>I am against the use of HLL's by programmers making commercial
>programs if they didn't program the HLL themselves because of the errors.
But compiler writers usually don't necessarily also write the business apps
too. And I'd be hard pressed to stop one project so that the same
programmer could spend his or her time fixing the compiler before resuming
(this is partially why I think some (not all) companies are somewhat kidding
themselves when the go for "free" things like gcc and g++, anyway, that
another discussion completely). And along with that line of reasoning,
why isn't it also true that the programmer should also have been required
to have written the editor they are using, the linker, the profiler,
the operating systems, the networks?
> AND I
>am against HLL's altogether in many cases because of the speed disadvantage
>when compared to assembler.
In many case that simply a red herring argument.
> I see that people are apparently prepared to pay
>double for a computer with a speed difference of 20% so why not program in
>assembler and get programs that are two, three times faster than their C
>equivalents?
Because that is not their only goals.
Because that is not necessary the situation.
Because, in fact, it is usually only more select part of the code that is
the bottleneck.
And so on.
>>>I am against the use of HLL's by programmers making commercial >programs if
they didn't program the HLL themselves because of the errors.
>>But compiler writers usually don't necessarily also write the business apps
too. And I'd be hard pressed to stop one project so that the same programmer
could spend his or her time fixing the compiler before resuming (this is
partially why I think some (not all) companies are somewhat kidding themselves
when the go for "free" things like gcc and g++, anyway, that another discussion
completely). And along with that line of reasoning, why isn't it also true
that the programmer should also have been required to have written the editor
they are using, the linker, the profiler, the operating systems, the
networks?<<
I agree totally. I am quite convinced this would be an ideal situation. I
realize however that life is perhaps a bit too short for this. This does not
diminish the fact that this is, in my view, an ideal situation. I realize of
course that there are many reasons making this approach unsuited for reality.
>>Because that is not their only goals. Because that is not necessary the
situation. Because, in fact, it is usually only more select part of the code
that is the bottleneck. And so on.<<
I agree. However the underlying idea of what I said remains true: At least in
principle, a program written in assembler will always be more efficient than
another for the same reason that; translating from English to French it doesn't
make much sense to use Russian as an intermediate language.
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
> … I am against the use of HLL's by programmers making commercial
> programs if they didn't program the HLL themselves because of the errors.
The idea of building all my own tools has a certain apeal to me but in reality
I don't have the expertise or the time to write a compiler, and I expect that
goes for most amateur and professional developers.
My experience of compilers is not as bad as yours seems to be. If a compiler
lets you down frequently it can be a frustrating experience. I have only come
across one compiler that was that bad. I spent weeks pulling my code apart and
wondering what on earth I could be doing wrong. Eventually when one of the most
experienced programmers on the team couldn't find the bug either he
disassembled the object code and found that the compiler was generating
garbage. After that we found a few other bugs were due to similar problems and
from then on I didn't trust that compiler any more.
But that is an extreme case, I find most compilers are useful and reliable.
Some of them may get things wrong once or twice but I can accept this as long
as it doesn't happen too often.
> I see that people are apparently prepared to pay double for a computer
> with a speed difference of 20% so why not program in assembler and get
> programs that are two, three times faster than their C equivalents?
I think it is a case of fitting the development tools to the application. If
you are developing the next great high speed 3D fast moving game you need all
the speed you can get. IMHO most application programs do not. Most business
programs are likely to spend most of their time waiting for the user to press a
key or for the disc drive to give them sone data.
And how many people really need an extra 25% speed? It seems crazy to me the
difference in price between some 60MHz and 75MHz pentium systems. If I was
buying a PC I would either go for the fastest or stick with 60MHz. I expect
that most PCs these days are being sold by non-technical salesmen to
non-technical customers. They aren't going to carefully evaluate the
performance and work out how fast it needs to be for an application. The
decision is likely to be based on "Its got more MHz so it must be better".
Peter Wade
Autopiloting from London, England
>The idea of building all my own tools has a certain apeal to me but in reality
>I don't have the expertise or the time to write a compiler, and I expect that
>goes for most amateur and professional developers.
It really cannot be any other way. As much fun as it might be,
there is only 24 hours in a day, as well as accomplishing something.
And as much control as one might have into thoughts like (well, if I wrote
it I can fix it, and such) they are not the only concerns. I'd much rather
have specialists doing their specialties. At somewhere in the pike, we are
all factory workers and consumers. There is indeed a risk involved
(there is a risk involved in doing it yourself too though), but so be it.
Let's get those risks down to 0 or miniscule. Doing it all ourselves
probably doesn't do that even when humanly possible.
>But that is an extreme case, I find most compilers are useful and reliable.
And they are.
>most PCs these days are being sold by non-technical salesmen to
>non-technical customers.
ABSOLUTELY!
>They aren't going to carefully evaluate the
>performance and work out how fast it needs to be for an application. The
>decision is likely to be based on "Its got more MHz so it must be better".
Yup. Even most technical people don't realize what they do when they put a
system together.
>>The idea of building all my own tools has a certain apeal to me but in
reality I don't have the expertise or the time to write a compiler, and I
expect that goes for most amateur and professional developers.<<
For the amateurs, I agree. An amateur is, for me, someone writing programs as a
hobby who does not plan to sell them.
>>But that is an extreme case, I find most compilers are useful and reliable.<<
I agree. I didn't mean to suggest that compilers make errors as a rule and
working programs as an exception.
>>Some of them may get things wrong once or twice but I can accept this as long
as it doesn't happen too often.<<
Try to explain that to those people who just crashed with a plane because of
those errors.
>>I expect that most PCs these days are being sold by non-technical salesmen to
non-technical customers. They aren't going to carefully evaluate the
performance and work out how fast it needs to be for an application. The
decision is likely to be based on "Its got more MHz so it must be better".<<
I have, unfortunately, the same opinion
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
> >>The idea of building all my own tools has a certain apeal to me but in
> reality I don't have the expertise or the time to write a compiler, and I
> expect that goes for most amateur and professional developers.<<
> For the amateurs, I agree. An amateur is, for me, someone writing
> programs as a hobby who does not plan to sell them.
I think it applies even more to professionals writing applications. My job
includes programming (as well as support and anything else they can't find
anyone else to do). If my boss asked for an estimate to do a job and I said "I
can do it in a couple of months, but it will take me six months to write a
compiler first" he would not be pleased. In fact the pressure is on to use
fourth generation languages whenever possible because they think 4GLs make
programmers more productive. Getting more out of fewer staff seems to be the
main aim where I am working now, and I think it is true in most places.
> Try to explain that to those people who just crashed with a plane because
> of those errors.
Safety critical applications are another issue. You need development tools that
have been very well designed and very thoroughly tested. I would be more uneasy
getting on the plane if I knew the compiler was built by a team who are very
good programmers, but don't work on compilers most of the time.
Peter Wade
Autopiloting from London, England
>>Getting more out of fewer staff seems to be the main aim where I am working
now, and I think it is true in most places.<<
Same here, but I remain convinced that it *should* not be this way.
>>Safety critical applications are another issue. You need development tools
that have been very well designed and very thoroughly tested.<<
How true.
>>I would be more uneasy getting on the plane if I knew the compiler was built
by a team who are very good programmers, but don't work on compilers most of
the time.<<
If the first remains true, why?
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
>>As far as I am concerned, OO makes programs slower, bigger, more buggy,
>>…than plain good (not too structured) programming.
That is the case for programmers who do not comprehend and correctly apply the
paradigm, just as it was the case with structured programming when things moved
from "software as art" mode to "software as science" in the late 60's.
OO has been around long enough that with optomizing compilers, profilers and
debuggers there is no excuse for it to be the cause of your contentions. As is
always the case, that usually results from lack of discipline on the part of
the programmer, programmers fighting tooth and nail against progress, and
programmers to lazy to learn and use profilers and debuggers or to do proper
unit desing and testing.
The other way it gets a bad rap is when it it partially implemented late in the
development cycle. What most people fail to appreciate is the OO starts with
OOA (analyis) OOR (requirements) OOD (design) OOS (specification) before coding
even starts. The entire system or localized sub-system has to be objectified in
total – that is have all its ojects, methods and messages defined – before
coding starts, otherwise you get code like you describe. But that always
results, regardless of the paradigm in use if the paradigm is not followed from
analysis through final testing. It is not a natural outcome of OO as you
suggest.
wmc – via Autopilot!
>>That is the case for programmers who do not comprehend and correctly apply
the paradigm, just as it was the case with structured programming when things
moved from "software as art" mode to "software as science" in the late 60's.<<
The trouble with software as science is that it remains an art in exactly the
same way as literature.
Wayne, I have a problem with you! I even like your arguments! The trouble is, I
think, that you speak more like an idealist. I have programmed more or less
continously for seventeen years now. I have made horrible errors and I still
do. HOWEVER! nearly all my errors are due to typing mistakes (I don't speak for
my first year or so). I don't know whoever said it first, but I consider it
true: EVERY more or less big program contains several errors. Most of the time
this is no problem for a program but, as far I am concerned it is a problem if
you are speaking about a programming language!
The one thing no theory I know of takes into account are just plain, human
typing errors. Even if I didn't want it, bringing up this fact, has forced me
to ridiculize a few professors at a small university here in Brussels. The
reactions showed that people understood what I was saying but I was embarrassed
in their place.
>>It is not a natural outcome of OO as you suggest.<<
From what I wrote I think you will understand I didn't want to suggest that OO
CAUSES trouble. I affirm however that logic clearly dictates that OO-based
languages ARE more buggy than other, much simpler, languages.
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
Bart,
>As far as I am concerned, OO makes programs slower, bigger, more buggy,
.. than plain good (not too structured) programming.<
Hmmmmmmmm, the exec kernel is true OO. Imnsho, its a didactic play of fast,
small and stable OO code.
Since i used exec to handle my lists and structures (from Modula2), i could
reduce debugging by a reasonable amount. On this base, lists are easier to
handle than arrays 🙂 But OO exec is capable of lots more….:-)
regards,
Dieter Goettmann jetting on AP1.80 A4000:graceful host of
from Karlsruhe, Germany OS3.1,Mac7.1,NetBSD1.0
>>Hmmmmmmmm, the exec kernel is true OO. Imnsho, its a didactic play of fast,
small and stable OO code.<<
How right you are! We were, originally speaking about OO-programming languages
though. The Amiga OS has, to the best of my knowledge, NOT being written in
such a language. Heck, we don't even need to. Programming the Amiga in
assembler is almost as easy as programming it in BASIC due to the very nature
of it!
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
Bart,
> The Amiga OS has, to the best of my knowledge, NOT being written in such a
language.< To my knowledge, is was written _before_ OO-programming was en vogue
🙂 It was B, the predecessor of C, and C itself, the successors of
A(ssembler), able to write hardware- and structure-near code too. Which means,
that the principles of OOP are language indepent, indeed. Of course, you will
need a much extended – and therefore slow one – BASIC interpreter to handle
capsuled stuctures 🙂
>Programming the Amiga in assembler is almost as easy< If you use the amiga
libraries (who doesn't?), in fact you use OOP :-)) You know how easy it is…
Imnho, OOP or not OOP is a question which style one prefers for problem
analysis and solving. You may use a (preferably true) oo-language or not.
Imnho, OOP just means to switch on your brain and let it warm-up before coding.
The other i would characterize as brain-storming. Both may lead to a reasonable
result. The bill comes with management of design errors and later with
servicing and upgrading/actualisation…:-)
regards,
Dieter Goettmann jetting on AP1.80 A4000:graceful host of
from Karlsruhe, Germany OS3.1,Mac7.1,NetBSD1.0
>> To my knowledge, <the Amiga OS> was written .. in B, the predecessor of C.
To be exact, only AmigaDOS was written in a language called BCPL, a relative
of B. This system was done as a crash project when the original Amiga DOS
system (CHAOS) came unstuck during early development.
BCPL is a 32-bit langauge. It has some interesting characteristics: for
example, all BCPL code is reentrant. But because of its 32-bit heritage, it
left an uncomfortable legacy for the Amiga: most DOS information needed to be
carefully placed at a longword boundary .. and filehandles were "pointers
divided by 4". Both of these conditions made extra work for programmers if
they were taking on certain jobs.
As far as I know, all BCPL code was removed as of the DOS 2.0 system. But
for compatibility reasons, we still have to live with those B-pointers and
B-strings.
I might observe that the Amiga operating system, in general, had OO-like
characteristics. Generally, you were instructed not to fiddle with information
in the various library base structures; instead, you were to "make application"
to read or change such information via library calls. That's close to the OO
idea of encapsulation.
–Jim
>Generally, you were instructed not to fiddle with information
>in the various library base structures; instead, you were to "make application"
>to read or change such information via library calls.
I think this is related to an issue Peter was trying to understand better.
Being told not to fiddle is different that being not allowed to accidently
fiddle [directly]. Peter, do you see this?
> I think this is related to an issue Peter was trying to understand
> better. Being told not to fiddle is different that being not allowed to
> accidently fiddle [directly]. Peter, do you see this?
Yes, I saw Jim's message. I have heard people say that the Amiga's OS is very
OO like although it wasn't written in an OO language, and I can see that you
don't need a special OO language to use OO techniques. Not only that you can
use non-OO techniques with some OO languages! Maybe in a few months time I will
be clearer on what the definition of OO is.
I am coming round to the view that the protection mechanisms in C++ are a more
flexible way of isolating parts of the program than C's system of locals,
statics and seperate source files. And the idea of creating an "object" that
behaves like a black box with only the interface known to the rest of the
program has a certain elegence to it.
Peter Wade
Autopiloting from London, England
>I can see that you don't need a special OO language to use OO techniques.
Though it is preferred (IMO).
>Not only that you can use non-OO techniques with some OO languages!
Absolutely. IMO, this is the real beauty of hybrid languages like C++.
This differs from say Smalltalk, which you mentioned you'll be being trained
in, which mostly requires you to do everything OO'y. But. The real world
is varied and diverse. And so, just like a procedural solution to something
better done with OOP is not optimal, the same applies to something OOP that
doesn't have to be. This of course involves philosphy and pragmatics,
but it seems to be that since the real work is diverse that we want
applicable solutions to the problems at hand. To me, this means being able
to span the spectrum as appropriate and hence why I prefer hybrid.
I know my universe, and the current corners of it that I need to be into.
A hybrid allows you to conveniently be in this corners as they fit instead
of being boxed into the corner and fighting it.
>Maybe in a few months time I will
>be clearer on what the definition of OO is.
We all will be. Learning is a never ending process and if it were all that
simple we'd be onto something else already.
>I am coming round to the view that the protection mechanisms in C++ are a more
>flexible way of isolating parts of the program than C's system of locals,
>statics and seperate source files.
It involves that, but instead of 'more flexible' I just prefer to say
different, additional, more ways, etc. And of course there are additional
C++ features that add to these various packagings.
>And the idea of creating an "object" that
>behaves like a black box with only the interface known to the rest of the
>program has a certain elegence to it.
Certainly we should have always been striving for this. Even with "plain
old" functions. The ability to do this with other things too (for instance,
objects, templates, etc) is certainly the way to go. And, as in above, as
each problem is different, we do need varied features, hybrids, yes even
different ways, approaches and paradigms to address them all.
Jim,
thank you for refreshing my memory about BCPL and AmigaDOS 🙂 but
>But for compatibility reasons, we still have to live with those B-pointers and
B-strings<
No. My compiler handles that for me. If not, i would have a method for that 🙂
>That's close to the OO idea of encapsulation< Exec has more than just simple
encapsulation: Classes with transmitted sub-classes and methods. Using
semaphores or one of the various other message systems, you may implement
independent interacting objects.
Dieter Goettmann jetting on AP1.80 A4000:graceful host of
from Karlsruhe, Germany OS3.1,Mac7.1,NetBSD1.0
>Exec has more than just simple
>encapsulation: Classes with transmitted sub-classes and methods. Using
>semaphores or one of the various other message systems, you may implement
>independent interacting objects.
How does this compare to say MS-Windows notions of these things (object and
so on)?
>the principles of OOP are language indepent, indeed.
Indeed.
>Of course, you will
>need a much extended – and therefore slow one – BASIC interpreter to handle
>capsuled stuctures 🙂
Yes, and herein lies part of the point of an OOL. It is not so much that
you must have an OOL to do OOP, but it becomes so much more convenient
and "natural" to do so.
> Imnho, OOP or not OOP is a question which style one prefers for problem
>analysis and solving.
Exactly.
> You may use a (preferably true) oo-language or not.
For sure (obviously with some force fitting and twistings, but definitely
possible).
>Imnho, OOP just means to switch on your brain and let it warm-up before coding.
Welllllll, I think that too generalized to be useful. I mean I can
definitely warm-up and do my pre-stuff under a non-OO approach.
>The other i would characterize as brain-storming. Both may lead to a reasonable
>result. The bill comes with management of design errors and later with
>servicing and upgrading/actualisation…:-)
Actually, both may, or may even lead to the same result.
Nonetheless, if the brain-storming is not merely hacking,
hopefully there is some method to the madness, and an educated senior
programmer who is concerned with product growth maintanence and other
even disjoint subsequent products, can only be keep teethering
through the same issues.
Of course, there is always a line in the sand. I don't think I just want to
brainstorm on a 10MLOC application. I want to do a lot more, including
being aware that there will be design errors, including some beyond my
control. We are often apt to say that because say a 500 LOC app is so small
is to be consumable (or mostly so) by one human that it can be done a
different way, but I believe the issue isn't as simple as that.
For instance, if my 500 LOC is a one-day program just to obtain a rough
answer of something, it might be validly argued that the upfront time and
planning of say an OOP design would be too excessive in ratio to the
lifetime of the app. Well, it's equally valid that the nonchalantness
of the throw-away might be problematic. Also, with a design, one may have
found reasonble prototype (starting?) points for the app based on this one.
Etc. I'm not arguing for either side, just raising that the issues and
goals and needs and tradeoffs and expenses need to be constantly evaluated.
Greg,
I'm arguing for the OO side, of course.
Reviewing my programming styles back to '72, using object classes and methods
grew up in a natural-like matter, with a kind suppport of amiga os libraries in
the last eight years. As a result, prototypes and reusable code were a
convenient way to avoid the invention of the wheel every week.
🙂
Dieter Goettmann jetting on AP1.80 A4000:graceful host of
from Karlsruhe, Germany OS3.1,Mac7.1,NetBSD1.0
>I'm arguing for the OO side, of course.
Yes, I wasn't disputing that (I am too).
>Reviewing my programming styles back to '72, using object classes and methods
>grew up in a natural-like matter, with a kind suppport of amiga os libraries
>in the last eight years. As a result, prototypes and reusable code were a
>convenient way to avoid the invention of the wheel every week.
Many hearing of the formalities of OOP often ask what the excitement is about
as they've been programming/designing that way for a long time.
Sounds great!
Greg,
Replay: using OO techniques is a matter of style and not of a language. Add: To
me, a language is a medium to transport my ideas to others, or for instance
instructions to a computer. If a language does this well, i'll use it,
otherwise not. Independent of a OO label. So: OOp is possible in any language;
even in binary or assembler, like Bart does. I'm not one of those who like to
learn many different languages and dialects.
>How does this compare to say MS-Windows notions of these things (object and so
on)?<
You really want a comparison of AmigaOS with MS-Windows??? Anyone else may do
it for me. If you go to XWindows, you'll find again a lot of classes and
methods.
Dieter Goettmann jetting on AP1.80 \/ 11 /\
from Karlsruhe, Germany /\ || on /==\MIGA
>>Do you find OO [Object Oriented) to be a good method for designing programs?
I don't make great use of it myself, but sometimes – in the middle of a data
file reorganization – I wish I had done.
Here's a rough sense of what OO gives you. You can (and should) take a piece
of the program's operation, and make it a fully independent module. Let me
explain that a bit further.
For example, in laying out a data file system, you could take both the data
structures and the programs that handle the data (find it, fetch it, change it,
add new records, delete unwanted records), and bundle it all together as a
"sealed" unit. Any application program that uses the data would then never go
directly to it; instead, it would request the bundle to perform the desired
action. The application program wouldn't know how the data was stored, or how
it was fetched, just how to call the operations it needs.
Here's the payoff: if it's ever desirable to change the setup of that data
file, the whole job will take place within that sealed bundle. You might
change the order or size of records, the sort/index method, whatever. The new
bundle would just get folded into the application programs, which wouldn't
notice that anything had changed, since they never touched that data directly.
The same could be done with various I/O modules too, for example.
–Jim
I see what you mean. My usual approach to designing a program is to design data
structures that match the way I am trying to solve the problem and write
functions to manipulate them. The advantage of OO is that it encourages you to
hide the data structures behind access functions so you can then change the
"object" (which includes both the data and the access functions) and keep the
interface to the rest of the program the same. I can think of quite a few
programs I have had to maintain that I really wish had been designed like this.
Peter Wade
Autopiloting from London, England
Yes, you're catching the idea I was trying to convey: "Class Constructs and
Data Encapsulation", as it's often called. Which brings up the idea that you
have a LOT of new terminology to digest when you go to an OO language.
For example, a bundle of data and associated code (an "object" whose
structural definition is called a "class") exchanges "messages" with external
parts of the program.
Something that makes casual reading of a program difficult is the concept of
"operator overloading". Just as within Basic the "+" operator might mean more
than one thing (addition or concatenation), the C++ language allows – or
insists on – extensive operator overloading, so that one object can interact
with another in some definable way. In particular, the C "bit shift" operator
'<<' gets a lot of reuse.
Anyway, have fun with your upcoming training session.
–Jim
Jim,
Even after seventeen years of experience AND having learnt much of what I know
by YOUR articles you still amaze me with you calm objectiveness. I can only
agree with this.
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…
Thank you for those kind words.
–Jim
They were really not meant to be kind, only as objective as I can get. But yes,
I am glad you like them. Also I really love the fact that you still say
positive things about the Amiga. I feel quite alone sometimes here in Belgium.
Bart Van Bockstaele at 100574.2352@compuserve.com
… On AutoPilot and Amiga all the way from Belgium NOT from Mars!…