Live data from Hacker News

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

talkpython.fm

111–120 of 151 posts

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

#111
post #78

Earlier quoted context omitted.

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 lo…

I used Scala for a few years. I actually prefer python to it though. My reasons are:

1) Compile time. In a tight dev loop, you can run Unit tests in say 2 seconds in Python, vs 15, 30, 60, 90 seconds in Scala (depending on code base size)

2) Django. Play is ok, but for web stuff I think Django does a little better job.

3) Ease to find help. Finding someone to write scala is hard. Usually means hire a Java or a Haskell guy and train them. Way more people know Python.

4) Easier to metaprogram. Sometimes, metaprogramming is awesome. Don't do it nonstop, but sometimes it is amazing. Reflection and macros and all of that exists, but it gets seriously awful to deal with.

5) Code readability. I read scala fine, but it can still take a while to parse a file to know what is going on. Trying to think through crazy scalaz or something can hurt your head, even if you get it.

6) No SBT

Now this is not to say all is perfect, things I do miss from Scala:

1) When you really do need high performance, you can get there without dropping to C.

2) Compile time checks catch many many errors. Really sucks if you write something in prod and get a ValueException at runtime. Obviously this means you missed a test, but a scala codebase with say 25% test coverage will be generally less likely to have runtime erors than a Python codebase with even 75% coverage.

3) IDE support. Mypy is a work in progress, but click though stuff still works a little bit better in Scala. Scala is not Java good at this though due to implicit magic, so this is becoming more of a wash.

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

#112
post #96
post #90

Earlier quoted context omitted.

"the assignment syntax "x=x+1" must be especially confusing to high-school kids" Many other comments already discussing this, but I have to add this. I don't think that has ever confused more than a handful of high school students because you are almost certainly bringing an understanding of "=" that you acquired at a much higher level of math. For a lot of students, "=" isn't even what you would consider the "equali…

In the UK, algebra is first introduced using the equality operator, often with pictures of weight scales and weights, which students are asked to balance. Then they are introduced to a concise notation for this, e.g.: 1 + x = 3 Simplification comes later; and it often involves moving terms from one side of the relation to the other, which isn't possible with an assignment operator. I have no doubt that beginners soon…

"but why reuse the operator in the first place? Is it really making it "easier" for the beginner"

That's a different question than "Has it confused a whole lot of high school students?"

"The misuse of the equality operator is only one minor detail, but if people care so little about such details, how can they be trusted to look after the more important ones?"

Assuming by "more important ones" you mean more important mathematical ones, that's extremely easy to answer: They can't and they haven't. Very few programming languages look anything like conventional mathematics. Most of the popular programming languages are wildly adhoc from a mathematical perspective. But while some mathematically-inclined folks consider that some sort of damning criticism, they must also address the fact that there are no known practically useful languages that are not at least partially adhoc. Haskell is the closest and the community is well-aware of the places where even it cuts substantial mathematical corners. However, the developing languages that don't cut mathematical corners are only useful on toy problems right now, with the occasional triumphant breakthrough on a very particular problem. It's hard to program in languages where successfully creating a "sort" algorithm is a modestly impressive feat.

Compared to the other wild liberties taken relative to conventional mathematics, rewriting two parallel horizontal lines to mean "assignment" is hardly even interesting... after all, assignment itself, as an operation embedded in time, isn't very "mathematical", requiring rather a lot of formal machinery to represent, and goodness help you if you try to formalize what a multi-core system is really doing. It's merely one of the more obvious deviations from math, but arguably the more numerous and profound subtle ones are much more important.

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

#113
post #86

Earlier quoted context omitted.

Love Python, but very happy to be writing Go instead now, to give one example of a post-90s language. (Their intersection of uses isn't total, of course; Python's still got Go handily beat for numpy-ish stuff and interactive use. See Julia for a possibly-superior post-90s competitor in those areas, though I've only played with it.)

I would argue that Go is very much a 90s language. It has none of the benefits of a 21st century language, none of the (as yet mostly unknown) drawbacks of a 21st century language, and fixes the drawbacks of 90s languages that we've learned over the last 25 years. This definitely should not be interpreted as a slight on Go, many people would very happily trade that lack of benefits to get that lack of drawbacks.

Yeah, Go is more of a "synthesis" language, trying to conservatively use proven-out techniques in a very refined, cohesive whole. To me it is still "post-90s"; see my response to zephyrfalcon for details. :)

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

#114
post #105

Earlier quoted context omitted.

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.

I don't what the process on Windows these days 1) Go to visualstudio.com 2) click Downloads if you want the full IDE: 3) choose between downloading free version of a trial of the professional version if you just want the command line tools 3) scroll down until you find C++ Build Tools and download that 4) double click the file you just downloaded. 5) Done

No more reboots?

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

#115
post #78

Earlier quoted context omitted.

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 lo…

I've been programming python 15 or so years, and packaging seems very much a solved problem to me. I'm sorry its difficult for others, I just can't see the problem myself. I guess I understand them all at this point, and it all seems easy... pytest and tox is a dream. It's so quick, I can modify some code and switch to my test window, and I already have the results... It is not unrealistic to author several thousands of lines in a single day, its just so freeing to make a thought into code so quickly.

Only programming Scala for one year, and it has been so depressing that it is beginning to affect my mental health. Mostly around sbt -- inconsistent incremental compiler issues, having more than one sbt causes a lock file I can't avoid, and even if they succeed, I get corrupt class files, so down to the one... and then getting inconsistent coverage report results, running all of the tests all over again because the report is no longer accurate, sbt and scala compiler are so dog shit slow that I'm back to "making tea" and "making sandwich" time during the edit & test cycle. Waiting just two extra seconds can interrupt a flow, waiting 12 minutes and you've lost it entirely.

Having worked with 20 or so languages professionally, this is probably the least productive I've ever been in my career.

Scala seems mega-boss hard.. please tell me it gets better

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

#116
post #104

Earlier quoted context omitted.

Seriously. For anything more than a single developer maven is the best build system I've ever used by a long way, because its customizability is so limited: every project uses the same source directory layout, every project uses the same release tag format, every project uses the same unit test layout, and so you can immediately jump into any project and be productive. When you want to run random code in your build p…

>Seriously. For anything more than a single developer maven is the best build system I've ever used by a long way, because its customizability is so limited That, along with its horrible XML markup abortion, was exactly what I hated about it. Any behavior that was even moderately unusual was a monumental pain to implement. Build scripts by their very nature need to be turing complete because the need for customizatio…

Maven is not a build script, it is a declarative build definition system.

It is not supposed to be Turing complete, for things that need that customization, as the GP stated, you use extensions.

For anyone who likes maven, checkout cargo in Rust. It got everything right, and made build extensions easier to integrate.

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

#117

Earlier quoted context omitted.

> The rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state of our industry There is no rise. Not any more. At best, it's a plateau, and in my opinion, all dynamically typed languages except Javascript are on a straight decline curve, slowly being replaced by statically typed languages. I noticed that a lot of people who enjoy Go come from Ruby or Python. Go'…

"""There is no rise. Not any more. At best, it's a plateau, and in my opinion, all dynamically typed languages except Javascript are on a straight decline curve, slowly being replaced by statically typed languages.""" This sounds like wishful thinking. (Your wish, apparently... certainly not mine. :-) I have seen no evidence that Python is on the way out. If I look at the languages asked for in HN's "Who's Hiring" th…

Sure, it's just my opinion.

Your post history seems to suggest you are heavily involved in Python. I'm not. I don't write Python, I don't write Go, I have no dog in this race. I'm just observing trends, like I've been doing for the 30+ years I've been in this industry.

And these past few years, I've observed enough hints that people are moving from Python and Ruby in droves. And also that no large projects would be started in either of these languages today. Python/Ruby are going to stay around forever, no doubt, but much more as a glue/infrastructure language to write scripts here and there (and TensorFlow might help Python stay relevant for a bit longer too).

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

#118
post #86

Earlier quoted context omitted.

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.

Love Python, but very happy to be writing Go instead now, to give one example of a post-90s language. (Their intersection of uses isn't total, of course; Python's still got Go handily beat for numpy-ish stuff and interactive use. See Julia for a possibly-superior post-90s competitor in those areas, though I've only played with it.)

Go has a large chuck of numpy/scipy stuff github.com/gonum

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

#119
post #42

Earlier quoted context omitted.

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 rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state of our industry. Stronger type systems don't come for free. They come at the expense of slower prototyping.

I respectively disagree. I use types for rapid prototyping. Often I write out the type signatures first, type-check the high-level compositions and then fill in the implementations later.

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

#120
post #55

Earlier quoted context omitted.

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.

It'd be great to have it built-in but you can get https://chocolatey.org and MinGW pretty easily:

  iwr https://chocolatey.org/install.ps1 -UseBasicParsing | iex
restart prompt, then:

  choco install mingw
(no machine reboots, disclaimer: I work at MSR, nothing related to this)
Post reply on HN