That is, admittedly, longer than PHP but it's arguably easier to understand what's going on, much easier to modify and extend, and just as easy to copy and paste off the web.
For Sinatra:
require 'sinatra'
get '/' do
"Hello World!"
end
Again, does PHP have any real advantage here? Python solutions will be similar. And in all those cases we can turn this into a full app with only a few more lines.
There's 76 sloc of code in the blog app, plus tests, templates, database access, and more. And it's clean, clear, and simple. What does the PHP equivalent look like?
Of course, PHP is still shorter for hello world...mostly because it's running as a CGI app. This is a terrible, archaic idea for all the reasons that get discussed when people talk about Why PHP Is Terrible, but nothing is stopping you from configuring other languages that way. So here's a real apples-to-apples comparison:
Python:
print "Hello world!"
Too long? Try Ruby:
puts "Hello world!"
19 characters including white space? Beat that! :)
No they aren't easier to understand, not by a long shot.
Imagine you're some mom who's made a static website for some group you're a member of. You made 20-30 static pages with Frontpage or something like it.
It's a much MUCH smaller step to rename a file .php and add
<?date('Y-m-d')?>
Than it is to wrap your head around what that node JS or python is doing.
It's exactly that integration that makes PHP win. If someone would make a similar integration for a better language (and made it fit the other niches that PHP fits that nothing else does) they'd stand a great chance of changing the world.
The problem is, no one gets it. Just like you you're fundamentally missing what people like about PHP. It's not the language that they like. It's that it's HTML+server scripting. No setup needed, no external files needed, no libraries to learn, no security issues at least at the start. It just works, in small increments above the level of static HTML.
So you walk into a culinary studio and they're having this intense class on how to properly prepare escargot.
And you stare at them ... and tell them they should just make a peanut-butter sandwich. They stare at you blankly. Then they tell you to go #$%$#^ yourself.
Is the peanut-butter sandwich easier to make? Yes. Does it taste better? Yes. Can you use it to feed the masses? Yes.
Great analogy. I never got the arguments telling you it's so simple to change little things. When is this ever useful except for when you just get started? It only takes a couple of hours until you leave the zone where small modifications are handy and you need to structure your code, mostly using some MV*-approach.
Either short tags would be disabled and cause an error. Or nothing would happen.
<?php echo date('Y-m-d')?> -- Would be most preferable.
<?=date('Y-m-d')?> -- Won't work on half of webservers.
PHP is simple but most PHP servers are terrible. Part of my job is to ensure the smooth installation of proprietary software on around 1000 servers a year. This is the painful part of PHP development. If the client is paying less than $5/mo for hosting then I often run into problems with misconfigured servers, common features being disabled.. hell.. shit not working! Why isn't it working? I don't know. There are no errors. There is nothing logged... yet for some reason the session only lasts 7 seconds before disappearing.. yay!
I love PHP because it is simple and just works... I really dislike 80% of shared hosting providers who cause all sorts of problems with what should be a simple cross platform application.
"<?=date('Y-m-d')?> -- Won't work on half of webservers."
You're referring to shorttags, and how evil they are. Firstly, PHP 5.4 enshrines this echo shortcut usage, and they'll always be on from now on. <?=$something;?> will always work from 5.4 on.
Secondly, "half"? Where the hell are these mythical 50% of web servers that actively disable short tags? I've been working with PHP since 1996, have worked on hundreds of projects on dozens of hosts - shared and dedicated - over those years, and have come across this once, on a server managed by someone who compiled everything by hand (not just PHP, but everything) and felt turning short tags off was "optimal" because he'd read it somewhere. He wasn't a PHP dev, just had read 'short tags are bad'.
I don't doubt that some admins and hosts do turn off short tags. It is no where close to 50% of servers out in the wild though. 5% perhaps? Even that, in my view, would be a huge stretch.
Surely you realize that PHP is alone in having vast swaths of its common functionalitity disabled by hosts because of massive security problems arising in actual use?
This means PHP being crippled on many servers is PHP’s own fault.
Not necessarily. Popularity makes something more likely to be exploited. Compare PCs to Macs re: viruses. Also, many security issues were due to conventions in early versions of the language, e.g. register globals.
This is the main strength, and also one of the most obvious flaws, of PHP. What makes it incredibly easy to get started (if you start from static HTML) also makes it easy to trip yourself up later on.
Mixing logic and your text/data will work well for inserting a simple date, but when you start adding more complicated logic it is easy to create a mess which is difficult to read and modify even for you a few months later. That's the reason other frameworks/languages try to give you a more structured (and complex) starting point.
Your examples are interesting, I may look at Sinatra and flask.
One other big advantage of PHP, which I find as time goes by, is (boringly) its broad stability. I first learnt PHP over 10 years ago, and what I learnt then still works now. Web apps are a very small part of what I do, I knock together the odd small one every couple of years or so.
I did do one app in Rails, but when I next came back to look at Rails about 18 months later, it seemed enough things had changed my app broke in various ways. I find I increasingly appreciate a large community, a book or two, and some stability.
Obviously if your day-to-day life is web design that doesn't apply. My day-to-day life in high performance algorithms, and I was using new C++11 features as they got implemented in compilers, and have played with many languages in that area.
I'd love an experts opinion on c++11 in the realm of high performance algorithms. Considering most of the updates were instruction additions and fixes, is it really increasing speed and even worth it to use the bleeding edge for maybe some small gain where a 10 year old language is simply much more reliable?
Also, I didn't mention the updates in parallelism that were added (because they should have come earlier)...but do you think c++ is comparable to a modern concurrent language atm? Worth it over erlang?
I wouldn't sat that C++11 is going to lead to faster code than C++03. However, if like many C++03 experts you were already writing a lot of template code, then 'decltype' and variadic templates in particular make a lot of templated code much easier and cleaner to write. lambda functions neaten up various things.
Other people may have different opinions, but I don't think C++11 will convert anyone, but people who already have a big time, or code, investment in C++ will find much of their lives much easier. Another indirect advantage is that by moving to C++11, it finally allows people to make a clean break from older, less standard C++ compilers. Wether will we end up with a new state, where people end up supporting partial C++11 compilers, we will have to wait and see.
The parallelism is really just standardising existing behaviour in many cases. People who want to write things like lock-free algorithms are very excited by the atomics stuff, but such stuff is beyond me.
I am disappointed that some more practically useful threading algorithms, like thread pools and such like did not end up in the standard. However they now seem to be arriving as 3rd party libraries.
I think what is going on is that before a threadpool library was '2 steps removed' from standard C++ (as first you had to write, or use someone else's, threading/atomics library). Now they are only '1 step removed', they are more useful.
In modern architectures there are lots of places where you can get way faster, just by organizing your data in more cache friendly ways, or the way the data is layered across registers and memory regions.
You need a language like C++ for these type of optimizations.
The trivial example of PHP is equivalent to making a file with only the text:
Hello World!
...and saving it as a .php file. I think you'll have a hard time finding something more concise. :)
In reality, one of the things that makes PHP an easy language to pick up is that you don't have to have all of the overhead of learning how it works. Novices sprinkle bits of PHP surrounded by HTML-looking tags and all of the sudden they're up and running.
I started with PHP myself, and found it to be an interesting and frustrating language (needle or haystack argument first?). It's often saved by an easily searchable manual and a huge user base.
PHP is a shoot-yourself-in-the-foot language. It'll happily let you do dangerous, awful, bad, bad things. This wouldn't be such an issue if there was a higher barrier to entry, the real problem is it's easy to pick up (is that really a "problem"?), but that's a feature not a bug.
This highlights PHP's core strength. The incremental effort to add dynamic content to an existing static website is very low. Even for an existing page. Right from the start, every existing page is already ready for PHP to be added.
It would be interesting to create a javascript server-side environment where code is in blocks and is executed through server modules.
The benefit of being able to output HTML by default, drag+drop files over FTP or SCP to get it working, and a lanaguge that a lot of developers already know through client scripting.
I wonder if ASP still has support for Javascript as a server lanagage.
An example would be something like:
<%
require('mysql');
require('session');
require('cookie');
require('datetime');
blog_data = mysql.fetch('select * from blog_meta');
posts = mysql.fetch('select title, content, author, pubdate, permalink from posts where published=1 order by pubdate desc');
user = session.get_current(cookie.sess_id);
%>
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title><%= blog_data.title %></title>
</head>
<body id="home">
<div class="container">
<% for post in posts: %>
<div id="post-<% post.id %>">
<a href="<% post.permalink %>">
<h1><%=post.title %></h1>
</a>
<div class="postmeta">
<%=post.author %> - <%= post.pubdate.format('%m %d %Y') %>
</div>
<div class="content">
<%=post.content %>
</div>
</div>
<% endfor %>
</div>
</body>
</html>
as simple as PHP, but Javascript - and simple webapp modules like session, mysql, etc. etc.
For Sinatra:
Again, does PHP have any real advantage here? Python solutions will be similar. And in all those cases we can turn this into a full app with only a few more lines.Consider this example of a completely function blog: https://github.com/mitsuhiko/flask/tree/master/examples/flas...
There's 76 sloc of code in the blog app, plus tests, templates, database access, and more. And it's clean, clear, and simple. What does the PHP equivalent look like?
Of course, PHP is still shorter for hello world...mostly because it's running as a CGI app. This is a terrible, archaic idea for all the reasons that get discussed when people talk about Why PHP Is Terrible, but nothing is stopping you from configuring other languages that way. So here's a real apples-to-apples comparison:
Python:
Too long? Try Ruby: 19 characters including white space? Beat that! :)