Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Friday, May 15, 2015 at 10:36:45 PM UTC-5, Rustom Mody wrote: > On Saturday, May 16, 2015 at 8:56:00 AM UTC+5:30, zipher wrote: > > On Wednesday, May 13, 2015 at 9:36:27 PM UTC-5, Mark Lawrence wrote: > > > On 14/05/2015 02:40, Steven D'Aprano wrote: > > > > On Thu, 14 May 2015 04:07 am, zipher wrote: > > > > > > > >> > > > >> No, you haven't understood, padawan. Lambda *is* the function, not > > > >> it's > > > >> definition. Perhaps you will understand what I mean by that, perhaps > > > >> you > > > >> won't. It's subtle. > > > > > > > > Subtle like a kick to the head. > > > > > > From the very first drivel that he posted on python ideas just over two > > > years ago, he's shown that he's incapable of any logical thought > > > relating to computing, in just the same way that the RUE has never > > > posted anything logical about the FSR. Please can we stop feeding him. > > > > The truth is quite the opposite. There is something very strange going on > > around the nets. People are very confused. Javascript has confused them. > > Tell me where is the lexer in Javascript? or the virtual machine? > > > > The point I'm making about LISP is that in LISP you don't define a > > function, it IS the function. Instead of f(x,y) = x+y, which is how you > > code a traditional program, you only show/program f itself. In the lambda > > calculus, it is expressed f = /(x,y).x+y where / is the lambda character, > > not f(x) or f OF x. Do you see why the difference is subtle? > > > > Java has a virtual machine. Python has a virtual machine. Do you think > > Chrome and these browsers include virtual machines to run on 50 different > > architectures? I'm actually curious if anyone has a non-magical answer to > > it. We all assume that computers can only act logically and have always > > acted such. But they way some people act and the way somethings are being > > done is making questions. Perhaps I'm the only one. > > > > As for chrome and its specific VM > http://en.wikipedia.org/wiki/V8_%28JavaScript_engine%29 > > As for the rest... > We are as confused by your confusions as you are > > [Your continual assertions about everyone everywhere being totally confused > reminds me of my first trip to N America where I was unnerved to find everyone > driving on the wrong side of the road] Thanks for that note, actually, it's quite apropos. I'm a space cowboy who's trying to tell people what I've seen from "outside the fishbowl". To those in the fishbowl, they don't think that they're in water, because they've never been outside of it--the concept doesn't exist. But I left the orthodoxy (without throwing it away) and saw from the outside. Zen is one of the nodal points of that outside. And from that view, I can tell you that Python has abandoned much of it`s Zen to the point that is now only held by the programmers who still believe in it like some lost ancient tablet that they keep in their pocket. It can come back easily, though. One conversation in person with a whiteboard would do it. I'm starting to see why I'm seen as such an iconoclast: I've been outside of it for a long time and have taken it for granted -- I couldn't see my own "water". Oh well. Maybe the relationship will be mended with the community, or maybe not. My psychological states go from one extreme to another, so that's my "thing" in case anyone was wondering what my issue is--it's happened ever since getting tazered. It sucked. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Saturday, May 16, 2015 at 8:56:00 AM UTC+5:30, zipher wrote: > On Wednesday, May 13, 2015 at 9:36:27 PM UTC-5, Mark Lawrence wrote: > > On 14/05/2015 02:40, Steven D'Aprano wrote: > > > On Thu, 14 May 2015 04:07 am, zipher wrote: > > > > > >> > > >> No, you haven't understood, padawan. Lambda *is* the function, not it's > > >> definition. Perhaps you will understand what I mean by that, perhaps you > > >> won't. It's subtle. > > > > > > Subtle like a kick to the head. > > > > From the very first drivel that he posted on python ideas just over two > > years ago, he's shown that he's incapable of any logical thought > > relating to computing, in just the same way that the RUE has never > > posted anything logical about the FSR. Please can we stop feeding him. > > The truth is quite the opposite. There is something very strange going on > around the nets. People are very confused. Javascript has confused them. > Tell me where is the lexer in Javascript? or the virtual machine? > > The point I'm making about LISP is that in LISP you don't define a function, > it IS the function. Instead of f(x,y) = x+y, which is how you code a > traditional program, you only show/program f itself. In the lambda calculus, > it is expressed f = /(x,y).x+y where / is the lambda character, not f(x) or f > OF x. Do you see why the difference is subtle? > > Java has a virtual machine. Python has a virtual machine. Do you think > Chrome and these browsers include virtual machines to run on 50 different > architectures? I'm actually curious if anyone has a non-magical answer to > it. We all assume that computers can only act logically and have always > acted such. But they way some people act and the way somethings are being > done is making questions. Perhaps I'm the only one. > As for chrome and its specific VM http://en.wikipedia.org/wiki/V8_%28JavaScript_engine%29 As for the rest... We are as confused by your confusions as you are [Your continual assertions about everyone everywhere being totally confused reminds me of my first trip to N America where I was unnerved to find everyone driving on the wrong side of the road] -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wednesday, May 13, 2015 at 9:36:27 PM UTC-5, Mark Lawrence wrote: > On 14/05/2015 02:40, Steven D'Aprano wrote: > > On Thu, 14 May 2015 04:07 am, zipher wrote: > > > >> > >> No, you haven't understood, padawan. Lambda *is* the function, not it's > >> definition. Perhaps you will understand what I mean by that, perhaps you > >> won't. It's subtle. > > > > Subtle like a kick to the head. > > From the very first drivel that he posted on python ideas just over two > years ago, he's shown that he's incapable of any logical thought > relating to computing, in just the same way that the RUE has never > posted anything logical about the FSR. Please can we stop feeding him. The truth is quite the opposite. There is something very strange going on around the nets. People are very confused. Javascript has confused them. Tell me where is the lexer in Javascript? or the virtual machine? The point I'm making about LISP is that in LISP you don't define a function, it IS the function. Instead of f(x,y) = x+y, which is how you code a traditional program, you only show/program f itself. In the lambda calculus, it is expressed f = /(x,y).x+y where / is the lambda character, not f(x) or f OF x. Do you see why the difference is subtle? Java has a virtual machine. Python has a virtual machine. Do you think Chrome and these browsers include virtual machines to run on 50 different architectures? I'm actually curious if anyone has a non-magical answer to it. We all assume that computers can only act logically and have always acted such. But they way some people act and the way somethings are being done is making questions. Perhaps I'm the only one. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wednesday, May 13, 2015 at 8:14:39 PM UTC+5:30, zipher wrote: > On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote: > > On Wednesday, May 13, 2015 at 8:00:50 AM UTC+5:30, Steven D'Aprano wrote: > > > Why can't a language be designed with a *practical and concrete* need in > > > mind? As far as I know, only one language designed from theoretical first > > > principles has had any measure of mainstream success, Lisp, and that was > > > probably because there weren't that many decent alternatives at the time. > > > > How history U-turns!! > > Lisp actually got every major/fundamental thing wrong > > - variables scopes were dynamic by mistake > > - lambdas were non-first class because the locution 'first-class' was still > > 8 > > years in the future > > I think you're confused. LISP doesn't have variables. It's a lambda > calculus with an entirely different model computation than other programming > languages which use variables all the time. To the extent that it DOES have > variables, it's to accomidate those coming over from iterative programming. > > And the idea of lambdas were already encoded by the use of special > expressions, set-off by parenthesis. So they practically *defined* the > concept of lambdas. See https://groups.google.com/forum/#!msg/haskell-cafe/gDwF__-HMXE/oCKCbco2bS8J | I asked McCarthy was the use of the LAMBDA notation in Lisp because the | language was functional, or was it just a convenient notation for anonymous | functions? His answer was short and very definitive: he said it was a | convenient notation --- *he didn't consider Lisp to be a functional language.* -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
> > No, Common LISP does, but as the website says Common LISP is a > > "multi-paradigm" langauge. It's trying to be everything to everybody, > > just like Python tried to do in the other direction, making "everything an > > object". Python was trying to be too pure, while LISP was trying to be > > too universal: be everything to everyone -- you might say "batteries > > included". > > > > True LISP [...] > > Ah, the "No True Scotsman" fallacy. You know that Lisp compiler you're > using? That's not *true* Lisp, because *true* Lisp doesn't have [insert > feature here]. While schools use the term "variable" and there are letters like x, y, z. These should not be considered variables in any sense that you know. They (generally) are not assigned to. They are placeholders holding state. They don't change once the program starts running. > > Again, you're speaking of "Common LISP". Such a lisp also wants to do > > OOP, but it's like lipstick on a pig. > > You really love that metaphor, don't you? You keep using it, and variations > like "a pig made of lipstick". I suggest you don't understand the metaphor. My apologies. I thought better after I posted the message. It's more like putting lipstick on a *boy*. LISP, indeed, is not a pig. > > Yes, and LISP is neither. Although LISP is a functional style, that is > > only by appearance. It's completely different from Haskell, which I would > > describe as a true functional language. The difference is how the program > > is lexed in the mind or on the machine. But that's too difficult to > > explain on this thread. > > Just because something is difficult to explain doesn't make it correct. It's > difficult to explain how the Atlantic Ocean merely looks, tastes and feels > like salt water while actually being filled with strawberry yoghurt. That > doesn't make it true. > > Something which is difficult to explain might be deeply profound, but is far > more likely to be rubbish. That's all fine and good, Steven. But the academically and politically correct thing to do in that case, is withhold judgement. Perhaps you don't know what to do with yourself if I'm right, so your remaining recourse is to defences rather than inquiry. > > The "opposite" of iterative programming is recursive programming. > > No it isn't. Iteration and recursion are, in a very deep sense, actually the > same thing, they're certainly not opposites. That is a fact which genuinely > is profound. My God, you and Lawrence have gone off the deep end. What you're telling me is that you've never programmed something on digital hardware. That, fucking C, you've never even counted on your FINGERS!! > >> > And the idea of lambdas were already encoded by the use of special > >> > expressions, set-off by parenthesis. So they practically *defined* the > >> > concept of lambdas. > >> > >> LISP is also the reason why we're cursed with the terrible name > >> "lambda" for anonymous functions rather than something more mnemonic > >> (like "function"). > > > > No, you haven't understood, padawan. Lambda *is* the function, not it's > > definition. Perhaps you will understand what I mean by that, perhaps you > > won't. It's subtle. > > Subtle like a kick to the head. Well, at least you got the kick. It's only be understanding your error, can you then proceed to a greater truth. More concretely, programming in an iterative language is like programming f(x, y, z...), where f is the idea your wanting to implement and x,y,z are inputs. Since the are input by user interaction, they are VARIABLE. A type of interactive program (not a Turing tape, either I might add). A program in LISP is simply f, or more to their nomemclature: lambda. It's like the difference of saying f(x) = x + 1, or saying f = /x.x+1 (where "/" is the Greek lambda character). Do you see the subtle difference? They both appear to have variables, but they are not the same. To repeat myself from two years ago: Here endeth the lesson. You may be seated. > If you wish to change our minds, you're going to have to demonstrate > objective, verifiable facts and not just allude to how your ideas are too > subtle and clever for us. Hopefully that helps. But if I thought my ideas were too subtle or clever for you I wouldn't keep responding to you. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On 14/05/2015 02:40, Steven D'Aprano wrote: On Thu, 14 May 2015 04:07 am, zipher wrote: No, you haven't understood, padawan. Lambda *is* the function, not it's definition. Perhaps you will understand what I mean by that, perhaps you won't. It's subtle. Subtle like a kick to the head. Mark, you seem to be labouring under the delusion that we don't agree with you because we "boneheads" don't understand what you are talking about. That's wrong. We understand what you are talking about. We don't agree with you because half of your thesis is wrong and the other half is not even wrong. If you wish to change our minds, you're going to have to demonstrate objective, verifiable facts and not just allude to how your ideas are too subtle and clever for us. From the very first drivel that he posted on python ideas just over two years ago, he's shown that he's incapable of any logical thought relating to computing, in just the same way that the RUE has never posted anything logical about the FSR. Please can we stop feeding him. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Thu, 14 May 2015 04:07 am, zipher wrote: > On Wednesday, May 13, 2015 at 10:27:23 AM UTC-5, Ian wrote: >> I don't know why I'm replying to this... > > Because you're trying to get an answer to a question that even Academia > hasn't answered or understood. > >> On Wed, May 13, 2015 at 8:44 AM, zipher >> wrote: >> > On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote: >> >> How history U-turns!! >> >> Lisp actually got every major/fundamental thing wrong >> >> - variables scopes were dynamic by mistake >> >> - lambdas were non-first class because the locution 'first-class' was >> >> still 8 years in the future >> > >> > I think you're confused. LISP doesn't have variables. >> >> Yes, it does. > > No, Common LISP does, but as the website says Common LISP is a > "multi-paradigm" langauge. It's trying to be everything to everybody, > just like Python tried to do in the other direction, making "everything an > object". Python was trying to be too pure, while LISP was trying to be > too universal: be everything to everyone -- you might say "batteries > included". > > True LISP [...] Ah, the "No True Scotsman" fallacy. You know that Lisp compiler you're using? That's not *true* Lisp, because *true* Lisp doesn't have [insert feature here]. If you really want to justify your claim that Lisp has no variables, you can start by answering two questions: (1) What is the definition of "variable" you are using? (2) What *objective* methods of distinguishing a "True" Lisp from an false/fake/faux/counterfit Lisp are there? > It's only abstractions, like math. It's purpose is to output a final > result, that is all. It's not at all to make commercial applications. Your suggestion that the people and companies that created Lisp machines weren't interested in commercial applications for Lisp is very naive. [...] > Again, you're speaking of "Common LISP". Such a lisp also wants to do > OOP, but it's like lipstick on a pig. You really love that metaphor, don't you? You keep using it, and variations like "a pig made of lipstick". I suggest you don't understand the metaphor. "Lipstick on a pig" is not a metaphor for combining two things which are unrelated, or that shouldn't go together. It is a metaphor for the impossibility of turning something of low value (a pig) into high value just by applying a few cosmetic changes. "Lipstick on a pig" would describe giving a wax and polish to a lemon of a car. It might be all shiny and clean, but it still won't go. It might describe putting a coarse, rough, uncultured thug in a suit and tie, or putting a weak and under-powered text editor like Windows Notepad in a fancy GUI -- it's still weak and underpowered, Aero interface or not. So by your metaphor, Lisp is the pig (i.e. a useless, weak, unpleasant and disagreeable programming language) and OOP is a mere cosmetic change that doesn't change the fact that Lisp is useless and unpleasant. Is that the message you want to give? >> > with an entirely different model computation than other programming >> > languages which use variables all the time. To the extent that it DOES >> > have variables, it's to accommodate those coming over from iterative >> > programming. >> >> What is "iterative programming"? If you mean "writing programs that >> work iteratively", then this describes both functional and procedural >> styles alike. > > Yes, and LISP is neither. Although LISP is a functional style, that is > only by appearance. It's completely different from Haskell, which I would > describe as a true functional language. The difference is how the program > is lexed in the mind or on the machine. But that's too difficult to > explain on this thread. Just because something is difficult to explain doesn't make it correct. It's difficult to explain how the Atlantic Ocean merely looks, tastes and feels like salt water while actually being filled with strawberry yoghurt. That doesn't make it true. Something which is difficult to explain might be deeply profound, but is far more likely to be rubbish. Saying that Lisp isn't actually functional but merely is so "only by appearance" is as profound as saying that the Atlantic isn't filled with water, it only appears to be filled with water. >> The opposite of "iterative programming" would then be a style where >> the program can't ever repeat anything. That would be a very limited >> language and would *not* be equivalent to a Turing machine. > > > The "opposite" of iterative programming is recursive programming. No it isn't. Iteration and recursion are, in a very deep sense, actually the same thing, they're certainly not opposites. That is a fact which genuinely is profound. > It's > not limited, except that it has an entirely different relationship to > data, one orthogonal to iterative computation. That's *not even wrong*. >> > And the idea of lambdas were already encoded by the use of special >> > expressions, set-off by parenthesis. So the
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wednesday, May 13, 2015 at 4:39:52 PM UTC-5, Ian wrote: > On Wed, May 13, 2015 at 12:07 PM, zipher wrote: > > On Wednesday, May 13, 2015 at 10:27:23 AM UTC-5, Ian wrote: > >> I don't know why I'm replying to this... > > > > Because you're trying to get an answer to a question that even Academia > > hasn't answered or understood. > > > >> On Wed, May 13, 2015 at 8:44 AM, zipher wrote: > >> > On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote: > >> >> How history U-turns!! > >> >> Lisp actually got every major/fundamental thing wrong > >> >> - variables scopes were dynamic by mistake > >> >> - lambdas were non-first class because the locution 'first-class' was > >> >> still 8 > >> >> years in the future > >> > > >> > I think you're confused. LISP doesn't have variables. > >> > >> Yes, it does. > > > > No, Common LISP does, but as the website says Common LISP is a > > "multi-paradigm" langauge. It's trying to be everything to everybody, > > just like Python tried to do in the other direction, making "everything an > > object". Python was trying to be too pure, while LISP was trying to be too > > universal: be everything to everyone -- you might say "batteries included". > > > > True LISP, doesn't need a 'let' statement for example. To understand true > > LISP you have to understand the modus operandi of the "lambda the ultimate" > > crowd. Very few do from academic computer science. MIT understands it. > > You think you understand it, but you don't. > > By "true LISP" are you referring to the original specification by John > McCarthy? Here's an example lambda S-expression from McCarthy's > original paper: > > (LABEL, SUBST, (LAMBDA, (X, Y, Z), (COND ((ATOM, Z), (COND, (EQ, Y, > Z), X), ((QUOTE, T), Z))), ((QUOTE, T), (CONS, (SUBST, X, Y, (CAR Z)), > (SUBST, X, Y, (CDR, Z))) > > Ugh, what a mess. But ignoring that, tell us how many variables you > see there. I'll give you a hint: I count more than two. LoL, it's an interesting example you've thrown up there. It's more than just a mess though. The problem is the use of the quote. I was hoping you wouldn't include it. The problem is that its a compromise to interact with your mental-visual lexer. It's like Javascript which runs on no virtual machine anyone's heard of. It's too magical. > Sure. Lisp machines never, ever ran computer graphics applications. Or > medical image processing. Nope, never, because that would be > commercial and dirty and a hideous perversion of the idol of computer > science created by the prophet McCarthy. Text editors? Heavens to > Betsy, now you're just trying to shock me, aren't you! CLISP =/= LISP. > > Yes, and LISP is neither. Although LISP is a functional style, that is > > only by appearance. It's completely different from Haskell, which I would > > describe as a true functional language. The difference is how the program > > is lexed in the mind or on the machine. But that's too difficult to > > explain on this thread. > > And Fermat had a truly marvelous proof, which you would think > wonderful, if only he had enough room in that infamous margin. Ha, you know, I actually think I found the proof he alleges. You have to visualize the problem geometrically. > Iteration is a type of recursion. Specifically, it's the type of > recursion that doesn't require keeping a stack of values from each > higher-up repetition in the evaluation. > Also known as "linear > recursion" or "tail recursion". You are so confused, it boggles. Can anyone else assert this? Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On 13/05/2015 22:38, Ian Kelly wrote: On Wed, May 13, 2015 at 12:07 PM, zipher wrote: Yes, and LISP is neither. Although LISP is a functional style, that is only by appearance. It's completely different from Haskell, which I would describe as a true functional language. The difference is how the program is lexed in the mind or on the machine. But that's too difficult to explain on this thread. And Fermat had a truly marvelous proof, which you would think wonderful, if only he had enough room in that infamous margin. The RUE also has a marvellous proof that the PEP 393 FSR is complete nonsense, but as it's so obvious to himself he's decided its not worth sharing with anybody else. What with that and this thread I therefore conclude that both the RUE and zipher suffer from a very severe case of Emperor's New Clothes Syndrome. No, you haven't understood, padawan. *plonk* You took your time over that :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wed, May 13, 2015 at 12:07 PM, zipher wrote: > On Wednesday, May 13, 2015 at 10:27:23 AM UTC-5, Ian wrote: >> I don't know why I'm replying to this... > > Because you're trying to get an answer to a question that even Academia > hasn't answered or understood. > >> On Wed, May 13, 2015 at 8:44 AM, zipher wrote: >> > On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote: >> >> How history U-turns!! >> >> Lisp actually got every major/fundamental thing wrong >> >> - variables scopes were dynamic by mistake >> >> - lambdas were non-first class because the locution 'first-class' was >> >> still 8 >> >> years in the future >> > >> > I think you're confused. LISP doesn't have variables. >> >> Yes, it does. > > No, Common LISP does, but as the website says Common LISP is a > "multi-paradigm" langauge. It's trying to be everything to everybody, just > like Python tried to do in the other direction, making "everything an > object". Python was trying to be too pure, while LISP was trying to be too > universal: be everything to everyone -- you might say "batteries included". > > True LISP, doesn't need a 'let' statement for example. To understand true > LISP you have to understand the modus operandi of the "lambda the ultimate" > crowd. Very few do from academic computer science. MIT understands it. You > think you understand it, but you don't. By "true LISP" are you referring to the original specification by John McCarthy? Here's an example lambda S-expression from McCarthy's original paper: (LABEL, SUBST, (LAMBDA, (X, Y, Z), (COND ((ATOM, Z), (COND, (EQ, Y, Z), X), ((QUOTE, T), Z))), ((QUOTE, T), (CONS, (SUBST, X, Y, (CAR Z)), (SUBST, X, Y, (CDR, Z))) Ugh, what a mess. But ignoring that, tell us how many variables you see there. I'll give you a hint: I count more than two. > It's only abstractions, like math. It's purpose is to output a final result, > that is all. It's not at all to make commercial applications. It's rather > like Asimov's computer in the Last Question. It's a whole different model of > computation. Instead of a Turing Tape or VonNeumann stream, you have > hierarchies of expressions all evaluating... > > ...well I would say all at the same time, but since I have to constrain my > description to a common set of reality that is shared with you, then I'd say > "on the stack frame". It's why they had specialized machines to run true > LISP. Sure. Lisp machines never, ever ran computer graphics applications. Or medical image processing. Nope, never, because that would be commercial and dirty and a hideous perversion of the idol of computer science created by the prophet McCarthy. Text editors? Heavens to Betsy, now you're just trying to shock me, aren't you! >> > with an entirely different model computation than other programming >> > languages which use variables all the time. To the extent that it DOES >> > have variables, it's to accommodate those coming over from iterative >> > programming. >> >> What is "iterative programming"? If you mean "writing programs that >> work iteratively", then this describes both functional and procedural >> styles alike. > > Yes, and LISP is neither. Although LISP is a functional style, that is only > by appearance. It's completely different from Haskell, which I would > describe as a true functional language. The difference is how the program is > lexed in the mind or on the machine. But that's too difficult to explain on > this thread. And Fermat had a truly marvelous proof, which you would think wonderful, if only he had enough room in that infamous margin. >> The opposite of "iterative programming" would then be a style where >> the program can't ever repeat anything. That would be a very limited >> language and would *not* be equivalent to a Turing machine. > > > The "opposite" of iterative programming is recursive programming. It's not > limited, except that it has an entirely different relationship to data, one > orthogonal to iterative computation. Iteration is a type of recursion. Specifically, it's the type of recursion that doesn't require keeping a stack of values from each higher-up repetition in the evaluation. Also known as "linear recursion" or "tail recursion". Often people use the word "iteration" to mean a syntactic construct that repeats itself without explicit reference to a function and "recursion" to mean a syntactic construct where a function explicitly repeats itself, but from a theoretical standpoint this is all just syntax. The two constructs are fundamentally the same. > >> > And the idea of lambdas were already encoded by the use of special >> > expressions, set-off by parenthesis. So they practically *defined* the >> > concept of lambdas. >> >> LISP is also the reason why we're cursed with the terrible name >> "lambda" for anonymous functions rather than something more mnemonic >> (like "function"). > > No, you haven't understood, padawan. *plonk* -- https://
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
Ian Kelly : > LISP is also the reason why we're cursed with the terrible name > "lambda" for anonymous functions rather than something more mnemonic > (like "function"). The only terrible aspect of "lambda" is how difficult it is to type. BTW, Common Lisp actually has an operator called "function": http://www.lispworks.com/documentation/HyperSpec/Body/s_fn.htm>. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wednesday, May 13, 2015 at 10:27:23 AM UTC-5, Ian wrote: > I don't know why I'm replying to this... Because you're trying to get an answer to a question that even Academia hasn't answered or understood. > On Wed, May 13, 2015 at 8:44 AM, zipher wrote: > > On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote: > >> How history U-turns!! > >> Lisp actually got every major/fundamental thing wrong > >> - variables scopes were dynamic by mistake > >> - lambdas were non-first class because the locution 'first-class' was > >> still 8 > >> years in the future > > > > I think you're confused. LISP doesn't have variables. > > Yes, it does. No, Common LISP does, but as the website says Common LISP is a "multi-paradigm" langauge. It's trying to be everything to everybody, just like Python tried to do in the other direction, making "everything an object". Python was trying to be too pure, while LISP was trying to be too universal: be everything to everyone -- you might say "batteries included". True LISP, doesn't need a 'let' statement for example. To understand true LISP you have to understand the modus operandi of the "lambda the ultimate" crowd. Very few do from academic computer science. MIT understands it. You think you understand it, but you don't. It's only abstractions, like math. It's purpose is to output a final result, that is all. It's not at all to make commercial applications. It's rather like Asimov's computer in the Last Question. It's a whole different model of computation. Instead of a Turing Tape or VonNeumann stream, you have hierarchies of expressions all evaluating... ...well I would say all at the same time, but since I have to constrain my description to a common set of reality that is shared with you, then I'd say "on the stack frame". It's why they had specialized machines to run true LISP. > > It's a lambda calculus > > No, it isn't. Lambda calculus is a formal system of mathematics. LISP > is a programming language. It may draw inspiration and borrow notation > from lambda calculus, but these are different things with different > uses and purposes. Again, you're speaking of "Common LISP". Such a lisp also wants to do OOP, but it's like lipstick on a pig. > > with an entirely different model computation than other programming > > languages which use variables all the time. To the extent that it DOES > > have variables, it's to accommodate those coming over from iterative > > programming. > > What is "iterative programming"? If you mean "writing programs that > work iteratively", then this describes both functional and procedural > styles alike. Yes, and LISP is neither. Although LISP is a functional style, that is only by appearance. It's completely different from Haskell, which I would describe as a true functional language. The difference is how the program is lexed in the mind or on the machine. But that's too difficult to explain on this thread. > The opposite of "iterative programming" would then be a style where > the program can't ever repeat anything. That would be a very limited > language and would *not* be equivalent to a Turing machine. The "opposite" of iterative programming is recursive programming. It's not limited, except that it has an entirely different relationship to data, one orthogonal to iterative computation. > > And the idea of lambdas were already encoded by the use of special > > expressions, set-off by parenthesis. So they practically *defined* the > > concept of lambdas. > > LISP is also the reason why we're cursed with the terrible name > "lambda" for anonymous functions rather than something more mnemonic > (like "function"). No, you haven't understood, padawan. Lambda *is* the function, not it's definition. Perhaps you will understand what I mean by that, perhaps you won't. It's subtle. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On 2015-05-12, Marko Rauhamaa wrote: > zipher : > >> That is why you have very high-level languages that allow you to >> rapidly prototype ideas, test them, and then, depending all the other >> constraints, move them to lower-level language implementations. > > Finally an argument to tackle. That rapid prototyping role is often > mentioned as a strong point of high-level languages. However, I can't > remember personally doing that. I've done that on several occasions: develop and debug an algorithm or protocol using Python, then re-write it in C once I'm happy with the way it works. Those instances are not for desktop use, though. They final app has to run on an embedded system that has zero chance of ever supporting Python. -- Grant Edwards grant.b.edwardsYow! YOU PICKED KARL at MALDEN'S NOSE!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
I don't know why I'm replying to this... On Wed, May 13, 2015 at 8:44 AM, zipher wrote: > On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote: >> How history U-turns!! >> Lisp actually got every major/fundamental thing wrong >> - variables scopes were dynamic by mistake >> - lambdas were non-first class because the locution 'first-class' was still 8 >> years in the future > > I think you're confused. LISP doesn't have variables. Yes, it does. > It's a lambda calculus No, it isn't. Lambda calculus is a formal system of mathematics. LISP is a programming language. It may draw inspiration and borrow notation from lambda calculus, but these are different things with different uses and purposes. > with an entirely different model computation than other programming languages > which use variables all the time. To the extent that it DOES have variables, > it's to accomidate those coming over from iterative programming. What is "iterative programming"? If you mean "writing programs that work iteratively", then this describes both functional and procedural styles alike. The opposite of "iterative programming" would then be a style where the program can't ever repeat anything. That would be a very limited language and would *not* be equivalent to a Turing machine. > And the idea of lambdas were already encoded by the use of special > expressions, set-off by parenthesis. So they practically *defined* the > concept of lambdas. LISP is also the reason why we're cursed with the terrible name "lambda" for anonymous functions rather than something more mnemonic (like "function"). -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 10:47:48 PM UTC-5, Ian wrote: > On Tue, May 12, 2015 at 9:11 PM, zipher wrote: > > I know. That's because most people have fallen off the path > > (http://c2.com/cgi/wiki?OneTruePath). > > You wrote that, didn't you? I recognize that combination of delusional > narcissism and curious obsession with Turing machines. Damn straight. But to call the reference to Turing machines delusional, means you've already been captured by the first enemy on the Path. (cf. Javascript!) > > You haven't done it because either others have done it for you (NumPy) or > > you simply aren't perfecting anything that needs to scale; i.e. you don't > > really need to minimize memory or CPU consumption because you're working > > with toy problems relative to the power of most hardware these days. > > There is such a thing as over-optimization. Given unlimited programmer > time, sure, everything might be made to run using the minimum possible > time and space. You don't need to teach me these basics. If you had read the document, you would have seen that I already had assimilated the lessons of [Master] Jon Bentley. I know about over-optimization, however, if you had followed my other posts, you would also know that I'm attempting something that will require some interest in the underlying hardware at some point. Or, perhaps let's say, it's just my personal (unique?) preference not to create bloatware. mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote: > On Wednesday, May 13, 2015 at 8:00:50 AM UTC+5:30, Steven D'Aprano wrote: > > Why can't a language be designed with a *practical and concrete* need in > > mind? As far as I know, only one language designed from theoretical first > > principles has had any measure of mainstream success, Lisp, and that was > > probably because there weren't that many decent alternatives at the time. > > How history U-turns!! > Lisp actually got every major/fundamental thing wrong > - variables scopes were dynamic by mistake > - lambdas were non-first class because the locution 'first-class' was still 8 > years in the future I think you're confused. LISP doesn't have variables. It's a lambda calculus with an entirely different model computation than other programming languages which use variables all the time. To the extent that it DOES have variables, it's to accomidate those coming over from iterative programming. And the idea of lambdas were already encoded by the use of special expressions, set-off by parenthesis. So they practically *defined* the concept of lambdas. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
Steven D'Aprano wrote: "I want to do numerical calculations" lead to Fortran. "I want to control telescopes" lead to Forth. I don't think those things led to their respective languages in the same way. The notation that mathematicians use for numerical calculations had a clear influence on the syntax of Fortran. But there's nothing about controlling telescopes that makes the structure of Forth particularly suited to it. I think there *is* a design principle behind Forth: the desire to keep everything as simple as possible. It's a lot like Lisp in that respect. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wednesday, May 13, 2015 at 9:17:48 AM UTC+5:30, Ian wrote: > On Tue, May 12, 2015 at 9:11 PM, zipher wrote: > > I know. That's because most people have fallen off the path > > (http://c2.com/cgi/wiki?OneTruePath). > > You wrote that, didn't you? I recognize that combination of delusional > narcissism and curious obsession with Turing machines. Interestingly saw this (CACM) the other day: http://www.tomandmaria.com/Tom/Writing/CACMActuallyTuringDidNotInventTheComputer.pdf non-delusional and in the opposite direction: Turing's is a paper on mathematical logic. It describes a thought experiment, like Schrödinger's famous 1935 description of a trapped cat shifting between life and death in response to the behavior of a single atom. Schrödinger was not trying to advance the state of the art of feline euthanasia. Neither was Turing proposing the construction of a new kind of calculating machine. As the title of his paper suggested, Turing designed his ingenious imaginary machines to address a question about the fundamental limits of mathematical proof. They were structured for simplicity, and had little in common with the approaches taken by people designing actual machines. Von Neumann's report said nothing explicitly about mathematical logic. It described the architecture of an actual planned computer and the technologies by which it could be realized, and was written to guide the team that had already won a contract to develop the EDVAC. Von Neumann does abstract away from details of the hardware, both to focus instead on what we would now call "architecture" and because the computer projects under way at the Moore School were still classified in 1945. His letters from that period are full of discussion of engineering details, such as sketches of particular vacuum tube models and their performance characteristic -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wednesday, May 13, 2015 at 11:47:19 AM UTC+5:30, Chris Angelico wrote: > On Wed, May 13, 2015 at 3:56 PM, Rustom Mody wrote: > >> Yep. I'd also use clear function/procedure names to make it more > >> visible, and probably tie this in with loops to show how you can print > >> more than one thing but can only return one. (Generators are a more > >> advanced topic.) > > > > [Structure of] Library function: basic > > Generator: advanced > > > > ?¿?¿ > > > > If you ask me that's sdrawkcab > > You think that generators are less advanced than the notion of code reuse?? > Notion of code reuse -- easy Writing reusable code -- hard Certainly much harder than writing working useful generators. Do remember that historical and pedagogical order dont necessarily match. A C programmer would say integers (scalars) are easy, lists are hard. Not a notion necessary or useful in python Let's just close this (for now) Chris with this: You are in all likelihood a better programmer than I. It so happens I have directly or indirectly taught near to 2000 students in about 25 years. Lets reopen this conversation when you reach ⅓ that number, ok? -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wed, May 13, 2015 at 3:56 PM, Rustom Mody wrote: >> Yep. I'd also use clear function/procedure names to make it more >> visible, and probably tie this in with loops to show how you can print >> more than one thing but can only return one. (Generators are a more >> advanced topic.) > > [Structure of] Library function: basic > Generator: advanced > > ?¿?¿ > > If you ask me that's sdrawkcab You think that generators are less advanced than the notion of code reuse?? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wednesday, May 13, 2015 at 10:25:18 AM UTC+5:30, Chris Angelico wrote: > On Wed, May 13, 2015 at 11:14 AM, Steven D'Aprano wrote: > > On Wed, 13 May 2015 02:05 am, Chris Angelico wrote: > > > >> So if you're writing a library function, it probably shouldn't use > >> print()... but your application is most welcome to. You usually know > >> which one you're writing at any given time. > > > > You might be, but beginners are not. > > I meant the generic "you" there. A beginner may well not know whether > to use / or //, whether it's better to use a list or a dict, etc etc > etc. That's what instructors are for. Make the distinction that > library functions shouldn't use print but application code can, and > then examples like this... > > > I'm not sure I accept Rustom's fix for the problem (I think that his cure is > > worse than the disease), but it is *hard* to get some beginners to use > > return instead of print: > > > > def add_twice(x, y): > > """Add twice y to x.""" > > print x + 2*y > > > > > > sort of thing. > > ... can be answered simply by explaining that "add_twice" ought to be > written as a library function rather than an application. It's the > exact same answer as this: And later > Yep. I'd also use clear function/procedure names to make it more > visible, and probably tie this in with loops to show how you can print > more than one thing but can only return one. (Generators are a more > advanced topic.) [Structure of] Library function: basic Generator: advanced ?¿?¿ If you ask me that's sdrawkcab -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wed, May 13, 2015 at 11:14 AM, Steven D'Aprano wrote: > On Wed, 13 May 2015 02:05 am, Chris Angelico wrote: > >> So if you're writing a library function, it probably shouldn't use >> print()... but your application is most welcome to. You usually know >> which one you're writing at any given time. > > You might be, but beginners are not. I meant the generic "you" there. A beginner may well not know whether to use / or //, whether it's better to use a list or a dict, etc etc etc. That's what instructors are for. Make the distinction that library functions shouldn't use print but application code can, and then examples like this... > I'm not sure I accept Rustom's fix for the problem (I think that his cure is > worse than the disease), but it is *hard* to get some beginners to use > return instead of print: > > def add_twice(x, y): > """Add twice y to x.""" > print x + 2*y > > > sort of thing. ... can be answered simply by explaining that "add_twice" ought to be written as a library function rather than an application. It's the exact same answer as this: def find_all_whatevers(base_dir): whatevers = [] os.chdir(base_dir) for fn in os.listdir(): if fn is a whatever: whatevers.append(fn) if fn is a directory: whatevers.extend(find_all_whatevers(fn)) return whatevers The working directory belongs to the application, not to a library function, so this shouldn't use os.chdir(), even though it does spare you the effort of string manipulation. (Of course, a real-world version of this should use os.walk(), but that's a complete rewrite.) The precise boundary between reusable functions and the actual application isn't always easy to draw, and there'll be times when you refactor something across that line. That's not a problem. There are still plenty of cases that are clear enough to use for explanation. > Personally, I think that banning print is only useful if you wish to > encourage cargo-cult programming: > > "Don't use print!" > "Why not?" > "My CS lecture said not to use it! I dunno, maybe it has a virus or > something." Agreed. There are VERY few features which should be utterly and totally banned, and they're usually kept only for backward compatibility with a time when people didn't know how dangerous they were. In Python, the only one I can think of is Py2's input(), which should be treated as XKCD 292 treats GOTO. (If you really *do* want to take a string from the user and immediately eval it, just write it as "eval(raw_input())" so everyone knows.) C has gets(), which is similarly dangerous and has a similarly straight-forward replacement. PHP has register_globals (or did until recently - it took a long time to go from "default is on, we recommend you turn it off" through "default is off, we recommend you don't turn it on" to finally "bad feature is removed"). Beyond those, there's not much that doesn't have at least _some_ reason for existing. > I'd rather give them exercises designed to show (rather than tell) the > differences between printing a result and returning a result, and how they > effect re-usability of software components and function chaining. Using a > procedural language is *perfect* for that, since you can highlight the > differences: > > function foo(n:int): int; > begin > foo := n+1; > end; > > procedure foo(n:int); > begin > writeln(n+1); > end; Yep. I'd also use clear function/procedure names to make it more visible, and probably tie this in with loops to show how you can print more than one thing but can only return one. (Generators are a more advanced topic.) A few examples go a long way. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tue, May 12, 2015 at 9:11 PM, zipher wrote: > I know. That's because most people have fallen off the path > (http://c2.com/cgi/wiki?OneTruePath). You wrote that, didn't you? I recognize that combination of delusional narcissism and curious obsession with Turing machines. > You haven't done it because either others have done it for you (NumPy) or you > simply aren't perfecting anything that needs to scale; i.e. you don't really > need to minimize memory or CPU consumption because you're working with toy > problems relative to the power of most hardware these days. There is such a thing as over-optimization. Given unlimited programmer time, sure, everything might be made to run using the minimum possible time and space. Nobody has unlimited time, though. The job of the programmer is to get the program to run "fast enough" for the needs of the application. Getting it to run faster than it needs to is generally a waste of the programmer's time that could be spent on more valuable tasks. Of course, I say this as somebody who works on a highly scaled user-facing application that will never be "fast enough". :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wednesday, May 13, 2015 at 8:00:50 AM UTC+5:30, Steven D'Aprano wrote: > Why can't a language be designed with a *practical and concrete* need in > mind? As far as I know, only one language designed from theoretical first > principles has had any measure of mainstream success, Lisp, and that was > probably because there weren't that many decent alternatives at the time. How history U-turns!! Lisp actually got every major/fundamental thing wrong - variables scopes were dynamic by mistake - lambdas were non-first class because the locution 'first-class' was still 8 years in the future And what it got right was more by fluke than by design - gc because the machine word was too small for a refcount but could squeeze in a mark-bit - Syntax: It was intended that a 'proper' (aka Algol-like) syntax was round the corner. The '1.5' in the lisp 1.5 manual was evidence of that interimness To me the most mind-boggling aspect this u-turning of history is this interview with McCarthy: http://www.infoq.com/interviews/Steele-Interviews-John-McCarthy Q: Who helped you with the early ideas Lisp? McCarthy: Backus' Fortran taught me functional programming! -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 9:30:50 PM UTC-5, Steven D'Aprano wrote: > On Wed, 13 May 2015 08:00 am, zipher wrote: > > > Everyone gets it wrong and now we have a plethora of languages which all > > do the same thing, without really knowing what they want as an overarching > > design or purpose. > > > Why must a language be designed with some "overarching design or purpose"? Because it's considerable work. Why re-invent the wheel? After all, there are plenty of Turing-complete languages out there. No, you make one because you have an implicit or explicit goal. > Why can't a language be designed with a *practical and concrete* need in > mind? As far as I know, only one language designed from theoretical first > principles has had any measure of mainstream success, Lisp, Yes, and that was a stellar achievement. Many language makers still compare to such a gold standard. Even Python. Yet it has also misled us -- it is based on a fundamentally different model of computation. An elegant model of computation, that many high-level languages seem to try to adopt, yet they fail because they can't re-produce the elegance without becoming LISP. So why, then, are there other programming languages that specifically try NOT to be LISP? Because the model of computation for most hardware is iterative. This is also why the design goal of "everything should be an object" needs to be revisited. It doesn't align with any model of computation. That's fine for small problems, but when you're trying to make a p2p data model that can scale to the Internet, it becomes an issue. > "I want to do numerical calculations" lead to Fortran. > > "I want to control telescopes" lead to Forth. > > "I want to teach beginners programming" lead to BASIC. You can stop there. You are proving my point, that there are goals to a given programming language. If those goals are strong or noble enough, it differentiates from existing languages. "I want to do numerical calculations" led to Fortran, which led to C because people wanted to do such calculations on many platforms. And C syntax had the more elegant syntax ultimately (I think the increment++ operator ultimately ran Fortran over, because it was directly implementable on CPU architectures in 1 clock cycle). "I want to control telescopes" could morph into the more general goal of "I want to make a controller programming language" and Boom, you'd have an elegant programming language for all controllers. "I want to teach beginners programming" started at BASIC, but then led to Pascal as the limitations of BASIC became clear, but then became Python. These are all decent design goals for a language. Python has superceded BASIC in almost every way. Anyway, having a design goal guides the process and helps everyone who wants to contribute know how to do so. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 5:24:34 PM UTC-5, Marko Rauhamaa wrote: > zipher : > > > That is why you have very high-level languages that allow you to > > rapidly prototype ideas, test them, and then, depending all the other > > constraints, move them to lower-level language implementations. > > Finally an argument to tackle. That rapid prototyping role is often > mentioned as a strong point of high-level languages. However, I can't > remember personally doing that. Rather, you want to use the right > programming language for any given role. I know. That's because most people have fallen off the path (http://c2.com/cgi/wiki?OneTruePath). You haven't done it because either others have done it for you (NumPy) or you simply aren't perfecting anything that needs to scale; i.e. you don't really need to minimize memory or CPU consumption because you're working with toy problems relative to the power of most hardware these days. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 1:22:55 PM UTC-5, Mark Lawrence wrote: > On 12/05/2015 18:35, Rustom Mody wrote: > > On Tuesday, May 12, 2015 at 8:48:13 PM UTC+5:30, zipher wrote: > >> > >> I/O is an essential part of computing in the West. (I'll leave Symbolics > >> out of of that category.) It started with switches and lights, so what > >> kind of bullshit is saying that you should get rid of PRINT? ACM must > >> have gotten confused or steamrolled by one of its members. > > > > In the West? WEST?? > > Did I hear that right? > > > > I prefer this[1] > [1]https://mail.python.org/pipermail/python-ideas/2013-March/019979.html > Mark Lawrence I was trying to differentiate models of computing. Perhaps you don't know the concept. I'll refer you to http://c2.com/cgi/wiki?ModelsOfComputation. One might think that they ALL originated from Western Civ, but not quite. Yes, I was sounding little too enthusiastic in that post. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 8:15:07 PM UTC-5, Steven D'Aprano wrote: > On Wed, 13 May 2015 02:05 am, Chris Angelico wrote: > > > So if you're writing a library function, it probably shouldn't use > > print()... but your application is most welcome to. You usually know > > which one you're writing at any given time. > > You might be, but beginners are not. > > I'm not sure I accept Rustom's fix for the problem (I think that his cure is > worse than the disease), but it is *hard* to get some beginners to use > return instead of print: > > def add_twice(x, y): > """Add twice y to x.""" > print x + 2*y > > > sort of thing. > > Personally, I think that banning print is only useful if you wish to > encourage cargo-cult programming: > > "Don't use print!" > "Why not?" > "My CS lecture said not to use it! I dunno, maybe it has a virus or > something." No, no, no. There's a very simple reason that you don't put extraneous I/O into your functions: you want your functions to be as general as possible for the given focus for re-usability. Otherwise, why write as a separate function? It's called separability of domains. See Hacking with the Tao: http://wiki.hackerspaces.org/Hacking_with_the_Tao. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
Steven D'Aprano writes: > As far as I know, only one language designed from theoretical first > principles has had any measure of mainstream success, Lisp, APL was cool back in the day too. -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wed, 13 May 2015 08:00 am, zipher wrote: > Everyone gets it wrong and now we have a plethora of languages which all > do the same thing, without really knowing what they want as an overarching > design or purpose. Why must a language be designed with some "overarching design or purpose"? Why can't a language be designed with a *practical and concrete* need in mind? As far as I know, only one language designed from theoretical first principles has had any measure of mainstream success, Lisp, and that was probably because there weren't that many decent alternatives at the time. "I want to do numerical calculations" lead to Fortran. "I want to control telescopes" lead to Forth. "I want to teach beginners programming" lead to BASIC. "I want to teach beginners good programming" lead to Pascal. "I want to generate webpages on the fly" lead to PHP. "I want to write interactive fiction and text-based games" lead to Inform. And so forth. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wednesday, May 13, 2015 at 6:45:07 AM UTC+5:30, Steven D'Aprano wrote: > On Wed, 13 May 2015 02:05 am, Chris Angelico wrote: > > > So if you're writing a library function, it probably shouldn't use > > print()... but your application is most welcome to. You usually know > > which one you're writing at any given time. > > You might be, but beginners are not. > > I'm not sure I accept Rustom's fix for the problem (I think that his cure is > worse than the disease), but it is *hard* to get some beginners to use > return instead of print: > > def add_twice(x, y): > """Add twice y to x.""" > print x + 2*y > > > sort of thing. > > Personally, I think that banning print is only useful if you wish to > encourage cargo-cult programming: > > "Don't use print!" > "Why not?" > "My CS lecture said not to use it! I dunno, maybe it has a virus or > something." :-) [And more real than you know --- every medicine has a side-effect] Just to be be clear about the framing -- though it does not work too well across Usenet -- I would suggest to TEACHERS to not use/show print TOO EARLY Something like cigarettes: You dont ban children from smoking. You ban adults from setting up tobacco shops near schools > procedural language is *perfect* for that, since you can highlight the > differences: > > function foo(n:int): int; > begin > foo := n+1; > end; > > procedure foo(n:int); > begin > writeln(n+1); > end; This cuts both ways Python much more than Pascal can make the 1st possible because of data structures in general being first class Unfortunately python culture across the net is laissez faire about using the 2nd -- I am demoing SMTP protocol... Does print or no print really have anything to do with it? When you give the procedure foo vs function foo example, you are jumping across the levels of familiarity and usage to assessment/evaluation. Shall I use an if or a while? Shall I use a list or a dict? Shall I use immutable + or mutable extend/append? : : And a dozen other more fundamental things to assess. If I could count the number of times a beginner hangs an else onto a while... Students dont 'Not get it' because they are asses but because they are at a firehose. The asses are the adults who stand by and keep turning on the pressure -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wed, 13 May 2015 02:05 am, Chris Angelico wrote: > So if you're writing a library function, it probably shouldn't use > print()... but your application is most welcome to. You usually know > which one you're writing at any given time. You might be, but beginners are not. I'm not sure I accept Rustom's fix for the problem (I think that his cure is worse than the disease), but it is *hard* to get some beginners to use return instead of print: def add_twice(x, y): """Add twice y to x.""" print x + 2*y sort of thing. Personally, I think that banning print is only useful if you wish to encourage cargo-cult programming: "Don't use print!" "Why not?" "My CS lecture said not to use it! I dunno, maybe it has a virus or something." I'd rather give them exercises designed to show (rather than tell) the differences between printing a result and returning a result, and how they effect re-usability of software components and function chaining. Using a procedural language is *perfect* for that, since you can highlight the differences: function foo(n:int): int; begin foo := n+1; end; procedure foo(n:int); begin writeln(n+1); end; -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
zipher : > That is why you have very high-level languages that allow you to > rapidly prototype ideas, test them, and then, depending all the other > constraints, move them to lower-level language implementations. Finally an argument to tackle. That rapid prototyping role is often mentioned as a strong point of high-level languages. However, I can't remember personally doing that. Rather, you want to use the right programming language for any given role. Bash has really concise idioms as long as you stay within its comfort zone. When you need finer-grained control, a bash program quickly becomes very tacky. I have had to rewrite bash components in Python for that reason. What is gained is clarity of expression at the cost of 2 to 5 times more code. And where performance is an issue, C does the job nicely. The end result is a system with bash, Python and C components that interact through the regular linux IPC mechanisms. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 12:57:48 PM UTC-5, Rustom Mody wrote: > On Tuesday, May 12, 2015 at 10:45:39 PM UTC+5:30, Stefan Ram wrote: > > Rob Gaddi writes: > > >Is that a true array or a linked list? "It's a high level language, > > >that's just an implementation detail." Yes, but it's an implementation > > >detail that determines whether even the simple act of looking up element > > >n is O(1) or O(n). > > > > The complexity is given in the documentation of high-level languages. > > > > For example, from the documentation of the Java standard library: > > > > »This implementation provides constant-time performance > > for the basic operations (get and put),« (java.util.HashMap) > > > > C++: > > > > Section 23.2.1 specifies the complexity, such as »compile time«, > > »constant«, »linear« for container operations. > > > > But the abstraction mechanisms (templates, polymorphism) > > often allow one to change the implementation quite easily. > > This is regarded in some circles as one of the big open problems in CS > https://existentialtype.wordpress.com/2014/09/28/structure-and-efficiency-of-computer-programs/ > [and the position paper therein] > viz how to integrate the elegance of high-level languages > with the precision of complexity analysis of machine language The answer is you don't. You *don't* because you can't. And you *can't* because you don't know what you want to do yet. That is why you have very high-level languages that allow you to rapidly prototype ideas, test them, and then, depending all the other constraints, move them to lower-level language implementations. So don't try it. Everyone gets it wrong and now we have a plethora of languages which all do the same thing, without really knowing what they want as an overarching design or purpose. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
Chris Angelico : > That's as may be, but I would still not recommend [C] as a first > language. I think the field can be approached from many angles successfully. And any approach will fail many students. The nice thing about C is that your feet are firmly on the ground. There's little magic. You can then abstract your concrete knowledge of C to higher-level concepts. In fact, going the other way could be harder. I'm thinking the lofty abstractions like objects will remain sort of mysteries without an experience with a low-level language. That's why first-graders are not given education in abstract algebra or category theory. They are first taught elementary arithmetics. The lofty concepts are abstracted from the low-level concepts and not the other way around. (I had a feeling in high-school that math was easy. In the university, I had the opposite experience: I hadn't understood a thing in high-school. However, the elementary "wrong" knowledge was a stepping stone to the "correct" understanding.) Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On 12/05/2015 18:35, Rustom Mody wrote: On Tuesday, May 12, 2015 at 8:48:13 PM UTC+5:30, zipher wrote: I/O is an essential part of computing in the West. (I'll leave Symbolics out of of that category.) It started with switches and lights, so what kind of bullshit is saying that you should get rid of PRINT? ACM must have gotten confused or steamrolled by one of its members. In the West? WEST?? Did I hear that right? I prefer this[1] Each object has to figure out how it will receive things from outside of it. Things it can't handle (a string sent to an int) just have to be dropped to some other space, much like stderr does within the O.S. There are probably many other very interesting examples, but the key idea I'm working on (as noted in other messages), is a sort-of universal language for the internet, a WebOS to be applied to a universal data model. I'd guess that the concept is in the same boat as Python 2.8 or RickedPython, but I suspect that these two have far more chance of making it into the real world than "a sort-of universal language for the internet, a WebOS to be applied to a universal data model" [1]https://mail.python.org/pipermail/python-ideas/2013-March/019979.html -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 10:45:39 PM UTC+5:30, Stefan Ram wrote: > Rob Gaddi writes: > >Is that a true array or a linked list? "It's a high level language, > >that's just an implementation detail." Yes, but it's an implementation > >detail that determines whether even the simple act of looking up element > >n is O(1) or O(n). > > The complexity is given in the documentation of high-level languages. > > For example, from the documentation of the Java standard library: > > »This implementation provides constant-time performance > for the basic operations (get and put),« (java.util.HashMap) > > C++: > > Section 23.2.1 specifies the complexity, such as »compile time«, > »constant«, »linear« for container operations. > > But the abstraction mechanisms (templates, polymorphism) > often allow one to change the implementation quite easily. This is regarded in some circles as one of the big open problems in CS https://existentialtype.wordpress.com/2014/09/28/structure-and-efficiency-of-computer-programs/ [and the position paper therein] viz how to integrate the elegance of high-level languages with the precision of complexity analysis of machine language -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 8:48:13 PM UTC+5:30, zipher wrote: > On Tuesday, May 12, 2015 at 4:16:31 AM UTC-5, Rustom Mody wrote: > > On Tuesday, May 12, 2015 at 12:27:44 PM UTC+5:30, Chris Angelico wrote: > > > On Tue, May 12, 2015 at 4:42 PM, Rustom Mody wrote: > > > > And related to that (and one reason a pure functional language is good > > > > for > > > > pedagogy): NO PRINT statement > > > > It may seem trivial but beginning students have a real hard writing > > > > clean > > > > structured code. Tabooing prints helps get there faster > > > > And working in the interpreter makes a print-taboo a viable option > > > > > > I firmly disagree. > > > > Yes we know that! > > > > As it happens you also disagree with ACM's latest CS curriculum: > > I/O is an essential part of computing in the West. (I'll leave Symbolics out > of of that category.) It started with switches and lights, so what kind of > bullshit is saying that you should get rid of PRINT? ACM must have gotten > confused or steamrolled by one of its members. In the West? WEST?? Did I hear that right? My profound genuflections to the Mark-modified Michaelson-Morley result. -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wed, May 13, 2015 at 3:15 AM, Stefan Ram wrote: > Rob Gaddi writes: >>Is that a true array or a linked list? "It's a high level language, >>that's just an implementation detail." Yes, but it's an implementation >>detail that determines whether even the simple act of looking up element >>n is O(1) or O(n). > > The complexity is given in the documentation of high-level languages. > > For example, from the documentation of the Java standard library: > > »This implementation provides constant-time performance > for the basic operations (get and put),« (java.util.HashMap) > > C++: > > Section 23.2.1 specifies the complexity, such as »compile time«, > »constant«, »linear« for container operations. > > But the abstraction mechanisms (templates, polymorphism) > often allow one to change the implementation quite easily. It isn't always given in the docs. Sometimes it's not even a promise; back when MicroPython was debating the implementation of Unicode strings, there was a lengthy discussion on python-dev about whether it's okay for string subscripting to be O(n) instead of O(1), and the final decision was that yes, that's an implementation detail. (UTF-8 internal string representation, so iterating over a string would still yield characters in overall O(n), but iterating up to the string's length and subscripting for each character would become O(n*n) on uPy.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wed, May 13, 2015 at 3:03 AM, Rob Gaddi wrote: > A firm grasp of C will make you a better programmer in any language, even > if you haven't written a line of it in 20 years. It's the ability to > read a map. A lack of C is the person blindly following their GPS and > hoping for the best. That's as may be, but I would still not recommend it as a first language. It's possible to explain algorithmic complexity with a high level language; Python's data types generally have predictable costs associated with them, although a lot of them aren't actually language guarantees (I could imagine a Python implementation using an O(log n) tree instead of an amortized O(1) hash table for its dict, if other tradeoffs make it worthwhile); at any rate, you can always just construct your own fundamental data structures if you want to teach what a linked list is good for, or what a splay tree can do for you. C knowledge is good, but first get to know the broader art of programming, and then get to know C. Learning low-level languages too soon will end up binding your mind to a particular CPU architecture. That happened to me in a big way; I got to thinking about everything in terms of how an 80x86 CPU would deal with it, without any comprehension of some of the modern aspects of low-level programming like pipeline management and cache locality. It was quite the eye-opener when I started hand-optimizing my C compiler's output on a more modern chip, and found that my improvements... uhh, added about 50% to the run time. That's when I stopped doing any assembly language work, and just let the compiler do its magic :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tue, 12 May 2015 08:11:25 -0700, zipher wrote: > On Monday, May 11, 2015 at 9:04:24 PM UTC-5, Steven D'Aprano wrote: >> On Tue, 12 May 2015 05:01 am, beliav...@aol.com wrote: >> >> > Yale has taken the unusual step of outsourcing its introductory CS >> > class to Harvard, which uses C as the main language in its CS50 >> > class. >> >> And another generation of new programmers will be irreversibly damaged >> by exposure to C... > > Come on, C is perfect for computer engineering students. For CS > students, it's of mixed value. And that's how you train CS students to write inefficient code that takes orders of magnitude longer to run than it should. Is that a true array or a linked list? "It's a high level language, that's just an implementation detail." Yes, but it's an implementation detail that determines whether even the simple act of looking up element n is O(1) or O(n). C teaches you the language of the computer. Understanding it allows you to grasp what your high-level code is actually doing, and why and when a list (array) is more efficient than a dict (hashtable). Because you've written a dynamically resizing list, and learned the perils of having to realloc() as the size grows. And you've written a hashtable, and understand the expense of the hashing function, and the tradeoffs between wasted memory and having to wade at O(n) pace through a linked list of collision candidates. A firm grasp of C will make you a better programmer in any language, even if you haven't written a line of it in 20 years. It's the ability to read a map. A lack of C is the person blindly following their GPS and hoping for the best. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Wed, May 13, 2015 at 1:53 AM, Stefan Ram wrote: > zipher writes: >>so what kind of bullshit is saying that you should get rid of PRINT? > > What might be reasonable is to be able to dissect a program > into functions, and have no effects in functions that are > there to calculate some value. > > For example, when one calculates, > > y = sin( x ) > > , using a library function »sin«, one does not want »sin« to > print something. > > Such library functions might even be used in code for a GUI > that has no console to print to at all. > > In order to learn how to write such functions, one might > temporarily use the rule that PRINT is allowed only in the > main block (not in functions) or temporarily for debugging. More generally, there are certain things which belong to the application, and not to any library - things like: * The console - print() and input(), and GUI windows * Command-line arguments * Program termination * Working directory and root directory * Credentials (uid/gid, etc) * Logging configuration (destinations etc) There are exceptions; argument parsing libraries often are granted control over the console and program termination in addition to reading sys.argv, but you would be somewhat surprised if having "--no-check-ssl-certs" in sys.argv silently downgraded your HTTP library's security settings. Control over application-wide settings generally has to be in the hands of the application, not any one library. So if you're writing a library function, it probably shouldn't use print()... but your application is most welcome to. You usually know which one you're writing at any given time. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On 12/05/2015 07:42, Rustom Mody wrote: And related to that (and one reason a pure functional language is good for pedagogy): NO PRINT statement It may seem trivial but beginning students have a real hard writing clean structured code. Tabooing prints helps get there faster And working in the interpreter makes a print-taboo a viable option If students can't be taught to distinguish print from other parts of the language they should get themselves onto a course teaching semi-skilled light bulb fitting. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 4:16:31 AM UTC-5, Rustom Mody wrote: > On Tuesday, May 12, 2015 at 12:27:44 PM UTC+5:30, Chris Angelico wrote: > > On Tue, May 12, 2015 at 4:42 PM, Rustom Mody wrote: > > > And related to that (and one reason a pure functional language is good for > > > pedagogy): NO PRINT statement > > > It may seem trivial but beginning students have a real hard writing clean > > > structured code. Tabooing prints helps get there faster > > > And working in the interpreter makes a print-taboo a viable option > > > > I firmly disagree. > > Yes we know that! > > As it happens you also disagree with ACM's latest CS curriculum: I/O is an essential part of computing in the West. (I'll leave Symbolics out of of that category.) It started with switches and lights, so what kind of bullshit is saying that you should get rid of PRINT? ACM must have gotten confused or steamrolled by one of its members. mark Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Monday, May 11, 2015 at 9:04:24 PM UTC-5, Steven D'Aprano wrote: > On Tue, 12 May 2015 05:01 am, beliav...@aol.com wrote: > > > Yale has taken the unusual step of outsourcing its introductory CS class > > to Harvard, which uses C as the main language in its CS50 class. > > And another generation of new programmers will be irreversibly damaged by > exposure to C... Come on, C is perfect for computer engineering students. For CS students, it's of mixed value. -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 12:27:44 PM UTC+5:30, Chris Angelico wrote: > On Tue, May 12, 2015 at 4:42 PM, Rustom Mody wrote: > > And related to that (and one reason a pure functional language is good for > > pedagogy): NO PRINT statement > > It may seem trivial but beginning students have a real hard writing clean > > structured code. Tabooing prints helps get there faster > > And working in the interpreter makes a print-taboo a viable option > > I firmly disagree. Yes we know that! As it happens you also disagree with ACM's latest CS curriculum: https://www.acm.org/education/CS2013-final-report.pdf [pg 158] Absolute basics of CS include functional programming; among which first point is 'effect-free programming' [Note there is no mention or commitment to fancy functional programming *languages*, just the principles] > Interactive work is well and good, but print (or > equivalent - console.log, log.info, werror, etc etc) is extremely > useful for learning about a larger application. You are talking phd level (or maybe graduate level) I am talking kindergarten > You can play with things at the terminal, Very important to play before you grow up > but how can you find out exactly what happens > when you click this button? Ensuring that your application can be > imported, executed, and manipulated interactively, all without > breaking its primary purpose, is a LOT of extra work, and not > something I'd recommend to beginners. So learn about print, learn > about how to get info out of a running program. You'll be the better > programmer for it. Maybe you should read up on Bloom's taxonomy [ACM curriculum follows this but simplified from 5 to 3 levels -- familiarity, usage, assessment] In particular wrt print: You are not distinguishing - learning the 'what' of print (familiarity) from - learning the how (usage) and most important the "when not" (assessment) -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tue, May 12, 2015 at 4:42 PM, Rustom Mody wrote: > And related to that (and one reason a pure functional language is good for > pedagogy): NO PRINT statement > It may seem trivial but beginning students have a real hard writing clean > structured code. Tabooing prints helps get there faster > And working in the interpreter makes a print-taboo a viable option I firmly disagree. Interactive work is well and good, but print (or equivalent - console.log, log.info, werror, etc etc) is extremely useful for learning about a larger application. You can play with things at the terminal, but how can you find out exactly what happens when you click this button? Ensuring that your application can be imported, executed, and manipulated interactively, all without breaking its primary purpose, is a LOT of extra work, and not something I'd recommend to beginners. So learn about print, learn about how to get info out of a running program. You'll be the better programmer for it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 11:09:01 AM UTC+5:30, Rustom Mody wrote: > The difference between C/Lisp (I club them together) and python is that > the former are more heroic. > > Like mountain climbing you can get a high, a thrill, even 'see God'¹ but > you can also break your back or worse. > > Python is by contrast like a walk in the park. If you find it interesting > (for reasons outside of python) you can get the job done. No epiphanies here Just to be clear the "No epiphanies" is entirely positive. Around 2002 I started teaching python. Around the same time I started using an open editor rather than blackboard to teach. And for the most part python has been a trusted friend -- even if I dont know the code I will write beforehand and the bugs and the debugging and so on. [I remember one time getting completely screwed by regular expressions And more recently some confusion re dunder methods. but these are the exception to the rule that mostly python is quite reliable. ] The reason I am saying this (to OP): Which language you choose may not matter too much. But choose one you are sufficiently friendly with to start hacking with an open editor in front of the class Scheme?? I used scheme in the 80s -- ie before the age of projectable editor So while *in principle* it may seem as reliable as python In practice when I read racket today I find it far more forbidding than the PC scheme manuals I read in the 80s The other suggestion I would make: Use an interactive interpreter. Even if I were using C today, I'd find a C interpreter. And never mind that it messes up 10% of 'official' C semantics. You'll breeze through the remaining 90% at 3⨯ the rate And related to that (and one reason a pure functional language is good for pedagogy): NO PRINT statement It may seem trivial but beginning students have a real hard writing clean structured code. Tabooing prints helps get there faster And working in the interpreter makes a print-taboo a viable option -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tuesday, May 12, 2015 at 10:34:32 AM UTC+5:30, Michael Torrie wrote: > On 05/11/2015 08:04 PM, Steven D'Aprano wrote: > > On Tue, 12 May 2015 05:01 am, beliavsky wrote: > > > >> Yale has taken the unusual step of outsourcing its introductory CS class > >> to Harvard, which uses C as the main language in its CS50 class. > > > > And another generation of new programmers will be irreversibly damaged by > > exposure to C... > > How so? Surely starting at first principles of a computer's operation > can't be all that bad. In my program at uni, one of the very first > level courses was actually to build a simulated CPU from logic gates and > then program it in assembly. Thats true. The intro to programming course needs to convey something beyond syntax and minor details -- something like the 'Zen' The difference between C/Lisp (I club them together) and python is that the former are more heroic. Like mountain climbing you can get a high, a thrill, even 'see God'¹ but you can also break your back or worse. Python is by contrast like a walk in the park. If you find it interesting (for reasons outside of python) you can get the job done. No epiphanies here > C is just a step up from there. which may be a step too much. And I think its much more than one step. [How many links in the gcc toolchain?] > I should note they also had Java in the first year, and that certainly caused > irreversible damage. A different question altogether. What Joel Spolsky describes² is simply the fact that Java slides its practitioners down the DIKW pyramid³ [My own record of the hell let lose by teaching too early C.⁴⁵ The first written in 91 and rather widely cited at that time including first edition of 'Code Complete'. Second is a toning down as I grow older! ] To some extent good teaching can ameliorate. Only to some extent since the whole purpose of such languages is to dumb down programming. [And lest pythonistas feel pleased with that, do consider whether what Spolsky applies to Java in 2005 in 2015 applies to python] > > The wonderfulness of LISP and Python can be appreciated just fine with a > solid background in how Von Neumann architecture actually functions. In > fact I appreciate the layers of abstraction even more after I understand > them. modulo the law of primacy ¹ Eric Raymond almost literally says this: | Lisp is worth learning for the profound enlightenment experience you will | have when you finally get it; that experience will make you a better | programmer for the rest of your days, even if you never actually use Lisp ² http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html ³ http://en.wikipedia.org/wiki/DIKW_Pyramid ⁴ http://www.the-magus.in/Publications/chor.pdf ⁵ http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On 05/11/2015 08:04 PM, Steven D'Aprano wrote: > On Tue, 12 May 2015 05:01 am, beliav...@aol.com wrote: > >> Yale has taken the unusual step of outsourcing its introductory CS class >> to Harvard, which uses C as the main language in its CS50 class. > > And another generation of new programmers will be irreversibly damaged by > exposure to C... How so? Surely starting at first principles of a computer's operation can't be all that bad. In my program at uni, one of the very first level courses was actually to build a simulated CPU from logic gates and then program it in assembly. C is just a step up from there. I should note they also had Java in the first year, and that certainly caused irreversible damage. The wonderfulness of LISP and Python can be appreciated just fine with a solid background in how Von Neumann architecture actually functions. In fact I appreciate the layers of abstraction even more after I understand them. -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Tue, 12 May 2015 05:01 am, beliav...@aol.com wrote: > Yale has taken the unusual step of outsourcing its introductory CS class > to Harvard, which uses C as the main language in its CS50 class. And another generation of new programmers will be irreversibly damaged by exposure to C... -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Sunday, May 10, 2015 at 9:38:38 PM UTC-4, Ian wrote: > On Sun, May 10, 2015 at 3:16 PM, Marko Rauhamaa wrote: > > Scheme is my favorite language. I think, however, it is a pretty > > advanced language and requires a pretty solid basis in programming and > > computer science. > > > > Python, in contrast, is a great introductory programming language. Sure, > > you *can* get quite advanced with it, too, but you can get quite a bit > > of fun stuff done with just the basics. > > MIT famously used Scheme in their introductory course for more than > two decades. Although they switched to Python a few years ago, I don't > think they did so because there was anything wrong with Scheme. > Wikipedia informs me that Yale and Grinnell are still using Scheme for > their introductory courses. Yale has taken the unusual step of outsourcing its introductory CS class to Harvard, which uses C as the main language in its CS50 class. http://yaledailynews.com/blog/2014/11/07/faculty-approve-cs50-for-yale/ Faculty approve CS50 for Yale "Just under a month after announcing that Yale's computer science department was considering importing Harvard's most popular course, faculty voted to bring CS50 to Yale. Following what Yale College Dean Jonathan Holloway described as a "long, healthy discussion," faculty at Thursday's monthly meeting voted overwhelmingly to approve CS50 as a class to be taught at Yale. Computer science department chair Joan Feigenbaum said that the next step for CS50 will be for Harvard to approve the sharing of CS50 with Yale. If the course earns approval, she noted, Yale will formally introduce the class in Fall 2015." -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Monday, May 11, 2015 at 8:05:56 PM UTC+5:30, Grant Edwards wrote: > On 2015-05-11, Skip Montanaro wrote: > > > Don't CS departments still have a computer languages survey class? When I > > was a graduate student at Iowa in the early 80s, we had one. (It was, as I > > recall, an upper level undergrad course. I didn't get into CS until > > graduate school, so went back to filled in some missing stuff.) I don't > > recall all the languages we touched on, but ISTR there were five or six. I > > know we hit Lisp (today, it would likely be Scheme), and probably APL > > (today it would probably be Python+Pandas, MATLAB, R, or something similar). > > There was a similar class at both Iowa State and University of MN. You > learned a half-dozen languages in a single quarter. IIRC, at ISU we > did Lisp, Prolog, APL, Snobol and a couple others. The main > pedagogical language at the time was Pascal, but we also learned > FORTRAN, COBOL, BASIC, and a couple three assembly languages (PDP-11, > VAX, Z80, 6502). If you were a computer enineering major instead of > computer science, you also leared a hardware description language. At > the time it was AHPL. These survey of PLs courses are a travesty. At best students learn nothing At worst they imagine they learnt something. IMHO if you dont get some feel for the language, something about its 'zen', you should not be allowed to say you know anything about it. Getting a grade for it ensures the exact opposite. [I recently heard of a course whose exam papers had questions like: "Name 7 keywords in C++ ] -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On 2015-05-11, Skip Montanaro wrote: > Don't CS departments still have a computer languages survey class? When I > was a graduate student at Iowa in the early 80s, we had one. (It was, as I > recall, an upper level undergrad course. I didn't get into CS until > graduate school, so went back to filled in some missing stuff.) I don't > recall all the languages we touched on, but ISTR there were five or six. I > know we hit Lisp (today, it would likely be Scheme), and probably APL > (today it would probably be Python+Pandas, MATLAB, R, or something similar). There was a similar class at both Iowa State and University of MN. You learned a half-dozen languages in a single quarter. IIRC, at ISU we did Lisp, Prolog, APL, Snobol and a couple others. The main pedagogical language at the time was Pascal, but we also learned FORTRAN, COBOL, BASIC, and a couple three assembly languages (PDP-11, VAX, Z80, 6502). If you were a computer enineering major instead of computer science, you also leared a hardware description language. At the time it was AHPL. More recent gruaduates only seem to know one language (Java or C++) and are completely baffled by anything else. And don't get me started on that damned noise they call music... -- Grant Edwards grant.b.edwardsYow! ! Now I understand at advanced MICROBIOLOGY and gmail.comth' new TAX REFORM laws!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
Don't CS departments still have a computer languages survey class? When I was a graduate student at Iowa in the early 80s, we had one. (It was, as I recall, an upper level undergrad course. I didn't get into CS until graduate school, so went back to filled in some missing stuff.) I don't recall all the languages we touched on, but ISTR there were five or six. I know we hit Lisp (today, it would likely be Scheme), and probably APL (today it would probably be Python+Pandas, MATLAB, R, or something similar). Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Monday, May 11, 2015 at 9:29:31 AM UTC+5:30, Steven D'Aprano wrote: > On Mon, 11 May 2015 06:43 am, Chris Seberino wrote: > > > I'm thinking that for the VERY beginning, Scheme is the fastest language > > to get beginners up and running writing code due to the extremely minimal > > simple syntax. > > Do you believe that learning syntax is the hardest part for beginners to get > past? You seem to be asking a rhetorical question. I regard it as a basic koan in CS http://blog.languager.org/2015/04/poverty-universality-structure-0.html#fundamentalKoan -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Mon, 11 May 2015 06:43 am, Chris Seberino wrote: > I'm thinking that for the VERY beginning, Scheme is the fastest language > to get beginners up and running writing code due to the extremely minimal > simple syntax. Do you believe that learning syntax is the hardest part for beginners to get past? If so, then perhaps you should start by teaching beginners machine code, since the syntax is very simple: any sequence of hexadecimal digits is syntactically valid machine code. If you can teach people to use 0123...9ABCDEF then you have just taught them everything they need to know about the syntax. *wink* The point is, syntax can be *too* minimal, as well as too heavyweight. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Monday, May 11, 2015 at 2:46:38 AM UTC+5:30, Marko Rauhamaa wrote: > Chris Seberino : > > > Instead of learning only Scheme or only Python for a one semester > > intro course, what about learning BOTH? Maybe that could somehow get > > the benefits of both? > > > > I'm thinking that for the VERY beginning, Scheme is the fastest > > language to get beginners up and running writing code due to the > > extremely minimal simple syntax. > > Scheme is my favorite language. I think, however, it is a pretty > advanced language and requires a pretty solid basis in programming and > computer science. Have you seen this? http://www-inst.eecs.berkeley.edu/~cs61a/sp12/book/ Yeah from a certain pov scheme is so advanced that even Abelson and Sussman dont quite get it: http://blog.languager.org/2013/08/applying-si-on-sicp.html So (from that pov) how reasonable is it to expect students to get it? Also good to see: http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Mon, May 11, 2015 at 6:43 AM, Chris Seberino wrote: > Instead of learning only Scheme or only Python for a one semester intro > course, what about learning BOTH? Maybe that could somehow > get the benefits of both? > > I'm thinking that for the VERY beginning, Scheme is the fastest language > to get beginners up and running writing code due to the extremely minimal > simple syntax. > > I'm thinking half way into the semester, instead of moving into intermediate > Scheme, perhaps that is a good time to switch to Python? > > Would a little strong intro to 2 nice languages in one semester be > same/good/worse/better than just 1? I strongly recommend learning multiple languages, but not at the cost of proper comprehension of one of them. Pick one and get started with it, and once you have some basic competence, pick up another; you'll gain a better appreciation for both that way. As to which one first... I always recommend Python as a first language, due to the lack of boilerplate and the simple layout. But if you have a background that makes LISPy languages a better fit for you, then by all means, take Scheme first. For most people I work with, an imperative language makes a better first fit; most people understand the concept of giving someone a series of instructions and expecting them to be performed in sequence down the page, but functional languages take more getting used to. But if you're already accustomed to a functional style - maybe a heavy mathematical background - then LISP-family languages will be a logical extension from that. Eric Raymond recommends [1] learning five languages with distinctly different styles: Python, C/C++, Java, Perl, and LISP. Of the five, I would recommend leaving C and Perl for later, as neither is particularly friendly to a new programmer; the other three you could pick up in any order, and there are commercial courses using all of them. (I personally don't think Java offers much that other languages don't, and haven't used it for anything since the days when Java applets were the only decent way to embed executable code in web browsers; these days, I'd much rather do everything in Python or Pike. But that doesn't mean Java isn't worth learning.) The more languages you learn, the better you'll be as a programmer - but don't skimp on one to pick up another. ChrisA [1] http://www.catb.org/esr/faqs/hacker-howto.html#skills1 -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Sun, May 10, 2015 at 3:16 PM, Marko Rauhamaa wrote: > Scheme is my favorite language. I think, however, it is a pretty > advanced language and requires a pretty solid basis in programming and > computer science. > > Python, in contrast, is a great introductory programming language. Sure, > you *can* get quite advanced with it, too, but you can get quite a bit > of fun stuff done with just the basics. MIT famously used Scheme in their introductory course for more than two decades. Although they switched to Python a few years ago, I don't think they did so because there was anything wrong with Scheme. Wikipedia informs me that Yale and Grinnell are still using Scheme for their introductory courses. > Of course, you could introduce Scheme with similar simplifications. > However, such simplifications (say, iterative constructs) are > nonidiomatic in Scheme. The students should not get into bad habits > that they need to be weaned off of later. You don't need iterative constructs to teach an introductory course. The full text of SICP (the "wizard book") is available on the web for anyone to read at https://mitpress.mit.edu/sicp/. I don't think it ever even *mentions* "iterative constructs". Where it distinguishes recursive algorithms from iterative ones, recursive syntax is used in both cases. >> I'm thinking half way into the semester, instead of moving into >> intermediate Scheme, perhaps that is a good time to switch to Python? No, stick with one language for at least the first course. Needing to learn the syntax and semantics of *two* programming languages, especially two such different ones, is just going to distract students from the fundamental concepts that the introductory class is intended to teach. -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
> > Instead of learning only Scheme or only Python for a one semester intro > > course, what about learning BOTH? Maybe that could somehow > > get the benefits of both? > > No. LISP-like languages are very different beasts, requiring different > mind-sets. It's like going from geometry to arithmetic. > > Or trying to teach OS/2 (which had great abstract ideas) and switching to > Linux without covering the architecture and engineering underneath them. Another point. You're allowing Church`s Thesis to misinform you. While, in theory, every programming language could be made into any other, the architecture in which to do so is completely different, so it misleads the programmer. To fit LISP into a Turing Machine architecture (what most every procedural programming language and most every computer sold is/utilizes) requires a very obscene translation table in the TM. I'm not even sure that it's been analyzed, because the TM has no concept of a stack. Any PhD's know of who's actually make a stack on the TM? Usually the tape itself holds the stack, but with LISP architecture, this isn't the natural fit. Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Sunday, May 10, 2015 at 3:43:25 PM UTC-5, Chris Seberino wrote: > Instead of learning only Scheme or only Python for a one semester intro > course, what about learning BOTH? Maybe that could somehow > get the benefits of both? > > I'm thinking that for the VERY beginning, Scheme is the fastest language > to get beginners up and running writing code due to the extremely minimal > simple syntax. > > I'm thinking half way into the semester, instead of moving into intermediate > Scheme, perhaps that is a good time to switch to Python? > > Would a little strong intro to 2 nice languages in one semester be > same/good/worse/better than just 1? No. LISP-like languages are very different beasts, requiring different mind-sets. It's like going from geometry to arithmetic. Or trying to teach OS/2 (which had great abstract ideas) and switching to Linux without covering the architecture and engineering underneath them. mark -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
Chris Seberino : > Instead of learning only Scheme or only Python for a one semester > intro course, what about learning BOTH? Maybe that could somehow get > the benefits of both? > > I'm thinking that for the VERY beginning, Scheme is the fastest > language to get beginners up and running writing code due to the > extremely minimal simple syntax. Scheme is my favorite language. I think, however, it is a pretty advanced language and requires a pretty solid basis in programming and computer science. Python, in contrast, is a great introductory programming language. Sure, you *can* get quite advanced with it, too, but you can get quite a bit of fun stuff done with just the basics. Of course, you could introduce Scheme with similar simplifications. However, such simplifications (say, iterative constructs) are nonidiomatic in Scheme. The students should not get into bad habits that they need to be weaned off of later. > I'm thinking half way into the semester, instead of moving into > intermediate Scheme, perhaps that is a good time to switch to Python? What are you teaching? If you are teaching computer science, you should use languages to illustrate abstract ideas. Thus, Python can be used to introduce basic control and data structures, I/O, OOP etc. Scheme should be used to teach functional programming and maybe combinatory logic and computability. Prolog could be used to demonstrate logic programming and automated theorem proving. C could be used to understand the nitty-gritties under the hood and fear of SIGSEGV. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
On Sun, 10 May 2015 13:43:03 -0700, Chris Seberino wrote: > Instead of learning only Scheme or only Python for a one semester intro > course, what about learning BOTH? Maybe that could somehow get the > benefits of both? > > I'm thinking that for the VERY beginning, Scheme is the fastest language > to get beginners up and running writing code due to the extremely > minimal simple syntax. > > I'm thinking half way into the semester, instead of moving into > intermediate Scheme, perhaps that is a good time to switch to Python? > > Would a little strong intro to 2 nice languages in one semester be > same/good/worse/better than just 1? The first course I took, we learned Algol-60, then when we couldn't get computer time for compiles, we were asked to pick up FORTRAN-IV on the side. So we "published" our solutions to the class problems in Algol and re-wrote them to be run in FORTRAN. It was a fine first-hand look at what the "general purpose" in General Purpose Computer really meant. There was no confusing the machine and the language after that. Scheme/ Python would be even more radical, I think. If you can put them across effectively, I say go for it. Mel. > > cs -- https://mail.python.org/mailman/listinfo/python-list
Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?
Instead of learning only Scheme or only Python for a one semester intro course, what about learning BOTH? Maybe that could somehow get the benefits of both? I'm thinking that for the VERY beginning, Scheme is the fastest language to get beginners up and running writing code due to the extremely minimal simple syntax. I'm thinking half way into the semester, instead of moving into intermediate Scheme, perhaps that is a good time to switch to Python? Would a little strong intro to 2 nice languages in one semester be same/good/worse/better than just 1? cs -- https://mail.python.org/mailman/listinfo/python-list
