The Python Paradox
paulgraham.com
paulgraham.com
Yes, I know I can make my code look cleaner in Ruby, but I'm lazy. Call me shallow, but sometimes not having to type in blocks and "end" is kind of nice because of the inherent indentation constraint. And that indentation makes it easier to find lexical scope hierarchy easily too (at least for me). YMMV :-)
I'm not saying this is bad. It just is.
I mentioned some of the reasons I stuck with Python here: http://news.ycombinator.com/item?id=1941594
Where _language_ is concerned, I think Ruby is every bit as nice as Python if not nicer.
To folk claiming PHP is to programming what white bread is to a healthy colon, I say that you are the inferior programmer for not being able to love it.
My claim is this: PHP (and most certainly Perl) are to web application development what paint is to painting.
Web application frameworks written in Ruby and Python are to web programming what paint by numbers is to painting.
I never mentioned any context of web in my statement. Au contraire, python's greatest strength is in its vast number of libraries for non-web stuff as well (though it can handle a lot of web stuff very easily). I find python's vast science and math packages to be very handy.
PHP, or Python, or Perl, as a language are to web applications what paint is to painting. CakePHP, or Symfony, or Rails, or Django is to web applications what paint + scaffolding + tarpaulins + masking tape + ladders is to painting.
Yes, you can build a ladder in the programming language you like, or you can just import one (or, in many cases, not have to) with a framework. They both still use paint, and I completely disagree with the assertion that a framework tells you where or what kind of paint to put -- it just puts you closer to the walls, and makes the application of said paint a little easier.
For the record, I personally consider an application framework more like a Wagner spray painter, or something more like that, but I think that's more dependent on the framework itself. Yes, there are constraints with frameworks, but there are significant advantages to speed of development.
As for the whole PHP vs Python, I'm completely ignoring, since you seem to be conflating PHP vs 'application frameworks in other languages' instead of PHP vs 'another language', which is unfair at best, and ill-informed at worst. For what it's worth, I'd put either Ruby or Python up as a general purpose language above PHP any day of the week, and PHP is the language I learned to program on (and still like, despite its unpopularity.)
There are two different ways languages accomplish this.
Smalltalk and Lisp accomplish this through odd-looking minimal syntaxes. The code may not look like anything familiar (outside of longish intention-revealing names) but there are so few syntactic rules to process that a smart person should be able to master them in a few days or weeks at most. (Despite the lack of familiar operator precedence for arithmetic operations.)
Python and Ruby accomplish this by having moderate amounts of syntax. (Ruby has about 3X more syntax than Python, but you can ignore much of Ruby syntax for general purpose programming and leave it in the "sysadmin toolshed.") However, the moderate amounts of syntax are designed to closely resemble pseudocode your professor used to scrawl on the chalkboard. Hence, the language can stay out of the way while you focus on the problem domain.
On the other end of the spectrum are languages that expose everything. C, C++, and Assembly are like this. Everything is available in raw form or as powerful and arcane tools. The beginner might be a little lost, but the rewards to the virtuoso are tremendous.
This is an oversimplification, of course. Python and Ruby also give the power-programmer access to powerful, arcane, and easily-abused tools. It's also quite possible to write very clean pseudocode-resembling code in C or C++. (See the Taligent coding standards.) The difference is really only in design-focus of the languages. (Smalltalk as another example. Smalltalk was designed to be simple to the complete novice -- as in a grade school aged kid. This is why it's minimalist, yet manages to look odd to the hard-core Unix geek.)
I describe it to people as 'feng-shui' for computers. I'm surprised I've not seen that concept mentioned more in connection with programming. Python is probably my favourite language. Probably due to the white-spacing more than anything. And lack of those damn brackets.
It seems with so much writing on how to effectively program computers, something has been lost - namely what it feels like to do so.
Doesn't show the past submissions of this article.
site:news.ycombinator.com +"the python paradox"
site:news.ycombinator.com http://www.paulgraham.com/pypar.html
When I open up any substantial Lua project, I am flooded with local local local and local. It drives me nuts coming from a Python background. Not only is there that, but they decided to use "end" which is more cluttered and longer than using brackets.
Lua also has no standard oop system which means you have to guess which half-baked version the project is using. I'm sure there are other problems I forgot to mention here.
Purely looking at the language resp. the consistency of the design I would even say that Lua is more beautiful than Python even though Lua has its share of warts. Note that this does not say anything about which language is easier to use in practice (which is Python imho).
But that aside, I think it is important to mention that comparing Lua and Python is a bit like comparing apples to oranges as they pursue different philosophies. Lua gives you just as much as you need but no more. This is the reason why it is so flexible and suited for embedding. Python, on the other hand, is a full blown general purpose programming language with a huge community/ecosystem.
However the main thesis holds true still... just replace python with haskell, erlang, clojure, or some other esoteric language.
The relatively new paradoxers are things like epigram, Agda, coq, ATS; mozart/oz, mercury, factor, io, D, newspeak, imho.
Probably others from emLangCamp:
http://www.oscon.com/oscon2010/public/schedule/stype/Emergin...
note hedge words, reasonably, relatively..
Not that it really mattered that much, you still want to see learning of languages not in the curriculum and no 4-year program will ever cover all the interesting possibilities. We just learned that where "Java, C++, C, nothing else" is a warning sign from one university, "Python, C++, C, nothing else" was the warning sign from that one. You could probably generalize to "C, (Java/C++), exactly one other" and still be right.
edit: I understand that the iOS SDK is well-thought-out and easy to work with, but there could have been an equally good API for Python, Ruby, or (if your argument is performance) one of the more performant lisps. I don't think the SDK alone justifies Obj-C.
edit: sorry, missed your edit. I'd probably agree with you and chc now. Obj-C was a clever hack for its time, but compared to modern dynamic/scripting languages, it's not really that special -- outside from being relatively high-performance due to its C compatibility, as you mentioned.
Obj-C + stringent/verbose coding standards = powerful APIs.
I've been writing Cocoa apps since 2002 and I pretty much love everything about programming on it, from the First Responder chain, the view hierarchy, bindings/observing, the new GC, blocks, properties, etc. (and more I'm forgetting) but I especially like how clear the design patterns are implemented. It's very rare to not know where a particular responsibility lies.
When it comes to the state of Mac/Cocoa programming, my biggest gripe is that Xcode 4 isn't progressing anywhere near fast enough. The IB integration should have happened long ago.
The iOS SDK is elegant and powerful in a different way. There is more syntax. Designs tend toward more exposed entities. However, there is less coupling to particular implementation strategies.
Let's take operations on dates as an example, specifically jumping to "the same day of the next month." This is not as simple as you might think at first, since months vary in length in an arbitrary pattern. In many high-level language libraries, you simply grab your date and you do a single call. (In Ruby: Date.today >> 1) With iOS, you end up having to use 3 different objects. (Calendar, Date, and DateComponents)
Working in Objective-C reminds me of the best of "mainstream" Object Oriented programming from the mid 90's. There is a bit too much arcana, seemingly too many entities, but if you work through some real examples, you find that some good thought was put into things.
Then as I started getting into it, and thinking to myself, yeah, a lot of that cruft is just unnecessary, getting rid of it would be awesome... I tripped over the underscores and passing of self in Python.
If the whole point of your syntax is to get rid of old ugly syntax cruft, don't introduce new ugly syntax cruft at the same time.
We decided to start using python in our agency a couple of years ago. We really love it but since that time we've really struggled to hire good people. Even in a big city like London we can't seem to find python devs that also have the other skills required for the agency world.
When I interviewed for this job we bonded over a shared interest in erlang (4 years ago). You don't need to use it internally but if you have a candidate who is interested in something like erlang, they're (probably) deeply interested in programming.
That's going probably a safer approach. Find people who do have an interest in the more obscure parts of software development (easy to gauge in a phone interview) whilst still practicing a more common language.
My point is that there's a much bigger picture to language choice. I'd rather be trying to find perfect candidates from a flood of ruby cvs than struggling to find any candidates at all from insert lesser known language cvs.
The only problem is the overall systems they wrote were bulky, not efficient and generally over-engineered. Very not hacker like. For example using threads in python, a very big no no that can and does cause many performance issues. Designing python middleware that had no reason to exist other than to be a cool project to build.
And so on and so forth. Painful.
I don't know what you're talking about.
Python requires some command line interaction. You have to edit text files, read online docs, have a mental model of lists, dictionaries, and strings. It doesn't come with a visual IDE, and it feels awfully foreign in a windows environment. Why would a less-than-average developer even bother with such a technology? It doesn't even come from Microsoft.
In fact, it may be that these introductory materials are explicit about basic language concepts which makes learning python so easy — they're not focussed on solving your immediate problem (coding X), but solving the problems you will face over the next few years/decades.
I switch back and forth between Python for small stuff and C++ for stuff where performance is an issue, and writing Python feels like no effort at all.
A few years ago I developed software (engine diagnostic/programming) for a large semi-truck manufacture in the Midwest. Our primary concern when selecting a language for a new product/project was whether or not we could find developers who were competent in that language. That almost always meant we chose Java because that is what our local developer pool was competent in.
Once one can screen applicants, I think you're just as likely to find good Java programmers as you are to find good Haskell developers.
>> I think you're just as likely to find good Java programmers as you are to find good Haskell developers.
>> Once one can screen applicants,
the language seems to blend all the best things, i'm never at a loss of finding a good open source library for python and it's most of all relevant. so even while ruby seems to be really popular at the moment because of the rails framework, python also has equivalent* web app frameworks such as django. i remember reading an article by the creator of python where he was praising the php language for having purpose built the language for the web and how python was more generic and less suited for the web (no reference at the moment), today there are lots of excellent web frameworks for python such as tornado web. so python is modern, it has adapted over the years quite nicely, and most importantly it just lets me do what i need to do.
Programming characteristics are quite different from fashion/lifestyle. It takes much more effort to learn a language than to choose an obscure band to listen to. And the payoff in perceived coolness is also much smaller - see for example http://steve-yegge.blogspot.com/2010/12/haskell-researchers-...