201–210 of 320 posts
Earlier quoted context omitted.
In a few years most NEW projects will probably not be made in PHP. You are suffering from Cognitive Dissonance, PHP is not good.
Uh... You're quite wrong about that statement. If I could find you in real life I'd love to make $1,000 bet with you.
I propose this as a blueprint for a solution: {% name = request.get('name','world') list = ['this','language','rocks'] %} Hello {{ name.upper }} {% for item in list %} {{ item }} {% endfor %} Save it as 'index.nxt' and run it in any future language you are going to design. Create a mod_next and try it on any web server like apache, nginx, etc. It should work without any extra fiddling with config files or installing…
Here is another point that highlights the problem: If I want to write a hello world application in PHP, it's neither as long as nor as short as Rather it's simply: hello world. Just type in those 11 characters in a text file and save it as hello.php. Now load it on your browser [or run it from command line] and it will print hello world. I don't think it can get any more simpler than that in other languages. PHP was…
Are you seriously basing a whole argument on what the hello world program looks like? That has nothing to do with actual real world programs. Mixing logic & presentation might make it easier to get something running quickly, but it's one of the downsides of PHP that these things get mixed up when they probably shouldn't for a project of reasonable size. The whole idea that it's an advantage of PHP that you can get so…
Unfortunately, nobody starts out well-educated and experienced. And many projects start out small and grow. If you want to make your platform a broad success, you need to have a good experience for noobs and quickies. PHP is an abomination as languages go, but it's massively successful because any idiot can quickly get something basic up.
Perhaps someone should make 'PYP', a Python that's easy for PHP programmers. Like PHP, .PYP files would be templates with no limits on mixing presentation and logic. The filesystem hierarchy provides the default URL-routing. But, you get the regularity/power/compactness of Python wherever you want it. (Perhaps, every line in a .PYP file beginning with '\' is meaningfully-indented Python.) If you ever want to hijack a…
I don't think it's widely used, though, probably because the possibility of using PHP in this template-like way isn't actually a big advantage (serious PHP devs almost certainly don't use PHP that way); PHP's big advantage is that it's installed everywhere.
Earlier quoted context omitted.
Do you want to provide an application that anyone can run and easily deploy on their own server with as little configuration as possible? Oh. I hate PHP as much as anyone (of course), but that's what it does.
That's the thing right? With PHP you need a server or you can't do anything. With Django, Sinatra, Rails, Flask, (Node?, Meteor?) you have all that for development as part of the application. To deploy you just push to a free heroku instance and you are fine until you get big. Much, much easier than setting up your own Apache+PHP. And much, much cheaper than buying hosting.
It costs 3 bucks for host gator, hmm maybe 4, but heroku is very opinionated on how you should structure your project.
Is it my imagination or is Marco the king of writing blog posts that are quick reactions to whatever is trending on HN? The message you should get from this post is that familiarity with one's tools easily trumps any aesthetic flaws (consistency in parameter ordering, naming conventions, etc are really nothing more than aesthetic flaws and not "deep" [1] as the author suggests. After all, human language is inconsiste…
someone who has mastered in PHP will no doubt be a lot more proficient in developing apps than a junior/intermediate python or ruby developer. same can be said for reverse.
it really all comes down to knowledge and experience.
Earlier quoted context omitted.
> The only thing actually wrong with PHP, is that it's popular but not cool. Hey now, we're all human. Even engineers. As soon as something becomes popular, it is no longer cool. Cool is the next popular. Cool is being different. That's just how things work. Apache is slooooow (NGINX is cool!). MySQL is retarded (Postgres is cool!). PHP sucks (Python is cool!). Red Hat is lame (Ubuntu is cool!). See a trend? The tech…
But the problem is MySQL and PHP are objectively, measurably much worse than the alternatives you have listed. Cool-ness biases are perhaps not so easy to distinguish from justified ones.
I was a linux sysadmin at a university for 6 years, and I used linux personally for a decade (before switching to iOS dev). During that period, I've had brief, frustrating encounters with Redhat.
It's not that it is unusable -- anything which can be done on Debian can be accomplished on a Redhat box. It's death by a thousand little annoyances, which is exactly the argument against PHP, so I think it's an "apt" comparison (pun intended).
For example,
* How do you restart apache on Debian? "/etc/init.d/apache restart". On Redhat? "/etc/init.d/httpd restart". Ah, so Redhat is in the habit of renaming all of their init.d scripts after the protocol of the service? Nope, turns out they only did that to Apache's script. WTF?
* While we are picking on Redhat's Apache, they also chose to pollute /etc with a bunch of crap which doesn't belong there. Symlinks to /var/log/httpd, /usr/lib/httpd/modules, /var/run, etc. So now, when I grep /etc for something config-related, I pause and think "why is this grep taking so long...", and then a bunch of crap from /var/log spews onto the screen. Thanks, guys...
* Still on the Apache kick, they decided to make the default permissions drwx------ for /var/log/httpd, with root as the owner. Really? Root is the only person who will ever need to look at those logs? Perhaps chgrp'ing to adm would be more sensible?
* Which leads to another problem... because they put their WSGI sockets in /var/log/http (WTF?), which is... only accessible by root. Wonderful, so now I have to reconfigure all of my WSGI processes to stick their sockets into some other location, like /var/run. On Debian, this "just works".
* The package maintainer of util-linux arbitrarily decided to remove cfdisk because it was a "pile of junk" (https://partner-bugzilla.redhat.com/show_bug.cgi?id=53061 ). Really? Because every partition I've created on Debian for a decade worked just fine, using cfdisk...
* There is (was?) no "vim" package. On Debian, to install vim, you type "sudo apt-get install vim". On Redhat, you type "sudo yum install vim", then go search google for a few minutes, and then type "yum install vim-enchanced". Thanks, guys.
* Supported packages. At the time, the Debian package repository was something like 12,000 packages, while Redhat's was around 3,000. This meant that for any production system, you inevitably had to either compile and install lots of software by hand, or you had to rely upon the community (e.g. http://dag.wieers.com/rpm/) for pre-compiled packages, but now you've just thrown away the consistency and quality level which comes from e.g. Debian's Policy Manual, and you've introduced a rather gaping security concern into a "production" system. Wonderful.
That's all I can recall off the top of my head, but the gist here is that there are a ton of tiny little bad decisions which make Redhat suck, and there's simply no good reason for it. Its just a pile of annoyance.
Unfortunately, Redhat has somehow positioned themselves as the "enterprise" linux, so PHB's often make the technical decision to go with Redhat, completely ignorant of its technical deficiencies, dooming their employees to suffer the consequences.
Perhaps I'm jaded, but when someone tells me they run Redhat, I immediately assume they made that decision from a position of inexperience, and they simply don't know any better.
Disclaimer: I'm a Rails programmer for work and hobby. Interested in learning something that isn't PHP to code your web applications in? Ok. You have a ton of options and this is a very exciting time to be a web developer. Do you want to lean towards stability and proven concepts and work within a full application structure? Look at Django and Rails. Do you want to serve up responses from a simple script without a lo…
> Interested in learning something that isn't PHP to code your web applications in? That's the problem. I'm in the same boat as Marco with pretty much the same reasoning. I'm not interesting in learning something -- I'm interesting in starting and completing my next project as quickly, cheaply, and well designed as possible. I'm willing to accept that, all things being equal, a better design is possible in Python or…
Software development is a Red Queen field [1]. If you don't take the time to keep up, you will eventually get left behind.
Earlier quoted context omitted.
Actually, I find Python and Ruby much more interesting than Java (actually, Java seems as a boring language :) ) . But since Java is general purpose language and it's known as market skill, I want go for it.
Python and Ruby are both general purpose languages, and both also run on the JVM. Knowledge of Java can be useful though, as terrible as the language is.
Earlier quoted context omitted.
I don't know enough about MySQL vs Postgres or RedHat vs Ubuntu to make a point with them, but sometimes it's not about being cool. Apache is a webserver from 1995. It uses a process (sometimes a thread) per request, a architectural decision which made it nearly fundamentally incapable of solving the C10K problem. Only back in January was the Event MPM added (and it's still experimental), allowing you to have many Ke…
You wrote a well thought out response. I owe you a response in kind. People have a tendency to overrate their rational capacity to reason out a viable decision. While you listed a few solid critiques, the situation is infinitely more complex. And by infinitely , I do mean exactly that. As in, beyond your capacity to reason it out. In the end, the only right decision is a decision which withstands the test of time. Bo…
> C10K is not a problem and never was.
Somebody better tell the developers of nginx, Lighttpd, Tornado, node.js, Cherokee, Apache Deft, IIS, and Jetty! All those hours wasted developing solutions to a problem that doesn't exist.
> Which is why people continue to use Apache.
For someone who just decried a situation "infinitely more complex" a few line breaks ago, you sure did generalize the reason millions of servers use a certain piece of software. It couldn't be because Apache has an easier installation on most of the common distros or that cPanel/WHM, the most-used virtual hosting control panel, only supports Apache as its web server. It also couldn't be because of mod_php.
This all stems from your conflation of popularity with quality. PHP did not become popular because it was good. It became popular because it was easy to learn and run.
> Except that article was written by somebody who doesn't have much experience in PHP and most of those complaints don't apply to the current stable version. The rest are easily avoided with sane design.
Most of his criticisms were completely valid, so I'm not sure where you're getting the author doesn't have much experience in PHP. Which ones have been fixed in the current stable PHP? And which ones can be avoided "with sane design"?
> Which explains why Python is so unpopular.
Now I know you're spouting nonsense: https://github.com/languages/