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