Be able to put a . inside any folder where your apache/nginx serves fiels from, then make your file give a much nicer file listing than the default of nginx/apache with possibility to comment on the file (using a __comments/directory and text file for each comment and sequence number as filename). Come back when you have to struggle with various "deployment" options in django/flask and .war files.
PHP: A fractal of bad design
151–160 of 514 posts
Re: PHP: A fractal of bad design
#152I enjoy Eevee's posts. I was first introduced to him through a handful of Pokémon sites where users would reverse-engineer the Pokémon games and protocols. He writes good code and knows his stuff. He even offered some assistance when I was writing a .pkm file manipulation package. I completely agree with most everything in this post, too. It can all be summarized in this sentence later down the page: > PHP is a minef…
Re: PHP: A fractal of bad design
#153"(And strictly speaking, Facebook isn’t written in PHP; it’s written in a C++ macro language with a striking resemblance.)" I'm a Facebook engineer who works on the HipHop compiler and HipHop virtual machine. It's in PHP, absolutely full stop. It's amazing how much the fact that g++ is involved somewhere in the toolchain confuses people in this matter. C++ is just an intermediate representation; the source language r…
I find it to be an interesting philosophical question about what defines a language. If you write code in Java, but compile it to native format (using gcj, for instance) instead of using the JVM, is it still Java? In doing so, you lose what is probably the language's biggest selling feature. Or, perhaps less relevant now, but I remember the days where people would go on about how Ruby didn't support native threads. E…
But the lines got very much blurred by the rise of scripting languages, in which - typically - the language was defined by the implementation. So for a few years there, it really was difficult to tell whether this was Python or CPython.
Fortunately, nearly all the languages to which this applies matured and got new implementations. Rubyists often to refer to the C ruby implementation as MRI (Matz' ruby interpreter), and there are lots of different Ruby implementations now. Python went out of its way to document behaviour which was specific to CPython, and put a lot of weight behind Unladen Swallow and Pypy.
But your Java example is bonkers. Compiling Java to native is still Java, its just not JVM. Compiling clojure to JVM is just JVM. The language feature is not the language. In Java's case, the language is specified, the VM is specified, the bytecode is specified. There really should be no ambiguity at all there.
Re: PHP: A fractal of bad design
#154…no template system. There’s PHP itself, but nothing that acts as a big interpolator rather than a program.
As if that was a bug and not a feature. PHP succeeds because there is one PHP templating syntax and it is called "PHP".
PHP started life as a templating language, and that's where its soul lies. Which is important, because if a non-programmer wants to start editing dynamic HTML pages, most likely the first thing they open in their text editor will be a template. And if a customer wants to change the website, but doesn't want to pay a highly-trained programmer (we're very expensive, especially because none of us really wants to be paid to edit templates all day), they'll hire someone who knows how to edit the theme. For every seasoned programmer in the world, there are half a dozen themers who know how to edit HTML and CSS, and maybe how to embed a "foreach" loop that calls a stock WordPress function, or edit an argument list, or swap one Drupal function name for another. And for every themer there's a dozen non-programmers who dream of knowing enough to be themers.
This class of user is what every other platform tends to neglect. Ruby and Python programmers tend to design tools that are intuitive to other programmers. We build "frameworks", where one must tinker and monkey-patch and fork to such a degree that only another programmer can download and assemble a working system, let alone customize it. (One word: Gemfiles.) We write programmer-centric documentation filled with jargon terms from Javaschool, like "object". (PHP themers often do not understand OO, and often don't need to. This, all by itself, could be why PHP is so popular.) But one leaves a lot of money on the table when one designs software systems exclusively for users whose programming education entitles them to six-figure salaries. There aren't enough such people on earth; that's why they earn six-figure salaries.
Designing the minimum viable product for borderline-non-programmers who want to tinker with dynamic web pages is hard work, though. PHP evolved into that niche, but if you don't start there it's hard to steer there deliberately. For me, trying to remember when object inheritance and version control and function definitions were mysterious is like trying to remember when I didn't understand algebra. (And, believe me, I really didn't understand, once. But I'll be damned if I can remember why not.) It's so hard to keep one's eye on that ball that even the PHP developers lost the plot long ago: PHP has long since bulked up with features borrowed from other languages. But if you ignore its newer features the soul of PHP is still a little templating language that you can edit into the HTML on your server; change a filename extension and reload and you're good to go. And, the thing is: You can write a crazy-complicated core system in PHP, but then expose it as an API at the template layer, and those tinkerers hacking at the HTML on their servers will be able to use it.
Re: PHP: A fractal of bad design
#155He (playing with his iPad 3): PHP
Me: I thought PHP devs died out for years??
He (angry): PHP is still the most used language for the web and it's fast.
Me: Do you guys still mix front-end and back-end code?
He (still angry): Of course not.
Back home I started googling "PHP" and "PHP frameworks" for the first time since 2003 again. I was surprised: there are many Rails-inspired frameworks like Yii, Zend, Codigniter, etc. And I tried to be objective giving PHP another chance (I haven't an actual use for PHP but I was just bored and wanted to be prepared for better counterattacks next time).
My impressions:
- There seem to be too many frameworks or call them ecosystems, so I couldn't figure out which is the dominating one (Zend?). And I am not sure if they are really interoperable
- Not relevant but awkward: most frameworks websites (except Yii) and in particular the PHP site look like 2003. What disturbed most was the often used claim "no console needed".
- On Freelancer.com, Monster or any other job-related site the quantity of postings for PHP devs were massive—any other web-related fraemwork/language else like Ruby, Python, Django was a small fraction oft that.
After looking at some "modern" PHP code (which strictly follow the MVC patterns now) I still couldn't get warm with PHP. I assume that most PHP devs are long-time PHP devs and I don't understand how PHP can attract people compared to newer concepts.
Re: PHP: A fractal of bad design
#156Earlier quoted context omitted.
Does warts-and-all PHP include that eval wart, or is it more like most-warts-and-a-subset-of-all PHP ? Not snarky, just curious if there was something I missed.
What is the problem with eval? Even Python lets you do that. There are legitimate uses for it.
Re: PHP: A fractal of bad design
#157A nit: "Subclasses cannot override private methods. Subclass overrides of public methods can’t even see, let alone call, the superclass’s private methods. Problematic for, say, test mocks." IMHO you don't want private methods to be visible in subclasses, because this makes the fragile base class problem worse. If I'm a framework developer working on a UI library, I should be free to add private methods to my Button c…
I'm not convinced this is universally applicable, but I'm otherwise sympathetic to it.
Re: PHP: A fractal of bad design
#158Re: PHP: A fractal of bad design
#159I regularly, (all over this thread), see people swear that PHP is great for beginners. Everything in this article seems to indicate the opposite. You have to trip over PHP's poor design while trying to learn to program. Outside of the wide availability of PHP servers for cheap, what makes PHP so great for beginners? With Ruby, Python, Go, hell, even JSP for the "instant", in-HTML effect, I just don't see PHP as some…
I think this is an argument that we are not good at three things: - Making better languages more accessible to utter newbies (PHP is unarguably the easiest to "get working", if nothing else of the prevalence of hosting). - Showing newbie PHP developers how to do it better - Introducing "better" languages to advanced newbies The fact that PHP is used so widely as a gateway language, and the web is stuffed full of bad…
The ease of php (as mentioned repeatedly) is that you get global access to hundreds of functions. If you know how to call a function, you can probably hack together what you're trying to do. Others (python, ruby, go) are meant for more mature applications because real problems are not that simple. You "have to" do imports and write more boilerplate, but it's also more explicit as to what's happening in the context of HTTP and enables and encourages better design.
I feel like it's a compromise and I think creating something new that is as well thought out as Go but as simple as `http://google.com) ?>` would be difficult to do. See other things like PHP: JSP, etc.
Re: PHP: A fractal of bad design
#160If PHP really is so shitty, can you please in any other language or framework of your choice finish the following project in 10 minutes, Be able to put a . inside any folder where your apache/nginx serves fiels from, then make your file give a much nicer file listing than the default of nginx/apache with possibility to comment on the file (using a __comments/directory and text file for each comment and sequence numbe…
Deploying as PSGI would take, like, three lines of nginx configuration and wrapping the bulk of the script in a function.