Mikä kieli ja/tai kehitysväline foorumialustan ohjelmointiin?

Avaajalle vaan sinolia, kun ei osaa mitään koodata.

Anonyymi kirjoitti:

Avaajalle vaan sinolia, kun ei osaa mitään koodata.

Hyvin humaloitua olutta mieluummin, kiitos!

Riippuu mitä osaamisella tarkoitetaan. Aloitin 80-luvulla useammalla BASIC-murteella, mukana myös Amstrad-PC:n mukana tullut graafisessa ympäristössä toimiva Locomotive BASIC. Sitten siirryin askeettisempaan merkkipohjaiseen ohjelmointiin C-kielellä. Seuraavaksi opiskelin tutkinnon, jossa opetuskielenä oli vanha perinteinen Pascal. Sitten palasin graafiseen ohjelmointiin, nyt Delphin avulla (moderni versio Pascalista). Sitten taas opiskelemaan ja nyt opetuskielenä oli Java vuosituhannen vaihteessa.

Ai niin, oli välissä joskus 90-luvulla yksi olio-ohjelmointikurssi tulkkipohjaisessa graafisessa ympäristössä, joka ei jäänyt mieleeni (olisikohan ollut Eiffel). Enpä tullut kurssilta hullua hurskaammaksi.

Yliopisto-opintoni venyivät sen verran pitkiksi että on tullut useamman vuosikymmenen aikana seurattua alaa, mutta varsinaisesti ohjelmoijana/ohjelmistosuunnittelijana en ole työskennellyt. Omat kaupalliset ohjelmani tein jo ennen varsinaista alan opiskelua (yrittäjänä). Käytännön ohjelmointi ei vaan innosta, siis jatkuva tietojen metsästys ja kaivelu. Ennen oli paremmin kun ohjelmistovälineiden (kieli + rajapinnat) dokumentaatio mahtui kirjaan, opetteli välineen käytön ja alkoi sen jälkeen naputtelemaan koodia. Toki suunnitella piti ensin ja siihen mulla on tupannut projektini tyssätä kun ei enää ole toteuttaminen innostanut. :)

Suorituskyvystä:

1. Tehdään Javalla: Tarvitaan useita palvelimia ja kuormantasausjärjestelmä. Ja yksittäinen käyttäjä voi silti joutua odottelemaan.

2. Tehdään Delphillä: 1 palvelin riittää niin kauan, kun palvelua ei käytetä rikollisella tavalla (tässä viitataan erityisesti rikoslain pykälään "Tietoliikenteen häirintä").
Delphin suorituskyky on niin ylivoimainen, että useita palvelimia tai kuormantasausjärjestelmää ei tarvita.

Anonyymi kirjoitti:

Suorituskyvystä:

1. Tehdään Javalla: Tarvitaan useita palvelimia ja kuormantasausjärjestelmä. Ja yksittäinen käyttäjä voi silti joutua odottelemaan.

2. Tehdään Delphillä: 1 palvelin riittää niin kauan, kun palvelua ei käytetä rikollisella tavalla (tässä viitataan erityisesti rikoslain pykälään "Tietoliikenteen häirintä").
Delphin suorituskyky on niin ylivoimainen, että useita palvelimia tai kuormantasausjärjestelmää ei tarvita.

Lue lisää

"Delphin suorituskyky on niin ylivoimainen, että useita palvelimia tai kuormantasausjärjestelmää ei tarvita."

Höpöhöpö.

Useampi palvelin tarvitaan mikäli halutaan vikasietoisuutta.

Sen lisäksi et selvästikään ymmärrä, että jos jotain foorumia tekee niin suorituskyvyn kannalta kriittisintä on se miten toteuttaa tietokannan. Joku service hakee kannasta tai tekee postauksia on tässä hyvin yksinkertainen.

Oman asiansa tekee tietenkin se, että halutaanko foorumipostausten näkyvän vaikka hakutuloksissa jolloin olisi hyvä tietenkin renderöidä näkymä palvelimella Tämäkään ei ole vaativaa.

Mutta sitten kun siinä kokonaisuudessa on autentikoinnit, sessionhallinnat, cache, renderöinti, kantaliittimet, access control API kutsuille jne. mitä tässä nyt tarvitseekaan, siisti toteutus edellyttää web frameworkkia.

Delphille ei löydy niin hyvää web frameworkkia kuin Javalle, eikä varmasti niin suorituskykyistä joten Delphillä ei tässä tee yhtään mitään.

Anonyymi kirjoitti:

Avaajalle vaan sinolia, kun ei osaa mitään koodata.

Örvellyskielellä koodaamaan.

Valmispohjia on vaikka kuinka paljon. Miksi siis kannattaa aloittaa kaikkea alusta ja sairastaa kaikki lastentaudit ennen kuin loppukäyttäjät on tyytyväisiä?

Anonyymi kirjoitti:

Valmispohjia on vaikka kuinka paljon. Miksi siis kannattaa aloittaa kaikkea alusta ja sairastaa kaikki lastentaudit ennen kuin loppukäyttäjät on tyytyväisiä?

Riippuu osaamistasosta ja kuinka suuren käyttäjämäärän palvelua tekemässä.

Noin esimerkkinä kyllä Mark Zuckerbergiä saattoi jossain kohtaa vähän vituttaa kun Facebook oli jonkun PHP:n varassa.

Anonyymi kirjoitti:

Valmispohjia on vaikka kuinka paljon. Miksi siis kannattaa aloittaa kaikkea alusta ja sairastaa kaikki lastentaudit ennen kuin loppukäyttäjät on tyytyväisiä?

Niinhän sitä luulisi, mutta en ole ihan varma päätellen siitä, etten täysin tyydyttävään foorumiin vielä ole törmännyt.

1) tärkeintä uudelle foorumille olisi tehokkaasti toimiva moderointi, joka toimisi ilman ylläpitäjän aktiviteettia (eli se olisi joukkoistettu kirjoitusten lukijoille ja algoritmille); ne foorumisoftat joista yhtään mitään tiedän, vaikuttavat vaativan sen verran ylläpitäjältä, että he valkkaavat/valtuuttavat moderaattoreita käyttäjien joukosta ja sitten "sosialiseeraavat" heidän kanssaan, mikä puuha ei itseäni kiinnosta yhtään . Uskoakseni ratkaisu löytyisi viestikohtaisista arviointi-/palautepainikkeista ja käyttäjien "maineenhallinnasta" (eli sellaisten käyttäjien arvioinneilla annetaan vähemmän arvoa, joiden "peukkualas-sormi" on kovin herkässä ja toki toisinpäinkin).

2) viestiketju- ja viestinäkymät olisi kiva saada ergonomisemmiksi seurattaviksi kuin olemassa olevissa; pitkistä Suomi24:n ketjuista on todella työlästä löytää viestien väleihin lisätyt uudet vastaukset (tiedä josko kirjautumalla olisi toisin)

3) eri foorumi- ja blogialustat tuntuvat kaatuilevan ja olevan ajoittain suht työläitä toimivaksi palautettavia: alustan olisi syytä toimia kuin se kuuluisa (vanhan) junanvessa, mikä tarkoittanee että jotain on tehtävä toisin

Teoriassa varmaan olisi nopeinta ottaa joku avoin foorumisofta pohjaksi ja lähteä sitä virittämään.

Hyviä kysymyksiä. Jotta foorumi menestyisi, täytyy siellä joko olla entuudestaan runsaasti kiinnostavaa keskustelua ja riittävän vähän "kohinaa" tai vaihtoehtoisesti laajan porukan olla tietoinen uuden foorumin tuloillaan olemisesta ja valmiina ottamaan areena haltuunsa kun se valmistuu. Jälkimmäinen tilanne taitaa olla varsin harvinainen, mutta näin kävi taannoin tiedepalsta.fi-foorumin kanssa Tiede.fi-palvelun lopettaessa (ilmoittivat onneksi etukäteen palstan lopettamisesta ja foorumilla kerittiin käydä keskustelua uuden foorumin perustamisesta ja polkaista kaksikin kilpailevaa foorumia, joista em. sitten voitti skaban).

En mene vannomaan oikeaan-osuvuudesta, mutta käsitykseni on, että ilmaiset foorumisoftat eivät taida selvitä kovinkaan hyvin suuren käyttäjämäärän tuottamasta kuormasta, ja siksi kaupalliset keskustelufoorumit (isojen sanomalehtien nettikommentoinnit ja varmaan tämä Suomi24:kin) pohjannevat kaupallisiin softiin ellei peräti omin voimin koodattuihin palveluihin. Tosin, syynä voi toki olla sekin, että epäkaupallisia foorumeita pyöritetään pienin resurssein eikä niille vain yksinkertaisesti ole varaa ostaa tarpeeksi suoritusvoimaa pilvestä. Olisi mahtavaa jos joku tietävä haluaisi tätä puolta, tai muutakin liittyvää, valottaa tässä keskustelussa.

Ilmeisesti suurella volyymillä toimivan foorumin pitäisi luopua relaatiotietokannan käyttämisestä ja käyttää jotain non-sql-järjestelmää (tai koodata sellainen itse), jolloin voisi selvitä murto-osalla siitä laiteresurssista mitä tavanomaiset foorumialustat tarvitsevat. Videoiden välittämisen mukaan ottaminen toisi myös kaistan kustannuksen relevantiksi tekijäksi.

Miten peität kustannukset, joita em. toimet aiheuttavat?

Ihan tiedoksi:

100€/kk + sähkönkulutus pystyy hostaamaan aivan, mitä vain haluaa.

Tuo sähkönkulutus - se taas riippuu toisaalta sähkösopimuksesta ja toisaalta paikallisen siirtoyhtiön siirtohinnastosta.

Jos tilaat laajan ohjelmiston, ja maksat siitä 200€ - 300 €, niin taatusti saat huonoa laatua!

Olen yllättynyt, jos edes saat koodaustyötä tuolla hintatasolla (luultavasti et saa).

Todennäköisemmin, joku hemmo Intiassa käy läpi valtavan määrän aiemmin koodattuja asioita, valitsee yhden niistä, ja esittelee tuotteeen tilaajalle "omanaan".

M-Karin päinvastaisista väitteistä huolimatta pystyisin koodaamaan Delphillä laadukkaa forumsoftan, mutta kuka sen maksaisi. Ilmaistyönä enaio ryhtyä sitä tekemään.
Jos työlle löytyy maksaja, niin sitten voisi koodatakin.

Tyypillinen javakoodaaja laittaisi jokaisen forumviestin tietokantaan. Ja aina, kun lukija lataa sivun, niin tietokannasta haettaisiin jokainen samalla web -sivulla oleva viesti.
Kyllä se noinkin toimii, tosin suorituskyky on tuolla tavalla tehtynä surkea.

Mietipä tätä: jos (keskustelukejun sisältävä) web -sivu ladataan miljoona kertaa päivässä, ja yhdellä web -sivulla on keskimäärin 10 viestiä, niin tuo on 10 miljoonaa tietokantahakua päivässä.

On olemassa parempiakin tapoja tehdä keskusteluforumin toteutus, mutta ehän nämä Java-"osaajat" muuta osaa kuin kirjoittaa koodi helpoimmalla mahdollisella tavalla, ja sitten selitellä, että tarvitaan kuormantasausjärjestelmä, kun koodin suorituskyky on niin huono.

Delphillä tehtynä moista kuormantasausjärjestelmää ei ainakaan Suomen oloissa suomenkieliselle sisällölle tarvita.

JOS kohdeyleisönä olisi englantia puhuvat ihmiset maailmanlaajuisesti, sitten ehkä tarvittaisiin useampia palvelimia ja se kuormantasausjärjestelmä. Suomen alle 6 miljoonan populaatiolla ei tarvita.

Mutta kertokaa nyt joku: voisiko tuollaisen paremman forumsofta koodaamalla tienata mitään, ja jos, kuinka paljon ja kuka on maksaja?

Miettikää myös: Google Ads -palvelun varaan en laskisi mitään.
Miksi laittaa toimeentuoaan sen varaan, että

1) mainostilaa saadaan myytyä

JA

2) ettei Google täysin moraalittomasti kaappaa mainostuloja kokonaan itselleen siten, että Google odottaa mainostulojakson viimeiseen päivään, ja sitten sanoo, että sivustolla on Googlen ehtojen vastaista sisältöä.

Google on todella kiero firma. Jos Googlen mielestä web -sivulla on Googlen ehtojen vastaista sisältöä, niin sivuston omistaja ei saa koko jaksolta senttiäkään mainostuloja, jos Google ilmoittaa ehtojen vastaisesta sisällöstä sopimusjakson viimeisenä päivänä.
Silti Google itse pitää kaikki mainostulot, eikä palauta niitä mainostilasta maksaneille yritykselle.

Tuollaiset sopimusehdot mahdollistavat näennäisesti laillisen ryöstön.

Itse en laittaisi omalle sivulleni Googlen mainoksia missään olosuhteissa, juuri tuollaisten sopimusehtojen takia.

Niiden ehtojen pitäisi olla niin, että joko sivuston omistajalle maksetaan, tai sitten mainoshinta palautetaan kokonaisuudessaan maksajalle.

Tämä olisi reilu peli, mutta sehän ei Googlelle sovi.
Googlelle sopii vain se, että Google voi halutessaan kaapata mainostulot kokonaan itselleen, eli laskuttaa mainostavia yrityksiä, mutta olla maksamatta sivuston omistajalle ja perustella tätä "sääntörikkomuksella".

Anonyymi kirjoitti:

Jos tilaat laajan ohjelmiston, ja maksat siitä 200€ - 300 €, niin taatusti saat huonoa laatua!

Olen yllättynyt, jos edes saat koodaustyötä tuolla hintatasolla (luultavasti et saa).

Todennäköisemmin, joku hemmo Intiassa käy läpi valtavan määrän aiemmin koodattuja asioita, valitsee yhden niistä, ja esittelee tuotteeen tilaajalle "omanaan".

M-Karin päinvastaisista väitteistä huolimatta pystyisin koodaamaan Delphillä laadukkaa forumsoftan, mutta kuka sen maksaisi. Ilmaistyönä enaio ryhtyä sitä tekemään.
Jos työlle löytyy maksaja, niin sitten voisi koodatakin.

Tyypillinen javakoodaaja laittaisi jokaisen forumviestin tietokantaan. Ja aina, kun lukija lataa sivun, niin tietokannasta haettaisiin jokainen samalla web -sivulla oleva viesti.
Kyllä se noinkin toimii, tosin suorituskyky on tuolla tavalla tehtynä surkea.

Mietipä tätä: jos (keskustelukejun sisältävä) web -sivu ladataan miljoona kertaa päivässä, ja yhdellä web -sivulla on keskimäärin 10 viestiä, niin tuo on 10 miljoonaa tietokantahakua päivässä.

On olemassa parempiakin tapoja tehdä keskusteluforumin toteutus, mutta ehän nämä Java-"osaajat" muuta osaa kuin kirjoittaa koodi helpoimmalla mahdollisella tavalla, ja sitten selitellä, että tarvitaan kuormantasausjärjestelmä, kun koodin suorituskyky on niin huono.

Delphillä tehtynä moista kuormantasausjärjestelmää ei ainakaan Suomen oloissa suomenkieliselle sisällölle tarvita.

JOS kohdeyleisönä olisi englantia puhuvat ihmiset maailmanlaajuisesti, sitten ehkä tarvittaisiin useampia palvelimia ja se kuormantasausjärjestelmä. Suomen alle 6 miljoonan populaatiolla ei tarvita.

Mutta kertokaa nyt joku: voisiko tuollaisen paremman forumsofta koodaamalla tienata mitään, ja jos, kuinka paljon ja kuka on maksaja?

Miettikää myös: Google Ads -palvelun varaan en laskisi mitään.
Miksi laittaa toimeentuoaan sen varaan, että

1) mainostilaa saadaan myytyä

JA

2) ettei Google täysin moraalittomasti kaappaa mainostuloja kokonaan itselleen siten, että Google odottaa mainostulojakson viimeiseen päivään, ja sitten sanoo, että sivustolla on Googlen ehtojen vastaista sisältöä.

Google on todella kiero firma. Jos Googlen mielestä web -sivulla on Googlen ehtojen vastaista sisältöä, niin sivuston omistaja ei saa koko jaksolta senttiäkään mainostuloja, jos Google ilmoittaa ehtojen vastaisesta sisällöstä sopimusjakson viimeisenä päivänä.
Silti Google itse pitää kaikki mainostulot, eikä palauta niitä mainostilasta maksaneille yritykselle.

Tuollaiset sopimusehdot mahdollistavat näennäisesti laillisen ryöstön.

Itse en laittaisi omalle sivulleni Googlen mainoksia missään olosuhteissa, juuri tuollaisten sopimusehtojen takia.

Niiden ehtojen pitäisi olla niin, että joko sivuston omistajalle maksetaan, tai sitten mainoshinta palautetaan kokonaisuudessaan maksajalle.

Tämä olisi reilu peli, mutta sehän ei Googlelle sovi.
Googlelle sopii vain se, että Google voi halutessaan kaapata mainostulot kokonaan itselleen, eli laskuttaa mainostavia yrityksiä, mutta olla maksamatta sivuston omistajalle ja perustella tätä "sääntörikkomuksella".

Lue lisää

"Tyypillinen javakoodaaja laittaisi jokaisen forumviestin tietokantaan. Ja aina, kun lukija lataa sivun, niin tietokannasta haettaisiin jokainen samalla web -sivulla oleva viesti.
Kyllä se noinkin toimii, tosin suorituskyky on tuolla tavalla tehtynä surkea."

Ja sillä ei välttämättä ole merkitystä jos tietokanta on sellainen jota voidaan lukea mielin määrin. Et nähtävästi tunne tietokantoja.

Mutta jos asialla on väliä niin siihen laitetaan cache väliin.

"Mutta kertokaa nyt joku: voisiko tuollaisen paremman forumsofta koodaamalla tienata mitään, ja jos, kuinka paljon ja kuka on maksaja?"

Ei ainakaan silloin jos sen tekee Delphillä koska kukaan ei halua Delphillä tehtyä foorumisoftaa.

Anonyymi kirjoitti:

"Tyypillinen javakoodaaja laittaisi jokaisen forumviestin tietokantaan. Ja aina, kun lukija lataa sivun, niin tietokannasta haettaisiin jokainen samalla web -sivulla oleva viesti.
Kyllä se noinkin toimii, tosin suorituskyky on tuolla tavalla tehtynä surkea."

Ja sillä ei välttämättä ole merkitystä jos tietokanta on sellainen jota voidaan lukea mielin määrin. Et nähtävästi tunne tietokantoja.

Mutta jos asialla on väliä niin siihen laitetaan cache väliin.

"Mutta kertokaa nyt joku: voisiko tuollaisen paremman forumsofta koodaamalla tienata mitään, ja jos, kuinka paljon ja kuka on maksaja?"

Ei ainakaan silloin jos sen tekee Delphillä koska kukaan ei halua Delphillä tehtyä foorumisoftaa.

Lue lisää

Väite:

"Ei ainakaan silloin jos sen tekee Delphillä koska kukaan ei halua Delphillä tehtyä foorumisoftaa."

Totuus:

"Ei ainakaan silloin jos sen tekee Delphillä koska M-KAR ei halua Delphillä tehtyä foorumisoftaa."

Mutta jos systeemiä pyörittäisi itse eikä ottaisi jotain ulkopuolista tekijää sitä pyörittämään, niin loppukäyttäjät olisivat erittäin tyytyväisiä Delphillä tehtyyn toteutukseen - koska suorituskyky on silloin ylivoimaisesti parempi, joten sivunlataukset sujuvat todella vauhdilla.

Ja niille, jotka eivät käytä selaimella, vaan lataavat sivustolta sivuston tarjoaman EXE -tiedoston, käyttökokemus on vieläkin sujuvampi, ja RAM -muistinkulutus on pieni murto-osa siitä, mitä se on selaimella käytettäessä.

Delphillä tehtynä: käyttäjä voi ladata 1000 viestiä, eikä se kuormita palvelinta enempää kuin Java -toteutuksessa 10 viestin lataaminen.

M-Kar valehtelee, kuten aina.

Ilmeisesti pitäisi vaan itse myydä mainostilaa eikä päästää Googlen kaltaisia välistävetäjiä apajille.

Sehän on sitten mainostavista yrityksistä kiinni, mikä yritys ostaa mainostilaa ja mikä ei.

Voisi tietty tehdä niin, että jos isot yritykset eivät halua mainostaa, niin siinä vaiheessa kun tuollainen ilmiö havaitaan, niin myydään mainostilaa alehinnalla pienyrityksille.

Siinähän avautuu monelle pienyritykselle mahdollisuus samalla kasvaa isommaksi.

Jos forumista tulee suosittu, voi maikkarin "kasvupaketti" jäädä toiseksi !

Tuohon auttaisi se, että liitetiedostojen liittäminen, ellei sitten ylipäätään viestien lähettäminen, vaatisi rekisteröitymisen, jolloin moderointi voisi jakaa jäähyjä tai lukita käyttäjätilin asiattomuuksista. Tietoturvamielessä ehkä liitetiedostojen tiedostomuotoja voisi ehkä rajata. Liitetiedostoja ongelmallisempana pitäisi linkkejä ulkopuolisille saiteille, niiden turvallisuutta kun käsittääkseni olisi lähes mahdotonta valvoa.

Itseasiassa tarkennuksena se, että kyseessä ei ollut pelkkä webbifoorumiohjelmisto, vaan ennemminkin täysi yleiskäyttöinen webbiportaali- ja foorumiohjelmisto. Eli keskustelufoorumiominaiisuudet oli vain osa sitä mitä kehitin. Mutta sille kävi sitten tosiaan huonosti kovalevyn hajottua jne.

T. miksuh

Anonyymi kirjoitti:

Itseasiassa tarkennuksena se, että kyseessä ei ollut pelkkä webbifoorumiohjelmisto, vaan ennemminkin täysi yleiskäyttöinen webbiportaali- ja foorumiohjelmisto. Eli keskustelufoorumiominaiisuudet oli vain osa sitä mitä kehitin. Mutta sille kävi sitten tosiaan huonosti kovalevyn hajottua jne.

T. miksuh

Lue lisää

Kiitoksia kokemuksesi jakamisesta! Itse aikoinaan menetin sähköposteja useamman vuoden ajalta kun olin ottanut varmuuskopion imagena, muistaakseni vieläpä RAID-0-järjestelmästä, jota sitten en saanutkaan palautettua. Jos olisinkin käyttänyt kaupallista imagenotto-ohjelmaa, niin olisi imagebrowserilla voinut palautella yksittäin tiedostot imagesta, mutta kun käytin ilmaisohjelmaa, josta itselläni ei pahemmin ollut kokemusta, niin siinä ei moista toimintoa ollut. Tuo oli aikaa jolloin pidin viestit omalla koneellani ja vain siellä. Tuon jälkeen meni maku sähköpostiviestinnästä ja siirryin yksityisviestinnässäni sosiaaliseen mediaan ja "yritysviestinnässä" monikansallisiin web-pohjaisiin sähköpostipalveluihin, vaikkakin POP/IMAP-laatikko vielä itseltäni löytyy kotimaisella palvelutarjoajalla. Koodauksessa ja dokumenttien tuotosten varmuuskopioinnissa olenkin sitten ollut aina tarkkana - lienenkö joskus alussa menettänyt muutaman tunnin työn tulokset ja siitä jäänyt tarkkuus päälle.

Tällä hetkellä vaikuttaisi parhaimmin uuden foorumialustan kehittämiseen soveltuvan Rust-ohjelmointikieli, jolla onnistuisi niin asiakas- kuin palvelinpään softan teko. Asiakaspäässä voisi ohjelman kääntää WebAssemblyksi ja palvelinpäässä suoraan binääriksi. Välistä kun jättäisi pois kaiken ylimääräisen ja pitäisi tietoliikenteen minimaalisena, niin eiköhän suorituskykyä saisi suhteessa kaistaan ja rautaan kertaluokalla lisää.

Anonyymi kirjoitti:

Kiitoksia kokemuksesi jakamisesta! Itse aikoinaan menetin sähköposteja useamman vuoden ajalta kun olin ottanut varmuuskopion imagena, muistaakseni vieläpä RAID-0-järjestelmästä, jota sitten en saanutkaan palautettua. Jos olisinkin käyttänyt kaupallista imagenotto-ohjelmaa, niin olisi imagebrowserilla voinut palautella yksittäin tiedostot imagesta, mutta kun käytin ilmaisohjelmaa, josta itselläni ei pahemmin ollut kokemusta, niin siinä ei moista toimintoa ollut. Tuo oli aikaa jolloin pidin viestit omalla koneellani ja vain siellä. Tuon jälkeen meni maku sähköpostiviestinnästä ja siirryin yksityisviestinnässäni sosiaaliseen mediaan ja "yritysviestinnässä" monikansallisiin web-pohjaisiin sähköpostipalveluihin, vaikkakin POP/IMAP-laatikko vielä itseltäni löytyy kotimaisella palvelutarjoajalla. Koodauksessa ja dokumenttien tuotosten varmuuskopioinnissa olenkin sitten ollut aina tarkkana - lienenkö joskus alussa menettänyt muutaman tunnin työn tulokset ja siitä jäänyt tarkkuus päälle.

Tällä hetkellä vaikuttaisi parhaimmin uuden foorumialustan kehittämiseen soveltuvan Rust-ohjelmointikieli, jolla onnistuisi niin asiakas- kuin palvelinpään softan teko. Asiakaspäässä voisi ohjelman kääntää WebAssemblyksi ja palvelinpäässä suoraan binääriksi. Välistä kun jättäisi pois kaiken ylimääräisen ja pitäisi tietoliikenteen minimaalisena, niin eiköhän suorituskykyä saisi suhteessa kaistaan ja rautaan kertaluokalla lisää.

Lue lisää

Siis verrattuna tavanomaisiin LAMP-ympäristön toteutuksiin.

Anonyymi kirjoitti:

Kiitoksia kokemuksesi jakamisesta! Itse aikoinaan menetin sähköposteja useamman vuoden ajalta kun olin ottanut varmuuskopion imagena, muistaakseni vieläpä RAID-0-järjestelmästä, jota sitten en saanutkaan palautettua. Jos olisinkin käyttänyt kaupallista imagenotto-ohjelmaa, niin olisi imagebrowserilla voinut palautella yksittäin tiedostot imagesta, mutta kun käytin ilmaisohjelmaa, josta itselläni ei pahemmin ollut kokemusta, niin siinä ei moista toimintoa ollut. Tuo oli aikaa jolloin pidin viestit omalla koneellani ja vain siellä. Tuon jälkeen meni maku sähköpostiviestinnästä ja siirryin yksityisviestinnässäni sosiaaliseen mediaan ja "yritysviestinnässä" monikansallisiin web-pohjaisiin sähköpostipalveluihin, vaikkakin POP/IMAP-laatikko vielä itseltäni löytyy kotimaisella palvelutarjoajalla. Koodauksessa ja dokumenttien tuotosten varmuuskopioinnissa olenkin sitten ollut aina tarkkana - lienenkö joskus alussa menettänyt muutaman tunnin työn tulokset ja siitä jäänyt tarkkuus päälle.

Tällä hetkellä vaikuttaisi parhaimmin uuden foorumialustan kehittämiseen soveltuvan Rust-ohjelmointikieli, jolla onnistuisi niin asiakas- kuin palvelinpään softan teko. Asiakaspäässä voisi ohjelman kääntää WebAssemblyksi ja palvelinpäässä suoraan binääriksi. Välistä kun jättäisi pois kaiken ylimääräisen ja pitäisi tietoliikenteen minimaalisena, niin eiköhän suorituskykyä saisi suhteessa kaistaan ja rautaan kertaluokalla lisää.

Lue lisää

"Tällä hetkellä vaikuttaisi parhaimmin uuden foorumialustan kehittämiseen soveltuvan Rust-ohjelmointikieli, jolla onnistuisi niin asiakas- kuin palvelinpään softan teko. Asiakaspäässä voisi ohjelman kääntää WebAssemblyksi ja palvelinpäässä suoraan binääriksi. Välistä kun jättäisi pois kaiken ylimääräisen ja pitäisi tietoliikenteen minimaalisena, niin eiköhän suorituskykyä saisi suhteessa kaistaan ja rautaan kertaluokalla lisää."

Itseasiassa ei.

Backendin suorituskyvyssä ohjelmointikielen tasolla ratkaisee älyttömän paljon kuinka nopeasti käsittelee requesteja. Suorituskyvyn puolesta Java ja C# saadaan helposti nopeammaksi.

Ohjelmointikieltä enemmän merkitsee se missä muodossa data on. Eli onko relaatiodataa vai dokumenttidataa vai jotain muuta, ja miten skaalata tätä.

Suorituskykyä enemmän merkitsee käytännössä hostauskustannukset. Siellä se kanta juurikin on se mikä tekee kulua ja kevyemmissä jutuissa joku pieni relaatiokanta tulee helposti halvimmaksi. Tässä pitää huomioida myös kahdennus että kantapalvelimen vikaantuminen ei aiheuta ongelmia.

Toinen erittäin kiinnostava asia kulujen kannalta on se, että onko kuormitus tasaista vai ajoittaista, eli jos on ajoittaista niin helposti mieltä rakentaa serverlessiä ja suurin osa palvelimista pois käytöstä kun ei ole käyttöä.

Asiakaspäässä webassembly hidastaa, sillä ei taida vielä päästä suoraan tekemään kyselyjä palvelimelle jota suuri osa suorituksesta on. Ja koko webassembly ympäristön käynnistys ja kaikki venkslaus sen kanssa jokseenkin varmasti vain hidastaa ja tekee hankalammaksi. Foorumsofta todennäköisesti kannattaa tehdä backend painotteisesti, etenkin jos haluaa hakukoneiden pääsevän näkemään sisälle.

Anonyymi kirjoitti:

"Tällä hetkellä vaikuttaisi parhaimmin uuden foorumialustan kehittämiseen soveltuvan Rust-ohjelmointikieli, jolla onnistuisi niin asiakas- kuin palvelinpään softan teko. Asiakaspäässä voisi ohjelman kääntää WebAssemblyksi ja palvelinpäässä suoraan binääriksi. Välistä kun jättäisi pois kaiken ylimääräisen ja pitäisi tietoliikenteen minimaalisena, niin eiköhän suorituskykyä saisi suhteessa kaistaan ja rautaan kertaluokalla lisää."

Itseasiassa ei.

Backendin suorituskyvyssä ohjelmointikielen tasolla ratkaisee älyttömän paljon kuinka nopeasti käsittelee requesteja. Suorituskyvyn puolesta Java ja C# saadaan helposti nopeammaksi.

Ohjelmointikieltä enemmän merkitsee se missä muodossa data on. Eli onko relaatiodataa vai dokumenttidataa vai jotain muuta, ja miten skaalata tätä.

Suorituskykyä enemmän merkitsee käytännössä hostauskustannukset. Siellä se kanta juurikin on se mikä tekee kulua ja kevyemmissä jutuissa joku pieni relaatiokanta tulee helposti halvimmaksi. Tässä pitää huomioida myös kahdennus että kantapalvelimen vikaantuminen ei aiheuta ongelmia.

Toinen erittäin kiinnostava asia kulujen kannalta on se, että onko kuormitus tasaista vai ajoittaista, eli jos on ajoittaista niin helposti mieltä rakentaa serverlessiä ja suurin osa palvelimista pois käytöstä kun ei ole käyttöä.

Asiakaspäässä webassembly hidastaa, sillä ei taida vielä päästä suoraan tekemään kyselyjä palvelimelle jota suuri osa suorituksesta on. Ja koko webassembly ympäristön käynnistys ja kaikki venkslaus sen kanssa jokseenkin varmasti vain hidastaa ja tekee hankalammaksi. Foorumsofta todennäköisesti kannattaa tehdä backend painotteisesti, etenkin jos haluaa hakukoneiden pääsevän näkemään sisälle.

Lue lisää

Olipas siinä taas mutuilua jolta kulta millä ei ole mitään tietoa asiasta.

Anonyymi kirjoitti:

Olipas siinä taas mutuilua jolta kulta millä ei ole mitään tietoa asiasta.

Piti tarkistaa.

Nähtävästi Rustilla työnalla ollut ntex tullut tuotantovalmiiksi 2kk sitten. Tietyntyyppisissä, synteettisissä testeissä näkyy siinä olevan erinomaisen hyvät tulokset mutta Javapuoli sitten on näissä normaaleissa JSON serialisoinneissa kovempi.

Foorumiin nyt kuitenkin sitten tarvitaan vähän muitakin komponentteja kuin webservice, että käytännössä kaivataan joku autentikointi vaikka ja tosiaankin se on se tietokanta mikä tässä merkitsee enemmän.

Webassemblyyn on tulossa HTTP (wasi-http) mutta ei ole valmis, ja webassemblyssä siten on omat haittansa miksi se on väärä tekniikka foorumin tekoon.

Anonyymi kirjoitti:

"Tällä hetkellä vaikuttaisi parhaimmin uuden foorumialustan kehittämiseen soveltuvan Rust-ohjelmointikieli, jolla onnistuisi niin asiakas- kuin palvelinpään softan teko. Asiakaspäässä voisi ohjelman kääntää WebAssemblyksi ja palvelinpäässä suoraan binääriksi. Välistä kun jättäisi pois kaiken ylimääräisen ja pitäisi tietoliikenteen minimaalisena, niin eiköhän suorituskykyä saisi suhteessa kaistaan ja rautaan kertaluokalla lisää."

Itseasiassa ei.

Backendin suorituskyvyssä ohjelmointikielen tasolla ratkaisee älyttömän paljon kuinka nopeasti käsittelee requesteja. Suorituskyvyn puolesta Java ja C# saadaan helposti nopeammaksi.

Ohjelmointikieltä enemmän merkitsee se missä muodossa data on. Eli onko relaatiodataa vai dokumenttidataa vai jotain muuta, ja miten skaalata tätä.

Suorituskykyä enemmän merkitsee käytännössä hostauskustannukset. Siellä se kanta juurikin on se mikä tekee kulua ja kevyemmissä jutuissa joku pieni relaatiokanta tulee helposti halvimmaksi. Tässä pitää huomioida myös kahdennus että kantapalvelimen vikaantuminen ei aiheuta ongelmia.

Toinen erittäin kiinnostava asia kulujen kannalta on se, että onko kuormitus tasaista vai ajoittaista, eli jos on ajoittaista niin helposti mieltä rakentaa serverlessiä ja suurin osa palvelimista pois käytöstä kun ei ole käyttöä.

Asiakaspäässä webassembly hidastaa, sillä ei taida vielä päästä suoraan tekemään kyselyjä palvelimelle jota suuri osa suorituksesta on. Ja koko webassembly ympäristön käynnistys ja kaikki venkslaus sen kanssa jokseenkin varmasti vain hidastaa ja tekee hankalammaksi. Foorumsofta todennäköisesti kannattaa tehdä backend painotteisesti, etenkin jos haluaa hakukoneiden pääsevän näkemään sisälle.

Lue lisää

Rust on erään testin mukaan viisi kertaa nopeampi kuin Java mitä tulee JWT-sovelluksiin (https://medium.com/deno-the-complete-reference/java-vs-rust-how-faster-is-machine-code-compared-to-interpreted-code-for-jwt-sign-verify-fa6aeeabff58). Rustilla tehdyt ongelmat ovat nopeudeltaan periaatteessa c:n luokkaa, joskin teoriassa mahdollistaa jopa nopeamman koodin (ainakin kääntäjän kehittyessä: https://kornel.ski/rust-c-speed).

Noin minäkin olen ymmärtänyt, että tietokantakulut ovat yksi keskeisimmistä kuluista, ja siksi tällaisen kuluttajalle päin ilmaisen palvelun toteuttamisessa tärkeä minimoitava kulu. Mikäli palvelu rajoittuisi vain suomenkielisille käyttäjille, niin kuormitus olisi varsin epätasaista ja siten palvelua todennäköisesti kannattaisi pyörittää pilvessä, jossa kuormitus skaalautuisi alas- ja ylöspäin tarpeen mukaan.

Tuo heittoni WebAssemblyn käytöstä asiakaspäässä tuli lähinnä vain siitä, että Rustilla tuo onnistuisi. Sinällään asiakaspäässä suorituskyky ei tällaisessa sovellutuksessa ole mitenkään kriittinen, enemmänkin tietoturva ja tietoliikenteen minimointi. Tietoliikenteen minimointi onnistuu JavaScriptillä, vaan sen tietoturvapuolta jotkut ovat kyseenalaistaneet. Käyttäjäkokemus toki on erittäin tärkeää ja jos WebAssemblyn kanssa on samoin kuin aikoinaan Javan kanssa että JVM:n käynnistys kestää häiritsevän pitkään (tiedä mikä tilanne tänä päivänä, jos joku vielä Javaa käyttää asiakaspäässä), niin ei se sitten tulisi kyseeseen. Oma arvioni on, että WebAssembly tulee pikkuhiljaa saamaan merkittävän aseman - ellei peräti perusalustaksi asiakaspään sovellusten suorittamiseen ja selaimet tehdään sen mukaan.

Anonyymi kirjoitti:

Rust on erään testin mukaan viisi kertaa nopeampi kuin Java mitä tulee JWT-sovelluksiin (https://medium.com/deno-the-complete-reference/java-vs-rust-how-faster-is-machine-code-compared-to-interpreted-code-for-jwt-sign-verify-fa6aeeabff58). Rustilla tehdyt ongelmat ovat nopeudeltaan periaatteessa c:n luokkaa, joskin teoriassa mahdollistaa jopa nopeamman koodin (ainakin kääntäjän kehittyessä: https://kornel.ski/rust-c-speed).

Noin minäkin olen ymmärtänyt, että tietokantakulut ovat yksi keskeisimmistä kuluista, ja siksi tällaisen kuluttajalle päin ilmaisen palvelun toteuttamisessa tärkeä minimoitava kulu. Mikäli palvelu rajoittuisi vain suomenkielisille käyttäjille, niin kuormitus olisi varsin epätasaista ja siten palvelua todennäköisesti kannattaisi pyörittää pilvessä, jossa kuormitus skaalautuisi alas- ja ylöspäin tarpeen mukaan.

Tuo heittoni WebAssemblyn käytöstä asiakaspäässä tuli lähinnä vain siitä, että Rustilla tuo onnistuisi. Sinällään asiakaspäässä suorituskyky ei tällaisessa sovellutuksessa ole mitenkään kriittinen, enemmänkin tietoturva ja tietoliikenteen minimointi. Tietoliikenteen minimointi onnistuu JavaScriptillä, vaan sen tietoturvapuolta jotkut ovat kyseenalaistaneet. Käyttäjäkokemus toki on erittäin tärkeää ja jos WebAssemblyn kanssa on samoin kuin aikoinaan Javan kanssa että JVM:n käynnistys kestää häiritsevän pitkään (tiedä mikä tilanne tänä päivänä, jos joku vielä Javaa käyttää asiakaspäässä), niin ei se sitten tulisi kyseeseen. Oma arvioni on, että WebAssembly tulee pikkuhiljaa saamaan merkittävän aseman - ellei peräti perusalustaksi asiakaspään sovellusten suorittamiseen ja selaimet tehdään sen mukaan.

Lue lisää

Voi se jonkun JWT:n tekeminen tosiaankin CPU:ssa tuntua mutta käytännössä se on kokonaissuorituskyvyssä vähäistä.

C myös sellainen kieli, että kyllä se matalalla tasolla on nopea mutta käytännössä webservicejä tehdessä, ei ole. On itseasiassa tyyliin hitain se että palvelin käynnistä jotain cgi-bin kikkareita kun tehdään kyselyjä kun jokainen request käynnistää oman prosessin niin tehot menee siihen sitten.

Tietokantakulut tosiaankin on se mikä maksaa että edullisin tapa on yhden serverin vehje ja etenkin jos sinne ei kirjoiteta mitään vaan lähinnä luetaan niin 5€/kk SQLite palvelin mikä ei skaalaudu. Mutta kun pitää kirjoittaakin kuten foorumiviestit (kirjoitusoperaatiot lukitsee koko SQLite kannan) niin seuraava hintataso olisi vaikka joku PostgreSQL kanta ja se on muutenkin hyvä jos haluaa relaatioita. 10€/kk tms. minimissään hitain mahdollinen kantapalvelin ja sen keulilla sitten voi ajaa web palvelimia. Siihen vaan tarvitsee helposti vauhtia siihen ettei halvin riitä vauhtia voi hakea laittamalla siihen joku redis cachettamaan ettei tarvitse lukuoperaatioilla turhaan kuormittaa kantaa. SQL kannoilla horisontaalinen skaalaus hankalempaa.

NoSQL:t lähtee jostain 50€/kk minimissään mutta niitä skaalailee helposti. Relaatiot näissä sitten se hankaluus.

Ja riippuen mitä tekee niin voi tarvita useita kantoja riippuen mitä dataa niissä on. Ihan normaalia vaikka se että PostgreSQL missä käyttäjät ja relaatiomuotoinen data ja NoSQL sitten dokumenteille.

Tuossa tilanteen mukaan skaalautuvassa suorituksessa Java on sitten hyvä, helposti paras, ja JVM:n käynnistys ei ole ongelma koska skaalautuviin vehkeisiin Javaa saa käännettyä natiiviksi. Jatkuvasti päällä roksottavissa koneissa JVM saakin käynnistyä ja JVM toimii helposti tehokkaammin kuin natiiviksi käännetty kun siellä ei tehdä muistinvapausta muulloin kuin idlellä.

Javascriptin tietoturvassa ei ole ongelmaa mutta webassemblyn ongelmat asiakaspäässä sitten sitä, että accessibility vaiketa. Siinä myöskin ladataan client binäärinä mutta tällä hetkellä suorituskyvyt hukkautuisi siihen kun HTTP kyselyt tapahtuisi JS puolella kun se on vasta kehitysasteella webassemblyssä. Webassembly siis hidastaisi. Webassemly sitten on erittäin hyvä vaikka peleissä missä koko peli pyörii webassemblyssä ja piirtää canvasille, tai jos tekee jonkun moduulin mikä tekee raskaampaa laskentaa client puolella niin sen voi kääntää webassemblylle ja JS kutsuu sitä.

Eli itse tekisin niin että pääasiassa renderöisi tavaran palvelimessa mutta JS:ää voisi käyttää asiakaspuolella siihen että vähentää sivulatauksia. Esimerkiksi kun kirjoittaa viestin niin JS:llä lisää sen viestiketjuun samalla kun lähettää palvelimelle mutta ei sitten tee tähän turhaa sivulatausta.

Olennainen optimointi on se sivulatausten määrän vähentäminen mutta kun sieltä palvelimelta jotain tarvitsee ladata niin sivulataus itsessään ei ole ongelma vaan voi olla hyvinkin nopeata.

Suomi24:ssä sitten viestin lähetys mielestäni tekee sivulatauksen missä se kirjoitettu viesti tulee näkyviin niin tuo nyt tarpeettomasti tekee kuormaa joka viestinlähetyksessä.

Anonyymi kirjoitti:

Rust on erään testin mukaan viisi kertaa nopeampi kuin Java mitä tulee JWT-sovelluksiin (https://medium.com/deno-the-complete-reference/java-vs-rust-how-faster-is-machine-code-compared-to-interpreted-code-for-jwt-sign-verify-fa6aeeabff58). Rustilla tehdyt ongelmat ovat nopeudeltaan periaatteessa c:n luokkaa, joskin teoriassa mahdollistaa jopa nopeamman koodin (ainakin kääntäjän kehittyessä: https://kornel.ski/rust-c-speed).

Noin minäkin olen ymmärtänyt, että tietokantakulut ovat yksi keskeisimmistä kuluista, ja siksi tällaisen kuluttajalle päin ilmaisen palvelun toteuttamisessa tärkeä minimoitava kulu. Mikäli palvelu rajoittuisi vain suomenkielisille käyttäjille, niin kuormitus olisi varsin epätasaista ja siten palvelua todennäköisesti kannattaisi pyörittää pilvessä, jossa kuormitus skaalautuisi alas- ja ylöspäin tarpeen mukaan.

Tuo heittoni WebAssemblyn käytöstä asiakaspäässä tuli lähinnä vain siitä, että Rustilla tuo onnistuisi. Sinällään asiakaspäässä suorituskyky ei tällaisessa sovellutuksessa ole mitenkään kriittinen, enemmänkin tietoturva ja tietoliikenteen minimointi. Tietoliikenteen minimointi onnistuu JavaScriptillä, vaan sen tietoturvapuolta jotkut ovat kyseenalaistaneet. Käyttäjäkokemus toki on erittäin tärkeää ja jos WebAssemblyn kanssa on samoin kuin aikoinaan Javan kanssa että JVM:n käynnistys kestää häiritsevän pitkään (tiedä mikä tilanne tänä päivänä, jos joku vielä Javaa käyttää asiakaspäässä), niin ei se sitten tulisi kyseeseen. Oma arvioni on, että WebAssembly tulee pikkuhiljaa saamaan merkittävän aseman - ellei peräti perusalustaksi asiakaspään sovellusten suorittamiseen ja selaimet tehdään sen mukaan.

Lue lisää

"Rustilla tehdyt ongelmat ovat nopeudeltaan periaatteessa c:n luokkaa, joskin teoriassa mahdollistaa jopa nopeamman koodin"

Tarkoittanet OHJELMIA kuitenkin? Hyvä Rust-kääntäjä voi tuottaa koodia, joka vastaa nopeudeltaan C-kielestä käännettyä, uskon tämän. Mutta teoriasi jopa nopeammasta koodista on yhtä uskottava kuin raketti, joka lentää valoa nopeammin.

Anonyymi kirjoitti:

Voi se jonkun JWT:n tekeminen tosiaankin CPU:ssa tuntua mutta käytännössä se on kokonaissuorituskyvyssä vähäistä.

C myös sellainen kieli, että kyllä se matalalla tasolla on nopea mutta käytännössä webservicejä tehdessä, ei ole. On itseasiassa tyyliin hitain se että palvelin käynnistä jotain cgi-bin kikkareita kun tehdään kyselyjä kun jokainen request käynnistää oman prosessin niin tehot menee siihen sitten.

Tietokantakulut tosiaankin on se mikä maksaa että edullisin tapa on yhden serverin vehje ja etenkin jos sinne ei kirjoiteta mitään vaan lähinnä luetaan niin 5€/kk SQLite palvelin mikä ei skaalaudu. Mutta kun pitää kirjoittaakin kuten foorumiviestit (kirjoitusoperaatiot lukitsee koko SQLite kannan) niin seuraava hintataso olisi vaikka joku PostgreSQL kanta ja se on muutenkin hyvä jos haluaa relaatioita. 10€/kk tms. minimissään hitain mahdollinen kantapalvelin ja sen keulilla sitten voi ajaa web palvelimia. Siihen vaan tarvitsee helposti vauhtia siihen ettei halvin riitä vauhtia voi hakea laittamalla siihen joku redis cachettamaan ettei tarvitse lukuoperaatioilla turhaan kuormittaa kantaa. SQL kannoilla horisontaalinen skaalaus hankalempaa.

NoSQL:t lähtee jostain 50€/kk minimissään mutta niitä skaalailee helposti. Relaatiot näissä sitten se hankaluus.

Ja riippuen mitä tekee niin voi tarvita useita kantoja riippuen mitä dataa niissä on. Ihan normaalia vaikka se että PostgreSQL missä käyttäjät ja relaatiomuotoinen data ja NoSQL sitten dokumenteille.

Tuossa tilanteen mukaan skaalautuvassa suorituksessa Java on sitten hyvä, helposti paras, ja JVM:n käynnistys ei ole ongelma koska skaalautuviin vehkeisiin Javaa saa käännettyä natiiviksi. Jatkuvasti päällä roksottavissa koneissa JVM saakin käynnistyä ja JVM toimii helposti tehokkaammin kuin natiiviksi käännetty kun siellä ei tehdä muistinvapausta muulloin kuin idlellä.

Javascriptin tietoturvassa ei ole ongelmaa mutta webassemblyn ongelmat asiakaspäässä sitten sitä, että accessibility vaiketa. Siinä myöskin ladataan client binäärinä mutta tällä hetkellä suorituskyvyt hukkautuisi siihen kun HTTP kyselyt tapahtuisi JS puolella kun se on vasta kehitysasteella webassemblyssä. Webassembly siis hidastaisi. Webassemly sitten on erittäin hyvä vaikka peleissä missä koko peli pyörii webassemblyssä ja piirtää canvasille, tai jos tekee jonkun moduulin mikä tekee raskaampaa laskentaa client puolella niin sen voi kääntää webassemblylle ja JS kutsuu sitä.

Eli itse tekisin niin että pääasiassa renderöisi tavaran palvelimessa mutta JS:ää voisi käyttää asiakaspuolella siihen että vähentää sivulatauksia. Esimerkiksi kun kirjoittaa viestin niin JS:llä lisää sen viestiketjuun samalla kun lähettää palvelimelle mutta ei sitten tee tähän turhaa sivulatausta.

Olennainen optimointi on se sivulatausten määrän vähentäminen mutta kun sieltä palvelimelta jotain tarvitsee ladata niin sivulataus itsessään ei ole ongelma vaan voi olla hyvinkin nopeata.

Suomi24:ssä sitten viestin lähetys mielestäni tekee sivulatauksen missä se kirjoitettu viesti tulee näkyviin niin tuo nyt tarpeettomasti tekee kuormaa joka viestinlähetyksessä.

Lue lisää

"C myös sellainen kieli, että kyllä se matalalla tasolla on nopea mutta käytännössä webservicejä tehdessä, ei ole. On itseasiassa tyyliin hitain se että palvelin käynnistä jotain cgi-bin kikkareita kun tehdään kyselyjä kun jokainen request käynnistää oman prosessin niin tehot menee siihen sitten."

Tuohan ei ole C-kielen heikkous lainkaan. Jos "palvelin käynnistä jotain cgi-bin kikkareita", vika on C-koodin kirjoittajassa. Siis jos se on vika eikä ominaisuus.

C-kieli tuottaa assemblerin jälkeen todennäköisesti tehokkainta koodia millä tahansa "tasolla". Tehokkainta eli nopeinta, tiiveintä tai mitä tahansa halutaankaan siltä väliltä. Mutta eihän kukaan kirjoita mitään tietokantakyselyjä C-kielellä tai assemblerilla varsinkaan, jos siihen on tuottavampia työkaluja käytettävissä.

Kuten totesit, C-kieli on matalan tason ohjelmointikieli. Tietokantakyselyjen teko sillä onnistuu kuten millä tahansa muulla kielellä, mutta koodaaminen on piinallisen työlästä ja aikaaviepää. Kokemusta on!

Anonyymi kirjoitti:

"C myös sellainen kieli, että kyllä se matalalla tasolla on nopea mutta käytännössä webservicejä tehdessä, ei ole. On itseasiassa tyyliin hitain se että palvelin käynnistä jotain cgi-bin kikkareita kun tehdään kyselyjä kun jokainen request käynnistää oman prosessin niin tehot menee siihen sitten."

Tuohan ei ole C-kielen heikkous lainkaan. Jos "palvelin käynnistä jotain cgi-bin kikkareita", vika on C-koodin kirjoittajassa. Siis jos se on vika eikä ominaisuus.

C-kieli tuottaa assemblerin jälkeen todennäköisesti tehokkainta koodia millä tahansa "tasolla". Tehokkainta eli nopeinta, tiiveintä tai mitä tahansa halutaankaan siltä väliltä. Mutta eihän kukaan kirjoita mitään tietokantakyselyjä C-kielellä tai assemblerilla varsinkaan, jos siihen on tuottavampia työkaluja käytettävissä.

Kuten totesit, C-kieli on matalan tason ohjelmointikieli. Tietokantakyselyjen teko sillä onnistuu kuten millä tahansa muulla kielellä, mutta koodaaminen on piinallisen työlästä ja aikaaviepää. Kokemusta on!

Lue lisää

"C-kieli tuottaa assemblerin jälkeen todennäköisesti tehokkainta koodia millä tahansa "tasolla". Tehokkainta eli nopeinta, tiiveintä tai mitä tahansa halutaankaan siltä väliltä. "

Tuota pitäisi arvioida niin, että kun kirjoittaa koodin mahdollisimman siististi että mikä se suorituskyky on silloin, eikä niin että kirjoitetaan koodista epäselvempää optimoimalla nopeutta.

Kun työvälineistä puuttuu tietyt helpottavat asiat niin sellainen selkeän näköinen C toteutus ei mitenkään selvästi ole enää nopein. Usein esimerkiksi Haskellilla tehdyt ohjelmat toimivat nopeammin kuin mitä C:llä tehty vastaava siisti koodi on, kun Haskell mahdollistaa rajumpia optimointeja automaattisesti mistä ohjelmoijan ei tarvitse välittää.

Anonyymi kirjoitti:

"C-kieli tuottaa assemblerin jälkeen todennäköisesti tehokkainta koodia millä tahansa "tasolla". Tehokkainta eli nopeinta, tiiveintä tai mitä tahansa halutaankaan siltä väliltä. "

Tuota pitäisi arvioida niin, että kun kirjoittaa koodin mahdollisimman siististi että mikä se suorituskyky on silloin, eikä niin että kirjoitetaan koodista epäselvempää optimoimalla nopeutta.

Kun työvälineistä puuttuu tietyt helpottavat asiat niin sellainen selkeän näköinen C toteutus ei mitenkään selvästi ole enää nopein. Usein esimerkiksi Haskellilla tehdyt ohjelmat toimivat nopeammin kuin mitä C:llä tehty vastaava siisti koodi on, kun Haskell mahdollistaa rajumpia optimointeja automaattisesti mistä ohjelmoijan ei tarvitse välittää.

Lue lisää

Kirjoitit: "Tuota pitäisi arvioida niin, että kun kirjoittaa koodin mahdollisimman siististi että mikä se suorituskyky on silloin, eikä niin että kirjoitetaan koodista epäselvempää optimoimalla nopeutta."

Sinulla saattaa olla hyvää kokemusta Haskellista ja ehkä muistakin korkean tason ohjelmointikielistä. Mutta C-kielen tuntemuksesi ei vakuuta.

Koodista puheenollen, siisti on ylläpidon kannalta ilman muuta parempi kuin epäselvä. Siistillä C-koodilla vain ei ole mitään tekemistä suorituskyvyn kanssa. Äärimmäisen suorituskykyinen C-koodi voi olla supersiistiä ja vastaavasti siistiltä näyttävä koodi voi olla kelvotonta kökköä.

C-koodaajan täytyy yleensä tietää miten kääntäjä koodin tulkitsee. Esimerkiksi osoittimen käytöllä tietyssä tilanteessa versus indeksoinnilla saattaa olla merkittävä vaikutus lopputulokseen. Erityisen tärkeää tämä on sulautetuissa koodeissa, joissa resurssit ovat niukat. Jollei C-koodaaja osaa lukea kääntäjän tuottamaa listausta, kökköä syntyy väistämättä.

C on siis matalan tason ohjelmointikieli, "symbolinen assembler", joka häviää koodaamisen helppoudessa ja tuottavuudessa jokseenkin kaikille korkean tason ohjelmointikielille. Mutta parempaan, siis tehokkaampaan lopputulokseen - millä mittarilla tahansa - yltäviä ohjelmointikieliä on vain yksi: Assembler.

Ole ystävällinen ja kerro esimerkki vaikkapa Haskell-koodista, joka "rajusti optimoituna" tuottaa nopeammin toimivaa koodia kuin "selkeän näköinen C toteutus" niin osoitan mielelläni luulosi vääräksi. Pidetään koodi inhimillisessä mitassa kuitenkin.

Anonyymi kirjoitti:

Kirjoitit: "Tuota pitäisi arvioida niin, että kun kirjoittaa koodin mahdollisimman siististi että mikä se suorituskyky on silloin, eikä niin että kirjoitetaan koodista epäselvempää optimoimalla nopeutta."

Sinulla saattaa olla hyvää kokemusta Haskellista ja ehkä muistakin korkean tason ohjelmointikielistä. Mutta C-kielen tuntemuksesi ei vakuuta.

Koodista puheenollen, siisti on ylläpidon kannalta ilman muuta parempi kuin epäselvä. Siistillä C-koodilla vain ei ole mitään tekemistä suorituskyvyn kanssa. Äärimmäisen suorituskykyinen C-koodi voi olla supersiistiä ja vastaavasti siistiltä näyttävä koodi voi olla kelvotonta kökköä.

C-koodaajan täytyy yleensä tietää miten kääntäjä koodin tulkitsee. Esimerkiksi osoittimen käytöllä tietyssä tilanteessa versus indeksoinnilla saattaa olla merkittävä vaikutus lopputulokseen. Erityisen tärkeää tämä on sulautetuissa koodeissa, joissa resurssit ovat niukat. Jollei C-koodaaja osaa lukea kääntäjän tuottamaa listausta, kökköä syntyy väistämättä.

C on siis matalan tason ohjelmointikieli, "symbolinen assembler", joka häviää koodaamisen helppoudessa ja tuottavuudessa jokseenkin kaikille korkean tason ohjelmointikielille. Mutta parempaan, siis tehokkaampaan lopputulokseen - millä mittarilla tahansa - yltäviä ohjelmointikieliä on vain yksi: Assembler.

Ole ystävällinen ja kerro esimerkki vaikkapa Haskell-koodista, joka "rajusti optimoituna" tuottaa nopeammin toimivaa koodia kuin "selkeän näköinen C toteutus" niin osoitan mielelläni luulosi vääräksi. Pidetään koodi inhimillisessä mitassa kuitenkin.

Lue lisää

"Sinulla saattaa olla hyvää kokemusta Haskellista ja ehkä muistakin korkean tason ohjelmointikielistä. Mutta C-kielen tuntemuksesi ei vakuuta."

Olen ohjelmoinut C:llä 29 vuotta. Tunnen sen läpeensä.

"Siistillä C-koodilla vain ei ole mitään tekemistä suorituskyvyn kanssa."

Sitten et ole ymmärtänyt ohjelmoinnin perusteita.

Ei lähdekoodia kirjoiteta tietokonetta varten vaan ihmisiä varten. Se että käydään tekemään sotkuisemmin asioita jonkun suorituskyvyn takia on hyvin poikkeuksellista ja silloin on syytä epäillä onko työkalu edes oikein valittu.

Suorituskyky kun ei ole tietokoneissa mikään ongelma.

"Ole ystävällinen ja kerro esimerkki vaikkapa Haskell-koodista, joka "rajusti optimoituna" tuottaa nopeammin toimivaa koodia kuin "selkeän näköinen C toteutus" niin osoitan mielelläni luulosi vääräksi."

Siis jos tehdään lähdekoodi niin, että sitä on mahdollisimman selkeätä lukea, mikä on täysin normaalia ohjelmointia, tekemällä samoja asioita C:llä ja Haskellilla antaa Haskell suorituskykyetua joissakin tilanteissa.

Syynä on yksinkertaisesti se, että C:llä ohjelmointi on sitä, että on varmistin pois päältä ja sillä voi ampua jalkaan. Sen sijaan Haskellissa kieli mahdollistaa sen, että kääntäjä pystyy tekemään turvallisia oletuksia rikkomatta toiminallisuutta.

Noin esimerkkinä, C:llä on mahdollista tehdä vaikka miljoonan alkion tietorakenne ja tehdä siitä kopio ja muokata kopiota. C:ssä on kopiointia varten esimerkiksi kutsu memcpy()

Kääntäjä tietenkin tekee sen kopioinnin kun ohjelmoija on niin käskenyt koska ohjelman oikea toiminta edellyttää sitä. Haskellissa kääntäjä voi käsitellä asioita automaattisesti viittauksina kopioimatta mitään. Kääntäjä tietää aina milloin missäkin muistipaikassa muutoksella on väliä.

Toinen esimerkki liittyisi suoritusjärjestykseen. C kielisissä ohjelmissa aika normaalisti funktion alussa tehdään alustuksia, avataan tiedosto että saa tiedostokahvan ja jne. ja käännettäessä ne tehdään pääpiirteissään näin.

Haskell sen sijaan evaluoi mitä tahansa lauseketta vasta silloin kun tarvitaan ja tuo tapahtuu automaattisesti. Kun käsitellään suurempia datamääriä, tuo Haskellin tapa voi olla automaattisesti tehokkaampi mutta tuo ei ole niin selkeä tilanne.

Tässä näistä vähän tarkemmin selitetty: https://www.dremio.com/wiki/eager-evaluation/

Haskell siis toimii automaattisesti lazy evaluationilla.

En minä nyt sano, että Haskell olisi aina parempi ja helposti Haskellilla voi tehdä hitaammankin softan, että lähtökohta olisi se, että pyritään kirjoittamaan softa niin selkeästi luettavaksi kuin mahdollista. Työkalu sitten valitaan tilanteen mukaan, että mikä siihen sopii parhaiten.

C ei ole automaattisesti tee nopeinta koodia.. Eihän sitä tarvitse kuin tehdä C++:lla niin voi lopputulos voi olla helpommin nopeampi kun tässä on nimiavaruudet, että ei tee mieli samalla tavalla palastella ohjelmia erillisiin prosesseihin. Tietenkin se C:n tapa tehdä ohjelmia taas rinnakkaistuu automaattisesti mutta se että palasteltu useaan prosessiin voi viedä tehoja.

Ei ne eri välineiden suorituskykyerot oikeasti tule vastaan kun tekee pikkuohjelmia. Hyvin yksinkertaisissa Hello Worldeissa C nyt onkin hyvä mutta sitten kun on kompleksisuutta niin pitää ymmärtää se miten se tehdään välineellä yksinkertaisimmin ja millaiset asiat tekee häviötä suorituskyvyssä. Joissakin välineissä kun nimenomaisesti on ratkottu jotain tarvetta.

Ei C oikein kivasti esimerkiksi sovellu myöskään kaikentyyppisiin asioihin. Hyvä esimerkki vaikka on Whatsappin koneisto millä niitä viestiä välitetään. 140 miljardia viestiä päivässä. Ja se lisäksi on toimii niin, että vaikka raudassa olisi ollut pieni häiriö niin toiminta ei keskeydy. Tai että kaatuisi kun paljon käyttäjiä.

Temppu on ratkottu tavukoodikoneella jossa jokainen yhteys on oma prosessi ja jos se mistä tahansa syystä toimii väärin niin kyseisen yhteyden prosessi vaan tapetaan ja käynnistetään uusiksi. C:llä tuollaisen rakentaminen vaatii aika paljon enemmän koodirivejä kuin käyttää kieltä joka tuollaisen mahdollistaa kielen ominaisuutena.

Eli ei tässä mitään ihmeellsitä ole, että valitsee vaan työkalun sen mukaan mitä sillä on tarkoitus tehdä että saa koodin kirjoitettua siististi.

Anonyymi kirjoitti:

Voi se jonkun JWT:n tekeminen tosiaankin CPU:ssa tuntua mutta käytännössä se on kokonaissuorituskyvyssä vähäistä.

C myös sellainen kieli, että kyllä se matalalla tasolla on nopea mutta käytännössä webservicejä tehdessä, ei ole. On itseasiassa tyyliin hitain se että palvelin käynnistä jotain cgi-bin kikkareita kun tehdään kyselyjä kun jokainen request käynnistää oman prosessin niin tehot menee siihen sitten.

Tietokantakulut tosiaankin on se mikä maksaa että edullisin tapa on yhden serverin vehje ja etenkin jos sinne ei kirjoiteta mitään vaan lähinnä luetaan niin 5€/kk SQLite palvelin mikä ei skaalaudu. Mutta kun pitää kirjoittaakin kuten foorumiviestit (kirjoitusoperaatiot lukitsee koko SQLite kannan) niin seuraava hintataso olisi vaikka joku PostgreSQL kanta ja se on muutenkin hyvä jos haluaa relaatioita. 10€/kk tms. minimissään hitain mahdollinen kantapalvelin ja sen keulilla sitten voi ajaa web palvelimia. Siihen vaan tarvitsee helposti vauhtia siihen ettei halvin riitä vauhtia voi hakea laittamalla siihen joku redis cachettamaan ettei tarvitse lukuoperaatioilla turhaan kuormittaa kantaa. SQL kannoilla horisontaalinen skaalaus hankalempaa.

NoSQL:t lähtee jostain 50€/kk minimissään mutta niitä skaalailee helposti. Relaatiot näissä sitten se hankaluus.

Ja riippuen mitä tekee niin voi tarvita useita kantoja riippuen mitä dataa niissä on. Ihan normaalia vaikka se että PostgreSQL missä käyttäjät ja relaatiomuotoinen data ja NoSQL sitten dokumenteille.

Tuossa tilanteen mukaan skaalautuvassa suorituksessa Java on sitten hyvä, helposti paras, ja JVM:n käynnistys ei ole ongelma koska skaalautuviin vehkeisiin Javaa saa käännettyä natiiviksi. Jatkuvasti päällä roksottavissa koneissa JVM saakin käynnistyä ja JVM toimii helposti tehokkaammin kuin natiiviksi käännetty kun siellä ei tehdä muistinvapausta muulloin kuin idlellä.

Javascriptin tietoturvassa ei ole ongelmaa mutta webassemblyn ongelmat asiakaspäässä sitten sitä, että accessibility vaiketa. Siinä myöskin ladataan client binäärinä mutta tällä hetkellä suorituskyvyt hukkautuisi siihen kun HTTP kyselyt tapahtuisi JS puolella kun se on vasta kehitysasteella webassemblyssä. Webassembly siis hidastaisi. Webassemly sitten on erittäin hyvä vaikka peleissä missä koko peli pyörii webassemblyssä ja piirtää canvasille, tai jos tekee jonkun moduulin mikä tekee raskaampaa laskentaa client puolella niin sen voi kääntää webassemblylle ja JS kutsuu sitä.

Eli itse tekisin niin että pääasiassa renderöisi tavaran palvelimessa mutta JS:ää voisi käyttää asiakaspuolella siihen että vähentää sivulatauksia. Esimerkiksi kun kirjoittaa viestin niin JS:llä lisää sen viestiketjuun samalla kun lähettää palvelimelle mutta ei sitten tee tähän turhaa sivulatausta.

Olennainen optimointi on se sivulatausten määrän vähentäminen mutta kun sieltä palvelimelta jotain tarvitsee ladata niin sivulataus itsessään ei ole ongelma vaan voi olla hyvinkin nopeata.

Suomi24:ssä sitten viestin lähetys mielestäni tekee sivulatauksen missä se kirjoitettu viesti tulee näkyviin niin tuo nyt tarpeettomasti tekee kuormaa joka viestinlähetyksessä.

Lue lisää

Itseäni houkuttaisi ajatus, että varsinaista sessionhallintaa ei olisi, vaan vain uusien viestien lisääminen (poistaminen yms.) vaatisi "kirjautumisen" toiminnon suorittamiseksi. Kirjautuminen edellä siis tarkoittaa vain käyttäjätunnuksen ja salasanan syöttämistä sen varmistamiseksi, että kyseisellä käyttäjällä on oikeus kyseiseen toimintoon. Mitään sessiota ei kuitenkaan muodostettaisi ja sama "kirjautuminen" pitäisi muodostaa vaikka heti perään, jos käyttäjä haluaa tehdä uuden lisäyksen tai poiston. Ehkäpä tämä "kirjautuminen" hoituisi käytännöllisemmin JavaScriptillä muodostettavalla yksittäisellä merkkijonolla, joka muodostettaisiin käyttäjätunnuksesta ja salasanasta, ja jota säilytettäisiin session ajan asiakaspäässä eli käytössä olisi tosiasiallisesti asiakaspään sessionhallinta. Tuo merkkijono pitäisi toki salakirjoittaa turvallisella tavalla, mikä puolestaan kävisi kätevimmin SSL-yhteyden kanssa, mikä taasen vaatisi oikean sessionhallinnan, ja hupsista, ollaan aika raskaassa järjestelmässä, ja ristiriidassa viestin ensimmäisessä lauseessa ilmaistun kanssa. :D Toki SSL-yhteyskin voisi olla uusi jokaista sivun latausta ja lähetystä kohti, vaan olisiko siinä sitten juurikaan järkeä...

Anonyymi kirjoitti:

"Rustilla tehdyt ongelmat ovat nopeudeltaan periaatteessa c:n luokkaa, joskin teoriassa mahdollistaa jopa nopeamman koodin"

Tarkoittanet OHJELMIA kuitenkin? Hyvä Rust-kääntäjä voi tuottaa koodia, joka vastaa nopeudeltaan C-kielestä käännettyä, uskon tämän. Mutta teoriasi jopa nopeammasta koodista on yhtä uskottava kuin raketti, joka lentää valoa nopeammin.

Lue lisää

Heh, toki; tiedä mistä 'ongelmat' tupsahti sijaan. Kun tarkemmin luin linkkaamaani artikkelia, niin pitänee tulkita niin päin, että teoriassa c:llä voi päästä samaan nopeuteen kuin Rustilla, mutta käytännössä kuka jaksaa viilata koodia niin pitkälle. Tekstissä https://kornel.ski/rust-c-speed kerrottiin lukuisia esimerkkejä tilanteista joissa Rust-koodi on nopeampaa, mutta oli mukana myös esimerkkejä niistä joissa Rust puolestaan ei ole vahvoilla. Tässä muutama esimerkki:

"Strings have their size encoded in their "fat" pointer. This makes length checks fast, eliminates risk of accidental O(n²) string loops, and allows making substrings in-place (e.g. splitting a string into tokens) without modifying memory or copying to add the \0 terminator."

"Like C++ templates, Rust generates copies of generic code for each type they're used with, so functions like sort() and containers like hash tables are always optimized for their type. In C I have to choose between hacks with macros or less efficient functions that work on void* and run-time variable sizes."

"Rust iterators can be combined into chains that get optimized together as one unit. So instead of a series of calls buy(it); use(it); break(it); change(it); mail(upgrade(it)); that may end up rewriting the same buffer many times, I can call it.buy().use().break().change().upgrade().mail() that compiles to one buy_use_break_change_mail_upgrade(it) optimized to do all of that in a single combined pass. (0..1000).map(|x| x*2).sum() compiles to return 999000."

"Similarly, there are Read and Write interfaces that allow functions to stream unbuffered data. They combine nicely, so I can write data to a stream that calculates CRC of the data on the fly, adds framing/escaping if needed, compresses it, and writes it to the network, all in one call. And I can pass such combined stream as an output stream to my HTML templating engine, so now each HTML tag will be smart enough to send itself compressed. The underlying mechanism is just a pyramid of plain next_stream.write(bytes) calls, so technically nothing stops me from doing the same in C, except the lack of traits and generics in C means it's very hard to actually do that in practice, other than with callbacks set up at run time, which isn't as efficient."

"These days everything seems to require JSON. Rust's serde is one of the fastest JSON parsers in the world, and it parses directly into Rust structs, so use of the parsed data is very fast and efficient, too."

Kommentteja valikoiden edellisii postauksiin.

Kirjoitit: "Olen ohjelmoinut C:llä 29 vuotta. Tunnen sen läpeensä."

Kommentointisi ei tue väitettä. C-kieli on helppo osata, mutta vaikea täysin hallita. Aina löytyy jokin uusi ahaa-elämys ja tämän totean ainakin yhtä pitkällä kokemuksella. Enkä voi vieläkään väittää tuntevani C-kieltä läpeensä ja siksi pyrinkin pitämään mieleni avoinna uusille näkökulmille ja jopa kritiikille.

Kirjoitit: "Ei lähdekoodia kirjoiteta tietokonetta varten vaan ihmisiä varten. [--] Suorituskyky kun ei ole tietokoneissa mikään ongelma."

Oikein ja väärin. Jos koodia täytyy ylläpitää tai uudelleenkäyttää, luettavuus on kaikki kaikessa. PC-ympäristössä suorituskyky harvoin on ongelma. Joskus kuitenkin on. Ja jos kirjoitat esimerkiksi uudelleenkäytettävää kirjastokoodia, huonon koodin suorituskyky voi nousta ongelmaksi arvaamattomalla tavalla myöhemmin. Sulautetussa maailmassa suorituskyky on aina huomioitava tekijä, koska rautaa ei haluta mitoittaa yhtään tehokkaammaksi eli kalliimaksi kuin on välttämätöntä.

Kirjoitit: "Syynä on yksinkertaisesti se, että C:llä ohjelmointi on sitä, että on varmistin pois päältä ja sillä voi ampua jalkaan."

En löytänyt pointtiasi. C on matalan tason ohjelmointikieli, siinä ei ole varmistinta. Rajattoman vallan mukana tulee vastuu, koodaajan täytyy tietää mitä tekee,

Kirjoitit: "Haskell sen sijaan evaluoi mitä tahansa lauseketta vasta silloin kun tarvitaan ja tuo tapahtuu automaattisesti."

C-kielessä koodaaja päättää mitä ohjelma tekee ja hyvä niin. Nykyiset kääntäjät ovat kuitenkin erittäin fiksuja ja jos annat kääntäjälle valtuudet esimerkiksi muuttaa suoritusjärjestystä, se toimii kokemusteni mukaan erittäin hyvin. Suoritusjärjestystä ei tietenkään saa muuttaa niin, että sillä on toiminnallista vakutusta tai edes sivuvaikutuksia. Esimerkiksi semaforin varaamisen ja jaettuun resurssiin sattumisen järjestystä ei pidä muuttaa. Kääntäjällähän ei välttämättä ole mitään tietoa tällaisten objektien luonteesta tai suhteesta toisiinsa.

En tunne Haskellia, mutta uskon, että lazy evaluation saattaa toimia tiettyjen järjestelmäresurssien kanssa, mutta merkittävää etua tästä optimoinnista on kovin vaikeaa nähdä.

Kirjoitit: "Ei C oikein kivasti esimerkiksi sovellu myöskään kaikentyyppisiin asioihin."

Tämä on päivänselvää. C-kielessä ja sillä koodaamisessa on heikkoutensa ja siksi meillä on laaja kirjo erilaisia haskelleita. Mutta keskustelumme lähti suoritustehokkuusnäkökulmasta, jos muistan, ja siinä suhteessa C-kielelle ei ole voittajaa. Extremistien assembleria lukuunottamatta.

Kirjoitit: "teoriassa c:llä voi päästä samaan nopeuteen kuin Rustilla".

Mitähän ovat tämän mielipiteen perustelut? Olisi hauska nähdä onko tässä vertailtu omenoita ja appelsiineja, mutta mikään tiedossani oleva ei tue väitettä.

Kirjoitit: ""Strings have their size encoded in their "fat" pointer. This makes length checks fast, eliminates risk of accidental O(n²) string loops, and allows making substrings in-place (e.g. splitting a string into tokens) without modifying memory or copying to add the \0 terminator.""

Merkkijonot voidaan toteuttaa monella tavoin. Kaksi tavanomaisinta tapaa ovat C-string ja P-string. Ensinmainitussa käytetään terminointimerkkiä ja jälkimmäisessä talletettua pituustietoa. Haskellissa on tietääkseni oma toteutuksensa (linkitetty lista), mutta kaikilla näillä on hyvät ja huonot puolensa, ei ole yksiselitteisesti yhtä voittajaa.

On totta, että C-string aiheuttaa tehottomuutta tietyisä tilanteissa. Esimerkiksi qsort() funktiota käytettäessä, jolloin jokaisen vertailuoperaation yhteydessä täytyy laskea toisen merkkijonon pituus. Tämä koskee mm. Intel-yhteensopivia prossuja, kun vertailu tehdään sinänsä tehokasta REP-käskyä käyttäen. Pituustieto tarvitaan ennen vertaluun ryhtymistä.

Jos sovellus käyttää runsaasti merkkijonoja, C-koodaajan tulee harkita käyttää P-string totetusta. Tässä onkin se C-kielen tehokkuuden salaisuus: ohjelmointikieli asettaa hyvin vähän rajoituksia. Koodaajalla on vapaus valita tehokkain tai nopein totetustapa tai mitä tahansa näiden väliltä.

C-standardi ei tunne merkkijonotyyppiä. On vain "array of char" ja sen terminointimerkillä varustettu muoto, jota standardikirjasto tukee. Mikään ei estä määrittelemästä omaa datatyyppiä, esimerkiksi...

typedef struct { size_t len; char s[]; } myString_t;

...ja sille funktioita. Jos merkkijono s[] talletaan edelleen C-string muodossa, saavutetaan lisäetua mm. merkkijonojen vertalussa. Tällöin esimerkiksi qsort() kutsuisi strcmp() funktion sijaan funktiota (tässä tapauksessa makroa):

#define myStrcmp(a,b) memcmp((a)->s, (b)->s, ((a)->len + 1) * sizeof(char))

Kirjoitit: ""Like C++ templates, Rust generates copies of generic code for each type they're used with, so functions like sort() and containers like hash tables are always optimized for their type [--]""

Tuo sekä muut vertailut C- ja Rust-kielen välillä ontuvat. Kielten suorituskyvystä oli kyse, kirjastojen kattavuus on eri asia.

Anonyymi kirjoitti:

Itseäni houkuttaisi ajatus, että varsinaista sessionhallintaa ei olisi, vaan vain uusien viestien lisääminen (poistaminen yms.) vaatisi "kirjautumisen" toiminnon suorittamiseksi. Kirjautuminen edellä siis tarkoittaa vain käyttäjätunnuksen ja salasanan syöttämistä sen varmistamiseksi, että kyseisellä käyttäjällä on oikeus kyseiseen toimintoon. Mitään sessiota ei kuitenkaan muodostettaisi ja sama "kirjautuminen" pitäisi muodostaa vaikka heti perään, jos käyttäjä haluaa tehdä uuden lisäyksen tai poiston. Ehkäpä tämä "kirjautuminen" hoituisi käytännöllisemmin JavaScriptillä muodostettavalla yksittäisellä merkkijonolla, joka muodostettaisiin käyttäjätunnuksesta ja salasanasta, ja jota säilytettäisiin session ajan asiakaspäässä eli käytössä olisi tosiasiallisesti asiakaspään sessionhallinta. Tuo merkkijono pitäisi toki salakirjoittaa turvallisella tavalla, mikä puolestaan kävisi kätevimmin SSL-yhteyden kanssa, mikä taasen vaatisi oikean sessionhallinnan, ja hupsista, ollaan aika raskaassa järjestelmässä, ja ristiriidassa viestin ensimmäisessä lauseessa ilmaistun kanssa. :D Toki SSL-yhteyskin voisi olla uusi jokaista sivun latausta ja lähetystä kohti, vaan olisiko siinä sitten juurikaan järkeä...

Lue lisää

No siis, JWT on keksitty. Haittansa siinäkin jos tokenin saa joku muu käsiinsä, että kaiksissa tilanteissa ei toimi.

Anonyymi kirjoitti:

Kommentteja valikoiden edellisii postauksiin.

Kirjoitit: "Olen ohjelmoinut C:llä 29 vuotta. Tunnen sen läpeensä."

Kommentointisi ei tue väitettä. C-kieli on helppo osata, mutta vaikea täysin hallita. Aina löytyy jokin uusi ahaa-elämys ja tämän totean ainakin yhtä pitkällä kokemuksella. Enkä voi vieläkään väittää tuntevani C-kieltä läpeensä ja siksi pyrinkin pitämään mieleni avoinna uusille näkökulmille ja jopa kritiikille.

Kirjoitit: "Ei lähdekoodia kirjoiteta tietokonetta varten vaan ihmisiä varten. [--] Suorituskyky kun ei ole tietokoneissa mikään ongelma."

Oikein ja väärin. Jos koodia täytyy ylläpitää tai uudelleenkäyttää, luettavuus on kaikki kaikessa. PC-ympäristössä suorituskyky harvoin on ongelma. Joskus kuitenkin on. Ja jos kirjoitat esimerkiksi uudelleenkäytettävää kirjastokoodia, huonon koodin suorituskyky voi nousta ongelmaksi arvaamattomalla tavalla myöhemmin. Sulautetussa maailmassa suorituskyky on aina huomioitava tekijä, koska rautaa ei haluta mitoittaa yhtään tehokkaammaksi eli kalliimaksi kuin on välttämätöntä.

Kirjoitit: "Syynä on yksinkertaisesti se, että C:llä ohjelmointi on sitä, että on varmistin pois päältä ja sillä voi ampua jalkaan."

En löytänyt pointtiasi. C on matalan tason ohjelmointikieli, siinä ei ole varmistinta. Rajattoman vallan mukana tulee vastuu, koodaajan täytyy tietää mitä tekee,

Kirjoitit: "Haskell sen sijaan evaluoi mitä tahansa lauseketta vasta silloin kun tarvitaan ja tuo tapahtuu automaattisesti."

C-kielessä koodaaja päättää mitä ohjelma tekee ja hyvä niin. Nykyiset kääntäjät ovat kuitenkin erittäin fiksuja ja jos annat kääntäjälle valtuudet esimerkiksi muuttaa suoritusjärjestystä, se toimii kokemusteni mukaan erittäin hyvin. Suoritusjärjestystä ei tietenkään saa muuttaa niin, että sillä on toiminnallista vakutusta tai edes sivuvaikutuksia. Esimerkiksi semaforin varaamisen ja jaettuun resurssiin sattumisen järjestystä ei pidä muuttaa. Kääntäjällähän ei välttämättä ole mitään tietoa tällaisten objektien luonteesta tai suhteesta toisiinsa.

En tunne Haskellia, mutta uskon, että lazy evaluation saattaa toimia tiettyjen järjestelmäresurssien kanssa, mutta merkittävää etua tästä optimoinnista on kovin vaikeaa nähdä.

Kirjoitit: "Ei C oikein kivasti esimerkiksi sovellu myöskään kaikentyyppisiin asioihin."

Tämä on päivänselvää. C-kielessä ja sillä koodaamisessa on heikkoutensa ja siksi meillä on laaja kirjo erilaisia haskelleita. Mutta keskustelumme lähti suoritustehokkuusnäkökulmasta, jos muistan, ja siinä suhteessa C-kielelle ei ole voittajaa. Extremistien assembleria lukuunottamatta.

Kirjoitit: "teoriassa c:llä voi päästä samaan nopeuteen kuin Rustilla".

Mitähän ovat tämän mielipiteen perustelut? Olisi hauska nähdä onko tässä vertailtu omenoita ja appelsiineja, mutta mikään tiedossani oleva ei tue väitettä.

Kirjoitit: ""Strings have their size encoded in their "fat" pointer. This makes length checks fast, eliminates risk of accidental O(n²) string loops, and allows making substrings in-place (e.g. splitting a string into tokens) without modifying memory or copying to add the \0 terminator.""

Merkkijonot voidaan toteuttaa monella tavoin. Kaksi tavanomaisinta tapaa ovat C-string ja P-string. Ensinmainitussa käytetään terminointimerkkiä ja jälkimmäisessä talletettua pituustietoa. Haskellissa on tietääkseni oma toteutuksensa (linkitetty lista), mutta kaikilla näillä on hyvät ja huonot puolensa, ei ole yksiselitteisesti yhtä voittajaa.

On totta, että C-string aiheuttaa tehottomuutta tietyisä tilanteissa. Esimerkiksi qsort() funktiota käytettäessä, jolloin jokaisen vertailuoperaation yhteydessä täytyy laskea toisen merkkijonon pituus. Tämä koskee mm. Intel-yhteensopivia prossuja, kun vertailu tehdään sinänsä tehokasta REP-käskyä käyttäen. Pituustieto tarvitaan ennen vertaluun ryhtymistä.

Jos sovellus käyttää runsaasti merkkijonoja, C-koodaajan tulee harkita käyttää P-string totetusta. Tässä onkin se C-kielen tehokkuuden salaisuus: ohjelmointikieli asettaa hyvin vähän rajoituksia. Koodaajalla on vapaus valita tehokkain tai nopein totetustapa tai mitä tahansa näiden väliltä.

C-standardi ei tunne merkkijonotyyppiä. On vain "array of char" ja sen terminointimerkillä varustettu muoto, jota standardikirjasto tukee. Mikään ei estä määrittelemästä omaa datatyyppiä, esimerkiksi...

typedef struct { size_t len; char s[]; } myString_t;

...ja sille funktioita. Jos merkkijono s[] talletaan edelleen C-string muodossa, saavutetaan lisäetua mm. merkkijonojen vertalussa. Tällöin esimerkiksi qsort() kutsuisi strcmp() funktion sijaan funktiota (tässä tapauksessa makroa):

#define myStrcmp(a,b) memcmp((a)->s, (b)->s, ((a)->len 1) * sizeof(char))

Kirjoitit: ""Like C templates, Rust generates copies of generic code for each type they're used with, so functions like sort() and containers like hash tables are always optimized for their type [--]""

Tuo sekä muut vertailut C- ja Rust-kielen välillä ontuvat. Kielten suorituskyvystä oli kyse, kirjastojen kattavuus on eri asia.

Lue lisää

"Kommentointisi ei tue väitettä. C-kieli on helppo osata, mutta vaikea täysin hallita. Aina löytyy jokin uusi ahaa-elämys ja tämän totean ainakin yhtä pitkällä kokemuksella."

No ei kyllä löydy. Sehän on hyvin yksinkertainen kieli.

Ja optimointijutut liittyen C:n on enemmänkin sitä hardware tason juttua että viilailee koodia toimimaan sen mukaan miten rauta toimii.

Itse C on niin yksinkertainen kieli että se on hyvin helppo hallita läpeensä.

"Ja jos kirjoitat esimerkiksi uudelleenkäytettävää kirjastokoodia, huonon koodin suorituskyky voi nousta ongelmaksi arvaamattomalla tavalla myöhemmin."

Nimenomaan ei tule. Tekemällä koodin siististi, sitä on helppo muuttaa jos jotain tarvetta tulee ja ei sitten käytä aikaa hinkkaamaan jotain yksittäisen osan suorituskykyä vaan keskittyy tekemään koko ohjelman siististi, valmiiksi ja pyrkiä virheettömyyteen.

Yleensä se suorituskyky ei vaan ole mikään ongelma kun valitsee työkalut ja tavat tilanteen mukaan ja tekee siististi ja välttää tekemästä jotain hölmöä. Hölmöydet huomaa juurikin silloin paremmin kun tekee siististi.

"Sulautetussa maailmassa suorituskyky on aina huomioitava tekijä, koska rautaa ei haluta mitoittaa yhtään tehokkaammaksi eli kalliimaksi kuin on välttämätöntä."

No just parhaillaan teen sulautettuun koodia. Pythonilla. Koska helpoiten valmiiksi ja tässä kohtaa ei tarvitse kun ei ole massatuotantoa. Kerätään kaikki vaatimukset ensiksi ennen kuin aletaan tekemään parempaa versiota.

"En löytänyt pointtiasi. C on matalan tason ohjelmointikieli, siinä ei ole varmistinta. Rajattoman vallan mukana tulee vastuu, koodaajan täytyy tietää mitä tekee,"

Se myös tarkoittaa sitä, että kääntäjän on käännettävä koodi sillä tavalla kuin ohjelmoija on sen kirjoittanut, tekemällä vaikka memcpy:llä joku hillitön kopiointi.

"Suoritusjärjestystä ei tietenkään saa muuttaa niin, että sillä on toiminnallista vakutusta tai edes sivuvaikutuksia."

Nyt alat päästä jäljille. Haskellissa ei oletuksena koodia kirjoitettaessa tule mitään sivuvaikutuksia muualla kuin tarkoin määritetysti, tyyliin niin että eristetään koodissa vaikka tiedoston käyttö.

Sitten kaikki mitä lasketaan niin kääntäjällä on vapaat kädet optimoida hurjilla tavoilla kun sillä on tieto, että ei ole sivuvaikutuksia. C:stä tämä puuttuu.

"Mutta keskustelumme lähti suoritustehokkuusnäkökulmasta, jos muistan, ja siinä suhteessa C-kielelle ei ole voittajaa. "

Kyllä on kun lähtökohtana on se, että kirjoitetaan softa siististi.

Siksi niinkin tavallisen asian kuin web servicen tekeminen onkin C:llä tehotonta kun ei ole niin optimoitua toteutusta.

Yksi suorituskykyyn vaikuttava asia on esimerkiksi roskien kerääjä, että se toimii joissakin tilanteissa nopeammin kuin manuaalinen muistinhallinta. C:llä ei järkevästi onnistu se, että kutsut free() silloin kun kone on idlellä. Roskien kerääjää käyttävillä kielillä runtime osaa tehdä tuota. Ihan puhtaassa yksinkertaisessa suorituksessakin Zig kääntää tehokkaampaa koodia.

Oikeasti C:n vahvuus ei ole suorituskyvyssä vaan se on ennemminkin siinä, että optimoidaan muistin käyttöä suorituskyvyn sijasta tehdään jotain sellaista jossa voi käyttää C:n vahvuuksia, kuten tietyntasoiset verifioinnit.

"Tässä onkin se C-kielen tehokkuuden salaisuus: ohjelmointikieli asettaa hyvin vähän rajoituksia. Koodaajalla on vapaus valita tehokkain tai nopein totetustapa tai mitä tahansa näiden väliltä."

Ja sitten on tavukoodivehkeitä optimoivat automaattisesti kohderaudalle....

Anonyymi kirjoitti:

No siis, JWT on keksitty. Haittansa siinäkin jos tokenin saa joku muu käsiinsä, että kaiksissa tilanteissa ei toimi.

Ahaa, eipä ole tullutkaan aiemmin varsinaisesti tuohon tutustuttua, muutoin kuin että eräs sessionhallintatekniikka kyseessä. Kiitoksia infosta.

Anonyymi kirjoitti:

Kirjoitit: "Tuota pitäisi arvioida niin, että kun kirjoittaa koodin mahdollisimman siististi että mikä se suorituskyky on silloin, eikä niin että kirjoitetaan koodista epäselvempää optimoimalla nopeutta."

Sinulla saattaa olla hyvää kokemusta Haskellista ja ehkä muistakin korkean tason ohjelmointikielistä. Mutta C-kielen tuntemuksesi ei vakuuta.

Koodista puheenollen, siisti on ylläpidon kannalta ilman muuta parempi kuin epäselvä. Siistillä C-koodilla vain ei ole mitään tekemistä suorituskyvyn kanssa. Äärimmäisen suorituskykyinen C-koodi voi olla supersiistiä ja vastaavasti siistiltä näyttävä koodi voi olla kelvotonta kökköä.

C-koodaajan täytyy yleensä tietää miten kääntäjä koodin tulkitsee. Esimerkiksi osoittimen käytöllä tietyssä tilanteessa versus indeksoinnilla saattaa olla merkittävä vaikutus lopputulokseen. Erityisen tärkeää tämä on sulautetuissa koodeissa, joissa resurssit ovat niukat. Jollei C-koodaaja osaa lukea kääntäjän tuottamaa listausta, kökköä syntyy väistämättä.

C on siis matalan tason ohjelmointikieli, "symbolinen assembler", joka häviää koodaamisen helppoudessa ja tuottavuudessa jokseenkin kaikille korkean tason ohjelmointikielille. Mutta parempaan, siis tehokkaampaan lopputulokseen - millä mittarilla tahansa - yltäviä ohjelmointikieliä on vain yksi: Assembler.

Ole ystävällinen ja kerro esimerkki vaikkapa Haskell-koodista, joka "rajusti optimoituna" tuottaa nopeammin toimivaa koodia kuin "selkeän näköinen C toteutus" niin osoitan mielelläni luulosi vääräksi. Pidetään koodi inhimillisessä mitassa kuitenkin.

Lue lisää

Delphillä homman saisi tehtyä tietoturvallisesti (esim: ei YHTÄÄN puskurin ylivuotohaavoittuvuutta, eikä toki SQL -pistoksia myöskään).

C:llä jos koodaat saman, niin taatusti mukaan tulee puskurin ylivuotohaavoittuvuuksia.
Eli jos koodaat C:llä, on vain ajan kysymys, milloin joku hakkeri löytää koodista puskurin ylivuotohaavoittuvuuden, jonka avulla hakkeri voi syöttää systeemiin omaa koodiaan suoritettavaksi.

Ja mikä hakkerin kannalta parasta: ns. "No Execute" flag prosessorissa ei auta tietoturvaa yhtään (toki se tekee hyökkäyksestä hieman vaativamman toteuttaa, mutta ei tee siitä mahdotonta).

Miksi?

Jos et tiedä miksi, niin tutustu aiheeseen "ROP = Return Oriented Programming".

Käsittääkseni joku on tehnyt ROP -skannerin, joka osaa etsiä systeemikoodista sellaisia osia, jotka voi lukuisilla RET -käskyillä linkittää toisiinsa, ja josta hakkeri voi koota haluamansa kokonaisuuden.

Onko tuo systeemi jo täysautomaattinen, vai vieläkö ollaan puoliautomaattisen tasolla, sitä en ole ehtinyt seurata.

Anonyymi kirjoitti:

Delphillä homman saisi tehtyä tietoturvallisesti (esim: ei YHTÄÄN puskurin ylivuotohaavoittuvuutta, eikä toki SQL -pistoksia myöskään).

C:llä jos koodaat saman, niin taatusti mukaan tulee puskurin ylivuotohaavoittuvuuksia.
Eli jos koodaat C:llä, on vain ajan kysymys, milloin joku hakkeri löytää koodista puskurin ylivuotohaavoittuvuuden, jonka avulla hakkeri voi syöttää systeemiin omaa koodiaan suoritettavaksi.

Ja mikä hakkerin kannalta parasta: ns. "No Execute" flag prosessorissa ei auta tietoturvaa yhtään (toki se tekee hyökkäyksestä hieman vaativamman toteuttaa, mutta ei tee siitä mahdotonta).

Miksi?

Jos et tiedä miksi, niin tutustu aiheeseen "ROP = Return Oriented Programming".

Käsittääkseni joku on tehnyt ROP -skannerin, joka osaa etsiä systeemikoodista sellaisia osia, jotka voi lukuisilla RET -käskyillä linkittää toisiinsa, ja josta hakkeri voi koota haluamansa kokonaisuuden.

Onko tuo systeemi jo täysautomaattinen, vai vieläkö ollaan puoliautomaattisen tasolla, sitä en ole ehtinyt seurata.

Lue lisää

"Delphillä homman saisi tehtyä tietoturvallisesti (esim: ei YHTÄÄN puskurin ylivuotohaavoittuvuutta, eikä toki SQL -pistoksia myöskään)."

Delphin käyttämä kieli ei millään tavalla estä SQL injektioita.

Eikä mitään foorumialustoja tehdä sen enempää C:llä kuin Delphillä, aivan vääriä työkaluja.

"Eli jos koodaat C:llä, on vain ajan kysymys, milloin joku hakkeri löytää koodista puskurin ylivuotohaavoittuvuuden, jonka avulla hakkeri voi syöttää systeemiin omaa koodiaan suoritettavaksi."

C:llä voi kirjoittaa verifioitua koodia missä ei ole mahdollista tapahtua puskurin ylivuotoja.

Anonyymi kirjoitti:

"Delphillä homman saisi tehtyä tietoturvallisesti (esim: ei YHTÄÄN puskurin ylivuotohaavoittuvuutta, eikä toki SQL -pistoksia myöskään)."

Delphin käyttämä kieli ei millään tavalla estä SQL injektioita.

Eikä mitään foorumialustoja tehdä sen enempää C:llä kuin Delphillä, aivan vääriä työkaluja.

"Eli jos koodaat C:llä, on vain ajan kysymys, milloin joku hakkeri löytää koodista puskurin ylivuotohaavoittuvuuden, jonka avulla hakkeri voi syöttää systeemiin omaa koodiaan suoritettavaksi."

C:llä voi kirjoittaa verifioitua koodia missä ei ole mahdollista tapahtua puskurin ylivuotoja.

Lue lisää

Ilmeisesti tänne jälleen kerran tupsahti M-Kar jauhamaan paskaa (kuten aina).

Mutta heitänpä tähän kysymyksen:

JOS koodaisin Delphillä hieman vastaavan systeemin kuin suom24 keskustelu on, niin:

MITEN voin ansaita rahaa tällä ?

Päinvastoin:
Jotta palveluun saataisiin käyttäjiä, sitä pitäisi mainostaa jossain.
Ja mainonta ei ole halpaa, se maksaa paljon!

Yksi asia on varma:
Tänne suomi24:lle on viime aikoina joku häirikkö postannut tuhansittain seksisivustoja mainostavia viestejä.

Esimerkiksi tällaisia linkkejä on havaittu (ÄLÄ klikkaa - tarjolla voi olla esim. haittaohjelmia):

Sarah Harrell
N­y­­m­f­o­m­a­a­n­­i -> https://x18.fun/girl01834670#SarahHarrell

Miten voi olla ylläpidolle noin vaikeaa torjua nuo ?

Toisaalta:

JOS joku menee klikkaamaan moista linkkiä, niin miten noiden linkkien massapostaaja hyötyy noista ?

Jollei sitten linkki mene jollekin maksulliselle seksisivustolle, mutta JOS menee, niin 99,9% klikkailijoista ei mitään maksa, koska netissä on tarjolla ilmaisseksisivustojakin vaikka millä mitalla, eli pornoa on katseltavissa ilmaiseksi sille, joka pornoa haluaa.

Tuossa joku asiaa ymmärtämätön valittelee, miten pitää olla joku monimutkainen sessionhallintatapa, ja väittää, ettei Delphissä ole sille frameworkia.

Tyypillistä ajattelua ihmiseltä, joka ei osaa itse koodata sessionhallintaa, vaan olettaa, että monimutkainen framework on tarpeen.

Tosiasiassa tuon voi hoitaa yksinkertaisemminkin, eikä sen kirjoittaminen itse Delphillä todellakaan ole vaikeaa, eikä edes kovin aikaavievää.

Lisäksi: vaikka kaikki suomalaiset käyttäisivät forumia, niin Delphin suorituskyky todennäköisesti riittää siihen, että kaikki pyörii yhdellä tietokoneella, ei siis tarvetta kuormantasausjärjestelmille.

Ainoastaan lainvastainen häiriköinti voi vaatia enemmän palvelintehoa, mutta silloin on siis kyse selkeästi laittomasta toiminnasta, joka on rangaistava teko (tietoliikenteen häirintä on rikoslain mukaan rikos).

Oikein toteutettu sessionhallinta auttaa tässäkin:
Vaikka kaikki datapaketit joudutaan vastaanottamaan, niin oikein tehdyssä sessionhallinnassa verifioimaton paketti tunnistetaan nopeasti, jolloin sille ei tehdä sen enempää käsittelyä, vaan se hylätään heti vastaanoton jälkeen, jolloin sen aiheuttama kuormitus on minimaalista.

Hölmö koodaaja tekee tietokantahaun aina, eli onko käyttäjätunnus ja salasana oikea.
Onneksi fiksu koodaaja voi toimia toisinkin, eikä vaadi tietokantahakua sen selvittäminen, onko ko. postaus autentikoitu vai ei.

Delphi antaa tähän erinomaiset mahdollisuudet, ja koodin nopeus on sellainen, että Java -ratkaisussa 20 konetta yhteensä häviää nopeudessa yhdelle koneelle, jossa ajetaan Delphillä fiksusti koodattua ohjelmaa.

Eli Delphi -koodaajalla ei tässä ole mitään teknistä ongelmaa, enemmäkin ongelma on se, että miten keskusteluforumilla voi mitään tienata, kun käyttäjät odottavat palvelun olevan ilmainen.

Google ads on muuten harvinaisen huono idea.
Googlea pidän mafian tapaan toimivana tahona.

Eli jos Googlen mielestä sivu ei sovi Googlen normistoon, niin sivulla mainosnäytöt toimivat silti normaalisti (ja Google laskuttaa mainostavia yrityksiä mainostilasta).

Sitten kun olisi aika Googlen maksaa sivuston omistajille, niin eivät maksa, ja väittävät, että sivusto ei täytä Google normeja.

Tässä sivuston omistaja on heikoilla, kun Google siis ensin jatkaa mainosten näyttämistä ja laskuttaa ne omilta asiakkailtaan, mutta raha ei päädy sivuston omistajalle asti.

Ilmeisesti mainostila pitäisi myydä sivustolle itse, ei käyttää Googlen kaltaisia moraalittomia välistävetäjiä.

Tehoaako "Sinun yrityksesi mainos tässä - klikkaa tästä nähdäksesi lisätietoja" -tyyppiset mainokset siten, että päästäisiin tekemään suora sopimus sivuston omistajan ja mainostavan yrityksen välillä ?

Voi nimittäin olla ainoa keino varmistaa, ettei näytetä sellaisia mainoksia, joista sivuston omistaja ei saa mitään.

Varsinkin, jos keskusteluforumi sallii seksiaiheisia viestejä, niin Google mielellään käyttää tuota tekosyynä em. kaltaiselle mainoshuijaukselle, jossa Google hyötyy ja sivuston omistaja ei hyödy.

Lisäksi:
Tiesittekö, että netissä on firmoja, jotka maksavat mainosten klikkailusta palkkaa ?

Jos kaikki osapuolet toimisivat rehellisesti, tuollaisille firmoille ei olisi mitään tarvetta.

Mutta jos Google sopii jokun yrityksen kanssa vaikkapa, että yritys maksaa Googlelle 1€ joka kerta, kun joku klikkaa ko. yrityksen mainosta, mitä tapahtuu ?

Sopiiko Google tuollaisen "palkkaa mainosklikkailusta" -yrityksen kanssa siitä, että tuon yrityksen työntekijä klikkailee mainoksia, ja mainoksen laittanut asiakasyritys maksaa 1€ per klikkaus, josta tietenkin Google saa 0,70€, tuo pikkufirma ottaa 0,20€ ja työntekijälle jää 0,10€, josta pitää tietenkin maksaa verot - tällaista kuviota ainakin vahvasti epäilen.

Jos tuollaista kuviota ei olisi, miksi mikään yritys maksaisi palkkaa mainosten klikkailemisista ?

Anonyymi kirjoitti:

Ilmeisesti tänne jälleen kerran tupsahti M-Kar jauhamaan paskaa (kuten aina).

Mutta heitänpä tähän kysymyksen:

JOS koodaisin Delphillä hieman vastaavan systeemin kuin suom24 keskustelu on, niin:

MITEN voin ansaita rahaa tällä ?

Päinvastoin:
Jotta palveluun saataisiin käyttäjiä, sitä pitäisi mainostaa jossain.
Ja mainonta ei ole halpaa, se maksaa paljon!

Yksi asia on varma:
Tänne suomi24:lle on viime aikoina joku häirikkö postannut tuhansittain seksisivustoja mainostavia viestejä.

Esimerkiksi tällaisia linkkejä on havaittu (ÄLÄ klikkaa - tarjolla voi olla esim. haittaohjelmia):

Sarah Harrell
N­y­­m­f­o­m­a­a­n­­i -> https://x18.fun/girl01834670#SarahHarrell

Miten voi olla ylläpidolle noin vaikeaa torjua nuo ?

Toisaalta:

JOS joku menee klikkaamaan moista linkkiä, niin miten noiden linkkien massapostaaja hyötyy noista ?

Jollei sitten linkki mene jollekin maksulliselle seksisivustolle, mutta JOS menee, niin 99,9% klikkailijoista ei mitään maksa, koska netissä on tarjolla ilmaisseksisivustojakin vaikka millä mitalla, eli pornoa on katseltavissa ilmaiseksi sille, joka pornoa haluaa.

Tuossa joku asiaa ymmärtämätön valittelee, miten pitää olla joku monimutkainen sessionhallintatapa, ja väittää, ettei Delphissä ole sille frameworkia.

Tyypillistä ajattelua ihmiseltä, joka ei osaa itse koodata sessionhallintaa, vaan olettaa, että monimutkainen framework on tarpeen.

Tosiasiassa tuon voi hoitaa yksinkertaisemminkin, eikä sen kirjoittaminen itse Delphillä todellakaan ole vaikeaa, eikä edes kovin aikaavievää.

Lisäksi: vaikka kaikki suomalaiset käyttäisivät forumia, niin Delphin suorituskyky todennäköisesti riittää siihen, että kaikki pyörii yhdellä tietokoneella, ei siis tarvetta kuormantasausjärjestelmille.

Ainoastaan lainvastainen häiriköinti voi vaatia enemmän palvelintehoa, mutta silloin on siis kyse selkeästi laittomasta toiminnasta, joka on rangaistava teko (tietoliikenteen häirintä on rikoslain mukaan rikos).

Oikein toteutettu sessionhallinta auttaa tässäkin:
Vaikka kaikki datapaketit joudutaan vastaanottamaan, niin oikein tehdyssä sessionhallinnassa verifioimaton paketti tunnistetaan nopeasti, jolloin sille ei tehdä sen enempää käsittelyä, vaan se hylätään heti vastaanoton jälkeen, jolloin sen aiheuttama kuormitus on minimaalista.

Hölmö koodaaja tekee tietokantahaun aina, eli onko käyttäjätunnus ja salasana oikea.
Onneksi fiksu koodaaja voi toimia toisinkin, eikä vaadi tietokantahakua sen selvittäminen, onko ko. postaus autentikoitu vai ei.

Delphi antaa tähän erinomaiset mahdollisuudet, ja koodin nopeus on sellainen, että Java -ratkaisussa 20 konetta yhteensä häviää nopeudessa yhdelle koneelle, jossa ajetaan Delphillä fiksusti koodattua ohjelmaa.

Eli Delphi -koodaajalla ei tässä ole mitään teknistä ongelmaa, enemmäkin ongelma on se, että miten keskusteluforumilla voi mitään tienata, kun käyttäjät odottavat palvelun olevan ilmainen.

Google ads on muuten harvinaisen huono idea.
Googlea pidän mafian tapaan toimivana tahona.

Eli jos Googlen mielestä sivu ei sovi Googlen normistoon, niin sivulla mainosnäytöt toimivat silti normaalisti (ja Google laskuttaa mainostavia yrityksiä mainostilasta).

Sitten kun olisi aika Googlen maksaa sivuston omistajille, niin eivät maksa, ja väittävät, että sivusto ei täytä Google normeja.

Tässä sivuston omistaja on heikoilla, kun Google siis ensin jatkaa mainosten näyttämistä ja laskuttaa ne omilta asiakkailtaan, mutta raha ei päädy sivuston omistajalle asti.

Ilmeisesti mainostila pitäisi myydä sivustolle itse, ei käyttää Googlen kaltaisia moraalittomia välistävetäjiä.

Tehoaako "Sinun yrityksesi mainos tässä - klikkaa tästä nähdäksesi lisätietoja" -tyyppiset mainokset siten, että päästäisiin tekemään suora sopimus sivuston omistajan ja mainostavan yrityksen välillä ?

Voi nimittäin olla ainoa keino varmistaa, ettei näytetä sellaisia mainoksia, joista sivuston omistaja ei saa mitään.

Varsinkin, jos keskusteluforumi sallii seksiaiheisia viestejä, niin Google mielellään käyttää tuota tekosyynä em. kaltaiselle mainoshuijaukselle, jossa Google hyötyy ja sivuston omistaja ei hyödy.

Lisäksi:
Tiesittekö, että netissä on firmoja, jotka maksavat mainosten klikkailusta palkkaa ?

Jos kaikki osapuolet toimisivat rehellisesti, tuollaisille firmoille ei olisi mitään tarvetta.

Mutta jos Google sopii jokun yrityksen kanssa vaikkapa, että yritys maksaa Googlelle 1€ joka kerta, kun joku klikkaa ko. yrityksen mainosta, mitä tapahtuu ?

Sopiiko Google tuollaisen "palkkaa mainosklikkailusta" -yrityksen kanssa siitä, että tuon yrityksen työntekijä klikkailee mainoksia, ja mainoksen laittanut asiakasyritys maksaa 1€ per klikkaus, josta tietenkin Google saa 0,70€, tuo pikkufirma ottaa 0,20€ ja työntekijälle jää 0,10€, josta pitää tietenkin maksaa verot - tällaista kuviota ainakin vahvasti epäilen.

Jos tuollaista kuviota ei olisi, miksi mikään yritys maksaisi palkkaa mainosten klikkailemisista ?

Lue lisää

"Tyypillistä ajattelua ihmiseltä, joka ei osaa itse koodata sessionhallintaa, vaan olettaa, että monimutkainen framework on tarpeen."

Kyse ei ole siitä etteikö sessionhallintaa osaisi koodata, eikä frameworkin tarvitse olla monimutkainen.

Olennaista on se, että koodia kirjoitetaan niin että muutkin ymmärtävät kun frameworkit määrittelevät esimerkiksi nimeämistä ja näille on dokumentaatiota.

Täysin samasta syystä lähdekoodin sekaan joskus kirjoitetaan kommenttirivejä ja ne kirjoitetaan englanniksi siksi, että muutkin ymmärtävät. Ohjelmointikielikin valitaan niin, että muutkin ymmrätävät. Tämä on merkittävä syy sille, miksi Typescript saanut suosiota backendin puolella kun se on pohjimmiltaan Javascriptiä mitä osaa kaikki. Ei niitä kommenttirivejä kirjoiteta myöskään arabiaksi kun ohjelmoijat ymmärtävät englantia.

"Tosiasiassa tuon voi hoitaa yksinkertaisemminkin, eikä sen kirjoittaminen itse Delphillä todellakaan ole vaikeaa, eikä edes kovin aikaavievää."

Mutta sen koodin pitäisi olla vastaavan näköistä kuin mitä maailmalla käytetään.

Muista että ohjelmoijan tehtävänä on kirjoittaa tilaajalta tai osakkeenomistajalta saatava määritelmä formaalilla kielellä niin, että muutkin ihmiset ymmärtävät sen ja että sitä voidaan koneellisesti lukea.

Suorituskyky tietenkään ole mikään ongelma Javalla. Sehän on C#:n ohella nopeinta mitä saa tuollaiseen foorumihommaan.

Mutta oikeasti tuossa foorumin tekemisessä suorituskyky on kiinni tietokannasta ja työkalusas ratkaisee hyvinkin paljon miten aikoo todentaa käyttäjän. Todennushan voidaan tehdä vaikka Facebook, Google tai Microsoft tunnuksilla. Todennusta varten halutaan sitten tähän joku palikka joka ylläpitää sitä kun Facebook, Google ja Microsoft voivat muuttaa rajapintaansa, että itse ei tarvitsisi hyysätä sitä.

Ja jos tallennetaan itse käyttäjädataa niin turvallisuus meneekin tarkaksi kun salasana palautetaan tavallisesti sähköpostiin. Tuon takia käytetään valmista tekniikkaa että jos tietoturva pettää niin ei ole itse ainakaan täysin vastuussa kun sitä osaa tekniikasta huolehtinut joku muu.

Anonyymi kirjoitti:

Ilmeisesti tänne jälleen kerran tupsahti M-Kar jauhamaan paskaa (kuten aina).

Mutta heitänpä tähän kysymyksen:

JOS koodaisin Delphillä hieman vastaavan systeemin kuin suom24 keskustelu on, niin:

MITEN voin ansaita rahaa tällä ?

Päinvastoin:
Jotta palveluun saataisiin käyttäjiä, sitä pitäisi mainostaa jossain.
Ja mainonta ei ole halpaa, se maksaa paljon!

Yksi asia on varma:
Tänne suomi24:lle on viime aikoina joku häirikkö postannut tuhansittain seksisivustoja mainostavia viestejä.

Esimerkiksi tällaisia linkkejä on havaittu (ÄLÄ klikkaa - tarjolla voi olla esim. haittaohjelmia):

Sarah Harrell
N­y­­m­f­o­m­a­a­n­­i -> https://x18.fun/girl01834670#SarahHarrell

Miten voi olla ylläpidolle noin vaikeaa torjua nuo ?

Toisaalta:

JOS joku menee klikkaamaan moista linkkiä, niin miten noiden linkkien massapostaaja hyötyy noista ?

Jollei sitten linkki mene jollekin maksulliselle seksisivustolle, mutta JOS menee, niin 99,9% klikkailijoista ei mitään maksa, koska netissä on tarjolla ilmaisseksisivustojakin vaikka millä mitalla, eli pornoa on katseltavissa ilmaiseksi sille, joka pornoa haluaa.

Tuossa joku asiaa ymmärtämätön valittelee, miten pitää olla joku monimutkainen sessionhallintatapa, ja väittää, ettei Delphissä ole sille frameworkia.

Tyypillistä ajattelua ihmiseltä, joka ei osaa itse koodata sessionhallintaa, vaan olettaa, että monimutkainen framework on tarpeen.

Tosiasiassa tuon voi hoitaa yksinkertaisemminkin, eikä sen kirjoittaminen itse Delphillä todellakaan ole vaikeaa, eikä edes kovin aikaavievää.

Lisäksi: vaikka kaikki suomalaiset käyttäisivät forumia, niin Delphin suorituskyky todennäköisesti riittää siihen, että kaikki pyörii yhdellä tietokoneella, ei siis tarvetta kuormantasausjärjestelmille.

Ainoastaan lainvastainen häiriköinti voi vaatia enemmän palvelintehoa, mutta silloin on siis kyse selkeästi laittomasta toiminnasta, joka on rangaistava teko (tietoliikenteen häirintä on rikoslain mukaan rikos).

Oikein toteutettu sessionhallinta auttaa tässäkin:
Vaikka kaikki datapaketit joudutaan vastaanottamaan, niin oikein tehdyssä sessionhallinnassa verifioimaton paketti tunnistetaan nopeasti, jolloin sille ei tehdä sen enempää käsittelyä, vaan se hylätään heti vastaanoton jälkeen, jolloin sen aiheuttama kuormitus on minimaalista.

Hölmö koodaaja tekee tietokantahaun aina, eli onko käyttäjätunnus ja salasana oikea.
Onneksi fiksu koodaaja voi toimia toisinkin, eikä vaadi tietokantahakua sen selvittäminen, onko ko. postaus autentikoitu vai ei.

Delphi antaa tähän erinomaiset mahdollisuudet, ja koodin nopeus on sellainen, että Java -ratkaisussa 20 konetta yhteensä häviää nopeudessa yhdelle koneelle, jossa ajetaan Delphillä fiksusti koodattua ohjelmaa.

Eli Delphi -koodaajalla ei tässä ole mitään teknistä ongelmaa, enemmäkin ongelma on se, että miten keskusteluforumilla voi mitään tienata, kun käyttäjät odottavat palvelun olevan ilmainen.

Google ads on muuten harvinaisen huono idea.
Googlea pidän mafian tapaan toimivana tahona.

Eli jos Googlen mielestä sivu ei sovi Googlen normistoon, niin sivulla mainosnäytöt toimivat silti normaalisti (ja Google laskuttaa mainostavia yrityksiä mainostilasta).

Sitten kun olisi aika Googlen maksaa sivuston omistajille, niin eivät maksa, ja väittävät, että sivusto ei täytä Google normeja.

Tässä sivuston omistaja on heikoilla, kun Google siis ensin jatkaa mainosten näyttämistä ja laskuttaa ne omilta asiakkailtaan, mutta raha ei päädy sivuston omistajalle asti.

Ilmeisesti mainostila pitäisi myydä sivustolle itse, ei käyttää Googlen kaltaisia moraalittomia välistävetäjiä.

Tehoaako "Sinun yrityksesi mainos tässä - klikkaa tästä nähdäksesi lisätietoja" -tyyppiset mainokset siten, että päästäisiin tekemään suora sopimus sivuston omistajan ja mainostavan yrityksen välillä ?

Voi nimittäin olla ainoa keino varmistaa, ettei näytetä sellaisia mainoksia, joista sivuston omistaja ei saa mitään.

Varsinkin, jos keskusteluforumi sallii seksiaiheisia viestejä, niin Google mielellään käyttää tuota tekosyynä em. kaltaiselle mainoshuijaukselle, jossa Google hyötyy ja sivuston omistaja ei hyödy.

Lisäksi:
Tiesittekö, että netissä on firmoja, jotka maksavat mainosten klikkailusta palkkaa ?

Jos kaikki osapuolet toimisivat rehellisesti, tuollaisille firmoille ei olisi mitään tarvetta.

Mutta jos Google sopii jokun yrityksen kanssa vaikkapa, että yritys maksaa Googlelle 1€ joka kerta, kun joku klikkaa ko. yrityksen mainosta, mitä tapahtuu ?

Sopiiko Google tuollaisen "palkkaa mainosklikkailusta" -yrityksen kanssa siitä, että tuon yrityksen työntekijä klikkailee mainoksia, ja mainoksen laittanut asiakasyritys maksaa 1€ per klikkaus, josta tietenkin Google saa 0,70€, tuo pikkufirma ottaa 0,20€ ja työntekijälle jää 0,10€, josta pitää tietenkin maksaa verot - tällaista kuviota ainakin vahvasti epäilen.

Jos tuollaista kuviota ei olisi, miksi mikään yritys maksaisi palkkaa mainosten klikkailemisista ?

Lue lisää

Tuosta kun puhut kustannusten säästämisestä että Delphillä tarvitsee olla vain yksi palvelin, niin tämä kyllä onnistuu hyvin Javallakin.

Mutta kuinka mukavasti Delphillä onnistuu ylläpitokulujen säästö tekemällä foorumisoftia niin että toimivat ilman aina päällä olevia palvelimia? Eli serverlessinä.

Anonyymi kirjoitti:

Ilmeisesti tänne jälleen kerran tupsahti M-Kar jauhamaan paskaa (kuten aina).

Mutta heitänpä tähän kysymyksen:

JOS koodaisin Delphillä hieman vastaavan systeemin kuin suom24 keskustelu on, niin:

MITEN voin ansaita rahaa tällä ?

Päinvastoin:
Jotta palveluun saataisiin käyttäjiä, sitä pitäisi mainostaa jossain.
Ja mainonta ei ole halpaa, se maksaa paljon!

Yksi asia on varma:
Tänne suomi24:lle on viime aikoina joku häirikkö postannut tuhansittain seksisivustoja mainostavia viestejä.

Esimerkiksi tällaisia linkkejä on havaittu (ÄLÄ klikkaa - tarjolla voi olla esim. haittaohjelmia):

Sarah Harrell
N­y­­m­f­o­m­a­a­n­­i -> https://x18.fun/girl01834670#SarahHarrell

Miten voi olla ylläpidolle noin vaikeaa torjua nuo ?

Toisaalta:

JOS joku menee klikkaamaan moista linkkiä, niin miten noiden linkkien massapostaaja hyötyy noista ?

Jollei sitten linkki mene jollekin maksulliselle seksisivustolle, mutta JOS menee, niin 99,9% klikkailijoista ei mitään maksa, koska netissä on tarjolla ilmaisseksisivustojakin vaikka millä mitalla, eli pornoa on katseltavissa ilmaiseksi sille, joka pornoa haluaa.

Tuossa joku asiaa ymmärtämätön valittelee, miten pitää olla joku monimutkainen sessionhallintatapa, ja väittää, ettei Delphissä ole sille frameworkia.

Tyypillistä ajattelua ihmiseltä, joka ei osaa itse koodata sessionhallintaa, vaan olettaa, että monimutkainen framework on tarpeen.

Tosiasiassa tuon voi hoitaa yksinkertaisemminkin, eikä sen kirjoittaminen itse Delphillä todellakaan ole vaikeaa, eikä edes kovin aikaavievää.

Lisäksi: vaikka kaikki suomalaiset käyttäisivät forumia, niin Delphin suorituskyky todennäköisesti riittää siihen, että kaikki pyörii yhdellä tietokoneella, ei siis tarvetta kuormantasausjärjestelmille.

Ainoastaan lainvastainen häiriköinti voi vaatia enemmän palvelintehoa, mutta silloin on siis kyse selkeästi laittomasta toiminnasta, joka on rangaistava teko (tietoliikenteen häirintä on rikoslain mukaan rikos).

Oikein toteutettu sessionhallinta auttaa tässäkin:
Vaikka kaikki datapaketit joudutaan vastaanottamaan, niin oikein tehdyssä sessionhallinnassa verifioimaton paketti tunnistetaan nopeasti, jolloin sille ei tehdä sen enempää käsittelyä, vaan se hylätään heti vastaanoton jälkeen, jolloin sen aiheuttama kuormitus on minimaalista.

Hölmö koodaaja tekee tietokantahaun aina, eli onko käyttäjätunnus ja salasana oikea.
Onneksi fiksu koodaaja voi toimia toisinkin, eikä vaadi tietokantahakua sen selvittäminen, onko ko. postaus autentikoitu vai ei.

Delphi antaa tähän erinomaiset mahdollisuudet, ja koodin nopeus on sellainen, että Java -ratkaisussa 20 konetta yhteensä häviää nopeudessa yhdelle koneelle, jossa ajetaan Delphillä fiksusti koodattua ohjelmaa.

Eli Delphi -koodaajalla ei tässä ole mitään teknistä ongelmaa, enemmäkin ongelma on se, että miten keskusteluforumilla voi mitään tienata, kun käyttäjät odottavat palvelun olevan ilmainen.

Google ads on muuten harvinaisen huono idea.
Googlea pidän mafian tapaan toimivana tahona.

Eli jos Googlen mielestä sivu ei sovi Googlen normistoon, niin sivulla mainosnäytöt toimivat silti normaalisti (ja Google laskuttaa mainostavia yrityksiä mainostilasta).

Sitten kun olisi aika Googlen maksaa sivuston omistajille, niin eivät maksa, ja väittävät, että sivusto ei täytä Google normeja.

Tässä sivuston omistaja on heikoilla, kun Google siis ensin jatkaa mainosten näyttämistä ja laskuttaa ne omilta asiakkailtaan, mutta raha ei päädy sivuston omistajalle asti.

Ilmeisesti mainostila pitäisi myydä sivustolle itse, ei käyttää Googlen kaltaisia moraalittomia välistävetäjiä.

Tehoaako "Sinun yrityksesi mainos tässä - klikkaa tästä nähdäksesi lisätietoja" -tyyppiset mainokset siten, että päästäisiin tekemään suora sopimus sivuston omistajan ja mainostavan yrityksen välillä ?

Voi nimittäin olla ainoa keino varmistaa, ettei näytetä sellaisia mainoksia, joista sivuston omistaja ei saa mitään.

Varsinkin, jos keskusteluforumi sallii seksiaiheisia viestejä, niin Google mielellään käyttää tuota tekosyynä em. kaltaiselle mainoshuijaukselle, jossa Google hyötyy ja sivuston omistaja ei hyödy.

Lisäksi:
Tiesittekö, että netissä on firmoja, jotka maksavat mainosten klikkailusta palkkaa ?

Jos kaikki osapuolet toimisivat rehellisesti, tuollaisille firmoille ei olisi mitään tarvetta.

Mutta jos Google sopii jokun yrityksen kanssa vaikkapa, että yritys maksaa Googlelle 1€ joka kerta, kun joku klikkaa ko. yrityksen mainosta, mitä tapahtuu ?

Sopiiko Google tuollaisen "palkkaa mainosklikkailusta" -yrityksen kanssa siitä, että tuon yrityksen työntekijä klikkailee mainoksia, ja mainoksen laittanut asiakasyritys maksaa 1€ per klikkaus, josta tietenkin Google saa 0,70€, tuo pikkufirma ottaa 0,20€ ja työntekijälle jää 0,10€, josta pitää tietenkin maksaa verot - tällaista kuviota ainakin vahvasti epäilen.

Jos tuollaista kuviota ei olisi, miksi mikään yritys maksaisi palkkaa mainosten klikkailemisista ?

Lue lisää

" ja väittää, ettei Delphissä ole sille frameworkia."

No onko muka?

"Tyypillistä ajattelua ihmiseltä, joka ei osaa itse koodata sessionhallintaa, vaan olettaa, että monimutkainen framework on tarpeen."

Framework tarvitaan että koodi on yhdenmukaista sen kanssa mitä muuallakin on käytössä. Ei kukaan halua mitään ripulikoodia mikä ei ole yhdenmukaista sen kanssa mitä muut käyttää.

"Delphi antaa tähän erinomaiset mahdollisuudet, ja koodin nopeus on sellainen, että Java -ratkaisussa 20 konetta yhteensä häviää nopeudessa yhdelle koneelle, jossa ajetaan Delphillä fiksusti koodattua ohjelmaa."

Javalla tehty vaan on nopeampi kuin Delphillä tehty.

Anonyymi kirjoitti:

Ilmeisesti tänne jälleen kerran tupsahti M-Kar jauhamaan paskaa (kuten aina).

Mutta heitänpä tähän kysymyksen:

JOS koodaisin Delphillä hieman vastaavan systeemin kuin suom24 keskustelu on, niin:

MITEN voin ansaita rahaa tällä ?

Päinvastoin:
Jotta palveluun saataisiin käyttäjiä, sitä pitäisi mainostaa jossain.
Ja mainonta ei ole halpaa, se maksaa paljon!

Yksi asia on varma:
Tänne suomi24:lle on viime aikoina joku häirikkö postannut tuhansittain seksisivustoja mainostavia viestejä.

Esimerkiksi tällaisia linkkejä on havaittu (ÄLÄ klikkaa - tarjolla voi olla esim. haittaohjelmia):

Sarah Harrell
N­y­­m­f­o­m­a­a­n­­i -> https://x18.fun/girl01834670#SarahHarrell

Miten voi olla ylläpidolle noin vaikeaa torjua nuo ?

Toisaalta:

JOS joku menee klikkaamaan moista linkkiä, niin miten noiden linkkien massapostaaja hyötyy noista ?

Jollei sitten linkki mene jollekin maksulliselle seksisivustolle, mutta JOS menee, niin 99,9% klikkailijoista ei mitään maksa, koska netissä on tarjolla ilmaisseksisivustojakin vaikka millä mitalla, eli pornoa on katseltavissa ilmaiseksi sille, joka pornoa haluaa.

Tuossa joku asiaa ymmärtämätön valittelee, miten pitää olla joku monimutkainen sessionhallintatapa, ja väittää, ettei Delphissä ole sille frameworkia.

Tyypillistä ajattelua ihmiseltä, joka ei osaa itse koodata sessionhallintaa, vaan olettaa, että monimutkainen framework on tarpeen.

Tosiasiassa tuon voi hoitaa yksinkertaisemminkin, eikä sen kirjoittaminen itse Delphillä todellakaan ole vaikeaa, eikä edes kovin aikaavievää.

Lisäksi: vaikka kaikki suomalaiset käyttäisivät forumia, niin Delphin suorituskyky todennäköisesti riittää siihen, että kaikki pyörii yhdellä tietokoneella, ei siis tarvetta kuormantasausjärjestelmille.

Ainoastaan lainvastainen häiriköinti voi vaatia enemmän palvelintehoa, mutta silloin on siis kyse selkeästi laittomasta toiminnasta, joka on rangaistava teko (tietoliikenteen häirintä on rikoslain mukaan rikos).

Oikein toteutettu sessionhallinta auttaa tässäkin:
Vaikka kaikki datapaketit joudutaan vastaanottamaan, niin oikein tehdyssä sessionhallinnassa verifioimaton paketti tunnistetaan nopeasti, jolloin sille ei tehdä sen enempää käsittelyä, vaan se hylätään heti vastaanoton jälkeen, jolloin sen aiheuttama kuormitus on minimaalista.

Hölmö koodaaja tekee tietokantahaun aina, eli onko käyttäjätunnus ja salasana oikea.
Onneksi fiksu koodaaja voi toimia toisinkin, eikä vaadi tietokantahakua sen selvittäminen, onko ko. postaus autentikoitu vai ei.

Delphi antaa tähän erinomaiset mahdollisuudet, ja koodin nopeus on sellainen, että Java -ratkaisussa 20 konetta yhteensä häviää nopeudessa yhdelle koneelle, jossa ajetaan Delphillä fiksusti koodattua ohjelmaa.

Eli Delphi -koodaajalla ei tässä ole mitään teknistä ongelmaa, enemmäkin ongelma on se, että miten keskusteluforumilla voi mitään tienata, kun käyttäjät odottavat palvelun olevan ilmainen.

Google ads on muuten harvinaisen huono idea.
Googlea pidän mafian tapaan toimivana tahona.

Eli jos Googlen mielestä sivu ei sovi Googlen normistoon, niin sivulla mainosnäytöt toimivat silti normaalisti (ja Google laskuttaa mainostavia yrityksiä mainostilasta).

Sitten kun olisi aika Googlen maksaa sivuston omistajille, niin eivät maksa, ja väittävät, että sivusto ei täytä Google normeja.

Tässä sivuston omistaja on heikoilla, kun Google siis ensin jatkaa mainosten näyttämistä ja laskuttaa ne omilta asiakkailtaan, mutta raha ei päädy sivuston omistajalle asti.

Ilmeisesti mainostila pitäisi myydä sivustolle itse, ei käyttää Googlen kaltaisia moraalittomia välistävetäjiä.

Tehoaako "Sinun yrityksesi mainos tässä - klikkaa tästä nähdäksesi lisätietoja" -tyyppiset mainokset siten, että päästäisiin tekemään suora sopimus sivuston omistajan ja mainostavan yrityksen välillä ?

Voi nimittäin olla ainoa keino varmistaa, ettei näytetä sellaisia mainoksia, joista sivuston omistaja ei saa mitään.

Varsinkin, jos keskusteluforumi sallii seksiaiheisia viestejä, niin Google mielellään käyttää tuota tekosyynä em. kaltaiselle mainoshuijaukselle, jossa Google hyötyy ja sivuston omistaja ei hyödy.

Lisäksi:
Tiesittekö, että netissä on firmoja, jotka maksavat mainosten klikkailusta palkkaa ?

Jos kaikki osapuolet toimisivat rehellisesti, tuollaisille firmoille ei olisi mitään tarvetta.

Mutta jos Google sopii jokun yrityksen kanssa vaikkapa, että yritys maksaa Googlelle 1€ joka kerta, kun joku klikkaa ko. yrityksen mainosta, mitä tapahtuu ?

Sopiiko Google tuollaisen "palkkaa mainosklikkailusta" -yrityksen kanssa siitä, että tuon yrityksen työntekijä klikkailee mainoksia, ja mainoksen laittanut asiakasyritys maksaa 1€ per klikkaus, josta tietenkin Google saa 0,70€, tuo pikkufirma ottaa 0,20€ ja työntekijälle jää 0,10€, josta pitää tietenkin maksaa verot - tällaista kuviota ainakin vahvasti epäilen.

Jos tuollaista kuviota ei olisi, miksi mikään yritys maksaisi palkkaa mainosten klikkailemisista ?

Lue lisää

Olen kuvitellut, että nykyään mainostaja voi tilata mainoksen näkyvyyden melko tarkkaan: tiettyyn maahan, tiettyyn ikäluokkaan kuluville, ilmaisemansa kiinnostuskohteen ilmoittaneille jne. Olen myös käsityksistä että se mistä maksetaan ja kuinka paljon vaihtelee eli maksaja voi joutua maksamaan pelkästä mainosbannerin näkemisestä, klikkaamisesta ja viimeisenä antamaan provikat tilauksesta, joka on tullut mainosklikin kautta. Jos kaikkea tuota haluaa tukea, ja kenties joukkoa tässä mainitsemattomia mekanismeja, niin olisihan siinä koodattavaa. Ei sen puoleen, että pelkkää koodaaminen riittäisi, sillä noissa mekanismeissahan on takana sosiaalisen median ja Googlen/Applen käyttäjädataa myös, joiden avulla profilointia tehdään.

Ketjussa puheena olevassa sovellutuksessa, jos se halutaan tehdä ilman monikansallisia mainosmyyntipalveluita, joutuisi tyytymään simppelimpiin menetelmiin. Yksi monilla foorumeilla käytössä oleva mekanismi on foorumin sponsoroiminen (varmaankin mainostikettien myynti onnistuisi olemassa olevien verkkokauppapalveluitten kautta). Toinen konsti voisi olla näyttökertojen myynti ja profilointi foorumin käyttäjätietojen perusteella (ikä, sukupuoli yms.) sekä sivulla esiintyvien termien tai hakusanojen perusteella. Suomessa saattaisi pelata luotto mainostajan ja foorumin mainostenmyyjän välillä ilman että tarvittaisiin kolmansia osapuolia varmentamaan mainosten näyttötapahtumia.

Anonyymi kirjoitti:

Itseäni houkuttaisi ajatus, että varsinaista sessionhallintaa ei olisi, vaan vain uusien viestien lisääminen (poistaminen yms.) vaatisi "kirjautumisen" toiminnon suorittamiseksi. Kirjautuminen edellä siis tarkoittaa vain käyttäjätunnuksen ja salasanan syöttämistä sen varmistamiseksi, että kyseisellä käyttäjällä on oikeus kyseiseen toimintoon. Mitään sessiota ei kuitenkaan muodostettaisi ja sama "kirjautuminen" pitäisi muodostaa vaikka heti perään, jos käyttäjä haluaa tehdä uuden lisäyksen tai poiston. Ehkäpä tämä "kirjautuminen" hoituisi käytännöllisemmin JavaScriptillä muodostettavalla yksittäisellä merkkijonolla, joka muodostettaisiin käyttäjätunnuksesta ja salasanasta, ja jota säilytettäisiin session ajan asiakaspäässä eli käytössä olisi tosiasiallisesti asiakaspään sessionhallinta. Tuo merkkijono pitäisi toki salakirjoittaa turvallisella tavalla, mikä puolestaan kävisi kätevimmin SSL-yhteyden kanssa, mikä taasen vaatisi oikean sessionhallinnan, ja hupsista, ollaan aika raskaassa järjestelmässä, ja ristiriidassa viestin ensimmäisessä lauseessa ilmaistun kanssa. :D Toki SSL-yhteyskin voisi olla uusi jokaista sivun latausta ja lähetystä kohti, vaan olisiko siinä sitten juurikaan järkeä...

Lue lisää

Delphillä tuokin ongelma on ERITTÄIN helppo ratkaista - eikä vaadi edes SSL -salausta.

Sitä voitte ihmetellä, miten... sitähän ei tyhmemmät koodarit voi käsittää.

Anonyymi kirjoitti:

Heh, toki; tiedä mistä 'ongelmat' tupsahti sijaan. Kun tarkemmin luin linkkaamaani artikkelia, niin pitänee tulkita niin päin, että teoriassa c:llä voi päästä samaan nopeuteen kuin Rustilla, mutta käytännössä kuka jaksaa viilata koodia niin pitkälle. Tekstissä https://kornel.ski/rust-c-speed kerrottiin lukuisia esimerkkejä tilanteista joissa Rust-koodi on nopeampaa, mutta oli mukana myös esimerkkejä niistä joissa Rust puolestaan ei ole vahvoilla. Tässä muutama esimerkki:

"Strings have their size encoded in their "fat" pointer. This makes length checks fast, eliminates risk of accidental O(n²) string loops, and allows making substrings in-place (e.g. splitting a string into tokens) without modifying memory or copying to add the \0 terminator."

"Like C templates, Rust generates copies of generic code for each type they're used with, so functions like sort() and containers like hash tables are always optimized for their type. In C I have to choose between hacks with macros or less efficient functions that work on void* and run-time variable sizes."

"Rust iterators can be combined into chains that get optimized together as one unit. So instead of a series of calls buy(it); use(it); break(it); change(it); mail(upgrade(it)); that may end up rewriting the same buffer many times, I can call it.buy().use().break().change().upgrade().mail() that compiles to one buy_use_break_change_mail_upgrade(it) optimized to do all of that in a single combined pass. (0..1000).map(|x| x*2).sum() compiles to return 999000."

"Similarly, there are Read and Write interfaces that allow functions to stream unbuffered data. They combine nicely, so I can write data to a stream that calculates CRC of the data on the fly, adds framing/escaping if needed, compresses it, and writes it to the network, all in one call. And I can pass such combined stream as an output stream to my HTML templating engine, so now each HTML tag will be smart enough to send itself compressed. The underlying mechanism is just a pyramid of plain next_stream.write(bytes) calls, so technically nothing stops me from doing the same in C, except the lack of traits and generics in C means it's very hard to actually do that in practice, other than with callbacks set up at run time, which isn't as efficient."

"These days everything seems to require JSON. Rust's serde is one of the fastest JSON parsers in the world, and it parses directly into Rust structs, so use of the parsed data is very fast and efficient, too."

Lue lisää

"Rust's serde is one of the fastest JSON parsers in the world, and it parses directly into Rust structs"

Ja taas (ilmeisesti M-Kar) kehuu Rustia.

Vaan pärjääkö tuo RUSTin serde delphi -luokalle, jota itse käytän parserina.

En tosin enää edes muista, onko parsittava data JSON vai XML -muotoista. Taitaa olla XML.

Mutta Delphi -luokka parseroi XML:ää salamannopeasti.

Jotkut kuvittelevat, että kun ohjelmointikieli tai -työväline on muotia, niin se olisi jotenkin parempi.

Tosiasiassa Delphi pärjää erinomaisesti kaikkialla siellä, missä halutaan nopeutta, luotettavuutta ja erinomaista suorituskykyä.

M-Kar jaksaa väittää toisin, mutta noihin valheisiin ei pidä uskoa.

Anonyymi kirjoitti:

"Kommentointisi ei tue väitettä. C-kieli on helppo osata, mutta vaikea täysin hallita. Aina löytyy jokin uusi ahaa-elämys ja tämän totean ainakin yhtä pitkällä kokemuksella."

No ei kyllä löydy. Sehän on hyvin yksinkertainen kieli.

Ja optimointijutut liittyen C:n on enemmänkin sitä hardware tason juttua että viilailee koodia toimimaan sen mukaan miten rauta toimii.

Itse C on niin yksinkertainen kieli että se on hyvin helppo hallita läpeensä.

"Ja jos kirjoitat esimerkiksi uudelleenkäytettävää kirjastokoodia, huonon koodin suorituskyky voi nousta ongelmaksi arvaamattomalla tavalla myöhemmin."

Nimenomaan ei tule. Tekemällä koodin siististi, sitä on helppo muuttaa jos jotain tarvetta tulee ja ei sitten käytä aikaa hinkkaamaan jotain yksittäisen osan suorituskykyä vaan keskittyy tekemään koko ohjelman siististi, valmiiksi ja pyrkiä virheettömyyteen.

Yleensä se suorituskyky ei vaan ole mikään ongelma kun valitsee työkalut ja tavat tilanteen mukaan ja tekee siististi ja välttää tekemästä jotain hölmöä. Hölmöydet huomaa juurikin silloin paremmin kun tekee siististi.

"Sulautetussa maailmassa suorituskyky on aina huomioitava tekijä, koska rautaa ei haluta mitoittaa yhtään tehokkaammaksi eli kalliimaksi kuin on välttämätöntä."

No just parhaillaan teen sulautettuun koodia. Pythonilla. Koska helpoiten valmiiksi ja tässä kohtaa ei tarvitse kun ei ole massatuotantoa. Kerätään kaikki vaatimukset ensiksi ennen kuin aletaan tekemään parempaa versiota.

"En löytänyt pointtiasi. C on matalan tason ohjelmointikieli, siinä ei ole varmistinta. Rajattoman vallan mukana tulee vastuu, koodaajan täytyy tietää mitä tekee,"

Se myös tarkoittaa sitä, että kääntäjän on käännettävä koodi sillä tavalla kuin ohjelmoija on sen kirjoittanut, tekemällä vaikka memcpy:llä joku hillitön kopiointi.

"Suoritusjärjestystä ei tietenkään saa muuttaa niin, että sillä on toiminnallista vakutusta tai edes sivuvaikutuksia."

Nyt alat päästä jäljille. Haskellissa ei oletuksena koodia kirjoitettaessa tule mitään sivuvaikutuksia muualla kuin tarkoin määritetysti, tyyliin niin että eristetään koodissa vaikka tiedoston käyttö.

Sitten kaikki mitä lasketaan niin kääntäjällä on vapaat kädet optimoida hurjilla tavoilla kun sillä on tieto, että ei ole sivuvaikutuksia. C:stä tämä puuttuu.

"Mutta keskustelumme lähti suoritustehokkuusnäkökulmasta, jos muistan, ja siinä suhteessa C-kielelle ei ole voittajaa. "

Kyllä on kun lähtökohtana on se, että kirjoitetaan softa siististi.

Siksi niinkin tavallisen asian kuin web servicen tekeminen onkin C:llä tehotonta kun ei ole niin optimoitua toteutusta.

Yksi suorituskykyyn vaikuttava asia on esimerkiksi roskien kerääjä, että se toimii joissakin tilanteissa nopeammin kuin manuaalinen muistinhallinta. C:llä ei järkevästi onnistu se, että kutsut free() silloin kun kone on idlellä. Roskien kerääjää käyttävillä kielillä runtime osaa tehdä tuota. Ihan puhtaassa yksinkertaisessa suorituksessakin Zig kääntää tehokkaampaa koodia.

Oikeasti C:n vahvuus ei ole suorituskyvyssä vaan se on ennemminkin siinä, että optimoidaan muistin käyttöä suorituskyvyn sijasta tehdään jotain sellaista jossa voi käyttää C:n vahvuuksia, kuten tietyntasoiset verifioinnit.

"Tässä onkin se C-kielen tehokkuuden salaisuus: ohjelmointikieli asettaa hyvin vähän rajoituksia. Koodaajalla on vapaus valita tehokkain tai nopein totetustapa tai mitä tahansa näiden väliltä."

Ja sitten on tavukoodivehkeitä optimoivat automaattisesti kohderaudalle....

Lue lisää

Mitä sulautettuihin tulee, itse koodaan näin:

Normaalikoodi kaikki ObjectPascalilla.

Keskeytyskäsittelijät assemblerilla suoraan.

Näin siksi, että keskeytyskäsittelijöissä tulee usein vastaan tilanne, että koodin on oltava nopein mahdollinen - siksi assembler.

Lisäksi sulautetuissa pitää ymmärtää, miten keskeytysten hallinta toimii - kas kun keskeytyksilläkin on prioriteetit.

Oikeasti aikakriittisen keskeytyksen pitää olla prioriteetiltään korkein.

Anonyymi kirjoitti:

"Rust's serde is one of the fastest JSON parsers in the world, and it parses directly into Rust structs"

Ja taas (ilmeisesti M-Kar) kehuu Rustia.

Vaan pärjääkö tuo RUSTin serde delphi -luokalle, jota itse käytän parserina.

En tosin enää edes muista, onko parsittava data JSON vai XML -muotoista. Taitaa olla XML.

Mutta Delphi -luokka parseroi XML:ää salamannopeasti.

Jotkut kuvittelevat, että kun ohjelmointikieli tai -työväline on muotia, niin se olisi jotenkin parempi.

Tosiasiassa Delphi pärjää erinomaisesti kaikkialla siellä, missä halutaan nopeutta, luotettavuutta ja erinomaista suorituskykyä.

M-Kar jaksaa väittää toisin, mutta noihin valheisiin ei pidä uskoa.

Lue lisää

Tokkopa M-Kar tuota englanninkielistä tekstiä on kirjoittanut. Itse puolestani en väitä että tuo lainaamani teksti olisi 100 % totta. Kuulosti vain varsin vakuuttavalta.

Delphi on oikein mainio väline, mutta sitä käyttävät firmat tuntuvat hankkiutuvan siitä eroon siirtyen web-työkaluihin (sillisalaatti eri kieliä ja kirjastoja). Saavat olla yhtenään korjaamassa koodia kun kirjastojen - ml. käyttöjärjestelmän, selainten jne. - päivitykset rikkovat softan. Vallan mainiostihan Delphikin selviytyy web-palveluista, jos sitä vain niihin halutaan käyttää.

Anonyymi kirjoitti:

"Rust's serde is one of the fastest JSON parsers in the world, and it parses directly into Rust structs"

Ja taas (ilmeisesti M-Kar) kehuu Rustia.

Vaan pärjääkö tuo RUSTin serde delphi -luokalle, jota itse käytän parserina.

En tosin enää edes muista, onko parsittava data JSON vai XML -muotoista. Taitaa olla XML.

Mutta Delphi -luokka parseroi XML:ää salamannopeasti.

Jotkut kuvittelevat, että kun ohjelmointikieli tai -työväline on muotia, niin se olisi jotenkin parempi.

Tosiasiassa Delphi pärjää erinomaisesti kaikkialla siellä, missä halutaan nopeutta, luotettavuutta ja erinomaista suorituskykyä.

M-Kar jaksaa väittää toisin, mutta noihin valheisiin ei pidä uskoa.

Lue lisää

"Tosiasiassa Delphi pärjää erinomaisesti kaikkialla siellä, missä halutaan nopeutta, luotettavuutta ja erinomaista suorituskykyä."

Sillä ei saa ohjelmoida esimerkiksi lentokoneen kriittisiä järjestelmiä. Puhuttaessa oikeasti luotettavista ohjelmista, vaatimukset ovat paljon korkeammalla mihin Delphi pystyy.

Anonyymi kirjoitti:

Mitä sulautettuihin tulee, itse koodaan näin:

Normaalikoodi kaikki ObjectPascalilla.

Keskeytyskäsittelijät assemblerilla suoraan.

Näin siksi, että keskeytyskäsittelijöissä tulee usein vastaan tilanne, että koodin on oltava nopein mahdollinen - siksi assembler.

Lisäksi sulautetuissa pitää ymmärtää, miten keskeytysten hallinta toimii - kas kun keskeytyksilläkin on prioriteetit.

Oikeasti aikakriittisen keskeytyksen pitää olla prioriteetiltään korkein.

Lue lisää

Todella aikakriittisissä asioissa sitten käännetään koodi suoraan raudalle että jätetään käyttöjärjestelmä pois tai käytetään jotain hard realtime OS:ia.

Anonyymi kirjoitti:

Tokkopa M-Kar tuota englanninkielistä tekstiä on kirjoittanut. Itse puolestani en väitä että tuo lainaamani teksti olisi 100 % totta. Kuulosti vain varsin vakuuttavalta.

Delphi on oikein mainio väline, mutta sitä käyttävät firmat tuntuvat hankkiutuvan siitä eroon siirtyen web-työkaluihin (sillisalaatti eri kieliä ja kirjastoja). Saavat olla yhtenään korjaamassa koodia kun kirjastojen - ml. käyttöjärjestelmän, selainten jne. - päivitykset rikkovat softan. Vallan mainiostihan Delphikin selviytyy web-palveluista, jos sitä vain niihin halutaan käyttää.

Lue lisää

"Delphi on oikein mainio väline, mutta sitä käyttävät firmat tuntuvat hankkiutuvan siitä eroon siirtyen web-työkaluihin (sillisalaatti eri kieliä ja kirjastoja). Saavat olla yhtenään korjaamassa koodia kun kirjastojen - ml. käyttöjärjestelmän, selainten jne. - päivitykset rikkovat softan. "

Eihän web kehitys tarkoita mitään sillisalaattia.

Kerrataanpa lyhyesti, oli reikäkortit ja erilaisia tietokoneita. Sitten tehtiin unix käyttäen C kieltä joka oli tarkoitettu käyttöjärjestelmän ohjelmointiin. Eri unixit kilpailivat ja niissä oli eroja. Kaikki alustat eri unixeineen toki oli sillisalaattia mutta näistä tuli standardi. Ei se standardi ollut sillisalaatia vaan varsin elegantti vioistaan huolimatta.

Kun se POSIX standardi tuli ja myöhemmin C-kielen standardi, oli graafisia käyttöliittymiä ollut pitkään mutta ne oli toki sillisalaattia. Sitten tuli web. Webissä oli aluksi sillisalaattia selainten vääntäessä omia virityksiään mutta se standardisoi graafisen käyttöliittymän.

Selaimissa ollut Javascript toki ja se oli aluksi se lelukieli sinne mutta siitä sitten tuli standardi. Ja siellä graafisen käyttöpuolella toki on standardeina HTML, CSS, DOM ja Javascript ja se mitä on standardeihin päässyt on juuristaan huolimatta siistiä eikä sillisalaattia.

Mistä se sillisalaatti sitten tulee on kun innokkaat junioriohjelmoijat rakentavat innoissaan kaikkea näiden standardien päälle.

Oikeasti sitä koodia ei tarvitse olla yhtenään korjaamassa. Kaikessa koodissa on riippuvuuksia, jos ei muualle niin alla olevaan rautaan. Ja koodi rikkoutuu jos tehdään muutoksia. Standardit sitten tekevät teknologiasta vakaata että se koodi ei ihan niin helposti rikkoudu. Se sillisalaatti mitä siinä oman koodin ja standardien välissä sitten voi huteraa että tarvitsee vähän näkemystä kehittäjältä että tietää mitä riippuvuuksia voi ottaa.

Siinä varmasti on hyvät syyt miksi Delphistä hankkiudutaan eroon. Hankala nähdä sitä kilpailukykyisenä.

Anonyymi kirjoitti:

"Tosiasiassa Delphi pärjää erinomaisesti kaikkialla siellä, missä halutaan nopeutta, luotettavuutta ja erinomaista suorituskykyä."

Sillä ei saa ohjelmoida esimerkiksi lentokoneen kriittisiä järjestelmiä. Puhuttaessa oikeasti luotettavista ohjelmista, vaatimukset ovat paljon korkeammalla mihin Delphi pystyy.

Lue lisää

Kysymys kaikille muille paitsi ei M-Karille:

Kumpaan lentokoneeseen sinä nousisit mieluummin ?

1. Koneeseen 1, jonka ohjelmistot minä olen koodannut ObjectPascalilla.

vai

2. Koneeseen 2, jonka ohjelmistot joku Airbusin työntekijä TAI sen alihankkijan työntekijä on koodannut C -kielellä?

Itse ainakin menisin koneeseen 1, jos vain valinnanmahdollisuus olisi.

Muistelkaapa, mitä tapahtui lennolla AF447 ?

Toki tuossa lentäjä Pierre-Cédric Bonin mokasi, mutta koneen ohjelmistot suunitellut koodari (ja mahdollisesti myös tuon koodarin esimies, jos oli antanut typeriä käskyjä koodarille) mokasi myös, useammallakin eri tavalla.

Ja koodi oli varmaan C -kielellä kirjoitettu ja Haskellilla verifioitu, kuten M-Karin mielestä on oikein.

Vaan auttoiko tuo yhtään koodin todellisen laadun suhteen?

No, eipä auttanut.

Jos minut olisi päästetty koodaamaan tuo ObjectPascalilla, niin tuokin kone olisi laskeutunut Pariisiin Charles De Gaulle -lentokentälle.

Jopa lentäjä Pierre-Cédric Bonin mokasta huolimatta.

Pitäisi päästää loppukäyttäjät (eli lentoyhtiöiden asiakkaat) tekemään itse valinta:

Kenen ja millä kielellä koodattu ohjelmisto lentokoneessa on sellainen, että uskaltaisit itse nousta lentokoneen kyytiin.

Jos minulla vain olisi siihen mahdollisuus, itse nousisin joka kerta lentokoneeseen mennessäni koneeseen, jonka ohjelmistot olen itse saanut koodata ObjectPascalilla.

Ja taatusti elän näin tehden kauemmin kuin se, joka nousee koneeseen, jonka ohjelmistot on koodattu C -kielellä.

Jos jokin määräys todella estää ObjectPascalin käytön lentokoneen ohjausohjelmiston koodauksessa, tuollainen määräys on kumottava välittömästi - moinen määräys vaarantaa lentoturvallisuuden (ja näin silti, vaikka M-Kar taas kerran tulee tänne väittämään päinvastaista).

Samoin:

Keskiviikkona 9. lokakuuta 2024 Entso-E:n palvelimelta ei saanut ladattua TO 10.10.2024 pörssisähkön hintatietoja. Jos minut olisi päästetty koodaamaan sama ObjectPascalilla, niin ohjelmistosta aiheutuvia virheitä ei tapahtuisi koskaan.

Toki: tämä ei poista sähkökatkon, tietoliikenneyhteyksien poikki olemisen, laitevian, käyttöjärjestelmän bugin, tai muiden vastaavien, itse ohjelman ulkopuolella olevien syiden aiheuttamia ongelmia - paraskaan ohjelma ei voi korjata noista johtuvia ongelmia.

Anonyymi kirjoitti:

Kysymys kaikille muille paitsi ei M-Karille:

Kumpaan lentokoneeseen sinä nousisit mieluummin ?

1. Koneeseen 1, jonka ohjelmistot minä olen koodannut ObjectPascalilla.

vai

2. Koneeseen 2, jonka ohjelmistot joku Airbusin työntekijä TAI sen alihankkijan työntekijä on koodannut C -kielellä?

Itse ainakin menisin koneeseen 1, jos vain valinnanmahdollisuus olisi.

Muistelkaapa, mitä tapahtui lennolla AF447 ?

Toki tuossa lentäjä Pierre-Cédric Bonin mokasi, mutta koneen ohjelmistot suunitellut koodari (ja mahdollisesti myös tuon koodarin esimies, jos oli antanut typeriä käskyjä koodarille) mokasi myös, useammallakin eri tavalla.

Ja koodi oli varmaan C -kielellä kirjoitettu ja Haskellilla verifioitu, kuten M-Karin mielestä on oikein.

Vaan auttoiko tuo yhtään koodin todellisen laadun suhteen?

No, eipä auttanut.

Jos minut olisi päästetty koodaamaan tuo ObjectPascalilla, niin tuokin kone olisi laskeutunut Pariisiin Charles De Gaulle -lentokentälle.

Jopa lentäjä Pierre-Cédric Bonin mokasta huolimatta.

Pitäisi päästää loppukäyttäjät (eli lentoyhtiöiden asiakkaat) tekemään itse valinta:

Kenen ja millä kielellä koodattu ohjelmisto lentokoneessa on sellainen, että uskaltaisit itse nousta lentokoneen kyytiin.

Jos minulla vain olisi siihen mahdollisuus, itse nousisin joka kerta lentokoneeseen mennessäni koneeseen, jonka ohjelmistot olen itse saanut koodata ObjectPascalilla.

Ja taatusti elän näin tehden kauemmin kuin se, joka nousee koneeseen, jonka ohjelmistot on koodattu C -kielellä.

Jos jokin määräys todella estää ObjectPascalin käytön lentokoneen ohjausohjelmiston koodauksessa, tuollainen määräys on kumottava välittömästi - moinen määräys vaarantaa lentoturvallisuuden (ja näin silti, vaikka M-Kar taas kerran tulee tänne väittämään päinvastaista).

Samoin:

Keskiviikkona 9. lokakuuta 2024 Entso-E:n palvelimelta ei saanut ladattua TO 10.10.2024 pörssisähkön hintatietoja. Jos minut olisi päästetty koodaamaan sama ObjectPascalilla, niin ohjelmistosta aiheutuvia virheitä ei tapahtuisi koskaan.

Toki: tämä ei poista sähkökatkon, tietoliikenneyhteyksien poikki olemisen, laitevian, käyttöjärjestelmän bugin, tai muiden vastaavien, itse ohjelman ulkopuolella olevien syiden aiheuttamia ongelmia - paraskaan ohjelma ei voi korjata noista johtuvia ongelmia.

Lue lisää

Lentokoneiden ohjelmistot ovat likimain parhaiten varmistettuja missään joten ei ole valittamista niistä.

Katsoin televisiosta ohjelman lentoturmatutkinnasta tuosta AF447 lennosta tässähän lentäjä kiskoi kahvasta taaksepäin vaikka sakkaushäly huusi jatkuvasti. En ole lentäjä mutta minäkin tiedän simulaatiolentämisestä, että ei nyt ainakaan näin pidä tehdä.

"Ja koodi oli varmaan C -kielellä kirjoitettu ja Haskellilla verifioitu, kuten M-Karin mielestä on oikein."

Airbus A330-200 luultavasti käyttää suurimmaksi osaksi Ada kieltä. Löytyy parikin mainintaa muutamasta kyseisen firman projektissa jossa ovat valinneet Adan, joten samat tyypit kun tekemässä niin luultavasti käyttäneet samoja työkaluja.

Ada on muuten hyvä kieli, muistuttaa itseasiassa Pascalia, mutta se on huikean paljon parempi, että sopii niihin luotettaviin järjestelmiin.

C:n käyttö luotettavissa järjestelmissä perustuu siihen että se on niin yksinkertainen. "portattava assembler". Kehittäjällä on täysi hallinta siihen mitä tapahtuu ja tuon ympärille sitten rakennettu kehittyneet työkalut varmistamaan oikeellisuus.

Ilman kurinalaista kehitysprosessia C:llä kehittäjä tekee paljon helpommin virheitä.

"Jos jokin määräys todella estää ObjectPascalin käytön lentokoneen ohjausohjelmiston koodauksessa, tuollainen määräys on kumottava välittömästi"

ObjectPascalin käyttöä ei kielletä. Sen sijaan kaikkien työkalujen käyttö joita ei ole verifioitu, käyttö on kiellettyä. Niitä verifioituja työkaluja sattuu sitten olemaan olemaan C ja Ada tärkeimpinä. Hiljattain C++:sta saatiin joku äärimmäisen suppea versio mitä sai käyttää. Javasta on saatu myös erikoisversio mutta sitä ei taideta päästää kaikista kriittisimpiin paikkoihin.

ObjectPascal kärsii muuten täysin samasta viasta kuin Rust. Kielellä ei ole formaalia spesifikaatiota. Se olisi ihan ensimmäinen askel, sitten pitäisi verifioida että työkalut että sille formaalille spesifikaatiolle että toimivat oikein. Se ei riitä että kääntää koodia ja ohjelma näyttää toimivan, pitää todistaa että ohjelma ei missään kohtaa ei toimi väärin. Kääntäjäbugit kun ovat myös mahdollisia.

"Toki: tämä ei poista sähkökatkon, tietoliikenneyhteyksien poikki olemisen, laitevian, käyttöjärjestelmän bugin, tai muiden vastaavien, itse ohjelman ulkopuolella olevien syiden aiheuttamia ongelmia - paraskaan ohjelma ei voi korjata noista johtuvia ongelmia."

Luotettavissa järjestelmissä ei välttämättä ole mitään käyttöjärjestelmää tai jos on niin sen pitää olla varmistettu virheettömäksi. Esimerkiksi mitään Windowsia ei voi laittaa sinne.

Anonyymi kirjoitti:

"Delphi on oikein mainio väline, mutta sitä käyttävät firmat tuntuvat hankkiutuvan siitä eroon siirtyen web-työkaluihin (sillisalaatti eri kieliä ja kirjastoja). Saavat olla yhtenään korjaamassa koodia kun kirjastojen - ml. käyttöjärjestelmän, selainten jne. - päivitykset rikkovat softan. "

Eihän web kehitys tarkoita mitään sillisalaattia.

Kerrataanpa lyhyesti, oli reikäkortit ja erilaisia tietokoneita. Sitten tehtiin unix käyttäen C kieltä joka oli tarkoitettu käyttöjärjestelmän ohjelmointiin. Eri unixit kilpailivat ja niissä oli eroja. Kaikki alustat eri unixeineen toki oli sillisalaattia mutta näistä tuli standardi. Ei se standardi ollut sillisalaatia vaan varsin elegantti vioistaan huolimatta.

Kun se POSIX standardi tuli ja myöhemmin C-kielen standardi, oli graafisia käyttöliittymiä ollut pitkään mutta ne oli toki sillisalaattia. Sitten tuli web. Webissä oli aluksi sillisalaattia selainten vääntäessä omia virityksiään mutta se standardisoi graafisen käyttöliittymän.

Selaimissa ollut Javascript toki ja se oli aluksi se lelukieli sinne mutta siitä sitten tuli standardi. Ja siellä graafisen käyttöpuolella toki on standardeina HTML, CSS, DOM ja Javascript ja se mitä on standardeihin päässyt on juuristaan huolimatta siistiä eikä sillisalaattia.

Mistä se sillisalaatti sitten tulee on kun innokkaat junioriohjelmoijat rakentavat innoissaan kaikkea näiden standardien päälle.

Oikeasti sitä koodia ei tarvitse olla yhtenään korjaamassa. Kaikessa koodissa on riippuvuuksia, jos ei muualle niin alla olevaan rautaan. Ja koodi rikkoutuu jos tehdään muutoksia. Standardit sitten tekevät teknologiasta vakaata että se koodi ei ihan niin helposti rikkoudu. Se sillisalaatti mitä siinä oman koodin ja standardien välissä sitten voi huteraa että tarvitsee vähän näkemystä kehittäjältä että tietää mitä riippuvuuksia voi ottaa.

Siinä varmasti on hyvät syyt miksi Delphistä hankkiudutaan eroon. Hankala nähdä sitä kilpailukykyisenä.

Lue lisää

Myönnän että laajakin web-ohjelmisto voi olla toteutettu elegantisti ja myös että monesti juurikin innokas junioriohjelmoija on se salaatin tekijä. Käytännössä vähänkään isompia softia ylläpitämässä ja kehittämässä tarvitaan junioreita kun työvoiman vaihtuvuus on alalla sitä mitä on. Kurinalaisuus on avain luotettavien ohjelmien kehittämiseen ja ylläpitämiseen (sitä kun tarvitaan kaikilla osa-alueilla suunnittelusta dokumentointiin).

Ei Delphin mukana olo projektissa automaattisesti laatua takaa, mutta sillä on vaikeampi tehdä virheitä, joita ei heti huomata, verrattuna moniin yleisempiin web-välineisiin ja ohjelmointikieliin. Rust on ymmärtääkseni Object-Pascaliakin krantumpi kieli. Tiedä sitten miltä osin parempi tai huonompi.

Anonyymi kirjoitti:

Myönnän että laajakin web-ohjelmisto voi olla toteutettu elegantisti ja myös että monesti juurikin innokas junioriohjelmoija on se salaatin tekijä. Käytännössä vähänkään isompia softia ylläpitämässä ja kehittämässä tarvitaan junioreita kun työvoiman vaihtuvuus on alalla sitä mitä on. Kurinalaisuus on avain luotettavien ohjelmien kehittämiseen ja ylläpitämiseen (sitä kun tarvitaan kaikilla osa-alueilla suunnittelusta dokumentointiin).

Ei Delphin mukana olo projektissa automaattisesti laatua takaa, mutta sillä on vaikeampi tehdä virheitä, joita ei heti huomata, verrattuna moniin yleisempiin web-välineisiin ja ohjelmointikieliin. Rust on ymmärtääkseni Object-Pascaliakin krantumpi kieli. Tiedä sitten miltä osin parempi tai huonompi.

Lue lisää

AI on korvannut tarpeen junioriohjelmoijille.

Työvoiman vaihtuvuus on jännä asia koska seuraus helposti on se, että sen vaihtuvan työvoiman mukana menee myös tieto liiketoimintaprosesseista ja mihin softa sijoittuu siellä ja mitä sen oikeastaan pitäisi tehdä ja miksi se on tehty niin.

Kaikista krantuin kieli on varmaankin Haskell. Se on niin tiukka, että sillä ei oikein onnistu tekemään mitään jos on mitään riippuvuuksia koska se huomaa lähes kaikki virheet käännösaikana. Se on hyvä, mutta liiketoimintatarpeissa usein kelvoton.

Rust on myös kranttu ja se ratkoo oikeastaan sitä, että miten voi tehdä natiivikoodia ilman roskien kerääjää niin että välttäisi bugeja. Kärsii vähän samasta ongelmasta myös kuin Haskell.

Yritysmaailmassa sitten tavallisesti paras on hyvän yleissuorituskyvyn tarjoavat, vahvasti tyypitetyt kielet joissa ei ole pointtereita. Java ja C# ratkovat tämän että näillä tehdään niitä liiketoimintasovelluksia, kääntäjä tarkistaa paljon asioita ja niihin saa myös pultattua kiinni verifiointityökaluja. Luotettavuussyistä ihan normaalia myös että ei käydä pelleilemään concurrencyn kanssa. Eli vakioitu kieli, vakioitu siisti framework, arkkitehturi vakioidaan ja sillä sitten tekemistä ilman pelleilyä. Jos oliot ei nappaa ja tarvitsee concurrencyä niin sitten löytyy vaikka Go ja Erlang.

Sitten kun kielessä on heikkoa tyypitystä, pointtereita, ohjelmoija huolehtii itse muistin varauksesta ja vapautuksesta niin sitten ollaan niissä vähemmän krantuissa kielissä joilla ohjelmoijat tekevät helpommin bugeja.

Ja kun puhutaan oikeasti virheettömyyteen tähtäävistä ohjelmista joita käytetään siellä missä ihmishenget ovat kyseessä, niin niissä on tiukat vaatimukset. C ja Ada ovat olleet pitkään käytössä mutta niillä ei noin vain sitä C:tä kirjoiteta, että prosessit ja työkalut ovat todella tiukat.

Rust ja ObjectPascal kärsivät siitä, että kieleltä puuttuu formaali spesifikaatio joten työkalujakaan ei voi varmistaa. Tilanne vähän se, että "Rustin spesifikaatio" on Rust kääntäjä ja "ObjectPascalin spesifikaatio" on FreePascal, paitsi Delphi ehkä erilainen.

Rustiahan on koitettu saada myös Linuxiin mutta tilannehan on se, että se ei vaan oikein toimi. ObjectPascalin kanssa tilanne olisi paljon kauheampi.

Rustissa kyllä sitten merkittävästi parempi suorituskyky verrattuna melkein mihin tahansa, että sehän on lähellä C:tä joka on pakotettu tietynlaiseksi, oikein toimivaksi mutta ei se nyt ihan ongelmaton ole tai joka paikkaan sopiva.

Anonyymi kirjoitti:

AI on korvannut tarpeen junioriohjelmoijille.

Työvoiman vaihtuvuus on jännä asia koska seuraus helposti on se, että sen vaihtuvan työvoiman mukana menee myös tieto liiketoimintaprosesseista ja mihin softa sijoittuu siellä ja mitä sen oikeastaan pitäisi tehdä ja miksi se on tehty niin.

Kaikista krantuin kieli on varmaankin Haskell. Se on niin tiukka, että sillä ei oikein onnistu tekemään mitään jos on mitään riippuvuuksia koska se huomaa lähes kaikki virheet käännösaikana. Se on hyvä, mutta liiketoimintatarpeissa usein kelvoton.

Rust on myös kranttu ja se ratkoo oikeastaan sitä, että miten voi tehdä natiivikoodia ilman roskien kerääjää niin että välttäisi bugeja. Kärsii vähän samasta ongelmasta myös kuin Haskell.

Yritysmaailmassa sitten tavallisesti paras on hyvän yleissuorituskyvyn tarjoavat, vahvasti tyypitetyt kielet joissa ei ole pointtereita. Java ja C# ratkovat tämän että näillä tehdään niitä liiketoimintasovelluksia, kääntäjä tarkistaa paljon asioita ja niihin saa myös pultattua kiinni verifiointityökaluja. Luotettavuussyistä ihan normaalia myös että ei käydä pelleilemään concurrencyn kanssa. Eli vakioitu kieli, vakioitu siisti framework, arkkitehturi vakioidaan ja sillä sitten tekemistä ilman pelleilyä. Jos oliot ei nappaa ja tarvitsee concurrencyä niin sitten löytyy vaikka Go ja Erlang.

Sitten kun kielessä on heikkoa tyypitystä, pointtereita, ohjelmoija huolehtii itse muistin varauksesta ja vapautuksesta niin sitten ollaan niissä vähemmän krantuissa kielissä joilla ohjelmoijat tekevät helpommin bugeja.

Ja kun puhutaan oikeasti virheettömyyteen tähtäävistä ohjelmista joita käytetään siellä missä ihmishenget ovat kyseessä, niin niissä on tiukat vaatimukset. C ja Ada ovat olleet pitkään käytössä mutta niillä ei noin vain sitä C:tä kirjoiteta, että prosessit ja työkalut ovat todella tiukat.

Rust ja ObjectPascal kärsivät siitä, että kieleltä puuttuu formaali spesifikaatio joten työkalujakaan ei voi varmistaa. Tilanne vähän se, että "Rustin spesifikaatio" on Rust kääntäjä ja "ObjectPascalin spesifikaatio" on FreePascal, paitsi Delphi ehkä erilainen.

Rustiahan on koitettu saada myös Linuxiin mutta tilannehan on se, että se ei vaan oikein toimi. ObjectPascalin kanssa tilanne olisi paljon kauheampi.

Rustissa kyllä sitten merkittävästi parempi suorituskyky verrattuna melkein mihin tahansa, että sehän on lähellä C:tä joka on pakotettu tietynlaiseksi, oikein toimivaksi mutta ei se nyt ihan ongelmaton ole tai joka paikkaan sopiva.

Lue lisää

Kaiketi itse Rust vakikehitysympäristöineen toimii ihan hyvin Linuxissa, mutta koodin päivittäminen itse Linuxiin on ollut ymmärtääkseni isompi huki kuin olettivat. Ongelma ilmeisesti on pikemminkin "politikoinnissa" kuin itse Rustissa ja helpompi olisi kehittää yhteensopiva uusi Linux kuin päivittää olemassa olevaa (jos oikein ymmärsin erästä mukana ollutta joka hommasta oli saanut burnoutin).

Anonyymi kirjoitti:

Kaiketi itse Rust vakikehitysympäristöineen toimii ihan hyvin Linuxissa, mutta koodin päivittäminen itse Linuxiin on ollut ymmärtääkseni isompi huki kuin olettivat. Ongelma ilmeisesti on pikemminkin "politikoinnissa" kuin itse Rustissa ja helpompi olisi kehittää yhteensopiva uusi Linux kuin päivittää olemassa olevaa (jos oikein ymmärsin erästä mukana ollutta joka hommasta oli saanut burnoutin).

Lue lisää

Kyse on ihan siitä, että Linuxissa kymmeniä miljoonia rivejä koodia jotka tehty toimimaan tietyllä tavalla ja maailma toimii sen varassa. Se ei muutu Rustin tavalle ideologisista syistä, vaan Rustin pitää muuttua Linuxin tavalle ja tämä aiheuttaa sen ongelman.

Parempi idea olisi tehdä kerneli puhtaasti uusiksi Rustilla jos siltä tuntuu mutta mielestäni olisi parempi idea miettiä tähän ihan oma kielensä vaikka että sopisi sitten myös niihin tarkoituksiin missä Linuxia ei voi nyt käyttää.

Anonyymi kirjoitti:

Kyse on ihan siitä, että Linuxissa kymmeniä miljoonia rivejä koodia jotka tehty toimimaan tietyllä tavalla ja maailma toimii sen varassa. Se ei muutu Rustin tavalle ideologisista syistä, vaan Rustin pitää muuttua Linuxin tavalle ja tämä aiheuttaa sen ongelman.

Parempi idea olisi tehdä kerneli puhtaasti uusiksi Rustilla jos siltä tuntuu mutta mielestäni olisi parempi idea miettiä tähän ihan oma kielensä vaikka että sopisi sitten myös niihin tarkoituksiin missä Linuxia ei voi nyt käyttää.

Lue lisää

En ollut kuullutkaan että Rustin takana olisi jotain ideologiaa, tai sen käyttämiseksi Linuxin koodaamisessa. Mikä tuo ideologia on?

Entä millaisia nuo käyttötarkoitukset ovat joihin Linux ei taivu nykyisin sen kehittämisessä käytettyjen ohjelmointikielten takia (C & C++)?

Anonyymi kirjoitti:

Todella aikakriittisissä asioissa sitten käännetään koodi suoraan raudalle että jätetään käyttöjärjestelmä pois tai käytetään jotain hard realtime OS:ia.

Sulautetut järjestelmät ovat aivan eri maailmansa verrattuna PC-koneisiin ja vastaaviin. Molempia voi ohjelmoida C-kielellä, mutta aika nopeasti siihen yhtäläisyyden loppuvatkin. Pieneen kontrolleriin ei ehkä edes teorissa mahdu käyttöjärjestelmää.

Anonyymi kirjoitti:

En ollut kuullutkaan että Rustin takana olisi jotain ideologiaa, tai sen käyttämiseksi Linuxin koodaamisessa. Mikä tuo ideologia on?

Entä millaisia nuo käyttötarkoitukset ovat joihin Linux ei taivu nykyisin sen kehittämisessä käytettyjen ohjelmointikielten takia (C & C )?

Lue lisää

"En ollut kuullutkaan että Rustin takana olisi jotain ideologiaa, tai sen käyttämiseksi Linuxin koodaamisessa. Mikä tuo ideologia on?"

Sellainen ideologia että käytetään eri kieltä mikä hommaan soveltuu. En tiedä tarkemmin.

"Entä millaisia nuo käyttötarkoitukset ovat joihin Linux ei taivu nykyisin sen kehittämisessä käytettyjen ohjelmointikielten takia (C & C++)?"

Linuxissa ei kielet rajoita mitään. Sen sijaan Linuxia ei ole suunniteltu käytettäväksi kohteissa joissa vikatilanteet voivat tappaa ihmisiä. Tuon ominaisuuden saaminen tarkoittaisi käytännössä sitä, että pitäisi tehdä uusiksi.

Tekemällä uuden kielen vartavasten kernelin kehitystä varten voisi kieleen ohjelmoida joitakin tällä tasolla ilmeneviä asioita ja siltä osin tehdä työstä yksinkertaisempaa ja yksinkertaistaa myös verifiointia jos tähän tehty uusi kieli tehdään tästä tätä huomioiden.

Rustia ei ole tehty tätä huomioiden, joten se ei hyödytä.

Anonyymi kirjoitti:

"En ollut kuullutkaan että Rustin takana olisi jotain ideologiaa, tai sen käyttämiseksi Linuxin koodaamisessa. Mikä tuo ideologia on?"

Sellainen ideologia että käytetään eri kieltä mikä hommaan soveltuu. En tiedä tarkemmin.

"Entä millaisia nuo käyttötarkoitukset ovat joihin Linux ei taivu nykyisin sen kehittämisessä käytettyjen ohjelmointikielten takia (C & C )?"

Linuxissa ei kielet rajoita mitään. Sen sijaan Linuxia ei ole suunniteltu käytettäväksi kohteissa joissa vikatilanteet voivat tappaa ihmisiä. Tuon ominaisuuden saaminen tarkoittaisi käytännössä sitä, että pitäisi tehdä uusiksi.

Tekemällä uuden kielen vartavasten kernelin kehitystä varten voisi kieleen ohjelmoida joitakin tällä tasolla ilmeneviä asioita ja siltä osin tehdä työstä yksinkertaisempaa ja yksinkertaistaa myös verifiointia jos tähän tehty uusi kieli tehdään tästä tätä huomioiden.

Rustia ei ole tehty tätä huomioiden, joten se ei hyödytä.

Lue lisää

Rust on juurikin suunniteltu järjestelmäohjelmointiin että siinä mielessä toki Linuxin ohjelmointiin soveltuu, joskin ehkä ideologian puolelle voisi mennä jos kielenvaihto on itsetarkoitus. Kaiketi motivaattorina joku ajatus tai useampi kuitenkin on.

Itse näkisin uudelle kielelle ennemminkin tilausta sovellusohjelmointi- ja web-sovelluspuolella. Liekö yhdessäkään kielessä tällä hetkellä "standardoitua" helppokäyttöistä tukea graafisen käyttöliittymän ja suojausten käyttöön sekä nettikommunikaatioon. Rustiinkin on tarjolla lukemattomia gui-kirjastoja omine syntakseineen eikä niiden kehityksen jatkosta ole mitään takeita.

Anonyymi kirjoitti:

Rust on juurikin suunniteltu järjestelmäohjelmointiin että siinä mielessä toki Linuxin ohjelmointiin soveltuu, joskin ehkä ideologian puolelle voisi mennä jos kielenvaihto on itsetarkoitus. Kaiketi motivaattorina joku ajatus tai useampi kuitenkin on.

Itse näkisin uudelle kielelle ennemminkin tilausta sovellusohjelmointi- ja web-sovelluspuolella. Liekö yhdessäkään kielessä tällä hetkellä "standardoitua" helppokäyttöistä tukea graafisen käyttöliittymän ja suojausten käyttöön sekä nettikommunikaatioon. Rustiinkin on tarjolla lukemattomia gui-kirjastoja omine syntakseineen eikä niiden kehityksen jatkosta ole mitään takeita.

Lue lisää

"Rust on juurikin suunniteltu järjestelmäohjelmointiin että siinä mielessä toki Linuxin ohjelmointiin soveltuu, joskin ehkä ideologian puolelle voisi mennä jos kielenvaihto on itsetarkoitus. Kaiketi motivaattorina joku ajatus tai useampi kuitenkin on."

Ottaen huomioon, että Linux on 33v ikäinen, kirjoitettu standardisoidulla kielellä josta on pari versiota ja vanhojakin tajuaa kääntäjät, ja Rust kieli muuttuu kääntäjän vaihtaessa versiota niin se on tuohon projektiin vähän huono. Johonkin kokeilujuttuun varmaan ihan kiva jos haluaa tutkia miten Rustin borrow checker yms. jutut pelaa kerneliä tehtäessä mutta se olisi uusi projekti.

"Itse näkisin uudelle kielelle ennemminkin tilausta sovellusohjelmointi- ja web-sovelluspuolella."

No melkein kaikki uudet kielet ovat tehty tähän tämän vuosituhannen puolella, että ei sieltä kieliä puutu.

"Liekö yhdessäkään kielessä tällä hetkellä "standardoitua" helppokäyttöistä tukea graafisen käyttöliittymän ja suojausten käyttöön sekä nettikommunikaatioon. "

Itse kielessä ei, mutta standardisoitu tapa löytyy Javascriptistä. Mutta Javascript itsessään on tavan assembler, että siihen käännetään muista kielistä. Mutta se on standardi.

Kieliä jotka kääntävät Javascriptille ja jotka sitten mahdollistavat tämän API:n käytön on sitten paljon. Typescript on yksi sellainen joka käytännössä on viimeisin versio Javascriptistä laajennettuna tyypityksellä. Tyypitys ei kuitenkaan ole "aito", vaan on sitä voi merkata koodiin niitä tyyppejä, että kääntäjällä on haisua asiasta ja älähtää sitten. Että sillä saa sitten suojattua sitä koodia, varsin hyvin itseasisassa.

Mutta koska se eri oikeasti ole vahvasti tyypitetty niin tuo voi vähän vuotaa sitten nettikommunikaation yhteydessä, että pitää oikeasti saada data toisesta koneesta siinä muodossa, miten tyypityksen tekee Typescriptillä. Sitten tuossa voi käyttää myös Javascript ekosysteemin kilkkeitä että integroituu niiden kanssa. Tuo on todella turvallinen vaihtoehto koska jos Microsoftia ei kiinnosta Typescriptin kehitys ja ylläpito ja mikäli ketään muutakaan ei kiinnosta eikä itsekään jaksa niin tarvittaessa Typescript koodin voi kääntää Javascriptille ja ylläpitää sitä sitten.

Sitten löytyy niitä tiukempia kieliä myös, vaikka Elm tai Purescript. Eivät ole standardeja mutta muistuttavat paljon standardisoitua Haskellia, sovitettu vaan UI puolelle. En ole katsonut minkälaista se näiden kääntämä Javascript on, se ei välttämättä ole enää ylläpidettävissä niin kivasti. Reason olisi sitten kieli mikä vähän vastaava kuin Elm ja Purescript mutta se sitten on syntaksiltaan ML:n sukuinen. Se näyttää tekevän koodia joka on tarvittaessa ylläpidettävissä Javascriptina.

Mielestäni Typescript ollut kätevin kieli käyttöliittymien teossa viimeiset 7v tms. Sillä saa tehtyä todella siistiä koodia ja niin kauan kun se koodin scope pysyy Typescriptissä, se on kohtalaisen suojattua virheiltä kun laittaa kääntäjävivut kireälle. Nuo tiukemmat kielet ovat kankeita.

Mutta, sovellusohjelmointipuolessa vastaan tulee se, että standardit eivät ihan riitä sovellusohjelmointiin vaan tarvitsevat jonkinlaista frameworkkia käyttöliittymäelementtien kirjoittamiseen ja tilanhallintaan, että vaikka löytyy standardi API ja kieli jolle käännetään on standardi, niin siinä helposti on vähän muutakin sitten.

Anonyymi kirjoitti:

"Rust on juurikin suunniteltu järjestelmäohjelmointiin että siinä mielessä toki Linuxin ohjelmointiin soveltuu, joskin ehkä ideologian puolelle voisi mennä jos kielenvaihto on itsetarkoitus. Kaiketi motivaattorina joku ajatus tai useampi kuitenkin on."

Ottaen huomioon, että Linux on 33v ikäinen, kirjoitettu standardisoidulla kielellä josta on pari versiota ja vanhojakin tajuaa kääntäjät, ja Rust kieli muuttuu kääntäjän vaihtaessa versiota niin se on tuohon projektiin vähän huono. Johonkin kokeilujuttuun varmaan ihan kiva jos haluaa tutkia miten Rustin borrow checker yms. jutut pelaa kerneliä tehtäessä mutta se olisi uusi projekti.

"Itse näkisin uudelle kielelle ennemminkin tilausta sovellusohjelmointi- ja web-sovelluspuolella."

No melkein kaikki uudet kielet ovat tehty tähän tämän vuosituhannen puolella, että ei sieltä kieliä puutu.

"Liekö yhdessäkään kielessä tällä hetkellä "standardoitua" helppokäyttöistä tukea graafisen käyttöliittymän ja suojausten käyttöön sekä nettikommunikaatioon. "

Itse kielessä ei, mutta standardisoitu tapa löytyy Javascriptistä. Mutta Javascript itsessään on tavan assembler, että siihen käännetään muista kielistä. Mutta se on standardi.

Kieliä jotka kääntävät Javascriptille ja jotka sitten mahdollistavat tämän API:n käytön on sitten paljon. Typescript on yksi sellainen joka käytännössä on viimeisin versio Javascriptistä laajennettuna tyypityksellä. Tyypitys ei kuitenkaan ole "aito", vaan on sitä voi merkata koodiin niitä tyyppejä, että kääntäjällä on haisua asiasta ja älähtää sitten. Että sillä saa sitten suojattua sitä koodia, varsin hyvin itseasisassa.

Mutta koska se eri oikeasti ole vahvasti tyypitetty niin tuo voi vähän vuotaa sitten nettikommunikaation yhteydessä, että pitää oikeasti saada data toisesta koneesta siinä muodossa, miten tyypityksen tekee Typescriptillä. Sitten tuossa voi käyttää myös Javascript ekosysteemin kilkkeitä että integroituu niiden kanssa. Tuo on todella turvallinen vaihtoehto koska jos Microsoftia ei kiinnosta Typescriptin kehitys ja ylläpito ja mikäli ketään muutakaan ei kiinnosta eikä itsekään jaksa niin tarvittaessa Typescript koodin voi kääntää Javascriptille ja ylläpitää sitä sitten.

Sitten löytyy niitä tiukempia kieliä myös, vaikka Elm tai Purescript. Eivät ole standardeja mutta muistuttavat paljon standardisoitua Haskellia, sovitettu vaan UI puolelle. En ole katsonut minkälaista se näiden kääntämä Javascript on, se ei välttämättä ole enää ylläpidettävissä niin kivasti. Reason olisi sitten kieli mikä vähän vastaava kuin Elm ja Purescript mutta se sitten on syntaksiltaan ML:n sukuinen. Se näyttää tekevän koodia joka on tarvittaessa ylläpidettävissä Javascriptina.

Mielestäni Typescript ollut kätevin kieli käyttöliittymien teossa viimeiset 7v tms. Sillä saa tehtyä todella siistiä koodia ja niin kauan kun se koodin scope pysyy Typescriptissä, se on kohtalaisen suojattua virheiltä kun laittaa kääntäjävivut kireälle. Nuo tiukemmat kielet ovat kankeita.

Mutta, sovellusohjelmointipuolessa vastaan tulee se, että standardit eivät ihan riitä sovellusohjelmointiin vaan tarvitsevat jonkinlaista frameworkkia käyttöliittymäelementtien kirjoittamiseen ja tilanhallintaan, että vaikka löytyy standardi API ja kieli jolle käännetään on standardi, niin siinä helposti on vähän muutakin sitten.

Lue lisää

1/4 Kysyin ChatGPT:ltä: "Kuinka typescriptillä muodostetaan dialogi-ikkuna näytölle?"

vastaus:

Vaihe 1: Luo dialogi-ikkuna HTML

<!DOCTYPE html>
<html lang="fi">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Dialogi-ikkuna</title>
</head>
<body>

<dialog id="myDialog">
<p>Tämä on dialogi-ikkuna!</p>
<button id="closeButton">Sulje</button>
</dialog>


<button id="openButton">Avaa Dialogi</button>

<script src="app.js"></script>
</body>
</html>

Vaihe 2: TypeScript-koodi (app.ts)
Seuraavaksi luodaan TypeScript-koodilla logiikka dialogin avaamiselle ja sulkemiselle.

// Haetaan dialogi-ikkuna ja nappulat DOM:sta
const dialog = document.getElementById('myDialog') as HTMLDialogElement;
const openButton = document.getElementById('openButton') as HTMLButtonElement;
const closeButton = document.getElementById('closeButton') as HTMLButtonElement;

// Avaa dialogi-ikkuna, kun käyttäjä klikkaa "Avaa Dialogi" -nappulaa
openButton.addEventListener('click', () => {
dialog.showModal(); // showModal tekee dialogista modaalisen
});

// Sulkee dialogi-ikkunan, kun käyttäjä klikkaa "Sulje" -nappulaa
closeButton.addEventListener('click', () => {
dialog.close();
});

Vaihe 3: Käännä TypeScript
Käännä TypeScript-koodi JavaScriptiksi komennolla:

tsc app.ts

Anonyymi kirjoitti:

"Rust on juurikin suunniteltu järjestelmäohjelmointiin että siinä mielessä toki Linuxin ohjelmointiin soveltuu, joskin ehkä ideologian puolelle voisi mennä jos kielenvaihto on itsetarkoitus. Kaiketi motivaattorina joku ajatus tai useampi kuitenkin on."

Ottaen huomioon, että Linux on 33v ikäinen, kirjoitettu standardisoidulla kielellä josta on pari versiota ja vanhojakin tajuaa kääntäjät, ja Rust kieli muuttuu kääntäjän vaihtaessa versiota niin se on tuohon projektiin vähän huono. Johonkin kokeilujuttuun varmaan ihan kiva jos haluaa tutkia miten Rustin borrow checker yms. jutut pelaa kerneliä tehtäessä mutta se olisi uusi projekti.

"Itse näkisin uudelle kielelle ennemminkin tilausta sovellusohjelmointi- ja web-sovelluspuolella."

No melkein kaikki uudet kielet ovat tehty tähän tämän vuosituhannen puolella, että ei sieltä kieliä puutu.

"Liekö yhdessäkään kielessä tällä hetkellä "standardoitua" helppokäyttöistä tukea graafisen käyttöliittymän ja suojausten käyttöön sekä nettikommunikaatioon. "

Itse kielessä ei, mutta standardisoitu tapa löytyy Javascriptistä. Mutta Javascript itsessään on tavan assembler, että siihen käännetään muista kielistä. Mutta se on standardi.

Kieliä jotka kääntävät Javascriptille ja jotka sitten mahdollistavat tämän API:n käytön on sitten paljon. Typescript on yksi sellainen joka käytännössä on viimeisin versio Javascriptistä laajennettuna tyypityksellä. Tyypitys ei kuitenkaan ole "aito", vaan on sitä voi merkata koodiin niitä tyyppejä, että kääntäjällä on haisua asiasta ja älähtää sitten. Että sillä saa sitten suojattua sitä koodia, varsin hyvin itseasisassa.

Mutta koska se eri oikeasti ole vahvasti tyypitetty niin tuo voi vähän vuotaa sitten nettikommunikaation yhteydessä, että pitää oikeasti saada data toisesta koneesta siinä muodossa, miten tyypityksen tekee Typescriptillä. Sitten tuossa voi käyttää myös Javascript ekosysteemin kilkkeitä että integroituu niiden kanssa. Tuo on todella turvallinen vaihtoehto koska jos Microsoftia ei kiinnosta Typescriptin kehitys ja ylläpito ja mikäli ketään muutakaan ei kiinnosta eikä itsekään jaksa niin tarvittaessa Typescript koodin voi kääntää Javascriptille ja ylläpitää sitä sitten.

Sitten löytyy niitä tiukempia kieliä myös, vaikka Elm tai Purescript. Eivät ole standardeja mutta muistuttavat paljon standardisoitua Haskellia, sovitettu vaan UI puolelle. En ole katsonut minkälaista se näiden kääntämä Javascript on, se ei välttämättä ole enää ylläpidettävissä niin kivasti. Reason olisi sitten kieli mikä vähän vastaava kuin Elm ja Purescript mutta se sitten on syntaksiltaan ML:n sukuinen. Se näyttää tekevän koodia joka on tarvittaessa ylläpidettävissä Javascriptina.

Mielestäni Typescript ollut kätevin kieli käyttöliittymien teossa viimeiset 7v tms. Sillä saa tehtyä todella siistiä koodia ja niin kauan kun se koodin scope pysyy Typescriptissä, se on kohtalaisen suojattua virheiltä kun laittaa kääntäjävivut kireälle. Nuo tiukemmat kielet ovat kankeita.

Mutta, sovellusohjelmointipuolessa vastaan tulee se, että standardit eivät ihan riitä sovellusohjelmointiin vaan tarvitsevat jonkinlaista frameworkkia käyttöliittymäelementtien kirjoittamiseen ja tilanhallintaan, että vaikka löytyy standardi API ja kieli jolle käännetään on standardi, niin siinä helposti on vähän muutakin sitten.

Lue lisää

2/4 Kysyin ChatGPT:ltä: "Kuinka elm-kielellä muodostetaan dialogi-ikkuna näytölle?"

vastaus:

Varmista, että sinulla on asennettuna Elm ja tarvittavat riippuvuudet. Luo Elm-projekti ja lisää paketteja tarvittaessa:

bash
Kopioi koodi
elm init
Vaihe 2: Koodi Elmissä
Tässä on täydellinen esimerkki Elm-koodista, joka näyttää dialogi-ikkunan ja antaa käyttäjän avata tai sulkea sen:

elm
Kopioi koodi
module Main exposing (..)

import Browser
import Html exposing (Html, button, div, text)
import Html.Attributes exposing (class)
import Html.Events exposing (onClick)


-- Malli eli sovelluksen tila
type alias Model =
{ isDialogOpen : Bool }


-- Alkuarvot sovellukselle
init : Model
init =
{ isDialogOpen = False }


-- Sovelluksen eri viestit eli tapahtumat
type Msg
= OpenDialog
| CloseDialog


-- Sovelluksen tilan päivittäminen tapahtuman perusteella
update : Msg -> Model -> Model
update msg model =
case msg of
OpenDialog ->
{ model | isDialogOpen = True }

CloseDialog ->
{ model | isDialogOpen = False }


-- Näkymän määrittely
view : Model -> Html Msg
view model =
div []
[ button [ onClick OpenDialog ] [ text "Avaa Dialogi" ]
, viewDialog model
]


-- Dialogin määrittely, joka näkyy vain, jos isDialogOpen on tosi
viewDialog : Model -> Html Msg
viewDialog model =
if model.isDialogOpen then
div [ class "modal" ]
[ div [ class "modal-content" ]
[ text "Tämä on dialogi-ikkuna!"
, button [ onClick CloseDialog ] [ text "Sulje" ]
]
]
else
text ""


-- Pääfunktio sovelluksen ajamiseen
main =
Browser.sandbox { init = init, update = update, view = view }
Vaihe 3: CSS modaalille
Jotta dialogi näyttää modaalilta (keskellä ruutua oleva ikkuna, joka peittää muun sisällön), lisää seuraavanlainen CSS-tiedosto:

css
Kopioi koodi
/* Yleinen dialogin taustatyyli */
.modal {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 100%;
background-color: rgba(0, 0, 0, 0.5);
display: flex;
justify-content: center;
align-items: center;
}

/* Dialogi-ikkunan sisältö */
.modal-content {
background-color: white;
padding: 20px;
border-radius: 5px;
text-align: center;
}

Anonyymi kirjoitti:

"Rust on juurikin suunniteltu järjestelmäohjelmointiin että siinä mielessä toki Linuxin ohjelmointiin soveltuu, joskin ehkä ideologian puolelle voisi mennä jos kielenvaihto on itsetarkoitus. Kaiketi motivaattorina joku ajatus tai useampi kuitenkin on."

Ottaen huomioon, että Linux on 33v ikäinen, kirjoitettu standardisoidulla kielellä josta on pari versiota ja vanhojakin tajuaa kääntäjät, ja Rust kieli muuttuu kääntäjän vaihtaessa versiota niin se on tuohon projektiin vähän huono. Johonkin kokeilujuttuun varmaan ihan kiva jos haluaa tutkia miten Rustin borrow checker yms. jutut pelaa kerneliä tehtäessä mutta se olisi uusi projekti.

"Itse näkisin uudelle kielelle ennemminkin tilausta sovellusohjelmointi- ja web-sovelluspuolella."

No melkein kaikki uudet kielet ovat tehty tähän tämän vuosituhannen puolella, että ei sieltä kieliä puutu.

"Liekö yhdessäkään kielessä tällä hetkellä "standardoitua" helppokäyttöistä tukea graafisen käyttöliittymän ja suojausten käyttöön sekä nettikommunikaatioon. "

Itse kielessä ei, mutta standardisoitu tapa löytyy Javascriptistä. Mutta Javascript itsessään on tavan assembler, että siihen käännetään muista kielistä. Mutta se on standardi.

Kieliä jotka kääntävät Javascriptille ja jotka sitten mahdollistavat tämän API:n käytön on sitten paljon. Typescript on yksi sellainen joka käytännössä on viimeisin versio Javascriptistä laajennettuna tyypityksellä. Tyypitys ei kuitenkaan ole "aito", vaan on sitä voi merkata koodiin niitä tyyppejä, että kääntäjällä on haisua asiasta ja älähtää sitten. Että sillä saa sitten suojattua sitä koodia, varsin hyvin itseasisassa.

Mutta koska se eri oikeasti ole vahvasti tyypitetty niin tuo voi vähän vuotaa sitten nettikommunikaation yhteydessä, että pitää oikeasti saada data toisesta koneesta siinä muodossa, miten tyypityksen tekee Typescriptillä. Sitten tuossa voi käyttää myös Javascript ekosysteemin kilkkeitä että integroituu niiden kanssa. Tuo on todella turvallinen vaihtoehto koska jos Microsoftia ei kiinnosta Typescriptin kehitys ja ylläpito ja mikäli ketään muutakaan ei kiinnosta eikä itsekään jaksa niin tarvittaessa Typescript koodin voi kääntää Javascriptille ja ylläpitää sitä sitten.

Sitten löytyy niitä tiukempia kieliä myös, vaikka Elm tai Purescript. Eivät ole standardeja mutta muistuttavat paljon standardisoitua Haskellia, sovitettu vaan UI puolelle. En ole katsonut minkälaista se näiden kääntämä Javascript on, se ei välttämättä ole enää ylläpidettävissä niin kivasti. Reason olisi sitten kieli mikä vähän vastaava kuin Elm ja Purescript mutta se sitten on syntaksiltaan ML:n sukuinen. Se näyttää tekevän koodia joka on tarvittaessa ylläpidettävissä Javascriptina.

Mielestäni Typescript ollut kätevin kieli käyttöliittymien teossa viimeiset 7v tms. Sillä saa tehtyä todella siistiä koodia ja niin kauan kun se koodin scope pysyy Typescriptissä, se on kohtalaisen suojattua virheiltä kun laittaa kääntäjävivut kireälle. Nuo tiukemmat kielet ovat kankeita.

Mutta, sovellusohjelmointipuolessa vastaan tulee se, että standardit eivät ihan riitä sovellusohjelmointiin vaan tarvitsevat jonkinlaista frameworkkia käyttöliittymäelementtien kirjoittamiseen ja tilanhallintaan, että vaikka löytyy standardi API ja kieli jolle käännetään on standardi, niin siinä helposti on vähän muutakin sitten.

Lue lisää

3/4 Kysyin ChatGPT:ltä: "Kuinka purescriptillä muodostetaan dialogi-ikkuna näytölle?"

Vastaus:

Vaihe 1: Projektin alustaminen
Jos sinulla ei vielä ole PureScript-projektia, luo uusi projekti seuraavasti:

bash
Kopioi koodi
spago init
Lisää sitten tarvittavat riippuvuudet, kuten dom ja effect:

bash
Kopioi koodi
spago install dom effect

Vaihe 2: HTML-tiedosto
Tässä on yksinkertainen HTML, johon dialogi-ikkuna integroidaan:

html
Kopioi koodi
<!DOCTYPE html>
<html lang="fi">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>PureScript Dialogi-ikkuna</title>
</head>
<body>
<button id="openButton">Avaa Dialogi</button>

<div id="dialog" style="display: none; background-color: rgba(0, 0, 0, 0.5); position: fixed; top: 0; left: 0; width: 100%; height: 100%; justify-content: center; align-items: center;">
<div style="background-color: white; padding: 20px; border-radius: 5px;">
<p>Tämä on dialogi-ikkuna!</p>
<button id="closeButton">Sulje</button>
</div>
</div>

<script src="output/Main/index.js"></script>
</body>
</html>

Vaihe 3: PureScript-koodi
Seuraavaksi kirjoitetaan PureScript-koodi, joka hallitsee dialogi-ikkunan avaamista ja sulkemista.

Luo tiedosto src/Main.purs ja lisää seuraava sisältö:

purescript
Kopioi koodi
module Main where

import Prelude
import Effect (Effect)
import Effect.Console (log)
import Effect.Uncurried (EffectFn1, mkEffectFn1)
import Web.DOM (window)
import Web.HTML (window)
import Web.HTML.Window (document)
import Web.HTML.Document (getElementById)
import Web.HTML.HTMLElement (htmlElementToElement)
import Web.HTML.Element (setAttribute)
import Web.HTML.Event (EventType(..), preventDefault)
import Web.HTML.Event.EventTarget (addEventListener)
import Web.HTML.Event.Event (target)
import Web.HTML.HTMLButtonElement (htmlButtonElementToElement)

-- Pääfunktio
main :: Effect Unit
main = do
-- Hae ikkunan dokumentti
doc <- window >>= document

-- Hae dialogi-elementti
dialog <- getElementById "dialog" doc

case dialog of
Just dlg -> do
-- Hae nappula, joka avaa dialogin
openButton <- getElementById "openButton" doc
case openButton of
Just btn -> do
-- Lisää kuuntelija avaamaan dialogi
addEventListener Click (openDialog dlg) (htmlElementToElement btn)
Nothing -> log "Avaa-nappulaa ei löytynyt."

-- Hae nappula, joka sulkee dialogin
closeButton <- getElementById "closeButton" doc
case closeButton of
Just btn -> do
-- Lisää kuuntelija sulkemaan dialogi
addEventListener Click (closeDialog dlg) (htmlElementToElement btn)
Nothing -> log "Sulje-nappulaa ei löytynyt."
Nothing -> log "Dialogi-elementtiä ei löytynyt."

-- Funktio dialogin avaamiseksi
openDialog :: forall a. Element -> EffectFn1 Event a
openDialog dlg = mkEffectFn1 \_ -> do
setAttribute "style" "display: flex;" dlg

-- Funktio dialogin sulkemiseksi
closeDialog :: forall a. Element -> EffectFn1 Event a
closeDialog dlg = mkEffectFn1 \_ -> do
setAttribute "style" "display: none;" dlg

Vaihe 4: Käännä PureScript-koodi
Käännä projekti käyttämällä Spagoa:

bash
Kopioi koodi
spago build

Anonyymi kirjoitti:

"Rust on juurikin suunniteltu järjestelmäohjelmointiin että siinä mielessä toki Linuxin ohjelmointiin soveltuu, joskin ehkä ideologian puolelle voisi mennä jos kielenvaihto on itsetarkoitus. Kaiketi motivaattorina joku ajatus tai useampi kuitenkin on."

Ottaen huomioon, että Linux on 33v ikäinen, kirjoitettu standardisoidulla kielellä josta on pari versiota ja vanhojakin tajuaa kääntäjät, ja Rust kieli muuttuu kääntäjän vaihtaessa versiota niin se on tuohon projektiin vähän huono. Johonkin kokeilujuttuun varmaan ihan kiva jos haluaa tutkia miten Rustin borrow checker yms. jutut pelaa kerneliä tehtäessä mutta se olisi uusi projekti.

"Itse näkisin uudelle kielelle ennemminkin tilausta sovellusohjelmointi- ja web-sovelluspuolella."

No melkein kaikki uudet kielet ovat tehty tähän tämän vuosituhannen puolella, että ei sieltä kieliä puutu.

"Liekö yhdessäkään kielessä tällä hetkellä "standardoitua" helppokäyttöistä tukea graafisen käyttöliittymän ja suojausten käyttöön sekä nettikommunikaatioon. "

Itse kielessä ei, mutta standardisoitu tapa löytyy Javascriptistä. Mutta Javascript itsessään on tavan assembler, että siihen käännetään muista kielistä. Mutta se on standardi.

Kieliä jotka kääntävät Javascriptille ja jotka sitten mahdollistavat tämän API:n käytön on sitten paljon. Typescript on yksi sellainen joka käytännössä on viimeisin versio Javascriptistä laajennettuna tyypityksellä. Tyypitys ei kuitenkaan ole "aito", vaan on sitä voi merkata koodiin niitä tyyppejä, että kääntäjällä on haisua asiasta ja älähtää sitten. Että sillä saa sitten suojattua sitä koodia, varsin hyvin itseasisassa.

Mutta koska se eri oikeasti ole vahvasti tyypitetty niin tuo voi vähän vuotaa sitten nettikommunikaation yhteydessä, että pitää oikeasti saada data toisesta koneesta siinä muodossa, miten tyypityksen tekee Typescriptillä. Sitten tuossa voi käyttää myös Javascript ekosysteemin kilkkeitä että integroituu niiden kanssa. Tuo on todella turvallinen vaihtoehto koska jos Microsoftia ei kiinnosta Typescriptin kehitys ja ylläpito ja mikäli ketään muutakaan ei kiinnosta eikä itsekään jaksa niin tarvittaessa Typescript koodin voi kääntää Javascriptille ja ylläpitää sitä sitten.

Sitten löytyy niitä tiukempia kieliä myös, vaikka Elm tai Purescript. Eivät ole standardeja mutta muistuttavat paljon standardisoitua Haskellia, sovitettu vaan UI puolelle. En ole katsonut minkälaista se näiden kääntämä Javascript on, se ei välttämättä ole enää ylläpidettävissä niin kivasti. Reason olisi sitten kieli mikä vähän vastaava kuin Elm ja Purescript mutta se sitten on syntaksiltaan ML:n sukuinen. Se näyttää tekevän koodia joka on tarvittaessa ylläpidettävissä Javascriptina.

Mielestäni Typescript ollut kätevin kieli käyttöliittymien teossa viimeiset 7v tms. Sillä saa tehtyä todella siistiä koodia ja niin kauan kun se koodin scope pysyy Typescriptissä, se on kohtalaisen suojattua virheiltä kun laittaa kääntäjävivut kireälle. Nuo tiukemmat kielet ovat kankeita.

Mutta, sovellusohjelmointipuolessa vastaan tulee se, että standardit eivät ihan riitä sovellusohjelmointiin vaan tarvitsevat jonkinlaista frameworkkia käyttöliittymäelementtien kirjoittamiseen ja tilanhallintaan, että vaikka löytyy standardi API ja kieli jolle käännetään on standardi, niin siinä helposti on vähän muutakin sitten.

Lue lisää

4/4 mielestäni helppo vaihtoehto olisi tällainen (kuvitteellisella kielellä):

Käynnistetään IDE

Kirjoitetaan lähdekoodi:

application "Dialogi-demo":
dialog(
title:"Kysely",
text:"Onko hyvä pössis?",
button:"Joo",
button:"Ei") vastaus. // vastaus immutable string jollei ennalta esitelty

if vastaus = "Joo" then "Hienoa!" hyvästi
else "Harmi. Tsemppiä!" hyvästi.

dialog(title:"Kysely", text:hyvästi).

Edellä oletetaan että dialog on komponentti, joka sulkeutuu minkä tahansa button-komponentin klikkauksesta, niin sitä ei tarvitse erikseen koodissa sulkea.

Muuttujat saavat tässä kuvitteellisesta kielestä vasemmalta oikealle, jolloin ei tarvita erillistä sijoitusoperaattoria.

Frameworkit ovat mainio työkalu(setti) kun halutaan tehdä sovelluksia tiettyyn muotoon, mutta jos haluaa vähänkään persoonallisempaa ulkonäköä tai toiminnallisuutta, niin menee vaikeaksi.

Tknk kirjoitti:

4/4 mielestäni helppo vaihtoehto olisi tällainen (kuvitteellisella kielellä):

Käynnistetään IDE

Kirjoitetaan lähdekoodi:

application "Dialogi-demo":
dialog(
title:"Kysely",
text:"Onko hyvä pössis?",
button:"Joo",
button:"Ei") vastaus. // vastaus immutable string jollei ennalta esitelty

if vastaus = "Joo" then "Hienoa!" hyvästi
else "Harmi. Tsemppiä!" hyvästi.

dialog(title:"Kysely", text:hyvästi).

Edellä oletetaan että dialog on komponentti, joka sulkeutuu minkä tahansa button-komponentin klikkauksesta, niin sitä ei tarvitse erikseen koodissa sulkea.

Muuttujat saavat tässä kuvitteellisesta kielestä vasemmalta oikealle, jolloin ei tarvita erillistä sijoitusoperaattoria.

Frameworkit ovat mainio työkalu(setti) kun halutaan tehdä sovelluksia tiettyyn muotoon, mutta jos haluaa vähänkään persoonallisempaa ulkonäköä tai toiminnallisuutta, niin menee vaikeaksi.

Lue lisää

Tuossa kuvitteellisessa kielessäni voisi olla oletusarvoisesti Ok-painike dialog-komponentissa siinä tapauksessa ettei muita painikkeita ole määritelty. Muutoinkin tuossa oli taustalla ajatus automaattisista oletusarvoista, joihin ohjelmoijan tarvitsisi kajota vain kun haluaa niistä poikkeavaa toiminnallisuutta.

Tknk kirjoitti:

4/4 mielestäni helppo vaihtoehto olisi tällainen (kuvitteellisella kielellä):

Käynnistetään IDE

Kirjoitetaan lähdekoodi:

application "Dialogi-demo":
dialog(
title:"Kysely",
text:"Onko hyvä pössis?",
button:"Joo",
button:"Ei") vastaus. // vastaus immutable string jollei ennalta esitelty

if vastaus = "Joo" then "Hienoa!" hyvästi
else "Harmi. Tsemppiä!" hyvästi.

dialog(title:"Kysely", text:hyvästi).

Edellä oletetaan että dialog on komponentti, joka sulkeutuu minkä tahansa button-komponentin klikkauksesta, niin sitä ei tarvitse erikseen koodissa sulkea.

Muuttujat saavat tässä kuvitteellisesta kielestä vasemmalta oikealle, jolloin ei tarvita erillistä sijoitusoperaattoria.

Frameworkit ovat mainio työkalu(setti) kun halutaan tehdä sovelluksia tiettyyn muotoon, mutta jos haluaa vähänkään persoonallisempaa ulkonäköä tai toiminnallisuutta, niin menee vaikeaksi.

Lue lisää

Ei noista ChatGPT:n ripulikoodeista tarvitse välittää. Eihän ne edes ole ihan vastaavia, yksi käyttää inline tyylejä, toinen ei ja jne.

Tällä hetkellä dialogin saa näin: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog

Eli ei tarvitse mitään ohjelmointikieltä, kaikki mikä ruudulla näkyy ja osittain myös piilossa, kuvataan dokumenttimallilla jota voi noin kirjoittaa ilman mitään logiikkaa.

Sitten tarvitsee kirjoittaa ne eventit mitä tapahtuu kun klikkaa vaikka sitä nappia. Siinä kohtaa tulee se ohjelmointikieli sitten.

Frameworkit liittyy sitten siihen rakenteeseen ja se on tärkeätä että muutkin ohjelmoijat ymmärtävät koodia. React ja SolidJS sopivat hyvin sovellusten tekemiseen frameworkilla, että alhaalla olevat rajapinnat ovat standardia mutta siinä sitten päällä frameworkkia. Reactia käytetään paljon kun halutaan valmiit komponentit jotka ovat halutun näköisiä, ja sille löytyy käytännössä kaikki tyylit (Apple, Google, Microsoft jne.) mutta SolidJS on hyvä jos haluaa tehdä itse kaiken. Reactillakin se toki onnistuu mutta SolidJS tuntuu olevan vähän nopeampi ja yksinkertaisempi.

Angular on vanhempi, hitaampi ja vielä jäykempi, että se pakottaa sitten sovelluksen kirjoittamiseen tiettyyn muotoon.

Mutta kaikki kirjoitettavat ohjelmat eivät ole sovelluksia vaan ovat sisältöä jota haetaan hakukoneilla vaikka. Näissä on parempi mennä ilman koodia mitä ajetaan käyttöliittymäpuolella, että tekee kaiken palvelimessa ja on sitten ne sivulataukset. Webcomponentit sopivat siihen, että voi jonkun osan käyttöliittymästä eristää omaksi komponentiksi mikä toimii itsenäisesti, että sillä tavalla voi sitä koodia laittaa käyttöliittymäpuolelle.

Tietysti jos hyvin yksinkertaista haluaa niin onhan sitä vielä sitten se Coffeescript, että koodi muistuttaa Pythonia tai Rubyä mutta kääntää sen Javascriptiksi. Sillä saa ehkä tehtyä UI koodia ehkä pienimmällä määrällä koodirivejä jos tekee tyhjästä ilman frameworkkeja mutta se taas ei ollut samalla tavalla suojattu virheiden tekemiseltä kuin Typescript.

Jos nyt haluaisi tehdä tyhjästä ilman mitään frameworkkeja, tekemällä puhdasta koodia vaan standardeilla rajapinnoilla niin Typescript todennäköisesti varma valinta tai sitten jos haluaa natseilla vahvalla tyypityksellä niin Elm/Purescript reitti sitten. En itse pidä Elm/Purescript kuitenkaan tuottavana liiketoimintasovelluksiin. Se vaan on todennäköisesti liian jäykkää tekemistä.

Filosofinen ero Elm:n ja Purescriptin välillä on se, että Purescript sisältää monipuolisemman tyypityksen että olisi mahdollista integroida Javascriptiä. Se on siis monimutkaisempi

Elm taas on tehty tyhjästä ja rajoittaa kaiken vanhan käyttöä, että jos tekee puhtaasti Elm:llä alusta loppuun niin on vahvasti tyypitetty ja yksinkertainen.

Anonyymi kirjoitti:

Ei noista ChatGPT:n ripulikoodeista tarvitse välittää. Eihän ne edes ole ihan vastaavia, yksi käyttää inline tyylejä, toinen ei ja jne.

Tällä hetkellä dialogin saa näin: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog

Eli ei tarvitse mitään ohjelmointikieltä, kaikki mikä ruudulla näkyy ja osittain myös piilossa, kuvataan dokumenttimallilla jota voi noin kirjoittaa ilman mitään logiikkaa.

Sitten tarvitsee kirjoittaa ne eventit mitä tapahtuu kun klikkaa vaikka sitä nappia. Siinä kohtaa tulee se ohjelmointikieli sitten.

Frameworkit liittyy sitten siihen rakenteeseen ja se on tärkeätä että muutkin ohjelmoijat ymmärtävät koodia. React ja SolidJS sopivat hyvin sovellusten tekemiseen frameworkilla, että alhaalla olevat rajapinnat ovat standardia mutta siinä sitten päällä frameworkkia. Reactia käytetään paljon kun halutaan valmiit komponentit jotka ovat halutun näköisiä, ja sille löytyy käytännössä kaikki tyylit (Apple, Google, Microsoft jne.) mutta SolidJS on hyvä jos haluaa tehdä itse kaiken. Reactillakin se toki onnistuu mutta SolidJS tuntuu olevan vähän nopeampi ja yksinkertaisempi.

Angular on vanhempi, hitaampi ja vielä jäykempi, että se pakottaa sitten sovelluksen kirjoittamiseen tiettyyn muotoon.

Mutta kaikki kirjoitettavat ohjelmat eivät ole sovelluksia vaan ovat sisältöä jota haetaan hakukoneilla vaikka. Näissä on parempi mennä ilman koodia mitä ajetaan käyttöliittymäpuolella, että tekee kaiken palvelimessa ja on sitten ne sivulataukset. Webcomponentit sopivat siihen, että voi jonkun osan käyttöliittymästä eristää omaksi komponentiksi mikä toimii itsenäisesti, että sillä tavalla voi sitä koodia laittaa käyttöliittymäpuolelle.

Tietysti jos hyvin yksinkertaista haluaa niin onhan sitä vielä sitten se Coffeescript, että koodi muistuttaa Pythonia tai Rubyä mutta kääntää sen Javascriptiksi. Sillä saa ehkä tehtyä UI koodia ehkä pienimmällä määrällä koodirivejä jos tekee tyhjästä ilman frameworkkeja mutta se taas ei ollut samalla tavalla suojattu virheiden tekemiseltä kuin Typescript.

Jos nyt haluaisi tehdä tyhjästä ilman mitään frameworkkeja, tekemällä puhdasta koodia vaan standardeilla rajapinnoilla niin Typescript todennäköisesti varma valinta tai sitten jos haluaa natseilla vahvalla tyypityksellä niin Elm/Purescript reitti sitten. En itse pidä Elm/Purescript kuitenkaan tuottavana liiketoimintasovelluksiin. Se vaan on todennäköisesti liian jäykkää tekemistä.

Filosofinen ero Elm:n ja Purescriptin välillä on se, että Purescript sisältää monipuolisemman tyypityksen että olisi mahdollista integroida Javascriptiä. Se on siis monimutkaisempi

Elm taas on tehty tyhjästä ja rajoittaa kaiken vanhan käyttöä, että jos tekee puhtaasti Elm:llä alusta loppuun niin on vahvasti tyypitetty ja yksinkertainen.

Lue lisää

Varmastikin hyviä vinkkejä nuo, jos joku tätä ketjua läpi kahlatessaan on etsimässä välineitä web-kehitykseen. Taitaa suurin haaste kehityksessä olla valinnan vaikeus kun vaihtoehtoja on runsaasti ja jotta pystyy valitsemaan fiksusti, niin niihin pitää perehtyä. Sen sijaan että olisi yksi standardi tapa, ja extroihin tarvitsisi perehtyä vasta kun standardipaletilla ei pärjää.

Kun hiilijalanjäljestä ollaan nykyään kovin huolissaan, niin harvemmin törmää softan hiilijalanjäljestä keskusteluun. Ensimmäisenä tuo taisi nousta pintaa epäsuorasti kryptovaluuttojen louhinnan virrankulutuksen ja hiljan AI:n sähkön tarpeen kasvun myötä. Sen sijaan en muista että kukaan olisi peräänkuuluttanut ekotehokkaampia kääntäjiä tai JVM:iä puhumattakaan ohjelmistojen siirtämistä tulkattavista kielistä käännettäviin.

Tknk kirjoitti:

Varmastikin hyviä vinkkejä nuo, jos joku tätä ketjua läpi kahlatessaan on etsimässä välineitä web-kehitykseen. Taitaa suurin haaste kehityksessä olla valinnan vaikeus kun vaihtoehtoja on runsaasti ja jotta pystyy valitsemaan fiksusti, niin niihin pitää perehtyä. Sen sijaan että olisi yksi standardi tapa, ja extroihin tarvitsisi perehtyä vasta kun standardipaletilla ei pärjää.

Kun hiilijalanjäljestä ollaan nykyään kovin huolissaan, niin harvemmin törmää softan hiilijalanjäljestä keskusteluun. Ensimmäisenä tuo taisi nousta pintaa epäsuorasti kryptovaluuttojen louhinnan virrankulutuksen ja hiljan AI:n sähkön tarpeen kasvun myötä. Sen sijaan en muista että kukaan olisi peräänkuuluttanut ekotehokkaampia kääntäjiä tai JVM:iä puhumattakaan ohjelmistojen siirtämistä tulkattavista kielistä käännettäviin.

Lue lisää

Niin standardihan on mutta kukaan ei tykkää puhtaalla javascriptillä tehdä mitään sovelluksia ja siitä tuskin ymmärtäisi muut kun siinä jää niin paljon kehittäjän tekemien päätösten varaan.

Käytännössä se standardipaletti riittää nykyään perusteiden opiskeluun, sitten jos haluaa jotain tehdä niin tarvitsee vähän lisätä jotain.

Softan hiilijalanjäljestä puhutaan kyllä ja energiatehokkuudesta ja olen siitä aika hyvin perillä.

Tällä hetkellä hiilijalanjäljen kannalta merkittävä ongelma on laitteiden suunniteltu vanheneminen, että täysin käyttökelpoisia laitteita menee roskiin kun joku ohjelma vanhenee. Standardien käyttö ohjelmoinnissa ehkäisee tuota, että standardien mukaan tehty ohjelma voi toimia hyvinkin vanhoissa laitteissa.

Ohjelmissa sitten on se tallentava osa datakeskuksissa ja datakeskusten energiatehokkuudessa on sellainen hieno asia, että siellä on hintaohjaus. Energiatehokkuus tuntuu suoraan kuukausilaskussa, että on parempi optimoida. Käytännössä mitä halvemmaksi tekee, sitä vähemmän vie sähköä.

Yleisesti ottaen hinnassa tuntuu juurikin tietokannat ja tallennusratkaisu, ja sitten taustajärjestelmä itsessään niin jos se on 24/7 tekemässä jotain, muisti ei tunnu missään että sitä voi käyttää optimoimaan kantahakuja kun minimimäärä mistä lähdetään on giga. Koko optimointi lähtee aina siitä, että miettii sopivimman tietokantaratkaisun ja missä muodossa data on.

Jos kuormitus vaihtelee niin on hyväkin idea optimoida järjestelmä niin, että lisää palvelimia laitetaan tarvittaessa kuorman kasvaessa ja jos ei ole kuormaa, sammutetaan ne palvelimet.

Mobiililaitteiden tapauksessa tehokkuuteen on kiinnitetty huomiota, että jos on tehoton niin on huono käyttötuntuma ja se syö akun tyhjäksi.

Natiivikoodia käytetään kyllä palvelimissa mutta sovelluksen käyttöliittymäpuolella natiivikoodi toimii huonosti johtuen kaikenkirjavista laitteista. Käytännössä ohjelmille tehdään Just-in-time kääntö.

Helpoin tapa optimoida energian kulutusta käyttöliittymäpuolella on tietenkin suosia energiatehokkaampia laitteita. Koodin viilaus ei tunnu missään jos laite rohmuaa sähköä idlelläkin.

Kääntäjät ja JVM:t ovat varsin ekotehokkaita.

Anonyymi kirjoitti:

Niin standardihan on mutta kukaan ei tykkää puhtaalla javascriptillä tehdä mitään sovelluksia ja siitä tuskin ymmärtäisi muut kun siinä jää niin paljon kehittäjän tekemien päätösten varaan.

Käytännössä se standardipaletti riittää nykyään perusteiden opiskeluun, sitten jos haluaa jotain tehdä niin tarvitsee vähän lisätä jotain.

Softan hiilijalanjäljestä puhutaan kyllä ja energiatehokkuudesta ja olen siitä aika hyvin perillä.

Tällä hetkellä hiilijalanjäljen kannalta merkittävä ongelma on laitteiden suunniteltu vanheneminen, että täysin käyttökelpoisia laitteita menee roskiin kun joku ohjelma vanhenee. Standardien käyttö ohjelmoinnissa ehkäisee tuota, että standardien mukaan tehty ohjelma voi toimia hyvinkin vanhoissa laitteissa.

Ohjelmissa sitten on se tallentava osa datakeskuksissa ja datakeskusten energiatehokkuudessa on sellainen hieno asia, että siellä on hintaohjaus. Energiatehokkuus tuntuu suoraan kuukausilaskussa, että on parempi optimoida. Käytännössä mitä halvemmaksi tekee, sitä vähemmän vie sähköä.

Yleisesti ottaen hinnassa tuntuu juurikin tietokannat ja tallennusratkaisu, ja sitten taustajärjestelmä itsessään niin jos se on 24/7 tekemässä jotain, muisti ei tunnu missään että sitä voi käyttää optimoimaan kantahakuja kun minimimäärä mistä lähdetään on giga. Koko optimointi lähtee aina siitä, että miettii sopivimman tietokantaratkaisun ja missä muodossa data on.

Jos kuormitus vaihtelee niin on hyväkin idea optimoida järjestelmä niin, että lisää palvelimia laitetaan tarvittaessa kuorman kasvaessa ja jos ei ole kuormaa, sammutetaan ne palvelimet.

Mobiililaitteiden tapauksessa tehokkuuteen on kiinnitetty huomiota, että jos on tehoton niin on huono käyttötuntuma ja se syö akun tyhjäksi.

Natiivikoodia käytetään kyllä palvelimissa mutta sovelluksen käyttöliittymäpuolella natiivikoodi toimii huonosti johtuen kaikenkirjavista laitteista. Käytännössä ohjelmille tehdään Just-in-time kääntö.

Helpoin tapa optimoida energian kulutusta käyttöliittymäpuolella on tietenkin suosia energiatehokkaampia laitteita. Koodin viilaus ei tunnu missään jos laite rohmuaa sähköä idlelläkin.

Kääntäjät ja JVM:t ovat varsin ekotehokkaita.

Lue lisää

Liekö suunniteltu vanheneminen enemmänkin urbaania legendaa kuin todellinen toiminnan motiivi. Laitteethan kannattaa suunnitella mahdollisimman halvoiksi ja kestämään tavoitellun käyttöiän hyväksyttävällä takuuajan vikaantumisprosentilla. Aiemmin kun ei osattu vielä optimoida, niin tehtiin tarpeettoman hyvää. Monella on varastoissaan kymmeniä vuosia vanhoja mikroja, jotka toimivat edelleen, mutta joille ei ole mitään käyttöä. Toki voidaan kyseenalaistaa suunnitellut käyttöiän järkevyys.

Itse olen ymmärtänyt että ainakin palvelimien kohdalla käyttösähkön merkitys hiilijalanjäljelle olisi paljon isompi kuin laitteen valmistus. Käyttösähköön on laskettava mukaan myös palvelinsalin jäähdytys, minkä hiilijalanjälkeä tosin pystyy pienentämään erinäisin keinoin.

Kännyköiden, reitittimien yms. kohdalla harmillisinta on päivitysten rajautuminen muutamaan vuoteen, jolloin moni panee laitteen "romulaariin" tai vie vastuullisesti elektroniikkakierrätykseen. Toki monella ennättää kännykän lasi, liittimet tai joku muu osa hajota ennen päivitysten päättymistä...

Itselläni käyttöliittymäongelmat ovat pikemminkin web-palveluitten kohdalla kuin Windows-sovelluksissa.

Anonyymi kirjoitti:

Liekö suunniteltu vanheneminen enemmänkin urbaania legendaa kuin todellinen toiminnan motiivi. Laitteethan kannattaa suunnitella mahdollisimman halvoiksi ja kestämään tavoitellun käyttöiän hyväksyttävällä takuuajan vikaantumisprosentilla. Aiemmin kun ei osattu vielä optimoida, niin tehtiin tarpeettoman hyvää. Monella on varastoissaan kymmeniä vuosia vanhoja mikroja, jotka toimivat edelleen, mutta joille ei ole mitään käyttöä. Toki voidaan kyseenalaistaa suunnitellut käyttöiän järkevyys.

Itse olen ymmärtänyt että ainakin palvelimien kohdalla käyttösähkön merkitys hiilijalanjäljelle olisi paljon isompi kuin laitteen valmistus. Käyttösähköön on laskettava mukaan myös palvelinsalin jäähdytys, minkä hiilijalanjälkeä tosin pystyy pienentämään erinäisin keinoin.

Kännyköiden, reitittimien yms. kohdalla harmillisinta on päivitysten rajautuminen muutamaan vuoteen, jolloin moni panee laitteen "romulaariin" tai vie vastuullisesti elektroniikkakierrätykseen. Toki monella ennättää kännykän lasi, liittimet tai joku muu osa hajota ennen päivitysten päättymistä...

Itselläni käyttöliittymäongelmat ovat pikemminkin web-palveluitten kohdalla kuin Windows-sovelluksissa.

Lue lisää

"Itse olen ymmärtänyt että ainakin palvelimien kohdalla käyttösähkön merkitys hiilijalanjäljelle olisi paljon isompi kuin laitteen valmistus. "

No mekanismi liiketoiminnassa käytännössä menee niin, että kun ostetaan rauta ja myydään siitä resurssia, niin ensimmäiset 9kk maksetaan raudan kuluja pois ja sitten vasta alkaa tuottamaan voittoa. Ne laitteet vaan sitten poksahtelevat rikki jossain kohtaa ja niitä uusitaan.

Kyllä se energiatehokkuus siellä sitten tuntuu kun sähkö maksaa paljon mutta palvelinfirmat sitten kertovat kyllä minkä sukupolven laitetta on ja missä ja niillä on hintansa. Vanhemman sukupolven laitteet ovat vähän hitaampia joten myytävä resurssi on halvempaa ja kun se myös syö sähköä niin vaikuttaa sitten heidän katteisiin.

"Itselläni käyttöliittymäongelmat ovat pikemminkin web-palveluitten kohdalla kuin Windows-sovelluksissa."

Hyvin pienellä vaivalla saa halutessaan uuttakin sovelluskoodia käännettyä vanhalle Firefox 52 ESR:lle, joka toimii sitten Windows XP:ssä, 24 vuotta vanhassa järjestelmässä.

Windowsille tekemällä natiivikoodia, temppu on paljon vaikeampi. Windows kun voi olla Windows 11 S-Modessa joten yhteensopivuuden säilyttäminen natiivikoodilla tarkoittaa ohjelman tekemistä niin, että Windows 10:ä vanhemmille kääntäminen on mahdotonta tai niille pitäisi säätää erilaista versiota. Esimerkiksi kääntää .NET 4.8:lle Visual Studio 2019 niin toimisi Windows 7:llakin.

Eli nämä standardit todellakin ratkoo sitä että on vähemmän ongelmia käyttöliittymäkoodilla kun tekee niiden mukaisesti.

Anonyymi kirjoitti:

"Itse olen ymmärtänyt että ainakin palvelimien kohdalla käyttösähkön merkitys hiilijalanjäljelle olisi paljon isompi kuin laitteen valmistus. "

No mekanismi liiketoiminnassa käytännössä menee niin, että kun ostetaan rauta ja myydään siitä resurssia, niin ensimmäiset 9kk maksetaan raudan kuluja pois ja sitten vasta alkaa tuottamaan voittoa. Ne laitteet vaan sitten poksahtelevat rikki jossain kohtaa ja niitä uusitaan.

Kyllä se energiatehokkuus siellä sitten tuntuu kun sähkö maksaa paljon mutta palvelinfirmat sitten kertovat kyllä minkä sukupolven laitetta on ja missä ja niillä on hintansa. Vanhemman sukupolven laitteet ovat vähän hitaampia joten myytävä resurssi on halvempaa ja kun se myös syö sähköä niin vaikuttaa sitten heidän katteisiin.

"Itselläni käyttöliittymäongelmat ovat pikemminkin web-palveluitten kohdalla kuin Windows-sovelluksissa."

Hyvin pienellä vaivalla saa halutessaan uuttakin sovelluskoodia käännettyä vanhalle Firefox 52 ESR:lle, joka toimii sitten Windows XP:ssä, 24 vuotta vanhassa järjestelmässä.

Windowsille tekemällä natiivikoodia, temppu on paljon vaikeampi. Windows kun voi olla Windows 11 S-Modessa joten yhteensopivuuden säilyttäminen natiivikoodilla tarkoittaa ohjelman tekemistä niin, että Windows 10:ä vanhemmille kääntäminen on mahdotonta tai niille pitäisi säätää erilaista versiota. Esimerkiksi kääntää .NET 4.8:lle Visual Studio 2019 niin toimisi Windows 7:llakin.

Eli nämä standardit todellakin ratkoo sitä että on vähemmän ongelmia käyttöliittymäkoodilla kun tekee niiden mukaisesti.

Lue lisää

Kaiketi joihinkin ikivanhoihin ympäristöihin tarvitaan yhteensopivuutta mutta kaiketi harvassa ne ohjelmistokehittäjät nykyään, jotka Windows XP -yhteensopivuutta nikkaroivat. Ei sillä että Windows olisi mikään maailman paras järjestelmä, mutta mielestäni ongelmattomin ja mukavin käyttää (Applen tuotteita en ole kokeillut). Nyt siis kirjoitan kokemuksistani ohjelmien käyttäjänä en ohjelmoijana. Sama myös sovelluksista vs. web-palvelut. En tosin usko että ongelmat johtuisivat niinkään kehitysvälineistä; eiköhän ongelmien lähde ole ohjelmoijat, jotka tekevät duunia päästäkseen lyhyellä tähtäimellä tavoitteisiinsa ja tämä esimiestensä tähän motivoimana.

Anonyymi kirjoitti:

Kaiketi joihinkin ikivanhoihin ympäristöihin tarvitaan yhteensopivuutta mutta kaiketi harvassa ne ohjelmistokehittäjät nykyään, jotka Windows XP -yhteensopivuutta nikkaroivat. Ei sillä että Windows olisi mikään maailman paras järjestelmä, mutta mielestäni ongelmattomin ja mukavin käyttää (Applen tuotteita en ole kokeillut). Nyt siis kirjoitan kokemuksistani ohjelmien käyttäjänä en ohjelmoijana. Sama myös sovelluksista vs. web-palvelut. En tosin usko että ongelmat johtuisivat niinkään kehitysvälineistä; eiköhän ongelmien lähde ole ohjelmoijat, jotka tekevät duunia päästäkseen lyhyellä tähtäimellä tavoitteisiinsa ja tämä esimiestensä tähän motivoimana.

Lue lisää

Tässä nyt vähän puhuttiin siitä sovellusten käyttöliittymäohjelmoinnin standardista tavasta ja ekotehokkuudesta, niin tällä hetkellä se toteutuu parhaiten selaimella. Käyttöjärjestelmällä ei siinä sitten ole mitään väliä

Sovelluksia nyt alettiin siirtämään selaimeen muutenkin sitä mukaan kun se järkevästi onnistui koska siinä saatiin aivan valtavasti säästöjä niin ekologisuudessa kuin rahassa. Ennen vanhaan piti asentajan käydä hyysäämässä tietokoneita asentaa sovellusta. Selain ratkaisi tuon joten vähemmän palaa bensaa kun asentajan ei tarvise käydä asentamassa ja päivittämässä ja samoin tarvitsee antaa vähemmän käyttäjätukea. Jos jotain ongelmaa tai bugia on niin se voidaan korjata etänä. Asiakkaan tarvitsee huolehtia vain siitä, että tietokoneessa toimii selain ja se oletuksena toimii aivan joka paikassa.

Mitään ongelmia tässä ei oikein ole.

Anonyymi kirjoitti:

Tässä nyt vähän puhuttiin siitä sovellusten käyttöliittymäohjelmoinnin standardista tavasta ja ekotehokkuudesta, niin tällä hetkellä se toteutuu parhaiten selaimella. Käyttöjärjestelmällä ei siinä sitten ole mitään väliä

Sovelluksia nyt alettiin siirtämään selaimeen muutenkin sitä mukaan kun se järkevästi onnistui koska siinä saatiin aivan valtavasti säästöjä niin ekologisuudessa kuin rahassa. Ennen vanhaan piti asentajan käydä hyysäämässä tietokoneita asentaa sovellusta. Selain ratkaisi tuon joten vähemmän palaa bensaa kun asentajan ei tarvise käydä asentamassa ja päivittämässä ja samoin tarvitsee antaa vähemmän käyttäjätukea. Jos jotain ongelmaa tai bugia on niin se voidaan korjata etänä. Asiakkaan tarvitsee huolehtia vain siitä, että tietokoneessa toimii selain ja se oletuksena toimii aivan joka paikassa.

Mitään ongelmia tässä ei oikein ole.

Lue lisää

Keskustelu on levähtänyt sen verran laveaksi, että tiivistän nyt ajatukseni tähän viestiin..

Tiedossani olevien ohjelmistokehitysvälineiden ongelmana on, että kielen käyttöliittymien ja turvallisen nettikommunikaation ohjelmoinnin tuki on kolmansien osapuolten kirjastojen varassa ja näiden hyödyntäminen kohtuullisen työlästä opetella. Olisi kiva, jos kaikki nykyaikaisen softan tarvitsemat perustoiminnot löytyisivät vähintäänkin kehityspaketin mukana. Kieli saisi mieluiten olla helppoa oppia ja selkeätä ylläpitää (toki jotain voi ohjelmoijaltakin vaatia).

Softan virrankulutukseen vaikuttaa eniten se mitä koodia suoritetaan eniten ja paljonko dataa siirretään suorittimen ja ulkopuolisten komponenttien ja laitteiden välillä. Samaa algoritmia toteuttava tulkattava ohjelma vie enemmän sähköä kuin käännetty, joskin tämän merkitys hiilijalanjäljen suhteen riippuu järjestelmän kuormitusasteesta.

Toki järjestelmän suorituskyky on monesti kiinni tietokantaosuudesta. Tällöin korostuu SQL-kyselyiden laatijan rooli hiilijalanjäljen minimoinnissa, jotta kyselyt ovat järkeviä. Tietokantapalvelimet osaavat kyllä vaikka minkälaisia temppuja optimoidessaan kyselyitä, mutta jos käyttölogiikka niiden suhteen on tehoton, niin eipä nekään paljoa sellaiselle mahda. Hyvä kieli tarjoaisi tehokkaat välineet monipuolisille tietorakenteille ilman että tarvitsisi turvautua heti lähtökohtaisesti tietokantapalvelimiin, mutta toki myös välineet niiden hyödyntämiselle ovat tarpeen.

Niin natiivit kuin web-pohjaiset sovellukset voidaan toteuttaa hyvin ja toimiviksi tai huonosti ja valmiiksi rikki.

Anonyymi kirjoitti:

Keskustelu on levähtänyt sen verran laveaksi, että tiivistän nyt ajatukseni tähän viestiin..

Tiedossani olevien ohjelmistokehitysvälineiden ongelmana on, että kielen käyttöliittymien ja turvallisen nettikommunikaation ohjelmoinnin tuki on kolmansien osapuolten kirjastojen varassa ja näiden hyödyntäminen kohtuullisen työlästä opetella. Olisi kiva, jos kaikki nykyaikaisen softan tarvitsemat perustoiminnot löytyisivät vähintäänkin kehityspaketin mukana. Kieli saisi mieluiten olla helppoa oppia ja selkeätä ylläpitää (toki jotain voi ohjelmoijaltakin vaatia).

Softan virrankulutukseen vaikuttaa eniten se mitä koodia suoritetaan eniten ja paljonko dataa siirretään suorittimen ja ulkopuolisten komponenttien ja laitteiden välillä. Samaa algoritmia toteuttava tulkattava ohjelma vie enemmän sähköä kuin käännetty, joskin tämän merkitys hiilijalanjäljen suhteen riippuu järjestelmän kuormitusasteesta.

Toki järjestelmän suorituskyky on monesti kiinni tietokantaosuudesta. Tällöin korostuu SQL-kyselyiden laatijan rooli hiilijalanjäljen minimoinnissa, jotta kyselyt ovat järkeviä. Tietokantapalvelimet osaavat kyllä vaikka minkälaisia temppuja optimoidessaan kyselyitä, mutta jos käyttölogiikka niiden suhteen on tehoton, niin eipä nekään paljoa sellaiselle mahda. Hyvä kieli tarjoaisi tehokkaat välineet monipuolisille tietorakenteille ilman että tarvitsisi turvautua heti lähtökohtaisesti tietokantapalvelimiin, mutta toki myös välineet niiden hyödyntämiselle ovat tarpeen.

Niin natiivit kuin web-pohjaiset sovellukset voidaan toteuttaa hyvin ja toimiviksi tai huonosti ja valmiiksi rikki.

Lue lisää

"Tiedossani olevien ohjelmistokehitysvälineiden ongelmana on, että kielen käyttöliittymien ja turvallisen nettikommunikaation ohjelmoinnin tuki on kolmansien osapuolten kirjastojen varassa ja näiden hyödyntäminen kohtuullisen työlästä opetella. "

Tämä on standardi tapa käyttöliittymäpuolella: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

Eli ei tarvitse erillistä kirjastoa.

"Kieli saisi mieluiten olla helppoa oppia ja selkeätä ylläpitää (toki jotain voi ohjelmoijaltakin vaatia)."

https://www.typescriptlang.org/

Tuo on helppo, ja selkeä ylläpitää. Juurikin se ylläpito tuossa helppoa koska on se tyypitys. Ilman tyypitystä tulee todella helposti virheitä koodiin. Typescript kääntäjä sisältää vipuja millä saa tarkistuksia.

Koska kaikkien työkalujen asentaminen ja nysvääminen perseestä, löytyy näille asennus, käyttöönotto ja kääntö valmiiksi nysvättynä. Itse käytän tätä: https://vite.dev/

Eli käytännössä devaamista varten NodeJS että saa npm:llä laitettua kamoja.

Eli Fetch API on standardi, Typescriptin pihalle kääntämä Javascript on standardia että on siltä osin turvallinen, Vite sitten pistää perustyökalut nippuun että voi vaan alkaa kirjoittaa koodia. Vite sisältää myös konfiguraatiota SolidJS, React jne. jos ottaa käyttöön näitä niin on sitten jokin muoto kirjoittaa käyttöliittymäelementtejä ja päivittää näkymiä.

"Softan virrankulutukseen vaikuttaa eniten se mitä koodia suoritetaan eniten ja paljonko dataa siirretään suorittimen ja ulkopuolisten komponenttien ja laitteiden välillä."

Ekologisuudessa eniten vaikuttaa se, että yleensäkin on se softa ettei jonkun tarvitse hypätä auton rattiin ja käydä tekemässä.

Mutta sitten kun softa on ylivoimaisesti eniten sähköä vie langaton datasiirto laitteen ulkopuolelle, ja yleensäkin datasiirto ja sitten toki se liikenne laitteen sisällä komponenttien ja laitteiden välillä.

"Samaa algoritmia toteuttava tulkattava ohjelma vie enemmän sähköä kuin käännetty, joskin tämän merkitys hiilijalanjäljen suhteen riippuu järjestelmän kuormitusasteesta."

Käytännössä niin, että mitä nopeammin järjestelmä pääsee huilimaan, sitä enemmän säästää. Palvelimissa tuo ei aina ihan päde että natiiviksi käännetty olisi parempi: https://quarkus.io/blog/runtime-performance/

JVM:llä saa enemmän througputtia mutta natiivi käynnistyy nopeammin. Eli käytännössä natiivi on helposti parempi kun kuormitus skaalailee mutta jos on jatkuvasti kuormaa niin JVM.

"Toki järjestelmän suorituskyky on monesti kiinni tietokantaosuudesta. Tällöin korostuu SQL-kyselyiden laatijan rooli hiilijalanjäljen minimoinnissa, jotta kyselyt ovat järkeviä"

No siis tosiaankin ei sillä koodilla ole niin paljoa väliä. Tietorakenteella on väliä. Aina pitää keskittyä siihen dataan.

"Hyvä kieli tarjoaisi tehokkaat välineet monipuolisille tietorakenteille ilman että tarvitsisi turvautua heti lähtökohtaisesti tietokantapalvelimiin, mutta toki myös välineet niiden hyödyntämiselle ovat tarpeen."

Tietokantapalvelimia tarvitaan lähes aina kun samaa tietoa tietoa tarvitsee usean käyttäjän päästä muokkaamaan. Relaatiotietokannat vaan sattuvat olemaan halvimpia ja data pysyy johdonmukaisena niin ovat sitten tavallisimpia, mutta jos haluaa skaalata niin sitten usein käytetään myös muita.

Ne vaan ratkovat sitä tiedon persistointia, suodattamista jne. Tietorakenne tehdään ihan normaalisti näiden päälle, että onko se sitten puu, lista, hashtaulu, taulukko, graaffi jne. Usein halutaan vain persistoida objekteja.

Minkä tahansa tietorakenteen laittaa mihin tahansa kantaan, Eri kantatyypit vaan käyttäytyvät eri tavalla, että onko data konsistenttiä, saatavilla olevaa, millaiset lukitukset on jos joku kirjoittaa sinne, miten relaatiot vaikuttavat.

Anonyymi kirjoitti:

"Tiedossani olevien ohjelmistokehitysvälineiden ongelmana on, että kielen käyttöliittymien ja turvallisen nettikommunikaation ohjelmoinnin tuki on kolmansien osapuolten kirjastojen varassa ja näiden hyödyntäminen kohtuullisen työlästä opetella. "

Tämä on standardi tapa käyttöliittymäpuolella: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

Eli ei tarvitse erillistä kirjastoa.

"Kieli saisi mieluiten olla helppoa oppia ja selkeätä ylläpitää (toki jotain voi ohjelmoijaltakin vaatia)."

https://www.typescriptlang.org/

Tuo on helppo, ja selkeä ylläpitää. Juurikin se ylläpito tuossa helppoa koska on se tyypitys. Ilman tyypitystä tulee todella helposti virheitä koodiin. Typescript kääntäjä sisältää vipuja millä saa tarkistuksia.

Koska kaikkien työkalujen asentaminen ja nysvääminen perseestä, löytyy näille asennus, käyttöönotto ja kääntö valmiiksi nysvättynä. Itse käytän tätä: https://vite.dev/

Eli käytännössä devaamista varten NodeJS että saa npm:llä laitettua kamoja.

Eli Fetch API on standardi, Typescriptin pihalle kääntämä Javascript on standardia että on siltä osin turvallinen, Vite sitten pistää perustyökalut nippuun että voi vaan alkaa kirjoittaa koodia. Vite sisältää myös konfiguraatiota SolidJS, React jne. jos ottaa käyttöön näitä niin on sitten jokin muoto kirjoittaa käyttöliittymäelementtejä ja päivittää näkymiä.

"Softan virrankulutukseen vaikuttaa eniten se mitä koodia suoritetaan eniten ja paljonko dataa siirretään suorittimen ja ulkopuolisten komponenttien ja laitteiden välillä."

Ekologisuudessa eniten vaikuttaa se, että yleensäkin on se softa ettei jonkun tarvitse hypätä auton rattiin ja käydä tekemässä.

Mutta sitten kun softa on ylivoimaisesti eniten sähköä vie langaton datasiirto laitteen ulkopuolelle, ja yleensäkin datasiirto ja sitten toki se liikenne laitteen sisällä komponenttien ja laitteiden välillä.

"Samaa algoritmia toteuttava tulkattava ohjelma vie enemmän sähköä kuin käännetty, joskin tämän merkitys hiilijalanjäljen suhteen riippuu järjestelmän kuormitusasteesta."

Käytännössä niin, että mitä nopeammin järjestelmä pääsee huilimaan, sitä enemmän säästää. Palvelimissa tuo ei aina ihan päde että natiiviksi käännetty olisi parempi: https://quarkus.io/blog/runtime-performance/

JVM:llä saa enemmän througputtia mutta natiivi käynnistyy nopeammin. Eli käytännössä natiivi on helposti parempi kun kuormitus skaalailee mutta jos on jatkuvasti kuormaa niin JVM.

"Toki järjestelmän suorituskyky on monesti kiinni tietokantaosuudesta. Tällöin korostuu SQL-kyselyiden laatijan rooli hiilijalanjäljen minimoinnissa, jotta kyselyt ovat järkeviä"

No siis tosiaankin ei sillä koodilla ole niin paljoa väliä. Tietorakenteella on väliä. Aina pitää keskittyä siihen dataan.

"Hyvä kieli tarjoaisi tehokkaat välineet monipuolisille tietorakenteille ilman että tarvitsisi turvautua heti lähtökohtaisesti tietokantapalvelimiin, mutta toki myös välineet niiden hyödyntämiselle ovat tarpeen."

Tietokantapalvelimia tarvitaan lähes aina kun samaa tietoa tietoa tarvitsee usean käyttäjän päästä muokkaamaan. Relaatiotietokannat vaan sattuvat olemaan halvimpia ja data pysyy johdonmukaisena niin ovat sitten tavallisimpia, mutta jos haluaa skaalata niin sitten usein käytetään myös muita.

Ne vaan ratkovat sitä tiedon persistointia, suodattamista jne. Tietorakenne tehdään ihan normaalisti näiden päälle, että onko se sitten puu, lista, hashtaulu, taulukko, graaffi jne. Usein halutaan vain persistoida objekteja.

Minkä tahansa tietorakenteen laittaa mihin tahansa kantaan, Eri kantatyypit vaan käyttäytyvät eri tavalla, että onko data konsistenttiä, saatavilla olevaa, millaiset lukitukset on jos joku kirjoittaa sinne, miten relaatiot vaikuttavat.

Lue lisää

Kiitoksia, nyt tuli mielenkiintoisia vinkkejä tutkittavaksi!

Kyllä Rustille IDE:jä on tehty varmaan lähemmäs 10kpl.

Anonyymi kirjoitti:

Kyllä Rustille IDE:jä on tehty varmaan lähemmäs 10kpl.

Muistio on ihan kelvollinen editori tutustumiseen ja Geany Linux järjestelmässä.

Juu, vaikka kieleltä periaatteessa paljon vaadin, niin en sentään moderointiapuja. Voi olla, että "täydellinen moderointi" on saavuttamaton unelma, mutta tässä panisin toivoni joukkovoimaan eli että foorumin käyttäjät reaktioillaan kannustaisivat kanssakeskustelijoita muut huomioivaan keskustelutyyliin. Foorumisofta tarjoaisi tähän riittävät välineet. Toisaalta olemme lukijoina erilaisia, joten olisi myös hyvä että voisimme foorumisoftan avuilla suodattaa itseämme potentiaalisesti kiinnostavat viestit näkyviin ja piilottaa vähemmän kiinnostavat tai suorastaan ärsyttävät.

Heittoja siitä millaisia avuja softa voisi tarjota:
- suodata pois runsaasti kirjoitusvirheitä sisältävät viestit
- näytä avainsanalistassani olevia sanoja sisältävät viestit ja vastaava estotoimintona
- edelliseen myös valmiita sanalistoja
- viestin luokittelua (käyttäjän toimesta): asiallinen, asiaton, huumoria, satiiria, solvaus, uusi idea, rakentava, kannustava, arvosana 1..5/5, jne., peukku alas ja ylös, ja näistä kaikista vihjetoiminnolla selostus mitä tarkoittaa
- viestien kirjoittajan pisteytys softan toimesta lukijapalautteen perusteella siten, että hänen kirjoittamien viestin näkyvyyttä voidaan heikentää tai ohjata lukijan toiveen mukaan
- luonnollisesti harva viitsii lähteä pidemmästi aikaa käyttämään viestien tai kirjoittajienkaan arvioimiseksi, joten palautteen antamisen käyttöliittymä pitäisi laatia helppo- ja nopeakäyttöiseksi
- softa voisi kirjoitusvaiheessa, tai viimeistään ennen lähetystä, varoittaa kirjoittajaa, jos viesti sisältää lukijakuntaa merkittävästi rajoittavaa sisältöä
- softa myös voisi kannustaa vanhojen ketjujen hyödyntämiseen ettei samasta aiheesta kertyisi tolkutonta määrää ketjuja näyttämällä otsikkoa kirjoitettaessa samankaltaisista tai peräti samoista aiemmista otsikoista

Suomi24:n tekeminen onnistuu yhdeltä kehittäjältä varsin helposti.