KLB Klaagbaak
Klaag maar raak voor een knaak.
Koppel dat met het feit dat dergelijke "slimme" code meestal niet de meest leesbare code is, en je kan je af gaan vragen wat je nou precies wint met die optimalisatieslag. En of er wel een probleem was om op te lossen ipv. dat je een onderhoudsprobleem hebt gecreëerd (want de code is zo slim dat niemand anders hem kan lezenquote:Op zaterdag 28 juni 2008 12:25 schreef Anthraxx het volgende:
Dat heb je andersom natuurlijk ook. Maar je hebt een punt ja.
).
"If you are depressed you shouldn't be in C major!" - Rick Beato
Kom zeg ga nu niet proberen af te vangen op een opmerking. Waar het omgaat is dat wanneer je de programmeertaal snapt waar je in werkt het echt niet noodzakelijk is dat je weet hoe de compiler werkt.quote:Op zaterdag 28 juni 2008 12:24 schreef Anthraxx het volgende:
[..]
Sorry, maar Tail Recursion is juist erg efficient. Nog sterker, functionele programmeertalen doen alles met recursie. En zo inefficient zijn die ook niet.
Dus jij denkt dat het noodzakelijk is om te weten hoe de php interpretator tot in detail werkt om een goede web app te kunnen schrijven?quote:Klopt. Dat maakt ze geen slechte programmeurs. Maar het is gewoon noodzakelijke kennis ongeacht het niveau. Uit ervaring weet ik dat je toch wel krijgt te horen hoe het allemaal in elkaar zit.
Een applicatie is vaak groter dan alleen een scriptje om een formulier in te vullen. Als je hier al voor de makkelijke (inefficiente) weg kiest, dan lijkt me de kans groot dat de hele applicatie ook wel een optelsom zal zijn van de verkeerde keuzes.quote:Op zaterdag 28 juni 2008 12:24 schreef Swetsenegger het volgende:
[..]
Kom nou toch, het gaat hier over het versturen van een formulier
Overigens zie ik niet wat er raar is aan die zin. Zal mijn tekortkoming als MBO'er wel zijn.
Ook een goed punt, efficiëntie zit niet alleen in de code.quote:Op zaterdag 28 juni 2008 12:29 schreef Litpho het volgende:
[..]
Koppel dat met het feit dat dergelijke "slimme" code meestal niet de meest leesbare code is, en je kan je af gaan vragen wat je nou precies wint met die optimalisatieslag. En of er wel een probleem was om op te lossen ipv. dat je een onderhoudsprobleem hebt gecreëerd (want de code is zo slim dat niemand anders hem kan lezen
En zo zijn we weer terug bij de OP van deel I.
Ja, ik ga aan header manipulatie doen, terwijl ik prima gedocumenteerde functies die EXACT hetzelfde doen tot mijn beschikking heb. Tenslotte is het versturen van een formulier rakettechnologie waar je als programmeur alles uit de code moet halen om de boel een beetje behoorlijk draaiend te houden.quote:Op zaterdag 28 juni 2008 12:34 schreef Core2 het volgende:
[..]
Een applicatie is vaak groter dan alleen een scriptje om een formulier in te vullen. Als je hier al voor de makkelijke (inefficiente) weg kiest, dan lijkt me de kans groot dat de hele applicatie ook wel een optelsom zal zijn van de verkeerde keuzes.
Je kan je beter drukker maken over de verwerking van de data nadat het formulier gepost is imho.
Recursie is lang niet altijd sneller, en in talen zoals C++ zelfs trager, omdat er nagenoeg altijd extra overhead is van de RT-lib, tenzij het algo echt perfect aansluit op de manier waarom de compiler recursie afhandelt.quote:Op zaterdag 28 juni 2008 12:24 schreef Anthraxx het volgende:
[..]
Sorry, maar Tail Recursion is juist erg efficient. Nog sterker, functionele programmeertalen doen alles met recursie. En zo inefficient zijn die ook niet.
Daarentegen is recursie vaak veel begrijpelijker, leesbaarder, en heb je voordeel van het feit dat je geen eigen stack hoeft te bouwen omdat je gewoon de inherente semantiek van de taal gebruikt, wat je code veel kleiner houdt.
Leuk, die cynisme in je post.quote:Op zaterdag 28 juni 2008 12:36 schreef Swetsenegger het volgende:
[..]
Ja, ik ga aan header manipulatie doen, terwijl ik prima gedocumenteerde functies die EXACT hetzelfde doen tot mijn beschikking heb. Tenslotte is het versturen van een formulier rakettechnologie waar je als programmeur alles uit de code moet halen om de boel een beetje behoorlijk draaiend te houden.
Je kan je beter drukker maken over de verwerking van de data nadat het formulier gepost is imho.
Nu ben ik toch wel benieuwd naar die prima gedocumenteerde functies waar je het dan over hebt. Voor de duidelijkheid, het gaat dus om het "invullen" van een formulier op een remote website, ofwel het sturen van een post request. Heb je het dan over CURL? Daar is toch wel redelijke http kennis voor vereist.
Voorbeeld: we zijn bezig met het ontwikkelen van een site die uit meerdere 2e-hands autosites resultaten haalt. Nu zijn deze resultaten niet altijd vrij, dus zal je via het formulier van zo een site de gegevens tevoorschijn moeten halen. Dit moet je doen via de header, dus je zal POST-resultaten in de header direct moeten manipuleren, die toesturen en de gegevens goed verwerken.quote:Op zaterdag 28 juni 2008 13:13 schreef Swetsenegger het volgende:
Ow dan begreep ik hem verkeerd. Ik zou me eerder afvragen waarom je dat überhaupt zou willen.
Zo zal op de onze site geen verschil te zien zijn, en alles netjes achter de schermen gebeuren.
Voorbeeld van een conculega die van dezelfde techniek gebruik maakt: http://www.gaspedaal.nl/
Op al deze posts is de no-homo clausule van toepassing.
The beaver is still fucked up, but fucked up with a yellow-black kind of feeling to it.
Omcircel koosnaam naar keuze: Razzy, Razz, Para, Kaizer Soze, Pablo.
The beaver is still fucked up, but fucked up with a yellow-black kind of feeling to it.
Omcircel koosnaam naar keuze: Razzy, Razz, Para, Kaizer Soze, Pablo.
2 tellen zoeken op internet en ik heb al diverse functies gevonden. Het lijkt me wederom geen sluitend bewijs dat je als programmeur per definitie alles moet weten van assemblers, interpretors, protocollen en standaarden.quote:Op zaterdag 28 juni 2008 13:20 schreef Paramnesia het volgende:
[..]
Voorbeeld: we zijn bezig met het ontwikkelen van een site die uit meerdere 2e-hands autosites resultaten haalt. Nu zijn deze resultaten niet altijd vrij, dus zal je via het formulier van zo een site de gegevens tevoorschijn moeten halen. Dit moet je doen via de header, dus je zal POST-resultaten in de header direct moeten manipuleren, die toesturen en de gegevens goed verwerken.
Zo zal op de onze site geen verschil te zien zijn, en alles netjes achter de schermen gebeuren.
Voorbeeld van een conculega die van dezelfde techniek gebruik maakt: http://www.gaspedaal.nl/
Dit is juist een goed voorbeeld, je hebt hier namelijk wel degelijk kennis nodig van het http protocol. Een programmeur zal deze kennis bezitten of uitzoeken, een prutser zou een paar functies copy&pasten van internet zonder enig benul van de werking. Hoe handel je dan wanneer je het script moet aanpassen of wanneer het niet werkt?quote:Op zaterdag 28 juni 2008 13:24 schreef Swetsenegger het volgende:
[..]
2 tellen zoeken op internet en ik heb al diverse functies gevonden. Het lijkt me wederom geen sluitend bewijs dat je als programmeur per definitie alles moet weten van assemblers, interpretors, protocollen en standaarden.
*zucht* ja zo kan je nog vier topics gaan mierenneuken over hoe ver je kennis precies moet gaan.
Er is vast wel een scenario te verzinnen waar je zelfs je eigen socket layer moet schrijven. Feit is dat je door de standarisatie en interfaces maar gelimiteerde kennis nodig hebt van de onderliggende lagen. En met het internet kan "zelfs een MBO-er" wel in een dag zelf een HTTP frame knutselen.
Vooral met webdevven heb je voor elke taak wel een kant-en-klare API liggen op het internet. Er zijn weinig PHP-devvers die een TCP frame kunnen opschrijven, net zoals er weinig graphicsdesigners zijn die een shadowmapping shader in ASM kunnen noteren.
Er is vast wel een scenario te verzinnen waar je zelfs je eigen socket layer moet schrijven. Feit is dat je door de standarisatie en interfaces maar gelimiteerde kennis nodig hebt van de onderliggende lagen. En met het internet kan "zelfs een MBO-er" wel in een dag zelf een HTTP frame knutselen.
Vooral met webdevven heb je voor elke taak wel een kant-en-klare API liggen op het internet. Er zijn weinig PHP-devvers die een TCP frame kunnen opschrijven, net zoals er weinig graphicsdesigners zijn die een shadowmapping shader in ASM kunnen noteren.
Ow maar ik heb nooit beweerd dat je het niet uit zou moeten zoeken als je het nodig hebt. Ik beweer dat het geen noodzakelijke kennis is om een goede programmeur te zijn. En dat staat nog steeds.quote:Op zaterdag 28 juni 2008 13:31 schreef Core2 het volgende:
[..]
Dit is juist een goed voorbeeld, je hebt hier namelijk wel degelijk kennis nodig van het http protocol. Een programmeur zal deze kennis bezitten of uitzoeken, een prutser zou een paar functies copy&pasten van internet zonder enig benul van de werking. Hoe handel je dan wanneer je het script moet aanpassen of wanneer het niet werkt?
En waar het nu om gaat is dat een recursieve loop om die reden dus niet per definitie onwenselijk is. Het gaat er om dat je weet wat je waar en wanneer moet gebruiken. Het oplossen van een probleem doormiddel van recursie kan in bepaalde gevallen de beste strategie zijn, ook al is het een zware bewerking.quote:Op zaterdag 28 juni 2008 12:22 schreef Swetsenegger het volgende:
[..]
Als je niet weet dat recursieve loop nogal intensief is ben je überhaupt geen programmeur maar een prutser. Let op, ik BEN niet eens programmeur en gewoon prutser en weet dit al.
Geen goede programmeurquote:Op zaterdag 28 juni 2008 12:22 schreef Swetsenegger het volgende:
Klopt, maar het is geen NOODZAKELIJKE kennis om een goede app te schrijven. Let op he, het gaat er hier niet om of mensen die zich in een platform verdiepen wellicht betere programmeurs zijn. Er wordt hier stellig beweerd dat MBO'ers géén programmeur kunnen zijn omdat ze niet weten hoe een assembler of compiler werkt. En DAT zijn blatante nonsens.
.
Nonsens. Je kan een prima programmeur zijn zonder dat je van alle achterliggende mechanismen weet hoe het werkt. Maar goed jouw stokpaardje mbt MBO'ers en de bijbehorende topics kennen we floris.
Ik heb respect voor ieder mens, maar een mens moet wel zijn eigen grenzen kennen. Dat is het enige waar ik voor pleit en als MBO'er moet je je grenzen dus ook kennen.quote:Op zaterdag 28 juni 2008 14:34 schreef Swetsenegger het volgende:
Nonsens. Je kan een prima programmeur zijn zonder dat je van alle achterliggende mechanismen weet hoe het werkt. Maar goed jouw stokpaardje mbt MBO'ers en de bijbehorende topics kennen we floris.
quote:Op zaterdag 28 juni 2008 14:41 schreef floris.exe het volgende:
[..]
Ik heb respect voor ieder mens, maar een mens moet wel zijn eigen grenzen kennen. Dat is het enige waar ik voor pleit en als MBO'er moet je je grenzen dus ook kennen.
Het resultaat van deze houding was te zien in de OP van het vorige topic ... een spaghetti code waar uniformiteit ver te zoeken is.quote:Op zaterdag 28 juni 2008 14:09 schreef Cruise.Elroy het volgende:
En met het internet kan "zelfs een MBO-er" wel in een dag zelf een HTTP frame knutselen.
Vooral met webdevven heb je voor elke taak wel een kant-en-klare API liggen op het internet.
Jij denkt dat elke MBO'er het redt op HBO? De grenzen worden bepaald door de docenten die het ingeleverde werk nakijken ... als zij een voldoende geven dan kun je het blijkbaar aan.quote:Op zaterdag 28 juni 2008 14:41 schreef floris.exe het volgende:
[..]
Ik heb respect voor ieder mens, maar een mens moet wel zijn eigen grenzen kennen. Dat is het enige waar ik voor pleit en als MBO'er moet je je grenzen dus ook kennen.
Wat een voorbarige conclusie. Je hebt geen flauw idee wie die code heeft geschreven en wat zijn opleiding was.quote:Op zaterdag 28 juni 2008 14:57 schreef -Six- het volgende:
[..]
Het resultaat van deze houding was te zien in de OP van het vorige topic ... een spaghetti code waar uniformiteit ver te zoeken is.
Ik zeg nergens dat het sneller is (ik zeg alleen dat Functionele Talen absoluut niet sloom zijn)quote:Op zaterdag 28 juni 2008 12:42 schreef Cruise.Elroy het volgende:
[..]
Recursie is lang niet altijd sneller, en in talen zoals C++ zelfs trager, omdat er nagenoeg altijd extra overhead is van de RT-lib, tenzij het algo echt perfect aansluit op de manier waarom de compiler recursie afhandelt.
Daarentegen is recursie vaak veel begrijpelijker, leesbaarder, en heb je voordeel van het feit dat je geen eigen stack hoeft te bouwen omdat je gewoon de inherente semantiek van de taal gebruikt, wat je code veel kleiner houdt.
. Ik reageer alleen op Swets die recursie afdoet als een inefficiente manier, terwijl er vormen van recursie zijn die efficient zijn (dus het gebruikte geheugen blijft minimaal voor duizenden iteraties). Verder geef ik je gelijk in je opmerking
.
Wat te denken van bijvoorbeeld het doorlopen van een boom datastructuur. De mooiste aanpak daarvoor is recursie. Misschien is de recht toe recht aan aanpak efficiënter als het gaat om gebruik van resources, maar met het oog op de opbouw van de code is recursie de mooiste oplossing. Het gaat niet altijd om efficiëncy.
Joh, en ik het maar proberen met nested if-statements en gotos. Weer wat geleerdquote:Op woensdag 2 juli 2008 10:02 schreef floris.exe het volgende:
Wat te denken van bijvoorbeeld het doorlopen van een boom datastructuur. De mooiste aanpak daarvoor is recursie. Misschien is de recht toe recht aan aanpak efficiënter als het gaat om gebruik van resources, maar met het oog op de opbouw van de code is recursie de mooiste oplossing. Het gaat niet altijd om efficiëncy.
Voor programmeren is dat niet noodzakelijk hoor.quote:Op zaterdag 28 juni 2008 10:11 schreef floris.exe het volgende:
[..]
Je hoeft assembler niet te snappen (de syntaxis), maar het principe daarachter wel. Namelijk de werking van de machine. Hoe software samenwerkt met hardware. Wat de processor doet, hoe het geheugen wordt gebruikt enzovoort. Dat is namelijk heel handig om goed te programmeren in hogere talen om bijvoorbeeld efficiënt om te gaan met geheugengebruik.
Dat is wel noodzakelijk, maar in de ICT is het absoluut niet belangrijk om daar meer over te weten dan de globale werking, en een beetje zicht op bottlenecks ed. Maar dat krijg je op elke MBO opleiding al het eerste jaar.
Er zit een enorm verschil tussen "wat de CPU doet" en het bizarre detail van 8086 mnemonics.
Ik ben zelf met enorm speed-critical code bezig (handmatig pre-bufferen, CPU/GPU stalls analyseren, en fdivs tellen) en zelfs ik zit echt bij grote uitzondering in ASM te werken.
Er zit een enorm verschil tussen "wat de CPU doet" en het bizarre detail van 8086 mnemonics.
Ik ben zelf met enorm speed-critical code bezig (handmatig pre-bufferen, CPU/GPU stalls analyseren, en fdivs tellen) en zelfs ik zit echt bij grote uitzondering in ASM te werken.
|
|
