Pagina 3 van 3

Re: Rubik's Cube - oplossing in ≤ 20 bewegingen

Geplaatst: 10 sep 2010, 12:54
door tsagld
De frameworks zijn per stuk enkele tientallen Mb's en in het ergste geval heb je nu zes versies staan, waarvan je de oudste gewoon kunt weggooien.
Het framework is m.i. een geweldig product en heeft veel problemen opgelost, waarvan de belangrijkste de dll-hell is. Genoeg over persoonlijke voorkeuren denk ik nu...

Om terug te komen op de noodzaak tot slimme algoritmes, jawel, als je slim programmeert kun je de doorlooptijd verkorten. Maar de vraag is simpelweg, hoe belangrijk is dat bij bepaalde projecten?

Met de huidige snelheden kun je rustig bubble-sorten over een paar duizend records terwijl dat vroeger ondenkbaar was. Zonde om moeite te stoppen in ingewikkelde algoritmes. Dit slechts als voorbeeld...

Re: Rubik's Cube - oplossing in ≤ 20 bewegingen

Geplaatst: 10 sep 2010, 15:21
door meneer van Hoesel
tsagld schreef:Met de huidige snelheden kun je rustig bubble-sorten over een paar duizend records terwijl dat vroeger ondenkbaar was. Zonde om moeite te stoppen in ingewikkelde algoritmes. Dit slechts als voorbeeld...
Het is maar goed dat we jou geen SQL hebben laten ontwikkelen en dat er bij SUN/Oracle/SAP en anderen toch wat mensen rondlopen die daar anders over denken :)

Re: Rubik's Cube - oplossing in ≤ 20 bewegingen

Geplaatst: 10 sep 2010, 16:01
door tsagld
Zie het in de context. Als ik het adressen bestand van mijn familie moet sorten en ik zou alles zelf moeten ontwikkelen, volstaat het om in een paar minuten een bubble-sort te schrijven i.p.v. complexe dictionaries en buckets.
Als een common-purpose dbms moet ontwikkelen (wat ik in het verleden overigens ook heb gedaan, in assembly nota-bene) is het natuurlijk een ander verhaal. Ik dacht dat ik dat in mijn vorig post duidelijk had gemaakt.

Re: Rubik's Cube - oplossing in ≤ 20 bewegingen

Geplaatst: 11 sep 2010, 10:37
door Sjoerd Job
tsagld schreef:Met de huidige snelheden kun je rustig bubble-sorten over een paar duizend records terwijl dat vroeger ondenkbaar was. Zonde om moeite te stoppen in ingewikkelde algoritmes. Dit slechts als voorbeeld...
Uiteraard is dat nog wel haalbaar om te doen. De vraag is meer: Hoe weet een programmeur hoeveel records er in die applicatie zullen worden gestopt? Tenzij als je net als bij excel er een harde limiet van 65.536 rijen inzet. (Ik ken persoonlijk iemand die bestanden van enkele gigabyte zou willen importeren in excel, en het met de hand stukje voor stukje doet)

Uiteraard, grote databestanden zijn echte uitzonderingen. Maar als de features van jou applicatie gewenst zijn, alleen het databestand te groot voor jou algoritmes, heeft een van beiden pech.

In ieder geval geld de regel: Als je alleen voor jezelf programmeert, maakt het niet uit wat je doet.