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 310 — 43 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 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 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 "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: 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 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 6 of 16 — ← Prev page 1 … 4 5 [6] 7 8 … 16 Next page →
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-08-12 01:39 -0700 |
| Message-ID | <173632d3-9113-4448-806f-8687385f2503@b19g2000yqj.googlegroups.com> |
| In reply to | #4753 |
On Aug 12, 2:50 am, Keith H Duggar <dug...@alum.mit.edu> wrote: > On Aug 11, 11:13 am, Alex McDonald <b...@rivadpm.com> wrote: > > > > > > > > > > > On Aug 11, 3:37 pm, Keith H Duggar <dug...@alum.mit.edu> wrote: > > > On Aug 11, 6:05 am, Alex McDonald <b...@rivadpm.com> wrote: > > > > On Aug 11, 2:01 am, Keith H Duggar <dug...@alum.mit.edu> wrote: > > > > > On Aug 10, 1:08¬†pm, "Elizabeth D. Rather" <erat...@forth.com> wrote: > > > > > > On 8/8/11 1:00 PM, Keith H Duggar wrote: > > > > > > > On Jun 28, 3:29 am, Elizabeth D Rather<erat...@forth.com> ¬†wrote: > > > > > > >> 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. > > > > > > > > That claim is also a myth; and, it has been debunked on numerous > > > > > > > occasions in various debates between various obscure superiority > > > > > > > complex communities (Forth, Lisp, Lisp Machine, etc) and the more > > > > > > > pragmatic thriving communities (C, Lua, Unix, etc). > > > > > > > > The myth is trotted out, along with various pejorative phrases such > > > > > > > as "Worse Is Better", by those communities to make themselves feel > > > > > > > better about themselves. > > > > > > > > Fact is many technologies die with vast marketing behind them and > > > > > > > many thrive and gain popularity with no "substantial, dedicated, and > > > > > > > well-funded marketing." Fact is that survival is highly informative > > > > > > > and should be rationally and seriously considered when objectively > > > > > > > evaluating a technology's overall fitness aka "better"ness. > > > > > > > > Dismissing survival and/or celebrating decay with the same tired > > > > > > > old "marketing" excuse is ... lol ... well lame. But, I'm sure > > > > > > > it makes you /feel/ better at least. > > > > > > > To be sure, no amount of marketing can guarantee the success of > > > > > > something that nobody wants. The really successful products have at > > > > > > That was only one direction of my claim. I also claim it is > > > > > not /necessary/ to have "substantial, dedicated, and well- > > > > > funded marketing" in contradiction to your claim that it is. > > > > > > > least a minimum level of technological soundness (not even Microsoft > > > > > > could sell Vista, smart cards, and a few other duds), but even a > > > > > > Vista ... hehe yeah that was a funny one. > > > > > > > technically excellent product will fail if not enough people know about > > > > > > it and its outstanding qualities. > > > > > > Fortunately it does not /necessarily/ require "substantial, > > > > > dedicated, and well-funded marketing" to garner enough users > > > > > for success. There are numerous examples of this in software > > > > > and technology products. > > > > > > To put it more simply. Just because a product that /you think/ > > > > > is "better" fails, does not imply it failed because it lacked > > > > > marketing. You may simply be /wrong/ and the product is not, > > > > > in fact, "better" in totality. > > > > > > KHD > > > > > I'm afraid that in the real world you will find that > > > > nothing beats marketing. Except more marketing. > > > > Asserting a falsehood multiple times does not make it > > > more true. P[A & A] = P[A]. The facts contradict your > > > hyperbolic claim. > > > Examples please. > > It's readily apparent form your comments regarding Linux that there > are No True Scotsman in your comfortable delusion. > > > > > I don't accept the "but Linux and other FOSS had no > > > > marketing!" argument. > > > > Of course you don't accept facts. That is the first > > > requirement of living in a delusion. > > > Please substantiate the facts with evidence. > > There are No True Scotsman for you. You will imagine phantasy labor > and "marketing" at every corner despite any evidence to the contrary. > > > > > It did. A huge army of volunteer marketeers; unpaid, > > > > yes, but substantial in number and fanatically dedicated. > > > > So even if your claim was stipulated, you agree that > > > they were not "well-funded" which contradicts Rather's > > > claim. Furthermore, Forth clearly demonstrates that > > > having "fanatically dedicated" fans is not sufficient. > > > Something about the product itself plays a role. The > > > sooner obscure communities accept that, the sooner > > > they can advance their product. > > > Hair splitting. Since labour (paid or otherwise)=money, and > > Linux had lots of unpaid labour, where's the difference? > > There difference appears to be that there are No True Scotsman. > > > And why would this "obscure community" of Forthers feel the need to > > "advance their product"? A motive is required. What is it? So is a > > product. What is it? > > What does motive have to do with capability? What does current > Forth motivation have to do with excusing past failure? Nothing ... > > > > > > > >> superiority will win if and only if there is a substantial, dedicated, > > > > > > >> and well-funded marketing campaign behind it. > > > > And it definitely wasn't a better OS technology > > > > in the early days. > > > > Just as a baby is not a "better" human in the early days? > > > Anthropomorphising this argument is silly. Software has no > > predetermined growth pattern, and it may or may not have utility > > (in the economic sense). Babies don't qualify. > > Babies do not have predetermined paths. That much should be obvious > to anyone. Some babies ultimately are productive to society and some > are anti-productive. What makes them analogous to a new product is > the anticipation, the prediction of success by supporters. > > > > Users ie markets often /anticipate/. Survival is a crucial > > > statistic regardless of how vehemently "smart know better > > > than you" fanatics dismiss it. > > > Markets buy stuff. Appealing to "anticipatory users" (aka tyre kickers > > in my business) doesn't get the bills paid. I'm not dismissing your > > argument out of hand, but you really need to provide evidence that you > > have a case in point, and I haven't seen any. > > There are No True Scotsman for you. > > > > Of course, I know it makes you /feel/ better to ignore the cold > > > facts. People always want to feel better about themselves and > > > the choices they've made. > > > Suit yourself. I note your "facts" appear to be missing. > > There are No True Scotsman for you. Trying to help you see them > would be nothing but a dreary and futile exercise. > > > I've been through this process several times during my 35 years in the > > software industry, and the better product doesn't necessarily win. > > Better marketing does. I can provide you with proof points should you > > need them. > > I did not claim the better product wins. Nor did I claim that > marketing cannot make a "bad" product commercially successful. > What I claimed is that "a substantial, dedicated, and well-funded > marketing" is not /necessary/ for the success of a good product. > > To repeat, EDR made the following /universal/ claim "technical > superiority will win if and only if there is a substantial, > dedicated, and well-funded marketing campaign behind it." I > dispute the "only if". It is nothing more than a lazy, tired, > lame, excuse for failure. > > KHD You win. I credit you with superior marketing.
[toc] | [prev] | [next] | [standalone]
| From | arc <arc@vorsicht-bissig.de> |
|---|---|
| Date | 2011-08-11 10:06 +0000 |
| Message-ID | <j209it$sg0$1@dont-email.me> |
| In reply to | #4649 |
Keith H Duggar wrote: > On Jun 28, 3:29 am, Elizabeth D Rather <erat...@forth.com> wrote: >> 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. > > That claim is also a myth; and, it has been debunked on numerous > occasions in various debates between various obscure superiority > complex communities (Forth, Lisp, Lisp Machine, etc) and the more > pragmatic thriving communities (C, Lua, Unix, etc). > > The myth is trotted out, along with various pejorative phrases such > as "Worse Is Better", by those communities to make themselves feel > better about themselves. > > Fact is many technologies die with vast marketing behind them and > many thrive and gain popularity with no "substantial, dedicated, and > well-funded marketing." Fact is that survival is highly informative > and should be rationally and seriously considered when objectively > evaluating a technology's overall fitness aka "better"ness. You're using a lot of evolutionary language here. Do you equate 'surviving and thriving' with ' "better"ness '? It sounds as if you do. If so, this isn't really a substantive debate, it's a terminological one. When you say 'C is better' you mean it's had greater uptake, or something like that. I'm sure even the most die-hard Forth enthusiast is aware that C has had more uptake, so when they say "Forth is better", they clearly don't mean that. They probably mean something like 'a skilled programmer with Forth delivers programs faster and with less defects' or 'Forth is more expressive than C' or something like that. Let's call claims of this sort 'intrinsic programming language virtues' or 'intrinsic virtues' for short. So you're saying C has more uptake, the Forther says Forth has greater intrinsic virtues - there's no disagreement here. We can all agree! Alternatively, you could mean that uptake always, or almost always, tracks intrinsic virtues. But you'd have to actually give an argument for that to be convincing, which would require discussing the intrinsic virtues of the technologys that haven't met with much uptake to show how they're usually not as good. I suspect you're hoping your evolutionary stance will mean you can avoid having that argument, but I'm afraid you can't avoid it that easily. > Dismissing survival and/or celebrating decay with the same tired > old "marketing" excuse is ... lol ... well lame. But, I'm sure > it makes you /feel/ better at least. > > KHD Keith - you're not one of those people who go around bursting people's balloons, are you? -arc
[toc] | [prev] | [next] | [standalone]
| From | Keith H Duggar <duggar@alum.mit.edu> |
|---|---|
| Date | 2011-08-11 08:02 -0700 |
| Message-ID | <669c0c74-e166-4a12-be5f-c9bf1687a0ea@c29g2000yqd.googlegroups.com> |
| In reply to | #4727 |
On Aug 11, 6:06 am, arc <a...@vorsicht-bissig.de> wrote: > Keith H Duggar wrote: > > On Jun 28, 3:29 am, Elizabeth D Rather <erat...@forth.com> wrote: > >> 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. > > > That claim is also a myth; and, it has been debunked on numerous > > occasions in various debates between various obscure superiority > > complex communities (Forth, Lisp, Lisp Machine, etc) and the more > > pragmatic thriving communities (C, Lua, Unix, etc). > > > The myth is trotted out, along with various pejorative phrases such > > as "Worse Is Better", by those communities to make themselves feel > > better about themselves. > > > Fact is many technologies die with vast marketing behind them and > > many thrive and gain popularity with no "substantial, dedicated, and > > well-funded marketing." Fact is that survival is highly informative > > and should be rationally and seriously considered when objectively > > evaluating a technology's overall fitness aka "better"ness. > > You're using a lot of evolutionary language here. Do you equate > 'surviving and thriving' with ' "better"ness '? It sounds as if you do. No. I am claiming survival is a crucial piece of evidence that must be rationally and carefully considered when evaluating the "intrinsic virtues" as you call them. That dismissing survival or lack of survival to marketing is a lame, lazy, tired, and irrational excuse. > If so, this isn't really a substantive debate, it's a terminological > one. When you say 'C is better' you mean it's had greater uptake, or > something like that. I'm sure even the most die-hard Forth enthusiast > is aware that C has had more uptake, so when they say "Forth is better", > they clearly don't mean that. They probably mean something like 'a > skilled programmer with Forth delivers programs faster and with less > defects' or 'Forth is more expressive than C' or something like that. > Let's call claims of this sort 'intrinsic programming language virtues' > or 'intrinsic virtues' for short. So you're saying C has more uptake, > the Forther says Forth has greater intrinsic virtues - there's no > disagreement here. We can all agree! I'm claiming that when a product /you think/ has better "intrinsic virtues" fails to thrive as well as a product /you think/ has worse "intrinsic virtue" a rational person would carefully re-evaluate their analysis of "intrinsic virtue". They would carefully consider 1) whether they failed to recognize virtues in the thriving product 2) whether they failed to recognize failures in the failing product 3) whether they inaccurately evaluated the value to the market of the virtues in the failing product etc ... > Alternatively, you could mean that uptake always, or almost always, > tracks intrinsic virtues. But you'd have to actually give an argument > for that to be convincing, which would require discussing the intrinsic > virtues of the technologys that haven't met with much uptake to show > how they're usually not as good. > > I suspect you're hoping your evolutionary stance will mean you can avoid > having that argument, but I'm afraid you can't avoid it that easily. The arguments have already been made numerous times before in many and various debates, flamewars, etc. There is absolutely not point whatever in having them again. I'm not trying to convince Forth users that "Lua is better" nor Lisp Machine fanatics that PCs were better etc. What I'm trying to convince them of, is that survival is a key piece of evidence and that chalking it up to "marketing" is 1) counter-factual 2) done at your own peril if you care about advancing a product 3) irrational. One can learn a great deal by rationally examining why a product is or is not thriving. Far more than a community members learn by stroking each other egos and making themselves /feel/ better by blaming marketing. > Keith - you're not one of those people who go around bursting > people's balloons, are you? If they are filled with mindless stale air, absolutely. KHD
[toc] | [prev] | [next] | [standalone]
| From | arc <arc@vorsicht-bissig.de> |
|---|---|
| Date | 2011-08-12 11:49 +0000 |
| Message-ID | <j233vo$v0t$1@dont-email.me> |
| In reply to | #4734 |
Keith H Duggar wrote: > On Aug 11, 6:06 am, arc <a...@vorsicht-bissig.de> wrote: >> Keith H Duggar wrote: >> > On Jun 28, 3:29 am, Elizabeth D Rather <erat...@forth.com> wrote: >> >> 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. >> >> > That claim is also a myth; and, it has been debunked on numerous >> > occasions in various debates between various obscure superiority >> > complex communities (Forth, Lisp, Lisp Machine, etc) and the more >> > pragmatic thriving communities (C, Lua, Unix, etc). >> >> > The myth is trotted out, along with various pejorative phrases such >> > as "Worse Is Better", by those communities to make themselves feel >> > better about themselves. >> >> > Fact is many technologies die with vast marketing behind them and >> > many thrive and gain popularity with no "substantial, dedicated, and >> > well-funded marketing." Fact is that survival is highly informative >> > and should be rationally and seriously considered when objectively >> > evaluating a technology's overall fitness aka "better"ness. >> >> You're using a lot of evolutionary language here. Do you equate >> 'surviving and thriving' with ' "better"ness '? It sounds as if you do. > > No. I am claiming survival is a crucial piece of evidence that > must be rationally and carefully considered when evaluating the > "intrinsic virtues" as you call them. That dismissing survival > or lack of survival to marketing is a lame, lazy, tired, and > irrational excuse. OK. So my second guess is correct, yes? I was mislead by your statement 'technology's overall fitness aka "better"ness' - I thought by 'fitness' you meant evolutionary fitness, which doesn't necessary track intrinsic virtue. > I'm claiming that when a product /you think/ has better "intrinsic > virtues" fails to thrive as well as a product /you think/ has worse > "intrinsic virtue" a rational person would carefully re-evaluate > their analysis of "intrinsic virtue". They would carefully consider > 1) whether they failed to recognize virtues in the thriving product > 2) whether they failed to recognize failures in the failing product > 3) whether they inaccurately evaluated the value to the market of > the virtues in the failing product etc ... OK. I suppose if your product has failed you might want to consider those things. But that doesn't rule out: 4) whether they failed to market the product appropriately. does it? After all, better marketing increases a product's fitness, surely. If it doesn't, you might want to go and explain to Apple and Microsoft (and every successful firm and politician on the planet) that they've wasted a huge stack of money over the years. I do agree with you (against Elizabeth) that marketing is not the only explanation for product failure. There are many more extrinsic factors that can contribute to a product's demise. We could also add: 5) whether the product is sufficiently similar to other products on the market to make transition easy. I'm no expert in Forth's history, but that could have a lot to say about it. C is quite similar to its immediate forbears, the incumbents of the day (such as FORTRAN), whereas Forth is a bit different. Also, 6) whether the successful product is strongly connected with other successful products in a way the unsuccessful product isn't. C was (and is) strongly connected to Unix, and there was a demand for a flexible, multi-platform, multi-user operating system at the time. There was a big incentive to learn C in order to work with Unix. AFAIK, there were no comparably successful products that required the use of Forth. Now, 4, 5, and 6 are plausible enough reasons for the difference in uptake of one product over another, aren't they? Do you have any reason to dismess these in favour of 1, 2 and 3? Notice, incidentally, what I am doing here: I have given a plausible account of how 5 and 6 may have contributed to Forth's lack of success, and I have invited you to provide reasons to show why this wouldn't be the case. You've not connected 1-3 with Forth specifically, or, indeed, with any product - you've only spoken in generalities. In fact, you've scarcely provided anything resembling an argument - instead, you've offered insults and you've banged the tired old 'products always succeed because they're just better!' drum, which has been repeated at least as often as 'we failed because of insufficient marketing', and equally fails at being reasoned analysis. (just for the record, I don't think Forth is necessarily better than C, and I don't especially care, either, so no need for the emphasized '/you think/'s.) >> Alternatively, you could mean that uptake always, or almost always, >> tracks intrinsic virtues. But you'd have to actually give an argument >> for that to be convincing, which would require discussing the intrinsic >> virtues of the technologys that haven't met with much uptake to show >> how they're usually not as good. >> >> I suspect you're hoping your evolutionary stance will mean you can avoid >> having that argument, but I'm afraid you can't avoid it that easily. > > The arguments have already been made numerous times before in > many and various debates, flamewars, etc. There is absolutely > not point whatever in having them again. > > I'm not trying to convince Forth users that "Lua is better" nor > Lisp Machine fanatics that PCs were better etc. What I'm trying > to convince them of, is that survival is a key piece of evidence > and that chalking it up to "marketing" is 1) counter-factual 2) > done at your own peril if you care about advancing a product 3) > irrational. One can learn a great deal by rationally examining > why a product is or is not thriving. > > Far more than a community members learn by stroking each other > egos and making themselves /feel/ better by blaming marketing. > >> Keith - you're not one of those people who go around bursting >> people's balloons, are you? > > If they are filled with mindless stale air, absolutely. Let me get this straight. You think Forth adherents are delusional people who don't accept facts, filled with mindless stale air, desperately clinging to their cherished belief that 'marketing' rather than technical flaws (again, it might help if you mentioned what you think these are) are the cause of the downfall of their language, the only thing left they have to make themselves '/feel/ better'. So what exactly do you think you're doing? There's no point in offering us a reasoned argument; because according to your assessment we won't recognise one when we see one, nor accept the outcome [1] , We might be swayed by appeals to emotion, I suppose, but insulting us probably isn't a good way to achieve that goal. I'm having difficulty making sense of your actions - it seems to me that you must be as mad as us, trying tactics that are sure to fail to achieve an outcome you believe is impossible. Either that, or you've just come down to poke the monkeys at the zoo. Or, is it that you too need to feel better about yourself and the choices that you've made? Strange that you should need to defend yourself to us, given that you've apparently backed winners. Explain yourself, sir. -arc [1] At any rate, Andrew, Alex and I are certainly having difficulty discerning much of an argument in your utterances.
[toc] | [prev] | [next] | [standalone]
| From | arc <arc@vorsicht-bissig.de> |
|---|---|
| Date | 2011-08-12 13:18 +0000 |
| Message-ID | <j2397q$1kl$1@dont-email.me> |
| In reply to | #4772 |
Let's put this more simply. Given the fact that language X has been generally more successful in the marketplace than language Y, there are two possible classes of contributing factors: a) intrinsic factors about the languages in question - e.g. X produces more compact code than Y, X produces faster code than Y, equally comptent programmers will produce code with less defects in X than they will in Y, etc. b) extrinsic factors about the languages in question - e.g. marketing, connection with a product that's successful for largely independent reasons, being commonly taught in schools, etc. (there can be mixed cases; you refer to one such in your reply to me -- the value of intrinsic virtues to the market -- but let's leave those aside for now. ) Forthers claim that C's success over Forth is largely to do with extrinsic factors. (Let's drop the suggestion that it's just marketing: I agree Elizabeth is wrong about that being the only factor. Although it is the obvious one, and one that's more tractable than others.) You, Keith, seem to be making a very bold claim that in every case, or almost every case, of one computing technology outdoing another, it's always ultimately down to intrinsic factors - computing technology Y is intrinsically inferior to Y, and the market has recognised this, and therefore has opted for technology Y. You've also claimed that this case is so strong that anyone who doesn't recognise it is evidencing some kind of cognitive deficiency. (You've cleaverly weakend your claim to 'if you've been outcompeted, you might want to consider instrinsic factors' in your response to me, but that doesn't justify your condescension) But so far, you've not given any actual evidence for this. I think you'd need pretty strong evidence: plenty of cases, and clear examples of their intirinsic worseness than the ones that were successful. Frankly, i'm inclined to doubt the idea that the market always, or almost always, tracks intrinsic factors. Not because I'm a rabid fan of alternative technologies, but just because extrinsic factors seem quite plausible reasons for product uptake or lack thereof. The cases you've mentioned don't seem very clear cut at all to me. But maybe I'm wrong about this! Maybe it has been conclusively shown (as you state it has) in all those cases you mention (and more) that the products have failed to be taken up because they were intrinsically worse. Now's your chance, Keith, convince me - show me this conclusive evidence! I don't care that much about Forth - I'm pretty new to it. So don't be dissuaded by the thought of my irrational attachment to something I've sunk a lot of cost into. -arc.
[toc] | [prev] | [next] | [standalone]
| From | Nomen Nescio <nobody@dizum.com> |
|---|---|
| Date | 2011-08-12 18:49 +0200 |
| Message-ID | <b33b006671738cba452a8afd09750b55@dizum.com> |
| In reply to | #4775 |
> Forthers claim that C's success over Forth is largely to do with > extrinsic factors. I'm not a Forther. I know very little about it but it seems like a very interesting and useful system. But let's get right to the point, the success of C is based on: 1. C is a just-right combination of high level flow control and low level capabilities. It compiles to native code. I realize the same could be said of several Forth implementations but nobody who doesn't read this newsgroup knows that and C without typedef madness is somewhat readable at first glance while Forth is not. 2. C was used to write two of the world's most popular (I didn't say "best", I said "popular") operating systems, UNIX and Linux. People barely understand desktop, they don't get Forth's embedded capabilities. 3. C was pushed as a political movement (freedom for the masses) and had lots of support from vendors. People (improperly) idolized the UNIX crowd and wanted to be like them, so they copied whatever they did, often without question and almost always without thought. 4. Standards-conforming C compilers are available free from many sources. Forth needs a good BSD or freely licensed implementation. Many people won't touch GPL with a thousand meter pole. I realize this seems contradictory in light of what I wrote in (3) but those people aren't going to use Forth anyway. I might, but I won't use a GPL implementation out of principle. I don't need the source either, an executable-only or proprietary license is also fine. But it should be cheap/free or there isn't a chance when everything is expected to be given away. Unless I can make money with it I'm not going to buy a copy. Most people are writing hobby code, few of us actually write code for a living. When we do, our employers buy the tools. 5. People wrote tons of libraries including very important support libraries and graphical toolkits for UNIX and Linux based on C interface. I don't think there's a cross platform GUI toolkit for Forth. I don't know about what database interfaces there are either. A language might be great but if it doesn't talk to the outside world it's not very useful. I personally think C is ugly and I don't use it. I think C++ is uglier still, and I also don't use it. But I can't argue they offer a lot in their niche. I really don't care what's popular. I prefer assembler. I do think traditional marketing and the Microsoft kind do play heavily upon what is seen as "good" and "useful" and most "programmers" today really are nothing more than script kiddies or cut and paste "programmers". I am glad to see languages and thinking that breaks the mould. Forth does that. The direction in new languages seems to be scripting and I think Forth could be very useful for that.
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-08-12 12:52 -0700 |
| Message-ID | <79e0ddc3-6aaa-40eb-b5cb-d60a55f90a14@s7g2000yqk.googlegroups.com> |
| In reply to | #4781 |
On Aug 12, 12:49 pm, Nomen Nescio <nob...@dizum.com> wrote: > 1. C is a just-right combination of high level flow control > and low level capabilities. It compiles to native code. I > realize the same could be said of several Forth > implementations but nobody who doesn't read this newsgroup > knows that and C without typedef madness is somewhat > readable at first glance while Forth is not. I'm sure others will disagree, but in many applications (including some embedded systems) the ability of a language to generate native code is increasingly irrelevant. It *used* to be a critical point, but as microprocessors have gotten faster, it's becoming more common to use languages that don't compile down to native code (or that are JIT'ed to native code at run-time). Or put another way, the expressiveness and power of the language is mattering more than the raw speed of the code generated by the language. It has been reported that back in the early days of Forth-- before native code compilers even existed-- that Forth programmers were writing applications that beat the speed of compiled languages. There is no great mystery there-- by putting the effort into coding efficient algorithms, a slower language can beat a faster language. And the same is true of other languages today. Sometimes having access to a particularly clever data structure or abstraction can dramatically speed up a program on a slower language than simpler brute-force code on a faster language. I don't see the problem with Forth having anything to do with access to native code compilers. Many large scale systems these days are written in languages like Perl, Python, Lua, Ruby, and so on, and most of these languages don't have native code static or JIT compilers. What they do have are a rich set of data structures and abstractions that allow programmers to think about problems in a simpler way. Yeah, it may burn more CPU cycles, but as those cycles get faster and faster, it matters less and less. So the economics of programming changes; when you care less about how many CPU cycles are used and more about expressivity, your priorities shift towards using languages and tools that give you value for the cycles they use up. A good example of this is our digital audio signal processing systems at work. We are now at the point in terms of CPU speed that we have large periods of time when the CPU is essentially idle. So a natural question to ask is how we can make use of those unused CPU cycles to make programming our systems faster, more pleasant, and with higher degrees of reliability. And one answer is to move parts of the code to a higher-level language. We still have low-level code that is time- critical, but by moving the majority of the rest of the code to a higher-level language, we can work at a higher level of abstraction. > I am glad to see languages and thinking that breaks the mould. > Forth does that. The direction in new languages seems to be > scripting and I think Forth could be very useful for that. It could be, but many of the people in this newsgroup really don't understand that a key component of scripting languages is that they tend to be very high-level languages. And that's why nearly every scripting language has things like automatic memory management, implicit type conversions, duck typing, some notion of objects, rich string libraries, and data structures like efficient key/value stores. In order to compete as a scripting language, you would need a version of Forth that had high-level notions like typed values, polymorphic operators, lexical scoping, and so on. Anything less, and you're slogging it down at the machine level, and that's not scripting. And the real problem there? The Forth community. Spend any time in comp.lang.forth, and one of the things you'll see often is that when someone proposed an *optional* extension to Forth (like for objects), people treat the discussion as if someone wants to fundamentally change Forth to be object-based. The notion that something can be optional (and thus one doesn't need to use it) seems to elude some here. So in past conversation about scripting, there is always a contigent here who reject the idea because they don't get that a high- level language based on Forth would be an *optional* extension, with nobody holding a gun to anyone's head to use it.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-08-14 09:54 -0400 |
| Message-ID | <j28k2e$chv$1@speranza.aioe.org> |
| In reply to | #4792 |
"John Passaniti" <john.passaniti@gmail.com> wrote in message news:79e0ddc3-6aaa-40eb-b5cb-d60a55f90a14@s7g2000yqk.googlegroups.com... > > We are now at the point in terms of CPU speed that we have > large periods of time when the CPU is essentially idle. > What?!?! What that says to me is: "The CPUs we used in our products were underpowered for many years." That probably means the cpu was chosen first, then had software written for it. I.e., the software was too much, too big, too bloated, for the chosen cpu. The cpu should've been chosen *after* the software was written in order to ensure it could handle the software load. However, that would also mean that the code would need to be coded in a HLL since you'd need to test different microprocessor platforms. AIUI from someone in the industry, the automotive industry did much the same thing for decades with their engine choices. The body designers couldn't design a body without knowing how much weight the engine could pull. So, the engine designers had to chose an engine upfront. The body designers would design a body ... that was too heavy. Then, marketing would get involved. They'd ask the engine designers about the engine, who would respond that it's got a nice, big engine. By the various departments finished modifying the cars design, the engine would be underpowered by 50% or more. Eventually, after decades, the automotive companies learned to do things the other way around. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-08-14 12:53 -0700 |
| Message-ID | <f818cbaf-eceb-46ae-a427-8003a369eab4@en1g2000vbb.googlegroups.com> |
| In reply to | #4871 |
On Aug 14, 9:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> wrote: > > We are now at the point in terms of CPU speed that we have > > large periods of time when the CPU is essentially idle. > > What?!?! What that says to me is: > > "The CPUs we used in our products were underpowered for many years." > > That probably means the cpu was chosen first, then had software > written for it. I.e., the software was too much, too big, too > bloated, for the chosen cpu. The cpu should've been chosen > *after* the software was written in order to ensure it could > handle the software load. However, that would also mean that > the code would need to be coded in a HLL since you'd need to test > different microprocessor platforms. That's a bizarre interpretation of what I wrote, with your usual heapin' helpin' of assumption tossed in. The reality is that in the past, the microcontroller and software in our systems were designed for each other. They knew how large the software needed to be and how fast the CPU needed to be and chose exactly what was needed and nothing more. There was no waste. And that has the obvious appeal to system design minimalists, but it also places limits on what we're able to do in terms of new features to address market demands. But more importantly, what has changed is that as time goes forward, we're finding that it doesn't economic sense to continue with the same microcontroller and support hardware. For the exact same system cost or less, we can have a much faster, more capable, and more expandable system. To put numbers on it, we're currently running on microcontrollers that offer around 70 MIPS. For the same system cost or less, we can move to a microcontroller that offers roughly 475 MIPS. But that's not the whole story as the same system would have much more memory, allowing us to shift the usual time/space tradeoff from CPU-bound calculation to RAM/ROM-bound lookup tables. And in our application, that means the CPU will have to do even less. And so when we run the *same* software on that newer hardware, we find that we have much more idle time, much more RAM, and much more ROM. So the obvious question is how can we use those extra resources to our benefit. And one way we're looking to do that is to divide up the software into two major classes: the time-critical code (which will remain in C or C++) and the rest of the system (which we'll move to a higher-level language like Lua). Part of what motivates that is a recognition that a lower-level language (like C, C++, or Forth) is great when you need control and efficiency. But working at that level for the whole system doesn't make sense. Higher-level control, user interface, networking, and related software can get a real benefit from a higher-level language.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2011-08-14 13:21 -0700 |
| Message-ID | <279c83e5-f8f5-4d50-be49-3c147a2cf803@c29g2000yqd.googlegroups.com> |
| In reply to | #4896 |
On Aug 14, 8:53 pm, John Passaniti <john.passan...@gmail.com> wrote: > On Aug 14, 9:54 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm> > wrote: > > > > We are now at the point in terms of CPU speed that we have > > > large periods of time when the CPU is essentially idle. > > > What?!?! What that says to me is: > > > "The CPUs we used in our products were underpowered for many years." > > > That probably means the cpu was chosen first, then had software > > written for it. I.e., the software was too much, too big, too > > bloated, for the chosen cpu. The cpu should've been chosen > > *after* the software was written in order to ensure it could > > handle the software load. However, that would also mean that > > the code would need to be coded in a HLL since you'd need to test > > different microprocessor platforms. > > That's a bizarre interpretation of what I wrote, with your usual > heapin' helpin' of assumption tossed in. > > The reality is that in the past, the microcontroller and software in > our systems were designed for each other. They knew how large the > software needed to be and how fast the CPU needed to be and chose > exactly what was needed and nothing more. There was no waste. And > that has the obvious appeal to system design minimalists, but it also > places limits on what we're able to do in terms of new features to > address market demands. But more importantly, what has changed is > that as time goes forward, we're finding that it doesn't economic > sense to continue with the same microcontroller and support hardware. > For the exact same system cost or less, we can have a much faster, > more capable, and more expandable system. > > To put numbers on it, we're currently running on microcontrollers that > offer around 70 MIPS. For the same system cost or less, we can move > to a microcontroller that offers roughly 475 MIPS. But that's not the > whole story as the same system would have much more memory, allowing > us to shift the usual time/space tradeoff from CPU-bound calculation > to RAM/ROM-bound lookup tables. And in our application, that means > the CPU will have to do even less. > > And so when we run the *same* software on that newer hardware, we find > that we have much more idle time, much more RAM, and much more ROM. > So the obvious question is how can we use those extra resources to our > benefit. And one way we're looking to do that is to divide up the > software into two major classes: the time-critical code (which will > remain in C or C++) and the rest of the system (which we'll move to a > higher-level language like Lua). Right, so what you are essentially saying is that you will knowingly waste cycles by implementing parts of the software in a less efficient language, because you can. Or perhaps more accurately, you will implement in a less efficient language, with a view to using those spare cycles up. Bizzare. "So a natural question to ask is how we can make use of those unused CPU cycles to make programming our systems faster, more pleasant, and with higher degrees of reliability." Doesn't seem like a natural question to me. A natural question would be "Wow! Look at all this horsepower! How can we leverage this to offer more facilities to our customers, and put us ahead in the marketplace?". *That's* a natural question. Furthermore, how does moving to a high level language increase reliability? You surely know that using higher level languages just leaves you at the mercy of the bug list of the high level language you are using. At least with C, there's only the compiler between you and the hardware. Ever used .Net? Ever used one of those commercially available plugins for .Net that always turn out to be a buggy mess? .Net itself was quite buggy for years. Using a high level language does not simplify the "software problem" - it just moves the complexity somewhere else, normally where you can't see it, and have no control/influence over it. Sure, high level languages have their place, of course they do, but I would have thought a high level language in application such as yours, which is almost mission critical is not the place for it. Your kit has to "just work" - not fall over after 3 days use due to a memory leak!
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-08-14 15:09 -0700 |
| Message-ID | <232c7469-c9cd-47a6-8db3-a64232b7f69c@k3g2000vbz.googlegroups.com> |
| In reply to | #4898 |
On Aug 14, 4:21 pm, Mark Wills <markrobertwi...@yahoo.co.uk> wrote: > Right, so what you are essentially saying is that you will > knowingly waste cycles by implementing parts of the software > in a less efficient language, because you can. No, I am saying that we can use those cycles to provide value to the system. There is no waste. We can target those parts of the application that can benefit from a higher-level approach. The cycles used by the higher-level language allow us to write code at a higher level of abstraction. > "So a natural question to ask is how we can make use of those unused > CPU cycles to make programming our systems faster, more pleasant, and > with higher degrees of reliability." > > Doesn't seem like a natural question to me. A natural question would > be "Wow! Look at all this horsepower! How can we leverage this to > offer more facilities to our customers, and put us ahead in the > marketplace?". *That's* a natural question. And indeed that's exactly how we view it. The addition horsepower means many things. It means that because we can code at a higher level of abstraction and leverage a lot of the facilities and tools the language provides, we aren't spending as much time writing code. That puts us ahead in the marketplace in terms of time-to-market. It also allows us to bring new functionality that we never could before. One concrete example: One feature I've wanted to bring to our marketplace is the ability of system designers to script our products for specific applications. That's a feature that *nobody* is offering and it will give us a competitive edge. And that's a feature that directly leverages the extra cycles we'll have. > Furthermore, how does moving to a high level language increase > reliability? [...] By eliminating classes of errors common with low-level languages. By allowing us to write code at a higher level of abstraction. By letting us leverage facilities that exist in the higher-level language that we would have to code ourselves. By giving us new ways to think about our software. By doing for us the things we would do ourselves, and letting us focus on the problem, not the solution. You know, all the standard advantages of higher-level languages. > Sure, high level languages have their place, of course they do, > but I would have thought a high level language in application such > as yours, which is almost mission critical is not the place for > it. Your kit has to "just work" - not fall over after 3 days use > due to a memory leak! Ironic example, since one of the many motivations was a recent bug in low-level code that caused a memory leak. That particular bug wouldn't have happened in a higher-level language. All languages above assembly have some risk associated with them. In our systems, we manage that risk in a variety of ways. For example, our systems use software to protect the power transistors in our amplifiers from blowing up because they get too hot. We monitor the temperature, and consider the rate of change. With that information, our software takes various counter-measures to protect the system. We might start by kicking up the speed of the system's fans. If that doesn't work, we might start attenuating the input signal. And if that still doesn't work, we'll eventually shut down the channel. All in software. So what happens if the microprocessor has gone insane and is in an infinite loop? That's fine-- in addition to the software that tries to gracefully handle the thermal condition, there is also hardware that will take over to protect the system if the software fails to do so. This is a fundamental part of the design of our systems (and presumably, our competition). And it comes from the realization that software can fail. It doesn't matter if that software exists in the interpreter loop of a higher-level language, the statically compiled code generated by a C compiler, or hand-tweaked assembly code. Humans write software, and if you don't have a strategy to deal with the fact that humans make mistakes, then *that* is your problem, not choosing to leverage spare cycles with a higher-level language.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-08-15 04:52 -0400 |
| Message-ID | <j2amor$of1$1@speranza.aioe.org> |
| In reply to | #4900 |
"John Passaniti" <john.passaniti@gmail.com> wrote in message news:232c7469-c9cd-47a6-8db3-a64232b7f69c@k3g2000vbz.googlegroups.com... > > One feature I've wanted to bring to our > marketplace is the ability of system designers to script > our products for specific applications. That's a feature > that *nobody* is offering > and it will give us a competitive edge. > Put a USB port on it, if it doesn't have one already. Everything is on USB. Let Windows and Linux users plug a cable into it and upload, download, reconfigure or whatever... Better yet, let them do it with their laptops, tablets, smart phones, PDAs, or etc portable device. Your customers probably prefer to do their work from some such device(s) already, instead of using the knobs and buttons on the face of your product (assumptions...). Let them. If you've got an internal script or batch language built in, file system to save stuff, minimal OS either command line or GUI, better yet. I've seen interpreted, line-oriented, BASIC work exceptionally well as the "script language" on industrial machines. Today, you might some other language ... FYI, a bit over decade ago, I worked for a company whose "flagship" product was a 1U rack mount, preamp, DSP based audio effect processor for musicians. It had the knobs, the buttons, a 16 character display, a microcontroller, rotary encoders, various inputs and outputs, analog audio stages, as well as the DSP. They were also known for a noise reduction IC they developed with Analog Devices. They also produce audio amplifiers with and without tubes, preamplifiers, audio effects, etc. One of the many problems they had (IMO) was that their employees, in general, had either music industry (musicians) or audio engineering experience (TV, car amplifiers). While they had no issue interfacing their equipment to other audio products, attempting to get them to interface anything to a PC was really a "hard sell". Today, it seems some of their products are labeled "online", although they still upload/download data via midi only (on your PC's soundcard gameport), not by USB or Ethernet. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-08-15 03:46 -0400 |
| Message-ID | <j2ait3$fk9$1@speranza.aioe.org> |
| In reply to | #4896 |
"John Passaniti" <john.passaniti@gmail.com> wrote in message news:f818cbaf-eceb-46ae-a427-8003a369eab4@en1g2000vbb.googlegroups.com... > > To put numbers on it, we're currently running on microcontrollers that > offer around 70 MIPS. For the same system cost or less, we can move > to a microcontroller that offers roughly 475 MIPS. But that's not the > whole story as the same system would have much more memory, allowing > us to shift the usual time/space tradeoff from CPU-bound calculation > to RAM/ROM-bound lookup tables. And in our application, that means > the CPU will have to do even less. ... > And so when we run the *same* software on that newer hardware, we find > that we have much more idle time, much more RAM, and much more ROM. Yes. > So the obvious question is how can we use those extra resources to our > benefit. Good. > And one way we're looking to do that is to divide up the > software into two major classes: the time-critical code (which will > remain in C or C++) and the rest of the system (which we'll move to a > higher-level language like Lua). You probably have to keep a minimal amount of low-level code, e.g., in C or assembly, but beyond that you should only need one HLL language. So, why would you split the codebase between two different languages? Won't that require *two* groups of programmers? Do you intend to hire C programmers and require them to program Lua most of the time? Or, do you intend to hire Lua programmers and force them to do C sometimes? Either way, that's probably a bad choice ... That's ignoring things like the cost or availability (or lack of) Lua programmers. C is very moldable. What's wrong with writing a library or preprocessor defines to do in C what you want to do in Lua? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Josh Grams <josh@qualdan.com> |
|---|---|
| Date | 2011-08-15 12:15 +0000 |
| Message-ID | <4e490dce$0$27156$a8266bb1@newsreader.readnews.com> |
| In reply to | #4914 |
Rod Pemberton wrote: <j2ait3$fk9$1@speranza.aioe.org> > "John Passaniti" <john.passaniti@gmail.com> wrote in message > news:f818cbaf-eceb-46ae-a427-8003a369eab4@en1g2000vbb.googlegroups.com... > >> And one way we're looking to do that is to divide up the >> software into two major classes: the time-critical code (which will >> remain in C or C++) and the rest of the system (which we'll move to a >> higher-level language like Lua). > > You probably have to keep a minimal amount of low-level code, e.g., in C or > assembly, but beyond that you should only need one HLL language. So, why > would you split the codebase between two different languages? Won't that > require *two* groups of programmers? Do you intend to hire C programmers > and require them to program Lua most of the time? Or, do you intend to hire > Lua programmers and force them to do C sometimes? I don't think there *are* "Lua programmers" or "C programmers" any more; isn't that a thing of the 90s (or earlier)? AFAICT these days any halfway competent programmer is thoroughly fluent in at least several languages, and passably familiar with a half dozen to a dozen more. For instance, though I'm mostly just a hobby programmer, I'm fluent in C, Forth, and PHP. I have done quite a bit of x86, PPC, and z80 assembly language, but not in a while, so I'd need to do some brushing up if I were going to do any serious work. I can read and debug code in Perl, Python, Ruby, emacs Lisp, JavaScript, and the Unix shell variants with no trouble, but usually need some resort to reference materials to write in those languages. I have dabbled in Prolog, Haskell, Common Lisp, Factor, and a number of others. I generally figure it only takes a couple of weeks, maybe a month, before I'm reasonably competent in a new language, and within 3 to 6 months I generally know it about as well as I have any real need to. Multiple languages just aren't a big deal any more. > C is very moldable. What's wrong with writing a library or > preprocessor defines to do in C what you want to do in Lua? Er...because what you want from Lua is a scripting language which does garbage collection and dynamic typing (is that the term I want?) and can evaluate code at runtime rather than having to compile it, and that sort of thing. You can't add that to C with a library or preprocessor defines. Or...maybe you could, but why re-implement Lua when it already exists? --Josh
[toc] | [prev] | [next] | [standalone]
| From | Nomen Nescio <nobody@dizum.com> |
|---|---|
| Date | 2011-08-15 20:51 +0200 |
| Message-ID | <7b6a303d2e382688f064b2120a9dfc1c@dizum.com> |
| In reply to | #4933 |
Josh Grams <josh@qualdan.com> wrote: > I don't think there *are* "Lua programmers" or "C programmers" any more; > isn't that a thing of the 90s (or earlier)? AFAICT these days any > halfway competent programmer is thoroughly fluent in at least several > languages, and passably familiar with a half dozen to a dozen more. When it comes to web stuff you're probably correct, but generally I think there are more specialty programmers than there are guys who code in multiple languages if we are talking about people who write code for their job. As an example I can get by in about 25 languages but I'm only an expert in one and that's because I use it day in and day out and don't have time for hobby coding so I don't use other languages much. In my off time I don't do much coding because I have many other interests so my other language skills get rusty and stay rusty. I think hobby programmers (which you consider yourself) probably do projects in more languages than most professionals because we have to specialize and keep up, and you don't. I mean you're not going to lose your job or look bad if you write shitty code or break something but guys who write code for their jobs will (or should!) if they keep doing that. The industry has always pushed developers towards specialization. The places where you use more than one language in a job are rare, and probably most of those are in web, as I said, or sysadmin type jobs where they have to deal with piles of legacy crap other sysadmins have left behind.
[toc] | [prev] | [next] | [standalone]
| From | Josh Grams <josh@qualdan.com> |
|---|---|
| Date | 2011-08-15 21:56 +0000 |
| Message-ID | <4e499604$0$27081$a8266bb1@newsreader.readnews.com> |
| In reply to | #4944 |
Nomen Nescio wrote: <7b6a303d2e382688f064b2120a9dfc1c@dizum.com> > Josh Grams <josh@qualdan.com> wrote: > >> I don't think there *are* "Lua programmers" or "C programmers" any more; >> isn't that a thing of the 90s (or earlier)? AFAICT these days any >> halfway competent programmer is thoroughly fluent in at least several >> languages, and passably familiar with a half dozen to a dozen more. > > When it comes to web stuff you're probably correct, but generally I think > there are more specialty programmers than there are guys who code in > multiple languages if we are talking about people who write code for their > job. I guess I was thinking of embedded programmers rather than mainstream application kind of guys, since that was kind of the context of the discussion. I have the impression that they tend to use whatever quirky thing required to get the necessary performance out of small hardware, and then more "convenience" languages on the desktop to explore, generate data tables, or other associated tasks that don't have to run with such limited resources. But that's just the impression I've picked up from listening to random people talk; as you've probably guessed, I came to this as a young hobbyist, with a few years working on web development and sysadmin stuff. I'm sure there are any number of people who are, say, straight Java programmers (or a handful of other languages). But I'm not sure I believe that there are dedicated Lua programmers. :) --Josh
[toc] | [prev] | [next] | [standalone]
| From | "Jeff M." <massung@gmail.com> |
|---|---|
| Date | 2011-08-15 19:50 -0700 |
| Message-ID | <3b5a75d8-9b0c-4a45-a2b3-0f34d10a62ec@glegroupsg2000goo.googlegroups.com> |
| In reply to | #4944 |
On Monday, August 15, 2011 12:51:11 PM UTC-6, Nomen Nescio wrote: > Josh Grams <jo...@qualdan.com> wrote: > > > I don't think there *are* "Lua programmers" or "C programmers" any more; > > isn't that a thing of the 90s (or earlier)? AFAICT these days any > > halfway competent programmer is thoroughly fluent in at least several > > languages, and passably familiar with a half dozen to a dozen more. > > When it comes to web stuff you're probably correct, but generally I think > there are more specialty programmers than there are guys who code in > multiple languages if we are talking about people who write code for their > job. > I really wonder how much of a factor this really is. I may be on the "young" side for people who frequent this group, but in the 12 years I've been professionally programming, I've yet to ever interview for - or interview someone else for - a position that required someone to hit the ground running on day one, immediately knowing N technologies "fluently," one of which being the language of choice for the company in question. Instead, it's always been far more valuable for the potential employee to be "fluent" in the problem domain. Do you know what kind of problems we're going to run into going down path A instead of B? Do you have experience mitigating those potential risks? Can you effectively communicate your concerns and ideas with those above you, peers, and/or those under you? Are you motivated and smart enough that I said you had to use language X, can you pick it up quickly, learn the 2-3 new paradigms it excels at, and use paradigms picked up in other languages to benefit you? And, are you capable of using Google to learn the basics instead of sitting idly by waiting for someone else to give you the answers? ;-) I'd rather hire someone with -0- experience using whatever language was required, but could do the aforementioned as opposed to someone who was "God" of that language, but as soon as there was a curve ball that required thinking outside that language's "box" they were immediately stuck. My 2 cents. Jeff M.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2011-08-16 03:07 -0700 |
| Message-ID | <2efd03fc-13e5-4b48-a901-0bcbdab4c0cc@a27g2000yqc.googlegroups.com> |
| In reply to | #4964 |
On Aug 16, 3:50 am, "Jeff M." <mass...@gmail.com> wrote: > On Monday, August 15, 2011 12:51:11 PM UTC-6, Nomen Nescio wrote: > > Josh Grams <jo...@qualdan.com> wrote: > > > > I don't think there *are* "Lua programmers" or "C programmers" any more; > > > isn't that a thing of the 90s (or earlier)? AFAICT these days any > > > halfway competent programmer is thoroughly fluent in at least several > > > languages, and passably familiar with a half dozen to a dozen more. > > > When it comes to web stuff you're probably correct, but generally I think > > there are more specialty programmers than there are guys who code in > > multiple languages if we are talking about people who write code for their > > job. > > I really wonder how much of a factor this really is. I may be on the "young" side for people who frequent this group, but in the 12 years I've been professionally programming, I've yet to ever interview for - or interview someone else for - a position that required someone to hit the ground running on day one, immediately knowing N technologies "fluently," one of which being the language of choice for the company in question. > > Instead, it's always been far more valuable for the potential employee to be "fluent" in the problem domain. Do you know what kind of problems we're going to run into going down path A instead of B? Do you have experience mitigating those potential risks? Can you effectively communicate your concerns and ideas with those above you, peers, and/or those under you? Are you motivated and smart enough that I said you had to use language X, can you pick it up quickly, learn the 2-3 new paradigms it excels at, and use paradigms picked up in other languages to benefit you? And, are you capable of using Google to learn the basics instead of sitting idly by waiting for someone else to give you the answers? ;-) > > I'd rather hire someone with -0- experience using whatever language was required, but could do the aforementioned as opposed to someone who was "God" of that language, but as soon as there was a curve ball that required thinking outside that language's "box" they were immediately stuck. > > My 2 cents. > > Jeff M. Agreed. I once hired a guy to do Visual Basic programming. He had absoloutely no experience whatsoever in VB programming, and said so at the top of the test paper. He answered all his questions using C code. That's fine by me. If you can learn C, you can learn VB. He did and did well at it. We're still friends more than 10 years later. Mark
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-08-18 23:45 -0700 |
| Message-ID | <ec25a5cc-ef12-4996-9ca5-d895ad9e7cdd@m18g2000vbl.googlegroups.com> |
| In reply to | #4975 |
On Aug 16, 6:07 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote: > I once hired a guy to do Visual Basic programming. He had > absoloutely no experience whatsoever in VB programming, > and said so at the top of the test paper. He answered all > his questions using C code. > > That's fine by me. If you can learn C, you can learn VB. He > did and did well at it. We're still friends more than 10 > years later. Where I work, we recently hired a new guy. I was responsible for technical evaluation of the candidates which was the normal conversational interview along with a skill assessment. That assessment was composed of seven questions, four of which required the candidate to write code. The assessment's instructions stated that the candidate was free to choose whatever language they were most comfortable with or which they felt worked best to solve the problem. I also stated, "your code will be read by a human being, not a compiler, so minor syntax errors are ignored." Most of the candidates were fine with this, but it was surprising to me that a few of the candidates were taken aback by the freedom they were given. Weird. The point is, of course, that coding is only one part of programming, and it's not the most important part. Being able to think like a programmer is far more important. Because when you have that skill,then you can usually translate that skill to whatever language you happen to be using. And that is what makes you valuable, not that you know syntax. Obviously at some point, the goal is that you can write efficient, elegant, and correct code. But that is just mechanical mapping of the concepts in your head down to the language you're using.
[toc] | [prev] | [next] | [standalone]
| From | arc <arc@vorsicht-bissig.de> |
|---|---|
| Date | 2011-08-18 11:38 +0000 |
| Message-ID | <j2itk0$b67$1@dont-email.me> |
| In reply to | #4964 |
Jeff M. wrote: > Instead, it's always been far more valuable for the potential employee to be "fluent" in the problem domain. Do you know what kind of problems we're going to run into going down path A instead of B? Do you have experience mitigating those potential risks? Can you effectively communicate your concerns and ideas with those above you, peers, and/or those under you? Are you motivated and smart enough that I said you had to use language X, can you pick it up quickly, learn the 2-3 new paradigms it excels at, and use paradigms picked up in other languages to benefit you? And, are you capable of using Google to learn the basics instead of sitting idly by waiting for someone else to give you the answers? ;-) > > > I'd rather hire someone with -0- experience using whatever language was required, but could do the aforementioned as opposed to someone who was "God" of that language, but as soon as there was a curve ball that required thinking outside that language's "box" they were immediately stuck. > The 'box' thing can be a problem for the previous paragraph, though. I've heard several times (either directly or second-hand) programmers who were very competent with procedural language admitting that they just don't 'get' some non-procedural paradigm (like functional programming or SQL). And i've also seen this for myself - code written by people (professionals, too) who clearly haven't 'got it' and are sticking to the procedural language ruts that they're used to. It took me a little while to get to grips with SQL myself, despite having used functional programming languages before. I'm sure I picked it up quickly enough, but it was a different matter to learning a new procedural language. I wouldn't hesitate to hire a C programmer to write Visual Basic like Mark did (well, i don't really know anything about Visual Basic, but I assume it's a fairly standard procedural language). But I wouldn't be so confident of their ability to learn SQL well. I'm not sure how you tell someone can do this unless you've got some evidence of them having done this before. -arc.
[toc] | [prev] | [next] | [standalone]
Page 6 of 16 — ← Prev page 1 … 4 5 [6] 7 8 … 16 Next page →
Back to top | Article view | comp.lang.forth
csiph-web