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 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-30 00:38 -0400 |
| Message-ID | <mailman.1143.1333082309.3037.python-list@python.org> |
| In reply to | #22374 |
>>> 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. Mathematics is all about abstraction. There are theories and structures in mathematics that have probably gone over a hundred years before being applied. As an analogy, just because a spear isn't useful while farming doesn't mean it won't save your life when you venture into the woods and come upon a bear. >> 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. He is basically saying they are too clever for their own good, as a result of being fixated upon purely intellectual constructs. If math was a failed discipline I might be willing to entertain that notion, but quite the opposite, it is certainly the most successful area of study. > >> 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. The electronic properties of silicon (among other compounds) is an obvious example of where quantum theory provides for us. We might have basic circuits, but we wouldn't have semiconductors. > In general, theory *follows* practice, not the other way around: parts of > quantum mechanics theory followed discoveries made using the transistor: You do need data points to identify an explanatory mathematical structure. > 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. The stochastic method, while useful, is many orders of magnitude less efficient than analytically closed solutions. Not having access to closed form solutions would have put us back hundreds of years at least. > 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. > 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). All I'm suggesting here is that if someone creates something abstract that is elegant and contains a kernel of fundamental truth on some level but doesn't immediately suggest applications, file it in the "neat and worth revisiting at some point in the distant future" bin and move on, don't denigrate them as asphyxiating space cases who need to stop following their curiosity, come down to earth, and produce some shiny bauble for immediate human consumption.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-03-30 10:47 +0000 |
| Message-ID | <4f758f43$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #22375 |
On Fri, 30 Mar 2012 00:38:26 -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.
>
> Mathematics is all about abstraction. There are theories and structures
> in mathematics that have probably gone over a hundred years before being
> applied. As an analogy, just because a spear isn't useful while farming
> doesn't mean it won't save your life when you venture into the woods and
> come upon a bear.
A spear is a concrete application of the principle of leverage, not an
abstraction. I also point out leverage was discovered experimentally long
before anyone had an abstraction for it.
In any case, so what? Who is saying that mathematics is useless? Not me,
and not Joel Spolksy. You are hunting strawmen with your non-abstract
spear.
Spolsky has written at least three times about Architecture Astronauts,
and made it abundantly clear that the problem with them is that they
don't solve problems, they invent overarching abstractions that don't do
anything useful or important, and hype them everywhere.
http://www.joelonsoftware.com/articles/fog0000000018.html
http://www.joelonsoftware.com/items/2005/10/21.html
http://www.joelonsoftware.com/items/2008/05/01.html
Jeff Attwood provides a simple test for the difference between a useful
abstraction and an Architecture Astronaut hyper-abstraction:
Does it solve a useful problem?
http://www.codinghorror.com/blog/2004/12/it-came-from-planet-architecture.html
You keep reading this as an assault on abstract mathematics, science and
knowledge for its on sake. It isn't any of these things.
If I'm paid to solve a problem, and instead I build an abstraction that
doesn't help solve the problem, then I'm guilty of doing architecture
astronauting.
>>> 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.
>
> He is basically saying they are too clever for their own good, as a
> result of being fixated upon purely intellectual constructs.
Yes, and he is right to do so, because that is the characteristic of the
Architecture Astronaut: 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.
Good abstractions enable problems to be solved. Bad abstractions don't.
If I ask you to build me a website, I probably don't want a website-
builder, I certainly don't want a website-builder-generator, and I
absolutely do not want you to generalise the concept of a compiler and
create a whole new abstract language for describing meta-compilers so
that I can create a brand new programming language for generating meta-
compilers that build compilers that will build factories for building
website generators so I can make my own website in just three easy steps
(the simplest one of which is about twice as difficult as just building
the website would have been).
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.
This is all well and good. It's not meant as an attack on mathematics.
You can't tell ahead of time which abstractions will solve real problems.
*Somebody* has to be thinking about ways that spherical camels can pass
through the eye of a 17-dimensional needle, because you never know when
somebody else will say, "Hey, that's just what we need to make low-fat
chocolate ice cream that doesn't taste like crap!" and then you'll be
richer beyond all the dreams of avarice.
But that doesn't mean that you have to turn every one of those
abstractions into software. I don't really care if checking my email and
deleting a file are both special cases of some abstract file operation, I
don't need to see it in my file manager.
[...]
> The electronic properties of silicon (among other compounds) is an
> obvious example of where quantum theory provides for us. We might have
> basic circuits, but we wouldn't have semiconductors.
A poor example. The existence of semiconductors was demonstrated, not
predicted: Michael Faraday discovered the existence of semiconductors in
1833, *long* before quantum theory:
http://sites.google.com/site/transistorhistory/faraday-to-shockley
The existence of photoconductivity was one of the experimental
discoveries which eventually led to QM, via Einstein's explanation of the
photoelectric effect.
But what's your point here? We started off talking about abstractions.
Quantum mechanics is not an abstraction, or at least no more than any
other physical theory. It is a *description* of reality (a model), not a
generalisation.
To counter Spolksy, you need to show the great practical discoveries and
inventions, not of quantum mechanics, but of a *generalisation* of
quantum mechanics that encompasses QM as a special, concrete, example.
[...]
> The stochastic method, while useful, is many orders of magnitude less
> efficient than analytically closed solutions. Not having access to
> closed form solutions would have put us back hundreds of years at least.
We don't have closed-form solutions.
At best we have closed-form solutions of simplified and idealised
problems. E.g. we don't have a closed-form solution for the actual
hydrogen atom, only of a simplified model of that atom:
http://en.wikipedia.org/wiki/Hydrogen_atom#Features_going_beyond_the_Schr.C3.B6dinger_solution
And likewise for helium, e.g. one simplifying approximation is to ignore
the electron-electron repulsion. And that's hardly the only one.
As for closed-form solutions of real devices like a CPU? Forget it.
As the famous saying goes, the more advanced the theory, the fewer
entities it can solve exactly. Newtonian physics can't solve the three
body problem exactly; Einsteinian physics can't solve the two body
problem; quantum mechanics can't solve the one body problem; and quantum
gravity can't solve the zero body problem (the vacuum).
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-30 09:46 -0400 |
| Message-ID | <mailman.1147.1333115192.3037.python-list@python.org> |
| In reply to | #22378 |
>> Mathematics is all about abstraction. There are theories and structures >> in mathematics that have probably gone over a hundred years before being >> applied. As an analogy, just because a spear isn't useful while farming >> doesn't mean it won't save your life when you venture into the woods and >> come upon a bear. > > A spear is a concrete application of the principle of leverage, not an > abstraction. I also point out leverage was discovered experimentally long > before anyone had an abstraction for it. And an analogy is a device to demonstrate the fundamental character of an argument in a different context. > In any case, so what? Who is saying that mathematics is useless? Not me, > and not Joel Spolksy. You are hunting strawmen with your non-abstract > spear. I don't think it is a strawman. He decries things that aren't immediately useful. That describes almost all pure math. If he had excluded things that have some characteristic of truth, and just talked about overly general systems, I might agree with him. > Spolsky has written at least three times about Architecture Astronauts, > and made it abundantly clear that the problem with them is that they > don't solve problems, they invent overarching abstractions that don't do > anything useful or important, and hype them everywhere. I believe in the idea of "things should be as simple as possible, but not simpler". Programming as it currently exists is absolutely convoluted. I am called on to help people learn to program from time to time, and I can tell you that we still have a LONG way to go before programming approaches a global optimum in either the semantic or syntactic space. Never mind configuring a build or anything else related to projects. The whole setup really is horrible, and I'm convinced that most of the people who are capable of changing this are more concerned about their personal investment in the way things are than helping others. There are a few exceptions like Alan Kay, but mostly people want to graft shortcuts on to what already exists. > You keep reading this as an assault on abstract mathematics, science and > knowledge for its on sake. It isn't any of these things. I never said it was an attack on science. Scientists don't really do abstraction, they explain observations. Mathematicians are the ones who discover truth that may be completely disconnected from reality. > If I'm paid to solve a problem, and instead I build an abstraction that > doesn't help solve the problem, then I'm guilty of doing architecture > astronauting. If I ignore everything Joel wrote and just use that definition, I agree with you. >> He is basically saying they are too clever for their own good, as a >> result of being fixated upon purely intellectual constructs. > > Yes, and he is right to do so, because that is the characteristic of the > Architecture Astronaut: 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. > > Good abstractions enable problems to be solved. Bad abstractions don't. > > If I ask you to build me a website, I probably don't want a website- > builder, I certainly don't want a website-builder-generator, and I > absolutely do not want you to generalise the concept of a compiler and > create a whole new abstract language for describing meta-compilers so > that I can create a brand new programming language for generating meta- > compilers that build compilers that will build factories for building > website generators so I can make my own website in just three easy steps > (the simplest one of which is about twice as difficult as just building > the website would have been). Again, I follow the principle of "everything should be as simple as possible, but no simpler". I have in the past built website builders rather than build websites (and done a similar thing in other cases), but not because I am trying to discover some fundamental truth of website building, because that would be bullshit. I did it because building websites (or whatever else it was) is a boring, tedious problem, and a website builder, while being more work, is an engaging problem that requires thought. I enjoy challenging myself. > 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? You forget that even abstractions that never directly get turned into something real are almost invariably part of the intellectual discourse that leads to real things. > 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. It is pretty rare that an article that has some element of truth doesn't live on through its intellectual progeny. The abstraction that is used in some amazing way will almost always have a large number of "useless" abstractions as intellectual ancestors. This is easy to see just by following the chain of citations for a paper. > This is all well and good. It's not meant as an attack on mathematics. > You can't tell ahead of time which abstractions will solve real problems. > *Somebody* has to be thinking about ways that spherical camels can pass > through the eye of a 17-dimensional needle, because you never know when > somebody else will say, "Hey, that's just what we need to make low-fat > chocolate ice cream that doesn't taste like crap!" and then you'll be > richer beyond all the dreams of avarice. I think you're overly concerned with money and consumption Steven. Those things are ephemeral. Things like truth and beauty are eternal. Moreover, research in psychology suggests people who pursue money and consumption are less happy in general than people who derive joy from creation. > But that doesn't mean that you have to turn every one of those > abstractions into software. I don't really care if checking my email and > deleting a file are both special cases of some abstract file operation, I > don't need to see it in my file manager. Careful Steven, when you make statements like this, it makes me want to agree with you. People are paralyzed by choice, and in general they want to be told what to do, so having interfaces tons of options actually distresses them. >> The electronic properties of silicon (among other compounds) is an >> obvious example of where quantum theory provides for us. We might have >> basic circuits, but we wouldn't have semiconductors. > > A poor example. The existence of semiconductors was demonstrated, not > predicted: Michael Faraday discovered the existence of semiconductors in > 1833, *long* before quantum theory: He observed a phenomenon, he did not explain it. > But what's your point here? We started off talking about abstractions. > Quantum mechanics is not an abstraction, or at least no more than any > other physical theory. It is a *description* of reality (a model), not a > generalisation. Lattice theory, rings of operators, Hilbert spaces, Lebesgue measure. All very abstract mathematical structures created not to solve a particular problem in the real world, but as descriptions of mathematical truth. > To counter Spolksy, you need to show the great practical discoveries and > inventions, not of quantum mechanics, but of a *generalisation* of > quantum mechanics that encompasses QM as a special, concrete, example. Quantum mechanics is built on a foundation of "meaningless" abstractions. If those abstractions did not exist we wouldn't have computers. > > [...] >> The stochastic method, while useful, is many orders of magnitude less >> efficient than analytically closed solutions. Not having access to >> closed form solutions would have put us back hundreds of years at least. > > We don't have closed-form solutions. > > At best we have closed-form solutions of simplified and idealised > problems. E.g. we don't have a closed-form solution for the actual > hydrogen atom, only of a simplified model of that atom: Of course, the world is complex and stochastic. The only complete solution of a system is the system itself. Thankfully, things like the central limit theorem allow us to pretend a lot of that complexity doesn't exist without sacrificing much. > As the famous saying goes, the more advanced the theory, the fewer > entities it can solve exactly. Newtonian physics can't solve the three > body problem exactly; Einsteinian physics can't solve the two body > problem; quantum mechanics can't solve the one body problem; and quantum > gravity can't solve the zero body problem (the vacuum). That may be true in some cases, but I wouldn't call that a universal. If you have to cross a boundary from linear to nonlinear or finitary to infinitary, of course things are going to get messy, because some areas of math are better developed than others. A complex linear system is just as easy to work with as a simple linear system though.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-31 03:20 +1100 |
| Message-ID | <mailman.1149.1333124439.3037.python-list@python.org> |
| In reply to | #22378 |
On Sat, Mar 31, 2012 at 12:46 AM, Nathan Rice <nathan.alexander.rice@gmail.com> wrote: > I believe in the idea of "things should be as simple as possible, but > not simpler". Programming as it currently exists is absolutely > convoluted. I am called on to help people learn to program from time > to time, and I can tell you that we still have a LONG way to go before > programming approaches a global optimum in either the semantic or > syntactic space. Aside from messes of installing and setting up language interpreters/compilers, which are averted by simply having several pre-installed (I think my Linux boxes come with some Python 2 version, Perl, bash, and a few others), that isn't really the case. Starting a Python script is easy. Programming gets convoluted only when, and to the extent that, the task does. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-30 14:15 -0400 |
| Message-ID | <mailman.1151.1333131323.3037.python-list@python.org> |
| In reply to | #22378 |
On Fri, Mar 30, 2012 at 12:20 PM, Chris Angelico <rosuav@gmail.com> wrote: > On Sat, Mar 31, 2012 at 12:46 AM, Nathan Rice > <nathan.alexander.rice@gmail.com> wrote: >> I believe in the idea of "things should be as simple as possible, but >> not simpler". Programming as it currently exists is absolutely >> convoluted. I am called on to help people learn to program from time >> to time, and I can tell you that we still have a LONG way to go before >> programming approaches a global optimum in either the semantic or >> syntactic space. > > Aside from messes of installing and setting up language > interpreters/compilers, which are averted by simply having several > pre-installed (I think my Linux boxes come with some Python 2 version, > Perl, bash, and a few others), that isn't really the case. Starting a > Python script is easy. Programming gets convoluted only when, and to > the extent that, the task does. It is true that program complexity is correlated with problem complexity, language and environment complexity is undeniable. If you want to prove this to yourself, find someone who is intelligent and has some basic level of computer literacy, sit them down at a computer and ask them to solve simple problems using programs. You could even be nice by opening the editor first. Don't help them, just watch them crash and burn. Then sit them in front of code that already works, and ask them to modify it to do something slightly different, and again just watch them crash and burn in all but the simplest of cases. It is painful - most of the time they just give up. These same people almost universally can describe the exact process of steps verbally or in writing to do what is required without any trouble; there might be some neglected edge cases, but if you describe the failed result, often times they will realize their mistake and be able to fix it quickly. Jeff Atwood had an article about programming sheep and non programming goats, and while he views it as a statement about people's failings, I view it as a statement about the failings of programming. Human computer interaction is really important, and the whole prefab GUI concept doesn't scale along any axis; people need to be able to interact with their computers in a flexible manner. In the beginning, we had no choice but to bend our communication to the the machine, but we're moving past that now. The machine should respect the communication of humans. We shouldn't decry natural language because of ambiguity; If we're ambiguous, the machine should let us know and ask for clarification. If we phrase things in a really awkward way, the machine should tell us so, and suggest a more understandable rendition (just like word processors do now). If the machine does something we didn't want based on our instructions, we should be able to state additional requirements in a declarative manner. Restricted natural languages are an active area of current research, and they clearly demonstrate that you can have an expressive formal language that is also valid English. Make no mistake about it, programming is a form of computer human interaction (I figured that would be an accepted mantra here). Think of it as modeling knowledge and systems instead of pushing bits around. You are describing things to the computer. To move from the syntactic domain to my point about programming languages, imagine if one person describes physics to a computer in French, and another person describes chemistry to a computer in English. The creators of the computer made different languages act as disjoint knowledge domains. The computer is incapable of making any inferences in physics which are informed by chemistry, and vice versa, unless someone comes along and re-describes one of the disciplines in the other language. Worse still, if someone that only speaks Mandarin comes along, the computer won't be able to tell him anything about either domain. Now imagine the creators of the computer decided that an acceptable solution was to have people print out statements from one domain in a given language, take it to another computer that scans the printout, translates it to a different language, and prints out the translated copy, then have that person take the translated copy back to the original computer, and scan it again in order to ask a cross cutting question. I hope from that perspective the paucity of our current methods will be more apparent.
[toc] | [prev] | [next] | [standalone]
| From | Neil Cerutti <neilc@norwich.edu> |
|---|---|
| Date | 2012-03-30 20:30 +0000 |
| Message-ID | <9tmjf7FqldU1@mid.individual.net> |
| In reply to | #22387 |
On 2012-03-30, Nathan Rice <nathan.alexander.rice@gmail.com> wrote: > Restricted natural languages are an active area of current > research, and they clearly demonstrate that you can have an > expressive formal language that is also valid English. See, for example, Inform 7, which translates a subset of English into Inform 6 code. I never thought too deeply about why I disliked it, assuming it was because I already knew Inform 6. Would you like to write the equivalent, e.g., C code in English? -- Neil Cerutti
[toc] | [prev] | [next] | [standalone]
| From | alex23 <wuwei23@gmail.com> |
|---|---|
| Date | 2012-04-01 20:38 -0700 |
| Message-ID | <7ccd462e-82f6-4924-ba05-596a8a3edc62@t8g2000pbe.googlegroups.com> |
| In reply to | #22394 |
On Mar 31, 6:30 am, Neil Cerutti <ne...@norwich.edu> wrote: > See, for example, Inform 7, which translates a subset of English > into Inform 6 code. I never thought too deeply about why I > disliked it, assuming it was because I already knew Inform 6. I've always respected Inform 7 while being also unwilling to use it. When you're trying to make your language grammar a subset of your data grammar and then combine them interchangeably, it can be unclear about where the error lies, even if the combination is done in prescribed and restricted ways. Whereas keywords are key words: they give texture to source code, like visual braille.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-31 05:29 +1100 |
| Message-ID | <mailman.1152.1333132156.3037.python-list@python.org> |
| In reply to | #22378 |
On Sat, Mar 31, 2012 at 5:15 AM, Nathan Rice <nathan.alexander.rice@gmail.com> wrote: > It is true that program complexity is correlated with problem > complexity, language and environment complexity is undeniable. If you > want to prove this to yourself, find someone who is intelligent and > has some basic level of computer literacy, sit them down at a computer > and ask them to solve simple problems using programs. You could even > be nice by opening the editor first. Don't help them, just watch them > crash and burn. Then sit them in front of code that already works, > and ask them to modify it to do something slightly different, and > again just watch them crash and burn in all but the simplest of cases. > It is painful - most of the time they just give up. These same > people almost universally can describe the exact process of steps > verbally or in writing to do what is required without any trouble; > there might be some neglected edge cases, but if you describe the > failed result, often times they will realize their mistake and be able > to fix it quickly. This is more a matter of being unable to express themselves appropriately. If I allowed them to write an exact process of steps to do what's required, those steps would either be grossly insufficient for the task, or would BE pseudo-code. There are plenty of people who cannot write those sorts of instructions at all. They're called non-programmers. Anyone who doesn't code but can express a task in such clear steps as you describe is what I would call a non-coding programmer - and such people are VERY easily elevated to full programmer status. I've worked with several like that, and the border between that kind of clear, concise, simple instruction list and actual Python or REXX code is so small as to be almost nonexistent. It's not the programming languages' fault. It's a particular jump in thinking that must be overcome before a person can use them. There are other similar jumps in thinking. On which side of these lines are you? Do you remember making the shift? Or, conversely, do you stare at it with "Huh? Why would I do that?"? * Source control. Don't just keep daily backups - record specific purposeful changes in a log. * WYSIWYG document editing vs plain-text with a compiler. Pass up Open Office (or worse) in favour of LaTeX, abandon Sibelius in favour of Lilypond. Plays very nicely with source control. * Unicode instead of head-in-the-sand pretending that ASCII is good enough. * Open standards and toolchains instead of expecting monolithic proprietary programs to do your work for you. Etcetera, etcetera. Everyone who's made the jump will see the benefit of the side they're on; most who haven't won't. Same with non-programmers to programmers. Why should I write like that when I could just write English? Simple: Because dedicated programming languages are far more expressive for the job. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-30 15:55 -0400 |
| Message-ID | <mailman.1156.1333137349.3037.python-list@python.org> |
| In reply to | #22378 |
> This is more a matter of being unable to express themselves > appropriately. If I allowed them to write an exact process of steps to > do what's required, those steps would either be grossly insufficient > for the task, or would BE pseudo-code. There are plenty of people who > cannot write those sorts of instructions at all. They're called > non-programmers. Anyone who doesn't code but can express a task in > such clear steps as you describe is what I would call a non-coding > programmer - and such people are VERY easily elevated to full > programmer status. I've worked with several like that, and the border > between that kind of clear, concise, simple instruction list and > actual Python or REXX code is so small as to be almost nonexistent. > It's not the programming languages' fault. It's a particular jump in > thinking that must be overcome before a person can use them. Your statement that the difference between Python or REXX and pseudo-code is almost non existent is completely false. While people reading Python might be able to guess with higher accuracy what a program does than some other programming languages, there is still a set of VERY specific set of glyphs, words and phrase structures it requires. Pretty much anyone can follow a recipe to make a meal (and there are a lot other examples of this), and conversely given the knowledge of how to make some dish, pretty much everyone could describe the process as a recipe. The same person will fail miserably when trying to create working code that is MUCH simpler from a conceptual standpoint. "Non coders" are not stupid, they just don't appreciate the multitude of random distinctions and computer specific abstractions programming foists on them for the purpose of writing EFFICIENT code. I'm talking about like multiple int/number types, umpteen different kinds of sequences, tons of different data structures that are used for basically the same things under different circumstances, indices starting at 0 (which makes amazing sense if you think like a machine, and very little if you think like a human), the difference between logical and bitwise operators (union and intersection would be better names for the latter), string encoding, etc. When you combine these with having to communicate in a new (very arbitrary, sometimes nonsensical) vocabulary that doesn't recognize synonyms, using an extremely restricted phrase structure and an environment with very limited interactivity, it should become clear that the people who learn to program are invariably fascinated by computers and very motivated to do so. I'm going to assume that you didn't mean that "non coders" are incapable of instructing others (even though your statement implies it directly). I think the ability of "non coders" to describe procedures would surprise you. Things I hear over and over from "non coders" all tie into people being frustrated that computers don't grasp similarity, and don't try to figure out what they want at all; most people provide instructions in an interactive manner. The computer is too stupid to interact with humans, so you have to tell it what to do, then try to run it, watch it fail, then go back and modify your program, which is highly unnatural. I think you'd find that these "non coders" would do very well if given the ability to provide instructions in a natural, interactive way. They are not failing us, we are failing them. > Etcetera, etcetera. Everyone who's made the jump will see the benefit > of the side they're on; most who haven't won't. Same with > non-programmers to programmers. Why should I write like that when I > could just write English? Simple: Because dedicated programming > languages are far more expressive for the job. Really? Or could it be that algorithms for natural language processing that don't fail miserably is a very recent development, restricted natural languages more recent still, and pretty much all commonly used programming languages are all ~20+ years old? Could it also be that most programmers don't see a lot of incentives to make things accessible, since they're already invested in the status quo, and they might lose some personal value if programming stopped being an arcane practice? Creating a programming language is a time consuming and laborious process, the fact that people are doing it constantly is a clear indication that what we have is insufficient.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-31 07:20 +1100 |
| Message-ID | <mailman.1157.1333138842.3037.python-list@python.org> |
| In reply to | #22378 |
On Sat, Mar 31, 2012 at 6:55 AM, Nathan Rice <nathan.alexander.rice@gmail.com> wrote: > I think you'd find that these "non coders" would do very well if given > the ability to provide instructions in a natural, interactive way. > They are not failing us, we are failing them. The nearest thing to natural-language command of a computer is voice navigation, which is another science that's plenty old and yet still current (I first met it back in 1996 and it wasn't new then). You tell the computer what you want it to do, and it does it. Theoretically. The vocabulary's a lot smaller than all of English, of course, but that's not a problem. The problem is that it's really REALLY slow to try to get anything done in English, compared to a dedicated domain-specific language (in the case of typical OS voice navigation, the nearest equivalent would probably be a shell script). > Really? Or could it be that algorithms for natural language > processing that don't fail miserably is a very recent development, > restricted natural languages more recent still, and pretty much all > commonly used programming languages are all ~20+ years old? Could it > also be that most programmers don't see a lot of incentives to make > things accessible, since they're already invested in the status quo, > and they might lose some personal value if programming stopped being > an arcane practice? Totally. That's why we're all still programming in assembly language and doing our own memory management, because we would lose a lot of personal value if programming stopped being so difficult. If it weren't for all these silly new-fangled languages with their automatic garbage collection and higher order function handling, we would all be commanding much higher salaries. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-30 22:07 -0700 |
| Message-ID | <d1e1a16c-caa8-4b55-ae7c-00ba25f7b906@vy9g2000pbc.googlegroups.com> |
| In reply to | #22393 |
On Mar 30, 1:20 pm, Chris Angelico <ros...@gmail.com> wrote: > > Really? Or could it be that algorithms for natural language > > processing that don't fail miserably is a very recent development, > > restricted natural languages more recent still, and pretty much all > > commonly used programming languages are all ~20+ years old? Could it > > also be that most programmers don't see a lot of incentives to make > > things accessible, since they're already invested in the status quo, > > and they might lose some personal value if programming stopped being > > an arcane practice? > > Totally. That's why we're all still programming in assembly language > and doing our own memory management, because we would lose a lot of > personal value if programming stopped being so difficult. If it > weren't for all these silly new-fangled languages with their automatic > garbage collection and higher order function handling, we would all be > commanding much higher salaries. > While I don't subscribe to the conspiracy theory that "programmers invest in arcane practices to preserve personal value" [paraphrase of Nathan], surely you could come up with a better argument than "garbage collection." Garbage collection was invented over 50 years ago (1959, according to Wikipedia), and it was implemented in a whole bunch of popular programming languages in the 90s (and earlier too, if you count Smalltalk as a popular language). Python's over 20 years old, and it had garbage collection pretty early on. Java's not quite 20 years old, but if Java is your best example of a "new-fangled" language with automatic garbage collection, then I have a hard time appreciating your sarcastic comments. There hasn't been much progress in programming language design in the last 20 years. It's been incremental at best. Nobody's really thinking outside the box, as far as I can tell. Please prove me wrong. It's true that we've moved past assembly language.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-04-03 08:06 +1000 |
| Message-ID | <mailman.1238.1333404389.3037.python-list@python.org> |
| In reply to | #22513 |
On Sat, Mar 31, 2012 at 4:07 PM, Steve Howell <showell30@yahoo.com> wrote: > On Mar 30, 1:20 pm, Chris Angelico <ros...@gmail.com> wrote: > >> Totally. That's why we're all still programming in assembly language >> and doing our own memory management, because we would lose a lot of >> personal value if programming stopped being so difficult. If it >> weren't for all these silly new-fangled languages with their automatic >> garbage collection and higher order function handling, we would all be >> commanding much higher salaries. >> > > While I don't subscribe to the conspiracy theory that "programmers > invest in arcane practices to preserve personal value" [paraphrase of > Nathan], surely you could come up with a better argument than "garbage > collection." GC is to programming what running water or a fridge is to a kitchen. It isn't exactly new, in fact you probably would expect it even in a fairly old kitchen, but you still wouldn't want to give it up. A somewhat newer example would be the ability to pass higher-order objects around - functions, mappings, lists, etc - and the basic concept that an expression resulting in (or function returning) an object is identical to a variable containing that object. Not every language supports that. > There hasn't been much progress in programming language design in the > last 20 years. It's been incremental at best. Nobody's really > thinking outside the box, as far as I can tell. Please prove me > wrong. > > It's true that we've moved past assembly language. Twenty years? That would almost certainly include solid Unicode support. Anything that dates back to 1992 is unlikely to truly acknowledge the difference between bytes and characters. That's probably incremental, but a fairly big increment. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Dan Sommers <dan@tombstonezero.net> |
|---|---|
| Date | 2012-03-30 16:51 -0400 |
| Message-ID | <mailman.1158.1333140695.3037.python-list@python.org> |
| In reply to | #22378 |
On Sat, 31 Mar 2012 07:20:39 +1100 Chris Angelico <rosuav@gmail.com> wrote: > ... That's why we're all still programming in assembly language and > doing our own memory management, because we would lose a lot of > personal value if programming stopped being so difficult. If it > weren't for all these silly new-fangled languages with their automatic > garbage collection and higher order function handling, we would all be > commanding much higher salaries. Back in the 1970's, the magazines were full of ads for "never write another line of code again" programs. A keystroke here, a keystroke there (those were the days *before* drag-and-drop and point-and-drool), and even managers and executives could "write programs." Now, of course, those managers and executives still command higher salaries, so I guess ChrisA is right about us assembly language guys losing our personal value. Dan
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-30 16:58 -0400 |
| Message-ID | <mailman.1159.1333141143.3037.python-list@python.org> |
| In reply to | #22378 |
On Fri, Mar 30, 2012 at 4:20 PM, Chris Angelico <rosuav@gmail.com> wrote: > On Sat, Mar 31, 2012 at 6:55 AM, Nathan Rice > <nathan.alexander.rice@gmail.com> wrote: >> I think you'd find that these "non coders" would do very well if given >> the ability to provide instructions in a natural, interactive way. >> They are not failing us, we are failing them. > > The nearest thing to natural-language command of a computer is voice > navigation, which is another science that's plenty old and yet still > current (I first met it back in 1996 and it wasn't new then). You tell > the computer what you want it to do, and it does it. Theoretically. > The vocabulary's a lot smaller than all of English, of course, but > that's not a problem. The problem is that it's really REALLY slow to > try to get anything done in English, compared to a dedicated > domain-specific language (in the case of typical OS voice navigation, > the nearest equivalent would probably be a shell script). I'm sure a ford truck would smoke a twin engine cessna if you compare their speed on the ground. Let the cessna fly and the ford doesn't have a snowball's chance. If you're navigating by going "cee dee space slash somefolder slash some other folder slash some third folder slash semicolon emacs somename dash some other name dash something dot something else dot one" the analogy would be a boss telling his secretary to reserve him a flight by saying "visit site xyz, click on this heading, scroll halfway down, open this menu, select this destination, ..." instead of "book me a flight to San Jose on the afternoon of the 23rd, and don't spend more than $500". > Totally. That's why we're all still programming in assembly language > and doing our own memory management, because we would lose a lot of > personal value if programming stopped being so difficult. If it > weren't for all these silly new-fangled languages with their automatic > garbage collection and higher order function handling, we would all be > commanding much higher salaries. Did you miss the fact that a 50 year old programming language (which still closely resembles its original form) is basically tied for the title of currently most popular, and the 3 languages following it are both nominal and spiritual successors, with incremental improvements in features but sharing a large portion of the design. Programming language designers purposefully try to make their language C-like, because not being C-like disqualifies a language from consideration for a HUGE portion of programmers, who cower at the naked feeling they get imagining a world without curly braces. Fear of change and the unknown are brutal, and humans are cowardly creatures that will grasp at whatever excuses they can find not to acknowledge their weaknesses. I also mentioned previously, most developers are just trying to graft shortcut after shortcut on to what is comfortable and familiar because we're inherently lazy. Additionally, I'm quite certain that when we finally do have a method for programming/interacting with computers in a natural way, many people invested in previous methods will make snarky comments about how lame and stupid people using the new methods are, just like we saw with command line/keyboard elitists who make fun of people who prefer a mouse/gui, even though in most cases research showed that the people using the mouse/gui actually got work done faster. You can even look at some comments on this thread for evidence of this.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-31 08:45 +1100 |
| Message-ID | <mailman.1160.1333143933.3037.python-list@python.org> |
| In reply to | #22378 |
On Sat, Mar 31, 2012 at 7:58 AM, Nathan Rice <nathan.alexander.rice@gmail.com> wrote: > Programming > language designers purposefully try to make their language C-like, > because not being C-like disqualifies a language from consideration > for a HUGE portion of programmers, who cower at the naked feeling they > get imagining a world without curly braces. Fear of change and the > unknown are brutal, and humans are cowardly creatures that will grasp > at whatever excuses they can find not to acknowledge their weaknesses. Braces are clear delimiters. English doesn't have them, and suffers for it. (Python's indentation is, too, but English doesn't have that either.) It's a lot harder to mark the end of an "if" block in English than in pretty much any programming language. And be careful of what has to be given up to gain your conveniences. I've used languages that demand variable declarations and ones that don't, and I'm very much a fan of the former. There are many benefits to being explicit about that. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-30 19:01 -0400 |
| Message-ID | <mailman.1162.1333148507.3037.python-list@python.org> |
| In reply to | #22378 |
On Fri, Mar 30, 2012 at 5:45 PM, Chris Angelico <rosuav@gmail.com> wrote: > On Sat, Mar 31, 2012 at 7:58 AM, Nathan Rice > <nathan.alexander.rice@gmail.com> wrote: >> Programming >> language designers purposefully try to make their language C-like, >> because not being C-like disqualifies a language from consideration >> for a HUGE portion of programmers, who cower at the naked feeling they >> get imagining a world without curly braces. Fear of change and the >> unknown are brutal, and humans are cowardly creatures that will grasp >> at whatever excuses they can find not to acknowledge their weaknesses. > > Braces are clear delimiters. English doesn't have them, and suffers > for it. (Python's indentation is, too, but English doesn't have that > either.) It's a lot harder to mark the end of an "if" block in English > than in pretty much any programming language. It seems to me that Indented blocks of text are used pretty frequently to denote definition bodies, section subordinate paragraphs and asides. The use of the colon seems pretty natural too. Parentheses are fairly natural for small asides. The notion of character delimiters for large sections of text is actually pretty unnatural with the exception of quotes. > And be careful of what has to be given up to gain your conveniences. > I've used languages that demand variable declarations and ones that > don't, and I'm very much a fan of the former. There are many benefits > to being explicit about that. I don't like declarations, my personal preference is to have typed signatures, and implicit declaration with type inference elsewhere. I view it as a matter of personal preference though, the result should be the same, and it should be possible to view the code either way.
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2012-03-31 00:03 -0400 |
| Message-ID | <mailman.1166.1333166645.3037.python-list@python.org> |
| In reply to | #22378 |
On 3/30/2012 6:47 AM, Steven D'Aprano wrote: > Spolsky has written at least three times about Architecture Astronauts, > and made it abundantly clear that the problem with them is that they > don't solve problems, they invent overarching abstractions that don't do > anything useful or important, and hype them everywhere. > > http://www.joelonsoftware.com/articles/fog0000000018.html > http://www.joelonsoftware.com/items/2005/10/21.html > http://www.joelonsoftware.com/items/2008/05/01.html > > Jeff Attwood provides a simple test for the difference between a useful > abstraction and an Architecture Astronaut hyper-abstraction: > > Does it solve a useful problem? > > http://www.codinghorror.com/blog/2004/12/it-came-from-planet-architecture.html My strong impression is that theoretical abstract mathematicians also prefer that hi-level abstractions solve some useful-to-mathematicians mathematical problem. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-31 19:05 +1100 |
| Message-ID | <mailman.1175.1333181144.3037.python-list@python.org> |
| In reply to | #22378 |
On Sat, Mar 31, 2012 at 10:01 AM, Nathan Rice <nathan.alexander.rice@gmail.com> wrote: > It seems to me that Indented blocks of text are used pretty frequently > to denote definition bodies, section subordinate paragraphs and > asides. The use of the colon seems pretty natural too. Parentheses > are fairly natural for small asides. The notion of character > delimiters for large sections of text is actually pretty unnatural > with the exception of quotes. Perhaps in formal written English, but not in spoken, and often not in casual writing either. Play around with my actual example, an "if" clause, and see where the punctuation goes in English - and how easily you can construct ambiguous sentences. > I don't like declarations, my personal preference is to have typed > signatures, and implicit declaration with type inference elsewhere. I > view it as a matter of personal preference though, the result should > be the same, and it should be possible to view the code either way. I'm not sure what you mean by "typed signatures", can you elaborate please? ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-31 10:43 -0400 |
| Message-ID | <mailman.1181.1333204993.3037.python-list@python.org> |
| In reply to | #22378 |
On Sat, Mar 31, 2012 at 2:15 AM, Lie Ryan <lie.1296@gmail.com> wrote:
> On 03/21/2012 03:55 AM, Nathan Rice wrote:
>>
>> <snip>
>
> I think you've just described that greedy algorithm can't always find the
> globally optimal solution.
Right. Using gradient descent on an algebraic surface is probably the
most natural example of why this is the case, since balls rolling down
a surface from a starting point to the bottom of a bowl is an exact
analogy.
On Sat, Mar 31, 2012 at 4:05 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, Mar 31, 2012 at 10:01 AM, Nathan Rice
> <nathan.alexander.rice@gmail.com> wrote:
>> It seems to me that Indented blocks of text are used pretty frequently
>> to denote definition bodies, section subordinate paragraphs and
>> asides. The use of the colon seems pretty natural too. Parentheses
>> are fairly natural for small asides. The notion of character
>> delimiters for large sections of text is actually pretty unnatural
>> with the exception of quotes.
>
> Perhaps in formal written English, but not in spoken, and often not in
> casual writing either. Play around with my actual example, an "if"
> clause, and see where the punctuation goes in English - and how easily
> you can construct ambiguous sentences.
Sure
an event has occurred recently if it occurred in the last time step.
if xyz has occurred recently, that implies abc will occur in the next time step.
when event abc occurs, all unbound floops become bound, and at most
three newly bound floops are eaten by blargs.
blargs that have not eaten in the last 3 time steps eat before blargs
that have eaten in those time steps.
Notice I don't talk about HOW anything is done, just the logic of what
is happening. The computer should be capable of making an inventory
of exactly what it will need to do given the statements I have made,
and choose the best data structures and algorithms for the job. If we
are in undecidable/halting problem territory (indefinite recursion)
then the computer should at least be nice enough to tell you it is
confused and would like some help.
>> I don't like declarations, my personal preference is to have typed
>> signatures, and implicit declaration with type inference elsewhere. I
>> view it as a matter of personal preference though, the result should
>> be the same, and it should be possible to view the code either way.
>
> I'm not sure what you mean by "typed signatures", can you elaborate please?
Just like the standard way in the Haskell community. To demonstrate
using Python annotations...
def myfunc(Sequence : a, Integral : b, Map : c) -> Sequence:
...
Given starting types and ending types, you can correctly infer some
VERY complex internal types. Haskell will let you omit signature types
as well, but that is really a bad idea because they add readability
and you will have to add them often anyhow if you are dealing with
complex types. Better to be consistent...
As a funny aside, people usually provide input type and return type
annotations to python functions, as part of the docstring (for
sphinx).
To be honest, I like having types baked into my code, though not
nominal types (the sort that is an A because it was declared as an A
or a subclass of A), but rather structural types (i.e. Abstract base
classes, or Java interfaces, if you didn't have to add the implements
...). I don't like having to verbosely tell the computer about the
types of everything I'm going to use, I only care that it gives me the
output I want if I give it some agreed upon input. It should be smart
enough to check the little things.
[toc] | [prev] | [next] | [standalone]
| From | rusi <rustompmody@gmail.com> |
|---|---|
| Date | 2012-03-30 11:17 -0700 |
| Message-ID | <c5150c24-d6d5-4e3e-8f0c-1f90e3ca8ef2@sv8g2000pbc.googlegroups.com> |
| In reply to | #22378 |
On Mar 30, 9:02 pm, Steve Howell <showel...@yahoo.com> wrote: > 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. A non-science/math analogous question: When Beethoven wrote his last sonatas and quartets they were called 'the abortions of a German idealist' or less charitably the only music that a stone-deaf man could possibly write Likewise, Bach's wrote Art of Fugue was regarded as a merely academic work that codified his knowledge of fugal writing. It was many decades after their death that everyone began to regard these as the greatest pieces of music (maybe 50 for Beethoven, almost 100 for Bach). However for every one Bach/Beethoven there are 100s of fadists who are great in one generation and garbage-dumped the next. The encyclopedia of music I grew up on regarded Schoenberg et al in the Bach/Beethoven category. Almost certainly a more recent view would not. So if I side with Steven/Spolsky I would regard a (future) Bach/ Beethoven as an 'abortion.' If I side with Nathan I may waste my money and life betting on serialists/cubists and such fashionable but ephemeral fads. tl;dr version The usefulness of uber-abstractions is undecidable in the near timeframe.
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.lang.python
csiph-web