Vihatuimmat ohjelmointikielet

Viestiketju alueella 'Ohjelmointi, pelikehitys ja muu sovelluskehitys' , aloittaja oselotti, 01.11.2017.

  1. oselotti

    oselotti

    Viestejä:
    300
    Rekisteröitynyt:
    02.11.2016
    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?

    languages-1-900x675.png

    Edit: väärä kuva
     
    Viimeksi muokattu: 01.11.2017
  2. Xtremerr

    Xtremerr

    Viestejä:
    61
    Rekisteröitynyt:
    19.10.2016
    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 :D
     
  3. Xiyng

    Xiyng

    Viestejä:
    967
    Rekisteröitynyt:
    19.10.2016
    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. :D
     
  4. oselotti

    oselotti

    Viestejä:
    300
    Rekisteröitynyt:
    02.11.2016
    JavaScriptissä olen kyllä ihmetellyt joitain juttuja, esimerkiksi tuota ASI:a (Automatic Semicolon Insertion). En vaan ymmärrä sen pointtia. Pidän kyllä itsekin staattisesti tyypitetyistä kielistä enemmän, vaikkakin dynaamisia pääosin nykyään käytänkin.

    There are only two kinds of languages: the ones people complain about and the ones nobody uses.
    --Bjarne Stroustrup
    ;)
     
    Wizand, Pekste, jarif ja 2 muuta tykkäävät tästä.
  5. AION

    AION

    Viestejä:
    340
    Rekisteröitynyt:
    09.12.2016
    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.
     
  6. Vertex

    Vertex

    Viestejä:
    849
    Rekisteröitynyt:
    17.10.2016
    C#, Java ja C++ on aika korkealla tuolla listalla. Miksi näin?
     
  7. Technocrat

    Technocrat

    Viestejä:
    122
    Rekisteröitynyt:
    17.10.2016
    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ä.
     
  8. AION

    AION

    Viestejä:
    340
    Rekisteröitynyt:
    09.12.2016

    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!

    :D

    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ä.
     
    Wizand ja Yleinen Faktoidi tykkäävät tästä.
  9. Xiyng

    Xiyng

    Viestejä:
    967
    Rekisteröitynyt:
    19.10.2016
    Huomaa toki, että CoffeeScript ja Haskell ovat listalla aika korkealla, ja olio-ohjelmointia edustavat JavaScript ja Python aika alhaalla.

    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ä.
     
  10. AION

    AION

    Viestejä:
    340
    Rekisteröitynyt:
    09.12.2016
    Juuh, toki JS:ää voi kirjoittaa aika pitkälle funktionaalisestikin eikä ole vaatimusta kirjoittaa välttämättä luokkia ollenkaan

    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ä.
     
  11. Xiyng

    Xiyng

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

    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.

    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.
     
  12. bulson

    bulson

    Viestejä:
    100
    Rekisteröitynyt:
    18.09.2017
    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).
     
  13. AION

    AION

    Viestejä:
    340
    Rekisteröitynyt:
    09.12.2016

    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 ;)
     
  14. Xiyng

    Xiyng

    Viestejä:
    967
    Rekisteröitynyt:
    19.10.2016
    @AION: IE:n kuolemaa odotellessa...
     
  15. joku43

    joku43

    Viestejä:
    106
    Rekisteröitynyt:
    03.02.2017
    perli on siel missä kuuluukii mutta PerseHaiseePaskalta on vasta puol-välin tuntumassa :confused: :smoke:
     
  16. oselotti

    oselotti

    Viestejä:
    300
    Rekisteröitynyt:
    02.11.2016
    Varmaankin johtuu siitä, että ne ovat vanhoja suuria teknologioita, joilla on paljon käyttäjiä.
    Tuolla oli myös tämä kuvaaja, jossa tarkasteltiin kasvua vuoden ajalta suhteutettuna siihen, miten paljon kyseisestä kielestä pidetään. Eli noin suurin piirtein kielestä pidetään jos se on nosteessa ja siitä ei pidetä jos sen käyttö on laskussa.

    growth_plot-1-759x675.png
    Jep, JS on kehittynyt hyvään suuntaan kun noita funktionaalisia juttuja on tuotu siihen, esim. map(), filter(), reduce() jne.
     
  17. Noddy

    Noddy

    Viestejä:
    413
    Rekisteröitynyt:
    28.10.2016
    Mutta tuohan on suhteutettuna kokonaismäärään eli alhaalla lukee # disliked / total
    Muutenhan koko taulukko olisi täysin hyödytön.
     
  18. oselotti

    oselotti

    Viestejä:
    300
    Rekisteröitynyt:
    02.11.2016
    Niin, olet oikeassa.

    Ajoin lähinnä takaa sitä, että jos on joku tällainen yleiskieli (esim. Java), jota käytännössä kaikki osaavat, niin siitä on helpompi olla pitämättä, kuin spesifistä "pienen piirin" kielestä, joka tekee sen tietyn asian paremmin, johon kyseistä kieltä käytetään (esim. R ja Rust). Viittasin siis tuohon lisäämääni lainaukseen.

    Vai onko tämä liian kaukaa haettua?
     
    Wizand tykkää tästä.
  19. Yleinen Faktoidi

    Yleinen Faktoidi

    Viestejä:
    94
    Rekisteröitynyt:
    18.10.2016
    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.
     
  20. fei

    fei BANNATTU BANNED

    Viestejä:
    209
    Rekisteröitynyt:
    28.12.2016
    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ä.

    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.
     
  21. mystikkogames

    mystikkogames

    Viestejä:
    102
    Rekisteröitynyt:
    05.11.2017
    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
     
  22. Vertex

    Vertex

    Viestejä:
    849
    Rekisteröitynyt:
    17.10.2016
    Mitä ne mokat sitten on?
     
  23. Xiyng

    Xiyng

    Viestejä:
    967
    Rekisteröitynyt:
    19.10.2016
    Niin? Olio-ohjelmointi ei edellytä luokkia vaikka monissa olio-ohjelmoinitikielissä sellaiset onkin.

    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.
     
  24. AION

    AION

    Viestejä:
    340
    Rekisteröitynyt:
    09.12.2016


    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 ;)
     
  25. Bladekill

    Bladekill

    Viestejä:
    310
    Rekisteröitynyt:
    18.10.2016
    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.
     
    Viimeksi muokattu: 11.11.2017
    oselotti, Paapaa ja Xiyng tykkäävät tästä.
  26. oselotti

    oselotti

    Viestejä:
    300
    Rekisteröitynyt:
    02.11.2016
    Mitä kääntäjää tarkoitat?

    Tuli mieleen tämä twiitti, joka kiteyttää aika hyvin:

     
  27. Karhukainen

    Karhukainen

    Viestejä:
    5
    Rekisteröitynyt:
    27.10.2016
    Vihatuimmat VBA ja PHP. Onneksi ei tarvitse PHP:lla tehdä mitään, se on aivan kammottavaa.

    Pidän eniten Pythonista.
     
  28. jive

    jive

    Viestejä:
    509
    Rekisteröitynyt:
    27.12.2016
    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ää.
     
  29. AION

    AION

    Viestejä:
    340
    Rekisteröitynyt:
    09.12.2016


    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.
     
    Wizand ja jive tykkäävät tästä.
  30. Bladekill

    Bladekill

    Viestejä:
    310
    Rekisteröitynyt:
    18.10.2016
    En?

    ...???...

    :D
     
  31. oselotti

    oselotti

    Viestejä:
    300
    Rekisteröitynyt:
    02.11.2016
    Millaisiin ongelmiin viittaat? Onko jotain esimerkkiä?
     
  32. jive

    jive

    Viestejä:
    509
    Rekisteröitynyt:
    27.12.2016
    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.
     
  33. AION

    AION

    Viestejä:
    340
    Rekisteröitynyt:
    09.12.2016

    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.
     
  34. mystikkogames

    mystikkogames

    Viestejä:
    102
    Rekisteröitynyt:
    05.11.2017
    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.
     
    Ormu tykkää tästä.
  35. Overgeneralizer

    Overgeneralizer

    Viestejä:
    48
    Rekisteröitynyt:
    26.04.2017
    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.
     
    Deussu, oselotti, Ormu ja 1 muu käyttäjä tykkää tästä.
  36. mopnex

    mopnex

    Viestejä:
    94
    Rekisteröitynyt:
    24.12.2016
    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.

    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ä.
     
    oselotti tykkää tästä.
  37. jive

    jive

    Viestejä:
    509
    Rekisteröitynyt:
    27.12.2016
    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 tykkää tästä.
  38. AION

    AION

    Viestejä:
    340
    Rekisteröitynyt:
    09.12.2016

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

    jive

    Viestejä:
    509
    Rekisteröitynyt:
    27.12.2016
    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:ää ...
     
  40. AION

    AION

    Viestejä:
    340
    Rekisteröitynyt:
    09.12.2016

    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.
     
  41. jive

    jive

    Viestejä:
    509
    Rekisteröitynyt:
    27.12.2016
    No minulle riittäisi jos sovellusohjelmoijat kunnioittaisivat tekniikoita, joilla heidän työnsä on mahdollista. Noinniinku terveisenä sieltä pinkan pohjalta :love:
     
  42. AION

    AION

    Viestejä:
    340
    Rekisteröitynyt:
    09.12.2016

    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 ;)
     
  43. mystikkogames

    mystikkogames

    Viestejä:
    102
    Rekisteröitynyt:
    05.11.2017
    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.

    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.
     
  44. AION

    AION

    Viestejä:
    340
    Rekisteröitynyt:
    09.12.2016

    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 ;)
     
  45. Xiyng

    Xiyng

    Viestejä:
    967
    Rekisteröitynyt:
    19.10.2016
    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?
     
    oselotti tykkää tästä.
  46. mystikkogames

    mystikkogames

    Viestejä:
    102
    Rekisteröitynyt:
    05.11.2017
    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.
     
  47. Xiyng

    Xiyng

    Viestejä:
    967
    Rekisteröitynyt:
    19.10.2016
    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.
     
  48. mystikkogames

    mystikkogames

    Viestejä:
    102
    Rekisteröitynyt:
    05.11.2017
    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
     
  49. Xiyng

    Xiyng

    Viestejä:
    967
    Rekisteröitynyt:
    19.10.2016
    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.

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

    Nähtävästi ihan kaikkia suomalaisia ei vaivaa ainakaan turha vaatimattomuus. :D
     
    null, Haaskis, Deussu ja 3 muuta tykkäävät tästä.