PHP For Academic and Practical Development: A False Dichotomy

A Dumb Argument

A few years ago Manuel Lemos wrote a post on the PHP Class blog about the wrong ideas that people have about PHP. It was largely in response to the general rejection of PHP by academics and others who hold themselves as the high priests of computing. It’s not that PHP is not taught in some universities, it’s just that getting a paper accepted at computer science conference in PHP is difficult. (By the way, Harvard University includes PHP in one of their introductory computer courses, and more than a few universities offer PHP as part of changing curricula that responds to the world around them.) Coming from academia myself, I’ve known CS faculty who act like teenage drama queens at the mention of PHP. However, I’ve also known academics who embrace PHP as they’ve come to realize that it is indeed an object oriented language and light years away from the original “Personal Home Page” intended for modest personal use. Besides, PHP is a server-side language and can communicate with an Internet-based data bases like MySQL and it’s open source.

The other side of the coin contains the legions of developers who have a job with a PHP-coded product to get out the door. They may not have a degree in computer science, or even a college degree of any sort. They have learned programming on their own and have settled on PHP as a language of choice. Generally, they also know HTML, JavaScript, CSS, MySQL and supporting Internet technologies. They see and use PHP as a practical tool to accomplish a set of goals. Their coding practices range from hacks to fully developed professional coding. Learning how to code is like learning how to write or do math; some do it well and some just enough to get by. Many such coders learn to code at work. Their job environment sets up the protocols for coding, and they follow the protocol whether they have a college degree or not. For example, one coder I know was working at a company whose new boss set up a Model View Controller (MVC) and showed everyone how to work with it. The coder learned MVC at work.

Same Goal; Different Paths

The stereotype of academics by non-academic coders is often one of fussy hair-splitters who accomplish nothing practical. The academics, on the other hand, see non-academic coders as hacks who throw together code that is a rat’s nest of statements that cannot be unraveled or re-used; they just hack out another rat’s nest. Their priorities center around an idiosyncratic and often eclectic collection of ideas, many of which are misguided or used out of context.

Both stereotypes, of course, are dead wrong. In fact, academics and practical computing have the same goals, and the goals are often from the same sources. Object oriented programming (OOP) has its origins in the practical realm of making large programming projects more manageable supported by both business and academic interests. For business, this means a more effective and efficient use of programmers’ time and the capacity to re-use the code and for programmers to work in teams that achieve a division of labor for faster development. The larger the project the more important this becomes. For academics, OOP represents a more efficient and effective programming paradigm. What’s the difference? Not much that I can see.

Different Roles: Programmers and IT Techs

A while back my email was hacked through our university mail server. I was informed of the attack, and I had to go through the process of changing passwords and other hassles to get it fixed. The IT office sent an IT Tech up to help me get everything reset, and we got to talking shop.

Much to my surprise, he told me that he really didn’t like to program. For some reason, I simply assumed that if a person was into IT, he/she would also like to program. However, I should have known better. The most loathsome chore for me is mucking about with set-ups. When I update PHP or install a new version of MySQL, there’s a lot of tweaking that I have to do so that everything I’ve done still works. If there’re any commands I have to issue via the terminal, it depends on whether I’m working with Windows (and which version), Mac OS X (and which version) or Linux (and which flavor). Further there are PHP files (like php.ini) that must be tweaked as well. Every time I have to look up the different commands on the different OS platforms, and it differs for the language, database and what I consider the fickle whim of the person who wrote the blasted parameters in the first place. So, no, I do not like IT work or system administration.(However, I love IT Techs and System Administrators who keep everything humming along.)

Problems seem to arise when IT Techs, who are not also programmers, make pronouncements about programming. One guy I ran into who was super helpful in getting my Raspberry Pi configured with a Raspbian OS (a Linux version of Debian OS configured for the Raspberry Pi) turned into a jerk when I was helping Raspberry Pi users ease into PHP. He started mouthing off about PHP and OOP, and it was clear that he had no idea what he was talking about. He figured that since he knew how to issue short Linux commands, he was an expert on all things programming. For a newbie, these characters can cause a lot of damage because noobs probably cannot distinguish between programming and system administration. (By the same token, just because a person is a good programmer does not mean that she can help you set up the right flags and settings on your OS.)

Whether you’re an IT Tech or a programmer (or both), it’s important to realize that system administration and programming live on two different planets. I fully realize that there is some overlap, but each requires a different mindset. Good IT Techs know which terminal/OS commands to issue and the order to issue them in. Programmers, on the other hand, really work in an environment where they both create the structures and write code for the structures they create. Classes and methods along with arrays, loops, conditionals and a host of data types and properties need a different kind of orchestration. Keeping them separate is essential to excelling in both.

Copyright © 2014 William Sanders. All Rights Reserved.