Delphin virheetön koodi

"Tuota kun vertaat Delphin koodiin, on helppo todistaa koodin virheettömyyttä, ja paikantaa olemassa olevat virheet vaikka vuokaavion avulla, silloin kun sitä tarvitaan."

Tuo ei ole formaalia todistamista. Minä tarkoitan tällä sitä, että on spesifikaatio ja todistetaan formaalisti, että ohjelma on vapaa virheistä.

Todistus on siis sitä, että esim. pythagoraan lauseke a^2 b^2 = c^2 pätee aina sillä suorakulmaisella kolmiolla.

Kun puhutaan virheettömyydestä, sekin tarvitsee todistamista matematiikalla.

Esimerkiksi Delphissä väärä suoritusjärjestys voi aiheuttaa bugin ja pitäisi voida todistaa, että sellaista bugia ei ole.

"Tästä en ole samaa mieltä, jos rutiinit pidetään sellaisissa pituuksissa, että sopivat kokonaisuudessaan yhdelle näytölle, ja päärunko vain kutsuu hyvin kuvaavasti nimettyjä ali rutiineja, pysyy koodi hyvin luettavana."

Sopii näytölle? Kännykän näytölle vai pöytäkoneen? On tavallista, että rutiinit vievät esim. kolme riviä tai sitten kielen ilmaisukyky on paska jos rivejä menee vaikka näytöllisiä.

"Tuo väittämä oli kovasti esillä silloin kun QBasic, Delphin vastapeluri salli muuttujien lennosta käyttöön oton. Tämähän korjautu sitten myöhemin, kun voitiin QBasic ohjelman alkuun määritellä esto, joka pakotti muuttujien esittelyn ennen kuin se voitiin ottaa käyttöön."

Miksi sitä Delphiä on pitänyt johonkin QBasicciin verrata kun sitä oli sillloinkin läjäpäin kieliä staattisella tyypityksellä?

"Tänä päivänä tuo ei ole enään mikään kilpailu valtti, vaan samat esittelyt tehdään aina kielestä riippumatta."

90-luvun alussa oli myös Ada, C, C jotka vaativat sitä tyypitystä.

"Jotenka väittämä taitaa olla historiaa."

Ei se oikein ole pätenyt ikinä koska kieli on mahdollistanut samojen bugien tekemistä. Kielissä kun on myös tekniikoita monien bugien estämiseksi kokonaan ja Delphissä niitä on nihkeästi.

Affiliate-Julkaisia:lle tiedoksi:

M-Kar on tunnettu
Delphin vihaaja, ja hänen idioottimaiset kommenttinsa kannattaa jättää huomiotta.

En ole koskaan formaalisti pyrkinyt ohjelman lähdekoodia todistamaan, se on yleensä tarpeetonta, ja sitä yleensä pidetään mahdottomana.

Delphi on kielenä kuitenkin erittäin selkeää, ja tässä on sen 1 vahvuus.

Päinvastoin kuin M-Karin älyvapaa väite: "Kielissä kun on myös tekniikoita monien bugien estämiseksi kokonaan ja Delphissä niitä on nihkeästi", totuus on toinen:

Delphistä löytyy esim {$R }
jolla saa Range Check -ominaisuuden päälle.

JOS se on päällä, niin:

var
a : Array[1..10] of byte

procedure Aseta(Index, Value:Integer);
begin
a[Index] := Value; // Aiheuttaa poikkeuksen, jos Index < 1 tai jos Index > 10.
end;

Esim. C- kielessä EI OLE vastaavaa!

Tässä vain 1 esimerkki, miksi Delphi on C -kieltä turvallisempaa.

Delphi on myös riittävän ilmaisuvoimainen kaikkiin käytännön tarpeisiin.
Se, että Delphissä ei ole jotain yksittäistä muotiominaisuutta, sillä ei ole mitään merkitystä!

Yksi tapa tuottaa Delphillä virheetöntä koodia:

hyödynnä Delphin luokkaominaisuuksia!

Eli suunnittele kukin luokka siten, että se estää ko. luokan väärinkäytön!

Miksi tuhlaisin aikaani miettimällä jotain teoreettisia todistuksia, kun samaan aikaan voin kirjoittaa virheetöntä koodia Delphillä?

Joo, näitä Delphi Compiler Directive eli kääntäjän ohjaamiseen tarkoitettuja sääntöjähän löytyy 100 . . . 150 en nyt muista tarkkaan, kun on vähemmän tullut ohjeistettua tuota kääntäjää.

Minullekin on ihan sama voidaanko vai eikö voida asioita todistella matemaattisesti, en ole mikään matematiikko, eikä ole M-Kar sen enempää, pidän Delphistä, se on hyvä ja tehokas ympäristö, helposti omaksuttavissa.

Olen joskus hämmästynyt Delphin suoritusnopeudesta, jonkin silmukan suhteen, jossa, sama on tehty C ja Delphillä, käännetty ja ajettu, jossa Delphin käännös on ollut nopeampi.

Lisäksi tuommonen todistelu ei kuulu mitenkään ohjelmointiin, jos nyt ajattelee ihan kansan tajuisesti tilanetta, meneekö suojatien yli nyt vai rupeaako laskeskelemaan mihin vuoden, kuukauden, päivän aikaan, ja millä nopudella suojatien vois ylittää että olis suurin mahdollisuus selvitä siitä hengissä, jää se suojatie varmasti ylittämättä. Ei siihen tarvita mitään matematiikkaa, se tehdään tai ollaan tekemättä ja sillä hyvä.

Niin tuo C jättää noita vastaavia juttuja enemän kuin mitä C . Yritin tähän nyt jonkin esimerkin raapasta, kun vasta törmäsin tilanteeseen (alta 5 vrk), mutta enhän minä enään muista sitä mikä se oli.

JOO, ei muuta, PIDETÄÄN DELPHIN LIPPU KORKEALLA, se on sen ansainnut.

Delphillä_laadukkaampaa kirjoitti:

Affiliate-Julkaisia:lle tiedoksi:

M-Kar on tunnettu
Delphin vihaaja, ja hänen idioottimaiset kommenttinsa kannattaa jättää huomiotta.

En ole koskaan formaalisti pyrkinyt ohjelman lähdekoodia todistamaan, se on yleensä tarpeetonta, ja sitä yleensä pidetään mahdottomana.

Delphi on kielenä kuitenkin erittäin selkeää, ja tässä on sen 1 vahvuus.

Päinvastoin kuin M-Karin älyvapaa väite: "Kielissä kun on myös tekniikoita monien bugien estämiseksi kokonaan ja Delphissä niitä on nihkeästi", totuus on toinen:

Delphistä löytyy esim {$R }
jolla saa Range Check -ominaisuuden päälle.

JOS se on päällä, niin:

var
a : Array[1..10] of byte

procedure Aseta(Index, Value:Integer);
begin
a[Index] := Value; // Aiheuttaa poikkeuksen, jos Index < 1 tai jos Index > 10.
end;

Esim. C- kielessä EI OLE vastaavaa!

Tässä vain 1 esimerkki, miksi Delphi on C -kieltä turvallisempaa.

Delphi on myös riittävän ilmaisuvoimainen kaikkiin käytännön tarpeisiin.
Se, että Delphissä ei ole jotain yksittäistä muotiominaisuutta, sillä ei ole mitään merkitystä!

Yksi tapa tuottaa Delphillä virheetöntä koodia:

hyödynnä Delphin luokkaominaisuuksia!

Eli suunnittele kukin luokka siten, että se estää ko. luokan väärinkäytön!

Miksi tuhlaisin aikaani miettimällä jotain teoreettisia todistuksia, kun samaan aikaan voin kirjoittaa virheetöntä koodia Delphillä?

Lue lisää

"M-Kar on tunnettu
Delphin vihaaja, ja hänen idioottimaiset kommenttinsa kannattaa jättää huomiotta."

Olen realisti.

"En ole koskaan formaalisti pyrkinyt ohjelman lähdekoodia todistamaan, se on yleensä tarpeetonta, ja sitä yleensä pidetään mahdottomana."

Ei ole mahdotonta. Sillä todistamisella voidaan osoittaa virheettömäksi. Aika hyvään tulokseen päästään myös DO-178B sertifioidulla koodilla.

"Delphi on kielenä kuitenkin erittäin selkeää, ja tässä on sen 1 vahvuus."

Mihin perustat sen selkeyden? Sille selkeydelle on ihan mittaustapa myös olemassa: https://en.wikipedia.org/wiki/Halstead_complexity_measures

"Delphistä löytyy esim {$R }
jolla saa Range Check -ominaisuuden päälle."

Tuollaisessa ominaisuudessa ei ole mitään ihmeellistä ja sitä on muuallakin. Tämä ei ole mikään Delphissä oleva erityisjuttu.

"Esim. C- kielessä EI OLE vastaavaa!"

Miksi vertaat C-kieleen?

"Delphi on myös riittävän ilmaisuvoimainen kaikkiin käytännön tarpeisiin.
Se, että Delphissä ei ole jotain yksittäistä muotiominaisuutta, sillä ei ole mitään merkitystä!"

Onhan sillä merkitystä sillä virheiden välttämisen kanssa. Kompleksisuudella on havaittu yhteys sen kanssa miten paljon virheitä on koodissa ja sitä aiheuttaa mm. koodissa olevat haarautumiset ja ehdot kuin myös itse ohjelmointikielen ilmaisukyky. Nuo ovat laskettavia asioita tietysti.

"Yksi tapa tuottaa Delphillä virheetöntä koodia: hyödynnä Delphin luokkaominaisuuksia!"

Luokkien käyttö ei todista virheettömyydestä ja luokkien tekeminen on aika perusjuttuja, ei mikään Delphissä oleva erityisjuttu.

"Miksi tuhlaisin aikaani miettimällä jotain teoreettisia todistuksia, kun samaan aikaan voin kirjoittaa virheetöntä koodia Delphillä?"

Havaintojen perusteella ihmiset kirjoittavat koodiin virheitä ohjelmointikielestä riippumatta ja virheiden määrä on verrannollinen kompleksisuuteen joka on koodin rakenteessa kuin myös kompleksisuutteen mitä ohjelmointikieli itsessään tekee kun toteutetaan koodia. Se kompleksisuus on havaintoihin perustuva todennäköisyys virheille.

Jos halutaa virheettömyyttä, se pitäisi voida osoittaa. Formaali todistus osoittaa virheettömyyttä tai vähän tiukemmat prosessit mahdollistaa sitä.

Delphissä taas ei ole mitään sellaista ominaisuutta mikä tekisi koodin virheettömäksi ja kyllä nuo range checkit ja luokat ovat ihan perusjuttuja eikä mitään kummallista virheettömäksi tekevää Delphikoodia.

En vittsi kaikkeen sanomaasi puuttua (on humpuukkia), mutta sinä vaadit toista todistelemaan, mutta mikset itse ensin todista väittämääsi, niillä matemaatisilla kaavoilla.

("Delphissä taas ei ole mitään sellaista ominaisuutta mikä tekisi koodin virheettömäksi ja kyllä nuo range checkit ja luokat ovat ihan perusjuttuja eikä mitään kummallista virheettömäksi tekevää Delphikoodia..")

ÄLÄ NYT PUHU PASKAA
Todista että sinä ymmärrät matemaatisesti todistetun virheettömyyden, antamalla näytteen kaavasta jolla väität noita virheitä löytyvän.

Affiliate-Julkaisia kirjoitti:

Joo, näitä Delphi Compiler Directive eli kääntäjän ohjaamiseen tarkoitettuja sääntöjähän löytyy 100 . . . 150 en nyt muista tarkkaan, kun on vähemmän tullut ohjeistettua tuota kääntäjää.

Minullekin on ihan sama voidaanko vai eikö voida asioita todistella matemaattisesti, en ole mikään matematiikko, eikä ole M-Kar sen enempää, pidän Delphistä, se on hyvä ja tehokas ympäristö, helposti omaksuttavissa.

Olen joskus hämmästynyt Delphin suoritusnopeudesta, jonkin silmukan suhteen, jossa, sama on tehty C ja Delphillä, käännetty ja ajettu, jossa Delphin käännös on ollut nopeampi.

Lisäksi tuommonen todistelu ei kuulu mitenkään ohjelmointiin, jos nyt ajattelee ihan kansan tajuisesti tilanetta, meneekö suojatien yli nyt vai rupeaako laskeskelemaan mihin vuoden, kuukauden, päivän aikaan, ja millä nopudella suojatien vois ylittää että olis suurin mahdollisuus selvitä siitä hengissä, jää se suojatie varmasti ylittämättä. Ei siihen tarvita mitään matematiikkaa, se tehdään tai ollaan tekemättä ja sillä hyvä.

Niin tuo C jättää noita vastaavia juttuja enemän kuin mitä C . Yritin tähän nyt jonkin esimerkin raapasta, kun vasta törmäsin tilanteeseen (alta 5 vrk), mutta enhän minä enään muista sitä mikä se oli.

JOO, ei muuta, PIDETÄÄN DELPHIN LIPPU KORKEALLA, se on sen ansainnut.

Lue lisää

"Minullekin on ihan sama voidaanko vai eikö voida asioita todistella matemaattisesti, en ole mikään matematiikko, eikä ole M-Kar sen enempää, pidän Delphistä, se on hyvä ja tehokas ympäristö, helposti omaksuttavissa."

Delphin ongelma on se, että siinä ei ole mitään sellaista miksi pitäisi käyttää sitä kun parempaakin löytyy.

"Lisäksi tuommonen todistelu ei kuulu mitenkään ohjelmointiin"

Tuota noin, kyllä kuuluu, Silloin kun tehdään virheetöntä koodia.

"jos nyt ajattelee ihan kansan tajuisesti tilanetta, meneekö suojatien yli nyt vai rupeaako laskeskelemaan mihin vuoden, kuukauden, päivän aikaan, ja millä nopudella suojatien vois ylittää että olis suurin mahdollisuus selvitä siitä hengissä, jää se suojatie varmasti ylittämättä."

Todennäköisyyslaskenta perustuu havaintoihin ja on induktuuvista mutta todistettaessa koodin virheettömyyttä, päättely tehdään deduktiivisesti.

Deduktiivisella päättelyllä osoitetaan onko mahdollista jäädä auton alle jossain tilanteessa. Parempi esimerkki voisi olla vaikka metroliikenne, että on osoitetaan formaalisti että kun vaihteita käännellään ja nopeuksia säädellään niin ei voidaan formaalisti todistaa, että junat eivät voi missään olosuhteessa törmätä.

"Olen joskus hämmästynyt Delphin suoritusnopeudesta, jonkin silmukan suhteen, jossa, sama on tehty C ja Delphillä, käännetty ja ajettu, jossa Delphin käännös on ollut nopeampi."

C kääntäjiin on laitettu niin paljon resursseja, että jos toimii hitaammin niin silmukan implementoinnissa on tehty joku virhe, mittavirhe tai on kääntäjän asetukset pielessä. Voi päästä kyllä samaankin nopeuteen mutta jos on jotain huomattavaa nopeutta Delphin eduksi niin se vihjaa siitä, että on jossain virhe.

"Niin tuo C jättää noita vastaavia juttuja enemän kuin mitä C ."

Mitä juttuja?

Delphiä voi muuten ennemmin verrata kieliin joka on kyseiseen ongelmaan ja vaatimusmäärittelyyn parhaiten sopiva.

Tässähän voidaan hakea suorituskykyä, mahdollisimman helppoa virheettömäksi todistamista, helppoutta loppukäyttäjälle, koodin selkeyttä jne.

En nyt tajua miksi pitää aina sitä C:tä yrittää tuputtaa sen tilalle. Kuitenkin kun Delphi on sovellusohjelmointiin ja C on systeemitason ohjelmointiin ja siinäkin on eroa miten näillä on tarkoitettu palikoida sitä ratkottavaa ongelmaa. C:llä kun esimerkiksi se ilmeinen tapa rakentaa komponentteja on unix putket ja vanhan ajan Delphissä tehtiin komponentteja VCL kirjastoa laajentamalla.

("Delphiä voi muuten ennemmin verrata kieliin joka on kyseiseen ongelmaan ja vaatimusmäärittelyyn parhaiten sopiva.")

Mihin ongelmaan viittaat, ei Delphissä ole ongelmaa. Vain sinulla on ongelma delphin suhteen.

Mihin kieliin viittaat, onko muitakin kieliä missä sinulla on ongelmia.

-

Affiliate-Julkaisia kirjoitti:

En vittsi kaikkeen sanomaasi puuttua (on humpuukkia), mutta sinä vaadit toista todistelemaan, mutta mikset itse ensin todista väittämääsi, niillä matemaatisilla kaavoilla.

("Delphissä taas ei ole mitään sellaista ominaisuutta mikä tekisi koodin virheettömäksi ja kyllä nuo range checkit ja luokat ovat ihan perusjuttuja eikä mitään kummallista virheettömäksi tekevää Delphikoodia..")

ÄLÄ NYT PUHU PASKAA
Todista että sinä ymmärrät matemaatisesti todistetun virheettömyyden, antamalla näytteen kaavasta jolla väität noita virheitä löytyvän.

Lue lisää

"En vittsi kaikkeen sanomaasi puuttua (on humpuukkia), mutta sinä vaadit toista todistelemaan, mutta mikset itse ensin todista väittämääsi, niillä matemaatisilla kaavoilla."

Niin kun tämä väittämä, että ohjelmat olisi jotenkin maagisesti virheettömiä kun niitä tehdään Delphillä ei ole minun. Havaintojen perusteella ohjelmia kirjoitettaessa tulee virheitä ja todennäköisyys virheisiin riippuu kompleksisuudesta. Lisäksi se todennäköisyys virheiden tekemiselle on vieläpä huomattavan korkea joten jos puhutaan virheettömyydestä niin siihen se menetelmä on se formaali verifiointi.

"Todista että sinä ymmärrät matemaatisesti todistetun virheettömyyden, antamalla näytteen kaavasta jolla väität noita virheitä löytyvän."

x > x 1

M-Kar kirjoitti:

"En vittsi kaikkeen sanomaasi puuttua (on humpuukkia), mutta sinä vaadit toista todistelemaan, mutta mikset itse ensin todista väittämääsi, niillä matemaatisilla kaavoilla."

Niin kun tämä väittämä, että ohjelmat olisi jotenkin maagisesti virheettömiä kun niitä tehdään Delphillä ei ole minun. Havaintojen perusteella ohjelmia kirjoitettaessa tulee virheitä ja todennäköisyys virheisiin riippuu kompleksisuudesta. Lisäksi se todennäköisyys virheiden tekemiselle on vieläpä huomattavan korkea joten jos puhutaan virheettömyydestä niin siihen se menetelmä on se formaali verifiointi.

"Todista että sinä ymmärrät matemaatisesti todistetun virheettömyyden, antamalla näytteen kaavasta jolla väität noita virheitä löytyvän."

x > x 1

Lue lisää

("x > x 1") = ("Siis rutiini = subroutine = funktio") samaa paskaa.

PELLE, et siis pysty etkä osaa. Et tunne delphi, etkä osaa tehdä sillä mitään. Sivistys-sanoja viljelet ja yrität hämätä ja tarjota mielikuvaa että olisit asioista perillä.

Affiliate-Julkaisia kirjoitti:

("Delphiä voi muuten ennemmin verrata kieliin joka on kyseiseen ongelmaan ja vaatimusmäärittelyyn parhaiten sopiva.")

Mihin ongelmaan viittaat, ei Delphissä ole ongelmaa. Vain sinulla on ongelma delphin suhteen.

Mihin kieliin viittaat, onko muitakin kieliä missä sinulla on ongelmia.

-

Lue lisää

"Mihin ongelmaan viittaat"

Siihen ongelmaan mihin kirjoitetaan joku ohjelma. Voidaan verrata Delphiä ja sellaista työkalua mikä sopii paremmin tähän.

Katsos kun Delphissä sellainen järkyttävä haittapuoli että olkoot kyseessä mikä tahansa ongelma mihin tarvitsisi ohjelmistokehitysvälinettä, aina näyttäisi löytyvän parempi työkalu.

Se tekee sitten sen, että Delphiä ei oikein käytä kukaan kun parempiakin löytyy. Delphin käyttö näyttää rajoittuvan tästä syystä aika pitkälti vanhojen ohjelmien ylläpitoon, ajalta jolloin Delphillä oli vahvuuksia.

"Mihin kieliin viittaat, onko muitakin kieliä missä sinulla on ongelmia."

Ei minulla ole minkään kielien kanssa "ongelmia". Olet nähtävästi todella typerä kun tulkitset tekstin väittämällä, että minulla olisi jonkun työkalun käytön kanssa jotain ongelmia.

Ongelmalla tarkoitettaan tässä asiaa jota ratkotaan käyttämällä sitä työkalua, esimerkiksi lasketaan kolmion pinta-ala (hyvin yksinkertainen ongelma) tai joku projekti johon valitaan työkalut (vaikka potilastietojärjestelmä). Delphiä ei tietystikään käytetä mihinkään kun aina löytyy parempi työkalu.

Affiliate-Julkaisia kirjoitti:

("x > x 1") = ("Siis rutiini = subroutine = funktio") samaa paskaa.

PELLE, et siis pysty etkä osaa. Et tunne delphi, etkä osaa tehdä sillä mitään. Sivistys-sanoja viljelet ja yrität hämätä ja tarjota mielikuvaa että olisit asioista perillä.

Lue lisää

Ahaa, siis väität että

x > x 1

..on tosi? Voitko todistaa, että tuo on tosi?

Minä väitän, että x > x 1 on epätosi, kaikilla x arvoilla ja voin toki todistaa sen.

Affiliate-Julkaisia kirjoitti:

En vittsi kaikkeen sanomaasi puuttua (on humpuukkia), mutta sinä vaadit toista todistelemaan, mutta mikset itse ensin todista väittämääsi, niillä matemaatisilla kaavoilla.

("Delphissä taas ei ole mitään sellaista ominaisuutta mikä tekisi koodin virheettömäksi ja kyllä nuo range checkit ja luokat ovat ihan perusjuttuja eikä mitään kummallista virheettömäksi tekevää Delphikoodia..")

ÄLÄ NYT PUHU PASKAA
Todista että sinä ymmärrät matemaatisesti todistetun virheettömyyden, antamalla näytteen kaavasta jolla väität noita virheitä löytyvän.

Lue lisää

Tässä mainio esimerkki: JOS OpenSSL olisi koodattu Delphillä, HeartBleed -bugia ei olisi koskaan tapahtunut!

Aiheesta muualla netissä:

"Modern languages, like delphi when using {$R }, range check all array accesses, so if the source language for openssl were delphi compiled using {$R }, this exploit would not exist. Almost all memory exploits are associated with old school languages such as C and C which depend on the programmer to check their own array accesses."

Mitä tulee kielen selkeyteen ja ilmaisuvoimaan, käytän omia aivojani, en tarvitse tuohon arviointiin M-Karin puffaamaa

https://en.wikipedia.org/wiki/Halstead_complexity_measures

sivua.

Oikein käytettynä muuten Delphin property:t ovat mainio lisä jo muutenkin ilmaisuvoimaiseen kieleen.

Samoin Delphin mahdollisuus tehdä näin:

TAnyClientConnType = Class of TClientConn;

var
Q : TAnyClientConnType;

myöhemmin koodissa:

CC := Q.Create();

tuolloin CC voi olla tyyppiä TClientConn tai mitä tahansa siitä joko suoraan tai välillisesti periytyvää tyyppiä.

Syy, miksi M-Karin mittari kannattaa jättää omaan arvoonsa:

Jos M-Karin mittarilla mitataan, niin silloin C on varmaankin ilmaisuvoimaisempi kuin Delphi, siksi kun C :ssa on moninperintä, Delphissä luokkien osalta ei ole (mutta interface:jen osalta ON!)

Tuo ei nimittäin ole mikään Delphin puute/vika, vaan Delphi on tarkoituksella suunniteltu näin!

Delphin alkuperäisen suunnittelijan mukaan moninperintää on liian helppo väärinkäyttää ja sen todelliset hyödyt ovat varsin vähäiset.

Ja niissä harvoissa tapauksissa, joissa moninperinnästä olisi jotain hyötyä, niissä Delphissä käytetään interface:jen moninperintää, ja itse luokka on ilman moninperintää, mutta siinä voi käyttää Delphin Delegate -ominaisuutta, josta lisätietoja hakusanalla implements.

Yksityiskohtia en muista, koska edes tuota implements tarvitsee käytännössä varsin harvoin, mutta Delphissä se kuitenkin on mukana, eli valmiina käytettäväksi, jos sille tulee tarve vastaan.

Ja vielä yksi asia:

Ilmeisesti kääntäjien välillä on nykyisin kova kilpailu, ja siksi kääntäjien (myös Delphin uudemmissa versioissa) on mukana kaikki mahdolliset ns. Buzzwordit.

Kokonaan eri asia, onko kaikista mahdollisista Buzzwordeista jotain käytännön hyötyä ohjelmointityön kannalta.

Veikkaanpa, että usein ei, eli ne Buzzwordit ovat mukana, eivät ohjelmoijien takia, vaan niiden ns. Excel -johtajien, jotka tekevät eri ohjelmointityövälineistä Excel -taulukon, ja sitten ajattelevat, että mitä enemmän Buzzwordeja joku työväline tukee, sen parempi se varmaan on.

Todellisuudessa Buzzwordit ohjelmoinnissa ovat vähän kuin muoti vaatteissa, eli siitä hyötyy vaatebisnes, ei muotia oikeasti kukaan mihinkään tarvitse.

Jos tuo M-Karin suosikkitesti https://en.wikipedia.org/wiki/Halstead_complexity_measures mittaa sitä, montako Buzzwordia kussakin työvälineessä on tuettuna, niin vaikka Delphi häviäisi tämän kisan, mitä ihmeen merkitystä sillä on ohjelmointityön kannalta?

Käytännössä ei mitään.

Käytän Delphiä, koska se on hyvä työväline tehdä niin sovelluksia (EXE) kuin myös kirjastoja (DLL), ja todellakin, jos olisin koodannut OpenSSL:n alusta alkaen Delphillä, niin HeartBleed -haavoittuvuutta ei olisi koskaan tapahtunut.

Mutta M-Karin mielestä on parempi koodata kirjastot C:llä, täytyyhän esim. NSA:n päästä murtautumaan kaikkiin tietojärjestelmiin, ja C -kielen käyttö on tapa varmistaa, että aina löytyy bugeja, joiden avulla NSA saavuttaa tavoitteensa ja voi aina murtautua kaikkiin tietojärjestelmiin.

Ehkäpä M-Kar on NSA:n palkkaama kirjoittaja, jolle NSA maksaa rahaa siitä, että hän kirjoittelee tänne Delphi -vastaisia tekstejä.

Niin minä tekisin (= palkkaisin M-Karin kirjoittelemaan tänne Delphi -vastaisia tekstejä), jos olisin NSA:n johtaja ja haluaisin varmistua, että jatkossakin riittää haavoittuvuuksia, joiden avulla NSA voi murtautua, minne haluaa, ja usein jopa jälkiä jättämättä.

M-Kar kirjoitti:

"M-Kar on tunnettu
Delphin vihaaja, ja hänen idioottimaiset kommenttinsa kannattaa jättää huomiotta."

Olen realisti.

"En ole koskaan formaalisti pyrkinyt ohjelman lähdekoodia todistamaan, se on yleensä tarpeetonta, ja sitä yleensä pidetään mahdottomana."

Ei ole mahdotonta. Sillä todistamisella voidaan osoittaa virheettömäksi. Aika hyvään tulokseen päästään myös DO-178B sertifioidulla koodilla.

"Delphi on kielenä kuitenkin erittäin selkeää, ja tässä on sen 1 vahvuus."

Mihin perustat sen selkeyden? Sille selkeydelle on ihan mittaustapa myös olemassa: https://en.wikipedia.org/wiki/Halstead_complexity_measures

"Delphistä löytyy esim {$R }
jolla saa Range Check -ominaisuuden päälle."

Tuollaisessa ominaisuudessa ei ole mitään ihmeellistä ja sitä on muuallakin. Tämä ei ole mikään Delphissä oleva erityisjuttu.

"Esim. C- kielessä EI OLE vastaavaa!"

Miksi vertaat C-kieleen?

"Delphi on myös riittävän ilmaisuvoimainen kaikkiin käytännön tarpeisiin.
Se, että Delphissä ei ole jotain yksittäistä muotiominaisuutta, sillä ei ole mitään merkitystä!"

Onhan sillä merkitystä sillä virheiden välttämisen kanssa. Kompleksisuudella on havaittu yhteys sen kanssa miten paljon virheitä on koodissa ja sitä aiheuttaa mm. koodissa olevat haarautumiset ja ehdot kuin myös itse ohjelmointikielen ilmaisukyky. Nuo ovat laskettavia asioita tietysti.

"Yksi tapa tuottaa Delphillä virheetöntä koodia: hyödynnä Delphin luokkaominaisuuksia!"

Luokkien käyttö ei todista virheettömyydestä ja luokkien tekeminen on aika perusjuttuja, ei mikään Delphissä oleva erityisjuttu.

"Miksi tuhlaisin aikaani miettimällä jotain teoreettisia todistuksia, kun samaan aikaan voin kirjoittaa virheetöntä koodia Delphillä?"

Havaintojen perusteella ihmiset kirjoittavat koodiin virheitä ohjelmointikielestä riippumatta ja virheiden määrä on verrannollinen kompleksisuuteen joka on koodin rakenteessa kuin myös kompleksisuutteen mitä ohjelmointikieli itsessään tekee kun toteutetaan koodia. Se kompleksisuus on havaintoihin perustuva todennäköisyys virheille.

Jos halutaa virheettömyyttä, se pitäisi voida osoittaa. Formaali todistus osoittaa virheettömyyttä tai vähän tiukemmat prosessit mahdollistaa sitä.

Delphissä taas ei ole mitään sellaista ominaisuutta mikä tekisi koodin virheettömäksi ja kyllä nuo range checkit ja luokat ovat ihan perusjuttuja eikä mitään kummallista virheettömäksi tekevää Delphikoodia.

Lue lisää

Tässä on https://en.wikipedia.org/wiki/Halstead_complexity_measures

sivun ohjelmaesimerkki Delphillä:

program Avrg;
{$APPTYPE CONSOLE}
var
a, b, c, avg : integer;

begin
ReadLn(a, b, c);
avg := (a b c) DIV 3;
WriteLn('avg = ', avg);
end.

Mitenkä tuosta Delphi -ohjelmasta lasketaan vastaavat luvut kuin em. wikipedia -artikkelissa on laskettu C- koodista?

Tosin, näin yksinkertainen ohjelma ei tuo esille Delphin vahvuuksia!

Esim:

jossain isommassa ohjelmassa C -koodaaja saattaa rakentaa linkitetyn listan itse koodaamalla.

Delphi -koodaaja sensijaan käyttää tyypillisesti joko

TList tai TStringList -tyyppistä luokkaa, joka toteuttaa tuon listan hallinnan, jolloin ohjelmoija ei tyypillisesti itse ala koodata sellaista uudelleen, mikä löytyy jo Delphin luokkakirjastosta, jota usein kutsutaan nimellä VCL (= Visual Control Library), vaikka tyypeissä TList tai TStringList ei sinänsä mitään visuaalista olekaan.

Toki on sitten esim TMemoStrings ja TListboxStrings, molemmat periytyvät TStrings -tyypistä.

On sekä vähemmän työtä että vähemmän virhealtista käyttää valmiita TList tai TStringList -luokkia kuin alkaa itse koodaamaan linkitettyä listaa, mitä C -koodaajat tyypillisesti tekevät.

Ja vaikka koodaisi itse, niin Delphin selkeä syntaksi tarkoittaa pienempää määrää koodausvirheitä kuin mitä C -koodaaja saa aikaiseksi.

Ei se ole mikään sattuma, että juuri C:llä koodatuista ohjelmista / kirjastoista löytyy niin paljon bugeja ja jopa puskurin ylivuotohaavoittuvuuksia.

Kyllä syy on sekä C -kielen rakenteellinen heikkous, jota vielä pahentaa C -kielen kryptinen ja sekava syntaksi, tällöin ohjelmoijan aivokapasiteetti kuluu tuon hankalan syntaksin kanssa tappelemiseen, ja varsinainen pääasia jää C -koodaajalla sivuasiaksi.

Delphin selkeä syntaksi taas antaa ohjelmoijan keskittyä pääasiaan, eli työn alla olevan tehtävän/ongelman ratkaisemiseen, kun ei tarvitse tuhlata aikaansa/ajatuksiaan hankalan syntaksin kanssa tappelemiseen.

Se, joka ei tätä halua uskoa, jatkakoon C:llä koodaamista.

ProDelphi kirjoitti:

Tässä mainio esimerkki: JOS OpenSSL olisi koodattu Delphillä, HeartBleed -bugia ei olisi koskaan tapahtunut!

Aiheesta muualla netissä:

"Modern languages, like delphi when using {$R }, range check all array accesses, so if the source language for openssl were delphi compiled using {$R }, this exploit would not exist. Almost all memory exploits are associated with old school languages such as C and C which depend on the programmer to check their own array accesses."

Mitä tulee kielen selkeyteen ja ilmaisuvoimaan, käytän omia aivojani, en tarvitse tuohon arviointiin M-Karin puffaamaa

https://en.wikipedia.org/wiki/Halstead_complexity_measures

sivua.

Oikein käytettynä muuten Delphin property:t ovat mainio lisä jo muutenkin ilmaisuvoimaiseen kieleen.

Samoin Delphin mahdollisuus tehdä näin:

TAnyClientConnType = Class of TClientConn;

var
Q : TAnyClientConnType;

myöhemmin koodissa:

CC := Q.Create();

tuolloin CC voi olla tyyppiä TClientConn tai mitä tahansa siitä joko suoraan tai välillisesti periytyvää tyyppiä.

Syy, miksi M-Karin mittari kannattaa jättää omaan arvoonsa:

Jos M-Karin mittarilla mitataan, niin silloin C on varmaankin ilmaisuvoimaisempi kuin Delphi, siksi kun C :ssa on moninperintä, Delphissä luokkien osalta ei ole (mutta interface:jen osalta ON!)

Tuo ei nimittäin ole mikään Delphin puute/vika, vaan Delphi on tarkoituksella suunniteltu näin!

Delphin alkuperäisen suunnittelijan mukaan moninperintää on liian helppo väärinkäyttää ja sen todelliset hyödyt ovat varsin vähäiset.

Ja niissä harvoissa tapauksissa, joissa moninperinnästä olisi jotain hyötyä, niissä Delphissä käytetään interface:jen moninperintää, ja itse luokka on ilman moninperintää, mutta siinä voi käyttää Delphin Delegate -ominaisuutta, josta lisätietoja hakusanalla implements.

Yksityiskohtia en muista, koska edes tuota implements tarvitsee käytännössä varsin harvoin, mutta Delphissä se kuitenkin on mukana, eli valmiina käytettäväksi, jos sille tulee tarve vastaan.

Ja vielä yksi asia:

Ilmeisesti kääntäjien välillä on nykyisin kova kilpailu, ja siksi kääntäjien (myös Delphin uudemmissa versioissa) on mukana kaikki mahdolliset ns. Buzzwordit.

Kokonaan eri asia, onko kaikista mahdollisista Buzzwordeista jotain käytännön hyötyä ohjelmointityön kannalta.

Veikkaanpa, että usein ei, eli ne Buzzwordit ovat mukana, eivät ohjelmoijien takia, vaan niiden ns. Excel -johtajien, jotka tekevät eri ohjelmointityövälineistä Excel -taulukon, ja sitten ajattelevat, että mitä enemmän Buzzwordeja joku työväline tukee, sen parempi se varmaan on.

Todellisuudessa Buzzwordit ohjelmoinnissa ovat vähän kuin muoti vaatteissa, eli siitä hyötyy vaatebisnes, ei muotia oikeasti kukaan mihinkään tarvitse.

Jos tuo M-Karin suosikkitesti https://en.wikipedia.org/wiki/Halstead_complexity_measures mittaa sitä, montako Buzzwordia kussakin työvälineessä on tuettuna, niin vaikka Delphi häviäisi tämän kisan, mitä ihmeen merkitystä sillä on ohjelmointityön kannalta?

Käytännössä ei mitään.

Käytän Delphiä, koska se on hyvä työväline tehdä niin sovelluksia (EXE) kuin myös kirjastoja (DLL), ja todellakin, jos olisin koodannut OpenSSL:n alusta alkaen Delphillä, niin HeartBleed -haavoittuvuutta ei olisi koskaan tapahtunut.

Mutta M-Karin mielestä on parempi koodata kirjastot C:llä, täytyyhän esim. NSA:n päästä murtautumaan kaikkiin tietojärjestelmiin, ja C -kielen käyttö on tapa varmistaa, että aina löytyy bugeja, joiden avulla NSA saavuttaa tavoitteensa ja voi aina murtautua kaikkiin tietojärjestelmiin.

Ehkäpä M-Kar on NSA:n palkkaama kirjoittaja, jolle NSA maksaa rahaa siitä, että hän kirjoittelee tänne Delphi -vastaisia tekstejä.

Niin minä tekisin (= palkkaisin M-Karin kirjoittelemaan tänne Delphi -vastaisia tekstejä), jos olisin NSA:n johtaja ja haluaisin varmistua, että jatkossakin riittää haavoittuvuuksia, joiden avulla NSA voi murtautua, minne haluaa, ja usein jopa jälkiä jättämättä.

Lue lisää

"Tässä mainio esimerkki: JOS OpenSSL olisi koodattu Delphillä, HeartBleed -bugia ei olisi koskaan tapahtunut!"

Delphillä ei onnistu koko OpenSSL:n teko niillä vaatimuksilla mitä sille on asetettu.

"Mitä tulee kielen selkeyteen ja ilmaisuvoimaan, käytän omia aivojani"

Jos aivosi toimii niin huomaat kuinka heikosti Delphi pärjää.

"niin vaikka Delphi häviäisi tämän kisan, mitä ihmeen merkitystä sillä on ohjelmointityön kannalta?"

Asiaa on tutkittu ja huomattu sen vaikuttavan bugien määrään.

"Se, joka ei tätä halua uskoa, jatkakoon C:llä koodaamista."

Miksi jankkaat kokoajan jostain C:stä?

"ja todellakin, jos olisin koodannut OpenSSL:n alusta alkaen Delphillä, niin HeartBleed -haavoittuvuutta ei olisi koskaan tapahtunut."

Delphillä ei oikein onnistu tekemään OpenSSL:ää.

"Mutta M-Karin mielestä on parempi koodata kirjastot C:llä, täytyyhän esim. NSA:n päästä murtautumaan kaikkiin tietojärjestelmiin, ja C -kielen käyttö on tapa varmistaa, että aina löytyy bugeja, joiden avulla NSA saavuttaa tavoitteensa ja voi aina murtautua kaikkiin tietojärjestelmiin."

Valehtelet. C on niitä harvoja kieliä joilla voidaan tehdä niin virheettömiä ohjelmia, että lentokoneet pysyvät ilmassa. Sillä on mahdollista tehdä täysin virheettömiä ohjelmia. Delphi ei kelpaa avioniikan ohjelmointiin.

Delphi_laadukkaampi kirjoitti:

Tässä on https://en.wikipedia.org/wiki/Halstead_complexity_measures

sivun ohjelmaesimerkki Delphillä:

program Avrg;
{$APPTYPE CONSOLE}
var
a, b, c, avg : integer;

begin
ReadLn(a, b, c);
avg := (a b c) DIV 3;
WriteLn('avg = ', avg);
end.

Mitenkä tuosta Delphi -ohjelmasta lasketaan vastaavat luvut kuin em. wikipedia -artikkelissa on laskettu C- koodista?

Tosin, näin yksinkertainen ohjelma ei tuo esille Delphin vahvuuksia!

Esim:

jossain isommassa ohjelmassa C -koodaaja saattaa rakentaa linkitetyn listan itse koodaamalla.

Delphi -koodaaja sensijaan käyttää tyypillisesti joko

TList tai TStringList -tyyppistä luokkaa, joka toteuttaa tuon listan hallinnan, jolloin ohjelmoija ei tyypillisesti itse ala koodata sellaista uudelleen, mikä löytyy jo Delphin luokkakirjastosta, jota usein kutsutaan nimellä VCL (= Visual Control Library), vaikka tyypeissä TList tai TStringList ei sinänsä mitään visuaalista olekaan.

Toki on sitten esim TMemoStrings ja TListboxStrings, molemmat periytyvät TStrings -tyypistä.

On sekä vähemmän työtä että vähemmän virhealtista käyttää valmiita TList tai TStringList -luokkia kuin alkaa itse koodaamaan linkitettyä listaa, mitä C -koodaajat tyypillisesti tekevät.

Ja vaikka koodaisi itse, niin Delphin selkeä syntaksi tarkoittaa pienempää määrää koodausvirheitä kuin mitä C -koodaaja saa aikaiseksi.

Ei se ole mikään sattuma, että juuri C:llä koodatuista ohjelmista / kirjastoista löytyy niin paljon bugeja ja jopa puskurin ylivuotohaavoittuvuuksia.

Kyllä syy on sekä C -kielen rakenteellinen heikkous, jota vielä pahentaa C -kielen kryptinen ja sekava syntaksi, tällöin ohjelmoijan aivokapasiteetti kuluu tuon hankalan syntaksin kanssa tappelemiseen, ja varsinainen pääasia jää C -koodaajalla sivuasiaksi.

Delphin selkeä syntaksi taas antaa ohjelmoijan keskittyä pääasiaan, eli työn alla olevan tehtävän/ongelman ratkaisemiseen, kun ei tarvitse tuhlata aikaansa/ajatuksiaan hankalan syntaksin kanssa tappelemiseen.

Se, joka ei tätä halua uskoa, jatkakoon C:llä koodaamista.

Lue lisää

"Mitenkä tuosta Delphi -ohjelmasta lasketaan vastaavat luvut kuin em. wikipedia -artikkelissa on laskettu C- koodista?"

n = 22
N = 30
D = 13,125
E = 1755,90135
T = 97,550075
B ~ 0,0485153

Näillä koodiriveillä Delphi häviää.

"jossain isommassa ohjelmassa C -koodaaja saattaa rakentaa linkitetyn listan itse koodaamalla."

Tuskinpa: https://developer.gnome.org/glib/stable/glib-data-types.html

"kuin alkaa itse koodaamaan linkitettyä listaa, mitä C -koodaajat tyypillisesti tekevät."

Höpöhöpö. Miksi alkaisi kun on valmis alustan vakiokirjastossa?

"Ja vaikka koodaisi itse, niin Delphin selkeä syntaksi tarkoittaa pienempää määrää koodausvirheitä kuin mitä C -koodaaja saa aikaiseksi."

Näissä kahdessa koodin pätkässä C:n ilmaisu kyky oli 17 ja Delphin 22, ja pienempi on parempi. C koodissa bugimäärä 0.04 ja Delphikoodissa ~0,0485153

"Kyllä syy on sekä C -kielen rakenteellinen heikkous, jota vielä pahentaa C -kielen kryptinen ja sekava syntaksi, tällöin ohjelmoijan aivokapasiteetti kuluu tuon hankalan syntaksin kanssa tappelemiseen, ja varsinainen pääasia jää C -koodaajalla sivuasiaksi."

Delphin syntaksi on selvästikin kryptinen näitä äskeisiä koodirivejä vertaamalla.

("
n = 22
N = 30
D = 13,125
E = 1755,90135
T = 97,550075
B ~ 0,0485153

Näillä koodiriveillä Delphi häviää.")

Taas näitä haistapaskan väittämiä. mitkä ajat sait C ja mitkä ajat sait Delpihillä. Etkö käsitä et voi noin vain sanoa että häviää, sinun on näytettävä se toteen. Ellet näytä on minultakin riitettävä se sama todistelu, joka on EI SAATANA HÄVIÄ.

Minä pystyn nuo kirjottamaan ja testaamaan, mutta kun sinä et tee muuta kuin väännät paskaa, niin en vitsi turhaa vaivaa nähdä.

Affiliate-Julkaisia kirjoitti:

("
n = 22
N = 30
D = 13,125
E = 1755,90135
T = 97,550075
B ~ 0,0485153

Näillä koodiriveillä Delphi häviää.")

Taas näitä haistapaskan väittämiä. mitkä ajat sait C ja mitkä ajat sait Delpihillä. Etkö käsitä et voi noin vain sanoa että häviää, sinun on näytettävä se toteen. Ellet näytä on minultakin riitettävä se sama todistelu, joka on EI SAATANA HÄVIÄ.

Minä pystyn nuo kirjottamaan ja testaamaan, mutta kun sinä et tee muuta kuin väännät paskaa, niin en vitsi turhaa vaivaa nähdä.

Lue lisää

"Etkö käsitä et voi noin vain sanoa että häviää, sinun on näytettävä se toteen."

Unique operators (14kpl):

program
{}
$
APPTYPE
var
:
integer;
begin end.
ReadLn
()
WriteLn
:=

DIV

Unique operands (8kpl):

Avrg;
CONSOLE
a
b
c
avg
3
'avg = '

Ja laskin kaavan mukaan: https://en.wikipedia.org/wiki/Halstead_complexity_measures

"Ellet näytä on minultakin riitettävä se sama todistelu, joka on EI SAATANA HÄVIÄ."

Kyllä nuo numerot täsmää, naputtele vaikka laskimella.

Affiliate-Julkaisia kirjoitti:

("
n = 22
N = 30
D = 13,125
E = 1755,90135
T = 97,550075
B ~ 0,0485153

Näillä koodiriveillä Delphi häviää.")

Taas näitä haistapaskan väittämiä. mitkä ajat sait C ja mitkä ajat sait Delpihillä. Etkö käsitä et voi noin vain sanoa että häviää, sinun on näytettävä se toteen. Ellet näytä on minultakin riitettävä se sama todistelu, joka on EI SAATANA HÄVIÄ.

Minä pystyn nuo kirjottamaan ja testaamaan, mutta kun sinä et tee muuta kuin väännät paskaa, niin en vitsi turhaa vaivaa nähdä.

Lue lisää

Sitä kun ymmärtää niitä työkalujen eroja niin kyllähän se nyt on selvää, että C saa etua yksinkertaisemmissa prosesseissa mutta toisaalta Delphi voi saada helposti etua merkkijonojen käsittelyssä ja laajemmissa prosesseissa missä samaan nimiavaruuteen tungetaan paljon luokkia.

Toisaalta edelleenkin en nyt ymmärrä miksi pitää joka asiassa verrata C:n kun se nyt edelleenkin on lähinnä systeemitason kieli ja Delphi sovellusohjelmointiin.

Sitten olisikin minun mielestäni maailmankirjat sekaisin jos Delphi olisi jossain asiassa jollain mittarilla paras. Haen itseasiassa sellaista esimerkkiä mutta kukaan ei ole kyennyt sellaista esittämään, mikä tarkoittaisi sitä että vanha argumenttini siitä, että Delphi on ns. paska, on pätevä.

M-Kar kirjoitti:

"Etkö käsitä et voi noin vain sanoa että häviää, sinun on näytettävä se toteen."

Unique operators (14kpl):

program
{}
$
APPTYPE
var
:
integer;
begin end.
ReadLn
()
WriteLn
:=

DIV

Unique operands (8kpl):

Avrg;
CONSOLE
a
b
c
avg
3
'avg = '

Ja laskin kaavan mukaan: https://en.wikipedia.org/wiki/Halstead_complexity_measures

"Ellet näytä on minultakin riitettävä se sama todistelu, joka on EI SAATANA HÄVIÄ."

Kyllä nuo numerot täsmää, naputtele vaikka laskimella.

Lue lisää

Eihän tuossa ole mitään ohjelmaa, eikä sen enempää mitään aikoja, kuinka kauan lasketa kestää milläkin. Mitä sinä tuolla oikein todistelet.

Elä väitä puuta heinää. tuossa ei ole edes toimivaan rutiinia, jotai sotkua jostakin siihen laitoit asiaa tuntemattomien hämäämiseksi.

Ainut millä voit jotai kielen paremmuudesta toiseen nähden osoittaa on se että teet silmukan jossa kaavaa toistetaan vaikka 20000 kertaa, otat ajan ilman kaavaa ja kaavan kanssa. Vähennät silmukan suoritukseen kuluneen ajan pois kokonaisajasta.

Teet sen Delphillä ja sitten C:llä, tarkastellaan sitten kummankin kielen koodia, onko tahallisesti hidastavaa mukana, korjataan testataan uudestaan korjauksen jälkeen.

JOS ET YMMÄRRÄ KUMPAAKIN KIELTÄ ET OLE PÄTEVÄ ANTAMAAN LAUSUNTOJA MIHINKÄÄN SUUNTAA, voit vain kertoa omia mielipiteitäsi ja myös sanoa sen niin että kukaan ei kuvittele sen vastaavan todellisuutta. Se on vain sinun MUTU juttu ei yhtään mitään muuta.

MUTU = Minusta tuntuu siltä että

LOPETA SE LUKIJOIDEN KUSETTAMINEN

-

Affiliate-Julkaisia kirjoitti:

Eihän tuossa ole mitään ohjelmaa, eikä sen enempää mitään aikoja, kuinka kauan lasketa kestää milläkin. Mitä sinä tuolla oikein todistelet.

Elä väitä puuta heinää. tuossa ei ole edes toimivaan rutiinia, jotai sotkua jostakin siihen laitoit asiaa tuntemattomien hämäämiseksi.

Ainut millä voit jotai kielen paremmuudesta toiseen nähden osoittaa on se että teet silmukan jossa kaavaa toistetaan vaikka 20000 kertaa, otat ajan ilman kaavaa ja kaavan kanssa. Vähennät silmukan suoritukseen kuluneen ajan pois kokonaisajasta.

Teet sen Delphillä ja sitten C:llä, tarkastellaan sitten kummankin kielen koodia, onko tahallisesti hidastavaa mukana, korjataan testataan uudestaan korjauksen jälkeen.

JOS ET YMMÄRRÄ KUMPAAKIN KIELTÄ ET OLE PÄTEVÄ ANTAMAAN LAUSUNTOJA MIHINKÄÄN SUUNTAA, voit vain kertoa omia mielipiteitäsi ja myös sanoa sen niin että kukaan ei kuvittele sen vastaavan todellisuutta. Se on vain sinun MUTU juttu ei yhtään mitään muuta.

MUTU = Minusta tuntuu siltä että

LOPETA SE LUKIJOIDEN KUSETTAMINEN

-

Lue lisää

"Eihän tuossa ole mitään ohjelmaa, eikä sen enempää mitään aikoja, kuinka kauan lasketa kestää milläkin. Mitä sinä tuolla oikein todistelet."

Se ohjelma oli tämä:

program Avrg;
{$APPTYPE CONSOLE}
var
a, b, c, avg : integer;

begin
ReadLn(a, b, c);
avg := (a b c) DIV 3;
WriteLn('avg = ', avg);
end.

Eli sama ohjelma Delphillä mikä oli sivulla https://en.wikipedia.org/wiki/Halstead_complexity_measures

Ja siitä laskettu kompleksisuutta jolla on tunnetusti yhteys bugien määrään mitä ihmiset kirjoittavat koodiin. Toinen tunnettu mittari on cyclomatic complexity jolla saadaan laskettua tarvittavien testien määrää kuin myös sitä, että meneekö joku osa ohjelmaa liian kompleksiseksi. Kun optimoidaan koodia mahdollisimman siistiksi, selkeäksi, ymmärrettäväksi ja virheettömäksi niin nämä ovat niitä millä sitä lasketaan.

Tässä ei ole kyse mistään suoritusajoista vaan siitä kuinka selkeää koodi on tai miten saadaan mahdollisimman vähän virheitä tai täysin bugittomaksi.

Yleensä näillä on enemmän merkitystä kuin laskenta-ajalla, kun suorituskyky ei käytännössä ole ollut useimmissa tilanteissa mikään ongelma yli 30 vuoteen. Etenkin viimeiset 5v suorituskyky ollut lähes kaikessa riittävä.

Affiliate-Julkaisia kirjoitti:

Eihän tuossa ole mitään ohjelmaa, eikä sen enempää mitään aikoja, kuinka kauan lasketa kestää milläkin. Mitä sinä tuolla oikein todistelet.

Elä väitä puuta heinää. tuossa ei ole edes toimivaan rutiinia, jotai sotkua jostakin siihen laitoit asiaa tuntemattomien hämäämiseksi.

Ainut millä voit jotai kielen paremmuudesta toiseen nähden osoittaa on se että teet silmukan jossa kaavaa toistetaan vaikka 20000 kertaa, otat ajan ilman kaavaa ja kaavan kanssa. Vähennät silmukan suoritukseen kuluneen ajan pois kokonaisajasta.

Teet sen Delphillä ja sitten C:llä, tarkastellaan sitten kummankin kielen koodia, onko tahallisesti hidastavaa mukana, korjataan testataan uudestaan korjauksen jälkeen.

JOS ET YMMÄRRÄ KUMPAAKIN KIELTÄ ET OLE PÄTEVÄ ANTAMAAN LAUSUNTOJA MIHINKÄÄN SUUNTAA, voit vain kertoa omia mielipiteitäsi ja myös sanoa sen niin että kukaan ei kuvittele sen vastaavan todellisuutta. Se on vain sinun MUTU juttu ei yhtään mitään muuta.

MUTU = Minusta tuntuu siltä että

LOPETA SE LUKIJOIDEN KUSETTAMINEN

-

Lue lisää

Pointti tällä kaikella on se kun on niitä paskapuheita, että Delphillä tehtäessä ohjelma on jotenkin ihmeellisesti "virheetön" tai että koodi on muka jotenkin ihmeellisen selkeätä. Näitä asioita voi laskea, kuinka selkeätä koodia on tai voi myös todistaa virheettömyyttä.

Suorituskyky on myös yksi mitattava suure mutta tunnetusti sillä on merkitystä sitten kun ohjelman suoritus alkaa viemään aikaa. Tyypilliset latenssirajat on

16ms - kuvan päivitys
19ms - korvin kuultava latenssi
50ms - tekstinkirjoitus
100ms - aivoille välitön latenssi suorassa datan käsittelyssä
1000ms - aika joka on "heti".
10000ms - aika jossa flow kärsii ja käyttäjä joutuu odottamaan

Tästä suuremmat latenssit sitten sitä, että onnistuuko kahvitauon, lounastauon, yön yli, viikonlopun yli jne. ajoissa vai onko niin pitkäkestoista laskentaa, että sitä lasketaan viikoissa ja kuukausissa.

Jos kahvipaussi olisi jotain vajaa 10min niin se on jo sellainen aika, että sen pitäisi olla päätelaitteessa sellainen jota tapahtuu harvoin ja on poikkeuksellista. Tuota raskaammat jutut menee käytännössä aina taustalle palvelimeen, ja helposti nekin yli sekunnin kestävät jotka kokonaisuudessaan käy palvelimessa nopeammin kuin päätelaitteessa.

M-Kar kirjoitti:

"Tässä mainio esimerkki: JOS OpenSSL olisi koodattu Delphillä, HeartBleed -bugia ei olisi koskaan tapahtunut!"

Delphillä ei onnistu koko OpenSSL:n teko niillä vaatimuksilla mitä sille on asetettu.

"Mitä tulee kielen selkeyteen ja ilmaisuvoimaan, käytän omia aivojani"

Jos aivosi toimii niin huomaat kuinka heikosti Delphi pärjää.

"niin vaikka Delphi häviäisi tämän kisan, mitä ihmeen merkitystä sillä on ohjelmointityön kannalta?"

Asiaa on tutkittu ja huomattu sen vaikuttavan bugien määrään.

"Se, joka ei tätä halua uskoa, jatkakoon C:llä koodaamista."

Miksi jankkaat kokoajan jostain C:stä?

"ja todellakin, jos olisin koodannut OpenSSL:n alusta alkaen Delphillä, niin HeartBleed -haavoittuvuutta ei olisi koskaan tapahtunut."

Delphillä ei oikein onnistu tekemään OpenSSL:ää.

"Mutta M-Karin mielestä on parempi koodata kirjastot C:llä, täytyyhän esim. NSA:n päästä murtautumaan kaikkiin tietojärjestelmiin, ja C -kielen käyttö on tapa varmistaa, että aina löytyy bugeja, joiden avulla NSA saavuttaa tavoitteensa ja voi aina murtautua kaikkiin tietojärjestelmiin."

Valehtelet. C on niitä harvoja kieliä joilla voidaan tehdä niin virheettömiä ohjelmia, että lentokoneet pysyvät ilmassa. Sillä on mahdollista tehdä täysin virheettömiä ohjelmia. Delphi ei kelpaa avioniikan ohjelmointiin.

Lue lisää

M-Karin väite: "Delphillä ei onnistu koko OpenSSL:n teko niillä vaatimuksilla mitä sille on asetettu."

Tosiasia:

Windows -ympäristöön OpenSSL -kirjasto olisi aivan hyvin voitu tehdä Delphillä. Jos M-Kar muuta väittää, se ei osoita muuta kuin sen, että M-Karin taidot eivät riitä koodaamaan Delphillä vastaavaa toiminnallisuutta.

Jos taas M-Kar tarkoitti sitä, että vaatimuksiin kuuluu toiminta muissakin käyttöjärjestelmissä kuin Windows -ympäristössä, silloin olisi voinut kirjoittaa OpenSSL -kirjaston ObjectPascalilla siten, että koodissa on sopivat ohjauslauseet:

{$IFEDEF DELPHI}

ja


{$IFEDEF FPC}

sekä

{$IFEDEF LINUX}


{$IFEDEF MSWINDOWS}

ja kääntää sitten windowsia varten DLL Delphillä ja .so linuxia varten Free Pascal -kääntäjällä.

Mitään esteitä ei ole sille, etteikö OpenSSL olisi voitu tehdä näin.

Itseasiassa, Free Pascalilla voi toki kääntää myös sen DLL:n.

Makuasia ehkä, mutta kun kyse on windowsille koodaamisesta, Delphi on miellyttävämpi käyttää kuin Free Pascal.

Erityisesti debuggaus on ominaisuus, jossa Delphi on laadukkaampi kuin Free Pascal.

Lähes sama ohjelmointikieli (pieniä eroja on), mutta Free Pascalin debuggeri perustuu GDB:n käyttöön, ja valitettavasti GDB:n alkuperäiset tekijät ovat tehneet siitä C ja C -käyttöön tarkoitetun debuggerin, jolloin sen käyttö Objectpascal -kielen kanssa on ikävää touhua, vaikkakin juuri ja juuri mahdollista, syynä esim merkkikokoherkkyys sekä GDB ei tue propertyja.

Lisää harmia aiheutuu versioyhteensopivuudesta, kas kun GDB:n tekijät jokaisessa uudessa versiossa muuttavat, mitä haluavat, eikä Free Pascal tiimillä ole mitään sanomista asiaan.

Järkevämpää olisikin ollut, että Free Pascal -tiimi olisi kopioinut GDB:n vaikkapa nimelle OPGDB ja sisällyttäneet tuon OPGDB projektiinsa.

Tämä olisi ainakin poistanut versioyhteensopivuuteen liittyvät ongelmat.

Mutta FreePascalilla voi kääntää kirjaston useisiin eri käyttöjärjestelmiin, eikä ole mitään estettä, etteikö OpenSSL:ää olisi voinut näin toteuttaa.

Jos näin olisi tehty, HeartBleed -haavoittuvuutta ei olisi koskaan ollut.

Mutta jatkakaa pojat C -kielen käyttöä, niin systeemeihin on helppo tehdä tietomurtoja jatkossakin.

ObjectPascal_parempi kirjoitti:

M-Karin väite: "Delphillä ei onnistu koko OpenSSL:n teko niillä vaatimuksilla mitä sille on asetettu."

Tosiasia:

Windows -ympäristöön OpenSSL -kirjasto olisi aivan hyvin voitu tehdä Delphillä. Jos M-Kar muuta väittää, se ei osoita muuta kuin sen, että M-Karin taidot eivät riitä koodaamaan Delphillä vastaavaa toiminnallisuutta.

Jos taas M-Kar tarkoitti sitä, että vaatimuksiin kuuluu toiminta muissakin käyttöjärjestelmissä kuin Windows -ympäristössä, silloin olisi voinut kirjoittaa OpenSSL -kirjaston ObjectPascalilla siten, että koodissa on sopivat ohjauslauseet:

{$IFEDEF DELPHI}

ja


{$IFEDEF FPC}

sekä

{$IFEDEF LINUX}


{$IFEDEF MSWINDOWS}

ja kääntää sitten windowsia varten DLL Delphillä ja .so linuxia varten Free Pascal -kääntäjällä.

Mitään esteitä ei ole sille, etteikö OpenSSL olisi voitu tehdä näin.

Itseasiassa, Free Pascalilla voi toki kääntää myös sen DLL:n.

Makuasia ehkä, mutta kun kyse on windowsille koodaamisesta, Delphi on miellyttävämpi käyttää kuin Free Pascal.

Erityisesti debuggaus on ominaisuus, jossa Delphi on laadukkaampi kuin Free Pascal.

Lähes sama ohjelmointikieli (pieniä eroja on), mutta Free Pascalin debuggeri perustuu GDB:n käyttöön, ja valitettavasti GDB:n alkuperäiset tekijät ovat tehneet siitä C ja C -käyttöön tarkoitetun debuggerin, jolloin sen käyttö Objectpascal -kielen kanssa on ikävää touhua, vaikkakin juuri ja juuri mahdollista, syynä esim merkkikokoherkkyys sekä GDB ei tue propertyja.

Lisää harmia aiheutuu versioyhteensopivuudesta, kas kun GDB:n tekijät jokaisessa uudessa versiossa muuttavat, mitä haluavat, eikä Free Pascal tiimillä ole mitään sanomista asiaan.

Järkevämpää olisikin ollut, että Free Pascal -tiimi olisi kopioinut GDB:n vaikkapa nimelle OPGDB ja sisällyttäneet tuon OPGDB projektiinsa.

Tämä olisi ainakin poistanut versioyhteensopivuuteen liittyvät ongelmat.

Mutta FreePascalilla voi kääntää kirjaston useisiin eri käyttöjärjestelmiin, eikä ole mitään estettä, etteikö OpenSSL:ää olisi voinut näin toteuttaa.

Jos näin olisi tehty, HeartBleed -haavoittuvuutta ei olisi koskaan ollut.

Mutta jatkakaa pojat C -kielen käyttöä, niin systeemeihin on helppo tehdä tietomurtoja jatkossakin.

Lue lisää

"Tosiasia:

Windows -ympäristöön OpenSSL -kirjasto olisi aivan hyvin voitu tehdä Delphillä."

Eli, ei siis niin niillä vaatimuksille mitä sille on asetettu. OpenSSL:n kun haluttiin siirrettäväksi.

Toinen juttu sitten tietysti se kääntäjävipujen kanssa puljaus mitä Delphi tekee kun OpenSSL:ää kutsutaan useista eri työkaluista ja käyttää defactoa tapaa kutsua toimintoja.

Ja kolmas juttu on se, että haluttiin se kirjasto tietysti sellaiseksi, että toimii käyttöjärjestelmä pienillä laitevaatimuksilla. Delphi tekisi tarvetta ylimääräisille ajoympäristöille. Käyttöjärjestelmässä kun on standardi libc ja OpenSSL toimii muutaman megan muistilla. Delphillä tehdyn koodin ajaminen toisi tämän ajoympäristöt viemään muistia.

"Jos taas M-Kar tarkoitti sitä, että vaatimuksiin kuuluu toiminta muissakin käyttöjärjestelmissä kuin Windows -ympäristössä"

Sanotaan niin, että toiminta pitäisi onnistua kaikissa käyttöjärjestelmissä, koko järjestelmän muistivaatimukset 24Mt tai vähemmän ja pitää olla kutsuttavissa kaikilla ohjelmointivälineillä ilman temppuilua.

"Jos näin olisi tehty, HeartBleed -haavoittuvuutta ei olisi koskaan ollut."

Heartbleed haavoittuvuus ei johtunut C kielestä. Tunnetusti C kielellä ohjelmoitaessa on menetelmiä estää tuollaiset.

M-Kar kirjoitti:

"Tosiasia:

Windows -ympäristöön OpenSSL -kirjasto olisi aivan hyvin voitu tehdä Delphillä."

Eli, ei siis niin niillä vaatimuksille mitä sille on asetettu. OpenSSL:n kun haluttiin siirrettäväksi.

Toinen juttu sitten tietysti se kääntäjävipujen kanssa puljaus mitä Delphi tekee kun OpenSSL:ää kutsutaan useista eri työkaluista ja käyttää defactoa tapaa kutsua toimintoja.

Ja kolmas juttu on se, että haluttiin se kirjasto tietysti sellaiseksi, että toimii käyttöjärjestelmä pienillä laitevaatimuksilla. Delphi tekisi tarvetta ylimääräisille ajoympäristöille. Käyttöjärjestelmässä kun on standardi libc ja OpenSSL toimii muutaman megan muistilla. Delphillä tehdyn koodin ajaminen toisi tämän ajoympäristöt viemään muistia.

"Jos taas M-Kar tarkoitti sitä, että vaatimuksiin kuuluu toiminta muissakin käyttöjärjestelmissä kuin Windows -ympäristössä"

Sanotaan niin, että toiminta pitäisi onnistua kaikissa käyttöjärjestelmissä, koko järjestelmän muistivaatimukset 24Mt tai vähemmän ja pitää olla kutsuttavissa kaikilla ohjelmointivälineillä ilman temppuilua.

"Jos näin olisi tehty, HeartBleed -haavoittuvuutta ei olisi koskaan ollut."

Heartbleed haavoittuvuus ei johtunut C kielestä. Tunnetusti C kielellä ohjelmoitaessa on menetelmiä estää tuollaiset.

Lue lisää

"Toinen juttu sitten tietysti se kääntäjävipujen kanssa puljaus mitä Delphi tekee kun OpenSSL:ää kutsutaan useista eri työkaluista ja käyttää defactoa tapaa kutsua toimintoja."


kääntäjävipujen kanssa puljaus - ?????

M-Kar ilmeisesti luulee, että Delphi tarvitsisi jotain komentoriviltä annettuja kääntäjävipuja siihen, että käytetään DLL:ssä platformin oletuskutsutapaa.

Mutta kun ei tarvita!

Seuraavassa esimerkki funktiosta, joka laskee yhteen 2 kokonaislukua.
Esimerkkinä ok, ja aivan samaa periaatetta käytetään myös todellisissa kirjastofunktioissa, vaikkapa sellaisissa, jotka toteuttavat tuon SSL -standardin.

function LaskeYhteen(A,B : Integer): Integer; {$IFDEF MSWINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF}
begin
Result := A B;
end;

Jos platformin oletuskutsutapa on stdcall (kuten se on Microsoftin Windows -käyttöjärjestelmässä) tai cdecl (kuten se on ilmeisesti lähes kaikissa muissa käyttöjärjestelmissä), niin edelläoleva Delphi/Freepascal -funktio toimii juurikin näin.

kirjastona siis näin:

Library MyDLL;

function LaskeYhteen(A,B : Integer): Integer; {$IFDEF MSWINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF}
begin
Result := A B;
end;

exports
LaskeYhteen;

end.

M-Karin päinvastaisista väitteistä huolimatta: C ABI:n käyttö ei mitenkään edellytä C (tai edes C ) -kielen käyttöä, vaan saman saa aikaiseksi Delphillä tai Freepascalilla, edellä kuvatulla tavalla.

eli ylläoleva kirjasto exportoi tuon LaskeYhteen -funktion siten, että Windowsissa se käyttää stdcall -kutsutapaa, ja muissa käyttöjärjestelmissä cdecl -kutsutapaa (mikä on C -kääntäjän oletus).

Eikös C -kääntäjän oletus ole AINA cdecl ?

Jos näin on, silloin Microsoft itsekin on joutunut laittamaan kirjastojensa melkein jokaiseen exportoitavaan funktioon tuon stdcall -määreen, jota Microsoftin koodarit usein kutsuvat nimellä WINAPI ; tämä toki perustuu C -kielen esiprosessorin käyttöön seuraavasti:

#define WINAPI __stdcall // ja mahdollisesti muita, C -kääntäjän vaatimia lisämääreitä.

"Toiminta pitäisi onnistua kaikissa käyttöjärjestelmissä, koko järjestelmän muistivaatimukset 24Mt tai vähemmän ja pitää olla kutsuttavissa kaikilla ohjelmointivälineillä ilman temppuilua."

Delphillä käännetty koodi ei kuluta sen enempää muistia kuin C -kielellä koodattukaan.

Freepascalista en osaa sanoa, päteekö sama tähän.

Tyypillisesti Freepascal -sovellus (eli EXE tai linuxissa ELF) on isompi kuin Delphin tuottama.

MUTTA: Tämä voi johtua siitä, että FCL -komponentit ovat tyypillisesti enemmän muistitilaa syöviä kuin Delphin VCL -komponentit.

Koska SSL:ssä kyse on kirjastosta, jossa ei ole lainkaan GUI -käyttöliittymäkoodia mukana, olettaisin, että tässä tapauksessa edes Freepascal:in käyttö ei vaadi sen enempää muistia kuin vastaava C-koodinkaan käyttö.

Saattaa olla, että jopa vähemmän, koska C -koodaajat tyypillisesti (olipa se M-Karin mielestä oikein tai väärin) koodaavat alusta alkaen joka kerta uudelleen sellaisia rutiineja, jotka löytyisivät jostain standardikirjastosta.

Olipa tuo teoreettisesti kuinka väärin/hölmöä tahansa, niin tosiasiassa moni C -koodaaja toimii juuri näin !

Delphi_Rules kirjoitti:

"Toinen juttu sitten tietysti se kääntäjävipujen kanssa puljaus mitä Delphi tekee kun OpenSSL:ää kutsutaan useista eri työkaluista ja käyttää defactoa tapaa kutsua toimintoja."


kääntäjävipujen kanssa puljaus - ?????

M-Kar ilmeisesti luulee, että Delphi tarvitsisi jotain komentoriviltä annettuja kääntäjävipuja siihen, että käytetään DLL:ssä platformin oletuskutsutapaa.

Mutta kun ei tarvita!

Seuraavassa esimerkki funktiosta, joka laskee yhteen 2 kokonaislukua.
Esimerkkinä ok, ja aivan samaa periaatetta käytetään myös todellisissa kirjastofunktioissa, vaikkapa sellaisissa, jotka toteuttavat tuon SSL -standardin.

function LaskeYhteen(A,B : Integer): Integer; {$IFDEF MSWINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF}
begin
Result := A B;
end;

Jos platformin oletuskutsutapa on stdcall (kuten se on Microsoftin Windows -käyttöjärjestelmässä) tai cdecl (kuten se on ilmeisesti lähes kaikissa muissa käyttöjärjestelmissä), niin edelläoleva Delphi/Freepascal -funktio toimii juurikin näin.

kirjastona siis näin:

Library MyDLL;

function LaskeYhteen(A,B : Integer): Integer; {$IFDEF MSWINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF}
begin
Result := A B;
end;

exports
LaskeYhteen;

end.

M-Karin päinvastaisista väitteistä huolimatta: C ABI:n käyttö ei mitenkään edellytä C (tai edes C ) -kielen käyttöä, vaan saman saa aikaiseksi Delphillä tai Freepascalilla, edellä kuvatulla tavalla.

eli ylläoleva kirjasto exportoi tuon LaskeYhteen -funktion siten, että Windowsissa se käyttää stdcall -kutsutapaa, ja muissa käyttöjärjestelmissä cdecl -kutsutapaa (mikä on C -kääntäjän oletus).

Eikös C -kääntäjän oletus ole AINA cdecl ?

Jos näin on, silloin Microsoft itsekin on joutunut laittamaan kirjastojensa melkein jokaiseen exportoitavaan funktioon tuon stdcall -määreen, jota Microsoftin koodarit usein kutsuvat nimellä WINAPI ; tämä toki perustuu C -kielen esiprosessorin käyttöön seuraavasti:

#define WINAPI __stdcall // ja mahdollisesti muita, C -kääntäjän vaatimia lisämääreitä.

"Toiminta pitäisi onnistua kaikissa käyttöjärjestelmissä, koko järjestelmän muistivaatimukset 24Mt tai vähemmän ja pitää olla kutsuttavissa kaikilla ohjelmointivälineillä ilman temppuilua."

Delphillä käännetty koodi ei kuluta sen enempää muistia kuin C -kielellä koodattukaan.

Freepascalista en osaa sanoa, päteekö sama tähän.

Tyypillisesti Freepascal -sovellus (eli EXE tai linuxissa ELF) on isompi kuin Delphin tuottama.

MUTTA: Tämä voi johtua siitä, että FCL -komponentit ovat tyypillisesti enemmän muistitilaa syöviä kuin Delphin VCL -komponentit.

Koska SSL:ssä kyse on kirjastosta, jossa ei ole lainkaan GUI -käyttöliittymäkoodia mukana, olettaisin, että tässä tapauksessa edes Freepascal:in käyttö ei vaadi sen enempää muistia kuin vastaava C-koodinkaan käyttö.

Saattaa olla, että jopa vähemmän, koska C -koodaajat tyypillisesti (olipa se M-Karin mielestä oikein tai väärin) koodaavat alusta alkaen joka kerta uudelleen sellaisia rutiineja, jotka löytyisivät jostain standardikirjastosta.

Olipa tuo teoreettisesti kuinka väärin/hölmöä tahansa, niin tosiasiassa moni C -koodaaja toimii juuri näin !

Lue lisää

"Mutta kun ei tarvita!"

"function LaskeYhteen(A,B : Integer): Integer; {$IFDEF MSWINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF}"

Tuollainen vielä karmeampaa, ylimääräistä sotkua koodiin.

"Delphillä käännetty koodi ei kuluta sen enempää muistia kuin C -kielellä koodattukaan."

Delphi itsessään ollut perinteisesti kovin rajoittunut missä sitä voi ajaa.

"Saattaa olla, että jopa vähemmän, koska C -koodaajat tyypillisesti (olipa se M-Karin mielestä oikein tai väärin) koodaavat alusta alkaen joka kerta uudelleen sellaisia rutiineja, jotka löytyisivät jostain standardikirjastosta."

Ei pidä paikkaansa. Huomioi se, että tuo OpenSSL on semmoinen kirjasto joka on tarkoitettu juurikin alustojen vakioiksi mitä käytetään ettei samoja asioita tarvitse toistamiseen tehdä

M-Kar kirjoitti:

"Mutta kun ei tarvita!"

"function LaskeYhteen(A,B : Integer): Integer; {$IFDEF MSWINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF}"

Tuollainen vielä karmeampaa, ylimääräistä sotkua koodiin.

"Delphillä käännetty koodi ei kuluta sen enempää muistia kuin C -kielellä koodattukaan."

Delphi itsessään ollut perinteisesti kovin rajoittunut missä sitä voi ajaa.

"Saattaa olla, että jopa vähemmän, koska C -koodaajat tyypillisesti (olipa se M-Karin mielestä oikein tai väärin) koodaavat alusta alkaen joka kerta uudelleen sellaisia rutiineja, jotka löytyisivät jostain standardikirjastosta."

Ei pidä paikkaansa. Huomioi se, että tuo OpenSSL on semmoinen kirjasto joka on tarkoitettu juurikin alustojen vakioiksi mitä käytetään ettei samoja asioita tarvitse toistamiseen tehdä

Lue lisää

"function LaskeYhteen(A,B : Integer): Integer; {$IFDEF MSWINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF}"

Jos me ei tehdä tuosta joustavaa, niin voimme korvata tuon ehdollisen direktiivin sijoittamalla halutun yksikön näin:

function LaskeYhteen(a,b : Integer): Integer; stdcall;
begin
result := a*b;
end;

{$IFDEF MSWINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF}"

-

"Tuollainen vielä karmeampaa, ylimääräistä sotkua koodiin. "

Jos ohjelman on kyvettävä toimimaan erinlaisissa ympäristöissä, jotenkinhan se ympäristö on tutkittava, ja käytettävä juuri siinä ympäristössä toimivaa koodikirjastoa. En usko että jossakin kehitysympäristössä tuo voi hoitaa nätimmin.

Tässä esimerkissä uses -lauseen sisältöä kootaan ympäristöstä riippuen Windows, MacOS ja Unix ympäristöä varten, ja se tehdään tosi siististi implementation -lohkossa, no voi sen sijoittaa muuallekin.

implementation

{$R *.lfm}

{$IF defined(MSWINDOWS)}
uses Winapi.Windows;
{$ELSEIF defined(MACOS)}
uses Macapi.Mach;
{$ELSEIF defined(POSIX)}
uses Posix.Time;
{$ENDIF}

Tämä se meni taas hukkaan, . . . . .
------------------------------------------------------------------------------------------------------------
Linux Mint 17.3 Rosa
Xfce 64-bit

No-voihan-rähmä kirjoitti:

"function LaskeYhteen(A,B : Integer): Integer; {$IFDEF MSWINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF}"

Jos me ei tehdä tuosta joustavaa, niin voimme korvata tuon ehdollisen direktiivin sijoittamalla halutun yksikön näin:

function LaskeYhteen(a,b : Integer): Integer; stdcall;
begin
result := a*b;
end;

{$IFDEF MSWINDOWS} stdcall; {$ELSE} cdecl; {$ENDIF}"

-

"Tuollainen vielä karmeampaa, ylimääräistä sotkua koodiin. "

Jos ohjelman on kyvettävä toimimaan erinlaisissa ympäristöissä, jotenkinhan se ympäristö on tutkittava, ja käytettävä juuri siinä ympäristössä toimivaa koodikirjastoa. En usko että jossakin kehitysympäristössä tuo voi hoitaa nätimmin.

Tässä esimerkissä uses -lauseen sisältöä kootaan ympäristöstä riippuen Windows, MacOS ja Unix ympäristöä varten, ja se tehdään tosi siististi implementation -lohkossa, no voi sen sijoittaa muuallekin.

implementation

{$R *.lfm}

{$IF defined(MSWINDOWS)}
uses Winapi.Windows;
{$ELSEIF defined(MACOS)}
uses Macapi.Mach;
{$ELSEIF defined(POSIX)}
uses Posix.Time;
{$ENDIF}

Tämä se meni taas hukkaan, . . . . .
------------------------------------------------------------------------------------------------------------
Linux Mint 17.3 Rosa
Xfce 64-bit

Lue lisää

"Jos ohjelman on kyvettävä toimimaan erinlaisissa ympäristöissä, jotenkinhan se ympäristö on tutkittava, ja käytettävä juuri siinä ympäristössä toimivaa koodikirjastoa. En usko että jossakin kehitysympäristössä tuo voi hoitaa nätimmin."

Buildijärjestelmissähän nuo on vuosikymmeniä hoidettu ja vieläpä niin, että haistellaan se ympäristö ja sitten sen mukaan käännellään.

Mutta tuokin on sovelluspuolella jäänyt vanhaksi vuosikymmeniä sitten kun sovelluksia on voitu tehdä niin, että nuo abstraktoidaan alta pois. Esimerkiksi Javalla homma hoitunut yli 20 vuotta.

M-Kar kirjoitti:

"Jos ohjelman on kyvettävä toimimaan erinlaisissa ympäristöissä, jotenkinhan se ympäristö on tutkittava, ja käytettävä juuri siinä ympäristössä toimivaa koodikirjastoa. En usko että jossakin kehitysympäristössä tuo voi hoitaa nätimmin."

Buildijärjestelmissähän nuo on vuosikymmeniä hoidettu ja vieläpä niin, että haistellaan se ympäristö ja sitten sen mukaan käännellään.

Mutta tuokin on sovelluspuolella jäänyt vanhaksi vuosikymmeniä sitten kun sovelluksia on voitu tehdä niin, että nuo abstraktoidaan alta pois. Esimerkiksi Javalla homma hoitunut yli 20 vuotta.

Lue lisää

Noin vastaa vain sellainen joka ei ole eläessään kirjoittanut ainuttakaan ohjelmaa millään kielellä.
Esimerkki ei tuota ohjelmaa johonkin ympäristöön, vaan ohjelman joka voidaan ajaa eri ympäristöissä. Eikä se JAVA tee siinä mitään poikkeusta, älä höpötä paskaa taas, pitää se jokin tolkku olla kerjätessäkin.

Mikä homma on hoitunut 20 vuotta ?
Mitä tiedät Abstraktoidun alta pois ?
Mikä on hoidettu Buildijärjestelmissä vuosikymmeniä ?
Missä Buildijärjestelmissä ne on hoidettu vuosikymmeniä ?
Millä tavalla sinä haistelet niitä Buildijärjestelmissä ?
Nimeä joku Buildijärjestelmä jossa olet parhaimillasi ?
Kerro jokin ohjelmointi kieli jossa olet parhaimillasi ?

"""""""""""""
Buildijärjestelmissähän nuo on vuosikymmeniä hoidettu ja vieläpä niin, että haistellaan se ympäristö ja sitten sen mukaan käännellään.
"""""""""""""
Kaikkein typerintä mitä tänä yönä tuli vastaan.

------------------------------------------------------------------------------------------------------------
Linux Mint 17.3 Rosa
Xfce 64-bit

No-voihan-rähmä kirjoitti:

Noin vastaa vain sellainen joka ei ole eläessään kirjoittanut ainuttakaan ohjelmaa millään kielellä.
Esimerkki ei tuota ohjelmaa johonkin ympäristöön, vaan ohjelman joka voidaan ajaa eri ympäristöissä. Eikä se JAVA tee siinä mitään poikkeusta, älä höpötä paskaa taas, pitää se jokin tolkku olla kerjätessäkin.

Mikä homma on hoitunut 20 vuotta ?
Mitä tiedät Abstraktoidun alta pois ?
Mikä on hoidettu Buildijärjestelmissä vuosikymmeniä ?
Missä Buildijärjestelmissä ne on hoidettu vuosikymmeniä ?
Millä tavalla sinä haistelet niitä Buildijärjestelmissä ?
Nimeä joku Buildijärjestelmä jossa olet parhaimillasi ?
Kerro jokin ohjelmointi kieli jossa olet parhaimillasi ?

"""""""""""""
Buildijärjestelmissähän nuo on vuosikymmeniä hoidettu ja vieläpä niin, että haistellaan se ympäristö ja sitten sen mukaan käännellään.
"""""""""""""
Kaikkein typerintä mitä tänä yönä tuli vastaan.

------------------------------------------------------------------------------------------------------------
Linux Mint 17.3 Rosa
Xfce 64-bit

Lue lisää

"Esimerkki ei tuota ohjelmaa johonkin ympäristöön, vaan ohjelman joka voidaan ajaa eri ympäristöissä. Eikä se JAVA tee siinä mitään poikkeusta, älä höpötä paskaa taas, pitää se jokin tolkku olla kerjätessäkin. "

Javassa käännellään tavukoodiksi ja sitä ajetaan missä vaan on se Javan ajoympäristö. Siinä Javassa semmoinen idea että ajoympäristö hoiti nuo nysvät pois.

"Mikä homma on hoitunut 20 vuotta ?"
Mitä tiedät Abstraktoidun alta pois ?"

Esimerkiksi riippuvuudet käyttöjärjestelmään ja laitearkkitehtuuriin.

M-Kar kirjoitti:

"Etkö käsitä et voi noin vain sanoa että häviää, sinun on näytettävä se toteen."

Unique operators (14kpl):

program
{}
$
APPTYPE
var
:
integer;
begin end.
ReadLn
()
WriteLn
:=

DIV

Unique operands (8kpl):

Avrg;
CONSOLE
a
b
c
avg
3
'avg = '

Ja laskin kaavan mukaan: https://en.wikipedia.org/wiki/Halstead_complexity_measures

"Ellet näytä on minultakin riitettävä se sama todistelu, joka on EI SAATANA HÄVIÄ."

Kyllä nuo numerot täsmää, naputtele vaikka laskimella.

Lue lisää

Kas kas .... !

M-Kar jäi kiinni valheesta !


"Unique operators (14kpl; Delphi):
Unique operands (8kpl; C):
"

muka Delphi (14) ja C (8) operaattoria / operandia (eivät muuten ole sama asia !)

Siis Delphille oli laskettu haittapisteeksi ReadLn ja WriteLn -proseduurien käyttö.
Sensijaan C:lle EI OLLUT laskettu haittapisteeksi scanf ja printf -funtioiden käyttöä.

Tällainen ei millään ole tasapuolista !

Lisäksi:

C -kielessä taulukon reunatarkistusta ei ole olemassakaan (ja tämä on yksi tekijä, miksi C aiheuttaa isoja tietoturvaongelmia, ks puskurin ylivuoto) !

Mutta Delphissä on, ja siihen liittyvä kääntäjän ohjauslauseke, jolla nuo taulukon reunatarkistukset kytketään päälle, on Delphissä:

{$R }

Koska tuo {$R } on YKSI kokonaisuus, ei ole asiallista laskea {} ja $ erikseen kahtena haittapisteenä (Näinhän se meni, että jokainen eri rakenne = 1 haittapiste, eli pienempi pisteluku on parempi; ja tämäkin edellyttäen, että tuolla halstead -mitoituksella yleensäkään on a) mitään merkitystä ja b) että tuollainen vertailu ERI ohjelmointikielien välillä käyttäen ko. Halsteadia olisi pätevää).

Lisäksi:

scanf() on käsittääkseni lähtökohtaisesti vaarallinen operaatio, eli jos käyttäjä syöttää selvästi pidemmän syötteen kuin ohjelma odottaa, voi syntyä puskurin ylivuoto, mikä on aina laskettava vakavaksi haavoittuvuudeksi !

Tuossa esimerkkiohjelmassa, jonka C -kielinen versio löytyy suoraan:

https://en.wikipedia.org/wiki/Halstead_complexity_measures

ja jonka Delphi -versio on tässä keskusteluketjussa,

ei Delphi -versiossa ole mitään vakavaa haavoittuvuutta !

Jonkun pitäisi tehdä testi:

ajetaan em. ohjelmasta sekä Delphillä että C:llä koodattu versio, ja siten , että konsoli -IO on suoraan uudelleenohjattu web -palvelimen kautta kenen tahansa selaimelle, eli palvelu julkisena internetiin kenen tahansa käytettäväksi!

Veikkaanpa, että lopputulos olisi tämä:

Delphi -versio: turvallinen

C -versio: osaava selaimen (tai selainta teeskentelevän ohjelman) käyttäjä saisi C -version murrettua nopeasti, ja voisi syöttää omia komentojaan testiä ajavalle tietokoneelle.

TOSIN: Delphissä varsinkin ReadLn suoraan numeeriseen muuttujaan sovellettuna on ikivanhaa tekniikkaa, ja siitäkin saattaa paljastua jotain.

Mutta jos Delphissä olisi koodattu:

var
Syote : String;

ja sitten: Luku := IntToStr(Syote);

niin olisi 100% turvallinen, jopa internetistä käsin kenen tahansa käpisteltävänä.

Eli tuo Halstead -indeksi ei kerro todellisesta tietoturvatasosta mitään, eli C:lle pitäisi antaa ainakin miljoona rangaistuspistettä tietoturvattoman scanf -funktion käytöstä.

Olen muuten löytänyt netistä julkaistua C -koodia, jossa nimenomaan tekijä on itse koodannut linkitetyn listan C -kielellä. Jos asiaan onkin joku kirjastofunktio olemassa, niin ko. ohjelman tekijä ei ole sitä käyttänyt, syitä voi vain arvella.

puolueeton_tarkkailija kirjoitti:

Kas kas .... !

M-Kar jäi kiinni valheesta !


"Unique operators (14kpl; Delphi):
Unique operands (8kpl; C):
"

muka Delphi (14) ja C (8) operaattoria / operandia (eivät muuten ole sama asia !)

Siis Delphille oli laskettu haittapisteeksi ReadLn ja WriteLn -proseduurien käyttö.
Sensijaan C:lle EI OLLUT laskettu haittapisteeksi scanf ja printf -funtioiden käyttöä.

Tällainen ei millään ole tasapuolista !

Lisäksi:

C -kielessä taulukon reunatarkistusta ei ole olemassakaan (ja tämä on yksi tekijä, miksi C aiheuttaa isoja tietoturvaongelmia, ks puskurin ylivuoto) !

Mutta Delphissä on, ja siihen liittyvä kääntäjän ohjauslauseke, jolla nuo taulukon reunatarkistukset kytketään päälle, on Delphissä:

{$R }

Koska tuo {$R } on YKSI kokonaisuus, ei ole asiallista laskea {} ja $ erikseen kahtena haittapisteenä (Näinhän se meni, että jokainen eri rakenne = 1 haittapiste, eli pienempi pisteluku on parempi; ja tämäkin edellyttäen, että tuolla halstead -mitoituksella yleensäkään on a) mitään merkitystä ja b) että tuollainen vertailu ERI ohjelmointikielien välillä käyttäen ko. Halsteadia olisi pätevää).

Lisäksi:

scanf() on käsittääkseni lähtökohtaisesti vaarallinen operaatio, eli jos käyttäjä syöttää selvästi pidemmän syötteen kuin ohjelma odottaa, voi syntyä puskurin ylivuoto, mikä on aina laskettava vakavaksi haavoittuvuudeksi !

Tuossa esimerkkiohjelmassa, jonka C -kielinen versio löytyy suoraan:

https://en.wikipedia.org/wiki/Halstead_complexity_measures

ja jonka Delphi -versio on tässä keskusteluketjussa,

ei Delphi -versiossa ole mitään vakavaa haavoittuvuutta !

Jonkun pitäisi tehdä testi:

ajetaan em. ohjelmasta sekä Delphillä että C:llä koodattu versio, ja siten , että konsoli -IO on suoraan uudelleenohjattu web -palvelimen kautta kenen tahansa selaimelle, eli palvelu julkisena internetiin kenen tahansa käytettäväksi!

Veikkaanpa, että lopputulos olisi tämä:

Delphi -versio: turvallinen

C -versio: osaava selaimen (tai selainta teeskentelevän ohjelman) käyttäjä saisi C -version murrettua nopeasti, ja voisi syöttää omia komentojaan testiä ajavalle tietokoneelle.

TOSIN: Delphissä varsinkin ReadLn suoraan numeeriseen muuttujaan sovellettuna on ikivanhaa tekniikkaa, ja siitäkin saattaa paljastua jotain.

Mutta jos Delphissä olisi koodattu:

var
Syote : String;

ja sitten: Luku := IntToStr(Syote);

niin olisi 100% turvallinen, jopa internetistä käsin kenen tahansa käpisteltävänä.

Eli tuo Halstead -indeksi ei kerro todellisesta tietoturvatasosta mitään, eli C:lle pitäisi antaa ainakin miljoona rangaistuspistettä tietoturvattoman scanf -funktion käytöstä.

Olen muuten löytänyt netistä julkaistua C -koodia, jossa nimenomaan tekijä on itse koodannut linkitetyn listan C -kielellä. Jos asiaan onkin joku kirjastofunktio olemassa, niin ko. ohjelman tekijä ei ole sitä käyttänyt, syitä voi vain arvella.

Lue lisää

C:

Unique operators (12kpl): main, (), {}, int, scanf, &, =, , /, printf,',', ;
The unique operands (7kpl): a, b, c, avg, "%d %d %d", 3, "avg = %d"

Delphi:

Unique operators (14kpl):

program
{}
$
APPTYPE
var
:
integer;
begin end.
ReadLn
()
WriteLn
:=

DIV

Unique operands (8kpl):

Avrg;
CONSOLE
a
b
c
avg
3
'avg = '


Eli missä siis valehtelen? Delphikoodissa on kaksi operaattoria ja yksi operandi enemmän. Kaikki kompleksisuus lasketaan haitaksi.

Halstead kertoo siitä kuinka ilmaisukykyinen kieli on. Lisäksi tiedetään, että kompleksisuudella ja bugien määrällä on yhteys.

Tuo mittaus kertoo kuinka siististi asia on toteutettu. Yrität jostain syystä väkisin verrata Delphiä johonkin C:n vaikka ongelma on se, että aina löytyy Delphiä parempi työkalu. C voidaan aivan hyvin jättää sinne missä se on standardi ja käyttää muualla parempia työkaluja. Sinun pitäisi keksiä missä asiassa Delphi on paras saatavilla oleva työkalu, että sillä olisi yhtään mitään merkitystä.

C:llä ei sitä ongelmaa ole kun se on tietyissä matalan tason jutuissa standardi. Korkeammalle tasolle mentäessä on se valinnan vara.

M-Kar kirjoitti:

"Jos ohjelman on kyvettävä toimimaan erinlaisissa ympäristöissä, jotenkinhan se ympäristö on tutkittava, ja käytettävä juuri siinä ympäristössä toimivaa koodikirjastoa. En usko että jossakin kehitysympäristössä tuo voi hoitaa nätimmin."

Buildijärjestelmissähän nuo on vuosikymmeniä hoidettu ja vieläpä niin, että haistellaan se ympäristö ja sitten sen mukaan käännellään.

Mutta tuokin on sovelluspuolella jäänyt vanhaksi vuosikymmeniä sitten kun sovelluksia on voitu tehdä niin, että nuo abstraktoidaan alta pois. Esimerkiksi Javalla homma hoitunut yli 20 vuotta.

Lue lisää

Ainoastaan M-Kar voi kuvitella, että käyttöjärjestelmästä riippuvien asioiden koodaaminen oikein olisi jotenkin parempi tehdä bildijärjestelmällä (esim. autoconf/automake) kuin FreePascalin kääntäjädirektiiveillä, kuten stdcall; (tyypillinen kutsutapa Windowsissa) tai cdecl; (tyypillinen kutsutapa muissa kuin windows -käyttöjärjestelmissä kuten esim. linux).

Fakta:

autoconf / automake on HIDAS linuxissa ja ERITTÄIN HIDAS windowsissa.

Freepascal -kääntäjä taas on nopea, ja Delphi erittäin nopea.

Eli ohjelman kääntäminen on:

* Erittäin nopeaa Delphillä

* nopeaa Freepascalilla

* hidasta gcc:n ja automaken avulla linuxissa

* erittäin hidasta gcc:n ja automaken avulla windowsissa

Tämä toki herättää kysymyksen: miksi gcc:n ja automaken avulla kääntäminen on juuri windowsissa niin järkyttävän hidasta ?

Ilmeisesti tuo (auto)make -systeemi on rakennettu pythonilla tms. skriptikielellä ja se tekee hommasta erittäin hidasta.

valmis exe saattaa olla gcc:n kääntämänä hieman nopeampi kuin vastaava Delphi -koodi, mutta nopeusero on paljon pienempi, kuin mitä C -koodaajat yleisesti kuvittelevat.

Sensijaan käännösprosessi on Delphillä vähintään 10 kertaa nopeampi kuin mingw-gcc:llä varsinkin isoissa projekteissa.

Eli kun komennat komentoriviltä:

make projekti

jossa on projekti.mak -makefile joka syötetään make:lle parametriksi, niin jos make ja gcc yhdessä vievät tunnin ison projektin kääntämisessä, vastaavan Delphillä koodatun projektin kääntäisi Delphi IDE.stä käsin alle 6 minuutissa painamalla Ctrl-F9 (make project).

Kuinkahan monta kehittäjätyötuntia yrityksissä tuhlataan siihen, että kehittäjä joutuu odottamaan hidasta make:lla ja gcc:llä tehtävää käännöstä?

Delphillä tyypillinen käännösaika on välillä 1 sekunti - 1 minuutti.

Vasta todella isoissa projekteissa Delphin käännösaika voi olla useampi minuutti.

Tämä toki edellyttäen, ettei Windows -käyttöjärjestelmä kärsi RAM -muistin puutteesta.

Toki, jos Windowsissa on yhtäaikaa auki vaikkapa Firefox, jossa satoja avoimia web -sivuja, silloin muuttuu Delphi -käännöksetkin hitaaksi touhuksi, mutta se ei ole Delphin vika, vaan se johtuu ns. RAM trashing -ilmiöstä, eli windows -käyttöjärjestelmä joutuu vaihtamaan tietoa edestakaisin RAM -muistin ja swapfilen välillä.

Mikähän olisi paras tapa tehdä windowsissa sama kuin linuxissa seuraavat komennot:

kill -SIGSTOP 999
kill -SIGCONT 999


Windows -tehtävänhallinnan kun saa näyttämään Process ID:t (PID).

SIGSTOPpia vaan nettiselaimelle , niin käännösaika pysyy Delphillä nopeana.

Windowsissa kyse taitaa olla ns. Thread Suspend -toimnnosta.

Ohjelmallisesti helppo tehdä, mutta valmista komentoriviapuohjelmaa ei windowsissa taida tuohon tarkoitukseen olla.

Pitäisiköhän koodata Delphillä vastaava apuohjelma Windowsille ?

Nettiselaimet muuten ovat tyypillisiä C:llä tai C PLUS PLUS -koodaajien tuotoksia:

Käyttävät RAM -muistia tuhlailevasti ja siten hidastavat tietokoneen kaikkia toimintoja.

JOS selain olisi avointa DELPHIllä tehtyä lähdekoodia, niin osaisin helposti muokata selaimen sellaiseksi, että se EI rohmua järjettömiä määriä RAM -muistia kuten nykyselaimet tekevät.

Tällöin selain itse toimisi nopeammin, eikä selain myöskään hidastaisi muistinrohmuamisellaan muiden sovellusten toimintoja.

Kun löytäisikin jostain "C-PLUS-PLUS to Delphi" source to source "kääntäjän" - sitten pääsisi helposti tekemään itse paremman selaimen, Firefoxin tekijät kun ovat käyttäneet vuosia tekeleensä koodaamiseen, ja silti Firefox on järkyttävä RAM -muistituhlari.

Ja taas pääsis M-Kar aukomaan päätään, kuinka Delpillä tehty selain "ei täytä vaatimuksia" kun sitä ei saa kaiken maailman tarpeettomille ja eksoottisille käyttöjärjestelmäympäristöihin.

Fakta: Delphin uusimmat versiot kääntävät Windowsille ja Linuxille, 32/64 -bit Intel/AMD prosessoreille.

Jos Delphillä käännetty EXE ei toimi linuxilla jollain eksoottisella CPU:lla, jonka markkinaosuus on alle 1%, ketä se kiinnostaa? Ei minua ainakaan.

Pöytä- ja kannettavista PC -tietokoneista (Windows tai Linux) yli 99% on sellaisia, joille Delphin uusin versio kykenee kääntämään.

Lopuillekin voi kääntää Freepascalilla, mutta sitten on debuggaus yhtä tuskaa, kun ei saa Embarcaderon laadukasta kaupallista Debuggeria, vaan joutuu käyttämään Freepascal IDE:n debuggeria, joka ikävä kyllä itse käyttää taustalla heikkolaatuista GDB:tä.

GDB kun linux -fanaatikkojen höpinöistä huolimatta on malliesimerkki siitä, miten EI tehdä hyvää debuggeria.

Selain on sovellusohjelma, joka näyttää web -sivuja, ja samalla toimii ajoalustana web -sivuilla on JavaScript -koodia.

M-Kar haluaa kutsua selainta alustaksi. Javascriptille selain onkin suoritusalusta, mutta samalla selain itse on sovellusohjelma.

Jos Microsoft oikeasti poistaisi vanhoja Windows API ohjelmointirajapintoja sellaisella vauhdilla kuin M-Kar antaa ymmärtää, selaimet windowsissa lakkaisivat toimimasta.

Delphi_Rules kirjoitti:

Ainoastaan M-Kar voi kuvitella, että käyttöjärjestelmästä riippuvien asioiden koodaaminen oikein olisi jotenkin parempi tehdä bildijärjestelmällä (esim. autoconf/automake) kuin FreePascalin kääntäjädirektiiveillä, kuten stdcall; (tyypillinen kutsutapa Windowsissa) tai cdecl; (tyypillinen kutsutapa muissa kuin windows -käyttöjärjestelmissä kuten esim. linux).

Fakta:

autoconf / automake on HIDAS linuxissa ja ERITTÄIN HIDAS windowsissa.

Freepascal -kääntäjä taas on nopea, ja Delphi erittäin nopea.

Eli ohjelman kääntäminen on:

* Erittäin nopeaa Delphillä

* nopeaa Freepascalilla

* hidasta gcc:n ja automaken avulla linuxissa

* erittäin hidasta gcc:n ja automaken avulla windowsissa

Tämä toki herättää kysymyksen: miksi gcc:n ja automaken avulla kääntäminen on juuri windowsissa niin järkyttävän hidasta ?

Ilmeisesti tuo (auto)make -systeemi on rakennettu pythonilla tms. skriptikielellä ja se tekee hommasta erittäin hidasta.

valmis exe saattaa olla gcc:n kääntämänä hieman nopeampi kuin vastaava Delphi -koodi, mutta nopeusero on paljon pienempi, kuin mitä C -koodaajat yleisesti kuvittelevat.

Sensijaan käännösprosessi on Delphillä vähintään 10 kertaa nopeampi kuin mingw-gcc:llä varsinkin isoissa projekteissa.

Eli kun komennat komentoriviltä:

make projekti

jossa on projekti.mak -makefile joka syötetään make:lle parametriksi, niin jos make ja gcc yhdessä vievät tunnin ison projektin kääntämisessä, vastaavan Delphillä koodatun projektin kääntäisi Delphi IDE.stä käsin alle 6 minuutissa painamalla Ctrl-F9 (make project).

Kuinkahan monta kehittäjätyötuntia yrityksissä tuhlataan siihen, että kehittäjä joutuu odottamaan hidasta make:lla ja gcc:llä tehtävää käännöstä?

Delphillä tyypillinen käännösaika on välillä 1 sekunti - 1 minuutti.

Vasta todella isoissa projekteissa Delphin käännösaika voi olla useampi minuutti.

Tämä toki edellyttäen, ettei Windows -käyttöjärjestelmä kärsi RAM -muistin puutteesta.

Toki, jos Windowsissa on yhtäaikaa auki vaikkapa Firefox, jossa satoja avoimia web -sivuja, silloin muuttuu Delphi -käännöksetkin hitaaksi touhuksi, mutta se ei ole Delphin vika, vaan se johtuu ns. RAM trashing -ilmiöstä, eli windows -käyttöjärjestelmä joutuu vaihtamaan tietoa edestakaisin RAM -muistin ja swapfilen välillä.

Mikähän olisi paras tapa tehdä windowsissa sama kuin linuxissa seuraavat komennot:

kill -SIGSTOP 999
kill -SIGCONT 999


Windows -tehtävänhallinnan kun saa näyttämään Process ID:t (PID).

SIGSTOPpia vaan nettiselaimelle , niin käännösaika pysyy Delphillä nopeana.

Windowsissa kyse taitaa olla ns. Thread Suspend -toimnnosta.

Ohjelmallisesti helppo tehdä, mutta valmista komentoriviapuohjelmaa ei windowsissa taida tuohon tarkoitukseen olla.

Pitäisiköhän koodata Delphillä vastaava apuohjelma Windowsille ?

Nettiselaimet muuten ovat tyypillisiä C:llä tai C PLUS PLUS -koodaajien tuotoksia:

Käyttävät RAM -muistia tuhlailevasti ja siten hidastavat tietokoneen kaikkia toimintoja.

JOS selain olisi avointa DELPHIllä tehtyä lähdekoodia, niin osaisin helposti muokata selaimen sellaiseksi, että se EI rohmua järjettömiä määriä RAM -muistia kuten nykyselaimet tekevät.

Tällöin selain itse toimisi nopeammin, eikä selain myöskään hidastaisi muistinrohmuamisellaan muiden sovellusten toimintoja.

Kun löytäisikin jostain "C-PLUS-PLUS to Delphi" source to source "kääntäjän" - sitten pääsisi helposti tekemään itse paremman selaimen, Firefoxin tekijät kun ovat käyttäneet vuosia tekeleensä koodaamiseen, ja silti Firefox on järkyttävä RAM -muistituhlari.

Ja taas pääsis M-Kar aukomaan päätään, kuinka Delpillä tehty selain "ei täytä vaatimuksia" kun sitä ei saa kaiken maailman tarpeettomille ja eksoottisille käyttöjärjestelmäympäristöihin.

Fakta: Delphin uusimmat versiot kääntävät Windowsille ja Linuxille, 32/64 -bit Intel/AMD prosessoreille.

Jos Delphillä käännetty EXE ei toimi linuxilla jollain eksoottisella CPU:lla, jonka markkinaosuus on alle 1%, ketä se kiinnostaa? Ei minua ainakaan.

Pöytä- ja kannettavista PC -tietokoneista (Windows tai Linux) yli 99% on sellaisia, joille Delphin uusin versio kykenee kääntämään.

Lopuillekin voi kääntää Freepascalilla, mutta sitten on debuggaus yhtä tuskaa, kun ei saa Embarcaderon laadukasta kaupallista Debuggeria, vaan joutuu käyttämään Freepascal IDE:n debuggeria, joka ikävä kyllä itse käyttää taustalla heikkolaatuista GDB:tä.

GDB kun linux -fanaatikkojen höpinöistä huolimatta on malliesimerkki siitä, miten EI tehdä hyvää debuggeria.

Selain on sovellusohjelma, joka näyttää web -sivuja, ja samalla toimii ajoalustana web -sivuilla on JavaScript -koodia.

M-Kar haluaa kutsua selainta alustaksi. Javascriptille selain onkin suoritusalusta, mutta samalla selain itse on sovellusohjelma.

Jos Microsoft oikeasti poistaisi vanhoja Windows API ohjelmointirajapintoja sellaisella vauhdilla kuin M-Kar antaa ymmärtää, selaimet windowsissa lakkaisivat toimimasta.

Lue lisää

"Ainoastaan M-Kar voi kuvitella, että käyttöjärjestelmästä riippuvien asioiden koodaaminen oikein olisi jotenkin parempi tehdä bildijärjestelmällä (esim. autoconf/automake) kuin FreePascalin kääntäjädirektiiveillä, kuten stdcall; (tyypillinen kutsutapa Windowsissa) tai cdecl; (tyypillinen kutsutapa muissa kuin windows -käyttöjärjestelmissä kuten esim. linux)."

Buildijärjestelmä tarvitaan siksi, että ei tarvitse käsin yksitellen kääntää jokaista sorsatiedostoa ja linkittää. Jotenkin täytyy hoidella ne lähdekooditiedostojen väliset riippuvuudet ja hallita riippuvuuksia käyttöjärjestelmän ja ulkoisten komponenttien välillä. Näissä sitten tavallisesti myös se deploy, että nappia painamalla asentuu se sovellus sinne palvelimelle toiselle puolelle maapalloa.

"autoconf / automake on HIDAS linuxissa ja ERITTÄIN HIDAS windowsissa."

Ei sitä pidä käyttää missään Windowsissa kun autotoolsin idea on helpottaa siirrettävyyttä unix -järjestelmien välillä ja hallita kaikkia järjestelmien eroja mitä hoideltu esiprosessoinnin direktiiveillä. Se generoi sitä makefileä. Homman toki voi tehdä Makella suoraan ja saa siitä nopeaa myös.

Et nähtävästi ymmärrä sitä, että se autotools siinä vain varmistaa, että prerequisitet on kunnossa, että ympäristölle voidaan kääntää. Ei sitä tarvitse toistamiseen ajaa.

-Erittäin nopeaa Delphillä
-nopeaa Freepascalilla

Miten Deplhillä käännetään vaikka Raspberry Pi:lle ohjelma? Tai miten sillä deployataan vaikka Azureen se ohjelma?

Sekoitat nyt hölmönään että pelkällä koodin käännöllä olisi väliä. Unohdat täysin siirrettävyyden, deployn, dokumenttigeneraattorit, koodin haistelijat, testrunnerit...

"Tämä toki herättää kysymyksen: miksi gcc:n ja automaken avulla kääntäminen on juuri windowsissa niin järkyttävän hidasta ?"

Vaikka siksi kujn Windowsissa ei ole tarkoituskaan käyttää tuollaisia. Windowsissa käännetään vaikka webpackilla tai Visual Studiolla.

"Delphillä tyypillinen käännösaika on välillä 1 sekunti - 1 minuutti."

Kyllähän se kääntäminen hujahtaa jossain hetkessä GCC:llä. Devaus vaiheessa voi ottaa optimoinnit pois päältä ja käyttää ram levyä, ja lisäksi käännöstä voidaan rinnakkaistaa että onhan sitä CPU:ssa ytimiä.

Releasea varten voi laittaa optimoinnit päälle sitten.

"Toki, jos Windowsissa on yhtäaikaa auki vaikkapa Firefox, jossa satoja avoimia web -sivuja, silloin muuttuu Delphi -käännöksetkin hitaaksi touhuksi, mutta se ei ole Delphin vika, vaan se johtuu ns. RAM trashing -ilmiöstä, eli windows -käyttöjärjestelmä joutuu vaihtamaan tietoa edestakaisin RAM -muistin ja swapfilen välillä."

Missä tuollaista muka on nykypäivänä? Miksi et käytä buildiserveriä? Normaalisti vaan kirjoitetaan koodia ja kun pushaillaan koodi repoon niin buildiserveri pyöräyttää sen. Nuhaisinkin Windows 10 ympäristö missä vain 4Gt muistia ajaa nätisti Edgeä ja VS Codea.

"Käyttävät RAM -muistia tuhlailevasti ja siten hidastavat tietokoneen kaikkia toimintoja."

Väärin meni. Käyttävät muistia sitä enemmän mitä löytyy ja käyttävät sitä nopeuttamaan toimintaa. Eihän tietokoneissa ole aikoihin ollut muistista pulaa joten käyttävät sitä cachettamaan ja vältetään sitten CPU:n ja IO järjestelmän kuormitusta.

"JOS selain olisi avointa DELPHIllä tehtyä lähdekoodia, niin osaisin helposti muokata selaimen sellaiseksi, että se EI rohmua järjettömiä määriä RAM -muistia kuten nykyselaimet tekevät."

Melkein kaikki selaimet on avointa koodia. Lähinnä vain Windowsissa on selain suljettu mutta sillä ei ole väliä. Palveluhan se Windows on ja kenelläkään muulla kuin Microsoftilla ei oikein ole mitään asiaa mennä korkean tason rajapinnan alle.

Selainten ram muistin käyttöä toki säätää muualla asetuksista säätämällä, että ei siihen mitään koodin muokkausta tarvitse.

"Tällöin selain itse toimisi nopeammin, eikä selain myöskään hidastaisi muistinrohmuamisellaan muiden sovellusten toimintoja."

Selain hidastuu kun sillä on vähemmän muistia käytössä ja tuo ei muuallekaan vaikuta olennaisesti mitenkään koska melkein kaikki käyttöliittymät toimivat selaimen kautta.

Sehän menee niin, että tietokoneen muistista menee siihen siihen alustaan muistia ja perustoimintoihin, ja vapaa muisti käytetään levyvälimuistina, roskien kerääjille löysää tilaa ja vaikka selaimessa cachena ja selain ajaa suurinta osaa käyttöliittymiä. Jotkut käyttöliittymät toimii ilman sitä mutta ei se niihinkään käytännössä vaikuta koska sieltä vähenee levyvälimuistin määrä lähinnä.

Edelleenkin ram muistin käyttöä toki säätää asetuksista säätämällä.

"Ja taas pääsis M-Kar aukomaan päätään, kuinka Delpillä tehty selain "ei täytä vaatimuksia" kun sitä ei saa kaiken maailman tarpeettomille ja eksoottisille käyttöjärjestelmäympäristöihin."

Nykyisin käytössä olevat selainkomponentit on siirretty aika laajalle ja olisi muuten aika kelvottomia. Esimerkiksi yhdessä vaiheessa MacOS:n, Androidin, ChromeOS:n, iOS:n ja ladattavien Opera ja Chrome selainten ja monien muiden sulautettujen komponenttien selain oli samaa tekniikkaa.

Delphi_Rules kirjoitti:

Ainoastaan M-Kar voi kuvitella, että käyttöjärjestelmästä riippuvien asioiden koodaaminen oikein olisi jotenkin parempi tehdä bildijärjestelmällä (esim. autoconf/automake) kuin FreePascalin kääntäjädirektiiveillä, kuten stdcall; (tyypillinen kutsutapa Windowsissa) tai cdecl; (tyypillinen kutsutapa muissa kuin windows -käyttöjärjestelmissä kuten esim. linux).

Fakta:

autoconf / automake on HIDAS linuxissa ja ERITTÄIN HIDAS windowsissa.

Freepascal -kääntäjä taas on nopea, ja Delphi erittäin nopea.

Eli ohjelman kääntäminen on:

* Erittäin nopeaa Delphillä

* nopeaa Freepascalilla

* hidasta gcc:n ja automaken avulla linuxissa

* erittäin hidasta gcc:n ja automaken avulla windowsissa

Tämä toki herättää kysymyksen: miksi gcc:n ja automaken avulla kääntäminen on juuri windowsissa niin järkyttävän hidasta ?

Ilmeisesti tuo (auto)make -systeemi on rakennettu pythonilla tms. skriptikielellä ja se tekee hommasta erittäin hidasta.

valmis exe saattaa olla gcc:n kääntämänä hieman nopeampi kuin vastaava Delphi -koodi, mutta nopeusero on paljon pienempi, kuin mitä C -koodaajat yleisesti kuvittelevat.

Sensijaan käännösprosessi on Delphillä vähintään 10 kertaa nopeampi kuin mingw-gcc:llä varsinkin isoissa projekteissa.

Eli kun komennat komentoriviltä:

make projekti

jossa on projekti.mak -makefile joka syötetään make:lle parametriksi, niin jos make ja gcc yhdessä vievät tunnin ison projektin kääntämisessä, vastaavan Delphillä koodatun projektin kääntäisi Delphi IDE.stä käsin alle 6 minuutissa painamalla Ctrl-F9 (make project).

Kuinkahan monta kehittäjätyötuntia yrityksissä tuhlataan siihen, että kehittäjä joutuu odottamaan hidasta make:lla ja gcc:llä tehtävää käännöstä?

Delphillä tyypillinen käännösaika on välillä 1 sekunti - 1 minuutti.

Vasta todella isoissa projekteissa Delphin käännösaika voi olla useampi minuutti.

Tämä toki edellyttäen, ettei Windows -käyttöjärjestelmä kärsi RAM -muistin puutteesta.

Toki, jos Windowsissa on yhtäaikaa auki vaikkapa Firefox, jossa satoja avoimia web -sivuja, silloin muuttuu Delphi -käännöksetkin hitaaksi touhuksi, mutta se ei ole Delphin vika, vaan se johtuu ns. RAM trashing -ilmiöstä, eli windows -käyttöjärjestelmä joutuu vaihtamaan tietoa edestakaisin RAM -muistin ja swapfilen välillä.

Mikähän olisi paras tapa tehdä windowsissa sama kuin linuxissa seuraavat komennot:

kill -SIGSTOP 999
kill -SIGCONT 999


Windows -tehtävänhallinnan kun saa näyttämään Process ID:t (PID).

SIGSTOPpia vaan nettiselaimelle , niin käännösaika pysyy Delphillä nopeana.

Windowsissa kyse taitaa olla ns. Thread Suspend -toimnnosta.

Ohjelmallisesti helppo tehdä, mutta valmista komentoriviapuohjelmaa ei windowsissa taida tuohon tarkoitukseen olla.

Pitäisiköhän koodata Delphillä vastaava apuohjelma Windowsille ?

Nettiselaimet muuten ovat tyypillisiä C:llä tai C PLUS PLUS -koodaajien tuotoksia:

Käyttävät RAM -muistia tuhlailevasti ja siten hidastavat tietokoneen kaikkia toimintoja.

JOS selain olisi avointa DELPHIllä tehtyä lähdekoodia, niin osaisin helposti muokata selaimen sellaiseksi, että se EI rohmua järjettömiä määriä RAM -muistia kuten nykyselaimet tekevät.

Tällöin selain itse toimisi nopeammin, eikä selain myöskään hidastaisi muistinrohmuamisellaan muiden sovellusten toimintoja.

Kun löytäisikin jostain "C-PLUS-PLUS to Delphi" source to source "kääntäjän" - sitten pääsisi helposti tekemään itse paremman selaimen, Firefoxin tekijät kun ovat käyttäneet vuosia tekeleensä koodaamiseen, ja silti Firefox on järkyttävä RAM -muistituhlari.

Ja taas pääsis M-Kar aukomaan päätään, kuinka Delpillä tehty selain "ei täytä vaatimuksia" kun sitä ei saa kaiken maailman tarpeettomille ja eksoottisille käyttöjärjestelmäympäristöihin.

Fakta: Delphin uusimmat versiot kääntävät Windowsille ja Linuxille, 32/64 -bit Intel/AMD prosessoreille.

Jos Delphillä käännetty EXE ei toimi linuxilla jollain eksoottisella CPU:lla, jonka markkinaosuus on alle 1%, ketä se kiinnostaa? Ei minua ainakaan.

Pöytä- ja kannettavista PC -tietokoneista (Windows tai Linux) yli 99% on sellaisia, joille Delphin uusin versio kykenee kääntämään.

Lopuillekin voi kääntää Freepascalilla, mutta sitten on debuggaus yhtä tuskaa, kun ei saa Embarcaderon laadukasta kaupallista Debuggeria, vaan joutuu käyttämään Freepascal IDE:n debuggeria, joka ikävä kyllä itse käyttää taustalla heikkolaatuista GDB:tä.

GDB kun linux -fanaatikkojen höpinöistä huolimatta on malliesimerkki siitä, miten EI tehdä hyvää debuggeria.

Selain on sovellusohjelma, joka näyttää web -sivuja, ja samalla toimii ajoalustana web -sivuilla on JavaScript -koodia.

M-Kar haluaa kutsua selainta alustaksi. Javascriptille selain onkin suoritusalusta, mutta samalla selain itse on sovellusohjelma.

Jos Microsoft oikeasti poistaisi vanhoja Windows API ohjelmointirajapintoja sellaisella vauhdilla kuin M-Kar antaa ymmärtää, selaimet windowsissa lakkaisivat toimimasta.

Lue lisää

"Fakta: Delphin uusimmat versiot kääntävät Windowsille ja Linuxille, 32/64 -bit Intel/AMD prosessoreille."

Ei riitä. Selainkomponentit toimivat yleisesti ottaen kaikkialla.

"Jos Delphillä käännetty EXE ei toimi linuxilla jollain eksoottisella CPU:lla, jonka markkinaosuus on alle 1%, ketä se kiinnostaa? Ei minua ainakaan."

ARM on yleisin suoritinarkkitehtuuri.

"Pöytä- ja kannettavista PC -tietokoneista (Windows tai Linux) yli 99% on sellaisia, joille Delphin uusin versio kykenee kääntämään."

Suurin osa natiivista käyttöliittymäkoodista tehdään kännyköille ja tableteille, ja nekin korvautuu HTML5 tekniikalla niiltä osin kuin ei ole välttämättöntä. On jo suurelta osin. Natiivia koodia toki on siellä palvelimen puolella ja nappia painamalla koodi kääntyy ja asentuu konesaliin.

"Selain on sovellusohjelma, joka näyttää web -sivuja, ja samalla toimii ajoalustana web -sivuilla on JavaScript -koodia."

https://fi.wikipedia.org/wiki/Sovellusohjelma

Kerrohan millä tavalla selain helpottaa työtä, vaikka tuntikirjanpitoa. Sovellus toimii tietystikin selaimessa.

"M-Kar haluaa kutsua selainta alustaksi. Javascriptille selain onkin suoritusalusta, mutta samalla selain itse on sovellusohjelma."

Selaimella ei ratkota mitään ongelmaa tai helpoteta työtehtävää.

"Jos Microsoft oikeasti poistaisi vanhoja Windows API ohjelmointirajapintoja sellaisella vauhdilla kuin M-Kar antaa ymmärtää, selaimet windowsissa lakkaisivat toimimasta."

Ei lakkaa. Edgessä ei tarvitse olla riippuvuutta Windows API:n.

"Minulle ei ole koskaan tullut mieleen että kirjoittaisin Delphi koodia kännykällä, joten enköhän minä liene tarkoittanut, tarkoitukseen sopivia työkaluja ja välineitä."

Tarkoitan sitä, että pöytäkoneen näytöllinen koodia on jo valtavan paljon yhteen funktioon.

"Tuskin on olemassa kieltä joka pakottaa tuommoseen."

Kyse onkin siitä, että miksi sitä koodia tarvitsee paljon.

"Kyllä delphikin sallii siirtää rutiinin osia eri tiedostoihin, jotka siten vain kutsutaan kuten C kielessäkin sille kohtaa missä se olisi kun koodi olisi kirjoitettu yhteen tiedostoon."

Siis rutiini = subroutine = funktio.

Puhut että nämä vie jotain näytöllisiä tai useita tiedostoja joka kertoo vain siitä, että koodi on paskaa.

"Mutta saman tehtävän ratkaisu on luettavuuden kannalta hyvä säilyttää ehjänä."

Eli siis pidetään muutamassa rivissä ja siististi niin pitkälle funktionaalisena kuin järkevästi käy.

"Siis rutiini = subroutine = funktio."

- RUTIINI = On yleisinimi koodille joka suorittaa jokin tehtävän

- PÄÄRUTIIN = nimitystä kantaa ohjelmakoodin osa jolla on alirutiini tai edustaa yksinää koko ohjelmaa.

- ALIRUTIINI = nimitystä kantaa ohjelmakoodin osa joka on kutsuttavissa päärutiinista

- FUNKTIO = nimitystä kantaa ohjelman osa joka palauttaa kutsuttaessa jonkin arvon.

Ihan noin rehellisesti ottaen, mitä luulet minun nyt ajattelevan siitä kuinka pätevä olet esittämään DELPHI ympäristön puutteita.

Affiliate-Julkaisia kirjoitti:

"Siis rutiini = subroutine = funktio."

- RUTIINI = On yleisinimi koodille joka suorittaa jokin tehtävän

- PÄÄRUTIIN = nimitystä kantaa ohjelmakoodin osa jolla on alirutiini tai edustaa yksinää koko ohjelmaa.

- ALIRUTIINI = nimitystä kantaa ohjelmakoodin osa joka on kutsuttavissa päärutiinista

- FUNKTIO = nimitystä kantaa ohjelman osa joka palauttaa kutsuttaessa jonkin arvon.

Ihan noin rehellisesti ottaen, mitä luulet minun nyt ajattelevan siitä kuinka pätevä olet esittämään DELPHI ympäristön puutteita.

Lue lisää

https://en.wikipedia.org/wiki/Routine

Routine, another name for a computer subprogram

- Subroutine, a routine inside another routine
- Coroutine, generalized reentrant computer subroutine having multiple entry points

Ja nämä toteutetaan tietysti funktioina.

"Ihan noin rehellisesti ottaen, mitä luulet minun nyt ajattelevan siitä kuinka pätevä olet esittämään DELPHI ympäristön puutteita."

Tuossahan itse osoitit omaa epäpätevyyttäsi kun yleensäkin käytät termiä "rutiini". Sehän viittaa vahvasti proseduraaliseen ohjelmointiin: https://fi.wikipedia.org/wiki/Proseduraalinen_ohjelmointi

Surkeat ohjelmointikielet toki tekee rajoitteita mutta tietysti ongelmia ratkotaan funktionaalisesti tai putkilla. Joku oliomallinnus nyt on se viimeinen keino ja siinäkin otetaan askeleita surkeaan proseduraaliseen ohjelmointiin mikä on paskaa.

Jos ongelmaa ei ratkota funktionaalisesti, menee virheettömäksi todistaminen astetta monimutkaisemmaksi.

Höpö höpö,
Tuolla wiki linkissä sanottiin ihan sama asia, minkä minäkin jo kerroin suomeksi mitä vittua sinä saivartelet.

Affiliate-Julkaisia kirjoitti:

Höpö höpö,
Tuolla wiki linkissä sanottiin ihan sama asia, minkä minäkin jo kerroin suomeksi mitä vittua sinä saivartelet.

"Routine, another name for a computer subprogram "

Eli siis puhutaan aliohjelmista, voivat olla myös sellaisia joihin tullaan useasta kohdin sisään ja ovat sitten coroutineja.

Mutta minkä aliohjelmat, eli mikä taho tuon kutsuu.

Mikä on tietokoneen pää ohjelma,
älä vääntele noita termejä päin vittua.

tämä saatanan ali ohjelma on tehty Delphillä
ja tämä delphillä tehty ohjelma tässä oli käsittelyssä

Tämä tietokoneen aliohjelma voi koostua yhdestä rutiinista
jolloin se on Main, ja jos siinä on Sub silloin se kotsuu jotain toista rutiinia.

Tuo väittämäsi on perseestä
( "Siis rutiini = subroutine = funktio" )
ei pidä alkuunkaan paikkaansa

Tietokoneen järjestelmä ajaa näitä ohjelmia jolloin siitä voidaan sanoa "computer subprogram"

COMPUTER saatan, etkä osaa lukea

ME PUHUTTIIN DELPHISTÄ JA SEN RUTINEISTA

ETKÖ NÄÄ TEHNEESI MITÄÄN VIRHETTÄ
SE EI OLE MIKÄÄN VITUN FUNKTIO, taulapää

Affiliate-Julkaisia kirjoitti:

Mutta minkä aliohjelmat, eli mikä taho tuon kutsuu.

Mikä on tietokoneen pää ohjelma,
älä vääntele noita termejä päin vittua.

tämä saatanan ali ohjelma on tehty Delphillä
ja tämä delphillä tehty ohjelma tässä oli käsittelyssä

Tämä tietokoneen aliohjelma voi koostua yhdestä rutiinista
jolloin se on Main, ja jos siinä on Sub silloin se kotsuu jotain toista rutiinia.

Tuo väittämäsi on perseestä
( "Siis rutiini = subroutine = funktio" )
ei pidä alkuunkaan paikkaansa

Tietokoneen järjestelmä ajaa näitä ohjelmia jolloin siitä voidaan sanoa "computer subprogram"

COMPUTER saatan, etkä osaa lukea

ME PUHUTTIIN DELPHISTÄ JA SEN RUTINEISTA

ETKÖ NÄÄ TEHNEESI MITÄÄN VIRHETTÄ
SE EI OLE MIKÄÄN VITUN FUNKTIO, taulapää

Lue lisää

"Mutta minkä aliohjelmat, eli mikä taho tuon kutsuu."

Ei sillä ole niin väliä. Rutiinilla tarkoitetaan aliohjelmaa, sanakirjamääritelmän mukaan jota pääohjelma kutsuu. Prosessissa on se aloituskohta "main" josta se voi siirtyä rutiineihin, eli aliohjelmiin.

"SE EI OLE MIKÄÄN VITUN FUNKTIO, taulapää"

Koita nyt käsittää, että ohjelmoitaessa funktionaalisesti, sitä tosiaankin tehdään funktioita.

Ja se funktionaalisuus on aika tärkeätä kun todistetaan virheettömyyttä helposti. Kun jankkaat niistä rutiineista niin tarkoittaako tämä siis sitä, että Delphillä tekeminen lisää todennäköisyyttä bugeille ja virheettömyys onkin höpöhöpöä?

Joo. Sille on menetelmiä ja työkaluja kehittää äärimmäisen virheettömiä ohjelmia.

Eli ei mitään olennaista eroa. 50-luvun omituisuuksia mitkä lähinnä lisää ylimääräistä sotkua koodiin.

Kannattaa muistaa että tietokoneohjelmien kuvaus on kuitenkin yksinkertaisimmillaan lamdakalkyylia. https://en.wikipedia.org/wiki/Lambda_calculus

Eli, funktioita. Kaikki muu näyttäisi lähinnä sotkevan ohjelmointia heikosti osaavien päätä.