ACM article on Python
The latest issue of Communications of the ACM (March 2015) has an article titled "Python for Beginners" with a few points that surprised me. The first thing that got my attention was the banner text "Choosing Python is the modern equivalent of the old adage 'nobody ever got fired for choosing IBM'". If I were an unimaginative, risk-averse bureaucrat, just wanting to run with the herd, the choice would be Java, not Python. The only clarification I can find is in the conclusion of the article where we learn that Python is "blandly conventional", just the latest crest in the "waves of fashion" (Pascal, C++, Java, Python, Scratch). Odd that Ruby is not mentioned anywhere. I read the article carefully, looking for substantive comparisons, and found only more baffling, vague statements without enough definition or specificity to reach any understanding. What does it mean that Java is more "industrial strength"? I would say Java is a more "industrial" language, but that is not a compliment. The biggest problem is calling Python a "scripting language". Any language can do scripting, and Python is particularly good at it, but this label makes me think of shell scripting (e.g. tcsh, bash, and all the variants of these special-purpose "job control" languages), not a modern, object-oriented, full-feature language like Python. Another problem is quoting a Python advocate on the productivity advantage of Python (2 man-months vs 24). Wild statements make prospective users walk away without further investigation. I tell my faculty friends it is 2 to 1 over an expert's productivity in Java. I might even quote Bruce Eckel's estimate, 5 to 1, but only to back up my own more conservative estimate. Until now, I've never seen 12 to 1. The bulk of the article is discussion of Python's "weaknesses": 1) Creating non-trivial data structures is onerous. 2) Limited support for testing. 3) Lack of static types. 4) Difficult transition to other languages because the syntax is quite different. Show me some real-world examples of a data structure or test setup I can't do better in Python. Python's doctest is an excellent methodology for teaching Test-Driven Design, or even just teaching basic Python (see pykata.org). I understand the complaint about data types, but I would not give up the advantages of dynamic typing for the few projects where I really need the efficiency of static types. Write first in Python, then insert some C code where testing shows that it is actually needed. When I first started using Python, I was astonished to learn that it was not derived from Java. See codingbat.com for many one-to-one comparisons of various code snippets. See Goldwasser's "Object Oriented Programming in Python" for an excellent transition to either Java or C++. This article was disappointing and superficial.
On Fri, Mar 13, 2015 at 7:33 AM, David MacQuigg <macquigg@ece.arizona.edu> wrote:
The first thing that got my attention was the banner text "Choosing Python is the modern equivalent of the old adage 'nobody ever got fired for choosing IBM'". If I were an unimaginative, risk-averse bureaucrat, just wanting to run with the herd, the choice would be Java, not Python. The only clarification I can find is in the conclusion of the article where we learn that Python is "blandly conventional", just the latest crest in the "waves of fashion" (Pascal, C++, Java, Python, Scratch). Odd that Ruby is not mentioned anywhere.
Remember, this article is specifically about language choices for programming education. I agree that Java is still the default choice for a risk-averse bureaucrat in industry, but in education, Python has become the most popular, default choice (that's sort of the whole point of the article). In industry, many managers don't feel the need to look beyond Java to find more compelling options (even those that might boost productivity); similarly, at this point, many educators don't feel the need to look beyond Python to see if there are more compelling options (even those that might provide a better educational experience). That's what I think the author's point is about Python being "blandly conventional". There's no reason to think that Python is the pinnacle of educational languages. It wasn't designed to be an educational language, so it should be possible to do better. But it happens to be a pretty good choice for education, good enough that many people have stopped looking for better. Ruby isn't mentioned because it never made significant waves in the educational community. Remember, the article is just about educational language choices, not fashionable languages in general. The bulk of the article is discussion of Python's "weaknesses":
1) Creating non-trivial data structures is onerous. 2) Limited support for testing. 3) Lack of static types. 4) Difficult transition to other languages because the syntax is quite different.
Show me some real-world examples of a data structure or test setup I can't do better in Python. Python's doctest is an excellent methodology for teaching Test-Driven Design, or even just teaching basic Python (see pykata.org).
I think the best way to understand these criticisms is to take a look at the language Pyret (pyret.org), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language. In Python you have a couple options to build structured data. You can use the object system, but that's a little heavyweight and clunky for beginners. You can just use dictionaries with the relevant entries, but beginners often don't have the discipline to mentally keep track of many different types of objects that are all dictionaries with different combinations of entries. This gets especially problematic when you get to recursive data structures like binary trees. It's pretty tough to teach this well in Python with dictionaries, so teaching this usually gets delayed until the object system has been taught, and then all your functionality that operates on the trees are generally written as methods split between the branch and leaf classes. This is tough for students because the code for a given function isn't all in one place, it is spread out among the two different types of classes. Contrast this with Pyret's approach to structured data and recursive data structures. As far as testing goes, Python's biggest limitation is that structured data created with dictionaries or objects are mutable data structures. It is fundamentally more difficult to test mutable data structures because you can't use a built-in notion of structural equality. So all tests must be in the form of setting up an object, calling functions/methods which mutate it, and then testing various properties of the mutated object. This is onerous for beginners, and very hard to get them to do this with any kind of discipline. Testing is radically more simple in languages that offer a rich set of immutable data structures and an easy way to create new immutable data structures that automatically come with a structural equality comparison. So it's easier to teach a "tests first" approach by starting with immutable data structures and moving to mutable data structures after students are more mature in their programming experiences. Doctests are great for regression testing, e.g., copying and pasting an interactive transcript into the actual code, but are not very easy for students to write the tests ahead of writing their code, especially for complex data structures or testing that certain errors are raised -- it is hard to figure out ahead of time how that kind of stuff is going to print.
I understand the complaint about data types, but I would not give up the advantages of dynamic typing for the few projects where I really need the efficiency of static types. Write first in Python, then insert some C code where testing shows that it is actually needed.
I vastly prefer dynamic typing over static typing in my own code. But this is about education. We have a responsibility to teach students both, so a language that lets you gradually transition from dynamic typing to static typing is preferable (in education) to one that doesn't. This isn't about bashing Python; we all recognize that Python is one of the more compelling alternatives right now in programming education. But let's not settle for "good enough". There's value to diagnosing the weaknesses of Python so we can continue to build and look for even better options.
Mark, thanks for the excellent reply on this topic. I was not aware of Pyret, and this is really opening my eyes. It has been a few years since I thought about the next step after Python. Ruby didn't add anything fundamentally better. On Sat, Mar 14, 2015 at 2:27 PM, Mark Engelberg <mark.engelberg@gmail.com> wrote:
On Fri, Mar 13, 2015 at 7:33 AM, David MacQuigg <macquigg@ece.arizona.edu> wrote:
The first thing that got my attention was the banner text "Choosing Python is the modern equivalent of the old adage 'nobody ever got fired for choosing IBM'". If I were an unimaginative, risk-averse bureaucrat, just wanting to run with the herd, the choice would be Java, not Python. The only clarification I can find is in the conclusion of the article where we learn that Python is "blandly conventional", just the latest crest in the "waves of fashion" (Pascal, C++, Java, Python, Scratch). Odd that Ruby is not mentioned anywhere.
Remember, this article is specifically about language choices for programming education. I agree that Java is still the default choice for a risk-averse bureaucrat in industry, but in education, Python has become the most popular, default choice (that's sort of the whole point of the article). In industry, many managers don't feel the need to look beyond Java to find more compelling options (even those that might boost productivity); similarly, at this point, many educators don't feel the need to look beyond Python to see if there are more compelling options (even those that might provide a better educational experience).
I wonder if there might be a significant difference between the top schools and all the rest. Faculty at schools like Caltech and MIT might be more willing to break with tradition, more likely to favor teaching fundamentals over training for industry. So Python appears to be most popular in the top schools surveyed for the article, but book sales still show Java to be tops. That's what I think the author's point is about Python being "blandly
conventional". There's no reason to think that Python is the pinnacle of educational languages. It wasn't designed to be an educational language, so it should be possible to do better. But it happens to be a pretty good choice for education, good enough that many people have stopped looking for better.
I used to think we were on a merry-go-round with a new language every ten years (starting with FORTRAN). Now I see it as a convergence, with Python being very close to the optimum. There are certain fundamental methodologies in computing, and Python implements those methodologies very well. Languages like Ruby, Prothon, now Pyret offer platforms to test new ideas that may one day be brought into Python. Ruby isn't mentioned because it never made significant waves in the
educational community. Remember, the article is just about educational language choices, not fashionable languages in general.
The bulk of the article is discussion of Python's "weaknesses":
1) Creating non-trivial data structures is onerous. 2) Limited support for testing. 3) Lack of static types. 4) Difficult transition to other languages because the syntax is quite different.
Show me some real-world examples of a data structure or test setup I can't do better in Python. Python's doctest is an excellent methodology for teaching Test-Driven Design, or even just teaching basic Python (see pykata.org).
I think the best way to understand these criticisms is to take a look at the language Pyret (pyret.org), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language.
Excellent website!! I can see some serious thought going into this new development.
In Python you have a couple options to build structured data. You can use the object system, but that's a little heavyweight and clunky for beginners. You can just use dictionaries with the relevant entries, but beginners often don't have the discipline to mentally keep track of many different types of objects that are all dictionaries with different combinations of entries. This gets especially problematic when you get to recursive data structures like binary trees. It's pretty tough to teach this well in Python with dictionaries, so teaching this usually gets delayed until the object system has been taught, and then all your functionality that operates on the trees are generally written as methods split between the branch and leaf classes. This is tough for students because the code for a given function isn't all in one place, it is spread out among the two different types of classes. Contrast this with Pyret's approach to structured data and recursive data structures.
I'm not convinced, but I'll let someone else address the issue of comparing data structures.
As far as testing goes, Python's biggest limitation is that structured data created with dictionaries or objects are mutable data structures. It is fundamentally more difficult to test mutable data structures because you can't use a built-in notion of structural equality. So all tests must be in the form of setting up an object, calling functions/methods which mutate it, and then testing various properties of the mutated object. This is onerous for beginners, and very hard to get them to do this with any kind of discipline. Testing is radically more simple in languages that offer a rich set of immutable data structures and an easy way to create new immutable data structures that automatically come with a structural equality comparison. So it's easier to teach a "tests first" approach by starting with immutable data structures and moving to mutable data structures after students are more mature in their programming experiences. Doctests are great for regression testing, e.g., copying and pasting an interactive transcript into the actual code, but are not very easy for students to write the tests ahead of writing their code, especially for complex data structures or testing that certain errors are raised -- it is hard to figure out ahead of time how that kind of stuff is going to print.
We need good, real-world examples to nail this down. The example on the Pyret website: check: empty.first raises "not-found" [list: 1,2,3,4,5].first is 1 [list: 2,4,6,8].first is 2 end shows a comparison with Python's clunky unittest. Doctest is much better for teaching than unittest: def first(lst): '''Returns the first element of a list >>> first([1,2,3,4,5]) is 1 True >>> first([2,4,6,8]) is 2 True >>> first([]) Traceback (most recent call last): ... IndexError: list index out of range ''' return lst[0] The Pyret syntax is less verbose, but as you pointed out, the Python is just a snip from an interactive session pasted into the docstring. A student can experiment easily getting a command to work in the interpreter, then just paste it into his final code. I have to disagree about the difficulty of writing tests first. Even in cases where the exact output cannot be predicted (e.g. a memory address) the doctest module allows those parts of the output to be ignored. Notice in the above example, we have ignored all the cruft in the traceback response.
I understand the complaint about data types, but I would not give up the advantages of dynamic typing for the few projects where I really need the efficiency of static types. Write first in Python, then insert some C code where testing shows that it is actually needed.
I vastly prefer dynamic typing over static typing in my own code. But this is about education. We have a responsibility to teach students both, so a language that lets you gradually transition from dynamic typing to static typing is preferable (in education) to one that doesn't.
I forgot to mention the module "numpy", which doesn't even require C to teach the benefits of static typing. Have the students sort a huge list of integers, then compare the speed using a static array of integers. This isn't about bashing Python; we all recognize that Python is one of the
more compelling alternatives right now in programming education. But let's not settle for "good enough". There's value to diagnosing the weaknesses of Python so we can continue to build and look for even better options.
Let's nail down what those weaknesses really are. So many faculty just repeat what they have heard, and this article may be doing the same.
Ruby isn't mentioned because it never made significant waves in the educational community. Remember, the article is just about educational language choices, not fashionable languages in general. The bulk of the article is discussion of Python's "weaknesses":
1) Creating non-trivial data structures is onerous. 2) Limited support for testing. 3) Lack of static types. 4) Difficult transition to other languages because the syntax is quite different.
Show me some real-world examples of a data structure or test setup I can't
do better in Python. Python's doctest is an excellent methodology for teaching Test-Driven Design, or even just teaching basic Python (see pykata.org).
I think the best way to understand these criticisms is to take a look at the language Pyret (pyret.org), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language. Shiriam Krishnamurti & Co. have a long history of being bitter about Python's success and vocal about it's perceived shortcomings. I suppose it makes sense that the ACM might be getting some input from that corner, which has also given us PLT Scheme and Racket before Pyret. 'Nature" also had an article on Python recently and pointed out that one of Python's chief advantages is the ecosystem to which it gives access, as a controller language. There's no reason to avoid "teaching languages" such as Racket, Squeak (Process?), Pyret and so on, but I do note they tend to have a shorter half life than languages used widely in industry and they do not open as many doors to 3rd party assets. I wouldn't give up on on Ruby making greater inroads in education, just maybe not among English-speakers as much. Kirby
Checking the edu-sig archive, looks like indentation doesn't show this paragraph was quoted by me not written by me: """ I think the best way to understand these criticisms is to take a look at the language Pyret (pyret.org), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language. """ Just thought I'd make that clearer. Email clients and what shows up archivally are sometimes different. https://mail.python.org/pipermail/edu-sig/2015-March/011213.html In addition, I'm continuing to explore where in STEM the kind of curriculum writing we need best fits, pre-college. Example post on that theme: http://mathforum.org/kb/thread.jspa?messageID=9724150 Kirby
Kirby, have you ever looked at mathpiper? (http://www.mathpiper.org/) I know you have a strong interest in fusing math explorations with programming, so it seems like something that would be right up your alley -- sort of an accessible Mathematica intended for education. The docs section also contains a couple e-textbooks that weave in a lot of mathematics examples into the programming instruction ( http://www.mathpiper.org/documentation-1) Certainly one of the more attractive aspects of Python is that it is both relatively-easy-to-learn and relatively-useful-in-the-real-world. But there's definitely a school of thought that *no* language used in industry is optimal for education, that the aims of industry and education are too incompatible for one language to rule for both purposes. It's definitely an interesting debate. I feel fortunate that I work with young enough kids that I feel little pressure to teach them something with immediate marketable value. This gives me the freedom to experiment with many different languages; I've found that I rather like teaching ones expressly designed for education, but Python remains one of my favorite educational options of the popular, mainstream languages. For me, the thing that has made me lose some enthusiasm for Python was not even mentioned in the article. For me, the biggest downside is that the language, with its Global Interpreter Lock, lacks a clean solution to teaching concurrency. IMHO, concurrency has become a vital issue, and requires a somewhat different way of thinking about problems. To create the next generation of exceptional programmers, I believe we need to introduce models of concurrent programming much earlier in the curriculum. Almost every recent programming language places a huge emphasis on concurrency (such as Clojure, Scala, Go, F#, Julia, and many others) but none of those are particularly welcoming to beginner programmers. So I'd love to see more educational languages that feature concurrency.
On Thu, Mar 19, 2015 at 12:59 AM, Mark Engelberg <mark.engelberg@gmail.com> wrote:
Kirby, have you ever looked at mathpiper? (http://www.mathpiper.org/) I know you have a strong interest in fusing math explorations with programming, so it seems like something that would be right up your alley -- sort of an accessible Mathematica intended for education. The docs section also contains a couple e-textbooks that weave in a lot of mathematics examples into the programming instruction ( http://www.mathpiper.org/documentation-1)
Thanks Mark, perusing the book / language now. Rings a bell. Yes: https://mail.python.org/pipermail/edu-sig/2010-December/010148.html Having an interactive console is key I think, so you may use the interpreter as a calculator. All the languages we're discussing are like that, including: ISETL (cited by Tim Peters early on), J, APL (both Iverson & Co.), and Mathpiper here (and Wolfram's Mathematica of course, and Guido's Python, and Pyret). REPL is king. [1] Logo was of course a huge pioneer in adding graphical / robot output really early. Logo had just the one "context turtle" e.g. FD 10 meant the one turtle. OO makes it easy to incarnate many such animals, each with its own state. Some schools of though decry "internal state" but I notice that we have it in the real world and value that feature. I've never been a "one language uber-alles" kind of guy in that I always encourage exposure to multiple languages, at least two that are different enough to provide real contrasts. I'm not eager for everyone to "agree on one language" for all purposes, though "business English" does serve as a kind of global esperanto in some dimensions. That doesn't mean it should take over in higher level thought. Sure, one language might be "front burner" compared to another in one's studies. Python + J (jsoftware.com) has been a combo I've often recommended. The LEX Institute approach ("Who is Fourier?") to learning human languages has been influential (better to tackle many over just one, because of the synergies involved). My first exposure to programming in university, no counting high school hours spent with an HP-65 programmable calculator as (a) eclectic and (b) pre-Python. Our intro course was more of a survey including: PL/1, Snobol, Assembler, APL, LISP. Obviously we were not to become masters of any, however letting the contrasts sink in really opened my thinking to the "ecosystem" idea. APL became my favorite in the 1970s (because of REPL in large degree), which explains my later fascination with J (both Iverson languages).[2]
Certainly one of the more attractive aspects of Python is that it is both relatively-easy-to-learn and relatively-useful-in-the-real-world. But there's definitely a school of thought that *no* language used in industry is optimal for education, that the aims of industry and education are too incompatible for one language to rule for both purposes. It's definitely an interesting debate. I feel fortunate that I work with young enough kids that I feel little pressure to teach them something with immediate marketable value. This gives me the freedom to experiment with many different languages; I've found that I rather like teaching ones expressly designed for education, but Python remains one of my favorite educational options of the popular, mainstream languages.
I'm all for encouraging debate. What I hear a lot is once your language becomes typecast as "a teaching language" that's "the kiss of death" as far as industry is concerned. That's a stereotype to overcome I think. I tend to think of industry as averaging 10 years ahead of academia with the latter making do with what more competitive / secretive enterprises have contributed to open source (I associate "free and open" with the "liberal" in "liberal arts"). That's more typecasting institutions than individuals, which latter tend to go back and forth between the two. So my attitude is more "Python and what else?" i.e. lets not stop with Python as if it were some be-all-end-all. It ain't. It's another tool, like business English is a tool. Python + Pyret as a bridge to something else then? Haskell? Prolog? I'm not one of those who think you need to join warring Camp A (OOP) or warring Camp B (FP) and then express loyalty to one by dissing the other. Rather, play up the strengths of both paradigms (I know Shiriam disputes that OOP is really a "paradigm" but whatever).[3] For me, the thing that has made me lose some enthusiasm for Python was not
even mentioned in the article. For me, the biggest downside is that the language, with its Global Interpreter Lock, lacks a clean solution to teaching concurrency. IMHO, concurrency has become a vital issue, and requires a somewhat different way of thinking about problems. To create the next generation of exceptional programmers, I believe we need to introduce models of concurrent programming much earlier in the curriculum. Almost every recent programming language places a huge emphasis on concurrency (such as Clojure, Scala, Go, F#, Julia, and many others) but none of those are particularly welcoming to beginner programmers. So I'd love to see more educational languages that feature concurrency.
That sounds valid and interesting. How well does Pyret fit that bill I wonder? Python has new infrastructure growing out of Tulip around the syntax of yield, using from and send, to develop its native asynchronous capabilities even more. For myself, when I'm at OSCON you'll find me in the Scala and Clojure tutorials. [4] My friend Dr. David DiNucci has written a book on concurrency which has plunged me back into thinking of programming as theater, scripting characters (agents) to do stuff, oft in parallel.[5] Managing concurrency in ordinary life amongst multiple players is something I think we need to get better at in business / enterprise / institution management in general, not just in our use of multiple processors. Operations Research, as it used to be called, with its PERT charts and critical paths, was always about concurrency (e.g. building a submarine or A-bomb faster than the competition). I go back to Python being a "glue language" that "plays well with others" and believe in harping on those virtues as they both imply "others" to glue together and play with. Python is not like the pythons in Florida, stereotyped as devouring everything else, leaving only pythons (all alligators eaten). That's not a goal. The evolutionary advantages that go with biodiversity is an important principle. Python is so useful because it's like a tour bus: once you're on board, you get to visit many alien lands through what it controls i.e. talks to (e.g. Blender). So for me it's always "Python and what else?" these days, and not "How can we replace Python with something else more trendy?". Kirby [1] http://mathforum.org/kb/message.jspa?messageID=9718737 http://mathforum.org/kb/message.jspa?messageID=9700004 [2] http://www.4dsolutions.net/ocn/Jlang.html (Jiving in J -- Iverson himself helped me catch a typo or two) [3] http://cs.brown.edu/~sk/Publications/Papers/Published/sk-teach-pl-post-linna... (anti "paradigms") [4] http://controlroom.blogspot.com/search?q=Clojure (Scala comes up too) [5] Dave's book: http://www.barnesandnoble.com/w/scalable-planning-david-dinucci/1110902186?e...
On Thu, Mar 19, 2015 at 7:38 AM, kirby urner <kirby.urner@gmail.com> wrote:
I'm not one of those who think you need to join warring Camp A (OOP) or warring Camp B (FP) and then express loyalty to one by dissing the other. Rather, play up the strengths of both paradigms (I know Shiriam disputes that OOP is really a "paradigm" but whatever).[3]
I followed your link [3], and that's not my take on what he's saying at all. My reading of the paper is that his central claim is that modern real-world languages don't fall into neat little divisions like "object-oriented" or "functional". Therefore, he claims, the typical "programming paradigms" course in college is out of date, and in need of a renovation, so students can gain an appreciation for how these paradigms blend, rather than thinking of them as separate entities. (He then puts forth his own textbook Programming Languages and Interpretation as a proposed solution). He even cites Python as an example of a language that blurs the lines between paradigms (it has OO, but it doesn't force you to use it, it has some functional constructs, but it's still not typically thought of as a functional programming language, etc.) I'd expect you to mostly agree with that premise.
For me, the thing that has made me lose some enthusiasm for Python was not
even mentioned in the article. For me, the biggest downside is that the language, with its Global Interpreter Lock, lacks a clean solution to teaching concurrency. IMHO, concurrency has become a vital issue, and requires a somewhat different way of thinking about problems. To create the next generation of exceptional programmers, I believe we need to introduce models of concurrent programming much earlier in the curriculum. Almost every recent programming language places a huge emphasis on concurrency (such as Clojure, Scala, Go, F#, Julia, and many others) but none of those are particularly welcoming to beginner programmers. So I'd love to see more educational languages that feature concurrency.
That sounds valid and interesting. How well does Pyret fit that bill I wonder?
Sadly, I don't expect Pyret will address concurrency at all. I learned that Pyret is now strictly a compile-to-javascript language (presumably they feel the language will have better educational reach if you can code it entirely in a web-based IDE). That may end up limiting Pyret's ability to include concurrency features. Thanks for the other interesting comments and links.
On Thu, Mar 19, 2015 at 9:42 PM, Mark Engelberg <mark.engelberg@gmail.com> wrote:
On Thu, Mar 19, 2015 at 7:38 AM, kirby urner <kirby.urner@gmail.com> wrote:
I'm not one of those who think you need to join warring Camp A (OOP) or warring Camp B (FP) and then express loyalty to one by dissing the other. Rather, play up the strengths of both paradigms (I know Shiriam disputes that OOP is really a "paradigm" but whatever).[3]
I followed your link [3], and that's not my take on what he's saying at all. My reading of the paper is that his central claim is that modern real-world languages don't fall into neat little divisions like "object-oriented" or "functional". Therefore, he claims, the typical "programming paradigms" course in college is out of date, and in need of a renovation, so students can gain an appreciation for how these paradigms blend, rather than thinking of them as separate entities. (He then puts forth his own textbook Programming Languages and Interpretation as a proposed solution).
I agree, his paper spells it out much more, where he thinks the "paradigms" notion falls down and betrays us, leading us into sloppy thinking. Before posting that email, I'd only seen a cross comment on math-thinking-l telling us to stop thinking of OOP as a "paradigm". It's a little bit like "races" which I likewise do not believe in, i.e. if you cling to the idea of "pure specimens" of any race, then you get the concept of "mixed" for the impure. It's like the "primary colors" model or RGB, very tempting. As long as we see OO and FP as paradigms, then Python may be cast as a "hybrid" of the two. It's somewhat hard *not* to think that way, with races too, until you read papers which remind us its all in our heads anyway. We circle some attributes, some family resemblances, and make those "hallmark". But the genetics (memetics) is really more complicated than that and not subject to such gross cartoonification. What we also need to consider is the nebulous concept of Community. Why did Smalltalk dissipate? https://youtu.be/YX3iRjKj7C0 Uploaded on May 8, 2009 Robert Martin (Object Mentor, Inc.) "What Killed Smalltalk Could Kill Ruby, Too" I used to think only the grammar / semantics / technical attributes of a language mattered, but others (e.g. one Michael Jennings at Food Not Bombs servings) opened my eyes to the importance of community, governance, PR etc. That the Python community has worked hard on a Code of Conduct for Pycons, a Diversity theme etc. has been beneficial. I think a next step is more literature / documentation not-in-English.
He even cites Python as an example of a language that blurs the lines between paradigms (it has OO, but it doesn't force you to use it, it has some functional constructs, but it's still not typically thought of as a functional programming language, etc.) I'd expect you to mostly agree with that premise.
I think what Shiriam really finds distasteful is the sudden ballooning of Java in popularity, starting with the hype of Java One and all the web stuff we were promised (where are applets today? Hardly used much right?). I was hanging with a C++ coder at the time and could see why he found Java more beautiful and convenient than C++ at least.
For me, the thing that has made me lose some enthusiasm for Python was
not even mentioned in the article. For me, the biggest downside is that the language, with its Global Interpreter Lock, lacks a clean solution to teaching concurrency. IMHO, concurrency has become a vital issue, and requires a somewhat different way of thinking about problems. To create the next generation of exceptional programmers, I believe we need to introduce models of concurrent programming much earlier in the curriculum. Almost every recent programming language places a huge emphasis on concurrency (such as Clojure, Scala, Go, F#, Julia, and many others) but none of those are particularly welcoming to beginner programmers. So I'd love to see more educational languages that feature concurrency.
That sounds valid and interesting. How well does Pyret fit that bill I wonder?
Sadly, I don't expect Pyret will address concurrency at all. I learned that Pyret is now strictly a compile-to-javascript language (presumably they feel the language will have better educational reach if you can code it entirely in a web-based IDE). That may end up limiting Pyret's ability to include concurrency features.
Thanks for the other interesting comments and links.
Interesting, didn't know that. When Mark Shuttleworth summoned (asked politely, paid some ways, including mine) a bunch of us to England for a pow wow on the future of education in South Africa, Alan Kay, the Smalltalk guy, showed up all burning with admiration for JavaScript.[1] He'd just done a Logo in that language. He liked Python too. We had many solid hours of meetings. Now the RSA is lightyears ahead, building Chappie and all. [2] :-D Another interesting language that leverage Python you may know about: Hy https://hy.readthedocs.org/en/latest/tutorial.html Thanks for another interesting thread, maybe more will chime in on this one. Kirby [0] http://mybizmo.blogspot.com/2012/10/omsi-science-on-race.html [1] http://controlroom.blogspot.com/2006/04/shuttleworth-summit-day-two.html [2] Chappie: http://worldgame.blogspot.com/2015/03/chappie-movie-review.html
This evening I had an interesting conversation with a very determined 10-year old boy who wants to learn programming in Java and nothing but Java. I told him that I recommend Python as a first programing language, because learning Python is easier. But he was adamant. It's Java or nothing. Why? Minecraft is implemented in Java. That made Java the ultimate in coolness to him. No "risk-averse bureaucratic" thinking there, just a willingness to do hard things to get what he wanted. So I told him, go for it, more power to you, and offered my assistance. What else could I do? :) In the face of determination like that, it's lead, follow, or get out of the way... David H On Saturday, March 14, 2015 5:27pm, "Mark Engelberg" <mark.engelberg@gmail.com> said: On Fri, Mar 13, 2015 at 7:33 AM, David MacQuigg <[ macquigg@ece.arizona.edu ]( mailto:macquigg@ece.arizona.edu )> wrote: The first thing that got my attention was the banner text "Choosing Python is the modern equivalent of the old adage 'nobody ever got fired for choosing IBM'". If I were an unimaginative, risk-averse bureaucrat, just wanting to run with the herd, the choice would be Java, not Python. The only clarification I can find is in the conclusion of the article where we learn that Python is "blandly conventional", just the latest crest in the "waves of fashion" (Pascal, C++, Java, Python, Scratch). Odd that Ruby is not mentioned anywhere. Remember, this article is specifically about language choices for programming education. I agree that Java is still the default choice for a risk-averse bureaucrat in industry, but in education, Python has become the most popular, default choice (that's sort of the whole point of the article). In industry, many managers don't feel the need to look beyond Java to find more compelling options (even those that might boost productivity); similarly, at this point, many educators don't feel the need to look beyond Python to see if there are more compelling options (even those that might provide a better educational experience). That's what I think the author's point is about Python being "blandly conventional". There's no reason to think that Python is the pinnacle of educational languages. It wasn't designed to be an educational language, so it should be possible to do better. But it happens to be a pretty good choice for education, good enough that many people have stopped looking for better. Ruby isn't mentioned because it never made significant waves in the educational community. Remember, the article is just about educational language choices, not fashionable languages in general. The bulk of the article is discussion of Python's "weaknesses": 1) Creating non-trivial data structures is onerous. 2) Limited support for testing. 3) Lack of static types. 4) Difficult transition to other languages because the syntax is quite different. Show me some real-world examples of a data structure or test setup I can't do better in Python. Python's doctest is an excellent methodology for teaching Test-Driven Design, or even just teaching basic Python (see [ pykata.org ]( http://pykata.org/ )). I think the best way to understand these criticisms is to take a look at the language Pyret ([ pyret.org ]( http://pyret.org )), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language. In Python you have a couple options to build structured data. You can use the object system, but that's a little heavyweight and clunky for beginners. You can just use dictionaries with the relevant entries, but beginners often don't have the discipline to mentally keep track of many different types of objects that are all dictionaries with different combinations of entries. This gets especially problematic when you get to recursive data structures like binary trees. It's pretty tough to teach this well in Python with dictionaries, so teaching this usually gets delayed until the object system has been taught, and then all your functionality that operates on the trees are generally written as methods split between the branch and leaf classes. This is tough for students because the code for a given function isn't all in one place, it is spread out among the two different types of classes. Contrast this with Pyret's approach to structured data and recursive data structures. As far as testing goes, Python's biggest limitation is that structured data created with dictionaries or objects are mutable data structures. It is fundamentally more difficult to test mutable data structures because you can't use a built-in notion of structural equality. So all tests must be in the form of setting up an object, calling functions/methods which mutate it, and then testing various properties of the mutated object. This is onerous for beginners, and very hard to get them to do this with any kind of discipline. Testing is radically more simple in languages that offer a rich set of immutable data structures and an easy way to create new immutable data structures that automatically come with a structural equality comparison. So it's easier to teach a "tests first" approach by starting with immutable data structures and moving to mutable data structures after students are more mature in their programming experiences. Doctests are great for regression testing, e.g., copying and pasting an interactive transcript into the actual code, but are not very easy for students to write the tests ahead of writing their code, especially for complex data structures or testing that certain errors are raised -- it is hard to figure out ahead of time how that kind of stuff is going to print. I understand the complaint about data types, but I would not give up the advantages of dynamic typing for the few projects where I really need the efficiency of static types. Write first in Python, then insert some C code where testing shows that it is actually needed. I vastly prefer dynamic typing over static typing in my own code. But this is about education. We have a responsibility to teach students both, so a language that lets you gradually transition from dynamic typing to static typing is preferable (in education) to one that doesn't. This isn't about bashing Python; we all recognize that Python is one of the more compelling alternatives right now in programming education. But let's not settle for "good enough". There's value to diagnosing the weaknesses of Python so we can continue to build and look for even better options.
http://pt.slideshare.net/rdonkin/minecraft-in-500-lines-with-pyglet-pycon-uk... On Mar 22, 2015, at 9:23 PM, David Handy <david@handysoftware.com<mailto:david@handysoftware.com>> wrote: This evening I had an interesting conversation with a very determined 10-year old boy who wants to learn programming in Java and nothing but Java. I told him that I recommend Python as a first programing language, because learning Python is easier. But he was adamant. It's Java or nothing. Why? Minecraft is implemented in Java. That made Java the ultimate in coolness to him. No "risk-averse bureaucratic" thinking there, just a willingness to do hard things to get what he wanted. So I told him, go for it, more power to you, and offered my assistance. What else could I do? :) In the face of determination like that, it's lead, follow, or get out of the way... David H On Saturday, March 14, 2015 5:27pm, "Mark Engelberg" <mark.engelberg@gmail.com<mailto:mark.engelberg@gmail.com>> said: On Fri, Mar 13, 2015 at 7:33 AM, David MacQuigg <macquigg@ece.arizona.edu<mailto:macquigg@ece.arizona.edu>> wrote: The first thing that got my attention was the banner text "Choosing Python is the modern equivalent of the old adage 'nobody ever got fired for choosing IBM'". If I were an unimaginative, risk-averse bureaucrat, just wanting to run with the herd, the choice would be Java, not Python. The only clarification I can find is in the conclusion of the article where we learn that Python is "blandly conventional", just the latest crest in the "waves of fashion" (Pascal, C++, Java, Python, Scratch). Odd that Ruby is not mentioned anywhere. Remember, this article is specifically about language choices for programming education. I agree that Java is still the default choice for a risk-averse bureaucrat in industry, but in education, Python has become the most popular, default choice (that's sort of the whole point of the article). In industry, many managers don't feel the need to look beyond Java to find more compelling options (even those that might boost productivity); similarly, at this point, many educators don't feel the need to look beyond Python to see if there are more compelling options (even those that might provide a better educational experience). That's what I think the author's point is about Python being "blandly conventional". There's no reason to think that Python is the pinnacle of educational languages. It wasn't designed to be an educational language, so it should be possible to do better. But it happens to be a pretty good choice for education, good enough that many people have stopped looking for better. Ruby isn't mentioned because it never made significant waves in the educational community. Remember, the article is just about educational language choices, not fashionable languages in general. The bulk of the article is discussion of Python's "weaknesses": 1) Creating non-trivial data structures is onerous. 2) Limited support for testing. 3) Lack of static types. 4) Difficult transition to other languages because the syntax is quite different. Show me some real-world examples of a data structure or test setup I can't do better in Python. Python's doctest is an excellent methodology for teaching Test-Driven Design, or even just teaching basic Python (see pykata.org<http://pykata.org/>). I think the best way to understand these criticisms is to take a look at the language Pyret (pyret.org<http://pyret.org/>), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language. In Python you have a couple options to build structured data. You can use the object system, but that's a little heavyweight and clunky for beginners. You can just use dictionaries with the relevant entries, but beginners often don't have the discipline to mentally keep track of many different types of objects that are all dictionaries with different combinations of entries. This gets especially problematic when you get to recursive data structures like binary trees. It's pretty tough to teach this well in Python with dictionaries, so teaching this usually gets delayed until the object system has been taught, and then all your functionality that operates on the trees are generally written as methods split between the branch and leaf classes. This is tough for students because the code for a given function isn't all in one place, it is spread out among the two different types of classes. Contrast this with Pyret's approach to structured data and recursive data structures. As far as testing goes, Python's biggest limitation is that structured data created with dictionaries or objects are mutable data structures. It is fundamentally more difficult to test mutable data structures because you can't use a built-in notion of structural equality. So all tests must be in the form of setting up an object, calling functions/methods which mutate it, and then testing various properties of the mutated object. This is onerous for beginners, and very hard to get them to do this with any kind of discipline. Testing is radically more simple in languages that offer a rich set of immutable data structures and an easy way to create new immutable data structures that automatically come with a structural equality comparison. So it's easier to teach a "tests first" approach by starting with immutable data structures and moving to mutable data structures after students are more mature in their programming experiences. Doctests are great for regression testing, e.g., copying and pasting an interactive transcript into the actual code, but are not very easy for students to write the tests ahead of writing their code, especially for complex data structures or testing that certain errors are raised -- it is hard to figure out ahead of time how that kind of stuff is going to print. I understand the complaint about data types, but I would not give up the advantages of dynamic typing for the few projects where I really need the efficiency of static types. Write first in Python, then insert some C code where testing shows that it is actually needed. I vastly prefer dynamic typing over static typing in my own code. But this is about education. We have a responsibility to teach students both, so a language that lets you gradually transition from dynamic typing to static typing is preferable (in education) to one that doesn't. This isn't about bashing Python; we all recognize that Python is one of the more compelling alternatives right now in programming education. But let's not settle for "good enough". There's value to diagnosing the weaknesses of Python so we can continue to build and look for even better options. _______________________________________________ Edu-sig mailing list Edu-sig@python.org<mailto:Edu-sig@python.org> https://mail.python.org/mailman/listinfo/edu-sig
On Sun, Mar 22, 2015 at 7:23 PM, David Handy <david@handysoftware.com> wrote:
This evening I had an interesting conversation with a very determined 10-year old boy who wants to learn programming in Java and nothing but Java. I told him that I recommend Python as a first programing language, because learning Python is easier. But he was adamant. It's Java or nothing. Why? Minecraft is implemented in Java. That made Java the ultimate in coolness to him. No "risk-averse bureaucratic" thinking there, just a willingness to do hard things to get what he wanted.
So I told him, go for it, more power to you, and offered my assistance. What else could I do? :) In the face of determination like that, it's lead, follow, or get out of the way...
When I was an undergrad at Caltech, we had no good courses in programming or computer science, and I really wanted to understand computers. So I dedicated most of one summer to slugging through several feet of IBM manuals. My first "computer language" was JCL!! It was a total waste. I lost interest in programming for many years. Same thing happened to my interest in literature, after a string of really bad teachers in high school. Give that 10-year old plenty of encouragement, but be ready to catch him when he falls. Write the Java for him, if necessary, but then show him the equivalent in Python.
Give that 10-year old plenty of encouragement, but be ready to catch him when he falls. Write the Java for him, if necessary, but then show him the equivalent in Python.
Having the motive to master Minecraft is a good reminder that a lot of us tackle a language as a means to an end not as an end in itself. Saying "Python is easier" is no consolation, like saying, "why not Sanskrit, it's easier than Czech" when, in fact, you're moving to Prague? A lot of us "like programming" and "enjoy learning languages" but lets remember our own personal story is just that. Some of us really do like to argue and/or debate whereas others just see that as being disagreeable. Finding good friends in the Java / Minecraft community, true peers who enjoy the same projects, might possibly be a critical step, though not knowing the individual in question, that could only be a guess. Perhaps those friendships have already been made. I had breakfast with a former Python student who was still overseas when we met online. He's a computer science student at a local university these days and is using C++. Although good at Python and steeped in SQL, he's not disrespectful of what C++ does for us in this world: a lot. Python extends through these languages i.e. is made the richer for them. Kirby
http://www.raspberrypi.org/learning/getting-started-with-minecraft-pi/ http://www.raspberrypi-spy.co.uk/2014/06/building-a-castle-in-minecraft-with... Francois El Mar 22, 2015, a las 10:23 PM, "David Handy" <david@handysoftware.com> escribió:
This evening I had an interesting conversation with a very determined 10-year old boy who wants to learn programming in Java and nothing but Java. I told him that I recommend Python as a first programing language, because learning Python is easier. But he was adamant. It's Java or nothing. Why? Minecraft is implemented in Java. That made Java the ultimate in coolness to him. No "risk-averse bureaucratic" thinking there, just a willingness to do hard things to get what he wanted.
So I told him, go for it, more power to you, and offered my assistance. What else could I do? :) In the face of determination like that, it's lead, follow, or get out of the way...
David H
On Saturday, March 14, 2015 5:27pm, "Mark Engelberg" <mark.engelberg@gmail.com> said:
On Fri, Mar 13, 2015 at 7:33 AM, David MacQuigg <macquigg@ece.arizona.edu> wrote: The first thing that got my attention was the banner text "Choosing Python is the modern equivalent of the old adage 'nobody ever got fired for choosing IBM'". If I were an unimaginative, risk-averse bureaucrat, just wanting to run with the herd, the choice would be Java, not Python. The only clarification I can find is in the conclusion of the article where we learn that Python is "blandly conventional", just the latest crest in the "waves of fashion" (Pascal, C++, Java, Python, Scratch). Odd that Ruby is not mentioned anywhere. Remember, this article is specifically about language choices for programming education. I agree that Java is still the default choice for a risk-averse bureaucrat in industry, but in education, Python has become the most popular, default choice (that's sort of the whole point of the article). In industry, many managers don't feel the need to look beyond Java to find more compelling options (even those that might boost productivity); similarly, at this point, many educators don't feel the need to look beyond Python to see if there are more compelling options (even those that might provide a better educational experience). That's what I think the author's point is about Python being "blandly conventional". There's no reason to think that Python is the pinnacle of educational languages. It wasn't designed to be an educational language, so it should be possible to do better. But it happens to be a pretty good choice for education, good enough that many people have stopped looking for better. Ruby isn't mentioned because it never made significant waves in the educational community. Remember, the article is just about educational language choices, not fashionable languages in general.
The bulk of the article is discussion of Python's "weaknesses": 1) Creating non-trivial data structures is onerous. 2) Limited support for testing. 3) Lack of static types. 4) Difficult transition to other languages because the syntax is quite different. Show me some real-world examples of a data structure or test setup I can't do better in Python. Python's doctest is an excellent methodology for teaching Test-Driven Design, or even just teaching basic Python (see pykata.org). I think the best way to understand these criticisms is to take a look at the language Pyret (pyret.org), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language.
In Python you have a couple options to build structured data. You can use the object system, but that's a little heavyweight and clunky for beginners. You can just use dictionaries with the relevant entries, but beginners often don't have the discipline to mentally keep track of many different types of objects that are all dictionaries with different combinations of entries. This gets especially problematic when you get to recursive data structures like binary trees. It's pretty tough to teach this well in Python with dictionaries, so teaching this usually gets delayed until the object system has been taught, and then all your functionality that operates on the trees are generally written as methods split between the branch and leaf classes. This is tough for students because the code for a given function isn't all in one place, it is spread out among the two different types of classes. Contrast this with Pyret's approach to structured data and recursive data structures. As far as testing goes, Python's biggest limitation is that structured data created with dictionaries or objects are mutable data structures. It is fundamentally more difficult to test mutable data structures because you can't use a built-in notion of structural equality. So all tests must be in the form of setting up an object, calling functions/methods which mutate it, and then testing various properties of the mutated object. This is onerous for beginners, and very hard to get them to do this with any kind of discipline. Testing is radically more simple in languages that offer a rich set of immutable data structures and an easy way to create new immutable data structures that automatically come with a structural equality comparison. So it's easier to teach a "tests first" approach by starting with immutable data structures and moving to mutable data structures after students are more mature in their programming experiences. Doctests are great for regression testing, e.g., copying and pasting an interactive transcript into the actual code, but are not very easy for students to write the tests ahead of writing their code, especially for complex data structures or testing that certain errors are raised -- it is hard to figure out ahead of time how that kind of stuff is going to print.
I understand the complaint about data types, but I would not give up the advantages of dynamic typing for the few projects where I really need the efficiency of static types. Write first in Python, then insert some C code where testing shows that it is actually needed. I vastly prefer dynamic typing over static typing in my own code. But this is about education. We have a responsibility to teach students both, so a language that lets you gradually transition from dynamic typing to static typing is preferable (in education) to one that doesn't. This isn't about bashing Python; we all recognize that Python is one of the more compelling alternatives right now in programming education. But let's not settle for "good enough". There's value to diagnosing the weaknesses of Python so we can continue to build and look for even better options. _______________________________________________ Edu-sig mailing list Edu-sig@python.org https://mail.python.org/mailman/listinfo/edu-sig
Thank you all for the links pointing to Minecraft on the Raspberry Pi and articles on how to control it with Python. That's not something I've tried myself, but I have passed the links along to my friend. David H On Monday, March 23, 2015 7:41pm, "Francois Dion" <francois.dion@gmail.com> said: [ http://www.raspberrypi.org/learning/getting-started-with-minecraft-pi/ ]( http://www.raspberrypi.org/learning/getting-started-with-minecraft-pi/ ) [ http://www.raspberrypi-spy.co.uk/2014/06/building-a-castle-in-minecraft-with... ]( http://www.raspberrypi-spy.co.uk/2014/06/building-a-castle-in-minecraft-with... ) Francois El Mar 22, 2015, a las 10:23 PM, "David Handy" <[ david@handysoftware.com ]( mailto:david@handysoftware.com )> escribió: This evening I had an interesting conversation with a very determined 10-year old boy who wants to learn programming in Java and nothing but Java. I told him that I recommend Python as a first programing language, because learning Python is easier. But he was adamant. It's Java or nothing. Why? Minecraft is implemented in Java. That made Java the ultimate in coolness to him. No "risk-averse bureaucratic" thinking there, just a willingness to do hard things to get what he wanted. So I told him, go for it, more power to you, and offered my assistance. What else could I do? :) In the face of determination like that, it's lead, follow, or get out of the way... David H On Saturday, March 14, 2015 5:27pm, "Mark Engelberg" <[ mark.engelberg@gmail.com ]( mailto:mark.engelberg@gmail.com )> said: On Fri, Mar 13, 2015 at 7:33 AM, David MacQuigg <[ macquigg@ece.arizona.edu ]( mailto:macquigg@ece.arizona.edu )> wrote: The first thing that got my attention was the banner text "Choosing Python is the modern equivalent of the old adage 'nobody ever got fired for choosing IBM'". If I were an unimaginative, risk-averse bureaucrat, just wanting to run with the herd, the choice would be Java, not Python. The only clarification I can find is in the conclusion of the article where we learn that Python is "blandly conventional", just the latest crest in the "waves of fashion" (Pascal, C++, Java, Python, Scratch). Odd that Ruby is not mentioned anywhere. Remember, this article is specifically about language choices for programming education. I agree that Java is still the default choice for a risk-averse bureaucrat in industry, but in education, Python has become the most popular, default choice (that's sort of the whole point of the article). In industry, many managers don't feel the need to look beyond Java to find more compelling options (even those that might boost productivity); similarly, at this point, many educators don't feel the need to look beyond Python to see if there are more compelling options (even those that might provide a better educational experience). That's what I think the author's point is about Python being "blandly conventional". There's no reason to think that Python is the pinnacle of educational languages. It wasn't designed to be an educational language, so it should be possible to do better. But it happens to be a pretty good choice for education, good enough that many people have stopped looking for better. Ruby isn't mentioned because it never made significant waves in the educational community. Remember, the article is just about educational language choices, not fashionable languages in general. The bulk of the article is discussion of Python's "weaknesses": 1) Creating non-trivial data structures is onerous. 2) Limited support for testing. 3) Lack of static types. 4) Difficult transition to other languages because the syntax is quite different. Show me some real-world examples of a data structure or test setup I can't do better in Python. Python's doctest is an excellent methodology for teaching Test-Driven Design, or even just teaching basic Python (see [ pykata.org ]( http://pykata.org/ )). I think the best way to understand these criticisms is to take a look at the language Pyret ([ pyret.org ]( http://pyret.org )), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language. In Python you have a couple options to build structured data. You can use the object system, but that's a little heavyweight and clunky for beginners. You can just use dictionaries with the relevant entries, but beginners often don't have the discipline to mentally keep track of many different types of objects that are all dictionaries with different combinations of entries. This gets especially problematic when you get to recursive data structures like binary trees. It's pretty tough to teach this well in Python with dictionaries, so teaching this usually gets delayed until the object system has been taught, and then all your functionality that operates on the trees are generally written as methods split between the branch and leaf classes. This is tough for students because the code for a given function isn't all in one place, it is spread out among the two different types of classes. Contrast this with Pyret's approach to structured data and recursive data structures. As far as testing goes, Python's biggest limitation is that structured data created with dictionaries or objects are mutable data structures. It is fundamentally more difficult to test mutable data structures because you can't use a built-in notion of structural equality. So all tests must be in the form of setting up an object, calling functions/methods which mutate it, and then testing various properties of the mutated object. This is onerous for beginners, and very hard to get them to do this with any kind of discipline. Testing is radically more simple in languages that offer a rich set of immutable data structures and an easy way to create new immutable data structures that automatically come with a structural equality comparison. So it's easier to teach a "tests first" approach by starting with immutable data structures and moving to mutable data structures after students are more mature in their programming experiences. Doctests are great for regression testing, e.g., copying and pasting an interactive transcript into the actual code, but are not very easy for students to write the tests ahead of writing their code, especially for complex data structures or testing that certain errors are raised -- it is hard to figure out ahead of time how that kind of stuff is going to print. I understand the complaint about data types, but I would not give up the advantages of dynamic typing for the few projects where I really need the efficiency of static types. Write first in Python, then insert some C code where testing shows that it is actually needed. I vastly prefer dynamic typing over static typing in my own code. But this is about education. We have a responsibility to teach students both, so a language that lets you gradually transition from dynamic typing to static typing is preferable (in education) to one that doesn't. This isn't about bashing Python; we all recognize that Python is one of the more compelling alternatives right now in programming education. But let's not settle for "good enough". There's value to diagnosing the weaknesses of Python so we can continue to build and look for even better options. _______________________________________________ Edu-sig mailing list [ Edu-sig@python.org ]( mailto:Edu-sig@python.org ) [ https://mail.python.org/mailman/listinfo/edu-sig ]( https://mail.python.org/mailman/listinfo/edu-sig )
Yes many thanks for the Minecraft with Pi link. @psf_snake tweeted about it too today -- and re a 111 line python chess engine a student pointed me at. Kirby
participants (7)
-
David Handy -
David MacQuigg -
DiPierro, Massimo -
Francois Dion -
kirby urner -
Kirby Urner -
Mark Engelberg