De Devschuur Coffee Corner - Iteratie ⓬

[bwerg]

.oisyn schreef op woensdag 24 oktober 2018 @ 10:42:
Op zich kun je best ver komen zonder de onderliggende wiskunde te begrijpen. De onderliggende vector en matrixoperaties zijn wel over te typen, daarna is het simpelweg het conceptueel toepassen van transformaties.

In lineaire algebra is een matrix inderdaad gewoon een transformatie/functie. Een matrix met een vector vermenigvuldigen is gewoon het toepassen van die functie op de matrix. Twee matrices vermenigvuldigen met elkaar is functiecompositie (één functie maken die beide functies na elkaar toepast). Een 3D-library heeft toch altijd wel wat functies om matrices voor je te genereren aan de hand van de transformaties die ze voorstellen (matrix turn(float degrees) o.i.d.).

Ik heb mijn dosis lineaire algebra op papier wel gehad hoor, maar toen ik met 3D-spul zat te pielen was bovenstaande vertaling naar begrijpelijke concepten het grootste deel van wat ik nodig had.

gekkie schreef op woensdag 24 oktober 2018 @ 10:34:
Wel interessant dat eigenlijk elke min of meer dynamische taal nu wel (de mogelijkheid) tot statische typing krijgt.

Wie vindt de eerste statisch getypeerde taal die de mogelijkheid tot dynamische typering krijgt?

[.oisyn]

bwerg schreef op woensdag 24 oktober 2018 @ 16:36:
Een 3D-library heeft toch altijd wel wat functies om matrices voor je te genereren aan de hand van de transformaties die ze voorstellen (matrix turn(float degrees) o.i.d.).

De tutorial gaat juist uit van 0 3rd party libraries

Wie vindt de eerste statisch getypeerde taal die de mogelijkheid tot dynamische typering krijgt?

Die bestaat allang, C#

[ Voor 17% gewijzigd door .oisyn op 24-10-2018 16:38 ]

[Lethalis]

.oisyn schreef op woensdag 24 oktober 2018 @ 16:37:
[...]
Die bestaat allang, C#

En ik vind het nog steeds 1 van de meest enge ontwikkelingen in C#.

dynamic

[ThomasG]

.oisyn schreef op woensdag 24 oktober 2018 @ 16:37:
[...]

Die bestaat allang, C#

Dat kan ook in C, met void pointers

[.oisyn]

Lethalis schreef op woensdag 24 oktober 2018 @ 16:45:
dynamic

Het is anders een prima concept om makkelijk te interfacen met dynamisch getypeerde talen.

ThomasG schreef op woensdag 24 oktober 2018 @ 16:46:
[...]
Dat kan ook in C, met void pointers

Nee, void pointers zijn nog steeds statisch getypeerd.

[ Voor 33% gewijzigd door .oisyn op 24-10-2018 16:47 ]

[Lethalis]

.oisyn schreef op woensdag 24 oktober 2018 @ 16:46:
[...]
Het is anders een prima concept om makkelijk te interfacen met dynamisch getypeerde talen.

Als je met iets anders wilt interfacen definieer je daar maar goed omschreven classes en interfaces voor.

Dat is inderdaad meer werk, maar voorkomt allerlei nasty runtime bugs.

[.oisyn]

Lethalis schreef op woensdag 24 oktober 2018 @ 16:52:
[...]

Als je met iets anders wilt interfacen definieer je daar maar goed omschreven classes en interfaces voor.

Dat is inderdaad meer werk, maar voorkomt allerlei nasty runtime bugs.

Nonsens, de taal waarmee je interfacet is dynamisch. Het is dus onmogelijk om dat statisch af te vangen. De gebruiker moet dus volgens jou meer werk gaan doen voor iets wat alsnog at runtime fout kan gaan.

[Lethalis]

.oisyn schreef op woensdag 24 oktober 2018 @ 16:53:
[...]
Nonsens, de taal waarmee je interfacet is dynamisch. Het is dus onmogelijk om dat statisch af te vangen. De gebruiker moet dus volgens jou meer werk gaan doen voor iets wat alsnog at runtime fout kan gaan.

Met welke dynamische talen interface jij vanuit C#?

En waarom in vredesnaam?

Ik ben benieuwd.

[.oisyn]

Lethalis schreef op woensdag 24 oktober 2018 @ 16:57:
[...]

Met welke dynamische talen interface jij vanuit C#?

Ik gebruik geen C#. Maar dat soort dynamische bindings zijn erg handig als je bindings wil creëren naar een scripttaal zoals javascript, python of lua. Bijvoorbeeld omdat je scriptmogelijkheden wil toevoegen aan je applicatie, of omdat je gebruik maakt van een browsercomponent.

[Hydra]

@Lethalis billing alerts negeer je natuurlijk niet. Daarnaast is AWS vrij makkelijk als het aankomt op het compenseren van fuckups van klanten. Ze kijken liever naar lange termijn dan op korte termijn die paar duizend euro pakken.

[Xiphalon]

Lethalis schreef op woensdag 24 oktober 2018 @ 16:04:
Voor de mensen met Amazon Web Services en / of Azure, zijn jullie nooit bang dat het een keer mis gaat?

PS
AWS of Azure introduceren op mijn werk vind ik hierdoor ook een beetje eng. Je zou maar degene zijn die het adviseert en vervolgens de werkgever onbedoeld op kosten jaagt... (al dan niet omdat een collega een keer niet oplet)

Gewoon opletten. Wij werken met limiten, het Dev account kan maar 2000/maand verstouwen daarna gaat de boel op slot. Is nog nooit voorgekomen, wel bijna toen een developer een complete ElasticSearch? stack volgens hun template in de lucht tilde voor een POC, dat waren 7 VM's oid á 100 euro/stuk/maand

Automatisch schalen moet je natuurlijk wel een bovengrens opgeven

[edit]
Vergeet ik helemaal te vertellen dat die ELK stack een dashboard was om de kosten en de logs in de gaten te houden. Werkt nu prima, ook met trendanalyse dus als iets opeens scheef loopt gaat er vrij rap een alert af.

[ Voor 12% gewijzigd door Xiphalon op 24-10-2018 17:08 ]

[Hydra]

Precies. AWS wil je daar met plezier bij helpen trouwens. Als je een serieuze gebruiker bent kun je zo ff een consultant uit Amsterdam laten overkomen.

[Alex)]

Ik heb wel eens IronPython ingezet in combinatie met C#. Het doel was om business rules (validatie en mapping) niet hardcoded in gecompileerde code te hebben, maar in een losse module die makkelijk te updaten was.

Destijds zijn er meerdere oplossingsrichtingen onderzocht, zoals business rule engines, Windows Workflow Foundation, en verschillende scripttalen (JS, Lua, IronPython). IronPython leek destijds de beste keuze omdat het makkelijk te integreren was, ontwikkeld door Microsoft zelf, en Python een populaire taal is.

Het werkte als een zonnetje.

Waar ik helemaal blij van werd is de .NET-bridge, waarmee ik aan .NET types kon vanuit m'n Python-scripts. Dat heb ik destijds gebruikt door in de python-environment een globaal .NET result-object aan te maken, dat te vullen vanuit IPy-scripts, en vervolgens in m'n .NET-code dat object weer verder te gebruiken.

[bwerg]

.oisyn schreef op woensdag 24 oktober 2018 @ 16:46:
Nee, void pointers zijn nog steeds statisch getypeerd.

Aanvulling: de mogelijkheid om void pointers te gebruiken is een teken van weak typing. Maar weak/strong typing is vaak wat minder duidelijk (gedefinieerd) dan static/dynamic.

[Mugwump]

Xiphalon schreef op woensdag 24 oktober 2018 @ 17:06:
[...]

Gewoon opletten. Wij werken met limiten, het Dev account kan maar 2000/maand verstouwen daarna gaat de boel op slot. Is nog nooit voorgekomen, wel bijna toen een developer een complete ElasticSearch? stack volgens hun template in de lucht tilde voor een POC, dat waren 7 VM's oid á 100 euro/stuk/maand

Automatisch schalen moet je natuurlijk wel een bovengrens opgeven

~~~[edit]
Vergeet ik helemaal te vertellen dat die ELK stack een dashboard was om de kosten en de logs in de gaten te houden. Werkt nu prima, ook met trendanalyse dus als iets opeens scheef loopt gaat er vrij rap een alert af.

Ik heb wel eens 5k aan kosten veroorzaakt met een klein configuratiefoutje in automatische uitrol van CosmosDB. Scheelt toch aanzienlijk in de kosten of je ze je een nulletje meer of minder capaciteit geeft.
Het was iets handiger geweest als daar wat strakkere monitoring op afwijking van de trend in had gezeten inderdaad.

Uiteindelijk was het bij een klant met te veel geld die zoiets had van "ach, kan gebeuren", maar ik zat wel even te zweten.

[RayNbow]

Lethalis schreef op woensdag 24 oktober 2018 @ 15:01:
[...]

20 jaar geleden beginnen met Visual Basic 6 is geen schande, maar als je het nu nog gebruikt is er toch ergens iets niet goed gegaan

Hoe moet ik anders oude projecten draaien?

[Lethalis]

RayNbow schreef op woensdag 24 oktober 2018 @ 17:59:
[...]

Hoe moet ik anders oude projecten draaien?

Dat bedoel ik dus. Something went horribly wrong

[Styxxy]

Mugwump schreef op woensdag 24 oktober 2018 @ 17:53:
[...]


Ik heb wel eens 5k aan kosten veroorzaakt met een klein configuratiefoutje in automatische uitrol van CosmosDB. Scheelt toch aanzienlijk in de kosten of je ze je een nulletje meer of minder capaciteit geeft.
Het was iets handiger geweest als daar wat strakkere monitoring op afwijking van de trend in had gezeten inderdaad.

Uiteindelijk was het bij een klant met te veel geld die zoiets had van "ach, kan gebeuren", maar ik zat wel even te zweten.

Kwestie van juiste governance model en approval fliws. Voor kleinere bedrijven misschien een zwaar en moeilijk proces om te beschrijven, maar kan hetwel waard zijn. Wij zijn nu bezig met deze oefening, en je kan tegenwoordig etcgt veel afdwingen en limiteren bv Azure.

[farlane]

RayNbow schreef op woensdag 24 oktober 2018 @ 17:59:
[...]
Hoe moet ik anders oude projecten draaien?

Pff, wie levert er nou nog support tegenwoordig ....

[RayNbow]

Lethalis schreef op woensdag 24 oktober 2018 @ 20:05:
[...]

Dat bedoel ik dus. Something went horribly wrong

farlane schreef op donderdag 25 oktober 2018 @ 00:12:
[...]

Pff, wie levert er nou nog support tegenwoordig ....

Wie zegt dat het om support gaat?

[Sandor_Clegane]

Nostalgia is a helluva drug!

[ThomasG]

.oisyn schreef op woensdag 24 oktober 2018 @ 16:46:
[...]

Nee, void pointers zijn nog steeds statisch getypeerd.

dynamic is ook statisch getypeerd, behalve dat het een bypass heeft op een aantal statisch checks. Het verschil tussen void * en dynamic is helemaal niet zo groot, behalve dat dynamic implicit casts toevoegd.

[.oisyn]

ThomasG schreef op donderdag 25 oktober 2018 @ 09:07:
[...]
dynamic is ook statisch getypeerd

Net als variabelen in JavaScript en PHP statisch getypeerd zijn ja. Niet dus . Het enige statische eraan is dat de compiler weet dat het dynamisch getypeerd is (en wellicht dat hij het type kan inferren uit de context, maar dat gaat alleen op voor lokale variabelen en wellicht private members).

Het verschil tussen void * en dynamic is helemaal niet zo groot, behalve dat dynamic implicit casts toevoegd.

Het verschil is enorm. Met een void* kun je niets, met dynamic kun je alles. Het enige dynamische wat je met void* kunt doen is dynamic_cast, zodat je het statische type kunt veranderen met een bijbehorende runtime check. Een void* is veel meer te vergelijken met een Object reference in C# of Java. Het is een generalisatie ervan, het kan naar álles wijzen en er zijn als zodanig dan ook geen gedeelde eigenschappen. Het is onmogelijk om at runtime het juiste type te bepalen, behalve als hij toevallig wijst naar een object met een vtable. Maar hij kan net zo goed naar een int wijzen, en er is geen manier om erachter te komen. Als je iets met een void* moet doen, zul je 'm eerst moeten casten naar iets anders. Dat is de hele essentie van statische typering.

bwerg schreef op woensdag 24 oktober 2018 @ 17:27:
[...]

Aanvulling: de mogelijkheid om void pointers te gebruiken is een teken van weak typing. Maar weak/strong typing is vaak wat minder duidelijk (gedefinieerd) dan static/dynamic.

Implicit casts zijn natuurlijk een vorm van weak typing, maar vind je dat ook van toepassing op een impliciete widening cast van bijvoorbeeld String naar Object?

[ Voor 27% gewijzigd door .oisyn op 25-10-2018 10:24 ]

[RayNbow]

.oisyn schreef op donderdag 25 oktober 2018 @ 10:08:
Het enige dynamische wat je met void* kunt doen is dynamic_cast

Dit is een verschil dat best wel belangrijk is om extra te benadrukken. Die dynamic_cast houdt dus in dat je het type moet weten. Dit in tegenstelling tot dynamic in C#, waarbij het type niet boeit, zolang je maar weet welke velden of methoden zo'n object heeft.


Edit:
Een C#-voorbeeld dat een scenario schetst waarin je het type niet eens kunt weten:

C#:

// based on: https://softwareengineering.stackexchange.com/a/93330/29561

using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.CSharp;
using System.CodeDom.Compiler;
using System.CodeDom;
using System.Reflection;

namespace Test
{
    class Program
    {
        static void Main(string[] args)
        {
            string className = "BlogPost";

            var props = new Dictionary<string, Type>() {
                { "Title", typeof(string) },
                { "Text", typeof(string) },
                { "Tags", typeof(string[]) }
            };

            var type = CreateType("Test.Dynamic", className, props);
            dynamic obj = Activator.CreateInstance(type);
            obj.Title = "Some title";
            obj.Text = "Lorem ipsum";
            obj.Tags = new string[] { "code example", "dynamic" };
            
            Console.WriteLine($"{obj.Title}: {obj.Text}");
            Console.WriteLine(String.Join(", ", obj.Tags));
        }

        static Type CreateType(string assemblyName, string typeName, IDictionary<string, Type> props)
        {
            var csc = new CSharpCodeProvider(new Dictionary<string, string>() { { "CompilerVersion", "v4.0" } });
            var parameters = new CompilerParameters(new[] { "mscorlib.dll", "System.Core.dll" }, "Test.Dynamic.dll", false)
            {
                GenerateExecutable = false
            };

            var compileUnit = new CodeCompileUnit();
            var ns = new CodeNamespace(assemblyName);
            compileUnit.Namespaces.Add(ns);
            ns.Imports.Add(new CodeNamespaceImport("System"));

            var classType = new CodeTypeDeclaration(typeName)
            {
                Attributes = MemberAttributes.Public
            };
            ns.Types.Add(classType);

            foreach (var prop in props)
            {
                var fieldName = "_" + prop.Key;
                var field = new CodeMemberField(prop.Value, fieldName);
                classType.Members.Add(field);

                var property = new CodeMemberProperty();
                property.Attributes = MemberAttributes.Public | MemberAttributes.Final;
                property.Type = new CodeTypeReference(prop.Value);
                property.Name = prop.Key;
                property.GetStatements.Add(new CodeMethodReturnStatement(new CodeFieldReferenceExpression(new CodeThisReferenceExpression(), fieldName)));
                property.SetStatements.Add(new CodeAssignStatement(new CodeFieldReferenceExpression(new CodeThisReferenceExpression(), fieldName), new CodePropertySetValueReferenceExpression()));
                classType.Members.Add(property);
            }

            var results = csc.CompileAssemblyFromDom(parameters, compileUnit);
            results.Errors.Cast<CompilerError>().ToList().ForEach(error => Console.WriteLine(error.ErrorText));

            var asm = Assembly.Load(assemblyName);
            return asm.GetType(String.Format("{0}.{1}", assemblyName, typeName));
        }
    }
}

[ Voor 77% gewijzigd door RayNbow op 25-10-2018 11:33 ]

[Lethalis]

RayNbow schreef op donderdag 25 oktober 2018 @ 11:06:
[...]
Een C#-voorbeeld dat een scenario schetst waarin je het type niet eens kunt weten:

Alsnog kun je de instantie die je on the fly hebt aangemaakt met reflection vullen (PropertyInfo.SetValue en zijn vriendjes... je hebt immers de Type informatie).

Je hebt hier dus niet per se "dynamic" voor nodig. Het is "makkelijker", maar niet nodig.

En ik blijf van mening dat "dynamic" het in de hand werkt dat mensen short cuts gaan nemen die ze beter niet kunnen nemen.

Sowieso vind ik de hele vraagstelling "apart":

https://softwareengineering.stackexchange.com/a/93330/29561

Is it possible to do the following in C# (or in any other language)?

I am fetching data from a database. At run time I can compute the number of columns and data types of the columns fetched.

Next I want to "generate" a class with these data types as fields. I also want to store all the records that I fetched in a collection.

Ja, en wat gaat hij er daarna mee doen? Als hij het vervolgens weer als JSON gaat uitpoepen ofzo, dan was de hele oefening nogal zinloos en extreem omslachtig (en verdomd traag qua performance).

Hydra schreef op woensdag 24 oktober 2018 @ 17:03:
@Lethalis billing alerts negeer je natuurlijk niet. Daarnaast is AWS vrij makkelijk als het aankomt op het compenseren van fuckups van klanten. Ze kijken liever naar lange termijn dan op korte termijn die paar duizend euro pakken.

Ja er zijn wel meer dingen die je niet zou mogen negeren (alerts dat een backup mislukt is bijvoorbeeld ).

Ik vind ook dat je hier normaal gesproken een systeembeheerder voor moet hebben wiens taak het is om dit soort dingen in de gaten te houden.

Maar bij ons is het meer dat we allemaal andere taken hebben en dat het beheer er een beetje bij wordt gedaan. En dan bestaat er altijd de kans dat dingen blijven liggen.

[ Voor 56% gewijzigd door Lethalis op 25-10-2018 12:17 ]

[bwerg]

.oisyn schreef op donderdag 25 oktober 2018 @ 10:08:
Implicit casts zijn natuurlijk een vorm van weak typing, maar vind je dat ook van toepassing op een impliciete widening cast van bijvoorbeeld String naar Object?

De meest gebruikte vorm van impliciete casts zijn upcasts, en die lijken me juist helemaal geen vorm van weak typing: upcasting is type-safe. Downcasting zou je kunnen zien als weak typing (want niet altijd type-safe), al ligt dat aan de semantiek: als je een downcast 'verkeerd doet' in C++ dan ben je gewoon je data aan het interpreteren met een verkeerd type, en dat is dus inderdaad een zwakke typering. In java-achtige talen wordt dit afgevangen met een dynamische check, waardoor je typing sterk blijft (en upcasting in java zou je dus sterk en dynamisch getypeerd kunnen noemen).

Maar goed, de betekenis van weak/strong typing is niet in beton gegoten dus de meningen kunnen verschillen.

[ Voor 6% gewijzigd door bwerg op 25-10-2018 12:21 ]

[RayNbow]

Lethalis schreef op donderdag 25 oktober 2018 @ 12:05:
Sowieso vind ik de hele vraagstelling "apart":

https://softwareengineering.stackexchange.com/a/93330/29561

Naar de vraagstelling heb ik niet gekeken, ik was op zoek naar een snelle manier om tijdens runtime een type aan te maken.

[...]

Alsnog kun je de instantie die je on the fly hebt aangemaakt met reflection vullen (PropertyInfo.SetValue en zijn vriendjes... je hebt immers de Type informatie).

In dit voorbeeld heb ik de instantie zelf aangemaakt, ja, maar wat als de instantie ergens anders vandaan komt (in de vorm van object of dynamic)?

(OK, dan kun je alsnog zelf waarschijnlijk GetType() aanroepen en verder met reflectie aan de slag kunnen...)

[.oisyn]

bwerg schreef op donderdag 25 oktober 2018 @ 12:19:
[...]

De meest gebruikte vorm van impliciete casts zijn upcasts, en die lijken me juist helemaal geen vorm van weak typing

Helemaal eens, maar waarom vind je void* dan wel weak?

Overigens weet ik niet of je eerste zin in C++ wel waar is. User defined conversions zijn best wel belangrijk.

[ Voor 17% gewijzigd door .oisyn op 25-10-2018 14:53 ]

[bwerg]

.oisyn schreef op donderdag 25 oktober 2018 @ 14:49:
[...]

Helemaal eens, maar waarom vind je void* dan wel weak?

Mijn definitie van weak typing zou het forceren van type-safety zijn. Upcasts zijn type-safe, alle andere casts niet (tenzij je ze weer dynamisch checkt): als je cast, loop je zomaar het risico dat je je bitjes ineens als verkeerd type aan het interpreteren bent. Zaken als handmatige memory management veroorzaken in dat opzicht ook weak typing: de mogelijkheid om pointers te gebruiken naar geheugen dat al gedealloceerd is, zorgt voor hetzelfde probleem.

[ Voor 3% gewijzigd door bwerg op 25-10-2018 15:00 ]

[farlane]

RayNbow schreef op donderdag 25 oktober 2018 @ 06:55:
Wie zegt dat het om support gaat?

Wel option explicit aanzetten he?! Of ben je ook zo'n dynamisch type?

[edit]
Laat maar, ik zie het al ...

[ Voor 8% gewijzigd door farlane op 25-10-2018 23:07 ]

[Super_ik]

Ik dacht meer aan ‘on error resume next’

[.oisyn]

bwerg schreef op donderdag 25 oktober 2018 @ 14:53:
[...]

Mijn definitie van weak typing zou het forceren van type-safety zijn. Upcasts zijn type-safe, alle andere casts niet (tenzij je ze weer dynamisch checkt): als je cast, loop je zomaar het risico dat je je bitjes ineens als verkeerd type aan het interpreteren bent. Zaken als handmatige memory management veroorzaken in dat opzicht ook weak typing: de mogelijkheid om pointers te gebruiken naar geheugen dat al gedealloceerd is, zorgt voor hetzelfde probleem.

Niet echt een antwoord op mijn vraag . Een cast naar void* kun je gewoon zien als een upcast. Het is daarmee niet weaker dan een upcast naar Object. Je kunt er niet heel veel mee, en het gebruik ervan is dan ook vrij beperkt in een moderne c++ codebase. Typische usecases zijn binary data (en dus untyped) en ongeïnitialeerd geheugen (voor constructie of na destructie).

[RayNbow]

farlane schreef op donderdag 25 oktober 2018 @ 22:55:
[...]



Wel option explicit aanzetten he?!

Werd die niet standaard aangezet zo rond VB4 of VB5?

Of ben je ook zo'n dynamisch type?

[edit]
Laat maar, ik zie het al ...

Het declareren van variabelen staat haaks op of iets dynamisch is. Daarnaast, VB heeft altijd al zaken als late binding en multimethods gehad, nog voordat C# met dynamic aan kwam zetten.

Super_ik schreef op donderdag 25 oktober 2018 @ 23:09:
Ik dacht meer aan ‘on error resume next’

On Error GoTo Hell

[ Voor 16% gewijzigd door RayNbow op 26-10-2018 07:04 ]

[Antrax]

option explicit, weak typing, untyped..

* Antrax voelt zich geen developer meer..

[ Voor 3% gewijzigd door Antrax op 26-10-2018 08:46 ]

[bwerg]

.oisyn schreef op donderdag 25 oktober 2018 @ 23:28:
[...]

Niet echt een antwoord op mijn vraag . Een cast naar void* kun je gewoon zien als een upcast.

Je vroeg niet naar de cast naar void*, maar enkel naar void* zelf. Aangezien een type op zichzelf niet zwak of sterk is, nam ik dus aan het gebruik van void* aan, en bij elk zinnig gebruik ga je toch ook weer een downcast nodig hebben.

Ha, jij bent weer aan zet in het mierenneuk-spel!

Is casten naar void trouwens wel een upcast? Pointers lijken me niet covariant, maar ik zit niet zo diep in C++.

[ Voor 11% gewijzigd door bwerg op 26-10-2018 09:13 ]

[Mugwump]

Inloggen via de Microsoft Teams desktop / web client werkt niet, lekker handig als je net een dagje thuiswerkt.

[.oisyn]

bwerg schreef op vrijdag 26 oktober 2018 @ 09:06:
[...]

Je vroeg niet naar de cast naar void*, maar enkel naar void* zelf. Aangezien een type op zichzelf niet zwak of sterk is, nam ik dus aan het gebruik van void* aan, en bij elk zinnig gebruik ga je toch ook weer een downcast nodig hebben.

Maar dan negeer je de rest van mijn post. Ik zeg dus dat je zo'n upcast zelden nodig hebt. Er zijn twee legitieme usecases:

1. Memory allocation. Daarmee deal je dus met void*, maar heeft geen downcast nodig omdat je de new operator gebruikt om een type eroverheen te constructen. Het resultaat van de new operator is gewoon een T*.
2. Binary data van een externe resource. Denk aan file reads/writes. Dat behandel je door het te memcpy'en naar een struct (geen downcast). Een downcast naar een POD* zie je natuurlijk ook, maar dat is feitelijk undefined behavior.

Ha, jij bent weer aan zet in het mierenneuk-spel!

Ik ga denk ik voor de kanskaart.
U wint de discussie. Ga langs start en ontvang €200.
Ha!

Is casten naar void trouwens wel een upcast? Pointers lijken me niet covariant, maar ik zit niet zo diep in C++.

Pointers in general zijn natuurlijk niet altijd covariant, zoals references in C# of Java dat ook niet zijn. Covariance komt over het algemeen terug in twee smaken, arrays en function return types. Covariant arrays heb je niet in C++, een Derived*[] is niet te converteren naar Base*[] en ook niet naar void*[], om begrijpelijke redenen. T*[] naar void*const[] zou dan typisch gezien nog wel kunnen (want read-only), al weet ik even niet of reinterpret_cast<intptr_t>(&obj) == reinterpret_cast<intptr_t>(static_cast<void*>(&obj)) altijd waar is volgens de standaard. Bij een Base* en een Derived* hoeft dat iig niet het geval te zijn.

Covariant function return types worden wel ondersteund:

C++:

struct Base { };
struct Derived : Base { };

struct A
{
    virtual Base* foo();
};

struct B : A
{
    virtual Derived* foo() override;
}

Alleen als je hier van Base* een void* zou maken, dan mag het niet. Dat is engiszins apart . Ik zou dat niet zo snel willen aanvoeren als bewijs dat T* niet covariant is met void*, maar soit.

[ElkeBxl]

* ElkeBxl komt hier eens koekeloeren hoe de boel hier nog draait. It's been a while

*zwaai*zwaai*

[Merethil]

ElkeBxl schreef op vrijdag 26 oktober 2018 @ 15:32:
* ElkeBxl komt hier eens koekeloeren hoe de boel hier nog draait. It's been a while

*zwaai*zwaai*

En je bent nog stééds klaar voor de winter!

[qless]

Hoe bevalt de nieuwe job?

On topic:
flutter eens zitten proberen. Leuk platform maar er missen nog wel wat zaken ( location services etc )

[farlane]

RayNbow schreef op vrijdag 26 oktober 2018 @ 07:03:
Werd die niet standaard aangezet zo rond VB4 of VB5?

Weet ik niet precies, maar as dat waar is heeft mijn (toenmalige) voorganger het expliciet weer uitgezet ....

Het declareren van variabelen staat haaks op of iets dynamisch is. Daarnaast, VB heeft altijd al zaken als late binding en multimethods gehad, nog voordat C# met dynamic aan kwam zetten.

Nja, dynamisch uit de lucht vallende variabelen dan....

VB was imba, en de VB6 IDE helemaal met zijn code completion .... Het was alleen jammer dat iedereen dacht ook *fatsoenlijk* BASIC te kunnen krassen ...

[Sandor_Clegane]

imba? double you tee eff.

Edit: Iemand wel eens wat met PInvoke gedaan? Ik zit eraan te denken voor mijn Raspberry Pi, maar ik sta nu niet echt te trappelen zeg maar.

Voorbeelden die ik gezien heb zien er wel ok uit, maar zal je net zien dat ik weer net wat anders zoek. Gaat voor de wiringpi bibliotheek om de GPIO's aan te sturen. Er zijn wel wrappers voor maar het leek me ook wel een uitdaging. Keuzes, keuzes

[ Voor 88% gewijzigd door Sandor_Clegane op 26-10-2018 21:36 ]

[Super_ik]

farlane schreef op vrijdag 26 oktober 2018 @ 19:55:
Weet ik niet precies, maar as dat waar is heeft mijn (toenmalige) voorganger het expliciet weer uitgezet ....

Nope, dat stond niet standaard aan.

[farlane]

Sandor_Clegane schreef op vrijdag 26 oktober 2018 @ 21:19:
Edit: Iemand wel eens wat met PInvoke gedaan? Ik zit eraan te denken voor mijn Raspberry Pi, maar ik sta nu niet echt te trappelen zeg maar.

Voorbeelden die ik gezien heb zien er wel ok uit, maar zal je net zien dat ik weer net wat anders zoek. Gaat voor de wiringpi bibliotheek om de GPIO's aan te sturen. Er zijn wel wrappers voor maar het leek me ook wel een uitdaging. Keuzes, keuzes

Man up en doe het in C ...

[Sandor_Clegane]

farlane schreef op vrijdag 26 oktober 2018 @ 23:12:
[...]

Man up en doe het in C ...

Maaruh imba?

Hahaha misschien wel, ware het niet dat ik F# gewoon leuk vind om te schrijven. Moet zeggen dat het wel steeds meer begint te kriebelen. Maar dat wordt ook weer een hoop gevogel.

En in F# is er nog zoveel meer te doen, maar wie weet.

[ElkeBxl]

Merethil schreef op vrijdag 26 oktober 2018 @ 15:47:

En je bent nog stééds klaar voor de winter!

JAAAAA Kerstmis komt eraan!!!

qless schreef op vrijdag 26 oktober 2018 @ 15:52:
Hoe bevalt de nieuwe job?

Supergoed! Zit nu bij mijn 2e klant en dat contract loopt al bijna ten einde. Het leven als consultant bevalt me wel. Superveel bijgeleerd, veel interessant volk leren kennen, ik ga met plezier terug werken, ... Geen moment spijt van gehad

[farlane]

Sandor_Clegane schreef op zaterdag 27 oktober 2018 @ 00:46:
[...]
Maaruh imba?

Te veel WoW in het verleden ben ik bang, mijn excuses.

[RayNbow]

Hmm, ik dacht laten we eens kijken of we zelf een gamepadconnected event kunnen triggeren, maar ik kan met geen mogelijkheid de event.gamepad property vullen in zo'n event.

* RayNbow gaat maar eens wat anders verzinnen om te onderzoeken.

[Sandor_Clegane]

Beetje javascript schrijven vind ik niet zo erg, maar man wat is Fable tof.

Webpack ook trouwens.

[ Voor 14% gewijzigd door Sandor_Clegane op 27-10-2018 21:27 ]

[farlane]

Sandor_Clegane schreef op zaterdag 27 oktober 2018 @ 21:27:
Webpack ook trouwens.

[Sandor_Clegane]

farlane schreef op zaterdag 27 oktober 2018 @ 22:15:
[...]

[Afbeelding]

Dat mag allemaal wel zo wezen, maar het saven van een F# file en hem dan on the fly in de browser zien bijwerken is gewoon hoe ontwikkelen moet zijn, helemaal met grafische dingen. Snelle feedback

Unity 3D kan het ook wel goed, maar dit is nog een stapje sneller.

Ik ben helemaal voor KISS en ik zou zelf het ook niet zo complex maken, maar het lijkt erop dat als je iets met JS of frontend dev wilt, er haast geen ontkomen aan is. En met Elmish is het redelijk te volgen.

[ Voor 17% gewijzigd door Sandor_Clegane op 27-10-2018 22:21 ]

[farlane]

Sandor_Clegane schreef op zaterdag 27 oktober 2018 @ 22:18:
[...]


Dat mag allemaal wel zo wezen, maar het saven van een F# file en hem dan on the fly in de browser zien bijwerken is gewoon hoe ontwikkelen moet zijn, helemaal met grafische dingen. Snelle feedback

Unity 3D kan het ook wel goed, maar dit is nog een stapje sneller.

Was meer een algemene naar de state van webdevelopment heden ten dage, na weet ik veel hoeveel tijd te hebben gehad om er iets fatsoenlijks van te maken.

... maar het lijkt erop dat als je iets met JS of frontend dev wilt, er haast geen ontkomen aan is ...

Wat jij zegt dus ...

[ Voor 11% gewijzigd door farlane op 27-10-2018 22:23 ]

[Sandor_Clegane]

farlane schreef op zaterdag 27 oktober 2018 @ 22:21:
[...]

Was meer een algemene naar de state van webdevelopment heden ten dage, na we3et ik veel hoeveel tijd te hebben gehad om er iets fatsoenlijks van te maken.

Oh dat ben ik helemaal met je eens, maar ja roeien met de riemen enzo. Het is eigenlijk te triest voor woorden hoe slecht het web nog functioneert na zoveel jaren en de enorme hoeveelheden CPU en bandbreedte die we erbij hebben gekregen. Groot deel ligt ook aan alle trackers natuurlijk, centjes verdienen haalt niet het beste in mensen naar boven.

[Alex)]

En helaas worden ook steeds meer desktopapplicaties met webtechnologie (lees: Chrome) gebouwd. Zelfs Microsoft is op die trein gestapt

[Sandor_Clegane]

Cross platform ontwikkelen is een drama. Enige die het een beetje redelijk doet is Xamarin als je de forms gebruikt. Maar ja dat is ook redelijk complex, als de maan verkeerd staat en je bent vergeten een klein diertje te offeren aan de juiste goden, valt alles om.

Dus ja, dan is electron wel een uitkomst. Ben wel blij met VS Code moet ik zeggen.

[Alex)]

VS Code, Slack, MS Teams, Azure Storage Explorer, SQL Operations Studio, Whatsapp Web... allemaal applicaties die zijn gebouwd op Electron. En functioneel doet het op zich wel wat het moet doen, en het ziet er wel fancy uit... maar heel erg lekker werken vind ik het nog altijd niet.

Opstarten duurt even, dingen renderen gaat schokkerig, de applicatie gedraagt zich niet-native (kijk maar eens naar hoe menu's zich gedragen) and to top it all off: het vreet geheugen en schijfruimte.

Van zulke applicaties word ik niet heel blij.

[Gropah]

Sandor_Clegane schreef op zaterdag 27 oktober 2018 @ 22:49:
Cross platform ontwikkelen is een drama. Enige die het een beetje redelijk doet is Xamarin als je de forms gebruikt. Maar ja dat is ook redelijk complex, als de maan verkeerd staat en je bent vergeten een klein diertje te offeren aan de juiste goden, valt alles om.

Dus ja, dan is electron wel een uitkomst. Ben wel blij met VS Code moet ik zeggen.

Het is niet zozeer electron, maar de mogelijkheid om alles in HTML/CSS te kunnen schrijven en draaien. 1 ding wat je wel verliest is performance en het worden snel memory hogs. En dat is niet iets wat altijd mogelijk is en waar iedereen van gediend is. Ik zelf vermijd het over het algemeen wel. Enige uitzonderingen zijn discord, spotify, slack en postman (en dit is mij eigenlijk al te veel). En mobile apps die gemaakt zijn op HTML/CSS haal je er over het algemeen erg snel uit, omdat ze net niet native zijn en animatie's sloom zijn.

[Sandor_Clegane]

Let maar op straks gaan ze Electron zo bouwen dat de libraries gedeeld worden binnen applicaties. Het lijkt een goed begin maar dan zijn we echt in een hele nieuwe world of hurt.

[Alex)]

De terugkeer van de DLL-hell?

[Gropah]

Ach, wat maakt het ook allemaal uit. Alles draait straks op Javascript via asm.js

[Sandor_Clegane]

Alex) schreef op zondag 28 oktober 2018 @ 00:38:
De terugkeer van de DLL-hell?

Het is nooit weggegaan

[Lethalis]

Alex) schreef op zaterdag 27 oktober 2018 @ 23:54:
VS Code, Slack, MS Teams, Azure Storage Explorer, SQL Operations Studio, Whatsapp Web... allemaal applicaties die zijn gebouwd op Electron. En functioneel doet het op zich wel wat het moet doen, en het ziet er wel fancy uit... maar heel erg lekker werken vind ik het nog altijd niet.

Opstarten duurt even, dingen renderen gaat schokkerig, de applicatie gedraagt zich niet-native (kijk maar eens naar hoe menu's zich gedragen) and to top it all off: het vreet geheugen en schijfruimte.

Van zulke applicaties word ik niet heel blij.

Ik word er heel blij van, want meestal doen deze applicaties het ook op Linux. En ik heb liever een Electron app dan helemaal niets

VS Code gebruik ik dagelijks, Postman regelmatig. SQL Operations Studio begint ook bruikbaar te worden.

Door deze tools kan ik dingen voor mijn werk uitzoeken thuis, terwijl ik Linux gebruik. Vroeger was dat altijd onhandig, ging ik maar RDP-en naar een Windows instantie (of installeerde ik Windows ).

Gisteravond nog de basis gelegd voor ouderwetse ASMX web service support op .Net Core met een custom middleware.

Dit maakt het porten van bestaande projecten naar .Net Core eenvoudiger, daarna kunnen ze in een Docker. Dat scheelt straks weer Windows servers die vervangen kunnen worden door Linux.

Scheelt enorm in de licentiekosten en ook qua security is het interessant (geen hopeloos verouderde Windows servers meer die niemand wil upgraden omdat het te duur is).

Dus ja, dan maar oude technieken naar .Net Core brengen

PS
Ik heb SoapCore geprobeerd, maar dat bootst een WCF endpoint na en is niet helemaal compatibel. Dat is al te modern voor wat ik wil

Bovendien kan ik nu tot in de puntjes alles aanpassen, zodat zelfs oude VB6 clients er niks van merken.

[ Voor 8% gewijzigd door Lethalis op 28-10-2018 06:03 ]

[RayNbow]

Gropah schreef op zaterdag 27 oktober 2018 @ 23:56:
[...]En mobile apps die gemaakt zijn op HTML/CSS[...]

Als bezitter van een Lumia 950 hoop ik juist dat meer bedrijven een webapplicatie maken i.p.v. een native ding...

[farlane]

Lethalis schreef op zondag 28 oktober 2018 @ 05:58:
[...]

Ik word er heel blij van, want meestal doen deze applicaties het ook op Linux. En ik heb liever een Electron app dan helemaal niets

Dat is een voordeel inderdaad maar dat zou met Java bijvoorbeeld ook kunnen. Grafisch is het minder fancy, maar ik ben wel fan van applicaties waar het menu telkens op dezelfde plek zit.

[Sandor_Clegane]

Java ziet er een beetje spartaans uit, en je kan het ermee eens zijn of niet, het oog wil ook wat.
Helemaal in de tijd van Apps mag het allemaal wel een beetje fancy zijn.

Zelfde probleem met WPF, Microsoft had er goed aan gedaan om mooi gestylde standaard componenten te maken, maar ja is weer een kwestie van mooie techniek zonder sane defaults.

[Gropah]

RayNbow schreef op zondag 28 oktober 2018 @ 07:57:
[...]

Als bezitter van een Lumia 950 hoop ik juist dat meer bedrijven een webapplicatie maken i.p.v. een native ding...

Ik doel met die zin voornamelijk op native apps die gebouwd zijn met HTML/CSS, waarbij er dus een javascript transpiler bezig is geweest om van de website een app te bouwen (of mbv een webview).

Overigens, is het misschien niet ook eens tijd om een topic a la Wil de laatste CRT-gebruiker de monitor uitzetten? voor windows phone op te zetten?

[RayNbow]

Gropah schreef op zondag 28 oktober 2018 @ 09:53:
Overigens, is het misschien niet ook eens tijd om een topic a la Wil de laatste CRT-gebruiker de monitor uitzetten? voor windows phone op te zetten?

Over CRTs gesproken, ik heb nog een kleine, oude, analoge 4:3 tv met antenne staan.

[Lethalis]

Sandor_Clegane schreef op zondag 28 oktober 2018 @ 09:30:
Java ziet er een beetje spartaans uit, en je kan het ermee eens zijn of niet, het oog wil ook wat.

Met JavaFX valt dat reuze mee.

Het grootste probleem van Java is Java zelf Mensen zijn gewend geraakt aan type inference, automatic properties, multiline string literals met interpolation, etc.

Als ik nu iets in Java doe, denk ik de hele tijd "ik heb echt geen zin om dit uit te gaan typen" of "dit is wel erg onhandig".

Persoonlijk vind ik JDBI een mooie library voor data access bijvoorbeeld, maar als ik dan mijn SQL statements bij elkaar moet gaan plussen omdat er geen multiline string literals zijn dan euh tsja. Laat dan maar.

Uiteraard kun je overal een view of stored procedure van maken, zodat je minder last ervan hebt. Maar het is gewoon irritant

Kotlin lost dit allemaal (en nog veel meer) op uiteraard.

[Sandor_Clegane]

Lethalis schreef op zondag 28 oktober 2018 @ 10:29:
[...]

Met JavaFX valt dat reuze mee.

Het grootste probleem van Java is Java zelf Mensen zijn gewend geraakt aan type inference, automatic properties, multiline string literals met interpolation, etc.

Als ik nu iets in Java doe, denk ik de hele tijd "ik heb echt geen zin om dit uit te gaan typen" of "dit is wel erg onhandig".

Persoonlijk vind ik JDBI een mooie library voor data access bijvoorbeeld, maar als ik dan mijn SQL statements bij elkaar moet gaan plussen omdat er geen multiline string literals zijn dan euh tsja. Laat dan maar.

Uiteraard kun je overal een view of stored procedure van maken, zodat je minder last ervan hebt. Maar het is gewoon irritant

Kotlin lost dit allemaal (en nog veel meer) op uiteraard.

Dat JavaFX ziet er wel slick uit, wist niet eens dat het bestond.

Als je een standaard UI maakt moet je dan nog een hoop aanpassen zodat het een beetje "smoelt"? Dat vond ik bij WPF echt een draak.

[Lethalis]

Sandor_Clegane schreef op zondag 28 oktober 2018 @ 10:31:
[...]


Dat JavaFX ziet er wel slick uit, wist niet eens dat het bestond.

Als je een standaard UI maakt moet je dan nog een hoop aanpassen zodat het een beetje "smoelt"? Dat vond ik bij WPF echt een draak.

Bij JavaFX kun je CSS gebruiken.

Enige wat ik echt minder vind, is dat het niet overal werkt. Ik heb ooit een narrowcasting prototype met JavaFX gebouwd, om er uiteindelijk achter te komen dat het niet (meer) supported is op een Raspberry Pi.

Uiteindelijk heb ik dus een volledige HTML5 player gebouwd. Weer zo'n voorbeeld waar het web gewonnen heeft.

Electron is de volgende stap daarvoor

Portability matters.

Maar Oracle heeft 1 of andere fetish met embedded devices en licenties, waardoor Java gebruiken in die scenario's überhaupt een mijnenveld is (last time I checked, correct me if I'm wrong).

[RayNbow]

Lethalis schreef op zondag 28 oktober 2018 @ 10:29:
maar als ik dan mijn SQL statements bij elkaar moet gaan plussen omdat er geen multiline string literals zijn dan euh tsja. Laat dan maar.

Strings

spoiler:

Het is 2018... kunnen we een keer eindelijk afstappen van SQL-strings?

[farlane]

Lethalis schreef op zondag 28 oktober 2018 @ 10:41:
Bij JavaFX kun je CSS gebruiken.

CSS zou ik niet als pluspunt adverteren tbh, wat een drama is dat.

[Sandor_Clegane]

farlane schreef op zondag 28 oktober 2018 @ 10:56:
[...]

CSS zou ik niet als pluspunt adverteren tbh, wat een drama is dat.

Ik wilde het niet zeggen......

[Lethalis]

RayNbow schreef op zondag 28 oktober 2018 @ 10:46:
[...]
Het is 2018... kunnen we een keer eindelijk afstappen van SQL-strings?

Ze zijn natuurlijk wel geparametriseerd (is dat een woord?).

Maar enlighten me, wat gebruik jij in scenario's waar je complexe queries hebt met meerdere joins die ook nog op een bepaalde volgorde worden geformuleerd om optimaal gebruik te maken van indexes?

Behalve stored procedures en views dan. Die in SQL server zo hun eigen quirks hebben (stored procedures worden niet automatisch gerecompiled bijvoorbeeld, dus een schema wijziging kan tot slechte performance leiden... En views kunnen echt gekke dingen doen, zelfs verkeerde velden teruggeven als je ze niet rebuild. De eerste keer dat ik dat meemaakte was echt schrikken, ik begreep de wereld niet meer ).

Ik wil nog steeds een keer serieus Postgres testen trouwens. Heb het wel voor hobby projecten gebruikt, maar nog nooit echt onder vuur genomen.

farlane schreef op zondag 28 oktober 2018 @ 10:56:
[...]
CSS zou ik niet als pluspunt adverteren tbh, wat een drama is dat.

Wat hebben jullie tegen CSS?

[ Voor 45% gewijzigd door Lethalis op 28-10-2018 11:44 ]

[farlane]

Lethalis schreef op zondag 28 oktober 2018 @ 11:07:
Wat hebben jullie tegen CSS?

Ik vind het een grote clusterfuck. Dit bijvoorbeeld, of het feit dat je niet een style class fatsoenlijk kunt inheriten en uitbreiden. Waarschijnlijk alle redenen waarom SASS ueberhaupt bestaat ....

[RayNbow]

Lethalis schreef op zondag 28 oktober 2018 @ 11:07:
[...]

Ze zijn natuurlijk wel geparametriseerd (is dat een woord?).

Maar enlighten me, wat gebruik jij in scenario's waar je complexe queries hebt met meerdere joins die ook nog op een bepaalde volgorde worden geformuleerd om optimaal gebruik te maken van indexes?

Ik interface doorgaans niet heel vaak met een database, maar helaas gebruik ik meestal nog steeds strings.

Het liefst zie ik dat database-libs i.p.v. een string als argument vragen een AST van de query vereisen. Maar ja, zelf een AST construeren is een gedoe. Als een database-lib om een AST vraagt, dan moet de programmeertaal eigenlijk een eDSL voor SQL ondersteunen om het gebruiksvriendelijk te maken.

Zeg maar iets als XML literals in VB:

Visual Basic .NET:

Dim contactDoc As XDocument = 
    <?xml version="1.0"?>
    <contact>
      <name>Patrick Hines</name>
      <phone type="home">206-555-0144</phone>
      <phone type="work">425-555-0145</phone>
    </contact>

[farlane]

RayNbow schreef op zondag 28 oktober 2018 @ 12:04:
[...]
Het liefst zie ik dat database-libs i.p.v. een string als argument vragen een AST van de query vereisen.

SQLAlchemy (Python) doet dat (of iets wat er op lijkt iig), maar ik kan niet zeggen dat ik dat veel duidelijker vind.

[Sandor_Clegane]

TypeProviders met query expressions, discussie over

[ Voor 26% gewijzigd door Sandor_Clegane op 28-10-2018 13:01 ]

[RayNbow]

farlane schreef op zondag 28 oktober 2018 @ 12:51:
[...]


SQLAlchemy (Python) doet dat (of iets wat er op lijkt iig), maar ik kan niet zeggen dat ik dat veel duidelijker vind.

Nu heb ik geen ervaring met SQLAlchemy, maar het is niet onmogelijk om SQL te embedden in een programmeertaal. In theorie zouden we iets als onderstaande kunnen hebben:

code:

import sqlite3
import random

conn = sqlite3.connect('stuff.sdb')
min_age = random.randint(18, 25)

for name, email in conn.execute($sql$ SELECT name, email FROM users WHERE age >= <$min_age$> $):
    print(name, email)

[Hydra]

RayNbow schreef op zondag 28 oktober 2018 @ 12:04:
[...]

Ik interface doorgaans niet heel vaak met een database, maar helaas gebruik ik meestal nog steeds strings.

Het liefst zie ik dat database-libs i.p.v. een string als argument vragen een AST van de query vereisen. Maar ja, zelf een AST construeren is een gedoe. Als een database-lib om een AST vraagt, dan moet de programmeertaal eigenlijk een eDSL voor SQL ondersteunen om het gebruiksvriendelijk te maken.

Voor Java heb je JOOQ. Fijn om mee te werken IMHO. Enige nadeel is dat 't niet open source is, is wel gratis als je een gratis DB gebruikt. Als je bijvoorbeeld Oracle gebruikt moet je betalen.

[ Voor 10% gewijzigd door Hydra op 28-10-2018 13:59 ]

[WernerL]

Alternatief voor Java/Scala is Slick om typesafe queries te schrijven: http://slick.lightbend.com/doc/3.0.0/introduction.html

IK vind dat icm Scala Play erg fijn werken. Volgens mij hebben ze ook ergens een tool om de boilerplate te genereren adhv je database-schema.

[Alex)]

Lethalis schreef op zondag 28 oktober 2018 @ 05:58:
[...]

Ik word er heel blij van, want meestal doen deze applicaties het ook op Linux. En ik heb liever een Electron app dan helemaal niets

VS Code gebruik ik dagelijks, Postman regelmatig. SQL Operations Studio begint ook bruikbaar te worden.

Door deze tools kan ik dingen voor mijn werk uitzoeken thuis, terwijl ik Linux gebruik. Vroeger was dat altijd onhandig, ging ik maar RDP-en naar een Windows instantie (of installeerde ik Windows ).

Ik vind het mooi dat er (eindelijk) een crossplatform-oplossing is die breed omarmd wordt door ontwikkelaars. I really do. Ik vind het alleen jammer dat de gebruikerservaring maar matig is en dat het tegelijk resources slurpt.

Ik ben misschien een zeur, maar waarom zou een simpele chatclient (Slack is niet veel meer dan dat) honderden megabytes aan RAM moeten verstoken, als mIRC met veel minder hetzelfde kan?

[farlane]

RayNbow schreef op zondag 28 oktober 2018 @ 13:48:
[...]

Nu heb ik geen ervaring met SQLAlchemy, maar het is niet onmogelijk om SQL te embedden in een programmeertaal. In theorie zouden we iets als onderstaande kunnen hebben:

SQLALchemy stelt je in staat dit soort dingen te doen:

Python:

users = Table('users', metadata,
     Column('id', Integer, primary_key=True),
     Column('name', String),
     Column('fullname', String),
)

users.insert().values(name='jack', fullname='Jack Jones')

Nou is dat voor simpele CRUD operaties wel te doen, maar als je wat exotischer select voorwaarden hebt bijvoorbeeld wordt het al snel...awkward

[Hydra]

Alex) schreef op zondag 28 oktober 2018 @ 15:15:
als mIRC met veel minder hetzelfde kan?

Ik ben geen fan van het geheugengebruik van Slack maar dat klopt natuurlijk niet.

[Alex)]

Okay, bijna hetzelfde.

Je hebt kanalen, je hebt deelnemers, je hebt berichten.

Slack heeft dan wat extra functionaliteiten, maar het is geen vanzelfsprekendheid dat dat zo'n zware applicatie oplevert. Met een andere tech-stack had je dezelfde functionaliteit gehad, maar dan met een stuk lichtere footprint

[Kalentum]

Toen ik nog PHP gebruikte werd ik wel blij van dit https://docs.zendframework.com/zend-db/sql/ Basically een interface op een SELECT statement. Je had full control over je queries maar hoefde geen strings te concatten of zo

Ik werk nu vooral met Ruby on Rails, daar zit iets dergelijks in (https://guides.rubyonrails.org/active_record_querying.html) maar ook dan moet je al snel met SQL strings in de weer als het enigszins 'complex' wordt.

[ Voor 33% gewijzigd door Kalentum op 28-10-2018 17:20 ]

[Sandor_Clegane]

LISTEN en NOTIFY in Postgres is tof. Dat is dan wel weer mooi aan een database.

[Ryur]

rutgerw schreef op zondag 28 oktober 2018 @ 17:17:
Ik werk nu vooral met Ruby on Rails, daar zit iets dergelijks in (https://guides.rubyonrails.org/active_record_querying.html) maar ook dan moet je al snel met SQL strings in de weer als het enigszins 'complex' wordt.

Ik werk nu al 4 jaar met RoR, en ik heb tot nu toe pas 2 queries met het handje moeten schrijven.
Dus ik vraag mij echt af wat jij dan bedoeld, want ActiveRecord is super krachtig (vooral Rails 5 versie, als je ouder zit dan snap ik het wel ja)

[Mugwump]

Ryur schreef op zondag 28 oktober 2018 @ 18:54:
[...]

Ik werk nu al 4 jaar met RoR, en ik heb tot nu toe pas 2 queries met het handje moeten schrijven.
Dus ik vraag mij echt af wat jij dan bedoeld, want ActiveRecord is super krachtig (vooral Rails 5 versie, als je ouder zit dan snap ik het wel ja)

Ligt in mijn ogen heel erg aan wat je voor systeem aan het maken bent en hoe de boel architectureel in elkaar steekt. Het komt niet zelden voor dat je een systeem hebt dat feitelijk OLTP is, waarvoor je doorgaans prima met een Active Record pattern kunt werken als het datamodel goed in elkaar steekt. Het wordt lastiger als je ook allerhande OLAP zaken op hetzelfde datamodel moet gaan doen.

[Kalentum]

Ryur schreef op zondag 28 oktober 2018 @ 18:54:
[...]

Ik werk nu al 4 jaar met RoR, en ik heb tot nu toe pas 2 queries met het handje moeten schrijven.
Dus ik vraag mij echt af wat jij dan bedoeld, want ActiveRecord is super krachtig (vooral Rails 5 versie, als je ouder zit dan snap ik het wel ja)

Ik had het over Active Record Query Interface, niet over Active Record zelf. En voor veel gevallen heb je inderdaad geen 'raw' SQL meer nodig. En je kan uiteraard alles oplossen in je Ruby applicatie.

Maar een voorbeeld uit het product waar ik aan werk: er is een intern endpoint dat een lijstje met eigenschappen in de vorm van key-value pairs oplevert. De logica hiervoor was volledig geïmplementeerd in Ruby code, inclusief instantieren van ActiveRecord objecten. Maar er zat complexe fallback logica in voor zowel de key als de value. Die zorgde ervoor dat er meer queries (2 tot 6 per request) werden gebruikt dan nodig. Op een gegeven moment werd de fallback logica nog iets complexer waardoor er een additionele query nodig was en de performance van dat eindpoint met 10% zou verslechteren.

Dus toen heb ik de fallback logica in 1 SQL query geïmplementeerd. Die query heeft een paar COALESCE calls in een GROUP_CONCAT en een stuk of 6 inner en left joins. Minder leesbaar. De responsetijd van het endpoint ging echter van plm 35ms naar 10ms en het geheugengebruik nam ook af. Ik kan helaas niet de query posten maar dit dus om aan te geven dat ActiveRecord ook niet alles is

[Sebazzz]

IBM neemt RedHat over

[R4gnax]

farlane schreef op zondag 28 oktober 2018 @ 10:56:
[...]

CSS zou ik niet als pluspunt adverteren tbh, wat een drama is dat.

Weinig mis met CSS. Veel mensen snappen er gewoon niets van en hebben geen zin zich er in te verdiepen, maar geven er liever op af. Als ze niet binnen 5 minuten snappen hoe het werkt omdat de werkingswijze en opzet buiten hun normale denkwereldje ligt, dan is het meteen ruk, klote en een "clusterfuck".

Dat terwijl zaken zoals de opbouw van selectors juist enorm regelmatig opgesteld zijn.
Het enige wat een beetje irritant is, is het principe van specificity. Ja; daar kun je je eigen mee in de vingers snijden en een complexe brij mee maken. Net zoals een slechte programmeur heel series if statements kan gaan nesten en compleet onleesbare piramide-code kan opleveren.

[ Voor 27% gewijzigd door R4gnax op 28-10-2018 23:48 ]

[alienfruit]

Sebazzz schreef op zondag 28 oktober 2018 @ 21:45:
IBM neemt RedHat over

Mijn ervaring met het samenwerken met IBM lui maakt mij dit niet goed nieuws te vinden. De overname van Github door Microsoft is er niks bij!

[gekkie]

Mjah vind het überhaupt lastig om overnames te noemen waarbij het een gigantische vooruitgang is geweest qua product / service.

rutgerw schreef op zondag 28 oktober 2018 @ 20:42:
Dus toen heb ik de fallback logica in 1 SQL query geïmplementeerd. Die query heeft een paar COALESCE calls in een GROUP_CONCAT en een stuk of 6 inner en left joins. Minder leesbaar. De responsetijd van het endpoint ging echter van plm 35ms naar 10ms en het geheugengebruik nam ook af. Ik kan helaas niet de query posten maar dit dus om aan te geven dat ActiveRecord ook niet alles is

Mjah dat heb je toch eigenlijk altijd met ORM ?
Het spuugt meestal een berg relatief simpele SQL queries uit, ipv gebruik te maken van alles wat SQL / SQL-dialecten te bieden hebben. De expresiviteit voor wat ingewikkelders is er meestal ook niet, of je krijgt waarschijnlijk iets wat weer verdomt veel op SQL gaat lijken
Met Postgres laat ik de DB regelmatig json uit spuigen die direct de deur uit kan, ja de query is wat langer (maar doorgaans wel logisch en leesbaar opgebouwd met wat CTE's (tenzij het performance erg zou schaden)).

[ Voor 80% gewijzigd door gekkie op 29-10-2018 11:39 ]

[Alex)]

Entity Framework kan behoorlijk complexe queries uitspugen. Het is ook heel makkelijk om jezelf met EF gruwelijk in de voet te schieten.

[ThomasG]

Alex) schreef op maandag 29 oktober 2018 @ 11:49:
Entity Framework kan behoorlijk complexe queries uitspugen. Het is ook heel makkelijk om jezelf met EF gruwelijk in de voet te schieten.

Het probleem van ORM's is dat ze vaak dingen doen die je eigenlijk helemaal niet wilt, of niet nodig hebt. Ze zijn handig, maar als je het aan komt op performance kun je vaak beter zelf je query schrijven.

[Alex)]

En bij complexe objectstructuren kan het soms net iets te makkelijk zijn om een hoop objecten te preloaden zonder je te beseffen dat dat allerlei dingen erbij joint die ook allemaal weer gematerialiseerd moeten worden.

Zoiets bijvoorbeeld:

C#:

var bar = _dbContext.Bars
                    .Include(x => x.Foo.Baz)
                    .Include(x => x.Foo.Quux)
                    .Include(x => x.Corges.Select(y => y.Waldo))
                    .Where(x => x.Bar == "Fleeb")
                    .ToList();

[ThomasG]

Alex) schreef op maandag 29 oktober 2018 @ 14:00:
En bij complexe objectstructuren kan het soms net iets te makkelijk zijn om een hoop objecten te preloaden zonder je te beseffen dat dat allerlei dingen erbij joint die ook allemaal weer gematerialiseerd moeten worden.

Zoiets bijvoorbeeld:

C#:

var bar = _dbContext.Bars
                    .Include(x => x.Foo.Baz)
                    .Include(x => x.Foo.Quux)
                    .Include(x => x.Corges.Select(y => y.Waldo))
                    .Where(x => x.Bar == "Fleeb")
                    .ToList();

Bijvoorbeeld. Ook zijn er situaties waarbij je de tabellen A, B, en C hebt. Je wilt iets doen met A en C, wat in een ruwe query wel kan (beide hebben het id van tabel B waar je op kunt joinen) maar via de ORM kan het niet zonder B op te halen.

[whoami]

ThomasG schreef op maandag 29 oktober 2018 @ 13:54:
[...]
Ze zijn handig, maar als je het aan komt op performance kun je vaak beter zelf je query schrijven.

Of leren hoe die ORM werkt en hoe je er best mee werkt ...

Je moet als developer nog altijd weten wat je doet en hoe de tools die je gebruikt werken. In het geval van een ORM check ik bij complexe queries altijd hoe de SQL die gegenereerd werd er uit ziet.

[Sandor_Clegane]

Lastig, als je elke keer je tool moet second guessen kan je je afvragen wat het dan nog oplevert. Juist met die complexe queries wil je juist dat hij zijn werk goed doet, daar heb je hem tenslotte voor.