Page 1 of 5 1 2 3 ... LastLast
Results 1 to 15 of 66

Thread: Het Einde van Delphi?

  1. #1

  2. #2
    Fornicatorus Formicidae VideoRipper's Avatar
    Join Date
    Mar 2005
    Location
    Vicus Saltus Orientalem
    Posts
    5,708
    Ben ik er een voorstander van: nee, maar ik weet van mezelf dat ik conservatief ben.

    Ik heb vernomen dat ze in Delphi 11 de lastige lange woorden begin en end willen gaan vervangen door accolades.
    TMemoryLeak.Create(Nil);

  3. #3
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    En in 12 implementatie en interface in een aparte files, en daarna dynamische typering :-)

    Er is over het doorlopende ge-me-too met C# features al veel discussie geweest. Persoonlijk denk ik dat ze gewoon de mensen niet meer hebben voor echte features, en dat development puur management/marketing gedreven is.

    Moeten we nog een featuretje implementeren om de release voor de huidige subscriptie cyclus een nieuwe glans te geven? Pak de makkelijkste maar van de user list (die vn door studenten ingevuld worden die niks anders kennen behalve javascript)

    Om dat conservatief te nuanceren: het is een ding om een feature zoals dit te hebben in een taal waarbij het in het algehele ontwerp ingedesigned is. Daar kan je een mening over hebben.

    Zelf ben ik daarover zelfs verrassend neutraal, vooral als er wat zinnige beperkingen op zitten, want oud, ongestandarizeerd C was wel heel erg permissief.

    De meeste nieuwe {} talen limiteren het ook tot het begin van een {} blok zonder statements ervoor. De vrijheid blijheid optie vind ik niks, maar met de nieuwere variant kan ik leven, ook al prefereer ik de Pascal manier).

    Het ergste van dit soort features blijft dat mensen het krankzinnig ver gaan doordrijven ipv er spartaans gebruik van gaan maken alleen om te laten zien dat ze een "moderne" delphi hebben (of een 50 jaar oude C feature integreren in Delphi het "modern" maakt is mijns inziens twijfelachtig)

    Echter het is een totaal ander ding om dit in een toch al topzware taal in te passen na 35 jaar (1985 - Object Pascal voorstel door Apple).

    Zelfs als het antwoord op de vorige vraag over de feature in een nieuwe taal positief is, zal het antwoord hier typisch negatief zijn door iedereen die iets weet van Pascal/Delphi parsing.
    Last edited by marcov; 31-Oct-18 at 11:51.

  4. #4
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Met verbazing en interesse de blog gelezen.
    De typo in de blog "Inline Varaible Declarations" geeft mij alweer een rillerig gevoel hahaha.
    De nieuwe syntax zal wel weer eerst 3 versies lang van bugs ontdaan moeten worden (net als de (constante) dynamische arrays syntax nog steeds buggy en onduidelijk is).

    Wanneer het goed geoptimaliseerd is en inderdaad 100% foutloos en intuitief werkt vind ik het toch wel een vooruitgang:
    het heeft de potentie code leesbaarder en compacter te maken.

    In het voorbeeld van Cantu zien we:

    Code:
    procedure NewTest;
    begin
      var MyDictionary := TDictionary<string, Integer>.Create (de puntkomma schijnt ook achterhaald te zijn)
      MyDictionary.Add ('one', 1);
      var APair := MyDictionary.ExtractPair('one');
      ShowMessage (APair.Value.ToString)
    end;
    Ik neem aan dat we nog een MyDictionary.Free moeten doen, of niet???

    Waarom noem je het "Het einde van Delphi" Marco?
    Hoe het met pascal-parsing zit weet ik niet. In ieder geval gaat iedere pascal-parser op zijn gat vanaf de volgende versie.

    By the way: ik haat accolades in alle andere talen. Alleen als je 4 spaties inspringt en veel lege regels toevoegt blijft het enigszins leesbaar.

    Verwarrend vind ik wel
    Code:
    var
      i: Integer := 22;
    Dit is dan weer niet intuitief anders dan wanneer je dit in globale scope gebruikt...

    Code:
    implementation
    var xxx: integer = 22;
    Last edited by Anoniem; 31-Oct-18 at 12:35.

  5. #5
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Leesbaarder zeker niet. Wat is het type van apair? En dan is dat nog maar een 4 regel voorbeeld.

    Je kan alles goed proberen te praten, maar ik zie hier met de beste wil van de wereld niks positiefs in.

    Het einde van Delphi omdat de blokvorm een kern taal principe is, en ook omdat Embarcadero blijkbaar niks anders meer kan doen dan de meest domme copy-syntax implementeren in de hoop dat het mensen over de streep trekt om te updaten. Impuls aankoop marketing filosofie toepast op development tools.

  6. #6
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    De "type inference" is inderdaad een item. Je kunt het type niet meer direct zien. Dat vind ik code-technisch gezien een enorm nadeel en moet m.i. altijd vermeden worden. Meestal is het luiheid van de programmeur, zoals ik in veel C# code zie.
    Code onleesbaar maken kan altijd. Zoals wij allen waarschijnlijk weten.
    Wat de verkoopstrategie is weet ik niet, maar netto gezien lijkt het mij toch een vooruitgang. Misschien kom ik hier later op terug :-)
    Ik maak mij het meest zorgen over dat het niet direct foutloos geimplementeerd is.

  7. #7
    Het lijkt er op alsof Embarcadero Delphi wil moderniseren aan de standaard van de huidig jonge ontwikkelaars. Niet verkeerd bedoeld maar Delphi lijkt langzaamaan een taal voor fossiele ontwikkelaars. Apple kwam met Swift dat sterk op C# lijkt. Wellicht maakt Embarcadero een gelijksoortige keuze.
    Onmogelijk... Is geen feit, maar een mening.

  8. #8
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Hebben ze dat niet al twee keer gedaan? Delphi.NET en Prism. Beide geen success.

    Ik denk sowieso dat ze er de resources (en belangrijker, wil van investeerders) niet voor hebben. Prism was al ingekocht, dus ik denk niet dat dit een voorteken is van een taal die aan jonge developers appelleert. EN dan hebben we het nog niet eens over of die er dergelijke bedragen voor over zullen hebben.

    Er is een reden waarom populaire development tools bij de grote IT bedrijven zit (Oracle Microsoft,Google ). Die kunnen de vraag sturen met integratie met andere producten, en zitten niet om de centen verlegen. Niets van dit alles geldt voor Embarcadero.

    Ik denk dat dit is meer een "Polish the turd" actie is.

  9. #9
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by EricLang View Post
    Ik maak mij het meest zorgen over dat het niet direct foutloos geimplementeerd is.
    En verzwakking van de kwaliteit van de errorfoutmeldingen. Die zijn redelijk accuraat in Delphi, en een ramp in b.v. C++.

  10. #10
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Ik denk dat dit is meer een "Polish the turd" actie is.
    +1

    Dit gaat veel op JAVA lijken (en wat heb ik toch een t....g hekel aan die taal).
    Jonge mensen worden alleen opgeleid voor jonge talen zoals JAVA. Om pascal die richting in te sturen vraag ik mij stellig af de dit de JUISTE roadmap is.
    Je maakt compiler onnodig zwaar om dit te implementeren.

    Ik kan mij herinneren dat er op het Lazarus forum hier ook een topic over is gemaakt. Toen werd er verteld dat deze implementatie uit ten boze is en nooit gebruikt zal worden.

    Wordt leuk om een conversie te doen naar FPC

    Ik zag op die blog dat dit door iedereen werd omarmd. Waar zijn de echte programmeurs.......

    Nog even en Delphi is geen native language meer maar een interpreter met een runtime library (al bestaat dat al d.m.v. packages).
    Delphi is great. Lazarus is more powerfull

  11. #11
    Fornicatorus Formicidae VideoRipper's Avatar
    Join Date
    Mar 2005
    Location
    Vicus Saltus Orientalem
    Posts
    5,708
    Ik zou eigenlijk willen concluderen dat het de verloedering van onze geliefde taal is,
    net zoals dat bij de hedendaagse spreek- en schrijftaal het geval is.

    Genoemde inline variables hebben wel één gigantisch voordeel: je kunt code dan
    echt zo een-op-een koppie-peesten vanuit StackOverflow in je eigen project, zonder
    ook maar een idee te hebben hoe het werkt.
    TMemoryLeak.Create(Nil);

  12. #12
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Zelfs dat niet. Oppervlakkig syntax is simpel, het zit hem in de details. Het probleem zit hem niet in de niveau nul taal conversie, maar in het opsporen van de details.

    Op het FPC en andere forums krijgen we b.v. hordes kromme benchmarks van dit soort lieden. FPC is _of_ gigantisch veel sneller of langzamer. Dat is bijna altijd ook code die hetzelfde lijkt, maar net iets anders of minder snel of sneller werkt:

    90% van de gevallen is
    1. Een compiler als GCC of MSVC die sommige slechte fragmenten gewoon helemaal reduceert tot een constante.
    2. Een benchmark wordt gevoerd met random data, maar de generatie van random data zit in het benchmark en domineert het benchmark. Maar echte programma's draaien niet op random data :-) (en die enkele keer dat het al zo is, dan pak je een PRNG die snel is)
    3. Idem, maar dan memory manager bound. Threading of niet enz.
    4. String routines die vergeleken worden met Delphi 6/7, maar FPC3+ implementeert D2009 strings met hun conversie.
    5. De ene taal is 64-bit op windows, de andere is 32-bit of 64-bit op Linux. Je bent FPU SSE2 vs FPU x87 aan het benchmarken. (zie ook voorbeeld beneden)
    6. Een of andere grafisch georienteerde taal heeft sommige wiskundige primitieve redelijk direct naar de copro doorgelusd. Snel ja, maar niet hele domein wordt ondersteund


    Ter illustratie van het SSE2 vs x87: er kwam laatst een koekebakker met de volgende oude TP (of geporte QB code aanzetten om het aantal significante.

    Het principe is logisch, deel door twee tot het resultaat niet meer verandert, en tel het aantal iteraties.

    Delphi Code:
    1. program Project36;
    2.  
    3. {$APPTYPE CONSOLE}
    4.  
    5. VAR II: INTEGER;
    6. VAR ONE,TWO,U,EPSMACH: double;
    7. BEGIN
    8.    II:= 0;
    9.    ONE:=1.0; TWO:=2.0; U:=1.0;
    10.     REPEAT
    11.       U:=U/TWO;
    12.       II:=II+1;
    13.     UNTIL ( (ONE+U)=ONE );
    14.     EPSMACH := TWO*U;
    15.     writeln (II, EPSMACH);
    16.     readln;
    17. END.

    Compileer het Delphi in 32 en 64 bit mode en vergelijk het resultaat.

  13. #13
    Zoals veel van jullie weten ben ik na (ongeveer) een jaar of 15 Delphi overgestapt naar C#. En ja, ik vond de accolades en de inline variabelen best even wennen. Net als bij elke overstap naar een nieuwe taal bekroop me even de vraag waarom ik dit ook alweer aan het doen was. En net als elke overstap wist ik na een paar maanden niet beter en voelde het al snel vertrouwd.

    Ik wil zeker geen discussie beginnen over welke taal nou beter is, maar in het Delphi werk dat ik nog doe voelt het declareren van variabelen en methods als verplichte administratie: ik doe het omdat de compiler het nodig heeft, maar het voegt voor mij niets toe.

    De var x = 1 / int x = 1 discussie speelt ook onder C# programmeurs. Ik ben persoonlijk een groot voorstander van het eerste, ook hier weer omdat vooraf vertellen wat een variabele gaat worden voelt als overbodige administratie.

    Delphi als bestaande taal aanpassen naar accolades en inline variabelen? Ik denk dat het voor meertaligen misschien makkelijker maakt om de code te lezen, maar misschien kan ook juist de verwarring groter worden. Ik vind de = en := al zo lastig in mijn hoofd . Bovendien wordt de altijd weer religieuze discussie over coding guidelines nog weer lastiger. Kortom: ik twijfel heel erg of dit nou een hele goede stap is of juist niet.
    Marcel

  14. #14
    Senior Member
    Join Date
    Mar 2002
    Location
    Edam
    Posts
    426
    Het voordeel van een betere leesbaarheid staat of valt met het consequent toepassen. Combinatie van verschillende manieren in een project werkt niet echt leesbevorderend. Om chaos te vermijden bij doorontwikkeling of onderhoud van bestaande projecten dus eerst even alles omzetten naar de nieuwe vorm of consequent de nieuwe manier alleen toepassen op nieuwe projecten.... niet echt gunstig voor de leercurve.. en hoe zit het met de mix van stijlen in dezelfde procedure kan dat?... en accolades als vervanger van "begin end" werkt volgens mij ook niet vanzelf lekker samen met comments tussen accolades .

  15. #15
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Wat dacht je van een stukje code, die gemaakt is in 10.3, teruglezen naar oudere versies?
    Delphi is great. Lazarus is more powerfull

Page 1 of 5 1 2 3 ... LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •