PHP-GTK based IDE for Midgard and PHP

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 ..."

Comments

Interesting

[trollbot]

With more projects like this, I look forward to the day Linux/Apache will finally be ready to compete with trusted solutions such as WinNT/IIS for mission critical systems.

PS, FP?

Great!

[NWT]

Dreamweaver is one thing why people have difficulties migrating from Windows to Linux/ I miss Dreamweaver a lot, but hopefully PhpMole will help us out of that lack. Of course there are a few great HTML editors for Linux, like bluefish, but these can't replace a good web-dev program like Dreamweaver!

State of PHP

[__past__]

Not having used PHP for about a year or so (I think it was 4.0.2 back then) and noticing that people start to use it for something roughly like real apps, could someone care to talk about whether it improved?

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

[josepha48]

Yes the for asp/vb script. I use php for small projects and have been looking for something easy to use to create the killer app. Since this allows ease of gtk app building, i.e. no need to compile and you get native gtk look and feel it is actually just another binding to gtk. This falls in with gtk-perl, gtk-tcl, gtk-, now gtk-php.

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

[Fweeky]

I'm afraid it's not changed much from that state, although some work is going into fixing some of it's biggest failings.

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

[Fweeky]

> As long as we're making a list, let's add its lack of multi-threading. Drives me crazy!

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

[Fweeky]

Good point, although it's still a good idea to look at your data from a PoV that doesn't include PHP, otherwise you end up doing what phpWiki does and having a database full of serialize()d PHP objects you can't even concider touching outside PHP.

Re:State of PHP

[einhverfr]

To be perfectly honest, I diagree slightly with the conclusion of your post. One should not expect all languages to use the same optimization proceedures, but rather design applications based on programming language.

I have been developing a HUGE web app 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

[akbkhome]

After reading some fo the previous posts, I though it would be nice to explain why I chose to write phpmole in php.. however it's a bit dificult to avoid the 'one language is better than the other ' issue, anyway this is roughly some of the reasoning.. - very much my opinion having done a bit too much PHP (or was that LSD :)

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 .Net's hidden adgenda appears to make all these language imposilbe to integrate into the .NET CLR by design (as it has design critera that alienates non declared variable languages)!

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?

[brlewis]

Can you supply more detail on your experience with "lisp and its friends"? What implementation were you using? What kind of apps? I've been quite happy using Scheme in web apps for the past few years.

Re:3 bad years with lisp+friends?

[brlewis]

Not being familiar with autolisp, I did a google search for "autolisp examples". The top hit described autolisp as follows:

AutoLISP is the scripting language for AutoCAD by Autodesk, a very crippled dynamic Lisp-1, based on very early xlisp sources (v1.0), posted by David Betz on usenet (alt.sources), and without proper copyright laws that time used by Autodesk as their free scripting language. There's an old Byte article about that.

To keep the language simple, some typical features such as macros, vectors, structs, destructive operations and objects were left out. Memory was low then in the late 80'ies. Since then the language itself was not improved at all, to keep things simple and to keep backwards portability....

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.