Advice on learning Python efficiently
simplydjango.com
simplydjango.com
I often suggest the read-a-chapter-write-a-program-based-on-it route, just to get the practice that is really important, and to solidify some intuition as to what the machine (whether interpreter or bare metal) is doing, and to make writing future programs easier.
Side note: While I definitely applaud the idea of trying to create a language that is geared towards beginners and good for learning on, I don't know if I can get behind recommending such a language that is still under development being suggested to beginners.
Then again, I'd consider recommending lisps to beginners (if not python), so maybe I'm not the most credible source
I second this. Especially when python itself is very beginner friendly.
IMHO the best advice on learning a skill is just do some projects with it. I am not exactly sure, which should come first, the 1. or the 2. point made in the article.
Though I would dare to say the 2. point is more important.
By doing python projects first you familiarize with it and then if you are still on - you should read zen of python, pep8, etc..
Would you mind recommending some projects for a python beginner?
With the web you can move to things like an address book, todo list, message board (regular or reddit/hn clone)...
For example, I once tried to learn Haskell and I started from little exercises (https://wiki.haskell.org/H-99:_Ninety-Nine_Haskell_Problems)... I got familiar with syntax and basic concepts, but I was dissatisfied both with the easy, abstract questions and with the simplistic, inefficient answers using basic standard library features that are more or less the same in any language. What was "real" Haskell code like? I expected dealing with serious libraries, memory management etc. would be uglier, more difficult and more cumbersome than exceptionally terse toy examples.
So I attempted something not merely useful and small, but with a well defined practical objective, depending on external standards, requiring production quality libraries and with performance challenges: converting the metadata dump from MAME (a nearly 200MB XML file) into an easy to use SQLite database.
The task was a good test of programming language productivity because, having already used ElementTree and APSW I was sure I could write it in Python quite easily. (And I did; a complete Python implementation, able to roundtrip data back to the XML format for testing purposes, took me less time than an aborted Haskell attempt that could parse a dumb document tree using a ridiculous amount of memory.)
This project allowed me to discover many things about Haskell that are not found in enthusiast-written tutorials: the mess of incompatible and undocumented libraries, the impracticality of basic language design decisions (text handling, lack of namespaces leading to name conflicts, etc.) and my profound disgust for the commonplace syntactic tricks.
Of course, a similar challenge for Python is likely to have a better outcome: learning the difference between good and really good libraries, finding a use for many language features, remembering useful idioms nd design patterns, etc.
After doing some of https://javascript30.com/ I want the "30 day challenges" style tutorials in every language - I love it. I'm not sure how well it works for long term learning but it's really helped with my motivation.
I'd also add "concise" to the list of required traits for a good language spec. If you don't believe me that's important, go check out the C++ specification. IIRC it contains some 50 pages of rules on how to choose implementations of an overloaded function.
the learnxinyminutes stuff is sometimes good. It'd be nice if there was a resource that taught languages from the perspective of already knowing another (any) language in that same family.
Show me definitions, modules, packages, namespacing, whatever, and get out of my way.
I think there are some books that really get it right though, that show you how to do stuff, but also try to get out of your way. Some examples (in order of adherence to this point, to the best of my ability):
- Practical Common Lisp
- Learn You a Haskell For Great Good
- Clojure For The Brave and True
Learning Perl (the llama book) was great for that. At first, I would think that I understood just from reading the chapter, but doing the exercises at the end of each chapter made me actually learn it.
Also, MIT switched from scheme to python.
\tangent I agree with your approach of mixing theory and practice. So what's the best way to learn fluid simulation? It's discouraging spending so long on maths without the gratification of Something Actually Working.
All these jobs definitely involved a very basic understanding of programming, but I had no understanding of many important fundamental programming concepts, and had created very few programs bigger than a 1-page script.
It was only when I started to learn Python, and then C (to write Python extensions), that everything really clicked. Something about Python made it so much easier than PHP or JavaScript for me. I think Python's relative lack of glyphs, brackets, and other "syntactic noise" (my opinion only) made it much easier for me personally to grasp big picture ideas. Python also prepared me for learning C to a pretty good level (with much help from the K&R book).
These two, in turn, gave me a good foundation for branching out into other languages, eventually including functional programming languages.
But Python was with no doubt the turning point for me, and even though I do little Python work these days (ironically, I'm back to JS but at a much higher level than in the 90s), I'll always be grateful for Python.
If you've struggled with programming and haven't given Python a shot, give it a try! If that doesn't work, maybe try Pyret like this post advises (once it's stable), or maybe some lisp such as Clojure. I also know some mathematicians who struggled initially with imperative programming but then thrived with Haskell. Point is, we think in different ways, so keep trying different approaches until something sticks.
So true, great advice. You have to experiment and find out what works for yourself.
I've hung around on a number of support chat rooms for languages / libraries for a few years, and tons of the problems we hear about are things that nearly any book would've made plain. As further evidence, 99% of Stack Overflow is filled with this stuff.
In my experience, skipping the dry stuff to get started faster tends to lead to poor mastery of a system. You can absolutely waste time on the dry stuff - don't read a 1000 page book when 100 will do (or ever; huge books are usually awful) - but the details very often matter in the long run when you start doing anything not in a cookbook / tutorial. Yes, you can always go back and read it later, but very few do so. Investing a day or two in a detailed book up-front isn't that much time.
How about just learning Python instead of learning a toy language and then having to learn Python anyway?
Also, Python may feel like a small language at times, but it is really quite large and complex. This can be seem by imagining a beginners perspective when Googling for help with a simple list operation. The inevitable Stack Overflow answer will almost certainly use a comprehension. I would argue that Pyret is actually fundamentally less complex than than Python.
As always, the biggest issues are your goals, constraints, and resources. If you can afford to spend time in a language optimized for education, that is fantastic. If you can't afford that time, python starts to look like a good trade off relative to the languages with reasonable job prospects.
* It doesn't make me an expert, but I do teach programming for a living. We use happily use python for introductory content and server-side web content, but I can easily see Pyret as a great option for an educational offering with different constraints than mine.
I also teach programming for a living, and, for instance, I usually have a hard time explaining to students what a for loop over a range() means for having a index. The problem is that there are a lot of things going on behind a for-each (which is what the for loop on Python does) and it is hard to explain that to newcomers. On the other hand, for loops in languages like C are simpler to explain to newcomers, as there isn't much hidden from you, and you don't have many alternatives for iterating on an array.
I would say that the higher-level benefits of Python are best understood when you have some experience with lower-level languages such as C/C++ or Java. For students, if they have time, I would say that they would benefit pedagogically by learning a simpler language with less functionalities. If not, I would say learn Python, but expect to not understand everything at first.
there are no stupid questions on #python on freenode IRC, and many many helpful people to answer questions in realtime
What sets the PLTgroup apart, in my mind, is that it tends to row in the same direction at the low level. This has allowed it to create a robust platform upon which tools (particularly in the form of languages) can be built. Pyret is an example of this. Adding a language with the offside rule to the ecosystem doesn't cause anyone offense or raging flame wars or fuck-you forking. Imagine a PEP to add Lisp syntax to Python.
Instead, Pyret just gets rolled up into the pedagogy that is described in How To Design Programs because Pyret fits with the philosophy of building teaching languages for the purposes of teaching. Other PLTgroup languages range from Beginning Student Language (a simplified lisp) up through Racklog (a lisp implementation of Prolog's logic programming model) and pure insanity like Scribble which introduces a documentation phase to the compilation. Racket even ships with an Algol60 implementation.
At the core, the important philosophical idea is that learning programming is not learning a language. In the age of Googling into StackOverflow, that's even more the case as far as I can see.
Python's use of semantic white space in the form of indentation is sometimes referred to as the 'offside rule'.
I also agree with you that math, CS and science education is really messed up, especially in my country.
Here's an old gem of a talk from a fantastic CS educator, https://www.youtube.com/watch?v=efhh0Cf6sT8, that I found some years ago.
Curricula in Pyret focus on building games using concepts from math, or interactive simulations using concepts from physics, or data analyses using concepts from working with spreadsheets.
I agree that a purely "CS concepts"-based approach is dry and ineffective for a huge portion of students. That's why applications are so critical, and why we build things like tables (https://twitter.com/PyretLang/status/773605473824145408) into the language, so we can give students real-world tasks to do right away.
We happen to also have carefully designed the language to allow us to teach these applications along with a rigorous programming style. Students write _examples_ that get them ready to understand automated testing, they write _contracts_ that teach them about type-based interfaces, they write _data definitions_ that teach them about structured data, and so on. But it's always in service of an application.
So I very much agree that a purely "bottom up" CS-concepts-only approach has issues.
But I see your point and I did struggle with whether to include it or not. I think me wanting to share the great work I see Shriram Krishnamurthi (https://cs.brown.edu/~sk/) and others (Matthias Felleisen, http://www.ccs.neu.edu/home/matthias/ for another example) are doing and have been doing for decades to advance Computer Science education and really tackle the tough problems pushed me to include it in the end.
I'm just a fan of their work and this post felt like a great time to mention it.
However, I do share your feelings that most people should just jump in and learn Python as their first language. It's easy to get started, batteries included and there's plenty of resources and people to help them if they get stuck.
Python used to be easy to learn. It isn't anymore. It may be a better language for all the feature additions, but it isn't easy to learn anymore and I no longer recommend it for that purpose. (I don't have a recommendation at the moment.)
Compared to C++, C# and Java, Python is still MUCH easier to learn. Python and Ruby are the easier languages to learn. I have to agree with the other commenter, why learn a toy language only to later have to learn a real one? That is a waste of time.
From a student or instructor's point of view, it is serving a lot of the same ends as some of Python's choices:
Toplevel code runs as a script without ceremony, the default behavior doesn't statically check types but is conservative about coercing types and overloading operators (e.g. "a" + 5 is an error), integers promote to bignums by default (though Pyret supports exact rational bignums as well).
Pyret supports docstrings explicitly, and examples/check blocks have similarities to Python's doctest.
Fields of ADT instances can be accessed simply with "." (in contrast to OCaml or other functional languages), and methods close over self on dot-access as they do in Python.
Some of these things are also true of Ruby, so that's a fair comparison as well. And things like "data", and the gradual type-checking facilities, are clearly coming from other sources (though Python is moving in a gradually-typed direction as well).
I know we were thinking about Python in particular when we made a lot these decisions, so I think it's a fair characterization, though Python is one of several inspirations.
For some perspective, when teaching Pyret to total beginners, we start with arithmetic and calls to library functions, then build up to function definitions and examples. At that point, there's just a handful of syntactic constructs to consider, and they are nearly identical to Python.
Things like "data" and "cases" don't come till later, and do come with more overhead, but also are introduced to students who already have some "finger-feel" with the language. Python has its own overhead with "class" for defining structured data at a similar point, including things like "self" and "__init__".
def square(n):
return n * n
fun square(n :: Number) -> Number:
n * n
end
fun square(n):
n * n
end
To zoom in for a second: in my experience teaching, the simplicity of the outdent as a mechanism for ending a control structure is a light-bulb moment for many people. I don't think that adding "end" is helpful for this segment of the population.
And so it is with `where`, which seems to shoehorn a BDD / Rspec'ish approach which, while typical of some of the best Ruby out there, is not typical of a Python library.
Again, this approach may be great for some people, but I'll bet that it won't be great for others.
I didn't realize this wasn't for beginners until I got to this section and read that his first application was a whitespace interpreter.
Personally, coming from Ruby, I learned Python via https://learnxinyminutes.com/docs/python/ after stumbling a bit on the Python 3 import syntax, which I came to love.
My biggest complaint about python is how easy it is to learn (heh). It takes so little effort to write a script, so it feels deceptively easy to write great python. After all, as long as it works, who cares right?
I care. Your colleagues care. Your users care. Python is an object oriented language, use it as such.
This X 1000. Some Python candidates declare themselves professionals when their code is unsuitable for production.
If you're gonna spend many thousands of hours using a language, don't use initial learn-time as the one thing to optimize for!
That reminds me of this wonderful talk by Rich Hickey called Simple Made Easy, https://www.infoq.com/presentations/Simple-Made-Easy.
Stating "Learn python efficiently" is one thing, but stating "My advice on learning Python efficiently" is another entirely different thing. One is a statement of fact, another is just yet another opinion.
Accepting clickbait articles degrades the quality of a news aggregator.
Thanks to whoever fixed it.