I generally come across 3 types of projects:
1. Projects that were originally developed a number of years ago and have not
been updated since
2. Projects that were originally developed a number of years ago and have been
updated regularly since
3. Projects that were originally developed in the last 5 years and have been
updated regularly since
Interesting categorization, especially the 5 years part. Looks like I
misjudged the magnitude of the shift in the PHP community a few years
back (not just from your categorization, but from what others wrote as
well).
I think of languages as tools specialized for a given problem space.
Even general purpose languages have a lot of design decisions that make
them better suited for specific areas than others (e.g. memory
management, threading, scripting, …). And usually there's some spillover
of thought patterns from one language community to another (e.g. someone
programming Java in PHP, JS in Ruby, C++ in C). I thought those
spillovers were merely affecting the language design a bit more than
usual. After all if I want a statically typed language there are already
ample to choose from.
But this was clearly the wrong mindset on my part. I usually combine
various languages in a project, mostly depending on whats already part
of the environment, well maintained and stable. So my focus is on when
to combine what tools and languages. But from your post and others in
the topic most (if not all) seem to work on larger code bases mostly
focused on PHP. And in this situation it makes more sense to bring
static typing into the used language. Thanks for clearing that up.
Generally projects in 1 match what Stephan described:
My usual tool set for web projects like that is plain PHP, HTML, CSS and JS.
Everything without any frameworks or unnecessary libraries and kept as simple
as possible. If possible I just use builtin and stable APIs and usually end up
without any or with just one or two dependencies (e.g. PDF generation).
I've tried to keep this generic, but in a lot of cases I see this with local
government work that was developed several years ago (generally PHP 5). They
had budget up front to build something but then expected to maintain it without
any code changes, just by updating the OS and PHP. They perfectly match
Stephan's use case group:
I think a lot of programmers underestimate the flexibility and simplicity of
file based webservers like Apache with PHP. If you keep it simple they allow
projects to grow organically.
A lot of that are just small projects, small customers or the inglorious
everyday work that nobody likes but someone has to do. So it doesn't get talked
about much.
These tend to run for 10 years plus.
I haven't worked on any government projects, but I guess industry and
process automation isn't that different (maybe a bit less bureaucratic).
Machines run for decades and I guess this also sets the time-frame or
mindset for the software used in there (ERP systems, CRUD-like stuff
that models small processes, etc.). Maintenance of course is part of the
picture but on the software side admins are expected to take care of
that. Actually changing code to keep it running as-is isn't expected,
and of course this shapes budgeting. Except for the industry 4.0
subculture, that seems to be a totally different set of people. But I
have no idea if my experience is representative of the industry. Most of
my experience comes from companies in the range of 100-200 employees
(with maybe 5 IT people) or smaller.
I've used PHP in such environments several times, funnily enough because
it was the preferred option for the admin. Maybe the budgeting is my
hint that I shouldn't do that again.
Apart from that I often employ a way of programming that seems to be
quite different from what other posts describe. I usually optimize for
minimal complexity, minimal dependencies and maximal stability. Taking
advantage of the environment to reduce the number of moving parts where
I can. You could say I hunt for synergies between tools to avoid
complexity. This often means taking a bit longer at the beginning or
sometimes using weird tools because they're already an indispensable
part of the environment. A classic is letting an already existing
webserver handle authentication via LDAP or Active Directory. It pays of
in the long run with low maintenance overhead. It's not zero, bugs
happen, stuff changes, but it's maybe a code change every few years
instead of every few months.
For me this is just another way to write software. It works in some
situations, it doesn't work in others. Since my projects are usually to
small to justify a team of programmers I end up using it quite often though.
Also almost all of my projects are one-off "built something that does X
in our environment" things. Not evolving products that get regularly
extended (I have just one of those). Hence its difficult to piggyback
regular cleanup on feature updates.
I maintain my code and take care of notices and deprecation warnings.
But mainly I try to avoid features that might get deprecated. I restrict
myself to a conservative subset of the language. Last time I've had to
put effort into updating some code bases was with PHP 5.3 (it was just
one small language change, though). It was smooth sailing ever since.
Until PHP 8.2 recently, which indicated that some of my core assumptions
about PHP got out of touch with reality.
Thanks to everyone for sharing your thoughts. All of this gave me a way
better handle on how the PHP community ticks right now. I was surprised
by the emotional component of the discussion but I hope I didn't make to
much of a mess for everyone.
Happy programming
Stephan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
