PHP-GTK based IDE for Midgard and PHP 30
bergie writes: "The new IDE for Midgard and PHP developers is entirely written in PHP using the PHP-GTK toolkit. PHPmole aims to provide the free software world with a web development environment comparable to DreamWeaver and MS Visual Studio, with additional content management functionalities. PHP is not only for web developers any more ..."
Interesting (Score:2, Funny)
PS, FP?
Great! (Score:2, Interesting)
Re:Great! (Score:1)
Re:php ain't for me (Score:1, Offtopic)
State of PHP (Score:2)
I always saw PHP as a nice tool for exactly one job - quickly hacking toghether dynamic web sites. It's great at that, but I never felt it suitable for bigger projects (not even bigger websites, but GUI apps - I guess typing <?php in every file gets boring really fast...)
For example, it's OO is rather weak - and it totally lacked any support for modularization, except the dirty include_once hack.
Re:State of PHP (Score:2)
After trying it out it is rather cool. I agree with you php does have weak classes but for quick projects that have tight deadlines this may be alternative answer to vb.
Re:State of PHP (Score:5, Informative)
The object model is being improved significantly in <a href="http://www.zend.org/zend/future.php">Zend Engine 2</a> (Zend being what powers PHP4), with namespaces (implimented as nested classes you pretend you can't instantiate), and object handles rather than hacks on the hash implimentation. It still lacks nice features like iterators, but it is at least moving in the right direction.
The shove-everything-in-the-default-namespace mentality is still there, meaning you either code functionally or write OO wrappers for everything (not to mention how bloated it becomes; when used for standalone apps, having it driven by a binary that's linked to to pretty much everything kinda looses it's appeal).
Keywords are still unusable anywhere; you can't have methods called Print(), or Import(), not even if you fully qualify them (maybe I'm spoilt by Ruby
The dodgy case sensitivity issues are still there; functions are not case sensitive, variables are (hence you can't use Print() in a class, despite the keyword being print). With the new object model where you can just use methodCall() instead of $this->methodCall() I can see this biting people more in future.
(include|require)_once are still there, and are the usual way to include any file; that's 4 statements that do pretty much the same thing, with the longer uglier ones being the most common. A Perlish 'use Package::Module::Class' statement may help here, although it's only just being discussed seriously.
The language still lacks any real specification; features are added and removed on the whims of the developers, occasionally based on the feedback from users, who sometimes miss obvious problems with changes until it's worryingly late.
On the plus side, they do take backward compatibility fairly seriously and aren't always afraid to break it to introduce badly wanted new features (hence case sensitivity is an unlikely candidate to be changed, but the new OO model might break things).
At the end of the day, I wouldn't use it for anything other than web stuff; the language simply isn't that good. The biggest plus point is it's truely kickass server embedding support, but beyond that there are much better alternatives.
Re:State of PHP (Score:1)
And I'd love to use private methods.
It's memory usage is also spotty. For one-second web scripts, this doesn't matter so much. But for long-running apps, I've had trouble.
Re:State of PHP (Score:2)
Thread.start(socket.accept) do |socket|
socket.send("Moo!")
end
Ah Ruby, how I love thee, let me count the ways.. er.. I mean.. *cough*
> And I'd love to use private methods.
Private member variables were recently added to Zend 2, although really this just means the variable $this->Bla isn't the same as $otherobject->Bla; internally the name is changed, so there's no error messages, just a different variable.
One more way you can make your programs difficult to maintain
This nasty behavior was chosen because it's pretty much free; the name is changed at compile time. Obviously a new field in the symbol table and an if() check is way too much to ask of Zend.
> It's memory usage is also spotty. For one-second web scripts, this doesn't matter so much.
Actually, since it's embedded, and since Apache likes to keep memory hanging around, this can be a problem; if your script allocates, say, 70MB once, the httpd process will sit at that level even if it sticks to more sane amounts in future.
That's what --enable-memory-limit is for, though.
> But for long-running apps, I've had trouble.
I'd say that's outside PHP's problem domain, and it should stay that way; the only advantage of being able to use PHP outside the webserver is the ability to not learn anything else, but all that does is give you the language equivilent of in-breeding, and we all know what that does..
PHP has finally moved (in CVS, anyway) to installing a command-line interpreter in all installations now, so unfortunately (or fortunately, depending on your point of view) there's now even less reason for 100,000 naive PHP users to learn a different language and give them a more rounded perspective.
Re:State of PHP (Score:1)
Actually, there's another reason:
I've inherited a large web site that uses many well-written classes and functions specific to the site's data model and functionality. When I need some maintenance shell scripts to work with the same data, it makes much more sense for me to use PHP so I can re-use these blocks, rather than create new (and redundant) blocks in some other language.
Re:State of PHP (Score:2)
Re:State of PHP (Score:1)
I really disagree. I think that the benefits of a single code base for a given set of data outweigh the dubious benefit of seeing the data "from a PoV that doesn't include PHP". I don't see how the extreme that you mention (storing serialized PHP objects in the DB) is somehow the logical extension of re-using one's classes. One of the best selling points of OOP is code re-use. There is no reason not to re-use them if they do what you need. If that means having some stand-alone PHP scripts, fine.
but then again (Score:1)
With that in mind, what is then the best solution for maintenance. Key desires are abstracted design elements to encourage reuse between all components, along with a framework for future projects/elements that you do not want to limit to one particular language or implementation. Would PHP be a good solution for a quick fix? Can PHP create data formats for storage and interfacing that will easily (hahaha) be usable by other languages like Java? Perhaps first creating a more Java friendly system that PHP can also access with little overhead? (rumoured desire is RMI, so I am leaning for Jini right now just because I want to learn it :) Then once operational the optimization can happen for different sections, converting to Java if needed (if only for the API and consistent calls), or writing C++ wrappers (apparently that is desired by some talking heads)... what to do, oh what to do? oh yeah... there are also a TON of datastores of various types that need to be normalized and made to play nicely together.
Perhaps simply coding under the influence will make all those problems solve themselves, believe I shall try that later!
thanks for the input! (Score:1)
Re:State of PHP (Score:1)
I agree that it's a good idea to look at the problem from outside the syntax of any one language, but I don't understand how it follows from the fact that PHP provides a commandline processor that it assumes responsibility for a programmer limiting h(is|er) view to PHP. Many programmers doubtless do this, in any language. But IMHO a programmer should be thinking in terms of the problem and just use the language as a tool to solve it.
In the PHPWiki example, if you want interoperable serialization, you should probably be using WDDX or something like it anyway. ;)
Re:State of PHP (Score:1)
Would I write an accounting package in it? No.... but for quick and dirty gui and web based apps it is great. I even find myself using the php cgi binary to run unix scripts in cron tabs and such.
But to use a scripting language to create a really huge app, or to use a really involved programming language to do a really quick and dirty app are both futile and why we have more than one type of language out there.
In other words, PHP is AWESOME, but like anything it is just another tool in the coders tool belt. Once PHP 4.2 hits, it will be pretty much perfected for what it is.
Re:State of PHP (Score:1)
Re:State of PHP (Score:2)
I have been developing a HUGE web app [sourceforge.net] for doing CRM work written in PHP. To give you an idea of its scope, it is designed to be platform and database manager independent, and the reporting engine creates its reports in PDF format. The entire application at present is over 5000 lines of code and constantly growing. Currently we are missing a few important management interfaces and an install script so it is officially in alpha, not to mention the fact that I am in the process of overhauling the reporting engine to provide more flexibility. Hopefully, we will be into a beta stage relatively soon (most of the components are completely stable and well tested).
In order to create such a massive project and avoid equally massive performance problems, we had to completely modularize the application into several areas including a core application server (handles database abstraction, state handling, and authentication), presentation engines (HTML-based data entry and PDF reporting at present), etc. as well as introduce a library model for the application as a whole.
While the core application server was designed in an explicitly non-OO way for performance reasons, it is small and hence easy to maintain, and the libraries tend to be OO due to the complexity of data passed between functions.
Even for such a massive application as this and one that will grow strongly, I have found everything I need in PHP, and the OO model is sufficient for most things. Furthermore, most people have separate web pages which call various other modules, and I have found this a little less than optimal (I use a single web page which dynamically includes the content files as needed).
Basically, what I would say is this: use your imagination and inspiration to come up with ways of designing quality applications rather complaining about features that are not available. Of course, if additional features are needed, you could get involved and add those features.
Why I choose PHP for the mole (Score:5, Informative)
These where some of the options (That are vaguely cross platform).
A compiled language C or C++ - the history of programs like evolution, which suffered extensive delays and has been the driving force of miguel (from what I've read/heard) moving toward C# is evidence that the concept of developing all of a large scale application in only a high level language is fraught with problems - generally thought to be problems with memory management, (Im not actually sure that C# will prove a much better alternative).
Java and C# , bytecode compiled languages, object orientated languages with strict variable definitions, again, these offer a few benifits over the high level languages, where the reduction of memory management consideration in coding improves productivity. It's just since C# is not ready on linux yet, and Java is a pain to install on debian (thanks to suns licencing), And from a long experience of getting Java going on different platforms it was obvious that trusting MS to keep java running correctly on windows was a recipe for disaster!.
Scripted, loose typed (non decleared variabled), runtime bytecode compiled languages like Python, Pike, Perl, and Ruby - These are extremely good as prototyping languages where the slower bits can be speeded up by writing extenstions in C etc. Almost all of these languages have similar advantages, Perl and PHP have strong variable identifiers, ruby and pike have strong object orientation. - noteable in
Others like delphi - which is not open souce, or particualy stable on linux....
lisp and it's friends - which after having spent 3 years writing scripts/applications in, I never would want to touch again.
Having developed in Pike,Python and Perl
(they do have their good points, but these are the ones that are -for me - significant downsides)
Perl - write once, never touch again - it is near impossible to write clear readable perl = even a 20 line shell script is a pain to work with later.
Pike - nice language, but it has a very small following and limited documenation (not critical mass)
Python - unclear object instantation referencing - difficult to read if you are using a static or dynamic class reference. (I believe that has improved, but it was increadibly fustrating to deal with) - probably the only other serious competition to PHP....
Ruby - again looks like another very nice language, similar to pike, but the big issue is that critical mass is important as it affects the quality and quantity of both documentation, extensions and sample code that are made available.
So in chosing a language for phpmole, these where the factors that where important.
1. Speed of development - no double compile/execute process
2. Documentation - online (well at least for the main language)!
3. Clarity of reading pure code - following most of PEAR rules tends to make PHP that reads like a book.
4. Object orientation - just the basics!
5. Source code! - the language source was written and organized in a clear enough way that it could be fixed if necessary. = no unexpected problems.
6. Speed - since there only a small load up 'compile' penalty on the language start up, after that it behaves like any other bytecode language.
7. Similarity to C - the extension language - making it easy in theory to build accelerate a section by rewriting it in C.
8. Sample code and libraries already written that can be extended. - Although most people think of PHP as a few prints in a web page, it has a much better written set of libraries in PEAR.php.net and a big black hole of libraries from phpclasses.upperdesign.com.
9. large existing userbase - which contributes to 2 & 8 and may even contribute to the mole
10. cross platform - other than Ada (which I've never tried), the only other option would be java which has the same downsides as delphi in stability on the desktop.
Things that where not available that are not important in 98% of development - and make life confusing anyway..
1. Weird and wonderfull Object orientation and functional features - polymorphism and all those other much banded catchphrases but totally useless for rapid applicatoin development and tend to cause more problems than they solve.
The only downside that I have found so far in PHP GTK is the lack of thread support , for the most part this can be worked around (using gtk::events_pending() calls, or forking(pcntl), sockets and a bit of intelligence...), - adding threading obviously has significant downsides is that it is a large black hole of introducing bugs from poor variable locking as well.... = give yourself enough rope
Obviously with PHP5 , the multiple interitance (using aggregation), exceptions - catch throw, and yet more extensions available, It will make developing applications like phpmole will become even easier.
As far as design, from my impressions - PHP is designed to be similar to C/C++, but with variable identifiers and a simplified 'user friendly' object orientation.
anyway a discussion like this could go on for ever....
3 bad years with lisp+friends? (Score:2)
Re:3 bad years with lisp+friends? (Score:1)
Re:3 bad years with lisp+friends? (Score:4, Informative)
By "dynamic" I assume it means dynamically scoped. Lexical scoping is an important feature, introduced by Scheme in the 1970s, that today is the unquestioned best way to scope variables. Perl and Python were both dynamically scoped when first released, but switched to lexical scoping later.
Macros let you customize the language to specific application domains, resulting in very readable code. They are a feature that is difficult to duplicate in languages without lisp-like syntax. C preprocessor macros are nothing by comparison.
Autolisp missed out on a lot by not having macros. Also objects. The Common Lisp Object System (CLOS) is one of CL's most vaunted features.
I'm not saying that a LISP dialect would have been better for this particular project. It certainly fails on the "Similarity to C" qualification. Just don't take your experience with autolisp as indicative of what LISP programming is like.