Programmeringssprog
NN
Der er et væld af programmeringssprog. Jeg kan umiddelbart nævne (af hvem
jeg kender af navn) C, Delphi, Java, Java script, VB, Perl, php m.v.
Men jeg har ikke det fjerneste overblik over de forskellige sprog.
Er der en, der vil bruge omkring 10 minutter på at kommentere en række sprog
(ikke nødvendigvis ovenstående, da jeg dels ønsker et bredt kendskab til
sprog generelt inden jeg går i detaljer for selv at lære).
Jeg er velvidende, at man ikke kan sige, "hvilket sprog der er bedst" da det
både er smag og behag samt afhænger af situation og behov m.v.
Men jeg kunne især godt tænke mig at høre lidt kommentarer omkring følgende.
Sværhedsgrad
Fordele
Ulemper
Anvendelighed (hvor og til hvad har sproget sine anvendeligheder)
Krav (kompetencer forinden og systemkrav)
Hvad der ellers falder Jer ind.
Findes der evt. en (dansk) oversigt på nettet eller i form af skriftlig
litteratur.
Jens Axel Søgaard
> Er der en, der vil bruge omkring 10 minutter på at kommentere en række sprog
> (ikke nødvendigvis ovenstående, da jeg dels ønsker et bredt kendskab til
> sprog generelt inden jeg går i detaljer for selv at lære).
Det er umuligt at skrive noget tilnærmelsesvist fornuftigt om
et så stort emne på 10 minuttter.
Du vil sikkert få bedre svar, hvis du skriver, hvilke problemstillinger,
du er interesseret i - og udfra dem få anbefalet et sprog.
> Findes der evt. en (dansk) oversigt på nettet eller i form af skriftlig
> litteratur.
Et skema:
<http://www.jvoegele.com/software/langcomp.html>
--
Jens Axel Søgaard
Jacob Sparre Andersen
> Er der en, der vil bruge omkring 10 minutter på at kommentere en
> række sprog (ikke nødvendigvis ovenstående, da jeg dels ønsker et
> bredt kendskab til sprog generelt inden jeg går i detaljer for selv
> at lære).
På <http://cvs.linuxbog.dk/program/bog/> er der et forsøg på at lave
sådan en oversigt.
Jacob
--
"Banning open source would have immediate, broad, and
strongly negative impacts on the ability of many sensitive
and security-focused DOD groups to protect themselves
against cyberattacks" -- Mitre Corp.
Michael Zedeler
> Der er et væld af programmeringssprog. Jeg kan umiddelbart nævne (af hvem
> jeg kender af navn) C, Delphi, Java, Java script, VB, Perl, php m.v.
De sprog, du nævner der, har alle det til fældes at de er imperative,
hvilket groft sagt betyder at computeres udfører instruktionerne i den
rækkefølge, de står.
Der er også to nadre klasser af sprog, som kan være sjove. Du kan se
mere om det på denne side: http://www.cs.nott.ac.uk/~gmh//faq.html
> Sværhedsgrad
Perl og C springer i øjnene som sprog, der ikke er nemme for begyndere,
hvor de andre er relativt lige til.
> Fordele
Så begynder en større religionskrig bare. Desuden er der så mange
forskellige muligheder, at det tager meget lang tid at gå dem igennem.
> Ulemper
C, Delphi og Java forudsætter at man oversætter, før man kan afprøve sit
program. Det kan sætte udviklingstempoet ned, men også medvirke til at
man overvejer hvad man gør, før man bare kører programmet :-)
> Anvendelighed (hvor og til hvad har sproget sine anvendeligheder)
Samme svar som "fordele".
> Krav (kompetencer forinden og systemkrav)
Jeg tror kun der er særlige systemkrav til Visual Basic - at man har
Windows. Ellers kører det hele overalt (jeg er dog ikke helt sikker på
Delphi). Af kompetencer, så kræver det ikke andet end at man kan læse en
bog om sproget og har tid til at rode med det (på en computer).
> Findes der evt. en (dansk) oversigt på nettet eller i form af skriftlig
> litteratur.
En meget god kompetence er at kunne læse engelsk. Der findes
dansksprogede bøger om programmering, men de er ikke meget værd, hvis du
også skal vedligeholde din viden, da de ikke bliver opdateret så ofte.
Desuden er der mange udviklere, som snakker "danglish", så snart de skal
beskrive noget datalogisk.
Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf
Jesper
Problemet er bare at sprogne er så forskellige på et utal af dimensioner, så
sammenligninger er svære at lave, hvis de stadig skal give bare en lille
smule overblik. Det er noget nemmere at anbefale et sprog til en konkret
opgave.
Eller også bør du nok angive om du hovedsageligt ønsker at lave:
- A) websider, B) windows programmer, eller C) generelle programmer.
- A) Små programmer rettet mod 1 simpel opgave, B) Generelle applikationer,
eller C) Store systemer.
- A) Programmer der kan distribueres til alle og enhver, B) Programmer der
kører på en server, eller C) Programmer til eget brug.
Svarene på de 3 spørgsmål vil nok indkredse anbefalingerne til en lille
håndfuld sprog.
Jesper
Bertel Lund Hansen
> Der er et væld af programmeringssprog. Jeg kan umiddelbart nævne (af hvem
> jeg kender af navn) C, Delphi, Java, Java script, VB, Perl, php m.v.
> Men jeg har ikke det fjerneste overblik over de forskellige sprog.
Det får du heller ikke af en gennemgang selv om den blev grundig.
Du har ikke noget skelet at hænge informationerne op på.
Gå i gang med Python, og vent med at spekulere over andre sprog
indtil du har fået fat i det grundlæggende. Python er temmelig
nemt at gå til samtidig med at det er et ganske stærkt sprog. Det
er forholdsvis let at lave komplekse ting fordi der findes
indbyggede moduler til at håndtere kompleksiteten. Desuden kan
man køre et program med det samme det er skrevet (hvis der ikke
er fejl i), mens andre sprog kræver at man kompilerer først. Ikke
at det er et stort problem, men det er altså en lille lettelse
ikke at skulle det.
Python kan bruges både som sekventielt sprog (også kaldet
imperativt), og som OOP-sprog (ObjektOrienteret
Programmeringssprog).
> Er der en, der vil bruge omkring 10 minutter på at kommentere
> en række sprog (ikke nødvendigvis ovenstående, da jeg dels
> ønsker et bredt kendskab til sprog generelt inden jeg går i
> detaljer for selv at lære).
Det lyder tilforladeligt, men det er bagvendt. Forestil dig at
dine forældre holdt lange foredrag om fransk, kinesisk, dansk,
serbokroatisk og spansk inden du skulle vælge modersmål og gå i
gang med at lære at tale. Udbyttet stod næppe mål med
anstrengelsen.
Python er ikke et meget brugt sprog, men strukturen i det minder
en del om C, C++, Java og flere andre, og generelt gælder det at
har man først lært ét sprog, så er det nemmere at lære de næste.
> Sværhedsgrad
Jeg har ikke prøvet noget sprog der er lettere ud af den halve
snes jeg har kendskab til.
> Fordele
Mange.
> Ulemper
Få.
> Anvendelighed (hvor og til hvad har sproget sine anvendeligheder)
Kan anvendes til alle programmeringsopgaver undtagen meget
tidskritiske rutiner.
> Krav (kompetencer forinden og systemkrav)
Lyst til at lære at programmere samt en fungerende computer.
> Hvad der ellers falder Jer ind.
Det kræver blod, sved, tårer og kaffe eller te at lære at
programmere. Alt andet er af underordnet betydning.
PS. Der er også nogle der programmerer på cola, men de bliver
ikke nær så gode ...
Morten Guldager
>
> PS. Der er også nogle der programmerer på cola, men de bliver
> ikke nær så gode ...
RELIGIONSKRIG!
/Morten %-)
Jens Axel Søgaard
Mjah - da der er mere koffein i kaffe end i cola, så
vokser dendritterne mere hos en kaffedrikker. Sandsynligvis
med en bedre langtidshukommelse til følge.
<http://data.intelihealth.com/pcn/general/00245888.htm>
--
Jens Axel Søgaard
Bertel Brander
> Hej.
>
> Der er et væld af programmeringssprog. Jeg kan umiddelbart nævne (af hvem
> jeg kender af navn) C, Delphi, Java, Java script, VB, Perl, php m.v.
Mine uforbeholdne fordomme:
C: Mest hvis man vil lave hardware drivere, Linux kerne, eller
programmere en PIC.
C++: Hurtige programmer der skal kunne kompileres til mange
platforme. Det er dog ikke ret let at lære C++, slet ikke
med GUI.
Delphi: Rimeligt "sprog" til mindre begynder programmer med
(windows) GUI.
C#: Et nyere sprog, som er på vej til at overtage en del efter
C++ (og delphi, java, ...). Er lettere at lære end C++, men
mangler en del i fleksibilitet.
VB: Legetøjs sprog for ikke programmører.
Python, Ruby: Gode begynder sprog. Specielt velegnet til små
programmer der kan lidt mere end et shell (/batch) script.
Python kan nok stadig mest, men Ruby er lidt mere elegant.
Java scritp, Asp, Php: Web applikationer.
Hvis du er helt ny inden for programmering: Python eller Ruby.
Derefter C++ eller C#, eller hvis det er til Web: Php.
--
Absolutely not the best homepage on the net:
http://home20.inet.tele.dk/midgaard
But it's mine - Bertel
Christian Iversen
> NN wrote:
>> Hej.
>>
>> Der er et væld af programmeringssprog. Jeg kan umiddelbart nævne (af hvem
>> jeg kender af navn) C, Delphi, Java, Java script, VB, Perl, php m.v.
>
> Mine uforbeholdne fordomme:
>
> C: Mest hvis man vil lave hardware drivere, Linux kerne, eller
> programmere en PIC.
Enig.
> Delphi: Rimeligt "sprog" til mindre begynder programmer med
> (windows) GUI.
Det må du gerne lige uddybe.
> VB: Legetøjs sprog for ikke programmører.
Enig ;-)
--
M.V.H
Christian Iversen
Bertel Brander
>>Delphi: Rimeligt "sprog" til mindre begynder programmer med
>>(windows) GUI.
>
>
> Det må du gerne lige uddybe.
Delphi er ikke et sprog, sproget hedder "Object pascal".
Delphi er Borlands udgave af sproget. Man får det sammen
med et tegn-og-klik IDE.
Delphi bliver mest brugt på Windows, selv om der findes
en variant til Linux (kylix).
Der findes kun en producent af Delphi.
Dette gør at jeg ikke vil anbefale Delphi som nyt
sprog til større seriøse opgaver.
Jeg er godt klar over at mange har stor fornøjelse af
Delphi, men mest til "små begynder programmer".
pb
> Christian Iversen wrote:
>
>>> Delphi: Rimeligt "sprog" til mindre begynder programmer med
>>> (windows) GUI.
>>
>>
>>
>> Det må du gerne lige uddybe.
>
>
> Delphi er ikke et sprog, sproget hedder "Object pascal".
programmet faktisk også kaldt selve sproget for Delphi. Jeg vil dog ikke
lægge hovedet på blokken.
> Delphi er Borlands udgave af sproget. Man får det sammen
> med et tegn-og-klik IDE.
> Delphi bliver mest brugt på Windows, selv om der findes
> en variant til Linux (kylix).
> Der findes kun en producent af Delphi.
>
Både og. Hvis man vil have det grafiske udviklingsværktøj er det rigtigt
nok, men fx FreePascal har også glimrende understøttelse for sproget --
hvilket i øvrigt betyder at man kan bruge det til både Windows, Linux
o.a. Der er faktisk også ved at blive udviklet et open source
RAD-værktøj med FreePascal som compiler: http://lazarus.freepascal.org.
Det er allerede brugbart til mindre projekter.
> Dette gør at jeg ikke vil anbefale Delphi som nyt
> sprog til større seriøse opgaver.
>
Selve Object Pascal-sproget er faktisk ganske kraftfuldt, og med
FreePascal-compileren kan jeg ikke se hvad der skulle stå i vejen. Men
om man kan lide sproget er selvfølgelig en smagssag.
> Jeg er godt klar over at mange har stor fornøjelse af
> Delphi, men mest til "små begynder programmer".
>
Det _kan_ også bruges til andet.
Mvh
pb
Martin Christensen
Hash: SHA1
Bertel Brander <ber...@post4.tele.dk> writes:
[...]
> Python, Ruby: Gode begynder sprog. Specielt velegnet til små
> programmer der kan lidt mere end et shell (/batch) script.
> Python kan nok stadig mest, men Ruby er lidt mere elegant.
[...]
Ud fra hvad du skriver, kunne man næsten forledes til at tro, at de
bare er søde små legetøjssprog. Det sidste jeg har kigget på i Ruby er
et avanceret og, efter sigende, højt ydende web framework (Ruby on
Rails), og i Python er det en pendent til Oracle Forms og Reports (GNU
Enterprise). Det kan godt være, at Ruby og Python er meget velegnede
til småprogrammer og som 'shell++', men de er bestemt ikke at fornægte
til større projekter. Faktisk ville jeg mange gange hellere lave et
større projekt i Python end i fx C++, Java eller C#.
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEYEARECAAYFAkNFg78ACgkQYu1fMmOQldU9qQCgtA2gLi+eR2F7LDY5RXc/NmNc
paIAmQEH2Ku/bEpa9lyJyQgNndjoABeo
=IHrl
-----END PGP SIGNATURE-----
Bertel Brander
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bertel Brander <ber...@post4.tele.dk> writes:
>
> [...]
>
>>Python, Ruby: Gode begynder sprog. Specielt velegnet til små
>>programmer der kan lidt mere end et shell (/batch) script.
>>Python kan nok stadig mest, men Ruby er lidt mere elegant.
>
> [...]
>
> Ud fra hvad du skriver, kunne man næsten forledes til at tro, at de
> bare er søde små legetøjssprog.
Jeg har vist formuleret mig forkert. Ruby og Python er IKKE
legetøjssprog, man kan lave meget med disse.
Men jeg vil ikke anbefale Ruby eller Python hvis formålet er
at lave avancerede spil, eller andre beregnings tunge applikationer,
dertil er de for langsomme.
Christian Iversen
> Christian Iversen wrote:
>
>>>Delphi: Rimeligt "sprog" til mindre begynder programmer med
>>>(windows) GUI.
>>
>>
>> Det må du gerne lige uddybe.
>
> Delphi er ikke et sprog, sproget hedder "Object pascal".
Som det er sagt tidligere er det ikke sandt i de nyeste udgaver af Borlands
produkter. Her tales om "The Delphi Language".
> Delphi er Borlands udgave af sproget. Man får det sammen
> med et tegn-og-klik IDE.
Ja, men der findes også fremragende gratis (frie) compilere til sproget, for
eksempel FreePascal.
> Delphi bliver mest brugt på Windows, selv om der findes
> en variant til Linux (kylix).
Det er sandt.
> Der findes kun en producent af Delphi.
Sandt. Men der findes flere forskellige compilere til sproget.
> Dette gør at jeg ikke vil anbefale Delphi som nyt
> sprog til større seriøse opgaver.
Hvorfor ikke?
> Jeg er godt klar over at mange har stor fornøjelse af
> Delphi, men mest til "små begynder programmer".
Det er et postulat, og ikke et særlig godt et.
--
M.V.H
Christian Iversen
Bertel Lund Hansen
>> Jeg er godt klar over at mange har stor fornøjelse af
>> Delphi, men mest til "små begynder programmer".
> Det er et postulat, og ikke et særlig godt et.
Jeg benytter Dialog som læseprogram til debatgrupperne. Det er
skrevet i Delphi. Resultatet må siges at være en anelse over
begynderstadiet.
Christian Iversen
> Christian Iversen skrev:
>
>>> Jeg er godt klar over at mange har stor fornøjelse af
>>> Delphi, men mest til "små begynder programmer".
>
>> Det er et postulat, og ikke et særlig godt et.
>
> Jeg benytter Dialog som læseprogram til debatgrupperne. Det er
> skrevet i Delphi. Resultatet må siges at være en anelse over
> begynderstadiet.
Helt enig. Det er en trættende fordom, men det er ikke andet end det.
--
M.V.H
Christian Iversen
Bertel Brander
>
>>Dette gør at jeg ikke vil anbefale Delphi som nyt
>>sprog til større seriøse opgaver.
>
>
> Hvorfor ikke?
Jeg ved ikke om der er grund til at trække diskutionen
længere, det har være drøftet før, men
Jeg har hørt mange argumentere for at Delphi (og/eller
Object Pascal) på mange punkter skulle være lige så
godt som C++, det er muligt. Men jeg har aldrig hørt noget
godt argument for at det skulle være bedre end C++.
Delphi (og/eller Object Pascal) er begrænset til en
(eller nogle få) producenter. Og kun til GUI applikationer
på Windows (og til dels Linux). Der findes færre biblioteker
til Delphi, man kan ikke bruge Delphi til at programmere
OS'er eller Mobiltelefoner eller lave Web-sider.
Så jeg vil mene at der er finde bedre sprog en Delphi til
formålet.
Bertel Brander
> Christian Iversen skrev:
>
>
>>>Jeg er godt klar over at mange har stor fornøjelse af
>>>Delphi, men mest til "små begynder programmer".
>
>
>>Det er et postulat, og ikke et særlig godt et.
>
>
> Jeg benytter Dialog som læseprogram til debatgrupperne. Det er
> skrevet i Delphi. Resultatet må siges at være en anelse over
> begynderstadiet.
>
Og man kan lave spil i bat-filer, og en hel web-browser i Python,
men ville du anbefale det?
Dit argument beviser (for mig at se) intet.
Christian Iversen
> Bertel Lund Hansen wrote:
>> Christian Iversen skrev:
>>
>>
>>>>Jeg er godt klar over at mange har stor fornøjelse af
>>>>Delphi, men mest til "små begynder programmer".
>>
>>
>>>Det er et postulat, og ikke et særlig godt et.
>>
>>
>> Jeg benytter Dialog som læseprogram til debatgrupperne. Det er
>> skrevet i Delphi. Resultatet må siges at være en anelse over
>> begynderstadiet.
>>
>
> Og man kan lave spil i bat-filer, og en hel web-browser i Python,
> men ville du anbefale det?
>
> Dit argument beviser (for mig at se) intet.
Flot argument. Du får det til at lyde som om det ville være lige så
smertefuldt at skrive et større program i Delphi, som det ville være at
skrive et spil i en bat-fil. Det er overhovedet ikke tilfældet.
Har du forresten prøvet Delphi?
--
M.V.H
Christian Iversen
Christian Iversen
> Christian Iversen wrote:
>>
>>>Dette gør at jeg ikke vil anbefale Delphi som nyt
>>>sprog til større seriøse opgaver.
>>
>>
>> Hvorfor ikke?
>
> Jeg ved ikke om der er grund til at trække diskutionen
> længere, det har være drøftet før, men
>
> Jeg har hørt mange argumentere for at Delphi (og/eller
> Object Pascal) på mange punkter skulle være lige så
> godt som C++, det er muligt. Men jeg har aldrig hørt noget
> godt argument for at det skulle være bedre end C++.
Så lad mig komme med nogle stykker:
- Bedre typesystem
- Interfaces
- Ægte unit-compilering i stedet for objectfil-suppe
- Properties
- Stack-baserede closures
Find selv på flere, det er bestemt ikke de eneste.
> Delphi (og/eller Object Pascal) er begrænset til en
> (eller nogle få) producenter.
Fint nok, så lad os lige fjerne PHP, Perl, Python, Ruby, Lua etc.
Eller hvad? Er det kun C og C++ der må bruges i "seriøse projekter"?
> Og kun til GUI applikationer på Windows (og til dels Linux).
hvorfor det?
> Der findes færre biblioteker til Delphi, man kan ikke bruge Delphi til at
> programmere OS'er
hvorfor ikke?
> eller Mobiltelefoner
Hvilke telefoner er det man ikke kan lave programmer til? Det gælder fx.
ikke for SmartPhones.
> eller lave Web-sider.
hvorfor ikke?
> Så jeg vil mene at der er finde bedre sprog en Delphi til
> formålet.
Ja, hvis jeg smed om mig med påstande på den måde,
ville jeg også tro mange ting ;-)
--
M.V.H
Christian Iversen
Bertel Brander
> Flot argument. Du får det til at lyde som om det ville være lige så
> smertefuldt at skrive et større program i Delphi, som det ville være at
> skrive et spil i en bat-fil. Det er overhovedet ikke tilfældet.
Min pointe var blot at, man ikke kan slutte fra at "det er muligt"
til at "det kan anbefales". Og nej, jeg tror ikke det er smertefuldt
at skrive større applikationer i Delphi.
> Har du forresten prøvet Delphi?
Ikke for alvor, og jeg har ikke lyst til at prøve. Da jeg stadig
ikke har set noget argument for at Delphi skulle være bedre end
C++ (eller C# eller Java eller ...)
Bertel Lund Hansen
>> Jeg benytter Dialog som læseprogram til debatgrupperne. Det er
>> skrevet i Delphi. Resultatet må siges at være en anelse over
>> begynderstadiet.
> Og man kan lave spil i bat-filer, og en hel web-browser i Python,
> men ville du anbefale det?
Jeg skrev min kommentar som svar til det postulat at man kun kan
lave småprogrammer i Delphi. Jeg kender stort set ikke sproget
bortset fra at TurboPascal nok stadig er det sprog som jeg har
skrevet mest i. Derfor kan jeg hverken anbefale eller fraråde
folk at bruge Delphi.
Jeg vil fraråde folk at bruge batfiler til andet end det mest
simple selv om jeg selv gør det. Det er et rodet sprog.
Python vil jeg anbefale til mange ting. Ganske vist er det ikke
så hurtigt som ren C, men tabet skulle i mange forhold ikke være
mere end ca. 10 %.
Til spil - som jeg ikke har erfaring med - vil jeg anbefale
forskellige sprog til forskellige elementer: højniveau til
styringen, og C eller ASM til tidskritiske rutiner.
> Dit argument beviser (for mig at se) intet.
Jo. Det beviser at det er muligt at skrive gode og avancerede
programmer i Delphi, QED.
Uffe Kousgaard
news:4346c37b$0$141$edfa...@dread11.news.tele.dk...
>> Har du forresten prøvet Delphi?
>
> Ikke for alvor, og jeg har ikke lyst til at prøve. Da jeg stadig
> ikke har set noget argument for at Delphi skulle være bedre end
> C++ (eller C# eller Java eller ...)
Hvis du snakkede som du havde forstand (om Delphi), så holdt du din mund.
Uffe
Christian Iversen
Uffe Kousgaard
> Delphi: Rimeligt "sprog" til mindre begynder programmer med
> (windows) GUI.
Så forkert som noget kan være, men din manglende viden om Delphi afslører du
jo også senere.
Faktum er, at Delphi er det bedste all-round værktøj, der eksisterer i dag.
Og mest produktive. Du kan finde andre værktøjer som er marginaler bedre til
bestemte typer af opgaver, men om det er værd at skulle lære 10 værktøjer
for at få den sidste procent med, må den enkelte jo selv vurdere.
Der er også områder som Delphi ikke er så godt til: low-level drivere,
kompilering på sun, mac m.m. Men har man ikke dette behov, er det jo ikke
noget problem.
Dette er en ikke-udtømmende liste over applikationstyper, som KAN laves med
Delphi:
Windows GUI applikationer, .NET applikationer, konsol-applikationer, NT
services, DLL'er, Active-X, Control panel applets, database-applikationer,
web-services, hjemme-sider (cgi, isapi m.v.), ASP.NET m.v.
hilsen
Uffe
Henrik Stidsen
>>> Jeg er godt klar over at mange har stor fornøjelse af
>>> Delphi, men mest til "små begynder programmer".
>> Det er et postulat, og ikke et særlig godt et.
> Jeg benytter Dialog som læseprogram til debatgrupperne. Det er
> skrevet i Delphi. Resultatet må siges at være en anelse over
> begynderstadiet.
Det firma der laver software til politiet og alarmcentralerne (og en
masse andre virksomheder med meget høje stabilitets og sikkerhedskrav)
bruger Delphi. Om de gør det til alle programmer ved jeg ikke, men de
gør i hvert fald til nogen af dem.
Så Delphi kan sagtens bruges langt ud over begynderstadiet.
--
Henrik Stidsen - http://henrikstidsen.dk/
Uffe Kousgaard
news:mn.3d417d5a0...@news.hs235.dk...
>
> Så Delphi kan sagtens bruges langt ud over begynderstadiet.
Skype var / er skrevet i Delphi. Det burde kunne overbevise de fleste om
anvendeligheden af Delphi :-)
Jens Axel Søgaard
> - Stack-baserede closures
Med "stakbaseret" mener du, så at man kun må
referere til frie variable så længe den funktion,
som bandt variablen stadig er med i den dynamiske
kontekst?
Altså, at man har lov til
(define (foo et-tal)
; her kaldes closuren, i en dynamisk kontekst,
; hvor bindingen af et-tal stadig er med
((lambda () et-tal))
(foo 42)
men ikke
(define (lav-closure et-tal)
(lambda () et-tal))
; her kaldes closuren i en dynamisk kontekst,
; udenfor bindingsstedet af et-tal
((lav-closure 42))
?
--
Jens Axel Søgaard
Bertel Brander
> Faktum er, at Delphi er det bedste all-round værktøj, der eksisterer i dag.
Jeg vidste ikke lige hvor jeg skulle svare, så det blev her.
På det område hvor jeg arbejder normalt, hvilket er på indlejrede
systemer, er der ikke andre sprog end C og C++.
At man så kan bruge dette sprog til at lave konsol og GUI
programmer på stort set alle platforme er et ekstra plus, for
så behøver jeg kun ét sprog.
At det er et af de mest (hvis ikke det mest) benyttede sprog
i verden er et ekstra plus, for det betyder at der findes
et hav af biblioteker og værktøjer til det.
At C og C++ efter 15 år er blevet mit andet modersmål er et
ekstra pluds.
At (stort set) alle OS'er er skrevet i C eller C++ er et ekstra
plus.
Jeg ved godt at der findes andre sprog, og en dag vil jeg nok
også sætte mig ind et andet sprog for alvor, men det blive ikke
Delphi, for jeg mener at der findes bedre.
Og ja, jeg ved godt at man kan lave programmer i Delphi.
Det kan i øvrigt undre at der skal så kraftige provokationer til
fra min side inden nogen tager sig sammen til at svarre. Bemærk
at jeg startede mit første indlæg med at skrive:
"Mine uforbeholdne fordomme:"
Martin Christensen
Hash: SHA1
"Uffe Kousgaard" <look_at_routeware.dk> writes:
> Faktum er, at Delphi er det bedste all-round værktøj, der eksisterer
> i dag. Og mest produktive.
Hvad vil du underbygge denne ret så store påstand med? Når du kan
udtale dig så skråsikkert, er jeg sikker på, at du let kan fremskaffe
utvetydig, uvildig dokumentation for Delphis overlegenhed.
Hvor mange andre sprog/værktøjer er du tilnærmelsesvist lige så
fortrolige med som med Delphi?
> Du kan finde andre værktøjer som er marginaler bedre til bestemte
> typer af opgaver, men om det er værd at skulle lære 10 værktøjer for
> at få den sidste procent med, må den enkelte jo selv vurdere.
Måske det var en idé at lære de 10 andre værktøjer at kende alligevel.
På samme måde som sprognørder siges at få større indsigt i grammatik
ved at lære latin (for mit vedkommende var det esperanto, men det er
ligegyldigt), har programmører vældig god gavn af at lære forskellige
sprog og programmeringsparadigmer at kende alene af den grund, at det
gør dem til bedre programmører. Jeg kender ikke nogen gode
programmører, der ikke har mindst en halv håndfuld sprog godt og
solidt under bæltet.
> Der er også områder som Delphi ikke er så godt til: low-level
> drivere, kompilering på sun, mac m.m. Men har man ikke dette behov,
> er det jo ikke noget problem.
Der findes skam compilere til en hel del platforme. Jeg har vist nok
en pascal compiler liggende på min Linuxæske, som kan klare
Delphikode.
> Dette er en ikke-udtømmende liste over applikationstyper, som KAN
> laves med Delphi:
> Windows GUI applikationer, .NET applikationer, konsol-applikationer, NT
> services, DLL'er, Active-X, Control panel applets, database-applikationer,
> web-services, hjemme-sider (cgi, isapi m.v.), ASP.NET m.v.
Hvad er din pointe? Delphi er Turingkomplet. Alle Turingkomplette
sprog er ækvivalente, ergo kan man principielt set det samme i alle
sprog, der er værd at tale om. I Delphi kunne du jo fx lave en
Lispfortolker, og så kan du gøre alt det, man kan gøre i Lisp. I denne
kunne du igen lave en Prologfortolker, hvis du tænder på den slags.
Diskussioner om hvad man kan og ikke kan med dette eller hint
programmeringssprog, har altid irriteret mig, for på nær i særlige
tilfælde kan man sgu det samme. Hvad man i virkeligheden burde tale
om, er hvad der er praktisk. Jeg programmerede fx min specialeopgave i
Python, og var meget glad for dette valg, da det gav mig mulighed for
at kode til et behageligt højt abstraktionsniveau. Kunne jeg have
gjort det samme i Lisp? Ja absolut, men jeg er ikke specielt fortrolig
med sproget. Kunne jeg have fået mere performance ud af C? Sikkert
nok, men så skulle jeg til at bekymre mig om pointere og
hukommelseshåndtering og eksterne strengbiblioteker osv., og som det
var fik jeg alligevel (tilsyneladende) lavet den hurtigste søgemaskine
af sin type.
Hvis vi skal tale om, hvad vores yndlingssprog hver især kan, kan vi
stort set lige så godt trække bukserne ned, finde linealen frem og få
afgjort sagen på dén gamle vis en gang for alle. Det er mange år siden
den slags diskussioner har været relevante.
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEUEARECAAYFAkNG/AoACgkQYu1fMmOQldWKHgCYseqKxjHsgheCd6YOHKATwWC+
cACfbEjmZP1EDV3Peaq/cK5rYdHS4Qc=
=AQmR
-----END PGP SIGNATURE-----
Uffe Kousgaard
news:87achlx...@gmail.com...
>
>> Faktum er, at Delphi er det bedste all-round værktøj, der eksisterer
>> i dag. Og mest produktive.
>
> Hvad vil du underbygge denne ret så store påstand med? Når du kan
> udtale dig så skråsikkert, er jeg sikker på, at du let kan fremskaffe
> utvetydig, uvildig dokumentation for Delphis overlegenhed.
Den overlegne produktivitet kan f.eks. aflæses af min selvangivelse, men den
er fortrolig. Jeg kan også se det, når konkurrenter forsvinder fra markedet.
Konkurrenter, som typisk har anvendt C++, men var for ineffektive.
> Hvor mange andre sprog/værktøjer er du tilnærmelsesvist lige så
> fortrolige med som med Delphi?
Ingen, men jeg kender til flere som anvender både C++ og Delphi intensivt og
hos dem er der ingen tvivl.
> Måske det var en idé at lære de 10 andre værktøjer at kende alligevel.
Måske som en akademisk øvelse, hvis jeg havde tid til den slags sjov.
> På samme måde som sprognørder siges at få større indsigt i grammatik
> ved at lære latin (for mit vedkommende var det esperanto, men det er
> ligegyldigt), har programmører vældig god gavn af at lære forskellige
> sprog og programmeringsparadigmer at kende alene af den grund, at det
> gør dem til bedre programmører. Jeg kender ikke nogen gode
> programmører, der ikke har mindst en halv håndfuld sprog godt og
> solidt under bæltet.
Mit udgangspunkt er ikke som programmør, men derimod civil-ingeniør og her
tillader Delphi mig at lave mange typer af applikationer indenfor mit
fagområde uden at skulle kende en "halv håndfuld" forskellige sprog i
detaljer.
>> Der er også områder som Delphi ikke er så godt til: low-level
>> drivere, kompilering på sun, mac m.m. Men har man ikke dette behov,
>> er det jo ikke noget problem.
>
> Der findes skam compilere til en hel del platforme. Jeg har vist nok
> en pascal compiler liggende på min Linuxæske, som kan klare
> Delphikode.
Ja, Freepascal kan f.eks. kompilere meget delphi-kode på næsten alle
tilgængelige platforme men ikke alt og nu gik snakken jo på Delphi.
> Hvad er din pointe?
At Delphi kan bruges til andet end windows-GUI applikationer, som Bertel
Brander skrev.
> Diskussioner om hvad man kan og ikke kan med dette eller hint
> programmeringssprog, har altid irriteret mig, for på nær i særlige
> tilfælde kan man sgu det samme.
Prøv f.eks. at lave en DLL (altså ikke en OCX) med VB6. Det kan man bare
ikke. Det samme gælder med en windows-driver i Delphi. Det kan man heller
ikke, da windows-DDK fra MS kun kan anvendes med C / C++. Så der er altså
helt faktuelle begrænsninger. Med Lisp, perl, php m.m. er der langt flere af
sådanne begrænsninger.
> Hvad man i virkeligheden burde tale om, er hvad der er praktisk.
Nemlig. Kun meget få opgaver er "upraktiske eller umulige" med Delphi.
hilsen
Uffe
Uffe Kousgaard
>
> På det område hvor jeg arbejder normalt, hvilket er på indlejrede
> systemer, er der ikke andre sprog end C og C++.
Enig og deraf følger det selvfølgelig, at du anvender netop disse til de
fleste andre opgaver.
> Det kan i øvrigt undre at der skal så kraftige provokationer til
> fra min side inden nogen tager sig sammen til at svarre. Bemærk
> at jeg startede mit første indlæg med at skrive:
> "Mine uforbeholdne fordomme:"
Havde jeg ikke været på messe hele denne uge i Tyskland havde jeg også været
ude noget tidligere :-)
hilsen
Uffe
Mogens Hansen
"Uffe Kousgaard" <o...@no.no> wrote in message
news:43477236$0$84014$edfa...@dtext01.news.tele.dk...
[8<8<8<]
> Den overlegne produktivitet kan f.eks. aflæses af min selvangivelse, men
> den er fortrolig.
Er det dig eller Delphi der har den største del af æren ?
[8<8<8<]
> Konkurrenter, som typisk har anvendt C++, men var for ineffektive.
Borland C++Builder er Delphi med C++ compiler.
Den har fordelen ved at bruge C++ er bl.a.:
* Et kraftigere sprog
* Mulighed for at skrive store dele af sin applikation i et leverandør
neutralt, standardiseret sprog
* Mulighed for at simpelt at bruge eksisterende C, C++ og Delphi Language
moduler
C++Builder har ulempen af langsommere oversættelsestid, forskellige
svagheder stammende fra at Delphi er lavet til Delphi Language og en
politisk omtumlet tilværelse de senere år.
[8<8<8<]
> Ingen, men jeg kender til flere som anvender både C++ og Delphi intensivt
> og hos dem er der ingen tvivl.
Når man snakker om Delphi i forhold til andre sprog, skal man nok passe på
ikke at underkende C#.
Det er trods alt samme mand der har lavet Delphi og C#, men C# er lavet i en
organisation som er væsentlig stærkere end Borland. C# er i høj grad lavet
på erfaringerne fra Delphi - nu prøver Delphi at lave catch up med C#.
F.eks. forventer Borland at levere Delphi med understøttelse for .NET 2.0
med bl.a. generics i 2006. C# har længe kørt i beta med det og bliver
frigivet inden for en måned.
Jeg har stor respekt for Delphi, men det forspring den havde da den kom frem
for 10 år siden er blevet kraftigt udhulet, og der indgår også politiske
overvejelser i valget af værktøjer.
Venlig hilsen
Mogens Hansen
Mogens Hansen
"Uffe Kousgaard" <o...@no.no> wrote in message
news:43477236$0$84014$edfa...@dtext01.news.tele.dk...
[8<8<8<]
> Konkurrenter, som typisk har anvendt C++, men var for ineffektive.
Delphi, og tilsvarende værktøjer, har en række egenskaber der lægger op til
quick-and-dirty programmering, som overtræder veletablerede
programmeringsteknikker for større projekter. Det er teknikker som f.eks.
encapsulation og seperation of concern. Det gør at man måske når første
milepæl hurtigt uden at tænke sig ret meget om, og så venter regningen
senere i projektet. Situationen bliver bestemt ikke bedre hvis vi snakker om
samtidigt at vedligeholde flere produkteter med flere programmører.
Det har ført til at vi på mit arbejde har måttet omskrive flere Delphi
programmer fordi de ikke kunne vedligeholdes stabilt - det er et
uomtvisteligt faktum.
Dermed ikke sagt at man kan skrive programmer ordenligt i Delphi - man kan
skrive pænt og grimt i de fleste sprog.
Venlig hilsen
Mogens Hansen
Kim
<moge...@dk-online.dk> wrote:
>Når man snakker om Delphi i forhold til andre sprog,
>skal man nok passe på ikke at underkende C#.
Hvordan udtaler man "C#" ?
--
Kim
Mogens Hansen
"Kim" <Jen...@post6.tele.x> wrote in message
news:f23fk1hoc8869s9sk...@4ax.com...
[8<8<8<]
> Hvordan udtaler man "C#" ?
See Sharp
http://msdn.microsoft.com/vcsharp/
Venlig hilsen
Mogens Hansen
Jens Axel Søgaard
> Hvordan udtaler man "C#" ?
Det kommer an på, hvordan du udtaler #.
Normalt udtaler jeg # som klaf. Dermed bliver det
til "C klaf".
(de kære amerikanere udtaler # som sharp)
--
Jens Axel Søgaard
Jesper
'C-sharp'
Og jeg kan i øvrigt også tilslutte mig den holdning. Jeg har selv brugt over
20 forskellige sprog i tidens løb. Mest af alt Delphi, C++, og nu C#. Jeg
var meget glad for Delphi til diverse projekter med faste og veldefinerede
formål. Et ganske glimrende sprog. C++ gik jeg over til i forbindelse med
nogle optimeringsprojekter hvor der simpel hent var så meget performance at
hente i mine algoritmer (Jeg havde kodet dem i begge sprog). Men det var nu
også meget atypiske programmer der skulle bruge minutter og nogle gange
timer til diverse udregninger. En anden gang har jeg også skulle bruge C++ i
forbindelse med noget low-level håndtering af grafik, som jeg heller ikke
synes gik helt tilfredsstillende i Delphi. Til mere typiske programmer
kommer man dog til at bruge meget tid på ellers trivielle ting i C++. Det er
i mange henseende en produktivitets-sluger.
De sidste par år er jeg gået over til C#. Det må jeg sige er det mest
elegante og veldesignede sprog jeg har set. Jeg kan stadig godt forstille
mig at jeg til enkelte ting må hoppe tilbage til C++, men umiddelbart vil
jeg nok kun hoppe tilbage til Delphi hvis jeg skulle lave en stand-alone
windows exe uden DotNet.
Jesper.
Christian Iversen
> Kim wrote:
>> Hvordan udtaler man "C#" ?
>
> Det kommer an på, hvordan du udtaler #.
> Normalt udtaler jeg # som klaf. Dermed bliver det
> til "C klaf".
>
> (de kære amerikanere udtaler # som sharp)
C klaf lyder meget sjovere ;-)
--
M.V.H
Christian Iversen
Christian Iversen
> Kim wrote:
>> Hvordan udtaler man "C#" ?
>
> Det kommer an på, hvordan du udtaler #.
> Normalt udtaler jeg # som klaf. Dermed bliver det
> til "C klaf".
>
> (de kære amerikanere udtaler # som sharp)
C klaf lyder meget sjovere.
Og i øvrigt, hvad kalder man #^ ? ;-)
--
M.V.H
Christian Iversen
Christian Iversen
Ja, lige præcis. Det kaldes mere populært indlejrede procedurer.
--
M.V.H
Christian Iversen
Jens Axel Søgaard
Heh!
Her et udsnit af udtalevejledningen, man
får smidt i hovedet det første år:
. dot
/ slash, skråstreg
\ backslash
' ping, plaf, quote
" dobbelt-ping, fnidder, double-quote
@ snabel-a, aberøv, at-tegn, master-space
^ hat, pege, pointer
# klaf, glyf, havelåge
_ underline, underscore
{ tuborg
} sluttuborg
| bar, pipe, pind
~ tilde, overskæg
? va?
! hov!
--
Jens Axel Søgaard
Christian Iversen
Jeg mener, ikke at du ikke allerede ved dét :-)
--
M.V.H
Christian Iversen
Jacob Sparre Andersen
> Det firma der laver software til politiet og alarmcentralerne (og en
> masse andre virksomheder med meget høje stabilitets og
> sikkerhedskrav) bruger Delphi. Om de gør det til alle programmer ved
> jeg ikke, men de gør i hvert fald til nogen af dem.
Radioerne der skal bruges til nødopkald fra Øresundstogene er
programmeret i Visual Basic.
Noget styresoftwaren i nogle ESA-satelitter er skrevet i C.
Det får mig hverken til at anbefale Visual Basic eller C til
programmer med høje stabilitets og sikkerhedskrav.
Jacob
--
"... while the C compiler will happily generate code for
almost anything produced by leaning on the keyboard."
Adam Sjøgren
> Hvordan udtaler man "C#" ?
"se-havelåge"
Mvh.
--
"Jeg har snart gennemlæst det meste af Internettet for Adam Sjøgren
at finde en løsning - men uden resultat..." as...@koldfront.dk
Bertel Brander
> Jeg har stor respekt for Delphi, men det forspring den havde da den kom frem
> for 10 år siden er blevet kraftigt udhulet, og der indgår også politiske
> overvejelser i valget af værktøjer.
Jeg er på ingen måde uening i det du har skrevet.
Dog havde jeg håbet at Java var blevet nævnt på lige fod med C#.
Men Java er nok bare nogle trin bagefter.
Henning Makholm
> Hvordan udtaler man "C#" ?
['sis].
--
Henning Makholm "However, the fact that the utterance by
Epimenides of that false sentence could imply the
existence of some Cretan who is not a liar is rather unsettling."
Martin Christensen
Hash: SHA1
"Uffe Kousgaard" <o...@no.no> writes:
>> Hvad vil du underbygge denne ret så store påstand med? Når du kan
>> udtale dig så skråsikkert, er jeg sikker på, at du let kan
>> fremskaffe utvetydig, uvildig dokumentation for Delphis
>> overlegenhed.
>
> Den overlegne produktivitet kan f.eks. aflæses af min selvangivelse,
> men den er fortrolig. Jeg kan også se det, når konkurrenter
> forsvinder fra markedet. Konkurrenter, som typisk har anvendt C++,
> men var for ineffektive.
Præmis 1: Du tjener mange penge.
Præmis 2: Du bruger Delphi.
Konklusion: Delphi er det bedste all-round værktøj.
Hmm... den er jeg ikke helt glad for. Nå, vi prøver igen...
Præmis 1: Din virksomhed bruger Delphi.
Præmis 2: Nogle af konkurrenterne bruger C++.
Præmis 3: Nogle af konkurrenterne bukker under.
Præmis 4: I er endnu ikke bukket under.
Konklusion: Delphi er det bedste all-round værktøj.
Pokkers også, den er heller ikke helt god. Hvad dælen gør vi nu? Jeg
tror, vi bliver nødt til at nøjes med at konkludere, at du/din
virksomhed har haft stor glæde af Delphi.
>> Hvor mange andre sprog/værktøjer er du tilnærmelsesvist lige så
>> fortrolige med som med Delphi?
>
> Ingen, men jeg kender til flere som anvender både C++ og Delphi
> intensivt og hos dem er der ingen tvivl.
Nu er der jo (heldigvis) et godt stykke fra 'Delphi er bedre at
arbejde med end C++' til 'Delphi er det bedste all-round værktøj'. Jeg
er ingen haj til nogen af delene, men jeg tror da også, jeg ville
vælge Delphi over C++, hvis jeg blev nødt til det. Men nu er verden jo
heldigvis større end blot de to valg.
>> Måske det var en idé at lære de 10 andre værktøjer at kende
>> alligevel.
>
> Måske som en akademisk øvelse, hvis jeg havde tid til den slags
> sjov.
Jeg finder det ret uprofessionelt, men desværre også meget
almindeligt, at man som programmør kan affeje noget så vigtigt med at
kalde det en 'akademisk øvelse', underforstået ubrugeligt i praksis,
blot fordi udbyttet ikke er trivielt at måle. Enhver tåbe kan kode.
Hvad der skiller fårene fra bukkene er kvaliteten af de mentale
krumspring, der ligger bag koden. Forskellige sprog/paradigmer fordrer
forskellige måder at tænke på. I mit arbejde bruger jeg kun yderst
sjældent andet end et enkelt af de sprog (PL/SQL), jeg har tilegnet
mig, men jeg er helt klart blevet en bedre programmør af at lære dem,
og det kan mærkes ligegyldigt hvilket sprog, jeg bruger.
> Mit udgangspunkt er ikke som programmør, men derimod civil-ingeniør
> og her tillader Delphi mig at lave mange typer af applikationer
> indenfor mit fagområde uden at skulle kende en "halv håndfuld"
> forskellige sprog i detaljer.
Hvis ens primære arbejde er at programmere, er man efter min
definition en programmør uanset ens uddannelse. Det er det, jeg mener.
Jeg har ikke påstået, at man bør bruge en bred vifte af sprog i sit
daglige arbejde. Faktisk vil jeg fraråde det, især hvis man skal
samarbejde med andre. Der er som regel forvirring nok omkring brugen
af biblioteker, kodestandarder osv. med bare et sprog at holde styr
på. Det rokker dog ikke ved min pointe fra ovenfor.
>> Hvad er din pointe?
>
> At Delphi kan bruges til andet end windows-GUI applikationer, som
> Bertel Brander skrev.
Ja, men hvis ikke man vil lave GUI-applikationer til Windows, er der
så nogen særlig grund til at bruge Delphi?
> Prøv f.eks. at lave en DLL (altså ikke en OCX) med VB6. Det kan man
> bare ikke. Det samme gælder med en windows-driver i Delphi. Det kan
> man heller ikke, da windows-DDK fra MS kun kan anvendes med C / C++.
> Så der er altså helt faktuelle begrænsninger.
Jeg har en formodning om, at det blot er et spørgsmål om at lave et
mellemlag. Mit eget yndlingssprog, Python, har den slags mellemlag til
alt mellem himmel og jord (blandt andet :-)).
> Med Lisp, perl, php m.m. er der langt flere af sådanne
> begrænsninger.
Ganske givet med PHP, men Lisp (i diverse afskygninger) og Perl har
biblioteker og mellemlag til utroligt mange ting. Jeg vil gætte på, at
Lisp vil kunne give Delphi god konkurrence, mens Perl sandsynligvis er
foran på det punkt, især inden for Open Source-verdenen.
>> Hvad man i virkeligheden burde tale om, er hvad der er praktisk.
>
> Nemlig. Kun meget få opgaver er "upraktiske eller umulige" med
> Delphi.
Er funktioner førsteklassesobjekter, dvs. kan man bruge en funktion
som argument til en anden funktion? Hvad med closures? Kan man få ens
egne objekter til syntaktisk at opføre sig som indbyggede typer, fx
arrays eller hashtabeller? Det er den slags, der for mig gør et sprog
behageligt at arbejde med. Hvad æstetik angår har Pascalfamilien af
sprog en syntaks, der generer mig, især med alt det begin/end, og det
viser sig desværre i PL/SQL, som jeg hacker hele dagen lang. Så
hellere tuborgparenteser som i C-familien eller indrykning som i
Python.
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEYEARECAAYFAkNIPBIACgkQYu1fMmOQldUJ7QCffiZsRNwL8INCuH90RTGWMlne
wc4AoNHAWOnQiUwUO/6JqLmKCzjasvOf
=zFYr
-----END PGP SIGNATURE-----
Peter Lykkegaard
> Hvis ens primære arbejde er at programmere, er man efter min
> definition en programmør uanset ens uddannelse.
Nemlig!
Det er ikke valg af sprog der er det afgørende
Det afgørende er hvad man bruger sproget til
- Peter
Michael Zedeler
> "Bertel Brander" <ber...@post4.tele.dk> wrote in message
> news:434175ac$0$150$edfa...@dread11.news.tele.dk...
>
>>Delphi: Rimeligt "sprog" til mindre begynder programmer med
>>(windows) GUI.
>
> Så forkert som noget kan være, men din manglende viden om Delphi afslører du
> jo også senere.
Jeg har set nogle meget store Delphi-applikationer, så deri er jeg enig
med dig. Delphi er _også_ et godt sted at starte, fordi sprogets
opbygning er enkel at lære for begyndere.
> Faktum er, at Delphi er det bedste all-round værktøj, der eksisterer i dag.
> Og mest produktive.
Det udsagn kommer vist mest af personlig erfaring med at udvikle i
Delphi, ikke? Jeg kan fiske et par fanatiske perl-programmører frem, som
vil påstå præcis det samme for perl. Hvad skal vi så stille op? Skal vi
arrangere en perl/Delphi-shootout?
> Du kan finde andre værktøjer som er marginaler bedre til
> bestemte typer af opgaver, men om det er værd at skulle lære 10
> værktøjer for at få den sidste procent med, må den enkelte jo selv
> vurdere.
At du har valgt at specialisere dig, er dit eget valg. Du skriver også
senere at du er civilingeniør - så undrer det i hvert fald ikke mig.
Hvis du har nogle konkrete opgaver, som du har nemt ved at løse med
Delphi, er det jo fint. At du generealiserer din situation til også at
gælde alle andre, synes jeg er problematisk. Specielt når det fremgår
ret tydeligt at du ikke har bred erfaring med andre sprog.
> Der er også områder som Delphi ikke er så godt til: low-level drivere,
> kompilering på sun, mac m.m. Men har man ikke dette behov, er det jo ikke
> noget problem.
Det er da et eksempel på en begrænsning, som jeg under ingen
omstændigheder ville acceptere i rigtig mange af de projekter, jeg har
arbejdet i. Igen er det historien om forskellige værktøjer til
forskellige opgaver.
> Dette er en ikke-udtømmende liste over applikationstyper, som KAN laves med
> Delphi:
> Windows GUI applikationer, .NET applikationer, konsol-applikationer, NT
> services, DLL'er, Active-X, Control panel applets
En hel masse Windows-snask. Hvem har brug for det? ;-)
> database-applikationer,
> web-services, hjemme-sider (cgi, isapi m.v.), ASP.NET m.v.
Tjaeh. Hvis et sprog har adgang til TCP/IP, er der jo nærmest ingen
grænser for hvad man kan lave...
Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf
Henning Makholm
> "Uffe Kousgaard" <o...@no.no> writes:
>> Nemlig. Kun meget få opgaver er "upraktiske eller umulige" med
>> Delphi.
> Er funktioner førsteklassesobjekter, dvs. kan man bruge en funktion
> som argument til en anden funktion?
Lige netop det er ikke nogen god forklaring af hvad det vil sige at
funktioner er førsteklassesobjekter, når vi taler Pascal.
I Jensen & Wirth-Pascal kunne funktioner (og procedurer) godt bruges
som argumenter til underprogrammer, men de var netop _ikke_
førsteklasses. De kunne nemlig ikke gemmes i variable. Det var en
bevidst begrænsning for at undgå at en reference til et indlejret
underprogram kunne overleve levetiden af det omgivende underprograms
lokale variable. Derfor kunne det hele stakallokeres så man ikke havde
brug for heapallokerede closures.
Compas/Poly/Turbo/Borland Pascal implementerede aldrig dette hjørne af
J&W, ihvertfald ikke mens jeg fulgte med i dens udvikling. Derimod
indlånt Borland-dialekten på et tidspunkt C's begreb om
funktionspointere, vist nok for at kunne udtrykke Windows 3.x-API'et.
De var mere førsteklasses end J&W's procedurale parametre, men kunne i
begyndelsen ikke henvise til indlejrede underprogrammer. Jeg har hørt
rygter om at Delphi, efter jeg forlod Pascalverdenen, er begyndt at
understøtte pointere til indlejrede underprogrammer ved at generere
nogen implicitte trampoliner. Jeg ved ikke helt hvordan den håndterer
levetiden af disse pointere i forhold til levetiden af det omgivende
underprograms variable.
> Hvad æstetik angår har Pascalfamilien af sprog en syntaks, der
> generer mig, især med alt det begin/end,
Det er lidt mere bogstavrigt end C-familiens { og }, men hvis man
måler i antal linjer kode (og skærmhøjde er ihvertfald i min hverdag
den knappeste ressource med hensyn til programoverskuelighed) gør det
jo ingen forskel.
--
Henning Makholm "It was intended to compile from some approximation to
the M-notation, but the M-notation was never fully defined,
because representing LISP functions by LISP lists became the
dominant programming language when the interpreter later became available."
Henrik Stidsen
> Det får mig hverken til at anbefale Visual Basic eller C til
> programmer med høje stabilitets og sikkerhedskrav.
Jeg anbefaler ikke Delphi, jeg konkluderer blot at noget af landets
vigtigste software (formentlig) er skrevet i Delphi og dermed at Delphi
*kan* bruges til den slags ting.
Jeg vil dog gentage at jeg ikke ved om det er tilfældet at
alarmcentralernes software er skrevet i Delphi, men jeg tror det
baseret på det faktum at firmaet søger Delphi programmører når de søger
nye folk.
--
Henrik Stidsen - http://henrikstidsen.dk/
Uffe Kousgaard
> Pokkers også, den er heller ikke helt god. Hvad dælen gør vi nu? Jeg
> tror, vi bliver nødt til at nøjes med at konkludere, at du/din
> virksomhed har haft stor glæde af Delphi.
Fint, at du fangede provokationen. Næste trin i argumentationen er så, at
hvis min virksomhed kan have glæde af Delphi, så kan det også tænkes at
andre kan og så er det måske lidt mere end det legetøjsværktøj, som det ofte
bliver udråbt til af ikke-kendere?
> Nu er der jo (heldigvis) et godt stykke fra 'Delphi er bedre at
> arbejde med end C++' til 'Delphi er det bedste all-round værktøj'. Jeg
> er ingen haj til nogen af delene, men jeg tror da også, jeg ville
> vælge Delphi over C++, hvis jeg blev nødt til det. Men nu er verden jo
> heldigvis større end blot de to valg.
Med de opgaver jeg har, kan jeg ikke se andre alternativer end netop Delphi
og C++ til mine kerneprodukter.
> Jeg finder det ret uprofessionelt, men desværre også meget
> almindeligt, at man som programmør kan affeje noget så vigtigt med at
> kalde det en 'akademisk øvelse', underforstået ubrugeligt i praksis,
> blot fordi udbyttet ikke er trivielt at måle.
Nej, det er ikke uprofessionelt. Det er resultatet af en vurdering: Hvor
meget tid vil det tage? Hvad kan der være at vinde ved det? Hvad kunne jeg
have brugt tiden til istedet? Det er den slags vurderinger man foretager i
en professionel virksomhed, hvor tid ikke er en gratis resource.
> Ja, men hvis ikke man vil lave GUI-applikationer til Windows, er der
> så nogen særlig grund til at bruge Delphi?
Den letlæselige kildekode, f.eks.
Den hurtige kompilering.
Blot et par eksempler.
>> Prøv f.eks. at lave en DLL (altså ikke en OCX) med VB6. Det kan man
>> bare ikke. Det samme gælder med en windows-driver i Delphi. Det kan
>> man heller ikke, da windows-DDK fra MS kun kan anvendes med C / C++.
>> Så der er altså helt faktuelle begrænsninger.
>
> Jeg har en formodning om, at det blot er et spørgsmål om at lave et
> mellemlag. Mit eget yndlingssprog, Python, har den slags mellemlag til
> alt mellem himmel og jord (blandt andet :-)).
Lyder interessant. Jeg vil måske kigge lidt på python.
> Hvad æstetik angår har Pascalfamilien af
> sprog en syntaks, der generer mig, især med alt det begin/end, og det
> viser sig desværre i PL/SQL, som jeg hacker hele dagen lang. Så
> hellere tuborgparenteser som i C-familien eller indrykning som i
> Python.
Ja, der har jeg det lige omvendt.
hilsen
Uffe
Uffe Kousgaard
news:lIY1f.70227$Fe7.2...@news000.worldonline.dk...
>> Faktum er, at Delphi er det bedste all-round værktøj, der eksisterer i
>> dag. Og mest produktive.
>
> Det udsagn kommer vist mest af personlig erfaring med at udvikle i Delphi,
> ikke? Jeg kan fiske et par fanatiske perl-programmører frem, som vil påstå
> præcis det samme for perl. Hvad skal vi så stille op? Skal vi arrangere en
> perl/Delphi-shootout?
Perl er et script-sprog, ikke? Med mindre perl kan meget mere end andre
script-sprog, så kan det ikke tilnærmelsesvis løse en brøkdel af de opgaver
jeg har. Kan du f.eks. lave en DLL med perl?
Eneste sprog som jeg ser som et relevant alternativ for mig er C++. Jeg vil
også godt medgive, at det kan løse allerflest typer opgaver (flere end
Delphi), men det er ikke ligeså produktivt.
> At du generealiserer din situation til også at gælde alle andre, synes jeg
> er problematisk.
Nu plejer denne slags diskussioner at starte med, at delphi bliver udråbt
til at være et legetøjsværktøj af folk, som ikke kender det. Derfor er det
nødvendigt ind imellem at fortælle en konkret historie om, at man altså
sagtens kan anvende Delphi til meget mere og det er der også mange som gør.
> Specielt når det fremgår ret tydeligt at du ikke har bred erfaring med
> andre sprog.
Jeg har tidligere arbejdet med basic, assembler, prolog, fortran og anvender
fortsat mapbasic og php, når de er relevante. Jeg har også snuset til både
c++ og java (via datamatiker-kursus). Er det nok?
>> Der er også områder som Delphi ikke er så godt til: low-level drivere,
>> kompilering på sun, mac m.m. Men har man ikke dette behov, er det jo ikke
>> noget problem.
>
> Det er da et eksempel på en begrænsning, som jeg under ingen
> omstændigheder ville acceptere i rigtig mange af de projekter, jeg har
> arbejdet i. Igen er det historien om forskellige værktøjer til forskellige
> opgaver.
Man kan også se på det på den denne måde: Hvilke opgaver har jeg? Skulle der
måske være ét værktøj som er ret godt til dem alle? Det er måske ikke det
allerbedste til alle opgaverne, men værdien af at kende det ene til bunds
overstiger ulempen ved ikke at have valgt et andet til enkelte af opgaverne.
hilsen
Uffe
Michael Zedeler
> "Michael Zedeler" <mic...@zedeler.dk> wrote in message
> news:lIY1f.70227$Fe7.2...@news000.worldonline.dk...
>
>
>>>Faktum er, at Delphi er det bedste all-round værktøj, der eksisterer i
>>>dag. Og mest produktive.
>>
>>Det udsagn kommer vist mest af personlig erfaring med at udvikle i Delphi,
>>ikke? Jeg kan fiske et par fanatiske perl-programmører frem, som vil påstå
>>præcis det samme for perl. Hvad skal vi så stille op? Skal vi arrangere en
>>perl/Delphi-shootout?
>
> Perl er et script-sprog, ikke? Med mindre perl kan meget mere end andre
> script-sprog, så kan det ikke tilnærmelsesvis løse en brøkdel af de opgaver
> jeg har. Kan du f.eks. lave en DLL med perl?
Hvad skal man bruge DLL'er til?
Jeg har arbejdet i 10 år med systemudvikling og aldrig haft brug for at
lave en DLL. Desuden har ActiveStates perl en COM-bro, så hvis jeg
endelig skal snakke med noget Windows-halløj, kan jeg bare bruge den.
> Eneste sprog som jeg ser som et relevant alternativ for mig er C++. Jeg vil
> også godt medgive, at det kan løse allerflest typer opgaver (flere end
> Delphi), men det er ikke ligeså produktivt.
Er du klar over at ordet "produktivt" ikke er universelt, eller tror du
virkelig at hvis bare alle programmører i hele verden skifter til
Delphi, ville det gå meget hurtigere?
>>At du generealiserer din situation til også at gælde alle andre, synes jeg
>>er problematisk.
>
> Nu plejer denne slags diskussioner at starte med, at delphi bliver udråbt
> til at være et legetøjsværktøj af folk, som ikke kender det. Derfor er det
> nødvendigt ind imellem at fortælle en konkret historie om, at man altså
> sagtens kan anvende Delphi til meget mere og det er der også mange som gør.
Ja. Men det ser ud til at du fortsætter med generaliseringerne lang tid
efter at folk er begyndt at diskutere i detaljer med dig.
> Jeg har tidligere arbejdet med basic, assembler, prolog, fortran og anvender
> fortsat mapbasic og php, når de er relevante. Jeg har også snuset til både
> c++ og java (via datamatiker-kursus). Er det nok?
Det kan jeg ikke bedømme. Det eneste, jeg hæfter mig ved, er at du
tilsyneladende mener at alle relevante opgaver, har noget med DLL'er på
Windows at gøre (og andet Windows-halløj). Så lever du altså i en
osteklokke. Den er stor, men der er altså mange ting udenfor den alligevel.
>>Det er da et eksempel på en begrænsning, som jeg under ingen
>>omstændigheder ville acceptere i rigtig mange af de projekter, jeg har
>>arbejdet i. Igen er det historien om forskellige værktøjer til forskellige
>>opgaver.
>
> Man kan også se på det på den denne måde: Hvilke opgaver har jeg? Skulle der
> måske være ét værktøj som er ret godt til dem alle? Det er måske ikke det
> allerbedste til alle opgaverne, men værdien af at kende det ene til bunds
> overstiger ulempen ved ikke at have valgt et andet til enkelte af opgaverne.
Klart. Og det er da godt for dig. Men hvad skal vi andre bruge det til?
Du skriver som om du er den eneste person i hele verden.
"If you only have a hammer, you tend to see every problem as a nail.",
Abraham Maslow.
Uffe Kousgaard
>
> Hvad skal man bruge DLL'er til?
Efter det spørgsmål vil jeg så afslutte diskussionen. Det fører tydeligvis
ikke til noget.
Jens Axel Søgaard
> Hvad skal man bruge DLL'er til?
De er praktiske, hvis man skal blander sprog. Man skriver
funktionen foo i sprog A. Laver en DLL. I sprog B åbner man
så DLL'en og fisker funktionen foo ud.
--
Jens Axel Søgaard
mic...@zedeler.dk
> funktionen foo i sprog A. Laver en DLL. I sprog B åbner man
> så DLL'en og fisker funktionen foo ud.
Det var ment som et retorisk spørgsmål. Jeg ved godt hvordan de
fungerer, men mener at der findes masser af udviklere, som aldrig får
brug for at fremstille dem selv.
At Uffe så vælger af afslutte diskussionen på grund af mit udsagn,
synes jeg er tegn på at han har bortskåret en meget stor andel
udviklere fra sin verdensopfattelse. Undertegnede inklusive.
Mvh. Michael.
Erlo Haugen
> Hej.
>
> Der er et væld af programmeringssprog. Jeg kan umiddelbart nævne (af hvem
> jeg kender af navn) C, Delphi, Java, Java script, VB, Perl, php m.v.
>
> Men jeg har ikke det fjerneste overblik over de forskellige sprog.
>
> Er der en, der vil bruge omkring 10 minutter på at kommentere en række sprog
> (ikke nødvendigvis ovenstående, da jeg dels ønsker et bredt kendskab til
> sprog generelt inden jeg går i detaljer for selv at lære).
>
> Jeg er velvidende, at man ikke kan sige, "hvilket sprog der er bedst" da det
> både er smag og behag samt afhænger af situation og behov m.v.
>
> Men jeg kunne især godt tænke mig at høre lidt kommentarer omkring følgende.
>
> Sværhedsgrad
> Fordele
> Ulemper
> Anvendelighed (hvor og til hvad har sproget sine anvendeligheder)
> Krav (kompetencer forinden og systemkrav)
> Hvad der ellers falder Jer ind.
>
>
> Findes der evt. en (dansk) oversigt på nettet eller i form af skriftlig
> litteratur.
>
>
Du kan jo kigge lidt på Ada. www.adapower.com / www.adaworld.com
Det er Pascal-lignende, let at læse, fås til mange platforme og er
standardiseret. Pga. standardiseringen er det rimeligt let at lave
portabel kode.
Sproget er objektorienteret uden at det dog tvinger brugeren til at
bruge objektdelen, som tilfældet er med Java.
Tasks er en del af sproget, med en stærk synkroniseringsmekanisme, som
jeg mener at Java mangler.
Enumereringstyper og egendefinerede typer er også en del af sproget.
Sidst, men ikke mindst skal lige nævnes at der stærkt typecheck, som gør
at ret mange indekseringsfejl og andet af den slags findes allerede
under oversættelsen.
Ada er et stort sprog, som kan virke uoverskueligt i starten, hvis man
prøver at forstå det hele, men tag en lille bid af gangen, så er det
faktisk ret forståeligt.
--
Erlo
-----
The statements and opinions are mine and does not
neccesarily reflect those of my employers
Jens Axel Søgaard
>>De er praktiske, hvis man skal blander sprog. Man skriver
>>funktionen foo i sprog A. Laver en DLL. I sprog B åbner man
>>så DLL'en og fisker funktionen foo ud.
>
> Det var ment som et retorisk spørgsmål. Jeg ved godt hvordan de
> fungerer, men mener at der findes masser af udviklere, som aldrig får
> brug for at fremstille dem selv.
Det kan godt være - men har du virkelig aldrig haft behov for
at blande sprog?
--
Jens Axel Søgaard
Morten Guldager
Jeg blander mig lige med en kommentar om at det er let at blande
andre sprog ind i perlprogrammer ved hjælp af perls inline biblioteker.
Det fine er at programmøren ikke behøver at forstå de mekanismer
der gøres brug af. (jeg har ihvertfald klaret mig fint uden at
fatte magien omme bag ved :-)
Men jeg har selvfølgelig også klaret broderparten i perl, så banket
en pose bits i C, for at vende tilbage til perl og afslutte "opgaven"
Det kan godt være det er lidt mere bøvlet hvis man koder sin web-side
i mason og det indbyggede ekspertsystem i prolog....
Men der hvor jeg kommer fra vil man så forsøge at lave AI tingen som
nogle rpc ligende ting som kan kaldes fra andre programmer.
/Morten %-)
Michael Zedeler
>>> så DLL'en og fisker funktionen foo ud.
>>
>> Det var ment som et retorisk spørgsmål. Jeg ved godt hvordan de
>> fungerer, men mener at der findes masser af udviklere, som aldrig får
>> brug for at fremstille dem selv.
>
> Det kan godt være - men har du virkelig aldrig haft behov for
> at blande sprog?
Joda, men der er mange andre måder at gøre det på. De gange, jeg har
haft brug for det, er det enten vha. pipes på unix (i 99% af tilfældene)
ellers har det været via en eller anden RPC-mekanisme imellem to
runtime-miljøer, f. eks. RMI, SOAP eller noget lignende.
Faktisk løj jeg også da jeg skrev at jeg _aldrig_ havde haft brug for
DLL'er, for jeg har været projektleder for et projekt, hvor vores
hovedprodukt netop var en DLL, men igen var det for at stille tingene på
spidsen. Det er også blot et projekt ud af måske 50 stykker.
Igen vil jeg slå på tromme for at folk får øjenene op for alle de
spændende sprog og udviklingsmiljøer, der findes, frem for at kode med
skyklapperne på. Hvis tilgangsvinklen er at undersøge hvad der findes af
ren og skær interesse, er sandsynligheden for at man finder noget som
kan bruges, så meget større.
Mvh. Michael.
P.s. jeg giver en kasse øl (til afhentning på Østerbro) til den første,
som implementerer den Ungarske algoritme i Flip. (Se
http://216.249.163.93/bob.pilgrim/445/munkres.html og
http://www.daimi.au.dk/~eriksoe/Flip/.)
Henrik Stidsen
> Den letlæselige kildekode, f.eks.
Hvordan er Delphis kildekode lettere at læse end f.eks. C# ?
Uffe Kousgaard
news:mn.5ad37d5ad...@news.hs235.dk...
> Uffe Kousgaard formulated on søndag :
>> Den letlæselige kildekode, f.eks.
>
> Hvordan er Delphis kildekode lettere at læse end f.eks. C# ?
Sammenligningen var primært rettet mod C/C++.
Henrik Stidsen
>>> Den letlæselige kildekode, f.eks.
>> Hvordan er Delphis kildekode lettere at læse end f.eks. C# ?
> Sammenligningen var primært rettet mod C/C++.
Jamen så prøver jeg igen:
Hvordan er Delphis kildekode lettere at læse end f.eks. C/C++ ?
Mads Bahrt
> Uffe Kousgaard explained on 11-10-2005 :
>
>>>> Den letlæselige kildekode, f.eks.
>
>
>>> Hvordan er Delphis kildekode lettere at læse end f.eks. C# ?
>
>
>> Sammenligningen var primært rettet mod C/C++.
>
>
> Jamen så prøver jeg igen:
>
> Hvordan er Delphis kildekode lettere at læse end f.eks. C/C++ ?
>
væsentligt større mulighed for at være det. Det er ikke tilfældigt at
det er i C man holder konkurrencer i at skrive ulæselige programmer
(http://www.ioccc.org/).
Henrik Stidsen
>> Hvordan er Delphis kildekode lettere at læse end f.eks. C/C++ ?
> C og C++ kildekode behøver ikke at være sværere læseligt, men har væsentligt
> større mulighed for at være det. Det er ikke tilfældigt at det er i C man
> holder konkurrencer i at skrive ulæselige programmer (http://www.ioccc.org/).
Nu var det ikke så meget muligheden for at skrive grim kode, mere
hvordan Delphi var nemmere at læse end C/C++.
Jeg mener f.eks. at VB.NET er ret forvirrende at læse i forhold til C#
- mange mener vist det er den anden vej rundt...
Brian Elmegaard
> væsentligt større mulighed for at være det. Det er ikke tilfældigt at
> det er i C man holder konkurrencer i at skrive ulæselige programmer
> (http://www.ioccc.org/).
De kan ikke hamle op med
ftp://tug.ctan.org/pub/tex-archive/macros/plain/contrib/misc/xii.tex
--
Brian (remove the sport for mail)
http://www.et.web.mek.dtu.dk/Staff/be/be.html
http://www.rugbyklubben-speed.dk
Peter Lykkegaard
> Hvordan er Delphis kildekode lettere at læse end f.eks. C/C++ ?
>
På samme måde som arabisk er lettere at læse end kinesisk
Eller var det omvendt? - hmmm
- Peter
Henrik Stidsen
>> Hvordan er Delphis kildekode lettere at læse end f.eks. C/C++ ?
> På samme måde som arabisk er lettere at læse end kinesisk
> Eller var det omvendt? - hmmm
Med andre ord, præcis som jeg tænkte, så er det noget med hvilket sprog
man har lært først/kan bedst ?
Mogens Hansen
"Uffe Kousgaard" <o...@no.no> wrote in message
news:434b9783$0$84015$edfa...@dtext01.news.tele.dk...
Lad os starte med at slå et par ting fast:
* Alle generaliseringer (inkl. denne) er en voldsom simplificering af
virkeligheden.
* Det som man er vandt til er nemmest.
F.eks. finder jeg det væsentligt nemmere at læse dansk end kinesisk -
selvom det intet objektiv siger om hvad der er lettest.
En global afstemning vil sikkert ende med 1.2 milliarder syntes
kinesisk er nemmest og 5 millioner syntes dansk er nemmest - og det siger
heller ikke noget.
* _jeg_ finder det ubetinget lettere at læse og skrive C++ end Delphi
Language - det kan overhovedet ikke diskuteres.
Lad os være helt konkrete med 2 stykker _fuldstændig_ ækvivalent kode- det
ene skrivet med Delphi Language og det andet med C++ (med lidt Borland
C++Builder specifik udvidelse). Koden er meget almindelig og relevant i
Delphi/C++Builder, hvor en Form (vindue) viser en anden form (dialogbox)
Delphi Language:
procedure TMyForm.OnButtonClick (Sender:OBject);
var
f:TOtherForm;
begin
f:=TOtherForm.Create (self);
try
f.ShowModal;
finally
FreeAndNil (f);
end;
end;
C++ (Borland C++Builder):
void __fastcall TMyForm::Button1Click(TObject *Sender)
{
auto_ptr<TOtherForm> f(new TOtherForm(this));
f->ShowModal();
}
Det taler vist for sig selv.
Hvis det ikke havde været for C++Builders slægtskab med Delphi havde man i
C++ skrevet
void TMyForm::Button1Click(TObject *Sender)
{
TOtherForm f(this);
f.ShowModal();
}
hvilket iøvrigt praktisk taget, og ikke tilfældigt, svarer til hvad man
skriver med C++/CLI til .NET:
System::Void button1_Click(System::Object^ sender, System::EventArgs^ e)
{
OtherForm f;
f.ShowDialog();
}
For fuldstændighedens skyld er den tilsvarende C# kode
private void button1_Click(object sender, EventArgs e)
{
using(OtherForm f = new OtherForm) {
f.ShowDialog();
}
}
Jeg ved godt hvad jeg syntes er lettest at læse (og skrive og vedligeholde).
Hvis du syntes at eksemplerne er urealistiske (hvad de bestemt ikke er), så
vil jeg opfordre dig til i Delphi Language at løse den opgave der er
beskrevet i sprogsammenligningen
http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprt_computer2000.pdf.
Jeg vil så til gengæld love at komme med 3 løsninger:
* Skrevet i C++: Meget effektiv og rimelig let læselig
* Skrevet i C++: Rimelig effektiv og meget let læselig
* Skrevet i Python: Ikke specielt effektiv men let læselig
Venlig hilsen
Mogens Hansen
Peter Makholm
> Delphi Language:
>
> procedure TMyForm.OnButtonClick (Sender:OBject);
> var
> f:TOtherForm;
> begin
> f:=TOtherForm.Create (self);
> try
> f.ShowModal;
> finally
> FreeAndNil (f);
> end;
> end;
>
> C++ (Borland C++Builder):
>
> void __fastcall TMyForm::Button1Click(TObject *Sender)
> {
> auto_ptr<TOtherForm> f(new TOtherForm(this));
> f->ShowModal();
> }
>
> Det taler vist for sig selv.
Nu er jeg bedre til C++ end til Delphi. Jeg har ikke brugt pascal
siden Turbo Pascal 5.noget. Men af ovenstående er Delphi-udgaven den
der tiltaler mig mest.
I Delphi må du tilsyneladnede selv ryde op efter dig, men det vejes op
af at skulle pille ved 'calling convention' og bruge pointer og
template-snask i C++udgaven. Resten er bare et spørgsmål om at
begin/end fylder mere end {}.
> Hvis det ikke havde været for C++Builders slægtskab med Delphi havde man i
> C++ skrevet
> void TMyForm::Button1Click(TObject *Sender)
> {
> TOtherForm f(this);
> f.ShowModal();
> }
Men denne er pænere, men dog kun et spørgsmål om ikke selv at ryde op
efter f.
--
Peter Makholm | Emacs is the only modern general-purpose
pe...@makholm.net | operating system that doesn't multitask
http://hacking.dk |
Christian Iversen
>
> "Uffe Kousgaard" <o...@no.no> wrote in message
> news:434b9783$0$84015$edfa...@dtext01.news.tele.dk...
>> "Henrik Stidsen" <nntp...@hs235.dk> wrote in message
>> news:mn.5ad37d5ad...@news.hs235.dk...
>>> Uffe Kousgaard formulated on søndag :
>>>> Den letlæselige kildekode, f.eks.
>>>
>>> Hvordan er Delphis kildekode lettere at læse end f.eks. C# ?
>>
>> Sammenligningen var primært rettet mod C/C++.
>
> Lad os starte med at slå et par ting fast:
> * Alle generaliseringer (inkl. denne) er en voldsom simplificering af
> virkeligheden.
Godt, så er vi enige så langt :-)
> * Det som man er vandt til er nemmest.
> F.eks. finder jeg det væsentligt nemmere at læse dansk end kinesisk
> - selvom det intet objektiv siger om hvad der er lettest.
> En global afstemning vil sikkert ende med 1.2 milliarder syntes
> kinesisk er nemmest og 5 millioner syntes dansk er nemmest - og det siger
> heller ikke noget.
Godt :)
> * _jeg_ finder det ubetinget lettere at læse og skrive C++ end Delphi
> Language - det kan overhovedet ikke diskuteres.
Fint.
> Lad os være helt konkrete med 2 stykker _fuldstændig_ ækvivalent
Ja, hvis du med "fuldstændig" mener "næsten" ;-)
> kode det ene skrivet med Delphi Language og det andet med C++ (med lidt
> Borland C++Builder specifik udvidelse). Koden er meget almindelig og
> relevant i Delphi/C++Builder, hvor en Form (vindue) viser en anden form
> (dialogbox)
> Delphi Language:
>
> procedure TMyForm.OnButtonClick (Sender:OBject);
> var
> f:TOtherForm;
> begin
> f:=TOtherForm.Create (self);
> try
> f.ShowModal;
> finally
> FreeAndNil (f);
> end;
> end;
>
> C++ (Borland C++Builder):
>
> void __fastcall TMyForm::Button1Click(TObject *Sender)
> {
> auto_ptr<TOtherForm> f(new TOtherForm(this));
> f->ShowModal();
> }
>
> Det taler vist for sig selv.
Ja, du bruger auto_ptr i C++, uden at bruge en tilsvarende i Delphi. Lad os
prøve at lade være med det, så bliver C++-koden: (så vidt jeg husker)
void __fastcall TMyForm::Button1Click(TObject *Sender)
{
TOtherForm f = new TOtherForm(this);
try {
f.ShowModal();
} finally {
delete f;
}
}
Så er det pludselig ret ens, ikke? :-)
Omvendt, så kan du jo bruge en auto_ptr-lignende konstruktion i Delphi:
procedure TMyForm.OnButtonClick (Sender:OBject);
var
f:IAutoPointer;
begin
f:=TAutoPointer(TOtherForm.Create(self));
TOtherForm(f.get).ShowModal;
end;
Og så minder det pludselig om C++
TAutoPointer er ikke det rigtige klassenavn, men en tilsvarende klasse
findes. Ellers kan den snildt skrives (fylder 20 linier tops)
> Hvis du syntes at eksemplerne er urealistiske (hvad de bestemt ikke er),
> så vil jeg opfordre dig til i Delphi Language at løse den opgave der er
> beskrevet i sprogsammenligningen
> http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprt_computer2000.pdf.
Må jeg vende tilbage om det? Jeg har ret travlt i øjeblikket, men det kunne
være sjovt. Ikke at det kan bruges til noget, men man har jo kun det fun
man selv blander :-)
> Jeg vil så til gengæld love at komme med 3 løsninger:
> * Skrevet i C++: Meget effektiv og rimelig let læselig
> * Skrevet i C++: Rimelig effektiv og meget let læselig
> * Skrevet i Python: Ikke specielt effektiv men let læselig
Hvor er de datafiler der bruges?
--
M.V.H
Christian Iversen
Henning Makholm
> De kan ikke hamle op med
> ftp://tug.ctan.org/pub/tex-archive/macros/plain/contrib/misc/xii.tex
Wow!
--
Henning Makholm "However, the fact that the utterance by
Epimenides of that false sentence could imply the
existence of some Cretan who is not a liar is rather unsettling."
Bertel Brander
> C og C++ kildekode behøver ikke at være sværere læseligt, men har
> væsentligt større mulighed for at være det. Det er ikke tilfældigt at
> det er i C man holder konkurrencer i at skrive ulæselige programmer
> (http://www.ioccc.org/).
Det skyldes nok mest at C er fleksibelt nok til at kunne lave
ulæselig kode. At lave en konkurrence i at lave ulæselig kode
i C++ er ikke sjovt, man laver blot nogle få sære operator
overloads og nogle templates, så er der ingen der kan læse
det.
Men der kan også laves pæn læselig kode i C og C++.
--
Absolutely not the best homepage on the net:
http://home20.inet.tele.dk/midgaard
But it's mine - Bertel
Mogens Hansen
"Christian Iversen" <chri...@iversen-net.dk> wrote in message
news:2537638.t...@iversen-net.dk...
> Mogens Hansen wrote:
[8<8<8<]
>> Lad os være helt konkrete med 2 stykker _fuldstændig_ ækvivalent
>
> Ja, hvis du med "fuldstændig" mener "næsten" ;-)
Den må du gerne uddybe.
Det sker _præcis_ det samme:
1. En TOtherForm bliver allokeret på heapen og constructoren bliver
udført
2. Dialogen bliver vist som modal dialogboks
3. Når dialogen lukkes bliver destructoren kaldt og hukommelsen frigivet
Dette gælder uanset om funktionen afslutter normal eller afbrydes af
en exception.
[8<8<8<]
> Ja, du bruger auto_ptr i C++, uden at bruge en tilsvarende i Delphi.
Jeps - det er en idiomatisk konstruktion i C++.
Hvordan vil du skrive den i Delphi, så den kan bruges med en hvilken som
helst type Form ?
> Lad os
> prøve at lade være med det, så bliver C++-koden: (så vidt jeg husker)
>
> void __fastcall TMyForm::Button1Click(TObject *Sender)
> {
> TOtherForm f = new TOtherForm(this);
> try {
> f.ShowModal();
> } finally {
> delete f;
> }
> }
>
> Så er det pludselig ret ens, ikke? :-)
Naturligvis kan man det - men hvorfor skulle man skrive det på den måde, som
er klart mere kompliceret og mindre "C++ agtig" ?
[8<8<8<]
> TAutoPointer er ikke det rigtige klassenavn, men en tilsvarende klasse
> findes. Ellers kan den snildt skrives (fylder 20 linier tops)
Vil du være venlig at gøre det, således at TAutoPointer typesikkert kan
bruges sammen med en hvilken som helst type, herunder samtlige type afledt
fra TForm ?
[8<8<8<]
> Må jeg vende tilbage om det? Jeg har ret travlt i øjeblikket, men det
> kunne
> være sjovt. Ikke at det kan bruges til noget, men man har jo kun det fun
> man selv blander :-)
Det er faktisk en rimelig sjov opgave.
Undersøgelsen, og min erfaring med opgaven, viser at måden man tænker på er
mere afgørende end hvilket sprog man bruger for produktivitet og
korrekthed - heldigvis.
[8<8<8<]
> Hvor er de datafiler der bruges?
Ups - det havde jeg glemt at skrive:
http://page.mi.fu-berlin.de/~prechelt/packages/pspe_testdata_package.zip
Venlig hilsen
Mogens Hansen
Morten Guldager
> Scripsit Brian Elmegaard <br...@rkspeed-rugby.dk>
>
>> De kan ikke hamle op med
>> ftp://tug.ctan.org/pub/tex-archive/macros/plain/contrib/misc/xii.tex
>
> Wow!
Det undrer mig bare at han sådan uden videre offentliggører krypteringsnøglen
der kan gå fra kortnummer til pinkode der bruges i dankortsystemet.
(og at man samtidig kan aflæse skostørelsen)
/Morten %-)
Bertel Brander
> Mads Bahrt <mads_...@hotmail.com> writes:
>
>
>>væsentligt større mulighed for at være det. Det er ikke tilfældigt at
>>det er i C man holder konkurrencer i at skrive ulæselige programmer
>>(http://www.ioccc.org/).
>
>
> De kan ikke hamle op med
> ftp://tug.ctan.org/pub/tex-archive/macros/plain/contrib/misc/xii.tex
Det mest læsevenlige sprog må være whitespace:
http://www.livejournal.com/users/debaday/14410.html
Mogens Hansen
"Peter Makholm" <pe...@makholm.net> wrote in message
news:873bn8q...@xyzzy.adsl.dk...
> "Mogens Hansen" <moge...@dk-online.dk> writes:
[8<8<8<]
> I Delphi må du tilsyneladnede selv ryde op efter dig, men det vejes op
> af at skulle pille ved 'calling convention'
Jeg kan ikke se at den mængde ekstra kode opvejes af de faktorer du
fremhæver.
Det er slagtskabet med Delphi der påtrykker det "calling convention"
specifikationen.
> og bruge pointer
Der er hverken mere eller mindre brug af pointer i C++ koden.
> og
> template-snask i C++udgaven.
Det sprog brug siger mig blot noget om personlig præference - ikke noget
objektivt.
Jeg finder det pænt, smart og nødvendigt i et statisk typet objekt
orienteret sprog - jeg skal nok undlade henvisning til Generics i Java, C#
og Delphi om et års tid :-).
> Resten er bare et spørgsmål om at
> begin/end fylder mere end {}.
Sådanne detaljer finder jeg _fuldstændigt_ ligegyldig - og det opfatter jeg
også at du mener.
[8<8<8<]
>> void TMyForm::Button1Click(TObject *Sender)
>> {
>> TOtherForm f(this);
>> f.ShowModal();
>> }
>
> Men denne er pænere, men dog kun et spørgsmål om ikke selv at ryde op
> efter f.
Det er sandelig da også vigtigt for hvor "tedios and error prone" koden er
at skrive.
Jeg mener faktisk at det allervigtigste er at programmerings stilen i C++
gør det simplere at skrive kode der også virker korrekt i tilfælde af
exceptions.
Venlig hilsen
Mogens Hansen
Henrik Stidsen
> Det mest læsevenlige sprog må være whitespace:
> http://www.livejournal.com/users/debaday/14410.html
Og så er der nogen der mener nørder er kedelige ;)
Henning Makholm
>>> ftp://tug.ctan.org/pub/tex-archive/macros/plain/contrib/misc/xii.tex
>> Wow!
> Det undrer mig bare at han sådan uden videre offentliggører krypteringsnøglen
> der kan gå fra kortnummer til pinkode der bruges i dankortsystemet.
> (og at man samtidig kan aflæse skostørelsen)
Har du prøvet at TeXe filen? Resultatet er særdeles imponerende.
--
Henning Makholm "Det nytter ikke at flygte
der er henna overalt"
Adam Sjøgren
> Det sprog brug siger mig blot noget om personlig præference - ikke
> noget objektivt.
Hvordan kan man sige noget objektivt om hvilket af to programmer der
er pænest?
Mvh.
--
"Alla sammanträffande med verkligheten är helt Adam Sjøgren
slumpmässiga, alla melodier är påhittade." as...@koldfront.dk
Michael Zedeler
> ftp://tug.ctan.org/pub/tex-archive/macros/plain/contrib/misc/xii.tex
Hvad så med denne her:
not exp log srand xor s qq qx xor
s x x length uc ord and print chr
ord for qw q join use sub tied qx
xor eval xor print qq q q xor int
eval lc q m cos and print chr ord
for qw y abs ne open tied hex exp
ref y m xor scalar srand print qq
q q xor int eval lc qq y sqrt cos
and print chr ord for qw x printf
each return local x y or print qq
s s and eval q s undef or oct xor
time xor ref print chr int ord lc
foreach qw y hex alarm chdir kill
exec return y s gt sin sort split
Sakset fra http://en.wikipedia.org/wiki/Just_another_Perl_hacker
Mvh. Michael.
Mads Bahrt
> Mads Bahrt wrote:
>
>> C og C++ kildekode behøver ikke at være sværere læseligt, men har
>> væsentligt større mulighed for at være det. Det er ikke tilfældigt at
>> det er i C man holder konkurrencer i at skrive ulæselige programmer
>> (http://www.ioccc.org/).
>
>
> Det skyldes nok mest at C er fleksibelt nok til at kunne lave
> ulæselig kode. At lave en konkurrence i at lave ulæselig kode
> i C++ er ikke sjovt, man laver blot nogle få sære operator
> overloads og nogle templates, så er der ingen der kan læse
> det.
>
> Men der kan også laves pæn læselig kode i C og C++.
>
Netop min pointe - jeg gjorde det måske ikke klart nok.
Jens Axel Søgaard
> Hvis du syntes at eksemplerne er urealistiske (hvad de bestemt ikke er), så
> vil jeg opfordre dig til i Delphi Language at løse den opgave der er
> beskrevet i sprogsammenligningen
> http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprt_computer2000.pdf.
Erann Gat [*] brugte opgaven til en Lisp/Java-undersøgelse.
<http://www.flownet.com/gat/papers/lisp-java.pdf>
Peter Norvig ("Director of Search Technology" for Google) løste opgaven
i Common Lisp:
<http://www.norvig.com/java-lisp.html>
[*] Han har nu skiftet navn til Ron Garret. I kid you not:
<http://www.flownet.com/gat/eg-rg-faq.html>
--
Jens Axel Søgaard
Kim Hansen
> Det mest læsevenlige sprog må være whitespace:
> http://www.livejournal.com/users/debaday/14410.html
Samme ide er ogsaa lavet i Perl:
http://search.cpan.org/~dconway/Acme-Bleach-1.12/lib/Acme/Bleach.pm
--
Kim Hansen
Michael Zedeler
To af mine nørd-venner snakkede om et sprog ved navn "Char", hvor det er
størrelsen af programmet, der udgør selve programmet. "Hello, world.",
skulle efter sigende fylde flere gigabytes. Men så er der da plads til
dokumentationen (og et par Star Trek Film) :-)
Peter Makholm
> Det sprog brug siger mig blot noget om personlig præference - ikke noget
> objektivt.
> Jeg finder det pænt, smart og nødvendigt i et statisk typet objekt
*Du* finder det pænt,smart og nødvendigt?!? Og *min* sprogbrug er
ikke objektiv.
> orienteret sprog - jeg skal nok undlade henvisning til Generics i Java, C#
> og Delphi om et års tid :-).
Fint, så skal jeg nok lade være med at henvise til rigtig type-polymorfi.
>> Resten er bare et spørgsmål om at
>> begin/end fylder mere end {}.
>
> Sådanne detaljer finder jeg _fuldstændigt_ ligegyldig - og det opfatter jeg
> også at du mener.
Ikke destro mindre er det den eneste reele forskel jeg kan se på dine
eksempler, når vi ser bort fra de detaljer som du undskylder med netop
slægtskabet med Delphi.
--
Peter Makholm | Why does the entertainment industry wants us to
pe...@makholm.net | believe that a society base on full surveillance
http://hacking.dk | is bad?
| Do they have something to hide?
Jacob Sparre Andersen
>>> Scripsit Brian Elmegaard <br...@rkspeed-rugby.dk>
>>>> ftp://tug.ctan.org/pub/tex-archive/macros/plain/contrib/misc/xii.tex
> Har du prøvet at TeXe filen? Resultatet er særdeles imponerende.
Imponerende er lidt af en underdrivelse. Det er sejt. Men koden er
ikke helt let at læse.
Jacob
--
"if a person can't communicate,
the very least he can do is to shut up!"
Christian Iversen
> Henning Makholm skrev:
>>>> Scripsit Brian Elmegaard <br...@rkspeed-rugby.dk>
>
>>>>> ftp://tug.ctan.org/pub/tex-archive/macros/plain/contrib/misc/xii.tex
>
>> Har du prøvet at TeXe filen? Resultatet er særdeles imponerende.
>
> Imponerende er lidt af en underdrivelse. Det er sejt. Men koden er
> ikke helt let at læse.
Ikke helt let at læse er lidt af en underdrivelse. Det er svært. Men det ser
lidt sjovt ud.
--
M.V.H
Christian Iversen
dk_sz
> til Delphi, man kan ikke bruge Delphi til at programmere
Det er jeg så ikke helt sikker på...
Det har altid været en af Delphi styrker den
nærmest uendelig række af componenter
og større biblioteker der findes... Så...
mvh
Thomas
Henning Makholm
> Henning Makholm skrev:
>> Har du prøvet at TeXe filen? Resultatet er særdeles imponerende.
> Imponerende er lidt af en underdrivelse. Det er sejt. Men koden er
> ikke helt let at læse.
Det må man sige. I nedenstående version har jeg erstattet alle
catcode-trickene og et par yderligere rædsler (fx mellemrum brugt som
parameteradskiller) med "læselige" escapesekvenser. Så er det en smule
lettere at overskue hvordan teksten bliver foldet ud.
\def\ZYX#1#2#3{#3#2#1}
\def\XYX#1<#2>{#1#2#1}
\def\YXX#1#2{#2#1#1}
\def\XlYX#1#2{#1l#2#1}
\def\Xi#1{#1i}
\def\Xdi#1{#1di}
\def\oXd#1{o#1d}
\def\SP{ }
\def\one{\SP a\SP}
\def\w{w}
\def\null{}
\def\en{en}
\def\th{th}
\def\ev{ev}
\def\f{f}
\def\ing{\ZYX gni}
\def\eat#1{}
\def\ve{ve}
\def\stmas{st\ZYX sam}
\def\our{\ZYX ruo}
\def\istmasm{i\stmas\SP m}
\def\ird{\ZYX dri}
\def\ers{\ZYX sre\SP}
\def\eig{\ZYX gie}
\def\perhapsand{\SP}
\def\fimover#1\fi{\fi#1}
\def\start{\bigskip\ZYX}
\def\ondayN#1{%
\start\SP nO\th e\SP#1\th\SP\ZYX yad\ZYX\f o\SP
\SP\ZYX rhC\istmasm y\SP\ZYX urt\XlYX{e\SP}{ov}%
ga\ve\SP t\ZYX e\ZYX om\SP\null
}
\def\lineloop#1#2#3#4\thgaveN#5\ING#6{%
\par
#1#2#3#5\ing
\ifx\DONE#6\else\fimover\lineloop#6\fi
}
\def\stanzaloop#1\thgaveN#2\ING#3\DONE{%
\if.#3.\else\stanzaloop#3\DONE\fi
\ondayN{#1}%
\lineloop#1\thgaveN#2\ING#3\DONE
}
\stanzaloop
t\w el\f\thgaveN l\ve\SP\XYX dr\YXX mu<\ers>\ING
\XlYX e\null v\en\thgaveN v\en\SP\XYX pip<\ers>\ING
t\en\null \thgaveN \null\SP\XYX l<\oXd rs\one>eap\ING
\XYX n<i>\thgaveN i>e\SP l\Xdi aes\SP d\ZYX cna\ING
\null\eig\null h\thgaveN ht\SP\XYX m<\Xdi\ZYX as\one>ilk\ING
s\ev\null \en\thgaveN \en\SP\XYX s\w<ans\one>\YXX mi\ING
\Xi sx\thgaveN \null\SP\YXX egse\one\ZYX yal\ING
\f i\null \f\thgaveN \ve\SP\ZYX logd\SP r\ing s\eat\ING
\f\null\our \thgaveN \SP c\YXX la\ing\SP b\ird s\eat\ING
\th\eat\ondayN \ird\eat\thgaveN ree \f r\en ch\SP h\en s\eat\ING
\null\eat E\ZYX ces\oXd n\eat\thgaveN
\XYX t<\w o\SP>\ZYX trul\null e do\ve s\eat\ING
\eat k\null \ZYX ri\f st\eat\thgaveN
a\perhapsand\def\perhapsand{nd\one}%
p\XYX ar<tridge\SP in\one pe>\SP t\YXX er.\eat\ING
\DONE
\bye
--
Henning Makholm "Okay, okay, life's a beach."
Mogens Hansen
[8<8<8<]
> *Du* finder det pænt,smart og nødvendigt?!? Og *min* sprogbrug er
> ikke objektiv.
Jeg kan godt forstå hvad du mener og tager det til mig.
Det jeg oponerede imod var egentlig udtrykket "template-snask" som ikke
fortæller mig ret meget om hvad du mener.
[8<8<8<]
> Ikke destro mindre er det den eneste reele forskel jeg kan se på dine
> eksempler, når vi ser bort fra de detaljer som du undskylder med netop
> slægtskabet med Delphi.
Den reele forskel er at i Delphi skal man dele arbejdet op i 3 forskellige
blokke
1. Erklæring af en variabel (var blokken)
2. Oprettelse af et objekt og tildeling af variabel (try blokken)
3. Nedlæggelse af objektet (finally blokken)
I C++ sker det eet sted.
Man skal derfor kun kigge eet sted i C++ for at overbevise sig om at koden
er korrekt og komplet.
Venlig hilsen
Mogens Hansen
Mogens Hansen
"Adam "Sjøgren"" <as...@koldfront.dk> wrote in message
news:87mzlf4...@koldfront.dk...
> On Tue, 11 Oct 2005 22:46:53 +0200, Mogens wrote:
>
>> Det sprog brug siger mig blot noget om personlig præference - ikke
>> noget objektivt.
>
> Hvordan kan man sige noget objektivt om hvilket af to programmer der
> er pænest?
Jeg opfatter er ordet "pænest" som noget med hvor let og sikkert det er at
skrive korrekte programmer, og tilsvarende at læse og vedligeholde dem.
Man kan godt sige noget rimeligt objektivt om hvilke programmer man mener er
lettest at skrive, læse og forstå.
Detaljer som hvorvidt man skriver
begin
f:=TOtherForm.Create (self);
eller
{
f = new TOtherForm(this);
kan vi vel blive enige om er fuldstændigt ligegyldige - det kræves i begge
tilfælde at man har lidt forståelse af sproget.
Men når tager lidt mere af koden
var
f:TOtherForm;
begin
f:=TOtherForm.Create (self);
og
TOtherForm* f = new TOtherForm(this);
så begynder der at opstå en lille forskel.
I Delphi koden skal man kigge 2 steder for at få den fulde information.
Det må objektivt kunne siges at være mindre læsevenligt.
C++ adskiller fra Delphi Language ved at man kan erklære variable på det
sted i en funktionsblok hvor man har brug for den, og derfor er i stand til
at initialisere den.
Når man skriver den kode i C++ eller Delphi, så pådrager man sig et ansvar
for manuelt at nedlægge det igen. For at løfte det ansvar ender man med den
kode som jeg skriv tidligere i tråden (med mindre vi håndfast får påvist at
min Delphi kode er suboptimal).
I f.eks. Java, C# og Delphi.NET vil garbage collectoren på et tidspunkt
nedlægge det - men det er ikke deterministisk og det øger presset på garbage
collectoren. Det er således ikke ækvivalente programmer.
I Delphi koden skal man læse 3 steder for at overbevise sig om at det er
korrekt, hvorimod man i C++ programmet forsat kun skal kigge eet sted.
Det må objektivt kunne siges at Delphi koden er mindre læsevenlig.
I C# eksemplet har man med "using statement", lidt tilsvarende C++ koden, i
samme udtryk erklæret variablen, allokeret og sikret sig deterministik
oprydning. Internt i C# compileren bliver det omskrevet svarende til
try/finally konstruktionen i Delphi.
Det er værd at bemærke at "using statement" blev tilføjet C# efter feedback
fra de første beta versioner, netop for at løse det "problem" som man har i
Delphi.
Jeg mener dog også at læsbarheden med C# "using statement" skalerer
dårligere end C++ (og C++/CLI) ved større eksempler.
Venlig hilsen
Mogens Hansen
Brian Elmegaard
> Det må man sige. I nedenstående version har jeg erstattet alle
> catcode-trickene og et par yderligere rædsler (fx mellemrum brugt som
> parameteradskiller) med "læselige" escapesekvenser. Så er det en smule
> lettere at overskue hvordan teksten bliver foldet ud.
Tak, så vil jeg prøve bare at tyde en smule af det.
--
Brian (remove the sport for mail)
http://www.et.web.mek.dtu.dk/Staff/be/be.html
http://www.rugbyklubben-speed.dk
Uffe Kousgaard
news:434d26d1$0$78280$157c...@dreader1.cybercity.dk...
> I Delphi koden skal man kigge 2 steder for at få den fulde information.
> Det må objektivt kunne siges at være mindre læsevenligt.
> C++ adskiller fra Delphi Language ved at man kan erklære variable på det
> sted i en funktionsblok hvor man har brug for den, og derfor er i stand
> til at initialisere den.
Til gengæld ved man i Delphi altid, hvor en variabel er defineret, nemlig i
"var"-sektionen. I C++ kan man risikere at skulle finde dette inde midt i
andre linier program-kode.
Så dit minimale eksempel er måske nok læsevenligt, men det ville et større
(realistisk) ikke nødvendigvis være.
hilsen
Uffe
Mogens Hansen
[8<8<8<]
> Så dit minimale eksempel er måske nok læsevenligt, men det ville et større
> (realistisk) ikke nødvendigvis være.
Det kan vi hurtigt blive enige om.
Omvendt vil Delphi kode ikke nødvendigvis være mere læseligt.
Intet er givet på forhånd og sproget i sig selv kan ikke garantere
læsbarhed.
Den opgave, jeg nævnte tidligere i tråden, som blev brugt til sprog
sammenligning, er realistisk og det kunne være interessant at sammenligne en
løsning fra en erfaring Delphi programmør som dig.
Venlig hilsen
Mogens Hansen
Christian Iversen
Korrekt, og der findes header-filer til et meget stort udvalg af
C-biblioteker, hvorimod C sjældent eller aldrig kan bruge Delphi-kode (med
mindre man da skriver det så det kan)
--
M.V.H
Christian Iversen
Uffe Kousgaard
>
> Den opgave, jeg nævnte tidligere i tråden, som blev brugt til sprog
> sammenligning, er realistisk og det kunne være interessant at sammenligne
> en løsning fra en erfaring Delphi programmør som dig.
Jeg har skimmet artiklen og det ser ud til at være en realistisk og
interessant metode til at sammenligne programmerings-sprog på den type
opgaver (jeg har ikke sat mig ind i hvilken opgave det er). Tiden til det er
der nok ikke lige nu, men nu er den i alle fald skrevet ud og så må jeg læse
den senere.
hilsen
Uffe