Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #75925 > unrolled thread
| Started by | luofeiyu <elearn2014@gmail.com> |
|---|---|
| First post | 2014-08-09 10:35 -0700 |
| Last post | 2014-08-11 03:17 +1000 |
| Articles | 7 on this page of 67 — 15 participants |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: how to get the ordinal number in list luofeiyu <elearn2014@gmail.com> - 2014-08-09 10:35 -0700
Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-09 13:06 +1000
Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-08 20:48 -0700
Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-09 11:34 -0400
Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-10 09:43 +1000
Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 09:28 -0700
Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-10 13:10 -0400
Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 10:34 -0700
Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-10 14:14 -0400
Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 11:26 -0700
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 05:03 +1000
Re: how to get the ordinal number in list Marko Rauhamaa <marko@pacujo.net> - 2014-08-10 22:14 +0300
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 05:20 +1000
Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 22:23 -0700
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 15:46 +1000
Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 23:22 -0700
Re: how to get the ordinal number in list Steven D'Aprano <steve@pearwood.info> - 2014-08-11 08:55 +0000
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 19:15 +1000
Re: how to get the ordinal number in list Marko Rauhamaa <marko@pacujo.net> - 2014-08-11 12:35 +0300
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 19:51 +1000
Re: how to get the ordinal number in list Marko Rauhamaa <marko@pacujo.net> - 2014-08-11 13:46 +0300
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 21:06 +1000
Re: how to get the ordinal number in list Steven D'Aprano <steve@pearwood.info> - 2014-08-11 09:44 +0000
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 19:53 +1000
Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-11 21:30 +1000
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 20:07 +1000
Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-13 10:47 +1000
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-13 11:31 +1000
Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-12 21:45 -0400
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-13 12:06 +1000
Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-11 07:55 -0400
Re: how to get the ordinal number in list Tim Chase <python.list@tim.thechases.com> - 2014-08-11 07:30 -0500
Re: how to get the ordinal number in list Marko Rauhamaa <marko@pacujo.net> - 2014-08-11 15:41 +0300
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 22:53 +1000
Re: how to get the ordinal number in list Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-11 14:57 +0100
Re: how to get the ordinal number in list Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-10 21:32 +0100
Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-10 18:01 -0400
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 08:43 +1000
Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 20:35 -0700
Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-11 12:04 +1000
Re: how to get the ordinal number in list Robert Kern <robert.kern@gmail.com> - 2014-08-11 12:56 +0100
Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-11 05:11 -0700
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 22:45 +1000
Re: how to get the ordinal number in list Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-11 15:01 +0100
Re: how to get the ordinal number in list alister <alister.nospam.ware@ntlworld.com> - 2014-08-11 12:30 +0000
Re: how to get the ordinal number in list Marko Rauhamaa <marko@pacujo.net> - 2014-08-11 15:41 +0300
Re: how to get the ordinal number in list Robin Becker <robin@reportlab.com> - 2014-08-11 15:32 +0100
Re: how to get the ordinal number in list Terry Reedy <tjreedy@udel.edu> - 2014-08-11 18:01 -0400
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-12 09:27 +1000
Re: how to get the ordinal number in list wxjmfauth@gmail.com - 2014-08-12 00:21 -0700
Re: how to get the ordinal number in list alister <alister.nospam.ware@ntlworld.com> - 2014-08-12 10:40 +0000
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-12 23:39 +1000
Re: how to get the ordinal number in list alister <alister.nospam.ware@ntlworld.com> - 2014-08-12 18:45 +0000
Re: how to get the ordinal number in list Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-12 20:16 +0100
Re: how to get the ordinal number in list "Neil D. Cerutti" <neilc@norwich.edu> - 2014-08-12 13:40 -0400
Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-12 11:20 -0700
Re: how to get the ordinal number in list "Neil D. Cerutti" <neilc@norwich.edu> - 2014-08-12 15:29 -0400
Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-12 20:49 -0700
Re: how to get the ordinal number in list Terry Reedy <tjreedy@udel.edu> - 2014-08-12 18:01 -0400
Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-11 13:00 +1000
Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 21:29 -0700
Re: how to get the ordinal number in list Steven D'Aprano <steve@pearwood.info> - 2014-08-11 10:28 +0000
Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-11 04:49 -0700
Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-13 12:11 +1000
Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-13 12:18 +1000
Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-13 13:11 +1000
Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-11 03:17 +1000
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-08-10 21:29 -0700 |
| Message-ID | <2768e86c-34cf-4478-ac02-2ea6a4eb9236@googlegroups.com> |
| In reply to | #76016 |
On Monday, August 11, 2014 8:30:32 AM UTC+5:30, Steven D'Aprano wrote:
> You did the same thing in your own course, the only difference being you
> accepted a different set of primitive functions. But ultimately you have to
> introduce *some* amount of concreteness, at some level, otherwise we're
> just engaged in mental masturbation:
> Q: "Write a function to calculate the nth Catalan number."
> A: "Assume that a function Catalan(n) exists and calculates the nth Catalan
> number. Then the solution is Catalan."
You're concocting your own definitions and critiquing/refuting them.
Here is the Haskell definition [Ive modernized my '93 code].
It corresponds to the 4th interpretation from
http://en.wikipedia.org/wiki/Catalan_number#Applications_in_combinatorics
-- applications of a bin op to a 'full' binary tree
All of 3 lines!
data Tree a = I (Tree a) (Tree a) | L a deriving Show
c [x]= [L x]
c ls = [I x y | i<-[1..length ls -1], let (l,r) = splitAt i ls, x <- c l, y <- c r]
Read 'L' as Leaf Node
'I' as Internal Node
'c' as the catalan enumerator
splitAt splits a list at a position:
*Main> splitAt 3 [3,4,5,6,7]
([3,4,5],[6,7])
And some example runs
*Main> c []
[]
*Main> c [1]
[L 1]
*Main> c [1,2]
[I (L 1) (L 2)]
*Main> c [1,2,3]
[I (L 1) (I (L 2) (L 3)),I (I (L 1) (L 2)) (L 3)]
*Main> c [1,2,3,4]
[I (L 1) (I (L 2) (I (L 3) (L 4))),I (L 1) (I (I (L 2) (L 3)) (L 4)),I (I (L 1) (L 2)) (I (L 3) (L 4)),I (I (L 1) (I (L 2) (L 3))) (L 4),I (I (I (L 1) (L 2)) (L 3)) (L 4)]
*Main>
Opening up the last eg into separate lines:
[I (L 1) (I (L 2) (I (L 3) (L 4))),
I (L 1) (I (I (L 2) (L 3)) (L 4)),
I (I (L 1) (L 2)) (I (L 3) (L 4)),
I (I (L 1) (I (L 2) (L 3))) (L 4),
I (I (I (L 1) (L 2)) (L 3)) (L 4)]
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2014-08-11 10:28 +0000 |
| Message-ID | <53e89aeb$0$29890$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #76018 |
On Sun, 10 Aug 2014 21:29:12 -0700, Rustom Mody wrote: > On Monday, August 11, 2014 8:30:32 AM UTC+5:30, Steven D'Aprano wrote: > >> You did the same thing in your own course, the only difference being >> you accepted a different set of primitive functions. But ultimately you >> have to introduce *some* amount of concreteness, at some level, >> otherwise we're just engaged in mental masturbation: > >> Q: "Write a function to calculate the nth Catalan number." A: "Assume >> that a function Catalan(n) exists and calculates the nth Catalan >> number. Then the solution is Catalan." > > > You're concocting your own definitions and critiquing/refuting them. No, but I think you are deliberately choosing to ignore my point for the sake of cheap shots. My point is that, at *some* level, you have to actually write code (well duh!) which must be targeted at some concrete environment. Different languages provide different levels of abstraction, but they all have a some concrete set of primitive operations which actually do *something*, and that something is concrete, not abstract. Every function, even in Haskell, has an implementation. Otherwise if you don't need an implementation, you can just declare "imagine a function that implements Foo" for any Foo, and you're done.[1] Computer science, if might be said, is the search for better and more productive abstractions which provide more useful implementations for concrete tasks. [1] A perfectly reasonable approach, sometimes, for some philosophical questions, including sometimes philosophical questions within the scope of computer science. E.g. if we had a supertask, or an oracle-machine, what class of problems could we solve? -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-08-11 04:49 -0700 |
| Message-ID | <f134ffa2-51d0-4840-97f5-b2e857cca615@googlegroups.com> |
| In reply to | #76044 |
On Monday, August 11, 2014 3:58:59 PM UTC+5:30, Steven D'Aprano wrote: > On Sun, 10 Aug 2014 21:29:12 -0700, Rustom Mody wrote: > > On Monday, August 11, 2014 8:30:32 AM UTC+5:30, Steven D'Aprano wrote: > >> You did the same thing in your own course, the only difference being > >> you accepted a different set of primitive functions. But ultimately you > >> have to introduce *some* amount of concreteness, at some level, > >> otherwise we're just engaged in mental masturbation: > >> Q: "Write a function to calculate the nth Catalan number." A: "Assume > >> that a function Catalan(n) exists and calculates the nth Catalan > >> number. Then the solution is Catalan." > > You're concocting your own definitions and critiquing/refuting them. > No, but I think you are deliberately choosing to ignore my point for the Because I dont understand what you are saying. [See below] > My point is that, at *some* level, you have to > actually write code (well duh!) which must be targeted at some concrete > environment. Different languages provide different levels of abstraction, > but they all have a some concrete set of primitive operations which > actually do *something*, and that something is concrete, not abstract. > Every function, even in Haskell, has an implementation. Otherwise if you > don't need an implementation, you can just declare "imagine a function > that implements Foo" for any Foo, and you're done.[1] I guess part of the problem is that evidently you and I use 'concrete' and 'abstract' in almost diametrically opposite ways. In my book, FP is easy and pleasant and smooth because (among other things) FP types are concrete, whereas OOP types are abstract. Here is an FP classic: http://www.nlda-tw.nl/janmartin/vakken/TFIT/Extra%20materiaal/Bird_Wadler.%20Introduction%20to%20Functional%20Programming.1ed.pdf In the section on 'abstract types' (pg 221 chap 8) he briefly explains what is an abstract type and indicates that the whole book only deals with concrete types. This was written in 1988. Across the last 25 years this view has only strengthened at least in the FP circles, viz. that concrete types are all thats needed for the most part whereas abstract types (ADTs) and other OOP fancies are a waste of time, a PITA and not worth the sweat of pursuing them. You are of course free to disagree with this viewpoint -- the majority of programmers do. But now you are turning the tables and saying that the FP types/constructs are more abstract than the conventional ones. I dont argue with this because I dont know how to, other than to say it does not seem to be the dominant view in either the conventional (OOP/imperative) communities or in the FP community. Here is a conversation from reddit: http://www.reddit.com/r/haskell/comments/xgq27/uday_reddy_sharpens_up_referential_transparency/ which should give a sense of the pov. Person 1 | By the way, somebody commented on the StackOverflow page that the | naive functional programmer seems to use syntactic reasoning while the | naive imperative programmer seems to use operational reasoning. Person 2 | Interesting. I have a theory that functional programmers use more | concrete (denotative, indicative, elemental) thought whereas | imperative programmers use more abstract (connotative, analogous) | thought. However, sequential and random thinking styles can also be | very different. On the Meyers-Briggs functional and imperative | programmers seem to differ on both axies of the four main personality | groups. Person 3 | Yup, that is also a quite insightful point. But we also need to keep | in mind the training aspect. Functional programming is taught in a | semi-rigorous way, using the knowledge of set theory and mathematics | that we all know. Imperative programming is taught in an intuitive | way, because there is no well-understood mathematics for it yet. In | fact, let us say that imperative programming is not really taught at | all. Whatever the imperative programmers learn, they learn through | experience. They write programs, see how they behave, and build up a | mental picture of how they work and how to reason about them. It is an | art rather than a science.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-08-13 12:11 +1000 |
| Message-ID | <53eac942$0$29980$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #76048 |
Rustom Mody wrote:
> I guess part of the problem is that evidently you and I use 'concrete'
> and 'abstract' in almost diametrically opposite ways.
[...]
> But now you are turning the tables and saying that the FP types/constructs
> are more abstract than the conventional ones.
[...]
> In my book, FP is easy and pleasant and smooth because (among other
> things) FP types are concrete, whereas OOP types are abstract.
I wrote about how your view of sorted() was an abstraction, not an Abstract
Base Class. I thought that was clear enough: you ignore the concrete
details of how one sorts (bubblesort, quicksort, timsort, ...) and
everything but the result returned. I shouldn't think that is
controversial. Let me repeat what I said at the time:
You are abstracting away the details of the real computer
implementation into an abstraction of a pure mathematical
function...
I am not talking about *abstract types* in the object-oriented sense.
I then went on to say:
But abstractions leak, and someday someone is going to ask
"Why does it take 45 minutes to find the five largest values
of my list?", and if you persist in insisting that sorted()
is a pure mathematical function you will have no clue on how
to even begin solving this [...]
(I don't actually believe that *you personally* are incapable of thinking
about the implementation of sorted(). It is a hypothetical situation.)
For the record, Wikipedia defines abstract types as:
In programming languages, an abstract type is a type in a
nominative type system which cannot be instantiated directly.
Abstract types are also known as existential types.
and contrasts them with "concrete types" like Python's float, list, str.
I am using "abstract" in the sense of an abstraction, as opposed to
something concrete and real, not as a mechanism for specifying interfaces in
Java or Python. Python's float is a leaky abstraction of mathematical Real
numbers, and Python's softed() is a leaky abstraction of the concept of
sorting a collection. Both are abstractions, because they are *intended* to
gloss over real world details of Real numbers and sorting, but both leak
because the implementation of the abstraction spoils the abstraction.
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-08-13 12:18 +1000 |
| Message-ID | <mailman.12907.1407896317.18130.python-list@python.org> |
| In reply to | #76165 |
On Wed, Aug 13, 2014 at 12:11 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > both leak > because the implementation of the abstraction spoils the abstraction. Can you name *any* nontrivial abstraction that doesn't leak? I can't. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-08-13 13:11 +1000 |
| Message-ID | <53ead75e$0$29986$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #76165 |
Steven D'Aprano wrote:
[...]
> I am using "abstract" in the sense of an abstraction, as opposed to
> something concrete and real, not as a mechanism for specifying interfaces
> in Java or Python. Python's float is a leaky abstraction of mathematical
> Real numbers, and Python's softed() is a leaky abstraction of the concept
> of sorting a collection.
Oh, I forgot to mention... "sorting a collection" is itself an abstraction
(that is, a generalisation) of concrete examples of sorting, such as
sorting a hand of cards, sorting an unruly crowd of school children into
order of height, sorting out a messy cutlery drawer, or sorting the books
in a library.
Abstractions are good and necessary, being a programmer is about learning to
invent and use abstractions, but both object-oriented and functional
programming circles are prone to over-abstraction and that's why they're a
an ill-fit for teaching beginners.
To a beginner, functions and their return result is an abstraction (and
quite a hard one for many people to learn). The natural tendency is to
write functions like this:
def frobnicate(value):
print (value + spam + eggs)
because they're thinking "how do I get the frobnicated value?" and the
obvious interface between "I" (the beginner) and the computer is visual.
They haven't learned the essential abstraction known as "returning a value"
yet and so they use:
- calculate the frobnicated value
- print it
instead of the generalisation:
- calculate the frobnicated value
- return[1] it to the caller[2]
- which captures that return result somewhere[3]
- and finally prints it
or possibly this one:
- calculate the frobnicated value
- return it to the REPL
- which prints it then throws it away
[1] What does "return" in the context of functions even mean? Try explaining
it to a beginner who doesn't understand functions. The best I can come up
with is you just keep showing them examples until they draw the connection
themselves.
[2] Who?
[3] Where?
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-08-11 03:17 +1000 |
| Message-ID | <53e7a918$0$30002$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #75983 |
Rustom Mody wrote:
> On Saturday, August 9, 2014 9:04:22 PM UTC+5:30, Roy Smith wrote:
[...]
>> They haven't figured out yet that the
>> first step to solving a problem is to decide what algorithms you're
>> going to use, and only then can you start translating that into code.
>> They need to be led in small steps towards basic knowledge.
>
> makes perfect sense... under one assumption: viz.
> The 'first steps' to becoming a programmer are necessarily imperative
> steps. So much so that programming is usually *defined* as imperative
> programming. This usually goes thus:
"Necessarily"? Well, that's possibly a bit strong, but I think it is
reasonable to say that the first steps to becoming a programmer are
*preferably* imperative, because the real world is imperative. If you want
to make a coffee, you:
- get a cup
- put instant coffee in the cup
- put sugar in the cup
- boil water
- pour boiling water into the cup
- stir
- add milk
not:
- call an abstract make_coffee() function.
> - CS is defined as the science of algorithms (or algorithmics)
Yes, but algorithms can be either concrete ("put the kettle on the stove and
light the gas"), intermediate ("bring the water to the boil at 100°C"), or
fully abstract ("f(Temperature(water)) = lambda: 100°C", or something like
that). So CS can and does envelop both imperative and functional
programming. They just don't typically teach functional programming to
beginners.
> - Programming (in the layman sense: python, java, C etc) is just about
> converting these 'abstract algorithms' into executable code
> - And an algorithm? An algorithm is an effective method expressed as a
> finite list[1] of well-defined instructions[2] for calculating a function.
> quoting http://en.wikipedia.org/wiki/Algorithm
>
> In my view this is starting from the wrong end.
> I do not need to know which kind of adder the hardware is implementing to
> use +, which sorting algorithm to use sort, etc.
Nobody says that you do. You're attacking a strawman.
> IOW the 'calculating a function' is primary and the 'effective steps'
> is secondary and traditional programming pedagogy gets this order wrong.
"Calculating a function" is *incredibly* abstract, and quite hard to
consider. If you think it isn't, then you're probably focused on a subset
of problems that involve transformations which are trivially modelled by
mathematical functions.
> What do I need to know to use sort? Nothing? Not so. I should be able to
> distinguish a sorted list from an unsorted one. This is primary.
> Getting from one to the other -- the how -- is secondary.
And how do you distinguish sorted list from an unsorted list, using
functional styles? You're not allowed to just propose a magic "is_sorted()"
function, any more than you're allowed to propose a magic "do whatever I
want" function. (The whole point of CS is to learn how to program, not to
just assume the program you want already exists.) Nor is it sufficient to
define it this way:
def is_sorted(alist):
return alist == sorted(alist)
since that assumes that sorted is correct. Consider this definition of
sorted:
def sorted(alist):
return alist
Now, the naturally intuitive way to determine whether something is sorted is
imperative: you start at one end of the list and loop over pairs of items.
If every item is >= to the previous item, the list is sorted. Now, of
course we both know that we can turn that into a functional approach using
reduce(), but if you can find one person in a hundred -- hell, even one
person in a thousand -- who will intuitively come up with that approach in
preference to the imperative style without being coached, I'll buy you a
coffee or soft drink of your choice.
Even Carl Gauss started off reasoning imperatively, and he was a natural
mathematics genius.
Learning programming is hard enough without trying to do it floating up in
the stratosphere breathing vacuum. Abstractions are *hard*, and the
functional approach is an abstraction.
[...]
> As a more demonstrative example of the above (abstract) talk, in the 90s
> I used to teach a first course in programming using a predecessor of
> haskell (gofer -- gofer stands for GOod For Equational Reasoning).
Aimed at what age and experience of student? There's a big difference
between aiming a course at mathematics post-grads, or at 12 year olds who
are still a bit fuzzy about the whole "what's a function?" thing.
What percentage of students passed?
> By the end of the course students could
> - handle data structures like generic n-ary trees, graphs etc
> - write toy interpreters, compilers, semantic functions
> - combinatorial enumerators corresponding to various types
> of combinatorial functions like ⁿCr ⁿPr Catalan numbers
>
> All WITHOUT a single assignment statement
> [very easy to accomplish since the language has no assignment statement
> [:-) ]
>
> and more important (and germane to this thread) NO PRINT statement.
Hmmm. With no print, how could they tell whether their program was correct?
By writing to a file? But that's just a generalised print.
Wait... I get it... you have a print, it's just a function, not a statement.
Am I close?
> Instead if we treated the python:
>
> [x**2 for x in range(10)]
>
> as an executable version for the standard set-theory expression:
>
> {x² | x ∈ [0..10) }
Apart from a difference of notation, the way I learned list comprehensions
was by learning the correspondence to "set builder notation", but then I
have a maths degree and many years of practice at using that notation. The
average beginner may never have seen set builder notation, or forgotten it
if they have.
--
Steven
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.python
csiph-web