Python has brought computer programming to a vast new audience
economist.com
economist.com
If a story has had significant attention in the last year or so, we kill reposts as duplicates. If not, a small number of reposts is ok.
252 points/261 comments probably qualifies as "significant attention".
In college, Processing.js was what I used in the Intro to Programming class, which was fun, but like Logo, not powerful enough. Java (why do I have to type so much?) and C (why do I have to worry about memory allocation?) for the intermediate courses. But I never really enjoyed a language until one of my upper division classes had us work in Python.
Finally, a reasonable language. Easy to pick up, but very powerful once mastered. Easy to read, quick and concise to write, thanks to the syntax and interpreter. A massive amount of open sources packages to choose from, for nearly any programming task you can think of. A sane blend of functional, object-oriented, and procedural features.
Python was the language that made me actually enjoy programming. Thanks GVR!
It wasn't until many years later that I touched lisp. I had seen it mocked before, but never used it. That said, I have since found that same sort of joy in programming that you seem to be describing. Only, instead of a "powerful once mastered" feel, I get more and more of "I remember finally grokking this idea in other languages, it was really this easy!?"
Python, in all of this, has fallen by the wayside in a way that I'm just annoyed by all of its claims. Notebooks don't make it any easier. Much of their charm is in areas that I feel tools I was able to use in college easily touched. Matlab is, in particular, an amazing program. Once you get used to it.
I'll give python the credit of being where everyone is today. There is a lot to be said for that. The language doesn't spark any joy for me, though. :(
Could you clarify what you mean here?
Python is claiming to be easier to read and faster to develop. Often (always?), without data. Notebooks are pushing something close to a live coding session, but having to recreate so much to get there.
And if you had ever used other environments, it is frustrating to see people lauding and making progress and tons of press, all while pushing bad practices.
That is, it isn't that nobody could or had done these things. If you care about productionizing, you just need a more formalized environment. You needa more pluggable setup. Just hitting "play all" again on a notebook is good, but is a very low bar. Or puts more effort on parts that don't matter. Often both.
So, I meant all of that at a personal level. I feel like the entire industry is trying to sell me something on faith. Or appeals to the impressive products of people that likely could have used any tool. It hits many of my "don't trust me" vibes.
As someone who came to it from Ruby, that is often my question about Python :)
After Java, CPP and Node, Python looks to me as the greatest of all. Syntax is just comes to you and usually does not produce problems. And Python even right now has so many areas of application, and does it without much compromises, that I wonder why would I want to change anything.
Anyway, long winded answer that i think i prefer node after a lifetime of python
I find the exprience working with TypeScript and Python/Mypy very similiar. (in VSCode)
> Async in python has a history of being weird, from twisted, to yield from, and finally to async/await (which still has some issues, but is much better). I thought javascripts "callback hell" actually made sense, promises made it easier, and now async/await which works great.
Both ended up with async/await. I find async programming is similar annoying in both Python/JS.
> Pip has a long way to go to catch up to npm/yarn
I don't see a big difference working with pipenv/poetry compared to npm. Once your project structure is configured it boils down to `pipenv install`/`poetry add`/`npm install`.
> Virtualenvs are weird, even though node_modules can be bloated i think its a lot more intuitive.
Again, once configured I don't see a big difference (from a user's perspective). One system puts your packages into `npm-packages` the other puts them into `some-venv-dir`.
I think npm works better out of the box, but you can configure your python dev enviornment very similar, if you want, without much effort.
To me working in either TS/Python+Mypy feels pretty much the same.
I am currently in my third hour of getting a pipenv+pyenv python project running. I started the project this past summer, and have reinstalled it three times. Each time I have spent 3-6 hours getting pipenv working, and each time the errors/problems/workarounds are completely different!!!!!!
I'm not the one doing any dirty work though...
I truly love that in Python I can look at my import statements and know what code is happening in a file!
But, man, it is tedious to so often have to use 5 clumsy lines for what Ruby could have said better in 2...
Sure, Ruby is not "consistent" in that there are several ways to do things. And with more tools at your disposal, you can get many things done easier!
An Apollo/yoga graphql setup with node and prismsa is just really, really productive.
There is also the advantage of sharing environment between front and backend, I mean, there are just so many hours, it’s hard to keep up with two major languages and their communities (two and a half if you’re using typescript).
I can understand why a lot of people start with Python. I can't work out why they stick with it once they become more advanced and understand its limitations though.
I believe that if you're walking the line between software-development and data-science Python does an excellent job of bridging the two.
I played around with PHP in order to make hacks on WordPress themes, which again I hated due to system-fighting.
I learned base R (pre RStudio/tidyverse) for stats classes, which I hated even more than the previous two since everything felt combersome.
Then just for fun I installed Linux on my laptop and experimented scraping APIs with Python with only a few lines of code and I got hooked.
Nowadays I use primarily Python for both work and personal projects. If I had started with learning Python, I would have had a much different career path!
Writing a basic hello world function you’ll learn about types, return values, references, imports and access modifiers, all in three lines of code.
Java is also excellent for building stuff like various linked lists to see how the lists and arrays we all take for granted actually work behind the scenes.
The confines of Java’s strictness is also a really great sandbox in which to teach best practices without students ever getting in danger, because java will tell them every time they do.
I know a lot of teachers really struggle to do it well, but going through public void X, word for word can be extremely useful in teaching. For one, it’s very easy to spot who knows what is happening and who is just copying stuff to make it work.
I think python is quite terrible for teaching beginners, but it’s certainly fun to write. These days, I think JS and Node is more fun than python but that’s mostly because it’s where a lot of the fun is happening, I certainly could do without all the {s and ;s.
Furthermore they are all easily explainable concepts that any CS student will be able to grasp once they reach their first programming language course.
I’d say most of the concepts are easy for non-CS students as well. Access modifiers, especially public and private aren’t hard concepts, are they? Yet they are insanely important to your basic understanding of what a function does. Private is like singing in the shower, you’re doing it for you. Public is like signing at a concert hall, there you’re signing for the audience.
Return values are values functions return, your can think of them as the result a calculator gives your when you ask it to add 2 and 2, here the return value is 4.
Types are typically the first thing you explain anyway, including when you teach python.
Maybe you could get people writing complicated functions faster in python, but why would you want to? The purpose of teaching programming isn’t to have people writing code as fast as possible, it’s to teach them to understand what the hell it is they are writing, so they’ll know why they do it.
Rather, I'd reword it. Just getting faster feedback from coding to some response is not enough. It has to be to the desired responses. (So, for example, it doesn't help to get faster feedback to syntax highlighting.)
But more seriously, I strongly disagree about Haskell being anything like Python is for kids.
The level of abstract reasoning that Haskell requires for more than just adding two numbers is not easy or intuitive for kids. Following step-by-step instructions is intuitive. Writing Python line-by-line is easy to understand by analogy to a list of instructions. Eventually they can start using functions when they're comfortable, but you're very unlikely to succeed in teaching a five year old about typeclasses, monads, functional purity, effect systems, or anything like that. The thing with Haskell is that you have have to know almost all of that to do anything useful from day one. Even something as simple as drawing lines on the screen.[1]
Don't be ridiculous by suggesting Haskell is just the same to five year olds as Python.
[0]: https://wiki.haskell.org/Zygohistomorphic_prepromorphisms
> The thing with Haskell is that you have have to know almost all of that to do anything useful from day one.
Okay, then how is adding two numbers together useful? If that's Python programming then the equivalent counts as Haskell programming. You are setting a double standard for what you expect a 5 year old to be doing.
Even then, tell me which of these is simpler and more clear:
def double(x): return x + x
double x = x + x
let f x = x + x
That "actual code" I mentioned can involve drawing on the screen, which as I pointed out in painstaking detail, is not going to be explainable to a five year old with Haskell code. That kind of visual feedback is incredibly important to concrete learners, which everyone is at that age.
Haskell and Python are not similar with regards to "conceptual/semantic complexity." At all.
I have used Haskell in the past. I understand it. Someone who hasn't reached Piaget's "formal operational" stage is not going to understand it. Piaget's theory isn't perfect, but it is normally true that people start out at a very concrete level.
As I said, don't be ridiculous.
Here is some super complicated Python code that kids can learn a lot from:
from turtle import *
color('blue')
forward(200)
left(90)
forward(200)
left(90)
forward(200)
left(90)
forward(200)
left(90)
done()
Please, show me what my above code looks like in Haskell, since it's so comparable in complexity.
I don't think you have an appreciation for what goes into learning programming. You've probably been doing it for far too long at this point, without thinking back to the early days.
Why are you so defensive about Haskell in the first place?
Books like The Haskell School of Expression have been teaching functional programming using simple graphics in Haskell for a long time. Need I remind you that the entire concept of a Turtle comes from Logo, which is Lisp minus parentheses?
For the record, those kids do not look like 5 year olds. Once someone is old enough to do abstract reasoning, I think Haskell might be a workable choice, if carefully taught. More often than not, it's more likely to drive them away than something simpler. That article appears to be using some web interface which was designed to hide all of the monads... I think that's a splendid way to get started. The students aren't writing their "main" function. Unfortunately, the website linked from that website is down, so it's hard for me to verify.
You haven't been listening to anything I have said, so I'm going to stop. I wish you would reflect on software education, because however well-intentioned, starting with Haskell is likely to drive many more people away than it would help to show what they can accomplish and inspire them.
In fact, as far as teaching 5 year olds is concerned, I'd go with Lisp rather than Python.
λ length [1,2]
2
λ length [1,2,3]
3
No problems here. Now tuples:
λ length (1,2)
1
λ length (1,2,3)
No instance for (Foldable ((,,) t0 t1)) arising from a use of ‘length’ In the expression: length (1, 2, 3) No instance for (Num t0) arising from the literal ‘1’ The type variable ‘t0’ is ambiguous Note: there are several potential instances: instance RealFloat a => Num (Complex a) -- Defined in ‘Data.Complex’ instance HasResolution a => Num (Data.Fixed.Fixed a) -- Defined in ‘Data.Fixed’ instance forall (k :: BOX) (f :: k -> *) (a :: k). Num (f a) => Num (Alt f a) -- Defined in ‘Data.Monoid’ ...plus 7 others In the expression: 1 In the first argument of ‘length’, namely ‘(1, 2, 3)’ In the expression: length (1, 2, 3) No instance for (Num t1) arising from the literal ‘2’ The type variable ‘t1’ is ambiguous Note: there are several potential instances: instance RealFloat a => Num (Complex a) -- Defined in ‘Data.Complex’ instance HasResolution a => Num (Data.Fixed.Fixed
A quick googling does not tell me how to find the length of a tuple. The closest thing to an answer is, 'you probably don't actually want to do that'.
1. If you gave this response to the hypothetical five year old, you will simply make them cry, and then they will quit programming.
2. If you give this response to the hypothetical fifty year old, they will feel you're hemming and hawing to cover a weakness in the language rather than giving a more direct and honest answer.
In regards to (2), I'm not literally a 50 year old learning Haskell, but I am an adult teaching himself how to program for the first time, starting with Standard ML. Perhaps if you have a few minutes you'd be willing to let me elaborate on my complaint and check my understanding?
The main issue i'm imagining is modeling homogeneous data vs heterogeneous data. With tuples, the types of data are encoded in the tuple type, and are known at compile time. In SML its a product, so a tuple of length 2 is a different type then one of length 3. Presumably this is what you meant by 'not really collection types'?
Tuples of different lengths having different types is, if i'm understanding things correctly, the key point for this discussion. If i want to write a mythic 'tuple length' function in SML, it has to be generic enough to work on something of type a->int, and a* b->int, and a* b* c->int, etc... And so it has to make sense for any 'a->int (where 'a is a variable), which is to say it can't know anything about the structure of tuples! Is this reasoning correct?
Assuming it is, you can see why I called those answers 'hemming and hawing'. This is clearly not something put in the language based on some prior logic about indices or collections or fixed sizes...nobody wants to not be able to write functions from arbitrary tuples; it appeared as a design trade off in order to access type information at compile time. It also is not specific to the length function.
A second strategy to model heterogeneous data is to use a homogeneous collection like a list but then use a sum type to introduce heterogenity. This makes a different trade off: the types are the same for different sizes so we can write functions easily (including length!) but the types are the same so we've lost access to compile time information, and the class checks from the sum are done at run time.
Thanks for taking the time to read this far and correct my misconceptions!
As easy as Python? That's a very high bar. We all agree (I hope) that JavaScript requires linters (plural) to write well. Rust/Scala/Haskell have unpleasant learning curves. Java is verbose and clumsy. Basic and Pascal have fallen into disuse. Go may be simple, but it's syntax is more symbolic and less English-like than Python. Don't get me started on Perl and the lisps. C/C++/PHP have more footguns than features.
I'm not a Python die-hard, but it's obvious that it's superior when it comes to ease-of-use and learning curve. It's very similar to how people write pseudocode.
If your criteria for readability is "English-like" I think you're missing a lot of what makes Python so readable in the first place. It is not very English-like at all. Compare to say COBOL, which actually had English-like readability as a design goal and was by all accounts an unmitigated disaster. AppleScript has a similar reputation for being a "read-only" language because of how difficult it is to pick up from reading it. What makes Python readable is having a small number of concise syntax constructs that compose into complex programs, the same things that make functional code readable. The presence of words vs operators is probably important, and Haskell tends towards the latter, but the ML family doesn't, and Lisps are plenty readable if you keep them simple. There's a reason that SICP and HTDP use Scheme, the latter using a gradually larger subset to make it less intimidating.
When I was a kid I wanted to make games, I picked up a book on C from the library. I wrote a simple interactive fiction type game but with never managed to compile it.
When I tried out python a couple of years later I was blown away. I could actually write and run programs. I wrote a mandelbrot set generator and I was hooked. This is what programming is supposed to be like, I thought to myself.