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 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-21 16:40 +1100 |
| Message-ID | <mailman.853.1332308421.3037.python-list@python.org> |
| In reply to | #21971 |
On Wed, Mar 21, 2012 at 3:58 PM, Steve Howell <showell30@yahoo.com> wrote: > So saying "push(stack, item)" or "push(item, stack)" seems very > unsophisticated, almost assembly-like in syntax, albeit at a higher > level conceptually than assembly. Perhaps it does, but "push(stack, item)" and "stack.push(item)" are so close to identical as makes no odds (in a number of languages, the latter is just syntactic sugar for something like the former) - yet they "read" quite differently, one with verb first, one with noun first. Code doesn't follow the same grammar as English prose, and forcing it to usually makes it sound odd. Reader.can_comprehend(code) is True. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-20 23:52 -0700 |
| Message-ID | <6af70db0-dc4a-48ee-9ee2-1a934846d5f2@r2g2000pbs.googlegroups.com> |
| In reply to | #21972 |
On Mar 20, 10:40 pm, Chris Angelico <ros...@gmail.com> wrote: > On Wed, Mar 21, 2012 at 3:58 PM, Steve Howell <showel...@yahoo.com> wrote: > > So saying "push(stack, item)" or "push(item, stack)" seems very > > unsophisticated, almost assembly-like in syntax, albeit at a higher > > level conceptually than assembly. > > Perhaps it does, but "push(stack, item)" and "stack.push(item)" are so > close to identical as makes no odds (in a number of languages, the > latter is just syntactic sugar for something like the former) - yet > they "read" quite differently, one with verb first, one with noun > first. > On the one hand, you say that "push(stack, item)" reads quite differently from "stack.push(item)". On the other hand, you say they are "so close to identical as makes no odds." I'm trying to make sense of that. Are you saying that the way the two idioms read makes no odds, despite reading quite differently? > Code doesn't follow the same grammar as English prose, and forcing it > to usually makes it sound odd. Reader.can_comprehend(code) is True. > Code shouldn't necessarily follow the example of English prose, but it seems that English has had some influence: 1 push(stack, item) # Push on the stack the item 2 push(item, stack) # Push the item on the stack 3 stack.push(item) # On the stack, push the item 4 stack item push # On the stack, take the item and push it 5 item stack push # Take the item and on the stack, push the former. 6 item push stack # Take the item; push it on the stack. The first three ways are the most common ways of arranging the grammar in mainstream programming languages, and they are also the three most natural ways in English (no pronouns required). #1/2 are imperative. #3 is OO. #4 and #5 are sort of Forth-like, maybe? #6 is just downright strange.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-21 17:59 +1100 |
| Message-ID | <mailman.854.1332313166.3037.python-list@python.org> |
| In reply to | #21973 |
On Wed, Mar 21, 2012 at 5:52 PM, Steve Howell <showell30@yahoo.com> wrote: > On the one hand, you say that "push(stack, item)" reads quite > differently from "stack.push(item)". > > On the other hand, you say they are "so close to identical as makes no > odds." > > I'm trying to make sense of that. Are you saying that the way the two > idioms read makes no odds, despite reading quite differently? If you're designing a language (or, often, a library/module), you can choose either option without greatly annoying your users. As a programmer, I use both types of API all the time. Yes, they read differently, but neither is confusing, and you can easily grok that they do the same thing. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Chris Rebert <clp2@rebertia.com> |
|---|---|
| Date | 2012-03-21 00:16 -0700 |
| Message-ID | <mailman.855.1332314212.3037.python-list@python.org> |
| In reply to | #21973 |
On Tue, Mar 20, 2012 at 11:52 PM, Steve Howell <showell30@yahoo.com> wrote:
> On Mar 20, 10:40 pm, Chris Angelico <ros...@gmail.com> wrote:
>> On Wed, Mar 21, 2012 at 3:58 PM, Steve Howell <showel...@yahoo.com> wrote:
>> > So saying "push(stack, item)" or "push(item, stack)" seems very
>> > unsophisticated, almost assembly-like in syntax, albeit at a higher
>> > level conceptually than assembly.
>>
>> Perhaps it does, but "push(stack, item)" and "stack.push(item)" are so
>> close to identical as makes no odds (in a number of languages, the
>> latter is just syntactic sugar for something like the former) - yet
>> they "read" quite differently, one with verb first, one with noun
>> first.
>
> On the one hand, you say that "push(stack, item)" reads quite
> differently from "stack.push(item)".
>
> On the other hand, you say they are "so close to identical as makes no
> odds."
>
> I'm trying to make sense of that. Are you saying that the way the two
> idioms read makes no odds, despite reading quite differently?
>
>> Code doesn't follow the same grammar as English prose, and forcing it
>> to usually makes it sound odd. Reader.can_comprehend(code) is True.
>
> Code shouldn't necessarily follow the example of English prose, but it
> seems that English has had some influence:
>
> 1 push(stack, item) # Push on the stack the item
> 2 push(item, stack) # Push the item on the stack
> 3 stack.push(item) # On the stack, push the item
<snip>
> 6 item push stack # Take the item; push it on the stack.
<snip>
> #4 and #5 are sort of Forth-like, maybe? #6 is just downright
> strange.
#6 is just an infix binary operator (likewise with its cousin #3, just
remove the punctuation). If you change the name slightly, it becomes
more sensical. One could easily write in Haskell:
item `pushOnto` stack
which would just be syntactic sugar for #2. Not that I endorse #6,
merely saying it's less weird than you think.
Cheers,
Chris
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-21 00:57 -0700 |
| Message-ID | <6a4c821e-3672-401a-9a35-e0950734c22f@ms3g2000pbb.googlegroups.com> |
| In reply to | #21975 |
On Mar 21, 12:16 am, Chris Rebert <c...@rebertia.com> wrote:
> On Tue, Mar 20, 2012 at 11:52 PM, Steve Howell <showel...@yahoo.com> wrote:
> > On Mar 20, 10:40 pm, Chris Angelico <ros...@gmail.com> wrote:
> >> On Wed, Mar 21, 2012 at 3:58 PM, Steve Howell <showel...@yahoo.com> wrote:
> >> > So saying "push(stack, item)" or "push(item, stack)" seems very
> >> > unsophisticated, almost assembly-like in syntax, albeit at a higher
> >> > level conceptually than assembly.
>
> >> Perhaps it does, but "push(stack, item)" and "stack.push(item)" are so
> >> close to identical as makes no odds (in a number of languages, the
> >> latter is just syntactic sugar for something like the former) - yet
> >> they "read" quite differently, one with verb first, one with noun
> >> first.
>
> > On the one hand, you say that "push(stack, item)" reads quite
> > differently from "stack.push(item)".
>
> > On the other hand, you say they are "so close to identical as makes no
> > odds."
>
> > I'm trying to make sense of that. Are you saying that the way the two
> > idioms read makes no odds, despite reading quite differently?
>
> >> Code doesn't follow the same grammar as English prose, and forcing it
> >> to usually makes it sound odd. Reader.can_comprehend(code) is True.
>
> > Code shouldn't necessarily follow the example of English prose, but it
> > seems that English has had some influence:
>
> > 1 push(stack, item) # Push on the stack the item
> > 2 push(item, stack) # Push the item on the stack
> > 3 stack.push(item) # On the stack, push the item
> <snip>
> > 6 item push stack # Take the item; push it on the stack.
> <snip>
> > #4 and #5 are sort of Forth-like, maybe? #6 is just downright
> > strange.
>
> #6 is just an infix binary operator (likewise with its cousin #3, just
> remove the punctuation). If you change the name slightly, it becomes
> more sensical. One could easily write in Haskell:
> item `pushOnto` stack
> which would just be syntactic sugar for #2. Not that I endorse #6,
> merely saying it's less weird than you think.
>
Ha, you're right, verb-in-the-middle is just infix. So, if you don't
care about the order of the nouns, you have three forms:
verb first: English-imperative ("boil water", "add noodles/salt",
"serve in dish") or math-functional, e.g. sum(a,b,c)
verb middle: infix, arithmetic-like ("5 plus 4", "10 divided by 2")
or English-descriptive ("Dog bites man")
verb last: Forth-like, maps well to simple underlying
implementation
I guess the OO syntax is really verb-first when you think of
"stack.push" as the verb.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-21 19:15 +1100 |
| Message-ID | <mailman.856.1332317725.3037.python-list@python.org> |
| In reply to | #21977 |
On Wed, Mar 21, 2012 at 6:57 PM, Steve Howell <showell30@yahoo.com> wrote:
> verb first: English-imperative ("boil water", "add noodles/salt",
> "serve in dish") or math-functional, e.g. sum(a,b,c)
> verb middle: infix, arithmetic-like ("5 plus 4", "10 divided by 2")
> or English-descriptive ("Dog bites man")
In English, verb-first imperative is just verb-middle descriptive with
an implied "You" as the subject. Its nearest equivalent in code, then,
is the common idiom of omitting the 'this' argument (eg in C++), which
Python doesn't support.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Evan Driscoll <driscoll@cs.wisc.edu> |
|---|---|
| Date | 2012-03-21 11:22 -0500 |
| Message-ID | <mailman.862.1332346941.3037.python-list@python.org> |
| In reply to | #21973 |
On 01/-10/-28163 01:59 PM, Steve Howell wrote: > Code shouldn't necessarily follow the example of English prose, but it > seems that English has had some influence: > > 1 push(stack, item) # Push on the stack the item > 2 push(item, stack) # Push the item on the stack > 3 stack.push(item) # On the stack, push the item > 4 stack item push # On the stack, take the item and push it > 5 item stack push # Take the item and on the stack, push the > former. > 6 item push stack # Take the item; push it on the stack. > > The first three ways are the most common ways of arranging the grammar > in mainstream programming languages, and they are also the three most > natural ways in English (no pronouns required). > > #1/2 are imperative. #3 is OO. In my opinion, people who make statements such as "#1/2 are imperative, #3 is OO" are missing pretty much the entire point of what OO is. OO is much more about semantics and the way code is structured. The difference between #1/2 (especially #1, of course) and #3 is surface-level syntax only. About the strongest statement you can make along those lines is that #3 will allow you to do dynamic dispatch on the type of 'stack' while #1/2 won't, but even that isn't true of course. For instance, CLOS will let you write '(push stack item)' (which is the direct analogy in that language to #1) and do even more powerful dynamic dispatch than what a language like C++, Java, or Python will let you do. Evan
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-21 09:30 -0700 |
| Message-ID | <f9fa2ba5-23e9-4bf7-9431-44154ad63480@m10g2000pbk.googlegroups.com> |
| In reply to | #21988 |
On Mar 21, 9:22 am, Evan Driscoll <drisc...@cs.wisc.edu> wrote: > On 01/-10/-28163 01:59 PM, Steve Howell wrote: > > > > > > > > > > > Code shouldn't necessarily follow the example of English prose, but it > > seems that English has had some influence: > > > 1 push(stack, item) # Push on the stack the item > > 2 push(item, stack) # Push the item on the stack > > 3 stack.push(item) # On the stack, push the item > > 4 stack item push # On the stack, take the item and push it > > 5 item stack push # Take the item and on the stack, push the > > former. > > 6 item push stack # Take the item; push it on the stack. > > > The first three ways are the most common ways of arranging the grammar > > in mainstream programming languages, and they are also the three most > > natural ways in English (no pronouns required). > > > #1/2 are imperative. #3 is OO. > > In my opinion, people who make statements such as "#1/2 are imperative, > #3 is OO" are missing pretty much the entire point of what OO is. > > OO is much more about semantics and the way code is structured. The > difference between #1/2 (especially #1, of course) and #3 is > surface-level syntax only. > > About the strongest statement you can make along those lines is that #3 > will allow you to do dynamic dispatch on the type of 'stack' while #1/2 > won't, but even that isn't true of course. For instance, CLOS will let > you write '(push stack item)' (which is the direct analogy in that > language to #1) and do even more powerful dynamic dispatch than what a > language like C++, Java, or Python will let you do. > In the grand scheme of things, of course code structure and semantics are more important the surface-level syntax. If you take it as a given that structure/semantics are sound (big assumption, I know), then the next issue with regards to "readability" is the syntax itself.
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-21 14:06 -0400 |
| Message-ID | <mailman.869.1332353213.3037.python-list@python.org> |
| In reply to | #21989 |
MOAR TROLLING... >> In my opinion, people who make statements such as "#1/2 are imperative, >> #3 is OO" are missing pretty much the entire point of what OO is. >> >> OO is much more about semantics and the way code is structured. The >> difference between #1/2 (especially #1, of course) and #3 is >> surface-level syntax only. The idea of actions as concrete attributes of entities is probably the worst bit of object oriented programming, except perhaps inheritance. Events occur in the context of multiple entities, but they are conceptually distinct and should not be subordinated. Furthermore, if you have an explicit self or this context, your ability to override elements of an event is limited to things which are directly encapsulated in that context. Additionally, dynamic dispatch induces overhead and the possibility of action at a distance. Reflective template meta-programming and explicit attribute delegation are VASTLY superior. To rant about inheritance, outside of mathematics platonic ideals are bullshit. Natural kinds are the closest we might actually be able to come to ideals, and philosophers still debate whether atomic elements and subatomic particles should have this designation. On the macro scale, classes or types are dynamic, fuzzy unions of structure, context and intent. Making any sort of invariant categorical statement about real things is just begging to be proven wrong. Programmers would be much better off if we made assertions about relationships and structure with an explicit, contextual reference. I think this would simplify code reuse, since you would be able to compare contexts to know if program elements were compatible and programs could be assembled by the union or intersection of sets of assertions. >> About the strongest statement you can make along those lines is that #3 >> will allow you to do dynamic dispatch on the type of 'stack' while #1/2 >> won't, but even that isn't true of course. For instance, CLOS will let >> you write '(push stack item)' (which is the direct analogy in that >> language to #1) and do even more powerful dynamic dispatch than what a >> language like C++, Java, or Python will let you do. >> > > In the grand scheme of things, of course code structure and semantics > are more important the surface-level syntax. > > If you take it as a given that structure/semantics are sound (big > assumption, I know), then the next issue with regards to "readability" > is the syntax itself. Sadly, defining sound (i.e. valid) language semantics is not terribly difficult; Turing complete systems occur spontaneously with surprising frequency in nature. The problem is that fundamentally, languages model the conceptual space at large, but language designers choose a semantic vocabulary that models their minuscule subset of that space. This semantic vocabulary is by its nature static, while the conceptual space is dynamic. We aren't going to get semantics really right until we model the dynamical meta structure of the concept space, and put abstract structure, context and intent at the fore. 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.
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-21 18:35 -0700 |
| Message-ID | <32b8c4ae-2509-43df-abf0-0fb308be398f@oq7g2000pbb.googlegroups.com> |
| In reply to | #21996 |
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. My position is that mankind is stuck in a painful, but inevitable, part of the evolutionary process of building programming languages. If there are quantum leaps of expressiveness/elegance/familiarity around the corner, I haven't seen them. My take is that the landscape in 2032 won't be vastly different than 2012. Languages will be better incrementally, but Python 4 or Python 5, or whatever eclipses Python in two decades, won't look vastly different than the Python we have now. If you look back to 1992, things weren't vastly different than now. In 1992 you already had Perl, C/C++, Python, Haskell, LISP, etc. Some of the languages we have in 2012 were still a glimmer in the eye back then (notably Java and Ruby), and some were quite young (notably Python), but most of them can at least trace their roots to earlier days. 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, 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.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-03-22 08:56 +0000 |
| Message-ID | <4f6ae931$0$29883$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #22008 |
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? > 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. > 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? -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Jon Clements <joncle@googlemail.com> |
|---|---|
| Date | 2012-03-22 04:18 -0700 |
| Subject | Re: Python is readable (OT) |
| Message-ID | <33536194.2563.1332415082529.JavaMail.geo-discussion-forums@ynlt15> |
| In reply to | #22010 |
On Thursday, 22 March 2012 08:56:17 UTC, Steven D'Aprano 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: [snip]. > > 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? > > > > 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. > > > > 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? > > > > -- > Steven On Thursday, 22 March 2012 08:56:17 UTC, Steven D'Aprano 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? > > > > 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. > > > > 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? > > > > -- > Steven Completely not related to this discussion, but, I just have to say to Steven, I could not have expressed that better. +1 QOTW (albeit a long one) Jon.
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-22 08:47 -0400 |
| Message-ID | <mailman.884.1332420438.3037.python-list@python.org> |
| In reply to | #22010 |
>> 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. There is a concept in statistical/mathematical modeling called minimum message length (a close analog is minimum description length), which asserts that the optimum model for some set of information is the one that minimizes the sum of the length of the model and the length of the set described by that model. Clearly no model is going to be optimal for every set of information. What I was alluding to in the post that Steve Howell replied to was that we need to have a programming language that is a model of models, then include a second order model as part of the program. 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. > 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. The difference between compiler optimized and writer optimized languages is how many assertions they require about the thing being modeled to be a "valid" program, given its deductive rules. Ideally, the number of assertions should be flexible, and the interpreter/compiler should try and figure out the best way to implement it given the information it has. > 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 agree about letting a thousand voices shout out, in the context of an embedding language that guarantees code interoperability. Additionally, the size of optimal DSLs for different areas is actually quite small, yet having separate languages for each DSL requires the user to re-learn common patterns such as collection manipulation, IO, etc. Pretty horrible all around. >> 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. The cores of English and math are pretty much singularly represented. At more nuanced or abstract levels, there is divergence in order to simplify the process of describing complicated things. How would you like it if linear algebra or algebraic geometry re-invented addition, multiplication, etc with completely different syntax and semantics (I'm ignoring non-commutativity of vector space multiplication) > 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. How about one browser that is infinitely configurable? That way if someone tries something new, you can try it as well without precluding anything else you already do. The CLI/JVM provide some flexibility, but they are not the correct path. They model the executable machine representations of language, rather than modeling the meta structure of language. This means that you still lack flexibility and dynamism. At least things are moving in the right direction.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-03-22 17:18 +0000 |
| Message-ID | <4f6b5ed9$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #22019 |
On Thu, 22 Mar 2012 08:47:15 -0400, Nathan Rice wrote: > There is a concept in statistical/mathematical modeling called minimum > message length (a close analog is minimum description length), which > asserts that the optimum model for some set of information is the one > that minimizes the sum of the length of the model and the length of the > set described by that model. (1) Optimum in what sense? (2) What does this have to do with designing programming languages? This discussion sounds to me like the apocryphal story about the spherical cow. http://en.wikipedia.org/wiki/Spherical_cow > Clearly no model is going to be optimal > for every set of information. What I was alluding to in the post that > Steve Howell replied to was that we need to have a programming language > that is a model of models, then include a second order model as part of > the program. Having one core language with many DSLs that can > interoperate is infinitely better than having many languages that > cannot. Some people, when confronted with a problem, think "I know, I'll use a DSL." Now they have two problems. And some people think "I know, I'll use a meta-language with an infinite number of infinitely variable DSLs." Now they have an infinite number of problems. > A language designed in such a way would also prevent issues > like the Python 2 -> 3 fiasco, What fiasco? You've just lost an awful lot of credibility with me. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-22 14:26 -0400 |
| Message-ID | <mailman.896.1332440814.3037.python-list@python.org> |
| In reply to | #22032 |
>> There is a concept in statistical/mathematical modeling called minimum >> message length (a close analog is minimum description length), which >> asserts that the optimum model for some set of information is the one >> that minimizes the sum of the length of the model and the length of the >> set described by that model. > > (1) Optimum in what sense? Oh, I don't know, the information theoretic one? Of course, if you're part of the department of redundancy department, that might seem to appear to look like a poor, weak, sub-optimal criterion for the purposes of evaluation of optimality, goodness and positive quality. If you're getting hung up on the fact that there are deep ties to data compression in this language, let me help you out. Imagine that instead of having a simple Boolean algebra of two values, the possible values ranged over a set of elementary concepts. You are then trying to come up with a set of compound concepts and a permutation of those concepts that can describe > (2) What does this have to do with designing programming languages? A program is a representation of knowledge (i.e. a model) which a machine has the ability to interpret. Let me know if you can't understand this, I'll break it down further for you. > This discussion sounds to me like the apocryphal story about the > spherical cow. > > http://en.wikipedia.org/wiki/Spherical_cow When you take the baton, you're supposed to keep running along the path in the same direction as the person who handed it to you. >> Clearly no model is going to be optimal >> for every set of information. What I was alluding to in the post that >> Steve Howell replied to was that we need to have a programming language >> that is a model of models, then include a second order model as part of >> the program. Having one core language with many DSLs that can >> interoperate is infinitely better than having many languages that >> cannot. > > Some people, when confronted with a problem, think "I know, I'll use a > DSL." Now they have two problems. Sure. When confronted with the problem of finding the area under a curve, using integral calculus is going to make things worse... I should just manually sum the infantesimals, from now until the end of time. > And some people think "I know, I'll use a meta-language with an infinite > number of infinitely variable DSLs." Now they have an infinite number of > problems. I'll agree with you, if we change that statement to say "an infinite number of possible problems, all isomorphic to each other." >> A language designed in such a way would also prevent issues >> like the Python 2 -> 3 fiasco, > > What fiasco? The extremely slow uptake? I don't really care one way or another but a lot of the devs have lamented the issue. > You've just lost an awful lot of credibility with me. I didn't lose anything, technically you lost some of your belief in my credibility. So, tautologically, you are the one that lost in this situation. > I'm just surprised you didn't manage to fit quantum mechanics and "the > interconnectedness of all things" into it :) Math/Logic are encompassing. I could draw analogies to quantum theory if you really wanted (category theory is great for this sort of thing). As for the interconnectedness of all things, that is quack language, I do science. >> 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 I read that article a long time ago, it was bullshit then, it is bullshit now. The only thing he gets right is that the Shannon information of a uniquely specified program is proportional to the code that would be required to generate it. Never mind that if a program meets a specification, you shouldn't care about any of the values used for unspecified parts of the program. If you care about the values, they should be specified. So, if Joel had said that the program was uniquely specified, or that none of the things that weren't specified require values in the programming language, he might have been kinda, sorta right. Of course, nobody cares enough to specify every last bit of minutiae in a program, and specifications change, so it is pretty much impossible to imagine either case ever actually occurring. > 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. Please don't black out Steven. I'm trying to encourage thought in interesting directions; you can't think when you're unconscious. Lets draw the analogy to mathematicians. If a mathematician wants to solve a problem, he can cruise along at a pretty good clip as long as he understands the theories of the problem domain. If he runs into a portion of the problem domain that requires theories he isn't familiar with, he must trot off to the library for a book, or read some journal articles. Once he's absorbed the theory, he can continue to work on solving the problem, and if he encounters other problems that require the theory, he is set. I can give you another analogy that is even clearer... What happens if there are several words in a paragraph you don't know? You go to the dictionary to look them up, you now know the words, they are part of your vocabulary, and life is good. Finally, what about when you want to use a library in a programming language you already know? That is a domain specific language that just so happens to have the syntax and semantics of the base language as a subset of its own syntax and semantics. Part of the problem here, I think, is that you imagine each DSL to have radically different syntax and semantics. That is unnecessary, and actually contrary to what I am proposing. > 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. They already do that (replace DSL with library here, again). The problem is that the meta-language lacks expressiveness and flexibility because it is modeling the permutation rather than the permutation generator. > 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. Every language goes to 1s and 0s in the end. Clearly 1s and 0s are capable of closing the space of requirements, preferences and styles. This is the case because programs are information (i.e. encoded knowledge). All I'm proposing is an intermediate representation language that describes the higher order structure and dynamics of knowledge in a clean, human readable format. Mathematicians realized this was a good idea and started down this path something like 140 years ago (minus the human readable ;). They aren't done yet, so clearly any meta language someone develops would similarly be a work in progress, but the nice thing is that backwards compatibility would never be broken; as deeper theorems are exposed, previous results can be recast as specific cases of them.
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2012-03-29 13:44 +0000 |
| Message-ID | <m1nfi1.9tn@spenarnc.xs4all.nl> |
| In reply to | #22037 |
In article <mailman.896.1332440814.3037.python-list@python.org>, Nathan Rice <nathan.alexander.rice@gmail.com> wrote: >> >> http://www.joelonsoftware.com/articles/fog0000000018.html > >I read that article a long time ago, it was bullshit then, it is >bullshit now. The only thing he gets right is that the Shannon >information of a uniquely specified program is proportional to the >code that would be required to generate it. Never mind that if a Thank you for drawing my attention to that article. It attacks the humbug software architects. Are you one of them? I really liked that article. >program meets a specification, you shouldn't care about any of the >values used for unspecified parts of the program. If you care about >the values, they should be specified. So, if Joel had said that the >program was uniquely specified, or that none of the things that >weren't specified require values in the programming language, he might >have been kinda, sorta right. Of course, nobody cares enough to >specify every last bit of minutiae in a program, and specifications >change, so it is pretty much impossible to imagine either case ever >actually occurring. I wonder if you're not talking about a different article. <SNIP> Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-29 14:37 -0400 |
| Message-ID | <mailman.1136.1333054997.3037.python-list@python.org> |
| In reply to | #22337 |
On Thu, Mar 29, 2012 at 9:44 AM, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <mailman.896.1332440814.3037.python-list@python.org>, > Nathan Rice <nathan.alexander.rice@gmail.com> wrote: >>> >>> http://www.joelonsoftware.com/articles/fog0000000018.html >> >>I read that article a long time ago, it was bullshit then, it is >>bullshit now. The only thing he gets right is that the Shannon >>information of a uniquely specified program is proportional to the >>code that would be required to generate it. Never mind that if a > > Thank you for drawing my attention to that article. > It attacks the humbug software architects. > Are you one of them? > I really liked that article. I read the first paragraph, remembered that I had read it previously and stopped. I accidentally remembered something from another Joel article as being part of that article (read it at http://www.joelonsoftware.com/items/2007/12/03.html). I don't really have anything to say on Joel's opinions about why people can or should code, their his and he is entitled to them. I feel they are overly reductionist (this isn't a black/white thing) and have a bit of luddite character to them. I will bet you everything I own the only reason Joel is alive today because of some mathematical abstraction he would be all too happy to discount as meaningless (because, to him, it is). Of course, I will give Joel one point: too many things related to programming are 100% hype, without any real substance; if his article had been about bullshit software hype and he hadn't fired the broadsides at the very notion of abstraction, I wouldn't have anything to say. Anyhow, if you "ugh rock good caveman smash gazelle put in mouth make stomach pain go away" meaning, here it is: Programs are knowledge. The reverse is not true, because programming is an infantile area of human creation, mere feet from the primordial tide pool from whence it spawned. We have a very good example of what a close to optimal outcome is: human beings - programs that write themselves, all knowledge forming programs, strong general artificial intelligence. When all knowledge is also programs, we will have successfully freed ourselves from necessary intellectual drudgery (the unnecessary kind will still exist). We will be able to tell computers what we want on our terms, and they will go and do it, checking in with us from time to time if they aren't sure what we really meant in the given context. If we have developed advanced robotics, we will simultaneously be freed from most manual labor. The only thing left for Joel to do will be to lounge about, being "creative" while eating mangos that were picked, packed, shipped and unloaded by robots, ordered by his computer assistant because it knows that he likes them, then delivered, prepared and served by more robots. The roadblocks in the path include the ability to deal with uncertainty, understand natural languages and the higher order characteristics of information. Baby steps to deal with these roadblocks are to explicitly forbid uncertainty, simplify the language used, and explicitly state higher order properties of information. The natural evolution of the process is to find ways to deal with ambiguity, correctly parse more complex language and automatically deduce higher order characteristics of information. Clearly, human intelligence demonstrates that this is not an impossible pipe dream. You may not be interested in working towards making this a reality, but I can pretty much guarantee on the scale of human achievement, it is near the top.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-03-30 01:42 +0000 |
| Message-ID | <4f750f9f$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #22361 |
On Thu, 29 Mar 2012 14:37:09 -0400, Nathan Rice wrote: > On Thu, Mar 29, 2012 at 9:44 AM, Albert van der Horst > <albert@spenarnc.xs4all.nl> wrote: >> In article <mailman.896.1332440814.3037.python-list@python.org>, Nathan >> Rice <nathan.alexander.rice@gmail.com> wrote: >>>> >>>> http://www.joelonsoftware.com/articles/fog0000000018.html > Of course, I will give Joel one point: too many things related to > programming are 100% hype, without any real substance; if his article > had been about bullshit software hype and he hadn't fired the broadsides > at the very notion of abstraction He did no such thing. I challenge you to find me one place where Joel has *ever* claimed that "the very notion of abstraction" is meaningless or without use. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-29 22:26 -0400 |
| Message-ID | <mailman.1142.1333074402.3037.python-list@python.org> |
| In reply to | #22368 |
> He did no such thing. I challenge you to find me one place where Joel has > *ever* claimed that "the very notion of abstraction" is meaningless or > without use. "When great thinkers think about problems, they start to see patterns. They look at the problem of people sending each other word-processor files, and then they look at the problem of people sending each other spreadsheets, and they realize that there's a general pattern: sending files. That's one level of abstraction already. Then they go up one more level: people send files, but web browsers also "send" requests for web pages. And when you think about it, calling a method on an object is like sending a message to an object! It's the same thing again! Those are all sending operations, so our clever thinker invents a new, higher, broader abstraction called messaging, but now it's getting really vague and nobody really knows what they're talking about any more. Blah. When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all." To me, this directly indicates he views higher order abstractions skeptically, and assumes because he does not see meaning in them, they don't hold any meaning. Despite Joel's beliefs, new advances in science are in many ways the result of advances in mathematics brought on by very deep abstraction. Just as an example, Von Neumann's treatment of quantum mechanics with linear operators in Hilbert spaces utilizes very abstract mathematics, and without it we wouldn't have modern electronics. I'm 100% behind ranting on software hype. Myopically bashing the type of thinking that resulted in the computer the basher is writing on, not so much. If he had said "if you're getting very high up, find very smart people and talk to them to make sure you're not in wing nut territory" I could have given him a pass. I really wish people wouldn't try to put Joel up on a pedestal. The majority of his writings either seem like sensationalist spins on tautological statements, self aggrandizement or luddite trolling. At least Stephen Wolfram has cool shit to back up his ego, Fog Creek makes decent but overpriced debuggers/version control/issue trackers... From my perspective, Stack Overflow is the first really interesting thing Joel had his hand in, and I suspect Jeff Atwood was probably the reason for it, since SO doesn't look like anything Fog Creek ever produced prior to that.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-03-30 03:36 +0000 |
| Message-ID | <4f752a3a$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #22371 |
On Thu, 29 Mar 2012 22:26:38 -0400, Nathan Rice wrote: >> He did no such thing. I challenge you to find me one place where Joel >> has *ever* claimed that "the very notion of abstraction" is meaningless >> or without use. [snip quote] > To me, this directly indicates he views higher order abstractions > skeptically, Yes he does, and so we all should, but that's not the claim you made. You stated that he "fired the broadsides at the very notion of abstraction". He did no such thing. He fired a broadside at (1) software hype based on (2) hyper-abstractions which either don't solve any problems that people care about, or don't solve them any better than more concrete solutions. > and assumes because he does not see meaning in them, they > don't hold any meaning. You are making assumptions about his mindset that not only aren't justified by his comments, but are *contradicted* by his comments. He repeatedly describes the people coming up with these hyper-abstractions as "great thinkers", "clever thinkers", etc. who are seeing patterns in what people do. He's not saying that they're dummies. He's saying that they're seeing patterns that don't mean anything, not that the patterns aren't there. > Despite Joel's beliefs, new advances in science > are in many ways the result of advances in mathematics brought on by > very deep abstraction. Just as an example, Von Neumann's treatment of > quantum mechanics with linear operators in Hilbert spaces utilizes very > abstract mathematics, and without it we wouldn't have modern > electronics. I doubt that very much. The first patent for the transistor was made in 1925, a year before von Neumann even *started* working on quantum mechanics. In general, theory *follows* practice, not the other way around: parts of quantum mechanics theory followed discoveries made using the transistor: http://en.wikipedia.org/wiki/History_of_the_transistor The Romans had perfectly functioning concrete without any abstract understanding of chemistry. If we didn't have QM, we'd still have advanced electronics. Perhaps not *exactly* the electronics we have now, but we'd have something. We just wouldn't understand *why* it works, and so be less capable of *predicting* useful approaches and more dependent on trial-and-error. Medicine and pharmaceuticals continue to be discovered even when we can't predict the properties of molecules. 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. In any case, Spolsky is not making a general attack on abstract science. Your hyperbole is completely unjustified. -- Steven
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.python
csiph-web