Welke programmeertaal? #2

Interessant topic, iemand linkje naar deel 1?

Laat maar, al gevonden. Ik moet niet zo lui zijn. Binnekort ff doornemen

quote:

Op vrijdag 7 oktober 2011 14:07 schreef raptorix het volgende:

[..]

Als je een component noemde, wist ie de hele namespace op te dreunen

Ik wil niet opscheppen, maar ik denk dat ik heel veel .NET types uit mijn hoofd kan benoemen (inclusief de volledige naam van de assembly waar deze deel van uit maakt).

quote:

Op vrijdag 7 oktober 2011 19:15 schreef Devv het volgende:

[..]

Ik wil niet opscheppen, maar ik denk dat ik heel veel .NET types uit mijn hoofd kan benoemen (inclusief de volledige naam van de assembly waar deze deel van uit maakt).

Ik denk niet dat veel mensen jaloers op je zijn. Eigenlijk.

quote:

Op vrijdag 7 oktober 2011 19:42 schreef minibeer het volgende:

[..]

Ik denk niet dat veel mensen jaloers op je zijn. Eigenlijk.

Dat maakt niet uit hoor. Ik verdien er mijn geld mee, dus het is dagelijkse routine. Ik kan .NET bijna dromen. En dat is best wel handig.

quote:

Op vrijdag 7 oktober 2011 20:05 schreef Devv het volgende:

[..]

Dat maakt niet uit hoor. Ik verdien er mijn geld mee, dus het is dagelijkse routine. Ik kan .NET bijna dromen. En dat is best wel handig.

Ja, dat punt probeerde ik ook al te maken. Ik bedoel, er zal best wel wat tijd overheen gegaan zijn voordat je die library kende, of niet?
Ik kan me heel goed voorstellen dat het handig is, het bevalt me alleen niet zo dat je een groot deel van de library uit je kop moet kennen voordat je optimaal gebruik kan maken van de mogelijkheden van een taal.

quote:

Op vrijdag 7 oktober 2011 20:38 schreef minibeer het volgende:

[..]

Ja, dat punt probeerde ik ook al te maken. Ik bedoel, er zal best wel wat tijd overheen gegaan zijn voordat je die library kende, of niet?
Ik kan me heel goed voorstellen dat het handig is, het bevalt me alleen niet zo dat je een groot deel van de library uit je kop moet kennen voordat je optimaal gebruik kan maken van de mogelijkheden van een taal.

Nee hoor. .Net (visual studio) heeft een ongelooflijk lekker werkende code aanvuller. Je hoeft geen enkele 'library uit je kop te kennen' om optimaal van de taal gebruik te kunnen maken. En voor de rest is er google. Ja, het werkt nèt even wat sneller als je meteen weet welke functies of classes in welke assembly zitten, maar via msdn zie je dat ook.

quote:

Op vrijdag 7 oktober 2011 22:06 schreef ralfie het volgende:

[..]

Nee hoor. .Net (visual studio) heeft een ongelooflijk lekker werkende code aanvuller. Je hoeft geen enkele 'library uit je kop te kennen' om optimaal van de taal gebruik te kunnen maken. En voor de rest is er google. Ja, het werkt nèt even wat sneller als je meteen weet welke functies of classes in welke assembly zitten, maar via msdn zie je dat ook.

Als je weet welke klasse je moet hebben, maar je bent de naam even vergeten wel, maar anders kan het wel eens een tijd duren voordat je vindt wat je bedoelt. Er zijn niet voor niks veel van die topics van 'hoe doe ik ... met c#/vb .net? op programmeerforums.

Het .NET framework is dan ook veel te omvangrijk om uit je hoofd te gaan leren. Belangrijker is als je maar weet waar je de oplossing moet zoeken wanneer je vast hangt. Zo heb ik van de week ook weer even op Internet moeten spieken hoe precies om te gaan met Serialization en de wijze van het omzetten naar XML. Heb ik al veel vaker mee gewerkt, maar als je het een tijdje niet gebruikt dan is een geheugensteuntje wel zo makkelijk. Sites als StackOverflow zit ik sowieso wekelijks wel een keer op te spieken.

Ook is het handig om bepaalde terminologie te kennen om dat zoeken eenvoudiger te maken. Ik krijg nog steeds vaak rare gezichten als ik programmeurs vraag waarom ze zo veel 'boxen', of waarom ze geen 'ternary operators' gebruiken voor eenvoudige condities.

Overigens is het .NET framework naar mijn mening erg logisch ingedeeld (nogmaals, mits je op de hoogte bent van hoe bepaalde zaken benoemd worden). Wil je met grafiekjes gaan freubelen? Dan weet je dat je in System.Drawing.BlaBla moet zoeken. Behoefte aan meertaligheid? System.Globalization.

quote:

Op vrijdag 7 oktober 2011 23:54 schreef SecurityException het volgende:
of waarom ze geen 'ternary operators' gebruiken voor eenvoudige condities.

Ternaire operators worden bij ons in de stijlregels gevlagd met lage prioriteit. Ja, ze kunnen nuttig zijn zolang de conditie heel eenvoudig is, maar zo gauw het iets complexer wordt (en zeker zo gauw je gaat nesten) zijn if/else constructies beter leesbaar en om de onderhoudbaarheid beter te maken wordt dus aangemoedigd om direkt maar met die if/else constructies te beginnen. Net zoals je bijv. bij 1-regel blocks achter een if ze toch verplicht met een accolade moet schrijven.

Allemaal overbodig als je de luxe hebt om met alleen maar briljante seniors te werken die nooit een off-day hebben. Dat is bij ons helaas niet altijd de realiteit .

Het blijft over het algemeen een kwestie van de gulden middenweg kiezen. Je wilt esthetische code, maar het moet voor anderen wel leesbaar blijven. Vooral met dat laatste heb ik wel eens moeite, omdat ik behoorlijk diep in de materie zit. Ik gebruik in mijn code heel veel korte notities, expressies en extension methods.

quote:

Op vrijdag 7 oktober 2011 12:37 schreef thabit het volgende:

[..]

Bij hem heb ik ook ooit een vak over functioneel programmeren gevolgd. Zeer vermakelijk om colleges te volgen van zo'n knettergekke figuur.

Dit is wel behoorlijk lang geleden dan, hij werkt al een hele tijd bij microsoft. Maar vet dat je colleges van hem gehad hebt, ik ben jaloers

Ik zit nu veel met Objective-C te werken, want iOS jeweet.

In het begin heb je soms weleens "wat een kut taal, waarom moeten ze het nou weer anders doen", maar intussen vind ik het eigenlijk best leuk om mee te werken. Dat hele message passing en named parameters werkt best goed en maakt de code leesbaarder.
Alleen jammer dat ze bij Apple ervoor gekozen hebben om de dot-notatie in Objective-C 2.0 te gooien, dus waarden aan object properties toewijzen kan op twee manieren:


En de laatste is niet efficiënter ofzo, die wordt intern gewoon vertaald naar de eerste. Mijn missie is om de dot-notatie er compleet uit te stampen bij alle iOS developers, het zal er vast zijn ingezet om developers die andere talen gewend zijn het naar de zin te maken... maar uiteindelijk krijg je er meer rommelige code voor terug. Je doet aan message passing, of je gaat maar met een andere taal werken.

Binnenkort ook maar eens kijken hoe de Android SDK werkt... Java en Eclipse e.d. ken ik al, dus dat moet wel vrij vlot te doen zijn.

[ Bericht 1% gewijzigd door Fleischmeister op 08-10-2011 23:23:45 ]

quote:

Op zaterdag 8 oktober 2011 23:17 schreef Henno het volgende:
Ik zit nu veel met Objective-C te werken, want iOS jeweet.

Heb ik ook wel wat positieve geluiden over gehoord. Misschien ook maar een beetje proberen als ik wat meer tijd heb .

quote:

Op zaterdag 8 oktober 2011 13:20 schreef Litpho het volgende:

[..]

Ternaire operators worden bij ons in de stijlregels gevlagd met lage prioriteit. Ja, ze kunnen nuttig zijn zolang de conditie heel eenvoudig is, maar zo gauw het iets complexer wordt (en zeker zo gauw je gaat nesten) zijn if/else constructies beter leesbaar en om de onderhoudbaarheid beter te maken wordt dus aangemoedigd om direkt maar met die if/else constructies te beginnen. Net zoals je bijv. bij 1-regel blocks achter een if ze toch verplicht met een accolade moet schrijven.

Allemaal overbodig als je de luxe hebt om met alleen maar briljante seniors te werken die nooit een off-day hebben. Dat is bij ons helaas niet altijd de realiteit .

Ik ben zelf fervent voorstander van leesbare en duidelijke code dus gebruik ternary operators alleen voor hele eenvoudige condities. In een class waar heel veel van die eenvoudige condities zitten kan het gebruik van ternary operators heel wat regeltjes schelen.

quote:

Op zondag 9 oktober 2011 00:02 schreef SecurityException het volgende:

[..]

Ik ben zelf fervent voorstander van leesbare en duidelijke code dus gebruik ternary operators alleen voor hele eenvoudige condities. In een class waar heel veel van die eenvoudige condities zitten kan het gebruik van ternary operators heel wat regeltjes schelen.

De term leesbaar is ook maar relatief. Het ligt er meer aan hoe bereidwillig de persoon is die het moet lezen om dieper in de materie te duiken. Vaak is de capaciteit er wel om het te kunnen begrijpen, maar wordt het uit gemakzucht nooit gebruikt.

Ik merk dit bijvoorbeeld op mijn werk. Daar gebruiken collega's nog heel veel de C# syntax van .NET 2.0 terwijl ik mijn syntax voor een groot gedeelte op .NET 4 richt. Daar is niets mis mee, maar het kan weleens tot Babylonische spraakverwarring leiden. En mijn collega's zijn echt geen beginners. Dit zijn programmeurs met ruime ervaring.

quote:

Op vrijdag 7 oktober 2011 23:54 schreef SecurityException het volgende:
Het .NET framework is dan ook veel te omvangrijk om uit je hoofd te gaan leren. Belangrijker is als je maar weet waar je de oplossing moet zoeken wanneer je vast hangt. Zo heb ik van de week ook weer even op Internet moeten spieken hoe precies om te gaan met Serialization en de wijze van het omzetten naar XML. Heb ik al veel vaker mee gewerkt, maar als je het een tijdje niet gebruikt dan is een geheugensteuntje wel zo makkelijk. Sites als StackOverflow zit ik sowieso wekelijks wel een keer op te spieken.

Ook is het handig om bepaalde terminologie te kennen om dat zoeken eenvoudiger te maken. Ik krijg nog steeds vaak rare gezichten als ik programmeurs vraag waarom ze zo veel 'boxen', of waarom ze geen 'ternary operators' gebruiken voor eenvoudige condities.

Overigens is het .NET framework naar mijn mening erg logisch ingedeeld (nogmaals, mits je op de hoogte bent van hoe bepaalde zaken benoemd worden). Wil je met grafiekjes gaan freubelen? Dan weet je dat je in System.Drawing.BlaBla moet zoeken. Behoefte aan meertaligheid? System.Globalization.

True, het .net framework is alleen zo groot. En vaak toch ook onlogisch, als je de achterliggende gedachten en technieken niet begrijpt. Voorbeeld: Ik moest ergens in een opdracht een string naar zijn sha1 hash omzetten. Ik had vrij snel door dat ik in de class System.Security.Cryptography moest zijn, alleen koos ik als n00b natuurlijk de SHA1 class uit om mee te kloten, en niet de SHA1CryptoServiceProvider. Als je wat ervarener bent met .NET snap je dan natuurlijk gelijk dat je die serviceprovider moet hebben, maar heel logisch is het niet. (en even om mijn eerste keuze voor de sha1 class te rechtvaardigen: er zit een hele waslijst aan klassen die met sha1 beginnen in die namespace, dus ik had die cryptoserviceprovider gewoon niet gezien)

quote:

Op zondag 9 oktober 2011 00:02 schreef SecurityException het volgende:

[..]

Ik ben zelf fervent voorstander van leesbare en duidelijke code dus gebruik ternary operators alleen voor hele eenvoudige condities. In een class waar heel veel van die eenvoudige condities zitten kan het gebruik van ternary operators heel wat regeltjes schelen.

Ja, maar het besparen op regeltjes is geen doel op zich (tenzij je werkt met mensen die alleen maar kunnen debuggen vanaf printouts - red het regenwoud!). Zeker met een team met grote niveauverschillen is code waarbij op een gegeven regel maar één ding tegelijk gebeurt vaak beter leesbaar (door iedereen, niet alleen door de schrijver/seniors) en dus onderhoudbaar.

quote:

Op zondag 9 oktober 2011 00:28 schreef Devv het volgende:

[..]

De term leesbaar is ook maar relatief. Het ligt er meer aan hoe bereidwillig de persoon is die het moet lezen om dieper in de materie te duiken. Vaak is de capaciteit er wel om het te kunnen begrijpen, maar wordt het uit gemakzucht nooit gebruikt.

Ik merk dit bijvoorbeeld op mijn werk. Daar gebruiken collega's nog heel veel de C# syntax van .NET 2.0 terwijl ik mijn syntax voor een groot gedeelte op .NET 4 richt. Daar is niets mis mee, maar het kan weleens tot Babylonische spraakverwarring leiden. En mijn collega's zijn echt geen beginners. Dit zijn programmeurs met ruime ervaring.

Zeker is leesbaarheid relatief/subjectief, maar mooie toepassingen voor ternary operators vind k bijvoorbeeld:


In plaats van


Veel van die simpele statements scheelt aanzienlijk in regels, en dat vind iedereen wel prettig neem ik aan. Slecht gebruik van ternary operators vind ik sowieso als ze nested gebruikt worden, daar kun je de boel lekker Cryptografisch mee maken.


Zoiets dus, dat kom je ook nog wel eens tegen. Of iets waar ik ook een gruwelijke hekel aan heb: inline String concatination met veel variabelen en statische waarden i.p.v. String.Fomat.


i.p.v.

quote:

Op zondag 9 oktober 2011 00:32 schreef minibeer het volgende:

[..]

True, het .net framework is alleen zo groot. En vaak toch ook onlogisch, als je de achterliggende gedachten en technieken niet begrijpt. Voorbeeld: Ik moest ergens in een opdracht een string naar zijn sha1 hash omzetten. Ik had vrij snel door dat ik in de class System.Security.Cryptography moest zijn, alleen koos ik als n00b natuurlijk de SHA1 class uit om mee te kloten, en niet de SHA1CryptoServiceProvider. Als je wat ervarener bent met .NET snap je dan natuurlijk gelijk dat je die serviceprovider moet hebben, maar heel logisch is het niet. (en even om mijn eerste keuze voor de sha1 class te rechtvaardigen: er zit een hele waslijst aan klassen die met sha1 beginnen in die namespace, dus ik had die cryptoserviceprovider gewoon niet gezien)

Voor simpele stringetjes naar SHA1 hashes om te zetten heb je toch ook alleen maar de SHA1 class in de System.Security.Cryptogaphy namespace (en de System.Text.ASCIIEncoding class) nodig?


Maar inderdaad, die geneste/verstopte/gespecialiseerde namespaces zijn in het begin lastig, ook bijvoorbeeld met de SQL/OleDB/Ado trukendoos. Maar je gaat dat patroon en de indeling op een gegeven moment wel doorkrijgen.

[ Bericht 0% gewijzigd door SecurityException op 09-10-2011 12:40:15 ]

quote:

Op zondag 9 oktober 2011 12:34 schreef SecurityException het volgende:

[..]

Voor simpele stringetjes naar SHA1 hashes om te zetten heb je toch ook alleen maar de SHA1 class in de System.Security.Cryptogaphy namespace (en de System.Text.ASCIIEncoding class) nodig?
[ code verwijderd ]

Maar inderdaad, die geneste/verstopte/gespecialiseerde namespaces zijn in het begin lastig, ook bijvoorbeeld met de SQL/OleDB/Ado trukendoos. Maar je gaat dat patroon en de indeling op een gegeven moment wel doorkrijgen.

O, dat heb ik helemaal niet doorgehad

Ik had het uiteindelijk maar één keer nodig, dus ik had iets gedaan als:
Nu we het toch over leesbaarheid hebben

[ Bericht 4% gewijzigd door minibeer op 09-10-2011 13:26:50 ]

quote:

Op zondag 9 oktober 2011 12:26 schreef SecurityException het volgende:

[..]

Zeker is leesbaarheid relatief/subjectief, maar mooie toepassingen voor ternary operators vind k bijvoorbeeld:
[ code verwijderd ]

In plaats van
[ code verwijderd ]

Veel van die simpele statements scheelt aanzienlijk in regels, en dat vind iedereen wel prettig neem ik aan. Slecht gebruik van ternary operators vind ik sowieso als ze nested gebruikt worden, daar kun je de boel lekker Cryptografisch mee maken.
[ code verwijderd ]

Zoiets dus, dat kom je ook nog wel eens tegen. Of iets waar ik ook een gruwelijke hekel aan heb: inline String concatination met veel variabelen en statische waarden i.p.v. String.Fomat.
[ code verwijderd ]

i.p.v.
[ code verwijderd ]

Ik schrijf eigenlijk alles zoveel mogelijk uit, wat maakt het nou uit hoeveel regels het is? Qua performance maakt het geen ene moer uit en qua leesbaarheid is het stukken beter.

quote:

Op maandag 10 oktober 2011 14:51 schreef Catbert het volgende:

[..]

Ik vind dit:
[ code verwijderd ]

Net zo leesbaar als:
[ code verwijderd ]

Ik vind persoonlijk zelf handig dat je in eerste geval wat netter commentaar kan zetten.

quote:

Op maandag 10 oktober 2011 14:51 schreef Catbert het volgende:

[..]

Ik vind dit:
[ code verwijderd ]

Net zo leesbaar als:
[ code verwijderd ]

Ik ook. Tot de toekenningen en/of de testconditie groter worden. Dan wordt de uitgeschreven versie al gauw leesbaarder.

Of je moet if statements hebben die naar een waarde evalueren .