Saying goodbye to Python(ianbicking.org)
ianbicking.org
Saying goodbye to Python
http://www.ianbicking.org/blog/2014/02/saying-goodbye-to-python.html
26 comments
I like how you squeezed in that subtle dig at PHP. It's like you like the idea of being language agnostic just as long as it doesn't involve languages you don't like.
I don't read that as being a "subtle dig at PHP". There are many very legitimate reasons for a developer, especially one well-versed in many languages, to not want to use PHP.
And his position is very reasonable. He doesn't seem to care if you use PHP, if it works for you. But he doesn't like using PHP himself, for whatever reason(s), and wishes to not use it. His abstinence from PHP doesn't prevent or affect your (or anyone else's) use of it.
And his position is very reasonable. He doesn't seem to care if you use PHP, if it works for you. But he doesn't like using PHP himself, for whatever reason(s), and wishes to not use it. His abstinence from PHP doesn't prevent or affect your (or anyone else's) use of it.
That's not what he's saying. He's basically saying that it's 0K to use PHP if you can't use anything else because you are not smart enough. And you won't even achieve great things, you will barely be able to build something.
PHPers like me know very well this kind of trolling (after years of suffering it), but we are also way above it already. Sometimes we want to reply, but then we remember that this trolling is born from bitterness and lack of success, so we just let it be.
PHPers like me know very well this kind of trolling (after years of suffering it), but we are also way above it already. Sometimes we want to reply, but then we remember that this trolling is born from bitterness and lack of success, so we just let it be.
> not smart enough
That's not what I said.
I was trying to point out a good side of a language that I do not particularly care for.
Think about it this way: there are plenty of smart people with good ideas who, however, are not programmers. Doctors, accountants, architects, physicists... whatever. A system that has a low barrier to entry so that these people can create something is a positive thing to have.
And if programming PHP floats your boat, that's fine too.
That's not what I said.
I was trying to point out a good side of a language that I do not particularly care for.
Think about it this way: there are plenty of smart people with good ideas who, however, are not programmers. Doctors, accountants, architects, physicists... whatever. A system that has a low barrier to entry so that these people can create something is a positive thing to have.
And if programming PHP floats your boat, that's fine too.
With respect, I'm a proud PHP developer who does crazy things like use a Lisp that compiles to PHP to build services; I am working on some awesome stuff to take advantage of Composer and the new modular PHP Library systems, and all sorts of other stuff. I love working in PHP, and I'm not ashamed to admit that, despite having written my own languages, and being partial to C. My current favourite to work with is nimrod...
Anyway, the point is: you completely read the OP wrong, in my opinion, and I'm the person that would be most offended if it was a dig...
Anyway, the point is: you completely read the OP wrong, in my opinion, and I'm the person that would be most offended if it was a dig...
I'm not sure you'll be able to read his post properly while you do it through the chip on your shoulder.
Or maybe it's you the one who can't read it properly? Else explain to me what he meant by this: "PHP made it very easy for a lot of people to do something with the web, something that otherwise they might not have been able to do"
a lot of people != all php users.
a lot of people != the majority of php users.
> we are also way above it already
Are you sure about that?
Are you sure about that?
I do python and scala at work yet I love php, it's made a ton of difference to the web (think wordpress for example) - it's perfectly possible to write killer php and do everything from machine learning to webapps. PHP has the best date extractor of any language that i've seen.
> There are many very legitimate reasons for a developer, especially one well-versed in many languages, to not want to use PHP.
Like what? I feel there are many reasons why it is a dangerous language for a novice, but if you can be productive with C/Java/Python/Go/YouNameIt, you can probably write nice, maintainable and reliable PHP.
If you're talking about technical difficulties or elegance or whatever, sure. I'll just go with the Facebook argument. I've bootstrapped many projects for companies who aren't made of über hackers, and going PHP guarantees them they can very easily find people who can pick-up the code later on. Also, any * hosting will run your code.
I think nowadays, ideally, I'd just use Go for everything. But in reality, productivity > idealism.
Like what? I feel there are many reasons why it is a dangerous language for a novice, but if you can be productive with C/Java/Python/Go/YouNameIt, you can probably write nice, maintainable and reliable PHP.
If you're talking about technical difficulties or elegance or whatever, sure. I'll just go with the Facebook argument. I've bootstrapped many projects for companies who aren't made of über hackers, and going PHP guarantees them they can very easily find people who can pick-up the code later on. Also, any * hosting will run your code.
I think nowadays, ideally, I'd just use Go for everything. But in reality, productivity > idealism.
I don't think OP is talking about absolute neutrality. It is more about maintaining a perspective. (Which usually includes understanding/acknowledging the good and bad parts)
He's stating a personal opinion. The only way that becomes a subtle dig at PHP is if you make it such.
Yeah, at this point I actually find it amusing just how much flack PHP gets from people on HN who only think about it in terms of Wordpress and spotty 15 year olds trying out web dev for the first time.
The same happens with everything, some people just choose to be ignorant. Another good example of this is the irrational hate Bitcoin gets.
I think at this point PHP programmers don't care about the flack. We're pretty used to it.
As a php programmer and a member of a php user group I can say that group seeems to have half of its talks on non php topics javascript, html5, css etc.
I like the community that doesn't fret about tools and only about how to build something interesting.
As a php programmer and a member of a php user group I can say that group seeems to have half of its talks on non php topics javascript, html5, css etc.
I like the community that doesn't fret about tools and only about how to build something interesting.
I think PHP was used an example of a language that is a total train wreck from a technical standpoint (and I don't think many people would disagree with that.) Despite being a train wreck, PHP is still useful and has been a net positive for the tech industry. Plus all the work that Facebook has done in fixing PHP has turned it into something better than it was.
I miss my Apple II days. I miss Applesoft BASIC, GPLE and Take-1 Programmers Toolkit. I am glad I'll never need to program with those again unless I want to.
Ahhhh AppleSoft + whatever graphical extensions, GPLE, Toolkit Assembler (there was another assembler but I don't remember its name), Pascal UCSD in 80 columns,cp/m,... Memories...
Doesn't it really just depend on what you focusing on and choosing the best language for that. I prefer python, but have written a lot of objective c, i created a search engine and ended up using lucene, nutch, opennlp and a few other Java programs and i really liked working with java and it seems like the Apache projects are really cool for big data projects. I also enjoyed javascript when i used it to create an api for an ios app but since i spend most of my time doing machine learning now, python is where the datascience community is and i love the opensource tools they create like ipython notebook, pandas, scikits, etc... So i just never get the staunch stance people take over languages but maybe its about being a "master" in a language and i am definitely not anyway near being a master in python.
Choice of development language is realistically more of a business decision than a technical one. With the proliferation of REST APIs, there are no longer really any technical hurdles to using any language.
Scalability can be an issue, but honestly business scalability is a problem for most businesses long before technical scalability is. Ruby and Python are awesome, but it can be hard to scale a company with one of those languages because it's hard to find good programmers who know Ruby or Python. It's much easier to find good Java or C# developers.
At this point, given all the work the Apache foundation has done to make Java awesome, I don't really know I would consider another language from a business standpoint. Sure, from a technical standpoint Java isn't that exciting; but it's easy to scale, easy to hire for and relatively standard across a number of platforms. Java code is also relatively easy to maintain since it forces you into certain design patterns.
There are some domains where this wouldn't hold true (and data science is definitely one of them -- you'll have an easier time hiring a machine learning expert who knows Python than Java) but that's really just technology. In a production environment, you'd eventually wrap your Python code in REST APIs and write all the ETL and interface code in Java.
Scalability can be an issue, but honestly business scalability is a problem for most businesses long before technical scalability is. Ruby and Python are awesome, but it can be hard to scale a company with one of those languages because it's hard to find good programmers who know Ruby or Python. It's much easier to find good Java or C# developers.
At this point, given all the work the Apache foundation has done to make Java awesome, I don't really know I would consider another language from a business standpoint. Sure, from a technical standpoint Java isn't that exciting; but it's easy to scale, easy to hire for and relatively standard across a number of platforms. Java code is also relatively easy to maintain since it forces you into certain design patterns.
There are some domains where this wouldn't hold true (and data science is definitely one of them -- you'll have an easier time hiring a machine learning expert who knows Python than Java) but that's really just technology. In a production environment, you'd eventually wrap your Python code in REST APIs and write all the ETL and interface code in Java.
This is probably one of the most excellent argument with respect to why we choose mainstream technology I've ever read.
You're on the money with Apache foundation (and other great quality tools/libraries/software written in Java). The ecosystem is just too huge to ignore. The other day we saw ElasticSearch at the top of HN when they announced they just released v1.0.0. I know tons of hi-tech companies are using it.
Meanwhile, there's no group or organization that invest in Ruby or Python the way Apache does to Java.
It's kinda sad. I really really wish (and want to see) similar thing happen to Ruby/Python but it's 2014 and sadly it hasn't happened. Outside Rails, I don't see anything else in the Ruby world that reach that level of adoption (maybe Jekyll or Octopress). Django seems to become minority. Plone seems to quiet down. Turbogears is probably dead. Flask is on the rise. Twisted doesn't seem to be the defacto solution.
Just that in general, Ruby or Python community seems to be locked on CRUD for web-app but nothing else.
You're on the money with Apache foundation (and other great quality tools/libraries/software written in Java). The ecosystem is just too huge to ignore. The other day we saw ElasticSearch at the top of HN when they announced they just released v1.0.0. I know tons of hi-tech companies are using it.
Meanwhile, there's no group or organization that invest in Ruby or Python the way Apache does to Java.
It's kinda sad. I really really wish (and want to see) similar thing happen to Ruby/Python but it's 2014 and sadly it hasn't happened. Outside Rails, I don't see anything else in the Ruby world that reach that level of adoption (maybe Jekyll or Octopress). Django seems to become minority. Plone seems to quiet down. Turbogears is probably dead. Flask is on the rise. Twisted doesn't seem to be the defacto solution.
Just that in general, Ruby or Python community seems to be locked on CRUD for web-app but nothing else.
Ruby and Python are awesome, but it can be hard to scale a company with one of those languages because it's hard to find good programmers who know Ruby or Python.
Good programmers usually become good python programmers quickly if it has become their day-to-day job. But maybe we have different levels in mind when we say "good".
Good programmers usually become good python programmers quickly if it has become their day-to-day job. But maybe we have different levels in mind when we say "good".
I think we do.
While I would love to hire a bunch of elite hackers who are able to adapt to any language in a week, the reality is that most of those guys work for Google or Facebook and aren't interested in writing code for business apps (and probably wouldn't stick around anywhere early in their career for more than a year or so anyway). What you end up being able to hire are the B students from CS programs at good state schools (Texas, Michigan, etc.) They're not bad developers by any means, just not uber-hackers.
A lot of these guys are developers because it pays well and affords them a comfortable life for them and their (potentially future) family, not because they love technology. And there's nothing wrong with that.
While I would love to hire a bunch of elite hackers who are able to adapt to any language in a week, the reality is that most of those guys work for Google or Facebook and aren't interested in writing code for business apps (and probably wouldn't stick around anywhere early in their career for more than a year or so anyway). What you end up being able to hire are the B students from CS programs at good state schools (Texas, Michigan, etc.) They're not bad developers by any means, just not uber-hackers.
A lot of these guys are developers because it pays well and affords them a comfortable life for them and their (potentially future) family, not because they love technology. And there's nothing wrong with that.
Php is easy and getting more complex every day. With x/y/z framework nowdays,newbies will struggle to understand php same as other programming language.
As a beginner PHP is still way easier to get started with for Web Development. I can take a new machine, or shared hosting and be pretty confident that I can get a PHP "Hello World" on a web page working. I'm still not sure what is the best or easiest way to do that in Python[1], although I've been using it quite a lot for more general stuff.
[1]: http://docs.python.org/2/howto/webservers.html
[1]: http://docs.python.org/2/howto/webservers.html
In the past 6 months I've switched from a mostly Python job to a mostly Go job, but I think I'll always consider myself part of the Python community. It's a positive and vibrant community.
Ian's participation in the Python community has been - and will continue to be - missed. I hope he brings the same wisdom and humility to the splintered Javascript community he brought to Python.
Ian's participation in the Python community has been - and will continue to be - missed. I hope he brings the same wisdom and humility to the splintered Javascript community he brought to Python.
If I may ask, how should I find Go jobs?
Same way you find a job in any field you are interested in. Find some companies that are using it[1], find their job page, apply.
To pick out a few companies hiring, where I use their services so want them to succeed:
https://www.docker.io/jobs/
http://careers.mozilla.org/en-US/listings/
http://www.cloudflare.com/join-our-team
[1] https://code.google.com/p/go-wiki/wiki/GoUsers (Note that Google isn't on that list. Pretty sure they use it a bit, and are hiring..)
To pick out a few companies hiring, where I use their services so want them to succeed:
https://www.docker.io/jobs/
http://careers.mozilla.org/en-US/listings/
http://www.cloudflare.com/join-our-team
[1] https://code.google.com/p/go-wiki/wiki/GoUsers (Note that Google isn't on that list. Pretty sure they use it a bit, and are hiring..)
FWIW we are a Go shop (well, mostly) and are hiring. Check out cbinsights.com/jobs if you're interested.
The same way you find any job? If they advertise they use Go, you know they are interested in Go programmers too. If they don't, still put it in the resume?
I'm terrible at job hunting and didn't know how to answer when people would ask me how to find Python jobs. There's only one method that has worked consistently for me:
- I met a founder from Lytics (my current mostly-Go job) at a Go meetup.
- I met a couple of the founders from Urban Airship (my previous mostly-Python job) at a Python meetup.
So I guess going to meetups is what works for me, but I don't think that's a general solution. Sorry I can't be more help.
- I met a founder from Lytics (my current mostly-Go job) at a Go meetup.
- I met a couple of the founders from Urban Airship (my previous mostly-Python job) at a Python meetup.
So I guess going to meetups is what works for me, but I don't think that's a general solution. Sorry I can't be more help.
going to meetups is what works for me, but I don't think that's a general solution
Personally I think it's a pretty good solution.
Personally I think it's a pretty good solution.
Keyword being "personally." :)
There are lots of people for whom it probably doesn't work. It takes a certain personality, and it really helps to be a white male. Minorities are often treated differently at meetups, so I don't want to presume that my experience in a privileged position applies universally.
There are lots of people for whom it probably doesn't work. It takes a certain personality, and it really helps to be a white male. Minorities are often treated differently at meetups, so I don't want to presume that my experience in a privileged position applies universally.
Fair point - and yes, it's a pity that minorities are treated differently (although it does work both ways a bit, too[1]).
I suspect those difference also apply in formal interview situations - and maybe even more difficult to overcome there. Maybe meetups have better potential to overcome negative sterotypes because people actually get to know each other a little?
But white male here too, so what do I know.
[1] http://www.slate.com/articles/technology/technology/2014/01/...
I suspect those difference also apply in formal interview situations - and maybe even more difficult to overcome there. Maybe meetups have better potential to overcome negative sterotypes because people actually get to know each other a little?
But white male here too, so what do I know.
[1] http://www.slate.com/articles/technology/technology/2014/01/...
I've switched from Python to Go for about a year and so far have no regrets. Still write some Python here and there, but nothing serious anymore. The whole debate about Python 2 and 3, performance issues, GIL, etc made me give up.
Wisdom? maybe, I don't know. But humility? well, long ego trip posts about ones achievements and future achievements are not exactly artifacts for humility, in my papers. And the usual downtoning of one's achievements in this article is only making matters worse.
Oh by the way, this comment is not against the author, it's against humility-as-a-value. I think we've gone too far here. The creator of virtualenv and pip do not have to force himself showing humility, he should be proud. There's nothing wrong in being proud of one's achievements.
[grammar edited]
Oh by the way, this comment is not against the author, it's against humility-as-a-value. I think we've gone too far here. The creator of virtualenv and pip do not have to force himself showing humility, he should be proud. There's nothing wrong in being proud of one's achievements.
[grammar edited]
I think this post is really addressed at the Python community, and I would be surprised if anyone in that category that has interacted with Ian over the years would interpret any of this as an ego trip and fake downplaying of achievements.
The person you replied to wasn't specifying that he valued Ian Bicking's humility in that specific blog post, but his general demeanour within the Python community.
Ok, possibly. But even then, I hope I am not the only one to have noticed a trend where many people in the tech community declare themselves "humbled" or display some humility in one form or another.
So, Ian Bicking aside, I think it is an interesting topic. Some notes:
- Like real generosity do not display itself, real humility hides itself. Or should.
- Humility (or some expressions of it) can be seen as a Middle-age Christian value. Jesus-Christ himself was all but humble, but in European Middle-Ages and after, there was a few movements trying to show unlimited submission to God's will, and humility was proposed as a core value.
- While I understand the pro-humility trend is a counterweight of the arrogance, which is quite annoying too, I think best would be to display none of them. In fact it means displaying less of the self, and more of interesting content. I think Peter Norvig's articles are good examples of writings letting the self in the back shade, which by ricochet raises curiosity and interest in the author's self. I think many other authors are also good examples.
So, Ian Bicking aside, I think it is an interesting topic. Some notes:
- Like real generosity do not display itself, real humility hides itself. Or should.
- Humility (or some expressions of it) can be seen as a Middle-age Christian value. Jesus-Christ himself was all but humble, but in European Middle-Ages and after, there was a few movements trying to show unlimited submission to God's will, and humility was proposed as a core value.
- While I understand the pro-humility trend is a counterweight of the arrogance, which is quite annoying too, I think best would be to display none of them. In fact it means displaying less of the self, and more of interesting content. I think Peter Norvig's articles are good examples of writings letting the self in the back shade, which by ricochet raises curiosity and interest in the author's self. I think many other authors are also good examples.
I agree with you. However, in my personal experience, pride seems to be shot down somewhat in our wider programming community--if you're outwardly seen as "boasting", that's considered bad form, so I understand why others would default to "humility".
Python's scientific ecosystem is really exciting, that's where I want to spend more time. Pandas,numpy,scikit-learn...
Just anecdotal/personal opinion on JS and Python communities. I went to Python and JS meetups. Python meetups are usually people talking about different real-life projects they are building with Python with maybe 10% of talks about new frameworks/language. the one JS meetup I went was people comparing and arguing which frameworks/library is better and should we stop using this one or that one, which one is messy .. etc, talking about things that were solved long time ago in AS/Flash/Flex
With JS I'm afraid to spend on a hyped framework that will be obsolete in 6 months.
Just anecdotal/personal opinion on JS and Python communities. I went to Python and JS meetups. Python meetups are usually people talking about different real-life projects they are building with Python with maybe 10% of talks about new frameworks/language. the one JS meetup I went was people comparing and arguing which frameworks/library is better and should we stop using this one or that one, which one is messy .. etc, talking about things that were solved long time ago in AS/Flash/Flex
With JS I'm afraid to spend on a hyped framework that will be obsolete in 6 months.
That's because much of JS is new. Server side is new. Even client side MVC is relatively new. Python has a long, long history that means its frameworks are much more stable. In time I expect JS to be the same.
The sad bit is that a lot of JS frameworks are trying to patch the many language design and implementation flaws (see wtfjs.com) and limitations. Python can evolve at faster speed and change more drastically, while the next version of JS has been promised since forever due to inefficiency of committee and backwards-compatibility worries.
No it isn't. Off the top of my head, 1996? I remember it as LiveScript. JS has been "mainstream" longer than Python has. This was written in '04 http://www.paulgraham.com/pypar.html
That's why I said "much of JS" and called out server side JS specifically.
JS and Python are almost the same age.
JS is designed by a committee where the participants are pushing their own corporate agenda, similar to three horses pulling the carriage in different directions. It's unfortunate but that's reality of Web browsers domain. No amount of frameworks going to fix it.
On the server side you have one designer - Google and its V8 engine which caused an explosion in innovation.
On the server side you have one designer - Google and its V8 engine which caused an explosion in innovation.
> It’s oddly common to see people talk about how a programmer can pick up something new in the matter of a few days or months.
I see this and it bothers me as well. Sure, picking up new language syntax isn't that big of a deal, but to become reasonably proficient at solving problems with a programming language takes a huge investment of time and energy.
I see this and it bothers me as well. Sure, picking up new language syntax isn't that big of a deal, but to become reasonably proficient at solving problems with a programming language takes a huge investment of time and energy.
It's the difference between learning enough to be conversational in a spoken language and learning enough to write a novel in it. Maybe the people who think they can do it in a few months have never written a novel in any language?
The people who think they can learn a new language in a few month, indeed, might never write a novel, but they are out there writing crappy code I'll probably have to maintain on day. They're also getting paid well I might add.
Most developers don't need to ever write novels, and most development tasks do not involve writing novels, for what that's worth.
I would say learning the syntax and features of languages like Scala and Haskell is quite hard (at least perhaps for people of C++/Java/C#/Python backgrounds).
Languages like Go and Python take very little time to learn the language features even though mastering any language is quite an undertaking.
Languages like Go and Python take very little time to learn the language features even though mastering any language is quite an undertaking.
Python and Go languages are super easy to learn. It might take you years to learn the standard library of either in-depth however.
C# is quite a functional language now (monads, lambdas, anonymous types etc.). C# is probably the next closest thing to Scala.
What's really hard is not mastering the language, but software development. That's the reason top, super-productive coders can jump between langs.
I would consider Ian Bicking to be a "top, super-productive coder" and he is saying exactly the opposite. In fact not to put words in his mouth, but I think he would agree with my opinion that you can not master something as broad and unqualified as "software development". You can only achieve the level of mastery he is talking about within a domain your are focused on for many years. Software in the gestalt is just too broad, it is arbitrary, any logical construct you can imagine can be built, but without an application deeply considered your efforts and crafting the perfect architecture with just the right tradeoffs will flounder. It's one thing to be a learned hacker who understands many paradigms, patterns and language features and can whip up a solution to anything in short order; it's a completely different thing to build an architecture that people consider brilliant and becomes a pillar of open-source.
I may be putting words in the grandparent poster's mouth, but I didn't read his post as saying you can be an expert at all "software development", but rather that there are certain skills that cut across languages, and then what you see in a specific language is one specific manifestation of that pattern. Learning those skills is both harder and more generally useful than learning any one specific language.
Or to put it succinctly, focus on problems, the constraints and forces shaping those problems, and not solutions. Different technologies will come up with different solutions depending on the specifics of their culture and where they're being used, but the underlying problems come up a lot, and understanding where you've seen it before can make reaching for the correct solution a breeze.
For example, I was just talking with some Polymer folks last week about how to manage global data that needs to be passed between components. They're largely from a client-side, web, JS-heavy background, but after listening to them sketch out this approach that they'd found very useful, I was like "Oh, it's like a Monostate pattern for HTML." That's made it dramatically easier for them to explain their solution to other people, because C++/Java/C# devs know what Monostates are, and now they can just plug in the syntax of HTML and semantics of Polymer elements into everything they know about why the pattern might be useful, what its drawbacks are, how it fits in with other patterns, etc.
One of the sibling comments here mentions how you really ought to know things like testing frameworks, in-code documentation practices, logging, etc. before you can be considered to "know" a language. I'd agree, but I'd argue that knowing that these things exist and why they're important is about 80% of the battle to using them effectively. I can pick up a new language in a few weeks and while I won't be an expert on it, I'll at least know to check out the preferred unit testing framework, read up on the logging APIs, see what the language's philosophy on error handling is, etc. I don't have to start from scratch, because I've worked on projects where these things were important and used a variety of frameworks that all solve these problems in subtly different ways. No, I'm not going to be as quick or elegant as someone who's been working with the language for 10 years - but I'll also be miles ahead of a fresh grad out of college who is just encountering the concepts for the first time and needs to learn the language mechanisms and why they're important. And when technology changes so fast, that knowledge is a lot less likely to go stale than whatever framework is flavor of the month.
Or to put it succinctly, focus on problems, the constraints and forces shaping those problems, and not solutions. Different technologies will come up with different solutions depending on the specifics of their culture and where they're being used, but the underlying problems come up a lot, and understanding where you've seen it before can make reaching for the correct solution a breeze.
For example, I was just talking with some Polymer folks last week about how to manage global data that needs to be passed between components. They're largely from a client-side, web, JS-heavy background, but after listening to them sketch out this approach that they'd found very useful, I was like "Oh, it's like a Monostate pattern for HTML." That's made it dramatically easier for them to explain their solution to other people, because C++/Java/C# devs know what Monostates are, and now they can just plug in the syntax of HTML and semantics of Polymer elements into everything they know about why the pattern might be useful, what its drawbacks are, how it fits in with other patterns, etc.
One of the sibling comments here mentions how you really ought to know things like testing frameworks, in-code documentation practices, logging, etc. before you can be considered to "know" a language. I'd agree, but I'd argue that knowing that these things exist and why they're important is about 80% of the battle to using them effectively. I can pick up a new language in a few weeks and while I won't be an expert on it, I'll at least know to check out the preferred unit testing framework, read up on the logging APIs, see what the language's philosophy on error handling is, etc. I don't have to start from scratch, because I've worked on projects where these things were important and used a variety of frameworks that all solve these problems in subtly different ways. No, I'm not going to be as quick or elegant as someone who's been working with the language for 10 years - but I'll also be miles ahead of a fresh grad out of college who is just encountering the concepts for the first time and needs to learn the language mechanisms and why they're important. And when technology changes so fast, that knowledge is a lot less likely to go stale than whatever framework is flavor of the month.
Super productive coders can't master languages within a few weeks.
They probably learn some of the syntaxes but they don't learn the idioms and proper ways of using the languages.
I've never met a developer who can pick up a book and be a master in relatively quick. They can hack something up but by no means the code is acceptable.
The only reason we believe someone can jump between languages quickly is because we _NEVER_ see their work and we _NEVER_ put them under microscope. We just believe the hype.
By acceptable I refer to the following criteria:
- Proper test automation
- Proper documentation (in-language doc)
- Proper idiom (that means logging properly, proper design pattern suitable for that language, using proper libraries/standard-lib correctly)
- Proper SCM (that means build, dependency management, folder structure, code style, code analysis tool in-place, etc)
Anything less than that is a sign of either the language ecosystem is not mature enough or the developer has yet reached the mastery level (or simply not enough data to measure the level accurately).
They probably learn some of the syntaxes but they don't learn the idioms and proper ways of using the languages.
I've never met a developer who can pick up a book and be a master in relatively quick. They can hack something up but by no means the code is acceptable.
The only reason we believe someone can jump between languages quickly is because we _NEVER_ see their work and we _NEVER_ put them under microscope. We just believe the hype.
By acceptable I refer to the following criteria:
- Proper test automation
- Proper documentation (in-language doc)
- Proper idiom (that means logging properly, proper design pattern suitable for that language, using proper libraries/standard-lib correctly)
- Proper SCM (that means build, dependency management, folder structure, code style, code analysis tool in-place, etc)
Anything less than that is a sign of either the language ecosystem is not mature enough or the developer has yet reached the mastery level (or simply not enough data to measure the level accurately).
And also most people write the new language in their old language.
Like the old adage. Good programmers can write FORTRAN in any language.
Like the old adage. Good programmers can write FORTRAN in any language.
It happened to me once. My QBasic instructor guessed that I probably have taken a FORTRAN class (and I did...).
I would agree.
One can read Perl code and say "this was written by a C programmer" for example, or "this was written by someone who knew Python better than Perl."
Switching between languages for me usually means at least one failed project which nobody ever sees.
Also I would not call myself superproductive, though I have been called that by others. A big reason some people think I am superproductive is they don't see where I spend most of my time.
One can read Perl code and say "this was written by a C programmer" for example, or "this was written by someone who knew Python better than Perl."
Switching between languages for me usually means at least one failed project which nobody ever sees.
Also I would not call myself superproductive, though I have been called that by others. A big reason some people think I am superproductive is they don't see where I spend most of my time.
Of your four points, the first two strike me as generic development skills (knowing what and when to test, knowing what and when to document), and the forth is just reading the docs and following their instructions once. Proper idiomatic language use is probably the only thing you mentioned that is language specific.
Writing "proper" javadoc takes time. It has tons of keywords and annotation to make it look consistent like any other "professional and good looking" javadoc out there.
For example: if one is deprecating a method, there are a bunch of proper JavaDoc ways to do this (starting with the @deprecated annotation, not to be confused with another @Deprecated annotation, don't forget to state since which version this method is deprecated, etc etc).
It requires a high level of discipline and knowledge of the javadoc idioms.
http://www.oracle.com/technetwork/java/javase/documentation/...
Occasionally, one have to insert HTML too...
I know C# support similar thing.
For example: if one is deprecating a method, there are a bunch of proper JavaDoc ways to do this (starting with the @deprecated annotation, not to be confused with another @Deprecated annotation, don't forget to state since which version this method is deprecated, etc etc).
It requires a high level of discipline and knowledge of the javadoc idioms.
http://www.oracle.com/technetwork/java/javase/documentation/...
Occasionally, one have to insert HTML too...
I know C# support similar thing.
Yes and no. Writing test cases can be rather different by language.
Also documentation frameworks may seem identical if you only program in C, C++, and Java. However when you start doing a lot in SQL, Perl, or Python, they start looking very different (and in fact these languages, assuming an SQL that supports COMMENT ON syntax) are more similar than any of them are to C or Java in this regard).
Move from there to TeX or LaTeX and you are in for another big shock.
In short, there are idioms for both test cases and documentation and those are remarkably language-specific.
Also documentation frameworks may seem identical if you only program in C, C++, and Java. However when you start doing a lot in SQL, Perl, or Python, they start looking very different (and in fact these languages, assuming an SQL that supports COMMENT ON syntax) are more similar than any of them are to C or Java in this regard).
Move from there to TeX or LaTeX and you are in for another big shock.
In short, there are idioms for both test cases and documentation and those are remarkably language-specific.
I would generaly agree on that, but considering the fact that the OP has actualky created pip and virtualenv, i would say that for going that deep in a language and its ecosystem one really need some time.
I have never bought the party line that learning languages for a new job is difficult, particularly from hiring managers. Multiple times in my career I've taken a job which required a new language, scala most recently. These all involved new frameworks, library stacks, etc. In each of those cases I was reasonably productive after a couple of weeks and productive enough after a month or two.
It's not like I was the world's expert in those languages and at that point and I'd probably flub the sort of interview questions focused on the nitty gritty (heck, I've never been good at those regardless) but I knew what I wanted to do, had a good idea of how to do it and a minute or so with google would fill in the rest.
It's not like I was the world's expert in those languages and at that point and I'd probably flub the sort of interview questions focused on the nitty gritty (heck, I've never been good at those regardless) but I knew what I wanted to do, had a good idea of how to do it and a minute or so with google would fill in the rest.
Let's face it, if you practice TDD (i.e. write tests first) and you have access to a browser and Internet connection, why would you need to memorize libraries? Sure you might make a few more mistakes than someone steeped in the platform, but I just don't see it making a difference when you consider the amount of time you need to get up to speed on a new company's quirks and needs.
It is interesting, I experienced a similar feeling to:
However, I ended up moving to other languages for what I was "making". First using Python, but now also venturing into native development using C. I guess part of it was wanting to not have limitations on what I could build. PHP was limiting in dealing with crappy hosts, Python less so, but the sky is the limit with C.
I don’t want to get caught up in the weeds again, building tools for something I never manage to make.
However, I ended up moving to other languages for what I was "making". First using Python, but now also venturing into native development using C. I guess part of it was wanting to not have limitations on what I could build. PHP was limiting in dealing with crappy hosts, Python less so, but the sky is the limit with C.
What kind of limitations?
Everything you can do in Python, can be done in PHP too. For long running processes you can use libevent, and for threading (web server) you can use libcurl. You can write native C or C++ extensions for both Python and PHP. Facebook's HHVM PHP JIT VM is very scalable and there is PyPy (Python JIT).
Everything you can do in Python, can be done in PHP too. For long running processes you can use libevent, and for threading (web server) you can use libcurl. You can write native C or C++ extensions for both Python and PHP. Facebook's HHVM PHP JIT VM is very scalable and there is PyPy (Python JIT).
I specifically mentioned dealing with crappy hosts. PHP's biggest strength is that it is available to almost everyone for cheap. Unfortunately most of those cheap hosts don't support sane extensions. And you certainly aren't going to get custom ones on there. Or even a recent version of PHP.
Python has some similar issues. Ensuring that an end-user application written in Python is going to have access the the appropriate version of Python with the packages you need is still a challenge. Asking Joe user to install virtualenv and Python 3.3 is not viable.
Currently I'm working on an app that uses Python, but is written in C and embeds Python for some of the cross-platform components.
Python has some similar issues. Ensuring that an end-user application written in Python is going to have access the the appropriate version of Python with the packages you need is still a challenge. Asking Joe user to install virtualenv and Python 3.3 is not viable.
Currently I'm working on an app that uses Python, but is written in C and embeds Python for some of the cross-platform components.
This is exactly where I'm at. If I had to characterize Python with one phrase, it's "blandly practical". Sure, Python gets the job done, and it's not a horrid mess like some languages. But at the same time, it's just kind of there. There just aren't any projects out there that I want to write (day job-wise or spare-time wise) that scream "I have to use Python for this!". There are no new exciting projects or libraries using Python that I have to check out now.
Javascript has Angular JS that I want to play with. Go is shaping up to be an efficient and easy-to-use server-side language. Rust is C++ that doesn't want to make me gouge my eyese out. But what about Python? Apart from throwaway command-line tools, I've got nothing.
Javascript has Angular JS that I want to play with. Go is shaping up to be an efficient and easy-to-use server-side language. Rust is C++ that doesn't want to make me gouge my eyese out. But what about Python? Apart from throwaway command-line tools, I've got nothing.
Someone explained "blandly practical" to me in terms of Python being very Dutch, pragmatic yet conservative.
I am not versed in Dutch culture, but considering Van Rossum's background, I thought it was an interesting statement.
I am not versed in Dutch culture, but considering Van Rossum's background, I thought it was an interesting statement.
This is something about you and what you hear as having buzz, not about Python
I've more or less reached the opposite conclusion for similar reasons. That is, yeah, when I'm programming in Python, I don't really notice the language at all. There's a definite flavor to the experience of programming in C++ and another to the experience of programming in Java and another to Haskell, the particular kinds of things I have to do in each case to get the language to do my bidding, but when I'm programming in Python, the language is almost transparent; the experience is almost entirely about the program I'm trying to write, the problem I'm trying to solve.
And that's exactly what I want, these days.
And that's exactly what I want, these days.
>>when I'm programming in Python, I don't really notice the language at all.
When you program in any language of your expertise you don't really notice the language at all.
When you program in any language of your expertise you don't really notice the language at all.
I moved from Perl to Python. I noticed Python was harder to do "clever stuff" with - the sort you would see in Perl one liners.
My code is a little more verbose in Python, but I notice I don't shoot myself in the foot by trying to be too clever too early, and ending up with a tangled mess a few days later.
My code is a little more verbose in Python, but I notice I don't shoot myself in the foot by trying to be too clever too early, and ending up with a tangled mess a few days later.
> If I had to characterize Python with one phrase, it's "blandly practical".
Um, exactly? Not a horrid mess is high praise in programming languages.
I can't think of many languages I use that come in for that description. Look at which languages come with a decent language, a decent standard library and a decent community. That's a really small subset.
Um, exactly? Not a horrid mess is high praise in programming languages.
I can't think of many languages I use that come in for that description. Look at which languages come with a decent language, a decent standard library and a decent community. That's a really small subset.
"Blandly practical" is the reason I still use python as my go to language for almost everything I do. The language is nice and stable, support for it is wide spread, there are nice and stable libraries for everything I need and so on. Python is the only language where I feel comfortable that can sit down and know I'll only have to think about my problem. I like that.
I'm currently keeping my eyes on both Julia and Rust and regularly try to do things in Haskell and Clojure, but basically every time I start a new non-trivial project in a new language I often end up at a point where I'm facing a language problem not a problem domain problem. How do I deploy language X on platform Y and make it talk to application Z, why is there no library to read/write .foo files, how to I make these two incomplete, buggy, almost-but-not-quite-overlapping libraries I found on github play together.
And don't get me wrong, that can be a fun challenge in its own way, but I don't always have time or desire to take 2 weeks out of what was really supposed to be a 2 week project to write a library to do something that would take me 2 minutes using a stable well tested python library.
I don't know, maybe it's just me getting old, but these days I'd much rather spend my time solving problems using programming than solve programming problems, doubly so when people are paying me to solve problems.
I'm currently keeping my eyes on both Julia and Rust and regularly try to do things in Haskell and Clojure, but basically every time I start a new non-trivial project in a new language I often end up at a point where I'm facing a language problem not a problem domain problem. How do I deploy language X on platform Y and make it talk to application Z, why is there no library to read/write .foo files, how to I make these two incomplete, buggy, almost-but-not-quite-overlapping libraries I found on github play together.
And don't get me wrong, that can be a fun challenge in its own way, but I don't always have time or desire to take 2 weeks out of what was really supposed to be a 2 week project to write a library to do something that would take me 2 minutes using a stable well tested python library.
I don't know, maybe it's just me getting old, but these days I'd much rather spend my time solving problems using programming than solve programming problems, doubly so when people are paying me to solve problems.
Unless you are a scientist. Then Python is the way to go. Julia may shape up to become a successor, Matlab and R are more specialized but generally worse languages.
The reason I force myself to learn Python is because it is everywhere. My stepson is learning it at school. A lot of machine learning is done in python. If I want to learn machine learning it makes sense to know python so I can follow along. Python is just everywhere..
I do struggle with it though, because it is so bland.
I do struggle with it though, because it is so bland.
Python has the libraries.
First, let me preface by saying that I use Python and JavaScript in my day to day work. There is a personal side to this issue, that is, his mastery of Python, but I believe the issue is more related to Python.
Python as a language is uninteresting. It has no novel or exciting ideas other than its readability. Python 3 has shown nothing of importance to upgrade as the rate of adoption shows.
It lacks the flexibility of Ruby, general appeal of JS, philosophy of Clojure.
Maybe its boringness might be of value to some, as it has reached steady state, but I believe that if you are going to be where the puck is going to be, you need to consider languages other than Python. I am betting on JS and Clojure.
Python as a language is uninteresting. It has no novel or exciting ideas other than its readability. Python 3 has shown nothing of importance to upgrade as the rate of adoption shows.
It lacks the flexibility of Ruby, general appeal of JS, philosophy of Clojure.
Maybe its boringness might be of value to some, as it has reached steady state, but I believe that if you are going to be where the puck is going to be, you need to consider languages other than Python. I am betting on JS and Clojure.
> It lacks the flexibility of Ruby, general appeal of JS, philosophy of Clojure.
This feels like a cheap shot. What flexibility, general appeal, or philosophy?
Flexibility: Python is very flexible (I'll say dynamic), but not at the expense of clarity. This is a (IMO, correct) decision made by the Python community.
General appeal: What does this even mean? The only reason JS has a general appeal is that it ships with every modern browser.
Philosophy: What philosophy? Purity? Simplicity? Python is a pragmatic language ("get stuff done") while keeping simplicity in mind (although I definitely wouldn't argue that Python is as "simple" as some languages, it's simple enough)
This feels like a cheap shot. What flexibility, general appeal, or philosophy?
Flexibility: Python is very flexible (I'll say dynamic), but not at the expense of clarity. This is a (IMO, correct) decision made by the Python community.
General appeal: What does this even mean? The only reason JS has a general appeal is that it ships with every modern browser.
Philosophy: What philosophy? Purity? Simplicity? Python is a pragmatic language ("get stuff done") while keeping simplicity in mind (although I definitely wouldn't argue that Python is as "simple" as some languages, it's simple enough)
> This feels like a cheap shot. What flexibility, general appeal, or philosophy?
Right, somewhat a cheap shot, that was partly a rant, as I don't have the motivation to explain it fully in a comment.
> Flexibility: Python is very flexible (I'll say dynamic), but not at the expense of clarity. This is a (IMO, correct) decision made by the Python community.
I would argue that it is not as flexible as Ruby or Clojure for building DSLs. I believe this is not only a decision, but the result of constraints of the language, like significant whitespace or lack of macros.
> General appeal: What does this even mean? The only reason JS has a general appeal is that it ships with every modern browser.
Exactly, but also due to significance of web, it is drawing lots of talent and there is a cambrian explosion in JS. There is so much energy and experimentation going on right now in JS world.
> Philosophy: What philosophy? Purity? Simplicity? Python is a pragmatic language ("get stuff done") while keeping simplicity in mind (although I definitely wouldn't argue that Python is as "simple" as some languages, it's simple enough)
Exactly, purity and simplicity. Lack of functional programming ideas in Python, broken lambdas, mutable state etc. Clojure tackles one of the major source of complexity, state, head on, while maintaining pragmatism.
Python is pragmatic too, I concur, but it is not a language that transforms the way one thinks about programming, it gets the job done, without giving you that much leverage.
Right, somewhat a cheap shot, that was partly a rant, as I don't have the motivation to explain it fully in a comment.
> Flexibility: Python is very flexible (I'll say dynamic), but not at the expense of clarity. This is a (IMO, correct) decision made by the Python community.
I would argue that it is not as flexible as Ruby or Clojure for building DSLs. I believe this is not only a decision, but the result of constraints of the language, like significant whitespace or lack of macros.
> General appeal: What does this even mean? The only reason JS has a general appeal is that it ships with every modern browser.
Exactly, but also due to significance of web, it is drawing lots of talent and there is a cambrian explosion in JS. There is so much energy and experimentation going on right now in JS world.
> Philosophy: What philosophy? Purity? Simplicity? Python is a pragmatic language ("get stuff done") while keeping simplicity in mind (although I definitely wouldn't argue that Python is as "simple" as some languages, it's simple enough)
Exactly, purity and simplicity. Lack of functional programming ideas in Python, broken lambdas, mutable state etc. Clojure tackles one of the major source of complexity, state, head on, while maintaining pragmatism.
Python is pragmatic too, I concur, but it is not a language that transforms the way one thinks about programming, it gets the job done, without giving you that much leverage.
> I would argue that it is not as flexible as Ruby or Clojure for building DSLs.
I've never met a DSL that was better than a well designed API. They all start leaking at some point.
I've never met a DSL that was better than a well designed API. They all start leaking at some point.
What most programmers today call a DSL are in fact just an API anyway!
>>Python is very flexible
As a design goal Python aims to be as little flexible as possible to enforce its design goal of making code readable at any and every cost.
In fact its so brittle merely small time changes to a print statement has caused nearly a 8 year backward incompatible ecosystem which is still catching up.
I can't image what would happen when some new ideas have to bought in the language to keep pace. Keep going through migration cycle every 6-7 years to handle backward incompatible changes.
The story till now was some how okayish. Basically Python was playing a catch up game with Perl to get the popular features Perl has. It still hasn't succeeded completely, and yet has a heavily fragmented ecosystem between 2.x and 3.x dev branches. I don't see anything new going into Python any time sooner.
Python is as little flexible as it gets.
As a design goal Python aims to be as little flexible as possible to enforce its design goal of making code readable at any and every cost.
In fact its so brittle merely small time changes to a print statement has caused nearly a 8 year backward incompatible ecosystem which is still catching up.
I can't image what would happen when some new ideas have to bought in the language to keep pace. Keep going through migration cycle every 6-7 years to handle backward incompatible changes.
The story till now was some how okayish. Basically Python was playing a catch up game with Perl to get the popular features Perl has. It still hasn't succeeded completely, and yet has a heavily fragmented ecosystem between 2.x and 3.x dev branches. I don't see anything new going into Python any time sooner.
Python is as little flexible as it gets.
>> As a design goal Python aims to be as little flexible as possible to enforce its design goal of making code readable at any and every cost.
I think that's a very narrow way of defining flexibility.
By your definition of flexibility, C++ must be really flexible because its template system is Turing Complete and you can do whatever you like!
By the same definition, Scheme must be a pretty inflexible language because its syntax is extremely limited (simple).
Python is flexible in that:
- it can be used in many different fields (because libraries exist for science, web -- you can find a library in Python for pretty much any task you can imagine).
- there a number of different implementations of the language to suit your needs (CPython, Pypy for speed, now Micropython for embedded). It is (somewhat) easily ported to other platforms (e.g. ARM, JVM, .NET).
- the language still allows you to do imperative, OO and to some degree functional programming. I don't think allowing Python to do everything under the Sun makes it "flexible".
- Python's dynamism (look at something like the library "sh"), ducktyping, keyword arguments make it flexible.
--
Final point: I think using Python 3's print statement as an example of Python being inflexible is dishonest. Python 3 had major internal changes made to it. The backward incompatible jump between 2 and 3 (AFAIK) was more a choice and a requirement. Guido has recently (just last year) said that he will never do anything like Python 2 -> Python 3 transition again.
I think that's a very narrow way of defining flexibility.
By your definition of flexibility, C++ must be really flexible because its template system is Turing Complete and you can do whatever you like!
By the same definition, Scheme must be a pretty inflexible language because its syntax is extremely limited (simple).
Python is flexible in that:
- it can be used in many different fields (because libraries exist for science, web -- you can find a library in Python for pretty much any task you can imagine).
- there a number of different implementations of the language to suit your needs (CPython, Pypy for speed, now Micropython for embedded). It is (somewhat) easily ported to other platforms (e.g. ARM, JVM, .NET).
- the language still allows you to do imperative, OO and to some degree functional programming. I don't think allowing Python to do everything under the Sun makes it "flexible".
- Python's dynamism (look at something like the library "sh"), ducktyping, keyword arguments make it flexible.
--
Final point: I think using Python 3's print statement as an example of Python being inflexible is dishonest. Python 3 had major internal changes made to it. The backward incompatible jump between 2 and 3 (AFAIK) was more a choice and a requirement. Guido has recently (just last year) said that he will never do anything like Python 2 -> Python 3 transition again.
> In fact its so brittle merely small time changes to a print statement has caused nearly a 8 year backward incompatible ecosystem which is still catching up.
Something which can be automatically ported with full backwards-compatibility for the last couple releases of the 2.x branch isn't a good example. You'd do better discussing the bytes / unicode growing pains since that may require a human to think about the problem.
Something which can be automatically ported with full backwards-compatibility for the last couple releases of the 2.x branch isn't a good example. You'd do better discussing the bytes / unicode growing pains since that may require a human to think about the problem.
Python 3 migration is a social problem, not a technical one. You can't draw any conclusions about Python itself from the social problems around it
Maybe its boringness might be of value to some, as it has reached steady state, but I believe that if you are going to be where the puck is going to be, you need to consider languages other than Python. I am betting on JS and Clojure.
I remember reading the announcements on Usenet for early versions of Python over two decades ago. I wasn't excited about it then because I was so tied up in learning The Next Big Thing and Python, even when it was brand spanking new, never screamed sexy.
At some point though, I stopped chasing The Next Big Thing because I needed to actually get stuff done in such a way that didn't involve me or another senior engineer maintaining it forever. Nearly 15 years after I read the first announcement of Python, I actually started to use it in earnest and I liked it. At some point in one's programming career, one starts to become practical and Python, if anything, is a practical language.
I sometimes think the reason Python doesn't have the zealotry in its community like other languages is because it attracts such practical people that when faced with a problem that would be easier solved in another language, will simply use the other language.
I remember reading the announcements on Usenet for early versions of Python over two decades ago. I wasn't excited about it then because I was so tied up in learning The Next Big Thing and Python, even when it was brand spanking new, never screamed sexy.
At some point though, I stopped chasing The Next Big Thing because I needed to actually get stuff done in such a way that didn't involve me or another senior engineer maintaining it forever. Nearly 15 years after I read the first announcement of Python, I actually started to use it in earnest and I liked it. At some point in one's programming career, one starts to become practical and Python, if anything, is a practical language.
I sometimes think the reason Python doesn't have the zealotry in its community like other languages is because it attracts such practical people that when faced with a problem that would be easier solved in another language, will simply use the other language.
A vibe I'm getting in this that Python is bland, and that "settling" for whether to use Python is good/bad.
It's existed for so long that it is a hugely high-functional tool, and many/most of it's hard edges have been filed off (either in the stdlib or in user-made packages).
Something I feel in using Python is that it's blandness/utility is itself beautiful, or at the very least, elegant. Like a well made tool, it doesn't get in your way, it works well for what it's designed for, making creation without thought easy.
That is one of the greatest joys of Python for me.
It's existed for so long that it is a hugely high-functional tool, and many/most of it's hard edges have been filed off (either in the stdlib or in user-made packages).
Something I feel in using Python is that it's blandness/utility is itself beautiful, or at the very least, elegant. Like a well made tool, it doesn't get in your way, it works well for what it's designed for, making creation without thought easy.
That is one of the greatest joys of Python for me.
Most of the action around JavaScript isn't particularly innovative. Much of the library development we see is solely due to JavaScript lacking a useful default standard library, for example. Many of the recent and proposed language changes are just fixing basic functionality that was really broken to being with, if not completely missing.
It's very similar for Clojure. It's based on ideas that go back many decades now. Its main selling point is that it's somewhat more practical than previous Lisp or Lisp-like language implementations. Other than that, there's nothing particularly innovative about it.
Python never really suffered from those kinds of problems. It has had a very sensible set of language features since its inception. It has had a very practical standard library since its inception.
Due to a general lack of past mistakes or omissions, there just isn't the need for significant and ongoing repairs that can be misinterpreted as "innovation". This is part of why Python 3's adoption hasn't been that rapid. There really wasn't much to fix, and the problems that did exist were generally quite minor and easy to work around.
It's very similar for Clojure. It's based on ideas that go back many decades now. Its main selling point is that it's somewhat more practical than previous Lisp or Lisp-like language implementations. Other than that, there's nothing particularly innovative about it.
Python never really suffered from those kinds of problems. It has had a very sensible set of language features since its inception. It has had a very practical standard library since its inception.
Due to a general lack of past mistakes or omissions, there just isn't the need for significant and ongoing repairs that can be misinterpreted as "innovation". This is part of why Python 3's adoption hasn't been that rapid. There really wasn't much to fix, and the problems that did exist were generally quite minor and easy to work around.
I think you're selling Clojure short. Its emphasis on purity, STM, and persistent data structures is quite different from most other Lisp-like languages, and indeed most other languages period. Those ideas have certain been tried elsewhere (Haskell, for example) but it's a path which is definitely not as well-trodden as you make it sound.
Maybe its boringness might be of value to some, as it has reached steady state, but I believe that if you are going to be where the puck is going to be, you need to consider languages other than Python.
I have a philosophy:
Innovate in either what you are building OR what you are using to build it, not both at once.
So if I'm working on a CRUD website, I'll happily push the boundaries on what tools I use. I can afford to burn some time because I know what I need to do.
If I'm working on something which no one is quite sure is possible, then I want boring, safe tools wherever possible.
There are exceptions, where you what you are doing is so innovative you need new tools to build it. Exceptions are exceptional (and often interesting...)
Of course, for some personal project I ignore my own advice. But then I know I'll be fighting my tools as well as what I'm trying to do, so that's my choice to be stupid.
I have a philosophy:
Innovate in either what you are building OR what you are using to build it, not both at once.
So if I'm working on a CRUD website, I'll happily push the boundaries on what tools I use. I can afford to burn some time because I know what I need to do.
If I'm working on something which no one is quite sure is possible, then I want boring, safe tools wherever possible.
There are exceptions, where you what you are doing is so innovative you need new tools to build it. Exceptions are exceptional (and often interesting...)
Of course, for some personal project I ignore my own advice. But then I know I'll be fighting my tools as well as what I'm trying to do, so that's my choice to be stupid.
That's a neat aphorism. It's the software equivalent of Intel's tick/tock process.
It also explains why I see far too many shiny web 'frameworks'. People just must attempt doing something "cleverly" especially if the end goal is boring.
I'm in the opposite case right now, I have way too much complexity to want tricky dev or ops tools.
It also explains why I see far too many shiny web 'frameworks'. People just must attempt doing something "cleverly" especially if the end goal is boring.
I'm in the opposite case right now, I have way too much complexity to want tricky dev or ops tools.
> Python as a language is uninteresting. It has no novel or exciting ideas other than its readability.
Python as a language is 23 years old -- older than quite a few people who program it. And while it has changed through the years (adding things like generators, comprehensions, dropping explicit member access control, etc.) it is still mostly the same language.
The fact you find nothing novel in it is mostly a reflection of your history, not Python's history; if I had to sum up Python's history, its novelty lies with distilling concepts into more limited but easily understandable, practical constructs - e.g., list comprehensions, generators, significant whitespace.
Python as a language is 23 years old -- older than quite a few people who program it. And while it has changed through the years (adding things like generators, comprehensions, dropping explicit member access control, etc.) it is still mostly the same language.
The fact you find nothing novel in it is mostly a reflection of your history, not Python's history; if I had to sum up Python's history, its novelty lies with distilling concepts into more limited but easily understandable, practical constructs - e.g., list comprehensions, generators, significant whitespace.
For me thinking about system design and coding is remarkably similar than actually coding it in Python. Language and its ecosystem has no quirks, libraries are stable, there is good documentation everywhere you look. Databases and services tend to have first rate Python bindings. Even web framework wars have quieted down with great winners.
I started with Python in 1998, over 15 years ago. These days practicality and blandness is a virtue to me, not a shortcoming. I wouldn't say Python is not going where other languages are to be heading. It might do so with little fanfare and less heated discussions, but it still gets there. Or perhaps it has arrived "there" already, with a zen like presence.
Only place of pain is the web browser. It is the most interesting platform, but with a language with greatly annoying warts. I'm glad that Ian has chosen to work at Mozilla to help create a better web. Perhaps he can do things for JavaScript ecosystem like he did so well for Python with virtualenv and pip.
I started with Python in 1998, over 15 years ago. These days practicality and blandness is a virtue to me, not a shortcoming. I wouldn't say Python is not going where other languages are to be heading. It might do so with little fanfare and less heated discussions, but it still gets there. Or perhaps it has arrived "there" already, with a zen like presence.
Only place of pain is the web browser. It is the most interesting platform, but with a language with greatly annoying warts. I'm glad that Ian has chosen to work at Mozilla to help create a better web. Perhaps he can do things for JavaScript ecosystem like he did so well for Python with virtualenv and pip.
What I love about python is that technical people use it who don't code and yet they do amazing stuff. Geologists. Astronomers. Mathematicians. Petroleum engineers. It has a wild, wide crazy community that's rare elsewhere.
I have a theory that one reason Python is gaining so much ground lately in scientific computing (over tools such as R) is because
1) it is literally almost impossible to write unreadable code in Python,
2) most scientists are terrible programmers,
and
3) when a project matures, "real" programmers get involved, and the fact that the code is readable (and therefore amenable to maintenance and extension) vastly increases the chances that the project will succeed.
1) it is literally almost impossible to write unreadable code in Python,
2) most scientists are terrible programmers,
and
3) when a project matures, "real" programmers get involved, and the fact that the code is readable (and therefore amenable to maintenance and extension) vastly increases the chances that the project will succeed.
I'm a scientist and also a terrible programmer. What's your hypothesis on why this is the case?
Scientists know how smart they are, and assume that programming is mainly about being smart. But it's not -- it's much more of a learned skill to become a really good programmer. It's something you have to focus on and respect as a goal in and of itself, not just something any smart person can muddle through on logic and intuition.
It's simply because most people are terrible programmers, except for programmers.
or 4 that they can't hack Fortan
"Squeak/Smalltalk was a deep mysterious world, like coming upon the ruins of an ancient and advanced civilization" is really spot on. If you have some spare time and get a hold of a copy of http://en.wikipedia.org/wiki/Croquet_Project it's just amazing what they were doing. Unfortunately it looks like the project site is down for the count.
As for the rest, it seems very confined to the use of Python as a web programming language, if you try to use many web languages in domains outside of the web you will be writing a lot of things from scratch. Python has multiple competitive web offerings but they form part of a huge landscape of offerings in many areas few can match. I'd go so far as to say the top two languages for "is there a B+ or higher viable library for this random task" would be Python and Java. Clojure's promise is to swiftly address the flaw in all other Lisps by incorporating the Java ecosystem.
Programming language research gets an order of magnitude more coverage on HN than it does inside Computer Science as a discipline. It's a simplification, which has nitpicks people can use to derail the argument, but broadly speaking algorithms - in terms of practically being able to import and use them as well as to practically be able to talk and reason about them with other people - are vastly more important than language syntax.
As for the rest, it seems very confined to the use of Python as a web programming language, if you try to use many web languages in domains outside of the web you will be writing a lot of things from scratch. Python has multiple competitive web offerings but they form part of a huge landscape of offerings in many areas few can match. I'd go so far as to say the top two languages for "is there a B+ or higher viable library for this random task" would be Python and Java. Clojure's promise is to swiftly address the flaw in all other Lisps by incorporating the Java ecosystem.
Programming language research gets an order of magnitude more coverage on HN than it does inside Computer Science as a discipline. It's a simplification, which has nitpicks people can use to derail the argument, but broadly speaking algorithms - in terms of practically being able to import and use them as well as to practically be able to talk and reason about them with other people - are vastly more important than language syntax.
> if you try to use many web languages in domains outside of the web you will be writing a lot of things from scratch
Not only that, you'll also realize that you're wasting CPU cycles and RAM.
Not only that, you'll also realize that you're wasting CPU cycles and RAM.
Ian contributed a huge amount to the python world, both in code and in general community presence. But I can easily imagine him contributing just as much, or more, to Javascript. Good luck to him!
Thanks for all the awesome work, Python and the community wouldn't have gotten to where they are without people like Ian.
"There is no community that created Javascript like the Python community created Python. Python comes from the internet in a way Javascript does not; Javascript was built for the internet, but Python was built on the internet."
"There is no community that created Javascript like the Python community created Python. Python comes from the internet in a way Javascript does not; Javascript was built for the internet, but Python was built on the internet."
> Anyway, that’s where I am now. No longer a language partisan, unclear of what community I am even participating in, I am less sure how to identify and self-identify myself. How do I describe myself now?
Actually I'm really glad for this conclusion. I've always thought it kind of counterproductive and useless to label ourselves as "Rubyists" or "Pythonistas" etc. Yes, we may use that language, we may even prefer that language over another, but it's not for the sake of the language itself, but because of what it allows us to do. So when a better replacement comes along, that kind of attachment to a language is only going to delay our adoption of it because of basically nothing but sentimentality. So yes, I prefer Clojure. But I also prefer C# and Objective-C and JavaScript. I'm not in any of these communities, I'm just a problem solver.
Actually I'm really glad for this conclusion. I've always thought it kind of counterproductive and useless to label ourselves as "Rubyists" or "Pythonistas" etc. Yes, we may use that language, we may even prefer that language over another, but it's not for the sake of the language itself, but because of what it allows us to do. So when a better replacement comes along, that kind of attachment to a language is only going to delay our adoption of it because of basically nothing but sentimentality. So yes, I prefer Clojure. But I also prefer C# and Objective-C and JavaScript. I'm not in any of these communities, I'm just a problem solver.
As a student, this is exactly what I think when a potential employer asks, "What language would you like to be interviewed in?" I love the power that each language brings to the table. I'm fluent in the language I'm using to solve a problem, but when I'm done, it goes back on the shelf to collect dust until I need it again. I just wish there was a way to convey that without looking stupid.
PS: I'm looking for an internship! Any suggestions?
PS: I'm looking for an internship! Any suggestions?
My recommendation to people interested in computer science is to not get too obsessed with individual programming languages.
This article/memoir is not about someone interested in computer science (or if they are, it's not about that interest), it's about someone interested in software development and building things.
Ok ... Thanks for that.
My recommendation to people interested in software development and "building things" is to not get too upset and wrapped up in a particular programming language.
Also, my recommendation to people interested in software development is to study computer science, unless you just want to make WordPress templates, I guess.
My recommendation to people interested in software development and "building things" is to not get too upset and wrapped up in a particular programming language.
Also, my recommendation to people interested in software development is to study computer science, unless you just want to make WordPress templates, I guess.
> I suppose it is the platform that I am drawn to now before language
I found this to be true about my experience too. I wanted to write GUI apps for Mac OS X so I embraced Objective-C. Now I want to write GUI apps for Windows, so I'm embracing C#. I guess it's just a really nice bonus that C# is awesome. Same thing when I have to do front-end work, I just use JavaScript (or ClojureScript if it's a big enough project).
I found this to be true about my experience too. I wanted to write GUI apps for Mac OS X so I embraced Objective-C. Now I want to write GUI apps for Windows, so I'm embracing C#. I guess it's just a really nice bonus that C# is awesome. Same thing when I have to do front-end work, I just use JavaScript (or ClojureScript if it's a big enough project).
I skipped the post, mainly because I somehow wanted to know what greener pastures the author had found...
Then he revealed Javascript. Even though I am putting out a ton of javascript and javascript-targeted languages, I found that a little disappointing!
Then he revealed Javascript. Even though I am putting out a ton of javascript and javascript-targeted languages, I found that a little disappointing!
For as interesting and smart as this article is, it was really jarring and annoying to see Malcolm Gladwell's ideas branded upon it everywhere.
It's so frustrating to see "Science-style bullshit" taken as gospel by intelligent, creative, and usually critically thinking people.
It's so frustrating to see "Science-style bullshit" taken as gospel by intelligent, creative, and usually critically thinking people.
I didn't get the sense that he intended "10,000 hours" as a pseudo-scientific assertion of fact.
It's a useful poetic phrase to express the observation that mastery takes time. Sure you could call that a Captain Obvious observation. However he used it in opposition to the idea that great programmers can master a new language in a few weeks. Since that idea is so popular, its opposite apparently is not so obvious.
It's a useful poetic phrase to express the observation that mastery takes time. Sure you could call that a Captain Obvious observation. However he used it in opposition to the idea that great programmers can master a new language in a few weeks. Since that idea is so popular, its opposite apparently is not so obvious.
"mastery takes time"
Also requires talent (or skill, genetic disposition, etc., call it what you will)
Also requires talent (or skill, genetic disposition, etc., call it what you will)
He mentions 10,000 hours once or twice, and uses the word "mastery." If you hadn't ever heard of Gladwell, you wouldn't even know he's making a reference to anything at all.
Hopefully we are approaching the slope of the Python hype:
http://en.wikipedia.org/wiki/Hype_cycle
http://en.wikipedia.org/wiki/Hype_cycle
Python has some problems but I don't think "hype" is one of them. It's almost 25 years old, and it's been in widespread use for at least the last 10. Hell, we've got 100kloc+ python codebase that probably qualifies as legacy already, how hype is that?
Actually I feel especially because of HN that Python got a boost like no other language in the last five years. It even reached our slow Berlin to recognize it as a potential alternative to Java. So I guess the hype in the rest of the world must have been quite huge.
Languages have long cycles. Python (1991), Ruby (1996), and Javascript (1995) inception dates are not that far apart. I also believe Python use has increased tremendously with HN, myself included. Ruby during the same time also fueled that (2005/6 ish), reddit being built on it possibly also sparked that.
A native language takes even longer sometimes, Objective-C just really hit it's stride with Apple/Next integration and the iPhone but it was made in 1983, same year as C++. Both with very different spikes/waves of interest.
From this we can see strict/native type languages in the 80's, more dynamic/scripted languages in the 90's, the ones in the last decade maybe are still in contention. All of them are pretty much products of their hardware environments at the time.
A native language takes even longer sometimes, Objective-C just really hit it's stride with Apple/Next integration and the iPhone but it was made in 1983, same year as C++. Both with very different spikes/waves of interest.
From this we can see strict/native type languages in the 80's, more dynamic/scripted languages in the 90's, the ones in the last decade maybe are still in contention. All of them are pretty much products of their hardware environments at the time.
Reddit was originally built on Lisp, but was later rewritten in Python. It was never built on Ruby.
Which is weird because I regard Python as very mainstream and established, even old, and I certainly live in a place that is slower than Berlin. Guess it depends on your niche.
Why hopefully?
It will take its well-deserved place in the range of many other languages available instead of being offered way too often as the only language worth learning here on HN. I hope the JS-madness will calm down in next few years as well. Would be helpful to get some other languages in browser. Maybe Dart/NaCl will help.
(didn't downvote you)
And the hype of Dart? I think there is always hype. Hype of Go, hype of Rust, hype of Scala.
And the hype of Dart? I think there is always hype. Hype of Go, hype of Rust, hype of Scala.
Who cares? Languages get hyped because people are newly finding them as great solutions to a problem they have.
There's no "perl hype" because (virtually) nobody is just discovering it as something new and useful.
As python came to have a robust web ecosystem, it started to get a lot of hype as it was getting a ton of converts from perl/php/etc.
Now as web tasks are changing, Go's niche is becoming larger, and people are excited to use it where Python was failing them.
This will continue forever, most likely.
There's no "perl hype" because (virtually) nobody is just discovering it as something new and useful.
As python came to have a robust web ecosystem, it started to get a lot of hype as it was getting a ton of converts from perl/php/etc.
Now as web tasks are changing, Go's niche is becoming larger, and people are excited to use it where Python was failing them.
This will continue forever, most likely.
I am not the one judging the hype, FYI.
There is always hype; the reason the "hype cycle" is an identifiable thing is that it repeats over and over again. And once the hype and the disillusionment die down, that's when you end up with a useful language.
(I say, as I work in Scala. But I think it's slightly different from your other examples; it's been around much longer than the other three languages you mention.)
(I say, as I work in Scala. But I think it's slightly different from your other examples; it's been around much longer than the other three languages you mention.)
[deleted]
How can one add "Python" to Google Trends?
http://www.google.com/trends/explore#q=%2Fm%2F060kv%2C%20%2F...
If I input e.g. "PHP" I can select "PHP (programming language)", but the search suggestions for "Python" make it impossible to add "Python" (the programming language) :(
Search suggestions are for me: Python molurus, Monty Python, Python reticulatus, Burmese python
http://www.google.com/trends/explore#q=%2Fm%2F060kv%2C%20%2F...
If I input e.g. "PHP" I can select "PHP (programming language)", but the search suggestions for "Python" make it impossible to add "Python" (the programming language) :(
Search suggestions are for me: Python molurus, Monty Python, Python reticulatus, Burmese python
[deleted]
I have to say this rings true for me. Long term involved in one language and feeling that the world is moving on. JavaScript feels exciting.
There is a lot of innovation in Javascript, especially since the advent of NodeJS. But compared to Python itself, the language has little to be excited about.
What you describe is "innovation" only in a very restricted, local sense. The developments we see within the JavaScript community today are just them catching up with where Python, Perl, C, C++, Java and other languages were years or decades ago.
Non-blocking IO is nothing new. Event-driven network app development frameworks are nothing new. Even using the same language server-side and client-side is nothing new. We were doing that in the 1980s when we wrote our clients and servers in C, and in the 1990s when we used C++, and in the 2000s when we used Java.
When it comes to JavaScript, what's seen as "innovation" is usually just the language and ecosystem desperately trying to catch up with where everybody else was many years in the past.
Non-blocking IO is nothing new. Event-driven network app development frameworks are nothing new. Even using the same language server-side and client-side is nothing new. We were doing that in the 1980s when we wrote our clients and servers in C, and in the 1990s when we used C++, and in the 2000s when we used Java.
When it comes to JavaScript, what's seen as "innovation" is usually just the language and ecosystem desperately trying to catch up with where everybody else was many years in the past.
> When it comes to JavaScript, what's seen as "innovation" is usually just the language and ecosystem desperately trying to catch up with where everybody else was many years in the past.
That's true up to a point, but you're being a bit uncharitable. I'm thinking of a couple of solutions specifically:
- npm [1], which I hear a lot of good things about, while this is definitely not the case about many languages-specific build systems/package managers
- react [2], which is a nice approach to DOM manipulation (if not, maybe, the first of its kind)
And obviously, more and more languages compile to JS nowadays, or are on their way there.
1: https://www.npmjs.org/doc/cli/npm.html 2: http://facebook.github.io/react/
That's true up to a point, but you're being a bit uncharitable. I'm thinking of a couple of solutions specifically:
- npm [1], which I hear a lot of good things about, while this is definitely not the case about many languages-specific build systems/package managers
- react [2], which is a nice approach to DOM manipulation (if not, maybe, the first of its kind)
And obviously, more and more languages compile to JS nowadays, or are on their way there.
1: https://www.npmjs.org/doc/cli/npm.html 2: http://facebook.github.io/react/
You are making a connection between the advent of NodeJS and the Javascript language. The correct version the way I see it is that the popularity of V8 and NodeJS makes Javascript more than a in-browser scripting language; now people can write both client and server side applications in JS. The latter doesn't require the language to change; the language implementation has been around for years and now people started to do things outside the original norm.
> The latter doesn't require the language to change; the language implementation has been around for years and now people started to do things outside the original norm.
No, but it certainly has pushed for decent dependency management systems, and has led to more complex libraries.
No, but it certainly has pushed for decent dependency management systems, and has led to more complex libraries.
"On December 3, 2009, ECMA-262 5th edition was published."
"ECMAScript Harmony ... with a target release date of December 2014"
Yeah, the world is moving... So damn fast! Only takes 6+ years to release a new version of language.
"ECMAScript Harmony ... with a target release date of December 2014"
Yeah, the world is moving... So damn fast! Only takes 6+ years to release a new version of language.
Is someone saying goodbye to Ruby? (in favor of Go, Rust, Node.js, etc.)
I would appreciate such blog posts/comments too.
I would appreciate such blog posts/comments too.
I never thought I would see the day. Best wishes Ian, no matter what path you take.
there's a bunch of smart under-appreciated observations in there.
tl;dr version:
> And when I did step back there wasn’t anything in Python that excited me.
> And when I did step back there wasn’t anything in Python that excited me.
I'm learning Python more deeply because I think it's a good "Learn X" language for the various X's I want to pick up over the next 5 years. If you learn, say, web programming in Clojure, you're going to be encountering a lot of non-mainstream concepts (see: Pedestal, which is cool as fuck but different from how most people program on the web). That's great, but it's sometimes easier, first, to learn the basics in an "uncomplicated" language. Python's an all-around B+ language in which one can pretty easily learn the basics (except in the browser, where JS is dominant).
That said, for a production system I'd prefer Clojure (or possibly Haskell). It can be almost as fast as Java, has proper lambdas, and doesn't have mutable state in unexpected places.
That said, for a production system I'd prefer Clojure (or possibly Haskell). It can be almost as fast as Java, has proper lambdas, and doesn't have mutable state in unexpected places.
you gonna pass that thing around, or are you gonna bogart it all night?
This sentence is worth pointing out as a good attitude. I think the healthiest place to be is using tools you like, but able to appreciate the good bits of other systems.
For instance, as long as I'm not actually working with it, I can appreciate the idea that PHP made it very easy for a lot of people to do something with the web, something that otherwise they might not have been able to do, because it is very easy to get started with. That is worth something, and worth thinking about for those who are building tomorrow's languages.