Vanwaar het PHP bashen

[daaan]

Phyxion schreef op dinsdag 31 maart 2009 @ 10:48:
[...]

Het valt mij op dat iedereen die ook maar een print("Hello World"); kan zichzelf al een programmeur vind (Vooral enorm goed in PHP).

Dat heeft imho meer te maken met de persoon zelf, niet met de taal. Dit zie je met alles gebeuren. Iedereen die een CD kan afspelen is bijvoorbeeld ook meteen een DJ.
Het probleem dat PHP heeft is dat deze mensen mogelijkheden te over hebben om hun zelf gebakken code aan de wereld te presenteren. Dát hebben de andere talen niet. Maar dat is een hele andere discussie.

Ik ben het eens met de stelling dat PHP vele design flaws heeft, en dat er nogal onprofessioneel met de taal word omgegaan.
In het segment waar ik in werk (privé, mkb en gemeente's) is PHP echter prima. It gets the job done, snel en relatief goedkoop. Ik denk ook niet dat PHP ooit écht uit dit segment komt.

Wil je iets professioneler, dan zul je niet verder gaan met PHP, dit geld voor zowel als opdrachtgevers als programmeurs.

[Janoz]

YopY schreef op dinsdag 31 maart 2009 @ 11:16:
[...]


Da's op zich ook zo met Java waarbij elke Java webapp binnen een eigen proces draait (binnen Tomcat e.d.),

Dat is ook wat ik aangeef, alleen is het grote verschil dat de hele java web applicatie een 'eigen proces' heeft terwijl bij php elk los requestje in een apart afgebakend stukje zit.

echter Java neemt van zichzelf al een tig MB extra geheugen in - en blijft die vasthouden tussen requests door.

Het vasthouden is logisch wanneer je bedenkt dat een java applicatie niet 'stopt' wanneer een request afgelopen is. Daarnaast worden veel resources maar 1x geladen en voor alle requests gebruikt.

PHP daarentegen wordt alleen actief bij een enkel request, en geeft dan alle resources weer terug. Veel makkelijker te beheren e.d.

Dat is inderdaad precies wat ik eerder al aangeef.

Daardoor is Java hosting van zichzelf gewoon duurder / zeldzamer. Ik denk echter wel dat er een markt in goedkope Java hosting zou zitten, mits ze dingen als CPU usage onder een quota kunnen zetten. Maar zelfs dan - Java apps zijn van zichzelf meestal zwaarder dan PHP scripts, o.a. omdat Java gewoon uitnodigt tot goed ontwerp dat een hoeveelheid extra overhead met zich meebrengt.

Conclusie blijft inderdaad hetzelfde . Ik denk echter niet dat een goed ontwerp voor meer overhead zorgt. Het is eerder zo dat een slecht ontwerp, of fouten in je ontwerp, een veel grotere impact hebben op de gehele server. Een stackoverflow in php gooit 1 request weg. Een stackoverflow in een java applicatie zou je hele applicatie of zelfs de hele server plat kunnen gooien.

[netvor]

YopY schreef op dinsdag 31 maart 2009 @ 11:16:
Edit: Wat een geruzie / retorts / counter-retorts / counter-counter-retorts in http://wiki.python.org/moin/PythonVsPhp

Inderdaad. Wat ik persoonlijk uit de discussie meeneem:

1. PHP is meer een webtaal, Python is meer general-purpose.
2. Qua features zijn ze vrijwel identiek, echter elk mist her en der wel een feature die toevallig wel in Ada oid zit.
3. Datastructuren in Python zijn opgezet volgens schoolboeken theoretische informatica. In PHP zijn ze opgezet op een pragmatische manier.
4. Men vindt dat de structuur van Python's functies beter in elkaar steekt. Ben ik het mee eens, maar het blijft iets subjectiefs.
5. De overige 90% van de discussie is "wij schrijven precies hetzelfde in een andere syntax."

Met name punt 3 is een nieuwe insteek in deze discussie. En het blijft niet zozeer beperkt tot datastructuren: een groot contrast tussen Python en PHP is dat de eerste veel academischer is dan de laatste. Heel veel constructies in Python, en ook voorbeelden op de site, lijken rechtstreeks te zijn overgenomen uit een willekeurig boek uit de jaren '70 van Dijkstra/Lamport/etc. In PHP, zo krijg ik het gevoel, zijn dingen gedaan volgens het "wat werkt voor de users" dogma.

Wat vinden jullie?

[user109731]

MBV schreef op dinsdag 31 maart 2009 @ 11:20:
[...]
Ik vind het juist wel grappig: geen wij-van-wc-eend verhaal, omdat er ook PHP-fanboys terechte verdedigingen geven.

Ik ben vast biased als Python-aanhanger, maar veel van die verdedigingen zijn nogal flauw imho, zoals:

# classes are used extensively in the standard library
* Retort: PHP 5 has SPL which is fully class-based

Alsof SPL met z'n paar classes voor datastructuren en iterators te vergelijken is met Python, waar bijna alles netjes uit modules en classes opgebouwd is

netvor schreef op dinsdag 31 maart 2009 @ 11:45:
Met name punt 3 is een nieuwe insteek in deze discussie. En het blijft niet zozeer beperkt tot datastructuren: een groot contrast tussen Python en PHP is dat de eerste veel academischer is dan de laatste. Heel veel constructies in Python, en ook voorbeelden op de site, lijken rechtstreeks te zijn overgenomen uit een willekeurig boek uit de jaren '70 van Dijkstra/Lamport/etc. In PHP, zo krijg ik het gevoel, zijn dingen gedaan volgens het "wat werkt voor de users" dogma.

Wat vinden jullie?

Je lijkt hiermee te zeggen dat PHP sneller 'wegschrijft'? Daar ben ik het niet mee eens, juist de inconsistentie in functie-namen en functie-argumenten in PHP zijn niet pragmatisch. Ik heb in beide talen veel ervaring en heb niet het idee dat Python me veel meer tijd kost of "over-engineered" is ofzo

[netvor]

Je zou kunnen denken aan het argument dat op de bovengenoemde site gemaakt wordt: dat PHP slechts één datastructuur heeft, de array, terwijl je bij Python een verschil ziet tussen tuples, lists en dictionaries. In Python word je als programmeur toch iets meer gedwongen om vooraf na te denken wat je wilt opslaan en wat je ermee wilt doen, alvorens de juiste container te kiezen.

[NMe]

netvor schreef op dinsdag 31 maart 2009 @ 12:34:
Je zou kunnen denken aan het argument dat op de bovengenoemde site gemaakt wordt: dat PHP slechts één datastructuur heeft, de array, terwijl je bij Python een verschil ziet tussen tuples, lists en dictionaries. In Python word je als programmeur toch iets meer gedwongen om vooraf na te denken wat je wilt opslaan en wat je ermee wilt doen, alvorens de juiste container te kiezen.

PHP maakt dezelfde functionaliteit beschikbaar met maar één datatype. Dat is voor het overgrote deel van de mensen die PHP gebruiken juist fijn.

[Janoz]

netvor schreef op dinsdag 31 maart 2009 @ 12:34:
Je zou kunnen denken aan het argument dat op de bovengenoemde site gemaakt wordt: dat PHP slechts één datastructuur heeft, de array de map die ze array genoemd hebben.

[netvor]

NMe schreef op dinsdag 31 maart 2009 @ 12:44:
PHP maakt dezelfde functionaliteit beschikbaar met maar één datatype. Dat is voor het overgrote deel van de mensen die PHP gebruiken juist fijn.

Precies, PHP is gewoon veel pragmatischer opgebouwd. Of dat nou goed is of niet, daar geef ik nu geen oordeel over.

[SPee]

Doordat PHP stateless is, kan je Apache zonder problemen herstarten. Ja, de 5 requests die dan in behandeling zijn gaan dan wel mis, maar als je server over z'n nek gaat neem je dat wel voor lief

Java en .NET zijn niet stateless, geen idee hoe die daarmee omgaan. Maar pak-em-beet Python, Ruby en dat soort talen heeft dat probleem toch niet? Ach ja, ik host het zelf wel, net zo makkelijk

Dat lig eraan hoe je je applicatie geprogrammeerd hebt. Je kunt je applicatie gewoon stateless draaien, echter moet je dan alles aan je client zijde bijhouden. Dat wordt echter niet aangeraden, waardoor je veelal van server sessies gebruikt maken.
Van Java (tomcat) weet ik dat alle sessies geserialiseerd (opgeslagen) worden en bij de herstart weer ingelezen worden. Echter, het vereist wel dat alle objecten op die sessie weggeschreven en weer gelezen kunnen worden. Je moet dat alleen voor die objecten wel willen
Voor .NET zal het ook wel zo zijn.

Een voordeel van Java (en .NET) t.o.v. PHP is dat ze objecten in hun geheugen kunnen bewaren tussen de requests door. Hierdoor hoeven ze niet de data opnieuw op te halen en kan het systeem sneller reageren. Waarschijnlijk ook een reden dat Tweakers een Java applicatie voor caching gebruikt. Bij PHP ben je de data na het request weer kwijt (voor zover ik weet) waardoor het opnieuw opvragen van data intensiever voor het systeem is.

[MBV]

Janoz schreef op dinsdag 31 maart 2009 @ 12:55:
[...]

Fout, $array[0] is geen map-entry. In feite is een array een samenstelling van 2 dingen: 'gewone' array/vector/list, $array[$integer], en map, $array[$al-het-andere]. Ook al heet de variabele het zelfde, alleen die iterators werken hetzelfde

netvor schreef op dinsdag 31 maart 2009 @ 11:45:
[...]


Inderdaad. Wat ik persoonlijk uit de discussie meeneem:
[list=1]
• PHP is meer een webtaal, Python is meer general-purpose.

Zo is het wel ontworpen, maar je kan het prima voor shell-scripts (alles is beter leesbaar dan bash _{let the bashing begin} ) en door de uitbreidingen zelfs voor GUI's gebruiken. Lijkt me dus niet zo'n punt.

Met name punt 3 is een nieuwe insteek in deze discussie. En het blijft niet zozeer beperkt tot datastructuren: een groot contrast tussen Python en PHP is dat de eerste veel academischer is dan de laatste. Heel veel constructies in Python, en ook voorbeelden op de site, lijken rechtstreeks te zijn overgenomen uit een willekeurig boek uit de jaren '70 van Dijkstra/Lamport/etc. In PHP, zo krijg ik het gevoel, zijn dingen gedaan volgens het "wat werkt voor de users" dogma.

Wat vinden jullie?

Ik heb ooit tegen een professor theoretische informatica gezegd dat sommige dynamische talen lambda-functies ondersteunen. Een tip: doe dat nooit

[Patriot]

MBV schreef op dinsdag 31 maart 2009 @ 14:11:
[...]

Zo is het wel ontworpen, maar je kan het prima voor shell-scripts (alles is beter leesbaar dan bash _{let the bashing begin} ) en door de uitbreidingen zelfs voor GUI's gebruiken. Lijkt me dus niet zo'n punt.

Ik denk dat of het wel of niet gedaan wordt hier even belangrijker is dan of het mogelijk is. PHP is hoofdzakelijk een webtaal in de zin dat men het verder nauwelijks ergens anders voor gebruikt.

[Mental]

Phyxion schreef op dinsdag 31 maart 2009 @ 10:48:
[...]

Het valt mij op dat iedereen die ook maar een print("Hello World"); kan zichzelf al een programmeur vind (Vooral enorm goed in PHP).

En dat is dan weer een ontzettend nadeel voor de mensen die hier hun geld mee proberen te verdienen.
Hoe erg de taal ook rammelt, er is markt voor dus zijn er ook mensen die er graag mee werken.
Nu moet je alleen zowat een portfolio van 3 jaar laten zien voordat je eens een knappe klus krijgt.
Dus als alle hobby bob's eens stoppen met de reputatie van php te verneuken door professioneel ogende software met een backend van likmevestje uit te brengen, dan zou het er lang niet zo erg aan toe zijn.

[.oisyn]

MBV schreef op dinsdag 31 maart 2009 @ 14:11:
[...]

Fout, $array\[0] is geen map-entry.

Waarom niet? Het is niet alsof je array indices consecutive moeten zijn. Dat het integer keys heeft wil nog niet zeggen dat het een array is. Het is en blijft gewoon een (geordende) hash-map. Ook voor integer keys.

netvor schreef op dinsdag 31 maart 2009 @ 13:10:

Precies, PHP is gewoon veel pragmatischer opgebouwd. Of dat nou goed is of niet, daar geef ik nu geen oordeel over.

Of dat zo pragmatisch is is maar de vraag. Arrays zijn hashmaps, maar worden vaak gewoon behandeld als arrays (niet zo gek, gezien het feit dat je geen echte arrays hebt). Dit is nogal een gekunstel in de standaard functies die werken op arrays. Neem bijvoorbeeld array_merge():

Merges the elements of one or more arrays together so that the values of one are appended to the end of the previous one. It returns the resulting array.

If the input arrays have the same string keys, then the later value for that key will overwrite the previous one. If, however, the arrays contain numeric keys, the later value will not overwrite the original value, but will be appended.

De redenatie snap ik wel. Voor arrays wil je geen waarden overschrijven maar gewoon 2 arrays concantenaten. Voor hashmaps wil je ze combineren zodat duplicates verdwijnen. Echter, als ik m'n "array" gewoon wil benaderen als hash-map waar toevallig integer keys in staan ben ik de sjaak, omdat deze functie m'n hashmap dan ziet als array. En dit is slechts een voorbeeld, de hele array lib zit vol met dit soort dingen. Het was wellicht pragmatisch tijdens de implementatie van de taalfeature, maar zeker niet meer toen de library erbij gemaakt werd.

Overigens heeft ook javascript hier last van.

JavaScript:

var a = [];
a[100] = 34;
alert(a.length);

Jawel, 101. Terwijl er toch echt maar 1 element in staat. Wat javascript hier vooral mist is een goede manier om over alle elementen heen te lopen. for (var i = 0; i < a.length; i++) wordt meestal aangeraden, wat goed werkt voor echte arrays maar niet voor bovenstaand voorbeeld. De for (var i in a) enumereert over alle properties, dus ook custom functies die je toevallig aan Array.prototype hebt toegevoegd. Wel logisch, die functies zijn dan immers ook gewoon onderdeel van a. Maar niet altijd even handig.

[ Voor 84% gewijzigd door .oisyn op 31-03-2009 15:02 ]

[prototype]

Volgens mij is array ook gewoon een hashmap hoor zoals .oisyn stelt: voor HashMap's geldt in het algemeen gewoon dat de key eigenlijk van alles kan zijn, zolang er maar een Hash waarde over berekend kan worden om intern te hanteren als key voor de bucket.De hashfunctie voor de key hier accepteert in dat geval dan ook gewoon integers, i.e. kent een transformatie voor Int -> HashValue.

En dan gewoon het laatste woord:

An array in PHP is actually an ordered map. A map is a type that associates values to keys. This type is optimized for several different uses; it can be treated as an array, list (vector), hash table (an implementation of a map), dictionary, collection, stack, queue, and probably more. As array values can be other arrays, trees and multidimensional arrays are also possible.

http://php.net/manual/en/language.types.array.php

[ Voor 59% gewijzigd door prototype op 31-03-2009 15:28 ]

[MBV]

.oisyn schreef op dinsdag 31 maart 2009 @ 14:27:
[...]

Waarom niet? Het is niet alsof je array indices consecutive moeten zijn. Dat het integer keys heeft wil nog niet zeggen dat het een array is. Het is en blijft gewoon een (geordende) hash-map. Ook voor integer keys.

Ik heb het even opgezocht in de documentatie, in mijn herinnering werkt PHP anders met integers dan met andere objecten. En verrek, je mag er alleen maar integers of strings in gooien:

quote: http://nl3.php.net/manual/en/language.types.array.php

array( key => value
, ...
)
// key may only be an integer or string
// value may be any value of any type
[...]
A key may be either an integer or a string. If a key is the standard representation of an integer, it will be interpreted as such (i.e. "8" will be interpreted as 8, while "08" will be interpreted as "08"). Floats in key are truncated to integer. The indexed and associative array types are the same type in PHP, which can both contain integer and string indices.
[...]
Arrays and objects can not be used as keys. Doing so will result in a warning: Illegal offset type.

Nu moet ik zeggen dat dat de laatste keer dat ik het probeerde geen enkel probleem was. In PHP4 geen warning gezien.

Oh en WTF nummer zoveel in PHP: "$foo[bar]" is hetzelfde als $foo["bar"]. Logisch toch?
"Hey, it compiles! Ship it!"

De redenatie snap ik wel. Voor arrays wil je geen waarden overschrijven maar gewoon 2 arrays concantenaten. Voor hashmaps wil je ze combineren zodat duplicates verdwijnen. Echter, als ik m'n "array" gewoon wil benaderen als hash-map waar toevallig integer keys in staan ben ik de sjaak, omdat deze functie m'n hashmap dan ziet als array. En dit is slechts een voorbeeld, de hele array lib zit vol met dit soort dingen. Het was wellicht pragmatisch tijdens de implementatie van de taalfeature, maar zeker niet meer toen de library erbij gemaakt werd.

En dat was precies waar ik op doelde toen ik zei dat arrays met integers en hashmaps met strings toevallig overlappende namen hebben, maar verder weinig met elkaar van doen hebben.

[.oisyn]

En dat was precies waar ik op doelde toen ik zei dat arrays met integers en hashmaps met strings toevallig overlappende namen hebben, maar verder weinig met elkaar van doen hebben.

Dat maakt nog niet dat een PHP array ook daadwerkelijk een array is - het is gewoon een hash map . Dat je er verder geen floats in mag stoppen is trouwens ook irrelevant, de situatie had niet anders geweest als dat ineens wel had gemogen.

[ Voor 19% gewijzigd door .oisyn op 31-03-2009 16:13 ]

[prototype]

MBV schreef op dinsdag 31 maart 2009 @ 16:08:
[...]

Ik heb het even opgezocht in de documentatie, in mijn herinnering werkt PHP anders met integers dan met andere objecten. En verrek, je mag er alleen maar integers of strings in gooien:


Nu moet ik zeggen dat dat de laatste keer dat ik het probeerde geen enkel probleem was. In PHP4 geen warning gezien.

Misschien dat hij de __toString() method heeft gebruikt op het object voor de hashkey?
edit
Lijkt niet meer te werken onder PHP 5 though:

PHP:

<?php
class Foo {
    public function __toString() {
        return "foo";
    }
}


$foo = new Foo();
$ary = array();
$ary[$foo] = "hoi";

echo $ary["foo"];

?>

code:

$ php test.php

Warning: Illegal offset type in /Users/ninh/test.php on line 11

Nouja, het werkt opzich wel als je expliciet hier $foo cast naar (string) in regel 11, maar ik neem aan dat je dat niet gedaan had?

[ Voor 32% gewijzigd door prototype op 31-03-2009 16:25 ]

[MBV]

Hmm, de code was nog nét niet zo fucked up dat je de warnings uit moest zetten. Notices ($array[leuke_string], $_GET vragen die niet !isset is, datzelfde geintje met andere arrays) was 3 pagina's scrollen per pagina Leuk, legacy... [/ot]

Wat gebeurt er trouwens als je op regel 13 dit neerzet:

PHP:

print_r($ary);

[XWB]

Lijkt niet meer te werken onder PHP 5 though:

__toString() wordt enkel aangeroepen wanneer je het object afprint ( met echo, print e.d. );

/edit

Zo te zien staat dit ook in de php docs vermeld:

quote: http://be.php.net/manual/...guage.oop5.magic.tostring

It is worth noting that before PHP 5.2.0 the __toString method was only called when it was directly combined with echo() or print(). Since PHP 5.2.0, it is called in any string context (e.g. in printf() with %s modifier) but not in other types contexts (e.g. with %d modifier). Since PHP 5.2.0, converting objects without __toString method to string would cause E_RECOVERABLE_ERROR.

[ Voor 63% gewijzigd door XWB op 31-03-2009 16:32 ]

[prototype]

Hacku schreef op dinsdag 31 maart 2009 @ 16:31:
[...]


__toString() wordt enkel aangeroepen wanneer je het object afprint ( met echo, print e.d. );

/edit

Zo te zien staat dit ook in de php docs vermeld:


[...]

Dan liegt de documentatie, want __toString wordt in algemene zin gewoon aangeroepen als hij gecast wordt naar String ;-)

Zie ook:

PHP:

<?php
class Foo {
    public function __toString() {
        return "foo";
    }
}


$foo = new Foo();
$ary = array();
$ary[(string)$foo] = "hoi";

echo $ary["foo"];

?>

code:

$ php test.php
hoi

__toString wordt dus __NIET ZOZEER__ angeroepen als je iets print, maar gewoon als je het naar een string cast. En dat is nodig voor echo en printf %s.

edit
@MBV:
Indien ik het expliciet cast naar string gewoon as expected:

code:

 php test.php
Array
(
    [foo] => hoi
)

Indien ik dat niet doe en dus de warning krijg krijg ik gewoon een lege array:

code:

 php test.php

Warning: Illegal offset type in /Users/ninh/test.php on line 13
Array
(
)

[ Voor 17% gewijzigd door prototype op 31-03-2009 16:41 ]

[XWB]

prototype schreef op dinsdag 31 maart 2009 @ 16:37:
[...]


Dan liegt de documentatie, want __toString wordt in algemene zin gewoon aangeroepen als hij gecast wordt naar String ;-)

Nouja, het klopt als je PHP 5.2 of hoger draait: Since PHP 5.2.0, it is called in any string context. Dus dit geldt ook voor een cast naar string.

[vorlox]

Soms heb ik rare uitgangspunten....dus don't shoot me,
echter ik heb altijd geleerd dat software, proces ondersteunend moet zijn. en van wat ik in de praktijk meemaak lijk dat idd. ook nog eens zo te zijn.

Voorbeeld. een bat bestand kopieert bestanden van machine 1 naar server 1....dat werkte jaren goed...todat er een echte programeur kwam werken die schreef een overkoepelende applicatie in C die van machine 1 en machine 2 en machine 3 en machine 4 alles kopieerde naar server 1....
erg vet denk ik echter het proces was echt niet veranderd en de uitkomst ook niet..

Nu zouden misschien mensen kunnen zeggen ja, maar eerst moest je op elke machine een bat bestandje kopieren en nu heb je 1 server die alles regelt...dus zou je het beheer-proces ondersteunen..
Echter in de praktijk was het zo dat als er 1 machine down was ook het bat bestandje van die machine dus niet werkte, maar omdat de machine niet werkte boeide dat dus niet.
Nu werd die kopieer server opeens kritiek voor alle machines dus moest hij redundant worden uitgevoerd backups van gemaakt worden, restore procedures enz enz....en dat is dan weer extra beheer.

Zoiets zie ik met PHP ook...zolang het een proces kan ondersteunen...en flexibel is dan kan de taal me geen drol schelen of het nou in ABAP, PHP, JSP, Java, Ruby, Delphi, fortran...whatever geschreven is...

Wat ik een beetje bedoel te zeggen is dat er sommige programmeurs zijn die denken dat de programeer taal enige echte betekenis heeft...en ik denk dat dat minder waar is.

[MBV]

Grotendeels mee eens, op de vele ... na dan Voor even snel een website in elkaar flansen zal ik ook naar PHP grijpen, omdat ik daar ervaring mee heb. Dat neemt niet weg dat er veel irritante gebreken in de taal zitten.

[Gomez12]

@Vorlox : Wat jij zegt klopt mits je alles goed gedocumenteerd hebt, met 100% documentatie maakt inderdaad de methode niets meer uit, het is ten allen tijde inzichtelijk voor iedereen ( totdat je het te groot maakt en daardoor de documentatie waardeloos maar dat is een andere discussie ) alleen heb ik eigenlijk in de praktijk nog nooit iets 100% goed gedocumenteerd gezien zeg maar 1 jaar na installatie

PHP kan perfect 1 proces ondersteunen, maar wil je verschillende 20 processen ondersteunen dan heb je of een beheermodule nodig die een groot gedeelte van de lacunes in je documentatie kan opvangen of je hebt perfecte documentatie nodig om geen chaos / houtje touwtje werk te krijgen.

Als iemand mij out of the blue een stuk php laat zien met stristr en in_array erin gebruikt, dan is het voor mij absoluut niet duidelijk dat needle en haystack soms omgedraaid zijn als dit niet gedocumenteerd is, code hoort redelijk selfdocumenting te zijn imho en dat is php niet vanwege de uitzonderingen.

Als eenzame programmeur op je eigen eiland met je eigen code / als bureautje wat alleen maar php doet is dit niet erg, dan ken je de uitzonderingen.
Maar als algemene stelregel voor programmeren zijn dit soort rare ( standaard niet gedocumenteerde want het is standaard functionaliteit binnen php ) uitzonderingen gewoon waardeloos. Het is gewoon niet logisch.

[vorlox]

Ik hoopte niet dat ik ergens zei dat PHP dus consequent / goed uitgedacht was.

Vooral je punt over documentatie is volledig terecht, echter begint documenteren naar mijn idee ook niet bij de software maar bij het proces, en in je proces model zul je dus ergens kwijt moeten dat je voor bepaalde onderdelen een stuk software inzet.

Vanuit eigen ervaring kan ik vertellen dat ik meermaals meegemaakt heb dat zelfs het proces niet in kaart was gebracht, dan heb je niks aan software documentatie, want je weet niet waarvoor je het gebruikt.

Ook zou je de documentatie van de software bijna evenredig naast de functionele specs moeten kunnen leggen...want daarvanuit bouw je de software. Wat ik bedoel is dat documentatie heel belangrijk is maar dat het wel van boven naar beneden moet lopen en niet andersom.

Maar goed het heeft verder niks meer met PHP te maken.
Ik miste gewoon ergens in de discussie nog dat ondersteunende verhaal...vandaar mijn post.

offtopic:
C# for president

[ Voor 6% gewijzigd door vorlox op 31-03-2009 22:58 ]

[Stijn]

Die had ik daarnet nog gemist: NOOIT goto's gebruiken, in dit geval een while-loop o.i.d. 't zit niet eens in PHP.

Jawel!