Lazarus muissakin käyttiksissä

Lazarusta voi hyödyntää monille vähän tuntemattomissa käyttiksissä
https://www.youtube.com/watch?v=yKGS6fcLLOE
eli miten VMWare:ta hyödyntäen luodaan Lazaruksella Amiga, AROS ja MorphOS ohjelmia
Ilmianna
Jaa

50 Vastausta



Noissa tuskin uusin html5/js toimii! Laite kirjo vain kasvaa!
Ilmianna
Jaa
"MWare:ta hyödyntäen luodaan Lazaruksella Amiga, AROS ja MorphOS ohjelmia"

Ja mitä näillä ohjelmissa sitten tehdään? bisnessii vai? :)
Kommentoi
Ilmianna
Jaa
6 VASTAUSTA:
Minkä vitun takia niillä pitäs tehdä "bisnessii", tahvo ?
Kommentoi
Ilmianna
Jaa
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
Kommentoi
Ilmianna
Jaa
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!
Kommentoi
Ilmianna
Jaa
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
Kommentoi
Ilmianna
Jaa
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)?
Kommentoi
Ilmianna
Jaa
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?
Kommentoi
Ilmianna
Jaa

Tästä on poistettu viesti sääntöjen vastaisena.

Kommentoi
Ilmianna
Jaa
+Lisää kommentti
"käyttöliittymä ei skaalaudu"
Mihinkä omakohtaiseen kokemukseen tuo väittämä nojaa?

Jos sinulla on jokin projekti, ja ongelmia saada lomakkeita skaalautumaan, kysy reilusti vaan, voin luultavasti antaa joitakin vinkkejä asian korjaamiseksi.
Kommentoi
Ilmianna
Jaa
29 VASTAUSTA:
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?
Kommentoi
Ilmianna
Jaa
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?
En ymmärrä sinua. Vaikuttaa Lazarus/Delphi vastaiselta propagandalta. En halua osallistua tullaiseen.
Kommentoi
Ilmianna
Jaa
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ä.
Kommentoi
Ilmianna
Jaa
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ä.
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?
Kommentoi
Ilmianna
Jaa
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ä.
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.
Kommentoi
Ilmianna
Jaa
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?
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.
Kommentoi
Ilmianna
Jaa
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.
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.
Kommentoi
Ilmianna
Jaa
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.
Ei tuo toimine. Käyttänee liian uutta teknologiaa jota alustalle ei saane. Ei HTML5 "taso" ole vielä kaikkialla käytössä.
Kommentoi
Ilmianna
Jaa
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.
Kommentoi
Ilmianna
Jaa
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.
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).
Kommentoi
Ilmianna
Jaa
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).
"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.
Kommentoi
Ilmianna
Jaa
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.
Eli antaa se kuvan et MS on huono valinta
Kommentoi
Ilmianna
Jaa
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.
Kommentoi
Ilmianna
Jaa
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ä...
Kommentoi
Ilmianna
Jaa
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.
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ää.
Kommentoi
Ilmianna
Jaa
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ä...
"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.
Kommentoi
Ilmianna
Jaa
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ää.
"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.
Kommentoi
Ilmianna
Jaa
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.
Javascript on vain välivaiheen ohjelmointikieli. Sovellukset alkavat pikku hiljaa siirtymään webassemblylle.
Kommentoi
Ilmianna
Jaa
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.
Kommentoi
Ilmianna
Jaa
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.
"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.
Kommentoi
Ilmianna
Jaa
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.
"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?
Kommentoi
Ilmianna
Jaa
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.
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.
Kommentoi
Ilmianna
Jaa
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.
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ä.
Kommentoi
Ilmianna
Jaa
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.
"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.
Kommentoi
Ilmianna
Jaa
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.
Tälläinen on jo ollut:
GNU Pascal
Ei saanut suosiota (esim. Pascal käyttäjiltä).
Kommentoi
Ilmianna
Jaa
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ä.
"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?
Kommentoi
Ilmianna
Jaa
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.
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.
Kommentoi
Ilmianna
Jaa
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.
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)!
Kommentoi
Ilmianna
Jaa
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)!
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ää.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Antaa ihmisten koodailla Lazaruksella jos haluaa, ei sen pitäisi olla keneltäkään pois. Skaalausongelmatkin on pois uusimmalla 1.8 versiolla. Lazarus on sentään ilmainen toisin kuin Delphi, sitä en tajua kuka Delphillä haluaa enään koodailla, kun on niin ylihinnoiteltu tuote.
Kommentoi
Ilmianna
Jaa
8 VASTAUSTA:
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.
Kommentoi
Ilmianna
Jaa
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.
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.
Kommentoi
Ilmianna
Jaa
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.
"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.
Kommentoi
Ilmianna
Jaa
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.
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
Kommentoi
Ilmianna
Jaa
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
Delphillä on voinut tehdä jo vuosia antero ja omppusoftia:
kuten tässä 3D kompanssi
https://www.youtube.com/watch?v=KXI1xQMLOZM
Kommentoi
Ilmianna
Jaa
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
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.
Kommentoi
Ilmianna
Jaa
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.
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.
Kommentoi
Ilmianna
Jaa
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.
"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ä.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Lazarus ja Delphi on hyviä ellei vieläkin parempia. Ensiaskeleet ohjelmointiin kannataa ehdottomasti suorittaa jommassa kummassa. Suosittelen lämpimästi jokaiselle ohjelmoinnista kiinnostuneelle.
Kommentoi
Ilmianna
Jaa
2 VASTAUSTA:
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.
Kommentoi
Ilmianna
Jaa
Millos meinaat töihin mennä?
Kommentoi
Ilmianna
Jaa
+Lisää kommentti

Vastaa alkuperäiseen viestiin

Lazarus muissakin käyttiksissä

Lazarusta voi hyödyntää monille vähän tuntemattomissa käyttiksissä
https://www.youtube.com/watch?v=yKGS6fcLLOE
eli miten VMWare:ta hyödyntäen luodaan Lazaruksella Amiga, AROS ja MorphOS ohjelmia

5000 merkkiä jäljellä

Peruuta