Tänne tietenkin kirjoittelevat enemmän koodaajat kuin IT -alan työnantajien edustajat.
Tästä syystä voi olla vaikea saada tarkkaa tilannetietoa asiasta, mutta oma arvioni on se, että kun jossain ilmoitetaan vapaa työpaikka haettavaksi, jossa saa koodata Delphillä, niin Delphi -työpaikkoja on avoinna Suomessa niin harvoin, että kun sellainen joskus ilmoitetaan, niin yhteen työpaikkaan voi olla yli 100 hakijaa, ja näistä suurin osa tai kaikki päteviä haettuun tehtävään.
Että se siitä IT -alan "työvoimapulasta".
Eräs typerimpiä päätöksiä IT-alalla oli se, että kun oli ilmeisesti tahtotila siihen, että ns. Full Stack Developer -idealla sama koodaaja koodaa sekä selaimessa ajettavan koodin että palvelimessa ajettavan koodin, niin kun järkevää olisi ollut tehdä näin:
Koodataan palvelinpään koodi Delphillä ja selaimessa ajettavan koodin voi tuottaa näin: 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,
niin sensijaan monessa yrityksessä päätettiinkin koodata javascriptillä myös palvelinpään koodi, minkä mahdollistamiseksi kehitettiin node.js -niminen ratkaisu, joka sallii javascriptin suorituksen palvelimella.
Sopii kysyä:
Miksi niin moni yritys lähti mukaan moiseen hölmöilyyn, ja sitten valitetaan IT -alan työvoimapulaa, kun tosiasiassa on enemmänkin pulaa osaavista IT -johtajista jotka suostuisivat ymmärtämään ylläolevan asian ja toimimaan sen mukaan:
eli koodataan palvelinkoodi Delphillä ja selaimessa ajettava koodi käännetään objectpascalista javascriptiksi ja ajetaan se selaimessa.
Toimitusjohtajat herätys:
Olisikohan aika antaa potkut osaamattomalle IT -johdolle ja palkata parempia tilalle ?
Delphi -koodareita saattaa olla aikamoinen määrä työttömänä, kun delphi -koodaajia ei etsi töihin oikein kukaan !
Näin siitä huolimatta, että Delphi työvälineenä on erinomainen, koska delphin objectpascal -kieli toimii sujuvasti ohjelmoijan oman ajattelun jatkeena, eli ajatus siitä, miten koodin tulee toimia, niin sen pohjalta on helppo kirjoittaa objectpascalilla toteutus.
Työllisyys ja Delphi
65
1749
Vastaukset
- Anonyymi
Bash Shell-, Python- scriptien liittymät on erittäin kätevä tehdä Lazaruksella ja unohtaa Tkinter-ohjelmointi kokonaan.
- Anonyymi
Poesta windowsssss
Winddows -aukko laajenee, imee ja pulpahtelee!...
===================================== - Anonyymi
Anonyymi kirjoitti:
Poesta windowsssss
Winddows -aukko laajenee, imee ja pulpahtelee!...
=====================================Ota siittä vaari!
- Anonyymi
EI TUMPELOKOODAAJA MITÄÄN TYÖTÄ SAA!
- Anonyymi
Ei tuossa esittämässäsi tavassa ole mitään järkeä.
Sekä backend ja frontend tehdään tällä vuosikymmenellä Nodella.
Mummonaikaisia dinosauruskoodeja on turha laittaa hidastamaan järjestelmiä.- Anonyymi
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
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..
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
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.("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
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.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
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.Ahaa, nyt olet jo tietoinen minun työelämästäkin, se kyllä kertoo riittävästi, mitä miehiä sinä olet.
- Anonyymi
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.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
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.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
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.Etkö vain voisi mennä muualle, kukaan ei kaipaa sinua täällä. Hus hus häiritsemästä alan ammattilaisia.
- Anonyymi
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
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ää."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
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ää.Oletko hullu?
- Anonyymi
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 ?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
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..
" 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
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."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
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."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
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 ?"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
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.Toinen köykäinen: Rust
- Anonyymi
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ää.Java on edelleen nykypäivää.
- Anonyymi
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..
Jos oot nettihäirikkö, ei sua kukaan palkkaa!
- Anonyymi
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
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..
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
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."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
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."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
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."Delphillä tehty koodi on energiatehokkaampaa" On täyttä paskaa!
- Anonyymi
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
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! :)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
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."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
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.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.
- Anonyymi
Mielellään tekisin front-endin Delphin kaltaisella visuaalisella työkalulla, jonka voisi sitten kääntää vaikka WebAssemplylla selaimessa pyöriväksi. Olkoon kieli oikeestaan mikä tahansa, kunhan saisi Delphin kaltaisen IDE:n designtimelle. Ärsyttää nämä nykyiset JavaScript frameworkit, Reactit sun muut.
Oli niin mahtavuutta ja ikävä Delphin aikaa kun esim. Gridin vain lätkäsi formille ja luki siihen datan ja koodasi pari eventtiä. Helevata nämä on säädön takana kun teet vastaavan JavaScriptilla.
PHP:ta viimeiset 10v työkseni koodanneena se on aika joustava ja helppo, toki tehokkuutta saisi jos voisi back-endin koodailla käännettäväksi natiiviksi softaksi.
- Ex-Delphisti- Anonyymi
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
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.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
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"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. - Anonyymi
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
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.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
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-DelphistiEi 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
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." 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
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."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.
- Anonyymi
" jossa saa koodata Delphillä"
Miksi työnantajat palkkaisi mihinkään "saa koodata Delphillä" -työhön kun ohjelmistokehitys on kuitenkin tiimityötä ja työtä tehdään ihan eri työkaluilla?
"Että se siitä IT -alan "työvoimapulasta"."
Kyllä sitä työvoimapulaa on mutta sillä tarkoitetaankin osaajia. Ei mitään Delphin nysvääjiä.
"Eräs typerimpiä päätöksiä IT-alalla oli se, että kun oli ilmeisesti tahtotila siihen, että ns. Full Stack Developer -idealla sama koodaaja koodaa sekä selaimessa ajettavan koodin että palvelimessa ajettavan koodin"
Tällaista päätöstä ei ole tehty ja useinkin kehittäjä toimii isommissa projekteissa joko backendin tai frontendin puolella. Kyse on siitä, että IT-alalla kaivataankin osaajia ja nykyään ohjelmoija useinkin osaa backendin, frontendin, suunnittelee tietokannan, vie tuotantoon, hoitaa testauksen, käyttää mitä tahansa ohjelmointikieltä, tekee ohjelman alusta loppuun tarvittaessa yksin ja ymmärtää liiketoimintaakin.
Siis sitä työvoimapulaa että työntekijät ovat tehtäviensä tasalla.
"Koodataan palvelinpään koodi Delphillä ja selaimessa ajettavan koodin voi tuottaa näin: 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"
Object pascal kielelle ei ole kunnollisia työkaluja joten sitä ei käytetä alalla.
"Delphi -koodareita saattaa olla aikamoinen määrä työttömänä, kun delphi -koodaajia ei etsi töihin oikein kukaan !"
Ei sellaisia haluta. IT-alalla on työvoimapula ihmisistä jotka ovat tehtäviensä tasalla. ""source to source" kääntäjään, joka tuottaa vastaavan asian tekevän koodin javascriptinä, joka siis kelpaa selaimelle suoritettavaksi,"
Ei hitto että sain hyvät naurut. :D- Anonyymi
Mies tulee räkänokastakin vaan ei tyhjän naurajasta.
- Anonyymi
QT on hyvä
- Anonyymi
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 :DAnonyymi 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....- Anonyymi
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 :DPidä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- Anonyymi
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"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.Mun puolesta usko mihin haluat :D Tosiasia on että kyseinen ehdotus on täysin absurdi ja naurettava :D :D
- Anonyymi
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ä.
- Anonyymi
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/"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ä?- Anonyymi
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ä?Onpa pahoja ongelmia sinulla ymmärtää kirjoitettua tekstiä, auttaisiko jos tavaisit pari kertaa sen hitaasti.
- Anonyymi
Anonyymi kirjoitti:
Ymmärrätkö itse mistä puhut?
https://webassembly.org/getting-started/developers-guide/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ä?
- Anonyymi
Osaavat Linuxille koodaavat saa heti töitä mm Tampereella
Tarvetta olisi kymmenille. - Anonyymi
Jos ei ole töitä, Opettele Oodo modaajaksi! Ja kyllä on töitä!
Eli siis yksilöit Oodon yrityksen tarpeisiin. - Anonyymi
QT on nykypäivää..
- Anonyymi
Delphi on historiaa!
- Anonyymi
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
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.
Ketjusta on poistettu 13 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Finlayson Tom of Finland tuotteineen ajautumassa konkurssiin
Takavuosina kotimainen lakana- ja pyyhevalmistaja Finlayson teki jättimäisiä voittoja, myymällä alastomien gay-miesten k1423011Ajattelit siis löytäneesi onnen minusta
Etkä sitä silloin sanonut. Miksi oi miksi. Olisit avannut suusi. Olisin kääntänyt vaikka minkä kiven, että oltaisiin voi322540- 1362096
Suhde varattuun, kuinka saa tunteet katoamaan
Kuinka unohtaa ihminen johon olet tulen palavasti ihastunut/rakastunut, varsinkin jos olet varattu tai kohteesi on vara1411728Mies millä tasolla sun kiinnostus oli?
Mitä musta halusit/hait? Nyt kun kaikki on ohi, ei ole mitään menetettävää enää...831447- 341314
- 1031239
Lubondaksentiellä taitaa huomenna tyssätä!
Nyt TAX-1 hakee kolmatta kertaa poikkeuslupaa venevajan muuttamiseksi kesäasuntoon! Sari Paljakka ehdottaa lautakunnalle21209Nainen, jos kiinnostaa niin miksi ihmeessä
et kirjoita tänne jotain tunnistettavaa? On niin paljon eri mahdollisuuksia ottaa esille yksityiskohtia menneestä ajasta671184Pienimies pääsi kunnanjohtajaksi
Se oli suuri voitto meille kaikille, nyt saa Yli-torniolaiset maistaa miten kuntaa johdetaan.251070