Niet kiezen voor een taal, vanwege de tooling?

[Schnupperpuppe]

Avalaxy schreef op zaterdag 11 april 2015 @ 16:50:
[...]


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.

Bon, en hoe refactort jouw IDE een functienaam wanneer je gebruikt maakt van runtime-evaluation? Dan kan een willekeurige variabele at runtime de naam van een functie bevatten. Jouw IDE 'weet' dat niet.
Refactoring is geen dagelijkse bezigheid. Dat mag ik hopen althans. Daar zijn goede tools voor en ik zie niet in waarom mijn editor zou moeten beschikken over refactoring-capaciteiten.

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.

Mijn beste, ik ben al decennia serieus bezig met programmeren. Da's mijn vak namelijk. In al die tijd heb ik vi(m) als mijn trouwe bondgenoot, tezamen met ettelijke andere tools. Ondertussen produceer ik uitstekend werkende software. Iets wat volgens jou dus niet kan?
Als jij meent dat jouw werkwijze de enige juiste is, dan heb je een zeer beperkte blik.
Ik gun je jouw IDE's van harte, maar ik hoef ze niet. Been there, done that, got the T-shirt.
Wat is daar zo moeilijk aan te begrijpen?
Ieder zijn ding.

[Azer]

Schnupperpuppe, hoe refactor jij dan variabelen/functienamen? Wel met VIM? Of gebruik je daar iets anders voor?

[Megamind]

Schnupperpuppe schreef op zaterdag 11 april 2015 @ 17:06:
[...]


Mijn beste, ik ben al decennia serieus bezig met programmeren. Da's mijn vak namelijk. In al die tijd heb ik vi(m) als mijn trouwe bondgenoot, tezamen met ettelijke andere tools. Ondertussen produceer ik uitstekend werkende software. Iets wat volgens jou dus niet kan?
Als jij meent dat jouw werkwijze de enige juiste is, dan heb je een zeer beperkte blik.
Ik gun je jouw IDE's van harte, maar ik hoef ze niet. Been there, done that, got the T-shirt.
Wat is daar zo moeilijk aan te begrijpen?
Ieder zijn ding.

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.

[Creepy]

Schnupperpuppe schreef op vrijdag 10 april 2015 @ 15:03:
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.

Ik denk dat we over hetzelfde praten. Maar alle andere schakeltjes van de keten houden er grotendeels rekening mee hier dat je in een ander schakeltje aan het debuggen kan zijn (alleen in de ontwikkelomgeving uiteraard) en dus o.a. timeout e.d. flink zijn opgeschroeft. Ik heb dus bijna geen last van die effecten. Los daarvan is het gros van de code per schakel hier los te testen, en dus ook los te debuggen. De problemen die je aanhaalt, daar hebben we hier nagenoeg geen last van, en op die paar punten waar we daar wel last van zouden kunnen hebben, weten we dat van te voren.

[Gomez12]

Schnupperpuppe schreef op zaterdag 11 april 2015 @ 15:36:
[...]
Hoezo omvormen? Code is tekst.

Nope, code is tekst in een context die een compiler begrijpt.
Het is net zoiets als simpel tekstverwerken, dat is ook tekst neerzetten in een context (namelijk dat een ander mens dat begrijpt) en daarvoor heb je spellingscontroles / grammaticacontroles etc. En bij tekst voor compilers kan je daarin veel verder gaan.

Maar laat ik het eens simplistisch vragen : Als jij "eho" typt in plaats van "echo", wanneer kom jij daar dan achter? Ik namelijk zo ongeveer als ik het ingetikt heb want de IDE die zet er een leuk rood lijntje onder want die weet namelijk dat het in de context van die tekst niet een geldig woord is. Terwijl het bijv in een stringwaarde wel weer toegestaan is.
Over de meer luxere IDE's kan je wmb discussieren maar een tekst editor mist gewoon basale functies om met code ipv tekst om te gaan.

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

Van mij mag iedereen heel veel, dus jij mag dit uiteraard doen.
Ik ben alleen heel benieuwd hoe jij een probleem waar je initiele logging niet voldoende info voor geeft aan gaat pakken? Is dat extra logging toevoegen, dan opnieuw draaien en hopen dat de extra logging het weer gaat geven en anders wederom extra logging toevoegen en opnieuw draaien etc ad infinitum.
Want debugging zie ik meer als oneindige log-regels toevoegen en op elk willekeurig moment kunnen steppen en dan niets meer hoeven opruimen naderhand.

Ik ga niet voor een "if (a=b){ " logregels neerzetten die mij even vertellen wat a en b zijn (inclusief types van a en b etc).

Maar nu ik er over nadenk heeft het met meer te maken vermoed ik, ik ben bijv geen voorstander van Hungarian notation waardoor een logregel mij dus in de basis niets zegt over het type van een variabele (dat zou dus een extra logregel vragen) terwijl debugging me die info wel direct geeft.

[...]
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.

En ik hoef alleen op de 'verdachte' plek de timeout te verhogen, ik ga er namelijk alleen tegenaan lopen waar ik wil gaan breakpointen / steppen.
Zoals ik al zeg, geen verschil...

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

Of je bent de eerste en enige en laatste foutloze programmeur ter wereld of je hebt een plaat voor je kop, directe feedback bij tikfouten is gewoon handig en werkt sneller.

[...]

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?

Wat programmeer jij dan? Want of je zit in een heel erge niche sectie te programmeren, of je bent gewoon een verdwaasde fanaticus.

Schnupperpuppe schreef op zaterdag 11 april 2015 @ 15:44:
[...]
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.

Je hebt een rijk gevuld kist boordevol kwaliteitsgereedschap voor de verkeerde klus.

Code != enkel tekst, code bevat tekst maar ook semantiek en context etc. etc. etc. En daarvoor heb jij allemaal geen tools binnen je teksteditor.

[Wim-Bart]

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.

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?

Conceptueel klopt jouw redenering niet helemaal en wel om de volgende reden:

Er is een functionaliteit benodigd welke op basis van software ingevuld moet worden. Bijvoorbeeld een financiële applicatie of bestruring van een CNC machine, een liftautomaat, een web gebaseerd EDP et cetera.

Voor iedere soort toepassing is er 1 of meerdere talen beschikbaar. Je gaat bijvoorbeeld geen assembler gebruiken voor een web applicatie en geen .NET voor een microcontroller. De gebruikte programmeertaal is dus gebonden aan de toepassing die je er mee gaat maken. Daarnaast heb je ook zo iets als standaarden binnen een bedrijf. Wanneer je bij een bedrijf werkt die alleen maar met PHP werkt voor Web applicaties, dan zou het vreemd zijn om daar van af te wijken, mits er technische argumenten zijn om dat te doen, bijvoorbeeld een custom module die in C++ geschreven moet worden als plugin voor PHP bijvoorbeeld.

Bij iedere omgeving hoort een set met Tools, deze tools zijn min of meer vast hoewel je soms wat kan afwijken. Ik gebruik graag UltraEdit voor veel werk, maar als ik met Microsoft talen werk pak ik gewoon de bijbehorende Visual Studio. Uit dit kan je de volgende trap maken:

1. Gevraagde functionaliteit
2. Keuze van de bijbehorende taal
3. Keuze van de bij de taal behorende tooling

Jij benaderd het precies andersom, wat gaat leiden tot:

1. Keuze tooling
2. Keuze taal wat misschien niet aansluit bij de functionaliteit
3. Funcioneel product gebouwd op basis van aan elkaar geknoopt zooitje wat misschien wel werkt maar slecht is te onderhouden.

Je kan het in jouw geval dus beter benaderen als:

1. Keuze taal waarin je wil excelleren
2. Je eigen tooling gebruiken
3. Werkgever/klant kiezen welke daar bij aansluit.

[Schnupperpuppe]

Azer schreef op zaterdag 11 april 2015 @ 17:37:
Schnupperpuppe, hoe refactor jij dan variabelen/functienamen? Wel met VIM? Of gebruik je daar iets anders voor?

Gewoon lekker met het handje.
Je kunt er een big deal van maken, maar dat is het niet.
Ik refactor trouwens zelden. Dat scheelt.

[johnkeates]

Ik vind het interessant om te zien dat VIM een editor genoemd wordt, en de term IDE daarna gelijk gesteld wordt aan editor terwijl een IDE geen editor is. VIM is geen IDE, en een IDE is geen editor. Waarom proberen mensen dat dan toch nog te vergelijken?

[Schnupperpuppe]

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.

Vage tools? Pardon?
Vi(m) is al sinds mensenheugenis de de-facto standaard editor in *nix omgevingen.
Niks vaags aan.
En bovendien. Kun jij aan de source code zien met welke editor deze ooit gemaakt is?
Dat maakt toch helemaal niks uit? Source code is source code.

[whoami]

Schnupperpuppe schreef op zaterdag 11 april 2015 @ 17:06:
[...]

Refactoring is geen dagelijkse bezigheid.

Waarom niet ?

Ik hou het niet echt bij, maar de kans is groot dat ik dagelijks wel iets refactor. Dat hoeven geen grote structurele wijzigingen te zijn, maar een variable - naam of method naam veranderen (verbeteren), dat is ook refactoren.

[Megamind]

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


Vage tools? Pardon?
Vi(m) is al sinds mensenheugenis de de-facto standaard editor in *nix omgevingen.
Niks vaags aan.
En bovendien. Kun jij aan de source code zien met welke editor deze ooit gemaakt is?
Dat maakt toch helemaal niks uit? Source code is source code.

Je snapt het niet. Het is niet alleen sourcecode, we hebben het over tooling. Het runnen van performance benchmarks, unit tests of code coverage wordt vaak ook in een IDE gedaan. Daarnaast gebruiken we bv GhostDoc templates, Re# settings en StyleCop om een goede code consistency te krijgen, wat je niet gaat lukken in een simpele texteditor. Daarnaast doen we aan pair programming, wat een hel is als iemand in een andere editor zit te rommelen.

Daarnaast met hierboven, als je TDD doet dan kan je niet om refactoring heen, ik refactor elke dag wel wat.

[ Voor 6% gewijzigd door Megamind op 11-04-2015 21:42 ]

[Lethalis]

Misschien is het handig om te vermelden wat je programmeert en niet alleen hoe.

Ik werk aan ERP pakketten die vrij complex zijn op Windows en .Net. Refactoring is een dagelijkse bezigheid. Ik kom elke dag wel code tegen van 10 jaar oud die niet te begrijpen is, of ik bedenk me dat een bepaalde naam voor iets eigenlijk niet handig is, etc.

En dan is het enorm handig dat ik het met Visual Studio ff snel kan aanpassen zonder dat er iets breekt.

[Schnupperpuppe]

johnkeates schreef op zaterdag 11 april 2015 @ 19:15:
Ik vind het interessant om te zien dat VIM een editor genoemd wordt, en de term IDE daarna gelijk gesteld wordt aan editor terwijl een IDE geen editor is. VIM is geen IDE, en een IDE is geen editor. Waarom proberen mensen dat dan toch nog te vergelijken?

Het is niet echt Vim versus IDE, het is non-Integrated versus Integrated Development Environment.
Of "The Right Tool For The Right Job" versus "One Size Fits All".

[Schnupperpuppe]

Gomez12 schreef op zaterdag 11 april 2015 @ 18:54:
[...]

Maar laat ik het eens simplistisch vragen : Als jij "eho" typt in plaats van "echo", wanneer kom jij daar dan achter? Ik namelijk zo ongeveer als ik het ingetikt heb want de IDE die zet er een leuk rood lijntje onder want die weet namelijk dat het in de context van die tekst niet een geldig woord is. Terwijl het bijv in een stringwaarde wel weer toegestaan is.
Over de meer luxere IDE's kan je wmb discussieren maar een tekst editor mist gewoon basale functies om met code ipv tekst om te gaan.

Ik heb liever een beest van een editor waarmee ik snel en efficiënt kan werken dan een middelmatige editor die rode lijntjes onder mijn typefouten zet. Een combinatie van beide zou nog beter zijn, maar die ben ik nog niet tegengekomen.
Vim heeft trouwens ook wel handige hulpjes om simpele foutjes te voorkomen. Syntax highlighting, parenthesis/brace matching, quote matching, etc.. Het is niet zo dat de context volledig genegeerd wordt.

[...]

Van mij mag iedereen heel veel, dus jij mag dit uiteraard doen.
Ik ben alleen heel benieuwd hoe jij een probleem waar je initiele logging niet voldoende info voor geeft aan gaat pakken? Is dat extra logging toevoegen, dan opnieuw draaien en hopen dat de extra logging het weer gaat geven en anders wederom extra logging toevoegen en opnieuw draaien etc ad infinitum.

Mijn standaard logging geeft mij in 90% van de gevallen voldoende info om een probleem te pinpointen. Voor de overige 10% moet ik soms wat extra logging toevoegen.

Maar nu ik er over nadenk heeft het met meer te maken vermoed ik, ik ben bijv geen voorstander van Hungarian notation waardoor een logregel mij dus in de basis niets zegt over het type van een variabele (dat zou dus een extra logregel vragen) terwijl debugging me die info wel direct geeft.

Het type van een variabele? Die weet je toch gewoon? Heb je daar een debugger voor nodig?

En ik hoef alleen op de 'verdachte' plek de timeout te verhogen, ik ga er namelijk alleen tegenaan lopen waar ik wil gaan breakpointen / steppen.
Zoals ik al zeg, geen verschil...

Dat is niet wat ik bedoel. Wat ik bedoel is dat wanneer je op plek A gaat debuggen er op plek B een timeout kan afgaan. Client/server, multiprocessing IPC. Dat soort dingen.

Wat programmeer jij dan? Want of je zit in een heel erge niche sectie te programmeren, of je bent gewoon een verdwaasde fanaticus.

Ik programmeer van alles en nog wat. Full stack.

Je hebt een rijk gevuld kist boordevol kwaliteitsgereedschap voor de verkeerde klus.

Want? Ik heb je maar één van mijn tools genoemd, nl. de editor. Mijn development environment bevat meer dan alleen een editor. Veel meer.

Code != enkel tekst, code bevat tekst maar ook semantiek en context etc. etc. etc. En daarvoor heb jij allemaal geen tools binnen je teksteditor.

Niet binnen mijn teksteditor, nee. Betekent dat automatisch dat ik die tools niet heb? Nee.

[Schnupperpuppe]

Megamind schreef op zaterdag 11 april 2015 @ 21:41:
[...]

Je snapt het niet. Het is niet alleen sourcecode, we hebben het over tooling. Het runnen van performance benchmarks, unit tests of code coverage wordt vaak ook in een IDE gedaan.

Dan begrijp je mij verkeerd. Ik probeer niet alles in een editor te doen wat jij in een IDE doet.
Mijn editor is slechts één van vele (losse) tools die ik gebruikt in mijn development environment.

[Avalaxy]

Schnupperpuppe schreef op zondag 12 april 2015 @ 08:39:

[...]

Het type van een variabele? Die weet je toch gewoon? Heb je daar een debugger voor nodig?

Je kunt wel een autoritair argument gebruiken dat je al "decennia programmeert", maar met zo'n opmerking als deze laat je toch echt duidelijk merken dat je er de ballen verstand van hebt en nog nooit aan een serieuze applicatie van meer dan 1000 regels code hebt gewerkt, of met een team hebt gewerkt.

[Cartman!]

Schnupperpuppe schreef op zaterdag 11 april 2015 @ 19:15:
Ik refactor trouwens zelden. Dat scheelt.

Dat verbaast me. Ik refactor continu dingen en niet omdat ik zit te prutsen maar gewoon omdat je along the way dingen moet verbouwen vanwege veranderende requirements. Kun je uitleggen wat voor soort software je maakt dat vrijwel nooit gewijzigd hoeft te worden?

[Schnupperpuppe]

Avalaxy schreef op zondag 12 april 2015 @ 11:28:
[...]


Je kunt wel een autoritair argument gebruiken dat je al "decennia programmeert",

Dat was als reactie op jouw wijsneuzerige opmerking:

Als je ook maar enigszins serieus bezig bent met programmeren dan werkt een text editor gewoon niet.

maar met zo'n opmerking als deze laat je toch echt duidelijk merken dat je er de ballen verstand van hebt en nog nooit aan een serieuze applicatie van meer dan 1000 regels code hebt gewerkt, of met een team hebt gewerkt.

Je hebt gelijk joh. Val ik even door de mand, zeg.
Ik werk in een team met louter mongolen zoals ik. Ik ben vanwege volslagen incompetent
management volledig per abuis lead developer geworden bij een grote multinational.

Voor jou is blijkbaar het aantal regels code de maat der dingen. Om jou een plezier te doen heb
ik de regels code die ik heb geklopt in mijn huidige uiterst amateuristische projectje even geteld.
Het zijn er 35 duizend. Allemaal ingeklopt in Vim, want pijn is fijn, nietwaar?

En nou snel weer terug naar de ballenbak!

[Schnupperpuppe]

Cartman! schreef op zondag 12 april 2015 @ 11:45:
[...]

Dat verbaast me. Ik refactor continu dingen en niet omdat ik zit te prutsen maar gewoon omdat je along the way dingen moet verbouwen vanwege veranderende requirements. Kun je uitleggen wat voor soort software je maakt dat vrijwel nooit gewijzigd hoeft te worden?

Ik wijzig ook continu. Wijzigen is niet hetzelfde als refactoren.
Refactoren doe ik uiteraard ook wel eens, maar zeker niet dagelijks. Ook niet wekelijks.

[Creepy]

Misschien is het handig om dan uit te leggen wat voor tools je nog gebruikt naast je text editor, en termen als "ballenbak" gewoon achterwege te laten? Dat op de man spelen is nergens voor nodig.

[Schnupperpuppe]

Creepy schreef op zondag 12 april 2015 @ 12:22:
Misschien is het handig om dan uit te leggen wat voor tools je nog gebruikt naast je text editor, en termen als "ballenbak" gewoon achterwege te laten? Dat op de man spelen is nergens voor nodig.

Als iemand die mij absoluut niet kent meent te moeten melden dat ik ergens de ballen verstand van heb, dan behoud ik mij het recht voor om diegene van repliek te dienen. Dat was een natuurlijke reactie op iemand die op de man speelt. Wie de bal kaatst...

Enfin, de tools die ik verder gebruik zijn o.a. de GNU toolchain, lint, perltidy, graphviz, perlpod, strace, ltrace, truss, valgrind. Voornamelijk op Linux servers, soms ook Solaris.

[Richh]

35k regels code over 'decennia' aan jaren tijd en vrijwel nooit hoeven te refactoren? Dat gaat er bij mij echt niet in, sorry. Of hoef je nooit terug te duiken in de oudere code?

[Schnupperpuppe]

Richh schreef op zondag 12 april 2015 @ 12:43:
35k regels code over 'decennia' aan jaren tijd en vrijwel nooit hoeven te refactoren? Dat gaat er bij mij echt niet in, sorry. Of hoef je nooit terug te duiken in de oudere code?

Nee hoor, die 35k regels is van de laatste pakweg 3 jaar.
Van die tijd daarvoor heb ik het echt niet bijgehouden. Is ook niet zo bijster interessant.
En ja, uiteraard moet ik wel eens terugduiken in oude code, maar dat hoeft toch niet te betekenen dat je moet gaan refactoren?
Ik heb de afgelopen 3 jaar 2 keer een behoorlijke refactoring gedaan. Of eigenlijk meer een redesign t.g.v. veranderde scope. Tussendoor natuurlijk ook wel eens kleine dingetjes aangepast/gerefactort, maar dat waren klusjes van een paar minuten (naampje wijzigen, dat soort werk).
Dit ter verduidelijking van 'vrijwel nooit'.

[gekkie]

Is even fijn devil's advocate spelen ... opzich zo een editor waar je snel veel code in kunt kloppen ook niet louter voordelen kunnen hebben.
Je denkt wat minder onderbewust na over wat je aan het doen bent ..
Wellicht verleiding om meer code te kloppen ipv het op een compactere wijze op te lossen ..

Maar goed VIM werkt dus net zo goed met een meta-key .. alleen hoef je die niet per (subcommando) in gedrukt te houden aangezien je het ding ermee in een modus knalt .. je hebt een clipboard met wat meer slots dan 1 (kunnen andere editors / besturingssystemen al dan niet met een extra applicatie ook) .. en het is in hoge maten scriptable en configurabel. Kan handig zijn als er iets is wat je dwars zit
Voor de rest zie ik in de genoemde voordelen niet iets revolutionairs wat andere editors totaal niet zouden hebben. Als ik het vergelijk met bijvb ultraedit dan geldt daar ook bijna alles voor .. behalve dan cli vs gui ..
blijft er voornamelijk een verschil in de mate waarin.

[Schnupperpuppe]

gekkie schreef op zondag 12 april 2015 @ 13:36:
[...]

Voor de rest zie ik in de genoemde voordelen niet iets revolutionairs wat andere editors totaal niet zouden hebben. Als ik het vergelijk met bijvb ultraedit dan geldt daar ook bijna alles voor .. behalve dan cli vs gui ..
blijft er voornamelijk een verschil in de mate waarin.

Het is feature-voor-feature misschien niet revolutionair, maar wel conceptueel anders dan vrijwel iedere andere editor.
Bij veel editors selecteer je bijv. eerst het het te editen code blok en kiest dan de operatie.
Bij vi(m) kies je eerst de operatie en vervolgens geef je de scope aan.
Dat aspect alleen maakt het niet beter of slechter, maar de manier waarop het in vi(m) is geïmplementeerd met keystrokes maakt het wel erg vernuftig en efficiënt.
Vi is ontstaan in een tijdperk van monochrome terminals met een supertrage seriële verbinding naar de host (1200 baud?). Iedere overbodige keystroke was er één teveel. Door je code scrollen was al helemaal geen pretje. Alles moest dus zo efficiënt mogelijk. Dat snelheids-aspect is natuurlijk allang achterhaald, maar de efficiency-winst is nu nog net zo bruikbaar als toen.
Je kunt van alles met elkaar combineren en iedere keer als je je afvraagt 'zou dit of dat ook werken?',
dan blijkt het antwoord telkens 'Ja' te zijn :-)

[Ruudjah]

Ik zou eigenlijk heel graag willen werken met een krachtigere tekst editor. Hoe kan ik het probleem oplossen dat een teksteditor als vim geen notie heeft van een AST? De meeste bewerkingen die ik doen hebben écht een AST nodig, anders wordt het inefficiënt en veel handmatig (foutgevoelig) werk.

De meeste bewerkingen kan de IDE die ik momenteel gebruik in mijn dagelijkse werk (VS2013) prima uitvoeren. Dit zorgt voor een hoop text-only bewerkingen die vervolgens niet nodig zijn om uit te voeren als tekst. Maar zo nu en dan kom ik refactorings tegen die offbeat zijn en behoorlijk buiten de general case vallen. Dan wil ik mijn eigen werk kunnen automatiseren in de vorm van teksteditor scripts (liever nog AST scripts, en die worden gemakkelijker mer R# en de nieuwe Roslyn API in VS2015). Maar laat ik beginnen met tekstbewerkingsscripts, kan ook handig zijn.

Dus gegeven een teksteditor waarbij ik mijn huidige AST bewerkingscommando's kan blijven gebruiken, sta ik erg open voor een andere editor met bijbehorend paradigma. Is er een manier om een dergelijke teksteditor zoals jij gebruikt Schnupperpuppe, te combineren met een AST editor zoals in VS2013?

[Schnupperpuppe]

Ruudjah schreef op zondag 12 april 2015 @ 14:31:
[...]

Dus gegeven een teksteditor waarbij ik mijn huidige AST bewerkingscommando's kan blijven gebruiken, sta ik erg open voor een andere editor met bijbehorend paradigma. Is er een manier om een dergelijke teksteditor zoals jij gebruikt Schnupperpuppe, te combineren met een AST editor zoals in VS2013?

Ik gebruik Vim. Zoals je uit deze draad wel zult hebben begrepen is Vim niet de aangewezen tool voor de werkwijze die jij prefereert. Er is wellicht wat functionaliteit te vinden middels Vimscript plugins, maar dat zal jou waarschijnlijk toch niet echt bieden wat je zoekt.
Heb je al eens gekeken naar de VsVim extension voor Visual Studio? Die schijnt je een beetje Vim-feeling te kunnen geven, maar dan wel binnen Visual Studio. Ik heb hier zelf geen ervaring mee, maar wellicht is het iets voor je?

Je kunt natuurlijk ook voor het brute edit-werk Vim gebruiken naast VS. Verre van ideaal, maar het kan.
Als ik eens iets met Eclipse of Xcode moet doen, dan doe ik dat toch meestal met Vim ernaast :-)

[ Voor 10% gewijzigd door Schnupperpuppe op 12-04-2015 15:21 ]

[gekkie]

Schnupperpuppe schreef op zondag 12 april 2015 @ 13:59:
[...]
Het is feature-voor-feature misschien niet revolutionair, maar wel conceptueel anders dan vrijwel iedere andere editor.
Bij veel editors selecteer je bijv. eerst het het te editen code blok en kiest dan de operatie.
Bij vi(m) kies je eerst de operatie en vervolgens geef je de scope aan.
Dat aspect alleen maakt het niet beter of slechter, maar de manier waarop het in vi(m) is geïmplementeerd met keystrokes maakt het wel erg vernuftig en efficiënt.
Vi is ontstaan in een tijdperk van monochrome terminals met een supertrage seriële verbinding naar de host (1200 baud?). Iedere overbodige keystroke was er één teveel. Door je code scrollen was al helemaal geen pretje. Alles moest dus zo efficiënt mogelijk. Dat snelheids-aspect is natuurlijk allang achterhaald, maar de efficiency-winst is nu nog net zo bruikbaar als toen.
Je kunt van alles met elkaar combineren en iedere keer als je je afvraagt 'zou dit of dat ook werken?',
dan blijkt het antwoord telkens 'Ja' te zijn :-)

Wat maakt het qua efficientie uit of je eerst je scoop kiest en dan je operatie of andersom ?
(hooguit als je dezelfde operatie achter elkaar op verschillende scopes wilt verhalen heb je dan wellicht dat je je operatie niet hoeft te herhalen als je er niets anders tussen in doet ?

De vraag is dan vervolgens .. waarom is er geen IDE met deze VIM-like editor (mogelijkheden) aanboord te vinden, kennelijk is die behoefte er dan toch niet ... ongetwijfeld mede veroorzaakt door de leercurve.

Als ik zie wat ik aan mass-code edititing doen dan is dat eigenlijk vrij beperkt .. search & replace op basis van regex doet elke editor(/editor in IDE) wel .. eventueel geholpen door refactoring opties die nog iets intelligenter kunnen zijn dan simpele search & replace in sommige IDE's.
Block selectie doen de meeste ook wel, syntax hightlighting voor de wereld aan talen ook.

Dus CLI en kunnen werken over een dun pijplijntje op een terminal met beperkte mogelijkheden zijn dan eigenlijk de voornaamste pluspunten. En als je dat vaak doet kan ik me voorstellen dat als je het eenmaal kunt je het graag overal voor inzet.

Denk dat het in jouw geval wellicht een beetje is als met een (licht afwijkend) toetsenbord .. als je er eenmaal aangewend bent en (onbewust) precies weet waar alles precies zit .. dan is typen op iets anders een verschrikking omdat je steeds mis ramt .. in jouw geval ga je waarschijnlijk alle vim-commando's in je IDE-editor of je notepadje proberen .. en raak je licht gefrustreerd, terwijl iemand anders er gewoon prima mee over weg kan.
(als alle commando's er zo ingesleten zitten dat je die bij een andere edit

[Schnupperpuppe]

gekkie schreef op zondag 12 april 2015 @ 16:20:
[...]

Wat maakt het qua efficientie uit of je eerst je scoop kiest en dan je operatie of andersom ?
(hooguit als je dezelfde operatie achter elkaar op verschillende scopes wilt verhalen heb je dan wellicht dat je je operatie niet hoeft te herhalen als je er niets anders tussen in doet ?

Zo sec gesteld maakt dat inderdaad niks uit. De grap zit 'em in de manier waarop het geïmplementeerd is. Je kunt de scope op vele manieren bepalen. Dat kan bijv. met een search-operatie, of een brace-match, of end-of-word, end-of-line, you name it. Vaak met slechts 1 of 2 keystrokes.

[...]
Als ik zie wat ik aan mass-code edititing doen dan is dat eigenlijk vrij beperkt .. search & replace op basis van regex doet elke editor(/editor in IDE) wel

Ja, ze kunnen het allemaal wel. Maar niet allemaal even goed en even makkelijk.

[...]
Dus CLI en kunnen werken over een dun pijplijntje op een terminal met beperkte mogelijkheden zijn dan eigenlijk de voornaamste pluspunten.

Kunnen werken over een dun pijplijntje is niet zo relevant. Dat dunne pijllijntje heeft er echter ooit wel voor gezorgd dat de efficiëntie optimaal is. Dát is een groot pluspunt.

Denk dat het in jouw geval wellicht een beetje is als met een (licht afwijkend) toetsenbord .. als je er eenmaal aangewend bent en (onbewust) precies weet waar alles precies zit .. dan is typen op iets anders een verschrikking omdat je steeds mis ramt .. in jouw geval ga je waarschijnlijk alle vim-commando's in je IDE-editor of je notepadje proberen .. en raak je licht gefrustreerd, terwijl iemand anders er gewoon prima mee over weg kan.
(als alle commando's er zo ingesleten zitten dat je die bij een andere edit

Het punt is dat Vim conceptueel volledig anders in elkaar steekt dan andere editors. Dat geeft Vim zijn enorme kracht. En dito learning curve Het gaat niet echt om lichte afwijkingen.
Het is een beetje lastig uitleggen zo op papier.

Een anekdotisch verhaal waar vele Vimmers zich wellicht in kunnen herkennen is wanneer een niet-vimmer met stijgende verbazing meekijkt op het scherm van de Vimmer.

Niet-vimmer: "Huh? Hoe deed je dat?"
Vimmer: "Wat bedoel je?"
Niet-vimmer: "Nou, wat je net deed. Zo snel?"
Vimmer: "Nou gewoon...klop-klop-klop-tjakka-bam!...bedoel je?"
Niet-vimmer: "Wow....hoe heet dat pakket?"

Normaal gesproken zou ik zeggen: "Probeer het eens.". Helaas gaat dat niet zomaar werken. Dat zal uitlopen op vloek-tirades en oplopende afkeer. Het is net als koffie leren drinken...in het begin is het niet te zuipen, maar je moet gewoon volhouden. Uiteindelijk vind je het lekker en kun je niet meer zonder ;-)
Maar ja, toch lust niet iedereen koffie. Voor hen is er thee :-)

[gekkie]

Schnupperpuppe schreef op zondag 12 april 2015 @ 17:11:
[...]
Normaal gesproken zou ik zeggen: "Probeer het eens.". Helaas gaat dat niet zomaar werken. Dat zal uitlopen op vloek-tirades en oplopende afkeer. Het is net als koffie leren drinken...in het begin is het niet te zuipen, maar je moet gewoon volhouden. Uiteindelijk vind je het lekker en kun je niet meer zonder ;-)
Maar ja, toch lust niet iedereen koffie. Voor hen is er thee :-)

Ik hou van koffie ... maar toch drink ik meer thee

Maar goed dan snap ik je punt deels ...
Als je geen VIm leert .. heb je het voordeel dat je nagenoeg met alle tools kunt werken zonder een grote mate van frustratie ...
Leer je VIm dan heb je het probleem dat je het concept overal wilt toepassen .. en dat gaat niet, kortom frustratie.

Ergens klinkt het te samen met de leercurve niet echt als een ideale propositie om VIm te gaan leren eigenlijk ....

[Schnupperpuppe]

gekkie schreef op zondag 12 april 2015 @ 17:27:
[...]

Ik hou van koffie ... maar toch drink ik meer thee

Maar goed dan snap ik je punt deels ...
Als je geen VIm leert .. heb je het voordeel dat je nagenoeg met alle tools kunt werken zonder een grote mate van frustratie ...
Leer je VIm dan heb je het probleem dat je het concept overal wilt toepassen .. en dat gaat niet, kortom frustratie.

Dat is wel waar, ja.
Gelukkig kan ik Vim overal gebruiken. Problem solved ;-)

Ergens klinkt het te samen met de leercurve niet echt als een ideale propositie om VIm te gaan leren eigenlijk ....

Als je er niet vol voor gaat zou ik zeggen: Niet doen!
Als je er wel vol voor gaat zul je beloond worden :-)

[johnkeates]

Schnupperpuppe schreef op zondag 12 april 2015 @ 17:36:

[...]


Als je er niet vol voor gaat zou ik zeggen: Niet doen!
Als je er wel vol voor gaat zul je beloond worden :-)

Dat zeggen emacs gebruikers ook altijd

*gooit olie op het vuur

[ Voor 4% gewijzigd door johnkeates op 12-04-2015 17:40 ]

[Schnupperpuppe]

johnkeates schreef op zondag 12 april 2015 @ 17:40:
[...]


Dat zeggen emacs gebruikers ook altijd

*gooit olie op het vuur

Klopt.
Ieder zijn ding. Mooi toch?

[gekkie]

Schnupperpuppe schreef op zondag 12 april 2015 @ 17:36:
[...]
Dat is wel waar, ja.
Gelukkig kan ik Vim overal gebruiken. Problem solved ;-)

Jij misschien wel .. maar dat betekend dan inderdaad dat de tooling inderdaad meer vast staat dan bij mensen die niet aan VIM verslingerd zijn.
Als je een IDE wil gebruiken heb je dus een probleem, aangezien je daar meestal geen editor met de mogelijkheden (en toetscombinaties) van VIM in kan schuiven.

Als je er niet vol voor gaat zou ik zeggen: Niet doen!
Als je er wel vol voor gaat zul je beloond worden :-)

Voor mij dus niet ... misschien denk ik gewoon niet snel genoeg .. wie weet, maar ik zie vooralsnog vooraf geen grote voordelen die mij over de streep gaan trekken. Dan liever wat meer keuze mogelijkheden van editors (in of buiten een IDE) die zodanig op elkaar lijken dat daar prima tussen te wisselen valt.

[Schnupperpuppe]

gekkie schreef op zondag 12 april 2015 @ 17:42:
[...]

Jij misschien wel .. maar dat betekend dan inderdaad dat de tooling inderdaad meer vast staat dan bij mensen die niet aan VIM verslingerd zijn.

Learn once...use everywhere :-)

Als je een IDE wil gebruiken heb je dus een probleem, aangezien je daar meestal geen editor met de mogelijkheden (en toetscombinaties) van VIM in kan schuiven.

Als ik dat zou willen ja...kosten/baten analyse.
Geen probleem dus.

[...]

Voor mij dus niet ... misschien denk ik gewoon niet snel genoeg .. wie weet, maar ik zie vooralsnog vooraf geen grote voordelen die mij over de streep gaan trekken. Dan liever wat meer keuze mogelijkheden van editors (in of buiten een IDE) die zodanig op elkaar lijken dat daar prima tussen te wisselen valt.

Wat jij wilt :-)

[gekkie]

Schnupperpuppe schreef op zondag 12 april 2015 @ 17:48:
[...]
Learn once...use everywhere :-)

Ik heb het ook op een (oude ) fiets geleerd ...
Maar om nou alles fietsend te gaan doen ... soms is een bolide ook wel prettig.

[Schnupperpuppe]

gekkie schreef op zondag 12 april 2015 @ 17:52:
[...]

Ik heb het ook op een (oude ) fiets geleerd ...
Maar om nou alles fietsend te gaan doen ... soms is een bolide ook wel prettig.

Hoho...elektrische fiets dan wel he?
Vi is de oude fiets. Vim is de elektrische fiets

Update:
Of zo'n fiets: https://youtu.be/WREyAicJXkM

[ Voor 12% gewijzigd door Schnupperpuppe op 12-04-2015 18:05 ]

[gekkie]

Schnupperpuppe schreef op zondag 12 april 2015 @ 17:55:
[...]
Hoho...elektrische fiets dan wel he?
Vi is de oude fiets. Vim is de elektrische fiets

Ah vandaar .. moet je een bejaarde ook niet op willen zetten .. geeft alleen maar ongelukken

Update:
Of zo'n fiets: https://youtu.be/WREyAicJXkM

Tsja als ik dan toch moest kiezen ... doe dan toch de ferrari maar .. al denk ik dat ik toch nog gewoon liever m'n huidige gezapige stationbak heb

[ Voor 47% gewijzigd door gekkie op 12-04-2015 18:19 ]

[Schnupperpuppe]

gekkie schreef op zondag 12 april 2015 @ 18:17:
[...]

Ah vandaar .. moet je een bejaarde ook niet op willen zetten .. geeft alleen maar ongelukken

...iets waar je met een bejaarde in een Ferrari gelukkig geen last van zult hebben ;-)

[...]

Tsja als ik dan toch moest kiezen ... doe dan toch de ferrari maar ..

Ja, maar toch is die fiets VET!

[gekkie]

Schnupperpuppe schreef op zondag 12 april 2015 @ 18:48:
[...]
...iets waar je met een bejaarde in een Ferrari gelukkig geen last van zult hebben ;-)

Vaak is stabiliteit een van de eerste problemen .. daar helpen 4 wielen in iedergeval wel bij

Ja, maar toch is die fiets VET!

Friet ook .. zeker met een klodder mayo.

[Schnupperpuppe]

gekkie schreef op zondag 12 april 2015 @ 19:03:
[...]

Vaak is stabiliteit een van de eerste problemen .. daar helpen 4 wielen in iedergeval wel bij

Totdat de achterwielen ineens op de plek zitten waar eigenlijk de voorwielen horen te zitten. ;-)

[...]

Friet ook .. zeker met een klodder mayo.

Hmmm...krijg honger!

[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 ]