Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #21634 > unrolled thread
| Started by | Kiuhnm <kiuhnm03.4t.yahoo.it> |
|---|---|
| First post | 2012-03-15 00:34 +0100 |
| Last post | 2012-03-18 18:19 +0000 |
| Articles | 20 on this page of 201 — 36 participants |
Back to article view | Back to comp.lang.python
Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 00:34 +0100
Re: Python is readable Arnaud Delobelle <arnodel@gmail.com> - 2012-03-14 23:54 +0000
Re: Python is readable Tony the Tiger <tony@tiger.invalid> - 2012-03-14 19:18 -0500
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-15 11:27 +1100
Re: Python is readable Rick Johnson <rantingrickjohnson@gmail.com> - 2012-03-14 20:02 -0700
Re: Python is readable alex23 <wuwei23@gmail.com> - 2012-03-14 23:23 -0700
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 11:44 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-15 21:50 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 12:27 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-15 22:47 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 12:59 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-15 23:21 +1100
Re: Python is readable Ben Finney <ben+python@benfinney.id.au> - 2012-03-15 23:31 +1100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-15 23:38 +1100
Re: Python is readable Ben Finney <ben+python@benfinney.id.au> - 2012-03-16 00:16 +1100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-16 00:33 +1100
Re: Python is readable Ben Finney <ben+python@benfinney.id.au> - 2012-03-16 00:50 +1100
RE: Python is readable "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-03-15 17:43 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 15:16 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-16 01:29 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 15:37 +0100
Re: Python is readable Roy Smith <roy@panix.com> - 2012-03-15 11:14 -0400
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-16 02:27 +1100
Re: Python is readable Roy Smith <roy@panix.com> - 2012-03-15 11:44 -0400
Re: Python is readable Alec Taylor <alec.taylor6@gmail.com> - 2012-03-16 03:01 +1100
Re: Python is readable Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-03-15 17:41 +0000
Re: Python is readable Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-03-15 12:14 +0100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 12:48 +0100
Re: Python is readable Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-03-15 14:06 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 15:19 +0100
Re: Python is readable Tim Golden <mail@timgolden.me.uk> - 2012-03-15 14:28 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 15:55 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-16 02:08 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 20:40 +0100
Re: Python is readable Michael Torrie <torriem@gmail.com> - 2012-03-15 16:12 -0600
Re: Python is readable Ben Finney <ben+python@benfinney.id.au> - 2012-03-16 09:35 +1100
Re: Python is readable Arnaud Delobelle <arnodel@gmail.com> - 2012-03-15 23:00 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 00:46 +0100
Re: Python is readable Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-03-15 23:58 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 12:41 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 00:15 +0000
Re: Python is readable Ben Finney <ben+python@benfinney.id.au> - 2012-03-16 10:57 +1100
Re: Python is readable Robert Kern <robert.kern@gmail.com> - 2012-03-15 15:13 +0000
Re: Python is readable Serhiy Storchaka <storchaka@gmail.com> - 2012-03-15 21:43 +0200
Re: Python is readable Alec Taylor <alec.taylor6@gmail.com> - 2012-03-16 01:17 +1100
Re: Python is readable Duncan Booth <duncan.booth@invalid.invalid> - 2012-03-15 14:23 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 15:30 +0100
Re: Python is readable Robert Kern <robert.kern@gmail.com> - 2012-03-15 14:43 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 16:18 +0100
Re: Python is readable Michael Torrie <torriem@gmail.com> - 2012-03-15 16:17 -0600
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 00:32 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 03:55 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 13:10 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 16:48 +0000
Re: Python is readable Michael Torrie <torriem@gmail.com> - 2012-03-16 17:39 -0600
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-17 22:22 +0100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-17 20:59 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-18 08:20 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-17 22:28 +0100
Re: Python is readable Michael Torrie <torriem@gmail.com> - 2012-03-17 17:04 -0600
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-19 12:15 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-19 11:57 +0000
Re: Python is readable Ben Finney <ben+python@benfinney.id.au> - 2012-03-18 11:42 +1100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-18 01:36 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-19 12:34 +0100
Re: Python is readable Lie Ryan <lie.1296@gmail.com> - 2012-03-31 16:56 +1100
Re: Python is readable MRAB <python@mrabarnett.plus.com> - 2012-03-31 18:27 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-16 01:48 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 16:05 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-16 02:14 +1100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-15 23:52 +0000
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-16 14:12 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 13:36 +0100
Re: Python is readable Neil Cerutti <neilc@norwich.edu> - 2012-03-16 12:50 +0000
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 13:03 +0000
Re: Python is readable Neil Cerutti <neilc@norwich.edu> - 2012-03-16 13:08 +0000
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 16:28 +0000
Re: Python is readable Neil Cerutti <neilc@norwich.edu> - 2012-03-16 17:53 +0000
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 18:50 +0000
Re: Python is readable Neil Cerutti <neilc@norwich.edu> - 2012-03-16 19:35 +0000
RE: Python is readable "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-03-16 20:04 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-17 21:54 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-18 00:57 +0000
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-18 12:07 +1100
Re: Python is readable Steven D'Aprano <steve+usenet@pearwood.info> - 2012-03-18 02:05 +0000
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-18 13:15 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-21 00:57 +0100
Re: Python is readable Mel Wilson <mwilson@the-wire.com> - 2012-03-16 16:01 -0400
Re: Python is readable Ethan Furman <ethan@stoneleaf.us> - 2012-03-16 13:30 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-17 07:59 +1100
Re: Python is readable Terry Reedy <tjreedy@udel.edu> - 2012-03-17 01:09 -0400
Re: Python is readable Neil Cerutti <neilc@norwich.edu> - 2012-03-19 11:26 +0000
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-19 11:51 +0000
Re: Python is readable Neil Cerutti <neilc@norwich.edu> - 2012-03-19 12:53 +0000
Re: Python is readable Robert Kern <robert.kern@gmail.com> - 2012-03-19 14:38 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-17 21:23 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-18 01:46 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-19 12:44 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-19 15:27 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-21 00:27 +0100
Re: Python is readable Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-03-15 16:41 +0100
Re: Python is readable Duncan Booth <duncan.booth@invalid.invalid> - 2012-03-16 09:30 +0000
Re: Python is readable John Ladasky <ladasky@my-deja.com> - 2012-03-18 14:30 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-19 09:02 +1100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-19 01:23 +0000
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-19 15:33 +1100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-19 13:37 +0000
Re: Python is readable Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-20 12:20 +0000
Re: Python is readable alex23 <wuwei23@gmail.com> - 2012-03-18 20:15 -0700
Re: Python is readable Chris Rebert <clp2@rebertia.com> - 2012-03-18 21:14 -0700
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-20 12:55 -0400
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-20 17:48 +0000
Re: Python is readable Terry Reedy <tjreedy@udel.edu> - 2012-03-20 14:09 -0400
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-20 15:28 -0400
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-21 00:22 +0000
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-20 18:28 -0700
Re: Python is readable Ben Finney <ben+python@benfinney.id.au> - 2012-03-21 13:28 +1100
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-20 19:44 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-21 15:16 +1100
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-20 21:58 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-21 16:40 +1100
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-20 23:52 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-21 17:59 +1100
Re: Python is readable Chris Rebert <clp2@rebertia.com> - 2012-03-21 00:16 -0700
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-21 00:57 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-21 19:15 +1100
Re: Re: Python is readable Evan Driscoll <driscoll@cs.wisc.edu> - 2012-03-21 11:22 -0500
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-21 09:30 -0700
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-21 14:06 -0400
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-21 18:35 -0700
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-22 08:56 +0000
Re: Python is readable (OT) Jon Clements <joncle@googlemail.com> - 2012-03-22 04:18 -0700
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-22 08:47 -0400
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-22 17:18 +0000
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-22 14:26 -0400
Re: Python is readable Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-29 13:44 +0000
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-29 14:37 -0400
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-30 01:42 +0000
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-29 22:26 -0400
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-30 03:36 +0000
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-30 00:38 -0400
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-30 10:47 +0000
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-30 09:46 -0400
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-31 03:20 +1100
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-30 14:15 -0400
Re: Python is readable Neil Cerutti <neilc@norwich.edu> - 2012-03-30 20:30 +0000
Re: Python is readable alex23 <wuwei23@gmail.com> - 2012-04-01 20:38 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-31 05:29 +1100
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-30 15:55 -0400
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-31 07:20 +1100
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-30 22:07 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-04-03 08:06 +1000
Re: Python is readable Dan Sommers <dan@tombstonezero.net> - 2012-03-30 16:51 -0400
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-30 16:58 -0400
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-31 08:45 +1100
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-30 19:01 -0400
Re: Python is readable Terry Reedy <tjreedy@udel.edu> - 2012-03-31 00:03 -0400
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-31 19:05 +1100
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-31 10:43 -0400
Re: Python is readable rusi <rustompmody@gmail.com> - 2012-03-30 11:17 -0700
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-30 09:02 -0700
Re: Python is readable alex23 <wuwei23@gmail.com> - 2012-04-01 20:30 -0700
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-04-01 21:01 -0700
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-29 23:44 -0700
RE: Python is readable "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-03-30 16:40 +0000
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-30 00:27 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-23 06:08 +1100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-23 00:17 +1100
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-22 10:29 -0400
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-22 09:12 -0700
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-22 17:44 +0000
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-22 19:42 -0700
Re: Python is readable rusi <rustompmody@gmail.com> - 2012-03-22 20:20 -0700
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-22 21:16 -0700
Re: Python is readable MRAB <python@mrabarnett.plus.com> - 2012-03-23 04:43 +0000
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-22 23:58 -0700
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-23 00:20 -0400
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-22 08:33 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-23 06:21 +1100
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-22 15:33 -0400
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-23 06:48 +1100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-23 06:49 +1100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-21 23:34 +0000
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-21 17:54 -0700
Re: Python is readable Lie Ryan <lie.1296@gmail.com> - 2012-03-31 17:25 +1100
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-31 09:59 -0700
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-21 00:55 -0400
Re: Python is readable Terry Reedy <tjreedy@udel.edu> - 2012-03-20 16:01 -0400
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-20 16:34 -0400
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-21 00:01 +0000
Re: Python is readable Lie Ryan <lie.1296@gmail.com> - 2012-03-31 17:15 +1100
Re: Python is readable Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-03-15 13:51 -0400
Re: Python is readable Arnaud Delobelle <arnodel@gmail.com> - 2012-03-15 20:54 +0000
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 02:03 +0000
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 01:53 +0000
Re: Python is readable Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-03-16 02:16 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 13:55 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 16:25 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 17:58 +0100
RE: Python is readable "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-03-16 17:01 +0000
Re: Python is readable alister <alister.ware@ntlworld.com> - 2012-03-18 18:19 +0000
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-30 09:02 -0700 |
| Message-ID | <64eb2ae9-b4ec-4acb-92bf-de4a86f0b83c@sv8g2000pbc.googlegroups.com> |
| In reply to | #22378 |
On Mar 30, 3:47 am, Steven D'Aprano <steve +comp.lang.pyt...@pearwood.info> wrote: > If you are being paid to build abstractions in the ivory tower, on the > chance that one in a thousand abstractions turns out to be a game > changer, or just because of a love of pure knowledge, that's great. I > love abstract mathematics too. I read maths in my free time, you won't > find me saying that it is bad or useless or harmful. But does it solve > real problems? > > Well, of course it does, and often in a most surprising places. But > that's because out of the hundred thousand abstractions, we see the > hundred that actually solve concrete problems. The other 99,999 exist > only in forgotten journals, or perhaps the odd book here or there. > Steven, how do you predict which abstractions are going to be useless? There was a time when imaginary numbers were just little toys that the mathematicians played around with in their ivory towers. I mean, really, what possible use could we have for the square root of -1, other than to entertain mathematicians avoiding "real" problems? Now the complex number plane helps us do 3-D math (air traffic control), circuit design (radios, computers), and frequency analysis (telecommunication).
[toc] | [prev] | [next] | [standalone]
| From | alex23 <wuwei23@gmail.com> |
|---|---|
| Date | 2012-04-01 20:30 -0700 |
| Message-ID | <9e42e87d-0836-4260-9031-4f071e269b08@z3g2000pbn.googlegroups.com> |
| In reply to | #22515 |
On Mar 31, 2:02 am, Steve Howell <showel...@yahoo.com> wrote: > Steven, how do you predict which abstractions are going to be useless? A useless abstraction is one that does nothing to simplify a problem *now*: > being so fixated on over-arching abstract > concepts that, far from those abstractions making it easier to solve the > problems they are being paid to solve, they actually make them harder An abstraction is also useless if it's so clever that it isn't readily understandable to an average developer; architecture astronauts don't tend to be big on sticking around to provide ongoing support.
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-04-01 21:01 -0700 |
| Message-ID | <31432272-ea2e-4428-89ca-3c96446bf99c@vy8g2000pbc.googlegroups.com> |
| In reply to | #22528 |
On Apr 1, 8:30 pm, alex23 <wuwe...@gmail.com> wrote: > On Mar 31, 2:02 am, Steve Howell <showel...@yahoo.com> wrote: > > > Steven, how do you predict which abstractions are going to be useless? > > A useless abstraction is one that does nothing to simplify a problem > *now*: That's the very definition of short-sighted thinking. If it doesn't do anything *now*.... > > > being so fixated on over-arching abstract > > concepts that, far from those abstractions making it easier to solve the > > problems they are being paid to solve, they actually make them harder > > An abstraction is also useless if it's so clever that it isn't readily > understandable to an average developer; architecture astronauts don't > tend to be big on sticking around to provide ongoing support. You are careless and sloppy with your quoting here. I didn't say the above; you should give proper attribution.
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-29 23:44 -0700 |
| Message-ID | <7d27d34b-99c3-40f5-a405-c293a2e7d577@to5g2000pbc.googlegroups.com> |
| In reply to | #22375 |
On Mar 29, 9:38 pm, Nathan Rice <nathan.alexander.r...@gmail.com> wrote: > The mathematics of the 20th century, (from the early 30s onward) tend > to get VERY abstract, in just the way Joel decries. Category theory, > model theory, modern algebraic geometry, topos theory, algebraic graph > theory, abstract algebras and topological complexes are all very > difficult to understand because they seem so incredibly abstract, yet > most of them already have important applications. I'm 100% positive > if you just presented Joel with seminal papers in some of those areas, > he would apply the "astronaut" rubber stamp, because the material is > challenging, and he wouldn't get it (I love math, and I've had to read > some papers 10+ times before they click). Nathan, Don't worry too much about Joel Spolsky, and worry even less about people that allude to him. Joel Spolksy is an early 21st century businessman. He's a smart guy with decent writing skills and semi-interesting thoughts, but he's not gonna change the world. He runs his business by promoting pragmatic processes, writing blogs, procuring comfortable chairs for developers, renting nice loft space in NYC, and building some useful, but basically unoriginal, websites and apps. Everything that Joel Spolsky has ever said in his blog has already been put into practice 100 times over by a bunch of similarly pragmatic early 21st century folk. If you really like math, it is no surprise that you find the current state of computer programming a bit inelegant. 90% of what programmers do in the early 21st century is move the data from HERE to THERE, then another 9% is placing the data in just the right part of the screen. I'm exaggerating a bit, but we're still in the backwaters. It's all engineering now; it's all breeding the faster horse. Or so it seems. There's a natural ebb and flow to progress. In the early to mid 20th century, there were tremendous advances in math, science, and technology, and maybe it's gonna take a full century or two of playing around with shit and arguing about stupid shit until the dust finally settles and we make another quantum jump.
[toc] | [prev] | [next] | [standalone]
| From | "Prasad, Ramit" <ramit.prasad@jpmorgan.com> |
|---|---|
| Date | 2012-03-30 16:40 +0000 |
| Message-ID | <mailman.1150.1333125631.3037.python-list@python.org> |
| In reply to | #22374 |
> > My aunt makes the best damn lasagna you've ever tasted without any > > overarching abstract theory of human taste. And if you think that > quantum > > mechanics is more difficult than understanding human perceptions of > > taste, you are badly mistaken. > > Taste is subjective, and your aunt probably started from a good recipe > and tweaked it for local palates. That recipe could easily be over a > hundred years old. An overarching mathematical theory of human > taste/mouth perception, if such a silly thing were to exist, would be > able to generate new recipes that were perfect for a given person's > tastes very quickly. > > Additionally, just to troll this point some more (fun times!), I would > argue that there is an implicit theory of human taste (chefs refer to > it indirectly as gastronomy) that is very poorly organized and lacks > any sort of scientific rigor. Nonetheless, enough empirical > observations about pairings of flavors, aromas and textures have been > made to guide the creation of new recipes. Gastronomy doesn't need to > be organized or rigorous because fundamentally it isn't very > important. I cannot live without eating, I can live just fine without math. Your opinion that gastronomy is fundamentally unimportant is fundamentally flawed. > > In any case, Spolsky is not making a general attack on abstract science. > > Your hyperbole is completely unjustified. > > The mathematics of the 20th century, (from the early 30s onward) tend > to get VERY abstract, in just the way Joel decries. Category theory, > model theory, modern algebraic geometry, topos theory, algebraic graph > theory, abstract algebras and topological complexes are all very > difficult to understand because they seem so incredibly abstract, yet > most of them already have important applications. I'm 100% positive > if you just presented Joel with seminal papers in some of those areas, > he would apply the "astronaut" rubber stamp, because the material is > challenging, and he wouldn't get it (I love math, and I've had to read > some papers 10+ times before they click). I do not think that you can compare abstract vs real world. Joel talks in the context of solving real-world problems for a living and producing tangible results to justify employment. It is only fair to talk about mathematics in the same context. Or vice-versa. Joining-the-trolling-bandwagon, Ramit Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology 712 Main Street | Houston, TX 77002 work phone: 713 - 216 - 5423 -- This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-30 00:27 -0700 |
| Message-ID | <e7821f56-46cd-4f03-97a4-e1c5e3e29b8c@x10g2000pbi.googlegroups.com> |
| In reply to | #22374 |
On Mar 29, 8:36 pm, Steven D'Aprano <steve +comp.lang.pyt...@pearwood.info> wrote: > The Romans had perfectly functioning concrete without any abstract > understanding of chemistry. If I ever stumbled upon a technology that proved how useless abstract thinking was, do you know what I would call it? "Concrete." Damn, those clever Romans beat me to it by a couple millennia! And they had AQUEDUCTS!!! > [...] Medicine and pharmaceuticals continue to be > discovered even when we can't predict the properties of molecules. I know this is really, really far out, and I should probably come back down to earth, but I can envision some sort of 25th century utopia where scientists measure the weights and charges and atoms, and arrange them into some kind of chart, and just BASED ON THE CHART ALONE, these 25th century scientists might be able to predict behaviors that have never been observed, just BASED ON ABSTRACT REASONING. Whoa! That's really far out stuff. Give me some oxygen! (preferably of the 1s2 2s2 2p4 variety) (Yep, I get it, the periodic table is about atoms, and medicine/ pharmaceuticals are about molecules, so your point is not invalid. It's still alchemy, though.)
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-23 06:08 +1100 |
| Message-ID | <mailman.897.1332443317.3037.python-list@python.org> |
| In reply to | #22032 |
On Fri, Mar 23, 2012 at 5:26 AM, Nathan Rice <nathan.alexander.rice@gmail.com> wrote: [regarding Python 2 -> 3] > The extremely slow uptake? I don't really care one way or another but > a lot of the devs have lamented the issue. By your plan, the slow uptake would be accepted, even encouraged. In fact, your plan is effectively equivalent to simply having both Python 2 and Python 3 installed on every computer, plus having some way for them to interact. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-23 00:17 +1100 |
| Message-ID | <mailman.887.1332422271.3037.python-list@python.org> |
| In reply to | #22010 |
On Thu, Mar 22, 2012 at 11:47 PM, Nathan Rice <nathan.alexander.rice@gmail.com> wrote: > Having one core language with > many DSLs that can interoperate is infinitely better than having many > languages that cannot. A language designed in such a way would also > prevent issues like the Python 2 -> 3 fiasco, because two versions of > a DSL can be separate, and code can reference them independently while > being able to interoperate. This is either utterly impossible, or already available, depending on your point of view. To have an infinitely-configurable program, you must make its configuration equivalent to writing code. There is already an infinitely-configurable program in Unix: "gcc config.c; ./a.out" takes a simple-format text file called "config.c" and processes it. You want infinite DSLs? Behold! $ ./module1 | ./module2 | ./module3 | ./module4 Each one has a shebang that tells you what they are (Python 2, Python 3, something else entirely). There's a very strict interoperability protocol between the modules - they pass information around through stdout and stdin. You can write any module in any language, and you can rewrite module1 for Python 3 without affecting any other or the invocation sequence. Problems always come when you want to share data between dissimilar modules. There's no single perfect data-transfer protocol that works across all languages. What does it mean to "call a function"? If you truly want this level of flexibility, the best thing to do is to separate sections cleanly. In fact, the pipe system I show above could be used that way, although it's stupidly ugly. Everything going on stdout/stdin has a two-word dispatch envelope with a from and a to, and each module reads a line, and if it's not addressed to it, passes it on to stdout. Responses get sent out with their from and to reversed. All you need is for the last module's stdout to be linked back into the first module's stdin (not sure if you can do that or not - it has the feeling of plugging a power strip into itself), and it'll work perfectly. Add a bit of boilerplate so that the application developers don't see what's happening underneath, and you could pretend that dissimilar languages are able to call into each other. Doesn't mean it's efficient though! TLDR version: Infinite flexibility means you're doing nothing. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-22 10:29 -0400 |
| Message-ID | <mailman.890.1332426591.3037.python-list@python.org> |
| In reply to | #22010 |
On Thu, Mar 22, 2012 at 9:17 AM, Chris Angelico <rosuav@gmail.com> wrote: > On Thu, Mar 22, 2012 at 11:47 PM, Nathan Rice > <nathan.alexander.rice@gmail.com> wrote: >> Having one core language with >> many DSLs that can interoperate is infinitely better than having many >> languages that cannot. A language designed in such a way would also >> prevent issues like the Python 2 -> 3 fiasco, because two versions of >> a DSL can be separate, and code can reference them independently while >> being able to interoperate. > > This is either utterly impossible, or already available, depending on > your point of view. Of course it is already available. It is called the laws of physics. Everything we know of inter-operates in the context of physical reality perfectly. > To have an infinitely-configurable program, you must make its > configuration equivalent to writing code. There is already an > infinitely-configurable program in Unix: "gcc config.c; ./a.out" takes > a simple-format text file called "config.c" and processes it. It is true that infinite configuration requires that the configuration be specified in the language of the program. What's the problem? > You want infinite DSLs? Behold! > > $ ./module1 | ./module2 | ./module3 | ./module4 > > Each one has a shebang that tells you what they are (Python 2, Python > 3, something else entirely). There's a very strict interoperability > protocol between the modules - they pass information around through > stdout and stdin. You can write any module in any language, and you > can rewrite module1 for Python 3 without affecting any other or the > invocation sequence. It has always been possible to get from one point in space to another point in space in finite time. Was the invention of the automobile was redundant and unimportant? Obviously not, the characteristics of the process matter. For example, your ability to reason about the behavior of the system you posited as a whole is limited. Are there parts of the different modules that can execute concurrently? Is the output of module1 guaranteed to be acceptable as the input for module2? Is part of module3 redundant (and thus avoidable) given some conditions in module1? If you make a change in module2 what effect does that have on module3 and module4? What if you need to go back and forth between module2 and module3 until some criterion is met before you transition to module4? What if you sometimes want to run module2b instead of module2? > Problems always come when you want to share data between dissimilar > modules. There's no single perfect data-transfer protocol that works > across all languages. What does it mean to "call a function"? If you > truly want this level of flexibility, the best thing to do is to > separate sections cleanly. In fact, the pipe system I show above could > be used that way, although it's stupidly ugly. Everything going on > stdout/stdin has a two-word dispatch envelope with a from and a to, > and each module reads a line, and if it's not addressed to it, passes > it on to stdout. Responses get sent out with their from and to > reversed. All you need is for the last module's stdout to be linked > back into the first module's stdin (not sure if you can do that or not > - it has the feeling of plugging a power strip into itself), and it'll > work perfectly. Add a bit of boilerplate so that the application > developers don't see what's happening underneath, and you could > pretend that dissimilar languages are able to call into each other. > Doesn't mean it's efficient though! What is a function? You could say that it is a sequence of logical statements that relates some assertion with another. You can make a big deal about call by name versus call by value, but it only really matters on a conceptual level when dealing with infinite objects that do not have an analytic closure. You can make a big deal about data format, but scientists have been communicating using different unit systems for hundreds of years, I don't see assertions of relationship between structures as different from unit conversions from imperial to metric; it's all data. There are of course a few snags such as cardinality of the set represented by the integer data type in one case versus another, but that is a low level detail that would be a problem if DSLs were embedded in an expressive modelling language. Data structures ultimately boil down to assertions, assertions about those assertions and relations between assertions. > TLDR version: Infinite flexibility means you're doing nothing. I could address that from a number of ways. First off, anything that is Turing complete is basically "infinitely flexible" but the difference in expressiveness (as measured by the combined length of the program and its input required to generate some output) varies over orders of magnitudes. So, we're actually discussing "infinitely expressive" though in fact we don't need to appeal to infinity here, so that is a strawman. The reason for that is the system in which concepts are generated (physical reality) is finite on some levels. Much like a fractal, though there is infinite "detail", it is the result of the recursive application and composition of a small set of motifs. This is why I keep harping on the importance of a meta-model. Given a description of the fractal system and starting state, I can predict the structure of any portion of the fractal at any time with complete accuracy (assuming it is not a stochastic system, in which case I can only predict the distribution of states). If you try to model a fractal system at a particular point by describing its geometry you will be busy for a VERY long time, and if I asked you anything about the state of the fractal at a different time you would be at a loss. All I'm trying to advocate is that people stop modelling the geometry of the system at time t and start modelling the dynamics of the system. Seems pretty reasonable to me. TL;DR there are a huge number of incompatible programming languages because people are modeling a permutation rather than the input to a permutation generating function. Nathan
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-22 09:12 -0700 |
| Message-ID | <887ca72d-72f6-46f4-9af2-2cfd72d10212@t8g2000pbe.googlegroups.com> |
| In reply to | #22025 |
On Mar 22, 7:29 am, Nathan Rice <nathan.alexander.r...@gmail.com> wrote: > On Thu, Mar 22, 2012 at 9:17 AM, Chris Angelico <ros...@gmail.com> wrote: > > On Thu, Mar 22, 2012 at 11:47 PM, Nathan Rice > > <nathan.alexander.r...@gmail.com> wrote: > >> Having one core language with > >> many DSLs that can interoperate is infinitely better than having many > >> languages that cannot. A language designed in such a way would also > >> prevent issues like the Python 2 -> 3 fiasco, because two versions of > >> a DSL can be separate, and code can reference them independently while > >> being able to interoperate. > > > This is either utterly impossible, or already available, depending on > > your point of view. > > Of course it is already available. It is called the laws of physics. > Everything we know of inter-operates in the context of physical > reality perfectly. > > > To have an infinitely-configurable program, you must make its > > configuration equivalent to writing code. There is already an > > infinitely-configurable program in Unix: "gcc config.c; ./a.out" takes > > a simple-format text file called "config.c" and processes it. > > It is true that infinite configuration requires that the configuration > be specified in the language of the program. What's the problem? > > > You want infinite DSLs? Behold! > > > $ ./module1 | ./module2 | ./module3 | ./module4 > > > Each one has a shebang that tells you what they are (Python 2, Python > > 3, something else entirely). There's a very strict interoperability > > protocol between the modules - they pass information around through > > stdout and stdin. You can write any module in any language, and you > > can rewrite module1 for Python 3 without affecting any other or the > > invocation sequence. > > It has always been possible to get from one point in space to another > point in space in finite time. Was the invention of the automobile > was redundant and unimportant? Obviously not, the characteristics of > the process matter. > The funny thing about the "automobile" is that, for all its impact, it's really just a better horse. Imagine in 1750 three futurists pondering how people in the future could solve the problem of physical separation: Futurist A: We'll breed a better horse. Futurist B: No, we should build a mechanical machine that's faster than a horse. Futurist C: What if we make it so that two people 10,000 miles away from each other can talk to each other like they're next door? The ironic thing is that telecommunication was more or less solved in the late 1800s or so, but in the 21 century, we still talk about "horsepower" for our people-moving machines. I think in 2012, when it comes to programming languages, we're still mostly breeding better horses. Nothing wrong with that, just an observation.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-03-22 17:44 +0000 |
| Message-ID | <4f6b64f9$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #22025 |
On Thu, 22 Mar 2012 10:29:48 -0400, Nathan Rice wrote: [Snip a load of stuff about the laws of physics, infinity, and of course fractals.] I'm just surprised you didn't manage to fit quantum mechanics and "the interconnectedness of all things" into it :) > TL;DR there are a huge number of incompatible programming languages > because people are modeling a permutation rather than the input to a > permutation generating function. No offence Nathan, but I think you need to come back down to earth for air before you black out: http://www.joelonsoftware.com/articles/fog0000000018.html Or at least before *I* black out. Even if somebody manages to write your meta-language, you're going to run into the problem of who is going to be able to use it. The typical developer knows three, maybe four languages moderately well, if you include SQL and regexes as languages, and might have a nodding acquaintance with one or two more. With the radical changes you're suggesting, developers would need to be able to deal with some arbitrary number of different DSLs, and whatever meta-language is used to glue them together. There are a huge number of incompatible programming languages because language designers have different requirements, preferences, and styles; and because the state of the art of language design is very different in 2012 than it was in 1962. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-22 19:42 -0700 |
| Message-ID | <94d35431-0d4f-44d8-85fb-93671829a554@m10g2000pbk.googlegroups.com> |
| In reply to | #22034 |
On Mar 22, 10:44 am, Steven D'Aprano <steve +comp.lang.pyt...@pearwood.info> wrote: > On Thu, 22 Mar 2012 10:29:48 -0400, Nathan Rice wrote: > > Or at least before *I* black out. Even if somebody manages to write your > meta-language, you're going to run into the problem of who is going to be > able to use it. The typical developer knows three, maybe four languages > moderately well, if you include SQL and regexes as languages, and might > have a nodding acquaintance with one or two more. > Maybe I'm not the typical developer, but I think "three, maybe four" is a very low estimate of the number of languages that the typical developer confronts in his lifetime. Just in the last couple weeks I've looked at code in all these languages: Python2 PHP JavaScript CoffeeScript C Perl Shell (bash) Regex (three variants--bash, Python, PHP) awk (albeit trivially) SQL (two variants--MySQL and Hive) HTML CSS With the exception of awk, I know all of the above languages in some depth, way beyond a "nodding acquaintance." I'm not taking any sides on the meta-language debate in pointing this out; I'm merely suggesting that we do live in a bit of a Tower of Babel. I'm only arguing with the numbers in your premise; maybe even if you underestimate the number of languages that typical devs consume in 2012, you could still draw the same valid conclusions overall with a slightly more accurate estimate. > There are a huge number of incompatible programming languages because > language designers have different requirements, preferences, and styles; > and because the state of the art of language design is very different in > 2012 than it was in 1962. Do you think we'll always have a huge number of incompatible programming languages? I agree with you that it's a fact of life in 2012, but will it be a fact of life in 2062?
[toc] | [prev] | [next] | [standalone]
| From | rusi <rustompmody@gmail.com> |
|---|---|
| Date | 2012-03-22 20:20 -0700 |
| Message-ID | <9c7ce4fd-9530-4c34-a88e-446bab7c31ab@sv8g2000pbc.googlegroups.com> |
| In reply to | #22054 |
On Mar 23, 7:42 am, Steve Howell <showel...@yahoo.com> wrote: > Do you think we'll always have a huge number of incompatible > programming languages? I agree with you that it's a fact of life in > 2012, but will it be a fact of life in 2062? It will be a fact of life wherever Godels theorem is; which put simplistically is: consistency and completeness cannot coexist. This is the 'logic-generator' for the mess in programming languages. Put in more general terms: Completeness is an 'adding' process Consistency is a 'subtracting' process Running the two together, convergence is hopeless. In programming language terms the pull is between simplicity and expressivity/power.
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-22 21:16 -0700 |
| Message-ID | <3c9b6aa7-0da1-4af3-a55d-e87609dccdd3@jx17g2000pbb.googlegroups.com> |
| In reply to | #22057 |
On Mar 22, 8:20 pm, rusi <rustompm...@gmail.com> wrote: > On Mar 23, 7:42 am, Steve Howell <showel...@yahoo.com> wrote: > > > Do you think we'll always have a huge number of incompatible > > programming languages? I agree with you that it's a fact of life in > > 2012, but will it be a fact of life in 2062? > > It will be a fact of life wherever Godels theorem is; which put > simplistically is: consistency and completeness cannot coexist. This > is the 'logic-generator' for the mess in programming languages. > Put in more general terms: > Completeness is an 'adding' process > Consistency is a 'subtracting' process > Running the two together, convergence is hopeless. Fair enough, but I don't think you can blame Godel's Theorem for the fact that JS, Ruby, Perl, and PHP all solve basically the same problems as Python in 2012. Can't we agree that at least *Perl* is redundant, and that the lingering existence of Perl 5 is an artifact of culture, legacy, and primitive experimentation (by future standards), not mathematical inevitability? > In programming language terms the pull is between simplicity and > expressivity/power. Sure, you can see this tension between Python (simplicity) and Ruby (expressivity). My idea of progress--way before 2062--is that you'd still have a spectrum of simplicity and expressivity, but the level of elegance and power throughout the spectrum would be elevated. There wouldn't be a monoculture, but the cream would eventually rise toward the top.
[toc] | [prev] | [next] | [standalone]
| From | MRAB <python@mrabarnett.plus.com> |
|---|---|
| Date | 2012-03-23 04:43 +0000 |
| Message-ID | <mailman.914.1332477827.3037.python-list@python.org> |
| In reply to | #22058 |
On 23/03/2012 04:16, Steve Howell wrote: > On Mar 22, 8:20 pm, rusi<rustompm...@gmail.com> wrote: >> On Mar 23, 7:42 am, Steve Howell<showel...@yahoo.com> wrote: >> >> > Do you think we'll always have a huge number of incompatible >> > programming languages? I agree with you that it's a fact of life in >> > 2012, but will it be a fact of life in 2062? >> >> It will be a fact of life wherever Godels theorem is; which put >> simplistically is: consistency and completeness cannot coexist. This >> is the 'logic-generator' for the mess in programming languages. >> Put in more general terms: >> Completeness is an 'adding' process >> Consistency is a 'subtracting' process >> Running the two together, convergence is hopeless. > > Fair enough, but I don't think you can blame Godel's Theorem for the > fact that JS, Ruby, Perl, and PHP all solve basically the same > problems as Python in 2012. Can't we agree that at least *Perl* is > redundant, and that the lingering existence of Perl 5 is an artifact > of culture, legacy, and primitive experimentation (by future > standards), not mathematical inevitability? > Perl's support for Unicode is much better than the others. >> In programming language terms the pull is between simplicity and >> expressivity/power. > > Sure, you can see this tension between Python (simplicity) and Ruby > (expressivity). My idea of progress--way before 2062--is that you'd > still have a spectrum of simplicity and expressivity, but the level of > elegance and power throughout the spectrum would be elevated. There > wouldn't be a monoculture, but the cream would eventually rise toward > the top. >
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-22 23:58 -0700 |
| Message-ID | <5e81d24b-96d8-4e4b-a90c-61cdf7b34a5b@px4g2000pbc.googlegroups.com> |
| In reply to | #22060 |
On Mar 22, 9:43 pm, MRAB <pyt...@mrabarnett.plus.com> wrote: > On 23/03/2012 04:16, Steve Howell wrote: > > > > > > > > > On Mar 22, 8:20 pm, rusi<rustompm...@gmail.com> wrote: > >> On Mar 23, 7:42 am, Steve Howell<showel...@yahoo.com> wrote: > > >> > Do you think we'll always have a huge number of incompatible > >> > programming languages? I agree with you that it's a fact of life in > >> > 2012, but will it be a fact of life in 2062? > > >> It will be a fact of life wherever Godels theorem is; which put > >> simplistically is: consistency and completeness cannot coexist. This > >> is the 'logic-generator' for the mess in programming languages. > >> Put in more general terms: > >> Completeness is an 'adding' process > >> Consistency is a 'subtracting' process > >> Running the two together, convergence is hopeless. > > > Fair enough, but I don't think you can blame Godel's Theorem for the > > fact that JS, Ruby, Perl, and PHP all solve basically the same > > problems as Python in 2012. Can't we agree that at least *Perl* is > > redundant, and that the lingering existence of Perl 5 is an artifact > > of culture, legacy, and primitive experimentation (by future > > standards), not mathematical inevitability? > > Perl's support for Unicode is much better than the others. > Maybe so, but is that an intrinsic feature of the language or just an implementation detail? Even if it's a somewhat intrinsic feature of the language, how hard would it be to subsume Perl's Unicode goodness into the best-of-breed language of all of Perl's cousins?
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-23 00:20 -0400 |
| Message-ID | <mailman.913.1332476445.3037.python-list@python.org> |
| In reply to | #22057 |
>> Do you think we'll always have a huge number of incompatible >> programming languages? I agree with you that it's a fact of life in >> 2012, but will it be a fact of life in 2062? > > It will be a fact of life wherever Godels theorem is; which put > simplistically is: consistency and completeness cannot coexist. This > is the 'logic-generator' for the mess in programming languages. > Put in more general terms: > Completeness is an 'adding' process > Consistency is a 'subtracting' process > Running the two together, convergence is hopeless. This isn't exactly correct. The incompleteness theorem basically shows that in a sufficiently expressive system, there are statements in the system that cannot be proven given the language of that system. We live with this already given the fact that the incompleteness theorem is closely related to Turing's halting problem. That doesn't indicate anything about the convergence of programming languages. It does say that we will need some form of unit testing or restricted subset simulation system as an adjunct to formal verification in most cases, until the end of time.
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-22 08:33 -0700 |
| Message-ID | <3d27a54d-b790-4c73-8fd1-05fcbe9abf7e@r2g2000pbs.googlegroups.com> |
| In reply to | #22010 |
On Mar 22, 1:56 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Wed, 21 Mar 2012 18:35:16 -0700, Steve Howell wrote:
> > On Mar 21, 11:06 am, Nathan Rice <nathan.alexander.r...@gmail.com>
> > wrote:
> >> As for syntax, we have a lot of "real" domain specific languages, such
> >> as English, math and logic. They are vetted, understood and useful
> >> outside the context of programming. We should approach the discussion
> >> of language syntax from the perspective of trying to define a unified
> >> syntactical structure for real these DSLs. Ideally it would allow
> >> representation of things in a familiar way where possible, while
> >> providing an elegant mechanism for descriptions that cut across domains
> >> and eliminating redundancy/ambiguity. This is clearly possible, though
> >> a truly successful attempt would probably be a work of art for the
> >> ages.
>
> > If I'm reading you correctly, you're expressing frustration with the
> > state of language syntax unification in 2012. You mention language in a
> > broad sense (not just programming languages, but also English, math,
> > logic, etc.), but even in the narrow context of programming languages,
> > the current state of the world is pretty chaotic.
>
> And this is a good thing. Programming languages are chaotic because the
> universe of programming problems is chaotic, and the strategies available
> to solve those problems are many and varied.
>
> Different programming languages are good for different things because
> they have been designed to work in different problem/solution spaces.
> Although I dislike C with a passion, I do recognise that it is good for
> when the programmer needs fine control over the smallest details. It is,
> after all, a high-level assembler. Likewise for Forth, which lets you
> modify the compiler and language as you go.
>
> Some languages are optimized for the compiler, some for the writer, and
> some for the reader. So are optimized for numeric work, others for
> database access. Some are Jack-Of-All-Trades. Each language encourages
> its own idioms and ways of thinking about programming.
>
> When it comes to programming, I say, let a thousand voices shout out.
> Instead of imagining a single language so wonderful that every other
> language is overshadowed and forgotten, imagine that the single language
> is the next Java, or C, or even for that matter Python, but whatever it
> is, it's not ideal for the problems you care about, or the way you think
> about them. Not so attractive now, is it?
>
I'm not imagining a world where a single, imperfect programming
language crowds out other useful solutions.
What I am hoping for is a more purposeful diversity. It would be
great if the top 20 languages in the future had the same expressive
power as say the top 200 do now. In other words, by the time you
investigated the 21st best language for your needs, it would be
something really interesting and cutting edge, instead of PHP.
It's hard to imagine the *specific* form of progress we'll have in the
future, but I'd imagine that some day we'll have something more
interesting than a best-of-breed Algol derivative dominating the
scene.
> > The optimistic view is that there will be some kind of inflection point
> > around 2020 or so. I could imagine a perfect storm of good things
> > happening, like convergence on a single browser platform,
>
> You call that a perfect storm of good things. I call that sort of
> intellectual and software monoculture a nightmare.
>
> I want a dozen browsers, not one of which is so common that web designers
> can design for it and ignore the rest, not one browser so common that
> nobody dares try anything new.
>
I don't want a monoculture any more than you do. When I talk about
"convergence on a single browser platform", the thought was that web
designers might not to have waste brain cycles on IE6 workarounds in
2020; instead, they could be working on actual, cutting edge design.
By "convergence on a single browser platform", I was hoping for
something like the Unix situation that we have now--there's still
competition, there's still innovation around the edges, but you can
generally rely on 90% of the platform to be predictable.
> > nearly
> > complete migration to Python 3, further maturity of JVM-based languages,
> > etc., where the bar gets a little higher from what people expect from
> > languages. Instead of fighting semicolons and braces, we start thinking
> > bigger. It could also be some sort of hardware advance, like screen
> > resolutions that are so amazing they let us completely rethink our views
> > on terseness, punctuation, code organization, etc.
>
> And what of those with poor eyesight, or the blind? Are they to be
> excluded from your "bigger" brave new world?
I made my hypothetical advance ("screen resolutions") a little too
narrow and hardware-focused. What I really meant to imagine is a
world where eyesight and monitors stop being a bottleneck. Suppose
people with normal eyesight had way, way better monitors, and suppose
people with less than perfect eyesight had way more remedies available
(laser surgery, brain implants, whatever). With those constraints
removed, how would it change our view on what code should "look" like?
Also, far more people are already held back by a lack of vision than a
lack of eyesight. They can only imagine the worst scenarios with any
suggestion of progress, they embrace the status quo despite its
obvious shortcomings, etc.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-23 06:21 +1100 |
| Message-ID | <mailman.899.1332444075.3037.python-list@python.org> |
| In reply to | #22010 |
On Fri, Mar 23, 2012 at 1:29 AM, Nathan Rice <nathan.alexander.rice@gmail.com> wrote: > For example, your ability to reason about the behavior of the system > you posited as a whole is limited. Are there parts of the different > modules that can execute concurrently? Is the output of module1 > guaranteed to be acceptable as the input for module2? Is part of > module3 redundant (and thus avoidable) given some conditions in > module1? If you make a change in module2 what effect does that have > on module3 and module4? What if you need to go back and forth between > module2 and module3 until some criterion is met before you transition > to module4? What if you sometimes want to run module2b instead of > module2? Pipes allow different modules to execute concurrently (except on DOS and maybe Windows, haven't checked). Nothing in ANY language "guarantees" acceptable input, but protocolling would do that for you. If part of module3 is redundant, you don't call it. If you make a change to one that affects others, then you fix the others, same as in any other coding system (or non-coding system - if you upgrade your hardware from an 8086 with 1MB of memory to a modern box with >4GB, you'll have to rewrite your code to take advantage of it). The (somewhat stupid) protocol I suggested allows you to go between 2 and 3 before going to 4. If you want module2b, you add it to the chain and call on it. Yep, Unix solved all your problems back in the 1970s. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-22 15:33 -0400 |
| Message-ID | <mailman.901.1332444812.3037.python-list@python.org> |
| In reply to | #22010 |
>> For example, your ability to reason about the behavior of the system >> you posited as a whole is limited. Are there parts of the different >> modules that can execute concurrently? Is the output of module1 >> guaranteed to be acceptable as the input for module2? Is part of >> module3 redundant (and thus avoidable) given some conditions in >> module1? If you make a change in module2 what effect does that have >> on module3 and module4? What if you need to go back and forth between >> module2 and module3 until some criterion is met before you transition >> to module4? What if you sometimes want to run module2b instead of >> module2? > > Pipes allow different modules to execute concurrently (except on DOS > and maybe Windows, haven't checked). Nothing in ANY language > "guarantees" acceptable input, but protocolling would do that for you. > If part of module3 is redundant, you don't call it. If you make a > change to one that affects others, then you fix the others, same as in > any other coding system (or non-coding system - if you upgrade your > hardware from an 8086 with 1MB of memory to a modern box with >4GB, > you'll have to rewrite your code to take advantage of it). The > (somewhat stupid) protocol I suggested allows you to go between 2 and > 3 before going to 4. If you want module2b, you add it to the chain and > call on it. > > Yep, Unix solved all your problems back in the 1970s. Pipes do not provide any fine grained control over the concurrent behavior. If you want to change the order of calls, suddenly you have to write a bash script (with its own set of issues), etc. Unix solved these problems in much the same way that the evolution of appendages solved the problem of changing location from one point to another before the automobile. The process matters.
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.python
csiph-web