Lazarus muissakin käyttiksissä

Minkä vitun takia niillä pitäs tehdä "bisnessii", tahvo ?

t78i768oi67o kirjoitti:

Minkä vitun takia niillä pitäs tehdä "bisnessii", tahvo ?

Kirjoita sä vaan ihan rauhassa näitä "hello World" sovelluksia lazaruksella amigalle :) Toivottavasti työttömyyskorvaukset riittää amigan ostamiseen, vajakki!! :D :D

code_red kirjoitti:

Kirjoita sä vaan ihan rauhassa näitä "hello World" sovelluksia lazaruksella amigalle :) Toivottavasti työttömyyskorvaukset riittää amigan ostamiseen, vajakki!! :D :D

Sullako ei riitä, oma on häpeäs, tahvo!

tyuhj7tjur67uj6 kirjoitti:

Sullako ei riitä, oma on häpeäs, tahvo!

Kyllä riittää vaikka 100 amigan ostoon :) Ja juuri sen takia riittää, etten opettelu aikoinaan lazaruksen kaltaisia leikkityökaluja käyttämään, vajakki :D :D

code_red kirjoitti:

Kyllä riittää vaikka 100 amigan ostoon :) Ja juuri sen takia riittää, etten opettelu aikoinaan lazaruksen kaltaisia leikkityökaluja käyttämään, vajakki :D :D

Olisi mielenkiintoista tietää mitä (oppimis)vaikeuksia "ammattilaisella" on Lazarus ohjelmointiympäristön käytön kanssa (ja mitähän versiota se koskee)?

Kysyjäkinkanssa kirjoitti:

Olisi mielenkiintoista tietää mitä (oppimis)vaikeuksia "ammattilaisella" on Lazarus ohjelmointiympäristön käytön kanssa (ja mitähän versiota se koskee)?

Ei mitään.

Sen sijaan ammattilainen ymmärtää, että ei ole mitään järkeä käyttää Lazarusta kun parempia välineitä saa maksutta.

Tähän mennessä Lazarus/Delphi porukka jankuttanut siitä että "on hyvä" että pääsisi kirjoittamaan jotain oksennuspascalia työkalulla jolla käännetyt ohjelmat ovat monin tavoin riippuvaisia alustasta ja käyttöliittymä ei skaalaudu.

Mitä hyvää siinä sitten niinku on?

Siihen faktaan että Windowsilla sovelluksia käännettäessä se kääntää koodin vanhaa Windows API:a vasten.

Microsoft toi skaalaukset enste Internet Explorerissa ja sitten .NET 3.0:ssa, niinkuin kunnolla. Kaikki ne vanhemmat ja Windows API:sta riippuvaiset skaalaukset on paskaa. Tämä artikkeli havainnollistaa hyvin: http://wiki.lazarus.freepascal.org/High_DPI#Setting_High_DPI

Sitten kun sovellus toimii Edgessä niin ei ole mitään ihme temppuilua skaalauksen kanssa.

Eli se varsinainen korjaus oli se, että kuinka saat Lazaruksen kääntämään sovelluksen Edgelle?

M-Kar kirjoitti:

Siihen faktaan että Windowsilla sovelluksia käännettäessä se kääntää koodin vanhaa Windows API:a vasten.

Microsoft toi skaalaukset enste Internet Explorerissa ja sitten .NET 3.0:ssa, niinkuin kunnolla. Kaikki ne vanhemmat ja Windows API:sta riippuvaiset skaalaukset on paskaa. Tämä artikkeli havainnollistaa hyvin: http://wiki.lazarus.freepascal.org/High_DPI#Setting_High_DPI

Sitten kun sovellus toimii Edgessä niin ei ole mitään ihme temppuilua skaalauksen kanssa.

Eli se varsinainen korjaus oli se, että kuinka saat Lazaruksen kääntämään sovelluksen Edgelle?

Lue lisää

En ymmärrä sinua. Vaikuttaa Lazarus/Delphi vastaiselta propagandalta. En halua osallistua tullaiseen.

127.0.0.1 kirjoitti:

En ymmärrä sinua. Vaikuttaa Lazarus/Delphi vastaiselta propagandalta. En halua osallistua tullaiseen.

Miksi Lazarusta tai Delphiä pitäisi jotenkin puolustella kun edelleenkin löytyy paremmat työkalut maksutta?

Tuo on se tosiasia ja siksi tuollaisia ei työelämässä käytetä muuten kuin jonkun 90-luvun roskan tekohengittämisessä. Kaikki uusi koodi tehdään paremmilla välineillä.

M-Kar kirjoitti:

Miksi Lazarusta tai Delphiä pitäisi jotenkin puolustella kun edelleenkin löytyy paremmat työkalut maksutta?

Tuo on se tosiasia ja siksi tuollaisia ei työelämässä käytetä muuten kuin jonkun 90-luvun roskan tekohengittämisessä. Kaikki uusi koodi tehdään paremmilla välineillä.

Lue lisää

M-Kar aina vetoaa sosiaaliseen paineeseen, tai ryhmän paineeseen. "Tee näin, koska kaikki muutkin koodarit tekee näin", tai "Tee näin, koska ammattilaiset tekee näin".

Mutta siihen on vanha, hyvin sopiva sananlaskukin olemassa: "Joukossa tyhmyys tiivistyy".

Kai sinun pitäisi osata asiantuntijana parempiakin argumentteja esittää asian puolesta?

M-Kar kirjoitti:

Miksi Lazarusta tai Delphiä pitäisi jotenkin puolustella kun edelleenkin löytyy paremmat työkalut maksutta?

Tuo on se tosiasia ja siksi tuollaisia ei työelämässä käytetä muuten kuin jonkun 90-luvun roskan tekohengittämisessä. Kaikki uusi koodi tehdään paremmilla välineillä.

Lue lisää

Löytyykö esim. Amigalle parempaa välinettä kuin Lazarus?
Kysymyshän on siitä että nämä teidän tarkoitamenne paremmat välineet toimivat ja tukevat vain uusimpia käyttöjärjestelmän versioita tai toimivat vain suosituimmilla alustoilla.

trollerson kirjoitti:

M-Kar aina vetoaa sosiaaliseen paineeseen, tai ryhmän paineeseen. "Tee näin, koska kaikki muutkin koodarit tekee näin", tai "Tee näin, koska ammattilaiset tekee näin".

Mutta siihen on vanha, hyvin sopiva sananlaskukin olemassa: "Joukossa tyhmyys tiivistyy".

Kai sinun pitäisi osata asiantuntijana parempiakin argumentteja esittää asian puolesta?

Lue lisää

Kyse ei ole mistään sosiaalisesta paineesta vaan mitattavista ja määriteltävistä asioista.

Selkeä fakta Lazaruksen heikkoudesta on esimerkiksi se, että kun sillä kääntää ohjelman niin se ohjelma on riippuvainen laitearkkitehtuurista ja käyttöjärjestelmästä, ja Windows ympäristössä myös riesana riippuvuus vanhaan Windows API:n mitä ei luvata pitävän vakaana pidemmälle kuin seuraavaan Windowsiin saakka, eli puoli vuotta.

Toinen fakta löytyy ohjelmointikielestä, sillä sitä ei ole standardoitu missään vaan on joku semmoinen laajennos Pascalista.

Kolmas fakta löytyy Lazaruksella tehtävästä koodista mitattavia asioita. Tämä on oikein hyvä: https://en.wikipedia.org/wiki/Halstead_complexity_measures

Paremmilla välineillä saa koodin siistimmäksi.

Neljäs fakta löytyy komponenteista mitä Lazarus tarjoaa. Ne kun näkyy olevan suunniteltu semmoisiksi, että tallentavat tilaa. Tuota ON mahdollista kiertää ja sitä näkyy joku kokeilleenkin: https://github.com/pierrejean-coudert/ReduxDelphi

Mutta ei tuo kyllä kovinkaan kypsä toteutus ole. Käytännössä menisi siihen, että jos haluaisi tehdä käyttöliittymiä niin pitäisi tehdä itse koko tilan tallennus.

Kysyjäkinkanss kirjoitti:

Löytyykö esim. Amigalle parempaa välinettä kuin Lazarus?
Kysymyshän on siitä että nämä teidän tarkoitamenne paremmat välineet toimivat ja tukevat vain uusimpia käyttöjärjestelmän versioita tai toimivat vain suosituimmilla alustoilla.

Lue lisää

Sitä on pitkään suosittu että käytetään semmoista välinettä millä tekeminen käy helpoiten ja valmista sovellusta voi sitten käyttää missä vaan. Eli jos ostaa Amigan niin ei tarvitsee Amigaa siihen, että tekee sovelluksia joita sillä voi ajaa.

Mutta, onhan siinä joku GCC saatavana että jos sitä vaikka kääntäisi NodeJS:n ja npm:n sorsista niin eihän siinä sitten mikään estä devaamasta suoraan sillä Amigalla vaikka Reactia ja backend sillä NodeJS:llä.

Semmoinen huomio, että nykypäivän sovellusten ei haluta olevan mitenkään riippuvaisia päätelaitteesta. Sama se millä sen sitten tekee.

M-Kar kirjoitti:

Sitä on pitkään suosittu että käytetään semmoista välinettä millä tekeminen käy helpoiten ja valmista sovellusta voi sitten käyttää missä vaan. Eli jos ostaa Amigan niin ei tarvitsee Amigaa siihen, että tekee sovelluksia joita sillä voi ajaa.

Mutta, onhan siinä joku GCC saatavana että jos sitä vaikka kääntäisi NodeJS:n ja npm:n sorsista niin eihän siinä sitten mikään estä devaamasta suoraan sillä Amigalla vaikka Reactia ja backend sillä NodeJS:llä.

Semmoinen huomio, että nykypäivän sovellusten ei haluta olevan mitenkään riippuvaisia päätelaitteesta. Sama se millä sen sitten tekee.

Lue lisää

Ei tuo toimine. Käyttänee liian uutta teknologiaa jota alustalle ei saane. Ei HTML5 "taso" ole vielä kaikkialla käytössä.

Ei_Kaikilla_Ole_Uusia kirjoitti:

Ei tuo toimine. Käyttänee liian uutta teknologiaa jota alustalle ei saane. Ei HTML5 "taso" ole vielä kaikkialla käytössä.

Näkyi olevan olevan AmigaOS:lle säädettynä selaimia tällä vuosikymmenellä, eli pitäisi onnistua. Selaimessa sitten saatu ajettua koodia todella pitkään ja siihen on eri ikäistä tekniikkaa. Tarvittaessa vanha jQuery ja buildaa komponentit ilman nodejs:ää cat:lla niin 10v takainen selainhärpäke toimii.

M-Kar kirjoitti:

Kyse ei ole mistään sosiaalisesta paineesta vaan mitattavista ja määriteltävistä asioista.

Selkeä fakta Lazaruksen heikkoudesta on esimerkiksi se, että kun sillä kääntää ohjelman niin se ohjelma on riippuvainen laitearkkitehtuurista ja käyttöjärjestelmästä, ja Windows ympäristössä myös riesana riippuvuus vanhaan Windows API:n mitä ei luvata pitävän vakaana pidemmälle kuin seuraavaan Windowsiin saakka, eli puoli vuotta.

Toinen fakta löytyy ohjelmointikielestä, sillä sitä ei ole standardoitu missään vaan on joku semmoinen laajennos Pascalista.

Kolmas fakta löytyy Lazaruksella tehtävästä koodista mitattavia asioita. Tämä on oikein hyvä: https://en.wikipedia.org/wiki/Halstead_complexity_measures

Paremmilla välineillä saa koodin siistimmäksi.

Neljäs fakta löytyy komponenteista mitä Lazarus tarjoaa. Ne kun näkyy olevan suunniteltu semmoisiksi, että tallentavat tilaa. Tuota ON mahdollista kiertää ja sitä näkyy joku kokeilleenkin: https://github.com/pierrejean-coudert/ReduxDelphi

Mutta ei tuo kyllä kovinkaan kypsä toteutus ole. Käytännössä menisi siihen, että jos haluaisi tehdä käyttöliittymiä niin pitäisi tehdä itse koko tilan tallennus.

Lue lisää

Windowsin suurin vahvuus on sen API. Sen kautta saadaan ohjelmat sellaisiksi kuin
"vanhat" käyttäjät ovat tottuneet niitä käyttämään. Jos Microsoft tyhmyyksissään menee lopettamaan sen niin sovellukset alkavat käyttämään jotain muuta rajapintaa. Tämä joku muu rajapinta toimii muissakin käyttöjärjestelmissä. Jonka jälkeen on helpompi siirtyä toiseen käyttöjärjestelmään. (Eli tästä on helppo tehdä se johtopäätös että windows API pitäisi olla Microsoft:lle tärkeä jos heillä on viisaita johtajia).

WindowsApi kirjoitti:

Windowsin suurin vahvuus on sen API. Sen kautta saadaan ohjelmat sellaisiksi kuin
"vanhat" käyttäjät ovat tottuneet niitä käyttämään. Jos Microsoft tyhmyyksissään menee lopettamaan sen niin sovellukset alkavat käyttämään jotain muuta rajapintaa. Tämä joku muu rajapinta toimii muissakin käyttöjärjestelmissä. Jonka jälkeen on helpompi siirtyä toiseen käyttöjärjestelmään. (Eli tästä on helppo tehdä se johtopäätös että windows API pitäisi olla Microsoft:lle tärkeä jos heillä on viisaita johtajia).

Lue lisää

"Windowsin suurin vahvuus on sen API. Sen kautta saadaan ohjelmat sellaisiksi kuin
"vanhat" käyttäjät ovat tottuneet niitä käyttämään."

Sovellukset saa sellaisiksi kuin sovelluskehittäjä suunnittelee ne. Saa sen käyttöliittymän tehdä sellaiseksi kuin haluaa riippumatta siitä mikä API on käytössä.

Windowsissa on aika monta API:a versioineen, uusia tulee kaiken aikaa ja vanhoja poistuu. Ohjelmistokehitysvälineet jotka ovat riippuvaisia epästabiilista tai poistuvasta API:sta ovat roskaa.

Pitkän aikaa on ollut niin, että on olemassa standardi API mikä toimii selaimen kautta, ja suurin osa ihmisistä on tottunut käyttämään sitä. Siinä on joitakin rajoitteita joita on tehty turvallisuus- sekä liiketoimintasyistä, että on lisäksi eri käyttöjärjestelmissä myös natiivit API:t.

Windowsissa natiiveille sovelluksille on ensisijaisesti WinRT mutta jos jostain syystä tarvitsee enemmän asioita tai vanhempaa WPF tekniikkaa taaksepäinyhteensopivuussyistä niin on sitten se .NET framework 4.x. Lisäksi on Visual C 2015 runtime jota vasten voi kääntää koodia laitearkkitehtuuririippuvaisesti ja se on varattu johonkin poikkeusjuttuihin ja taaksepäinyhteensopivuussyistä.

"Jos Microsoft tyhmyyksissään menee lopettamaan sen niin sovellukset alkavat käyttämään jotain muuta rajapintaa. Tämä joku muu rajapinta toimii muissakin käyttöjärjestelmissä. Jonka jälkeen on helpompi siirtyä toiseen käyttöjärjestelmään. (Eli tästä on helppo tehdä se johtopäätös että windows API pitäisi olla Microsoft:lle tärkeä jos heillä on viisaita johtajia)."

Windows API ei ole Microsoftille tärkeä koska ohjelmistokehittäjät eivät käytä sitä. Mistäs kummasta semmoista keksit että Windows API:a käytettäisiin?

Sen käyttö suoraan alkoi loppua jo 90-luvun alussa kun tuli MFC, Visual Basic tai muita välineitä jotka tarjosivat omat rajapinnat ja toimi sen Windows API:n päällä. Esimerkiksi Java tekniikka ja Delphin VCL. MFC oli kyllä tehty lähinnä käärimään vanhaa API:a luokkiin ja samasta virheestä kärsi VCL. Javan Swing vuodelta 1998 pärjäsikin näistä pisimpään koska suunnittelua ei tehty 80-luvun rajoitteilla. Sitähän käytettiin vuoteen 2009 saakka laajasti.

Windows API on jo oikeasti käytännössä tuhottu niin, että siitä pysyy vakaana ne osat mitä MFC käyttää. Wikipediasta lainaten:

"MFC is a library that wraps portions of the Windows API in C classes, including functionality that enables them to use a default application framework."

Tästä saadaan selkeä aikataulu:

mfc90.dll -> 2018
mfc100.dll -> 2020
mfc110.dll -> 2022
mfc120.dll -> 2024
mfc140.dll -> 2027

Jokaisessa näistä on riippuvuuksia vanhaan Windows API:n joiltakin osin, ja sitä mukaan kun nuo vanhenevat, toiminnot voidaan siivota Windows API:sta sitä mukaan kun niitä ei tarvitse. Tarvitseminen menee sen mukaan kun luvattu aika umpeutuu.

Windows API itsessään muuttuu 2x vuodessa, aina Windowsin version mukaan mutta nuo korkeamman tason kirjastot on ne mitä pidetään luvatusti vakaina pidempiä aikoja.

M-Kar kirjoitti:

"Windowsin suurin vahvuus on sen API. Sen kautta saadaan ohjelmat sellaisiksi kuin
"vanhat" käyttäjät ovat tottuneet niitä käyttämään."

Sovellukset saa sellaisiksi kuin sovelluskehittäjä suunnittelee ne. Saa sen käyttöliittymän tehdä sellaiseksi kuin haluaa riippumatta siitä mikä API on käytössä.

Windowsissa on aika monta API:a versioineen, uusia tulee kaiken aikaa ja vanhoja poistuu. Ohjelmistokehitysvälineet jotka ovat riippuvaisia epästabiilista tai poistuvasta API:sta ovat roskaa.

Pitkän aikaa on ollut niin, että on olemassa standardi API mikä toimii selaimen kautta, ja suurin osa ihmisistä on tottunut käyttämään sitä. Siinä on joitakin rajoitteita joita on tehty turvallisuus- sekä liiketoimintasyistä, että on lisäksi eri käyttöjärjestelmissä myös natiivit API:t.

Windowsissa natiiveille sovelluksille on ensisijaisesti WinRT mutta jos jostain syystä tarvitsee enemmän asioita tai vanhempaa WPF tekniikkaa taaksepäinyhteensopivuussyistä niin on sitten se .NET framework 4.x. Lisäksi on Visual C 2015 runtime jota vasten voi kääntää koodia laitearkkitehtuuririippuvaisesti ja se on varattu johonkin poikkeusjuttuihin ja taaksepäinyhteensopivuussyistä.

"Jos Microsoft tyhmyyksissään menee lopettamaan sen niin sovellukset alkavat käyttämään jotain muuta rajapintaa. Tämä joku muu rajapinta toimii muissakin käyttöjärjestelmissä. Jonka jälkeen on helpompi siirtyä toiseen käyttöjärjestelmään. (Eli tästä on helppo tehdä se johtopäätös että windows API pitäisi olla Microsoft:lle tärkeä jos heillä on viisaita johtajia)."

Windows API ei ole Microsoftille tärkeä koska ohjelmistokehittäjät eivät käytä sitä. Mistäs kummasta semmoista keksit että Windows API:a käytettäisiin?

Sen käyttö suoraan alkoi loppua jo 90-luvun alussa kun tuli MFC, Visual Basic tai muita välineitä jotka tarjosivat omat rajapinnat ja toimi sen Windows API:n päällä. Esimerkiksi Java tekniikka ja Delphin VCL. MFC oli kyllä tehty lähinnä käärimään vanhaa API:a luokkiin ja samasta virheestä kärsi VCL. Javan Swing vuodelta 1998 pärjäsikin näistä pisimpään koska suunnittelua ei tehty 80-luvun rajoitteilla. Sitähän käytettiin vuoteen 2009 saakka laajasti.

Windows API on jo oikeasti käytännössä tuhottu niin, että siitä pysyy vakaana ne osat mitä MFC käyttää. Wikipediasta lainaten:

"MFC is a library that wraps portions of the Windows API in C classes, including functionality that enables them to use a default application framework."

Tästä saadaan selkeä aikataulu:

mfc90.dll -> 2018
mfc100.dll -> 2020
mfc110.dll -> 2022
mfc120.dll -> 2024
mfc140.dll -> 2027

Jokaisessa näistä on riippuvuuksia vanhaan Windows API:n joiltakin osin, ja sitä mukaan kun nuo vanhenevat, toiminnot voidaan siivota Windows API:sta sitä mukaan kun niitä ei tarvitse. Tarvitseminen menee sen mukaan kun luvattu aika umpeutuu.

Windows API itsessään muuttuu 2x vuodessa, aina Windowsin version mukaan mutta nuo korkeamman tason kirjastot on ne mitä pidetään luvatusti vakaina pidempiä aikoja.

Lue lisää

Eli antaa se kuvan et MS on huono valinta

MMMMMMI kirjoitti:

Eli antaa se kuvan et MS on huono valinta

Ei mitenkään, koska nykypäiväisiä sovelluksia ei tarvitse tehdä riippuvaiseksi mistään Microsoftin rajapinnasta.

M-Kar kirjoitti:

Ei mitenkään, koska nykypäiväisiä sovelluksia ei tarvitse tehdä riippuvaiseksi mistään Microsoftin rajapinnasta.

Ihan vaan tiedoksi että Lazaruksella (Pascal) tehdään sovelluksia hyvin monille rajapinnoille: windowsin lisäksi mm QT:lle, GTK:lle, FreeBsd, Macille, androidille, isoille ja pienille sulautetuille, Javan tavukoodille, JavaScript:lle jne.

Pascalilla sovellukset voidaan tehdä hyvin konekohtaiseksi mutta näin ei välttämättä tarvi tehdä. Esim. hyvin pienissä sulautetuissa voi olla vain 2 tavua RAM muistia!
Isommissa sulautetuissa voi olla joku tietokanta ja OpenGL näytönohjain mutta ei mitään käyttöjärjestelmää!

Ja näiden sulautettujen lisäksi tulee nämä joissa on käyttöjärjestelmä...

M-Kar kirjoitti:

Kyse ei ole mistään sosiaalisesta paineesta vaan mitattavista ja määriteltävistä asioista.

Selkeä fakta Lazaruksen heikkoudesta on esimerkiksi se, että kun sillä kääntää ohjelman niin se ohjelma on riippuvainen laitearkkitehtuurista ja käyttöjärjestelmästä, ja Windows ympäristössä myös riesana riippuvuus vanhaan Windows API:n mitä ei luvata pitävän vakaana pidemmälle kuin seuraavaan Windowsiin saakka, eli puoli vuotta.

Toinen fakta löytyy ohjelmointikielestä, sillä sitä ei ole standardoitu missään vaan on joku semmoinen laajennos Pascalista.

Kolmas fakta löytyy Lazaruksella tehtävästä koodista mitattavia asioita. Tämä on oikein hyvä: https://en.wikipedia.org/wiki/Halstead_complexity_measures

Paremmilla välineillä saa koodin siistimmäksi.

Neljäs fakta löytyy komponenteista mitä Lazarus tarjoaa. Ne kun näkyy olevan suunniteltu semmoisiksi, että tallentavat tilaa. Tuota ON mahdollista kiertää ja sitä näkyy joku kokeilleenkin: https://github.com/pierrejean-coudert/ReduxDelphi

Mutta ei tuo kyllä kovinkaan kypsä toteutus ole. Käytännössä menisi siihen, että jos haluaisi tehdä käyttöliittymiä niin pitäisi tehdä itse koko tilan tallennus.

Lue lisää

Pascal:lla ohjelmoitaessa ei tarvi käyttää komponentteja. Jos haluaa voi tehdä komponentit itse sellaiseksi kuin haluaa. Voi käyttää haluamiansa rajapintoja. Näihän Lazarus on tehtykin. Esim. kun Lazarus käyttää QT:tä niin siinä on koodia joka toimii QT rajapinnan kanssa.

Myöskään olio-ohjelmointia ei tarvitse käyttää.

Lazz_o kirjoitti:

Ihan vaan tiedoksi että Lazaruksella (Pascal) tehdään sovelluksia hyvin monille rajapinnoille: windowsin lisäksi mm QT:lle, GTK:lle, FreeBsd, Macille, androidille, isoille ja pienille sulautetuille, Javan tavukoodille, JavaScript:lle jne.

Pascalilla sovellukset voidaan tehdä hyvin konekohtaiseksi mutta näin ei välttämättä tarvi tehdä. Esim. hyvin pienissä sulautetuissa voi olla vain 2 tavua RAM muistia!
Isommissa sulautetuissa voi olla joku tietokanta ja OpenGL näytönohjain mutta ei mitään käyttöjärjestelmää!

Ja näiden sulautettujen lisäksi tulee nämä joissa on käyttöjärjestelmä...

Lue lisää

"Ihan vaan tiedoksi että Lazaruksella (Pascal) tehdään sovelluksia hyvin monille rajapinnoille: windowsin lisäksi mm QT:lle, GTK:lle, FreeBsd, Macille, androidille, isoille ja pienille sulautetuille, Javan tavukoodille, JavaScript:lle jne."

Ei se ole muuta kuin LCL -> wrapperi natiivirajapinnalle. Ja se kääntää edelleen laitearkkitehtuurikohtaista koodia ja Windowsissa se kääntää Windowsin legacyrajapinnalle.

Jos homma olisi tehty oikein kääntäjän osalta, niin siinä olisi:

1. Pascal -> C kääntäjä. Eli se kääntäjä kääntäisi natiiviksi kääntämällä C:lle ja käyttöjärjestelmän vakio C kääntäjä hoitaisi optimoinnit
2. Pascal -> Javascript kääntäjä. Kun siirrettävää koodia, se kääntäisi Javascriptiksi joka sitten edelleen optimoidaan
3. LCL pitäisi toteuttaa myös esim. Reactille

Kohta 2. näkyy olevan huomioituna: https://foundation.freepascal.org/projects/pastojs

Todistaa siis sitä, että argumenttini pitää paikkansa.

Tuossa vaan tulee vähän hassunhauskoja asioita vastaan kun Pascal kieli ei ole mitenkään erityisen hyvä, että miksi sitä pitäisi käyttää? Ja LCL komponentit eivät ole mitenkään erityisen hyviä, että miksi se on niiden varassa?

No, syy on siinä, että Lazarus tehty vanhan Delphikoodin tekohengittämiseen ja siirtämiseen Windowsista pois.

Ohjelmistokehittäjästä se toki on edelleen viime kädessä kiinni mutta se ei muuta sitä, että kaikesta huolimattaa samat asiat saa tehtyä niin paljon paremmin muilla välineillä.

Jostain syystä joillain tuntuu olevan harhakäsityksiä, että Pascal olisi jotenkin erityisen hyvä kieli että se oikeuttaisi tuohon mutta sehän ei tietenkään pidä paikkaansa.

Lazz_o kirjoitti:

Pascal:lla ohjelmoitaessa ei tarvi käyttää komponentteja. Jos haluaa voi tehdä komponentit itse sellaiseksi kuin haluaa. Voi käyttää haluamiansa rajapintoja. Näihän Lazarus on tehtykin. Esim. kun Lazarus käyttää QT:tä niin siinä on koodia joka toimii QT rajapinnan kanssa.

Myöskään olio-ohjelmointia ei tarvitse käyttää.

Lue lisää

"Pascal:lla ohjelmoitaessa ei tarvi käyttää komponentteja. Jos haluaa voi tehdä komponentit itse sellaiseksi kuin haluaa."

Lazaruksella et saa tehtyä edes menua helpolla selaimeen.

"Voi käyttää haluamiansa rajapintoja. Näihän Lazarus on tehtykin. Esim. kun Lazarus käyttää QT:tä niin siinä on koodia joka toimii QT rajapinnan kanssa."

Sillä ei pysty tekemään esim. React, Vue tai Angular -komponentteja.

"Myöskään olio-ohjelmointia ei tarvitse käyttää."

Ennemminkin kiinnostaa se miten funktionaaliseksi sen koodin saa.

M-Kar kirjoitti:

"Ihan vaan tiedoksi että Lazaruksella (Pascal) tehdään sovelluksia hyvin monille rajapinnoille: windowsin lisäksi mm QT:lle, GTK:lle, FreeBsd, Macille, androidille, isoille ja pienille sulautetuille, Javan tavukoodille, JavaScript:lle jne."

Ei se ole muuta kuin LCL -> wrapperi natiivirajapinnalle. Ja se kääntää edelleen laitearkkitehtuurikohtaista koodia ja Windowsissa se kääntää Windowsin legacyrajapinnalle.

Jos homma olisi tehty oikein kääntäjän osalta, niin siinä olisi:

1. Pascal -> C kääntäjä. Eli se kääntäjä kääntäisi natiiviksi kääntämällä C:lle ja käyttöjärjestelmän vakio C kääntäjä hoitaisi optimoinnit
2. Pascal -> Javascript kääntäjä. Kun siirrettävää koodia, se kääntäisi Javascriptiksi joka sitten edelleen optimoidaan
3. LCL pitäisi toteuttaa myös esim. Reactille

Kohta 2. näkyy olevan huomioituna: https://foundation.freepascal.org/projects/pastojs

Todistaa siis sitä, että argumenttini pitää paikkansa.

Tuossa vaan tulee vähän hassunhauskoja asioita vastaan kun Pascal kieli ei ole mitenkään erityisen hyvä, että miksi sitä pitäisi käyttää? Ja LCL komponentit eivät ole mitenkään erityisen hyviä, että miksi se on niiden varassa?

No, syy on siinä, että Lazarus tehty vanhan Delphikoodin tekohengittämiseen ja siirtämiseen Windowsista pois.

Ohjelmistokehittäjästä se toki on edelleen viime kädessä kiinni mutta se ei muuta sitä, että kaikesta huolimattaa samat asiat saa tehtyä niin paljon paremmin muilla välineillä.

Jostain syystä joillain tuntuu olevan harhakäsityksiä, että Pascal olisi jotenkin erityisen hyvä kieli että se oikeuttaisi tuohon mutta sehän ei tietenkään pidä paikkaansa.

Lue lisää

Javascript on vain välivaiheen ohjelmointikieli. Sovellukset alkavat pikku hiljaa siirtymään webassemblylle.

webassembly kirjoitti:

Javascript on vain välivaiheen ohjelmointikieli. Sovellukset alkavat pikku hiljaa siirtymään webassemblylle.

Javascript -> webassembly on vain optimointia. Ei vaikuta ohjelmointiin millään tavalla. Sama koodi vaan toimii paremmalla hyötysuhteella.

Eli nykyinen ohjelma mitä tekee siirtyy webassemblylle käytännössä buildijärjestelmässä jonkun vivun vääntämisellä. Sitten sama ohjelma kääntyy webassemblylle.

M-Kar kirjoitti:

"Pascal:lla ohjelmoitaessa ei tarvi käyttää komponentteja. Jos haluaa voi tehdä komponentit itse sellaiseksi kuin haluaa."

Lazaruksella et saa tehtyä edes menua helpolla selaimeen.

"Voi käyttää haluamiansa rajapintoja. Näihän Lazarus on tehtykin. Esim. kun Lazarus käyttää QT:tä niin siinä on koodia joka toimii QT rajapinnan kanssa."

Sillä ei pysty tekemään esim. React, Vue tai Angular -komponentteja.

"Myöskään olio-ohjelmointia ei tarvitse käyttää."

Ennemminkin kiinnostaa se miten funktionaaliseksi sen koodin saa.

Lue lisää

"Sillä ei pysty tekemään esim. React, Vue tai Angular -komponentteja."

Niin näille mobiili-virityksillehän on omat työkalut jos niille pitää koodailla! Ei kait kukaan oletakkaan että Lazaruksella tekee jollekkin Angularille komponentteja =D Sama JavaScriptin kanssa, eli koodaa sitten suoraan JavaScriptillä/TypeScriptillä ym. sopivaan mobiiliin väkkyrään (framewörkkiin), jos tehdään sille tarkoitettua softaa.

ex-delphisti kirjoitti:

"Sillä ei pysty tekemään esim. React, Vue tai Angular -komponentteja."

Niin näille mobiili-virityksillehän on omat työkalut jos niille pitää koodailla! Ei kait kukaan oletakkaan että Lazaruksella tekee jollekkin Angularille komponentteja =D Sama JavaScriptin kanssa, eli koodaa sitten suoraan JavaScriptillä/TypeScriptillä ym. sopivaan mobiiliin väkkyrään (framewörkkiin), jos tehdään sille tarkoitettua softaa.

Lue lisää

"Niin näille mobiili-virityksillehän on omat työkalut jos niille pitää koodailla!"

Ei kyse ole mistään mobiilivirityksistä. Lähes kaikkien työpöytäsovellusten käyttöliittymä tehdään käyttämällä näitä.

"Ei kait kukaan oletakkaan että Lazaruksella tekee jollekkin Angularille komponentteja =D"

No eihän sillä Lazaruksella tee mitään kun ei se käytä nykypäivän tekniikaa

Kerrohan nyt ihan omin sanoin miksi pitäisi käyttää Lazarusta jossa on karmea kieli ei käännä koodia standarditekniikalle? Miksi pitää olla jotain typeriä laitearkkitehtuuririippuvuuksia tai käyttöjärjestelmäriippuvuuksia käännetyssä koodissa?

ex-delphisti kirjoitti:

"Sillä ei pysty tekemään esim. React, Vue tai Angular -komponentteja."

Niin näille mobiili-virityksillehän on omat työkalut jos niille pitää koodailla! Ei kait kukaan oletakkaan että Lazaruksella tekee jollekkin Angularille komponentteja =D Sama JavaScriptin kanssa, eli koodaa sitten suoraan JavaScriptillä/TypeScriptillä ym. sopivaan mobiiliin väkkyrään (framewörkkiin), jos tehdään sille tarkoitettua softaa.

Lue lisää

Ja katsohan tämä huolella: https://upload.wikimedia.org/wikipedia/commons/thumb/e/e2/Lazarus_architecture.svg/2000px-Lazarus_architecture.svg.png

Mietihän vähän että mikä siinä Lazaruksessa on perustavalla tasolla pielessä kun se LCL on tuollainen wrapperi ja se ei kuitenkaan käännä komponenteille mitkä toimisi standardin varassa. Mitä helvettiä tuo Win32 ja Carbon tuolla edes tekee? Nehän on ihan kivikautisia.

M-Kar kirjoitti:

Ja katsohan tämä huolella: https://upload.wikimedia.org/wikipedia/commons/thumb/e/e2/Lazarus_architecture.svg/2000px-Lazarus_architecture.svg.png

Mietihän vähän että mikä siinä Lazaruksessa on perustavalla tasolla pielessä kun se LCL on tuollainen wrapperi ja se ei kuitenkaan käännä komponenteille mitkä toimisi standardin varassa. Mitä helvettiä tuo Win32 ja Carbon tuolla edes tekee? Nehän on ihan kivikautisia.

Lue lisää

Kyllä nämä perinteiin rajapintoihin perustuvat sovellukset on vielä voimissaan. Esim tässä omassa työkoneessa äkkisteltään katsottuna mitä käytän on XmlSpy, SqlYog ja PHPEd. XmlSpy on versio 2014 joten uusimmasta en tiedä, mutta tämä näyttäisi olevan vielä tämmöinen vanhan mallinen MDI-sovellus, joten ei varmaan ole millään web-teknologialla tehty. Sikäli ihan mielenkiintoista seurata näiden sovellusten kehitystä. Eikä kyllä tule mieleen mitään isomman tason ammattisovellusta joka olisi tehty web-teknologialla, näin omassa käytössä. VSCode on ainut mutta vain omassa kotikäytössä.

M-Kar kirjoitti:

"Ihan vaan tiedoksi että Lazaruksella (Pascal) tehdään sovelluksia hyvin monille rajapinnoille: windowsin lisäksi mm QT:lle, GTK:lle, FreeBsd, Macille, androidille, isoille ja pienille sulautetuille, Javan tavukoodille, JavaScript:lle jne."

Ei se ole muuta kuin LCL -> wrapperi natiivirajapinnalle. Ja se kääntää edelleen laitearkkitehtuurikohtaista koodia ja Windowsissa se kääntää Windowsin legacyrajapinnalle.

Jos homma olisi tehty oikein kääntäjän osalta, niin siinä olisi:

1. Pascal -> C kääntäjä. Eli se kääntäjä kääntäisi natiiviksi kääntämällä C:lle ja käyttöjärjestelmän vakio C kääntäjä hoitaisi optimoinnit
2. Pascal -> Javascript kääntäjä. Kun siirrettävää koodia, se kääntäisi Javascriptiksi joka sitten edelleen optimoidaan
3. LCL pitäisi toteuttaa myös esim. Reactille

Kohta 2. näkyy olevan huomioituna: https://foundation.freepascal.org/projects/pastojs

Todistaa siis sitä, että argumenttini pitää paikkansa.

Tuossa vaan tulee vähän hassunhauskoja asioita vastaan kun Pascal kieli ei ole mitenkään erityisen hyvä, että miksi sitä pitäisi käyttää? Ja LCL komponentit eivät ole mitenkään erityisen hyviä, että miksi se on niiden varassa?

No, syy on siinä, että Lazarus tehty vanhan Delphikoodin tekohengittämiseen ja siirtämiseen Windowsista pois.

Ohjelmistokehittäjästä se toki on edelleen viime kädessä kiinni mutta se ei muuta sitä, että kaikesta huolimattaa samat asiat saa tehtyä niin paljon paremmin muilla välineillä.

Jostain syystä joillain tuntuu olevan harhakäsityksiä, että Pascal olisi jotenkin erityisen hyvä kieli että se oikeuttaisi tuohon mutta sehän ei tietenkään pidä paikkaansa.

Lue lisää

"Pascal -> C kääntäjä. Eli se kääntäjä kääntäisi natiiviksi kääntämällä C:lle ja käyttöjärjestelmän vakio C kääntäjä hoitaisi optimoinnit"

Tämän kaltainen käännös on toteutettu Vala-kielessä, periaatteessa toimii ihan mukavasti, ainut huono puoli tuossa on että koodia on tosi hankala debugata.

ex-delphisti kirjoitti:

"Pascal -> C kääntäjä. Eli se kääntäjä kääntäisi natiiviksi kääntämällä C:lle ja käyttöjärjestelmän vakio C kääntäjä hoitaisi optimoinnit"

Tämän kaltainen käännös on toteutettu Vala-kielessä, periaatteessa toimii ihan mukavasti, ainut huono puoli tuossa on että koodia on tosi hankala debugata.

Lue lisää

Tälläinen on jo ollut:
GNU Pascal
Ei saanut suosiota (esim. Pascal käyttäjiltä).

ex-delphisti kirjoitti:

Kyllä nämä perinteiin rajapintoihin perustuvat sovellukset on vielä voimissaan. Esim tässä omassa työkoneessa äkkisteltään katsottuna mitä käytän on XmlSpy, SqlYog ja PHPEd. XmlSpy on versio 2014 joten uusimmasta en tiedä, mutta tämä näyttäisi olevan vielä tämmöinen vanhan mallinen MDI-sovellus, joten ei varmaan ole millään web-teknologialla tehty. Sikäli ihan mielenkiintoista seurata näiden sovellusten kehitystä. Eikä kyllä tule mieleen mitään isomman tason ammattisovellusta joka olisi tehty web-teknologialla, näin omassa käytössä. VSCode on ainut mutta vain omassa kotikäytössä.

Lue lisää

"Kyllä nämä perinteiin rajapintoihin perustuvat sovellukset on vielä voimissaan. Esim tässä omassa työkoneessa äkkisteltään katsottuna mitä käytän on XmlSpy, SqlYog ja PHPEd. XmlSpy on versio 2014 joten uusimmasta en tiedä, mutta tämä näyttäisi olevan vielä tämmöinen vanhan mallinen MDI-sovellus, joten ei varmaan ole millään web-teknologialla tehty."

"Eikä kyllä tule mieleen mitään isomman tason ammattisovellusta joka olisi tehty web-teknologialla"

Miten olisi vaikka Bugzilla?

ex-delphisti kirjoitti:

"Pascal -> C kääntäjä. Eli se kääntäjä kääntäisi natiiviksi kääntämällä C:lle ja käyttöjärjestelmän vakio C kääntäjä hoitaisi optimoinnit"

Tämän kaltainen käännös on toteutettu Vala-kielessä, periaatteessa toimii ihan mukavasti, ainut huono puoli tuossa on että koodia on tosi hankala debugata.

Lue lisää

On muitakin. Esimerkiksi Haskell tai ja varmasti jotain LISP kieliä käännellään C:lle.

Ja tuo on järkevää. Voi keskittyä tekemään sitä kielen kääntäjää ja jättää optimoinnit sille C-kääntäjälle mihin prosessorivalmistajat tekevät opimointejaan. C-kääntäjä joka paikassa että ratkoo siirrettävyydenkin sitten.

Vala muuten on varmaan paras valmis työkalu tehdä natiiveja GUI sovelluksia GTK ympäristöihin. Mutta ehkä parempaan pääsis jos työstäisi Haskellilla jotain uniflow patternia.

M-Kar kirjoitti:

Ja katsohan tämä huolella: https://upload.wikimedia.org/wikipedia/commons/thumb/e/e2/Lazarus_architecture.svg/2000px-Lazarus_architecture.svg.png

Mietihän vähän että mikä siinä Lazaruksessa on perustavalla tasolla pielessä kun se LCL on tuollainen wrapperi ja se ei kuitenkaan käännä komponenteille mitkä toimisi standardin varassa. Mitä helvettiä tuo Win32 ja Carbon tuolla edes tekee? Nehän on ihan kivikautisia.

Lue lisää

Tuostahan voit päätellä että jos tuo on sinusta monimutkainen niin millaisia asioita jo "harrastajat" sillä pystyy tekemään. Tuohan on pysynyt kasassa pidempään kuin moni muu ohjelma. Toistakymmentä vuotta (ja monella alustalla)!

AsianVoiNähdäNäinkin kirjoitti:

Tuostahan voit päätellä että jos tuo on sinusta monimutkainen niin millaisia asioita jo "harrastajat" sillä pystyy tekemään. Tuohan on pysynyt kasassa pidempään kuin moni muu ohjelma. Toistakymmentä vuotta (ja monella alustalla)!

Lue lisää

Sillä ei edelleenkään ole merkitystä kun perusasiat on pielessä. Koko Lazarus on lähtenyt siitä, että koitetaan apinoida Delphiä että voidaan tekohengittää vanhoja Delphillä tehtyjä sovelluksia, ja Delphi taas on sitä ysäri tekniikkaa jonka VCL rajapinta on wrapperina 80-luvun Windows API:lle, joka on kaikin puolin päin persettä suunniteltu ja riippuvainen mm. arkkitehtuurista.

Sillä aikaa kun Lazaruksen kehittäjät keskittyivät apinoimaan Delphiä, ohjelmistoalan työkalut menivät eteenpäin.

Lazaruksella on joidenkin perusasioiden tekeminen joko mahdotonta tai työlästä ja lopputuloksesta ei saa hyvää.

Jonkinnäköistä häkkäystä ja purkkaa ne skaalausasiat on niin pitkään kuin renderöinti tehdään jonkun muinaisen Windows API:n kautta eikä WPF:n.

Ja WPF:n kautta ei tule onnistumaan niin pitkään kuin FreePascal ei käännä CIL tavukoodia.

Tuossa on siis asiat pielessä perustuksia myöten.

Ei tuo minulta tietenkään pois ole mitenkään jos joku haluaa ohjelmoida paskasti mutta ehkä pitäisi kyseistä työkalua jokaisen käyttävän ymmärtää mitkä asiat siellä on perustuksia myöten pielessä ja mitä se tarkoittaa jatkuvuudelle.

Siitä olen samaa mieltä, että Delphi on ylihinnoiteltu. Se mitä niillä on tarjota, kelpaisi ilmaisohjelmaksi johon myydään tukea haluakkaille.

Mielestäni viimeinen hyvä Delphi versio oli Delphi 7 ja sen jälkeen se alkoi näivettymään pahasti ja ennen kaikkea siksi kun ilmaiseksi sai kokoajan enemmän ja parempaa joka mittarilla, ja tästä on 15v aikaa jo. Delphissä oli silloin vuonna 2002 oikein kiva IDE ikkunoiden suunnitteluun mutta vuoden 2006 NetBeans teki samat ilmaiseksi ja paremmin.

Jänskästi vaan samaan aikaan oli alettu oppia, että käyttöliittymissä ikkunat toimivat huonosti ja paremmin toimii kun on yksi scrollattava näkymä, ja käytettävyystutkimuksien mukaan ihmiset lisäksi oppineet tuohon jo vuonna 1997 WWW-selainten myötä.

Vanhanmalliset GUI builder työkalut tuntuvat sopivan huonosti nykyaikaan kun haluttaisiin lukita navigointi johokin kohtaa ikkunaa ja sitten sisältö semmoinen scrollattava alue. Ennnen vanhaan harrastettin sitä että kaikki mitä käytetään pitäisi näkyä ruudulla ja sitten on joku menuvalikko helvetti mistä se vaihdettiin. Nykyään on vähemmän menuhelvettiä ja sen sijaan vaihdetaan näkymä mitä scrollaillaan.

M-Kar kirjoitti:

Jonkinnäköistä häkkäystä ja purkkaa ne skaalausasiat on niin pitkään kuin renderöinti tehdään jonkun muinaisen Windows API:n kautta eikä WPF:n.

Ja WPF:n kautta ei tule onnistumaan niin pitkään kuin FreePascal ei käännä CIL tavukoodia.

Tuossa on siis asiat pielessä perustuksia myöten.

Ei tuo minulta tietenkään pois ole mitenkään jos joku haluaa ohjelmoida paskasti mutta ehkä pitäisi kyseistä työkalua jokaisen käyttävän ymmärtää mitkä asiat siellä on perustuksia myöten pielessä ja mitä se tarkoittaa jatkuvuudelle.

Siitä olen samaa mieltä, että Delphi on ylihinnoiteltu. Se mitä niillä on tarjota, kelpaisi ilmaisohjelmaksi johon myydään tukea haluakkaille.

Mielestäni viimeinen hyvä Delphi versio oli Delphi 7 ja sen jälkeen se alkoi näivettymään pahasti ja ennen kaikkea siksi kun ilmaiseksi sai kokoajan enemmän ja parempaa joka mittarilla, ja tästä on 15v aikaa jo. Delphissä oli silloin vuonna 2002 oikein kiva IDE ikkunoiden suunnitteluun mutta vuoden 2006 NetBeans teki samat ilmaiseksi ja paremmin.

Jänskästi vaan samaan aikaan oli alettu oppia, että käyttöliittymissä ikkunat toimivat huonosti ja paremmin toimii kun on yksi scrollattava näkymä, ja käytettävyystutkimuksien mukaan ihmiset lisäksi oppineet tuohon jo vuonna 1997 WWW-selainten myötä.

Vanhanmalliset GUI builder työkalut tuntuvat sopivan huonosti nykyaikaan kun haluttaisiin lukita navigointi johokin kohtaa ikkunaa ja sitten sisältö semmoinen scrollattava alue. Ennnen vanhaan harrastettin sitä että kaikki mitä käytetään pitäisi näkyä ruudulla ja sitten on joku menuvalikko helvetti mistä se vaihdettiin. Nykyään on vähemmän menuhelvettiä ja sen sijaan vaihdetaan näkymä mitä scrollaillaan.

Lue lisää

Jos osaat voit lisätä funktionaallisuutta, kääntää CIL-tavukoodiksi tai C-kielelle ja kääntää komponenteille mitä sinä pidät tärkeänä. Voit jopa saada apua muilta. Eli kaikki tämä on mahdollista (Lisenssit sallivat sen. Kaikilla muilla näin ei ole). Tilanne taitaa tällä hetkellä vain olla se että muut haluavat kuluttaa aikansa mielummin muiden asioiden parissa (kuten "ikivanhan" Amigan...) ja tehdä niille koodia. Tietenkin edellytyksenä on että osaamista löytyy.

Lazz_0 kirjoitti:

Jos osaat voit lisätä funktionaallisuutta, kääntää CIL-tavukoodiksi tai C-kielelle ja kääntää komponenteille mitä sinä pidät tärkeänä. Voit jopa saada apua muilta. Eli kaikki tämä on mahdollista (Lisenssit sallivat sen. Kaikilla muilla näin ei ole). Tilanne taitaa tällä hetkellä vain olla se että muut haluavat kuluttaa aikansa mielummin muiden asioiden parissa (kuten "ikivanhan" Amigan...) ja tehdä niille koodia. Tietenkin edellytyksenä on että osaamista löytyy.

Lue lisää

"Jos osaat voit lisätä funktionaallisuutta, kääntää CIL-tavukoodiksi tai C-kielelle ja kääntää komponenteille mitä sinä pidät tärkeänä."

No se on sen ohjelmointivälineen tehtävä. Ei sovellusohjelmoija tuollaista nysvää, se on se ohjelmointivälineen kehittäjän hommia.

Asioiden pitää olla valmiita NYT. Jos ne ei ole valmiita nyt, Lazarus ei nyt ole kelvollinen työväline puutteidensa takia.

M-Kar kirjoitti:

"Jos osaat voit lisätä funktionaallisuutta, kääntää CIL-tavukoodiksi tai C-kielelle ja kääntää komponenteille mitä sinä pidät tärkeänä."

No se on sen ohjelmointivälineen tehtävä. Ei sovellusohjelmoija tuollaista nysvää, se on se ohjelmointivälineen kehittäjän hommia.

Asioiden pitää olla valmiita NYT. Jos ne ei ole valmiita nyt, Lazarus ei nyt ole kelvollinen työväline puutteidensa takia.

Lue lisää

No kaikki sovellusohjelmoijat eivät pidä tärkeänä noita asioita (CIL-tavukoodia, kääntämistä C-kielelle jne).

Todennäköisesti nämä android sukupolven nuoret arvostavat enemmän sitä että
sovellus toimii heidän laitteissa jne

anterookin kirjoitti:

No kaikki sovellusohjelmoijat eivät pidä tärkeänä noita asioita (CIL-tavukoodia, kääntämistä C-kielelle jne).

Todennäköisesti nämä android sukupolven nuoret arvostavat enemmän sitä että
sovellus toimii heidän laitteissa jne

Lue lisää

Delphillä on voinut tehdä jo vuosia antero ja omppusoftia:
kuten tässä 3D kompanssi
https://www.youtube.com/watch?v=KXI1xQMLOZM

anterookin kirjoitti:

No kaikki sovellusohjelmoijat eivät pidä tärkeänä noita asioita (CIL-tavukoodia, kääntämistä C-kielelle jne).

Todennäköisesti nämä android sukupolven nuoret arvostavat enemmän sitä että
sovellus toimii heidän laitteissa jne

Lue lisää

Vain lähes 100% ja se nähdään sovelluksista mitä tehdään. Lähes kaikki ammattikäyttöön tehdyt sovellukset mitä on aloitettu tekemään viimeisen 10v aikana toimii HTML5/HTTP/EcmaScript standardeja käyttämällä.

Sovelluksen pitää tietysti toimia kaikissa laitteissa. Sama asia kuin ostaisi vaikka hiustenkuivaajan niin sen pitää toimia Imatran voiman, Vattenfallin jne. kaikkien sähköjen kanssa. Sitä asiaa kutsutaan standardoinniksi.

M-Kar kirjoitti:

Vain lähes 100% ja se nähdään sovelluksista mitä tehdään. Lähes kaikki ammattikäyttöön tehdyt sovellukset mitä on aloitettu tekemään viimeisen 10v aikana toimii HTML5/HTTP/EcmaScript standardeja käyttämällä.

Sovelluksen pitää tietysti toimia kaikissa laitteissa. Sama asia kuin ostaisi vaikka hiustenkuivaajan niin sen pitää toimia Imatran voiman, Vattenfallin jne. kaikkien sähköjen kanssa. Sitä asiaa kutsutaan standardoinniksi.

Lue lisää

En sinuna ostaisi hiustenkuivaajaa esim. USAsta ;-) ! "...viimeisen 10v aikana toimii HTML5..." HTML5 tuli standarksi 28. lokakuuta 2014 eli 3 vuotta sitten. Esim. jotkut ajavat 10-18 v vanhalla autolla -> HTML 3.2 tuli 1997 joten nettisivut
jotka halutaan toimivan lähes kaikilla pitää olla tätä tasoa (Yhteiskunnalliset). Yritykset joilla ei ole yhteiskunnallista velvoitetta (eikä ole monopoli tai oligopoli- asemaa) voivat toki valita asiakkaansa ja tukea mitä haluavat.

Jotainasiaa kirjoitti:

En sinuna ostaisi hiustenkuivaajaa esim. USAsta ;-) ! "...viimeisen 10v aikana toimii HTML5..." HTML5 tuli standarksi 28. lokakuuta 2014 eli 3 vuotta sitten. Esim. jotkut ajavat 10-18 v vanhalla autolla -> HTML 3.2 tuli 1997 joten nettisivut
jotka halutaan toimivan lähes kaikilla pitää olla tätä tasoa (Yhteiskunnalliset). Yritykset joilla ei ole yhteiskunnallista velvoitetta (eikä ole monopoli tai oligopoli- asemaa) voivat toki valita asiakkaansa ja tukea mitä haluavat.

Lue lisää

"HTML5 tuli standarksi 28. lokakuuta 2014 eli 3 vuotta sitten."

Aikaisemmin. Keskeiset asiat oli defactoa kauan sitten. Ja webbipuolella defactoa on se mikä toimii kaikissa tärkeimmissä selainmoottoreissa mitä eri alustoissa on. Se sitten kirjataan viralliseksi standardiksi vähän viiveellä.

HTML5 on ns. "umbrella term": https://en.wikipedia.org/wiki/Umbrella_term

Sillä käytännössä tarkoitetaan sitä, että selaimella on valmiudet ajaa sovellusten käyttöliittymiä asiakaspuolella. Ennen vanhaan kun se selain toimi sivulatausten varassa ja esitti tekstiä kuvia ja mitä palvelin tuotti. Se itse HTML5 kuvauskieli tuossa kokonaisuudessa merkitsee vähemmän. Kokonaisuus on paljon laajempi ja merkittävintä tuossa oli se, että jQuery aloitti kehityksen jonka seurauksena Javascriptistä tuli se standardi sinne käyttöliittymäpuolelle.

jQuery ilmestyi vuonna 2006.

"Esim. jotkut ajavat 10-18 v vanhalla autolla -> HTML 3.2 tuli 1997 joten nettisivut
jotka halutaan toimivan lähes kaikilla pitää olla tätä tasoa (Yhteiskunnalliset)."

Ei tietenkään pidä. Vanhin selaintekniikka joka toimii lähes kaikilla on tasoltaan Internet Explorer 10. Sitä on alle 4v ikäisissä Lumia puhelimissa.

Tosin kuin autot, tietokoneohjelmat ovat päivitettäviä ja ne oletuksena päivitetään. Turvallinen käyttö kun edellyttää sitä.

Ensiasekeleet ohjelmointiin kannattaa opetella työkalussa joka on yksinkertainen ja ei johdata mihinkään harhaoppeihin mikä johdattaa huonoon koodiin.

Scheme varmaankin olisi semmoinen mutta sillä kun on vähän vähemmän käyttöä tällä hetkellä työelämässä, että työelämää silmälläpitäen olisi sitten ennemmin vaikka Python.

Millos meinaat töihin mennä?