Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #56759 > unrolled thread

Python was designed (was Re: Multi-threading in Python vs Java)

Back to article view | Back to comp.lang.python

Contents

  Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-13 09:37 +1100
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-13 03:38 +0000
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-13 15:34 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Roy Smith <roy@panix.com> - 2013-10-13 09:04 -0400
        Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-14 03:39 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) John Nagle <nagle@animats.com> - 2013-10-14 12:18 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-15 09:43 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-15 10:11 +1100
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve@pearwood.info> - 2013-10-15 08:50 +0000
          Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-15 08:48 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-14 18:31 -0700
        Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-14 20:02 -0700
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-15 13:26 -0700
            Re: Python was designed (was Re: Multi-threading in Python vs Java) Grant Edwards <invalid@invalid.invalid> - 2013-10-15 21:46 +0000
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-16 10:45 -0700
                Re: Python was designed (was Re: Multi-threading in Python vs Java) Grant Edwards <invalid@invalid.invalid> - 2013-10-16 18:42 +0000
            Re: Python was designed (was Re: Multi-threading in Python vs Java) "Rhodri James" <rhodri@wildebst.demon.co.uk> - 2013-10-15 23:01 +0100
              Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-15 21:45 -0700
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-16 10:57 -0700
                Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-16 11:25 -0700
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Skip Montanaro <skip@pobox.com> - 2013-10-16 13:49 -0500
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-17 07:40 +1100
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-16 17:13 -0700
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-17 11:28 +1100
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Ned Batchelder <ned@nedbatchelder.com> - 2013-10-16 20:47 -0400
                    Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-16 18:30 -0700
                      Re: Python was designed (was Re: Multi-threading in Python vs Java) Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-10-17 11:20 +0300
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-16 17:53 -0700
                    Re: Python was designed Piet van Oostrum <piet@vanoostrum.org> - 2013-10-16 22:33 -0400
                    Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve@pearwood.info> - 2013-10-17 05:24 +0000
                    Re: Python was designed (was Re: Multi-threading in Python vs Java) Grant Edwards <invalid@invalid.invalid> - 2013-10-17 13:43 +0000
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-17 12:01 +1100
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Ned Batchelder <ned@nedbatchelder.com> - 2013-10-16 22:09 -0400
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-17 08:02 +0100
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-17 07:49 -0700
                    Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-18 01:52 +0000
                      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-17 19:08 -0700
                        Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-17 20:34 -0700
                        Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-18 03:56 +0000
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-18 02:00 +1100
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-17 16:00 +0100
                Re: Python was designed (was Re: Multi-threading in Python vs Java) Grant Edwards <invalid@invalid.invalid> - 2013-10-16 18:44 +0000
                Re: Python was designed (was Re: Multi-threading in Python vs Java) alex23 <wuwei23@gmail.com> - 2013-10-17 10:26 +1000
            Re: Python was designed Piet van Oostrum <piet@vanoostrum.org> - 2013-10-15 23:20 -0400
            Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-15 20:53 -0700
            Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-17 10:32 -0700
              Re: Python was designed (was Re: Multi-threading in Python vs Java) MRAB <python@mrabarnett.plus.com> - 2013-10-17 18:44 +0100
                Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-17 20:15 -0700
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-17 19:08 +0100
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-17 12:49 -0700
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Ned Batchelder <ned@nedbatchelder.com> - 2013-10-17 16:57 -0400
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Ethan Furman <ethan@stoneleaf.us> - 2013-10-17 15:10 -0700
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-17 18:59 -0700
                Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-18 02:57 +0000
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-15 23:48 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Terry Reedy <tjreedy@udel.edu> - 2013-10-14 21:35 -0400
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Roy Smith <roy@panix.com> - 2013-10-14 21:50 -0400
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-15 08:21 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-15 12:48 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Janssen <dreamingforward@gmail.com> - 2013-10-14 19:11 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-15 13:19 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-15 03:18 +0000
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-15 14:29 +1100
        Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-14 20:48 -0700
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve@pearwood.info> - 2013-10-15 05:51 +0000
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-10-15 09:48 +0200
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-15 19:57 +1100
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-15 15:01 +0000
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-16 06:09 +1100
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Tim Chase <python.list@tim.thechases.com> - 2013-10-15 16:17 -0500
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-10-15 12:26 +0200
      Re: Python was designed (was Re: Multi-threading in Python vs Java) wxjmfauth@gmail.com - 2013-10-15 13:11 -0700
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-15 22:00 +0100
          Re: Python was designed (was Re: Multi-threading in Python vs Java) wxjmfauth@gmail.com - 2013-10-24 23:14 -0700
            Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 19:05 +0100
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-26 04:46 +0000
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-14 14:11 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-14 22:43 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-15 09:45 +1100
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-15 17:18 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-16 23:49 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-17 18:15 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-17 05:39 -0700
        Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-17 06:00 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Terry Reedy <tjreedy@udel.edu> - 2013-10-17 16:15 -0400
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-17 21:41 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-18 03:14 +0000
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-18 15:12 +1100
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-18 04:45 +0000
            Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-18 15:53 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-19 09:57 +0000
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-19 21:49 +1100
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-17 00:23 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Christian Gollwitzer <auriocus@gmx.de> - 2013-10-17 09:42 +0200
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-17 19:24 +1100
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-18 01:58 +0000
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Piet van Oostrum <piet@vanoostrum.org> - 2013-10-17 12:58 -0400
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-17 12:37 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Roy Smith <roy@panix.com> - 2013-10-17 20:01 -0400
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-18 11:09 +1100
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-17 13:54 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-18 13:32 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-18 21:41 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-18 22:26 -0700
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-19 16:35 +1100
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-21 02:07 +0000
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Roy Smith <roy@panix.com> - 2013-10-20 22:21 -0400
            Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-20 21:44 -0700
          Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-21 17:56 +1100
            Re: Python was designed (was Re: Multi-threading in Python vs Java) Roy Smith <roy@panix.com> - 2013-10-21 09:05 -0400
              Re: Python was designed (was Re: Multi-threading in Python vs Java) Lele Gaifax <lele@metapensiero.it> - 2013-10-22 09:38 +0200
                Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve@pearwood.info> - 2013-10-23 08:16 +0000
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Ned Batchelder <ned@nedbatchelder.com> - 2013-10-23 06:36 -0400
                    Re: Python was designed (was Re: Multi-threading in Python vs Java) Grant Edwards <invalid@invalid.invalid> - 2013-10-23 14:21 +0000
                  Re: Python was designed (was Re: Multi-threading in Python vs Java) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-10-24 00:31 +1300
                    Re: Python was designed (was Re: Multi-threading in Python vs Java) Lele Gaifax <lele@metapensiero.it> - 2013-10-23 17:56 +0200
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-18 13:56 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-20 23:44 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-21 18:01 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-21 08:27 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-21 18:31 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-21 08:39 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-21 18:43 +1100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-21 09:11 +0100
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve@pearwood.info> - 2013-10-21 08:24 +0000
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Metallicow <metaliobovinus@gmail.com> - 2013-10-21 01:39 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-21 01:43 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Metallicow <metaliobovinus@gmail.com> - 2013-10-21 02:17 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-21 05:50 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 02:29 +0000
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Skip Montanaro <skip@pobox.com> - 2013-10-22 07:02 -0500
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Metallicow <metaliobovinus@gmail.com> - 2013-10-23 22:31 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-21 19:55 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) rusi <rustompmody@gmail.com> - 2013-10-21 20:19 -0700
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-22 17:13 +1100
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-22 00:51 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-25 01:12 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-26 06:19 +0000
        Re: Python was designed (was Re: Multi-threading in Python vs Java) Chris Angelico <rosuav@gmail.com> - 2013-10-26 17:36 +1100
      Re: Python was designed Paul Rubin <no.email@nospam.invalid> - 2013-10-26 10:36 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-25 23:59 -0700
    Re: Python was designed (was Re: Multi-threading in Python vs Java) Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-26 12:24 -0700
      Re: Python was designed (was Re: Multi-threading in Python vs Java) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-26 22:31 +0100

Page 1 of 8  [1] 2 3 4 5 6 7 8  Next page →

#56759 — Python was designed (was Re: Multi-threading in Python vs Java)

On Sat, Oct 12, 2013 at 7:10 AM, Peter Cacioppi
<peter.cacioppi@gmail.com> wrote:
> Along with "batteries included" and "we're all adults", I think Python needs a pithy phrase summarizing how well thought out it is. That is to say, the major design decisions were all carefully considered, and as a result things that might appear to be problematic are actually not barriers in practice. My suggestion for this phrase is "Guido was here".

"Designed".

You simply can't get a good clean design if you just let it grow by
itself, one feature at a time. You'll end up with something where you
can do the same sort of thing in three different ways, and they all
have slightly different names:

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/#general

(Note, I'm not here to say that PHP is awful and Python is awesome
(they are, but I'm not here to say it). It's just that I can point to
a blog post that shows what I'm saying.)

Design is why, for instance, Python's builtin types all behave the
same way with regard to in-place mutator methods: they don't return
self. I personally happen to quite like the "return self" style, as it
allows code like this:

GTK2.MenuBar()
    ->add(GTK2.MenuItem("_File")->set_submenu(GTK2.Menu()
        ->add(menuitem("_New Tab",addtab)->add_accelerator(...))
        ->add(menuitem("Close tab",closetab)->add_accelerator(...))
        ... etc ...
    ))
    ->add(GTK2.MenuItem("_Options")->set_submenu(GTK2.Menu()
        ->add(menuitem("_Font",fontdlg))
        ... etc ...
    ))
    ... etc ...

It's a single expression (this is from Pike, semantically similar to
Python) that creates and sets up the whole menu bar. Most of Pike's
object methods will return this (aka self) if it's believed to be of
use. The Python equivalent, since the .add() method on GTK objects
returns None, is a pile of code with temporary names. But that's a
smallish point of utility against a large point of consistency;
newbies can trust that a line like:

lst = lst.sort()

will trip them up immediately (since lst is now None), rather than
surprise them later when they try to make a sorted copy of the list:

sorted_lst = lst.sort()

which, if list.sort returned self, would leave you with sorted_lst is
lst, almost certainly not what the programmer intended.

Oh, and the use of exceptions everywhere is a sign of design, too.
Something went wrong that means you can't return a plausible value?
Raise.

>>> json.loads("{")
ValueError: Expecting object: line 1 column 0 (char 0)

>>> pickle.loads(b"\x80")
EOFError

Etcetera. PHP borrows from C in having piles and piles of "was there
an error" functions; there's no consistency in naming, nor (in many
cases) in the return values. Pike generally raises exceptions, but I/O
failure usually results in a zero return and the file object's errno
attribute set; but at least they're consistent error codes.

This is design. Python has a king (Guido). It wasn't built by a
committee. Maybe you won't like some aspect of Python's design, but it
has one, it's not just sloppily slapped together.

ChrisA

[toc] | [next] | [standalone]

#56760

On Sun, 13 Oct 2013 09:37:58 +1100, Chris Angelico wrote:

> This is design. Python has a king (Guido). It wasn't built by a
> committee. Maybe you won't like some aspect of Python's design, but it
> has one, it's not just sloppily slapped together.


While I agree with your general thrust, I don't think it's quite so 
simple. Perl has a king, Larry Wall, but his design is more or less 
"throw everything into the pot, it'll be fine" and consequently Perl is, 
well, *weird*, with some pretty poor^W strange design decisions.

- Subroutines don't have signatures, you have to parse arguments 
  yourself by popping values off the magic variable @_ .

- More special variables than you can shake a stick at: @_ $_ $a $b @ARGV
  $& ${^ENCODING} $. $| $= $$ $^O $^S @F and many, many more.

- Context sensitivity: these two lines do very different things:

      $foo = @bar
      @foo = @bar 

  and so do these two:

      my($foo) = `bar`
      my $foo = `bar`

- Sigils. Sigils everywhere.

- Separate namespaces for scalars, arrays, hashes, filehandles,
  and subroutines (did I miss anything?), co-existing in the same 
  scope, all the better for writing code like this:

      $bar = &foo($foo, $foo[1], $foo{1})

  If you think that all three references to $foo refer to the same
  variable, you would be wrong.

- Two scoping systems (dynamic and lexical) which don't cooperate.

- Strangers to Perl might think that the way to create a local variable
  is to define it as local:

      local $foo;

  but you'd be wrong. "local" does something completely different. To
  create a local variable, use "my $foo" instead.


More here: http://perl.plover.com/FAQs/Namespaces.html


Likewise Rasmus Lerdorf, king of PHP (at least initially), but he had no 
idea what he was doing:

"I had no intention of writing a language. I didn't have a clue how to 
write a language. I didn't want to write a language," Lerdorf explained. 
"I just wanted to solve a problem of churning out Web applications very, 
very fast."

http://www.devshed.com/c/a/PHP/PHP-Creator-Didnt-Set-Out-to-Create-a-Language/



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#56761

On Sun, Oct 13, 2013 at 2:38 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sun, 13 Oct 2013 09:37:58 +1100, Chris Angelico wrote:
>
>> This is design. Python has a king (Guido). It wasn't built by a
>> committee. Maybe you won't like some aspect of Python's design, but it
>> has one, it's not just sloppily slapped together.
>
>
> While I agree with your general thrust, I don't think it's quite so
> simple. Perl has a king, Larry Wall, but his design is more or less
> "throw everything into the pot, it'll be fine" and consequently Perl is,
> well, *weird*, with some pretty poor^W strange design decisions.

My apologies, I wasn't exactly clear. Having a king doesn't in any way
guarantee a clean design...

> Likewise Rasmus Lerdorf, king of PHP (at least initially), but he had no
> idea what he was doing:
>
> "I had no intention of writing a language. I didn't have a clue how to
> write a language. I didn't want to write a language," Lerdorf explained.
> "I just wanted to solve a problem of churning out Web applications very,
> very fast."

... yeah, what he said; but having no king pretty much condemns a
project to design-by-committee. Python has a king and a clear design.

In any case, we're broadly in agreement here. It's design that makes
Python good. That's why the PEP system and the interminable
bike-shedding on python-dev is so important... and why, at the end of
the day, the PEP's acceptance comes down to one person (Guido or a
BDFL-Delegate).

ChrisA

[toc] | [prev] | [next] | [standalone]

#56771

In article <525a15ad$0$29984$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> While I agree with your general thrust, I don't think it's quite so 
> simple. Perl has a king, Larry Wall, but his design is more or less 
> "throw everything into the pot, it'll be fine" and consequently Perl is, 
> well, *weird*, with some pretty poor^W strange design decisions.

To be fair to Larry, there were different design drivers working there.

Pre-perl, people built humungous shell scripts, duct-taping together 
little bits of sed, grep, awk, and other command-line tools.  What perl 
did, was make it easier to use the functionality of those disparate 
tools together in a single language.  By holding on to the little bits 
of syntax from the precursor languages, he kept the result familiar 
feeling, so Unix sysadmins (who were the main audience for perl) were 
willing to adopt it.

It was wildly successful, not because it was perfect, but because it 
beat the pants off what came before it.

[toc] | [prev] | [next] | [standalone]

#56799

On Sunday, October 13, 2013 6:34:56 PM UTC+5:30, Roy Smith wrote:
> To be fair to Larry, there were different design drivers working there.

One more thing to be said for perl: 

I remember when some colleague first told me about perl (I guess early 90s) I was incredulous that the *same* language could run on DOS and on Unix unchanged.
Yeah in principle we all talked about portability however in practice, we found that the only program that would run on all systems was the asymptotic null C program:
main() {;}

So a full scale language whose programs ran unchanged on all systems was BIG back then.

That we take it for granted today indicates the shoulders of the giants we are standing on.

[toc] | [prev] | [next] | [standalone]

#56818

On 10/12/2013 3:37 PM, Chris Angelico wrote:
> On Sat, Oct 12, 2013 at 7:10 AM, Peter Cacioppi 
> <peter.cacioppi@gmail.com> wrote:
>> Along with "batteries included" and "we're all adults", I think
>> Python needs a pithy phrase summarizing how well thought out it is.
>> That is to say, the major design decisions were all carefully
>> considered, and as a result things that might appear to be
>> problematic are actually not barriers in practice. My suggestion
>> for this phrase is "Guido was here".
> 
> "Designed".
> 
> You simply can't get a good clean design if you just let it grow by 
> itself, one feature at a time.

    No, Python went through the usual design screwups.  Look at how
painful the slow transition to Unicode was, from just "str" to
Unicode strings, ASCII strings, byte strings, byte arrays,
16 and 31 bit character builds, and finally automatic switching
between rune widths. Old-style classes vs. new-style classes.  Adding a
boolean type as an afterthought (that was avoidable; C went through
that painful transition before Python was created).    Operator "+"
as concatenation for built-in arrays but addition for NumPy
arrays.

    Each of those reflects a design error in the type system which
had to be corrected.

    The type system is now in good shape. The next step is to
make Python fast.  Python objects have dynamic operations suited
to a naive interpreter like CPython.  These make many compile
time optimizations hard. At any time, any thread can monkey-patch
any code, object, or variable in any other thread.  The ability
for anything to use "setattr()" on anything carries a high
performance price.  That's part of why Unladen Swallow failed
and why PyPy development is so slow.

				John Nagle

[toc] | [prev] | [next] | [standalone]

#56827

On Tue, Oct 15, 2013 at 6:18 AM, John Nagle <nagle@animats.com> wrote:
> On 10/12/2013 3:37 PM, Chris Angelico wrote:
>> "Designed".
>>
>> You simply can't get a good clean design if you just let it grow by
>> itself, one feature at a time.
>
>     No, Python went through the usual design screwups.  Look at how
> painful the slow transition to Unicode was, from just "str" to
> Unicode strings, ASCII strings, byte strings, byte arrays,
> 16 and 31 bit character builds, and finally automatic switching
> between rune widths. Old-style classes vs. new-style classes.  Adding a
> boolean type as an afterthought (that was avoidable; C went through
> that painful transition before Python was created).    Operator "+"
> as concatenation for built-in arrays but addition for NumPy
> arrays.
>
>     Each of those reflects a design error in the type system which
> had to be corrected.

Oh, Python's design wasn't perfect - that's a pretty much impossible
goal anyway. Sometimes you don't learn what you ought to have done
till it's been in production for a while - that's why, for instance,
these happened:

https://wiki.theory.org/YourLanguageSucks#Fixed_in_Python_3

You'd have to be completely omniscient to avoid that kind of
misjudgment, and breaking backward compatibility is such a major cost
that sometimes design errors just have to be kept. But you'll still
end up with something far cleaner than would come from ad-hoc
undirected changes; it'll be a design with warts, rather than a lack
of design.

>     The type system is now in good shape. The next step is to
> make Python fast.  Python objects have dynamic operations suited
> to a naive interpreter like CPython.  These make many compile
> time optimizations hard. At any time, any thread can monkey-patch
> any code, object, or variable in any other thread.  The ability
> for anything to use "setattr()" on anything carries a high
> performance price.  That's part of why Unladen Swallow failed
> and why PyPy development is so slow.

Yeah, this does make things hard. But that dynamism is a fundamental
part of Python's design, even if it's used by almost nothing. I'd say
this isn't proof of a design error, just a consequence of a design
decision. Python isn't for everyone, nor for every task - sometimes
it'll be too slow for what you want. So be it! There are plenty of
places where it's good. And there are similar languages (hi Pike!) for
when you want a bit more performance.

ChrisA

[toc] | [prev] | [next] | [standalone]

#56831

On Tue, Oct 15, 2013 at 6:18 AM, John Nagle <nagle@animats.com> wrote:
>     No, Python went through the usual design screwups.
>     Each of [the below] reflects a design error in the type system which
> had to be corrected.

I'll pick up each one here as I think some of them need further discussion.

> Look at how painful the slow transition to Unicode was,
> from just "str" to Unicode strings, ASCII strings, byte strings, byte
> arrays, 16 and 31 bit character builds, and finally automatic
> switching between rune widths.

I'm not sure what you mean by all of these - I've known Python for
only a (relatively) short time, wasn't there in the 1.x days (much
less the <1.0 days). But according to its history page, the early 1.x
versions of Python predate the widespread adoption of Unicode, so it's
a little unfair to look with 2013 eyes and say that full true Unicode
support should have been there from the start. If anyone invents a
language today that doesn't handle Unicode properly, I would be very
much disappointed; but changing the meaning of quoted string literals
is a pretty major change. I'm just glad it got sorted out for 3.0. As
to the 16/32 bit builds, there aren't actually very many languages
that get this right; Python's now a blazing torch, showing the way for
others to follow. (Pike's had something very similar to PEP 393 for
years, but nobody looks to obscurities.) I hope we'll see other
languages start to follow suit.

> Old-style classes vs. new-style classes.

By the time I started using Python, new-style classes existed and were
the recommended way to do things, so I never got the "feel" for
old-style classes. I assume there was a simplicity to them, since
new-style classes were described as having a performance cost, but one
worth paying. My guess is it comes under the category of "would have
to be omniscient to recognize what would happen"; Steven, maybe you
can fill us in?

> Adding a
> boolean type as an afterthought (that was avoidable; C went through
> that painful transition before Python was created).

I don't know about that. Some languages get by just fine without
dedicated a boolean type. Python didn't have them, then it had them as
integers, now it has them as bools. Is it a major problem? (Apart from
adding them in a point release. That's an admitted mistake.) Python
doesn't have a 'vector' type either, you just use a tuple. Some things
don't need to be in the language, they can be pushed off to the
standard library. And speaking of which...

> Operator "+" as concatenation for built-in arrays but addition
> for NumPy arrays.

... NumPy definitely isn't part of the language. It's not even part of
the standard library, it's fully third-party. The language decrees
that [1,2] + [3,4] = [1,2,3,4], and that custom_object1 +
custom_object2 = custom_object1.__add__(custom_object2) more or less,
and then leaves the implementation of __add__ up to you. Maybe you'll
make an "Entropy" class, where entropy+=int blocks until it's acquired
that much more entropy (maybe from /dev/random), and entropy-int
returns a random number based on its current state. It makes a measure
of sense, if not what you normally would want. You can shoot yourself
in the foot in any language; and if you write something as big and
popular as NumPy, you get to shoot other people in the foot too! :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#56848

On Tue, 15 Oct 2013 10:11:53 +1100, Chris Angelico wrote:

> On Tue, Oct 15, 2013 at 6:18 AM, John Nagle <nagle@animats.com> wrote:

>> Old-style classes vs. new-style classes.
> 
> By the time I started using Python, new-style classes existed and were
> the recommended way to do things, so I never got the "feel" for
> old-style classes. I assume there was a simplicity to them, since
> new-style classes were described as having a performance cost, but one
> worth paying. My guess is it comes under the category of "would have to
> be omniscient to recognize what would happen"; Steven, maybe you can
> fill us in?

Heh, I'm not privy to why GvR decided to have built-in types and classes 
be distinct :-) but it wasn't a performance issue. The very first 
versions of Python didn't have user-defined types at all:

http://python-history.blogspot.com.au/2009/02/adding-support-for-user-
defined-classes.html

For a while classic classes were faster, but I don't think that's been 
the case for a long while now.

You can read up more about the unification of types and classes here:

http://www.python.org/download/releases/2.2.3/descrintro/

and the associated PEPs:

http://www.python.org/dev/peps/pep-0252/
http://www.python.org/dev/peps/pep-0253/


but note that the PEPs may no longer reflect the current implementation. 
The descrintro document above is interesting for its explanation of how 
descriptors work.


>> Adding a
>> boolean type as an afterthought (that was avoidable; C went through
>> that painful transition before Python was created).
> 
> I don't know about that. Some languages get by just fine without
> dedicated a boolean type. Python didn't have them, then it had them as
> integers, now it has them as bools. 

Actually, Python's bools *are* ints :-)


If you read the whole python-history blog on blogspot, you'll see that 
Python's had it's share of mistakes, design failures and other "oops!" 
moments. I think that it is a testament to GvR's over-all design that the 
end result has been so good, despite the mistakes, as well as Python's 
conservative-but-not-too-conservative approach to changes. Compared to 
(say) Firefox, which comes out with new releases seemingly twice a week, 
Python is slow to change and conservative; compared to (say) Fortran, 
which changes in a time-span of decades rather than years, it's quite 
fast moving. I think Python has more or less hit the sweet-spot.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#56853

On Tuesday, October 15, 2013 2:20:10 PM UTC+5:30, Steven D'Aprano wrote:
> If you read the whole python-history blog on blogspot, you'll see that 
> Python's had it's share of mistakes, design failures and other "oops!" 
> moments. I think that it is a testament to GvR's over-all design that the 
> end result has been so good, despite the mistakes, as well as Python's 
> conservative-but-not-too-conservative approach to changes. Compared to 
> (say) Firefox, which comes out with new releases seemingly twice a week, 
> Python is slow to change and conservative; compared to (say) Fortran, 
> which changes in a time-span of decades rather than years, it's quite 
> fast moving. I think Python has more or less hit the sweet-spot.

Yes heartily agree.

Mostly we have systems/software/languages that fall into one of two categories:
a. Completely immobile -- which means the only change is the inevitable bitrot of slow aging
b. So much blood that we cant see the 'edge' in the bleeding edge

That way python is surely in a sweetspot (for me):

In 2001 I started teaching programming with a computer projector (rather than chalk).  This meant that classes became more dynamic and alive but also my head was more than ever on the line -- with chalk-board you can occasionally fudge your way out with bullshit.  When the projector is displaying an unexpected result or a backtrace/segfault there is no such room!!

By chance(?) it was also the time I started teaching python.

And for these last 10+ years python has been like a faithful servant -- useful, unobtrusive, predictable.  The number of times Ive had  to say in a class: "Ok guys I dont know..." (In short I am screwed) is hardly a handful.

One of the very occasional embarrassing exceptions: 
https://mail.python.org/pipermail/python-list/2011-July/609362.html

[toc] | [prev] | [next] | [standalone]

#56833

On Mon, Oct 14, 2013 at 12:18 PM, John Nagle <nagle@animats.com> wrote:
> On 10/12/2013 3:37 PM, Chris Angelico wrote:
>> On Sat, Oct 12, 2013 at 7:10 AM, Peter Cacioppi
>> <peter.cacioppi@gmail.com> wrote:
>>> Along with "batteries included" and "we're all adults", I think
>>> Python needs a pithy phrase summarizing how well thought out it is.
>>> That is to say, the major design decisions were all carefully
>>> considered, and as a result things that might appear to be
>>> problematic are actually not barriers in practice. My suggestion
>>> for this phrase is "Guido was here".
>>
>> "Designed".
>>
>> You simply can't get a good clean design if you just let it grow by
>> itself, one feature at a time.
>
>     No, Python went through the usual design screwups.

I hesitate to poke my nose in here, but Python is fine.  No one knows
how to design the perfect language from the start, otherwise it would
be here.   But Python has set the precedent for allowing
backwards-incompatibility to fix language problems and that's what
will keep it from breaking.

> Look at how
> painful the slow transition to Unicode was, from just "str" to
> Unicode strings, ASCII strings, byte strings, byte arrays,

This is where I wish I could have been involved with the discussion,
but I was outside of civilization at the time, and was not able to
contribute.

> 16 and 31 bit character builds, and finally automatic switching
> between rune widths. Old-style classes vs. new-style classes.  Adding a
> boolean type as an afterthought (that was avoidable; C went through
> that painful transition before Python was created).    Operator "+"
> as concatenation for built-in arrays but addition for NumPy
> arrays.

All of this will get fixed, but the problem is that you are stirring
up issues without really understanding the problem.   The problem is
something that is at the bleeding-edge of Computer Science itself and
settling on a theory of types.  I've answered this by creating a
unified object model, but no one has understood why the hell anyone
needs one, so I'm sitting around waiting for a friend..

>     Each of those reflects a design error in the type system which
> had to be corrected.

To call it a "design error" makes it seem like someone make a decision
that resulted in a mistake, but it isn't (wasn't) that simple.

>     The type system is now in good shape. The next step is to
> make Python fast.

Woah, boy.  There's no reason to make an incomplete design faster, for
psuedo-problems that no one will care about in 5-10 years.  The field
has yet to realize that it needs an object model, or even what that
is.

> Python objects have dynamic operations suited
> to a naive interpreter like CPython.

Naive, no.

> These make many compile
> time optimizations hard. At any time, any thread can monkey-patch
> any code, object, or variable in any other thread.  The ability
> for anything to use "setattr()" on anything carries a high
> performance price.  That's part of why Unladen Swallow failed
> and why PyPy development is so slow.

Yes, and all of that is because, the world has not settled on some
simple facts.  It needs an understanding of type system.  It's been
throwing terms around, some of which are well-defined, but others,
not:  there has been enormous cross-breeding that has made mutts out
of everybody and someone's going to have to eat a floppy disk for
feigning authority where there wasn't any.

Mark J
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#56839

On Tuesday, October 15, 2013 7:01:37 AM UTC+5:30, zipher wrote:
> Yes, and all of that is because, the world has not settled on some
> simple facts.  It needs an understanding of type system.  It's been
> throwing terms around, some of which are well-defined, but others,
> not:  there has been enormous cross-breeding that has made mutts out
> of everybody and someone's going to have to eat a floppy disk for
> feigning authority where there wasn't any.

Objects in programming languages (or 'values' if one is more functional programming oriented) correspond to things in the world.
Types on the other hand correspond to our classifications and so are things in our minds.
So for the world 'to settle' on a single universal type system is about as nonsensical and self contradictory as you and I having the same thoughts.

To see how completely nonsensical a classification system of a so-called alien culture is, please read:
http://en.wikipedia.org/wiki/Celestial_Emporium_of_Benevolent_Knowledge

And then reflect that the passage is implying that CONVERSELY our natural/obvious/FACTual classifications would appear similarly nonsensical to them.

The same in the world of programming languages:

Here's an APL session
$ ./apl 
                                       
                        Welcome to GNU APL version 1.0
      1 + 2
3
      1 + 2 3 4
3 4 5
      1 = 2
0
      1 2 3 = 2 3 4
0 0 0
      1 = 1 2 3
1 0 0
     2 ≥ 1 2 3
1 1 0


a perfectly good (and for many of us old-timers a very beautiful) type system
but completely incompatible with anything designed in the last 40 years!
[Hell it does not even have a prompt!
Also note the character-set (≥ not >=) -- long before unicode not an emasculated deference to ASCII

[toc] | [prev] | [next] | [standalone]

#56859

> Objects in programming languages (or 'values' if one is more functional programming oriented) correspond to things in the world.

One of the things you're saying there is that "values correspond to
things in the world".  But you will not get agreement in computer
science on that anymore than saying "numbers correspond to things in
the world" -- they are abstractions that are not supposed to
correspond to things.  (Objects, OTOH, were intended to, so your
statement has mixed truthiness.)

> Types on the other hand correspond to our classifications and so are things in our minds.

That is not how a C programmer views it.  They have explicit
"typedef"s that make it a thing for the computer.

> So for the world 'to settle' on a single universal type system is about as nonsensical and self contradictory as you and I having the same thoughts.

Yes, well clearly we are not "having the same thoughts", yet the
purpose of the academic establishment is to pin down such terminology
and not have these sloppy understandings everywhere.  You dig?

> To see how completely nonsensical a classification system of a so-called alien culture is, please read:
> http://en.wikipedia.org/wiki/Celestial_Emporium_of_Benevolent_Knowledge
>
> And then reflect that the passage is implying that CONVERSELY our natural/obvious/FACTual classifications would appear similarly nonsensical to them.
>
> The same in the world of programming languages:

No.  There is one world in which the computer is well-defined.  All
others are suspect.

> Here's an APL session
> $ ./apl
> a perfectly good (and for many of us old-timers a very beautiful) type system
> but completely incompatible with anything designed in the last 40 years!

Yeah, well 40 years ago they didn't have parsers.   The purpose of
having a field of computer science worthy of the name, is to advance
the science not let this riff-raff dominate the practice.

-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#56862

On 2013-10-15, Mark Janssen <dreamingforward@gmail.com> wrote:

> Yeah, well 40 years ago they didn't have parsers.

That seems an odd thing to say. People were assembling and compiling
computer programs long before 1973.

How did they do that without parsers?

-- 
Grant Edwards               grant.b.edwards        Yow! Of course, you
                                  at               UNDERSTAND about the PLAIDS
                              gmail.com            in the SPIN CYCLE --

[toc] | [prev] | [next] | [standalone]

#56888

On Tue, Oct 15, 2013 at 2:46 PM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2013-10-15, Mark Janssen <dreamingforward@gmail.com> wrote:
>
>> Yeah, well 40 years ago they didn't have parsers.
>
> That seems an odd thing to say. People were assembling and compiling
> computer programs long before 1973.

I'm using the word "parser" in the sense of a stand-alone application
that became useful with the growing open source culture that was
developing in the 70's.  Prior to that you have punch cards where
there's no meaningful definition of "parsing" because there are no
tokens.  Would you say you were "parsing" on an old digital machine
where you input programs with binary switches?

But after the advent of the dumb terminal, parsers started evolving,
and that was the early 70's.  I might be a year or two off, but I only
gave one significant digit there.   ;^)

Cheers,
-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#56891

On 2013-10-16, Mark Janssen <dreamingforward@gmail.com> wrote:
> On Tue, Oct 15, 2013 at 2:46 PM, Grant Edwards <invalid@invalid.invalid> wrote:
>> On 2013-10-15, Mark Janssen <dreamingforward@gmail.com> wrote:
>>
>>> Yeah, well 40 years ago they didn't have parsers.
>>
>> That seems an odd thing to say. People were assembling and compiling
>> computer programs long before 1973.
>
> I'm using the word "parser" in the sense of a stand-alone application
> that became useful with the growing open source culture that was
> developing in the 70's.  Prior to that you have punch cards where
> there's no meaningful definition of "parsing" because there are no
> tokens.

What do you mean "there are no tokens?".   Pascal/Fortran/COBOL on
a deck of punched cards is parsed/compiled the same as it is in a file
on a hard drive.

> Would you say you were "parsing" on an old digital machine
> where you input programs with binary switches?

No, that's not what I'm talking about.  I'm talking about compiling
Fortran or PL/1 or whatnot.

> But after the advent of the dumb terminal, parsers started evolving,
> and that was the early 70's.  I might be a year or two off, but I only
> gave one significant digit there.   ;^)

I don't understand what dumb terminals have to do with it.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm GLAD I
                                  at               remembered to XEROX all
                              gmail.com            my UNDERSHIRTS!!

[toc] | [prev] | [next] | [standalone]

#56863

On Tue, 15 Oct 2013 21:26:27 +0100, Mark Janssen  
<dreamingforward@gmail.com> wrote:

>> = Rusi, attribution missing from original.

>> Objects in programming languages (or 'values' if one is more functional  
>> programming oriented) correspond to things in the world.
>
> One of the things you're saying there is that "values correspond to
> things in the world".  But you will not get agreement in computer
> science on that anymore than saying "numbers correspond to things in
> the world" -- they are abstractions that are not supposed to
> correspond to things.  (Objects, OTOH, were intended to, so your
> statement has mixed truthiness.)
>
>> Types on the other hand correspond to our classifications and so are  
>> things in our minds.
>
> That is not how a C programmer views it.  They have explicit
> "typedef"s that make it a thing for the computer.

Speaking as a C programmer, no.  We have explicit typedefs to create new  
labels for existing types, to make the type-abstraction easier to relate  
to the object-abstraction.  Not that I personally think of C objects as  
abstractions, I'm rather with Rusi on that, but if you do then the object  
type must be an abstracted abstraction.  At which point my head starts to  
hurt and I'll get back to some engineering if you don't mind.

>> The same in the world of programming languages:
>
> No.  There is one world in which the computer is well-defined.  All
> others are suspect.

Perhaps, though I'm personally rather dubious of that claim.  Proving  
well-definedness may be rather interesting.

> Yeah, well 40 years ago they didn't have parsers.   The purpose of
> having a field of computer science worthy of the name, is to advance
> the science not let this riff-raff dominate the practice.

That is an utterly ludicrous statement (and grammatically suspect to boot)  
that does nothing to bolster my confidence in your philosophising.

-- 
Rhodri James *-* Wildebeest Herder to the Masses

[toc] | [prev] | [next] | [standalone]

#56869

On Wednesday, October 16, 2013 3:31:06 AM UTC+5:30, Rhodri James wrote:
> On Tue, 15 Oct 2013 21:26:27 +0100, Mark Janssen  
> wrote:
> 
> >> = Rusi, attribution missing from original.

Yes. It would help to keep your quotes bound (firstclassly?) to their respective quoters -- Mark Janssen also and Peter Cacioppi also.

[toc] | [prev] | [next] | [standalone]

#56889

>>> Types on the other hand correspond to our classifications and so are
>>> things in our minds.
>>
>> That is not how a C programmer views it.  They have explicit
>> "typedef"s that make it a thing for the computer.
>
> Speaking as a C programmer, no.  We have explicit typedefs to create new
> labels for existing types, to make the type-abstraction easier to relate to
> the object-abstraction.

Who uses "object abstraction" in C?  No one.  That's why C++ was invented.

-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#56890

On Wednesday, October 16, 2013 11:27:03 PM UTC+5:30, zipher wrote:
> >>> Types on the other hand correspond to our classifications and so are
> >>> things in our minds.
> >>
> >> That is not how a C programmer views it.  They have explicit
> >> "typedef"s that make it a thing for the computer.
> >
> > Speaking as a C programmer, no.  We have explicit typedefs to create new
> > labels for existing types, to make the type-abstraction easier to relate to
> > the object-abstraction.
> 
> Who uses "object abstraction" in C?  No one.  That's why C++ was invented.

I wonder if you've heard of something called linux?
http://lwn.net/Articles/444910/

[toc] | [prev] | [next] | [standalone]

Page 1 of 8  [1] 2 3 4 5 6 7 8  Next page →

Back to top | Article view | comp.lang.python

csiph-web