/u/12668/hydra.png?f=community)
:strip_icc():strip_exif()/u/206968/325134.jpg?f=community)
Ik vind het vervelend dat je zo over je collega's praat
Mijn kinderen doen dat noooooooooooooooooooit
[ Voor 7% gewijzigd door Matis op 24-10-2019 09:51 ]
If money talks then I'm a mime
If time is money then I'm out of time
/u/262310/ava.png?f=community)
:strip_icc():strip_exif()/u/36083/crop5dca9e34ce091_cropped.jpeg?f=community)
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
:strip_icc():strip_exif()/u/439769/crop5a510243ea2e3_cropped.jpeg?f=community)
/u/3813/100_8985_ICON2.JPG?f=community)
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
:strip_exif()/u/52746/eric-cartman_small.gif?f=community)
Mwa je kan nu al wel Engels met haar praten, dus 2 talen gaat wel lukken
Maar als ik haar goed Duits wil leren, dan moet ik het zelf ook weer spreken en dus mensen kennen waarmee dat kan (en het bovendien ook interessant is).
Ik ben 3 talig opgegroeid overigens. Mijn ouders spraken altijd Duits met mij, Nederlands op school en ik had een Engelse buurjongen waar ik een tijd veel mee omging (daarnaast natuurlijk allemaal films in het Engels gezien etc).
Mijn vader sprak daarnaast ook nog Frans en kon dus 4 talen.
Hoewel ik talen snel kan leren, verleer ik ze ook weer snel als ik ze niet blijf gebruiken...
Het is een beetje hetzelfde als met programmeertalen
PS
Dit las ik gisteren op de site van de BBC:
Fun fact: "Withdrawal Agreement Bill" translates to a 44-letter word in German
Germany's Brexit spokesman, Axel Dittmann, has revealed on Twitter that "Austrittsvertragsratifizierungsgesetzentwurf" is the German word for "Withdrawal Agreement Bill."
[ Voor 14% gewijzigd door Lethalis op 25-10-2019 06:55 ]
Ask yourself if you are happy and then you cease to be.
/u/243953/crop56f55a7bcf291.png?f=community)
Ik zelf vind het woord datenverarbeitungsanlage altijd nog interessant en tekenend voor Duits. Omschrijvend tot en met, maar niet altijd even praktisch:
[...]
PS
Dit las ik gisteren op de site van de BBC:
Fun fact: "Withdrawal Agreement Bill" translates to a 44-letter word in German
Germany's Brexit spokesman, Axel Dittmann, has revealed on Twitter that "Austrittsvertragsratifizierungsgesetzentwurf" is the German word for "Withdrawal Agreement Bill."
:strip_icc():strip_exif()/u/36003/crop584e9e5c223bd.jpeg?f=community)
Gerelateerd aan dat andere prachtige Duitse woord Sehnsucht.:
Weltschmerz takes the cake.
En aan het enige mooie Portugese woord: saudade.
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
Saudade is mooi, taal is mooi.
Weltanschauung, zeitgeist en gestalt. Duits is best mooi, ik wou dat ik het kon spreken.
Duits is mooi hoe je enorm veel informatie in een woord weet te vatten.
[ Voor 9% gewijzigd door Sandor_Clegane op 25-10-2019 09:21 ]
Less alienation, more cooperation.
Duitse IT termen zijn überhaupt verschrikkelijk:
[...]
Ik zelf vind het woord datenverarbeitungsanlage altijd nog interessant en tekenend voor Duits. Omschrijvend tot en met, maar niet altijd even praktisch
Programmierschnittstelle (API)
Laufzeitumgebung (runtime)
Ausführungsgeschwindigkeit (performance)
Automatische Speicherbereinigung (Garbage Collection)
Enzovoorts. Er is een moment in mijn leven geweest dat ik dacht om voor de gein eens naar Duitsland te verhuizen en te kijken hoe dat nou is. Maar toen realiseerde ik mij al snel dat ik dan ook als programmeur in Duitsland moet werken
Alleen al het idee dat het OS in het Duits zou zijn
Datei öffnen! Abbrechen! Speichern! Drucken! Beenden!
Argh.
Ask yourself if you are happy and then you cease to be.
Vroegah, heb ik een Amiga 1200 in Duitsland gekocht, met een Duits OS. Daar zat ook een duitse Deluxe Paint bij, man man dat was zoeken.:
[...]
Duitse IT termen zijn überhaupt verschrikkelijk
Programmierschnittstelle (API)
Laufzeitumgebung (runtime)
Ausführungsgeschwindigkeit (performance)
Automatische Speicherbereinigung (Garbage Collection)
Enzovoorts. Er is een moment in mijn leven geweest dat ik dacht om voor de gein eens naar Duitsland te verhuizen en te kijken hoe dat nou is. Maar toen realiseerde ik mij al snel dat ik dan ook als programmeur in Duitsland moet werken
Alleen al het idee dat het OS in het Duits zou zijn
Datei öffnen! Abbrechen! Speichern! Drucken! Beenden!
Argh.
Less alienation, more cooperation.
Weet je wat zoeken is?
Als je - net zoals ik - in de begintijden van XFCE de allernieuwste versie installeerde en er volgens achterkwam dat alles in het Frans was
Ouvrir le fichier!
Het is mij nooit gelukt om goed Frans te leren overigens. Germaanse talen zoals Nederlands, Duits en Engels lijken tenminste nog op elkaar.
[ Voor 13% gewijzigd door Lethalis op 25-10-2019 09:36 ]
Ask yourself if you are happy and then you cease to be.
Ik was altijd wel blij met de layout van Windows, dan wist je gewoon: 3 naar beneden 1 opzij is afdrukken, maakte niet uit welke taal. Best handig in sommige delen van de wereld.:
[...]
Weet je wat zoeken is?
Als je - net zoals ik - in de begintijden van XFCE de allernieuwste versie installeerde en er volgens achterkwam dat alles in het Frans was
Ouvrir le fichier!
Less alienation, more cooperation.
Zweeds was helemaal mooi geweest, kuehlevleuhstueve......
Je voelt je wel "in control" dan, wat is eject?
Less alienation, more cooperation.
Ooit op een Russische Windows XP iets in het configuratiescherm moeten aanpassen (was nog in de RealVNC-tijd, voor TeamViewer). Enige optie was om m'n eigen configuratiescherm er naast te houden en te navigeren op icoontjes en positie van velden...:
[...]
Weet je wat zoeken is?
Als je - net zoals ik - in de begintijden van XFCE de allernieuwste versie installeerde en er volgens achterkwam dat alles in het Frans was
Ouvrir le fichier!
Het is mij nooit gelukt om goed Frans te leren overigens. Germaanse talen zoals Nederlands, Duits en Engels lijken tenminste nog op elkaar.
Het is dat wij in het Nederlands voor veel computer dingen gewoon de Engelse benaming hebben overgekomen, maar anders hadden wij hier hetzelfde gehad als in het Duits. Je kunt de Duitse variant bijna letterlijk vertalen hoe het in het Nederlands geweest zou zijn. Ik heb dan ook vaak mijn OS in het Engels, omdat ik anders bepaalde dingen gewoon niet kan vinden:
[...]
Duitse IT termen zijn überhaupt verschrikkelijk
Programmierschnittstelle (API)
Laufzeitumgebung (runtime)
Ausführungsgeschwindigkeit (performance)
Automatische Speicherbereinigung (Garbage Collection)
Enzovoorts. Er is een moment in mijn leven geweest dat ik dacht om voor de gein eens naar Duitsland te verhuizen en te kijken hoe dat nou is. Maar toen realiseerde ik mij al snel dat ik dan ook als programmeur in Duitsland moet werken
Alleen al het idee dat het OS in het Duits zou zijn
Datei öffnen! Abbrechen! Speichern! Drucken! Beenden!
Argh.
Ik ben bij .net achter gekomen dat de foutmeldingen van het framework allemaal vertaald zijn. Dit lijkt afhankelijk te zijn van je geïnstalleerde os taal. Soms krijg je dan de meest oncijferbare meldingen:
[...]
Het is dat wij in het Nederlands voor veel computer dingen gewoon de Engelse benaming hebben overgekomen, maar anders hadden wij hier hetzelfde gehad als in het Duits. Je kunt de Duitse variant bijna letterlijk vertalen hoe het in het Nederlands geweest zou zijn. Ik heb dan ook vaak mijn OS in het Engels, omdat ik anders bepaalde dingen gewoon niet kan vinden
.
[ Voor 4% gewijzigd door P-Storm op 25-10-2019 10:56 ]
:strip_icc():strip_exif()/u/137799/pp.jpg?f=community)
Zo kreeg ik ooit ergens een melding over boomstronkgegevens. Bleek log data te zijn.:
[...]
Ik ben bij .net achter gekomen dat de foutmeldingen van het framework allemaal vertaald zijn. Dit lijkt afhankelijk te zijn van je geïnstalleerde os taal. Soms krijg je dan de meest oncijferbare meldingen
Mother north, how can they sleep while their beds are burning?
:strip_icc():strip_exif()/u/69431/crop5d6d1438b1ba6_cropped.jpeg?f=community)
Ah ja herkenbaar en super irritant. Daarom nu altijd een Engels Windows voor mij op dev machines. En mocht je er dan toch tegenaan lopen; http://unlocalize.com/ ;-):
[...]
Ik ben bij .net achter gekomen dat de foutmeldingen van het framework allemaal vertaald zijn. Dit lijkt afhankelijk te zijn van je geïnstalleerde os taal. Soms krijg je dan de meest oncijferbare meldingen
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Toch is het niet helemaal fit als er koelvloeistof verdwijnt
Zou er toch even naar laten kijken dan. Bij de garage kunnen ze een druktest doen om te kijken of er ergens een lekkage zit. Met een beetje mazzel ben je dan met een nieuwe slangetje of pakking klaar en het voorkomt dat de motor op een dag oververhit raakt als je een keer te laat bent met bijvullen.
Als het iets ergers is (lekke koppakking, scheurtje in cilinderkop, etc) dan kun je het maar beter op tijd weten en de auto inruilen voor iets anders, voordat het erger wordt.
Ask yourself if you are happy and then you cease to be.
Prachtig toch ...:
[...]
Duitse IT termen zijn überhaupt verschrikkelijk
Programmierschnittstelle (API)
Laufzeitumgebung (runtime)
Ausführungsgeschwindigkeit (performance)
Automatische Speicherbereinigung (Garbage Collection)
In het verleden wilde ik nog wel eens de koffiezetautomaat op het werk naar Duits zetten, de "verdammt noch mal"'s van mijn collega's waren dan niet van de lucht
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Overigens verzint een beetje architect z'n eigen lekke, onmogelijk te maken details, tot zover standaardisatie. En passingsproblemen (vergelijk die inconsistentie API's waar je tegen aan mag proggen) zijn ook aan de orde van de dag. Lang leve de kit, pur en de boorhamer.
In de bouw heb je dus ook die "architecten" clubjes die nooit een schroef ergens in gedraaid hebben.
Het voornaamste is dat uiteindelijk de aannemer verantwoordelijk is voor alle prut en vervolgens in de werkvoorbereiding alles nog tig keer keer doorgenomen wordt (o.a. op maakbaarheid) en eventueel weer teruggespeeld richting architect, constructeur etc.
In die zin heb je inderdaad enige scheiding tussen architect en werkelijk uitvoerende, maar daar zit dus nog een hele slag tussen bij de aannemer. Overigens geeft dat voor de verantwoordelijkheid dat architecten en constructeurs doorgaans maar weinig aansprakelijk zijn en de aannemer bijna overal voor.
Het is op zich allemaal iets beter geworden met betere ontwerp-tooling (afstemming tussen installaties bijvb), maar goed zoals te doen gebruikelijk gebruiken we de ruimte die we daarmee gewonnen hebben meestal door of het ontwerp moeilijker te maken, of alsnog te laat klaar te zijn met dingen of als we het echt niet meer weten tegen lagere kosten (of instortende gebouwen).
Nu voor nog even voor de analogie het equivalent in de IT vinden van de kit en purspuit dan wel de boorhamer
...
SOA:
[...]
Overigens verzint een beetje architect z'n eigen lekke, onmogelijk te maken details, tot zover standaardisatie. En passingsproblemen (vergelijk die inconsistentie API's waar je tegen aan mag proggen) zijn ook aan de orde van de dag. Lang leve de kit, pur en de boorhamer.
In de bouw heb je dus ook die "architecten" clubjes die nooit een schroef ergens in gedraaid hebben.
Het voornaamste is dat uiteindelijk de aannemer verantwoordelijk is voor alle prut en vervolgens in de werkvoorbereiding alles nog tig keer keer doorgenomen wordt (o.a. op maakbaarheid) en eventueel weer teruggespeeld richting architect, constructeur etc.
In die zin heb je inderdaad enige scheiding tussen architect en werkelijk uitvoerende, maar daar zit dus nog een hele slag tussen bij de aannemer. Overigens geeft dat voor de verantwoordelijkheid dat architecten en constructeurs doorgaans maar weinig aansprakelijk zijn en de aannemer bijna overal voor.
Het is op zich allemaal iets beter geworden met betere ontwerp-tooling (afstemming tussen installaties bijvb), maar goed zoals te doen gebruikelijk gebruiken we de ruimte die we daarmee gewonnen hebben meestal door of het ontwerp moeilijker te maken, of alsnog te laat klaar te zijn met dingen of als we het echt niet meer weten tegen lagere kosten (of instortende gebouwen).
Nu voor nog even voor de analogie het equivalent in de IT vinden van de kit en purspuit dan wel de boorhamer
Less alienation, more cooperation.
Ah, mein lievelings Woorden...
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Mjah .. beflapje op het toestenbord dan maar.:
[...]
SOA
Wat wel weer de vraag op gaat leveren .. wat is een beflapje in het duits
.(en zo komt de vrijdagmiddagborrel al met rasse schreden dichterbij)
[ Voor 14% gewijzigd door gekkie op 25-10-2019 13:42 ]
Ik wil zeker niet beweren dat het op de bouw allemaal snaarstrak geregeld is en er daar geen enkele discrepantie bestaat tussen wat er op papier wordt gezet en wat er in de praktijk gebeurt hoor. Maar ik denk wel dat er fundamentele verschillen zijn tussen de 'echte ingenieursdisciplines' en de IT. Dat heeft meerdere oorzaken. Zoals je zelf al aangeeft gebeurt er veel meer in de voorbereiding. Dat kan ook omdat requirements een stuk stabieler zijn dan in de IT. Daarnaast benaderen de modellen die worden gehanteerd in de bouw de praktijk wel een stuk beter dan die in de IT. Een bouwtekening voor een huis is voor zover mij bekend vrij goed gestandaardiseerd (Mijn vader maakte die dingen jarenlang en volgens mij is er weinig aan veranderd) en is een abstractie die de juiste aspecten van het te bouwen gebouw abstraheert. TOGAF modellen, UML, 4+1 en ga zo maar door doen dat in mijn ogen een stuk minder goed.:
[...]
Overigens verzint een beetje architect z'n eigen lekke, onmogelijk te maken details, tot zover standaardisatie. En passingsproblemen (vergelijk die inconsistentie API's waar je tegen aan mag proggen) zijn ook aan de orde van de dag. Lang leve de kit, pur en de boorhamer.
In de bouw heb je dus ook die "architecten" clubjes die nooit een schroef ergens in gedraaid hebben.
Het voornaamste is dat uiteindelijk de aannemer verantwoordelijk is voor alle prut en vervolgens in de werkvoorbereiding alles nog tig keer keer doorgenomen wordt (o.a. op maakbaarheid) en eventueel weer teruggespeeld richting architect, constructeur etc.
In die zin heb je inderdaad enige scheiding tussen architect en werkelijk uitvoerende, maar daar zit dus nog een hele slag tussen bij de aannemer. Overigens geeft dat voor de verantwoordelijkheid dat architecten en constructeurs doorgaans maar weinig aansprakelijk zijn en de aannemer bijna overal voor.
Het is op zich allemaal iets beter geworden met betere ontwerp-tooling (afstemming tussen installaties bijvb), maar goed zoals te doen gebruikelijk gebruiken we de ruimte die we daarmee gewonnen hebben meestal door of het ontwerp moeilijker te maken, of alsnog te laat klaar te zijn met dingen of als we het echt niet meer weten tegen lagere kosten (of instortende gebouwen).
Nu voor nog even voor de analogie het equivalent in de IT vinden van de kit en purspuit dan wel de boorhamer
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
/u/175723/crop5dbbf867e8d37_cropped.png?f=community)
:strip_exif()/u/19853/Goku1.gif?f=community)
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Vrij bekende grote organisatie, dus dat zeg ik liever niet.
Ik heb het overigens al veel vaker gezien in grote organisaties al is het hier wel heel erg. Bij mijn sollicitatie bij mijn werkgever destijds werd me ook expliciet iets gevraagd over hoe ik discussies met architecten voerde door één van mijn huidige teamgenoten. Die vraag kon ik toen niet zo goed plaatsen, inmiddels wel.
Er zijn ook altijd wel de nodige lichtpuntjes in dat soort organisaties hoor. Mensen die wel weten waar ze over praten, bereid zijn om mee te denken en flexibel te zijn en ga zo maar door. Sowieso is voor je dagelijkse werkplezier je eigen team het belangrijkst en dat is echt een topteam.
[ Voor 15% gewijzigd door Mugwump op 25-10-2019 16:04 ]
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Mjah ben ik deels wel met je eens, aan de andere kant zijn functionele aspecten meestal een zweef verhaal van de architect waar ook de honden weinig brood van lusten. Maar ook op het technische vlak is de bouw dan wel de zwakste van de ingenieursdisciplines. Het nadenken over toleranties en passing, rekening houden in het ontwerp met de uitvoering etc. zijn maar beperkt en dat is waar het knelt (of juist kiert
).En dat voor een discipline die al eeuwen bestaat (al geldt dat misschien voor de ICT op kleitabletten ook wel afhankelijk van je definitie van Informate Communicatie en Technologie
)En een andere overeenkomst is dat de overheid een dankbare opdrachtgever is voor de grote jongens.
Zie die OMA muts met de tweedekamer verbouwing, herverbouwing van VROM in wat het nu is, maar waarbij er nu een berg gebruiksrestricties bij is gekomen.
Dus ik denk dat er wat meer fundamentele aspecten van menselijke samenwerking, communicatie en belangen aan ten grondslag liggen die zich in alle ontwerp disciplines wel uiten bij wat grotere projecten.
[ Voor 12% gewijzigd door gekkie op 25-10-2019 17:35 ]
Ik had vanmiddag ook weer iets moois. Op mijn Xubuntu machine stopte bij Spotify ineens, met een harde tik, het geluid.
Ik verdacht eerst een vastgelopen (kernel)driver van de geluidskaart. Echter andere programma's hadden wel gewoon geluid
Toen Spotify vanuit de console gestart met debug logging aan. Ook dat gaf geen duidelijk probleem aan. Toen m'n geluidsinstellingen gecontroleerd, maar alles stond vol open. Dus ook dat was het niet.
Toen de cache van Spotify, maar ook dat hielp niets. Toen heel Spotify gepurged en opnieuw geïnstalleerd. Nog steeds geen geluid
Ten einde raad het euvel nogmaals in Spotify gezocht. Bleek dat de Spotify zelf gemute stond
Hoe het komt of kan, weet ik niet. Voor zover ik heb kunnen vinden, bestaat er geen sneltoets voor. Of ik heb een easter egg gevonden
Ik verdacht eerst een vastgelopen (kernel)driver van de geluidskaart. Echter andere programma's hadden wel gewoon geluid
Toen Spotify vanuit de console gestart met debug logging aan. Ook dat gaf geen duidelijk probleem aan. Toen m'n geluidsinstellingen gecontroleerd, maar alles stond vol open. Dus ook dat was het niet.
Toen de cache van Spotify, maar ook dat hielp niets. Toen heel Spotify gepurged en opnieuw geïnstalleerd. Nog steeds geen geluid
Ten einde raad het euvel nogmaals in Spotify gezocht. Bleek dat de Spotify zelf gemute stond
Hoe het komt of kan, weet ik niet. Voor zover ik heb kunnen vinden, bestaat er geen sneltoets voor. Of ik heb een easter egg gevonden
If money talks then I'm a mime
If time is money then I'm out of time
Dit is een van de redenen waarom ik grote organisaties liever vermijd. Ik werk nu bij een redelijk klein bedrijf (<20 man) met multinationals en overheden als klant, waarbij het meer om de persoon gaat. Ik zou dat echt niet snel inruilen voor werken bij een grote organisatie, want dan ben je een van vele, wordt je in een hokje geschoven, en pas jij je maar aan naar de organisatie. Ik zou dan niet met plezier naar mijn werk gaan.:
[...]
Vrij bekende grote organisatie, dus dat zeg ik liever niet.
Ik heb het overigens al veel vaker gezien in grote organisaties al is het hier wel heel erg. Bij mijn sollicitatie bij mijn werkgever destijds werd me ook expliciet iets gevraagd over hoe ik discussies met architecten voerde door één van mijn huidige teamgenoten. Die vraag kon ik toen niet zo goed plaatsen, inmiddels wel.
Er zijn ook altijd wel de nodige lichtpuntjes in dat soort organisaties hoor. Mensen die wel weten waar ze over praten, bereid zijn om mee te denken en flexibel te zijn en ga zo maar door. Sowieso is voor je dagelijkse werkplezier je eigen team het belangrijkst en dat is echt een topteam.
Volgens mij luistert hij gewoon naar mediatoetsen, dus als je op je toetsenbord een combinatie hebt voor (en die per ongeluk aan hebt geraakt) dan mute hij wel.:
[...]Voor zover ik heb kunnen vinden, bestaat er geen sneltoets voor. Of ik heb een easter egg gevonden
Wat luisterde je? Misschien wilden ze je tegen jezelf beschermen.:
Ik had vanmiddag ook weer iets moois. Op mijn Xubuntu machine stopte bij Spotify ineens, met een harde tik, het geluid.
Ik verdacht eerst een vastgelopen (kernel)driver van de geluidskaart. Echter andere programma's hadden wel gewoon geluid
Toen Spotify vanuit de console gestart met debug logging aan. Ook dat gaf geen duidelijk probleem aan. Toen m'n geluidsinstellingen gecontroleerd, maar alles stond vol open. Dus ook dat was het niet.
Toen de cache van Spotify, maar ook dat hielp niets. Toen heel Spotify gepurged en opnieuw geïnstalleerd. Nog steeds geen geluid
Ten einde raad het euvel nogmaals in Spotify gezocht. Bleek dat de Spotify zelf gemute stond
Hoe het komt of kan, weet ik niet. Voor zover ik heb kunnen vinden, bestaat er geen sneltoets voor. Of ik heb een easter egg gevonden
Less alienation, more cooperation.
Ik draai 18.04. Op het systeem werkt het wel, maar wordt niet doorgegeven aan Spotify. Waarom weet ik niet, maar via dbus wel.:
Vertel dat aan mijn ubuntu 16.04 installatie
Google is eng:
Identificeert John Williams als artiest/musicus en laat me Spotify starten met zijn muziek
[ Voor 31% gewijzigd door Matis op 25-10-2019 19:02 ]
If money talks then I'm a mime
If time is money then I'm out of time
Maar ben ik schuldig of onschuldig?:
Case closed......
If money talks then I'm a mime
If time is money then I'm out of time
Schakel voor de gein de netwerkverbinding eens uit tijdens het afspelen, kijken of hij dan ook een tik geeft en vervolgens het geluid uitzet
Ask yourself if you are happy and then you cease to be.
:strip_icc():strip_exif()/u/437778/crop684040f89be83_cropped.jpg?f=community)
Ich sehe das Problem nicht... was ist los damit?:
[...]
Duitse IT termen zijn überhaupt verschrikkelijk
Programmierschnittstelle (API)
Laufzeitumgebung (runtime)
Ausführungsgeschwindigkeit (performance)
Automatische Speicherbereinigung (Garbage Collection)
Enzovoorts. Er is een moment in mijn leven geweest dat ik dacht om voor de gein eens naar Duitsland te verhuizen en te kijken hoe dat nou is. Maar toen realiseerde ik mij al snel dat ik dan ook als programmeur in Duitsland moet werken
Alleen al het idee dat het OS in het Duits zou zijn
Datei öffnen! Abbrechen! Speichern! Drucken! Beenden!
Argh.
"Georg! Wir haben ein Problem mit unserer Programmierschnittstelle! Die hat soeben einen Laufzeitumgebungfehler gegeben und die Ausführungsgeschwindigkeit ist sofort gesenkt. Hat das etwas mit der automatischen Speicherbereinigung zu tun?"
Klinkt toch wunderbar (of geil zoals de Duitsers dat zouden zeggen)?
Alleen foutmeldingen van .NET vind ik vervelend in 't Nederlands (of Duits), maar dat is vooral omdat de vertaling vaak nogal "interessant" gekozen is, en het zoeken op die foutmelding daardoor lastiger wordt. Maar verder gebruik ik gewoon de meeste applicaties in het Nederlands (als ze fatsoenlijk in het Nederlands beschikbaar zijn). Maar volgens mij ben ik hier de uitzondering
🠕 This side up
:strip_exif()/u/294184/20150204_SITE_GIF_VALKUIL-resized.gif?f=community)
http://unlocalize.com/:
Alleen foutmeldingen van .NET vind ik vervelend in 't Nederlands (of Duits), maar dat is vooral omdat de vertaling vaak nogal "interessant" gekozen is, en het zoeken op die foutmelding daardoor lastiger wordt. Maar verder gebruik ik gewoon de meeste applicaties in het Nederlands (als ze fatsoenlijk in het Nederlands beschikbaar zijn). Maar volgens mij ben ik hier de uitzondering
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
/u/189240/av70.png?f=community)
Voor mensen zoals jij is er een speciaal plekje in de hel
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Ik was weer even in Scala gedoken, vooral om ScalaJS te gebruiken. Ik was altijd best gecharmeerd van hun type system en het FP. Vooral hun persistent data structures werken erg fijn. Kotlin gebruik ik in het dagelijks leven en dat vind ik geweldig productief. Kotlin is alsof je een mountainbike hebt waarmee je elke berg af durft te raggen. Scala is de ultracarbon-super-shiny fiets die helemaal perfect lijkt, maar je eigenlijk de weg niet mee op durft, vanwege alle andere idioten.
Maar soms denk ik echt met Scala en FP....
Bij FP is het nogal een gedoetje om in diep geneste structuren mutaties te doen, als je immutable data structures wil gebruiken. Dan kom je in het domein van Optics terechts met Lenses en Prisms. En, dan kom je dus in een wereld waar dit soort teksten normaal worden:
Ligt het aan mij of is er iets niet juist als je zoveel terminologie nodig hebt om een basic mutatie te moeten beschrijven. Of zijn mijn hersenen te geprime'd op imperatief denken? Het lijkt in dit geval wel alsof er met man en macht geprobeerd wordt een concept in een taal te beuken.
De case voor immutability is best sterk, alleen programmeren we graag in diep geneste patronen. En die combinatie lijkt nog best lastig te zijn. Als je bijvoorbeeld kijkt naar Redux, zie je alle tutorials en voorbeeldjes werken met simpele todo-lijstjes. Maar als er meer relaties in de data komen zie je dat de oplossing is dat je dan maar je data moet normaliseren in JS. Dat levert natuurlijk weer een lekkere lading mogelijke bugs op, want nu moet je ook nog eens de integriteit van je data-structuur handmatig managen.
Zijn er mensen die serieus FP gebruiken in productie en dit op serieus complexe datastructuren gebruiken? Dus geen todo-lists
Maar soms denk ik echt met Scala en FP....
Bij FP is het nogal een gedoetje om in diep geneste structuren mutaties te doen, als je immutable data structures wil gebruiken. Dan kom je in het domein van Optics terechts met Lenses en Prisms. En, dan kom je dus in een wereld waar dit soort teksten normaal worden:
En dan profunctor:
Wat zijn bimodules dan weer?
Ligt het aan mij of is er iets niet juist als je zoveel terminologie nodig hebt om een basic mutatie te moeten beschrijven. Of zijn mijn hersenen te geprime'd op imperatief denken? Het lijkt in dit geval wel alsof er met man en macht geprobeerd wordt een concept in een taal te beuken.
De case voor immutability is best sterk, alleen programmeren we graag in diep geneste patronen. En die combinatie lijkt nog best lastig te zijn. Als je bijvoorbeeld kijkt naar Redux, zie je alle tutorials en voorbeeldjes werken met simpele todo-lijstjes. Maar als er meer relaties in de data komen zie je dat de oplossing is dat je dan maar je data moet normaliseren in JS. Dat levert natuurlijk weer een lekkere lading mogelijke bugs op, want nu moet je ook nog eens de integriteit van je data-structuur handmatig managen.
Zijn er mensen die serieus FP gebruiken in productie en dit op serieus complexe datastructuren gebruiken? Dus geen todo-lists
Engineering is like Tetris. Succes disappears and errors accumulate.
:strip_icc():strip_exif()/u/492949/crop627d0c893ea0e_cropped.jpg?f=community)
Ja, maar niet in scala. In F# heb je de with operator om properties te updaten en die kan je zo veel nesten als je wilt::
Zijn er mensen die serieus FP gebruiken in productie en dit op serieus complexe datastructuren gebruiken? Dus geen todo-lists
F#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| type Bar = { baz : int } type Foo = { bar: Bar; foo : bool } let foo = { bar = { baz = 1 } foo = true } let foo1 = { foo with bar = { foo.bar with baz = 2 } } |
/u/81985/crop566b00b43645a.png?f=community)
Heb je ooit een willekeurige Wikipedia-pagina geopend over een wiskundig begrip? Meeste zaken zijn érg beknopt en formeel opgeschreven.
Dan over de aangehaalde teksten:
Het probleem hier is dat je niet alle abstracties en generalisaties nodig hebt om te begrijpen wat een profunctor is. Als je als kind leert tellen (de natuurlijke getallen), pakken we toch ook niet eerst een boek over commutatieve/abelse monoïdes erbij? Abstracties zijn later pas nuttig om vergelijkbare concepten aan elkaar te linken.
Een nuttigere uitleg over wat een profunctor is om een concretere definitie te pakken:
Okay, dit helpt ook nog niet. Wat zijn de type-beschrijvingen?
code:
1
2
3
4
5
| class Bifunctor f where
bimap ∷ (a → c) → (b → d) → f a b → f c d
class Profunctor f where
dimap ∷ (c → a) → (b → d) → f a b → f c d |
Dit is misschien ook nog niet meteen duidelijk, maar als je weet wat een (covariante) functor en een contravariante functor zijn, dan wordt het begrip profunctor misschien duidelijker:
code:
1
2
3
4
5
| class Functor f where
map ∷ (a → b) → f a → f b
class Contravariant f where
contramap ∷ (b → a) → f a → f b |
Een profunctor is dus in feite een structuur die een functor en een contravariante functor combineert.
Maar waarom komen termen als covariantie en contravariantie om de hoek kijken? Laten we kijken naar een simpele definitie van wat een simpele lens is:
Een getter en een setter? Okay, dat is simpel...
...totdat generics om de hoek komen kijken.
C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| interface Get</*covariant*/out T> { T Get(); } interface Set</*contravariant*/in T> { void Set(T value); } class Box<T> : Get<T>, Set<T> { private T value; public T Get() => value; public void Set(T value) { this.value = value; } } class Fruit { } class Apple : Fruit { } class Jonagold : Apple { } class Program { static void Main(string[] args) { Get<Fruit> gf = new Box<Apple>(); // covariance Set<Jonagold> sa = new Box<Apple>(); // contravariance } } |
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Met lists gebruik je List.map en voor andere objecten kun je helper functies schrijven::
Ik was weer even in Scala gedoken, vooral om ScalaJS te gebruiken. Ik was altijd best gecharmeerd van hun type system en het FP. Vooral hun persistent data structures werken erg fijn. Kotlin gebruik ik in het dagelijks leven en dat vind ik geweldig productief. Kotlin is alsof je een mountainbike hebt waarmee je elke berg af durft te raggen. Scala is de ultracarbon-super-shiny fiets die helemaal perfect lijkt, maar je eigenlijk de weg niet mee op durft, vanwege alle andere idioten.
Maar soms denk ik echt met Scala en FP....
Bij FP is het nogal een gedoetje om in diep geneste structuren mutaties te doen, als je immutable data structures wil gebruiken. Dan kom je in het domein van Optics terechts met Lenses en Prisms. En, dan kom je dus in een wereld waar dit soort teksten normaal worden:
[...]
En dan profunctor:
[...]
Wat zijn bimodules dan weer?
[...]
Ligt het aan mij of is er iets niet juist als je zoveel terminologie nodig hebt om een basic mutatie te moeten beschrijven. Of zijn mijn hersenen te geprime'd op imperatief denken? Het lijkt in dit geval wel alsof er met man en macht geprobeerd wordt een concept in een taal te beuken.
De case voor immutability is best sterk, alleen programmeren we graag in diep geneste patronen. En die combinatie lijkt nog best lastig te zijn. Als je bijvoorbeeld kijkt naar Redux, zie je alle tutorials en voorbeeldjes werken met simpele todo-lijstjes. Maar als er meer relaties in de data komen zie je dat de oplossing is dat je dan maar je data moet normaliseren in JS. Dat levert natuurlijk weer een lekkere lading mogelijke bugs op, want nu moet je ook nog eens de integriteit van je data-structuur handmatig managen.
Zijn er mensen die serieus FP gebruiken in productie en dit op serieus complexe datastructuren gebruiken? Dus geen todo-lists
https://stackoverflow.com...-and-return-full-new-list
De oplossing zoals beschreven voor het maken van een generieke update functie is wel een mooie. Als het heel specifiek is hoeft het allemaal niet generiek te zijn en kan je functie wat specifieker zijn.
Aangezien JS single threaded is kun je er voor kiezen om bepaalde data mutable te maken aangezien je toch geen race conditions in de browser hebt.
Een ander idee is het afstappen van die geneste objecten, alles plat te slaan, en gewoon met tuples gaan werken. Je kan dan een voor de hierarchie een List.Distinct op je tuples doen zodat je de organisatie eruit haalt. enz.
[ Voor 4% gewijzigd door Sandor_Clegane op 27-10-2019 09:30 ]
Less alienation, more cooperation.
True, als je met async spul gaat spelen wel, en dingen die je aan de browser zelf over laat. Maar voor delen van je data kan het een goede afweging zijn als je niet met die update functies wilt klooien.
Ik zou gewoon die update functies bouwen, ben je van een hoop geneuzel af.
Less alienation, more cooperation.
Mwoah een bibliotheek doet het wat te kort.
Het is meer een manier om F# naar de browser te krijgen. Je programmeert dus ook geen JS maar gewoon F# wat transpileert naar JS.Er is dus ook een "gezegende" manier om Fable applicaties te bouwen door middel van het van Elm afgekeken Model View Update idee. In de basis is het een Fold die bij elke update je applicatie van de vorige naar de nieuwe "state" fold. Door middel van messages worden acties in je applicatie verwerkt en deze vloeien door de Fold loop. Ik vind het wel elegant om eerlijk te zijn.
Ieder zijn ding.
Less alienation, more cooperation.
:
[...]
Ieder zijn ding.
Ik ben er verder ook niet bekend mee, een andere taal compileren kan ik soort van nog begrijpen, in essentie niet anders dan esnext of jsx. Mijn voorkeur zou zijn om iets meer op de standards track te blijven (vandaar dat ik esnext gebruik en geen Typescript, wat ik als de technisch betere acht). Kan wat jij zegt niet via webassembly, of gebruikt het dat wellicht?
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Blazor gebruikt webassembly, Fable gebruikt Babel op de backend. In het kort pakken ze de AST van de F# compiler en deze gooien ze door Babel heen met wat trucjes. Dat is veels te kort, maar wel waar het op neer komt.:
[...]
Ik ben er verder ook niet bekend mee, een andere taal compileren kan ik soort van nog begrijpen, in essentie niet anders dan esnext of jsx. Mijn voorkeur zou zijn om iets meer op de standards track te blijven (vandaar dat ik esnext gebruik en geen Typescript, wat ik als de technisch betere acht). Kan wat jij zegt niet via webassembly, of gebruikt het dat wellicht?
Doordat het Babel gebruikt is het allemaal hele nette javascript, wat in principe best goed te begrijpen is. Er zitten wel wat extra's in zodat je structural equality krijgt wat standaard JS niet heeft maar F# wel. Dit geeft ook weer overhead, maar dit kan je dan weer afvangen door POJOs (Plain Old Javascript Ojects ) te gebruiken.
Nou ja, zoals boven geschetst met geneste objecten is het soms best lastig om deze te updaten. Je hebt wat extra code nodig. Voordeel is wel dat je er gewoon vanuit kunt gaan dat waar je het object ook aanroept hij altijd consistent is.
Less alienation, more cooperation.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Voor mezelf: Ik heb in principe niet zoveel tegen Javascript, ik vind het alleen niet zo'n fijne taal om in te werken. Als ik Fable gebruik kan ik mijn domein modelleren met types zoals ik dat wil en deze kan ik daarna een op een in de browser gebruiken. Ik hoef me dan ook geen zorgen te maken over serialisation en dergelijke omdat de types aan beide kanten hetzelfde zijn. Dat is best fijn.
De compiler van F# is gewoon redelijk bulletproof, als het compileert heb je grote kans dat het gewoon werkt. Dat mis ik in JS.
Het is een reverse Node.JS. Waarom JS op de server als ik F# in de browser kan hebben alsook op de server.
Ik snap dat het lapmiddelen zijn, en ja je kan het punt maken waarom niet doorzetten en gewoon JS gebruiken? Tja, misschien komt dat er ooit van. Alleen lijkt het dat vanilla JS ook niet meer gedaan wordt, het lijkt allemaal weer frameworkje du jour.
Het zijn niet hele sterke argumenten maar voor mij genoeg om eerst zo nog even door te gaan.
Less alienation, more cooperation.
Dat stond er al bij
"ik haat zo ongeveer alles dat geen static type checking heeft"
Ik moet er persoonlijk niet aan denken om JS op de backend te gebruiken:
[...]
Waarom JS op de server als ik F# in de browser kan hebben alsook op de server.
Man, ik vind alles best... Java, Kotlin, C#, Golang... al moet ik het met veel pijn en moeite met C++ doen. Maar hell no dat ik JavaScript zou gebruiken ervoor.
Ik denk persoonlijk dat de hele frontend wereld binnen 5 jaar compleet op zijn kop staat als WebAssembly in die time frame goede DOM access krijgt.:
[...]
Alleen lijkt het dat vanilla JS ook niet meer gedaan wordt, het lijkt allemaal weer frameworkje du jour.
Het zijn niet hele sterke argumenten maar voor mij genoeg om eerst zo nog even door te gaan.
Bovendien vond ik de demo van QT met WASM / WebGL ook wel bizar om te zien.
Misschien is het hele concept van het internet wel aan het veranderen, van websites naar echte applicaties en dat de browser alleen maar een universele host ervoor is.
Oftewel: over 5 jaar maak jij misschien wel webapplicaties net zoals dat je nu een WPF of een Android app maakt. Alleen dan dat het overal werkt. En gewoon in de taal die jij fijn vindt. Of dat nou F# of Kotlin is maakt niet uit.
En JavaScript is dan weer waar het hoort... bij de script kiddies.
[ Voor 68% gewijzigd door Lethalis op 28-10-2019 09:09 ]
Ask yourself if you are happy and then you cease to be.
Dat het static type checking mist, vind ik wel een argument.
Ik werk al sinds 2003 met tegenzin met JavaScript en als er 1 ding waar ik mij mateloos aan erger, dan is het dat. Te vaak in mijn leven meegemaakt dat code het niet doet, omdat er ergens toevallig een hoofdletter een kleine letter is, of simpelweg een tikfoutje in staat. Of omdat je een Peer geeft aan iets wat een Appel wil.
Van die dingen die de compiler bij een static taal simpelweg voor jou afvangt.
TypeScript lost dit voor een deel op, maar heeft geen grip op de runtime environment die nog steeds JavaScript is. Het wekt de illusie dat je met een serieuze taal aan het werk bent, waarin je ook code kan schrijven die prima compileert, maar vervolgens alsnog niet werkt in de browser met JavaScript.
Omdat het qua syntax dingen toelaat die logisch lijken, maar het voor JavaScript niet zijn.
Wat dat betreft ben ik het zelfs met jou eens dat ik geen fan ben van transpilers. Ik hou daar ook niet van. Maar ik heb een nog grotere hekel aan JavaScript (en zo ongeveer alles dat dynamisch is).
Toen in C# dynamic werd ingevoerd, heb ik mij echt een tijdje verdrietig gevoeld. En voor ik het wist, gingen frameworks als NancyFX ermee aan de slag... en ik vind het helemaal kut.
Ik wil gewoon een formeel contract. Het moet absoluut vast staan wat er in gaat en wat er uit gaat. Klaar.
Bij alles wat ik maak.
Maar ja... daar werken dynamische talen als JavaScript niet echt aan mee.
Tuurlijk, leuk voor even snel een prototype in elkaar flansen... maar voor de rest is het in grotere projecten gewoon helemaal zielig en stompzinnig dat we hier in 2019 nog mee moeten dealen.
Ik vind frontend development op dit moment ook in een verschrikkelijke staat verkeren.
En dat heeft niks met gebrek aan ervaring te maken. Ik ga zometeen rustig verder met mijn Angular 8 project en TypeScript. Ik werk er gewoon mee - omdat ik er anno nu niet omheen kan - maar dat betekent niet dat ik het ook mooi vind of ideaal in welke vorm dan ook.
Het zal wel de Duitser in mij zijn... Ordnung muß sein!
Als het in een erbarmelijke staat verkeert, zijn er we nog lang niet.
Daarin verschillen wij dus van perceptie.
Pas als browsers ons een degelijke runtime environment bieden, gaat het ergens op lijken en kun je daar iets op bouwen.
Op dit moment bouwen we flatgebouwen op drijfzand (het lijkt Nederland wel
even wat diepe palen in die veengrond stampen en dan komt het wel goed dat je vervolgens een halve meter naar beneden dondert als je de voordeur uitstapt, praktisch onder jouw huis door kan kijken en wateroverlast krijgt, mja... hoort erbij... het is niet "perfect uitgekristralliseerd" ).
[ Voor 13% gewijzigd door Lethalis op 28-10-2019 10:11 ]
Ask yourself if you are happy and then you cease to be.
Tja, maar als je de boel gaat vergelijken met de 2003 versie van JS weet je of niet wat de status nu is (wat ik denk dat je heel goed weet) of je vergelijking gaat mank. In 2003 was JS kut met compatibility issues en weet ik wat. Dat is nu wel ff iets anders.
Dit is meer een case tegen dynamische talen, niet specifiek tegen JS. Nu ben ik ook voor static type checking maar het maakt de taal niet minder serieus als het, het niet heeft. Dat is een ontwerp keuze in de taal, een waar jij het niet mee eens bent, en ik wellicht ook niet, maar niet iets waardoor de taal gelijk "kut" is.
Kun je dit specificeren? Veelal is dit ook gewoon onbegrip over hoe de taal werkt en wat het kan. Dat jij het dan niet begrijpt betekent niet per se dat het onlogisch is.
Ik heb niet gezegd dat ik geen fan ben van transpilers. Ik heb gezegd at ik geen fan ben van libraries, of in exacte woorden: "Ik heb sowieso niet heel veel met libraries die de hele taal proberen te hervormen".
Hiermee doel ik meer op libraries als jQuery die zo'n intrusive abstractie toepassen dat er niets meer van de taal overblijft om vervolgens een klein leger aan developers achter te laten die niet meer weten hoe het zonder moet en dus ook geen regel nodejs (wat dezelfde taal is) geschreven krijgen.
Nu overdrijf je een beetje, static typing is nuttig maar je kunt prima, ook complexere projecten doen zonder.
offtopic:
Don't get met started on 2-way data binding!!!!1
Don't get met started on 2-way data binding!!!!1
Dat mag, ik ben het niet met je eens al zie ik wel dat het een hele andere manier van programeren/denken is en dat het vakgebied an sich minder ver ontwikkeld is zie ik ook wel. Mijn punt is dat je afkeer voor X (dynamische talen) projecteert op Y (JS), dat slaat nergens op.
Tja, iks nap dan weer niet zo goed wat dat met landsgrenzen te maken heeft maar goed.
Oh, the drama! Serieus"erbarmelijk" "drijfzand", het is toch allemaal wat.Als het in een erbarmelijke staat verkeert, zijn er we nog lang niet.
Daarin verschillen wij dus van perceptie.
Pas als browsers ons een degelijke runtime environment bieden, gaat het ergens op lijken en kun je daar iets op bouwen.
Op dit moment bouwen we flatgebouwen op drijfzand (het lijkt Nederland wel
Definieer dan eerste eens even een "degelijke runtime environment" en wat je er exact van verwacht en hoe je dat voor je ziet. Ik kan zo verbeteringen bedenken maar erbarmelijk is nogal een overstatement.
Veel kwaliteit van implementaties/projecten is enigszins te beschrijven als "erbarmelijk" maar dat heeft meer met de developers te maken die met de beste bedoelingen iets matigs neerzetten. Er is geen drag'n drop dus je zult wat moeten kunnen, en dat bootstrap templateje met wat jQuery gaat absoluut geen kwaliteit opleveren nee.
Frontend'en is dan ook een IMO een vak apart, en sure, daar is verbetering mogelijk. Maar niet alleen aan de kant van het vakgebied/tools/environment...
[ Voor 15% gewijzigd door Ed Vertijsment op 28-10-2019 10:51 ]
Ik kijk niet naar de 2003 versie, maar geef alleen even aan dat ik het sindsdien gebruik. Natuurlijk is ES6 mooier dan wat we hadden in 2003.
Dat geef ik ook aan in mijn reacties! Misschien ben ik dan een programmeertaalracist, maar ik hou nou eenmaal niet van dynamische talen en JavaScript er daar helaas eentje van waar ik verplicht mee moet dealen.
Ik begrijp bijvoorbeeld op zich prima hoe closures werken en waarom het ervoor kan zorgen dat iets niet werkt in JavaScript, maar als het dan vervolgens wel in TypeScript compileert dan verwacht je eigenlijk wel een foutmelding als er geen "this" meer is.
Maar ook dit is een symptoom van de taal.
Omdat je in JavaScript alles kunt herdefiniëren, kun je dus ook de meest gekke dingen doen.
Om deze reden ben ik ook geen fan van extension methods in C#, of macro's in C/C++. Je verandert de syntax en schrijft daarmee elke keer jouw eigen dialect.
Een paar posts terug werd Scala nog aangehaald, wat heer en meester probeerde te zijn op het gebied van DSL's. Met als gevolg dat niemand nou echt weet wat typische Scala code is. Scala is alles en iedereen en niemand snapt het nog. De scope is te breed. Zelfs de ontwerpers ervan geven dit toe.
Daarom is Kotlin ook veel populairder. Het is simpeler, maar kan toch meer dan Java. Het heeft een mooie balans.
Daarin verschillen wij dus van mening
Zodra je namelijk wil gaan refactoren wordt het een hel zonder static type checking.
En natuurlijk kun je dan in cirkeltjes gaan redeneren dat je in een dynamische taal minder hoeft te refactoren, maar als die dag komt dan heb je het niet naar je zin.
Ik merk gewoon dat ik veel meer dan mijn collega's (en ook veel mensen hier op dit forum) van de regeltjes ben en alles graag precies heb. Ik heb een liefde voor structuur en duidelijkheid.
Tijdens het programmeren dus ook. Zodra een functie op meerdere types kan werken, vind ik dat bijna alsof die functie vreemd kan gaan. Speciaal voor @Sandor_Clegane : ik heb hier dus ook moeite mee bij functionele programmeertalen die een vergaande type inference hebben.
Als de programmeertaal namelijk op basis van jouw gebruik al kan bepalen op welke types de functie mogelijkerwijs van toepassing is, dan levert dit nogal een cognitieve overhead op. Zodra ik dus F# doe, dan ben ik geneigd een functioneel anti pattern toe te passen, en dat is type hints toe te voegen zodat de scope van mijn functie beperkter wordt.
Dat maakt hem minder breed inzetbaar, maar de intentie is tenminste duidelijk.
Maar goed, ik heb dus ook een collega die JavaScript hartstikke leuk vindt. Die het juist tof vindt dat alles helemaal dynamisch en flexibel is.
To each their own I guess. Het is gewoon jammer dat ik verplicht JavaScript moest gebruiken al die jaren. Dan krijg je er ook een hekel aan.
Stel ik had al die tijd al iets anders kunnen gebruiken en JavaScript was gewoon 1 van de opties, mja... whatever floats your boat. Maar in de browserland was (en is) er heel lang niks anders.
Als je web development doet, moet je wel.
En je moet web development doen, omdat het weer andere voordelen heeft qua reikwijdte van de software. Je kunt tenminste iets bouwen dat het overal doet, of dat nou een PC, tablet, telefoon of een Chromebook is. Mensen kunnen jouw webapplicatie gebruiken.
Om die reden moet het wel, want je wil niet voor al die dingen een aparte client app gaan bouwen. Zonde van de tijd en energie.
Ask yourself if you are happy and then you cease to be.
Okay, ik hap::
[...]
Als er iets is waardoor je geen clue meer hebt van wat waar wanneer vandaan gekomen is zijn het die vreselijke "JS MVC" frameworks die alles alle kanten opsturen, (leuk dat je type checking werkt maar waar is deze value vandaan komen?). Om vervolgen bij complexere meuk in allerlei issues te lopen. Prefereer ik toch de voorspelbaarheid van het React ecosysteem hoe brak ik ook de hype train van React vind, (die ontwikkelaars weten volgens mij gewoon niet wat ze willen, om je wel schuldig te laten voelen als je niet de laatste versie van hoe het volgens hun hoort).
[ Voor 5% gewijzigd door Ed Vertijsment op 28-10-2019 11:24 ]
En de grap is in deze: ik ben het met jou eens. Two way data binding heb ik altijd al moeite mee gehad. Zelfs bij Windows Forms development zou ik liever nog met een model view presenter pattern (MVP) werken (al word ik dan afgeschoten op mijn werk, omdat het "meer werk" is dan gewoon aan een DataSet binden
). Totdat we dan een paar maanden later weer 1 of andere obscure bug moeten oplossen door simpelweg een DataSourceUpdateMode van een binding aan te passen Je wil directe controle over wanneer een model wordt bijgewerkt en waarom.
En nu ga ik weer aan het werk! Anders word ik om andere redenen afgeschoten
Ask yourself if you are happy and then you cease to be.
Model View Update is vele malen simpeler.:
[...]
En de grap is in deze: ik ben het met jou eens. Two way data binding heb ik altijd al moeite mee gehad. Zelfs bij Windows Forms development zou ik liever nog met een model view presenter pattern (MVP) werken (al word ik dan afgeschoten op mijn werk, omdat het "meer werk" is dan gewoon aan een DataSet binden
Je wil directe controle over wanneer een model wordt bijgewerkt en waarom.
En nu ga ik weer aan het werk! Anders word ik om andere redenen afgeschoten
En speciaal voor jou: als jij blij wordt van type hints dan doe je dat toch gewoon? Je kan ook een signature file bouwen: https://docs.microsoft.co...reference/signature-files
Potverdikkie, ain't life grand? You do you
Less alienation, more cooperation.
/u/224026/crop5a1c1a6fcf1b1.png?f=community)
Gelukkig is me de komst van Strict Types en dito checks wel een stuk verbeterd. We hadden laatst ook weer een pareltje van een bug doordat
PHP:
true oplevert. Wat er eigenlijk bedoeld werd was strlen 1
| empty("000") |
If money talks then I'm a mime
If time is money then I'm out of time
:strip_exif()/u/259931/stuiterbal2.gif?f=community)
dat is niet waar. Het is prima gedefineerd welke cases true of false zijn voor empty(). Vaak is het gebruik van empty() wel een beetje een code-smell omdat het eigenlijk alleen praktisch nut heeft als je geen flauw idee hebt watvoor type je variable heeft. Maar er zijn wel legit use-cases te bedenken.:
[...]
Gelukkig is me de komst van Strict Types en dito checks wel een stuk verbeterd. We hadden laatst ook weer een pareltje van een bug doordatPHP:true oplevert. Wat er eigenlijk bedoeld werd was strlen
:strip_exif()/u/627282/charmander-kerst.gif?f=community)
Valt er iets te vieren?
Without nipples, boobs are pointless - 365 project - In mijn hoofd is het alle dagen Kerstmis - What type of bees make milk? Boobies! - What type of bees are scary? BoooOOOOOooobeees! - Cactusliefhebster
Doe mij maar appeltaart:
[...]
Van programmeertalen word ik sowieso niet vrolijk. Van taart wel
Daar word ik vrolijker van
[ Voor 6% gewijzigd door Lethalis op 28-10-2019 16:56 ]
Ask yourself if you are happy and then you cease to be.
Je hebt gelijk. Ik heb het even teruggezocht en er zat inderdaad nog een cast naar int tussen ergens in de code.
Dikke
voor mijzelf:Ik dook vanochtend even in de logging van een stukje software van ons. Ik schrok me wezenloos, alle crons draaiden een uur te vroeg...
Alles nagelopen, tijd op de scheduler gecontroleerd, testjes gedraaid etc etc, maar ik kon het lek niet vinden. Totdat ik me realiseerde dat niet de server een uur opgeschoven was tov van UTC, maar wij
Stom, hoe automatisch je zelf al 2 uur optelt bij de timestamps in de logging, zonder dat je het in de gaten hebt. CEST is a bitch
If money talks then I'm a mime
If time is money then I'm out of time
Dit topic is gesloten.