TWebBrowser / Lazarus

TFPHTTPClient ja https:// ?

Lähdekoodin noutaminen onnistuu mutta
TFPHTTPClient ja http:// eikö näin ?

Tuolla ei kummoista käyttöliittymää tehdä :D

"Kaikki muut osat ohjelmasta koodaat Lazaruksella.

Mutta se osa, joka tuota TWebBrowser -komponenttia tarvitsee, se koodataan Gambasilla."

Kerrohan mitä järkeä tässä on? Yleisesti ottaen ohjelmoinnissa pyritään tekemään nykytekniikalla asiat ja legacyt roikkuu siellä missä ei eroon pääse.

Eli jos kuvitellaan, että Pascalia joku haluaisi käyttää ja haluaisi käyttää IDE:nä Lazarusta niin ensisijaisen tärkeätä olisi että ei käytetä mitään visuaalisia LCL komponentteja vaan ennemmin integroidaan CEF siihen käyttöliittymiä varten, ja sitten käännetään käyttöliittymäkoodi vaikka tällä: https://github.com/kanaka/pascal.js/tree/master

Ja backend puolella sitten voi käyttää sitä FreePascal kääntäjää.

M-Kar kirjoitti:

"Kaikki muut osat ohjelmasta koodaat Lazaruksella.

Mutta se osa, joka tuota TWebBrowser -komponenttia tarvitsee, se koodataan Gambasilla."

Kerrohan mitä järkeä tässä on? Yleisesti ottaen ohjelmoinnissa pyritään tekemään nykytekniikalla asiat ja legacyt roikkuu siellä missä ei eroon pääse.

Eli jos kuvitellaan, että Pascalia joku haluaisi käyttää ja haluaisi käyttää IDE:nä Lazarusta niin ensisijaisen tärkeätä olisi että ei käytetä mitään visuaalisia LCL komponentteja vaan ennemmin integroidaan CEF siihen käyttöliittymiä varten, ja sitten käännetään käyttöliittymäkoodi vaikka tällä: https://github.com/kanaka/pascal.js/tree/master

Ja backend puolella sitten voi käyttää sitä FreePascal kääntäjää.

Lue lisää

Alla olevan kääntäminen ajettavaksi JavaScriptiksi, tuottaa tuolla tavalla tehtynä:
2778 rivisen JavaScripti tiedoston, joka sisältää 107300 merkkiä. Tätä ei kyllä kannata suositella kenellekkään.


program HelloWorld;
begin
WriteLn('Hello World!');
end

Tässä kannattaa huomioida että JavaScripti itsessään tarvitsee vain tämän:

console.log('Hello world!');

Ja tuohan ajetaa CTRL ALT T
node hello.js

Siinä tapauksessa että tallensit tuon rivin hello.js nimiseen tiedostoon.

M-Kar kirjoitti:

"Kaikki muut osat ohjelmasta koodaat Lazaruksella.

Mutta se osa, joka tuota TWebBrowser -komponenttia tarvitsee, se koodataan Gambasilla."

Kerrohan mitä järkeä tässä on? Yleisesti ottaen ohjelmoinnissa pyritään tekemään nykytekniikalla asiat ja legacyt roikkuu siellä missä ei eroon pääse.

Eli jos kuvitellaan, että Pascalia joku haluaisi käyttää ja haluaisi käyttää IDE:nä Lazarusta niin ensisijaisen tärkeätä olisi että ei käytetä mitään visuaalisia LCL komponentteja vaan ennemmin integroidaan CEF siihen käyttöliittymiä varten, ja sitten käännetään käyttöliittymäkoodi vaikka tällä: https://github.com/kanaka/pascal.js/tree/master

Ja backend puolella sitten voi käyttää sitä FreePascal kääntäjää.

Lue lisää

M-Kar seuraavan ohjeen kun kirjoitat tyylillä että saa vaikutelman sinun kokemuksestasi puhuvan, OTA SAA.ANA JA TESTAA SE ENSIN ITSE, tämä suomi 24 palsta on noita hai.ta-vitun ohjeitasi täynnä, mikään niistä ei ole toteuttamisen arvoinen ollut.

JOS ET ITSE KYKENE TESTAAMAAN OHJETTASI, kirjoita tyylillä, toimiskohan tuo, voiskohan tuota kokeilla, saiskohan tuosta jotain aikaan ja niin edespäin.

Turbo-Urpo kirjoitti:

Alla olevan kääntäminen ajettavaksi JavaScriptiksi, tuottaa tuolla tavalla tehtynä:
2778 rivisen JavaScripti tiedoston, joka sisältää 107300 merkkiä. Tätä ei kyllä kannata suositella kenellekkään.


program HelloWorld;
begin
WriteLn('Hello World!');
end

Tässä kannattaa huomioida että JavaScripti itsessään tarvitsee vain tämän:

console.log('Hello world!');

Ja tuohan ajetaa CTRL ALT T
node hello.js

Siinä tapauksessa että tallensit tuon rivin hello.js nimiseen tiedostoon.

Lue lisää

Löytyy näitä muitakin:

http://p2js.gelicon.biz/en
https://prezi.com/jqtrvvku_etm/pas2js-pascal-to-javascript-transpiler/

En ole sen tarkemmin vertaillut noita, otin ensimmäisen google hitin.

Tärkeintä tuollaisessa se että toimii oikein ja että olisi jatkuvuutta, että kyllähän kääntäjät tuottaa kokoaika parempaa koodia mitä pidempään kehitys jatkuu.

Turbo-Urpo kirjoitti:

M-Kar seuraavan ohjeen kun kirjoitat tyylillä että saa vaikutelman sinun kokemuksestasi puhuvan, OTA SAA.ANA JA TESTAA SE ENSIN ITSE, tämä suomi 24 palsta on noita hai.ta-vitun ohjeitasi täynnä, mikään niistä ei ole toteuttamisen arvoinen ollut.

JOS ET ITSE KYKENE TESTAAMAAN OHJETTASI, kirjoita tyylillä, toimiskohan tuo, voiskohan tuota kokeilla, saiskohan tuosta jotain aikaan ja niin edespäin.

Lue lisää

"M-Kar seuraavan ohjeen kun kirjoitat tyylillä että saa vaikutelman sinun kokemuksestasi puhuvan, OTA SAA.ANA JA TESTAA SE ENSIN ITSE, tämä suomi 24 palsta on noita hai.ta-vitun ohjeitasi täynnä, mikään niistä ei ole toteuttamisen arvoinen ollut."

Hyvinhän se toimii. En kyllä pidä sitä mitenkään ongelmana jos binäärin koko on vähän iso mutta saa vapaasti vertailla mikä miellyttää

Kun sitä kieltä saa käännettyä ja on jotenkin käytettävissä alustan rajapinta niin sehän oikeastaan riittää että pääsee tekemään... jotain.

Muista että en pidä Pascalia mitenkään hyvänä vaihtoehtona, että tuskin saa yhtä hyvää kuin vaikka sillä TypeScriptillä. Saa vapaasti todistaa vääräksi.

M-Kar kirjoitti:

Löytyy näitä muitakin:

http://p2js.gelicon.biz/en
https://prezi.com/jqtrvvku_etm/pas2js-pascal-to-javascript-transpiler/

En ole sen tarkemmin vertaillut noita, otin ensimmäisen google hitin.

Tärkeintä tuollaisessa se että toimii oikein ja että olisi jatkuvuutta, että kyllähän kääntäjät tuottaa kokoaika parempaa koodia mitä pidempään kehitys jatkuu.

Lue lisää

Tuo ensimmäinen on vain Windows käyttäjille, online esimerkki kääntäminen ei onnistunut, mutta tämä Pas2js kääntäjä saattas jo joitakin kiinnostaa: http://wiki.freepascal.org/pas2js

JavaScripti lisää Web-sivuille dynaamista toiminnallisuutta ja Pascal toimii useissa eri käyttöjärjestelmissä ja eri suorittimilla työpöytäsovellusten kääntäjänä, onko näitä tarve sekoittaa, kummallakin on oma selkeä roolinsa, eivätkä mielestäni kilpaile elintilasta keskenään.

Turbo-Urpo kirjoitti:

Tuo ensimmäinen on vain Windows käyttäjille, online esimerkki kääntäminen ei onnistunut, mutta tämä Pas2js kääntäjä saattas jo joitakin kiinnostaa: http://wiki.freepascal.org/pas2js

JavaScripti lisää Web-sivuille dynaamista toiminnallisuutta ja Pascal toimii useissa eri käyttöjärjestelmissä ja eri suorittimilla työpöytäsovellusten kääntäjänä, onko näitä tarve sekoittaa, kummallakin on oma selkeä roolinsa, eivätkä mielestäni kilpaile elintilasta keskenään.

Lue lisää

Javascript assembleriin verrattavissa oleva juttu. Kun tehdään ohjelma jollain kielellä, se käännetään Javascriptiksi. Selain toimii alustana käyttöliittymille ja sama käännetty ohjelma toimii joka paikassa.

C-kieli muistuttaa samaa POSIX puolella, että siihenkin usein käännetään korkeamman tason kielestä, ja se C-kieli on semmoinen korkean tason assembler. Sitten se C-käännetään prosessorin natiiviksi vielä. Näin on tehty monilla toteutuksilla kun ei

On olennaisen tärkeätä pyrkiä kääntämään sovellus Javascriptiksi kun on kyse käyttöliittymistä, koska sillä tavalla ohjelmat saadaan sellaisiksi, että toimivat asentamatta suoraan joka paikassa.

Lazarus epäonnistuu tässä koska pitää kääntää joka hemmetin käyttöjärjestelmässä erikseen se koodi, ja on vielä sen lisäksi käännös eri arkkitehtuuriversioille, ja tehdä asennuspaketit näistä ja niiden jakelu.

Tuollainen ei ole nykypäivää. Sitä kun katsos vaatimustaso nousee kokoaika. Graafisia käyttöliittymiä oli 80-luvulla yllin kyllin mutta 90-luvulle mentäessä siitä alkoi tulla vaatimus, että sovelluksen käyttöliittymän pitäisi olla graafinen eikä tekstitilassa oleva.

90-luvulla oli ihan ok, että sovellukset olivat käyttöjärjestelmä- ja arkkitehtuurikohtaisia mutta siihen tuli tekniikkaa mikä poisti sen riippuvuuden, joten 2000-luvulle alettiin vaatimaan siirrettävyyyttä ja saman ohjelman ajoa eri paikoissa. Ja pian sen jälkeen alettiin kyllästymään siihen, että on erikseen eri arkkitehtuuriversioita. Niihin aikoihin, joskus 2005-2006, Javascript alkoi kypsymään standardiksi. Se toimi vielä niin, että palvelin tuotti näkymät mutta Javascriptillä alkoi voida etenevissä määrin tehdä komponentteja korvaamaan niitä korvikkeita mitä aiemmin oli (Flash plugin, Java appletit, ActiveX kikkareet)

Tällä vuosikymmenellä se meni siihen, että Javascriptillä saa hoidettua koko sovelluksen käyttöliittymän kokonaisuudessaan että renderöintä ei tarvitse tehdä palvelimella.

Toisin sanoen, Pascal kelpaa työpöytäsovellusten kääntämiseen kunhan se kääntää Javascriptiksi.

Javascript on muuten tunnetusti vähän jarru siellä suorituskyvyssä mutta sillä ei ole niin väliä koska se on standardi. Se korvautuu pian WebAssemblyllä niin nostaa sitten suorituskykyä, ei tarvitse muuta kuin kääntää eri vivulla se sovellus.

Jos nyt tästä katsoit: https://nofile.io/f/d1SXvaZf8Tg/sliding-puzzle_0.1.0.zip

Niin kyllä se näkyvä käyttöliittymä on ihan sillä TypeScriptillä hoidettuna.

M-Kar kirjoitti:

Javascript assembleriin verrattavissa oleva juttu. Kun tehdään ohjelma jollain kielellä, se käännetään Javascriptiksi. Selain toimii alustana käyttöliittymille ja sama käännetty ohjelma toimii joka paikassa.

C-kieli muistuttaa samaa POSIX puolella, että siihenkin usein käännetään korkeamman tason kielestä, ja se C-kieli on semmoinen korkean tason assembler. Sitten se C-käännetään prosessorin natiiviksi vielä. Näin on tehty monilla toteutuksilla kun ei

On olennaisen tärkeätä pyrkiä kääntämään sovellus Javascriptiksi kun on kyse käyttöliittymistä, koska sillä tavalla ohjelmat saadaan sellaisiksi, että toimivat asentamatta suoraan joka paikassa.

Lazarus epäonnistuu tässä koska pitää kääntää joka hemmetin käyttöjärjestelmässä erikseen se koodi, ja on vielä sen lisäksi käännös eri arkkitehtuuriversioille, ja tehdä asennuspaketit näistä ja niiden jakelu.

Tuollainen ei ole nykypäivää. Sitä kun katsos vaatimustaso nousee kokoaika. Graafisia käyttöliittymiä oli 80-luvulla yllin kyllin mutta 90-luvulle mentäessä siitä alkoi tulla vaatimus, että sovelluksen käyttöliittymän pitäisi olla graafinen eikä tekstitilassa oleva.

90-luvulla oli ihan ok, että sovellukset olivat käyttöjärjestelmä- ja arkkitehtuurikohtaisia mutta siihen tuli tekniikkaa mikä poisti sen riippuvuuden, joten 2000-luvulle alettiin vaatimaan siirrettävyyyttä ja saman ohjelman ajoa eri paikoissa. Ja pian sen jälkeen alettiin kyllästymään siihen, että on erikseen eri arkkitehtuuriversioita. Niihin aikoihin, joskus 2005-2006, Javascript alkoi kypsymään standardiksi. Se toimi vielä niin, että palvelin tuotti näkymät mutta Javascriptillä alkoi voida etenevissä määrin tehdä komponentteja korvaamaan niitä korvikkeita mitä aiemmin oli (Flash plugin, Java appletit, ActiveX kikkareet)

Tällä vuosikymmenellä se meni siihen, että Javascriptillä saa hoidettua koko sovelluksen käyttöliittymän kokonaisuudessaan että renderöintä ei tarvitse tehdä palvelimella.

Toisin sanoen, Pascal kelpaa työpöytäsovellusten kääntämiseen kunhan se kääntää Javascriptiksi.

Javascript on muuten tunnetusti vähän jarru siellä suorituskyvyssä mutta sillä ei ole niin väliä koska se on standardi. Se korvautuu pian WebAssemblyllä niin nostaa sitten suorituskykyä, ei tarvitse muuta kuin kääntää eri vivulla se sovellus.

Jos nyt tästä katsoit: https://nofile.io/f/d1SXvaZf8Tg/sliding-puzzle_0.1.0.zip

Niin kyllä se näkyvä käyttöliittymä on ihan sillä TypeScriptillä hoidettuna.

Lue lisää

Monenko luulet osaavan järjestää työpöytäympäristönsä siihen kuntoon että pystyvät linkkaamasi peliä pelaamaan, epäilen että yksikään ei halua nähdä sitä vaivaa minkä joutuu tuon pelin toimimaan saattaminen vaatii, epäile että et edes itse ole asentanut Reactin JavaScript kirjastoja, joten et ole testannut peliä itsekkään.

Se on totta että peli on koostettu TypeScriptillä, mutta vaatii Reactin kirjastot, npm pakettihallinan, ja kukaties vielä muuta. minä en tarvittavaa ympäristöä ainakaan tällä hetkellä pistä pystyyn, pyytää aivan liian paljon levytilaa, jota tarvitaan Lazarus projektien käyttöön.

M-Kar kirjoitti:

Javascript assembleriin verrattavissa oleva juttu. Kun tehdään ohjelma jollain kielellä, se käännetään Javascriptiksi. Selain toimii alustana käyttöliittymille ja sama käännetty ohjelma toimii joka paikassa.

C-kieli muistuttaa samaa POSIX puolella, että siihenkin usein käännetään korkeamman tason kielestä, ja se C-kieli on semmoinen korkean tason assembler. Sitten se C-käännetään prosessorin natiiviksi vielä. Näin on tehty monilla toteutuksilla kun ei

On olennaisen tärkeätä pyrkiä kääntämään sovellus Javascriptiksi kun on kyse käyttöliittymistä, koska sillä tavalla ohjelmat saadaan sellaisiksi, että toimivat asentamatta suoraan joka paikassa.

Lazarus epäonnistuu tässä koska pitää kääntää joka hemmetin käyttöjärjestelmässä erikseen se koodi, ja on vielä sen lisäksi käännös eri arkkitehtuuriversioille, ja tehdä asennuspaketit näistä ja niiden jakelu.

Tuollainen ei ole nykypäivää. Sitä kun katsos vaatimustaso nousee kokoaika. Graafisia käyttöliittymiä oli 80-luvulla yllin kyllin mutta 90-luvulle mentäessä siitä alkoi tulla vaatimus, että sovelluksen käyttöliittymän pitäisi olla graafinen eikä tekstitilassa oleva.

90-luvulla oli ihan ok, että sovellukset olivat käyttöjärjestelmä- ja arkkitehtuurikohtaisia mutta siihen tuli tekniikkaa mikä poisti sen riippuvuuden, joten 2000-luvulle alettiin vaatimaan siirrettävyyyttä ja saman ohjelman ajoa eri paikoissa. Ja pian sen jälkeen alettiin kyllästymään siihen, että on erikseen eri arkkitehtuuriversioita. Niihin aikoihin, joskus 2005-2006, Javascript alkoi kypsymään standardiksi. Se toimi vielä niin, että palvelin tuotti näkymät mutta Javascriptillä alkoi voida etenevissä määrin tehdä komponentteja korvaamaan niitä korvikkeita mitä aiemmin oli (Flash plugin, Java appletit, ActiveX kikkareet)

Tällä vuosikymmenellä se meni siihen, että Javascriptillä saa hoidettua koko sovelluksen käyttöliittymän kokonaisuudessaan että renderöintä ei tarvitse tehdä palvelimella.

Toisin sanoen, Pascal kelpaa työpöytäsovellusten kääntämiseen kunhan se kääntää Javascriptiksi.

Javascript on muuten tunnetusti vähän jarru siellä suorituskyvyssä mutta sillä ei ole niin väliä koska se on standardi. Se korvautuu pian WebAssemblyllä niin nostaa sitten suorituskykyä, ei tarvitse muuta kuin kääntää eri vivulla se sovellus.

Jos nyt tästä katsoit: https://nofile.io/f/d1SXvaZf8Tg/sliding-puzzle_0.1.0.zip

Niin kyllä se näkyvä käyttöliittymä on ihan sillä TypeScriptillä hoidettuna.

Lue lisää

Niin Pascalissa "Javascript assembleriin verrattavissa oleva juttu" eli jos halutaan välttämättä liittää Javascriptiä Pascal koodin sekaan niin se tapahtuu aivan samoin kuin assembler koodikin.
Pascal koodin voi kääntää Javascript:ksi
http://wiki.freepascal.org/pas2js
https://prezi.com/jqtrvvku_etm/pas2js-pascal-to-javascript-transpiler/

Jos halutaan tehdä nopeata koodia (mikä on oletusarvo) niin Pascal kääntää koodin suoraan konekieliseksi (eli tekee ns exen).
Myös ristikääntäjää voidaan käyttää jolloin konekielinen koodi valmistuu toisenlaiseen käyttöjärjestelmään (ja prosessorille).

Turbo-Urpo kirjoitti:

Monenko luulet osaavan järjestää työpöytäympäristönsä siihen kuntoon että pystyvät linkkaamasi peliä pelaamaan, epäilen että yksikään ei halua nähdä sitä vaivaa minkä joutuu tuon pelin toimimaan saattaminen vaatii, epäile että et edes itse ole asentanut Reactin JavaScript kirjastoja, joten et ole testannut peliä itsekkään.

Se on totta että peli on koostettu TypeScriptillä, mutta vaatii Reactin kirjastot, npm pakettihallinan, ja kukaties vielä muuta. minä en tarvittavaa ympäristöä ainakaan tällä hetkellä pistä pystyyn, pyytää aivan liian paljon levytilaa, jota tarvitaan Lazarus projektien käyttöön.

Lue lisää

"Monenko luulet osaavan järjestää työpöytäympäristönsä siihen kuntoon että pystyvät linkkaamasi peliä pelaamaan"

Pienempi vaiva kuin Lazaruksen kanssa.

Tuon pelin kehitysympäristö on riippuvainen nodejs serveristä ja npm paketinhallinnasta, eli asennetaan esimerkiksi "apt-get install nodejs npm"

Sitten menee vaan kyseisen softan kansioon ja käskee siellä "npm install && npm run start" niin se asentaa tarvittavat riippuvuudet tähän node_modules -kansioon, kääntää ja käynnistää pelin.

Näinhän se npm paketinhallinta toimii, eli kasaa hierarkisesti riippuvuudet projekti kohtaisesti. Sehän ei siis sotke järjestelmää millään tavalla.


"epäile että et edes itse ole asentanut Reactin JavaScript kirjastoja, joten et ole testannut peliä itsekkään."

Minähän tein tuon joten tietysti olen ja React asentuu siinä muiden riippuvuuksien ohella kuten TypeScript kääntäjä. Et nähtävästi tunne npm paketinhallintaa mikä on ylivoimaisesti suosituin käyttöliittymäpuolella. Siinä on omat ongelmansa mutta se asia siinä toimii kivasti, että riittää kun on nodejs ja npm koneella niin voi ajella mistä vaan mitä versioita vain eri välineillä eri projekteissa.

"Se on totta että peli on koostettu TypeScriptillä, mutta vaatii Reactin kirjastot, npm pakettihallinan, ja kukaties vielä muuta. minä en tarvittavaa ympäristöä ainakaan tällä hetkellä pistä pystyyn, pyytää aivan liian paljon levytilaa, jota tarvitaan Lazarus projektien käyttöön."

Parisataa megaa levytilaa ei oikeasti ole mikään ongelma kun kehittäjillä on lähtökohtaisesti päätelaitteissa tavallisesti vähintään sadan gigan levyt jossa alusta ja työtila.

Mutta siinä on kuitenkin siistiä koodia että näytäs miten Lazaruksella saisi käyttöliittymän deklaratiiviseksi ja yhtä kätevästi?

Temppu pitäisi onnistua kun siihen laittaisi asianmukaisen layout komponentin, jonkun gridin johon latoisi pelitiili komponentteja joille syöttää tiedot ja mielellään CSS:nä, mutta epäilen kyllä että koodimäärä räjähtää tuollaisessa simppelissä asiassa Lazaruksen heikkouksien takia ja se sitten syynä siinäkin miksi tuo Lazarus peliesimerkki on niin huonosti tehty.

Mutta saa näyttää miten onnistuu homma Lazaruksella siistimmin, minä ainakin pidän sanani siitä että kun väitän pystyväni tekemään homman paremmin kuin Lazarus esimerkki niin silloin minä myös sen teen ja todistan väittämäni siitä, että Lazarus ei sovellu käyttöliittymäpuolelle. Se toimii selvästi paremmin IDE:nä mutta Lazaruksen LCL komponentit on roskaa.

Pas2JSa kirjoitti:

Niin Pascalissa "Javascript assembleriin verrattavissa oleva juttu" eli jos halutaan välttämättä liittää Javascriptiä Pascal koodin sekaan niin se tapahtuu aivan samoin kuin assembler koodikin.
Pascal koodin voi kääntää Javascript:ksi
http://wiki.freepascal.org/pas2js
https://prezi.com/jqtrvvku_etm/pas2js-pascal-to-javascript-transpiler/

Jos halutaan tehdä nopeata koodia (mikä on oletusarvo) niin Pascal kääntää koodin suoraan konekieliseksi (eli tekee ns exen).
Myös ristikääntäjää voidaan käyttää jolloin konekielinen koodi valmistuu toisenlaiseen käyttöjärjestelmään (ja prosessorille).

Lue lisää

"Niin Pascalissa "Javascript assembleriin verrattavissa oleva juttu" eli jos halutaan välttämättä liittää Javascriptiä Pascal koodin sekaan niin se tapahtuu aivan samoin kuin assembler koodikin."

Ei vaan käyttöliittymäpuolella koodi käännetään Javascriptiksi, eli Pascal pitäisi kääntää Javascriptiksi. Muuten sitä ei saa selainkomponenttiin.

"Jos halutaan tehdä nopeata koodia (mikä on oletusarvo) niin Pascal kääntää koodin suoraan konekieliseksi (eli tekee ns exen)."

Lazarus kääntää ohjelmia niin, että niissä on riippuvuus käyttöjärjestelmään ja laitearkkitehtuuriin ja on siis paskaa. Nykypäivän sovelluksilla kehitys on sitä, että saadaan käynnistettyä suoraan mistä vaan ilman asennuksia.

"Myös ristikääntäjää voidaan käyttää jolloin konekielinen koodi valmistuu toisenlaiseen käyttöjärjestelmään (ja prosessorille)."

Ja tuollaista paskaa ei haluta. Jos minä käytän sovellusta vaikka Ubuntulla ja sitten vaihdan koneen vaikka Android järjestelmällä varustetuksi niin en minä halua kääntää ja asentaa sovellusta uusiksi.

Suorituskyky ei oikeastaan ole mikään ongelma, kirjoittamani TypeScript sovellus toimii nopeasti.

Ja suorituskyky tietysti paranee kaiken aikaa, kokoajan kirjastoja ja kääntäjää optimoidaan, laitteet paranee, selainta optimoidaan, käyttöjärjestelmää optimoidaan kääntäjää optimoidaan ja kohta WebAssembly toimii joka paikassa. Suorituskyky ihan normaalisti kasvaa kaiken aikaa.

Eli siis on parasta valita paras tekniikka mihin suorituskyky riittää ja antaa sen suorituskyvyn vaan parantua vuodesta toiseen.

M-Kar kirjoitti:

"Niin Pascalissa "Javascript assembleriin verrattavissa oleva juttu" eli jos halutaan välttämättä liittää Javascriptiä Pascal koodin sekaan niin se tapahtuu aivan samoin kuin assembler koodikin."

Ei vaan käyttöliittymäpuolella koodi käännetään Javascriptiksi, eli Pascal pitäisi kääntää Javascriptiksi. Muuten sitä ei saa selainkomponenttiin.

"Jos halutaan tehdä nopeata koodia (mikä on oletusarvo) niin Pascal kääntää koodin suoraan konekieliseksi (eli tekee ns exen)."

Lazarus kääntää ohjelmia niin, että niissä on riippuvuus käyttöjärjestelmään ja laitearkkitehtuuriin ja on siis paskaa. Nykypäivän sovelluksilla kehitys on sitä, että saadaan käynnistettyä suoraan mistä vaan ilman asennuksia.

"Myös ristikääntäjää voidaan käyttää jolloin konekielinen koodi valmistuu toisenlaiseen käyttöjärjestelmään (ja prosessorille)."

Ja tuollaista paskaa ei haluta. Jos minä käytän sovellusta vaikka Ubuntulla ja sitten vaihdan koneen vaikka Android järjestelmällä varustetuksi niin en minä halua kääntää ja asentaa sovellusta uusiksi.

Suorituskyky ei oikeastaan ole mikään ongelma, kirjoittamani TypeScript sovellus toimii nopeasti.

Ja suorituskyky tietysti paranee kaiken aikaa, kokoajan kirjastoja ja kääntäjää optimoidaan, laitteet paranee, selainta optimoidaan, käyttöjärjestelmää optimoidaan kääntäjää optimoidaan ja kohta WebAssembly toimii joka paikassa. Suorituskyky ihan normaalisti kasvaa kaiken aikaa.

Eli siis on parasta valita paras tekniikka mihin suorituskyky riittää ja antaa sen suorituskyvyn vaan parantua vuodesta toiseen.

Lue lisää

M-KAR sinä et ole kirjoittanut yhtään mitään, ÄLÄ VALEHTELE.

Turbo-Urpo kirjoitti:

M-KAR sinä et ole kirjoittanut yhtään mitään, ÄLÄ VALEHTELE.

Olenhan. Esimerkiksi tämän: https://nofile.io/f/d1SXvaZf8Tg/sliding-puzzle_0.1.0.zip

Hienosti kääntyy Javascriptiksi ja on paljon siistimpi kuin tämä Lazaruksella tehty: http://wiki.freepascal.org/15-puzzle/fi

Tein omani omista itsekkäistäni syistä, eli siitä että tiesin TypeScriptin hyväksi työkaluksi mutta aikaisemmin se oli semmoista nysväämistä Reactin kanssa.Angularilla toimi heittämällä.

Työkalut Reactia varten kypsyivät paljon viime vuoden puolivälin jälkeen joten testasin ja keräsin kokemusta ja jaoin sen tuossa kun sinä aloit kitisemään pidemmälle ehtineille kehittäjille.

Sinulla ei ole muuta esittää kuin tuo joku Lazarus esimerkki. En tiedä onko se sinun tekemäsi vai jonkun muun Lazarus yhteisössä mutta sillä ei niin väliä ole koska tuo minun kirjoittamani TypeScript versio hoitaa homman siistimmin.

Näköjään löytyy muitakin Typescriptillä tehtyjä:

https://github.com/V381/Slide_Puzzle
https://github.com/apemanzilla/TilePuzzle

Tuo miun tekemäni näyttää hoitavan homman minimalistismmin eikä ole esimerkiksi solveria kuten toisessa.

Voisin vielä parantaa koodin laatua omastani helposti käyttämällä reduceria, poistamalla this:n käytön yms. mutta olkoot nyt noin.

M-Kar kirjoitti:

Olenhan. Esimerkiksi tämän: https://nofile.io/f/d1SXvaZf8Tg/sliding-puzzle_0.1.0.zip

Hienosti kääntyy Javascriptiksi ja on paljon siistimpi kuin tämä Lazaruksella tehty: http://wiki.freepascal.org/15-puzzle/fi

Tein omani omista itsekkäistäni syistä, eli siitä että tiesin TypeScriptin hyväksi työkaluksi mutta aikaisemmin se oli semmoista nysväämistä Reactin kanssa.Angularilla toimi heittämällä.

Työkalut Reactia varten kypsyivät paljon viime vuoden puolivälin jälkeen joten testasin ja keräsin kokemusta ja jaoin sen tuossa kun sinä aloit kitisemään pidemmälle ehtineille kehittäjille.

Sinulla ei ole muuta esittää kuin tuo joku Lazarus esimerkki. En tiedä onko se sinun tekemäsi vai jonkun muun Lazarus yhteisössä mutta sillä ei niin väliä ole koska tuo minun kirjoittamani TypeScript versio hoitaa homman siistimmin.

Näköjään löytyy muitakin Typescriptillä tehtyjä:

https://github.com/V381/Slide_Puzzle
https://github.com/apemanzilla/TilePuzzle

Tuo miun tekemäni näyttää hoitavan homman minimalistismmin eikä ole esimerkiksi solveria kuten toisessa.

Voisin vielä parantaa koodin laatua omastani helposti käyttämällä reduceria, poistamalla this:n käytön yms. mutta olkoot nyt noin.

Lue lisää

Tässä yksi Reactin komento:

it('renders without crashing', () => {
const div = document.createElement('div')
ReactDOM.render(<App />, div)
})

KERRO meille tietämättömille mitä siinä tehdään ?

Ja koska saamme nähdä ne korjaukset siihen Lazarus esimerkkiin jotka oli sinun mielestä kirjoitettu väärin.

Siinä on kolme asiaa, Tehdään DOM:n <div>, renderöidään App komponentti siihen. Tämä ajetaan testitapauksessa "renderds without crashing" että voidaan testata failaako ohjelma.

Eli ei siis tarvitse käynnistää ohjelmaa selaimessa vaan voi testata noin.

Siinä nyt ei ole enempää kuin tuo yksi testi, eihän sitä ohjelmia näin normaalisti tehdä mutta tämä kun oli niin simppeli ja olin laiskapaska niin tein ilman testejä.

Saahan noita lisättyä tuohon helposti, esim. tekee testin jossa yhtä siirtoa vailla valmis pelilauta tehdään valmiiksi että muuttuuko ohjelman "win" oikeaan tilaan ja vaihtuuko tiilien väri vihreäksi. Siis ihan vaan yksi simppeli testi.

"Ja koska saamme nähdä ne korjaukset siihen Lazarus esimerkkiin jotka oli sinun mielestä kirjoitettu väärin."

Minä väitän, että Lazarus on paska käyttöliittymien teossa enkä usko että sillä ei saa tehtyä yhtä siististi. Hölmöydet näkyy kun vertaa minun tekemään versioon. Minun versiossa ei ole mitään typeriä laskuja tiilien asemointiin.

Lazaruksessa voisi tehdä oman komponentin siihen peli tiilelle ja käyttää jotain grid layout komponenttia mutta näytähän sinä se jos sinun mielestäsi Lazarus kelpaa käyttöliittymien tekemiseen. Sinun mielestäsihän se esimerkki oli hyvä mutta minusta se koodi on laadultaan huonoa.

M-Kar kirjoitti:

Siinä on kolme asiaa, Tehdään DOM:n <div>, renderöidään App komponentti siihen. Tämä ajetaan testitapauksessa "renderds without crashing" että voidaan testata failaako ohjelma.

Eli ei siis tarvitse käynnistää ohjelmaa selaimessa vaan voi testata noin.

Siinä nyt ei ole enempää kuin tuo yksi testi, eihän sitä ohjelmia näin normaalisti tehdä mutta tämä kun oli niin simppeli ja olin laiskapaska niin tein ilman testejä.

Saahan noita lisättyä tuohon helposti, esim. tekee testin jossa yhtä siirtoa vailla valmis pelilauta tehdään valmiiksi että muuttuuko ohjelman "win" oikeaan tilaan ja vaihtuuko tiilien väri vihreäksi. Siis ihan vaan yksi simppeli testi.

"Ja koska saamme nähdä ne korjaukset siihen Lazarus esimerkkiin jotka oli sinun mielestä kirjoitettu väärin."

Minä väitän, että Lazarus on paska käyttöliittymien teossa enkä usko että sillä ei saa tehtyä yhtä siististi. Hölmöydet näkyy kun vertaa minun tekemään versioon. Minun versiossa ei ole mitään typeriä laskuja tiilien asemointiin.

Lazaruksessa voisi tehdä oman komponentin siihen peli tiilelle ja käyttää jotain grid layout komponenttia mutta näytähän sinä se jos sinun mielestäsi Lazarus kelpaa käyttöliittymien tekemiseen. Sinun mielestäsihän se esimerkki oli hyvä mutta minusta se koodi on laadultaan huonoa.

Lue lisää

No niin nyt alkaa jo olemaan jotain itua tuossa kirjoituksessa, lazaruksen osalta, eli siinä olikin vain mielipidenäkemyksestä kysymys eikä virheestä. Jokainen voi olla mitä mieltä tahaansa, se asia oli siinä.

Mutta selitys tuon Reactin osilta ei pidä paikkaansa, joten tuo selitys vain vahvistaa käsitystäni sinun Reactin soveltamisen kyvyistä. En yllättynyt yhtään tästä selityksestä. Jos lähtökohta olisi se ettet olisi vielä sanonut osaavasi, olisin sijoittanut tähän mielestäni ihan hyvä kuvauksen tuon it(); funktion sisällöstä, nyt en sitä tee.

Turbo-Urpo kirjoitti:

No niin nyt alkaa jo olemaan jotain itua tuossa kirjoituksessa, lazaruksen osalta, eli siinä olikin vain mielipidenäkemyksestä kysymys eikä virheestä. Jokainen voi olla mitä mieltä tahaansa, se asia oli siinä.

Mutta selitys tuon Reactin osilta ei pidä paikkaansa, joten tuo selitys vain vahvistaa käsitystäni sinun Reactin soveltamisen kyvyistä. En yllättynyt yhtään tästä selityksestä. Jos lähtökohta olisi se ettet olisi vielä sanonut osaavasi, olisin sijoittanut tähän mielestäni ihan hyvä kuvauksen tuon it(); funktion sisällöstä, nyt en sitä tee.

Lue lisää

"No niin nyt alkaa jo olemaan jotain itua tuossa kirjoituksessa, lazaruksen osalta, eli siinä olikin vain mielipidenäkemyksestä kysymys eikä virheestä."

Kyse on siitä soveltuuko Lazarus käyttöliittymäohjelmointiin vai ei. Ja selvästikään ei sovellu jos sinulle tuottaa vaikeuksia todistaa se kun siellä koodissa on sotkua.

"Mutta selitys tuon Reactin osilta ei pidä paikkaansa, joten tuo selitys vain vahvistaa käsitystäni sinun Reactin soveltamisen kyvyistä. En yllättynyt yhtään tästä selityksestä. Jos lähtökohta olisi se ettet olisi vielä sanonut osaavasi, olisin sijoittanut tähän mielestäni ihan hyvä kuvauksen tuon it(); funktion sisällöstä, nyt en sitä tee."

Väärin meni. It -ei kuulu Reactiin. Se kuuluu Jestiin. Eli siis et tiedä mistä puhut.

M-Kar kirjoitti:

"No niin nyt alkaa jo olemaan jotain itua tuossa kirjoituksessa, lazaruksen osalta, eli siinä olikin vain mielipidenäkemyksestä kysymys eikä virheestä."

Kyse on siitä soveltuuko Lazarus käyttöliittymäohjelmointiin vai ei. Ja selvästikään ei sovellu jos sinulle tuottaa vaikeuksia todistaa se kun siellä koodissa on sotkua.

"Mutta selitys tuon Reactin osilta ei pidä paikkaansa, joten tuo selitys vain vahvistaa käsitystäni sinun Reactin soveltamisen kyvyistä. En yllättynyt yhtään tästä selityksestä. Jos lähtökohta olisi se ettet olisi vielä sanonut osaavasi, olisin sijoittanut tähän mielestäni ihan hyvä kuvauksen tuon it(); funktion sisällöstä, nyt en sitä tee."

Väärin meni. It -ei kuulu Reactiin. Se kuuluu Jestiin. Eli siis et tiedä mistä puhut.

Lue lisää

''''''''''''
jos sinulle tuottaa vaikeuksia todistaa se kun siellä koodissa on sotkua.
''''''''''''

Mitä hittoa sinä sekoilet, minä en missään vaiheessa ole sanonut siellä olevan sotkua, se on erittäin hyvä esimerkki ja aivan virheettömästi tehty. Miksi minun pitää todistaa sellaista mitä en ole sanonut ?

Sinähän teet itsesi naurunalaiseksi tuollaisella, nyt viimeistään jokainen huomaa sinun vain asiattomasti vain vittuilevan, kun tieto taito ei mihinkään riitä. Oletko nyt itseesi tyytyväinen ?

Turbo-Urpo kirjoitti:

''''''''''''
jos sinulle tuottaa vaikeuksia todistaa se kun siellä koodissa on sotkua.
''''''''''''

Mitä hittoa sinä sekoilet, minä en missään vaiheessa ole sanonut siellä olevan sotkua, se on erittäin hyvä esimerkki ja aivan virheettömästi tehty. Miksi minun pitää todistaa sellaista mitä en ole sanonut ?

Sinähän teet itsesi naurunalaiseksi tuollaisella, nyt viimeistään jokainen huomaa sinun vain asiattomasti vain vittuilevan, kun tieto taito ei mihinkään riitä. Oletko nyt itseesi tyytyväinen ?

Lue lisää

"Mitä hittoa sinä sekoilet, minä en missään vaiheessa ole sanonut siellä olevan sotkua"

Et niin. Minä sanoin ja todistin sen.

"se on erittäin hyvä esimerkki"

No siinä on edelleenkin sotkettu logiikkaa käyttöliittymän tekemisessä. Minun toteutuksessani ei ole.

"Miksi minun pitää todistaa sellaista mitä en ole sanonut ?"

Ei se niin mene. Minä sanon jotain ja jos vänkäät vastaan olemalla eri mieltä niin se tarvitsee todistamista. Eli ollaanko siis yhtä mieltä siitä, että Lazarus on paska käyttöliittymäohjelmoinnissa kun tuo sinun mielestäsi hyvä esimerkki sisältää turhaa logiikkaa käyttöliittymän esittämistä varten?

"Sinähän teet itsesi naurunalaiseksi tuollaisella, nyt viimeistään jokainen huomaa sinun vain asiattomasti vain vittuilevan, kun tieto taito ei mihinkään riitä. Oletko nyt itseesi tyytyväinen ?"

Siis minullahan se tieto ja taito todistettavasti riittää, linkitin paremmin tehtyyn versioon minkä minä olin tehnyt. Sinulla taas ei ole esittää mitään. Ei koodia, olet esittänyt huuhaa väitteitä, että käyttöliittymät muka tehtäisiin enimmäkseen staattisesti, It -kuului mukamas Reactiin, piti selittää mitä tarkoittaa deklaratiivinen..

Minusta on kummallista että intät kokoajan vastaan ja sitten joutuu selittämään alkeita.

M-Kar kirjoitti:

"Mitä hittoa sinä sekoilet, minä en missään vaiheessa ole sanonut siellä olevan sotkua"

Et niin. Minä sanoin ja todistin sen.

"se on erittäin hyvä esimerkki"

No siinä on edelleenkin sotkettu logiikkaa käyttöliittymän tekemisessä. Minun toteutuksessani ei ole.

"Miksi minun pitää todistaa sellaista mitä en ole sanonut ?"

Ei se niin mene. Minä sanon jotain ja jos vänkäät vastaan olemalla eri mieltä niin se tarvitsee todistamista. Eli ollaanko siis yhtä mieltä siitä, että Lazarus on paska käyttöliittymäohjelmoinnissa kun tuo sinun mielestäsi hyvä esimerkki sisältää turhaa logiikkaa käyttöliittymän esittämistä varten?

"Sinähän teet itsesi naurunalaiseksi tuollaisella, nyt viimeistään jokainen huomaa sinun vain asiattomasti vain vittuilevan, kun tieto taito ei mihinkään riitä. Oletko nyt itseesi tyytyväinen ?"

Siis minullahan se tieto ja taito todistettavasti riittää, linkitin paremmin tehtyyn versioon minkä minä olin tehnyt. Sinulla taas ei ole esittää mitään. Ei koodia, olet esittänyt huuhaa väitteitä, että käyttöliittymät muka tehtäisiin enimmäkseen staattisesti, It -kuului mukamas Reactiin, piti selittää mitä tarkoittaa deklaratiivinen..

Minusta on kummallista että intät kokoajan vastaan ja sitten joutuu selittämään alkeita.

Lue lisää

Älä viitsi valehdella, sinä et ole mitään tehnyt, koska et osaa. Toisten tekemien ohjelmien omakseen väittäminen hiton iljettävää.

Turbo-Urpo kirjoitti:

Älä viitsi valehdella, sinä et ole mitään tehnyt, koska et osaa. Toisten tekemien ohjelmien omakseen väittäminen hiton iljettävää.

Tietysti osaan. Olen ohjelmoinut 27v että tunnen kyllä alani enkä väitä kenenkään muun tekemää omakseni.

Muista että minä olen se ammattilainen ja sinä olet se pelle mille pitää selittää että testframework ei kuulu Reactiin tai mitä on deklaratiivinen ohjelmointi.

Jos tietäisit jotain niin et kysyisi perusasioiden merkitystä. Mene vaikka kouluun tai jotain.

M-Kar kirjoitti:

Tietysti osaan. Olen ohjelmoinut 27v että tunnen kyllä alani enkä väitä kenenkään muun tekemää omakseni.

Muista että minä olen se ammattilainen ja sinä olet se pelle mille pitää selittää että testframework ei kuulu Reactiin tai mitä on deklaratiivinen ohjelmointi.

Jos tietäisit jotain niin et kysyisi perusasioiden merkitystä. Mene vaikka kouluun tai jotain.

Lue lisää

Voisit rauhoittua välillä , minä olen huomannut että olet ohjelmoinut vähintäänkin tuo 27 vuotta.

M-Kar kirjoitti:

Tietysti osaan. Olen ohjelmoinut 27v että tunnen kyllä alani enkä väitä kenenkään muun tekemää omakseni.

Muista että minä olen se ammattilainen ja sinä olet se pelle mille pitää selittää että testframework ei kuulu Reactiin tai mitä on deklaratiivinen ohjelmointi.

Jos tietäisit jotain niin et kysyisi perusasioiden merkitystä. Mene vaikka kouluun tai jotain.

Lue lisää

Hei, mutta eihän tuo näytä hyvältä, laitetaan 10 vuotta lisää, olet siis ohjelmointu 37 vuotta, onko nyt hyvä ?

Turbo-Urpo kirjoitti:

No niin nyt alkaa jo olemaan jotain itua tuossa kirjoituksessa, lazaruksen osalta, eli siinä olikin vain mielipidenäkemyksestä kysymys eikä virheestä. Jokainen voi olla mitä mieltä tahaansa, se asia oli siinä.

Mutta selitys tuon Reactin osilta ei pidä paikkaansa, joten tuo selitys vain vahvistaa käsitystäni sinun Reactin soveltamisen kyvyistä. En yllättynyt yhtään tästä selityksestä. Jos lähtökohta olisi se ettet olisi vielä sanonut osaavasi, olisin sijoittanut tähän mielestäni ihan hyvä kuvauksen tuon it(); funktion sisällöstä, nyt en sitä tee.

Lue lisää

Niin. Riippuu siitä, mitä kukin arvottaa ja miten.

1. perinteinen malli: (Delphi, FreePascal Lazarus)

Sama ohjelma hoitaa niin taustatoiminnot kuin paikallisen käyttöliittymänkin (Delphi: VCL, Lazarus: LCL).

Muistinkulutus: Delphi: pieni
Lazarus: keskinkertainen

JOS ajetaan 32-bit sovellusta 64-bit käyttöjärjestelmässä, niin käyttöjärjestelmän oma 32/64 -bit "tulkkauskerros" aktivoidaan. Varsinkin windowsissa tämä lisää muistinkulutusta vain vähän, M-Karin päinvastaisista väitteistä huolimatta. Linuxissa saattaa listätä enemmän.

2. M-Karin kannattama malli:

Taustatehtävät erillisellä koneella, ei paikallista käyttöliittymää lainkaan, vaan käyttöliittymä toteutetaan web -selaimessa.

Tämä se vasta muistia kuluttaakin, ja PALJON !

Sama käyttöliittymä, mikä LCL tai VCL -toteutettuna kuluttaisi muistia vain vähän, kuluttaa HTML5 CSS JavaScript -virityksenä muistia aivan tuhottomasti.

Tämä "kaikki web -selaimeen" -tyyli lisää muistinkulutusta vähintäänkin monikymmenkertaiseksi.

Selain myös tuhlaa CPU -aikaa minkä ehtii.

Miksi luulette, että Androidissa joka yritys haluaa kehittää oman sovelluksen sen sijaan, että tekisivät vain web -sivun (HTML5 CSS JavaScript) ?

Luultavasti siksi, että jos yritys tarjoaisi haluamansa asiakkaiden itsepalvelut tuolla HTML5 CSS JavaScript -tyylillä, niin saisiva valituksia siitä, että mobiililaitteista loppuu sekä RAM -muisti että akku. (mobiililaitteissa kun tuhlaileva CPU:n käyttö lisää virrankulutusta siihen malliin, ettei akku kovin kauaa riitä).

TOKI myös se Android -sovellus pitäisi koodata kunnolla, sillä huolimattoman koodarin jäljiltä törmätään myös tuhlailevaan CPU:n käyttöön.

Osa koodaajista ehkä tekee tuossa suhteessa laadukasta työtä, osa ei.


Tuo M-Karin kannattama malli ainakin lisää RAM -muistipalikoiden ja nopeiden, mutta vähän virtaa kuluttavien prosessorien kysyntää.

Valitettavasti vain prosessorien osalta: nopeaa ja vähän virtaa kuluttavaa CPU:ta ei yleensä saa samassa tuotteessa. Kun nopeutta tavoitellaan kellotaajuuden nostolla, ja se taas suoraan lisää virrankulutusta.

IT_alanMuotiTuhlaaCpuRam kirjoitti:

Niin. Riippuu siitä, mitä kukin arvottaa ja miten.

1. perinteinen malli: (Delphi, FreePascal Lazarus)

Sama ohjelma hoitaa niin taustatoiminnot kuin paikallisen käyttöliittymänkin (Delphi: VCL, Lazarus: LCL).

Muistinkulutus: Delphi: pieni
Lazarus: keskinkertainen

JOS ajetaan 32-bit sovellusta 64-bit käyttöjärjestelmässä, niin käyttöjärjestelmän oma 32/64 -bit "tulkkauskerros" aktivoidaan. Varsinkin windowsissa tämä lisää muistinkulutusta vain vähän, M-Karin päinvastaisista väitteistä huolimatta. Linuxissa saattaa listätä enemmän.

2. M-Karin kannattama malli:

Taustatehtävät erillisellä koneella, ei paikallista käyttöliittymää lainkaan, vaan käyttöliittymä toteutetaan web -selaimessa.

Tämä se vasta muistia kuluttaakin, ja PALJON !

Sama käyttöliittymä, mikä LCL tai VCL -toteutettuna kuluttaisi muistia vain vähän, kuluttaa HTML5 CSS JavaScript -virityksenä muistia aivan tuhottomasti.

Tämä "kaikki web -selaimeen" -tyyli lisää muistinkulutusta vähintäänkin monikymmenkertaiseksi.

Selain myös tuhlaa CPU -aikaa minkä ehtii.

Miksi luulette, että Androidissa joka yritys haluaa kehittää oman sovelluksen sen sijaan, että tekisivät vain web -sivun (HTML5 CSS JavaScript) ?

Luultavasti siksi, että jos yritys tarjoaisi haluamansa asiakkaiden itsepalvelut tuolla HTML5 CSS JavaScript -tyylillä, niin saisiva valituksia siitä, että mobiililaitteista loppuu sekä RAM -muisti että akku. (mobiililaitteissa kun tuhlaileva CPU:n käyttö lisää virrankulutusta siihen malliin, ettei akku kovin kauaa riitä).

TOKI myös se Android -sovellus pitäisi koodata kunnolla, sillä huolimattoman koodarin jäljiltä törmätään myös tuhlailevaan CPU:n käyttöön.

Osa koodaajista ehkä tekee tuossa suhteessa laadukasta työtä, osa ei.


Tuo M-Karin kannattama malli ainakin lisää RAM -muistipalikoiden ja nopeiden, mutta vähän virtaa kuluttavien prosessorien kysyntää.

Valitettavasti vain prosessorien osalta: nopeaa ja vähän virtaa kuluttavaa CPU:ta ei yleensä saa samassa tuotteessa. Kun nopeutta tavoitellaan kellotaajuuden nostolla, ja se taas suoraan lisää virrankulutusta.

Lue lisää

Verkkosovellukset ei korvaa työpöytäsovelluksia, tietokoneet ei muutu päätteiksi, ikuiset haaveilijat, mahdottomien asioiden uneksijat, HERÄTKÄÄ TODELLISUUTEEN. Keksikää mieluummin tuulimyllynlämmittäjä, niin ei mene aika hukkaan.

Lazaruksen mollaamisella saadaan vain vahinkoa aikaan.

IT_alanMuotiTuhlaaCpuRam kirjoitti:

Niin. Riippuu siitä, mitä kukin arvottaa ja miten.

1. perinteinen malli: (Delphi, FreePascal Lazarus)

Sama ohjelma hoitaa niin taustatoiminnot kuin paikallisen käyttöliittymänkin (Delphi: VCL, Lazarus: LCL).

Muistinkulutus: Delphi: pieni
Lazarus: keskinkertainen

JOS ajetaan 32-bit sovellusta 64-bit käyttöjärjestelmässä, niin käyttöjärjestelmän oma 32/64 -bit "tulkkauskerros" aktivoidaan. Varsinkin windowsissa tämä lisää muistinkulutusta vain vähän, M-Karin päinvastaisista väitteistä huolimatta. Linuxissa saattaa listätä enemmän.

2. M-Karin kannattama malli:

Taustatehtävät erillisellä koneella, ei paikallista käyttöliittymää lainkaan, vaan käyttöliittymä toteutetaan web -selaimessa.

Tämä se vasta muistia kuluttaakin, ja PALJON !

Sama käyttöliittymä, mikä LCL tai VCL -toteutettuna kuluttaisi muistia vain vähän, kuluttaa HTML5 CSS JavaScript -virityksenä muistia aivan tuhottomasti.

Tämä "kaikki web -selaimeen" -tyyli lisää muistinkulutusta vähintäänkin monikymmenkertaiseksi.

Selain myös tuhlaa CPU -aikaa minkä ehtii.

Miksi luulette, että Androidissa joka yritys haluaa kehittää oman sovelluksen sen sijaan, että tekisivät vain web -sivun (HTML5 CSS JavaScript) ?

Luultavasti siksi, että jos yritys tarjoaisi haluamansa asiakkaiden itsepalvelut tuolla HTML5 CSS JavaScript -tyylillä, niin saisiva valituksia siitä, että mobiililaitteista loppuu sekä RAM -muisti että akku. (mobiililaitteissa kun tuhlaileva CPU:n käyttö lisää virrankulutusta siihen malliin, ettei akku kovin kauaa riitä).

TOKI myös se Android -sovellus pitäisi koodata kunnolla, sillä huolimattoman koodarin jäljiltä törmätään myös tuhlailevaan CPU:n käyttöön.

Osa koodaajista ehkä tekee tuossa suhteessa laadukasta työtä, osa ei.


Tuo M-Karin kannattama malli ainakin lisää RAM -muistipalikoiden ja nopeiden, mutta vähän virtaa kuluttavien prosessorien kysyntää.

Valitettavasti vain prosessorien osalta: nopeaa ja vähän virtaa kuluttavaa CPU:ta ei yleensä saa samassa tuotteessa. Kun nopeutta tavoitellaan kellotaajuuden nostolla, ja se taas suoraan lisää virrankulutusta.

Lue lisää

"1. perinteinen malli: (Delphi, FreePascal Lazarus)

Sama ohjelma hoitaa niin taustatoiminnot kuin paikallisen käyttöliittymänkin (Delphi: VCL, Lazarus: LCL)."

Eli ohjaa spagettikoodiin joka kuormittaa tarpeettomasti päätelaitetta ja tietojärjestelmä alkaa rakentua niin, että datat on levällään ympäri päätelaitteita eikä keskitetysti. Huomaa että tarkoitan kuormituksella tietenkin IOPS:eja.

Huomioi se, että tuo ei edes ole "perinteinen" vaan joku 80-luvun hömpötys. 70-luvun suurkoneissa ja minikoneissa pidettiin datat keskitettynä. Sitä vaan 80-luvulla graafiset käyttöliittymät, halvat koneet ja kalliit yhteydet ohjasi joksikin aikaa tekemään suurta osaa ohjelmia typerästi.

"JOS ajetaan 32-bit sovellusta 64-bit käyttöjärjestelmässä, niin käyttöjärjestelmän oma 32/64 -bit "tulkkauskerros" aktivoidaan. Varsinkin windowsissa tämä lisää muistinkulutusta vain vähän, M-Karin päinvastaisista väitteistä huolimatta. Linuxissa saattaa listätä enemmän."

Jos ajossa on yksikin 32-bittinen sovellus, se aktivoituu. Joskus Windows Vista aikoina oli yleensä hankalaa saada siivottua kaikki 32-bittinen pois ja IE:ssä tuo tarvitsi oman nysvänsä mutta siinä kohtaa kun ihan kaikki 32-bittinen oli poissa, muistin kulutus selvästi. Yksikin 32-bittinen pökäle aiheuttaa monien yhteensopivuuskirjastojen latauksen.

Sen lisäksi joku Delphi tai Lazarus raahaa mukana omaa kirjastokoodia, että sovellus rohmuaa muistia.

"2. M-Karin kannattama malli:

Taustatehtävät erillisellä koneella, ei paikallista käyttöliittymää lainkaan, vaan käyttöliittymä toteutetaan web -selaimessa.

Tämä se vasta muistia kuluttaakin, ja PALJON !"

Siis selaimessa voidaan ajaa paikallista käyttöliittymää. Toki erikoistilanteisiin voidaan tehdä natiivikäyttöliittymä mikä ei käytä selainta vaan on Windowsissa vaikka WinRT tai Ubuntussa vaikka GTK rajapinnoille tehtynä.

Käyttämällä järjestelmän natiivia tai selainta, säästää muistia paljon kun ei tarvitse raahata mukana lisäkirjastoja.

"Tämä "kaikki web -selaimeen" -tyyli lisää muistinkulutusta vähintäänkin monikymmenkertaiseksi."

Ei kuluta. On mahdollista itseasiassa tehdä päätelaite jossa ei ole muuta kuin selain ja kaikki muu roina voidaan riisua pois muistia kuluttamasta.

"Selain myös tuhlaa CPU -aikaa minkä ehtii."

Ennen kulutti aika paljon. IE7 oli hyvin hidas. Sen jälkeen CPU-ajan käyttö selaimella ei ole ollut ongelma, ja hyötysuhde parantunut rajusti. Nykyisellään taitaa olla 10x suurempi CPU-kuormitus kuin natiivilla (en ole mitannut viimeaikoina onko paljon parantunut) mutta se korjaantuu lähikuukausina Webassemblyn myötä. Itseasiassa sitä voi jo käyttää kun paketoi hybridisovelluksen.

"Miksi luulette, että Androidissa joka yritys haluaa kehittää oman sovelluksen sen sijaan, että tekisivät vain web -sivun (HTML5 CSS JavaScript) ?"

Koska Androidia käytetään paljon taskukoneissa ja näiden selaintekniikka ja suorituskyky tulee noin 6v jäljessä pöytäkoneita. Tästä syystähän natiivisovelluksia on tehty lähes täysin vain Androidille ja iOS:lle ja kun Windowsia vaikka näkee lähinnä pöytäkoneissa ja läppäreissä niin niissä on aikoja sitten luovuttu natiisisovellusten tekemisestä lähes täysin kun voi käyttää standardia.

"Tuo M-Karin kannattama malli ainakin lisää RAM -muistipalikoiden ja nopeiden, mutta vähän virtaa kuluttavien prosessorien kysyntää."

Siis se vähentää muistin tarvetta. Toistaiseksi nostanut CPU kuormitusta mutta unohdat nähtävästi sen asian, että piirien kehityksessä hyötysuhde paranee kaikista eniten prosessointikyvyssä (näin ollut vuosikymmeniä), eli GPU:n ja CPU:n hyötysuhde siellä on parantunut kaiken aikaa ja alustan toteutusten laatu paranee niin ikään myös joten sillä CPU kuormituksella ei oikeasti ole mitään väliä. Näinhän se oli esimerkiksi Javan kanssa aikoinaan, että kuormitti paljon mutta mitä väliä kun alusta ja koneet nopeutuu kaiken aikaa?

Voi surutta alkaa tekemän vaikka sovellusta nyt joka toimisi luokattoman hitaasti nykyisillä laitteilla ja softa-alustalla mutta kun sovellus on valmis niin suorituskyky riittää ja hyötysuhde paranee kaiken aikaa vaikka kehittäjä ei tekisi mitään muuta kuin päivittäisi alustaa. Tästä syystä softa kannattaakin tehdä tekniikalla mille on pisin jatkuvuus ja siistein rakenne että saadaan täysi hyöty siitä kun suorituskyky paranee itsekseen tyyliin 12v eteenpäin. Sitten onkin tavallisesti aika uudelleenkirjoittaa paremmilla välineillä.

Java hyvä esimerkki tuosta, että sehän oli usein erinomainen valinta silloin vuosien 1996-2009 välillä desktop sovelluksiin kunnes aika meni siitä ohitse, ja vanhat aikoinaan tehdyt Java 6 sovellukset on vielä asennettavissa toimimaan hyvän taaksepäinyhteensopivuuden ansiosta ja toimivat varmaan ilman muutoksia Java 9:llä, ja ovat nopeutuneet kaiken aikaa, aina sieltä vuodesta 1996 saakka.

IT_alanMuotiTuhlaaCpuRam kirjoitti:

Niin. Riippuu siitä, mitä kukin arvottaa ja miten.

1. perinteinen malli: (Delphi, FreePascal Lazarus)

Sama ohjelma hoitaa niin taustatoiminnot kuin paikallisen käyttöliittymänkin (Delphi: VCL, Lazarus: LCL).

Muistinkulutus: Delphi: pieni
Lazarus: keskinkertainen

JOS ajetaan 32-bit sovellusta 64-bit käyttöjärjestelmässä, niin käyttöjärjestelmän oma 32/64 -bit "tulkkauskerros" aktivoidaan. Varsinkin windowsissa tämä lisää muistinkulutusta vain vähän, M-Karin päinvastaisista väitteistä huolimatta. Linuxissa saattaa listätä enemmän.

2. M-Karin kannattama malli:

Taustatehtävät erillisellä koneella, ei paikallista käyttöliittymää lainkaan, vaan käyttöliittymä toteutetaan web -selaimessa.

Tämä se vasta muistia kuluttaakin, ja PALJON !

Sama käyttöliittymä, mikä LCL tai VCL -toteutettuna kuluttaisi muistia vain vähän, kuluttaa HTML5 CSS JavaScript -virityksenä muistia aivan tuhottomasti.

Tämä "kaikki web -selaimeen" -tyyli lisää muistinkulutusta vähintäänkin monikymmenkertaiseksi.

Selain myös tuhlaa CPU -aikaa minkä ehtii.

Miksi luulette, että Androidissa joka yritys haluaa kehittää oman sovelluksen sen sijaan, että tekisivät vain web -sivun (HTML5 CSS JavaScript) ?

Luultavasti siksi, että jos yritys tarjoaisi haluamansa asiakkaiden itsepalvelut tuolla HTML5 CSS JavaScript -tyylillä, niin saisiva valituksia siitä, että mobiililaitteista loppuu sekä RAM -muisti että akku. (mobiililaitteissa kun tuhlaileva CPU:n käyttö lisää virrankulutusta siihen malliin, ettei akku kovin kauaa riitä).

TOKI myös se Android -sovellus pitäisi koodata kunnolla, sillä huolimattoman koodarin jäljiltä törmätään myös tuhlailevaan CPU:n käyttöön.

Osa koodaajista ehkä tekee tuossa suhteessa laadukasta työtä, osa ei.


Tuo M-Karin kannattama malli ainakin lisää RAM -muistipalikoiden ja nopeiden, mutta vähän virtaa kuluttavien prosessorien kysyntää.

Valitettavasti vain prosessorien osalta: nopeaa ja vähän virtaa kuluttavaa CPU:ta ei yleensä saa samassa tuotteessa. Kun nopeutta tavoitellaan kellotaajuuden nostolla, ja se taas suoraan lisää virrankulutusta.

Lue lisää

"Valitettavasti vain prosessorien osalta: nopeaa ja vähän virtaa kuluttavaa CPU:ta ei yleensä saa samassa tuotteessa. Kun nopeutta tavoitellaan kellotaajuuden nostolla, ja se taas suoraan lisää virrankulutusta."

Suorituskyky ei ole ollut mikään ongelma vuosikymmeniin kun pidetään käyttöliittymä erillään taustaprosessoinnista. Standardeja prosessoinnin tekemisessä käyttöliittymäpuolella vaan alkoi muotoutua vasta joskus 12v sitten ja ennen standardeja oli usein kannattavinta pitää prosessointi palvelimessa kokonaan jos suinkin mahdollista. Monissakaan sovelluksissa se ei ollut mahdollista ja natiivisovelluksille oli usein kysyntää 7v sitten.

Nyt on viimeiset 7v onnistunu lähes kaikki pöytäkoneissa ja läppäreissä käyttöliittymän prosessointi standardilla tavalla ja taskuvehkeet tulleet noin 6v jäljessä ja kaiken tämän ajan on hyötysuhde parantunut ja parantuu kaiken aikaa.

Itseasiassa vaikka CPU kuormitusta olisikin teoriassa enemmän, helposti selainta käyttävät sovellukset käytännön tasolla kuormittavat vähemmän kuin vaikka Lazaruksella tehty spagetti missä palvelinosaa ei ole erotettu.

Esimerkkejä:
-32-bittiset kirjastot muistissa
-Lazaruksen kirjastokoodi muistissa
-CPU:n cache missit kun tulee kun ajellaan ylimääräistä koodia
-Päätelaitteessa olevien tiedostojen varmuuskopioinnin kuormitus levylle
-Lisääntynyt IO käyttö yleisesti
-Verkon tukkeutuminen varmuuskopioinneissa
-Mahdollisesti rakenteeltaan huonomman koodin häviöt kun koodia ajetaan enemmän. Eli siis jos käännetty koodi olisikin nopeampi yhdessä silmukassa niin jos paremmilla välineillä silmukoita ajetaan vähemmän, saadaan suorituskykylisää.


Oisko tuossa viimisessä kohdassa syy siihen miksi Lazaruksen kanssa on joku CPU-kuormitus jollain tavalla rajoittavaa? Nykyisillä välineillä tehdyssä selainsovelluksessa saa olla aika hillitön käyttöliittymä että CPU-kuormitus olisi jokin ongelma. Lähinnä ne taskukoneet ovat ahtaita kun olisi hyvä saada sullottua kerralla käsiteltävät tietorakenteet johonkin 16-20 megan muistialueelle että jaksaa vuosia vanhatkin laitteet ajaa sovellusta sujuvasti.

Turbo-Urpo kirjoitti:

Verkkosovellukset ei korvaa työpöytäsovelluksia, tietokoneet ei muutu päätteiksi, ikuiset haaveilijat, mahdottomien asioiden uneksijat, HERÄTKÄÄ TODELLISUUTEEN. Keksikää mieluummin tuulimyllynlämmittäjä, niin ei mene aika hukkaan.

Lazaruksen mollaamisella saadaan vain vahinkoa aikaan.

Lue lisää

"Verkkosovellukset ei korvaa työpöytäsovelluksia, tietokoneet ei muutu päätteiksi, ikuiset haaveilijat, mahdottomien asioiden uneksijat, HERÄTKÄÄ TODELLISUUTEEN. Keksikää mieluummin tuulimyllynlämmittäjä, niin ei mene aika hukkaan."

Mikä kumman "verkkosovellus"? Työpöytäsovellus on työpöytäsovellus vaikka olisi tehty standardilla tavalla, ja tallennuksen ja taustaprosessoinnin pitäminen erillään on tärkeimpiä yksittäisiä arkkitehtuurikäytäntöjä.

"Lazaruksen mollaamisella saadaan vain vahinkoa aikaan."

Jaa mitä muka? Legacystä on tarkoituskin päästä eroon. Legacykoodi on olennaisesti sama asia kuin velka. Ja velat maksetaan pois. Tämän päivän suomessa on miljardien edestä velkaa mutta maksajia velalle ei oikein ole, eli riittävästi ohjelmistokehittäjiä.

Itse ajattelen asian yhteiskunnan tasolla tärkeänä, että teknisestä velasta päästäisiin eroon.

M-Kar kirjoitti:

"Verkkosovellukset ei korvaa työpöytäsovelluksia, tietokoneet ei muutu päätteiksi, ikuiset haaveilijat, mahdottomien asioiden uneksijat, HERÄTKÄÄ TODELLISUUTEEN. Keksikää mieluummin tuulimyllynlämmittäjä, niin ei mene aika hukkaan."

Mikä kumman "verkkosovellus"? Työpöytäsovellus on työpöytäsovellus vaikka olisi tehty standardilla tavalla, ja tallennuksen ja taustaprosessoinnin pitäminen erillään on tärkeimpiä yksittäisiä arkkitehtuurikäytäntöjä.

"Lazaruksen mollaamisella saadaan vain vahinkoa aikaan."

Jaa mitä muka? Legacystä on tarkoituskin päästä eroon. Legacykoodi on olennaisesti sama asia kuin velka. Ja velat maksetaan pois. Tämän päivän suomessa on miljardien edestä velkaa mutta maksajia velalle ei oikein ole, eli riittävästi ohjelmistokehittäjiä.

Itse ajattelen asian yhteiskunnan tasolla tärkeänä, että teknisestä velasta päästäisiin eroon.

Lue lisää

legacy=vanha

'''Legacystä on tarkoituskin päästä eroon.'''
En ole kuullut/nähnyt informaatiota, jossa sanottaisiin että Lazaruksesta pitää päästä eroon.

Mikä kumman "verkkosovellus"?
Kokeile, ratkeaako tuo arvoitus Googlen hakukoneella.

'''Legacykoodi on olennaisesti sama asia kuin velka. '''
En näe mitään yhteyttä velkaantumisessa ja vanhassa koodissa.

'''Ja velat maksetaan pois. '''
Toivon mukaan, jokainen tekee niin.

'''Tämän päivän suomessa on miljardien edestä velkaa mutta maksajia velalle ei oikein ole, eli riittävästi ohjelmistokehittäjiä.'''
Ei ohjelmistokehittäjiät ole syyllisiä suomen talouskriisiin eikä he tätä saa ratkaistua, mielestäni
tarvitaan mullistavia innovaatioita ja niiden toteuttajia.

'''Itse ajattelen asian yhteiskunnan tasolla tärkeänä, että teknisestä velasta päästäisiin eroon.'''
Tämäkään ei liity asiaan mitenkään, olet alistanut itsesi palvelimien konfiguraationhallinnan mainoksille, viittaan tähän ( Chef ), jota yritetään markkinoida teknisenvelan termein.

Turbo-Urpo kirjoitti:

legacy=vanha

'''Legacystä on tarkoituskin päästä eroon.'''
En ole kuullut/nähnyt informaatiota, jossa sanottaisiin että Lazaruksesta pitää päästä eroon.

Mikä kumman "verkkosovellus"?
Kokeile, ratkeaako tuo arvoitus Googlen hakukoneella.

'''Legacykoodi on olennaisesti sama asia kuin velka. '''
En näe mitään yhteyttä velkaantumisessa ja vanhassa koodissa.

'''Ja velat maksetaan pois. '''
Toivon mukaan, jokainen tekee niin.

'''Tämän päivän suomessa on miljardien edestä velkaa mutta maksajia velalle ei oikein ole, eli riittävästi ohjelmistokehittäjiä.'''
Ei ohjelmistokehittäjiät ole syyllisiä suomen talouskriisiin eikä he tätä saa ratkaistua, mielestäni
tarvitaan mullistavia innovaatioita ja niiden toteuttajia.

'''Itse ajattelen asian yhteiskunnan tasolla tärkeänä, että teknisestä velasta päästäisiin eroon.'''
Tämäkään ei liity asiaan mitenkään, olet alistanut itsesi palvelimien konfiguraationhallinnan mainoksille, viittaan tähän ( Chef ), jota yritetään markkinoida teknisenvelan termein.

Lue lisää

"legacy=vanha"

LCL perustuu ikinvanhaan 90-luvun alkupuolen VCL:ää joka taas rakentunut 80-luvun Windows API:n varaan, ja sen typeryydet kummittelee edelleen.

On siis vanha ja semmoinen mistä hankkiudutaan eroon.

"Kokeile, ratkeaako tuo arvoitus Googlen hakukoneella."

Melko epämääräinen kuvaus. Onko kyse standardien käytöstä vai asiakas-palvelin mallista vai mistä?

"En näe mitään yhteyttä velkaantumisessa ja vanhassa koodissa."

Koodia tarvitsee ylläpitää, enemmän tai vähemmän. Koodissa luodaan uutta velkaa aina kun sitä kirjoitetaan koska sitä kasvavaa koodimassaa pitää ylläpitää. Koodiin lisäksi yleensä kertyy typeryyksiä puutteellisten määrittelyjen, kiireen puuttellisen ymmärryksen jne. seurauksena ja niiden kanssa sitten eletään kunnes koodi on uusittu.

Vanha koodi typeryyksineen menee kokoajan vaikeammaksi ylläpitää ja toimivana pitäminen vaatii enemmän resursseja ja ainoa lääke tähän on kirjoittaa sitä uusiksi siistimmin kun ymmärrys lisääntynyt, tiedetään vaatimukset ja jne.

Lazaruksen LCL:ssä itseasiassa on vähemmän teknistä velkaa kuin Delphin VCL:ssä, että siinä on jotain siivottu kun saatu paremmin siirrettäväksi mutta molemmat ovat rakenteeltaan... paskaa. 80-luvun typeryydet kummittelevat ja koodia on paljon vaikeampaa tehdä siististi. Delphissä typeryyksiä on korjattu FMX:llä.

Lazaruksessa tekniseksi velaksi voi laskea sen, mitä vaatii että saadaan irroitettua arkkitehtuuri- ja ajettava ohjelma prosessorin arkkitehtuurista tai käyttöjärjestelmästä tai LCL:n korvaaminen nykyaikaisella frameworkilla kun nuo vanhat näivettyvät vähitellen.

"Ei ohjelmistokehittäjiät ole syyllisiä suomen talouskriisiin eikä he tätä saa ratkaistua, mielestäni tarvitaan mullistavia innovaatioita ja niiden toteuttajia."

Ei niin, ohjelmitokehittäjät eivät ole syyllisiä tähän. Sen sijaan suomessa on valtavat määrät teknistä velkaa tai korjausvelkaa joiden hoitaminen pois on iso hinta lappu.

Esimerkiksi mitä maksaa että saadaan kaikki vanhat Windowsit päivitettyä Windows 10:n tai nykyiseen käyttöjärjestelmäversioon, mitä maksaa kaikki putkiremontit ja muut korjausvelat rakennuksissa, mitä maksaa ohjelmien päivittäminen standardeille (HTML5, HTTP) ja nykyiset frameworkit käyttöön. Aivan käsittämätön määrä työsarkaa pelästään tietotekniikassa joka pitää tehdä ennemmin tai myöhemmin, ja joka lopulta jossain kohtaa tulee näpeille kuten vaikka ylipäivätyt Windows XP:t sairaaloissa.

Tekninen velka myös menee sitä kalliimmaksi hoitaa mitä myöhemmin tekee. Siksi se on "velka", koska siinä on käytännössä myös korko.

M-Kar kirjoitti:

"legacy=vanha"

LCL perustuu ikinvanhaan 90-luvun alkupuolen VCL:ää joka taas rakentunut 80-luvun Windows API:n varaan, ja sen typeryydet kummittelee edelleen.

On siis vanha ja semmoinen mistä hankkiudutaan eroon.

"Kokeile, ratkeaako tuo arvoitus Googlen hakukoneella."

Melko epämääräinen kuvaus. Onko kyse standardien käytöstä vai asiakas-palvelin mallista vai mistä?

"En näe mitään yhteyttä velkaantumisessa ja vanhassa koodissa."

Koodia tarvitsee ylläpitää, enemmän tai vähemmän. Koodissa luodaan uutta velkaa aina kun sitä kirjoitetaan koska sitä kasvavaa koodimassaa pitää ylläpitää. Koodiin lisäksi yleensä kertyy typeryyksiä puutteellisten määrittelyjen, kiireen puuttellisen ymmärryksen jne. seurauksena ja niiden kanssa sitten eletään kunnes koodi on uusittu.

Vanha koodi typeryyksineen menee kokoajan vaikeammaksi ylläpitää ja toimivana pitäminen vaatii enemmän resursseja ja ainoa lääke tähän on kirjoittaa sitä uusiksi siistimmin kun ymmärrys lisääntynyt, tiedetään vaatimukset ja jne.

Lazaruksen LCL:ssä itseasiassa on vähemmän teknistä velkaa kuin Delphin VCL:ssä, että siinä on jotain siivottu kun saatu paremmin siirrettäväksi mutta molemmat ovat rakenteeltaan... paskaa. 80-luvun typeryydet kummittelevat ja koodia on paljon vaikeampaa tehdä siististi. Delphissä typeryyksiä on korjattu FMX:llä.

Lazaruksessa tekniseksi velaksi voi laskea sen, mitä vaatii että saadaan irroitettua arkkitehtuuri- ja ajettava ohjelma prosessorin arkkitehtuurista tai käyttöjärjestelmästä tai LCL:n korvaaminen nykyaikaisella frameworkilla kun nuo vanhat näivettyvät vähitellen.

"Ei ohjelmistokehittäjiät ole syyllisiä suomen talouskriisiin eikä he tätä saa ratkaistua, mielestäni tarvitaan mullistavia innovaatioita ja niiden toteuttajia."

Ei niin, ohjelmitokehittäjät eivät ole syyllisiä tähän. Sen sijaan suomessa on valtavat määrät teknistä velkaa tai korjausvelkaa joiden hoitaminen pois on iso hinta lappu.

Esimerkiksi mitä maksaa että saadaan kaikki vanhat Windowsit päivitettyä Windows 10:n tai nykyiseen käyttöjärjestelmäversioon, mitä maksaa kaikki putkiremontit ja muut korjausvelat rakennuksissa, mitä maksaa ohjelmien päivittäminen standardeille (HTML5, HTTP) ja nykyiset frameworkit käyttöön. Aivan käsittämätön määrä työsarkaa pelästään tietotekniikassa joka pitää tehdä ennemmin tai myöhemmin, ja joka lopulta jossain kohtaa tulee näpeille kuten vaikka ylipäivätyt Windows XP:t sairaaloissa.

Tekninen velka myös menee sitä kalliimmaksi hoitaa mitä myöhemmin tekee. Siksi se on "velka", koska siinä on käytännössä myös korko.

Lue lisää

LCL = Lazaruksen komponentti kirjasto
VCL = Visuaalinen komponentti kirjasto

LCL perustuu ikinvanhaan 90-luvun alkupuolen VCL:ää joka taas rakentunut 80-luvun Windows API:n varaan, ja sen typeryydet kummittelee edelleen.

Tälläinen komponenttikirjasto idea on vanha, ei komponentit. Olet itsekin jossakin pitänyt ajatusta hyvänä, kun kyseessä on ollut verkkosovelluksen kehittäminen latomalla lomakekomponentteja sivulle, niin ettei niiden luomiseen tarvitse tuhlata aikaa. Lazaruksen komponenttikirjasto laajenee joka versiossa, luultavasti myös Delphin (VCL) komponenttikirjasto. Idea on erittäin hyvä, ja on suotavaa että näin myös jatkuu.

Mitä typeryyttä tuossa voi olla, mikä siellä sinulle kummittelee ?

————————————————————————————————————————————————

''''Melko epämääräinen kuvaus. Onko kyse standardien käytöstä vai asiakas-palvelin mallista vai mistä?'''

Työpöytäsovellus on sinun omalla koneella, verkkosovellus on ohjelma joka suoritetaan palvelimella. Esimerkkinä vaikka tämä suomi24 keskustelupalsta, verkkokaupat, ja kymmenet tuhannet muut ohjelmat.

Kyseessä ei ole (asiakas-palvelin=client-server) tai (peer-to-peer=vertaisverkko) mallista. Standardisointi = Normittaminen on hyvä asia, mutta se ei tee jostakin huonoa jos sellainen puuttuu, saattaa olla että on erittäin paljon parempi. Standardi ei ole laadun tai paremmuuden synonyymi, se kertoo vain sen että asia ei ole tään huonompi eikä tätä parempi.

"Onko kyse standardien käytöstä" siis missä pitäs olla, "Verkkosovellus" termikö ei ole standardien mukainen, vai mitä sinä tarkoitat. Minusta termi on yleisesti käytössä ja sillä on yleisesti hyväksytty merkitys, siinä on aivan riittävästi standardia yhdelle termille.

En jaksa tämän pitemälle, koska kaikki loppukin noudattelee samaa kaavaa.

Turbo-Urpo kirjoitti:

LCL = Lazaruksen komponentti kirjasto
VCL = Visuaalinen komponentti kirjasto

LCL perustuu ikinvanhaan 90-luvun alkupuolen VCL:ää joka taas rakentunut 80-luvun Windows API:n varaan, ja sen typeryydet kummittelee edelleen.

Tälläinen komponenttikirjasto idea on vanha, ei komponentit. Olet itsekin jossakin pitänyt ajatusta hyvänä, kun kyseessä on ollut verkkosovelluksen kehittäminen latomalla lomakekomponentteja sivulle, niin ettei niiden luomiseen tarvitse tuhlata aikaa. Lazaruksen komponenttikirjasto laajenee joka versiossa, luultavasti myös Delphin (VCL) komponenttikirjasto. Idea on erittäin hyvä, ja on suotavaa että näin myös jatkuu.

Mitä typeryyttä tuossa voi olla, mikä siellä sinulle kummittelee ?

————————————————————————————————————————————————

''''Melko epämääräinen kuvaus. Onko kyse standardien käytöstä vai asiakas-palvelin mallista vai mistä?'''

Työpöytäsovellus on sinun omalla koneella, verkkosovellus on ohjelma joka suoritetaan palvelimella. Esimerkkinä vaikka tämä suomi24 keskustelupalsta, verkkokaupat, ja kymmenet tuhannet muut ohjelmat.

Kyseessä ei ole (asiakas-palvelin=client-server) tai (peer-to-peer=vertaisverkko) mallista. Standardisointi = Normittaminen on hyvä asia, mutta se ei tee jostakin huonoa jos sellainen puuttuu, saattaa olla että on erittäin paljon parempi. Standardi ei ole laadun tai paremmuuden synonyymi, se kertoo vain sen että asia ei ole tään huonompi eikä tätä parempi.

"Onko kyse standardien käytöstä" siis missä pitäs olla, "Verkkosovellus" termikö ei ole standardien mukainen, vai mitä sinä tarkoitat. Minusta termi on yleisesti käytössä ja sillä on yleisesti hyväksytty merkitys, siinä on aivan riittävästi standardia yhdelle termille.

En jaksa tämän pitemälle, koska kaikki loppukin noudattelee samaa kaavaa.

Lue lisää

"Tälläinen komponenttikirjasto idea on vanha, ei komponentit."

Niissä komponenteissa heijastuu 80-luvun typeryydet kun mallia otettu VCL:stä.

"Olet itsekin jossakin pitänyt ajatusta hyvänä, kun kyseessä on ollut verkkosovelluksen kehittäminen latomalla lomakekomponentteja sivulle, niin ettei niiden luomiseen tarvitse tuhlata aikaa."

Komponenttipohjaisuus on hyvä asia mutta tekniikka on mennyt valtavasti eteenpäin että pitäisi olla nykyaikainen framework alla eikä valmiiksi legacyä.

"Mitä typeryyttä tuossa voi olla, mikä siellä sinulle kummittelee ?"

1. LCL komponentit tallentavat tarpeettomasti tilaa. Eli on komponentti mikä on periaatteessa visuaalinen niin sillä jotain metodeita mitkä tallentavat tähän tietoa. Tilojen tallentaminen hallitsemattomasti on tehokas bugimagneetti ja olennaisesti spagettia kun softa voi olla lukemattomissa eri tiloissa ja väärässä tilassa ollessan voi toimia väärin.
2. Tieto kulkee kaksisuuntaisesti, komponentista sisään ja ulos eikä ole rakennettu yksisuuntaista datan siirtoa bugien välttämiseksi.
3. Miten käännetään LCL leiska arkkitehtuuri -ja käyttöjärjestelmäriippumattomaksi?
4. Miten tehdään helposti skaalautuvia ulkoasuja? Eli semmoinen missä vaikka kolme ruudullista tavaraa joka skaalautuu kaiken kokoiille näytöille?
5. Miten lisätään helposti vaihdettava ulkoasuteema? Esim. säädetään napin varjo 5px levyiseksi?

"Työpöytäsovellus on sinun omalla koneella, verkkosovellus on ohjelma joka suoritetaan palvelimella. Esimerkkinä vaikka tämä suomi24 keskustelupalsta, verkkokaupat, ja kymmenet tuhannet muut ohjelmat."

Kyllä palvelin voi olla ihan yhtä lailla oma kone ja olen kokoajan sanonut, että käyttöliittymä pitääkin ajaa päätelaitteessa, eli se on omalla koneella. Ei mitään järkeä nykypäivänä prosessoida näkymää palvelimella. Palvelimella voi pitää ne mitä siellä kuuluukin olla, eli datat, taustaprosessit, viestinvälitykset, haut, indeksoinnit, varmuuskopioinnit jne.

"Normittaminen on hyvä asia, mutta se ei tee jostakin huonoa jos sellainen puuttuu, saattaa olla että on erittäin paljon parempi. Standardi ei ole laadun tai paremmuuden synonyymi, se kertoo vain sen että asia ei ole tään huonompi eikä tätä parempi."

Aina ei voi tehdä standardilla tavalla mutta se pitäisi jotenkin voida perustella koska standardoinnin edut on kiistattomat.

"Minusta termi on yleisesti käytössä ja sillä on yleisesti hyväksytty merkitys, siinä on aivan riittävästi standardia yhdelle termille."

Eli siis jos pelaan vaikka World of Tanksia niin se siis on "verkkosovellus".

M-Kar kirjoitti:

"Tälläinen komponenttikirjasto idea on vanha, ei komponentit."

Niissä komponenteissa heijastuu 80-luvun typeryydet kun mallia otettu VCL:stä.

"Olet itsekin jossakin pitänyt ajatusta hyvänä, kun kyseessä on ollut verkkosovelluksen kehittäminen latomalla lomakekomponentteja sivulle, niin ettei niiden luomiseen tarvitse tuhlata aikaa."

Komponenttipohjaisuus on hyvä asia mutta tekniikka on mennyt valtavasti eteenpäin että pitäisi olla nykyaikainen framework alla eikä valmiiksi legacyä.

"Mitä typeryyttä tuossa voi olla, mikä siellä sinulle kummittelee ?"

1. LCL komponentit tallentavat tarpeettomasti tilaa. Eli on komponentti mikä on periaatteessa visuaalinen niin sillä jotain metodeita mitkä tallentavat tähän tietoa. Tilojen tallentaminen hallitsemattomasti on tehokas bugimagneetti ja olennaisesti spagettia kun softa voi olla lukemattomissa eri tiloissa ja väärässä tilassa ollessan voi toimia väärin.
2. Tieto kulkee kaksisuuntaisesti, komponentista sisään ja ulos eikä ole rakennettu yksisuuntaista datan siirtoa bugien välttämiseksi.
3. Miten käännetään LCL leiska arkkitehtuuri -ja käyttöjärjestelmäriippumattomaksi?
4. Miten tehdään helposti skaalautuvia ulkoasuja? Eli semmoinen missä vaikka kolme ruudullista tavaraa joka skaalautuu kaiken kokoiille näytöille?
5. Miten lisätään helposti vaihdettava ulkoasuteema? Esim. säädetään napin varjo 5px levyiseksi?

"Työpöytäsovellus on sinun omalla koneella, verkkosovellus on ohjelma joka suoritetaan palvelimella. Esimerkkinä vaikka tämä suomi24 keskustelupalsta, verkkokaupat, ja kymmenet tuhannet muut ohjelmat."

Kyllä palvelin voi olla ihan yhtä lailla oma kone ja olen kokoajan sanonut, että käyttöliittymä pitääkin ajaa päätelaitteessa, eli se on omalla koneella. Ei mitään järkeä nykypäivänä prosessoida näkymää palvelimella. Palvelimella voi pitää ne mitä siellä kuuluukin olla, eli datat, taustaprosessit, viestinvälitykset, haut, indeksoinnit, varmuuskopioinnit jne.

"Normittaminen on hyvä asia, mutta se ei tee jostakin huonoa jos sellainen puuttuu, saattaa olla että on erittäin paljon parempi. Standardi ei ole laadun tai paremmuuden synonyymi, se kertoo vain sen että asia ei ole tään huonompi eikä tätä parempi."

Aina ei voi tehdä standardilla tavalla mutta se pitäisi jotenkin voida perustella koska standardoinnin edut on kiistattomat.

"Minusta termi on yleisesti käytössä ja sillä on yleisesti hyväksytty merkitys, siinä on aivan riittävästi standardia yhdelle termille."

Eli siis jos pelaan vaikka World of Tanksia niin se siis on "verkkosovellus".

Lue lisää

SINUN KIRJOITUKSESI

"Tälläinen komponenttikirjasto idea on vanha, ei komponentit."

Niissä komponenteissa heijastuu 80-luvun typeryydet kun mallia otettu VCL:stä.

"Olet itsekin jossakin pitänyt ajatusta hyvänä, kun kyseessä on ollut verkkosovelluksen kehittäminen latomalla lomakekomponentteja sivulle, niin ettei niiden luomiseen tarvitse tuhlata aikaa."

Komponenttipohjaisuus on hyvä asia mutta tekniikka on mennyt valtavasti eteenpäin että pitäisi olla nykyaikainen framework alla eikä valmiiksi legacyä.

————————————————————————————————————————————————

MINUN VASTAUKSENI

En lukenut viestiäsi tämän enempää, kuin tuossa yllä lainasin.

Ensinnäkin, termi "legacyä", ei ole suomea eikä ole englantia, mitä se on ?

Toiseksi
Niissä komponenteissa heijastuu 80-luvun typeryydet kun mallia otettu VCL:stä.

Kerro ihmeessä ne typeryydet, äläkä jauha sitä samaa koko ajan. Pyöräkin keksittiin jo kivikaudella, eikä siinä siitä huolimatta ole mitään typeryyksiä. Pyörät pyörii tänäpäivänäkin hyvin, niin toimii Lazaruksen komponettipalettikin, ajatus on loistava, ja varmasti elää pitempään kuin sinä ja laajenee muihinkin ympäristöihin, ihmiset on laiskoja tekemään saman uudestaan ja uudestaan eikä siinä mitään järkeä olisikaan.

'''mallia otettu VCL:stä''', sekö komponenttipaletti on jotenkin ikävän näköinen, kokoinen, hajuinen, makuinen vai mikä siinä on vikana. Etkö saa niitä toimimaan, etkö tiedän miten niitä käytetään, pitäskö ne sijoittaa toisellatavalla, toisen kokoisena ja toisen näköisenä.

Koitappa arvata missä minun mielestäni heijastuu aivan uskomaton typeryys.

Turbo-Urpo kirjoitti:

SINUN KIRJOITUKSESI

"Tälläinen komponenttikirjasto idea on vanha, ei komponentit."

Niissä komponenteissa heijastuu 80-luvun typeryydet kun mallia otettu VCL:stä.

"Olet itsekin jossakin pitänyt ajatusta hyvänä, kun kyseessä on ollut verkkosovelluksen kehittäminen latomalla lomakekomponentteja sivulle, niin ettei niiden luomiseen tarvitse tuhlata aikaa."

Komponenttipohjaisuus on hyvä asia mutta tekniikka on mennyt valtavasti eteenpäin että pitäisi olla nykyaikainen framework alla eikä valmiiksi legacyä.

————————————————————————————————————————————————

MINUN VASTAUKSENI

En lukenut viestiäsi tämän enempää, kuin tuossa yllä lainasin.

Ensinnäkin, termi "legacyä", ei ole suomea eikä ole englantia, mitä se on ?

Toiseksi
Niissä komponenteissa heijastuu 80-luvun typeryydet kun mallia otettu VCL:stä.

Kerro ihmeessä ne typeryydet, äläkä jauha sitä samaa koko ajan. Pyöräkin keksittiin jo kivikaudella, eikä siinä siitä huolimatta ole mitään typeryyksiä. Pyörät pyörii tänäpäivänäkin hyvin, niin toimii Lazaruksen komponettipalettikin, ajatus on loistava, ja varmasti elää pitempään kuin sinä ja laajenee muihinkin ympäristöihin, ihmiset on laiskoja tekemään saman uudestaan ja uudestaan eikä siinä mitään järkeä olisikaan.

'''mallia otettu VCL:stä''', sekö komponenttipaletti on jotenkin ikävän näköinen, kokoinen, hajuinen, makuinen vai mikä siinä on vikana. Etkö saa niitä toimimaan, etkö tiedän miten niitä käytetään, pitäskö ne sijoittaa toisellatavalla, toisen kokoisena ja toisen näköisenä.

Koitappa arvata missä minun mielestäni heijastuu aivan uskomaton typeryys.

Lue lisää

"Kerro ihmeessä ne typeryydet"

1. LCL komponentit tallentavat tarpeettomasti tilaa. Eli on komponentti mikä on periaatteessa visuaalinen niin sillä jotain metodeita mitkä tallentavat tähän tietoa. Tilojen tallentaminen hallitsemattomasti on tehokas bugimagneetti ja olennaisesti spagettia kun softa voi olla lukemattomissa eri tiloissa ja väärässä tilassa ollessan voi toimia väärin.
2. Tieto kulkee kaksisuuntaisesti, komponentista sisään ja ulos eikä ole rakennettu yksisuuntaista datan siirtoa bugien välttämiseksi.
3. Miten käännetään LCL leiska arkkitehtuuri -ja käyttöjärjestelmäriippumattomaksi?
4. Miten tehdään helposti skaalautuvia ulkoasuja? Eli semmoinen missä vaikka kolme ruudullista tavaraa joka skaalautuu kaiken kokoiille näytöille?
5. Miten lisätään helposti vaihdettava ulkoasuteema? Esim. säädetään napin varjo 5px levyiseksi?

Siinä nyt vaikka muutama.

"Pyöräkin keksittiin jo kivikaudella, eikä siinä siitä huolimatta ole mitään typeryyksiä."

Pyörä on yksinkertainen. LCL:stä taas selvästi näkyy typeryydet. Vähän niinkuin VCL:stä tai Windows API:sta kun nykyään ihmiskunta ymmärtää enemmän.

"ajatus on loistava, ja varmasti elää pitempään kuin sinä ja laajenee muihinkin ympäristöihin, ihmiset on laiskoja tekemään saman uudestaan ja uudestaan eikä siinä mitään järkeä olisikaan."

"Laajenee muihin?" mitä helvettiä horiset? Komponenttipohjainen kehittäminen tuli 70-luvulla ja aivan perusasioita jokapuolella. Kyse on siitä että LCL sisältää typeryyksiä joita ei pitäisi uuteen koodiin tuoda kun se on semmoista mikä pitää kirjoittaa uusiksi teknisen velan poistamiseksi.

"Etkö saa niitä toimimaan, etkö tiedän miten niitä käytetään, pitäskö ne sijoittaa toisellatavalla, toisen kokoisena ja toisen näköisenä."

Pitäisi voida ohjelmoida yksinkertaisemmin tekemättä spagettikoodia mihin LCL:n käyttö pakottaa. Esimerkiksi vaikka se tilan tallennus niissä komponenteissa. Paskaa oliokoodia joka tuo bugeja.

Olio-ohjelmoinnin pioneeri Alan Kay ilmaisi asian selkeästi: "The last thing you wanted any programmer to do is mess with internal state even if presented figuratively. It is unfortunate that much of what is called "object-oriented programming" today is simply old style programming with fancier constructs."

Ja LCL menee tuohon roskakoodiin kun siinä on tarpeettomia tiloja komponenteissa mikä aiheuttaa bugeja koodiin. Tuollaisten mokien korjaus tapahtuu kirjoittamalla koodi uusiksi ja LCL:ää käyttävät ohjelmat ovat kaikki puhtaasti velkaa ja velan hinta on ohjelman kirjoittaminen uusiksi niin, että ei vältetään nuo typeryydet.

Tämä ei sitten ole mikään mielipide asia vaan on laskennallisesti todistettavissa. Ohjelman komponenteilla jos on tiloja niin se ei ole pelkästään koodissa olevat haarautumat miten suoritus etenee vaan jokainen bitti komponentteihin tallennetuissa tiloissa aiheuttaa mahdollisuuden toimia eri tavoin. Siitä seuraa ääretön määrä mahdollisuuksia miten ohjelma voi toimia ja paljon bugeja.

"Ensinnäkin, termi "legacyä", ei ole suomea eikä ole englantia, mitä se on ?"

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

Ei päde täysin LCL:ään sillä sitä pidetään toimivana mutta rakenteellisia vikoja ei näytetä korjaavan kun keskittyy apinoimaan sitä VCL:ää ja VCL:n typeryyksiä on korjattu FMX:n muodossa.

M-Kar kirjoitti:

"Kerro ihmeessä ne typeryydet"

1. LCL komponentit tallentavat tarpeettomasti tilaa. Eli on komponentti mikä on periaatteessa visuaalinen niin sillä jotain metodeita mitkä tallentavat tähän tietoa. Tilojen tallentaminen hallitsemattomasti on tehokas bugimagneetti ja olennaisesti spagettia kun softa voi olla lukemattomissa eri tiloissa ja väärässä tilassa ollessan voi toimia väärin.
2. Tieto kulkee kaksisuuntaisesti, komponentista sisään ja ulos eikä ole rakennettu yksisuuntaista datan siirtoa bugien välttämiseksi.
3. Miten käännetään LCL leiska arkkitehtuuri -ja käyttöjärjestelmäriippumattomaksi?
4. Miten tehdään helposti skaalautuvia ulkoasuja? Eli semmoinen missä vaikka kolme ruudullista tavaraa joka skaalautuu kaiken kokoiille näytöille?
5. Miten lisätään helposti vaihdettava ulkoasuteema? Esim. säädetään napin varjo 5px levyiseksi?

Siinä nyt vaikka muutama.

"Pyöräkin keksittiin jo kivikaudella, eikä siinä siitä huolimatta ole mitään typeryyksiä."

Pyörä on yksinkertainen. LCL:stä taas selvästi näkyy typeryydet. Vähän niinkuin VCL:stä tai Windows API:sta kun nykyään ihmiskunta ymmärtää enemmän.

"ajatus on loistava, ja varmasti elää pitempään kuin sinä ja laajenee muihinkin ympäristöihin, ihmiset on laiskoja tekemään saman uudestaan ja uudestaan eikä siinä mitään järkeä olisikaan."

"Laajenee muihin?" mitä helvettiä horiset? Komponenttipohjainen kehittäminen tuli 70-luvulla ja aivan perusasioita jokapuolella. Kyse on siitä että LCL sisältää typeryyksiä joita ei pitäisi uuteen koodiin tuoda kun se on semmoista mikä pitää kirjoittaa uusiksi teknisen velan poistamiseksi.

"Etkö saa niitä toimimaan, etkö tiedän miten niitä käytetään, pitäskö ne sijoittaa toisellatavalla, toisen kokoisena ja toisen näköisenä."

Pitäisi voida ohjelmoida yksinkertaisemmin tekemättä spagettikoodia mihin LCL:n käyttö pakottaa. Esimerkiksi vaikka se tilan tallennus niissä komponenteissa. Paskaa oliokoodia joka tuo bugeja.

Olio-ohjelmoinnin pioneeri Alan Kay ilmaisi asian selkeästi: "The last thing you wanted any programmer to do is mess with internal state even if presented figuratively. It is unfortunate that much of what is called "object-oriented programming" today is simply old style programming with fancier constructs."

Ja LCL menee tuohon roskakoodiin kun siinä on tarpeettomia tiloja komponenteissa mikä aiheuttaa bugeja koodiin. Tuollaisten mokien korjaus tapahtuu kirjoittamalla koodi uusiksi ja LCL:ää käyttävät ohjelmat ovat kaikki puhtaasti velkaa ja velan hinta on ohjelman kirjoittaminen uusiksi niin, että ei vältetään nuo typeryydet.

Tämä ei sitten ole mikään mielipide asia vaan on laskennallisesti todistettavissa. Ohjelman komponenteilla jos on tiloja niin se ei ole pelkästään koodissa olevat haarautumat miten suoritus etenee vaan jokainen bitti komponentteihin tallennetuissa tiloissa aiheuttaa mahdollisuuden toimia eri tavoin. Siitä seuraa ääretön määrä mahdollisuuksia miten ohjelma voi toimia ja paljon bugeja.

"Ensinnäkin, termi "legacyä", ei ole suomea eikä ole englantia, mitä se on ?"

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

Ei päde täysin LCL:ään sillä sitä pidetään toimivana mutta rakenteellisia vikoja ei näytetä korjaavan kun keskittyy apinoimaan sitä VCL:ää ja VCL:n typeryyksiä on korjattu FMX:n muodossa.

Lue lisää

Käsittääkseni sinulla on Lazarus jollain tietokoneella. Tee pieni kokeilu vaihda Lazaruksen käyttöliittymän kieli toiseksi (esim. englannista suomeksi tai joksikin muuksi). Jos käynnistät Lazaruksen uudelleen huomaat että käyttöliittymä skaalautuu tälle kielelle.
Jos katsot sivun kuvia
http://wiki.lazarus.freepascal.org/Screenshots
niin huomaat että Lazarus toimii hyvin monenlaisilla alustoilla
http://wiki.freepascal.org/UserSuppliedSchemeSettings

M-Kar kirjoitti:

"Kerro ihmeessä ne typeryydet"

1. LCL komponentit tallentavat tarpeettomasti tilaa. Eli on komponentti mikä on periaatteessa visuaalinen niin sillä jotain metodeita mitkä tallentavat tähän tietoa. Tilojen tallentaminen hallitsemattomasti on tehokas bugimagneetti ja olennaisesti spagettia kun softa voi olla lukemattomissa eri tiloissa ja väärässä tilassa ollessan voi toimia väärin.
2. Tieto kulkee kaksisuuntaisesti, komponentista sisään ja ulos eikä ole rakennettu yksisuuntaista datan siirtoa bugien välttämiseksi.
3. Miten käännetään LCL leiska arkkitehtuuri -ja käyttöjärjestelmäriippumattomaksi?
4. Miten tehdään helposti skaalautuvia ulkoasuja? Eli semmoinen missä vaikka kolme ruudullista tavaraa joka skaalautuu kaiken kokoiille näytöille?
5. Miten lisätään helposti vaihdettava ulkoasuteema? Esim. säädetään napin varjo 5px levyiseksi?

Siinä nyt vaikka muutama.

"Pyöräkin keksittiin jo kivikaudella, eikä siinä siitä huolimatta ole mitään typeryyksiä."

Pyörä on yksinkertainen. LCL:stä taas selvästi näkyy typeryydet. Vähän niinkuin VCL:stä tai Windows API:sta kun nykyään ihmiskunta ymmärtää enemmän.

"ajatus on loistava, ja varmasti elää pitempään kuin sinä ja laajenee muihinkin ympäristöihin, ihmiset on laiskoja tekemään saman uudestaan ja uudestaan eikä siinä mitään järkeä olisikaan."

"Laajenee muihin?" mitä helvettiä horiset? Komponenttipohjainen kehittäminen tuli 70-luvulla ja aivan perusasioita jokapuolella. Kyse on siitä että LCL sisältää typeryyksiä joita ei pitäisi uuteen koodiin tuoda kun se on semmoista mikä pitää kirjoittaa uusiksi teknisen velan poistamiseksi.

"Etkö saa niitä toimimaan, etkö tiedän miten niitä käytetään, pitäskö ne sijoittaa toisellatavalla, toisen kokoisena ja toisen näköisenä."

Pitäisi voida ohjelmoida yksinkertaisemmin tekemättä spagettikoodia mihin LCL:n käyttö pakottaa. Esimerkiksi vaikka se tilan tallennus niissä komponenteissa. Paskaa oliokoodia joka tuo bugeja.

Olio-ohjelmoinnin pioneeri Alan Kay ilmaisi asian selkeästi: "The last thing you wanted any programmer to do is mess with internal state even if presented figuratively. It is unfortunate that much of what is called "object-oriented programming" today is simply old style programming with fancier constructs."

Ja LCL menee tuohon roskakoodiin kun siinä on tarpeettomia tiloja komponenteissa mikä aiheuttaa bugeja koodiin. Tuollaisten mokien korjaus tapahtuu kirjoittamalla koodi uusiksi ja LCL:ää käyttävät ohjelmat ovat kaikki puhtaasti velkaa ja velan hinta on ohjelman kirjoittaminen uusiksi niin, että ei vältetään nuo typeryydet.

Tämä ei sitten ole mikään mielipide asia vaan on laskennallisesti todistettavissa. Ohjelman komponenteilla jos on tiloja niin se ei ole pelkästään koodissa olevat haarautumat miten suoritus etenee vaan jokainen bitti komponentteihin tallennetuissa tiloissa aiheuttaa mahdollisuuden toimia eri tavoin. Siitä seuraa ääretön määrä mahdollisuuksia miten ohjelma voi toimia ja paljon bugeja.

"Ensinnäkin, termi "legacyä", ei ole suomea eikä ole englantia, mitä se on ?"

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

Ei päde täysin LCL:ään sillä sitä pidetään toimivana mutta rakenteellisia vikoja ei näytetä korjaavan kun keskittyy apinoimaan sitä VCL:ää ja VCL:n typeryyksiä on korjattu FMX:n muodossa.

Lue lisää

SINUN VIESTIN LUETTU OSA

"Ensinnäkin, termi "legacyä", ei ole suomea eikä ole englantia, mitä se on ?"

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

————————————————————————————————————————————————

MINUN VASTAUKSENI

Antamasi linkin takaa ei löytynyt mitään termistä "legacyä". Myöskään Googlen hakukone ei tunnistanut sanaa. Jos ihan itse keksii sanoja, olisi hyvä ainakin kertaalleen tehdä selvitys mitä sillä tarkoittaa.

Eli mitä tarkoitat sanalla "legacyä" ?

M-Kar kirjoitti:

"Kerro ihmeessä ne typeryydet"

1. LCL komponentit tallentavat tarpeettomasti tilaa. Eli on komponentti mikä on periaatteessa visuaalinen niin sillä jotain metodeita mitkä tallentavat tähän tietoa. Tilojen tallentaminen hallitsemattomasti on tehokas bugimagneetti ja olennaisesti spagettia kun softa voi olla lukemattomissa eri tiloissa ja väärässä tilassa ollessan voi toimia väärin.
2. Tieto kulkee kaksisuuntaisesti, komponentista sisään ja ulos eikä ole rakennettu yksisuuntaista datan siirtoa bugien välttämiseksi.
3. Miten käännetään LCL leiska arkkitehtuuri -ja käyttöjärjestelmäriippumattomaksi?
4. Miten tehdään helposti skaalautuvia ulkoasuja? Eli semmoinen missä vaikka kolme ruudullista tavaraa joka skaalautuu kaiken kokoiille näytöille?
5. Miten lisätään helposti vaihdettava ulkoasuteema? Esim. säädetään napin varjo 5px levyiseksi?

Siinä nyt vaikka muutama.

"Pyöräkin keksittiin jo kivikaudella, eikä siinä siitä huolimatta ole mitään typeryyksiä."

Pyörä on yksinkertainen. LCL:stä taas selvästi näkyy typeryydet. Vähän niinkuin VCL:stä tai Windows API:sta kun nykyään ihmiskunta ymmärtää enemmän.

"ajatus on loistava, ja varmasti elää pitempään kuin sinä ja laajenee muihinkin ympäristöihin, ihmiset on laiskoja tekemään saman uudestaan ja uudestaan eikä siinä mitään järkeä olisikaan."

"Laajenee muihin?" mitä helvettiä horiset? Komponenttipohjainen kehittäminen tuli 70-luvulla ja aivan perusasioita jokapuolella. Kyse on siitä että LCL sisältää typeryyksiä joita ei pitäisi uuteen koodiin tuoda kun se on semmoista mikä pitää kirjoittaa uusiksi teknisen velan poistamiseksi.

"Etkö saa niitä toimimaan, etkö tiedän miten niitä käytetään, pitäskö ne sijoittaa toisellatavalla, toisen kokoisena ja toisen näköisenä."

Pitäisi voida ohjelmoida yksinkertaisemmin tekemättä spagettikoodia mihin LCL:n käyttö pakottaa. Esimerkiksi vaikka se tilan tallennus niissä komponenteissa. Paskaa oliokoodia joka tuo bugeja.

Olio-ohjelmoinnin pioneeri Alan Kay ilmaisi asian selkeästi: "The last thing you wanted any programmer to do is mess with internal state even if presented figuratively. It is unfortunate that much of what is called "object-oriented programming" today is simply old style programming with fancier constructs."

Ja LCL menee tuohon roskakoodiin kun siinä on tarpeettomia tiloja komponenteissa mikä aiheuttaa bugeja koodiin. Tuollaisten mokien korjaus tapahtuu kirjoittamalla koodi uusiksi ja LCL:ää käyttävät ohjelmat ovat kaikki puhtaasti velkaa ja velan hinta on ohjelman kirjoittaminen uusiksi niin, että ei vältetään nuo typeryydet.

Tämä ei sitten ole mikään mielipide asia vaan on laskennallisesti todistettavissa. Ohjelman komponenteilla jos on tiloja niin se ei ole pelkästään koodissa olevat haarautumat miten suoritus etenee vaan jokainen bitti komponentteihin tallennetuissa tiloissa aiheuttaa mahdollisuuden toimia eri tavoin. Siitä seuraa ääretön määrä mahdollisuuksia miten ohjelma voi toimia ja paljon bugeja.

"Ensinnäkin, termi "legacyä", ei ole suomea eikä ole englantia, mitä se on ?"

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

Ei päde täysin LCL:ään sillä sitä pidetään toimivana mutta rakenteellisia vikoja ei näytetä korjaavan kun keskittyy apinoimaan sitä VCL:ää ja VCL:n typeryyksiä on korjattu FMX:n muodossa.

Lue lisää

M-KARIN KIRJOTTAMAA
1. LCL komponentit tallentavat tarpeettomasti tilaa. Eli on komponentti mikä on periaatteessa visuaalinen niin sillä jotain metodeita mitkä tallentavat tähän tietoa. Tilojen tallentaminen hallitsemattomasti on tehokas bugimagneetti ja olennaisesti spagettia kun softa voi olla lukemattomissa eri tiloissa ja väärässä tilassa ollessan voi toimia väärin.
2. Tieto kulkee kaksisuuntaisesti, komponentista sisään ja ulos eikä ole rakennettu yksisuuntaista datan siirtoa bugien välttämiseksi.
3. Miten käännetään LCL leiska arkkitehtuuri -ja käyttöjärjestelmäriippumattomaksi?
4. Miten tehdään helposti skaalautuvia ulkoasuja? Eli semmoinen missä vaikka kolme ruudullista tavaraa joka skaalautuu kaiken kokoiille näytöille?
5. Miten lisätään helposti vaihdettava ulkoasuteema? Esim. säädetään napin varjo 5px levyiseksi?

————————————————————————————————————————————————
MINUN VASTAUS
Mietin että kannattaako tuon yllä olevan johdosta yrittää arvailla mitä kaveri tarkoittaa tarinallaan. On niin kaukana asiasta että en ota tarinan yksityiskohtiin kantaa, saattaa olla enemän hyötyä perun-nostokoneen huoltajalle, kuin jollekin Lazaruksen alkeita opettelevalle.

Vaikuttaa huolestuttavalta, M-Karin kunto on romahtanut, vielä puoli vuotta sitten hänen kirjoituksissaan oli sen verran enemän asiaan liittyvää, että kun hän kirjoitti tarinan auton ajovalopolttimon vaihdosta, lukija saattoi jäädä miettimään onko kaveri nähnyt autoa ollenkaan. Nyt tilanne on jo mennyt siihen pisteeseen että lukija ei enään jää miettimään onko vai eikö ole nähnyt, tarinat on niin etäällä todellisuudesta että voi pitää 100% varmana kirjoittaja ei tiedä asiasta yhtään mitään.

Kieltämättä joskus saa hämmästellä M-karin juttuja =D Kyllä joskus ihan asiaakin tuntuu kirjoittavan ja olen joskus samaa mieltäkin hänen kirjoituksistaan, toisaalta jotkin asiat menee sitten ihan kympillä yli, kuten tuo "kaksisuuntainen tiedon kulkeminen", sillä ei mene mulla kaaliin miten voi edes kirjoittaa mitään ohjelmaa jos tieto kulkee vain yhteen suuntaan? Etenkin jos puhutaan olio-ohjelmoinnista, vai tarkoittaneeko tuo sitä että pitää vain kopioida helekkaristi asioita muistiin erilaisilla asetuksilla ja sitten ne instanssit palauttaa tuloksia niiden asetusten perusteella ja uusi kierros objekteja muistiin?

Toisaalta miten tuommoinen yksisuuntainen tiedon kulku tapahtuu sitten JavaScriptissa ja jollakin js-frameworkilla jolla tehdään vaikka käyttöliittymä? Omasta kokemuksesta juuri JavaScriptissa niitä asetuksia ja vipuja pitääkin viljellä muistiin ihan urakalla.

ex-delphisti kirjoitti:

Kieltämättä joskus saa hämmästellä M-karin juttuja =D Kyllä joskus ihan asiaakin tuntuu kirjoittavan ja olen joskus samaa mieltäkin hänen kirjoituksistaan, toisaalta jotkin asiat menee sitten ihan kympillä yli, kuten tuo "kaksisuuntainen tiedon kulkeminen", sillä ei mene mulla kaaliin miten voi edes kirjoittaa mitään ohjelmaa jos tieto kulkee vain yhteen suuntaan? Etenkin jos puhutaan olio-ohjelmoinnista, vai tarkoittaneeko tuo sitä että pitää vain kopioida helekkaristi asioita muistiin erilaisilla asetuksilla ja sitten ne instanssit palauttaa tuloksia niiden asetusten perusteella ja uusi kierros objekteja muistiin?

Toisaalta miten tuommoinen yksisuuntainen tiedon kulku tapahtuu sitten JavaScriptissa ja jollakin js-frameworkilla jolla tehdään vaikka käyttöliittymä? Omasta kokemuksesta juuri JavaScriptissa niitä asetuksia ja vipuja pitääkin viljellä muistiin ihan urakalla.

Lue lisää

"toisaalta jotkin asiat menee sitten ihan kympillä yli, kuten tuo "kaksisuuntainen tiedon kulkeminen", sillä ei mene mulla kaaliin miten voi edes kirjoittaa mitään ohjelmaa jos tieto kulkee vain yhteen suuntaan? Etenkin jos puhutaan olio-ohjelmoinnista, vai tarkoittaneeko tuo sitä että pitää vain kopioida helekkaristi asioita muistiin erilaisilla asetuksilla ja sitten ne instanssit palauttaa tuloksia niiden asetusten perusteella ja uusi kierros objekteja muistiin?"

Tilalle voi olla keskitetty paikka.

Kun olio luodaan niin sen sisältö pitäisi olla muuttumaton. Propertyt sisään luontivaiheessa ja niillä mennään instanssin eliniän ajan.

"Toisaalta miten tuommoinen yksisuuntainen tiedon kulku tapahtuu sitten JavaScriptissa ja jollakin js-frameworkilla jolla tehdään vaikka käyttöliittymä? Omasta kokemuksesta juuri JavaScriptissa niitä asetuksia ja vipuja pitääkin viljellä muistiin ihan urakalla."

Laitetaan tiedot propertyinä sisään mutta pidetään komponentit pääasiassa tilattomina ja tilan tallennukselle sitten container.

Komponentit voivat tallentaa tietoa keskitettyyn paikkaan välittämällä niille propertyinä ne funktiot millä tilaa muutetaan. Avainjuttu siis on pitää komponentit pääasiassa tilattomana. Se on se huono juttu jos on vaikka 5 komponenttia ja niillä omat tilansa ja logiikkaa kun ajetaan niin eri komponenttien sen hetkinen tila vaikuttaa siihen miten suoritus menee. Luetaan vaikka muualta jollain getterillä.

Sitten jos yksi olio vaikka poistuu jolla tila mikä vaikuttaa toisessa paikassa suoritettavaan laskentaan niin siinähän sitten on aika vakava bugi.

Siltä tiedon venksalukselta välttyy kun pitää kaiken olennaisen samassa paikassa. Sen lisäksi sen logiikan voi kirjoittaa niin, että tilan muutos tapahtuu funktiona jossa annetaan parametrina aikaisempi tila jolloin se ohjelman keskitetty tila voi olla muuttumaton.

Olio-ohjelmoinnin pioneerit ajatteli käytön niin, että ei tallenneta tilaa miten sattuu ja sen lisäksi muuttumattomana pitäminen on perusjuttuja funktionaalisuudessa.

summa(a, b) { return a b }

Eli a ja b sisään ja palautetaan tulos. Ei tarvitse niitä sijoituslauseita kylvää miten sattuu.

M-Kar kirjoitti:

"toisaalta jotkin asiat menee sitten ihan kympillä yli, kuten tuo "kaksisuuntainen tiedon kulkeminen", sillä ei mene mulla kaaliin miten voi edes kirjoittaa mitään ohjelmaa jos tieto kulkee vain yhteen suuntaan? Etenkin jos puhutaan olio-ohjelmoinnista, vai tarkoittaneeko tuo sitä että pitää vain kopioida helekkaristi asioita muistiin erilaisilla asetuksilla ja sitten ne instanssit palauttaa tuloksia niiden asetusten perusteella ja uusi kierros objekteja muistiin?"

Tilalle voi olla keskitetty paikka.

Kun olio luodaan niin sen sisältö pitäisi olla muuttumaton. Propertyt sisään luontivaiheessa ja niillä mennään instanssin eliniän ajan.

"Toisaalta miten tuommoinen yksisuuntainen tiedon kulku tapahtuu sitten JavaScriptissa ja jollakin js-frameworkilla jolla tehdään vaikka käyttöliittymä? Omasta kokemuksesta juuri JavaScriptissa niitä asetuksia ja vipuja pitääkin viljellä muistiin ihan urakalla."

Laitetaan tiedot propertyinä sisään mutta pidetään komponentit pääasiassa tilattomina ja tilan tallennukselle sitten container.

Komponentit voivat tallentaa tietoa keskitettyyn paikkaan välittämällä niille propertyinä ne funktiot millä tilaa muutetaan. Avainjuttu siis on pitää komponentit pääasiassa tilattomana. Se on se huono juttu jos on vaikka 5 komponenttia ja niillä omat tilansa ja logiikkaa kun ajetaan niin eri komponenttien sen hetkinen tila vaikuttaa siihen miten suoritus menee. Luetaan vaikka muualta jollain getterillä.

Sitten jos yksi olio vaikka poistuu jolla tila mikä vaikuttaa toisessa paikassa suoritettavaan laskentaan niin siinähän sitten on aika vakava bugi.

Siltä tiedon venksalukselta välttyy kun pitää kaiken olennaisen samassa paikassa. Sen lisäksi sen logiikan voi kirjoittaa niin, että tilan muutos tapahtuu funktiona jossa annetaan parametrina aikaisempi tila jolloin se ohjelman keskitetty tila voi olla muuttumaton.

Olio-ohjelmoinnin pioneerit ajatteli käytön niin, että ei tallenneta tilaa miten sattuu ja sen lisäksi muuttumattomana pitäminen on perusjuttuja funktionaalisuudessa.

summa(a, b) { return a b }

Eli a ja b sisään ja palautetaan tulos. Ei tarvitse niitä sijoituslauseita kylvää miten sattuu.

Lue lisää

Voi hyvä jumala mitä soopaa, ja viellä omilla tunnuksilla ilkeää tuollaista kirjoitella. Olis kyllä aihetta lähiomaisten käydä kylässä vikaisemassa, onko ruokapöytä vessa ja napottaako vessanpönttö olohuoneessa keskellä lattiaa.

lasse_1.8 kirjoitti:

Käsittääkseni sinulla on Lazarus jollain tietokoneella. Tee pieni kokeilu vaihda Lazaruksen käyttöliittymän kieli toiseksi (esim. englannista suomeksi tai joksikin muuksi). Jos käynnistät Lazaruksen uudelleen huomaat että käyttöliittymä skaalautuu tälle kielelle.
Jos katsot sivun kuvia
http://wiki.lazarus.freepascal.org/Screenshots
niin huomaat että Lazarus toimii hyvin monenlaisilla alustoilla
http://wiki.freepascal.org/UserSuppliedSchemeSettings

Lue lisää

"Käsittääkseni sinulla on Lazarus jollain tietokoneella. Tee pieni kokeilu vaihda Lazaruksen käyttöliittymän kieli toiseksi (esim. englannista suomeksi tai joksikin muuksi). Jos käynnistät Lazaruksen uudelleen huomaat että käyttöliittymä skaalautuu tälle kielelle."

En minä mistään kielen vaihdosta puhu vaan skaalautuvuudesta vaikka niin, että sama käyttöliittymä toimii sujuvasti kun näytön halkaisija vaihtelee muutamasta tuumasta 80" välillä ja pikselimäärä vähäisestä johonkin 8K välillä, ja toimii zoomi normaaliin tapaan Ctrl ja Ctrl - ja kaikki asemoituu oikein. Pikselien koot, kuva alue ja fonttikoot voivat muuttua rajustikin.

Turbo-Urpo kirjoitti:

Voi hyvä jumala mitä soopaa, ja viellä omilla tunnuksilla ilkeää tuollaista kirjoitella. Olis kyllä aihetta lähiomaisten käydä kylässä vikaisemassa, onko ruokapöytä vessa ja napottaako vessanpönttö olohuoneessa keskellä lattiaa.

Lue lisää

Ei ole mitään soopaa missään vaan kaikki on täyttä totta.

Se mikä tässä nyt näyttäisi minun silmiin olevan havaittavissa, että jotkut ovat kirjoittaneet koodia Delphillä ja Object pascalilla ja pyrkivät kirjoittamaan koodia yleisesti kuin tässä.

Se vaan menee niin, että jos ainoa työkalu on vasara, niin kaikki ongelmat alkavat näyttää nauloilta. Ei kirjoiteta ohjelmointikielellä, vaan kirjoitetaan ongelma ohjelmointkikieleen eikä rajoiteta omia ajatuksia ohjelmointivälineen typeryyksiin.

M-Kar kirjoitti:

"Käsittääkseni sinulla on Lazarus jollain tietokoneella. Tee pieni kokeilu vaihda Lazaruksen käyttöliittymän kieli toiseksi (esim. englannista suomeksi tai joksikin muuksi). Jos käynnistät Lazaruksen uudelleen huomaat että käyttöliittymä skaalautuu tälle kielelle."

En minä mistään kielen vaihdosta puhu vaan skaalautuvuudesta vaikka niin, että sama käyttöliittymä toimii sujuvasti kun näytön halkaisija vaihtelee muutamasta tuumasta 80" välillä ja pikselimäärä vähäisestä johonkin 8K välillä, ja toimii zoomi normaaliin tapaan Ctrl ja Ctrl - ja kaikki asemoituu oikein. Pikselien koot, kuva alue ja fonttikoot voivat muuttua rajustikin.

Lue lisää

Kyllä Lazaruksella voidaan skaalata liittymän ikkuna miten halutaan, ja PixelsPerInch asettaa/muuttaa (Pikselien koot) pisteiden määrän tuumaa kohti. Tämä (kuva alue) kai tarkoittaa TForm (päälomakkeen/ikkunan) kokoa joka voi olla myös kuvaruutua suurempi, läpnäkyvä osittain tai kokonaan. Kaikki lomakkeen näkyvät komonentit voidaan halutessa sitoa kuvaruudun kokoon tai jossakin suhteessa siihen.

Nämä on perusasioita, miten sinä voit olla näistä tietämätön. On sataprosentisesti ohjelmoijasta kiinni pitääkö se noita ominaisuuksia tarpeellisena. Minu tekeleissä ikkuna avautuu ruudun keskelle monitorin koosta riippuvassa koossa. Ohjelman suketuminen tallentaa sijainin ja koon, ja uudestaan käynnistettäessä se avautuu niille sijoilleen missä se suljettiin. Tai ainakin tuo viimeisin tekele oli hyvä laittaa käyttäytymään noin.

Eihän hitto sellaisella liittymällä tee mitään kuten Debian livet on, ihan perseestä kun eivät osaa edes tuon vertaa ajatella loppukäyttäjän olosuhteita.

Turbo-Urpo kirjoitti:

Kyllä Lazaruksella voidaan skaalata liittymän ikkuna miten halutaan, ja PixelsPerInch asettaa/muuttaa (Pikselien koot) pisteiden määrän tuumaa kohti. Tämä (kuva alue) kai tarkoittaa TForm (päälomakkeen/ikkunan) kokoa joka voi olla myös kuvaruutua suurempi, läpnäkyvä osittain tai kokonaan. Kaikki lomakkeen näkyvät komonentit voidaan halutessa sitoa kuvaruudun kokoon tai jossakin suhteessa siihen.

Nämä on perusasioita, miten sinä voit olla näistä tietämätön. On sataprosentisesti ohjelmoijasta kiinni pitääkö se noita ominaisuuksia tarpeellisena. Minu tekeleissä ikkuna avautuu ruudun keskelle monitorin koosta riippuvassa koossa. Ohjelman suketuminen tallentaa sijainin ja koon, ja uudestaan käynnistettäessä se avautuu niille sijoilleen missä se suljettiin. Tai ainakin tuo viimeisin tekele oli hyvä laittaa käyttäytymään noin.

Eihän hitto sellaisella liittymällä tee mitään kuten Debian livet on, ihan perseestä kun eivät osaa edes tuon vertaa ajatella loppukäyttäjän olosuhteita.

Lue lisää

Minkä hiton takia sinä tuota samaa jankutat jatkuvasti kun kehut osaavasi, niin ei tuota testatessa mene kuin 15 min. nyt pistä se Lazarus tulille, visko joitain komponentteja lomakkeelle ja sido koko lomakkeen koko kuvaruudun leveyteen ja korkeuteen. Muuttele likusäätimellä läpinäkyvyyttä, ja PixelsPerInch asetuksella soomausta. Sen jälkeen pistä paperille, ja paperi lyö naulla siihen monitorin yläpuolelle, ennen kaikkee lopeta tuo väkääminen asiasta jonka voit ihan itse testata varttitunnissa.

Näissä ohjelmointi asioissa kannattaa olla avoin mielinen ja tutustua uusiin (vaikka itselle uusiin) asioihin. Aikoinaan juuri olio-ohjelmoinnin jutun älyäminen oli vuonna 1998 itselle se kova juttu, innostuin siitä tosi paljon kun kävin läpi Opeta itsellesi C 21 päivässä -kirjaa. Ohjelmointi on kiinnostanut juuri siksi itseäni jo noin 30 vuotta koska siinä ei ole koskaan valmis ja aina kiva "hiffata" uusia asioita :)

ex-delphisti kirjoitti:

Näissä ohjelmointi asioissa kannattaa olla avoin mielinen ja tutustua uusiin (vaikka itselle uusiin) asioihin. Aikoinaan juuri olio-ohjelmoinnin jutun älyäminen oli vuonna 1998 itselle se kova juttu, innostuin siitä tosi paljon kun kävin läpi Opeta itsellesi C 21 päivässä -kirjaa. Ohjelmointi on kiinnostanut juuri siksi itseäni jo noin 30 vuotta koska siinä ei ole koskaan valmis ja aina kiva "hiffata" uusia asioita :)

Lue lisää

Ja vanhoja myös, meinasin skaalata talvisodan aikaista ympäristöä, mutta olipa jutut unohtuneet: https://i.imgur.com/pjAvxcj.gif tuollaseksi jäi.

jokainen voi itse kokeilla mitä muistaa:
CTRL ALT T
fp

ja sitten koodaamaan.

ex-delphisti kirjoitti:

Näissä ohjelmointi asioissa kannattaa olla avoin mielinen ja tutustua uusiin (vaikka itselle uusiin) asioihin. Aikoinaan juuri olio-ohjelmoinnin jutun älyäminen oli vuonna 1998 itselle se kova juttu, innostuin siitä tosi paljon kun kävin läpi Opeta itsellesi C 21 päivässä -kirjaa. Ohjelmointi on kiinnostanut juuri siksi itseäni jo noin 30 vuotta koska siinä ei ole koskaan valmis ja aina kiva "hiffata" uusia asioita :)

Lue lisää

Mutta Lazarus taipui paremmin: https://i.imgur.com/gYMKe6r.gif vaikka kyllähän tuohonkin meni enemän kuin 15 min.

Turbo-Urpo kirjoitti:

Kyllä Lazaruksella voidaan skaalata liittymän ikkuna miten halutaan, ja PixelsPerInch asettaa/muuttaa (Pikselien koot) pisteiden määrän tuumaa kohti. Tämä (kuva alue) kai tarkoittaa TForm (päälomakkeen/ikkunan) kokoa joka voi olla myös kuvaruutua suurempi, läpnäkyvä osittain tai kokonaan. Kaikki lomakkeen näkyvät komonentit voidaan halutessa sitoa kuvaruudun kokoon tai jossakin suhteessa siihen.

Nämä on perusasioita, miten sinä voit olla näistä tietämätön. On sataprosentisesti ohjelmoijasta kiinni pitääkö se noita ominaisuuksia tarpeellisena. Minu tekeleissä ikkuna avautuu ruudun keskelle monitorin koosta riippuvassa koossa. Ohjelman suketuminen tallentaa sijainin ja koon, ja uudestaan käynnistettäessä se avautuu niille sijoilleen missä se suljettiin. Tai ainakin tuo viimeisin tekele oli hyvä laittaa käyttäytymään noin.

Eihän hitto sellaisella liittymällä tee mitään kuten Debian livet on, ihan perseestä kun eivät osaa edes tuon vertaa ajatella loppukäyttäjän olosuhteita.

Lue lisää

"Kyllä Lazaruksella voidaan skaalata liittymän ikkuna miten halutaan"

Turing täydellisellä välineellä onnistuu toki mikä tahansa mutta se ei ole se pointti.

"ja PixelsPerInch asettaa/muuttaa (Pikselien koot) pisteiden määrän tuumaa kohti."

Olen tietoinen.

"Tämä (kuva alue) kai tarkoittaa TForm (päälomakkeen/ikkunan) kokoa joka voi olla myös kuvaruutua suurempi, läpnäkyvä osittain tai kokonaan. Kaikki lomakkeen näkyvät komonentit voidaan halutessa sitoa kuvaruudun kokoon tai jossakin suhteessa siihen."

Mutta homman pointti on se, että näin ei tapahdu oikeastaan missään Lazaruksella tehdyllä ohjelmalla koska se on Lazaruksella kömpelöä.

"On sataprosentisesti ohjelmoijasta kiinni pitääkö se noita ominaisuuksia tarpeellisena."

Kyse on perusasioista joiden oletetaan toimivan ilman nysväämistä.

M-Kar kirjoitti:

"Kyllä Lazaruksella voidaan skaalata liittymän ikkuna miten halutaan"

Turing täydellisellä välineellä onnistuu toki mikä tahansa mutta se ei ole se pointti.

"ja PixelsPerInch asettaa/muuttaa (Pikselien koot) pisteiden määrän tuumaa kohti."

Olen tietoinen.

"Tämä (kuva alue) kai tarkoittaa TForm (päälomakkeen/ikkunan) kokoa joka voi olla myös kuvaruutua suurempi, läpnäkyvä osittain tai kokonaan. Kaikki lomakkeen näkyvät komonentit voidaan halutessa sitoa kuvaruudun kokoon tai jossakin suhteessa siihen."

Mutta homman pointti on se, että näin ei tapahdu oikeastaan missään Lazaruksella tehdyllä ohjelmalla koska se on Lazaruksella kömpelöä.

"On sataprosentisesti ohjelmoijasta kiinni pitääkö se noita ominaisuuksia tarpeellisena."

Kyse on perusasioista joiden oletetaan toimivan ilman nysväämistä.

Lue lisää

SINUN VIESTISTÄ OSA
"Kyllä Lazaruksella voidaan skaalata liittymän ikkuna miten halutaan"

Turing täydellisellä välineellä onnistuu toki mikä tahansa mutta se ei ole se pointti.

——————————————————————————————————————————————

MINUN VASTAUS
Mikä on Turing ?
Miten se liittyy Lazarukseen ?

M-Kar kirjoitti:

"Kyllä Lazaruksella voidaan skaalata liittymän ikkuna miten halutaan"

Turing täydellisellä välineellä onnistuu toki mikä tahansa mutta se ei ole se pointti.

"ja PixelsPerInch asettaa/muuttaa (Pikselien koot) pisteiden määrän tuumaa kohti."

Olen tietoinen.

"Tämä (kuva alue) kai tarkoittaa TForm (päälomakkeen/ikkunan) kokoa joka voi olla myös kuvaruutua suurempi, läpnäkyvä osittain tai kokonaan. Kaikki lomakkeen näkyvät komonentit voidaan halutessa sitoa kuvaruudun kokoon tai jossakin suhteessa siihen."

Mutta homman pointti on se, että näin ei tapahdu oikeastaan missään Lazaruksella tehdyllä ohjelmalla koska se on Lazaruksella kömpelöä.

"On sataprosentisesti ohjelmoijasta kiinni pitääkö se noita ominaisuuksia tarpeellisena."

Kyse on perusasioista joiden oletetaan toimivan ilman nysväämistä.

Lue lisää

SINUN VIESTISTÄ OSA
"ja PixelsPerInch asettaa/muuttaa (Pikselien koot) pisteiden määrän tuumaa kohti."

Olen tietoinen.

——————————————————————————————————————————————

MINUN VASTAUS
Mikäs ongelma sinulla sitten on niiden pikselien kokojen kanssa ?

M-Kar kirjoitti:

"Kyllä Lazaruksella voidaan skaalata liittymän ikkuna miten halutaan"

Turing täydellisellä välineellä onnistuu toki mikä tahansa mutta se ei ole se pointti.

"ja PixelsPerInch asettaa/muuttaa (Pikselien koot) pisteiden määrän tuumaa kohti."

Olen tietoinen.

"Tämä (kuva alue) kai tarkoittaa TForm (päälomakkeen/ikkunan) kokoa joka voi olla myös kuvaruutua suurempi, läpnäkyvä osittain tai kokonaan. Kaikki lomakkeen näkyvät komonentit voidaan halutessa sitoa kuvaruudun kokoon tai jossakin suhteessa siihen."

Mutta homman pointti on se, että näin ei tapahdu oikeastaan missään Lazaruksella tehdyllä ohjelmalla koska se on Lazaruksella kömpelöä.

"On sataprosentisesti ohjelmoijasta kiinni pitääkö se noita ominaisuuksia tarpeellisena."

Kyse on perusasioista joiden oletetaan toimivan ilman nysväämistä.

Lue lisää

SINUN VIESTISTÄ OSA
Mutta homman pointti on se, että näin ei tapahdu oikeastaan missään Lazaruksella tehdyllä ohjelmalla koska se on Lazaruksella kömpelöä.

——————————————————————————————————————————————

MINUN VASTAUS
Mihin verrattuna "kömpelöä", vai onko tämä ongelma vain sinulla. Sehän voi olla oletus, jos siihen on tarvetta. Mielestäni sellaista tarvetta ei ole, ohjelmien käyttämä tila kiintolevyllä, tarvittava muisti kasvaa turhasta taakasta. Suorituskyky laskee, käynistymisajat pitenee.

On aivan perseestä, jos asiat ei ole ohjelmoijan käsissä, sellaisella ympäristöllä ei ole mitään virkaa koska soveltaminen kapenee sitä mukaa mitä enemän lähtökohtaisesti asioita on pakko ottaa mukaan.

Ohjelmoija voi jos niin katsoo tarpeelliseksi, luoda projektipohjan jossa on hänen haluamansa ominaisuudet valmiina. En usko kuitenkaan että tuollaista tarvetta on olemassa, kuin yksittäisissä tapauksissa, ja silloinkin peruslomakepohjalla tuen käyttöön otto on helpompaa kuin oman sähköpostin avaaminen.

Turbo-Urpo kirjoitti:

SINUN VIESTISTÄ OSA
"Kyllä Lazaruksella voidaan skaalata liittymän ikkuna miten halutaan"

Turing täydellisellä välineellä onnistuu toki mikä tahansa mutta se ei ole se pointti.

——————————————————————————————————————————————

MINUN VASTAUS
Mikä on Turing ?
Miten se liittyy Lazarukseen ?

Lue lisää

"Mikä on Turing ?"

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

https://fi.wikipedia.org/wiki/Turing-vahva

"Miten se liittyy Lazarukseen ?"

Lazarus ympäristä on turing täydellinen. Ja kun sillä voi piirtää vaikka pisteitä niin käytännössä mikä tahansa onnistuu jos vain jaksaa nysvätä.

Kyse onkin siitä, että miksi tarvitsee niin paljon nysväämistä? Pitää erikseen säätää perusasioita toimimaan kuten skaalausta. Havaintojen mukaan Lazaruksella tehdyt ohjelmat skaalautuvat heikosti joten siinä nyt selvästikin on jotain kohtuutonta vaivaa saada perusasiat toimimaan.

"Mikäs ongelma sinulla sitten on niiden pikselien kokojen kanssa ?"

Käyttäjä säätää koot Ctrl ja Ctrl - näppäimillä. Esimerkiksi Lazaruksen käyttöliittymässä ei tapahdu yhtään mitään kun painaa näin. Sitten vertaa vaikka Suomi24:n tai vaikka Visual Studio Codeen niin perusjutut toimivat. Hienosti menee vaikka menu piiloon Suomi24:ssä kun tarpeeksi pieneksi menee tila koko muuttuu Ctrl ja Ctrl -

M-Kar kirjoitti:

"Kyllä Lazaruksella voidaan skaalata liittymän ikkuna miten halutaan"

Turing täydellisellä välineellä onnistuu toki mikä tahansa mutta se ei ole se pointti.

"ja PixelsPerInch asettaa/muuttaa (Pikselien koot) pisteiden määrän tuumaa kohti."

Olen tietoinen.

"Tämä (kuva alue) kai tarkoittaa TForm (päälomakkeen/ikkunan) kokoa joka voi olla myös kuvaruutua suurempi, läpnäkyvä osittain tai kokonaan. Kaikki lomakkeen näkyvät komonentit voidaan halutessa sitoa kuvaruudun kokoon tai jossakin suhteessa siihen."

Mutta homman pointti on se, että näin ei tapahdu oikeastaan missään Lazaruksella tehdyllä ohjelmalla koska se on Lazaruksella kömpelöä.

"On sataprosentisesti ohjelmoijasta kiinni pitääkö se noita ominaisuuksia tarpeellisena."

Kyse on perusasioista joiden oletetaan toimivan ilman nysväämistä.

Lue lisää

SINUN VIESTISTÄ OSA
Kyse on perusasioista joiden oletetaan toimivan ilman nysväämistä.

——————————————————————————————————————————————

MINUN VASTAUS
Kyse on perusasiasta, ja siksipä se onkin ruksi->ruutuun asia, jos ohjelman Fontti on skaalauduttava lomakkeen mukana, se vie 17 merkkiä. Minusta olisi hiton kiva nähdä mitä sinä sen kanssa teet kun se sinulle on "nysväämistä". Laita pieni animaatio, katsotaan porukalla miten sen voisit tehdä helpommin.

Turbo-Urpo kirjoitti:

SINUN VIESTISTÄ OSA
Mutta homman pointti on se, että näin ei tapahdu oikeastaan missään Lazaruksella tehdyllä ohjelmalla koska se on Lazaruksella kömpelöä.

——————————————————————————————————————————————

MINUN VASTAUS
Mihin verrattuna "kömpelöä", vai onko tämä ongelma vain sinulla. Sehän voi olla oletus, jos siihen on tarvetta. Mielestäni sellaista tarvetta ei ole, ohjelmien käyttämä tila kiintolevyllä, tarvittava muisti kasvaa turhasta taakasta. Suorituskyky laskee, käynistymisajat pitenee.

On aivan perseestä, jos asiat ei ole ohjelmoijan käsissä, sellaisella ympäristöllä ei ole mitään virkaa koska soveltaminen kapenee sitä mukaa mitä enemän lähtökohtaisesti asioita on pakko ottaa mukaan.

Ohjelmoija voi jos niin katsoo tarpeelliseksi, luoda projektipohjan jossa on hänen haluamansa ominaisuudet valmiina. En usko kuitenkaan että tuollaista tarvetta on olemassa, kuin yksittäisissä tapauksissa, ja silloinkin peruslomakepohjalla tuen käyttöön otto on helpompaa kuin oman sähköpostin avaaminen.

Lue lisää

"Mihin verrattuna "kömpelöä", vai onko tämä ongelma vain sinulla."

Yleisesti ottaen mihin tahansa käyttöliittymäframeworkkiin.

Lazarus IDE ja sillä tehdyt ohjelmat eivät yleisesti ottaen skaalaudu. Teoriassa mahdollista tehdä mitä tahansa mutta näin ei ole tehty koska se on kömpölöä. Perusasiat normaalisti toimivat automaattisesti ilman nysväämistä tai ainakin hyvin vähäisellä vaivalla.

"Mielestäni sellaista tarvetta ei ole, ohjelmien käyttämä tila kiintolevyllä, tarvittava muisti kasvaa turhasta taakasta. Suorituskyky laskee, käynistymisajat pitenee."

Tuohan on sitä surkeutta Lazaruksessa. Ei nykypäivän välineillä ole tuollaisia heikkouksia perusasioiden kanssa kuten vaikka suorituskykyongelmia.

M-Kar kirjoitti:

"Mihin verrattuna "kömpelöä", vai onko tämä ongelma vain sinulla."

Yleisesti ottaen mihin tahansa käyttöliittymäframeworkkiin.

Lazarus IDE ja sillä tehdyt ohjelmat eivät yleisesti ottaen skaalaudu. Teoriassa mahdollista tehdä mitä tahansa mutta näin ei ole tehty koska se on kömpölöä. Perusasiat normaalisti toimivat automaattisesti ilman nysväämistä tai ainakin hyvin vähäisellä vaivalla.

"Mielestäni sellaista tarvetta ei ole, ohjelmien käyttämä tila kiintolevyllä, tarvittava muisti kasvaa turhasta taakasta. Suorituskyky laskee, käynistymisajat pitenee."

Tuohan on sitä surkeutta Lazaruksessa. Ei nykypäivän välineillä ole tuollaisia heikkouksia perusasioiden kanssa kuten vaikka suorituskykyongelmia.

Lue lisää

Nyt STOP,
jos väität jotakin, anna joki ihan kokreettinen esimerkki, että voidaan käydä asia yksityiskohtaisesti läpi, et sinä noin voi mitään oppia kun höpötät joutavia.

M-Kar kirjoitti:

"Mihin verrattuna "kömpelöä", vai onko tämä ongelma vain sinulla."

Yleisesti ottaen mihin tahansa käyttöliittymäframeworkkiin.

Lazarus IDE ja sillä tehdyt ohjelmat eivät yleisesti ottaen skaalaudu. Teoriassa mahdollista tehdä mitä tahansa mutta näin ei ole tehty koska se on kömpölöä. Perusasiat normaalisti toimivat automaattisesti ilman nysväämistä tai ainakin hyvin vähäisellä vaivalla.

"Mielestäni sellaista tarvetta ei ole, ohjelmien käyttämä tila kiintolevyllä, tarvittava muisti kasvaa turhasta taakasta. Suorituskyky laskee, käynistymisajat pitenee."

Tuohan on sitä surkeutta Lazaruksessa. Ei nykypäivän välineillä ole tuollaisia heikkouksia perusasioiden kanssa kuten vaikka suorituskykyongelmia.

Lue lisää

SINUN VIESTISTÄ OSA
"Mihin verrattuna "kömpelöä", vai onko tämä ongelma vain sinulla."

Yleisesti ottaen mihin tahansa käyttöliittymäframeworkkiin.

——————————————————————————————————————————————

MINUN VASTAUS
Tarkoittaako tuo suomeksi tätä:
Lääkäri on yleisesti ottaen kömpelö tekemään sähkömienen töitä.

jos niin tämä keskustelu, on pelkää trollaamista sinulta, ei mitään yritystäkään asialliseen keskusteluun, MUTTA MIKSI HARRASTAT TÄTÄ TROLLAAMISTA NIIN PALJON?

Turbo-Urpo kirjoitti:

Nyt STOP,
jos väität jotakin, anna joki ihan kokreettinen esimerkki, että voidaan käydä asia yksityiskohtaisesti läpi, et sinä noin voi mitään oppia kun höpötät joutavia.

Lue lisää

Ei minulla ole tässä mitään oppimistarvetta.

Konreettinen esimerkki vaikka se, että tekee Lazaruksella sen lomakkeen niin ei toimi Ctrl ja Ctrl - näppäimet että skaalaisi.

Toisin sanoen, Lazaruksella on hankalaa tehdä näinkin yksinkertainen käyttöliittymä kuin vaikka tämä suomi24 näkymä tässä missä menu joka menee itsekseen piiloon ja tekstiä muutama ruudullinen.

Turbo-Urpo kirjoitti:

SINUN VIESTISTÄ OSA
"Mihin verrattuna "kömpelöä", vai onko tämä ongelma vain sinulla."

Yleisesti ottaen mihin tahansa käyttöliittymäframeworkkiin.

——————————————————————————————————————————————

MINUN VASTAUS
Tarkoittaako tuo suomeksi tätä:
Lääkäri on yleisesti ottaen kömpelö tekemään sähkömienen töitä.

jos niin tämä keskustelu, on pelkää trollaamista sinulta, ei mitään yritystäkään asialliseen keskusteluun, MUTTA MIKSI HARRASTAT TÄTÄ TROLLAAMISTA NIIN PALJON?

Lue lisää

"Tarkoittaako tuo suomeksi tätä:
Lääkäri on yleisesti ottaen kömpelö tekemään sähkömienen töitä."

Tarkoittaa suomeksi sitä, että LCL museotavaraa ja aiheuttaa paljon teknistä velkaa heti suoraan kun vain käyttää sitä, ja että Lazarus on kelvoton käyttöliittymäohjelmointiin. Se kun on kömpelö ja perusasiat eivät toimi helposti, eikö vain?

ex-delphisti kirjoitti:

Näissä ohjelmointi asioissa kannattaa olla avoin mielinen ja tutustua uusiin (vaikka itselle uusiin) asioihin. Aikoinaan juuri olio-ohjelmoinnin jutun älyäminen oli vuonna 1998 itselle se kova juttu, innostuin siitä tosi paljon kun kävin läpi Opeta itsellesi C 21 päivässä -kirjaa. Ohjelmointi on kiinnostanut juuri siksi itseäni jo noin 30 vuotta koska siinä ei ole koskaan valmis ja aina kiva "hiffata" uusia asioita :)

Lue lisää

Kyllä ohjelmoinnissa voi saavuttaa sen tason että on valmis.

Sanoisin että se menee jossain siellä kun tekee tekoälyn mikä ohjelmoi suurelta osin itse. Aika korkealla siis.

M-Kar kirjoitti:

Ei minulla ole tässä mitään oppimistarvetta.

Konreettinen esimerkki vaikka se, että tekee Lazaruksella sen lomakkeen niin ei toimi Ctrl ja Ctrl - näppäimet että skaalaisi.

Toisin sanoen, Lazaruksella on hankalaa tehdä näinkin yksinkertainen käyttöliittymä kuin vaikka tämä suomi24 näkymä tässä missä menu joka menee itsekseen piiloon ja tekstiä muutama ruudullinen.

Lue lisää

SINUN VIESTISTÄ
Ei minulla ole tässä mitään oppimistarvetta.

MINUN VASTAUS
Jollei tunne asioita, ei pidä myöskään mennä väittämään että jokin on jotain.

——————————————————————————————————————————————
SINUN VIESTISTÄ
Konreettinen esimerkki vaikka se, että tekee Lazaruksella sen lomakkeen niin ei toimi Ctrl ja Ctrl - näppäimet että skaalaisi.

MINUN VASTAUS
Mikään ohjelmointi ympäristö ei saisi varat näppäimistön tapahtumia mihinkään ennakolta, niiden käyttötarkoitus ja niihin kytketyt tapahtumat pitää säilyttää ohjelmoijan aseteltavissa.

Kuvassa on näytetty kuinka luet käyttäjän painamat TILANVAIHTO NÄPPÄIMET. Ohjelmoija itse laittaa mäppäinten painamiselle merkityksen. Kuvassa CTRL ja näppäin yhdistelmä nostaa esiin viestiikkunan jossa kerrotaan painettu näppäin yhdistelmä.
https://i.imgur.com/Nctgll4.png

——————————————————————————————————————————————

SINUN VIESTISTÄ
Toisin sanoen, Lazaruksella on hankalaa tehdä näinkin yksinkertainen käyttöliittymä kuin vaikka tämä suomi24 näkymä tässä missä menu joka menee itsekseen piiloon ja tekstiä muutama ruudullinen.

MINUN VASTAUS
Lazaruksen pääpaino on työpöytäsovellukset. Kukaan ei valitse Lazarusta kun tarvitaan sovellus palvelinkäyttöön, kuten ei myöskään kukaan ihminen mene sähkömiehen tykö, kun hänellä on kipuja selässä.

——————————————————————————————————————————————
JA YLEISETI OTTAEN
Vaikeus asioiden suhteen on kiinni tekijästä. Lapsi joka on 1 - 2 vuotta vanha, ei koe itsensä ilaisua helppona puhumalla, mutta harvalle se on 10 vuoden ikäisenä mikään onglma.

Sinä olet pyörinyt täällä itseäsi kehumassa, kuinka osaat ohjelmoida joka vuosi uudella ohjelmointi kielellä. Tätä on kestänyt kuka ties yli kymmenen vuotta. Heti kun käsittelyyn tulee jokin yksittäinen ohjelmointikieli ja sen perusasiat, niin sinä koet asiat vaikeina, tai jopa mahdottomina tehdä. Mihin sinä olet tuhlannut ne toistakymmentä vuotta, tai jopa omien sanojesi mukaan 27 vuotta.

Turbo-Urpo kirjoitti:

SINUN VIESTISTÄ
Ei minulla ole tässä mitään oppimistarvetta.

MINUN VASTAUS
Jollei tunne asioita, ei pidä myöskään mennä väittämään että jokin on jotain.

——————————————————————————————————————————————
SINUN VIESTISTÄ
Konreettinen esimerkki vaikka se, että tekee Lazaruksella sen lomakkeen niin ei toimi Ctrl ja Ctrl - näppäimet että skaalaisi.

MINUN VASTAUS
Mikään ohjelmointi ympäristö ei saisi varat näppäimistön tapahtumia mihinkään ennakolta, niiden käyttötarkoitus ja niihin kytketyt tapahtumat pitää säilyttää ohjelmoijan aseteltavissa.

Kuvassa on näytetty kuinka luet käyttäjän painamat TILANVAIHTO NÄPPÄIMET. Ohjelmoija itse laittaa mäppäinten painamiselle merkityksen. Kuvassa CTRL ja näppäin yhdistelmä nostaa esiin viestiikkunan jossa kerrotaan painettu näppäin yhdistelmä.
https://i.imgur.com/Nctgll4.png

——————————————————————————————————————————————

SINUN VIESTISTÄ
Toisin sanoen, Lazaruksella on hankalaa tehdä näinkin yksinkertainen käyttöliittymä kuin vaikka tämä suomi24 näkymä tässä missä menu joka menee itsekseen piiloon ja tekstiä muutama ruudullinen.

MINUN VASTAUS
Lazaruksen pääpaino on työpöytäsovellukset. Kukaan ei valitse Lazarusta kun tarvitaan sovellus palvelinkäyttöön, kuten ei myöskään kukaan ihminen mene sähkömiehen tykö, kun hänellä on kipuja selässä.

——————————————————————————————————————————————
JA YLEISETI OTTAEN
Vaikeus asioiden suhteen on kiinni tekijästä. Lapsi joka on 1 - 2 vuotta vanha, ei koe itsensä ilaisua helppona puhumalla, mutta harvalle se on 10 vuoden ikäisenä mikään onglma.

Sinä olet pyörinyt täällä itseäsi kehumassa, kuinka osaat ohjelmoida joka vuosi uudella ohjelmointi kielellä. Tätä on kestänyt kuka ties yli kymmenen vuotta. Heti kun käsittelyyn tulee jokin yksittäinen ohjelmointikieli ja sen perusasiat, niin sinä koet asiat vaikeina, tai jopa mahdottomina tehdä. Mihin sinä olet tuhlannut ne toistakymmentä vuotta, tai jopa omien sanojesi mukaan 27 vuotta.

Lue lisää

V.ttu kun tuli paljon kirjoitusvirheitä.

Turbo-Urpo kirjoitti:

SINUN VIESTISTÄ
Ei minulla ole tässä mitään oppimistarvetta.

MINUN VASTAUS
Jollei tunne asioita, ei pidä myöskään mennä väittämään että jokin on jotain.

——————————————————————————————————————————————
SINUN VIESTISTÄ
Konreettinen esimerkki vaikka se, että tekee Lazaruksella sen lomakkeen niin ei toimi Ctrl ja Ctrl - näppäimet että skaalaisi.

MINUN VASTAUS
Mikään ohjelmointi ympäristö ei saisi varat näppäimistön tapahtumia mihinkään ennakolta, niiden käyttötarkoitus ja niihin kytketyt tapahtumat pitää säilyttää ohjelmoijan aseteltavissa.

Kuvassa on näytetty kuinka luet käyttäjän painamat TILANVAIHTO NÄPPÄIMET. Ohjelmoija itse laittaa mäppäinten painamiselle merkityksen. Kuvassa CTRL ja näppäin yhdistelmä nostaa esiin viestiikkunan jossa kerrotaan painettu näppäin yhdistelmä.
https://i.imgur.com/Nctgll4.png

——————————————————————————————————————————————

SINUN VIESTISTÄ
Toisin sanoen, Lazaruksella on hankalaa tehdä näinkin yksinkertainen käyttöliittymä kuin vaikka tämä suomi24 näkymä tässä missä menu joka menee itsekseen piiloon ja tekstiä muutama ruudullinen.

MINUN VASTAUS
Lazaruksen pääpaino on työpöytäsovellukset. Kukaan ei valitse Lazarusta kun tarvitaan sovellus palvelinkäyttöön, kuten ei myöskään kukaan ihminen mene sähkömiehen tykö, kun hänellä on kipuja selässä.

——————————————————————————————————————————————
JA YLEISETI OTTAEN
Vaikeus asioiden suhteen on kiinni tekijästä. Lapsi joka on 1 - 2 vuotta vanha, ei koe itsensä ilaisua helppona puhumalla, mutta harvalle se on 10 vuoden ikäisenä mikään onglma.

Sinä olet pyörinyt täällä itseäsi kehumassa, kuinka osaat ohjelmoida joka vuosi uudella ohjelmointi kielellä. Tätä on kestänyt kuka ties yli kymmenen vuotta. Heti kun käsittelyyn tulee jokin yksittäinen ohjelmointikieli ja sen perusasiat, niin sinä koet asiat vaikeina, tai jopa mahdottomina tehdä. Mihin sinä olet tuhlannut ne toistakymmentä vuotta, tai jopa omien sanojesi mukaan 27 vuotta.

Lue lisää

"Jollei tunne asioita, ei pidä myöskään mennä väittämään että jokin on jotain."

Tunnen Lazaruksen heikkouksia paljonkin.

"Mikään ohjelmointi ympäristö ei saisi varat näppäimistön tapahtumia mihinkään ennakolta, niiden käyttötarkoitus ja niihin kytketyt tapahtumat pitää säilyttää ohjelmoijan aseteltavissa."

Jotkut näppäimet ovat melko vakioita että ennemminkin voi olla poikkeustilanteita joissa vakiot koukutetaan. Esim. tekstikentässä enter nappi tekee jotain ilman erillistä ohjelmointia.

"Lazaruksen pääpaino on työpöytäsovellukset."

Suomi24 on työpöytäsovellus. Se toimii myös mobiilisti ja voit testata pienentämällä ikkunan kokoa, että näet miten skaalautuu.

Tämä on sitä nykypäivän perusasioita sovellusten skaalautumisessa. 15v sitten oli ihan normaalia, että saattoi olla pari erilaista versiota käyttöliittymästä erilaisten laitteiden tarpeisiin mutta ainakin viimeiset 7v se ollut itsestäänselvyys, että sama käyttöliittymä skaalautuu.

"Kukaan ei valitse Lazarusta kun tarvitaan sovellus palvelinkäyttöön"

Ei ole ollut kyse mistään palvelinkäytöstä vaan työpöytäsovelluksesta, eli siitä käyttöliittymästä.

"Heti kun käsittelyyn tulee jokin yksittäinen ohjelmointikieli ja sen perusasiat, niin sinä koet asiat vaikeina, tai jopa mahdottomina tehdä. "

En ole missään sanonut että on mahdotonta mutta olen sanonut, että Lazarus on kelvoton käyttöliittymäohjelmointiin ja LCL muinasviritys jota käyttämällä lähinnä tekee tarpeettomasti teknistä velkaa ja joka voi "ohjata" ohjelmoijaa tekemään bugeja esim. tarpettomien tilojen tallennuksen muodossa.

Minä vain kysyn että kuinka nyt saisi Lazaruksella HELPOSTI hoidettua perusasiat niin tulee vaan selityksiä suorituskyvystä tai jostain muusta. Kyllähän minä sen tiedän että et pysty vastaamaan koska tiedän, että Lazaruksella ei pysty hoitamaan perusasioita toimimaan helposti vaan tarvitsee paljon nysväilyä eli kyse on siitä että LCL ei kelpaa työpöytäsovellusten tekemiseen.

Ajatteles nyt vaikka sitäkin kun maailman ylivoimaisesti suosituin Delphiä käyttänyt sovellus ei käyttänyt VCL:ää vaan käyttöliittymä oli kirjoitettu standardiin tapaan HTML5:lle ja Object Pascalia oli pieni kikkare mikä hoiti logiikkaa. Sitten sinä niinkuin kuvittelet että sillä LCL:llä tekisi yhtään mitään? Minkä kumman takia? Miksi ei vaan hävitä sitä roskaa pois ja tee käyttöliittymää siistimmin?

M-Kar kirjoitti:

"Jollei tunne asioita, ei pidä myöskään mennä väittämään että jokin on jotain."

Tunnen Lazaruksen heikkouksia paljonkin.

"Mikään ohjelmointi ympäristö ei saisi varat näppäimistön tapahtumia mihinkään ennakolta, niiden käyttötarkoitus ja niihin kytketyt tapahtumat pitää säilyttää ohjelmoijan aseteltavissa."

Jotkut näppäimet ovat melko vakioita että ennemminkin voi olla poikkeustilanteita joissa vakiot koukutetaan. Esim. tekstikentässä enter nappi tekee jotain ilman erillistä ohjelmointia.

"Lazaruksen pääpaino on työpöytäsovellukset."

Suomi24 on työpöytäsovellus. Se toimii myös mobiilisti ja voit testata pienentämällä ikkunan kokoa, että näet miten skaalautuu.

Tämä on sitä nykypäivän perusasioita sovellusten skaalautumisessa. 15v sitten oli ihan normaalia, että saattoi olla pari erilaista versiota käyttöliittymästä erilaisten laitteiden tarpeisiin mutta ainakin viimeiset 7v se ollut itsestäänselvyys, että sama käyttöliittymä skaalautuu.

"Kukaan ei valitse Lazarusta kun tarvitaan sovellus palvelinkäyttöön"

Ei ole ollut kyse mistään palvelinkäytöstä vaan työpöytäsovelluksesta, eli siitä käyttöliittymästä.

"Heti kun käsittelyyn tulee jokin yksittäinen ohjelmointikieli ja sen perusasiat, niin sinä koet asiat vaikeina, tai jopa mahdottomina tehdä. "

En ole missään sanonut että on mahdotonta mutta olen sanonut, että Lazarus on kelvoton käyttöliittymäohjelmointiin ja LCL muinasviritys jota käyttämällä lähinnä tekee tarpeettomasti teknistä velkaa ja joka voi "ohjata" ohjelmoijaa tekemään bugeja esim. tarpettomien tilojen tallennuksen muodossa.

Minä vain kysyn että kuinka nyt saisi Lazaruksella HELPOSTI hoidettua perusasiat niin tulee vaan selityksiä suorituskyvystä tai jostain muusta. Kyllähän minä sen tiedän että et pysty vastaamaan koska tiedän, että Lazaruksella ei pysty hoitamaan perusasioita toimimaan helposti vaan tarvitsee paljon nysväilyä eli kyse on siitä että LCL ei kelpaa työpöytäsovellusten tekemiseen.

Ajatteles nyt vaikka sitäkin kun maailman ylivoimaisesti suosituin Delphiä käyttänyt sovellus ei käyttänyt VCL:ää vaan käyttöliittymä oli kirjoitettu standardiin tapaan HTML5:lle ja Object Pascalia oli pieni kikkare mikä hoiti logiikkaa. Sitten sinä niinkuin kuvittelet että sillä LCL:llä tekisi yhtään mitään? Minkä kumman takia? Miksi ei vaan hävitä sitä roskaa pois ja tee käyttöliittymää siistimmin?

Lue lisää

27 Vuotta on pojat yrittäneet sinua opettaa, ja tuon olet oppinut, hukkaan on aikasi mennyt. Entäpä jos olisit yrittänyt tehdä ihan jotain muuta.

"Ajatteles nyt vaikka sitäkin kun maailman ylivoimaisesti suosituin Delphiä käyttänyt sovellus ei käyttänyt VCL:ää vaan käyttöliittymä oli kirjoitettu standardiin tapaan HTML5:lle ja Object Pascalia oli pieni kikkare mikä hoiti logiikkaa. Sitten sinä niinkuin kuvittelet että sillä LCL:llä tekisi yhtään mitään? Minkä kumman takia? Miksi ei vaan hävitä sitä roskaa pois ja tee käyttöliittymää siistimmin?"

Mikä on tämä sovellus, ihan mielenkiinnosta kysyn? Fruityloops?

ex-delphisti kirjoitti:

"Ajatteles nyt vaikka sitäkin kun maailman ylivoimaisesti suosituin Delphiä käyttänyt sovellus ei käyttänyt VCL:ää vaan käyttöliittymä oli kirjoitettu standardiin tapaan HTML5:lle ja Object Pascalia oli pieni kikkare mikä hoiti logiikkaa. Sitten sinä niinkuin kuvittelet että sillä LCL:llä tekisi yhtään mitään? Minkä kumman takia? Miksi ei vaan hävitä sitä roskaa pois ja tee käyttöliittymää siistimmin?"

Mikä on tämä sovellus, ihan mielenkiinnosta kysyn? Fruityloops?

Lue lisää

"Mikä on tämä sovellus, ihan mielenkiinnosta kysyn? Fruityloops? "

Skype. Tässä toteutettiin se P2P ja jokunen muu palikka Delphillä mutta käyttöliittymä sitten HTML5 API:a ja käännetty Javascriptille.

Tämä siis ilmeisesti on semmoinen "verkkosovellus" ja toimii siksi hitaasti ja surkeasti eikä työpöytäsovellus vai miten se nyt menikään Lazarus maailmassa?

ex-delphisti kirjoitti:

"Ajatteles nyt vaikka sitäkin kun maailman ylivoimaisesti suosituin Delphiä käyttänyt sovellus ei käyttänyt VCL:ää vaan käyttöliittymä oli kirjoitettu standardiin tapaan HTML5:lle ja Object Pascalia oli pieni kikkare mikä hoiti logiikkaa. Sitten sinä niinkuin kuvittelet että sillä LCL:llä tekisi yhtään mitään? Minkä kumman takia? Miksi ei vaan hävitä sitä roskaa pois ja tee käyttöliittymää siistimmin?"

Mikä on tämä sovellus, ihan mielenkiinnosta kysyn? Fruityloops?

Lue lisää

On kyllä mahdollista, että se Delphillä tehty osuus löytyy enää siitä vanhasta Windows versiosta mitä saa Windows 7:lle vielä. Tuotahan on uudelleenkirjoitettu moneen kertaan eri alustoille aikaa sitten, että Object Pascal koodia ei kokonaisuudessa enää välttämättä ole paljoa.

M-Kar kirjoitti:

On kyllä mahdollista, että se Delphillä tehty osuus löytyy enää siitä vanhasta Windows versiosta mitä saa Windows 7:lle vielä. Tuotahan on uudelleenkirjoitettu moneen kertaan eri alustoille aikaa sitten, että Object Pascal koodia ei kokonaisuudessa enää välttämättä ole paljoa.

Lue lisää

Näin se tuolla kerrotaan: https://www.quora.com/Skype-product/What-programming-language-was-Skype-originally-written-in?mid=55546

"Ladattava Windows-sovellus oli suunnilleen 50:50 Delphi (UI-puoli) ja C (verkko- ja audiopuoli)."

Ja tuo UI-puoli (User Interface) oli työpöytäsovellus, vertaisverkko puoli (PeerToPeer) eli ne Client–Server osat tehtiin C kielellä. Vertaisverkkohan vatii että koneella on molemmat Asiaks ja Palvelin puolen yhdistämään työpöytäsovellukset keskenään.

Tuli muuten just lappu eteen että pitää käynnistää kone uudestaan ison päivityksen loppuun viemiseksi, saa nähdä käynnistyykö.

Turbo-Urpo kirjoitti:

Näin se tuolla kerrotaan: https://www.quora.com/Skype-product/What-programming-language-was-Skype-originally-written-in?mid=55546

"Ladattava Windows-sovellus oli suunnilleen 50:50 Delphi (UI-puoli) ja C (verkko- ja audiopuoli)."

Ja tuo UI-puoli (User Interface) oli työpöytäsovellus, vertaisverkko puoli (PeerToPeer) eli ne Client–Server osat tehtiin C kielellä. Vertaisverkkohan vatii että koneella on molemmat Asiaks ja Palvelin puolen yhdistämään työpöytäsovellukset keskenään.

Tuli muuten just lappu eteen että pitää käynnistää kone uudestaan ison päivityksen loppuun viemiseksi, saa nähdä käynnistyykö.

Lue lisää

Tuo juttu vuodelta 2004... Ei siellä sitten ole varmaan enää riviäkään Pascalia jäljellä kun se UI-puoli uusittu ajat sitten HTML5:lle.

M-Kar kirjoitti:

"toisaalta jotkin asiat menee sitten ihan kympillä yli, kuten tuo "kaksisuuntainen tiedon kulkeminen", sillä ei mene mulla kaaliin miten voi edes kirjoittaa mitään ohjelmaa jos tieto kulkee vain yhteen suuntaan? Etenkin jos puhutaan olio-ohjelmoinnista, vai tarkoittaneeko tuo sitä että pitää vain kopioida helekkaristi asioita muistiin erilaisilla asetuksilla ja sitten ne instanssit palauttaa tuloksia niiden asetusten perusteella ja uusi kierros objekteja muistiin?"

Tilalle voi olla keskitetty paikka.

Kun olio luodaan niin sen sisältö pitäisi olla muuttumaton. Propertyt sisään luontivaiheessa ja niillä mennään instanssin eliniän ajan.

"Toisaalta miten tuommoinen yksisuuntainen tiedon kulku tapahtuu sitten JavaScriptissa ja jollakin js-frameworkilla jolla tehdään vaikka käyttöliittymä? Omasta kokemuksesta juuri JavaScriptissa niitä asetuksia ja vipuja pitääkin viljellä muistiin ihan urakalla."

Laitetaan tiedot propertyinä sisään mutta pidetään komponentit pääasiassa tilattomina ja tilan tallennukselle sitten container.

Komponentit voivat tallentaa tietoa keskitettyyn paikkaan välittämällä niille propertyinä ne funktiot millä tilaa muutetaan. Avainjuttu siis on pitää komponentit pääasiassa tilattomana. Se on se huono juttu jos on vaikka 5 komponenttia ja niillä omat tilansa ja logiikkaa kun ajetaan niin eri komponenttien sen hetkinen tila vaikuttaa siihen miten suoritus menee. Luetaan vaikka muualta jollain getterillä.

Sitten jos yksi olio vaikka poistuu jolla tila mikä vaikuttaa toisessa paikassa suoritettavaan laskentaan niin siinähän sitten on aika vakava bugi.

Siltä tiedon venksalukselta välttyy kun pitää kaiken olennaisen samassa paikassa. Sen lisäksi sen logiikan voi kirjoittaa niin, että tilan muutos tapahtuu funktiona jossa annetaan parametrina aikaisempi tila jolloin se ohjelman keskitetty tila voi olla muuttumaton.

Olio-ohjelmoinnin pioneerit ajatteli käytön niin, että ei tallenneta tilaa miten sattuu ja sen lisäksi muuttumattomana pitäminen on perusjuttuja funktionaalisuudessa.

summa(a, b) { return a b }

Eli a ja b sisään ja palautetaan tulos. Ei tarvitse niitä sijoituslauseita kylvää miten sattuu.

Lue lisää

" Olio-ohjelmoinnin pioneerit ajatteli käytön niin, että ei tallenneta tilaa miten sattuu ja sen lisäksi muuttumattomana pitäminen on perusjuttuja funktionaalisuudessa.

summa(a, b) { return a b }

Eli a ja b sisään ja palautetaan tulos. Ei tarvitse niitä sijoituslauseita kylvää miten sattuu. "


function summa(a,b:integer):integer;
begin
result := a b;
end;

Mielestäni tämä on periaatteelliselta tasolta yhtä hyvä ratkaisu.

jotainasia kirjoitti:

" Olio-ohjelmoinnin pioneerit ajatteli käytön niin, että ei tallenneta tilaa miten sattuu ja sen lisäksi muuttumattomana pitäminen on perusjuttuja funktionaalisuudessa.

summa(a, b) { return a b }

Eli a ja b sisään ja palautetaan tulos. Ei tarvitse niitä sijoituslauseita kylvää miten sattuu. "


function summa(a,b:integer):integer;
begin
result := a b;
end;

Mielestäni tämä on periaatteelliselta tasolta yhtä hyvä ratkaisu.

Lue lisää

Eihän tuossa nyt ollut kuin syntaksi ero.

Sen sijaan jos siellä funktion sisällä on vaikka Inputti.setInputField("") tai jotain vastaavaa niin silloin menee pieleen ja rankasti.

LCL:ää käyttävissä ohjemissa näkyy viljeltävän erilaisia metodien kutsumista mitkä muuttavat komponentin tilaa.

M-Kar kirjoitti:

Eihän tuossa nyt ollut kuin syntaksi ero.

Sen sijaan jos siellä funktion sisällä on vaikka Inputti.setInputField("") tai jotain vastaavaa niin silloin menee pieleen ja rankasti.

LCL:ää käyttävissä ohjemissa näkyy viljeltävän erilaisia metodien kutsumista mitkä muuttavat komponentin tilaa.

Lue lisää

Täyttä paskaa M-Karilta taas, v.ttu tuo trollaaminen olisi saatava terveelle tasolle.

Turbo-Urpo kirjoitti:

Täyttä paskaa M-Karilta taas, v.ttu tuo trollaaminen olisi saatava terveelle tasolle.

Mikähän siinä on kun tosiasioiden kertominen rassaa?

Kyllä siellä on ollut koko ajan, mutta vain file ja http -protokollaa tukevana, https on edelleen se ongelma.

Turbo-Urpo kirjoitti:

Kyllä siellä on ollut koko ajan, mutta vain file ja http -protokollaa tukevana, https on edelleen se ongelma.

Oiskohan tässä kyse siitä, että kyseiseen hommaan mitä ollaan tekemässä, on valittu väärä työkalu.