Niet kiezen voor een taal, vanwege de tooling?

[gekkie]

[quote]Schnupperpuppe schreef op zondag 12 april 2015 @ 19:14:

Hmmm...krijg honger!

Heeft vim daar geen commando voor ?
Of is moeders de vrouw nu opeens ook de moeder aller editors ? (gaat de oude fiets wel weer op )

[Ruudjah]

Schnupperpuppe, welke taal schrijf jij je code in? Welke libs gebruik je?

[Schnupperpuppe]

Ruudjah schreef op zondag 12 april 2015 @ 19:36:
Schnupperpuppe, welke taal schrijf jij je code in? Welke libs gebruik je?

Op dit moment voornamelijk Perl en JavaScript. Zijdelings nog wat PHP, C, Obj-C en Java.
Libraries? JavaScript frameworks: Cordova, jQuery, jQuery-UI en jQuery-Mobile. Perl modules: te veel om op te noemen. ZeroMQ.

[hackerhater]

Lethalis schreef op zaterdag 11 april 2015 @ 13:30:
Ik heb in mijn leven meer dan 100 Linux kernels gecompileerd (daarnaast ook FreeBSD kernels). Mijn werk is .Net ontwikkelaar op Windows

Simpelweg omdat ik daar meer geld mee verdien. Java en IntelliJ op een Mac lijkt me tegenwoordig ook leuker.. Maar ja, dan zou ik nu moeten switchen en geen idee of ik daarmee meteen goed verdien.

Leuke collega's en een vooruitstrevend team in het algemeen is toch wel het belangrijkste.

Oftwel; VS 2013 met Asp.net MVC gebruiken is niks mis mee.. Nu nog met VS2010 werken en WebForms of zoiets als SourceSafe erbij.. Ja, dan raak ik wel geirriteerd.

Ik wil wel met nieuwe technieken bezig zijn. Of dat dan met C#, Java, of bijv Scala is en op welk OS boeit mij dan eigenlijk niet echt.

True dat leuke collega's belangrijker zijn. Echter voor wat meer geld zou ik niet switchen naar Windows.
Of ik nu 1,5 of 2 modaal verdien. #care. Huisje, boompje, beestje heb ik al.

Ik heb meer dan genoeg werk en genoeg aanbiedingen. Waarom zou ik dan in vredesnaam uitwijken naar technieken die ik niet zie zitten?

[Brent]

Megamind schreef op zaterdag 11 april 2015 @ 17:44:
[...]

Waar werk je (aan) als ik vragen mag? In mijn dev team sta ik het niet toe dat mensen maar hun eigen tooltjes gaan proberen, we gebruiken een standaard omgeving met standaard tools. Als iemand dan moet inspringen hoeft hij niet eerst 4 uur te kloten met vage tools waar die ene developer zo graag mee moet werken.

Je raakt hier een belangrijk punt: de aard van de shop waar je werkt. Mijn ervaring zegt dat bij de archetypische corporate CRUD-achtige software, men zeer sterk hecht aan standaard-software, zodat een werknemer makkelijk te vervangen is. Verantwoording is de bottomline. Er zijn echter ook shops waar het er heel anders aan toe gaat, dus de niet-typische corporate software die niet verkocht/gesupport wordt denk ik dan aan. Indien je software alleen voor intern gebruik is. Dan maakt het niet zoveel (iig minder) uit de software 'maintainable' is, niemand die die code ooit lezen zal.

Mijn job heeft 1 bottomline: get the job done. Het maakt niet uit welke taal of tools ik gebruik, of dat ik eigen tools bouw. Sterker nog, dat wordt wel gewaardeerd. Natuurlijk is het in mijn eigenbelang niet duizend-en-een dependencies te gebruiken, ik moet het zelf over een half jaar ook nog snappen/gebruiken. Simpel is altijd in m'n achterhoofd Toko's die nieuw spul ontwikkelen zullen per definitie geen standaard-tooling opleggen.

Vorm over functie, dat zie je toch voornamelijk in een bepaalde hoek van software-ontwikkeling, het is zeker niet overal zo.

[Lethalis]

hackerhater schreef op maandag 13 april 2015 @ 10:05:
[...]
True dat leuke collega's belangrijker zijn. Echter voor wat meer geld zou ik niet switchen naar Windows.
Of ik nu 1,5 of 2 modaal verdien. #care. Huisje, boompje, beestje heb ik al.

Ik heb meer dan genoeg werk en genoeg aanbiedingen. Waarom zou ik dan in vredesnaam uitwijken naar technieken die ik niet zie zitten?

1,5 of 2 keer modaal is nogal een verschil

Daar ben ik wel voor om te kopen hoor.

Maar ik heb dan ook geen hekel aan Windows. Ik vind Linux en OS X misschien wel leuker, maar baal er niet van dat ik met Windows werk.

Brent schreef op maandag 13 april 2015 @ 14:03:
[...]
Je raakt hier een belangrijk punt: de aard van de shop waar je werkt. Mijn ervaring zegt dat bij de archetypische corporate CRUD-achtige software, men zeer sterk hecht aan standaard-software, zodat een werknemer makkelijk te vervangen is. Verantwoording is de bottomline. Er zijn echter ook shops waar het er heel anders aan toe gaat, dus de niet-typische corporate software die niet verkocht/gesupport wordt denk ik dan aan. Indien je software alleen voor intern gebruik is. Dan maakt het niet zoveel (iig minder) uit de software 'maintainable' is, niemand die die code ooit lezen zal.

Naar mijn mening moet software altijd goed te onderhouden zijn en ik zou het in een bedrijf altijd slecht vinden als er code is die maar door 1 persoon veranderd kan worden.

Mocht ik een eigen bedrijf hebben, dan zou ik bijvoorbeeld wel voor iets grappigs kunnen kiezen, zoals Go ipv C#, maar dan nog moet die code goed beheerd worden en is het fijn als er een bepaalde standaard wordt gekozen.

Niet teveel cowboy programming

[ Voor 46% gewijzigd door Lethalis op 13-04-2015 15:47 ]

[hackerhater]

Lethalis schreef op maandag 13 april 2015 @ 15:42:
1,5 of 2 keer modaal is nogal een verschil

Daar ben ik wel voor om te kopen hoor.

Maar ik heb dan ook geen hekel aan Windows. Ik vind Linux en OS X misschien wel leuker, maar baal er niet van dat ik met Windows werk.

Dat is dan mijn salaris. Komt die van mijn vriendin nog bij en dan praat je straks over 3,5 en 4 modaal.
Het is maar geld. Zodra je genoeg hebt om niet op je geld te hoeven letten wordt plezier in je werk veel belangrijker.
Als vergelijk : we "dreigen" over een paar jaar de vermogensgrens te gaan raken.

[Lethalis]

hackerhater schreef op maandag 13 april 2015 @ 15:47:
[...]
Dat is dan mijn salaris. Komt die van mijn vriendin nog bij en dan praat je straks over 3,5 en 4 modaal.
Het is maar geld. Zodra je genoeg hebt om niet op je geld te hoeven letten wordt plezier in je werk veel belangrijker.
Als vergelijk : we "dreigen" over een paar jaar de vermogensgrens te gaan raken.

Daar heb je gelijk in.

Die vermogensgrens tsja.. dat is relatief en heeft veel met het bestedingspatroon te maken. Ik ken genoeg mensen die meer dan ik verdienen die geen cent overhouden

[Cloud]

Lethalis schreef op maandag 13 april 2015 @ 15:42:
[...]
Naar mijn mening moet software altijd goed te onderhouden zijn en ik zou het in een bedrijf altijd slecht vinden als er code is die maar door 1 persoon veranderd kan worden.
[...]

Absoluut mee eens, anders krijg je zo'n persoon er nooit weer uit. Die kan zichzelf makkelijk in zo'n positie blijven houden dat hij cruciaal is. Je weet nooit wat de toekomst brengt. Alle software die je maakt moet gewoon goed te onderhouden zijn. Als je dat niet doet komt het altijd een keer terug om je te bijten, denk ook aan ziekte. Ongeacht of je nu van plan bent werknemers te switchen, is het gewoon slimme bedrijfsvoering om de boel wel zodanig te structureren dat het kán.

Ik heb bij een hele kleine ontwikkelaar gewerkt waar men exact het soort vrijheden had waar het hier om gaat. Ik had mezelf, niet eens opzettelijk, binnen een jaar tijd vrijwel cruciaal gemaakt voor de bedrijfsvoering. En dat begon ik later ook te merken; denk aan vakantie vragen dat moeilijker werd, buiten werktijd vaker gebeld worden (zonder beloning), dat soort zaken. Ook werden er allerlei projecten gedraaid die elk eigen afhankelijkheden, tools en specifieke kennis nodig hadden. Dit terwijl de ontwikkelafdeling echt te klein was om dat allemaal te kunnen blijven onderhouden. Wat uiteraard gezeik opleverde. De enige met alle kennis was ik.

Nu waren er veel meer redenen maar uiteindelijk ben ik er opgestapt mede-omdat ik mij in zo'n bedrijfsvoering gewoon niet thuis voelde

[creator1988]

Wat me tegenstaat aan IDEs is dat het werkt, tot het niet meer werkt. Hoe goed een IDE ook is, er komt een moment waarop je IDE je workflow niet ondersteunt en je toch weer terug moet naar handmatig bewerken. Bijv. als je je interfaces in IDL schrijft, of als je code generation hebt voor je IPC bindings (om twee dingen te noemen die ik vandaag gedaan heb). Het moment dat je even van de 'standaard' afgaat ga je al nat, want dat ondersteunt je IDE niet.

En de meeste refactor acties die ik doe zijn op code waarmee ik bekend ben en dus weet ik wel redelijk waar alles staat. Bovendien mist je refactor actie waarschijnlijk ergens een mapping in je build script dus ben je nog steeds handmatig bezig.

En refactoring in code blocks gaat makkelijk met multiple cursors. In ieder geval voor mijn gevoel niet sneller dan een refactor actie in VS.

(context: C++ schrijvende voor Mozilla, gebruik een text editor met wat features zoals code outline, geen IDE. Vroeger veel C# met VS/Reshareper geschreven.)

[Brent]

Cloud schreef op maandag 13 april 2015 @ 16:05:
[...]

Absoluut mee eens, anders krijg je zo'n persoon er nooit weer uit.

Het hangt er dus maar helemaal vanaf of dat een probleem is. Voor een deel van de industrie, ja. Maar een belangrijk deel ook niet. Start-up founders zijn voordehandliggend, maar ook de echte 'rockstars'. Sowieso als je je software niet verkoopt is het minder van belang.

Bovendien zijn prototyperen en verpakken voor consumptie (en support) te ontbinden.

Lethalis schreef op maandag 13 april 2015 @ 15:42:
Naar mijn mening moet software altijd goed te onderhouden zijn en ik zou het in een bedrijf altijd slecht vinden als er code is die maar door 1 persoon veranderd kan worden.

Je haalt hier een aantal dingen door elkaar. Goede software is per definitie goed te onderhouden. Extra tooltjes gebruiken maakt het niet minder onderhoudbaar, wel minder makkelijk. Voor bepaalde delen van de industrie is dat een punt van belang, maar niet overal.

Niet teveel cowboy programming

Ik zou niet anders willen Zonder dollen, tussen striktheid waar jij het over lijkt te hebben en totale anarchie zit een heel spectrum. Je moet niet denken dat iets anders dan jouw visie op 'orde' direct cowboy is, integendeel. Ik heb geen regeltjes of een beperkte toegestane set tools nodig om te weten hoe het wel moet en hoe niet. Tegelijk weet ik dat er lieden zijn die dat absoluut nodig hebben. Daartussen verkeer is sowieso liever niet. Ik zou snel verdrietig worden bij corporate coden, ingericht op mijn inwisselbaarheid, mijn vermeende domheid. Maar ik geloof dat ik m'n werkgever ook wel iets meer kan bieden dan dat

[Lethalis]

Brent schreef op maandag 13 april 2015 @ 16:26:
[...]
Je haalt hier een aantal dingen door elkaar. Goede software is per definitie goed te onderhouden. Extra tooltjes gebruiken maakt het niet minder onderhoudbaar, wel minder makkelijk. Voor bepaalde delen van de industrie is dat een punt van belang, maar niet overal.

Ik reageerde op jouw opmerking dat software niet "maintainable" hoefde te zijn. Ik vind van wel

Ik zou niet anders willen Zonder dollen, tussen striktheid waar jij het over lijkt te hebben en totale anarchie zit een heel spectrum. Je moet niet denken dat iets anders dan jouw visie op 'orde' direct cowboy is, integendeel. Ik heb geen regeltjes of een beperkte toegestane set tools nodig om te weten hoe het wel moet en hoe niet. Tegelijk weet ik dat er lieden zijn die dat absoluut nodig hebben. Daartussen verkeer is sowieso liever niet. Ik zou snel verdrietig worden bij corporate coden, ingericht op mijn inwisselbaarheid, mijn vermeende domheid. Maar ik geloof dat ik m'n werkgever ook wel iets meer kan bieden dan dat

Ik heb jouw website even bezocht. Context is wel belangrijk hier denk ik. Persoonlijk werk ik als software developer bij een automatiseringsbedrijf van ERP software in een bepaalde branche. Coden draait grotendeels om nieuwe features opleveren, deadlines halen, code doorspitten die mensen 10 jaar geleden hebben geschreven die niet eens meer bij het bedrijf werken, enzovoorts.

Dat is wat anders dan zelf code schrijven om een bepaald onderzoek te kunnen doen. Dat kun je niet met elkaar vergelijken. De software is dan ondersteunend, maar geen doel op zich.

Het project waar ik momenteel aan werk bevat ontzettend veel regels code.. ik heb voor de gein even de Code Metrics uitgevoerd op de solution in Visual Studio: 462.470 regels code.

[Brent]

Lethalis schreef op maandag 13 april 2015 @ 16:53:
[...]

Ik reageerde op jouw opmerking dat software niet "maintainable" hoefde te zijn. Ik vind van wel

Lees nog even goed: ik zeg dat het van je branche afhangt of dat uitmaakt.

[...]

Ik heb jouw website even bezocht. Context is wel belangrijk hier denk ik.

Precies mijn punt.

Persoonlijk werk ik als software developer bij een automatiseringsbedrijf van ERP software in een bepaalde branche. Coden draait grotendeels om nieuwe features opleveren, deadlines halen, code doorspitten die mensen 10 jaar geleden hebben geschreven die niet eens meer bij het bedrijf werken, enzovoorts.

Dat is wat anders dan zelf code schrijven om een bepaald onderzoek te kunnen doen. Dat kun je niet met elkaar vergelijken. De software is dan ondersteunend, maar geen doel op zich.

Het project waar ik momenteel aan werk bevat ontzettend veel regels code.. ik heb voor de gein even de Code Metrics uitgevoerd op de solution in Visual Studio: 462.470 regels code.

Ik dev ook primair aan een pakket dat nu bijna een decennium oud is (teller staat op ~150kloc check ik net even). Dus dat is niet zozeer het verschil. Het genot van 10 oude code begrijpen en fixen ken ik maar al te goed Het verschil zit hem vooral in de aard van je zaak: zoals jij nu en ik al eerder zei: als je software verkoopt en support doe je het anders dan als het voor eigen gebruik is. Vriend bij Booking gaat ook wel ietsjes anders te werk dan jij, al wel weer een stuk formeler dan wij hier.

Het doorhameren op vorm (die taal, die tools) zie ik vooral terug bij bedrijven in jouw straatje. Ik wilde slechts toevoegen dat er ook andere straatjes zijn, en als je dus niet van bepaalde talen of tooling houd zoals OP kun je eens in een ander straatje kijken.

[R4gnax]

Cloud schreef op maandag 13 april 2015 @ 16:05:
[...]

Absoluut mee eens, anders krijg je zo'n persoon er nooit weer uit. Die kan zichzelf makkelijk in zo'n positie blijven houden dat hij cruciaal is. Je weet nooit wat de toekomst brengt. Alle software die je maakt moet gewoon goed te onderhouden zijn. Als je dat niet doet komt het altijd een keer terug om je te bijten, denk ook aan ziekte. Ongeacht of je nu van plan bent werknemers te switchen, is het gewoon slimme bedrijfsvoering om de boel wel zodanig te structureren dat het kán.

Ik heb bij een hele kleine ontwikkelaar gewerkt waar men exact het soort vrijheden had waar het hier om gaat. Ik had mezelf, niet eens opzettelijk, binnen een jaar tijd vrijwel cruciaal gemaakt voor de bedrijfsvoering. En dat begon ik later ook te merken; denk aan vakantie vragen dat moeilijker werd, buiten werktijd vaker gebeld worden (zonder beloning), dat soort zaken. Ook werden er allerlei projecten gedraaid die elk eigen afhankelijkheden, tools en specifieke kennis nodig hadden. Dit terwijl de ontwikkelafdeling echt te klein was om dat allemaal te kunnen blijven onderhouden. Wat uiteraard gezeik opleverde. De enige met alle kennis was ik.

Maar...

Kwam dit puur omdat jij allerlei eigen methodiek of tooling introduceerde? Of was dit ook omdat het de andere ontwikkelaars niet wisten (of erger: niet kon schelen) waar je mee bezig was? Of stiekem deels ook omdat jij op een heel ander denkniveau kon programmeren, waar sommige collega's bijv. maar amper de SOLID concepten konden begrijpen of toepassen?

In de onschuldige gevallen, waarbij iemand dus niet bewust job security through obscurity pleegt, is het nog vaak die tweede of derde die echt ten grondslag ligt aan het probleem. Als jij met toegenomen kennis over tijd in een rol als specialist op een bepaald gebied beland en daar vervolgens proces- of architectuur-verbeteringen in gaat spearheaden, maar je collega's daar niet in mee kunnen komen of zich over willen informeren; wiens fout is dat dan?

(Ik zou eerlijk gezegd zeggen dat het dan meer een communicatieprobleem is met een gebrek aan kennisoverdracht.)

[Ruudjah]

Naar mijn mening moet software altijd goed te onderhouden zijn en ik zou het in een bedrijf altijd slecht vinden als er code is die maar door 1 persoon veranderd kan worden.

Dat is inderdaad gewoon een vorm van een vendor-lockin.

[downtime]

R4gnax schreef op maandag 13 april 2015 @ 18:32:
Als jij met toegenomen kennis over tijd in een rol als specialist op een bepaald gebied beland en daar vervolgens proces- of architectuur-verbeteringen in gaat spearheaden, maar je collega's daar niet in mee kunnen komen of zich over willen informeren; wiens fout is dat dan?

Ik denk dat jouw werkgever niet wil weten wiens fout het is. Die hoort liever hoe het voorkomen kan worden. Die wil dat er oplossingen bedacht worden die ook de mindere goden in het team (kunnen) begrijpen want die mensen moeten ook kunnen functioneren. Geen enkel team bestaat alleen maar uit toppers en juist als voortrekker in je team wordt de uitdaging om verder te kijken dan de techniek en je ook af te vragen hoe het team als geheel beter kan functioneren. En dat betekent ook dat je oplossingen verzint waarmee iedereen uit de voeten kan.

[R4gnax]

downtime schreef op maandag 13 april 2015 @ 19:03:
[...]

En dat betekent ook dat je oplossingen verzint waarmee iedereen uit de voeten kan.

Wat uiteraard iets anders is (en waar ik het ook zeker mee eens ben) dan dat je de interne logica voor die ene oplossing op zo'n manier in elkaar zou moeten steken dat deze veruit suboptimaal is. De externe API; ja, die zal altijd goed in elkaar moeten steken. Maar is het ook zo dat iemand in moet leveren op de internals van zo'n oplossing zodat persoon X,Y,Z zonder enige vorm van toelichting, training of andere vorm van kennis daar direct 100% mee aan de slag kan?

Nee, zou ik zeggen.

[Brent]

Ruudjah schreef op maandag 13 april 2015 @ 19:01:
[...]

Dat is inderdaad gewoon een vorm van een vendor-lockin.

Niet bepaald. Switching costs zijn niet per se hoog bij zoiets, alleen als je er vanuit gaat dat je dombo's in dienst hebt is die bij voorbaat hoog.

Een andere kijk op de zaak is dat een paar simpele loosely coupled tools eerder een teken dat je iemand in dienst hebt die voor zichzelf kan zorgen dan dat hij alles moet googlen en afhangt van $ide.

[Hatsieflatsie]

Schnupperpuppe schreef op zondag 12 april 2015 @ 19:14:

M'n PM nog gekregen?

[Ruudjah]

Niet bepaald. Switching costs zijn niet per se hoog bij zoiets, alleen als je er vanuit gaat dat je dombo's in dienst hebt is die bij voorbaat hoog.

Switching costs kunnen in potentie oplopen tot een complete rewrite en zelfs een compleet nieuw R&D traject. Als een lead devver core componenten onderhoud die alléén híj kan begrijpen omdat er oeverloze complexiteit is gebruikt, dan kan je niet zomaar een ander ervaren werknemer op die plek krijgen. Ik zou zelfs zover willen gaan dat het de klassieke interpretatie (een library/dienst/middleware leverancier als "vendor") zou kunnen overstijgen in kosten.

[Ruudjah]

Schnupperpuppe schreef op maandag 13 april 2015 @ 07:22:
[...]


Op dit moment voornamelijk Perl en JavaScript. Zijdelings nog wat PHP, C, Obj-C en Java.
Libraries? JavaScript frameworks: Cordova, jQuery, jQuery-UI en jQuery-Mobile. Perl modules: te veel om op te noemen. ZeroMQ.

Opvallend dat vooral perl, maar toch ook javascript en C eigenlijk niet echt een goed analyseerbare AST kennen. Deze zijn dynamisch genoeg om een analyzer het leven zuur te maken. Ergo: de waarde van een IDE die je wel static analysis hints en refactorings geeft, is inherent lager dan talen als Java, C#, Dart,TypeScript en dergelijke. Perl kent wel een AST, maar die heeft zijn eigen problemen (met name complexiteit).

Dan snap ik wel dat je er een mening op nahoudt als code === text.

[Brent]

Ruudjah schreef op maandag 13 april 2015 @ 21:17:
[...]

Switching costs kunnen in potentie oplopen tot een complete rewrite en zelfs een compleet nieuw R&D traject. Als een lead devver core componenten onderhoud die alléén híj kan begrijpen omdat er oeverloze complexiteit is gebruikt, dan kan je niet zomaar een ander ervaren werknemer op die plek krijgen. Ik zou zelfs zover willen gaan dat het de klassieke interpretatie (een library/dienst/middleware leverancier als "vendor") zou kunnen overstijgen in kosten.

Dit is je reinste slippery slope fallacy. We hadden het wat over simpele tools.

[EfBe]

Ruudjah schreef op maandag 13 april 2015 @ 19:01:
[...]

Dat is inderdaad gewoon een vorm van een vendor-lockin.

Hoezo? Misschien heeft er maar 1 iemand kennis van bepaalde algoritmiek en kan de rest het gewoon niet.

[Lethalis]

Brent schreef op maandag 13 april 2015 @ 17:16:
[...]
Het doorhameren op vorm (die taal, die tools) zie ik vooral terug bij bedrijven in jouw straatje. Ik wilde slechts toevoegen dat er ook andere straatjes zijn, en als je dus niet van bepaalde talen of tooling houd zoals OP kun je eens in een ander straatje kijken.

Je hebt op zich gelijk, maar je ziet ook dat bepaalde technieken vooral in bepaalde sectoren populair zijn.

Python zie je vaak terug in de wetenschap en bij startups, terwijl Java / C# toch vooral corporate is zoals je zelf aangeeft. Mensen zoals ik, die bijvoorbeeld alleen HBO Informatica hebben gedaan, kunnen niet zomaar de wetenschap in (sterker nog, heb er eigenlijk niks te zoeken). En op dat moment kan ik het mij dus niet veroorloven om zo te denken.

Althans, dat idee heb ik. Correct me if I'm wrong

Ik ken ook iemand die bij de TU Delft werkt die Visual Basic 6 ( ) gebruikt om robotarmen aan te sturen. Maar ja, daar geldt dan ook: hij mag helemaal zelf weten hoe hij het doet, als het maar werkt. In zo'n situatie zou ik waarschijnlijk ook lekker Linux installeren en dan gewoon iets kiezen dat ik leuk vind (Java is dan wel makkelijk alsnog, vanwege de vele libraries.. maar goed, qua tooling kun je dan lekker vrij zijn verder).

Kortom: misschien zijn die andere straatjes wel onbereikbaar.

[Oljoner]

Megamind schreef op zaterdag 11 april 2015 @ 17:44:
[...]
Waar werk je (aan) als ik vragen mag? In mijn dev team sta ik het niet toe dat mensen maar hun eigen tooltjes gaan proberen, we gebruiken een standaard omgeving met standaard tools. Als iemand dan moet inspringen hoeft hij niet eerst 4 uur te kloten met vage tools waar die ene developer zo graag mee moet werken.

Ik ben, zoals meerderen hier, van mening dat sourcecode=sourcecode. Zolang je de code kunt uitchecken & het build out of the box, is het mij allemaal goed.
En dat is iets wat imo veel belangrijker is op team niveau: build automation & standard environments (met vb. vagrant/docker).
Het zou me echt niets kunnen interesseren welke tools de developers uiteindelijk gebruiken, zolang ze maar efficiënt kunnen werken in die omgevingen & de code buildable blijft voor andere developers.

Moest men mij opleggen met welke ide/editor ik zou moeten werken, zou ik toch gaan uitkijken naar vacatures..

Wat de talen of ecosystemen betreft, lijkt het me wel enigszins logisch dat een bedrijf of organisatie hierin een duidelijke keuze willen maken (omdat er bijvoorbeld goede tooling voor is), maar het zou nieuwe ontwikkelingen niet in de weg mogen staan.

Zelf werk ik in een java-shop, maar ben nu in een project bezig met groovy. Hier wordt nogal argwanend tegenop gekeken omdat men ooit beslist heeft dat "alles java moet zijn". Nuja, het project build met maven (groovy compiler is een plugin), dus uiteindelijk geen probleem.

Een keuze voor een taal zou ik ook niet enkel baseren op de tooling, maar ook op het licentiemodel, filosofie (open source ftw), ondersteuning (frabrikant die het tempo bepaalt?),..
Persoonlijk valt C# en .net hiervoor volledig af & zou er elke jobaanbod voor weigeren tenzij ze 15% meer loon bieden..

[Cloud]

R4gnax schreef op maandag 13 april 2015 @ 18:32:
[...]


Maar...

Kwam dit puur omdat jij allerlei eigen methodiek of tooling introduceerde? Of was dit ook omdat het de andere ontwikkelaars niet wisten (of erger: niet kon schelen) waar je mee bezig was? Of stiekem deels ook omdat jij op een heel ander denkniveau kon programmeren, waar sommige collega's bijv. maar amper de SOLID concepten konden begrijpen of toepassen?

Wellicht vooral het laatste, al probeerde ik dat voor zover als mogelijk te communiceren/uitleggen. Ze wisten uiteraard wel waar ik mee bezig was maar hadden het niet aan tijd zich erin te verdiepen. Ander probleem was dat nieuwe methodiek/tooling nodig was vanwege platform switches. Bedrijf maakte primair vooral ASP.net applicaties maar er moest ook een Windows Mobile app komen. En toen die er was, zou een Android app toch ook wel leuk zijn, etc. etc. Die denkwijze.

In de onschuldige gevallen, waarbij iemand dus niet bewust job security through obscurity pleegt, is het nog vaak die tweede of derde die echt ten grondslag ligt aan het probleem. Als jij met toegenomen kennis over tijd in een rol als specialist op een bepaald gebied beland en daar vervolgens proces- of architectuur-verbeteringen in gaat spearheaden, maar je collega's daar niet in mee kunnen komen of zich over willen informeren; wiens fout is dat dan?

(Ik zou eerlijk gezegd zeggen dat het dan meer een communicatieprobleem is met een gebrek aan kennisoverdracht.)

Dat laatste was het uiteraard maar vooral ook het bedrijf dat teveel verschillende dingen tegelijkertijd wilde doen terwijl de uren en kennis er gewoon niet waren. De tijd was er niet om dingen uitvoerig aan elkaar uit te leggen omdat er productie gedraaid moest worden. De bestaande klanten van de webapps moesten al te lang wachten op bugfixes/features omdat alle tijd zat in nieuwe dingen bouwen. Laat staan dat je dan ook nog tijd vrij maakt om elkaar dingen uit te kunnen leggen..

[roy-t]

Schnupperpuppe schreef op vrijdag 10 april 2015 @ 19:56:
[...]


Wees nou eens eerlijk. Waar is een developer nou de meeste tijd mee kwijt. Editen.
Refactoring, leuk, maar dat hoef ik echt niet in mijn editor te hebben. Daar gebruik ik dan wel refactoring tools voor.
Ik ken geen enkele IDE met een editor die ook maar in de buurt komt van Vim.
IDE: Jack of all trades, master of none.

Ik moest hier echt ontzettend om lachen! Een editor is juist de jack of all trades, immers is deze niet met het specifieke doel gemaakt om (1) taal aan te passen, maar juist om een zo divers mogelijke type bestanden aan te passen. De IDE is juist de hyper specifieke variant waar alles gericht is op het ontwikkelen van een programma in 1 bepaalde taal.

Anyway, niet om een dood paard nog verder dood te maken, ik kan me gewoon echt niet voorstellen dat mensen een editor over een IDE preferren voor projecten van meer dan 1000 regels code (of zoiets). Een fatsoenlijke debugger, watch windows, expressies kunnen evalueren terwijl het programma draait. Refactoring (er wordt hier beweerd dat dat niet telt, want meestal ben je gewoon aan het typen. Toch vind ik het super handig als ik even CTRL+R+R kan doen om een variabele te hernoemen zonder alle replaces te checken of ik niet met "myBook" -> "myLiterature" ook "myBookstore" naar myLiteratureStore" verander en daardoor alles breek .

Ook het logging verhaal snap ik niet. Natuurlijk gebruik ik logging, dat is leuk om de staat van de applicatie te zien zonder (inderaad) invasief te debuggen. Maar volgens mij is de workflow met logging als volgt.

Hey, er is een bug in module X. Dat zou te maken kunnen hebben met de waarde van Variabele Y. Laat ik die even loggen. Restart. Oh shit, Y was het niet. Hmm laat ik dan ook maar Z U V W loggen. Ah het was W, even fixen!

Terwijl de workflow met debugger het volgende is.

Hey, er is een bug in module X. Even een breakpoint neer zetten in de buurt van Variabele Y. Oh shit, Y was het niet, even wat is de waarde van Z U V W? Ah! Kan ik meteen zien, het was W, even fixen!

Dat scheelt toch elke keer weer 2 minuten?


Ik heb tot nu toe op iets van vijf plekken gewerkt (ik ben nog jong ) en daar wordt overal een IDE gebruikt. Man daar wordt zelfs grof geld voor neer gelegd omdat zelfs de managers vinden dat programmeurs niet zonder kunnen. (Op sommige plekken zelfs wel 6000,- p.j. voor een stuk software, nee niet eenmalig 200,- voor een tweede beeldscherm )

[Lethalis]

roy-t schreef op dinsdag 14 april 2015 @ 10:20:
[...]
Ook het logging verhaal snap ik niet. Natuurlijk gebruik ik logging, dat is leuk om de staat van de applicatie te zien zonder (inderaad) invasief te debuggen. Maar volgens mij is de workflow met logging als volgt.

Hey, er is een bug in module X. Dat zou te maken kunnen hebben met de waarde van Variabele Y. Laat ik die even loggen. Restart. Oh shit, Y was het niet. Hmm laat ik dan ook maar Z U V W loggen. Ah het was W, even fixen!

Terwijl de workflow met debugger het volgende is.

Hey, er is een bug in module X. Even een breakpoint neer zetten in de buurt van Variabele Y. Oh shit, Y was het niet, even wat is de waarde van Z U V W? Ah! Kan ik meteen zien, het was W, even fixen!

Dat scheelt toch elke keer weer 2 minuten?

Amen.

Ik heb daarnet nog een bug opgelost die vrij moeilijk te vinden was. Zonder conditional breakpoints was het echt een crime geweest om die te vinden (de bug kwam alleen voor in een bepaald stukje code onder bepaalde omstandigheden).

[ Voor 3% gewijzigd door Lethalis op 14-04-2015 10:58 ]

[EfBe]

Lethalis schreef op dinsdag 14 april 2015 @ 09:04:
[...]
Python zie je vaak terug in de wetenschap en bij startups, terwijl Java / C# toch vooral corporate is zoals je zelf aangeeft. Mensen zoals ik, die bijvoorbeeld alleen HBO Informatica hebben gedaan, kunnen niet zomaar de wetenschap in (sterker nog, heb er eigenlijk niks te zoeken). En op dat moment kan ik het mij dus niet veroorloven om zo te denken.
Althans, dat idee heb ik. Correct me if I'm wrong

Wrong . HBO informatica is ook B.sc, het is alleen niet een M.sc, en je mist initieel kennis, maar dat is niet hetzelfde als wijsheid. Een 'universitair werk- en denkniveau' is niet iets wat je leert op de universiteit, je hebt het of niet. Jezelf niet zo naar beneden halen, is nergens voor nodig. Het is immers zo dat wanneer jij zelf onderzoek doet en daarover een wetenschappelijk geaccepteerd boek over schrijft men je laat promoveren. Je hebt dan immers laten zien dat je kunt wat vereist is. Niet veel mensen nemen die moeite overigens, want wetenschappelijk onderzoek vereist dat je je jarenlang focust op een klein aspect van het vakgebied.

Een HBO informatica opleiding kan meer gericht zijn op de 'praktijk' als in 'je leert vaardigheden die nodig zijn voor het maken van software', maar dat doet tegenwoordig een M.sc op de universiteit feitelijk ook. Ik zou me er niet zo druk om maken. Wat wel vereist is is dat je je blijft ontwikkelen, en dan met de vaardigheden die je geleerd hebt op het HBO: leer de vakkennis achter een techniek, niet de techniek zelf, dat is een toepassing. Val je terug op truukjes leren dan zul je niet verder komen qua kennis en wijsheid.

(bron: HBO informatica (HIO enschede), 20+ jaar werkervaring)

Ik ken ook iemand die bij de TU Delft werkt die Visual Basic 6 ( ) gebruikt om robotarmen aan te sturen. Maar ja, daar geldt dan ook: hij mag helemaal zelf weten hoe hij het doet, als het maar werkt. In zo'n situatie zou ik waarschijnlijk ook lekker Linux installeren en dan gewoon iets kiezen dat ik leuk vind (Java is dan wel makkelijk alsnog, vanwege de vele libraries.. maar goed, qua tooling kun je dan lekker vrij zijn verder).

Je voorbeeld geeft goed aan dat tooling precies is wat het woord zegt: hulpmiddelen. X willen bereiken en daarvoor een tool T gebruiken maakt niet dat je werk inhoudt dat je 'T doet', maar dat je X wilt bereiken. Lekker boeiend dat die persoon in VB6 moet werken, dat is niet wat hij aan het doen is, hij doet onderzoek op het gebied van robotica.

Wat wel boeit is of er tooling is. Zonder tooling wordt het onderzoek, of wat algemener, het bereiken van X lastiger. Wellicht te lastig. Op het gebied van onderzoek is dat dan een onderdeel van je onderzoeksresultaten. Op het gebied van softwarebouw is het wellicht noodzaak andere wegen te bewandelen die je indirect toch bij X brengen. Er zijn tegenwoordig zelden geen alternatieven voor iets. Voorbeeld: niet voor 'Go' kiezen ivm de belabberede debug situatie kan, er zijn alternatieven zat met betere tooling.

[Lethalis]

EfBe schreef op woensdag 15 april 2015 @ 08:28:
[...]
Wat wel vereist is is dat je je blijft ontwikkelen, en dan met de vaardigheden die je geleerd hebt op het HBO: leer de vakkennis achter een techniek, niet de techniek zelf, dat is een toepassing. Val je terug op truukjes leren dan zul je niet verder komen qua kennis en wijsheid.

Ik begrijp dat dit de pragmatische insteek is. Maar heb jij dan nooit dat het werken ook leuker wordt met betere tooling?

Eerst wou ik hier een hele rant over ASP.Net vNext neerzetten bijvoorbeeld, maar door puur toeval kwam ik erachter dat jij er ook niet heel blij mee bent ( http://www.itwriting.com/...nt-page-1#comment-3625771 ).

Persoonlijk verlies ik steeds meer het vertrouwen in .Net. Microsoft maakt er elke keer een potje van, terwijl C# echt een fijne taal is verder.

Dan kan ik aan de ene kant wel denken "het is maar een tool", aan de andere kant is het wel een stuk gereedschap dat me steeds meer tegenstaat. Als Windows 10 straks flopt, of bedrijven simpelweg geen zin hebben om universal apps te schrijven, wat dan? Is .NET 4.5 met Windows Forms en WPF zometeen het nieuwe VB6? In de steek gelaten door Microsoft, maar nog volop in gebruik.

Behalve Java zie ik echter ook geen echte alternatieven nog. Scala begon leuk, maar staat ook voor een language rethink. Go, tsja, het is erg praktisch, maar mist ook een hoop. Kotlin, Ceylon, etc.. moeten we allemaal maar afwachten (cute, not there yet).

In ieder geval heeft Java wel erg uitgebreide tooling en libraries.

[InZane]

Lethalis schreef op donderdag 16 april 2015 @ 11:35:
Als Windows 10 straks flopt, of bedrijven simpelweg geen zin hebben om universal apps te schrijven, wat dan? Is .NET 4.5 met Windows Forms en WPF zometeen het nieuwe VB6? In de steek gelaten door Microsoft, maar nog volop in gebruik.

Ik snap eigenlijk niet zo goed wat Windows 10 en Universal Apps met Windows Forms en WPF te maken hebben. Sowieso zijn, in mijn ogen, WF en WPF op een heel ander soort publiek gericht.

[Lethalis]

InZane schreef op donderdag 16 april 2015 @ 12:50:
[...]


Ik snap eigenlijk niet zo goed wat Windows 10 en Universal Apps met Windows Forms en WPF te maken hebben. Sowieso zijn, in mijn ogen, WF en WPF op een heel ander soort publiek gericht.

Windows Forms en WPF worden voorlopig niet geport naar .NET 5 (en zijn ook niet open source), terwijl Microsoft .NET 5 wel aanprijst als het nieuwe platform waar straks alle aandacht naar uitgaat.

Persoonlijk had ik veel liever gezien dat het bestaande framework simpelweg de aandacht krijgt die het verdient. Zo zou je veel uitgebreidere databinding in Windows Forms kunnen bouwen (MVVM anyone?), of WPF dermate uitbreiden dat het echt als opvolger van Windows Forms kan dienen.

Maar elke keer wordt er iets in het leven geroepen, en daarna krijgt het geen aandacht meer. Ze lijken bijna op Google

[ Voor 32% gewijzigd door Lethalis op 16-04-2015 13:10 ]

[Cloud]

Waarom zou je dan nog WPF verbeteringen aanbrengen in Framework 4.6 en de WPF editor in VS2015 nog een flinke update geven, als je toch niet van plan bent om WPF aan te houden? Ik denk dat het allemaal wel wat mee zal vallen

Je vergelijking met Google gaat wat dat betreft wel heel ver hoor Google maakt er wat dat betreft echt een potje van, al is dat voornamelijk op applicatie niveau en niet op framework niveau.

[Lethalis]

Cloud schreef op donderdag 16 april 2015 @ 13:14:
Waarom zou je dan nog WPF verbeteringen aanbrengen in Framework 4.6 en de WPF editor in VS2015 nog een flinke update geven, als je toch niet van plan bent om WPF aan te houden? Ik denk dat het allemaal wel wat mee zal vallen

Het meest toffe zou zijn als WPF ook open source zou worden en het ook op .NET 5 zou werken. Gewoon als een framework dat ook in de toekomst nog volop gebruikt zal worden.

Nu moet je maar afwachten wat ermee gebeurt.

Je vergelijking met Google gaat wat dat betreft wel heel ver hoor Google maakt er wat dat betreft echt een potje van, al is dat voornamelijk op applicatie niveau en niet op framework niveau.

AngularJS 2.0

[Cloud]

Lethalis schreef op donderdag 16 april 2015 @ 13:21:
[...]
Het meest toffe zou zijn als WPF ook open source zou worden en het ook op .NET 5 zou werken. Gewoon als een framework dat ook in de toekomst nog volop gebruikt zal worden.

Nu moet je maar afwachten wat ermee gebeurt.

Ben ik met je eens, maar er is (voor mij) nog geen reden om negatief te zijn. Als je ziet wat MS qua open sourcing het afgelopen jaar gedaan heeft, petje af hoor. Ze hebben ook aangegeven dat sommige dingen gewoon meer tijd nodig hebben dan andere.

Ik ben vooralsnog positief

[...]

AngularJS 2.0

Oké true Ik ben geen webdevver dus dat soort dingen gaan wat langs mij heen.

[Lethalis]

Cloud schreef op donderdag 16 april 2015 @ 13:26:
[...]

Ben ik met je eens, maar er is (voor mij) nog geen reden om negatief te zijn. Als je ziet wat MS qua open sourcing het afgelopen jaar gedaan heeft, petje af hoor. Ze hebben ook aangegeven dat sommige dingen gewoon meer tijd nodig hebben dan andere.

Ik ben vooralsnog positief

Ja het kan ook gewoon een marketing blunder zijn. In die zin dat ze gewoon te graag met iets nieuws willen komen nu en dat het nog lang niet af of volledig is.. maar ik vrees het ergste gezien WPF op diverse diagrammen simpelweg op de .NET 4.5 kant staat en effectief dood is. Misschien moeten we ook onder ogen zien dat web(api) development sinds de opkomst van HTML5 en de vele JavaScript frameworks gewoon de toekomst is.

Het biedt immers steeds meer voordelen. Een goede HTML5 webapplicatie met responsive design werkt bijna overal en doet qua ervaring allang niet meer onder voor een Windows applicatie (het is eerder andersom nu).

Het grote voordeel van het open sourcen is wel dat er nu meer libraries zullen komen. Zelf kijk ik al naar NancyFX bijvoorbeeld (als alternatief voor Asp.net MVC).

En ander probleem waar Microsoft nu mee te maken krijgt: Asp.net ontwikkeling wordt steeds minder Asp.net en steeds meer HTML5 en JavaScript. De rol van Microsoft wordt steeds kleiner en het wordt steeds eenvoudiger om voor iets anders te kiezen (dat eventueel gratis / goedkoper is).

Dus wat we nu zien bij Microsoft is misschien gewoon onvermijdelijk. Ze volgen de markt in plaats van dat ze hem bepalen. De boel open sourcen wordt door Microsoft misschien ook wel als pure noodzaak gezien om nog developer mind share binnen te houden. Er zijn namelijk relatief weinig startups die aan de Microsoft stack denken en daar zitten wel de ervaren developers van de toekomst. Als die nu voor iets anders kiezen, dan wordt dat na 5 jaar de standaard en niet de MS stack.

Dit zijn zorgen die mensen als Scott Hanselman weleens uiten op hun blog.. die heeft het dan over de zogenaamde "greenfield developers".

[ Voor 51% gewijzigd door Lethalis op 16-04-2015 15:40 ]

[AlphaRomeo]

Lethalis schreef op donderdag 16 april 2015 @ 13:02:
[...]
Windows Forms en WPF worden voorlopig niet geport naar .NET 5 (en zijn ook niet open source), terwijl Microsoft .NET 5 wel aanprijst als het nieuwe platform waar straks alle aandacht naar uitgaat.

Heb je hier een bron voor? Alles wat ik kan vinden is dat het volgende .NET framework 4.6 gaat heten en dat daar WPF gewoon in blijft zitten: MSDN: What's New in the .NET Framework.

Bedoel je .NET core 2015? Die is inderdaad onder open source vrijgegeven (MIT License):
http://blogs.msdn.com/b/d...ew-a-new-era-for-net.aspx

[Lethalis]

http://blogs.msdn.com/b/d...introducing-net-core.aspx

Daar staat dat .Net core voor alles in de toekomst wordt gebruikt.. "It forms the future of all .Net verticals".

In hetzelfde bericht zie je ook het diagram dat ik bedoel.

Er wordt echter met geen woord gerept over de toekomst van WPF.. Gaan ze het porten naar .net core? Of is het jammer maar helaas.. En zien ze WinRT met universal apps als de vervanger?

[ Voor 26% gewijzigd door Lethalis op 16-04-2015 19:59 ]

[InZane]

Er staat in dat artikel ook dat .NET Core een subset is van het .NET Framework. Het is niet zo dat Core een vervanging is van het .NET Framework. Ook geldt dat .NET Core != .NET 5.

[Lethalis]

http://pragmateek.com/is-...resent-and-future-of-wpf/

Ik denk dat deze auteur het bij het juiste eind heeft. Hoe vervelend WinForms en WPF liefhebbers het ook vinden.

[Lethalis]

InZane schreef op donderdag 16 april 2015 @ 20:01:
Er staat in dat artikel ook dat .NET Core een subset is van het .NET Framework. Het is niet zo dat Core een vervanging is van het .NET Framework. Ook geldt dat .NET Core != .NET 5.

In het artikel staat uitvoerig beschreven welke problemen Microsoft heeft met het huidige framework. .Net Core is modulair en veel eenvoudiger om in de toekomst nieuwe features voor te ontwikkelen. Doordat .Net Core applicaties een eigen kopie van libraries meedistribueren, is backwards compatibility ook een minder groot issue dan nu.

Direct gevolg hiervan is dat .Net Core als eerste alle nieuwe features krijgt. En dat het bestaande .Net framework ze alleen krijgt na een kosten/baten analyse van Microsoft.

De enige manier waarop WPF zal overleven is als het ook naar .Net Core wordt geport. Probleem daarmee is echter dat het een complex framework is met enorm veel dependencies die niet in .Net Core zitten.

Wat zal de kosten/baten analyse dan zijn?

[EfBe]

Lethalis schreef op donderdag 16 april 2015 @ 19:40:
http://blogs.msdn.com/b/d...introducing-net-core.aspx
Daar staat dat .Net core voor alles in de toekomst wordt gebruikt.. "It forms the future of all .Net verticals".
In hetzelfde bericht zie je ook het diagram dat ik bedoel.
Er wordt echter met geen woord gerept over de toekomst van WPF.. Gaan ze het porten naar .net core? Of is het jammer maar helaas.. En zien ze WinRT met universal apps als de vervanger?

Dat is precies het punt waar ik over struikelde: https://weblogs.asp.net/f...%E2%80%99s-future-is-that Je houdt een hele lange tijd .NET full en .NET core naast elkaar, en het is onduidelijk wanneer (of beter: of het uberhaupt) de .NET core stack het gaat overnemen van .NET full. Verschillende .NET managers hebben me verzekerd dat .NET core nodig was omdat de code in .NET full niet meer te maintainen was (hun letterlijke woorden) en ze een 'reboot' nodig hadden en het de enige manier was om .NET een toekomst te geven.

Mij zegt het alleen maar dat .NET core de .NET versie is waar ze hun toekomstige zaken op bouwen (dus incl. universal apps en web) en .NET full, die backports krijgt van core erbij wordt geleverd maar niet de hoofdzaak is voor de toekomst. Ikzelf denk dat ze niet wijs zijn en schepen verbranden die ze nodig hebben, maar goed.

Wat betreft WPF: ze doen wel stoer, maar de progressie daarin is marginaal. De roadmap die ze hebben laten zien is er een van een stagiair. Is ook niet zo vreemd, xaml's nu voornamelijk van belang voor universal apps, niet voor wpf.

Ik begrijp ook niet goed waarom .NET core zo nodig op linux en mac moet draaien. Het lijkt alsof ze dolgraag de developers die weg zijn gegaan en nu node gebruiken terug willen winnen. Maar die krijgen ze nooit meer terug, die zijn niet voor niets weg. Ze kunnen zich beter focusen op wat de devs die nog op .net zitten nodig hebben.

[ Voor 9% gewijzigd door EfBe op 17-04-2015 08:27 ]

[Lethalis]

EfBe schreef op vrijdag 17 april 2015 @ 08:25:
[...]
Ik begrijp ook niet goed waarom .NET core zo nodig op linux en mac moet draaien. Het lijkt alsof ze dolgraag de developers die weg zijn gegaan en nu node gebruiken terug willen winnen. Maar die krijgen ze nooit meer terug, die zijn niet voor niets weg. Ze kunnen zich beter focusen op wat de devs die nog op .net zitten nodig hebben.

Linux en de Mac zijn razend populair bij jonge ontwikkelaars. Kijk naar de gemiddelde developer conference - zelfs bij Microsoft - en bijna iedereen loopt rond met een MacBook Pro. Microsoft is heel bang dat ze de boot missen. En dan gaat het ze duidelijk niet om de programmeurs van nu, maar die van de toekomst.

Ik begrijp op zich wel waarom ze bepaalde dingen doen, maar ik vind de manier waarop om te huilen.

Als je kijkt naar Java bijvoorbeeld, daar hebben ze hetzelfde probleem: de JVM en JDK is een grote monolithische puinhoop. Daar moet project Jigsaw verandering in brengen. Java 9 gaat modulair worden.

Dus zijn ze bij Oracle al jaren bezig om alle libraries zo in te richten dat ze een duidelijke dependency structuur hebben. De spaghetti aan het ontwarren zeg maar. Daar zijn ze de afgelopen jaren al behoorlijk ver mee gekomen en met de volgende release wordt de boel dus echt modulair. En het mooie is: alles blijft werken. De Java 8 SDK is al vele malen "opgeruimder" dan Java 7.

Heb je geinvesteerd in JSF of andere EE libraries? Bouw je client applicaties met Swing of ben je wat avontuurlijker bezig met JavaFX? Er wordt nog steeds aan gewerkt. Sterker nog, je kunt zelfs JavaFX op een Android telefoon draaien.

Er wordt niet gezegd van "oh laten we de hele boel wegpleuren en opnieuw beginnen".

Dat vind ik een heel sterk argument voor het kiezen van Java. Het is natuurlijk ook meteen het nadeel ervan. Als ik met Java aan het programmeren ben, voelt het nog steeds als het jaar 1999. Er zijn geen coole type inference features, automatic properties (ueberhaupt geen properties ), verbose exception handling, enzovoorts. Java 8 heeft dan iig nog lambda's geintroduceerd. En die gebruiken dan ook meteen een minder data georienteerde en juist FP trouwere syntax dan LINQ.

Maar ja, het werkt wel. En het werkt veel sneller dan 10 jaar geleden. De JVM is enorm geoptimaliseerd.

Daarom denk ik ook dat een modernere taal die de JVM target, zomaar eens de toekomst kan hebben. Scala was mijn persoonlijke favoriet, maar probeerde zoveel dingen tegelijk op te lossen dat het niet meer praktisch werd (dat zien ze ook in, dus er is nog hoop). Maar wie weet wat een Kotlin (van JetBrains) bijvoorbeeld gaat doen (en daar kun je dan gewoon weer alles mee.. zelfs Swing applicaties bouwen, want het blijft op de JVM draaien).

Ik ben nu al bijna een jaar aan het twijfelen .NET developer by day, Java developer by night Het zou me niet verbazen als ik op een dag gewoon helemaal switch.

En er zijn genoeg mensen die mij dan voor gek verklaren, want die hebben vooral het Java van 10 jaar geleden gezien en zijn toen heel snel overgestapt op .NET. Maar Java stond al die tijd niet stil en de frameworks er omheen al helemaal niet.

Als ik een web applicatie met Spring MVC bouw dan zit dat zoveel mooier in elkaar dan met Asp.net.. de scheiding tussen een web container en een applicatie is ook erg fijn. Via JNDI lookups kan ik allerlei configuratiewaarden ophalen. Geen web.config die op elke server anders is. Ik gooi gewoon de WAR op de server en het werkt. Fire and forget.

Dependency injection die gewoon in het framework zit en aspect oriented werkt. Ga zo maar door.

Het leren van Java en vooral de frameworks er omheen was voor mij een scary experience. Ik ging .Net in een heel ander licht zien. Het .Net waar ik al bijna 12 jaar mijn brood mee verdien

Microsoft wil heel graag dat diezelfde mensen die mooie open source frameworks als het Spring framework of het Play framework hebben gemaakt, dat ook voor .NET gaan doen. Scheelt Microsoft ook een hoop geld (hoeven ze het zelf niet meer te doen).

Dus gaan ze nu op de open source tour en moet het op Linux en de Mac werken. Anders gaan ze die developer mindshare nooit krijgen.

[Merethil]

Lethalis schreef op vrijdag 17 april 2015 @ 09:22:
[...]

Linux en de Mac zijn razend populair bij jonge ontwikkelaars. Kijk naar de gemiddelde developer conference - zelfs bij Microsoft - en bijna iedereen loopt rond met een MacBook Pro. Microsoft is heel bang dat ze de boot missen. En dan gaat het ze duidelijk niet om de programmeurs van nu, maar die van de toekomst.

Ik begrijp op zich wel waarom ze bepaalde dingen doen, maar ik vind de manier waarop om te huilen.

Als je kijkt naar Java bijvoorbeeld, daar hebben ze hetzelfde probleem: de JVM en JDK is een grote monolithische puinhoop. Daar moet project Jigsaw verandering in brengen. Java 9 gaat modulair worden.

Dus zijn ze bij Oracle al jaren bezig om alle libraries zo in te richten dat ze een duidelijke dependency structuur hebben. De spaghetti aan het ontwarren zeg maar. Daar zijn ze de afgelopen jaren al behoorlijk ver mee gekomen en met de volgende release wordt de boel dus echt modulair. En het mooie is: alles blijft werken. De Java 8 SDK is al vele malen "opgeruimder" dan Java 7.

Heb je geinvesteerd in JSF of andere EE libraries? Bouw je client applicaties met Swing of ben je wat avontuurlijker bezig met JavaFX? Er wordt nog steeds aan gewerkt. Sterker nog, je kunt zelfs JavaFX op een Android telefoon draaien.

Er wordt niet gezegd van "oh laten we de hele boel wegpleuren en opnieuw beginnen".

Dat vind ik een heel sterk argument voor het kiezen van Java. Het is natuurlijk ook meteen het nadeel ervan. Als ik met Java aan het programmeren ben, voelt het nog steeds als het jaar 1999. Er zijn geen coole type inference features, automatic properties (ueberhaupt geen properties ), verbose exception handling, enzovoorts.

Maar ja, het werkt wel. En het werkt veel sneller dan 10 jaar geleden. De JVM is enorm geoptimaliseerd.

Daarom denk ik ook dat een modernere taal die de JVM target, zomaar eens de toekomst kan hebben. Scala was mijn persoonlijke favoriet, maar probeerde zoveel dingen tegelijk op te lossen dat het niet meer praktisch werd (dat zien ze ook in, dus er is nog hoop). Maar wie weet wat een Kotlin (van JetBrains) bijvoorbeeld gaat doen (en daar kun je dan gewoon weer alles mee.. zelfs Swing applicaties bouwen, want het blijft op de JVM draaien).

Ik ben nu al bijna een jaar aan het twijfelen .NET developer by day, Java developer by night Het zou me niet verbazen als ik op een dag gewoon helemaal switch.

En er zijn genoeg mensen die mij dan voor gek verklaren, want die hebben vooral het Java van 10 jaar geleden gezien en zijn toen heel snel overgestapt op .NET. Maar Java stond al die tijd niet stil en de frameworks er omheen al helemaal niet.

Als ik een web applicatie met Spring MVC bouw dan zit dat zoveel mooier in elkaar dan met Asp.net.. de scheiding tussen een web container en een applicatie is ook erg fijn. Via JNDI lookups kan ik allerlei configuratiewaarden ophalen. Geen web.config die op elke server anders is. Ik gooi gewoon de WAR op de server en het werkt. Fire and forget.

Dependency injection die gewoon in het framework zit en aspect oriented werkt. Ga zo maar door.

Het leren van Java en vooral de frameworks er omheen was voor mij een scary experience. Ik ging .Net in een heel ander licht zien. Het .Net waar ik al bijna 12 jaar mijn brood mee verdien

Microsoft wil heel graag dat diezelfde mensen die mooie open source frameworks als het Spring framework of het Play framework hebben gemaakt, dat ook voor .NET gaan doen. Scheelt Microsoft ook een hoop geld (hoeven ze het zelf niet meer te doen).

Dus gaan ze nu op de open source tour en moet het op Linux en de Mac werken. Anders gaan ze die developer mindshare nooit krijgen.

Ik heb een tijd gewenst dat ik .NET developer kon worden, gezien sommige dingen waar ik dagelijks tegenaan loop zoveel fijner worden opgelost. Alleen al zaken als ORM's, Exception handling, opruimen van streams en andere memory-intensive business.
Echter, sinds ik begon bij het bedrijf waar ik nu werk, waar we java full stack gebruiken (Spring Framework, Hibernate als ORM, JAXB en alle zooi die meegeleverd wordt) ben ik begonnen met het waarderen van de snelheid (ja, snelheid!) van Java en vooral de toegankelijke programmeertaal.

Omdat ik Hibernate niets vind voor mijn eigen tools ben ik OrmLite gaan gebruiken. Echter, omdat ik die weer wat te basaal vind, ben ik mijn eigen ORM gaan schrijven. De reflection API van Java is eigenlijk heel netjes opgezet en werkt naar mijn mening vlekkeloos als je weet wat je doet, om maar een voorbeeld te noemen.

Gezien hoe makkelijk het is om een webservice/website te bouwen in Java, hoe snel deze is vergeleken met PHP onder versie 5.5 (daarboven heb ik geen benchmarks gezien), Ruby, Node.JS of python, en hoe makkelijk de programmeertaal te leren is, merk ik dat ik niet veel anders meer wil.
Mensen roepen vaak dat Java slecht is vanwege de applets, maar als je alles bekijkt wat niet een applet is, heb je een hele solide programmeertaal met voldoende jars die overal te vinden zijn op 't web en genoeg web containers (Glassfish, Tomcat, JBoss etc.etc.) om alles in te draaien.

En natuurlijk mis ik zaken als goed geimplementeerde lambda's, makkelijk te creeëren getters en setters en zelfs de kleine dingen als een tryParse op een Integer, in plaats van steeds zelf je try-catch om een parseInt heen te zetten. Maar al met al is Java zeker geen taal die echt achterloopt: Ze lopen op een ander tempo, maar bepaalde zaken zijn gewoon veel beter uitgedacht en geimplementeerd dan bij de counterparts.

[Lethalis]

Merethil schreef op vrijdag 17 april 2015 @ 09:41:
[...]
Ik heb een tijd gewenst dat ik .NET developer kon worden, gezien sommige dingen waar ik dagelijks tegenaan loop zoveel fijner worden opgelost. Alleen al zaken als ORM's, Exception handling, opruimen van streams en andere memory-intensive business.

Ik vind het wel lachen dat je over ORM's begint. Als er iets ****** is, dan is het wel het Entity Framework

Zelf gebruik ik nHibernate

Ik hou namelijk van code, maar niet zo van code first. Vaak werk ik namelijk met bestaande SQL server databases, maar het laatste dat ik wil zijn allemaal complexe designer files om ermee te praten. Ik wil gewoon een simpele klassenstructuur met enkele mapping files. En nHibernate doet precies dat. Bij code first EF ben ik een half uur bezig om alles uit te zetten zodat het niet zelf ineens tabellen gaat zitten aanmaken etc Om ook maar niet over pluralization te beginnen. "Klants" etc Ik hou daar niet van. Ik ben meer klassiek geschoold; relaties in een database hebben bij mij enkelvoudige benamingen, dus "Klant" en niet "Klanten" en al helemaal niet "Klants"

[Merethil]

Lethalis schreef op vrijdag 17 april 2015 @ 09:59:
[...]

Ik vind het wel lachen dat je over ORM's begint. Als er iets ****** is, dan is het wel het Entity Framework

Zelf gebruik ik nHibernate

Ik hou namelijk van code, maar niet zo van code first. Vaak werk ik namelijk met bestaande SQL server databases, maar het laatste dat ik wil zijn allemaal complexe designer files om ermee te praten. Ik wil gewoon een simpele klassenstructuur met enkele mapping files. En nHibernate doet precies dat. Bij code first EF ben ik een half uur bezig om alles uit te zetten zodat het niet zelf ineens tabellen gaat zitten aanmaken etc Om ook maar niet over pluralization te beginnen. "Klants" etc Ik hou daar niet van. Ik ben meer klassiek geschoold; relaties in een database hebben bij mij enkelvoudige benamingen, dus "Klant" en niet "Klanten" en al helemaal niet "Klants"

Ik ben erg gecharmeerd van LLBLGen (Hi Efbe! ) en NHibernate bij .NET, maar EF vind ik fijn werken voor snel een klein hobbyprojectje opzetten. Echter, Hibernate voor Java is bijzonder irritant gezien de hoeveelheid instellingen die je moet doen en alle mappingfiles, cfg.xml files en andere rotzooi die je moet hebben. Het werkt ook wel met annotations, maar daar ben ik ook niet helemaal van.
Het ORM dat ik zelf schrijf heeft één XML-mapping file per database en zal een generator erbij hebben om je models en je mapping file direct vanuit de DB te genereren naar simpele .java files, die je dan weer kan extenden.

Ik merk dat er een hoop ORM's zijn voor Java die allemaal exact hetzelfde werken, maar allemaal werken ze met ingewikkelde mappings en onhandige installaties. Een drop-in .jar met ondersteuning voor een simpele XML die je zelf opgeeft in je constructor is er niet bij. In dat opzicht vind ik dat EF een hoop minder onderhoud nodig heeft en derhalve vond ik EF aan het begin een stuk fijner en makkelijker. Echter, het is ook een pak trager

[Cloud]

Lethalis schreef op donderdag 16 april 2015 @ 20:29:
http://pragmateek.com/is-...resent-and-future-of-wpf/

Ik denk dat deze auteur het bij het juiste eind heeft. Hoe vervelend WinForms en WPF liefhebbers het ook vinden.

Ik vind het een goed verhaal met een aantal zorgwekkende punten maar de conclusie is wel wat anders dan jij hier schetst toch? Zeker het stuk vanaf 'Still a development effort [Update 2014-11]' t/m de conclusie geeft hij een aantal redenen waarom het toch niet zo slecht is als initieel gedacht.

Hij zegt dat WPF in de toekomst een strijd aan zal moeten gaan met WinRT en dat afhankelijk van het succes van WinRT in de toekomst WPF wel af zou kunnen vallen. Ik lees niet in zijn verhaal dat het nú al dood is en de ontwikkeling eraan nu stopt. De toekomst zal het uit moeten wijzen en dat is geheel logisch; niets is voor altijd.

Ik deel zijn en jouw zorgen maar ik zie het nog steeds niet zo somber in

[Lethalis]

Merethil schreef op vrijdag 17 april 2015 @ 10:05:
[...]
Ik ben erg gecharmeerd van LLBLGen (Hi Efbe! ) en NHibernate bij .NET, maar EF vind ik fijn werken voor snel een klein hobbyprojectje opzetten. Echter, Hibernate voor Java is bijzonder irritant gezien de hoeveelheid instellingen die je moet doen en alle mappingfiles, cfg.xml files en andere rotzooi die je moet hebben. Het werkt ook wel met annotations, maar daar ben ik ook niet helemaal van.
Het ORM dat ik zelf schrijf heeft één XML-mapping file per database en zal een generator erbij hebben om je models en je mapping file direct vanuit de DB te genereren naar simpele .java files, die je dan weer kan extenden.

Tsja, ik werk vooral aan grote projecten. Databases met 100 tabellen zijn eerder de regel dan uitzondering. Dus ik vind het fijn om een structuur te hebben die zo los mogelijk is en die het toelaat dat meerdere ontwikkelaars tegelijkertijd aan hetzelfde project kunnen werken.

Het laatste dat ik wil, is 1 mapping file dus Net zoals dat ik een schurfthekel aan Visual Studio project files heb (hoe moeilijk kan het zijn om directory wildcards toe te voegen, zodat we niet elke keer hoeven te mergen als iemand een bestandje toevoegt ).

De dingen die jij onhandig vindt, verwelkom ik dus juist. Iets meer configuratie, maar wel alle flexibiliteit van de wereld. En dat waardeer ik juist aan (n)Hibernate

[Merethil]

Lethalis schreef op vrijdag 17 april 2015 @ 10:10:
[...]

Tsja, ik werk vooral aan grote projecten. Databases met 100 tabellen zijn eerder de regel dan uitzondering. Dus ik vind het fijn om een structuur te hebben die zo los mogelijk is en die het toelaat dat meerdere ontwikkelaars tegelijkertijd aan hetzelfde project kunnen werken.

Het laatste dat ik wil, is 1 mapping file dus Net zoals dat ik een schurfthekel aan Visual Studio project files heb (hoe moeilijk kan het zijn om wildcards toe te voegen, zodat we niet elke keer hoeven te mergen als iemand een bestandje toevoegt ).

De dingen die jij onhandig vindt, verwelkom ik dus juist. Iets meer configuratie, maar wel alle flexibiliteit van de wereld. En dat waardeer ik juist aan (n)Hibernate

Het onhandigst aan de talloze mappingfiles vind ik dus dat je geen mooie generators of wat dan ook hebt om de boel makkelijk en snel te laten maken vanuit de DB. Als ik een ORM heb, wil ik dat het ding alles voor me doet en ik niet zelf de helft moet gaan bouwen voor simpele CRUD.

De enkele mappingfile slaat natuurlijk wel alleen op een opbouw die alle tabellen beschrijft en mapt van tabel naar class en vice versa. Je stopt alle tabellen die je in een database hebt in één XML file en je bent klaar. Tevens kan er gewerkt worden met annotations, aangezien dat toch iets is wat veel mensen graag doen. Ik zie niet voor me dat mijn ORM ooit door iemand anders gebruikt zal gaan worden dan door mijzelf, maar de oefening en de uitvoering is in ieder geval leuk.
En da's iets wat ik altijd een beetje mis bij .NET. Ik heb plezier in het gemak, maar niet in het schrijven van de code. Ik heb wel plezier als ik Visual Studio opstart, maar zodra ik dan merk dat je niet kan switchen tussen twee projecten zonder twee VS-instances te draaien of steeds je project te openen (en dus de andere te sluiten), raak ik gefrustreerd. Geef mij maar Eclipse, lekker simpel en toch best rap, met goeie plugins. Lekker coden in allerlei projecten tegelijk, die mooi met elkaar integreren en Merethil is happy

[AlphaRomeo]

Lethalis schreef op donderdag 16 april 2015 @ 19:40:
http://blogs.msdn.com/b/d...introducing-net-core.aspx
Er wordt echter met geen woord gerept over de toekomst van WPF.. Gaan ze het porten naar .net core? Of is het jammer maar helaas.. En zien ze WinRT met universal apps als de vervanger?

Uit datzelfde artikel:

.NET Framework 4.6

The .NET Framework is still the platform of choice for building rich desktop applications and .NET Core doesn’t change that.

en:

There are also investments that are exclusively being made for the .NET Framework such as the work we announced in the WPF Roadmap.

Maar ik ben het met je eens dat Microsoft een beetje vaag is. Ik had ook liever gehad dat iemand een richting uit zou zetten voor de toekomst van UI op .NET. Wij zitten zelf op dit moment op een punt waar we moeten beslissen welke kant we met de UI op gaan, en er wordt hier sterk geneigt naar WPF.

[whoami]

AlphaRomeo schreef op vrijdag 17 april 2015 @ 10:38:
[...]


Maar ik ben het met je eens dat Microsoft een beetje vaag is. Ik had ook liever gehad dat iemand een richting uit zou zetten voor de toekomst van UI op .NET. Wij zitten zelf op dit moment op een punt waar we moeten beslissen welke kant we met de UI op gaan, en er wordt hier sterk geneigt naar WPF.

Tja, wat zijn de alternatieven buiten WPF ?

[Cloud]

Die genoemde roadmap is gewoon positief inderdaad:

quote: http://blogs.msdn.com/b/d.../the-roadmap-for-wpf.aspx

[...]
Tooling: We will continue to co-evolve the tools for WPF when appropriate, alongside new platforms like .NET/WINRT. This commitment is reflected in the tooling investments section of this post.

[...]
Let’s first address a common question regarding support: WPF is a quintessential part of the .NET Framework. The .NET Framework is defined as a component of the operating system, instead of an independent product. So, support for .NET Framework is driven by the support lifecycle policy of the Windows operating system. Extended support for the current recommended version of .NET (4.5.2) on Windows 8.1 is available till 2023. We will continue to fix security issues and bugs reported by customers that impact a large cross-section of our WPF customers.

Het wordt echt geen Silverlight

whoami schreef op vrijdag 17 april 2015 @ 11:01:
[...]

Tja, wat zijn de alternatieven buiten WPF ?

Geen flauw idee.

[ Voor 8% gewijzigd door Cloud op 17-04-2015 11:05 ]

[AlphaRomeo]

whoami schreef op vrijdag 17 april 2015 @ 11:01:
[...]
Tja, wat zijn de alternatieven buiten WPF ?

WINRT? HTML 5 achtig?
Of toch nog WinForms dat ook nog steeds niet doodverklaard is...

[Cloud]

Als je je wilt beperken tot Win8+ zou je inderdaad WinRT kunnen overwegen WinForms is niet echt een fijne vervanger voor WPF, al kan het uiteraard wel. Maar ik denk dat nog eerder WinForms verdwijnt dan dat WPF verdwijnt.

[R4gnax]

whoami schreef op vrijdag 17 april 2015 @ 11:01:
[...]

Tja, wat zijn de alternatieven buiten WPF ?

Webkit of een andere browser engine in je desktop applicatie embedden voor het UI werk, via .NET Core een ASP.NET vNext process 'self-hosten' en op die manier werken.

Veruit de meest portable oplossing, lijkt me. Het enige platform-afhankelijke stukje dat je zelf zult moeten schrijven is het stukje wrapper om die browser engine heen.

[ Voor 13% gewijzigd door R4gnax op 17-04-2015 11:23 ]

[InZane]

Lethalis schreef op vrijdag 17 april 2015 @ 09:59:
[...]
Bij code first EF ben ik een half uur bezig om alles uit te zetten zodat het niet zelf ineens tabellen gaat zitten aanmaken etc Om ook maar niet over pluralization te beginnen. "Klants" etc Ik hou daar niet van. Ik ben meer klassiek geschoold; relaties in een database hebben bij mij enkelvoudige benamingen, dus "Klant" en niet "Klanten" en al helemaal niet "Klants"

Een half uur bezig om alles uit te zetten? Ik hoef niks uit te zetten hoor bij een nieuw code-first project. EF gaat alleen maar tabellen aanmaken/wijzigen als ik daar om vraag door een 'Update-Database' in de console.
Die pluralization ben ik verder ook niet zo van, ondanks dat mijn voertaal eigenlijk altijd Engels is als het even kan, maar het is natuurlijk een eitje om dat even te renamen.

Lethalis schreef op vrijdag 17 april 2015 @ 10:10:
Net zoals dat ik een schurfthekel aan Visual Studio project files heb (hoe moeilijk kan het zijn om directory wildcards toe te voegen, zodat we niet elke keer hoeven te mergen als iemand een bestandje toevoegt ).

Oh daar ben ik nou juist wel blij mee en dat mergen lost TFS toch wel voor je op?


We gaan trouwens wel een beetje offtopic inmiddels..

[ Voor 17% gewijzigd door InZane op 17-04-2015 11:49 ]

[Lethalis]

We gebruiken geen TFS

Maar goed, we gaan idd off topic. Ik wacht Microsoft Build nog even af. Kijken met wat ze nog meer gaan komen.

Hanselman heeft geschreven dat er nog meer grote announcements gaan komen ivm open source namelijk.

[ Voor 26% gewijzigd door Lethalis op 21-04-2015 07:26 ]

[R4gnax]

InZane schreef op vrijdag 17 april 2015 @ 11:47:
Oh daar ben ik nou juist wel blij mee en dat mergen lost TFS toch wel voor je op?

Not sure if sarcasm...

Er is in elk geval geen speciale intelligente merge functionaliteit voor project files. Die worden gewoon als untyped XML behandeld, waardoor je vaak; heel vaak, te maken krijgt met banale merge conflicts.

Daarnaast heeft ziet de auto-merge functionaliteit van TFS heel vaak niet correct wat nu wel of niet een merge conflict is. Alleen al de laatste 4 maanden heb ik een groot project file al 5 of 6 keer met het handje achteraf kunnen lopen herstellen omdat niet iedereen in mijn dev team de auto-merge functie uit heeft gezet of uit had staan (waar ze vaak niets aan kunnen doen, omdat Visual Studio af en toe deze ook om Joost mag weten wat voor reden weer terug aan heeft gezet).

[CodeCaster]

R4gnax schreef op dinsdag 21 april 2015 @ 21:19:
[...]


Er is in elk geval geen speciale intelligente merge functionaliteit voor project files. Die worden gewoon als untyped XML behandeld, waardoor je vaak; heel vaak, te maken krijgt met banale merge conflicts.

Met twee man tegelijk dezelfde reference updaten naar dezelfde versie... Tien regels conflicted. Why.

[ Voor 6% gewijzigd door CodeCaster op 21-04-2015 21:43 ]

[InZane]

R4gnax schreef op dinsdag 21 april 2015 @ 21:19:
[...]


Not sure if sarcasm...

Uh ja dat was inderdaad sarcastisch bedoeld. Met meerdere mensen in een project zitten roeren kan inderdaad behoorlijk irritant zijn. Vooral zorgen dat je je aanpassingen die een project file raken snel weer incheckt.

[Lethalis]

InZane schreef op dinsdag 21 april 2015 @ 21:48:
[...]
Uh ja dat was inderdaad sarcastisch bedoeld. Met meerdere mensen in een project zitten roeren kan inderdaad behoorlijk irritant zijn. Vooral zorgen dat je je aanpassingen die een project file raken snel weer incheckt.

En omdat elk bestand in de projectfile wordt geregistreerd is dat dus niet te doen.

Ik werk met 3 anderen aan dezelfde solution die 20 projecten bevat. En helaas komen we elkaar regelmatig tegen.

Wij gebruiken een locking mechanisme voor project files en moeten om die reden regelmatig op elkaar wachten. Maar ja, alles is beter dan die bestanden proberen te mergen.

Het nieuwe json formaat heeft hier gelukkig geen last van. Door de wildcard ondersteuning kan iedereen naar hartelust bestanden toevoegen tegelijkertijd.

Ik vind het alleen idioot dat ze daar nu pas mee komen.

[NC83]

Hatsieflatsie schreef op donderdag 09 april 2015 @ 23:19:
[...]

Ik kan het niet volledig buigen naar m'n voorkeuren. Dat houdt ook in dat de GUI geheel verdwijnt.

Je hebt gewoon een VIM plugin voor VS tegenwoordig waardoor de editor window op de manier van VIM begint te werken

[Amanush]

Mag ik jullie er even op attenderen dat zeuren op IDE's en zeuren op Vim of Emacs (of welke editor dan ook) kansloos is?

Iemand die een IDE gebruikt, wil nooit meer terug naar een editor. Iemand die een editor als Vim of Emacs gebruikt, wil nooit meer terug naar een IDE. Iemand daarom aanvallen op "regels code" of "ervaring" slaat nergens op.

Dat gezegd te hebben, zijn er genoeg programma's buiten Vim (of Emacs) die de functionaliteit bieden welke een IDE ook biedt. Ik gebruik nu bijvoorbeeld Scala, maar de TUI / CLI SBT biedt veel functionaliteit die normaal gezien ook in een IDE zit. Het enige verschil: ik typ "sbt run" in plaats van dat ik op een knopje "run" klik. - Groot verschil - *not*

SBT draait mijn Unit Tests, compileert mijn code naar JVM bytecode, voert mijn applicatie uit, regelt mijn depencies, etc. etc.
Ikzelf vind het prachtig werken, maar dat betekent niet dat jij het *moet* gebruiken. Gebruik gerust een IDE.

Stop met discusseren of een IDE beter is dan Vim/Emacs. Je kan er praktisch gezien exact hetzelfde mee.
Vim bestempelen als "ballenbak" of "kist met verkeerde tools" is kinderachtig en slaat nergens op. Vim biedt voor mij persoonlijk een fijne omgeving om in the werken.

IDE's zijn gespecialiseerd in een specifieke taal, en Vim gewoon niet. Vim zal niet "gespecialiseerd" zijn in een bepaalde taal. Dat gezegd te hebben zie ik het niet zitten voor elke taal die ik beheers een andere IDE te gebruiken: daarom gebruik ik ook Vim.

Samengevat: stop met discusseren wat beter is, je komt er toch niet uit.

[ Voor 3% gewijzigd door Amanush op 22-04-2015 20:18 ]

[Caelorum]

Amanush schreef op woensdag 22 april 2015 @ 20:02:
[...]
Samengevat: stop met discusseren wat beter is, je komt er toch niet uit.

Zonder discussie kom je nergens uit. Juist met een discussie kan je mensen overtuigen van je gelijk, mits de discussie zelf van enige kwaliteit is.

Dat gezegd hebbende: zeggen dat mensen moeten discussiëren over wel of niet een IDE in een topic die daar zo ongeveer over gaat is ook wel een beetje kansloos IMO ^^

[Amanush]

Caelorum schreef op woensdag 22 april 2015 @ 20:29:
[...]

Zonder discussie kom je nergens uit. Juist met een discussie kan je mensen overtuigen van je gelijk, mits de discussie zelf van enige kwaliteit is.

[...]

- Als de discussie van kwaliteit is -. Dit lijkt meer op christenen afschieten omdat ze niet in Allah geloven. Een fundamentalistische strijd tussen twee partijen.

Het is niet nodig om mensen te overtuigen van je gelijk bij dit onderwerp. We zouden er eigenlijk over moeten praten en het gesprek aan moeten gaan. We kunnen best aan elkaar vertellen "waarom" op een rustige toon, zonder dat we gaan gooien met modder en gaan schreeuwen dat een IDE/editor beter is.

[ Voor 32% gewijzigd door Amanush op 22-04-2015 20:52 ]

[Brent]

De discussie was: is het kiezen voor een taal (enigszins) afhankelijk van de tooling? M.a.w., zijn er bepaalde zaken elementair voor het gebruiken van een taal, buiten de taal zelf? Voor velen zal dat een debugger zijn, voor sommigen een IDE, weer andere of je het zonder proprietaire compilers kunt compileren. Een enkeling moet en zal met Emacs typen. Enzovoorts.

Over wat precies van belang is voor jou zullen de meningen verschillen, zeker, maar dat maakt een interessante discussie nog wel mogelijk. We moesten het inderdaad maar niet over IDE vs vim vs Emacs hebben, maar als ik C++ typ, vind ik een visuele debugger toch echt een must, en IDE is zeker een pre. Maar het allerliefst programmeer ik in Python, en dan heb ik alleen een basic text editor nodig (Kate is mijn favoriet momenteel).

Niets _is_ beter, maar als je uitlegd waarom jij het een of ander prettig vind, kun je misschien tot een nieuw inzicht komen. Ik ben alweer wat jaartjes geleden tot het inzicht gekomen dat het doodtoolen in de Java-wereld bijvoorbeeld veel te maken heeft met de cultuur waarin die taal vaak gebruikt wordt: IT uitbestedingsshops. Die zijn vaak ingericht op jou inwisselbaarheid, en dan is veel en stricte tooling een oplossing. En daar zitten best wat aardige spullen tussen. Toch ben ik blij met de 'vrijheid' wat te kunnen spelen, want stricte tooling zal (voor mij) altijd uitlopen op vechten met die tool. Ik vind vechten met de taal al erg genoeg (C++ kuch), ik werk het liefst gewoon aan het oplossen van mijn probleem, het redeneren over mijn algoritme, het versnellen ervan. Teveel tooling leidt me er van af, al helpt iets als een debugger dus wel enorm.

Ofwel: alle software zijn gereedschappen, het is aan u ze te leren en te weten wat je wanneer kunt gebruiken Religie is voor onzekere mensen of om anderen in het gareel te houden. Helaas komen beide situaties voor, dus ook de tools en de discussies

[raptorix]

Ik zou geen enkele reden kunnen opnoemen waarom je c# niet in Visual Studio zou gebruiken, bovendien denk ik dat je maar in weinig talen zo productief kunt zijn, zeker in combinatie met resharper.

[CodeCaster]

raptorix schreef op donderdag 23 april 2015 @ 08:52:
Ik zou geen enkele reden kunnen opnoemen waarom je c# niet in Visual Studio zou gebruiken

Omdat je geen Windows kan of wil gebruiken.

[raptorix]

CodeCaster schreef op donderdag 23 april 2015 @ 09:50:
[...]

Omdat je geen Windows kan of wil gebruiken.

Tjah, waarom zou je dat niet kunnen of willen?

[Cloud]

Nou ja als je nu als ontwikkelaar met Mono bezig bent onder Linux kan ik me voorstellen dat het lastig is om VS te gebruiken binnen Windows. Ik weet niet of dat zo goed werkt via virtualisatie?

[Caelorum]

Sowieso is er een kostenplaatje aan het gebruik van Visual Studio. Daarnaast kan je ook nog eens met legacy projecten zitten (zoals ik).

[Brent]

raptorix schreef op donderdag 23 april 2015 @ 10:17:
[...]

Tjah, waarom zou je dat niet kunnen of willen?

Ik geloof niet dat je daar geen echte reden voor kunt bedenken. Je kunt het ermee oneens zijn, maar dat is niet zo'n interessante discussie.

raptorix schreef op donderdag 23 april 2015 @ 08:52:
bovendien denk ik dat je maar in weinig talen zo productief kunt zijn

Een religieuzer uitspraak had je niet kunnen maken, mijn beste

[ Voor 28% gewijzigd door Brent op 23-04-2015 11:00 ]

[CodeCaster]

Caelorum schreef op donderdag 23 april 2015 @ 10:47:
Sowieso is er een kostenplaatje aan het gebruik van Visual Studio.

Express-editions van Visual Studio bestaan al even, en nu is er ook Visual Studio Community. Die zijn gratis, ook voor commercieel gebruik.

Dan heb je nog steeds een whopping tachtig euro nodig voor een OEM-licentie van Windows, maar Visual Studio hoeft geen geld te kosten.

[Cloud]

Caelorum schreef op donderdag 23 april 2015 @ 10:47:
Sowieso is er een kostenplaatje aan het gebruik van Visual Studio. Daarnaast kan je ook nog eens met legacy projecten zitten (zoals ik).

Dat kostenplaatje valt tegenwoordig gelukkig wel wat mee. In veel situaties kun je uit de voeten met de community edition van Visual Studio. Vroeger was dat wel wat anders ja

Je moet al aardig professioneel bezig zijn wil je buiten de gebruiksvoorwaarden van deze editie stappen. En dan zouden de kosten ook geen probleem meer hoeven zijn.

[Caelorum]

CodeCaster schreef op donderdag 23 april 2015 @ 10:52:
[...]
Express-editions van Visual Studio bestaan al even, en nu is er ook Visual Studio Community. Die zijn gratis, ook voor commercieel gebruik.[...]

De express editions hebben (of hadden) een limiet op het aantal projecten in een solution. Iets dat enorm in de weg zat.
Sinds de VS Community edition uit is gebruiken we die inderdaad ook, maar er zijn nog zat projecten die met een makefile en notepad++ moeten worden behandelt, vanwege verschillende redenen. (en ja dat is kut, zo zonder debugger)

[ Voor 3% gewijzigd door Caelorum op 23-04-2015 11:34 ]

[MSalters]

Bouwen met een makefile is geen reden om MSVC als debugger aan de kant te zetten. Kwestie van een PDB meebouwen, attach to process en klaar. Werkt zelfs op release builds.

[Brent]

'nog' een makefile? OK, wij gebruiken CMAKE, maar veel keuze is er niet voor crossplatform software volgens mij. VS leest geen CMAKE?

[Lethalis]

Caelorum schreef op donderdag 23 april 2015 @ 10:47:
Sowieso is er een kostenplaatje aan het gebruik van Visual Studio. Daarnaast kan je ook nog eens met legacy projecten zitten (zoals ik).

Met Visual Studio Community Edition zijn die kosten vrijwel tot 0 gereduceerd.

Verwar die niet met de Express editions. Hij ondersteunt plugins en alles. Het is in feite een volledige studio.

CodeCaster schreef op donderdag 23 april 2015 @ 09:50:
[...]
Omdat je geen Windows kan of wil gebruiken.

Waarom wil je dan C# doen?

1 van de redenen dat ik in mijn vrije tijd ben begonnen met Java leren was omdat ik thuis een Mac heb staan en geen zin meer had om een Windows VM te starten

En met Java weet ik redelijk zeker dat ik de code kan hergebruiken op zowel Windows, Mac als Linux.

Het is nu nog even afwachten hoe ver Microsoft zal komen met de portabiliteit. .NET core zal als het goed is volledig moeten werken op de Mac en Linux.

Je hebt dan inderdaad voorlopig geen Visual Studio. Als je bereid bent om een volledige IDE achter je te laten, zou je nog Sublime met OmniSharp kunnen gebruiken:

http://www.omnisharp.net/

Hiermee kun je vanuit Sublime of bijvoorbeeld Atom gewoon C# code completion krijgen en de boel direct compileren etc. Debuggen is eigenlijk het enige dat je mist (wel serieus probleem ).

Maar ja, ik hou van C#. Ik heb zelfs een C# t-shirt aan op dit moment (van Xamarin). Hoewel ik Xamarin IDE vrij beperkt vind..

Terug naar mijn punt, hoe fijn ik C# ook vind, als ik niet op een Windows machine wil zitten, dan doe ik iets anders. Dan wordt het Java, Scala of whatever. Dan is C# simpelweg niet geschikt. Jammer maar helaas.

Ik vind Swift van Apple ook stoer, maar het is niet open source en werkt alleen op iOS en OS X. Tsja, dan is het jammer maar helaas bij mij (totdat ik weer eens een iPad app moet maken van mijn werkgever, maar that's it).

PS:
We leven in een era van polyglot development. De fragmentatie zal steeds erger worden, omdat elke grote speler alles naar zichzelf toe wil brengen. Ook neemt de diversiteit van gebruikte technieken in een project toe.

Vasthouden aan een bepaalde taal is niet meer te doen. Laat die gedachte dan ook los en kies gewoon wat handig is voor het project.

[ Voor 9% gewijzigd door Lethalis op 24-04-2015 12:32 ]

[Caelorum]

Keuze tussen java of C#/Mono is snel gemaakt IMO. Zou altijd voor C# kiezen, tenzij mono *echt* niet beschikbaar is op het target platform, maar dat komt eigenlijk in mijn geval nooit voor. Met monodevelop kom je ook nog wel een heel eind. Is niet de meest ideale IDE, maar je kan iig eenvoudig debuggen

[Grijze Vos]

Amanush schreef op woensdag 22 april 2015 @ 20:02:
SBT draait mijn Unit Tests, compileert mijn code naar JVM bytecode, voert mijn applicatie uit, regelt mijn depencies, etc. etc.
Ikzelf vind het prachtig werken, maar dat betekent niet dat jij het *moet* gebruiken. Gebruik gerust een IDE.

SBT is dus gewoon een IDE.

[Lethalis]

Caelorum schreef op vrijdag 24 april 2015 @ 12:35:
Keuze tussen java of C#/Mono is snel gemaakt IMO. Zou altijd voor C# kiezen, tenzij mono *echt* niet beschikbaar is op het target platform, maar dat komt eigenlijk in mijn geval nooit voor. Met monodevelop kom je ook nog wel een heel eind. Is niet de meest ideale IDE, maar je kan iig eenvoudig debuggen

Toch maak je het jezelf dan moeilijk als je niet op een Windows machine zit en zonder Visual Studio.

Als ik dan Java met NetBeans IDE of IntelliJ erbij pak, dan heb ik veel completere tooling op Linux / Mac dan wanneer ik het met C# en Mono zou willen oplossen.

Dan lig ik niet meer wakker van class properties die missen ofzo, of een fijnere syntax. Zeker niet als ik in NetBeans met een paar simpele drukken op een knop alle getters / setters genereer die ik nodig heb.

En dan hebben we nog andere JVM talen zoals Scala en Kotlin als je de code graag kort en bondig houdt.

Het wordt misschien anders als Microsoft morgen met een IDE komt voor Linux / Mac. Maar tot die tijd kies ik liever voor iets dat goed werkt op het platform dat ik gebruik en waar alle tools voor beschikbaar zijn

[InZane]

Lethalis schreef op vrijdag 24 april 2015 @ 13:01:
[...]
Het wordt misschien anders als Microsoft morgen met een IDE komt voor Linux / Mac. Maar tot die tijd kies ik liever voor iets dat goed werkt op het platform dat ik gebruik en waar alle tools voor beschikbaar zijn

Met de weg die MS is ingeslagen momenteel sta ik er niet raar van te kijken als VS multi-platform gaat.

[Brent]

Caelorum schreef op vrijdag 24 april 2015 @ 12:35:
Keuze tussen java of C#/Mono is snel gemaakt IMO. Zou altijd voor C# kiezen, tenzij mono *echt* niet beschikbaar is op het target platform, maar dat komt eigenlijk in mijn geval nooit voor. Met monodevelop kom je ook nog wel een heel eind. Is niet de meest ideale IDE, maar je kan iig eenvoudig debuggen

Zoals reeds gezegd, hangt helemaal af van je eisen. Ik kies altijd cross-platform, niets maakt me banger dan het idee dat ik niet op elk moment kan verhuizen

[Caelorum]

Ik wil hier niet een hele discussie over C# vs Java gaan beginnen, maar of je nou mono target of jvm, maakt over het algemeen niet zoveel uit. Mono draait al op zoveel systemen, dat ik durf te wedden dan 90% van de ontwikkelaars gewoon C#/mono zouden kunnen gebruiken.

Dan heb je alleen nog de tooling die wellicht niet heel fijn is onder linux. Aan de andere kant is daar met monodevelop ook weer niet zoveel op aan te merken. Het is bij lange na niet een Visual Studio, maar alle dingen die je IMO echt nodig zou kunnen hebben is er gewoon. Er is een GUI designer, een debugger, nuget package manger, code completion en refactoring, NUnit integratie, SVN integratie. Eigenlijk al meer dan je echt nodig zou moeten hebben. Wat dat betreft is er IMO niet echt een reden waarom je niet C#/mono zou kiezen, behalve als je al bekent bent met java of de jvm.

Dat gezegd hebbende zou ik persoonlijk ook liever voor C++/Qt gaan, maar die optie is niet altijd even handig

[Lethalis]

Grijze Vos schreef op vrijdag 24 april 2015 @ 13:00:
[...]

SBT is dus gewoon een IDE.

Nope.

Mijn avonturen met Scala heb ik overigens ook vooral met SublimeText en SBT beleefd, omdat de beschikbare IDE's vrij crappy zijn (Scala IDE ). IntelliJ kan een hoop, maar moet je goed configureren en dat kostte mij helaas vaak meer tijd dan gewoon iets bouwen met Sublime.

Maar zodra de IDE's voor Scala beter en toegankelijker worden (lees: eenvoudiger werkbaar te krijgen zijn), zou ik daar ook veel sneller voor kiezen. Een IDE biedt simpelweg vaak meer gemak, zolang hij niet in de weg staat (Scala IDE gaf bij mij veel syntax errors die er helemaal niet waren ).

Caelorum schreef op vrijdag 24 april 2015 @ 13:10:
Dan heb je alleen nog de tooling die wellicht niet heel fijn is onder linux. Aan de andere kant is daar met monodevelop ook weer niet zoveel op aan te merken. Het is bij lange na niet een Visual Studio, maar alle dingen die je IMO echt nodig zou kunnen hebben is er gewoon. Er is een GUI designer, een debugger, nuget package manger, code completion en refactoring, NUnit integratie, SVN integratie. Eigenlijk al meer dan je echt nodig zou moeten hebben. Wat dat betreft is er IMO niet echt een reden waarom je niet C#/mono zou kiezen, behalve als je al bekent bent met java of de jvm.

Dat gezegd hebbende zou ik persoonlijk ook liever voor C++/Qt gaan, maar die optie is niet altijd even handig

Been there, done that MonoDevelop gebruiken voor web development was iig een crime. Project templates die het niet out of the box doen etc. Het viel mij behoorlijk tegen.

Maar ja, de focus van Xamarin ligt ook niet op web development (terwijl Java er juist heel groot in is).

C++/Qt is wel leuk voor client development, maar in een wereld van web applicaties en Android / iOS apps bedient het vooral een niche. Ik vind het nog steeds jammer dat de Borland VCL min of meer een eenzame dood is gestorven

[edit]
Het bestaat nog steeds! Borland C++ Builder was het laatste dat ik gebruikte tig jaar geleden..

http://www.embarcadero.com/products/cbuilder/whats-new

[ Voor 50% gewijzigd door Lethalis op 24-04-2015 13:27 ]

[WernerL]

Lethalis schreef op vrijdag 24 april 2015 @ 13:15:
[...]
Nope.

Mijn avonturen met Scala heb ik overigens ook vooral met SublimeText en SBT beleefd, omdat de beschikbare IDE's vrij crappy zijn (Scala IDE ). IntelliJ kan een hoop, maar moet je goed configureren en dat kostte mij helaas vaak meer tijd dan gewoon iets bouwen met Sublime.

Maar zodra de IDE's voor Scala beter en toegankelijker worden (lees: eenvoudiger werkbaar te krijgen zijn), zou ik daar ook veel sneller voor kiezen. Een IDE biedt simpelweg vaak meer gemak, zolang hij niet in de weg staat (Scala IDE gaf bij mij veel syntax errors die er helemaal niet waren ).

Eclipse is sowieso een crime imho. Maar nu ben ik toch wel benieuwd wat jij tegen IntelliJ hebt. Een van de voordelen van intelliJ is dat je gewoon zonder problemen een SBT project kunt openen zonder eerst project files te genereren. (Wat wel moet als je Scala IDE gebruikt). Het enige stomme is dat Play support alleen in de ultimate edition zit. Maar intellij werkt bij mij zeer goed. Hoef er niets voor te configureren. Alleen zorgen dat sbt en scala in je path staan. Maar dat moet sowieso, ook als je geen IDE gebruikt.

Ik moet eerlijk zeggen dat ik tegenwoordig liever in geany mijn code schrijf. Het biedt de basis features die ik verlang van een IDE. Je hebt alleen geen code-completion. Terminal venster in geany openen en vanuit daar compilen.testen en applicatie starten.

[Lethalis]

WernerL schreef op vrijdag 24 april 2015 @ 13:29:
[...]
Het enige stomme is dat Play support alleen in de ultimate edition zit. Maar intellij werkt bij mij zeer goed. Hoef er niets voor te configureren. Alleen zorgen dat sbt en scala in je path staan. Maar dat moet sowieso, ook als je geen IDE gebruikt.

Ik liep dus tegen een paar dingen aan:
- Ik werkte met het Play! framework
- Ik had meerdere versies van Scala op mijn OS X machine en IntelliJ vond dat minder tof. Hij kon elke keer niet de juiste sdk vinden.
- Ik was eigenwijs (wilde eerst alles met gradle + scala plugin doen ipv SBT) en dan zag IntelliJ de dependencies niet (doet het alleen bij Java projecten)

Volgens diverse handleidingen had ik alles goed ingesteld, maar het bleef foutmeldingen geven. Kan er ook aan liggen dat ik op een Mac zit.

Overigens heb ik inmiddels een student licentie van JetBrains voor de ultimate, dus ik zou het opnieuw kunnen proberen Maar ja, ik probeer zoveel dingen na mijn werk dat ik mezelf uitput

[ Voor 9% gewijzigd door Lethalis op 24-04-2015 13:54 ]

[NC83]

Caelorum schreef op donderdag 23 april 2015 @ 11:33:
[...]

De express editions hebben (of hadden) een limiet op het aantal projecten in een solution. Iets dat enorm in de weg zat.
Sinds de VS Community edition uit is gebruiken we die inderdaad ook, maar er zijn nog zat projecten die met een makefile en notepad++ moeten worden behandelt, vanwege verschillende redenen. (en ja dat is kut, zo zonder debugger)

Je weet dat een community editie in een bedrijf door niet meer dan 5 man mag worden gebruikt. Tenzij het research of open source software is.

Ik weet niet waar je werkt maar CE is leuk voor thuis hobby of open source, voor de rest is de licentie redelijk strict.

Brent schreef op donderdag 23 april 2015 @ 15:45:
'nog' een makefile? OK, wij gebruiken CMAKE, maar veel keuze is er niet voor crossplatform software volgens mij. VS leest geen CMAKE?

Je kunt altijd VS solution file en project file aanpassen zodat VS gewoon een external buildsystem aanroept via een batch file. Dit is hoe we dit doen op het werk om waf te gebruiken als buildsystem.

[ Voor 23% gewijzigd door NC83 op 24-04-2015 14:26 ]

[Amanush]

Grijze Vos schreef op vrijdag 24 april 2015 @ 13:00:
[...]

SBT is dus gewoon een IDE.

Een IDE zonder mogelijkheid om files te editen.

[Caelorum]

NC83 schreef op vrijdag 24 april 2015 @ 14:23:
[...] Je weet dat een community editie in een bedrijf door niet meer dan 5 man mag worden gebruikt. Tenzij het research of open source software is.

Ik weet niet waar je werkt maar CE is leuk voor thuis hobby of open source, voor de rest is de licentie redelijk strict. [...]

We zijn daarvan op de hoogte. De omzet van het bedrijf moet ook minder dan een miljoen zijn, omdat je anders in de Enterprise categorie valt die is uitgesloten van de community edition.

@onder:

Lethalis schreef op vrijdag 24 april 2015 @ 17:08:
[...]
Weer een voordeel van Java: NetBeans IDE en Eclipse kan je onbeperkt gebruiken. [...]

Net als MonoDevelop, dus je punt is?

---

Laten we nu maar weer lekker ontopic gaan

[ Voor 21% gewijzigd door Caelorum op 24-04-2015 17:13 ]

[Lethalis]

Caelorum schreef op vrijdag 24 april 2015 @ 16:40:
[...]

We zijn daarvan op de hoogte. De omzet van het bedrijf moet ook minder dan een miljoen zijn, omdat je anders in de Enterprise categorie valt die is uitgesloten van de community edition.

Weer een voordeel van Java: NetBeans IDE en Eclipse kan je onbeperkt gebruiken.

Maar goed. Een open source IDE is wat Microsoft hard nodig heeft nu wil het een breder publiek aanspreken.

[Amanush]

Lethalis schreef op vrijdag 24 april 2015 @ 17:08:
[...]
Weer een voordeel van Java: NetBeans IDE en Eclipse kan je onbeperkt gebruiken.

Maar goed. Een open source IDE is wat Microsoft hard nodig heeft nu wil het een breder publiek aanspreken.

We hebben Eclipse en MonoDevelop.

Trouwens, aan de Vim-gebruikers: heeft iemand ervaring met Eclim? (http://eclim.org/)

[Hatsieflatsie]

Amanush schreef op vrijdag 24 april 2015 @ 18:41:
[...]


We hebben Eclipse en MonoDevelop.

Trouwens, aan de Vim-gebruikers: heeft iemand ervaring met Eclim? (http://eclim.org/)

Erg positief. Maar ik ben overgestapt op Emacs, dat betere ondersteuning voor Java en C# kent (ook met F-sharp), en Vim interface en keybindings volledig ondersteunt. Kijk bijv. op Spacemacs.

[Amanush]

Hatsieflatsie schreef op zondag 26 april 2015 @ 17:41:
[...]
Erg positief. Maar ik ben overgestapt op Emacs, dat betere ondersteuning voor Java en C# kent (ook met F-sharp), en Vim interface en keybindings volledig ondersteunt. Kijk bijv. op Spacemacs.

Ik zit eroverna te denken ook het Vim-platform te verlaten en een kijkje in de wereld van Emacs te nemen. Ik kan namelijk geen Eclim draaien omdat JVM dat niet leuk vind (CPU springt ook naar de 100% usage).

Hoe was de overgang van Vim naar Emacs? Werken automatic imports in Emacs zonder gebruik van Eclim?

[InZane]

InZane schreef op vrijdag 24 april 2015 @ 13:03:
[...]


Met de weg die MS is ingeslagen momenteel sta ik er niet raar van te kijken als VS multi-platform gaat.

nieuws: Microsoft komt met afgeslankte Visual Studio voor Mac en Linux

[Brent]

InZane schreef op woensdag 29 april 2015 @ 19:37:
[...]


nieuws: Microsoft komt met afgeslankte Visual Studio voor Mac en Linux

Even voorop gesteld dat het om Visual Studio Code gaat, wat een editor a la Atom of Brackets is (draai het nu even), is het inderdaad een verassing. Maar de richting is duidelijk, VSC wordt aangeprezen als modern webdev tool, voor nodejs en asp.net applicaties. Het is dus duidelijk wat de bedoeling is, asp.net op Linux aan de man brengen, iets wat helemaal past in de eerdere vrijggave van dat platform voor Linux.

[Cloud]

Ik moest ook meteen aan dit topic denken toen ik het bericht las

quote: http://techcrunch.com/201...and-windows/#.eethu9:gLUr

...
but the company also worked on bringing some of Visual Studio’s language features to Visual Studio Code. These include the Roslyn project, for example, Microsoft’s .NET compiler platform and Microsoft says the language services it built for Visual Studio Code will be available in other editors as well, including Sublime Text, Vi and Atom.

Microsoft is echt radicaal omgedraaid. Petje af hoor

[Hatsieflatsie]

Amanush schreef op zondag 26 april 2015 @ 18:54:
[...]


Ik zit eroverna te denken ook het Vim-platform te verlaten en een kijkje in de wereld van Emacs te nemen. Ik kan namelijk geen Eclim draaien omdat JVM dat niet leuk vind (CPU springt ook naar de 100% usage).

Hoe was de overgang van Vim naar Emacs? Werken automatic imports in Emacs zonder gebruik van Eclim?

Je kunt ook Eclim draaien in Emacs? Of bedoel je wat anders? Emacs heeft overigens ook goede tooling voor JVM (zie emacs.zeef.com).

[Amanush]

Hatsieflatsie schreef op dinsdag 12 april 2016 @ 22:30:
[...]

Je kunt ook Eclim draaien in Emacs? Of bedoel je wat anders? Emacs heeft overigens ook goede tooling voor JVM (zie emacs.zeef.com).

Eclim is uiteraard ook een mogelijkheid (kan ook in Vim). Wat jammer is, is dat ik Emacs gewoon niet fijn vind voelen. Zelfs de Vim-emulatie voelt niet 'echt Vim'. Volgens mij komt dat ook doordat ik als een gek op toetsen loop te drukken, en Emacs daar allemaal rare dingen uit haalt die niks met Evil / Vim emulatie te maken hebben, terwijl ik dat wel zo bedoel.

Ik ga me even inlezen in emacs.zeef.com

[ Voor 3% gewijzigd door Amanush op 14-04-2016 10:37 ]

[Hatsieflatsie]

Amanush schreef op donderdag 14 april 2016 @ 10:36:
[...]

Eclim is uiteraard ook een mogelijkheid (kan ook in Vim). Wat jammer is, is dat ik Emacs gewoon niet fijn vind voelen. Zelfs de Vim-emulatie voelt niet 'echt Vim'. Volgens mij komt dat ook doordat ik als een gek op toetsen loop te drukken, en Emacs daar allemaal rare dingen uit haalt die niks met Evil / Vim emulatie te maken hebben, terwijl ik dat wel zo bedoel.

https://github.com/syl20bnr/spacemacs een optie voor jou?