C Pascal

Olen samaa mieltä, että kumpikin on samanlaisia aluksi, mutta c:ssä on sitten paljon enemmän laajentumismahdollisuuksia jos uudet asiat alkavat kiinnosta alkuopettelun jälkeen. Oliot ja kaikki sisäkkeiset muuttuja ja struktuurien sekä muut ihmeelliset määrittelytyypit.

Alussa melko samaa, syntaksi on vain erilainen, laajentumismahdollisuuksien takia suosittaisin kyllä c:tä, vaikka se onkin aluksi hieman vaikeaa syntaksiltaan, mutta helposti oppii.

Pascalin kanssa voi syntyä ongelma jos pitää saada yhteyksiä Ring-0 eli järjestelmän tason käyttöihin.

aluksimelkosamaa kirjoitti:

Olen samaa mieltä, että kumpikin on samanlaisia aluksi, mutta c:ssä on sitten paljon enemmän laajentumismahdollisuuksia jos uudet asiat alkavat kiinnosta alkuopettelun jälkeen. Oliot ja kaikki sisäkkeiset muuttuja ja struktuurien sekä muut ihmeelliset määrittelytyypit.

Alussa melko samaa, syntaksi on vain erilainen, laajentumismahdollisuuksien takia suosittaisin kyllä c:tä, vaikka se onkin aluksi hieman vaikeaa syntaksiltaan, mutta helposti oppii.

Lue lisää

"Oliot ja kaikki sisäkkeiset muuttuja ja struktuurien sekä muut ihmeelliset määrittelytyypit."

Tuota....c:ssä ei ole olioita...c :ssa on...struct:it toki löytyy.

Eräs esimerkki miten tehdään ja käytetään jaettuja kirjastoja Pascalilla (
testattu freepascal 2.6.4:llä joka on julkaistu vuonna 2014, mutta ei tämä ole
mikään uusi asia)


Aliohjelmakirjasto voidaan tehdä niin että valitaan Luo uusi projekti kohdassa
Aliohelmakirjasto

Täydennä alla kuvatunlaiseksi
----8

Pascal:ssa aliohjelmien kutsutapa ei ole "kiinnitetty" tiettyyn tapaan. Ohjelmoija voi kiinnittää ne aliohjelmat joita hän haluaa (esim. jaetut kirjastot).

Jos halutaan käyttää C-kielen tapaa niin sekin on mahdollista!
Kun lisätään aliohjelman esittelyyn sana: cdecl ; niin käytössä on C-kielen tapainen kutsutapa.

cdecl kirjoitti:

Pascal:ssa aliohjelmien kutsutapa ei ole "kiinnitetty" tiettyyn tapaan. Ohjelmoija voi kiinnittää ne aliohjelmat joita hän haluaa (esim. jaetut kirjastot).

Jos halutaan käyttää C-kielen tapaa niin sekin on mahdollista!
Kun lisätään aliohjelman esittelyyn sana: cdecl ; niin käytössä on C-kielen tapainen kutsutapa.

Lue lisää

Ei kyllä taida olla Pascalin ominaisuus vaan riippuu työkalusta... Tuskin on standardi tapa.

Vielä kun joku osaisi perustella miksi pitäisi kiduttaa itseään jollain Pascalilla kun siitä on aika jo mennyt ohi. Vai onko tarkoituksena joku nostalgiafiilistely, vähän niin kuin Cobolilla tekisi ohjelmia?

Oliot eli struktuurit (struct {}), joita voi ajonaikana itseluoda, jopa itsekursiivisia globaaleita funktiota käyttäen näiden "olioiden eli struktuurien sisällä" ja täydentäen ovat C:ssä mahdollisia, koska niihin voivat vaikuttaa toisten yhtäaikaa ajossa olevien globaalien funktioiden samanaikaiset muut globaalit funktiot sekä muuttujat ;)

cdecl kirjoitti:

Pascal:ssa aliohjelmien kutsutapa ei ole "kiinnitetty" tiettyyn tapaan. Ohjelmoija voi kiinnittää ne aliohjelmat joita hän haluaa (esim. jaetut kirjastot).

Jos halutaan käyttää C-kielen tapaa niin sekin on mahdollista!
Kun lisätään aliohjelman esittelyyn sana: cdecl ; niin käytössä on C-kielen tapainen kutsutapa.

Lue lisää

Tuollainen esim. "struct" määritelmä, joka määrittää jonkun funktiojoukon sekä koko ohjelman kääntäjäkohtaista syntaksia voi täysin määritellä #define-tiedostoissa, voit antaa pre-processorille sellaisessa tiedossa käskyn että "#defin struct BEGIN_ALREADY", jolloin kääntäjä tottelee koko loppuohjelman tuota uutta syntaksia joka on sen tietyn ohjelman kääntämistä varten tehty ;)

M-Kar kirjoitti:

Ei kyllä taida olla Pascalin ominaisuus vaan riippuu työkalusta... Tuskin on standardi tapa.

Vielä kun joku osaisi perustella miksi pitäisi kiduttaa itseään jollain Pascalilla kun siitä on aika jo mennyt ohi. Vai onko tarkoituksena joku nostalgiafiilistely, vähän niin kuin Cobolilla tekisi ohjelmia?

Lue lisää

"Oliot ja kaikki sisäkkeiset muuttuja ja struktuurien sekä muut ihmeelliset määrittelytyypit."

kyllä cdecl taitaa olla suht. "de-facto" pascal työkaluissa.

"Vielä kun joku osaisi perustella miksi pitäisi kiduttaa itseään jollain Pascalilla kun siitä on aika jo mennyt ohi."

Täysin samaa mieltä.

code_red kirjoitti:

"Oliot ja kaikki sisäkkeiset muuttuja ja struktuurien sekä muut ihmeelliset määrittelytyypit."

kyllä cdecl taitaa olla suht. "de-facto" pascal työkaluissa.

"Vielä kun joku osaisi perustella miksi pitäisi kiduttaa itseään jollain Pascalilla kun siitä on aika jo mennyt ohi."

Täysin samaa mieltä.

Lue lisää

Miten ison Pascal ohelman olet tehnyt?

Oletko kokeillut sitä toisessa käyttöjärjestelmässä?

Mutta ei siis ole Pascalin tapa vaan on työkalukohtainen viritys.

M-Kar kirjoitti:

Mutta ei siis ole Pascalin tapa vaan on työkalukohtainen viritys.

cdecl toimii kaikissa tällä vuosikymmenellä ilmestyneissä Pascaleissa (valmistajasta riippumatta).

Mitä järkeä olisi tehdä se erilailla (jos koodarit ovat käyttäneet sitä jo yli parikymmentä vuotta)?

joo pa kirjoitti:

cdecl toimii kaikissa tällä vuosikymmenellä ilmestyneissä Pascaleissa (valmistajasta riippumatta).

Mitä järkeä olisi tehdä se erilailla (jos koodarit ovat käyttäneet sitä jo yli parikymmentä vuotta)?

Lue lisää

Mitä järkeä on tehdä sitä Pascalilla joka vaatii ylimääräistä, standardinvastaista säätämistä kun voisi asian tehdä fiksumminkin, esim. C:llä ?

M-Kar kirjoitti:

Mitä järkeä on tehdä sitä Pascalilla joka vaatii ylimääräistä, standardinvastaista säätämistä kun voisi asian tehdä fiksumminkin, esim. C:llä ?

Standardin vastaista on esim. tehdä C tai C# grafiikka ohjelmia!

Esim. tulostaminen on ainoastaan sallittu standarditulostusvirtaan!

näinpä1 kirjoitti:

Standardin vastaista on esim. tehdä C tai C# grafiikka ohjelmia!

Esim. tulostaminen on ainoastaan sallittu standarditulostusvirtaan!

Höpö höpö.

näinpä1 kirjoitti:

Standardin vastaista on esim. tehdä C tai C# grafiikka ohjelmia!

Esim. tulostaminen on ainoastaan sallittu standarditulostusvirtaan!

C kielelle on standardoituja grafiikkarajapintoja, jotka ovat tehty C-kielellä.

M-Kar kirjoitti:

C kielelle on standardoituja grafiikkarajapintoja, jotka ovat tehty C-kielellä.

Osaatko sanoa mitä ne ovat? Ainakin nuo yleisimmät ikkunointijärjestelmät muuttuvat niin useasti ja ovat erilaisia (että tuskin niistä löytyy standardia).

Mutta joku X Window System tai openGL voisi olla (Ovat ainakin yleiskäyttöisiä kirjastoja ) ? Olisi kiva tietää mikä standardi on sen/niiden takana.

Ja jos on standardoitu niin todennäköisesti samaan standardiin nojautuu useampi valmistaja/tekijä (kilpailevia kirjastoja joiden väliltä voi valita)?

Kerro nyt ihmeessä!

fffffffffee kirjoitti:

Osaatko sanoa mitä ne ovat? Ainakin nuo yleisimmät ikkunointijärjestelmät muuttuvat niin useasti ja ovat erilaisia (että tuskin niistä löytyy standardia).

Mutta joku X Window System tai openGL voisi olla (Ovat ainakin yleiskäyttöisiä kirjastoja ) ? Olisi kiva tietää mikä standardi on sen/niiden takana.

Ja jos on standardoitu niin todennäköisesti samaan standardiin nojautuu useampi valmistaja/tekijä (kilpailevia kirjastoja joiden väliltä voi valita)?

Kerro nyt ihmeessä!

Lue lisää

"Osaatko sanoa mitä ne ovat?"

Vanha Xlib sekä Motif ovat jo ikivanhoja standardeja (UNIX 98 workstation) mutta sitä ei välttämättä kannata enää käyttää. Mutta, esim. GTK 2 on standardoitu (ISO/IEC International Standard 23360), kuten myös Xlib löytyy tästä).

OpenGL:stä vastaa Khronos Group ja tämä on käytännössä konsortio johon kuuluu käytännössä ~kaikki alan yritykset ja jonka tarkoitus on ylläpitää specifikaatioita. "Open standards for graphics, media and parallel computation".

"Ja jos on standardoitu niin todennäköisesti samaan standardiin nojautuu useampi valmistaja/tekijä (kilpailevia kirjastoja joiden väliltä voi valita)?"

Kyllä, samoja standardeja käyttää useampi valmistaja/tekijä. GTK 2:sta esimerkiksi tukee Attachmate, Canonical, Debian ja Red Hat. OpenGL:ää nyt löytyy melkein joka paikasta.

Standardeissa on standardoitu kirjaston rajapinta ja kirjasto voi myös olla sama usealla valmistajalla jos lisensointi mahdollistaa sen. GTK 2 ja Motif perustuvat nykyisin käytännössä kaikki samaan koodiin eri valmistajilla.

M-Kar kirjoitti:

"Osaatko sanoa mitä ne ovat?"

Vanha Xlib sekä Motif ovat jo ikivanhoja standardeja (UNIX 98 workstation) mutta sitä ei välttämättä kannata enää käyttää. Mutta, esim. GTK 2 on standardoitu (ISO/IEC International Standard 23360), kuten myös Xlib löytyy tästä).

OpenGL:stä vastaa Khronos Group ja tämä on käytännössä konsortio johon kuuluu käytännössä ~kaikki alan yritykset ja jonka tarkoitus on ylläpitää specifikaatioita. "Open standards for graphics, media and parallel computation".

"Ja jos on standardoitu niin todennäköisesti samaan standardiin nojautuu useampi valmistaja/tekijä (kilpailevia kirjastoja joiden väliltä voi valita)?"

Kyllä, samoja standardeja käyttää useampi valmistaja/tekijä. GTK 2:sta esimerkiksi tukee Attachmate, Canonical, Debian ja Red Hat. OpenGL:ää nyt löytyy melkein joka paikasta.

Standardeissa on standardoitu kirjaston rajapinta ja kirjasto voi myös olla sama usealla valmistajalla jos lisensointi mahdollistaa sen. GTK 2 ja Motif perustuvat nykyisin käytännössä kaikki samaan koodiin eri valmistajilla.

Lue lisää

Selitän vielä että "rekursiivinen funktio", eli c:ssä sanotaan että, sellainen että kun on eri tavoilla määriteltyjä funktioita esim. jonkun "olion" eli struktuurin sisällä, niin kaikissa tilanteessa voi määritellä aina jokaisen funktion jokaisen muuttujan staattiseksi sen funktion sisällä, struktuurin sisällä tai koko ohjelmalle.

Esim. kun kerran tutkin opengl:n lähdekoodia, niin juuri näissä 3d-laskennoissa oli hyödynnetty tuota ominaisuutta, että on struct { ... struct { ---, ja funktioiden kaikkien sisällä paljon eri tavoilla määriteltyjä muuttujia, jolloin se perusfunktio palauttaa arvon kun on sen saanut valmiiksi).

Itse tein eräälle firmalle, ja opetin toimistosihteeriä myös silloin samalla: osasi käyttää Exceliä, sellaisen ohjelman, joka muodostaa ja tulostaa excel-taulukkoon syötetyistä laskutustiedoista, aivan pankin näköisen, virallisen laskun laser-tulostimella.

Tuossa excelin sekä tietokantojen lukemisen ja manipuloimisen apuna käytin visualbasicia. Tuli aika hyvä, aina kun aika on kirjoittaa lasku niin syöttää vain numerot ja painaa nappia, niin tulee oikean muotoinen lasku ulostimesta, ja laskun numero juoksee automaattisesti.

M-Kar kirjoitti:

"Osaatko sanoa mitä ne ovat?"

Vanha Xlib sekä Motif ovat jo ikivanhoja standardeja (UNIX 98 workstation) mutta sitä ei välttämättä kannata enää käyttää. Mutta, esim. GTK 2 on standardoitu (ISO/IEC International Standard 23360), kuten myös Xlib löytyy tästä).

OpenGL:stä vastaa Khronos Group ja tämä on käytännössä konsortio johon kuuluu käytännössä ~kaikki alan yritykset ja jonka tarkoitus on ylläpitää specifikaatioita. "Open standards for graphics, media and parallel computation".

"Ja jos on standardoitu niin todennäköisesti samaan standardiin nojautuu useampi valmistaja/tekijä (kilpailevia kirjastoja joiden väliltä voi valita)?"

Kyllä, samoja standardeja käyttää useampi valmistaja/tekijä. GTK 2:sta esimerkiksi tukee Attachmate, Canonical, Debian ja Red Hat. OpenGL:ää nyt löytyy melkein joka paikasta.

Standardeissa on standardoitu kirjaston rajapinta ja kirjasto voi myös olla sama usealla valmistajalla jos lisensointi mahdollistaa sen. GTK 2 ja Motif perustuvat nykyisin käytännössä kaikki samaan koodiin eri valmistajilla.

Lue lisää

Standardilla on merkitystä vasta sitten jos koodipohja on eri. Standardin ideanahan on se että
siihen nojautuvat järjestelmät voivat vaihtaa eri valmistajaan (eri koodiin) "lennossa".

Lisäksi jos koodipohja on sama menetetään se etu että jos koodissa on haavoittuvuus niin
sitä ei pysty kiertämään vaihtamalla valmistajaa. Siksi on hyvä että tarjolla on useampi tekijä joka käyttää samaa rajapintaa mutta eri koodia sen alla!

kaksi koodia kirjoitti:

Standardilla on merkitystä vasta sitten jos koodipohja on eri. Standardin ideanahan on se että
siihen nojautuvat järjestelmät voivat vaihtaa eri valmistajaan (eri koodiin) "lennossa".

Lisäksi jos koodipohja on sama menetetään se etu että jos koodissa on haavoittuvuus niin
sitä ei pysty kiertämään vaihtamalla valmistajaa. Siksi on hyvä että tarjolla on useampi tekijä joka käyttää samaa rajapintaa mutta eri koodia sen alla!

Lue lisää

"Standardilla on merkitystä vasta sitten jos koodipohja on eri. Standardin ideanahan on se että siihen nojautuvat järjestelmät voivat vaihtaa eri valmistajaan (eri koodiin) "lennossa"."

Voi se valmistaja olla eri, mutta koodi samaa pohjaa.

Ja tämähän on itseasiassa se ideaalinen tilanne. Jos ne olisi eri koodista rakennettu niin niissä kuitenkin olisi versioeroja ja säätämistä kun standardointi on helposti epätäydellistä kun on kyse jostain monimutkaisesta. On paljon helpompaa standardoida joku ASCII merkistö kuin joku ohjelmointirajapinta.

"Lisäksi jos koodipohja on sama menetetään se etu että jos koodissa on haavoittuvuus niin sitä ei pysty kiertämään vaihtamalla valmistajaa."

Ne ohjelmakomponentit jotka ovat standardin asemassa (esim. zlib) ovat kyllä niin hyvin hinkattua koodia että ei tarvitse ottaa stressiä mistään turva-aukoista.

M-Kar kirjoitti:

"Standardilla on merkitystä vasta sitten jos koodipohja on eri. Standardin ideanahan on se että siihen nojautuvat järjestelmät voivat vaihtaa eri valmistajaan (eri koodiin) "lennossa"."

Voi se valmistaja olla eri, mutta koodi samaa pohjaa.

Ja tämähän on itseasiassa se ideaalinen tilanne. Jos ne olisi eri koodista rakennettu niin niissä kuitenkin olisi versioeroja ja säätämistä kun standardointi on helposti epätäydellistä kun on kyse jostain monimutkaisesta. On paljon helpompaa standardoida joku ASCII merkistö kuin joku ohjelmointirajapinta.

"Lisäksi jos koodipohja on sama menetetään se etu että jos koodissa on haavoittuvuus niin sitä ei pysty kiertämään vaihtamalla valmistajaa."

Ne ohjelmakomponentit jotka ovat standardin asemassa (esim. zlib) ovat kyllä niin hyvin hinkattua koodia että ei tarvitse ottaa stressiä mistään turva-aukoista.

Lue lisää

"Ne ohjelmakomponentit jotka ovat standardin asemassa (esim. zlib) ovat kyllä niin hyvin hinkattua koodia että ei tarvitse ottaa stressiä mistään turva-aukoista."

OpenSSL cryptography library - sehän on myös ollut avoimen lähdekoodin fanaatikkojen (eli fanaattisesti GPL -lisenssiä kannattavien) tekeleissä "standardin asemassa", joten M-Karin mukaan varmaankin "on kyllä niin hyvin hinkattua koodia että ei tarvitse ottaa stressiä mistään turva-aukoista."

Mutta kuinkas kävikään:

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

Jos tuo OpenSSL olisi koodattu Objectpascalilla ja käännetty Freepascalilla, niin tuota Heartbleedia ei olisi koskaan ollutkaan.

Mutta tosiasia on se, että niin kauan kuin C ja C -kielten käyttöä yleisesti jatketaan, niin kauan tietoturva-aukkoja on ja tulee aina olemaan.

Jos C ja C -kielten käyttö kertakaikkiaan lopetettaisiin liian vaarallisena ja kirjoitettaisiin kaikki uusiksi Objectpascalilla, niin rikollisille koittaisivat kovat ajat, kun tietoturva-aukkoja ei löytyisi enää mistään.

Sopiikin epäillä, että C ja C -kielten vahva asema johtuu siitä, että illuminaatit ja vapaamuurarit ovat pitäneet ja edelleen pitävät huolta siitä, että yritysmaailmassa suositaan näitä vaarallisia ohjelmointikieliä.

Kas kun näin taataan, että käytännössä kaikissa C:llä ja C :lla koodatuissa ohjelmistoissa on 1 tai useampi tietoturva-aukko, ja ne on sinne tahallaan laitettu siksi, että näin esim. NSA:n on illuminaattien pyynnöstä helpompi murtautua mihin tahansa tietojärjestelmään.

C:n ja C :n suorastaan kiduttavan kryptinen syntaksi on tahallaan suunniteltu vaikeaksi ymmärtää. Näin varmistetaan se, että kun kyseisiä kieliä käyttävä koodari joutuu käyttämään 95% aivokapasiteetistaan hankalan ja ikävän syntaksin hallintaan niin muuhun koodaustyöhön jää enää 5%, tämä riittää varmistamaan, ettei koodaaja enää hallitse kokonaisuutta, vaan tietoturva-aukkoja aina syntyy.

FreePascalilla onkin kiva kirjoitella tietoturvallista koodia, menköön NSA:n pojat murtautumaan sen kilpailevan yrityksen järjestelmiin, jotka on C:llä ja/tai C :lla koodattu, siksi kilpailijan järjestelmän murtaminen on paljon helpompaa.

Kun järjestelmä koodataan huolellisesti Objectpascalilla, tulee NSA:n pojille suru puseroon, kun eivät kovasta yrittämisestä huolimatta löydä yhtään turva-aukkoa itse sovelluksesta.

Kuinka monta turva-aukkoa sitten löytyy itse käyttöjärjestelmästä, se on hyvä kysymys. Ja jos löytyy, ovatko ne ulkoapäin internetistä tulevien hyökkääjien hyödynnettävissä ?

Ketjussa väitetään Pascalilla tai Objectpascalilla koodaamisen olevan itsekidutusta.

Tosiasiassa asia on juuri päinvastoin: C:llä tai C :lla koodaus on itsekidutusta.

Mutta M-Karia suuresti häiritsee se, että esim. pascalin ja objectpascalin cdecl; -kutsutapamäärite ei ole ISO:n virallisesti standardoima. Mutta miksi edes tarvitsisi olla, kun se kuitenkin toimii samoin kaikissa tällä vuosituhannella julkaistuissa pascal / objectpascal -kääntäjissä.

Virallisella standardoinnilla ei saavuteta mitään etua, mutta haittoja kyllä:

Jos asiasta tehtäisiin virallinen standardi, niin dokumentointi eli asiakirjat olisivat ISO:n tekijänoikeuksien alaisia, eikä dokumentointia voisi enää avoimesti julkaista netissä, ei ainakaan maksamatta lisenssimaksuja ISO:lle.

Kuka ne sitten maksaisi?

Ei kukaan, vaan dokumentointi jouduttaisiin poistamaan julkisesta kaikkien saatavilla olevasta netistä, ettei tekijänoikeuksia loukattaisi.

Objectpascal -koodaajat osaavat hommansa ilmankin, että ISO järjestönä puuttuisi asioihin ja tulisivat rahastamaan tekijänoikeusvaateillaan.

Vaikkapa ruuvien ja mutterien kierteissä viralliset standardit ovat hyvä asia, ne takaavat yhteensopivuuden.

Mutta ohjelmointimaailmassa, kuka haluaa maksaa ylimääräistä siitä, että laaditaan tarpeettomia standardeja, ja dokumentointi siirtyy maksumuurin taakse?

Ehkä C ja C -koodaajat ovat niin hölmöjä, että haluavat maksaa.

ObjectPascal -koodaajien ei onneksi tarvitse, ei ainakaan itse ohjelmointikielen osalta.

FreePascal_koodaaja kirjoitti:

"Ne ohjelmakomponentit jotka ovat standardin asemassa (esim. zlib) ovat kyllä niin hyvin hinkattua koodia että ei tarvitse ottaa stressiä mistään turva-aukoista."

OpenSSL cryptography library - sehän on myös ollut avoimen lähdekoodin fanaatikkojen (eli fanaattisesti GPL -lisenssiä kannattavien) tekeleissä "standardin asemassa", joten M-Karin mukaan varmaankin "on kyllä niin hyvin hinkattua koodia että ei tarvitse ottaa stressiä mistään turva-aukoista."

Mutta kuinkas kävikään:

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

Jos tuo OpenSSL olisi koodattu Objectpascalilla ja käännetty Freepascalilla, niin tuota Heartbleedia ei olisi koskaan ollutkaan.

Mutta tosiasia on se, että niin kauan kuin C ja C -kielten käyttöä yleisesti jatketaan, niin kauan tietoturva-aukkoja on ja tulee aina olemaan.

Jos C ja C -kielten käyttö kertakaikkiaan lopetettaisiin liian vaarallisena ja kirjoitettaisiin kaikki uusiksi Objectpascalilla, niin rikollisille koittaisivat kovat ajat, kun tietoturva-aukkoja ei löytyisi enää mistään.

Sopiikin epäillä, että C ja C -kielten vahva asema johtuu siitä, että illuminaatit ja vapaamuurarit ovat pitäneet ja edelleen pitävät huolta siitä, että yritysmaailmassa suositaan näitä vaarallisia ohjelmointikieliä.

Kas kun näin taataan, että käytännössä kaikissa C:llä ja C :lla koodatuissa ohjelmistoissa on 1 tai useampi tietoturva-aukko, ja ne on sinne tahallaan laitettu siksi, että näin esim. NSA:n on illuminaattien pyynnöstä helpompi murtautua mihin tahansa tietojärjestelmään.

C:n ja C :n suorastaan kiduttavan kryptinen syntaksi on tahallaan suunniteltu vaikeaksi ymmärtää. Näin varmistetaan se, että kun kyseisiä kieliä käyttävä koodari joutuu käyttämään 95% aivokapasiteetistaan hankalan ja ikävän syntaksin hallintaan niin muuhun koodaustyöhön jää enää 5%, tämä riittää varmistamaan, ettei koodaaja enää hallitse kokonaisuutta, vaan tietoturva-aukkoja aina syntyy.

FreePascalilla onkin kiva kirjoitella tietoturvallista koodia, menköön NSA:n pojat murtautumaan sen kilpailevan yrityksen järjestelmiin, jotka on C:llä ja/tai C :lla koodattu, siksi kilpailijan järjestelmän murtaminen on paljon helpompaa.

Kun järjestelmä koodataan huolellisesti Objectpascalilla, tulee NSA:n pojille suru puseroon, kun eivät kovasta yrittämisestä huolimatta löydä yhtään turva-aukkoa itse sovelluksesta.

Kuinka monta turva-aukkoa sitten löytyy itse käyttöjärjestelmästä, se on hyvä kysymys. Ja jos löytyy, ovatko ne ulkoapäin internetistä tulevien hyökkääjien hyödynnettävissä ?

Ketjussa väitetään Pascalilla tai Objectpascalilla koodaamisen olevan itsekidutusta.

Tosiasiassa asia on juuri päinvastoin: C:llä tai C :lla koodaus on itsekidutusta.

Mutta M-Karia suuresti häiritsee se, että esim. pascalin ja objectpascalin cdecl; -kutsutapamäärite ei ole ISO:n virallisesti standardoima. Mutta miksi edes tarvitsisi olla, kun se kuitenkin toimii samoin kaikissa tällä vuosituhannella julkaistuissa pascal / objectpascal -kääntäjissä.

Virallisella standardoinnilla ei saavuteta mitään etua, mutta haittoja kyllä:

Jos asiasta tehtäisiin virallinen standardi, niin dokumentointi eli asiakirjat olisivat ISO:n tekijänoikeuksien alaisia, eikä dokumentointia voisi enää avoimesti julkaista netissä, ei ainakaan maksamatta lisenssimaksuja ISO:lle.

Kuka ne sitten maksaisi?

Ei kukaan, vaan dokumentointi jouduttaisiin poistamaan julkisesta kaikkien saatavilla olevasta netistä, ettei tekijänoikeuksia loukattaisi.

Objectpascal -koodaajat osaavat hommansa ilmankin, että ISO järjestönä puuttuisi asioihin ja tulisivat rahastamaan tekijänoikeusvaateillaan.

Vaikkapa ruuvien ja mutterien kierteissä viralliset standardit ovat hyvä asia, ne takaavat yhteensopivuuden.

Mutta ohjelmointimaailmassa, kuka haluaa maksaa ylimääräistä siitä, että laaditaan tarpeettomia standardeja, ja dokumentointi siirtyy maksumuurin taakse?

Ehkä C ja C -koodaajat ovat niin hölmöjä, että haluavat maksaa.

ObjectPascal -koodaajien ei onneksi tarvitse, ei ainakaan itse ohjelmointikielen osalta.

Lue lisää

"Mutta kuinkas kävikään:"

Tuohan korjattiin ennätysnopeasti. Eikä tarvinnut sovelluskehittäjältä mitään toimia, tuli ihan käyttöjärjestelmän päivityksistä.

"Jos C ja C -kielten käyttö kertakaikkiaan lopetettaisiin liian vaarallisena ja kirjoitettaisiin kaikki uusiksi Objectpascalilla, niin rikollisille koittaisivat kovat ajat, kun tietoturva-aukkoja ei löytyisi enää mistään."

Kovat ajat koittaa siitä kun Lazarus ei ole stabiili vaan kerta vuoteen jotain paskotaan rikki. Pelkkä ohjelmointikieli ei niiltä turva-aukoilta suojaa.

"C:n ja C :n suorastaan kiduttavan kryptinen syntaksi on tahallaan suunniteltu vaikeaksi ymmärtää."

Tosiasiassa C:n ja C :n syntaksi osoittautui menestyksekkääksi koska se oli selkeä, nopeata kirjoittaa ja helppo lukea. C ja C jyräsi Pascalin. Eikä ainoastaan sitä vaan myös Ada:n jonka syntaksi on Pascalin kaltainen. On vaan paljon parempi kieli kuin mikään Pascal. C:n ja C :n syntaksia sitten apinoi Java, C#, PHP, Javascript, Typescript jne.

Tuntuu siltä, että vasta nämä Ruby, CoffeeScript, Python jne. tuovat jotain etua syntaksiin selkeyden osalta.

"Mutta ohjelmointimaailmassa, kuka haluaa maksaa ylimääräistä siitä, että laaditaan tarpeettomia standardeja, ja dokumentointi siirtyy maksumuurin taakse?"

Standardoi sitten vaikka W3C:ssä jos siltä tuntuu. Ja mikään ei muuten estä tekemästä toteutusta ensin, dokumentoi sen ja sitten vasta standardoi.

M-Kar kirjoitti:

"Mutta kuinkas kävikään:"

Tuohan korjattiin ennätysnopeasti. Eikä tarvinnut sovelluskehittäjältä mitään toimia, tuli ihan käyttöjärjestelmän päivityksistä.

"Jos C ja C -kielten käyttö kertakaikkiaan lopetettaisiin liian vaarallisena ja kirjoitettaisiin kaikki uusiksi Objectpascalilla, niin rikollisille koittaisivat kovat ajat, kun tietoturva-aukkoja ei löytyisi enää mistään."

Kovat ajat koittaa siitä kun Lazarus ei ole stabiili vaan kerta vuoteen jotain paskotaan rikki. Pelkkä ohjelmointikieli ei niiltä turva-aukoilta suojaa.

"C:n ja C :n suorastaan kiduttavan kryptinen syntaksi on tahallaan suunniteltu vaikeaksi ymmärtää."

Tosiasiassa C:n ja C :n syntaksi osoittautui menestyksekkääksi koska se oli selkeä, nopeata kirjoittaa ja helppo lukea. C ja C jyräsi Pascalin. Eikä ainoastaan sitä vaan myös Ada:n jonka syntaksi on Pascalin kaltainen. On vaan paljon parempi kieli kuin mikään Pascal. C:n ja C :n syntaksia sitten apinoi Java, C#, PHP, Javascript, Typescript jne.

Tuntuu siltä, että vasta nämä Ruby, CoffeeScript, Python jne. tuovat jotain etua syntaksiin selkeyden osalta.

"Mutta ohjelmointimaailmassa, kuka haluaa maksaa ylimääräistä siitä, että laaditaan tarpeettomia standardeja, ja dokumentointi siirtyy maksumuurin taakse?"

Standardoi sitten vaikka W3C:ssä jos siltä tuntuu. Ja mikään ei muuten estä tekemästä toteutusta ensin, dokumentoi sen ja sitten vasta standardoi.

Lue lisää

C osoittaitui menestykseksi siksi että c-kääntäjä oli/on helppo tehdä. Turbo Pascal jyräsi kaikki muut Pascalit. Se oli nopein, siinä oli älykäs kääntäjä, innovatiivinen tuote jne. ylivoimainen tuote aikanaan. Turbo Pascalin heikkous oli se että sillä oli "väärä" valmistaja. Se rajoittui vain PC:n ja Appleen.

Turbo_P kirjoitti:

C osoittaitui menestykseksi siksi että c-kääntäjä oli/on helppo tehdä. Turbo Pascal jyräsi kaikki muut Pascalit. Se oli nopein, siinä oli älykäs kääntäjä, innovatiivinen tuote jne. ylivoimainen tuote aikanaan. Turbo Pascalin heikkous oli se että sillä oli "väärä" valmistaja. Se rajoittui vain PC:n ja Appleen.

Lue lisää

Muistelehan tarkemmin. Turbo Pascal oli todella edullinen, ja juuri tämän edullisuuden ansiosta Pascal yleensäkin selvisi hengissä.

Oikeat C kääntäjät olivat kalliimpia silloin 80-luvulla

M-Kar kirjoitti:

Muistelehan tarkemmin. Turbo Pascal oli todella edullinen, ja juuri tämän edullisuuden ansiosta Pascal yleensäkin selvisi hengissä.

Oikeat C kääntäjät olivat kalliimpia silloin 80-luvulla

Lue lisää

Applehan käytti Pascalia hyvin pitkän ajan käyttöjärjestelmän pohjassa mm, Macien ( Lisan) käyttöjärjestelmä oli pascalilla kirjoitettu.

M-Kar kirjoitti:

Muistelehan tarkemmin. Turbo Pascal oli todella edullinen, ja juuri tämän edullisuuden ansiosta Pascal yleensäkin selvisi hengissä.

Oikeat C kääntäjät olivat kalliimpia silloin 80-luvulla

Lue lisää

Turbo Pascal oli hurjan nopea verrattuna USCD pascaliin ja Algorin Pascaliin verrattuna (Microsoftin pascal oli myös raskaskäyttöinen). Lisäksi Turbo Pascalissa kääntäminen tapahtui heti. Turbo Pascalin tutustumisen jälkeen kaikki muut kielet olivat hyvin kankeita ja hitaita (muita kieliä (lähinnä c) oli pakko käyttää kun Turbo Pascal tuki vain PC:tä).