:strip_exif()/u/80759/monstermania_small.gif?f=community)
Nu nog een PHP versie 
/u/39688/AnnoAvatarSmall.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/36003/crop584e9e5c223bd.jpeg?f=community)
Vinden dat iemand geen antwoord geeft is op de man spelen
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
/u/12668/hydra.png?f=community)
Pardon? Jij make broad sweeping statements over de meestgebruikte enterprise-taal van dit moment, dan mag je dergelijke uitspraken ook wel even ondersteunen met voorbeelden.
Dat is gewoon een onzinnig voorbeeld. Ja, je kunt met 20 verschillende classes een Hello World maken, maar dat kan in iedere taal. Ik vind de opmerking van een van die mensen daar die klagen over dat je maar 1 class per .java bestand mag hebben typerend voor het soort developers die over dit soort zaken klagen: absolute beginners.Snel even een satirisch voorbeeld: http://www.plug.org/pipermail/plug/2007-July/013665.html
Dit is niet real-life maar het geeft heel erg precies mijn pijnpunt aan. Als je wilt kan ik gaan zoeken naar voorbeelden uit echte java applicaties, maar dat duurt even, al die voorbeelden zitten verborgen tussen een hoop andere onnodige klassen
En dat is dus waar ik over val: het is gewoon complete onzin. Het maken van van veel classes is geen doel. Een developer die dat als doel heeft is een slechte developer, klaar. Natuurlijk zijn er developers die zaken overengineeren, maar wederom zijn dat slechte developers. Java stimuleert 'slecht' ontwikkelen absoluut niet, integendeel. OO in general stimuleert juist goed programmeren omdat je functionaliteit plaatst in objecten die daarvoor verantwoordelijk zijn.
Waarom? Dit topic is hier prima geschikt voor. Het is onnodig daar een eigen topic voor te beginnen.
Ik bedoel vooral dat ik het belachelijk vindt dat zowel Java als .Net je dit zelf op laten lossen. Maargoed, kennelijk is het niet iets waar ze zelf hun vingers aan willen branden en is het dus een kwestie van "download maar een library".
[ Voor 14% gewijzigd door Hydra op 17-08-2012 10:54 ]
https://niels.nu
/u/249034/arrow.png?f=community){kind=icon}
Mwja, java-programmeurs hebben last van het toepassen van te veel design patterns. Als je kijkt naar hoe veel keer je new Blablabla(...) moet doen om een bestandje in te lezen in java bijvoorbeeld, omdat ze het decorator-pattern wel leuk vonden. Niet handig voor de gebruiker. Of dat je natuurlijk geen class terugkrijgt, maar een Interface, zodat je minder makkelijk in de IDE even kan checken of de implementatie ongeveer doet wat jij denkt dat die doet. Of die verwijst naar een methode die ergens is geoverride, want loose-coupling natuurlijk. En je kunt natuurlijk niet gewoon even die klasse instantiëren, dat doe je met een factory, waar met een string dynamisch de implementatie wordt geïnstantieerd, zodat je die makkelijk kunt wijzigen, want dat gebeurd zo vaak (ten opzichte van het gewoon kunnen doorklikken in je IDE). Maar om met die factory een nieuw object te kunnen aanmaken, moet je natuurlijk wel een configuratie hebben gebouwd volgens het builder pattern.
Gevolg: heel veel classes, die eigenlijk allemaal weinig doen, en tamelijk veel werk om er achter te komen wat er nu eigenlijk gaat gebeuren en hoe je dit laat gebeuren. Handig, die design patterns
</rant>En verder kun je hier makkelijk een topic mee vullen.
Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten
Heb jij zitten snuisteren in onze code?!!:
[...]
Mwja, java-programmeurs hebben last van het toepassen van te veel design patterns. Als je kijkt naar hoe veel keer je new Blablabla(...) moet doen om een bestandje in te lezen in java bijvoorbeeld, omdat ze het decorator-pattern wel leuk vonden. Niet handig voor de gebruiker. Of dat je natuurlijk geen class terugkrijgt, maar een Interface, zodat je minder makkelijk in de IDE even kan checken of de implementatie ongeveer doet wat jij denkt dat die doet. Of die verwijst naar een methode die ergens is geoverride, want loose-coupling natuurlijk. En je kunt natuurlijk niet gewoon even die klasse instantiëren, dat doe je met een factory, waar met een string dynamisch de implementatie wordt geïnstantieerd, zodat je die makkelijk kunt wijzigen, want dat gebeurd zo vaak (ten opzichte van het gewoon kunnen doorklikken in je IDE). Maar om met die factory een nieuw object te kunnen aanmaken, moet je natuurlijk wel een configuratie hebben gebouwd volgens het builder pattern.
Gevolg: heel veel classes, die eigenlijk allemaal weinig doen, en tamelijk veel werk om er achter te komen wat er nu eigenlijk gaat gebeuren en hoe je dit laat gebeuren. Handig, die design patterns
En verder kun je hier makkelijk een topic mee vullen.
Daar wil ik enige nuance aan toevoegen. Het hangt natuurlijk af van je definitie van overengineering. Maar zo'n ontwikkelaar per definitie slecht te noemen... mwa
Software development/design is constant afwegingen maken. Derhalve kan ik me goed voorstellen dat iemand ervoor kiest om een bepaald onderdeel wat uitgebreider op te zetten dan nodig is, omdat deze voorziet dat er in de toekomst nog veel aan zal worden toegevoegd oid.
Designing for change is een term die mij hierbij te binnen schiet.
Ik zou dit anders verwoorden. OO in het algemeen dwingt je om goed na te denken over de structuur van je code en de onderliggende verantwoordelijkheden.
Het plaatsen van functionaliteit in objecten is geen doel opzich namelijk, imo
edit: Ow en de dingen die ik niet quote ben ik gewoon mee eens overigens
[ Voor 3% gewijzigd door D-Raven op 17-08-2012 11:02 ]
Wat is dan volgens jou de oplossing? Alles in de File class stoppen? Functies om Bytes te lezen, Strings te lezen, of de file als random access te benaderen? Wat als het een gezipte file is?
Ik wil strings lezen uit een text file:
code:
1
| BufferedReader in = new BufferedReader(new InputStreamReader(new FileInputStream("bla.txt"))); |
Oh, die is compressed:
code:
1
| BufferedReader in = new BufferedReader(new InputStreamReader(new GZIPInputStream(new FileInputStream("bla.txt")))); |
DAT is de reden dat hier het decorator pattern voor gebruikt wordt. Je scheidt verantwoordelijkheden af in de classes die alleen die verantwoordelijkheid hebben. Het is namelijk doodsimpel om bovenstaande te veranderen zodat je die regels uit het geheugen of van een socket leest.
Ja, klote dat inheritance. Stel je toch eens voor dat een implementatie net niet doet wat je wil en je een eigen versie kan maken.
Nou, ik lees vooral een hoop geklaag. Natuurlijk zijn er slechte programmeurs die helemaal losgaan met design patterns, van elke class een interface + implementatie maken. Maar dat ligt niet aan het platform maar gewoon aan de programmeurs. Design patters zijn zaken die je, zoals vrijwel alles in de IT, kunt misbruiken.En je kunt natuurlijk niet gewoon even die klasse instantiëren, dat doe je met een factory, waar met een string dynamisch de implementatie wordt geïnstantieerd, zodat je die makkelijk kunt wijzigen, want dat gebeurd zo vaak (ten opzichte van het gewoon kunnen doorklikken in je IDE). Maar om met die factory een nieuw object te kunnen aanmaken, moet je natuurlijk wel een configuratie hebben gebouwd volgens het builder pattern.
Gevolg: heel veel classes, die eigenlijk allemaal weinig doen, en tamelijk veel werk om er achter te komen wat er nu eigenlijk gaat gebeuren en hoe je dit laat gebeuren. Handig, die design patterns
En verder kun je hier makkelijk een topic mee vullen.
Ik weet niet welke definitie jij van overengineering hebt maar het is per definitie negatief hoor?
Dat is geen overengineering. Overengineering is een duikboot bouwen als iemand alleen een rivier over wil steken: die persoon had genoeg gehad aan een simpele brug.
Dat heb ik ook nooit gezegd. Het plaatsen van functionaliteit in de juiste objecten wel.Ik zou dit anders verwoorden. OO in het algemeen dwingt je om goed na te denken over de structuur van je code en de onderliggende verantwoordelijkheden.
Het plaatsen van functionaliteit in objecten is geen doel opzich namelijk, imo
[ Voor 19% gewijzigd door Hydra op 17-08-2012 11:06 ]
https://niels.nu
/u/19474/avatar2015.png?f=community){kind=avatar}
Inderdaad. Komt bij dat dit soort zaken voor een groot deel door je IDE voor je geregeld wordt. Ik krijg het idee dat deze klachten vooral van mensen komen die alleen met notepad en javac werken omdat ze Eclipse niet snappen
https://niels.nu
Amen. ReSharper for teh win. Rechtsklik, 'Go To Implementation'.:
[...]
Inderdaad. Komt bij dat dit soort zaken voor een groot deel door je IDE voor je geregeld wordt. Ik krijg het idee dat deze klachten vooral van mensen komen die alleen met notepad en javac werken omdat ze Eclipse niet snappen
.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?
:strip_icc():strip_exif()/u/315253/boy-tweakers.jpg?f=community)
Nou ja, Eclipse is behoorlijk buggy. Ik krijg om de haverklap vage fouten als 'editor descriptor exception' of 'widget blah balh exception' en dan doe ik niks spannends. 
:strip_icc():strip_exif()/u/78891/W-Seawolf.jpg?f=community)
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_icc():strip_exif()/u/206968/325134.jpg?f=community)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Toch zit er een verschil tussen alles wegstoppen achter een interface, en echt OO design.
Het eerste vind ik echt waardeloos maar kom je vaak genoeg tegen (heb me er zelf ook aan schuldig gemaakt).
Het eerste vind ik echt waardeloos maar kom je vaak genoeg tegen (heb me er zelf ook aan schuldig gemaakt).
Dit wil ik nog steeds doorvoeren, nog geen tijd voor gehad
ctrl-shift-alt-b (uit mn hoofd):
[...]
Rechtsklik.
Weet nog toen ik voor t eerst in Swing een UI ging bouwen... dafuq zeg..
duh
Het gaat erom dat de definitie van wat overengineering is nogal verschilt van persoon tot persoon. Puur omdat het geen kwantificeerbaar iets is, het is onderhevig aan meningen en opvattingen.
Daar ben ik het mee eens, maar dan zit je wel meteen aan het extreme eind van t spectrum zegmaar
Waardoor het makkelijker is om iets als overengineering te bestempelen. Het wordt een stuk lastiger om dit te doen naarmate meer in het "grijze gebied" komt .Maargoed het wordt nogal een meta discussie over de definitie van 1 woord zo. Dus lets move on
Don't get me wrong, er zijn een hoop fouten gemaakt in de Java API. De UI meuk (oh AWT, oh nee Swing, oh nee dat is ook volkomen kut. Oh, Java3D...hmm...nee da's ook kut. Etc.) is wel het beste voorbeeld vind ik. Maar ik vind dat lezen van files gewoon een enorm slecht voorbeeld, dat is gewoon extreem simpel.
Moet je d'r eens een Java sourcefile van 6.6MB inplempen. Joy!:
Nou ja, Eclipse is behoorlijk buggy. Ik krijg om de haverklap vage fouten als 'editor descriptor exception' of 'widget blah balh exception' en dan doe ik niks spannends.
Mee eens. Ik had het ook niet over het grijze gebied, ik stelde het ff zwart wit. Als ik alles moet uitnuanceren hier kom ik niet meer aan m'n werk (*geeft Eclipse ff een schop*) toe
[ Voor 40% gewijzigd door Hydra op 17-08-2012 11:26 ]
https://niels.nu
:strip_icc():strip_exif()/u/24001/SV_klein.jpg?f=community)
Hahaha dat is echt met afstand, het slechtste argument welke ik ooit gehoord heb, om het design van Java goed te praten.
of mijn sarcasme detector is stuq dat kan ook
[ Voor 6% gewijzigd door D-Raven op 17-08-2012 11:49 ]
Ik vind het wel goed dat ze met .Net goed gekeken hebben naar de fouten die ze met Java gemaakt hebben en die fouten niet herhaald hebben. In .Net heb je veel meer 'handige' methodes voor veelgebruikte functionaliteiten. Zo is het lezen van een textfile wat simpeler. Maar dan moet je niet vergeten dat Java wel een stukje ouder is en ze niet zo maar even nieuwe dingen toe kunnen voegen zonder daar een goede afweging in te maken.
Maargoed. Ik vind dat file lezen een nonissue. En voor een hoop andere zaken (tijd, XML) zijn gewoon prima alternatieven in de vorm van betere simpelere libraries (joda, jdom) beschikbaar. XML lezen en schrijven doe ik als het even kan ook niet met de standaard J2EE meuk.
Nou, het speelt wel mee. Vergeet niet dat de core van Java bedoeld is om ongeveer overal op te draaien. Je hebt het dan niet over Windows versus Unix maar over Intel versus embedded systemen. Veel van die systemen kennen het concept 'file' uberhaupt niet. Dat heeft de design keuzes destijds in 1995 sterk beinvloed.:
Hahaha dat is echt met afstand, het slechtste argument welke ik ooit gehoord heb, om het design van Java goed te praten.
[ Voor 20% gewijzigd door Hydra op 17-08-2012 11:36 ]
https://niels.nu
/u/81985/crop566b00b43645a.png?f=community)
/u/63681/soia.png?f=community)
Als je dit voorbeeld al moeilijk vindt... Laten we anders ook eens Python gaan bashen met z'n GIL of hoe lastig het is om zlib te gebruiken.
Daarnaast zijn voor elke gebruikte class in Hydra's voorbeeld goede redenen en kan ik dit echt geen voorbeeld van overengineering noemen - eerder gewoon goed design (er zijn ook veel goede libs zoals commons-lang, commons-io, etc. die het allemaal nog simpeler maken). Laten we wel wezen, het hier vaak opgehemelde .net is op veel gebieden gebaseerd op Java en veel goede Java libraries worden geport naar .net (noda-time, nhibernate, nts, etc.). Respect your elders
[ Voor 5% gewijzigd door matthijsln op 17-08-2012 12:22 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_exif()/u/159970/avatar.60x60.gif?f=community){kind=avatar}
Dit begon dan ook als een opmerking over het maken van teveel klasses, dat alle java mensen zich meteen aangesproken voelden...
Het is/zijn voornamelijk java/java-ontwikkelaars die hier met de grond gelijk gemaakt worden. Niet zo heel gek dat een java-programmeur zich dan aangesproken voelt:
[...]
Dit begon dan ook als een opmerking over het maken van teveel klasses, dat alle java mensen zich meteen aangesproken voelden...
Er is genoeg aan te merken op Java. Alleen de opmerking die jij maakte sloeg nergens op. Dat jij je dan meteen aangevallen voelt...:
Dit begon dan ook als een opmerking over het maken van teveel klasses, dat alle java mensen zich meteen aangesproken voelden...
https://niels.nu
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_icc():strip_exif()/u/110760/ava.jpg?f=community)
Jij beweert dat niet expliciet maar je spreekt zijn reactie tegen waarin die vergelijking werd gemaakt. Dus impliciet is dat er uit af te leiden
Joh, het is gewoon een discussie. Je mag het best eens met iemand oneens zijn zolang je niet gaat lopen schelden toch?:
offtopic:
Pssst.... we houden het toch wel een beetje gezellig hé, zo voor 't weekend.
[ Voor 35% gewijzigd door Hydra op 17-08-2012 12:56 ]
https://niels.nu
Huh? Ik zeg dat
Java:
1
| BufferedReader in = new BufferedReader(new InputStreamReader(new FileInputStream("bla.txt"))); |
ingewikkelder is dan
Java:
1
| BufferedReader in = new FileReader("bla.txt"); |
omdat het eerste weliswaar handig is om een GzipStreamFiepeltje er tussen te hangen, maar niet handig is als je gewoon een bestand wilt lezen. Dat blijkt m.i. al uit het feit dat je voor de bovenste moet scrollen terwijl bij de onderste meteen duidelijk is wat er gebeurt.
Waarom je vervolgens de GIL (die alles met de implementatie van cpython en niets met de programmeertaal python zelf te maken heeft) en een willekeurige C library (waar een simpelere interface nu eenmaal lastig is) er bij haalt snap ik niet - zeker aangezien ik letterlijk zeg:
hoewel ik misschien beter had kunnen zeggen 'daar is de stdlib niet naar' - want commons-io doet dat inderdaad ietsje beter - hoewel je ook dáár iets in de richting van
Java:
1
| string = readStringFromFile(getFile('/path/to/file')) |
moet doen.
Bedoel je die ene taal uit 1991 of die andere uit 1993 - die beiden wél er voor kiezen om de common use case gemakkelijk te maken?Respect your elders
[ Voor 3% gewijzigd door ValHallASW op 17-08-2012 13:12 ]
Gezipte files zijn een apart geval. Ik wil een standaard-encoding die overal hetzelfde is: utf-8. En voor het standaard-inlezen wil ik dus helper functies zoals ReadAllLines (maar die ook kunnen omgaan met bestanden die niet in het geheugen passen en evengoed try-with-resources doet). Dus ik wil iets als (alle getallen in bestand optellen, ook voor bestanden die niet in het geheugen passen, gebuffered inlezen, resources teruggeven bij fout):
Java:
1
2
| var sum = new File("testbestand.txt").readLines() .select(line => Integer.parse(line)).sum(); |
In plaats van (verbeteringen zijn welkom):
Java:
1
2
3
4
5
6
7
| int sum = 0; try (BufferedReader s = new BufferedReader(new InputStreamReader( new FileInputStream("testbestand.txt"), "utf-8")), 2 << 17) { for (String line; (line = reader.readLine()) != null; ) { sum += Integer.parseInt(line); } } |
Verder is dit natuurlijk geen groot issue, maar het is wel een voorbeeld hoe met die 3 klasses een stukje design over de schutting richting de gebruikende programmeur wordt gegooid. En laten beginners nu juist gelijk dit soort dingen te zien krijgen.
Je hoeft mij dat pattern niet uit te leggen
Op het moment dat ik een implementatie van de library die ik aan het gebruiken ben aan het schrijven ben, gaat er volgens mij iets mis.
En java-programmeurs hebben hier dus een handje van.
Op zich is het niet erg als ik ver moet zoeken naar de daadwerkelijke implementatie van iets, maar als ook de examples ontbreken/niet werken en/of de documentatie brak is wordt het vervelend.Ah, dus de fundamentele reden dat een library een Interface teruggeeft in plaats van een class is zodat je lekker makkelijk kan testen?
Moet je mij toch eens vertellen hoe je Eclipse of Netbeans zo in stelt dat je met ctrl-click naar de juiste daadwerkelijke implementatie gaat (dus die de juiste interface-implementatie/child/parent pakt en desnoods strings die de boel aanroepen parsed daarvoor). Of hoe je op Github of Google code bij het snel bekijken van de source de IDE de boel laat uitvinden.:
Inderdaad. Komt bij dat dit soort zaken voor een groot deel door je IDE voor je geregeld wordt. Ik krijg het idee dat deze klachten vooral van mensen komen die alleen met notepad en javac werken omdat ze Eclipse niet snappen
Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten
Ik stel voor dat je eens goed terug gaat lezen waar ik op gereageerd heb en wat ik precies gezegd heb, want volgens mij ben je de boel een beetje uit het oog verloren:
[...]
Jij beweert dat niet expliciet maar je spreekt zijn reactie tegen waarin die vergelijking werd gemaakt. Dus impliciet is dat er uit af te leiden
En even voor de goede orde, als ik een stukje uit iemand's reactie quote dan reageer ik louter op dat stukje en niet per se op de rest van z'n reactie.
[ Voor 15% gewijzigd door .oisyn op 17-08-2012 13:16 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Want het is niet erg dat je het in 10 verschillende codebases allemaal één keer hebt staan
Dat het voor je backend praktisch is om het in losse classes op te splitsen geloof ik wel. Dat betekent alleen nog niet dat je dat ook in je common use case-API zou moeten laten zien.
Hier gaan we::
[...]
Ik stel voor dat je eens goed terug gaat lezen waar ik op gereageerd heb en wat ik precies gezegd heb, want volgens mij ben je de boel een beetje uit het oog verloren
:
[...]
Licht eens toe
Het lijkt me toch dat als je gevraagd wordt om toe te lichten waarom Java overengineered is en je stelt dat je het eens bent met ValHallASW je zijn GZipInputStream voorbeeld dus blijkbaar overengineered vindt, vandaar mijn reactie
/u/373849/cowava2.png?f=community)
A R G H!
libspotify.so
not a dynamic executable
Zoek het nu dan ook echt maar uit. Ik heb'm verdorie zelfs een make install gegeven!
libspotify.so
not a dynamic executable
Zoek het nu dan ook echt maar uit. Ik heb'm verdorie zelfs een make install gegeven!
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Grappig dat volgens jou gezipte files een 'geval apart' zijn, maar alle regels in een textfile in 1 keer inlezen, daar dus allemaal objecten voor aanmaken, en die dan simpelweg optellen, is geen 'apart' geval. Botweg X strings in het geheugen plempen vind ik nogal een typische usecase.
Sorry hoor, maar als een simpele for-loop al teveel gevraagd is... Hoe vaak moet je in een echte applicatie een hele textfile inlezen? En kom me niet aan met config files want het standaard Java mechanisme daarvoor heeft wel gewoon een convenience method (java.util.Properties)
Aangezien je een object dat verantwoordelijk is voor het lezen van een file ook de verantwoordelijkheid wil geven voor het bufferen van data kennelijk wel.Je hoeft mij dat pattern niet uit te leggen
Als het goed is biedt een library je alleen interfaces aan voor zaken die je zelf zou kunnen willen implementeren. Als het een library is waar botweg voor iedere implementatie een interface is, is het gewoon een slechte library. Die zijn er genoeg ja, maar dat heeft niks met Java te maken.
En dat is dus onzin. Ik werk zelf veel met Java en werk ook veel met developers die Java gebruiken. En ik zie vrijwel nooit dat deze developers zooi overengineeren. Waarom zouden ze? Ze werken ook gewoon onder dezelfde tijdsdruk die .Net en C++ programmeurs hebben hoor. Dergelijke opmerkingen vind ik gewoon dom en ongenuanceerd. Sorry.En java-programmeurs hebben hier dus een handje van.
PHP prutsers die zichzelf ondergewaardeerd voelen zeker. Kan ik me best voorstellen. PHP programmeurs hebben er nogal een handje van ranzige spaghetticode te produceren en van OO snappen ze ook niks.
See what I did thar?
[ Voor 9% gewijzigd door Hydra op 17-08-2012 13:38 ]
https://niels.nu
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Okay...
Je kunt eta-reduction toepassen op het argument van de select-method, i.e., (x => f(x)) == f.
Maar goed, de echte verbetering is natuurlijk een andere taal gebruiken:
Haskell:
1
| readFile "testbestand.txt" >>= return.sum.map read.lines |
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Wat goed aan .Net is, is dat niet alle publieke functies in de API staan beschreven (is niet een rant tegen de documentatie )
Waar Java veel last van heeft is de backwards compatibiliteit.
Veel functies uit b.v. de java.util.Date() class zijn deprecated. Maar dat houdt in; gebruik deze functie a.u.b. niet meer.
Maar omdat veel programmeurs dat verzoek negeren, moet het er nog steeds in zitten.
Er is geen mechanisme om dat af te dwingen (vanuit de fabrikant) anders dan door het te verwijderen. Daar zou m.i. nog een stap tussen moeten. Zodat oude programma's er nog gebruik van kunnen maken, maar nieuwe falen tijdens compilatie.
Classes: ja
)Waar Java veel last van heeft is de backwards compatibiliteit.
Veel functies uit b.v. de java.util.Date() class zijn deprecated. Maar dat houdt in; gebruik deze functie a.u.b. niet meer.
Maar omdat veel programmeurs dat verzoek negeren, moet het er nog steeds in zitten.
Er is geen mechanisme om dat af te dwingen (vanuit de fabrikant) anders dan door het te verwijderen. Daar zou m.i. nog een stap tussen moeten. Zodat oude programma's er nog gebruik van kunnen maken, maar nieuwe falen tijdens compilatie.
functies: nee
Classes: ja
[ Voor 9% gewijzigd door SPee op 17-08-2012 14:09 ]
let the past be the past.
Anonieme functies bestaan niet, anonieme classes wel.
Het gaat wel tegen alle coding standaarden in om ze te blijven gebruiken. Wat ik vervelender vind is gewoon het gegoochel met belangrijke componenten en deprecations daarvan. Maargoed, dat komt voor een deel omdat Java van verschillende voorgangers heeft geleend en aan de andere kant omdat er nogal wat powerstruggles zijn geweest tussen '95 en nu.:
Wat goed aan .Net is, is dat niet alle publieke functies in de API staan beschreven (is niet een rant tegen de documentatie
Waar Java veel last van heeft is de backwards compatibiliteit.
Veel functies uit b.v. de java.util.Date() class zijn deprecated. Maar dat houdt in; gebruik deze functie a.u.b. niet meer.
Maar omdat veel programmeurs dat verzoek negeren, moet het er nog steeds in zitten.
Er is geen mechanisme om dat af te dwingen (vanuit de fabrikant) anders dan door het te verwijderen. Daar zou m.i. nog een stap tussen moeten. Zodat oude programma's er nog gebruik van kunnen maken, maar nieuwe falen tijdens compilatie.
Zou kunnen, maar ik ben wel benieuwd of het ook zo geimplementeerd is. Daarna lijntjes tellen is ook niet erg efficient. Maar hoe dan ook vind ik dat botweg alle text inlezen over het algemeen niet de beste optie is, en dat dergelijke methodes 'lui' programmeren uitlokken.
[ Voor 19% gewijzigd door Hydra op 17-08-2012 14:11 ]
https://niels.nu
Ik tel niet zo vaak aantal regels in mijn Java code maar als ik het eens wil weten van een bestand gebruik ik vaak deze implementatie
/u/142011/crop65b383c6c6c2f_cropped.png?f=community)
En de nieuwe Non Blocking IO al is dat meer iets voor de JDK7..
Also @ de mensen een paar pagina's terug die zo moeilijke "go to definition" hebben in VS. ctrl+click hier bij mij
[ Voor 13% gewijzigd door Caelorum op 17-08-2012 14:31 ]
Nou, gelukkig zijn we het er dan over eens dat die GZipInputStream handig is
Voor wat betreft het nodig hebben van 5 classes, tja. Zonder gzip waren het er in het voorbeeld maar drie hoor. Er zijn goede redenen voor zoals hier uitputtend uitgelegd. Ik vind het best duidelijk:
Van file naar byte stream
Van byte stream naar karakter stream
Van unbuffered naar buffered met line reading
Best goed ge-engineered toch?
Toevallig is dit precies hoe ze het in .net hebben gedaan, nadat ze hadden afgekeken hoe het in java werkt. En die functionaliteit wordt niet zozeer herhaalt: dezelfde implementatie wordt aangeroepen.
Daarnaast is er al best wat buffering aanwezig in de api's/hardware die een filereader aanroept. Ik zie geen normale usecase voor niet bufferen, dus waarom zou je die usecase standaard aanbieden? En java heeft daarnaast nog een geavanceerde IO api ook (nio) die voor dat soort bijzondere gevallen is.
Yikes, nu werk je met de platform default encoding die willekeurig kan zijn ingesteld! Zo ga je de Turkey test nooit halen.
Dus je moet zelf een wrapper-functie gaan schrijven die eigenlijk in de library had moeten zitten?
Wie zegt dat de strings niet weggeoptimaliseerd worden bij het uitvoeren? Die ReadAllLines functie in .net is er voor een reden: als je simpel even een array met ints met testIds wil inlezen bijvoorbeeld. Echt niet heel vreemd, zelfs ongeveer sinds het mainframetijdperk gebruikelijk.
Het is een overgeneralisatie natuurlijk. Voorbeeldje anders van een op zich prima library met helaas wat overdesign? http://www.twitter4j.org Ondersteund bijvoorbeeld meerdere logging-frameworks, waaronder SLF4J, wat reeds een facade is die had kunnen worden bijgeleverd, of ze hadden de standaard java.util.logging.Logger kunnen gebruiken die kan worden doorgelinkt naar SLF4J. En natuurlijk voldoende Factories, Interfaces, enz.
Eerst maar eens lambda's in java
Nee, dit is dus een door mij gewenste situatie.
readLines() levert in mijn gewenste situatie een Iterable<String>, AutoCloseAble op. Er wordt dus geen array gebruikt, en resources worden geforceerd gesloten buiten de aanroep (ook een nieuwe feature). Een onderliggende implementatie zou prima van memory mapped files gebruik kunnen maken, waarbij de data dus idealiter on-demand maar 1 keer van disk naar geheugen wordt gekopieerd direct die String-objecten in.
Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten
Net een (beetje) werkende Aargh! interpreter geschreven. Alleen ergens zit iets fout, waardoor "hello world" "hello wordldAargh!" wordt 
Ach ja, dan nog maar ff doormodderen, steek je altijd weer iets van op
Ach ja, dan nog maar ff doormodderen, steek je altijd weer iets van op
Misschien komt het omdat je een A teveel hebt?
Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten
http://www.sha-bang.de/12_eso/Argh-Spec.txt
EDIT: hoewel ik niet controleer hoe breed de regels zijn, dus het Aaargh! zou zijn, zou dat bestaan
code:
1
2
3
4
| for string in code:
if len(string)>80:
print("Aargh!")
return |
nu wel
[ Voor 11% gewijzigd door iThinkSo op 17-08-2012 14:52 ]
Hét bewijs dat .Net infinite keer beter is dan Java
:When you use ReadLines, you can start enumerating the collection of strings before the whole collection is returned; when you use ReadAllLines, you must wait for the whole array of strings be returned before you can access the array. Therefore, when you are working with very large files, ReadLines can be more efficient.
Overigens begint .Net ook al een hoop backwards compatiblity meuk te krijgen.
Edit:
Ow dus Java kan dat ook? Hè daar gaat mn ".Net ownzz" argument
@Pedorus: in versie 4 al lees ik! Ik ga toch maar eens upgraden...
[ Voor 24% gewijzigd door alwinuzz op 17-08-2012 14:52 ]
Ah, wist niet eens dat ze mijn gewenste functie al hadden toegevoegd in .net 4
Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten
Juist omdat je onderliggende platform over het algemeen al buffert wil je dat NIET standaard doen. Stel dat je leest uit een memorystream bijvoorbeeld, dan heeft nog een keer bufferen toch geen zin? Je wil de buffering van BufferedReader in de meeste gevallen dat je binaire data uit een file leest (ook een veelvoorkomende usecase) misschien weer helemaal niet.
Ja hallo, ik klaagde niet over de complexiteit!Yikes, nu werk je met de platform default encoding die willekeurig kan zijn ingesteld! Zo ga je de Turkey test nooit halen.
Aangezien de library niet weet of die 10 files van jou gzipped textfiles of deflated bitmaps zijn: ja. En aangezien het ongeveer 10 seconden werk is dat je 1 keer moet doen zie ik het probleem ook niet.Dus je moet zelf een wrapper-functie gaan schrijven die eigenlijk in de library had moeten zitten?
Dat snap ik ook wel. Het probleem is dat heel veel mensen die ook doodleuk gebruiken om de integer waarden te parsen en die op te tellen.
Ik vind het apart dat je aan de ene kant niet voor "convenience" bent in het lezen van files, maar als je in een library convenience aangeboden wordt zodat je rechtstreeks je favoriete logging framework kunt gebruiken dan is het overengineering? Spreek je jezelf nu niet een beetje tegen? Je kunt in .Net ook regels 1 voor 1 lezen, waarom heb je dan een ReadAll() method nodig?
Java 8Eerst maar eens lambda's in java
Een specifiek iets wat je volgens mij prima zelf kunt doen lijkt me? Schrijf je een keer en kun je daarna hergebruiken.
Euh, de standaard manier van textfiles lezen in Java is gewoon regel voor regel he, dus als je het goed doet lees je ze sowieso niet eerst allemaal in je geheugen. Het komt sowieso niet vaak voor dat je dat wil.:
[...]
Hét bewijs dat .Net infinite keer beter is dan Java
When you use ReadLines, you can start enumerating the collection of strings before the whole collection is returned; when you use ReadAllLines, you must wait for the whole array of strings be returned before you can access the array. Therefore, when you are working with very large files, ReadLines can be more efficient.
[ Voor 10% gewijzigd door Hydra op 17-08-2012 14:56 ]
https://niels.nu
Volgens mij komt het erop neer dat Java wat handige shortcut functies mist, klopt dat?
Los daarvan heb ik het idee dat er bij Java en .Net meer architecture astronauts zitten dan bij Ruby of PHP. Dat betekent niet dat elk Java programma overengineerd is, maar het komt wel relatief vaak voor.
Ik weet niet of ik hier PHP moet noemen, straks hebben we díe discussie weer
Los daarvan heb ik het idee dat er bij Java en .Net meer architecture astronauts zitten dan bij Ruby of PHP. Dat betekent niet dat elk Java programma overengineerd is, maar het komt wel relatief vaak voor.
Ik weet niet of ik hier PHP moet noemen, straks hebben we díe discussie weer
/u/313216/crop679f937b7f4c1_cropped.png?f=community)
Ik had vroeger ook ctrl+click aanstaan (powertools), maar heb dat disabled. Ik dubbelklik vaak en wil Ctrl+C doen, waardoor ik iets te vaak weg sprong. F12 rammen of RMK->Go to definition is nu ook niet zo veel extra werk:
[...]
Also @ de mensen een paar pagina's terug die zo moeilijke "go to definition" hebben in VS. ctrl+click hier bij mij
.
Mwa. Het komt er op neer dat mensen die niet zo bekend zijn met Java een verkeerd beeld van Java hebben. Net zoals dat geneuzel over dat Java erg traag zou zijn. Dat is op z'n minst wat ongenuanceerd
Er zitten zeker een hoop rare / irritante dingen in Java, maar dat heb je overal wel. Ik ben zelf geen 'Java programmeur'. Ik doe dingen in C#, Java, Javascript, Python, etc. Iedere taal/framework heeft weer z'n eigen voors en tegens. Ben bijvoorbeeld zelf erg gecharmeerd over Node.js, hoewel ik het async gebeuren nog niet helemaal onder de knie heb.
https://niels.nu
Juist omdat het onderliggende platform buffert, wil je daarop je api-calls optimaliseren. Als je 1 byte meer buffert dan de onderliggende laag, dan heeft de onderliggende laag opeens 2 buffer-leesacties nodig voor de afhandeling. Andersom levert te weinig te bufferen weer te veel api-calls en overhead op.
Helemaal mee eens. Daarom wil je ook niet dat daar een BufferedReader voor wordt geplaatst door iemand die denkt dat je die maar beter overal op kan zetten.. En een MemoryStream doet natuurlijk standaard niet aan buffering.
Inlezen per 1 byte levert veels te veel api calls op en is zeldzaam traag, probeer maar eens uit.
Ik klaag over excessieve benodigde code bij sommige frameworks, de code weglaten met beroerd resultaat is daarvoor niet echt een oplossing.Ja hallo, ik klaagde niet over de complexiteit!
Het probleem is dat je bij het kopieren naar een simpel testprojectje je opeens ook je persoonlijke utility-functies erbij moet zoeken. En als iedereen zijn eigen utility-functies heeft, die niet overeenkomen, wordt het het er echt niet handiger op. Het idee van een library is natuurlijk juist dat iedereen dezelfde aanroepen kan gebruiken voor veel-voorkomende taken.
Als ze de tijd die die extra onnodige abstracties hebben gekost gestoken hadden in goede documentatie, dan was ik echt een stuk blijer geweest. Afgezien van de te verwaarlozen overhead aan geheugen/cpu.
Zo specifiek dat het standaard in vele andere talen zit.
Ik ben niet van de eigen 'persoonlijke' libraries maken, bovendien ontbreekt er dus ook nog wat functionaliteit in java zelf voor de ideale oplossing.
Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten
Goed, ik vind het een beetje geneuzel in de marge. Als we het willen hebben over hoe kut Java is kunnen we beter over Swing beginnen. Dan zijn we het sneller eens
https://niels.nu
Tja, ik ben ook niet zo van de jazz:
Goed, ik vind het een beetje geneuzel in de marge. Als we het willen hebben over hoe kut Java is kunnen we beter over Swing beginnen. Dan zijn we het sneller eens
Wikipedia: Swing
Een discussie als deze hou je toch niet om het eens te worden?
Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten
Oh nee, maar op een gegeven moment ga je in cirkeltjes rond en dan houdt 't wel een beetje op.:
Een discussie als deze hou je toch niet om het eens te worden?
Komt bij dat ik zin heb in 't weekend
https://niels.nu
Het is gewoon veels te warm vandaag, tijd voor een biertje 
Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten
:strip_icc():strip_exif()/u/87691/avatar_alex.jpg?f=community){kind=avatar}
Iemand Windows 8 gekregen via Action Pack for Development (https://mspartner.microso...tion-pack-dev-design.aspx) ? Dan kan ik mijn pa vragen
Nee, 20 augustus waarschijnlijk.:
Iemand Windows 8 gekregen via Action Pack for Development (https://mspartner.microso...tion-pack-dev-design.aspx) ? Dan kan ik mijn pa vragen
.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?
Dat gaat een stuk sneller met een baar biertjes op, hoor:
[...]
Zou graag meedoen, maar ik moet nog vele honderden kilometers rijden
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
nouja ik ben gestrand met me auto op me werk. Zit een scheur in de hoofd olie leiding waardoor me stuurbekrachtiging niet meer werkt . Nou wachten op de rolstoel taxi om me naar huis te laten brengen.
. Nou wachten op de rolstoel taxi om me naar huis te laten brengen.
Nothing to see here!
Ai, die bedrijven die telkens in het nieuws komen voor de 'goede' service? of was dat wat anders?:
nouja ik ben gestrand met me auto op me werk. Zit een scheur in de hoofd olie leiding waardoor me stuurbekrachtiging niet meer werkt
:strip_exif()/u/294184/20150204_SITE_GIF_VALKUIL-resized.gif?f=community)
Jippie.
Ben een stuk software in java aan het schrijven dat gebruik maakt van sterke versleuteling. Had daarvoor (het project dateert al van vorig jaar) in het begin mijn Jurisdiction Policy File* aangepast, was dit verder totaal vergeten... Wou vandaag de app testen op een andere pc, werkte ie niet... Toch eventjes moeten nadenken
* Nuttige links: http://docs.oracle.com/ja...jce/JCERefGuide.html#AppE, http://www.oracle.com/tec...ce-6-download-429243.html
Ben een stuk software in java aan het schrijven dat gebruik maakt van sterke versleuteling. Had daarvoor (het project dateert al van vorig jaar) in het begin mijn Jurisdiction Policy File* aangepast, was dit verder totaal vergeten... Wou vandaag de app testen op een andere pc, werkte ie niet... Toch eventjes moeten nadenken
* Nuttige links: http://docs.oracle.com/ja...jce/JCERefGuide.html#AppE, http://www.oracle.com/tec...ce-6-download-429243.html
Nah. Mercedes Benz heeft heel netjes me auto weggehaald. Maandag krijg ik hem weer terug
. En taxi is me komen ophalen. Leuk zo'n aangepaste rolstoel bus maar je hebt haast geen vervangend vervoer in deze situaties XD
Nothing to see here!
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Daar kan ik me dan ook wel aan ergeren, maar aan d/t fouten toch echt niet hoor. Dat word toch wel erg vervelend
Deze vind ik ook vele malen erger dan d/t fouten. Je leest het overal. Het gaat ook nergens over, denken mensen dat je het uitspreekt als thirth ofzo
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ach, leading zeroes zijn niet significant
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_exif()/u/11775/SoulTaker.gif?f=community)
Dit topic is gesloten.