source: at-w96k/content/en/posts/php-review.org@ 05217bb

#+TITLE: PHP & Symfony: libre development perspective
#+DATE: <2022-05-28 Сб>
#+LANGUAGE: en

* PHP and Symfony from libre development perspective
#+BEGIN_abstract
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.
#+END_abstract

I use [[https://www.php.net/][PHP language]] and [[https://symfony.com/][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
[[../../public/images/php.png]]

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 "[[https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/][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 ([[https://lwn.net/Articles/604630/][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 [[https://en.wikipedia.org/wiki/Advice_(programming)][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
- [[https://www.gnusocial.rocks/v2/][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.