Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #3564 > unrolled thread
| Started by | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| First post | 2011-06-26 15:13 -0500 |
| Last post | 2011-07-02 17:52 +0000 |
| Articles | 20 on this page of 328 — 44 participants |
Back to article view | Back to comp.lang.forth
The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-06-26 15:13 -0500
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-27 16:13 +0100
Re: The Lisp Curse vandys@vsta.org - 2011-06-27 15:50 +0000
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-27 16:55 +0100
Re: The Lisp Curse vandys@vsta.org - 2011-06-27 17:23 +0000
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-27 20:09 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-06-29 18:59 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 12:49 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-02 16:38 -0700
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-03 11:27 +0000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-03 17:40 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-04 18:38 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-06-30 12:25 -0700
Forth OO ( was: Re: The Lisp Curse ) Doug Hoffman <glidedog@gmail.com> - 2011-07-12 09:43 -0400
Re: Forth OO ( was: Re: The Lisp Curse ) Doug Hoffman <glidedog@gmail.com> - 2011-07-12 12:35 -0400
Re: Forth OO ( was: Re: The Lisp Curse ) John Passaniti <john.passaniti@gmail.com> - 2011-07-13 10:02 -0700
Re: Forth OO ( was: Re: The Lisp Curse ) Doug Hoffman <glidedog@gmail.com> - 2011-07-14 08:32 -0400
Re: Forth OO ( was: Re: The Lisp Curse ) Alex McDonald <blog@rivadpm.com> - 2011-07-14 07:10 -0700
Re: Forth OO ( was: Re: The Lisp Curse ) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-14 09:31 -0500
Re: The Lisp Curse arc@vorsicht-bissig.de - 2011-07-12 22:20 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-13 10:01 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-28 03:02 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-06-27 21:29 -1000
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-28 06:55 -0400
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-06-28 06:17 -0500
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-28 14:14 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-06-30 16:08 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:01 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-01 13:41 -1000
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-04 21:18 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 02:26 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-02 16:56 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-02 08:28 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-02 17:00 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-03 10:20 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-04 20:57 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-06 15:45 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-06 16:19 -0700
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-07-07 01:23 +0000
Re: The Lisp Curse "David N. Williams" <williams@umich.edu> - 2011-07-06 21:44 -0400
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-06 19:01 -0700
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-07-07 10:39 +0000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-07 13:07 -0700
Re: The Lisp Curse "David N. Williams" <williams@umich.edu> - 2011-07-06 21:42 -0400
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-07 10:32 +0100
Re: The Lisp Curse marko <marko@marko.marko.marko> - 2011-07-07 22:09 +1000
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-07 09:19 -0500
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-07 14:08 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 10:33 +0100
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-08 05:31 -0500
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 17:47 +0100
Re: The Lisp Curse vandys@vsta.org - 2011-07-08 17:23 +0000
Re: The Lisp Curse Spam@ControlQ.com - 2011-07-08 15:34 -0400
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 21:04 +0100
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-08 10:34 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 21:28 +0100
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-09 15:25 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-10 10:14 +0100
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-10 22:02 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 03:18 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-11 12:42 -0700
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-12 19:42 +0000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-12 14:42 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-07-11 07:01 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 07:24 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-11 20:40 -0700
Re: The Lisp Curse Ron Aaron <rambamist@gmail.com> - 2011-07-11 21:24 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-12 18:54 -0700
Re: The Lisp Curse Ron Aaron <rambamist@gmail.com> - 2011-07-12 20:45 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-13 00:28 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-13 10:25 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-11 19:55 +0100
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 13:41 -0700
Re: The Lisp Curse Mark Wills <forthfreak@forthfiles.net> - 2011-07-11 13:45 -0700
Re: The Lisp Curse Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-07-12 21:51 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-09 16:49 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 04:27 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-07 14:53 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-28 11:57 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-29 21:54 -0700
Re: The Lisp Curse Julian Fondren <ayrnieu@gmail.com> - 2011-07-30 18:22 -0500
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-01 12:59 +0000
Re: The Lisp Curse Julian Fondren <ayrnieu@gmail.com> - 2011-08-02 00:07 -0500
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-01 22:58 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-08 20:44 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-31 10:25 +0100
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-08 16:00 -0700
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-10 07:08 -1000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-10 18:01 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-11 03:05 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 07:37 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-11 10:07 -0500
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 08:32 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-11 08:37 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 18:25 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-12 01:37 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-12 07:15 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-12 08:02 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-11 08:13 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 18:50 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-12 01:39 -0700
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-11 10:06 +0000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 08:02 -0700
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-12 11:49 +0000
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-12 13:18 +0000
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-08-12 18:49 +0200
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-12 12:52 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-14 09:54 -0400
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-14 12:53 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-14 13:21 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-14 15:09 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-15 04:52 -0400
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-15 03:46 -0400
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-08-15 12:15 +0000
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-08-15 20:51 +0200
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-08-15 21:56 +0000
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-15 19:50 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-16 03:07 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-18 23:45 -0700
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-18 11:38 +0000
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-18 07:57 -1000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-15 06:01 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-16 05:10 -0400
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-16 03:13 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-18 23:31 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-19 06:09 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-20 17:14 -0700
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-20 20:38 -0700
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-20 20:49 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-20 23:39 -0700
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-21 00:29 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 00:57 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 01:04 -0700
Hamming numbers (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-22 16:12 +0000
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net> - 2011-08-21 13:21 +0200
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 10:40 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-21 13:56 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 12:33 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 12:42 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 13:30 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 12:49 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-23 10:20 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:15 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-24 00:13 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-21 13:41 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 11:48 -0400
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-22 10:36 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 22:57 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-22 23:28 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-23 04:16 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-23 08:29 -0500
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-23 14:59 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:12 -0400
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:09 -0400
Re: The Lisp Curse vandys@vsta.org - 2011-08-22 16:54 +0000
Re: The Lisp Curse Doug Hoffman <glidedog@gmail.com> - 2011-08-23 10:48 -0400
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-23 11:41 -0500
Re: The Lisp Curse vandys@vsta.org - 2011-08-23 17:11 +0000
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-23 12:27 -0500
Re: The Lisp Curse Brad <hwfwguy@gmail.com> - 2011-08-23 10:07 -0700
Re: The Lisp Curse Pablo Hugo Reda <pabloreda@gmail.com> - 2011-08-23 13:02 -0700
Re: The Lisp Curse vandys@vsta.org - 2011-08-23 20:30 +0000
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-21 13:49 -0400
Re: The Lisp Curse George Hubert <georgeahubert@yahoo.co.uk> - 2011-08-22 01:49 -0700
Re: The Lisp Curse vandys@vsta.org - 2011-08-22 17:02 +0000
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-22 07:50 -1000
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-23 01:03 -0700
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-22 22:38 -1000
Hamming numbers (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-22 15:10 +0000
Re: Hamming numbers Paul Rubin <no.email@nospam.invalid> - 2011-08-23 00:09 -0700
Re: Hamming numbers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-23 13:09 +0000
Re: Hamming numbers Paul Rubin <no.email@nospam.invalid> - 2011-08-23 10:41 -0700
Re: Hamming numbers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-23 17:58 +0000
Re: Hamming numbers Paul Rubin <no.email@nospam.invalid> - 2011-08-24 00:25 -0700
Re: Hamming numbers Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net> - 2011-08-24 07:17 +0200
Re: The Lisp Curse vandys@vsta.org - 2011-08-19 17:41 +0000
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-19 18:05 +0000
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-19 13:53 -0500
Re: The Lisp Curse Pablo Hugo Reda <pabloreda@gmail.com> - 2011-08-19 13:15 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-19 15:39 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-19 19:49 -0400
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-19 17:41 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-20 03:54 -0400
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-08-20 15:20 +0000
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-21 14:41 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 11:47 -0400
Re: The Lisp Curse coos haak <chforth@hccnet.nl> - 2011-08-22 20:30 +0200
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-22 15:22 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 23:34 -0400
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-22 22:48 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:07 -0400
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-23 15:44 -1000
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-23 21:43 -0700
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-08-20 08:55 +0000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-12 10:49 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-13 14:03 +0000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-14 07:57 -0700
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-12 09:51 -1000
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-13 13:45 +0000
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-13 08:08 -1000
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-08-14 02:56 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-13 04:35 -0500
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-12 07:53 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-13 14:13 +0000
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-13 13:59 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-14 14:46 +0000
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-17 01:31 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-06-28 03:24 -0500
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201106.rodent.frell.theremailer.net> - 2011-06-28 19:55 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 06:30 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-29 13:49 +0100
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-29 14:02 +0100
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 18:16 -0400
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-06-29 15:45 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 19:45 -0400
Re: The Lisp Curse Elko T <nono.black.elko@gmail.com> - 2011-06-29 22:08 -0400
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-30 10:07 -0400
Re: The Lisp Curse coos haak <chforth@hccnet.nl> - 2011-06-30 20:44 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-30 18:08 -0400
Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-06-30 20:07 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-06-30 22:12 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:01 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-01 17:59 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) The Beez <the.beez.speaks@gmail.com> - 2011-07-01 16:33 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-02 18:37 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) kenney@cix.compulink.co.uk - 2011-07-01 06:07 -0500
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:00 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-01 14:06 +0000
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-01 14:57 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-02 16:55 +0000
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:04 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-02 11:26 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) coos haak <chforth@hccnet.nl> - 2011-07-02 22:10 +0200
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-02 14:36 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-02 21:36 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-02 18:25 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-03 10:53 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-04 23:41 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-05 01:02 -0700
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-02 22:46 +0200
Re: The Lisp Curse David Thompson <dave.thompson2@verizon.net> - 2011-07-18 01:25 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-30 14:44 +0100
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 23:24 +0100
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-03 12:04 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-03 20:24 -0400
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 02:21 -0700
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-04 16:02 +0200
Re: The Lisp Curse Tarkin <tarkin000@gmail.com> - 2011-07-04 10:21 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 11:13 -0700
Re: The Lisp Curse Tarkin <tarkin000@gmail.com> - 2011-07-04 12:31 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 15:01 -0700
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-04 13:23 -1000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 01:45 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-05 11:34 +0000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 05:34 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-05 14:28 +0000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 09:39 -0700
OT: full virtualization (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-07 15:36 +0000
Re: OT: full virtualization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-07 13:17 -0500
Re: OT: full virtualization Alex McDonald <blog@rivadpm.com> - 2011-07-08 04:53 -0700
Re: OT: full virtualization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-08 17:11 +0000
Re: OT: full virtualization Alex McDonald <blog@rivadpm.com> - 2011-07-08 12:41 -0700
Re: OT: full virtualization (was: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-08 04:34 -0700
Re: OT: full virtualization (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-10 16:03 +0000
Re: OT: full virtualization (was: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-10 13:06 -0700
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-07 00:11 +0200
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-06 12:47 -1000
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-07 10:07 +0000
Re: The Lisp Curse Tarkin <tarkin000@gmail.com> - 2011-07-07 13:00 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-04 12:40 -0500
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 11:15 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-04 15:53 -0500
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-05 10:16 +0200
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 02:23 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-05 09:54 -0500
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-05 22:33 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-05 16:28 -0500
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 16:18 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-04 15:03 -0400
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-05 00:20 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-05 11:35 -0400
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 09:46 -0700
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-05 23:13 +0200
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-05 15:31 -0700
Re: The Lisp Curse kenney@cix.compulink.co.uk - 2011-07-07 04:38 -0500
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-05 19:21 -0500
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-05 14:57 -1000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-05 20:48 -0700
Re: The Lisp Curse BruceMcF <agila61@netscape.net> - 2011-07-06 07:38 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-06 09:46 -0500
Re: The Lisp Curse kenney@cix.compulink.co.uk - 2011-07-07 04:38 -0500
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-07 10:41 -0500
Re: The Lisp Curse BruceMcF <agila61@netscape.net> - 2011-07-07 09:12 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-06 09:53 -0500
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-06 21:45 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-07 14:48 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-07-07 20:20 +0100
Re: The Lisp Curse coos haak <chforth@hccnet.nl> - 2011-07-08 04:39 +0200
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-07-12 23:22 +0100
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-12 19:35 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-07-13 23:37 +0100
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-12 05:10 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-12 03:44 -0500
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-13 22:06 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-14 04:01 -0500
Re: The Lisp Curse kenney@cix.compulink.co.uk - 2011-07-07 04:38 -0500
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-03 07:34 -0500
Re: The Lisp Curse Spam@ControlQ.com - 2011-06-29 13:25 -0400
Forth as implementation language vandys@vsta.org - 2011-06-29 18:27 +0000
Re: Forth as implementation language Spam@ControlQ.com - 2011-06-29 17:50 -0400
Re: Forth as implementation language vandys@vsta.org - 2011-06-29 22:45 +0000
Re: Forth as implementation language Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 13:04 +0100
Re: Forth as implementation language Spam@ControlQ.com - 2011-06-30 11:42 -0400
Re: Forth as implementation language "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-30 13:12 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-06-29 08:38 -1000
Re: The Lisp Curse Spam@ControlQ.com - 2011-06-29 18:01 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-06-29 12:50 -1000
Re: The Lisp Curse stephenXXX@mpeforth.com (Stephen Pelc) - 2011-06-30 08:15 +0000
Re: The Lisp Curse Spam@ControlQ.com - 2011-07-03 15:22 -0400
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 13:09 +0100
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 18:31 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-06-29 23:01 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-01 09:42 -0500
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-01 18:49 +0000
Re: The Lisp Curse Mentifex <mentifex@myuw.net> - 2011-06-29 15:41 -0700
Re: The Lisp Curse "Fuschia, President-Elect of the Bright Purplish-Green Council" <fp-eotbp-gc@ibm.com> - 2011-06-29 19:16 -0400
Re: The Lisp Curse Mark Wills <forthfreak@forthfiles.net> - 2011-06-30 00:34 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-02 17:52 +0000
Page 11 of 17 — ← Prev page 1 … 9 10 [11] 12 13 … 17 Next page →
| From | Nomen Nescio <nobody@dizum.com> |
|---|---|
| Date | 2011-08-14 02:56 +0200 |
| Message-ID | <5879201819f9ec358d45f95272e08c9e@dizum.com> |
| In reply to | #4822 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Looking at some of the most popular languages today, I see some that > definitely benefited from marketing (e.g., Java), but also others like > Python and Ruby that certainly had no professional marketing (at least > up to the stage where they were so successful that publishers paid for > books about them). Interesting that those three languages you mentioned are scripting languages (byte-compiled, not native)..and.... > I also see languages like PL/1 and Ada that had a big and committed > organization behind them, but still did not succeed in the wider public > (although they still have their users and (at least Ada) fans). PL/I has succeeded in many ways. It's still used enough on IBM that IBM pays a staff quite a lot of money to keep the compiler upgraded from year to year. It has its fans, although if you don't work on the mainframe you probably haven't had a chance to see why it's so good. It's still here with us since around 1964 so it's hard to say it hasn't succeeded. I suppose it depends on what you mean by that word and what the people who developed it meant. IBM doesn't care about selling zillions of copies, that's a PC business model. They care about big margins and big support dollars and they succeeded with PL/I. Ada has also succeeded in its niche although it's been pushed out a bit lately. The problem there is companies selling mostly to government contractors who pass the high price of admission back to the US taxpayers. There is a very good free as in beer compiler available on the PC (Windows and Linux) but that hasn't helped since C and C++ make life simpler when programming on OS written in C and C++ (UNIX/Linux, and Windows).
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-08-13 04:35 -0500 |
| Message-ID | <vN-dnfsnAsHs2NvTnZ2dnUVZ8tKdnZ2d@supernews.com> |
| In reply to | #4775 |
arc <arc@vorsicht-bissig.de> wrote: > Forthers claim that C's success over Forth is largely to do with > extrinsic factors. This Forther doesn't. In some of the areas C is used, it's a better choice than Forth would be. Not all of them: in many areas, Forth would be a better choice. The most important issue, though, is that of a lingua franca. By all accounts the original lingua franca was a terrible language, but it was good enough and everyone spoke it. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Keith H Duggar <duggar@alum.mit.edu> |
|---|---|
| Date | 2011-08-12 07:53 -0700 |
| Message-ID | <d56b19e5-5886-419d-9d35-56edba7e82d5@y24g2000yqb.googlegroups.com> |
| In reply to | #4772 |
On Aug 12, 7:49Â am, arc <a...@vorsicht-bissig.de> wrote: > 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 see. Yes that was poor and misleading phrasing on my part. I did not mean to say survial == "better"ness. I mean to say that when evaluating overall "better"ness one should consider market survival as a crucial data point. > > 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. Agreed. > 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. Sure. "Great" marketing (ie "substantial, dedicated, and well-funded") or even some marketing can help. My only claim is that it is not /necessary/. > 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. It certainly does. As another example, familiarity partly explains Lua's rapid success and market acceptance. > 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. Agreed. > 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.) I agree with you entirely. I even partially agree with your characterization of my tone here. The reason for that tone? Simple, I am not interested in debating points you raised above because they have been debated /numerous/ times in many, many contexts. My only goal is to point out, casually without proof, that the /only if/ direction of EDRs universal claim "Technical superiority will win if and only if there is a substantial, dedicated, and well-funded marketing campaign behind it." is a non-sense, bs, feel good excuse that has been debunked multiple times. Heck, EDR herself even gives one example in nearby thread Elizabeth D Rather wrote: > FORTH83 mandated implementation details such as return > addresses, stack widths (only 16 bits!), layout of definitions, > etc. In the Forth94 process, we realized that this was a > terrible mistake, and took the firm step towards specifying > behavior, not implementation. Wow ... FORTH83 embodies /at least one/ "terrible mistake"; but, you know, it's all because of 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'. No not all "Forth adherents", just some, perhaps even a small subset. > 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. You have mistakenly project or somewhere I have mistakenly implied a /universal/ claim about /all Forthers/. That is not my intent. There is a subset responsible for propagating the same old tired excuses now and many times in the past. My purpose is only to provide a small counterbalance by simply point those excuses are bs. Anyone who wants to learn more can google and think for themselves. > 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. See above. Mostly I want open minded readers to know there is a possibility that EDR is simply spouting "feel good" tired old excuses for failure. > 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. Yes, mostly by pure luck I backed some "winners". The only thing that makes me feel is lucky. > Explain yourself, sir. I don't want innocent casual readers to be mislead into thinking Forth's lack of success, if there is a lack of success, is only because of "marketing". That might send them down blind allys wasting the finite resources of the world. > [1] Â At any rate, Andrew, Alex and I are certainly having difficulty > discerning much of an argument in your utterances. Because, it seems, both of you mistakenly determined I was here to create yet another debate on the history and merits of Forth. That has been done to death. I'm only posting to call bs on EDRs non-sense universal claim "Technical superiority will win if and only if there is a substantial, dedicated, and well-funded marketing campaign behind it." From what I can see, you actually agree that the universal only if claim above is non-sense? KHD
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-08-13 14:13 +0000 |
| Message-ID | <2011Aug13.161318@mips.complang.tuwien.ac.at> |
| In reply to | #4772 |
arc <arc@vorsicht-bissig.de> writes:
>5) whether the product is sufficiently similar to other products on the
>market to make transition easy.
Note that similarity can be a benefit or a disadvantage.
E.g., Magic/L was a Forth-based language with Algol-style syntax
(i.e., more similar to Algol-family languages like C than Forth), but
it's dead.
Another example: Modula-2 became relatively successful for a while,
but was eventually replaced by other Algol-family languages like Turbo
Pascal, C, C++, or Java.
>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.
The interesting thing is that Forth and Unix offered many of the same
features in the beginning; in particular, Forth was (and, in some
systems, still is) a flexible, multi-platform, multi-user operating
system.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-08-13 13:59 -0700 |
| Message-ID | <7xmxfdc9iw.fsf@ruckus.brouhaha.com> |
| In reply to | #4824 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > The interesting thing is that Forth and Unix offered many of the same > features in the beginning; in particular, Forth was (and, in some > systems, still is) a flexible, multi-platform, multi-user operating > system. I'd would expect that any reasonable "flexible, multi-user OS" would have to incorporate pre-emptive multitasking and interprocess memory protection at minimum. I thought Forth traditionally used cooperative multitasking in a single address space, which is fine for many types of concurrent applications but not for timesharing.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-08-14 14:46 +0000 |
| Message-ID | <2011Aug14.164650@mips.complang.tuwien.ac.at> |
| In reply to | #4838 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> The interesting thing is that Forth and Unix offered many of the same
>> features in the beginning; in particular, Forth was (and, in some
>> systems, still is) a flexible, multi-platform, multi-user operating
>> system.
>
>I'd would expect that any reasonable "flexible, multi-user OS" would
>have to incorporate pre-emptive multitasking and interprocess memory
>protection at minimum.
Unix did not get memory protection before 3BSD in 1979. As mentioned,
they really offered many of the same features in the beginning;
divergence in features came later.
As for pre-emptive vs. cooperative multitasking: If the programmers on
Unix could refrain from destroying other processes' memory, they
probably could also refrain from monopolizing the CPU.
>I thought Forth traditionally used cooperative
>multitasking in a single address space, which is fine for many types of
>concurrent applications but not for timesharing.
Forth and early Unix were used for time-sharing, so a single address
space and cooperative multitasking obviously was fine for
time-sharing. Today, we have higher expectations of OSs (or lower
expectations of applications:-); the original Unix would flop today.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-08-17 01:31 -0700 |
| Message-ID | <7x62lwwib8.fsf@ruckus.brouhaha.com> |
| In reply to | #4879 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Unix did not get memory protection before 3BSD in 1979.
I think you mean virtual memory. The PDP-11 versions had memory
protection much earlier. E.g. Ritchie and Thompson 1974:[1]
The user-memory part of an image is divided into three logical
segments. The program text segment begins at location 0 in the
virtual address space. During execution, this segment is
write-protected and a single copy of it is shared among all
processes executing the same program. At the first hardware
protection byte boundary above the program text segment in the
virtual address space begins a non-shared, writable data segment,
the size of which may be extended by a system call.
Consider also that the setuid bit was patented in 1972. Setuid
would have made no sense if there was no memory protection.
> As for pre-emptive vs. cooperative multitasking: If the programmers on
> Unix could refrain from destroying other processes' memory, they
> probably could also refrain from monopolizing the CPU.
Of the even older PDP-11/20 version, Ritchie wrote:[2]
Back around 1970-71, Unix on the PDP-11/20 ran on hardware that not
only did not support virtual memory, but didn't support any kind of
hardware memory mapping or protection, for example against writing
over the kernel. This was a pain, because we were using the machine
for multiple users. When anyone was working on a program, it was
considered a courtesy to yell "A.OUT?" before trying it, to warn
others to save whatever they were editing.
[A substory: at some point several were sitting around working
away. Bob Morris asked, almost conversationally, "what are the
arguments to ld?" Someone told him. We continued typing for the
next minute, as a thought began to percolate, not quite to the top
of the brain-- in other words, not quite fast enough. The terminal
stopped echoing before anyone could stop and say "Hold on Bob, what
is it you're trying to do?"]
They later bought a special board (described in same place) to add
memory protection to the 11/20.
I'd say an OS with no protection can't support software development
concurrently with other stuff, so it's not really general-purpose.
It's more like a wrapper for a multi-task application.
> Forth and early Unix were used for time-sharing, so a single address
> space and cooperative multitasking obviously was fine for
> time-sharing. Today, we have higher expectations of OSs (or lower
> expectations of applications:-); the original Unix would flop today.
If giants like Thompson and Ritchie needed memory protection, most of
the rest of us would have no chance without it ;-).
[1] http://cm.bell-labs.com/cm/cs/who/dmr/cacm.pdf
[2] http://cm.bell-labs.com/cm/cs/who/dmr/odd.html
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-06-28 03:24 -0500 |
| Message-ID | <ibKdnWYFUvc1EpTTnZ2dnUVZ8sWdnZ2d@supernews.com> |
| In reply to | #3593 |
Rod Pemberton <do_not_have@noavailemail.cmm> wrote: > From the "Lisp Curse" article: > > "Real Hackers have also known, for a while, that C and C++ are not > appropriate for most programs that don't need to do arbitrary > bit-fiddling." > > Wow, some people just truly hate C don't they? I guess belittling a > successful HLL language is one way to make your unwise decision to > use an another unpopular, unsuccessful one seem less grating. Eh? Surely the comment is simply true, or at the worst a reasonable opinion. I can't see that there's any hatred there. > What's really telling though is that none of the people who hate C > seem to hate other Algol derived languages such as BASIC and Pascal, > nor Pascal derivatives: Algol W, Modula, Modula-2, Oberon, Prolog, > nor C derivatives: C++, Java, Objective-C. What is that: > irrationality, or hate? ISTM that Forth and Lisp programmers seem > to use the word "feel" alot, instead of "think"... Would you say > this is true? No. I think your imagination is running away. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Fritz Wuehler <fritz@spamexpire-201106.rodent.frell.theremailer.net> |
|---|---|
| Date | 2011-06-28 19:55 +0200 |
| Message-ID | <1e406776cc6779c8ac4f6231c24dbffa@msgid.frell.theremailer.net> |
| In reply to | #3593 |
"Rod Pemberton" <do_not_have@noavailemail.cmm> wrote: > "Real Hackers have also known, for a while, that C and C++ are not > appropriate for most programs that don't need to do arbitrary > bit-fiddling." > > Wow, some people just truly hate C don't they? Yes, we do. But what you quoted doesn't sound hateful to me, maybe you're projecting? ;-) > I guess belittling a successful HLL language is one way to make your > unwise decision to use an another unpopular, unsuccessful one seem less > grating. That's not much of an argument unless you sell software. How popular or successful a language (implementation) is has nothing to do with how good it is. C was used to write UNIX (yes I know not the original UNIX clunker, just the next few decades of clunkers) so if you want to work in that environment it's a top choice. Other OS were written in other languages so whatever they're written in is a top choice. Companies sell this or that and people are basically sheep so they do what they're told and believe what companies tell them. How does popularity relate to how good something is? Not at all. C and C++ are not HLL. You really ought to know better. > What's really telling though is that none of the people who hate C seem to > hate other Algol derived languages such as BASIC and Pascal, nor Pascal > derivatives: Algol W, Modula, Modula-2, Oberon, Prolog, nor C derivatives: > C++, Java, Objective-C. C isn't ALGOL derived more than any HLL with control structures is ALGOL derived. That is way too general. And BASIC has nothing to do with ALGOL at all. If people like Pascal then it's either because they're mindless structured programming groupies or because they grew up on Turbo Pascal which I've heard is really great but have never used. The original Pascal was a one-pass teaching compiler so anybody who thinks the language is good obviously doesn't code for his day job. The rest of the Wirth-originated languages are just him trying to fix the screwups he made in his original designs and for his groupies just like Apple fanboys will always buy Macs and iPhones even when they're all looks and no go. Nobody uses any of the Wirth languages for work. C++? Abomination. Java? For people who can't code and want to write bad code cross platform. Objective C? Never heard of it. ALGOL? I liked ALGOL 68 for academic work but it's not practical for commercial coding. Ada is, and it's much better than C, C++, Java, or almost anything else. It's somewhat ALGOL derived. I hate C and I like ALGOL, PL/I, assembler, FORTRAN and basically anything designed before 1970. Never used Forth but it looks interesting. I wouldn't call it readable and I don't buy the false argument once you know Forth it's readable. There are readable languages like Ada that any programmer can read. I could also claim APL is readable because I can read it. That doesn't make it readable, and it's not. Neither is Forth. Lisp is only a little better. > What is that: irrationality, or hate? ISTM that Forth and Lisp > programmers seem to use the word "feel" alot, instead of "think"... Would > you say this is true? Lisp is interesting but not very practical and they haven't grown it in a controlled way. There are too many quirks and too many ways to do one thing, just because the people involved in developing it are strange and they're afraid to break backward compatability (misplaced concern IMHO). People love or hate their niche languages just like people love or hate sports teams. Why is it ok for sports but not ok for programming? If you say sports is based on opinion and programming is based on facts then you missed the answer. Both are based on opinions because nobody can agree on the facts.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-06-29 06:30 -0400 |
| Message-ID | <iueuu1$v3p$1@speranza.aioe.org> |
| In reply to | #3607 |
"Fritz Wuehler" <fritz@spamexpire-201106.rodent.frell.theremailer.net> wrote in message news:1e406776cc6779c8ac4f6231c24dbffa@msgid.frell.theremailer.net... > "Rod Pemberton" <do_not_have@noavailemail.cmm> wrote: > > > "Real Hackers have also known, for a while, that C and C++ are not > > appropriate for most programs that don't need to do arbitrary > > bit-fiddling." > > > > Wow, some people just truly hate C don't they? > > Yes, we do. But what you quoted doesn't sound hateful to me, maybe you're > projecting? ;-) > Hmm... psychological term... Another clue to your true identity? IMO, unlikely... Well, I took the statement to be hateful. Here's a breakdown. C [is] not appropriate <-- intentional put down of language as a whole not appropriate for most programs <-- false claim that C is utterly useless in regards to programming that don't need to do arbitrary bit-fiddling <-- belittling of C's very powerful HLL capabilities Basically, that statement puts C on the same level as Brainfuck. I.e., it's hateful. > > I guess belittling a successful HLL language is one way to make your > > unwise decision to use an another unpopular, unsuccessful one seem less > > grating. > > [...] How popular or > successful a language (implementation) is has nothing to do > with how good it is. If you had only said "popular", I'd agree. > How does popularity relate to how good something is? Not at all. > I agree. See, you only used "popular" here. > C and C++ are not HLL. You really ought to know better. > Hateful ... > C isn't ALGOL derived more than any HLL with control structures is ALGOL > derived. That is way too general. http://hopl.murdoch.edu.au/showlanguage.prx?exp=2273 http://hopl.murdoch.edu.au/showlanguage.prx?exp=577 > And BASIC has nothing to do with ALGOL at all. http://hopl.murdoch.edu.au/showlanguage.prx?exp=176 Are you sure? Personally, I'm not familiar with Algol. So, I take HOPL as the definitive perspective. > [ ... ] so anybody who thinks > the [Pascal] language is good > obviously doesn't code for his day job. Although this discussion is suited for comp.lang.misc and not c.l.f., I find that statement from you to be *really* interesting, from a psychological perspective. The entire problem with Pascal is (or was) that it is purely a HLL. There are (or were) no low-level capabilities. C has both, yet you deride it. > ALGOL? I liked ALGOL 68 for academic work but it's not > practical for commercial coding. ... > Ada is, and it's much better than C, C++, Java, or almost > anything else. It's somewhat ALGOL derived. > Ok, Ada question: AIR, Ada is the only major language that does not use zero to represent logical "false", such as used by conditionals. True? Yes, I "got" that you are an "Ada is perfect!" fanboy from the c.l.m. post (you?)... Like I said, there are, what, 3 or 4 of you guys left? ;-) There is another one on comp.lang.c (KT) and another on comp.lang.misc (DAK). Slightly older posts show another on comp.lang.c (EP) as well as comp.programming (J). ISTM, Forth programmers are almost, but not quite, as fanatical as you guys. > I hate C and I like ALGOL, PL/I, assembler, FORTRAN and > basically anything designed before 1970. > It's interesting that you don't like C. C is great. I've probably used a different set of languages than you, but it consistently ranks at the top of my list. As for Ada, I've seen more than a few archived posts that represent Ada as just like C but with stronger type checking. Disagree? As for the PL/1 variant I programmed, it pointed out one serious mistake with C: pass-by-value. Pass-by-reference worked beautifully in PL/1. Pass-by-value was never used, basically. I only had to force pass-by-value twice. Otherwise, I saw no advantage over C. It was just as capable, but no more so. But, that could've been due to it being a non-standard variation. FORTRAN sucked. I *hate* FORTRAN. I've got *NO* pleasant memories in regards to FORTRAN some two decades after the fact. It always surprises me how intense the negative memories are on this language... It's the perfect example of how to *NOT* design a language. > Never used Forth but it looks interesting. I wouldn't > call it readable and I don't buy the false argument once > you know Forth it's readable. I've never programmed in Forth either. I am implementing an interpreter for it. At this point, I think one _must_ implement their own version to understand some of the concepts. The fact that the Forth community uses non-standard language, i.e., non Comp. Sci. language, for everything, obscures how much of the functionality works. The fact that not much seems to be well documented as to implementation of Forth does so also. You (or some other remailer dude ...) may have seen my c.l.m. post discussing how it works using normal terminology. > There are readable languages > like Ada that any programmer can read. AIR, I once read that about COBOL ... > Lisp is only a little better. > I heard this from a hobbyist LISP programmer once: "Lost In Stupid Parenthesis". It's a common joke, but no joke that he told it to me. He loved it at first, hated it later. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Chris Hinsley <chris.hinsley@gmail.com> |
|---|---|
| Date | 2011-06-29 13:49 +0100 |
| Message-ID | <2011062913490647947-chrishinsley@gmailcom> |
| In reply to | #3622 |
> I've never programmed in Forth either. I am implementing an interpreter for > it. At this point, I think one _must_ implement their own version to > understand some of the concepts. The fact that the Forth community uses > non-standard language, i.e., non Comp. Sci. language, for everything, > obscures how much of the functionality works. The fact that not much seems > to be well documented as to implementation of Forth does so also. You (or > some other remailer dude ...) may have seen my c.l.m. post discussing how it > works using normal terminology. Rob, can you post a link to your description. I'd quite like to read that. I think I get how Forth works, but another way of looking at it could be good. Chris
[toc] | [prev] | [next] | [standalone]
| From | Chris Hinsley <chris.hinsley@gmail.com> |
|---|---|
| Date | 2011-06-29 14:02 +0100 |
| Message-ID | <2011062914020762838-chrishinsley@gmailcom> |
| In reply to | #3626 |
On 2011-06-29 13:49:06 +0100, Chris Hinsley said: >> >> I've never programmed in Forth either. I am implementing an interpreter for >> it. At this point, I think one _must_ implement their own version to >> understand some of the concepts. The fact that the Forth community uses >> non-standard language, i.e., non Comp. Sci. language, for everything, >> obscures how much of the functionality works. The fact that not much seems >> to be well documented as to implementation of Forth does so also. You (or >> some other remailer dude ...) may have seen my c.l.m. post discussing how it >> works using normal terminology. > > Rob, can you post a link to your description. I'd quite like to read > that. I think I get how Forth works, but another way of looking at it > could be good. > > Chris Sorry 'Rod', typo. Chris
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-06-29 18:16 -0400 |
| Message-ID | <iug8ag$b51$1@speranza.aioe.org> |
| In reply to | #3626 |
"Chris Hinsley" <chris.hinsley@gmail.com> wrote in message news:2011062913490647947-chrishinsley@gmailcom... > > Rod, can you post a link to your description. I'd quite like to read > that. I think I get how Forth works, but another way of looking at it > could be good. > Bottom paragraph: http://groups.google.com/group/comp.lang.misc/msg/16a9b1e59e0056e2 RP
[toc] | [prev] | [next] | [standalone]
| From | Nomen Nescio <nobody@dizum.com> |
|---|---|
| Date | 2011-06-29 15:45 +0200 |
| Message-ID | <cfd41c943985a7a68fb6f35ae07dd02b@dizum.com> |
| In reply to | #3622 |
> Well, I took the statement to be hateful. Here's a breakdown. > > C [is] not appropriate > <-- intentional put down of language as a whole Put down? Value judgement? Statement of fact? I don't get that wrapped up in it. Maybe I would if I wrote C compilers. I read it as "not a good choice" in the author's opinion. I didn't read the link btw, only your post. > not appropriate for most programs > <-- false claim that C is utterly useless in regards to programming Depends on what the author thinks most programs do and where they run. If he thinks they run on mainframes (probably not valid) then true, C isn't appropriate in most cases. If he is talking about mini computers, again, C isn't on the radar. If he is talking about PC's running Windows I don't know but I guess he would be wrong. If he is talking about PC's running Linux or Unix then he's definitely wrong. So sue him LOL. Who cares? But hateful? No. Maybe he just believes there are better languages for the kind of code he writes, or better general purpose languages for the code he thinks is most written. > that don't need to do arbitrary bit-fiddling > <-- belittling of C's very powerful HLL capabilities I don't think C has any powerful HLL capabilities but you would know better than me about that since you like and use it and I hate it and don't use it. Mostly I hate it because it's ugly (personal value judgement) and the operators are confusing and overloaded for the sake of terseness. I consider that a mistake. I guess I could use the preprocessor and clean up some of what I think is so hideous (those endless ugly braces etc) but it would still be C and I still wouldn't like it or the people who like it or the people who wrote it. It's not my kind of people. No offense, because I enjoy reading your posts but most other C people I could live without. > Basically, that statement puts C on the same level as Brainfuck. I.e., > it's hateful. As a Brainfuck fan, I resent that remark ;-). I didn't read the statement that way at all. I figure he means why play around with stuff like malloc/calloc and free and low-level abstractions when modern languages make it easy for idiots to write bad code faster than ever before. Garbage collection, classes (yeah I know C++ is really C) all that stuff makes life fun for guys born after 1990 and anything older than that sucks. Who cares. > > [...] How popular or > > successful a language (implementation) is has nothing to do > > with how good it is. > > If you had only said "popular", I'd agree. Why? C is successful because it was used to write two major, bad operating systems. If you want to write code on those systems then you need to use C because all the header files and system calls are set up for C. If you look at the IBM mainframe the operating system is written in assembler. All the header files and system calls are in assembler. If you want to use C on a mainframe you cannot physically write system code. At all. Assembler is the best choice on that platform. Is it popular or successful? There yes, elsewhere no. It all depends what we are discussing. > > How does popularity relate to how good something is? Not at all. > > > > I agree. See, you only used "popular" here. > > > C and C++ are not HLL. You really ought to know better. > > > > Hateful ... Not intentional! > > C isn't ALGOL derived more than any HLL with control structures is ALGOL > > derived. That is way too general. > http://hopl.murdoch.edu.au/showlanguage.prx?exp=2273 > http://hopl.murdoch.edu.au/showlanguage.prx?exp=577 > > > And BASIC has nothing to do with ALGOL at all. > http://hopl.murdoch.edu.au/showlanguage.prx?exp=176 > > Are you sure? Personally, I'm not familiar with Algol. So, I take HOPL > as the definitive perspective. Yes, quite sure. I am not going to look at those links because I really don't care what they say. I used ALGOL68 on two platforms and if anything is like ALGOL it's PL/I and Pascal to some degree. BASIC has no resemblance to ALGOL at all. C doesn't either, like I said unless you consider any language with control structures (if/end if while/do while etc) ALGOL derived. If you do then almost every HLL qualifies except original COBOL. Even later COBOL and FORTRAN would qualify. That does not make any sense. > > [ ... ] so anybody who thinks > > the [Pascal] language is good > > obviously doesn't code for his day job. > > Although this discussion is suited for comp.lang.misc and not c.l.f., I > find that statement from you to be *really* interesting, from a > psychological perspective. The entire problem with Pascal is (or was) > that it is purely a HLL. There are (or were) no low-level capabilities. > C has both, yet you deride it. The problems with Pascal are as I said, it is a one-pass teaching compiler. It generates crap code. It was never intended to be used in production, like most of what Wirth put out there. AFAIK Turbo Pascal does have low level facilities but again I am not sure. The other thing I don't like about Pascal is Wirth. He and Dijkstra fucked up generations of programmers with their unfounded anti-COBOL spewage and blind hatred of GOTO's. Some of the worst code ever written is thanks to those two assholes. Their stuff is good on paper but it falls over in production. The problems for me with C are not whether it's an HLL or not (it's not). I prefer assembler so you can't say I have anything against low level languages. I guess in NIX C is ok but I don't write code in NIX because it's a crap OS. In my context C is a solution looking for a problem. On other platforms it's a high level assembler. > Ok, Ada question: AIR, Ada is the only major language that does not use zero > to represent logical "false", such as used by conditionals. True? AFAIK, no. I believe COBOL, PL/I, and maybe even ALGOL68 use false for false. 0 does not compute. I think that would be true of any typed language unless you have implicit conversions. Many of them do, but many of them don't do implicit conversions for boolean. You should check me on that because I haven't done anything in HLL recently. > Yes, I "got" that you are an "Ada is perfect!" fanboy from the c.l.m. post > (you?)... I don't think so. It's got problems, especially the post 95 versions but it's a very nice language. > Like I said, there are, what, 3 or 4 of you guys left? ;-) Ada? I'm not an Ada guy. They have a niche. I have no idea how many people it is but there is more than one company surviving by selling Ada compilers so there has to be some market. It should be used more widely. > It's interesting that you don't like C. C is great. I've probably used a > different set of languages than you, but it consistently ranks at the top of > my list. I think it gets back to what platform(s) you code on most. My comments aren't really relevant for most people since almost none of my coding is on Intel and almost everyone elses is. One of the reasons I never spent much time coding on PC's is I don't like C. > As for Ada, I've seen more than a few archived posts that represent Ada as > just like C but with stronger type checking. Disagree? No, it's a lot different. In a way, all algebraic languages with control structures are similar but that's where it ends. Ada use English like COBOL (your point taken further on) and after you get the hang of the structure I think it's much more attractive to look at and read than C and that's important to me. Ada offers a pretty nice list of features built into the language instead of providing them through libraries so it's more coherent and one-piece feeling than C. Examples: exceptions, storage management, tasking, etc. are all Ada language features. They are not add ons or library calls. That makes Ada very portable, in my tiny experience even more portable than C. People who love C won't like Ada because C is terse and overloads operators and Ada makes you spell stuff out because the compiler and build system is designed to insure that you write what you mean. When you do it should be pretty close to working. > As for the PL/1 variant I programmed, it pointed out one serious mistake > with C: pass-by-value. Pass-by-reference worked beautifully in PL/1. > Pass-by-value was never used, basically. I only had to force pass-by-value > twice. Otherwise, I saw no advantage over C. It was just as capable, but > no more so. But, that could've been due to it being a non-standard > variation. I haven't used it in a long time but it's a nice language, again with many features built in rather than added on as library calls. IBM puts out a super nice optimizing compiler, it's been improved for decades. One main advantage to PL/I over C is how PL/I handles strings, but since I believe you are a fan of null terminated strings you probably won't agree. PL/I avoids the whole issue of buffer overruns on string operations since it knows the length of the source and target and will positively not blow off the end of a string. That's pretty important for any serious code. I know, the C guys take responsibility for themselves and that is good but in reality they write an awful lot of crap code. I'm not saying PL/I coders don't, mostly because there aren't a whole lot of them around anymore, but PL/I is a better language than C in my opinion and certainly on the mainframe. Elsewhere it would depend on the implementation, but it's a very nice language with almost no downside. > FORTRAN sucked. I *hate* FORTRAN. I've got *NO* pleasant memories in > regards to FORTRAN some two decades after the fact. It always surprises me > how intense the negative memories are on this language... It's the perfect > example of how to *NOT* design a language. I think it's perfect for what it's for just like COBOL is perfect for what it's for. If you try to use it for something it's not designed to do, both of them fall over quickly. > I've never programmed in Forth either. I am implementing an interpreter for > it. At this point, I think one _must_ implement their own version to > understand some of the concepts. The fact that the Forth community uses > non-standard language, i.e., non Comp. Sci. language, for everything, > obscures how much of the functionality works. The fact that not much seems > to be well documented as to implementation of Forth does so also. You (or > some other remailer dude ...) may have seen my c.l.m. post discussing how it > works using normal terminology. It's an interesting topic. I follow the ng just because of how odd it is, and how much the users like it. > > > There are readable languages > > like Ada that any programmer can read. > > AIR, I once read that about COBOL ... That's true, I should have included it. COBOL can be very readable to the point of picking things up really fast. Like anything else it's not impervious to idiots but when used by a competent person coding a solution to a business problem like doing financial reports or moving money etc. there's nothing better. On the mainframe anyway. > > Lisp is only a little better. > > > > I heard this from a hobbyist LISP programmer once: "Lost In Stupid > Parenthesis". It's a common joke, but no joke that he told it to me. He > loved it at first, hated it later. I got to where I can read it now but it's just too quirky. Kind of makes me think the people developing the new standards can't let go of old baggage and just take the good and throw out the bad and call it something else. It's been around so long it has sentimental value like an old pair of jeans. They may be ripped and patched and stained but when they come out of the wash nothing fits better. I wanted to like it but since I have no history with it, I decided for me it's not worth it.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-06-29 19:45 -0400 |
| Message-ID | <iugdh4$ljb$1@speranza.aioe.org> |
| In reply to | #3628 |
"Nomen Nescio" <nobody@dizum.com> wrote in message news:cfd41c943985a7a68fb6f35ae07dd02b@dizum.com... > > [C's] operators are confusing and overloaded for the sake of terseness. & and * are "overloaded." Two #defines and you've taken care of the "issue" ... All you need do is to come up with some syntax you like. I've seen C code, using preprocessor and #defines to change sytnax, that looks like BASIC, Pascal, etc. > I consider that a mistake. It's very minimal, so, why? There are other more serious language issues with C, mostly related to parsing. Er... Did you mean the overloading or the terseness is a mistake? I originally took that to mean overloading was a mistake, but I now think you meant terseness is a mistake ... Why? > hideous (those endless ugly braces etc) What would you prefer? Blocked BEGIN END? Is that any clearer? How do you group items or code together? That's an issue with all languages. Forth has : and ; to do that. > If you look at the IBM mainframe the operating system is written in > assembler. Has any operating system written in assembly been ported to another platform? (No, or very few...) Has any operating system written in C been ported to another platform? (Yes, many...) Assembly code "dies". It's affixed to the specific processor in use. I learned that decades ago. HLL code survives. It's not dependent on a specific processor. > All the header files and system calls are in assembler. If you > want to use C on a mainframe you cannot physically write system > code. At all "At all" is a bit of an extreme claim. The GCCMVS project (Paul Edwards) ported GCC to MVS. I don't know much about MVS, but I assume it was written in assembly. AIUI, it's a mainframe OS by IBM. So, it probably did what you claim cannot be done "at all". DOS is also written in assembly. DJGPP (GCC port) for DOS does just what you claim cannot be done. http://gccmvs.sourceforge.net/ > [Wirth] and Dijkstra fucked up generations of programmers > with their [...] blind hatred of GOTO's. Line-oriented BASIC was the only place GOTOs are needed. As for C, there is no need for them whatsoever. Use of GOTOs in C usually indicate a program has a structural issue of some sort: too many nested functions, functions too large, programmer unfamiliar with coding techniques such as fall-through or status variables, etc. They can always be eliminated, usually without any additional overhead, albeit sometimes with difficulty. Of course, they are still needed for porting code, or for code generated by code. > I prefer assembler so you can't say I have anything against > low level languages. There are problems with assembler: the code "dies", it's not as easily maintained, and it's harder to use variables, struct's, etc. I saw this with 6502 and even x86 (DOS). Look at the mountains and mountains of DOS code that is still available to this day. It made DOS great, but it's also all "dead": no source, difficult to update or modify, difficult to debug, etc. > Ada? I'm not an Ada guy. They have a niche. I have no idea how many people > it is but there is more than one company surviving by selling Ada > compilers so there has to be some market. It should be used more widely. > Ada is a US Gov't requirement for some projects. > One of the reasons I never spent much > time coding on PC's is I don't like C. > It's got assembly. It's got a half-dozen assemblers for it. NASM is a decent assembler for it. > One main advantage to PL/I over C is how PL/I handles strings, > but since I believe you are a fan of null terminated strings you > probably won't agree. I don't agree. I lived through the "counted strings" era and saw the numerous issues with them. Nul-terminated strings put an end to those problems, many of which I mentioned here recently. > PL/I avoids the whole issue of buffer overruns on string operations > since it knows the length of the source and target and will positively > not blow off the end of a string. > One disadvantage versus many ... > That's pretty important for any serious code. > Today, C has routines now that fix such problems. Forth also had numerous such "blow-up" situations. I'm not as familiar with ANS, so I can't say Forth still "has" them ... > > FORTRAN sucked. > > I think it's perfect for what it's for [...] > "... everything has a purpose or place ..." Psychologically, I'd guess your MBTI type indicates you seek: harmony (NF) ... > COBOL [..] when used by a competent person coding a solution > to a business problem like doing financial reports or moving money > etc. there's nothing better. On the mainframe anyway. > Well, the PL/1 variant I used was used for a RT OLTP application. IMO, C would've been a better solution. I think it would've been much easier to maintain and be more flexible. However, their base of programmers, consultants, and management were all PL/1 skilled. They had considered porting their application to C to lower their programmer salary costs. AIUI, the manager was unfamiliar with C and believed attempting to manage C code and C programmers wouldn't be wise (probably quite a bit of "job security" in there too... when you get payed big $ to play fantasy football all day while your underlings work, one likes to protect that). Management was also concerned about having C programmers, even skilled ones, who were not very familiar with their codebase, having to program it. They couldn't figure out a solution to the issue of not having around programmers experienced or skilled with their codebase. So, that never happened, AFAIK. I.e., they weren't willing to pay for PL/1 consultants to train the C programmers after a port, and they weren't willing to "retrain" in-house PL/1 programmers for C. A few, like me, already knew C. I suspect staying with PL/1 cost them much in dollars. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Elko T <nono.black.elko@gmail.com> |
|---|---|
| Date | 2011-06-29 22:08 -0400 |
| Message-ID | <iuglrm$96e$1@dont-email.me> |
| In reply to | #3657 |
Rod Pemberton wrote: > "Nomen Nescio" <nobody@dizum.com> wrote in message > >> One main advantage to PL/I over C is how PL/I handles strings, >> but since I believe you are a fan of null terminated strings you >> probably won't agree. > > I don't agree. I lived through the "counted strings" era and saw > the numerous issues with them. Nul-terminated strings put an > end to those problems, many of which I mentioned here recently. I have no issue with most of what you say, but this statement is truly bizarre. Zero-terminated strings are the biggest drawback, bug and even enormity of the languages that use them. They have no redeeming qualities I can think of (would you please list at least one positive?), and the drawbacks I can produce off the top of my head (and there're no doubt many others), are: - lack of security - inefficient string manipulation - violation of the principle of separation of the metadata from the data. Any data structure whose description is obtained by parsing "magic" tokens that are not part of the normal data, is conceptually suspect. You say you mentioned issues with counted strings. What could they possibly be? Do you have a link to your post? -- No, no, you can't e-mail me with the nono.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-06-30 10:07 -0400 |
| Message-ID | <iui00n$5s3$1@speranza.aioe.org> |
| In reply to | #3660 |
"Elko T" <nono.black.elko@gmail.com> wrote in message news:iuglrm$96e$1@dont-email.me... > Rod Pemberton wrote: > > "Nomen Nescio" <nobody@dizum.com> wrote in message > > > >> One main advantage to PL/I over C is how PL/I handles strings, > >> but since I believe you are a fan of null terminated strings you > >> probably won't agree. > > > > I don't agree. I lived through the "counted strings" era and saw > > the numerous issues with them. Nul-terminated strings put an > > end to those problems, many of which I mentioned here recently. Actually, it seems, NN said "null terminated strings". I mistook that for NUL-terminated strings. "Null terminated strings" are something else entirely in the C context, nowadays. Null in C is not a character value anymore. It was prior to ANSI standards. Modern C's null is a pointer. So, no I don't like null terminated strings. > I have no issue with most of what you say, but this statement is > truly bizarre. > Ok. > Zero-terminated strings are the biggest drawback Zero-terminated might be perfectly valid description for NUL-terminated strings for some languages. FYI, that's not so for C. In C, strings are not zero terminated. In C, zero is a value for an integer or character. In C, strings are "all bits zero" terminated. This is a "byte" in C, or multiple bytes, and not a character. Simply put, a C "byte" is an address unit(s) as large, or larger, than a character's size in bits. If strings were zero terminated in C, an ASCII or EBCDIC NUL would suffice to terminate the string. Syntactically, that's how you terminate strings in C, you use a NUL character: '\0'. However, to comply with the C specifications, C must clear the bits for the entire string terminator "byte" with '\0', not just the bits used for the character. This is an issue if C bytes and characters are of different sizes in bits. > Zero-terminated strings are the biggest drawback, bug > and even enormity of the languages that use them. They have no > redeeming qualities I can think of (would you please list at least one > positive?), and the drawbacks I can produce off the top of my head > (and there're no doubt many others), are: > > - lack of security How is this any different than counted strings? I.e., I suspect you have some example(s) which to you qualify as "lack of security," such as missing terminators? As I said, C today has functions which fix many of the serious string issues. All one needs to do is use them. Problem solved. The C compiler places termintors on all known strings automatically. So, it shouldn't be a serious issue. It's really only an issue when strings are constructed from characters, or strings are broken up into sub-strings, *and* someone is using the older functions which aren't safe *and* the programmer forgets to terminate the string. A bunch of stuff has to go wrong. Counted strings can result in erroneous code too. The count can be wrong for the string. That can lead to a number of problems: storage that's not free'd, storage that shouldn't have been free'd, wrong text output, etc. String storage that's not free'd because of an incorrect count value is a memory leak. Storage that shouldn't have been free'd can lead to data corruption or program crashes. If the count is short, the text output is truncated. What if that happens on an choice-based input prompt? If the count is too long, it can emit unintentional text characters, such as control characters which could shift the character set on terminals and terminal emulators. Some control sequences may even block keyboard input. Counted strings also do not resolve the issues with string lengths causing overflow and underflows when copying. They have the exact same issues as terminated strings in regards to copying. Also see issues in the links you asked for, which are at the bottom. > - inefficient string manipulation How so? The string length is almost never needed. Loop until terminator found. That's good for copying, printing, moving strings. Search for a character, insert NUL. That's good for substrings etc. When the string length is needed, the string should be terminated and can be counted. If you want to be safer, without using safe string functions, you can automatically insert a NUL in the last character position of the string. You know the string length. It's in the declaration or malloc() call. > - violation of the principle of separation of the metadata from the > data. Any data structure whose description is obtained by parsing > "magic" tokens that are not part of the normal data, is conceptually > suspect. > Why is that important? Isn't "locality of reference" preferred? (Don't link me to Wikipedia on those. Both "metadata" and "locality of reference" are there.) How do you explain integers, floats, structs, unions, and the count for counted strings, etc? Integers and floats have no "metadata" at runtime. How do you separate data from not-present metadata? Structs and unions have lots of "metadata" for their addressing of elements that the user in most languages doesn't have access to, i.e., hidden. AISI, the count for counted strings is a "'magic' token that [is] not part of the normal data" either, assuming the string is the "normal data". Well, it's not a "token" per se, but it's still nearby somewhere, stored at a "magic" location. The "magic" location has no user accessable metadata telling the user the size of the location or the location. But, both must be known by the user to be used. I.e., it's what a few people around here having been calling "carnal knowledge" of a language or "fruits of the forbidden tree of knowledge", etc. > You say you mentioned issues with counted strings. What could they > possibly be? Do you have a link to your post? > http://groups.google.com/group/comp.lang.forth/msg/9bd0c7d06b2c68a8 http://groups.google.com/group/comp.lang.forth/msg/fe585a620e28486b http://groups.google.com/group/comp.lang.forth/msg/642828bbd8b1addb Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | coos haak <chforth@hccnet.nl> |
|---|---|
| Date | 2011-06-30 20:44 +0200 |
| Message-ID | <1a73g46n856zh.x5mniy2k430v.dlg@40tude.net> |
| In reply to | #3670 |
Op Thu, 30 Jun 2011 10:07:29 -0400 schreef Rod Pemberton: <snip> > Zero-terminated might be perfectly valid description for NUL-terminated > strings for some languages. FYI, that's not so for C. > > In C, strings are not zero terminated. In C, zero is a value for an integer > or character. In C, strings are "all bits zero" terminated. This is a > "byte" in C, or multiple bytes, and not a character. Simply put, a C "byte" > is an address unit(s) as large, or larger, than a character's size in bits. > If strings were zero terminated in C, an ASCII or EBCDIC NUL would suffice > to terminate the string. Syntactically, that's how you terminate strings in > C, you use a NUL character: '\0'. However, to comply with the C > specifications, C must clear the bits for the entire string terminator > "byte" with '\0', not just the bits used for the character. This is an > issue if C bytes and characters are of different sizes in bits. What about paragraph 2 of N1548 5.2.1 Character sets: In a character constant or string literal, members of the execution character set shall be represented by corresponding members of the source character set or by escape sequences consisting of the backslash \ followed by one or more characters. A byte with all bits set to 0, called the null character, shall exist in the basic execution character set; it is used to terminate a character string. So a string is terminated with a null byte (or character). -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-06-30 18:08 -0400 |
| Message-ID | <iuis64$cek$1@speranza.aioe.org> |
| In reply to | #3674 |
"coos haak" <chforth@hccnet.nl> wrote in message news:1a73g46n856zh.x5mniy2k430v.dlg@40tude.net... > Op Thu, 30 Jun 2011 10:07:29 -0400 schreef Rod Pemberton: > > <snip> > > Zero-terminated might be perfectly valid description for NUL-terminated > > strings for some languages. FYI, that's not so for C. > > > > In C, strings are not zero terminated. In C, zero is a value for an integer > > or character. In C, strings are "all bits zero" terminated. This is a > > "byte" in C, or multiple bytes, and not a character. Simply put, a C "byte" > > is an address unit(s) as large, or larger, than a character's size in bits. > > If strings were zero terminated in C, an ASCII or EBCDIC NUL would suffice > > to terminate the string. Syntactically, that's how you terminate strings in > > C, you use a NUL character: '\0'. However, to comply with the C > > specifications, C must clear the bits for the entire string terminator > > "byte" with '\0', not just the bits used for the character. This is an > > issue if C bytes and characters are of different sizes in bits. > > What about paragraph 2 of N1548 5.2.1 Character sets: > In a character constant or string literal, members of the execution > character set shall be represented by corresponding members of the source > character set or by escape sequences consisting of the backslash \ followed > by one or more characters. A byte with all bits set to 0, called the null > character, shall exist in the basic execution character set; it is used to > terminate a character string. > > So a string is terminated with a null byte Yes. > (or character). > No. It's *called* the "nulll character". The emphasis is on called. It's not a character. It's a byte. A byte must be at least the same size as a character. But, a byte can be larger. That's the critical distinction. ISTM, that those who cite this section as a claim that it's a character instead of a byte associate "called" with "is" instead of with "named". You must not be reading all articles here. I mentioned this recently with some others. They cited the same thing and argued about it's meaning too. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Elko T <nono.black.elko@gmail.com> |
|---|---|
| Date | 2011-06-30 20:07 -0400 |
| Subject | Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <iuj34p$4gt$1@dont-email.me> |
| In reply to | #3670 |
I see. As you say in one of the old posts that you kindly provided, too much C, indeed. In short, all your assertions, both pro null-terminated/NUL-terminated (z-strings) and against counted strings (c-strings), are mostly wrong. Let's start with efficiency. I claim, that without exception, *any* operation on counted strings is more efficient than when the length is unknown a priori and has to be determined from the contents. - outputting: z-strings need a program loop that examines each character in turn, always. Depending on how output is implemented in the particular environment, with c-strings it can be a single machine language instruction - REPNZ MOVSB, or LDIR / OTIR; and even in the cases where the OS expects character by character calls, it is still cheaper to do the loop using a counting instruction like LOOPNZ or DJNZ, rather than explicitly reading *and* testing every byte. - copying: even worse; mostly single machine language instructions for c-strings, and there's no OS overhead for each byte, that would mask the advantage in the outputting case. Add to that the fact that if you need to allocate the memory for the copy of the string, you need to read the string all over *twice* - the first time to count to see how much memory to allocate, and the second time to do the actual copy. - concatenation: same thing. If you know the lengths beforehand, you can allocate the total first, and then do the efficient moves (or resize the first string if appending in place, etc.) With z-strings, you need to scan through at least one of them twice, and through both of them once. In contrast, with c-strings, if appending in place, you don't need to touch the first string at all, just copy the second. - substrings: with c-strings, you don't need to touch the data at all, if providing a reference - just return the address and count data. With z-strings, you need to scan the source string at least once, no matter what the operation is, to make sure that the desired substring is inside the source string's length; with c-strings this is just a calculation. - parsing: with z-strings, you need two comparisons - is the byte 0, is it what we want. In c-strings, we setup the loop parameters by string length, and make just one comparison inside, leaving the loop when done. Second, let's look at the "errors" of the counted strings. They are mostly of your imagining. How can it happen that the count is wrong? Maybe if *you* program it, but not in a program by anybody who routinely uses counted strings, especially a Forther. Concatenation - just add the lengths, store the result. Substring - same thing; subtract, store. If the initial counts are correct, all string operations will trivially yield correct results. Contrary to your absurd statement in the last of the links you provided, when a c-string is being modified, one does *not* need to re-count. The new size is trivially calculated from the old. You are under the mistaken impression that the string data is somehow manipulated in isolation from the length, while in fact they form a logical tuple (address count), and any correct program manipulates them that way. For ex, when editing in a line buffer, you increase the count when inserting a character, decrease the count when deleting, don't change it when overwriting. There's no need to re-scan or re-count. Third, security. Is it, or isn't it true, that when accepting a stream of data, where the size of the data is determined by its contents, one can overflow any pre-allocated buffer? I agree, however, that this is mostly fixed nowadays (as you point out), by extra overhead in the re-written security conscious C functions. All that needed not be done, had it started with proper counted strings, where all operations are correct from the get-go, and screwups of that nature can't happen. Fourth, metadata. It's part of a bigger problem, actually. Even the counted strings where the count is adjacent to the beginning of the string are flawed, but less so than the z-strings. Ideally, the address/count pair should be in a separate location from the string itself, in a separately allocated memory area. The reason is that if a misbehaving program overwrites it, the size is lost. This is especially troublesome for other data structures. For example arrays, if they store their sizes inside themselves. Or memory managers, that store the size and owner of the allocated memory segment at the beginning of the chunk, at a negative offset to the address they return to the requesting application. Fifth, one more flaw of z-strings that I just remembered - they can't contain the NUL character. :) (Yes, I've had that problem in '94 - a modem needed some NULs as part of its initialization, and the M$ DTE software we were using couldn't output it, even though it accepted any hex values in its custom command strings. I don't remember what exactly we did (maybe wrote a small custom initialization program?), but we had to find a workaround.) Still waiting for just one redeeming quality of z-strings. ;) Rod Pemberton wrote: > "Elko T" <nono.black.elko@gmail.com> wrote in message > news:iuglrm$96e$1@dont-email.me... >> Rod Pemberton wrote: >>> "Nomen Nescio" <nobody@dizum.com> wrote in message >>> >>>> One main advantage to PL/I over C is how PL/I handles strings, >>>> but since I believe you are a fan of null terminated strings you >>>> probably won't agree. >>> I don't agree. I lived through the "counted strings" era and saw >>> the numerous issues with them. Nul-terminated strings put an >>> end to those problems, many of which I mentioned here recently. > > Actually, it seems, NN said "null terminated strings". I mistook that for > NUL-terminated strings. "Null terminated strings" are something else > entirely in the C context, nowadays. Null in C is not a character value > anymore. It was prior to ANSI standards. Modern C's null is a pointer. > So, no I don't like null terminated strings. > >> I have no issue with most of what you say, but this statement is >> truly bizarre. >> > > Ok. > >> Zero-terminated strings are the biggest drawback > > Zero-terminated might be perfectly valid description for NUL-terminated > strings for some languages. FYI, that's not so for C. > > In C, strings are not zero terminated. In C, zero is a value for an integer > or character. In C, strings are "all bits zero" terminated. This is a > "byte" in C, or multiple bytes, and not a character. Simply put, a C "byte" > is an address unit(s) as large, or larger, than a character's size in bits. > If strings were zero terminated in C, an ASCII or EBCDIC NUL would suffice > to terminate the string. Syntactically, that's how you terminate strings in > C, you use a NUL character: '\0'. However, to comply with the C > specifications, C must clear the bits for the entire string terminator > "byte" with '\0', not just the bits used for the character. This is an > issue if C bytes and characters are of different sizes in bits. > >> Zero-terminated strings are the biggest drawback, bug >> and even enormity of the languages that use them. They have no >> redeeming qualities I can think of (would you please list at least one >> positive?), and the drawbacks I can produce off the top of my head >> (and there're no doubt many others), are: >> >> - lack of security > > How is this any different than counted strings? I.e., I suspect you have > some example(s) which to you qualify as "lack of security," such as missing > terminators? > > As I said, C today has functions which fix many of the serious string > issues. All one needs to do is use them. Problem solved. The C compiler > places termintors on all known strings automatically. So, it shouldn't be a > serious issue. It's really only an issue when strings are constructed from > characters, or strings are broken up into sub-strings, *and* someone is > using the older functions which aren't safe *and* the programmer forgets to > terminate the string. A bunch of stuff has to go wrong. > > Counted strings can result in erroneous code too. The count can be wrong > for the string. That can lead to a number of problems: storage that's not > free'd, storage that shouldn't have been free'd, wrong text output, etc. > String storage that's not free'd because of an incorrect count value is a > memory leak. Storage that shouldn't have been free'd can lead to data > corruption or program crashes. If the count is short, the text output is > truncated. What if that happens on an choice-based input prompt? If the > count is too long, it can emit unintentional text characters, such as > control characters which could shift the character set on terminals and > terminal emulators. Some control sequences may even block keyboard input. > Counted strings also do not resolve the issues with string lengths causing > overflow and underflows when copying. They have the exact same issues as > terminated strings in regards to copying. Also see issues in the links you > asked for, which are at the bottom. > >> - inefficient string manipulation > > How so? The string length is almost never needed. Loop until terminator > found. That's good for copying, printing, moving strings. Search for a > character, insert NUL. That's good for substrings etc. When the string > length is needed, the string should be terminated and can be counted. If > you want to be safer, without using safe string functions, you can > automatically insert a NUL in the last character position of the string. > You know the string length. It's in the declaration or malloc() call. > >> - violation of the principle of separation of the metadata from the >> data. Any data structure whose description is obtained by parsing >> "magic" tokens that are not part of the normal data, is conceptually >> suspect. >> > > Why is that important? Isn't "locality of reference" preferred? > (Don't link me to Wikipedia on those. Both "metadata" and "locality of > reference" are there.) > > How do you explain integers, floats, structs, unions, and the count for > counted strings, etc? Integers and floats have no "metadata" at runtime. > How do you separate data from not-present metadata? Structs and unions have > lots of "metadata" for their addressing of elements that the user in most > languages doesn't have access to, i.e., hidden. AISI, the count for counted > strings is a "'magic' token that [is] not part of the normal data" either, > assuming the string is the "normal data". Well, it's not a "token" per se, > but it's still nearby somewhere, stored at a "magic" location. The "magic" > location has no user accessable metadata telling the user the size of the > location or the location. But, both must be known by the user to be used. > I.e., it's what a few people around here having been calling "carnal > knowledge" of a language or "fruits of the forbidden tree of knowledge", > etc. > >> You say you mentioned issues with counted strings. What could they >> possibly be? Do you have a link to your post? >> > > http://groups.google.com/group/comp.lang.forth/msg/9bd0c7d06b2c68a8 > http://groups.google.com/group/comp.lang.forth/msg/fe585a620e28486b > http://groups.google.com/group/comp.lang.forth/msg/642828bbd8b1addb -- No, no, you can't e-mail me with the nono.
[toc] | [prev] | [next] | [standalone]
Page 11 of 17 — ← Prev page 1 … 9 10 [11] 12 13 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web