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?

Re:Interesting

[Anonymous Coward]

You make it sound like you are one who trusts WinNT/IIS, the system that is being hacked all the time by everyone.

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!

Re:Great!

[Anonymous Coward]

dreamweaver? come on... use notepad.

Re:Great!

[hyperstation]

i sorta agree on the dreamweaver thing - dont get me wrong, i generally write all of my html with quanta or kate, but having dreamweaver around for graphically setting upt big tables saves me time

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

[TurboRoot]

PHP is what it always has been, a really great SCRIPTING language.

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

[vircum]

PHP is really designed for use as a web server module. One consequence of this is its method of importing dynamic modules: they're all loaded when php is invoked. This saves a lot of time when it's running as part of a web server and it doesn't incur startup penalty. However, this hurts when it's a standalone application. The language has strange quirks; code like $number = 20; $copy = $nunber; will actually assign the value 0 to $copy ($nunber is undefined, so it gets 0 by default). It does raise an E_NOTICE, but nobody really has error reporting for those turned on. While implicit definition of variables like that is nice sometimes in I-have-to-put-up-this-voting-booth-for-dorm-gov-in -less-than-2-minutes style scripts, it really doesn't work in large programs where it's easier to make mistakes and harder to catch them. Even the braces, as great as they are embedded in a web page, really get annoying in anything not containing a fair amount of html code.

Re:State of PHP

[Lord Puppet]

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

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

[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

[Lord Puppet]

"the only advantage of being able to use PHP outside the webserver is the ability to not learn anything else"

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

[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

[Lord Puppet]

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.

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.

Re:State of PHP

[dhalgren]

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

[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?

[akbkhome]

Autolisp - it was quite good at the time - it's just as a language it never made much sense. It doesnt compare in terms of ending up with well writen ('readable') code in C,C++ or PHP,Python,Pike etc...

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.

Re:php ain't for me

[RevAaron]

Heh. A little offended PHP people get? So I'm modded down, but no one has any defense of it? Good work, my slashkiddiez. :)

PHP is now more than a web scripting language

[Anonymous Coward]

phpmole is a start, and check this out, it was on freshmeat yesterday : a php webserver

php is becoming the next great scripting language, after all perl and python had their time :)

Re:php ain't for me

[Anonymous Coward]

fuck you, idiot.

Re:php ain't for me

[Anonymous Coward]

Heh. Further proving my point! Not only have you any real defense, you post as an AC. When it comes down to it though, I'm the one who's a schmuck- because I haven't learn to expect less from you people.

good job, that could have been bad

[Anonymous Coward]

that could have been yet another of those 'I don't like you now because you personally (even stated as such) had a problem with a particular language/technology and personally (again, stated as such) don't like it.... POOP on you, mr. evil person! I will now flail about and cry, attacking you and trying my best to make you look foolish! HOW DARE YOU?!"

It is funny how often on slashdot you have situations where someone has had problems with some technology, yet others attack them for that, because they personally have not had those problems. Instead of trying to legitimately help those people through their problems and maybe, just maybe, considering that the problems stemmed from issues in which those who did not have problems never tried, so therefore are unqualified to argue. Actually, the fact is you are NEVER qualified to argue with someone that has problems. Either they made a mistake in which you can help them solve, or they had a legitimate problem... arguing and throwing a fit on a forum (or in real life) will NOT change that. Intelligent people solve problems, monkeys rage and cover them up (yes that includes denial and hypocricy).

With that 'logic' I guess I could reason that since I have driven drunk so much and never had an accident, that it is not possible. All those others that kill innocents are just 'wrong', because there IS NO problem with drunk driving! And if you disagree with me, I will merely shout it LOUDER!

but then again

[Stalcair]

what about inheriting large web sites that use a combination of ASP, PHP, Perl and JSP that you must integrate together. (well most parts, but not necessarily all of them) Add to that non-'web based' services that are either in development or are legacy in which you must incorporate/integrate at various levels...

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!

[Stalcair]

I apparently did not want any answers, but just thought that my keyboard needed a workout. Amazing how people can get so worked up about bitching and griping, arguing and attacking each other and write megabyte sized rants... yet when it comes to a technical question/problem... all one can hear are the crickets chirping.

PHP in Action

[Anonymous Coward]

Here is PHP in action pulling quotes from Yahoo?? http://pennypros.com/picks.html