Mooie cursus "algo & datastructuren" + welk boek?
user
Een kereltje gaf me recent een handleiding "cds branden", en beweerde "je
gaat nu wat bijleren over informatica". Wat? Alsof je met een handleiding
van een video recorder een cursus fysica (magnetisme, electronica) kunt
vervangen. Dat is geen informatica, maar gewoon een beetje vuile
business... Verandert om de zoveel maanden, want er moet omzet gehaald
worden, BTW gekakt worden.
Ik heb bovendien les gehad, en oefeningen gevolgd, zonder computer. Gewoon
op papier nadenken. Je kunt de cursussen aan de unifs er eens op
natrekken. Waarom geen selectie van deze onderwerpen in het middelbaar
onderwijs?
Hier een online cursus
http://cg.scs.carleton.ca/~luc/252.html
Ik heb een bon van 30 euro bij DS boekhandel, en moet die besteden ...
Iemand hints?? (anders)Iets over C misschien?/ development in linux. Ik
zag al wel "betere" boeken in de franse FNAC/Le Furet du Nord.
Gisteren een postscript boek gevonden "Mathematical illustrations"
Casselman. Daar staat deze belg LD in. Ik had hem al eens gevonden toen
ik naar postscript op zoek was..
http://cg.scs.carleton.ca/~luc/postscript.html
Ik zou deze
http://users.fulladsl.be/~spb13810/research/loc.tar.bz2
met tijd wat mooier willen maken...
--
--
What's on Shortwave guide: choose an hour, go!
http://shortwave.tk
700+ Radio Stations on SW http://swstations.tk
300+ languages on SW http://radiolanguages.tk
user
> Gisteren een postscript boek gevonden "Mathematical illustrations"
> Casselman.
boek hier als pdf/ps
http://www.math.ubc.ca/~cass/graphics/manual/
John Bokma
> Een kereltje gaf me recent een handleiding "cds branden", en beweerde "je
> gaat nu wat bijleren over informatica". Wat? Alsof je met een handleiding
> van een video recorder een cursus fysica (magnetisme, electronica) kunt
> vervangen. Dat is geen informatica, maar gewoon een beetje vuile
> business... Verandert om de zoveel maanden, want er moet omzet gehaald
> worden, BTW gekakt worden.
> Ik heb bovendien les gehad, en oefeningen gevolgd, zonder computer. Gewoon
> op papier nadenken. Je kunt de cursussen aan de unifs er eens op
> natrekken. Waarom geen selectie van deze onderwerpen in het middelbaar
> onderwijs?
>
>
> Hier een online cursus
>
> http://cg.scs.carleton.ca/~luc/252.html
Na je post helemaal gelezen te hebben wilde ik je "An Introduction to
Algorithms" aanraden, en zie nu dat het precies dat boek is wat op 3/5e
van die pagina genoemd wordt. Als je niet vies bent van zelf-studie en
je wilt een erg goed boek, kopen, echt. Het is iets meer dan 30 euro,
maar zeker waard. Let op dat je de laatste editie (3e) koopt.
Andere boeken die ik zelf heb (of nog op mijn wish list staan):
* Elements of Programming by Alexander A. Stepanov
* Programming Language Pragmatics, Third Edition by Michael L. Scott
* Computational Geometry: Algorithms and Applications by Mark de Berg,
Otfried Cheong, Marc van Kreveld, and Mark Overmars
* Algorithms in a Nutshell, O'Reilly (uitgever)
* Essentials of Programming Languages, 3rd Edition
* Structure and Interpretation of Computer Programs, 2nd edition
> Ik heb een bon van 30 euro bij DS boekhandel, en moet die besteden ...
> Iemand hints?? (anders)Iets over C misschien?/ development in linux. Ik
> zag al wel "betere" boeken in de franse FNAC/Le Furet du Nord.
Wat je hierboven gedaan hebt: kijken naar informatica programma's van
universiteiten is een aanrader. Ik doe dat ook als ik over een bepaald
onderwerp een goed boek wil hebben (en lees vervolgens de reviews op
Amazon).
Als je onder Linux wilt programmeren en Python wilt leren:
* Practical Programming: An Introduction to Computer Science Using Python
Ik ken het boek verder niet, maar ik heb er een tijdje over getwijfelt
of ik het wel/niet zou aanschaffen. Als je Python overweegt, laat het
hier weten, want dan kan ik je een lijst van boeken geven die ik erg
goed vind.
--
John Bokma
Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/
jaap
>
> Ik heb een bon van 30 euro bij DS boekhandel, en moet die besteden ...
> Iemand hints?? (anders)Iets over C misschien?/ development in linux. Ik
> zag al wel "betere" boeken in de franse FNAC/Le Furet du Nord.
The Pragmatic Programmer van Andrew Hunt en David Thomas:
http://tinyurl.com/ykvm96h
Werkelijk zeer de moeite waard. Na het lezen van dit boek sta je weer
steviger in je schoenen en is programmeren nog leuker geworden.
Veel plezier er mee,
Jaap
John Bokma
> Op 29-12-09 19:54, schreef user:
>>
>> Ik heb een bon van 30 euro bij DS boekhandel, en moet die besteden ...
>> Iemand hints?? (anders)Iets over C misschien?/ development in linux. Ik
>> zag al wel "betere" boeken in de franse FNAC/Le Furet du Nord.
>
> The Pragmatic Programmer van Andrew Hunt en David Thomas:
> http://tinyurl.com/ykvm96h
Goed boek, heb het al een aantal keer doorgebladerd, samen met
* Code Complete (2nd edition), Steve McConnell
Ook een dikke aanrader.
Bart Friederichs
> Een kereltje gaf me recent een handleiding "cds branden", en beweerde "je
> gaat nu wat bijleren over informatica". Wat? Alsof je met een handleiding
> van een video recorder een cursus fysica (magnetisme, electronica) kunt
> vervangen. Dat is geen informatica, maar gewoon een beetje vuile
> business... Verandert om de zoveel maanden, want er moet omzet gehaald
> worden, BTW gekakt worden.
> Ik heb bovendien les gehad, en oefeningen gevolgd, zonder computer. Gewoon
> op papier nadenken. Je kunt de cursussen aan de unifs er eens op
> natrekken. Waarom geen selectie van deze onderwerpen in het middelbaar
> onderwijs?
Ik denk dat middelbaar algemeen onderwijs zich niet teveel moet bemoeien
met specifieke beroepen. Wiskunde is al moeilijk genoeg voor veel
mensen. Wel zou programmeren misschien wiskunde kunnen helpen, maar dan
ben je echt al met hogere wiskunde bezig.
> Hier een online cursus
>
> http://cg.scs.carleton.ca/~luc/252.html
Niet echt een online cursus ...
>
> Ik heb een bon van 30 euro bij DS boekhandel, en moet die besteden ...
> Iemand hints?? (anders)Iets over C misschien?/ development in linux. Ik
> zag al wel "betere" boeken in de franse FNAC/Le Furet du Nord.
>
> Gisteren een postscript boek gevonden "Mathematical illustrations"
> Casselman. Daar staat deze belg LD in. Ik had hem al eens gevonden toen
> ik naar postscript op zoek was..
> http://cg.scs.carleton.ca/~luc/postscript.html
>
> Ik zou deze
> http://users.fulladsl.be/~spb13810/research/loc.tar.bz2
> met tijd wat mooier willen maken...
Lezen en leren over algoritmen is een goed idee. Maar veel van die zaken
gebruik je in het dagelijks leven als programmeur nooit. Je bent niet
slim bezig als je zelf een sorteerroutine implementeert of een linked
list. Er zijn stomweg teveel libraries die dat veel beter en efficienter
doen dan jij (en zonder segfaults en memory leaks). Datzelfde geldt als
wet zelfs voor alles wat met encryptie te maken heeft. Goed om het te
snappen, dom om het zelf te implementeren.
Wat ik absoluut gemist heb in alle lessen en cursussen die ik gehad heb,
is hoe de hele program-compile-link keten in elkaar steekt en hoe
bijvoorbeeld dynamic linking werkt.
Ook belangrijk is weten hoe een compiler werkt, en over zaken als
geheugengebruik (en -lekken). Zelf heb ik nogal wat geleerd in "Write
Great Code, volume 2" (vol 1 gaat over 'understanding the machine', wat
ik op de universiteit en hbo ruim geleerd heb met programmeerlessen (C +
assembly)):
http://www.amazon.com/Write-Great-Code-Low-Level-High-Level/dp/1593270658.
Ook "Exploiting Software"
(http://www.bol.com/nl/p/engelse-boeken/exploiting-software/1001004002209871/index.html)
geeft je veel inzichten hoe software werkt.
Succes
Bart
PS
Ik 'programmeer' sinds mijn 7e, maar durf me pas sinds een paar jaar
programmeur te noemen. Na een aantal jaar ervaring in 'the real world'.
--
Bart Blogt Beter: blog.friesoft.nl
Rob
> Wat ik absoluut gemist heb in alle lessen en cursussen die ik gehad heb,
> is hoe de hele program-compile-link keten in elkaar steekt en hoe
> bijvoorbeeld dynamic linking werkt.
>
> Ook belangrijk is weten hoe een compiler werkt, en over zaken als
> geheugengebruik (en -lekken).
Nou toen ik in de jaren 80 op school zat werd dat toch allemaal wel heel
uitgebreid behandeld. Kan zijn doordat de docent (Leen Ammeraal) hier
speciaal in geinteresseerd was.
Van hem heb ik in ieder geval een manier van werken geleerd die je bij
tegenwoordige programmeurs vaak niet meer ziet. In die tijd had je meestal
geen IDE (er bestond wel UCSD p-system en Turbo Pascal), dus je werkte
al zorgvuldiger omdat iedere compilatieslag een hoop tijd kostte.
Maar vooral het critisch kijken naar je code en zelf begrijpen dat het
correct is in plaats van net zo lang er aan friemelen en proberen tot
het zo te zien goed werkt, dat houd ik nog steeds in ere.
Bart Friederichs
> Bart Friederichs <"bart apestaartje friesoft punt nl"> wrote:
>> Wat ik absoluut gemist heb in alle lessen en cursussen die ik gehad heb,
>> is hoe de hele program-compile-link keten in elkaar steekt en hoe
>> bijvoorbeeld dynamic linking werkt.
>>
>> Ook belangrijk is weten hoe een compiler werkt, en over zaken als
>> geheugengebruik (en -lekken).
>
> Nou toen ik in de jaren 80 op school zat werd dat toch allemaal wel heel
> uitgebreid behandeld. Kan zijn doordat de docent (Leen Ammeraal) hier
> speciaal in geinteresseerd was.
Zelf zat ik in de jaren 90-00 op school, en er werd wel wat tijd aan
besteed, maar niet heel veel. Software werd inderdaad in een editor
geschreven en met command-line gecompileerd. Maar gcc doet het nu
allemaal voor jou.
>
> Van hem heb ik in ieder geval een manier van werken geleerd die je bij
> tegenwoordige programmeurs vaak niet meer ziet. In die tijd had je meestal
> geen IDE (er bestond wel UCSD p-system en Turbo Pascal), dus je werkte
> al zorgvuldiger omdat iedere compilatieslag een hoop tijd kostte.
Ik denk dat talen als Python en Java ervoor gezorgd hebben dat steeds
meer programmeurs geen idee hebben, wat er in die machine gebeurt. Om
maar te zwijgen over C#.NET en Javascript. Ik zie behoorlijk veel
crapware, die alleen maar redelijk draait, omdat er een monsterlijke
machine onder zit. (Je hebt �cht geen 1 gig RAM nodig en 2000 MHz om
alleen maar een simpel animatietje te laten zien...).
>
> Maar vooral het critisch kijken naar je code en zelf begrijpen dat het
> correct is in plaats van net zo lang er aan friemelen en proberen tot
> het zo te zien goed werkt, dat houd ik nog steeds in ere.
Zo is dat.
Bart
PS
Een goed 2010.
Martijn van Buul
Bart Friederichs ("bart apestaartje friesoft punt nl") schreef:
> Je bent niet slim bezig als je zelf een sorteerroutine implementeert of een
> linked list.
Mwah. Je bent niet slim bezig als je je vastbijt in generalisaties.
"Generalisations considered harmful" enzo.
> Er zijn stomweg teveel libraries die dat veel beter en efficienter doen dan
> jij (en zonder segfaults en memory leaks).
Dat ben ik absoluut niet met je eens. Ik implementeer regelmatig een linked
list - omdat de standaard oplossingen onhandig, inefficient of domweg
onmogelijk zijn. Dito voor sorteerroutines - een generieke QuickSort is *niet*
altijd de beste oplossing. Integendeel.
Een slecht programmeur schrijft alles zelf - maar een programmeur die denkt
dat standaard oplossingen per definitie de juiste zijn, zal altijd maar
matigjes blijven. Van de andere kant is iemand die alles zelf schrijft omdat
de rest toch bagger is (en dus last heeft van het Not Invented Here syndroom)
waarschijnlijk bijzonder intelligent en slim - maar hij is ook niet handig
bezig. Een goed programmeur weet wanneer hij genoegen kan nemen met een
generieke oplossing, en wanneer het gebruik van die generieke oplossing
meer problemen oplevert dan oplost.
> Datzelfde geldt als wet
Het is geen wet. Hooguit een richtlijn voor matige programmeurs.
> zelfs voor alles wat met encryptie te maken heeft. Goed om het te snappen,
> dom om het zelf te implementeren.
Onzin. Als dat waar zou zijn, zouden er nooit nieuwe cryptoalgoritmen komen.
Of herimplementaties van cryptoalgoritmen. Tevens zou er nooit iemand de
moeite nemen om eens een crypto algoritme proberen te kraken, danwel te
verbeteren.
Wat niet wil zeggen dat iedereen maar even zijn eigen encryptiealgoritme
moet gaan verzinnen, overigens.
> Wat ik absoluut gemist heb in alle lessen en cursussen die ik gehad heb,
> is hoe de hele program-compile-link keten in elkaar steekt en hoe
> bijvoorbeeld dynamic linking werkt.
Dan heb je de verkeerde cursussen gevolgd. Overigens is het niet zo heel
erg ingewikkeld op hoofdlijnen. Jammer genoeg zijn er wel veel platform-
afhankelijke details en eigenaardigheden.
> Ook belangrijk is weten hoe een compiler werkt,
Waarom *wel* weten hoe een compiler werkt, maar *niet* hoeven te weten hoe
een linked list werkt. Hmm, ergens klinkt dat als een contradictio in
teminus; als je weet wat voor bagger code gcc en stdlibc++ uit een simpele
std::list<bla> bouwen, is alleen *dat* al een argument waarom het gebruik
van STL in een aantal situaties voorkomen dient te worden - en dan heb ik het
nog niet eens gehad over de onhebbelijkheden van diezelfde STL die niet eens
compiler en implementatieafhankelijk zijn.
Hetgeen overigens niet wegneemt dat het gebruik van standaard containers
en dergelijke bijzonder nuttig kan zijn op plaatsen waar performance
niet zo belangrijk is.
--
Martijn van Buul - pi...@dohd.org
Martijn van Buul
> In die tijd had je meestal geen IDE
Nu is er ook geen IDE :X
Ik heb in mijn kerstvakantie eens geprobeerd om een van de applicaties die
ik tijdens $dayjob ontwikkel onder Win32 te porten naar een toolkit die
wat beter cross-platform is, in de hoop dat het ons een beetje uit de
wurggreep van Microsoft kan halen. Ik weet het, gekkenwerk - zoiets hoor je
niet te doen tijdens je vakantie. De haalbaarheid van zo'n actie valt of staat
natuurlijk wel bij het vinden van een ontwikkelomgeving waarin het enigszins
prettig werken is - het gebruiksgemak van Visual Studio is nou niet echt
briljant te noemen, zoiets moet goed te evenaren zijn. Voor mij is (g)vim
en make voldoende, maar voor mijn collega's waarschijnlijk niet.
Tot mijn spijt moet ik constateren dat zoiets wederom niet bestaat. Ik word
heel graag overtuigd van het tegendeel; dit is mijn eisenlijstje:
Ik zoek een IDE die:
1. Overweg kan met grote projecten, bestaande uit duizenden files. Alleen
dit blijkt al een onoverkomelijk probleem voor veel beschikbare IDE's
onder Linux te zijn.
2. Het moet overweg kunnen met C++. Liefst met fatsoenlijke integratie van
een debugger, en met fatsoenlijke syntax highlighting en code completion.
Hierdoor vallen Monodevelop (want alleen mono) en eclipse (Want alleen
java; de C++ development tools zijn kapotgebitrot en niet meer
beschikbaar) af.
3. Gezien 1): Het moet mij in staat stellen mijn files te ordenen zoals ik
dat wil. Gezien de omvang van de projecten is dat waarschijnlijk niet
de standaardoplossing van de IDEbakker, te meer aangezien veel van deze
files geshared zijn tussen meerdere projecten, en dus wel eens in een
andere directory te vinden zijn. Ook dit is een struikelblok voor
bijvoorbeeld Anjuta (Die mij opdwingt hoe ik mijn code moet ordenen,
danwel vereist dat de directoryrepresentatie hetzelfde moet zijn) en
qtCreator, die van mening is dat 3000 files in *een* enkele lijst gooien
geen enkel bezwaar is.
4. Aangezien we cross-platform development doen is het een vereiste dat er
een custom build optie moet zijn, waarin *ik* bepaal hoe en wat er
gecompileerd wordt. Make en een gemakkelijk te parsen project file formaat
is voldoende; op dit moment gebruiken we visual studio + GNU make op
deze manier. Autotools zijn in ieder geval niet welkom.
5. Een nette integratie heeft met een mooie resource editor voor de te kiezen
toolkit. Op dit moment neig ik naar wxWindows (want gejat van MFC, en ik
vermoed dat de conversie eenvoudiger gaat zijn), maar GTK (wxWindows ziet
er wat gedateerd uit) en Qt (GTK *en* wxWindows zijn vervelend in gebruik
en leveren lelijke code op) mogen ook.
6. Het moet op een zinnige manier overweg kunnen met multiple monitors. Op
zijn minst wil ik meerdere files tegelijkertijd kunnen editen, en op
meerdere plaatsen in dezelfde file kunnen werken.
Ik kon er geen vinden, en ik heb er veel geprobeerd. KDevelop gaat stuk op
grote projecten. Eclipse doet niet meer aan C++. qtCreator is vervelend en
legt beperkingen op in mijn ordening. CodeBlocks snapt ook niet dat *IK*
bepaal hoe mijn project eruitziet, en niet CodeBlocks - en tevens legt het
een toolchain en build type op. CodeLite is leuk, maar de editor is te licht.
En oh ja; IDE's die na het aanmaken van een template project meteen al crashen
als je een enkele file wil toevoegen (Anjuta..) tellen ook niet mee.
Ik sta open voor suggesties; tot die tijd moet ik bekennen dat Visual Studio
eigenlijk zo slecht nog niet is, want behalve een wat matige multi-monitor
support en een code completion cq codebrowser die wel heel vaak de plank
misslaat voldoet het *wel* aan alle andere eisen.
Bart Friederichs
> Ik sta open voor suggesties;
Ik ook (zie ook
http://blog.friesoft.nl/2009/11/18/ui-programming-in-linux-sucks-a-little-less/).
> tot die tijd moet ik bekennen dat Visual Studio
> eigenlijk zo slecht nog niet is, want behalve een wat matige multi-monitor
> support en een code completion cq codebrowser die wel heel vaak de plank
> misslaat voldoet het *wel* aan alle andere eisen.
Is dit niet wat Ballmer bedoelde met 'developers, developers,
developers, ...' (ad inifitum) ?
Bart
John Bokma
> Lezen en leren over algoritmen is een goed idee. Maar veel van die zaken
> gebruik je in het dagelijks leven als programmeur nooit.
Ik wel.
> Je bent niet
> slim bezig als je zelf een sorteerroutine implementeert of een linked
> list.
Stel je wilt een associatief array sorteren op de sleutel waar een
berekening op is uitgevoerd. Dan kan het handig zijn om te weten dat het
van te voren berekenen O(n) is, en het on-the-fly in het sorteren O(n
log n).
Ook is het handig om te weten dat sommige sorteerroutines niet slim
omgaan met bepaalde data. Dus ook al implementeer je het nooit zelf,
snappen hoe een algoritme in elkaar *kan* zitten en hoe het schaalt
(grote O notatie), is wat mij betreft een must.
Daarnaast zijn er ook specifieke datastructuren en bijbehorende
algoritmen die als je pecht hebt, toch echt zelf in elkaar moet
sleutelen. En/of je moet weten dat je algoritme A door B kan vervangen,
waar B in een library zit.
> Er zijn stomweg teveel libraries die dat veel beter en efficienter
> doen dan jij (en zonder segfaults en memory leaks).
Oh, we hebben het over C :-D. (j/k, ook in programmeertalen die aan
garbage collection doen kan resources eenvoudig verkwisten).
> Wat ik absoluut gemist heb in alle lessen en cursussen die ik gehad heb,
> is hoe de hele program-compile-link keten in elkaar steekt en hoe
> bijvoorbeeld dynamic linking werkt.
Leestip: het bekende drakenboek :-). Hoewel er wellicht andere boeken
zijn die het net zo goed doen (ik zelf heb Modern Compiler Design by
D. Grune nog op mijn wensenlijst staan).
> Ook belangrijk is weten hoe een compiler werkt, en over zaken als
> geheugengebruik (en -lekken).
Wat mij betreft net zo belangrijk als zelf quicksort kunnen [1]
implementeren, en de voor- en nadelen weten. Of een gelinkte lijst. Dat
laatste gaat ook over geheugengebruik, maar ook over zaken als hoe
"snel" gaat invoegen, wissen, iets op kop van de lijst zetten, iets
achteraan zetten. Wat is het nut om geheugengebruik te snappen als je
andere resources (zoals tijd) over het hoofd ziet?
> Ik 'programmeer' sinds mijn 7e, maar durf me pas sinds een paar jaar
> programmeur te noemen. Na een aantal jaar ervaring in 'the real
> world'.
Dat zouden meer mensen moeten doen. Ik ben ook altijd voorzichtig om
mijzelf expert (in Perl) te noemen, omdat ik regelmatig nog nieuwe
dingen leer.
[1] waarmee ik niet bedoel dat je *niet* een library moet gebruiken.
John Bokma
> Maar vooral het critisch kijken naar je code en zelf begrijpen dat het
> correct is in plaats van net zo lang er aan friemelen en proberen tot
> het zo te zien goed werkt, dat houd ik nog steeds in ere.
Kenmerk van een goede programmeur, echt. Als ik ergens een hekel aan heb
is het wel "trial and error" "programmeurs", zeker als ze beweren dat ze
anders leren dan andere mensen, en praktischer zijn (dwz: ze leren iets
met boek op de schoot achter een computer of erger door te googlen, code
pasten en dan maar veranderen tot het werkt).
Ooit ergens op een opdracht gezeten waar kunde gemeten werd aan het
aantal toetsaanslagen per minuut. Ik kwam daar achter toen iemand mij
wat uitlegde achter zijn computer en constant zenuwachtig de op de
cursor toetsen zat te tikken. Hij vertelde dat we zo de indruk gaven
hard aan het werk te zijn....
John Bokma
[IDE eisen]
> 5. Een nette integratie heeft met een mooie resource editor voor de te kiezen
> toolkit. Op dit moment neig ik naar wxWindows (want gejat van MFC, en ik
> vermoed dat de conversie eenvoudiger gaat zijn), maar GTK (wxWindows ziet
> er wat gedateerd uit) en Qt (GTK *en* wxWindows zijn vervelend in gebruik
> en leveren lelijke code op) mogen ook.
Ik heb redelijk wat ervaring met wxWindows, en ben er niet echt over te
spreken. Ik weet vrij weinig van Qt af, maar wat ik gezien heb geeft mij
heel sterk het gevoel dat Qt veel prettiger werkt dan wxWindows, ook
omdat wxWindows duidelijk van de vorige eeuw is.
> 6. Het moet op een zinnige manier overweg kunnen met multiple monitors. Op
> zijn minst wil ik meerdere files tegelijkertijd kunnen editen, en op
> meerdere plaatsen in dezelfde file kunnen werken.
2-6 kan prima met Emacs. Ik ken zowel vi(m) (maar niet goed genoeg, wil
ik dit jaar wat aan gaan doen) als emacs (vrij goed), en neig meer naar
Emacs.
Qua je eerste punt: het zou mij totaal niets verbazen als er een (of
zelfs meer) uitbreidingen zijn op Emacs om dat mogelijk te maken.
(terzijde: ik gebruik zelf veel ant, maar dan meer om dingen bij elkaar
in een tarball of zip te pakken)
Vraag is of Emacs een IDE te noemen is ;-) (Ik doe er ook Usenet mee, en
dat is fijn, om te kunnen schrijven in je dagelijkse editor).
Martijn Lievaart
> Kenmerk van een goede programmeur, echt. Als ik ergens een hekel aan heb
> is het wel "trial and error" "programmeurs", zeker als ze beweren dat ze
> anders leren dan andere mensen, en praktischer zijn (dwz: ze leren iets
> met boek op de schoot achter een computer of erger door te googlen, code
> pasten en dan maar veranderen tot het werkt).
Dan heb je nog nooit met VBA gewerkt. Trial and error is de enige manier
bij gebrek aan goede documentatie.... :-)
M4
John Bokma
> On Fri, 01 Jan 2010 16:51:33 -0600, John Bokma wrote:
>
>> Kenmerk van een goede programmeur, echt. Als ik ergens een hekel aan heb
>> is het wel "trial and error" "programmeurs", zeker als ze beweren dat ze
>> anders leren dan andere mensen, en praktischer zijn (dwz: ze leren iets
>> met boek op de schoot achter een computer of erger door te googlen, code
>> pasten en dan maar veranderen tot het werkt).
>
> Dan heb je nog nooit met VBA gewerkt.
Jawel, maar dat is al weer eventjes geleden (eind jaren 90).
> Trial and error is de enige manier
> bij gebrek aan goede documentatie.... :-)
Toen ik VBA gebruikte was er tenminste 1 boek (Microsoft Press). Verder
vond ik e.e.a. wel logisch in elkaar zitten.
Martijn van Buul
> Ik heb redelijk wat ervaring met wxWindows, en ben er niet echt over te
> spreken.
Hmja, het lijkt nogal op MFC. Heel eerlijk gezegd vind ik dat ook niet echt
tof, maar het is nou eenmaal de toolkit waarin de bestaande dialogs
geschreven zijn, en het is de manier van denken waar mijn gewaardeerde
collegae aan gewend zijn.
> Ik weet vrij weinig van Qt af, maar wat ik gezien heb geeft mij
> heel sterk het gevoel dat Qt veel prettiger werkt dan wxWindows,
Tsja, ik heb wel met Qt gewerkt, en het is ook niet echt je-dat. Ze
gebruiken een houtjes-touwtjes oplossing om C++ uit te breiden met nieuwe
constructies, en dat heeft zo zijn nadelen. Van de andere kant is de
uiteindelijke code wel redelijk elegant - iets wat je van GTK+ (de andere
grote toolkit) niet kunt zeggen.
> ook omdat wxWindows duidelijk van de vorige eeuw is.
Zelden zo'n onzinnig argument gezien, maar Qt is ook niet nieuw. Sterker nog,
Qt is ouder dan wxWindows/wxWidgets *en* GTK+.
>> 6. Het moet op een zinnige manier overweg kunnen met multiple monitors. Op
>> zijn minst wil ik meerdere files tegelijkertijd kunnen editen, en op
>> meerdere plaatsen in dezelfde file kunnen werken.
>
> 2-6 kan prima met Emacs.
Euh, ik had toch al gezegd dat vim+make niet echt een acceptabele oplossing
is? Waarom zou emacs+make dat dan wel zijn?
> Vraag is of Emacs een IDE te noemen is ;-) (Ik doe er ook Usenet mee, en
> dat is fijn, om te kunnen schrijven in je dagelijkse editor).
Tsja. ik ben eerlijk gezegd geen emacs-fan; de toetsenbordcombinaties zijn
mij te bizar.
Martijn - die zich spontaan afvraagt welk Stallmangedrocht hij wel fijn vindt..
John Bokma
> John Bokma (jo...@castleamber.com) schreef:
>
>> ook omdat wxWindows duidelijk van de vorige eeuw is.
>
> Zelden zo'n onzinnig argument gezien, maar Qt is ook niet nieuw.
Het gaat niet om ouderdom in jaren, maar gewoon hoe het
aanvoelt. Uiteraard is het een persoonlijke mening.
>>> 6. Het moet op een zinnige manier overweg kunnen met multiple monitors. Op
>>> zijn minst wil ik meerdere files tegelijkertijd kunnen editen, en op
>>> meerdere plaatsen in dezelfde file kunnen werken.
>>
>> 2-6 kan prima met Emacs.
>
> Euh, ik had toch al gezegd dat vim+make niet echt een acceptabele oplossing
> is? Waarom zou emacs+make dat dan wel zijn?
Geen idee, ik gaf alleen aan dat 2 t/m 6 prima met Emacs te doen
is. Emacs is verder geen vim en vice versa natuurlijk.
>> Vraag is of Emacs een IDE te noemen is ;-) (Ik doe er ook Usenet mee, en
>> dat is fijn, om te kunnen schrijven in je dagelijkse editor).
>
> Tsja. ik ben eerlijk gezegd geen emacs-fan; de toetsenbordcombinaties zijn
> mij te bizar.
Kijk, en dat is dus /wel/ een onzinnig argument, want daar kan je
probleemloos /zelf/ wat aan doen.
> Martijn - die zich spontaan afvraagt welk Stallmangedrocht hij wel
> fijn vindt..
Ik heb altijd het idee dat Martijn niks echt fijn vind wat andere fijn
vinden.
gast
> Ik heb redelijk wat ervaring met wxWindows, en
ben er niet echt over te
> spreken. Ik weet vrij weinig van Qt af, maar
wat ik gezien heb geeft mij
> heel sterk het gevoel dat Qt veel prettiger
werkt dan wxWindows, ook
> omdat wxWindows duidelijk van de vorige eeuw
is.
Je zou Motif beter kunnen vinden dan programmeren
in X11.
Motif is van ?? 1989, X11 van 1984. Maar het
werkt beide nog, want is "open bron".....
Zo rendeert opgedane kennis. Pas op je pensioen
gooi je het definitief weg? Neen, dan maak je
openbroncode??
robert
> John Bokma wrote:
>
>> Ik heb redelijk wat ervaring met wxWindows, en ben er niet echt over te
>> spreken. Ik weet vrij weinig van Qt af, maar wat ik gezien heb geeft mij
>> heel sterk het gevoel dat Qt veel prettiger werkt dan wxWindows, ook
>> omdat wxWindows duidelijk van de vorige eeuw is.
>
> Je zou Motif beter kunnen vinden dan programmeren in X11.
>
> Motif is van ?? 1989, X11 van 1984. Maar het werkt beide nog, want is
> "open bron".....
Maar Motif sucks...
--
robert