Related
I am tasked with learning PHP, but there are many things I don't understand. For example, the concept of "variable functions" is not one I've seen anywhere else. There are many other examples, but for brevity, I found PHPWTF, which has many examples of PHP's idiosyncrasies.
Most other languages I've used have either a formal specification (e.g., Haskell 2010) or at least a research paper on their formal semantics (e.g., this for Javascript). However, I can't find anything comparable for PHP.
There is an official "language reference". However, it is very informal, reads like a wiki, and is missing entire sections (e.g., the section on syntax doesn't define the syntax at all). Confirming what I suspected, this guy tells me that there is no official specification, nor even a defined syntax.
Wikipedia has an article on "PHP syntax and semantics", but it only touches on the syntax, and barely mentions semantics.
One paper I've found on PHP is this paper on its assignment semantics. This is a very small fragment of the language and probably not much use to me without some context. There is also this paper on 'SaferPHP', which presumably has to work with some definition of PHP, though I couldn't see any.
Interpreters/compilers provide a semantics, so I thought to look at these. However, the Zend source is intimidating (though it does provide useful test cases), and HipHop runs to 2.7 million LoC. (I find it amazing that people have poured enormous effort into writing compilers for a language without ever writing something like a specification.)
I thought of looking at type systems for PHP for guidance, much like TypeScript provides some guidance for JavaScript. I found these tantalising slides on Hack, an optional type system for PHP. However, it's just slides, and the project seems to be an internal one at Facebook at this time.
Does anyone know of anything better than these poor man's semantics? Or does everyone just "learn by example"?
It seems that you're not after an official standard (which might be useful, for example, to someone writing an independent conforming implementation), but for a presentation of the language that will allow you to make coherent sense of it. Unfortunately there cannot be such a thing, because PHP does not have a coherent formal model behind it. It has grown organically and is now saddled with inconsistencies, most notoriously in function and method naming but also in little details like what counts as true and false, and other similarly worrisome details.
The best one can do to approach PHP, in my opinion, is to get a good feel for the core features and libraries, for the "gotcha's" that you need to watch out for, and (in order to read existing code without distraction) for the anti-patterns that are all too common in real-world PHP scripts. My guess is that it's best to learn PHP under the tutelage of people who know how to work with it effectively, but I didn't have that luxury. (Regarding the documentation: It took me forever before I noticed that you can use square brackets to index into strings. The feature may be mentioned somewhere in the documentation, but not, back then at least, anyplace where it belongs.)
This article gives a nice tour of the kind of things that make a semantic model of the kind you want impossible. (You may want to skip the opening rant and go straight to the discussion of PHP features.) There are many, many other similar texts. Quote: "PHP was originally designed explicitly for non-programmers (and, reading between the lines, non-programs); it has not well escaped its roots."
Don't get me wrong: I work with PHP, and although it's not my favorite language, I wouldn't say I hate it. I would say that to work effectively with it, one must be aware of its nature and limitations. If you're coming to this from Haskell, you're in for quite a shock.
This answer comes a bit after your initial question, but now we finally have a formal semantics for PHP. Check it out: http://www.phpsemantics.org. A paper about it has been recently published in the ECOOP 2014 proceedings, if you are interested you can find the link in the webpage I linked. Regards.
Doesn't directly address your inquiry, but explains some of the magic behind PHP variables.
http://webandphp.com/how-php-manages-variables
Interesting question. I'd regard the manual as the official language reference; I appreciate it isn't quite "formal reference" in the sense you are seeking, but I don't know how much such a thing would be widely desired as something to learn from.
I'm not familiar with PHPWTF, but I'd guess it is in the same mould as the blog post Fractal Of Bad Design (linked by #alexis earlier). I can't peer into the mind of either author, but it seems to me that they are written from the perspective of wanting PHP to be bad. Religious wars frequently dominate on the internet and in programming — the browser you prefer, the IDE/editor you use, your operating system and your choice of framework have all had the same ferocious, partisan and unyielding treatment. Programming languages are, sadly, no different.
It is certainly true that PHP does have a number of design inconsistencies, in particular about how nulls are treated, and in the ordering of parameters in standard functions. However, it is also true that PHP has been hugely successful, despite all that. It spent a long time in the reliability doldrums in 5.0 and 5.1, 5.2 was stable but arguably not enterprise, and it's finally coming of age in 5.3 onwards.
Whilst this might be my biases emerging, I sense a consensus amongst users I read on Stack Overflow that all of the popular languages have their place. This is partly a response to the reality that the ones we dislike won't go away, and partly perhaps that learning .net, Java, Perl, Ruby, PHP, Python etc is pretty much always a good thing. Maybe we have also collectively tired of the flame-wars over each (Java is bloated, PHP is inconsistent, Microsoft is vendor lock-in, Rails is unstable, and so forth).
I've veered rather off-topic, but I tend to regard this particular viewpoint as worth reading, especially for those who would be traditionally minded to disagree with it in relation to PHP.
To address the purpose of your question, how should you learn? Well, learning by example is an excellent approach - one just needs to know which examples to learn. Searching for "PHP tutorial" and "PHP beginner" will — perhaps as is the case with any language — offer a mix of excellent and dreadful material. One might argue that PHP's low barriers to entry have given rise to a large stock of insecure and badly written "how to" articles, and I've certainly seen quite a few!
I think the solution is to look directly at code from well-engineered projects, and to learn from there. Such as:
Symfony2 (and Components)
Zend Framework
Guzzle
Propel
Doctrine
Ah, nearly forgot; this website is also a good place to start.
Post Script: they may be referred to by a different name in other languages, but I expect they all have variable functions. In JavaScript for example, it's object[myFunc]();, where myFunc is a string.
It's not exactly a formal semantics, but, after all these years, the HHVM project has produced a PHP specification!
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I was reading the article "PHP Sucks, But It Doesn't Matter" by Jeff Atwood.
In the comments he writes:
That said, I absolutely think it's important for PHP devs to be aware of the architectural limitations of PHP, and understand the alternatives.
What are those limitations and how do they compare with other scripting / weakly typed languages?
Also, what are the alternatives in those conditions where limitations need to be avoided?
There are basically two real limitations I see:
PHP is a fully synchronous language. This has impact on which things you can easily implement in PHP and which not. For example implementing a Long Polling driven chat application isn't trivial, because PHP would need block one process per chatter. I'm not saying it's impossible, you can hack around this limitation using some PHP Daemon library. I'm just saying that this is one of the cases where other languages, like JavaScript, are more appropriate (NodeJS).
PHP is slow. Please don't understand this an an offense. It's a fact that PHP - as implemented by Zend - is slow compared to other scripting languages. This typically is no problem when building websites, but you obviously can't do certain things: Implementing a ray tracer in PHP is definitely a bad idea - whereas in JavaScript you could do this.
But apart from that, I think that PHP is pretty multi-purpose. You can use it for nearly anything - and I do ;)
Take a look at the date. The article was written in 2008.
It means, that if you'll see the PHP5.3 advantages, you'll find there many things, like closures and namespaces, which were in other languages before. Some of them is already affected the architecture of famous frameworks, like Symfony.
And that list will never be complete.
Meanwhile, I meet a lot of people who think that "weak typing" language is an architectural problem itself.
Then, some people think that inline regex syntax is good thing in, for example, JavaScript, but others think, that "different language" must be written down in string constants there, as in PHP. Etc.
I'll take a stab at this without getting too into the nitty gritty:
The initial design of PHP as a collection of functions still shows through.
Object-oriented patterns that have been implemented in the latest PHP 5 releases are still half-baked and lack multiple inheritance (or "mixins"), proper module support, and are designed to be backwards compatible with the CoF (collection of functions) design.
Method overriding and callbacks are not supportive natively.
Closures. They are there, but they are very weak.
Errors vs Exceptions — methods are inconsistent in which they use (thanks again to CoF design), and error-handling is half-baked.
I'm sure I'm stepping on someone's toes here and I'll get any angry mob, but I'm also sure that I still didn't hit everything. It's largely subjective, but it's easy to see what is to dislike when you stack PHP up next to Ruby or Python.
I don't find it odd anymore that all of "PHP SUCKS" articles are coming from developers accustomed to established Microsoft technologies.
What I do find odd are statements that indicate that PHP is a spaghetti code. It's completely up to the author of the code whether the code will be spaghetti or if it'll use certain design rules when approaching the problem.
The reason a lot of PHP code out there is spaghetti code is because examples and tutorials are such that they don't teach beginners the good coding practices. Also, people are quick to grasp examples like hello world or connecting to MySQL, doing a query and looping over the result - but that's it, that's where ALL tutorials stop. I still haven't found a tutorial that covers the following:
what is a framework and what it helps with
what are data structures and data types (explained in a way a normal human can understand)
what is an array, what are array dimensions, how do arrays work, what are arrays useful for
what is object oriented code, why object oriented code, how does PHP do it, what is considered good, why are there patterns out there and so on
As you can see, a beginner programmer won't be bothered to learn all of those points outlined above, I know that because I was a beginner too and did all the mistakes beginners do. However, even if someone doesn't know how to program, they can still create useful applications.
Many popular scripts were written by people who knew WHAT they want to achieve, however they did not know HOW to properly design the environment (framework) in which they'll deploy their php code.
That's why we see scripts that become incredibly popular due to the ease of their use as a regular user which are hard to extend looking at it as a developer, using weird function names, odd coding conventions and no commenting.
Also, what's ridiculous is saying PHP is slow which is absolute nonsense. When I come across such statement, I want to shoot myself in the head for reading such a blog entry.
One has to know several things before making such a statement:
PHP is a scripting language, that means the interpreter is invoked every time someone requests a PHP page which takes A LOT of CPU power. That has been addressed by using bytecode caching mechanisms such as APC which stores the copy of pre-interpreted piece of the script in memory. The results are impressive, and I kid you not - execution for some of my scripts goes from 20 milliseconds to 1 microsecond, where some benefit "only" 5 times. That's on a system that serves 1 thousand concurrent users. Now, if someone wants to tell me that 1 microsecond is slow (or 5 milliseconds) - I'll take that as bullshit.
PHP is not the only thing involved in serving a web page. There's also underlying server (Apache) which has its own issues, there's MySQL which runs queries - and who says all queries are optimal? There's the network, there's the hard disk, there's the CPU, there are tons of other processes. Configure Apache with PHP-FPM, optimize MySQL to perform good on 8 core machine with 16 gigs of ram, use APC, use Memcache - and voila, you're getting an incredibly fast, scalable system capable of serving an incredible amount of traffic.
Languages that PHP is being compared to are often "compiled" into the bytecode and then executed by
You can extend PHP yourself. Assuming a PHP function is slow, NOTHING prevents anyone from creating a .so in C that is able to do the job faster and then hooking everything up trough extension in PHP. Not that I know what would such job be that would require that, but such a thing IS possible.
Sadly, and I say sadly because I respect certain programmers and admire their work (and I'm by no means a PHP fanboy) but it hurts me when I see uneducated, inexperienced and subjective comments about a tool which spreads misinformation.
As for why big websites use PHP - because it's fast. Because they laid proper foundations before starting the projects. Because it's free, extensible and scalable. Because it follows C syntax. Because you can extend it when you need it to be faster. Because it runs on a free operating system. Because it's easy to use.
PHP is improving everyday. It is open source and used all around the world. That said, when you have a problem, it is most probable that you will find your solution or get help faster than any other language.
The very reason of this article, I believe it is simple. If you (or in that matter any other programmer) used to code in C++, Java etc.. they had a lot of possibilities such as OOP coding and PHP was limited in the beginning.
It is a good thing that PHP has many built-in functions / methods / classes so you don't have to spend hours to code some function / class / method which PHP already has.
You don't have to (and you shouldn't) try to memorize all these functions. It is useless to memorize all of them (which one is doing what, how to use it etc). Imagine you are working on some project which took you 4-5 months to finish (yeah big one (: ) You are not going to use all these functions in all the projects and eventually you will forget what they were doing since you don't use them often.
The point is, you should know the syntax of PHP. When you need to do something, check first if PHP already has what you want to do in its library. Check the manual to see how to use it. This way, you will also LEARN (NOT MEMORIEZE) the ones you use often and this information will be hard to forget.
PHP or any other programming language is just like a normal language which we humans use daily to communicate with each other. If you don't use it, you will forget.
PHP 5.3 and above brought many features. Static feature is one of the biggest feature for me. It made my life so much easier that I can't even begin to describe.
Since PHP is that famous and open source web scripting language, Facebook developer team created HipHop.
What HipHop does is, takes the data from PHP and sends it to C++. C++ does all the process and sends back results to PHP for outputting.
The whole idea of HipHop was to make Facebook use less servers & improve the page display times.
Now you tell me if this seems limited and / or slow to you?
i dont think there is anything like 'architectural limitation' for php. developer knowledge limitation might be the reason. read this http://www.quora.com/What-is-Facebooks-architecture . most of the time, non-world-class developer does not know how they could use php to its full capabilities.
I would assume he is referring to the fact the the OOP portions of PHP are not the greatest compared to languages that are purely object oriented.
Architecture Limitations in Addition to nikic's answer
Writing extensions for PHP is a PITA. Not as bad as with Perl or Java, but not as easy as it could be. The ease of extensibility champion is still TCL which hails from the early 90's. Nearly any C function taking char* can be made into a TCL extension.
Embedding PHP in other systems. mod_php, gtk.php.net shows it can be done, but Guile and TCL are much easier to embed.
There are a ton of PHP frameworks out there (i.e. Zend, Seagull, Symfony, CodeIgniter, CakePHP, Yii, Prado) that do a great job of implementing important pieces of a scalable/maintainable website, and I almost always pick one to start building client websites.
As of recently, I've started getting tired of providing constant development services to clients, and I'm looking at the possibility of writing more full-featured commercial scripts that can be resold over and over again in the hopes of finding that magical "recurring revenue stream" that you always hear about in fairy tales. Please note that I'm not talking about building extensions/plugins to CMS systems like Drupal or Joomla, but full blown website scripts.
So here's my multi-part question:
Is there any reason why I couldn't resell a script built on one of these frameworks as a full-blown turn-key solution (especially if the framework's licensing is something very flexible, like the BSD license)?
If not, why aren't others doing the same thing?
Have you ever seen a commercial PHP script that is based on a well-known open source framework?
I've wondered this for years, and no one I ask has ever really come up with a good explanation. It just seems like it is taboo to do so, and no one really knows why? I've seen commercial scripts that use third party libraries (i.e. jQuery, PHPmailer, etc), but never have I seen one built entirely on an application framework.
It really seems that a lot of people have missed the true nature of the question and even taken it as far as language debates (those never end well).
Is there any reason why I couldn't resell a script built on one of these frameworks as a full-blown turn-key solution (especially if the framework's licensing is something very flexible, like the BSD license)?
Assuming the framework license permits it then there's no reason you couldn't do this. You had mentioned Zend Framework so you may be interested in looking at Magento. While they offer a free community edition they also have a paid edition that works with the Zend Framework as well.
I recently worked with a file upload script that was offered commercially and it happened to be built on codeigniter (name escapes me at the moment).
If not, why aren't others doing the same thing?
My personal opinion is that it's a mix of quite a few factors really. The web based market for on premise applications (as apposed to SaaS) is already flooded with options and is starting to shrink in size. This makes less demand for an application that you would actually see the framework behind (with SaaS you most likely will never know what framework if any is being used).
A lot of the existing large players in the PHP market have been around for a while and already have their own code base that they have created and are familiar with. When you've spent years building your own libraries it's hard to justify moving to another framework.
A lot of the smaller players rarely educate themselves in proper application design and usually stick to procedural code. The big OOP features that exist in PHP today didn't come along until the 5.0 release. Mind you that was around 5 years ago but a lot of your programmers had started on their PHP tutorials and learning adventures before PHP5 was widely available and accepted on standard hosting accounts. As such most of our modern frameworks were not available CakePHP as an example didn't start until 2005. Zend framework wasn't around until 2007. These are all relatively new dates and I wouldn't expect to see a lot of commercial applications moving to them until the current generation of programmers that can write quality commercial applications age a bit (again just my opinion).
I have to heartily disagree with back2dos..
PHP's a solid, incredibly well used programming language for developing web apps. It can, of course, be used for commercial development and millions of people (me included) do just that. I'm not sure PHP bashing is really relevant here.
True, PHP is not compiled but if you really care about this you can use Zend Guard which can encrypt code. Personally I've always found open source code a plus point. Clients like to know they can get at the code if they really need to, it offers some reassurance.
There are lots of OS PHP apps, some great, some awful. Find a niche (like any business), something that has real demand, and develop for that.
So I think you're fine to develop commercial apps/scripts. Just make sure you give them decent support and documentation. You'll find people appreciate that and are willing to pay for it.
Finally on the point of your question, I agree they stand a much better chance of being used if they are based on an open source framework since you'll be opening yourself up to wider market. Zend Framework, as you may know, has a pretty open license which says you can sell anything you develop with it.
I think your most important question is point 2, why aren't others doing the same thing?
Well some people are. Vbulletin have been quite successful selling forum software, even though there's no end of free forum software available. I think their success can be attributed to a paid product, in part. As they're earning money, it's easy to fund further development. Open source, free projects usually require a dedicated team to keep development moving, as there's no money for motivation.
There's no shortage of turnkey solutions available on the web. eBay will have no end of $5 scripts available - they're usually rubbish and unsupported.
Where I work, we develop bespoke 'one-off' applications for our clients, but we're looking at selling the same applications to other clients as an opportunity to scale our business. In this case we're talking about large projects worth tens of thousands, but they're only sold to a handful of customers.
There's no reason why you can't sell a product for 50 or 100 dollars and make money - you'd just need to sell to 10, 100 or 1000 customers to start making a living from it.
And to succeed over the free open software? Produce something that isn't already available, or do something much better than what's available for free.
Finally, another model you may want to consider is software as a service. Take a look at Basecamp (37 signals) for example. Their product is not open source, you can't download it, but you register online and pay something like $10 for their lowest end offering per month.
They don't have to give out source code, and they have a solid recurring revenue stream. They have tens of thousands of accounts.
Yes of course you can sell it.
Most people don't just sell the scripts as normal people and businesses don't know what to do with them and so require a developer to install and configure the script. Developers won't then buy the script if there is an open source/free alternative. If the script performs a valuable task that is often done, then somebody is likely to copy it and create an open source version.
Your key to selling PHP code is to sell it as a service. This could either be the installation and configuration of it (like most web design/development agencies) or an on-demand version of it (think of any online business app).
My company writes and builds a lot of PHP software for businesses and as we get new clients and solve new problems we write our code in re-usable classes which we can then package up and sell to other clients without any further coding - which I assume is what you are trying to do. It's all possible, it just takes time and planning to write the software to make it re-usable for other projects.
Well in this case I think that codeigniter will be the best option because:
Don't need console access to configure
You just have to configure Database Connections
Fast, MVC, Cache, Logs, Good Documentation
Runs in PHP4, must of the people that buy this scripts have server restrictions to Upgrade PHP
Best Regards,
Pedro
As a PHP developer for over 5 years and selling scripts I never tried to developed a commercial script with a framework.It is just because Im not a good fan of any PHP framework.
Someone can say if you don't use framework you are a amateur as a developer.But I think its the a way any developer has rights to choose.
I think some companies don't use frameworks just because they just dont like to say this script based on 'ABC' to the customers.They want to boast about their scripts and only they can developed something like that.
I event seen any commercial web script that used any frameworks so far.
I can think of one reason against it: piracy. If your script is something a bunch of framework guys want, it will be pirated. If it is only for a rich niche, you can avoid this, but then you aint going to get any fairy-tale income.
It's not in the open source spirit of PHP. The trend is to give it away and then bill for the service. You might be better at marketing your script as such, and just charge people after they consult you and you hand them a script download and a manual.
i think, these are the key reasons, why it is not done:
the point of PHP was never building commercial applications (the original acronym means "Personal HomePage") ... it is an insecure, inconsistent language ... there are quite some good PHP frameworks ... nevertheless, the language is ... poor ... other server languages are cleaner, stricter, more secure, more powerfull, give access to a larger codebase and to better developement tools (notably java and the whole .NET stuff) ... i'd never use PHP if i had to built something really reliable ... (my favourite is this "overflow vulnerability fix" of chunk_split (line 1966)) ...
PHP is always open source ... ok, there are obfuscators, or even ways to distribute PHP in a binary form ... but the first is likely to break the code, if you do a lot of reflection/introspection, and the second usually requires some PHP extensions to be run, which is not really sexy ...
there are too many open source PHP projects around for any commercial software to succeed ... this was different before, but nowadays, you can simply get ANYTHING in PHP ... Typo3, Joomla, Mambo, osCommerce, PHPBB etc. ... frameworks as Flow3, symfony, CakePHP ... etc. ...
there are commercial sites running on PHP, but there is no good PHP software/framework i heard about, that i would pay for ... there's always a free alternative, and usually it is better ...
you will be having a hard time creating something, that is really worth buying ... and if you succeed, you will be having a huge community that will copy it, if it is worth buying ... either for personal commercial profit, or simply to provide a free solution ...
well, that's what i think ... :)
edit:
let me clarify my points
seems, i upset some PHP folks here ... that was not my intention (however i am quite disappointed, how biased you seem to be, given the fact that everyone contradicting me is a PHP developer and i seriously ask myself, what other languages you ever used) ... i myself started out with PHP on server side too and after moving through other languages, i came to see PHP in a different light ... explanation is provided ... whoever just does not want to read it, move on to point 2 ...i am not saying, PHP prohibits you from implementing a specific solution ... but it is being used to implement solutions it was never designed for ... it started out as >this< ... and it was constantly extended by many people, which produced:
an inconsistent API ... or does anyone else know a language, having a naming convention, where array_search, count and implode are all array routines? look at ruby, ecmascript or Haxe if you wanna see how beautiful core language APIs can be ... i'd say it's awfully designed ... but it's not designed at all ... it has simply been thrown together by numerous PHP contributors ... that's cool in the sense that you have a function for everything ... the point is, you probably won't find it ... ok, after a while, you will know it all ... probably ... but in other languages, for example, where arrays are objects, it does not take you long to know all core array routines ...
no real philosophy ... look at the languages mentioned above, look at Objective-C or functional languages, if you want, to see how consistent a languages semantics and philosophy can be, compared to PHP's "oh well, we'll just throw in another function, that'll solve the problem" ... also PHP arrays are the strangest data structure, i have ever seen ... something like a hyperpotent hash with internal order for keys and values ... and yet, it's not even an object ...
a lot of unsafe code (a lot of functions exposing overflow vulnerability or not being binary safe, or not escaping is documented, which could be used for XSS attacks) ... when i read an API reference, and it tells me what a function does, but the truth is, i have to take in account a lot of possibilities (long strings could crash my complete system or even inject ANY code, nullbytes could make escaping routines not work, but when printing out the string again, they disappear (this was a strip_tags vulnerability until not too long ago)), then that is what i call unreliable and dangerous ...
slow execution ... eaccelerator and similar extensions can reduce booting time signifficantly, but execution it self will still be slow ... the actual problem is, the language is far to permissive, which causes a lot of overhead ...
PHP was designed as a scripting language tying together a bunch of C functions ... it is often extended with further C functions, due to the fact that it is not the fastest language around ... this gives a nice speed up ... but how the hell do i know, whether a function is safe? who can tell me? i don't want to read through lines and lines of C to know ... so my two main points:
the API is a mess
what is behind that API can be a serious vulnerability for your application!!
in consequence, PHP is hard to trust ... i mean, i personally dislike both Java and ASP.NET, but i have to admit, they are trusted plattforms and trusted for a reason ... now problems arousing from the messy API are being solved by some frameworks ... but if a language requires a framework to wrap the core API in order to have something usable, that is a base for good, maintainable code, then something is wrong ...
how exactly do i use zend guard or ioncube on an arbitrary shared webspace?
really, best thing you can do, is write commmercial plugins for widely spread PHP software, but it seems this is exactly the opposite of what Lusid wants to do ... but hoping to find a niche, that is big enough that you don't need signifficant marketing efforts to reach you customers, that is small enough that you don't get crushed by copycats, simple enough to build as a standalone app and fits a number of other criteria that are prequisites for a commercial success, seems a little naive to me ...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
As you probably know, Derek Sivers is the guy who created CD Baby and eventually sold it for some big bucks. He wrote it in PHP originally and then down the road set about rewriting it in Rails. His troubles are the stuff of legend:
7 reasons I switched back to PHP after 2 years on Rails
That article came out in 2007 but being newly infatuated with Rails, I'm wondering whether anything has changed to make Rails more of a wise bet in the meantime, or should I stick with my good old ugly PHP girlfriend?
Does anyone agree that Rails does not offer any significant advantages over PHP?
Austin Ziegler wrote an interesting response to that article:
On Derek Siver’s Return to PHP…
The gist of it is:
Derek chose the technology for the wrong reasons. He chose it partially
based on the hype of Rails, but he
envisioned it as a silver bullet that
would magically make his application
better just because it’s in Rails.
Rails didn’t fit Derek’s application model for CD Baby, and
Derek’s application model is more
important than the technology to be
used, since it represents a business
he understands well.
He ignored his existing experts for the new technology. Neither he nor his
employees knew Ruby aside, perhaps,
from playing around with it. This
wasn’t a technology that was deemed to
be appropriate from experience; this
was a technology deemed appropriate by
management (sorry Derek, you might
still be getting your hands dirty with
code, but you’re still management).
Derek approached the project as a whole-environment ground-up rewrite
with a One Big Day deployment, without
considering ways to phase it in over
time. It’s almost always possible to
find interface points where you can
replace one broken piece at a time.
Ultimately, this is what the Rails
folks wouldshould tell you anyway:
replace one area at a time, each with
a different codebase. Interface them
as REST-ful services. Don’t make them
depend on a single database schema.
Re-writing an existing site is almost always a bad idea. It's hard to put your heart into retreading an old wheel. I worked on a rewrite of a site from CGIs to a Java app server and saw several programmers quit because of it. For one, they preferred their old way of doing things and did not want to learn Java. Secondly, I believe they did not have the enthusiasm to re-write a ton of legacy code that they had been maintaining reluctantly to begin with. Far better to try Rails out on a new task and see how it fares. At least then you are putting it on an even footing with PHP in the psychological motivation sweepstakes.
I have experience with PHP & Ruby + Ruby on Rails (earned money using both, but not a lot).
The Ruby library is much better. PHP's library is a collection of functions in a global namespace with inconsistent names and argument order. strpos vs str_repeat. strpos's first argument is the big string and the second argument is the string to find. explode's first argument is the string to split by and the second argument is the big string. This was a big problem for me. I had to look up a lot of things when using PHP, but not when using Ruby. I can remember things because they're consistent. The names of the methods make argument order clear. Another: PHP's strlen($str) vs count($arr) while in Ruby it's just anything.length.
Ruby the language is better than PHP. It has closures, good OO, nice syntax (this is subjective, but you need a lot less punctuation in Ruby, and that's what I get wrong most often).
That's my experience. Try both and see what works for you.
The best answer will be the author's himself. He seems to make another comeback to RoR!:
Foreword
My former company (CD Baby) was one of
the first to loudly switch to Ruby on
Rails, and then even more loudly
switch back to PHP (Google me to read
about the drama). This book by Michael
Hartl came so highly recommended that
I had to try it, and Ruby on Rails
Tutorial is what I used to switch back
to Rails again.
http://railstutorial.org/book
And skimming his own site, indeed, proves his return to RoR:
Instead of trying to teach everyone my unique PHP framework, all
projects will standardize on Rails 3.
http://thoughts.pro/
The guys who changed from Rails to PHP just by following the renowned article of his, now it is your time to come back to Rails, again!
I read that post from Derek Silvers. There is something weird about it. He tells the tale of a project that got out of control, dragged on for months, and eventually had to be abandoned. He blames this on the Rails framework. Yet he never says what it was about Rails that caused the project to fail. The article would be far more credible if he offered some solid information, but he doesn't mention even one specific place where Rails let him down. The closest he comes is to say that their "needs" (?) clashed with Rails's preferences (which ones? How?)
Meanwhile, people all over the world (including myself) are implementing complex Web applications in reasonable amounts of time using Ruby on Rails.
Given the lack of detail, or really any specific technical information at all, in Derek's piece, it could easily be that the project failed for any number of reasons having nothing to do with Rails.
The original question was "should I heed Derek Silvers' warnings about migrating from PHP to Rails?" My answer would be no, his "warnings" amount to a vague anecdote with zero supporting evidence. It is perfectly safe to ignore them.
Should you reimplement a PHP app in Rails? That's another question. There is no blanket answer to that one. It depends entirely on circumstances.
Luke Crawford's recent post about Muxtape offers another perspective.
I spent my first 4 years as a web developer using PHP, and it was fun at the time, but as I began to realize how severely inefficient it was I started looking elsewhere. I’d abandoned my traditional computer science background for the web and its greater design possibilities, but because of this I knew there was a better way. PHP developers shouldn’t be ridiculed as much as they often are because, frankly, it enables people without a more rigorous background to accomplish amazingly technical things. This should satisfy nerds but usually is turned into some kind of weak ‘machismo’ thing instead. Anyways, this dissatisfaction began in late 2004 and Ruby on Rails was brand-new, stable, and addressed every limitation I’d confronted with my old homegrown PHP MVC framework. I’ve exclusively done Rails work ever since.
In any case, it would be hard to defend the categorical statement "Rails does not offer any significant advantages over PHP."
PHP is a great tool to solve certain problems. Rails is a great tool to solve certain problems.
As both an active Rails and PHP developer (with experience going back to 2000), I strongly disagree with the statement.
I maintain that Ruby offers significant advantages over PHP, and Rails is a better framework than anything in the PHP world. A lot of this has to do with the language itself - Ruby can do things that PHP just simply cannot. Once you grok the elegance of meta-programming, a whole new level of expressiveness opens up to you.
Disclaimer: I am by no means a Ruby or Rails expert.
As someone who's been in the industry for nigh on 15 years I see several warning signs that make me nervous about Ruby on Rails specifically. I'm going to ignore the language here because a language is a language. Ruby is a modern language with closures, exceptions, OO, etc. Some criticize it with regards to performance. These issues are largely irrelevant in that they don't impact real world performance (if it takes 300ms to download and display a Web page, who cares that the serverside codes takes 10, 20 or even 30ms to run?) and transitory in that they are fixed in later versions (as seems to be the case with Ruby 1.9).
Ruby on Rails is a closed, heavyweight stack. I mean this as an observation not an accusation. It is tightly integrated (including with Prototype) much like JBoss Seam in the Java world (being integrated tightly with JBoss/Hibernate and yes I know recent releases and articles have tackled the issue of using it with, say, Glassfish and another JPA provider)
This can be both a good thing and a bad thing. J2EE, for example, being a fairly open stack was the cause for much innovation in the software industry in the last decade as almost every piece of it (notably EJB) was replaced by different projects that could be slotted together. And of course it was, if not the birthplace for Spring, it was certainly the incubator.
On the other hand you have more closed stacks like .Net where their closed nature allows for rapid innovation, a model Microsoft has (generally) excelled at. In a few short years DirextX went from being a joke to completely trouncing OpenGL as a games development platform because any closed system can evolve that much faster than an open standards system. That's just how it works.
The other relevant point I'll mention is that in recent years there has been a move towards ORMs ("object-relational mapping") in Java, .Net and elsewhere and this is part of the impetus behind Rails. I've commented on this previously, for example "Using an ORM or plain SQL?" and I won't reiterate those points in their entirety.
As most of you would know there is a mismatch between the object and relational worlds that ORMs have sought to bridge. In the last year or two I've dealt with this mainly through Java (JPA specifically).
Now when you bridge between two things that don't match you end up with "leaky abstractions" (as Joel put it):
All non-trivial abstractions, to some
degree, are leaky.
Now what I'll add is this: there is an inverse relationship between the complexity of the abstraction and how leaky the abstraction is. Case in point: ibatis. Ibatis is an extremely lightweight yet powerful persistence framework for Java and one I'm a huge fan of. It wraps SQL in external files and on top of that puts many modern ORM behaviour, such as:
Lazy-loading of relationships;
Result mapping;
Grouping of results to multiple levels (something JPA can't do); and
Discriminated types (ie the type is determined the data).
I would estimate that ibatis has 90-95% of the functionality of Hibernate with the only complexity overhead being runtime bytecode enhancement for the lazy loading via cglib (JPA does it the same way) with the only downside that you have to write your own queries (and I don't consider that a serious downside but opnions will vary).
Compare that to a JPA provider that relies on instrumentation, load-time weaving and non-standard class loaders to implemennt that extra 5-10% functionality (and the abstraction is still leaky).
So there is a law of diminishing returns when it comes to making things less leaky. At some point you're better off investing in a bilge pump than you are in fixing every leak in the boat.
Bringing this back to Rails: the leaky abstraction argument is my biggest problem with the Rails philosophy.
What also rings alarm bells for me is the comments you get in posts like On Derek Siver’s Return to PHP… is:
"Derek chose the technology for the wrong reasons.": wait... isn't RoR either a general-purpose Web application framework or a pretty close facsimile? That being the case, why can't you do a site like CDbaby in it?
"Rails didn’t fit Derek’s application model for CD Baby": How so?
"He ignored his existing experts for the new technology.": wait... didn't he hire an expert?
"sorry Derek, you might still be getting your hands dirty with code, but you’re still management": I agree with the comment that this quote is "asinine" and will add that its misleading, irrelevant and arguably a strawman;
"Derek approached the project as a whole-environment ground-up rewrite with a One Big Day deployment": arguably not advisable but if you're willing to spend the time and money on it, I don't see it as a reason why you can't do the site in RoR.
Now 5-7 years ago when EJB was hyped up you got criticisms of it based on lots of things and you'd get stalwart defenders arguing:
"Application X didn't fit the EJB model";
"They didn't understand how EJB works";
"EJB is not for all applications" (they'd rather concede defeat on this one than face the more glaring issue that it's not really appropriate let alone a good idea for, well, just about anything);
etc.
So the anti-Ruby posts (and especially their rebuttals) all sound very familiar to me.
It's worth mentioning the year old rant "Rails is a Ghetto" by Zed Shaw, which is a 6000 odd word rant ("conflagration" is probably a better word) against Rails. Some notable quotes:
This is exactly what makes Rails a
ghetto. A bunch of half-trained former
PHP morons who never bother to sit
down and really learn the computer
science they were too good to study in
college.
and
Notice how it took me a few seconds to
reply. This one single statement
basically means that we all got duped.
The main Rails application that DHH
created required restarting _400
times/day. That’s a production
application that can’t stay up for
more than 4 minutes on average.
and (on memory leaks):
That’s one more reason Rails is ghetto
as hell. Important patches like the
above go largely ignored by the
Japanese developers, and while they
are very nice guys, the above just
smacks of amateur hour.
and
The best part about the whole thing is
there’s potentially 10 new web
frameworks that can take on Rails.
Hell, Mongrel spawned or helped 5 of
those. My favorite of those frameworks
is Merb which is literally “Mongrel
plus Erb” but now it uses Erubis
mostly. What I love about Merb is that
it proved you could make a fast thread
safe Ruby web framework with all the
same ideas as Rails and using most of
the Rails gear at the same time.
However, the joke is that before Merb
the Rails Core morons would scream up
and down you can’t make Rails thread
safe. Ezra however proved them all
wrong by just writing a better Rails
than Rails and all thanks to Mongrel
being so easy to hack and work with.
and:
Ruby on Rails has become full of
people like Koz, with Koz the most
senior of the wannabe smarties. Koz
got lucky at best and injected his
shitty coding into a good project,
messed it up, and then latched on to
security as the way to get more
control. Of course he doesn’t actually
know anything about secure coding
which is why his code seems to have
lots of the bugs (go check out the
date parsing shit. Clue: months don’t
always have 30 days).
And, well it goes on.
So I guess I can sum it up this way: Rails smells bad.
Rails is a good framework, but sometimes migrations are bad ideas.
I prefer to start from scratch, you can't be "translating" PHP code into the Rails context. It just can't be done, mostly because of the Ruby language itself and the MVC pattern.
I'd rewrite it in Rails, but if you love PHP, go with PHP. Don't care about what other people say, do whatever suits you.
In business, time is money - and sometimes you have to go the path of least resistance. No environment, language, framework, etc. is perfect. Learn and use what you want to and keep it movin' homeboys!!!!
I've been a PHP developer for many years now, with many tools under my belt; tools that I've either developed myself, or free-to-use solutions that I have learned to trust.
I looked into CodeIgniter recently, and discovered that they have many classes and helper routines to aid with development, yet saw nothing in the examples that I couldn't do just as easily with my own tools. Simple things like DB abstractions, Email helpers, etc. There was some interesting code relating to routes - mapping urls to the right controllers; but even that's not particularly difficult to code yourself if you've ever written an MVC style web app with pretty urls.
Even after looking through some of the other popular frameworks, I still see nothing that would be that much of a time-saver. Even looking at the forums, I see people struggling to get the tools to work for them. I do understand how they would be more useful for junior developers, since full system design skills take a while to understand and appreciate fully.
Yet, I'm often told that I should use an off-the-shelf framework to produce my solutions, but I still remain unconvinced. What's the real benefit to someone like myself? Am I just being elitist, or is this a common opinion?
Edit: Looking at some of the answers here, should I perhaps consider packaging up my toolset as its very own framework, writing some documentation and posting tutorials? If I'm hesitant to take on other's frameworks, would opening it up and getting more eyes on it help to improve my own skills/tools?
Frameworks have several advantages:
You don't have to write everything. In your case, this is less of a help because you have your own framework which you have accumulated over the years.
Frameworks provide standardized and tested ways of doing things. The more users there are of a given framework, the more edge cases that have been encountered and coded for. Your own code may, or may not, be battle hardened in the same way.
Others can be recruited onto a project with a standard framework and have access to the documentation, examples and experience with that framework. Your own snippets may or may not be fully documented or have examples of use... but isn't much chance that others are comfortable with them initially.
EDIT:
With regards to your idea of packaging up your own framework, the benefit of cleaning it up for public consumption can be larger than the benefit of getting others to use it.
The reason is simple: you will have to re-evaluate your assumptions about each component, how they fit together and how clear each piece is to understand. Once you publish your framework, your success will be strongly dependent on how easy it is to get up and running with.
Big wins with little effort are essential for adoption (those wins will encourage people to delve further into the framework). Ruby on Rails in an example of a framework that gives such big wins with little effort, and then has hidden layers of features that would have overwhelmed someone just getting started. (The question of the quality of RoR apps is not the point, the point is about adoption speed).
After people adopt a framework, it is about the ease of continued use. Little details like consistent parameter use patterns make all the difference here. If one class has many parameters on every method, while another has setters that are expected to be called before invoking methods, you will lose users because they can't get a "feel" for what is expected in a given case without resorting to the documents.
If both ease-of-adoption and ease-of-living-with issues are addressed properly, you only have to get lucky for people to adopt your framework. If those issues are not addressed properly, even an initial interest in the framework will wane quickly. The reason is that there are many frameworks: you will need to stand out to gain the advantages of having others using your kit (as they rightfully are as wary of your framework as you are of others).
Here's another reason not to create your own framework. Linus' Law - "Given enough eyeballs, all bugs are shallow". In other words, the more people who use a given framework, the more solid and bug-free it is likely to be.
Have you seen how many web frameworks there are for Java? Back in the day, it was fashionable for any half-decent developer/architect to write their own custom web framework. And at the end of the day, 95% of them looked like a custom implementation of Struts (the most popular Java web framework at the time). So they basically created a Struts clone that was: 1) proprietary; and 2) not as well documented and tested.
Let's face it - writing our own customer framework is fun, but what happens next? It becomes a maintenance burden to keep up with the framework yourself (or the poor soul who replaces you). And maintaining software is much, much more costly, especially when it comes to custom frameworks. Is the company in business to solve domain problems or in the business of maintaining frameworks?
I forget who said it, but I once heard a great quote - "The first rule to creating your own framework is: don't". Somebody else has probably gone through the effort of doing so and probably done the same work you would have done. Save yourself the time, effort, and testing.
There's many comments here as to the advantages of using a framework, and certainly I think in a good many cases they are perfectly correct.
HOWEVER
All frameworks come with the downside that they have a domain of problems that can be fitted into them. If your problem is well inside the scope of the domain then using a framework isn't an issue, and most of the time it's readily apparent if your problem is well outside the domain so you don't give it a thought. Issues arise when you try to force a problem into a framework that it just doesn't quite fit into or has some unusual non-standard feature - in which case you complete 90% of the code really fast then spend all the time you've saved figuring out how to bend or extend the framework so it can accomplish some obscure requirement. Because in these case your solution/extension has to plug into the framework it can often be more difficult to code than if you'd come to it independently.
In the wrong circumstances this can actually be disastrous. For example if a client asks for a project that you believe will fit into a framework solution and you quote accordingly, then after completing 90% you find the gotcha then you can be really up the creek, especially if it's some feature that the client is insistent upon (and it always is). These issues tend to arise because it is not always apparent from the word go where the gotchas might lie, particularly if you're using a framework you are less familiar with (and you have to from time to time).
This is really the same problem as arises with deploying any third party software in a project. Myself from experience I have no qualms about using frameworks or similar, but given the choice I will always go for the lightest, thinnest, wrapper I can find that will do what I need. That way I gain the advantages, whilst knowing that if issues do arise (and they are generally less likely to with a thinner wrapper) then figuring out how to work around them is likely to be simpler than learning an extensive code-base to the point where I can safely modify it.
The framework code is likely to be well-tested and relatively free of bugs. By using it you save yourself time testing/maintaining your own code to do the same thing.
And any time saved is good. Laziness pays off in programming.
One thing that you will be missing out on is all of the Validation that goes into a popular framework.
Your routines simply don't have the same exposure that the popular libraries have.
You may have a point.... however I wouldn't underestimate the power of many, as an example phpBB is as far as i'm concerned the bb solution to use. Why? Because there are many, many thousands of posts on their support boards and many people using it who are knowledgeable and can help people solve problems.
Therefore the only reason in your case to use a popular framework is the many others that use it, report bugs against it, fix it and support it. It'll be tricky to get the same coverage on your own libraries.
I would go against the grain here, and say, you should use your own custom framework, If the software you are building is the core of your business. As Joel would say, "Find the dependencies - and eliminate them". If you are just putting up a little website for your company, and you business isn't maintaining websites, then go ahead and use a framework. But when that website is your business, then you shouldn't depend on a framework from somebody else to let you get the job done.
I think the main reason is that when you use a common framework, there are a lot of people who are instantly familiar with your product.
Apart from that I think it's most important that whatever tools you use actually get the job done. If it happens to be familiar to other people, then that's a bonus.
I agree you should use your own custom framework. Not only is it easier for you to understand, but it provides the ultimate in job security!
Three reasons I can think of immediately:
A well-known framework will be familiar to other developers who may have to work on your project
A well-known framework will have resources like books, discussion boards, and other experts that can be used for finding out more information
Managers will often have a "don't reinvent the wheel" philosophy. In fact, existing solutions have probably solved the same problems that you'd discover if you create your own solution.
All of that said, there may still be a place for your own solutions. We wouldn't have so many frameworks (or scripting languages) to choose from if no one started something new.
Any experienced developer can build a framework -- the challenging part is convincing others that it's worth using. You'll need to create documentation and tutorials for it for those who plan to use or maintain it. You'll probably need to create a demo site to prove that its useful and actually works like it's supposed to.
That alone can be a considerable investment, not including bugs that could pop up in between. When its all said it done, it could be worth spending time learning another framework instead of making your own.
You mentioned CodeIgniter -- I personally feel like that's a pretty framework -- it doesn't get much more barebones than that.
What you essentially have is your own framework. So, it isn't a time-saver FOR YOU, because you have already spent the time to develop the framework. If you didn't have that to build from, it would certainly be easier and faster to use an existing framework than to roll your own.
What you need to look at is whether or not your framework is better than other options out there, and whether your familiarity with your own code outweighs having other eyes looking at it, and other people using it in enough different ways that the likelihood of any problems being found and corrected is much higher.
Also, if your framework is so much better than everyone elses', you might consider opening yours up to the community ;)
As you probably know: "time is money". So by using a popular framework with a lot of helpers, a lot of code examples on web and a big community you do more in less time.
Sometimes it if ok to use frameworks because you become more productive, but in some advanced and difficult projects it may happen so that the framework stays in your way and you have to find workarounds.
I think there is no definitive answer. You should put in balance the pros and cons and take the right decision for your project.
Usually I adopt popular frameworks very fast but not in critical parts of the projects and in time I extend their usage.
I think that if you don't see a need to use a framework then don't.
The reason I use a framework for example Django for python or Rails for Ruby or Webforms and MVC for ASP.net is because they make it easier and faster to write applications for them. In the case of Ruby and Python not using a framework for me would make me go crazy.
If you have something that works and don't see a need to use a framework I would say stick with what you feel is best. But, I would still keep up to date with frameworks.
I think they are more useful if you are starting from scratch and don't have the time to write your own. If you already have a codebase you developed over the years, they may be much less useful, but it may still be useful to take a look and see what they did.
For example, I am sure major game development shops are not using third-party tools, engines and frameworks, not because they are not sufficient, but they already have built their own since the 80's or whatever.
Plus, if you are using an off-the-shelf component, there is no way to exceed it in its particular area. If you need to be a market leader in a particular dimension, you should be building your own solution in that dimension, so you can lead. If you don't need this capability, using a third-party component that is just as good as yours may be a good solution as long as it is an easy transition. Time to train in the new tool and living with its idiosyncrasies may or may not be worth it though.
The other thing to consider is that if you can build something, you truly understand it. Otherwise, you don't. Now, you don't need to fully understand stuff to use them, so long as they "just work", but we all know how that goes... :)
Can you solve the problems you are given have with your code faster and more reliably than public frameworks?
If yes, then keep using your own.
If no, then find the framework that does a better job and run with it for that project.
It all comes down to which codebase gets the job done better(for the value of better given by the client. ;) )
Disadvantages.
Most frame works are not object orientated. (code igniter does show some promiss)
Most of the code is done via includes. trying to track down the problem is like pulling on a thread on a sweater, and having to unravel the entire garment to fully understand the creation.
Most frame works have poorly written documentation.
Most frame works try to do many many many things.
I find from my experience developing with frame works that it takes a good 3-6 months to get on top of the code base. And its only after that period of time that you will find out weather you are trying to fit a square peg into a round hole. Given that most php projects want to be finished before that period has elapsed, it will cost employers more to get any project using a big "frame work" to fruition.
Many of the php Frame works were written for php 4, and were written in a different enviroment. They have been extended greatly, but are showing their origins. The use of global constraints is particularly prevalent. I am hoping that php 6 puts most of them to death. Code igniter escapes most of this, but it is new, and has object orientated parts.
Some frame works have written code that is not needed, and causes problems.. eg: CAKE has a most excellent model view controller, but its session handling is a disaster. Unfortunately frame works are not written in a modular way. Often its an all or nothing option.
MOst programers "hack" the frame work to get it to do what they want. This leaves future programers sractching their heads. It also makes "upgrading" the frame work a impossibility.
I have yet to see a frame work that implements unit testing. (how do you know that you have not broken it).
give me a well written object any time. At least them you know the scope right off the bat.
Advantages are that it's already written and tested by multiple people therefore less likely to be bug prone.
Disadvantages are that it's not built specifically for your application and therefore will most likely perform worse.
All in all, I can't really see much reason to use one considering you already have your own...although it may be worth releasing that open source so others are able to bug check and recommend improvements.