De Devschuur Coffee Corner

[.oisyn]

Dus Java'ers stelen en bedriegen. Heb ik altijd al gedacht!

[Creepy]

[RayNbow]

.oisyn schreef op vrijdag 24 december 2010 @ 15:15:
Dus Java'ers stelen en bedriegen. Heb ik altijd al gedacht!

Ze geven inderdaad het slechte voorbeeld.

(Met als gevolg dat Microsoft de idiote covariantie van arrays heeft overgenomen )

[Woy]

RayNbow schreef op vrijdag 24 december 2010 @ 16:49:
[...]
(Met als gevolg dat Microsoft de idiote covariantie van arrays heeft overgenomen )

Niet alleen array's, sinds .net 4.0 ook in generic interfaces en delegates

[RayNbow]

Woy schreef op vrijdag 24 december 2010 @ 16:53:
[...]

Niet alleen array's, sinds .net 4.0 ook in generic interfaces en delegates

Ja, maar covariante arrays zijn niet typesafe en dat had .NET niet moeten overnemen. De def-site co-/contravariantie in interfaces van .NET en de use-site co-/contravariantie van Java zijn daarentegen wel typesafe.

[Soultaker]

Tja, wat is typesafe? Null-pointers zijn ook niet typesafe en daar klaagt niemand over. Bij imperatieve talen als C# en Java wordt er dus enige pragmatisme toegepast bij dit soort features. Als je stricte typesafety wil moet je lekker in Haskell blijven coden (en dan geen unsafe.. dingen gebruiken).

[farlane]

C99 en >

Seriously, in bv C# zou je ook niet productief zijn als je zelf je string classes en GUI toolkit zou moeten schrijven.
Libraries maken C net zo productief als elke andere (productieve) taal. En libraries zijn er een shitload van.

En je wordt niet gedwongen een garbage collecting waterhoofd te gebruiken. In C wordt je geacht te weten wat malloc en free doet. Yay.

[ Voor 7% gewijzigd door farlane op 24-12-2010 20:41 ]

[Sebazzz]

En dingen zoals Linq dan? No way dat je zoiets in C of C++ kan simuleren. Misschien door middel van functiepointers, want dan in Java niet kan.

[.oisyn]

Sebazzz schreef op vrijdag 24 december 2010 @ 20:42:
En dingen zoals Linq dan? No way dat je zoiets in C of C++ kan simuleren. Misschien door middel van functiepointers, want dan in Java niet kan.

C++ wel, C niet.

[RayNbow]

Soultaker schreef op vrijdag 24 december 2010 @ 17:44:
Tja, wat is typesafe? Null-pointers zijn ook niet typesafe en daar klaagt niemand over.

Dat er meer gaten in een typesysteem aanwezig zijn betekent natuurlijk niet dat covariante arrays opeens okay zijn.

Verder wordt er wel degelijk geklaagd over het bestaan van null-pointers. Ik zou zelf wel graag non-nullable references willen zien in een moderne taal. Nog liever zie ik dat het de default-optie is en dat nullability opt-in is.

Bij imperatieve talen als C# en Java wordt er dus enige pragmatisme toegepast bij dit soort features.

Ik zie het vaker als conservatisme.

Als je stricte typesafety wil moet je lekker in Haskell blijven coden (en dan geen unsafe.. dingen gebruiken).

Het gebruik van unsafe* in Haskell is niet per se een zonde. De typechecker kan echter niet controleren of je code veilig is. Standaard ligt de verantwoordelijkheid bij de typechecker om te garanderen dat iets correct is. Bij het gebruik van unsafe* verschuift de verantwoordelijkheid en komt het bij de programmeur te liggen. Die moet dus bewijzen dat de code wel veilig is.

[.oisyn]

RayNbow schreef op vrijdag 24 december 2010 @ 22:03:
[...]

Dat er meer gaten in een typesysteem aanwezig zijn betekent natuurlijk niet dat covariante arrays opeens okay zijn.

Het is wat dat betreft jammer dat er geen read-only array types zijn. In C++ mag je bijvoorbeeld een int** (een array van pointers naar int) niet naar een int const** (een array van pointers naar const int) converteren, want dan zou je een element naar een const int kunnen laten wijzen, die je dan met de originele array zou kunnen wijzigen (omdat die ints niet const zijn). Maar naar een int const * const * converteren mag wel - de array is dan niet meer aanpasbaar. Bij inheritance werkt dit dan weer niet omdat een pointer naar Base niet per se binary compatible is met de pointer naar Derived, itt pointers naar resp. const en non-const objecten.

In Java en .Net is dit wel het geval (anders was de feature ook niet mogelijk), en zou je dus iets soortgelijks voor kunnen toepassen. Bijvoorbeeld:

C#:

string[] arrayOfStrings = new string[10];
object[] const arrayOfObjects = arrayOfStrings;
arrayOfObjects[3] = new SomeClass(); // compile-time error, array is const

Het gebruik van unsafe* in Haskell is niet per se een zonde. De typechecker kan echter niet controleren of je code veilig is. Standaard ligt de verantwoordelijkheid bij de typechecker om te garanderen dat iets correct is. Bij het gebruik van unsafe* verschuift de verantwoordelijkheid en komt het bij de programmeur te liggen. Die moet dus bewijzen dat de code wel veilig is.

Mja, dezelfde argumentatie kun je natuurlijk ook toepassen op non-typesafe talen.

[ Voor 11% gewijzigd door .oisyn op 24-12-2010 23:05 ]

[RayNbow]

.oisyn schreef op vrijdag 24 december 2010 @ 22:59:
[...]

Het is wat dat betreft jammer dat er geen read-only array types zijn.

Inderdaad, maar...

In Java en .Net is dit wel het geval (anders was de feature ook niet mogelijk), en zou je dus iets soortgelijks voor kunnen toepassen. Bijvoorbeeld:

C#:

string[] arrayOfStrings = new string[10];
object[] const arrayOfObjects = arrayOfStrings;
arrayOfObjects[3] = new SomeClass(); // compile-time error, array is const

...met .NET's variance zou je het ook kunnen bereiken door bijv. elk type T[] automatisch zowel de hypothetische interfaces ReadOnlyArray<out T> als WriteOnlyArray<in T> te laten implementeren.

Het is alleen meer schrijfwerk dan "T[] const"...

(Alternatief is missch. om T[in] en T[out] een shorthand te laten zijn voor ReadOnlyArray<T> en WriteOnlyArray<T>?)

[...]

Mja, dezelfde argumentatie kun je natuurlijk ook toepassen op non-typesafe talen.

Ja, maar ik heb liever dat zaken by-default veilig zijn dan andersom.

[.oisyn]

Hoe doe je in C# eigenlijk een cross join met LINQ extension methods? Er is geen From() of Cross() method oid. En een Join() is een inner join.

Ik werd geïnspireerd door .oisyn in "De Devschuur Coffee Corner" . Ik heb nu dit:

C++:

int main()
{
    auto r = 
        range(1, 10)
        .select([](int i) { return i * 10; })
        .filter([](int i) { return i % 3 == 0; })
        .concat(range(1, 10))
        .select([](int i) { return i+100; });

    std::copy(r.begin(), r.end(), std::ostream_iterator<int>(std::cout, ", "));
}

Het is jammer dat lambda's in C++ wat meer verbose zijn dan in C# .

[ Voor 65% gewijzigd door .oisyn op 24-12-2010 23:32 ]

[RayNbow]

.oisyn schreef op vrijdag 24 december 2010 @ 23:29:
Hoe doe je in C# eigenlijk een cross join met LINQ extension methods? Er is geen From() of Cross() method oid. En een Join() is een inner join.

Een cross-join is toch gewoon een Cartesisch product?

Dan zijn de volgende constructies gelijk:

C#:

// Monadic unit (a -> M<a>) for arrays
static T[] Unit<T>(T a)
{
    return new T[] { a };
}

static void Main(string[] args)
{
    // no tuples in C#3.5, so I'll use this for now:
    Func<int, int, string> Tuple = (a, b) => String.Format("({0},{1})", a, b);

    var xs = new int[]{ 1, 2, 3};
    var ys = new int[] { 5, 6};

    // LINQ query-syntax:
    var cartesian = from x in xs
                    from y in ys
                    select Tuple(x,y);
    
    // Using SelectMany (monadic bind) and Unit:
    cartesian = xs.SelectMany(x => ys.SelectMany(y => Unit(Tuple(x,y))));

    // m.SelectMany(z => Unit(f(z))) === m.Select(f)
    cartesian = xs.SelectMany(x => ys.Select(y => Tuple(x,y)));

    foreach (var c in cartesian)
        Console.WriteLine(c);

    Console.ReadKey();
}

[.oisyn]

Oh, right

.edit: hmmz, de VC++ compiler bugt. Dit mag wel:

C++:

    auto r2 = range('a', 'd').select([](char c) { return c; });
    auto r = 
        range(1, 4)
        .select_many([=](int i) { return r2; });

Maar dit niet:

C++:

    auto r = 
        range(1, 4)
        .select_many([=](int i) { return range('a', 'd').select([](char c) { return c; }); });

Blijkbaar heeft ie het wat lastig met geneste lambda's

[ Voor 93% gewijzigd door .oisyn op 25-12-2010 03:32 ]

[farlane]

Sebazzz schreef op vrijdag 24 december 2010 @ 20:42:
En dingen zoals Linq dan? No way dat je zoiets in C of C++ kan simuleren. Misschien door middel van functiepointers, want dan in Java niet kan.

Zoiets zal er waarschijnlijk nooit komen in standaard C, aangezien het toepassingsgebied van een dergelijke functionaliteit redelijk beperkt is.
Mocht er niet te leven zijn zonder iets dergelijks in C, dan komt er ongetwijfeld iets of iemand langs die een Linq-to-C compiler/preprocessor schrijft.

Anyways, ik denk niet dat het ontbreken van Linq-voor-C voor een gigantische non-productiviteit zal zorgen.

[Gamebuster]

Dood hier. Iedereen kerst aan't vieren zeker

[Freeaqingme]

Gamebuster schreef op zaterdag 25 december 2010 @ 17:41:
Dood hier. Iedereen kerst aan't vieren zeker

Gek he, op eerste kerstdag?

[Gamebuster]

Freeaqingme schreef op zaterdag 25 december 2010 @ 18:32:
[...]


Gek he, op eerste kerstdag?

hehe

Ik ben niet zo'n kerstfan. Altijd gezeik rond kerst bij familie over wie wat moet betalen en over wat er gegeten gaat worden.

[ Voor 5% gewijzigd door Gamebuster op 25-12-2010 19:40 ]

[Snake]

Mwa, heb gegeten maar nu ga ik toch terug CoD 1 uitspelen opnieuw. Voor de zoveelste keer. Deze week dit boek lezen

[Snake]

.oisyn schreef op zaterdag 25 december 2010 @ 00:59:
Oh, right

.edit: hmmz, de VC++ compiler bugt. Dit mag wel:

C++:

    auto r2 = range('a', 'd').select([](char c) { return c; });
    auto r = 
        range(1, 4)
        .select_many([=](int i) { return r2; });

Maar dit niet:

C++:

    auto r = 
        range(1, 4)
        .select_many([=](int i) { return range('a', 'd').select([](char c) { return c; }); });

Blijkbaar heeft ie het wat lastig met geneste lambda's

Nu stel ik mij de vraag: in C++ zijn zoveel meer gekke dingen met [] en [=]. Hoe zoek je zoiets op wat dat betekend?

[Gamebuster]

Snake schreef op zaterdag 25 december 2010 @ 19:55:
[...]

Nu stel ik mij de vraag: in C++ zijn zoveel meer gekke dingen met [] en [=]. Hoe zoek je zoiets op wat dat betekend?

unusual square brackets with equal sign in between them operator

[Verwijderd]

Gamebuster schreef op zaterdag 25 december 2010 @ 19:39:
[...]
. Altijd gezeik rond kerst bij familie over wie wat moet betalen

[Verwijderd]

Freeaqingme schreef op zaterdag 25 december 2010 @ 18:32:
Gek he, op eerste kerstdag?

Niet iedereen hangt het Christelijk geloof aan. Aan sommigen is het hele kerstfeest om (een van diverse redenen) gewoon absoluut niet besteed.

Gamebuster schreef op zaterdag 25 december 2010 @ 19:39:
Altijd gezeik rond kerst bij familie over wie wat moet betalen en over wat er gegeten gaat worden.

Be like me - niets aan kerst doen, je familie gewoon duidelijk maken dat je geen enkele behoefte hebt om mee te doen aan die onzin.

[Gamebuster]

Verwijderd schreef op zaterdag 25 december 2010 @ 21:39:
[...]

Niet iedereen hangt het Christelijk geloof aan. Aan sommigen is het hele kerstfeest om (een van diverse redenen) gewoon absoluut niet besteed.


[...]

Be like me - niets aan kerst doen, je familie gewoon duidelijk maken dat je geen enkele behoefte hebt om mee te doen aan die onzin.

Wie viert er nog kerst met christelijke gedachte? Er is niets christelijks aan de kerstman, een kerstboom, etc. Er zijn christelijke varianten die beweren dat een kerstboom zelfs "demonisch" is, omdat het gebaseerd is op "het occulte". (kerstballen zouden geesten verjagen o.i.d., weet ik veel)

Ik betwijfel dat de gemiddelde mens zelfs nog de christelijke gedachte achter kerst weet. Mensen denken bij kerst niet aan Jezus, die denken aan kerstbomen, lekker eten, familie en kerstcadeaus.

[ Voor 3% gewijzigd door Gamebuster op 25-12-2010 23:11 ]

[afraca]

Gamebuster schreef op zaterdag 25 december 2010 @ 23:09:
[...]

Wie viert er nog kerst met christelijke gedachte?

offtopic:
Me En de 400 mensen die samen vanochtend met mij in de kerk zaten

edit: En nee, ik ga niet in op de opmerking over het "demonische" karakter van kerst, onze privacyschendende ( *note to self: wees lief, is kerst* ) Google weet daarop prima antwoord

[ Voor 27% gewijzigd door afraca op 25-12-2010 23:20 ]

[Gamebuster]

afraca schreef op zaterdag 25 december 2010 @ 23:18:
[...]

offtopic:
Me En de 400 mensen die samen vanochtend met mij in de kerk zaten

edit: En nee, ik ga niet in op de opmerking over het "demonische" karakter van kerst, onze privacyschendende ( *note to self: wees lief, is kerst* ) Google weet daarop prima antwoord

Ik zei ook, "sommige christelijke varianten", lang niet allemaal. Maarja, "sommige christelijke varianten" sporen gewoon niet helemaal.

[RayNbow]

Snake schreef op zaterdag 25 december 2010 @ 19:55:
[...]

Nu stel ik mij de vraag: in C++ zijn zoveel meer gekke dingen met [] en [=]. Hoe zoek je zoiets op wat dat betekend?

Door de rest van .oisyn's post te lezen en erachter te komen dat het over lambda's gaat.

 

farlane schreef op zaterdag 25 december 2010 @ 13:08:
Zoiets zal er waarschijnlijk nooit komen in standaard C, aangezien het toepassingsgebied van een dergelijke functionaliteit redelijk beperkt is.

Waarom is het toepassingsgebied beperkt?

Mocht er niet te leven zijn zonder iets dergelijks in C, dan komt er ongetwijfeld iets of iemand langs die een Linq-to-C compiler/preprocessor schrijft.

Ik wens zo'n iemand dan veel succes met het gebrekkige polymorfisme in C.

[Freeaqingme]

Verwijderd schreef op zaterdag 25 december 2010 @ 21:39:
[...]

Niet iedereen hangt het Christelijk geloof aan.

Dat hoef took niet Het is wat mij betreft tegenwoordig ook gewoon een feest waarbij veel mensen gewoon gezellig bij elkaar komen (zeker in Amerika, waarbij kerst eigenlijk de enige dag is dat _iedereen_ echt vrij is (op wat medische meuk enzo na)).

[Verwijderd]

Gamebuster schreef op zaterdag 25 december 2010 @ 23:09:
Wie viert er nog kerst met christelijke gedachte?

Freeaqingme schreef op zondag 26 december 2010 @ 01:04:
Dat hoef took niet

Voor jullie maakt het niet zoveel uit, kennelijk. Voor mij wel. Zoek het in mijn afkeur voor Wikipedia: Abrahamitische religie

Enfin... dit blijft het koffiehoekje, dus, daar ga ik niet verder op in. *snort nog een kopje koffie op*

[Hillie]

Freeaqingme schreef op zondag 26 december 2010 @ 01:04:
Dat hoef took niet Het is wat mij betreft tegenwoordig ook gewoon een feest waarbij veel mensen gewoon gezellig bij elkaar komen (zeker in Amerika, waarbij kerst eigenlijk de enige dag is dat _iedereen_ echt vrij is (op wat medische meuk enzo na)).

De lokale safeway (supermarkt) was hier vandaag van 8 tot 4 open meen ik. Best jammer, maar ja. Ik denk dat de mensen die werkten wel leuk extra kregen vandaag.

[Verwijderd]

Verwijderd schreef op zaterdag 25 december 2010 @ 21:39:
[...]

Niet iedereen hangt het Christelijk geloof aan.

Heeft kerst iets met Christendom te maken dan! Sowieso is die boom onstaan uit een heidense traditie.
Mijn invulling is het vieren dat de dagen weer langer worden! Dat doe ik samen met familie, kerstversiering en cadeautjes! Ik heb persoon best wel helemaal niets met religie, maar kerst vind ik gewoon een gezellige tijd. Kerstboompje in huis, wat frutsels her en der

[ Voor 44% gewijzigd door Verwijderd op 26-12-2010 08:44 ]

[farlane]

RayNbow schreef op zaterdag 25 december 2010 @ 23:28:
[...]
Waarom is het toepassingsgebied beperkt?

C is gemaakt als general purpose taal, je kunt er (vrijwel) alles mee. Iets als Linq is te specifiek om in de C standaard te worden opgenomen.

[...]

Ik wens zo'n iemand dan veel succes met het gebrekkige polymorfisme in C.

Ik zie even niet wat polymorfisme met Linq te maken heeft, maar de basis van polymorfisme (van objecten) is de functiepointer ( en ook van lambda expressies, de basis van Linq, volgens mij ) , en C beheerst die vrij goed.

[Davio]

Verwijderd schreef op zondag 26 december 2010 @ 08:39:
[...]

Heeft kerst iets met Christendom te maken dan! Sowieso is die boom onstaan uit een heidense traditie.
Mijn invulling is het vieren dat de dagen weer langer worden! Dat doe ik samen met familie, kerstversiering en cadeautjes! Ik heb persoon best wel helemaal niets met religie, maar kerst vind ik gewoon een gezellige tijd. Kerstboompje in huis, wat frutsels her en der

De christelijke kerst is ook één grote marketingstunt.

Het vieren van het lengen van de dagen was al eeuwen een bekend ritueel. Maar de christenen wilden graag zieltjes winnen. Daarom hebben ze maar bedacht dat Jezus op 25 december geboren was, wat uiteraard totaal niet waar is, zodat de heidenen er niets voor hoefden te doen om over te stappen; alleen even de kerk binnenlopen.

Walgelijk, die christenen.

Ik vier met kerst familie. Dat doen we ook op andere dagen, maar kerst is praktisch, omdat iedereen dan vrij is.

[RayNbow]

farlane schreef op zondag 26 december 2010 @ 11:26:
[...]

C is gemaakt als general purpose taal, je kunt er (vrijwel) alles mee. Iets als Linq is te specifiek om in de C standaard te worden opgenomen.

Dat is een valide reden om iets specifieks apart van de kern van C te houden. Nu weet ik alleen nog steeds niet waarom je denkt waarom het te specifiek is.

[...]

Ik zie even niet wat polymorfisme met Linq te maken heeft,

De kracht van LINQ is dat je iets als het volgende kunt schrijven

C#:

var zs = from x in xs
         from y in ys
         select f(x,y);

wat werkt voor elke xs en elke ys, zolang het type van xs en ys de LINQ operatoren ondersteunen. Dit is polymorfisme.

(Alleen is het niet mogelijk in C# om er verder over te abstraheren.)

maar de basis van polymorfisme (van objecten) is de functiepointer

Nee, dat is een implementatie.

( en ook van lambda expressies, de basis van Linq, volgens mij ) ,

Met alleen functiepointers kom je er niet. Je wilt graag closures en naast de code (functiepointer) ook de omgeving kunnen raadplegen.

en C beheerst die vrij goed.

Ja, maar functies zijn nog steeds geen first-class citizens in C.

[farlane]

RayNbow schreef op zondag 26 december 2010 @ 12:40:
Dat is een valide reden om iets specifieks apart van de kern van C te houden. Nu weet ik alleen nog steeds niet waarom je denkt waarom het te specifiek is.

Omdat er andere dingen zijn die naar mijn idee eerder in aanmerking zouden komen om in de taal te worden opgenomen dan Linq. Bijvoorbeeld templates/generic achtige dingen.

Ook dat zie ik in C niet gebeuren, de kracht van C is juist dat de basis klein en overzichtelijk is.

Nee, dat is een implementatie.

Naar mijn weten ook de enige zinnige implementatie?

Met alleen functiepointers kom je er niet. Je wilt graag closures en naast de code (functiepointer) ook de omgeving kunnen raadplegen.

Een closure is een soort functorfunction object toch? In dat geval lijkt het nl wel erg veel op een functiepointer, again.

Ja, maar functies zijn nog steeds geen first-class citizens in C.

Maar een functie pointer wel. Is dat niet voldoende?

[RayNbow]

farlane schreef op zondag 26 december 2010 @ 14:32:
[...]

Omdat er andere dingen zijn die naar mijn idee eerder in aanmerking zouden komen om in de taal te worden opgenomen dan Linq. Bijvoorbeeld templates/generic achtige dingen.

Ook dat zie ik in C niet gebeuren, de kracht van C is juist dat de basis klein en overzichtelijk is.

Ik ben het eens dat C's kracht idd de kleine basis en overzichtelijkheid is.

[...]

Naar mijn weten ook de enige zinnige implementatie?

Zou kunnen, maar ik zou niet stellen dat een bepaalde implementatie de basis is voor een bepaald concept.

[...]

Een closure is een soort functor toch? In dat geval lijkt het nl wel erg veel op een functiepointer, again.

Een closure kun je inderdaad zien als wat code met wat state, waarbij de state de omgeving van de closure is.

* RayNbow vindt het trouwens jammer dat het woord functor ooit door sommigen is gebruikt om function objects mee aan te duiden...

[...]

Maar een functie pointer wel. Is dat niet voldoende?

Het maakt het er iig niet gemakkelijker op. Hoe zou je bijv. in C de functie compose maken met de volgende eigenschap?

code:

compose(f,g)(x) == f(g(x))

[armageddon_2k1]

Davio schreef op zondag 26 december 2010 @ 12:22:
[...]

De christelijke kerst is ook één grote marketingstunt.

Het vieren van het lengen van de dagen was al eeuwen een bekend ritueel. Maar de christenen wilden graag zieltjes winnen. Daarom hebben ze maar bedacht dat Jezus op 25 december geboren was, wat uiteraard totaal niet waar is, zodat de heidenen er niets voor hoefden te doen om over te stappen; alleen even de kerk binnenlopen.

Walgelijk, die christenen.

Ik vier met kerst familie. Dat doen we ook op andere dagen, maar kerst is praktisch, omdat iedereen dan vrij is.

Gezellig! Even een hele groep afkraken met kerst! On-fucking-gelooflijk..... stoor je in hemelsnaam niet zo en kom niet met termen als 'walgelijk die ...' over groepen die tijden geleden wat uitspookten.

Terug naar waar de Devschuur Coffeecorner voor bedoeld is.

Wij implementeren gewoon de IChristmas interface:

Java:

interface IChristmasCelebrateable {
    public Tree getTree();
    public Vector<Present> getPresents();
    public Vector<Present> putPresents();

   // etc
}

[farlane]

RayNbow schreef op zondag 26 december 2010 @ 15:13:
Het maakt het er iig niet gemakkelijker op. Hoe zou je bijv. in C de functie compose maken met de volgende eigenschap?

code:

compose(f,g)(x) == f(g(x))

Ff voor mijn begrip: compose is een functie die een functie oplevert die achtereenvolgens f(g(x)) doet?

[H!GHGuY]

farlane schreef op zondag 26 december 2010 @ 15:23:
[...]

Ff voor mijn begrip: compose is een functie die een functie oplevert die achtereenvolgens f(g(x)) doet?

In C kun je dit vziw enkel doen door met void* te gaan casten, of is:

C:

#define MAKE_COMPOSE(ResultType, ParamType, f, g) \
  ResultType compose_#ResultType_#ParamType(ParamType param) \
  { return f(g(param)); }

#define USE_COMPOSE(ResultType, ParamType, param) \
  compose_#ResultType_#ParamType(param)

ook goed?

In C++ zijn er echter wel andere mogelijkheden

C++:

// C++ 0x
auto compose(ResultOuter (*f)(ResultInner), ResultInner (*g)(Param)) ->
  std::function<std::result_of(f(g(Param())) (Param)>
{
  return [] (Param x) { f(g(x)); }
}

Ik vermoed dat het met de huidige incarnatie van C++ ook wel kan, maar dan moet ik even dieper in de boost syntax voor lambda's en metaprogramming gaan duiken.

[ Voor 16% gewijzigd door H!GHGuY op 26-12-2010 16:22 ]

[Verwijderd]

c

[ Voor 98% gewijzigd door Verwijderd op 26-12-2010 16:17 ]

[RayNbow]

farlane schreef op zondag 26 december 2010 @ 15:23:
[...]

Ff voor mijn begrip: compose is een functie die een functie oplevert die achtereenvolgens f(g(x)) doet?

Juist.

H!GHGuY schreef op zondag 26 december 2010 @ 16:16:
[...]


In C kun je dit vziw enkel doen door met void* te gaan casten, of is:

C:

#define MAKE_COMPOSE(ResultType, ParamType, f, g) \
  ResultType compose_#ResultType_#ParamType(ParamType param) \
  { return f(g(param)); }

#define USE_COMPOSE(ResultType, ParamType, param) \
  compose_#ResultType_#ParamType(param)

ook goed?

Eh... hoe werkt dat?

[H!GHGuY]

RayNbow schreef op zondag 26 december 2010 @ 18:35:
[...]
Eh... hoe werkt dat?

Kom ik er van af met '(black) magic'?

[Verwijderd]

En nu partiële functie-applicatie

Ja, dat kan ook (het zit in boost), maar waarom zou je zoiets willen als de compiler het waarschijnlijk niet netjes kan optimaliseren? Ik kan me ook voorstellen dat een compiler bij het bovenstaande voorbeeld nog steeds niet inziet dat de functies te fuseren zijn.[/reclame-voor-functionele-programmeertalen]

[farlane]

Verwijderd schreef op zondag 26 december 2010 @ 20:09:
En nu partiële functie-applicatie

Ja, dat kan ook (het zit in boost), maar waarom zou je zoiets willen als de compiler het waarschijnlijk niet netjes kan optimaliseren? Ik kan me ook voorstellen dat een compiler bij het bovenstaande voorbeeld nog steeds niet inziet dat de functies te fuseren zijn.[/reclame-voor-functionele-programmeertalen]

Het ging er meer om of het mogelijk zou zijn om, als er niet te leven zou zijn *kuch* zonder Linq in C, er een Linq-To-C compiler te maken zou zijn. ( Dat weer ivm mijn opmerking dat je ook in C productief kunt zijn,en niet alleen in embedded omgevingen, als je maar libraries ter beschikking hebt )

Nogmaals, zoiets zal waarschijnlijk nooit gebeuren omdat C nu eenmaal een andere doelstelling heeft dan C#.

Een voordeel van een taal als C is dat het altijd redelijk makkelijk te leren zal zijn ( niet om te 'masteren' ), itt tot een taal als C# en in mindere mate C++(maar die was al moeilijk) die met hun almaar groeiende featureset telkens een tikkeltje moeilijker worden.

[ Voor 13% gewijzigd door farlane op 26-12-2010 20:59 ]

[RayNbow]

H!GHGuY schreef op zondag 26 december 2010 @ 19:18:
[...]


Kom ik er van af met '(black) magic'?

Nee.
Maar ik stelde de vraag omdat ik denk dat je macro's al heel snel nameclashes kunnen opleveren.

Verwijderd schreef op zondag 26 december 2010 @ 20:09:
En nu partiële functie-applicatie

Dat is imo altijd een hel in ongecurryde talen.

Ja, dat kan ook (het zit in boost), maar waarom zou je zoiets willen als de compiler het waarschijnlijk niet netjes kan optimaliseren?

Waarom? Omdat het altijd leuk is om te kijken hoe ver je kunt gaan om bepaalde dingen uit te drukken in een taal.

Ik kan me ook voorstellen dat een compiler bij het bovenstaande voorbeeld nog steeds niet inziet dat de functies te fuseren zijn.[/reclame-voor-functionele-programmeertalen]

* RayNbow hoopt trouwens dat C# ooit in de nabije toekomst bepaalde ketens van LINQ operators kan fuseren.

[D-Raven]

Wat een rust op de weg vandaag.. jammer dat het niet standaard zo is

[Soultaker]

H!GHGuY schreef op zondag 26 december 2010 @ 16:16:
In C kun je dit vziw enkel doen door met void* te gaan casten

Dat is niet wat RayNBow bedoelt; compose() moet niet zelf f en g aanroepen en een waarde retourneren, maar een functie retourneren die g toepast op zijn argument en dan f toepast op het resultaat en dat resultaat weer retourneert.

Een mogelijke constructie zou zijn om eerst functors te modelleren als first-class objects en daar dan wat mee te doen:

C:

struct Functor
{
    int apply(struct Functor *this, int arg);
};

struct ComposedFunctor
{
    struct Functor functor;
    struct Functor *f, *g;
};

static int compose_apply(struct Functor *this, int arg)
{
    struct ComposedFunctor *cf = (struct ComposedFunctor*)this;
    return cf->f->apply(cf->f, cf->g->apply(cf->g, arg));
}

struct Functor *compose(struct Functor *f, struct Functor *g)
{
    struct ComposedFunctor *result = malloc(sizeof(struct ComposedFunctor));
    if (!result) return NULL;
    result->functor.apply = compose_apply;
    result->f = f;
    result->g = g;
    return &result.functor;
}

int main()
{
    Functor *f = /* .. */, *g = /* .. */, *fg = compose(f, g);
    return fg->apply(fg, 123);
}

Maar je mist hier genericiteit (ik heb het type van argumenten en resultaten gehardcode als int), garbage collection (die functors moeten ergens vrijgegeven worden) en impliciete passing van de context (je moet de this-pointer zelf meegeven; i.mo. nog het minst grote bezwaar). Een aantal van die concepten hangen samen: als je closures wil supporten (één manier om context impliciet te passen) ontkom je praktisch niet aan garbage collection, bijvoorbeeld.

Al met al is aan de beperkingen hierboven en de lap code die je nodig hebt om dit te implementeren wel duidelijk dat C niet ideaal is voor dit soort dingen. Ter vergelijking, in Haskell schrijf je simpelweg:

Haskell:

compose f g x = f (g x)

En dat is dan wel generiek, typesafe, garbage collected, en het resultaat gedraagt zich als een gewone functie.

[ Voor 3% gewijzigd door Soultaker op 27-12-2010 16:53 ]

[Haan]

Jeuh, we zitten weer op internet aangesloten Appartement in Duitsland waar internet via andere bewoner van het complex komt, met een repeater bij ons om het signaal te versterken. Maar die was z'n instellingen kwijt, dus met veel pijn en moeite een handleiding gedownload via een ander netwerk met een beetje bereik en zo het ding weer weten in te stellen. Paar dagen zonder internet zitten zou toch behoorlijk afzien zijn natuurlijk

[R4gnax]

RayNbow schreef op maandag 27 december 2010 @ 08:05:
* RayNbow hoopt trouwens dat C# ooit in de nabije toekomst bepaalde ketens van LINQ operators kan fuseren.

LINQ is eigenlijk niets anders dan een samenvoeging van closures, delegates en reentrant functions (m.b.v. het yield keyword Enumerables opbouwen). Het is op zichzelf geen speciale language feature. (Sterker nog: feitelijk kon je dit allemaal al met het oude C# 2.0 implementeren, maar met de type inference van latere versies werd het pas toegankelijk en praktisch.)

Wil je hierin gaan optimaliseren, dan zou je de compiler op een hoog niveau semantische kennis moeten geven van bepaalde types geassocieerd met de huidige LINQ implementatie, zoals gespecialiseerde IEnumerable varianten als ISortedEnumerable. Voor een deel gebeurt dat soort van optimalisatie nu al runtime in sommige LINQ providers, geloof ik.

Denk niet dat je de compiler in de nabije toekomst slim genoeg kunt krijgen om op zo'n hoog niveau over zelf gebouwde 'operators' autonoom te kunnen redeneren. Misschien dat je door je operator te decoreren met wat attributes nog wat kunt behalen, maar dan zou je dus ook met zaken als .AsParallel() rekening moeten gaan houden. Mocht je dan met de hand zaken af moeten gaan stellen, kun je net zo goed zelf meteen een efficiente LINQ query uit hameren.

[.oisyn]

Soultaker schreef op maandag 27 december 2010 @ 16:50:

C:

struct Functor
{
    int apply(struct Functor *this, int arg);
};

Mag die syntax? Heb je niet iets als int (*apply)(...) nodig? Of is dat C99?

[Soultaker]

Nee, dat was een foutje van mij inderdaad. (Ik had de code getypt zonder te testen.)

[RayNbow]

R4gnax schreef op maandag 27 december 2010 @ 22:37:
Wil je hierin gaan optimaliseren, dan zou je de compiler op een hoog niveau semantische kennis moeten geven van bepaalde types geassocieerd met de huidige LINQ implementatie, zoals gespecialiseerde IEnumerable varianten als ISortedEnumerable. Voor een deel gebeurt dat soort van optimalisatie nu al runtime in sommige LINQ providers, geloof ik.

Je hebt gelijk. Natuurlijk wordt het lastig om de boel te optimaliseren voor elke mogelijke implementatie van de LINQ operators. Er zullen misschien zelfs instanties zijn waarbij je missch. bepaalde dingen niet wil fuseren.

Denk niet dat je de compiler in de nabije toekomst slim genoeg kunt krijgen om op zo'n hoog niveau over zelf gebouwde 'operators' autonoom te kunnen redeneren. Misschien dat je door je operator te decoreren met wat attributes nog wat kunt behalen, maar dan zou je dus ook met zaken als .AsParallel() rekening moeten gaan houden. Mocht je dan met de hand zaken af moeten gaan stellen, kun je net zo goed zelf meteen een efficiente LINQ query uit hameren.

Het zou wel handig zijn als library bouwers bepaalde optimalisatieregels konden definieren die de compiler dan kan toepassen. Dan hoef je deze last niet bij de gebruiker van de library te leggen.

Simpel voorbeeld (pseudocode):

C#:

#pragma rewrite {IEnumerable<T> xs; Func<T, Boolean> p, q;}
#               {xs.Where(p).Where(q) -> xs.Where(x => p(x) && q(x));}

Btw, over optimalisaties gesproken. Ik kwam een keer de volgende optimalisatie tegen op Stackoverflow:

C#:

// accepted answer:
return xs.TakeWhile(i => i != 5)
         .Where(j => j == 1);

// optimalisation suggested by another user:
bool find5 = false;
return xs.Where(p => p == 1 && !(find5 = (p == 5) ? true : find5));

In een microbenchmark was de optimalisatie sneller, maar ik vind het niet leesbaar en niet iets dat de eindgebruiker zou moeten schrijven.

Er is trouwens een situatie waarin de optimalisatie zich anders gedraagt. Bonuspunten voor mensen die weten wanneer.

[Woy]

een nieuwe pc op mijn werk.


mijn pc wou niet opstarten vandaag, dus ben al de hele ochtend bezig om mijn spullen van de oude HD te kopieren, en mijn nieuwe pc in te richten.

[BoAC]

En waarom wilde die niet meer opstarten? Een echte tweaker zoekt dat uit tot op de bodem

[AtleX]

Ik als Tweaker doe dat wel in mijn eigen tijd en laat het op mijn werk over aan de systeembeheerder. Ik ga niet een paar uur van mijn strakke planning afhalen om werk te gaan dat geen cent oplevert voor de baas terwijl daar iemand voor aanwezig is die daarvoor betaald wordt.

[ Voor 13% gewijzigd door AtleX op 28-12-2010 10:59 ]

[.oisyn]

RayNbow schreef op dinsdag 28 december 2010 @ 07:58:
Btw, over optimalisaties gesproken. Ik kwam een keer de volgende optimalisatie tegen op Stackoverflow:

C#:

// accepted answer:
return xs.TakeWhile(i => i != 5)
         .Where(j => j == 1);

// optimalisation suggested by another user:
bool find5 = false;
return xs.Where(p => p == 1 && !(find5 = (p == 5) ? true : find5));

In een microbenchmark was de optimalisatie sneller, maar ik vind het niet leesbaar en niet iets dat de eindgebruiker zou moeten schrijven.

Het is imho nogal situatieafhankelijk wanneer dit sneller is. Als TakeWhile() een substantieel deel van de elementen weglaat is de geoptimaliseerde variant echt niet sneller (want die stopt niet zodra i == 5). En het gaat fout wanneer de collectie oneindig is (en dat was vast je bonusvraag).

BoAC schreef op dinsdag 28 december 2010 @ 10:57:
En waarom wilde die niet meer opstarten? Een echte tweaker zoekt dat uit tot op de bodem

Echt niet, een echte tweaker denkt "cool, nieuwe hardware" als z'n werk-PC niet meer werkt

[ Voor 84% gewijzigd door .oisyn op 28-12-2010 11:10 ]

[R4gnax]

RayNbow schreef op dinsdag 28 december 2010 @ 07:58:
Er is trouwens een situatie waarin de optimalisatie zich anders gedraagt. Bonuspunten voor mensen die weten wanneer.

De tweede expressie is stateful, vanwege de find5 variabele die via een closure bereikbaar is. Wanneer je de resulterende IEnumerable meerdere keren evalueert kan deze met een andere start waarde een ander resultaat opleveren.

Verder ben ik het eens met .oisyn. Die optimalisatie zal bij grotere sets elementen zeker niet sneller zijn, omdat de eerste expressie met TakeWhile() de resultaat set meteen een flink stuk kan limiteren alvorens Where() aan de slag gaat.

Wat .oisyn verder schrijft klopt ook: bij het behandelen van een oneindige reeks loopt de optimalisatie oneindig door terwijl de eerste expressie netjes stopt op het stop criterion in TakeWhile().

Drie problemen met de optimalisatie dus:

1. Stateful expressie levert ander resultaat bij her-evaluatie.
2. Ondersteunt oneindige reeksen niet.
3. Het is waarschijnlijk in de average case helemaal geen optimalisatie.

[ Voor 43% gewijzigd door R4gnax op 28-12-2010 11:22 ]

[Woy]

BoAC schreef op dinsdag 28 december 2010 @ 10:57:
En waarom wilde die niet meer opstarten? Een echte tweaker zoekt dat uit tot op de bodem

Er was een bestand beschadigd, maar aangezien ik toch al een nieuwe pc moest, heb ik deze gelegenheid maar aangegrepen om dat direct te doen. De systeembeheerder kan daarna weer zorgen dat de oude PC het doet, zodat we weer een pc voor een stagiaire hebben.

Thuis zou ik trouwens ook geen tijd gaan besteden om uit te zoeken waarom het kapot is, maar gewoon opnieuw installeren, alle belangrijke zaken staan toch op de NAS

[Hoogie2004]

Pfff, soms.....
SharePoint 2010 en MySites in combinatie met Site Stapling wil nog niet echt...

[.oisyn]

H!GHGuY schreef op zondag 26 december 2010 @ 16:16:
In C++ zijn er echter wel andere mogelijkheden

C++:

// C++ 0x
auto compose(ResultOuter (*f)(ResultInner), ResultInner (*g)(Param)) ->
  std::function<std::result_of(f(g(Param())) (Param)>
{
  return [] (Param x) { f(g(x)); }
}

Die result_of heb je niet nodig, je weet al dat dat ResultOuter is. Ook werkt dit helaas alleen maar met functiepointers, maar voor de generieke case is het jammer dat Param dan niet deducable is, en die zul je dus expliciet op moeten geven.

Wat dat betreft vind ik het ook een erg gemis van de huidige C++0x lambda spec dat de volledige function signature op geen enkele manier deducable is, zoals dat in C# wel het geval is. Terwijl dat toch vrij makkelijk te doen is als je elke lambda (en function object) laat deriven van functionsig<T,SIG> met T het daadwerkelijke type en SIG het signature.

C++:

template<class F, class FResult, G, class GResult, class Param>
std::function<FResult(Param>>
Compose(std::functionsig<F,FResult(GResult)> & f, std::functionsig<G,GResult(Param)> & g)
{
    return [&](Param p) { f(g(p)); };
}

Dan kun je ook overloaden op de lambda die je meegeeft:

C++:

template<class F> void Foo(std::functionsig<F, void(int)> & f)
{
    f(34);
}

template<class F> void Foo(std::functionsig<F, void(const char *)> & f)
{
    f("Hello World");
}

int main()
{
    Foo([](const char * str) { std::cout << str << std::endl; });
}

[RayNbow]

.oisyn schreef op dinsdag 28 december 2010 @ 11:05:
*snip*

Virtuele bonuspunten toegekend.
(Met een kleine aantekening. Zie einde van m'n post )

R4gnax schreef op dinsdag 28 december 2010 @ 11:14:
[...]

De tweede expressie is stateful, vanwege de find5 variabele die via een closure bereikbaar is. Wanneer je de resulterende IEnumerable meerdere keren evalueert kan deze met een andere start waarde een ander resultaat opleveren.

Hier had ik nog niet aangedacht. Echter, als ik het volgende test:

C#:

public static IEnumerable<int> SoCalledOptimized(IEnumerable<int> xs)
{
    bool find5 = false;
    return xs.Where(p => p == 1 && !(find5 = (p == 5) ? true : find5));
}

static void Main(string[] args)
{
    var xs = new int[] { 1, 1, 2, 3, 4, 5 };
    var q = SoCalledOptimized(xs);
    foreach (var x in q)
    {
        Console.WriteLine(x);
    }
    foreach (var x in q)
    {
        Console.WriteLine(x);
    }
    Console.ReadKey();
}

Dan krijg ik wel de juiste output.

Verder ben ik het eens met .oisyn. Die optimalisatie zal bij grotere sets elementen zeker niet sneller zijn, omdat de eerste expressie met TakeWhile() de resultaat set meteen een flink stuk kan limiteren alvorens Where() aan de slag gaat.

Daarom zei ik ook dat het in een microbenchmark sneller was. Dat was een redelijke kleine lijst met de 5 ergens in het buurt van het midden.

De user die de optimalisatie voorstelde had het over een factor 2 verschil in de benchmark (op zijn computer).

* RayNbow ziet nu trouwens pas dat die user z'n antwoord verwijderd heeft op StackOverflow...

Wat .oisyn verder schrijft klopt ook: bij het behandelen van een oneindige reeks loopt de optimalisatie oneindig door terwijl de eerste expressie netjes stopt op het stop criterion in TakeWhile().

Ook hier de bonuspunten toegekend.
(Met een kleine aantekening. Zie einde van m'n post )

Drie problemen met de optimalisatie dus:

• Stateful expressie levert ander resultaat bij her-evaluatie.

Kan ik iig niet reproduceren, maar misschien kan jij wel een codevoorbeeld vinden waarin dit wel gebeurt.

• Ondersteunt oneindige reeksen niet.

Juist.
(Met een kleine aantekening. Zie einde van m'n post )

• Het is waarschijnlijk in de average case helemaal geen optimalisatie.

Zou best kunnen.

De kleine aantekening m.b.t. oneindige reeksen:
De "geoptimaliseerde" versie werkt wel op oneindige reeksen waar geen 5 in voorkomt.

[ Voor 0% gewijzigd door RayNbow op 28-12-2010 13:15 . Reden: formatting ]

[.oisyn]

RayNbow schreef op dinsdag 28 december 2010 @ 12:03:
Kan ik iig niet reproduceren, maar misschien kan jij wel een codevoorbeeld vinden waarin dit wel gebeurt.

Duh, jij geeft die bool een aparte scope door het in een extension method te gieten. Als je de Where direct vanuit Main() had aangeroepen dan had je wel een probleem gehad

[RayNbow]

.oisyn schreef op dinsdag 28 december 2010 @ 12:06:
[...]

Duh, jij geeft die bool een aparte scope door het in een extension method te gieten.

Het is geen extension method.

Als je de Where direct vanuit Main() had aangeroepen dan had je wel een probleem gehad

In m'n oorspronkelijke post had ik al een return in de code staan, dus ik dacht het duidelijk was dat het om code in een methode ging.

[YopY]

Gatverdamme, die koffie is niet te zuipen!


Autobar, ik haat u! Sterf!

[Matis]

YopY schreef op dinsdag 28 december 2010 @ 13:59:
Gatverdamme, die koffie is niet te zuipen!


Autobar, ik haat u! Sterf!

Ik drink die bocht al in geen maanden meer. Ik kreeg er echt buikpijn van

Sindsdien neem ik mijn eigen Senseo-pads mee naar het werk. Dat werkt een stuk beter

[Verwijderd]

Wat een graftakkedag vandaag! Krijg echt niks uit m'n vingers... Misschien toch 3de kerstdag wat minder uitgebreid moeten bieren... Lag om 03:30 met de WC-pot te kroelen

[ Voor 13% gewijzigd door Verwijderd op 28-12-2010 14:48 ]

[Gamebuster]

Verwijderd schreef op dinsdag 28 december 2010 @ 14:41:
Wat een graftakkedag vandaag! Krijg echt niks uit m'n vingers... Misschien toch 3de kerstdag wat minder uitgebreid moeten bieren... Lag om 03:30 met de WC-pot te kroelen

Jij bent tenminste geen 10 kilo afgevallen in 2 weken i.v.m. ziekte en gebrek aan eetlust.

[.oisyn]

Hoezo, "tenminste"? Ik wil best even 2 weken ziek zijn en daardoor 10 kilo afvallen. Lekker makkelijk

[Devilly]

.oisyn schreef op dinsdag 28 december 2010 @ 15:11:
Hoezo, "tenminste"? Ik wil best even 2 weken ziek zijn en daardoor 10 kilo afvallen. Lekker makkelijk

Het nadeel is dat die tien kilogram niet zomaar wegblijven op het moment dat je je oude levenswijze weer oppakt. Zo gezien heeft hij wel een punt.

[Matis]

Ik val soms 2 kilo af in ongeveer 15 minuten. Dat is ook geen pretje

[Woy]

Matis schreef op dinsdag 28 december 2010 @ 15:18:
Ik val soms 2 kilo af in ongeveer 15 minuten. Dat is ook geen pretje

Het lucht anders best wel op

[Verwijderd]

Devilly schreef op dinsdag 28 december 2010 @ 15:16:
[...]


Het nadeel is dat die tien kilogram niet zomaar wegblijven op het moment dat je je oude levenswijze weer oppakt. Zo gezien heeft hij wel een punt.

Het vervelende is ook dat je lichaam relatief meer spiermassa opgegeten heeft als bron voor eiwitten. Dit betekent dat je lichaam minder brandstof nodig heeft. Als je je eetgewoontes daar niet op aanpast zul je juist weer harder aankomen. Het jojo-effect.
Als je goed wil afvallen wil je krachttraining (eventueel gecombineerd met joggen) doen om spiermassa aan te zetten en gewoon goed, gevarieerd en veel eten. Uithongeren is niet zinvol voor de langere termijn en je lichaam heeft gewoon brandstof nodig om goed te kunnen functioneren.

[ Voor 4% gewijzigd door Verwijderd op 28-12-2010 15:28 ]

[YopY]

Matis schreef op dinsdag 28 december 2010 @ 14:36:
[...]

Ik drink die bocht al in geen maanden meer. Ik kreeg er echt buikpijn van

Sindsdien neem ik mijn eigen Senseo-pads mee naar het werk. Dat werkt een stuk beter

Mwa, senseo ben ik ook niet een grote fan van. Het is beter dan deze rommel, maar de echte koffiepot die de ICT afdeling een verdieping onder ons heeft is beterder .

[Devilly]

Verwijderd schreef op dinsdag 28 december 2010 @ 15:26:
[...]

Het vervelende is ook dat je lichaam relatief meer spiermassa opgegeten heeft als bron voor eiwitten.

Is dat niet alleen zo in het geval dat je je verhoudingsgewijs veel inspant? Voor zover ik me nog kan herinneren, haalt je lichaam anders alle benodigde stoffen zoveel als mogelijk uit je reserves (lees: zwembandjes ).

[Verwijderd]

Je lichaam is juist super zuinig op vet en wil spiermassa in bepaalde situaties snel kwijt. Bekijk het zo: stel dat je in een situatie terecht komt waarin weinig voedsel voor handen is, is spiermassa niet handig, want het heeft meer energie nodig dan vet, dus is het om te overleven beter dat je lichaam spiermassa afbreekt.

[ Voor 11% gewijzigd door Verwijderd op 28-12-2010 16:26 ]

[Alex)]

Vraagje, zijn er hier mensen die ervaring hebben met Telerik's JustMock?

[wackmaniac]

Verwijderd schreef op dinsdag 28 december 2010 @ 14:41:
Wat een graftakkedag vandaag! Krijg echt niks uit m'n vingers... Misschien toch 3de kerstdag wat minder uitgebreid moeten bieren... Lag om 03:30 met de WC-pot te kroelen

Hier een volwaardig overwinningsgevoel; nokkievol bakkie koffie omgegooid en werkelijk niets geraakt! Geen papier, geen elektronica, nog geen pen. Dan weet je hoe Superman zich voelt; onoverwinnelijk!

[Davio]

wackmaniac schreef op dinsdag 28 december 2010 @ 16:56:
[...]


Hier een volwaardig overwinningsgevoel; nokkievol bakkie koffie omgegooid en werkelijk niets geraakt! Geen papier, geen elektronica, nog geen pen. Dan weet je hoe Superman zich voelt; onoverwinnelijk!

Ik heb ook wel eens dat ik iets aanstoot, het probeer te redden en daarom juist omflikker, dat is dan weer minder.

[Verwijderd]

als er bij mij wat omflikkerd dan zit 1 van de collega's meestal onder de koffie
tja als ik enthousiast word dan wil ik nog wel eens zwaaien met mn armen om iets uit te drukken.

maar ik maak geen onderscheid. alles gaat om: kop koffie of de hele kan met koffie

ik kom eigenlijk altijd zonder koffie vlekken uit de strijd

[jip_86]

YopY schreef op dinsdag 28 december 2010 @ 15:58:
[...]


Mwa, senseo ben ik ook niet een grote fan van. Het is beter dan deze rommel, maar de echte koffiepot die de ICT afdeling een verdieping onder ons heeft is beterder .

Als ICT-er prefereer het krijgen van koffie met een druk op de knop boven de regelmatig lege koffiekan en vervolgens weer een kwartier kunnen wachten.

[farlane]

wackmaniac schreef op dinsdag 28 december 2010 @ 16:56:
Hier een volwaardig overwinningsgevoel; nokkievol bakkie koffie omgegooid en werkelijk niets geraakt! Geen papier, geen elektronica, nog geen pen. Dan weet je hoe Superman zich voelt; onoverwinnelijk!

Meh, heb afgelopen maand 2 toetsenborden vermoord met ellebogenkoffie ...

[Devilly]

Verwijderd schreef op dinsdag 28 december 2010 @ 16:23:
Je lichaam is juist super zuinig op vet en wil spiermassa in bepaalde situaties snel kwijt. Bekijk het zo: stel dat je in een situatie terecht komt waarin weinig voedsel voor handen is, is spiermassa niet handig, want het heeft meer energie nodig dan vet, dus is het om te overleven beter dat je lichaam spiermassa afbreekt.

Dat klinkt logisch, maar dit volgens mij ook: vet is voor het lichaam moeilijker om te zetten in energie dan spier, waardoor dit ook langer duurt. Op het moment dat jij je intensief inspant, heeft je lichaam snel energie nodig en zal daardoor eerst naar de spieren grijpen. Bij handelingen die minder energie vergen, heeft je lichaam meer tijd om de benodigde energie te produceren en dan is het vet dus aan de beurt. Dat is ook de reden dat vaak wordt aangeraden om op een rustig tempo langdurig te sporten als je wilt afvallen.

Ik ga trouwens niets zeggen over wie gelijk heeft en wie niet, want daarvoor heb ik hier te weinig kennis van.

[Verwijderd]

farlane schreef op dinsdag 28 december 2010 @ 20:05:
[...]


Meh, heb afgelopen maand 2 toetsenborden vermoord met ellebogenkoffie ...

Waarschijnlijk wel van die goedkope dell meuk, dat gebeurde bij mij laatst namelijk...

[whoami]

Ik ben van plan een smartphone aan te schaffen, maar zit een beetje te twijfelen welk platform ik zou kiezen: Android of Win Phone 7.
Ik lees dat mensen het een nadeel vinden dat Phone7 geen multitasking ondersteund, en dat dit als een gemis wordt ervaren. Anderszijds schijnt het wel een leuke UI te hebben, maar is het soms traag (?).
Android heeft natuurlijk als voordeel de goede integratie met alle Google Stuff ...

Nu, ik wil natuurlijk ook kunnen software kunnen schrijven voor op het toestel. Ik heb begrepen dat je voor WinPhone7 met Silverlight & XNA aan de slag kunt.
Op Android is dat met Java ?

Ik wil zowiezo webservices kunnen benaderen met die apps die ik wil schrijven; veronderstel dat dat wel mogelijk is ?

[roy-t]

WP7 doet aan tombstoning, je kunt dus wel 'alt-tabben' je applicatie pauzeert dan. Verder kunnen applicaties wel een soort kleine taakjes doen terwijl ze niet actief zijn.

Het niet multi-tasken is wat Apple 'wel-multitasken' noemt. Het is niet puur multi-tasken, maar van een telefoon gebruikers perspectief is het geen verschil.

Webservices benaderen is zeker mogelijk.

Verder gebruik je idd XNA (meer geschikt voor 3D applicaties/games) en Silverlight(meer voor 2D games en normale programmas), maar onderliggend is het allemaal C#, wat erg lijkt op JAVA.

[ Voor 26% gewijzigd door roy-t op 28-12-2010 21:51 ]

[whoami]

C# & Java kan ik wel van elkaar onderscheiden.

[.oisyn]

whoami schreef op dinsdag 28 december 2010 @ 21:33:
Anderszijds schijnt het wel een leuke UI te hebben, maar is het soms traag (?).

Traag? Veel 3rd party apps ervaar ik wel als traag, maar volgens mij is het gewoon een kwestie van je XAML optimaliseren, wat nog te weinig gebeurt. Het ding is snel zat om alle animaties vloeiend te krijgen, volgens mij cachen mensen te weinig naar bitmaps (louter transformatie-animaties worden bijna geheel op de GPU uitgevoerd).

Dit merk ik ook met m'n eigen FreeCell clone. De graphics van een kaart zijn namelijk gewoon geheel gedefinieerd met XAML en databindings (fantastisch dat de suit-symbolen gewoon unicode codepoints hebben ), maar rendering (van font, lijnen, vlakken en gradients e.d.) gebeurt in eerste instantie gewoon in software op de CPU. En dan neemt het renderen van het volledige speelveld iets van 1 a 2 seconden in beslag. Zou ik elke kaart cachen naar een bitmap dan kun je ze makkelijk met 60fps laten animeren.

Android heeft natuurlijk als voordeel de goede integratie met alle Google Stuff ...

Waar doel je dan precies op? Ik mis idd nog een Google Maps, maar verder is de integratie met google prima via exchange activesync. Ik sync m'n mail, agenda en al m'n contacten met m'n Google account.

[ Voor 24% gewijzigd door .oisyn op 29-12-2010 00:59 ]

[whoami]

.oisyn schreef op dinsdag 28 december 2010 @ 22:27:


Waar doel je dan precies op? Ik mis idd nog een Google Maps

Bing Maps ?

[.oisyn]

Sucks . Seriously, ik vind het een van de grotere minpunten van WP7, en hoop heel erg dat dat wordt verbeterd. Ten eerste heeft het geen specifieke search, je hebt de algemene search die ook op web zoekt, en die vindt maar bar weinig adressen in NL (en met de verkeerde locale instellingen zelfs helemaal niet nou vraag ik je, waarom hangt dat in hemelsnaam af van je locale? Als je op vakantie gaat pas je de locale van je telefoon toch niet aan?), en op veel punten klopt de kaart van NL niet eens (hij zegt bijvoorbeeld dat waar Maarssen ligt eigenlijk Kockengen ligt, en Maarssen ligt vervolgens in the middle of knowhere op een snelweg. De straatnamen kloppen wel though).

Maar ik zie Google Maps eigenlijk ook wel gewoon zelf een WP7 app maken, ze hebben immers ook een iPhone app.

[ Voor 9% gewijzigd door .oisyn op 28-12-2010 23:05 ]

[Hillie]

Google maps werkt op blackberry ook heel goed.

jip_86 schreef op dinsdag 28 december 2010 @ 19:09:
Als ICT-er prefereer het krijgen van koffie met een druk op de knop boven de regelmatig lege koffiekan en vervolgens weer een kwartier kunnen wachten.

Gewoon hondelullen van collega's dus. Waar ik normaal werk wil men ook nogal eens weglopen als men de laatste koffie heeft gepakt. Nieuwe koffie aanzetten kost 30 seconden (filter vullen, kan onder apparaat, knopje drukken), wachten op nieuwe koffie 5 minuten. Ik loop altijd hartgrondig te vloeken als er weer een lul te lam was om nieuwe te zetten.

[ Voor 3% gewijzigd door Hillie op 28-12-2010 23:08 ]

[whoami]

Is zo'n GPS functie op een smartphone eigenlijk bruikbaar ? Ik bedoel hiermee: is het doenbaar om te gebruiken in de auto ? of heb je toch een dataconnectie nodig ?

[.oisyn]

Geen idee, ik had TomTom op m'n vorige mobiel (dus met lokale kaarten) en die gebruikte ik altijd voor navigatie. Google Maps slingerde ik vooral aan als ik iets specifieks zocht in de buurt.

[Alex)]

Ik gebruik Google Maps Navigatie vrij regelmatig binnen NL, en dat werkt gewoon echt heel goed. De dataconnectie heb je inderdaad wel nodig (wat niet zo handig is in het buitenland) maar met mijn FUP-Vodafone-verbinding binnen NL hoor je mij niet klagen.

Daarvoor had ik TomTom op mijn E-ten X500 en Xperia X1 en dat werkte ook erg goed.

[Verwijderd]

Met bepaalde mods op google maps (voor android iig te verkrijgen) kun je de maps cachen. Alleen de route-berekening wordt volgens mij door google servers gedaan, en niet door google maps zelf. Dus dataconnectie heb je altijd nodig.
Het enige nadeel met navigatie van google maps is dat het soms nog wel fout zit.

[Uchiha1911]

Hey Tweakers!

Ik zit nu in 5VWO en mijn interesse in de informatica en vooral in het programmeren begint steeds groter te worden. Daarom wil ik ook de stap gaan nemen om voor mezelf te beginnen met programmeren. Ik heb op internet al wat rondgekeken wat de beste programmeertaal zou zijn om mee te starten. Vaak kwam ik uit op Python. Heeft iemand hier een andere mening over? Ben je het hier mee eens: waarom is Python een goede opstap? Heb je een andere mening: wat is volgens jou de beste taal om mee te beginnen?

[ZaZ]

If Windows; gewoon lekker met C# beginnen.
Plenty info, met de hottest items zijn voorbeelden van te vinden, OO...
Wil je daarna een kijk onder de motorkap nemen, kan dat altijd nog met een andere taal.

[Boudewijn]

ZaZ schreef op woensdag 29 december 2010 @ 02:14:
If Windows; gewoon lekker met C# beginnen.
Plenty info, met de hottest items zijn voorbeelden van te vinden, OO...
Wil je daarna een kijk onder de motorkap nemen, kan dat altijd nog met een andere taal.

Want? Waarom is C# zo tof dan?


Imo is python wel interessant omdat het redelijk vernieuwend is, maar dat is C# ook.
Voordeel is wel dat het allemaal stukken lichter is en je niet van windows afhankelijk bent.

[RayNbow]

whoami schreef op woensdag 29 december 2010 @ 00:34:
Is zo'n GPS functie op een smartphone eigenlijk bruikbaar ? Ik bedoel hiermee: is het doenbaar om te gebruiken in de auto ? of heb je toch een dataconnectie nodig ?

Het is doenbaar zolang je een GPS signaal hebt. Er zijn wel eens toestellen met een niet al te beste GPS chip. Mijn oudeTouchPro2 deed het vaak wel, maar het is best vervelend wanneer je GPS signaal wegvalt wanneer je 'm het meest nodig hebt (bijv. midden in de stad).

[Jan_V]

Wil een base class toevoegen voor m'n views, maar krijg continu de melding dat een partial class niet van verschillende base klassen kan overloaden. Ja, logisch, maar ik kan de andere gedeelte van de partial class niet vinden. Waarschijnlijk bouwt MVVM Light onderwater nog het een en ander (designer/resource file?).

Dit is een van de redenen waarom ik zo'n hekel hem om frameworks te gebruiken. Minder controle en overzicht op de uitgevoerde code.