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

That sounds interesting, do you have any details (blog post, tutorial) on exactly how to do that?

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

I learned this when my boss was wringing his hands over an Excel job that was too complicated to do comfortably in VBA. I'm not allowed to install anything on the computers because I'm a flunky technician.

I started poking around the C:\Windows directory to see if there was something that I could use, and I found C:\Windows\Windows.NET\

"Wait a second - C# is .NET, right?"

A hundred lines of C# later, I had a solution for my boss where you drag the CSV onto the program and it spits out another CSV. I would've liked to have the ability to grab an Excel file, but that requires installing another library... can't do it.

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

I should clarify that my experience is pretty narrow in the python space. The comment was based on my (recent) experiences in the land of jupyter notebooks -- first using matplotlib and then switching to bokeh and finding the api to be more straightforward.

> why defining a function and calling it right after?

Documentation.

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.

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.

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.

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.

Good god. If anything is "forced" upon high-school kids, it's algebra. (Maybe ask the average high schooler and see what they have to say about it.) I haven't heard of any schools that make Python mandatory though; where are these located?

BASIC used "=" for both assignment and equality tests long before Pascal existed and was more popular for teaching the youngest students even when Pascal was available, so I find the idea that the use of "=" for assignment is some kind of barrier that high school kids (or younger, even) are going to have a lot of problems with just as implausible as the idea that imperative mutation is such a problem.

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

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

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 process it has to be encapsulated as a plugin, which means a) any random logic in the build process is at least ordinary first-class code that goes through your normal code review process, has a versioning and release cycle, can be unit tested etc. b) the slight extra overhead means there's more likely to be one standard plugin for doing a thing, which again means there'll be a standardised source directory etc., rather than everyone integrating thrift or swagger or what-have-you into their build in an ad-hoc and slightly different way. c) often people decide that actually they can live without having function names be capitalised if the build was made on a Wednesday or whatever nonsense they wanted to do to the build, and put their business logic in code where it belongs instead.

Beyond that there's a working central repository where all the important libraries are (and it's one of the few ecosystems that actually enforces code signing of all published libraries), and also a free repository server that you can run on-premises (and that's a normal JVM app that runs like anything else in the ecosystem) and use for private publishing and/or to proxy remote repositories to make sure you will always be able to rebuild any previously successful build even if a remote repository goes down. The release plugin enforces good practices by default, e.g. you tag a release and rebuild from that release, ensuring you can always recreate any given release; you may build a -SNAPSHOT which depends on another -SNAPSHOT, which makes it lightweight to make a change to an upstream library and check that it has the right effect on your downstream application (and the first-class IDE integration dovetails very nicely with this), but releases are only allowed to depend on releases, which ensures they're reproducible and immutable. None of this should be hard, and I think other ecosystems are gradually getting it right, but Maven just seems to have managed to make all the right choices and avoid all the pitfalls. You don't hear as much about it as you do about, say, NPM, but I think that's at least partly because it rarely goes wrong, so a lot of the time it's invisible to developers.

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

True, but 95%+ of the issues you'd catch with unit testing in Python you catch during compilation in Scala, and that can be an incremental compile rather than a full compile. So once you have a properly set up dev environment the feedback loop takes less than 2 seconds in practice, though the one-off setup to reach that point is a lot fiddlier than for Python.

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

Heh, I don't like either, I'm a huge fan of Wicket (the one time I had to use Django I wrapped it in a Wicket-like layer I called smoff, which I think might even still be out there). Django is too page/request-oriented for my liking, I think a component-oriented library leads to much better design when you're making actual UIs. For REST endpoints spray is the best thing I've ever used, in any language: having your route definition look more-or-less like a route definition but being regular code that you can refactor in all the regular ways is amazing, especially when you get to the point of wanting to use e.g. custom directives and you can just click through to the standard directives and they're just ordinary code that you can adapt the same way as any other code.

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

I think if you can't do it with Shapeless it's probably not worth doing. The typeclass-derivation stuff is more boilerplate than it should be, but it does work well apart from that, and always leaves you with something more-or-less understandable. Whereas some of the Python metaclass tricks I've seen have just been completely crazy.

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

I think you have to remember to compare code that does the same amount, not code that's the same length. Like, sometimes there will be a 1-liner in Scala that I'll have to mentally expand out to 6 lines to understand - but in Python the same code would have been 6 lines in the first place. And I think there's a huge benefit to being able to see a whole class definition on a single page, so I'd rather have the "compressed" single-line version even if it takes slightly longer to read in isolation than the "expanded" six-line version.

> 6) No SBT

Agreed. Can't stand it, have no idea why it's popular. I just use maven.

Scala gets great, SBT stays awful. Avoid it if you can.

Once you get used to working with the type system you'll need tests a lot less - the cycle becomes edit/save/look at IDE "problems" tab, and that catches the overwhelming majority of issues, so you only resort to running the tests every couple of hours. It takes a while to make the transition though.

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

Part of Go's charm is how much it leaves out.

But that's not to say it doesn't include good stuff.

I'd say support for lightweight threading, CSP (channels), structural typing, fully embracing first-class functions (crippled python lambda, anyone?), and a build-system integrated into the language rather than left to 3rd-party-tools are all distinctly post-90s features, for a mainstream language.

Also, gofmt is a huge boon. The Go community focuses on ecosystem and ergonomic human factors of development feels distinctly post-90s-lanauge to me.

Also, the 90s saw an intense, misguided focus on "object-oriented-programming", which Go completely, mercifully ditches. In that sense, it's post-90s. :)

(Well, OK, maybe OO-style programming is good for UIs -- thinking of stuff like iOS/Cocoa apis and Unity.)

Well, if you want people to switch to 3, you do need to apply some pressure by end-of-lifing 2.

Oh absolutely. There's a few linux distros starting to ship python3 by default, which is great. It's happening far too slowly.

Speaking of speed, I hear 3.7 should finally be able to beat 2.7 for most benchmarks, which is pretty sweet.

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

There's a reason the python command points to Python 2: https://www.python.org/dev/peps/pep-0394/