HR'ers, Is Xamarin toegestaan als vervanging voor java?

[Verwijderd]

1 september ga ik beginnen aan de opleiding Informatica aan de Hogeschool Rotterdam en ik vroeg me af of java verplicht is, of kan je het ook vervangen voor Xamarin als je een android app maakt?
het voordeel van Xamarin is natuurlijk overduidelijk, het is even snel als native (en soms wel sneller) en je kan je apps over 3 platformen (iOS, Windows 10 Mobile en Android) verspreiden met maar één programmeertaal (C#)

Natuurlijk zijn er ook nadelen (google maar even) maar die wegen niet op tegen de voordelen.

Iemand die informatica student is aan HR en hier ervaring mee heeft?

[boe2]

Wel, je vergelijkt een framework met specifiek doel met een programmeertaal

Ik weet niet hoe waardevol java in de toekomst nog gaat zijn als platform-onafhankelijke taal, nu .NET volledig open source gegaan is. Met dat in gedachte lijkt Xamarin/.NET mij nuttiger te zijn.

[Jogai]

Wat boe2 zegt en:
Ze geven java om je OOP te leren. Volgens mij geven ze ook microsoft cursussen als keuze vak. Als je de 2e nu kan inwisselen voor de java lessen ben je klaar.

[Janoz]

Voor het leren van algoritmiek maakt de taal eigenlijk niet zo heel veel uit. Ik zou dan ook niet moeilijk gaan lopen doen. Xamarin lijkt me voor dergelijke vakken compleet kansloos aangezien er helemaal geen complete apps gebouwd worden.

Tot slot zou ik niet onderschatten hoe groot Java is ivm C#. In de praktijk wordt de eerste namelijk 2 tot 3 keer zo veel gebruikt als de laatste.

[Davidshadow13]

Eigenlijk maakt het ook helemaal niet zoveel uit. Als je Java leert dan kun je in principe ook C# met weinig aanpassingen. Die talen lijken best wel veel op elkaar op wat Framework specifieke zaken na. Ook de concepten zijn hetzelfde.

Java wordt alleen gebruikt om de concepten van OOP aan te leren als je die eenmaal goed aangeleerd hebt dan moet je instaat zijn deze zonder al teveel problemen in elke objectgeoriënteerde taal toe te passen.

[Verwijderd]

Janoz schreef op vrijdag 31 juli 2015 @ 13:52:
Voor het leren van algoritmiek maakt de taal eigenlijk niet zo heel veel uit. Ik zou dan ook niet moeilijk gaan lopen doen. Xamarin lijkt me voor dergelijke vakken compleet kansloos aangezien er helemaal geen complete apps gebouwd worden.

Tot slot zou ik niet onderschatten hoe groot Java is ivm C#. In de praktijk wordt de eerste namelijk 2 tot 3 keer zo veel gebruikt als de laatste.

Niet compleet? http://xamarin.com/platform

Native API Access

Xamarin apps have access to the full spectrum of functionality exposed by the underlying platform and device, including platform-specific capabilities like iBeacons and Android Fragments.

en

C# is the best language for mobile app development.
Anything you can do in Objective-C, Swift or Java, you can do in C#.

Share code everywhere.

Use the same language, APIs and data structures to share an average of 75% of app code across all mobile development platforms. Build user interfaces with Xamarin.Forms and share nearly 100%.

[Trolando]

Leuk dat je handig bent in C#, maar waarom wil je geen Java leren? Waarom zou je jezelf de mogelijkheid om een andere taal te leren, ontzeggen?

Bovendien moet de lesstof compleet worden herzien en herschreven als je van programmeertaal verandert; men gebruikt Java omdat dit al tien jaar gebruikt wordt in de lessen.

Anything you can do in C#, you can do in <willekeurige andere taal> too....

[Janoz]

Verwijderd schreef op vrijdag 31 juli 2015 @ 15:35:
[...]


Niet compleet? http://xamarin.com/platform

Native API Access

Xamarin apps have access to the full spectrum of functionality exposed by the underlying platform and device, including platform-specific capabilities like iBeacons and Android Fragments.

en

C# is the best language for mobile app development.
Anything you can do in Objective-C, Swift or Java, you can do in C#.

Share code everywhere.

Use the same language, APIs and data structures to share an average of 75% of app code across all mobile development platforms. Build user interfaces with Xamarin.Forms and share nearly 100%.

Dat WC-Eend verhaal is allemaal heel leuk en grappig, maar compleet niet relevant voor wat je gaat leren en doen. API's en syntax leren is iets wat je keurig in je eigen tijd kunt doen. Tijdens je studie leer je algoritmiek en analytische vaardigheden. De gebruikte taal is een middel, niet een doel.

[Vaan Banaan]

In mijn tijd dat ik de HIO deed (1990 - 1996) hoefde je helemaal geen kennis te hebben van een specifieke programmeertaal.
De eerste 2 jaar was het vooral concepten (software engeneering) dus: Hoe maak je een programma in functionele blokjes
Ik kan me herinneren dat we vooral les kregen in
• database normalisatie
• (kritieke) paden en grafen,
• queues en stacks (BFS en DFS)
• recursie vs loops
• Paging (toentertijd was 1 MB geheugen nog veul)
• Multitasking (semaphores / mutex)
• Tree balancing
• Spreadsheets (Lotus 123, jawel!)
En verder:
• Lineaire algebra (Matrices)
• Technisch Engels
• Bedrijfskunde
• Boekhouding

[NMe]

Verwijderd schreef op vrijdag 31 juli 2015 @ 13:41:
1 september ga ik beginnen aan de opleiding Informatica aan de Hogeschool Rotterdam en ik vroeg me af of java verplicht is, of kan je het ook vervangen voor Xamarin als je een android app maakt?

En wat zegt de school daarover?

[jip_86]

Verwijderd schreef op vrijdag 31 juli 2015 @ 13:41:
1 september ga ik beginnen aan de opleiding Informatica aan de Hogeschool Rotterdam en ik vroeg me af of java verplicht is, of kan je het ook vervangen voor Xamarin als je een android app maakt?
het voordeel van Xamarin is natuurlijk overduidelijk, het is even snel als native (en soms wel sneller) en je kan je apps over 3 platformen (iOS, Windows 10 Mobile en Android) verspreiden met maar één programmeertaal (C#)

Natuurlijk zijn er ook nadelen (google maar even) maar die wegen niet op tegen de voordelen.

Iemand die informatica student is aan HR en hier ervaring mee heeft?

Je krijgt java om object georienteerd te leren programmeren. Als je xamarin wilt gebruiken om voor drie platforms apps te gaan ontwikkelen schiet je het doel van het vak veel te ver voorbij. Daarnaast kan wat kennis van een andere taal nooit kwaad. Heb zelf mijn afstudeeropdracht in Delphi gedaan terwijl ik daar nooit iets mee gedaan had op de opleiding.

[johnkeates]

Ik zou wel Java nemen, dan leer je een taal die vrij groot is en vrij hard kan performen op grote schaal. Er zit een dikke geschiedenis achter, en er is altijd goed werk in te vinden.

Met de huidige inrichting van opleidingen komen er elk jaar weer meer dan honderd junior C# .NET programmeurs bij, niet echt iets waardoor je een onderscheidende factor krijgt. Verder is hoe open source het ook is C# nog steeds vooral een Microsoft-ding. Hetzelfde geldt voor Xamarin dat het een net-niet-native-Mobile-Apps-only ding is. Je op een opleiding al zo vergaand beperken lijkt me niet verstandig.

Juist met een opleiding heb je kans om naast de basis zaken zoals OOP, patronen en architectuur ook
flink wat rond te kijken qua talen, frameworks en bestuuringssystemen. Dat je vooral Microsoft kent/ziet betekent lang niet dat het buiten huis-tuin-keuken gebruik daadwerkelijk groot of goedbetaald is.

[Megamind]

Eerste 4 periode's zijn toch geen apps maken Gewoon Java leren, syntax komt overeen met C#. In jaar 2 krijg je al geen programmeerlessen meer zowat en met projecten kan je gewoon je eigen framework / taal gebruiken.

[Gomez12]

Ik vraag me eigenlijk af of je wel weet waar je aan begint?

Xamarin of welke (app-) taal dan ook is totaal niet relevant voor dat soort opleidingen, de opleiding geeft je een solide basis die je in principe in elke taal moet kunnen toepassen.

Ze gaan je niet leren hoe je apps moet schrijven (laat staan in 1 specifieke taal), ze gaan je leren hoe je moet programmeren.

Het hele noemen van Xamarin is wmb al een vraagteken of je wel begrijpt wat voor opleiding je gaat doen...

[EddoH]

Ik ben vooral verbaasd over het feit dat je geen nieuwe taal wilt leren maar je het met bestaande kennis wilt doorlopen. Het doel van een studie is om nieuwe dingen te leren, niet om een diploma te halen met kennis die je al hebt...

Nieuwe dingen leren (in de breedste zin van het woord) is toch juist leuk? Waarom zou je nou juist dat over willen slaan?

[BoringDay]

Zonder de basis mis je het meest belangrijke.
Begin bij C en erna C++ (OOP/Design patterns/Callbacks/Reflection/bouwen van een project via de prompt ect.)

Hou je daarna pas met een omgeving (IDE) waarvan jij vind dat het prettig werkt en bij je doelstelling past.

Programmeren leer je niet even in een jaar tijd, dan heb je lang niet alle kennis tot je beschikking.

[ Voor 20% gewijzigd door BoringDay op 31-07-2015 22:20 ]

[Megamind]

BoringDay schreef op vrijdag 31 juli 2015 @ 22:18:
Zonder de basis mis je het meest belangrijke.
Begin bij C en erna C++ (OOP/Design patterns/Callbacks/Reflection/bouwen van een project via de prompt ect.)

Hou je daarna pas met een omgeving (IDE) waarvan jij vind dat het prettig werkt en bij je doelstelling past.

Programmeren leer je niet even in een jaar tijd, dan heb je lang niet alle kennis tot je beschikking.

Hij heeft het over een Informatica opleiding, niet TI

[BoringDay]

Dat behoort toch gewoon tot het vak programmeren? Ik mag hopen dat het niveau wat hoger ligt dan slechts wat 'hello world' appjes te maken.

[Megamind]

Echt geen C en dan C++. Je leert 1/2 modules syntax Java, loopjes e.d. en daarna datastructuren en alogoritmes. En dan heb ik het over technische informatica, informatica is vooral appjes bouwen ja.

[BoringDay]

Megamind schreef op vrijdag 31 juli 2015 @ 22:34:
Echt geen C en dan C++. Je leert 1/2 modules syntax Java, loopjes e.d. en daarna datastructuren en alogoritmes. En dan heb ik het over technische informatica, informatica is vooral appjes bouwen ja.

Vreemd in mijn tijd was de informatica opleiding (HIO) wel wat meer dan appjes maken en
Technische informatica was meer gericht op automatisering.

[Croga]

BoringDay schreef op vrijdag 31 juli 2015 @ 22:51:
Vreemd in mijn tijd was de informatica opleiding (HIO) wel wat meer dan appjes maken en
Technische informatica was meer gericht op automatisering.

Het is ook wel wat meer dan appjes maken. Het gaat over algorithmen, datastructuren, OO, design patterns. Maar daar heb je geen C++ voor nodig en al helemaal geen C.

Laat ze vooral rustig beginnen met Java of C#, waar de focus juist ligt op de voorgenoemde zaken. Als ze dan meer aan de technische kant willen gaan kijken (naar geheugen management, stack management, etc.) dan kunnen ze altijd nog naar C gaan kijken. Maar dat is werk wat tegenwoordig vooral bij de compiler/VM makers ligt, en niet bij het gros van de programmeurs.

[BoringDay]

Croga schreef op zaterdag 01 augustus 2015 @ 10:18:
[...]

Het is ook wel wat meer dan appjes maken. Het gaat over algorithmen, datastructuren, OO, design patterns. Maar daar heb je geen C++ voor nodig en al helemaal geen C.

Laat ze vooral rustig beginnen met Java of C#, waar de focus juist ligt op de voorgenoemde zaken. Als ze dan meer aan de technische kant willen gaan kijken (naar geheugen management, stack management, etc.) dan kunnen ze altijd nog naar C gaan kijken. Maar dat is werk wat tegenwoordig vooral bij de compiler/VM makers ligt, en niet bij het gros van de programmeurs.

Het is juist slim om met C/C++ te beginnen omdat bijna elke huidige taal hierop gebaseerd is.
Doe je voordeel ermee zou ik zeggen.

Algoritme, datastructuren, OO, design patterns is allemaal niet heel spannend.

[Jeroen]

Mijn ervaring met informaticaopleidingen is dat het praktisch is om gewoon de opdrachten te doen in de aanbevolen talen, omdat je zo een hoop talen leert. Je zult zien dat de simpele dingen allemaal wel overeenkomen zodra je de syntaxis hebt uitgevogeld, en dan kun je tenminste goed onderbouwd beoordelen welke platforms en talen in welke gevallen het meest geschikt zijn. Talen leren is niet moeilijk, maar verschillende soorten talen hebben wel andere moeilijkheden. Zo is bijvoorbeeld het gedoe in C/C++ met geheugenbeheer t.o.v. een garbage-collected taal een gigantisch gezeik voor de meeste toepassingen, maar soms is het juist nuttig. Volgens mij zul je dat vrijwel nooit nodig hebben.

[ Voor 30% gewijzigd door Jeroen op 01-08-2015 11:00 ]

[Salmon]

Ik doe zelf die opleiding Op de HRO (in september 3e jaar in) en je krijgt gewoon java, 3 periodes in t eerste jaar. Sinds vorig jaar mogen de eerste jaars ook C# doen ipv java voor veel dingen + tentamens. Maar als je eenmaal java een beetje kan, kan je C# ook zo oppakken!

Ik zou gewoon aanraden om mee te doen met Java In de laatste periode van jaar 1 krijg je trouwens pas een project om een app te maken.

[Croga]

BoringDay schreef op zaterdag 01 augustus 2015 @ 10:55:
Het is juist slim om met C/C++ te beginnen omdat bijna elke huidige taal hierop gebaseerd is.
Doe je voordeel ermee zou ik zeggen.

En juist die basis is voor 99% van de mensen absoluut en totaal onbelangrijk. Er is een heel goede reden waarom de nieuwere talen er zijn; C/C++ bevatten eisen aan de programmeur die niet van belang zijn voor het doel van de software en waar een programmeur zich dus ook helemaal niet mee bezig zou moeten houden.

Algoritme, datastructuren, OO, design patterns is allemaal niet heel spannend.

Dat is waar de waarde van de software vandaan komt. De functionaliteit van een applicatie zit in algorithmen, niet in geheugen management. En dus wil je dat eerste wel leren en dat laatste niet.

Laten we vooral niet vergeten wat het uiteindelijke doel van ons werk als programmeur is: Waarde creëren voor degene die de software gebruikt. Een algorithme heeft waarde, geheugen management heeft geen waarde. Spendeer dus alsjeblieft zo min mogelijk tijd aan de zaken die geen waarde hebben. De groei van C naar C#/Java bestaat grotendeels uit het verwijderen van zaken die geen waarde hebben en daarmee het versnellen van het creëren van waarde.

(zoals gezegd; tenzij je compilers/VMs programmeert. Houdt je dan vooral bezig met geheugen management en stack management zodat je gebruiker, de programmeur, zich daar niet mee hoeft te vermoeien )

[ Voor 7% gewijzigd door Croga op 01-08-2015 11:08 ]

[BoringDay]

Croga schreef op zaterdag 01 augustus 2015 @ 11:07:
[...]

En juist die basis is voor 99% van de mensen absoluut en totaal onbelangrijk. Er is een heel goede reden waarom de nieuwere talen er zijn; C/C++ bevatten eisen aan de programmeur die niet van belang zijn voor het doel van de software en waar een programmeur zich dus ook helemaal niet mee bezig zou moeten houden.

[...]

Dat is waar de waarde van de software vandaan komt. De functionaliteit van een applicatie zit in algorithmen, niet in geheugen management. En dus wil je dat eerste wel leren en dat laatste niet.

Laten we vooral niet vergeten wat het uiteindelijke doel van ons werk als programmeur is: Waarde creëren voor degene die de software gebruikt. Een algorithme heeft waarde, geheugen management heeft geen waarde. Spendeer dus alsjeblieft zo min mogelijk tijd aan de zaken die geen waarde hebben. De groei van C naar C#/Java bestaat grotendeels uit het verwijderen van zaken die geen waarde hebben en daarmee het versnellen van het creëren van waarde.

(zoals gezegd; tenzij je compilers/VMs programmeert. Houdt je dan vooral bezig met geheugen management en stack management zodat je gebruiker, de programmeur, zich daar niet mee hoeft te vermoeien )

99% van de basiskennis niet van belang? Ik vind dat een uitspraak als vergelijkingen maken in wiskunde maar niet tot 10 kunnen tellen. Maar goed ik laat het hier bij.

[Croga]

BoringDay schreef op zaterdag 01 augustus 2015 @ 12:15:
99% van de basiskennis niet van belang? Ik vind dat een uitspraak als vergelijkingen maken in wiskunde maar niet tot 10 kunnen tellen. Maar goed ik laat het hier bij.

Vergelijk het eerder met wiskunde maar niet kunnen herleiden waar de stelling van Pythagoras vandaan komt. 99% van de mensen heeft er helemaal niets aan om die stelling te kunnen herleiden en dus leer je het niet op school. Wil je fundamenteel onderzoek naar Wiskunde gaan doen, dan zul je het moeten leren maar wil je gewoon wiskunde in het dagelijks leven kunnen toepassen dan heb je er geen ruk aan.

[BoringDay]

Croga schreef op zaterdag 01 augustus 2015 @ 12:51:
[...]

Vergelijk het eerder met wiskunde maar niet kunnen herleiden waar de stelling van Pythagoras vandaan komt. 99% van de mensen heeft er helemaal niets aan om die stelling te kunnen herleiden en dus leer je het niet op school. Wil je fundamenteel onderzoek naar Wiskunde gaan doen, dan zul je het moeten leren maar wil je gewoon wiskunde in het dagelijks leven kunnen toepassen dan heb je er geen ruk aan.

Zelf weten, wat ik weet uit ervaring is dat basis kennis belangrijk is.
Als je al geen aandacht aan geheugen management wil besteden, veel succes met pointers, memory leaks ect.

[Croga]

BoringDay schreef op zaterdag 01 augustus 2015 @ 13:03:Zelf weten, wat ik weet uit ervaring is dat basis kennis belangrijk is.
Als je al geen aandacht aan geheugen management wil besteden, veel succes met pointers, memory leaks ect.

Precies. Al die dingen waar de gemiddelde programmeur, aan memory management kant, helemaal niet over na hoeft te denken.

Pointers zijn verleden tijd. Memory leaks komen alleen nog voor als gevolg van slecht gebruik van design patterns. (eigenlijk bestaan memory leaks ook niet meer; alleen nog het vasthouden van obsolete variabelen).

[BoringDay]

Croga schreef op zaterdag 01 augustus 2015 @ 13:10:
[...]

Precies. Al die dingen waar de gemiddelde programmeur, aan memory management kant, helemaal niet over na hoeft te denken.

Pointers zijn verleden tijd. Memory leaks komen alleen nog voor als gevolg van slecht gebruik van design patterns. (eigenlijk bestaan memory leaks ook niet meer; alleen nog het vasthouden van obsolete variabelen).

Pointers verleden tijd? Memory leaks bestaan niet meer?
Weet je, ik laat het hier bij. Succes!

[johnkeates]

Croga schreef op zaterdag 01 augustus 2015 @ 13:10:
Pointers zijn verleden tijd. Memory leaks komen alleen nog voor als gevolg van slecht gebruik van design patterns. (eigenlijk bestaan memory leaks ook niet meer; alleen nog het vasthouden van obsolete variabelen).

Weet je überhaupt wel waar je het over hebt? Wat voor engineer of student ben je?

[Croga]

johnkeates schreef op zaterdag 01 augustus 2015 @ 13:42:Weet je überhaupt wel waar je het over hebt? Wat voor engineer of student ben je?

25 jaar programmeer ervaring, begonnen met Assembly, door naar zo'n beetje iedere taal die er in gebruik geweest is....

Ik heb me meer dan vaak genoeg druk gemaakt over het soort onzin wat je in C allemaal moet afdekken en houd me nu liever bezig met wat de gebruiker nodig heeft.

De wereld is verandert. Sommige programmeurs snappen dat niet. Dat zijn de programmeurs die nu overtollig zijn en klagen dat De Jeugd het allemaal niet begrijpt.

[Cilph]

Er zullen altijd mensen moeten zijn voor het ontwikkelen van compilers, assemblers, high-performant systemen, game engines, etcetera. Verder geeft kennis over pointers, caches en geheugenmanagement je intuitie om performance problemen op te lossen ook in hogere talen.

[johnkeates]

Croga schreef op zaterdag 01 augustus 2015 @ 14:15:
[...]

25 jaar programmeer ervaring, begonnen met Assembly, door naar zo'n beetje iedere taal die er in gebruik geweest is....

Ik heb me meer dan vaak genoeg druk gemaakt over het soort onzin wat je in C allemaal moet afdekken en houd me nu liever bezig met wat de gebruiker nodig heeft.

De wereld is verandert. Sommige programmeurs snappen dat niet. Dat zijn de programmeurs die nu overtollig zijn en klagen dat De Jeugd het allemaal niet begrijpt.

Maar dan zal je toch ook wel moeten snappen dat er meer is dan alleen maar end-user software or managed talen die in een of andere runtime verdwijnen? En dat je met een probleem zit als niemand je runtime kan schrijven om dat die zelf niet in een managed taal geschreven wordt? Of dat je kernel echt niet in Java of C# geschreven wordt? Of dat je BIOS geen benul heeft van al die high-level taaltjes? En dat embedded systemen vaak de luxe van vrij geheugen en vrije cycles niet kent en daarmee alles wat 'hoger' dan C is niet eens mogelijk maakt?

Stel dat je de massa van generieke developers bedoelt die eigenlijk alleen maar meer dertien-in-een-dozijn end-user meuk toevoegen aan de appstores waar we nu mee zitten, dan heb je gelijk, die hoeven niks te weten. Maar dat zijn dan ook toevallig de developers waar je niet echt een hoge standaard van engineering van hoeft te verwachten, of die je gaat selecteren als je een goede engineer in je softwarehuis gaat aannemen.

[Afvalzak]

Megamind schreef op vrijdag 31 juli 2015 @ 22:23:
[...]

Hij heeft het over een Informatica opleiding, niet TI

Zijn allemaal dingen die ik bij mijn Informatica opleiding in Breda gedaan heb hoor

[Verwijderd]

Waarom begin je niet met assembly. Ook ooit mee begonnen en ondanks je het later praktisch niet gaat gebruiken geeft het je wel een perspectief van hoe een von Neumann architectuur in elkaar zit. En hoe uberhaupt een processor werkt door werkelijk deze aan te spreken. Dan naar C dan naar C++ dan naar VM talen zoals C#/Java etc.

Als je begint met VM talen zul je nooit begrijpen hoe een processor uberhaupt werkt. Weet je uberhaupt wel hoe een bepaalde processor instructie werkt met betrekking tot optellen of bitshiften of wegschrijven van data e.d.

Al zou je van Assembly naar VM taal gaat. Het is interessant en je hebt een goede kijk van hoe zaken nou op de achtergrond werken.

Tegenwoordig heb je zelf een nieuwe low level taal genaamd "Rust" welke twee werelden wil samenvoegen. De voordelen van VMtaal zoals C# en Java en die op een low level taal toepassen(lang niet alles hoor).

Uiteindelijk is het toch je doel op school om de basis te begrijpen waaruit later iedereen zijn aftakking kan pakken en daarin doorgroeien. De basis is laag de basis technieken welke in elke taal terug komen. En talen zoals Java worden daarvoor gebruikt om het in de praktijk te brengen. Maar dat zou geen belemmering moeten geven om simpele overstap te maken naar C# en andere OOP VM talen.

[Croga]

johnkeates schreef op zaterdag 01 augustus 2015 @ 14:31:
Maar dan zal je toch ook wel moeten snappen dat er meer is dan alleen maar end-user software or managed talen die in een of andere runtime verdwijnen? En dat je met een probleem zit als niemand je runtime kan schrijven om dat die zelf niet in een managed taal geschreven wordt? Of dat je kernel echt niet in Java of C# geschreven wordt? Of dat je BIOS geen benul heeft van al die high-level taaltjes? En dat embedded systemen vaak de luxe van vrij geheugen en vrije cycles niet kent en daarmee alles wat 'hoger' dan C is niet eens mogelijk maakt?

Vandaar ook, keer op keer, mijn opmerking over 99% en stevige uitzonderingen voor iedereen die aan compilers, JavaVMs, BIOS en soortgelijk spul werkt.

Stel dat je de massa van generieke developers bedoelt die eigenlijk alleen maar meer dertien-in-een-dozijn end-user meuk toevoegen aan de appstores waar we nu mee zitten, dan heb je gelijk, die hoeven niks te weten. Maar dat zijn dan ook toevallig de developers waar je niet echt een hoge standaard van engineering van hoeft te verwachten, of die je gaat selecteren als je een goede engineer in je softwarehuis gaat aannemen.

Je noemt hier nu zwart en wit. De hele berg grijs die daar tussen zit, de 99% waar ik het over heb, is bezig met exact die software die onze huidige maatschappij draaiende houdt. De software die dijken, bruggen, tunnels aanstuurt is nagenoeg allemaal Java en heeft dus geen low-level kennis nodig aangezien die door de VM aangestuurd worden. De software die wij alleen dagelijks gebruiken om onze betaalopdrachten aan banken te geven is veelal C# (okay, ook veel Java ) en laat dat soort zaken dus door de compiler regelen. De SAPs, Exacts, Baans, Sharepoints, etc. van deze wereld hebben allemaal niets met dat soort zaken te maken.

Ja, er zijn mensen die wél álle bases van het programmeren moeten weten. Net zo goed als dat er mensen zijn die wel alle bases van de Wiskunde en Geneeskunde moeten weten. Maar net zo goed als dat je wiskunde niet begint met hoe de stelling van Pythagoras in elkaar zit, en je geneeskunde niet begint met hoe je kanker krijgt, moet je programmeren niet beginnen met de allermoeilijkste onderdelen. Begin nou gewoon eens met "Hello World". Begin nou eens met de gebruiker. En ga van daar uit verder werken naar het niveau wat nodig is. Als dan blijkt dat je wél compilers gaat bouwen of wél die 1KB aansturing van een robot-mug wilt programmeren dan kun je altijd nog kijken naar pointers, stacks, heaps, memory management, micro-optimalisatie en wat niet meer. Maar 99% doet dat niet. 99% programmeert die ING app, die Sharepoint rapportage, die afzuiginstallatie in de tunnel op de A67, die voorraad module of die PHP login library.

Verwijderd schreef op zaterdag 01 augustus 2015 @ 14:35:
Uiteindelijk is het toch je doel op school om de basis te begrijpen waaruit later iedereen zijn aftakking kan pakken en daarin doorgroeien. De basis is laag de basis technieken welke in elke taal terug komen.

Je cruciale denkfout zit hem hier. De basis is helemaal niet laag in de techniek. De basis is de gebruiker. Zolang je blijft redeneren vanuit de techniek zul je nooit een applicatie bouwen die zo zinvol mogelijk is voor de gebruiker. Door te beginnen bij de gebruiker kun je zelf bepalen hoe diep je de techniek in moet. Uit gaan van de techniek is nou juist de reden dat 80% van alle programmeer code nooit gebruikt wordt.

[ Voor 11% gewijzigd door Croga op 01-08-2015 14:49 ]

[johnkeates]

Croga schreef op zaterdag 01 augustus 2015 @ 14:47:
[...]
dingen
[...]

Ik ben toch blij dat ik je bredere post zo uitgelokt heb Want voor veel mensen is het niet duidelijk wat jij bedoelt. Iemand die low level geprogrammeerd heeft weet prima waar wat nodig is, wat uit een kleinere post niet heel makkelijk op te maken is. Ik denk dat BoringDay nu snapt wat je bedoelt.

Waar ik nog wel even op in wil gaan is de grijze massa / 95% bell curve / 'de meeste', hoewel je inderdaad vaak mensen tegen zal komen die op een hoger/abstracter niveau met software bezig zijn zoals met managed talen of geïnterpreteerde talen, zijn er echt veel meer mensen die bijvoorbeeld nog met hardcore C moeten werken dan je denkt. Zo zal je weinig microcontrollers tegen komen die voor massa productie geschikt zijn en met Java of C# gaan werken, puur en alleen al door de beperkte resources. PLC's kan je meestal ook wel vergeten, op z'n best kan je een bridge krijgen of een API, maar de PLC's zelf draaien geen CLR of JVM. Kernels zijn ook best wel belangrijk, en er zijn meer kernels en meer kernel onderzoeken dan je denkt. Wat banken en andere grote financiële instellingen betreft zal je ook nog steeds vrij veel koppelingen tussen nieuw en oud vinden waarbij oud soms zelfs nog op mainframes draait. Soms heb je geluk en is het iets als IBM waar IBM's JVM op draait, meestal niet. In de automotive industrie kan je Java en C# ook wel vergeten. Basebands? Die dingen waarvan er meer van zijn dan er mensen op de wereld zijn? Allemaal low-level firmware nodig.

Alles wat niet 'makkelijk' en 'zichtbaar' is draait vaker nog op C-niveau dan dat je er een kernel met software stack die een JVM of CLR heeft bij krijgt, om met een modern framework je software te ontwerpen. De laatste keer dat ik met infrastructuur bezig was (geen bruggen, maar wel in de buurt ;-) ) was het een mix van technologie. Ja, tussen de mensen die achter een monitor zitten te niksen en de 'hardware' zit wat lijm en GUI in een managed taaltje, maar daar achter zit gewoon wat low-level spul. Microcontrollers, RTOSsen, baseband transcievers. Daar ontkom je niet aan En daar is ook niks mis mee, zolang er maar genoeg developers zijn die het kunnen. En dat is een beetje het probleem van nu: net zoals je vroeger mensen had die ALGOL deden heb je nu mensen die C doen. Stel je voor dat we die over 10 jaar nodig hebben maar er alleen maar tieners zijn die C# kunnen? Lijkt me niet bepaald prettig.

Ja, van alle apps voor eindgebruikers zal je op z'n best iets als GLSL tegen komen qua "moeilijke" code die je zal schrijven. De rest is allemaal 'makkelijk' en 'modern'. Iedereen die van een HBO af komt rollen kan in principe wat Java/C#/Obj-C/Swift pakken en een appje bouwen bij z'n stagebedrijf waar ie vaak wel mag blijven hangen. En voor de meeste mensen is dat ook prima

[Megamind]

Afvalzak schreef op zaterdag 01 augustus 2015 @ 14:33:
[...]

Zijn allemaal dingen die ik bij mijn Informatica opleiding in Breda gedaan heb hoor

Hij heeft het over de HR Rotterdam, maar het programma zal niet zo heel veel meer verschillen landelijk. In de laatste 20 jaar zijn de IT opleidingen natuurlijk enorm verschoven, zo hebben ze volgens mij bij I zo goed als geen wiskunde meer (TI trouwens ook niet).

[Croga]

johnkeates schreef op zaterdag 01 augustus 2015 @ 15:15:
...
ook dingen
...

En toch zie je daar ook steeds meer C# en/of Java langs komen. Een vriend van me programmeert video cameras en die dingen hebben gewoon een JVM draaien. Ja, ze moeten ook hier en daar wat C schrijven om de poorten aan te kunnen sturen (aangezien ze nogsteeds niet snappen dat ze die 1.5 cent die ze besparen op wéér een nieuwe chip honderd keer kwijt zijn aan de nieuwe drivers die er geschreven moeten worden) maar het gros van de besturing draait gewoon in een VM.

Als ik kijk naar, bijvoorbeeld, de stormvloed kering bij Rotterdam dan is er inderdaad wat low-level spul nodig om de hardware te programmeren maar dat valt in het niet bij de hoeveelheid Java code die het uitlezen, analyseren en aansturen doet. Ik gok zomaar dat het 10% low-level, 10% UI, 80% intelligentie is.

Wellicht dat mijn 99% een hyperbool is en het dichter bij de 85% zal liggen. Punt verandert daar niet heel hard mee. Als je van iedere programmeur gaat vragen bij C te beginnen dan zal een groot deel afhaken simpelweg omdat ze, terecht, het nut er niet van inzien.

[johnkeates]

Croga schreef op zaterdag 01 augustus 2015 @ 16:06:
[...]


En toch zie je daar ook steeds meer C# en/of Java langs komen. Een vriend van me programmeert video cameras en die dingen hebben gewoon een JVM draaien. Ja, ze moeten ook hier en daar wat C schrijven om de poorten aan te kunnen sturen (aangezien ze nogsteeds niet snappen dat ze die 1.5 cent die ze besparen op wéér een nieuwe chip honderd keer kwijt zijn aan de nieuwe drivers die er geschreven moeten worden) maar het gros van de besturing draait gewoon in een VM.

Als ik kijk naar, bijvoorbeeld, de stormvloed kering bij Rotterdam dan is er inderdaad wat low-level spul nodig om de hardware te programmeren maar dat valt in het niet bij de hoeveelheid Java code die het uitlezen, analyseren en aansturen doet. Ik gok zomaar dat het 10% low-level, 10% UI, 80% intelligentie is.

Wellicht dat mijn 99% een hyperbool is en het dichter bij de 85% zal liggen. Punt verandert daar niet heel hard mee. Als je van iedere programmeur gaat vragen bij C te beginnen dan zal een groot deel afhaken simpelweg omdat ze, terecht, het nut er niet van inzien.

Ik ben het met je eens dat het in een complete stack net perse een groot deel uitmaakt van de custom software die je schrijft, maar je zal eigenlijk nooit een stack tegen komen waar je geen C, C++ of ASM tegen komt. Eigenlijk komt het een beetje neer op aan welke kant van het verhaal je zit; als integrator die wat laagjes lijmlogica nodig heeft is de kans erg klein dat je daadwerkelijk buiten managed taal hoeft te komen. Als entry-level engineer zal je er ook niet echt bij terecht komen. Dat maakt inderdaad een groot deel van de massa op. Ik zou zeggen, 50%, maar het kan natuurlijk meer zijn. 85% of 80% is dan weer te veel vanuit mijn perspectief, maar dat hangt denk ik van de projecten die je kiest af.

Neem bijvoorbeeld consumentenelectronica zoals een printer; daar zal voor een Windows systeem 80% C# in zitten, 10% C++, en 10% C, verspreid over de GUI, drivers, en printer firmware. Natuurlijk zijn er ook diverse smart-printers, die draaien soms VxWorks (helemaal C en ASM) of Linux (C, C++, wat scripting), maar hebben dan voor de low level hardware controle alsnog een microcontroller of CPLD/FPGA voor de afhandeling. Is goedkoper in massaproductie en betrouwbaarder en sneller dan een full stack OS met CLR/JVM er op En zo zit dat dus met nagenoeg alles wat je in een Media Markt of vergelijkbare winkel koopt.

Natuurlijk zijn er ook systemen waarbij alles 'lekker makkelijk' gebouwd is, zoals geldautomaten, parkeerautomaten enz. waar meestal gewoon Windows op draait met een slappe WinForms applicatie en seriele/USB randapparatuur voor.. alles

Voor veel mensen lijkt het er op dat alles er magisch gewoon is, zoals de CLR, JVM, Kernel, compilers enz. Maar die worden ook allemaal actief onderhouden, geforkt en gecommercialiseerd door diverse bedrijven met dedicated teams. Natuurlijk zal de verhouding iets van 1 op 5 zijn, waarbij je zowel qua kosten als qua personeel voor 1 programmeur die ook low-level skills heeft 5 kan krijgen die maar 1 of 2 dingen kunnen. (zoals bijv. C# met .NET en Java met Spring ofzo)

En om even on-topic in te haken op de HR-vraag: het is dus heel sterk afhankelijk van wat je wil doen en waar je aan het werk wil. Als je bij een of andere App-startup gaat werken maakt het geen zak uit wat je precies geleerd hebt op school, je past in het bedrijfje of je past niet. Als jij met Xamarin een App kan bouwen of het bedrijfje er al mee werkt, dan zit je goed. Stel dat je bij een groot softwarehuis gaat werken, dan is de kans groot dat je het eerste jaar vooral vuile klusjes mag opknappen en moet leren wat je precies moet weten en gaat doen, en is die hele opleiding met Xamarin vooral 'leuk en aardig' en niet heel relevant. Je moet snel een taal kunnen leren, een framework kunnen begrijpen, en de architectuur en patronen kunnen herkennen. Of dat dan in C++, C#, Obj-C, Java of LISP is maakt geen zak uit. Hetzelfde geldt voor tooling en OS. Je kan nu wel alles in Windows willen doen met Visual Studio ofzo, maar dat is niet waar de wereld op draait. Overal is een stuk gereedschap voor welke het beste werkt. Zodra je embedded dingen gaat maken, of voor non-Windows platforms kom je er heel snel achter dat je met een Microsoft-eilandje niet heel ver komt. Dan beperk je jezelf in waar je kan solliciteren en aan het werk kan. Natuurlijk is er (nu nog) genoeg Microsoft-werk te vinden, en zit er in alle bedrijven van groot tot klein genoeg gebakken lucht om zelfs als je (nog) niet precies weet wat je aan het doen bent een jaartje te kunnen leren en op niveau kan komen. Het enige wat je daar voor nodig hebt is ervaring met het leren van dingen en de theorie van patronen, algoritmes en architectuur snappen, goed kennen, en weten waar je meer kan vinden. Als je op school klaar bent betekent het niet dat je nooit meer wat gaat leren

[ Voor 21% gewijzigd door johnkeates op 01-08-2015 16:48 ]

[JJ93]

Megamind schreef op zaterdag 01 augustus 2015 @ 15:20:
[...]

Hij heeft het over de HR Rotterdam, maar het programma zal niet zo heel veel meer verschillen landelijk. In de laatste 20 jaar zijn de IT opleidingen natuurlijk enorm verschoven, zo hebben ze volgens mij bij I zo goed als geen wiskunde meer (TI trouwens ook niet).

De ICT opleidingen worden vanaf volgend schooljaar bij elke hogeschool samengevoegd onder de naam HBO-ICT. De opleidingsnaam Informatica wordt vervangen door Software Engineering.

Bij de HBO-ICT opleidingen krijg je een minimale hoeveelheid wiskunde. Software Engineering past dan ook beter als naam. Op de universiteit krijg je bij Computer Science echter nog steeds een grote hoeveelheid wiskunde.

Landelijk zullen er nog zeker verschillen zijn wat qua stof. Zo heb ik de basis van AspectJ, Haskell, Prolog geleerd, UNIX memory management algoritmes, sorteer algoritmes en Android ontwikkeling. Maar vrienden die Informatica studeren bij Windesheim of op de HAN hebben hier vrijwel niks mee gedaan.

Juist meer website ontwikkeling en andere minder technische dingen. Daarom heb ik juist gekozen voor Saxion (Enschede).

[EfBe]

OP/TS: gewoon de taal leren die door de opleiding wordt voorgeschreven. Daar heb je geen keuze in (het zou me verbazen) en je moet dat ook niet willen. Je hebt het wel over xamarin en C#, maar met java ben je hier beter af. Het is ook beter om zo veel mogelijk talen te leren met al hun concepten.

Croga schreef op zaterdag 01 augustus 2015 @ 13:10:
[...]

Precies. Al die dingen waar de gemiddelde programmeur, aan memory management kant, helemaal niet over na hoeft te denken.

Pointers zijn verleden tijd. Memory leaks komen alleen nog voor als gevolg van slecht gebruik van design patterns. (eigenlijk bestaan memory leaks ook niet meer; alleen nog het vasthouden van obsolete variabelen).

Onzin. Memory leaks bestaan nog steeds (event handlers in .NET bv) en memory management is nog altijd erg belangrijk, ook in GC talen. Sterker, door het maar lukraak alloceren van memory dmv het aanmaken van vele objects zijn programmas vaak zo traag. Nothing is free.

[Croga]

EfBe schreef op maandag 03 augustus 2015 @ 09:27:
Onzin. Memory leaks bestaan nog steeds (event handlers in .NET bv) en memory management is nog altijd erg belangrijk, ook in GC talen. Sterker, door het maar lukraak alloceren van memory dmv het aanmaken van vele objects zijn programmas vaak zo traag. Nothing is free.

Beiden hebben niets te maken met klassiek Memory Management of klassieke memory leaks.
Je hoeft helemaal geen C te kennen om te snappen dat als je maar variabelen/objecten aan blijft maken, je geheugen op een gegeven moment vol is. Dat heeft niets met memory management of memory leaks te maken, dat heeft te maken met netjes programmeren. Dat leer je in C# en Java net zo goed als in C.

Het grote verschil is dat je tegenwoordig helemaal niet meer hoeft te weten wélk stukje geheugen door welk object/variabele gebruikt wordt. Je hoeft je dus ook geen zorgen te maken over het vrijgeven van een exact stuk geheugen, je hoeft alleen maar te zorgen dat je object vernietigen, de rest gaat vanzelf. Je hoeft niet te weten op welke stack positie je specifieke waarde zich bevindt, ook dat wordt voor je geregeld. Je hoeft niet na te denken over hoeveel geheugen je voor een variabele of object moet reserveren, dat wordt voor je geregeld.

[igmar]

Croga schreef op zaterdag 01 augustus 2015 @ 14:15:
25 jaar programmeer ervaring, begonnen met Assembly, door naar zo'n beetje iedere taal die er in gebruik geweest is....

Ik heb me meer dan vaak genoeg druk gemaakt over het soort onzin wat je in C allemaal moet afdekken en houd me nu liever bezig met wat de gebruiker nodig heeft.

Daarvoor heb je tegenwoordig tooling (valgrind om er een te noemen). En bij goed geschreven code is het zelden een issue. In talen met smart pointers (c++, Java, C#) is het helemaal zelden een issue.

De wereld is verandert. Sommige programmeurs snappen dat niet. Dat zijn de programmeurs die nu overtollig zijn en klagen dat De Jeugd het allemaal niet begrijpt.

Dat geklaag is wel ten dele terecht. Er is meer op de wereld als een moderne PC met 4GB memory. Enige kennis van low-level zaken zoals pointers helpen de kwaliteit van opgeleverde code enorm. En ja, code in C++ en Java kan net zo goed memory leaks bevatten.

[EfBe]

Croga schreef op maandag 03 augustus 2015 @ 09:36:
[...]
Beiden hebben niets te maken met klassiek Memory Management of klassieke memory leaks.
Je hoeft helemaal geen C te kennen om te snappen dat als je maar variabelen/objecten aan blijft maken, je geheugen op een gegeven moment vol is. Dat heeft niets met memory management of memory leaks te maken, dat heeft te maken met netjes programmeren. Dat leer je in C# en Java net zo goed als in C.

Daar had ik het helemaal niet over. Ik had het over het feit dat objects in memory blijven ondanks dat ze out of scope zijn en dus de GC ze niet verwijdert en je dus over een leak kunt spreken (exact hetzelfde als memory alloceren en het niet vrij geven).

En ik had het over het feit dat objects alloceren je programma traag maakt als je dat meer doet dan nodig (en dat is al snel zo). Heeft niets met out of memory te maken, maar met het alloceren an sich.

Het grote verschil is dat je tegenwoordig helemaal niet meer hoeft te weten wélk stukje geheugen door welk object/variabele gebruikt wordt. Je hoeft je dus ook geen zorgen te maken over het vrijgeven van een exact stuk geheugen, je hoeft alleen maar te zorgen dat je object vernietigen, de rest gaat vanzelf. Je hoeft niet te weten op welke stack positie je specifieke waarde zich bevindt, ook dat wordt voor je geregeld. Je hoeft niet na te denken over hoeveel geheugen je voor een variabele of object moet reserveren, dat wordt voor je geregeld.

Dat doe je in C ook niet. Of alloceer jij je memory met hardcoded waarden en niet mbv de grootte van de types die in het gealloceerde stukje memory moeten staan? Variables op de stack kun je bij maar waarom zou je? Ik zou het moeten opzoeken, maar als ik me goed herinner is de ordering van variables op de stack in bv C tegenwoordig random.

[bomberboy]

EfBe schreef op dinsdag 04 augustus 2015 @ 09:28:
[...]

En ik had het over het feit dat objects alloceren je programma traag maakt als je dat meer doet dan nodig (en dat is al snel zo). Heeft niets met out of memory te maken, maar met het alloceren an sich.

Dat is dus ook zo'n misvatting die niet klopt. Belachelijk veel geheugen gebruiken gaat inderdaad een probleem zijn. En dus zoals je correct aangeeft referenties naar je objecten blijven vasthouden zodat ze niet vrijgegeven worden.

Echter is het alloceren van objecten niet noodzakelijk trager. Integendeel, in veel gevallen is het aanmaken van veel short-lived objecten net significant sneller vs het aanhouden van een kleinere set langlevende objecten in een managed taal.

igmar schreef op maandag 03 augustus 2015 @ 20:40:
Dat geklaag is wel ten dele terecht. Er is meer op de wereld als een moderne PC met 4GB memory. Enige kennis van low-level zaken zoals pointers helpen de kwaliteit van opgeleverde code enorm. En ja, code in C++ en Java kan net zo goed memory leaks bevatten.

Maar de vraag is hoeveel van die low-level zaken. Je moet ook niet alles van wiskunde kennen om in excel de interest van een lening uit te rekenen. Of weten hoe een motor werkt ommet een auto te rijden enz... Het is immers ook niet zo dat je plots iet met een elektrische wagen kan rijden als je eerder geleerd had dat met een wagen met benzinemotor geleerd had.


Uiteraard dat al die kennis kan helpen indien zodra je tegen een probleem aanloopt of van de platgetreden paden afgaat. De belangrijkste vraag is vooral of de volgorde waarin je dat allemaal leert dezelfde is als hoe de technologiestack in elkaar zit.

Persoonlijk ben ik er van overtuigd dat je leert programmeren op papier, en niet op een computer. Wanneer de computer er bij te pas komt is een hogere taal wat mij betreft een betere keuze en kan je nadien een drill down doen naar de nitty gritty details. Merk op dat dit ook de aanpak is voor bijna alles in het onderwijs. In biologie leer je ook niet eerst wat DNA is en wat cellen zijn om uiteindelijk tot een kikker te komen. Dat gebeurt daar ook omgekeerd.

In praktijk is het grootste probleem dat er nog beperkt goede tools zijn om op die manier software development aan te leren (en dat er een enorme digitale kloof kan zijn tussen studenten onderling, maar dat is een andere discussie)


Nu om op de oorspronkelijke vraag te antwoorden:
- Vraag het aan je school (maar ik gok van niet)

[Gomez12]

bomberboy schreef op dinsdag 04 augustus 2015 @ 10:58:
[...]
Dat is dus ook zo'n misvatting die niet klopt. Belachelijk veel geheugen gebruiken gaat inderdaad een probleem zijn. En dus zoals je correct aangeeft referenties naar je objecten blijven vasthouden zodat ze niet vrijgegeven worden.

Echter is het alloceren van objecten niet noodzakelijk trager. Integendeel, in veel gevallen is het aanmaken van veel short-lived objecten net significant sneller vs het aanhouden van een kleinere set langlevende objecten in een managed taal.

Heb je van dat laatste een concreet voorbeeld? Want ik kan me wel wat edge-cases bedenken waarvoor het zou gelden, maar eigenlijk geen "normaal" voorbeeld. En jij heb het over veel gevallen dus dan denk ik niet aan edge-cases

[bomberboy]

Een concreet voorbeeld waar ik vroeger zelf aan gewerkt heb was een SIP proxy & router. En bij uitbreiding heel veel scenario's met sterk event gebaseerde applicaties (denk bv bepaalde message queues).

Een mogelijke manier van werken is dat je objectpools gaat aanleggen om bepaalde objecten bij te houden in de veronderstelling dat de creatie van objecten lang duurt en een dure operatie is. Gaat perfect op bijvoorbeeld bij database connecties. Opzetten en afbreken van die database connectie duurt immers "verschrikkelijk" lang.

Dat betekent echter niet dat je dit altijd kan doortrekken. Voor short-lived objecten die eenvoudig zijn in aanmaak/afbraak is dat doorgaans geen goed idee. Het idee van zo'n pool (of bepaalde objecten lang in leven houden en hergebruiken in het algemeen) heeft wat betreft de garbage collection zijn eigen problemen.

Korte intro over bepaalde aspecten van een generational garbage collection (Java): http://www.oracle.com/web.../obe/java/gc01/index.html (deeltje: The Generational Garbage Collection Process)

Samegevat komt het er op neer dat het geheugen is onderverdeeld in verschillende blokken: eden, voor alle nieuwe objecten, survivor spaces en één of meerdere oudere generatie-blokken. Eden wordt heel vaak een eenvoudig ge-garbage collect en de oudere generaties iets minder. Indien een object lang genoeg blijft bestaan verhuist het naar de oudere generatie (in een naïeve implementatie een copy/move, uiteraard in praktijk veel efficiënter opgelost).
In het ideale geval, je object wordt aangemaakt, is niet meer nodig en wordt onmiddellijk gecollect. Dus weinig overhead.

Wanneer je objecten lang blijven bestaan worden deze telkens overlopen en opnieuw gechecked bij verschillende runs door de garbage collector (uiteraard zijn daar ook optimalisaties) en een neveneffect van lang levende objecten, en bv ook in zo'n pool strategie, is dat deze typisch meerdere referenties hebben en/of op meerdere plaatsen gereferenced worden. Dus het garbage collection algoritme heeft er ook meer werk aan om te beslissen of het object weg mag, ja of neen. Ze worden ook telkens weer gemarkeerd als te controleren iedere keer er een referentie wijzigt enz. Wat uiteindelijk dan allemaal betekent dat de GC-overhead net groter wordt. En die weegt dan al snel zwaarder door dan de overhead van het creëren/afbreken van de objecten zelf.

Een ander mogelijk neveneffect, is dat door langlevende objecten te gaan gebruiken het kans op een resource lek eigenlijk groter wordt omdat je een referentie van/naar dergelijk object net voorkomt dat de dependencies opgeruimd worden. Maar dat is afhankelijk van fouten, dus dat is niet helemaal correct om als argument te houden. Datzelfde probleem heb je ook met short-lived objecten, maar de impact is potentieel wel groter.

Betekent dit dat je in het wilde weg enorm veel nieuwe objecten moet instantiëren en voor het plezier enorme Lists moet repliceren in je code (en dus potentieel veel objecten creëren/afbreken). Uiteraard niet.

Maar heel vak neigt een aanpak om het actief te voorkomen van creëren van objecten naar premature optimization wat bijna altijd fout afloopt.

Is dat nu een edge case of iets veel voorkomend. Misschien wel, misschien niet. Maar alles wat event-based is (netwerk gerelateerde applicaties vallen daar heel vaak onder) zijn volgens mij toch vrij vaak voorkomend.

(/me heeft eens bijna een jaar van zijn leven aan garbage collection tuning gespendeerd, al is dat ondertussen ook wel bijna 10 jaar geleden)

[EfBe]

bomberboy schreef op dinsdag 04 augustus 2015 @ 10:58:
[...]
Dat is dus ook zo'n misvatting die niet klopt. Belachelijk veel geheugen gebruiken gaat inderdaad een probleem zijn. En dus zoals je correct aangeeft referenties naar je objecten blijven vasthouden zodat ze niet vrijgegeven worden.

Echter is het alloceren van objecten niet noodzakelijk trager. Integendeel, in veel gevallen is het aanmaken van veel short-lived objecten net significant sneller vs het aanhouden van een kleinere set langlevende objecten in een managed taal.

Het punt is niet dat het creeeren van objects traag is in vergelijking met bv C++, het punt is dat het creeeren van veel objects je applicatie traag maakt, en in managed code heb je veelal geen invloed op wanneer hoeveel objects gecreeerd worden en dat laatste is nu juist het probleem. Nu is de GC in de ene VM beter dan de andere, maar ook in bv hotspot zijn object allocaties niet gratis: memory compaction, memory moves, het is allemaal werk wat nodig is en hoe meer objects jij creeert, hoe eerder je daar tegenaan loopt (door fragmentatie van de heap)

Zie bv: http://sebastiansylvan.co...level-languages-are-slow/ en het oude maar zeker niet slechte: MSDN: Writing Faster Managed Code: Know What Things Cost

Het is helemaal geen opvatting die niet klopt, het klopt als een bus.

[ Voor 13% gewijzigd door EfBe op 05-08-2015 09:00 ]

[igmar]

bomberboy schreef op dinsdag 04 augustus 2015 @ 10:58:
Dat is dus ook zo'n misvatting die niet klopt. Belachelijk veel geheugen gebruiken gaat inderdaad een probleem zijn. En dus zoals je correct aangeeft referenties naar je objecten blijven vasthouden zodat ze niet vrijgegeven worden.

Echter is het alloceren van objecten niet noodzakelijk trager. Integendeel, in veel gevallen is het aanmaken van veel short-lived objecten net significant sneller vs het aanhouden van een kleinere set langlevende objecten in een managed taal.

In veel moderne talen zijn veel objecten immutable. String is er bijvoorbeeld 1 van : In bv bijna alle JVM talen is ie immutable. Immutable objecten maakt het in veel gevallen veel makkelijker : Makkelijker management, geen concurrency issues om maar wat zaken te noemen.

Maar de vraag is hoeveel van die low-level zaken. Je moet ook niet alles van wiskunde kennen om in excel de interest van een lening uit te rekenen. Of weten hoe een motor werkt ommet een auto te rijden enz... Het is immers ook niet zo dat je plots iet met een elektrische wagen kan rijden als je eerder geleerd had dat met een wagen met benzinemotor geleerd had.

Uiteraard dat al die kennis kan helpen indien zodra je tegen een probleem aanloopt of van de platgetreden paden afgaat. De belangrijkste vraag is vooral of de volgorde waarin je dat allemaal leert dezelfde is als hoe de technologiestack in elkaar zit.

De low-level zaken worden steeds minder gegeven in het onderwijs. Men heeft tegenwoordig steeds minder een idee wat er nu eigenlijk gebeurd, en ik weet niet of dat wel z'n goede zaak is. Leuke al die managed talen, todat je de embedded wereld induikt, waar het vaak niet zo makkelijk is. En low-level OS zaken gaan al helemaal niet in managed talen. Als je dan geen wet hebt van pointers en hoe je code schrijft die daarmee werkt heb je wel een behoorlijk probleem.

Persoonlijk ben ik er van overtuigd dat je leert programmeren op papier, en niet op een computer. Wanneer de computer er bij te pas komt is een hogere taal wat mij betreft een betere keuze en kan je nadien een drill down doen naar de nitty gritty details. Merk op dat dit ook de aanpak is voor bijna alles in het onderwijs. In biologie leer je ook niet eerst wat DNA is en wat cellen zijn om uiteindelijk tot een kikker te komen. Dat gebeurt daar ook omgekeerd.

In praktijk is het grootste probleem dat er nog beperkt goede tools zijn om op die manier software development aan te leren (en dat er een enorme digitale kloof kan zijn tussen studenten onderling, maar dat is een andere discussie)

Ik ben nog van de generatie die Motorola assembler en C kreeg. En eerlijk gezegd : Ik ben er blij mee. IK heb regelmatig "huidige generatie" informatica studenten moeten begeleiden, en op wat uitzonderingen na wat het nivo echt ver te zoeken.

Nu om op de oorspronkelijke vraag te antwoorden:
- Vraag het aan je school (maar ik gok van niet)

Precies

[Laurens-R]

Ontopic: Als je serieus Android developer wilt worden zou ik gewoon Java leren. Xamarin is een cross platform framework wat handig is als je cross platform apps in elkaar wilt draaien (zit overigens tegenwoordig in VS2015 gebakken ) Xamarin is mijn ogen een tool voor een business case, niet een doel op zich. En het is gewoon goed om te weten hoe Android in elkaar steekt als je doel is om een echte android dev pro te worden.

sub-topic: Ik zie regelmatig wat een gebrek aan kennis doet met de kwaliteit van code. En als we de lat steeds lager gaan leggen word dat probleem alleen maar groter. Ik verwacht niet van de ontwikkelaars die voor mij werken dat ze een memory manager in elkaar zetten, of dat ze lexer/parser bouwen, of dat ze hun eigen datastructures etc in elkaar draaien als daar een library voor is.

Wat ik wel verwacht is dat ze weten welke datastructure bij welk scenario hoort; dat ze niet een list gebruiken als een tree of dictionary beter is. En dat ik niet hoef uit te leggen dat het ook in moderne talen nodig is om af en toe een Dispose te doen van classes die native resources claimen (IO classes etc). Laatst nog 1 sec van een API request kunnen afschaven omdat iemand allerlei string operaties deed ipv een stringbuilder te gebruiken. De persoon in kwestie (van een outsourcing club in ander land) zei dat er geen verschil was tussen de twee; terwijl hij met meer kennis had kunnen weten dat normale operaties meer memory copies en allocations etc tot gevolg hebben omdat strings immutable zijn en een stringbuilder een groter blok geheugen aanvraagt waarin de class string operaties doet. Een goed voorbeeld van een high level beslissing die low-level gevolgen had.

De grap is; zonder een solide basis, snap je ook niet wat je higher level aan het doen bent. Dat leid tot slechte code, slechte onderhoudbaarheid, hogere kosten, trage buggy software, projecten die de bocht uit vliegen en ontevreden klanten. Ik zie het de laatste tijd steeds meer. Het feit dat je het in een hogere taal/framework doet, betekend niet dat je het niet kan verkl*ten. (Ik ben dan ook heel blij dat ik voor een bedrijf werk waar we wat dat betreft gewoon veel verwachten van een medewerker).

Ik verwacht niet dat mensen het wiel opnieuw gaan uitvinden; ik ben een groot fan van high level abstractie, frameworks, talen etc... wat ik wel verwacht van mensen dat ze snappen wat ze aan het doen zijn zodat ze kwalitatief goede software opleveren.

[ Voor 42% gewijzigd door Laurens-R op 05-08-2015 12:38 ]

[ChaosZ0ne]

Docent HR Informatica hier: In het eerste jaar ga je 1 project doen met Android en daar is het eigenlijk verplicht in het eerste jaar met Java aan de slag te gaan; behalve dat er zo nu en dan nog wat rare quirks zitten in Xamarin, sluit het ook niet aan op de rest van de ondersteunende lessen, die in Java zijn.

Tweede jaar ben je wat vrijer in je keuzevan taal en platform overigens, het eerste jaar willen we iedereen op een basisniveau krijgen (uiteraard met wel wat verschil in complexiteit voor de wat meer ervaren leerlingen).

EDIT: zoals eerder aangekaart is er maar 1 project waar je een app maakt; het laatste kwartaal. Verder ga je aan de slag met Python en java (en c# voor de liefhebbers)

[ Voor 13% gewijzigd door ChaosZ0ne op 05-08-2015 13:30 ]

[bomberboy]

EfBe schreef op woensdag 05 augustus 2015 @ 08:57:
[...]
Het punt is niet dat het creeeren van objects traag is in vergelijking met bv C++, het punt is dat het creeeren van veel objects je applicatie traag maakt, en in managed code heb je veelal geen invloed op wanneer hoeveel objects gecreeerd worden en dat laatste is nu juist het probleem. Nu is de GC in de ene VM beter dan de andere, maar ook in bv hotspot zijn object allocaties niet gratis: memory compaction, memory moves, het is allemaal werk wat nodig is en hoe meer objects jij creeert, hoe eerder je daar tegenaan loopt (door fragmentatie van de heap)

Zie bv: http://sebastiansylvan.co...level-languages-are-slow/ en het oude maar zeker niet slechte: MSDN: Writing Faster Managed Code: Know What Things Cost.

Ik beweer ook niet dat er gen kost aan het creëren van objecten is, maar de "oplossingen" die soms gebruikt worden om dat te omzeilen zijn vaak gewoon slechter dan ze wel creëren.

De indruk die die artikels deels lijken te wekken is dat high performance code in een managed taal niet kan/een slecht idee is ben ik het wel mee oneens. Er staan geen echte fouten in die artikels, maar 't is wel een beetje met een zekere bias geschreven. (Die ik zelf ongetwijfeld ook heb in de andere richting)

igmar schreef op woensdag 05 augustus 2015 @ 09:05:
[...]
De low-level zaken worden steeds minder gegeven in het onderwijs. Men heeft tegenwoordig steeds minder een idee wat er nu eigenlijk gebeurd, en ik weet niet of dat wel z'n goede zaak is. Leuke al die managed talen, todat je de embedded wereld induikt, waar het vaak niet zo makkelijk is. En low-level OS zaken gaan al helemaal niet in managed talen. Als je dan geen wet hebt van pointers en hoe je code schrijft die daarmee werkt heb je wel een behoorlijk probleem.

Maar het is ook net goed dat je niet hoeft te weten hoe het onderhuids allemaal werkt. Dat maakt het allemaal veel schaalbaarder en eenvoudiger.
Uiteraard heb je op een bepaald niveau die kennis nodig en is die tot op zekere hoogte ook een meerwaarde. Anderzijds ken ik ook niets nauwelijks iets van een boormachine, maar gaat het weten van hoe de motor die daarin zit werkt mij in het grootste deel van de gevallen niet helpen om sneller een gat in de muur te maken. Spreken we over een gespecialiseerd iets als gaten in beton van 50cm boren zal het wel wat relevanter zijn om te voorkomen dat de boel in de fik schiet.

Maar moet je daarom eerst weten hoe die elektromotor werkt? Volgens mij niet. Wil je je verder specialiseren, dan wel. Betekent dat ook dat je zomaar alle soorten gaten moet gaan boren, neen, uiteraard, je moet bewust zijn van je skillset en je grenzen kennen. (En dit is vaak een probleem)

igmar schreef op woensdag 05 augustus 2015 @ 09:05:
Ik ben nog van de generatie die Motorola assembler en C kreeg. En eerlijk gezegd : Ik ben er blij mee. IK heb regelmatig "huidige generatie" informatica studenten moeten begeleiden, en op wat uitzonderingen na wat het nivo echt ver te zoeken.

Idem hier, maar de vraag is waar dat slechte niveau dan aan ligt. (Heb ook 5 jaar studenten & thesissen begeleid). Een aantal mogelijkheden:

• het onderwijssysteem in het algemeen (denk ik niet).
• De intelligentie van de studenten zelf? (denk ik niet, mensen zijn plots niet dommer of slimmer geworden).
• De instroom van de studenten die aan de opleiding beginnen? Ik vermoed dat hier wel een groot verschil zit. Waar vroeger de studenten die aan een dergelijke opleiding gestart waren meestal top of class waren, is dit vandaag niet meer noodzakelijk het geval door de democratisering van het onderwijs.

Ik zie die verschuiving niet als slecht, maar "we" moeten er ons wel aan aanpassen.

Tot slot is het ook nog zo'n (relatief) jonge discipline dat alles verandert aan ongelooflijk hoge snelheden. De mens bouwt al duizenden jaren bruggen, gebouwen, wegen enz (en dat loopt ook vandaag soms nog pijnlijk fout af). Software is iets van de laatste 50 jaar. Een ingenieur in opleiding leert vandaag ook zelf niet bouwen.

Maar 'k begin wat te veel off-topic te gaan

[Schnupperpuppe]

bomberboy schreef op woensdag 05 augustus 2015 @ 14:08:
[...]

Tot slot is het ook nog zo'n (relatief) jonge discipline dat alles verandert aan ongelooflijk hoge snelheden.

Dat is maar hoe je het bekijkt. Ik heb 30 jaar geleden Informatica (HIO) gestudeerd. Dat was voornamelijk het opdoen van een fundamenteel begrip van wat informatica eigenlijk is. Low level, dus. Assembly/C, compilers bouwen, operating system bouwen. Dat soort zaken. Geen nadruk op talen of tools, maar op principes. Daarnaast ook erg veel wiskunde.
De basis-principes die ik destijds geleerd heb, zijn heden ten dage nog net zo geldig als toen.
Ik begrijp uit deze draad dat de IT-opleidingen van tegenwoordig weinig waarde meer hechten aan deze low level basis-principes. Ik denk dat dat jammer is.

Wat mij betreft is er in 30 jaar verrekte weinig veranderd. Er is links en rechts wel wat geëvolueerd, maar de basis-principes zijn onveranderd.

[igmar]

bomberboy schreef op woensdag 05 augustus 2015 @ 14:08:
Maar het is ook net goed dat je niet hoeft te weten hoe het onderhuids allemaal werkt. Dat maakt het allemaal veel schaalbaarder en eenvoudiger.
Uiteraard heb je op een bepaald niveau die kennis nodig en is die tot op zekere hoogte ook een meerwaarde. Anderzijds ken ik ook niets nauwelijks iets van een boormachine, maar gaat het weten van hoe de motor die daarin zit werkt mij in het grootste deel van de gevallen niet helpen om sneller een gat in de muur te maken. Spreken we over een gespecialiseerd iets als gaten in beton van 50cm boren zal het wel wat relevanter zijn om te voorkomen dat de boel in de fik schiet.

Maar moet je daarom eerst weten hoe die elektromotor werkt? Volgens mij niet. Wil je je verder specialiseren, dan wel. Betekent dat ook dat je zomaar alle soorten gaten moet gaan boren, neen, uiteraard, je moet bewust zijn van je skillset en je grenzen kennen. (En dit is vaak een probleem)

Als je met je te kleine boormachine in dik gewapend beton gaat boren gaat er iets kapot. Als je kennis had gehad van die boormachine was dat je niet gebeurd.
Niet weten hoe het werkt maakt het alles behalve schaalbaar en eenvoudig. De bovenste laag misschien, maar niet de lagen eronder die er ook zijn.

Idem hier, maar de vraag is waar dat slechte niveau dan aan ligt. (Heb ook 5 jaar studenten & thesissen begeleid). Een aantal mogelijkheden:

• het onderwijssysteem in het algemeen (denk ik niet).
• De intelligentie van de studenten zelf? (denk ik niet, mensen zijn plots niet dommer of slimmer geworden).
• De instroom van de studenten die aan de opleiding beginnen? Ik vermoed dat hier wel een groot verschil zit. Waar vroeger de studenten die aan een dergelijke opleiding gestart waren meestal top of class waren, is dit vandaag niet meer noodzakelijk het geval door de democratisering van het onderwijs.

Het onderwijssysteem is een hele belangrijke factor. Er gaan steeds meer stemmen op om weer terug te gaan naar het systeem van de jaren 70, en met een reden. Het nivo is in de laatste jaren sterk gedaald, je moet steeds minder kunnen om hetzelfde diploma te behalen.

Ook internationaal gezien doet NL het steeds minder goed. Op zich ook wel logisch : Het is tegenwoordig gericht op uitstromen (== geld) en minder op kennis.

Ik zie die verschuiving niet als slecht, maar "we" moeten er ons wel aan aanpassen.

Tot slot is het ook nog zo'n (relatief) jonge discipline dat alles verandert aan ongelooflijk hoge snelheden. De mens bouwt al duizenden jaren bruggen, gebouwen, wegen enz (en dat loopt ook vandaag soms nog pijnlijk fout af). Software is iets van de laatste 50 jaar. Een ingenieur in opleiding leert vandaag ook zelf niet bouwen.

Ik zie die verschuiving wel als slecht. Ik heb 4de jaars HTS informatica studenten gezien die amper wisten wat een IP adres was. Kom op, dat hoor je in jaar 1 te leren, het is de fundering van het internet.

[igmar]

Schnupperpuppe schreef op woensdag 05 augustus 2015 @ 14:25:
De basis-principes die ik destijds geleerd heb, zijn heden ten dage nog net zo geldig als toen.
Ik begrijp uit deze draad dat de IT-opleidingen van tegenwoordig weinig waarde meer hechten aan deze low level basis-principes. Ik denk dat dat jammer is.

Wat mij betreft is er in 30 jaar verrekte weinig veranderd. Er is links en rechts wel wat geëvolueerd, maar de basis-principes zijn onveranderd.

Met een groot verschil met vroeger : De basisprincipes leren ze steeds minder.

[bomberboy]

igmar schreef op woensdag 05 augustus 2015 @ 15:25:
[...]
Met een groot verschil met vroeger : De basisprincipes leren ze steeds minder.

Vroeger waren er ook een zeer beperkt aantal "Computer Science" opleidingen waarin alles aan bod kwam. Typisch de algemene versies afgeleid uit de wiskunde opleidingen, universitair niveau enz.

Vandaag zijn er tientallen zoniet honderden IT-opleidingen beschikbaar van verschillende niveaus. Dus ook bewust dat er daar verschillen in niveau zitten

ivm je opmerking tovh boormachine: klopt volledig, maar dat is waar ik op doelde met je bewust zijn van je eigen skillset en mogelijkheden. Je moet kunnen weten dat ik met mijn accu-boormachine daar niet ga in slagen. Ik hoef de exacte details waarom en hoe niet te weten.

Uiteraard denkt iedereen met een diploma vodje initieel alles te weten en te kunnen tot je een paar keer tegen de muur knalt. Anderzijds zijn de verwachtingen van anderen ook vaak van die aard wat leidt tot deze negatieve percepties (jammer genoeg)

Overigens kan ik niet oordelen over de Nederlandse opleidingen, ben zelf Belg en vind dat het hier wel nog behoorlijk meevalt (als je uitgaat van de juiste verwachtingen met het corresponderende diploma). Dus misschien zit daar ook een verschil.

[MSalters]

Croga schreef op zaterdag 01 augustus 2015 @ 16:06:
[...]
Als ik kijk naar, bijvoorbeeld, de stormvloed kering bij Rotterdam dan is er inderdaad wat low-level spul nodig om de hardware te programmeren maar dat valt in het niet bij de hoeveelheid Java code die het uitlezen, analyseren en aansturen doet. Ik gok zomaar dat het 10% low-level, 10% UI, 80% intelligentie is.

Dat is de Maeslantkering, en die software is door mijn collega's bij CMG Mission Critical Systems geschreven. 0% Java, om de hele simpele reden dat fouten kunnen leiden tot duizenden doden. Java mág niet eens gebruikt worden in dergelijke systemen, lees de licentie maar.

De daadwerkelijke code was vziw 30% low-level, 70% intelligentie, 0% UI. Zelfde reden overigens: users zijn te foutgevoelig.

[Lethalis]

Wat je ook doet, sta open voor andere technieken en talen.

Java is nog steeds heel groot qua marktaandeel. Om die reden alleen al is het niet handig om het te negeren. Zelf ben ik al ruim 10 jaar .NET ontwikkelaar, maar ben in mijn vrije tijd vooral met Java bezig. Enerzijds omdat ik voor mijn hobbyprojecten Linux en OS X gebruik (en Java inclusief tools volwassener is op die platformen), anderzijds omdat ik daardoor zo naderhand op 2 keer zoveel vacatures kan reageren als het nodig is

Mijn kennis van Spring MVC is inmiddels dermate dat ik dat ook wel aandurf namelijk.

[ Voor 14% gewijzigd door Lethalis op 06-08-2015 13:55 ]

[Janoz]

MSalters schreef op woensdag 05 augustus 2015 @ 15:53:
[...]

Dat is de Maeslantkering, en die software is door mijn collega's bij CMG Mission Critical Systems geschreven. 0% Java, om de hele simpele reden dat fouten kunnen leiden tot duizenden doden. Java mág niet eens gebruikt worden in dergelijke systemen, lees de licentie maar.

De daadwerkelijke code was vziw 30% low-level, 70% intelligentie, 0% UI. Zelfde reden overigens: users zijn te foutgevoelig.

CMG? Dan moet dat voor 2002 gebeurt zijn. Toen zag het software landschap er nog heel anders uit en kan ik me voorstellen dat Java nog niet volwassen genoeg geacht werd.

[EfBe]

MSalters schreef op woensdag 05 augustus 2015 @ 15:53:
[...]

Dat is de Maeslantkering, en die software is door mijn collega's bij CMG Mission Critical Systems geschreven. 0% Java, om de hele simpele reden dat fouten kunnen leiden tot duizenden doden. Java mág niet eens gebruikt worden in dergelijke systemen, lees de licentie maar.

De daadwerkelijke code was vziw 30% low-level, 70% intelligentie, 0% UI. Zelfde reden overigens: users zijn te foutgevoelig.

Nou, ik werkte toen bij CMG, en we praten over 1996-1997 als ik het goed heb, dus 'Java' was toen ook nog niet echt ingeburgerd als een algemene taal, laat staan voor dit soort zaken. Dat toen niet voor een managed taal is gekozen is begrijpelijk: die waren niet echt algemeen in gebruik.

Overigens ben ik van mening dat fouten voorkomen niets te maken heeft met de keuze van de taal maar alles met het opvolgen van strikte procedures. Daarom kan een taal als C nog steeds goed gebruikt worden in bv MRI scanners ookal is C niet echt ongevoelig voor fouten (en de optimizers ook niet)

[ Voor 4% gewijzigd door EfBe op 07-08-2015 09:01 ]

[MSalters]

Java mag dan ingeburgered zijn, de licentie verbiedt nog steeds safety-critical toepassingen:

[Java] is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury

.

[bomberboy]

Ik ben geen jurist, maar ik lees dat niet als een verbod maar als "wij bieden geen enkele garantie voor het gebruik van de software in dergelijke toepassingen, doe je het toch, dan is dat je eigen verantwoordelijkheid en kan je eventuele problemen niet op ons verhalen"

En gelijkaardige statements vind je bij bijna alle software producten. Die waar dergelijke disclaimers niet in opgenomen zijn hebben zich door de verkeerde jurist laten bijstaan. (Of verkopen iedere licentie voor een paar miljard per stuk)

[MSalters]

De licentietekst zelf is geen verbod. Als ontwikkelaar van safety-critical toepassingen ben je echter verantwoordelijk voor de selectie van geschikte componenten. Als een leverancier ze actief ongeschikt verklaart, dan moet je ze zelf valideren. Ik geef het je te doen, heel Java valideren.

En nee, serieuze software die geschikt is voor safety-critical systemen kost geen miljarden. Soms kost het zelfs minder dan een miljoen per licentie. Zou wat worden, als de ABS-software van je auto een paar miljard per wiel zou kosten.

[farlane]

MSalters schreef op woensdag 05 augustus 2015 @ 15:53:
[...]

Dat is de Maeslantkering, en die software is door mijn collega's bij CMG Mission Critical Systems geschreven. 0% Java, om de hele simpele reden dat fouten kunnen leiden tot duizenden doden. Java mág niet eens gebruikt worden in dergelijke systemen, lees de licentie maar.

De daadwerkelijke code was vziw 30% low-level, 70% intelligentie, 0% UI. Zelfde reden overigens: users zijn te foutgevoelig.

Vaak wordt dit soort systemen met PLC's aangestuurd. Ben nu wel benieuwd of dat hier ook het geval is.

[MSalters]

Low-level ongetwijfeld, het systeem dat de beslissingen neemt niet.

[Spacejockey]

Lethalis schreef op donderdag 06 augustus 2015 @ 13:53:
Wat je ook doet, sta open voor andere technieken en talen.

Java is nog steeds heel groot qua marktaandeel. Om die reden alleen al is het niet handig om het te negeren. Zelf ben ik al ruim 10 jaar .NET ontwikkelaar, maar ben in mijn vrije tijd vooral met Java bezig. Enerzijds omdat ik voor mijn hobbyprojecten Linux en OS X gebruik (en Java inclusief tools volwassener is op die platformen), anderzijds omdat ik daardoor zo naderhand op 2 keer zoveel vacatures kan reageren als het nodig is

Mijn kennis van Spring MVC is inmiddels dermate dat ik dat ook wel aandurf namelijk.

Is het verschil tussen .NET en Java inderdaad zo groot? Als ik op indeed vergelijk is het verschil tussen c# en java ongeveer 600 vacatures, maar dan mis je nog een hoop advertenties waarin alleen .NET wordt genoemd (zoeken op .NET werkt niet omdat dat wordt geïnterpreteerd als 'net' en irrelevante hits oplevert). Ik zit namelijk in dubio of het handiger is om verder te specialiseren in .NET of over te stappen op Java, wat betreft toekomstperspectief.

Edit: Ik begreep je verkeerd, je zei niet dat Java 2x zoveel vacatures heeft als .NET. Als senior .NET ontwikkelaar ben ik alsnog wel benieuwd naar jouw mening wat betreft de toekomstperspectieven voor .NET t.o.v
Java.

[ Voor 8% gewijzigd door Spacejockey op 22-08-2015 18:11 ]

[RagingPenguin]

Ik heb afgelopen jaar het eerste jaar informatica gedaan op het HR en de opbouw van het vak development is zo:
periode 1: html/javascript, project is website bouwen met html en javascript.
periode 2: theorie over OO, pratische opdracht is gamedevelopment met een Mono engine, project is gamedevelopment met Mono(engine naar keuze)
periode 3: theorie over overerven, pratische opdracht is een VM(wees niet bang, je hoeft niet iets te maken als virtual box om te slagen ) maken met C#(deze keer de MS variant), project is een applicatie maken voor het analyseren van sociaal-media. je mag zelf kiezen tussen C#, Java en C++.
periode 4: meer theorie over OO, overerven ed, pratische opdracht is een Andriod applicatie(native, alleen java en xml dus) maken en project is ook een native Andriod applicatie.

Zowel Java als C# komen aan bod en voor het halen van het vak development is je kennis en inzicht die je kan toepassen op iedere taal belangrijker als je taal-specefieke kennis. Code-kloppen word er niet echt gegeven.

Edit:

pionters en memory-leaks worden behandeld als concept wat je moet weten, maar waar je verder niets mee hoeft. Van de compiler moet je de typechecker en interpenter wel helemaal beheersen, de rest word alleen als concept behandeld. Assembly en C zijn echte TI dingen, geen informatica. De mensen die hier roepen dat 'alle programmeurs alle low-level zaken moet beheersen' snappen denk ik helemaal niet dat de informatica-sector meer is als alleen low-level.

[ Voor 18% gewijzigd door RagingPenguin op 22-08-2015 18:00 ]

[Lethalis]

Spacejockey schreef op zaterdag 22 augustus 2015 @ 16:54:
[...]
Is het verschil tussen .NET en Java inderdaad zo groot? Als ik op indeed vergelijk is het verschil tussen c# en java ongeveer 600 vacatures, maar dan mis je nog een hoop advertenties waarin alleen .NET wordt genoemd (zoeken op .NET werkt niet omdat dat wordt geïnterpreteerd als 'net' en irrelevante hits oplevert). Ik zit namelijk in dubio of het handiger is om verder te specialiseren in .NET of over te stappen op Java, wat betreft toekomstperspectief.

Edit: Ik begreep je verkeerd, je zei niet dat Java 2x zoveel vacatures heeft als .NET. Als senior .NET ontwikkelaar ben ik alsnog wel benieuwd naar jouw mening wat betreft de toekomstperspectieven voor .NET t.o.v
Java.

Ik bedoelde dus inderdaad dat zowel .NET als Java even veel vacatures hebben. En dat je door beide te kunnen op 2 keer zoveel vacatures kunt reageren.

Het toekomstperspectief is heel moeilijk te voorspellen. Persoonlijk begin ik het gevoel te krijgen dat Java blijft groeien en dat mensen steeds negatiever over Microsoft denken, met name omdat:
- Microsoft het ene framework na het andere introduceert, en het vervolgens verwaarloost. Java maakt minder snelle ontwikkelingen door, maar is daardoor wel stabieler en voorspelbaarder. Hibernate / JPA is bijvoorbeeld een veel voorspelbaarder framework dan het Entity Framework, dat met EF7 gewoon een complete rewrite is die geen EDMX bestanden meer ondersteunt Misschien is EF7 wel heel gaaf, maar ja, is het verstandig het te gebruiken? Wat gebeurt er als EF8 komt? Om nog maar even te zwijgen over het Silverlight en WPF debacle.
- Open source cross platform ontwikkeling wordt steeds populairder. Microsoft speelt met .NET core en ASP.NET 5 hierop in, maar het is de vraag of ze op tijd zijn hiermee.
- MacBook Pro's zijn overal. Ook bij de gemiddelde Microsoft conference stikt het ervan en iedereen wil met OS X ontwikkelen ipv Windows. Het is bizar dat zelfs de Microsoft devs hun werk op Windows VM's presenteren die op OS X draaien. Neem Python, Go of Java en het kan gewoon. Visual Studio Code is niet voor niets in het leven geroepen.
- Windows hosting is verschrikkelijk duur vergeleken met Linux hosting.

Maar goed, Microsoft reageert er wel op. Misschien is het open sourcen van .NET, Visual Studio Code en ASP.NET 5 wel precies wat ze nodig hebben om weer aan populariteit te winnen. En misschien lukt dit ook. De tijd zal het leren.

EF7 ondersteunt ook out of the box Postgres straks

De vraag is ook wat voor programmeur jij bent. Wil je altijd met de nieuwste dingen bezig zijn? (Microsoft .NET) Of wil je graag stabiele en grote systemen opzetten en onderhouden? (Java)

Ik weet het zelf ook nog niet Wel vind ik het fijn dat Java zo voorspelbaar is. Je wil in principe iets moois bouwen dat jarenlang meegaat, en niet elke keer het gevoel hebben dat je vastzit op een oud framework omdat de leverancier toevallig heeft besloten dat er een nieuw framework komt dat het oude vervangt (en dat dan ook meteen in verval geraakt). En vervolgens dagen en weken bezig zijn om de boel te upgraden.

Dat is zo zonde van de energie.

[Spacejockey]

Lethalis schreef op zaterdag 22 augustus 2015 @ 21:29:
[...]

Bedankt voor de uitgebreide reactie. Toch een beetje jammer om te horen dat zelfs een zeer ervaren .NET ontwikkelaar niet voor de volle honderd procent overtuigd is over de toekomst van .NET (dat idee kreeg ik in ieder geval een beetje, ik wil je geen woorden in de mond leggen). Ik denk namelijk dat er weinig Java ontwikkelaars zijn die ook zo over hun platform denken. Ik werk graag met de .NET stack, maar soms knaagt het een beetje in mijn achterhoofd of ik die tijd niet nuttiger kan besteden door de Java stack te leren en dat is jammer.

[Lethalis]

Spacejockey schreef op zondag 23 augustus 2015 @ 06:49:
[...]
Bedankt voor de uitgebreide reactie. Toch een beetje jammer om te horen dat zelfs een zeer ervaren .NET ontwikkelaar niet voor de volle honderd procent overtuigd is over de toekomst van .NET (dat idee kreeg ik in ieder geval een beetje, ik wil je geen woorden in de mond leggen). Ik denk namelijk dat er weinig Java ontwikkelaars zijn die ook zo over hun platform denken. Ik werk graag met de .NET stack, maar soms knaagt het een beetje in mijn achterhoofd of ik die tijd niet nuttiger kan besteden door de Java stack te leren en dat is jammer.

Het probleem met ervaren zijn, is dat je ontwikkelingen op iets grotere schaal gaat zien. En ik kan je nu alvast vertellen, er is niet zoiets als "100% overtuigd zijn van de toekomst" van een bepaalde techniek of platform. Dat heeft geen zin, omdat alles verandert.

De vraag is dus ook een beetje waar jouw focus ligt. Ben je een web / backend developer? Bouw je graag apps? Of ben je bijvoorbeeld juist met embedded bezig? (dan doe je nu nog steeds C/C++)

Het is niet ondenkbaar dat zowel .NET als Java uit de mode raken voor jouw tak van sport

Wat is eigenlijk jouw eigen beweegreden om naar Java te kijken?

Mijn eigen frustratie met .NET zit overigens ook bij de andere .NET programmeurs. Dit zijn veelal ex Visual Basic prutsers Terwijl ik zelf uit de C++ hoek kom en mezelf ook verdiep in allerlei zaken zoals OO design patterns. Ik probeer in mijn vak te groeien. En naar mijn idee - wederom een veronderstelling - zijn Java developers daar meer mee bezig, omdat het geen ex VB-ers zijn.

Ik kom in mijn werk zoveel shit code tegen dat het gewoon niet meer leuk is.. "als het maar werkt" is het motto. En ik wil liever iets bouwen dat degelijk in elkaar zit. Ik wil in een team werken met mensen die ook bezig zijn zichzelf te verbeteren en niet schrikken van zaken als dependency injection, Gang of Four design patterns, aspect oriented programming, agile practices, test driven development enzovoorts.

En dan zie ik een framework als Spring MVC en daar zit het allemaal al in. Het faciliteert die manier van werken. Dat geeft mij het idee dat gebruikers van dat framework ook eerder op die manier zullen werken. Terwijl Microsoft nog steeds meer zo'n quick and dirty appeal heeft.

[Spacejockey]

Lethalis schreef op zondag 23 augustus 2015 @ 08:35:
[...]

Wat is eigenlijk jouw eigen beweegreden om naar Java te kijken?

De werkgevers die mij aantrekken lijken vooral Java te verkiezen boven .NET, zoals TNO of NLR. Niet dat ik daar per direct wil gaan solliciteren, maar als je ooit buiten de enterprise-achtige bedrijven wil gaan werken heb je met Java volgens mij wat meer flexibiliteit en dan is het fijn om die opties open te houden. Wellicht dat dat ook verband houdt met jouw ervaringen met (sommige) andere .NET programmeurs. Kijk je bijvoorbeeld naar Amerikaanse tech giganten zie je ook bijna geen enkele die .NET gebruikt, het is Java dat de klok slaat. Dan praat je toch over het summum van de software engineering wereld.

Daarnaast is er het feit dat Java simpelweg harder lijkt te groeien dan .NET, dus zoals jij in een eerdere post al zei kun je het eigenlijk niet negeren.

[ Voor 14% gewijzigd door Spacejockey op 24-08-2015 09:07 ]

[Croga]

Spacejockey schreef op zondag 23 augustus 2015 @ 06:49:maar soms knaagt het een beetje in mijn achterhoofd of ik die tijd niet nuttiger kan besteden door de Java stack te leren en dat is jammer.

Realiseer je goed dat de bedrijven waar je het liefst wilt werken steeds meer uit gaan van "Don't hire for skill, hire for motivation. Skill can be taught, motivation cannot."

Als ik teamleden moet recruteren voor een Java dev team en ik heb de keuze tussen een superenthousiaste .NETter of een ingekakte, extreem ervaren Javaan dan kies ik die eerste. Die twee weken die jij nodig hebt om te leren welke libraries je graag wilt hebben zijn binnen 2 maanden terug verdient in de enorme productiviteits boost die motivatie geeft. En let's face it; algorithme is algorithme, of het nu in .NET is of in Java.

[Spacejockey]

Croga schreef op maandag 24 augustus 2015 @ 09:06:
[...]

Realiseer je goed dat de bedrijven waar je het liefst wilt werken steeds meer uit gaan van "Don't hire for skill, hire for motivation. Skill can be taught, motivation cannot."

Als ik teamleden moet recruteren voor een Java dev team en ik heb de keuze tussen een superenthousiaste .NETter of een ingekakte, extreem ervaren Javaan dan kies ik die eerste. Die twee weken die jij nodig hebt om te leren welke libraries je graag wilt hebben zijn binnen 2 maanden terug verdient in de enorme productiviteits boost die motivatie geeft. En let's face it; algorithme is algorithme, of het nu in .NET is of in Java.

Dat is zeker waar, maar voor elke vacature die ik voorbij zie komen waarin skills op de eerste plaats komen zie ik er ook tien die twee jaar met dit of dat framework eisen, ook bij werkgevers die mij leuk lijken. Ik weet niet of Nederlandse werkgevers zo vooruitstrevend zijn op dat gebied.

[ Voor 3% gewijzigd door Spacejockey op 24-08-2015 09:13 ]

[Lethalis]

Croga schreef op maandag 24 augustus 2015 @ 09:06:
[...]
Als ik teamleden moet recruteren voor een Java dev team en ik heb de keuze tussen een superenthousiaste .NETter of een ingekakte, extreem ervaren Javaan dan kies ik die eerste. Die twee weken die jij nodig hebt om te leren welke libraries je graag wilt hebben zijn binnen 2 maanden terug verdient in de enorme productiviteits boost die motivatie geeft. En let's face it; algorithme is algorithme, of het nu in .NET is of in Java.

Ik ben in mijn eigen tijd bezig het Spring framework te leren (overdag ben ik gewoon .NET developer). Mijn ervaring is wel dat die 2 weken erg optimistisch zijn Nu komt er bij het ontwikkelen met Java ook veel meer kijken dan dat. Zo heeft het even geduurd voordat ik:
- Handig werd in het gebruik van IntelliJ IDEA en zijn configuratie
- Goed begreep hoe Maven werkt
- Grip kreeg op het gebruik van verschillende web containers (Jetty, TomCat, GlassFish) en bijvoorbeeld dat TomCat niet aan de volledige spec voldoet en dus extra dependencies nodig heeft.
- Begreep hoe de configuratie van Spring MVC van begin tot einde aan elkaar hangt van blokken die met dependency injection aan elkaar gekoppeld zijn. En als je dat eenmaal begrijpt, je eenvoudig van XML configuratie kunt overstappen op code based configuratie (wat ik dus ook gedaan heb, in mijn hobby projecten komt geen XML meer voor)
- Begreep wat de best practices zijn omtrend het gebruik van Hibernate / JPA in een Spring MVC project. Dus ik heb nu connection pooling aan de praat, implicit transaction management, enzovoorts.
- Spring Security precies laat doen wat ik wil

Nou ja, you get the picture

Ik vind het best veel om te behappen, maar ik wil er dan ook goed in zijn.

[Croga]

Lethalis schreef op maandag 24 augustus 2015 @ 09:24:
Ik vind het best veel om te behappen, maar ik wil er dan ook goed in zijn.

Maar het zijn allemaal "beter worden" punten. Zaken die je niet persé nodig hebt om aan de slag te kunnen.
Realiseer je daarnaast dat er in mijn wereld niet met singletons gewerkt wordt (in personen ), iedereen is lid van een team. En in dat team zitten altijd wel mensen die dit wél onder de knie hebben en waar je dus van kan leren (pair-programming FTW!)

Spacejockey schreef op maandag 24 augustus 2015 @ 09:12:
Dat is zeker waar, maar voor elke vacature die ik voorbij zie komen waarin skills op de eerste plaats komen zie ik er ook tien die twee jaar met dit of dat framework eisen, ook bij werkgevers die mij leuk lijken. Ik weet niet of Nederlandse werkgevers zo vooruitstrevend zijn op dat gebied.

Gelukkig zijn er steeds meer Nederlandse werkgevers wél zo vooruitstrevend

[Lethalis]

Croga schreef op maandag 24 augustus 2015 @ 09:35:
[...]

Maar het zijn allemaal "beter worden" punten. Zaken die je niet persé nodig hebt om aan de slag te kunnen.
Realiseer je daarnaast dat er in mijn wereld niet met singletons gewerkt wordt (in personen ), iedereen is lid van een team. En in dat team zitten altijd wel mensen die dit wél onder de knie hebben en waar je dus van kan leren (pair-programming FTW!)

Maar hoe zit dat dan met iemand die van .NET naar Java overstapt?

Ik werk al sinds 2003 fulltime als .NET ontwikkelaar met bijbehorend salaris, dus dan kom je wel anders binnen op een Java baan (als je al binnenkomt).

[Croga]

Lethalis schreef op maandag 24 augustus 2015 @ 09:52:Maar hoe zit dat dan met iemand die van .NET naar Java overstapt?

Ik werk al sinds 2003 fulltime als .NET ontwikkelaar met bijbehorend salaris, dus dan kom je wel anders binnen op een Java baan (als je al binnenkomt).

Waarom zou je dan anders binnen komen op een Java baan? Is de kennis van verschillende libraries zoveel belangrijker dan de ervaring in algorithmen of OO-denken?

Als we naar het Agile Manifesto kijken dan zien we op de eerste regel "Individuals and Interactions over Processes and Tools". Een programmeertaal en alles wat daar specifiek aan is, is slechts tooling. Daarmee een heel stuk minder belangrijk dan de programmeer-kennis en de instelling die de programmeur met zich mee brengt. Iedereen kan binnen relatief korte tijd zich een tool eigen maken, maar de kennis en het inzicht wat nodig is om goed te programmeren is veel lastiger.

Je hebt gelijk als je stelt dat er nog heel veel werkgevers zijn die dit niet snappen. Maar hoe volwassener de organisaties worden, hoe meer je zult zien dat je intrinsieke persoonlijke eigenschappen belangrijker worden dan de truukjes die je kent.

[Hydra]

Croga schreef op maandag 24 augustus 2015 @ 09:06:
Als ik teamleden moet recruteren voor een Java dev team en ik heb de keuze tussen een superenthousiaste .NETter of een ingekakte, extreem ervaren Javaan dan kies ik die eerste.

Lekker makkelijk. Als je in de komende 2 maanden een flinke Java enterprise omgeving op gaat zetten heb je aan die "superenthousiaste" .Netter ook geen fluit. Die is 2 weken bezig met alleen het uitvogelen hoe Maven werkt, laat staan 't hele Spring framework.

Natuurlijk is de drive om je nieuwe dingen aan te leren super belangrijk; dit geldt voor elke dev ongeacht welk platform je vandaan komt, simpelweg omdat de informatica wereld enorm snel vooruit gaat. Maar onderschat niet de waarde van ervaring.

Je mag wel iets minder hoog van de toren blazen. Je claim 25 jaar ervaring te hebben strookt niet helemaal met je volledige gebrek aan waardering van de ervaring die een developer over een X aantal jaren opbouwt in een tech stack, of claims dat memory leaks niet meer bestaan. Maargoed, da's wel wat ik bij meer Sogetisten gezien heb Heb ooit nog jullie rotzooi op mogen ruimen bij D-Reizen dus die "wat nou memory leaks?" houding is herkenbaar.

[Croga]

Hydra schreef op dinsdag 25 augustus 2015 @ 11:35:
Lekker makkelijk. Als je in de komende 2 maanden een flinke Java enterprise omgeving op gaat zetten heb je aan die "superenthousiaste" .Netter ook geen fluit. Die is 2 weken bezig met alleen het uitvogelen hoe Maven werkt, laat staan 't hele Spring framework.

Gelukkig bestaat er geen ontwikkelaar meer en praten we alleen nog maar over teams. Multidisciplinaire teams waarbij niet iedereen dezelfde kennis in brengt.
Daarnaast spreek ik slechts in algemene termen. Natuurlijk zijn daar uitzonderingen op. Maar de tijd die er binnen een bedrijf besteed wordt aan het opzetten van een enterprise omgeving valt in het niet bij de tijd die besteed wordt aan het zorgen dat die enterprise omgeving waarde levert voor het bedrijf.

De persoonlijke aanvallen mag je overigens gewoon thuis laten. Die horen niet thuis.

[ Voor 4% gewijzigd door Croga op 25-08-2015 12:04 ]

[RagingPenguin]

Hydra schreef op dinsdag 25 augustus 2015 @ 11:35:
[...]


Lekker makkelijk. Als je in de komende 2 maanden een flinke Java enterprise omgeving op gaat zetten heb je aan die "superenthousiaste" .Netter ook geen fluit. Die is 2 weken bezig met alleen het uitvogelen hoe Maven werkt, laat staan 't hele Spring framework.

Als je weet hoe een depedency maneger werkt heb je echt geen problemen om met Maven te werken(of iedere andere willekeurige dependency maneger). Het soort taferelen die jij schrijft zie je bij mensen die allen hebben leren code kloppen en geen idee hebben wat ze eigenlijk doen. Op het HBO doen ze dat gelukkig niet en leer je gewoon het pricipe 'depedency' en heb je iets van 5 minuten nodig om je thuis te voelen met maven.

[Woy]

RagingPenguin schreef op dinsdag 25 augustus 2015 @ 12:02:
[...]
Als je weet hoe een depedency maneger werkt heb je echt geen problemen om met Maven te werken(of iedere andere willekeurige dependency maneger). Het soort taferelen die jij schrijft zie je bij mensen die allen hebben leren code kloppen en geen idee hebben wat ze eigenlijk doen. Op het HBO doen ze dat gelukkig niet en leer je gewoon het pricipe 'depedency' en heb je iets van 5 minuten nodig om je thuis te voelen met maven.

Jullie stellen het nu beide wel erg zwart/wit. Als je lange tijd in een bepaalde omgeving werkt dan bouw je daar echt wel een voordeel mee op. Je zult gewoon veel sneller werken, en de do's en don'ts kennen.

Het is dan ook niet slim om te verwachten dat een ervaren .NET ontwikkelaar meteen volledig even productief is in een Java omgeving ( En visa versa precies hetzelfde )

Echter is het ook weer niet zo dat het jaren gaat duren om effectief mee te kunnen draaien in een team, want veel kennis is met een beetje oefening gewoon goed herbruikbaar in een andere omgeving.

Dat is niet anders dan een automonteur die jaren aan BMW's heeft gewerkt, en dus exact weet welke verschijnselen bij welke kwalen horen die opeens aan een VW gaat werken. De onderliggende techniek kent hij wel, maar toch zal hij wel weer even uit moeten zoeken hoe het bij het andere merk precies in elkaar zit.

[RagingPenguin]

Woy schreef op dinsdag 25 augustus 2015 @ 12:20:
[...]

Jullie stellen het nu beide wel erg zwart/wit. Als je lange tijd in een bepaalde omgeving werkt dan bouw je daar echt wel een voordeel mee op. Je zult gewoon veel sneller werken, en de do's en don'ts kennen.

Het is dan ook niet slim om te verwachten dat een ervaren .NET ontwikkelaar meteen volledig even productief is in een Java omgeving ( En visa versa precies hetzelfde )

Echter is het ook weer niet zo dat het jaren gaat duren om effectief mee te kunnen draaien in een team, want veel kennis is met een beetje oefening gewoon goed herbruikbaar in een andere omgeving.

Dat is niet anders dan een automonteur die jaren aan BMW's heeft gewerkt, en dus exact weet welke verschijnselen bij welke kwalen horen die opeens aan een VW gaat werken. De onderliggende techniek kent hij wel, maar toch zal hij wel weer even uit moeten zoeken hoe het bij het andere merk precies in elkaar zit.

O, ja, voor de switch Java -> C# heb je wel even nodig(en andersom ook). Op de studies is op dit moment zowel C# als Java verplicht, juist om te zorgen dat de studenten zich makkelijk kunnen richten op de kant die zij willen(vanaf jaar 3 bepaal je helemaal zelf wat je gebruikt, in jaar 1 en 2 mag in ongeveer de helft van de gevallen zelf kiezen en is de andere helft voorgeschreven)

[Hydra]

RagingPenguin schreef op dinsdag 25 augustus 2015 @ 12:02:
Als je weet hoe een depedency maneger werkt heb je echt geen problemen om met Maven te werken(of iedere andere willekeurige dependency maneger). Het soort taferelen die jij schrijft zie je bij mensen die allen hebben leren code kloppen en geen idee hebben wat ze eigenlijk doen. Op het HBO doen ze dat gelukkig niet en leer je gewoon het pricipe 'depedency' en heb je iets van 5 minuten nodig om je thuis te voelen met maven.

Dus je hebt binnen 5 minuten door hoe je verschillende build profiles met managed dependencies op zet inclusief deployable EARs voor Glassfish? Knap!

Ik heb het niet over het kunnen runnen van "mvn clean install". Ik heb het over het snappen hoe maven werkt, inclusief bijvoorbeeld het binden van plugins aan verschillende build phases. Een onderwerp waar boeken over geschreven zijn leer jij niet ff binnen 5 minuten.

Ik ben overigens wel blij met je reactie want dit geeft precies het probleem weer: veel mensen kennen een hoop dingetjes erg oppervlakkig. Er zijn veel te weinig echt ervaren devs die van de hoed en de rand weten.

Croga schreef op dinsdag 25 augustus 2015 @ 11:51:
Gelukkig bestaat er geen ontwikkelaar meer en praten we alleen nog maar over teams. Multidisciplinaire teams waarbij niet iedereen dezelfde kennis in brengt.

Je zult hoe dan ook een paar ervaren seniors moeten hebben die de meer junior developers coachen. Vanuit ons bedrijf worden we regelmatig binnengehaald op projecten die op dat moment 'gerund' worden door jullie zuster Cap bijvoorbeeld en compleet gestrand zijn vanwege een gebrek aan goede ervaren seniors. "Er is geen ontwikkelaar, er is alleen een team" is typisch iets voor integrators wiens business het is om veel warm vlees naar binnen te schuiven zonder acht te slaan op individuele competenties. En dit, samen met gebrekkige doorgroeimogelijkheden, is precies de reden waarom high potentials over het algemeen zo rond hun 3e wel klaar zijn met juist die grote integrators.

Daarnaast spreek ik slechts in algemene termen.

Je maakte een erg specifieke en erg makkelijke vergelijking tussen een enthousiaste dev in stack A en een vastgeroeste no-no in stack B. Dat is niet 'algemeen', dat is gewoon drogredeneren.

Natuurlijk zijn daar uitzonderingen op. Maar de tijd die er binnen een bedrijf besteed wordt aan het opzetten van een enterprise omgeving valt in het niet bij de tijd die besteed wordt aan het zorgen dat die enterprise omgeving waarde levert voor het bedrijf.

Als de fundering waardeloos is gaat wat je er ook op gaat bouwen, met wie dan ook, als een kaartenhuis in elkaar storten. Dit is precies waarom het in grote (oevrheids-)projecten vaak helemaal misloopt.

De persoonlijke aanvallen mag je overigens gewoon thuis laten. Die horen niet thuis.

Je probeert indruk te maken met je 25 jaar 'ervaring' waar nu blijkt dat de laatste 7 jaar hiervan is bij een bedrijf dat een bijzonder slechte reputatie heeft. Als je niet wil dat mensen gaan kijken waar die ervaring dan wel precies uit bestaat is het misschien handiger je betoog niet op te hangen aan een ad verecundiam. Beweren dat in talen als Java geen memory leaks bestaan is ook ronduit dom; ik heb er vorige week nog een uit moeten debuggen hier en dit was ook geen kwestie van "design patterns" maar gewoon een programmeer fout.

Was dit een persoonlijke aanval? Als je dit zo voelt is dat het misschien wel. Maar het gaat me er vooral om dat je beroep op autoriteit enorm misplaatst is. Als je discussieert doe het dan zelf ook gewoon op argumenten en niet op loze managementpraat ("er is alleen een team") of drog redenaties.

RagingPenguin schreef op dinsdag 25 augustus 2015 @ 12:25:
O, ja, voor de switch Java -> C# heb je wel even nodig(en andersom ook). Op de studies is op dit moment zowel C# als Java verplicht, juist om te zorgen dat de studenten zich makkelijk kunnen richten op de kant die zij willen(vanaf jaar 3 bepaal je helemaal zelf wat je gebruikt, in jaar 1 en 2 mag in ongeveer de helft van de gevallen zelf kiezen en is de andere helft voorgeschreven)

M.i. is het verplichten van zowel Java als C# complete tijdsverspilling. Het zijn beiden managed talen op een VM die bovendien zowel kwa syntax als kwa opbouw enorm op elkaar lijken. Ik hoop van harte dat jullie ook blootgesteld worden aan andere paradigma's zoals unmanaged talen, functional talen als Haskell en logic programming talen als Prolog. Daar leer je veel meer van dan van een Java kloon.

[ Voor 10% gewijzigd door Hydra op 25-08-2015 13:08 ]

[Croga]

Hydra schreef op dinsdag 25 augustus 2015 @ 13:03:
Je zult hoe dan ook een paar ervaren seniors moeten hebben die de meer junior developers coachen. Vanuit ons bedrijf worden we regelmatig binnengehaald op projecten die op dat moment 'gerund' worden door jullie zuster Cap bijvoorbeeld en compleet gestrand zijn vanwege een gebrek aan goede ervaren seniors. "Er is geen ontwikkelaar, er is alleen een team" is typisch iets voor integrators wiens business het is om veel warm vlees naar binnen te schuiven zonder acht te slaan op individuele competenties. En dit, samen met gebrekkige doorgroeimogelijkheden, is precies de reden waarom high potentials over het algemeen zo rond hun 3e wel klaar zijn met juist die grote integrators.

Dat "er is alleen een team" iets zou zijn voor integrators is nonsense. Integrators hebben daar juist een enorme hekel aan aangezien ze (wij) CVs verkopen en geen oplossingen. Teams zijn er voor oplossingen, niet voor CVs. En juist die high potentials wil je niet in je team hebben. De psychologische gevolgen van 1 hipo in een team op de rest van het team zijn zwaar destructief voor de productiviteit van het gehele team.

Kijk voor de grap eens naar ALLE succesvolle bedrijven van die moment (even snel; Google, Skype, Spotify, Valve om er maar wat te noemen...) Geen van allen werken ze meer als individuen. Allemaal werken ze met team als de kleinste ondeelbare eenheid en allemaal werken ze met een kennis/kunde/ervarings profiel per team.

Je maakte een erg specifieke en erg makkelijke vergelijking tussen een enthousiaste dev in stack A en een vastgeroeste no-no in stack B. Dat is niet 'algemeen', dat is gewoon drogredeneren.

Boude uitspraak zonder onderbouwing. Waarom is dat niet algemeen?

Als de fundering waardeloos is gaat wat je er ook op gaat bouwen, met wie dan ook, als een kaartenhuis in elkaar storten. Dit is precies waarom het in grote (oevrheids-)projecten vaak helemaal misloopt.

Dus huur je voor 2 weken die chagrijnige specialist in waarna je hem vervangt door die enthousiaste nieuweling. Om een enterprise systeem uit de grond te trekken heb je geen medewerker nodig, daar heb je een aap voor nodig die een truukje kent.

Wederom verwerp ik je ad-hominem. Persoonlijke aanvallen waren leuk op de kleuterschool, in een professionele omgeving is het zinloos. Je zet je persoonlijke mening neer als feiten, ondanks dat de wereld anders in elkaar steekt. Leuk voor je, maar doe dat gewoon op het schoolplein.

M.i. is het verplichten van zowel Java als C# complete tijdsverspilling. Het zijn beiden managed talen op een VM die bovendien zowel kwa syntax als kwa opbouw enorm op elkaar lijken. Ik hoop van harte dat jullie ook blootgesteld worden aan andere paradigma's zoals unmanaged talen, functional talen als Haskell en logic programming talen als Prolog. Daar leer je veel meer van dan van een Java kloon.

Dát verschil is wel weer een belangrijke. Mijn voorbeelden stelden allemaal dat de manier van denken voor Java en .NET vergelijkbaar is en dus nauwelijks interessant waar de persoon ervaring mee heeft. Zodra je met andere manieren van denken gaat werken (procedureel versus OO, bytewise versus "humanlike" versus functional) ligt de keuze wellicht anders.....

[Hydra]

Croga schreef op dinsdag 25 augustus 2015 @ 13:27:
Dat "er is alleen een team" iets zou zijn voor integrators is nonsense. Integrators hebben daar juist een enorme hekel aan aangezien ze (wij) CVs verkopen en geen oplossingen. Teams zijn er voor oplossingen, niet voor CVs. En juist die high potentials wil je niet in je team hebben. De psychologische gevolgen van 1 hipo in een team op de rest van het team zijn zwaar destructief voor de productiviteit van het gehele team.

Wat? Dus je ontneemt je eigen juniors de mogelijkheid om uberhaupt wat van een ervaren developer te leren? Ik zelf probeeer, als behoorlijk ervaren developer, juist zoveel mogelijk samen te werken met mensen die slimmer zijn dan ik. Dat is de beste manier om beter te worden; afkijken.

Software development is een trade en zoals je vroeger bij een ervaren timmerman in de leer ging zo leer je tegenwoordig het meest door in een team te zitten met voldoende erg ervaren devs. Dat die de productiviteit omlaag zouden halen is een laf excuus van een CV schuiver die niet in staat is ervaren mensen vast te houden.

Wel komisch dat ik ondertussen op LinkedIn door jullie PR afdeling platgespamd wordt met uitnodigen om te kijken wat Sogeti vindt van het door hun net ontdekte IoT

Kijk voor de grap eens naar ALLE succesvolle bedrijven van die moment (even snel; Google, Skype, Spotify, Valve om er maar wat te noemen...) Geen van allen werken ze meer als individuen. Allemaal werken ze met team als de kleinste ondeelbare eenheid en allemaal werken ze met een kennis/kunde/ervarings profiel per team.

Grappig dat je dat soort bedrijven aanhaalt. Vooral Google kan het zich permitteren erg picky te zijn wat beterft de developers die ze binnenhalen. Ze gaan alleen voor de high potentials (die ze daarna overigens triviale taken laten uitvoeren).

Ik snap overigens niet waar bij jou de stap vandaan komt dat een team niet betekent dat je geen ervaren seniors nodig hebt: juist de bedrijven die jij aanhaalt, vooral Google, laat het architectuur door hele ervaren en hoog opgeleide mensen doen.

Boude uitspraak zonder onderbouwing. Waarom is dat niet algemeen?

Dat zeg ik letterlijk: je schetst een specifieke situatie. Dat is niet "algemeen". Dat is zo iets als zeggen dat als je een dood konijn zit fietsen je dan "over het algemeen" verbaasd zal zijn. Ja duh.

Dus huur je voor 2 weken die chagrijnige specialist in waarna je hem vervangt door die enthousiaste nieuweling. Om een enterprise systeem uit de grond te trekken heb je geen medewerker nodig, daar heb je een aap voor nodig die een truukje kent.

Ja nogmaals: Ik snap steeds beter waarom het destijds bij D-Reizen zo'n rotzooi was. Je aap die het truukje uitvoerde had overduidelijk nooit van het concept graceful degradation gehoord. Om het over de kwaliteit van de code (oh de query werkt niet, we doen het gewoon nog een keer en als 't dan neit werkt geven we een 500) nog maar niet te hebben.

Large scale enterprise omgevingen, helemaal nu "big data" zo in opkomst is, is geen truukje. Er zijn talloze randvoorwaarden die afgedekt moeten worden en al die randvoorwaarden zijn specifiek voor een klant. Wehkamp is geen D-Reizen is geen UWV is geen IND is geen NFI. Allemaal systemen met veel data, allemaal **compleet** anders. En bij elk van die bedrijven heb ik jullie of Cap of Logica de boel zien verstieren met jullie "het is een truukje" mentaliteit. De enige grote integrator die het een beetje doorheeft is Accenture; die laten de initiele setup tenminste door erg ervaren erg intelligente mensen doen. Die trekken als zigeuners heel Europa door.

Wederom verwerp ik je ad-hominem. Persoonlijke aanvallen waren leuk op de kleuterschool, in een professionele omgeving is het zinloos. Je zet je persoonlijke mening neer als feiten, ondanks dat de wereld anders in elkaar steekt. Leuk voor je, maar doe dat gewoon op het schoolplein.

Ik snap dat 't pijnlijk is dat je appel op autoriteit onderuit gehaald wordt, geeft niks. Je opmerking over memory leaks was dom en fout. Ik vind het kinderachtig dat je dat niet kunt onderkennen.

[Lethalis]

Mijn eigen ervaring tot nu toe: ik heb er ongeveer 2 jaar over gedaan om naast mijn baan als .NET programmeur Java en Spring MVC te leren. Dan hebben we het gemiddeld over 10 uur per week denk ik.

Dus als ik dat naar een 40 urige werkweek vertaal dan is dat 6 maanden. Dat is dan wel zonder begeleiding, dus misschien dat het in 4 maanden had gekund om op het punt te komen waar ik nu ben (dat was dus een dikke faal geweest waarschijnlijk).

Eigenlijk durf ik het nu pas aan om voorzichtig te zeggen van "als ik op een Java baan zou solliciteren waar ze veel Spring gebruiken, dan zou dat op zich goed moeten komen" Dat wil zeggen: ik kan nu met Spring MVC en Java in principe alles bouwen dat ik op mijn werk als .NET developer heb gebouwd (en dat is alsnog geen garantie dat ik dat op de meest handige manier zal doen).

12 jaar .NET ervaring hier en ik sta nou niet bepaald als een slow learner bekend (ik ben op mijn werk altijd de eerste die iets nieuws leert zo ongeveer).

Het zou vrij safe zijn om gewoon met .NET verder te gaan, maar Java lijkt me wel leuker.

[ Voor 3% gewijzigd door Lethalis op 25-08-2015 16:43 ]

[RagingPenguin]

Hydra schreef op dinsdag 25 augustus 2015 @ 13:03:
M.i. is het verplichten van zowel Java als C# complete tijdsverspilling. Het zijn beiden managed talen op een VM die bovendien zowel kwa syntax als kwa opbouw enorm op elkaar lijken. Ik hoop van harte dat jullie ook blootgesteld worden aan andere paradigma's zoals unmanaged talen, functional talen als Haskell en logic programming talen als Prolog. Daar leer je veel meer van dan van een Java kloon.

Die laatste dingen zijn TI en geen informatica. De beroepssector informatica heeft de studies technische informatica, informatica, creatieve media en game technologie, mediadesign en communicatie en mediadesign.

De dingen waar jij op wijst al belangrijk zijn dat ongetwijfeld, maar niet voor de studie informatica. Al wil je een baan waar kennis van die zaken belangrijk voor is dan ga je TI doen. En ja, C# en Java lijken veel op elkaar en vandaar dat ze ook naast- en door elkaar worden gegeven.

eidt: ik heb uit het lijstje met opleidingen de netwerkbeheer en hrdware studies weggelaten. Die worden op ons instistuut niet gegeven en ik heb geen idee welke smaken je daarin hebt

[ Voor 8% gewijzigd door RagingPenguin op 25-08-2015 17:15 ]

[Hydra]

RagingPenguin schreef op dinsdag 25 augustus 2015 @ 17:06:
[...]


Die laatste dingen zijn TI en geen informatica. De beroepssector informatica heeft de studies technische informatica, informatica, creatieve media en game technologie, mediadesign en communicatie en mediadesign.

De dingen waar jij op wijst al belangrijk zijn dat ongetwijfeld, maar niet voor de studie informatica. Al wil je een baan waar kennis van die zaken belangrijk voor is dan ga je TI doen. En ja, C# en Java lijken veel op elkaar en vandaar dat ze ook naast- en door elkaar worden gegeven.

Heb je het nu specifiek over de hogeschool van Rotterdam? Ik heb toch echt HBO informatica gedaan (HIO destijds) en daar waren dat toch gewoon onderdelen van je studie. En hoe dan ook ik dit een belangrijke achtergrond voor eenieder die zichzelf Software Engineer wil kunnen noemen.

[RagingPenguin]

Hydra schreef op dinsdag 25 augustus 2015 @ 17:17:
[...]


Heb je het nu specifiek over de hogeschool van Rotterdam? Ik heb toch echt HBO informatica gedaan (HIO destijds) en daar waren dat toch gewoon onderdelen van je studie. En hoe dan ook ik dit een belangrijke achtergrond voor eenieder die zichzelf Software Engineer wil kunnen noemen.

Ik zit zelf op het HRO, maar de inhoud van de studies is tegenwoordig min of meer landelijk geregeld(lees: er is een omschrijving van wat je moet kunnen na je studie en hoe dat word geleerd bepalen de scholen zelf). En met alle studies krijg je het label 'Ingenieur', zelfs met communicatie en mediadesign wat eigenlijk een cross-over is tussen communicatie en mediadesign(en waar C# en Java al amper gegeven word). Software Engineer hoort bij informatica en TI.

[Lethalis]

Unmanaged talen zoals C++ en functional programming met bijv. Haskell is iets waarvan elke programmeur idd de basis van zou moeten kennen.

Op zijn minst het functionele paradigma en de voordelen van immutability.

C++ heb ik op het hbo geleerd, Haskell is onderdeel van WO (in mijn geval Open Universiteit) studie Informatica.

[ Voor 20% gewijzigd door Lethalis op 25-08-2015 18:24 ]

[BoringDay]

"Software Engineer hoort bij informatica en TI."

Is dan er nog wel iets overgebleven van het vak informatica tegenwoordig?

In de praktijk is het i.i.g. een feit dat dergelijke kennis nodig is, als je wat verder wil komen dan slechts wat formuliertjes wilt opstellen en beetje syntaxes kloppen voor websites.

[Megamind]

BoringDay schreef op dinsdag 25 augustus 2015 @ 18:48:
"Software Engineer hoort bij informatica en TI."

Is dan er nog wel iets overgebleven van het vak informatica tegenwoordig?

In de praktijk is het i.i.g. een feit dat dergelijke kennis nodig is, als je wat verder wil komen dan slechts wat formuliertjes wilt opstellen en beetje syntaxes kloppen voor websites.

Je kan prima een app bouwen zonder diep gaande kennis van programmeren, zo simpel is het. Zelfs bij TI krijg je echt geen functioneel programmeren meer.

[Hydra]

RagingPenguin schreef op dinsdag 25 augustus 2015 @ 17:26:
Ik zit zelf op het HRO, maar de inhoud van de studies is tegenwoordig min of meer landelijk geregeld(lees: er is een omschrijving van wat je moet kunnen na je studie en hoe dat word geleerd bepalen de scholen zelf). En met alle studies krijg je het label 'Ingenieur', zelfs met communicatie en mediadesign wat eigenlijk een cross-over is tussen communicatie en mediadesign(en waar C# en Java al amper gegeven word). Software Engineer hoort bij informatica en TI.

Je gaf niet echt antwoord op mijn vraag. Ik ben niet erg geinteresseerd in communicatie achtige studies. Afaik is technische informatica wat vroeger computertechniek was, kruising tussen informatica en electrotechniek en is HBO informatica wat vroeger de HIO was. Het lijkt mij redelijk bizar dat je op een informatica opleiding alleen Java en C# gebruikt.

Megamind schreef op dinsdag 25 augustus 2015 @ 18:51:
Je kan prima een app bouwen zonder diep gaande kennis van programmeren, zo simpel is het. Zelfs bij TI krijg je echt geen functioneel programmeren meer.

HBO informatica is een opleiding tot software engineer, niet tot iemand die appjes bakt. Dat kan je buurjongen van 16 ook wel.

[ Voor 17% gewijzigd door Hydra op 25-08-2015 18:52 ]

[RagingPenguin]

Hydra schreef op dinsdag 25 augustus 2015 @ 18:51:
Je gaf niet echt antwoord op mijn vraag. Ik ben niet erg geinteresseerd in communicatie achtige studies. Afaik is technische informatica wat vroeger computertechniek was, kruising tussen informatica en electrotechniek en is HBO informatica wat vroeger de HIO was. Het lijkt mij redelijk bizar dat je op een informatica opleiding alleen Java en C# gebruikt.

Techniek krijgen ze bij TI wel, net als Embedded en C++(en Java). informatica krijgt voor de programmeertalen alleen Java en C#(wat al meer is als voorgaande jaren, toen was het alleen Java). Informatica heeft behalve dat ook nog html, css, javascript en SQL. Mediatechnologie en Creative media en game technologie heeft ook nog wel een heel klein beetje techniek, voornamelijk sensoren en iot achtige dingen(Raspberry en Arduino).

in dit topic hiet op GoT word HIO omschreven als 'een vergaarbak van informatica studies' en ik denk dat dat aardig waar is. Tegenwoordig zijn er 10+ studies voor de informatica sector.

HBO informatica is een opleiding tot software engineer, niet tot iemand die appjes bakt. Dat kan je buurjongen van 16 ook wel.

Zullen we het erop houden dat er wat variantie in de software engineers zit? Ik heb geen enkele moeite met het belang van low-level kennis, maar al wil je er echt wat mee doen kies je TI.

[Hydra]

Goed. Hoef me over m'n toekomst dus geen zorgen te maken als ze informatica zo laten verwateren.

[BoringDay]

Megamind schreef op dinsdag 25 augustus 2015 @ 18:51:
[...]

Je kan prima een app bouwen zonder diep gaande kennis van programmeren, zo simpel is het. Zelfs bij TI krijg je echt geen functioneel programmeren meer.

Wat heeft functioneel programmeren ermee te maken?
Het gaat om de praktijk en daar kom je nog een heleboel dingen tegen die aardig wat kennis vereisen (Pointers zijn daar geen uitzondering op. Zelfs met debuggen kom je dat regelmatig tegen).

[Lethalis]

Megamind schreef op dinsdag 25 augustus 2015 @ 18:51:
[...]

Je kan prima een app bouwen zonder diep gaande kennis van programmeren, zo simpel is het. Zelfs bij TI krijg je echt geen functioneel programmeren meer.

En dus zullen er enorme tekorten ontstaan op functies waar je meer voor moet kunnen dan apps en websites bouwen.

[Bv202]

Hier in België heb ik de opleiding TI (Toegepaste Informatica) gevolgd en kreeg je bijna niets meer over memory management en dergelijke. Ik moest wat basic sorteer- en zoekalgoritmen kennen, maar verder dan dat ging het ook niet eigenlijk. Je ziet het wel, maar echt heel beperkt. Dat is enorm teleurstellend eigenlijk...

Ik begrijp niet goed waarom er discussie is over .NET vs Java. Ik werk zelf als .NET developer, maar werk nu bij een klant in AngularJS, zonder hiervoor een degelijke Javascript-kennis te hebben. Ik heb een week gekregen om me voor te bereiden via zelfstudie (ik kon wel terugvallen op een ervaren developer voor advies en sturing) en dan moest ik m'n plan trekken. En die week kreeg ik eigenlijk omdat het contract pas startte op een bepaalde datum. Daar draait het uiteindelijk toch om als developer: openstaan voor nieuwe/andere dingen en deze je zelfstandig kunnen aanleren. Of zien jullie dit hier anders?