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 323 — 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 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: 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 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 | 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]
| From | Elko T <nono.black.elko@gmail.com> |
|---|---|
| Date | 2011-06-30 22:12 -0400 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <iujaf7$ftf$1@dont-email.me> |
| In reply to | #3680 |
Elko T wrote: > > Still waiting for just one redeeming quality of z-strings. ;) Actually, you need not bother answering. I read the entire thread referenced below only after I posted my message, while I should have read the entire thread first. There, all your absurd arguments were thoroughly refuted, many with the same arguments that I use. And you still come forward and post a link to where you were totally shown wrong? I have nothing more to say, and don't think you have either. Move along people, nothing to see here. > Rod Pemberton wrote: >> "Elko T" <nono.black.elko@gmail.com> wrote in message >> >>> 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]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-07-01 16:01 -0400 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <iul93i$mhd$1@speranza.aioe.org> |
| In reply to | #3681 |
"Elko T" <nono.black.elko@gmail.com> wrote in message news:iujaf7$ftf$1@dont-email.me... > > I have nothing more to say, and don't think you have either. Move > along people, nothing to see here. > I disagree. Your last post was totally erroneous. I've posted those errors. You failed to understand x86. You don't know what a "c-string" is. You think c-strings don't have many of the same issues as z-strings. You used numerous arguments supporting my position. You used flawed logic. You're beyond my help. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Elko T <nono.black.elko@gmail.com> |
|---|---|
| Date | 2011-07-01 17:59 -0400 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <iulg0a$k6i$1@dont-email.me> |
| In reply to | #3698 |
Rod Pemberton wrote: > "Elko T" <nono.black.elko@gmail.com> wrote in message > news:iujaf7$ftf$1@dont-email.me... >> I have nothing more to say, and don't think you have either. Move >> along people, nothing to see here. >> > > I disagree. Your last post was totally erroneous. I've posted those > errors. You failed to understand x86. You don't know what a "c-string" is. > You think c-strings don't have many of the same issues as z-strings. You > used numerous arguments supporting my position. You used flawed logic. > You're beyond my help. No. *Your* new post is totally erroneous. Have you ever programmed an Intel CPU in assembly? You don't appear to know what its instructions do; for example you appear to think that REPNZ MOVSB repeats until a zero string byte is encountered. Reread your CPU instruction set manual. All the rest of your arguments are like that - either in error, or twisting the truth and making nonsensical assumptions. You have been repeatedly shown wrong - by my post, and by all the people who answered you the previous time. You obviously refuse to learn from your mistakes; so be it. One can't teach the unteachables. -- No, no, you can't e-mail me with the nono.
[toc] | [prev] | [next] | [standalone]
| From | The Beez <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2011-07-01 16:33 -0700 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <a740c33e-b421-4f84-a5fd-9e709dbb9a2d@d14g2000yqb.googlegroups.com> |
| In reply to | #3701 |
On Jul 1, 11:59 pm, Elko T <nono.black.e...@gmail.com> wrote: The only speed penalty is when you fetch a terminated string from memory. Yes, then you have to find the NUL character. When it's on the stack in its addr/count form there is no difference between terminated string or counted strings, since they both have a contiguous text part. Storing a string is not too much of a difference, I guess. Either you first write the count character and then the text part or you first write the text part and then the terminator. If you want to "convert" e.g. a ACCEPT buffer to a terminated string, simply terminate it (if you have the space). You don't have to shift the whole text part one character up to make room for the count. Most of my strings live most of their life as an addr/count string. E.g. all string manipulations (on my system) work on addr/count strings. You don't use variables if you don't have to. We're not doing BASIC here. So, in short, I don't think that on an ANS system (where the addr/ count form is used) the difference is that significant. Of course, somebody will stand up and prove that in the middle of a tight loop counted strings are half a millisecond faster, but IRL? I don't think so. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-07-02 18:37 -0400 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <iuo6lt$1l9$1@speranza.aioe.org> |
| In reply to | #3701 |
"Elko T" <nono.black.elko@gmail.com> wrote in message news:iulg0a$k6i$1@dont-email.me... > > No. *Your* new post is totally erroneous. Wrong. It's not. There is one mistake, due to you... > Have you ever > programmed an Intel CPU in assembly? > Yes, frequently, albeit I prefer C and use it much more often. > You don't appear to know what its > instructions do; for example you appear to think > that REPNZ MOVSB > repeats until a zero string byte is encountered. > *YOU* wrote "REPNZ MOVSB". Take responsibility for your error: incorrect pairing of repeat prefix and instruction. A failure to catch your mistake or trust that you got something correct was my mistake. REPNZ MOVSB wasn't. Yes, I assumed you got the correct combination before I posted, but like everything else in that post, that was wrong too. So, I explained what each of those meant - together. How is that my error? REPNZ means what I said. MOVSB means what I said. Together, it means what I said. Do they work together? Yes. Do they work that way together? Probably not... REPNZ and MOVSB will probably work as REP MOVSB, i.e., c-string only. MS uses incorrect repeat prefix pairings in a number of places their code. Some of their bootloader code is the most well known example. This doesn't change the flaws in your argument regarding c-strings being better suited to assembly versus z-strings. > All the rest of your arguments are like that - either in error, or > twisting the truth and making nonsensical assumptions. Wrong. There is nothing twisted. It's accurate and correct. The only thing that isn't is your mistakes and things derived from them... > You have been > repeatedly shown wrong By whom? When? Not by you... All of your claims were incorrect. I've explained *repeatedly* why you're wrong. > by my post Your post was completely wrong. I showed you where and told you why. What is it that you don't understand? Comprehension, or lack of, real or feigned, seems to be an issue with you. > and by all the people who > answered you the previous time. I reread the thread that I posted links to after your BS claims that I was thoroughly refuted somewhere. I don't see where anyone demonstrated anything incorrect about what I said. > You obviously refuse to learn from your mistakes; so be it. One can't > teach the unteachables. Cute! Recycling my statements about you: "... You used flawed logic. You're beyond my help." It's there. Go back and reread it. Since you didn't realize it, I'll state it very clearly. I'm not the one being taught. That's as politely as I can state the issue. Rod Pemberton
[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