Why Reddit uses Python(brainsik.theory.org)
brainsik.theory.org
Why Reddit uses Python
http://brainsik.theory.org/.:./2009/why-reddit-uses-python
5 comments
Sorry, this is not exactly thought-provoking. Why did you all vote up? It boils down to "I have my employees write software in the language I know to be able to control them better." That's not a far-fetched wish for a company owner, but hardly a good reason to choose a language if you expect the language to have a certain impact by itself.
> "I have my employees write software in the language I know to be able to control them better."
You're completely misinterpreting what he is saying.
You're completely misinterpreting what he is saying.
Well, he did say:
"I don’t think we’ve yet hired an employee who knew Python. I just say, “everything you write needs to be in Python.” Just so I can read it. And it’s awesome because I can see from across the room, looking at their screen, whether their code is good or bad. Because good Python code has a very obvious structure. And that makes my life so much easier."
Which boils down to: I make them use python to be able to control them better. It is legitimate for a boss to do that, he pays you after all. But it's hardly groundbreaking new management style or a good criterion for choosing a language.
I also can see why you are sympathetic to this. I know the good feeling when you know the language so well that you can see across a room from the shape on the screen wether it is good code or bad code. I love that myself.
"I don’t think we’ve yet hired an employee who knew Python. I just say, “everything you write needs to be in Python.” Just so I can read it. And it’s awesome because I can see from across the room, looking at their screen, whether their code is good or bad. Because good Python code has a very obvious structure. And that makes my life so much easier."
Which boils down to: I make them use python to be able to control them better. It is legitimate for a boss to do that, he pays you after all. But it's hardly groundbreaking new management style or a good criterion for choosing a language.
I also can see why you are sympathetic to this. I know the good feeling when you know the language so well that you can see across a room from the shape on the screen wether it is good code or bad code. I love that myself.
How does Python help anyone control anyone else better? Especially versus something like Java or C# where you can just replace cogs and not have to train them when you bring on new staff.
Partly because you'll hardly find a python environment where developers are treated like interchangable cogs with a need for constant supervision ("control").
It's more a mindset thing than a language thing - and your vocabulary exposed it better than any second hand description could have done.
It's more a mindset thing than a language thing - and your vocabulary exposed it better than any second hand description could have done.
You can judge better and act accordingly if you now Python very well. That way Steve can control better using Python. Is external to the language, that's why I didn't find their reasoning that interesting, because it is Java or C# for somebody else. It is Steve-centric and not programming language-centric thinking.
> And it’s awesome because I can see from across the room, looking at their screen, whether their code is good or bad
Please tell me this is a joke. He may be able to tell whether the code is unreadably bad, but that's about all.
Please tell me this is a joke. He may be able to tell whether the code is unreadably bad, but that's about all.
In the actually pycon video, he does clear this up and say that he can tell if code is not correct because python programs all look very similar in terms of structure (short lines, small units, etc.) and due to python's required tabbing, its easy to see from his desk whether or not a programmer is following these methodologies.
This is actually true of Lisp and Scheme too, though, since nearly everybody indents their code the same way (how Emacs does it). Code with lots of small functions, long and relatively flat imperative code blocks, etc. has very distinctive shapes.
Come to think of it, that's true for most languages that don't have Java-style static typing annotations interspersed throughout. Functional and imperative code in OCaml or Lua code look noticeably different, too, and there's not a whole lot of stylistic overlap between OCaml, Scheme, and Python's syntaxes. (Lua's is relatively similar to Python's.)
Come to think of it, that's true for most languages that don't have Java-style static typing annotations interspersed throughout. Functional and imperative code in OCaml or Lua code look noticeably different, too, and there's not a whole lot of stylistic overlap between OCaml, Scheme, and Python's syntaxes. (Lua's is relatively similar to Python's.)
I believe Haskell looks different. At least with heavy use of combinators my code looks more like Forth than Python. For me small functions tend to be even smaller in Haskell than Python.
And do notation retains a lot of the typical "block of imperative code" appearance.
Yes. Though it has more in common with "strict functional programming with side effects" than traditional imperative code.
It used to be thought that you could judge someone’s character by looking at the shape of his head. Whether or not this is true of people, it is generally true of Lisp programs.
from pg's On Lisp
from pg's On Lisp
I've noticed in myself and other programmers an unconscious assumption that serious errors have serious symptoms. E.g. we must have fixed all the serious defects by now, because there's nothing obviously wrong with the code.
I've seen this proved wrong time and time again. Have you ever been maintaining some shipped code, and found a crash bug, where you're like: "I can't believe this shipped and we haven't heard about it."
So, I'm probably treating this out-of-context comment more seriously than it deserves, but I like to emphasize the point. Even though there is a set of errors that are detectable from the shape of the source code, there is a much larger set of serious errors that are not.
I've seen this proved wrong time and time again. Have you ever been maintaining some shipped code, and found a crash bug, where you're like: "I can't believe this shipped and we haven't heard about it."
So, I'm probably treating this out-of-context comment more seriously than it deserves, but I like to emphasize the point. Even though there is a set of errors that are detectable from the shape of the source code, there is a much larger set of serious errors that are not.
I moved to Python recently to be able to take advantage of Google App Engine. I love the language and syntax for the reasons mentioned.
No offense but this blogpost is pretty much fluff. All it is is a blatant transcript of the video. I was on the A/V team to help record this. Everyone is better off just watching the video.
Can I encourage you in the future to provide transcript or a best of yourself? I read a lot faster than any sane person talks, I can read on my cellphone while packed in a wall to wall train full of salarymen, and I can read at the office to my heart's content whereas watching video is widely considered not-work-related.
Incidentally: getting me to key points of the talk without requiring 26 minutes of watching low-information-density video is a value-add for me.
Incidentally: getting me to key points of the talk without requiring 26 minutes of watching low-information-density video is a value-add for me.
If I talk to the guys at pycon we might be able to do a transcript if we had another volunteer. I was thinking about doing this after I read this fluff piece.
> Everyone is better off just watching the video.
If they actually want to watch the video. I skim articles. I can't skim a video.
If they actually want to watch the video. I skim articles. I can't skim a video.
We should employ mturkers to transcribe videos. If only ten people pay like 5 cent for it, it should be viable given the low pay of mturkers. (Perhaps the content provider could also do this, as he profits from advertising and the transactions/coordination costs are much lower for this centralised solution.)
"It's extremely expressive, extremely readable, and extremely writable. And that just keeps life smooth."
Something hardcore lispers don't fully understand.
Something hardcore lispers don't fully understand.
They don't understand why "expressive, readable, writable" code is a good thing? I doubt that very much. I think their definition of those terms just differs from yours.
"their definition of those terms just differs from yours."
That is what most people don't understand.
There is a best language. It just varies from programmer to programmer. Also picking the "right" language for the job is overrated. Should pick the "right" language for the developer(or switched around pick devs who's right language is the one your code base is written in.)
That is what most people don't understand.
There is a best language. It just varies from programmer to programmer. Also picking the "right" language for the job is overrated. Should pick the "right" language for the developer(or switched around pick devs who's right language is the one your code base is written in.)
No sarcasm intended: would C++ be a good choice for web development if it feels right for the developer?
In my short experience with several popular languages, there are certain niches for development. E.g. high-level web development (Python, Ruby, Perl), complex enterprise development (C#, Java), video games and embedded (C), general desktop software (C#, C++).
Within the niche, it is perfectly fine to chose any language within niche. However, to use langauges across niches is quite troublesome. No one cares if you use Ruby instead Python to write a web-site but people would raise eyebrows if you use C (counter-example: eBay).
In my short experience with several popular languages, there are certain niches for development. E.g. high-level web development (Python, Ruby, Perl), complex enterprise development (C#, Java), video games and embedded (C), general desktop software (C#, C++).
Within the niche, it is perfectly fine to chose any language within niche. However, to use langauges across niches is quite troublesome. No one cares if you use Ruby instead Python to write a web-site but people would raise eyebrows if you use C (counter-example: eBay).
There's exceptions to all those examples you've given.
Web dev: There is tons of Java web dev junk Tomcat and all that. MochiWeb and Yaws are Erlang web platforms.
Video games: Eve Online is mostly Stackless Python with some C++ libs.
General desktop software: (not sure what this category means) but wings3d is written in Erlang, plenty of examples here http://pypi.python.org/pypi?:action=browse&c=32
Complex enterprise development: I doubt there is such a beast written in only one language. And I argue that Java is used because it is close to best for hordes of programmer drones working for enterprises. The non-hordes are why jruby, jython, scala are becoming popular.
pg did the airline ticket thing in Lisp cause it was best for him.
You claim short experience and reiterate long held stereotypes. I claim 20 years of experience and see a vastly different picture than you do.
Web dev: There is tons of Java web dev junk Tomcat and all that. MochiWeb and Yaws are Erlang web platforms.
Video games: Eve Online is mostly Stackless Python with some C++ libs.
General desktop software: (not sure what this category means) but wings3d is written in Erlang, plenty of examples here http://pypi.python.org/pypi?:action=browse&c=32
Complex enterprise development: I doubt there is such a beast written in only one language. And I argue that Java is used because it is close to best for hordes of programmer drones working for enterprises. The non-hordes are why jruby, jython, scala are becoming popular.
pg did the airline ticket thing in Lisp cause it was best for him.
You claim short experience and reiterate long held stereotypes. I claim 20 years of experience and see a vastly different picture than you do.
Another counter-example: okcupid.com
Apparently their site is ~200k lines of C++
http://en.wikipedia.org/wiki/OkCupid#Technical
Apparently their site is ~200k lines of C++
http://en.wikipedia.org/wiki/OkCupid#Technical
Certain languages are clearly better suited to some niches, though. I just learned awk, and, in retrospect, it's obvious that I've reimplemented a subset of it in every other language I've used* . Sure, it's designed specifically for processing semi-structured textual data, but that's a surprisingly common situation. (Unix, man!) Since it's clearly a niche tool, it can dispense with a lot of boilerplate, and everything I need to know to use it fits in about 30 pages. (I've already written a couple useful three-line programs in it.) Likewise, if I have to calculate dependencies in a DAG, make immediately comes to mind.
I think the real problem is languages that don't have clear mechanisms in place for co-operating with other languages (and their libraries). Without an FFI or other integration, you're stuck with a languages' weak points. It's too easy to get bogged down rewriting everything in Lisp (or whatever).
* Granted, I don't like Perl (the heart of which is a sort of sprawling mega-awk).
I think the real problem is languages that don't have clear mechanisms in place for co-operating with other languages (and their libraries). Without an FFI or other integration, you're stuck with a languages' weak points. It's too easy to get bogged down rewriting everything in Lisp (or whatever).
* Granted, I don't like Perl (the heart of which is a sort of sprawling mega-awk).
Lisp is also expressive, readable, and writable.
Honestly, Python claims to sacrifice expressiveness and writibility for readability. That whole "there's only one way to do things" is the opposite of expressiveness.
If you want to optimize for writibility and expressiveness, you want a language that won't prevent you from doing anything you want to do. Lisp is definitely one of these languages.
Anyway, your comment reads of blatant fanboi-ing. If you like Python, that's great, just say that instead. It's much better than inventing bullshit "reasons".
Honestly, Python claims to sacrifice expressiveness and writibility for readability. That whole "there's only one way to do things" is the opposite of expressiveness.
If you want to optimize for writibility and expressiveness, you want a language that won't prevent you from doing anything you want to do. Lisp is definitely one of these languages.
Anyway, your comment reads of blatant fanboi-ing. If you like Python, that's great, just say that instead. It's much better than inventing bullshit "reasons".
Not taking sides here, just bringing up a potential counterpoint. I like Python, Lisp and a fair few other languages as well.
From my understanding, the "there's only one way to do things" idea generally applies at the smaller scales, so an argument could be made that it helps with expressiveness at larger scales, since once you know the idioms you don't need to choose between them - ie you can just type it in and keep going and save the mindspace that making a choice between the multiple equivalent options would have required.
Of course, that only makes sense if the "one way to do things" is eliminating choices that are 100% functionally identical, and you can also get bitten if you need something just outside of what the idiom can do nicely, but I thought it was a point worth bringing up.
From my understanding, the "there's only one way to do things" idea generally applies at the smaller scales, so an argument could be made that it helps with expressiveness at larger scales, since once you know the idioms you don't need to choose between them - ie you can just type it in and keep going and save the mindspace that making a choice between the multiple equivalent options would have required.
Of course, that only makes sense if the "one way to do things" is eliminating choices that are 100% functionally identical, and you can also get bitten if you need something just outside of what the idiom can do nicely, but I thought it was a point worth bringing up.
Expressiveness isn't about saving time discriminating among different options. That's more like a form of simplicity. Expressiveness is a soft quality and is about being able to convey the thought or feeling of an algorithm in a natural way to a human. This helps when you're reading code and when you're conjuring up the code in your head.
Functionally identical patterns of code are not equivalently expressive. Certainly the computer doesn't care, but code is written for humans first and foremost. The more ways I can express a functionally equivalent operation, the more expressive the language is. This is because (ideally) each of the different ways has a unique feeling to it that evokes the right intuition needed in the right contexts.
Functionally identical patterns of code are not equivalently expressive. Certainly the computer doesn't care, but code is written for humans first and foremost. The more ways I can express a functionally equivalent operation, the more expressive the language is. This is because (ideally) each of the different ways has a unique feeling to it that evokes the right intuition needed in the right contexts.
All good points which I agree with.
It appears that we were using different meanings for expressiveness though - yours was focusing on communicating both the feel and the function of the code, mine was focusing on communicating efficiently[1].
I don't think that they're orthogonal, and I'm not sure at the level that "there's only one way to do anything" is normally applied in Python that it negatively effects either, especially since the implied full version seems to be "there's only one way to do anything if you don't have a reason to do differently".
Not that it helps with communicating the feel of an algorithm, but at least it doesn't necessarily hurt. I was only trying to point out that "there's only one way to do things" may not actually be the opposite of expressiveness. Liberally applied it's possibly neutral or better.
[1] An argument could be made that accurately communicating the feel of the code is the most efficient way to communicate it, although I'm more concerned with the time it takes both to read and to write the code - surely at some point of massaging your code for readability you reach the point diminishing returns :)
It appears that we were using different meanings for expressiveness though - yours was focusing on communicating both the feel and the function of the code, mine was focusing on communicating efficiently[1].
I don't think that they're orthogonal, and I'm not sure at the level that "there's only one way to do anything" is normally applied in Python that it negatively effects either, especially since the implied full version seems to be "there's only one way to do anything if you don't have a reason to do differently".
Not that it helps with communicating the feel of an algorithm, but at least it doesn't necessarily hurt. I was only trying to point out that "there's only one way to do things" may not actually be the opposite of expressiveness. Liberally applied it's possibly neutral or better.
[1] An argument could be made that accurately communicating the feel of the code is the most efficient way to communicate it, although I'm more concerned with the time it takes both to read and to write the code - surely at some point of massaging your code for readability you reach the point diminishing returns :)
If they don't understand something, I'd say it's having the libraries, but I think they understand that.
Huh? Lisp is very expressive, readable, and writable.
There is a second reason - availability of reusable modules and it is that matters.