malterisio777

Please let me do a little explanation of the title first. Japanese is an
interesting language where context is vital to the meaning of a word.
Sayonara usually means a simple "good bye", but within a different context
can mean "we'll probably never meet again".

To understand this mail you'll have to know that I was just another user of
PHP, an user that was probably too eager. I wanted to get more involved with
the development of PHP as I do believe in all the philosophy of open-source.
In the end I found my attempts ended in frustration, but, nevertheless, I
learned a lot in just a few months. I don't want this mail to be one where I
get to display all my frustration, instead I want to leave here all my
findings, the things I researched, the few things I managed to actually
code, and mostly the ideas that someone else might find useful.

---- To those who may want to involve in the php internals ----

For those in the generals list that may ever try to venture in the internals
of PHP, remember that you have to back your point of view with a patch. So,
sit down, remember the old days in college using the c compiler, and code
like a cowboy before trying to promote anything in the internals. It's the
status quo of the PHP development community, as I did learn too late.

---- Namespaces: function imports ----

Here is the patch to add function imports to 5.3. To be consistent constants
imports have to be added too:

http://martinalterisio.com.ar/php5.3...tion.v2b.patch

If you don't know what imports are, they are just a way to refer to a longer
name with a shorter name. For example:

<?php
class MyRowset extends Zend:b::Table::Rowset::Abstract {
....

or with imports:

<?php
use Zend:b::Table::Rowset::Abstract as Rowset;
class MyRowset extends Rowset {
....

The use statement behavior currently supports only class names aliasing.
Functions and constants have to referred with full name, although these too
can be namespaced.

---- Import statement is broken, why, how can be fixed ----

While doing the previous patch I realized that the use statement is broken.
It should generate and error when you try to override an existing name. But
the use statement is handled at compile, where it's unknown if a name will
be overridden or not. What happens is that the error might be triggered
depending on the conditions and order of compilation. If you have an opcode
cache, this error may not appear until the cache is invalidated.

On a suggestion by Dmitry, which I really don't know if he knew about this
issue with use or not, but, anyway, his idea solved this issue, I made this
patch:

http://martinalterisio.com.ar/php5.3...cope.use.patch

With this the use statement is checked only against the names used in the
current file (or namespace if using multiple namespaces per file). Since the
imports only affect the current file, this is more sensible, and the issue
mentioned before disappears.

---- Name clash and ambiguity issue introduced by namespaces ----

There's another pending issue with namespaces, there's a name clash that
currently goes undetected, and makes static methods partially unavailable.
This is due to the fact that using :: as namespace separator generates
ambiguity. foo::bar() can refer to the static method bar in class foo, or to
the function bar in the namespace foo. This is an issue to php library
developers. Someone can inject a namespaced function which overrides your
static method.

One possible solution I approached was to prevent the name clash altogether,
but I found this approach inappropriate for 2 reasons: the performance
impact is too big; is not consistent with how other name clashes are handled
in php (classes and functions may have the same name).

Another approach, which I believe is the correct one but never got the
chance to implement in a patch, is to change the order of name resolution,
search first the static method and then the namespaced function, and if the
user wants to refer to the function he can import the function. This way
both remain accessible although the user has to solve the ambiguity. Also
this reduces the impact of adding namespaces on legacy code, since there's
an impact to all static method calls (because first the namespaced function
is searched).

---- Reducing impact on performance introduced by namespaces ----

I found out that although the philosophy behind the namespaces
implementation is to do as much as possible in compile time, but much is
pushed to the executor. Those could be solved on compile time. Much can be
optimized changing the name resolution rules. If these become more explicit,
the compiler can discern which is the actual name that's referred to. As of
now, it can be optimized using imports and explicit names, which are used as
alternative notation. In other words, the normal use of namespaces is not
optimal.

There's still one name resolution that seems inevitable that it will fall to
the executor: the ambiguity mentioned earlier between static methods and
namespaced functions. This could be solved by the user if the use statement
allows to also explicitly indicate the type of import: use class X; use
namespace X; use function X; use const X;

---- Fix name resolution rules for better coding practices ----

Also, as of now, I'm more than confident when I say that the current name
resolution rules will bring much headaches to users. For starters you'll
have to make a habit of prefixing :: to all internal function calls (such as
::count, ::strlen, etc). This way will be safer for creating php libraries,
since another user could inject a namespaced function that overrides those
functions. This is because the function call without that prefix will try
first a function in the same namespace then the internal. Also, for this
same reason, using the :: prefix will be faster (since it's solved at
compile time). And if you want to refer to an element of the current
namespace, is better to use namespace::


http://php.net/language.namespaces.rules

What I wanted to implement but will never get the chance is name resolution
rules that aren't context aware and explicit:

foo(); // is always global foo (except if foo is an alias)
new A(); // is always global class A (except if A is an alias)
A::B(); // try static method of global class then namespaced function
(except if A is an alias)
namespace::foo(); // is always foo() in current namespace
new namespace::A(); // is always class A in current namespace
::foo(); // is always global foo (aliases ignored)
new ::A(); // is always global class A (aliases ignored)

I think this will improve readability, maintainability and debugging,
because of its explicitness.

---- Autoloading issue with namespaces ----

There is also an issue with autoloading and internal names with the name
resolution rules. The autoload has to be the last thing tried, therefore
even if there's a namespaced name that overrides an internal name, it won't
be seen if its loading its subject to autoloading. That's also another
reason to change the name resolution rules. With the rules I explained
earlier there won't be this issue with the autoload.

---- Possible enhancement for autoloading with namespaces ----

Regarding the autoloading, I think there's an enhancement that can be
achieved with the implementation of namespaces. Consider the possibility of
a namespaced __autoload(). Autoloading in PHP has one important issue: as
the system grows, and external libraries grow, the complexity of the
autoloading increases. Using the spl autoloader, each library adds its
autoloading. If you have many libraries, autoload can cost too much. If a
namespaced __autoload() is implemented, this can reduce the impact by
distributing the autoloading behavior, ie, first use the namespace autoload,
then try the global autoload. A package should know better where its classes
are.

---- Constrained scope for imports is unpractical ----

When trying to refactor code to use namespaces, as a test, I also found that
having the use statement limited to outer scope is unpractical. One
necessary addition, which is not very complicated, is to have an extra scope
for use statements, such as imports in a function scope. It's only a matter
of keeping an extra table for the function scope in compile time.

---- Namespaces keyword issue, it can be solved without taking a keyword
----

There's still the issue of the keyword taken by the namespaces
implementation. It doesn't matter if it's "package" or "namespace". Both are
keywords widely used in php (use google code search if you don't believe
me). I know they have tried to remove the need for the keyword, but I still
think there's a way. Consider the following:

<?php
class Foo::Bar { use bla::bla; }
?>

Instead of:

<?php
namespace Foo;
use bla::bla; class Bar { }
?>

In the first there's no need for namespace declaration, it's declared with
the class name. The same can used for functions and consts:

<?php
function Foo::test() {
use bla::bla;
} const Foo::CONSTANT = 101;
?>

This approach restricts namespaces to classes, functions or constants scope.
If you want to execute code in a namespace you'll have to be in one of these
scopes. But, I think it's a restriction one would pay in favor of all those
libraries that will break because they use the fatal keyword (think of all
the XML related libraries that use "namespace").

Also, using namespace:: or package:: doesn't need to take a keyword (think
of self:: and parent::, they aren't keywords just special names that can't
be used for naming classes).

---- Namespaces as nested classes? ----

Reading about how the previous implementation of namespaces went down the
drain, one recurring though in some users and developers caught my
attention. Maybe namespaces and nested classes should be one and the same
thing in php. Considering that many are using classes as namespaces for
functions, this is not such a illogical approach to the problem. I have not
much considered the technical feasibility of this approach, but one that
would be probably needed is the ability to forward declare members. Without
this, all definition must be clustered.

Example:
<?php
final class A { // should be final to have nested classes?
public class B; // forward declaration }
?>

other file:
<?php class A::B { }
?>

I can't say much about this approach. It's just one wild idea.

---- Type hints, improvements could help drastically improve performance
----

I thought much about type hints. Right now they are only seen as syntactic
sugar for system designers, and something that reduces performance. Actually
quite the opposite can be achieved, but not with the current implementation
of type hinting. The guys behind flash 9 obtained a 10x improvement in
performance thanks to type hinting. Actually doing the same with PHP is
quite sensible, since one of the bottlenecks for performance is the zval.
Knowing before hand that the variable is a native type, a just in time
native compile can be done to drastically improve performance.

For that to happen first type hinting must be improved. Here are some
thoughts I shared with another user some time ago:

http://martinalterisio.com.ar/php5.3/php-typehints.txt

---- Taints ----

Last but not least, I thought about taints. Since PHP6 will remove safe mode
and magic quotes, as far as I know, if nothing else is there to prevent
users from being users, well PHP6 might be considered too insecure. Taints
should be the solution to this, but approaches copied from other languages
seem not feasible in PHP. Variable level taints are not the way to go: not
much can be added to zval without suffering the consequences, and a simple
model of tainted/not tainted is not safe enough, as there are many taints to
be considered (XSS, SQL injection, HTML injection to say the least).

I think one possible approach to consider is scope taints. Instead of
tracking taints on variable level, do it on scope level, ie, attach taints
to functions, classes, global scope. Taints should be an arbitrarily sized
list of elements, where the user can also add taints of his own (we don't
know where security holes might appear in the near future, so let's leave
that door open). Taints tracking is to be attached to classes, functions or
global scope (methods use class scope).

When function or class code refer to another scope (function call, method
call, member access, global access) a pollution occurs. In a pollution the
involved scopes become infected with taints from both. The pollution
operation needs a new opcode that can handle a reference to scope either
statically or by an object reference. For each function/class the user has
to be able to mark taints that infect them, which taints they can
handle/resist, and which taints they reject. A function/class ignores
pollution by taints that can handle/resist. If a function/class is polluted
by a taint that rejects, an error occurs. Internal functions should define
also how they are affected by taints, and some defaults taints be specified
for known security issues.

The problem with this approach is that is not an automagical solution. It
requires the user to be conscious of the security issues. If he does nothing
about it an error occurs, but he can mark the scope as one that handles the
taint and still do nothing about it.

There's two alternatives to how keep track of taints:
1) keep a list of taints that pollute the scope
2) keep a list of taints that DO NOT pollute the scope

The second alternative is harder to understand. It assumes that any scope
cannot be trusted by nature. Instead of adding threats, you remove threats.
I think this approach is more secure.

---- The end ----

Well that wraps it all, I think. That's as much as I can download from my
brain which is related to PHP. Do whatever you want with all this, even the
spam folder is fine.

Anyway, it's been fun, and I learned a lot.
My thanks to everyone that ever gave a hand.

A former PHP user says to you all:

Sayonara PHP

P.S.: Please be understanding if I don't answer replies to this email.

gmane

Hi,


Snip of interesting technical stuff.

While I'll admit I've not fully read your mail due to it's relatively
in-depth and technical nature that I'm not really up-to-speed with
regarding the internals of PHP, it did strike me when skimming the mail,
that you've not really covered your personal standpoint now.

You state some interesting technical about how namespaces and such
will/could work in 5.3 (something which I would personally welcome with
open arms (especially as I've coded around the autoloading issue with
other techniques involving regexps of class names and other such
slightly nasty things (although acceptable if you used good prefixes on
all your class/interface names)).

But you also say you're leaving PHP (if not for good, at least for now)
and you don't really say why, other than referring to the hard initial
entry to the internals community.

If you would be so kind, I think it would be interesting to say why you
have decided to move away from using PHP (and what you are now intending
to use!). I think it would help the PHP community grow stronger with
this kind of information as much as the technical information you've already given.


Wishing you all the best.

I appreciate this may not get an answer

Col

agrobinet

Well, my fellow countryman... one of my classmates at college had a saying:
"el hombre es un animal de costumbres" (translate it "you gringos" - no
offense). And I guess it's most of the time like that... we learn something,
we are never willing to unlearn it. But the truth is, there are at least as
many habits and learnt behaviors as people are there walking in the streets.
So, sometimes, we should be a bit more tolerant to "foreign habits" (unless
we are Micro$oft.. but even so...).

If my intuition is right you must come from the Java/C++ world (my bet is
java 80/20). Maybe you have evaluated the hassles of implementing namespaces
into PHP... and you have concluded it's not possible. Or maybe, that it will
be a "buggy implementation" in the end; like PHP 4 OOP (which doesn't look
like OOP at all). Maybe some old-seasoned gurus in the internals community
have set you apart, or have treated your opinions with contempt (this is
just my assumption, like most of this email's contents). So, you are now
assuming that you won't need PHP, and that it will 'die("alone")' like some
poem of your authorship stated in one of its verses. Yes, after all
developers find out the hassles of namespaces and type hinting in PHP, they
will give up... won't they? (just reading your mind... forgive my arrogance
and continue).

You know... I think I'm about your age (judging for the picture of yours at
phpclasses.org, if that's your picture). Maybe a bit younger, or a bit
older... but just a bit. And the thing is, I heard about two years ago or
so, a big buzz around a "PHP replacement". It was something about trains
(that's the farthest understanding I reached on it... "something about
trains"). I think it was called, railroad, or railway, or diamond on a
train... mmmm... nope, now I remember, it's "ruby on rails" (if you have a
sarcasm detector, use it now). Last time I checked, it was still alive...
arguably in a much more evolved fashion, and some (may I say "few"?) hosting
companies support it now. I don't know much about current statistics, but
I'm tempted to say that:
- There are many more Books on PHP than on RoR
- There are many more PHP hosting offers than RoR's counterpart (even if we
reduce the stats to PHP 5 - just a guess)
- There are many many more websites built on top of PHP than the RoR's
counterpart
- There are many many more extensions, APIs and Frameworks for PHP than for
RoR (actually, RoR IS a framework itself)
- There are many many more PHP developers than RoR developers
In the shared market niche, PHP has beaten java, coldfusion, asp, and perl,
which already existed. PHP has survived .Net rumbling, despite the Vb, C#,
J# or C++ flavors and the awesome Vi$ual $tudio IDE. And despite all the
predictions and prophecies about PHP's doom... it is still here, and will be
here and in the top 5 for at least 10 years. By the time PHP is replaced by
RoR or anything else, I will probably be selling RoR T-Shirts, or be
retired, or be dead (maybe of lung cancer, or cirrhosis, or just because
no-one can live past 120's)...

The point is... "sayonara PHP" means "sayonara most new clients" right now,
sayonara "sustained trend", sayonara "all php-based solutions" and sayonara
"most of the web development world". The facts show that googling for "PHP"
throws about 8,830,000,000 results (this is a bit biased, but the point
still holds)... try to Google for anything else and get similar numbers.

So... why not just saying "sayonara PHP internals" if that's the scenario in
which you've had trouble? (meaning, bad luck, not lack of skill). I've seen
some of your code, and though I don't personally use it, I find it
interesting. And I don’t use it because I see no need for it; RIGHT NOW,
most of my company's projects are either small or already work with a
framework of some kind. I think I know why not "just sayonara PHP
internals"... because "I know how this or that should be, I want to turn it
into the way I think it should be... and as I can't do that, because someone
or something prevents me to do so... I feel frustrated and I just give it
up". Again... just (wrongly?) reading your mind.

Now, it's like you couldn't live without namespaces, could you? We've all
being living without namespaces so far... and we've all lived with PHP 4 OOP
so far. And it was even harder for me... I come from the Delphi world and
had previously done some bit of C++ too. So just imagine that when I
switched from Delphi to C++ I was expecting a (SINGLE!) VCL... and a form to
place the UI elements... oh and a "use MyUnit" kind of magical syntax
(instead of “include <whatever>” or "using namespace std"). But I had to
live with that... and finally I got used to the good and bad of C++…
somehow. Then, I started making my first steps into PHP and the web, and
immediately thought “similar syntax, supports OOP… will be easy”… but I had
to drop and/or rewrite all my “first attempt” code because it just happened
that the client for which we where working had a hosting of it’s own with
PHP 4.2 and MySQL 3.23 (there are still some of those archaic hosting
packages over there… I don’t need to tell you). So, I just had to get used
to this “new OOP” of PHP 4 (which is almost no OOP at all).

All in all, my fellow countryman, I guess that unless you have a huge
positive bank account balance, and you drive a BMW (I don’t like them
anyway…) you’d better off tolerating PHP for this little “namespace issue”
if you want to stay in business. Unless, of course, that you have an
incoming contract to develop a core system for an NSA mainframe. And if
that’s the case please tell them I prepare the most awesome “mate”
(http://en.wikipedia.org/wiki/Mate_(beverage)) in the world, and that you
cannot work without it.

I know that, even if you wish to leave PHP forever, you’ll come back… all
the roads will lead you to it. So, you’d better take a smart decision now…
than have no other choice in the future (... ok, that was kind of The
Godfather’s script, lol).

Enjoy your holidays,

Rob

Andrés Robinet | Lead Developer | BESTPLACE CORPORATION
5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale, FL 33308
| TEL 954-607-4207 | FAX 954-337-2695
Email: info@bestplace.net | MSN Chat: best@bestplace.net | SKYPE:
bestplace | Web: http://www.bestplace.biz | Web: http://www.seo-diy.com

malterisio777

2007/12/26, Colin Guthrie <gmane@colin.guthr.ie>:


Well, it was my intent not to say that in particular because is rather
personal. I just wanted to pass on all the things that may be of some use to
another developer.

If you must know, there are three reasons why I'm distancing myself from
PHP.

1) I'm tired of web development as a whole. Too many clients which do not
understand what the web is. Too many opiniologists who should know what the
web is but talk about a second web, which is nothing more than the old web
with logos on shiny floor. It feels like the bubble all over again (luckily
I was too young to be affected when the first happened, now I cannot say I
won't be affected).

2) I started in the business of software development with a dream that I was
told afterwards it was childish and immature. Now I've learned enough to
know that my dream, being a game developer, it's neither childish nor
immature, totally the opposite, it's probably the most serious and important
job in the whole software development industry. I wanna give it a try
chasing that rainbow.

3) I'm not so sure anymore if PHP is profitable as a language choice for web
development. The small and medium projects market is becoming infested with
developers who I cannot compete anymore in terms of cost, and software
quality is something this market did not yet got a grasp on. Big projects
market has scalability requirements that aren't easily met on PHP grounds,
and if it does, the cost is code quality or performance, two things that
this market doesn't easily overlook.

Right now, the future of web development is mostly uncertain, too many
things are happening too fast. If I had to I would bet on Java for server
technology and Flash for client technology. The performance of Java6 have
left PHP and the many other scripting languages panting for air way way
behind. And its scripting API has engulfed all the good things about
scripting languages into its domain. And yet the most important thing about
Java is its scalability. Let's be honest, how can anyone expect to beat Sun
in its own turf (networking)? Anyway, PHP developers, remember this word:
"Quercus".

And the Flash guys pulled a rabbit out of the hat and called it Flash 9.
They broke every compatibility known to developers, but finally developing
for Flash doesn't suck. And also, they are going with the open-source
approach as the Sun guys did (I pity the poor graphic designer, he still has
to get a commercial license to author some content for the flash
environment). And we have now many tools to apply the AJAX technique and
DHTML easily, but I would still beat the crap out of anyone who thinks that
building a thick client on HTML DOM and javascript is a good idea.

On the other hand, there hasn't happened anything important on the PHP
frontier, except for the PHP4 EOL and the Zend Framework (IMHO the first
real framework for PHP). And the most annoying thing is this stupid marriage
PHP/MySQL that keeps on going. The moment was appropriate for PHP to end
this relationship and PDO was a good step towards this. You'll probably have
heard or will soon hear about mysqlnd, and many will think "yay! mysql
functions are again part of the core!!! and they're faster!!!" and I would
be thinking "damn! open source php projects will be tightly tied to MySQL,
AGAIN!".

Anyway that was much of a rant. The short version is "I liked the php
development market because it was safe, but now I doubt its safety".

That's all. I don't think that rant may be of use to anyone, but at least it
felt nice to let go of some steam.

Best Regards and Happy New Year,

Martin Alterisio

malterisio777

2007/12/26, Andrés Robinet <agrobinet@bestplace.biz>:

Well, it's been years since I've done anything important in Java or C++.
I've been doing mostly scripting languages in all sorts of flavors.

I don't really care that my opinion felt to /dev/null or something else, I
just kept trying, and when I understood that I had to get my hands really
dirty to be taken into consideration, that's what I did. The short time I
had been dwelling through php source code, I finally understood why the core
developers have such a short temper. To be fair with the core developers,
the php community should issue a "thank you for keeping php running" email
each week.

The poem! That was fun! =D
It's not an assumption that I won't need PHP, it's just that I wanna try
doing something that's far away from web development and php. It would have


sensible or useful in there, he can just take it. That was my only
intention.

I don't expect developers to just give up. I expect them to (a) accept them
and continue doing as always (b) ignore them (c) complain (d) use them
wrongly. I'll go for (d) if you wanna bet.

You know... I think I'm about your age (judging for the picture of yours at


Please, don't let me get started on the Freaks on Rails.

RoR is a stillborn baby. It wasn't just bad enough that the RoR developer
failed while doing the first video presentation of RoR. People still kept
boarding that train. And it become worst, people from PHP started to think
that RoR was actually a good idea to be copied.

There are two major faults with RoR:
1) The MVC design pattern is not applied correctly
2) The whole application is designed around the (faulty) MVC design pattern

The MVC design pattern has one purpose and one purpose only, user interface
implementation. RoR forces you to put code that's not pertinent to the
system design because the MVC design pattern is forced on you. You should
never force a problem to fit a pattern.

The resultant is code that's hardly maintainable, mostly redundant, poorly
reusable, scalable only in dreams, and strictly limited.

All the PHP "frameworks" which copied the RoR ideology, had also, most of
the times, copied its faults. Luckily, the Zend Framework was really well
thought, and it is, as I said before, IMHO, the first real php framework.

It's ironic that they choose "Rails" as the name for their abomination. It's
quite appropriate. When you're on rails there's not much you can do, just
one way to go.

The point is... "sayonara PHP" means "sayonara most new clients" right now,


Probably, I'm not sure. But, in this case, yes, I'm saying goodbye to web development. [snip]

I'll tell them, but I'm guessing it won't be easy to pass through
immigration with a bag of "yerba". Last man I heard trying, was almost
body-cavity searched.

xD

I know that, even if you wish to leave PHP forever, you'll come back… all

We'll see... for now I'll follow the stupid decision of finally doing what I
intended when I began this whole dance of software development. I hoping
with all my heart that this will go well and I'll never have to work in web
development again. If not, well, I'll come back to whatever it's that's
being used in that specific moment, be it PHP or whatever may come.

Just know that I'm not leaving for some petty reason. And I really hope that
someone else could find anything sensible in the things I posted in the
first mail, and keep on building on top of them.

Best Regards and Happy New Year,

Martin Alterisio

gmane

Sorry I didn't mean to drag it out of you


That's fair enough really. I'm still enjoying it, even if I'm not always
at the bleeding edge!

Absolutely. I have a lot of friends in that industry and it's definately
a market in which there are lots of opportunities in many different
areas of testing etc. It's hard work and from what I hear long hours,
but it's certainly rewarding in terms of work enjoyment


I think it depends on how you use PHP to be honest. If you're playing
about on small to medium sized projects for clients PHP is an excellent
choice IMO. With the right approach and understanding PHP is also an
excellent choice for large scale projects (Facebook anyone??).

One of the interesting points you make about code quality I think is
true but that's simply because of the low barrier for entry into PHP
coding. Lots of people are self taught and their PHP projects are often
their first programming projects. Even if they've had a programming
background, web projects are often quite different. I know a lot of my
code is crap and I'm now working hard to replace the old bits with new
designs and approaches and am becoming increasingly happy with the
potential for scalability and maintenance etc. so I'm happily sticking
with PHP for the time being for most of my projects.


Well I think this is true to an extent but there are always going to be
several platform technologies out there and I think PHP will continue to
be a major player in that area, regardless of the success of JSP/ASP/RoR etc.

I think this is very true too, but not always. Flash is fine and I think
it will play a key part in some applications I will develop in the
future but I don't think DHTML+JS will die just yet. It really depends
on your application - if you want a funky system for email or another
desktop-like app, then Flash is a good choice, if you just want small
bits of interactivity in your webpage I really don't have a problem with
javascript (especially with the excellent jQuery). Flash has too many
drawbacks in terms of accessibility and indexibility for it to be a
general replacement for all things client side (not that you were
suggesting that). So again, I think there is plenty room for all sorts
of things out there.


Well I quite like MySQL but I am very much in favour of PDO right now. I
think healthy competition is needed in this area to ensure a good degree
of innovation! I'm quite annoyed right now at some of the decisions
MySQL have made regarding their development structure of late but such is life.

I think it's useful to get other people's opinions on things and yours
was very well written and thought out. Not everyone will agree with it
all but some of your points will ring true with some (especially the
non-PHP stuff!). Thanks for takign the time to reply with that info.

Good luck in the games industry

Col

quickshiftin

try telling that to yahoo, or wikipedia, or facebook..
no, php scales just fine. the problem is most people dont put in the effort
learning
how to scale with php. and for those people who sacrifice code quality,
well thats
their own decision and they should be aware of the consequences. if a
business
owner is too niaeve to know, said business owner should be told by a
competent
developer or project manager what risks are being taken.

i would venture to say java or .net are potentially more costly depending on
what
your particular technology mix is. really anything that you can sell, built
on open
source, should inherently be high margin products / services.

i know all about quercus. im on the resin interest mailing list as well.
to be frank quercus has its own problems.
lets face it; java is serious. there are many aspects of java i prefer over
php,
for example the comparatively clean apis provided in the standard libraries.
i dont see java doing so well on the web compared to php though, and i think
php is better suited for the web. if you want to compare them overall in
terms of
what all they can do, eg.
daemons, desktop apps, applets and such; well i think its clear java has
more
and although php does have some ports to the desktop im not one to say
whether theyre any good as ive not used them.
however i shall not stray from my point which is php is well, and ill say
it,
*better* suited for the web (server side) than java. it is also highly
scalable
albiet techniques that arent packaged with the language itself.

btw; i liked you comment about coding c like a cowbow to gain any notice
from the internals group

-nathan

tedd.sperling

Good luck with your gaming programming -- not that I regret my
decision, but I often wonder where my gaming would have taken me, if
I had stayed with it, after writing gnop gnip (ping pong) in 1971.
That's a few years before Pong, which was the same game. But, Pong
wasn't invented by me either -- it was developed by Bell Labs (I
think, or Westinghouse) back in 1956.

Luck, talent, and opportunity -- if you happen to be on the cusp of
all three, the world can change in a heartbeat.

Cheers,

tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com