| Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung |
| projects:i_love_forth [2017-12-01 23:32] – mka | projects:i_love_forth [2017-12-02 00:01] (aktuell) – mka |
|---|
| There are some factual errors in Jack Ganssle's "I Hate Forth."((Links change from time to time. 11/2017 I got this one: https://www.embedded.com/electronics-blogs/break-points/4023811/I-Hate-Forth)) Forth is not just an interpreter that stores text (and comments) in the target. Forth is an incremental compiler. The generated code varies from simple and small address interpreters (threaded code), where the "inner interpreter" is an indirect jump to full-blown native code. Also, systems on small targets often have the outer interpreter (the one for interpreting ASCII commands) and compiler in the host. | There are some factual errors in Jack Ganssle's "I Hate Forth."((Links change from time to time. 11/2017 I got this one: https://www.embedded.com/electronics-blogs/break-points/4023811/I-Hate-Forth)) Forth is not just an interpreter that stores text (and comments) in the target. Forth is an incremental compiler. The generated code varies from simple and small address interpreters (threaded code), where the "inner interpreter" is an indirect jump to full-blown native code. Also, systems on small targets often have the outer interpreter (the one for interpreting ASCII commands) and compiler in the host. |
| |
| Forth words (subroutines) also are rarely as long as 50 lines. That's considered bad form. Forth words should be typically one or two lines long (excluding comments and special indentation, e.g. control words on a line of their own). This follows Dijkstra's principle that programs either are so simple that they obviously contain no bugs, or so complex that they contain no obvious bugs. It's clear that you can only reach reliable operation by doing the further. Forth follows traditional bottom-up engineering where you build larger parts out of proven smaller parts. The implicit parameter passing (and multiple return values) eases factoring of larger functions to an extent that can't be easily duplicated in more popular languages. Also, the interactive testing allows you to test even small words without the overhead of writing test procedures, so there's no gap between writing and testing. Writing a few hundred lines of code and then testing often results in long debug sessions because it is not clear which of the few hundred lines doesn't work). | Forth words (subroutines) also are rarely as long as 50 lines. That's considered bad form. Forth words should be typically one or two lines long (excluding comments and special indentation, e.g. control words on a line of their own). This follows Hoare's principle((Hoare, 1980, Turing Award Lecture[1]; Communications of the ACM 24 (2), (February 1981): pp. 75-83. : "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature." https://en.wikiquote.org/wiki/C._A._R._Hoare [Citation changed by the author , 2017])) that programs either are so simple that they obviously contain no bugs, or so complex that they contain no obvious bugs. It's clear that you can only reach reliable operation by doing the further. Forth follows traditional bottom-up engineering where you build larger parts out of proven smaller parts. The implicit parameter passing (and multiple return values) eases factoring of larger functions to an extent that can't be easily duplicated in more popular languages. Also, the interactive testing allows you to test even small words without the overhead of writing test procedures, so there's no gap between writing and testing. Writing a few hundred lines of code and then testing often results in long debug sessions because it is not clear which of the few hundred lines doesn't work). |
| |
| Documentation in a Forth project often is delayed. When we try something we know we will throw away, we don't write documentation. When the program is done and works (no more redesign necessary), documentation could be written. But managers drag programmers away to the next task, leaving undocumented code. IMHO undocumented code is often a management problem. In the waterfall flow, documentation (even if slightly inaccurate) is generated up front, and therefore non-existent documentation blocks the code to be written. In the Forth model (or XP model), documentation is generated as last step, after fully functional code is reached. Omitting it is bad, but that's only recognized when starting the next project. | Documentation in a Forth project often is delayed. When we try something we know we will throw away, we don't write documentation. When the program is done and works (no more redesign necessary), documentation could be written. But managers drag programmers away to the next task, leaving undocumented code. IMHO undocumented code is often a management problem. In the waterfall flow, documentation (even if slightly inaccurate) is generated up front, and therefore non-existent documentation blocks the code to be written. In the Forth model (or XP model), documentation is generated as last step, after fully functional code is reached. Omitting it is bad, but that's only recognized when starting the next project. |
| |
| Bernd Paysan\\ | Bernd Paysan |
| Mikron AG((That's History)) | |
| |
| |
