Olen sitä mieltä, että Java on huono teknologia, koska:
-Sen omistaa yritys.
-Se toteuttaa huonon kielen (lähinnä pakotettu-"all is object" OO ja monisanainen syntaksi), jonka takia tarvittiin esimerkiksi Kotlin paikkaamaan sitä.
-Sen tyyppijärjestelmä poikkeaa hieman muista.
-Sen keskeisyys JVM:ssa tarkoittaa, että JVM:lle on hankala toteuttaa muitakaan kieliä, jotka ohittaisivat Java:n huonoja puolia.
Eräs kuva:
https://external-content.duckduckgo.com/iu/?u=https://i.pinimg.
Yleensäkin en keksi lainkaan, miksi käyttäisin Javaa C++:n sijaan.
Mutta ymmärrän, miksi Clojure yms. on kehitetty.
Mielestäni tulisi siis olla jokin JVM:n kaltainen juttu, joka on kuitenkin vähemmän huono kuin Java ja JVM. Luulin eräiden keskusteluiden perusteella, että LLVM on tällainen.
Java on helppo kieli ja aloittelijat pääsee sillä hyvin liikkeelle!
TapaniS kirjoitti:
Java on helppo kieli ja aloittelijat pääsee sillä hyvin liikkeelle!
No siis, luulin, että Java oli alunperin JVM:n demokieli. Tätä tukee se, että Java ei edes toteuta kaikkea JVM:ssä.
mavavilj kirjoitti:
Olen sitä mieltä, että Java on huono teknologia, koska:
-Sen omistaa yritys.
On myös olemassa:
https://en.wikipedia.org/wiki/OpenJDK
mavavilj kirjoitti:
-Se toteuttaa huonon kielen (lähinnä pakotettu-"all is object" OO ja monisanainen syntaksi), jonka takia tarvittiin esimerkiksi Kotlin paikkaamaan sitä.
WAD
mavavilj kirjoitti:
-Sen tyyppijärjestelmä poikkeaa hieman muista.
Jokaisella kielellä on oma tyyppijärjestelmä.
mavavilj kirjoitti:
-Sen keskeisyys JVM:ssa tarkoittaa, että JVM:lle on hankala toteuttaa muitakaan kieliä, jotka ohittaisivat Java:n huonoja puolia.
Ei pidä paikkaansa:
"
ChatGPT
JVM bytecode is not tightly bound to the Java language itself. While Java was the original language designed to compile to JVM bytecode, the JVM (Java Virtual Machine) is designed to be language-agnostic.
Many programming languages other than Java, such as Kotlin, Scala, Groovy, Clojure, and Jython, can also be compiled to JVM bytecode and run on the JVM. These languages leverage the JVM's capabilities, such as its garbage collection, security features, and platform independence, while providing their own language syntax and features.
Therefore, JVM bytecode serves as an intermediate language that can be generated by compilers for various programming languages, not just Java. This allows developers to choose the language that best fits their needs while still benefiting from the JVM's robust runtime environment.
"
mavavilj kirjoitti:
Yleensäkin en keksi lainkaan, miksi käyttäisin Javaa C++:n sijaan.
Moni on kuitenkin keksinyt pitkään koska monia vuosia keikkunut käytetyinpien ohjelmointikielien top-listalla elllei jopa kärjessä.
On omalla tavallaan viihdyttävää, että tämä perinteinen C++-uskonto on edelleen voimissaan, vaikka nimenomaan korkeamman tason kielten suhteellinen nopeus on vuosi vuodelta parantunut ja tulkin tms. koko ei nykyisillä nettiyhteyksillä enää ole niin kiinnostava tekijä kuin 20 vuotta sitten.
Jos et keksi yhtään syytä käyttää Javaa, älä sitten käytä. Monet kielet ovat eri tilanteissa hyviä vaihtoehtoja Javalle, esimerkiksi C++, Rust, C#, Python, PHP, JavaScript. Et ole rajannut kysymystä sillä tavalla, että siihen olisi järkevää esittää jotain yksittäistä ratkaisua. Ehkä vain kaipaat lisää ideoita, mitä kieliä voisit haukkua C++:n ylistykseksi.
_Pete_ kirjoitti:
mavavilj kirjoitti:
-Se toteuttaa huonon kielen (lähinnä pakotettu-"all is object" OO ja monisanainen syntaksi), jonka takia tarvittiin esimerkiksi Kotlin paikkaamaan sitä.
WAD
https://en.wikipedia.org/wiki/Criticism_of_Java
https://gist.github.com/thom-nic/2c74ed4075569da0f80b
_Pete_ kirjoitti:
mavavilj kirjoitti:
-Sen tyyppijärjestelmä poikkeaa hieman muista.
Jokaisella kielellä on oma tyyppijärjestelmä.
Miksi näin pitäisi olla?
_Pete_ kirjoitti:
mavavilj kirjoitti:
-Sen keskeisyys JVM:ssa tarkoittaa, että JVM:lle on hankala toteuttaa muitakaan kieliä, jotka ohittaisivat Java:n huonoja puolia.
Ei pidä paikkaansa:
"
ChatGPTJVM bytecode is not tightly bound to the Java language itself. While Java was the original language designed to compile to JVM bytecode, the JVM (Java Virtual Machine) is designed to be language-agnostic.
Many programming languages other than Java, such as Kotlin, Scala, Groovy, Clojure, and Jython, can also be compiled to JVM bytecode and run on the JVM. These languages leverage the JVM's capabilities, such as its garbage collection, security features, and platform independence, while providing their own language syntax and features.
Therefore, JVM bytecode serves as an intermediate language that can be generated by compilers for various programming languages, not just Java. This allows developers to choose the language that best fits their needs while still benefiting from the JVM's robust runtime environment.
"
Joo mutta millä kirjoitat sen kääntäjän?
Teknisesti ottaen tietysti voi: https://en.wikipedia.org/wiki/
Oma vastaukseni olisi voinut olla Scala, koska sen voi laittaa käyttämään esim. Boehm-GC:iä, jolloin se vastaa tavallaan C++:aa GC:lla.
mavavilj kirjoitti:
Joo mutta millä kirjoitat sen kääntäjän?
No onko sillä väliä? Aluksi voit kirjoittaa sen kääntäjän millä kielellä haluat ja kun se toimii niin paljon että pystyt kirjoittamaan omalla kielellä kääntäjän, voit siirtyä käyttämään sitä.
Olihan Java -kääntäjäkin kirjoitettu alun perin C:llä ja nykyisin Javalla.
Grez kirjoitti:
(09.02.2024 12:42:02): ”– –” No onko sillä väliä? Aluksi voit kirjoittaa sen...
Eikös tässä ole nimenomaan se raja, josta sanoin.
Kieli A toteuttaa kielen B.
-> Ei ole mahdollista, että kielen B ominaisuudet ovat suuremmat kuin kielen A riippumatta siitä, että onko kääntäjä lopulta toteutettu kielellä B.
mavavilj kirjoitti:
Eikös tässä ole nimenomaan se raja, josta sanoin.
Kieli A toteuttaa kielen B.
-> Ei ole mahdollista, että kielen B ominaisuudet ovat suuremmat kuin kielen A riippumatta siitä, että onko kääntäjä lopulta toteutettu kielellä B.
Mikä ihmeen raja? Eihän tuossa ole mitään järkeä. Miksi jos kääntäjä kielelle B tehdään kielellä A, niin sen kääntäjän tarvitsisi välittää mitään siitä, mitkä kielen A ominaisuudet on?
Ja sitä paitsi jos nyt ajatellaan jotain olemassa olevaa kieltä niin sen kääntäjänhän voi kirjoittaa heti suoraan sillä kielellä. Eli jos vaikka Pythonia saa suoritettua tulkilla ympäristössä X (vaikka Linux), niin sillä voi kirjoittaa Python->JVM -kääntäjän ja sen voi tulkilla ajaen sitten kääntää JVM:ksi ja sen jälkeen ajaa JVM:llä pyörivää Python-kääntäjää.
Grez kirjoitti:
(09.02.2024 12:49:02): ”– –” Mikä ihmeen raja? Eihän tuossa ole mitään...
Siis koska kääntäjä ei voi esittää muita asioita kuin mitä kääntäjän toteuttavassa kielessä on.
Jos on niin, että Java ei toteuta koko JVM:n instruction set:iä, niin kaikki Java:lla tehdyt kääntäjät eivät myöskään toteuta.
JVM tarkoittaa myös, että ei ole olemassa JVM-kieliä, joissa ei ole roskienkeruuta.
mavavilj kirjoitti:
Jos on niin, että Java ei toteuta koko JVM:n instruction set:iä, niin kaikki Java:lla tehdyt kääntäjät eivät myöskään toteuta.
Sä nyt puhut ilmeisesti systeemistä, jossa kielestä X tehdään välikäännös Javaksi ja vasta se käännetään JVM:ksi. Tämä on tällainen surkea välimalli. Yleensä kääntäjä kääntää kieltä suoraan kohteeksi. Eihän kaikki Linuxilla toimivat kääntäjätkään käännä koodia ensin C-kieleksi ja siitä sitten vasta tee binääriä, vaikka varmaan sellaisiakin on.
Grez kirjoitti:
(09.02.2024 12:52:41): ”– –” Sä nyt puhut ilmeisesti systeemistä, jossa...
Ei vaan myös, että turingin kone A ei voi tunnistaa turingin konetta B, jos B:llä on laajempi instruction set.
Eli että kääntäjä, joka ei toteuta koko instruction set:iä ei voi tunnistaa koko instruction set:iä käyttäviä kieliä täydellisesti.
mavavilj kirjoitti:
Ei vaan myös, että turingin kone A ei voi tunnistaa turingin konetta B, jos B:llä on laajempi instruction set.
Millä vaan turingin koneella voi tehdä kääntäjän joka kääntää mitä tahansa koodia mihin tahansa kohde instruction settiin. Ei sillä koneen käyttämällä instruction setillä tarvitse olla ole yhtään mitään korrelaatiota kohde instruction settiin.
Minäkin pystyn omalla X86-PC:lläni kääntämään koodia Armille, jossa on eri instruction set.
Jos tekisin kuusnepalle kääntäjän joka kääntää vaikka C:tä x86-koodiksi, niin se että 6502 prosessorissa ei ole liukulukuoperaatioita, ei mitenkään estäisi kääntämästä koodia x86:n liukulukuoperaatioiksi. Käytännössä toki kaikkia C ominaisuuksia toteuttavan kääntäjän tekeminen voisi olla hankalaa, mutta siinä ehkä enemmänkin tökkisi muistin määrä kuin se että jotain toimintoja puuttuu.
No miksi Java:lla ei voi toteuttaa C++:n kääntäjää ilman GC:ia? Koska sen pitää simuloida myös GC, koska Java:ssa ei ole konseptia manuaalisesta muistista.
mavavilj kirjoitti:
No miksi Java:lla ei voi toteuttaa C++:n kääntäjää ilman GC:ia? Koska sen pitää simuloida myös GC, koska Java:ssa ei ole konseptia manuaalisesta muistista.
Tässäkään ei ole relevantti se, onko kääntäjä toteutettu Javalla tai ihan muulla kielellä. Kääntäjän täytyy tietenkin huomioida kohdeympäristön, esimerkiksi JVM, rajoitteet. Eli ihan sama millä kielellä teet kääntäjän, niin C64:ssä on silti vain 64kt muistia.
Grez kirjoitti:
(09.02.2024 13:19:18): ”– –” Tässäkään ei ole relevantti se, onko kääntäjä...
Nähdäkseni mikään Java:lla tai JVM:lle tehty kääntäjä ei osaa tehdä free:tä. Miksi se ei siten ole relevanttia?
Ja siis:
lainaus:
Olihan Java -kääntäjäkin kirjoitettu alun perin C:llä ja nykyisin Javalla.
Nimenomaan toimii, koska card(C) > card(Java).
mavavilj kirjoitti:
Nimenomaan toimii, koska card(C) > card(Java).
No mikään ei estäisi tekemästä C-kääntäjää Javalla. Javalla pystyy tekemään kääntäjän ihan mistä tahansa kielestä ihan mihin tahansa ympäristöön. Tai jos ei pysty, niin sitten sitä ei pysty tekemään muullakaan kielellä.
Lopeta jo se trollaaminen. Vai onko oikeasti niin, että sinulla ei ole minkäänlaista käsitystä siitä, mitä kääntäjä tekee?
mavavilj kirjoitti:
Eli että kääntäjä, joka ei toteuta koko instruction set:iä ei voi tunnistaa koko instruction set:iä käyttäviä kieliä täydellisesti.
Jos mielestäsi ei ole mahdollista pienemmällä tai erilaisella käskykannalla kääntää ohjelmaa suuremmalle käskykannalle, miten sitten ikinä on saatu tehtyä uusiin tietokoneisiin ajurit ja käyttöjärjestelmät?
Konekieli (esim. nyt x86_64) ei sisällä käskyjä muistin varaamiseen ja vapauttamiseen tai tiedostojen käsittelyyn, joten koko muistinhallinta ja tiedostojen olemassaolo on yhtä simulaatiota ja C-kieli on vain suuri huijaus.
Metabolix kirjoitti:
mavavilj kirjoitti:
Eli että kääntäjä, joka ei toteuta koko instruction set:iä ei voi tunnistaa koko instruction set:iä käyttäviä kieliä täydellisesti.
Jos mielestäsi ei ole mahdollista pienemmällä tai erilaisella käskykannalla kääntää ohjelmaa suuremmalle käskykannalle, miten sitten ikinä on saatu tehtyä uusiin tietokoneisiin ajurit ja käyttöjärjestelmät?
Tietysti niiden symbolisella konekielellä.
On mahdollista, mutta käännetty ohjelma ei voi käyttää lähtökielen ulkopuolisia ominaisuuksia.
Metabolix kirjoitti:
mavavilj kirjoitti:
Eli että kääntäjä, joka ei toteuta koko instruction set:iä ei voi tunnistaa koko instruction set:iä käyttäviä kieliä täydellisesti.
Konekieli (esim. nyt x86_64) ei sisällä käskyjä muistin varaamiseen ja vapauttamiseen tai tiedostojen käsittelyyn, joten koko muistinhallinta ja tiedostojen olemassaolo on yhtä simulaatiota ja C-kieli on vain suuri huijaus.
No siis eräs toinen kiinnostava paradigma voisi olla "App-Rust".
mavavilj kirjoitti:
On mahdollista, mutta käännetty ohjelma ei voi käyttää lähtökielen ulkopuolisia ominaisuuksia.
Sinulla menee nyt puurot ja vellit sekaisin. Kaikki koodi on dataa ja sillä millä kielellä kääntäjä on kirjoitettu ei ole mitään merkitystä. Mikäli kääntäjä tuottaa Java tavukoodia tarvitsee sen tuottama koodi tietysti JVM:n toimiakseen.
jalski kirjoitti:
(09.02.2024 15:33:44): ”– –” Sinulla menee nyt puurot ja vellit sekaisin...
No mutta, miten esim. deterministinen malloc/free -sykli ilmaistaan JVM:stä?
Kääntäjän pitää osata muodostaa oikeanlainen AST.
mavavilj kirjoitti:
No mutta, miten esim. deterministinen malloc/free -sykli ilmaistaan JVM:stä?
Miksi pitäisi ilmaista? Älä tuota tavukoodia JVM:lle, mikäli GC on ongelma. Totuushan on, että Javan GC on oikeasti erittäin suorituskykyinen ja harvoin aiheuttaa ongelmia. Tällä ei ole kuitenkaan mitään tekemistä sen kannssa, että Javalla ei voisi kirjoittaa kääntäjää. Ei käännetyn binäärin tarvitse tietää mitään kääntäjästä.
mavavilj kirjoitti:
Kääntäjän pitää osata muodostaa oikeanlainen AST.
Yksinkertaisen kääntäjän kirjoittamiseen ei tarvitse tietää AST:stä mitään.
jalski kirjoitti:
(09.02.2024 16:58:21): ”– –” Miksi pitäisi ilmaista? Älä tuota tavukoodia...
Kysymys on, että voiko se ilmaista?
mavavilj kirjoitti:
Kysymys on, että voiko se ilmaista?
Miksi ei voisi?
Grez kirjoitti:
mavavilj kirjoitti:
Kysymys on, että voiko se ilmaista?
Miksi ei voisi?
Se varmaan voikin, jos syöteohjelma sisältää ne. Tällöin kuitenkin on mahdollista, että syötekieli on eräänlainen C++ DSL. Sattumalta tämä on ehkä se, miten Scala Native näyttäytyy.
https://www.scala-lang.org/blog/2021/01/19/scala-native-0.4-release.html
On aivan itsestään selvää että minkä tahansa kääntäjän pystyy toteuttamaan millä tahansa Turing-täydellisellä kielellä. Käytännössä kaikki ohjelmointikielet ovat Turing-täydellisiä.
Jos olet eri mieltä tästä, niin voisitko avata että miksi väite ei pidä paikkaansa.
Grez kirjoitti:
On aivan itsestään selvää että minkä tahansa kääntäjän pystyy toteuttamaan millä tahansa Turing-täydellisellä kielellä. Käytännössä kaikki ohjelmointikielet ovat Turing-täydellisiä.
Jos olet eri mieltä tästä, niin voisitko avata että miksi väite ei pidä paikkaansa.
Alkuperäinen ongelma koski JVM:ää targetina. Toki Javan voisi kääntää suoraan konekielelle, mutta tällöin se ei kai voi käyttää JVM:n kirjastoja.
Osaatko selittää, mitä free-kutsu tavallisessa ohjelmassa sisäisesti tekee? Onko asialla edes merkitystä? Oletko itse lukenut edes C:n standardia vai väitteletkö ihan fiilispohjalta?
C ei taida asettaa mitään vaatimuksia, millä aikataululla muisti vapautuu muille prosesseille tai onko tällaista konseptia edes olemassa. Kuvitelmasi, että tämä tapahtuisi C:ssä jotenkin JVM:n näkökulmasta mahdottoman "deterministisesti" (käytit kyllä tätäkin sanaa väärin), ei taida perustua mihinkään faktaan. Muistisivujen käsittely on käyttöjärjestelmän vastuulla eikä C ota siihen kantaa; free ei takaa minkään muistisivun vapautumista millään tietyllä tavalla.
JVM:llä malloc ja free voitaisiin siis toteuttaa suunnilleen samalla tavalla kuin muissakin järjestelmissä: standardikirjasto pyytää järjestelmältä (JVM, Windows, Linux tms.) kerralla isomman palan muistia ja jakaa sitä sitten ohjelman sisällä, ja kun koko pala ohjelman puolesta vapautuu, standardikirjasto mahdollisesti ilmoittaa järjestelmälle siitä, ellei ole toteutettu niin, että jokin määrä muistia pidetään varalla (mikä voisi olla hyvin järkevää jossain tilanteissa). Käyttäjälle eli C-koodarille ei kuulu, miten standardikirjasto ja järjestelmä (Linux tai JVM) muistin viime kädessä vapauttaa.
Isompi hidaste JVM:ssä saattaisi liittyä eri tietotyyppeihin ja osoittimilla kikkailuun. Toisaalta C määrittelee aika löyhät puitteet, joten varmaan jokin standardiin sopiva ratkaisu löytyisi. Pitäisi tarkistaa JVM:n rajat ja C:n vaatimukset.
Ja edelleen, vaikka JVM:ssä ei olisi natiivia ratkaisua johonkin, aina jokin kiertotie tai emulointitapa löytyy. Viime kädessä voisi ajaa JVM:n sisällä x86-emulaattoria ja siinä vaikka Linuxia ja siinä tavallista C-ohjelmaa. Ongelma ratkaistu! Tämä on siihen kielten Turing-täydellisyyteen liittyvä asia, kai ymmärrät sen? (Aiemmista viesteistä päätellen ei taida olla ihan hallussa...)
mavavilj kirjoitti:
Alkuperäinen ongelma koski JVM:ää targetina.
Voi olla, mutta tuntuu että joka viestissä ongelma vaihtui.
Kuten jo aikaisemmin sanoin niin tietenkin jos käännöksen kohteena on JVM, niin eletään JVM:n mahdollistamissa puitteissa. Mutta jos itse toteuttaa kääntäjän JVM:lle, niin kaikkia JVM:n ominaisuuksia on mahdollista käyttää, ei pelkästään niitä joita Java käyttää (kuten väitit). Ei edes silloinkaan, vaikka kääntäjän kirjoittaisi Javalla. (kuten väitit)
mavavilj kirjoitti:
Toki Javan voisi kääntää suoraan konekielelle, mutta tällöin se ei kai voi käyttää JVM:n kirjastoja.
No se on taas erillinen ongelma, eikä siinäkään ole kyse siitä etteikö niitä kirjastojakin voisi kirjoittaa vaikka konekielellä - vaan enemmänkin että miksi kukaan niin haluaisi tehdä.
Päivä kerrallaan ja sen mukaan edetään. Jokaisella kielellä on omat vahvuutensa ja heikkoutensa. Itse olen vuosien myötä omassa työssäni oppinut arvostamaan Pythonia, mutta en silti dissaa muita ohjelmointikieliä. Jos olisin jossain muussa ammatissa, niin pitäisin jotain toista kieltä todennäköisesti vahvempana (älä pakota leipuria mekaanikoksi, jne.). Muista että itse päätät, mihin kieleen haluat erikoistua ja valitse ammattisi sen mukaan.
Ei kun minusta pääongelma on, että ehkä Javan suosio ei perustu teknologiseen etuun, vaan johonkin muuhun.
Aika harvoin se mitä ihmiset tykkää käyttää erilaisiin asioihin perustuu "teknologiseen etuun". Se voi olla yksi tekijä, mutta sanoisin että todella usein sen merkitys päätöksenteossa saattaa olla jopa alle 10%.
No minusta on myös väärin, että jotkut Alan Kay:t ohitetaan, koska React tai jotain.
mavavilj kirjoitti:
Ei kun minusta pääongelma on, että ehkä Javan suosio ei perustu teknologiseen etuun, vaan johonkin muuhun.
https://spectrum.ieee.org/the-top-programming-languages-2023
Jos nämä laitettaisiin "teknologia etu" järjestykseen niin miten menisi top-10 lista?
_Pete_ kirjoitti:
mavavilj kirjoitti:
Ei kun minusta pääongelma on, että ehkä Javan suosio ei perustu teknologiseen etuun, vaan johonkin muuhun.
https://spectrum.ieee.org/the-top-programming-languages-2023
Jos nämä laitettaisiin "teknologia etu" järjestykseen niin miten menisi top-10 lista?
Siis yleisesti paras on tietysti Pareto-optimaalinen ominaisuuksien suhteen. Java ei ole, mutta se on yleisesti käytetty. Python myös.
On mahdollista, että se löytyy myös yhdistämällä olemassaolevia.
Jotta voisi arvioida pareto-optimaalisuutta, pitäisi ensin määritellä mitattavat kriteerit.
Metabolix kirjoitti:
Jotta voisi arvioida pareto-optimaalisuutta, pitäisi ensin määritellä mitattavat kriteerit.
No niin. En itseasiassa ole löytänyt tällaista, joten ehkä tutkimusalue on jokseenkin novel. On tuolla se energy efficiency -chart verkossa, mutta se on pinnallinen.
Noita top charteja vääristää ad populum ja se, että alustoilla kuten Android ei ole vaihtoehtoja. Ja myös, että eri alustoilla on eri määrä käyttäjiä.
mavavilj kirjoitti:
Ehkä tutkimusalue on jokseenkin novel.
Joo, tuskin kukaan on koskaan keksinyt vertailla ohjelmointikieliä, taidat olla ainutlaatuinen nero. Koko ohjelmistoala tulee mullistumaan, kun tämä parhaan kielen ongelma vihdoin rationaalisesti ratkeaa!
mavavilj kirjoitti:
Ei kun minusta pääongelma on, että ehkä Javan suosio ei perustu teknologiseen etuun, vaan johonkin muuhun.
Monesti isoissa ohjelmistohankkeissa mietitään myös tuotteen elinkaarta. Jos elinkaaritavoite on vaikka 25vuotta, pitäisi sen ajan olla kehittäjiä tarjolla. Ja tämä edellyttää että näitä koulutetaan aktiivisesti.
Javaa koulutetaan melkeinpä joka korkeakoulussa yhäkin eniten suhteessa muihin kieliin, joten on luonnollista että kieltä myös käytetään hankkeissa samassa suhteessa. Nyt Kotlin taitaa kuitenkin pikkuhiljaa nakertaa Javan suosiota, ainakin Suomessa. Tämä siis vain oma subjektiivinen kokemus, kun kyselin eri toimittajien kehittäjiltä heidän näkemyksiään valtion hankepuolella viime vuonna.
Metabolix kirjoitti:
mavavilj kirjoitti:
Ehkä tutkimusalue on jokseenkin novel.
Joo, tuskin kukaan on koskaan keksinyt vertailla ohjelmointikieliä, taidat olla ainutlaatuinen nero. Koko ohjelmistoala tulee mullistumaan, kun tämä parhaan kielen ongelma vihdoin rationaalisesti ratkeaa!
Eli mikä on pareto-optimaalinen Java-tyyppinen kieli?
Korkeakoulut ei sitten ole mikään todiste, koska ne voi lahjoa tarjouslisensseillä tms.
groovyb kirjoitti:
(11.02.2024 22:25:39): ”– –” Monesti isoissa ohjelmistohankkeissa...
Niin ja julkishallinnollisuuskaan ei takaa kaikkia parametreja. Nehän maksaa yleensä tuesta.
Java:ssa on teoreettisena ominaisuutena se, että kun mennään JNI:n läpi, niin sen alla koodi on täsmälleen samanlaista kuin natiivi C/C++ tai vast.
En ole vaan törmännyt siihen, että joku käyttäisi tätä jotenkin fiksusti siten, ettei GC tai Java:n puutteet haittaa. Kun tällähän voi nätisti kirjoittaa halutut osat C/C++:lla, ja toiset JNI:n puolella. Voi esimerkiksi painaa vasteaikoja alas siten, että raskaammat osat lasketaan C++:ssa. Mutta en ole nähnyt sovelluksia, joissa käytetään molempien parhaita puolia.
mavavilj kirjoitti:
Eli mikä on pareto-optimaalinen Java-tyyppinen kieli?
Tähän on harvinaisen selvä vastaus: Java. Jos mitään parametria muuttaa, se on vähemmän Java-tyyppinen, eli pareto-optimaalisuus Java-tyyppisyyden suhteen on saavutettu.
Aiemman sarkasmini viesti ei ollut se, että ongelma olisi jo ratkaisu, vaan se, että ohjelmointikielelle ei varmastikaan pysty määrittelemään sellaisia kattavia ja kaikkia tyydyttäviä objektiivisia mittareita, että parhaan kielen ongelmaan edes olisi jotain hyväksyttävää ratkaisua.
Lisäksi vaikuttavat todellisuuden rajat. Esimerkiksi jos tavoite on korjata yksi yksinkertainen asia isosta ohjelmasta, tähän ajallisesti optimaalinen kieli on yleensä se, jolla ohjelma on tehty, vaikka kieli olisi muuten huono ja epäoptimaalinen.
Metabolix kirjoitti:
(13.02.2024 16:37:54): ”– –” Tähän on harvinaisen selvä vastaus: Java. Jos...
Nippu hyviä kieliä, joilla on helppo C-rajapinta? Esimerkiksi, C, C++ ja Lua. JNI on hankala käyttää.
Eikös noi juuri korjaa C++:aa jollain Rust:lla. Ei se mene silloin noin kun sanoit. Vaan kirjoittamalla uusia moduuleita uudella kielellä ja liittämällä ne C API:lla. Tämä tukisi käsitystä, että C API on eräs parametri. Mutta minusta JNI:n tapa hyödyntää sitä on kehno, koska mielestäni Java ei tarjoa mitään etuja, se vain karsii asioita ("rikkinäinen urheiluauto").
https://nim-lang.org/ oli minusta kiinnostava Java-tyyppinen kieli, mutta luulen, että se ei koskaan yleisty mihinkään muuhun kuin joihinkin tiettyihin kirjastoihin. Yhdistää Pythonimaisen syntaksin funktionaalistyyppiseen jäsennykseen ja C:mäiseen suorituskykyyn optionaalisella roskienkeruulla.
mavavilj kirjoitti:
Eikös noi juuri korjaa C++:aa jollain Rust:lla. Ei se mene silloin noin kun sanoit. Vaan kirjoittamalla uusia moduuleita uudella kielellä ja liittämällä ne C API:lla. Tämä tukisi käsitystä, että C API on eräs parametri. Mutta minusta JNI:n tapa hyödyntää sitä on kehno, koska mielestäni Java ei tarjoa mitään etuja, se vain karsii asioita ("rikkinäinen urheiluauto").
Java tarjoaa paljon etuja siihen käyttöön mihin se on suunnattu ja yleensä ottaen Java ohjelmoija ei tarvitse C API:a mihinkään.
mavavilj kirjoitti:
Niin ja julkishallinnollisuuskaan ei takaa kaikkia parametreja. Nehän maksaa yleensä tuesta.
Ei tietenkään, mutta teknologiavalintoja on pohdittava myös elinkaariajattelun näkökulmasta
jalski kirjoitti:
(13.02.2024 19:25:30): ”– –” Java tarjoaa paljon etuja siihen käyttöön mihin...
JNI kyllä tarkoitettiin noille. Mutta tästä uusi ongelma eli työkalujen käyttö epäoptimaalisiin tarkoituksiin.
Muuten, toisaalla sanottiin, että hyvien OS API:en, kuten Linux, kanssa VM:t ovat tarpeettomia, koska OS tarjoaa samanlaisen abstraktion.
mavavilj kirjoitti:
Muuten, toisaalla sanottiin, että hyvien OS API:en, kuten Linux, kanssa VM:t ovat tarpeettomia, koska OS tarjoaa samanlaisen abstraktion.
Tämä on tietyssä mielessä totta: Linuxissa on mahdollista luoda pitkälti eristettyjä suoritusympäristöjä, joissa tulee lähestulkoon vaikutelma, että ohjelmaa suoritettaisiin erillisissä virtuaalikoneessa. Tämä tarkoittaa kuitenkin virtuaalikonetta, joka tarjoaa enintään samat tekniset ominaisuudet ja saman Linux-käyttöjärjestelmän kuin isäntäkone. Tämä ei tietenkään korvaa JVM:ää, joka toteuttaa aivan eri arkkitehtuurin kuin isäntäkone ja suorittaa erityisiä ohjelmatiedostoja, joita isäntäkone ei osaa suoraan suorittaa.
Metabolix kirjoitti:
(14.02.2024 08:13:00): ”– –” Tämä on tietyssä mielessä totta: Linuxissa on...
Entä: https://www.graalvm.org/latest/reference-manual/native-image/
mavavilj kirjoitti:
Muuten, toisaalla sanottiin, että hyvien OS API:en, kuten Linux, kanssa VM:t ovat tarpeettomia, koska OS tarjoaa samanlaisen abstraktion.
Eli voit ajaa näille OS:eille käännettyjä binäärejä ko. OS:eissa millä vaan CPU:lla?
Grez kirjoitti:
mavavilj kirjoitti:
Muuten, toisaalla sanottiin, että hyvien OS API:en, kuten Linux, kanssa VM:t ovat tarpeettomia, koska OS tarjoaa samanlaisen abstraktion.
Eli voit ajaa näille OS:eille käännettyjä binäärejä ko. OS:eissa millä vaan CPU:lla?
Siis OS korvaa VM:n eli OS:n API on alustariippumaton ja OS on siirrettävä jne.
Itseasiassa, en ollut aiemmin ymmärtänyt GraalVM:n use case:a, mutta sehän on täydellinen tähän kun halutaan kuopata JVM, mutta jatkaa legacy Java-ohjelmien käyttämistä natiivi API:issa.
Erityisesti tässä kontekstissa: Java:n voi Linux:lla tai BSD:llä korvata millä tahansa.
mavavilj kirjoitti:
(14.02.2024 09:21:17): Itseasiassa, en ollut aiemmin ymmärtänyt GraalVM:n use case:a, mutta sehän on täydellinen tähän kun halutaan kuopata JVM, mutta jatkaa legacy Java-ohjelmien käyttämistä natiivi API:issa.
Mutta näytti olevan sen verran epätäydellinen toteutus, että syytetään taas Java:a siitä, ettei se salli muita. Native Image näytti myös pyörivän hitaammin kuin JVM-toteutus. Muistin käyttö on alhaisempi.
mavavilj kirjoitti:
Entä GraalVM
Sehän on selvä, että periaatteessa Java kielenä ei edellytä JVM:n käyttöä, vaikka käytännössä vaihtoehdot ovatkin vähissä. Tämä ei liity mitenkään siihen, että ”hyvien OS API:en, kuten Linux, kanssa VM:t ovat tarpeettomia”, vaan kuten jo sanoin, tässä puhutaan VM:stä kahdessa ihan eri asiayhteydessä. Jos tämä on vielä sinulle vieras alue, kannattaa ainakin päällisin puolin tutustua virtuaalikoneisiin (esim. QEMU, VirtualBox) ja näihin Linuxin mahdollistamiin vaihtoehtoisiin tekniikoihin (yleisenä esimerkkinä Docker).
Metabolix kirjoitti:
(14.02.2024 13:14:49): ”– –” Sehän on selvä, että periaatteessa Java...
Tarkoitin, että voi olla mahdollista, että JVM VM:na ei ole enää ajankohtainen. Ehkä se oli 90-luvulla yms. Tai Windows:lla. Ja että nyt voitaisiin kirjoittaa yhtä joustavia sovelluksia helposti siirrettävien käyttöjärjestelmien päälle. Tosiaan, Linux tai BSD on paljon helpompi asentaa kuin Windows.
Voisikohan toteuttaa "Javalaattorin", joka on kuin FreeBSD:n Linuxulator eli vain yhteensopivuusrajapinta, jolla ohjelma luulee, että se on edelleen JVM:ssä, vaikka se onkin natiivi. Ja tällöin siis myös Java käännettäisiin ilman JVM:ää, mutta "Javalaattori" mahdollistaisi JVM:lle tehtyjen ohjelmien ajamisen edelleen. Vai onko tämä Native Image?
mavavilj kirjoitti:
Voisikohan toteuttaa "Javalaattorin", joka on kuin FreeBSD:n Linuxulator eli vain yhteensopivuusrajapinta, jolla ohjelma luulee, että se on edelleen JVM:ssä, vaikka se onkin natiivi.
Voisitko ensin selventää, mitä eroa ajattelet ohjelman kannalta olevan sillä, onko se JVM:ssä vai natiivi, ts. mistä ohjelma tämän erottaisi ja millä tavalla se muuttaisi ohjelman toimintaa ilman tätä kuvitteellista Javalaattoria?
Metabolix kirjoitti:
(14.02.2024 13:40:10): ”– –” Voisitko ensin selventää, mitä eroa ajattelet...
JVM-ohjelma olettaa, että JVM/JRE on olemassa. Siksi kääntämällä Java-koodia staattisesti natiiviksi ei voi ajaa JVM-ohjelmia ellei käännä tai paketoi myös JRE:ia, kuten Native Image:ssa tehdään: https://external-content.duckduckgo.com/iu/?u=https://tse1.mm.
Kuitenkin, Linuxulator ei ole emulaattori: https://wiki.freebsd.org/Linuxulator. Voiko siis olla JRE, joka ei ole emulaattori, vaan kernel interface, joka toteuttaa JRE:n? Eli kovakoodataan vaan JRE:n jutut joksikin C-interfaceksi, ja JVM-ohjelma luulee, että se on JVM:ssä.
No siis se tietysti tarkoittaisi, ettei tarvitse raahata JRE:ia mukana?
Oletko nyt ihan kujalla vai mitä. Tietenkin Java-ohjelma tarvitsee Javan standardikirjaston. Ei sillä ole väliä, onko se standardikirjasto JVM:ssä tai JRE:ssä vai missä, mutta sovitut luokat ja funktiot pitää olla olemassa.
Yhtä hyvin voisit miettiä, että pitäisikö C-ohjelmaa kääntäessä laittaa mukaan "Claattori", jolla C-ohjelma luulee käyttävänsä C:n standardikirjastoa vaikka käyttääkin oikeasti "Claattoria".
Linuxulaattorin olennainen juttu on se, että siinä ajetaan Linuxille käännettyjä ohjelmia, mikä on sillä lailla kätevästi mahdollista, että itse ohjelma ja standardikirjasto on ihan käypää natiivia binäärikoodia ja vain kernelin rajapinnat joutuu uusimaan. Linuxulaattori rajapintana ei sisällä mitään massiivista Linux-kirjastojen uutta implementaatiota, vaan kyllä, ne joutuu kääntämään ja paketoimaan ohjelman mukaan. Tähän verrattuna JVM:ssä ongelmana on, että JVM:lle käännetty ohjelma on JVM:n tavukoodia, jota ei luonnollisestikaan voi ajaa x86-prosessorilla ilman virtuaalikonetta, tulkkia, emulaattoria tms. Eli koodi pitäisi kuitenkin erillisellä kääntäjällä kääntää uudestaan. Ja kyllä, standardikirjasto pitää paketoida mukaan.
Javan standardikirjaston ei tarvitse eikä kannata olla kernel interface, vaan käytännössä se olisi kirjasto, jossa on JVM:n objekti- ja GC-logiikka toteutettuna jollakin tavalla. Java kielenä pakottaa tietynlaisen muistinhallintaperiaatteen, ja tämä olisi aivan mahdollista toteuttaa jonkinlaisen C:llä tehdyn kirjaston muotoon.
Lisäksi hypoteettisesti tuo kernel-rajapinta voisi sallia GC:n poisottamisen ja lisätä manuaalisen muistinhallinnan(?) Tai sitten latenssien painamisen riittävän alas.
Ja siis ajattelin, että tällainen natiivi-Java olisi asfastascee. Mutta edelleen täysin JVM-yhteensopiva.
mavavilj kirjoitti:
...Tai sitten latenssien painamisen riittävän alas.
Eikös GC toimi asynkronisesti, joten sen latenssivaikutusta ei kyllä kannata laskea suoritusaikoihin mukaan. Se tapahtuu asynkronisesti vasta kun muistialueen käyttökin loppuu. Vai puhutko nyt GC:n latenssista, eli väliajasta varatun muistin ja vapautetun muistin välillä?
Ehkä järkevästi toteutettu "natiivi-Java" yhdistettynä hyvään GC-toteutukseen voisi olla evenfasterthanc
groovyb kirjoitti:
(14.02.2024 14:20:52): Vai puhutko nyt GC:n latenssista, eli väliajasta varatun muistin ja vapautetun muistin välillä?
"Pause times"
Täytyy myöntää, että en ole lukenut Javan matalan tason speksejä, mutta tuskin Java mitenkään kieltäisi toteuttamasta muistinhallintaa vaikka ihan reaaliaikaisesti refcountilla. Roskienkeruu voi olla kuitenkin merkittävä etu. Muistin vapauttaminen on suhteellisen kallis operaatio (tiesitkö?), ja kun monet ohjelmat eivät kuitenkaan käytä prosessoria ja muistia 100-prosenttisesti jatkuvasti vaan jossain määrin sykäyksittäin, roskienkeruu voidaan ihanteellisesti tehdä jossain kevyemmässä vaiheessa ohjelmaa.
Herra astfastascee tietysti voi tähän sanoa, että kyllähän C:ssäkin voi vaikka tiukassa silmukassa laittaa vapautettavat osoittimet johonkin taulukkoon ja vapauttaa ne vasta sitten silmukan jälkeen. Varmasti voi, mutta tässä tullaan taas kysymykseen, onko millään tavalla järkevää tai tehokasta käyttää koodarin aikaa tällaisen asian toteuttamiseen sen sijaan, että otettaisiin jokin 99-prosenttisesti riittävän hyvin toimiva valmis ratkaisu.
Metabolix kirjoitti:
(14.02.2024 14:27:36): Täytyy myöntää, että en ole lukenut Javan...
Joku sanoi joskus, että Java:lla voisi tehdä myös esim. reaaliaikaisia musiikkisekvenssereitä, mikäli sen GC:ia annettaisiin virittää siten, että korjanta voidaan tehdä silloin kun ei tehdä jotain oleellista.
Ainoa missä Java tuntuu jotenkin hyvältä minusta on Android, mutta sitten ongelmana on, että samoja ohjelmia ei halua käyttää muilla tietokoneilla. Joitain seuraamiani avoimen lähdekoodin projekteja, jotka on aloitettu Java:lla, on pyritty uudelleenkirjoittamaan C++:lla jälkeenpäin.
Kun miettii esim. projektien kielivalintoja, on syytä huomata, että myös C++ on viime versioissa kehittynyt merkittävästi. Esimerkiksi vielä muutamia vuosia sitten auto ja for eivät toimineet nykyisellä tavalla, move constructor (siirtomuodostin?) puuttui ja monia ihan tavallisia ominaisuuksia (tiedostojärjestelmän navigointi, ajanhallinta, säikeet) joutui hakemaan erillisestä kirjastosta. Kun kerran vaihtaa kielestä pois, voi olla vaikea palata takaisin: pitäisi ensinnäkin olla sopiva vaihe (esim. täysin uusi projekti, jossa voi tehdä kielivalinnan puhtaalta pöydältä) ja toiseksi motivaatiota opetella ne uudet asiat ja selvittää, onko nyt jo tarpeeksi mukavat ominaisuudet omiin tarpeisiin.
Jonnet ei muista ehkä, että vielä 15–20 vuotta sitten JavaScriptilla saattoi scriptailla jotain webbisivuja muttei voinut tehdä oikein todellisia ohjelmia, koska selainsovellus ei voinut avata paikallisia tiedostoja, AJAX oli vielä kömpelö tekniikka, Canvas oli vasta tuloillaan, ja HTML ja CSS olivat selvästi nykyistä rajoittuneempia. Siihen aikaan selainpuolen vaihtoehtoja olivat Java-appletit, joihin saattoi tehdä ihan oikeita ohjelmia, sekä multimediaesityksiin hyvin sopiva Adobe Flash. Itsekin koodasin täällä aikaisempiin kilpailuihin pelit ja testausohjelmat Java-appletteina, ja töissä koodasin Java-applettina natiivikirjaston avulla sarjaporttiin kytketyn lipputulostimen ajurin, joka toimi siis selaimessa ilman paikallisesti asennettavia osia. Nyt nämä aikaisemmin hienot tekniikat ovat historiaa ja JS on kehittynyt.
Suosittelen, että nimim. mavavilj tekee pienen aikamatkan joko syvällisellä ohjelmoinnin lähihistorian lukemisella tai varttumalla tästä vaikka 5–10 v eteenpäin, niin ehkä perspektiivi näihin palavalla innolla julistettuihin totuuksiin ja ainutlaatuisen mullistaviin ideoihin vähän muuttuu. Myös ihan ajankohtaisten teknologioiden syvällisempi opettelu voisi olla hyödyllistä, että esimerkiksi tämä kernelin, VM:n, JVM:n, standardikirjaston, muistin ym. kokonaisuus jäsentyisi paremmin.
Minusta TS on parempi kompromissi kuin Java.
Entäs sitten se, että joku sanoi joskus, että Java:n suosio perustuu mm. siihen, että sillä oli joskus huomattavasti helpompi tehdä monisäikeistetty ohjelma kuin jollain OS:n POSIX-threadeilla. Tämä liittyy siihen, että C++:n tuki oli puutteellinen.
On totta, että jos sovellus ei piittaa latensseista, niin tuolla saa helpommin jonkun max throughput -ohjelman tehtyä.
https://www.toptal.com/scala/why-should-i-learn-scala
Hyvä artikkeli, ostin.
Sovitaanko, että aina kun mainitset jonkin kielen tai teknologian, sinun pitää ohjelmoida ja esitellä pieni ohjelma sillä, ennen kuin saat mainita seuraavan. Hello world ei kelpaa, vaan jotain vähän monimutkaisempaa. Keskustelusta tulisi tosi paljon kehittävämpi.
Metabolix kirjoitti:
Keskustelusta tulisi tosi paljon kehittävämpi.
Lieköhän tämä HannuTapioLaudan sukulaisia!?
Entä Objective-C?
mavavilj kirjoitti:
Entä Objective-C?
Täällä on onneksi jo selvitetty nopein(eli paras) ohjelmointikieli:
https://www.youtube.com/watch?v=Yl9OegOorYM
Voi myös itse ajaa kaikki:
https://github.com/PlummersSoftwareLLC/Primes/
mavavilj kirjoitti:
Entä Objective-C?
Mutta onko ongelma, että Java on yleistynyt, mutta Objective-C ei, vaikka Objective-C on god-tier yhdistelmä Smalltalk:sta ja C:stä? Entä Swift?
Niin miksi näet sen ongelmallisena? Java kyllä toimii, on tuotantokelpoinen ja tekijöitäkin löytyy runsain mitoin. ja palvelinresurssit on tänäpäivänä ilmaista.
Kyse on paljolti siitä että _mitä_ tehdään. Hyvin harva nyt valitsisi C++:aa esim normaalien rest-rajapintojen kieleksi, kun mitään ultimaattista performanssia ei edes tarvita. On hyvä muistaa että joka ainut asia ei ole suinkaan nopeuskriittistä toimintaa. Ja jos nopeuskriittisyys ei ole pääasiallinen tarve, niin voidaan käyttää kieliä joilla taas toteutuksen tekee nopeammin, mitä matalamman tason kielellä sen tekemiseen (esimerksiksi juuri gc:n puuttumisen takia) menisi.
Jos tehdään näyttiksen ajureita, java tuskin on hyvä vaihtoehto. Mutta kun tehdään joku verkkopalvelu, ne spring bootin bäkkärit askartelee nopeasti ja sisältää kaiken tarvittavan vaikka kuberneteksen palveluvalvontaan ja skaalaukseen.
Minun mielestä tuossa testissä on hyvä huomata myös että lispillä on saatu 10 000 kertaa nopeampi (yksisäikeisenä) tulos kuin C:llä. Ja monisäikeisenä D:llä samaa luokkaa. Eli olisiko aika siirtyä AsFastAsC -hashtageistä AsFastAsLisp tai AsFastAsD -hashtageihin?
Voisi sanoa että jos Java on 2,5 kertaa hitaampi kuin C, niin tuohan on lähinnä pyöristysvirhe C:n ja Lispin väliseen eroon verrattuna.
groovyb kirjoitti:
(16.02.2024 11:03:18): Niin miksi näet sen ongelmallisena? Java...
Siis minun omat ongelmat on:
-"all is object" on typerä paradigma, koska se vaikeuttaa lukemista.
-GC pakollisena on typerä, koska se pakottaa luopumaan manuaalisen muistinhallinnan suorituskyvystä.
-VM on typerä, koska se tarkoittaa, että natiivin ja VM:n välillä on aina kapula, jota ei saa pois. Minusta esim. Objective-C:n toteutus on siksi järkevämpi samoihin tavoitteisiin. Eli, mikäli tavoitteena on OO-C, niin se on C:n ylijoukko. Java ei minusta näytä, että sitä on edes suunniteltu mihinkään yleiseen sovelluskehitykseen, kun sen paradigma näyttää niin paljon pelkästään business-ohjelmistoihin tarkoitetulta eli sen tavoite oli "nopea turn-around".
mavavilj kirjoitti:
-VM on typerä, koska se tarkoittaa, että natiivin ja VM:n välillä on aina kapula, jota ei saa pois. Minusta esim. Objective-C:n toteutus on siksi järkevämpi samoihin tavoitteisiin.
Siis tuo "sama tavoite" varmaankin on, että käännetty binääri/tavukoodi toimisi millä vaan alustalla prosessorista riippumatta, niin miten tuo käytännössä hoituu Objective-C:llä?
Grez kirjoitti:
(16.02.2024 11:19:46): ”– –” Siis tuo "sama tavoite" varmaankin on, että...
Käyttämällä enemmän C:tä.
mavavilj kirjoitti:
Ihanko pokkana väität että tuolla käännetty toimii suoraan natiivisti ARM:lla tai RISC-V:llä ?
Grez kirjoitti:
mavavilj kirjoitti:
Ihanko pokkana väität että tuolla käännetty toimii suoraan natiivisti ARM:lla tai RISC-V:llä ?
Myös ehkä joskus.
Grez kirjoitti:
(16.02.2024 11:19:46): ”– –” Siis tuo "sama tavoite" varmaankin on, että...
Ei vaan myös:
-On korkeampitasoinen C ja sisältää olio-ohjelmoinnin.
-Säilyttää tavan käyttää C:tä (vrt. JNI).
Minusta Java:n eräs tavoite oli olla C++:n kilpailija. Mutta minusta on ilmiselvää, että Java ei ole parempi toteutus tästä kuin Objective-C.
C++:n tapa sisällyttää C-ohjelmia on erittäin helppo käyttää, mutta C++ on kielenä työläs. Objective-C on selvästi yksi abstraktio ylöspäin olematta niin paljoa kuin Java, mutta ilmiselvästi, koska se on iOS:n kieli, niin se tavoittaa ~saman käytännön hyödyn.
No VM:ää ei varmaankaan otettu Javaan mukaan siitä syystä, mistä kuvittelet.
Grez kirjoitti:
No VM:ää ei varmaankaan otettu Javaan mukaan siitä syystä, mistä kuvittelet.
No miksi se otettiin?
mavavilj kirjoitti:
No miksi se otettiin?
Jotta sitä voitaisiin ajaa alusta ja prosessoririippumattomasti. Alunperinhän sitä ajateltiin telkkareihin ja set-top-bokseihin ja sen sellaisiin, joissa saattoi olla ties minkä arkkitehtuurin prosessoreja.
Sitten toisessa vaiheessa ne keksivät että tällainen kevyt VM voisi pyöriä nettiselaimissa. Tästä tulikin käytännössä Java Appletit.
Ja Sunillahan oli alun perin myös suunnitelmana tehdä prosessoreita, jotka ajaisivat Java tavukoodia myös natiivisti (picoJava), mutta ko. projekti kuopattiin koska ei ollut kysyntää ja aika ajoi ohi.
Grez kirjoitti:
(16.02.2024 13:40:03): ”– –” Jotta sitä voitaisiin ajaa alusta ja...
Miksi tähän tarvitaan VM?
mavavilj kirjoitti:
Miksi tähän tarvitaan VM?
Enhän minä niin sanonut.
No niin eli eikö sitten lähtökohtaisesti JVM ole ihan turha.
-> Kotlin
-> Scala
-> ...
mavavilj kirjoitti:
No niin eli eikö sitten lähtökohtaisesti JVM ole ihan turha.
No joo vähän niin kuin esim. C on lähtökohtaisesti ihan turha.
Grez kirjoitti:
mavavilj kirjoitti:
No niin eli eikö sitten lähtökohtaisesti JVM ole ihan turha.
No joo vähän niin kuin esim. C on lähtökohtaisesti ihan turha.
Minusta C on objektiivisesti hyödyllisempi abstraktio kuin assembly.
No mutta onhan meillä muitakin tapoja tuottaa ohjelmia kuin C, joten se on lähtökohtaisesti ihan turha.
Metabolix kirjoitti:
Kun miettii esim. projektien kielivalintoja, on syytä huomata, että myös C++ on viime versioissa kehittynyt merkittävästi.
Niin tosiaan. C++11 oli toisena "most loved" -teknologia: https://insights.stackoverflow.com/survey/2015
Monet ovat myös sanoneet, että kyseessä on eri kieli kuin < C++11. Ergonomia on minustakin jo enemmän jotain C#/Java/Python suuntaan.
Grez kirjoitti:
mavavilj kirjoitti:
No miksi se otettiin?
Jotta sitä voitaisiin ajaa alusta ja prosessoririippumattomasti. Alunperinhän sitä ajateltiin telkkareihin ja set-top-bokseihin ja sen sellaisiin, joissa saattoi olla ties minkä arkkitehtuurin prosessoreja.
Eli abstraktio mediastreamaukseen?
Siihen se varmaan sopiikin, mutta jo esim. peliohjelmointi Java:lla on epäeleganttia.
mavavilj kirjoitti:
Eli [JVM oli] abstraktio mediastreamaukseen?
No ei, vaan JVM on vakioitu suoritusympäristö, jossa sama käännetty ohjelma toimii kaikenlaisilla laitteilla eikä ohjelman tekijän tarvitse tuntea niitä laitteita tai tehdä mitään niiden tukemiseksi. Ohjelman tekijän pitää vain tehdä JVM:ssä toimiva ohjelma. Laitteen ylläpitäjän pitää tuottaa toimiva JVM ja muutamat järjestelmästä riippuvat luokat, ja laitteelle on sitten olemassa koko joukko valmiita ohjelmia.
Edellä ehdotit fat binary -lähestymistapaa, mutta siinä on kuitenkin ohjelman tekijän vastuulla kääntää fat binary kaikille alustoille ja päivittää sitä, jos jonkin alustan osalta löytyy bugi tai tarvitsee lisätä uusi alusta. JVM-ratkaisussa mahdolliset järjestelmäkohtaiset bugit korjataan päivittämällä JVM ja uudet alustat lisätään tekemällä niille JVM, ja ohjelman levittäjän ei tarvitse välittää asiasta vaan vanhatkin ohjelmat hyötyvät suoraan.
mavavilj kirjoitti:
Esim. peliohjelmointi Java:lla on epäeleganttia.
Tämä ongelma ei liity taas suoranaisesti JVM:ään vaan Javaan ja sen kirjastoihin. Eli koeta nyt päättää, mistä asiasta valitat.
Metabolix kirjoitti:
(18.02.2024 11:09:55): ”– –” No ei, vaan JVM on vakioitu...
https://justine.lol/cosmopolitan/howfat.html
Ei kun minusta peleissä on muitakin kuin objekteja. Esim. laajoja tilamuuttujia.
mavavilj kirjoitti:
Metabolix kirjoitti:
(18.02.2024 11:09:55): ”– –” No ei, vaan JVM on vakioitu...
https://justine.lol/cosmopolitan/howfat.html
Ei kun minusta peleissä on muitakin kuin objekteja. Esim. laajoja tilamuuttujia.
Mikä on laaja tilamuuttuja? Mikäli sinua häiritsee esimerkiksi globaalien muuttujien puuttuminen, niin voit aina tehdä "globals" luokan mihin tunget nuo muuttujasi.
jalski kirjoitti:
(18.02.2024 12:19:41): ”– –” Mikä on laaja tilamuuttuja? Mikäli sinua...
Tätä tarkoitan, pitää kirjoittaa lisää syntaksia sopiakseen "all is object"-vankilaan.
mavavilj kirjoitti:
jalski kirjoitti:
(18.02.2024 12:19:41): ”– –” Mikä on laaja tilamuuttuja? Mikäli sinua...
Tätä tarkoitan, pitää kirjoittaa lisää syntaksia sopiakseen "all is object"-vankilaan.
Jotkut pitävät globaalien muuttujien puuttumista hyvänä asiana. Jotkut myös ovat sitä mieltä, että tuo isompi määrä syntaksia tuo lisää luettavuutta. Kaikkia ei voi ikinä miellyttää.
Itse ohjelmoin nykyään 8th:lla jossa on minimaalinen syntaksi, mikä tietysti vaatii hieman kurinalaisuutta mikäli haluaa pitää koodin luettavana.
Alla esimerkkikoodi, minkä toiminnallisuuden voit koittaa saada lyhyemmin kirjoitettua käyttämälläsi ohjelmointikielellä säilyttäen silti luettavuuden:
needs net/http
needs array/parallel
"https://hacker-news.firebaseio.com/v0/topstories.json" constant STORIES_URL
"https://hacker-news.firebaseio.com/v0/item/" constant ITEM_URL_BASE
16 constant NUMTASKS
: get-ids \ -- a
STORIES_URL net:get if
nip json>
else
drop "Error retrieving data" throw
then ;
: item \ n -- s | null
ITEM_URL_BASE "%s%d.json" s:strfmt net:get if
nip json> null? if
"Failed get." log
else
"title" m:_@
then
else
"Error retrieving data." log
then ;
: get-top-stories \ a -- a'
' item NUMTASKS a:map-par ;
: print-top-stories \ a --
( "*Error: failed get*" ?: . "\n" . ) a:each! drop ;
: app:main
"Trying to fetch the 'Hacker News' top stories...\n\n" .
get-ids get-top-stories print-top-stories ;mavavilj kirjoitti:
Linkkisi ei liittynyt asiaan taas millään tavalla. Tuolla käsitellään tiedoston kokoa, ei mainitsemiani kääntämiseen ja ylläpitoon liittyviä ongelmia. Lisäksi jos luet tuolta vähän lisää, saatat huomata, että koko systeemi sopii vain yksinkertaisten tekstipohjaisten ohjelmien tekoon eikä esimerkiksi graafiseen käyttöliittymään. Eli kun nyt itsekin valitit peliohjelmoinnin vaikeuksista, niin tuo ei ole ainakaan siihen ratkaisu. Projektin sivujen mukaan myös tiedostojen ajamisessa on ongelmia alkaen siitä, että ilman lisäjärjestelyjä Linuxissa ne melko todennäköisesti tunnistetaan Windows-ohjelmiksi ja ajetaan Winellä.
mavavilj kirjoitti:
Ei kun minusta peleissä on muitakin kuin objekteja. Esim. laajoja tilamuuttujia.
Mikä on sellainen "laaja tilamuuttuja", joka ei ole objekti? Ja jos nyt sekoitit asiaan jotenkin globaalit muuttujat, niin niihin ei laajaa tilaa kannata tallentaa missään laajassa ohjelmassa. "Laajat tilamuuttujat" olisi ihan erityisen järkevää sijoittaa johonkin käynnissä olevaa peliä kuvaavaan olioon, jossa niiden omistaja on selvää ja ne on luontevaa nollata aina uuden pelin alussa.
Metabolix kirjoitti:
(18.02.2024 15:07:24): ”– –” Linkkisi ei liittynyt asiaan taas millään...
Sellainen, mihin käytetään yleensä paljon globaaleja tai struct:ia. Objekti avaa heti kysymyksen metodeista, joita ei tarvita. Eli niiden laittaminen objektiin on järjenvastaista, koska C-termein class ei ole abstraktio samaan asiaan kuin struct. En oikeasti tiedä peleistä kauheasti, mutta numeerinen Java-koodi on hirveän monisanaista verrattuna samaan C:llä ja vaikeuttaa koko algoritmin ymmärtämistä. Ja erityisesti, _se ei lisää oikeasti mitään C-koodiin verrattuna_.
Itse pidän cosmopolitan:ia lupaavana samaan ongelmaan kuin Java.
Metabolix kirjoitti:
mavavilj kirjoitti:
Linkkisi ei liittynyt asiaan taas millään tavalla. Tuolla käsitellään tiedoston kokoa, ei mainitsemiani kääntämiseen ja ylläpitoon liittyviä ongelmia.
No jaa, mutta siellä sanotaan, että se vie cosmopolitan:lla vain 12kb, joten kuinka paljon tuohon mahtuu?
Lisäksi siellä on linkki:
Osaatko sanoa, mikä vie 12kb? Vastaus löytyy tuolta sivulta, mutta viestisi antaa ymmärtää, että et ole ehkä edes lukenut tai ymmärtänyt asiaa.
Metabolix kirjoitti:
Osaatko sanoa, mikä vie 12kb? Vastaus löytyy tuolta sivulta, mutta viestisi antaa ymmärtää, että et ole ehkä edes lukenut tai ymmärtänyt asiaa.
Mutta eikös tuo implikoi, että kaikki muu on OS:n puolelta? Ja että:
"why the portability benefits Cosmopolitan provides have negligible performance impact"
En ymmärrä, miten joku VM-provideri on sen parempi provideri kuin OS-providerikaan?
Mitä sitten, jos OS-provideri on esim. Canonical tai Red Hat?
mavavilj kirjoitti:
Sellainen, mihin käytetään yleensä paljon globaaleja tai struct:ia.
Mihin perustat ajatuksen, että "yleensä" käytettäisiin paljon globaaleja nykyään enää yhtään mihinkään?
mavavilj kirjoitti:
Objekti avaa heti kysymyksen metodeista, joita ei tarvita.
Objektissa ei ole mikään pakko olla metodeja. Kannattaa pyrkiä joustavampaan ajatteluun, niin on vapaammat kädet ohjelmoida eikä tarvitse väitellä turhasta.
mavavilj kirjoitti:
Itse pidän cosmopolitan:ia lupaavana samaan ongelmaan kuin Java.
En käsitä, miten niitä voi edes erehtyä vertaamaan toisiinsa.
mavavilj kirjoitti:
Metabolix kirjoitti:
Osaatko sanoa, mikä vie 12kb? Vastaus löytyy tuolta sivulta, mutta viestisi antaa ymmärtää, että et ole ehkä edes lukenut tai ymmärtänyt asiaa.
Mutta eikös tuo implikoi, että kaikki muu on OS:n puolelta?
Siis mikä nyt olisi OS:n puolella? Saitko selville, mitä kaikkea se 12kb ohjelma kykenee tekemään, vai väistitkö liian vaikean kysymyksen? Jos et edes ota selvää niistä tekniikoista ja projekteista, joista lähdet niin itsevarmasti väittelemään, on kyllä ihan turha jatkaa tätä keskustelua.
Kokeile nyt kääntää vaikka se kysymäsi C-serveri tuolla Cosmopolitanilla ja kerro, miten kävi, toimiiko Windowsissa ja Macissa.
Ja siis jotkin käyttäjät eivät pidä Windows- ja Mac-yhteensopivuutta edes tavoiteltavana. Vaan näiden vendorien ongelmana.
OS tarjoaa siis koko infran WORA:ä varten.
Olet yksinkertaisesti väärässä. Käyttöjärjestelmä ei tarjoa "write once, run anywhere" -infraa, puhumattakaan compile once, josta tässä nyt selvästi puhutaan. Tästä selvä osoitus on jo se purkkapallon määrä, jonka Cosmopolitan tarvitsee, jotta ohjelma edes käynnistyy. Se, että tämä purkka mahtuu 12 kilotavuun, ei ole yllättävää eikä osoita muuta kuin sen, että tekijä on ollut aika kekseliäs ja että pelkän käynnistyksen osalta kyse on pitkälti tiedoston muodosta eikä suurista kooditarpeista.
Cosmopolitan toteuttaa jonkinlaisen staattisesti linkitettävän standardikirjaston, jossa paikkaillaan aukkoja juuri ja juuri sen verran, että alkeellisimmat perusasiat kuten muistin varaaminen, tiedostojen käsittely ja sokettien käsittely toimivat. Jos nämä riittävät niin kiva juttu. Usein eivät riitä. Esimerkkiohjelman pieni koko selittyy sillä, että siinä ei käytetä näitä ominaisuuksia ja staattinen linkitys karsii kirjaston käyttämättömät osat pois. Kyllä se binääri siitä kasvaa, kun eri ominaisuuksia otetaan mukaan.
Jos Windows tuntuu epärelevantilta alustalta, kannattaisi tämä kertoa ja määritellä selkeät speksit jo keskustelun alussa ennen kuin alkaa puhua mistään WORA:sta. Lisäksi pelkkä x86-64 ja/tai ARM64 ei tuota läheskään "run anywhere" -tilannetta edes raudan osalta.
Ehkä sinulle WORA tarkoittikin "write once, run anywhere on x86-64 Linux". Hassusti vain Linux-jakelujen erojen takia edes tämä ei ihan aina toteudu (tai ainakaan compile once).
Linuxien epäyhteensopivuus on osa ongelmaa, kuten on myös Mac:n ja Windows:n sulkeutuneisuus POSIX:ia kohden. On ilmiselvää, että suljetut käyttöjärjestelmät eivät välitä cross-plattasta. Kertoohan se jo gcc-tukikin.
Voi myös olla tyytyväinen, jos saa crossplataksi osan koodista, esim. 30-50%.
Nyt ymmärrän kuitenkin Java-VM:n lähestymistavan portabilityyn paremmin. En vain ole samaa mieltä siitä, että se on jotenkin optimaalinen, vaan miksei sekin ole kasa purkkaa?
Cosmopolitan voi olla herkullinen alusta, sitten kun ottaa huomioon C API -tukien määrän eri FFI:issa.
Siis Windows on epäyhteensopiva cross-platform tavoitteiden suhteen, koska se ei luonnollisesti halua tukea niitä. Sehän veisi heiltä asiakkaita pois.
Metabolix kirjoitti:
Kokeile nyt kääntää vaikka se kysymäsi C-serveri tuolla Cosmopolitanilla ja kerro, miten kävi, toimiiko Windowsissa ja Macissa.
Niin oliko tuo se käyttämäsi vai halusitko vain kertoa, että joku on tehnyt tällaisen? Tietysti hauska sattuma, jos tuo olisi juuri se, jota käytit.
mavavilj kirjoitti:
Nyt ymmärrän kuitenkin Java-VM:n lähestymistavan portabilityyn paremmin. En vain ole samaa mieltä siitä, että se on jotenkin optimaalinen, vaan miksei sekin ole kasa purkkaa?
JVM on ihan tavallinen ohjelma, joka lukee ja suorittaa virtuaalikoneessa hyvin määritellyn muotoisia tiedostoja. Vaikka henkilökohtaisesti et tykkäisi ideasta, mitään purkkaa tässä ei ole. Optimaalisuus on sitten asia erikseen ja sitä on turha sotkea samaan keskusteluun.
Cosmopolitanin APE on käsin tarkasti viritelty tiedosto, joka näyttää samaan aikaan usealta eri tiedostotyypiltä ja jonka suoritus alkaa eri käyttöjärjestelmillä eri kohdista. Jokainen järjestelmä lukee siitä vain tiettyjä osia, muut osat ovat niille tuntemattomia ja hädin tuskin sallituissa rajoissa. On ylipäänsä sattumaa, että tällaisen tiedoston pystyy suunnittelemaan. Jos tiedostoa muuttaa yhden järjestelmän kannalta aivan sallitusti, se todennäköisesti ei enää toimi muilla. Kuten jo suomensin sinulle projektin omilta nettisivuilta, Linux saattaa käynnistää APE-ohjelman Winellä Windows-ohjelmana, koska se näyttää enemmän Windows-ohjelmalta kuin Linux-ohjelmalta, vaikka kuitenkin Linux olisi sen parhaiten tuettu ajoympäristö. Kyllä juuri tällaista voi ohjelmointislangilla nimittää purkkaviritykseksi.
Metabolix kirjoitti:
Niin oliko tuo se käyttämäsi vai halusitko vain kertoa, että joku on tehnyt tällaisen? Tietysti hauska sattuma, jos tuo olisi juuri se, jota käytit.
No siis tietenkään emme oleta, että kaikki aiemmat ohjelmat ovat välttämättä tuohon sopivaa. Joitain on kuitenkin portattu kuten SQLite.
Miksi C ei ole hyvin määritely?
mavavilj kirjoitti:
Miksi C ei ole hyvin määritely?
Mainitsinko C:tä? Onko APE-tiedosto tehty C:llä?
mavavilj kirjoitti:
No siis tietenkään emme oleta, että kaikki aiemmat ohjelmat ovat välttämättä tuohon sopivaa.
On kyllä tosi surkea ehdotus uudeksi yhteensopivuusstandardiksi, että kaikki ohjelmat joutuu porttaamaan äärimmäisen rajattuun ympäristöön ja sittenkin käynnistyminen vaatii tuuria tai kikkailua.
Metabolix kirjoitti:
(20.02.2024 07:33:23): ”– –” On kyllä tosi surkea ehdotus uudeksi...
Niin toimii staattinen JS:kin (Microsoft STS). Varmaan kaikki olisi hyvin, jos olisi alusta asti tehty hyvä tuote. Tässä tapauksessa siis kunnioitettu POSIX-standardeja.
Metabolix kirjoitti:
mavavilj kirjoitti:
Miksi C ei ole hyvin määritely?
Mainitsinko C:tä? Onko APE-tiedosto tehty C:llä?
Ei mutta se kääntyy cross-platform C-kirjastosta, joten tiedoston muoto on vain neuvottelukysymys.
https://justine.lol/cosmopolitan/functions.html
Tästä chart:sta tosiaan pitäisi nähdä, että ongelma ei ole kirjasto, vaan se, että MacOS ja erityisesti Microsoft Windows ovat laiskempia seuraamaan POSIX-standardia.
mavavilj kirjoitti:
Ei mutta se kääntyy cross-platform C-kirjastosta, joten tiedoston muoto on vain neuvottelukysymys.
Voi jestas. Millä tavalla tiedostomuoto on neuvottelukysymys? Se on tuon projektin isoin juttu, että saman tiedoston voi (yrittää) ajaa eri järjestelmillä. Jos ei sitä ominaisuutta kaipaa, ei ole juuri mitään syytä käyttää tuota kirjastoa.
Metabolix kirjoitti:
(20.02.2024 11:55:10): ”– –” Voi jestas. Millä tavalla tiedostomuoto on...
No siis miksi ei voisi tuottaa executable:n myös kullekin alustalle erikseen?
Tai konffata OS:t siten, että ne osaa käsitellä tuota.
Jos kääntää kuitenkin ohjelman joka järjestelmälle, miksi ei voisi sitten kirjoittaa sitä vaikka kunnon C++:lla? Miksi kiusaisi itseään käyttämällä tuollaista puolivalmista POSIX-yhteensopivuusrajapintaa?
Metabolix kirjoitti:
Jos kääntää kuitenkin ohjelman joka järjestelmälle, miksi ei voisi sitten kirjoittaa sitä vaikka kunnon C++:lla? Miksi kiusaisi itseään käyttämällä tuollaista puolivalmista POSIX-yhteensopivuusrajapintaa?
Koska siitä saa stable API:n vaikka jollekin Haskell:ille.
C++:lla voi kirjoittaa hour glass -pattern:n:
Nojoo, myönnetään, että mikäli cross-platform on oleellista ja JVM:n rajat eivät haittaa, niin onhan JVM:llä helpompi tuottaa ohjelmia kuin C++:lla. Pitäisi vaan olla järkevämpi kieli kuin Java. Minusta POSIX ratkaisee lopulta kuitenkin saman ongelman.
What prevents Java from achieving C-level portability?
Python?
a karppinen kirjoitti:
Python?
No, huonot puolet:
dynaaminen
hidas
ei curly bracket:eja (helpottavat parserointia)
Käytännössä osa ihmisistä on kuitenkin siirtänyt Java-kehitystä Python:iin. Tämä ei tarkoita, että Python on hyvä, mutta se on ehkä ollut saatavilla olevista alustoista vähiten huono.
mavavilj kirjoitti:
a karppinen kirjoitti:
Python?
No, huonot puolet:
dynaaminen
hidas
ei curly bracket:eja
Itse en kyllä 'curly bracket:eja' koodin luettavuuden kannalta laskisi hyviin puoliin... Tosin hyvä IDE helpottaa tuskaa.
mavavilj kirjoitti:
Nojoo, myönnetään, että mikäli cross-platform on oleellista ja JVM:n rajat eivät haittaa, niin onhan JVM:llä helpompi tuottaa ohjelmia kuin C++:lla. Pitäisi vaan olla järkevämpi kieli kuin Java. Minusta POSIX ratkaisee lopulta kuitenkin saman ongelman.
Niin, siis JVM:nkin voi mieltää purkaksi, koska se menee olemassaolevien asioiden päälle, missä mahdollisuus olisi myös muuntaa olemassaolevia asioita tai tukea asioita sinänsä. Eli se on tosiasiassa emulaatio-layer, joka ei sinänsä voi myöskään hyödyntää rautaa täydellisesti.
Mites edesmennyt XUL tai HTML5?
Olet melko pitkän ketjun saanut aikaan. Täytyypä joskus lukea kokonaan läpi. :) Ohjelmointikielten vertailu on kivaa kieltämättä. Entisen MOL:n (nykyinen TE) sivuilta varmaan selviää, mistä kielestä eniten kysyntää. Tiedän kokemuksesta vanhoja jääriä, jotka eivät suostu koodaamaan kuin C/C++, mutta tässä lienee enemmän kysymys uudelleen opettelun hitaudesta. Noilla kielillä kyllä pärjää monissa sulautettujen järjestelmien projekteissa, joissa varsinaista C:tä on vaikea syrjäyttää. Itseäni nykyään enemmän viehättää ohjelmoinnin helppous korkeamman tason kielillä, joilla ei tarvitse kirjoittaa tuhatta riviä koodia saadakseen jonkin yksinkertaisen asian toimimaan.
C++:lla oli C++/CLI. Joten rajapintaan oli kysyntää. Se ei vaan ole yleistynyt.
mavavilj kirjoitti:
Mites edesmennyt XUL tai HTML5?
Niin tosiaan, UI:t ovat ainakin 2D tapauksessa yksisäikeisiä:
http://stackoverflow.com/questions/5544447/ddg#5544714
Jos taas tehdään 3D, niin miksei canvas tai OpenGL suoraan.
Myös JS:n ctypes on mielenkiintoinen rajapinta.
mpni kirjoitti:
Olet melko pitkän ketjun saanut aikaan. Täytyypä joskus lukea kokonaan läpi. :) Ohjelmointikielten vertailu on kivaa kieltämättä. Entisen MOL:n (nykyinen TE) sivuilta varmaan selviää, mistä kielestä eniten kysyntää.
Siis frontend:iä on eniten. Myös siksi Java on ihan menneitä lumia.
mavavilj kirjoitti:
Siis frontend:iä on eniten. Myös siksi Java on ihan menneitä lumia.
Ja tarjoat ratkaisuksi 36 - 52 vuotta vanhoja ratkaisuja kuten C, C++ ja POSIX? Kannattaisikohan keskittyä ohjelmoimaan eikä yrittämään ratkaista olematonta ongelmaa?
jalski kirjoitti:
mavavilj kirjoitti:
Siis frontend:iä on eniten. Myös siksi Java on ihan menneitä lumia.
Ja tarjoat ratkaisuksi 36 - 52 vuotta vanhoja ratkaisuja kuten C, C++ ja POSIX? Kannattaisikohan keskittyä ohjelmoimaan eikä yrittämään ratkaista olematonta ongelmaa?
Siis frontend:n ongelma on suorituskyky vaativiin sovelluksiin, ja osin dynaamiset, vaikeasti ylläpidettävät kielet.
jalski kirjoitti:
mavavilj kirjoitti:
Siis frontend:iä on eniten. Myös siksi Java on ihan menneitä lumia.
Ja tarjoat ratkaisuksi 36 - 52 vuotta vanhoja ratkaisuja kuten C, C++ ja POSIX? Kannattaisikohan keskittyä ohjelmoimaan eikä yrittämään ratkaista olematonta ongelmaa?
Lisäksi uskon, että POSIX on sinänsä hyvä, mutta ongelma on, että teollisuus ei ole seurannut sitä. Vastaavia esimerkkejä aiemmin olleista hyvistä, mutta sivuutetuista ideoista on.
POSIX oli kuitenkin myös lain vaatima rajapinta USA:ssa.
No joo. Kotlin on ihan kiva rajapinnoissa, jotka toimivat riittävän hyvin JVM-alustalla. Vähemmän mutantoitunut objektisysteemi.
mavavilj kirjoitti:
POSIX oli kuitenkin myös lain vaatima rajapinta USA:ssa.
Toisaalta Valkoinen talo kehottaa lopettamaan C- ja C++ -koodaamisen
Grez kirjoitti:
mavavilj kirjoitti:
POSIX oli kuitenkin myös lain vaatima rajapinta USA:ssa.
Toisaalta Valkoinen talo kehottaa lopettamaan C- ja C++ -koodaamisen
Valkoinen talo ei taida tietää, että korvaaminen ei ole mahdollista legacy:n määrän takia. Sitä paitsi POSIX:nhan saa aikaan muuallakin.
Python olisi ihan hyvä kieli, jos se olisi yhtä nopea kuin Java ja staattisesti tyypitetty. On siinä tietty arvo, että "monimutkaista" konetta voi ohjata vaivattomasti kuin luonnollinen kieli. Mutta kun tämä tapahtuu siten, että ajo tapahtuu 30x hitaammin, niin tämä ei ole hyödyllistä.
mavavilj kirjoitti:
Python olisi ihan hyvä kieli, jos se olisi yhtä nopea kuin Java ja staattisesti tyypitetty. On siinä tietty arvo, että "monimutkaista" konetta voi ohjata vaivattomasti kuin luonnollinen kieli. Mutta kun tämä tapahtuu siten, että ajo tapahtuu 30x hitaammin, niin tämä ei ole hyödyllistä.
Ei ohjelmointikielen ainoa arvo ole, että se toimii todella nopeasti, vaan yleensä riittää, että ohjelma toimii riittävän nopeasti.
Lisäksi mielestäni on järkevää optimoida vain ne toiminnot, jotka ovat aikakriittisiä tai jossa nopeudesta saadaan jotain muuta (mahdollisesti rahanarvoista) etua.
On myös usein tärkeää, että ohjelman ominaisuudet toteutetaan nopeasti, ennemmin kuin, että ohjelma itsessään olisi nopea.
Siis kyllä talo saadaan aikaiseksi nauloista, lankuista ja muista nippeleistä, mutta joskus on järkevää luoda talo halvemmalla tavalla esimerkiksi elementeistä.
Olen eri mieltä, koska ohjelmointikielen valinta vaikuttaa suoraan tietokoneen tehonkulutukseen. Kun sama ohjelma pyöriikin miljoonassa tai sadassa miljoonassa tietokoneessa, niin se, että toinen toteutus vie 1/75 tai 1/37.5 sähköstä on aika iso luku. https://storage.googleapis.com/cdn.thenewstack.
Myös se, että mitä muuta koneella voi tehdä samanaikaisesti ilman, että muisti loppuu yms. Jos jonkin serverin toteuttaisi Python:lla niin sehän olisi hirveää resurssien tuhlausta, kun jokainen client maksaa hirveästi hukkatehoja.
Ainakin omien testailujen perusteella javalla ja pythonilla ei ole mitään merkittävää eroa suoritusnopeudessa, muistia java hörppää äkkiä huomattavasti enemmän kuin python.
a karppinen kirjoitti:
Ainakin omien testailujen perusteella javalla ja pythonilla ei ole mitään merkittävää eroa suoritusnopeudessa, muistia java hörppää äkkiä huomattavasti enemmän kuin python.
No sitten et ole kauheasti tainnut testailla, koska Java on keskimäärin melkein 30x suorituskykyisempi teknologia. Jossain rajoitetussa GUI-ohjelmassa ero voi olla havaitsematon, koska GUI:n saa helposti pyörimään 60 fps.
mavavilj kirjoitti:
Olen eri mieltä, koska ohjelmointikielen valinta vaikuttaa suoraan tietokoneen tehonkulutukseen. Kun sama ohjelma pyöriikin miljoonassa tai sadassa miljoonassa tietokoneessa, niin se, että toinen toteutus vie 1/75 tai 1/37.5 sähköstä on aika iso luku.
Itselläni ei ole päivittäin tapana tehdä ohjelmia, jotka pyörivät miljoonassa tai sadassa miljoonassa tietokoneessa, jolloin sähkön kulutuksessa pienempi toteutusaika on tärkeämpi kuin sen ajoaika.
Sinä ilmeisesti teet päivittäin ohjelmia, jotka pyörivät miljoonissa koneissa, sillä ethän muutoin viitsisi paasata siitä niin suuresti ?
peran kirjoitti:
(14.03.2024 17:02:19): ”– –” Itselläni ei ole päivittäin tapana tehdä...
No siis sehän päätyy niille koneille, jos jaat ohjelmasi.
Oma 8th:lla kirjoiteltu monisäikeinen kotiautomaation ohjaussoftani pyörii keskimäärin vajaan prosentin prosessorikuormalla vanhalla Rasberry Pi 3B pohjaisella ratkaisulla. Luuletko, että saavuttaisin jotain etua kirjoittamalla ohjelman uusiksi esimerkiksi C++:lla? Pointti on se, että harva ohjelma pelejä ja raakaa laskentaa lukuun ottamatta vaatii älytöntä määrää resursseja toimiakseen.
jalski +1
Juuri tätä tarkoitin.
jalski kirjoitti:
(14.03.2024 17:20:37): Oma 8th:lla kirjoiteltu monisäikeinen...
No tuo on varmaan syy Androidin Java-preferenssiinkin. C++ tuottaisi suurimmalle osalle käyttäjistä lisää työtä ja ei mitään etuja.
Tuo on ihan validi use case kyllä. Mikäli suorituskykyero jää merkityksettömän pieneksi, ja muitakaan etuja ei tarvita, kuten staattinen tyypitys. Tämä ei ole kuitenkaan se, mikä tekee teknologioista huonoja, vaan huonoja tekee, kun ne käytetään asioihin, joihin olisi parempi vaihtoehto.
Mutta Python on vähän eri asia muutenkin, koska se on referenssitoteutuksessa käytännössä wrapperi C:lle toisin kuin Java. Toisin sanoen, toteutus myös on olemassa C:llä, ennen Python:ia, joka vaan wrappaa C:n.
Ja tuossa Python:n tapauksessa järkevä uudelleenkäyttö nimenomaan toteutuu, koska siinä on aina C API. Jos mukaan sotkee C++:aa, niin sitten menee vaikeammaksi, koska pybind11 ei toteuta kaikkea.
Voisikohan Java:an tehdä wrapperin, joka edes muuttaisi sen syntaksin samaksi kuin C++ niiltä osin kuin toiminnallisuus on sama tai lähes sama? Eli esim. std::vector, eikä Vector.
Olisi kätevämpää käyttää samaa syntaksia kuin aina toista.
Toisaalta, koska JNI antaa jo käyttää C++:aa, niin ehkä tämmöinen wrapperi on jokseenkin turha. Eli voisi yhtä hyvin wrapata Java:n C++:aan JNI:llä.
mavavilj kirjoitti:
Voisikohan Javaa:n tehdä wrapperin, joka edes muuttaisi sen syntaksin samaksi kuin C++ niiltä osin kuin toiminnallisuus on sama tai lähes sama? Eli esim. std::vector, eikä Vector.
Olisi kätevämpää käyttää samaa syntaksia kuin aina toista.
Mielestäni turha tehdä asioita vaikeammaksi kuin on tarpeellista. Helpompaa vaan käyttää sitä Javaa mikäli tarvetta on eikä säätää turhaan. Itse käytän 8th:n lisäksi Fortran ja PL/I ohjelmointikieliä. En ole pitänyt ohjelmointikielestä toiseen vaihtamista suurena ponnistuksena.
On tuollaisia wrappeja kyllä tehty muitakin. Esim. lukemattomat vaihtoehtokielet, jotka transpiletään JavaScript:lle.
