
Taking PHP Seriously [pdf] - memla
https://raw.github.com/strangeloop/StrangeLoop2013/master/slides/sessions/Adams-TakingPHPSeriously.pdf
======
dkhenry
At this point we almost need to stop saying facebook programs in PHP. I know
this was defending PHP, but look at what is happening. Facebook ( big
engineering firm, lots of developers and resources ) could not get php to work
for them short of rewriting the core (HPHP ) and then adding on features to
the language that most other languages have determined are useful enough to be
baked into the language.

Here is my TL;DR of this article. PHP is bad we all know this and accept it.
Facebook has made it better by keeping most of the syntax and chucking
everything else out the window. Run your stuff on HipHop ( unless you need
extensions in which case your OOL )

~~~
workhere-io
_could not get php to work for them short of rewriting the core (HPHP )_

I've heard this argument before, but it's important to realize that Facebook
was able to use standard PHP up until the point when they had roughly 500
million users. Unless your site has a half billion users you can't compare
your use case to Facebook's.

~~~
hyperpape
They're making three sorts of changes: 1) removing/restricting the footguns in
the language 2) adding interesting features taken from other languages
(typing, traits, etc). 3) creating a new VM with better performance.

As far as I can tell, only 3 is obviously something that only affects whether
you can use the language once you have a certain number of users. The first
two are really about changing the language.

~~~
Joeri
Speaking as someone who works on a 2 million user enterprise app with standard
PHP, i would have to counter that: 1) the footguns are easy to sidestep once
you know them and are gradually getting removed, 2) standard php has traits
and strict typing, but the typing is not for primitive types (which is what
Hack adds) and 3) in nearly a decade i have had a single feature where i could
have really used a faster php, whereas in practice my performance issues all
come from the Oracle bottleneck because php is so easy to parallellize.
Facebook could run on standard php, it would just require more hardware, and
since releasing hhvm php has gotten a lot faster without breaking backwards
compatibility.

~~~
camus
PHP(.net) doesnt have strict typing ,but type hinting, which is not the same.

~~~
Navarr
It does have strict typing with objects, but not literals.

If I make a function meow(MyClass $meow) { } it will throw errors if anything
other than a MyClass is given to it, __including __NULL.

~~~
camus
You are wrong , it has type hinting , not strict type checking. You can alias
types, there is no hard types in PHP except for arrays. Your function
signature check the name of the object in the namespace , not it's type.

~~~
jtreminio
function meow(MyClass $meow) { }

This will only accept an object that is_a MyClass. It can either implement an
interface MyClass, extend an abstract MyClass, extend a regular class MyClass,
or be the actual object MyClass.

Namespaces have nothing to do with this, other than you being able to use the
"use" statement at the top to alias it.

------
DigitalSea
Adams actually makes some very valid arguments in this PDF. People like to
argue the superiority of languages, but at the end of the day if the result in
PHP is the same as it is in Ruby & Rails, Java, .NET or whatever, does it
really make what the language is? Another good point is the efficiency of a
developer working in PHP. The language is easy, it's so easy to be a PHP
master after a few years working in the language. It's easy to find super-
talented PHP developers compared to any other language.

I like the idea of opt-in typing for PHP via Hack which you can enter by
beginning your PHP code with <?hh — Facebook have essentially taken everything
that is wrong with PHP, every complaint that someone has ever published in a
blog post or bug report, forum or IRC channel and built it into an improvement
of the language.

PHP isn't going anywhere. It might be one of the oldest web languages, but I
think the PHP space is starting to get better with Facebook's contributions to
the language, Laravel 4 being a solid PHP framework and we can't forget that
most Yahoo! products are built using PHP as well (even the recently acquired
Tumblr is coded in PHP). Flickr! is probably one of their biggest PHP
applications.

Event hough Facebook appear to have resolved the many complaints and problems
of PHP, I am sure people will still find a way to complain about the language
that powers most of the web...

~~~
Almaviva
Are the complaints about PHP even controversial? The built in library
functions are a mess, and mostly terrible. The syntax and basic language are
overly verbose and have layers upon layers of cruft. The type and object
systems are grafted on, and have so many gotchas and inconsistencies that it
takes many months to understand enough of them to be very productive in the
language. The aspects of PHP that were intended to make it simple (like
pretending types don't exist) actually make it more difficult to reason about
precisely. I don't think anyone who knows anything else would ever choose PHP
for a fun personal project.

Despite this, there is nothing in PHP that prevents you from doing the thing
you want to do, however you want to do it. As projects become larger and
involve more time and people, the fine grain of line syntax fades out of view,
and all that is left is the large scale design decisions, which are similar in
any language. And this is what ultimately determines the technical success or
failure of software.

~~~
asnyder
I code in Python, BASH, C, and PHP on a regular basis and still strongly
prefer PHP for everyday coding and hobby tasks. I even prefer to create
command-line scripts in PHP (though will switch to Python if it's large to
begin with). For me getting Flask to work properly under NGINX + uwsgi was
such a hassle. Having to tell it what module, and hooking things up to touch
versus just passing to PHP under fast cgi.

To be honest, PHP is really just simpler, less hassle, and if you know what
you're doing things come out structured well. Just stick to classes (Including
statics! There shouldn't be a define() anywhere.), use namespaces, use
composer (I've come to really like it), and use a coding standard.

~~~
leokun
In what ways is PHP less hassle than Python? I don't understand this argument.

~~~
LeafStorm
Deployment, for one. sudo apt-get install Apache and PHP, then edit the Apache
config to say, "use this directory." I love Django and Flask to pieces, but
deploying a Python app is like building a hovercraft compared to PHP.

~~~
leokun
I have no problems deploying a django app with gunicorn. It's a simple command
line statement, and deployment is always an intricate thing, unless you don't
have to worry about ssl certs and secrets and keys, and managing access, admin
pages, etc etc.

~~~
ericd
Which you usually don't for fun personal projects.

------
badclient
Most of the criticism of php seems to contrast it with a language _plus_ a
framework. If you really want to compare, compare php with ruby or python, not
Django or RoR.

As for php encouraging shitty programming, a good bit of that is that so many
more people program in php because its easier to get started with. This does
_not_ mean that just because php attracts shitty programmers that it doesn't
have more or many awesome programmers than languages such as python.

~~~
bowlofpetunias
Methinks the argument that PHP encourages shitty programming has been
effectively countered by the amount of crap legacy Ruby code that has appeared
several years since Rails became "hip".

It should be quite obvious to anyone by now that when it comes to shitty
programming, language is negligible factor once a language has hit the
mainstream.

But I'm pretty sure 5 to 10 years from now someone manages to argue that Ruby
is crap, Rails is to blame for encouraging a generation of developers to write
bloated controllers full of spaghetti code, and that this attracts shitty
programmers incapable of understanding software architecture.

~~~
pgeorgi
I already start arguing along these lines now - starting with the refusal to
define even semi-stable interfaces across versions of a library.

Instead of relying on actual reusable building blocks, you're expected to
build specific versions of ruby interpreter and libraries for every project.

Imagine having to cope with just ever so slightly different (but certainly
incompatible) philips screws whenever you want to affix one physical thing to
another.

------
samuellevy
Before this turns into a recanting of the points in the "PHP is a double-
clawed hammer" post again, I would like to remind people that PHP still has a
place in the business world that nno other language has stepped up to fill.

[http://blog.samuellevy.com/post/41-php-is-the-right-tool-
for...](http://blog.samuellevy.com/post/41-php-is-the-right-tool-for-the-job-
for-all-the-wrong-reasons.html)

Please stop complaining about how horrible PHP is if you don't use it or have.
intentions to replace it.

~~~
ryanSrich
I couldn't agree more.

Having worked with clients that publish thousands of articles of content per
month the best solution for the job at the end of the day is still WordPress.
Have a client that needs an online store? Magento (both of which are built in
PHP).

Development shops don't have time to custom build CMS's and eCommerce solution
because their clients don't give a shit what language or framework their site
is built in.

Show me a CMS built in ruby, python or javascript that comes anywhere near
WordPress and I'll gladly switch. Unfortunately it just doesn't exist. Like
you said, PHP has its place and until something better comes along stop
complaining.

~~~
vdaniuk
In my experience Spree is better than Magento for most smbs. You are
right,however, there is no replacement for WordPress and its ecosystem. Ghost
looks interesting, though.

------
contingencies
I've used _php_ since v3, in its non-OO days. Coming from _perl_ , that fit
nicely. Today, I still avoid OOPHP and continue to write procedurally. The
convenience of web-oriented functionality, broad deployment, and soft typing
is basically unparalleled, although writing this way requires a bit of
discipline. It's also a surprisingly good fit for a lot of server side code if
you scale beyond a merely web-based execution model and have existing
libraries. These days, I generally avoid _perl_ if data structures are
required, and despite dabbling RoR-esque frameworks feel overly constraining
with regards to execution path control: _I don 't want a controller and
additional layers of abstraction, the web server does that already!_

~~~
wanderr
Agreed. There are a few things which are stateful and are therefore made
easier/better by OO, mainly DB connections. For everything else, we mostly use
classes as namespace (pre-5.3) with lots of static methods. In general for
backend web it's pretty silly to spend a bunch of time building up stateful
objects when your real goal is usually to load up the subset of information
the user needs right now, return that and die as quickly as possible.

~~~
jtreminio
The problem with static methods is that they make testing nearly impossible.

~~~
wanderr
Hmm, how so? In general it seems to make testing things easier since nothing
is carrying around state; a static method with the same parameters is going to
run exactly the same way every time no matter where or when it's called.

~~~
jtreminio
You are unable to properly mock static methods. So, for example, if you have a
AuthorizeNet class that has a static method ::submit(), if you test the code
then every single time you run it you're pinging Authorize.net's servers,
which opens you up to a world of hurt.

Properly mocking methods allows you to get rid of this unknown and say, "The
submit() method will return an array of this specified data" without
Authorize.net ever getting a ping.

With static properties, the problem is that they _do_ have memory. If you
change it in one place in your codebase, that static property will then be
changed across your whole codebase for that execution, even if you have
multiple, separate object instances.

~~~
wanderr
Perhaps I'm missing something, what about static methods prevents you from
having a mock AuthorizeNet class implementing the same interface but with a
submit() method that just returns fake data? Perhaps there is something
specific to the testing framework you use that makes this clunky?

As far as static properties go, if you're mucking with those you're back into
the world of storing state, which OO is more suitable for, but the whole point
is to avoid doing that wherever possible. :) What I was getting at before is
that we really use a mixture of both real OO and procedural with class-
namespaces-static-methods wherever each thing makes sense, but given the
nature of what most backend PHP is trying to accomplish, the latter ends up
being the majority.

~~~
jtreminio
I am completely against create actual files to make mocks.

I use PHPUnit, the de facto standard for testing php code.

To create a proper mock in it, you use getMockBuilder()

~~~
Kiro
Why can't you use getMockBuilder() for static methods? (I don't know PHPUnit
so maybe it's a stupid question.)

~~~
jtreminio
These tools only work when:

1) You've implemented dependency injection, or

2) You're using a container

For example, in PHP you can't mock something like "$foo = new Bar();". The
code is right there, it's saying exactly what it wants, you can't return a
fake class (unless you do some ugly magic).

However, you can pass in an object that is_a Bar, either injecting it via DI
or storing it and then retrieving it from a container.

With code like Foo::Bar() - that's it. You're tied to the Foo class, Bar()
method and you can't change a thing about this.

~~~
contingencies
Procedural testing isn't hard.

All that dependency crap is only a result of your
_AbstractTestingFrameworkMethodFactoryClassMockMethodGenerator()_ and
similarly useless abstractions, anyway.

A simple module system can be implemented in a single function and referenced
from test code as easily as:

 _test_requires( 'module1','module2');_

Purely procedural tests are as easy as:

 _assert_equals(function_one( 'example_input'),'expected_output');
assert_not_equals(function_two(true),false);_

Full featured test framework:

 _function assert_equals($a,$b) { return $a==$b; } function
assert_not_equals($a,$b) { return $a!=$b; }_

(Edit: I don't believe I missed the point - 'dependency injection', a recent
term in PHP, essentially means tightly coupling to an entire DI system instead
of directly to a single dep as demonstrated above. Either way, loose coupling
is a concept to strive for as far as reasonably possible - not an absolute
requirement. If your code requires something else, then it requires something
else. The solution is not to create a _new
AbstractPretenderOfTotalWorldVisibilityEvenThoughControlFlowIsNowAllOverTheShop()_
After all, if you carry that tight coupling argument further you could claim
that by virtue of writing PHP at all you are tight coupling to a certain, if
broad, class of processor architectures. There has to be a limit somewhere!
Mostly, that's determined by legibility/maintaintability and programmer time,
not by abstract measures of correctness.)

~~~
bencoder
I think you've missed the point. If your procedure calls other procedures, how
do you test its functionality individually? How do you know if the problem
exists in the procedure itself or one of the procedures it calls. Without DI
in some form you are stuck with your procedures being tightly coupled
together.

------
ChikkaChiChi
Can anyone please point me in the direction of an open source project on
Github that can showcase to me the 'elegance' of all these other programming
languages that have the scale and adoption of some of the more well-known PHP
community pieces?

I feel like so much of the bias towards PHP is either an unfair comparison
(language to 'rails') or a bad taste left in the mouth because the person
worked with a nasty domain specific language like Wordpress, Drupal, Magento,
etc.

PHP is like pop music; there is a lot of it and 'true' artists think it's
beneath them. Nevertheless the public demands and craves it, and most of the
big web applications that are open source run on PHP.

If you feel like PHP is a blight on the world, by all means go out there and
disrupt the community by launching something that gets widespread adoption the
way PHP software has.

~~~
lmm
> Can anyone please point me in the direction of an open source project on
> Github that can showcase to me the 'elegance' of all these other programming
> languages that have the scale and adoption of some of the more well-known
> PHP community pieces?

Just look at MoinMoin's source and see how much more elegant it is than
MediaWiki.

> either an unfair comparison (language to 'rails')

Why is that unfair?

> a bad taste left in the mouth because the person worked with a nasty domain
> specific language like Wordpress, Drupal, Magento, etc.

If that's how PHP is used in practice then it's fair to complain about PHP.

~~~
adamors
> Why is that unfair?

Because PHP isn't actually used like that. Most engineers use frameworks (like
Symfony, Zend, Yii, Cake, Laravel etc.) or at least components of these
frameworks if they work on something very complex. NIH is a thing of the past.

> If that's how PHP is used in practice then it's fair to complain about PHP.

If shitty developers use a language then it's fair to complain about said
language? Really?

------
gfodor
I feel like the reason you don't see a web app development model that takes
from the best ideas from both PHP model and the Rails/Django model is because
by the time you've been exposed deeply enough to both of these approaches to
truly understand the benefits and flaws of each you are way too cynical and
burnt out on the idea of tooling around building "the next big web framework."
Instead, after watching trends come and go, you just take whatever you can get
for free and go out and solve real problems with it.

------
mVChr
I'm preferentially a Python programmer who is currently working on a large
well-known high-Alexa-ranked website that uses the LAMP stack. The site has
been around for a while and is a behemoth, so I understand why it has stayed
with these technologies despite the fact that there are many people on the
project at this point who'd prefer otherwise. There are both ugly workarounds
and rambling boilerplate in several places due to limitations in both PHP and
MySQL, and there are also other ugly portions of the codebase due to
inexperienced developers or bad legacy decisions that haven't been fully
refactored (not the fault of PHP or MySQL). However, there is also a good deal
of work that is well thought out and architected so I no longer have as many
qualms about PHP as I used to (that I now realize was due to being thrown into
codebases that were just a mishmash of crap... there do seem to be more of
those in PHP than in other languages, but that's just my personal exposure).

All the same, if you're not inheriting a legacy codebase, I don't think there
is any reason to use a LAMP stack on a greenfield project that you will be
creating tomorrow. There are just too many better alternatives out there.

------
sil3ntmac

        > Facebook’s PHP Codebase
        >  x * 105 files
        > y*107 LoC
        >  10 releases per week
        >  Anecdotally, good engineers are astonishingly productive in PHP
    

Erm... are you kidding me? LoC != productivity, not even close. And it goes
downhill from there :( I really, really don't want to rail on PHP (people do
that enough, it gets old, yada yada), but you're kinda asking for it here. The
only useful point made is about state, although that's a double edged sword.

...Fuck it, I'll rail. It's 2013. Do yourself a favor. Use something better
than a horribly inconsistent glorified cgi script.

~~~
Joeri
That's a very unfavorable reading of that slide. Who are you to say they are
wrong when they talk about their own anecdotal experience?

Speaking anecdotally, I got exposed to PHP before I did to Python. I tried
Python after hearing how much more amazing than PHP it was. I understand why
people say that now, because Python has a "flavor" that I suspect most
programmers find more pleasing. I also learned another thing: I am not more
productive in Python than PHP.

PHP, like JavaScript, is a language constructed out of good parts and bad
parts. They both suffer from the same ailments. It is painfully easy to
construct code examples of their horribleness, there are mountains of bad code
floating around the internet, they lack essential facilities like strict
typing, many facilities that they do provide should be carefully avoided, and
the overall flavor of the language is just plain weird. However, PHP, like
JavaScript, allows you to be remarkably productive.

JavaScript got out of the doghouse when Douglas Crockford wrote his book and
converted the JS community to the jslint style of programming. JavaScript
didn't change, but the perception and practice of it did. I think PHP needs a
similar champion who is willing to say: PHP can be a good and proper language,
provided you use it correctly, and btw here is a tool that tells you whether
you're doing that in your code.

I am a PHP programmer, and to your high and mighty attitude I say: screw that.
There's nothing wrong with being a PHP programmer.

~~~
sil3ntmac
Sorry. I got bitter there at the end, it was uncalled for. I spent 3+ years as
a PHP programmer, there's _certainly nothing wrong with being a PHP
programmer_ , but it's hard to argue that in 2013 it is still a good and
productive platform to learn. It pains me to see newcomers starting out by
learning PHP, they are essentially shooting themselves in the foot for at
least a year of their life (if they are going to be a professional web dev). I
was pretty productive at PHP, but only because I cut my teeth for years
writing shitty cgi-style PHP scripts, learning the abortion they call their
stdlib, then using PHP's OOP crap and finally using frameworks like CI.
Imagine if I had spent that time writing ruby. By the time you get the whole
way through, you realize that your "high-level language" _should do work for
you_ , not the other way around. I think what it comes down to is that PHP
does not mandate good design patterns because it cannot even decide on one
itself. Once I understood this, the language was forever tainted.

I think the only reason PHP is still relevant is because it's so damn
accessible (kinda like w3schools), every shared hosting provider under the sun
gives you apache+php, and when you're starting learning web programming shared
providing is the way to go.

Why do you say php and Javascript suffer from the same ailments? They suffer
from _a few_ of the same ailments, like a crappy/confusing stdlib (although
you don't see mysql_real_escape_string in javascript's API) and funky
invisible type coercions. Lack of true OOP in javascript, though confusing to
beginners, is a design feature as far as I'm concerned, prototyping gives you
the tools to implement OOP however you like. But javascript has had a known
design pattern from the beginning, which is very powerful and useful once you
learn it. I strongly doubt a (another?) phplint at this point would change
anything.

As for the "anecdotally" slide, I read the last statement as a conclusion of
the previous stats, which didn't make any sense to me. Either I am completely
misreading it or you are taking the phrase "anecdotally" far too literally.

------
fsniper
Please don't flame war. If you do not like PHP do not use it. Don't force
another language to someone else's throat.

------
shire
Idk about you guys but I love PHP. After using new technology for Web
Development PHP makes me feel nostalgic. I really enjoy PHP's ease of learning
for Web Development. It's easy to understand Databases and Server-side
programming using PHP than it is using Ruby on Rails, IMO It feels like magic
using Ruby on Rails.

------
dribnet
This was an interesting talk. My own interpretation was that PHP's strengths
were claimed to be:

1) State => because endpoints have no persistent state

2) Concurrency => because there is no concurrency model

3) Transparency => (1) + (2) + fast reload = easy to understand

These combined give the language nice programmer "ergonomics" (Keith's
terminology). It also limits the collateral damage any particular change to
the codebase can have which allows Facebook to more confidently deploy
multiple times a week.

~~~
Joeri
I think PHP's strength is that the default way of how sessions work makes you
intuitively build shared-nothing architectures that parallellize easily and
have session data that is hard to corrupt. Sessions are locked at the
beginning of the request, and the changes are committed atomically at the end
of the request. The next request by the same user is blocked until the session
is unlocked. This means that any error causes a rollback to the last known
valid session state, and that it is basically impossible to have concurrency
bugs (though obviously a PHP server can handle more than one request at a time
if they're coming from muliple user sessions). A PHP app that gets an error
will typically recover just by pressing F5, whereas in other platforms often
you have to log out to throw away corrupted session data. I had little
appreciation for this myself until the PHP app I work on reached the point
where it had both a large codebase and a large userbase.

Remember also that a large part of the reason why facebook won over its
competitors (friendster and myspace) was technology. Both myspace and
friendster had trouble scaling up their featureset at the same time as their
userbase, whereas facebook pulled it off relatively well. It's hard to know
without inside knowledge whether PHP had anything to do with that, but it
obviously didn't prevent facebook from winning.

------
Xorlev
It's a strange, strange world when your code has more gravity than the
language it's written in and you start warping your language to fit your view
of it.

I'll be the first one to take a swing at PHP, but Facebook has done some
awesome things with it. I used to program in PHP and it does have some really
nice bits...I mean, it's hard to fathom not waiting for my container to start
anymore and go back to the days of save/reloading.

Cool. Nice link, OP.

------
fmitchell0
a better link:
[https://docs.google.com/viewer?url=https://raw.github.com/st...](https://docs.google.com/viewer?url=https://raw.github.com/strangeloop/StrangeLoop2013/master/slides/sessions/Adams-
TakingPHPSeriously.pdf)

------
maerF0x0
I like the look of this "hack". It adds things to PHP that I missed from C# ..
now if they will add Accessors syntax, that would be nice, especially for
those that use Doctrine2. PHP is as professional of a language as the user. I
found fun working with PHP, C#, (node)js, python and think each has its own
way, quirks and benefits.

~~~
Joeri
You can easily add something like accessors using traits. I cooked this up in
5 minutes:
[https://gist.github.com/jsebrech/6740010](https://gist.github.com/jsebrech/6740010)

You can do a lot with meta-programming in PHP. For example, you can write your
own array type if you are so inclined and use it anywhere you would use an
array. Here's an experimental library that showcases the meta-programming
abilities:
[https://github.com/jsebrech/php-o](https://github.com/jsebrech/php-o)

~~~
maerF0x0
i can do something interesting with __set and __get , but i really just want
it to be part of the language. Nice ideas in the meantime tho.

------
dancecodes
PHP must be more functional and use concepts of Functional Programming but
without lost current features.

------
zeuben
[http://www.phptherightway.com/](http://www.phptherightway.com/)

------
vinight
obligatory X is better than php flames on the way.. php just works.. end of
story

~~~
harshreality

      $productid = "0x4zz5";
      print $productid + 4;
    

If printing "8" is your idea of a working interpretation of that code, then
PHP is the language for you.

If not, then PHP doesn't work. End of story.

~~~
memla
Things like this and some interesting developments from Facebook concerning
them are mentioned in the presentation, so it would be nice if people would
actually discuss that. Just a suggestion.

~~~
jasonlotito
It's PHP. Unfortunately, enough developer got bit by the fact that PHP doesn't
prevent you from shooting yourself in the foot, and shot themselves in the
foot.

So, you'd probably be pretty ornery too when other people had more discipline
to use the language without shooting their foot and were also employing it
successfully. You'd probably want to make assumptions, and word hard to
belittle them. Insult them.

And they'll talk about beauty. And zen. And wonder, and joy in a language. And
they'll gloss over the major problems that it suffers from. They'll imagine
all is well. And they'll try and tell you that nothing good can come from the
tool they once used to shoot themselves in the foot.

Just walk away. Because you still have two feet.

~~~
justinhj
PHP may have a bunch of ways to shoot yourself in the foot, but you get a new
foot back right away. IMHO the oddities in PHP rarely hit you, and when they
do you'll pick it up right away in PHPUnit, fix it, and walk away.

~~~
jasonlotito
Sorry, maybe it wasn't clear, but the professional using PHP was the one
walking away. =)

~~~
justinhj
Yes I think I misunderstood, thanks for correcting.

------
dancecodes
dont see any PHP Seriously.

Its just baby garden. Im sorry.

PHP will be Seriously if will use major Erlang features: processes, pattern
matching, atoms, lists, tuples

~~~
krapp
So what you're saying is... the language that's holding about 80% of the web
together isn't worth taking seriously... because it isn't Erlang? Remind me
how many sites are built in Erlang again? Why would lists and tuples be
critical in generating html files?

~~~
dancecodes
sorry for my English I just mean about these pdf - saw but not see any
seriously. I mean that PHP is very seriously but I want some features of
Erlang. I love PHP and programming with it but I need pattern matching and
long running processes.

Tuples need because they more simple for understand and matching then lists
and strings. Tuples can simple converts to lists and back. Tuples more
effective with memory.

Only one class can implement tuples now its SplFixedArray. But there bugg when
you call createFromArray in own custom class derived from SplFixedArray. Also
with small count uts slow.

Try test Erlang and see his power. I hope you think will too, that PHP needs
with Erlang features.

~~~
krapp
Alright, my mistake then.

I'll look at Erlang. I'm trying to wedge self-teaching Python into this
semester.

~~~
dancecodes
If you need some help for any info about initial Erlang ask me.

For start:

[http://www.maht0x0r.net/library/computing/erlang.pdf](http://www.maht0x0r.net/library/computing/erlang.pdf)

[http://www.erlang.org/erldoc](http://www.erlang.org/erldoc)

[http://rosettacode.org/wiki/Category:Erlang](http://rosettacode.org/wiki/Category:Erlang)

[http://ruslanspivak.com/2007/09/09/erlang-for-python-
program...](http://ruslanspivak.com/2007/09/09/erlang-for-python-programmers-
part-i/)

and you need emacs24+ for good ide and programming with erlang or just use
interactive shell erl for initial start.

------
hayksaakian
> mysql_escape_string vs. (sigh ) mysql_real_escape_string

ouch

~~~
bilalq
I don't think bringing up deprecated functions is valid criticism. Everyone
uses PDO these days.

~~~
duskwuff
Everyone _should_ be using PDO these days. Whether they are is another matter.
:(

~~~
theOnliest
I work in a large educational institution, using PHP and MS SQL Server, and I
can't convince the sysadmins to install PDO because the SQL Server PDO
bindings have a big red EXPERIMENTAL sign on the page
([http://php.net/manual/en/ref.pdo-
dblib.php](http://php.net/manual/en/ref.pdo-dblib.php)). So I'm stuck using
'mssql_' functions, I'm afraid.

~~~
tmister
You can try the driver released from Microsoft
[http://sqlsrvphp.codeplex.com/](http://sqlsrvphp.codeplex.com/). Haven't
tried it myself though.

------
mrjj
Good title for a joke. Idea of serious coding on templating engine can't be
serious.

