Re: tough-to-explain Python

greg writes: > However, I suspect that you can't improve much on what we've already > got without restricting the domain of applicability of the > language. Otherwise, you just shift the intellectual bottleneck from > writing a correct program to writing correct specifications. Really, it's easie

Re: tough-to-explain Python

Simon Forman wrote: My understanding (so far) is that you (hope to) /derive/ correct code using formal logic, rather than writing code and then proving its soundness. But to the extent you can rigorously formalise it, all you've done is create Yet Another Programming Language. Which is fine,

Re: tough-to-explain Python

On Mon, Jul 20, 2009 at 9:54 PM, Paul Rubin wrote: > Simon Forman writes: >> But I'm glad it's there to study, these are wheels I don't have to >> invent for myself. > > http://dwheeler.com/essays/high-assurance-floss.html > > might be an interesting place to start.

Re: tough-to-explain Python

Simon Forman writes: > But I'm glad it's there to study, these are wheels I don't have to > invent for myself. http://dwheeler.com/essays/high-assurance-floss.html might be an interesting place to start. -- http://mail.python.org/mailman/listinfo/python-list

Re: tough-to-explain Python

On Jul 20, 4:00 am, greg wrote: > Calroc wrote: > > It may be that flawless software is an unreachable asymptote, like the > > speed of light for matter, but I'm (recently!) convinced that it's a > > goal worthy of exploration and effort. > > Seems to me that once you get beyond the toy program >

Re: tough-to-explain Python

On Jul 19, 2:51 pm, Paul Rubin wrote: > Calroc writes: > > I'm engaged presently in starting a school to teach programming from > > the ground up, based roughly on the curriculum outlined in the article > > I mentioned. ... > > I'm excited about formal methods becaus

Re: tough-to-explain Python

Calroc wrote: It may be that flawless software is an unreachable asymptote, like the speed of light for matter, but I'm (recently!) convinced that it's a goal worthy of exploration and effort. Seems to me that once you get beyond the toy program stage and try to apply correctness proving to re

Re: tough-to-explain Python

Calroc writes: > I'm engaged presently in starting a school to teach programming from > the ground up, based roughly on the curriculum outlined in the article > I mentioned. ... > I'm excited about formal methods because one, I just heard about them, Formal methods are a big and complicated subje

Re: tough-to-explain Python

On Jul 9, 1:20 pm, Steven D'Aprano wrote: [...] > You'll excuse my skepticism about all these claims about how anyone can > program, how easy it is to teach the fundamentals of Turing Machines and > functional programming to anybody at all. Prove it. Where are your peer- > reviewed studies demonst

Re: tough-to-explain Python

Hendrik van Rooyen wrote: The creativity could, arguably, be in the "Design". Not in the translation to python, or assembler. No way. That is just coding. No, the mechanical part of the process is called compiling, and we have programs to do it for us. By the time you've specified the design

Re: tough-to-explain Python

John O'Hagan wrote: >The drawings produced by an architect, the script of a play, the score of a piece of music, and the draft of a piece of >legislation are all examples of other things which are "useless" until they are interpreted in some way. Granted. But... >There are countless human act

Re: tough-to-explain Python

"D'Arcy J.M. Cain" > One might also argue that divorcing the design from the code is the > problem in a lot of legacy code. See Agile Programming methods. Now > you could say that there is a design step still in talking to the > client and making a plan in your head or in some notes but that's

Re: tough-to-explain Python

On Sat, 11 Jul 2009 14:01:25 +0200 "Hendrik van Rooyen" wrote: > "Programming" is the step of going from the "design" to something > that tells the machine how to implement the design. > > The creativity could, arguably, be in the "Design". > Not in the translation to python, or assembler. > No w

Re: tough-to-explain Python

Steven D'Aprano wrote: Even *soup stock* fits the same profile as what Hendrik claims is almost unique to programming. On its own, soup stock is totally useless. But you make it, now, so you can you feed it into something else later on. Or instant coffee. I think I'll avoid coming to your ho

Re: tough-to-explain Python

"pdpi" wrote; >I've always found cooking an apt metaphor for programming. No this is wrong. Writing a recipe or a cookbook is like programming. Cooking, following a recipe, is like running a program. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list

Re: tough-to-explain Python

"Steven D'Aprano" wrote: >On Fri, 10 Jul 2009 12:54:21 +0200, Hendrik van Rooyen wrote: > >> "Steven D'Aprano" wrote: >> >>>On Wed, 08 Jul 2009 22:05:57 -0700, Simon Forman wrote: >>> > persistent idea "out there" that programming is a very accessible > skill, like cooking or gardening,

Re: tough-to-explain Python

> I V (IV) wrote: >IV> On Fri, 10 Jul 2009 16:27:12 -0400, Terry Reedy wrote: >>> a bug, bug a limitation due to using limited-range numbers. If one uses >>> residue classes instead of integers, and makes no adjustment, I consider >>> it wrong to blame Bentley. >IV> But it was Bentley himsel

Re: tough-to-explain Python

On Fri, 10 Jul 2009, Hendrik van Rooyen wrote: > "Steven D'Aprano" wrote: > >On Wed, 08 Jul 2009 22:05:57 -0700, Simon Forman wrote: [...] > >> Programming is not like any other human activity. > > > >In practice? In principle? Programming in principle is not the same as it > >is performed in pr

Re: tough-to-explain Python

Bearophile wrote: kj, as Piet van Oostrum as said, that's the difference between mutable an immutable. It comes from the procedural nature of Python, and probably an explanation of such topic can't be avoided if you want to learn/teach Python. The problem with Python's mutable/immutable dis

Re: tough-to-explain Python

I V wrote: On Fri, 10 Jul 2009 16:27:12 -0400, Terry Reedy wrote: a bug, bug a limitation due to using limited-range numbers. If one uses residue classes instead of integers, and makes no adjustment, I consider it wrong to blame Bentley. But it was Bentley himself who used the C int type, so i

Re: tough-to-explain Python

On Fri, 10 Jul 2009 16:27:12 -0400, Terry Reedy wrote: > a bug, bug a limitation due to using limited-range numbers. If one uses > residue classes instead of integers, and makes no adjustment, I consider > it wrong to blame Bentley. But it was Bentley himself who used the C int type, so it hardly

Re: tough-to-explain Python

Steven D'Aprano wrote: On Thu, 09 Jul 2009 23:07:34 -0400, Terry Reedy wrote: The is *not* a bug is Bentley program. This is *not* a bug in Bentley's program. Wow. That's an impressive set of typos :) 3. Way beneath my usual standards ;-) It is a bug in bad, buggy, insane integer arit

Re: tough-to-explain Python

Steven D'Aprano wrote: On Fri, 10 Jul 2009 08:28:29 -0700, Scott David Daniels wrote: Steven D'Aprano wrote: Even *soup stock* fits the same profile as what Hendrik claims is almost unique to programming. On its own, soup stock is totally useless. But you make it, now, so you can you feed it in

Re: tough-to-explain Python

On Jul 7, 1:04 pm, kj wrote: > I'm having a hard time coming up with a reasonable way to explain > certain things to programming novices. > : > How do I explain to rank beginners (no programming experience at > all) why x and y remain unchanged above, but not z? > : > What do you say to th

Re: tough-to-explain Python

On Jul 10, 2:11 pm, Steven D'Aprano wrote: > On Fri, 10 Jul 2009 12:54:21 +0200, Hendrik van Rooyen wrote: > > "Steven D'Aprano" wrote: > > >>On Wed, 08 Jul 2009 22:05:57 -0700, Simon Forman wrote: > > persistent idea "out there" that programming is a very accessible > skill, like cooki

Re: tough-to-explain Python

On 10 Jul 2009 15:48:47 GMT Steven D'Aprano wrote: > I meant the instant coffee powder is prepared in advance. It's useless on > it's own, but later on you feed it into boiling water, add sugar and > milk, and it's slightly less useless. I don't know about that. I find instant coffee pretty us

Re: tough-to-explain Python

On Fri, 10 Jul 2009 08:28:29 -0700, Scott David Daniels wrote: > Steven D'Aprano wrote: >> Even *soup stock* fits the same profile as what Hendrik claims is >> almost unique to programming. On its own, soup stock is totally >> useless. But you make it, now, so you can you feed it into something >>

Re: tough-to-explain Python

On Fri, 10 Jul 2009 12:54:21 +0200, Hendrik van Rooyen wrote: > "Steven D'Aprano" wrote: > >>On Wed, 08 Jul 2009 22:05:57 -0700, Simon Forman wrote: >> persistent idea "out there" that programming is a very accessible skill, like cooking or gardening, anyone can do it, and even profit

Re: tough-to-explain Python

"Steven D'Aprano" wrote: >On Wed, 08 Jul 2009 22:05:57 -0700, Simon Forman wrote: > >>> persistent idea "out there" that programming is a very accessible >>> skill, like cooking or gardening, anyone can do it, and even profit >>> from it, monetarily or otherwise, etc., and to some extent I am >>

Re: tough-to-explain Python

On Thu, 09 Jul 2009 23:07:34 -0400, Terry Reedy wrote: > Steven D'Aprano wrote: > >> And speaking of binary search: >> >> [quote] >> I was shocked to learn that the binary search program that Bentley >> PROVED CORRECT and SUBSEQUENTLY TESTED [emphasis added] in Chapter 5 of >> "Programming Pearl

Re: tough-to-explain Python

Steven D'Aprano wrote: And speaking of binary search: [quote] I was shocked to learn that the binary search program that Bentley PROVED CORRECT and SUBSEQUENTLY TESTED [emphasis added] in Chapter 5 of "Programming Pearls" contains a bug. Once I tell you what the it is, you will understand wh

Re: tough-to-explain Python

Steven D'Aprano wrote: There is some evidence that 30-60% of people simply cannot learn to program, no matter how you teach them: http://www.codinghorror.com/blog/archives/000635.html http://www.cs.mdx.ac.uk/research/PhDArea/saeed/ I'm sympathetic to the idea, but not entirely convinced. Per

Re: tough-to-explain Python

On Thu, 2009-07-09 at 18:10 +, Steven D'Aprano wrote: > If programming is symbol manipulation, then you should remember that > the > user interface is also symbol manipulation, and it is a MUCH harder > problem than databases, sorting, searching, and all the other > problems > you learn abou

Re: tough-to-explain Python

On Wed, 08 Jul 2009 22:05:57 -0700, Simon Forman wrote: >> persistent idea "out there" that programming is a very accessible >> skill, like cooking or gardening, anyone can do it, and even profit >> from it, monetarily or otherwise, etc., and to some extent I am > > Programming is not like any ot

Re: tough-to-explain Python

On Wed, 08 Jul 2009 22:05:57 -0700, Simon Forman wrote: > The core abstractions of [mechanical] computation are just not that > complicated. You can teach them to anybody in about a half an hour, > drunk. I have. That's *easy*. Anyone can teach the most complicated and abstract principles of an

Re: tough-to-explain Python

On Thu, Jul 9, 2009 at 1:05 AM, Simon Forman wrote: > Everyone gets so caught up in programming via languages that > you get, well, people trying to teach "Computer Programming" as if it > were only necessary to grok a language, rather than grokking /symbol > manipulation/ itself. > > +1 QOTW. I'

Re: tough-to-explain Python

greg wrote: Dave Angel wrote: By the time I graduated, I had five six-level languages ^^^ Are they languages that you have to edit using vi? :-) Back then I didn't need glasses. That was of course intended to be "six high-level languages" -- http://

Re: tough-to-explain Python

Dave Angel wrote: By the time I graduated, I had five six-level languages ^^^ Are they languages that you have to edit using vi? :-) -- Greg -- http://mail.python.org/mailman/listinfo/python-list

Re: tough-to-explain Python

(I wanted to reply to a few messages in one post so I quoted them all below. Let me know if this is bad etiquette.) On Jul 8, 8:23 am, kj wrote: > In <5f0a2722-45eb-468c-b6b2-b7bb80ae5...@q11g2000yqi.googlegroups.com> Simon > Forman writes: > > >Frankly, I'm of the impression that it's a mistak

Re: tough-to-explain Python

kj wrote: In <5f0a2722-45eb-468c-b6b2-b7bb80ae5...@q11g2000yqi.googlegroups.com> Simon Forman writes: Frankly, I'm of the impression that it's a mistake not to start teaching programming with /the bit/ and work your way up from there. I'm not kidding. I wrote a (draft) article about this:

Re: tough-to-explain Python

On Jul 7, 5:18 pm, kj wrote: > In Chris Rebert > writes: > > >You might find the following helpful (partially): > >http://effbot.org/zone/call-by-object.htm > > Extremely helpful.  Thanks!  (I learned more from it than someone > who will teach the stuff would care to admit...) > > And it confir

Re: tough-to-explain Python

2009/7/8 kj : > There is this > persistent idea "out there" that programming is a very accessible > skill, like cooking or gardening, anyone can do it, and even profit > from it, monetarily or otherwise, etc., and to some extent I am > actively contributing to this perception by teaching this cours

Re: tough-to-explain Python

In <5f0a2722-45eb-468c-b6b2-b7bb80ae5...@q11g2000yqi.googlegroups.com> Simon Forman writes: >I'm not kidding. I wrote a (draft) article about this: "Computer >Curriculum" http://docs.google.com/View?id=dgwr777r_31g4572gp4 Very cool. kj -- http://mail.python.org/mailman/listinfo/python-list

Re: tough-to-explain Python

On Wed, 08 Jul 2009 12:23:50 +, kj wrote: > In <5f0a2722-45eb-468c-b6b2-b7bb80ae5...@q11g2000yqi.googlegroups.com> > Simon Forman writes: > >>Frankly, I'm of the impression that it's a mistake not to start teaching >>programming with /the bit/ and work your way up from there. I'm not >>kiddi

Re: Fractions as result from divisions (was: Re: tough-to-explain Python)

On Wed, 08 Jul 2009 11:24:28 +0200, Ulrich Eckhardt wrote: > Bearophile wrote: >> For example a novice wants to see 124 / 38 to return the 62/19 fraction >> and not 3 or 3.263157894736842 :-) > > Python has adopted the latter of the three for operator / and the the > second one for operator //.

Re: tough-to-explain Python

In <5f0a2722-45eb-468c-b6b2-b7bb80ae5...@q11g2000yqi.googlegroups.com> Simon Forman writes: >Frankly, I'm of the impression that it's a mistake not to start >teaching programming with /the bit/ and work your way up from there. >I'm not kidding. I wrote a (draft) article about this: "Computer >Cu

Re: Fractions as result from divisions (was: Re: tough-to-explain Python)

In Ulrich Eckhardt writes: >Bearophile wrote: >> For example a novice wants to see 124 / 38 to return the 62/19 >> fraction and not 3 or 3.263157894736842 :-) >Python has adopted the latter of the three for operator / and the the second >one for operator //. I wonder if it was considered to ju

Fractions as result from divisions (was: Re: tough-to-explain Python)

Bearophile wrote: > For example a novice wants to see 124 / 38 to return the 62/19 > fraction and not 3 or 3.263157894736842 :-) Python has adopted the latter of the three for operator / and the the second one for operator //. I wonder if it was considered to just return a fraction from that opera

Re: tough-to-explain Python

> Simon Forman (SF) wrote: >SF> Why would you even tell the poor bastards about "+=" before they were >SF> comfortable with (python's style of) function calls, immutable >SF> integers, mutable lists and immutable tuples? >SF> Let them use "x = x + y" until they have enough knowledge to >SF>

Re: tough-to-explain Python

En Wed, 08 Jul 2009 04:32:07 -0300, Francesco Bochicchio escribió: I would go with something like this: """ In object oriented programming, the same function or operator can be used to represent different things. This is called overloading. To understand what the operator/function do, we hav

Re: tough-to-explain Python

On Jul 7, 10:04 pm, kj wrote: > I'm having a hard time coming up with a reasonable way to explain > certain things to programming novices. > > Consider the following interaction sequence: > > >>> def eggs(some_int, some_list, some_tuple): > > ...     some_int += 2 > ...     some_list += [2] > ...

Re: tough-to-explain Python

On Tue, 07 Jul 2009 20:04:46 +, kj wrote: > I'm having a hard time coming up with a reasonable way to explain > certain things to programming novices. [...] > Or consider this one: > ham = [1, 2, 3, 4] spam = (ham,) spam > ([1, 2, 3, 4],) spam[0] is ham > True spam

Re: tough-to-explain Python

On Jul 7, 4:04 pm, kj wrote: > I'm having a hard time coming up with a reasonable way to explain > certain things to programming novices. > > Consider the following interaction sequence: > > >>> def eggs(some_int, some_list, some_tuple): > > ... some_int += 2 > ... some_list += [2] > ...

Re: tough-to-explain Python

En Tue, 07 Jul 2009 17:04:46 -0300, kj escribió: I'm having a hard time coming up with a reasonable way to explain certain things to programming novices. ham = [1, 2, 3, 4] spam = (ham,) spam ([1, 2, 3, 4],) spam[0] is ham True spam[0] += [5] Traceback (most recent call last): File "",

Re: tough-to-explain Python

Ben, > I have got very good results from teaching using the analogy of "paper tags > tied to physical objects" to describe Python's references to values. Great analogy!! And an excellent analogy for newcomers to Python. (this would have saved me some personal pain in my early days). Regards, Ma

Re: tough-to-explain Python

On Tue, 07 Jul 2009 21:18:53 +, kj wrote: > I had not realized how *profoundly* different the meaning of the "=" in > Python's > > spam = ham > > is from the "=" in its > > spam[3] = ham[3] > > So much for "explicit is better than implicit"... I'm sorry, I don't get it. Can you explai

Re: tough-to-explain Python

On Jul 7, 8:06 pm, Ben Finney wrote: > I have got very good results from teaching using > the analogy of “paper tags tied to physical objects” > to describe Python's references to values. Ah, I like that! I think it's better than what I used in my post (which I composed and submitted before your

Re: tough-to-explain Python

On Jul 7, 5:11 pm, kj wrote: > I don't plan to present these examples to them. > But beginners have a way of bumping into such > conundrums all on their own [...].  I doubt that > an answer of the form "don't worry your pretty > little head over this now; wait until your second > course" will do t

Re: tough-to-explain Python

kj writes: > In Chris Rebert > writes: > > >You might find the following helpful (partially): > >http://effbot.org/zone/call-by-object.htm > > Extremely helpful. Thanks! (I learned more from it than someone > who will teach the stuff would care to admit...) I have got very good results fr

Re: tough-to-explain Python

I really enjoyed your boxes analogy, from a guy with a trucking background, it makes a lot of sense! -Bret > ... The more I delve into OOP the more I liken an 'object' to a box. A box > with a shipping manifest. > > There are big boxes, > little boxes, > squat boxes and so on. > > A box can conta

Re: tough-to-explain Python

Bearophile wrote: kj, as Piet van Oostrum as said, that's the difference between mutable an immutable. It comes from the procedural nature of Python, and probably an explanation of such topic can't be avoided if you want to learn/teach Python. ...(snip) See you later, bearophile

Re: tough-to-explain Python

kj, as Piet van Oostrum as said, that's the difference between mutable an immutable. It comes from the procedural nature of Python, and probably an explanation of such topic can't be avoided if you want to learn/teach Python. Lot of people think that a language where everything is immutable is sim

Re: tough-to-explain Python

In Chris Rebert writes: >You might find the following helpful (partially): >http://effbot.org/zone/call-by-object.htm Extremely helpful. Thanks! (I learned more from it than someone who will teach the stuff would care to admit...) I had not realized how *profoundly* different the meaning o

Re: tough-to-explain Python

In Piet van Oostrum writes: >> kj (k) wrote: >>k> I'm having a hard time coming up with a reasonable way to explain >>k> certain things to programming novices. >>k> Consider the following interaction sequence: >> def eggs(some_int, some_list, some_tuple): >>k> ... some_int += 2 >

Re: tough-to-explain Python

> kj (k) wrote: >k> I'm having a hard time coming up with a reasonable way to explain >k> certain things to programming novices. >k> Consider the following interaction sequence: > def eggs(some_int, some_list, some_tuple): >k> ... some_int += 2 >k> ... some_list += [2] >k> ...

Re: tough-to-explain Python

On Tue, Jul 7, 2009 at 1:04 PM, kj wrote: > > > I'm having a hard time coming up with a reasonable way to explain > certain things to programming novices. > > Consider the following interaction sequence: > def eggs(some_int, some_list, some_tuple): > ...     some_int += 2 > ...     some_list +