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

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

Experiences/guidance on teaching Python as a first programming language

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

Contents

  Experiences/guidance on teaching Python as a first programming language Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-12-09 12:23 +0000
    Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-09 05:54 -0800
    Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-09 08:57 -0800
      Re: Experiences/guidance on teaching Python as a first programming language William Ray Wing <wrw@mac.com> - 2013-12-09 12:55 -0500
      Re: Experiences/guidance on teaching Python as a first programming language Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-10 18:25 +1300
        Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-10 16:55 +1100
          Re: Experiences/guidance on teaching Python as a first programming   language Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-11 10:38 +1300
        Re: Experiences/guidance on teaching Python as a first programming language Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-10 20:35 -0500
          Re: Experiences/guidance on teaching Python as a first programming language Denis McMahon <denismfmcmahon@gmail.com> - 2013-12-11 02:16 +0000
            Re: Experiences/guidance on teaching Python as a first programming language Larry Martell <larry.martell@gmail.com> - 2013-12-11 07:08 -0500
          Re: Experiences/guidance on teaching Python as a first programming language Grant Edwards <invalid@invalid.invalid> - 2013-12-11 15:05 +0000
          Re: Experiences/guidance on teaching Python as a first programming language Rick Johnson <rantingrickjohnson@gmail.com> - 2013-12-16 16:47 -0800
            Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-16 20:06 -0500
              Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 01:25 +0000
              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-17 12:27 +1100
              Re: Experiences/guidance on teaching Python as a first programming language Gene Heskett <gheskett@wdtv.com> - 2013-12-16 20:32 -0500
              Re: Experiences/guidance on teaching Python as a first programming language "Cousin Stanley" <cousinstanley@gmail.com> - 2013-12-17 07:32 -0700
                Re: Experiences/guidance on teaching Python as a first programming language Gene Heskett <gheskett@wdtv.com> - 2013-12-17 12:27 -0500
        Re: Experiences/guidance on teaching Python as a first programming language Neil Cerutti <neilc@norwich.edu> - 2013-12-11 15:46 +0000
    Re: Experiences/guidance on teaching Python as a first programming language "Rhodri James" <rhodri@wildebst.demon.co.uk> - 2013-12-09 23:32 +0000
      Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-09 18:42 -0500
        Re: Experiences/guidance on teaching Python as a first programming language "Rhodri James" <rhodri@wildebst.demon.co.uk> - 2013-12-10 00:00 +0000
        Re: Experiences/guidance on teaching Python as a first programming language Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-09 20:56 -0500
    Re: Experiences/guidance on teaching Python as a first programming language Wolfgang Keller <feliphil@gmx.net> - 2013-12-12 21:36 +0100
      Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-13 08:12 +1100
        Re: Experiences/guidance on teaching Python as a first programming language Wolfgang Keller <feliphil@gmx.net> - 2013-12-16 21:32 +0100
          Re: Experiences/guidance on teaching Python as a first programming language "Rhodri James" <rhodri@wildebst.org.uk> - 2013-12-16 23:01 +0000
          Re: Experiences/guidance on teaching Python as a first programming language Ned Batchelder <ned@nedbatchelder.com> - 2013-12-16 19:28 -0500
            Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-16 16:39 -0800
              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-17 11:44 +1100
                Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-16 17:58 -0800
              Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-17 02:33 +0000
                Re: Experiences/guidance on teaching Python as a first programming language Rick Johnson <rantingrickjohnson@gmail.com> - 2013-12-16 20:41 -0800
                Re: Experiences/guidance on teaching Python as a first programming language Neil Cerutti <neilc@norwich.edu> - 2013-12-17 14:51 +0000
                  Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-17 09:54 -0500
                    Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 15:07 +0000
                    Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-17 15:24 +0000
                      Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 15:35 +0000
                      Re: Experiences/guidance on teaching Python as a first programming language Larry Martell <larry.martell@gmail.com> - 2013-12-17 11:21 -0500
                        Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-17 08:56 -0800
                  Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-17 10:03 -0800
                    Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-18 05:20 +1100
                    Re: Experiences/guidance on teaching Python as a first programming language Joel Goldstick <joel.goldstick@gmail.com> - 2013-12-17 13:39 -0500
                  Re: Experiences/guidance on teaching Python as a first programming language dkcombs@panix.com (David Combs) - 2014-01-29 03:17 +0000
              Re: Experiences/guidance on teaching Python as a first programming language Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-12-17 11:12 +0000
                Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-17 12:18 +0000
                Re: Experiences/guidance on teaching Python as a first programming language Wolfgang Keller <feliphil@gmx.net> - 2013-12-17 16:51 +0100
                  Re: Experiences/guidance on teaching Python as a first programming language Grant Edwards <invalid@invalid.invalid> - 2013-12-17 16:59 +0000
                    Re: Experiences/guidance on teaching Python as a first programming language Larry Martell <larry.martell@gmail.com> - 2013-12-17 12:18 -0500
                    Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 17:24 +0000
                    Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 17:44 +0000
                      Re: Experiences/guidance on teaching Python as a first programming language Grant Edwards <invalid@invalid.invalid> - 2013-12-17 19:38 +0000
                    Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-17 19:39 -0500
                      Re: Experiences/guidance on teaching Python as a first programming language Grant Edwards <invalid@invalid.invalid> - 2013-12-18 18:05 +0000
                        Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-18 18:17 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-18 20:49 -0500
                            Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-19 02:05 +0000
                            Re: Experiences/guidance on teaching Python as a first programming language Wolfgang Keller <feliphil@gmx.net> - 2013-12-19 15:54 +0100
                        Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-18 20:40 -0500
                          Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-18 20:05 -0800
                            Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-18 23:16 -0500
                              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-19 15:26 +1100
                              Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-18 20:48 -0800
                                Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-19 09:14 -0800
                              Re: Experiences/guidance on teaching Python as a first programming language 88888 Dihedral <dihedral88888@gmail.com> - 2013-12-18 22:03 -0800
                          Re: Experiences/guidance on teaching Python as a first programming language Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-19 19:40 +1300
                    Re: Experiences/guidance on teaching Python as a first programming language Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-17 20:20 -0500
                  Re: Experiences/guidance on teaching Python as a first programming language Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-12-17 17:09 +0000
                  Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-17 19:32 -0500
                    Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve@pearwood.info> - 2013-12-18 01:33 +0000
                      Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-18 13:11 +1100
                        Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve@pearwood.info> - 2013-12-18 08:22 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-18 19:32 +1100
                          Re: Experiences/guidance on teaching Python as a first programming
 language Dave Angel <davea@davea.name> - 2013-12-18 07:53 -0500
                          Re: Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-19 01:55 +1100
                            Re: Re: Experiences/guidance on teaching Python as a first programming language "Rhodri James" <rhodri@wildebst.org.uk> - 2013-12-19 00:10 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Neil Cerutti <neilc@norwich.edu> - 2013-12-18 15:17 +0000
                          Re: Re: Experiences/guidance on teaching Python as a first
 programming language Dave Angel <davea@davea.name> - 2013-12-18 15:52 -0500
                            Re: Experiences/guidance on teaching Python as a first programming language Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-19 19:41 +1300
                              Re: Experiences/guidance on teaching Python as a first programming
 language Dave Angel <davea@davea.name> - 2013-12-19 07:06 -0500
                        Re: Experiences/guidance on teaching Python as a first programming language Grant Edwards <invalid@invalid.invalid> - 2013-12-18 18:00 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-18 18:07 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-18 20:56 -0500
                            Re: Experiences/guidance on teaching Python as a first programming language Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-19 18:39 +1300
                              Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-19 00:56 -0500
                      Re: Experiences/guidance on teaching Python as a first programming language Paul Smith <paul@mad-scientist.net> - 2013-12-17 22:49 -0500
                        Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve@pearwood.info> - 2013-12-18 08:18 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-18 19:51 +1100
                            Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-19 16:20 +0000
                              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-20 04:02 +1100
                          Re: Experiences/guidance on teaching Python as a first programming language Ethan Furman <ethan@stoneleaf.us> - 2013-12-18 07:23 -0800
                            Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-18 08:53 -0800
                              Re: Experiences/guidance on teaching Python as a first programming language Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-18 19:29 -0500
                            Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-19 16:20 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-18 17:15 +0000
                            Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-19 17:12 +0000
                              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-20 04:28 +1100
                              Re: Experiences/guidance on teaching Python as a first programming language Neil Cerutti <neilc@norwich.edu> - 2013-12-19 18:40 +0000
                              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-20 07:18 +1100
                              Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-19 19:38 -0500
                                Re: Experiences/guidance on teaching Python as a first programming language "Rhodri James" <rhodri@wildebst.org.uk> - 2013-12-20 00:45 +0000
                                Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-20 02:16 +0000
                                  Re: Experiences/guidance on teaching Python as a first programming language Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-20 18:58 -0500
                                  Re: Experiences/guidance on teaching Python as a first programming language Ned Batchelder <ned@nedbatchelder.com> - 2013-12-20 21:04 -0500
                                Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-27 14:35 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Terry Reedy <tjreedy@udel.edu> - 2013-12-18 17:33 -0500
                            Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-19 17:06 +0000
                              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-20 04:18 +1100
                          Re: Experiences/guidance on teaching Python as a first programming language Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-12-19 00:21 +0000
                      Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve@pearwood.info> - 2013-12-18 07:53 +0000
                    Re: Experiences/guidance on teaching Python as a first programming language Devin Jeanpierre <jeanpierreda@gmail.com> - 2013-12-17 18:33 -0800
                    Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-18 14:01 +1100
                    Re: Experiences/guidance on teaching Python as a first programming language Devin Jeanpierre <jeanpierreda@gmail.com> - 2013-12-17 19:12 -0800
                    Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-18 14:24 +1100
                  Re: Experiences/guidance on teaching Python as a first programming language "Rhodri James" <rhodri@wildebst.org.uk> - 2013-12-19 00:49 +0000
                    Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-19 11:54 +1100
                    Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-18 20:29 -0800
                      Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-19 04:50 +0000
                        Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-18 21:09 -0800
                          Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-19 05:36 +0000
                        Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-19 21:31 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-19 19:30 -0500
                Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-18 01:18 -0800
                  Re: Experiences/guidance on teaching Python as a first programming language Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-12-18 10:06 +0000
              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-18 01:10 +1100
            Re: Experiences/guidance on teaching Python as a first programming language Wolfgang Keller <feliphil@gmx.net> - 2013-12-17 16:22 +0100
              Re: Experiences/guidance on teaching Python as a first programming language Wolfgang Keller <feliphil@gmx.net> - 2013-12-19 16:14 +0100
                Re: Experiences/guidance on teaching Python as a first programming   language Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-20 09:42 +1300
                  Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-20 07:51 +1100
          Re: Experiences/guidance on teaching Python as a first programming language dkcombs@panix.com (David Combs) - 2014-01-29 03:09 +0000

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

#62365

In article <07c6e6a3-c5f4-4846-9551-434bdaba8b50@googlegroups.com>,
 rusi <rustompmody@gmail.com> wrote:

> Soon the foo has to split into foo1.c and foo2.c.  And suddenly you need to
> understand:
> 
> 1. Separate compilation
> 2. Make (which is separate from 'separate compilation')
> 3. Header files and libraries and the connection and difference

None of that is specific to C.  Virtually any language (including 
Python) allows a program to be split up into multiple source files.  If 
you're running all but the most trivial example, you need to know how to 
manage these multiple files and how the pieces interact.

It's pretty common here to have people ask questions about how import 
works.  How altering sys.path effects import.  Why is import not finding 
my module?  You quickly get into things like virtualenv, and now you've 
got modules coming from your source tree, from your vitualenv, from your 
system library.  You need to understand all of that to make it all work.

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

#62366

On Thu, Dec 19, 2013 at 3:16 PM, Roy Smith <roy@panix.com> wrote:
> It's pretty common here to have people ask questions about how import
> works.  How altering sys.path effects import.  Why is import not finding
> my module?  You quickly get into things like virtualenv, and now you've
> got modules coming from your source tree, from your vitualenv, from your
> system library.  You need to understand all of that to make it all work.

Python might one day want to separate "system paths" from "local
paths", to give the same effect as:

#include <stdio.h>
#include "local_config.h"

where the current directory won't be searched for stdio.h. But other
than that, it's exactly the same consideration in either Python or C.

ChrisA

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

#62369

On Thursday, December 19, 2013 9:46:26 AM UTC+5:30, Roy Smith wrote:
>  rusi  wrote:

> > Soon the foo has to split into foo1.c and foo2.c.  And suddenly you need to
> > understand:
> > 1. Separate compilation
> > 2. Make (which is separate from 'separate compilation')
> > 3. Header files and libraries and the connection and difference


> It's pretty common here to have people ask questions about how import 
> works.  How altering sys.path effects import.  Why is import not finding 
> my module?  You quickly get into things like virtualenv, and now you've 
> got modules coming from your source tree, from your vitualenv, from your 
> system library.  You need to understand all of that to make it all work.

Yes agreed. Python is far from stellar in this regard.
Just as distutils got into the core at 2.3(??) now at 3.3 virtualenv(+pip+wheel)
is getting in. Belated but better late than never.

> None of that is specific to C.  Virtually any language (including 
> Python) allows a program to be split up into multiple source files.  If 
> you're running all but the most trivial example, you need to know how to 
> manage these multiple files and how the pieces interact.

Thats a strange thing to say.  In the abstract every language that
allows for significant programs supports separate units/modules.

Somewhere those units will map onto system entities -- usually though
not always files (think of PL-SQL inside Oracle).

Even assuming files, the lines drawn between interior (to the language)
and exterior (OS-facing) are vastly different.

C, Pascal, Python, Java, SML, APL -- all very different in this regard.

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

#62409

> On Thursday, December 19, 2013 9:46:26 AM UTC+5:30, Roy Smith wrote:
> >  rusi  wrote:

> > > Soon the foo has to split into foo1.c and foo2.c.  And suddenly you need to
> > > understand:
> > > 1. Separate compilation
> > > 2. Make (which is separate from 'separate compilation')
> > > 3. Header files and libraries and the connection and difference

> > It's pretty common here to have people ask questions about how import 
> > works.  How altering sys.path effects import.  Why is import not finding 
> > my module?  You quickly get into things like virtualenv, and now you've 
> > got modules coming from your source tree, from your vitualenv, from your 
> > system library.  You need to understand all of that to make it all work.

> Yes agreed. Python is far from stellar in this regard.
> Just as distutils got into the core at 2.3(??) now at 3.3 virtualenv(+pip+wheel)
> is getting in. Belated but better late than never.

> > None of that is specific to C.  Virtually any language (including 
> > Python) allows a program to be split up into multiple source files.  If 
> > you're running all but the most trivial example, you need to know how to 
> > manage these multiple files and how the pieces interact.

> Thats a strange thing to say.  In the abstract every language that
> allows for significant programs supports separate units/modules.

> Somewhere those units will map onto system entities -- usually though
> not always files (think of PL-SQL inside Oracle).

> Even assuming files, the lines drawn between interior (to the language)
> and exterior (OS-facing) are vastly different.

> C, Pascal, Python, Java, SML, APL -- all very different in this regard.

Just adding this:
Different languages do their modularizing and packaging differently (what I 
earlier said) in order to achieve different tradeoffs.

Here's a thread by a competent programmer who switched from Lisp to C++.
https://groups.google.com/forum/#!topic/ledger-cli/Mjky9AvrRKU
He clearly says that while he loves Lisp the language, its packaging facilities
lost out to C++ and so he rewrote his whole app in C++.

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

#62376

Roy Smith於 2013年12月19日星期四UTC+8下午12時16分26秒寫道：
> In article <07c6e6a3-c5f4-4846-9551-434bdaba8b50@googlegroups.com>,
> 
>  rusi <rustompmody@gmail.com> wrote:
> 
> 
> 
> > Soon the foo has to split into foo1.c and foo2.c.  And suddenly you need to
> 
> > understand:
> 
> > 
> 
> > 1. Separate compilation
> 
> > 2. Make (which is separate from 'separate compilation')
> 
> > 3. Header files and libraries and the connection and difference
> 
> 
> 
> None of that is specific to C.  Virtually any language (including 
> 
> Python) allows a program to be split up into multiple source files.  If 
> 
> you're running all but the most trivial example, you need to know how to 
> 
> manage these multiple files and how the pieces interact.
> 
> 
> 
> It's pretty common here to have people ask questions about how import 
> 
> works.  How altering sys.path effects import.  Why is import not finding 
> 
> my module?  You quickly get into things like virtualenv, and now you've 
> 
> got modules coming from your source tree, from your vitualenv, from your 
> 
> system library.  You need to understand all of that to make it all work.

OK, just any novice can take the 
BOA and WXPYTHON packages to 
implement an editor in 1 to 3 hours,
but that is trivial in Delphi and 
object pascal long time ago.

The GUI to python scrit generation 
engine is the smarter way to 
let the mass interested in programming.

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

#62378

Roy Smith wrote:
> I suspect what you mean is, "There are some things that don't make sense 
> until you understand computer architecture".

An example of that kind of thing from a different
perspective: I learned Z80 assembly language by first
learning Z80 *machine* language (my homebrew computer
didn't have an assembler, so I had to write my own
and hand assemble it (after writing my own DOS
(after building my own disk controller... etc!))).

If you just look at the Z80 architecture at the
assembly language level, the rules for which
instructions go with which registers and which
addressing modes seem very haphazard. But because
I knew how the instructions were encoded, I never
had any trouble remembering the allowable combinations.
If it didn't have an encoding, you couldn't do it!

-- 
Greg

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

#62249

On Tue, 17 Dec 2013 12:18:13 -0500, Larry Martell <larry.martell@gmail.com>
declaimed the following:

>It wasn't for me either when I went to college in the late 1970's.
>Pascal first, then FORTRAN, then IBM 360 assembler. That was all the
>formal language training I had. (I had taught myself BASIC in high
>school.)

	Pascal was an elective at my school -- small class size having to share
a pair of CRDS LSI-11s running UCSD Pascal.

	The CompSci core curriculum had parallel threads of

(intro) FORTRAN, (adv) FORTRAN, Sigma-6 Assembler (Meta-Symbol)
(intro) COBOL, (adv) COBOL, Database (DBTG Network model)

	The OS course also used the CRDS LSI-11 and Macro-11 (which was taught
in the first few sessions, one was expected to be familiar with assembly
language programming on the Sigma)

	I took APL as independent study just to get the last three (only needed
two) credits for graduation.

	The algorithms class was a bit of a free-for-all; we where permitted to
use any language the instructor could make sense of -- which meant FORTRAN,
COBOL, Pascal, BASIC, and Assembly; SNOBOL and APL were not viable. I ended
up using BASIC -- on a system that only allowed four open files at a time
-- and I used program chaining to switch among the primary functions of the
assignment (a hashed head multiple linked list "phone directory"). I don't
even want to imagine the effort it took in Assembler (memory claims someone
DID choose that implementation)

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#62215

On 17 December 2013 15:51, Wolfgang Keller <feliphil@gmx.net> wrote:
>>
>> I was also taught C as an undergrad but having already learned Java, C
>> and C++ before arriving at University I found the C course very easy
>> so my own experience is not representative. Many of the other students
>> at that time found the course too hard and just cheated on all the
>> assignments (I remember one students offering to fix/finish anyone's
>> assignment in exchange for a bottle of cider!).
>
> The problem with the C class wasn't that it was "hard". I had passed my
> Pascal class, which taught nearly exactly the same issues with
> "straight A"s before (without ever having writeen any source code ever
> before). And by standard cognitive testing standards, I'm not exactly
> considered to be an idiot.

Please don't misunderstand me: I'm certainly not saying that you're an
idiot. Also I'm sure many of the students on my course would have
fared better on a course that was using e.g. Python instead of C.

Well actually come to think of it some of the other students were
pretty stupid. The lecturer had explained that they were using a
plagiarism detector so if you copy-paste code from someone else they
could catch you out for cheating. A few people took that literally and
thought that it could detect copy-pasting (in plain text files!). The
rumour went round that it would be okay if you printed out the code
and then typed it back in. For some reason they didn't bother running
the plagiarism detector until about 6 weeks into the course by which
time ~20% of submissions were exact duplicates of at least one other
(according to the lecturer who announced that all such students would
get zero marks for those assignments).


Oscar

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

#62247

In article <20131217165144.39bf9ba1cd4e4f27a96893ca@gmx.net>,
 Wolfgang Keller <feliphil@gmx.net> wrote:

> C is just a kafkaesque mess invented by a sadistic pervert who must
> have regularly consumed illegal substances for breakfast. 

Don't be absurd.  C is a perfectly good language for the kinds of things 
it's meant for.  It lets you get down close to the hardware while still 
using rational flow control and program structure, and being reasonably 
portable.

There's very few mysteries in C.  You never have to wonder what the 
lifetime of an object is, or be mystified by which of the 7 signatures 
of Foo.foo() are going to get called, or just what operation "x + y" is 
actually going to perform.

If you maim yourself with a razor-sharp chisel, do you blame the chisel 
for being a bad tool?

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

#62250

On Tue, 17 Dec 2013 19:32:20 -0500, Roy Smith wrote:

> There's very few mysteries in C.

Apart from "What the hell does this piece of code actually do?". It's no 
coincidence that C, and Perl which borrows a lot of syntax from C, are 
the two champion languages for writing obfuscated code.

And "What does 'implementation-specific undefined behaviour' actually 
mean in practice?", another common question when dealing with C.

And most importantly, "how many asterisks do I need, and where do I put 
them?" (only half joking).


> You never have to wonder what the
> lifetime of an object is, 

Since C isn't object oriented, the lifetime of objects in C is, um, any 
number you like. "The lifetime of objects in <some language with no 
objects> is ONE MILLION YEARS!!!" is as good as any other vacuously true 
statement.


> or be mystified by which of the 7 signatures
> of Foo.foo() are going to get called, 

Is that even possible in C? If Foo is a struct, and Foo.foo a member, I 
don't think C has first-class functions and so Foo.foo can't be callable. 
But if I'm wrong, and it is callable, then surely with no arguments there 
can only be one signature that Foo.foo() might call, even if C supported 
generic functions, which I don't believe it does.

(You can simulate something rather like generic functions using pointers, 
but that's it.)


> or just what operation "x + y" is
> actually going to perform.


With no operator overloading, that one at least is correct.



-- 
Steven

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

#62252

On Wed, Dec 18, 2013 at 12:33 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Tue, 17 Dec 2013 19:32:20 -0500, Roy Smith wrote:
>
>> There's very few mysteries in C.
>
> Apart from "What the hell does this piece of code actually do?". It's no
> coincidence that C, and Perl which borrows a lot of syntax from C, are
> the two champion languages for writing obfuscated code.

I thought APL would beat both of them, though you're right that the
International Obfuscoted Python Code Contest would be a quite
different beast. But maybe it'd be just as viable... a competent
programmer can write unreadable code in any language.

> And "What does 'implementation-specific undefined behaviour' actually
> mean in practice?", another common question when dealing with C.

You mean like mutating locals()? The only difference is that there are
a lot more implementations of C than there are of Python (especially
popular and well-used implementations). There are plenty of things you
shouldn't do in Python, but instead of calling them
"implementation-specific undefined behaviour", we call them
"consenting adults" and "shooting yourself in the foot".

> And most importantly, "how many asterisks do I need, and where do I put
> them?" (only half joking).

The one differentiation that I don't like is between the . and ->
operators. The distinction feels like syntactic salt. There's no
context when both are valid, save in C++ where you can create a
"pointer-like object" that implements the -> operator (and has the .
operator for its own members).

>> You never have to wonder what the
>> lifetime of an object is,
>
> Since C isn't object oriented, the lifetime of objects in C is, um, any
> number you like. "The lifetime of objects in <some language with no
> objects> is ONE MILLION YEARS!!!" is as good as any other vacuously true
> statement.

Lifetime still matters. The difference between automatic and static
variables is lifetime - you come back into this function and the same
value is there waiting for you. Call it "values" or "things" instead
of "objects" if it makes you feel better, but the consideration is
identical. (And in C++, it becomes critical, with object destructors
being used to release resources. So you need to know.)

>> or be mystified by which of the 7 signatures
>> of Foo.foo() are going to get called,
>
> Is that even possible in C? If Foo is a struct, and Foo.foo a member, I
> don't think C has first-class functions and so Foo.foo can't be callable.
> But if I'm wrong, and it is callable, then surely with no arguments there
> can only be one signature that Foo.foo() might call, even if C supported
> generic functions, which I don't believe it does.

Well, okay. In C you can't have Foo.foo(). But if that were Foo_foo(),
then the point would be better made, because C will have just one
function of that name (barring preprocessor shenanigans, of course).
In C++, the types of its arguments may affect which function is called
(polymorphism), and the dot notation works, too; but C++ does this
without having first-class functions, so that part of your response is
immaterial. In C++, Foo.foo() will always call a function foo defined
in the class of which Foo is an instance. Very simple, and static type
analysis will tell you exactly which function that is. Things do get a
bit messier with pointers, because a function might be virtual or not
virtual; C++ gives us the simple option (non-virtual functions) that
most high level languages don't (C++'s virtual functions behave the
same way as Python member functions do).

ChrisA

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

#62278

On Wed, 18 Dec 2013 13:11:58 +1100, Chris Angelico wrote:

> On Wed, Dec 18, 2013 at 12:33 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> On Tue, 17 Dec 2013 19:32:20 -0500, Roy Smith wrote:
>>
>>> There's very few mysteries in C.
>>
>> Apart from "What the hell does this piece of code actually do?". It's
>> no coincidence that C, and Perl which borrows a lot of syntax from C,
>> are the two champion languages for writing obfuscated code.
> 
> I thought APL would beat both of them, though you're right that the
> International Obfuscoted Python Code Contest would be a quite different
> beast. But maybe it'd be just as viable... a competent programmer can
> write unreadable code in any language.
> 
>> And "What does 'implementation-specific undefined behaviour' actually
>> mean in practice?", another common question when dealing with C.
> 
> You mean like mutating locals()? The only difference is that there are a
> lot more implementations of C than there are of Python (especially
> popular and well-used implementations). There are plenty of things you
> shouldn't do in Python, but instead of calling them
> "implementation-specific undefined behaviour", we call them "consenting
> adults" and "shooting yourself in the foot".
> 
>> And most importantly, "how many asterisks do I need, and where do I put
>> them?" (only half joking).
> 
> The one differentiation that I don't like is between the . and ->
> operators. The distinction feels like syntactic salt. There's no context
> when both are valid, save in C++ where you can create a "pointer-like
> object" that implements the -> operator (and has the . operator for its
> own members).
> 
>>> You never have to wonder what the
>>> lifetime of an object is,
>>
>> Since C isn't object oriented, the lifetime of objects in C is, um, any
>> number you like. "The lifetime of objects in <some language with no
>> objects> is ONE MILLION YEARS!!!" is as good as any other vacuously
>> true statement.
> 
> Lifetime still matters. The difference between automatic and static
> variables is lifetime - you come back into this function and the same
> value is there waiting for you. Call it "values" or "things" instead of
> "objects" if it makes you feel better, but the consideration is
> identical. (And in C++, it becomes critical, with object destructors
> being used to release resources. So you need to know.)
> 
>>> or be mystified by which of the 7 signatures of Foo.foo() are going to
>>> get called,
>>
>> Is that even possible in C? If Foo is a struct, and Foo.foo a member, I
>> don't think C has first-class functions and so Foo.foo can't be
>> callable. But if I'm wrong, and it is callable, then surely with no
>> arguments there can only be one signature that Foo.foo() might call,
>> even if C supported generic functions, which I don't believe it does.
> 
> Well, okay. In C you can't have Foo.foo(). 

Hah, well according to Paul Smith's example code you can. So either:


- it's possible to be an experienced C programmer and still have 
fundamental gaps in your knowledge about basic concepts like dotted 
function calls;

- or Paul's sample code was not what he claimed it to be;

- or maybe the whole thing is undefined and we're all right! C both does 
and doesn't allow Foo.foo() function calls, *sometimes at the same time*.



-- 
Steven

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

#62279

On Wed, Dec 18, 2013 at 7:22 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>> Well, okay. In C you can't have Foo.foo().
>
> Hah, well according to Paul Smith's example code you can. So either:
>
>
> - it's possible to be an experienced C programmer and still have
> fundamental gaps in your knowledge about basic concepts like dotted
> function calls;
>
> - or Paul's sample code was not what he claimed it to be;
>
> - or maybe the whole thing is undefined and we're all right! C both does
> and doesn't allow Foo.foo() function calls, *sometimes at the same time*.

- or it's possible to be an experienced C and C++ programmer and have
your mind just blank out about which things you can do in C and which
were added in C++, especially when you've been up all night and are
wired on energy drinks.

Mea culpa. My brain looked at that and thought it was a member
function, which is a C++ feature, and forgot that it could be a
straight-up function pointer, which is a C feature. Paul's correct,
I'm wrong.

ChrisA

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

#62298 — Re: Experiences/guidance on teaching Python as a first programming language

On 18 Dec 2013 08:22:58 GMT, Steven D'Aprano <steve@pearwood.info> 
wrote:
> On Wed, 18 Dec 2013 13:11:58 +1100, Chris Angelico wrote:
> > The one differentiation that I don't like is between the . and ->
> > operators. The distinction feels like syntactic salt. There's no 
context
> > when both are valid, save in C++ where you can create a 
"pointer-like
> > object" that implements the -> operator (and has the . operator 
for its
> > own members).

Funny you should say that in the middle of a discussion about 
lifetime.  In C, when you do the -> thing, you're now in a different 
struct with a potentially different lifetime.  If p is a local,  with 
auto lifetime,  then so is p.x

So, although the two are mutually exclusive,  there's valuable 
information hidden in the required choice.

-- 
DaveA

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

#62308

On Wed, Dec 18, 2013 at 11:53 PM, Dave Angel <davea@davea.name> wrote:
> Funny you should say that in the middle of a discussion about lifetime.  In
> C, when you do the -> thing, you're now in a different struct with a
> potentially different lifetime.  If p is a local,  with auto lifetime,  then
> so is p.x
>
> So, although the two are mutually exclusive,  there's valuable information
> hidden in the required choice.

Sure, but you can figure out whether p is a local struct or a local
pointer to some other struct by looking at its declaration. Do you
also need to look at every usage of it? We don't adorn every / with a
marker saying whether we're dividing ints or floats, and that's
something that could be potentially useful (float division of two ints
being what Py3 does). Why adorn pointer usage?

ChrisA

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

#62347

On Wed, 18 Dec 2013 14:55:10 -0000, Chris Angelico <rosuav@gmail.com>  
wrote:

> On Wed, Dec 18, 2013 at 11:53 PM, Dave Angel <davea@davea.name> wrote:
>> Funny you should say that in the middle of a discussion about  
>> lifetime.  In
>> C, when you do the -> thing, you're now in a different struct with a
>> potentially different lifetime.  If p is a local,  with auto lifetime,   
>> then
>> so is p.x
>>
>> So, although the two are mutually exclusive,  there's valuable  
>> information
>> hidden in the required choice.
>
> Sure, but you can figure out whether p is a local struct or a local
> pointer to some other struct by looking at its declaration. Do you
> also need to look at every usage of it? We don't adorn every / with a
> marker saying whether we're dividing ints or floats, and that's
> something that could be potentially useful (float division of two ints
> being what Py3 does). Why adorn pointer usage?

Because explicit is better than implicit?

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

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

#62309

On 2013-12-18, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, Dec 18, 2013 at 11:53 PM, Dave Angel <davea@davea.name> wrote:
>> Funny you should say that in the middle of a discussion about
>> lifetime.  In C, when you do the -> thing, you're now in a
>> different struct with a potentially different lifetime.  If p
>> is a local,  with auto lifetime,  then so is p.x
>>
>> So, although the two are mutually exclusive,  there's valuable
>> information hidden in the required choice.
>
> Sure, but you can figure out whether p is a local struct or a
> local pointer to some other struct by looking at its
> declaration. Do you also need to look at every usage of it? We
> don't adorn every / with a marker saying whether we're dividing
> ints or floats, and that's something that could be potentially
> useful (float division of two ints being what Py3 does). Why
> adorn pointer usage?

Indeed. Golang allows . to do member lookup for both structs and
pointers to structs.

The -> syntax perhaps was needful in the days before function
prototypes.

-- 
Neil Cerutti

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

#62341 — Re: Re: Experiences/guidance on teaching Python as a first programming language

On Thu, 19 Dec 2013 01:55:10 +1100, Chris Angelico <rosuav@gmail.com> 
wrote:
> Sure, but you can figure out whether p is a local struct or a local
> pointer to some other struct by looking at its declaration. Do you
> also need to look at every usage of it? 

C is a glorified macro assembler.  So the -> operator is not 
analogous to the dot operator, it's Syntactic sugar:

p-> a. Is really
(*p).a

-- 
DaveA

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

#62379

Dave Angel wrote:
> C is a glorified macro assembler.  So the -> operator is not analogous 
> to the dot operator, it's Syntactic sugar:
> 
> p-> a. Is really
> (*p).a

But it's not above inferring a dereferencing
operation when you call a function via a
pointer. If f is a pointer to a function,
then

    f(a)

is equivalent to

    (*f)(a)

If the compiler can do that for function calls,
there's no reason it couldn't do it for member
access as well.

If I remember rightly, Ada not only does implicit
dereferencing like this, it doesn't even have an
explicit dereferencing operator! If you want to
refer to the whole record pointed to by p, you
have to say 'p.all'.

BTW, the whole notion of a "pointer to a function"
is redundant in C, since you can't do anything
with what it points to other than call it. The
equivalent concept in Modula, for example, is
just called a function type, not a pointer-to-
function type. Similarly in most languages that
have functions as values.

-- 
Greg

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

#62395 — Re: Experiences/guidance on teaching Python as a first programming language

On Thu, 19 Dec 2013 19:41:00 +1300, Gregory Ewing 
<greg.ewing@canterbury.ac.nz> wrote:
> But it's not above inferring a dereferencing
> operation when you call a function via a
> pointer. If f is a pointer to a function,
> then


>     f(a)


> is equivalent to


>     (*f)(a)


> If the compiler can do that for function calls,
> there's no reason it couldn't do it for member
> access as well.

Quite right.  And I recall being confounded by the function pointer 
syntax; it never fit in my mental model of how the rest of C worked.

Anyway I was not intending to defend C choices,  merely to point out 
an advantage this choice gave me.  On a language without garbage 
collection,  the indirection was very important to keep in mind.

-- 
DaveA

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

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

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

csiph-web