Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

talkpython.fm

Post reply on HN
Print view View original

91–100 of 151 posts

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

#91

Post by hota_mazi »

willtim wrote: post #69
ue_ wrote: 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".

The syntax is trying to look friendly and familiar, but ultimately it's an abuse of a standard mathematical notation that has meant something else for hundreds of years. The original meaning, an equality relation, is still being taught to high-school children today, typically before python is forced upon them.

You're over dramatizing.

The human brain is very good at interpreting things in context and it's really trivial for even middle school kids to understand that `=` in math is different from `=` in programming.

Do you want an example of something that beginner programmers struggle with? Pointers.

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

#92

Post by bryanlarsen »

dilap wrote: post #86
moonshinefe wrote: post #63

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.)

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.

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

#93

Post by zephyrfalcon »

dilap wrote: post #86
moonshinefe wrote: post #63

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.)

Interesting, because a common criticism of Go is that it's "stuck in the 70s". [1] It's "modern" only because of its age, not because of its features.

[1] https://github.com/ksimka/go-is-not-good

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

#94

Post by crdoconnor »

lmm wrote: post #78
moonshinefe wrote: post #63

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…

>And the whole library/build ecosystem works a lot better

Seriously? Maven was one of the things that made me run away screaming from the Java ecosystem.

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

#95

Post by sametmax »

preordained wrote: post #20
pmontra wrote: post #13

Earlier quoted context omitted.

It might depend on your previous history. My development arc was C, Perl, Java, Ruby, Python with Javascript in parallel. Python is not particularly intuitive after 10 years of Ruby. Actually it's a mistery to me how people can like such a complicated language. However I got only customers using Python last year so I must make me like it at least a little. I keep thinking I could have been very unlucky and found some…

Yup. I'm with you. For my money, Ruby could fill exactly the space Python does and do it better...but Python has too much steam in its niche and Ruby got pigeon-holed as a web language; such is life.

The reason it happened that way is the community.

The python one valued doc, robustness, readability and stability.

The ruby one loved cleverness, beautiful design and conventions.

Eventually they ended up meeting at the middle, but in the mean time, people got tired of :

- having the last monkey patch breaking their code

- having to try to understand the last crazy dsl somebody came up with

- having an incomplete out of data doc and no tests

- having gem install breaks on you randomly

- having to mess with rvm (still an issue though) which never seems to do quite what you want

Ruby is a good language, but it took too much type to come out of it's teen years, playing bold and teasing. Now it's too late.

JS is getting away with it, despite being way inferior to ruby, because it's the only language on the web platform and we are forced to use it. Ruby didn't have this chance.

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

#96

Post by willtim »

jerf wrote: post #90
willtim wrote: 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 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 learn any different meaning of "=" over time, but why reuse the operator in the first place? Is it really making it "easier" for the beginner? At least with BASIC the context switch was easier as it was strictly imperative. Python tries to mix in more declarative concepts.

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?

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

#97

Post by crdoconnor »

willtim wrote: post #42
Rapzid wrote: 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 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.

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

#98

Post by willtim »

hota_mazi wrote: post #89
willtim wrote: 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 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'…

I hope you are right. It's spreading all over the industry I work in and the schools want to teach it to my kids.

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

#99

Post by ylem »

mivade wrote: post #71
breatheoften wrote: post #54

Earlier quoted context omitted.

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

This. Where I work, a lot of the scientists use matlab. Transferring from that to matplotlib is relatively simple. Also, making publication quality graphics is what I use it for. If I want to make something interactive these days, I tend to just put it on the web...

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

#100

Post by crdoconnor »

FrederikNS wrote: post #87
moonshinefe wrote: post #59

Earlier quoted context omitted.

Yeah, I don't think you know python very well at all given your criticisms. The very first thing you criticize is "its reliance on mutable data structures"--uhh no, most data structures and types in python are immutable. I'll at least agree I've met a lot of python snobs who say don't use the built in map/filter functions and things like that in favour of comprehensions, but that's hardly representative of the langua…

Most semi-primitive types in python is immutable, yes (int, float, char, str, and DateTime), but all of the collections are mutable (List, Dict, Set). I'm sure there are immutable versions of those same data structures hidden somewhere in the standard library, but I haven't looked. I did stumble upon pyrsistent ( https://github.com/tobgu/pyrsistent ) a while ago which does provide proper immutable (and persistent) da…

I usually treat them as immutable by using copy(x) or deepcopy(x) unless I'm writing a chunk of code that is explicitly building it from scratch and pushing it somewhere.
Post reply on HN