Niet kiezen voor een taal, vanwege de tooling?

[Hatsieflatsie]

Een algemene vraag uit interesse. Wanneer je rondkijkt, zul je algauw opmerken dat er veel C#-vacatures zijn. Maar daarbij wordt er meestal Visual Studio en Microsoft-producten gebruikt. Dus daar ga ik al niet voor, ongeacht hoe goed C# als taal in elkaar steekt.

Hetzelfde zou je kunnen zeggen over Java (Eclipse en IntelliJ IDEA). Nu heb ik heb meer dan duizenden uren besteed aan VimL en Lisp code, om de editors Vim en Emacs volledig naar m'n wensen te krijgen in de terminal.

Alhoewel je wel C# en Java autocompletion kunt verkrijgen in Emacs, is het eerder een uitzondering die de regel bevestigt. Hetzelfde voor Vim.

Wat ik om mij heen zie, is dat men de taal kiest en vervolgens de bijpassende tooling. Ik kies de tooling waar ik mij thuis in voel, het prettigst mee overweg kan, en kijk vervolgens met welke talen-ie goed mee overweg kan.

Nu vraag ik mij af of er Tweakers die zich in deze omgekeerde keuze herkennen?

[Matis]

Bedoel je in de selecties van vacatures of binnen het bedrijf zelve?
Wij hebben weinig tot geen keuze in een programmeertaal; C met POSIX lib.
De IDE of editor is iedereen vrij in. We hebben Eclipse, Qt Creator, Geany, Gedit, vi(m), EMACS...
Zo'n beetje alles is geaccepteerd qua editor.

Ik snap niet waarom je de voorkeur van een taal alleen beslist op basis van de beschikbare IDEs.

Je zou voor C# bijvoorbeeld ook SharpDevelop kunnen gebruiken.

[whoami]

Hatsieflatsie schreef op donderdag 09 april 2015 @ 22:31:
Een algemene vraag uit interesse. Wanneer je rondkijkt, zul je algauw opmerken dat er veel C#-vacatures zijn. Maar daarbij wordt er meestal Visual Studio en Microsoft-producten gebruikt. Dus daar ga ik al niet voor, ongeacht hoe goed C# als taal in elkaar steekt.

Is dat gebaseerd op een gegronde reden of op vooroordelen ?

[Ramon]

Ik denk toch dat je je prioriteiten niet helemaal op orde hebt Inmiddels programmeer ik al 20 jaar en ik kan met iedere editor werken, de ene beter dan de andere natuurlijk. Ik zou wanneer het om vacatures gaat toch eerder kijken naar werkomgeving, collega's, klanten, salaris, reisafstand.... IDE zou bij mij op de laatste plaats komen

[RobIII]

Ramon schreef op donderdag 09 april 2015 @ 22:54:
Ik denk toch dat je je prioriteiten niet helemaal op orde hebt Inmiddels programmeer ik al 20 jaar en ik kan met iedere editor werken, de ene beter dan de andere natuurlijk. Ik zou wanneer het om vacatures gaat toch eerder kijken naar werkomgeving, collega's, klanten, salaris, reisafstand.... IDE zou bij mij op de laatste plaats komen

Ik wou exact hetzelfde posten. Ben het dan ook 200% met je eens, vooral je eerste zin.

@TS: Zou je bij ons werken: wat geef ik er om dat je je C# schrijft in Notepad2, Sublimetext, VIM, nano, Word, Visual Studio, Eclipse, Emacs, vim, gEdit, atom, ...? Als je je werk maar af hebt en het goed doet. Sourcecode == sourcecode. Boeie.

[ Voor 6% gewijzigd door RobIII op 09-04-2015 23:04 ]

[Hatsieflatsie]

Hmmmz. Ik was in de veronderstelling dat het haast onwerkbaar was om zonder Visual Studio C# applicaties te ontwikkelen, of daarmee in een team te werken waar iedereen met VS werkt.

My bad.

[Hatsieflatsie]

whoami schreef op donderdag 09 april 2015 @ 22:47:
[...]
Is dat gebaseerd op een gegronde reden of op vooroordelen ?

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

[F.West98]

Het is natuurlijk wel een stuk makkelijker om een full-blown .NET MVC applicatie te maken met tests en alles in VS dan in een andere IDE. Neemt niet weg dat het niet KAN.

[ Voor 10% gewijzigd door F.West98 op 09-04-2015 23:21 ]

[RobIII]

Hatsieflatsie schreef op donderdag 09 april 2015 @ 23:17:
Ik was in de veronderstelling

Assumptions are the mother of all....

Neemt niet weg dat VS écht wel een behoorlijk goede, stabiele en (IMHO) fijne IDE is en de ervaring (again, IMHO) vele malen beter is dan wanneer je ligt te frotten met allerlei aan-elkaar-ge-duct-tapete-losse-tools, batchfiles, makefiles, powershell scripts etc. om zo je workflow een beetje te stroomlijnen waar je in VS gewoon op F5 ramt. Wanneer heb je VS voor 't laatst serieus bekeken? 2003? Of 2013?

[ Voor 24% gewijzigd door RobIII op 09-04-2015 23:28 ]

[Herko_ter_Horst]

Je lijkt je tools tot doel verheven te hebben. Dat lijkt mij de omgekeerde wereld, tools zijn een middel.

"The right tool for the job". Net zo als je de juiste programmeertaal kiest voor een bepaald probleem, kies je de tools bij de programmeertaal.

[The Eagle]

Ik werk zelf heel graag met UltraEdit en Toad (voor Oracle SQL). Maar ja, die kosten $$$. En Emerald Editor resp Oracle SQL Developer kunnen het zelfde en zijn gratis. Guess wat ik vaker gebruik

[johnkeates]

Ik zou sowieso niet op een vacature duiken die voor een taal, ecosysteem of merk beperkt is. Dan kom je eigenlijk automatisch op een afdeling terecht waar 90% van het personeel oogkleppen op heeft. Niet zo zeer op een slechte manier, het kan heel leuk zijn om met een heel selectief stukje van de wereld bezig te zijn, maar dat moet je dan maar net liggen. Je bent dan eigenlijk code klopper als je de meeste van die vacatures langs gaat, en wat betreft uitdaging kan je het dan voornamelijk vinden in vendor-specifieke quirks en de logica die je mag maken.

Tooling is eigenlijk nooit handig om als uitgangspunt te nemen. Sure, je kan stellen dat je ergens mee wil werken wat niet achter loopt, maar stel dat je VCS/SCM Bazaar of Mercurial is in plaats van Git, om dat het bestaande team daar al mee werkt, dan is er eigenlijk weinig aan de hand. Of stel dat je geen JIRA gebruikt maar TeamCity of GitHub's issue systeem, of dat van GitLab, hell, zelfs Redmine en Trac kunnen prima door. Maakt ook weinig uit.

Hetzelfde geldt voor je IDE, het is niet alsof er een gigantisch verschil is, op z'n best kan je onderscheid maken in esthetische aspecten en zo nu en dan unieke features (die dan toch wel weer door andere IDE's over genomen worden). Ik zou zo snel niet een taal kunnen bedenken die alleen maar 'goed' werkt met een specifieke IDE. Er zijn altijd meerdere opties qua editors, debuggers, linkers, compilers enz.

Het grootste obstakel wat je zou kunnen ervaren is de vrijheid qua tooling die je krijgt. Soms mag je niet zelf kiezen, en dan kan je dus met crappy tooling zitten waar je niet onder uit komt. Op dat moment is het tijd om een ander baantje te zoeken ;-)

Qua tooling en talen heb je uiteraard ook te maken met het niveau van het bedrijf. De grootte en markt waar op gericht wordt maakt niet zo veel uit, daar lijkt weinig onderscheid in te zitten. Het is vaker de kwestie of de mensen in het team überhaupt weten wat ze aan het doen zijn. Dat hoeft natuurlijk qua winst en productiviteit niet altijd wat uit te maken, je kan prima software maken zonder dat je weet wat er nou eigenlijk gebeurt als je op 'run' klikt. Probleem is dan wel dat mensen vaak gewoon te weinig van hun werk weten en zichzelf een vendor lock-in aansmeren door gewoon niet verder te willen leren/kijken. Dan moet je dus haast wel dezelfde tooling gebruiken, ook al had je de keuze, om dat de rest van je team anders niet met je code aan de slag kan.

Waar je voor kiest hangt natuurlijk van je eisen en wensen af. Voor mij is het eerder een mix:

- Niveau van het team
- Vrijheid van tooling
- Type project
- Beschikbaar budget voor tooling of resources voor self-hosting (bijv. GitLab vs. hosted Git om maar wat te noemen)

Stel dat iedereen gewoon op niveau is, iedereen mag gebruiken waar hij/zij zin in heeft en het project een doorsnee PHP/PGSQL/JS/HTML5 webapp moet uitpoepen, dan maakt het eigenlijk geen zak uit wat iedereen gebruikt, zolang de common tooling zoals coverage checks, tests, deployment tools, issue tracker, scm etc. hetzelfde is.

Als je ergens zit waar je een stapeltje Microsoft-mannen hebt die niet echt goed weten wat er tussen C#-code schrijven en software bij de klant afleveren gebeurt, dan zit je aan VS vast, met een beetje geluk kan je dan nog Git integratie gebruiken als je een beetje een recente versie hebt (al dan niet met een plugin), of heb je pech en moet je Microsoft's SCM idee gebruiken.

Het is een beetje een ruwe tegenstelling, maar dat zijn de kanten die ik het vaakst zie. Ik kies nooit meer voor een project waarbij je met een paar mensen moet werken die eigenlijk geen idee hebben van de manier waarop hun ingeklopte taal resulteert in bruikbare software. Leuk als je al je software engineering skills op orde hebt, maar zonder diepgang kan je gewoon niet vrij bewegen, en ik beweeg graag ;-)

[ Voor 22% gewijzigd door johnkeates op 09-04-2015 23:52 ]

[Avalaxy]

Als een taal geen goede IDE heeft maar je vrijwel gedwongen wordt om in Notepad te werken en je hebt geen enkele manier om fatsoenlijk te debuggen dan schrijf ik de taal eigenlijk al direct af. Ik wil productief zijn, daarvoor heb je goede tools nodig. Dat de andere taal dan misschien iets eleganter is dan mijn voorkeurstaal kan me aan mijn derrière oxideren.

[CodeCaster]

johnkeates schreef op donderdag 09 april 2015 @ 23:44:
Ik zou sowieso niet op een vacature duiken die voor een taal, ecosysteem of merk beperkt is.

Die luxe kan niet iedereen zich permitteren. Veel softwareshops en ontwikkelafdelingen binden zich (in mijn ervaring) toch gedurende lange tijd aan één platform, om zo het benodigde personeel voor ontwikkeling en beheer te kunnen selecteren.

Wil je brede ervaring opdoen en bij één werkgever met verschillende talen, tools en platforms kunnen werken, zul je naar een grotere club moeten, waar net zo goed de kans weer aanwezig is dat je op één type project terechtkomt en je wederom moet gaan specialiseren in, en binden aan, één platform.

[Kettrick]

De specifieke tooling maakt mij niet zo heel veel uit, hoewel mijn persoonlijke voorkeur IntelliJ is ( met als taal Java, Scala, Python, Golang ).

Wat voor mij wel een no-go gebied is Windows als ontwikkel/hosting omgeving. Ik werk ondertussen zo'n 15 jaar in een Mac/Unix omgeving en ben goed up to date met alle aspecten hiervan. Ik zou werkelijk geen idee hebben hoe ik een C# applicatie bouw, laat staan deploy.

Dit is overigens niet uit een mac-fanboy 'Ik haat windows" standpunt, ik zie ( welliswaar vanaf grote afstand ) best coole dingen gebeuren, en geloof meteen dan visual studio een geweldig product is. Ik zie het meer als een carriere-pad wat ik ben ingeslagen.

Verbreding is belangrijk, maar ik hou het wel binnen een bepaalde richting

[Gomez12]

Wmb kent tooling een aantal basis-onder vereisten (en die kunnen nog wel eens verschillen per taal / bedrijf etc) maar buiten die basis-onder vereisten is tooling compleet irrelevant voor mij als devver.

Als bedrijf heb je een soortgelijk standpunt (in wezen maakt het niet uit waar je medewerkers in werken) alleen is er 1 grote maar, je werknemers moeten wel guru's zijn in hun eigen tools.
Als er namelijk bijv een nieuwe Source control-solution naar binnen geschoven wordt dan moet er voor de non-guru's een simpele uitleg geschreven worden hoe die binnen 15 minuten de nieuwe oplossing moeten gebruiken in hun VS / IntelliJ of wat dan ook, en de mensen die eigen tools willen gebruiken die moeten binnen dezelfde 15 minuten de oplossing in hun tool geschoven hebben.
Als jij bij een nieuwe oplossing / uitbreiding 2 dagen moet gaan googlen hoe je TFS aan VimL moet koppelen dan gebruik je vanaf heden maar VS, want 2 dagen niet-productief zijn is erg kostbaar (of je moet een heel erg goede business case kunnen maken dat jij met VimL minimaal per x tijd 2 dagen productiever bent dan je collega's met VS).

Zelfde als er een nieuwe CI-server komt, of een nieuwe deploy methode of er vanwege VS 2015 opeens met grunt gewerkt moet gaan worden of ...

Als werkgever is de specifieke tooling van de werknemer niet zo relevant, zolang changes maar geen extra tijd kosten. En dat is waar het veelvoudig fout gaat, als een bedrijf zegt Resharper te gebruiken tegen zijn klanten, dan moet jij ook R# gebruiken en dat gaat niet vanuit VimL verwacht ik zo maar.

Dus nee ik herken me niet in jouw keuze, ik krijg eerder gewoon een vraag voor een product, daar kies ik de imho meest geschikte taal voor en daarbij komt dan een stuk tooling.

Maar ik denk ook dat het tegenwoordig twijfelachtig is om 1000'en uren te steken in het customizen van tooling, juist doordat de specifieke tooling zo kan veranderen.
Voor generieke tools als sublimetext etc wil ik nog wel eens wat customizen, maar specifieke tooling als VS of intelllij print ik gewoon een cheatsheet uit en die hang ik een maandje naast mijn bureau en ik besteed nog even 2 uurtjes aan het customizen van de tool (donkere theming etc) en dan is het gewoon productie draaien.
Uren en uren spenderen aan customizen van shortcuts / specifieke theming aanpassingen etc etc dat heb ik al jaren terug opgegeven, dat levert gewoon niets op. Want voor het volgende project kunnen de eisen weer anders zijn, de tools kunnen anders zijn etc. etc.
En tegenwoordig interesseert het me ook gewoon allemaal vrij weinig meer, de tools zijn ondertussen zo mature dat de default instellingen voor 80% goed zijn.

Zoals je zelf al zegt, jouw tooling sluit zo ongeveer de 2 grootste talen uit, waarschijnlijk nog een heleboel specifieke kleinere talen ook, waarmee je je beperkt tot het maar kunnen werken in een extreem smal segment

[Camulos]

Hatsieflatsie schreef op donderdag 09 april 2015 @ 22:31:
Ik kies de tooling waar ik mij thuis in voel, het prettigst mee overweg kan, en kijk vervolgens met welke talen-ie goed mee overweg kan.
Nu vraag ik mij af of er Tweakers die zich in deze omgekeerde keuze herkennen?

Zekers! Bij een programmeertaal zijn er vaak een paar best-in-class editors (betaald of gratis). Voor C# is het ongetwijfeld VS2013 (er is inmiddels een volledige gratis editie). Voor JAVA gebruik ik dan liever IntelliJ of Eclipse. Andere talen en snel ff sourcecode checken doe ik vaak in Notepad++, alhoewel ik ook wel gecharmeerd ben van Sublime.

Het strak vasthouden aan bepaalde tooling is alleen maar contraproductief (imo). Als jij Lisp specialist bent, en VIM/Emacs is daarbij de beste tooling dan is dat prima ^^ Verwacht alleen niet dat VIM/Emacs nu meteen de beste tooling voor alle talen is

Zelfde laken een pak: Een spijker sla je er met een hamer in... maar een schroef met een schroevendraaier... je kan de schroef ook wel met de hamer erin slaan maar het is niet de beste tool die je kunt gebruiken

[ Voor 9% gewijzigd door Camulos op 10-04-2015 08:37 ]

[Zoijar]

Hatsieflatsie schreef op donderdag 09 april 2015 @ 22:31:
Ik kies de tooling waar ik mij thuis in voel, het prettigst mee overweg kan, en kijk vervolgens met welke talen-ie goed mee overweg kan.

Nu vraag ik mij af of er Tweakers die zich in deze omgekeerde keuze herkennen?

Nee, sorry, ik heb niet de vrijheid om te zeggen, ik port deze miljoen regels even naar een andere taal want die IDE vind ik lekkerder werken

IDEs, talen... het is allemaal programmeren; ik doe geregeld drie verschillende talen in drie verschillende editors op een dag.

[maniak]

Als iets als een IDE belangrijk is voor je, dat je zelf wilt kiezen, moet je werken bij kleine bedrijven. Daar ben je meestal meer vrij in je keuzes. Grotere bedrijven hebben vaak al een ontwikkelstraat. Besef alleen wel dat jouw IDE maar een klein onderdeel is in een ontwikkelstraat. Je hebt te maken met allerlei disciplines. Programmeurs, testers, functioneel en technische ontwerpers, project leiding en eindgebruikers.

Wij gebruiken bijvoorbeeld Visual Studio met TFS omdat die alle disciplines samenbrengt maar ook omdat die automatisch build en deployed. Dit alles verhoogt de kwaliteit en de productiviteit significant.

Daarbij nog even de kanttekening, het zelf willen kiezen van een IDE klinkt mij alsof je niet echt in een team wilt werken.

[InZane]

maniak schreef op vrijdag 10 april 2015 @ 10:18:
Daarbij nog even de kanttekening, het zelf willen kiezen van een IDE klinkt mij alsof je niet echt in een team wilt werken.

Vind ik ook.
Ik kom bij redelijk veel bedrijven over de vloer en ik schik me naar hun manier van werken. Daar valt dus ook een IDE onder. Als C# prutser gebruik ik zelf (natuurlijk) graag Visual Studio en het liefst ook nog eens in combinatie met TFS, maar dat kan helaas niet altijd. Zo zat ik laatst nog bij een bedrijf waar ze MS SourceSafe gebruikten voor versiebeheer. Tja, het is even mopperen, maar je komt er gewoon niet onderuit.

Als je keuzevrijheid wilt qua tooling, kun je het beste bij een klein bedrijf aan de slag gaan.

[hackerhater]

Voor mij is de IDE om het even al werk ik het liefst met Eclipse.
Ik wil alleen absoluut niet werken op Windows. Er even mee moeten testen a la, maar verder wil ik er niet mee te maken hebben.

Dat is ook de reden waarom talen als C# tot nu toe altijd afvielen.

[maniak]

hackerhater schreef op vrijdag 10 april 2015 @ 11:47:
Voor mij is de IDE om het even al werk ik het liefst met Eclipse.
Ik wil alleen absoluut niet werken op Windows. Er even mee moeten testen a la, maar verder wil ik er niet mee te maken hebben.

Dat is ook de reden waarom talen als C# tot nu toe altijd afvielen.

Als ontwikkelaar doe je er verstandig aan om zo veel mogelijk talen te leren. Niet omdat je er mee hoeft te werken, maar voornamelijk om je kennis te verbreden over software ontwikkeling in het algemeen. Wellicht worden in C# dingen anders aangevlogen wat je goed kan toepassen in je Java project. Je wereld wordt namelijk erg klein als je nooit verdiept in andere dingen.

[InZane]

hackerhater schreef op vrijdag 10 april 2015 @ 11:47:
Voor mij is de IDE om het even al werk ik het liefst met Eclipse.
Ik wil alleen absoluut niet werken op Windows. Er even mee moeten testen a la, maar verder wil ik er niet mee te maken hebben.

Dat is ook de reden waarom talen als C# tot nu toe altijd afvielen.

Moet je zelf weten. Ik denk alleen dat je bij veel grote bedrijven niet aan de slag komt. Het grootste deel is nog steeds Windows + AD. Daar kom/mag je over het algemeen met je Linux/OSX doosje niet op.

[hackerhater]

maniak schreef op vrijdag 10 april 2015 @ 11:51:
Als ontwikkelaar doe je er verstandig aan om zo veel mogelijk talen te leren. Niet omdat je er mee hoeft te werken, maar voornamelijk om je kennis te verbreden over software ontwikkeling in het algemeen. Wellicht worden in C# dingen anders aangevlogen wat je goed kan toepassen in je Java project. Je wereld wordt namelijk erg klein als je nooit verdiept in andere dingen.

Ik heb C# gehad op mijn opleiding. Mijn kennis is ondertussen verouderd, maar dat betekend niet dat ik de taal niet ken.

Sowieso heb ik met C,C++,Python, JAVA en PHP genoeg talen achter de hand.

InZane schreef op vrijdag 10 april 2015 @ 11:53:
Moet je zelf weten. Ik denk alleen dat je bij veel grote bedrijven niet aan de slag komt. Het grootste deel is nog steeds Windows + AD. Daar kom/mag je over het algemeen met je Linux/OSX doosje niet op.

I know, evengoed blijft dit een harde eis van mijn kant. Ik heb jaren gewerkt met Windows (oa opleiding) en heb elk moment gehaat dat het moest. Geen enkele baan is dagelijkse frustratie waard.
Daarnaast werk ik nu bij een bedrijf van 25+ man en daar is het juist een pre dat ik ervaring met meerdere OS'en heb.

[Umbrah]

Tsja, als ik mensen spreek die bij ons willen komen werken, dan valt er in principe over alles te praten. Wat voorop staat is dat diegene een 'klik' moet hebben met ons, en dat moet vanuit beide kanten komen. Ik sluit me aan bij het begrip 'sourcecode = sourcecode", maar soms is aanpassing gewenst... als je een .Net dev aanneemt, dan is dat niet meer "alleen" een dev, hij moet ook wat meer kunnen, en .Net suggereert (en dat is niet altijd zo) een bepaalde omgeving. Vaak TFS, gekoppeld met eventueel IIS/Windows. Maar wederom: dat hoeft niet. Als het het leukste bedrijf is met de leukste collega's, dan zouden tools secundair moeten komen.

Hetgeen wederom niet wil zeggen dat het een het ander uitsluit... als je een geweldig leuk energiek team hebt, en (dat staat hier ook boven), iedereen zit érg lekker op VS2013 (soms gewoon puur omdat een klant dat heeft, of omdat het gewoon goed is), dan kan het zwáár irritant zijn als je ineens een 'zealot' er tussen hebt zitten die met een lading hacks van heb ik jou daar probeert met VIM mee te doen op de TFS repo... auw... zeker als het iemand is die vind dat hij een punt moet maken.

Het belangrijkste is houding. Iemand als 'hackerhater' zal ik niet snel als collega zien: hij sluit bij voorbaat al uit namelijk, en staat er niet zo pragmatisch in. Tsja... wat mijn baan betreft? Vele petten, uiteraard, maar inderdaad: vaak windows, persoonlijk gék op Visual Studio (en ja, ik ontwikkel dus ook python daarmee... puur omdat het me ligt), maar ook regelmatig loop ik rond in het *nix wereldje, en dan zit je idd binnen eclipse met apache-tooling/tomcat te werken. Je kan meningen hebben, en soms is iets minder leuk, maar je houding en de houding van je werkgever bepaalt hoe/of je een leuke baan kan hebben, of niet. Niemand die zin heeft in schuimbekkende mac-zeloten, unix-nekbaarden, of windows-droogstoppels (heb ik nu iedereen evenveel beledigd?). Je mag een voorkeur hebben, maar sluit het niet uit! Sterker nog: versterk je voorkeur. Bash op Windows, stukjes powershell op Linux, en uiteraard: welke IDE je maar wilt, of áltijd kunnen werken met je team (als 7 man + de klant graag alles in TFS heeft, wie ben jij dan?)

[Cyphax]

RobIII schreef op donderdag 09 april 2015 @ 23:26:
[...]

Assumptions are the mother of all....

Neemt niet weg dat VS écht wel een behoorlijk goede, stabiele en (IMHO) fijne IDE is en de ervaring (again, IMHO) vele malen beter is dan wanneer je ligt te frotten met allerlei aan-elkaar-ge-duct-tapete-losse-tools, batchfiles, makefiles, powershell scripts etc. om zo je workflow een beetje te stroomlijnen waar je in VS gewoon op F5 ramt. Wanneer heb je VS voor 't laatst serieus bekeken? 2003? Of 2013?

De enige reden dat ik thuis niets doe met C#, .NET en VS is dan ook omdat ik thuis een heel Linux-netwerk heb, en eigenlijk nauwelijks Windows gebruik, en Visual Studio er alleen voor Windows is. Maar met de koers die MS nu aan het varen is verwacht ik eigenlijk dat daar ook nog verandering in komt. En het hoeft dan echt niet per se open source te zijn allemaal.

Daarbuiten zou ik ook gewoon Visual Studio gaan gebruiken. 't Is hartstikke flexibel om in te richten. Als je geen toolbars en toolwindows wil, dan klik je die gewoon weg. Ik zou de debuggingmogelijkheden niet willen missen. Ik weet niet of die te integreren zijn met andere editors.

[AlphaRomeo]

hackerhater schreef op vrijdag 10 april 2015 @ 11:58:
.... Ik heb jaren gewerkt met Windows (oa opleiding) en heb elk moment gehaat dat het moest. Geen enkele baan is dagelijkse frustratie waard.

Sorry, maar als je niet universeler bent dan dat beperk je jezelf inderdaad behoorlijk in de banen die eventueel geschikt voor je zijn. Ook Windows en AD went na een tijdje, en de nieuwste Visual Studio versies, evenals het laatste .NET framework zijn mijns inziens van extreem hoge kwaliteit. Een voordeel van C# vind ik juist dat het niet zo versnipperd is qua IDE als bijvoorbeeld Java met tientallen ontwikkelomgevingen die allemaal weer andere pre-requisites en mogelijkheden hebben.

Ik ben misschien ook een beetje bevooroordeeld, maar werken met VS201x+Resharper is een genot.

[Ahrnuld]

Hatsieflatsie schreef op donderdag 09 april 2015 @ 22:31:
Een algemene vraag uit interesse. Wanneer je rondkijkt, zul je algauw opmerken dat er veel C#-vacatures zijn. Maar daarbij wordt er meestal Visual Studio en Microsoft-producten gebruikt. Dus daar ga ik al niet voor, ongeacht hoe goed C# als taal in elkaar steekt.
Nu vraag ik mij af of er Tweakers die zich in deze omgekeerde keuze herkennen?

De laatste jaren ben ik inderdaad de juiste ontwikkeltools steeds belangrijker gaan vinden, taal vind ik een stuk minder belangrijk. Het gaat er uiteindelijk om hoe productief je kunt zijn (en dan bij voorkeur op een prettige manier). Met een goede IDE kan je echt veel meer doen in dezelfde tijd dan met een texteditor en allerlei losse tools.

Wat trouwens juist de reden is dat ik graag Visual Studio gebruik...

[Schnupperpuppe]

Met een goede IDE kan je echt veel meer doen in dezelfde tijd dan met een texteditor en allerlei losse tools.

Da's een mening, geen feit.
Voor mij geldt precies het omgekeerde. Geen IDE biedt mij dezelfde flexibiliteit als mijn goed gevulde gereedschapskist met losse tools.
Ieder zijn ding.

[hackerhater]

@Umbrah
zij. Niet direct aannemen dat iedereen hier een man is.

Ik wil zelf niet met Windows werken. Het boeit mij compleet niet wat mijn collega's gebruiken. Het bedrijf waar ik werk gebruikt Linux, OS X en Windows door elkaar. Ik werk al 12 jaar op Linux en ken het OS van binnen en van buiten. Ik compileer nog net niet mijn eigen kernel (al zou ik het wel kunnen).

Of ik nu met een gui-tool werk of zelfs terug moet vallen op vi om live te debuggen op de server. Ik kan het allemaal. Op Windows voel ik me als een timmerman die je net zijn gereedschapskist afgepakt hebt. Het gaat niet om de IDE, maar om het complete plaatje.

[Umbrah]

Schnupperpuppe schreef op vrijdag 10 april 2015 @ 13:14:
[...]


Da's een mening, geen feit.
Voor mij geldt precies het omgekeerde. Geen IDE biedt mij dezelfde flexibiliteit als mijn goed gevulde gereedschapskist met losse tools.
Ieder zijn ding.

Niet mee eens, zeker als het een project is wat wat complexer is, als er UI-componenten meespelen, databases, en/of teamwerken. Je hebt tot op zekere hoogte een punt: "ik werk even snel"; "ik werk sneller". En daar denk ik dat je een goed punt hebt: efficiëntie. Als je op een bepaald punt ervaring zit, of op een bepaald niveau zit qua kennis, dan kom je op een moment dat het schrijven van de code dusdanig verwaarloosbaar tegenover het bediening van je tools qua tijdsbesteding, dat je haast kan stellen, dat die tools die er voor jou waren, je tegen werken. Dit is voor mij ook de reden geweest om uiteindelijk Visual Studio steeds meer te gaan waarderen: het 'ontzorgt' een hoop, het is volledig instelbaar, het heeft geweldige addins & extensions, en in principe, zodra ik het heb opgezet qua project/omgeving voor mijzelf, kan ik VS full-screen zetten over m'n 28" 4K-er en m'n 24" 1200P-er, en kloppen tot ik er bij neerval, terwijl ik bij sommige projecten waar ik vast zit aan het plakwerk/vim/etc op een of andere manier steeds maar bezig ben met interface/shortkeys/systeembeheer dingetjes. Ik ben een consultant, geen developer, maar ik ontkom er niet aan.

Dit moet echter geen "welles nietes" VS/C# discussie worden (hoewel de TS er wel mee begon als voorbeeld), maar meer "gebruiken wat er is" VS "gebruiken wat je wil". Geen werkgever wacht op eigenwijs, zeker als het niet praktisch is in die situatie. Wat niet wil zeggen dat er geen tijd en geen plaats is: uiteraard is die er wel als je het wil! En ga er nooit vanuit dat je het beter weet, of dat je het beter kan: er is altijd iemand die het nog beter weet en nog beter kan/in Visual Studio je voorbij code! (en hij weer gefrustreerd dat iemand in Eclipse hem voorbij gaat).

[Schnupperpuppe]

Umbrah schreef op vrijdag 10 april 2015 @ 13:23:
[...]

Niet mee eens, zeker als het een project is wat wat complexer is

Je bent het er niet mee eens dat het voor mij anders werkt dan voor jou?
Dat VS voor jou de ideale IDE is, prima, be my guest. Voor mij is een IDE een gruwel. Mag dat?

[hackerhater]

Umbrah schreef op vrijdag 10 april 2015 @ 13:23:
Dit moet echter geen "welles nietes" VS/C# discussie worden (hoewel de TS er wel mee begon als voorbeeld), maar meer "gebruiken wat er is" VS "gebruiken wat je wil". Geen werkgever wacht op eigenwijs, zeker als het niet praktisch is in die situatie. Wat niet wil zeggen dat er geen tijd en geen plaats is: uiteraard is die er wel als je het wil! En ga er nooit vanuit dat je het beter weet, of dat je het beter kan: er is altijd iemand die het nog beter weet en nog beter kan/in Visual Studio je voorbij code! (en hij weer gefrustreerd dat iemand in Eclipse hem voorbij gaat).

True, daarom gebruik ik ook een complete IDE voor het meeste werk.
Maar ik ben heel blij dat ik indien nodig naar een gewone editor of zelfs commandline tools kan grijpen als het nodig is.
Heel leuk die IDE, maar als je een bug zoekt die alleen op de server op treed heb je er niks aan. Dan is het heel handig als je met een commandline-editor of met de database op de commandline om kan gaan.

Het klopt dat je voorkeuren moeten passen in je werkomgeving. Ik weet dat mijn houding qua Windows een probleem is bij veel bedrijven en daarom mijn werk er ook op uit gezocht op dat het geen probleem is.
Ik kan niet werken aan de Windows-projecten, soit. 50 a 60% van de projecten hier zijn of cross-platform of *nix-only.

[Cyphax]

Schnupperpuppe schreef op vrijdag 10 april 2015 @ 13:14:
[...]


Da's een mening, geen feit.
Voor mij geldt precies het omgekeerde. Geen IDE biedt mij dezelfde flexibiliteit als mijn goed gevulde gereedschapskist met losse tools.
Ieder zijn ding.

Stiekem is Visual Studio grotendeels ongeveer dat; een editor met bijkomstige tools die je veelal ook los kunt gebruiken. Maar ik vermoed dat jij die tools op vergelijkbare manier aan elkaar geknoopt hebt, want ik kan me bijna niet voorstellen dat je helemaal met de hand wil debuggen ipv dat je breakpoints kan zetten en stack traces kan inzien?

[Schnupperpuppe]

Cyphax schreef op vrijdag 10 april 2015 @ 13:34:
[...]

Stiekem is Visual Studio grotendeels ongeveer dat; een editor met bijkomstige tools die je veelal ook los kunt gebruiken. Maar ik vermoed dat jij die tools op vergelijkbare manier aan elkaar geknoopt hebt, want ik kan me bijna niet voorstellen dat je helemaal met de hand wil debuggen ipv dat je breakpoints kan zetten en stack traces kan inzien?

Ja en nee. Het grote verschil is dat ik mijn eigen tools kan kiezen. In een IDE heeft iemand anders die tools voor je gekozen.

BTW, een debugger heb ik al 20 jaar niet meer gebruikt. Logging, logging en nog eens logging.

[AlphaRomeo]

Schnupperpuppe schreef op vrijdag 10 april 2015 @ 13:41:
BTW, een debugger heb ik al 20 jaar niet meer gebruikt. Logging, logging en nog eens logging.

Werkt misschien voor server side applicaties heel goed. Als je een vracht client side wiskunde zit te kraken is een debugger wel verrekte handig!

[Umbrah]

Een breakpoint invoeren (overigens: afhankelijk van je project kan dat natuurlijk ook op een server, daarom heb je een OTAP-stijl omgeving) is anders wel zo fijn, waardes uitlezen per object/klasse, en klaar. Uiteraard kan dat ook op een server zelfs al draai je niks lokaal. Sterker nog: je kan een debuggende applicatie, afhankelijk van je framework, overal onderbreken. Desnoods op de database zelfs. Mooie ASP.NET app met een silverlight frontend + een stuk middleware + MSSQL, breakpoint in de silverlight app, en je kan in feite steppen in de middleware, de MSSQL extensie, en ASP.Net modules; zelfs al draait het op je acceptatie binnen een live IIS omgeving.

[Cyphax]

Schnupperpuppe schreef op vrijdag 10 april 2015 @ 13:41:
[...]


Ja en nee. Het grote verschil is dat ik mijn eigen tools kan kiezen. In een IDE heeft iemand anders die tools voor je gekozen.

Dat hangt een beetje van de IDE af. Ik gebruik nog weleens Codeblocks en dat is allemaal heel flexibel. Je moet zelfs de debugger nog zelf koppelen. In Visual Studio is dat inderdaad minder los en wat meer totaalpakket.

BTW, een debugger heb ik al 20 jaar niet meer gebruikt. Logging, logging en nog eens logging.

Logging is ook een goede manier maar dat vind ik omslachtiger dan breakpoints kunnen zetten en door code heenlopen en variabelen bekijken on the fly

[Schnupperpuppe]

Umbrah schreef op vrijdag 10 april 2015 @ 13:44:
Een breakpoint invoeren (overigens: afhankelijk van je project kan dat natuurlijk ook op een server, daarom heb je een OTAP-stijl omgeving) is anders wel zo fijn, waardes uitlezen per object/klasse, en klaar. Uiteraard kan dat ook op een server zelfs al draai je niks lokaal. Sterker nog: je kan een debuggende applicatie, afhankelijk van je framework, overal onderbreken. Desnoods op de database zelfs. Mooie ASP.NET app met een silverlight frontend + een stuk middleware + MSSQL, breakpoint in de silverlight app, en je kan in feite steppen in de middleware, de MSSQL extensie, en ASP.Net modules; zelfs al draait het op je acceptatie binnen een live IIS omgeving.

Ik weet wat een debugger kan en hoe je hem moet gebruiken. Heb ze ook jarenlang gebruikt.
Tegenwoordig heeft logging/tracing mijn voorkeur. Ieder zijn ding.
En breakpoints zijn ook niet echt praktisch in tijd-kritische applicaties.
Debuggers zijn invasief, logging/tracing is dat niet of nauwelijks.

[InZane]

Cyphax schreef op vrijdag 10 april 2015 @ 13:50:
Logging is ook een goede manier maar dat vind ik omslachtiger dan breakpoints kunnen zetten en door code heenlopen en variabelen bekijken on the fly

Tja, logging is verder prima inderdaad, maar is wel wat spartaans in vergelijking met een breakpoint zetten en door je code kunnen wandelen.

Schnupperpuppe schreef op vrijdag 10 april 2015 @ 13:53:
Debuggers zijn invasief, logging/tracing is dat niet of nauwelijks.

True. Gelukkig werk ik over het algemeen aan webapplicaties en daar is het invasieve karakter van een debugger meestal niet zo'n issue.

[ Voor 28% gewijzigd door InZane op 10-04-2015 13:56 ]

[Umbrah]

Overigens mee eens dat debuggers invasive >KUNNEN< zijn (hangt wederom van je framework/ontwerp) af. Maar daarom werk je dus OTAP: Ontwikkel, test, acceptatie, productie, en heb je MEESTAL vanaf het begin af aan ook een tester aan boord die uiteraard WEET dat hij niet hoeft te performance testen tot "T"... en zelfs dan: de impact kent van een debugger. Het is maar net hoe professioneel je er mee om gaat.

[Schnupperpuppe]

Cyphax schreef op vrijdag 10 april 2015 @ 13:50:
[...]

Logging is ook een goede manier maar dat vind ik omslachtiger dan breakpoints kunnen zetten en door code heenlopen en variabelen bekijken on the fly

Met logging/tracing kun je je hele applicatie-flow volgen en vervolgens inzoomen op het probleemgebied. Met een debugger is dat veel omslachtiger. Als je een breakpoint wil zetten, moet je al vrij nauwkeurig weten waar het probleem zit.
Ook zijn debuggers niet zo handig als je meerdere processen hebt draaien die met IPC met elkaar babbelen.

[Cyphax]

Dan denk ik dat de beste conclusie is dat debugging en logging elkaar heel mooi kunnen aanvullen

[Schnupperpuppe]

InZane schreef op vrijdag 10 april 2015 @ 13:55:
[...]

True. Gelukkig werk ik over het algemeen aan webapplicaties en daar is het invasieve karakter van een debugger meestal niet zo'n issue.

Als een client een server-request doet, dan zit daar toch (hopelijk) een timeout op? Terwijl jij je server aan het debuggen bent schiet de client dus in een timeout. Lastig.

[InZane]

Schnupperpuppe schreef op vrijdag 10 april 2015 @ 14:02:
[...]


Als een client een server-request doet, dan zit daar toch (hopelijk) een timeout op? Terwijl jij je server aan het debuggen bent schiet de client dus in een timeout. Lastig.

Meestal zei ik ook
Als je de debugger 5 minuten op een breakpoint laat hangen, heb je inderdaad wel een keer een time-out te pakken ja.

[Schnupperpuppe]

Umbrah schreef op vrijdag 10 april 2015 @ 13:58:
Overigens mee eens dat debuggers invasive >KUNNEN< zijn (hangt wederom van je framework/ontwerp) af. Maar daarom werk je dus OTAP: Ontwikkel, test, acceptatie, productie, en heb je MEESTAL vanaf het begin af aan ook een tester aan boord die uiteraard WEET dat hij niet hoeft te performance testen tot "T"... en zelfs dan: de impact kent van een debugger. Het is maar net hoe professioneel je er mee om gaat.

Heeft weinig met OTAP te maken. Mijn punt is dat je applicatie zich anders gedraagt omdat je aan het debuggen bent. Dat is inherent aan een debugger.

[Schnupperpuppe]

InZane schreef op vrijdag 10 april 2015 @ 14:03:
[...]


Meestal zei ik ook
Als je de debugger 5 minuten op een breakpoint laat hangen, heb je inderdaad wel een keer een time-out te pakken ja.

Een web-applicatie met een timeout van 5 minuten? Ik dacht eerder aan 5 seconden.

[InZane]

Schnupperpuppe schreef op vrijdag 10 april 2015 @ 14:06:
[...]


Een web-applicatie met een timeout van 5 minuten? Ik dacht eerder aan 5 seconden.

Argh, je mist mijn punt..

[Schnupperpuppe]

InZane schreef op vrijdag 10 april 2015 @ 14:09:
[...]

Argh, je mist mijn punt..

Ja, blijkbaar. Wat was je punt? ;-)

[InZane]

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


Ja, blijkbaar. Wat was je punt? ;-)

Dat er in het geval van debugging niet van die strakke time-outs worden gehanteerd

[Schnupperpuppe]

Umbrah schreef op vrijdag 10 april 2015 @ 13:58:
Overigens mee eens dat debuggers invasive >KUNNEN< zijn (hangt wederom van je framework/ontwerp) af. Maar daarom werk je dus OTAP: Ontwikkel, test, acceptatie, productie, en heb je MEESTAL vanaf het begin af aan ook een tester aan boord die uiteraard WEET dat hij niet hoeft te performance testen tot "T"... en zelfs dan: de impact kent van een debugger. Het is maar net hoe professioneel je er mee om gaat.

Nee, debuggers >ZIJN< invasive. Een breakpoint 'breekt' de normale applicatie-flow.
En met tijd-kritisch doelde ik niet op performance, maar op een beperkt tijds-window van een bepaalde operatie. Als een server een client-request uitvoert, dan verwacht de client binnen een bepaalde tijd een antwoord, anders ontstaat er een fout-situatie. Zo'n tijds-window kan te kort zijn om iets zinnigs met een debugger uit te halen.
Met stand-alone applicaties heb je hier uiteraard minder snel last van.

[Schnupperpuppe]

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


Dat er in het geval van debugging niet van die strakke time-outs worden gehanteerd

Op die fiets.
Maar dan moet je dus de client aanpassen omdat je de server wilt debuggen. Lastig.

[Creepy]

Dat je dat in productie doet, dat snap ik. Maar op je development omgeving kan je prima de timeout anders configgen zodat je prima kan debuggen.

[Schnupperpuppe]

Creepy schreef op vrijdag 10 april 2015 @ 14:20:
Dat je dat in productie doet, dat snap ik. Maar op je development omgeving kan je prima de timeout anders configgen zodat je prima kan debuggen.

Omslachtig en werkt alleen in niet al te complexe omgevingen. Als je server bestaat uit meerdere processen (frontend/backend/database/...) dan wordt het al een heel gedoe.
Met logging schroef je het log-level wat omhoog en kun je op je gemak achteraf de log-file analyseren.
Ik heb mezelf aangeleerd om in iedere routine standaard de input en output te loggen. Meestal is dat al voldoende om een bug te kunnen traceren.
Op ontwikkel-systemen staat het log-level standaard op 'max'; op productie-systemen niet, maar heb ik vaak voldoende aanknopingspunten om achteraf(!) een probleem op te kunnen sporen.
Aan een debugger heb je achteraf(!) helemaal niets.

[Creepy]

Ik zeg niet dat logging niet goed is, maar persoonlijk heb ik vaker sneller het probleem te pakken als ik het probleem kan naspelen op mijn ontwikkelomgeving. Dan kan je daar ook gelijk mee verifieren dat je fix de juiste is i.p.v. alleen maar op logging af te gaan.

Wat vind je trouwens omslachtig en een heel gedoe? Met de tools die ik gebruik kan ik gelijk al andere configs gebruiken per omgeving dus daar hoef ik geen moeite voor te doen. Met 1 druk op de knop run ik m'n code of deploy ik dezelfde code op 1 van de verschillende omgevingen. Met de build tools van tegenwoordig is dat echt geen gedoe meer, ook niet op complexe omgevingen.

[InZane]

Schnupperpuppe schreef op vrijdag 10 april 2015 @ 14:27:
[...]


Omslachtig en werkt alleen in niet al te complexe omgevingen. Als je server bestaat uit meerdere processen (frontend/backend/database/...) dan wordt het al een heel gedoe.
Met logging schroef je het log-level wat omhoog en kun je op je gemak achteraf de log-file analyseren.

Omslachtig? De meeste applicaties waar ik aan werk bestaan uit een frontend, backend en database en soms nog wel meer en verdeeld over meerdere machines. Dat hoeft niet complex te zijn.

Ik heb mezelf aangeleerd om in iedere routine standaard de input en output te loggen. Meestal is dat al voldoende om een bug te kunnen traceren.
Op ontwikkel-systemen staat het log-level standaard op 'max'; op productie-systemen niet, maar heb ik vaak voldoende aanknopingspunten om achteraf(!) een probleem op te kunnen sporen.
Aan een debugger heb je achteraf(!) helemaal niets.

Nee natuurlijk heb je aan een een debugger achteraf niet veel, maar met een debugger is vaak wel makkelijk een issue op je dev. omgeving omhoog te toveren.

Ik wil verder helemaal niet zeggen dat je niet loggen. Natuurlijk moet dat.

Ik krijg een beetje appels, peren gevoel bij je reactie.

[Schnupperpuppe]

Creepy schreef op vrijdag 10 april 2015 @ 14:32:
Ik zeg niet dat logging niet goed is, maar persoonlijk heb ik vaker sneller het probleem te pakken als ik het probleem kan naspelen op mijn ontwikkelomgeving. Dan kan je daar ook gelijk mee verifieren dat je fix de juiste is i.p.v. alleen maar op logging af te gaan.

Wat vind je trouwens omslachtig en een heel gedoe? Met de tools die ik gebruik kan ik gelijk al andere configs gebruiken per omgeving dus daar hoef ik geen moeite voor te doen. Met 1 druk op de knop run ik m'n code of deploy ik dezelfde code op 1 van de verschillende omgevingen. Met de build tools van tegenwoordig is dat echt geen gedoe meer, ook niet op complexe omgevingen.

Wat ik omslachtig vind? Ik moet de ene omgeving aanpassen, omdat ik de andere omgeving wil debuggen.
Praat je over meerdere servers en/of server-processen, die allemaal hun eigen flow hebben, dan moet ik dus in de hele keten aanpassingen doen omdat ik ergens aan het eind van de keten iets wil debuggen. Met alle mogelijk bijwerkingen van dien.
Met puur logging heb ik dat probleem helemaal niet. Ik schroef het log-level omhoog, speel het probleem na, en achteraf heb ik alle informatie die ik nodig heb. Desnoods uit de complete keten.
Idem dito als ik een fix heb. Ik doe nog een keer hetzelfde als bovenstaand en kan in mijn logging verifiëren of de fix het probleem heeft verholpen.

Ik heb debuggers niet vervangen door logging uit masochistische overwegingen, maar uit praktische overwegingen. In mijn ervaring levert mij dat vrijwel altijd de informatie die ik nodig heb. Ik heb simpelweg geen use-case meer voor een debugger.

Ik doe regelmatig code-reviews en dan valt mij vaak op dat collega's code produceren die helemaal niets logt. Zo herken ik de 'debuggers' onder ons.
Logging is overigens niet alleen van belang om problemen op te sporen, maar levert ook andere waardevolle informatie over het gebruik van applicaties.

Het zal wel door mijn *nix achtergrond komen; daar is het usance om lekker veel te loggen :-)

[Schnupperpuppe]

InZane schreef op vrijdag 10 april 2015 @ 14:37:
[...]

Ik krijg een beetje appels, peren gevoel bij je reactie.

Helemaal waar. Appels en peren.
Mijn punt is dat ik peren veel lekkerder vind dan appels en dat ik daarom helemaal geen appels meer eet :-)

[CodeCaster]

Net zo'n sneer zou je kunnen maken naar de "loggers onder ons", namelijk de developers die niet de gehele keten begrijpen of onder controle hebben, en dan maar "op hoop van zegen" een aanpassing doen en nogmaals de hele flow aftrappen met dezelfde testcase om een fout op één plek hopelijk op te lossen.

Met een debugger kun je de uitvoering pauzeren, variabelen inspecteren en wijzigen en vervolgens vervolgen, daarbij in de gaten houdend dat de wijziging het juiste resultaat tot gevolg heeft.

Volgens de fans daarvan zou je met unit tests beide, namelijk logging en debugging, in theorie helemaal niet meer nodig hebben. Helaas wijst de praktijk toch telkens weer anders uit.

Ik hou van (verbose) logging, met name beslissingen ("Ik ga nu X doen want variabele Y heeft waarde Z"), maar dat is voor mij absoluut geen vervanging voor debugging.

Cyphax schreef op vrijdag 10 april 2015 @ 13:34:
[...]

Stiekem is Visual Studio grotendeels ongeveer dat

Precies. Het skelet van Visual Studio wordt door tig applicaties gedeeld. De editor is één van de meest briljante die ik ken (qua aanpassingsmogelijkheden door jou én add-ons, automatische aanvulling middels Intellisense en het gebruik van tabs). De diverse explorers (Solution, Test, Object, Server, Team) zijn geweldig om door je project, schijf en servers te bladeren en de koppeling met compilers en debuggers is gewoonweg fenomenaal. Switch eens van een C# naar C++-project en de volledige toolchain verandert, terwijl je scherm vrijwel identiek blijft met dezelfde mogelijkheden.

En dan de add-ons en plugins nog...

[ Voor 62% gewijzigd door CodeCaster op 10-04-2015 14:56 ]

[Creepy]

Schnupperpuppe: Het klinkt alsof je direct live aanpassingen maakt op je live omgeving? (wat ik me niet kan voorstellen).

Ik weet daarnaast niet wat je complex vindt, maar met tools ala Vagrant en Docker is het relatief makkelijk om op je ontwikkelomgeving dezelfde setup te hebben als je live omgeving. Ik hoef simpelweg nooit een omgeving aan te passen om te kunnen debuggen, dat is nu juist het nut van de verschillende omgevingen. Debuggen in de ontwikkelingomgeving, niet ergens anders.

[ Voor 6% gewijzigd door Creepy op 10-04-2015 14:58 ]

[Schnupperpuppe]

CodeCaster schreef op vrijdag 10 april 2015 @ 14:49:
Net zo'n sneer zou je kunnen maken naar de "loggers onder ons",

Het was niet als sneer bedoeld. Excuses als het toch zo over is gekomen.

Met een debugger kun je de uitvoering pauzeren, variabelen inspecteren en wijzigen en vervolgens vervolgen, daarbij in de gaten houdend dat de wijziging het juiste resultaat tot gevolg heeft.

Dat kan zeker. Maar je wijkt daarmee af van de normale flow.
Daarom prefereer ik logging.

Volgens de fans daarvan zou je met unit tests beide, namelijk logging en debugging, in theorie helemaal niet meer nodig hebben. Helaas wijst de praktijk toch telkens weer anders uit.

Eensch. Unit tests zijn slechts een onderdeel van je QA en dekken allen situaties af die je vooraf hebt bedacht. De meeste bugs komen aan het licht in situaties die je niet vooraf hebt kunnen bedenken.

[InZane]

CodeCaster schreef op vrijdag 10 april 2015 @ 14:49:
Volgens de fans daarvan zou je met unit tests beide, namelijk logging en debugging, in theorie helemaal niet meer nodig hebben. Helaas wijst de praktijk toch telkens weer anders uit.

Ja in een ideale wereld zou iedereen eerst netjes alle unit tests schrijven voordat er ook maar iets aan functionaliteit gebouwd wordt. In de praktijk zie je het nergens gebeuren. Daar maak ik me zelf ook schuldig aan trouwens

[Schnupperpuppe]

Creepy schreef op vrijdag 10 april 2015 @ 14:56:
Schnupperpuppe: Het klinkt alsof je direct live aanpassingen maakt op je live omgeving? (wat ik me niet kan voorstellen).

Nee, natuurlijk niet. Of er moet echt bloed uit lopen ;-)

Ik weet daarnaast niet wat je complex vindt, maar met tools ala Vagrant en Docker is het relatief makkelijk om op je ontwikkelomgeving dezelfde setup te hebben als je live omgeving. Ik hoef simpelweg nooit een omgeving aan te passen om te kunnen debuggen, dat is nu juist het nut van de verschillende omgevingen.

Wij hebben het over verschillende begrippen van 'omgeving'. Met OTAP geef je een scheiding aan tussen verschillende omgevingen. Wat ik bedoel is dat je binnen een omgeving ook verschillende systemen kunt hebben. Dan bedoel ik client- en server-systemen en/of verschillende server-processen.
Binnen je ontwikkel-omgeving kun je te maken hebben met een hele keten van systemen die allemaal met elkaar praten. Wil je een debugger gebruiken in 1 schakeltje van die keten, dan kan dat onverwachte effecten hebben op de andere schakels in de keten.

[johnkeates]

Schnupperpuppe schreef op vrijdag 10 april 2015 @ 15:03:
[...]
Wil je een debugger gebruiken in 1 schakeltje van die keten, dan kan dat onverwachte effecten hebben op de andere schakels in de keten.

Je hoeft je debugger natuurlijk niet live te attachen he. Gezien je runtime met je debugger toch geen wijzigingen gaat maken kan je natuurlijk ook prima een call grind maken. Nul invasie, alle data.

[Schnupperpuppe]

johnkeates schreef op vrijdag 10 april 2015 @ 15:13:
[...]


Je hoeft je debugger natuurlijk niet live te attachen he. Gezien je runtime met je debugger toch geen wijzigingen gaat maken kan je natuurlijk ook prima een call grind maken. Nul invasie, alle data.

Dat noem ik niet debuggen, maar tracen en valt dus onder mijn werkwijze van loggen/tracen.
Met debuggen bedoel ik breakpoints, single-steppen, etc. Kan zijn dat jouw debugger de mogelijkheid biedt om te tracen, maar het blijft tracen...

[Avalaxy]

Je kunt in .NET gewoon een debugsessie 'opnemen' op je productie-omgeving en lokaal afspelen en daarbij alles doen wat je normaal zou doen (waardes bekijken, er doorheen steppen, breakpoints zetten), dat is gewoon debuggen.

[CodeCaster]

Dat kost gelukkig ook maar € 6.500 per Ultimate-licentie die je nodig hebt voor IntelliTrace, of doel je op iets anders?

[ Voor 43% gewijzigd door CodeCaster op 10-04-2015 16:43 ]

[Schnupperpuppe]

Avalaxy schreef op vrijdag 10 april 2015 @ 15:55:
Je kunt in .NET gewoon een debugsessie 'opnemen' op je productie-omgeving en lokaal afspelen en daarbij alles doen wat je normaal zou doen (waardes bekijken, er doorheen steppen, breakpoints zetten), dat is gewoon debuggen.

Dat klinkt dan wel weer als een bruikbare feature.

[ValHallASW]

CodeCaster schreef op vrijdag 10 april 2015 @ 16:37:
Dat kost gelukkig ook maar € 6.500 per Ultimate-licentie die je nodig hebt voor IntelliTrace, of doel je op iets anders?

En €2750 per jaar daarna. Valt toch best mee voor tooling die iemand (die op jaarbasis toch minstens het tienvoudige van die 6500 euro kost) elke dag, de hele dag, gebruikt?

[SPee]

CodeCaster schreef op vrijdag 10 april 2015 @ 14:49:
Ik hou van (verbose) logging, met name beslissingen ("Ik ga nu X doen want variabele Y heeft waarde Z"), maar dat is voor mij absoluut geen vervanging voor debugging.

Autch... Dit heeft toch wel een performance impact.


Maar om weer ontopic te gaan: Wat kies je eerst: tooling of de taal?

Ik zou er zelfs nog een bij doen: de omgeving.
Waar komt straks je applicatie te draaien? Ga je voor C# en VS, maar draait het in productie op Linux, dan werkt dat niet lekker (offtopic: kan wel, maar niet 100% veilig in werking en minder tools)
Ook beheerders hebben hun tooling en wensen.
Dit kan je keus ook al beperken.

Pas als je de omgeving waar je applicatie gaat draaien weet, dan kun je de keuze voor taal maken.
En m.i. pas daarna de keuze omtrendt tooling om mee te ontwikkelen. Hoewel bij een enkele taal er vrijwel maar 1 reële keus is (vb C# => VS).

Een IDE is er om de ontwikkelaar te helpen om sneller 'zijn ding' te laten doen.
Dus autocomplete, genereren van code, refactoren, etc. Vim en Emacs zijn teveel text editors, waardoor dingen als refactoring minder snel gaan. (of je bent veel tijd kwijt aan het maken van scripts, terwijl dit in je IDE zit).
True, soms gebruik ik een simpele texteditor om een code bestand te bekijken, maar vrijwel nooit om aanpassingen te doen. Zeker niet als er meerdere classes bij betrokken zijn.

[Schnupperpuppe]

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

Vim en Emacs zijn teveel text editors, waardoor dingen als refactoring minder snel gaan. (of je bent veel tijd kwijt aan het maken van scripts, terwijl dit in je IDE zit).

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.

[Avalaxy]

CodeCaster schreef op vrijdag 10 april 2015 @ 16:37:
Dat kost gelukkig ook maar € 6.500 per Ultimate-licentie die je nodig hebt voor IntelliTrace, of doel je op iets anders?

Hmm, daar was ik niet op de hoogte. Ik heb zelf Ultimate via MSDN dus weet niet echt wat de ultimate features zijn

[gekkie]

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.

Dat is makkelijk gezegd .. noem dan eens een aantal zaken die VIM zo briljant maken dat geen enkele IDE editor daar bij in de buurt komt ?

[CodeCaster]

ValHallASW schreef op vrijdag 10 april 2015 @ 17:33:
[ Visual Studio Ultimate ]

En €2750 per jaar daarna. Valt toch best mee voor tooling die iemand (die op jaarbasis toch minstens het tienvoudige van die 6500 euro kost) elke dag, de hele dag, gebruikt?

Het is een veelvoud van Professional en oneindig veel duurder dan Community, dus het moet de investering wel waard zijn. Ik ga het voor mezelf niet kopen, maar zal niet klagen als een opdrachtgever een licentie over heeft.

SPee schreef op vrijdag 10 april 2015 @ 17:54:
[ Debug-logging / tracing ]
Autch... Dit heeft toch wel een performance impact.

Verwaarloosbaar. Het loglevel stel je in configuratie in, dus tenzij je een issue probeert te troubleshooten, staat staat op productie het niveau hopelijk niet op trace/debug.

Een if (logger.DebugEnabled) in je Log.Debug()-methode is ook verwaarloosbaar, zeker gezien de gemiddelde applicatie praat met databases en webservices, wat een veel grotere impact op de performance heeft.

[ Voor 6% gewijzigd door CodeCaster op 10-04-2015 20:24 ]

[Hatsieflatsie]

gekkie schreef op vrijdag 10 april 2015 @ 20:00:
[...]

Dat is makkelijk gezegd .. noem dan eens een aantal zaken die VIM zo briljant maken dat geen enkele IDE editor daar bij in de buurt komt ?

Een voorbeeld is modus editing in alle uithoeken van je editor.

Dan is het alsof je 3 toetsenborden tegelijk onder je handen hebt, zonder dat je hoeft te navigeren naar de muis of naar sneltoetsen (Ctrl, Alt, Meta, etc). .

[gekkie]

Hatsieflatsie schreef op vrijdag 10 april 2015 @ 20:56:
[...]
Een voorbeeld is modus editing in alle uithoeken van je editor.

Dan is het alsof je 3 toetsenborden tegelijk onder je handen hebt, zonder dat je hoeft te navigeren naar de muis of naar sneltoetsen (Ctrl, Alt, Meta, etc). .

Hmm geen idee wat het is .. google doet ook geen wonderen in dit geval ...

Maar goed aangezien er niets bij in de buurt komt heb je vast nog wel een iets minder obscure voorbeelden

[WernerL]

VIM keybindings zijn rete handig. (Ik denk dat dat is wat Hatsieflatsie bedoeld) Stiekem mis ik het ook wel een beetje in andere editors. Maar alleen dat vervangt voor mij nog geen goede IDE.

Ik kies per taal uit wat het meest geschikt is. Bij voorkeur een goede IDE. Hoewel een goede build tool ook al veel kan helpen. In Scala wordt bijvoorbeeld SBT vaak gebruikt en dan boeit het geen reet meer waarin je programmeert. Unit tests draai je via SBT, compilen doe je via SBT, dependencies voeg je toe via SBT. SBT kan ook code-changes in de gaten houden zodat je niet handmatig iedere keer hoeft te compilen tijdens het ontwikkelen. Dan heb je alleen nog maar de editor nodig voor code completion, en breakpoints als je die wil gebruiken. Gedit + SBT open in de build-in terminal van Gedit werkt voor mij meer dan prima.

[ Voor 7% gewijzigd door WernerL op 10-04-2015 23:17 ]

[Hatsieflatsie]

gekkie schreef op vrijdag 10 april 2015 @ 22:19:
[...]

Hmm geen idee wat het is .. google doet ook geen wonderen in dit geval ...

http://stackoverflow.com/a/1220118/2826258

Wellicht dat dit een en ander verduidelijkt.

[gekkie]

Hatsieflatsie schreef op vrijdag 10 april 2015 @ 23:34:
[...]
http://stackoverflow.com/a/1220118/2826258

Wellicht dat dit een en ander verduidelijkt.

Yups .. flinke berg automagie .. opzich wel sneller .. als je het dermate vaak gebruikt dat het ook in je kop blijft zitten
Maar goed ook wel een dodelijke leercurve lijkt me .. zodat je dat niet al te snel bereikt.

[Hatsieflatsie]

gekkie schreef op vrijdag 10 april 2015 @ 23:55:
[...]

Yups .. flinke berg automagie .. opzich wel sneller .. als je het dermate vaak gebruikt dat het ook in je kop blijft zitten
Maar goed ook wel een dodelijke leercurve lijkt me .. zodat je dat niet al te snel bereikt.

Even snel een voorbeeld bij gezocht.

Dus je typt een soort taal om te vertellen wat-ie moet doen, zonder dat je alles handmatig moet doen. Dat compenseert het gebrek aan intelligente autocompletion zoals Eclipse en Visual Studio gelukkig, alhoewel je dat ook in Vim kunt integreren (www.eclim.org )

[ Voor 4% gewijzigd door Hatsieflatsie op 11-04-2015 00:30 ]

[WernerL]

gekkie schreef op vrijdag 10 april 2015 @ 23:55:
[...]

Yups .. flinke berg automagie .. opzich wel sneller .. als je het dermate vaak gebruikt dat het ook in je kop blijft zitten
Maar goed ook wel een dodelijke leercurve lijkt me .. zodat je dat niet al te snel bereikt.

Hoe vaker je VIM gebruikt, hoe leuker en makkelijker het wordt. Maar je blijft wel leren ja. Ik vraag mezelf af hoelang het duurt voordat je VIM voor de volle 100% kunt benutten. Maar even 1 dag je best doen om het belangrijkste te leren en je bent al een heel stuk productiever dan in een andere editor. :-)

[SlaadjeBla]

Ik gebruik VSVim voor Vim functionaliteit in Visual Studio. Werkt uitstekend.

Ik ben VSVim pas gaan gebruiken nadat ik Visual Studio al jaren professioneel gebruikte en daarnaast af en toe wat hobbyde in linux. Niet alleen overal "dezelfde" editor te kunnen gebruiken, de keybindings zijn ook gewoon goed doordacht en bieden vooral veel werkcomfort omdat je de muis veel minder nodig hebt voor navigeren en je veel met weinig toetsaanslagen kunt. Het zijn kleine dingen, maar waarom zou ik het laten? (leercurve daargelaten)

[Schnupperpuppe]

gekkie schreef op vrijdag 10 april 2015 @ 20:00:
[...]

Dat is makkelijk gezegd .. noem dan eens een aantal zaken die VIM zo briljant maken dat geen enkele IDE editor daar bij in de buurt komt ?

Jeetje, waar moet ik beginnen...

• Draait op zo'n beetje op ieder platform
• Betrouwbaar
• Bloedsnel, ook met zeer grote bestanden
• Geen muis nodig
• Highly customisable + scriptable
• Zowel beschikbaar in GUI als in CLI
• Zeer krachtige search/replace met reguliere expressies
• Integratie met shell commando's
• Snapt zo'n beetje iedere programmeertaal

Er is ook een groot nadeel: learning curve.
Vim is een draak om onder de knie te krijgen, maar als dat eenmaal is gelukt,
wil je nooit meer wat anders :-)

[Ruudjah]

Hét probleem van VIM en dergelijke is dat het een fundamentele tekstbewerking is. Leuk dat je de beste textautomatiseringstools goed kan bedienen. Maar bij sourcebase changes gaat het om changes in de AST, dat dit ook kan op textniveau is bijzaak.

Jouw texteditor kan niet een symbol rename doen (met een handig in elkaargeknutseld script kom je denk ik nog best een eind). Een goede IDE doet dat out-of-the-box en vraagt je om precies de relevante parameters. Om nog maar niet na te denken over geavanceerdere refactorings als "replace enum with interface".

[Schnupperpuppe]

Ruudjah schreef op zaterdag 11 april 2015 @ 11:38:
Hét probleem van VIM en dergelijke is dat het een fundamentele tekstbewerking is. Leuk dat je de beste textautomatiseringstools goed kan bedienen. Maar bij sourcebase changes gaat het om changes in de AST, dat dit ook kan op textniveau is bijzaak.

Jouw texteditor kan niet een symbol rename doen (met een handig in elkaargeknutseld script kom je denk ik nog best een eind). Een goede IDE doet dat out-of-the-box en vraagt je om precies de relevante parameters. Om nog maar niet na te denken over geavanceerdere refactorings als "replace enum with interface".

Tja, daar zit nou exact het verschil van opvatting.
Ik ben van de *nix filosofie. "Do One Thing and Do It Well" en "The Right Tool For The Right Job".
Symbol rename en refactoring zijn, in mijn opvatting, geen taken van een editor. Daar heb je andere tools voor die dat heel goed kunnen. Ik heb niks met "Jack Of All Trades".
Ieder zijn ding.

[Ruudjah]

Mijn punt is nu juist dat voor sourcecode editing een teksteditor geen goede tool is. Het doet misschien one thing,maar zeker niet well. Omdat je dus op een fundamenteler niveau wil gaan bewerken, namelijk dat op AST niveau.

Nu we het toch over die *nix filosofie hebben, die is wat mij betreft ook flawed qua implementatie in *nix. Waarom? Iemand anders dan ik zei het veel beter:

Everything should be as simple as it can be, [...] but not simpler.

Het probleem is niet zozeer de *nix filosofie, als wel de implementatie. Die zuigt, namelijk: de tools moet je aansturen met: jawel, daar is ie weer: tekst. Als tool an sich werkt dat en conformeert dat aan bovenstaande quote van Einstein. Hetgaat alleen verschrikkelijk op z'n bek als die tools met elkaarmoeten gaan samenwerken. Dan is de doorgeschoten eenvoud opeens een factor wat tegenhoud. Leesvoer.

De filosofie zélf vind ik dan bijvoorbeeld ontzettend goed werken in de context van libraries.

[Schnupperpuppe]

Ruudjah schreef op zaterdag 11 april 2015 @ 12:04:
Mijn punt is nu juist dat voor sourcecode editing een teksteditor geen goede tool is. Het doet misschien one thing,maar zeker niet well. Omdat je dus op een fundamenteler niveau wil gaan bewerken, namelijk dat op AST niveau.

Dat is wat jij wilt. Dat is niet wat ik wil.
Als ik aan het editen ben, dan wil ik de editor gebruiken die dat (voor mij) het beste kan.
De rest interesseert me geen moer op dat moment. Wat heb ik aan al die extra 'features'
wanneer de basis-functionaliteit sub-par is? Nogmaals, voor mij.
Ieder zijn ding.

[Ruudjah]

Dit is simpelweg een gevolg van hoe het systeem in elkaar steekt. En niet meer dan een redelijk preferentieloze observatie. Dan kan je wel eigenwijs zitten doen dat het allemaal voor jouw niet geldt, maar dan doe je oogkleppen op. Accepteer de wereld hoe het in elkaar zit, dat is veel handiger kan ik uit eigen ervaring vertellen.

Een alternatief is bijvoorbeeld om jezelf te trainen in louter AST-bewerkingen. Dan heb je ook een steile leercurve (maar als je met vim e.d. werkt heb je inmiddels ervaring opgedaan hoe je die steile leercurve te lijf kan gaan), maar je kan veel krachtigere bewerkingenop je codebase uitvoeren.

[Amanush]

Vim is geweldig, period.

[Schnupperpuppe]

Ruudjah schreef op zaterdag 11 april 2015 @ 12:19:
Dit is simpelweg een gevolg van hoe het systeem in elkaar steekt. En niet meer dan een redelijk preferentieloze observatie. Dan kan je wel eigenwijs zitten doen dat het allemaal voor jouw niet geldt, maar dan doe je oogkleppen op. Accepteer de wereld hoe het in elkaar zit, dat is veel handiger kan ik uit eigen ervaring vertellen.

Een alternatief is bijvoorbeeld om jezelf te trainen in louter AST-bewerkingen. Dan heb je ook een steile leercurve (maar als je met vim e.d. werkt heb je inmiddels ervaring opgedaan hoe je die steile leercurve te lijf kan gaan), maar je kan veel krachtigere bewerkingenop je codebase uitvoeren.

Ik vind je reactie eerlijk gezegd nogal arrogant. Sorry hoor.
Jij weet helemaal niets over mijn ervaring, je kent mij nl. niet, maar vindt wel je eigen ervaring superieur. Je poneert je mening als feit.
Relax. Ieder zijn ding.

[Ruudjah]

Als je codebase changes wil doen, dan wil je over het algemeen dat je code na de change nog steeds compiled. Dit betekend dat je een codebase change kan zien als een change in je AST. Daar is niets nieuws aan, zo doen we het al decennia.

Een teksteditor bewerkt tekst. Een IDE bewerkt een codebase.

Dat de toepassing van de *nix filosofie met *nix tool interactie stroef verloopt, is simpelweg een observatie.

Bovenstaande dingen liggen buiten mijn voorkeursveld. Het gaat hier nog even helemaal niet over mijn of jouw ervaring. Ik krijg de indruk dat jij bovenstaande feiten niet accepteert.

[Schnupperpuppe]

Ruudjah schreef op zaterdag 11 april 2015 @ 12:39:
Als je codebase changes wil doen, dan wil je over het algemeen dat je code na de change nog steeds compiled. Dit betekend dat je een codebase change kan zien als een change in je AST. Daar is niets nieuws aan, zo doen we het al decennia.

Een teksteditor bewerkt tekst. Een IDE bewerkt een codebase.

Exacto. Als ik mijn tekst (code) wil editen, dan wil ik mijn tekst editen. Ik wil niet mijn 'codebase bewerken', ik wil mijn code editen. Capice?

Dat de toepassing van de *nix filosofie met *nix tool interactie stroef verloopt, is simpelweg een observatie.

Nee, dat is simpelweg een mening. Mijn mening is een andere.

Bovenstaande dingen liggen buiten mijn voorkeursveld. Het gaat hier nog even helemaal niet over mijn of jouw ervaring. Ik krijg de indruk dat jij bovenstaande feiten niet accepteert.

Daar gaat 'ie weer. Jouw mening weerspiegelt niet noodzakelijkerwijs de feiten. Ik krijg de indruk dat je dat feit niet accepteert.

[CodeCaster]

Schnupperpuppe schreef op zaterdag 11 april 2015 @ 12:47:
[...]


Exacto. Als ik mijn tekst (code) wil editen, dan wil ik mijn tekst editen. Ik wil niet mijn 'codebase bewerken', ik wil mijn code editen.

Code is meer dan tekst. Code raakt ook vaak meer dan één bestand. Als je een member van een klasse hernoemt, wil je dat die wijziging consequent door de gehele codebase wordt doorgevoerd, en niet toevallig op alle plekken waar een losstaand woord met dezelfde naam voorkomt.

De keren dat ik de 'trucs' nodig heb waar vi(m) in uitblinken, ben ik niet met code bezig maar met data als JSON, XML en CSV. De bewerkingen die daarbij getoond worden, kan ik met een regex-replace vaak net zo snel uitvoeren, en dan hoef ik geen toetsencombinaties te gebruiken die me aan één editor binden.

[Schnupperpuppe]

CodeCaster schreef op zaterdag 11 april 2015 @ 13:06:
[...]

Code is meer dan tekst. Code raakt ook vaak meer dan één bestand. Als je een member van een klasse hernoemt, wil je dat die wijziging consequent door de gehele codebase wordt doorgevoerd, en niet toevallig op alle plekken waar een losstaand woord met dezelfde naam voorkomt.

Daar ben ik het niet mee oneens. De vraag is of dat een primaire taak van een editor is cq. zou moeten zijn.

De keren dat ik de 'trucs' nodig heb waar vi(m) in uitblinken, ben ik niet met code bezig maar met data als JSON, XML en CSV. De bewerkingen die daarbij getoond worden, kan ik met een regex-replace vaak net zo snel uitvoeren, en dan hoef ik geen toetsencombinaties te gebruiken die me aan één editor binden.

Dan bevind je je misschien nog op het stijle gedeelte van de learning curve ;-)
Het zijn nl. geen 'trucs'. Het zit allemaal heel logisch in elkaar, mits je de filosofie onder de knie hebt.
Dat laatste kan overigens wel een struikelblok zijn. Dat geef ik onmiddellijk toe.

M.b.t. het je aan één editor binden. Bekijk het eens andersom: je hoeft maar één editor te kennen. Die kun je vervolgens overal gebruiken :-)

[Herko_ter_Horst]

Schnupperpuppe schreef op zaterdag 11 april 2015 @ 13:14:
M.b.t. het je aan één editor binden. Bekijk het eens andersom: je hoeft maar één editor te kennen. Die kun je vervolgens overal gebruiken :-)

"If all you have is a hammer, everything starts to look like a nail."

Lijk jij ook wel 'last' van te hebben... "Ik heb een editor die goed is in tekstbewerking (hammer), dus ik beschouw code als tekst (nail)".

[Lethalis]

hackerhater schreef op vrijdag 10 april 2015 @ 13:20:
@Umbrah
zij. Niet direct aannemen dat iedereen hier een man is.

Ik wil zelf niet met Windows werken. Het boeit mij compleet niet wat mijn collega's gebruiken. Het bedrijf waar ik werk gebruikt Linux, OS X en Windows door elkaar. Ik werk al 12 jaar op Linux en ken het OS van binnen en van buiten. Ik compileer nog net niet mijn eigen kernel (al zou ik het wel kunnen).

Of ik nu met een gui-tool werk of zelfs terug moet vallen op vi om live te debuggen op de server. Ik kan het allemaal. Op Windows voel ik me als een timmerman die je net zijn gereedschapskist afgepakt hebt. Het gaat niet om de IDE, maar om het complete plaatje.

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.

[Gomez12]

Schnupperpuppe schreef op zaterdag 11 april 2015 @ 13:14:
[...]
M.b.t. het je aan één editor binden. Bekijk het eens andersom: je hoeft maar één editor te kennen. Die kun je vervolgens overal gebruiken :-)

Je kan hem overal gebruiken als je eerst alles maar omvormt naar een niveau van text-editing.

Jij bent gewoon met andere dingen bezig als menig developer, jij wilt alleen tekst bewerken...

Datzelfde zie je ook terug in je eerdere statements dat je niet debugt maar logged. Wat in mijn ervaring gewoon de helft weggooien is. Ik log in de basis verbose, maar ik log niet elke regel. Kom ik toch in de situatie dat mijn logging tekort schiet dan ga ik verder met debuggen omdat ik het dan opeens op statement niveau kan benaderen (dit niveau ga je nooit bereiken met logging).
En logging niet invasive, tja ik heb vaak genoeg tight-loops waar ik toch echt de logging maar weer uit ben gaan halen en bij default een breakpoint neergezet omdat de logging 10% van de tijd in die tight loop was (en dan hebben wij nog 2 methodes van logging, 1 algemene die direct naar log-server logt en 1 snelle die lokaal logt alleen)
Logging is cheap, maar het is zeker niet gratis en het werkt altijd mee

Hetzelfde heb je met dat jij zegt dat het debuggen moeilijker is in een complex proces omdat je meerdere plekken moet aanpassen qua timeouts etc. Maar je mist even compleet dat jij op dezelfde plekken je logging-niveau moet aanpassen.
Of je nou logged of debugged, in een complexe omgeving ga je voor troubleshooting settings binnen je omgeving moeten veranderen en die settings zijn qua plaats relatief gelijk (als je het goed opgezet hebt).
Geef jij vanaf een client-proces het log-niveau steeds door naar boven tot aan de server, hetzelfde kan je doen met timeouts etc.

In wezen is wat ik bedoel te zeggen : Code is niet enkel tekst editten, het is tekst editten binnen een specifieke context.
Qua textuele waarde maakt het niet uit of ik nou een "enif" schrijf of "endif" of "end if".
Maar qua code waarde maakt het wel een heleboel uit en dan heb ik toch liever direct een rood lijntje eronder als ik het verkeerd type binnen de huidige context.

En dan zullen er vast wel weer allemaal plugins etc aangedragen worden die het allemaal wel weer kunnen, maar guess what. Met die plugins ben je enkel maar bezig een IDE te bouwen om de lacunes van enkel tekst-editen op te vangen, waarom dan niet direct een IDE pakken?

[Schnupperpuppe]

Gomez12 schreef op zaterdag 11 april 2015 @ 14:37:
[...]

Je kan hem overal gebruiken als je eerst alles maar omvormt naar een niveau van text-editing.

Hoezo omvormen? Code is tekst.

Jij bent gewoon met andere dingen bezig als menig developer, jij wilt alleen tekst bewerken...

Klopt. Mag ik?

Datzelfde zie je ook terug in je eerdere statements dat je niet debugt maar logged. Wat in mijn ervaring gewoon de helft weggooien is. Ik log in de basis verbose, maar ik log niet elke regel. Kom ik toch in de situatie dat mijn logging tekort schiet dan ga ik verder met debuggen omdat ik het dan opeens op statement niveau kan benaderen (dit niveau ga je nooit bereiken met logging).

Geloof me. Ik heb jarenlang debuggers gebruikt. Nu niet meer. En nee, ik ben geen masochist.
Mag ik?

En logging niet invasive, tja ik heb vaak genoeg tight-loops waar ik toch echt de logging maar weer uit ben gaan halen en bij default een breakpoint neergezet omdat de logging 10% van de tijd in die tight loop was (en dan hebben wij nog 2 methodes van logging, 1 algemene die direct naar log-server logt en 1 snelle die lokaal logt alleen)
Logging is cheap, maar het is zeker niet gratis en het werkt altijd mee

Eens.

Hetzelfde heb je met dat jij zegt dat het debuggen moeilijker is in een complex proces omdat je meerdere plekken moet aanpassen qua timeouts etc. Maar je mist even compleet dat jij op dezelfde plekken je logging-niveau moet aanpassen.

Nee, dat moet nou juist niet. Ik hoef alleen op de 'verdachte' plek het log-level te verhogen. De rest van de keten kan ik ongemoeid laten.

Of je nou logged of debugged, in een complexe omgeving ga je voor troubleshooting settings binnen je omgeving moeten veranderen en die settings zijn qua plaats relatief gelijk (als je het goed opgezet hebt).
Geef jij vanaf een client-proces het log-niveau steeds door naar boven tot aan de server, hetzelfde kan je doen met timeouts etc.

Dat doe ik nou juist niet. Zie boven.

In wezen is wat ik bedoel te zeggen : Code is niet enkel tekst editten, het is tekst editten binnen een specifieke context.
Qua textuele waarde maakt het niet uit of ik nou een "enif" schrijf of "endif" of "end if".
Maar qua code waarde maakt het wel een heleboel uit en dan heb ik toch liever direct een rood lijntje eronder als ik het verkeerd type binnen de huidige context.

Ik heb daar geen behoefte aan. En nee, ik ben geen masochist.

En dan zullen er vast wel weer allemaal plugins etc aangedragen worden die het allemaal wel weer kunnen, maar guess what. Met die plugins ben je enkel maar bezig een IDE te bouwen om de lacunes van enkel tekst-editen op te vangen, waarom dan niet direct een IDE pakken?

Die plugins zijn er inderdaad. Ik gebruik ze niet, omdat ik dan inderdaad zou proberen een IDE te bouwen. En waarschijnlijk niet eens een goede.
Mijn punt is dat ik geen IDE-achtige dingen gebruik, omdat die voor mij geen toegevoegde waarde hebben. Voor mij. Ik heb ze allemaal gebruikt hoor: VS, Eclipse, Xcode. Ik kom toch telkens weer terug bij good old Vim. Mijn hersenpan is mijn IDE ;-) Mag ik?

En oh ja, had ik al gezegd dat ik geen masochist ben?

[Schnupperpuppe]

Herko_ter_Horst schreef op zaterdag 11 april 2015 @ 13:28:
[...]

"If all you have is a hammer, everything starts to look like a nail."

Lijk jij ook wel 'last' van te hebben... "Ik heb een editor die goed is in tekstbewerking (hammer), dus ik beschouw code als tekst (nail)".

Je slaat de spijker op zijn kop! Pun intended.
Code is tekst. Langer is het verhaal niet.

Voor de rest gaat je analogie niet op. Ik heb niet alleen een hamer, ik heb een rijk gevulde kist boordevol kwaliteitsgereedschap. Voor alle spijkers gebruik ik inderdaad het liefst een goede hamer en geen speelgoedhamer van de Action. Voor schroeven heb ik een uitgebreide set schroevendraaiers, niet zo'n plastic prul met waardeloze bitjes onder een schroefdopje in het handvat.
Verder heb ik nog steeksleutels, ringsleutels, pijpsleutels en probeer ik het gebruik van de Bahco te vermijden.
Ben ik nog iets vergeten?

[Avalaxy]

Schnupperpuppe schreef op zaterdag 11 april 2015 @ 15:36:
Code is tekst.

Nee, dat is het niet. Code is relationele, variabele tekst. Een bijzonder belangrijk onderdeel van programmeren is dat je weet waar een functie/variabele vandaan komt. Een IDE legt die relatie en stelt je in staat om naar de definitie van de functie te springen, een text editor ziet die relatie niet en geeft je geen enkele hint waar je functie vandaan komt, of wat hij doet. Zo geldt ook dat een IDE je in staat stelt om hem te refactoren, bijvoorbeeld door de naam of de signature aan te passen. De IDE weet namelijk dat er meer plekken zijn waar de functie gebruikt wordt, en kijkt niet alleen dom naar de naam, maar ook naar de namespace. Een text editor ziet alleen tekst en kan dat niet.

Code is gewoon geen tekst, hoe je het ook wendt of keert. Als je ook maar enigszins serieus bezig bent met programmeren dan werkt een text editor gewoon niet.