Archief - Hibernate should be to programmers what cake mixes are to bakers

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Cycloon

Legacy Member
Ze heeft een punt natuurlijk :) Uiteraard moet je hier en daar wel iets nuanceren. Niet elk generisch framework is slecht, je moet alleen weten wanneer het bruikbaar is.

NeverwinterX

Legacy Member
De 3de comment op die pagina trekt de redenering door en legt de fout in de redenering pijnlijk bloot.

Yes, we should not use any frameworks at all. In fact, we shouldn't even be using Java. Assembler FTW!

Cycloon

Legacy Member
NeverwinterX zei:
De 3de comment op die pagina trekt de redenering door en legt de fout in de redenering pijnlijk bloot.

Je hebt dan niet echt begrepen wat ze wou duidelijk maken. Om het maar met haar woorden te zeggen:

Met een cakemix win je geen tijd, want je moet nog steeds evenveel handelingen doen + je weet niet wat je krijgt.
Als je een brood, wijn of kaas gaat kopen in de winkel win je wel tijd, want dat kan je direct consumeren.

Java zit overduidelijk in de tweede situatie, waar het gebruik van het framework echt voordelen heeft. Hibernate neigt heel sterk naar de eerste situatie waar je zelf gelooft dat je tijd wint maar het eigenlijk niet zo is.

NeverwinterX

Legacy Member
Cycloon zei:
Je hebt dan niet echt begrepen wat ze wou duidelijk maken. Om het maar met haar woorden te zeggen:

Met een cakemix win je geen tijd, want je moet nog steeds evenveel handelingen doen + je weet niet wat je krijgt.
Als je een brood, wijn of kaas gaat kopen in de winkel win je wel tijd, want dat kan je direct consumeren.

Java zit overduidelijk in de tweede situatie, waar het gebruik van het framework echt voordelen heeft. Hibernate neigt heel sterk naar de eerste situatie waar je zelf gelooft dat je tijd wint maar het eigenlijk niet zo is.

Dat hangt af van de cakemix, met een fatsoenlijke cakemix win je wel degelijk tijd.

Wat ze zegt over Hibernate kan je perfect doortrekken naar Java:
Hibernate als hoger niveau alternatief voor SQL - Java alternatief voor lower level languages zoals assembler, c, c++ ...
Hibernate is in sommige gevallen even lang als SQL - Java is in sommige gevallen even lang als assembler/c/c++/... (closures bijvoorbeeld)
Hibernate is in sommige gevallen niet efficient - Java is in sommige gevallen inefficient
Het is dezelfde redenering en die is even fundamentally flawed.

En de statement dat je met Hibernate geen tijd wint, is ook pertinent onwaar. Check your facts.

Er zijn gevallen waar pure SQL beter gebruikt kan worden dan Hibernate, net zoals er gevallen zijn waar je beter assembler gebruikt dan Java, maar dat is een beperkte set van gevallen. Het zoveelste voorbeeld van een ongenuanceerde, onnauwkeurige generalisering van de persoonlijke use cases waarmee je bezig bent, waardoor je het geheel uit het oog verliest. Meestal gaat het dan om een persoonlijk fixatie/obsessie van de auteur of het is een moedwillige overdrijving om te zorgen dat het punt dat je maakt meer in het oog springt (genuanceerde meningen springen nu eenmaal niet in het oog, denk aan marketing).

Cycloon

Legacy Member
NeverwinterX zei:
Er zijn gevallen waar pure SQL beter gebruikt kan worden dan Hibernate, net zoals er gevallen zijn waar je beter assembler gebruikt dan Java, maar dat is een beperkte set van gevallen.

Ik vind deze vergelijking eerlijk gezegd niet zo sterk. Het is niet zo dat je java door en door moet kennen om er goede applicaties met te bouwen. Hibernate moet je wel door en door kennen om het correct te gebruiken. Als je zelf je queries schrijft moet je maar 1 niveau van abstractie leren kennen (en dat is de SQL interface van je databank).

NeverwinterX zei:
Het zoveelste voorbeeld van een ongenuanceerde, onnauwkeurige generalisering van de persoonlijke use cases waarmee je bezig bent, waardoor je het geheel uit het oog verliest. Meestal gaat het dan om een persoonlijk fixatie/obsessie van de auteur of het is een moedwillige overdrijving om te zorgen dat het punt dat je maakt meer in het oog springt (genuanceerde meningen springen nu eenmaal niet in het oog, denk aan marketing).

Ik had dat zelf al genuanceerd hoor in mijn eerste post. En uiteraard is dit filmpje gemaakt door iemand die overduidelijke tegen hibernate is.

Anyway, mijn mening over ORM is sowieso dat je het gerust kan gebruiken in eenvoudige omgevingen. Wanneer meer vereist is moet je ofwel het ORM systeem enorm goed kennen ofwel hier en daar zelf de nodige sql statements schrijven (en dan opteer ik persoonlijk voor het laatste).

Moto

Legacy Member
De 3de comment op die pagina trekt de redenering door en legt de fout in de redenering pijnlijk bloot.
Als ge de Video van 8 min 50 effectief zou gezien hebben zou ge weten dat die comment compleet naast de kwestie was. maar allez...

snap wel dat ge geen tijd voor filmkes te zien hebt als ge nhibernate gebruikt, al die logs nakijken om die N + 1 selects te vinden kost tijd

dJeez

Legacy Member
Cycloon zei:
Met een cakemix win je geen tijd, want je moet nog steeds evenveel handelingen doen + je weet niet wat je krijgt.
Als je een brood, wijn of kaas gaat kopen in de winkel win je wel tijd, want dat kan je direct consumeren.
Als je direct software koopt win je tijd, want die kan je direct beginnen gebruiken. Waarom dus nog software gaan ontwikkelen?

Als je uitgangspunt verkeerd is, met name dat je er schijnbaar van uit gaat dat de cake zichzelf zou moeten bakken, tjah, dan zal je uiteraard ontgoocheld zijn. Overigens doe je met een cakemix echt wel minder handelingen, vraag het maar aan de eerste de beste bakker - of lees er eens een kookboek op na :p.

Wegens gebrek aan Flash (oude PPC laptop als tijdelijke backup voor de MBP die de geest aan 't geven was) heb ik het filmpje wel nog niet kunnen zien. Ik weet 1 ding en dat is dat een goed framework u wel degelijk time to market tijd bespaart (en dus sneller inkomsten oplevert), dat je achteraf nog dingen moet bijschaven is iets dat niet inherent is aan het gebruik van frameworks.

Cycloon

Legacy Member
dJeez zei:
Als je direct software koopt win je tijd, want die kan je direct beginnen gebruiken. Waarom dus nog software gaan ontwikkelen?

Als je uitgangspunt verkeerd is, met name dat je er schijnbaar van uit gaat dat de cake zichzelf zou moeten bakken, tjah, dan zal je uiteraard ontgoocheld zijn. Overigens doe je met een cakemix echt wel minder handelingen, vraag het maar aan de eerste de beste bakker - of lees er eens een kookboek op na :p.

Wegens gebrek aan Flash (oude PPC laptop als tijdelijke backup voor de MBP die de geest aan 't geven was) heb ik het filmpje wel nog niet kunnen zien. Ik weet 1 ding en dat is dat een goed framework u wel degelijk time to market tijd bespaart (en dus sneller inkomsten oplevert), dat je achteraf nog dingen moet bijschaven is iets dat niet inherent is aan het gebruik van frameworks.

Kijk eerst eens naar het filmpje zou ik zeggen.

En in sommige situaties zal hibernate er voor zorgen dat je een kleinere time to market hebt. Dit zal eerder in eenvoudige applicaties zijn waar weinig concrete afspraken zijn van specs (buiten de functionele). Echter, voor backends die een grote workload hebben oid kom je er niet met hibernate, tenzij je er véél meer werk insteekt om die perfect te configureren (en dan nog). Maar dan kan je al net zo goed gewoon zelf je queries schrijven en je objecten vullen. Dus het komt er weer op neer welke de use case is.

NeverwinterX

Legacy Member
Moto zei:
Als ge de Video van 8 min 50 effectief zou gezien hebben zou ge weten dat die comment compleet naast de kwestie was. maar allez...

snap wel dat ge geen tijd voor filmkes te zien hebt als ge nhibernate gebruikt, al die logs nakijken om die N + 1 selects te vinden kost tijd

Als ge de video effectief gezien en begrepen zou hebben, zou ge de analogie in de (foute) redenering zien met de comment en zien dat die comment helemaal niet naast de kwestie is. Ze maken alletwee dezelfde belachelijke, ongenuanceerde redenering die in slechts een beperkt aantal gevallen geldt (met het verschil dat diegene die de comment maakt het tenminste beseft en het expres doet om de fout te tonen).

blackrabbit

Legacy Member
Ze heeft anders wel een punt.
Het gaat hier niet enkel over performance. Het doel van Hibernate is net het onttrekken van database gerelateerde code (SQL) van uw programma code. Mooi en wel, maar als je dan plots je code moet gaan volschrijven met annotaties (en dat moet zelfs bij de kleinste applicaties), in hoeverre win je dan iets? Ipv SQL te leren/schrijven, moet je Hibernate annotaties gaan opzoeken/leren.

In die zin gaat de vergelijking met assembler<->Java niet op: Java vereenvoudigt wel degelijk het programmeren (je moet véél minder schrijven en op een makkelijkere manier denken om hetzelfde te bereiken). De vergelijking wordt nog belachelijker als je Assembler vs C/C++ neemt. Gcc/g++ optimaliseren de uiteindelijke programmacode zo sterk, dat het al moeilijk wordt om als assembler-programmeur performantere software te schrijven. Terwijl C of C++ toch wel véle malen makkelijker/sneller te programmeren is.

NeverwinterX

Legacy Member
blackrabbit zei:
Ze heeft anders wel een punt.
Het gaat hier niet enkel over performance. Het doel van Java is net het onttrekken van low level details van uw programma code. Mooi en wel, maar als je dan plots je code moet gaan volschrijven met objecten (en dat moet zelfs bij de kleinste applicaties), in hoeverre win je dan iets? Ipv Assembler te leren/schrijven, moet je Java gaan opzoeken/leren.

In die zin gaat de vergelijking met SQL<->Hibernate niet op: Hibernate vereenvoudigt wel degelijk het programmeren (je moet véél minder schrijven en op een makkelijkere manier denken om hetzelfde te bereiken).

See what i did there?

Gcc/g++ optimaliseren de uiteindelijke programmacode zo sterk, dat het al moeilijk wordt om als assembler-programmeur performantere software te schrijven. Terwijl C of C++ toch wel véle malen makkelijker/sneller te programmeren is.

Kwestie van tijd, vroeger waren de high level languages ook niet zo performant als assembler. Ik verwacht niet dat het lang duurt voor Hibernate en consoorten even snel zijn (als ze dat niet al zijn in sommige gevallen).

Moto

Legacy Member
See what i did there?
hoe meer Non-trival abstractions zijn hoe meer leaky de abstractions zijn, tot op een punt dat de abstraction niet meer de moeite waard is, trouwens ook nog eens denken aan mensen die later support moeten doen van zoiets.

Ik verwacht niet dat het lang duurt voor Hibernate en consoorten even snel zijn
hoe lang dan nog? fallacies of distributed computing zijn nog altijd relevant, bandwith = finite, latency is zero, en die zullen ook nooit weg gaan

Anyways

Het gaat ook niet alleen om de makkelijkheid van bereiding maar ook om het eindresultaat.
Als ik naar een dure pizzeria ga, wil ik geen Dr Oetker voorgeschoteld krijgen.

Als ik wel ergens een overeenkomst zie tussen "developers" die (n)hibernate gebruiken is het wel een totale apatische houding ten opzichte van wat de gebruiker zal vinden van hun applicatie.
Als hun gebruikers blij worden of gefrustreerd worden van hun software maakt voor hun NIKS uit

Nu als uw gebruikers blij zijn met uw nhibernate toepassing, geen probleem voor mij, een applicatie is maar zo goed als wat uw gebruikers dervan vinden ongeacht welke methodolgie/Framework/design patterns of technologie.
Het kan zijn dat mensen die nHibernate gebruiken WEL rekening houden met hun gebruikers en met performance ed, ik moet er alleen nog zo iemand tegenkomen

NeverwinterX

Legacy Member
Moto zei:
hoe meer Non-trival abstractions zijn hoe meer leaky de abstractions zijn, tot op een punt dat de abstraction niet meer de moeite waard is, trouwens ook nog eens denken aan mensen die later support moeten doen van zoiets.

Sure, maar ik zou niet stellen dat dat geldt voor Hibernate. Er is wel degelijk sprake van nuttige abstraction die tijd en low level details bespaart in een hoop (niet alle) gevallen.
En een reeks SQL spaghetti statements is makkelijker te onderhouden dan Hibernate zeker? Right.


Moto zei:
hoe lang dan nog? fallacies of distributed computing zijn nog altijd relevant, bandwith = finite, latency is zero, en die zullen ook nooit weg gaan

Van mij zeggen dat de analogie met Java naast de kwestie is, maar dan zelf met een analogie komen.
Fallacies of distributed computing en toch maakt cloud computing nu zwaar zijn opmars, blijkbaar zijn de fallacies toch niet echt onoverkomelijk.

Moto zei:
Anyways
Het gaat ook niet alleen om de makkelijkheid van bereiding maar ook om het eindresultaat.
Als ik naar een dure pizzeria ga, wil ik geen Dr Oetker voorgeschoteld krijgen.

Hangt ervan af of het verlies in efficiëntie significant is voor de eindgebruiker. In de meeste toepassingen niet. En dan zorgt de hogere abstractie voor een betere kwaliteit, aanpasbaarheid, onderhoudbaarheid van de rest van de code.


Moto zei:
Als ik wel ergens een overeenkomst zie tussen "developers" die (n)hibernate gebruiken is het wel een totale apatische houding ten opzichte van wat de gebruiker zal vinden van hun applicatie.
Als hun gebruikers blij worden of gefrustreerd worden van hun software maakt voor hun NIKS uit

Nu als uw gebruikers blij zijn met uw nhibernate toepassing, geen probleem voor mij, een applicatie is maar zo goed als wat uw gebruikers dervan vinden ongeacht welke methodolgie/Framework/design patterns of technologie.
Het kan zijn dat mensen die nHibernate gebruiken WEL rekening houden met hun gebruikers en met performance ed, ik moet er alleen nog zo iemand tegenkomen

Kansloze generalisering van een groep developers zoals je vaker ziet, vb "C programmers schrijven slechte code" etc. Nogal flauw.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan