I guess, nobody ever accessed that.
I wouldn't ever expect to convince anyone who had ever worked on an old CF site to move back to CF ever again (believe me, I'm still scarred from it) but it's actually pretty good these days (Railo, that is).
My experience isn't limited either; Rails, Django, Flask, .Net (Umbraco), CodeIgniter, Drupal to name a few. They all have their warts. I hate to say it but in my experience Railo (CF) is way more performant than any of them.
Even JBoss has an open source CFML distribution, http://www.getrailo.org/ so the whole cost argument is mute.
CFScript is JavaScript (ECMAScript)
No it isn't, by any stretch of definition or imagination.In fact, I think Ruby has more in common with ECMAScript than CFScript does.
That and utterly unreliable servers, to the point of having a process running under Windows to restart the server when it accumulated, say, 50 pending requests.
I'll never touch it again.
I think good TDD/agile/architecture cultures are more prevalent in ruby/python but as those languages have become more mainstream the quality of the average dev in those environments has dropped quickly. A few years ago only really good devs ventured into ruby stuff. Now everyone is trying it as the tools have made the language much more accessible for the average developer. I am seeing more and more programming mistakes in the ruby code I dive into than I used to.
Language choice doesn't matter too much from a technical perspective. It matters from a practical perspective. Consider the jQuery/prototypejs war. Prototypejs was technically superior for a long time, yet due to jQuery's more accessible plugin culture and prettier web site they were over time able to build a more robust community and took the mindshare lead in the js space. I still think one of the core reasons ruby/rails and python/django got big is that for a long time there was only one major framework available for the language and this caused a better community than the php landscape, which pre-dated frameworks by a long time (this happened to perl as well). So there wasn't "one true way" in php to build apps quickly, and this hurt the php community when rails got big. I think as a community we lost a lot of talent to ruby/rails in the last few years.
Bottom line is that accessibility, pervasiveness and low-learning-curve are critical to the initial and continued success of any platform, whether it's a language (ruby > php > perl), OS (ios > android > rim), etc.
Language advances in PHP (circular gc, traits, closures, etc) have brought php's language capabilities forward enough that it's a respectable platform for sticking with. However, you can't fix the community really since it's so fragmented. Fortunately some frameworks are getting enough traction to have rich ecosystems, and that's definitely a great thing for the language and the community.
Can you expand on that at all? What made Protoype technically superior?
(this is all with the understanding that prototype adding methods to standard objects was dangerous...)
I believe I meet your criteria but can only work remotely. I am currently looking so if remote is an option please let me know and I can send you more details.
* Arrays are created with array() as opposed to a more modern [].
* Arrays are not objects, so you have a ton of functions in the global namespace starting with array -- array_join() as opposed to $array->join().
* The functions are not consistent. Half of them don't have "array_" as a prefix. The order of arguments isn't consistent with other parts of the standard library.
I'm really curious about why you consider this a strong point of PHP.
When people want to pick nits about this or significant whitespace it makes me think that there must very little variance between the languages if THIS is the issue that deserves scrutiny. Am I missing something about array() vs [] ?
if you really hate typing array(), http://codepad.org/ASREdjTK
What? Why is [] better? Because it saves you typing 5 extra characters?
In my view the only problem with PHP array functions is the fact that the naming scheme is an absolute disaster (as it is all over PHP, for historical reasons).
This should help you.
Awesome PHP is awesome.
Downvote? Really? Pfft.
> But if you considering building anything today on PHP (when you have sooooooooo fucking many better platforms) you are incompetent and plain stupid, because it will be a big technical debpt for the whole project.
I think we have a bunch of stupids like facebook and mailchimp... Php or any other programming language is a tool, a proven one. So if you can do some amazing things go for it.
"You use X then you are an idiot. Y is for masters !" approach is childish and proves that you can only use Y technology.
I'm talking about Wordpress and vBulletin.
While MVC isn't the only valid design pattern, some varient of it is rather nice when working with websites and these two seem to ignore it through and through. Testing? What's that?
I know that better can be written in PHP, but for apps that I've had to deal with, PHP normally looks like an overpowered scripting language that's just a mess. I'll stay with Rails and Sinatra when I can.
MediaWiki is all over the place and the themes included in the install are just horrifying. Whoever made the original (monobook) theme should get slapped in the face.
Matters for a single 15 years-old developer. Deployment is never easy when you get do anything non-trivial, and the cheap hosting... hosting for other languages start at $5 or $10... The only cheaper hostage PHP has is free.
> good documentation
That's highly debatable. I've also seen the PHP doc comments being pimped, I could never find anything worth more than a laugh in that cesspool.
The key here, as it states, is that they "built their own framework/libraries", which essentially means nothing to indie-devs and other small non-well-established companies who want to build something...
So the trend is simply this:
1) We use PHP because it's what we know, easy to get started with etc.
2) It gets us by while we build our business
3) Profit! Re-factor our codebase, in PHP!
Thus, the blog post should read: "Hey Mailchimp is doing awesomely, so we refactored our PHP codebase with our very own custom framework!"
It's not that PHP is all bad; it just lost the "framework wars" IMO, and I think when companies come out and state things like this, it kinda proves it...
I don't think everyone is doing that (building frameworks), or can, or even should when they're other possibilities outside of the PHP world...
I never really understood this argument. I mean, the overlap between Ruby and PHP are so great that they are virtually interchangeable.
Why am I calling "validate_purchase" on the server?
Client Clicks Buy -> JSONP to Payment Gateway -> Gateway to Server (with all the info) -> Server to Client Confirming Transaction
All my server is doing is recording the transaction and forwarding the info to the client. The gateway is trusted, since they are processing payments.
I'm serious. This is where we're headed. Yes, you will have a hell of a lot of server-side code on the gateway, but that's a service, not the application.