Python progression path - From apprentice to guru | Hacker News Reader

Python progression path - From apprentice to guru

stackoverflow.com

147 pointslimist23 comments

The top answer seems to be for the question "How do I learn to program Python using only the functional style". Which is FAR from being a Python Guru. A Guru knows how to use Python for many styles and to mix them for optimal effect.

#11 "balance" is laughable based on the preceding ten.

Some things missing include:

  * properties (glaringly so)
  * slots
  * meta classes
  * dynamic code generation / data as code
  * emulating various types and the rest of __methods__
  * know thy standard lib
  * distribution setup tools, et al
  * documentation epydoc, sphinx, docutils, et al
  * profiling and performance

Also from the top answer.

"... Python class. Claim it could be "better" implemented as a dictionary plus some functions"

Um, that is almost all a Python Class is.

Also from the parent's comment.

"... Programming commentary. Protagonist proudly advocates against something he feels he's moved far beyond in favour of a solution which is exactly that thing in more obtuse terms."

Um, that is almost all a humorous instance of dramatic irony is.

While the OP's list has a more functional outlook than most similar lists, for most Python programmers the difference between being average and being good in Python is in knowing when to drop into functional paradigms. Your list contains a couple of key points the OP missed (grokking properties and the standard lib) but takes a similar divergence when you get into things like slots, meta classes, and dynamic code generation that are the primary source of code smell from wannabe Python gurus. 99.99999% of the time you will not actually need them and are just throwing it in to demonstrate your 'leet python skillz'.

Sure, but as a guru you know how to and when to use them.

Gurus are the people you go to for the .00001%.

The subject was getting to Guru "level". If you don't understand those (and when to use them, i.e. almost never) then you are not a Python Guru.

I'm really into the whole "code as craft" idea, though a lot of my thoughts on the subject aren't fully baked.

It seems to me that we're at a place with software where we were with, say, civil engineering in roughly 2000 BC or something. This date is horribly wrong, but what I mean is that we're building basic structures, and we're okay at it, but when we try to do anything larger, we're failing.

At some point, we'll be able to make larger buildings, bridges, and roads... but we're not there yet. It seems like the best path forward is to follow is to do exactly what early engineers did: an apprenticeship model. Yes, software is based in math, but so are bridges. We've got a better grip on the math now, and it does help us build modern bridges, but at first, we had to schlep along.

I'm starting to ramble slightly, so I'll cut this off. And as I said, this is only a half-baked thought... but I think this 'apprentice -> journeyman -> master' path is an intriguing way to move forward with software.

That's not quite true: we do know how to make large, complex, highly reliable programs.

It's just that in most cases, no-one cares enough to pay what it costs. You either have to be extremely high profile (e.g. the Space Shuttle) or doing huge volume (think of a CPU as simply a Verilog program) to make it worthwhile. Would you pay 10x as much for a word processor or web browser that never, ever crashed? Would you pay 100x?

The problem with the space shuttle example is that it has incredibly limited scope. Yes, we could build a large program to exacting specifications, but once they change, all bets are off. The space shuttle software doesn't need to adapt over time.

And you're right, it is incredibly expensive... but even in my example, that just moves us forward to the Roman Empire, or something. People know how to build an aquaduct, but only the most excessive society on the face of the planet can afford it.

But if we're sticking with the civil engineering analogy, a road is not built in 1-week sprints with the route potentially changing as requests come in that it link more or different towns. So you have to compare like with like.

There's a reason that I said my thoughts are half-baked. ;)

Good point.

Doing mathematics is actually closer to hacking than to engineering.

Using mathematics (or say arithmetic in particular) may be closer to engineering. But we have no reliable and routine method for finding interesting statements and their proofs.

I hope we never get to where civil engineering is now: a heavily regulated industry, need to 'join the club' just to practise; several degrees of separation between designer and builder" severely conservative professional body; inability to practise easily in foreign countries; tonnes of rules and regulations that vary from place to place; nothing gets built without people waiving clipboards and shouting. Oh, and 4 compulsory years of soil-mechanics lectures.

So long as the typical programmer is only working on websites (that have absolutely zero consequence if they fail) there'll be no need for that.

The way I look at it, software 'engineering' is an apt term. When you look at, say, a suspension bridge, you can tell how it works in principle. But you also want to be confident of the standards to which it's engineered: that the bolts wont slip out, that the surfaces have been coated properly, that the stress factors have been calculated, that the blueprints are up to date, that the right metals were used, the right joints, etc. etc.. All the details which you don't care to understand but know that professionals have taken care of them. That's how I think of software engineering - applying all the tools of the trade, like unit testing, Big-O analysis, compatibility handling - ideas that are not central to any one implementation but common to all projects. Stuff you don't write about in the tour guide, but is pretty darn important all the same. Some of it industry standard practice, some of it unsung heroics.

(note: not that I think normal construction is comparable to software development. In a nutshell any computer system has an orders of magnitude more 'moving parts' (even if they only exist in the abstract) than any normal object or machine. Most programs are built on layer upon layer of supporting frameworks right down to the hardware. When you're at the top, things are inherently unstable)

A key element to that, more appropriate to the architecture side of things, is the capability of the human resources available to implement things. Perfect engineering plans for a bridge are of no use if the team's skills were not taken into account and they are unable to execute.

Actually we don't even "know" how to build buildings anymore -- if you compare the standards of modern, throwaway buildings (as in, generic commercial or residential buildings; not skyscrapers or luxury condos) with those of the 1850s-1940s.

If you compare the standards of modern buildings with those that have survived from the 1850s-1940s there is considerable survivor bias in play. There were plenty of crappy buildings built in the late 1800s eg http://en.wikipedia.org/wiki/Industrial_Revolution#Housing

Quite so. Today's "throwaway" buildings are light-years beyond the throwaway buildings (tenement apartments and such-like) of the 1850s-1940s. Such buildings don't meet any modern fire or construction codes, which is why so few of them still exist in unmodified form anywhere in the developed world.

Actually I was thinking more in terms of aesthetics (and long-term durability) than things like fire safety.

Also, the survival rates of older buildings has to do with a zillion different factors -- from changes in taste (and ideology) to fate (wars and natural disasters) to the simple economic happenstance of the particular plot of land these structures were located on.

That is, the vast majority of buildings are torn down deliberately, to replace them with something bigger or different; to purge a neighborhood of undesirable residents; or to purge collective memory of an unfashionable sense of design, or of place -- rather than because they run into disrepair (or get burned down).

This is like saying you can be fluent in Japanese by learning the grammar and saying nothing about the vocabulary. Fluency with the libraries python offers is far more important than whether you express yourself imperatively or functionally.

That said, I'm off to the library to borrow a copy of Real World Haskell.

The first answer is interesting but I don't understand step 10. Imperative is a model with state and deterministic sequence and Haskell constructs like state and IO monads form imperative DSLs (with some typing burden/advantages). I don't see why the strategy pattern is particularly interesting here (but I see why imperative structures like mutable arrays and associative arrays are interesting). I don't see either why I would especially forget all those design patterns outside of imperative code : for instance the presentation of Connal Elliot "Tangible Functionnal Programming" is a great exemple of the use a kind of MVC pattern precisely to avoid using imperative constructs.

For me at least, the balance lies more in the use of state (easy in python) or the cost of abstraction (no inling and TCO).

Dude, it's a joke. Going to one extreme (trying to write Haskell-style code in Python), then the other (OOP code dripping with Design Patterns), then finding a balance.

(I know what he's talking about with Haskell-in-Python, though. I did that. Briefly.)

Learn to simplify and beautify.

We learn new tricks just to make our code simpler and prettier. As a side effect, we code faster and with less bugs.

Reply on news.ycombinator.com