Työllisyys ja Delphi

Poesta windowsssss
Winddows -aukko laajenee, imee ja pulpahtelee!...
=====================================

Anonyymi kirjoitti:

Poesta windowsssss
Winddows -aukko laajenee, imee ja pulpahtelee!...
=====================================

Ota siittä vaari!

EI TUMPELOKOODAAJA MITÄÄN TYÖTÄ SAA!

Asia taitaa olla juuri päinvastoin eli ne vanhat koodit pyörii jouhevasti edelleen, mutta ei edellytä raudan nopeuden kasvattamista, joten hankala sitten on myydä uutta rautaa. Node.js on luonteeltaan raskas ympäristö koska se käännetään pahimmassa tapauksessa juuri ennen suoritusta java byte-koodiksi ja tämä sitten suoritetaan kalliisti virtuaalikoneessa. Eli ei paljoa raskaampi systeemi enää voi olla. Näennäisesti se on toki helppo varsinkin ohjelmoijan kannalta, mutta totuus paljastuu sitten myöhemmin..

Anonyymi kirjoitti:

Asia taitaa olla juuri päinvastoin eli ne vanhat koodit pyörii jouhevasti edelleen, mutta ei edellytä raudan nopeuden kasvattamista, joten hankala sitten on myydä uutta rautaa. Node.js on luonteeltaan raskas ympäristö koska se käännetään pahimmassa tapauksessa juuri ennen suoritusta java byte-koodiksi ja tämä sitten suoritetaan kalliisti virtuaalikoneessa. Eli ei paljoa raskaampi systeemi enää voi olla. Näennäisesti se on toki helppo varsinkin ohjelmoijan kannalta, mutta totuus paljastuu sitten myöhemmin..

Lue lisää

Et tunnu "taitavan" yhtään mitään, kun sönkötät noista jeesuksenaikaisista tavoista, joista on syystäkin haluttu eroon. Javalla ja javascriptillä ei ole muuten mitään tekemistä keskenään.

Node on kaikkein kevyin suoritusympäristö. Alpine-kontissa jotain 60–70 megatavua, ja sitä voi heitellä orkesterointiympäristössä vaivatta sinne tänne. Vain jotkut ash-tulkatut skriptit saadaan kevyemmiksi, mutta ei niillä sitten mitään backendiä pyöritetäkään.

Ihminen ei sovellu koodariksi, jos on fakkiutunut yhteen kieleen. Yhden uuden kielen oppiminen lisää ei ole mikään iso juttu. Peruslogiikka on kaikissa sama.

Anonyymi kirjoitti:

Et tunnu "taitavan" yhtään mitään, kun sönkötät noista jeesuksenaikaisista tavoista, joista on syystäkin haluttu eroon. Javalla ja javascriptillä ei ole muuten mitään tekemistä keskenään.

Node on kaikkein kevyin suoritusympäristö. Alpine-kontissa jotain 60–70 megatavua, ja sitä voi heitellä orkesterointiympäristössä vaivatta sinne tänne. Vain jotkut ash-tulkatut skriptit saadaan kevyemmiksi, mutta ei niillä sitten mitään backendiä pyöritetäkään.

Ihminen ei sovellu koodariksi, jos on fakkiutunut yhteen kieleen. Yhden uuden kielen oppiminen lisää ei ole mikään iso juttu. Peruslogiikka on kaikissa sama.

Lue lisää

("Vain jotkut ash-tulkatut skriptit saadaan kevyemmiksi, mutta ei niillä sitten mitään backendiä pyöritetäkään.")

Sanot ettei yhden kielen oppiminen ole iso juttu, nyt sitten täytyy ihmetellä miksi sinä et ole sitä yhtäkään opetellut, vaan mutuilet paikkaansa pitämättömiä asioita, "minusta tuntuu siltä että".

Vasta tuossa ylempänä kerroin kuinka kätevää on komentotulkin scripteille rakentaa liittymää Lazaruksella ja tämähän näyttää ulospäin siltä että homman hoitaa kokonaisuudessaan Free Pascal. Eikö silloin Bash (Bourne-Again SHell), ash (Almquist shell), dash (Debian Almquist shell), csh (C shell), tcsh (TENEX C shell), zsh (Z shell) tai ksh (Korn shell) ole tasta-ajossa, eli juuri siinä tehtävässä mihin ne on tarkoitettukin, edustaohjelman ja ytimen väliin.

Anonyymi kirjoitti:

("Vain jotkut ash-tulkatut skriptit saadaan kevyemmiksi, mutta ei niillä sitten mitään backendiä pyöritetäkään.")

Sanot ettei yhden kielen oppiminen ole iso juttu, nyt sitten täytyy ihmetellä miksi sinä et ole sitä yhtäkään opetellut, vaan mutuilet paikkaansa pitämättömiä asioita, "minusta tuntuu siltä että".

Vasta tuossa ylempänä kerroin kuinka kätevää on komentotulkin scripteille rakentaa liittymää Lazaruksella ja tämähän näyttää ulospäin siltä että homman hoitaa kokonaisuudessaan Free Pascal. Eikö silloin Bash (Bourne-Again SHell), ash (Almquist shell), dash (Debian Almquist shell), csh (C shell), tcsh (TENEX C shell), zsh (Z shell) tai ksh (Korn shell) ole tasta-ajossa, eli juuri siinä tehtävässä mihin ne on tarkoitettukin, edustaohjelman ja ytimen väliin.

Lue lisää

Eipä ihme, että et kelpaa työelämään, kun jankkaat täyttä paskaa.

Työelämässä pitää osata käyttää työhön tarvittavia työkaluja. Sinä vaikutat sopivan lähinnä reikäkortinlävistäjäksi, ja tuskin osaat edes sitäkään.

Nyt eletään 2020-lukua. Jos et osaa tämän hetken teknologiaa, niin se on sinun oma ongelmasi. Reikäkortteja ei sinun osaamattomuudesi vuoksi palauteta takaisin käyttöön.

Anonyymi kirjoitti:

Eipä ihme, että et kelpaa työelämään, kun jankkaat täyttä paskaa.

Työelämässä pitää osata käyttää työhön tarvittavia työkaluja. Sinä vaikutat sopivan lähinnä reikäkortinlävistäjäksi, ja tuskin osaat edes sitäkään.

Nyt eletään 2020-lukua. Jos et osaa tämän hetken teknologiaa, niin se on sinun oma ongelmasi. Reikäkortteja ei sinun osaamattomuudesi vuoksi palauteta takaisin käyttöön.

Lue lisää

Ahaa, nyt olet jo tietoinen minun työelämästäkin, se kyllä kertoo riittävästi, mitä miehiä sinä olet.

Anonyymi kirjoitti:

Eipä ihme, että et kelpaa työelämään, kun jankkaat täyttä paskaa.

Työelämässä pitää osata käyttää työhön tarvittavia työkaluja. Sinä vaikutat sopivan lähinnä reikäkortinlävistäjäksi, ja tuskin osaat edes sitäkään.

Nyt eletään 2020-lukua. Jos et osaa tämän hetken teknologiaa, niin se on sinun oma ongelmasi. Reikäkortteja ei sinun osaamattomuudesi vuoksi palauteta takaisin käyttöön.

Lue lisää

Ei reikäkortteja tarvitse palauttaaa, mutta Delphi palvelimeen ja Freepascali source-to-source käntäjällä objectpascal javascriptiksi jota ajetaan selaimessa, homma toimisi erinomaisen hyvin !

Kunpa vielä EU päättäisi, että palvelinsaleille toimitettavasta sähköstä peritään datasähkövero 20 € / kWh.

Veikkaanpa, että viimeistään tuollainen datasähkövero 20 € / kWh pakottaisi yritykset toimimaan esittämälläni tavalla, eli pois nou node.js -viritykset ja Delphillä tehty palvelinkoodi tilalle. Delphi energiatehokkuus verrattuna node.js javascript -yhdistelmään on erinomainen.

Ruotsissa muuten datapalveluita / ohjelmistoja tarjoavalla yrityksellä on jo oltava hiilineutraalisuussuunnitelma ja jos ei ole, ei pääse mukaan tarjouskilpailuihin.

Esittämäni datasähkövero 20 € / kWh olisi parannettu versio tästä, eli ei tarvittaisi mitään erillisiä hiilineutraalisuussuunnitelmia viranomaisten tarkastettavaksi, mutta huomattava datasähkövero aiheuttaisi sen, että tehottomia tapoja käyttävät yritykset joutuisivat maksamaan veroa jokaisesta konesalinsa (oma tai vuokrattu, aivan sama verokohtelu) kuluttamasta kilowattitunnista.

Koska Delphi ja Freepascal kääntävät aidoksi konekieleksi, niin natiivikoodi on aina energiatehokkaampi ratkaisu, eli datamielessä samat tehtävät saadaan suoritettua vähemmällä kulutetulla sähköllä.

Ja laki tietenkin sellaiseksi, että veroa ei voi kiertää käyttämällä Azure tai Amazon -konesalia tai virtuaalikonetta.

Anonyymi kirjoitti:

Ei reikäkortteja tarvitse palauttaaa, mutta Delphi palvelimeen ja Freepascali source-to-source käntäjällä objectpascal javascriptiksi jota ajetaan selaimessa, homma toimisi erinomaisen hyvin !

Kunpa vielä EU päättäisi, että palvelinsaleille toimitettavasta sähköstä peritään datasähkövero 20 € / kWh.

Veikkaanpa, että viimeistään tuollainen datasähkövero 20 € / kWh pakottaisi yritykset toimimaan esittämälläni tavalla, eli pois nou node.js -viritykset ja Delphillä tehty palvelinkoodi tilalle. Delphi energiatehokkuus verrattuna node.js javascript -yhdistelmään on erinomainen.

Ruotsissa muuten datapalveluita / ohjelmistoja tarjoavalla yrityksellä on jo oltava hiilineutraalisuussuunnitelma ja jos ei ole, ei pääse mukaan tarjouskilpailuihin.

Esittämäni datasähkövero 20 € / kWh olisi parannettu versio tästä, eli ei tarvittaisi mitään erillisiä hiilineutraalisuussuunnitelmia viranomaisten tarkastettavaksi, mutta huomattava datasähkövero aiheuttaisi sen, että tehottomia tapoja käyttävät yritykset joutuisivat maksamaan veroa jokaisesta konesalinsa (oma tai vuokrattu, aivan sama verokohtelu) kuluttamasta kilowattitunnista.

Koska Delphi ja Freepascal kääntävät aidoksi konekieleksi, niin natiivikoodi on aina energiatehokkaampi ratkaisu, eli datamielessä samat tehtävät saadaan suoritettua vähemmällä kulutetulla sähköllä.

Ja laki tietenkin sellaiseksi, että veroa ei voi kiertää käyttämällä Azure tai Amazon -konesalia tai virtuaalikonetta.

Lue lisää

Onnea työnhakuun. Et sinä noilla meriiteillä pääse mihinkään ohjelmistoalan työpaikkaan, jos haikailet 1980-luvusta ja alat höpöttelemään vielä jostain sähkön hinnoittelumallista.

Ne sinun mummokoodisi kuluttavat älyttömiä määriä prosessoritehoa, eikä sellaisia käytetä kuin hätätapuksessa, jos pitää jossain kohdassa käyttää ikivanhaa ohjelmistoa. Niitä tilanteita ei enää onneksi juuri ole, ja ovat silloinkin vain joku tilapäisratkaisu siirryttäessä esimerkiksi vanhasta järjestelmästä uuteen. Jo pelkän tietoturvan vuoksi pitää käyttää ajantasaista teknologiaa.

Olisit kieltämättä parempi virkamiehenä kuin ohjelmistosuunnittelijana.

Anonyymi kirjoitti:

Onnea työnhakuun. Et sinä noilla meriiteillä pääse mihinkään ohjelmistoalan työpaikkaan, jos haikailet 1980-luvusta ja alat höpöttelemään vielä jostain sähkön hinnoittelumallista.

Ne sinun mummokoodisi kuluttavat älyttömiä määriä prosessoritehoa, eikä sellaisia käytetä kuin hätätapuksessa, jos pitää jossain kohdassa käyttää ikivanhaa ohjelmistoa. Niitä tilanteita ei enää onneksi juuri ole, ja ovat silloinkin vain joku tilapäisratkaisu siirryttäessä esimerkiksi vanhasta järjestelmästä uuteen. Jo pelkän tietoturvan vuoksi pitää käyttää ajantasaista teknologiaa.

Olisit kieltämättä parempi virkamiehenä kuin ohjelmistosuunnittelijana.

Lue lisää

Etkö vain voisi mennä muualle, kukaan ei kaipaa sinua täällä. Hus hus häiritsemästä alan ammattilaisia.

Anonyymi kirjoitti:

Etkö vain voisi mennä muualle, kukaan ei kaipaa sinua täällä. Hus hus häiritsemästä alan ammattilaisia.

Sinä näköjään pidät työttömänä olemistakin "alana". Eipä sinänsä ihme, kun olet pudonnut kehityksen kelkasta.

Ehkä sinullekin paikka löytyy, mutta se ei ole ohjelmistokehityksessä, jos et kykene omaksumaan nykyajan teknologioita. Pascalit ja Javat ovat eilispäivää.

Anonyymi kirjoitti:

Sinä näköjään pidät työttömänä olemistakin "alana". Eipä sinänsä ihme, kun olet pudonnut kehityksen kelkasta.

Ehkä sinullekin paikka löytyy, mutta se ei ole ohjelmistokehityksessä, jos et kykene omaksumaan nykyajan teknologioita. Pascalit ja Javat ovat eilispäivää.

Lue lisää

"Pascalit ja Javat ovat eilispäivää."

Delphin osalta: Delphin kieli ei ole pascal, vaan objectpascal.

Kielenä objectpascalin suhde pascaliin on suunnilleen sama kuin C :n suhde C:hen.

Javan osalta: En koskaan tykännyt javasta. Ikävä kyllä monessa yrityksessä vieläkin käytetään javaa, miksi, sitä en tiedä. Hankala kieli, delphi on koodaajan kannalta helpompi ja delphikoodaaja selviää työstään vähemmällä työmäärällä kuin javakoodaaja.

objectpascalissa on kaikki hyvältä ohjelmointikieleltä tarvittavat ominaisuudet ja muutama tarpeetonkin ominaisuus mukana (kuten "anonymous methods").

nuo anonyymit metodit ovat haitallinen ominaisuus, en suosittele kenenkään niitä käyttävän vaikka uusin Delphi niitäkin tukee. Miksikö?
No, ne tekevät debuggauksesta helvettiä, samoin kuin tällainen "antipattern":

with TSomeClass.Create do
try
// käytä luotua TSomeClass -luokan ilmentymää täällä

finally
Free;
end;

Miksikö tuo on "antipattern" ?

Koska kun et anna luodulle objektille nimeä, vaan viittaat siihen with-lauseen avulla, jolloin koko try-finally-end on with-lauseen vaikutusalueella, niin teet mahdottomaksi delphin debuggerille napata kiinni luotuun objektiin !
Tästä syystä: ÄLÄ käytä em. antipatternia, se on tässä vain esimerkkinä kelvottomasta ohjelmointityylistä!

Hätäratkaisuna voisi yrittää debuggerissa jotain tämäntapaista:

TSomeClass(Pointer(EAX))
jolloin esim. TSomeClass(Pointer(EAX)).ClassName tulostaisi debuggerissa 'TSomeClass'.

huomaa: tuo toimii HETI kun uusi objekti on luotu, mutta myöhemmin koodissa EAX:n arvo on muuttunut, eli ei toimi enää siellä.

Sitäpaitsi: kelpaako EAX debuggerin evaluatorille (Ctrl-F4) samoin kuin muuttujanimi kelpaisi ?

objectpascal on hieno ohjelmointikieli, eivätkä hyvät kielet vanhene. Ainoa ongelma on kelvottomat IT -johtajat, jotka eivät ymmärrä Delphin ja sen ohjelmointikielen objectpascalin arvoa !

Kukaan ei pysty esittämään ensimmäistäkään pätevää syytä, miksi node.js -alusta ja javascript -kieli olisi parempi kuin delphillä koodattu palvelinkoodi. Sellaista syytä ei ole!

Todellisuudessa Delphillä tehty palvelinkoodi on kaikin tavoin parempi kuin tuo node.js javascript -viritys.

Tämä tarkoittaa samalla sitä, että jos yritys A toteuttaa jonkin palvelun node.js javascript -virityksellä ja yritys B vastaavan palvelun Delphillä, niin sillä edellytyksellä, että yritysten muut kilpailuedellytykset ovat samat, niin voisin ennustaa yritykselle B parempaa menestystä, erityisesti jos tulee suuria yllättäviä piikkejä palvelun käyttäjämäärään, sillä Delphin natiivikoodi selviää isoistakin kuormituksista ongelmitta, vaan miten on node.js:n laita ?

Anonyymi kirjoitti:

Sinä näköjään pidät työttömänä olemistakin "alana". Eipä sinänsä ihme, kun olet pudonnut kehityksen kelkasta.

Ehkä sinullekin paikka löytyy, mutta se ei ole ohjelmistokehityksessä, jos et kykene omaksumaan nykyajan teknologioita. Pascalit ja Javat ovat eilispäivää.

Lue lisää

Oletko hullu?

Anonyymi kirjoitti:

"Pascalit ja Javat ovat eilispäivää."

Delphin osalta: Delphin kieli ei ole pascal, vaan objectpascal.

Kielenä objectpascalin suhde pascaliin on suunnilleen sama kuin C :n suhde C:hen.

Javan osalta: En koskaan tykännyt javasta. Ikävä kyllä monessa yrityksessä vieläkin käytetään javaa, miksi, sitä en tiedä. Hankala kieli, delphi on koodaajan kannalta helpompi ja delphikoodaaja selviää työstään vähemmällä työmäärällä kuin javakoodaaja.

objectpascalissa on kaikki hyvältä ohjelmointikieleltä tarvittavat ominaisuudet ja muutama tarpeetonkin ominaisuus mukana (kuten "anonymous methods").

nuo anonyymit metodit ovat haitallinen ominaisuus, en suosittele kenenkään niitä käyttävän vaikka uusin Delphi niitäkin tukee. Miksikö?
No, ne tekevät debuggauksesta helvettiä, samoin kuin tällainen "antipattern":

with TSomeClass.Create do
try
// käytä luotua TSomeClass -luokan ilmentymää täällä

finally
Free;
end;

Miksikö tuo on "antipattern" ?

Koska kun et anna luodulle objektille nimeä, vaan viittaat siihen with-lauseen avulla, jolloin koko try-finally-end on with-lauseen vaikutusalueella, niin teet mahdottomaksi delphin debuggerille napata kiinni luotuun objektiin !
Tästä syystä: ÄLÄ käytä em. antipatternia, se on tässä vain esimerkkinä kelvottomasta ohjelmointityylistä!

Hätäratkaisuna voisi yrittää debuggerissa jotain tämäntapaista:

TSomeClass(Pointer(EAX))
jolloin esim. TSomeClass(Pointer(EAX)).ClassName tulostaisi debuggerissa 'TSomeClass'.

huomaa: tuo toimii HETI kun uusi objekti on luotu, mutta myöhemmin koodissa EAX:n arvo on muuttunut, eli ei toimi enää siellä.

Sitäpaitsi: kelpaako EAX debuggerin evaluatorille (Ctrl-F4) samoin kuin muuttujanimi kelpaisi ?

objectpascal on hieno ohjelmointikieli, eivätkä hyvät kielet vanhene. Ainoa ongelma on kelvottomat IT -johtajat, jotka eivät ymmärrä Delphin ja sen ohjelmointikielen objectpascalin arvoa !

Kukaan ei pysty esittämään ensimmäistäkään pätevää syytä, miksi node.js -alusta ja javascript -kieli olisi parempi kuin delphillä koodattu palvelinkoodi. Sellaista syytä ei ole!

Todellisuudessa Delphillä tehty palvelinkoodi on kaikin tavoin parempi kuin tuo node.js javascript -viritys.

Tämä tarkoittaa samalla sitä, että jos yritys A toteuttaa jonkin palvelun node.js javascript -virityksellä ja yritys B vastaavan palvelun Delphillä, niin sillä edellytyksellä, että yritysten muut kilpailuedellytykset ovat samat, niin voisin ennustaa yritykselle B parempaa menestystä, erityisesti jos tulee suuria yllättäviä piikkejä palvelun käyttäjämäärään, sillä Delphin natiivikoodi selviää isoistakin kuormituksista ongelmitta, vaan miten on node.js:n laita ?

Lue lisää

Tervetuloa 2020-luvulle. Selvitä itsellesi mitä tarkoittaa termi load balancing, ja mitä ovat orkesterointijärjestelmät. Niiden avulla saadaan pidettyä palvelinten tarve minimissä, ja tarvittaessa skaalattua resursseja lisää kuormituksen kasvaessa, ja vapautettua niitä, kun tarvetta ei enää ole.

Anonyymi kirjoitti:

Asia taitaa olla juuri päinvastoin eli ne vanhat koodit pyörii jouhevasti edelleen, mutta ei edellytä raudan nopeuden kasvattamista, joten hankala sitten on myydä uutta rautaa. Node.js on luonteeltaan raskas ympäristö koska se käännetään pahimmassa tapauksessa juuri ennen suoritusta java byte-koodiksi ja tämä sitten suoritetaan kalliisti virtuaalikoneessa. Eli ei paljoa raskaampi systeemi enää voi olla. Näennäisesti se on toki helppo varsinkin ohjelmoijan kannalta, mutta totuus paljastuu sitten myöhemmin..

Lue lisää

" joten hankala sitten on myydä uutta rautaa"

Mitä hemmetin "rautaa" ?

Kun tarvitaan lisää suorituskykyä, käänetään palvelimeen lisää CPU:a, muistia tai käynnistetään niitä lisää.

"Node.js on luonteeltaan raskas ympäristö koska se käännetään pahimmassa tapauksessa juuri ennen suoritusta java byte-koodiksi "

Höpöhöpö. Ensiksikin NodeJS ei ole raskas ja toisekseen se ei käytä mitään "java byte-koodia".

Et tunnu tietävän mikä tekee ohjelman raskaaksi missäkin.

Anonyymi kirjoitti:

Et tunnu "taitavan" yhtään mitään, kun sönkötät noista jeesuksenaikaisista tavoista, joista on syystäkin haluttu eroon. Javalla ja javascriptillä ei ole muuten mitään tekemistä keskenään.

Node on kaikkein kevyin suoritusympäristö. Alpine-kontissa jotain 60–70 megatavua, ja sitä voi heitellä orkesterointiympäristössä vaivatta sinne tänne. Vain jotkut ash-tulkatut skriptit saadaan kevyemmiksi, mutta ei niillä sitten mitään backendiä pyöritetäkään.

Ihminen ei sovellu koodariksi, jos on fakkiutunut yhteen kieleen. Yhden uuden kielen oppiminen lisää ei ole mikään iso juttu. Peruslogiikka on kaikissa sama.

Lue lisää

"Et tunnu "taitavan" yhtään mitään, kun sönkötät noista jeesuksenaikaisista tavoista, joista on syystäkin haluttu eroon."

Totta. Ei tuo tiedä mitään. Voisi ihan suoraan näyttää kustannuslaskelmat paljon sen Delphi pökäleen hostaus maksaa ja paljon ylläpito vie aikaa ja miten kätevästi automatisoi. NodeJS:ää hostailee varmaan alle 5€/kk.

"Node on kaikkein kevyin suoritusympäristö."

Sanoisin että Go:lla menisi vielä köykäisemmäksi.

"Yhden uuden kielen oppiminen lisää ei ole mikään iso juttu."

Totta.

"Peruslogiikka on kaikissa sama."

No ei ihan. Ohjelmointikielissä on paradigmaeroja. Funktionaalinen, olioparadigma, proceduraalinen, logiikkaohjelmointi ja sitten ne domain specifistiset kielet.

Anonyymi kirjoitti:

Ei reikäkortteja tarvitse palauttaaa, mutta Delphi palvelimeen ja Freepascali source-to-source käntäjällä objectpascal javascriptiksi jota ajetaan selaimessa, homma toimisi erinomaisen hyvin !

Kunpa vielä EU päättäisi, että palvelinsaleille toimitettavasta sähköstä peritään datasähkövero 20 € / kWh.

Veikkaanpa, että viimeistään tuollainen datasähkövero 20 € / kWh pakottaisi yritykset toimimaan esittämälläni tavalla, eli pois nou node.js -viritykset ja Delphillä tehty palvelinkoodi tilalle. Delphi energiatehokkuus verrattuna node.js javascript -yhdistelmään on erinomainen.

Ruotsissa muuten datapalveluita / ohjelmistoja tarjoavalla yrityksellä on jo oltava hiilineutraalisuussuunnitelma ja jos ei ole, ei pääse mukaan tarjouskilpailuihin.

Esittämäni datasähkövero 20 € / kWh olisi parannettu versio tästä, eli ei tarvittaisi mitään erillisiä hiilineutraalisuussuunnitelmia viranomaisten tarkastettavaksi, mutta huomattava datasähkövero aiheuttaisi sen, että tehottomia tapoja käyttävät yritykset joutuisivat maksamaan veroa jokaisesta konesalinsa (oma tai vuokrattu, aivan sama verokohtelu) kuluttamasta kilowattitunnista.

Koska Delphi ja Freepascal kääntävät aidoksi konekieleksi, niin natiivikoodi on aina energiatehokkaampi ratkaisu, eli datamielessä samat tehtävät saadaan suoritettua vähemmällä kulutetulla sähköllä.

Ja laki tietenkin sellaiseksi, että veroa ei voi kiertää käyttämällä Azure tai Amazon -konesalia tai virtuaalikonetta.

Lue lisää

"Ei reikäkortteja tarvitse palauttaaa, mutta Delphi palvelimeen ja Freepascali source-to-source käntäjällä objectpascal javascriptiksi jota ajetaan selaimessa, homma toimisi erinomaisen hyvin !"

Miksi pitäisi noin huonosti tehdä?

"Kunpa vielä EU päättäisi, että palvelinsaleille toimitettavasta sähköstä peritään datasähkövero 20 € / kWh."

Miksi? Konesalista saa spot instanssit. Softan hostaus on halvempaa mitä paremmin optimoi.

"Koska Delphi ja Freepascal kääntävät aidoksi konekieleksi, niin natiivikoodi on aina energiatehokkaampi ratkaisu, eli datamielessä samat tehtävät saadaan suoritettua vähemmällä kulutetulla sähköllä."

Höpöhöpö. Natiivikoodi ei ole automaattisesti energiatehokkaampaa. Jo silloin 70- ja 80-lukujen unix C-kielisten kikkareiden kanssa oli energiatehokkaampaa palastella ja yhdistellä tulkattavalla shellillä, että kuorma tuli jaettua tasaisemmin.

Kun ensimmäiset HTTP-palvelimet tuli, energiatehokkuus parani kun siirryttiin natiivikoodista pois käyttämällä tulkattavaa kieltä, koska toimivat samassa prosessissa. Uuden prosessin käynnistäminen aina kun tehtiin jotain taustalla vei tehoja.

Nykypäivänä suorituskykyyn vaikuttaa enemmän kuinka kypsä toteutus on frameworkilla ja kielellä, kuin että onko tulkattava vai ei.

"että tehottomia tapoja käyttävät yritykset joutuisivat maksamaan veroa jokaisesta konesalinsa (oma tai vuokrattu, aivan sama verokohtelu) kuluttamasta kilowattitunnista."

Maksavat jo nyt. Se energian hinta on siinä hostauksen hinnassa ja sitä saadaan optimoitua. Se energiaoptimointi on melko suoraan hinnan optimointia hostauksessa.

Anonyymi kirjoitti:

"Pascalit ja Javat ovat eilispäivää."

Delphin osalta: Delphin kieli ei ole pascal, vaan objectpascal.

Kielenä objectpascalin suhde pascaliin on suunnilleen sama kuin C :n suhde C:hen.

Javan osalta: En koskaan tykännyt javasta. Ikävä kyllä monessa yrityksessä vieläkin käytetään javaa, miksi, sitä en tiedä. Hankala kieli, delphi on koodaajan kannalta helpompi ja delphikoodaaja selviää työstään vähemmällä työmäärällä kuin javakoodaaja.

objectpascalissa on kaikki hyvältä ohjelmointikieleltä tarvittavat ominaisuudet ja muutama tarpeetonkin ominaisuus mukana (kuten "anonymous methods").

nuo anonyymit metodit ovat haitallinen ominaisuus, en suosittele kenenkään niitä käyttävän vaikka uusin Delphi niitäkin tukee. Miksikö?
No, ne tekevät debuggauksesta helvettiä, samoin kuin tällainen "antipattern":

with TSomeClass.Create do
try
// käytä luotua TSomeClass -luokan ilmentymää täällä

finally
Free;
end;

Miksikö tuo on "antipattern" ?

Koska kun et anna luodulle objektille nimeä, vaan viittaat siihen with-lauseen avulla, jolloin koko try-finally-end on with-lauseen vaikutusalueella, niin teet mahdottomaksi delphin debuggerille napata kiinni luotuun objektiin !
Tästä syystä: ÄLÄ käytä em. antipatternia, se on tässä vain esimerkkinä kelvottomasta ohjelmointityylistä!

Hätäratkaisuna voisi yrittää debuggerissa jotain tämäntapaista:

TSomeClass(Pointer(EAX))
jolloin esim. TSomeClass(Pointer(EAX)).ClassName tulostaisi debuggerissa 'TSomeClass'.

huomaa: tuo toimii HETI kun uusi objekti on luotu, mutta myöhemmin koodissa EAX:n arvo on muuttunut, eli ei toimi enää siellä.

Sitäpaitsi: kelpaako EAX debuggerin evaluatorille (Ctrl-F4) samoin kuin muuttujanimi kelpaisi ?

objectpascal on hieno ohjelmointikieli, eivätkä hyvät kielet vanhene. Ainoa ongelma on kelvottomat IT -johtajat, jotka eivät ymmärrä Delphin ja sen ohjelmointikielen objectpascalin arvoa !

Kukaan ei pysty esittämään ensimmäistäkään pätevää syytä, miksi node.js -alusta ja javascript -kieli olisi parempi kuin delphillä koodattu palvelinkoodi. Sellaista syytä ei ole!

Todellisuudessa Delphillä tehty palvelinkoodi on kaikin tavoin parempi kuin tuo node.js javascript -viritys.

Tämä tarkoittaa samalla sitä, että jos yritys A toteuttaa jonkin palvelun node.js javascript -virityksellä ja yritys B vastaavan palvelun Delphillä, niin sillä edellytyksellä, että yritysten muut kilpailuedellytykset ovat samat, niin voisin ennustaa yritykselle B parempaa menestystä, erityisesti jos tulee suuria yllättäviä piikkejä palvelun käyttäjämäärään, sillä Delphin natiivikoodi selviää isoistakin kuormituksista ongelmitta, vaan miten on node.js:n laita ?

Lue lisää

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

Ja noita ei oikein käytetä.

"Hankala kieli, delphi on koodaajan kannalta helpompi ja delphikoodaaja selviää työstään vähemmällä työmäärällä kuin javakoodaaja."

Ei selviä. Java frameworkeille on paljon paremmat työkalut.

"objectpascal on hieno ohjelmointikieli, eivätkä hyvät kielet vanhene."

Mutta kun parempaa saa aikaiseksi pienemmällä vaivalla niin ei sillä object pascalilla tee mitään.

"Kukaan ei pysty esittämään ensimmäistäkään pätevää syytä, miksi node.js -alusta ja javascript -kieli olisi parempi kuin delphillä koodattu palvelinkoodi. "

1. Hinta. NodeJS ei maksa mitään ja hostaus on halpaa. Delphissä lisenssikulut ja hostauskulut korkeat.

2. Tietoturva. Delphiä ei saa ajettua alpine imageissa.

3. Suorituskyky. Pikaisen googletuksen perusteella Delphissä ei ole asynkronista HTTP/2 serveriä. Delphi ei siis selviydy suuresta kuormasta kuten NodeJS.

Anonyymi kirjoitti:

"Et tunnu "taitavan" yhtään mitään, kun sönkötät noista jeesuksenaikaisista tavoista, joista on syystäkin haluttu eroon."

Totta. Ei tuo tiedä mitään. Voisi ihan suoraan näyttää kustannuslaskelmat paljon sen Delphi pökäleen hostaus maksaa ja paljon ylläpito vie aikaa ja miten kätevästi automatisoi. NodeJS:ää hostailee varmaan alle 5€/kk.

"Node on kaikkein kevyin suoritusympäristö."

Sanoisin että Go:lla menisi vielä köykäisemmäksi.

"Yhden uuden kielen oppiminen lisää ei ole mikään iso juttu."

Totta.

"Peruslogiikka on kaikissa sama."

No ei ihan. Ohjelmointikielissä on paradigmaeroja. Funktionaalinen, olioparadigma, proceduraalinen, logiikkaohjelmointi ja sitten ne domain specifistiset kielet.

Lue lisää

Toinen köykäinen: Rust

Anonyymi kirjoitti:

Sinä näköjään pidät työttömänä olemistakin "alana". Eipä sinänsä ihme, kun olet pudonnut kehityksen kelkasta.

Ehkä sinullekin paikka löytyy, mutta se ei ole ohjelmistokehityksessä, jos et kykene omaksumaan nykyajan teknologioita. Pascalit ja Javat ovat eilispäivää.

Lue lisää

Java on edelleen nykypäivää.

Anonyymi kirjoitti:

Asia taitaa olla juuri päinvastoin eli ne vanhat koodit pyörii jouhevasti edelleen, mutta ei edellytä raudan nopeuden kasvattamista, joten hankala sitten on myydä uutta rautaa. Node.js on luonteeltaan raskas ympäristö koska se käännetään pahimmassa tapauksessa juuri ennen suoritusta java byte-koodiksi ja tämä sitten suoritetaan kalliisti virtuaalikoneessa. Eli ei paljoa raskaampi systeemi enää voi olla. Näennäisesti se on toki helppo varsinkin ohjelmoijan kannalta, mutta totuus paljastuu sitten myöhemmin..

Lue lisää

Jos oot nettihäirikkö, ei sua kukaan palkkaa!

No, oma kokemus nodesta on se, että sillä ei pysty tekemään mitään nopeasti toimivaa vaan sen käyttö vaatii ylimääräisiä kellosyklejä prosessorilta ja aiheuttaa laitteiston turhan päivityksen..

Anonyymi kirjoitti:

No, oma kokemus nodesta on se, että sillä ei pysty tekemään mitään nopeasti toimivaa vaan sen käyttö vaatii ylimääräisiä kellosyklejä prosessorilta ja aiheuttaa laitteiston turhan päivityksen..

Lue lisää

Höpöhöpö.

NodeJS:llä tehdään paljon nopeasti toimivia ohjelmia eikä ohjelmoijat mitään laitteistoja päivittele. Sitä voidaan säätää hallintapaneelista tarvittava määrä CPU:a ja muistia

Anonyymi kirjoitti:

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

Ja noita ei oikein käytetä.

"Hankala kieli, delphi on koodaajan kannalta helpompi ja delphikoodaaja selviää työstään vähemmällä työmäärällä kuin javakoodaaja."

Ei selviä. Java frameworkeille on paljon paremmat työkalut.

"objectpascal on hieno ohjelmointikieli, eivätkä hyvät kielet vanhene."

Mutta kun parempaa saa aikaiseksi pienemmällä vaivalla niin ei sillä object pascalilla tee mitään.

"Kukaan ei pysty esittämään ensimmäistäkään pätevää syytä, miksi node.js -alusta ja javascript -kieli olisi parempi kuin delphillä koodattu palvelinkoodi. "

1. Hinta. NodeJS ei maksa mitään ja hostaus on halpaa. Delphissä lisenssikulut ja hostauskulut korkeat.

2. Tietoturva. Delphiä ei saa ajettua alpine imageissa.

3. Suorituskyky. Pikaisen googletuksen perusteella Delphissä ei ole asynkronista HTTP/2 serveriä. Delphi ei siis selviydy suuresta kuormasta kuten NodeJS.

Lue lisää

"2. Tietoturva. Delphiä ei saa ajettua alpine imageissa."

Voi Jmal**uta !


Miten saisin sinut haastettua tällaiseen kaksintaisteluun:

Molemmille sama työtehtävä.

Minä teen omani Delphillä, sinä voit tehdä omasi vaikkapa Javalla tai node.js:llä, ihan millä vain haluat.

Ja senjälkeen katsotaan tietoturva:

Minulla on oikeus etsiä koodaamastasi tekeleestä virheitä aivan parhaaksi katsomallani tavalla...

ja aivan vastaavasti Sinulla on oikeus etsiä koodaamastani tekeleestä virheitä aivan parhaaksi katsomallasi tavalla...

Ja homman nimi on se, että se, jonka tekemästä koodista löytyy yksikin puskurin ylivuotohaavoittuvuus (sekä lukeminen että kirjoittaminen katsotaan tällaiseksi), häviää.
Jos kummankaan koodista ei löydy yhtään puskurin ylivuotohaavoittuvuutta, niin siinä tapauksessa jokaisesta muusta virheestä yksi virhepiste, ja se, jolla on enemmän virhepisteitä, häviää.

Häviäjä työttömäksi ja voittaja koodaamaan tietojärjestelmiä hyvällä palkalla ja mahdollisuudella rajoittamattomaan etätyöhön - näin se olisi reilua.

Mutta tähän haasteeseenhan et tietenkään ole valmis - koska käyttämällä Delphiä olen jo etukäteen 100% varma voittaja !

Delphillä tehty koodi on energiatehokkaampaa, toisin kuin väität.

Jos EU määräisi, että jokaisesta konesalissa käytetystä kWh:sta maksetaan sähköveroa 20€ / kWh, niin pian konesaleissa ei mitään muuta koodia käytettäisikään kuin Delphillä kirjoitettua.

Tosin tuollainen laki pitäisi määrätä niin, että sitä ei voi kiertää suorittamalla koodia EU:n ulkopuolella sijaitsevassa konesalissa.
Eli jos palvelin tarjoaa palveluja EU -alueella olevalle käyttäjälle, niin tuo 20€ /kWh sähkövero on maksettava, olipa itse palvelin aivan missä tahansa.

Johan sen Windows -tehtävänhallinnasta näkee, mikä on kunkin prosessin CPU -kuormitus. Delphi -ohjelmassa silloin, kun ohjelma ei aktiivisesti tee mitään, se kuormitus% on tasan 0.

Anonyymi kirjoitti:

"2. Tietoturva. Delphiä ei saa ajettua alpine imageissa."

Voi Jmal**uta !


Miten saisin sinut haastettua tällaiseen kaksintaisteluun:

Molemmille sama työtehtävä.

Minä teen omani Delphillä, sinä voit tehdä omasi vaikkapa Javalla tai node.js:llä, ihan millä vain haluat.

Ja senjälkeen katsotaan tietoturva:

Minulla on oikeus etsiä koodaamastasi tekeleestä virheitä aivan parhaaksi katsomallani tavalla...

ja aivan vastaavasti Sinulla on oikeus etsiä koodaamastani tekeleestä virheitä aivan parhaaksi katsomallasi tavalla...

Ja homman nimi on se, että se, jonka tekemästä koodista löytyy yksikin puskurin ylivuotohaavoittuvuus (sekä lukeminen että kirjoittaminen katsotaan tällaiseksi), häviää.
Jos kummankaan koodista ei löydy yhtään puskurin ylivuotohaavoittuvuutta, niin siinä tapauksessa jokaisesta muusta virheestä yksi virhepiste, ja se, jolla on enemmän virhepisteitä, häviää.

Häviäjä työttömäksi ja voittaja koodaamaan tietojärjestelmiä hyvällä palkalla ja mahdollisuudella rajoittamattomaan etätyöhön - näin se olisi reilua.

Mutta tähän haasteeseenhan et tietenkään ole valmis - koska käyttämällä Delphiä olen jo etukäteen 100% varma voittaja !

Delphillä tehty koodi on energiatehokkaampaa, toisin kuin väität.

Jos EU määräisi, että jokaisesta konesalissa käytetystä kWh:sta maksetaan sähköveroa 20€ / kWh, niin pian konesaleissa ei mitään muuta koodia käytettäisikään kuin Delphillä kirjoitettua.

Tosin tuollainen laki pitäisi määrätä niin, että sitä ei voi kiertää suorittamalla koodia EU:n ulkopuolella sijaitsevassa konesalissa.
Eli jos palvelin tarjoaa palveluja EU -alueella olevalle käyttäjälle, niin tuo 20€ /kWh sähkövero on maksettava, olipa itse palvelin aivan missä tahansa.

Johan sen Windows -tehtävänhallinnasta näkee, mikä on kunkin prosessin CPU -kuormitus. Delphi -ohjelmassa silloin, kun ohjelma ei aktiivisesti tee mitään, se kuormitus% on tasan 0.

Lue lisää

"Delphillä tehty koodi on energiatehokkaampaa, toisin kuin väität."

"Johan sen Windows -tehtävänhallinnasta näkee, mikä on kunkin prosessin CPU -kuormitus. "

Miten kummassa se olisi energiatehokkaampaa jos sen koodin ajoa varten pitää varata resurssia jotain Windowsia varten?

Kaksi merkittävintä energiatehokkuutta parantava asia viimeisen 10v aikana kun ollut tämä, että virtualisoinnissa on siirrytty käyttöjärjestelmätason virtualisointiin, eli sama Linux on joka serverissä ja käyttöjärjestelmät ovat virtualisoituna containereihin ja sitten se, että niitä containereita käynnistellään automaattisesti kuormituksen mukaisesti joten silloin kun softaa ei käytetä, se ei vie yhtään sähköä.

Delphillä on mahdotonta saada energiatehokkaampaa koska se ei käännä Linuxille.

"Johan sen Windows -tehtävänhallinnasta näkee, mikä on kunkin prosessin CPU -kuormitus. Delphi -ohjelmassa silloin, kun ohjelma ei aktiivisesti tee mitään, se kuormitus% on tasan 0."

Höpöhöpö. Ei se Windowsin tehtävienhallinta toimi ilman sähköä.

Et tunnu tajuavan, että energiatehokkaissa ohjelmissa koko tietokone sammuu itsestään kun ohjelma ei aktiivisesti tee mitään.

"Minulla on oikeus etsiä koodaamastasi tekeleestä virheitä aivan parhaaksi katsomallani tavalla..."

Tietoturvaan vaikuttaa myös alustan virheet.

Et tunnu ymmärtävän kuinka minimalistinen joku Alpine on tai se Red Hatin Universal Base Image 9 Micro että siellä on harvoin virhettä.

Lisäksi et ymmärrä miten tehdään oikeasti virheettömiä ohjelmia. Niissä virheettömyys esimerkiksi todistetaan, että ei ole mahdollista olla puskurinylivuotovirhettä, deadlockia, silmukka ei jää päälle, muistivuotoa, heap overflow, heap exhaustion, koodin käyttöä vapautuksen jälkeen... Koodia ei itseasiassa aina tarvitse edes kirjoittaa vaan kirjoitetaan speksiä todistusavustajalle joka generoi siitä virheettömän koodin.

Anonyymi kirjoitti:

"Delphillä tehty koodi on energiatehokkaampaa, toisin kuin väität."

"Johan sen Windows -tehtävänhallinnasta näkee, mikä on kunkin prosessin CPU -kuormitus. "

Miten kummassa se olisi energiatehokkaampaa jos sen koodin ajoa varten pitää varata resurssia jotain Windowsia varten?

Kaksi merkittävintä energiatehokkuutta parantava asia viimeisen 10v aikana kun ollut tämä, että virtualisoinnissa on siirrytty käyttöjärjestelmätason virtualisointiin, eli sama Linux on joka serverissä ja käyttöjärjestelmät ovat virtualisoituna containereihin ja sitten se, että niitä containereita käynnistellään automaattisesti kuormituksen mukaisesti joten silloin kun softaa ei käytetä, se ei vie yhtään sähköä.

Delphillä on mahdotonta saada energiatehokkaampaa koska se ei käännä Linuxille.

"Johan sen Windows -tehtävänhallinnasta näkee, mikä on kunkin prosessin CPU -kuormitus. Delphi -ohjelmassa silloin, kun ohjelma ei aktiivisesti tee mitään, se kuormitus% on tasan 0."

Höpöhöpö. Ei se Windowsin tehtävienhallinta toimi ilman sähköä.

Et tunnu tajuavan, että energiatehokkaissa ohjelmissa koko tietokone sammuu itsestään kun ohjelma ei aktiivisesti tee mitään.

"Minulla on oikeus etsiä koodaamastasi tekeleestä virheitä aivan parhaaksi katsomallani tavalla..."

Tietoturvaan vaikuttaa myös alustan virheet.

Et tunnu ymmärtävän kuinka minimalistinen joku Alpine on tai se Red Hatin Universal Base Image 9 Micro että siellä on harvoin virhettä.

Lisäksi et ymmärrä miten tehdään oikeasti virheettömiä ohjelmia. Niissä virheettömyys esimerkiksi todistetaan, että ei ole mahdollista olla puskurinylivuotovirhettä, deadlockia, silmukka ei jää päälle, muistivuotoa, heap overflow, heap exhaustion, koodin käyttöä vapautuksen jälkeen... Koodia ei itseasiassa aina tarvitse edes kirjoittaa vaan kirjoitetaan speksiä todistusavustajalle joka generoi siitä virheettömän koodin.

Lue lisää

"Delphillä tehty koodi on energiatehokkaampaa" On täyttä paskaa!

Anonyymi kirjoitti:

"Delphillä tehty koodi on energiatehokkaampaa" On täyttä paskaa!

"Delphillä on mahdotonta saada energiatehokkaampaa koska se ei käännä Linuxille. "
Väite on itse asiassa väärä, koska Lazarus osaa mm. kääntää Delphi-koodia - delphi-moodi on fpc-kääntäjän vipu -Mdelphi ja sen voi asettaa vaikkapa suoraan lähdekoodissa: {$MODE DELPHI}.
https://www.freepascal.org/docs-html/prog/progse74.html
Mieluummin tulee kuitenkin käytettyä extended-pascal moodia, joka on ISO pascalin mukainen mutta noudattaa ISO 10206 standardia.
Yleensä koodaus ei kuulu ylläpito-hommiin, mutta 100-200 rivisiä ohjelmia sillä tulee tehtyä aina välillä, koska se ei vaadi minkään uuden kielen opettelua - pärjää yläasteella opetellulla! :)

Anonyymi kirjoitti:

"Delphillä on mahdotonta saada energiatehokkaampaa koska se ei käännä Linuxille. "
Väite on itse asiassa väärä, koska Lazarus osaa mm. kääntää Delphi-koodia - delphi-moodi on fpc-kääntäjän vipu -Mdelphi ja sen voi asettaa vaikkapa suoraan lähdekoodissa: {$MODE DELPHI}.
https://www.freepascal.org/docs-html/prog/progse74.html
Mieluummin tulee kuitenkin käytettyä extended-pascal moodia, joka on ISO pascalin mukainen mutta noudattaa ISO 10206 standardia.
Yleensä koodaus ei kuulu ylläpito-hommiin, mutta 100-200 rivisiä ohjelmia sillä tulee tehtyä aina välillä, koska se ei vaadi minkään uuden kielen opettelua - pärjää yläasteella opetellulla! :)

Lue lisää

Puhe oli Delphistä.

FreePascalilla nyt periaatteessa voi tehdä energiatehokasta koodia johonkin yksinkertaiseen. Mitään UI:ta tähän ei tietenkään kuulu että se on headless mutta pari huomiota:

1. Se ei ole energiatehokas ison kuorman järjestelmissä. Näissä ratkaisee HTTP serverin kyky ja garbage collector. Tässä asiassa parhaita ovat Java ja C#

2. FreePascalin standardikirjastossa ei ole koko HTTP serveriä, että se on aika huono valinta tällaiseen. Näihin sopivin on yleensä Go, tai vaikka C++ yhdessä Boostin kanssa jos Go ei riitä.

Anonyymi kirjoitti:

Et tunnu "taitavan" yhtään mitään, kun sönkötät noista jeesuksenaikaisista tavoista, joista on syystäkin haluttu eroon. Javalla ja javascriptillä ei ole muuten mitään tekemistä keskenään.

Node on kaikkein kevyin suoritusympäristö. Alpine-kontissa jotain 60–70 megatavua, ja sitä voi heitellä orkesterointiympäristössä vaivatta sinne tänne. Vain jotkut ash-tulkatut skriptit saadaan kevyemmiksi, mutta ei niillä sitten mitään backendiä pyöritetäkään.

Ihminen ei sovellu koodariksi, jos on fakkiutunut yhteen kieleen. Yhden uuden kielen oppiminen lisää ei ole mikään iso juttu. Peruslogiikka on kaikissa sama.

Lue lisää

"Ihminen ei sovellu koodariksi, jos on fakkiutunut yhteen kieleen."

Riippuu tilanteesta. Jos esimerkiksi haluaa viettää uransa yliopistolla, voinee pärjätä LaTeXilla ja R:llä. Tai voihan toimia vaikka COBOL-konsulttina ja ylläpitää koko uransa vanhoja ohjelmistoja.

Anonyymi kirjoitti:

"Ihminen ei sovellu koodariksi, jos on fakkiutunut yhteen kieleen."

Riippuu tilanteesta. Jos esimerkiksi haluaa viettää uransa yliopistolla, voinee pärjätä LaTeXilla ja R:llä. Tai voihan toimia vaikka COBOL-konsulttina ja ylläpitää koko uransa vanhoja ohjelmistoja.

Lue lisää

Jolloin ajatusmaailma olisi R:n ja COBOL:n rajoitteissa ja hölmöyksissä.

Semmoinen ominaisuus tuossa ChatGPT:ssä että enää ei tuollaisia tumpeloita tarvitse kun se hoitaa hommat paremmin. Tarvetta on enää vain oikeasti osaaville ohjelmoijille.

Delphillä ei ole tehty yhtään käyttöliittymää kätevästi. Ongelma on siinä "formissa" kun se ei ole samankokoinen kaikilla laiteilla niin ne Delphipökäleet ovat tavallisesti aivan kauheita. React on kiva.

PHP:tä on optimoitu ihan hyvin kaiken aikaa, että kun tuoreen imagen otta niin voi sekin olla tehokkaampi kun Delphi.

Anonyymi kirjoitti:

Delphillä ei ole tehty yhtään käyttöliittymää kätevästi. Ongelma on siinä "formissa" kun se ei ole samankokoinen kaikilla laiteilla niin ne Delphipökäleet ovat tavallisesti aivan kauheita. React on kiva.

PHP:tä on optimoitu ihan hyvin kaiken aikaa, että kun tuoreen imagen otta niin voi sekin olla tehokkaampi kun Delphi.

Lue lisää

No oman työpaikan projekti on tehty Bootstrapilla jQuery, johtuen toki historiallisesta taustasta, mutta tuon piti toimia myös kännyköillä ja tänään kuulin ettei X käytetä kännykällä =) "Noonni". Toki React ym. voi olla sitten erikseen, mutta epäilen että mitään yleispätevää kirjastoa on vieläkään, jolla tehtynä softa toimii kätevästi laitteessa kuin laitteessa taikaiskusta.

Jotkut pienet kirppu-sovellukset on nyt asia erikseen, mutta oman työpaikan sota X on aika iso ja laaja, sisältää paljon gridejä ym. joita on hankala käyttää kännykällä.

Työpöytä sovelluksille on paikkansa ja mobiili perse edellä puuhun ei kannattaisi aina mennä, vaan tunnustaa tosiasiat tosiasioina.

- Ex-delphisti

Anonyymi kirjoitti:

No oman työpaikan projekti on tehty Bootstrapilla jQuery, johtuen toki historiallisesta taustasta, mutta tuon piti toimia myös kännyköillä ja tänään kuulin ettei X käytetä kännykällä =) "Noonni". Toki React ym. voi olla sitten erikseen, mutta epäilen että mitään yleispätevää kirjastoa on vieläkään, jolla tehtynä softa toimii kätevästi laitteessa kuin laitteessa taikaiskusta.

Jotkut pienet kirppu-sovellukset on nyt asia erikseen, mutta oman työpaikan sota X on aika iso ja laaja, sisältää paljon gridejä ym. joita on hankala käyttää kännykällä.

Työpöytä sovelluksille on paikkansa ja mobiili perse edellä puuhun ei kannattaisi aina mennä, vaan tunnustaa tosiasiat tosiasioina.

- Ex-delphisti

Lue lisää

"mutta epäilen että mitään yleispätevää kirjastoa on vieläkään, jolla tehtynä softa toimii kätevästi laitteessa kuin laitteessa taikaiskusta."

Kyllä on. Selaimissa vaan kyse on liikkuvasta maalista kun standardit ja toiminallisuudet tulevat selaimiin päivitysten myötä.

Sitten kun kyse on näistä niin sanotuista mobiililaitteista, näiden selaimien tekniikka tulee vain jäljessä läppäreitä ja pöytäkoneita, eivät ole aina niin pitkään päivitettävissä. Kuitenkin voidaan odottaa minkä tahansa kännykän olevan ainakin 4v käytössä.

Esimerkiksi se jQuery teki sen, että vuonna 2009 se ES3 Javascript koodi toimi sujuvasti Internet Explorer 8, Firefox 3.5, Windows Mobile 6.1 ja Safari 4 selaimissa.

Siis Javascipt. Windows Mobile 6.1:n CSS oli IE6 tasoa, että piti tehdä mobiiliversiota erikseen.

Vasta vuonna 2014 oli lähes 100%:sti laitteissa Javascriptin ES5, CSS2.1 ja CSS:n mediaqueries käytössä niin laajasti että joku jQuery Bootstrap toimi heittämällä joka laitteessa missä selain ja sai skaalautumaan sopivaksi. Silloin tuli sitten myös React, että ei tarvinnut jQueryä käyttää ja sai sivulataukset vähemmälle tai pois kokonaan.

jQuery oli kuitenkin siihen, että käyttöliittymä tehtiin palvelimessa ja sillä tehtiin vain dynaamisia komponentteja sinne sivulle.

USA:n tiedustelupalvelu CIA ”natsifioi” Ukrainaa salaisesti vuodesta 1953
Julkaistu 21.03.2022 07:43, 3315 lukukertaa, Ei kommentteja

USA:n keskustiedustelupalvelu CIA on "natsifioinut" Ukrainaa salaisissa operaatioissa jo 70 vuoden ajan. Dokumentit ovat paljastaneet, että Yhdysvallat on osallistunut useisiin hankkeisiin, joiden tarkoituksena on horjuttaa Ukrainan hallituksia vahvistamalla äärimielisiä nationalistivoimia.

Anonyymi kirjoitti:

"mutta epäilen että mitään yleispätevää kirjastoa on vieläkään, jolla tehtynä softa toimii kätevästi laitteessa kuin laitteessa taikaiskusta."

Kyllä on. Selaimissa vaan kyse on liikkuvasta maalista kun standardit ja toiminallisuudet tulevat selaimiin päivitysten myötä.

Sitten kun kyse on näistä niin sanotuista mobiililaitteista, näiden selaimien tekniikka tulee vain jäljessä läppäreitä ja pöytäkoneita, eivät ole aina niin pitkään päivitettävissä. Kuitenkin voidaan odottaa minkä tahansa kännykän olevan ainakin 4v käytössä.

Esimerkiksi se jQuery teki sen, että vuonna 2009 se ES3 Javascript koodi toimi sujuvasti Internet Explorer 8, Firefox 3.5, Windows Mobile 6.1 ja Safari 4 selaimissa.

Siis Javascipt. Windows Mobile 6.1:n CSS oli IE6 tasoa, että piti tehdä mobiiliversiota erikseen.

Vasta vuonna 2014 oli lähes 100%:sti laitteissa Javascriptin ES5, CSS2.1 ja CSS:n mediaqueries käytössä niin laajasti että joku jQuery Bootstrap toimi heittämällä joka laitteessa missä selain ja sai skaalautumaan sopivaksi. Silloin tuli sitten myös React, että ei tarvinnut jQueryä käyttää ja sai sivulataukset vähemmälle tai pois kokonaan.

jQuery oli kuitenkin siihen, että käyttöliittymä tehtiin palvelimessa ja sillä tehtiin vain dynaamisia komponentteja sinne sivulle.

Lue lisää

Voi toimia mutta onko käyttö järkevää mobiilissa? Kuinka moni esim. käyttää jotain Exceliä kännykän kautta pääasiassa, käyttö on paljon sujuvampaa näppäimistöllä ja hiirellä, eli oikeana työpöytä-sovelluksena.

Riippuu toki sovelluksesta, mutta kaikkea ei kannattais aina vääntää sillä periaatteella että se toimii myös mobiilina.

ex-Delphisti

Anonyymi kirjoitti:

Voi toimia mutta onko käyttö järkevää mobiilissa? Kuinka moni esim. käyttää jotain Exceliä kännykän kautta pääasiassa, käyttö on paljon sujuvampaa näppäimistöllä ja hiirellä, eli oikeana työpöytä-sovelluksena.

Riippuu toki sovelluksesta, mutta kaikkea ei kannattais aina vääntää sillä periaatteella että se toimii myös mobiilina.

ex-Delphisti

Lue lisää

Ei varmaan taulukkolaskinta kannata käyttää kännykällä mutta ei se sen taulukkolaskimen tekemiseen vaikuta mitenkään.

Kysehän on vain siitä että sopii ne käyttöliittymäelementit ruudulle kun se kännykkä ajaa täysin samaa koodia. Eli kyse on käyttöliittymäkomponenttien asettelusta.

Nehän siirtyy suunnilleen melkein leikkaa & liitä, ja sitten muuttaa tyyliin polut.

Anonyymi kirjoitti:

Delphillä ei ole tehty yhtään käyttöliittymää kätevästi. Ongelma on siinä "formissa" kun se ei ole samankokoinen kaikilla laiteilla niin ne Delphipökäleet ovat tavallisesti aivan kauheita. React on kiva.

PHP:tä on optimoitu ihan hyvin kaiken aikaa, että kun tuoreen imagen otta niin voi sekin olla tehokkaampi kun Delphi.

Lue lisää

" Ongelma on siinä formissa kun se ei ole samankokoinen kaikilla laiteilla niin ne Delphipökäleet ovat tavallisesti aivan kauheita. "

Ei ole mitään ongelmaa!

VCL:llä Windows -versio ohejlmasta, ja FireMonkey:lla esim. Android -versio.

Silloin Windows -versio toimii erinomaisesti tietokoneessa, ja se FireMonkey:lla tehty toimii erinomaisesti Android -puhelimessa. Ei mitään ongelmaa.

Tuo HTML5:n ja javascriptin käyttö ei todellisuudessa ratkaise yhtään mitään ongelmaa, antaapa vain illuusion muka ratkaisemisesta.

Jos sitä "tavaraa" on enemmän, niin PC:n näytölle mahtuu, mutta HTML5 + CSS + javascript -viritys aiheuttaa nopeasti sen, että Android -puhelimen näytöllä on näytön levyinen, mutta noin kilometrin korkea virtuaalisivu, jota sitten joutuu vierittämään puhelimen kosketusnäyttöä käyttäen.

Käyttöliittymäkokemus: Aivan hirvittävä.

Se, että tuollainen GUI teoriassa skaalautuu eri näyttökokojen mukaan:
Juu, niin skaalautuu, mutta käyttöliittymäkokemus on silti aivan hirvittävä!

Jos käsiteltävät tietomäärät ovat isoja, niin tietokone on laitteena se ainoa oikea: ei kaiken tarvitse toimia älypuhelimen pienellä näytöllä!

Pienempiin datatarpeisiin se älypuhelinkin toki sopii, mutta miksi niin moni Android -sovellus on laadultaan aivan paskaa ?

Esimerkki:
Here We Go -navigointisovellus Androidille.
Tuon sovelluksen laatu on luokattoman huono.
Antaa pari ohjetta, ja sitten hiljenee ... eli menee tuntemattomasta syystä sellaiseen tilaan, ettei enää anna ajo-ohjeita.
Ihme roskaa sitä ihmisille tarjotaankin.

Pitäisikö ostaa uusi navigaattorilaite hajonneen (Garmin) tilalle?
Here We Go -navigointisovellus ainakin on täysin kelvoton.

Anonyymi kirjoitti:

" Ongelma on siinä formissa kun se ei ole samankokoinen kaikilla laiteilla niin ne Delphipökäleet ovat tavallisesti aivan kauheita. "

Ei ole mitään ongelmaa!

VCL:llä Windows -versio ohejlmasta, ja FireMonkey:lla esim. Android -versio.

Silloin Windows -versio toimii erinomaisesti tietokoneessa, ja se FireMonkey:lla tehty toimii erinomaisesti Android -puhelimessa. Ei mitään ongelmaa.

Tuo HTML5:n ja javascriptin käyttö ei todellisuudessa ratkaise yhtään mitään ongelmaa, antaapa vain illuusion muka ratkaisemisesta.

Jos sitä "tavaraa" on enemmän, niin PC:n näytölle mahtuu, mutta HTML5 CSS javascript -viritys aiheuttaa nopeasti sen, että Android -puhelimen näytöllä on näytön levyinen, mutta noin kilometrin korkea virtuaalisivu, jota sitten joutuu vierittämään puhelimen kosketusnäyttöä käyttäen.

Käyttöliittymäkokemus: Aivan hirvittävä.

Se, että tuollainen GUI teoriassa skaalautuu eri näyttökokojen mukaan:
Juu, niin skaalautuu, mutta käyttöliittymäkokemus on silti aivan hirvittävä!

Jos käsiteltävät tietomäärät ovat isoja, niin tietokone on laitteena se ainoa oikea: ei kaiken tarvitse toimia älypuhelimen pienellä näytöllä!

Pienempiin datatarpeisiin se älypuhelinkin toki sopii, mutta miksi niin moni Android -sovellus on laadultaan aivan paskaa ?

Esimerkki:
Here We Go -navigointisovellus Androidille.
Tuon sovelluksen laatu on luokattoman huono.
Antaa pari ohjetta, ja sitten hiljenee ... eli menee tuntemattomasta syystä sellaiseen tilaan, ettei enää anna ajo-ohjeita.
Ihme roskaa sitä ihmisille tarjotaankin.

Pitäisikö ostaa uusi navigaattorilaite hajonneen (Garmin) tilalle?
Here We Go -navigointisovellus ainakin on täysin kelvoton.

Lue lisää

"VCL:llä Windows -versio ohejlmasta, ja FireMonkey:lla esim. Android -versio."

Ohjelma käännetään nykypäivänä täysin samasta koodista niin, että toimii Androidilla, iOS:lla, MacOS:lla, Windowsilla, Ubuntulla, Red Hatilla, Debianilla jne. ilman asentamista eikä laitteen ikä siihen vaikuta. Ohjelma vaan toimii näkyy oikein riippumatta laitteen- ja ikkunan koosta.

Mies tulee räkänokastakin vaan ei tyhjän naurajasta.

QT on hyvä

No eikö useat kääntäjät kuten C/C osaa kääntää WebAssemblyksi, miltein sama asia?

Anonyymi kirjoitti:

Mies tulee räkänokastakin vaan ei tyhjän naurajasta.

"Mies tulee räkänokastakin vaan ei tyhjän naurajasta."

Et selvästikään ymmärrä, kuinka absurdi toi väite on, jolle nauroin :D
Jos mä lähtisin sellaista ehdottamaan omille asiakkaille, niin varmaan jäisi viimeiseksi asiakkaaksi :D :D

Anonyymi kirjoitti:

No eikö useat kääntäjät kuten C/C osaa kääntää WebAssemblyksi, miltein sama asia?

"No eikö useat kääntäjät kuten C/C osaa kääntää WebAssemblyksi, miltein sama asia?"

No ei todellakaan ole miltei sama asia!!! Ymmärrätkö, mistä puhut???

Anonyymi kirjoitti:

QT on hyvä

"QT on hyvä"

Duunitorissa työpaikat:

QT: 39
Java: 429
C#: 289

Tee itse johtopäätökset, jos pystyt....

code_red kirjoitti:

"Mies tulee räkänokastakin vaan ei tyhjän naurajasta."

Et selvästikään ymmärrä, kuinka absurdi toi väite on, jolle nauroin :D
Jos mä lähtisin sellaista ehdottamaan omille asiakkaille, niin varmaan jäisi viimeiseksi asiakkaaksi :D :D

Lue lisää

Pidänkin paljon todennäköisempänä että se joka ei ohjelmoinnista ymmärrä mitään olet sinä itse.

Anonyymi kirjoitti:

Pidänkin paljon todennäköisempänä että se joka ei ohjelmoinnista ymmärrä mitään olet sinä itse.

"Pidänkin paljon todennäköisempänä että se joka ei ohjelmoinnista ymmärrä mitään olet sinä itse."

Varmistit vaan mun oletuksen, ettet ymmärrä ohjelmistokehityksestä paskan vertaa, jos et tajua tuon väitteen naurettavuutta :D :D

code_red kirjoitti:

"Mies tulee räkänokastakin vaan ei tyhjän naurajasta."

Et selvästikään ymmärrä, kuinka absurdi toi väite on, jolle nauroin :D
Jos mä lähtisin sellaista ehdottamaan omille asiakkaille, niin varmaan jäisi viimeiseksi asiakkaaksi :D :D

Lue lisää

"Jos mä lähtisin sellaista ehdottamaan omille asiakkaille, niin varmaan jäisi viimeiseksi asiakkaaksi"

Tiedätkö mitä, minä uskon että sinun asiakkuutesi liittyy enemmän tuonne terveyspuolelle, näin kirjoituksistasi voisi olettaa, paranemisia toivoen anonyymi.

Anonyymi kirjoitti:

"Jos mä lähtisin sellaista ehdottamaan omille asiakkaille, niin varmaan jäisi viimeiseksi asiakkaaksi"

Tiedätkö mitä, minä uskon että sinun asiakkuutesi liittyy enemmän tuonne terveyspuolelle, näin kirjoituksistasi voisi olettaa, paranemisia toivoen anonyymi.

Lue lisää

Mun puolesta usko mihin haluat :D Tosiasia on että kyseinen ehdotus on täysin absurdi ja naurettava :D :D

code_red kirjoitti:

Mun puolesta usko mihin haluat :D Tosiasia on että kyseinen ehdotus on täysin absurdi ja naurettava :D :D

Tietämättömyydestä ja tiedon puutteesta johtui aikoinaan myös uskomus ettei maapallo olisi pyöreä.

code_red kirjoitti:

"No eikö useat kääntäjät kuten C/C osaa kääntää WebAssemblyksi, miltein sama asia?"

No ei todellakaan ole miltei sama asia!!! Ymmärrätkö, mistä puhut???

Ymmärrätkö itse mistä puhut?

https://webassembly.org/getting-started/developers-guide/

Anonyymi kirjoitti:

Ymmärrätkö itse mistä puhut?

https://webassembly.org/getting-started/developers-guide/

Lue lisää

"Ymmärrätkö itse mistä puhut?"

Luetun ymmärtämisessä vaikeuksia? Mee nyt kattomaan mitä aloittaja ehdotti!!! Ei kyse ollut mistään webassemblystä vaan:

"Kirjoitetaan koodi esim. Delphin tai FreePascalin editorilla objectpascal -kielellä, syötetään ko. koodi freepascal.org -sivustolta ilmaiseksi imuroitavissa olevaan "source to source" kääntäjään, joka tuottaa vastaavan asian tekevän koodin javascriptinä, joka siis kelpaa selaimelle suoritettavaksi"

Onko mielestäsi tässä kyse webassemblystä tässä?

code_red kirjoitti:

"Ymmärrätkö itse mistä puhut?"

Luetun ymmärtämisessä vaikeuksia? Mee nyt kattomaan mitä aloittaja ehdotti!!! Ei kyse ollut mistään webassemblystä vaan:

"Kirjoitetaan koodi esim. Delphin tai FreePascalin editorilla objectpascal -kielellä, syötetään ko. koodi freepascal.org -sivustolta ilmaiseksi imuroitavissa olevaan "source to source" kääntäjään, joka tuottaa vastaavan asian tekevän koodin javascriptinä, joka siis kelpaa selaimelle suoritettavaksi"

Onko mielestäsi tässä kyse webassemblystä tässä?

Lue lisää

Onpa pahoja ongelmia sinulla ymmärtää kirjoitettua tekstiä, auttaisiko jos tavaisit pari kertaa sen hitaasti.

Anonyymi kirjoitti:

Ymmärrätkö itse mistä puhut?

https://webassembly.org/getting-started/developers-guide/

Lue lisää

Kyse ei ollut webassemblyn tuottamisesta vaan aloittajan mielestä olisi järkevää tehdä sovelluksia kirjoittamalla ne Lazaruksella ja jääntämällä pas2js -palikalla Javascriptiksi.

Käyttöliittymien tekeminen kunnolla edellyttää kuitenkin pääsyä DOM:n mistä ei tajua Lazarus eikä pas2js yhtään mitään. Myöskään Webassemblyllä ei käytetä DOM:ia, että siinä on lähinnä pääsy grafiikkapintaan tai sillä ajetaan edustalla jotain prosessointia.

C :sta käännetty Webassembly on noin 10x nopeampi kuin pas2js.

Sitten olisi kiva tietää että mitähän helvettiä sillä Lazaruksella tai pas2js:llä oikein tekisi kun ne eivät ole mihinkään hyviä?

Delphi on historiaa!

Anonyymi kirjoitti:

Delphi on historiaa!

Kannattaisiko sitten palkata Delphi-osaajia jos niitä on tarjolla? Qt-osaajia ei ainakaan ole yhtään vapaana. Sekin on valinta.

Anonyymi kirjoitti:

Kannattaisiko sitten palkata Delphi-osaajia jos niitä on tarjolla? Qt-osaajia ei ainakaan ole yhtään vapaana. Sekin on valinta.

Qt:tä tarvitsee melko vähän. Ei se oikein ole tätä päivää ollut kymmeneen vuoteen pois lukien muutama erikoisempi kohde.