Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #111760 > unrolled thread
| Started by | Kent Tong <kent.tong.mo@gmail.com> |
|---|---|
| First post | 2016-07-22 08:33 -0700 |
| Last post | 2016-07-26 16:31 +0200 |
| Articles | 20 on this page of 258 — 33 participants |
Back to article view | Back to comp.lang.python
Why not allow empty code blocks? Kent Tong <kent.tong.mo@gmail.com> - 2016-07-22 08:33 -0700
Re: Why not allow empty code blocks? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-22 16:44 +0000
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-23 11:49 +1000
Re: Why not allow empty code blocks? Kent Tong <kent.tong.mo@gmail.com> - 2016-07-22 19:06 -0700
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-07-23 14:13 +0300
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-23 21:34 +1000
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-07-23 14:49 +0300
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-23 15:00 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-24 00:19 +1000
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-29 10:58 +0200
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-29 07:14 -0400
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-29 14:15 +0100
Re: Why not allow empty code blocks? Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-29 07:41 -0600
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-29 23:43 +1000
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-29 15:55 +0200
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-30 00:38 +1000
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-29 20:32 +0200
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-30 13:49 +1000
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-08-02 09:31 +0200
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-29 12:28 -0400
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-29 12:20 -0400
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-29 15:46 +0200
Re: Why not allow empty code blocks? Terry Reedy <tjreedy@udel.edu> - 2016-07-29 15:43 -0400
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-29 21:19 +0100
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-07-30 01:01 +0300
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-30 13:35 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 11:15 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 21:25 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 04:39 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 21:49 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 05:11 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 22:22 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 05:31 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 22:44 +1000
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 01:07 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 13:39 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 22:47 +1000
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 22:47 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 13:27 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 22:34 +1000
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 00:58 +1000
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 00:47 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 09:15 -0700
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 09:29 -0700
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 03:53 +1000
Re: Why not allow empty code blocks? Michael Torrie <torriem@gmail.com> - 2016-07-30 12:16 -0600
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-31 13:37 +1200
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 19:34 -0700
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 13:14 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 20:34 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-31 14:12 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 23:42 -0700
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-30 22:10 -0700
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-31 19:39 +1200
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-07-31 10:51 +0300
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-31 01:18 -0700
Re: Why not allow empty code blocks? Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-31 06:51 -0600
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-31 09:23 -0700
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-31 01:14 -0700
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-08-01 03:06 +1000
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-31 10:32 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-31 02:37 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 09:58 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-31 03:15 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 10:48 -0700
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-31 13:45 +1200
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-31 12:17 +1000
Procedures and functions [was Re: Why not allow empty code blocks?] Steven D'Aprano <steve@pearwood.info> - 2016-07-31 13:32 +1000
Re: Procedures and functions [was Re: Why not allow empty code blocks?] "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-31 00:01 -0400
Re: Procedures and functions [was Re: Why not allow empty code blocks?] Steven D'Aprano <steve@pearwood.info> - 2016-07-31 16:40 +1000
Re: Procedures and functions [was Re: Why not allow empty code blocks?] Rustom Mody <rustompmody@gmail.com> - 2016-07-30 23:47 -0700
Re: Procedures and functions [was Re: Why not allow empty code blocks?] Chris Angelico <rosuav@gmail.com> - 2016-07-31 16:55 +1000
Re: Procedures and functions [was Re: Why not allow empty code blocks?] Chris Angelico <rosuav@gmail.com> - 2016-07-31 14:05 +1000
Re: Procedures and functions [was Re: Why not allow empty code blocks?] Random832 <random832@fastmail.com> - 2016-07-31 00:26 -0400
Re: Why not allow empty code blocks? Random832 <random832@fastmail.com> - 2016-07-30 23:51 -0400
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-31 14:21 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 21:22 +0100
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-08-02 12:30 +0200
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-02 05:29 -0700
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-08-03 10:26 +0200
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-03 04:48 -0700
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-08-03 15:09 +0300
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-03 05:23 -0700
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-03 05:27 -0700
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-08-03 15:37 +0300
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-03 05:43 -0700
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-08-03 15:34 +0300
{non sequitur/bad humor} was: Why not allow empty code blocks? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-08-03 18:01 -0400
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 02:43 +1000
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-30 23:06 +1000
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 23:36 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 14:58 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 01:48 +1000
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-31 02:34 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 19:46 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 12:10 +1000
Re: Why not allow empty code blocks? Random832 <random832@fastmail.com> - 2016-07-30 23:41 -0400
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-31 11:18 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-08-01 01:31 +1000
Re: Why not allow empty code blocks? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-07-31 12:39 -0400
Re: Why not allow empty code blocks? bart4858@gmail.com - 2016-07-31 17:11 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-01 10:21 +1000
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-31 17:55 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-01 11:10 +1000
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-31 19:09 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-01 12:14 +1000
Re: Why not allow empty code blocks? bart4858@gmail.com - 2016-08-01 00:55 -0700
Re: Why not allow empty code blocks? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-07-31 22:08 -0400
Re: Why not allow empty code blocks? Gene Heskett <gheskett@shentel.net> - 2016-07-31 21:29 -0400
Debugging (was Re: Why not allow empty code blocks?) Terry Reedy <tjreedy@udel.edu> - 2016-07-31 14:58 -0400
Re: Debugging (was Re: Why not allow empty code blocks?) BartC <bc@freeuk.com> - 2016-08-02 12:05 +0100
Re: Debugging (was Re: Why not allow empty code blocks?) Chris Angelico <rosuav@gmail.com> - 2016-08-03 00:58 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) BartC <bc@freeuk.com> - 2016-08-02 18:12 +0100
Re: Debugging (was Re: Why not allow empty code blocks?) Steven D'Aprano <steve+python@pearwood.info> - 2016-08-03 03:57 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) BartC <bc@freeuk.com> - 2016-08-02 20:14 +0100
Re: Debugging (was Re: Why not allow empty code blocks?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-08-03 15:43 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) BartC <bc@freeuk.com> - 2016-08-03 11:16 +0100
Re: Debugging (was Re: Why not allow empty code blocks?) Chris Angelico <rosuav@gmail.com> - 2016-08-03 23:18 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) Steven D'Aprano <steve+python@pearwood.info> - 2016-08-04 13:23 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) BartC <bc@freeuk.com> - 2016-08-04 10:13 +0100
Re: Debugging (was Re: Why not allow empty code blocks?) Chris Angelico <rosuav@gmail.com> - 2016-08-04 19:39 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-08-04 19:38 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) Terry Reedy <tjreedy@udel.edu> - 2016-08-04 14:37 -0400
Re: Debugging (was Re: Why not allow empty code blocks?) Chris Angelico <rosuav@gmail.com> - 2016-08-05 04:54 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) Chris Angelico <rosuav@gmail.com> - 2016-08-03 05:18 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) Christian Gollwitzer <auriocus@gmx.de> - 2016-08-02 21:55 +0200
Re: Debugging (was Re: Why not allow empty code blocks?) Chris Angelico <rosuav@gmail.com> - 2016-08-03 06:50 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) Terry Reedy <tjreedy@udel.edu> - 2016-08-02 17:27 -0400
Re: Debugging (was Re: Why not allow empty code blocks?) Paul Rubin <no.email@nospam.invalid> - 2016-08-02 14:54 -0700
Re: Debugging (was Re: Why not allow empty code blocks?) BartC <bc@freeuk.com> - 2016-08-02 23:38 +0100
Re: Debugging (was Re: Why not allow empty code blocks?) Chris Angelico <rosuav@gmail.com> - 2016-08-01 05:03 +1000
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-31 15:12 +1200
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-31 14:07 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 15:16 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 02:08 +1000
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 02:10 +1000
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-31 15:10 +1200
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-30 10:39 -0400
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 16:14 +0100
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-30 13:11 -0400
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 19:15 +0100
Re: Why not allow empty code blocks? Gordon Levi <gordon@address.invalid> - 2016-08-01 00:25 +1000
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-31 11:53 -0400
Re: Why not allow empty code blocks? Gordon Levi <gordon@address.invalid> - 2016-08-03 23:38 +1000
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-31 12:04 -0400
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-31 09:27 -0700
Re: Why not allow empty code blocks? Gordon Levi <gordon@address.invalid> - 2016-08-02 01:30 +1000
Using valid emails "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-08-01 12:05 -0400
Re: Using valid emails Chris Angelico <rosuav@gmail.com> - 2016-08-02 02:22 +1000
Re: Using valid emails Marko Rauhamaa <marko@pacujo.net> - 2016-08-01 22:16 +0300
Re: Using valid emails "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-08-01 12:40 -0400
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-08-01 22:14 +0300
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-07-31 19:41 +0300
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-08-01 03:22 +1000
Re: Why not allow empty code blocks? "Jan Erik Moström" <lists@mostrom.pp.se> - 2016-07-31 20:58 +0200
Re: Why not allow empty code blocks? Michael Torrie <torriem@gmail.com> - 2016-07-31 14:01 -0600
Re: Why not allow empty code blocks? bart4858@gmail.com - 2016-07-31 16:43 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-01 09:49 +1000
Re: Why not allow empty code blocks? bart4858@gmail.com - 2016-07-31 17:21 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-01 10:33 +1000
Re: Why not allow empty code blocks? bart4858@gmail.com - 2016-08-01 01:05 -0700
Re: Why not allow empty code blocks? alister <alister.ware@ntlworld.com> - 2016-08-01 09:50 +0000
Re: Why not allow empty code blocks? bart4858@gmail.com - 2016-08-01 06:26 -0700
Re: Why not allow empty code blocks? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-08-01 20:12 +1000
Re: Why not allow empty code blocks? bart4858@gmail.com - 2016-08-01 06:19 -0700
Re: Why not allow empty code blocks? bartc <bart4858@gmail.com> - 2016-08-01 13:22 -0700
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-02 06:28 -0700
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-02 17:56 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve+python@pearwood.info> - 2016-08-03 03:54 +1000
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-03 05:10 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-02 20:19 +0100
Re: Why not allow empty code blocks? Grant Edwards <grant.b.edwards@gmail.com> - 2016-08-02 19:38 +0000
Re: Why not allow empty code blocks? lists@juliensalort.org (Julien Salort) - 2016-08-02 21:45 +0200
Re: Why not allow empty code blocks? Steven D'Aprano <steve+python@pearwood.info> - 2016-08-03 03:50 +1000
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-08-02 12:22 -0700
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-03 03:02 -0700
Re: Why not allow empty code blocks? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-08-03 18:58 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-03 05:16 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-03 22:36 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-03 14:04 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-03 23:25 +1000
Re: Why not allow empty code blocks? Grant Edwards <grant.b.edwards@gmail.com> - 2016-08-03 14:06 +0000
Re: Why not allow empty code blocks? alister <alister.ware@ntlworld.com> - 2016-08-03 20:40 +0000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-03 14:23 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-03 23:31 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-03 19:52 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-04 06:12 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-03 21:53 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-04 07:39 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-03 23:21 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-04 08:31 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-04 00:51 +0100
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-08-03 16:25 -0700
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-04 00:48 +0100
Re: Why not allow empty code blocks? alister <alister.ware@ntlworld.com> - 2016-08-01 09:40 +0000
Using valid emails "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-08-01 12:32 -0400
Re: Using valid emails Michael Torrie <torriem@gmail.com> - 2016-08-01 12:38 -0600
Re: Using valid emails "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-08-01 15:27 -0400
Re: Why not allow empty code blocks? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-28 20:01 +0000
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-29 06:11 +1000
Detecting the trivial can be non-trivial (was Why not allow empty code blocks?) Rustom Mody <rustompmody@gmail.com> - 2016-07-23 05:28 -0700
Re: Detecting the trivial can be non-trivial (was Why not allow empty code blocks?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-24 11:15 +0100
Re: Detecting the trivial can be non-trivial (was Why not allow empty code blocks?) Rustom Mody <rustompmody@gmail.com> - 2016-07-24 07:49 -0700
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-23 08:29 -0400
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-07-23 16:13 +0300
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-23 09:54 -0400
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-23 15:06 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-24 01:55 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 11:35 +0100
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 11:45 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-24 21:27 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 14:09 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-24 23:24 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 15:05 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-25 00:32 +1000
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-25 12:40 +1200
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-25 02:14 +0100
Re: Why not allow empty code blocks? Ben Finney <ben+python@benfinney.id.au> - 2016-07-25 11:45 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-25 09:54 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-26 03:02 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-25 10:11 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-26 03:26 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-25 19:43 -0700
Re: Why not allow empty code blocks? Michael Torrie <torriem@gmail.com> - 2016-07-24 20:48 -0600
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-25 13:12 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-24 20:20 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-25 13:28 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-24 20:46 -0700
Re: Why not allow empty code blocks? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-25 17:20 +1000
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-25 14:27 +1000
Re: Why not allow empty code blocks? neceros@gmail.com - 2016-07-24 11:27 -0700
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-24 22:17 +1000
Re: Why not allow empty code blocks? Joel Goldstick <joel.goldstick@gmail.com> - 2016-07-24 08:28 -0400
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-24 22:48 +1000
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-24 23:38 +1000
Re: Why not allow empty code blocks? Marco Sulla <mail.python.org@marco.sulla.e4ward.com> - 2016-07-24 15:11 +0200
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 15:44 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-25 00:51 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 19:14 +0100
Re: Why not allow empty code blocks? Jonathan Hayward <jonathan.hayward@pobox.com> - 2016-07-24 13:34 -0500
Re: Why not allow empty code blocks? alister <alister.ware@ntlworld.com> - 2016-07-24 18:52 +0000
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-25 05:00 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 21:03 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-25 07:08 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 23:13 +0100
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-25 13:04 +1200
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-25 10:44 +0100
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-26 19:21 +1200
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-07-26 10:56 +0300
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-26 20:35 +1200
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-26 11:11 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-25 12:37 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-25 11:39 +0100
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-26 19:23 +1200
Re: Why not allow empty code blocks? Random832 <random832@fastmail.com> - 2016-07-25 10:36 -0400
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-25 18:33 +0100
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-24 17:56 -0700
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-26 16:31 +0200
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
| From | bart4858@gmail.com |
|---|---|
| Date | 2016-08-01 01:05 -0700 |
| Message-ID | <3d96c99b-72fa-439c-93b4-abef2b9fd8a0@googlegroups.com> |
| In reply to | #112159 |
On Monday, 1 August 2016 01:33:37 UTC+1, Chris Angelico wrote: > On Mon, Aug 1, 2016 at 10:21 AM, <bart4858@gmail.com> wrote: > > However I do 'drive' as I've been programming for decades. And I can have an opinion about a model of car that I don't normally drive. An opinion which you might well not get from someone who drives that model for a living. > > > > So've I, but I don't try to tell the Scheme folks that they need to > change the language. You can have an opinion - but it doesn't make it > worth anything. OK. But I both drive, and build my own cars! You think that my nearly 30 years' experience of designing interpreted languages and writing fast bytecode interpreters doesn't make my opinions have any more merit, that's fine. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | alister <alister.ware@ntlworld.com> |
|---|---|
| Date | 2016-08-01 09:50 +0000 |
| Message-ID | <kXEnz.4737$es5.3425@fx34.am4> |
| In reply to | #112172 |
On Mon, 01 Aug 2016 01:05:53 -0700, bart4858 wrote: > On Monday, 1 August 2016 01:33:37 UTC+1, Chris Angelico wrote: >> On Mon, Aug 1, 2016 at 10:21 AM, <bart4858@gmail.com> wrote: > >> > However I do 'drive' as I've been programming for decades. And I can >> > have an opinion about a model of car that I don't normally drive. An >> > opinion which you might well not get from someone who drives that >> > model for a living. >> > >> > >> So've I, but I don't try to tell the Scheme folks that they need to >> change the language. You can have an opinion - but it doesn't make it >> worth anything. > > OK. But I both drive, and build my own cars! > > You think that my nearly 30 years' experience of designing interpreted > languages and writing fast bytecode interpreters doesn't make my > opinions have any more merit, that's fine. Actually the more you make these claims the more I think you are suffering from NIH (Not Invented Here) syndrome. there is another poster on the F1 group who initially made comments along the lines "Maybe Ferrari should employ me" at first they were taken as tongue in cheek until it became apparent he actually believed them. without any significant user base for any of your invented Languages I would suggest they are nothing more than toys* & instead of thinking "my designs are much better" you would be better to use the approach "that's not how I would have done it what, do they know that I am missing" * to be fare even a toy language is beyond my own meagre abilities. -- Worst Month of 1981 for Downhill Skiing: August. The lift lines are the shortest, though. -- Steve Rubenstein
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2016-08-01 06:26 -0700 |
| Message-ID | <65021545-28c4-4e7d-9d92-a6739fc13d93@googlegroups.com> |
| In reply to | #112176 |
On Monday, 1 August 2016 10:50:20 UTC+1, alister wrote: > Actually the more you make these claims the more I think you are > suffering from NIH (Not Invented Here) syndrome. That's not surprising. I started out developing hardware such as microprocessor boards and video displays. My languages started as streamlined tools that I needed for my job. Commercial products at the time were poor Chris pointed out (and also expensive). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2016-08-01 20:12 +1000 |
| Message-ID | <579f207f$0$11110$c3e8da3@news.astraweb.com> |
| In reply to | #112172 |
On Monday 01 August 2016 18:05, bart4858@gmail.com wrote: > You think that my nearly 30 years' experience of designing interpreted > languages and writing fast bytecode interpreters doesn't make my opinions > have any more merit, that's fine. If you are the only one who has ever seen or used these fast bytecode interpreters, then they might as well not exist, in which case, no, your opinions have no merit. No offense intended Bart, but for all we know every single one of your benchmarks are faked, your interpreters are buggy pieces of garbage, and for all your self-promotion, your code wouldn't survive more than six seconds of peer review. -- Steve
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2016-08-01 06:19 -0700 |
| Message-ID | <2214300f-92ca-48e2-ae2c-2fd7a27ffc06@googlegroups.com> |
| In reply to | #112177 |
On Monday, 1 August 2016 11:12:30 UTC+1, Steven D'Aprano wrote: > On Monday 01 August 2016 18:05, bart4858@gmail.com wrote: > > > You think that my nearly 30 years' experience of designing interpreted > > languages and writing fast bytecode interpreters doesn't make my opinions > > have any more merit, that's fine. > > If you are the only one who has ever seen or used these fast bytecode > interpreters, then they might as well not exist, in which case, no, your > opinions have no merit. > > No offense intended Bart, but for all we know every single one of your > benchmarks are faked, your interpreters are buggy pieces of garbage, and for > all your self-promotion, your code wouldn't survive more than six seconds of > peer review. Sure. I can't pretend the implementations are wonderful. But I think the ideas are good and they would make fine little languages when seriously implementated. Not that it bothers me because I've sold $millions of software implemented 100% in these 'toy' languages (and versions from 20+ years ago too). (If you want to try something out, go to: https://github.com/bartg/langs Download the interpreter pcc32.exe (a Windows binary, but I remember it seemed to work under 'wine' in Linux). And test program jpeg.bc (a binary bytecode file). Run as pcc32 jpeg file.jpg (or as wine pcc32 jpeg file.jpg). If it works, the image will be displayed. The sourcecode for jpeg.bc (its main module) is in jpeg.q. (jpeg.m is a separate static language version.) I don't have the Python version to hand, but that has been posted in the past (and which you have already commented on!). There is also qq.bc, a bytecode compiler. Run as pcc32 qq filename.q, but I haven't provided libraries so only simple programs can be compiled. (Note that pcc32.exe is not accelerated; that version is 2-3 times faster on this test.) I'm working at the moment on a version that works like Python, directly on source code rather than precompiled bytecode. But it needs to be fast enough so I'm aiming for a 1M lines per second compilation speed; I've managed 0.8-0.9Mpls so far on real applications.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bart4858@gmail.com> |
|---|---|
| Date | 2016-08-01 13:22 -0700 |
| Message-ID | <01f3d086-ba00-43c6-8f86-712fb940b054@googlegroups.com> |
| In reply to | #112177 |
On Monday, 1 August 2016 11:12:30 UTC+1, Steven D'Aprano wrote: > On Monday 01 August 2016 18:05, bart4858@gmail.com wrote: > No offense intended Bart, but for all we know every single one of your > benchmarks are faked, your interpreters are buggy pieces of garbage, and for > all your self-promotion I missed this comment earlier on, but I can't really let it go. I never promote any actual product of mine, but I might bring in ideas from them to illustrate a point or a different way of doing things (although that usually falls on deaf as the language is already perfect. As is C, funnily enough.) Only a couple of times have links been given (after creating them to make it possible) when people have accused me of making things up! But I'm not selling anything. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-08-02 06:28 -0700 |
| Message-ID | <e5810fc7-93a3-4ed0-acd0-1192d1385048@googlegroups.com> |
| In reply to | #112195 |
> I think the real reason is not willing to admit that the language lacks > something that could actually be useful, and especially not to an > upstart on usenet who is not even an expert in that language. And earlier you said: > But dedicated forms (even if they just map to 'while' or 'for') wouldn't > hurt. Syntax is free after all, and it's about expressing exactly what > you mean. You are in effect repeating yourself What you are saying would be true if syntax were free — or even cheap However a case may be made that syntax is one of the most wastefully expensive hobby with which computer scientists waste their time First some… <background> Turing-completeness or Church-Turing thesis says that all languages are the same — identical power. And yet in the last ½ century of computers there is as chaotic a babel of computer languages as there is of natural languages in the last 5000 years of human history. IOW that L₁ and L₂ are same in power means that the difference is entirely in syntax Of course we need to understand syntax as - super-superficial — lexical - superficial — CFG grammar — what is normally called ‘syntax’ - deeper but still static aspects eg type structure More at http://blog.languager.org/2015/04/poverty-universality-structure-0.html [Heh! I see it is related to another thread of yours!] </background> Ok lets agree we need both C (like) and Python (like) languages because they serve very different purposes. But do we really need Python and Perl and Ruby and Tcl and Pike and …? Or bash and zsh and ksh and powershell and …? Now lets try to quantify the cost of this bedlam gcc is 15 million lines of code. How much is that in man-years? I guess somewhere between 100 and 1000 But that’s just the compiler One needs a development environment. Java folks tend towards eclipse C# towards Visual Studio Evidently eclipse is nearly 50 million lines of code(!!) https://dzone.com/articles/eclipse-indigo-released One may expect VS to be of comparable order. And as the ide-divide points out, choosing a fancy language implies choosing an underpowered IDE And vice-versa: http://blog.osteele.com/posts/2004/11/ides/ This is exactly the cost I am talking about: If people did not spend their time inventing newer and newer languages — especially when that is just fiddling with syntax — the IDEs and other necessary tooling that is needed for practical usage would have the chance to develop So to amplify Steven’s > No offense intended Bart, but for all we know every single one of your > benchmarks are faked, your interpreters are buggy pieces of garbage, and for > all your self-promotion If your language(s) gain enough traction as to contribute something beyond the language — Great! All power to you! But if its just one more (misshapen) brick in the babel of computer languages then you are an anti-social element, of course not on a big scale like a terrorist¹ but let us say of the scale of someone who litters public spaces ¹ Stupid word! Those who use it should also be considered anti-social
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-02 17:56 +0100 |
| Message-ID | <nnqjb7$v66$1@dont-email.me> |
| In reply to | #112219 |
On 02/08/2016 14:28, Rustom Mody wrote: >> I think the real reason is not willing to admit that the language lacks >> something that could actually be useful, and especially not to an >> upstart on usenet who is not even an expert in that language. > However a case may be made that syntax is one of the most wastefully expensive > hobby with which computer scientists waste their time > > First some… > <background> > Turing-completeness or Church-Turing thesis says that all languages are the same — > identical power. And yet in the last ½ century of computers there is as chaotic a babel > of computer languages as there is of natural languages in the last 5000 years of human > history. Who's talking about creating a new language? I was discussing tweaking an existing one. > Ok lets agree we need both C (like) and Python (like) languages > because they serve very different purposes. > > But do we really need Python and Perl and Ruby and Tcl and Pike and …? > Or bash and zsh and ksh and powershell and …? You really want my opinion? For my own use, I could use 2 or 3 languages at different levels: 1 C-like 2 Intermediate 3 Python-like 4 Scripting (I have my own versions of 1 and 2, but not of 3.) Other people will have different lists, and with different languages. C++ is quite popular (but so complex that it is unusable IMO). Others might like the discipline of Ada. A few might like to code in Haskell. Or it might need a small footprint. Or work on certain platforms. Or needs to be fast.. So there are diverse requirements. But I agree we don't need thousands of languages, each inventing different syntax too. Perhaps someone can just invent or choose syntax styles A, B and C and a language can adopt one of those (this is the approach I use actually). > Now lets try to quantify the cost of this bedlam > > gcc is 15 million lines of code. How much is that in man-years? > I guess somewhere between 100 and 1000 > But that’s just the compiler Well, it also supports lots of targets, which accounts for some of the size. But gcc would still be huge. > One needs a development environment. > Java folks tend towards eclipse > C# towards Visual Studio > > Evidently eclipse is nearly 50 million lines of code(!!) OK. 50 million lines. Keep that in mind. > https://dzone.com/articles/eclipse-indigo-released > > One may expect VS to be of comparable order. I heard that VS comprises 1.5 million *files*. And a full compile takes 60 *hours*. So the shift has been from evolving languages to horrendously large and complex development *tools*. (And I expect that next they will eliminate languages altogether. All you need is some way of specifying a sequence of calls to library functions and sprinkling around some control statements; it could be drag-and-drop with a GUI display of the program flow.) I don't have any interest in that. 1.5M files or 50M lines for a tool cannot possibly be right. And I believe in using a traditional language with textual syntax and not being overly dependent on extraneous tools so massive that they completely the language they are supposed to work with. > And as the ide-divide points out, choosing a fancy language implies choosing an underpowered IDE > And vice-versa: > http://blog.osteele.com/posts/2004/11/ides/ > > This is exactly the cost I am talking about: > If people did not spend their time inventing newer and newer > languages — especially when that is just fiddling with syntax — > the IDEs and other necessary tooling that is needed for practical > usage would have the chance to develop Your figures suggest the opposite! So people spend time creating huge bloated IDEs instead of writing 100 lines of a parser so that other people can avoid writing 'for i in range(N):' millions of times instead of 'for N:' or 'repeat N:'. > So to amplify Steven’s >> No offense intended Bart, but for all we know every single one of your >> benchmarks are faked, your interpreters are buggy pieces of garbage, and for >> all your self-promotion > > If your language(s) gain enough traction as to contribute something beyond the > language — Great! All power to you! > > But if its just one more (misshapen) brick in the babel of > computer languages then you are an anti-social element, Anti-social, yes. When I was doing most of my stuff in 80s, my 'brick' was the only one. It didn't need to fit to anything else! However such a brick can still be tremendously useful in the 2010s, just like a bicycle can be in city traffic. It's small, manageable, understandable, and can go anywhere. And it can be very nippy. (Very nippy indeed. If I say how long it takes me to build my compiler from scratch - for my C replacement language - no one would believe me.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+python@pearwood.info> |
|---|---|
| Date | 2016-08-03 03:54 +1000 |
| Message-ID | <57a0de5d$0$1620$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112234 |
On Wed, 3 Aug 2016 02:56 am, BartC wrote: > (And I expect that next they will eliminate languages altogether. All > you need is some way of specifying a sequence of calls to library > functions and sprinkling around some control statements; That would be called "a language". > it could be > drag-and-drop with a GUI display of the program flow.) It could be, but won't be. Outside of a very few tiny niches, including Squeak which is designed for children, such user-interfaces are far too cumbersome to ever get widespread use. But for limited niches, like generating GUIs, form designers, or even assembling regular expressions, sure, why not? -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-08-03 05:10 +1000 |
| Message-ID | <mailman.123.1470165011.6033.python-list@python.org> |
| In reply to | #112240 |
On Wed, Aug 3, 2016 at 3:54 AM, Steven D'Aprano
<steve+python@pearwood.info> wrote:
> On Wed, 3 Aug 2016 02:56 am, BartC wrote:
>
>> (And I expect that next they will eliminate languages altogether. All
>> you need is some way of specifying a sequence of calls to library
>> functions and sprinkling around some control statements;
>
> That would be called "a language".
:)
>> it could be
>> drag-and-drop with a GUI display of the program flow.)
>
> It could be, but won't be. Outside of a very few tiny niches, including
> Squeak which is designed for children, such user-interfaces are far too
> cumbersome to ever get widespread use.
>
> But for limited niches, like generating GUIs, form designers, or even
> assembling regular expressions, sure, why not?
They do exist, and IMO they're languages just as much as textual ones
are. You don't eliminate computer language by switching to a GUI
drag-and-drop system than you eliminate human language by using hand
signs. In fact, deaf people generally communicate using something
called "{American,Korean,Australian,...} Sign Language" - it's not
called "American Way of Talking Without Talking Or Using Language".
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-02 20:19 +0100 |
| Message-ID | <nnqrnk$tp3$1@dont-email.me> |
| In reply to | #112240 |
On 02/08/2016 18:54, Steven D'Aprano wrote: > On Wed, 3 Aug 2016 02:56 am, BartC wrote: > >> (And I expect that next they will eliminate languages altogether. All >> you need is some way of specifying a sequence of calls to library >> functions and sprinkling around some control statements; > > That would be called "a language". No, it wouldn't be given its own identity. And it probably couldn't be used without that specific tool. It would be more like a file format, if the details are even exposed when the format is proprietary. A traditional language exists as text and can be stored as plain text. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <grant.b.edwards@gmail.com> |
|---|---|
| Date | 2016-08-02 19:38 +0000 |
| Message-ID | <mailman.126.1470166735.6033.python-list@python.org> |
| In reply to | #112247 |
On 2016-08-02, BartC <bc@freeuk.com> wrote:
> On 02/08/2016 18:54, Steven D'Aprano wrote:
>> On Wed, 3 Aug 2016 02:56 am, BartC wrote:
>>
>>> (And I expect that next they will eliminate languages altogether. All
>>> you need is some way of specifying a sequence of calls to library
>>> functions and sprinkling around some control statements;
>>
>> That would be called "a language".
>
> No, it wouldn't be given its own identity.
Sure it would. How else could you talk about it or differentiate it
from something else?
> And it probably couldn't be used without that specific tool.
You mean like a compiler or interpreter?
> It would be more like a file format,
So you'd have to define a combination of syntax and semantics where
you specify what elements are allowed in what order/context and what
they mean in various combinations?
It turns out there's a English word for that.
It's called a "language".
> if the details are even exposed when the format is proprietary.
>
> A traditional language exists as text and can be stored as plain
> text.
Many languages are plain text. Some aren't.
--
Grant Edwards grant.b.edwards Yow! If elected, Zippy
at pledges to each and every
gmail.com American a 55-year-old
houseboy ...
[toc] | [prev] | [next] | [standalone]
| From | lists@juliensalort.org (Julien Salort) |
|---|---|
| Date | 2016-08-02 21:45 +0200 |
| Message-ID | <1mrdj0d.hm4ccb1ikbvgmN%lists@juliensalort.org> |
| In reply to | #112240 |
Steven D'Aprano <steve+python@pearwood.info> wrote: > It could be, but won't be. Outside of a very few tiny niches, including > Squeak which is designed for children, such user-interfaces are far too > cumbersome to ever get widespread use. Unfortunately, many people use LabView in my field... even for sufficiently complex programs for it to become totally unreadable. -- Julien Salort Entia non sunt multiplicanda praeter necessitatem http://www.juliensalort.org
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+python@pearwood.info> |
|---|---|
| Date | 2016-08-03 03:50 +1000 |
| Message-ID | <57a0dd53$0$1620$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112219 |
On Tue, 2 Aug 2016 11:28 pm, Rustom Mody wrote:
>> I think the real reason is not willing to admit that the language lacks
>> something that could actually be useful, and especially not to an
>> upstart on usenet who is not even an expert in that language.
>
> And earlier you said:
>
>> But dedicated forms (even if they just map to 'while' or 'for') wouldn't
>> hurt. Syntax is free after all, and it's about expressing exactly what
>> you mean.
>
> You are in effect repeating yourself
> What you are saying would be true if syntax were free — or even cheap
>
> However a case may be made that syntax is one of the most wastefully
> expensive hobby with which computer scientists waste their time
>
> First some…
> <background>
> Turing-completeness or Church-Turing thesis says that all languages are
> the same — identical power.
That depends on how you define the power of a language.
Earlier, you wrote:
"Ok Python is better than Java is better than C++
But it cannot stand up to scheme as a teaching language"
So you are aware that languages are *not* the same. Languages have more or
less "power", where power is defined (rather fuzzily) as the expressiveness
of the language, how easy it is for the programmer to read, write and
maintain code, how efficient/fast you can implement it, etc. The power of a
language is rather subjective, but we all surely acknowledge that adding
new features to a language can make it more powerful:
- Python 1.5 is less powerful than Python 3.5;
- Fortran 77 is less powerful than Fortran 95.
We acknowledge that languages can differ in power too:
- 1970s BASIC is less powerful than C;
- COBOL is less powerful than Scheme.
Google for the Blub Paradox, by Paul Graham, for more information.
So language are not all the same, and can differ in power.
So what does the Church-Turing thesis say? It doesn't say anything about
language power in the above sense. Language power is a rather subjective,
fuzzy, non-linear measure, which is why language flame wars will never end.
What the C-T thesis talks about is *computability*. *What* can you compute,
not necessarily how easy it is to compute it. And there is a hierarchy of
language "power" in this sense.
(A Turing Machine can do anything that Conway's Game Of Life can do, but is
easier to program; assembly language is easier still, and Javascript even
more so.)
A good discussion of the Church-Turing thesis can be found in Chapter 13 of
Hofstadter's "Gödel, Escher, Bach". He introduces three languages that
differ in computing power in the computability sense: Bloop, Floop and
Gloop.
- Bloop can perform calculations that predictably terminate; that is, it
can do any calculation which can be performed by a primitive recursive
function;
- Floop can perform calculations that have no upper bounds to the number
of steps needed; that is, it can perform *unbounded* potentially
non-terminating loops; another way of saying this is that terminating
Floop programs are general recursive, and non-terminating Floop
programs are partial recursive;
- Gloop can perform calculations which never terminate in Floop, and
do so in a finite number of steps.
In simple terms, Bloop has for-loops; Floop has while-loops; and Gloop,
well, Gloop is magical and probably doesn't exist. "Gloop is a myth" is one
way of putting the Church-Turing Thesis.
Hofstadter gives three equivalent ways to state the C-T Thesis:
(1) What is human-computable is machine-computable;
(2) What is machine-computable is Floop-computable;
(3) What is human-computable is Floop-computable (i.e., general or
partial recursive).
Most interesting and useful languages are equivalent to Floop, but there are
languages (potential, if not actual) which are equivalent only to Bloop.
Pure regular expressions, for example, are not Turing Complete: they can
only perform calculations which are primitive recursive.
The Halting Problem is easily solved for Bloop languages: they always halt.
> And yet in the last ½ century of computers
> there is as chaotic a babel of computer languages as there is of natural
> languages in the last 5000 years of human history.
I think that human languages have been *far* more complicated. The history
of English *alone* is probably as complex and chaotic as that of
programming languages. My guess is that once you go down to the level of
regional dialects, there are more variants of English alone than
programming languages have existed. In some sense, virtually every village
and hamlet in Great Britain has had its own version of English (and
sometimes not even mutually comprehensible).
> IOW that L₁ and L₂ are same in power means that the difference is entirely
> in syntax
But as we've seen, syntax can make a HUGE difference to power in the sense
of expressiveness, maintainability of code, readability, efficiency of the
programmer, and even efficiency of the interpreter. Conway's Game of Life
is Turing Complete. Would you rather use Python, or Game of Life? BrainF*ck
or Javascript?
[...]
> But do we really need Python and Perl and Ruby and Tcl and Pike and …?
> Or bash and zsh and ksh and powershell and …?
Yes.
Programming languages are tools for solving problems, but they are also
tools for thinking about problems and communicating between people. There
are many ways to think about problems, many ways to communicate between
them, and no clear or practical way to decide what is "best". That's why
language flame-wars occur!
With no objective way to decide which language to use, there will always be
people who are dissatisfied with the existing languages they have available
to them. Look at yourself: you are dissatisfied with Python's lack of
support for Unicode operators. But that's "just syntax". And yet you are
convinced that Python would be a better language if it supported more
mathematical notation with Unicode operators.
And perhaps you are right.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-08-02 12:22 -0700 |
| Message-ID | <87a8gv562h.fsf@jester.gateway.pace.com> |
| In reply to | #112239 |
Steven D'Aprano <steve+python@pearwood.info> writes: > where power is defined (rather fuzzily) as the expressiveness > of the language, how easy it is for the programmer to read, write and > maintain code, how efficient/fast you can implement it, etc. Scheme guru Matthias Felleisen takes a stab at a precise definition here (though it's pointy-headed theory that I don't understand that well): http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4656 > The Halting Problem is easily solved for Bloop languages: they always > halt. If Bloop is powerful enough to "solve the halting problem" as you describe, that gives it capabilities that Turing-complete languages lack. (Of course it also loses some capabilities). Some of the advantages of Turing-incomplete languages (plus why they are less constraining than it might sound) are discussed here: http://www.jucs.org/doi?doi=10.3217/jucs-010-07-0751 > But as we've seen, syntax can make a HUGE difference to power in the > sense of expressiveness, maintainability of code, readability, > efficiency of the programmer, and even efficiency of the > interpreter. Conway's Game of Life is Turing Complete. Would you > rather use Python, or Game of Life? BrainF*ck or Javascript? That's completely different than Python vs Scheme, where you can basically transliterate Python to Scheme by converting indentation structure into parentheses and a few other things like that. Felleisen's paper (linked above) has a deeper take on what expressiveness really means. I've programmed lots of Python and a fair amount of Lisp, and Lisp's parentheses really aren't that big a deal. Python is more pleasant than Lisp for me these days, mostly because its built-in datatypes and the standard libraries are a better match for today's programming than Lisp, which is somewhat stuck in the 1980s. Clojure (a new Lisp dialect with modern capabilities, currently only on the JVM) may be the way forward for Lisp, parentheses and all. > you are convinced that Python would be a better language if it > supported more mathematical notation with Unicode operators. Haskell and Agda both support this. It isn't used much in Haskell but Agda users actually use it, and the Emacs editing mode for Agda has special stuff to make it easier. It's probably more useful in Agda since Agda programs deal more with actual mathematical proofs.
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-08-03 03:02 -0700 |
| Message-ID | <890bc5c3-969e-4ac6-a9a0-c2c56caff72c@googlegroups.com> |
| In reply to | #112248 |
On Wednesday, August 3, 2016 at 12:53:02 AM UTC+5:30, Paul Rubin wrote: > Steven D'Aprano writes: > > where power is defined (rather fuzzily) as the expressiveness > > of the language, how easy it is for the programmer to read, write and > > maintain code, how efficient/fast you can implement it, etc. > > Scheme guru Matthias Felleisen takes a stab at a precise definition here > (though it's pointy-headed theory that I don't understand that well): > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4656 Lovely! Thanks for that! [Been preparing some notes/thoughts for a Theory of CS course — v drafty : https://bitbucket.org/rustom/toc/wiki/themes — and had listed this (topic) as one of the big open problems] > > > The Halting Problem is easily solved for Bloop languages: they always > > halt. > > If Bloop is powerful enough to "solve the halting problem" as you > describe, that gives it capabilities that Turing-complete languages > lack. (Of course it also loses some capabilities). Some of the > advantages of Turing-incomplete languages (plus why they are less > constraining than it might sound) are discussed here: > > http://www.jucs.org/doi?doi=10.3217/jucs-010-07-0751 And thanks for that as well I had seen that decades ago but forgot waht to look for
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2016-08-03 18:58 +1000 |
| Message-ID | <57a1b23c$0$11093$c3e8da3@news.astraweb.com> |
| In reply to | #112248 |
On Wednesday 03 August 2016 05:22, Paul Rubin wrote:
>> The Halting Problem is easily solved for Bloop languages: they always
>> halt.
>
> If Bloop is powerful enough to "solve the halting problem" as you
> describe, that gives it capabilities that Turing-complete languages
> lack. (Of course it also loses some capabilities).
It only solves it in the sense that it isn't capable of looping forever, so
there's never a question of whether or not a Bloop program will halt: they all
do. It doesn't have any capabilities that Floop lacks: Floop can solve any
problem that Bloop can solve, plus problems that Bloop cannot.
In a sense, it's a less extreme version of this:
Me: "I have here a computer which is immune to all computer viruses, malware
and hostile code, now and in the future!"
You: "That's great! Turn it on so we can see how it works."
Me: "Oh, it doesn't turn on. There's no power supply. That was the only way I
could guarantee it wouldn't execute malware: by making sure it couldn't execute
*anything*."
While I suppose it is true that a computer that doesn't run is still a
computer, its an abuse of language to say that it has capabilities that running
computers lack:
- unhackable
- immune to all viruses
- unaffected by power surges
- data storage is 100% reliable, never lose data again
- instantaneous log-off and shutdown
:-)
Floop can certainly give a *partial* solution to the Halting Problem:
- if the code is runnable using Bloop, then it definitely halts;
- if the code is runnable using Floop, then ... maybe it halts?
A sufficiently clever Floop program might be able to analyse Floop code and
recognise many common cases of non-terminating loops. For example, the Floop
equivalent of:
while True:
pass
is clearly non-terminating. There's no mystery about being able to detect that.
But not all code is that straight-forward.
> Some of the
> advantages of Turing-incomplete languages (plus why they are less
> constraining than it might sound) are discussed here:
>
> http://www.jucs.org/doi?doi=10.3217/jucs-010-07-0751
>
>> But as we've seen, syntax can make a HUGE difference to power in the
>> sense of expressiveness, maintainability of code, readability,
>> efficiency of the programmer, and even efficiency of the
>> interpreter. Conway's Game of Life is Turing Complete. Would you
>> rather use Python, or Game of Life? BrainF*ck or Javascript?
>
> That's completely different than Python vs Scheme, where you can
> basically transliterate Python to Scheme by converting indentation
> structure into parentheses and a few other things like that.
I wouldn't say "completely different".
Since GoL, Python, BrainF*uck and Javascript are all Turing Complete, there
must be a way to convert a program in any one to any of the others. One obvious
way to do this is to (for example) write a Javascript interpreter in BrainF*ck.
That demonstrates that anything Javascript can do, BrainF*ck can do too.
Of course, going the other way (BrainF*ck interpreter written in Javascript) is
considerably easier :-)
Python is sometimes described as a Lisp with more sensible syntax, so its not
surprising that it is relatively simple to translate Python to Lisp and visa
versa. It would be harder to translate (say) COBOL code to (say) Smalltalk. But
it is always the case that any program for a Turing Complete language can be
translated into a program for any other Turing Complete language.
It might be *really really really difficult*, inefficient and slow, but its
always possible.
What's *not* possible is to take any Floop program and translate it into Bloop.
There are things Floop can do that Bloop cannot -- Bloop is not Turing
Complete, but Floop is.
--
Steve
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-08-03 05:16 -0700 |
| Message-ID | <28e12b9b-4e9c-4a19-9ca1-74cfca782293@googlegroups.com> |
| In reply to | #112272 |
On Wednesday, August 3, 2016 at 5:11:23 PM UTC+5:30, Steven D'Aprano wrote: > On Wednesday 03 August 2016 05:22, Paul Rubin wrote: > > >> The Halting Problem is easily solved for Bloop languages: they always > >> halt. > > > > If Bloop is powerful enough to "solve the halting problem" as you > > describe, that gives it capabilities that Turing-complete languages > > lack. (Of course it also loses some capabilities). > > It only solves it in the sense that it isn't capable of looping forever, so > there's never a question of whether or not a Bloop program will halt: they all > do. It doesn't have any capabilities that Floop lacks: Floop can solve any > problem that Bloop can solve, plus problems that Bloop cannot. > > In a sense, it's a less extreme version of this: > > Me: "I have here a computer which is immune to all computer viruses, malware > and hostile code, now and in the future!" > > You: "That's great! Turn it on so we can see how it works." > > Me: "Oh, it doesn't turn on. There's no power supply. That was the only way I > could guarantee it wouldn't execute malware: by making sure it couldn't execute > *anything*." > > While I suppose it is true that a computer that doesn't run is still a > computer, its an abuse of language to say that it has capabilities that running > computers lack: > > - unhackable > - immune to all viruses > - unaffected by power surges > - data storage is 100% reliable, never lose data again > - instantaneous log-off and shutdown > > :-) There he comes waddling in… Your cute-n-cudly strawman!! A more realistic analogy would be phones The cellphones we use today often crash The first nokia I used never crashed but could still run out of battery And the round-dial landlines of 30 years ago had not even that problem But correspondingly the functionality: The early landlines could just dial a NUMBER (which you looked up from a dead-tree book) The first cell phones had some rudimentary phone book Nowadays phones do everything a computer can… Including crash!
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-08-03 22:36 +1000 |
| Message-ID | <mailman.140.1470227770.6033.python-list@python.org> |
| In reply to | #112276 |
On Wed, Aug 3, 2016 at 10:16 PM, Rustom Mody <rustompmody@gmail.com> wrote: > There he comes waddling in… Your cute-n-cudly strawman!! > A more realistic analogy would be phones > The cellphones we use today often crash > The first nokia I used never crashed but could still run out of battery > And the round-dial landlines of 30 years ago had not even that problem 1986? Yeah, we had a phone from then (granted, I don't remember much of 1986, but we had the same handsets in the 1990s), and it could run out of battery and lose its phone book. Sorry matey, you just lost the strawman game. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-03 14:04 +0100 |
| Message-ID | <nnsq47$s9p$1@dont-email.me> |
| In reply to | #112282 |
On 03/08/2016 13:36, Chris Angelico wrote: > On Wed, Aug 3, 2016 at 10:16 PM, Rustom Mody <rustompmody@gmail.com> wrote: >> There he comes waddling in… Your cute-n-cudly strawman!! >> A more realistic analogy would be phones >> The cellphones we use today often crash >> The first nokia I used never crashed but could still run out of battery >> And the round-dial landlines of 30 years ago had not even that problem > > 1986? Yeah, we had a phone from then (granted, I don't remember much > of 1986, but we had the same handsets in the 1990s), and it could run > out of battery and lose its phone book. He said landlines. A typical handset would have no battery as it's powered from the line. And does not have need a memory to function. Nor would it suffer from lack of signal. Or credit (if you'd paid the last bill). Or get lost (as it's tethered to the socket). Very clunky technology but it was solid! It only did one thing but it did it incredibly well. -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
Back to top | Article view | comp.lang.python
csiph-web