Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #16632 > unrolled thread
| Started by | visualforth@rocketmail.com |
|---|---|
| First post | 2012-10-23 16:09 -0700 |
| Last post | 2012-10-25 10:17 -0400 |
| Articles | 14 on this page of 74 — 16 participants |
Back to article view | Back to comp.lang.forth
I Don’t Make Mistakes. I Use C visualforth@rocketmail.com - 2012-10-23 16:09 -0700
Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-23 16:43 -0700
Re: I Don’t Make Mistakes. I Use C jacko <jackokring@gmail.com> - 2012-10-23 16:50 -0700
Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-23 18:58 -0700
Re: I Don’t Make Mistakes. I Use C jacko <jackokring@gmail.com> - 2012-10-24 15:12 -0700
Re: I Don’t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-23 14:02 -1000
Re: I Don’t Make Mistakes. I Use C Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-24 02:51 +0200
Re: I Don’t Make Mistakes. I Use C Mark Wills <forthfreak@gmail.com> - 2012-10-24 04:23 -0700
Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-23 19:20 -0700
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-24 05:04 -0500
Re: I Don?t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-24 08:04 -1000
Re: I Don?t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-24 13:11 -0700
Re: I Don?t Make Mistakes. I Use C Pavel Klinkovsky <pavel.klinkovsky@gmail.com> - 2012-10-24 13:21 -0700
Re: I Don?t Make Mistakes. I Use C Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-25 20:00 +0200
Re: I Don?t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 11:30 -0700
Re: I Don?t Make Mistakes. I Use C Anonymous <nobody@remailer.paranoici.org> - 2012-10-26 09:00 +0000
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-26 05:01 -0500
Re: I Don?t Make Mistakes. I Use C Brad Eckert <hwfwguy@gmail.com> - 2012-10-26 08:46 -0700
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-25 23:05 -0500
Re: I Don?t Make Mistakes. I Use C Anonymous <nobody@remailer.paranoici.org> - 2012-10-28 15:35 +0000
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-28 12:06 -0500
Re: I Don?t Make Mistakes. I Use C Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-28 21:38 +0100
Re: I Don?t Make Mistakes. I Use C jacko <jackokring@gmail.com> - 2012-10-28 16:34 -0700
Re: I Don?t Make Mistakes. I Use C Anonymous <nobody@remailer.paranoici.org> - 2012-10-29 10:56 +0000
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-29 06:11 -0500
Re: I Don?t Make Mistakes. I Use C rickman <gnuarm@gmail.com> - 2012-10-29 13:51 -0400
Re: I Don?t Make Mistakes. I Use C Anonymous <nobody@remailer.paranoici.org> - 2012-10-29 20:45 +0000
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-30 04:20 -0500
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-30 04:16 -0500
Re: I Don’t Make Mistakes. I Use C rickman <gnuarm@gmail.com> - 2012-10-25 10:04 -0400
Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 14:16 -0700
Re: I Don’t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-25 15:51 -1000
Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 20:14 -0700
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-25 23:11 -0500
Re: I Don?t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 21:53 -0700
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-26 01:27 -0500
Re: I Don?t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-26 07:06 -0700
Re: I Don?t Make Mistakes. I Use C Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-26 11:34 -0500
Re: I Don?t Make Mistakes. I Use C Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-26 19:13 +0200
Re: I Don?t Make Mistakes. I Use C Alex McDonald <blog@rivadpm.com> - 2012-10-27 04:49 -0700
Re: I Don?t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-25 21:20 -1000
Re: I Don’t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-25 21:23 -1000
Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-26 00:53 -0700
Re: I Don’t Make Mistakes. I Use C "Stanley Daniel de Liver" <notagoodone@invalid.org.invalid> - 2012-11-21 16:21 +0000
Re: I Don't Make Mistakes. I Use C "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-24 06:55 -0400
Re: I Don't Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-24 08:17 -1000
Re: I Don't Make Mistakes. I Use C "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-25 00:23 -0400
Re: I Don't Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-24 22:18 -0700
Re: I Don't Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-24 21:47 -1000
Re: I Don't Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 11:21 -0700
Re: I Don't Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-25 08:43 -1000
Re: I Don't Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-25 12:18 -0700
Re: I Don't Make Mistakes. I Use C "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-26 19:55 -0400
Re: I Don't Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-26 17:38 -1000
Re: I Don't Make Mistakes. I Use C Brad Eckert <hwfwguy@gmail.com> - 2012-10-26 09:07 -0700
Re: I Don't Make Mistakes. I Use C "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-26 19:56 -0400
Re: I Don't Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-26 17:47 -1000
Re: I Don't Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-26 22:04 -0700
Re: I Don't Make Mistakes. I Use C visualforth@rocketmail.com - 2012-10-27 07:27 -0700
Re: I Don't Make Mistakes. I Use C Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-27 19:14 +0200
Re: I Don't Make Mistakes. I Use C Brad Eckert <hwfwguy@gmail.com> - 2012-10-24 11:48 -0700
Re: I Don't Make Mistakes. I Use C rickman <gnuarm@gmail.com> - 2012-10-25 19:14 -0400
Re: I Don’t Make Mistakes. I Use C Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-24 10:41 -0700
Re: I Don’t Make Mistakes. I Use C Pavel Klinkovsky <pavel.klinkovsky@gmail.com> - 2012-10-24 13:10 -0700
Re: I Don’t Make Mistakes. I Use C "Elizabeth D. Rather" <erather@forth.com> - 2012-10-24 14:00 -1000
Re: I Don’t Make Mistakes. I Use C Pavel Klinkovsky <pavel.klinkovsky@gmail.com> - 2012-10-24 23:54 -0700
Re: I Don't Make Mistakes. I Use C "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-25 00:29 -0400
Re: I Don't Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-24 22:25 -0700
Re: I Don't Make Mistakes. I Use C Pavel Klinkovsky <pavel.klinkovsky@gmail.com> - 2012-10-24 23:57 -0700
Re: I Don't Make Mistakes. I Use C Pavel Klinkovsky <pavel.klinkovsky@gmail.com> - 2012-10-25 00:11 -0700
Re: I Don’t Make Mistakes. I Use C visualforth@rocketmail.com - 2012-10-24 16:14 -0700
Re: I Don’t Make Mistakes. I Use C Paul Rubin <no.email@nospam.invalid> - 2012-10-24 17:16 -0700
Re: I Don’t Make Mistakes. I Use C visualforth@rocketmail.com - 2012-10-24 17:47 -0700
Re: I Don’t Make Mistakes. I Use C rickman <gnuarm@gmail.com> - 2012-10-25 10:17 -0400
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2012-10-24 11:48 -0700 |
| Subject | Re: I Don't Make Mistakes. I Use C |
| Message-ID | <0759b9bd-7c71-4df0-a0ee-a851031a32e9@googlegroups.com> |
| In reply to | #16643 |
On Wednesday, October 24, 2012 3:51:19 AM UTC-7, Rod Pemberton wrote: > Forth should be far worse for bugs. Interpreted Forth has no error checking > whatsoever. I.e., few or no bugs will be detected. If it's compiled Forth, > the errors which are detected is entirely up to the compiler author. One > Forth compiler might detect everything whereas another won't check anything. > C compilers check for incompatible types and a fairly standard set of > various other common C coding errors. > Not when used correctly. The Forth way of working is Agile-like. Test as you go, factor and re-factor. A waterfall style of project development doesn't suit Forth very well.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-25 19:14 -0400 |
| Subject | Re: I Don't Make Mistakes. I Use C |
| Message-ID | <k6ch5m$2r9$1@dont-email.me> |
| In reply to | #16661 |
On 10/24/2012 2:48 PM, Brad Eckert wrote: > On Wednesday, October 24, 2012 3:51:19 AM UTC-7, Rod Pemberton wrote: >> Forth should be far worse for bugs. Interpreted Forth has no error checking >> whatsoever. I.e., few or no bugs will be detected. If it's compiled Forth, >> the errors which are detected is entirely up to the compiler author. One >> Forth compiler might detect everything whereas another won't check anything. >> C compilers check for incompatible types and a fairly standard set of >> various other common C coding errors. >> > Not when used correctly. The Forth way of working is Agile-like. Test as you go, factor and re-factor. A waterfall style of project development doesn't suit Forth very well. Waterfall is only one of many methods of project management. I was taught a V model with progressive decomposition until individual modules were specified and were ready to be coded. Then implementation constituted the other side of the V where as you complete each level of implementation it was tested against the spec before integration at the next higher level. Errors resulted in moving across the V to fix the requirement or the spec or the code that was erroneous and progress resumes along the V. Of course it is much better to find errors at the lowest levels, that is why they unit test every module. I believe this is what you are describing is the "Forth way". It's not like Forth is the only way to get a job done. Rick
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-10-24 10:41 -0700 |
| Message-ID | <4e87458b-7ccf-4cef-a87e-cd19135a15f9@y8g2000yqy.googlegroups.com> |
| In reply to | #16632 |
On Oct 23, 4:09 pm, visualfo...@rocketmail.com wrote: > The cost of finding and fixings bugs has not really changed a lot. Figure a factor of ten in cost for each step software moves away from the programmer. > > The big difference is that it is now possible to significantly reduce the number of bugs in the field. It has to do more with using the right tools rather than whether you don't make mistakes because you will. > > So what about Ada? I agree that, given languages that are appropriate for micro- controllers (obviously not Lisp or JavaScript, etc.), then the major distinction is which language is easiest to debug. Nothing is more important than debugging! Unless we are all going to turn into Passaniti and talk endlessly about programming, then we have to write programs --- and the programs have to be bug-free. If your programs don't work, then they aren't programs, and you are not a programmer --- this isn't a problem that can be smoothed over with a lot of talking and hand-waving --- you have to debug the program! In my experience, the primary difference between Forth and C is in debugging. Although it is possible to have a source-level debugger for Forth (I wrote one for my 65c02 cross-compiler), this isn't really what Forth is all about. Forth debugging is interactive. You write functions and you test them on the command-line. That's pretty much it! You should never get an entire program written, discover that it doesn't work, and then have to single-step through it to find out where the bug is. If you find yourself in this inenviable position, then the usual solution is to write assertions to find out where things are not what they should be (for example, Mark suggested rewriting @ and ! to do bounds-checking if you have data that is getting over-written but you don't know what is doing the over- writing). For the most part though, Forth debugging involves testing functions on the command-line, and they should be tested shortly after they are written --- you want to avoid letting a lot of untested code build up, but you should test as you go so that you always have a firm grip on the program (it is like riding a bicycle, you shouldn't generally let go of the handlebars, although this is possible on flat straightaways at low speed). I don't know anything about Ada. I vaguely suppose that it is, as Paul said: "a tanked-up version of Pascal." Also, I've heard that it is a tanked-up version of everything. It was designed by a committee and each member had their own favorite language that they wanted Ada to be, so Ada became a little bit of everything (except Forth, as the Pentagon for some reason didn't see fit to put me on the committee). I assume that Ada just uses ICE similar to C. Please tell us what you liked about Ada. I've never heard anybody say that they liked Ada before, so I'm very curious to find out what you liked about it. Most people get into Ada because they are hoping for big-dollar Pentagon work --- they don't particularly like Ada though --- for that kind of money, they would walk around on their hands with their feet up in the air, if that was what the job required. :-) P.S. --- Are you Dirk Bruehl?
[toc] | [prev] | [next] | [standalone]
| From | Pavel Klinkovsky <pavel.klinkovsky@gmail.com> |
|---|---|
| Date | 2012-10-24 13:10 -0700 |
| Message-ID | <d7e53940-d49e-4868-b417-96a344048c52@googlegroups.com> |
| In reply to | #16657 |
Dne středa, 24. října 2012 19:41:28 UTC+2 Hugh Aguilar napsal(a): > Please tell us what you liked about Ada. Here is my viewpoint as a member of international development team working in C++... I like Ada because of (shortly): - strong typing system - parameter passing - threads as native language feature - array slices - runtime check of the type constraints ... - and (maybe surprisingly) FORCED STYLE OF CODING (if you allow in in the compiler)! Pavel
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-10-24 14:00 -1000 |
| Message-ID | <_L2dnboDYZC1HBXNnZ2dnUVZ_uSdnZ2d@supernews.com> |
| In reply to | #16668 |
On 10/24/12 10:10 AM, Pavel Klinkovsky wrote: > Dne středa, 24. října 2012 19:41:28 UTC+2 Hugh Aguilar napsal(a): > >> Please tell us what you liked about Ada. > > Here is my viewpoint as a member of international development team working in C++... > > I like Ada because of (shortly): > - strong typing system > - parameter passing > - threads as native language feature > - array slices > - runtime check of the type constraints > ... > - and (maybe surprisingly) FORCED STYLE OF CODING (if you allow in in the compiler)! > > Pavel > Yep, those were all the desired features for Ada. If you like that style of compiler, Forth is probably not for you. :-) 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 | Pavel Klinkovsky <pavel.klinkovsky@gmail.com> |
|---|---|
| Date | 2012-10-24 23:54 -0700 |
| Message-ID | <d346b542-af15-4e0e-a9a9-bb96c5a33d8a@googlegroups.com> |
| In reply to | #16677 |
> Yep, those were all the desired features for Ada. If you like that style > of compiler, Forth is probably not for you. :-) Sorry Elizabeth, you are wrong. ;) I am a fancier of Forth and I used it in my projects too, mainly as a interactive debugging and testing tool. But since I am working in a huge project (unfortunatelly in C++) with many colegues, I must work in language which is mandatory. Pavel
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-10-25 00:29 -0400 |
| Subject | Re: I Don't Make Mistakes. I Use C |
| Message-ID | <k6aev2$jsv$1@speranza.aioe.org> |
| In reply to | #16668 |
"Pavel Klinkovsky" <pavel.klinkovsky@gmail.com> wrote in message news:d7e53940-d49e-4868-b417-96a344048c52@googlegroups.com... > Dne streda, 24. ríjna 2012 19:41:28 UTC+2 Hugh Aguilar napsal(a): ... > > Please tell us what you liked about Ada. > > Here is my viewpoint as a member of international development > team working in C++... Congrats, but we're not familiar with you ... > I like Ada because of (shortly): > - strong typing system A typing system detects coding errors. But, it also gets in the way of programming. Even C, with a minimal type system, requires casts or conversion type abuse for certain, otherwise simple, tasks that are easily implemented in assembly. E.g., dereference a pointer in C and have it result in the same type as the pre-dereferenced pointer. This is needed for a variety of interpreters. You need a cast, or abuse of pointer-through_integer-to_pointer conversion, or abuse of pointer-to-pointer-to-void type, etc. Then, you still need a cast if you need that data item as a function pointer ... > - parameter passing That's good. C and PL/I both have it. PL/I is actually better in that regard as it uses call-by-reference. But, parameter passing is primarily in C for a few reasons: 1) automatic allocation and free-ing of stack space, 2) to enforce the the type system, and 3) makes implementing recursion easier. Memory was a scarce resource on early computers. That's why C is typically implemented using an automatic parameter stack for procedure locals, even though a stack *IS NOT* require by the C specifications, and there have been C implementations that did not use a stack. There is nothing wrong with a 0-operand stack as long as there is some method to track the data on the stack. That's where Forth is lacking. Once you put a "variable's" value on the data stack, there is no association of that value with that variable. The data on the stack is completely separate from the data in the variable. C and other compiled HLLs keep track of a variable whether it's data is placed on a stack, in a register, or in memory. > - threads as native language feature You'll have to explain why that's important. > - array slices I've got no idea what that is. So, it's probably unneeded. > - runtime check of the type constraints So, the user, at run-time, is getting type constraint errors? That's a very bad idea. The programmer can't verify at compile time whether the types are correct or not. Did you mean something else? > ... > - and (maybe surprisingly) FORCED STYLE OF CODING > (if you allow in in the compiler)! I don't see how that's any help. Fortran had that. You had to start coding in specific text columns! It was a nightmare. BASIC had that too. It needed line numbers! In fact, every language with any syntax at all has some "FORCED STYLE OF CODING". Even Forth, a language without syntax, has developed some "standard" syntax over time, e.g., [ and ] surround the names compile only words. Even : and ; which are Forth words for starting and ending a definition can be viewed as syntax for starting and ending a procedure. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-24 22:25 -0700 |
| Subject | Re: I Don't Make Mistakes. I Use C |
| Message-ID | <7x3913t96m.fsf@ruckus.brouhaha.com> |
| In reply to | #16681 |
"Rod Pemberton" <do_not_have@notemailnotz.cnm> writes: > That's good. C and PL/I both have it. PL/I is actually better in that > regard as it uses call-by-reference. If you want to pass something by reference in C, just take its address and pass the pointer. C++ has reference types but they're just syntactic sugar for pointers anyway. >> - runtime check of the type constraints > So, the user, at run-time, is getting type constraint errors? That's a very > bad idea. The programmer can't verify at compile time whether the types > are correct or not. I think he may mean types like INTEGER[5..17] (I'm not sure of the syntax), which means an integer constrained to be in a certain range. Going out of the range is a runtime error similar to a subscript out of bounds.
[toc] | [prev] | [next] | [standalone]
| From | Pavel Klinkovsky <pavel.klinkovsky@gmail.com> |
|---|---|
| Date | 2012-10-24 23:57 -0700 |
| Subject | Re: I Don't Make Mistakes. I Use C |
| Message-ID | <b0e91f0c-d198-4d69-8b0f-7e5675bc6e1f@googlegroups.com> |
| In reply to | #16688 |
> If you want to pass something by reference in C, just take its address > and pass the pointer. C++ has reference types but they're just > syntactic sugar for pointers anyway. Yes, but in Ada it is up to the compiler to choose how the parameter should be passed. > >> - runtime check of the type constraints > I think he may mean types like INTEGER[5..17] (I'm not sure of the > syntax), which means an integer constrained to be in a certain range. > Going out of the range is a runtime error similar to a subscript out of bounds. Exactly. Pavel
[toc] | [prev] | [next] | [standalone]
| From | Pavel Klinkovsky <pavel.klinkovsky@gmail.com> |
|---|---|
| Date | 2012-10-25 00:11 -0700 |
| Subject | Re: I Don't Make Mistakes. I Use C |
| Message-ID | <ead0b6d1-4856-4d80-9294-8004df409418@googlegroups.com> |
| In reply to | #16681 |
> > > Please tell us what you liked about Ada. > > > > Here is my viewpoint as a member of international development > > team working in C++... > > Congrats, but we're not familiar with you ... OK, I just answer the asked question... Pavel
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2012-10-24 16:14 -0700 |
| Message-ID | <d86e0b8f-9534-4034-9cb2-31f7a4e88a92@googlegroups.com> |
| In reply to | #16657 |
On Wednesday, October 24, 2012 1:41:28 PM UTC-4, Hugh Aguilar wrote: > On Oct 23, 4:09 pm, visualfo...@rocketmail.com wrote: > The cost of finding and fixings bugs has not really changed a lot. Figure a factor of ten in cost for each step software moves away from the programmer. > > The big difference is that it is now possible to significantly reduce the number of bugs in the field. It has to do more with using the right tools rather than whether you don't make mistakes because you will. > > So what about Ada? I agree that, given languages that are appropriate for micro- controllers (obviously not Lisp or JavaScript, etc.), then the major distinction is which language is easiest to debug. Nothing is more important than debugging! Unless we are all going to turn into Passaniti and talk endlessly about programming, then we have to write programs --- and the programs have to be bug-free. If your programs don't work, then they aren't programs, and you are not a programmer --- this isn't a problem that can be smoothed over with a lot of talking and hand-waving --- you have to debug the program! In my experience, the primary difference between Forth and C is in debugging. Although it is possible to have a source-level debugger for Forth (I wrote one for my 65c02 cross-compiler), this isn't really what Forth is all about. Forth debugging is interactive. You write functions and you test them on the command-line. That's pretty much it! You should never get an entire program written, discover that it doesn't work, and then have to single-step through it to find out where the bug is. If you find yourself in this inenviable position, then the usual solution is to write assertions to find out where things are not what they should be (for example, Mark suggested rewriting @ and ! to do bounds-checking if you have data that is getting over-written but you don't know what is doing the over- writing). For the most part though, Forth debugging involves testing functions on the command-line, and they should be tested shortly after they are written --- you want to avoid letting a lot of untested code build up, but you should test as you go so that you always have a firm grip on the program (it is like riding a bicycle, you shouldn't generally let go of the handlebars, although this is possible on flat straightaways at low speed). I don't know anything about Ada. I vaguely suppose that it is, as Paul said: "a tanked-up version of Pascal." Also, I've heard that it is a tanked-up version of everything. It was designed by a committee and each member had their own favorite language that they wanted Ada to be, so Ada became a little bit of everything (except Forth, as the Pentagon for some reason didn't see fit to put me on the committee). I assume that Ada just uses ICE similar to C. Please tell us what you liked about Ada. I've never heard anybody say that they liked Ada before, so I'm very curious to find out what you liked about it. Most people get into Ada because they are hoping for big-dollar Pentagon work --- they don't particularly like Ada though --- for that kind of money, they would walk around on their hands with their feet up in the air, if that was what the job required. :-) P.S. --- Are you Dirk Bruehl? The author of "I Don’t Make Mistakes. I Use C" is William Wong, a technology editor for Electronic Design focusing on embedded,software, and systems. http://electronicdesign.com/author/14946/WilliamWong I only added "What about Forth ?" William wrote "So what about Ada?" to convince the reader that Ada is better than C. My goal was to get some appreciation for Forth at c.l.f. in the meaning Forth would be better than C. Seems to be that assumptions like this are like touching a wasps nest.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-24 17:16 -0700 |
| Message-ID | <7xzk3b9zjh.fsf@ruckus.brouhaha.com> |
| In reply to | #16676 |
visualforth@rocketmail.com writes: > William wrote "So what about Ada?" to convince the reader that Ada is > better than C. My goal was to get some appreciation for Forth at > c.l.f. in the meaning Forth would be better than C. Seems to be that > assumptions like this are like touching a wasps nest. Forth vs. C is a historically contentious subject as I'm sure you know. There is tons of discussion about it under the bridge. Comparisons with Ada don't come up that often, because not that many people use Ada. I think Ada is the subject of misconceptions in the computing world in general, but maybe even more intensely here (on clf) than most other places. Comparing Ada with C or C++ is maybe easier than comparing Forth with Ada or C/C++. That's because Ada and C/C++ have basically similar development models: a relatively heavyweight, batch compiler provides a lot of services which the programmer uses in a historically slow edit/compile/test/debug cycle, so "comparing" means weighing up the lists of compiler services against each other. Forth is different, it provides almost no services, but historically gave a lightweight environment with a fast, interactive code-and-test cycle, making it easier to press through obstacles that take a lot of iterations to defeat. Poorly documented hardware requiring experimentation to make stuff work is a classic example of where that helps.
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2012-10-24 17:47 -0700 |
| Message-ID | <7199ff55-3de8-45fc-bf62-38037e8fd7c1@googlegroups.com> |
| In reply to | #16678 |
On Wednesday, October 24, 2012 8:16:19 PM UTC-4, Paul Rubin wrote: > visualforth.com writes: > William wrote "So what about Ada?" to convince the reader that Ada is > better than C. My goal was to get some appreciation for Forth at > c.l.f. in the meaning Forth would be better than C. Seems to be that > assumptions like this are like touching a wasps nest. Forth vs. C is a historically contentious subject as I'm sure you know. There is tons of discussion about it under the bridge. Comparisons with Ada don't come up that often, because not that many people use Ada. I think Ada is the subject of misconceptions in the computing world in general, but maybe even more intensely here (on clf) than most other places. Comparing Ada with C or C++ is maybe easier than comparing Forth with Ada or C/C++. That's because Ada and C/C++ have basically similar development models: a relatively heavyweight, batch compiler provides a lot of services which the programmer uses in a historically slow edit/compile/test/debug cycle, so "comparing" means weighing up the lists of compiler services against each other. Forth is different, it provides almost no services, but historically gave a lightweight environment with a fast, interactive code-and-test cycle, making it easier to press through obstacles that take a lot of iterations to defeat. Poorly documented hardware requiring experimentation to make stuff work is a classic example of where that helps. Paul, Thank you so much for your clarifying explanations! You are right, Forth doesn't need those services other languages need from their compilers. But now a new level of development starts: building projects out of proven parts - that's how Forth works, but now the proven parts are expected to be words on a much higher level. I see the WIND RIVER INTELLIGENT DEVICE PLATFORM as an example for that. Source: http://www.windriver.com/products/product-overviews/PO_Wind-River-Intelligent-Device-Platform.pdf Forth vendors should recognize that there will be an important new wave of development systems.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-10-25 10:17 -0400 |
| Message-ID | <k6c64e$rvf$2@dont-email.me> |
| In reply to | #16676 |
On 10/24/2012 7:14 PM, visualforth@rocketmail.com wrote: > On Wednesday, October 24, 2012 1:41:28 PM UTC-4, Hugh Aguilar wrote: >> On Oct 23, 4:09 pm, visualfo...@rocketmail.com wrote:> The cost of finding and fixings bugs has not really changed a lot. Figure a factor of ten in cost for each step software moves away from the programmer.> > The big difference is that it is now possible to significantly reduce the number of bugs in the field. It has to do more with using the right tools rather than whether you don't make mistakes because you will.> > So what about Ada? I agree that, given languages that are appropriate for micro- controllers (obviously not Lisp or JavaScript, etc.), then the major distinction is which language is easiest to debug. Nothing is more important than debugging! Unless we are all going to turn into Passaniti and talk endlessly about programming, then we have to write programs --- and the programs have to be bug-free. If your programs don't work, then they aren't programs, and you are not a programmer --- this isn't a problem that can be smoothed over with a lot of talking and ha nd-waving --- you have to debug the program! In my experience, the primary difference between Forth and C is in debugging. Although it is possible to have a source-level debugger for Forth (I wrote one for my 65c02 cross-compiler), this isn't really what Forth is all about. Forth debugging is interactive. You write functions and you test them on the command-line. That's pretty much it! You should never get an entire program written, discover that it doesn't work, and then have to single-step through it to find out where the bug is. If you find yourself in this inenviable position, then the usual solution is to write assertions to find out where things are not what they should be (for example, Mark suggested rewriting @ and ! to do bounds-checking if you have data that is getting over-written but you don't know what is doing the over- writing). For the most part though, Forth debugging involves testing functions on the command-line, and they should be tested shortly after they are wri tten --- you want to avoid letting a lot of untested code build up, but you should test as you go so that you always have a firm grip on the program (it is like riding a bicycle, you shouldn't generally let go of the handlebars, although this is possible on flat straightaways at low speed). I don't know anything about Ada. I vaguely suppose that it is, as Paul said: "a tanked-up version of Pascal." Also, I've heard that it is a tanked-up version of everything. It was designed by a committee and each member had their own favorite language that they wanted Ada to be, so Ada became a little bit of everything (except Forth, as the Pentagon for some reason didn't see fit to put me on the committee). I assume that Ada just uses ICE similar to C. Please tell us what you liked about Ada. I've never heard anybody say that they liked Ada before, so I'm very curious to find out what you liked about it. Most people get into Ada because they are hoping for big-dollar Pentagon work --- they don't particularly like Ada though --- for that kind of money, they would walk around on their hands with their feet up in the air, if that was what the job required. :-) P.S. --- Are you Dirk Bruehl? > Seems to be that assumptions like this are like touching a wasps nest. Now you know c.l.f... Rick
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.forth
csiph-web