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 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.
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.
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.)
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.
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.
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.
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.
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.
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.)
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.)
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).
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.
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).
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.
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.
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 :)
