|
|
|
|
|
|
by vinay_ys
1407 days ago
|
|
|
Very long time ago, I worked on a very large code base for a medical imaging platform that ran on multiple operating system platforms and had a shelf-life of 10+ years. The code had two personalities. First was all the scaffolding/framework and inter-process/server protocol code was meticulous and beautiful. As a young c/c++ favoring engineer, I was very impressed and my design thinking was influenced a lot by this, for a long time. Second, there were these deep algorithm implementations for digital image processing pipelines and also dicom data protocol implementation stuff. These "plugins" or "processing elements" were heavily optimized to squeeze out every last microsecond out of the start-to-finish execution wall time. So the code was hard to follow just by reading. Also, there's no way to understand this code without knowing the domain knowledge (studying the Matlab implementation of the image processing algorithm – to understand that required having a basic theoretical understanding of signal/image processing concepts). But this was great as different engineers/teams could work on different deep algorithm processing elements and the framework/scaffolding ensured there were no leakages or undue blast-radius of any messy bugs. A decade later I found myself staring at a very large php codebase. This codebase had a lot of sprawl but no depth. It was messy (bad idioms, wasteful of resources, functionally buggy etc) but it was easy to read and understand. PHP + the framework/scaffolding we had was very forgiving of these mistakes. The application would continue to chug along even with a lot of warnings and some data induced errors. It took some mental attitude adjustment to not lose it every time I saw crazy stuff like 3-level nested for-loops that would unpack an array of huge serialized objects and iterate over their elements only to not use the results for any final response rendering at all. |
|
|
I work in PHP every day, and this is something I've picked up from seeing other resources online. PHP with its automatic casting and loose type comparisons is forgiving. This would be great for getting things to run quickly and making it easy for early web development for a beginner, and I think this has a lot to do with PHP's success and ability to get new developers interested back in the late 90s and early 00s.
The issue with this is it encourages bad behavior if there isn't a style guide for the team in place. Sure, we can pass around a string representation of our integers and it doesn't matter because PHP will handle casting for us whenever, but this leads to sloppy and hard to read code in my experience.
Modern PHP has leaned towards a more powerful type system (relative to its previous). I'm really happy with the static typing that the language has added in and I think that's a huge reason for a lot of the old gross PHP code.
Another one is the easy intermingling of server code and HTML. Again, this is powerful for fast and newby development, but ends up introducing complexity and mess. Writing a SQL query inside of a loop inside of a <table> tag? You can't tell me that isn't at least a little confusing to look at.
Fine language with a good trajectory, and it's legacy helped shape the web, but damn can you get your hands dirty.