Vihatuimmat ohjelmointikielet

[user1435]

Stack Overflow julkaisi eilen blogipostauksen, jossa esiteltiin sivuston käyttäjiltä kerättyä tietoa vihatuimmista ohjelmointikielistä. Ei mitenkään yllätä että mm. Perl ja PHP ovat vihatuimpien joukossa.

What are the Most Disliked Programming Languages? - Stack Overflow Blog

Mitkä ovat tekkiläisten vihatuimmat ja toisaalta taas pidetyimmät kielet/teknologiat?

Edit: väärä kuva

 

[Xtremerr]

Itseasiassa tuolla PHP:eellä tulee eniten koodailtua tällä hetkellä vaikka satunnaisesti koodailenkin Javaa ja C#. Vaikka tuo PHP onkin vähän sekava kieli niin kyllä sillä jotain pientä saa aikaan vaikkei se olekaan raskaita sovelluksia varten. Sellaisia vanhentuneita kieliä vihaan jota pitää kirjoittaa pitkä pätkä että saa jotain aikaan

 

[Xiyng]

Mitenkäs Delphi on noin vihattu? Käytetäänkö sitä tosiaan niin paljon, että vihaajiakin riittää noin runsaasti vai vihaavatko kaikki vähätkin käyttäjät sitä niin syvästi, että se näkyy tilastoissa noin voimakkaasti?

Omalla kohdalla JavaScript on varmaan se suurin inhokki. Kieli itsessään tekee virheiden tekemisestä aivan liian helppoa, minkä lisäksi siihen vieläpä törmää jatkuvasti helposti ymmärrettävistä syistä. Tosin en pidä dynaamisesti tyypitetyistä kielistä juuri ollenkaan, ja lisäksi C ja C++ ansaitsevat "kunniamaininnan" yleisesti huonon käännösprosessin vuoksi ja C vieläpä senkin lisäksi vapaasti määriteltävien nimiavaruuksien puuttumisen takia. Javaa taas voisi moittia siitä, miten kangistunut kieli se on vaikken muilta osin pidäkään sitä sinänsä huonona. Kaikissa muissakin kielissä on varmaan jotain valittamista, mutta tässä ehkä ne isoimmat.

 

[AION]

Kyllä omasta mielestä PHP on tuolla ja ihan syystäkin. Sillä voi toki tehdä asioita oikeinkin mutta useimmiten kun näkee sitä käytettynä niin asiat on tehty päin helvettiä ja kieli tekee siitä aivan liian helppoa ja tavallaan jopa antaa siihen mallia kun iso osa coren funktioistakin on täysin inconsistentteja.

JS oli ennen sama juttu. Nykyään kun tehdään modernia JS:ää niin meno on onneksi vähän parempi. Moderni JS kärsii enemmänkin vain tosta dependency management / micro library ongelmasta.

 

[aleksejjj]

C#, Java ja C++ on aika korkealla tuolla listalla. Miksi näin?

 

[Technocrat]

Mielenkiintoista, että r on vähiten vihattu, omasta mielestäni se on aivan hirveää kuraa. Toki esim tuon vihatuimman perlin tilalle kuuluisi mielestäni PHP jne.

Makuasioita nämä.

 

[AION]

C#, Java ja C++ on aika korkealla tuolla listalla. Miksi näin?

Koska olioohjelmointi on hidasta ja raskasta wäääähhhhhhh. Koska funktionaalinen ohjemointi on niin siistiä ja first class citizen funktioiden passaus parametreinä ja return arvoina on niiiiiiiin siiiistiiii!



Ei vaan, aika moni aloitteleva (tai hipster) ohjelmoija taas huutaa ton fuktionaalisen ohjelmoinnin perään ja selittää, että olio-ohjelmoinnista ei ole mitään hyötyä. Mitä itse olen tässä kohta 10 vuotta paukuttanut koodia duunikseni niin voin sanoa, että jos ei olio-ohjelmoinnista ole hyötyä niin kannattaa vaihtaa alaa. Jos ei pysty suunnittelemaan järkevää luokkahierarkiaa niin syy on koodarissa eikä kielessä.

 

[Xiyng]

Koska olioohjelmointi on hidasta ja raskasta wäääähhhhhhh. Koska funktionaalinen ohjemointi on niin siistiä ja first class citizen funktioiden passaus parametreinä ja return arvoina on niiiiiiiin siiiistiiii!

Huomaa toki, että CoffeeScript ja Haskell ovat listalla aika korkealla, ja olio-ohjelmointia edustavat JavaScript ja Python aika alhaalla.

Ei vaan, aika moni aloitteleva (tai hipster) ohjelmoija taas huutaa ton fuktionaalisen ohjelmoinnin perään ja selittää, että olio-ohjelmoinnista ei ole mitään hyötyä. Mitä itse olen tässä kohta 10 vuotta paukuttanut koodia duunikseni niin voin sanoa, että jos ei olio-ohjelmoinnista ole hyötyä niin kannattaa vaihtaa alaa. Jos ei pysty suunnittelemaan järkevää luokkahierarkiaa niin syy on koodarissa eikä kielessä.

Aika helppo tuo luokkahierarkia tuntuu silti olevan sössiä, joten eiköhän siinä kielessäkin ole vikaa. Missään nimessä en siis väitä, etteikö olio-ohjelmoinnista olisi hyötyä, mutta järkevän luokkahierarkian laatiminen vaikuttaa olevan yllättävän virhealtista puuhaa. Vähän sama juttu kuin että kyllähän C on hieno kieli ja on ohjelmoijan vika, jos tuleekin muistivuoto. Juu, ohjelmoijan vikahan se on, mutta kieli mahdollistaa kyseisenlaiset virheet paljon helpommin kuin monissa muissa kielissä.

 

[AION]

Huomaa toki, että CoffeeScript ja Haskell ovat listalla aika korkealla, ja olio-ohjelmointia edustavat JavaScript ja Python aika alhaalla.

Juuh, toki JS:ää voi kirjoittaa aika pitkälle funktionaalisestikin eikä ole vaatimusta kirjoittaa välttämättä luokkia ollenkaan

Aika helppo tuo luokkahierarkia tuntuu silti olevan sössiä, joten eiköhän siinä kielessäkin ole vikaa. Missään nimessä en siis väitä, etteikö olio-ohjelmoinnista olisi hyötyä, mutta järkevän luokkahierarkian laatiminen vaikuttaa olevan yllättävän virhealtista puuhaa. Vähän sama juttu kuin että kyllähän C on hieno kieli ja on ohjelmoijan vika, jos tuleekin muistivuoto. Juu, ohjelmoijan vikahan se on, mutta kieli mahdollistaa kyseisenlaiset virheet paljon helpommin kuin monissa muissa kielissä.

Noh, tää on vähän niinkuin kaksi piippuinen juttu. Se on helppo sössiä joo. Helposti tulee tehtyä liian laiha, jolloin hyödyt jäävät minimaalisiksi ja sitten taas liian lihava, jolloin se on liian raskas.
Toisaalta Javaakin kirjoittaessa pitäisi osata käyttää interfaceja, abstracteja, useampi kerroksista hierarkiaa ja sen lisäksi vielä genericsejä oikein. Usein kun katsoo kirjastoja tai projekteja niin ollaan käytetty helposti vain interfaceja ja niitä toteutettu ja sitten välillä joku luokka perii jotain toiselta mutta esimerkiksi genericsien käyttö tuntuu olevan monella hukassa. Ja sitten olen kyllä nähnyt sellaisiakin generics hirviöitä, että ne eivät edes resolvoidu loppuun ja jossain joku joutuu sen olettamaan...

Kuitenkin näen tuon luokkahierarkian enemmän "suunnittelu" kuin "toteutus" ongelmana. Eli jos se suunnitellaan kunnolla niin sitä ei sössitä. Sitten taas C:n muistivuota on enemmän "toteutus" kuin "suunnittelu" ongelma. Toki jos suunnittelee softan huonosti niin muistivuotoja on varmasti helpompi tehdä mutta harvoin yhden rivin typolla sössii luokkahierarkiaa kun taas muistivuoto on sellaisella helppo tehdä.

 

[Xiyng]

Juuh, toki JS:ää voi kirjoittaa aika pitkälle funktionaalisestikin eikä ole vaatimusta kirjoittaa välttämättä luokkia ollenkaan

Eivät luokat ole välttämättömiä olio-ohjelmoinnissa. JS:ssä melkeinpä mikä tahansa on olio.

Noh, tää on vähän niinkuin kaksi piippuinen juttu.

Toki. En minä C:täkään tosiaan mollaa muistivuotojen sun muiden helppoudesta, koska se lienee yksi parhaista työkaluista matalan tason ohjelmointiin. Korkeamman tason jutuissa se taas ei välttämättä ole parhaimmillaan. Kuhunkin tilanteeseen valitaan siihen sopivin työkalu (esim. kieli). Olio-ohjelmointi on varmaan joihinkin tarpeisiin paras paradigma, kun taas funktionaalinen ohjelmointi voi olla paras valinta joihinkin muihin tarpeisiin.

Kuitenkin näen tuon luokkahierarkian enemmän "suunnittelu" kuin "toteutus" ongelmana. Eli jos se suunnitellaan kunnolla niin sitä ei sössitä. Sitten taas C:n muistivuota on enemmän "toteutus" kuin "suunnittelu" ongelma. Toki jos suunnittelee softan huonosti niin muistivuotoja on varmasti helpompi tehdä mutta harvoin yhden rivin typolla sössii luokkahierarkiaa kun taas muistivuoto on sellaisella helppo tehdä.

Lieneekö tuo siltikään relevanttia, kummasta on kyse. Molemmat liittyvät silti kieleen. Funktionaalisissa kielissä ei tarvitse miettiä ollenkaan koko luokkahierarkiaa - kielen avulla ainakin kyseinen ongelma on kokonaan väistetty. Toki funktionaalisissakin kielissä on omat ongelmansa enkä ota kantaa siihen, tuleeko olio-ohjelmoinnin ongelmien välttämisestä kokonaisuudessaan enemmän voittoa vai tappiota.

 

[bulson]

JavaScript on omalla listalla ykkösenä jo pelkästään syntaksin (joo, TypeScript on olemassa) takia. Sillä on tosin iso vaikutus tähän, että kun ensikertaa opettelin JS:ää, se oli back in the days kun ei ollut mitään nodeja tai frameworkkeja vaan käytettiin vanillaa joka paikassa (noin hieman kärjistettynä, mutta tällöin webdev oli aika alkeellista vrt. nykypäivään).

 

[AION]

JavaScript on omalla listalla ykkösenä jo pelkästään syntaksin (joo, TypeScript on olemassa) takia. Sillä on tosin iso vaikutus tähän, että kun ensikertaa opettelin JS:ää, se oli back in the days kun ei ollut mitään nodeja tai frameworkkeja vaan käytettiin vanillaa joka paikassa (noin hieman kärjistettynä, mutta tällöin webdev oli aika alkeellista vrt. nykypäivään).

Nykyyänhän syntaksi on käytännössä täysin eri. Esim var avainsana ei juuri enää ole käytössä (for ja while loopeissa se on marginaalisesti tehokkaampi) vaan se on korvattu let ja const avainsanoilla. Sama pätee function avainsanaan joka on korvattu läski nuolella ( () => {} ). Sen lisäksi käytetään avainsanoja class, import, export jne. Myös esim perseInt on tyylikkäämpää kutsua Number.parseInt().

Sen lisäksi looppeja voi nykyään kirjoittaa for of (for each) rakenteella ja sitten on vielä spread (...) yms kivat operaattorit olemassa.

Eli nykyään puhdas JS on myös paljon luettavampaa ja nykyaikaiset työkalut antavat paljon paremman intellisensen, eli ei tarvii enää seitsemää näyttöä ja neljäätoista notepadia

 

[Xiyng]

@AION: IE:n kuolemaa odotellessa...

 

[Noddy]

Varmaankin johtuu siitä, että ne ovat vanhoja suuria teknologioita, joilla on paljon käyttäjiä.

Mutta tuohan on suhteutettuna kokonaismäärään eli alhaalla lukee # disliked / total
Muutenhan koko taulukko olisi täysin hyödytön.

 

[Yleinen Faktoidi]

Typerää puhua vihasta, kun kyse on lähinnä itseään ruokkivasta suosion puutteesta, jonka taustalla voi olla monenlaisia syitä. Esimerkiksi Delphin ongelma on ennemmin lisensoinnissa, kuin kielen puutteissa.

 

[fei]

Huomaa toki, että CoffeeScript ja Haskell ovat listalla aika korkealla, ja olio-ohjelmointia edustavat JavaScript ja Python aika alhaalla.

JavaScript on prototyyppipohjainen oliokieli. Erittäin harvoin pitää määritellä mitään luokkaa, vaan ne voi näppärästi rullata lennosta tarpeen mukaan ja sitten käsitellä sisältöä kuin olisi instantioitu objekti kyseessä.

@AION: IE:n kuolemaa odotellessa...

Babel hoitaa näppärästi ES6 -> ES5 käännöksen. Käytännössä tuosta, että tietyt selaimet ei tue uusinta versiota JavaScriptistä ei tarvitse välittää. Sen kun näpyttelee menemään.

 

[mystikkogames]

JavaScriptiin tuli kyllä päivityksiä. constructor ja muut C++maiset tohkeet unohtaisin. ()=>{} haittaa luettavuutta. jsewelissä käytän joitakin ES6 ominaisuuksia. Mutta kaikki featuret eivät olleet tarpeen. No eipä niitä tarvitse käyttää. Ainoa mikä risoo JavaScriptissä on kääntäjä, joka ei käännä kunnolla. On usein selviä mokia koodissa joka kääntyy oikein.
jsewel by mystikkogames

 

[aleksejjj]

Ainoa mikä risoo JavaScriptissä on kääntäjä, joka ei käännä kunnolla. On usein selviä mokia koodissa joka kääntyy oikein.

Mitä ne mokat sitten on?

 

[Xiyng]

JavaScript on prototyyppipohjainen oliokieli. Erittäin harvoin pitää määritellä mitään luokkaa, vaan ne voi näppärästi rullata lennosta tarpeen mukaan ja sitten käsitellä sisältöä kuin olisi instantioitu objekti kyseessä.

Niin? Olio-ohjelmointi ei edellytä luokkia vaikka monissa olio-ohjelmoinitikielissä sellaiset onkin.

Babel hoitaa näppärästi ES6 -> ES5 käännöksen. Käytännössä tuosta, että tietyt selaimet ei tue uusinta versiota JavaScriptistä ei tarvitse välittää. Sen kun näpyttelee menemään.

Mietinkin jossain välissä, onko tällaista olemassa, mutta unohtui sitten viestiä kirjoittaessa. Kiitos tiedosta siis! Tietysti vähän tympeää, että tarvitsee välissä moisen palikan, mutta minkäs teet.

 

[AION]

JavaScriptiin tuli kyllä päivityksiä. constructor ja muut C++maiset tohkeet unohtaisin. ()=>{} haittaa luettavuutta. jsewelissä käytän joitakin ES6 ominaisuuksia. Mutta kaikki featuret eivät olleet tarpeen. No eipä niitä tarvitse käyttää. Ainoa mikä risoo JavaScriptissä on kääntäjä, joka ei käännä kunnolla. On usein selviä mokia koodissa joka kääntyy oikein.
jsewel by mystikkogames

Noh Noh.

Siinä vaiheessa kun teet samat methodit sadetta kertaa nii alkaa ne luokatkin tuntumaan ihan fiksuilta. On se kuitenkin yleismaallisesti luettavia tapa periytää koodia.

Ja sitten siitä läski nuolesta on muutakin hyötyä kuin vaan se, että korvaa function avainsanan

 

[Bladekill]

Koska olioohjelmointi on hidasta ja raskasta wäääähhhhhhh. Koska funktionaalinen ohjemointi on niin siistiä ja first class citizen funktioiden passaus parametreinä ja return arvoina on niiiiiiiin siiiistiiii!



Ei vaan, aika moni aloitteleva (tai hipster) ohjelmoija taas huutaa ton fuktionaalisen ohjelmoinnin perään ja selittää, että olio-ohjelmoinnista ei ole mitään hyötyä. Mitä itse olen tässä kohta 10 vuotta paukuttanut koodia duunikseni niin voin sanoa, että jos ei olio-ohjelmoinnista ole hyötyä niin kannattaa vaihtaa alaa. Jos ei pysty suunnittelemaan järkevää luokkahierarkiaa niin syy on koodarissa eikä kielessä.

Kuulostaa aika katkeralta ja aivan yliampuvalta kärjistykseltä. Ensinnäkään en ole ikinä (eteenkään tässä kontekstissa) kuullut kenenkään sanovan, että olio-ohjelmoinnista ei olisi mitään hyötyä. Toiseksi aloittelevat ohjelmoijat nimenomaan yleensä tulevat juuri koulun penkiltä Java OO-maailmasta eivätkä useimmiten edes tiedä mitä funktionaalinen ohjelmointi tarkoittaa. Kolmanneksi "hipster-ohjelmoija" tuntuu nykyisin olevan enterprise seniilipappojen tapa kirota niitä, jotka osaavat siirtyä ajassa eteenpäin.

Olio-ohjelmointi on paradigma siinä missä muutkin ja tuskin on kovin montaa asiaa mitä funktionaalisella ohjelmoinnilla voisi tehdä jota ei kuitenkaan OO:lla saisi tehtyä. Näiden vastakkainasettelussa kyse ei kuitenkaan ole siitä että mitä vaan _miten_. Kun noudattaa FP perusperiaatteita eli mm. no (global) mutable state, funktiot/koodi ilman side-efektejä jne. saadaan huomattavasti parempaa koodia jota on huippuhelppoa ylläpitää ja uudelleenkäyttää, bugien määrä vähenee 90-99% ja unit testaaminen ja debuggaaminen muuttuu tuskasta lähes automaattiseksi. Kuten yleensäkin IT projekteissa, softan vaatimukset, UI, ominaisuudet jne. muuttuvat n. miljardi kertaa prosessin aikana ja tämä tekee lähes poikkeuksetta ennen pitkää koodista "spagettia" tai vähintäänkin vaatii isompia refaktorointivaihteita. Yleensä nämä isommat refaktorointivaiheet menevät siihen että todetaan codebaselle "kill it with fire" eli vanha sotku viemäristä alas ja koko homma skrädestä uusiksi uusilla vaatimuksilla kunnes se taas spagetoituu.

 

[Karhukainen]

Vihatuimmat VBA ja PHP. Onneksi ei tarvitse PHP:lla tehdä mitään, se on aivan kammottavaa.

Pidän eniten Pythonista.

 

[jive]

Kuulostaa aika katkeralta ja aivan yliampuvalta kärjistykseltä. Ensinnäkään en ole ikinä (eteenkään tässä kontekstissa) kuullut kenenkään sanovan, että olio-ohjelmoinnista ei olisi mitään hyötyä. Toiseksi aloittelevat ohjelmoijat nimenomaan yleensä tulevat juuri koulun penkiltä Java OO-maailmasta eivätkä useimmiten edes tiedä mitä funktionaalinen ohjelmointi tarkoittaa. Kolmanneksi "hipster-ohjelmoija" tuntuu nykyisin olevan enterprise seniilipappojen tapa kirota niitä, jotka osaavat siirtyä ajassa eteenpäin.

Olio-ohjelmointi on paradigma siinä missä muutkin ja tuskin on kovin montaa asiaa mitä funktionaalisella ohjelmoinnilla voisi tehdä jota ei kuitenkaan OO:lla saisi tehtyä. Näiden vastakkainasettelussa kyse ei kuitenkaan ole siitä että mitä vaan _miten_. Kun noudattaa FP perusperiaatteita eli mm. no (global) mutable state, funktiot/koodi ilman side-efektejä jne. saadaan huomattavasti parempaa koodia jota on huippuhelppoa ylläpitää ja uudelleenkäyttää, bugien määrä vähenee 90-99% ja unit testaaminen ja debuggaaminen muuttuu tuskasta lähes automaattiseksi. Kuten yleensäkin IT projekteissa, softan vaatimukset, UI, ominaisuudet jne. muuttuvat n. miljardi kertaa prosessin aikana ja tämä tekee lähes poikkeuksetta ennen pitkää koodista "spagettia" tai vähintäänkin vaatii isompia refaktorointivaihteita. Yleensä nämä isommat refaktorointivaiheet menevät siihen että todetaan codebaselle "kill it with fire" eli vanha sotku viemäristä alas ja koko homma skrädestä uusiksi uusilla vaatimuksilla kunnes se taas spagetoituu.

Yritätkö syyttää huonosta projektinhallintakulttuurista jotakin tiettyä ohjelmointikieltä? Yleisesti ottaen mitä korkeampi abstraktiotaso ja ilmaisuvoima, sitä tehokkaammin saa aikaan ongelmia joiden selvittäminen ei ole taloudellisesti järkevää.

 

[AION]

Yritätkö syyttää huonosta projektinhallintakulttuurista jotakin tiettyä ohjelmointikieltä? Yleisesti ottaen mitä korkeampi abstraktiotaso ja ilmaisuvoima, sitä tehokkaammin saa aikaan ongelmia joiden selvittäminen ei ole taloudellisesti järkevää.

Mutta samalla taas mitä korkeampi abstraktio taso ja ilmaisuvoima niin saat aikaiseksi nopeammin korkeamman tason funktionaalisuutta.

Eli ns. 50-50 tilanne. Itse olen sitä mieltä, että pätevä porukka tekee korkeammalla abstraktiotasolla nopeammin hyvää tulosta kuin alemmalla. Sitten taas paska porukka saattaa tehdä vaikeasti selvitettäviä ongelmia korkeammalla abstraktiotasolla mutta samalla taas saattavat tehdä näitä vaikeasti selvitettäviä ongelmia. Kuitenkin jos ne olisi kokeillut tehdä saman projektin alhaisemmalla abstraktiotasolla niin yksittäiset ongelmat olisivat helpompi selvittää mutta sen sijaan, että on (vaikka) 10k riviä koodia niin yht'äkkiä sulla onkin koko armeijalle spagettia.

 

[Bladekill]

Yritätkö syyttää huonosta projektinhallintakulttuurista jotakin tiettyä ohjelmointikieltä?

En?

...???...

 

[jive]

Millaisiin ongelmiin viittaat? Onko jotain esimerkkiä?

Muistinhallinta, rinnakkaisuus ja reaktiivisuus. Noissa kun on bugi, niin niitä on haastava selvitellä. Toisaalta DSM tai suunnittelun virheillä saa aikaan toteutuksen loppuvaiheessa snafuja joita voi olla mahdoton korjata muutoin kuin aloittamalla alusta.

 

[AION]

Muistinhallinta, rinnakkaisuus ja reaktiivisuus. Noissa kun on bugi, niin niitä on haastava selvitellä. Toisaalta DSM tai suunnittelun virheillä saa aikaan toteutuksen loppuvaiheessa snafuja joita voi olla mahdoton korjata muutoin kuin aloittamalla alusta.

Mitä tarkkaan ottaen meinaat muistihallinnan ongelmilla?

Olen kymmenen vuoden aikana tasan kaksi kertaa ajanut oikeasti vaikeasti selvitettävään muistivuotoon Java softassa. Molemmat kyllä lopulta aukesi mutta oli ns. Circular referenssi jota GC ei osannut (sillon) korjata pois.

Sitten taas C:llä niitä on aika helvetisti helpompi tehdä.

Rinnakkaisuus vähän sama. Kyllä se JVM paiskaa sieltä sen ConcurrentException ihan stack tracen kanssa ja jos ei sillä vielä selviä nii Mission Controlli päälle ja break on throw ja ei pitäis olla kovin hankala selvittää. Joskus tullut pari deadlockia vastaan, jotka oli vitun vaikea selvittää (ja jcifs kirjasto ja miten pompitaan staticciin koodiin ja takasin ja lukotetaan ristiin nii siellä on pari miinaa)

Sitten taas jos sulla on 10miljoonaa riviä C:tä tai Ecma scriptiä nii gg hf niillä työkaluilla.

 

[mystikkogames]

Kyllähän std - kirjasto ja v8 on huonoa mainosta C++:lle. Kotlin on kyllä myös yksi esimerkki huonosta kielestä. Sehän pyörii Javan päällä kuten processing. En tajua miksi se tarvitsee Javaa yhtään mihinkään. Ihan oma kieli ilman mitään Java kytköksiä olisi ollut parempi.

GC on todella huono juttu. Jos ohjelmoija ei osaa itse käsitellä muistia niin toivo on mennyttä. flangissa ei ole GC:tä eikä tule. Ei se muistivuoto ole huono juttu vaan se että sitä muistia joudutaan tutkimaan ja vapauttelemaan laiskan ohjelmoijan puolesta. Ja se syö prosessoritehoa.

 

[Overgeneralizer]

Jos ohjelmoija ei osaa itse käsitellä muistia niin toivo on mennyttä. flangissa ei ole GC:tä eikä tule. Ei se muistivuoto ole huono juttu vaan se että sitä muistia joudutaan tutkimaan ja vapauttelemaan laiskan ohjelmoijan puolesta. Ja se syö prosessoritehoa.

Ei se nyt ihan noin yksinkertaista ole. Se että osaa jotain, ei tee virheistä mahdottomia. Ja monet GC kielet ovat throughput mielessä varsin ok, vaikkeivät välttämättä sovellukaan käyttötapauksiin joissa RT vaatimukset ovat tiukat. Periaatteessa on aina positiivista, jos kehittäjän ajankäyttöä saadaan siirrettyä kielen konstruktioiden kanssa nyhjäämisestä business-logiikan miettimisen puolelle. Eli GC kieliä pitää käyttää oikeissa tilanteissa, siis siellä missä niiden vahvuudet tulevat esiin, mutta heikkoudet eivät.

 

[mopnex]

Tarpeen mukaan valitaan kieli, siihen liittyy niin paljon muuttujia että aika turha listata tässä kaikkia. Muutamia kuitenkin mainitakseni: asiakkaan ympäristöt, asiakkaan tarpeet, tiimin osaaminen, tiimin kiinnostus oppia uutta, ylläpidettävyys jne.. Teoriassa kaiken voisi kirjoittaa Haskellia käyttäen, mutta onko se järkevää - niin ehkäpä ei.

Omat suosikit on varmaan compile-to-JS-kielet (Elm, ReasonML/BuckleScript, PureScript, TypeScript) sekä JVM maailmasta Clojure ja Kotlin. Haskellia tekisi mieli opetella enemmänkin, Elm lähtee vähän enemmän siitä kulmasta että käytöntö ensin. Kirjoitan työkseni JavaScript / TypeScript / (Flow) / Java -kielillä, ja kyllähän sitä itse tiedostaa ne vaikeat/huonot paikat noissa kielissä. Missä asiat olisi voinut tehdä eri tavalla. Harrastepuolella omia suosikkeja on Clojure, Elm ja Kotlin - näillä tulee siis lähinnä testailtua miltä noiden kielten kanssa toimiminen tuntuisi. Haskell, Elixir, Prolog noistakin on vähän kokemusta, mutta kun omassa työssä näille ei ehkä ole suoraa käyttöä.

En mielellään kirjoita PHP:llä nykyisin mitään, eikä ole tarvetta. Ymmärrän kuitenkin että maailmassa on sen verran paljon PHP koodia, että tällekkin on paikkansa. MUMPS on sellainen kieli mitä ei kyllä mielellään lähtisi kirjoittamaan - tarpeettoman epäselvää ja huonosti luettavaa. Ylläpitomielessä kun pitää miettiä myös sitä, millaista osaamista on saatavilla nyt - tai mahdollisesti tulevaisuudessa.

Kyllähän std - kirjasto ja v8 on huonoa mainosta C++:lle. Kotlin on kyllä myös yksi esimerkki huonosta kielestä. Sehän pyörii Javan päällä kuten processing. En tajua miksi se tarvitsee Javaa yhtään mihinkään. Ihan oma kieli ilman mitään Java kytköksiä olisi ollut parempi. ...

Kotlin, Clojure, Scala ja muut JVM päällä pyörivät kielet ovat fiksuja siinä - että käyttävät JVM ekosysteemiä hyväkseen. Kuitenkin tuotantokoodista kun puhutaan, niin on järkevää käyttää jo olemassa olevaa alustaa hyödyksi. Javasta kielenä toki voi olla montaa mieltä, mutta ekosysteeminä se on sen verran laaja ja laajalle levinnyt että mielummin sitä ottaa järkevän kielen joka hyötyy JVM:stä. Kuin koodailee kotona sitten jollain esoteerisemmalla kielellä, ja naputtelee Java 6 töissä.

 

[jive]

Mitä tarkkaan ottaen meinaat muistihallinnan ongelmilla?

esimerkkinä vaikkapa QtQuick jossa oli näkymän sulkemiseen liittyvä muistivuoto. Ei ollut ihan helppo löytää. Viimeisin oli Windowsin resurssihallinan ominaisuus, jossa descriptorien periytyminem prosessien välillä oli haastava hanskata. JS maailmasta tulee lähinnä mieleen ongelmat replikoida ympäristöjä kun kaikki liikkuu eteenpäin sellaisella vauhdilla, että kokonaisuus on ehjä vain hetken kerrallaan. Jotta jotakin saisi testattua niin koko maailma pitää kietoa shrinkwrapilla tai varautua pitämään npm mirroria yllä täältä ikuisuuteen.

 

[AION]

esimerkkinä vaikkapa QtQuick jossa oli näkymän sulkemiseen liittyvä muistivuoto. Ei ollut ihan helppo löytää. Viimeisin oli Windowsin resurssihallinan ominaisuus, jossa descriptorien periytyminem prosessien välillä oli haastava hanskata. JS maailmasta tulee lähinnä mieleen ongelmat replikoida ympäristöjä kun kaikki liikkuu eteenpäin sellaisella vauhdilla, että kokonaisuus on ehjä vain hetken kerrallaan. Jotta jotakin saisi testattua niin koko maailma pitää kietoa shrinkwrapilla tai varautua pitämään npm mirroria yllä täältä ikuisuuteen.

Palaan asiaan vielä paremmalla ajalla mutta toi JS osui kyllä naulan kantaan.

 

[jive]

Kannattaa muistaa että jonkun on saatava se koko kerros ASIC:a, käyttöjärjestelmää, ajuria, kääntäjiä ja paksua middlewarea koodattua, jotta joku JS edes saadaan ajoon. Siellä tehdään edelleen hommia kyynärpäät rasvassa ja jos C tuntuu kankealta, niin koodatpaakas VHDL:ää ...

 

[AION]

Kannattaa muistaa että jonkun on saatava se koko kerros ASIC:a, käyttöjärjestelmää, ajuria, kääntäjiä ja paksua middlewarea koodattua, jotta joku JS edes saadaan ajoon. Siellä tehdään edelleen hommia kyynärpäät rasvassa ja jos C tuntuu kankealta, niin koodatpaakas VHDL:ää ...

Se on ihan totta, että joku varmasti tekee duunia siellä pinkan keskelläkin. Kuitenkin suurin osa täälläkin pyörivästä porukasta on enemmän vähemmän sovellusohjelmoijia, joiden ei periaatteessa pitäisi tarvita mennä pyörimään sinne pinkan keskellä vaan pelkästää tehdä siitä pinkasta jotain käytettävää tavalliselle kansalaiselle.

Tässä onkin juuri omasta mielestäni se jutun juju, että sovellusohjelmoijien duuni ei ole hallita muistia tai miettiä prosessorin cachejen kokoja ja laatuja vaan pelkästään tuottaa sovelluksia tai palveluita niitä kaipaaville. Tämä juurikin sitten taas erottelee ohjelmointikieliä aika isosti jo.

Ja se koko pakka on niin karmivan kokoinen, että ei me löydetä montaa ihmistä, jotka tietäisi tai osaisi sitä kokonaan. Eikä me voida vaatia, että se kaveri kuka paukuttelee meille iltalehti.fi:n JS:t edes osaisi, saati sitten haluaisi ostata, koko pakkaa. Ja niin kauan kun meitä ei kiinnosta testata jotain onLoad funktioiden latausjärjestyksiä jollain mobiili IE:llä niin ei me sitä voida edes vaatia.

 

[jive]

Ja se koko pakka on niin karmivan kokoinen, että ei me löydetä montaa ihmistä, jotka tietäisi tai osaisi sitä kokonaan. Eikä me voida vaatia, että se kaveri kuka paukuttelee meille iltalehti.fi:n JS:t edes osaisi, saati sitten haluaisi ostata, koko pakkaa. Ja niin kauan kun meitä ei kiinnosta testata jotain onLoad funktioiden latausjärjestyksiä jollain mobiili IE:llä niin ei me sitä voida edes vaatia.

No minulle riittäisi jos sovellusohjelmoijat kunnioittaisivat tekniikoita, joilla heidän työnsä on mahdollista. Noinniinku terveisenä sieltä pinkan pohjalta

 

[AION]

No minulle riittäisi jos sovellusohjelmoijat kunnioittaisivat tekniikoita, joilla heidän työnsä on mahdollista. Noinniinku terveisenä sieltä pinkan pohjalta

No itse kyllä kunniotan, tai ainakin pyrin kunnioittamaan. Olen C - kielen, piirisuunnittelun jne kurssini käynyt ja voin suositella kaikille, ketkä haluavat ymmärtää sieltä jotain. Mutta sitten on taas porukkaa ketä se ei kiinnosta ja se on mulle ihan ok niin kauan kun ne tekee hommansa

 

[mystikkogames]

Kotlin, Clojure, Scala ja muut JVM päällä pyörivät kielet ovat fiksuja siinä - että käyttävät JVM ekosysteemiä hyväkseen. Kuitenkin tuotantokoodista kun puhutaan, niin on järkevää käyttää jo olemassa olevaa alustaa hyödyksi. Javasta kielenä toki voi olla montaa mieltä, mutta ekosysteeminä se on sen verran laaja ja laajalle levinnyt että mielummin sitä ottaa järkevän kielen joka hyötyy JVM:stä. Kuin koodailee kotona sitten jollain esoteerisemmalla kielellä, ja naputtelee Java 6 töissä.

GitHub - JetBrains/kotlin: The Kotlin Programming Language
Yritin etsiä tuolta sotkusta parseria, lexeriä ja executeria, mutta tuolta löytyy vaan miljoona kansiota ja .jar siellä sun täällä. En viitsinyt ladata koska paketti on luultavasti 500MB. Pelkän sotkuisen sorsan perusteella en aio koskea tikullakaan kotliniin ikinä. Luultavasti tuokin "kieli" on samanlainen kuin processing. Eli regexillä komennot Javaksi. Ei siinä mitään, mutta miksi koodaisin Javaa Kotlinilla. Muutenkin liian verbose-kieli.

No itse kyllä kunniotan, tai ainakin pyrin kunnioittamaan. Olen C - kielen, piirisuunnittelun jne kurssini käynyt ja voin suositella kaikille, ketkä haluavat ymmärtää sieltä jotain. Mutta sitten on taas porukkaa ketä se ei kiinnosta ja se on mulle ihan ok niin kauan kun ne tekee hommansa

Ainoa tapa oppia ohjelmointia on ohjelmoida valtavasti. Mitään kurssia ei ole olemassa missä oppisi ohjelmoimaan mestarillisesti. Esim. et voi käydä GO-kurssia ja pelata GOta samantien 7-danin arvoisesti. Ohjelmoinnissa on sama juttu. Monet eivät ymmärrä että ohjelmoinnin mestarilliseen hallitsemiseen vaaditaan valtava määrä työtä. 10 vuotta ohjelmointia ja vasta sitten ymmärtää ohjelmoinnin "kieltä". Kuinka asiat ohjelmoidaan elegantisti. Kuinka vältetään komplikaatiot, johon noviisit sortuvat.

 

[AION]

Ainoa tapa oppia ohjelmointia on ohjelmoida valtavasti. Mitään kurssia ei ole olemassa missä oppisi ohjelmoimaan mestarillisesti. Esim. et voi käydä GO-kurssia ja pelata GOta samantien 7-danin arvoisesti. Ohjelmoinnissa on sama juttu. Monet eivät ymmärrä että ohjelmoinnin mestarilliseen hallitsemiseen vaaditaan valtava määrä työtä. 10 vuotta ohjelmointia ja vasta sitten ymmärtää ohjelmoinnin "kieltä". Kuinka asiat ohjelmoidaan elegantisti. Kuinka vältetään komplikaatiot, johon noviisit sortuvat.

Hei,

Olet aivan oikeassa.

Kuitenkin ihminen, joka haluaa toteuttaa tai yrittää toteuttaa koirien kustukseen Tinderin kaltaisen softan - ei halua tai ei tarvitse osata ohjelmoida. Minä osaan ohjelmoida mutta ei tule mieleenkään, että mitä ohjelmoisin. Siksi otan siitä rahaa.

Ohjelmointi, kielet, työkalut jne. pitäisi kuitenkin loppupeleissä olla työkaluja ihmisille tuottamaan palveluja ihmisille.

Se, että me (itse olen serveri / business logiikka / full stack tekijä) tehdään vaikeitakin asioita on yksi tarina. Toinen tarina on se, että joku haluaa tuottaa koirien kusetuksen Tinderin ei välttämättä vaadi mallocin osaamista. Eikä pitäisikään vaatia.

Tästä olen sinun kanssasi yrittänyt käydä keskustelua jo monessa eri threadissa. Ohjelmointi, varinskin HC ohjelmointi, on eri asia kuin se, että tuotetaan sovelluksia, palveluita, pelejä tms. Niissä on isompia tiimejä tekemässä sitä asiaa ja riittävän helppokäyttöinen stackki mahdollistaa sen, että minun ja sinun ei tarvitse miettiä koirien kusetusta vaan me tehdään se pakka ja ihan jotkut muut ihmiset tekevät sen viimeisen tason siihen koirien kusetuksen ja oikean koodin väliin

 

[Xiyng]

GitHub - JetBrains/kotlin: The Kotlin Programming Language
Yritin etsiä tuolta sotkusta parseria, lexeriä ja executeria, mutta tuolta löytyy vaan miljoona kansiota ja .jar siellä sun täällä. En viitsinyt ladata koska paketti on luultavasti 500MB. Pelkän sotkuisen sorsan perusteella en aio koskea tikullakaan kotliniin ikinä. Luultavasti tuokin "kieli" on samanlainen kuin processing. Eli regexillä komennot Javaksi. Ei siinä mitään, mutta miksi koodaisin Javaa Kotlinilla. Muutenkin liian verbose-kieli.

Nähtävästi et ihan osaa, koska ainakin parseri ja lexeri löytyivät hyvin pienellä vaivalla - ja olivat muuten ihan loogisissa paikoissa. Regex-väitteen perusteella on muuten pakko kysyä: ymmärrätkö, mikä JVM on?

 

[mystikkogames]

Nähtävästi et ihan osaa, koska ainakin parseri ja lexeri löytyivät hyvin pienellä vaivalla - ja olivat muuten ihan loogisissa paikoissa. Regex-väitteen perusteella on muuten pakko kysyä: ymmärrätkö, mikä JVM on?

No olisit edes laittanut linkit mistä löytyy parseri, lexeri ja joku millä tuo sotku ajetaan. Ihan mielenkiinnosta katson jos olisi jotain hyödyllistä flangiin. Regex - väite perustuu siihen että processing oli lyhyitä komentoja jotka muokattiin Javaksi. drawRect() -> pitkä Java - rimpsu. Jos koodaisit muitakin kuin hello-worldejä sillä haskellilla niin ehkä olisit ymmärtänyt.

 

[Xiyng]

No olisit edes laittanut linkit mistä löytyy parseri, lexeri ja joku millä tuo sotku ajetaan. Ihan mielenkiinnosta katson jos olisi jotain hyödyllistä flangiin. Regex - väite perustuu siihen että processing oli lyhyitä komentoja jotka muokattiin Javaksi. drawRect() -> pitkä Java - rimpsu. Jos koodaisit muitakin kuin hello-worldejä sillä haskellilla niin ehkä olisit ymmärtänyt.

Ajattelin jättää omaksi iloksesi, kun ovat niin loogisissa paikoissa, mutta tässäpä ovat ainakin lekseri ja parseri. Vilkaise ihmeessä samalla tiedostojen polut huomataksesi logiikan. Huomaa myös, että lekseri taitaa olla generoitu erillisestä määrittelytiedostosta (jonka osoite on annettu lähdekooditiedostossa). main taas löytyy preloading-paketista, joka on ainakin minusta sille ihan looginen paikka.

"Luultavasti" on muuten sana, joka saa väitteen vaikuttamaan kovasti arvaukselta eikä edes valistuneelta sellaiselta, joten ehkä siksi arvelin, että kyseessä oli vain ylimielinen arvaus eikä mitään tietoon perustuvaa. Jos kääntäjä tosiaan yksinkertaisesti muuttaa koodia Javaksi, sitä voi pitää jo vähän mielenkiintoisena ratkaisuna minunkin mielestäni. Toki se lienee helpoin tapa tehdä asioita ainakin tiettyyn pisteeseen asti, ja ehkä javac tuottaa parempaa tavukoodia kuin mihin Kotlin-tiimillä on tähän hätään rahkeita.

Hello world -heitto oli muuten aika hieno ad hominem (joka ei edes pitänyt paikkaansa). Nähtävästi mitään oikeaa sanottavaa ei kuitenkaan ollut.

 

[mystikkogames]

Etsin sitä missä toteutetaan shunting-yard algoritmi jossa infix muunnetaan postfixiksi. Tunnistan tämän algoritmin vaikka se olisi Javan verbose - paskan alla. Tietysti tämän asian tajuaminen on vaikeaa jos ei ole ohjelmoinut yhtään mitään. Muuta kuin lukenut mitä viisaammat kuten allekirjoittanut kirjoittaa interwebbiin. Tietysti jonkunhan tyhmempienkin valistaminen on tehtävä. Ja se risti lankeaa itselleni.

Täällä voivat kaikki ihailla kuinka toteutin jumalallisesti shunting-yard algoritmin voodoo.js:ssa
voodoo/voodoo.js at master · mystikkogames/voodoo · GitHub

 

[Xiyng]

Etsin sitä missä toteutetaan shunting-yard algoritmi jossa infix muunnetaan postfixiksi. Tunnistan tämän algoritmin vaikka se olisi Javan verbose - paskan alla.

No, en osaa auttaa tuon kanssa, koska en jaksa lukea minulla melko yhdentekevää koodia. Melko pienellä vaivalla sain sen sijaan selvitettyä, oliko projekti niin sekavasti järjestetty kuin väitit.

Tietysti tämän asian tajuaminen on vaikeaa jos ei ole ohjelmoinut yhtään mitään.

Lähinnä tuottaa vaikeuksia ymmärtää, miten tämä kommentti liittyy yhtään mihinkään.

Muuta kuin lukenut mitä viisaammat kuten allekirjoittanut kirjoittaa interwebbiin. Tietysti jonkunhan tyhmempienkin valistaminen on tehtävä. Ja se risti lankeaa itselleni.

Täällä voivat kaikki ihailla kuinka toteutin jumalallisesti shunting-yard algoritmin voodoo.js:ssa
voodoo/voodoo.js at master · mystikkogames/voodoo · GitHub

Nähtävästi ihan kaikkia suomalaisia ei vaivaa ainakaan turha vaatimattomuus.

 

[JRan]

Omat inhokit on Haskell, Brainfuck ja Assembler.

Mutta itse olen hyvin eri mieltä esim. Perlistä ja PHP:sta. PHP-CLI, PERL, BASH ja Python käytösssä ja niillä saa hyvinkin nopeastikin kirjoitettua monimutkaisia scriptejä esim. relaatiokantojen ylläpitoon. Kertakäyttöisiä sekä pysyvämpiä, joita voi ajaa cronilla ihan yhtä hyvin, kun mitä tahansa muutakin.