PHP 5 Released; PHP Compiler, Too
TheTomcat writes "After years of anticipation, PHP 5 was released today. This release represents a milestone in the evolution of PHP. It sports the new Zend Engine II, a completely re-worked object model, and many many new features. Check it and the changelog out."
In other PHP news, remote_bob writes "There have been many attempts, like
BinaryPHP
and PASM,
but finally there is a complete
compiler
for PHP. The Roadsend compiler produces standalone, native executables, and supports the entire PHP language (but not all extensions). It uses
Bigloo Scheme
to do its job, a variant of Lisp, the language that
Paul Graham writes about.
Benchmarks say that performance is pretty good. Is this another sign that dynamic languages are the future?"
...but who will use it for another year or two?
~Necromutant
This may well sever my last remaining link with Perl. While I used to ride the camel for web and shell scripting, I've now moved entirely to php for the web, and mostly php for shell scripting, with Perl used when its extra speed is useful. Presumably compiled php will eclipse Perl for scripting use now though, so (on Linux at least) I'll probably convert fully. Pity I have to stick with sed, awk and shell scripts on our old HPUX servers though...
Code, Hardware, stuff like that.
While I use PHP quite a bit, I think I'll wait a few months / versions befor deploying this...
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Doing PHP development has been my main source of income for a couple of years, the new release will make my life much easier, especially the new OOP model, let's just hope that web hosts will upgrade soon.
Thanks again PHP team!
The IT section color scheme sucks.
Is this another sign that dynamic languages are the future?
Yes.
Remember, nobody's forcing you to upgrade that site running perfectly well under php4, and you probably shouldn't.
How is the cross platform ability of PHP? Can I write an app un Linux and comile and run it on OS X and Windows? Does it need a runtime, or is it bundled? Seems like an intriguing alternative to .NET.
Is this another sign that dynamic languages are the future?
I'm starting to think there are no new ideas any more, just re-hashes of old ideas. Unix, almost 35 years old, looks to be once again the wave of the future. LISP is still teaching us lessons. And the command line is still the most powerful sysadmin tool we have.
Some folks were suspicious of PHP5, and being a longtime PHP programmer, I am very pleased with the changes and additions in PHP5. Can't wait to test it out. Personally, I'm not sure if I'll use *all* of the new stuff, yet I'm sure I'll have to play with the coolest additions for the hell of it, and sort out what I'll be using and what will remain vestigial in my scripts. I will add that some of the previous PHP version quirkiness seems to be fixed.
I am certain this is not the last we'll hear about PHP5 on Slashdot, yet I am only hoping that it's creative/cool stuff, and not security problem/exploit stuff.
I can't wait to see what kinds of changes I can make to my content management system that PHP5 will bring.
The dangers of knowledge trigger emotional distress in human beings.
A good reworking of the PHP object model was definitely in order. Inheritance was a bit weird, destructors were odd to work with, and there weren't ways to declare stuff private.
The bigger question is compatibility. Will older code be ok? When will mainstream hosts migrate to the newer version? It'll be scary to find systems borken because of version updates.
As for a compiler, I'm not sure I'm comfy with the idea. Always figured if you wanted to write code for native compilation, you'd hack in C or maybe C++. Not that PHP wouldn't have its uses...as PHP is really handy and greatly increases the speed of development.
http://www.roadsend.com/home/index.php?pageID=faq
$400 for the license, which is only good for one year. After that, it won't compile until you renew.
Doesn't seem worth it for the casual hobbyist...
Ever since I picked up George Schlossnagle's Advanced PHP Programming as few weeks back I've been using PHP5 RC3 to get used to the new Object-Oriented layout. It's my first real step into using strong OO in my web application and I'm learning a lot!
If speed and not closed-source is your main consideration, then how does the Roadsend compiled code stack up against interpreted code fed through the Zend Accelerator, the Turck MMcache or other caches?
mmCache is OSS and free (as in beer), which is a big plus in my book.
-Charles
Learning HOW to think is more important than learning WHAT to think.
Uhm, the compiler is priced at a low, low introductory price of $399. I don't think it'll be taking the *NIX world by storm any time soon, or cause mass adoption to PHP executables anytime soon.
Now that PHP has stopped imitating Perl, and started imitating Java, I can write some Java-look-alike code while still simple-mindedly sneering at that language as inefficient and bloated!
The compiler generates binary code that is executed directly by the CPU, avoiding the intermediate process of compiling to bytecode and running in a virtual machine
That's a true native compiler to me.
For those who are not new to php, but wan't a good primer for PHP 5 I would definatly recommend this book by George Schlossnagle. Advanced PHP Programming was recently reviewed here and it was upon reading that review that I decided to pick up a copy. It serves as an introduction to OOP to those who are unfamiliar and does a good job in covering the specific mechanics of how things operate in PHP. The book even includes some good info on some Zend Engine hacking.
Steal This Sig
Maybe a language with dynamic typing? AFAIK languages with static typing are considered as more useful...
;)
OK. C advocates, reload your rifles
Just finding inspiration, well, that's my excuse
Am I the only one who is troubled by the blend of proprietary and 'open' systems
I'm with you. I am even troubled by using my computer, what with all those patents and proprietary things under the hood.
PHP itself including the zend engine is 100% opensource, You can download the source you can browse the cvs to your hearts content and see everything.
The products they produce to support the development of php the closed source.
You do not need to touch, use or otherwise dirty your poor soul with any "non-free" software to use php.
There is nothing wrong with this business model, get over it.
Personal Website
And the compiler is only $399.00! And it only runs on x86, no Sparc, no AMD64, no PPC and no S/390 support!
What a deal, what a deal!
I used to really be into PHP. It was great for creating a webpage in little or no time. It's syntax, while maybe not perfect, was pretty good. Until, that is, I tried to start developing my own libraries, and ran into weird quirkiness with object design, and trying to figure out the best way to do libraries, etc. It looks like PHP5 might fix the problems I had with how objects worked, and I'm not sure if it was my own fault with the messy libraries I ended up with, or whether I didn't find the best way to do it in PHP, but I eventually moved to Python out of frustration.
I had avoided Python for a long time, as I really disliked (and still do) the indentation-matters issue. But besides that, and its own set of quirks, it's a really great language, and for larger projects I have trouble even thinking about going back to PHP.
I think the biggest selling point to PHP over other solutions such as Python is that its simple. You don't have to make a whole of choices. For example, with Python you have a large number of packages to choose from: Zope, mod_python, twisted.web, Python CGI, and a bunch of variants on these. While choice can be good, it can also be overwhelming (like how do you know which package to go with until you've tried them all?).
I think I am not alone with some of difficulties I faced with PHP. So while it's great to hear that PHP has fixed many of its bugs, I think its worthwhile for people to also look at other solutions out there.
Just my $0.02.
Speaking of PHP compilers, there's a good and very affordable solution from IonCube as well.
(no, I have no affiliation to them)
That kind of price tag certainly provides an incentive for Roadsend to publish attractive benchmarks. I think it would be better to wait until there are independent benchmarks before we proclaim that "the performance is pretty good", as the submitter does.
...does the FBI know about this? I have heard about some of the PHP busts in recent years, but all this talk about how 'powerful' this new PHP is makes me wonder how dangerous it is. It sounds expensive, too. I hope that this doesn't lead nice young kids, into a life of crime. Imagine, hords of young, glassy-eyed kids stealing stuff like...video games and movies just to fund their PHP habbit.
Damn kids.
HA! I just wasted some of your bandwidth with a frivolous sig!
What the heck does that mean? Is that a fancy way of saying "Compiled languages"? (I somehow doubt it) What precisely is meant here? Is a dynamic language "a language that can be either compiled or interpreted"?
Honey, I shrunk the Cygwin
AUGH! And now I've violated your copyright by creating a derivative work by replying to your post without permission!
(I'll stop now. It's just too easy to make fun of the current interpretations of "Intellectual Property"...)
Hacker Public Radio is our Friend
For a list of PHP 5 related tutorials and articles check out this faqt or simply look around the faqts PHP 5 section.
Too late...
Hacker Public Radio is our Friend
If you'd like to see what's new in PHP 5, we got some of the leading PHP developers to write about new extensions they developed.
I also posted the first chapter of my PHP 5 book in that section which gives an overview of what's new in PHP 5. This book will be part of the Bruce Perens series of Prentice-Hall and will therefore be open-source and freely accessible to anyone.
yes
I am particularily excited about Scheme.. a language that do not support loops like while and for loops in C.
But wait! Scheme understands a tail-recursion!! An infinite self-calling function that will reuse it's memory and never run out of it!
Great! Writing meta-circular evaluators with Scheme used to be a didactic masterpiece of annoyance. Now we get it in production for real work!
What's next? Perl compiler in Prolog?
First I wanted to be a chef. Then I wanted to be Napoleon. My ambitions have continued to grow ever since.
Roadsend is a development house unrelated to the PHP development team. I doubt that their compiler would make any noticable impact since they don't support many of the PHP's most useful extensions. I have not tested it but it looks to me that the people that would be interested in this are those that want to close source their own PHP code so I guess its only fair to pay for it.
Many useful PHP tools are open source. From the bytecode compiles such as APC and MMCache, debuggers (APD and XDebug).
I see tha fact that there are some companies out there providing commercial tools for PHP developers as a good thing(tm).
Anyone have information on how PHP5 handles code written for PHP4 and below? And, just to be clear, I'm talking about first-hand knowledge.
Thanks,
LISP's parentheses turn everybody off, including me, but the data structures really are a win for tree-like applications.
Dynamic languages the future? Unlikely. The future of programming is more likely in code that isn't written, but rather "drawn"
Many people haven't heard of LabView, even though it has been around since the late 80s. It runs on Windows, Mac OS, and Linux. The premise behind LabView is there is no such thing as written code. Instead of code, applications are literally drawn by dragging variables (controls, indicators) onto the block diagram and wiring them together. For instance, if I wanted to add 1 and 2, I would create two integer objects with respective values, find the addition function, and wire them together to an output (indicator - think text box). I have written entire graphical application suites/analysis tools in a matter of days and weeks instead of months (had I written them in, say, C or Java or $your_texT_based_language_of_choice).
The only issue many will have with LabView is that it is expensive. It is also closed source, but hey, so is Java. Anyone interested in rapid application prototyping/development or digital/analog instrumentation should check out LabView.
What does it mean finally and complete?
The Zend compiler is quite complete and AFAIR for flat-fee. Do you mean that it does not produce binaries but byte-code? Then neither Java nor CMUCL have compilers...
The biggest issues developers have with the PHP compilation:
- They don't want to sell their sources unobfuscated;
- They want to gain some optimization speed eliminating the parsing (this can also be achieved by caching);
You have all this since 2000.I have to convert an old oracle 8i database on Windows NT with a client written in visual basic+ to Mysql on Gentoo linux. I use php to write a web interface to that database.
Now, with php5, my classes will get private and protected members which i missed with php4. I'm wondering about try/catch style error handling, will php5 have those? I'm looking at changelog right now, if you know anything about the goodness of php5, please let me know
there you go. much better.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
The bigloo scheme compiler can compile the scheme to native machine code that runs without an interpreter.
There's certainly nothing wrong with this business model, although that's no reason to not be concerned about potential problems. As you said, they create a significant part of the core for PHP and make it open source and available for free, all of which is good. In a perfect world, this would be the perfect solution.
However, it is right to be watchful (not necessarily concerned) when the core of an open-source app is created and driven by a for-profit company. Since they sell a lot of surrounding support applications to make their money, they are clearly driven at some level to pay for that development. At the very least, it means that any really good idea that they have will get turned into a commercial product instead of rolled into an open source solution. Again, perfectly fine business model, but not awesome.
The other thing it does is that there is a subtle but probably powerful pressure pushing other developers working in the PHP space to consider not working there, because they will by definition start out behind this core company. It wouldn't hold off a determined company, but if a determined company began to come into the mix, it would be surprising if the core company didn't somehow use the fact that they are so essential to their advantage somehow. Without competition they can be magnanimous, but with it much less so.
At any rate, I'm just pointing out that there's reason to keep an eye on it, even if nothing ever comes of it. It's also important to encourage more businesses to adopt this model so something as good as this can come along, and it's important for them to be watched by others to make sure they don't abuse it. The lessons of Microsoft, although in a different league entirely, are too strong to ignore.
First of all having PCRE support and having regular expressions heavily integrated into the language the way Perl does are completely different things. So when I need to do log parsing, I do it in Perl, not Python, not PHP. It is simply easier and things fit more nicely for me (I use Python and PHP for at least as much development as I do Perl, but Perl still has its uses).
Second Perl has some nice features that PHP and Python lack. Of course PHP has some nice features that Perl and Python lack, and Python has some nice features that..... You get the point.
Even Javascript has some nice features if you are scripting other components (i.e. in a XUL application) but the next time I ask someone how to itterate through a hash table in Javascript, they had better not say "you don't..."
LedgerSMB: Open source Accounting/ERP
I can assure you that Zend as a company is very friendly to the open-source development and do their best to support it. They make their income from tooling around PHP, but why can IBM, Oracle make money from apache, and Zend not from PHP? Some time ago, they even changed their license (of the Zend engine) in a bow to the rest of the PHP developers. Open-source developers buy their food as well, right?
Seeing as php just passes on anything not contained within
tags, surely the best Hello World script is the followingsig under construction...
Except the multithreading argument every point in your list is wrong...
So how do you explain PHP's install base overtaking ASP according in April last year (according to Netcraft)?
I'll tell you why:
a) Most people feel more comfortable running their web sites on UNIX based systems.
b) PHP is cross-platform which is a big advantage for companies who want to create off-the-shelf applications.
c) It is much easier to find libraries on the Internet which will do exactly what you want.
I am sure there are some other reasons. I'm not a Microsoft basher but let's just say that PHP is doing pretty well for good reasons.
It is called Forth.
(extensible, embedible, and cross-platform)
But is is nice to see a major new release of
PHP, especially with a compiler, and cross
platform as well. Congratulations, PHP Team!
You are right, but the technology comparison was far from accurate. For example, PHP on Windows supports COM and it can be extended by both COM and dlls.
A more thorough technology comparison would be a bit more accurate, but in any case, not only do you have to do a technology comparison but also a TCO comparison and that's where PHP wins. Not because it's free but because the development time is so much faster than with ASP.
PHP is dead. Long live PHP!
Now that I have that out of my system. Does anyone know if PHP5 Unicode is any better than PHP4?
Admittedly I've done about 10 total minutes of PHP coding in my entire life, but I do follow it as closely as possible when I'm not thinking about Perl. I always got the impression the Unicode working in PHP4 was a little lacking compared to the latter versions of Perl.
For example: PHP does have limited unicode support and Joel on Software.
Are you comfortable about using apache or mozilla? There are corporate influences (and corporate only features) in a lot of F/OSS projects. Covalent is the employer for a large part of the Apache core team and sells customized apache builds, Mozilla gets hacked by a NS/AOL team to produce the Netscape 7 series of browsers with added features that do not get ported back to the Moz trunk.
Its nothing but the old GPL vs BSD license flamewars, I'm not about to rehash them here.
09f911029d74e35bd84156c5635688c0
While technically correct, there is nothing there (except perhaps file extension) to denote that it is actually PHP, and I'd argue that you have to at least use one statement/command out of a language to actually make something count as being written IN that language. Otherwise, it's just written in English.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
Exactly. It's not that we always want free beer, we just like to make sure that we can drink as much as everyone else. Now, if you could request a cross-compilation for a different architecture at no additional cost with the license, then we'd all be impressed.
The IT section color scheme sucks.
I didn't check whether it translates PHP to Scheme or implements a bytecode in Scheme or whatever other possibilities exist, but this definitely seems like an extension of Greenspun's Tenth Rule of Programming:
Every sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
Scheme is a small Lisp, compared to Common Lisp, so presuming we throw out bugs and speed because there's an open admission to using a Lisp (whereas gcc, for example, makes no such admission) as well as the "C or Fortran" limitation, the Rule applies.
I guess those of us who do not know how to make our own binaries just have to wait for Marc Liyanage to port this thing.
thanks Marc.
I cant wait to play with the final XML/DOM-3 libs.
...but Microsoft really did get there lightyears ahead of this, with a far more complete class library and a standardized language, as well as a scripting engine that supported true seperation of code, presentation and so forth.
Just to clarify this, consider the following:- ASP.net's been precompiled since the 2000 beta, and it's been production ready for years. The C# language is also fully documented and is a public standard ratified by the EMCA.
PHP5, however nice, is treading old water, and in terms of functionality is still lagging behind even Java/JSP. The whole reason I'm assuming people stuck with PHP4, rather than move to something more robust that provides this kind of capability, is that:-
1) They're apathetic about new technology.
2) If the old language does what they want, why upgrade. It's *Personal* Home Page, after all, not corporate homepage.
3) Why make things more complex, for very little benifit.
Performance wise, the compiled version advantages are fairly insubstantial, and 99.9% of the new stuff they've added could have been done in other ways using the existing language.
The whole thing seems pretty stagnant, and I'm guessing there's a small chance that the PHP guys are stuggling to find their own space between the land of true pre-compiled OO languages and the interperated world that lay behind it.
I've worked with PHP4 and ASP.net since both of them were betas, and if PHP wants to be a serious consideration for large scale development, it'd better decide which side of the OO fence its on, and stay there.
How comfortable are you in knowing that your web hosting service uses Plesk, a closed source application?
"She's a West Texas girl, just like me" - G.W Bush Iraqis
This makes me wonder if the PHP programs have to be manually compiled, if they can be compiled JIT, or if a compiled version can be cached and only recompiled if the original PHP source changes....
Ok, apart from the fact that you're obviously trolling, I don't really have a comment on most of your points as I've never used ASP, and I've used PHP enough to know that I hate it and everything it stands for, but I still have to question at least one of your points - "ASP includes database connection pooling, something that costs many thousands of dollars on Unix"
That sounds like you're quoting a marketing guy with no idea what you're talking about.
Sure, ASP may contain DB connection pooling, and sure, PHP may not have it, but "Costs many thousands of dollars on Unix" is the most ridiculous thing I've ever heard.
Show me this many thousands of dollars worth of "Database Connection Pooling On Unix".
Unix has nothing whatsoever to do with it. PHP runs in IIS quite nicely. And even if PHP was a Unix specific thing, there's nothing hard or expensive about connection pooling, and there are free libraries implementing it in just about any language that can access a database.
Advanced users are users too!
Not to be flaimbait (really!), but after reading over the new features in PHP 5, my reaction is, "you mean you haven't had this all along?" Sure, all this is great for existing PHP users, but I don't think users of other languages will care much. New XML support? Now you can define constructors with __constructor() instead of the name of the class!!! Umm... Try/Catch? Overall, it seems they're just Java-fying PHP, in which case you might as well use Java, so it seems to me (unless, of course, you are already a PHP programmer). Perl programmers will just keep waiting for Perl 6, which makes these "new" features seem kinda like your 6 year old nephew threating to kick your ass. People who are looking for a new, hip, language all seem to be going for Ruby, and I can't blame them (heck, I would too if I had time for such things). Hey, can you hold on a sec... 1999 just called, they want their features back...
I really cannot understand your post. Please don't mod me as troll, but are you saying that instead of writing the compiler in scheme they should just write in Scheme? I can't tell if you are looking down on Scheme/LISP or up at it. I don't consider this OT since I'm just asking the original poster for clarification.
Your CPU is not doing anything else, at least do something.
(Hurray for being modded as flamebait!)
Is this another sign that dynamic languages are the future?
Umm, let's see, this is slashdot, you probably think C is where it's at, right?
I hear that Microsoft is working on something like this. You can punch holes into their ideas of security, but they have the money to make wise choices in research.
In my experience, the memory management in PHP is not good. Coding should be very careful, or the memory will be usually exhausted.
Another problem is the speed. Well, it is inevitable that interpreter execution is slow. However, I think PHP can run at least twice than current version if the inner architecture of PHP could be carefully rewritten.
Additional, I hope PHP could be multithreaded. When develop a serious application, multithreading or multitask can help programmer lots. And also the efficiency of application could be higher.
I hope these problems could be solved in PHP 5 or later versions.
If you are interested in apia, check : http://clonefab.net/, but there is no English web site yet, sorry for this. It is developed in Chinese language initially. The English document will be ready ASAP. As for apia package itself already support english. You can download it in : http://clonefab.net/apiaDownload.php
dynamic languages are going to be just another tool in the toolbox. Not *the* tool.
For dynamic web-sites I can't think of any reason not to use PHP. I even use PHP when I could just as well use server side includes. I just like using PHP so that the pages are future proof in case I want to add some dynamic content later.
But for real time computing you need fast compiled languages. I'm working on tutorials to teach the basics of software rendering using JavaScript. The final set of lessons deobfuscates and fully explains how Wolf5K works. From there it's on to PHP to teach the core concepts behind raytracing. And from there it's on to C to do real time raytracing and finally it's on to ASM to teach optimization tricks to enhance the quality of the graphics while still retaining acceptable frame rates.
It's going to be a very very long time before something like Anti-Planet could be written in PHP.
I'd like to get in the ballpark of what Anti-Planet is doing with my own tutorials.
Ben
Work Safe Porn
With your reasoning, there's reasons to be concerned about every open source software except those created in the basements of college dorms.
Frankly, I don't disagree with you. You should be mindful of every piece of software you use, open or otherwise. But, your argument seems more about Karma Whoring than it does a real concern.
I mean, seriously, what about the Apache Foundation? Where do you think they get their money from? Corporations using their products, right? Don't think they're influenced by said corporations?
I frankly an very supportive of the Zend model of creating a business around open source. It's very pioneering, they've done a good job. I've used php since the PHP/FI (v2) iterations, and I'm still happy to continue using it.
Beware of geeks bearing formulas.
It is not only a matter of Apache but also a matter of PHP. Currently it is not recommended to run PHP in multi-threaded web servers. The main problem isn't the core of PHP but the dozens of PHP extensions and third-party libraries which they use. You can never be sure those are really thread-safe. So even if you're using Apache 2, best to stick to pre-fork MPM. Anyway, there are other ways to tackle connection pooling and these solutions might appear at some stage.
A lot of folks have no problem migrating from f(a, b) to (f a b). In fact, a lot of people don't find the migration from 2+2 to (+ 2 2) all that hard. I use Scheme all the time and like it.
Is php 5 thread safe? More specifically, is it safe to use in a production environment with Apache 2?
While technically correct, there is nothing there (except perhaps file extension) to denote that it is actually PHP, and I'd argue that you have to at least use one statement/command out of a language to actually make something count as being written IN that language. Otherwise, it's just written in English.
Your example was:While technically correct, there is nothing there (except perhaps file extension) to denote that it is actually PHP ;)
How about:
sig under construction...
Paul Graham's site makes no mention of using Bigloo Scheme. On the contrary, he mentions Scheme-48 and PLT Scheme.
Also, how do they know it uses Bigloo Scheme? I find no mention of this on the Roadsend website.
-toomuchPerl
Nope. I love it. It means that there's enough free PHP stuff out there to get things done. And enough PHP business to employee full time PHP programmers.
It sounds fantastic, and I'm very excited that these guys have managed to create jobs by writing useful tools.
Democrats or Republicans. They are both taking us to the same place and they are not afraid of us anymore.
Its definatly an awesome release. I'm thrilled by the native SOAP support.
Hard to imagine what the OS crowd will do with a blockbuster feature like this generally available. SQLite will improve the xcopy deployment compatibilities of simpler apps and SimpleXML is the best xml API i have seen so far in any language. On the OOP front we get exceptions which will finally unmangle the error systems of most complex php web apps which usually accounted for a big chunk of the code.
Anyways, php is cutting edge again.
I would love to use another tool, unfortunately I had to make the decision to not use Webmin and its virtual hosting system because it doesn't provide the experience for my paying clients that they expect. I will gladly switch to a Free substitute once I have time to build one or someone else produces one that will meet the expectations of my clients.
Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. -Martin Luther
As a long-time PHP developer, I have to agree with you somewhat. PHP5--Woohoo!! Ohh, wait... No namespace support? (Arggh... of all features to leave out...)
;), but at least PHP puts them all together easily at your fingertips.
All the new features are sort of the stuff you would call a 'given' for object-oriented programming. Nice to have, but nothing to get really excited about.
Really the things that I found more interesting about PHP were all the system-oriented capabilities developed from version 4.3 onward, such as streams, sockets, direct I/O, etc... Of course, all these are givens in some languages too
The other cool things about PHP are the really dynamic things you can't do in Java, such as variable variables ($$varname), variable function calls ($function_name()), and the extended features for variable interpolation in strings. Also, features like array_map, create_function, and the overload extension are quite cool.
But yes, it looks like Perl 6 is going to up the ante big-time. Interesting to see where PHP goes in the interim, though.
I remember looking at PHP5 notes on a microsoft slide one evening at work and thinking i cant wait till this comes out.. Now that it is, kewl! :) Even better news is that you can not compile binaries... Thats Awsome!! I'd like to see some statistics... Surly the php binaries must be slower, but just how slow is interesting. Also, Dynamic language i feel will be huge in years to come. I believe they'll be the future. But i dont know how a php compiler fits into that, by dynamic i mean languages that are interpretured, not compiled into machine language. Interpretured languages have some many advantages such as being portable, which will be very important. Cool, i'll have to start brushing up on it, havnt used php seriously since the 4.(1|2|3) days?
Giving IE users a taste of their own medicine since 2005 - http://pods.-is-a-geek.net/
I see so many posts about how this would make them switch from perl to php.. but perl has had this for ages...
http://www.indigostar.com/perl2exe.htm
http://par.perl.org/
HEH!!!
...but for some reason I'm rather disinterested.
Don't get me wrong; I've been doing PHP coding for a while. But the fact of the matter is that the more I code in PHP, the more I dislike it.
Granted, the new OOP features in PHP5 are a good thing; hell, they should've been in there a LONG time ago. And exception support has me jumping for joy.
But where for the love of all that is holy is support for namespaces? I mean, sure PHP has a ton of really handy extensions, but I am getting so sick to death with typing underscores that I'll be happy man if the world suddenly decided that underscores were bad and removed them from all character sets (oh, and keyboards) entirely.
And I've also come to the conclusion that the standard PHP api can't quite make up it's mind whether it's supposed to be emulating C, or maybe some other language. Some array functions are prefixed by array_. Some aren't. Some have their arguments in the reverse order that almost all the others do. It's a mess.
PHP is a nice language, good for beginners. But it's complete lack of namespaces, half-arsed support for functional constructs (damn I hate having to write callback functions out seperately when they're one liners!), and schizophrenic api are slowly pushing me towards more well thought-out languages like Python.
Sure, Python's "thou shalt indent" system annoys me a lot of the time, but other then that it's just a clean, logical language. Unfortunetly, support for it on web hosts seems to be all but non-existant.
Seriously, if the PHP devs really want to bring PHP up a few notches, they need namespaces, and to standardize the API naming conventions. I shouldn't have to constantly open up the PHP manual to work out whether the array sorting function has array_ out the front or not.
Still, it's a nice set of improvements, so credit where credit is due. Kudos to the PHP team.
We're geeks... We're the sorcerers of the modern-day world. --
Jeez, you're a bad troll. I've been running it as SAPI for a while now. So, when did you last check? 1995? If the rest of your info is that old, why do you think anyone would believe you? You're as bad as the trolls on alt.sci.physics that deny GR and SR.
Hurricane Ivan: A 17th century prison collapsed. All of the inmates escaped.
The basic summary is, PHP does not support Unicode or any other encodings properly. PHP strings are 8-bit-per-character and do not have any explicit encoding. Sure, there is a multibyte string extension available, but when you look at the big picture, it's worthless.
/maybe/ the popular graphical extensions like GDlib). Which means that for those developers, PHP does not do Unicode at all.
The reason is that PHP's biggest strength is that these days, you can get a PHP-enabled host for virtually no money. However, most of these installs run a standard PHP, some even a locked down one.
The consequence is that anyone who wants to develop PHP software for a large audience cannot use any non-standard stuff (except
I don't see why they won't do native Unicode, when Perl, Python, Java and all the other popular web languages support Unicode with all the bells and whistles.
Download the source
./configure
tar -zxf php-5.0.0.tar.gz
cd php-5.0.0
make all install
Gabriel Ricard
Yes, because it's exceedingly difficult to write a general tree or graph algorithm in a language that has arrays of arrays and references.
I can't believe you got a +4, Informative for a completely inaccurate comment. Congratulations.
Benchmarks say that performance is pretty good. Is this another sign that dynamic languages are the future?"
No more and no less so than they have ever been: dynamic languages are a good choice for many, but not all applications. And dynamic languages have been enormously popular for decades, with far programmers using them than using static languages; PHP just follows in that tradition.
What is more interesting is the emergence of dynamic languages which use static type systems by default: in their runtimes, Java and C# have more complete and better defined dynamic features than Lisp, but they still give the user a simple static type system by default. It remains to be seen whether that gives you the best of both worlds or the worst. Fortunately, their runtimes are well-defined enough that one isn't limited to the specific choices that the currently popular languages running on top of them have made.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
-- . . ramblin' . . .
ASP includes database connection pooling, something that costs many thousands of dollars on Unix
.
Oh yeah? Or, perhaps you meant this one?
Perhaps you forgot to mention persistent, shared memory objects, which ASP cannot do, but PHP CAN? Get a clue, dude.
PHP is aweseome. It's powerful, reasonably fast, allows for incredibly rapid development, lets you get alot done FAST, and it's free.
What's to argue with? I use PHP for
1) client application development with PHP-GTK
2) Exensive server based development a la LAMP
3) Shell/other scripting with its CLI interface.
I've written daemons with PHP. It's clean, simple, and powerful. My best is a large, 50,000+ line application in it. Write a clean codebase with consistent error-handling, and it's a breeze.
It's downright fun to take the contents of a file, turn it into an array with a single line, loop thru it with 1 more line, do a few if statements, and process a 500 MB file in 5 minutes flat.
I *love* replacing a large, complex mini-applet with 12 lines of PHP code - I've done it time and time again.
And, to write in it all day long?! Pure heaven.
I'll be watching PHP5 - I've not deployed it anywhere, and probably won't even start until PHP-GTK 2 (with PHP5, GTK2.X) is out.
BTW, I'm also using Apache 1.3...
I have no problem with your religion until you decide it's reason to deprive others of the truth.
The ruby syntax is dead standard:
If you can read this, thank a teacher. If you are reading it in English, thank a soldier.
Um, what soldiers should I thank? Just out of curiosity.... (And I could read before I started school. That's probably true of a lot of people around here)
Like what I said? You might like my music
I do a lot of professional web and internet developement, but never thought of PHP being the cream of software technologies. Mostly due to the fact that it is 'just' a SSI language which mangles content and code to much for my taste. And for SSI stuff, Zope's TAL extension still is the most interessting imho.
Yet me, and everyone else in the field allways has been well aware of the fact that PHP is the 400 lb. Gorilla of SSI technologies and web developement platforms. And one of those OSS technologies that lead the field in their league. Feature and library laden, performant, well documented and with something like a bazillion active Inet and www related projects using it as primary PL.
What is begining to show now is that the libs and features are growing more and more dense and specialized for tasks that are known to be the most common way of doing things right. Such as extensive use of XML for content, object orientedness in developement and optimized acceleration for the languages primary field of use.
PHP is more and more becoming a one-size-fits-all primary choice for web related stuff, finaly completely dismissing ASP.NET, JSP and Cold Fusion as mere also-ran candidates. Even for those who initially consider using them.
Even though PHP isn't by far the cleanest of modern PL's - I would even say it's somewhat ugly compared to, let's say, Python - I'm begining to expect it to become an all time classic like C or C++.
We suffer more in our imagination than in reality. - Seneca
Lucky PHP guys.. Too bad that support for compiling Perl code into executables is almost non-working.. The only viable alternative I know of is using Stunnix Perl-Obfus for obfuscation/scrambling, and turning output into executable with PAR or Perl2Exe. Does anybody knows a better alternative?
OK, Lisp is cool enough to compile PHP5. Why not switching to Lisp and skip this part?
Java and C# have more complete and better defined dynamic features than Lisp
Could you elaborate on that? It doesn't seem correct to me. Java/C# (at least in C# 1.0, the current version) do not have closures. Neither C# or java will ever have the code/data unity that Lisp has.
My Karma: ran over your Dogma
StrawberryFrog
I don't care what those benchmarks say, for me the Roadsend compiler is magnitudes slower than native PHP, on several benchmarks and some real world code..
I'm a geek and I get some... my geek code proves it! -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS d- s: a- C+@$ UL+++>++++ P+>+++ L++>+++ E--- W+++ N+ o? K- w-- O- M+ V- PS--- PE Y PGP>+++ t- 5+ X- R- tv b++>+++ DI D+ G e++ h--- r+++ y+++ ------END GEEK CODE BLOCK------ (r+++ y+++)
You can do similiar data structures with PHP, for example a tree can be created with arrays containing leafs and other arrays mixed.
...Dmitri who wrote Turck mmcache was offered a job at Zend and, shock horror, took it. However, as mmcache is GPL'd it lives on at sourceforge, with a new cvs commiter appointed (IIRC) and dev work continuing. To be honest though, it's pretty much feature complete so all they need to do is sure up support for PHP5 (still beta at the moment).
I am NaN
Now, admittedly, I'm *not* a PHP programmer. I only peruse annoucements like this periodically in case someday the choice of whether to use PHP or "technology X" lays before me. I don't use scripting languages much, using Perl when I do. But the things you mention as plusses *seem to me* to be pretty common amoungst the scripting languages (as you even say :). Seeing as how you're already a PHP developer, I expect these OOP features to be a great boon for your development. I guess I'm just hard pressed to see the long term PHP niche. Java's got most of the enterprise market and tool/vendor support, Perl 5's probably still got the most hacker/sysadmin users, while Perl 6 is just this side of vaporware they've at least mapped out a clear path to the future, and Ruby and Python have fancy shmancy language features and are pretty mature by now. So is the magic in the secret sauce or what?
i'm not quite sure where you're getting this from.
/* outputs:
i've been using php5 since the first beta and afaik it has never required overloaded child methods to require the same number of arguments as the parent class.
<?
error_reporting(E_ALL|E_STRICT);
class SomeParent
{
function __construct($var1, $var2)
{
echo "Parent: $var1, $var2\n";
}
}
class SomeChild extends SomeParent
{
function __construct($var1,$var2,$var3)
{
echo "Child: $var1, $var2, $var3\n";
}
}
$x = new SomeParent(1,2);
$y = new SomeChild(3,4,5);
$z = new SomeParent(6,7,8);
Parent: 1, 2
Child: 3, 4, 5
Parent: 6, 7
*/
?>
as for sqlite as session handler, it is not the default, nor has it ever been the default.
there was a patch to ALLOW it to be used as a session handler, by setting session.save_handler = sqlite in php.ini
but if we look at the php.inis in the php5 distribution:
[solidox@server150 php-5.0.0]$ cat php.ini-*|grep "session.save_handler"
session.save_handler = files
session.save_handler = files
both dist and recommended use flat files as the default session handler.
You also get logging in those application servers, are you telling me that logging is something that costs many thousands of dollars?
Database connection pooling is trivial to implement.
It's definitely not the thousand dollar feature of those application servers.
Advanced users are users too!
...Turck mmcache, which is completely 100% free OSS (GPL) software, works as a zend extension and not only compiles to zend engine byte-code but also caches the result in ram or a mmapped file? It beats all of the other encoder/loader combo's for speed (probably one of the reasons Dmitri (the guy who wrote it) got offered a job at Zend).
We've been running it on two of our production servers as a test over the past few months, and apart from having to recompile every new PHP release it's been rock solidly available 100% of the time - and has reduced server load to negligible levels. These are high traffic servers too, doing ~900 gigs to a terrabyte per month of traffic- all highly dynamic sites.
I am NaN
I'm a huge fan of Ruby, and have been using it for years, however I still use Perl a lot, mostly because more people know how to use it at my work, and fewer people understand objective programming here, too.
But another reason I still use Perl is 'Perl 6', and the fact it seems to be incorporating a lot of the things I like about Ruby, plus a couple of other interesting ones, but also because the Parrot VM is supposed to allow you to write different parts in Perl or Ruby (or Python, etc?) or *whatever* is appropriate at the time.
I really like the idea of your HTML developer being able to use their polished PHP/HTML skills to suck the data through the nicely objectified RubyOracle libs your DB Developer wrote (instead of the rubbish method(s) PHP insists on now for accessing SQL-ised data...) which can also interact with the more up-to-date Perl6/LDAP libs, all because Parrot lets them work together at the code-level.
I can't wait untill it is fully possible to write object orientated windows programs in PHP... it will happen, one day!
Counter Strike
Sure, but that doesn't mean that it doesn't run on SAPI. You're a true idiot, you know that? Sure, it might be running in multithreaded mode, but andig already answered why you shouldn't, because of the third part packages and the like. So, just shutup, you're obvious trolling just proves how stupid you are.
Hurricane Ivan: A 17th century prison collapsed. All of the inmates escaped.
If memory serves, PHP3 had built-in debugging output capabilities. When Zend became 'official' and PHP4 was released, debugging was suddenly nowhere to be found. BUT, lo and behold, you can get debugging capabilities if you purchase the Zend Studio and server extensions. Yes, there are open source debugging extensions now too, but that move was the one that made me start thinking like you're doing. Again, nothing inherently WRONG with it, but it was something that seemed to be held out of the core system to help fund the development by selling it separately.
creation science book
Have they fixed the most annoying thing about PHP4? Specifically, if I put <?xml version="1.0" encoding="iso-8859-1"?> quite normally outside of PHP code, PHP4 barfs. (Which is quite annoying if the recommended way to put PHP code in is to use <?php ... ?<, specifically for XML/XHTML compliance. A savage hypocrisy.) And before you ask, no, I can't mess around with PHP configuration or anything.
Also, what about componentization? Any news on that front? I'm quite fond of Perl's HTML::Mason and sort of like JSP tag library ideas - can I clearly separate the code and the page, or do I still need to mess them together?
News of a new XML parser sound good, though. PHP4's idea of XML parsing is... ugly. =)
Yahoo Store *used* to be in LISP. As far as I know, it was rewritten some time ago, partly because nobody knew the language and partly because the way it was done meant they had to have stupid warnings telling the user not to hit the browsers back button.
Could you elaborate on that? It doesn't seem correct to me. Java/C# (at least in C# 1.0, the current version) do not have closures. Neither C# or java will ever have the code/data unity that Lisp has.
Well, just telegraphically...
Java has a pretty close approximation to closures (nested classes).
Both Java and C# can be extended with closures without changes to the runtime.
I think support for lexical closures is planned for the CLR (I don't know about C#).
Closures are probably not a necessary part of being a dynamic language (PHP doesn't have them, neither did many versions of Lisp).
Both Java and C# have full dynamic type information and full reflection; the reflection system of standard CommonLisp has some limitations in comparison (although individual CommonLisp implementations often provided implementation-specific workarounds).
Both Java and C# have full dynamic code generation and full reflection of existing, compiled code (you can analyze code from other methods/classes); Lisp's dynamic code generation and code reflection are more limited.
Lisp syntax is nice, and you can program the JVM and CLR with Lisp syntax. But while I fully believe that Lisp syntax is great for programming, I think for data structures, it is a compromise, and XML and similar standard representations fulfill similar functions for other languages.
So, Java and C# aren't exactly like Lisp--they have made different choices, and you may or may not like the overall package. They are clearly not "dynamic" in the important sense of being "interactive" by default (although bsh helps). But in some ways (reflection, dynamic code generation, etc.), I think they are arguably better dynamic languages than Lisp ever was.
If the Lisp community ever got its act together and actually learned from Java/C#, they could produce a great response, something that combines the best of Java/C# and Lisp. But I doubt that's going to happen any time soon.
Is this another sign that dynamic languages are the future?
Is this guy serious? Where's he been the last 7 years? hehe.
There isn't any loop construct in C that can't be done easily with named let in Scheme. You really don't have to learn recursion if you don't want to.
I think support for lexical closures is planned for the CLR (I don't know about C#).
.NET crown jewel. C# 2.0 will have anonymous methods with "environment capture" of visible variables.
Yes it will. The whidbey whitepaper is online somewhere. The functionality will of course be in C#, since C# is the
Lisp is and will always be a better functional language than Java/C# - the syntax is just better for it - but I take the point that it not the same thing as a dynamic language.
If the Lisp community ever got its act together and actually learned from Java/C#, they could produce a great response, something that combines the best of Java/C# and Lisp. But I doubt that's going to happen any time soon.
Possibly the ML/CAML/OOCAML/Haskel crowd would be more open to innovation.
My Karma: ran over your Dogma
StrawberryFrog
Don't use R5RS as your reference doc. Use the docs that come with your Scheme implementation. I'd be surprised if you're using an implementation that doesn't come with a read-line function.
Well... hehe. You have pretty well described the lay of the land, except for your last question. I still wonder myself sometimes, but there is definitely something about PHP that just makes it sooo easy to get things going with it. It's by no means the most elegant language out there (I have actually been toying with Python, although I find some things about it very irritating too).
In fact, I think PHP's previous simplicity and 'under-featuredness' with regards to OOP are actually what made it so popular. It's not like Java, where you have to not only understand language syntax, but absorb a large piece of documentation on the "foundation classes", and who knows what other standard libs. It's not like Perl, where you have to get all kinds of oddness firmly fixed in your head in order to really be proficient (not that Perl isn't fun--its probably the most fun scripting language out there).
Also, there are people, like me, who are just a little skeptical of the grand benefits of OOP, especially when you are doing applications which can express business logic in a database like PostgreSQL. IMHO relational logic is the ultimate way to handle the business needs of an organization, and I don't buy the whole object-relational mapping thing. So in that sense, I don't depend on PHP to handle the grand scheme of things, but to handle the messy details of displaying data, taking user input, dynamically buidling HTML, etc... PHP tends to make messy details easy, which again is because of it's "bad" features like weak typing, using the same prefix on all variables (unlike Perl), easy array access and manipulation, etc...
Also, I have recently been doing some serious client-side scripting in PHP (sockets, Unix system stuff, etc..), and it is quite nice. The only oddity there is the need to enclose all PHP code in the tags, but I'm sure that will be an optional thing sooner or later.
Oh, and the other part of the 'secret sauce' is that PHP is so easy to install on just about any operating system out there. Can't complain about that.
The Ruby interpreter will not run python code, nor will it run perl code.
Ruby borrows features and ideas from perl, scheme, and smalltalk. From perl it gets powerful regular expressions and other features that are generally useless but are great for one-liners. From scheme it gets continuations and lambdas. From smalltalk it gets blocks, which are a very powerful way to represent acquiring and releasing of resources.
I don't know what ruby might borrow from python, but I'm sure there's something. The syntax is similar, at any rate.
All this borrowing is a good thing. It means that Ruby can take the best of what's out there and combine it into a single package. But when it does that, it loses something in the process. Ruby isn't good for purely functional-style programming; use scheme for that. In ruby almost everything is an object, but if you want everything to be an object (even your control structures) you should consider smalltalk. And ruby isn't the fastest interpreter out there; if you want something faster, determine your requirements and write some benchmarks to find something that suits your needs.
Ruby is a great language, but what's even better is its community. It's a small community right now, and with a small community comes a quaintness and a friendliness that is generally not found in larger communities. Unfortunately, a side efefect of ruby's small community is that there are fewer libraries available for ruby than for, say, perl or python. Plus a nice small community is something that cannot last; as ruby gains in popularity, it will attract trolls and garbage library writers.
Give ruby a try, but don't expect it to solve all your problems. It will not make breakfast for you in bed or greet you with a kiss.
It'll be scary to find systems borken because of version updates.
De system's borken! Borken borken borken!
<insert witty linux comment here>
I remember putting a CMS together with PHP4, something like Midgard, but pure PHP with multiple backends. It's not entirely a bad design even now, though I think Zope has a better answer.
... which did exactly the WRONG thing and implemented even DEEPER comparison. That was the point where I went over the edge and wrote off PHP. I hear this behavior has mercifully changed to a sane one in PHP5.
I ran into some awesomely dumb stuff. I mean "what are they smoking" stuff.
Brain dead parser: First of all, this requirement to put everything in tags or whatever brackets you have defined. What is this, javascript? (and even javascript doesn't need it if you use src="foo.js"). That alone, not so bad, but the parser would easily choke on any end bracket construct ANYWHERE -- in a string, in a comment, etc.
Flat namespace. OOP completely unused in extensions. Since PHP can easily call functions dynamically by name, and we have PEAR now, I consider the problem solved. No worse a hack than perl's OOP implementation, really. But I had other problems with OOP...
Pass-by-value: PHP4 would pass objects by value. Which is actually great if I want such value-type, but 99.9% of the time, I don't. What made matters worse was PHP's twisted notion of object identity -- it had no operator to test it. Equality comparison operators were always by value, and either "shallow" or "deep". I had to explain the concept of object identity, and for my trouble, got the '===' operator
Second-class-language attitude: I got choice responses from Zeev himself about how PHP is never intended to be more than a "web language" (apparently meaning limited to trivial scripting, because the web apps I use sure aren't trivial). PHP can be and has been used for powerful things, but I don't see writing a caching bulk DNS lookup service that tests against multiple RBL's using PHP if I can't get a serious contender to Net::DNS because PHP is "merely a web language" after all. I used Perl for that, then switched it to Python (stackless was ideal for this job) and then dropped it into the object publisher in mod_python. Painless. There is no such thing as a "web language", behind every web app there should be a *real* language.
Error handling: Nonexistent. Got an error, it would print a traceback to the output if you were lucky. Syntax errors would simply die without any useful diagnostic. No eval (well there is, but it would also just die on syntax errors). I've seen structured exceptions in C, but PHP's was awful. Awesomely brittle.
Hopefully PHP5 is migrating most of these warts away from PHP4. Perl certainly still has its own problems (mod_perl 2.0 is still not in a stable release state) so it's not too late for PHP among current perl users.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Lisp is and will always be a better functional language than Java/C#
I agree, and I prefer Lisp syntax myself. I hope one can eventually come up with a Lisp-like system that combines the advantages of Lisp syntax with the practicality and completeness of the C# runtime, libraries, and specification. Since Lisp syntax has been used even for C-like languages, it seems like it should be fairly easy. Also, I believe Microsoft is even thinking about improving support for fully dynamically typed languages (like Scheme and Smalltalk), so then one would really have the best of both worlds: full support for Lisp styles with full acess to C#-like syntax and semantics.
I love perl's IO::Socket and IO::Select classes for writing socket-based applications. Python's socket and select classes are quite nice too.
PHP is much faster than ASP running on a comparable system. Oh, and ASP and IIS are connected at the hip, and anyone running an IIS webserver needs to be strung out in the desert somewhere. :-P
Comparing a model like Zend to a model like Apache is apples and oranges, frankly. Apache is an non-profit, organization that is both privately held (i.e. not publically traded) and does not sell products based on the apps that they create. Whenever any company starts requiring a profit from whatever they're doing, and worse if they are accountable for quarterly earnings reports for the stock market, there is the potential for what I will loosely call "bad things". I'm not suggesting Zend or other groups like MySQL or JBoss have done any bad things, but it's always possible.
Unlike Perl and Python, Ruby hasn't accepted yet, that it is important to have good, integrated Unicode support.
This is the single point stopping me to switch over to Ruby.
In what way? All Common Lisp implementations have structures, arrays, hashtables, and CLOS objects as part of the standard. These are just as usuable in Lisp (perhaps more so, because of the common syntax) as in any other language. The days of Lisps using lists as their main data structures (in anything but the prototyping phases of coding) are long gone.
That is all.
Common Lisp doesn't specify reflection facilities for generated code because it doesn't specify anything about the implementation of the language. The reason C# and Java can offer generated code reflection as part of the language is that their code generation is tied to a single VM bytecode specification. It is also unfair to call it "compiled" code reflection, since the reflection capabilities are defined over VM bytecode. The downside to the Smalltalk approach (Smalltalk was the first language to integrate the language and implementation in such a way) is exactly the downside of the VMs. With parallel processing coming back in vogue, I suspect that pretty soon we'll be seeing the same idiocy of the 80s (trying to squeeze parallelism out of 'for' loops in C, trying to make a parallel Fortran) repeated in a mountain of research on parallelising stack-based virtual machines. Guy Steele added 3 primitive constructs to the specification of Common Lisp to make Connection Machine Lisp, and those ideas are still the best approach for implementing an efficient data-driven parallel language.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
LISP is a good match for operating on HTML and XML ... Perl, PHP, and Java don't do trees well. You have to hammer the tree into an object paradigm, which doesn't help all that much.
I'm sorry, but DOM is a standard tree representation. DOM works well in this regard, and it is a fairly standard API across most languages. You should never have to build your own data structures.
Perl's representation of a tree is rather inefficient, too. I do considerable parsing of large documents into trees in Perl.
I do too, and I know it doesn't have to be inefficient. How are you currently doing it? If absolute efficiency is what you want, use a stream-based API like SAX, TokeParser, etc. If a tree-based approach is what you want (such as for conveniences like XPath queries) use XML::LibXML, which uses libxml, the most efficient and fastest parser available. It is written in C, and is fast, fast, fast. There are language bindings for not only Perl, but PHP, Python, Ruby, and many other languages.
bp
All Common Lisp implementations have structures, arrays, hashtables, and CLOS objects as part of the standard.
I didn't say CommonLisp lacked data structures. I said that I think Lisp syntax is a compromise for representing data structures.
The days of Lisps using lists as their main data structures (in anything but the prototyping phases of coding) are long gone.
Yes, and that's why Lisp syntax has also become somewhat less important. Lisp syntax is a huge advantage as long as almost everything is lists. But the more diverse and complicated the set of data structures you use becomes, the more Lisp syntax loses its advantage.
This is BS. Neither Java nor C# have the equivalents of read, eval, compile,
No, they don't have them "as primitives", but they have the primitives that let you implement those. For example, if you want Lisp-like read and eval functionality, you can use Beanshell.
As I was saying, you may not like the way Java provides dynamic features, but it does provide lots of dynamic features.
or even change-class as language primitives.
I believe the Java debugging interface specifies that, and it works about as well (take that as you like).
Common Lisp doesn't specify reflection facilities for generated code because it doesn't specify anything about the implementation of the language.
Well, neither does Java, really. Java specifies an intermediate level representation, somewhat below the source, but way above machine code.
The reason C# and Java can offer generated code reflection as part of the language is that their code generation is tied to a single VM bytecode specification. [...] t is also unfair to call it "compiled" code reflection, since the reflection capabilities are defined over VM bytecode.
Well, the situation is a little more complex. You don't reflect over machine code, but the VM dynamically maintains a one-to-one correspondence between VM code and machine code.
The downside to the Smalltalk approach (Smalltalk was the first language to integrate the language and implementation in such a way) is exactly the downside of the VMs. With parallel processing coming back in vogue, I suspect that pretty soon we'll be seeing the same idiocy of the 80s (trying to squeeze parallelism out of 'for' loops in C, trying to make a parallel Fortran) repeated in a mountain of research on parallelising stack-based virtual machines.
Sorry, but that's not how the JVM or CLR work. They are not arbitrary stack machines, they impose restrictions that make them basically just binary representations of the macro-expanded and canonicalized source code using postfix notation. You compile them using the same high-performance compilation strategies you might use with a C, Fortran, or Lisp source compiler. They are no harder and no easier to parallelize than any other representation of an imperative language.
As for "the" Smalltalk approach, there is no such thing. The original Smalltalk used a stack-based bytecode interpreter, recent versions of Smalltalk (and Self) are using the same JIT approach as Java. I don't know of any Lisp system using a high-performnce JIT (other than those based on the JVM or CLR, of course), and I think that's a major problem with Lisp.
Java's choice of "binary postfix program representation after canonicalization" instead of Lisp's "weakly parsed uncanonicalized symbols-plus-lists" seems to be a winning combination: manipulating code at that level is slightly less intuitive, but it avoids many of the complexities and limitations of Lisp code walkers. As a result, people have been able to implement things in bullet proof was in Java that ended up being at best flaky using code walkers.
Let me just be clear again: I'm not saying that Java is "better" than Lisp, or worse than Lisp, In fact, I'm pretty neutral on the matter: I think both systems have some brilliant ideas, and both systems have some absolutely awful design flaws. Neither language meets my standards for careful language design or good taste. But I do appreciate the good points each has to offer and I believe both languages and systems have contributed significantly to progress in the state of the art.
And that's why we use XML?
That is all.
I think PHP's previous simplicity and 'under-featuredness' with regards to OOP are actually what made it so popular
:)
You know what, I can respect that. It's not for me, but that's cool. See, I'm primarily a C++ and Java coder. And while C++ is more complex, I find it's complexity *useful*, while Java's is just infuriating (J2EE is a nightmare). Now what I dream about is the day when you can use your choice of language on your choice of VM-Mono, JVM, or Parrot, including libraries etc. Being able to choose your libraries and language independantly would eliminate a lot of language wars, IMHO.
Well, I'm gonna mark you as friend since you seem level-headed and un-fanboyish
I'm not brave enough to try PHP 5 yet, just because of possible regression with PHP packages (Phorum and SymPoll).
Running PHP on multithreaded webservers on Win32 is fine, it's only an issue on Unix.
Was. Was running it...
And that's why we use XML?
XML seems to be largely a more cumbersome form of Lisp syntax, and both have many of the same strengths and weaknesses.
Fortunately, "we" have lots of other choices for representing data. "We" should use the best syntax and tools for each job.
Ditto ;)
And I completely agree on the concept of "useful complexity". That's what it really comes down to, and it depends on the type of work you are doing. For example, many developers use MySQL because of its simplicity, while I find the relative complexity of PostgreSQL *extremely* useful, to the point that I pretty much can't live without it. It's all about choosing your battles.
Further, because the (same) Lisp image is running for the compile and run cycless, it's significantly easier to degenerate and compile and load code even late in a life cycle.
Again, you haven't worked with Lisp enough recently. In every way that could possibly matter, Lisp's facilities are superior. Especially now that the Meta-Object Protocol has seen widespread adoption, the facilities of Lisp are so far superior to C# and Java that it's not fair to compare them. It's possible to do Smalltalk-style metaclass programming, to dynamically update and reflect upon classes (and update all running instances transparently, try that in Java!), and to completely change classes dynamically. Given your inexperience with Lisp-like languages (which shows quite plainly), you might want to consider looking into it more before making such a bizzare statement. One of the reasons lispniks get so grumpy about XML is that XML is a more verbose version of S-expressions, but gets a lot of hype in the press (where Lisp suffers a lot).When it comes down to it, they're practicaly equivalent except:
- S-expressions are more convenient for human use and parsing.
- XML is more convenient for computer use and parsing.
Otherwise, they're essentially the same and represent things in a similar fashion. Please update your mental database accordingly. Lisp DID listen. They came up with CLOS and the MOP (meta-object protocol). If you bothered to understand what they did, you'd see they beat C# and Java to the punch by nearly a decade, and they're still ahead in every way that matters to programmers.To even complain that "Lisp isn't dynamic compared to C#/Java," is actually hard for me to understand. Please, name one operation that you can do in C# but cannot do in Lisp (that makes sense to do in Lisp and C#). I know Java and Lisp pretty well, and I can't think of one.
It's great to see such a mainstream product as PHP being powered by a Lisp dialect(even if it is a Lisp-1).
Slashdot. It's Not For Common Sense
Maybe read was a poor example. External representations aside, eval has nothing to do with interactivity or dynamic features, but everything to do with being able to construct and then execute programs with the regular abstract data structures and operators of the language, without any regard for it's implementation.
Well, you yourself just stated that the relationship between the generated code and the bytecode is one-to-one. JIT is nothing more than another way to interpret the intermediate code. The point I was trying to make was that Smalltalk was the first system to specify a common, platform-neutral binary representation for program and data and an interpretation mechanism for that representation.
What's the point? To be popular? Cross-platform? High performance? Persistence? Lisp won't be any more popular if there's a bytecode JIT implementation. C is currently the most portable language available, so the cross-platform argument doesn't hold much water (especially considering that the CLR is controlled by Microsoft). Many Common Lisp implementations (Allegro, CMUCL, SBCL) come with native-code compilers that can match or beat G++, so going the JIT way will only be a penalty to performance. Neither Java nor .NET take advantage of the persistence possibilities of a VM like Smalltalk does, but most Common Lisp implementations can already dump a non-portable memory image executable.
There were several Lisp dialects based on virtual machines in the 70s and 80s, the most prominent being Lisp/370 from IBM and Interlisp. Both used the capabilities provided by the VM quite heavily (Lisp/370 for performance (there's a paper on the subject in the proceedings of the Lisp conference 80 or 82), Interlisp for most everything, especially the exploitation of the sphaghetti stack for control structures). Lisp/370 died for commercial reasons, but Interlisp lived well into the early 90s. It may have been that the system wasn't particularly well structured or architected (which is perfectly excusable considering that Interlisp continually evolved as a single system since the mid 60s), but Interlisp was not easy to port or high performance. The Orbit T compiler showed that source code transformations could produce a more portable, efficient compiler than the alternatives - it was written by four or five undergraduates over the course of two summers, but it was faster than many commercial implementations using either the traditional native-code or VM approaches. Starting with Lucid's Common Lisp, pretty much all the commercial and non-commercial Lisp systems have used the same approach. JIT may alleviate some of the performance penalties for using a VM, but as I've pointed out, there are other disadvantages to tying a language down to interpretation strategies.
The problem with doing manipulations at the intermediate representation is that the transformation between the high and mid-lev
In the great CONS chain of life, you can either be the CAR or be in the CDR.
Whoa boy, another flame war unto itself! I'm not a DB guy, but I like Postgres. I'm anxiously awaiting bugzillia 2.20 I think it is, with Postgres support. Then, when postgres 7.5 comes out with native Win32 support, life'll be grand. Not that that's what's holding me up, mind you, I have a couple linux servers running, but bugzilla's install looks intimidating and it's not pressing and I have a gazillion other jobs. It was enough for me to get Subversion running, and I failed getting samba configured properly. Now I'm waiting for all the tools (like IDEs especially) to have Subversion integration. Guess that's why I'm a coder and project manager, I'm a lousy admin! I know enough apache and tomcat to be dangerous, enough linux to get around, but diddley about sendmail, bind, and countless other programs. Hell, I can't get the ftp server configured to set permissions the way I want them (whatever the default ftp server is on FC1).
.Net stuff, you know? I want to stick with my IDE of choice, which right now means Netbeans or VC++.Net. BTW, I think VC++ 6 was an amazing product for its time, but I don't really like VC++.Net the IDE, although I do appreciate compiler advancements (better code and more standards compliant). Anyway, I intend to get around to playing with Mono sometime; I'm especially interested in the OSX version.
Fortunately Mono looks to have Postgres support. Now, if they would just ditch monodevelop and work on Netbeans, Eclipse, and KDevelop integration... I mean, competition is good and all, but I don't want to switch to monodevelop just to develop
About choosing your battles, amen, that's why I do use Java--it's the right tool for the job in the places where I use it. Which has nothing to do with Java, but the fact that 3rd party products provide java libraries/interfaces. Perl would actually be better for what I'm doing, but toss in an obscure commercial database with only JDBC and a few java libraries, and poof, there you have it (the Netbeans angle helped a lot too, to be fair).
However, I really really like JSPs/Servlets. I *want* to like JSF, but but but... And EJBs are enought to make a grown man cry. I'm following the MyFaces list, and it looks like good things are coming. MyFaces will become an Apache project, and will integrate smoothly with Struts soon, and there's talk in the air about portlets. I figure that by next spring (march say), a lot of my frustrations with Java-land will be cleared up. Java 1.5 err I mean 5.0, Netbeans 4, hopefully a new JSF spec to clean up probs, and Struts-MyFaces harmony, all given some time to stabalize. Maybe even the commercial Java guys will get their acts together by then--I was dismayed to find that IBM's latest offering only supports old JSP/Servlets, BEA has their own proprietary nastiness, and Sun's proprietary versions of Netbeans (Java Studio Creator, I think) and Tomcat (Sun Web App Server?) are steaming piles of poo when I tried them a couple months ago. Granted, they were beta, but wtf??
Alright, enough chewing your ear off. Later.
Looking at the responses to this article with a low threshold is really disheartening. PHP is a powerful language/library set. But PHP has some core design issues that still need addressing. And every intelligent post that points this out gets modded as a troll.
I guess I shouldn't be suprised at this anymore here on slashdot. But I would not ditch other languages in favor of (non-free) compiled PHP until they address *ALL* the problems listed in these articles:
Using PHP in large websites
PHP in contrast to Perl