I'd like to read more from users who program real object-oriented Forth >applications.
The OOF hype of 10-15 years ago has subsided, standardization did notMost Forthers jump to the opportunity to implement another tool
find support, and various implementations seem to gather dust
on their shelves. From mini-oof to Swoop to FMS, just to name a few.
I'd like to read more from users who program real object-oriented Forth >applications.
Before I take this stuff up again I'd like to read other opinions
about good namespace management techniques.
"minf...@arcor.de" <minf...@arcor.de> writes:
I'd like to read more from users who program real object-oriented Forth >applications.Gforth uses an object-oriented header [paysan&ertl19].
You can also find minos2 in the Gforth source, which uses mini-oof2 as object-oriented system.
Before I take this stuff up again I'd like to read other opinionsObject orientation is not about name space management, it's about polymorphism (dynamic dispatch).
about good namespace management techniques.
In article <f4cb32af-52d0-4a5b...@googlegroups.com>,
minf...@arcor.de <minf...@arcor.de> wrote:
I'd like to read more from users who program real object-oriented Forth >applications.You can download the cvs archive of manx 2 from my site below
in particular manx.tar.gz.
It is object oriented as hell.
It uses 7 classes, but it could use more.
It is a substantial program, playing multiple part music,polyphonic,on multiple instruments, driven by a musical score that is essentially
a Forth program.
Moreover I testify that I couldn't pull it off, barring object
oriented techniques.
The oo package fits in one screen, and pulls in 2 auxiliary screens,
to wit an alternative compilation area, and string formatting.
I'd like to read more from users who program real object-oriented Forth applications.
The OOF hype of 10-15 years ago has subsided, standardization did not
find support, and various implementations seem to gather dust
on their shelves. From mini-oof to Swoop to FMS, just to name a few.
I am not interested in reviving dead-beaten debates. But perhaps time and experience have given new viewpoints and preferences.
Implementation-wise I had once been experimenting with wordlist entries
in headers (not only for classes) but dropped it due to other priorities
at that time. Before I take this stuff up again I'd like to read other opinions
about good namespace management techniques.
On Tuesday, November 15, 2022 at 8:29:31 AM UTC-5, minf...@arcor.de wrote:
I'd like to read more from users who program real object-oriented Forth applications.I haven't written anything that, e.g., uses objects to play music. My use has always been for myself and has focussed on formatting raw data
(from data loggers) and analyzing the same. I posted the objects extension
I use on GitHub in case anyone else is interested in it. https://github.com/DouglasBHoffman/FMS2
But I think most Forthers either write their own OOF or dismiss OOP entirely.
Back in the 1980s and 1990s the Yerk objects extension was
used at the Yerkes Observatory to control telescopes and process
images received by the scopes. Yerk was a close derivative of Neon.
I also liked most of the characteristics of Neon and kept many of
them for FMS.
The OOF hype of 10-15 years ago has subsided, standardization did notFrom Chuck Moore: "I created an object in Forth called the month.
find support, and various implementations seem to gather dust
on their shelves. From mini-oof to Swoop to FMS, just to name a few.
And this object had a starting point and a year and the number of days
and stuff like that. This is back, back very early. That's the only object I've ever done and it was useless. ... So I think object oriented programming is a mistake." ;-)
I am not interested in reviving dead-beaten debates. But perhaps time and experience have given new viewpoints and preferences.
Implementation-wise I had once been experimenting with wordlist entriesA long time ago Rodriguez & Poehlman put together a summary of the
in headers (not only for classes) but dropped it due to other priorities
at that time. Before I take this stuff up again I'd like to read other opinions
about good namespace management techniques.
various OOFs available and their differing characteristics: http://www.bradrodriguez.com/papers/oofs.htm
That information is almost fully out of date with Mops being
perhaps the only OOF from their comparison still available as far as I know.
"minf...@arcor.de" <minf...@arcor.de> writes:
Anton Ertl schrieb am Dienstag, 15. November 2022 um 19:16:34 UTC+1:
"minf...@arcor.de" <minf...@arcor.de> writes:
I'd like to read more from users who program real object-oriented Forth >> >applications.Gforth uses an object-oriented header [paysan&ertl19].
You can also find minos2 in the Gforth source, which uses mini-oof2 as
object-oriented system.
So Minos places all objects into the dictionary.Why do you think so?
mini-oof2 certainly supports allocating objects on the heap as well as in the dictionary.
Of course, GUI programmingCounterevidence: the memory usage of typical Web browsers.
does not create large object pools in heap memory.
Another case for your original question: The parser generator Gray <http://www.complang.tuwien.ac.at/forth/gray.zip> uses a hand-crafted object-oriented extension (which later inspired mini-oof) for the
different kinds (classes) of grammar operators.
Anton Ertl schrieb am Dienstag, 15. November 2022 um 19:16:34 UTC+1:
"minf...@arcor.de" <minf...@arcor.de> writes:
I'd like to read more from users who program real object-oriented ForthGforth uses an object-oriented header [paysan&ertl19].
applications.
AFAIU this is a hand-crafted prototype scheme without generic OOP wordset.
When reading the report I was wondering whether I would go to such lengths.
You can also find minos2 in the Gforth source, which uses mini-oof2 as
object-oriented system.
So Minos places all objects into the dictionary.
Of course, GUI programming
does not create large object pools in heap memory.
Doug Hoffman schrieb am Mittwoch, 16. November 2022 um 00:00:10 UTC+1:
From Chuck Moore: "I created an object in Forth called the month.
And this object had a starting point and a year and the number of days
and stuff like that. This is back, back very early. That's the only object >> I've ever done and it was useless. ... So I think object oriented programming
is a mistake." ;-)
I always had the (unfounded) impression that his ego was never his weak trait. ;-)
"if it is useless for me, it is useless"
From Chuck Moore: "I created an object in Forth called the month.
And this object had a starting point and a year and the number of days
and stuff like that. This is back, back very early. That's the only object
I've ever done and it was useless. ... So I think object oriented programming
is a mistake." ;-)
-Doug
I'd like to read more from users who program real object-oriented Forth applications.
The OOF hype of 10-15 years ago has subsided, standardization did not
find support, and various implementations seem to gather dust
on their shelves. From mini-oof to Swoop to FMS, just to name a few.
I am not interested in reviving dead-beaten debates. But perhaps time and experience have given new viewpoints and preferences.
Implementation-wise I had once been experimenting with wordlist entries
in headers (not only for classes) but dropped it due to other priorities
at that time. Before I take this stuff up again I'd like to read other opinions
about good namespace management techniques.
Anton Ertl schrieb am Mittwoch, 16. November 2022 um 09:32:14 UTC+1:
"minf...@arcor.de" <minf...@arcor.de> writes:
Anton Ertl schrieb am Dienstag, 15. November 2022 um 19:16:34 UTC+1:Why do you think so?
"minf...@arcor.de" <minf...@arcor.de> writes:
I'd like to read more from users who program real object-oriented Forth >> >> >applications.Gforth uses an object-oriented header [paysan&ertl19].
You can also find minos2 in the Gforth source, which uses mini-oof2 as
object-oriented system.
So Minos places all objects into the dictionary.
Browsing through the minos2 sources I found only few instances of ALLOCATE >that seemed to me more case-by-case than systematic object heap memory >allocations.
mini-oof2 certainly supports allocating objects on the heap as well as in the dictionary.
Yes, I see. Minos predated oof2 I guess.
In article <3e88234e-ee15-47f5-9c0d-55f1bc561e06n@googlegroups.com>,
Doug Hoffman <dhoffman888@gmail.com> wrote:
<SNIP>
From Chuck Moore: "I created an object in Forth called the month.
And this object had a starting point and a year and the number of days
and stuff like that. This is back, back very early. That's the only object
I've ever done and it was useless. ... So I think object oriented programming
is a mistake." ;-)
Actually coming up with <BUILDS DOES> means he is thinking in an
object oriented way.
The OOF hype of 10-15 years ago has subsided, standardization did not4tH has got FOOS. The name is not an accident. It features an "object method" syntax, constructors, destructors, early binding, late binding and single inheritance.
find support, and various implementations seem to gather dust
on their shelves. From mini-oof to Swoop to FMS, just to name a few.
On Tuesday, November 15, 2022 at 2:29:31 PM UTC+1, minf...@arcor.de wrote:
The OOF hype of 10-15 years ago has subsided, standardization did not4tH has got FOOS. The name is not an accident. It features an "object method" syntax, constructors, destructors, early binding, late binding and single inheritance.
find support, and various implementations seem to gather dust
on their shelves. From mini-oof to Swoop to FMS, just to name a few.
No different name spaces, though - although private members are supported.
I've done all classic design patterns - and more. It's fun to tinker with, but I've
never written a FOOS application from scratch. It never feels right. It's got a
handful of standard classes, like hash tables, streams and dynamic strings.
Featurewise - it seems to hold its ground against other Forth OOP frameworks.
I think it's fun to see it execute some (translated) stuff - but I don't feel the need
to create a program from scratch.
"minf...@arcor.de" <minforth@arcor.de> writes:
I'd like to read more from users who program real object-oriented Forth
applications.
Gforth uses an object-oriented header [paysan&ertl19].
You can also find minos2 in the Gforth source, which uses mini-oof2 as object-oriented system.
Before I take this stuff up again I'd like to read other opinions
about good namespace management techniques.
Object orientation is not about name space management, it's about polymorphism (dynamic dispatch).
- anton
@InProceedings{paysan&ertl19,
author = {Bernd Paysan and M. Anton Ertl},
title = {The new {Gforth} Header},
crossref = {euroforth19},
pages = {5--20},
url = {http://www.euroforth.org/ef19/papers/paysan.pdf},
url-slides = {http://www.euroforth.org/ef19/papers/paysan-slides.pdf},
video = {https://wiki.forth-ev.de/doku.php/events:ef2019:header},
OPTnote = {refereed},
abstract = {The new Gforth header is designed to directly
implement the requirements of Forth-94 and
Forth-2012. Every header is an object with a fixed
set of fields (code, parameter, count, name, link)
and methods (\texttt{execute}, \texttt{compile,},
\texttt{(to)}, \texttt{defer@}, \texttt{does},
\texttt{name>interpret}, \texttt{name>compile},
\texttt{name>string}, \texttt{name>link}). The
implementation of each method can be changed
per-word (prototype-based object-oriented
programming). We demonstrate how to use these
features to implement optimization of constants,
\texttt{fvalue}, \texttt{defer}, \texttt{immediate},
\texttt{to} and other dual-semantics words, and
\texttt{synonym}.}
}
@Proceedings{euroforth19,
title = {35th EuroForth Conference},
booktitle = {35th EuroForth Conference},
year = {2019},
key = {EuroForth'19},
url = {http://www.euroforth.org/ef19/papers/proceedings.pdf}
}
I've adapted Mini-OOF to ESP32forth and Taqoz (for Parallax Propeller 2) and found it to be very usable. In my opinion, CREATE and DOES> are fine for very
simple defining words, but the code rapidly goes cryptic as complexity rises. Mini-OOF Classes and Objects remain very readable as complexity rises - which
is good for maintenance. Well worth trying.
See https://github.com/bob-g4bby/Bob-Edwards--Forth-Stuff for my code
Cheers, Bob G4BBY
That is precisely my experience, with tmanx, ciasdis and other
non-trivial programs. I use my own OOF, even simpler than
Mini-OOF. Basically a multiple CREATE/DOES> .
This e.g. a serial port driver object.
It becomes incredibly messy otherwise.
\ The infamous termios struct from c. See termios.h.
\ Size must be 0x3c.
class TERMIOS
\ Method working on the whole struct
\ Get and set this struct for file DESCRIPTOR.
M: tcget TCGETS SWAP __NR_ioctl XOS ?ERRUR M;
M: tcset TCSETSF SWAP __NR_ioctl XOS ?ERRUR M;
\ All these methods working on the c_iflags field.
M: ixon $0400 set-bits M;
M: no-ixon $0400 clear-bits M;
M: ixoff $1000 set-bits M;
M: no-ixoff $1000 clear-bits M;
M: ixany $0800 set-bits M;
M: no-ixany $0800 clear-bits M;
M: no-ix $1C00 clear-bits M;
M: iraw $FFFF clear-bits M;
M: c_iflag M; 4 ALLOT
M: opost $1 set-bits M;
M: oraw $FFFF clear-bits M;
M: c_oflag M; 4 ALLOT
\ All these methods working on the c_cflags field.
M: parity $100 set-bits M;
M: no-parity $100 clear-bits M;
M: doublestop $40 set-bits M;
M: no-doublestop $40 clear-bits M;
M: size8 $30 set-bits M;
M: size7 $30 clear-bits $10 set-bits M;
M: set-speed-low DUP $F clear-bits SWAP get-code set-bits M;
M: c_cflag M; 4 ALLOT
\ All these methods working on the c_lflags field.
M: icanon $02 set-bits M;
M: no-icanon $02 clear-bits M;
M: echo $08 set-bits M;
M: no-echo $08 clear-bits M;
M: echoe $10 set-bits M;
M: no-echoe $10 clear-bits M;
M: isig $01 set-bits M;
M: no-isig $01 clear-bits M;
M: lraw $FF clear-bits M;
M: c_lflag M; 4 ALLOT
M: c_line M; 1 ( !) ALLOT \ We are now at offset $11
M: set-timeout no-icanon 5 + C! M; \ `VTIME' Timeout in DECISECONDS.
M: set-min no-icanon 6 + C! M; \ `VMIN' Minimal AMOUNT to recieve.
M: c_cc M;
$34 $11 - ALLOT \ to make speeds at an offset of $34
\ The offsets of the c_ispeed and c_ospeed are $34 $38
\ Stolen from c in 32 and 64 bits on a 64 bits system.
\ Set SPEED, for input and output the same.
\ In 64 bits those don't fit, needs an extra "1 CELLS ALLOT".
M: set-speed-high 2DUP ! 4 + ! M;
\ ALIGN \ To 32 bits intended but unaligned word better!
M: c_ispeed M; 4 ALLOT
M: c_ospeed M; 4 ALLOT
M: termios-size ^TERMIOS @ - M;
M: termios-erase >R ^TERMIOS @ R> OVER - ERASE M;
M: termios-compare >R ^TERMIOS @ R> OVER - CORA 1004 ?ERROR M;
1 CELLS ALLOT
endclass
If this is OOF, then I'm doing it too (minus fancy words).
-marcel
On Thursday, November 17, 2022 at 9:20:03 PM UTC+1, none albert wrote:
[..]
That is precisely my experience, with tmanx, ciasdis and other
non-trivial programs. I use my own OOF, even simpler than
Mini-OOF. Basically a multiple CREATE/DOES> .
This e.g. a serial port driver object.
It becomes incredibly messy otherwise.
\ The infamous termios struct from c. See termios.h.
\ Size must be 0x3c.
class TERMIOS
\ Method working on the whole struct
\ Get and set this struct for file DESCRIPTOR.
M: tcget TCGETS SWAP __NR_ioctl XOS ?ERRUR M;
M: tcset TCSETSF SWAP __NR_ioctl XOS ?ERRUR M;
\ All these methods working on the c_iflags field.
M: ixon $0400 set-bits M;
M: no-ixon $0400 clear-bits M;
M: ixoff $1000 set-bits M;
M: no-ixoff $1000 clear-bits M;
M: ixany $0800 set-bits M;
M: no-ixany $0800 clear-bits M;
M: no-ix $1C00 clear-bits M;
M: iraw $FFFF clear-bits M;
M: c_iflag M; 4 ALLOT
M: opost $1 set-bits M;
M: oraw $FFFF clear-bits M;
M: c_oflag M; 4 ALLOT
\ All these methods working on the c_cflags field.
M: parity $100 set-bits M;
M: no-parity $100 clear-bits M;
M: doublestop $40 set-bits M;
M: no-doublestop $40 clear-bits M;
M: size8 $30 set-bits M;
M: size7 $30 clear-bits $10 set-bits M;
M: set-speed-low DUP $F clear-bits SWAP get-code set-bits M;
M: c_cflag M; 4 ALLOT
\ All these methods working on the c_lflags field.
M: icanon $02 set-bits M;
M: no-icanon $02 clear-bits M;
M: echo $08 set-bits M;
M: no-echo $08 clear-bits M;
M: echoe $10 set-bits M;
M: no-echoe $10 clear-bits M;
M: isig $01 set-bits M;
M: no-isig $01 clear-bits M;
M: lraw $FF clear-bits M;
M: c_lflag M; 4 ALLOT
M: c_line M; 1 ( !) ALLOT \ We are now at offset $11
M: set-timeout no-icanon 5 + C! M; \ `VTIME' Timeout in DECISECONDS.
M: set-min no-icanon 6 + C! M; \ `VMIN' Minimal AMOUNT to recieve.
M: c_cc M;
$34 $11 - ALLOT \ to make speeds at an offset of $34
\ The offsets of the c_ispeed and c_ospeed are $34 $38
\ Stolen from c in 32 and 64 bits on a 64 bits system.
\ Set SPEED, for input and output the same.
\ In 64 bits those don't fit, needs an extra "1 CELLS ALLOT".
M: set-speed-high 2DUP ! 4 + ! M;
\ ALIGN \ To 32 bits intended but unaligned word better!
M: c_ispeed M; 4 ALLOT
M: c_ospeed M; 4 ALLOT
M: termios-size ^TERMIOS @ - M;
M: termios-erase >R ^TERMIOS @ R> OVER - ERASE M;
M: termios-compare >R ^TERMIOS @ R> OVER - CORA 1004 ?ERROR M;
1 CELLS ALLOT
endclass
If this is OOF, then I'm doing it too (minus fancy words).
-marcel--
...
From Chuck Moore: "I created an object in Forth called the month.
And this object had a starting point and a year and the number of days
and stuff like that. This is back, back very early. That's the only object I've ever done and it was useless. ... So I think object oriented programming
is a mistake." ;-)
The old Minos uses Bernd Paysan's more heavy-weight OOF. Minos2 uses mini-oof2; I think Minos2 and mini-oof2 were developed concurrently.
https://suzdalnitski.medium.com/oop-will-make-you-suffer-846d072b4dce
https://suzdalnitski.medium.com/oop-design-patterns-bd2c4fb3014c
http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
https://ovid.github.io/articles/why-is-object-oriented-programming-bad.html
https://chiefio.wordpress.com/2018/12/27/why-object-oriented-programming-is-bad/
https://suzdalnitski.medium.com/oop-design-patterns-bd2c4fb3014c
http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
https://ovid.github.io/articles/why-is-object-oriented-programming-bad.html
https://chiefio.wordpress.com/2018/12/27/why-object-oriented-programming-is-bad/
A quote from Suzdalnitski's article:be automatically enforced.
„How can we enforce sufficient constraints to prevent the code from turning into spaghetti? Two options — manually, or automatically. Manual approach is error-prone, humans will always make errors. Therefore, it is logical for such constraints to
Unfortunately, OOP is not the solution we’ve all been looking for. It provides no constraints to help with the problem of code entanglement. One can become proficient in various OOP best practices, like Dependency Injection, test-driven Development,Domain-Driven Design, and others (which do help). However, none of that is enforced by the programming paradigm itself (and no such tooling exists that would enforce the best practices).
None of the built-in OOP features help with preventing spaghetti code — encapsulation simply hides and scatters state across the program, which only makes things worse. Inheritance adds even more confusion. OOP polymorphism once again makes thingseven more confusing — there are no benefits in not knowing what exact execution path the program is going to take at runtime. Especially when multiple levels of inheritance are involved.”
So the use of the „old-fashionable” Forth-screens — instead of the files — is
the better remedy for spaghetti-code (if avoiding „the arrow”). These impose
„constraints to prevent the code from turning into spaghetti”.
As for the OOP paradigm… IMHO it's adding just more „red tape” into program, with
no REAL benefits. Whatever is done using OOP — can be done as well in procedural
way, but it'll be done quicker and in lesser amount of code. The amount of OOP that
CREATE...DOES brings is roughly enough for me. Or — when programming in C — at
most creating „objects” using struct (no polymorphism, no inheritance, no delegation,
nothing like that).
Of course everyone is free to use whatever suits him.
The citation reads like a typical rant from a long gone time when OOP was hyped and people
tried to apply OO tools even to problems that had few to even zero data/method objects.
No wonder results were unsatisfactory. OTOH disciplined programmers following appropriate
coding guidelines write readable structured code even in BASIC or BASH - without Forth screens.
The citation reads like a typical rant from a long gone time when OOP was hyped and people„Even in BASH”, you say… then why (according to Suzdalnitski) they somehow
tried to apply OO tools even to problems that had few to even zero data/method objects.
No wonder results were unsatisfactory. OTOH disciplined programmers following appropriate
coding guidelines write readable structured code even in BASIC or BASH - without Forth screens.
can't do that using C++/C# etc.? Maybe OOP paradigm has something to do
with that?
I have seen a=
lso lots of ugly=20
hacked-together blocks in my time, chained together through -->. BTW the wo= >rd --> had been used
widely then, but for whatever reason did not make it into ANS Forth.
"minf...@arcor.de" <minforth@arcor.de> writes:
I have seen a=
lso lots of ugly=20
hacked-together blocks in my time, chained together through -->. BTW the wo= >> rd --> had been used
widely then, but for whatever reason did not make it into ANS Forth.
I used -->, too, when I programmed with blocks.
The Gforth documentation for --> says:
|[...] Not recommended, because it destroys the independence of
|loading. Use 'thru' (which is standard) or '+thru' instead.
Zbig schrieb am Freitag, 16. Dezember 2022 um 15:27:18 UTC+1:
The citation reads like a typical rant from a long gone time when OOP was hyped and people„Even in BASH”, you say… then why (according to Suzdalnitski) they somehow
tried to apply OO tools even to problems that had few to even zero data/method objects.
No wonder results were unsatisfactory. OTOH disciplined programmers following appropriate
coding guidelines write readable structured code even in BASIC or BASH - without Forth screens.
can't do that using C++/C# etc.? Maybe OOP paradigm has something to do
with that?
It is a wide world and Suzdalnitski has his own experience. I am not counter-argumenting here.
I think his words are correct before his personal background. The praise of limited Forth screens
goes hand in hand with factoring to smaller routines (words in Forth speak) which brings some
benefits indeed, but only when the programmer is disciplined. I have seen also lots of ugly
hacked-together blocks in my time, chained together through -->.
Indeed. I wanted to know how far I can get with mini-oof2...
Are screen users any less capable of improving on what they've done? After working withForth blocks:
same for many years I gravitated to a form that satisfied me. I won't say it's the only
or best way.
On Friday, December 16, 2022 at 9:53:44 PM UTC-6, dxforth wrote:
Are screen users any less capable of improving on what they've done? After working withForth blocks:
same for many years I gravitated to a form that satisfied me. I won't say it's the only
or best way.
I camp often months at a time in all seasons contending with thunder
storms, freezing nights, blistering days but worst of all Mariah; not
to mention gnats, mosquitoes and flies that can bite through socks and
draw blood, poison plants, thorns that puncher through shoes and
briers that entangle and rip, spiders, snakes, wild pig (do my best to
avoid mountain lion and bear). Living in a house is much easier, but
all the other can be dealt with and life on trail provides many
lasting memories.
--
me
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 43:05:33 |
| Calls: | 6,709 |
| Calls today: | 2 |
| Files: | 12,243 |
| Messages: | 5,354,017 |