Tästä alkuun pascal-opinnoissa

Pikkupoikien puuhastelua. Mutta oppivathan turhan kielen kanssa ehkä ohjelmoimaan, jos intoa riittää.

No juu, Lazarus on kyllä parempi! :) Itse jätin Qt:n ja siirryin pelkästään käyttämään tätä, koska tässsä rakenteesta tulee heti selkeä - ilman valmiiksi ajateltua taustaframeworkkia. Ohjelmissa ei ole pakkoa käyttää joka paikassa olioparadigmaa vaan funktionaalisella pärjää (FOO - Functional - or - Object - Oriented metodologia).
Missä muualla se olisi näin helppoa? Jos tarvitset ikkunan, kirjoitat Unitin. Raahaat ikkunaasi haluamasi painikkeet ja syötteet/tulosteet. Sitten sanot pääohjelmassa, että "Uses OmaIkkuna1" ja kutsut haluamassasi kohdassa rakentajaa. Selkeydessä tämä voittaa jo palkintoja!

Höpsis, tuolla ei tee mitään. Tosiohjelmoijat käyttää Brainfuckia https://en.wikipedia.org/wiki/Brainfuck

suosittelen_lämpimästi kirjoitti:

No juu, Lazarus on kyllä parempi! :) Itse jätin Qt:n ja siirryin pelkästään käyttämään tätä, koska tässsä rakenteesta tulee heti selkeä - ilman valmiiksi ajateltua taustaframeworkkia. Ohjelmissa ei ole pakkoa käyttää joka paikassa olioparadigmaa vaan funktionaalisella pärjää (FOO - Functional - or - Object - Oriented metodologia).
Missä muualla se olisi näin helppoa? Jos tarvitset ikkunan, kirjoitat Unitin. Raahaat ikkunaasi haluamasi painikkeet ja syötteet/tulosteet. Sitten sanot pääohjelmassa, että "Uses OmaIkkuna1" ja kutsut haluamassasi kohdassa rakentajaa. Selkeydessä tämä voittaa jo palkintoja!

Lue lisää

"Itse jätin Qt:n ja siirryin pelkästään käyttämään tätä, koska tässsä rakenteesta tulee heti selkeä - ilman valmiiksi ajateltua taustaframeworkkia."

Qt:n framework on tunnetusti erittäin hyvä.

"Ohjelmissa ei ole pakkoa käyttää joka paikassa olioparadigmaa vaan funktionaalisella pärjää (FOO - Functional - or - Object - Oriented metodologia)."

Toki sitä voi kirjoittaa funktionaalisesti asioita, se on selkeätä.

Lazaruksella vaan on käytettävyydessä isompia ongelmia, kuten se että se Windows versio kääntää Win32 rajapinnoille ja tiettävästi skaalaus kusee.

Onpas kiva kun jo FullHD ruuduilla tarvitsee välillä pientä kälin skaalausta niin entäs sitten kun yleistyy 4K ja 8K näytöt niin Lazaruksella tehdyt ohjelmat näyttää Windowsilla silloin jokseenkin varmasti paskalta.

Qt:llä tuo ongelma on kierrettävissä kun on katkottu sitä napanuoraa Win32 API kutsuihin kauan sitten.

En kyllä ole vielä testannut Lazarus softaa Windows 10 ja 4K ruudulla, että mitä tykkää kun säätää DPI:tä ruudusta ja skaalaa kaikkea isommaksi mutta olen erittäin skeptinen, että se toimisi.

No evvk, jos on vielä kehitettävää. Päivityksiä kuitenkin tulee edelleen aika säännöllisesti - eikä millään 3kk turhakepäivitystahdilla. Qt häviää tämän kisan vielä Lazarukselle sen helpomman tekemistavan vuoksi.
On totta, että Lazarusta kehitetään pienemmän porukan turvin kuin mitä C/C härpättimiä, siitä syystä se vähän lagaa. Tästä seuraa kuitenkin se, ettei tarvitse toteuttaa huonoiksi osottautuneita rakenteita - kokemusta toimintatavasta on jo olemassa jonka arvottamiselle kehitys perustetaan. Kieli on eriytetty toiminnasta siinä mielessä, että sama koodi kääntyy eri ympäristöissä, toteustapa on käyttöjärjestelmäriippuva tietysti - mutta eikös sen käyttöjäjrestelmän kehityksen pitäisi olla myös kuosissa - eli kehitetään se API mikä on rikki kuntoon jos sitä kerran tarvitaan? Kielenä se ei kuitenkaan häviä millään tavalla vertaisilleen.

sanompa_vaan kirjoitti:

No evvk, jos on vielä kehitettävää. Päivityksiä kuitenkin tulee edelleen aika säännöllisesti - eikä millään 3kk turhakepäivitystahdilla. Qt häviää tämän kisan vielä Lazarukselle sen helpomman tekemistavan vuoksi.
On totta, että Lazarusta kehitetään pienemmän porukan turvin kuin mitä C/C härpättimiä, siitä syystä se vähän lagaa. Tästä seuraa kuitenkin se, ettei tarvitse toteuttaa huonoiksi osottautuneita rakenteita - kokemusta toimintatavasta on jo olemassa jonka arvottamiselle kehitys perustetaan. Kieli on eriytetty toiminnasta siinä mielessä, että sama koodi kääntyy eri ympäristöissä, toteustapa on käyttöjärjestelmäriippuva tietysti - mutta eikös sen käyttöjäjrestelmän kehityksen pitäisi olla myös kuosissa - eli kehitetään se API mikä on rikki kuntoon jos sitä kerran tarvitaan? Kielenä se ei kuitenkaan häviä millään tavalla vertaisilleen.

Lue lisää

"No evvk, jos on vielä kehitettävää."

Nykyisellä tahdilla näyttää todella heikolta se sopivuus Windowsilla toimivien sovelluksen tekemiseen kun kääntäjä siellä Lazaruksen pellin alla ei tajua mitään CIL koodille kääntämisestä ja GUI koodi on riippuvaista Win32:sta. Qt:ssä ovat onnistuneet erottamaan riippuvuuden kääntäjästäkin.

Lazarus on noin 7v jäljessä kehitystä, ja 7v sitten ei ollut edes versio 1.0 valmis.

"Tästä seuraa kuitenkin se, ettei tarvitse toteuttaa huonoiksi osottautuneita rakenteita - kokemusta toimintatavasta on jo olemassa jonka arvottamiselle kehitys perustetaan."

No ei.

Aluksi Microsoft teki sen WinAPI:n. Tämän juuret ovat 80-luvulla.

Borland teki tämän päälle wrapperin, VCL:n millä sai tehtyä oliopohjaisesti käyttöliittymäkoodia ja se tulkitsi ne melko suoraan WinAPI:lle (ja myöhemmin Win32 API:lle).

Lazaruksen rakenteet on olennaisesti LCL, mikä on tehty reverse engineeringillä siitä VCL:stä. Siksi Delphillä tehdyt ohjelmat siirtyvät hyvin vähäisin muutoksin.

Lazarukseen tehty pari olennaista muutosta:

1. Kääntäjänä on Freepascal, mikä on frontend GCC:lle. GCC:n mahtiominaisuus on se, että se toimii joka prosessoriarkkitehtuurilla ja tuo GCC on koko Lazaruksen selkäranka.

2. Koska saatiin GCC:n ansiosta koodi siirtymään, tehtiin LCL:n merkittävä parannus. Nimittäin tämän arkkitehtuuriin tehtiin rajapinta jossa se koodi on siirrettävissä eri widget toolkiteille. Tämä tekee sen, että Pascal/LCL koodi sitten kääntyy GTK , Qt, Cocoa, Win32 jne. ja eri ympäristöissä GCC:n ansiosta.

Eli siis Lazaruksen rakenteissa, siinä LCL frameworkissa EI OLE sovelluskehityksen kannalta mitään olennaisen hienoa, koska sen juuret on johdettavissa vanhasta Win32 API:sta ja VCL:stä. Ja toisekseen tuo riippuvuus GCC:n ei ole hyvä juttu kun Windows kehityksessä siirrytään Win32 API:sta WinRT:lle. GCC ei tajua WinRT:stä mitään eikä Freepascal.

Qt:llä on merkittävä etumatka, sillä tämän juuret eivät ole Win32 API:ssa. Tässä tarkoituksena oli tehdä aivan itsenäinen C framework GUI ohjelmointiin ja tämän rakennetta on uudistettu monesti. Tarkoituksena on ollut optimoida sitä ohjelmistokehittäjän tuottavuutta ja ohjelmoinnin helppoutta. Qt:ssä myös tehtiin widget wrapperien sijasta ratkaisu, että Qt itsessään toteuttaa sen tekniikan nappien yms. piirtämiseen ja siellä sitten on mallinnettuna alustan natiivit teemat. Eli siellä on riippuvuudet olleet matalan tason juttuihin vähäisiä.

Qt reagoi myös hyvissä ajoin riippuvuuteen mikä oli kääntäjässä joten se on tyyliin aina kääntänyt eri kääntäjille ja jo vuonna 2010 oli jo QML tähän, että riippuvuudet oli katkaistu.

Qt:ssä on siis ollut ikuisuuden tekniikka jolla voidaan tehdä softaa mikä on riippumaton käyttöjärjestelmästä, kääntäjästä, arkkitehtuurista, resoluutiosta ja jne. Jonkinlainen minimaalinen runtime tarvitaan vähintään mikä on QML:ää käyttäen mahdollista saada ihan natiivisti.

Se C on siellä enää sitä varten, että tarvitsee jotain suorituskykyriippuvaista komponenttia. Tuossa tulee Lazaruksen tapaan arkkitehtuuririippuvaisuus mutta pitäisi onnistua myös WinRT/CXX jos ei nyt niin kohta, Visual Studiolla kääntäen.

"Kieli on eriytetty toiminnasta siinä mielessä, että sama koodi kääntyy eri ympäristöissä, toteustapa on käyttöjärjestelmäriippuva tietysti - mutta eikös sen käyttöjäjrestelmän kehityksen pitäisi olla myös kuosissa - eli kehitetään se API mikä on rikki kuntoon jos sitä kerran tarvitaan?"

Kuten kerroin niin asia on monimutkaisempi. Siksi Qt:ssäkin on C :n ohella QML.

"Kielenä se ei kuitenkaan häviä millään tavalla vertaisilleen."

Pascal on alunperin tehty opetuskäyttöön. Se olisi jo kuollut 80-luvulla ellei Borland olisi tehnyt Turbo Pascalia. Ja Turbo Pascalin etu oli se, että saivat tehty käännöksen 1-pass:na joten se oli nopea, ja se oli vielä halpa. Tuon menestys on sitä pitänyt hengissä.

Mutta se LCL on edelleenkin 80-luvun WinAPI -> VCL wrapperista johdettu. En kiellä, etteikö se VCL olisi silloin 90-luvulla ollut hyvä mutta Qt on tosiaankin alunperin tehty riippumattomaksi 80-luvun jutuista ensimmäisestä versiosta lähtien signals/slots, ja sen jälkeen tullut neljä sukupolvea uudistusta joten Qt:llä tarvitsee paljon vähemmän nysvätä koodia ja saa siistimmin tehtyä.

...

Niin itsehän en sitten mitenkään erityisesti sitä Qt:tä suosi, se nyt oli tässä vertailukohteena kun mainittu, että Qt:stä vaihdettu Lazarukseen.

Itsehän suosin nykyään Typescript/React yhdistelmää:

http://www.typescriptlang.org/
https://facebook.github.io/react/
https://code.visualstudio.com/

M-Kar kirjoitti:

"Itse jätin Qt:n ja siirryin pelkästään käyttämään tätä, koska tässsä rakenteesta tulee heti selkeä - ilman valmiiksi ajateltua taustaframeworkkia."

Qt:n framework on tunnetusti erittäin hyvä.

"Ohjelmissa ei ole pakkoa käyttää joka paikassa olioparadigmaa vaan funktionaalisella pärjää (FOO - Functional - or - Object - Oriented metodologia)."

Toki sitä voi kirjoittaa funktionaalisesti asioita, se on selkeätä.

Lazaruksella vaan on käytettävyydessä isompia ongelmia, kuten se että se Windows versio kääntää Win32 rajapinnoille ja tiettävästi skaalaus kusee.

Onpas kiva kun jo FullHD ruuduilla tarvitsee välillä pientä kälin skaalausta niin entäs sitten kun yleistyy 4K ja 8K näytöt niin Lazaruksella tehdyt ohjelmat näyttää Windowsilla silloin jokseenkin varmasti paskalta.

Qt:llä tuo ongelma on kierrettävissä kun on katkottu sitä napanuoraa Win32 API kutsuihin kauan sitten.

En kyllä ole vielä testannut Lazarus softaa Windows 10 ja 4K ruudulla, että mitä tykkää kun säätää DPI:tä ruudusta ja skaalaa kaikkea isommaksi mutta olen erittäin skeptinen, että se toimisi.

Lue lisää

Itse Lazaruksen (se IDE) käyttöliittymä on käyttökelvoton 4K-näytöllä, olen testannut sekä Mintillä että Windows 10:llä. Työkalurivin painikkeet on tosi pieniä 32x32px tuhnuja, osa käyttöliittymästä osaa skaalata elementit ja osa taas ei. Sääli sikäli että itse tykkäisin Lazaruksesta, mutta en voi Lazarusta käyttää ennen kuin tämä HiDPI on kunnossa.

Täällä jotain keskustelua tuosta ongelmasta:

http://comments.gmane.org/gmane.comp.ide.lazarus.general/83133

ex-delphisti kirjoitti:

Itse Lazaruksen (se IDE) käyttöliittymä on käyttökelvoton 4K-näytöllä, olen testannut sekä Mintillä että Windows 10:llä. Työkalurivin painikkeet on tosi pieniä 32x32px tuhnuja, osa käyttöliittymästä osaa skaalata elementit ja osa taas ei. Sääli sikäli että itse tykkäisin Lazaruksesta, mutta en voi Lazarusta käyttää ennen kuin tämä HiDPI on kunnossa.

Täällä jotain keskustelua tuosta ongelmasta:

http://comments.gmane.org/gmane.comp.ide.lazarus.general/83133

Lue lisää

Tuo kuullostaa pahalta jos vika on myös Mintillä, koska se käyttää GTK :aa jossa niitä skaalausongelmia ei ole.

Se viittaa siihen, että vika on saatu perittyä muinaisesta WinAPI->VCL->LCL kehityksessä siihen API:n myös, joten tuon korjaaminen voi sitten paskoa rikki kaiken GUI koodin mitä on tehty, ja Windowsissa ongelman korjaaminen vaatisi sitä, että tehdään uusi kääntäjä mikä kääntää CIL koodia.

Tää vaikuttaa lähes mission imbossiblelta kun laahaavat nytkin vielä jossain vuodessa 2008 tms.

Siis ihan oikeasti, se Lazarus ei oikeasti ole tarkoitettu uusille projekteille vaan siihen, että tekohengitetään vanhaa Delphikoodia. Sillä Lazaruksella saa sen softan käännettyä uusiksi sitten ja jollain tavalla ylläpidettyä vaikka paskannäköisenä nykyvehkeissä.

Uusia projekteja varten on sopivammat työkalut keksitty, kuten vaikka tuo mainitsemani Typescript/React.

M-Kar kirjoitti:

"No evvk, jos on vielä kehitettävää."

Nykyisellä tahdilla näyttää todella heikolta se sopivuus Windowsilla toimivien sovelluksen tekemiseen kun kääntäjä siellä Lazaruksen pellin alla ei tajua mitään CIL koodille kääntämisestä ja GUI koodi on riippuvaista Win32:sta. Qt:ssä ovat onnistuneet erottamaan riippuvuuden kääntäjästäkin.

Lazarus on noin 7v jäljessä kehitystä, ja 7v sitten ei ollut edes versio 1.0 valmis.

"Tästä seuraa kuitenkin se, ettei tarvitse toteuttaa huonoiksi osottautuneita rakenteita - kokemusta toimintatavasta on jo olemassa jonka arvottamiselle kehitys perustetaan."

No ei.

Aluksi Microsoft teki sen WinAPI:n. Tämän juuret ovat 80-luvulla.

Borland teki tämän päälle wrapperin, VCL:n millä sai tehtyä oliopohjaisesti käyttöliittymäkoodia ja se tulkitsi ne melko suoraan WinAPI:lle (ja myöhemmin Win32 API:lle).

Lazaruksen rakenteet on olennaisesti LCL, mikä on tehty reverse engineeringillä siitä VCL:stä. Siksi Delphillä tehdyt ohjelmat siirtyvät hyvin vähäisin muutoksin.

Lazarukseen tehty pari olennaista muutosta:

1. Kääntäjänä on Freepascal, mikä on frontend GCC:lle. GCC:n mahtiominaisuus on se, että se toimii joka prosessoriarkkitehtuurilla ja tuo GCC on koko Lazaruksen selkäranka.

2. Koska saatiin GCC:n ansiosta koodi siirtymään, tehtiin LCL:n merkittävä parannus. Nimittäin tämän arkkitehtuuriin tehtiin rajapinta jossa se koodi on siirrettävissä eri widget toolkiteille. Tämä tekee sen, että Pascal/LCL koodi sitten kääntyy GTK , Qt, Cocoa, Win32 jne. ja eri ympäristöissä GCC:n ansiosta.

Eli siis Lazaruksen rakenteissa, siinä LCL frameworkissa EI OLE sovelluskehityksen kannalta mitään olennaisen hienoa, koska sen juuret on johdettavissa vanhasta Win32 API:sta ja VCL:stä. Ja toisekseen tuo riippuvuus GCC:n ei ole hyvä juttu kun Windows kehityksessä siirrytään Win32 API:sta WinRT:lle. GCC ei tajua WinRT:stä mitään eikä Freepascal.

Qt:llä on merkittävä etumatka, sillä tämän juuret eivät ole Win32 API:ssa. Tässä tarkoituksena oli tehdä aivan itsenäinen C framework GUI ohjelmointiin ja tämän rakennetta on uudistettu monesti. Tarkoituksena on ollut optimoida sitä ohjelmistokehittäjän tuottavuutta ja ohjelmoinnin helppoutta. Qt:ssä myös tehtiin widget wrapperien sijasta ratkaisu, että Qt itsessään toteuttaa sen tekniikan nappien yms. piirtämiseen ja siellä sitten on mallinnettuna alustan natiivit teemat. Eli siellä on riippuvuudet olleet matalan tason juttuihin vähäisiä.

Qt reagoi myös hyvissä ajoin riippuvuuteen mikä oli kääntäjässä joten se on tyyliin aina kääntänyt eri kääntäjille ja jo vuonna 2010 oli jo QML tähän, että riippuvuudet oli katkaistu.

Qt:ssä on siis ollut ikuisuuden tekniikka jolla voidaan tehdä softaa mikä on riippumaton käyttöjärjestelmästä, kääntäjästä, arkkitehtuurista, resoluutiosta ja jne. Jonkinlainen minimaalinen runtime tarvitaan vähintään mikä on QML:ää käyttäen mahdollista saada ihan natiivisti.

Se C on siellä enää sitä varten, että tarvitsee jotain suorituskykyriippuvaista komponenttia. Tuossa tulee Lazaruksen tapaan arkkitehtuuririippuvaisuus mutta pitäisi onnistua myös WinRT/CXX jos ei nyt niin kohta, Visual Studiolla kääntäen.

"Kieli on eriytetty toiminnasta siinä mielessä, että sama koodi kääntyy eri ympäristöissä, toteustapa on käyttöjärjestelmäriippuva tietysti - mutta eikös sen käyttöjäjrestelmän kehityksen pitäisi olla myös kuosissa - eli kehitetään se API mikä on rikki kuntoon jos sitä kerran tarvitaan?"

Kuten kerroin niin asia on monimutkaisempi. Siksi Qt:ssäkin on C :n ohella QML.

"Kielenä se ei kuitenkaan häviä millään tavalla vertaisilleen."

Pascal on alunperin tehty opetuskäyttöön. Se olisi jo kuollut 80-luvulla ellei Borland olisi tehnyt Turbo Pascalia. Ja Turbo Pascalin etu oli se, että saivat tehty käännöksen 1-pass:na joten se oli nopea, ja se oli vielä halpa. Tuon menestys on sitä pitänyt hengissä.

Mutta se LCL on edelleenkin 80-luvun WinAPI -> VCL wrapperista johdettu. En kiellä, etteikö se VCL olisi silloin 90-luvulla ollut hyvä mutta Qt on tosiaankin alunperin tehty riippumattomaksi 80-luvun jutuista ensimmäisestä versiosta lähtien signals/slots, ja sen jälkeen tullut neljä sukupolvea uudistusta joten Qt:llä tarvitsee paljon vähemmän nysvätä koodia ja saa siistimmin tehtyä.

...

Niin itsehän en sitten mitenkään erityisesti sitä Qt:tä suosi, se nyt oli tässä vertailukohteena kun mainittu, että Qt:stä vaihdettu Lazarukseen.

Itsehän suosin nykyään Typescript/React yhdistelmää:

http://www.typescriptlang.org/
https://facebook.github.io/react/
https://code.visualstudio.com/

Lue lisää

Freepascal Ei ole frontend GCC:lle vaan FreePascal tukee/pystyy käyttämään GCC ympäristöä hyväkseen eli sille on tuki ja näin ollen se saa sen ominaisuudet (tarvittaessa) käyttöön. Mutta esim. windows versiossa on GCC:n "heikkouksien" vuoksi oma tausta. Eli GCC:n rajoitukset eivät ole Free Pascalin rajoituksia.

jotain-selvitystä kirjoitti:

Freepascal Ei ole frontend GCC:lle vaan FreePascal tukee/pystyy käyttämään GCC ympäristöä hyväkseen eli sille on tuki ja näin ollen se saa sen ominaisuudet (tarvittaessa) käyttöön. Mutta esim. windows versiossa on GCC:n "heikkouksien" vuoksi oma tausta. Eli GCC:n rajoitukset eivät ole Free Pascalin rajoituksia.

Lue lisää

No FreePascalilla ei saa käännettyä WinRT:lle joten vähän paskassa jamassa se tällä hetkellä.

jotain-selvitystä kirjoitti:

Freepascal Ei ole frontend GCC:lle vaan FreePascal tukee/pystyy käyttämään GCC ympäristöä hyväkseen eli sille on tuki ja näin ollen se saa sen ominaisuudet (tarvittaessa) käyttöön. Mutta esim. windows versiossa on GCC:n "heikkouksien" vuoksi oma tausta. Eli GCC:n rajoitukset eivät ole Free Pascalin rajoituksia.

Lue lisää

Ymmärrät ehkäpä asian parhaiten niin että GCC-tuki lisättiin jälkeenpäin (saatiin nopeammin enemmän "alustoja" !

M-Kar kirjoitti:

Tuo kuullostaa pahalta jos vika on myös Mintillä, koska se käyttää GTK :aa jossa niitä skaalausongelmia ei ole.

Se viittaa siihen, että vika on saatu perittyä muinaisesta WinAPI->VCL->LCL kehityksessä siihen API:n myös, joten tuon korjaaminen voi sitten paskoa rikki kaiken GUI koodin mitä on tehty, ja Windowsissa ongelman korjaaminen vaatisi sitä, että tehdään uusi kääntäjä mikä kääntää CIL koodia.

Tää vaikuttaa lähes mission imbossiblelta kun laahaavat nytkin vielä jossain vuodessa 2008 tms.

Siis ihan oikeasti, se Lazarus ei oikeasti ole tarkoitettu uusille projekteille vaan siihen, että tekohengitetään vanhaa Delphikoodia. Sillä Lazaruksella saa sen softan käännettyä uusiksi sitten ja jollain tavalla ylläpidettyä vaikka paskannäköisenä nykyvehkeissä.

Uusia projekteja varten on sopivammat työkalut keksitty, kuten vaikka tuo mainitsemani Typescript/React.

Lue lisää

Typescript/React taitaa vaatia ajoympäristön (selaimen, mielestäni aikamoinen heikkous). Useimmat muut kielet vaativat tietyn käyttöjärjestelmän. Tiedät että FreePascal toimii monissa käyttöjärjestelmissä mutta monista muista kielistä poiketen FreePascal ei tarvitse edes käyttöjärjestelmää!

jotain-selvitystä kirjoitti:

Ymmärrät ehkäpä asian parhaiten niin että GCC-tuki lisättiin jälkeenpäin (saatiin nopeammin enemmän "alustoja" !

No se ei muuta kuitenkaan sitä oleellista juttua, että tuossa on aika merkittäviä rakenteellisia ongelmia havaittavissa joihin todennäköisesti ei löydy helppoa ratkaisua.

Tosiasiassa ei ole oikeasti mitään järkisyytä miksi kannattaisi ottaa Lazarus vaikka sen Qt:n sijasta, jos vaikka React ei käy.

jotain-selvitystä kirjoitti:

Typescript/React taitaa vaatia ajoympäristön (selaimen, mielestäni aikamoinen heikkous). Useimmat muut kielet vaativat tietyn käyttöjärjestelmän. Tiedät että FreePascal toimii monissa käyttöjärjestelmissä mutta monista muista kielistä poiketen FreePascal ei tarvitse edes käyttöjärjestelmää!

Lue lisää

"Typescript/React taitaa vaatia ajoympäristön (selaimen, mielestäni aikamoinen heikkous)."

Päinvastoin, se on vahvuus. Sama ohjelma toimii sellaisenaan joka vekottimessa ilman asentamisia. Lazaruksella kaikenlaista typerää kääntämistä eri käyttöjärjestelmille, laitearkkitehtuureille, ja sitten on rakenteelliset ongelmat mitkä rajoittaa 4K/8K ja jopa FullHD käyttöä, asentamiset jne.

Qt päässyt sentäs siihen, että muut asiat on kunnossa paitsi kääntämiset ja laitearkkitehtuuririippuvuudet jotka rajoittuu mahdollisiin C komponentteihin. Runtimesta ne on ehkä jo pois tai on ainakin poistettavissa.

M-Kar kirjoitti:

"Typescript/React taitaa vaatia ajoympäristön (selaimen, mielestäni aikamoinen heikkous)."

Päinvastoin, se on vahvuus. Sama ohjelma toimii sellaisenaan joka vekottimessa ilman asentamisia. Lazaruksella kaikenlaista typerää kääntämistä eri käyttöjärjestelmille, laitearkkitehtuureille, ja sitten on rakenteelliset ongelmat mitkä rajoittaa 4K/8K ja jopa FullHD käyttöä, asentamiset jne.

Qt päässyt sentäs siihen, että muut asiat on kunnossa paitsi kääntämiset ja laitearkkitehtuuririippuvuudet jotka rajoittuu mahdollisiin C komponentteihin. Runtimesta ne on ehkä jo pois tai on ainakin poistettavissa.

Lue lisää

Kuluttaja sovelluksissa voidaan tuo selainpohjaisuus hyväksyä (pakotetaan kuluttaja hyväksymään) mutta esim. teollisuudessa ei (ei ainakaan kaikissa tapauksissa!)

ei_teollisuudessa kirjoitti:

Kuluttaja sovelluksissa voidaan tuo selainpohjaisuus hyväksyä (pakotetaan kuluttaja hyväksymään) mutta esim. teollisuudessa ei (ei ainakaan kaikissa tapauksissa!)

Tuota noin, mikä estää selainpohjaisuuden?

Ihan esimerkkejä ja miksi. Kiinnostaa.

M-Kar kirjoitti:

Tuota noin, mikä estää selainpohjaisuuden?

Ihan esimerkkejä ja miksi. Kiinnostaa.

Estetään se ettei kyseisellä koneella mennä missään olosuhteissa nettiin. Teollisuudessa voi nähdä tosi vanhoja koneita. Ne ovat yhteydessä laitteisiin joita käytetään 20 vuotta.

PC on halpa mutta jatkuva päivittäminen on todella kallista ja se saattaa rikkoa koko prosessin.

Tiedän että tuotantokäytössä on vielä esim. win3.1 pohjaisia pc:tä. Kun niissä ei käytetä selainta eikä niitä ole päivitetty niin ne toimivat hyvin (paljon paremmin kuin toimistolla olevat nyky- PC:t) ja täyttävät tehtävänsä.

Eli kun ostetaan uusi laite niin se jätetään sen hetkiseen tilaan ja estetään nettiselailu.

ei_teollisuudessa kirjoitti:

Estetään se ettei kyseisellä koneella mennä missään olosuhteissa nettiin. Teollisuudessa voi nähdä tosi vanhoja koneita. Ne ovat yhteydessä laitteisiin joita käytetään 20 vuotta.

PC on halpa mutta jatkuva päivittäminen on todella kallista ja se saattaa rikkoa koko prosessin.

Tiedän että tuotantokäytössä on vielä esim. win3.1 pohjaisia pc:tä. Kun niissä ei käytetä selainta eikä niitä ole päivitetty niin ne toimivat hyvin (paljon paremmin kuin toimistolla olevat nyky- PC:t) ja täyttävät tehtävänsä.

Eli kun ostetaan uusi laite niin se jätetään sen hetkiseen tilaan ja estetään nettiselailu.

Lue lisää

"Estetään se ettei kyseisellä koneella mennä missään olosuhteissa nettiin."

Ei tarvitse. Kyllä selainsofta toimii ihan hyvin sisäverkossa.

Kätevintähän se olisi se joku kone mikä lukee antureista yms. tiedot ja sitten softaa käytetään kun avaa tämän koneen osoitteen selaimella.

M-Kar kirjoitti:

Tuo kuullostaa pahalta jos vika on myös Mintillä, koska se käyttää GTK :aa jossa niitä skaalausongelmia ei ole.

Se viittaa siihen, että vika on saatu perittyä muinaisesta WinAPI->VCL->LCL kehityksessä siihen API:n myös, joten tuon korjaaminen voi sitten paskoa rikki kaiken GUI koodin mitä on tehty, ja Windowsissa ongelman korjaaminen vaatisi sitä, että tehdään uusi kääntäjä mikä kääntää CIL koodia.

Tää vaikuttaa lähes mission imbossiblelta kun laahaavat nytkin vielä jossain vuodessa 2008 tms.

Siis ihan oikeasti, se Lazarus ei oikeasti ole tarkoitettu uusille projekteille vaan siihen, että tekohengitetään vanhaa Delphikoodia. Sillä Lazaruksella saa sen softan käännettyä uusiksi sitten ja jollain tavalla ylläpidettyä vaikka paskannäköisenä nykyvehkeissä.

Uusia projekteja varten on sopivammat työkalut keksitty, kuten vaikka tuo mainitsemani Typescript/React.

Lue lisää

Lazarus käyttää vanhempaa GTK2:sta, jos käyttäisi uudempaa 3 versiota, siinä tuota skaalausongelmaa ei ole. Ihmettelen miksi Lazarus käyttää pixeleitä yksikköinä, jos laitan painikkeen leveydeksi width := 64, tuo on tietääkseni 64 pikseliä? Eikö tuo voisi olla jokin "virtuaalinen pikseli", joka HiDPI-asetuksen ollessa päällä kerrotaan kahdella? Linux Mintissä (Cinnamon) HiDPI-asetus kertoo kaiken kahdella, eli mittasuhteilaan täysin sama kuin 1080p näyttö, mutta kaikki on vain tarkempaa.

Windowsissa on jokin HiDPI aware käytössä, eli Windows osaa sisäisesti skalata sen käyttöliittymän grafiikan isommaksi, mutta tökerösti kaikki näyttää vähän sumeelta (kuin matalampi resoluutio näytössä päällä, mutta vain ikkunassa), Windowsissa on omiakin sovelluksia jotka näyttää 4K-näytällä vähän sameilta.

ex-delphisti kirjoitti:

Lazarus käyttää vanhempaa GTK2:sta, jos käyttäisi uudempaa 3 versiota, siinä tuota skaalausongelmaa ei ole. Ihmettelen miksi Lazarus käyttää pixeleitä yksikköinä, jos laitan painikkeen leveydeksi width := 64, tuo on tietääkseni 64 pikseliä? Eikö tuo voisi olla jokin "virtuaalinen pikseli", joka HiDPI-asetuksen ollessa päällä kerrotaan kahdella? Linux Mintissä (Cinnamon) HiDPI-asetus kertoo kaiken kahdella, eli mittasuhteilaan täysin sama kuin 1080p näyttö, mutta kaikki on vain tarkempaa.

Windowsissa on jokin HiDPI aware käytössä, eli Windows osaa sisäisesti skalata sen käyttöliittymän grafiikan isommaksi, mutta tökerösti kaikki näyttää vähän sumeelta (kuin matalampi resoluutio näytössä päällä, mutta vain ikkunassa), Windowsissa on omiakin sovelluksia jotka näyttää 4K-näytällä vähän sameilta.

Lue lisää

En tiedä mistä se GTK 2:n skaalausongelma johtuu, mutta noin periaatteessa GTK ymmärtää sen skaalauksen valtavasti paremmin kuin se ikivanha Win32.

M-Kar kirjoitti:

"Estetään se ettei kyseisellä koneella mennä missään olosuhteissa nettiin."

Ei tarvitse. Kyllä selainsofta toimii ihan hyvin sisäverkossa.

Kätevintähän se olisi se joku kone mikä lukee antureista yms. tiedot ja sitten softaa käytetään kun avaa tämän koneen osoitteen selaimella.

Lue lisää

koneista voidaan ottaa http-portti pois.

En nyt ole aivan varma, mutta eikös tuo usean alustan tuki käytännössä tarkoita, että graphics-unit kavereineen on portattu tietylle alustalle? Mikäs estää backporttaamasta sitä vaikka qt:lle? Sen jälkeen käytössä on mielenkiintoinen ympäristö, jossa voi koodata qt:ta Pascal:lla. Miten ois? Lähdetäänkös porttaamaan?

ei_mahdotonta kirjoitti:

En nyt ole aivan varma, mutta eikös tuo usean alustan tuki käytännössä tarkoita, että graphics-unit kavereineen on portattu tietylle alustalle? Mikäs estää backporttaamasta sitä vaikka qt:lle? Sen jälkeen käytössä on mielenkiintoinen ympäristö, jossa voi koodata qt:ta Pascal:lla. Miten ois? Lähdetäänkös porttaamaan?

Lue lisää

Voit jo nyt (jo useita vuosia) kääntää Lazaruksen käyttämään esim. QT:ta. Itse sovelluksen kirjoittaminen ei muutu.
Katso jotain mahdollisuuksia
http://wiki.lazarus.freepascal.org/Screenshots

jaaaskaa kirjoitti:

koneista voidaan ottaa http-portti pois.

Mitäs järkeä siinä?

ei_mahdotonta kirjoitti:

En nyt ole aivan varma, mutta eikös tuo usean alustan tuki käytännössä tarkoita, että graphics-unit kavereineen on portattu tietylle alustalle? Mikäs estää backporttaamasta sitä vaikka qt:lle? Sen jälkeen käytössä on mielenkiintoinen ympäristö, jossa voi koodata qt:ta Pascal:lla. Miten ois? Lähdetäänkös porttaamaan?

Lue lisää

Niin... mutta se ei oikein riitä kun pitäisi saada sitä Pascalia saada käännettyä myös CIL:lle ja vaihtaa API Qt:ksi tai tehdä wrapperi LCL->Qt.

Katsos kun Qt:ssä on se juttu, että siinä käli ja suuri osa koodista voidaan pitää QML:nä joka tulkataan, ja jos on suorituskykykriittistä niin voi sen komponentintehdä C :lla joka käännetään suoraan prosessorin arkkitehtuurille.

Windowsissa tuo onnistuu myös WinRT:llä kun siinä oli se C /CX , eli pitäisi aika pienellä vaivalla onnistua kääntämään C koodi siihen myös. Pascalilla tarvitsisi sitten CIL kääntäjää käytännössä.

a--a--a kirjoitti:

Voit jo nyt (jo useita vuosia) kääntää Lazaruksen käyttämään esim. QT:ta. Itse sovelluksen kirjoittaminen ei muutu.
Katso jotain mahdollisuuksia
http://wiki.lazarus.freepascal.org/Screenshots

Lue lisää

No se nyt ei kuitenkaan tee sitä mitä tarvitsisi.

Palataan asiaan sitten kun se toimii puhtaasti WinRT:n päällä ja vielä parempi jos saa toimimaan niin, että runtime ja ajettava oma koodi pyörii puhtaasti laitearkkitehtuurista riippumatta.

Ja sitten tulee mieleen se juttu, että mitä järkeä siinä Lazaruksen LCL:ssä sitten olisi kun voisi suoraan kirjoittaa Qt:lle?

Tuskin microsoft lopettaa win32 rajapintaa. Se on niitä harvoja tämän päivän windowsin vahvuuksia. Windowsia kannattelee nimenomaan erikoisohjelmat joita on vain ylläpidetty. Monet uudet ohjelmat on suunniteltu niin että ne ovat "helposti" siirrettävissä muille alustoille.

win32 kirjoitti:

Tuskin microsoft lopettaa win32 rajapintaa. Se on niitä harvoja tämän päivän windowsin vahvuuksia. Windowsia kannattelee nimenomaan erikoisohjelmat joita on vain ylläpidetty. Monet uudet ohjelmat on suunniteltu niin että ne ovat "helposti" siirrettävissä muille alustoille.

Lue lisää

"Tuskin microsoft lopettaa win32 rajapintaa."

Siis sitähän se parhaillaan tekee, on alasajossa. Windows 8 RT tavallaan näytti suuntaa mihin sitä Windowsia viedään ja koko Windows 8:n taulutietokonekäyttöliittymän ajatus oli vauhdittaa uutta rajapintaa.

Nyt se homma sitten viimeisteltiin Windows 10:ssä ja tämä kun on jatkuvasti päivittyvä palvelu niin pudottelevat niitä vanhoja juttuja vähitellen.

Tässä lista deprekoiduista jutuista: https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.85).aspx#deprecated_or_legacy_apis

Tuon lisäksi siitä Win23 API:sta muutettiin jo Windows 8 vai 8.1:ssä jotain GetVersionEx yms. kutsuja, että ne eivät palauta oikein arvoja. ActiveX on myös deprekoitu.

Tosiasiasiassa se Win32 API meni jo 90-luvun alkupuolella ns. matalan tason API:ksi, että sitä ei suoraan käytetty vaan sovellukset tehtiin Visual Basicilla, Visual C MFC:llä, Delphillä, Javalla jne. ja Win32 API on oli niiden alla ja tarjosi ne matalantason kutsut.

Nyt näkyy olevan Windows 10:llä se meininki, että ensisijaiset sovellusrajapinnat ovat HTML5 ja WinRT, ja lisäksi on taaksepäinyhteensopivuussyistä .NET:ä, Silverlightia, MFC:tä, eli siellä niitä Visual C runtime versioita. Ne pitää jokaista Visual C runtime versiota luvatusti ainakin 10v yhteensopivana ja on muitakin komponentteja mitkä tuota käyttää mutta sitten kun korkeamman tason rajapinnoissa ei ole enää mitään missä olisi riippuvuutta johonkin Win32 API kutsuun, voidaan niitä sieltä rapsia vähitellen pois.

Eli näillä näkymin Win32 API kutsuja löytyy vielä n. 10v kuluttua tai ainakin Win64 API, jos vaikka 32-bit versiot on pudotettu pois, kun n. 10v kuluttua pitäisi olla Visual C 2015 runtimen tuki loppumassa.

Nähdäkseni se Win32 API kutistuu vähitellen ja sitten kun tekevät Visual C kääntäjän joka ei käännä enää Win32 API:lle, voidaan arvioida, että 10v siitä eteenpäin se on kadonnut.

Microsoftia tuskin kiinnostaa Lazarus, Java tai mikään muukaan, että muiden valmistajien tekniikat saavat sitten itse hoitaa ongelmansa. Qt:ssä tämä juttu kiva, ovat reagoineet asiaan niin varhain. QML:ää saa ajettua pienellä runtimella ja C ja C /CX melkein samaa jos tarvitsee jotain suorituskykykriittistä tehdä.

M-Kar kirjoitti:

"Tuskin microsoft lopettaa win32 rajapintaa."

Siis sitähän se parhaillaan tekee, on alasajossa. Windows 8 RT tavallaan näytti suuntaa mihin sitä Windowsia viedään ja koko Windows 8:n taulutietokonekäyttöliittymän ajatus oli vauhdittaa uutta rajapintaa.

Nyt se homma sitten viimeisteltiin Windows 10:ssä ja tämä kun on jatkuvasti päivittyvä palvelu niin pudottelevat niitä vanhoja juttuja vähitellen.

Tässä lista deprekoiduista jutuista: https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.85).aspx#deprecated_or_legacy_apis

Tuon lisäksi siitä Win23 API:sta muutettiin jo Windows 8 vai 8.1:ssä jotain GetVersionEx yms. kutsuja, että ne eivät palauta oikein arvoja. ActiveX on myös deprekoitu.

Tosiasiasiassa se Win32 API meni jo 90-luvun alkupuolella ns. matalan tason API:ksi, että sitä ei suoraan käytetty vaan sovellukset tehtiin Visual Basicilla, Visual C MFC:llä, Delphillä, Javalla jne. ja Win32 API on oli niiden alla ja tarjosi ne matalantason kutsut.

Nyt näkyy olevan Windows 10:llä se meininki, että ensisijaiset sovellusrajapinnat ovat HTML5 ja WinRT, ja lisäksi on taaksepäinyhteensopivuussyistä .NET:ä, Silverlightia, MFC:tä, eli siellä niitä Visual C runtime versioita. Ne pitää jokaista Visual C runtime versiota luvatusti ainakin 10v yhteensopivana ja on muitakin komponentteja mitkä tuota käyttää mutta sitten kun korkeamman tason rajapinnoissa ei ole enää mitään missä olisi riippuvuutta johonkin Win32 API kutsuun, voidaan niitä sieltä rapsia vähitellen pois.

Eli näillä näkymin Win32 API kutsuja löytyy vielä n. 10v kuluttua tai ainakin Win64 API, jos vaikka 32-bit versiot on pudotettu pois, kun n. 10v kuluttua pitäisi olla Visual C 2015 runtimen tuki loppumassa.

Nähdäkseni se Win32 API kutistuu vähitellen ja sitten kun tekevät Visual C kääntäjän joka ei käännä enää Win32 API:lle, voidaan arvioida, että 10v siitä eteenpäin se on kadonnut.

Microsoftia tuskin kiinnostaa Lazarus, Java tai mikään muukaan, että muiden valmistajien tekniikat saavat sitten itse hoitaa ongelmansa. Qt:ssä tämä juttu kiva, ovat reagoineet asiaan niin varhain. QML:ää saa ajettua pienellä runtimella ja C ja C /CX melkein samaa jos tarvitsee jotain suorituskykykriittistä tehdä.

Lue lisää

"Nähdäkseni se Win32 API kutistuu vähitellen ja sitten kun tekevät Visual C kääntäjän joka ei käännä enää Win32 API:lle, voidaan arvioida, että 10v siitä eteenpäin se on kadonnut."

Korjaan, 10v edellisen Visual C julkaisun jälkeen 10v eteenpäin. Jos uusi release tulee vaikka 3v myöhemmin mikä ei käännä, voi Win32 API:n täydellinen häviäminen olla jo 7v kuluttua.

M-Kar kirjoitti:

"No evvk, jos on vielä kehitettävää."

Nykyisellä tahdilla näyttää todella heikolta se sopivuus Windowsilla toimivien sovelluksen tekemiseen kun kääntäjä siellä Lazaruksen pellin alla ei tajua mitään CIL koodille kääntämisestä ja GUI koodi on riippuvaista Win32:sta. Qt:ssä ovat onnistuneet erottamaan riippuvuuden kääntäjästäkin.

Lazarus on noin 7v jäljessä kehitystä, ja 7v sitten ei ollut edes versio 1.0 valmis.

"Tästä seuraa kuitenkin se, ettei tarvitse toteuttaa huonoiksi osottautuneita rakenteita - kokemusta toimintatavasta on jo olemassa jonka arvottamiselle kehitys perustetaan."

No ei.

Aluksi Microsoft teki sen WinAPI:n. Tämän juuret ovat 80-luvulla.

Borland teki tämän päälle wrapperin, VCL:n millä sai tehtyä oliopohjaisesti käyttöliittymäkoodia ja se tulkitsi ne melko suoraan WinAPI:lle (ja myöhemmin Win32 API:lle).

Lazaruksen rakenteet on olennaisesti LCL, mikä on tehty reverse engineeringillä siitä VCL:stä. Siksi Delphillä tehdyt ohjelmat siirtyvät hyvin vähäisin muutoksin.

Lazarukseen tehty pari olennaista muutosta:

1. Kääntäjänä on Freepascal, mikä on frontend GCC:lle. GCC:n mahtiominaisuus on se, että se toimii joka prosessoriarkkitehtuurilla ja tuo GCC on koko Lazaruksen selkäranka.

2. Koska saatiin GCC:n ansiosta koodi siirtymään, tehtiin LCL:n merkittävä parannus. Nimittäin tämän arkkitehtuuriin tehtiin rajapinta jossa se koodi on siirrettävissä eri widget toolkiteille. Tämä tekee sen, että Pascal/LCL koodi sitten kääntyy GTK , Qt, Cocoa, Win32 jne. ja eri ympäristöissä GCC:n ansiosta.

Eli siis Lazaruksen rakenteissa, siinä LCL frameworkissa EI OLE sovelluskehityksen kannalta mitään olennaisen hienoa, koska sen juuret on johdettavissa vanhasta Win32 API:sta ja VCL:stä. Ja toisekseen tuo riippuvuus GCC:n ei ole hyvä juttu kun Windows kehityksessä siirrytään Win32 API:sta WinRT:lle. GCC ei tajua WinRT:stä mitään eikä Freepascal.

Qt:llä on merkittävä etumatka, sillä tämän juuret eivät ole Win32 API:ssa. Tässä tarkoituksena oli tehdä aivan itsenäinen C framework GUI ohjelmointiin ja tämän rakennetta on uudistettu monesti. Tarkoituksena on ollut optimoida sitä ohjelmistokehittäjän tuottavuutta ja ohjelmoinnin helppoutta. Qt:ssä myös tehtiin widget wrapperien sijasta ratkaisu, että Qt itsessään toteuttaa sen tekniikan nappien yms. piirtämiseen ja siellä sitten on mallinnettuna alustan natiivit teemat. Eli siellä on riippuvuudet olleet matalan tason juttuihin vähäisiä.

Qt reagoi myös hyvissä ajoin riippuvuuteen mikä oli kääntäjässä joten se on tyyliin aina kääntänyt eri kääntäjille ja jo vuonna 2010 oli jo QML tähän, että riippuvuudet oli katkaistu.

Qt:ssä on siis ollut ikuisuuden tekniikka jolla voidaan tehdä softaa mikä on riippumaton käyttöjärjestelmästä, kääntäjästä, arkkitehtuurista, resoluutiosta ja jne. Jonkinlainen minimaalinen runtime tarvitaan vähintään mikä on QML:ää käyttäen mahdollista saada ihan natiivisti.

Se C on siellä enää sitä varten, että tarvitsee jotain suorituskykyriippuvaista komponenttia. Tuossa tulee Lazaruksen tapaan arkkitehtuuririippuvaisuus mutta pitäisi onnistua myös WinRT/CXX jos ei nyt niin kohta, Visual Studiolla kääntäen.

"Kieli on eriytetty toiminnasta siinä mielessä, että sama koodi kääntyy eri ympäristöissä, toteustapa on käyttöjärjestelmäriippuva tietysti - mutta eikös sen käyttöjäjrestelmän kehityksen pitäisi olla myös kuosissa - eli kehitetään se API mikä on rikki kuntoon jos sitä kerran tarvitaan?"

Kuten kerroin niin asia on monimutkaisempi. Siksi Qt:ssäkin on C :n ohella QML.

"Kielenä se ei kuitenkaan häviä millään tavalla vertaisilleen."

Pascal on alunperin tehty opetuskäyttöön. Se olisi jo kuollut 80-luvulla ellei Borland olisi tehnyt Turbo Pascalia. Ja Turbo Pascalin etu oli se, että saivat tehty käännöksen 1-pass:na joten se oli nopea, ja se oli vielä halpa. Tuon menestys on sitä pitänyt hengissä.

Mutta se LCL on edelleenkin 80-luvun WinAPI -> VCL wrapperista johdettu. En kiellä, etteikö se VCL olisi silloin 90-luvulla ollut hyvä mutta Qt on tosiaankin alunperin tehty riippumattomaksi 80-luvun jutuista ensimmäisestä versiosta lähtien signals/slots, ja sen jälkeen tullut neljä sukupolvea uudistusta joten Qt:llä tarvitsee paljon vähemmän nysvätä koodia ja saa siistimmin tehtyä.

...

Niin itsehän en sitten mitenkään erityisesti sitä Qt:tä suosi, se nyt oli tässä vertailukohteena kun mainittu, että Qt:stä vaihdettu Lazarukseen.

Itsehän suosin nykyään Typescript/React yhdistelmää:

http://www.typescriptlang.org/
https://facebook.github.io/react/
https://code.visualstudio.com/

Lue lisää

"M-Kar: Kääntäjänä on Freepascal, mikä on frontend GCC:lle"

M-Kar osoittaa jälleen tietämättömyytensä.

Tosiasiassa Freepascal toimii ihan ilman gcc:tä.

Se on GNU Pascal, joka on frontend GCC:lle.

Freepascal taas on aito Objectpascal -kääntäjä, joka on ohjelmoitu ihan alusta alkaen itse, eli EI siis todellakaan ole frontend GCC:lle.

gcc on muuten uskomattoman hidas kääntäjä.

Freepascal taas on suhteellisen nopea kääntäjä, toki häviää käännösnopeudessa Delphille.