Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #45489 > unrolled thread
| Started by | laheadle@gmail.com |
|---|---|
| First post | 2016-02-12 13:57 -0800 |
| Last post | 2016-02-22 01:46 -0800 |
| Articles | 15 on this page of 115 — 26 participants |
Back to article view | Back to comp.lang.forth
How do you remember the stack? laheadle@gmail.com - 2016-02-12 13:57 -0800
Re: How do you remember the stack? Paul Rubin <no.email@nospam.invalid> - 2016-02-12 14:08 -0800
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-16 13:35 +1100
Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-15 19:28 -0800
Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-02-15 19:54 -0800
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-16 07:28 +0000
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-15 22:03 -1000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-16 13:30 +0000
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-16 08:20 -1000
Re: How do you remember the stack? dunno <dunno@dunno.dunno> - 2016-02-16 20:48 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-17 15:42 +0000
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-18 18:48 +1100
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-18 12:27 -0800
Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-18 14:53 -0800
Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-18 15:18 -0800
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-21 13:32 +1100
Re: How do you remember the stack? Chris Curl <ccurl609@gmail.com> - 2016-02-20 20:57 -0800
Re: How do you remember the stack? Ron Aaron <rambamist@gmail.com> - 2016-02-21 07:23 +0200
Re: How do you remember the stack? Chris Curl <ccurl609@gmail.com> - 2016-02-21 08:54 -0800
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-21 22:05 -0800
Re: How do you remember the stack? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-02-22 16:20 +0100
Re: How do you remember the stack? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-02-22 09:47 -0600
Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-02-23 16:51 -0800
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-28 15:22 +1100
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-27 21:30 -0800
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-27 21:33 -0800
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-27 21:39 -1000
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-29 13:47 +1100
Re: How do you remember the stack? Paul Rubin <no.email@nospam.invalid> - 2016-02-28 19:02 -0800
Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-28 22:26 -0800
Re: How do you remember the stack? Paul Rubin <no.email@nospam.invalid> - 2016-02-28 22:37 -0800
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-28 19:11 -0800
Re: How do you remember the stack? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-02-29 11:55 -0600
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-29 19:30 -1000
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-03-02 00:49 +1100
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-01 13:50 -1000
Re: How do you remember the stack? Paul Rubin <no.email@nospam.invalid> - 2016-03-01 16:49 -0800
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-03-01 18:04 -0800
Re: How do you remember the stack? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-02 02:53 -0600
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-02 09:57 +0000
Re: How do you remember the stack? Pablo Hugo Reda <pabloreda@gmail.com> - 2016-03-02 03:21 -0800
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-02 11:49 +0000
Re: How do you remember the stack? Pablo Hugo Reda <pabloreda@gmail.com> - 2016-03-02 04:23 -0800
Re: How do you remember the stack? stephen@mpeforth.com (Stephen Pelc) - 2016-03-02 18:32 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-02 18:41 +0000
Re: How do you remember the stack? stephen@mpeforth.com (Stephen Pelc) - 2016-03-02 20:36 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-03 07:38 +0000
Re: How do you remember the stack? stephen@mpeforth.com (Stephen Pelc) - 2016-03-03 09:26 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-03 11:15 +0000
Re: How do you remember the stack? stephen@mpeforth.com (Stephen Pelc) - 2016-03-03 15:35 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-03 15:56 +0000
Re: How do you remember the stack? stephen@mpeforth.com (Stephen Pelc) - 2016-03-03 17:04 +0000
Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-03-01 19:29 -0800
Re: How do you remember the stack? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-28 18:52 +0000
Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-02-28 13:30 -0800
Re: How do you remember the stack? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-02-29 07:55 +0100
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-29 19:34 -1000
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-03-01 20:40 -0800
Re: How do you remember the stack? Unknown <dog@gmail.com> - 2016-06-02 05:46 +0000
Re: How do you remember the stack? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-06-02 08:48 +0200
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-06-02 00:17 -0700
Re: How do you remember the stack? Michael Barry <barrym95838@yahoo.com> - 2016-06-02 19:48 -0700
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-06-02 20:34 -0700
Re: How do you remember the stack? "WJ" <w_a_x_man@yahoo.com> - 2016-02-22 19:23 +0000
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-25 20:31 +1100
Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-25 07:44 -0800
Re: How do you remember the stack? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-02-25 20:22 +0100
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-28 13:43 +1100
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-27 21:43 -1000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-28 14:53 +0000
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-28 15:27 -0800
Re: How do you remember the stack? humptydumpty <ouatubi@gmail.com> - 2016-06-02 02:02 -0700
Re: How do you remember the stack? JennyB <jennybrien@googlemail.com> - 2016-06-03 05:57 -0700
Re: How do you remember the stack? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-01 16:38 +0000
Re: How do you remember the stack? Chris Curl <ccurl609@gmail.com> - 2016-02-12 16:31 -0800
Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-02-12 17:31 -0800
Re: How do you remember the stack? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-02-13 08:03 +0100
Re: How do you remember the stack? dunno <dunno@dunno.dunno> - 2016-02-13 08:06 +0000
Re: How do you remember the stack? minforth@arcor.de - 2016-02-13 01:50 -0800
Re: How do you remember the stack? mhx@iae.nl - 2016-02-13 03:22 -0800
Re: How do you remember the stack? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-13 17:09 +0000
Re: How do you remember the stack? mhx@iae.nl - 2016-02-13 03:39 -0800
Re: How do you remember the stack? mhx@iae.nl - 2016-02-13 03:42 -0800
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-13 11:27 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-13 12:33 +0000
Re: How do you remember the stack? minforth@arcor.de - 2016-02-15 01:05 -0800
Re: How do you remember the stack? dunno <dunno@dunno.dunno> - 2016-02-14 19:34 +0000
Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-13 06:43 -0800
Re: How do you remember the stack? minforth@arcor.de - 2016-02-15 01:22 -0800
Re: How do you remember the stack? dunno <dunno@dunno.dunno> - 2016-02-15 09:48 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-15 09:53 +0000
Re: How do you remember the stack? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-15 11:26 +0000
Re: How do you remember the stack? minforth@arcor.de - 2016-02-15 04:53 -0800
Re: How do you remember the stack? dunno <dunno@dunno.dunno> - 2016-02-15 17:06 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-16 14:57 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-16 14:14 +0000
Re: How do you remember the stack? Ron Aaron <rambamist@gmail.com> - 2016-02-15 12:31 +0200
Re: How do you remember the stack? Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-02-18 22:53 +0000
Re: How do you remember the stack? Doug Hoffman <glidedog@gmail.com> - 2016-02-13 10:51 -0500
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-14 10:18 +1100
Re: How do you remember the stack? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-02-14 04:21 -0600
Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-02-20 14:36 -0800
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-21 16:35 +0000
Re: How do you remember the stack? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-21 18:34 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-22 09:52 +0000
Re: How do you remember the stack? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-22 13:07 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-22 15:41 +0000
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-22 08:24 -1000
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-22 08:21 -1000
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-22 17:51 -0800
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-22 18:15 -0800
Re: How do you remember the stack? "WJ" <w_a_x_man@yahoo.com> - 2016-02-29 06:20 +0000
Re: How do you remember the stack? "WJ" <w_a_x_man@yahoo.com> - 2016-03-02 20:42 +0000
Re: How do you remember the stack? "WJ" <w_a_x_man@yahoo.com> - 2016-06-02 20:13 +0000
Re: How do you remember the stack? humptydumpty <ouatubi@gmail.com> - 2016-02-22 01:46 -0800
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-02-14 04:21 -0600 |
| Message-ID | <D9adnZHUmp7eyF3LnZ2dnUU7-LOdnZ2d@supernews.com> |
| In reply to | #45489 |
laheadle@gmail.com wrote: > When I'm reading forth code, I have to work hard to remember the > contents of the stack. Especially when a word is more than a few > subwords long, or contains words whose stack effects I have to go > and look up, I am likely to forget what the stack looks like at the > point I was just at. So I have to backtrack to a previous known > stack state, and recover the context by reading word by word. You've already had some good replies, but I'd like to add mine. If it's hard for an experienced Forther to read code without writing down stack effects then (IMHO) it's probably not good code. Sure, sometimes stack complexity is hard to avoid, and then it's worth sprinkling the odd stack comment to make things clearer. But it's often the case that factoring is the best way to solve the problem. Also, maybe you're overusing the stack: consider putting related values into a data structure rather than passing them as a group of items on the stack. Stylish stacks are not very deep. Consistent use of stack conventions is really important. For example, words always consume their arguments. Occasionally you might violate this rule, but it should be unusual. There are other rules: for example, if you are handling co-ordinates they should always be in the same order, etc. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Whammo <sidciavic@gmail.com> |
|---|---|
| Date | 2016-02-20 14:36 -0800 |
| Message-ID | <9afbf54f-7a44-4a29-8524-6854d7678fd0@googlegroups.com> |
| In reply to | #45489 |
On Friday, February 12, 2016 at 1:57:08 PM UTC-8, lahe...@gmail.com wrote: > When I'm reading forth code, I have to work hard to remember the contents of the stack. Especially when a word is more than a few subwords long, or contains words whose stack effects I have to go and look up, I am likely to forget what the stack looks like at the point I was just at. So I have to backtrack to a previous known stack state, and recover the context by reading word by word. > > One thing I do is mentally "say" the contents of the stack after every word: "a b c...b c a...c a..." etc. This seems to help my memory. But I sometimes find I'm using so much attention remembering the stack that I don't have as much short-term memory left over as I would like for understanding the program itself. > > Part of this is that I'm still pretty new, but I am wondering if you have any similar experiences or strategies to share. Another thing, it's easier to learn and understand the objective then code it yourself than to work out someones mess.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-02-21 16:35 +0000 |
| Message-ID | <2016Feb21.173543@mips.complang.tuwien.ac.at> |
| In reply to | #45645 |
Whammo <sidciavic@gmail.com> writes:
> Another thing, it's easier to learn and understand the objective then code=
> it yourself than to work out someones mess.
If "someone" did leave a mess, yes. But is it really a mess, or is it
just that you don't understand the code yet, and an attempt to do it
from scratch is just as likely to be messier as it is to be cleaner?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-02-21 18:34 +0000 |
| Message-ID | <56ca0337$0$24033$e4fe514c@news.xs4all.nl> |
| In reply to | #45652 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >Whammo <sidciavic@gmail.com> writes: >> Another thing, it's easier to learn and understand the objective then code= >> it yourself than to work out someones mess. >If "someone" did leave a mess, yes. But is it really a mess, or is it >just that you don't understand the code yet, and an attempt to do it >from scratch is just as likely to be messier as it is to be cleaner? Joel om software has to say something about this. (And I can confirm from personal experience.) If there is a large body of software in a working environment, you cannot get away with saying it is a mess, and you will certainly not be able to rewrite it wholesale. There are those pesky details that have been edited into the software in the passed years, to get around hardly understood problems, and if you just mess with them, you're bound to create million euro damages. Instead you're bound to capture the experience by designing a regression test for a certain detail and then rewrite parts piecemeal. That can be gloriously succesful, though. The largest problem with those situations is that there are no specifications. So most of the time you're editing the source, trying to add the spec's of the routines. (That is the documentation that is missing from Forth words with only stack "documentation") On a smaller scale I've rewritten software wholesale. An example is manx. The requirement was simple to state, we wanted the gold and silver tingles to play together the pieces that were written for them. A couple of weeks and I was done. This situation is not comparable to software patches to prevent Airbuses falling from the sky, or in my case trains running over people. There one has to tread very carefully. >- anton Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-02-22 09:52 +0000 |
| Message-ID | <2016Feb22.105217@mips.complang.tuwien.ac.at> |
| In reply to | #45656 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>>Whammo <sidciavic@gmail.com> writes:
>>> Another thing, it's easier to learn and understand the objective then code=
>>> it yourself than to work out someones mess.
>
>>If "someone" did leave a mess, yes. But is it really a mess, or is it
>>just that you don't understand the code yet, and an attempt to do it
>>from scratch is just as likely to be messier as it is to be cleaner?
>
>Joel om software has to say something about this. (And I can confirm
>from personal experience.) If there is a large body of software in a
>working environment, you cannot get away with saying it is a mess,
>and you will certainly not be able to rewrite it wholesale.
Maybe you can, but the probability of failure is high. I remember
talking to someone from the IT staff of a venerable auction house;
they tried a "big bang" solution, i.e., do new software from scratch
instead of tinkering with the old one. Eventually they had to abandon
the project after huge costs were incurred; and the reason for
abandoning it was performance problems that could not be overcome by
throwing more hardware at it.
>There are those pesky details that have been edited into the software
>in the passed years, to get around hardly understood problems,
>and if you just mess with them, you're bound to create million euro
>damages.
>Instead you're bound to capture the experience by designing a
>regression test for a certain detail and then rewrite parts
>piecemeal. That can be gloriously succesful, though.
>The largest problem with those situations is that there are no
>specifications.
I.e., the software is really messy. How can you be "gloriously
successful" in such a setting (except maybe in the sense of "Paths to
Glory")? My impression is that you cannot do substantial changes to
such software, so either you live with it being hardly modifyable, or,
when the pain from that gets big enough to overcome the insistence on
bug-for-bug compatibility, eventually you replace it with something
written from scratch, probably with a specification coming out of
requirements engineering rather than from the old software; of course
with a high probablility of failure.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-02-22 13:07 +0000 |
| Message-ID | <56cb082a$0$24092$e4fe514c@news.xs4all.nl> |
| In reply to | #45672 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> >>>Whammo <sidciavic@gmail.com> writes: >>>> Another thing, it's easier to learn and understand the objective then code= >>>> it yourself than to work out someones mess. >> >>>If "someone" did leave a mess, yes. But is it really a mess, or is it >>>just that you don't understand the code yet, and an attempt to do it >>>from scratch is just as likely to be messier as it is to be cleaner? >> >>Joel om software has to say something about this. (And I can confirm >>from personal experience.) If there is a large body of software in a >>working environment, you cannot get away with saying it is a mess, >>and you will certainly not be able to rewrite it wholesale. >Maybe you can, but the probability of failure is high. I remember >talking to someone from the IT staff of a venerable auction house; >they tried a "big bang" solution, i.e., do new software from scratch >instead of tinkering with the old one. Eventually they had to abandon >the project after huge costs were incurred; and the reason for >abandoning it was performance problems that could not be overcome by >throwing more hardware at it. >>There are those pesky details that have been edited into the software >>in the passed years, to get around hardly understood problems, >>and if you just mess with them, you're bound to create million euro >>damages. >>Instead you're bound to capture the experience by designing a >>regression test for a certain detail and then rewrite parts >>piecemeal. That can be gloriously succesful, though. >>The largest problem with those situations is that there are no >>specifications. >I.e., the software is really messy. How can you be "gloriously >successful" in such a setting (except maybe in the sense of "Paths to >Glory")? My impression is that you cannot do substantial changes to >such software, so either you live with it being hardly modifyable, or, >when the pain from that gets big enough to overcome the insistence on >bug-for-bug compatibility, eventually you replace it with something >written from scratch, probably with a specification coming out of >requirements engineering rather than from the old software; of course >with a high probablility of failure. My example was the removal of the compression from the package eldo at the Dutch taxes. What you have to do is isolate a feature, think up a test that exercises that feature, and then do it. In this case the regression test was accept and rework a message consisting of 2Gbyte tax files. You must accept the fact that you may have introduced new defects, the only thing you can do is statitically prove that your improved program is better. There was a command that I was not allowed to change anything, ... until such time that maintenance engineer had to get up on successive nights for emergencies (disk full). The spec's of Eldo took one meter shelf space. (It was also utterly worthless, after one year I got some basic idea of what was going on. One year partly spent on reverse engineering that is.) A specification from requirements reverse engineering? Ha ha. Been there too. Some highly paid Dec engineers provided me with a spec of a text processing facility (mixing in changes into a 1000 page dictionary.)There was a clear requirement: the vax program must behave the same as the old pdp 11 program (assembler) and be written in C. The spec's were utterly worthless. It took me three days to replace it with a number of tests to be run on the old program. That worked. This is no comparison to situations like Eldo or Elizabeths infamous example of the airport luggage. Such large systems can be replaced piecemeal, but the way working system -> specifications -> working system is an illusion. Than Archimeded law kicks in: if you continue making noticable improvements, you end up with a certain level of quality. >- anton >-- >M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-02-22 15:41 +0000 |
| Message-ID | <2016Feb22.164131@mips.complang.tuwien.ac.at> |
| In reply to | #45674 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>when the pain from that gets big enough to overcome the insistence on
>>bug-for-bug compatibility, eventually you replace it with something
>>written from scratch, probably with a specification coming out of
>>requirements engineering rather than from the old software; of course
>>with a high probablility of failure.
...
>A specification from requirements reverse engineering? Ha ha.
I never heard about "requirements reverse engineering", and neither
has Google. I wrote about "a specification coming out of requirements
engineering rather than from the old software". "Requirements
engineering", you know, talking to users, looking at what they need to
do, etc.
>This is no comparison to situations like Eldo
>or Elizabeths infamous example of the airport luggage.
>Such large systems can be replaced piecemeal, but the way
>working system -> specifications -> working system
>is an illusion.
As far as I read about the Riad airport system, they started from the
requirements after their predecessors had failed. There was no
working computer-based system that they had to replace.
>Than Archimeded law kicks in: if you continue making noticable
>improvements, you end up with a certain level of quality.
Not sure what this has to do with Archimedes, but the typical case for
messy software is that you are afraid to make big changes, because the
software then stops working, and you don't know how to fix it. So you
make small additions here and there, and the software becomes bigger
and messier. That process continues until it becomes so hard to do
changes that people either stop doing changes, go for the
rewrite-from-scratch route, or rewrite substantial portions over a
relatively long time of not doing significant new releases.
The latter cases are rare AFAIK, but Mozilla and maybe gcc seem to be
examples of that happening.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-02-22 08:24 -1000 |
| Message-ID | <Q9GdnQOzdtvBz1bLnZ2dnUU7-IcAAAAA@supernews.com> |
| In reply to | #45678 |
On 2/22/16 5:41 AM, Anton Ertl wrote: > Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>> when the pain from that gets big enough to overcome the insistence on >>> bug-for-bug compatibility, eventually you replace it with something >>> written from scratch, probably with a specification coming out of >>> requirements engineering rather than from the old software; of course >>> with a high probablility of failure. > ... >> A specification from requirements reverse engineering? Ha ha. > > I never heard about "requirements reverse engineering", and neither > has Google. I wrote about "a specification coming out of requirements > engineering rather than from the old software". "Requirements > engineering", you know, talking to users, looking at what they need to > do, etc. > >> This is no comparison to situations like Eldo >> or Elizabeths infamous example of the airport luggage. >> Such large systems can be replaced piecemeal, but the way >> working system -> specifications -> working system >> is an illusion. > > As far as I read about the Riad airport system, they started from the > requirements after their predecessors had failed. There was no > working computer-based system that they had to replace. The "requirements" were voluminous, but practically useless. They specified every electrical connection and the color of every wire, but then threw in remarks like, "there shall be a security system for every entrance and exit" with no further description. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-02-22 08:21 -1000 |
| Message-ID | <Q9GdnQCzdts7zFbLnZ2dnUU7-IednZ2d@supernews.com> |
| In reply to | #45674 |
On 2/22/16 3:07 AM, Albert van der Horst wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > >> Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>> ... >> I.e., the software is really messy. How can you be "gloriously >> successful" in such a setting (except maybe in the sense of "Paths to >> Glory")? My impression is that you cannot do substantial changes to >> such software, so either you live with it being hardly modifyable, or, >> when the pain from that gets big enough to overcome the insistence on >> bug-for-bug compatibility, eventually you replace it with something >> written from scratch, probably with a specification coming out of >> requirements engineering rather than from the old software; of course >> with a high probablility of failure. > ... > The spec's of Eldo took one meter shelf space. (It was also > utterly worthless, after one year I got some basic idea of > what was going on. One year partly spent on reverse engineering > that is.) Deriving specs from existing software is a tricky process. The important thing, in my experience, is to concentrate on *what* the program does, not *how* it does it, except where logical algorithms (as opposed to software procedures) are at issue. > A specification from requirements reverse engineering? Ha ha. > Been there too. Some highly paid Dec engineers provided me with a > spec of a text processing facility (mixing in changes into > a 1000 page dictionary.)There was a clear requirement: the > vax program must behave the same as the old pdp 11 program > (assembler) and be written in C. > The spec's were utterly worthless. It took me three days to > replace it with a number of tests to be run on the old program. > That worked. This is no comparison to situations like Eldo > or Elizabeths infamous example of the airport luggage. > Such large systems can be replaced piecemeal, but the way > working system -> specifications -> working system > is an illusion. Yes, in the case of the airport baggage handling, we were able to reproduce the apparent behavior of the system (including the user interface, which they liked) while totally redesigning everything inside, to achieve the major improvement in throughput. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-02-22 17:51 -0800 |
| Message-ID | <6df0fe98-cdb8-49cf-95c7-224d21a38c17@googlegroups.com> |
| In reply to | #45679 |
On Monday, February 22, 2016 at 11:21:29 AM UTC-7, Elizabeth D. Rather wrote:
> Yes, in the case of the airport baggage handling, we were able to
> reproduce the apparent behavior of the system (including the user
> interface, which they liked) while totally redesigning everything
> inside, to achieve the major improvement in throughput.
The sales-person's favorite word: "we"
That baggage handling software was written on a PDP-11 when Charles Moore was still with Forth Inc. --- you are still bragging it up, despite the fact that Charles Moore left Forth Inc. decades ago --- way back in 1994/1995 that baggage-handling story was decades old and everybody had lost interest in Forth.
You really don't know anything about programming. Every example of Forth code that you have posted on comp.lang.forth was copied directly out of the "Starting Forth" book (afaik, Charles Moore wrote all those code snippets). ANS-Forth ruined Forth. ANS-Forth was just a marketing gimmick that you came up with to prove to the world that Forth Inc. sets the standard for all Forthers, but it is a mess of ambiguities and.
ANS-Forth also lacks almost everything that would be needed to write even the most basic program. For example, I'm writing some code now to work with strings, and I have to write all of the following myself. This is a waste of time! Also, this code should be written in assembly-language for speed, but if I do that then my code becomes compiler-specific. Apparently your baggage-handling software didn't involve strings, because you seem to have no experience with the subject.
: char-lower ( char -- new-char ) \ lowercase the char
dup [char] A [char] Z 1+ within if
[char] A - [char] a + then ;
: char-upper ( char -- new-char ) \ uppercase the char
dup [char] a [char] z 1+ within if
[char] a - [char] A + then ;
: string-walk ( adr len xt -- ) \ execute the xt for every char
locals| xt |
bounds ?do I c@ xt execute I c! loop ;
: lower ( adr len -- ) \ lowercase the string
['] char-lower string-walk ;
: upper ( adr len -- ) \ uppercase the string
['] char-upper string-walk ;
: str= ( adrA lenA adrB lenB -- flag ) \ compare the strings for equality
rover <> if 3drop false exit then
tuck + swap ?do \ -- adrA
dup c@ I c@ <> if drop false unloop exit then
1+ loop
drop true ;
: istr= ( adrA lenA adrB lenB -- flag ) \ compare the strings for equality case-insensitive
rover <> if 3drop false exit then
tuck + swap ?do \ -- adrA
dup c@ char-upper I c@ char-upper <> if drop false unloop exit then
1+ loop
drop true ;
: icompare { adrA lenA adrB lenB | charA charB -- -1|0|1 } \ like COMPARE except case-insensitive
lenA lenB min 0 ?do
adrA I + c@ char-upper to charA
adrB I + c@ char-upper to charB
charA charB < if -1 unloop exit then
charA charB > if 1 unloop exit then
loop
lenA lenB < if -1 exit then
lenA lenB > if 1 exit then
0 ;
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-02-22 18:15 -0800 |
| Message-ID | <a601faa0-d71c-44ec-9e19-d7efb07e4236@googlegroups.com> |
| In reply to | #45685 |
On Monday, February 22, 2016 at 6:51:14 PM UTC-7, hughag...@gmail.com wrote: > : char-upper ( char -- new-char ) \ uppercase the char > dup [char] a [char] z 1+ within if > [char] a - [char] A + then ; Lets take a look at how VFX and SwiftForth generate code: This is VFX: see char-upper CHAR-UPPER ( 004DF690 8BD3 ) MOV EDX, EBX ( 004DF692 83C39F ) ADD EBX, -61 ( 004DF695 83FB1A ) CMP EBX, 1A ( 004DF698 8BDA ) MOV EBX, EDX ( 004DF69A 0F8303000000 ) JNB/AE 004DF6A3 ( 004DF6A0 83C3E0 ) ADD EBX, -20 ( 004DF6A3 C3 ) NEXT, ( 20 bytes, 7 instructions ) ok This is SwiftForth: see char-upper 478F0F 4 # EBP SUB 83ED04 478F12 EBX 0 [EBP] MOV 895D00 478F15 8 # EBP SUB 83ED08 478F18 EBX 4 [EBP] MOV 895D04 478F1B 61 # 0 [EBP] MOV C7450061000000 478F22 7A # EBX MOV BB7A000000 478F27 EBX INC 43 478F28 40603F ( WITHIN ) CALL E812D1F8FF 478F2D EBX EBX OR 09DB 478F2F 0 [EBP] EBX MOV 8B5D00 478F32 4 [EBP] EBP LEA 8D6D04 478F35 478F41 JZ 0F8406000000 478F3B 61 # EBX SUB 83EB61 478F3E 41 # EBX ADD 83C341 478F41 RET C3 ok see within 40603F 4 # EBP SUB 83ED04 406042 EBX 0 [EBP] MOV 895D00 406045 4 [EBP] EBX MOV 8B5D04 406048 EBX NEG F7DB 40604A 0 [EBP] EBX ADD 035D00 40604D 4 # EBP ADD 83C504 406050 EBX PUSH 53 406051 0 [EBP] EBX MOV 8B5D00 406054 4 # EBP ADD 83C504 406057 EBX NEG F7DB 406059 0 [EBP] EBX ADD 035D00 40605C 4 # EBP ADD 83C504 40605F 4 # EBP SUB 83ED04 406062 EBX 0 [EBP] MOV 895D00 406065 EBX POP 5B 406066 405F7F ( U< ) CALL E814FFFFFF 40606B RET C3 ok see u< 405F7F EBX 0 [EBP] CMP 395D00 405F82 EBX EBX SBC 19DB 405F84 4 # EBP ADD 83C504 405F87 RET C3 ok
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-02-29 06:20 +0000 |
| Message-ID | <nb0nvv$5ga$1@dont-email.me> |
| In reply to | #45685 |
hughaguilar wrote:
> : char-lower ( char -- new-char ) \ lowercase the char
> dup [char] A [char] Z 1+ within if
> [char] A - [char] a + then ;
>
> : char-upper ( char -- new-char ) \ uppercase the char
> dup [char] a [char] z 1+ within if
> [char] a - [char] A + then ;
>
> : string-walk ( adr len xt -- ) \ execute the xt for every char
> locals| xt |
> bounds ?do I c@ xt execute I c! loop ;
>
> : lower ( adr len -- ) \ lowercase the string
> ['] char-lower string-walk ;
>
> : upper ( adr len -- ) \ uppercase the string
> ['] char-upper string-walk ;
SML (Standard ML):
fun str_upper s = String.map Char.toUpper s;
str_upper "foo bar";
===>
"FOO BAR"
> : str= ( adrA lenA adrB lenB -- flag ) \ compare the strings for equality
> rover <> if 3drop false exit then
> tuck + swap ?do \ -- adrA
> dup c@ I c@ <> if drop false unloop exit then
> 1+ loop
> drop true ;
>
> : istr= ( adrA lenA adrB lenB -- flag ) \ compare the strings for equality case-insensitive
> rover <> if 3drop false exit then
> tuck + swap ?do \ -- adrA
> dup c@ char-upper I c@ char-upper <> if drop false unloop exit then
> 1+ loop
> drop true ;
>
> : icompare { adrA lenA adrB lenB | charA charB -- -1|0|1 }
> \ like COMPARE except case-insensitive
> lenA lenB min 0 ?do
> adrA I + c@ char-upper to charA
> adrB I + c@ char-upper to charB
> charA charB < if -1 unloop exit then
> charA charB > if 1 unloop exit then
> loop
> lenA lenB < if -1 exit then
> lenA lenB > if 1 exit then
> 0 ;
"foo" = "foo";
===>
true
fun str_compare_i s1 s2 =
String.collate
(fn (c1,c2) => Char.compare (Char.toUpper c1, Char.toUpper c2))
(s1,s2) ;
- str_compare_i "foo" "FOO";
> val it = EQUAL : order
- str_compare_i "afoo" "FOO";
> val it = LESS : order
- str_compare_i "xfoo" "FOO";
> val it = GREATER : order
More:
String.tokens Char.isSpace " foo bar ";
===>
["foo", "bar"]
--
Goyim were born only to serve us. Without that, they have no place in the
world---only to serve the People of Israel.... They will work, they will plow,
they will reap. We will sit like an effendi and eat. --- Rabbi Ovadia Yosef
http://archive.org/download/DavidDuke_videos/TopRabbiExposesJewishRacism-cybsdwjezqi.ogv
https://web.archive.org/web/20101020044210/http://www.jpost.com/JewishWorld/JewishNews/Article.aspx?id=191782
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-03-02 20:42 +0000 |
| Message-ID | <nb7j8c$t9k$1@dont-email.me> |
| In reply to | #45685 |
hughaguilar96@gmail.com wrote: > ANS-Forth also lacks almost everything that > would be needed to write even the most basic > program. For example, I'm writing some code > now to work with strings, and I have to > write all of the following myself. This is a > waste of time! SML: val str = "ANS-Forth also lacks almost everything that would be needed to " ^ "write even the most basic program. For example, I'm writing " ^ "some code now to work with strings, and I have to write all of " ^ "the following myself. This is a waste of time!" ; val words = String.tokens Char.isSpace str; String.concatWith " " (List.take (words,1) @ List.drop (words,38)); ===> "ANS-Forth is a waste of time!" -- [T]he number of Jews killed there was 800,000,000.... [T]he Talmud makes it all clear by informing us that the blood of the holocausted Jews ran to the sea in a huge tidal wave that swept boulders in its path and was so deep that it reached the nostrils of the Romans' horses. nationalvanguard.org/2014/09/disillusioned-part-1/
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-06-02 20:13 +0000 |
| Message-ID | <niq41j$bla$1@dont-email.me> |
| In reply to | #45789 |
WJ wrote: > hughaguilar96@gmail.com wrote: > > > ANS-Forth also lacks almost everything that > > would be needed to write even the most basic > > program. For example, I'm writing some code > > now to work with strings, and I have to > > write all of the following myself. This is a > > waste of time! > > SML: > > val str = > "ANS-Forth also lacks almost everything that would be needed to " ^ > "write even the most basic program. For example, I'm writing " ^ > "some code now to work with strings, and I have to write all of " ^ > "the following myself. This is a waste of time!" ; > > val words = String.tokens Char.isSpace str; > > String.concatWith " " (List.take (words,1) @ List.drop (words,38)); > ===> > "ANS-Forth is a waste of time!" OCaml: #load "str.cma";; "ANS-Forth also lacks almost everything that would be needed to write even the most basic program. For example, I'm writing some code now to work with strings, and I have to write all of the following myself. This is a waste of time!" |> Str.split (Str.regexp " [^T]*This ") |> String.concat " " ;; ===> "ANS-Forth is a waste of time!" -- When the Israeli bombers and torpedo-planes were sent to attack and destroy the ship, the Jewish commander, seeing that it was an American vessel, had misgivings and reported to the High Command, which simply repeated the orders to attack and sink the Liberty. www.revilo-oliver.com/rpo/Bit_of_Good_News.html
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-02-22 01:46 -0800 |
| Message-ID | <e5dd3eb0-9bb7-4946-81a5-e908aefaca86@googlegroups.com> |
| In reply to | #45489 |
On Friday, February 12, 2016 at 11:57:08 PM UTC+2, lahe...@gmail.com wrote: > When I'm reading forth code, I have to work hard to remember the contents of the stack. Especially when a word is more than a few subwords long, or contains words whose stack effects I have to go and look up, I am likely to forget what the stack looks like at the point I was just at. So I have to backtrack to a previous known stack state, and recover the context by reading word by word. > > One thing I do is mentally "say" the contents of the stack after every word: "a b c...b c a...c a..." etc. This seems to help my memory. But I sometimes find I'm using so much attention remembering the stack that I don't have as much short-term memory left over as I would like for understanding the program itself. > > Part of this is that I'm still pretty new, but I am wondering if you have any similar experiences or strategies to share. Hi! Sometime ago I made a compiling from clf (mostly from Wil Baden): BEGIN QUOTES --- Programming style is not just layout. Here are six desirable qualities of program style that I got from someone in 1986. Economy. Avoidance of superfluous items in a program. Modularity. Breaking up lengthy or complex passages into subprograms. Simplicity. Using a simple or straightforward method. Structure. Writing an orderly or well-organized program. Documentation. Effective use of comments. Layout. Effective use of space -- horizontal and vertical. These are neither mutually exclusive nor complete, but they do provide a check-list for analyzing programming style. Your evaluation of these qualities will vary over time. The last quality, Layout, is the one that gets almost all the attention in Forth style notes. It is the quality that has least to do with the meaning of a program. My suggestions for Forth layout are: Do Show, Do Tell, Be Straight, Be Narrow, Don't Mumble, Don't Shout. Do Show. Show logic by phrasing, indentation, and alignment. Do Tell. Tell what's on the stack for every line. Be Straight. Minimize re-arranging elements on the stack. Be Narrow. Don't put many or unrelated items on a line. Don't Mumble. Avoid abbreviations and special characters in identifiers. Don't Shout or Whisper. Don't use all caps or all lowercase. Telling what's on the stack _for_ every line is not _on_ every line. When the stack state for the beginning of the next line is the same as in the preceding stack indicator it doesn't need repeating. I use one graphic word for every cell on the stack. `.` is used for a cell that doesn't need a name. For instance, the stack effect for `D+` could be ( a . b . -- c . ) `.`s at the beginning of a stack stack is used for cells that don't participate until a later stack indicator. | Stack effect | Upper-Case | Extra spaces after ----------------+---------------+---------------+------------------- STANDARD WORDS | | ALL | see next rows Nouns | -- n .. | First | none verbs | .. m -- | none | 1 adjectives | .. m -- n .. | none | none Interjections | -- | First | 1 ( -- Wil Baden Costa Mesa, California WilBaden@Netcom.com ) --- END-QUOTES That table I made myself to have it concise. Enjoying Forth, humptydumpty
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.forth
csiph-web