C# og Visual Basic skal kunne klare sig uden .Net - og køre lige så hurtigt som C++

Illustration:
En af de nye funktioner til .Net-udviklere i Microsofts nye Universal Apps-fremstød er muligheden for lade applikationerne køre direkte på systemet uden det underliggende .Net-framework.

Applikationer, som starter hurtigere og bruger mindre hukommelse, er nogle af de argumenter, Microsoft vil bruge for at få de mange udviklere til Windows-platformen til at se nærmere på Universal Apps.

Universal Apps er den nye applikationsplatform i Windows 10, som bygger videre på Modern UI-applikationerne fra Windows 8. I dag er langt størstedelen af applikationerne til Windows baseret på enten et framework som .Net eller direkte til Win32-platformen.

Men Universal Apps giver mulighed for at få det bedste fra netop de to verdener med .Net Native, påpeger programchef Daniel Jacobson fra Microsoft i et blogindlæg.

Med .Net Native er det muligt at udvikle sin applikation som en almindelig .Net-applikation i C# eller Visual Basic, men få den oversat til binær kode, der kører direkte i Windows uden .Net. Det kan ifølge Microsoft forbedre opstartstiden for applikationen med 60 procent, og man vil kunne opnå samme ydelse som med applikationer skrevet i for eksempel C++.

Samtidig er det ikke nødvendigt for brugerne at have .Net-frameworket installeret på deres Windows-pc. Den kode, som applikationen har brug for fra .Net-biblioteker eller eksterne biblioteker, bliver inkluderet i applikationen, men vel at mærke kun de dele af bibliotekerne, som applikationen bruger.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (53)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Glenn Dufke

Det er imponerende at se Microsoft nu forsøger at begå det som Delphi og Object Pascal sproget har formået i mange år.
Delphi er native, hastighed er lig eller hurtigere end C++, kræver ikke noget eksternt framework eller runtime og så er den færdige eksekverbare fil, efter debug information er skrældet fra, ikke særligt stor.

Jeg er ikke imponeret.

// Rant off

  • 5
  • 13
Thomas Andersen

Wow, du er da en sur gammel(?) mand. Hvad er det du er sur over, for jeg forstår ikke dit indlæg?

Som jeg forstår ovenstående; så kan man vælge at lade sin universal app være universel=samme exe/dll kører på flere platforme, eller man kan vælge at compilere den til binær=exe/dll kan kun køre på én platform.
Det lyder da sådan set smart. Så jeg forstår ikke lige din rant, og hvad hulan det har med Delphi at gøre? (eller du er måske stadig bitter på Anders Hejlsberg?

  • 6
  • 4
Glenn Dufke

Ingen bitterhed her :)

Her er forklaringen:
Det som Microsoft forsøger nu er teknologi som vi i Delphi / Object Pascal verdenen har haft tilrådighed længe - også cross platform mellem flere arkitekture og operativ systemer.
Det formår micrsoft så at sælge som det nye sort.

Jeg er bestemt ikke bitter på Andes Hejlsberg, jeg har stor respekt for den mand og hvad han har formået at konstruere - også for microsoft, omend er jeg ikke enig med ham i hvordan C# rent teknisk er konstrueret, men det er en anden sag :)

Min rant bygger også lidt på at mange udviklere i dag ser Delphi / Object Pascal som et oldtidssprog, men det er i virkeligheden utroligt kraftfulgt og har mange af de samme features så som Generics og Anonymous Methods man kender fra de hotte sprog i dag.
Plus, compileren er sygt hurtig.

  • 4
  • 1
Bjarke I. Pedersen

Jeg er ikke imponeret.

Så fordi at andre har lavet noget som compiler til native kode, så har ingen andre lov...
Fordelen her er, at det samme bliver compilet til native kode, og sendt ned til brugeren, så det matcher deres processor arkitektur. (MSIL sendes til deres store, native kode sendes ned til brugeren).

Wow, du er da en sur gammel(?) mand. Hvad er det du er sur over, for jeg forstår ikke dit indlæg?

Det er let nok - tag et kig igennem hans tidligere kommentarer herinde, så tegner der sig et billede ;-)

  • 1
  • 2
Simon Moore Højer-Simonsen

Og hvad så hvis andre allerede kan det? Det er vel stadig en skridt i den rigtige retning (noget man vel skal være imponeret over når det er MS??).

For en som mig der hverken kender Delphi, C++ eller Object Pascal og bruger C# så er det det jo netop en forbedring på "op til" 60 % hvilket må siger at være en fordel.

  • 1
  • 0
Glenn Dufke

Og hvad så hvis andre allerede kan det? Det er vel stadig en skridt i den rigtige retning (noget man vel skal være imponeret over når det er MS??).

For en som mig der hverken kender Delphi, C++ eller Object Pascal og bruger C# så er det det jo netop en forbedring på "op til" 60 % hvilket må siger at være en fordel.

Ro på :)

Skal vi se det fra den konstruktive side, ja det er da et fornuftigt tiltag i Microsoft land.

Jeg tænker bare mit om hvorfor det skulle tage dem så lang tid at få kørt i stilling netop, ved at kigge på andre teknologier på markedet, allerede har disse features tilrådighed.

For de udviklere der baserer deres hovedinteresse på C# eller VB vil det på længere sigt være en fordel, det skal der heller ikke være nogen tvivl om :)

  • 2
  • 0
Glenn Dufke

Så fordi at andre har lavet noget som compiler til native kode, så har ingen andre lov...
Fordelen her er, at det samme bliver compilet til native kode, og sendt ned til brugeren, så det matcher deres processor arkitektur. (MSIL sendes til deres store, native kode sendes ned til brugeren).

Bjarke, jeg tror ikke helt du fanger min pointe.

Det handler ikke om hvem der må og ikke må hvad men i bund og grund om hvorfor det skal tage Microsoft så lang tid at få så essentiel feature på plads i deres udviklingssytem når andre teknologier på markedet allerede har sådanne features.

Bare tag Free Pascal Compileren, den er open source og formår at compile den samme Object Pascal kode til flere forskellige processore og operativsystemer uden problemer - ren nativ kode. :)

  • 2
  • 0
Bjarke I. Pedersen

Det som har taget lang tid for dem har ikke været at få C# -> Native til at virke (De har selv omtalt, at det stort set blot var at sætte deres VC++ backend ind bagefter deres C# compiler).

Det som har taget tid har været at få deres runtime og base class library klart til at kunne klare det. (Selvom det er native kører det stadigvæk i .NET, på den måde at der stadigvæk er garbage collection osv. - koden er blot direkte native i stedet for at være MSIL, som så JIT compiles af brugeren).

  • 0
  • 0
Troels Henriksen

Delphi er native, hastighed er lig eller hurtigere end C++

Har du dokumentation for dette? Fra et oversættersynspunkt minder Delphi og C/C++ ret meget om hinanden, så ydelsesforskelle mellem tilsvarende programmer ville nok tilskrives kvaliteten af oversætterens optimeringstransformationer - og her er der immervæk brugt mere tid og penge på C/C++-oversætterne (omend man nok bare kunne bruge LLVM som bagende for en Delphi-oversætter).

  • 2
  • 0
Glenn Dufke

Har du dokumentation for dette? Fra et oversættersynspunkt minder Delphi og C/C++ ret meget om hinanden, så ydelsesforskelle mellem tilsvarende programmer ville nok tilskrives kvaliteten af oversætterens optimeringstransformationer - og her er der immervæk brugt mere tid og penge på C/C++-oversætterne (omend man nok bare kunne bruge LLVM som bagende for en Delphi-oversætter).

Delphis codegen er faktisk skrevet i C++ og benytter samme underlæggende compiler som C++ Builder.

I Delphi Next træet bruger de faktisk en LLVM backend, primært til generering af kode til iOS og Android, men det er embarcaderos langsigtede mål at kunne generere kode til bla OSX, Windows, Linux osv fra samme compiler backend.

Free Pascal Compileren er i modsætning skrevet i object pascal og er i stand til at compile sig selv :)

  • 0
  • 0
Troels Henriksen

Delphis codegen er faktisk skrevet i C++ og benytter samme underlæggende compiler som C++ Builder.

Det er ikke væsentligt hvilket sprog kodegeneratoren er skrevet i (en kodegenerator skrevet i shell script kunne sagtens generere fantastisk kode). Jeg kan ikke umiddelbart finde nogen afprøvninger af ydelsen af den kode som C++ Builder genererer (!!!), men det ville undre mig hvis den var på højde med mere populære oversættere.

Tilføjelse: Jeg kan finde nogle antydninger af at Delphi/C++ Builder ikke understøtter autovektorisering via brug af f.eks. SSE-instruktioner, hvilket er en voldsom mangel når det kommer til at optimere løkker.

  • 2
  • 0
Christian Nobel

Jeg er stadig forvirret... Kan Delphi lave én exe/dll der kan køre på flere platforme, eller findes der en anden Object Pascal compiler der kan?

Ja, FreePascal (og så er der altså ikke noget der hedder en exe fil under andre OS', det er lidt mere sofistikeret, da OS'et detekterer om vil taler om en fil der kan afvikles - extension er underordnet).

Og hvis man ønsker et Delphi'sh IDE, så hedder det Lazarus.

  • 0
  • 1
Christian Nobel

Så man kan ikke bruge Delphi til det? Så må det være "Det er imponerende at se Microsoft nu forsøger at begå det som Delphi og Object Pascal sproget har formået i mange år." der er fis i en hornlygte?

Er det noget med du er vildt langt ude i flueknepperi, eller du bare ikke vil forstå?

Delphi har i årevis (altid) været i stand til at kompilere direkte til en exe fil på en Windows platform, sådan at der ikke er behov for noget framework på afviklingsmaskinen.

Object Pascal ligeledes, men her er der så også den mulighed at der kan kompileres til andre platforme end Windows, og andre arkitekturer end X86/X64.

Og jeg læser intetsteds i ovenstående at MS forholder sig til andet end Windows, bare uden .Net.

  • 0
  • 2
Lars I. Nielsen

Synes bestemt jeg kan erindre, at Microsoft i slut-halvfemserne lovpriste scriptbaseret programmering (ASP) til web, og fnøs af mere "projekt-orienterede" værktøjer, hvorefter de skiftede hest til ASP.net og Visual Studio, et - (drum roll) - projektorinteret værktøj, og nu mente, at scriptbaserede websites var helt forældede.

Men godt at Microsoft nu også tilbyder helt ægte "Zero Impact Deployment" distribution som en option. Håber ikke det vil medføre alt for meget "bloatware" derude.

  • 0
  • 0
Thomas Andersen

Er det noget med du er vildt langt ude i flueknepperi, eller du bare ikke vil forstå?


Det er det første indlæg af Glenn jeg ikke kan/vil forstå? Og jeg forstår heller ikke hvorfor du hele tiden svare i stedet for han selv gør?

Glenn skrev: "Det er imponerende at se Microsoft nu forsøger at begå det som Delphi og Object Pascal sproget har formået i mange år."

Men det er jo noget sludder, for det har intet med hinanden at gøre.

Jeg genere ikke Delphi eller Object Pascal, jeg er faktisk fuldstændigt ligeglad med det. Det jeg ikke forstår er hvori sammenligningen er med artiklen?

Men fint nok, I har fået promoveret jeres platform. Så mission accomplished.

  • 0
  • 1
Niels Henriksen

Det er fedt at Microsoft vil til at gøre det som man kan med Delphi - altså kompilere et projekt så det ikke behøver andre biblioteker.

Men at få det til at køre på andre platforme vil være stærkt. Jeg ser nu muligheden for at Microsoft kan på sigt erstatte Java ned .NET i Minecraft

  • 0
  • 0
Michael Cederberg

Tag et kig her fx:
http://blog.digitaltundra.com/?p=348

Som du kan se er det ikke meget der skiller dem ad.

Nu er testen du refererer til ikke specielt interessant. Den tester specifikt hvordan nogle integer operationer bliver optimeret og det er ikke det der tager lang tid på en moderne CPU.

Istedet skulle man lave tests der var mere memory intensive idet det der er dyrt på en moderne CPU. Og specielt burde man også kigge på "dynamic dispatch" situationer som ofte ender med at være normen i Java/C# men kan undgås i C++ (ved ikke nok om Delphi).

Og selv det ikke engang særligt interessant. Det interessante er hele økosystemet omkring "sproget" (libraries, tools, etc.). Og for performance: Hvor nemt er det at lave parallelle/distribuerede løsninger (for der er her den den store performance gevinst er).

  • 0
  • 0
Thomas Andersen

Øh, bøh, kan benytte .Net under eksempelvis Linux, BSD, Unix, OS/2, OSX, Android, og på Arm eller Mips arkitektur?
Eller har du ikke helt forstået hvad man mener med forskellige platforme?


Kære ven, men kan køre .Net på alle de platforme hvor det er lavet. Og nej, det er ikke alle dem du nævner, men det kunne det være, hvis der var et .Net framework.

Du har da forstået ideen i .Net ikke? Og hørt om f.eks Xamarin og Mono?

  • 0
  • 1
Christian Nobel

Og selv det ikke engang særligt interessant. Det interessante er hele økosystemet omkring "sproget" (libraries, tools, etc.). Og for performance: Hvor nemt er det at lave parallelle/distribuerede løsninger (for der er her den den store performance gevinst er).

Og kompleksiten omkring det at lave et program (for det er jo i bund og grund det det drejer sig om).

Vi må også have så meget selverkendelse og se i øjnene at vi ikke alle har en IQ som Stephen Hawkings, hvorfor vi ofte kvajer os eller mister overblikket.

Så jeg foretrækker personligt at have en god og rigoristisk compiler som fanger mange fejl, og et programmeringssprog der gør programmering/programmet overskuelig.

Så hvis man kan skrive et Pascal program der fylder en tredjedel af et tilsvarende C program, er mere overskueligt og velstruktureret, samt man undgår at pointe sig lige ned i helvede, for slutteligt at ende med noget der ikke er langsommere, ja så fortrækker jeg klart det.

Snakken om hyper-duper optimeret hastighed er imo relativ teoretisk, det er resultatet der tæller.

  • 1
  • 1
Christian Nobel

Og nej, det er ikke alle dem du nævner, men det kunne det være, hvis der var et .Net framework.

Ja hvis - og hvis min bedstemor havde haft hul i ryggen kunne vi bruge hende som sparegris.

Du har da forstået ideen i .Net ikke? Og hørt om f.eks Xamarin og Mono?

Selve MS' ide i .Net var vel ikke nødvendigvis at det skulle bruges til andet end Windows - at tredjeparter som Xamarin og Mono så prøver at samle op er en anden sag, og ikke altid med den helt store succes.

  • 0
  • 1
Christian Nobel

Kan det samme ikke siges om Object Pascal?

Det vil jeg ikke sige, for eksempelvis FreePascal er et community drevet projekt, der som udgangspunkt ikke fastlagt fra en bestemt vinkel eller dikteret af en producent, hvorimod Xamarin og Mono er lavet for at kunne kompilere (ikke altid med succes) programmer der tager afsæt i .Net og dermed er kontrolleret af kun en part.

Xamarin og Mono er lidt en slags stedbarn i dette spil.

Endvidere kompileres Object Pascal jo direkte ned mod jernet, så der er ikke behov for de underliggende frameworks.

Imo er det to helt forskellige angrebsvinkler.

  • 1
  • 1
Troels Henriksen

Imo er det to helt forskellige angrebsvinkler.

Det er stadigvæk to tredjepartsimplementeringer af sprog der er defineret af en virksomhed. Den eneste forskel er at Object Pascal/Delphi er så svært definérbart, og så Windows-centrisk, at FreePascal-projektet ikke har megen chance for at oversætte almindelige Delphi-programmer, hvorimod .NET (eller retteligt CLR - .NET er vist specifikt navnet på Microsofts implementering) er langt mere åbent for at tillade andre implementeringer. Ikke helt på niveau med Java, men Mono er dokumentérbart en stor succes, og har tilladt utallige krydsplatformsapplikationer, især spil, som ellers ikke ville have haft en chance. I modsætning hertil er FreePascal mig bekendt en udmærket oversætter, men det har ikke fået så meget succes målt på antal af programmører, eller brugere af programmer skrevet i Pascal.

  • 4
  • 0
Christian Nobel

Den eneste forskel er at Object Pascal/Delphi er så svært definérbart, og så Windows-centrisk, at FreePascal-projektet ikke har megen chance for at oversætte almindelige Delphi-programmer

Det kan der så være noget om, det er heller ikke det jeg anser for vejen frem, men derimod at man starter direkte fra FreePascal/Lazarus.

Tit og ofte har man alligevel fået gravet sig så langt ned hvis man bliver ved med at lappe på et gammelt program, at det kan være en fordel at starte forfra (men uden at forkaste sine erfaringer).

FreePascal mig bekendt en udmærket oversætter, men det har ikke fået så meget succes målt på antal af programmører, eller brugere af programmer skrevet i Pascal.

Hvilket er synd og skam, for der er virkelig muligheder - og Lazarus communitiet er nu ikke helt lille, der er bare ikke så mange danskere.

  • 0
  • 2
Troels Henriksen

Så er vi helt uenige, for mig betyder det noget hvilke resultater jeg kan opnå - ikke om buzzword barometret røger helt i top.

Og frameworket som .Net er jo totalt ligegyldigt, når man compilerer direkte til jernet.

Arbejder du som programmør? Jeg har ikke nævnt buzzwords overhovedet. Det eneste konkrete jeg har nævnt er at Pascal har et forældet typesystem, hvilket da næppe kan være kontroversielt.

Og hvorfor denne begejstring for at oversætte "til jernet"? Programmer ender som regel alligevel med at køre oven på et stort styresystem, og typisk også lige så store biblioteker og frameworks, også selvom de er skrevet i et lavniveausprog som C. Det meste af .NET er klassebiblioteker og deslige, hvilket altid er nyttigt. Eller undlader du også at bruge biblioteksfunktioner?

  • 4
  • 2
Stig Christensen

Men hvad med alle de gange hvor man i C# udnytter at sproget kører på CLR og man bruger Reflection til at aflæse metadata, udføre AOP eller alt muligt andet sjovt. Det er så meget mere værd end at eksekvere lidt hurtigere. Min oplevelse er at de færreste virkelig har brug for øget hastighed, men at de fleste har brug for lækker læseligt kode med så få fejl som muligt. Jeg udnytter det dagligt.

Det får nok ikke den store udbredelse, ligesom det er gået med Java native compilers.

  • 0
  • 0
Christian Nobel

Arbejder du som programmør?

Jeg vil mere sige jeg udvikler løsninger - for mig er det slutresultatet der tæller, og i det spil mener jeg at jeg kan være meget effektiv med FreePascal/Lazarus.

Det eneste konkrete jeg har nævnt er at Pascal har et forældet typesystem

Hvordan/hvorfor?

Programmer ender som regel alligevel med at køre oven på et stort styresystem

Det behøver faktisk ikke være så stort, og jeg ved at hvis der er installeret en vilkårlig Windows, eller en stort set vilkårlig Linux, så virker mine programmer out-of-the-box, uden nogen afhængigheder.

typisk også lige så store biblioteker og frameworks

Nej det er jo lige præcis det der ikke er nødvendigt.

  • 0
  • 1
David Christensen

Forskellen er nok, Glenn, at det rent faktisk har relevans for vores industri. Penetrationen af "Object Pascal", forstået som det sprog der anvendes i Delphi (der er flere OOP-udgaver af Wirth's Pascal som hedder dette), er minimal.

Derimod er anvendelsen af .NET ganske enorm. .NET-platformen har også en langt større ambitus end Delphi, som stadig primært er bedst til desktop-applikationer. Jeg ved godt der er diverse fiksfakserier så man kan targete smartphones, m.fl.

Men faktum er, at dette greb har en langt større effekt end Delphi. Derudover er den eneste årsag at Delphi i visse applikationer kan outperforme C++Builder og VisualC++ er de strenge regler, sproget enforcer. Hvis man enforcer at pointere ikke må aliases i C++, vil du opleve et sprog som med de ovennævnte compilere performer langt bedre end Delphi.

  • 0
  • 1
David Christensen

Pascal har ikke som sådan et forældet typesystem. Det er blot så megen lap-på-lap (det er dælme den længste closure og generics-syntaks jeg i mit liv har set) at resultatet er decideret ubehageligt og verbost.

Derudover vil jeg rigtig gerne vide hvilke løsninger du udvikler, som ikke anvender nogen som helst form for frameworks (som jo dybest set bare er et fancy ord for et library) og bare er "direkte på jernet"? Med mindre du laver embedded udvikling (hvor der ville være langt mere velvalgte sprog) håber jeg din timepris er lav...

  • 0
  • 1
Jens loggo

Så fordi at andre har lavet noget som compiler til native kode, så har ingen andre lov...

Har har intet skrevet, der kan overhovedet fortolkes, som om ingen andre har lov.

Det eneste der står, er at det de vil lave, ikke er noget specielt.

Det er let nok - tag et kig igennem hans tidligere kommentarer herinde, så tegner der sig et billede ;-)

Måske du skulle forholde dig til det han faktisk har skrevet, i stedet for din forventning om personen.

  • 1
  • 0
Mogens Hansen

Overskriften giver ingen mening.
Microsoft C# og VB.NET, .NET Native og Windows 10 er konkrete produkter, hvorom man kan udtale sig om performance (hvis licensbetingelserne tillader det).
C++ er en sprogspecifikation - der i sig selv ikke har en garanteret performance karakteristik. Der findes mange konkrete produkter, der implementerer specifikationen.
Så overskriften sammenligner et konkret produkt med en specifikation.

Ved at .NET Native bruger Microsoft Visual C++ aldeles glimrende backend, får man adgang til samme optimeringer i de produkter - og derfor kan man formodentlig forvente samme samme performance for identiske konstruktioner i C# og C++ genereret med Microsofts værktøjer.
Samme C++ program (source kode) oversat med forskellige compilere (f.eks. gcc, Clang/LLVM, og Microsoft Visual C++) vil have forskellig performance.

Derudover er der fundamentale forskelle i C++ og C#, der vil medføre performance forskelle.
F.eks. har C# runtime range-check på tilgang til containere og garbage-collection hvilket C++ ikke har.

Bortset fra det syntes jeg .NET Native er et interessant og fornuftigt produkt - det har bare taget noget lang tid at nå til de erkendelser, der ligger bag.

  • 0
  • 0
Sune Marcher

Delphi er native, hastighed er lig eller hurtigere end C++,


Hmm, siden hvornår? Det er et reelt spørgsmål, da det efterhånden er en del år siden jeg har set den vej :)

Generelt har jeg aldrig været imponeret over codegen eller library-kvalitet i Borland-og-efterkommere produkter. Men det var så heller ikke deres force - indtil de blev overhalet indenom havde de de bedste IDEs, det bedste xref'ede og kontekst-sentitive hjælp/API-dokumentation, samt de bedste GUI toolkits.

Jeg kan dog ikke se nogen god grund til at bruge Delphi (eller Object Pascal) i dag, med mindre man skal supporte et legacy system.

  • 0
  • 0
Christian Nobel

Jeg kan dog ikke se nogen god grund til at bruge Delphi (eller Object Pascal) i dag, med mindre man skal supporte et legacy system.

En grund til at bruge f.eks. Lazarus er at man kan lave et program som så kan kompileres til Intel, Arm og andre platforme, og dækkende stort set alle OS'er - uden man er afhængig af at der skal være installeret et framework på klientmaskinen.

Og produktiviteten i Lazarus/FreePascal er altså meget høj, og compileren er rigtig god til at fange "dummefejl" bla. pga stærk typing.

  • 0
  • 0
Sune Marcher

En grund til at bruge f.eks. Lazarus er at man kan lave et program som så kan kompileres til Intel, Arm og andre platforme, og dækkende stort set alle OS'er - uden man er afhængig af at der skal være installeret et framework på klientmaskinen.


Fair nok - krav om at undgå frameworks virker lidt niche-agtigt, men diskvalificerer så bl.a. C# og Java.

Og produktiviteten i Lazarus/FreePascal er altså meget høj, og compileren er rigtig god til at fange "dummefejl" bla. pga stærk typing.


Men hvorfor en Pascal variant fremfor f.eks. C++? Der må immervæk være flere 3rd party C/C++ libraries (højere produktivitet end at genopfinde hjulet), og moderne C++ er ganske pænt produktivt?

Hvilke ting tænker du på mht. "stærk typing" frem for andre sprog? Det eneste jeg lige umiddelbart kan komme på er range-limited integer types, men det burde kunne implementeres uden de helt store problemer (og er garanteret allerede blevet det af andre) som et library.

Det er ikke for at disse FPC/Lazarus, jeg er bare nysgerrig :)

  • 0
  • 0
Christian Nobel

Men hvorfor en Pascal variant fremfor f.eks. C++? Der må immervæk være flere 3rd party C/C++ libraries (højere produktivitet end at genopfinde hjulet), og moderne C++ er ganske pænt produktivt?

Faktisk er der også et hav af libraries/komponenter til FreePascal/Lazarus.

Men det er nok også mere min personlige preference, jeg synes et Pascal program er enklere at overskue, og når jeg sammenligner eksempler, så er der ca. det halve antal kodelinier i et Pascal program end i et tilsvarende C'et-eller-andet.
Se eksempelvis på de kodesnips Glenn refererer til omkring performance.

Og med Pascal kan jeg undgå at pointe mig selv direkte ned i helvede (man kan godt, men man behøver ikke).

Hvilke ting tænker du på mht. "stærk typing" frem for andre sprog? Det eneste jeg lige umiddelbart kan komme på er range-limited integer types, men det burde kunne implementeres uden de helt store problemer (og er garanteret allerede blevet det af andre) som et library.

Mit primære sammenligningsgrundlag er JavaScript, hvor alting sejler, og der ingen styr er på variabel deklaration osv.

Det er ikke for at disse FPC/Lazarus, jeg er bare nysgerrig :)

Du burde tage et kik på Lazarus - du vil givetvis blive positivt overrasket.

Men det er et frit land (påstås, men det er en helt anden diskussion) og man skal bruge det man selv føler sig mest komfortabel ved - og for mig drejer det sig om at vælge det værktøj jeg mener jeg er mest effektiv med.

Og set fra en slutbrugers side er det jo sådan set bedøvende ligegyldigt om hans program er udviklet i a, b, eller c, bare det er hurtigt og stabilt.

  • 0
  • 0
Log ind eller Opret konto for at kommentere