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 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

#62422

On Fri, 20 Dec 2013 00:38:51 -0000, Roy Smith <roy@panix.com> wrote:

> I disagree entirely (but respectfully).  If you want to get down to the
> hardware where you can fiddle bits, you want as little getting between
> you and the silicon as possible.  Every time you add a safety feature,
> you put another layer of *stuff* between you and the machine.
>
> That's not to say it's the right language to be writing applications.

+1

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

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

#62423

On Thu, 19 Dec 2013 19:38:51 -0500, Roy Smith wrote:

> In article <52b328f7$0$6512$c3e8da3$5496439d@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> 
>> Correct. The *great deal of trouble* part is important. Things which
>> are the responsibility of the language and compiler in (say) Java, D,
>> Rust, Go, etc. are the responsibility of the programmer with C.
> 
> Does anybody ever use D?  I looked at it a few years ago.  It seemed
> like a very good concept.  Sort of C++, with the worst of the crap torn
> out.  If nothing else, with the preprocessor torn out :-)
> 
> Did it ever go anywhere?

There are still people using D. Like most niche languages, it's in a 
niche :-)



>> Now, I wish to be absolutely clear. There are certain programming areas
>> where squeezing out every last iota of performance is important, and to
>> do so MAY REQUIRE MAKING SOME COMPROMISES ON CORRECTNESS OR SAFETY. I
>> find the C standard's position on undefined behaviour to be
>> irresponsible, but, hey, MAYBE IT IS JUSTIFIED on the basis that C is a
>> systems language intended for use in writing performance-critical
>> operating system kernels, device drivers and similar. It's fine for
>> Python to promise that nothing you do will ever cause a segfault, but
>> for a language used to write kernels and device drivers, you probably
>> want something more powerful and less constrained.

Emphasis added.

> I disagree entirely (but respectfully).  If you want to get down to the
> hardware where you can fiddle bits, you want as little getting between
> you and the silicon as possible.  Every time you add a safety feature,
> you put another layer of *stuff* between you and the machine.

I think that if you re-read what I wrote, you actually agree with me.

With the following two provisos:

1) There is a tendency among some programmers to premature optimization 
and coding machismo where correctness is a distant fourth place behind 
speed, memory use, and code size -- and security doesn't even place. For 
those programmers, "I want to get down to the hardware" often has nothing 
to do with *needing* to get down to the hardware. Screw 'em.

2) Even for kernel developers, I believe that systems languages should be 
safe by default. You ought to have to explicitly disable (say) bounds 
checking in critical sections of code, rather than explicitly enable it. 
Or worse, have to program your own bounds checking -- especially if the 
compiler is permitted to silently disregard it if you make one tiny 
mistake.


> That's not to say it's the right language to be writing applications.

I find it interesting to note that the utter failure of C programmers to 
deal with the consequences of buffer overflows has lead Intel to put 
pointer safety into hardware.

http://software.intel.com/en-us/articles/introduction-to-intel-memory-protection-extensions


There is little reason to believe that a safer language would necessarily be 
slower in practice. C has had 40 years of development to get to where it 
is now. With a fraction of the development of C, Scala code gets to 
within a factor of 2-3 of the equivalent C++ code, Go to within a factor 
of 5-7, and even Java to within a factor of 3-4. Okay, so Java has had 
oodles of optimization development too, so that's probably about as good 
as it will get. Imagine if newer languages like Go and Rust had even a 
quarter of the development effort as C and C++.

http://readwrite.com/2011/06/06/cpp-go-java-scala-performance-benchmark



-- 
Steven

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

#62459

On 20 Dec 2013 02:16:05 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following:

>
>2) Even for kernel developers, I believe that systems languages should be 
>safe by default. You ought to have to explicitly disable (say) bounds 
>checking in critical sections of code, rather than explicitly enable it. 
>Or worse, have to program your own bounds checking -- especially if the 
>compiler is permitted to silently disregard it if you make one tiny 
>mistake.
>
	I wonder how BLISS falls into that... Have to read the rest of
http://en.wikipedia.org/wiki/BLISS (while I had 22 years on VMS, it was
mostly F77, a touch of F90, C, Pascal, and some DCL; but never used BLISS)
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#62463

On 12/20/13 6:58 PM, Dennis Lee Bieber wrote:
> On 20 Dec 2013 02:16:05 GMT, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> declaimed the following:
>
>>
>> 2) Even for kernel developers, I believe that systems languages should be
>> safe by default. You ought to have to explicitly disable (say) bounds
>> checking in critical sections of code, rather than explicitly enable it.
>> Or worse, have to program your own bounds checking -- especially if the
>> compiler is permitted to silently disregard it if you make one tiny
>> mistake.
>>
> 	I wonder how BLISS falls into that... Have to read the rest of
> http://en.wikipedia.org/wiki/BLISS (while I had 22 years on VMS, it was
> mostly F77, a touch of F90, C, Pascal, and some DCL; but never used BLISS)
>

Bliss is even lower-level than C.  It made the too-consistent choice of 
having names mean the same thing on the left-hand side of an assignment 
as on the right-hand side.  A name meant the address of a variable, so 
to access the value of a variable, you had to dereference it with the 
dot operator, much like the unary asterisk in C.

C:	a = b
Bliss:	a = .b

C:	a = a + 1
Bliss:	a = .a + 1

C:	a = *b
Bliss:	a = ..b

C: 	a = &b
Bliss:	a = b

It was far too common to forget the dots...

-- 
Ned Batchelder, http://nedbatchelder.com

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

#62798

On Thu, 19 Dec 2013 19:38:51 -0500, Roy Smith wrote:

> Does anybody ever use D?  I looked at it a few years ago.  It seemed
> like a very good concept.  Sort of C++, with the worst of the crap torn
> out. If nothing else, with the preprocessor torn out :-)
> 
> Did it ever go anywhere?

Apparently Facebook are now working with it:

http://www.fastcolabs.com/3019948/more-about-d-language-and-why-facebook-is-experimenting-with-it



-- 
Steven

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

#62344

On 12/18/2013 3:18 AM, Steven D'Aprano wrote:

> We don't know what locals()['spam'] = 42 will do inside a function,

I am mystified that you would write this. Locals() will "Update and 
return a dictionary representing the current local symbol table." The 
only thing unspecified is the relation between the 'current local symbol 
table' and the *dict* that 'represents' it. Given that a dict is 
returned, the rest is unambiguous.

> unlike the C case, we can reason about it:
>
> - it may bind 42 to the name "spam";

"somedict['spam'] = 42" will do exactly that.

> - it may raise a runtime exception;

Absolutely not.

> - it may even be a no-op;

Absolutely not.

-- 
Terry Jan Reedy

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

#62407

On Wed, 18 Dec 2013 17:33:49 -0500, Terry Reedy wrote:

> On 12/18/2013 3:18 AM, Steven D'Aprano wrote:
> 
>> We don't know what locals()['spam'] = 42 will do inside a function,
> 
> I am mystified that you would write this.

Context is everything. locals() doesn't just return any old dictionary. 
It returns a dictionary of variables.


> Locals() will "Update and
> return a dictionary representing the current local symbol table." The
> only thing unspecified is the relation between the 'current local symbol
> table' and the *dict* that 'represents' it. 

Precisely.


> Given that a dict is returned, the rest is unambiguous.
> 
>> unlike the C case, we can reason about it:
>>
>> - it may bind 42 to the name "spam";
> 
> "somedict['spam'] = 42" will do exactly that.

We're not talking about setting items in an arbitrary dict. We're talking 
about setting variables using locals(), and in that case, writing to 
locals() does not guarantee to bind the value to the *name*.

def test():
    spam = 23
    locals()["spam"] = 42
    assert spam == 42


test() passes the assertion in IronPython 2.6, but fails in CPython 2.7 
and 3.4, and Jython 2.5.


>> - it may raise a runtime exception;
> 
> Absolutely not.

I don't know of any Python implementation which does so, but the 
documentation says:

     The contents of this dictionary should not be modified

so it is hardly beyond the realm of possibility that some implementation 
may choose to treat it as an error and raise an exception.


>> - it may even be a no-op;
> 
> Absolutely not.


In the example I show above, it is a no-op. The dict returned by locals 
is modified and then immediately garbage-collected. There are no side-
effects. Should some implementation decide to compile that away as dead 
code, it would be perfectly allowed to. (Well, assuming that it 
determined first that locals() actually was the built-in and not some 
substitute, either by static analysis or runtime testing.) It wouldn't 
surprise me if PyPy was capable of doing that today.



-- 
Steven

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

#62410

On Fri, Dec 20, 2013 at 4:06 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Should some implementation decide to compile that away as dead
> code, it would be perfectly allowed to. (Well, assuming that it
> determined first that locals() actually was the built-in and not some
> substitute, either by static analysis or runtime testing.)

Hmm. I'm not sure how safe it is to optimize that sort of thing away
in Python. Is there any way to be truly sure that locals is still the
built-in, and if there isn't, is there any advantage to optimizing it
out with some sort of check to see if it should be de-optimized now?
But yes, in theory you're right. Mutating locals() could be optimized
out.

ChrisA

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

#62348

On 18 December 2013 22:33, Terry Reedy <tjreedy@udel.edu> wrote:
> On 12/18/2013 3:18 AM, Steven D'Aprano wrote:
>
>> We don't know what locals()['spam'] = 42 will do inside a function,
>
> I am mystified that you would write this. Locals() will "Update and return a
> dictionary representing the current local symbol table." The only thing
> unspecified is the relation between the 'current local symbol table' and the
> *dict* that 'represents' it. Given that a dict is returned, the rest is
> unambiguous.

It's not unambiguous. The full wording is:
'''
locals()

Update and return a dictionary representing the current local symbol
table. Free variables are returned by locals() when it is called in
function blocks, but not in class blocks.

Note:
The contents of this dictionary should not be modified; changes may
not affect the values of local and free variables used by the
interpreter.
'''

The part that says "changes may ..." is deliberately ambiguous; the
author didn't want to impose too strong a constraint on any particular
implementation.

>> unlike the C case, we can reason about it:
>>
>> - it may bind 42 to the name "spam";
>
> "somedict['spam'] = 42" will do exactly that.

That's not what is usually meant by "name-binding".

>> - it may raise a runtime exception;
>
> Absolutely not.

Agreed.

>> - it may even be a no-op;
>
> Absolutely not.

Incorrect. The code in question is:

    locals()['spam'] = 42

and it is semantically a no-op. The index assignment on a temporary
dict may actually be performed by e.g. the CPython interpreter but it
is really just dead code.


Oscar

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

#62276

On Wed, 18 Dec 2013 01:33:03 +0000, Steven D'Aprano wrote:

>> or just what operation "x + y" is
>> actually going to perform.
> 
> 
> With no operator overloading, that one at least is correct.


Actually, I stand corrected. I was completely mistaken about that. The C 
operation x + y is undefined if the addition overflows. A valid C 
compiler can produce whatever code it damn well feels like in the case of 
overflow.

Oh, and in case you think that integer overflow in C will always follow 
two's complement semantics, such that INT_MAX+1 = INT_MIN, you are wrong. 
That's not guaranteed either. Clang and gcc have a flag, -fwrapv, to 
force defined behaviour on integer overflow, but that's not part of the C 
standard and not all C compilers will do the same.



-- 
Steven

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

#62253

On Tue, Dec 17, 2013 at 4:32 PM, Roy Smith <roy@panix.com> wrote:
> There's very few mysteries in C.  You never have to wonder what the
> lifetime of an object is

Yes you do. Lifetimes are hard, because you need to malloc a lot, and
there is no defined lifetime for pointers -- they could last for just
the lifetime of a stack frame, or until the end of the program, or
anywhere in-between, and it's impossible to know for sure, and if you
get it wrong your program crashes. So there's all these conventions
you have to come up with like "borrowing" and "owning", but they
aren't compiler-enforced, so you still have to figure it out, and you
will get it wrong. Successors like C++ mitigate these issues with
destructors (allowing heap-allocated stuff to be tied to the lifetime
of a stack), and smart pointers and so on.

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

C still has overloaded functions, just fewer of them. It'll still
mystify you when you encounter it, though.
http://www.robertgamble.net/2012/01/c11-generic-selections.html

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

I don't know. Will it do float addition? int addition? size_t
addition? How does coercion work?

+ can do many different things, it's not just a straight translation
to an obvious machine instruction.

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

If I didn't need it to be that sharp, then yes.

-- Devin

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

#62254

On Wed, Dec 18, 2013 at 1:33 PM, Devin Jeanpierre
<jeanpierreda@gmail.com> wrote:
> On Tue, Dec 17, 2013 at 4:32 PM, Roy Smith <roy@panix.com> wrote:
>> There's very few mysteries in C.  You never have to wonder what the
>> lifetime of an object is
>
> Yes you do. Lifetimes are hard, because you need to malloc a lot, and
> there is no defined lifetime for pointers -- they could last for just
> the lifetime of a stack frame, or until the end of the program, or
> anywhere in-between, and it's impossible to know for sure, and if you
> get it wrong your program crashes. So there's all these conventions
> you have to come up with like "borrowing" and "owning", but they
> aren't compiler-enforced, so you still have to figure it out, and you
> will get it wrong. Successors like C++ mitigate these issues with
> destructors (allowing heap-allocated stuff to be tied to the lifetime
> of a stack), and smart pointers and so on.

Wrong. A pointer is a scalar value, usually some kind of integer, and
its lifetime is the same as any other scalar. Heap memory's lifetime
is also very simple: it lasts until freed. (Though technically that's
not even a part of the language - malloc/free are just functions. Not
that it matters. Anyway, C++ has the new and delete operators, which
are part of the language.) There are conventions to prevent memory
leaks, but those are mere conventions. It's simple in the same way
that a toy electric motor is simple: you apply current to it, and it
spins. There's so little that it can do that it HAS to be simple.

ChrisA

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

#62257

On Tue, Dec 17, 2013 at 7:01 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, Dec 18, 2013 at 1:33 PM, Devin Jeanpierre
> <jeanpierreda@gmail.com> wrote:
>> Yes you do. Lifetimes are hard, because you need to malloc a lot, and
>> there is no defined lifetime for pointers -- they could last for just
>> the lifetime of a stack frame, or until the end of the program, or
>> anywhere in-between, and it's impossible to know for sure, and if you
>> get it wrong your program crashes. So there's all these conventions
>> you have to come up with like "borrowing" and "owning", but they
>> aren't compiler-enforced, so you still have to figure it out, and you
>> will get it wrong. Successors like C++ mitigate these issues with
>> destructors (allowing heap-allocated stuff to be tied to the lifetime
>> of a stack), and smart pointers and so on.
>
> Wrong. A pointer is a scalar value, usually some kind of integer, and
> its lifetime is the same as any other scalar.

The duration of a pointer's validity is far more interesting, and that
is why it is the primary meaning of the term "pointer lifetime". Also,
it's obviously what I meant.

>  Heap memory's lifetime
> is also very simple: it lasts until freed.

Sometimes simple things are hard to use correctly. I only said it was
hard, not complicated.

-- Devin

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

#62261

On Wed, Dec 18, 2013 at 2:12 PM, Devin Jeanpierre
<jeanpierreda@gmail.com> wrote:
>> Wrong. A pointer is a scalar value, usually some kind of integer, and
>> its lifetime is the same as any other scalar.
>
> The duration of a pointer's validity is far more interesting, and that
> is why it is the primary meaning of the term "pointer lifetime". Also,
> it's obviously what I meant.
>>  Heap memory's lifetime
>> is also very simple: it lasts until freed.
>
> Sometimes simple things are hard to use correctly. I only said it was
> hard, not complicated.

Sure, which is why I went on to discuss the block of memory pointed
to. But the rules are a lot simpler than in Python, where something
exists until... uhh... the system feels like disposing of it. At which
point __del__ will probably be called, but we can't be sure of that.
All we know about an object's lifetime in Python is that it will
continue to live so long as we're using it. And then multiprocessing
and fork make it messier, but that's true in any language.

The original point was that C has no mysteries. I posit that this is
true because C's rules are so simple. It might well be harder to work
in this system (taking it to an extreme, Brainf* is about the simplest
Turing-complete language possible, and it's virtually impossible to
write good code in it), but it has no mysteries.

ChrisA

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

#62351

On Tue, 17 Dec 2013 15:51:44 -0000, Wolfgang Keller <feliphil@gmx.net>  
wrote:

> The only issue for me was to figure out how to do in C what I already
> knew in Pascal. And I had to waste a *lot* more time and mental effort
> to mess with that language than it took for me to learn *both* the
> basics of programming per se *and* Pascal in the first class at my home
> university.

It's sounds like you made, and are carrying on making, one of the classic  
mistakes of software engineering: you're trying to write one language in  
the style of another.  It is possible to write C code as if it were  
Pascal, but it's a painful process and it won't be pretty.  It's far  
better to use a language as it is rather than as you want it to be.

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

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

#62352

On Thu, Dec 19, 2013 at 11:49 AM, Rhodri James <rhodri@wildebst.org.uk> wrote:
> It's sounds like you made, and are carrying on making, one of the classic
> mistakes of software engineering

Never get into a flame war in Asia, and never go up against a C
programmer when segfaults are on the line!

ChrisA

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

#62367

On Thursday, December 19, 2013 6:19:04 AM UTC+5:30, Rhodri James wrote:
> On Tue, 17 Dec 2013 15:51:44 -0000, Wolfgang Keller wrote: 
> > The only issue for me was to figure out how to do in C what I already
> > knew in Pascal. And I had to waste a *lot* more time and mental effort
> > to mess with that language than it took for me to learn *both* the
> > basics of programming per se *and* Pascal in the first class at my home
> > university.

> It's sounds like you made, and are carrying on making, one of the classic  
> mistakes of software engineering: you're trying to write one language in  
> the style of another.  It is possible to write C code as if it were  
> Pascal, but it's a painful process and it won't be pretty.  It's far  
> better to use a language as it is rather than as you want it to be.

Yes but the reverse is also true: Sometimes the best code in language
L is first conceptualized in design-language D and then 'coded' into
L.

When we were students D was called 'flow-charts'
Gone out of fashion today and replaced by UML.

Now I expect the majority on this list to not care for UML.
However the idea of a separate design language is not negated by the fact
that UML is overkill and silly.

eg Saw this (on the Erlang mailing list)
In some Australian university (in the 90s) 2 sems of Cobol was
replaced by 1 sem Scheme + 1 sem Cobol.  Students learnt more Cobol in
the second arrangement than in the first. [Note: 'More Cobol' not 'More
Programming']

Now if you were to ask those *students* I would expect similar
emotions towards Cobol as Wolfgang is expressing towards C.
That is however a separate issue :D

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

#62370

On 19/12/2013 04:29, rusi wrote:
> On Thursday, December 19, 2013 6:19:04 AM UTC+5:30, Rhodri James wrote:
>> On Tue, 17 Dec 2013 15:51:44 -0000, Wolfgang Keller wrote:
>>> The only issue for me was to figure out how to do in C what I already
>>> knew in Pascal. And I had to waste a *lot* more time and mental effort
>>> to mess with that language than it took for me to learn *both* the
>>> basics of programming per se *and* Pascal in the first class at my home
>>> university.
>
>> It's sounds like you made, and are carrying on making, one of the classic
>> mistakes of software engineering: you're trying to write one language in
>> the style of another.  It is possible to write C code as if it were
>> Pascal, but it's a painful process and it won't be pretty.  It's far
>> better to use a language as it is rather than as you want it to be.
>
> Yes but the reverse is also true: Sometimes the best code in language
> L is first conceptualized in design-language D and then 'coded' into
> L.
>
> When we were students D was called 'flow-charts'
> Gone out of fashion today and replaced by UML.
>
> Now I expect the majority on this list to not care for UML.
> However the idea of a separate design language is not negated by the fact
> that UML is overkill and silly.
>
> eg Saw this (on the Erlang mailing list)
> In some Australian university (in the 90s) 2 sems of Cobol was
> replaced by 1 sem Scheme + 1 sem Cobol.  Students learnt more Cobol in
> the second arrangement than in the first. [Note: 'More Cobol' not 'More
> Programming']
>
> Now if you were to ask those *students* I would expect similar
> emotions towards Cobol as Wolfgang is expressing towards C.
> That is however a separate issue :D
>

If C is such a crap language, what does it says for the thousands of 
languages that never got anywhere?  Or did C simply have a far larger 
sales and marketing budget? :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

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

#62371

On Thursday, December 19, 2013 10:20:54 AM UTC+5:30, Mark Lawrence wrote:
> On 19/12/2013 04:29, rusi wrote:
> > On Thursday, December 19, 2013 6:19:04 AM UTC+5:30, Rhodri James wrote:
> >> On Tue, 17 Dec 2013 15:51:44 -0000, Wolfgang Keller wrote:
> >>> The only issue for me was to figure out how to do in C what I already
> >>> knew in Pascal. And I had to waste a *lot* more time and mental effort
> >>> to mess with that language than it took for me to learn *both* the
> >>> basics of programming per se *and* Pascal in the first class at my home
> >>> university.
> >> It's sounds like you made, and are carrying on making, one of the classic
> >> mistakes of software engineering: you're trying to write one language in
> >> the style of another.  It is possible to write C code as if it were
> >> Pascal, but it's a painful process and it won't be pretty.  It's far
> >> better to use a language as it is rather than as you want it to be.
> > Yes but the reverse is also true: Sometimes the best code in language
> > L is first conceptualized in design-language D and then 'coded' into
> > L.
> > When we were students D was called 'flow-charts'
> > Gone out of fashion today and replaced by UML.
> > Now I expect the majority on this list to not care for UML.
> > However the idea of a separate design language is not negated by the fact
> > that UML is overkill and silly.
> > eg Saw this (on the Erlang mailing list)
> > In some Australian university (in the 90s) 2 sems of Cobol was
> > replaced by 1 sem Scheme + 1 sem Cobol.  Students learnt more Cobol in
> > the second arrangement than in the first. [Note: 'More Cobol' not 'More
> > Programming']
> > Now if you were to ask those *students* I would expect similar
> > emotions towards Cobol as Wolfgang is expressing towards C.
> > That is however a separate issue :D

> If C is such a crap language, what does it says for the thousands of 
> languages that never got anywhere?  Or did C simply have a far larger 
> sales and marketing budget? :)

Are you addressing that to me?
[Assuming you are a good boy who does not use GG-crap and knows the laws
of snipping and attributing I am taking it so :D ]

No I am not in the 'C-is-crap' camp.  Very far into the opposite actually.

What would you say to someone who says:
- food is crap to eat
- air is crap to breathe

"C is crap technology" is analogous.

If you are using python its likely CPython. Whats the C there?
If you are connected to the net the modem likely runs a linux. Coded in?

I am an Luddite -- dont touch computers.
Right. The car I drive probably has embedded chips... Embeded linux.

No Amish/Luddite is not enough to say "No!" to C
You'd have to be completely isolated from every connection with modern
civilization.

So python programmers employ the 'black-cat' squad of GvR and gang to shield
us from C.  Because they are good at it we can afford to ignore it.

No, "No C" is no option.
The only option is at how many removes we keep away from it.

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

#62373

On 19/12/2013 05:09, rusi wrote:
> On Thursday, December 19, 2013 10:20:54 AM UTC+5:30, Mark Lawrence wrote:
>> On 19/12/2013 04:29, rusi wrote:
>>> On Thursday, December 19, 2013 6:19:04 AM UTC+5:30, Rhodri James wrote:
>>>> On Tue, 17 Dec 2013 15:51:44 -0000, Wolfgang Keller wrote:
>>>>> The only issue for me was to figure out how to do in C what I already
>>>>> knew in Pascal. And I had to waste a *lot* more time and mental effort
>>>>> to mess with that language than it took for me to learn *both* the
>>>>> basics of programming per se *and* Pascal in the first class at my home
>>>>> university.
>>>> It's sounds like you made, and are carrying on making, one of the classic
>>>> mistakes of software engineering: you're trying to write one language in
>>>> the style of another.  It is possible to write C code as if it were
>>>> Pascal, but it's a painful process and it won't be pretty.  It's far
>>>> better to use a language as it is rather than as you want it to be.
>>> Yes but the reverse is also true: Sometimes the best code in language
>>> L is first conceptualized in design-language D and then 'coded' into
>>> L.
>>> When we were students D was called 'flow-charts'
>>> Gone out of fashion today and replaced by UML.
>>> Now I expect the majority on this list to not care for UML.
>>> However the idea of a separate design language is not negated by the fact
>>> that UML is overkill and silly.
>>> eg Saw this (on the Erlang mailing list)
>>> In some Australian university (in the 90s) 2 sems of Cobol was
>>> replaced by 1 sem Scheme + 1 sem Cobol.  Students learnt more Cobol in
>>> the second arrangement than in the first. [Note: 'More Cobol' not 'More
>>> Programming']
>>> Now if you were to ask those *students* I would expect similar
>>> emotions towards Cobol as Wolfgang is expressing towards C.
>>> That is however a separate issue :D
>
>> If C is such a crap language, what does it says for the thousands of
>> languages that never got anywhere?  Or did C simply have a far larger
>> sales and marketing budget? :)
>
> Are you addressing that to me?

No, I never address individuals.  As far as I'm concerned I'm sending to 
an entire newsgroup/mailing list.

> [Assuming you are a good boy who does not use GG-crap and knows the laws
> of snipping and attributing I am taking it so :D ]

Please cut the sarcastic crap.

>
> No I am not in the 'C-is-crap' camp.  Very far into the opposite actually.
>
> What would you say to someone who says:
> - food is crap to eat
> - air is crap to breathe
>
> "C is crap technology" is analogous.
>
> If you are using python its likely CPython. Whats the C there?
> If you are connected to the net the modem likely runs a linux. Coded in?
>
> I am an Luddite -- dont touch computers.
> Right. The car I drive probably has embedded chips... Embeded linux.
>
> No Amish/Luddite is not enough to say "No!" to C
> You'd have to be completely isolated from every connection with modern
> civilization.
>
> So python programmers employ the 'black-cat' squad of GvR and gang to shield
> us from C.  Because they are good at it we can afford to ignore it.
>
> No, "No C" is no option.
> The only option is at how many removes we keep away from it.
>

I've no idea what most of the above is meant to mean.  Have you been 
reading too much RR or "Joseph McCarthy"?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

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

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

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

csiph-web