Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #3564 > unrolled thread
| Started by | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| First post | 2011-06-26 15:13 -0500 |
| Last post | 2011-07-02 17:52 +0000 |
| Articles | 20 on this page of 328 — 44 participants |
Back to article view | Back to comp.lang.forth
The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-06-26 15:13 -0500
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-27 16:13 +0100
Re: The Lisp Curse vandys@vsta.org - 2011-06-27 15:50 +0000
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-27 16:55 +0100
Re: The Lisp Curse vandys@vsta.org - 2011-06-27 17:23 +0000
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-27 20:09 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-06-29 18:59 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 12:49 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-02 16:38 -0700
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-03 11:27 +0000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-03 17:40 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-04 18:38 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-06-30 12:25 -0700
Forth OO ( was: Re: The Lisp Curse ) Doug Hoffman <glidedog@gmail.com> - 2011-07-12 09:43 -0400
Re: Forth OO ( was: Re: The Lisp Curse ) Doug Hoffman <glidedog@gmail.com> - 2011-07-12 12:35 -0400
Re: Forth OO ( was: Re: The Lisp Curse ) John Passaniti <john.passaniti@gmail.com> - 2011-07-13 10:02 -0700
Re: Forth OO ( was: Re: The Lisp Curse ) Doug Hoffman <glidedog@gmail.com> - 2011-07-14 08:32 -0400
Re: Forth OO ( was: Re: The Lisp Curse ) Alex McDonald <blog@rivadpm.com> - 2011-07-14 07:10 -0700
Re: Forth OO ( was: Re: The Lisp Curse ) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-14 09:31 -0500
Re: The Lisp Curse arc@vorsicht-bissig.de - 2011-07-12 22:20 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-13 10:01 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-28 03:02 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-06-27 21:29 -1000
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-28 06:55 -0400
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-06-28 06:17 -0500
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-28 14:14 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-06-30 16:08 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:01 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-01 13:41 -1000
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-04 21:18 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 02:26 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-02 16:56 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-02 08:28 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-02 17:00 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-03 10:20 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-04 20:57 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-06 15:45 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-06 16:19 -0700
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-07-07 01:23 +0000
Re: The Lisp Curse "David N. Williams" <williams@umich.edu> - 2011-07-06 21:44 -0400
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-06 19:01 -0700
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-07-07 10:39 +0000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-07 13:07 -0700
Re: The Lisp Curse "David N. Williams" <williams@umich.edu> - 2011-07-06 21:42 -0400
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-07 10:32 +0100
Re: The Lisp Curse marko <marko@marko.marko.marko> - 2011-07-07 22:09 +1000
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-07 09:19 -0500
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-07 14:08 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 10:33 +0100
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-08 05:31 -0500
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 17:47 +0100
Re: The Lisp Curse vandys@vsta.org - 2011-07-08 17:23 +0000
Re: The Lisp Curse Spam@ControlQ.com - 2011-07-08 15:34 -0400
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 21:04 +0100
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-08 10:34 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 21:28 +0100
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-09 15:25 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-10 10:14 +0100
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-10 22:02 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 03:18 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-11 12:42 -0700
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-12 19:42 +0000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-12 14:42 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-07-11 07:01 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 07:24 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-11 20:40 -0700
Re: The Lisp Curse Ron Aaron <rambamist@gmail.com> - 2011-07-11 21:24 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-12 18:54 -0700
Re: The Lisp Curse Ron Aaron <rambamist@gmail.com> - 2011-07-12 20:45 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-13 00:28 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-13 10:25 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-11 19:55 +0100
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 13:41 -0700
Re: The Lisp Curse Mark Wills <forthfreak@forthfiles.net> - 2011-07-11 13:45 -0700
Re: The Lisp Curse Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-07-12 21:51 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-09 16:49 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 04:27 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-07 14:53 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-28 11:57 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-29 21:54 -0700
Re: The Lisp Curse Julian Fondren <ayrnieu@gmail.com> - 2011-07-30 18:22 -0500
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-01 12:59 +0000
Re: The Lisp Curse Julian Fondren <ayrnieu@gmail.com> - 2011-08-02 00:07 -0500
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-01 22:58 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-08 20:44 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-31 10:25 +0100
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-08 16:00 -0700
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-10 07:08 -1000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-10 18:01 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-11 03:05 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 07:37 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-11 10:07 -0500
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 08:32 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-11 08:37 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 18:25 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-12 01:37 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-12 07:15 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-12 08:02 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-11 08:13 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 18:50 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-12 01:39 -0700
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-11 10:06 +0000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 08:02 -0700
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-12 11:49 +0000
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-12 13:18 +0000
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-08-12 18:49 +0200
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-12 12:52 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-14 09:54 -0400
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-14 12:53 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-14 13:21 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-14 15:09 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-15 04:52 -0400
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-15 03:46 -0400
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-08-15 12:15 +0000
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-08-15 20:51 +0200
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-08-15 21:56 +0000
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-15 19:50 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-16 03:07 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-18 23:45 -0700
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-18 11:38 +0000
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-18 07:57 -1000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-15 06:01 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-16 05:10 -0400
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-16 03:13 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-18 23:31 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-19 06:09 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-20 17:14 -0700
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-20 20:38 -0700
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-20 20:49 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-20 23:39 -0700
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-21 00:29 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 00:57 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 01:04 -0700
Hamming numbers (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-22 16:12 +0000
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net> - 2011-08-21 13:21 +0200
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 10:40 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-21 13:56 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 12:33 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 12:42 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 13:30 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 12:49 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-23 10:20 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:15 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-24 00:13 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-21 13:41 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 11:48 -0400
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-22 10:36 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 22:57 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-22 23:28 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-23 04:16 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-23 08:29 -0500
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-23 14:59 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:12 -0400
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:09 -0400
Re: The Lisp Curse vandys@vsta.org - 2011-08-22 16:54 +0000
Re: The Lisp Curse Doug Hoffman <glidedog@gmail.com> - 2011-08-23 10:48 -0400
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-23 11:41 -0500
Re: The Lisp Curse vandys@vsta.org - 2011-08-23 17:11 +0000
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-23 12:27 -0500
Re: The Lisp Curse Brad <hwfwguy@gmail.com> - 2011-08-23 10:07 -0700
Re: The Lisp Curse Pablo Hugo Reda <pabloreda@gmail.com> - 2011-08-23 13:02 -0700
Re: The Lisp Curse vandys@vsta.org - 2011-08-23 20:30 +0000
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-21 13:49 -0400
Re: The Lisp Curse George Hubert <georgeahubert@yahoo.co.uk> - 2011-08-22 01:49 -0700
Re: The Lisp Curse vandys@vsta.org - 2011-08-22 17:02 +0000
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-22 07:50 -1000
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-23 01:03 -0700
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-22 22:38 -1000
Hamming numbers (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-22 15:10 +0000
Re: Hamming numbers Paul Rubin <no.email@nospam.invalid> - 2011-08-23 00:09 -0700
Re: Hamming numbers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-23 13:09 +0000
Re: Hamming numbers Paul Rubin <no.email@nospam.invalid> - 2011-08-23 10:41 -0700
Re: Hamming numbers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-23 17:58 +0000
Re: Hamming numbers Paul Rubin <no.email@nospam.invalid> - 2011-08-24 00:25 -0700
Re: Hamming numbers Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net> - 2011-08-24 07:17 +0200
Re: The Lisp Curse vandys@vsta.org - 2011-08-19 17:41 +0000
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-19 18:05 +0000
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-19 13:53 -0500
Re: The Lisp Curse Pablo Hugo Reda <pabloreda@gmail.com> - 2011-08-19 13:15 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-19 15:39 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-19 19:49 -0400
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-19 17:41 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-20 03:54 -0400
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-08-20 15:20 +0000
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-21 14:41 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 11:47 -0400
Re: The Lisp Curse coos haak <chforth@hccnet.nl> - 2011-08-22 20:30 +0200
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-22 15:22 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 23:34 -0400
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-22 22:48 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:07 -0400
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-23 15:44 -1000
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-23 21:43 -0700
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-08-20 08:55 +0000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-12 10:49 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-13 14:03 +0000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-14 07:57 -0700
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-12 09:51 -1000
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-13 13:45 +0000
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-13 08:08 -1000
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-08-14 02:56 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-13 04:35 -0500
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-12 07:53 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-13 14:13 +0000
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-13 13:59 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-14 14:46 +0000
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-17 01:31 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-06-28 03:24 -0500
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201106.rodent.frell.theremailer.net> - 2011-06-28 19:55 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 06:30 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-29 13:49 +0100
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-29 14:02 +0100
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 18:16 -0400
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-06-29 15:45 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 19:45 -0400
Re: The Lisp Curse Elko T <nono.black.elko@gmail.com> - 2011-06-29 22:08 -0400
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-30 10:07 -0400
Re: The Lisp Curse coos haak <chforth@hccnet.nl> - 2011-06-30 20:44 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-30 18:08 -0400
Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-06-30 20:07 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-06-30 22:12 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:01 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-01 17:59 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) The Beez <the.beez.speaks@gmail.com> - 2011-07-01 16:33 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-02 18:37 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) kenney@cix.compulink.co.uk - 2011-07-01 06:07 -0500
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:00 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-01 14:06 +0000
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-01 14:57 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-02 16:55 +0000
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:04 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-02 11:26 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) coos haak <chforth@hccnet.nl> - 2011-07-02 22:10 +0200
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-02 14:36 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-02 21:36 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-02 18:25 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-03 10:53 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-04 23:41 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-05 01:02 -0700
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-02 22:46 +0200
Re: The Lisp Curse David Thompson <dave.thompson2@verizon.net> - 2011-07-18 01:25 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-30 14:44 +0100
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 23:24 +0100
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-03 12:04 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-03 20:24 -0400
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 02:21 -0700
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-04 16:02 +0200
Re: The Lisp Curse Tarkin <tarkin000@gmail.com> - 2011-07-04 10:21 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 11:13 -0700
Re: The Lisp Curse Tarkin <tarkin000@gmail.com> - 2011-07-04 12:31 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 15:01 -0700
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-04 13:23 -1000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 01:45 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-05 11:34 +0000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 05:34 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-05 14:28 +0000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 09:39 -0700
OT: full virtualization (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-07 15:36 +0000
Re: OT: full virtualization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-07 13:17 -0500
Re: OT: full virtualization Alex McDonald <blog@rivadpm.com> - 2011-07-08 04:53 -0700
Re: OT: full virtualization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-08 17:11 +0000
Re: OT: full virtualization Alex McDonald <blog@rivadpm.com> - 2011-07-08 12:41 -0700
Re: OT: full virtualization (was: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-08 04:34 -0700
Re: OT: full virtualization (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-10 16:03 +0000
Re: OT: full virtualization (was: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-10 13:06 -0700
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-07 00:11 +0200
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-06 12:47 -1000
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-07 10:07 +0000
Re: The Lisp Curse Tarkin <tarkin000@gmail.com> - 2011-07-07 13:00 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-04 12:40 -0500
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 11:15 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-04 15:53 -0500
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-05 10:16 +0200
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 02:23 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-05 09:54 -0500
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-05 22:33 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-05 16:28 -0500
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 16:18 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-04 15:03 -0400
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-05 00:20 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-05 11:35 -0400
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 09:46 -0700
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-05 23:13 +0200
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-05 15:31 -0700
Re: The Lisp Curse kenney@cix.compulink.co.uk - 2011-07-07 04:38 -0500
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-05 19:21 -0500
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-05 14:57 -1000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-05 20:48 -0700
Re: The Lisp Curse BruceMcF <agila61@netscape.net> - 2011-07-06 07:38 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-06 09:46 -0500
Re: The Lisp Curse kenney@cix.compulink.co.uk - 2011-07-07 04:38 -0500
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-07 10:41 -0500
Re: The Lisp Curse BruceMcF <agila61@netscape.net> - 2011-07-07 09:12 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-06 09:53 -0500
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-06 21:45 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-07 14:48 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-07-07 20:20 +0100
Re: The Lisp Curse coos haak <chforth@hccnet.nl> - 2011-07-08 04:39 +0200
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-07-12 23:22 +0100
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-12 19:35 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-07-13 23:37 +0100
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-12 05:10 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-12 03:44 -0500
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-13 22:06 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-14 04:01 -0500
Re: The Lisp Curse kenney@cix.compulink.co.uk - 2011-07-07 04:38 -0500
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-03 07:34 -0500
Re: The Lisp Curse Spam@ControlQ.com - 2011-06-29 13:25 -0400
Forth as implementation language vandys@vsta.org - 2011-06-29 18:27 +0000
Re: Forth as implementation language Spam@ControlQ.com - 2011-06-29 17:50 -0400
Re: Forth as implementation language vandys@vsta.org - 2011-06-29 22:45 +0000
Re: Forth as implementation language Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 13:04 +0100
Re: Forth as implementation language Spam@ControlQ.com - 2011-06-30 11:42 -0400
Re: Forth as implementation language "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-30 13:12 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-06-29 08:38 -1000
Re: The Lisp Curse Spam@ControlQ.com - 2011-06-29 18:01 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-06-29 12:50 -1000
Re: The Lisp Curse stephenXXX@mpeforth.com (Stephen Pelc) - 2011-06-30 08:15 +0000
Re: The Lisp Curse Spam@ControlQ.com - 2011-07-03 15:22 -0400
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 13:09 +0100
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 18:31 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-06-29 23:01 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-01 09:42 -0500
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-01 18:49 +0000
Re: The Lisp Curse Mentifex <mentifex@myuw.net> - 2011-06-29 15:41 -0700
Re: The Lisp Curse "Fuschia, President-Elect of the Bright Purplish-Green Council" <fp-eotbp-gc@ibm.com> - 2011-06-29 19:16 -0400
Re: The Lisp Curse Mark Wills <forthfreak@forthfiles.net> - 2011-06-30 00:34 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-02 17:52 +0000
Page 2 of 17 — ← Prev page 1 [2] 3 4 … 17 Next page →
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-07-13 10:01 -0700 |
| Message-ID | <76c5c1a4-657e-4b82-b887-beb05bda1be4@eb1g2000vbb.googlegroups.com> |
| In reply to | #4077 |
On Jul 13, 1:20 am, a...@vorsicht-bissig.de wrote: > This sounds really interesting, John - both the fact that > the Lua community have agreed on object abstractions which > don't imply any particular object paradigm, and that you've > used two different paradigms in the same project. > > This project wouldn't be an open source one, by any > chance, would it? Yes and no. The project itself was under contract, and I don't own the code. But most of the underlying libraries we used are open source. I'll try to cull together some examples, and probably put it on my little-used blog (since it isn't immediately relevant here). I am starting on a new project at work where parts are going to be released to the public. I don't know if anyone will care as it is a programmatic description of the UDP-based communications protocol our products use. It's in Lua and uses both classes and prototypes (which isn't any big trick, as the syntactic sugar Lua provides works fine with both styles). Here incidentally is a Wiki page that offers some examples of different styles of objects in Lua (classes, prototypes, no/single/ multiple inheritance, early bound/late bound, etc.): http://lua-users.org/wiki/ObjectOrientedProgramming
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-06-28 03:02 -0400 |
| Message-ID | <iububn$am$1@speranza.aioe.org> |
| In reply to | #3582 |
"Chris Hinsley" <chris.hinsley@gmail.com> wrote in message news:201106271655172796-chrishinsley@gmailcom... > > However, reading the linked to article I feel Andrew might have posted > this here in the Forth newsgroup because theres a lot of similar > arguements for Forth ! > In the AI Winter" article it links to, the similarities are even more pronounced: http://c2.com/cgi/wiki?AiWinter Read the Lisp quote. With slight changes, here is the start of that Lisp quote as modified for Forth: "Forth was always very general-purpose, but was especially good at real-time control, and was for a long time very closely associated with astronomer's telescopes. The Forth companies rode the great embedded microcontroller wave in the early 90's, when large corporations poured millions of dollars into the Forth that hype promised manageable, readable, and fast Forth software in 10 years. When the promises turned out to be harder than originally thought, ... " From the "Lisp Curse" article: "Real Hackers have also known, for a while, that C and C++ are not appropriate for most programs that don't need to do arbitrary bit-fiddling." Wow, some people just truly hate C don't they? I guess belittling a successful HLL language is one way to make your unwise decision to use an another unpopular, unsuccessful one seem less grating. What's really telling though is that none of the people who hate C seem to hate other Algol derived languages such as BASIC and Pascal, nor Pascal derivatives: Algol W, Modula, Modula-2, Oberon, Prolog, nor C derivatives: C++, Java, Objective-C. What is that: irrationality, or hate? ISTM that Forth and Lisp programmers seem to use the word "feel" alot, instead of "think"... Would you say this is true? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2011-06-27 21:29 -1000 |
| Message-ID | <Puidnb2hFt5ZH5TTnZ2dnUVZ_qGdnZ2d@supernews.com> |
| In reply to | #3593 |
On 6/27/11 9:02 PM, Rod Pemberton wrote: > "Chris Hinsley"<chris.hinsley@gmail.com> wrote in message > news:201106271655172796-chrishinsley@gmailcom... >> >> However, reading the linked to article I feel Andrew might have posted >> this here in the Forth newsgroup because theres a lot of similar >> arguements for Forth ! >> > > In the AI Winter" article it links to, the similarities are even more > pronounced: > http://c2.com/cgi/wiki?AiWinter > > Read the Lisp quote. With slight changes, here is the start of that Lisp > quote as modified for Forth: > > "Forth was always very general-purpose, but was especially good at real-time > control, and was for a long time very closely associated with astronomer's > telescopes. The Forth companies rode the great embedded microcontroller > wave in the early 90's, when large corporations poured millions of dollars > into the Forth that hype promised manageable, readable, and fast Forth > software in 10 years. When the promises turned out to be harder than > originally thought, ... " The promises of Forth were more like smaller programs and much, much shorter development times -- now, not in 10 years. In my experience, we delivered every time, right then, not as some future promise. But we failed spectacularly in the public relations/marketing sphere: our successes went largely unnoticed. The great myth in technology is that "if you build a better mousetrap the world will beat a path to your door." In other words, technical superiority will win on its merits. That is not true. Technical superiority will win if and only if there is a substantial, dedicated, and well-funded marketing campaign behind it. 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 | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-06-28 06:55 -0400 |
| Message-ID | <iucc02$369$1@speranza.aioe.org> |
| In reply to | #3594 |
"Elizabeth D Rather" <erather@forth.com> wrote in message news:Puidnb2hFt5ZH5TTnZ2dnUVZ_qGdnZ2d@supernews.com... > > The great myth in technology is that "if you build a better mousetrap > the world will beat a path to your door." In other words, technical > superiority will win on its merits. That is not true. > ISTM, the "better mousetrap" was invented *before* the mousetrap by over half a century (1894 vs. 1832 or so). The mechanism used in spring-loaded bar mouse traps is basically identical to the firing mechanism in single-action revolvers. They both have a hammer, trigger, latch (sear), and a spring. Variations of this mechanism are what guns still use to this day. So, yeah, a path was beaten to someone's door, I'd say ... Oh, BTW, we now know the egg came first, since birds _evolved_ from dinosaurs which laid eggs... So, that quote is out also. :-) > Technical > superiority will win if and only if there is a substantial, dedicated, > and well-funded marketing campaign behind it. > For most cases, I agree. I.e., that's true for a free, open, capitalistic marketplace. There are exceptions though. E.g., SCSI, x86 PCs, Intel/MS, military weapons, etc. SCSI just won't die. The x86 computing platform won by default. "Last man standing." Intel and MS are monopolies. The military tests everything. The government buys from whomever won the contract bid. And, there are many markets around the world that are "closed" or "private" or not capitalistic. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-06-28 06:17 -0500 |
| Message-ID | <aOOdnaAF3f2zJZTTnZ2dnUVZ8vednZ2d@supernews.com> |
| In reply to | #3600 |
Rod Pemberton <do_not_have@noavailemail.cmm> wrote: > E.g., SCSI, x86 PCs, Intel/MS, military weapons, etc. SCSI just > won't die. The x86 computing platform won by default. "Last man > standing." Well, let's see. SCSI was certainly good enough. The x86 won because it was compatible with a lot of what went before and because it was decently fast. (People always cite the 68000, but it came a fair bit later and it was dog slow.) As Hermann Hauser put it, "I remember when Bill Gates visited us and I showed him an operating system that was much more developed than MS-DOS at the time. We thought this was a clear advantage; not realising that the game had changed and the real advantage was standards." > Intel and MS are monopolies. Intel perhaps, but both of them have problems getting into mobile technology, which is where a lot of the attention (and money) is going. Look instead at ARM and Google. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Chris Hinsley <chris.hinsley@gmail.com> |
|---|---|
| Date | 2011-06-28 14:14 +0100 |
| Message-ID | <2011062814140394997-chrishinsley@gmailcom> |
| In reply to | #3594 |
> The great myth in technology is that "if you build a better mousetrap > the world will beat a path to your door." In other words, technical > superiority will win on its merits. That is not true. Technical > superiority will win if and only if there is a substantial, dedicated, > and well-funded marketing campaign behind it. > > Cheers, > Elizabeth Amen sister. ! The best tech definate dosn't mean you'll win. :( Chris
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2011-06-30 16:08 -0700 |
| Message-ID | <9c50a06d-fd91-46bb-89cc-8ca83d167259@j15g2000yqf.googlegroups.com> |
| In reply to | #3594 |
On Jun 28, 1:29 am, Elizabeth D Rather <erat...@forth.com> wrote: > The promises of Forth were more like smaller programs and much, much > shorter development times -- now, not in 10 years. In my experience, we > delivered every time, right then, not as some future promise. But we > failed spectacularly in the public relations/marketing sphere: our > successes went largely unnoticed. > > The great myth in technology is that "if you build a better mousetrap > the world will beat a path to your door." In other words, technical > superiority will win on its merits. That is not true. Technical > superiority will win if and only if there is a substantial, dedicated, > and well-funded marketing campaign behind it. > > Cheers, > Elizabeth This is pretty typical of salespeople --- to believe that anything can be sold with a well-funded marketing campaign behind it. This actually works pretty well when selling soda pop or energy drinks. It is not a good plan with a computer programming language however. I think that Forth failed largely because it continued to use threaded schemes well into the 1990s, whereas C generated machine code. The result was that Forth code got a reputation for being at least an order of magnitude slower than C code. Memory was also a problem. In the days of MS-DOS, PolyForth required the programmer to fit his code, data, and dictionary headers, all into a *single* 64K segment. Apparently nobody at Forth Inc. knew that the 8086 allows programs to be put into multiple segments (CS for code, DS for data, and ES for the dictionary headers). Most likely, the 8086 version of PolyForth was just a direct port of an old 8080 Forth system. PolyForth just didn't compare well with Turbo C, which was the main competition. The slow indirect-threaded-code and the 64K limit combined to make PolyForth unsuitable for anything except tiny toy programs. All of this talk about the need for a "well-funded marketing campaign" is just Elizabeth Rather wishing that people would give her money. The problem was technical. I read that article about the "Lisp Curse." There is actually a huge abundance of Lisp code available. If you need a library of code, you generally have dozens of choices available. That is the so-called "Lisp Curse." By comparison, the "Forth Curse" is that you don't generally have anything available, but you are required to write everything yourself from scratch. When I wrote my LLRB tree implementation in Forth, I was called "incompetent" (Passaniti) and a "donkey" (Ron), etc.. That doesn't happen in the Lisp community --- people there are encouraged to write software tools and make them publicly available --- that is why there are so many Lisp libraries available. I really wish that somebody would write a library of code in competition with my novice package. You don't have to go up against the entire thing --- you could just pick out one aspect, such as arrays, lists or associative arrays, and write your own version. Would that be so difficult?
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-07-01 16:01 -0400 |
| Message-ID | <iul94d$mim$1@speranza.aioe.org> |
| In reply to | #3679 |
"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message news:9c50a06d-fd91-46bb-89cc-8ca83d167259@j15g2000yqf.googlegroups.com... > > Memory was also a problem. In the days of MS-DOS, PolyForth required > the programmer to fit his code, data, and dictionary headers, all into > a *single* 64K segment. Apparently nobody at Forth Inc. knew that the > 8086 allows programs to be put into multiple segments (CS for code, DS > for data, and ES for the dictionary headers). > The x86 segmented memory model caused problems for C too. Yes, many, many x86 compilers produced C code for the segmented model without problems. But, there are examples of C compilers that won't: GCC, LCC. To be fair, that's not the entire story for either of them. LCC did produce x86 segmented code at first. They abandoned that after having problems with C specification compliance with segmentation. GCC was designed for non-segmented memory platforms from the start. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2011-07-01 13:41 -1000 |
| Message-ID | <2NydnatdH8uExpPTnZ2dnUVZ_jadnZ2d@supernews.com> |
| In reply to | #3699 |
On 7/1/11 10:01 AM, Rod Pemberton wrote: > "Hugh Aguilar"<hughaguilar96@yahoo.com> wrote in message > news:9c50a06d-fd91-46bb-89cc-8ca83d167259@j15g2000yqf.googlegroups.com... >> >> Memory was also a problem. In the days of MS-DOS, PolyForth required >> the programmer to fit his code, data, and dictionary headers, all into >> a *single* 64K segment. Apparently nobody at Forth Inc. knew that the >> 8086 allows programs to be put into multiple segments (CS for code, DS >> for data, and ES for the dictionary headers). >> > > The x86 segmented memory model caused problems for C too. Yes, many, many > x86 compilers produced C code for the segmented model without problems. > But, there are examples of C compilers that won't: GCC, LCC. To be fair, > that's not the entire story for either of them. LCC did produce x86 > segmented code at first. They abandoned that after having problems with C > specification compliance with segmentation. GCC was designed for > non-segmented memory platforms from the start. 32-bit polyFORTH used a full 32-bit address space. The DOS implementation (pF32-386/pMSD) used the Phar Lap DOS extender and operated in virtual mode, with address space to 1 Mb. 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 | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2011-07-04 21:18 -0700 |
| Message-ID | <dadb67d7-2426-4667-af17-7fd8785593d3@r27g2000prr.googlegroups.com> |
| In reply to | #3704 |
On Jul 1, 5:41 pm, Elizabeth D Rather <erat...@forth.com> wrote: > On 7/1/11 10:01 AM, Rod Pemberton wrote: > > "Hugh Aguilar"<hughaguila...@yahoo.com> wrote in message > >news:9c50a06d-fd91-46bb-89cc-8ca83d167259@j15g2000yqf.googlegroups.com... > > >> Memory was also a problem. In the days of MS-DOS, PolyForth required > >> the programmer to fit his code, data, and dictionary headers, all into > >> a *single* 64K segment. Apparently nobody at Forth Inc. knew that the > >> 8086 allows programs to be put into multiple segments (CS for code, DS > >> for data, and ES for the dictionary headers). > > 32-bit polyFORTH used a full 32-bit address space. The DOS > implementation (pF32-386/pMSD) used the Phar Lap DOS extender and > operated in virtual mode, with address space to 1 Mb. By the time that the 80386 came out, Forth was already dead. There was a short period after the 80386 came out during which people continued to use MS-DOS and would use DOS-extenders to access memory beyond the 640K limit (mostly because Windows 3.1 was so horrible). This trailing edge of MS-DOS became obsolete when Windows-95 came out. When I wrote MFX at Testra, this was done on the 32-bit version of UR/ Forth running on a DOS-extender. Forth was already dead though --- other than a few rinky-dink outfits such as Testra that used Forth, everybody was using C and C++ (Turbo Pascal and Delphi too). During the decade that the 8088 and 80286 were used to run MS-DOS, PolyForth supported only the Tiny memory-model. This is largely what killed Forth. Most casual observers assume that Forth Inc. defines Forth (they assume this because Forth Inc. owns the name "Forth"). When these people see that Forth Inc. is run by incompetents who don't even know that the 8088 provides access to more than 64K of memory, they believe that the entire Forth community must be incompetent without any further evidence --- PolyForth permanently ruined Forth's reputation --- this all happened many years prior to the introduction of the 80386. If Forth Inc. hadn't dragged the name "Forth" through the mud in the late 1980s, Forth might have succeeded. I blame Forth Inc. entirely for Forth's failure. To be more specific, I blame *you* for ruining Forth's reputation.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-05 02:26 -0700 |
| Message-ID | <296152e2-54c3-42ec-a8f6-69512a9f9931@t7g2000vbv.googlegroups.com> |
| In reply to | #3794 |
On Jul 5, 5:18 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote: > On Jul 1, 5:41 pm, Elizabeth D Rather <erat...@forth.com> wrote: > > > On 7/1/11 10:01 AM, Rod Pemberton wrote: > > > "Hugh Aguilar"<hughaguila...@yahoo.com> wrote in message > > >news:9c50a06d-fd91-46bb-89cc-8ca83d167259@j15g2000yqf.googlegroups.com... > > > >> Memory was also a problem. In the days of MS-DOS, PolyForth required > > >> the programmer to fit his code, data, and dictionary headers, all into > > >> a *single* 64K segment. Apparently nobody at Forth Inc. knew that the > > >> 8086 allows programs to be put into multiple segments (CS for code, DS > > >> for data, and ES for the dictionary headers). > > > 32-bit polyFORTH used a full 32-bit address space. The DOS > > implementation (pF32-386/pMSD) used the Phar Lap DOS extender and > > operated in virtual mode, with address space to 1 Mb. > > By the time that the 80386 came out, Forth was already dead. > > There was a short period after the 80386 came out during which people > continued to use MS-DOS and would use DOS-extenders to access memory > beyond the 640K limit (mostly because Windows 3.1 was so horrible). > This trailing edge of MS-DOS became obsolete when Windows-95 came out. > When I wrote MFX at Testra, this was done on the 32-bit version of UR/ > Forth running on a DOS-extender. Forth was already dead though --- > other than a few rinky-dink outfits such as Testra that used Forth, > everybody was using C and C++ (Turbo Pascal and Delphi too). > > During the decade that the 8088 and 80286 were used to run MS-DOS, > PolyForth supported only the Tiny memory-model. This is largely what > killed Forth. Most casual observers assume that Forth Inc. defines > Forth (they assume this because Forth Inc. owns the name "Forth"). > When these people see that Forth Inc. is run by incompetents who don't > even know that the 8088 provides access to more than 64K of memory, > they believe that the entire Forth community must be incompetent > without any further evidence --- PolyForth permanently ruined Forth's > reputation --- this all happened many years prior to the introduction > of the 80386. > > If Forth Inc. hadn't dragged the name "Forth" through the mud in the > late 1980s, Forth might have succeeded. I blame Forth Inc. entirely > for Forth's failure. To be more specific, I blame *you* for ruining > Forth's reputation. You only have yourself to blame for ruining your own.
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2011-07-02 16:56 -0700 |
| Message-ID | <cdd45ec8-43a4-486f-96ca-f20b48fa5629@p6g2000vbj.googlegroups.com> |
| In reply to | #3699 |
On Jul 1, 2:01 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm> wrote: > "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message > > news:9c50a06d-fd91-46bb-89cc-8ca83d167259@j15g2000yqf.googlegroups.com... > > > > > Memory was also a problem. In the days of MS-DOS, PolyForth required > > the programmer to fit his code, data, and dictionary headers, all into > > a *single* 64K segment. Apparently nobody at Forth Inc. knew that the > > 8086 allows programs to be put into multiple segments (CS for code, DS > > for data, and ES for the dictionary headers). > > The x86 segmented memory model caused problems for C too. Yes, many, many > x86 compilers produced C code for the segmented model without problems. > But, there are examples of C compilers that won't: GCC, LCC. To be fair, > that's not the entire story for either of them. LCC did produce x86 > segmented code at first. They abandoned that after having problems with C > specification compliance with segmentation. GCC was designed for > non-segmented memory platforms from the start. > > Rod Pemberton The 8086 architecture was thin *only* thing being used for MS-DOS, and MS-DOS commanded maybe 99% of the market (the Apple Macintosh, Atari ST and Amiga had *very* thin usage). Anybody who was going to program under MS-DOS was expected to master the concept of segments (it is not difficult). Anybody who fails to master this most rudimentary concept would not be taken seriously --- this includes QBasic and PolyForth and some other toy languages (actually, I think that QBasic did use the Small memory model internally, so even it was ahead of PolyForth). GCC has primarily been used on Linux (and BSD) systems, and on micro- controllers, neither of which use the 8086 architecture. As for LCC, I've never heard of it being used by anybody --- afaik, it is just an educational system intended to teach compiler design.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2011-07-02 08:28 +0100 |
| Message-ID | <iumh9u$24i$1@dont-email.me> |
| In reply to | #3679 |
On 01/07/2011 00:08, Hugh Aguilar wrote: [...] > > I really wish that somebody would write a library of code in > competition with my novice package. You don't have to go up against > the entire thing --- you could just pick out one aspect, such as > arrays, lists or associative arrays, and write your own version. Would > that be so difficult? Do you have a memory problem are are you just disingenuous? You've been told before about the Forth Foundation Library, and indeed have adversely commented on it. https://groups.google.com/group/comp.lang.forth/browse_frm/thread/e9d153aa4a2ae48/6a324f46003cd91e?hl=en&lnk=gst&q=%22forth+foundation+library%22+novice#6a324f46003cd91e The FFL has been in existence longer than your novice package and has far more functionality. If you think your novice package is better, and I don't know whether it is or not, the onus is on you to provide facts and figures proving so instead of just stating opinions and just ignoring its existence. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2011-07-02 17:00 -0700 |
| Message-ID | <a6324f49-4f81-46f7-9621-b850742e87fa@t9g2000vbv.googlegroups.com> |
| In reply to | #3709 |
On Jul 2, 1:28 am, Gerry Jackson <ge...@jackson9000.fsnet.co.uk> wrote: > On 01/07/2011 00:08, Hugh Aguilar wrote: > [...] > > > > > I really wish that somebody would write a library of code in > > competition with my novice package. You don't have to go up against > > the entire thing --- you could just pick out one aspect, such as > > arrays, lists or associative arrays, and write your own version. Would > > that be so difficult? > > Do you have a memory problem are are you just disingenuous? You've been > told before about the Forth Foundation Library, and indeed have > adversely commented on it. > > https://groups.google.com/group/comp.lang.forth/browse_frm/thread/e9d... > > The FFL has been in existence longer than your novice package and has > far more functionality. If you think your novice package is better, and > I don't know whether it is or not, the onus is on you to provide facts > and figures proving so instead of just stating opinions and just > ignoring its existence. > > -- > Gerry Show me *any* application program that has been written using FFL. Or better yet, write one yourself! FFL isn't any good. It is extremely primitive in many ways --- I don't think that it is suitable for use in application programming.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2011-07-03 10:20 +0100 |
| Message-ID | <iupc83$itn$1@dont-email.me> |
| In reply to | #3729 |
On 03/07/2011 01:00, Hugh Aguilar wrote: > On Jul 2, 1:28 am, Gerry Jackson<ge...@jackson9000.fsnet.co.uk> > wrote: >> On 01/07/2011 00:08, Hugh Aguilar wrote: >> [...] >> >> >> >>> I really wish that somebody would write a library of code in >>> competition with my novice package. You don't have to go up against >>> the entire thing --- you could just pick out one aspect, such as >>> arrays, lists or associative arrays, and write your own version. Would >>> that be so difficult? >> >> Do you have a memory problem are are you just disingenuous? You've been >> told before about the Forth Foundation Library, and indeed have >> adversely commented on it. >> >> https://groups.google.com/group/comp.lang.forth/browse_frm/thread/e9d... >> >> The FFL has been in existence longer than your novice package and has >> far more functionality. If you think your novice package is better, and >> I don't know whether it is or not, the onus is on you to provide facts >> and figures proving so instead of just stating opinions and just >> ignoring its existence. >> >> -- >> Gerry > > Show me *any* application program that has been written using FFL. Why on earth should I? I have little interest in the relative merits of FFL and the novice package and was just pointing out that your claim of no competing libraries was false and that you were well aware of the fact. > Or better yet, write one yourself! > > FFL isn't any good. It is extremely primitive in many ways --- I don't > think that it is suitable for use in application programming. It's a well known sales technique to promote a product by omitting any mention of competing products or rubbishing any such products without evidence. You've used both tactics. A better sales technique is to recognise there are competitors and to present some evidence, for example an analysis showing why your product is superior whether by: - absence of bugs - superior functionality - better performance - ease of use ... I don't think that just shouting "it's rubbish" convinces anybody, particularly knowledgeable members of this group, indeed it is more likely to antagonise them. You've complained several times about nobody using your library. Trying to be helpful I would suggest: 1. Give it a better name than the novice package. It may be suitable for novices but calling it that makes it plain that it is *only* suitable for novices. Why should a seasoned Forther who already possesses his own library even look at yours? 2. Deposit it or a link in FLAG http://soton.mpeforth.com/flag/ so that its existence has a better chance of becoming known. 3. Provide evidence of why it is superior without rubbishing the opposition. 4. Provide comprehensive test programs using the Hayes tester, that prove your library is well tested. Others do e.g. David Williams (see http://www-personal.umich.edu/~williams/archive/forth/strings/index.html - incidentally there are quite a few library packages in ANS Forth on this site that you probably haven't considered) and Krishna Myneni. Again why should experienced Forthers use a library when there's little or no evidence that it's been well tested. 5. Write a small, easily understandable application where your library is beneficial. Your slide rule program is too large. Of course items 3, 4 (see **) and 5 take quite a bit of work which you may be unwilling to do, in which case you'll probably have to live with the indifference shown. I hope this helps. ** If such test programs are developed simulataneously with the library code I would argue that it both speeds development and you get the final test programs automatically for free. At least that is my experience. Also when you modify the library running a test suite provides confidence that nothing has been broken. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2011-07-04 20:57 -0700 |
| Message-ID | <96fb04bf-96ef-4d49-84a1-fa2e43de56d9@s33g2000prg.googlegroups.com> |
| In reply to | #3735 |
On Jul 3, 3:20 am, Gerry Jackson <ge...@jackson9000.fsnet.co.uk> wrote: > On 03/07/2011 01:00, Hugh Aguilar wrote: > > Show me *any* application program that has been written using FFL. > > Why on earth should I? I have little interest in the relative merits of > FFL and the novice package and was just pointing out that your claim of > no competing libraries was false and that you were well aware of the fact. > > > Or better yet, write one yourself! > > > FFL isn't any good. It is extremely primitive in many ways --- I don't > > think that it is suitable for use in application programming. I really doubt that anybody has ever used FFL for any application. Just the ugly naming convention alone precludes this. Also, FFL doesn't have any features. For example, the AVL-tree code doesn't provide a way for the programmer to in-order traverse the tree within a selected range. That is the whole point of using a tree rather than a hash table! The linked-list code doesn't provide a way to find the node prior to the node that you are looking for, which is necessary for sorting lists. There is no conversion between lists and arrays. With both the AVL-trees and the lists, there is no way to have nodes of different sizes, and be able to clone the entire data structure. FFL doesn't provide any way to have a mixture of nodes that are in the heap and in the dictionary, which is necessary for shifting some of the work over to compile-time (see how in my slide-rule program I generate some lists at compile-time to reduce the program's run time). FFL is so primitive that I wouldn't even consider using it in an application. My impression of FFL is that those were homework assignments (implement a linked list, implement an AVL tree, etc.), but that the authors never had any intention of their code actually being used in any application. They just implemented the data structure simplistically, and they were done --- they didn't provide any features that would allow the code to be useful. Who did write that stuff anyway? Were those Anton Ertl's students striving to get an A from Anton by proving that they could implement some data structure? Whoever the authors were, they definitely weren't application programmers. > It's a well known sales technique to promote a product by omitting any > mention of competing products or rubbishing any such products without > evidence. You've used both tactics. A better sales technique is to > recognise there are competitors and to present some evidence, for > example an analysis showing why your product is superior whether by: > - absence of bugs > - superior functionality > - better performance > - ease of use > ... > > I don't think that just shouting "it's rubbish" convinces anybody, > particularly knowledgeable members of this group, indeed it is more > likely to antagonise them. What "knowledgeable members of this group" are you referring to? If anybody is at all knowledgeable of my novice package and FFL (spent an hour perusing both), they are going to see for themselves which is superior. This obviously doesn't describe yourself, as you seem to know nothing of either package. This doesn't describe anybody that I know of. > You've complained several times about nobody using your library. Trying > to be helpful I would suggest: > > 1. Give it a better name than the novice package. It may be suitable for > novices but calling it that makes it plain that it is *only* suitable > for novices. Why should a seasoned Forther who already possesses his own > library even look at yours? I don't think that calling it the "expert package" is going to make it more suitable to "seasoned Forthers." If they can't learn how a novice package works, then they aren't going to learn how an expert package works. > 2. Deposit it or a link in FLAGhttp://soton.mpeforth.com/flag/so that > its existence has a better chance of becoming known. It seems very unlikely that Stephen Pelc would allow that --- that is about as likely as www.forth.com providing a link. lol In my novice package I have a lot of work-arounds for problems in ANS- Forth. For example, I rewrote ALLOCATE and friends so that I could have ALLOCATION. Obviously, members of the Forth-200x committee (including Stephen Pelc) aren't going to support my novice package, because doing so would be a tacit admission that ANS-Forth has problems. Leon Wagner has stated that ALLOCATION is worthless, and that damns the entire novice package along with it. I put my novice package on www.forth.org because that is one place that the Forth-200x members don't have enough authority to order that it be deleted. > 3. Provide evidence of why it is superior without rubbishing the opposition. I didn't "rubbish" the opposition (is that even a verb?) --- the authors of FFL inflicted rubbish on the world under the grandiose name "Forth Foundation Library." I spent an hour or so browsing through the FFL and I found nothing of value in there. This was after I had written my novice package, but if I had known about FFL prior to writing my novice package I would have still written it just the way that I did --- I don't really concern myself with other people's code, as I feel confident that I can always do a better job myself. > 4. Provide comprehensive test programs using the Hayes tester, that > prove your library is well tested. Others do e.g. David Williams (seehttp://www-personal.umich.edu/~williams/archive/forth/strings/index.html > - incidentally there are quite a few library packages in ANS Forth on > this site that you probably haven't considered) and Krishna Myneni. > Again why should experienced Forthers use a library when there's little > or no evidence that it's been well tested. I don't know what a "Hayes tester" is. The only evidence I have that my novice package has been well tested is that I wrote a lot of application code, including the slide-rule program, using the novice package and that software worked. As I have said, I have never heard of anybody writing any application program using FFL, and I doubt that it could be done anyway --- so FFL has never been tested in the crucible of application-writing. > 5. Write a small, easily understandable application where your library > is beneficial. Your slide rule program is too large. > > Of course items 3, 4 (see **) and 5 take quite a bit of work which you > may be unwilling to do, in which case you'll probably have to live with > the indifference shown. I find it amazing that you say my slide-rule program is too large, and then immediately you say that I am unwilling to do the "quite a bit of work" involved in writing a small program. Are small programs more difficult than big programs? You are essentially accusing me of being lazy, because I don't take the time to spoon-feed you. Actually, most of my novice package is oriented toward writing large programs. For example, I have ALLOCATION provided, as well as CLONE- LIST and COPY-ASSOCIATION that use it. These are for situations in which the data structure contains nodes of different types (parent and child types typically). This obviously only becomes an issue in large programs that have inheritance of data types. For the most part, applications that need data-structure support are fairly large, in that they are working with a lot of data of more than one type. Small programs tend to also be simple programs. There is a lot in the novice package that can even be used by small programs though. For example, I have <SPLIT> that breaks a string apart on delimiters, building a list. One guy used <SPLIT> to break apart file names on the / character. His program was presumably quite small, although I never looked at it. <SPLIT> could be used for working with comma-delimited sequential files, which are a pretty common database-dump format. Such programs tend to be small --- I used to write programs like that every day when I was working as an IBM370 assembly-language programmer. I had a personal library of functions and macros, including something similar to <SPLIT>, that allowed me to write small programs in an hour or two. I could write assembly- language programs significantly faster than other people could write HHL programs, primarily because I had macros (and macros are the one thing that no HHL language other than Forth and Lisp allow). > I hope this helps. It didn't. You are pretty much in the same category as John Passaniti in the sense that you are talking at length about a subject that you know nothing about. On the plus side though, you didn't say that my novice package "sucks," so that does put you a step above Passaniti. If you would actually spend an hour looking at my package before commenting on it, that would put you leagues above anybody that I know. I spent that much time looking at FFL before I commented on it. Try looking at LIST.4TH as that one is pretty simple --- linked lists are possibly the simplest data-structure in existence, but also the most useful (the Lispers think so, anyway). > ** If such test programs are developed simulataneously with the library > code I would argue that it both speeds development and you get the final > test programs automatically for free. At least that is my experience. > Also when you modify the library running a test suite provides > confidence that nothing has been broken. I'm aware of the concept of Agile development. I don't think that test suites are all that useful for code such as a library that gets written once and isn't changed again --- that is more for applications that are in continual flux, especially when multiple programmers are all working on the application.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2011-07-06 15:45 +0100 |
| Message-ID | <iv1sef$d6$1@dont-email.me> |
| In reply to | #3793 |
On 05/07/2011 04:57, Hugh Aguilar wrote:
> On Jul 3, 3:20 am, Gerry Jackson<ge...@jackson9000.fsnet.co.uk>
> wrote:
>> On 03/07/2011 01:00, Hugh Aguilar wrote:
>>> Show me *any* application program that has been written using FFL.
>>
>> Why on earth should I? I have little interest in the relative merits of
>> FFL and the novice package and was just pointing out that your claim of
>> no competing libraries was false and that you were well aware of the fact.
>>
>>> Or better yet, write one yourself!
>>
>>> FFL isn't any good. It is extremely primitive in many ways --- I don't
>>> think that it is suitable for use in application programming.
>
> I really doubt that anybody has ever used FFL for any application.
> Just the ugly naming convention alone precludes this. Also, FFL
> doesn't have any features. For example, the AVL-tree code doesn't
> provide a way for the programmer to in-order traverse the tree within
> a selected range. That is the whole point of using a tree rather than
> a hash table! The linked-list code doesn't provide a way to find the
> node prior to the node that you are looking for, which is necessary
> for sorting lists. There is no conversion between lists and arrays.
> With both the AVL-trees and the lists, there is no way to have nodes
> of different sizes, and be able to clone the entire data structure.
> FFL doesn't provide any way to have a mixture of nodes that are in the
> heap and in the dictionary, which is necessary for shifting some of
> the work over to compile-time (see how in my slide-rule program I
> generate some lists at compile-time to reduce the program's run time).
The novice package lacks a lot more functionality than that, the list is
too long to give here, see http://code.google.com/p/ffl/ to identify
what's missing.
>
> FFL is so primitive that I wouldn't even consider using it in an
> application. My impression of FFL is that those were homework
> assignments (implement a linked list, implement an AVL tree, etc.),
> but that the authors never had any intention of their code actually
> being used in any application. They just implemented the data
> structure simplistically, and they were done --- they didn't provide
> any features that would allow the code to be useful. Who did write
> that stuff anyway? Were those Anton Ertl's students striving to get an
> A from Anton by proving that they could implement some data structure?
> Whoever the authors were, they definitely weren't application
> programmers.
The link above states who the author is. If he's reading these posts
that's probably yet another enemy you've made.
>
>> It's a well known sales technique to promote a product by omitting any
>> mention of competing products or rubbishing any such products without
>> evidence. You've used both tactics. A better sales technique is to
>> recognise there are competitors and to present some evidence, for
>> example an analysis showing why your product is superior whether by:
>> - absence of bugs
>> - superior functionality
>> - better performance
>> - ease of use
>> ...
>>
>> I don't think that just shouting "it's rubbish" convinces anybody,
>> particularly knowledgeable members of this group, indeed it is more
>> likely to antagonise them.
>
> What "knowledgeable members of this group" are you referring to? If
> anybody is at all knowledgeable of my novice package and FFL (spent an
> hour perusing both), they are going to see for themselves which is
> superior. This obviously doesn't describe yourself, as you seem to
> know nothing of either package. This doesn't describe anybody that I
> know of.
I was using knowledgeable in the general Forth/computing/programming
sense, not a detailed knowledge of the two libraries.
>
>> You've complained several times about nobody using your library. Trying
>> to be helpful I would suggest:
>>
>> 1. Give it a better name than the novice package. It may be suitable for
>> novices but calling it that makes it plain that it is *only* suitable
>> for novices. Why should a seasoned Forther who already possesses his own
>> library even look at yours?
>
> I don't think that calling it the "expert package" is going to make it
> more suitable to "seasoned Forthers." If they can't learn how a novice
> package works, then they aren't going to learn how an expert package
> works.
If they are not novices why should they even look at a package called
'the novice package'? Calling it an 'expert package' would be just as
silly - why classify a library according to the expertise of users?
>
>> 2. Deposit it or a link in FLAGhttp://soton.mpeforth.com/flag/so that
>> its existence has a better chance of becoming known.
>
> It seems very unlikely that Stephen Pelc would allow that --- that is
> about as likely as www.forth.com providing a link. lol
You don't know unless you try, if it was rejected you could legitimately
complain about a 'Forth establishment' which I don't think actually
exists, other than in your imagination. Could it be that you're afraid
to try?
>
> In my novice package I have a lot of work-arounds for problems in ANS-
> Forth. For example, I rewrote ALLOCATE and friends so that I could
> have ALLOCATION. Obviously, members of the Forth-200x committee
> (including Stephen Pelc) aren't going to support my novice package,
> because doing so would be a tacit admission that ANS-Forth has
> problems.
I think everybody is aware that ANS Forth has some problems e.g. see the
discussion about FIND elsewhere. I don't think there is a formal Forth
200X committee, anyone can comment and vote on proposals for change,
AFAIK anyone can attend Forth200X meetings and vote.
> Leon Wagner has stated that ALLOCATION is worthless, and
> that damns the entire novice package along with it.
>
> I put my novice package on www.forth.org because that is one place
> that the Forth-200x members don't have enough authority to order that
> it be deleted.
>
>> 3. Provide evidence of why it is superior without rubbishing the opposition.
>
> I didn't "rubbish" the opposition
Yes you did, both your previous post and earlier in this post.
> (is that even a verb?)
I've heard it used as such many times, it is commonplace in English for
nouns to be used as verbs e.g. google
> the
> authors of FFL inflicted rubbish on the world under the grandiose name
> "Forth Foundation Library." I spent an hour or so browsing through the
> FFL and I found nothing of value in there. This was after I had
> written my novice package, but if I had known about FFL prior to
> writing my novice package I would have still written it just the way
> that I did --- I don't really concern myself with other people's code,
> as I feel confident that I can always do a better job myself.
IMO that's an arrogant attitude to have.
>
>> 4. Provide comprehensive test programs using the Hayes tester, that
>> prove your library is well tested. Others do e.g. David Williams (seehttp://www-personal.umich.edu/~williams/archive/forth/strings/index.html
>> - incidentally there are quite a few library packages in ANS Forth on
>> this site that you probably haven't considered) and Krishna Myneni.
>> Again why should experienced Forthers use a library when there's little
>> or no evidence that it's been well tested.
>
> I don't know what a "Hayes tester" is.
There have been many references to it in comp.lang.forth, see
http://www.forth200x.org/tests/ttester.fs
It enables you to run code and compare expected results against actual
results.
>
> The only evidence I have that my novice package has been well tested
> is that I wrote a lot of application code, including the slide-rule
> program, using the novice package and that software worked.
Unfortunately, in general, running one application doesn't adequately
test a library. Neither does a test program but it comes a lot closer.
Does your slide rule program use *every* bit of code in the novice package?
> As I have
> said, I have never heard of anybody writing any application program
> using FFL, and I doubt that it could be done anyway --- so FFL has
> never been tested in the crucible of application-writing.
I see - if you haven't heard of something it has never happened.
>
>> 5. Write a small, easily understandable application where your library
>> is beneficial. Your slide rule program is too large.
>>
>> Of course items 3, 4 (see **) and 5 take quite a bit of work which you
>> may be unwilling to do, in which case you'll probably have to live with
>> the indifference shown.
>
> I find it amazing that you say my slide-rule program is too large, and
> then immediately you say that I am unwilling to do the "quite a bit of
> work" involved in writing a small program. Are small programs more
> difficult than big programs? You are essentially accusing me of being
> lazy, because I don't take the time to spoon-feed you.
Incredible - I write "may be unwilling to do" and you translate that
into an accusation of laziness. That doesn't make sense.
>
[...]
>
>> I hope this helps.
>
> It didn't. You are pretty much in the same category as John Passaniti
> in the sense that you are talking at length about a subject that you
> know nothing about.
I don't think he said that about your novice package, IIRC he said that
about the algorithm in your symtab module and proved it with a detailed
analysis and experimental results which you've never disputed. The code
itself may be of excellent quality but that doesn't make a poor choice
of algorithm anything but a poor choice of algorithm.
> On the plus side though, you didn't say that my
> novice package "sucks," so that does put you a step above Passaniti.
Wow, praise indeed!
> If you would actually spend an hour looking at my package before
> commenting on it, that would put you leagues above anybody that I
> know.
OK I've done that and will comment below.
> I spent that much time looking at FFL before I commented on it.
> Try looking at LIST.4TH as that one is pretty simple --- linked lists
> are possibly the simplest data-structure in existence,
A list is simpler than an array or structure? I don't think so.
> but also the
> most useful (the Lispers think so, anyway).
>
>> ** If such test programs are developed simulataneously with the library
>> code I would argue that it both speeds development and you get the final
>> test programs automatically for free. At least that is my experience.
>> Also when you modify the library running a test suite provides
>> confidence that nothing has been broken.
>
> I'm aware of the concept of Agile development. I don't think that test
> suites are all that useful for code such as a library that gets
> written once and isn't changed again
So you never change any code in the novice package - I don't believe
that is true. You miss some important points of having a decent test
program e.g.
- it would enable you to test the package on different ANS Forth
systems, which would increase confidence that the package was actually
ANS Forth compliant rather than it just being your opinion based on
running it on 1 system
- it would enable you or others to run it on different hardware/software
platforms e.g. Mac, Linux etc
- it would enable people like me who have their own ANS Forth system to
check that the package works on my system without having to examine it
in detail first.
- if running the test fails in any of the above, a good test program
will indicate where the failure is.
> --- that is more for applications
> that are in continual flux, especially when multiple programmers are
> all working on the application.
It has that use too.
As I said I spent an hour looking at the novice package, which isn't
long enough to do justice to it. To comment on a couple of points, you
seem to dislike CREATE ... DOES> intensely and go to great lengths to
avoid it on the grounds that it is slower than in-line code (true) and
that only one action can be applied to a data structure using does>,
(again true) hence your :NAME family.
Taking the first point about in-line code, your definition of <FIELD> is:
: <field> ( offset -- ) \ run-time: struct-adr -- field-adr
?dup if >r
: state@, if, r@ lit, postpone lit+,
else, r@ lit+, then, ;,
immediate
rdrop
else
: ;, immediate \ the first field does nothing whatsoever
then ;
But, ignoring the state-smartedness issue and unless I'm missing
something, isn't this definition equivalent, compiles code in-line, is
shorter, simpler etc:
: <field> ( offset -- )
create immediate ,
does> @ ?dup
if state @
if postpone literal postpone +
else +
then
then
;
Incidentally why didn't you use the Forth 200X structure proposal that
has already been accepted?
On the second point to take one example, you have a word <1array> that
defines an array and 5 words to operate on it using :name and friends to
prefix/suffix substrings to the array name. (I've a lot of sympathy for
wanting a word like :name in the ANS Forth standard as I've wanted it
myself several times so that's OK). However your technique is not the
only way to bind several actions to a data structure. Look at
http://excamera.com/sphinx/article-forth-boundmethods.html#forthboundmethods
for another way, using CREATE...DOES> funnily enough. The actions
following DOES> can insert code in-line just as easily as your <1array>
definition so there should be no speed penalty.
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2011-07-06 16:19 -0700 |
| Message-ID | <38fcdb0a-58b0-427d-989d-936c233589b4@em7g2000vbb.googlegroups.com> |
| In reply to | #3837 |
On Jul 6, 8:45 am, Gerry Jackson <ge...@jackson9000.fsnet.co.uk> wrote: > On 05/07/2011 04:57, Hugh Aguilar wrote: > > I really doubt that anybody has ever used FFL for any application. > > Just the ugly naming convention alone precludes this. Also, FFL > > doesn't have any features. For example, the AVL-tree code doesn't > > provide a way for the programmer to in-order traverse the tree within > > a selected range. That is the whole point of using a tree rather than > > a hash table! The linked-list code doesn't provide a way to find the > > node prior to the node that you are looking for, which is necessary > > for sorting lists. There is no conversion between lists and arrays. > > With both the AVL-trees and the lists, there is no way to have nodes > > of different sizes, and be able to clone the entire data structure. > > FFL doesn't provide any way to have a mixture of nodes that are in the > > heap and in the dictionary, which is necessary for shifting some of > > the work over to compile-time (see how in my slide-rule program I > > generate some lists at compile-time to reduce the program's run time). > > The novice package lacks a lot more functionality than that, the list is > too long to give here, seehttp://code.google.com/p/ffl/to identify > what's missing. I have seen that list and I am aware that FFL has functionality such as XML and regex that my novice package lacks. I may add regex (or, more likely, a parsing-expression-grammar) in the next novice package upgrade. What I meant is that, for the functionality that does correspond between the two packages, mine is superior. If FFL can't even get a simple data-structure such as linked-lists to work properly, then I wouldn't expect them to get something more complicated such as XML or regex to work properly. > If they are not novices why should they even look at a package called > 'the novice package'? Calling it an 'expert package' would be just as > silly - why classify a library according to the expertise of users? I don't know what the big deal is about the name. I just gave it that name to indicate that I'm trying to help novices get started. I use the package myself though, so maybe I was an expert when I wrote it but a novice when I used it. Of course, Elizabeth Rather has stated that the novice package was "written by a novice" (yuk! yuk!). > > In my novice package I have a lot of work-arounds for problems in ANS- > > Forth. For example, I rewrote ALLOCATE and friends so that I could > > have ALLOCATION. Obviously, members of the Forth-200x committee > > (including Stephen Pelc) aren't going to support my novice package, > > because doing so would be a tacit admission that ANS-Forth has > > problems. > > I think everybody is aware that ANS Forth has some problems e.g. see the > discussion about FIND elsewhere. I don't think there is a formal Forth > 200X committee, anyone can comment and vote on proposals for change, > AFAIK anyone can attend Forth200X meetings and vote. Forth-200x is what Leon Wagner says it is; he has the final say. When I proposed SIZE (later renamed ALLOCATION), I was getting a lot of support, including from Anton Ertl. Then Leon Wagner killed it, and the whole matter died immediately. Not even Anton Ertl can buck Leon Wagner's decisions. Sure, anybody can comment and vote, but your comments aren't read (when Leon Wagner killed my RfD he said that it had nothing to do with linked lists, and yet the linked-list was the only example I had given, so it was obvious that he hadn't actually read the RfD before killing it.) As for voting, you can vote on anything that you want to, but your vote doesn't count at all. Last night I watched "Bury my Heart at Wounded Knee." In that movie Sitting Bull refused to go to the meetings. There was a lot of talk about how every Injun was equal and any man could stand up and speak at the meetings. Sitting Bull said: "If any man can speak, then let any man go in my place." The point that he was making, is that the decisions had already been made; the meeting was just a charade intended to give the people the illusion that they had debated the matter and that they had lost the debate, but there really was no way that they were going to get what they wanted. I've been attending meetings like this for a long time, starting with family meetings when I was five years old and continuing with work meetings as an adult --- it is just a charade --- people only go to those kind of meetings so that they can be suck-ups and tell the boss that whatever he thinks is also what they think. Of course, there are sometimes free doughnuts being given away, which is another reason to attend. In the days of Sitting Bull, there were free blankets being given away --- and just hope that the blankets hadn't been purposely infected with small-pox! > > The only evidence I have that my novice package has been well tested > > is that I wrote a lot of application code, including the slide-rule > > program, using the novice package and that software worked. > > Unfortunately, in general, running one application doesn't adequately > test a library. Neither does a test program but it comes a lot closer. > Does your slide rule program use *every* bit of code in the novice package? > > > As I have > > said, I have never heard of anybody writing any application program > > using FFL, and I doubt that it could be done anyway --- so FFL has > > never been tested in the crucible of application-writing. > > I see - if you haven't heard of something it has never happened. You haven't given me any example of FFL being used in an application program, so you don't know of any either! Everything in the novice package has been tested; there are no bugs. Not everything has been used in an application though. For example, when I wrote ASSOCIATION.4TH I intended to rewrite the slide-rule program to use associations rather than lists, but I never got around to doing that. Still though, I wrote my associations so that they could be used in applications. It was my intention to provide features and interface appropriate to application writing, and not to just implement the basic data-structure and stop there, without providing any real way to use it. > >> 5. Write a small, easily understandable application where your library > >> is beneficial. Your slide rule program is too large. Since you are such a fan of FFL, why don't you write a program that uses it? I will write a corresponding version using the novice package. Write something that uses linked lists. I think it is a good idea for a language to have a primary data-structure that is used by most every program, unless they have some particular need for something special. This idea was pioneered by Lisp with its lists. You do have data-structures such as self-balancing trees or hash tables available if you really need them, but you generally use the list as your first choice. Similarly, Lua has hash tables and Factor has "sequences," which you are expected to use as a first choice unless you have a pressing need for something else. When I wrote LIST.4TH, it was my intention that lists should become the primary data-structure for Forth. > >> I hope this helps. > > > It didn't. You are pretty much in the same category as John Passaniti > > in the sense that you are talking at length about a subject that you > > know nothing about. > > I don't think he said that about your novice package, IIRC he said that > about the algorithm in your symtab module and proved it with a detailed > analysis and experimental results which you've never disputed. The code > itself may be of excellent quality but that doesn't make a poor choice > of algorithm anything but a poor choice of algorithm. You use the word "prove" pretty loosely! The only argument against symtab seemed to be that it wasn't a hash table. I had my reasons for not using hash tables though. The good news with hash tables is that there are only two possible mistakes, which are to make the table too small or to make it too big. The bad news is that you always make at least one mistake, and you may make both mistakes (start out with it too small and then over-correct and make it too big.) If you make the table too small, then you have to "stop the world" and rebuild the entire table, which is time-consuming. If you make the table too big, then you waste a lot of memory. All in all, I think that hash tables are only appropriate when you have beaucoup memory and can just make the table significantly bigger than necessary so that you never have to rebuild, and to heck with the inefficient memory usage. Of course, modern desktop computers do have beaucoup memory, so the hash table is a reasonable choice most of the time. Languages such as Factor that are only going to be used on big 32-bit computers can just use the hash-table as a no-brainer. My symtab is more appropriate for mid-sized computers in which memory usage is more of an issue. So it is a little more complicated than just saying that symtab "sucks" and hash tables rule. > > On the plus side though, you didn't say that my > > I'm aware of the concept of Agile development. I don't think that test > > suites are all that useful for code such as a library that gets > > written once and isn't changed again > > So you never change any code in the novice package - I don't believe > that is true. You miss some important points of having a decent test > program e.g. > - it would enable you to test the package on different ANS Forth > systems, which would increase confidence that the package was actually > ANS Forth compliant rather than it just being your opinion based on > running it on 1 system I have tested it on SwiftForth, Gforth and Win32Forth --- that is 3, not 1. > - it would enable people like me who have their own ANS Forth system to > check that the package works on my system without having to examine it > in detail first. The big problem here is that the ANS-Forth standard is too vague. When you read the document, you notice the word "may" being used an awfully lot. It is wishy-washy. There are also a lot of parts that are just confusing, such as the definition of (LOCAL) not explicitly saying that the local gets initialized. There is no way to know if ANS-Forth software will run on a specific ANS-Forth system except extensive testing. It is easy to say that a test suite will catch all of these problems, but it is much more difficult to actually write such a test suite --- doing so requires knowledge of the internal workings of Forth to know where the possible problems will arise --- which I'm marginal at, as my only compiler-writing experience was in Forth-83 rather than ANS-Forth. Upgrading the novice package so that it worked on Gforth and not just SwiftForth, was a pretty big step for me. Upgrading to work on Win32Forth was easier, as the only issues I ran into were that Win32Forth supports fewer locals (which is why I commented out <5ARRAY> and <6ARRAY>) and that there was a bug in FEXPM1 (which I provided a patch for, thanks to George Hubert). I have no idea if my novice package will run on your ANS-Forth system or not. Provide a link to your system and I will test it when I have time. I know that my novice package doesn't run on FICL, which is supposed to be ANS-Forth, but that is due to myriad problems in FICL. I asked John Sadler to fix the problems, but he said that I should do this myself and then submit the new version of FICL to him, so I just ignore FICL until I have some reason to specifically support FICL (there is a lot of C programming required to get FICL to support the novice package, and I don't have much interest in C programming). > Incidentally why didn't you use the Forth 200X structure proposal that > has already been accepted? That structure proposal was introduced by David Williams after my novice package was released, and he said that it was inspired by my novice package: http://groups.google.com/group/comp.lang.forth/browse_thread/thread/d90c532cae6410f7 For reasons unknown, he changed the name from FIELD to +FIELD --- but I think the former is more readable and more common, so I am sticking with it. I don't really care if my code or his is used, as the result is the same either way --- his is shorter, but whether it is simpler or not is debatable. > On the second point to take one example, you have a word <1array> that > defines an array and 5 words to operate on it using :name and friends to > prefix/suffix substrings to the array name. (I've a lot of sympathy for > wanting a word like :name in the ANS Forth standard as I've wanted it > myself several times so that's OK). However your technique is not the > only way to bind several actions to a data structure. Look athttp://excamera.com/sphinx/article-forth-boundmethods.html#forthbound... > for another way, using CREATE...DOES> funnily enough. The actions > following DOES> can insert code in-line just as easily as your <1array> > definition so there should be no speed penalty. I have more than one way to implement arrays. I have my <1ARRAY> etc., and I also have <ARY> which is more robust in that we have only a single word no matter how many dimensions are in the array, rather than have a distinct word for each number of dimensions (on the downside, <ARY> uses more memory and it may be slightly slower). I really consider CREATE DOES> to be a horrible and ugly construct, and I just don't use it. Since you seem to like it, why don't you write something similar to my ARY that is based upon the CREATE DOES> definer? You'll notice that the common note throughout this post is that I don't much like being criticized for not having done work, which nobody else has done either. I put a lot of time and effort into writing the novice package, so I'm not interested in hearing people tell me that I should put in more time and effort --- maybe I will, but I would be a lot more inclined to do so if somebody were to say something positive about what I've already done (it can't all suck!). The internet is full of people who will tell others that their work sucks, but there is a definite shortage of people who are willing to put forth any time and effort of their own. I'm really thinking about jumping to another language where the people aren't so mean. Even the Lisp community, which is notoriously nasty, is a step up from the Forth community (mostly because there aren't any commercial Lisp systems being pushed by salespeople, as we have SwiftForth being pushed by Elizabeth Rather, so there is no big muckety-muck for the trolls to flock around).
[toc] | [prev] | [next] | [standalone]
| From | Josh Grams <josh@qualdan.com> |
|---|---|
| Date | 2011-07-07 01:23 +0000 |
| Message-ID | <4e150a94$0$29769$a8266bb1@newsreader.readnews.com> |
| In reply to | #3843 |
Hugh Aguilar wrote: > On Jul 6, 8:45?am, Gerry Jackson <ge...@jackson9000.fsnet.co.uk> > wrote: >> On 05/07/2011 04:57, Hugh Aguilar wrote: > If FFL can't even get a simple data-structure such as linked-lists to > work properly The FFL's linked lists have worked properly every time I have used them. What specifically is wrong with them? >>> You are pretty much in the same category as John Passaniti in the >>> sense that you are talking at length about a subject that you know >>> nothing about. >> >> I don't think he said that about your novice package, IIRC he said >> that about the algorithm in your symtab module and proved it with a >> detailed analysis and experimental results which you've never >> disputed. The code itself may be of excellent quality but that >> doesn't make a poor choice of algorithm anything but a poor choice of >> algorithm. > > You use the word "prove" pretty loosely! The only argument against > symtab seemed to be that it wasn't a hash table. The argument against symtab was that, given a sequence of definitions and lookups taken from real codebases (including the source to your novice package, IIRC), it performed measurably worse than other algorithms, including some simple hash tables. > big.) If you make the table too small, then you have to "stop the > world" and rebuild the entire table, which is time-consuming. People pointed out hash table algorithms for which this is not true. > There is no way to know if ANS-Forth software will run on a specific > ANS-Forth system except extensive testing. It is easy to say that a > test suite will catch all of these problems, but it is much more > difficult to actually write such a test suite --- doing so requires > knowledge of the internal workings of Forth to know where the possible > problems will arise --- which I'm marginal at, as my only > compiler-writing experience was in Forth-83 rather than ANS-Forth. You don't need knowledge of the Forth system, you just have to check whether your code returns the expected results for a reasonable subset of the possible inputs -- check all the paths through your code, check the boundary conditions, and a few random checks of other values. If a Forth system does something unexpected that causes your code to misbehave, this will usually catch it. And if a Forth system does something unexpected that doesn't cause your code to misbehave, you don't need to care about it. >> Incidentally why didn't you use the Forth 200X structure proposal >> that has already been accepted? > > That structure proposal was introduced by David Williams after my > novice package was released, and he said that it was inspired by my > novice package: > http://groups.google.com/group/comp.lang.forth/browse_thread/thread/d90c532cae6410f7 > For reasons unknown, he changed the name from FIELD to +FIELD He "changed the name" because that is the syntax in the Forth200x structure proposal, which was introduced long before your novice package was released -- I'm too lazy to look up exactly when it was introduced, but it was accepted into the standard at the 2007 meeting. It was the optimization that was inspired by your novice package, not the idea of implementing data structures or the syntax. --Josh
[toc] | [prev] | [next] | [standalone]
| From | "David N. Williams" <williams@umich.edu> |
|---|---|
| Date | 2011-07-06 21:44 -0400 |
| Message-ID | <iv331j$k9e$2@dont-email.me> |
| In reply to | #3844 |
On 7/6/11 9:23 PM, Josh Grams wrote: > [...] > He "changed the name" because that is the syntax in the Forth200x > structure proposal, which was introduced long before your novice package > was released -- I'm too lazy to look up exactly when it was introduced, > but it was accepted into the standard at the 2007 meeting. > > It was the optimization that was inspired by your novice package, not > the idea of implementing data structures or the syntax. Thanks, Josh. I saw this just as I finished my reply, but decided to post it anyway. -- David
[toc] | [prev] | [next] | [standalone]
Page 2 of 17 — ← Prev page 1 [2] 3 4 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web