Skip to main content

Bandwagon Hatred for PHP

I tweeted the title of this blog post tonight and it got me to thinking about some of the encounters I have as a more or less polyglot developer who finds good and rewarding employment in PHP.

I just finished attending the excellent and stimulating Praire Dev Con 2015 this week.  I'll let the web site speak for itself, but in summary it's a regional conference that attracts speakers from far and wide.  For two days, men and women enjoy a brief glimpse of professional-speaking disneyland, returning home late in the evening and passing out from social and intellectual exhaustion.

One thing that many of my coworkers past and present have noted about this conference though is that it is very .NET centric.  Now to me this is of course no discouragement at all.  These are exciting (or possibly intimidating) times for many a Microsoft dev.  I've discovered over the past few years that you can learn a lot from people who practice with tools and technologies different to your own.
For those within my own circles however, I think they would feel more comfortable if the pool of experience hailed from a more diverse sampling of technologies.
There are a few reasons for this, but I think the most prominent one is quite sad: It's actually very hard being a PHP developer at a conference.  Especially .NET ones.

Seriously, even the PERL guys take the occasional swipe.

If you take a general temperature check on PHP in any Microsoft circles, you may find that there is a strong tendency for people to look down their noses at anyone who self-identifies as a "PHP developer".  It's as if even the very combination of the words "PHP" and "developer" raises their hackles.
Which is oddly contradictory, because today we see recognition for nodejs, ruby and many other newer technologies from the .NET community.  Languages that frankly even as a PHP developer, I have a strong distaste for because they are so blase about code structure, global state and mutability.  But when it comes to PHP the policy is almost decisively still scorched earth!

I don't know if this is because ASP never made headway into tag-soup.  I don't know if it's because the "M" in LAMP ate all of Microsoft SQL's TCO babies.  And I probably will never know if it's because 2006-2007-era efforts to win them over with free copies of Visual Studio was only done to prove that PHP developers were just a bunch of lost causes.

What I do know is that it's 2015, Core CLR is now open source on github.  ASP.NET is on github.  Both projects are soliciting everything from commits, to suggestions, to drawings from peoples' children and homework questions.
If nobody has done it yet, let me be the first person to welcome you to the brave world of free and open source cross platform development.  I know some .NET developers have been using NuGet and were getting a small taste of this world.

But this is even more different still and before you get too much further, I would implore .NET as a community to do something about unexploded ordinance left behind from a time when things were radically different.  Certain relic ideals that fly in the face of reality and defy the successes of many that back then said "We don't believe you" -- and won.

Certain sentiments that show the .NET community is prone to large pockets of stagnation and ignorance towards things outside of their bubble.

I see this kind of yucking all too often.

Let's be totally honest and set the record straight here: Everybody can win.  .NET is getting runtime compilation, simplified project configuration, conventions, packages, cross platform and independence from IIS.  PHP has some type hinting, closures, packages, traits and some strong OO advocates.

It's no big secret, I have complete language envy over C#.  I wish I could have the environment of PHP with the capabilities of C#.  The way things are going, it's starting to sound like I just might get that too!  The difference is that I don't go around lampooning the people.  No, I learn from your Scott Hanselmans, your Jeff Atwoods, your Greg Youngs and your Dino Espositos.  But have you heard my Taylor Otwells, Fabien Potenciers, Benjamin Eberleis and Jordi Boggianos?

When I write PHP code, you'd be hard pressed to say you couldn't with minimal effort transpose it to some infrastructure-friendly C#.  To say that the PHP I author is inferior is tantamount to making the same claim about yourself.
We are converging and soon you won't be able to tell who is a cylon and who isn't - well - mostly.  I may not wear a suit and my preferred topics of discussion outside of technology may offend your sensibilities.  But would you believe that as a PHP developer I enjoy DDD, CQRS, onion architecture, [non]leaky abstractions, composition, conventions, strong typing, weak typing, closures, functional programming, unit of work, active record, repositories and POPO (POCO) services...just as much as you do?

Join with the global community and shed some of the tired marketing and animosity from the old days.  Don't be afraid to learn from PHP and admit the language got lots of things right.

And for goodness sake, if you do really need to take a swing, have the professional courtesy to do it about current challenges!

Comments

Post a Comment

Popular posts from this blog

Laravel Project Architecture: The Missing Guide

At my job, we've been doing a lot of learning and development using Taylor Otwell 's Laravel 4 PHP framework.  As we've become more familiar with it, we've had to come up with better ways to structure our projects outside of what the documentation indicates and the default distribution that is provided. If you've been working with Laravel 4 for any amount of time or come with experience from another framework and are just getting started, you've probably noticed that there are a lot of different ways to cut up your projects. Choice is nice, but sometimes it can be paralysing or misleading. Concrete Advice This post is done in such a way that you can just skim the headings, but if you want a detailed explanation in each section, feel free to read in where necessary. While I can't say the entirety of my advice is in practice throughout the community, I can say that we are starting to use it, and to very good effect at my job.  Especially consider...
5 comments
Read more

Building .NET Core Nuget Packages

My last blog post was on building and publishing npm packages, specifically for typescript projects. In my opinion, packages are an important fundamental unit in software development. They sit at the confluence of technical competence and collaboration, and represent something the software community should be proud of. Most of the time, you're going to be creating software packages once you're comfortable with some essential pillars: Coding Project structure Software architecture Building Delivery Community Licensing After I got my npm package up and running, my next task was to do the same thing with my C# libraries. Similar to protoculture, I have made a library called praxis .  This is done by leveraging the services and tooling known in the .NET ecosystem as nuget. In this case, praxis abstracts many of the concepts and functionality I require when producing server projects. It builds on top of ASP.NET Core, so in that sense you can almost think of it as ...
1 comment
Read more

Laravel is Good, Facades Aren't

I've been working on some Laravel 4 based packages lately which inevitably results in me also looking at other packages. I've noticed sometimes that people use facades at times that give me pause. The most troubling being from inside their model classes. A quick google turned up this video which assures people "there's still an instance behind everything, we're fine" .  Everything mentioned in the video is true except that there is a very glaring omission. Scope What usually goes out the door at the start of a long series of mishaps in software design is scope . When the desire to obtain a solution is stronger than the desire to consider the implications of a firm approach, mistakes are sure to follow.  Sacrifices like this are made due to the assumption of a high cost to developing carefully. What really is happening however is a false dilemma , being responded to with a convenience decision . It's very easy to write model code like ...
1 comment
Read more