Live data from Hacker News

Python past, present, and future with Guido van Rossum [audio]

talkpython.fm

71–80 of 151 posts

Re: Python past, present, and future with Guido van Rossum [audio]

#71

Earlier quoted context omitted.

It IS a 90s language! ;-) My main issue with Python is distribution. Oh, you're using it on Windows? No worries, just install matplotlib using pip. Oh wait, you need to install cygwin and a C compiler and for some weird reason it won't compile but no worries there is a website with Unofficial Windows Binaries for Python Extension Packages but it's still not working.... Numerical computations and plotting are also my…

There isn't anything good about matplotlib that I can see. Maybe I'm just not smart enough to see what's nice about it -- but as someone who has to learn it rather than already indoctrinated into matlab style plotting -- it seems like a disaster ... I switched to bokeh and am so far much happier

Matplotlib's main API is pretty terrible. But it's just fine for the simple plots that scientists and engineers are often needing (e.g., just plot y vs. x). It's also pretty straightforward to get publication-quality plots. Bokeh can handle simple plotting and more complex visualizations, but it is aimed mostly at interactive visualizations rather than plotting for publication. For now, matplolib is the only real option for that in the Python world.

Matplotlib inherits most of its baggage from originally being meant to mimic Matlab plotting that many were then familiar with. As an aside, I find the pandas interface to plotting with matplotlib to generally be much easier to work with.

Re: Python past, present, and future with Guido van Rossum [audio]

#72
post #67
post #53

Earlier quoted context omitted.

>x=x+1 I've always heard this explained along the lines of "adds 1 to whatever x is, then puts that value into x, so x is one more than it was before".

I first came across that as a school kid (in BASIC) and didn't find it confusing at all. I still find functional computing confusing - I mean to do something for the numbers 1 to 100 instead of for x = 1 to 100 you have to do some weird tail call recursion which if you are lucky the compiler then converts back to for x = 1 to 100 because that's how processors work efficiently.

I learnt BBC Basic before my high-school algebra and was certainly confused by the different meanings. Don't concern yourself with tail recursion if you are still learning FP, it's just an optimisation, nothing to do with semantics. Python doesn't have it and few people care. What do you want to do with the numbers 1..100? A for loop doesn't give me any hints, which is part of its problem.

Re: Python past, present, and future with Guido van Rossum [audio]

#73
post #56

Earlier quoted context omitted.

On most OSes, open a terminal and type 'python', and you get a python2 REPL. That's reason enough to write a lot of scripty admin / automation stuff in python2. And then if you need to extend that, it's easy to just continue on in python2. It's there, it works, it's stable, you don't have to maintain versions in case of security issues, the OS package does it for you.

It's high time to change that default. I'm glad django will not support Python2 after 2020, making clear it's legacy.

To give another example, Ubuntu is moving towards Python 3 by default, the plan is to have it as the only pre-installed Python version by 18.04 LTS, which is only a year away.

https://wiki.ubuntu.com/Python

Re: Python past, present, and future with Guido van Rossum [audio]

#74
post #55

Earlier quoted context omitted.

Might be an off-topic, but recently I learned that Windows does come with a C# compiler. It's included in the .NET runtime, which is installed by default nowadays. This might be useful if you're extremely lazy to install any language implementation. It is quite amazing since even Ubuntu doesn't ship a C/C++ compiler by default.

I'm surprised Ubuntu doesn't come with gcc.

You type in 'sudo apt-get install build-essentials' and you have it. I don't what the process on Windows these days but you used to have to find visual studio install media, install it, and reboot two or three times.

Re: Python past, present, and future with Guido van Rossum [audio]

#75
post #5

I've recently had to start writing python professionally and I'm not super impressed. My previous python experience was writing small services and fixing others code. Now that I'm working on larger "apps" it feels like a 90's language with all the rough edges and warts. I'd rather being working in a language with better language services and tooling, but python has numpy and all these data viz libraries so whatcha go…

It IS a 90s language! ;-) My main issue with Python is distribution. Oh, you're using it on Windows? No worries, just install matplotlib using pip. Oh wait, you need to install cygwin and a C compiler and for some weird reason it won't compile but no worries there is a website with Unofficial Windows Binaries for Python Extension Packages but it's still not working.... Numerical computations and plotting are also my…

I don't think this has been true for at least a couple of years. There are wheels posted back to 2014 and maybe farther (didn't check beyond 1.4.1).

https://pypi.python.org/pypi/matplotlib

Re: Python past, present, and future with Guido van Rossum [audio]

#76
post #42
post #5

I've recently had to start writing python professionally and I'm not super impressed. My previous python experience was writing small services and fixing others code. Now that I'm working on larger "apps" it feels like a 90's language with all the rough edges and warts. I'd rather being working in a language with better language services and tooling, but python has numpy and all these data viz libraries so whatcha go…

Haskell and OCaml are also 90's languages. The rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state of our industry. I do not even believe it is the best choice for teaching programming to children. It heavily mixes and conflates higher-level ideas like lambdas and list comprehensions with imperative programming and mutation (the assignment syntax "x=x+1" mu…

> "x=x+1" must be especially confusing to high-school kids

I like immutability as much as the next programmer, probably more. But the idea that changing the value of a variable in memory is confusing to high-school kids gets repeated way too often with way too little evidence. X isn't the x from algebra, x is your bank account balance. That it changes at payday is not a hard analogy to understand. I have yet to meet the high-school kid who thinks this says that 1=0.

Now, like the rest of us, high-school kids can get tripped up by assignment and its consequences. Functional programming offers us great tools to deal with that. But the 1=0 argument is not credible to your average procedural programmer who's been doing assignment since the age of fourteen, and is in full command of basic algebra. A much better argument would be that Haskell lets you take advantage of algebra as an analogy, and Python doesn't unless you're unusually disciplined.

Edit: removed a word for grammar.

Re: Python past, present, and future with Guido van Rossum [audio]

#77

Earlier quoted context omitted.

Serious question: What are the reasons people are still preferring Python2 over Python3? (No troll intended)

On most OSes, open a terminal and type 'python', and you get a python2 REPL. That's reason enough to write a lot of scripty admin / automation stuff in python2. And then if you need to extend that, it's easy to just continue on in python2. It's there, it works, it's stable, you don't have to maintain versions in case of security issues, the OS package does it for you.

You can also open a terminal and type 'python3', and get a Python 3 REPL.

I only learned recently that it's a compatibility decision that means that plain 'python' will always be Python 2. However, you're starting to see Python 3 distributed right alongside it in most recent distros.

Re: Python past, present, and future with Guido van Rossum [audio]

#78
post #5

I've recently had to start writing python professionally and I'm not super impressed. My previous python experience was writing small services and fixing others code. Now that I'm working on larger "apps" it feels like a 90's language with all the rough edges and warts. I'd rather being working in a language with better language services and tooling, but python has numpy and all these data viz libraries so whatcha go…

I'd absolutely love to hear what language you're using that's superior and not a "90s language" then. Pretty sure most of the popular languages date back to then if not a decade or two earlier. I find it especially amusing you cite typescript and the node ecosystem as superior. I've never seen such an unreliable and constantly changing ecosystem with dozens of frameworks and libraries ever in recent history.

Having used Scala I can't stand to go back to Python. Almost as lightweight (more lightweight in some places - case classes and "_ lambdas" are things I really missed in Python, though attrs maybe solves the first), but a whole lot safer, which makes it much easier to refactor, which makes it possible to maintain a much higher quality standard in a long-lived codebase.

And the whole library/build ecosystem works a lot better - partly the problem is harder for Python because many "python" libraries rely on native code (whereas JNI is relatively rare), but it seems there are still four or five different ways to build and package Python projects and to work at an organization with a large Python codebase you end up having to understand all of them. (Every few years I see a blog post on how the packaging problem is totally solved now, for real this time, but at this point I've stopped believing them).

Re: Python past, present, and future with Guido van Rossum [audio]

#79
post #67
post #53

Earlier quoted context omitted.

>x=x+1 I've always heard this explained along the lines of "adds 1 to whatever x is, then puts that value into x, so x is one more than it was before".

I first came across that as a school kid (in BASIC) and didn't find it confusing at all. I still find functional computing confusing - I mean to do something for the numbers 1 to 100 instead of for x = 1 to 100 you have to do some weird tail call recursion which if you are lucky the compiler then converts back to for x = 1 to 100 because that's how processors work efficiently.

Don't bother thinking about what the processor is doing. Just trust it to figure it out. Tell it what to do (which shouldn't involve "weird tail recursion" - rather you probably want to use "map" or similar), and let the runtime/processor do it for you. If and when it turns out to actually be too slowly, and you profile it and can't immediately see why, then you're allowed to worry about that kind of thing. Not before.

Re: Python past, present, and future with Guido van Rossum [audio]

#80
post #42
post #5

I've recently had to start writing python professionally and I'm not super impressed. My previous python experience was writing small services and fixing others code. Now that I'm working on larger "apps" it feels like a 90's language with all the rough edges and warts. I'd rather being working in a language with better language services and tooling, but python has numpy and all these data viz libraries so whatcha go…

Haskell and OCaml are also 90's languages. The rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state of our industry. I do not even believe it is the best choice for teaching programming to children. It heavily mixes and conflates higher-level ideas like lambdas and list comprehensions with imperative programming and mutation (the assignment syntax "x=x+1" mu…

> the assignment syntax "x=x+1" must be especially confusing to high-school kids

It wasn't at all confusing to me as an elementary school kid in BASIC, so I doubt it. The variables = named boxes metaphor was a fairly standard part of the pedagogy.

Immutability is great, sure, but let's not pretend that imperative sequences of instructions aren't basic and common things humans have to deal with and quite natural.

Post reply on HN