PHP & Symfony: libre development perspective

PHP and Symfony from libre development perspective

In this article I want to emphasise good and bad parts of php as a language and ecosystem. This article is mostly non technical and contains a lot of personal bias.

I use PHP language and Symfony framework at work. I don't like web-development at this point, but I have developed skills at that area, so I continue to do it. I am free software enthusiast, so it means I try to minimize proprietary software in my life, but in some areas it is harder than in others, one of them is the need to earn money for a living doing programming.

PHP

PHP is very popular server-side programming language, that being used mostly for web-development. It is tied for a use with an http-server, think of Rack or WSGI, but built-in.

PHP characteristics:

No official updated specification or a standard
Weakly typed
Optional types with runtime checks
Garbage Collected
Procedural, but community has a strong bias towards "traditional" Java OOP
Java-like autoloaded classes (but done by 3rd party software called composer)
OOP support, but not in a standard library
Standard library functions are mostly written in C
Extended by PHP extensions written in C
More static than dynamic
JIT Compilation, it is mostly faster than Python and Ruby
Documentation is available in many languages including Russian
Introspection is not great, but var_dump function is useful
Node.js styled package manager (uses json & installs everything in project folder)
Huge surface for different vulnerabilities
Uses sigils just for variables, so they are kinda useless
Even with OOP bias it doesn't support some OOP features:
- You can set fields of an object outside of setter functions
- You can't initialize some data types in fields, so you are forced to do that in constructor

You might have read the article called "PHP: a fractal of bad design". I want to note, that the language is indeed have a feel that it was built on top of poor fundament. Most of issues from that article are fixed now, but the language still falls under weight of legacy and bad initial design choices.

And yet it has good parts and that parts are important for business. That parts are:

Support from a big company (Zend)
Support of everything in C++ style The language even has goto statement
C-like syntax, so many programmers can be quickly familiar with the language
Java-like OOP, so programmers can enjoy reading Martin Fawler

Personal observations:

PHP feels like Bash or Perl with OOP features
Lack of many datatypes. Solve everything with list-hashmap datatype or an object.
PHP classes are not first class objects, so you can't pass them as parameters and forced to get strings like class::classname
It is similar to Perl, but it doesn't have good regular expression support
The language has cryptic error messages and it doesn't show parser error column
There is no pipe operator and since most of standard library is a set of function you can't chain/compose functions with each other and need to repeat yourself.
Documentation lacks articles about debugging and builtin debugger is not well maintained and difficult to use
Most CLI php apps doesn't use GNU Readline, so you can't autocomplete and forced to use rlwrap
Most PHP projects and libraries have ads, paid screencasts, certification and other beaties of corporate culture
Some PHP libraries includes non-free stuff (symfony cli was proprietary and it advertise proprietary services)
Package manager has ads in it (or to be more precise packages have ads)
Standard library is a mess because of C naming and lack of OO support (everything is in global namespace)
Frameworks like symfony have data types reimplemented. Such stuff should be in standard library.
The behavior of programming language is configured by ini config file which is clumsy and not so good in general. Same program can behave differently in a different configured interpreter.
Documentation is not versioned and some parts are missed or outdated, but overall it is good documentation.
Good debugger is not bundled and built-in debugger is not documented and not being used that much by a community.
var_dump function is good
Symfony doesn't type check everything. There are parts that can break only in runtime.

Symfony

Symfony is a web framework that wants to be Spring from java, but in php world. It uses OOP DDD patterns, Dependency Injection, DataMapper ORM. It is complex piece of software with good and quite detailed documentation.

Good parts for libre dev

PHP is not controlled that much by a single company like Java controlled by Oracle.
PHP is fast for scripting language compared to others, but not as fast as Java.
Symfony provides backward compatibility promise.
Symfony is not highly tighten, so it provides much more flexibility than monolith web frameworks like Django
Many developers are available. The language has C syntax and types are optional.
Existing ecosystem of packages. There are less things to develop from scratch (not that much packages compared to rails or django)

Bad parts for libre dev

PHP has single implementation and no standard which means that you probably will have to leave if implementators do something wrong with the only php interpreter. There are other implementation, but without a standard it is harder to switch between them (See how it is done in Common Lisp).
PHP licensing is a bit complext (LWN). You can't patch PHP without changing its name. Devs have dropped GPL license.
PHP has extension system which mostly compiled C code. I think many people don't read C code, so projects like Racket, Emacs or SBCL try to minimize C part of implementation.
PHP doesn't allow monkey patching by default. You can't redefine standard library at all. No advices from Common Lisp / Elisp world.
PHP tooling is mostly proprietary. It lacks proper emacs/vim support. Libre LSP servers are unmainteined or too laggy. Most people just use PHPStorm which is proprietary software or proprietary LSP server.
Packagist contains non-free packages.
Packagist doesn't store packages, it just contains links to git repositories. Haven't checked, but there is a possibility, that packages can be replaced by git push –force.
Since C standard library is written in C it is hard to reimplement and fix code. It doesn't violate freedom of modification since you can fix your issues in C code, but it makes restrictions in emacs thesis sense where you can redifine everything in available system. It is applicatable to other programming languages too.
Same goes to OOP. Property modificators make restrictions to user to modificate some parts of a program even if it is a broken part. There is Reflection API for fixing such issues or you can inherit broken class to a fixed class, but you can't really redefine some properties and methods.
Symfony uses Stack Overflow instead of mailing lists. Stackoverflow needs auth, it is proprietary on server side and it uses proprietary javascript on client side.
Symfony uses Slack instead of IRC/XMPP. Slack is corporate messaging solution, it is proprietary at server side and it uses proprietary javascript on client side. It is unusable with javascript disabled or with LibreJS extension.
Composer and Symfony show ads while installing packages.
Symfony has tons of ads on their documentation page. Symfony is promoting their proprietary services in docs pages. There is no documentation in info/man format without additional ads.
Symfony requires some javascript to develop it and in some cases to use it as a visitor of your website.

Why procedural OOP might be bad

Symfony and PHP heavily rely on OOP. I call it procedural because it is not like Smalltalk or Lisp OOP where you can extend anything. I don't like several things in that paradigm. The first is access modificators which makes a developer of a library in charge of its user. Luckily there is reflection in most OOP languages, so you can extend anything you want. Many people think it is bad, but library devs can do mistakes or just abandon their libraries and you want to modify them to work. The second is Inversion of Control pattern. It is bad mostly by the same reason as the first one, you lose control over some code. Instead of you running the code it is someone else running your code (mostly classes). Also as I said before because PHP has tons of C under the hood you can't modify standard library which is sad.

This is not so critical since all the code is available for free as in freedom, but this can be kinda annoying while working with third-party code. My motto is that the most useful features that provide freedom to developer are: Introspection, Reflection, Macros.

What to improve

Remove ads from Symfony docs and host it elsewhere
Remove ads from Symfony docs and make it available in info/man formats
Do the same for PHP documentation website. HTML docs are not cool at all.
Create licenses file for LibreJS
Remove all ads from package manager
Remove all proprietary services in symfony cli binary
Create mailing lists, because stack overflow requires non-free javascript to read. SO is impossible to use offline.
Create IRC <> Slack bridge or just irc room. Slack is proprietary and unaccessible by many people.

Libre projects using Symfony

GNU Social v2

Conclusions

Overall PHP and Symfony is not bad choice for libre development, but I would recommend to stick with python if it is available. PHP is better than Java in a sense, that it has much less corporate proprietary influence. I see corporate influence also in Ruby ecosystem where almost every package has sponsors by large companies, Python is much more clear in that regard.

Table of Contents