Abandoning PHP for Python
techblog.stickyworld.com
techblog.stickyworld.com
Bigger takeaways - working in a situation where you get to choose your own tools and be self-directed is probably a better fit for this person. When he works on a team of 3-5 other people who want to do different things in his Django code, there will be tension. Probably not as much as his PHP monstrosity, but there will be some.
Working with large established frameworks, it's hard to see one file have JS, HTML, raw SQL, ORM code and core PHP app logic all in the same file. The conventions dictate where/how to separate.
The OP likes that separation, likes conventions, and wants to move to Python. Great. However, I feel the benefits he's going to get are coming more from a greenfield setup and working alone vs the language or framework itself.
Also, typo alert: the word is 'resonate', not 'resinate'. ;)
I just refactored an old class hierarchical system where each class extended a random other one and all functions were called from a global parameter or $this-> so if I can do that, anyone can!
In other words, in the Python world, personal standards are discouraged, and there is a remarkable amount of voluntary compliance with the community standards. I work in a number of other languages on a regular basis, and while there are certainly a set of best-practices out there for most languages (often 2 or 3 of them, in fact), I don't see anything nearly so much uniform compliance as in the Python world. I don't really know why.
I feel Python has played a part too though. Python has an official style guide (PEP 8), so code is more homogenous across developers. Python also has a set of core principles (the Zen of Python) which put a focus on readable code.
As to this (my) response, I was pushing a bit more towards "greenfield projects always tend to feel better", but I'm not sure they'll be much better over the long haul if the same person with the same skill level has the same constraints (time, features, etc).
Now that he's classifying himself as a Python programmer, he will run into the same problems as a when he was just a PHP programmer.
Language Programmers suffer.
In Python, it almost feels like that is akin to changing gears without a clutch... and I've only theories as to why that is.
Python has PEP-8. PHP has FIG. Not as ubiquitous, but its getting there.
"There is package management in PHP but I never found any code bases in the wild using it to the same extent as PIP". Wait, what? Just about everyone uses Packagist and Composer these days.
Also, isn't is pythonista, not pythonist?
By the way, no disrespect to Python, which I use as well. There are arguments for preferring python over php in some circumstances, but most of the reasons given in this article lack validity.
edit: Looking at the guidelines on FIG, they really should take some cues from PEP 8 and make the writing style look less hostile and less RFCish², if they want a majority of the community to willingly read it.
Discussing it with a fellow PHP developer looking over the FIG guides, he said it best (by quoting PEP 8):
"A Foolish Consistency is the Hobgoblin of Little Minds"
[1] http://framework.zend.com/manual/1.12/en/coding-standard.htm...
²Nothing against RFC and the format works for what they are trying to accomplish. It doesn't work so well for coding guidelines though.
No one cares about Zend coding standards anymore.
They have branched out and there are efforts towards establishing common interfaces too (logger, http client, and so forth).
PSR-1 and PSR-2 are generally accepted as being authoritative on how to write "Good PHP".
3rd party PHP libraries have become so much easier to read in recent years thanks in large part to the work of the FIG.
[0] - Majority of community being major players like most frameworks and almost all of the most popular libraries.
Major frameworks and libraries going in that directly though is still a very good thing.
Also, while Rails is in the same league as Django as far as tools and expressiveness go(expressiveness perhaps more so), Django goes to considerable lengths to enforce style and consistency; it is not taboo to politely tell people that their code is not PEP8 compliant.
>> Quoted from article: "It was around this point that I decided I'd rather be an unemployed Pythonist than an employed LAMP developer."
Sorry man, I'd rather be an employed LAMP developer, but with a few side projects in Python. It's just a programming language, not a religion. :D
There were so many clients in need of Pythonists in London in 2011-2013 when I was working there that I didn't have the time of day to take care of PHP ones. Also, PHP rates were dying and there weren't a lot of people competing for the Python work so I could keep my day rates nice and juicy.
I can think of a lot of things that beat Zend, Yii and Drupal in terms of code management, security, DRYness of code that's implemented, flexibility, the list goes on.
I can play a little piano, but I'm way better at the bass because it's more fun. I can get work done on a PC, but I get way more done on a Mac because it's easier for me to work with. I can cook with a dull knife, but it's never as much fun as using a good one.
I think it's okay for people who don't really like PHP to publicly admit that, but it often seems to be taken as a religious attack by those on the other end of the spectrum.
I agree that there is a large number of bad php code/coders out there, but you can write and build beautiful, fast and well designed codebases with PHP just as well.
Like the martial arts, the barrier of entry is very low. The black belt, however, takes perseverance and years to earn.
I deploy within virtualenv mainly because I use the same machine to host multiple services. I sometimes use requirements.txt.freeze(pip freeze -l requirements.txt > requirements.txt.freeze) for production deployments, but in the end, I find specifying versions in requirements.txt itself more convenient.
If you are building async services in python, have a look at gevent and learn the basics of event loops. gevent abstracts the event loops(there isn't an explicit loop) but there are cases where you are better off rolling your own select/epoll loop. Also, the article paints too rosy a picture - "I've built backends that do authentication, query a few million rows in Solr and return JSON in a couple of milliseconds thanks to Python" If you structure your applications properly, and your application is IO bound, you can get good performance out of Python. But it goes without saying that Python isn't a performance powerhorse. You might need to replace CPU intensive services with some other language or write a c extension or write cython ...
There is no analogue to virtualenv, and dependencies are loaded into a directory rather than somewhere in the operating system.
Huh? Any serious, modern PHP project uses Composer (http://getcomposer.org/).
Have a look at http://packagist.org
That it's labelled alpha by the developers?
https://github.com/composer/composer/releases
That it's barely 2 years old?
I'm not sure what pointing at packagist proves. There's a lot of packages published for it. Great. THE most popular package installed via packagist's counters is Doctrine, at 1.4 million installs. It's a lot, but compared to all the PHP installs out there, and all the PHP apps out there that aren't using composer (because it's alpha and not very old yet, my conjecture) dwarf the 1.4 million installs of a program via packagist. I'm probably 20 of those Doctrine installs myself.
I was referring to the statement "Any serious, modern PHP project uses Composer". There are loads of 'serious' PHP apps that don't use it, or may only be adopting it now. If the definition of 'modern' means "has to use composer", then, of course, "serious modern PHP projects" use composer.
I personally know people who aren't allowed to rely on it yet in their companies because it's still labelled 'alpha'.
See also: http://www.paulgraham.com/avg.html
The PHP ecosystem is just vastly larger.
A lot of good ideas were either implemented into the language or ported over from other languages/frameworks. There are tools/frameworks that rival those in Python/Ruby land.
Every PHP dev after working on it for few years will know that its not the best language out there, but they will also realize that using it they can get stuff done.
Regarding books : I have to agree on the fact that there are many crappy books out there related to PHP, and I have still not found the ideal reference book for my needs .
Package Management : while its true that there was no standard package management tool for php few years ago ( except PECL ), the situation is different now, composer has evolved now and has become very common these days. composer does have the system where one can put all the dependencies in a single json file to manage all the dependencies .
Django's first tutorial : just go through Symfon2's first tutorial and in my honest opinion it can give serious competition to that of Django's http://symfony.com/doc/current/book/http_fundamentals.html
RESTful and DRY : OP mentiones some libraries which are good for creating RESTful API's in Python, and Of course PHP has some high quality libraries to create RESTful API's.
https://packagist.org/search/?q=REST
Evented Codebases : PHP does have some tools to do the achieve the same result http://reactphp.org/
Deployments : no one can deny the fact that PHP is knows for its ease of deployment ( shared hosting ) , but any ony one serious about their app cannot go with shared hosting , but deploying PHP on a VPS/dedi is actually easier then deploying a Django App . and even modern deployment tools can Chef, Puppet, Ansible have wide support for PHP and its frameworks.
I am wondering that how just by switching to a language will make my code RESTful, DRY and more maintainable. In the end even Python/Django can be used to write crappy code.
Actually I was expecting more solid reasons to switch from PHP to Python ( There might be some too ) .
Are you serious? This is what your hate boils down to: you don't know the PHP ecosystem well, at all. It seems like you've been living under a rock.
Going to your 8-4 every day and hacking away at your company's codebase and not bothering to read up on the goings-on about your language will result in bad times.
The same for sh/bash. It's great for very simple automation/scripts, but after certain level, it's much much easier to use a language which helps you write maintainable code and doesn't actively try to stop you.
that's when I decided I needed to find a globally method to deploy which brought me back to php. Which initially pissed me off cause I was Loving Ruby's syntax.
then I discovered laravel..and holy shit I finally learned how to be a good php developer and use namespaces and really build some awesome stuff. It is rails on php and a hundred times easier to deploy on just about any lamp stack.
This is a typical quote:
"I'm still a little bummed that python doesn't have the for(;;) C syntax"
I'm pleased to report that quite a few people have been impressed with how clean and simple the code is once they see the Python way.
She and another friend of hers was having some troubles understanding when and when not to use parentheses and I did a quick clinic with them to walk through it.
It might be a good idea if volunteers from the Python community could be found to offer extra lessons, perhaps some sort of live video cast mixed with a live chat. It could help out a lot of people who otherwise don't have many people to call on around them.
The main struggle has actually been with people on OSX Lion getting the libraries installed.
Hardly well-hidden.
I was referring to this little quiz [1] which I thought should be posted directly in the description to scare people off.
[1] http://wiki.quantsoftware.org/index.php?title=Compinvesti-pr...
Cheers for pointing this course out, though. It's right up my street.
"technical architecture of the code could change with a developer simply deciding to do things in a different way from the rest of the team" tells me there's no strong code review culture, or code discoverability, and you've simply moved the problem from a lower level to a higher one. While people might be adhering to Python idioms, they're probably not going to write the code that's idiomatic to the organization or make the best use of internal libraries.
* not totally true, 6 months on Groovy, followed by 6 months of hell (AKA pre-2.0 Grails)
Can't speak for Python other than a couple of months of Django (out of the box CRUD functionality is indeed nice).
After a couple of years of Scala can't imagine going back to a runtime only language (other than Coffeescript/LESS via GruntJS for the front end)
On the other side Python feels like one mind's labour, it just fits togheter.