Mitä Delphin tilalle

Tavallaan joo. Lazarus on myös Debianissa vakaa jos sattuu sellaista ominaisuutta arvostamaan, että ei tarvitse olla testailemassa ja kääntelemässä niitä sovelluksia uudemmaksi vähän väliä jos sillä on merkitystä.

Se Lazarus vaan on aika paljon sellaiseen vanhojen Delphi sovellusten ylläpitoon. Uusille sovelluksille voisi miettiä kyllä jotain sopivampaa ja vanhoja sovelluksia voi sitten vähitellen siirtää uudemmalle tekniikalle.

"Lazarus kääntyy eri käyttöjärjestelmille sujuvasti samalla koodilla. Se on hyvä juttu. Ja sillä voi tehdä kompakteja exe-paketteja ilman monenlaisia ajonaikaisia kirjastoja tai ajonaikaista tulkkia. se on kätevää."

.exe:t voi unohtaa koska ne on Windows juttu. Lazarus tekee Windows ympäristössä koodia vanhentuneita rajapintoja vasten joita poistetaan parhaillaan, että siitä lähinnä seuraa harmia. Lazaruksella ei näytä olevan mitään tulevaisuutta Windows ohjelmoinnissa.

"Kumma, että esim. RichText-konmponentti ja mediaplayer-komponentti edelleenkin puuttuu Lazaruksen peruskomponenteisista."

Nuo on Deplhiin tulleet alunperin siitä, että se VCL kirjasto oli tehty lähinnä wrappaamaan WinAPI:a, jota taas hävitetään parhaillaan.

Ihan hyvästä syystä tuollaisia ei ole kun Lazarus toimii muualla kuin Windowsissa. Ja jos jostain poikkeussyystä vielä tekohengittää vanhoja ohjelmia Windowsissa, ihan hyvä että saa katkottua riippuvuuksia pilaantuvasta WinAPI koodista.

Ohjelmointikieli on vähän sivuseikka, uuden omaksuu niin nopeasti.

Lazaruksella ja Delphillä on aika vähän käyttöä uusien sovelluksien tekemisessä.

Hehee! IDE korjautui Linuxin puolella kerta laakista (Ubuntu Gnome 17.04)

Seuraavat komennot näytti "resolution: 96x96 dots per inch", vaikka muutoin skaalatut asetukset Gnomessa onkin?

xdpyinfo | grep dots

Korjausasetus:
xrandr --dpi 144x144

Voila! Lazaruksen IDE näyttää nyt samalta kuin Windowsin puolella :)

Hienoa!

"M-Kar, et taida olla Windows-fani muutenkaan"

Suhtaudun neutraalisti. Ei minulla ole mitään Windowsia vastaan.

"mutta tarkoitatko, että Windows on pian menneen talven lumia?"

En. Kyllä Windows pysyy pitkään markkinoilla.

"Ja Windows-ohjelmille käyttöä siis myös?"

Windowsille tehty viimeisen 10v aikana olemattoman vähän natiiveja sovelluksia. Lähes kaikki Windowsilla käytettävät sovellukset toimivat standardilla HTML5 tekniikalla ja natiivisti on pääasiassa viihdesovelluksia ja sitten on muutama ikivanha ja isolla rahalla ylläpidetty työkalusovellus mitä modernisoidaan kaiken aikaa.

"Nuo on Deplhiin tulleet alunperin siitä, että se VCL kirjasto oli tehty lähinnä wrappaamaan WinAPI:a, jota taas hävitetään parhaillaan.-"

"Mitä tilalle on tulossa"

90-luvun alussa tuli jo MFC mikä wrappasi sitä samaan tapaan kuin VCL. 2000-luvun alussa tuli .NET ja nykyisin on natiivina WinRT.

Kaikkia vanhoja rajapintoja hävitetään joten sovellukset tarvitsisi vähintäänkin kääntää uusiksi Visual C 2015 versiolla, .NET 4.x:lle, WinRT:lle tai sitten tehdä standarditekniikalla.

Siellä on riippuvuuksia vanhaan WinAPI:n että odotettavasti korkeammantason rajapinnan käyttämä toiminto joka on riippuvainen WinAPI:sta, pitää sitä toimintoa WinAPI:ssa. Sitä mukaa kun korkeamman tason rajapinnat vanhenee, niitä riisutaan WinAPI:sta pois.

,"vai tarkoitatko, että koko Windows on kuolemassa"

En usko Windowsin katoavan mihinkään lähitulevaisuudessa. Paskat ysärisovellukset kyllä menee uusiksi. Uudet ohjelmat harvemmin ovat riippuvaisia Windowsista millään tavalla.

"Graafinen käyttöliittymä säilynee kaikkialla joka tapauksessa käyttöjärjestelmäsä riippumatta (käyttäjäsyötteet texboxilla, tapahtumat pyydetään klikkauksilla ym. kaikki tämä lomakkeilla jne. jne.) Jollakin kielellä näitä käyttäen aina ohjelmoidaan."

Tällä hetkellä lähes aina Javascriptillä tai kielellä josta saadaan käännettyä Javascriptiksi.

"Mikä se executable-tiedosto muissa järjestelmissä sitten on, ohjelma on aina jossain tiedostossa josta se käynnistetään ilmeiestikin?"

Suurin osa ohjelmista käynnistetään linkistä joka avaa ohjelman selainikkunaan.

"Jos rajapinnat vanhenee, eikö Lazarustiimi pysty tähän reagoimaan uusilla ratkaisuilla?"

Käytännössä ei. Lazarusta ohjelmoidaan kuin 90-luvulla ja tämän LCL kirjasto on kasa paskaa. Pascal kieleltä ollaan tuomassa LLVM:n, että sitä saadaan varmaan kohta käännettyä Javascriptiksi mutta kyllä tuohon tarvitsisi jonkun järjellisen käyttöliittymäframeworkin/kirjaston.

Lazarusporukka ei ole millään tavalla yrittänyt edes tehdä siitä nykyaikaista, intressit ovat ennemminkin muinaisten Delphillä kirjoitettujen sovelluksien siirtämisessä Lazaruksessa ajettavaksi, että niille saadaan lisää käyttöikää.

Tuon tason muutoksien tekeminen laajoissa ohjelmissa ei tapahdu heti, eikä Lazarusporukka ole vielä edes aloittanut joten ei ole syytä odottaa mitään merkittävää parannusta missään järjellisessä ajassa.

M-Kar kirjoitti:

"M-Kar, et taida olla Windows-fani muutenkaan"

Suhtaudun neutraalisti. Ei minulla ole mitään Windowsia vastaan.

"mutta tarkoitatko, että Windows on pian menneen talven lumia?"

En. Kyllä Windows pysyy pitkään markkinoilla.

"Ja Windows-ohjelmille käyttöä siis myös?"

Windowsille tehty viimeisen 10v aikana olemattoman vähän natiiveja sovelluksia. Lähes kaikki Windowsilla käytettävät sovellukset toimivat standardilla HTML5 tekniikalla ja natiivisti on pääasiassa viihdesovelluksia ja sitten on muutama ikivanha ja isolla rahalla ylläpidetty työkalusovellus mitä modernisoidaan kaiken aikaa.

"Nuo on Deplhiin tulleet alunperin siitä, että se VCL kirjasto oli tehty lähinnä wrappaamaan WinAPI:a, jota taas hävitetään parhaillaan.-"

"Mitä tilalle on tulossa"

90-luvun alussa tuli jo MFC mikä wrappasi sitä samaan tapaan kuin VCL. 2000-luvun alussa tuli .NET ja nykyisin on natiivina WinRT.

Kaikkia vanhoja rajapintoja hävitetään joten sovellukset tarvitsisi vähintäänkin kääntää uusiksi Visual C 2015 versiolla, .NET 4.x:lle, WinRT:lle tai sitten tehdä standarditekniikalla.

Siellä on riippuvuuksia vanhaan WinAPI:n että odotettavasti korkeammantason rajapinnan käyttämä toiminto joka on riippuvainen WinAPI:sta, pitää sitä toimintoa WinAPI:ssa. Sitä mukaa kun korkeamman tason rajapinnat vanhenee, niitä riisutaan WinAPI:sta pois.

,"vai tarkoitatko, että koko Windows on kuolemassa"

En usko Windowsin katoavan mihinkään lähitulevaisuudessa. Paskat ysärisovellukset kyllä menee uusiksi. Uudet ohjelmat harvemmin ovat riippuvaisia Windowsista millään tavalla.

"Graafinen käyttöliittymä säilynee kaikkialla joka tapauksessa käyttöjärjestelmäsä riippumatta (käyttäjäsyötteet texboxilla, tapahtumat pyydetään klikkauksilla ym. kaikki tämä lomakkeilla jne. jne.) Jollakin kielellä näitä käyttäen aina ohjelmoidaan."

Tällä hetkellä lähes aina Javascriptillä tai kielellä josta saadaan käännettyä Javascriptiksi.

"Mikä se executable-tiedosto muissa järjestelmissä sitten on, ohjelma on aina jossain tiedostossa josta se käynnistetään ilmeiestikin?"

Suurin osa ohjelmista käynnistetään linkistä joka avaa ohjelman selainikkunaan.

"Jos rajapinnat vanhenee, eikö Lazarustiimi pysty tähän reagoimaan uusilla ratkaisuilla?"

Käytännössä ei. Lazarusta ohjelmoidaan kuin 90-luvulla ja tämän LCL kirjasto on kasa paskaa. Pascal kieleltä ollaan tuomassa LLVM:n, että sitä saadaan varmaan kohta käännettyä Javascriptiksi mutta kyllä tuohon tarvitsisi jonkun järjellisen käyttöliittymäframeworkin/kirjaston.

Lazarusporukka ei ole millään tavalla yrittänyt edes tehdä siitä nykyaikaista, intressit ovat ennemminkin muinaisten Delphillä kirjoitettujen sovelluksien siirtämisessä Lazaruksessa ajettavaksi, että niille saadaan lisää käyttöikää.

Tuon tason muutoksien tekeminen laajoissa ohjelmissa ei tapahdu heti, eikä Lazarusporukka ole vielä edes aloittanut joten ei ole syytä odottaa mitään merkittävää parannusta missään järjellisessä ajassa.

Lue lisää

Tyhjä tynnyri kaikista eniten kolisee.

M-Kar. Lazaruksella voi siis tehdä ohjelmia Mac ja Linux ypäristöön ja vähät välittää näinWIN:sta. Eli se pascal-kielikö siinä närästää ja sen rajoitetteet(?) vai koko tapa tehdä graafisia sovelluksia Lazaruksella. Kysehän on lopulta siitä, miten tehdää mahdollisimman joustavasti toimivia ja käytettäviä ohjelmia käyttäjille, jotka niitä tarvitsevat.

Lazarusko kirjoitti:

M-Kar. Lazaruksella voi siis tehdä ohjelmia Mac ja Linux ypäristöön ja vähät välittää näinWIN:sta. Eli se pascal-kielikö siinä närästää ja sen rajoitetteet(?) vai koko tapa tehdä graafisia sovelluksia Lazaruksella. Kysehän on lopulta siitä, miten tehdää mahdollisimman joustavasti toimivia ja käytettäviä ohjelmia käyttäjille, jotka niitä tarvitsevat.

Lue lisää

"Eli se pascal-kielikö siinä närästää ja sen rajoitetteet(?) vai koko tapa tehdä graafisia sovelluksia Lazaruksella."

Pascal kieli on kyllä kauhea ja sehän ei ole minkään standardin mukainen enää. Heikko ilmaisukyky.

Mutta tuohan ei rajoitu pelkästään siihen se ankeus, vaan pitää ottaa huomioon stabiilius. Lazarus on käytännössä stabiili vain tyyliin jollain Debianilla. Muualle jos haluaa turvapäivitykset niin pyöräytetään Lazarusta uudemmaksi mikä vaikuttaa yhteensopivuuksiin.

Lazaruksen LCL komponenttikirjasto on karmea, tuohan ohjailee siihen, että komponentit tallentavat omaa tilaansa komponentteihin. Eli jos teet vaikka tekstinsyöttökentän niin työkalu ohjaa siihen, että sen kentän sisältö ja muutokset siihen tapahtuisi siinä komponentissa.

Tuollainen sotku oikein kerjää bugeja. Joku voi todistaa vapaasti vääräksi näyttämällä miten Lazaruksella käytetään LCL:ää tilattomasti. En sano etteikö onnistuisi mutta varmasti järkyttävää säätämistä.

Lazaruksella sovellukset ovat hölmösti riippuvaisia käyttöjärjestelmästä tai laitearkkitehtuurista. Sillä ei oikein saa käännettyä sovellusta kertaalleen niin, että sama sovellus toimisi sellaisenaan vaikka iPadissa tai PS4:ssä tai missä nyt haluaakaan. Se ei nimittäin standardia HTML5 API:a ympäristönä vaan sisältää virityksiä millä käytetään natiivisti käännettyjä rajapintoja.

Kaikki nuo harmit voi kiteyttää niin, että ei ole olemassa mitään tilannetta missä Lazarus olisi hyvä vaihtoehto uuteen projektiin. Vanhojen Dephiviritysten tekohengitykseen käy jotka odottavat uudelleenkirjoitusta.

"Kysehän on lopulta siitä, miten tehdää mahdollisimman joustavasti toimivia ja käytettäviä ohjelmia käyttäjille, jotka niitä tarvitsevat."

Ja miksi sitten joka tilanteessa löytyy parempia?

Vanha-sananlasku kirjoitti:

Tyhjä tynnyri kaikista eniten kolisee.

M-Karin höpinät voi jättää 100% omaan arvoonsa.

JOS Microsoft oikeasti poistaisi Windowsista tuen noille perinteisille windows API -funktiokutsuille, ja näin pakottaisi .NET:in ainoaksi vaihtoehdoiksi (kuten tapahtuu M-Karin märissä unissa) niin silloin lakkaisi toimimasta KAIKKI nämä:

mingw-gcc:llä tehdyt ohjelmat.
cygwin gcc -yhdistelmällä tehdyt ohjelmat.
MS Visual C :lla tehdyt ohjelmat.
MS Visual basiclla tehdyt ohjelmat.
Delphillä tehdyt ohjelmat.

Pitäisi oikastaan tarkistaa, moniko näistä:

Firefox
Google Chrome
Opera
Microsoft Internet Explorer
Microsoft Edge

on ns. perinteinen Windows -ohjelma (käyttää Windows API -kutsuja joko WINAPI32 tai WINAPI64) ja moniko on .NET assembly (joista suurin osa on tehty Visual C#:lla, osa myös Visual basic .NET -versiolla).

Mikäli suurin osa noista on ns. perinteisiä Windows -ohjelmia, niin silloin on äärimäisen epätodennäköistä, että Microsoft poistaisi mitään olennaisia Windows API -kutsuja käyttöjärjestelmästään, eli tämä todistaisi M-Karin höpinät 100% paskanjauhamiseksi.

Koska tämä ei tekisi pelkästäänDelphi -ohjelmia kelvottomiksi, vaan sillon suurin osa ylläluetelluista selaimista lakkaisi myös toimimasta.

Käsittääkseni esim. FIREFOX on tehty "C ":lla, EI C#:lla.

"C " tuottaa perinteisiä Windows API:a käyttäviä ohjelmia, sillä ei voi tehdä .NET assemblyjä.

Eli jos M-Kar olisi oikeassa (mitä en usko) niin silloin myös Firefoxin päivät Windows -käyttöjärjestelmissä olisivat luetut.

En ole teknisesti tutkinut asiaa (ainakaan vielä) mutta luulenpa, että Microsoft Egde on
noista AINOA jossa on saatettu käyttää .NET -ohjelmointia, kaikki muut ovat käsittääkseni perinteisiä Windows -ohjelmia jotka tarvitsevat toimiakseen sen perinteisen Windows API:n.

Samoin:

JOS M-Kar olisi oikeassa, niin silloin työmarkkinoilla olisi suuri kysyntä nimenomaan C# -koodaajille, ja kaikki muut kielet kuin C#, niiden osaajat olisivat tervemenneitä työttömyyskortistoon kunnes ovat opetelleet koodaamaan C#:lla.

Kuitenkin työmarkkinoilla haetaan jatkuvasti koodaajia ainakin näille:

C
"C "
Java
Php
Python
NodeJS

jne.

Onko joku muka toteuttanut .NET -pohjaisen JAVA -ajoympäristön? Tietääkseni EI OLE.

Silloin JAVA olisi koodausvälineenä arvoton Windows -käyttöjärjestelmässä.

Toki JAVA ajoympäristöä varmaan edelleen tuetaan linuxissa, mutta vaikea kuvitella, että yritysmaailmassa laskettaisiin noin paljoa linuxin varaan!

Ylläoleva lienee riittävä osoitus M-Karin täydellisestä ymmärtämättömyydestä ohjelmistoasioissa.

Perinteinen windows API EI OLE katoamassa yhtään mihinkään.

Esimerkiksi TextOut windows API -funktio tulee toimimaan 50 vuoden päässä aivan samoin kuin nytkin, ainoa muutos on se, että Microsoft saattaa pudottaa jossain vaiheessa tuen pois TextOut windows API32 -versiolta ja ilmoittaa, että jatkossa toimii vain TextOut windows API64 -versio.

Ja tuohonkin muutokseen menee VÄHINTÄÄN 10 vuotta todennäköisemmin 25-50 vuotta.

ELI TextOut windows API32 -versio toimii 100% varmuudella 31.12.2028 saakka, ja hyvin todennäköisesti aljon pidempäänkin, eli todennäköisesti ainakin 31.12.2068 saakka.

Näinollen Delphiä ei siis tarvitse korvata millään, kuten ei myöskään näitä:

mingw-gcc
cygwin gcc -yhdistelmä
MS Visual C
MS Visual basic

Windows API tulee siis olemaan jopa 32 -bittisen versionkin osalta vähintään 10, todennäköisesti 50 vuotta, ja 64 -bittisen version osalta vähintään 100 vuotta, todennäköisesti 1000 vuotta.

Jätä siis M-Karin roskapuheet omaan arvoonsa, niillä ei ole käytännön merkitystä.

WinAPI_Rules kirjoitti:

M-Karin höpinät voi jättää 100% omaan arvoonsa.

JOS Microsoft oikeasti poistaisi Windowsista tuen noille perinteisille windows API -funktiokutsuille, ja näin pakottaisi .NET:in ainoaksi vaihtoehdoiksi (kuten tapahtuu M-Karin märissä unissa) niin silloin lakkaisi toimimasta KAIKKI nämä:

mingw-gcc:llä tehdyt ohjelmat.
cygwin gcc -yhdistelmällä tehdyt ohjelmat.
MS Visual C :lla tehdyt ohjelmat.
MS Visual basiclla tehdyt ohjelmat.
Delphillä tehdyt ohjelmat.

Pitäisi oikastaan tarkistaa, moniko näistä:

Firefox
Google Chrome
Opera
Microsoft Internet Explorer
Microsoft Edge

on ns. perinteinen Windows -ohjelma (käyttää Windows API -kutsuja joko WINAPI32 tai WINAPI64) ja moniko on .NET assembly (joista suurin osa on tehty Visual C#:lla, osa myös Visual basic .NET -versiolla).

Mikäli suurin osa noista on ns. perinteisiä Windows -ohjelmia, niin silloin on äärimäisen epätodennäköistä, että Microsoft poistaisi mitään olennaisia Windows API -kutsuja käyttöjärjestelmästään, eli tämä todistaisi M-Karin höpinät 100% paskanjauhamiseksi.

Koska tämä ei tekisi pelkästäänDelphi -ohjelmia kelvottomiksi, vaan sillon suurin osa ylläluetelluista selaimista lakkaisi myös toimimasta.

Käsittääkseni esim. FIREFOX on tehty "C ":lla, EI C#:lla.

"C " tuottaa perinteisiä Windows API:a käyttäviä ohjelmia, sillä ei voi tehdä .NET assemblyjä.

Eli jos M-Kar olisi oikeassa (mitä en usko) niin silloin myös Firefoxin päivät Windows -käyttöjärjestelmissä olisivat luetut.

En ole teknisesti tutkinut asiaa (ainakaan vielä) mutta luulenpa, että Microsoft Egde on
noista AINOA jossa on saatettu käyttää .NET -ohjelmointia, kaikki muut ovat käsittääkseni perinteisiä Windows -ohjelmia jotka tarvitsevat toimiakseen sen perinteisen Windows API:n.

Samoin:

JOS M-Kar olisi oikeassa, niin silloin työmarkkinoilla olisi suuri kysyntä nimenomaan C# -koodaajille, ja kaikki muut kielet kuin C#, niiden osaajat olisivat tervemenneitä työttömyyskortistoon kunnes ovat opetelleet koodaamaan C#:lla.

Kuitenkin työmarkkinoilla haetaan jatkuvasti koodaajia ainakin näille:

C
"C "
Java
Php
Python
NodeJS

jne.

Onko joku muka toteuttanut .NET -pohjaisen JAVA -ajoympäristön? Tietääkseni EI OLE.

Silloin JAVA olisi koodausvälineenä arvoton Windows -käyttöjärjestelmässä.

Toki JAVA ajoympäristöä varmaan edelleen tuetaan linuxissa, mutta vaikea kuvitella, että yritysmaailmassa laskettaisiin noin paljoa linuxin varaan!

Ylläoleva lienee riittävä osoitus M-Karin täydellisestä ymmärtämättömyydestä ohjelmistoasioissa.

Perinteinen windows API EI OLE katoamassa yhtään mihinkään.

Esimerkiksi TextOut windows API -funktio tulee toimimaan 50 vuoden päässä aivan samoin kuin nytkin, ainoa muutos on se, että Microsoft saattaa pudottaa jossain vaiheessa tuen pois TextOut windows API32 -versiolta ja ilmoittaa, että jatkossa toimii vain TextOut windows API64 -versio.

Ja tuohonkin muutokseen menee VÄHINTÄÄN 10 vuotta todennäköisemmin 25-50 vuotta.

ELI TextOut windows API32 -versio toimii 100% varmuudella 31.12.2028 saakka, ja hyvin todennäköisesti aljon pidempäänkin, eli todennäköisesti ainakin 31.12.2068 saakka.

Näinollen Delphiä ei siis tarvitse korvata millään, kuten ei myöskään näitä:

mingw-gcc
cygwin gcc -yhdistelmä
MS Visual C
MS Visual basic

Windows API tulee siis olemaan jopa 32 -bittisen versionkin osalta vähintään 10, todennäköisesti 50 vuotta, ja 64 -bittisen version osalta vähintään 100 vuotta, todennäköisesti 1000 vuotta.

Jätä siis M-Karin roskapuheet omaan arvoonsa, niillä ei ole käytännön merkitystä.

Lue lisää

"JOS Microsoft oikeasti poistaisi Windowsista tuen noille perinteisille windows API -funktiokutsuille, ja näin pakottaisi .NET:in ainoaksi vaihtoehdoiksi (kuten tapahtuu M-Karin märissä unissa) niin silloin lakkaisi toimimasta KAIKKI nämä:

mingw-gcc:llä tehdyt ohjelmat.
cygwin gcc -yhdistelmällä tehdyt ohjelmat.
MS Visual C :lla tehdyt ohjelmat.
MS Visual basiclla tehdyt ohjelmat.
Delphillä tehdyt ohjelmat."

Visual Basicilla tehdyt ohjelmat taisi hajota jo.

Ei ne kaikkia Windows API kutsuja poista. Ne poistavat ne mitä ei tarvita Visual C 2010 ja uudempien toimimista varten. Jokaista Visual C redistributablea tuetaan 10v, että kun menee tuen ulkopuolelle niin sitten voidaan siivoilla.

Lisäksi 32-bittisen koodin tuki säilyy ainakin 10v vielä.

Se vaan, että WinAPI:a ei luvata pidettävän vakaana tai muuttumattomana, että siitä tulee vaikeuksia jos ei ole Microsoftin kääntäjä. Delphille erityisesti, sitä pitää uusia vuosittain.

"Mikäli suurin osa noista on ns. perinteisiä Windows -ohjelmia, niin silloin on äärimäisen epätodennäköistä, että Microsoft poistaisi mitään olennaisia Windows API -kutsuja käyttöjärjestelmästään, eli tämä todistaisi M-Karin höpinät 100% paskanjauhamiseksi."

En minä ole sellaista sanonutkaan. Olennaisia on ne mitä tarvitaan edelleen tuettuja Visual C 2010 redistributableja varten tai vaikka NodeJS:lle.

"Koska tämä ei tekisi pelkästäänDelphi -ohjelmia kelvottomiksi, vaan sillon suurin osa ylläluetelluista selaimista lakkaisi myös toimimasta."

Microsoftia ei oikeastaan kiinnosta muu kuin Edge ja Chromium Embedded Framework, mitä käyttää monet muut Microsoftin ohella. Siinäkään ei ole montaa WinAPI kutsua. Olennaista onkin että sitä WinAPI:a olisi mahdollisimman vähän, siihen pyrkii kaikki.

"Käsittääkseni esim. FIREFOX on tehty "C ":lla, EI C#:lla."

Firefox on tehty Rustilla. Mozilla teki uuden ohjelmointikielen millä käänsi Firefoxin. Siinä on siis huolella siivottu WinAPI kutsut pois. Chromium Embedded Framework on sitten C :aa.

" "C " tuottaa perinteisiä Windows API:a käyttäviä ohjelmia, sillä ei voi tehdä .NET assemblyjä."

C :lla voi kääntää vaikka .wasm:lle, täysin irti WinAPI:sta.

"En ole teknisesti tutkinut asiaa (ainakaan vielä) mutta luulenpa, että Microsoft Egde on
noista AINOA jossa on saatettu käyttää .NET -ohjelmointia, kaikki muut ovat käsittääkseni perinteisiä Windows -ohjelmia jotka tarvitsevat toimiakseen sen perinteisen Windows API:n."

Ne ovat kaikki käännetty natiivikoodille IA32/AMD64/ARM64 ja niissä on WinAPI:a minimaalinen määrä. Nähdäkseni WinAPI kutistuu hiljalleen pieneksi että se on sitä varten, että käynnistetään jokin ajoympäristö. Toki siellä on vielä kaikkea nappia yms. ylimääräistä KOSKA ne on MFC:ssä, Visual C redistributablessa tuettuna.

"JOS M-Kar olisi oikeassa, niin silloin työmarkkinoilla olisi suuri kysyntä nimenomaan C# -koodaajille, ja kaikki muut kielet kuin C#, niiden osaajat olisivat tervemenneitä työttömyyskortistoon kunnes ovat opetelleet koodaamaan C#:lla."

Miksi ihmeessä? Suurinta osaa ohjelmista ei tehdä Microsoftin rajapinnoille.

"Kuitenkin työmarkkinoilla haetaan jatkuvasti koodaajia ainakin näille:"

Niin? Muista että suurin osa ohjelmista tehdään palvelimille tai sulautetuille joissa on jokin Linuxia käyttävä käyttöjärjestelmä.

"Silloin JAVA olisi koodausvälineenä arvoton Windows -käyttöjärjestelmässä."

Aika kuollut se onkin. Javaa tehdään kyllä Windowsissa vaikka Android SDK:ssa ja ehkä Google Web Toolkitissa käännellään selaimille.

"Toki JAVA ajoympäristöä varmaan edelleen tuetaan linuxissa, mutta vaikea kuvitella, että yritysmaailmassa laskettaisiin noin paljoa linuxin varaan!"

Yritysmaailma toimii 85%:sti linuxien varassa. Vitun kallista uusia kerta vuoteen Delphiä kun voi käyttää maksuttomia kehitysvälineitä.

M-Kar kirjoitti:

"Eli se pascal-kielikö siinä närästää ja sen rajoitetteet(?) vai koko tapa tehdä graafisia sovelluksia Lazaruksella."

Pascal kieli on kyllä kauhea ja sehän ei ole minkään standardin mukainen enää. Heikko ilmaisukyky.

Mutta tuohan ei rajoitu pelkästään siihen se ankeus, vaan pitää ottaa huomioon stabiilius. Lazarus on käytännössä stabiili vain tyyliin jollain Debianilla. Muualle jos haluaa turvapäivitykset niin pyöräytetään Lazarusta uudemmaksi mikä vaikuttaa yhteensopivuuksiin.

Lazaruksen LCL komponenttikirjasto on karmea, tuohan ohjailee siihen, että komponentit tallentavat omaa tilaansa komponentteihin. Eli jos teet vaikka tekstinsyöttökentän niin työkalu ohjaa siihen, että sen kentän sisältö ja muutokset siihen tapahtuisi siinä komponentissa.

Tuollainen sotku oikein kerjää bugeja. Joku voi todistaa vapaasti vääräksi näyttämällä miten Lazaruksella käytetään LCL:ää tilattomasti. En sano etteikö onnistuisi mutta varmasti järkyttävää säätämistä.

Lazaruksella sovellukset ovat hölmösti riippuvaisia käyttöjärjestelmästä tai laitearkkitehtuurista. Sillä ei oikein saa käännettyä sovellusta kertaalleen niin, että sama sovellus toimisi sellaisenaan vaikka iPadissa tai PS4:ssä tai missä nyt haluaakaan. Se ei nimittäin standardia HTML5 API:a ympäristönä vaan sisältää virityksiä millä käytetään natiivisti käännettyjä rajapintoja.

Kaikki nuo harmit voi kiteyttää niin, että ei ole olemassa mitään tilannetta missä Lazarus olisi hyvä vaihtoehto uuteen projektiin. Vanhojen Dephiviritysten tekohengitykseen käy jotka odottavat uudelleenkirjoitusta.

"Kysehän on lopulta siitä, miten tehdää mahdollisimman joustavasti toimivia ja käytettäviä ohjelmia käyttäjille, jotka niitä tarvitsevat."

Ja miksi sitten joka tilanteessa löytyy parempia?

Lue lisää

"Pascal kieli on kyllä kauhea ja sehän ei ole minkään standardin mukainen enää. Heikko ilmaisukyky."

M-kar on tunnettu delphivihaaja!

Delphin (ja Lazaruksen) kieli on objectpascal.

objectpascalin suhde pascaliin on sama kuin "C ":n suhde "C":hen.

objectpascalin kieli on erittäin ilmaisukykyinen ja toimii hyvin eri ympäristöissä!

M-Karin väitteelle heikosta ilmaisukyvystä ei ole yhtään järkiperustetta.

objectpascalin kieli on paitsi erittäin ilmaisukykyinen, myös hyvin selkeä, ja jo kielen selkeys on iso etu, koska se auttaa vähentämään muille kielille tyypillisiä ohjelmointivirheitä, ja selkeys on myös etu, kun muokataan jo olemassaolevaa koodia.

M-Kar kirjoitti:

"JOS Microsoft oikeasti poistaisi Windowsista tuen noille perinteisille windows API -funktiokutsuille, ja näin pakottaisi .NET:in ainoaksi vaihtoehdoiksi (kuten tapahtuu M-Karin märissä unissa) niin silloin lakkaisi toimimasta KAIKKI nämä:

mingw-gcc:llä tehdyt ohjelmat.
cygwin gcc -yhdistelmällä tehdyt ohjelmat.
MS Visual C :lla tehdyt ohjelmat.
MS Visual basiclla tehdyt ohjelmat.
Delphillä tehdyt ohjelmat."

Visual Basicilla tehdyt ohjelmat taisi hajota jo.

Ei ne kaikkia Windows API kutsuja poista. Ne poistavat ne mitä ei tarvita Visual C 2010 ja uudempien toimimista varten. Jokaista Visual C redistributablea tuetaan 10v, että kun menee tuen ulkopuolelle niin sitten voidaan siivoilla.

Lisäksi 32-bittisen koodin tuki säilyy ainakin 10v vielä.

Se vaan, että WinAPI:a ei luvata pidettävän vakaana tai muuttumattomana, että siitä tulee vaikeuksia jos ei ole Microsoftin kääntäjä. Delphille erityisesti, sitä pitää uusia vuosittain.

"Mikäli suurin osa noista on ns. perinteisiä Windows -ohjelmia, niin silloin on äärimäisen epätodennäköistä, että Microsoft poistaisi mitään olennaisia Windows API -kutsuja käyttöjärjestelmästään, eli tämä todistaisi M-Karin höpinät 100% paskanjauhamiseksi."

En minä ole sellaista sanonutkaan. Olennaisia on ne mitä tarvitaan edelleen tuettuja Visual C 2010 redistributableja varten tai vaikka NodeJS:lle.

"Koska tämä ei tekisi pelkästäänDelphi -ohjelmia kelvottomiksi, vaan sillon suurin osa ylläluetelluista selaimista lakkaisi myös toimimasta."

Microsoftia ei oikeastaan kiinnosta muu kuin Edge ja Chromium Embedded Framework, mitä käyttää monet muut Microsoftin ohella. Siinäkään ei ole montaa WinAPI kutsua. Olennaista onkin että sitä WinAPI:a olisi mahdollisimman vähän, siihen pyrkii kaikki.

"Käsittääkseni esim. FIREFOX on tehty "C ":lla, EI C#:lla."

Firefox on tehty Rustilla. Mozilla teki uuden ohjelmointikielen millä käänsi Firefoxin. Siinä on siis huolella siivottu WinAPI kutsut pois. Chromium Embedded Framework on sitten C :aa.

" "C " tuottaa perinteisiä Windows API:a käyttäviä ohjelmia, sillä ei voi tehdä .NET assemblyjä."

C :lla voi kääntää vaikka .wasm:lle, täysin irti WinAPI:sta.

"En ole teknisesti tutkinut asiaa (ainakaan vielä) mutta luulenpa, että Microsoft Egde on
noista AINOA jossa on saatettu käyttää .NET -ohjelmointia, kaikki muut ovat käsittääkseni perinteisiä Windows -ohjelmia jotka tarvitsevat toimiakseen sen perinteisen Windows API:n."

Ne ovat kaikki käännetty natiivikoodille IA32/AMD64/ARM64 ja niissä on WinAPI:a minimaalinen määrä. Nähdäkseni WinAPI kutistuu hiljalleen pieneksi että se on sitä varten, että käynnistetään jokin ajoympäristö. Toki siellä on vielä kaikkea nappia yms. ylimääräistä KOSKA ne on MFC:ssä, Visual C redistributablessa tuettuna.

"JOS M-Kar olisi oikeassa, niin silloin työmarkkinoilla olisi suuri kysyntä nimenomaan C# -koodaajille, ja kaikki muut kielet kuin C#, niiden osaajat olisivat tervemenneitä työttömyyskortistoon kunnes ovat opetelleet koodaamaan C#:lla."

Miksi ihmeessä? Suurinta osaa ohjelmista ei tehdä Microsoftin rajapinnoille.

"Kuitenkin työmarkkinoilla haetaan jatkuvasti koodaajia ainakin näille:"

Niin? Muista että suurin osa ohjelmista tehdään palvelimille tai sulautetuille joissa on jokin Linuxia käyttävä käyttöjärjestelmä.

"Silloin JAVA olisi koodausvälineenä arvoton Windows -käyttöjärjestelmässä."

Aika kuollut se onkin. Javaa tehdään kyllä Windowsissa vaikka Android SDK:ssa ja ehkä Google Web Toolkitissa käännellään selaimille.

"Toki JAVA ajoympäristöä varmaan edelleen tuetaan linuxissa, mutta vaikea kuvitella, että yritysmaailmassa laskettaisiin noin paljoa linuxin varaan!"

Yritysmaailma toimii 85%:sti linuxien varassa. Vitun kallista uusia kerta vuoteen Delphiä kun voi käyttää maksuttomia kehitysvälineitä.

Lue lisää

"Firefox on tehty Rustilla. Mozilla teki uuden ohjelmointikielen millä käänsi Firefoxin. Siinä on siis huolella siivottu WinAPI kutsut pois"

HahHaa, mikä vitsi !

Jos Firefoxista oikeasti olisi "huolella siivottu WinAPI kutsut pois" kuten M-Kar väittää, niin eipä Firefox Windowsissa voisi edes toimia !

Kas kun se käyttää WinAPIa ainakin:

Näytölle piirtämiseen (teksti ja grafiikka)
Näppäimistön lukemiseen
Hiiren liikkeiden ja klikkausten käsittelyyn
Tietoliikenteeseen (pääosin TCP/IP), ja http ja https -tuki on Firefoxissa TCP/IP:n päälle rakennettu.
Kryptovahvojen satunnaislukujen luontiin, mikä https -yhteyksien toteutuksessa on välttämätöntä. Jossain vanhassa Debianissa (ja sen johdannaisissa) oli tässä isoja tietoturvaongelmia, koska järjestelmän generoimat satunnaisluvut eivät olleet aidosti satunnaisia, ja siksi vanhojen debianien https -yhteydet olivat osaavien tahojen helposti kräkättävissä, kun satunnaisuvut olivat luokattoman huonoja. Kas kummaa kun M-Kar kritisoi hanakasti Delphiä ja WinAPI:a, mutta debianin surkeista satunnaisluvuista ei M-Kar ole juuri tänne kirjoitellut.

Widowsissa uusin järjestelmä, jossa kryptovahvojen satunnaislukujen generoinnissa oli laatuongelmia, oli Windows 2000, ja Windows XP:ssä tuokin ongelma oli jo korjattu.

M-Kar kirjoitti:

"JOS Microsoft oikeasti poistaisi Windowsista tuen noille perinteisille windows API -funktiokutsuille, ja näin pakottaisi .NET:in ainoaksi vaihtoehdoiksi (kuten tapahtuu M-Karin märissä unissa) niin silloin lakkaisi toimimasta KAIKKI nämä:

mingw-gcc:llä tehdyt ohjelmat.
cygwin gcc -yhdistelmällä tehdyt ohjelmat.
MS Visual C :lla tehdyt ohjelmat.
MS Visual basiclla tehdyt ohjelmat.
Delphillä tehdyt ohjelmat."

Visual Basicilla tehdyt ohjelmat taisi hajota jo.

Ei ne kaikkia Windows API kutsuja poista. Ne poistavat ne mitä ei tarvita Visual C 2010 ja uudempien toimimista varten. Jokaista Visual C redistributablea tuetaan 10v, että kun menee tuen ulkopuolelle niin sitten voidaan siivoilla.

Lisäksi 32-bittisen koodin tuki säilyy ainakin 10v vielä.

Se vaan, että WinAPI:a ei luvata pidettävän vakaana tai muuttumattomana, että siitä tulee vaikeuksia jos ei ole Microsoftin kääntäjä. Delphille erityisesti, sitä pitää uusia vuosittain.

"Mikäli suurin osa noista on ns. perinteisiä Windows -ohjelmia, niin silloin on äärimäisen epätodennäköistä, että Microsoft poistaisi mitään olennaisia Windows API -kutsuja käyttöjärjestelmästään, eli tämä todistaisi M-Karin höpinät 100% paskanjauhamiseksi."

En minä ole sellaista sanonutkaan. Olennaisia on ne mitä tarvitaan edelleen tuettuja Visual C 2010 redistributableja varten tai vaikka NodeJS:lle.

"Koska tämä ei tekisi pelkästäänDelphi -ohjelmia kelvottomiksi, vaan sillon suurin osa ylläluetelluista selaimista lakkaisi myös toimimasta."

Microsoftia ei oikeastaan kiinnosta muu kuin Edge ja Chromium Embedded Framework, mitä käyttää monet muut Microsoftin ohella. Siinäkään ei ole montaa WinAPI kutsua. Olennaista onkin että sitä WinAPI:a olisi mahdollisimman vähän, siihen pyrkii kaikki.

"Käsittääkseni esim. FIREFOX on tehty "C ":lla, EI C#:lla."

Firefox on tehty Rustilla. Mozilla teki uuden ohjelmointikielen millä käänsi Firefoxin. Siinä on siis huolella siivottu WinAPI kutsut pois. Chromium Embedded Framework on sitten C :aa.

" "C " tuottaa perinteisiä Windows API:a käyttäviä ohjelmia, sillä ei voi tehdä .NET assemblyjä."

C :lla voi kääntää vaikka .wasm:lle, täysin irti WinAPI:sta.

"En ole teknisesti tutkinut asiaa (ainakaan vielä) mutta luulenpa, että Microsoft Egde on
noista AINOA jossa on saatettu käyttää .NET -ohjelmointia, kaikki muut ovat käsittääkseni perinteisiä Windows -ohjelmia jotka tarvitsevat toimiakseen sen perinteisen Windows API:n."

Ne ovat kaikki käännetty natiivikoodille IA32/AMD64/ARM64 ja niissä on WinAPI:a minimaalinen määrä. Nähdäkseni WinAPI kutistuu hiljalleen pieneksi että se on sitä varten, että käynnistetään jokin ajoympäristö. Toki siellä on vielä kaikkea nappia yms. ylimääräistä KOSKA ne on MFC:ssä, Visual C redistributablessa tuettuna.

"JOS M-Kar olisi oikeassa, niin silloin työmarkkinoilla olisi suuri kysyntä nimenomaan C# -koodaajille, ja kaikki muut kielet kuin C#, niiden osaajat olisivat tervemenneitä työttömyyskortistoon kunnes ovat opetelleet koodaamaan C#:lla."

Miksi ihmeessä? Suurinta osaa ohjelmista ei tehdä Microsoftin rajapinnoille.

"Kuitenkin työmarkkinoilla haetaan jatkuvasti koodaajia ainakin näille:"

Niin? Muista että suurin osa ohjelmista tehdään palvelimille tai sulautetuille joissa on jokin Linuxia käyttävä käyttöjärjestelmä.

"Silloin JAVA olisi koodausvälineenä arvoton Windows -käyttöjärjestelmässä."

Aika kuollut se onkin. Javaa tehdään kyllä Windowsissa vaikka Android SDK:ssa ja ehkä Google Web Toolkitissa käännellään selaimille.

"Toki JAVA ajoympäristöä varmaan edelleen tuetaan linuxissa, mutta vaikea kuvitella, että yritysmaailmassa laskettaisiin noin paljoa linuxin varaan!"

Yritysmaailma toimii 85%:sti linuxien varassa. Vitun kallista uusia kerta vuoteen Delphiä kun voi käyttää maksuttomia kehitysvälineitä.

Lue lisää

"Yritysmaailma toimii 85%:sti linuxien varassa. Vitun kallista uusia kerta vuoteen Delphiä kun voi käyttää maksuttomia kehitysvälineitä."

VÄÄRIN!

Yritysmaailmassa se tosiasia, että 1 delphikoodaaja saa yksin aikaan sen, mitä 3 huipputasoista tai 10 keskinkertaista C -koodaajaa saavat yhdessä aikaan.

Jos mietitään, mitä yritys säästää palkkakuluissa palkkaamalla yhden delphi -osaajan verrattuna 3-10 C -osaajan palkkaamiseen, niin erotuksella maksaa kevyesti Delphi -lisenssien uusimiset ja silti jää vielä voiton puolelle eli säästöt ovat suuremmat kuin Delphin lisenssimaksut.

Suurin ongelma on yrityspuolella se, että ne yritykset, joissa Delphiä käytetään, salailevat Delphin käyttöä, syynä se, että Delphin käyttö on heille kilpailuetu, ja siksi sitä pidetään liikesalaisuutena (eli ei haluta, että kilpailevat yritykset saisivat saman edun).

Anonyymi kirjoitti:

"Pascal kieli on kyllä kauhea ja sehän ei ole minkään standardin mukainen enää. Heikko ilmaisukyky."

M-kar on tunnettu delphivihaaja!

Delphin (ja Lazaruksen) kieli on objectpascal.

objectpascalin suhde pascaliin on sama kuin "C ":n suhde "C":hen.

objectpascalin kieli on erittäin ilmaisukykyinen ja toimii hyvin eri ympäristöissä!

M-Karin väitteelle heikosta ilmaisukyvystä ei ole yhtään järkiperustetta.

objectpascalin kieli on paitsi erittäin ilmaisukykyinen, myös hyvin selkeä, ja jo kielen selkeys on iso etu, koska se auttaa vähentämään muille kielille tyypillisiä ohjelmointivirheitä, ja selkeys on myös etu, kun muokataan jo olemassaolevaa koodia.

Lue lisää

"objectpascalin suhde pascaliin on sama kuin "C ":n suhde "C":hen."

Ymmärrätkö missä näitä enää käytetään ja minkä takia?

Ohjelmointivälineet ovat kehittyneet 70-luvulta, että mitään C ei paljoa käytetä. Vielä vähemmän object pascalia.

"M-Karin väitteelle heikosta ilmaisukyvystä ei ole yhtään järkiperustetta."

Tuo väite ei ole perusteeton. Lähdekoodin analysointiin on työkaluja ja algoritmeja tehty. Ei ainoastaan rivimäärä vaan muitakin mittareita löytyy.

Object pascal ei ole erityisen selkeä kieli ja VCL kirjasto on kauhea. Nykyään on paremmin suunniteltuja ohjelmointivälineitä.

"Jos Firefoxista oikeasti olisi "huolella siivottu WinAPI kutsut pois" kuten M-Kar väittää, niin eipä Firefox Windowsissa voisi edes toimia !"

Siellä on wrapperi. Jos WinAPI kutsuja ei olisi siivottu pois, Firefox ei kääntyisi heittämällä muissa käyttöjärjestelmissä.

"Tietoliikenteeseen (pääosin TCP/IP)"

Pöh: https://doc.rust-lang.org/std/net/index.html

Rustissa tuo on standardikirjastossa.

Debianin satunnaisluvuissa ei ole mitään vikaa. Puhut jostain 14 vuotta sitten korjatusta turva-aukosta.

"Widowsissa uusin järjestelmä, jossa kryptovahvojen satunnaislukujen generoinnissa oli laatuongelmia, oli Windows 2000, ja Windows XP:ssä"

Eli yhtä vanha.

Tuo nyt kuullostaa siltä, että projektisi rakenne on jotenkin sotkuinen. Vaikka nuokin ovat ikivanhoja tekniikoita niin kyllä sitä pystyy PHP kielellä lätkimään komponentteja lomakkeelle. Ideana toki se, että PHP komponentit renderöidään palvelinpuolella. Sitä PHP sovellusta voi sitten täydentää päätelaitteissa ajettavilla komponenteilla mitä tekee vaikka sillä jQueryllä.

Jokaisen komponentin toki voi pitää siististi omassa tiedostossaan ja niiden liittämisen voi tehdä lomakkeelle kuten palvelinpuolella renderöitävien komponenttien asettelun, koska ne saa kapseloitua PHP koodin sisään.

Ei tuollaista copypaste helvettiä ole missään oikeasti.

Tekniikka toki mennyt reiluti eteenpäin noista jQuery ajoista.

Ei ole "minun projekti", oli tehty talossa jo yli 2 vuotta ennen kun minä aloitin. Nykyisin on jo niin laaja ettei hevin modernisoida vaikka toki parannuksia on tehty vuosien varrella (bootstrap). Mutta edelleen sitä että JavaScript-tiedostot on omana, sitten php/css/html tiedostot omanaan, näiden välillä on pakko tunnisteita copy-pasteilla siirrellä jotta homma toimii sitten selaimessa.

Komponentit kuten grid on aika sekava tapa aina copy-pastella se js-koodihäkkyrä liittää js-tiedostoon ja ne alustukset, joskus pitää muodostaa vielä PHP-koodissa että saa tietyt ominaisuudet käyttöön, huoh! Tuon kanssa tulee aina joskus ikävä Delphi aikoja, kun lätkäsi sen gridin vain lomakkeelle ja propertyt naksutteli hiirellä kohilleen.

Minun mielipide, mutta minusta webbisovellukset ei tunnu "oikeilta" sovelluksilta, vaan ne on vähän kuin joku gallup-lomake ja postaa tiedot eteenpäin, responsiivisuutta vaikea saavuttaa.

ex-delphisti kirjoitti:

Ei ole "minun projekti", oli tehty talossa jo yli 2 vuotta ennen kun minä aloitin. Nykyisin on jo niin laaja ettei hevin modernisoida vaikka toki parannuksia on tehty vuosien varrella (bootstrap). Mutta edelleen sitä että JavaScript-tiedostot on omana, sitten php/css/html tiedostot omanaan, näiden välillä on pakko tunnisteita copy-pasteilla siirrellä jotta homma toimii sitten selaimessa.

Komponentit kuten grid on aika sekava tapa aina copy-pastella se js-koodihäkkyrä liittää js-tiedostoon ja ne alustukset, joskus pitää muodostaa vielä PHP-koodissa että saa tietyt ominaisuudet käyttöön, huoh! Tuon kanssa tulee aina joskus ikävä Delphi aikoja, kun lätkäsi sen gridin vain lomakkeelle ja propertyt naksutteli hiirellä kohilleen.

Minun mielipide, mutta minusta webbisovellukset ei tunnu "oikeilta" sovelluksilta, vaan ne on vähän kuin joku gallup-lomake ja postaa tiedot eteenpäin, responsiivisuutta vaikea saavuttaa.

Lue lisää

"Mutta edelleen sitä että JavaScript-tiedostot on omana, sitten php/css/html tiedostot omanaan, näiden välillä on pakko tunnisteita copy-pasteilla siirrellä jotta homma toimii sitten selaimessa."

Mokailut on taidettu tehdä projektin perustamisvaiheessa, että ei ole rakennetta mietitty.

On täysin normaalia että jokaisella komponentilla on oma tiedostonsa. Sitten ne vaan laittaa paikalleen siihen käyttöliittymänäkymään ja asetetaan propertyt.

PHP nyt on templatekieli siihen HTML:n tuottamiseen, että PHP komponentit upottaa siihen HTML:n ja ne menee suoraan käsi kädessä. Ulkoasu tyyli nyt on erillinen, kaikkien komponenttien laajuinen. Kuten se Bootstrap. Modifierit saa kirjoitettua sinne PHP templaten sekaan tai jQuery komponentteihin.

Ja ne jQuery komponentit toki saa käärittyä PHP:n sisään, että siinä käyttöliittymä näkymässä se komponentti lisätään samalla tavalla ja propertyt asetetaan samalla tavalla. Ei tarvitse mitään copy pastettaa.

"Komponentit kuten grid on aika sekava tapa aina copy-pastella se js-koodihäkkyrä liittää js-tiedostoon ja ne alustukset,"

Siis miksi muka on tuollaista? Mistä ihmeen copypastesta puhut?

"Minun mielipide, mutta minusta webbisovellukset ei tunnu "oikeilta" sovelluksilta, vaan ne on vähän kuin joku gallup-lomake ja postaa tiedot eteenpäin, responsiivisuutta vaikea saavuttaa."

Siis kun tekee PHP:llä softaa, se toimii sivulatauksina, oletusarvoisesti. Jokainen käyttöliittymä näkymä ja sen päivitys tapahtuu oletusarvoisesti sivulatauksena.

Se toki kestää aina sen sekunnin kun avaa jonkun. Kaikkia asioita ei kuitenkaan pysty näin tekemään vaan tarvitaan reaaliaikaisuutta tai tapahtumapohjaista käyttöliittymää, että asioita käsitellään ilman sivulatauksia. Sitä varten on sitten ne jQuery komponentit.

Tuohon aikaan silloin vuosien 2000-2010 välillä sovelluksia tehtiin näin, että pääosa suorituksesta oli palvelimessa mikä renderöi sen näkymän ja sitten oli niitä reaaliaikaisuutta vaativia komponentteja siellä mitkä sitä vaati. Aluksi oli Java Appletit ja ActiveX:t, sekä Flash swf:t ja sitten tuli jQuery.

2010 lokakuussa tuli Angular joka siirsin sen renderöinnin käyttöliittymäpuolelle, että siinä ei ole ollut mitään vaikeata saavuttaa viimeisen 6v aikana laajempaakin webbisovellusta ilman sivulatauksia. Onelma on siinä, että käytätte teknologiaa joka oli kova juttu 10v sitten.

Niin kyllä tiedän PHP:n toiminnan ja että tämän projektin ikä on kohta 10v. Ne php:t on siellä palvelimella ja ne muodostaa sen html-matskut ohjelmallisesti, tyyliin
<input type="text" id="#abc_nappi" class="tyylinappi aaa eew" value="<?php echo $bla_bla;?>">

Sitten se JavaScript pitää muodostaa ja ladata erikseen, jotka koskee tuota yhtä "sivua", sinne pitää erikseen koodailla sitten tuo toiminnallisuus $("#abc_nappi").click(function.. tyyliin <- tämä on minusta sitä kyrsää hommaa, etenkin jos koodia on tosi paljon. Selaimen debug-tilasta on onneksi apua.

Ennen CSS:t oli ympätty myös tuonne php-koodiin ja onneksi ne on nyt bootstrapin tultua erilliset, osa järjestelmää.

Mutta itse kaipaan semmoista "visuaalista" suunnittelua, mikä oli Delphissä, olkoon kuinka 1990-lukua tahansa, eli olisi ikään kuin designtime näkymä. Tosi ärsyttävän vanhanaikaista pelailla noiden tunnisteiden kanssa. Delphillä on se näkyvä osa ja sen toiminnallisuuden toteutus aina hyvin "lähellä" toisistaan, eikä tarvi eri tiedostoja selailla levyltä, muokata kun tekee yhtä kohtaa ohjelmasta.

Varmasti nämä webbihommat on kehittyneet vuosien varrella, mutta se ei minun ikeniä naurata, olen töissä naimisissa tämän projektin kanssa (ja moni muu) tekemisissä ja välillä aina kaipaan Delphin helppoutta.

jqGrid-komponentti, se on yksi helevetti, yrjö meinaa lentää aina kun tuota pitäisi muokata tai tehdä uusi, hyi!
http://www.trirand.com/jqgridwiki/doku.php?id=wiki:jqgridexamples

Voi elämän kevät kun Delphissä vain lätkäsi sen gridin formille, aika minimaalista koodia sitten sen datan hakeminen siihen ja eventeistä sai eri toiminnot klikattua koodit niihin.

ex-delphisti kirjoitti:

Niin kyllä tiedän PHP:n toiminnan ja että tämän projektin ikä on kohta 10v. Ne php:t on siellä palvelimella ja ne muodostaa sen html-matskut ohjelmallisesti, tyyliin
<input type="text" id="#abc_nappi" class="tyylinappi aaa eew" value="<?php echo $bla_bla;?>">

Sitten se JavaScript pitää muodostaa ja ladata erikseen, jotka koskee tuota yhtä "sivua", sinne pitää erikseen koodailla sitten tuo toiminnallisuus $("#abc_nappi").click(function.. tyyliin <- tämä on minusta sitä kyrsää hommaa, etenkin jos koodia on tosi paljon. Selaimen debug-tilasta on onneksi apua.

Ennen CSS:t oli ympätty myös tuonne php-koodiin ja onneksi ne on nyt bootstrapin tultua erilliset, osa järjestelmää.

Mutta itse kaipaan semmoista "visuaalista" suunnittelua, mikä oli Delphissä, olkoon kuinka 1990-lukua tahansa, eli olisi ikään kuin designtime näkymä. Tosi ärsyttävän vanhanaikaista pelailla noiden tunnisteiden kanssa. Delphillä on se näkyvä osa ja sen toiminnallisuuden toteutus aina hyvin "lähellä" toisistaan, eikä tarvi eri tiedostoja selailla levyltä, muokata kun tekee yhtä kohtaa ohjelmasta.

Varmasti nämä webbihommat on kehittyneet vuosien varrella, mutta se ei minun ikeniä naurata, olen töissä naimisissa tämän projektin kanssa (ja moni muu) tekemisissä ja välillä aina kaipaan Delphin helppoutta.

Lue lisää

" Ne php:t on siellä palvelimella ja ne muodostaa sen html-matskut ohjelmallisesti, tyyliin
<input type="text" id="#abc_nappi" class="tyylinappi aaa eew" value="<?php echo $bla_bla;?>"> "

Tai sitten voisit tehdä komponentin sinne <?php ?> tagien väliin. Näkymän alkuun joku dependencyt lisäävä pulikka <?php ?> tagien väliin jos komponentti on vaikka jQuery komponentti niin lisää sen automaattisesti sen riippuvuudet.

"Sitten se JavaScript pitää muodostaa ja ladata erikseen, jotka koskee tuota yhtä "sivua", sinne pitää erikseen koodailla sitten tuo toiminnallisuus $("#abc_nappi").click(function.. tyyliin <- tämä on minusta sitä kyrsää hommaa, etenkin jos koodia on tosi paljon. Selaimen debug-tilasta on onneksi apua."

Joo ei. Sinne <?php ?> tagien väliin voi laittaa myös komponentin mikä on jQuery komponentti. Sitten se dependency management huolehtii sen komponetti.min.js lisäyksestä sivulatauksiin.

Ongelma tuntuu olevan teillä se, että teillä ei ole järkevää komponettiarkkitehtuuria käytössä. Koodi pitää kirjoittaa niin, että tehdään komponentteja ja niitä sitten lätkitään siihen näkymään ja laitetaan propertyt paikalleen, ja se on sitten se ja sama onko komponentti backendissä ajettava PHP komponentti vai frontissa ajettava jQuery komponentti. Propertyt saa siitä PHP:stä menemään heittämällä.

Sitä jQuery komponenttia ei tarvitse mitenkään kummallisesti muodostella, käännetty komponentti.min.js toimii itsenäisesti PHP komponentin propertyt voi välittää siihen, että niitä kutsutaan samalla tavalla.

"Mutta itse kaipaan semmoista "visuaalista" suunnittelua, mikä oli Delphissä, olkoon kuinka 1990-lukua tahansa, eli olisi ikään kuin designtime näkymä."

No onhan semmoinen.. Brackets Chrome ja läiskii niitä bootstrap komponentteja siihen.

ex-delphisti kirjoitti:

jqGrid-komponentti, se on yksi helevetti, yrjö meinaa lentää aina kun tuota pitäisi muokata tai tehdä uusi, hyi!
http://www.trirand.com/jqgridwiki/doku.php?id=wiki:jqgridexamples

Voi elämän kevät kun Delphissä vain lätkäsi sen gridin formille, aika minimaalista koodia sitten sen datan hakeminen siihen ja eventeistä sai eri toiminnot klikattua koodit niihin.

Lue lisää

Miksi käyttää sitten tuommoista? Saahan ne lomakkeet rakennettua lätkimällä bootsrap komponenteilla: http://getbootstrap.com/css/#forms

Ja Braketsilla kun tekee designiä niin näkee tuloksen reaaliajassa Chromen ikkunassa.

"Delphillä on se näkyvä osa ja sen toiminnallisuuden toteutus aina hyvin "lähellä" toisistaan, eikä tarvi eri tiedostoja selailla levyltä, muokata kun tekee yhtä kohtaa ohjelmasta."

Se että muokataan vain yhtä osaa ohjelmasta on sitä, että on ne komponentit. Sen sijaan toiminnallisuuden pitäminen näkyvästä osasta tulisi pitää mahdollisimman hyvin erillään toisistaan.

Oikein tehdyssä käyttöliittymässä on data ja sitten käyttöliittymä rakentuu sen datan mukaan.

Redux tekee tempun hienosti Reactille: http://redux.js.org/

Siinä käyttöliittymän tila on yksi .json mitä käsitellään. Kyseinen rakenne käytännössä poistaa silmukat, lähes kaikki if lauseet yms. joten koodista tulee hyvin selkeää ja virheetöntä. Ei siis ole mitään kaikkea dataa leviteltynä ympäri komponentteja minkä kuuluisi heijastaa käyttöliittymän tilaa. Se data syötetään tuosta niille komponenteille ja käyttöliittymä rakentuu datan mukaan. Siellähän voi olla esimerkiksi jossain 0-10 komponenttia jossain listassa niin tuo tekee sen automaattisesti riippuen sitä mitä sieltä json:sta löytyy. Mitään silmukoita ei tarvitse tehdä, että map ja reduce toimivat.

Vuelle löytyy vastaava Vuex: https://vuex.vuejs.org/en/

PHP jutuissa tehdään vastaavasto palvelinpuolella, että rakentaa sen käyttöliittymän johonkin array rakenteeseen mikä syötetään näkyviin.

"PHP jutuissa tehdään vastaavasto palvelinpuolella, että rakentaa sen käyttöliittymän johonkin array rakenteeseen mikä syötetään näkyviin."

Ali PHP array -> javascript json data ? Näin olen tehnyt yhdessä jutussa missä pitää muodostaa useita hakemuksia ja niistä xml mikä lähetetään eteenpäin toiselle osapuolelle.

Kitti linkeistä pitää tutkailla noita, jospa ajan tästä projektista saisi järkevämmän.

ex-delphisti kirjoitti:

"PHP jutuissa tehdään vastaavasto palvelinpuolella, että rakentaa sen käyttöliittymän johonkin array rakenteeseen mikä syötetään näkyviin."

Ali PHP array -> javascript json data ? Näin olen tehnyt yhdessä jutussa missä pitää muodostaa useita hakemuksia ja niistä xml mikä lähetetään eteenpäin toiselle osapuolelle.

Kitti linkeistä pitää tutkailla noita, jospa ajan tästä projektista saisi järkevämmän.

Lue lisää

"Ali PHP array -> javascript json data ?"

Siis tarkoitin, että käyttöliittymän data on PHP arrayssä siitä sitten tuodaan komponentit mitä näytetään.

Tai jos käyttää valmista frameworkkia, kuten Symfonyä niin siinähän on sitten ne Twig templatet.

Periaatetasolla templatessa ei saisi olla yhtään ehtolausetta. Jos näin on niin jossain on jotain pielessä.

ex-delphisti kirjoitti:

Niin kyllä tiedän PHP:n toiminnan ja että tämän projektin ikä on kohta 10v. Ne php:t on siellä palvelimella ja ne muodostaa sen html-matskut ohjelmallisesti, tyyliin
<input type="text" id="#abc_nappi" class="tyylinappi aaa eew" value="<?php echo $bla_bla;?>">

Sitten se JavaScript pitää muodostaa ja ladata erikseen, jotka koskee tuota yhtä "sivua", sinne pitää erikseen koodailla sitten tuo toiminnallisuus $("#abc_nappi").click(function.. tyyliin <- tämä on minusta sitä kyrsää hommaa, etenkin jos koodia on tosi paljon. Selaimen debug-tilasta on onneksi apua.

Ennen CSS:t oli ympätty myös tuonne php-koodiin ja onneksi ne on nyt bootstrapin tultua erilliset, osa järjestelmää.

Mutta itse kaipaan semmoista "visuaalista" suunnittelua, mikä oli Delphissä, olkoon kuinka 1990-lukua tahansa, eli olisi ikään kuin designtime näkymä. Tosi ärsyttävän vanhanaikaista pelailla noiden tunnisteiden kanssa. Delphillä on se näkyvä osa ja sen toiminnallisuuden toteutus aina hyvin "lähellä" toisistaan, eikä tarvi eri tiedostoja selailla levyltä, muokata kun tekee yhtä kohtaa ohjelmasta.

Varmasti nämä webbihommat on kehittyneet vuosien varrella, mutta se ei minun ikeniä naurata, olen töissä naimisissa tämän projektin kanssa (ja moni muu) tekemisissä ja välillä aina kaipaan Delphin helppoutta.

Lue lisää

"Delphillä on se näkyvä osa ja sen toiminnallisuuden toteutus aina hyvin "lähellä" toisistaan, eikä tarvi eri tiedostoja selailla levyltä, muokata kun tekee yhtä kohtaa ohjelmasta."

Saahan sitä koodin hierarkian rakennettua noin millä tahansa välineellä, että komponentin visuaalinen puoli vastaa sen toimintoa.

Delphissä taas oli perustavanlaatuisesti komponentit rikki kun ne tallensivat omaa tilaansa komponenttiin.

"Se mikä oli vanhan liiton aikaan mukavaa oli ohjelmien toiminnan nopeus."

Ohjelmat toimii nykyään nopeasti. Ei ole muutoksia siinä.

"Selainpohjaisuus tarkoittaa jatkuvaa odottelua."

Ei tietenkään tarkoita.

"Tietty hyötyohjelma täytyy saada koneelle ja käyttää siinä, nopeasti ilman viiveitä."

Selainpohjaisesti saa nopeammin kun ei tarvitse asennella mitään, toimii tietysti ilman viiveitä.

"Sekunti on pitkä aika odotella esim. tekstin käsittelyssä."

Sekunnin viive liittyy vain sivulataukseen. Tekstiä kirjoitettaessa ei ole ikinä ollut mitään sivulatausta.

Ja sivulataus liittyy siihen kun ladataan toinen käyttöliittymänäkymä. Siis silloin ennen muinoin joskus 6v sitten. Eihän enää tarvita mitään sivulatauksia ellei nimenomaisesti rajata vaikka käyttöoikeuksia eri osiin ohjelmia.

"Syöttö on tahmaista ja sitten odottaa selain ruudun päivitystä."

Ei ole missään mitään tahmaisuutta.

"Video-, audio-, graafinen-ym editointityö ei pelitä selainpohjaisilla sovelluksilla."

Ei ole mitään merkitystä koska 99.99% ohjelmista ei ole mitään hemmetin median editointia. Eikä sekään ole mitenkään selvää että ei muka onnistuisi.

"Kaikki, mikä on verkossa on väistämättä hidasta."

Todista. On ihan helposti laskettavissa aikavaatimukset.

"No mitä ne sitten on?"

Esim. erilaiset viestintä, CRM, CMS, ERP, PIM, osto- ja myyntireskontra, tiketöinti, projektinhallinta, varastonhallinta jne. Erilaiset toimialakohtaiset sovellukset kuten potilastietojärjestelmät, erilaiset anturit mitkä kerää tietoa ja niitä käsitellään, hallintajärjestelmät ties mihin vempaimeen.

Tässä vaikka vähän näitä bisnessovelluksia mitä käytetään töiden tekemiseen: https://www.getapp.com/

Siinä nyt on jo pelkästään yli 5000 sovellusta.

Siitä on hyvä lähteä että suurimmassa osassa sovelluksia on jokin tietokanta mikä kerää tietoa. Jos tätä ei käsitä, ei tajua yhtään mitään millä ihmiset tekee töitä.

"Hemmetin" media-alan ammattilaiset käyttävät 2D/3D-graafisia sovelluksia (Adoben paketit), videoeditointi on arkityötä filmi ja TV-puolella, muusikot tekevät musiikkia musiikkisoveluksilla."

Eli marginaalista puuhastelua. Jostain kumman syystä niitä tuhansia kuvankäsittelyohjelmia ei löydy. Huomioi että Adoben sovellukset ei pääse edes promilleen kaikista ammattisovelluksista. Sinä nyt jotenkin käännät todellisuuden päälaelleen että melkein kaikki sovellukset olisikin jotain mediasovellusta ja sitten kukaan ei vaikka lähetä pikaviestiä tai sähköpostia. Tai vaikka maksa laskuja.

M-Kar kirjoitti:

"No mitä ne sitten on?"

Esim. erilaiset viestintä, CRM, CMS, ERP, PIM, osto- ja myyntireskontra, tiketöinti, projektinhallinta, varastonhallinta jne. Erilaiset toimialakohtaiset sovellukset kuten potilastietojärjestelmät, erilaiset anturit mitkä kerää tietoa ja niitä käsitellään, hallintajärjestelmät ties mihin vempaimeen.

Tässä vaikka vähän näitä bisnessovelluksia mitä käytetään töiden tekemiseen: https://www.getapp.com/

Siinä nyt on jo pelkästään yli 5000 sovellusta.

Siitä on hyvä lähteä että suurimmassa osassa sovelluksia on jokin tietokanta mikä kerää tietoa. Jos tätä ei käsitä, ei tajua yhtään mitään millä ihmiset tekee töitä.

"Hemmetin" media-alan ammattilaiset käyttävät 2D/3D-graafisia sovelluksia (Adoben paketit), videoeditointi on arkityötä filmi ja TV-puolella, muusikot tekevät musiikkia musiikkisoveluksilla."

Eli marginaalista puuhastelua. Jostain kumman syystä niitä tuhansia kuvankäsittelyohjelmia ei löydy. Huomioi että Adoben sovellukset ei pääse edes promilleen kaikista ammattisovelluksista. Sinä nyt jotenkin käännät todellisuuden päälaelleen että melkein kaikki sovellukset olisikin jotain mediasovellusta ja sitten kukaan ei vaikka lähetä pikaviestiä tai sähköpostia. Tai vaikka maksa laskuja.

Lue lisää

Työkalut valitaan tarpeen mukaan.

Eihän tuolla mitä sovelluksia ihmiset enimmäkseen käyttää ole hevonperseen väliä sille, joka kehittää vaikka grafiikkasoftaa.

102030405060 kirjoitti:

Työkalut valitaan tarpeen mukaan.

Eihän tuolla mitä sovelluksia ihmiset enimmäkseen käyttää ole hevonperseen väliä sille, joka kehittää vaikka grafiikkasoftaa.

Ei niin, mutta ei pidä tuputtaa marginaalijuttuja keskusteluun kun ei ole missään erikseen puhuttu mistään erikoistarpeista.

Eikä se asiaan mitenkään vaikuta koska sellaista poikkeustarvettakaan ei oikein ole missä kannattaisi uuteen projektiin ottaa Lazarus tai Delphi.

M-Kar kirjoitti:

"No mitä ne sitten on?"

Esim. erilaiset viestintä, CRM, CMS, ERP, PIM, osto- ja myyntireskontra, tiketöinti, projektinhallinta, varastonhallinta jne. Erilaiset toimialakohtaiset sovellukset kuten potilastietojärjestelmät, erilaiset anturit mitkä kerää tietoa ja niitä käsitellään, hallintajärjestelmät ties mihin vempaimeen.

Tässä vaikka vähän näitä bisnessovelluksia mitä käytetään töiden tekemiseen: https://www.getapp.com/

Siinä nyt on jo pelkästään yli 5000 sovellusta.

Siitä on hyvä lähteä että suurimmassa osassa sovelluksia on jokin tietokanta mikä kerää tietoa. Jos tätä ei käsitä, ei tajua yhtään mitään millä ihmiset tekee töitä.

"Hemmetin" media-alan ammattilaiset käyttävät 2D/3D-graafisia sovelluksia (Adoben paketit), videoeditointi on arkityötä filmi ja TV-puolella, muusikot tekevät musiikkia musiikkisoveluksilla."

Eli marginaalista puuhastelua. Jostain kumman syystä niitä tuhansia kuvankäsittelyohjelmia ei löydy. Huomioi että Adoben sovellukset ei pääse edes promilleen kaikista ammattisovelluksista. Sinä nyt jotenkin käännät todellisuuden päälaelleen että melkein kaikki sovellukset olisikin jotain mediasovellusta ja sitten kukaan ei vaikka lähetä pikaviestiä tai sähköpostia. Tai vaikka maksa laskuja.

Lue lisää

Noista sovelluksien määristä vielä. Määrät ei oikein ole mielekäs mittari näiden sovellustyyppien vertailemiseen.

Hyvien GUI työkalujen kehittäminen graafiseen, insinöörityöhön, jne. on paljon työläämpää kuin yksinkertaisia numero ja tekstitietoa käsittelevien sovellusten tuotanto.

Toisin sanoen, kynnys tehdä vaikka uusi laskutusohjelma tyhjästäkin on hyvin matala verrattuna siihen, että tekee uuden GUI työkalun vaativampaan graafiseen, piirtotyöhön, jne.

Tämä enimmäkseen selittää käyttöliittymältään yksinkertaisten business sovellusten hyvin suurta lukumäärää. Tuo 5000 on sekin reippaasti alakanttiin.

Siitä huolimatta, erilaisia graafisia ja piirto-ohjelmia muilta osin käytetään melkein alalla kuin alalla. Käyttökohteita on hyvin paljon markkinointi, insinöörialat, rakennus, teollisuus jne.

Toisaalta, vaikka jonkin ohjelmatyypin käyttäjäkunta olisi lukumääräisesti pieni, sen merkitys yhteiskunnallisesti voi edelleen olla erittäin suuri. Tästä hyvänä esimerkkinä vaikkapa elektroniikkateollisuuden EDA ohjelmistot, joita ilman nykyaikaisten IC piirien ja siis tietokoneidenkaan suunnittelu ei olisi ollut mahdollista. Ohjelman käyttäkunta marginaalisen pieni, mutta koko yhteiskunta hyötyy sen tuomista tuloksista nykyisenkaltaisen tietotekniikan muodossa.

102030405060 kirjoitti:

Noista sovelluksien määristä vielä. Määrät ei oikein ole mielekäs mittari näiden sovellustyyppien vertailemiseen.

Hyvien GUI työkalujen kehittäminen graafiseen, insinöörityöhön, jne. on paljon työläämpää kuin yksinkertaisia numero ja tekstitietoa käsittelevien sovellusten tuotanto.

Toisin sanoen, kynnys tehdä vaikka uusi laskutusohjelma tyhjästäkin on hyvin matala verrattuna siihen, että tekee uuden GUI työkalun vaativampaan graafiseen, piirtotyöhön, jne.

Tämä enimmäkseen selittää käyttöliittymältään yksinkertaisten business sovellusten hyvin suurta lukumäärää. Tuo 5000 on sekin reippaasti alakanttiin.

Siitä huolimatta, erilaisia graafisia ja piirto-ohjelmia muilta osin käytetään melkein alalla kuin alalla. Käyttökohteita on hyvin paljon markkinointi, insinöörialat, rakennus, teollisuus jne.

Toisaalta, vaikka jonkin ohjelmatyypin käyttäjäkunta olisi lukumääräisesti pieni, sen merkitys yhteiskunnallisesti voi edelleen olla erittäin suuri. Tästä hyvänä esimerkkinä vaikkapa elektroniikkateollisuuden EDA ohjelmistot, joita ilman nykyaikaisten IC piirien ja siis tietokoneidenkaan suunnittelu ei olisi ollut mahdollista. Ohjelman käyttäkunta marginaalisen pieni, mutta koko yhteiskunta hyötyy sen tuomista tuloksista nykyisenkaltaisen tietotekniikan muodossa.

Lue lisää

"Noista sovelluksien määristä vielä. Määrät ei oikein ole mielekäs mittari näiden sovellustyyppien vertailemiseen."

Määrät kertoo miten sitä sovelluskehitystä tehdään.

"Hyvien GUI työkalujen kehittäminen graafiseen, insinöörityöhön, jne. on paljon työläämpää kuin yksinkertaisia numero ja tekstitietoa käsittelevien sovellusten tuotanto."

Työläys riippuu kompleksisuudesta.

"Tämä enimmäkseen selittää käyttöliittymältään yksinkertaisten business sovellusten hyvin suurta lukumäärää. Tuo 5000 on sekin reippaasti alakanttiin."

Ei noissa business sovelluksissa aina ole mikään yksinkertainen käyttöliittymä. Tuotannonohjauksessa aika paljonkin toimintoja ja sitten kun kirjanpitoväline sisältää varastonhallinnat, reskontrat, laskutukset yms. niin ovat aika kompleksisia käyttöliittymältään.

Huomioi että sillä ei ole oikeastaan väliä onko käsiteltävä tieto kuvaa, tekstiä vai numeroita. Enemmän merkitsee kuinka kompleksinen se on. Esim. Kelan järjestelmät käsittelevät tekstiä ja numeroita mutta kyllähän ne ovat aika valtavan monimutkaiset ja sitten sielä sekin, että muuttuu kerran neljässä vuodessa suunnileen kun tulee lakimuutoksia.

Ja se kompleksisuus kannattaa ymmärtää niin, että jos on jokin hyvin kompleksinen, vanha ohjelma niin siinä voi olla sen takia käytössä joku vanha tekniikka kun ei ole vielä saatu modernisoitua ohjelmaa.

Normaalisti sovellusohjelman koodi alkaa olla vanhaa kuraa n. kahdentoista vuoden aikana ja alkaa kaivata uudelleen kirjoitusta. Sitten jos sitä koodia on paljon niin tarvitaan rekryillä iso lauma kehittäjiä tekohengittämään ja samalla asteittain modernisoida kun koodi alkaa mädäntyä kelvottomaksi.

Ja paino sanalla sovellusohjelman. Systeemitason jutut ja middlewaret voivat olla hyvinkin pitkäikäistä perustekniikkaa softapinossa korkeammalle mentäessä muutostarvetta tulee enemmän. Sitä aiheuttaa jo sekin, että 12v aikana on perinteisesti rautateknologia mennyt 100x nopeammaksi, halvemmaksi, pienemmäksi ja jne. Pitää ymmärtää että ei voi loputtomiin rakentaa softaa sen varaan että jollain modeemilla soitellaan johonkin numeroon missä softa kuuntelee merkkikomentoja ja tulostaa tekstiä. Maailma muuttuu.

"Kun verkko kaatuu, mikään noista 5000 sovelluksesta ei toimi."

Riippuu siitä onko asennettuna paikalliselle serverille tai miten paljon sovellus on tehty sietämään katkoksia verkkoyhteydessä.

Käytännössä ei ole mitään syytä miksi ei toimisi.

"mutta ne ovat vain osa normaalikäyttäjien sovelluksista myös ammattilaismaailmassa."

Niin, löytyy lukemattomia muita mitä ei tuolla ole ja ne toimivat niinikään vastaavasti normaalilla arkkitehtuurilla missä käyttöliittymä pidetään erillään datasta.

"Mediasisältötuotantoa ja monien alojen suunnittelutyötä ei käytännössä voi tehdä, kuin koneelle asennetuilla sovelluksilla. "

Tuskin löytyy mitään sellaista sovellusta mitä ei voisi tehdä niin, että vain käyttöliittymä on paikallisesti asennettuna. Kaikki mediasovellukset nyt ainakin ovat sellaisia. Useimmat vielä onnistuu tekemään standarditekniikalla.

"Töitä täytyy pystyä jatkamaan myös silloin kun verkko on kaatunut."

Et edelleenkään perustellut miksi työnteko loppuisi siihen vaikka WAN-yhteys vähän pätkisi. Tuo on jotain harhaa että ei muka saisi tehtyä toimimaan myös ilman jatkuvaa verkkoyhteyttä.

"Kun verkko kaatuu, mikään noista 5000 sovelluksesta ei toimi."

Eikä toimi myöskään mainitsemasi tv-teollisuuden mediasoftat. Katos ku ammattilaiskäytössä ne toimii pelkän keskusmuistin varassa ilman kovalevyjä ja kaikki työ on tallennettu verkkopalvelimille. Tosin nykyään kaikki vähänkin kriittiset järjestelmät on replikoitu useamalle palvelimelle ympäri maailmaa ja aina on varayhteys käytettävissä. Esim. yhdessä meidän myyntijärjestelmässä replikointipalvelimet sijaitsee hollannissa ja jenkeissä.

code_red kirjoitti:

"Kun verkko kaatuu, mikään noista 5000 sovelluksesta ei toimi."

Eikä toimi myöskään mainitsemasi tv-teollisuuden mediasoftat. Katos ku ammattilaiskäytössä ne toimii pelkän keskusmuistin varassa ilman kovalevyjä ja kaikki työ on tallennettu verkkopalvelimille. Tosin nykyään kaikki vähänkin kriittiset järjestelmät on replikoitu useamalle palvelimelle ympäri maailmaa ja aina on varayhteys käytettävissä. Esim. yhdessä meidän myyntijärjestelmässä replikointipalvelimet sijaitsee hollannissa ja jenkeissä.

Lue lisää

"aina on varayhteys käytettävissä"

Minkälainen varayhteys? Jos sattuu tilanne, että joku sabotööri laittaa ne harvat merikaapelit poikki, mitkä suomenkin yhdistää muuhun maailmaan, niin se on sitten siinä.

Vaikka joku varayhteys olisikin, se todennäköisesti olisi hyvin ruuhkainen tilanteen ollessa päällä.

Ei ole oikein vielä ollut sellaista aikaa, että internet olisi kunnolla poikki, esim niin, että vaikka Suomen yhteydet olisi eristyksissä. Tosin onhan niitä pieniä häiriöitä ollut aina välillä, esim soneralla ja elisalla, ettei ruotsin kautta menevä liikenne ole päässyt läpi puoleen tuntiin tai tuntiin. Kyllä se aika reippaasti rajoittaa . . . .

TV-teollisuuden softien toimimattomuus nyt ei olisi kovin iso menetys, niin heikkoa on tuo ohjelmatarjonta muutenkin.

102030405060 kirjoitti:

"aina on varayhteys käytettävissä"

Minkälainen varayhteys? Jos sattuu tilanne, että joku sabotööri laittaa ne harvat merikaapelit poikki, mitkä suomenkin yhdistää muuhun maailmaan, niin se on sitten siinä.

Vaikka joku varayhteys olisikin, se todennäköisesti olisi hyvin ruuhkainen tilanteen ollessa päällä.

Ei ole oikein vielä ollut sellaista aikaa, että internet olisi kunnolla poikki, esim niin, että vaikka Suomen yhteydet olisi eristyksissä. Tosin onhan niitä pieniä häiriöitä ollut aina välillä, esim soneralla ja elisalla, ettei ruotsin kautta menevä liikenne ole päässyt läpi puoleen tuntiin tai tuntiin. Kyllä se aika reippaasti rajoittaa . . . .

TV-teollisuuden softien toimimattomuus nyt ei olisi kovin iso menetys, niin heikkoa on tuo ohjelmatarjonta muutenkin.

Lue lisää

Mitä ne merikaapelit siihen vaikuttaa kun serveri on omassa lähiverkossa?

M-Kar kirjoitti:

Mitä ne merikaapelit siihen vaikuttaa kun serveri on omassa lähiverkossa?

Sovellus hakee vaikka fontit googlen palvelusta, siitä huolimatta että ajat sitä localhostina, myös tämä sivu tekee noin, luultavasti suurin osa verkkosovelluksista tekee noin. Pitääkö kertoa miksi ?

r67ti7t8oiii kirjoitti:

Sovellus hakee vaikka fontit googlen palvelusta, siitä huolimatta että ajat sitä localhostina, myös tämä sivu tekee noin, luultavasti suurin osa verkkosovelluksista tekee noin. Pitääkö kertoa miksi ?

Lue lisää

Ei vaikutakkaan jos on omassa verkossa.

Googlen fontit jos ei löydy, niin selain itseaisassa korvaa fontin seuraavalla listassa, että se ei vielä estä ohjelman toimintaa . . .

10203040506 kirjoitti:

Ei vaikutakkaan jos on omassa verkossa.

Googlen fontit jos ei löydy, niin selain itseaisassa korvaa fontin seuraavalla listassa, että se ei vielä estä ohjelman toimintaa . . .

Lue lisää

Sitä ennen haetaan cachesta.