The depth and breadth of Python | Hacker News Reader

The depth and breadth of Python

neopythonic.blogspot.com

204 pointsfogus41 comments

We've disassembled and decompiled the "obfuscated" bytecode, and we have to say that a few of their constructs are very interesting. The custom memory allocator is very nifty, and along with a few other things gleaned from their binaries has proven very useful and educational to take apart and discover.

When I read the article, I wasn't very convinced the obfuscated Python bytecode couldn't be decompiled. There have been Python bytecode decompilers around for years.

Has there been any research done on programming language readability for non-programmers? I think that that would be extremely interesting.

Interesting for sure but what purpose would it serve?

Programming languages are meant for programmers. A survey of non-programmers on programming would be something on the lines of non-math people on math symbols.

Every programmer starts as a non-programmer. Every mathematician starts as a non-mathematician.

So in both cases, it'd be extremely useful.

Professional mathematicians and professional programmers are small groups. They're surrounded by very many people who do a bit of math or a bit of code to get things done. Helping them is extremely valuable.

> So in both cases, it'd be extremely useful.

Assume all those surveyed say they don't like what they see in Mathematics at all - its all greek symbols and stuff. And then we do what? The current practices have originated from long research and its the best we have right now. For beginners, things are simplified in both programming and mathematics.

The current practices have originated from long research

Technically true, but only in the sense of "have originated as a side effect of long research in other things", rather than "have originated from long research into the most efficient or easily understood practices".

> "have originated from long research into the most efficient or easily understood practices".

Agreed. But judgement can't be passed on efficiency and/or clarity based on opinions of people who don't follow the trade.

If we are talking about Mathematics, its going to look strange to people who don't follow it. Weird symbols and horrifying looking formulae are the most efficient and clear form of describing Mathematics - and its actually pretty clear to people who follow them.

> Assume all those surveyed say they don't like what they see in Mathematics at all - its all greek symbols and stuff. And then we do what?

Go to Adobe and get them to create the ColdFusion equivalent for Mathematics!

But ColdFusion didn't change much. And the abstractions it provides are generally frowned upon and ultimately, you need to learn what lies beneath. Doing that for Mathematics would be a bad idea. I can't find the reference but it was Feynman or someone who said something about that we have to let go of the idea that I am here to show you why Mathematics or Physics is fun. Mathematics is fun but it requires work on your part. If it seems cruel, that isn't so to torment you - that's how it is. There are shortcomings and people work consciously to overcome them.

There always is room for improving mathematics or programming or anything for that sake. But why not aim at converting the non-programmers to programmers(which takes work - a lot of work) and then working at optimizing programming for programmers? It seem like a better option than transforming programming to suit non-programmers.

I think that a programming language that is easy for non-programmers to read might be easier to learn. When I learned Python, it took me significantly less time to internalize its syntax than with C.

In the case of your example, not just easier to learn, but far easier to use on a daily basis to get things done (unless the things you need to do are mostly things that need to run faster than Python can go without lots of tweaking).

Which suggests a correlation between a language being easy for beginners to learn and being productive for advanced coders.

I've heard an argument that Python, of the widely used languages, comes closest to being "executable pseudocode", simultaneously actually code and yet readable as an informal algorithm description. It'd be interesting to know if that were true.

Among others, Norwig has said(on HN; can't find the thread but it was the thread about "Ask PG: Lisp vs Python") about close mapping between his pseudo code and Python code. Personally, I find it true.But I also find it true for Ruby, Clojure and other high level languages.

If we are talking non programmers, I am afraid this close mapping would mean anything to them. Isn't it more or less about how similar programmers find the pseudo-code and the implementation?

If there's one thing I've learned from studying programming languages, it's that human minds are extremely diverse, especially when it comes to designing notations.

For some programmers, their 'executable pseudocode' language is Haskell, or Forth, or maybe even the assembly language of some specific piece of hardware. Some people might naturally think in COBOL.

Also, the problem domain can dictate some of the shape of the language: Something that's built out of a mathematical expression is almost always going to be expressed most compactly as that expression in standard mathematical notation, with something like APL coming close to being the 'executable pseudocode' form of that program. That said, there are almost always many ways to solve the same problem.

I haven't actually programmed in Haskell, but once I started reading about it, my pseudo-code started to look like it, especially type declarations and inline conditionals. Other times, I use more Python-y (won't say Pythonic) syntax.

So even in one person, it can vary.

CoffeeScript might give it scare.

Do it on people just learning to program. They don't have any preconceived notions of what is a block and the research would be more valuable.

Would someone please explain what he means by "pattern matching" in this context?

The discussion in Learn you some Erlang is probably good enough: http://learnyousomeerlang.com/syntax-in-functions

Python already has something accessible and similar in it's tuple unpacking. For example it allows:

a,b,c = (1,2,3)

Here the variables are being filled by values from the tuple based purely on their position within it.

Pattern matching takes this a few steps further by allowing you to mix known values into things and combine dispatch from those values with variable assignment.

For example, imagine that Python had the following Python expression give a true/false value based on if the elements match:

"test", a, b = ("test", 1, 2) # would evaluate to True and bind a=1, b=2

"test", a, b = ("nope", 1, 2) # would evaluate to False and would not bind a or b

This can clean up a surprising amount of code, especially if you structure a case statement around it.

The double-whammy is when you allow a function to be defined multiple times so long as each definition has a different pattern match in the variable declaration. The Erlang article I linked to covers this topic pretty well.

It's a feature in Erlang - this is a reasonably brief explanation:

http://learnyousomeerlang.com/syntax-in-functions

You can think of it as a smart way of doing a switch statement that takes the number and type of arguments in to account - though that's a huge simplification.

Interesting that the two replies so far cited the exact same URL to answer your question.

Pattern matching is the process of defining multiple functions with the same number of arguments, where the arguments decide which function to execute.

E.g.: foo(0) -> 1; foo(n) -> foo(n) * foo(n-1).

calls to foo(0) would execute the first function, while all other calls would execute the 2nd. Note that it is often necessary to define the functions in order of most specific first.

A similar concept in Erlang is guards, where an expression can be evaluated instead of simple pattern matching.

foo(n) where n == 0 -> 1; foo(n) -> foo(n) * foo(n-1).

Might have screwed up on the Erlang notation in that example though.

This is why you don't write code before your morning shot of caffeine (unending recursive function calls). Meh.

I have to admit, that life does sound awesome.

If any of the Dropbox folks are around, why not wxPython everywhere? Why the switch to the PyObjc?

IIRC, I read somewhere that wxPython didn't get completely native looking UI elements, or didn't support some of the native OSX UI paradigms that they wanted to use. Their goal was to get 100% native UI and UX on each platform, and the only way to do that on OSX was with PyObjc.

Cocoa support in wxPython is coming along but isn't 100% there yet:

http://groups.google.com/group/wxpython-users/browse_thread/...

wxPython didn't look native enough is the reason I've been given by the Dropbox folks.

So if there are changes I'd like to see in Python, I should lobby Guido in person?

Yes I know, Python has a fairly decentralized control structure and a nice open process in the form of PEPs. There was just something about this post that made me a bit uncomfortable...scratching phantom itches from old, somewhat exotic languages...

I don't know, but I recall this post from 2003 which still seems relevant here: http://code.activestate.com/lists/python-list/326948/

http://en.wikipedia.org/wiki/Benevolent_Dictator_For_Life ?

No, you write down a detailed proposal and send it to the python-ideas mailing list, which Guido mentioned in this post. The decision making process in Python is fair and egalitarian. It's useful to have a "dictator" to give the final rule on difficult decisions every once in a while, because we all are engineers who get bogged down in design alternatives which don't always end up being conclusive. Guido has never really forced himself on the community. Sure, any new ideas he brings to the table will be taken more seriously, but so would ideas brought by other senior core-devs. It's a meritocracy, after all!

Pattern matching in python sounds like a GREAT idea.

That would be incredible, I really miss pattern matching when writing Python code. Fitting it into the existing style of syntax and the language semantics is a problem though.

Pattern matching in list comprehensions would be awesome too. List comprehensions are very cool in Python but they're so much cooler in Haskell :)

I was just reading a bunch of older articles from 2009 lamenting MIT changing their intro course from Scheme to Python. I wonder if this sort of article would have been helpful in that debate.

I doubt it. The debate wasn't an indictment of Python, but rather resistance to the idea of replacing SICP (of which Scheme use was simply an implementation detail) with anything else.

I love Python as a language, but I am frustrated by its dynamic typing. I'm surprised there has been more research into static type inference for Python (and JavaScript). Google App Engine's Python libraries implement manual type checking of API parameters (with typeof and exception raising) to make the APIs harder to misuse.

The Boo programming language is heavy influenced by Python, but includes static typing and type inference. Unfortunately, Boo requires the .NET Runtime.

Too bad -- I guess dropbox isn't doing anything to get efficient what's-changed notifications from the OS, then (since the only platform-specific code is the UI). Because those hooks are not at all cross-platform.

/probably obvious to all you actual dropbox users

UI isn't the only platform-specific thing in the code; we have a bunch of (non-Python) native code on each platform to monitor filesystem changes.

Totally unrelated request - you posted your YC application a few years ago, but the link 404s. If this is intentional, you can forget it, but if not, I'd really would like to see it,

Link in question is: http://files.dropbox.com/u/2/app.html

Original submission: http://news.ycombinator.com/item?id=801503

Thanks in advance! Dropbox is really an amazing product, even to techies.

Funny, I remember Prof. Hilfinger going off on about style during a lecture for a course using Java.

Reply on news.ycombinator.com