Het hoort niet in de web request processor, maar wel in de web app.:
precies wat je zegt background processing hoort niet binnen een webapp te draaien
:strip_icc():strip_exif()/u/43473/crop5e12eeae6a054_cropped.jpeg?f=community)
Verwijderd
Geen negatief beeld, een reeel beeld:
Die quote is van iemand die (net als heel veel hier) een negatief beeld van PHP wilt geven
Toch vind ik hem wel (deels) terecht::
Die quote is van iemand die (net als heel veel hier) een negatief beeld van PHP wilt geven
Vooral als een deel van een applicatie als gewoon Java draait en een deel als JSP lijkt me dit een groot voordeel.
Verder zou ik met PHP uitkijken, als je iets te kritische bug reports indient wordt je gebanned van de server.
[ Voor 9% gewijzigd door Olaf van der Spek op 16-12-2004 15:18 ]
lees het topic nog maar eens door:
[...]
Geen negatief beeld, een reeel beeld
de meeste weten echt niet waar ze over praten, maargoed deze discussie is ook niet nuttig, Java is meer dan alleen webapplicaties en PHP is speciaal daarvoor gemaakt, een appel en een peer vergelijken is ook niet goed mogelijk behalve dat ze allebei gegeten kunnen worden kan je er niet meer over zeggen.
Gebruik gewoon de taal waar die volgens jou het best ingezet kan worden.
PHP ljikt erg veel op andere talen dus dat je wat nieuws moet leren is onzin, daarnaast, als je altijd in taal X hebt geprogrammeerd dan is het logisch dat je wat moet leren voor taal Y, raar argument imo.
PHP heeft ook erg veel mogelijkheden voor db en networking etc, ook geen argument.
Verder zou ik met PHP uitkijken, als je iets te kritische bug reports indient wordt je gebanned van de server.
[ Voor 34% gewijzigd door Erkens op 16-12-2004 15:22 ]
:strip_exif()/u/22119/ch.gif?f=community)
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Welke normale desktop/server app geschreven in PHP heb jij dan waarvan je code hergebruikt in web scripts?:
kan ik ook met PHP, onzin argument dus
Verwijderd
Dit is een discussie waar we nooit uit gaan komen omdat iedereen z'n eigen voorkeuren heeft en natuurlijk z'n eigen platform als het beste ziet... anders werk je er niet mee, toch? Ik heb in Java, PHP en C# aan verschillende middelgrote projecten (mee)gewerkt en ze zijn alledrie goed, anders waren ze niet zo populair! Dit onderstreept alleen mijn punt van enkele pagina's terug dat de keuze voor een bepaald platform gewoon afhankelijk is van de voorkeur en de ervaring van de programmeur(s).
Nogmaals, je bent appels met peren aan het vergelijken. De taal PHP is gewoon anders en doet vanaf versie 5 zeker niet meer onder voor Java. Zoals Zef al zei, zie ook Bruce Eckel's Strong typing versus Strong testing
Wat wil je hiermee nou zeggen? Als ik utility spul in C++ ofzo heb, zou ik dus webapplicaties in C++ moeten gaan maken? Nee, dank je
Dit onderstreept alleen mijn punt van enkele pagina's terug dat de keuze voor een bepaald platform gewoon afhankelijk is van de voorkeur en de ervaring van de programmeur(s).Wat dit betreft zijn JSP's en pagina's met inline PHP goed te vergelijken. In JSP's kun je ook een gigantische puinzooi bouwen als je geen fatsoenlijk ontwerp maakt. Dit is iets wat vaak als nadeel van PHP wordt aangehaald, maar het ligt wederom gewoon aan de programmeur/ontwerper om dit goed op te lossen.
Als je een significante hoeveelheid relevante code hebt is dat misschien niet zo'n gek idee.:
Wat wil je hiermee nou zeggen? Als ik utility spul in C++ ofzo heb, zou ik dus webapplicaties in C++ moeten gaan maken? Nee, dank je
Verwijderd
Ik vind de taal zelf niet geschikt vanwege de vele mogelijke 'unsafe' constructies. Ik zie C++ eigenlijk alleen als handig om af en toe wat low-level dingen te bereiken via JNI, maar graag gebruik ik het zeker niet... Weer een voorbeeld van mijn stelling dat de voorkeur voor een platform meestal subjectief is.
Maar laten we C++ maar verder helemaal buiten beschouwing laten, anders hebben we dalijk nog een taal erbij waarover we kunnen discussieren
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Hoe meer hoe beter toch?:
Ik vind de taal zelf niet geschikt vanwege de vele mogelijke 'unsafe' constructies. Ik zie C++ eigenlijk alleen als handig om af en toe wat low-level dingen te bereiken via JNI, maar graag gebruik ik het zeker niet... Weer een voorbeeld van mijn stelling dat de voorkeur voor een platform meestal subjectief is.
Maar laten we C++ maar verder helemaal buiten beschouwing laten, anders hebben we dalijk nog een taal erbij waarover we kunnen discussieren
Maar volgens mij denk je meer aan C-style constructies.
C++-style constructies (std::string, smart pointers, smart wrappers) zijn erg eenvoudig om te gebruiken en gewoon safe.
Het 'grote' probleem met C++ is eigenlijk dat je een cross compiler nodig hebt of het server platform zelf. Voor grote projecten is dat geen issue, maar voor veel hobby/prive projecten wel.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Het was ook alleen maar als grapje bedoelt hoor
Tuurlijk kun je overigens C++ gebruiken, alleen is dat dan vaak niet wel overwogen. Want waarom zou je het wiel opnieuw uitvinden als bij de buren complete frameworks klaarliggen. Dan schrijf je een framework waar niemand verstand van heeft. Conclusie, niet handig om C++ te gebruiken.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Omdat threads per definitie dezelfde address space delen. In C++ kun je als er wat fout gaat perongeluk geheugen beschrijven wat niet door jou gealloceerd is. (bv een simpele toekenning aan een element buiten de grenzen van een array).
Je kunt dus niet gemakkelijk requests door verschillende threads laten afhandelen in C++. Als er wat fout gaat beinvloed dat alle users, niet alleen de user die de request deed waarin er wat fout ging.
Je zou in C++ dus eerder voor processen gaan om requests af te handelen. Een context switch voor een process is echter veel zwaarder als bij een thread.
Dit heb jij als het goed is bij het vak Operating Systems uitgebreid gehad.
(en hopelijk komt .oisyn nu met een mooie methode waarmee het toch wel kan
)
[ Voor 5% gewijzigd door Verwijderd op 16-12-2004 19:05 . Reden: hoop doet leven ]
Verwijderd
Kijk, zijn we toch nog over C++ aan het discussieren...
Mijn punt (dat waarschijnlijk weer nergens op slaat volgens .Oisin
) is dat een web omgeving nogal wat overhead met zich mee brengt, zoals het verwerken van de textuele HTTP requests, de traffic, het webserver of applicatieserver proces zelf, authenticatie, opbouw van pagina's op de client etc. Door deze overhead zal de tijd en het geheugen dat je webapp nodig heeft om puur een request af te handelen slechts een fractie zijn van het totaal wat nodig is voor de hele omgeving. Hierdoor denk ik dat de performance en memory use wat je zou besparen met C++ geen goed argument is om voor webapps in C++ te kiezen. Tuurlijk kun je dan ook je hele omgeving in C++ gaan proggen, maar dan ben je echt het wiel 3 keer opnieuw aan het uitvinden.
Hoe je het dan wel zou moeten oplossen weet ik ook niet zo snel, maar je zou inderdaad kunnen denken aan een desktop client die rechtstreeks met een DB kan communiceren en waarvan de GUI onderdelen ook beter op de te tonen data zijn afgestemd (table component i.p.v. html table enzo).
in mijn geval dan andersom, maar ik heb een aantal PHP shell scripts die enorm krachtig zijn en diverse zaken regelen, en dus kan ik die code ook weer hergebruiken in andere scripts
Verwijderd
Lees je eigelijk wel, ik schrijf toch nergens dat C++ programmeurs duurder zouden zijn dan andere programmeurs
Alleen een programmeur is nou eenmaal duur en hardware goedkoop. Zodoende kies je een taal waar je zo min mogelijk hoeft te programmeren door verscheidene (defacto standaard) frameworks die beschikbaar zijn. Deze frameworks zijn dan ook bekend bij toekomstige programmeurs waardoor aanpassingen makkelijker kunnen worden doorgevoerd. Tevens kunnen ze zich dan bezig houden met de business logic in plaats van de taal.
Al met al kies je dus eigelijk heel vaak niet voor C++
Alleen een programmeur is nou eenmaal duur en hardware goedkoop. Zodoende kies je een taal waar je zo min mogelijk hoeft te programmeren door verscheidene (defacto standaard) frameworks die beschikbaar zijn. Deze frameworks zijn dan ook bekend bij toekomstige programmeurs waardoor aanpassingen makkelijker kunnen worden doorgevoerd. Tevens kunnen ze zich dan bezig houden met de business logic in plaats van de taal.
Al met al kies je dus eigelijk heel vaak niet voor C++
Realtime is heel wat anders, ik heb het gewoon over pure performance. Realtime hoeft niet snel te zijn, het zegt puur dat je garanties kan geven over hoe lang iets duurt en dat het binnen die tijd ook echt klaar is.
Nou kan ik alleen spreken over windows omdat ik daar ervaring mee heb, maar je kunt (structured) exception handling gebruiken om fouten als page faults en access violations e.d. af te vangen. Met standaard c++ exception handling (try/catch) of met structured exception handling (__try/__except), hangt een beetje van de gebruikte compile optie af. In principe kun je dus elke thread guarden tegen exceptions en dus killt het niet het hele proces. En als safety een issue is, en performance niet (wat meestal het geval is bij simpele webapps) kun je natuurlijk altijd custom classes gebruiken zodat je nooit buiten de array bounds of naar dangling pointers kan schrijven. C++ kan zo veilig zijn als je het zelf maakt:
Omdat threads per definitie dezelfde address space delen. In C++ kun je als er wat fout gaat perongeluk geheugen beschrijven wat niet door jou gealloceerd is. (bv een simpele toekenning aan een element buiten de grenzen van een array).
Je kunt dus niet gemakkelijk requests door verschillende threads laten afhandelen in C++. Als er wat fout gaat beinvloed dat alle users, niet alleen de user die de request deed waarin er wat fout ging.
Je zou in C++ dus eerder voor processen gaan om requests af te handelen. Een context switch voor een process is echter veel zwaarder als bij een thread.
Dit heb jij als het goed is bij het vak Operating Systems uitgebreid gehad.
(en hopelijk komt .oisyn nu met een mooie methode waarmee het toch wel kan
Je kunt beter helemaal niets zomaar roepen zolang je er (nog) niet veel ervaring mee hebt
Dat is toch geen keuze die je hebt? Als je een webapp moet maken die goed moet performen, dan kun je toch niet kiezen om dan maar geen webapp te maken? Waarom zou een webapplicatie niet gewoon goede performance nodig kunnen hebben? Neem bijvoorbeeld een webbased game waar duizenden mensen tegelijk aan meedoen, C++ zou daarvoor echt de perfecte keus zijn.
Ik denk dat jouw beeld van een webapplicatie toch meer iets van een simpel pagina-genererend iets is dat een verbinding heeft met een bepaalde database (zoals de meeste projecten die in PHP geimplementeerd worden). Maar een webapplicatie kan in principe alles zijn, van een visitor counter tot een fullblown webbased game, of misschien een game in een java applet die weer verbinding maakt met een server (ja die server is ook een webapp en ook te implementeren met talen als PHP en Java)
Dikke onzin. Ervan uitgegaan dat je het over C++ hebt, waar deze discussie over gaat, want C is over het algemeen idd een slechte keuze
Nou hier bijvoorbeeld: Verwijderd in "[JAVA] vs [PHP] wat is de meerwaarde?":
Lees je eigelijk wel, ik schrijf toch nergens dat C++ programmeurs duurder zouden zijn dan andere programmeurs
En wie zegt dat een dergelijke webinterface niet voor C++ bestaat? Sterker nog, je kunt in native C++ ook gewoon managed C++ gebruiken en dus heb je direct toegang tot een hele mooie webinterface.
[ Voor 8% gewijzigd door .oisyn op 17-12-2004 11:14 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Geschikt, je kunt het met de taal realiseren
Ongeschikt, het is veel te duur
En de laatste weegt uiteraard vele malen zwaarder
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Nee, jouw redenatie was gebaseerd op het feit dat je in C++ nog een heel framework moet ontwikkelen, we gingen er even vanuit dat die er al was (zie onderste regel van OlafvdSpek in "[JAVA] vs [PHP] wat is de meerwaarde?").
Ik zou een php-er sowieso niet betalen, daar heb ik niets aan
Maar even serieus, daar hebben we het al over gehad en dat was geen issue
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Geloof me, dat zal ik ook niet meer doen als ik naar de antwoorden op m'n post kijkJe kunt beter helemaal niets zomaar roepen zolang je er (nog) niet veel ervaring mee hebt
Maar het ging zich dus gewoon om het voorbeeld. Enfin...Dan heb ik je het verkeerde idee gegeven.
Mijn punt was dus dat bij WebApps op andere plaatsen een veel relevantere performance gain kan worden gehaald, dan de relatief lage gain die je zou bereiken door voor C++ te kiezen voor je WebApp.
Bijvoorbeeld bij het weergeven van database gegevens. Dit kan idd in een webapp (phpMyAdmin), maar het opbouwen van de HTML op de client alleen al duurt waarschijnlijk langer dan de hele server-side processing. In dit geval is een desktop applicatie met specifieke code en GUI voor dit soort data (MySQLFront) misschien een beter keuze.
Hetzelfde geldt voor jouw voorbeeld van een online spel. Door bijvoorbeeld een applet of Flash te gebruiken op de client ipv. (D)HTML verbeter je de performance van de gehele omgeving (dus client en server, want dat is tenslotte de 'webapp') waarschijnlijk meer dan door je backend in C++ te gaan schrijven.
En dan nog, hoe ga je vanuit je applet communiceren met je backend? Als je het netjes wilt doen via SOAP en anders via standaard HTTP requests. Ik waag te beweren dat in het licht van de overhead van deze request de performance gain die je met C++ kunt behalen in het niet valt.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Ik denk dat we hier nooit uit gaan komen
In mijn ogen is de complexiteit van de logic aan de serverkant inderdaad niet zo gigantisch spannend. Als je het over echt complexe logic hebt, waar heb je het dan over?
Gegevensverwerking? Daar heb je een DBMS of ander systeem voor om dat mooi op te lossen, waar je webapp weer gebruik van kan maken. Complexe business logic? Delegeer het maar naar het ERP systeem. Bewerken van afbeeldingen? Ook daar heeft zo'n elke webapp taal wel een efficiente library voor die dit voor je kan oplossen. Etc.
Ik ben het met je eens dat het theoretisch mogelijk is dat je zo'n complexe actie moet ondernemen op een request dat je deze extra performance & efficiency van C++ zou kunnen gebruiken, maar ik weet zo snel dus echt niet waarvoor ik het zou moeten gebruiken. Als je een concreet voorbeeld weet dan hoor ik het graag en geef ik me gewonnen
[ Voor 4% gewijzigd door Verwijderd op 17-12-2004 14:12 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
... http://www.tdzk.com/external/statistics.php ...
[ Voor 38% gewijzigd door Verwijderd op 17-12-2004 14:44 ]
Ja heel TDZK is in php gemaakt, het loopt dan ook niet zo heel erg soepel
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_exif()/u/73955/foxavatar-60.gif?f=community){kind=avatar}
Euh, wrong. Ik vind PHP een fijnere, betere taal dan Java. Gebruik Objectieven argumenten a.u.b., geen subjectieve.
Dit is geen strict Java vs PHP argument. Maar eerder (net als je hierboven aangeeft) een switch-argument. Waarom zou je moeten switchen van Java naar PHP. Laat mij die vraag omdraaien. Neem een doorgewinterde PHP-programmeur. Eentje die geen prutser is, en al zoveel generieke classes heeft (en zelfs allemaal omgebouwd naar PHP5
). Waarom zou hij dan moeten switchen naar Java voor webapps? Je argument raakt kant noch wal.Hier kom ik later in mn post op terug.
Ik zal je dan even uit de droom helpen. TU/e, wat heb ik geleerd. Hmz, begonnen met Pascal, toen algoritmen leren ontwikkelen in GCL (Guarded Command Language, kennen jullie verder vast niet, is ook geen ge-implementeerde taal.), daarna hebben we C gebruikt, toen PHP voor een webwinkel. (Ja, met heuse business logic erachter.) En ook nog ergens wat assembly tussendoor. Al met al redelijk gevarieerd dus.
Vraagje? Heb je zelf een universitaire opleiding gedaan? Ik kan niet spreken namens HBO opleidingen, maar een van de eerste dingen die je leert op de universiteit is dat een taal een middel is, en geen doel. Wij 'leren' dus ook geen talen, wij 'gebruiken' talen. Een taal leren doe je maar in je vrije tijd, is het idee.
Als er werkelijk hier iemand is die zegt dat het beter is om een project met webshops op de universiteit in Java te doen dan in PHP, dan lach ik hem vierkant uit. Het leerporces zit hem niet in het uiteindelijk afgemaakte product, maar in de stappen die leiden tot dat product. En als je eerst 5 weken aan het kutten bent om Java onder de knie te krijgen, blijft er weinig tijd over om een zinnige implementatie te maken. PHP heeft een lichtere leercurve dan Java, en is in dat opzicht dus juist een geschikte taal om in het onderwijs te gebruiken.
Fout dus. Zie mijn webshop voorbeeld. En ik ken zat HBO-ers die voor stages dingen in PHP hebben gemaakt. Vast voor 'gewone' schoolopdrachten ook wel, maar dat zou ik moeten navragen.
Overtuig mij er eens van dat een Java-webapp implementatie sneller is in string en array manipulaties dan PHP?
Gelukkig zegt iemand hier wel nog wat zinnigs. Er zijn dus hier mensen, die, als ik ze moet geloven. Liever iemand aannemen omdat hij Java doet en geen PHP. Ik zou zeggen, kijk wat ze kunnen, ipv waarin ze het liefste werken. Maar goed, dit is weer hetzelfde argument wat ik al eerder gebruiktte. Er zijn zat prutsers die java doen. Je komt alleen eerder in aanraking met PHP-prutsers, omdat java-gepruts vaak niet web-related is; en omdat er teveel niet-programmeurs zijn die zich met PHP bezig houden.
Dit is een perfect voorbeeld van de multi-inzetbaarheid van PHP. Henk_de_man gaf aan dat java zo universeel was, etc..etc.. Nou, PHP is misschien niet geschikt voor desktop application use. Maar het is in te zetten op de commandline. (Doe ik zelf met redelijk wat dingen, te lui om bash-scripting fatsoenlijk te leren.
)Verder is PHP prima te combineren met andere talen. Laat een PHP script lekker de frontend doen, en doe het 'dure' werk met C++ bijvoorbeeld. Een perfect voorbeeld hiervan is .oisyn's highlighter. Dat is een in C++ geschreven module voor PHP use. Dat java 'alles kan' wil niet zeggen dat het 'alles het beste kan'.
Ik weet niet meer wie het had geschreven, maar ik las ergens hierboven iets van code copy/pasten binnen java. Als je Java's genericiteit en uitbreidbaarheid als sterk punt voor Java wilt aanprijzen, kom dan alsjeblieft niet met ranzige dingen als copy/pasten aanzetten. Bah.
sorry voor de lange post en voor het replyen op posts van 3 pages terug, ben een paar dagen niet actief geweest op GOT.
Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info
Omdat (oa) Java een andere, meer maintainable approach geeft. PHP is heel erg request based en behoorlijk stateless, alles wordt keer op keer opnieuw geparsed, gecompiled en uitgevoerd, connecties worden aangemaakt en weer verbroken, alle persistente data moet steeds opnieuw worden ingeladen. Ik kan me voorstellen dat je op een gegeven moment liever hebt dat je een persistente app hebt, en dat er een bepaalde functie in je app wordt aangeroepen op het moment dat er een request binnenkomt. De data staat dan gewoon al in het geheugen en je kunt je puur concentreren op het afhandelen van de request. Plus dat je nog dingen kunt doen op het moment dat je geen request af hoeft te vangen, wat in PHP een stuk trickier is.:
Dit is geen strict Java vs PHP argument. Maar eerder (net als je hierboven aangeeft) een switch-argument. Waarom zou je moeten switchen van Java naar PHP. Laat mij die vraag omdraaien. Neem een doorgewinterde PHP-programmeur. Eentje die geen prutser is, en al zoveel generieke classes heeft (en zelfs allemaal omgebouwd naar PHP5
Al met al kan ik me dus goed voorstellen dat je op een gegeven moment over wilt schakelen als je meer uit een systeem wilt halen dan PHP je kan bieden.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Wie zegt dat hij moet switchen?:
Dit is geen strict Java vs PHP argument. Maar eerder (net als je hierboven aangeeft) een switch-argument. Waarom zou je moeten switchen van Java naar PHP. Laat mij die vraag omdraaien. Neem een doorgewinterde PHP-programmeur. Eentje die geen prutser is, en al zoveel generieke classes heeft (en zelfs allemaal omgebouwd naar PHP5
Er is alleen gezegd dat het waarschijnlijk(er) is dat een organisatie of persoon ook gewone apps maakt en dat die niet in PHP maar in C++ of Java geschreven zijn.
Dat werkt alleen als je dure pure functies hebt (die dus geen of weinig non-local state gebruiken).
[ Voor 15% gewijzigd door Olaf van der Spek op 17-12-2004 15:21 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Aangezien dit topic toch al helemaal stuurloos is, wil ik nog even 1 ding kwijt wat ik zo geweldig vind aan PHP.
Er is vaak het argument tegen PHP aangehaald in dit topic dat het elke keer opnieuw wordt geparsed, dat het nogal rommelig met fouten omgaat en dat types ontbreken. Dat mag dan wel zo zijn, maar daarvoor krijg je wel een ongelofelijke dynamiek en vrijheid voor terug.
Als voorbeeld heb ik iets wat ik net heb gemaakt voor m'n PHP webapp (jaja, af en toe werk ik ook nog ). Ik moet bepaalde events naar het Windows event log kunnen schrijven. De gewone PHP syslog voldoet niet omdat ik m'n events graag in een log wil zetten waarin alleen events van mijn applicaties komen te staan. Dus heb ik ff een kleine utility class geschreven in C# en deze als COM lib geregistreerd. Nu kan ik in PHP het volgende doen:
Probeer dat maar eens op een ander platform
Er is vaak het argument tegen PHP aangehaald in dit topic dat het elke keer opnieuw wordt geparsed, dat het nogal rommelig met fouten omgaat en dat types ontbreken. Dat mag dan wel zo zijn, maar daarvoor krijg je wel een ongelofelijke dynamiek en vrijheid voor terug.
Als voorbeeld heb ik iets wat ik net heb gemaakt voor m'n PHP webapp (jaja, af en toe werk ik ook nog
). Ik moet bepaalde events naar het Windows event log kunnen schrijven. De gewone PHP syslog voldoet niet omdat ik m'n events graag in een log wil zetten waarin alleen events van mijn applicaties komen te staan. Dus heb ik ff een kleine utility class geschreven in C# en deze als COM lib geregistreerd. Nu kan ik in PHP het volgende doen:PHP:
1
2
| $sysLog = new COM ("LogLibrary.SysLog"); $sysLog->Log("App name", "Event title", "Event message", E_USER_WARNING); |
Probeer dat maar eens op een ander platform
[ Voor 8% gewijzigd door Verwijderd op 17-12-2004 15:52 . Reden: Ik kan echt niet ypen vandaag ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Daar ben ik het helemaal mee eens, en dan moet ie er niet op ingaan als ik zeg dat je in sommige gevallen wel voor C++ zou kiezen
Ik heb nooit beweerd dat het gebruik van C++ net zo handig is als php of java, voor een web interface. Alleen dat er wel situaties denkbaar zijn waarin het gebruik van C++ voordelen heeft tov andere talen (en dan bedoel ik dus dat de voordelen wél opwegen tegen de nadelen).
.edit: ik moet wel toegeven, nu ik de posts allemaal nog eens doorlees, dat ik zelf ook wel schuldig ben aan het te zwart-wit opvatten van bepaalde opmerkingen. Mijn excuses daarvoor
Ik heb nooit beweerd dat het gebruik van C++ net zo handig is als php of java, voor een web interface. Alleen dat er wel situaties denkbaar zijn waarin het gebruik van C++ voordelen heeft tov andere talen (en dan bedoel ik dus dat de voordelen wél opwegen tegen de nadelen).
.edit: ik moet wel toegeven, nu ik de posts allemaal nog eens doorlees, dat ik zelf ook wel schuldig ben aan het te zwart-wit opvatten van bepaalde opmerkingen. Mijn excuses daarvoor
[ Voor 136% gewijzigd door .oisyn op 17-12-2004 17:46 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_icc():strip_exif()/u/77332/crop5e54ec42433bc_cropped.jpeg?f=community)
COM objecten aanspreken? Mocht dat zo zijn;:
PHP:
Probeer dat maar eens op een ander platform
Visual Basic .NET:
1
2
3
| Dim X X = CreateObject("LogLibrary.SysLog") X.Log("","","", <getal>) |
Of,
Delphi:
1
| X := CreateOleObject("LogLibrary.SysLog"); |
Of mis ik je punt?
[ Voor 13% gewijzigd door PrisonerOfPain op 17-12-2004 18:19 . Reden: Syntax... ]
Verwijderd
Een beetje. COM objecten aanspreken is idd niet zo bijzonder, maar PHP zorgt er zonder wrappers of wat dan ook voor dat je de methods & properties op het COM object kunt aanroepen alsof je met een PHP object te maken hebt. Dat VB dit kan mag ook wel, aangezien het hele COM gebeuren het idee van MS is, maar ik vond het gewoon mooi dat ze PHP ook zo flexibel hebben gemaakt. Hetzelfde kan in PHP trouwens ook met Java objecten en rechtstreeks met .NET classes (zonder COM interop, maar da's nog experimenteel).
Maar goed, ik stop met posten in deze thread. Elke keer als ik een voorbeeld aanhaal kan ik weer nog verder off-topic gaan uitleggen wat ik bedoel. Zo zijn we op C++ gekomen en nu zijn we weer aan het discussieren over hoe makkelijk je ook in andere talen COM objecten kunt aanroepen.
:strip_icc():strip_exif()/u/46177/FoX-icon.jpg?f=community){kind=icon}
:strip_icc():strip_exif()/u/69009/eend.jpg?f=community)
Je kan zelf de scheiding bepalen, dat is wat anders dan dat het standaard gebeurt maar mogelijk is het.
networking en db acces zijn gewoon mogelijk lijkt mij?
bewijs? Ik dacht dat het geen verschil maakte aldus een onderzoek maar ik kan me natuurlijk vergissen.
zie vorige
als apache module draaien?
er staat zelfs een regelnummer bij volgens mij hoor.
Wat weerhoudt je er van om hetzelfde te doen in PHP?[/quote]
controleerd Java dan wel semantiek? De syntax errors worden overigens wel er uit gehaald door PHP door middel van een error. Laat maar ergens een puntkomma weg.
waarom is dat zo? Als het te kostbaar wordt kunnen ze er mee stoppen als ze willen. Bij een community gebeurt dit niet zo snel aangezien ze geen winst of verlies hoeven te maken. Maar zelf buiten dat is het geen echt argument omdat het altijd kan stoppen.
Klopt sommige zaken worden bij PHP inderdaad aangepast of vervangen. In de meeste gevallen blijft de oude methode echter nog een versie gehandhaafd.
Juist en dat kan zeker niet met PHP?
Wat houdt security ondersteuning in? Verder kan je gerust logging en monitoring in PHP implementeren maar het is inderdaad niet standaard. Transacties voor de code zelf bestaan inderdaad niet, de meeste databases hebben echter wel deze functionaliteit.
cijfers graag
niemand houdt je tegen in PHP om hetzelfde te doen, het komt zelfs vrij vaak voor dat dit gebeurt.
zou goed kunnen dat weet ik niet. Maar je punt is me sowieso niet duidelijk: met PHP kan je ook snelle applicaties kunnne maken.
geen idee, zou ook te maken kunnen hebben met het imago van PHP, geen feitelijke reden voor zover ik weet.
Die hebben we al gehad
welke van de 4?
Wat bedoel je hier precies mee? Wat zou dat volgens jou in moeten houden?
:strip_icc():strip_exif()/u/26612/droptikkels_icon.jpg?f=community){kind=icon}
Jammer, dit topic was in het begin best interessant, nu is het Java kamp tegen het PHP kamp aan het knokken.
Met .oisyn als C++ hippie die er omheen danst
Met .oisyn als C++ hippie die er omheen danst
Nah, het stoort me gewoon dat mensen eerst je mening vragen, en vervolgens in hun samenvatting gewoon al je tergenargumenten genegeerd hebben.:
Jammer, dit topic was in het begin best interessant, nu is het Java kamp tegen het PHP kamp aan het knokken.
Met .oisyn als C++ hippie die er omheen danst
Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info
Ligt blijkbaar toch bij de programmeur zelf, ns.nl is ook niet echt uhm, stabiel om het zo maar te zeggen. Bij het manipuleren van een paar parameters kun je al null-pointer exceptions krijgen, en er kan html injection toegepast worden op de site zelf.
Nogmaals, heeft dus niets met de taal te maken
Mja, uiteraard. Ik ben zelf niet zo thuis met Java, dus kan daar niet zo diep op ingaan. Maar, in de verdediging van Java, PHP kan i.c.m. misconfiguraties in Apache nogal gevaarlijk zijn. Nu valt dat sinds PHP4/5 al flink mee. (register_globals, o.a.), maar je blijft toch altijd wat punten hebben. Veel van die punten zullen er bij Java ook zijn, maar die ken ik verder niet.:
[...]
Ligt blijkbaar toch bij de programmeur zelf, ns.nl is ook niet echt uhm, stabiel om het zo maar te zeggen. Bij het manipuleren van een paar parameters kun je al null-pointer exceptions krijgen, en er kan html injection toegepast worden op de site zelf.
Nogmaals, heeft dus niets met de taal te maken
Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info
:strip_exif()/u/26373/anim4.gif?f=community)
Goed.... uit dit topic blijkt maar weer dat liefhebbers van twee talen elkaar lekker in de haren kunnen vliegen
Java valt aan, PHP verdedigt.. en andersom. Daarnaast mist er over de gehele thread gekeken ook te vaak een fatsoenlijke onderbouwing. Het begint hier nu echt op een holy war te lijken. Mocht je echt nog iets toe te voegen hebben met een fatsoenlijk onderbouwing (dus geen lijstje met alleen voor en nadelen, maar elk punt fatsoenlijk onderbouwt): voeg gerust nog een post toe. Op het moment dat er weer met modder en slechte/niet onderbouwde posts gesmeten wordt dan gooi ik hem dicht, want de pret heeft nu wel lang genoeg geduurt en eruit komen doen we toch toch niet
Java valt aan, PHP verdedigt.. en andersom. Daarnaast mist er over de gehele thread gekeken ook te vaak een fatsoenlijke onderbouwing. Het begint hier nu echt op een holy war te lijken. Mocht je echt nog iets toe te voegen hebben met een fatsoenlijk onderbouwing (dus geen lijstje met alleen voor en nadelen, maar elk punt fatsoenlijk onderbouwt): voeg gerust nog een post toe. Op het moment dat er weer met modder en slechte/niet onderbouwde posts gesmeten wordt dan gooi ik hem dicht, want de pret heeft nu wel lang genoeg geduurt en eruit komen doen we toch toch niet
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
:strip_icc():strip_exif()/u/92327/Image1.jpg?f=community)
Verwijderd
Websjwans, als je het volgende beweert,
Moet je niet gaan mekkeren als iemand je punt nogal simpel onderuit haalt.:
Nu kan ik in PHP het volgende doen:
PHP:
Probeer dat maar eens op een ander platform
Nogal jammer. Incasseren en fouten toegeven is ook onderdeel van het leven
Verwijderd
Fox had wat "feiten" op een rij gezet maar daar klopt eigenlijk bar weinig van
• Java wordt ondersteund door grote bedrijven (Sun, IBM, ..) waardoor de toekomst die Java heeft eens temeer verzekert wordt
• In de Java taal wordt goed gedefinieerd wat wel en niet compatible is en blijft. Daarnaast is refactoring geen optimalisatie methode. (ik heb nog nooit een programma sneller zien worden van het hernoemen van een functie ) Ook is de snelheid van het optimaliseren niet echt relevant, relevant is hoe snel de code na optimaliseren is. Dat is iets anders.
Als je dan feiten wilt weergeven, zouden deze 12 pagina's discussie toch op zijn minst het idee naar boven moeten brengen dat niet alles zo simpel is als het lijkt. PHP is gewoon vaak een goede taal. Als je dan een opdrachtgever wil overtuigen gebruik dan geen argumenten waarvan je bij voorbaat al weet dat ze erg makkelijk onderuit gehaald kunnen worden. Zoals ik al eerder gezegd heb, overtuig een opdrachtgeven door middel van de methode waarop jij het zou aanpakken en wijs hem op de voordelen voor hém van die methode. MVC? Wat is dat?, Foutboodschappen? Die ziet de opdrachtgever toch niet. enz.
Het eerste is waar, maar heeft op zich natuurlijk weinig te maken met de mate van gestructureerdheid van de code
Het is bij elke programmeertaal (vrijwel) onmogelijk te verklaren dat je code bugvrij is. MS is het in ieder geval nog steeds niet gelukt en ook Linux barst van de bugs. Runtime errors zijn niet erger of minder erg dan compiler errors. Het gaat erom dat een programma doet wat het moet doen, niet of het wel of niet compileert.
Niet correct, op Windows draait PHP als een DLL.
Mening, geen feit.
PHP is heel goed te managen met bestaande tools. 1 file, So what, en gestuctureerde managment interface is belangrijker (en heeft PHP) en voor een client is het eigenlijk helemaal oninteressant
Zie hierboven. Welke zekerheid heb je? De code voldoet aan de syntax, inhoudelijk zegt het nog niets. "De Peer zegt dat de Boekenlegger goud moet comprimeren." Begrijp jij het? Toch is het correct nederlands.
• Java wordt ondersteund door grote bedrijven (Sun, IBM, ..) waardoor de toekomst die Java heeft eens temeer verzekert wordt
• In de Java taal wordt goed gedefinieerd wat wel en niet compatible is en blijft.
Dat doet java niet, dat doet de programmeur! In PHP is dit ook mogelijk.
PHP ondersteund login forms, https dus een vorm van security, Php ondersteund database transacties en monitoring en logging. Zonder op java specifieke zaken in te gaan zoals EJBs is dit eigenlijk veel te ruim gedefineerd ofwel pure onzin (take your pick)
Gebaseerd op wat? Weer een mening, zeker geen feit.
Technisch is een PHP applicatie ook op te splitsen volgens het MVC patroon. Standaard java ondersteund trouwens geen MVC, daar heb je aparte libs (zoals struts) voor nodig.
Goede code behoeft geen refactoring.
Daarnaast is refactoring geen optimalisatie methode. (ik heb nog nooit een programma sneller zien worden van het hernoemen van een functie ) Ook is de snelheid van het optimaliseren niet echt relevant, relevant is hoe snel de code na optimaliseren is. Dat is iets anders.Tegenargument. Waarom gebruikt het overgrote deel van de webdesigners PHP. Hoeveel e-banking applicaties ken jij? Hoeveel grote sites (zoals tweakers) draaien op PHP?
Je begint je te herhalen!
So What? Wat is het voordeel in de applicatie en hoezo kun je het niet in de session of page scope afvangen. Verschil in concept, maar niet echt in functionaliteit
Misschien zoals sommigen programmeren, maar het hoeft natuurlijk niet.
Als je dan feiten wilt weergeven, zouden deze 12 pagina's discussie toch op zijn minst het idee naar boven moeten brengen dat niet alles zo simpel is als het lijkt. PHP is gewoon vaak een goede taal. Als je dan een opdrachtgever wil overtuigen gebruik dan geen argumenten waarvan je bij voorbaat al weet dat ze erg makkelijk onderuit gehaald kunnen worden. Zoals ik al eerder gezegd heb, overtuig een opdrachtgeven door middel van de methode waarop jij het zou aanpakken en wijs hem op de voordelen voor hém van die methode. MVC? Wat is dat?, Foutboodschappen? Die ziet de opdrachtgever toch niet. enz.
/u/92525/me.png?f=community)
In Java heb je wel degelijk een aantal checks die wat over de semantiek zeggen, maar dat zijn natuurlijk wel de eenvoudigere checks zoals bijvoorbeeld "unreachable code", "variable might not be initialized at this point of usage" en "uncaught exception".:
Jan Klaas had wat "feiten" op een rij gezet maar daar klopt eigenlijk bar weinig van
Zie hierboven. Welke zekerheid heb je? De code voldoet aan de syntax, inhoudelijk zegt het nog niets. "De Peer zegt dat de Boekenlegger goud moet comprimeren." Begrijp jij het? Toch is het correct nederlands.
Java zelf ondersteund inderdaad niet direct een design pattern als MVC. De *standaard* libraries van Java echter wel: Swing is wel degelijk op MVC gebasseerd (hoewel wel een aanpaste vorm, waarbij M & C gedeeltelijk compressed zijn).
J2EE is voorbereid op MVC. In een model 1 applicatie maak je er geen gebruik van, en in model 2 wel. Het hele concept van servlets (en alles wat hiermee samenhangt) maakt het mogelijk om verschillende patterns toe te passen. Struts is een implementatie van model 2 door een externe partij. De standaard implementatie van Sun heet JFC. Deze wordt geleverd bij de reference implementatie van J2EE 1.4 (de huidige versie) en zal volledig opgenomen worden in de specificaties van J2EE 1.5.
JFC is volledig MVC, waarbij vooral het V gedeelte erg sterk is (de zogenaamde web widgets, zoals ASP.NET deze ook zeer sterk implementeerd). Struts is iets sterker in het C gedeelte. Je kunt Struts en JFC gewoon door elkaar gebruiken; er is een speciale intergration lib.
Maw, J2EE (wat je waarschijnlijk bedoelde met java) is door het basis design zeer geschikt voor MVC in een client-server omgeving (dit is subtiel anders als klassiek MVC zoals in smalltalk).
We zouden niet meer met modder gaan gooien, maar dat is toch echt B*llshjiet met een capital B. Typische PHP gedachte: design hoeft niet, patterns zijn waardeloos, scholing is overbodig, en ach refactoring dus ook maar.Goede code behoeft geen refactoring.
Refactoring is -juist- van essentieel belang voor je ontwikkelings process. Het is een doorlopend en continu process. Code groeit, requirements veranderen, je domain evolueert, je inzichten nemen toe, etc. Als je ooit wel eens design werk hebt gedaan, dan weet je dat je in veel gevallen een design niet sluitend kan krijgen voordat je met coden begint. Overdesignen is absoluut niet goed. Met de refactoring techniek groeit je design langzaam vanuit een basis design. Dit ondersteun je met unit testen om na elke refactoring te garanderen dat je refactoring de basis garanties heel gelaten heeft.
Refactoren is veel meer dan het alleen hernoemen van een functie. Typische kinderlijke PHP gedachte om er zo over te denkenDaarnaast is refactoring geen optimalisatie methode. (ik heb nog nooit een programma sneller zien worden van het hernoemen van een functie
De snelheid en efficientheid van refactoren is wel dedelijk een heel groot issue.
Ten eerste, tijd is geld weet je nog? Als een programmeur of software architect het overzicht verliest (omdat de taal niet strak genoeg specifeerd wat wat is) dan ben je zowieso al meer geld kwijt, en bovendien zal zij dan niet het uiterste uit de mogelijke optimalisaties kunnen halen.
Ten tweede, doordat je in Java een strakkere definitie hebt van je code, kun je veel refactorings operaties ondersteund door tools laten uitvoeren. Met name Eclipse en IntelliJ zijn hier heel sterk in. Je kunt bijvoorbeeld een inner class naar een normale class refactoren, waarbij alle parameters en referenties in je hele project automatisch upgedate worden. Dit zijn zeer krachtige tools in de handen van een volwassen programmeur.
In PHP zal je een dergelijke refactoring nooit kunnen doen, omdat de compiller niet kan weten wat wat is (de programmeur vertelt dit namelijk niet, de PHP syntax dwingt haar niet daartoe).
Ik moet dan wel toegeven dat in JSP, refactoring ook niet je van het is. JSP is met z'n fragments een heel stuk minder strakker als puur java. Daarom wil je ook zo veel mogelijk logica in je pure java code layers houden, en alleen een minimaal aan code in JSP pagina's zetten. Een niet al te snuggere J2EE programmeur zal dus gewoon hele lappen java code in haar JSP pagina gaan zetten, waardoor veel voordelen van J2EE al weer wegvallen.
Omdat een webdesigner meestal geen echte programmeur is. Een website kun je best scripten, maar een webapplicatie is heel andere koek.
In het stukje hierboven over C++ was er ook iemand zo snugger om op te merken dat web applicaties geen of nauwelijks performance nodig hadden. Mischien dat dat voor websites met 1 concurrent user geldt, maar een web applicatie is feitelijk gelijk aan een willekeurige gewone applicatie maar dan met een interface in HTML over HTTP. Een web applicatie kan gewoon dingen doen als ingewikkelde berekeningen real time uitvoeren (mischien patronen in statische data zoeken), bewerkingen op bestanden uitvoeren, zoals grafische filters die zeer rekenintensief kunnen zijn, etc. In princiepe zijn zeer veel applicaties geschikt voor een web interface. Alleen die waar snelle screen updates essentieel zijn valt het af.
Als je geen globale (application) scope hebt vallen een aantal mogelijkheden af voor een echte server applicatie. Maar mischien moet je gewoon eens wat posts van gisteren in deze thread lezen, dit werd namelijk al besproken.
Die ziet ze wel degelijk als ze in haar web log verschijnen. Kijkt de opdracht gever niet naar die log, dan komen ze wellicht wel op haar scherm. Deze worden dan naar jou toegestuurt (als je een support/onderhoud er bij afgesproken hebt). Dan mag jij, remote aan de hand van de errors uitvogelen wat er mis ging. Des te duidelijker de foutmeldingen, des te sneller je een patch kan maken. Natuurlijk is dit niet alleen Java specificiek maar de programmeur moet zelf ook goede logging van essentiele state doen in geval van exceptions.
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
:strip_exif()/u/31626/eend.gif?f=community)
Dat gaan we nu wel eens even zien.:
Fox had wat "feiten" op een rij gezet maar daar klopt eigenlijk bar weinig van
Programmeurs maken fouten.. dat moet je met me eens zijn. Jij maakt domme type fouten en ik ook. Het compilatie proces zorgt er voor dat de meest voor de hand liggende fouten er al uit zijn gehaald. Stel dat jij en ik allebei evenveel typefouten per regel code maken, dan zal onze ongecompileerde code grofweg evenveel fouten bevatten. Maar op het moment dat ik moet compileren krijg ik ineens een hele lading foutmeldingen voor de kiezen die ik moet fixen voordat ik de app uberhaubt aan de praat kan krijgen. Het nare is natuurlijk dat ik even bezig ben om de fouten eruit te halen, maar het eind resultaat is nu ineens dat mijn code per regel code minder fouten zal bevatten dan de jouwe.
En idd.. grote semantische fouten haal je er niet uit (appels bij peren optellen), maar de kleine fouten zijn er bij gecompileerde talen meer uit dan ongecompileerde talen. En vaak zijn dit er een enorme hoeveelheid...
Zie mijn verhaal hierboven.
Op het gebied van testing zal PHP wel hetzelfde kunnen als Java (een testtool schrijven moet vast wel mogelijk zijn). Maar even een keyquestion: gebruik jij unit tests? Zo nee, waarom niet? Is het te veel werk? De instap te hoog? De manier van werken laat het niet toe? PHP applicaties zijn lastiger te testen omdat ze vrij monolytisch zijn opgezet? Mock objecten plaatsen is lastig omdat er geen goeie oo technieken worden toegepast?
Ik test mijn code behoorlijk zwaar (hangt trouwens wel heel erg van het type applicatie).
Wel een typerend antwoord van iemand die geen serieuze omgevingen is gewend. In java/.net is het mogelijk om security, en transacties toe te voegen op andere zaken dan alleen databases. Niet alle applicaties bestaan uit alleen maar een webinterface en een database. Dit is dus echt een heel typerend PHP antwoord..
Typisch het antwoord van een amateur. Het is niet erg hoor.. zo dacht ik ook eens. Code schrijf je in 1 keer goed. Maar dat is niet zo.. software schrijven is een organisch proces. Iets dat niet meteen in 1 keer goed te doen is. Als je nieuwe inzichten op doet (en ja.. die doe je nu eenmaal op), refactor je. Soms is het even methode naam aanpassen zodat hij beter beschrijft wat hij doet. Maar in sommige gevallen ga je ook op hoger nivo refactoren.Goede code behoeft geen refactoring.
Het gaat om het gemak van refactoring. ALs ik 200 classes in een andere package moet zetten en ik heb geen beschikking over refactor opties, dan.. tjah... kan ik niets anders zeggen: kut klus. Veel eentonig werk.. imports aanpassen.. namespaces aanpassen.. kut werk en dat is ook de reden dat je het in de praktijk minder gaat doen (en ik spreek uit ervaring...). Op het moment dat je een IDE tot je beschikking hebt die dit volledig geautomatiseerd kan uitvoeren is de stap om dit soort kleine aanpassingen te doen ook vele malen kleiner geworden.Daarnaast is refactoring geen optimalisatie methode. (ik heb nog nooit een programma sneller zien worden van het hernoemen van een functie
[ Voor 9% gewijzigd door Alarmnummer op 18-12-2004 15:56 ]
:
We zouden niet meer met modder gaan gooien, maar dat is toch echt B*llshjiet met een capital B. Typische PHP gedachte: design hoeft niet, patterns zijn waardeloos, scholing is overbodig, en ach refactoring dus ook maar.
[..]
Refactoren is veel meer dan het alleen hernoemen van een functie. Typische kinderlijke PHP gedachte om er zo over te denken
Nee zo win je je discussie
Mensen die PHP gebruiken zijn dus prutsers, weten niet waar ze het over hebben, hebben geen scholing gehad en PHP gebruikers zijn kinderlijk...
Nee ik heb het al door.
* Erkens verlaat het topic, ik weet wel beter
Tja... we hebben argumenten genoeg gegeven en als je dat nog steeds niet inziet dan schort er wel iets aan je. (waarschijnlijk scholing en visie) Ik wil niet zeggen dat php een prutstaal is en dat alle php`ers prutsers zijn, maar wat ik uit dit topic (weer) naar voren heb zien komen is dat de gemiddelde php`er niet op hetzelfde nivo software schrijft als de gemiddelde java/.net man.:
Nee zo win je je discussie
vraag:
hoeveel php`ers hebben bv boeken gelezen zoals:
Patterns of enterprise application architecture.
design patterns explained
design patterns, elements of reusable software.
enterprise integration patterns
refactoring.
patterns of software architecture 1/2/3
of andere boeken die zich bezighouden met software ontwikkeling op een veel hoger nivo.
de meeste .NET/Java/c++ die ik ken hebben wel een of meerdere van deze titels gelezen. Hoeveel mensen die niet in deze talen werken hebben dit soort boeken gelezen?
ik durf de stelling nog wel aan dat dat nog geen fractie is tov de mensen die ik ken. hieruit durf ik dus wel te concluderen dat het nivo toch zeker anders is.Als je zegt dat dit soort boeken niet belangrijk zijn trouwens, kunnen daar ook zeker bepaalde conclusies aan verbonden worden.
[ Voor 49% gewijzigd door Alarmnummer op 19-12-2004 08:37 ]
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Creepy,
Ik heb nog een reply voor in dat Java/PHP/Meerwaarde topic.
(wel jammer dat ie dicht is trouwens, ik las hem net...)
whoami
Jan Klaassen:
Goede code behoeft geen refactoring. Daarnaast is refactoring geen
optimalisatie methode. (ik heb nog nooit een programma sneller zien worden
van het hernoemen van een functie ) Ook is de snelheid van het
optimaliseren niet echt relevant, relevant is hoe snel de code na
optimaliseren is. Dat is iets anders.
Schrijf ik dan slechte code ?
Ik heb ergens in oktober een soort 'batch' systeem ontwikkeld, dat volledig
configureerbaar was door een xml file, en verschillende soorten 'stappen'
kon uitvoeren. Enkele weken geleden heb ik dat nog eens herbekeken, en heb
ik gezien dat het hier en daar wel wat beter of anders kon opgezet worden.
Ik heb dan ook enige tijd gestoken in het refactoren van het design van dat
subsysteem.
Was mijn vorig systeem niet goed? Toch wel, het was goed. Het deed wat
het moest doen, maar nu is het nog beter. Het is uitbreidbaar en als er
plots verwacht wordt, dat mijn 'configuratie' niet alleen via een xml file
moet gebeuren, maar bv. ook in de DB moet opgeslagen zijn, dan heb ik in een
mum van tijd die functionaliteit erin gebouwd.
Refactoren is meer dan een 'method een andere naam geven'. Refactoren is
het aanpassen van je applicatie zonder daarbij nieuwe functionaliteit toe te
voegen. Refactoren is je applicatie voor een stuk redesignen, zodat die
makkelijker aanpasbaar, generieker wordt, logischer in elkaar zit.
Refactoren kan ook zo zijn dat je je applicatie herdesigned om tot een
betere performance te komen.
Echter, wat is er de dag van vandaag belangrijker ? Optimalizeren tot op de
milliseconde, of een schaalbaar en onderhoudbaar design hebben dat makkelijk
kan uitgebreid worden?
Alarmnummer:
En idd.. grote semantische fouten haal je er niet uit (appels bij peren
optellen)
Hum... Mijn compiler haalt dit specifieke voorbeeld er wel uit.
Zal niet compilen.
Ik heb nog een reply voor in dat Java/PHP/Meerwaarde topic.
(wel jammer dat ie dicht is trouwens, ik las hem net...)
whoami
Jan Klaassen:
Goede code behoeft geen refactoring.
Daarnaast is refactoring geenoptimalisatie methode. (ik heb nog nooit een programma sneller zien worden
van het hernoemen van een functie
) Ook is de snelheid van hetoptimaliseren niet echt relevant, relevant is hoe snel de code na
optimaliseren is. Dat is iets anders.
Schrijf ik dan slechte code ?
Ik heb ergens in oktober een soort 'batch' systeem ontwikkeld, dat volledig
configureerbaar was door een xml file, en verschillende soorten 'stappen'
kon uitvoeren. Enkele weken geleden heb ik dat nog eens herbekeken, en heb
ik gezien dat het hier en daar wel wat beter of anders kon opgezet worden.
Ik heb dan ook enige tijd gestoken in het refactoren van het design van dat
subsysteem.
Was mijn vorig systeem niet goed? Toch wel, het was goed. Het deed wat
het moest doen, maar nu is het nog beter. Het is uitbreidbaar en als er
plots verwacht wordt, dat mijn 'configuratie' niet alleen via een xml file
moet gebeuren, maar bv. ook in de DB moet opgeslagen zijn, dan heb ik in een
mum van tijd die functionaliteit erin gebouwd.
Refactoren is meer dan een 'method een andere naam geven'. Refactoren is
het aanpassen van je applicatie zonder daarbij nieuwe functionaliteit toe te
voegen. Refactoren is je applicatie voor een stuk redesignen, zodat die
makkelijker aanpasbaar, generieker wordt, logischer in elkaar zit.
Refactoren kan ook zo zijn dat je je applicatie herdesigned om tot een
betere performance te komen.
Echter, wat is er de dag van vandaag belangrijker ? Optimalizeren tot op de
milliseconde, of een schaalbaar en onderhoudbaar design hebben dat makkelijk
kan uitgebreid worden?
Alarmnummer:
En idd.. grote semantische fouten haal je er niet uit (appels bij peren
optellen)
Hum... Mijn compiler haalt dit specifieke voorbeeld er wel uit.
code:
1
2
3
| float f = 5; int i = 6; int result = f + i; |
Zal niet compilen.
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Dit topic is gesloten.