Going Back to PHP(pathdependent.com)
pathdependent.com
Going Back to PHP
http://pathdependent.com/2009/10/26/going-back-to-php/
16 comments
> Do serious PHP developers use PHP's built-in template language?
No. However, my template engine compiles to PHP's built-in template language.
> In exchange for not having to understand abstraction or OO
My PHP code is just as object-oriented as my C++, Java, or C# code. As for the functions, you memorize what you need and have a good IDE for the rest. One of the benefits of PHP is that there's a function for just about every common task and using them is really easy. Other languages may have the same functionality in a library, but the setup and calling is far more complicated.
PHP is a get-things-done language and it always has been. You can dick around with all the abstractions, frameworks, and meta-programming you want but often that's just more complicated and a waste of time.
No. However, my template engine compiles to PHP's built-in template language.
> In exchange for not having to understand abstraction or OO
My PHP code is just as object-oriented as my C++, Java, or C# code. As for the functions, you memorize what you need and have a good IDE for the rest. One of the benefits of PHP is that there's a function for just about every common task and using them is really easy. Other languages may have the same functionality in a library, but the setup and calling is far more complicated.
PHP is a get-things-done language and it always has been. You can dick around with all the abstractions, frameworks, and meta-programming you want but often that's just more complicated and a waste of time.
> my template engine compiles to PHP's built-in template language
No, PHP is a template language... just a very complete one.
> PHP is a get-things-done language and it always has been
No, PHP is more of a spaghetti language. Sure, it's easy to get something working. Make a tweak here, a bug fix there. If you need a quick knock off, just copy the files, copy and paste a bit, and you're good to go.
But after going through that a few dozen times, you quickly end up with a tangled mess of spaghetti code. Speaking as someone who wrote and had to fix plenty of code (from myself and others) like that, it's not something that I'd like to do. PHP makes it very easy to get trapped like this.
Like any language, it is possible to write good, well abstracted code. Unlike others though, PHP makes is very easy to write bad code. I don't know why... perhaps it's that the learning curve is _too_ low.
The newer versions are definitely trying to elevate the language, but I think that ship has already sailed.
No, PHP is a template language... just a very complete one.
> PHP is a get-things-done language and it always has been
No, PHP is more of a spaghetti language. Sure, it's easy to get something working. Make a tweak here, a bug fix there. If you need a quick knock off, just copy the files, copy and paste a bit, and you're good to go.
But after going through that a few dozen times, you quickly end up with a tangled mess of spaghetti code. Speaking as someone who wrote and had to fix plenty of code (from myself and others) like that, it's not something that I'd like to do. PHP makes it very easy to get trapped like this.
Like any language, it is possible to write good, well abstracted code. Unlike others though, PHP makes is very easy to write bad code. I don't know why... perhaps it's that the learning curve is _too_ low.
The newer versions are definitely trying to elevate the language, but I think that ship has already sailed.
> If you need a quick knock off, just copy the files, copy and paste a bit, and you're good to go.
That's a style of programming, it really has nothing to do with the language. I can cut'n'paste code in any language and I can write nicely abstracted modular code in PHP. Why are you confusing the two?
> PHP makes it very easy to get trapped like this.
Really? Why is that? What is so different about PHP than every other language in existence? You don't even know, do you?
> Unlike others though, PHP makes is very easy to write bad code. I don't know why... perhaps it's that the learning curve is _too_ low.
I'm not sure how the learning curve would have anything to do with it. If you already know how to program well, PHP isn't going to break your legs. You're not suddenly going to stop doing good design because of a few dollar signs, are you?
That's a style of programming, it really has nothing to do with the language. I can cut'n'paste code in any language and I can write nicely abstracted modular code in PHP. Why are you confusing the two?
> PHP makes it very easy to get trapped like this.
Really? Why is that? What is so different about PHP than every other language in existence? You don't even know, do you?
> Unlike others though, PHP makes is very easy to write bad code. I don't know why... perhaps it's that the learning curve is _too_ low.
I'm not sure how the learning curve would have anything to do with it. If you already know how to program well, PHP isn't going to break your legs. You're not suddenly going to stop doing good design because of a few dollar signs, are you?
The dollar signs are not the problem with PHP's variables. Their global scope is.
But anyway, well-abstracted PHP ends up looking like Java -- very verbose. Quick example; if you want to pass around a callback that has state, you have to make it a class, since there are no closures (instances of classes and closures are about equivalent). This is, however, a lot of typing to do something simple. Instead of a quick one-liner, you now have a new file and a new class, or, at the very least, an interface and anonymous class. Messy.
You can't abstract away that pattern, either, as there is no MOP (to auto-generate the classes as needed), or macros (to at least type in the code for you automatically).
Anyway, something that's just a few characters in other languages is now multiple files. Sure, it's well-abstracted and pretty easy to understand. But it's also massively over-engineered, and distracts from the task that you were actually trying to accomplish.
If you are going to write PHP code that looks exactly like Java, why not just use Java and get your 70x speed boost?
But anyway, well-abstracted PHP ends up looking like Java -- very verbose. Quick example; if you want to pass around a callback that has state, you have to make it a class, since there are no closures (instances of classes and closures are about equivalent). This is, however, a lot of typing to do something simple. Instead of a quick one-liner, you now have a new file and a new class, or, at the very least, an interface and anonymous class. Messy.
You can't abstract away that pattern, either, as there is no MOP (to auto-generate the classes as needed), or macros (to at least type in the code for you automatically).
Anyway, something that's just a few characters in other languages is now multiple files. Sure, it's well-abstracted and pretty easy to understand. But it's also massively over-engineered, and distracts from the task that you were actually trying to accomplish.
If you are going to write PHP code that looks exactly like Java, why not just use Java and get your 70x speed boost?
> The dollar signs are not the problem with PHP's variables. Their global scope is.
I think you sort of have that backwards, all variables in PHP are local unless you go out of your way to make them global (or just start typing into an empty file without any functions). I pretty much surrender the global scope. None of my variables are global except for static class members. I don't have any global functions, except static class methods.
> Quick example; if you want to pass around a callback that has state
I don't pass around callbacks that have state very often. I tune my programming style to the language that I'm working on. Often there are different ways of handling the situation in PHP -- it's is actually quite dynamic in places. I prefer to keep my pages pretty KISS anyway -- I can do hell of a lot (see my other replies) without needing stateful callbacks.
> If you are going to write PHP code that looks exactly like Java, why not just use Java and get your 70x speed boost?
I don't know, why are Java sites so painfully slow and all PHP sites so fast?
I think you sort of have that backwards, all variables in PHP are local unless you go out of your way to make them global (or just start typing into an empty file without any functions). I pretty much surrender the global scope. None of my variables are global except for static class members. I don't have any global functions, except static class methods.
> Quick example; if you want to pass around a callback that has state
I don't pass around callbacks that have state very often. I tune my programming style to the language that I'm working on. Often there are different ways of handling the situation in PHP -- it's is actually quite dynamic in places. I prefer to keep my pages pretty KISS anyway -- I can do hell of a lot (see my other replies) without needing stateful callbacks.
> If you are going to write PHP code that looks exactly like Java, why not just use Java and get your 70x speed boost?
I don't know, why are Java sites so painfully slow and all PHP sites so fast?
You can dick around with all the abstractions, frameworks, and meta-programming you want but often that's just more complicated and a waste of time.
PHP is itself an abstraction. CPU instructions don't generate HTML, after all...
It is interesting that you assume PHP is the perfect level of abstraction. I think that is called "blub". You should try deeper abstractions some time.
Today I wrote a complicated database query joining by saying "$securities_rs->find({ security => 'USD', month => DateTime->new( year => 2009, month => 1 )})->messages->users->count" to see how many users looked up data on the USD for 2009/1. It is one SQL query, and there is no speed hit for writing it this way. A bit of abstraction made my app infinitely flexible; any query I can imagine is just a line of Perl. Abstraction is good.
Don't think that pounding on your keys as fast as possible makes your productive -- it doesn't. Thinking about your application's needs and designing your code to be easily tweaked to fit those needs is what you really want to do. When you have a mess of SQL, HTML, and PHP all in one file, you are stuck with what you wrote forever. When you abstract things, big changes only involve a small amount of code.
PHP is itself an abstraction. CPU instructions don't generate HTML, after all...
It is interesting that you assume PHP is the perfect level of abstraction. I think that is called "blub". You should try deeper abstractions some time.
Today I wrote a complicated database query joining by saying "$securities_rs->find({ security => 'USD', month => DateTime->new( year => 2009, month => 1 )})->messages->users->count" to see how many users looked up data on the USD for 2009/1. It is one SQL query, and there is no speed hit for writing it this way. A bit of abstraction made my app infinitely flexible; any query I can imagine is just a line of Perl. Abstraction is good.
Don't think that pounding on your keys as fast as possible makes your productive -- it doesn't. Thinking about your application's needs and designing your code to be easily tweaked to fit those needs is what you really want to do. When you have a mess of SQL, HTML, and PHP all in one file, you are stuck with what you wrote forever. When you abstract things, big changes only involve a small amount of code.
> It is interesting that you assume PHP is the perfect level of abstraction.
It's interesting you assume I said that, but I did not. In PHP you can have all kinds of levels of abstraction (and I use a multitude of levels). It is just as interesting that you assume most levels of abstraction are not possible.
If you call that a complicated a database query, we're clearly working at different levels. Get back to me when you hit 100 lines of SQL.
> I think that is called "blub". You should try deeper abstractions some time... Don't think that pounding on your keys as fast as possible makes your productive -- it doesn't.
The self-righteousness and ignorance here is absolutely astounding.
It's interesting you assume I said that, but I did not. In PHP you can have all kinds of levels of abstraction (and I use a multitude of levels). It is just as interesting that you assume most levels of abstraction are not possible.
If you call that a complicated a database query, we're clearly working at different levels. Get back to me when you hit 100 lines of SQL.
> I think that is called "blub". You should try deeper abstractions some time... Don't think that pounding on your keys as fast as possible makes your productive -- it doesn't.
The self-righteousness and ignorance here is absolutely astounding.
It's interesting you assume I said that, but I did not. In PHP you can have all kinds of levels of abstraction (and I use a multitude of levels). It is just as interesting that you assume most levels of abstraction are not possible.
Your initial post called this "a waste of time". That is why I assumed you didn't do it. If you do do it and think it's a waste of time, you are probably doing it wrong, as the rest of the programming community disagrees with you.
Also, you have 100 line SQL statements embedded in your PHP programs? That is the wrong level of abstraction.
The point of my abstraction is that a quick one-liner is the same mental complexity as your supposed 100-line statement. The idea is that most of the complexity is abstracted away by specific names. You compose the specific names into something that ends up being physically complex, but mentally simple as you are reading your code.
Anyway, probably not worth arguing with you, since you are quick to make personal attacks, aren't consistent with your own ideals, and won't discuss anything specific. (Well, I guess you will discuss how many lines of code something is.)
Your initial post called this "a waste of time". That is why I assumed you didn't do it. If you do do it and think it's a waste of time, you are probably doing it wrong, as the rest of the programming community disagrees with you.
Also, you have 100 line SQL statements embedded in your PHP programs? That is the wrong level of abstraction.
The point of my abstraction is that a quick one-liner is the same mental complexity as your supposed 100-line statement. The idea is that most of the complexity is abstracted away by specific names. You compose the specific names into something that ends up being physically complex, but mentally simple as you are reading your code.
Anyway, probably not worth arguing with you, since you are quick to make personal attacks, aren't consistent with your own ideals, and won't discuss anything specific. (Well, I guess you will discuss how many lines of code something is.)
Fair enough. I suppose I do try and keep it KISS and that does often require abstractions and even the occasional meta-programming. But in most cases, KISS principles are best achieved by using the most minimal abstraction that does what you need.
> Also, you have 100 line SQL statements embedded in your PHP programs? That is the wrong level of abstraction.
If you need to calculate payroll against a schedule of appointments consisting of elements that need to be calculated as a flat fee, percentage, or sliding scale of appointments and you need to return results in real-time than it's the right level of abstraction. And when you actually need to mix in values, constants, and even function calls from the software into that SQL statement, you need something very different from your example.
"The point of my abstraction is that a quick one-liner is the same mental complexity as your supposed 100-line statement."
The same technology that allows you to make quick one-liners of moderate SQL statements would balloon my 100-line statement into a 200 monstrosity that would be impossible to follow. There are trade-offs with abstractions. Look at Rails, absolutely great for certain types of projects but when you need to do something outside of the box it gets very complicated to work with.
"Anyway, probably not worth arguing with you, since you are quick to make personal attacks"
You're the one making a lot of assumptions about "PHP programmers" that I could take offense with. I really don't think pounding my keys really fast makes me productive. Or that my HTML, PHP, and SQL is all in one file. Or the countless other things that you've said. Really, if I was black would you think I talked all gangsta too?
> and won't discuss anything specific.
I was just very specific, enjoy.
> Also, you have 100 line SQL statements embedded in your PHP programs? That is the wrong level of abstraction.
If you need to calculate payroll against a schedule of appointments consisting of elements that need to be calculated as a flat fee, percentage, or sliding scale of appointments and you need to return results in real-time than it's the right level of abstraction. And when you actually need to mix in values, constants, and even function calls from the software into that SQL statement, you need something very different from your example.
"The point of my abstraction is that a quick one-liner is the same mental complexity as your supposed 100-line statement."
The same technology that allows you to make quick one-liners of moderate SQL statements would balloon my 100-line statement into a 200 monstrosity that would be impossible to follow. There are trade-offs with abstractions. Look at Rails, absolutely great for certain types of projects but when you need to do something outside of the box it gets very complicated to work with.
"Anyway, probably not worth arguing with you, since you are quick to make personal attacks"
You're the one making a lot of assumptions about "PHP programmers" that I could take offense with. I really don't think pounding my keys really fast makes me productive. Or that my HTML, PHP, and SQL is all in one file. Or the countless other things that you've said. Really, if I was black would you think I talked all gangsta too?
> and won't discuss anything specific.
I was just very specific, enjoy.
So I've been voted down for having an opinion -- way to be open minded hacker news.
I think your close minded attitude ("I don't want to learn anything outside of my comfort zone, as it isn't clear whether it will get me from point A to point B") and vulgarity ("dick around") is what got you the down votes.
Given that I already stated a wide range of skills beyond PHP (and I use more languages than I even listed there) I hardly think my closed minded attitude is the problem.
There are a lot of complaints about PHP from people who've never even used it. They have bullet-point list of features lacking or strangeness and think they can make an informed comment. But I have built several large scale projects in PHP and at the time I started them most everyone's pet language here was too immature in the web space to consider. Look at Ruby, the tools of choice for deploying it and serving it up are constantly changing. I don't have time for that fire and motion. Maybe for the next project I will choose something else. But I think developers here would rather fawn over the pet language of the week than hear from someone using PHP effectively.
There are a lot of complaints about PHP from people who've never even used it. They have bullet-point list of features lacking or strangeness and think they can make an informed comment. But I have built several large scale projects in PHP and at the time I started them most everyone's pet language here was too immature in the web space to consider. Look at Ruby, the tools of choice for deploying it and serving it up are constantly changing. I don't have time for that fire and motion. Maybe for the next project I will choose something else. But I think developers here would rather fawn over the pet language of the week than hear from someone using PHP effectively.
Let me say that I have used PHP extensively, and found it to be incredibly painful. It basically allows the expressiveness of C with classes. It is possible to write working applications like this, but that's about all I can say. Given the choice, I would pick absolutely any other language. Even a tiny bit more expressiveness makes me happier and more productive.
The only reason I can see for picking PHP for one's own internal applications is ignorance. Any language is better.
The only reason I can see for picking PHP for one's own internal applications is ignorance. Any language is better.
When I started my last big project it was several years ago and PHP5 had just been released. I had been doing PHP for many years before that (since PHP3 -- moved from Perl to ASP to PHP). At the same time I've been doing desktop and mobile development in C++, VB, and C#. I also keep up with Python and other tools to see how things are progressing.
So I needed to start up a new project those years ago and it really wasn't the best time to learn another language. Ruby and Python were still a bit lame in the web space at that time. I'm not even sure Rails was out at the time; and if it was it was really new. I definitely didn't need to start a massive project on something that was very much untested. Performance and stability are also factors.
You are entitled to your opinion, but I don't find PHP to be all that painful. I've built up a large body of code and, more specifically, a coding style that makes PHP as productive to me as most other languages. For example, all my objects inherit from a root Object class that provides automatic properties: declare a method as setFoo and you use $object->foo = 'hello' to call it. My framework library is very modular and uses the autoload facility. I have a template library that is like smarty only less weird (and much less code). I have a few different database abstractions for different needs. Entity objects that can be loaded and saved. Classes for quick inline queries (similar to what you've used in other examples). An an abstraction for larger more complex SQL queries. In addition to basic templating for the UI, I also have something akin to ASP.NET user controls so I can built up complex forms just by adding tags to the template. The UI is connected end-to-end with the database so load, save, and validation is automatically generated (including client-side javascript) from a description of the data. I can push about a CRUD page in minutes.
So really, I have lots of reasons besides ignorance to stick with PHP at this point. Now, if I had to start the project again now, I'd have re-evaluate all my options but it would have to weighted against the body of code and knowledge I already have. I won't claim that PHP is better than any other language -- but it's really not as bad as you make it out to be. Just look at all the things that are possible in it!
So I needed to start up a new project those years ago and it really wasn't the best time to learn another language. Ruby and Python were still a bit lame in the web space at that time. I'm not even sure Rails was out at the time; and if it was it was really new. I definitely didn't need to start a massive project on something that was very much untested. Performance and stability are also factors.
You are entitled to your opinion, but I don't find PHP to be all that painful. I've built up a large body of code and, more specifically, a coding style that makes PHP as productive to me as most other languages. For example, all my objects inherit from a root Object class that provides automatic properties: declare a method as setFoo and you use $object->foo = 'hello' to call it. My framework library is very modular and uses the autoload facility. I have a template library that is like smarty only less weird (and much less code). I have a few different database abstractions for different needs. Entity objects that can be loaded and saved. Classes for quick inline queries (similar to what you've used in other examples). An an abstraction for larger more complex SQL queries. In addition to basic templating for the UI, I also have something akin to ASP.NET user controls so I can built up complex forms just by adding tags to the template. The UI is connected end-to-end with the database so load, save, and validation is automatically generated (including client-side javascript) from a description of the data. I can push about a CRUD page in minutes.
So really, I have lots of reasons besides ignorance to stick with PHP at this point. Now, if I had to start the project again now, I'd have re-evaluate all my options but it would have to weighted against the body of code and knowledge I already have. I won't claim that PHP is better than any other language -- but it's really not as bad as you make it out to be. Just look at all the things that are possible in it!
> "PHP shows that people would rather understand the exact details of arguments to a function instead of..."
I disagree. While yes, the function names and parameters are not always consistent and easy to remember, the point is they don't have to be, because it takes very little time to type "php.net/thefunctionorclosetoit" into a browser and quickly reference whatever you need.
Add a smart IDE that gives parameter hinting into the mix and you don't even need to do that most of the time.
I disagree. While yes, the function names and parameters are not always consistent and easy to remember, the point is they don't have to be, because it takes very little time to type "php.net/thefunctionorclosetoit" into a browser and quickly reference whatever you need.
Add a smart IDE that gives parameter hinting into the mix and you don't even need to do that most of the time.
While php.net is a great reference tool, jrockway opinion still stands. By using PHP, the developer is missing out many abstraction patterns that make life easier.
What abstractions patterns would the average PHP developer missing out on? You can throw a rock in any direction and hit a PHP framework. Throw a second rock and you'll get one with an entirely different philosophy.
Yes, PHP is a simple language but in many ways that's a virtue not a curse. Jrockway is right about PHP's inconsistency but that doesn't exclude one from building solid software in the language.
Yes, PHP is a simple language but in many ways that's a virtue not a curse. Jrockway is right about PHP's inconsistency but that doesn't exclude one from building solid software in the language.
Closures, namespaces, objects, mixins, meta-programming, etc.
Yes I realize PHP has made strides in some of those areas, but its mostly too little too late.
Yes I realize PHP has made strides in some of those areas, but its mostly too little too late.
Mixins can be as double-edged as operator overloading. Doesn't mean I don't love me some operator overloading in C# when the mood strikes, but neither are features that in anyway approach KISS principles nor are they essential.
As for everything else, PHP can hang. I actually particularly like their implementation of closures. I know people fretted about NS but that is all much ado about nothing. Millions of keystrokes wasted complaining about which single keystroke is used as a NS delimiter.
If you must do some PHP and you've come from Python, Ruby, Scala, etc, do check out the Flow3 framework. You'll feel closest to home.
As for everything else, PHP can hang. I actually particularly like their implementation of closures. I know people fretted about NS but that is all much ado about nothing. Millions of keystrokes wasted complaining about which single keystroke is used as a NS delimiter.
If you must do some PHP and you've come from Python, Ruby, Scala, etc, do check out the Flow3 framework. You'll feel closest to home.
None of those features are necessary (or even desirable) for building large scale software. Very few languages have that full set including C++, C, and Java.
First, C++ has MI (which can be used as mixins, although they also give you enough power to shoot yourself in the foot if you so choose) and namespaces. Namespaces and mixins are vital for building large scale software projects. C++ also allows generic programming (via templates).
Java has interfaces and namespaces. Both C++ and Java have static typing, which is a tool for building certain kinds of large scale software projects (dynamic typing -- combined with an actual type system -- as in Python, Ruby or Lisp -- is another tool).
Lastly, Java (as well as PHP) are garbage collector. C and C++ don't -- yet many large scale software projects were created without a garbagage collector. Does this mean that you don't gain a lot of power from a garbage collector?
C++ and Java are not examples of powerful programming languages either. You don't use them because they're the most powerful and elegant programming languages. Typically, they're used out of HR considerations ("it's easy to hire Java programmers"), performance requirements (C++ is fast; properly tuned JVM can be at most 10% behind C for applications which don't require a large heap) or libraries (although availability of other languages on the JVM overrules that argument as well in many cases).
Hate to be blunt, but you're speaking as a Blub Programmer. Sure, you can get things done in PHP (or in Java, or in C++) but there are languages out there with a greater amount of power that you willingly neglect. That's sad.
Java has interfaces and namespaces. Both C++ and Java have static typing, which is a tool for building certain kinds of large scale software projects (dynamic typing -- combined with an actual type system -- as in Python, Ruby or Lisp -- is another tool).
Lastly, Java (as well as PHP) are garbage collector. C and C++ don't -- yet many large scale software projects were created without a garbagage collector. Does this mean that you don't gain a lot of power from a garbage collector?
C++ and Java are not examples of powerful programming languages either. You don't use them because they're the most powerful and elegant programming languages. Typically, they're used out of HR considerations ("it's easy to hire Java programmers"), performance requirements (C++ is fast; properly tuned JVM can be at most 10% behind C for applications which don't require a large heap) or libraries (although availability of other languages on the JVM overrules that argument as well in many cases).
Hate to be blunt, but you're speaking as a Blub Programmer. Sure, you can get things done in PHP (or in Java, or in C++) but there are languages out there with a greater amount of power that you willingly neglect. That's sad.
> C++ and Java are not examples of powerful programming languages either.
I never claimed they were, in fact I purposely lumped PHP in with them. I'm not ignoring other languages, but the these criticisms against PHP are entirely wrong. There are languages with a greater amount of cleverness, I agree. And yes, I probably would rather be programming in Python at this point. But PHP isn't bad because it lacks closures or mixins.
I never claimed they were, in fact I purposely lumped PHP in with them. I'm not ignoring other languages, but the these criticisms against PHP are entirely wrong. There are languages with a greater amount of cleverness, I agree. And yes, I probably would rather be programming in Python at this point. But PHP isn't bad because it lacks closures or mixins.
PHP is a blunt force language. You can get stuff done in it. It's success is based on low barrier to entry and easy deployment.
The problem with PHP is not one thing that it lacks. It's the complete lack of design in the language. Everything is tacked on, and the sum result is quite ugly. Certainly it's a usable tool, and you can build large scale systems with it, but there is no language that's as much of a mess except for Perl, and Perl at least is incredibly powerful.
The problem with PHP is not one thing that it lacks. It's the complete lack of design in the language. Everything is tacked on, and the sum result is quite ugly. Certainly it's a usable tool, and you can build large scale systems with it, but there is no language that's as much of a mess except for Perl, and Perl at least is incredibly powerful.
Technically speaking, Java can have mixins as well if you include libraries that provide it. Stuff like Spring AOP uses aspectj under the covers and you can mimic mixin-like functionality in your classes with a few annotations here and there.
Technically, you could also provide mixins through the decorator pattern and interfaces. IntelliJ (and I am sure Eclipse) can generate this for me. However, that's less elegant and more fragile than using a language (e.g. Scala) which has Mixins as a language feature: IntelliJ can write code for me, but it can't read for me, nor can it explain it to other developers.
Likewise, I can use multiple inheritance in C++ exclusively only to mimic interfaces (as purely virtual classes) or Mixins (and in fact a lot of corporate style guidelines, e.g. Google's explicitly say that), but it isn't quite the same as having these as language features.
Likewise, I can use multiple inheritance in C++ exclusively only to mimic interfaces (as purely virtual classes) or Mixins (and in fact a lot of corporate style guidelines, e.g. Google's explicitly say that), but it isn't quite the same as having these as language features.
You can do closures, namespaces, mixins, etc in all of those languages (C++, C, Java). Some of them involve libraries, but the fact that people are engineering libraries to do those things means there is actually a need for those things in the enterprise community. I'd say C++ probably has all of those at the expense of uglier looking code. Java has a wealth of libraries that provide feature support for most of those too... I've done mixins & meta-programming at "enterprise level" jobs using Java before (Barclay's Bank), but the code is much more verbose and uglier than languages that support it natively.
My guess is that you haven't actually done enterprise-level jobs using those languages before, otherwise you probably would have seen many of those standard techniques used in the so-called "blub" languages of C, C++, and Java, even if the language didn't provide the feature natively.
My guess is that you haven't actually done enterprise-level jobs using those languages before, otherwise you probably would have seen many of those standard techniques used in the so-called "blub" languages of C, C++, and Java, even if the language didn't provide the feature natively.
Really? Namespaces aren't important for building large scale software? I'd argue that unless you are writing in C for a good reason, namespaces are absolutely a requirement for any-scale of software.
You can argue about closures and mixins, which are handy for people that know how to use them, but are not essential. But are you really going to argue against namespaces?
Ironically, the newer versions of PHP have most of those things, but most people who would care to use them left PHP years ago.
You can argue about closures and mixins, which are handy for people that know how to use them, but are not essential. But are you really going to argue against namespaces?
Ironically, the newer versions of PHP have most of those things, but most people who would care to use them left PHP years ago.
You can fake module naming with underscores (ugly but it works) and with duct typing you're only typing the full names of classes sparingly. In Java, the lack of namespaces would drive you insane, in PHP not so much. The lack of namespaces hasn't slowed down the development of very large class hierarchies in PHP -- just look at the Zend framework.
I'm not arguing against namespaces, I'm just saying for PHP they're more of a luxury than a necessity.
I'm not arguing against namespaces, I'm just saying for PHP they're more of a luxury than a necessity.
Mixins are actually kind of nasty; better to use Traits/Roles instead.
Not sure that you would want to use any of those three for large-scale development. C and C++ execute quickly at the expense of safety (bad for big apps), and Java is optimized mainly for ease of hiring programmers.
If you want to write clean, large-scale applications, you are going to need abstractions that those languages don't have. (Too bad CL never caught on, that would be perfect for what people use Java and C++ for...)
If you want to write clean, large-scale applications, you are going to need abstractions that those languages don't have. (Too bad CL never caught on, that would be perfect for what people use Java and C++ for...)
> If you want to write clean, large-scale applications, you are going to need abstractions that those languages don't have.
That's pretty much false given that nearly all large-scale applications are written in C and C++. Every operating system, every web browser, almost every type of server software, and most desktop software. You might not want to it (I prefer C# for desktop development) but it's possible. And most large-scale web software (Facebook, etc) is written in PHP. So perhaps all those developers know something that you do not.
All those features are just not necessary. They're nice to have, perhaps. You can shoot yourself in foot with them, also possible. But you can build really great and clean software without them. And you can certainly build a massive ball of mud with closures and mixins.
That's pretty much false given that nearly all large-scale applications are written in C and C++. Every operating system, every web browser, almost every type of server software, and most desktop software. You might not want to it (I prefer C# for desktop development) but it's possible. And most large-scale web software (Facebook, etc) is written in PHP. So perhaps all those developers know something that you do not.
All those features are just not necessary. They're nice to have, perhaps. You can shoot yourself in foot with them, also possible. But you can build really great and clean software without them. And you can certainly build a massive ball of mud with closures and mixins.
This is where the term "code monkey" came from.
PHP has a lot of virtues. It's fast. It has libraries for almost everything a web programmer needs. Deployment is trivial with SCP and with rsync scales to hundreds of machines easily, with barely more infrastructure than a shell script.
Even its supposed deficits are advantages sometimes. PHP stops you from a lot of temptations to go non-REST. Anyone who's seen a Java project where the web server is spawning multiple threads per request can understand.
It just gets incredibly annoying when you try to do anything complex with programming logic. Due to its rather low ceiling of abstraction, PHP encourages you to cut and paste rather than refactor. Again, not actually a problem for many, until you get to a very advanced stage (say three years) and how many projects even last that long?
Even its supposed deficits are advantages sometimes. PHP stops you from a lot of temptations to go non-REST. Anyone who's seen a Java project where the web server is spawning multiple threads per request can understand.
It just gets incredibly annoying when you try to do anything complex with programming logic. Due to its rather low ceiling of abstraction, PHP encourages you to cut and paste rather than refactor. Again, not actually a problem for many, until you get to a very advanced stage (say three years) and how many projects even last that long?
PHP is very good for little, dirty projects coded in a weekend, but also for big, long-running projects (well, maybe Java and Rails are better for that).
Facebook, Yahoo! and lately (at least, looks like) twitter (that's just a guess after seeing their server-status pages) do use PHP. I do, also.
You can build huge projects using a self-made (or external maintained) abstraction structure fitting your needs (database, data clustering, middleware). Or just a countdown page with the days before the next party (?). And, in both examples, it wouldn't be slower to code things with PHP than with RoR.
Facebook, Yahoo! and lately (at least, looks like) twitter (that's just a guess after seeing their server-status pages) do use PHP. I do, also.
You can build huge projects using a self-made (or external maintained) abstraction structure fitting your needs (database, data clustering, middleware). Or just a countdown page with the days before the next party (?). And, in both examples, it wouldn't be slower to code things with PHP than with RoR.
Using PHP does not mean that it is turtles all the way down. Best tool for the job, i suppose.
Twitter uses a combination of Ruby and Scala, by the way.
You're right.
I should have been more precise. I should have said the vast majority of web development is not complex, not web development is not complex. PHP is a good fit for the majority of projects. For exceptionally large projects (the far right of the distribution), the weak abstraction may impose a penalty.
I should have been more precise. I should have said the vast majority of web development is not complex, not web development is not complex. PHP is a good fit for the majority of projects. For exceptionally large projects (the far right of the distribution), the weak abstraction may impose a penalty.
"Again, not actually a problem for many, until you get to a very advanced stage (say three years) and how many projects even last that long?"
Two of our oldest clients who also happen to be the busiest and most profitable have been with us for 4+ years, and have been requesting feature changes, etc., without a total rewrite.
So, from my experience, enough.
Two of our oldest clients who also happen to be the busiest and most profitable have been with us for 4+ years, and have been requesting feature changes, etc., without a total rewrite.
So, from my experience, enough.
By fast, you mean 70 times slower than other dynamic languages?
http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
Nice cherry picking.
I can cherry pick: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
too: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
My favourite chart is still this one though: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
If that doesn't show how optimized Erlang is for certain use cases, nothing does.
I can cherry pick: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
too: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
My favourite chart is still this one though: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
If that doesn't show how optimized Erlang is for certain use cases, nothing does.
Just saying that PHP is not objectively fast. "Fast enough", perhaps.
It's also worth noting that where PHP does well is in direct calls to C libraries; compare the C version and PHP version of pidigits; they are almost identical. A few languages do as well with their native numerical tower, which is very interesting.
It's also worth noting that where PHP does well is in direct calls to C libraries; compare the C version and PHP version of pidigits; they are almost identical. A few languages do as well with their native numerical tower, which is very interesting.
> A few languages do as well...
Specifically?
Specifically?
Haskell: http://shootout.alioth.debian.org/u32/benchmark.php?test=pid...
(I am pretty sure GHC uses GMP for its core math routines, though.)
(I am pretty sure GHC uses GMP for its core math routines, though.)
> GHC uses GMP
Exactly, so I don't understand in what sense we could say GHC is an example of languages that "do as well with their native numerical tower"?
http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes
Exactly, so I don't understand in what sense we could say GHC is an example of languages that "do as well with their native numerical tower"?
http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes
It is GMP, but the programmer doesn't know that. It is simply a good implementation choice (for speed, anyway), which is what the benchmark measures.
And few of the Ruby programs are re-written for quadcore so:
http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...
And that PHP :: SBCL webpage has a link to "Overall Performance: PHP is rarely the bottleneck (HTML slides)" ;-)
http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...
And that PHP :: SBCL webpage has a link to "Overall Performance: PHP is rarely the bottleneck (HTML slides)" ;-)
If you work someplace where LISP and PHP are both contenders for the same numerically-intensive task, I agree you should use LISP.
I am curious to see evidence of the encouragement to cut and paste. Especially now that 5.3 has real first class functions, I can not see what paradigm/feature (other than macro expansion) you are using in another language which can not be done in php. Well ok mixins would definitely be nice...
I don't have evidence - I'd need a study for that. It's just one guy's experience.
Ok, maybe PHP 5.3 has this now, but previously, the lack of anything lambda-ish made some refactorings just impossible. Even with Java you could make a functor that, while ugly to code, would be reasonably performant.
As your comment shows, PHP spent most of its life as a procedural language and it took a few versions to get objects right. And being not-strongly-typed, refactoring tools are necessarily incomplete or primitive. I just went Googling and it seems that many PHP devs think that refactoring is the same thing as applying a regular expression search and replace to their codebase. Compared to what's possible with Java plus IDEA or Eclipse, it's no wonder PHP devs hate to refactor.
Lastly: PHP encourages you NOT to separate presentation and logic. This is why big PHP sites tend to use some other templating language even on top of PHP. The barriers to refactoring when presentation and logic are commingled should be obvious.
Ok, maybe PHP 5.3 has this now, but previously, the lack of anything lambda-ish made some refactorings just impossible. Even with Java you could make a functor that, while ugly to code, would be reasonably performant.
As your comment shows, PHP spent most of its life as a procedural language and it took a few versions to get objects right. And being not-strongly-typed, refactoring tools are necessarily incomplete or primitive. I just went Googling and it seems that many PHP devs think that refactoring is the same thing as applying a regular expression search and replace to their codebase. Compared to what's possible with Java plus IDEA or Eclipse, it's no wonder PHP devs hate to refactor.
Lastly: PHP encourages you NOT to separate presentation and logic. This is why big PHP sites tend to use some other templating language even on top of PHP. The barriers to refactoring when presentation and logic are commingled should be obvious.
"PHP encourages you NOT to separate presentation and logic."
Is this a stated policy, or are you inferring it based on the structure of PHP being embedded in HTML?
There's nothing about PHP which prevents separating the two. There are even the shorter tags and braceless syntax, which are especially friendly to templating. Eg,
Is this a stated policy, or are you inferring it based on the structure of PHP being embedded in HTML?
There's nothing about PHP which prevents separating the two. There are even the shorter tags and braceless syntax, which are especially friendly to templating. Eg,
<? foreach($pages as $page): ?>
<h2><?= $page->title ?>
<div class="content">
<?= paragraphs($page->content) ?>
</div>
<? endforeach; ?>BlogPost blogPost = BlogPost.factory("post");
Ahhhhh, Java.
Ahhhhh, Java.
[deleted]
I've been trying to implement rubyisms in php for fun and got some pretty cool mixins functionality working. Requires php 5.3 though: http://github.com/huberry/phuby
Wait, how do you deploy with with scp? What happens when you drop a file locally?
He's saying that all you have to do is post the file on a webserver with PHP installed and it should work. No compiling. No raking. No installing Passenger, Rack, etc...
I'm a Ruby guy, but I do recognize that PHP deployment is generally fast, smooth and easy.
I'm a Ruby guy, but I do recognize that PHP deployment is generally fast, smooth and easy.
That exact same workflow exists for Passenger. I'm not even sure you can install Rails without Rack anymore. And installing and deploying a fresh Passenger install is easier than deploying a second app on a Mongrel/Apache cluster; it is very, very easy.
I know the first time that I tried to set up Passenger with Sinatra- I had some issues, despite following tutorials. I kept having to touch some file to get it to read the new files and wasn't really working as expected. PHP just seems to run after I apt-get the php stuff and drop the files in there.
But yes, generally Passenger does the trick.
But yes, generally Passenger does the trick.
I've consistently had problems deploying Rails apps. I can usually work through them, but it has never once been smooth.
It must be me, though, because every time I mention it, someone accuses me of being an idiot or trolling.
It must be me, though, because every time I mention it, someone accuses me of being an idiot or trolling.
It used to be way complicated, but Passenger has made everything orders of magnitude easier. Tried it?
I understand the above, I was asking something else.
Your app machine pulls the new version from the source machine via scp, then changes a symlink. like a poor man's rsync --backup
I'm not sure what you mean by "drop" a file.
Small websites with low cohesion between pages can probably get away with scp or rsync and nothing else. For a more highly trafficked website, you'll hide server instances from the outside world as you update their files and configuration. But this still isn't rocket science.
Small websites with low cohesion between pages can probably get away with scp or rsync and nothing else. For a more highly trafficked website, you'll hide server instances from the outside world as you update their files and configuration. But this still isn't rocket science.
What I think they mean is that if you remove a file locally, it is still probably accessible on the production machine if you just use scp to copy the files over directly. Rsync is a better option for this if you want to ensure locally removed files are in fact removed on your production machine(s).
I haven't done PHP work for almost 5-6 years, but when we did it, I had post-commit scripts set up in SVN (or was it CVS back then?) that if a commit was tagged "production" would trigger the production server to perform a fresh checkout. That was the only deploy step needed.
Funny, but you can get the same type of setup working with any language. Scp a WAR file into the appropriate Tomcat directory and your Java project is good to go (no reloading of the appserver required). Or, if you have auto-reloading of modules setup in Python, you can do the same thing.
So, this type of deployment isn't just for PHP... but with PHP it is the default (only?) method.
I haven't done PHP work for almost 5-6 years, but when we did it, I had post-commit scripts set up in SVN (or was it CVS back then?) that if a commit was tagged "production" would trigger the production server to perform a fresh checkout. That was the only deploy step needed.
Funny, but you can get the same type of setup working with any language. Scp a WAR file into the appropriate Tomcat directory and your Java project is good to go (no reloading of the appserver required). Or, if you have auto-reloading of modules setup in Python, you can do the same thing.
So, this type of deployment isn't just for PHP... but with PHP it is the default (only?) method.
PHP is one language, I am absolutely not willing to (primarily) develop in. I've left a PHP-only job almost entirely over the matter of language choice (there PHP was used for everything. My worst decision there was -- after getting a Hadoop cluster going -- showing the team how to do Map/Reduce in PHP via the streaming API).
I've never felt a strong repulsion to any language like I do with PHP and I wonder why. I think at the core of are these facts: it's optimized for web development, doing anything complex or CS/math intensive (developing algorithms, doing off line computation, systems programming) is sometimes possible, but always painful. I've played with PHP3 before college and other than what I've learned in a databases course, very little what I've learned in a university seems to be applicable to routine PHP programming. It doesn't feel like actual development.
Ironically, PHP seems to work very well in conjunction with more powerful languages: Yahoo, Facebook and others are built with PHP as essentially a template layer, with Java/C++/Erlang/Perl/Python on the backend. Perhaps the fact that coding PHP doesn't feel like software engineering is it's greatest asset. It's a language that a web developer can immediately be productive in. Yet it also exposes what is often tediousness and triviality of most web development. I remember first playing with emacs, SLIME, cl-sql, mod_lisp and UCW: while I was writing a web application (something PHP is well suited for), I felt I was excercising my brain a great deal more. To a lesser extent it felt true with Python/CherryPy and Perl/mod_perl.
Perhaps what makes PHP successful at Yahoo and Facebook is that they're serious, well-funded technology companies who are able to attract talented developers (who can take advantage of PHP's easy interoperability with C). An early stage start-up choosing PHP seems to almost doom itself by attracting a crowd that treats PHP as Blub (rather than as a sometimes appropriate tool), or in less refined terms "script kiddies".
I've never felt a strong repulsion to any language like I do with PHP and I wonder why. I think at the core of are these facts: it's optimized for web development, doing anything complex or CS/math intensive (developing algorithms, doing off line computation, systems programming) is sometimes possible, but always painful. I've played with PHP3 before college and other than what I've learned in a databases course, very little what I've learned in a university seems to be applicable to routine PHP programming. It doesn't feel like actual development.
Ironically, PHP seems to work very well in conjunction with more powerful languages: Yahoo, Facebook and others are built with PHP as essentially a template layer, with Java/C++/Erlang/Perl/Python on the backend. Perhaps the fact that coding PHP doesn't feel like software engineering is it's greatest asset. It's a language that a web developer can immediately be productive in. Yet it also exposes what is often tediousness and triviality of most web development. I remember first playing with emacs, SLIME, cl-sql, mod_lisp and UCW: while I was writing a web application (something PHP is well suited for), I felt I was excercising my brain a great deal more. To a lesser extent it felt true with Python/CherryPy and Perl/mod_perl.
Perhaps what makes PHP successful at Yahoo and Facebook is that they're serious, well-funded technology companies who are able to attract talented developers (who can take advantage of PHP's easy interoperability with C). An early stage start-up choosing PHP seems to almost doom itself by attracting a crowd that treats PHP as Blub (rather than as a sometimes appropriate tool), or in less refined terms "script kiddies".
Conversely, PHP has one several advantages over Rails. Most notably, immediacy. Deployment via SCP is very satisfying.
Though not as satisfying as using source control and having a one command "deploy" that's just as quick as SCPing a bunch of files.. I can deploy - to production - local builds of my Ruby projects in seconds.
There are no significant advantages to using PHP or disadvantages to using Ruby or Rails presented in that blog post, even though it tries to make it seem that way. (And on the library complaint, the Ruby libraries that came along for things like S3 and EC2 are better than the official ones by a long shot.)
Despite that, different strokes for different folks. Use what works for you and all that!
Though not as satisfying as using source control and having a one command "deploy" that's just as quick as SCPing a bunch of files.. I can deploy - to production - local builds of my Ruby projects in seconds.
There are no significant advantages to using PHP or disadvantages to using Ruby or Rails presented in that blog post, even though it tries to make it seem that way. (And on the library complaint, the Ruby libraries that came along for things like S3 and EC2 are better than the official ones by a long shot.)
Despite that, different strokes for different folks. Use what works for you and all that!
I come off like a Capistrano fanboy in this thread, but I guess that I kind of am.
I only ever used the SCP method when I did PHP stuff, but the projects were never anything that big. Now that I do Rails all the time, having a tool like Capistrano is amazing. 'cap deploy' copies my code, changes the symlink, updates my database schema, notifies my error reporting, restarts my webserver, and cooks me dinner.
Okay, I exaggerate. But seriously. Automation! It's awesome.
I only ever used the SCP method when I did PHP stuff, but the projects were never anything that big. Now that I do Rails all the time, having a tool like Capistrano is amazing. 'cap deploy' copies my code, changes the symlink, updates my database schema, notifies my error reporting, restarts my webserver, and cooks me dinner.
Okay, I exaggerate. But seriously. Automation! It's awesome.
It is! And even if you just jury rig it! Several of my projects have a deploy script that's just a bash one liner that does a git push and does a git pull and touches a restart file on the server :-)
Another advantage of this is that it makes you actually commit to your repository, if you're bad at that kind of thing.
You could have deployed code using SCP with Passenger, which is basically Ruby deployed PHP-style and is basically the emerging standard for how Rails apps are deployed. So immediacy seems like a weird reason to take such a step back on languages.
But I mean, do whatever makes sense for you. PHP apps are good for business for us. =)
But I mean, do whatever makes sense for you. PHP apps are good for business for us. =)
Or better yet, via git push and a post-receive hook to touch tmp/restart.txt...
Or better yet, using Capistrano to do that and more.
Things like Capistrano are the reason this person gave up Rails for PHP, and I don't really blame them.
Why? I mean, for a very basic setup, you just run 'capify .', and then change some passwords, and you're good to go. It doesn't even really take any configuring.
Here's the thing: good engineering means that you should automate as much as possible. That way, everything is consitant. One command deployment is amazing, regardless of your technology stack.
Here's the thing: good engineering means that you should automate as much as possible. That way, everything is consitant. One command deployment is amazing, regardless of your technology stack.
It's more complicated than just scp'ing files over. That's all I have to say. It's fine to say that it's also better engineering, but that doesn't address the original article. Ruby is also a better engineered language than PHP in a lot of ways.
Ruby is also a better engineered language than PHP in a lot of ways.
I would say better designed, but the engineering definitely leaves a lot to be desired. Here's hoping Rubinius gets finished one day.
I would say better designed, but the engineering definitely leaves a lot to be desired. Here's hoping Rubinius gets finished one day.
Well, there's also JRuby, and YARV is a lot better than MRI, although the libraries haven't quite caught up yet.
Ruby wasn't even a semi-mainstream competitor for web development until Ruby on Rails came along, so even comparing it to PHP (or worse, thinking Ruby and RoR is the same thing) is where a lot of the confusion starts.
yeah, for most simple apps, scp will do the trick, but anytime you start writing scripts to upload the same set of files on 5 different machines, it's time to use capistrano.
'cap deploy' is easier than 'scp here there'.
[9:28pm:/playbook] DIVISION:tqbf [0:279]% cap deploy
the task `deploy' does not existReally? I'm pretty new to Capistrano, but 'deploy' was just kind of built in or something. That's very strange.
See the footnote. I mentioned passenger.
You didn't say anything about it, only that "it's a game-changer for Rails application deployment" and that PHP is better, for no reason you can articulate.
I don't care.
I don't care.
Using PHP hits back at you after a few years when you find out all its libraries are slowly rotting, revealing fundamental security flaws that will give you unimaginable headaches. These days I select my languages purely by programmer competence.
So true. PHP library implementers seem to love making everything a strange corner case instead of taking a step back and picking a better abstraction. It is amazing how easy it is to write code that works for all possible inputs when you pick the right abstraction, and it's amazing how downright difficult it is when you pick the wrong one. PHP libraries function accordingly.
After reading up on the powerful SPL classes included with PHP5 and developing on top of the very well-coded KohanaPHP framework, PHP development has become very productive lately. Although, I prefer Python's syntax, the deployment speed of PHP is very hard to match.
The inconsistent function library definitely gets annoying, but I guess that's why PHP has such excellent documentation. Using Eclipse PDT code hinting also mitigates the API annoyances.
The inconsistent function library definitely gets annoying, but I guess that's why PHP has such excellent documentation. Using Eclipse PDT code hinting also mitigates the API annoyances.
When I was first learning Ruby on Rails as a proficient PHP programmer, the company I worked for landed a largish (for us at the time, given there were only two programmers in the place back then) contract for a web application. Since I was just learning Rails, and I needed to be highly productive on the project, I recommended that we use CakePHP so I could use my PHP skills. I figured my co-programmer, who loved Rails, would acquiesce due to the presence (at least) of an MVC framework, and I was right.
I've regretted that decision many times. Not all MVC frameworks are created equal, and I can say from painful experience that Rails is far superior to CakePHP. We got the job done, and I may have been right that I was more productive in PHP back then than I was in Ruby. But three years later, it is far more difficult to get things done on this web app than if it were built on Rails.
I'm not one to engage in language wars, and I still enjoy coding in PHP. But if you want a great framework, I'm still not sure you can beat Rails, and I really don't think there's anything in the PHP world that can.
I've regretted that decision many times. Not all MVC frameworks are created equal, and I can say from painful experience that Rails is far superior to CakePHP. We got the job done, and I may have been right that I was more productive in PHP back then than I was in Ruby. But three years later, it is far more difficult to get things done on this web app than if it were built on Rails.
I'm not one to engage in language wars, and I still enjoy coding in PHP. But if you want a great framework, I'm still not sure you can beat Rails, and I really don't think there's anything in the PHP world that can.
Just out of curiosity, what problems did you run into specifically? I adopted CakePHP for similar reasons and haven't run into any issues that have made me regret it, although I did leave standard development practice for a few reasons that have made caching a bit more difficult than otherwise.
Sorry, I tend not to notice when people respond to my comments, it'd be great if this site had an easier way of letting you know when people do (maybe I'm just not aware of it?)
Anyway, the main issues I ran into were all related to database queries. This application was not a standard CRUD-style app at all, it has a lot of pretty complex queries for building reports. I found the way that CakePHP deals with joins and associations really clunky and hard to use compared to Rails' ActiveRecord. I'd often have to write the raw queries and try to shoehorn them into CakePHP's ORM objects.
I just found myself frequently frustrated with the way it was working. It's been too long since I really worked on it for me to be able to give much more detail than that (also, it probably has improved a lot since then too).
That said, using it as a web framework still made coding the app a heck of a lot easier than it would have been without it. Also, I found that it really improved my PHP skills, I picked up a ton of good stuff from using it.
Anyway, the main issues I ran into were all related to database queries. This application was not a standard CRUD-style app at all, it has a lot of pretty complex queries for building reports. I found the way that CakePHP deals with joins and associations really clunky and hard to use compared to Rails' ActiveRecord. I'd often have to write the raw queries and try to shoehorn them into CakePHP's ORM objects.
I just found myself frequently frustrated with the way it was working. It's been too long since I really worked on it for me to be able to give much more detail than that (also, it probably has improved a lot since then too).
That said, using it as a web framework still made coding the app a heck of a lot easier than it would have been without it. Also, I found that it really improved my PHP skills, I picked up a ton of good stuff from using it.
In general I can't disagree. If it makes sense, use it. What always struck me as odd though is the heavy focus on application code deployment.
I mostly work on larger projects, so application updates are usually simply a pull from the repository. It is usually a bigger hassle to get a smooth transition of the database schema, file-system storage or anything else that holds data.
I mostly work on larger projects, so application updates are usually simply a pull from the repository. It is usually a bigger hassle to get a smooth transition of the database schema, file-system storage or anything else that holds data.
That may be true. I have not seen what Cake offers in that respect.
For the few rails projects I developed, I used capistrano but for small projects this felt unrewarding. Tangentially (to git pulls), I did notice that PHP developers favor SVN to git, which I don't like as much.
For the few rails projects I developed, I used capistrano but for small projects this felt unrewarding. Tangentially (to git pulls), I did notice that PHP developers favor SVN to git, which I don't like as much.
"I did notice that PHP developers favor SVN to git..."
I can attest to this. I spend a lot of time working with PHP with a lot of different people, and almost every single one of them uses SVN for deployment. I'm not sure if this good practice or not, but it's just so convenient.
I can attest to this. I spend a lot of time working with PHP with a lot of different people, and almost every single one of them uses SVN for deployment. I'm not sure if this good practice or not, but it's just so convenient.
i can only hope this post doesn't degrade into a troll war about why ruby is better than php or vice versa... i've used both, they both work, they're both fine. can't we leave it at that? =]
Eh. I decided to read the post because of how outrageous the title seemed, but I can't say I really agree with the gist of what you're saying.
I don't really understand why you'd prefer to deploy over SCP, either. You know what's really trivial? "cap deploy"
As far as speed goes, I think of Ruby as some sort of investment, in that I believe Ruby's 2.0 era will surpass PHP, and perhaps come close to Python.
I don't really understand why you'd prefer to deploy over SCP, either. You know what's really trivial? "cap deploy"
As far as speed goes, I think of Ruby as some sort of investment, in that I believe Ruby's 2.0 era will surpass PHP, and perhaps come close to Python.
> As far as speed goes...
But will any of them catch up to JavaScript :-)
But will any of them catch up to JavaScript :-)
I use Ruby and I love this language, truly. I wrote my framework, play with Sinatra, and so on, like you. But we are in hacker news and are in some way a closed ring of people a bit smarter than the average programmer.
Then there is the mass of programmers that could witch from PHP to something better. All they want is a mod_please_make_ruby_simple that is, like mod_php but for Ruby. You install it on Apache, and all the pages called .rhtml will get executed with the trick of things outside <? ?> being translated into echos.
This module should also provide, automagically and built-in, support for all the obvious stuff like file uploads, MySQL bindings and so on.
I understand that PHP got this right for the masses, but can't understand why no one is trying to do it the right way for other much more powerful and elegant dynamic languages.
Then there is the mass of programmers that could witch from PHP to something better. All they want is a mod_please_make_ruby_simple that is, like mod_php but for Ruby. You install it on Apache, and all the pages called .rhtml will get executed with the trick of things outside <? ?> being translated into echos.
This module should also provide, automagically and built-in, support for all the obvious stuff like file uploads, MySQL bindings and so on.
I understand that PHP got this right for the masses, but can't understand why no one is trying to do it the right way for other much more powerful and elegant dynamic languages.
Because those of us that know how to implement that sort of system have no need for it. There are thousands of things I want to implement; making something I'll never use is not one of those.
Rails + Heroku is deployment heaven. It's even easier than scp.
Yes, +1 for that. "git push heroku master"
and expensive
Actually, this is one thing that I really love about Heroku. They will host apps for free. I put my http://2rgb.com there and am not paying a cent.
For a serious app, I'll have to start paying, but the prices seem worth it to me because they're saving me a lot of time. Maybe it's expensive compared to other hosts; that I don't know.
For a serious app, I'll have to start paying, but the prices seem worth it to me because they're saving me a lot of time. Maybe it's expensive compared to other hosts; that I don't know.
the free account only allows 5MB of storage. I can't do much of anything with that. From there it gets expensive fast if you run multiple sites. It might be a different equation for a single site.
Could someone please provide a link as to how Facebook and/or Yahoo use PHP with "templates"?
I want to create "yet another" social networking site for a niche market, and am trying to figure out what technology would work best for this space.
I've been using asp.net for the last several years, and used to code in mod_perl, java, etc. But, I don't have any experience with the newer open source languages. I want to pick what's a good fit (even if I have to learn a new language). I know these are just basic details, but would greatly appreciate any feedback.
Thanks! (long-time lurker, first-timer poster)
I want to create "yet another" social networking site for a niche market, and am trying to figure out what technology would work best for this space.
I've been using asp.net for the last several years, and used to code in mod_perl, java, etc. But, I don't have any experience with the newer open source languages. I want to pick what's a good fit (even if I have to learn a new language). I know these are just basic details, but would greatly appreciate any feedback.
Thanks! (long-time lurker, first-timer poster)
This post is meta-interesting for me. I did not expect it to elicit 4,000+ unique visits. I almost want to put an: Update: PHP S%cks! at the top of the blog post just for fun (I wont).
Your post appeals to two audiences; the blub/PHP programmer that reads your post to justify his own tastes, and the OMG Ruby Is So Awesome programmer, who wants to read your post to tell you how dumb you are.
I wrote about Java once on my blog. Never again. That is a crazy language community.
I wrote about Java once on my blog. Never again. That is a crazy language community.
Sadly, I think your summation is accurate.
I got 9 up votes for my comment on PHP in http://news.ycombinator.com/item?id=903402 so I wrote this blog entry while at work. I have a feeling the post makes me sound like a douche. We'll see.
PHP is also not tuned to some fitness function; it tunes its users. In exchange for not having to understand abstraction or OO, you get to learn the wierd quirks of thousands of inconsistently-named functions that live in a shared global environment. Sure, the number of "concepts" you have to know is low (no closures, no MOP, no lexical scope, ...), but the number of inane details you have to know is high. PHP shows that people would rather understand the exact details of arguments to a function instead of understanding abstraction and metaprogramming. (Similarly, people like to cram for exams without really understand the subject matter.)
That is fine, but unless you are "people in general", you are missing out on a lot by "choosing" PHP.
(Deployment is always a big issue. Do you really want to market your app to people that can't even run a package manager, "cpan" or equivalent, and so on? I find Perl perfectly easy to deploy. If I can't "apt-get install" the app, I type "cpan AppName", wait a while, and my app works.
Additionally, users that find deployment too hard unless it's "untar this and click pictures" are going to require a lot of support but aren't going to contribute a lot of code back to you. So maybe this isn't the best optimization to make.
Finally, why not JSP for this? Startup Tomcat, edit code in a web page, and boom, your "app" works. It ain't pretty, but it's better than PHP. Tomcat is no harder to setup than Apache + mod_php either.)