back to article CodeGear's Delphi PHP suite gets nip and tuck job

Borland Software's CodeGear subsidiary has refined its PHP development environment, Delphi for PHP. The tool continues to be associated with the older Delphi suite that helped make Borland's name. Delphi for PHP 2.0 features a number of changes designed to build on the Delphi reputation for rapid-application development. These …

COMMENTS

This topic is closed for new posts.
  1. Anonymous Coward
    Linux

    Platforms?

    It's a bit sad to see a company trying to make progress in a market with the free, cross-platform, open-source Eclipse (amongst others), with a paid-for Windows-only product.

    Do you not get it? Windows-only products for PHP development are ridiculous.

  2. Anonymous Coward
    Anonymous Coward

    re: Platforms

    "Do you not get it? Windows-only products for PHP development are ridiculous."

    I use the Nusphere PhpED which is windows only, and I tell you now it wipes the floor with any cross-platform IDE in both use-ability, speed and functionality!

    Unless you specifically require an IDE that works on multiple platforms, go for a PHP IDE which was designed for your OS, you'll find it faster and get a better use experience.

  3. Anonymous Coward
    Thumb Up

    Zend Studio ...

    I use Zend Studio [Professional 5.5] for my PHP development. After trying many other IDE's I finally found something that helped me a *lot*, especially the debugger. I may try the Borland one out when the Zend license is about to expire to see if it offers me anything better.

  4. Sim
    Thumb Up

    title required

    i just use editplus and xampp.

  5. Anonymous Coward
    Flame

    re: Eclipse

    Eclipse fast becoming a jack of all trades - master of bloat and not much else

  6. Jeff Dickey
    Boffin

    A Craftsman hammer vs. a Stanley hammer

    ...either will still pound nails; it's just a question of which one feels better in your hand.

    The point is...we're still in a <a href="http://en.wikipedia.org/wiki/Craft">craft-work</a>, solidly pre-engineering phase of development. The software for the Jules Verne ATV or the Boeing 787 Dreamliner may be the most complex, needful-of-near-perfection software we have yet created; amazing achievements - but still, a monumental achievement in the literal sense, on the order of <a href="http://en.wikipedia.org/wiki/Reims_Cathedral">the cathedral at Reims</a>, where major features were over-engineered by now-seemingly "ridiculous" levels because structural and materials knowledge at the time was not in any way up to today's levels.

    All the "patterns" and "best practices" and so on that have yet become reasonably widespread in our craft do not yet combine to form a body of knowledge on the same level as, say, a civil engineer's ability to predict how a dam built of certain materials to certain dimensions and located on a specific place on a river will hold back that river's water. In other words, we haven't yet met the definition of "engineering" as "using a known process to take sufficiently known inputs and produce a sufficiently knowable product, by individuals whose knowledge and/or education meets an industry-wide set of standards."

    "Software is different," you say. "Anybody can learn to do it, and we don't need no stinkin' gubbamint regulation." The first part is (technically) true, as long as quality of resulting work is ignored. As for the second.... imagine a failure scenario such as this: a "market-leading" spreadsheet, used to build the software that presents information to millions of small/midsize businesses around the world, ships an update that includes a subtle, seemingly intermittent defect. That bug happens to get exercised in complex calculations across multiple pages of a spreadsheet - say, the kind of thing that these companies use to plan and track some budgetary areas. As a result of the problem, errors are introduced into these calculations that cause American businesses collectively to "lose" billions of dollars, often going bankrupt in the process. Does anybody seriously believe that the government wouldn't - or shouldn't - intervene <em>once it were shown that the defect was a root cause of the fault</em>?

    "Poppycock", you say (if not something less printable). "THEY wouldn't ever screw up that badly." To which I have two, engineering-related, responses. First, remember the FDIV bug. Then think about pumps and dikes in New Orleans - a very engineering-aware failure.

    Finally...consider this: At what point does a recently-widespread technology or practice (such as software construction) acquire sufficient impact on and importance to public policy, safety, health and welfare that any government that fails to at least actively monitor its development and use becomes negligent in its duties? Would you want to drive a car built by home hobbyists that lacked sealed headlamps, seat belts or safety glass? Would you, as a member of the motoring public who saw that others were driving such a car, feel safe and unaffected?

    Is a world largely dependent upon a single vendor's software which exercises no effective oversight or regulation of that software, or the dependencies being built on it, truly sane? Or has it degenerated into a miasma of Randian "individualistic" groupthink that may well cost it dearly later on?

This topic is closed for new posts.

Other stories you might like