/u/12668/hydra.png?f=community)
Leg dan eens uit wat volgens jou een betere taal is? PHP?
https://niels.nu
:strip_icc():strip_exif()/u/36003/crop584e9e5c223bd.jpeg?f=community)
Interessant dat je reageert op de grappig bedoelde opmerking en de rest negeert
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
Ben het met de rest gewoon eens:
Interessant dat je reageert op de grappig bedoelde opmerking en de rest negeert
Die reactie was niet om je tegen te spreken, snap dat het grappig ebdoeld was, maar ik vind het best bizar om te zien waar sommige grote integrators mee weg komen. Vooral bij de overheid.
[ Voor 28% gewijzigd door Hydra op 17-12-2008 15:30 ]
https://niels.nu
:strip_icc():strip_exif()/u/5855/BDKAMZi.jpg?f=community)
Ik zit in de grote bedrijven wereld en kom PHP daar nooit tegen.:
Leg dan eens uit wat volgens jou een betere taal is? PHP?
Met de gemiddelde procedurele 3GL kunnen de meeste junior programmeurs prima werken.
De functionaliteit van een traditioneel programma kun je daar in een paar pagina's prima achter elkaar lezen en debuggen.
Bij java is het om een of andere reden gelijk een stapel bestanden met verschillende functie en inhoud. Er is altijd wel iets wat over het hoofd gezien wordt of wat niet begrepen is.
Het heeft denk ik wel te maken met de manier waarom er gebruik van gemaakt wordt. Je kunt met java ook wel op de traditionele manier een voor iedereen overzichtelijk programma schrijven, maar in de praktijk zie je allerlei architecturele lagen onnodig toegevoegd worden.
Ook OO inheritance toestanden worden vaak gelijk bij het eerste de beste kleine programma toegepast, terwijl het voordeel hiervan dan vele malen kleiner is dan het nadelige verlies aan doorzichtigheid.
Zet de gemiddelde onderhoudsprogrammeur van een willekeurige dienstverlener erop en je krijgt geheid een veelvoud aan problemen tov. de 'ouderwetse' programma's.
Who is John Galt?
/u/220490/bombcut.png?f=community)
Als ej ja had geantwoord had ik je hard uitgelachen
Tja. Ik weet niet wat voor'n programma's jij in een paar (dus 2-4) pagina's kunt coden, maar dat noem ik geen applicatie maar eerder een 'tooltje'. De tools die ik zelf voor klanten geschreven heb, heb ik eigenlijk altijd in C# (als ze windows based zijn) of Java (als het platformonafhankelijk moet) geschreven, ook als dat een paar pagina's code is. Gewoon omdat het beide hele simpele talen zijn waar je snel in kunt devven.
Tja, sorry als ik de verkeerde indruk krijg, maar ik krijg een beetje het idee dat je zelf weinig aan development werk gedaan hebt. Java een 'stapel bestanden'? Je kunt een simpel (2-4 pagina's aan code) tooltje prima in 1 class vangen. Da's dus gewoon 1 .java file. OO inheritance pas je toe als het nodig is. Je gaat niet koste wat 't kost inheritance gebruiken als er niks te inheriten valt.
Je beschrijft dus een slechte programmeur die een applicatie onnodig complex maakt. Ik geloof niet dat deze in ander eomgevingen (kun je specifieke voorbeelden noemen in plaats van alleen heel generiek "gemiddelde procedurele 3G"?
Je kunt in elke taal code maken die je niet snapt. Volgens mij zal die 9 van de 10 keer danook niet doen wat de bedoeling is. Ik zie absoluut niet hoe Java daarin anders is dan welke taal dan ook. Sterker nog; in Java zal de schade vaak beperkter zijn dan bijvoorbeeld C++ alleen al omdat een prutser daarin gegarandeerd fouten gaat maken met z'n memory management.
[ Voor 11% gewijzigd door Hydra op 17-12-2008 16:05 ]
https://niels.nu
:strip_icc():strip_exif()/u/18149/catfish60.jpg?f=community)
@justmental: Wat was die quote ook al weer: mensen zullen altijd code maken die zo complex is dat ze hem nog maar net snappen. Dus als je het doorgronden van code makkelijker maakt, zullen mensen complexere code gaan schrijven. Overigens zonder erbij na te denken dat achteraf snappen moeilijker is, en dat dat dus vaak niet meer lukt 
: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.
Dat is niet zo netjes, want dat zou best een heel valide statement kunnen zijn.:
Als ej ja had geantwoord had ik je hard uitgelachen
Je begrijpt ook wel wat ik bedoel. Je hebt een bug, en die pinpoint je razendsnel tot een functie die je voor iedereen begrijpbaar is.
Ik zal niet ingaan op dat 'tooltje'.
Mijn persoonlijke programmeerervaring is geen onderwerp van discussie. Ik bespreek hier mijn ervaringen in 12 jaar enterprise omgeving waar ik met bouw en onderhoud van vele tientallen systemen van dichtbij heb meegemaakt.
Om een of andere reden zijn de java applicaties altijd de zwarte schapen in de onderhoudsfase. Een simpele applicatie van een tiental schermen wordt opgeleverd en er zitten vele honderden bestanden in de .ear.
Dat is dan niet allemaal code, maar ook configuratiebestanden, xml's, manifests etc. en daar gaat het dan ook vaak in mis.
Dat lijkt me een open deur, maar ik had het over de praktijk.
Who is John Galt?
:strip_icc():strip_exif()/u/110767/avatar_6060.jpg?f=community){kind=avatar}
@Hydra: Ok, ik snap nu iets beter wat je bedoelt. Ik vermoed dat mijn nuance voornamelijk in één argument niet goed naar voren kwam, dus dat zal ik nog even proberen te verhelderen.
Met het "niet begrijpen van de oplossing" bedoel ik dat je alleen het trucje hebt aangeleerd. Bijvoorbeeld dat je weet dat je een functie aan moet roepen in je code, maar niet weet wat die functie daadwerkelijk doet.
Je gooit 1 in een functie en krijgt er 2 uit, accepteert dat dit zo is en gebruikt het wanneer je het nodig hebt in plaats van te snappen wat die functie nu met je 1 doet om er 2 van te maken.
Mijn grens die ik stelde mbt dieptekennis of geen dieptekennis ligt dan ook op de grens tussen code kunnen schrijven en code kunnen begrijpen. Dat je als programmeur een stukje functionaliteit moet kunnen bouwen, al dan niet aan de hand van een design, staat voor mij buiten kijf.
Alleen kunnen kopieren en plakken beschouw ik als niet competent.
Ik weet hoe ik door middel van code, in mijn geval af en toe in de meest gruwelijk verouderde en beperkte talen en ontwikkelomgevingen, kan bereiken wat ik wil bereiken. Ik weet echter niet altijd wat de ingebouwde functies in de omgeving waar ik mee bezig ben precies doen. Dáár ligt voor mij de grens tussen iets kunnen bouwen en snappen waarom iets werkt en daarom reken ik mijzelf niet tot de harde kern.
Natuurlijk, ik heb een MBO opleiding zoals ik zei, maar ik werk volgens mij op het niveau van een redelijke HBO ontwikkelaar (waarbij redelijk < goed and redelijk > slecht). Soms moet ik ook iets tot in de diepte uitzoeken en dat vind ik dan ook leuk om te doen, maar als ik iets kan bouwen door een paar blokken op elkaar te zetten zal ik dat ook op die manier doen.
Wat misschien het verschil is tussen mij en andere programmeurs (bij andere bedrijven) is dat ik geen enkele keuze heb in betrekking tot de omgeving waar ik iets in wil bouwen. Ik heb een omgeving en daar moet ik het in doen. Vandaar dat ik ook niet dieper in ga op het punt of Java een vloek is, ik heb geen keus.
Ik zou zelfs eerder stellen dat PHP een vloek is, omdat daar in mijn ogen nog meer mensen denken dat ze kunnen programmeren zodra ze een PHP script hebben gekopieerd van een website.
Maar ook dit kan komen omdat ik andere ervaringen heb en andere mensen tegenkom. Van de 3 "self-proclaimed" Java programmeurs die ik hier in anderhalf jaar heb gezien is er "slechts" eentje compleet incompetent gebleken en ontslagen.
Daarentegen heb ik een fors aantal klasgenoten gezien die echt niks meer kunnen dan kopieren en plakken en toch hun papiertje hebben gehaald, en dat ging meestal om PHP.
Of je wel of niet goed een design kan opstellen en met een klant kan praten laat ik hier nog steeds buiten beschouwing. Dit is weliswaar een kwaliteit die vaak gevraagd wordt en handig is, maar valt even buiten het punt dat ik wilde maken.
Met het "niet begrijpen van de oplossing" bedoel ik dat je alleen het trucje hebt aangeleerd. Bijvoorbeeld dat je weet dat je een functie aan moet roepen in je code, maar niet weet wat die functie daadwerkelijk doet.
Je gooit 1 in een functie en krijgt er 2 uit, accepteert dat dit zo is en gebruikt het wanneer je het nodig hebt in plaats van te snappen wat die functie nu met je 1 doet om er 2 van te maken.
Mijn grens die ik stelde mbt dieptekennis of geen dieptekennis ligt dan ook op de grens tussen code kunnen schrijven en code kunnen begrijpen. Dat je als programmeur een stukje functionaliteit moet kunnen bouwen, al dan niet aan de hand van een design, staat voor mij buiten kijf.
Alleen kunnen kopieren en plakken beschouw ik als niet competent.
Ik weet hoe ik door middel van code, in mijn geval af en toe in de meest gruwelijk verouderde en beperkte talen en ontwikkelomgevingen, kan bereiken wat ik wil bereiken. Ik weet echter niet altijd wat de ingebouwde functies in de omgeving waar ik mee bezig ben precies doen. Dáár ligt voor mij de grens tussen iets kunnen bouwen en snappen waarom iets werkt en daarom reken ik mijzelf niet tot de harde kern.
Natuurlijk, ik heb een MBO opleiding zoals ik zei, maar ik werk volgens mij op het niveau van een redelijke HBO ontwikkelaar (waarbij redelijk < goed and redelijk > slecht
). Soms moet ik ook iets tot in de diepte uitzoeken en dat vind ik dan ook leuk om te doen, maar als ik iets kan bouwen door een paar blokken op elkaar te zetten zal ik dat ook op die manier doen.Wat misschien het verschil is tussen mij en andere programmeurs (bij andere bedrijven) is dat ik geen enkele keuze heb in betrekking tot de omgeving waar ik iets in wil bouwen. Ik heb een omgeving en daar moet ik het in doen. Vandaar dat ik ook niet dieper in ga op het punt of Java een vloek is, ik heb geen keus.
Ik zou zelfs eerder stellen dat PHP een vloek is, omdat daar in mijn ogen nog meer mensen denken dat ze kunnen programmeren zodra ze een PHP script hebben gekopieerd van een website.
Maar ook dit kan komen omdat ik andere ervaringen heb en andere mensen tegenkom. Van de 3 "self-proclaimed" Java programmeurs die ik hier in anderhalf jaar heb gezien is er "slechts" eentje compleet incompetent gebleken en ontslagen.
Daarentegen heb ik een fors aantal klasgenoten gezien die echt niks meer kunnen dan kopieren en plakken en toch hun papiertje hebben gehaald, en dat ging meestal om PHP.
Of je wel of niet goed een design kan opstellen en met een klant kan praten laat ik hier nog steeds buiten beschouwing. Dit is weliswaar een kwaliteit die vaak gevraagd wordt en handig is, maar valt even buiten het punt dat ik wilde maken.
:strip_icc():strip_exif()/u/25814/camus_small.jpg?f=community)
:strip_exif()/u/26499/avatarRHCP6060.gif?f=community){kind=avatar}
Dat is ook mijn mening. Voor de meest simpele webservice calls worden er complete Struts-gedrochten uit de kast getoverd (mooiste voorbeeld: 10 verschillende 1 regelige strings versturen
); voor extended functionaliteit die bestaat uit twee typen met elk een method van 2 regels worden er interfaces en abstract classes gebouwd. Maar goed, als je weet hoe de verschillende framework generators in elkaar zitten, is het niet zo'n probleem, behalve dat er een enorme overhead aan code is. Dit ligt alleen niet aan Java, want in .Net zie ik dat ook wel eens gebeuren.
Verder is communicatie het allerbelangrijkste (zoals boven gemeld) en daarnaast ben ik van mening dat een developer of software engineer goed moet weten wat er allemaal mogelijk is binnen de scope van een project (met alle politiek die daar bij hoort) en binnen de gebruikte platformen. Dat vereist gewoon een hoog abstract denkniveau en heeft niks met welke taal dan ook te maken. En ik denk dat de training in dat denkniveau misschien nogal eens tekort schiet als je steeds maar weer snel applicaties in elkaar moet beitelen.
Wat dat betreft ben ik het eens met Efbe, die ooit eens zei dacht ik dat gedegen algoritmenkennis toch het belangrijkste is.
@ Kenneth: jij patser met je bookmarks
Jij patser jij, met je goeie geheugen:
Wat dat betreft ben ik het eens met Efbe, die ooit eens zei dacht ik dat gedegen algoritmenkennis toch het belangrijkste is.
EfBe in "[alg] Eerst basics of meteen best practi..."
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
:strip_exif()/u/72391/Pinky_and_the_Brain_-_Brain.gif?f=community)
:strip_exif()/u/220180/Animation11.gif?f=community)
:strip_icc():strip_exif()/u/83088/icon%25203.jpg?f=community)
offtopic:
Eerste Google ads reclame: Cursus C#
Eerste Google ads reclame: Cursus C#
Het wordt ook gedeeltelijk bepaald door de aanwezige kennis. Bij de TH Rijswijk ging het verhaal dat de docent die Object Georienteerd Programmeren gaf geen Java kende, en ons dus C++ leerde. Java hebben we later gekregen. Eerste taal die we leerden was C, dus voor de pointers hoefden we geen C++ te leren.
[ Voor 4% gewijzigd door MBV op 17-12-2008 23:24 ]
Erg handig op een universiteit... Ik mag hopen dat je als universitair student jezelf binnen een maand een nieuwe taal eigen kan maken 
En hebben ze op de TUD niet een groot bachelor-project waarin je zelf een programma moet schrijven voor een interne klant?
En hebben ze op de TUD niet een groot bachelor-project waarin je zelf een programma moet schrijven voor een interne klant?
/u/112490/crop5821eafeac2b9_cropped.png?f=community)
:strip_exif()/u/26373/anim4.gif?f=community)
Phyxion: De FP is niet hetzelfde als het forum. Kan je je punten nog eens onderbouwd herhalen hier? -1 modden kan hier niet En als je dan toch bezig bent geef dan gelijk een alternatief die de nadelen niet heeft (en dan liefst ook nog de nadelen die het alternatief wel heeft om eerlijk te zijn).
En als je dan toch bezig bent geef dan gelijk een alternatief die de nadelen niet heeft (en dan liefst ook nog de nadelen die het alternatief wel heeft om eerlijk te zijn).
[ Voor 40% gewijzigd door Creepy op 18-12-2008 10:14 ]
"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
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.
/u/3273/crop62bb0d316df4f_cropped.png?f=community)
leuk zo'n rel.
wat ik mis is het volgende:
Wordt er binnen de bedrijven waar die code gemaakt en gebruikt wordt, gecontroleerd op de kwaliteit, onderhoudbaarheid en beheerbaarheid van de code?
Het antwoord zal wel "nee" zijn.
De acceptatietest van de architectuurafdeling en de beheerafdeling zou onjuist geformuleerde code of overdadig en foutief gebruik van patterns en principes af moeten wijzen. Daarvoor hebben ze natuurlijk wel eerst een document met acceptatiecriteria nodig, die voortkomen uit de (architectuur-)richtlijnen die gelden voor de code van dat bedrijf... maar het gaat erom dat de coders blijkbaar veel te weinig gewezen worden op de kwaliteit van hun werk.
Dus als je iets wilt verbeteren, begin dan daar. Zo ontstaat in ieder geval het besef bij coders dat hun code niet alleen hoeft te compileren, maar dat er ook nog andere eisen aan gesteld worden. En dat foutief gebruik niet door de molen komt. Onderwijsinstellingen volgen vanzelf als het nut van goverance op kwaliteit, onderhoudbaarheid en beheerbaarheid bewezen is.
(even voor de duidelijkheid: ik roep niet dat alle coders fout coderen.)
wat ik mis is het volgende:
Wordt er binnen de bedrijven waar die code gemaakt en gebruikt wordt, gecontroleerd op de kwaliteit, onderhoudbaarheid en beheerbaarheid van de code?
Het antwoord zal wel "nee" zijn.
De acceptatietest van de architectuurafdeling en de beheerafdeling zou onjuist geformuleerde code of overdadig en foutief gebruik van patterns en principes af moeten wijzen. Daarvoor hebben ze natuurlijk wel eerst een document met acceptatiecriteria nodig, die voortkomen uit de (architectuur-)richtlijnen die gelden voor de code van dat bedrijf... maar het gaat erom dat de coders blijkbaar veel te weinig gewezen worden op de kwaliteit van hun werk.
Dus als je iets wilt verbeteren, begin dan daar. Zo ontstaat in ieder geval het besef bij coders dat hun code niet alleen hoeft te compileren, maar dat er ook nog andere eisen aan gesteld worden. En dat foutief gebruik niet door de molen komt. Onderwijsinstellingen volgen vanzelf als het nut van goverance op kwaliteit, onderhoudbaarheid en beheerbaarheid bewezen is.
(even voor de duidelijkheid: ik roep niet dat alle coders fout coderen.)
Het enige belangrijke is dat je vandaag altijd rijker bent dan gisteren. Als dat niet in centen is, dan wel in ervaring.
Het antwoord is inderdaad vaak 'nee'. Vaak is er ook niet eens een architectuurafdeling hoor.:
leuk zo'n rel.
wat ik mis is het volgende:
Wordt er binnen de bedrijven waar die code gemaakt en gebruikt wordt, gecontroleerd op de kwaliteit, onderhoudbaarheid en beheerbaarheid van de code?
Het antwoord zal wel "nee" zijn.
De acceptatietest van de architectuurafdeling en de beheerafdeling zou onjuist geformuleerde code of overdadig en foutief gebruik van patterns en principes af moeten wijzen. Daarvoor hebben ze natuurlijk wel eerst een document met acceptatiecriteria nodig, die voortkomen uit de (architectuur-)richtlijnen die gelden voor de code van dat bedrijf... maar het gaat erom dat de coders blijkbaar veel te weinig gewezen worden op de kwaliteit van hun werk.
Dus als je iets wilt verbeteren, begin dan daar. Zo ontstaat in ieder geval het besef bij coders dat hun code niet alleen hoeft te compileren, maar dat er ook nog andere eisen aan gesteld worden. En dat foutief gebruik niet door de molen komt. Onderwijsinstellingen volgen vanzelf als het nut van goverance op kwaliteit, onderhoudbaarheid en beheerbaarheid bewezen is.
(even voor de duidelijkheid: ik roep niet dat alle coders fout coderen.)
Voor de meeste bedrijven is code geen core-business en vertrouwen ze erop dat zij mensen inhuren met kennis. Dat er vervolgens allerlei onduidelijke en tegenstrijdige eisen zijn ontwikkeld draagt niet bij aan heldere patterns en principes en zorgt er vaak voor dat er weinig tijd (lees budget en onrealistische deadlines) is om of van te voren goed na te denken of achteraf dingen goed te zetten.
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/13818/episodebutler_60x60.gif?f=community)
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Met command line tools en een clientside windows applicaties dek je maar een heel minimaal deel af van het totale applicatie landschap. Sterker nog, ik snap heel goed waarom je helemaal geen energie meer stopt in Swing omdat dergelijke clientside applicaties redelijk end of life raken...:
Een commandline programma vinden gebruikers meestal nog minder plezant dan een trage Swing
C# heeft toch ook geen trage Forms.. Dat ze dat bij Sun/Java dat eens fixen.
Meneer uw F1-wagen is niet traag, het gaspedaal werkt alleen traag
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
:strip_icc():strip_exif()/u/6143/rincewind.jpg?f=community)
Ja maar niemand verplicht je om een Java applicatie in Swing te maken, er zijn ook alternatieven zoals http://www.eclipse.org/swt/:
Een commandline programma vinden gebruikers meestal nog minder plezant dan een trage Swing
C# heeft toch ook geen trage Forms.. Dat ze dat bij Sun/Java dat eens fixen.
Meneer uw F1-wagen is niet traag, het gaspedaal werkt alleen traag
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Er zijn GUI alternatieven, je bent niet gebonden aan Swing (en is nu blijkbaar deprecated):
Een commandline programma vinden gebruikers meestal nog minder plezant dan een trage Swing
WinForms is dan ook een stuk minder abstract opgezet.
Het punt is dat jij zegt dat java traag is, terwijl je het eigenlijk hebt over het design van een specifieke API dat traag is, onafhankelijk van hoe snel Java code uitgevoerd wordt. Je bent dus appels met peren aan het vergelijken.
Meneer uw Intel Core i7 is niet traag, het door u gebruikte OS, Windows 95, maakt er alleen niet optimaal gebruik van
[ Voor 10% gewijzigd door .oisyn op 18-12-2008 13:41 ]
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/126096/crop580e4f8566fec_cropped.jpeg?f=community)
Ik krijg zelf op de RuG het eerste jaar alleen maar java, en ik ben daar niet al te blij mee, veel dingen zijn gewoon wat simplistisch en de conventies rond java zijn nooit echt mooi en strak uitgevoerd.
Maar ik denk niet dat mensen slechter gaan programmeren van java, natuurlijk is de taal wat vergeeflijker dan C(++) maar je leert wel degelijk van. En of een programma nu verkeerd loopt/memory leaked of dat er keurig een exception wordt gegooid, dat is toch gewoon beide fout?
(Verder krijgen we hier in het eerste jaar naast java ook 68Kasm dus tsja )
Maar ik denk niet dat mensen slechter gaan programmeren van java, natuurlijk is de taal wat vergeeflijker dan C(++) maar je leert wel degelijk van. En of een programma nu verkeerd loopt/memory leaked of dat er keurig een exception wordt gegooid, dat is toch gewoon beide fout?
(Verder krijgen we hier in het eerste jaar naast java ook 68Kasm dus tsja
)
:strip_icc():strip_exif()/u/148505/31bb5b263ef71bb4d5751e9a89035105.jpeg.jpg?f=community)
:strip_exif()/u/21687/aaron.gif?f=community)
Dan deed je toch echt wat fout. Ik ben nu 10 jaar geleden begonnen met Java, en in die tijd waren zelfs de crappy Sparc bakken bij ons in staat een Swing (nee, geen AWT, 1.2 was net uit) File dialog in no time op het scherm te tonen. Lijkt erop dat je een windows probleem had met netwerkshares ofzo.
Er is geen 'de' GUI. Tegenwoordig is SWT erg gangbaar. Vroegah, als je Swing te traag vondt (en Swing is inderdaad relatief traag omdat het geen gebruik maakt van het onderliggende systeem) ging je gewoon voor AWT. AWT is net zo snel als een .Net Windows forms app. Werkt ook op exact hetzelfde princiepe.
En dat je zegt dat Java traag is bevestig je in de regel boven waar je zegt dat je het niet zegt. Best bizar
[ Voor 4% gewijzigd door Hydra op 18-12-2008 14:04 ]
https://niels.nu
Je reageerde op een post waarin ik weerlegde dat java traag is.
Er zijn twee belangrijke alternatieven voor Swing:
- SWT
- Web-based GUI (vaak misbruikt: pak je de installer van zo'n programma, blijkt dat hij Tomcat installeert met hun applicatie erin
beetje overkill, om het over responsiveness maar niet te hebben)Ik heb inmiddels wel een paar java-programma's gebruikt waarbij de responsiveness van de applicatie zeker niet het probleem is (Eclipse bijvoorbeeld). Dus het kan zeker goed zijn
Dat het traag is ligt dus eerder aan de programmeur dan aan de taal, Java wordt vaak gebruikt om 'enterprisey' applicaties te schrijven, met onnodige abstracties e.d.
[ Voor 8% gewijzigd door MBV op 18-12-2008 14:05 ]
Wie zegt dat swing supervlug is
Niet zo chargeren joh.Maar 10-15 seconden heb ik ook nog nooit meegemaakt, en ik heb van 1998 tot 2004 met Swing gewerkt. Allesbehalve fan van, maar je kan het overdrijven.
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
:strip_icc():strip_exif()/u/190884/dug.jpg?f=community)
The #1 programmer excuse for legitimately slacking off: "My code's compiling"
Firesphere: Sommige mensen verdienen gewoon een High Five. In the Face. With a chair.
:strip_icc():strip_exif()/u/104742/trompet.jpg?f=community)
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
:strip_exif()/u/19853/Goku1.gif?f=community)
Ik zie programmeren als een functionerende applicatie ontwikkelen, en ben het dan ook niet met jou eens.
Als iemand een programma wil hebben wat een mooie 7segmenten output (even voor microcontrollers op een wekker, embedded systems, meer mijn richting), dan kan ik dat ontwikkelen met
if(x=0) { seg_A = true; seg_B = true; }
if(x=1) { seg_A = false; seg_B = true; }
Ik kan dat echter ook met een switch/case doen, veel netter. En als ik echt wil klooien met algoritmes, dan kan ik dat zelfs doen met een karnaugh-diagram en vervolgens
seg_B = !(x&0x02)
Dat laatste vind ik een algoritme, maximale performance eruit halen. Maar is dat altijd nodig? Nee. Iedereen die een ledje kan laten knipperen (electronica's Hello World), kan het goed genoeg maken. Bitfucken, switch/case of desnoods een if/else, ze krijgen het werkend.
Voor programmeertechnieken geld hetzelfde. Ik vind bitfucken erg leuk, maar je *hoeft* het niet te gebruiken. Met if, while en de juiste library functies aanroepen kun je het meeste wel implementeren. Tuurlijk is het handig om classes te gebruiken, overerving e.d. te gebruiken, maar niet altijd, en zonder dat kun je ook prima programmeren. Afhankelijk van je applicatie is dat een marteling, maar dat is nu even niet het punt
Computersystemen? Vooruit, maar daarvoor heb je niet veel meer dan basiskennis nodig. Als je iets wil opslaan, dan kun je dat in een file doen. Nouja, je moet dan weten wat een file is. Tegenwoordig weten teveel mensen niet eens meer wat een pointer is en hoe ze die kunnen gebruiken. Ja, je moet er wel wat van weten, nee, niet alles. Basiskennis is voldoende.
Programmeertalen? Wat bedoel je daar precies mee? Ik moet kennis hebben van andere programmeertalen voordat ik iets ontwikkel? Je hebt daarin gedeeltelijk gelijk, omdat voor sommige applicaties het makkelijker is om een specifieke programmeertaal te gebruiken. Maar dat maakt het niet noodzakelijk om een andere programmeertaal te kennen. Ikzelf heb pas sinds kort fatsoenlijk met VB leren programmeren, maar met C/C++ kan ik, ongeacht de (on)gebruiksvriendelijkheid van de compiler, toch nog sneller programmeren. Maar daar weet ik van dat het aan mij ligt
Wiskunde? Ik nodig je graag uit om bij sommige HBO-opleidingen te komen kijken. Wiskunde wordt, tot mijn grote ergenis overigens, niet standaard meer op fatsoenlijk niveau gegeven op de opleiding. Het heeft nadelen als je met beeldvorming werkt (2d, 3d, audio, externe inputs bij embedded, etc). Maar als je een CMS wil opzetten boeit het totaal niks. Niet veel meer dan if while in ieder geval.
Ik ben het er mee eens dat kennis van de punten die je noemt weldegelijk erg handig is, maar het is geen harde eis zoals jij aangeeft. Zonder dat kun je ook programmeren. Goed? Nouja, je kunt een functionerend programma opzetten binnen reeele tijd. Als ik kijk naar de lichting die van mijn opleiding & jaar af gaan komen, kun je daar al best tevreden mee zijn
Mijn kritieke mening is, onder andere over Java, dat het teveel library's heeft die de leercurve van het programmeren wegnemen. PHP is in dat opzicht, wat mij betreft, nog een stapje erger: je leert er geen algoritmes (meer) mee. Ik vind dat zelf een van de interessantere dingen aan programmeren. Niet hard noodzakelijk, maar soms is het toch verdomd handig als je library je in de steek laat.
En zoals roy-t in "Is java de grootste vloek in de informat..." aangeeft: Memory leak is een bug die je moet fixen, niet afvangen. Voor mijn gevoel (ik programmeer niet in Java), leren mensen niet meer hoe noodzakelijk het is om naar geheugen te kijken.
In zo'n topic even voor de volledigheid, dit is puur zoals ik het ervaar. Ik heb net 5 jaar programmeerervaring op opleiding(en), maar geen echt interessante programmeerervaring buiten mijn huidige stage.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Ik ben afgestudeerd als licentiaat informatica vorig jaar (= master tegenwoordig). En hoewel de focus lag op java, hebben wij op zijn minst de volgende talen gezien:
Java
C
C#
C++
NesC
Pascall
Smalltalk
Visual basic
Perl
Haskell
een taal die lijkt op haskell maar waar de naam mij van ontschiet, Logo of zoiets...
Eiffel
Cobol
..
Ik vergeet er ongetwijfeld nog enkele. En dan natuurlijk nog XML, html, ...
Zou ik een probleem oplossen in java ipv C? Hangt beetje van het probleem af, maar ja waarschijnlijk. Als dat ding zelf garbage collecting doet en ik geen zorgen moet maken over pointers, waarom niet. Ken ik er daarom niets van? Fout. Geef mij een nieuwe taal en ik ben er ook in 2 dagen mee weg, gewoon omdat we de concepten kennen. Ken ik alle bovenstaande talen in detail? Neen natuurlijk niet, maar ik ken de gebruikte concepten, van de meesten nog wat syntax etc...
Java is goed als programmeertaal qua concepten, goede compilers en omdat je nog niet zo moet bezig zijn met pointers. Eens je dat kent kan je verder gaan.
De achteruitgang van de studenten (in informatica maar ook wel algemeen) ligt eerder in de luiheid van jongeren (ikzelf was zeker geen voorbeel van ijverigheid maar ik leerde mezelf dan wel programmeertalen die ik niet kende, voor school werken was iets anders
).En java is inderdaad niet altijd de optimale taal om dingen in te maken, door zijn traagheid soms. Zoals al vaak gezegd in dit topic. Java is niet de beste taal en ook niet de slechtste. Er is geen beste taal, dat hangt af waar je goed in bent en wat je moet schrijven.
Het artikel gelinked in de openingspost is een zoveelste rant uit de miljarden die op internet te vinden zijn. Constructieve posts maken daarentegen ...
:strip_icc():strip_exif()/u/106218/wc-backbone.jpg?f=community)
Sinds .Net3/3.5 loopt .Net toch echt erg voor op java in mijn ogen, ik denk dan vooral vanuit C# maar C# heeft niet eens alle functionaliteiten die IL (*de onderliggende taal van .NET) ondersteund.
Ik heb bij java nog nooit delegates, closures,[unsafe] code blokken met pointers en alles, of props gezien, ook handige toevoegingen als threadpools (ok die kun je ook zelf maken) mis ik. Ik twijfel er nu ook over of ik eigenlijk wel structs in java ken, en ik weet vrij zeker dat je in java niet de layoutkind van je struct kan setten, en zelf kunt aan geven hoe qua geheugen locaties structs worden opgebrouwd. Ook heb ik nog nooit projecten gezien waarbij een deel van het programma hielp met zichzelf compilen. (denk aan apparte compile-projecten en content managers). Ook lijkt .Net wat betreft services veel uitgebreider en zijn er voor Threads veel mooiere contructies dan in Java waar je alleen op een parameterloze manier threads kunt starten waardoor je weer properties moet setten van te voren.
Nu krijg ik waarschijnlijk het argument 'dat kun je zelf maken' wat waarschijnlijk ook wel valide is, aangezien het uiteindelijk allemaal x86 code wordt (of nouja vaak) maar .NET loopt zover ik weet gewoon nu een stuk voor op Java. In java is het veel moeilijker om dichter bij de compiler/computer te komen (dnek aan de handige compiler statements in [] in C#) Misschien dat het met Java7 weer dichter bij elkaar komt.
(verder vind ik C#/.Net over het algemeen wat consistenter dan java, en is de MSDN in mijn ogen beduidend beter dan sun's java documentatie).
@blackangel
Je hebt helemaal gelijk, op de RuG krijgen we iig het eerste jaar absoluut geen informatie over wat een pointer uberhaupt is. Dit komt waarschijnlijk ook mede doordat je in Java geen unsafe code kunt maken (zover ik weet). Imho zou C# een stuk geschikter zijn maar somehow hebben ze op de RuG een soort van Microsoft haat wat er ook echt flink in getrapt wordt hier, (en waar ik ondertussen als ms fanboy een grondige hekel aan begin te krijgen) elke leraar heeft wel weer wat te zeuren op MS, (hoewel vele wel toegeven dat ze liever C# dan Java hadden gegeven
).Ik zou het absoluut niet jammer vinden als ze op de Uni's en HBO's weer Java schrappen en terug gaan naar C++ waar je toch echt veel mee zult moeten werken later (hoewel C++ natuurlijk ook absoluut een rotzooitje is de laatste tijd
) Misschien wordt het is tijd voor een nieuwe high-performance unsafe taal die lekker opgeschoond is (ik weet dat er iets als D++ is maar dat loopt allemaal nog niet zonder industry support.Ons wordt zoals eerder verteld wel memory management geleerd dmv assembly.
Note: waarom is er geen speciaal vak waar je leert debuggen!!! Als je iets vaak doet als programmeur is het wel debuggen, ik durf bijna te zeggen dat je vaker achter de debugger zit dan dat je echt code aan het schrijven bent, dat is mooi te combineren met unit testing wat bij ons nu verstopt wordt in 1 college over OO.
C++09, next year in a compiler suite near you!:
(hoewel C++ natuurlijk ook absoluut een rotzooitje is de laatste tijd
[ Voor 4% gewijzigd door .oisyn op 18-12-2008 17:31 ]
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.
Een vak debuggen zou geen kwaad kunnen, hoe vaak ik dat aan iemand heb moeten uitleggen is niet normaal meer 
Java ontwikkelen in Eclipse met printf-debugging, iemand van een jaar of 40 met 10 jaar java-ervaring
Bij de C# voordelen zit je volgens mij op dingen die platform-afhankelijk zijn (Java moet overal op kunnen draaien, niet alleen x86, dus memory-mgmt aanpassen is dan een stuk minder interessant, en big/little endian is 'leuk' met pointers), en die in 98% van de applicaties niet zinvol zijn. Het kan handig zijn, als een tussenstap tussen C++ en Java-achtige talen.
C++ zit dicht op de hardware, heeft geen VM, en geen standaard toolkit om GUI's en webservices (wat eigenlijk wel?) mee te schrijven. Er zijn genoeg standaarden voor (denk aan QT, of op een ander vlak de Posix-standaard), maar die zijn niet industrie-breed. Zit je weer met het java-probleem: welk framework pakken we, met welke voors en tegens.
Java ontwikkelen in Eclipse met printf-debugging, iemand van een jaar of 40 met 10 jaar java-ervaring Bij de C# voordelen zit je volgens mij op dingen die platform-afhankelijk zijn (Java moet overal op kunnen draaien, niet alleen x86, dus memory-mgmt aanpassen is dan een stuk minder interessant, en big/little endian is 'leuk' met pointers), en die in 98% van de applicaties niet zinvol zijn. Het kan handig zijn, als een tussenstap tussen C++ en Java-achtige talen.
C++ zit dicht op de hardware, heeft geen VM, en geen standaard toolkit om GUI's en webservices (wat eigenlijk wel?) mee te schrijven. Er zijn genoeg standaarden voor (denk aan QT, of op een ander vlak de Posix-standaard), maar die zijn niet industrie-breed. Zit je weer met het java-probleem: welk framework pakken we, met welke voors en tegens.
/u/81985/crop566b00b43645a.png?f=community)
Je weet wel dat dat het probleem is, maar je weet het ook niet zeker?
1.1 en 2.0 zijn idd grote verschillen, maar 3.5 is niets anders dan een extensie op 3.0 die weer een extensie is op 2.0 ...
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
/u/105842/Homer_60x60.png?f=community)
Dat brengt voor de RuG veel gelazer met zich mee; die draaien volledig op Debian Linux.:
[...]
@blackangel
Je hebt helemaal gelijk, op de RuG krijgen we iig het eerste jaar absoluut geen informatie over wat een pointer uberhaupt is. Dit komt waarschijnlijk ook mede doordat je in Java geen unsafe code kunt maken (zover ik weet). Imho zou C# een stuk geschikter zijn maar somehow hebben ze op de RuG een soort van Microsoft haat wat er ook echt flink in getrapt wordt hier, (en waar ik ondertussen als ms fanboy een grondige hekel aan begin te krijgen) elke leraar heeft wel weer wat te zeuren op MS, (hoewel vele wel toegeven dat ze liever C# dan Java hadden gegeven
Read the code, write the code, be the code!
Blijkbaar hebben we nog een communicatie-geschil:
Je hebt wizzkids en prutsers, maar ook die 'normale' mensen. Ik vond het alleen nogal raar klinken; alsof de andere 2 groepen niet normaal zijn. Dus op dat vlak zitten we ook op 1 lijn.
Ik zat aan Hogent, III kun je trouwens enkel daar doen. Er zaten echter ook studenten (SV'ers doel ik dan op) die van Brussel, Brugge, etc. kwamen.zolang de bedrijven mij graag zien komen waar ik solliciteer en het een pluspunt vinden dat ik Toegepaste informatica gedaan heb ben ik blij. En ik ben heeeel blij
BTW waar heb jij je studie gedaan, want dat verschilt ook nogal eens per regio.. Ik heb namelijk genoeg diepgang gehad in de meeste vakken imho.
ASSUME makes an ASS out of U and ME
Dat JFileChooser traag was in veel (maar niet alle!) situaties is/was een bekende bug die voor zover ik weet sinds Java 6 Update 10 pas echt verholpen is (met wat verbeteringen in de afgelopen paar jaar). Het ging - als ik mij goed herinner - vooral mis als de start-folder veel zip-bestanden bevatte oid, en dan hoofdzakelijk onder Windows omdat Sun een bepaalde Win32-API op de verkeerde wijze gebruikte.:
[...]
Geen idee wat het nu allemaal is. Ik heb mijn eindwerk met het leuke Java Swing gemaakt en een gewone filechooser dialog tonen (standaard stuff) duurde de eerste keer 5-15 seconden op álle pc's. 4-5 jaar geleden. Sindsdien nog nauwelijks java/swing aangeraakt na deze traumatische ervaring haha
Natuurlijk doet java het goed op supercomputers (cern/ebay) maar (vroeger) toch niet op desktop clientpc's (met swing gui dus, en laat dat nu het meest gebruikte zijn)...
Dat er zoveel mensen denken dat 'java' traag is, zal wel niet zomaar uit de lucht gegrepen zijn...
@oisyn ik heb nergens gezegd dat java traag is, enkel dat de gui traag is (dus swing of whatever)
Overigens heb ik een paar (kleine) tooltjes gemaakt met Swing, en in mijn ervaring doen zich de meeste problemen met trage UI voor als je zaken afhandelt op de event-thread in plaats van via een SwingWorker of een losse Thread ed.
Daarnaast is het natuurlijk een feit dat Sun gewoon een vreemde beslissing heeft genomen door de systeem look- en feel te emuleren ipv de systeem-eigen widgets te gebruiken (zoals SWT bijvoorbeeld doet), die emulatie zorgt voor vertraging (ook omdat het veelal niet via de 2D accelarator gaat, pas sinds Java 6 Update 10).
In tegenstelling tot eerdere posts is Swing NIET deprecated (Sun heeft in Java 6 Update 10 zelfs een nieuwe platformonafhankelijke look-en feel geïntroduceerd.
ik somde een paar feiten op: lambda-calculus-concepten worden ook wel functioneel programmeren genoemd wanneer je dat toepast in programma's (functies zijn 'first-class citizens'). De eerste talen die dit concept ondersteunden waren dynamische programmeertalen. Nu pak ik weer je originele reactie erbij:
Lambda expressions zijn iets heel kenmerkends voor dynamische talen. Zo ongeveer alle dynamische talen ondersteunen lambda-expressies, terwijl het een concept is wat tot voor kort niet voorkwam in statische programmeertalen. Dus jouw opmerking vond ik echt nergens op slaan.
Waarom C# en Java trouwens geen dynamische programmeertalen zouden zijn zou ik niet weten: met reflection enzo kan je run-time de uitgevoerde code veranderen, waarmee het een dynamische programmeertaal is.
offtopic:
The reflections are all wrong
The reflections are all wrong
:strip_icc():strip_exif()/u/85602/ElvisSpace_112.jpg?f=community)
De grootste vloek in de informatica was toch goto? 
Ontopic:
Volgens mij verwordt deze discussie nu voornamelijk een Java vs .net verhaal. Terwijl deze talen imho toch een hele hoop zaken gemeen hebben, en deels met dezelfde ideeën in het achterhoofd zijn ontwikkeld: een heldere object georiënteerde taal, middels bytecode draaiende in een virtual machine met garbage collection, het aanbieden van een uitgebreide collectie libraries voor datastructuren, netwerken, etc etc om direct een multifunctionele taal neer te zetten, het aanpakken van de nadelen van C/C++.
Waar de platformen enigszins in verschillen zijn de nadrukken op platformonafhankelijkheid, het toch kunnen gebruiken van unsafe code en het aantal taalvarianten. Inmiddels zou je ook het licentiemodel als verschil kunnen aanmerken.
Maar goed, er was dus een tijd dat de insteek van deze twee talen helemaal de toekomst leek. (En omdat Java eerder op de markt verscheen is het misschien daardoor in het onderwijs inmiddels meer omarmd dan .net).
Dus. Moeten we de oorzaak van de gevreesde teloorgang misschien meer zoeken in het idee dat informatici begin jaren negentig de verkeerde toekomstvisie hadden?
Edit: En dan bedoel ik dus te zeggen dat het volgens mij niet zozeer om de implementatie gaat, maar om de concepten. Het doel was volgens mij om sneller software te kunnen maken, met minder fouten.
Ontopic:
Volgens mij verwordt deze discussie nu voornamelijk een Java vs .net verhaal. Terwijl deze talen imho toch een hele hoop zaken gemeen hebben, en deels met dezelfde ideeën in het achterhoofd zijn ontwikkeld: een heldere object georiënteerde taal, middels bytecode draaiende in een virtual machine met garbage collection, het aanbieden van een uitgebreide collectie libraries voor datastructuren, netwerken, etc etc om direct een multifunctionele taal neer te zetten, het aanpakken van de nadelen van C/C++.
Waar de platformen enigszins in verschillen zijn de nadrukken op platformonafhankelijkheid, het toch kunnen gebruiken van unsafe code en het aantal taalvarianten. Inmiddels zou je ook het licentiemodel als verschil kunnen aanmerken.
Maar goed, er was dus een tijd dat de insteek van deze twee talen helemaal de toekomst leek. (En omdat Java eerder op de markt verscheen is het misschien daardoor in het onderwijs inmiddels meer omarmd dan .net).
Dus. Moeten we de oorzaak van de gevreesde teloorgang misschien meer zoeken in het idee dat informatici begin jaren negentig de verkeerde toekomstvisie hadden?
Edit: En dan bedoel ik dus te zeggen dat het volgens mij niet zozeer om de implementatie gaat, maar om de concepten. Het doel was volgens mij om sneller software te kunnen maken, met minder fouten.
[ Voor 7% gewijzigd door zwippie op 18-12-2008 20:44 ]
How much can you compute with the "ultimate laptop" with 1 kg of mass and 1 liter of volume? Answer: not more than 10^51 operations per second on not more than 10^32 bits.
offtopic:
De grootste vloek is Cobol. "It's not dead yet, it just smells funny." Zal ik morgen even een snippet copy/pasten? Dan wil iedereen direct weer Java programmeren
De grootste vloek is Cobol. "It's not dead yet, it just smells funny." Zal ik morgen even een snippet copy/pasten? Dan wil iedereen direct weer Java programmeren
Ik denk dat een paar pagina's terug de juiste opmerking is gemaakt: we willen dat meer mensen kunnen programmeren (in 1998 werd je met alleen VWO nog aangenomen als programmeur
), dat betekent dat je niet al te selectief kan zijn. En dat betekent weer dat je ook mindere goden moet accepteren als informaticus. De Nederlandse cultuur dat we allemaal manager moeten worden als promotie helpt daar niet bij. Een van de tools die het mogelijk maakte om relatief eenvoudig complexe programma's te schrijven was Java, die hier het zondebok lijkt te worden.
Dus nee, ik denk niet dat de toekomstvisie verkeerd was. Eerder de ambities te hoog. Het echte probleem zat namelijk niet in de techniek, maar in de praktijk van te weinig testen en structuur.
[ Voor 24% gewijzigd door MBV op 18-12-2008 20:52 ]
:strip_icc():strip_exif()/u/7307/images.jpg?f=community)
Roy-t, waarom zou C# volgens jou een geschikter platform zijn om studenten te leren programmeren? Je komt met allemaal argumenten (unsafe code blokken, geheugenindeling van structs, dichter bij de compiler komen) die het leren programmeren alleen maar moeilijker maken in het begin.
Hoe vaak heb je al gesolliciteerd? Zoveel wordt er niet meer gedaan in C++ voorzover ik weet.
offtopic:
Welke leraren willen volgens jou liever doceren in C#? Benieuwd
Welke leraren willen volgens jou liever doceren in C#? Benieuwd
Onvoorstelbaar!
Als je C, C++ en nog een taal hebt geleerd kan je de meeste imperatieve talen heel snel onder de knie krijgen. Ik heb laatst ook wat gedaan in C#, en met een beetje googlen kom je er wel. En of je nu een diploma hebt met 0 ervaring en een schoolprojectje in C++, of 0 ervaring en een schoolprojectje in Java, dat zal de meeste bedrijven een worst wezen. Zeker uit het HBO ga je direct op cursus, en leren ze je in 3 maanden opnieuw programmeren (bij de grote bedrijven):
Roy-t, waarom zou C# volgens jou een geschikter platform zijn om studenten te leren programmeren? Je komt met allemaal argumenten (unsafe code blokken, geheugenindeling van structs, dichter bij de compiler komen) die het leren programmeren alleen maar moeilijker maken in het begin.
[...]
Hoe vaak heb je al gesolliciteerd? Zoveel wordt er niet meer gedaan in C++ voorzover ik weet.
offtopic:
Welke leraren willen volgens jou liever doceren in C#? Benieuwd
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.
Algortimes zijn een systematische manier om een bepaald probleem op te lossen. Dat laatste statement kan net zo goed onderdeel zijn van een algoritme als dat eerste stuk. Daarbij gaat je argument imho mank. Kennis gaat niet alleen over toepassingen. Ander begrip van kennis veroorzaakt ook spraakverwarringen. Wij hebben blijkbaar een ander begrip van de term algoritme.
Om deze afwegingen te maken moet je de programmeertechnieken op zijn minst kennen en kunnen toepassen. Als je een brede kennis hebt op dit gebied, dan kun je goed bepalen wanneer je welke techniek toepast. Waardoor je inderdaad martelgangen voorkomt. Ik ben het compleet met je eens wat hierboven staat, maar het is geen argument tegen wat ik stelde.Voor programmeertechnieken geld hetzelfde. Ik vind bitfucken erg leuk, maar je *hoeft* het niet te gebruiken. Met if, while en de juiste library functies aanroepen kun je het meeste wel implementeren. Tuurlijk is het handig om classes te gebruiken, overerving e.d. te gebruiken, maar niet altijd, en zonder dat kun je ook prima programmeren. Afhankelijk van je applicatie is dat een marteling, maar dat is nu even niet het punt
Als je goed wilt kunnen programmeren, moet je mijns inziens de beperkingen van systemen kennen. Dat kan zijn de bandbreedte van een databus of netwerkverbinding. Het begrip van geheugen allocatie en lowlevel dingen die achter de schermen gebeuren, kunnen een hoop problemen verklaren die men vaak tegen komt. Ik ben het met je eens dat het allemaal niet noodzakelijk is, maar het is beter om deze kennis wel te hebben. Je wilt immers dat jouw product van de hoogste kwaliteit is.
Je moet toch de syntax en standaard structuren van een programmeertaal kennen om deze te kunnen gebruiken? Dit bedoel ik letterlijk, lijkt me volkomen terecht.Programmeertalen? Wat bedoel je daar precies mee? Ik moet kennis hebben van andere programmeertalen voordat ik iets ontwikkel? Je hebt daarin gedeeltelijk gelijk, omdat voor sommige applicaties het makkelijker is om een specifieke programmeertaal te gebruiken. Maar dat maakt het niet noodzakelijk om een andere programmeertaal te kennen. Ikzelf heb pas sinds kort fatsoenlijk met VB leren programmeren, maar met C/C++ kan ik, ongeacht de (on)gebruiksvriendelijkheid van de compiler, toch nog sneller programmeren. Maar daar weet ik van dat het aan mij ligt
Mja, komen we weer uit op hetzelfde punt als de kennis over computersystemen. Kennis van wiskunde helpt je complexe problemen sneller oplossen. Als je minder kennis hebt, zul je in de praktijk vaak langer doen over complexe problemen.
Het waren ook geen harde eisen hoorIk ben het er mee eens dat kennis van de punten die je noemt weldegelijk erg handig is, maar het is geen harde eis zoals jij aangeeft. Zonder dat kun je ook programmeren. Goed? Nouja, je kunt een functionerend programma opzetten binnen reeele tijd. Als ik kijk naar de lichting die van mijn opleiding & jaar af gaan komen, kun je daar al best tevreden mee zijn
Gewoon mijn mening en het waarom achter die mening. Ik denk dat we het op veel punten eens zijn.Java is erg uitgebreid, zonder enige andere kennis kun je inderdaad erg eenvoudig de weg kwijt raken. Je hoeft die libraries niet te gebruiken. Java kan een goede tool zijn, maar het wordt nu eenvoudigweg teveel gebruikt om te leren.
Jouw ervaring kan anders zijn dan mijn mening. Ik wil benadrukken: het blijft subjectief
Grofweg gezien wel. Hoe meer verstand je hebt van die punten, hoe beter. Dat betekend wat mij betreft niet dat je zonder die punten ook een functionerende applicatie neer kunt zetten, alleen wordt het uiteindelijk een marteling. Voordat ik C++ kende (wel classes, geen overerving:
[...]
Het waren ook geen harde eisen hoor
), heb ik mijzelf vaak genoeg gepijnigd inderdaad. Maar dat betekend niet dat ik het niet functionerend neer kon zetten.En ik zie dat we een aantal verschillen in begripdefinities hebben. Als ik die van jouw zo lees, heb jij in die punten zeker gelijk
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
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.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Je draait nogsteeds code in een VM, het vm vangt alles af, je hoeft dus alleen te weten of het .Net vm big of little endian is, het VM zelf zorgt er wel voor dat het goed vertaald wordt naar de computer! (.Net draait bijvoorbeeld ook op de Xbox360 en op de Zune, ik dacht dat de 360 een powerpc achtige processor had en de zune heeft iig geen x86 processor:
Een vak debuggen zou geen kwaad kunnen, hoe vaak ik dat aan iemand heb moeten uitleggen is niet normaal meer
Bij de C# voordelen zit je volgens mij op dingen die platform-afhankelijk zijn (Java moet overal op kunnen draaien, niet alleen x86, dus memory-mgmt aanpassen is dan een stuk minder interessant, en big/little endian is 'leuk' met pointers), en die in 98% van de applicaties niet zinvol zijn. Het kan handig zijn, als een tussenstap tussen C++ en Java-achtige talen.
C++ zit dicht op de hardware, heeft geen VM, en geen standaard toolkit om GUI's en webservices (wat eigenlijk wel?) mee te schrijven. Er zijn genoeg standaarden voor (denk aan QT, of op een ander vlak de Posix-standaard), maar die zijn niet industrie-breed. Zit je weer met het java-probleem: welk framework pakken we, met welke voors en tegens.
. Het heeft dus zeker wel nut, .Net is dan ook net zo platform afhankelijk als Java! Verder zie ik niet hoe closures en delegates ooit platform afhankelijk kunnen zijn .Verschilt misschien per faculteit maar op de informatica faculteit zijn ale systemen dual-boot Wingtips(Windows+Novel)/Linux (dacht suse of ubuntu).
@ Oisyn, ah C++09, ik zit er echt op te wachten! Maar wat duurt het lang voordat het komt, de nieuwste versie is toch al 6 jaar oud?
@Janoz: alles in hogere programmeer talen is syntaxtische suiker voor machine-code expressies, dat gaf ik ook al aan in mijn eerste post. Hoe je het nu implementeerd of maakt of bouwt in C++/C#/Java, met of zonder VM, het wordt uiteindelijk uitgevoerd als machine code. Dit is dan ook niet een erg sterk argument. Vooral ook omdat callback interfaces toch net even iets anders zijn dan delegates. (ok je kunt er dezelfde functionaliteit mee bouwen, maar het is geen foreach loop vs een for loop
.
[ Voor 10% gewijzigd door roy-t op 19-12-2008 17:39 ]
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)
:strip_icc():strip_exif()/u/35767/images.jpg?f=community)
De Zune en XBox360 draaien het compact framework, dus ik weet niet of die alle leuke gimmicks die eerder zijn opgenoemd daarin draaien. O.a. delegates werken niet, de rest kan ik zo 1-2-3 niet vinden.:
[...]
Je draait nogsteeds code in een VM, het vm vangt alles af, je hoeft dus alleen te weten of het .Net vm big of little endian is, het VM zelf zorgt er wel voor dat het goed vertaald wordt naar de computer! (.Net draait bijvoorbeeld ook op de Xbox360 en op de Zune, ik dacht dat de 360 een powerpc achtige processor had en de zune heeft iig geen x86 processor
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.