Digitalisaatio - hyvät ja huonot puolet

[lizard]

Legacy-koodit eivät tiedä tällaisesta mitään vaan ne on kirjoitettu oletuksella 1 tavu = 1 merkki. On vähän vaikeaa arvioida miten paljon tämän oletuksen särkyminen rikkoo koodia. Eihän esim. alimerkkijonoihin pääse enää käsiksi suoraan indeksoimalla (esim. tekstirivillä 5 saraketta vakiopaikoissa ja halutaan poimia 4. sarakkeessa oleva numero ja konvertoida se liukuluvuksi). Hyvin tavallinen tehtävä, kun luetaan tekstitiedostosta dataa sisään. Toki voi pitäytyä ASCII-merkistössä mutta entäs kun 2. sarakkeessa lukeekin "Hyvinkää"?

Ihanko varmasti, jos käytetään jotain binääriä (esim. vanha kirjasto), jossa nämä kutsut on inline-optimoitu suoraan assembleriksi? Enää näin ei voi tehdä, jolloin suorituskyky kärsii.

Ehkä toimii, jos todella kutsutaan jotain funktiota mutta monet merkkijonofunktiot on tehty inline-assemblerina. Ei taida toimia, jos on koodattu jokin toiminnallisuus itse käsin.

Legacy-ohjelma, joka ei tiedä UTF-8'sta mitään, näkee nuo enkoodatut pätkät tilanvarauksensa mukaisina hivenen pitempinä pätkinä. Pääsääntöisesti tuo ei haittaa mitään. Esimerkiksi tuota tekstitiedostoa (vaikka CSV) parsiessa etsit jonkinlaisia column-markereita, joilla jaat tekstin sarakkeiksi. Nuo löytyvät ihan samalla tavalla kuin ennenkin. Se "hyvinkää" parsiutuu sieltä ihan oikein. strlen() palauttaa sille oikean tilanvarauksen mukaisen arvon, jolla voi tarvittaessa varata oikean määrän muistia. Ja vaikka strncpy kopioi sen varattuun bufferiin oikein, vaikka sovellus ei ole ikinä unicodesta kuullutkaan. Ja ei haittaa, vaikka kaikki nuo olisi inlinetetty binääriin, se strlen on edelleen ihan sama toteutus.

Sitten jos sulla on vaikka legacy tekstieditori, niin toki sillä saa generoitua rikkinäisiä utf-8 payloadeja: menet vaikka lisäämään välilyönnin keskelle tuollaista enkoodattua blobia. Mutta niiden esimerkiksi deletoiminen tai copy-paste toimii ihan oikein. Tällainen käyttötapaus sopii hyvin tilanteeseen, jossa tiedoston payload on pääasiassa ASCII, mutta voi sisältää pieniä määriä muita merkkejä.

 

[lizard]

Unicode on tarpeellinen tapauksissa, joissa saman dokumentin on pystyttävä näyttämään eri kirjoitusjärjestelmien merkkejä, siis esimerkiksi sekä koodisivulta IBM850 että japanilaisten kirjoitusjärjestelmästä löytyviä merkkejä.

Hyöty unicodesta tulee jo ihan siitä, että jokaisen tiedoston mukana ei tarvitse erikseen olla jossain toisaalla metatietona, millä koodisivulla se on kirjoitettu. Ääkköset ja muutkin yli 128'n olevat merkit menevät heti pieleen, jos tietoa siirtäessä lähettäjä ja vastaanottaja käyttävät eri koodisivua. UTF-8 pystyy esittämään kerralla kaikki unicode-speksin määrittelemät merkit, ei pelkkää 256-merkin subsettia. No, meille Suomessa on tuttua jo kymmenien vuosien takaa, että ääkköset voivat mennä pieleen, mutta käytännössä nämä paikat ovat koko ajan vähentyneet. Ja tässä unicode on ratkaisu, ei ongelma. Ongelma ovat nuo toisistaan irralliset 8-bittiset merkistöt.

Ja näinä päivinä tietty ihan mikä teksti vaan voi sisältää vaikka hymiöitä.

 

[JCSH]

Hyöty unicodesta tulee jo ihan siitä, että jokaisen tiedoston mukana ei tarvitse erikseen olla jossain toisaalla metatietona, millä koodisivulla se on kirjoitettu. Ääkköset ja muutkin yli 128'n olevat merkit menevät heti pieleen, jos tietoa siirtäessä lähettäjä ja vastaanottaja käyttävät eri koodisivua. UTF-8 pystyy esittämään kerralla kaikki unicode-speksin määrittelemät merkit, ei pelkkää 256-merkin subsettia. No, meille Suomessa on tuttua jo kymmenien vuosien takaa, että ääkköset voivat mennä pieleen, mutta käytännössä nämä paikat ovat koko ajan vähentyneet. Ja tässä unicode on ratkaisu, ei ongelma. Ongelma ovat nuo toisistaan irralliset 8-bittiset merkistöt.

Ja näinä päivinä tietty ihan mikä teksti vaan voi sisältää vaikka hymiöitä.

Puhumattakaan siitä, että noin 2/3 maailmasta käyttää jotain muita aakkosia kuin latinalaisia.

 

[Paapaa]

Hämmentävää lukea, että joku haikailee suppeita merkistöjä, jotka eivät siis kykene kattamaan edes kaikkia länsieurooppalaisten kielien tarvitsemia merkkejä, puhumattakaan muusta maailmasta. Se, että ohjelmoija on paska eikä kykene toimimaan UTF-8:n kanssa ja on saanut oppinsa 80-luvulla ei ole mikään peruste luopua siitä ja palata johonkin puutteellisen Latin-1:een. Devaaja on hyvä ja siirtyy 2000-luvulle. UTF-8-enkoodaus on todella toimiva ratkaisu, eikä ihme että se on saavuttanut laajan tuen.

Mutta miten ihmeessä tämä nyt sitten liittyy digitalisaatioon? En tiedä. Taas jotain ihme vänkäämistä uusista ja vanhoista protokollista, mikä varmaan kuuluisi jonnekin muualle. EDIT: No ehkä niin, että merkistöongelmat olivat ihan oikea ja paha ongelma digitalisaation alkuvaiheessa: nimet olivat väärin, vieraskieliset sanat oli väärin, piti muuttaa kirjaimia vääriksi ja sen jälkeen samalla sanalla olikin useita kirjoitusasuja ja haku ei toiminut oikein, sama sana näkyi eri tavalla eri käyttäjille jne. UTF-8 ja tietenkin Unicode ovat tuoneet tähän todella hyvän ja toimivan ratkaisun. EI nyt jumalauta kukaan tervejärkinen voi kaivata jotain vanhoja merkistöjä

 

[JCSH]

Legacy-koodit eivät tiedä tällaisesta mitään vaan ne on kirjoitettu oletuksella 1 tavu = 1 merkki. On vähän vaikeaa arvioida miten paljon tämän oletuksen särkyminen rikkoo koodia. Eihän esim. alimerkkijonoihin pääse enää käsiksi suoraan indeksoimalla (esim. tekstirivillä 5 saraketta vakiopaikoissa ja halutaan poimia 4. sarakkeessa oleva numero ja konvertoida se liukuluvuksi). Hyvin tavallinen tehtävä, kun luetaan tekstitiedostosta dataa sisään. Toki voi pitäytyä ASCII-merkistössä mutta entäs kun 2. sarakkeessa lukeekin "Hyvinkää"?

Tai jos siinä lukeekin 北京 tai 東京都. Puhumattakaan جِدَّة‎ tai תל אביב. Sitten on toki myös Αθήνα ja Hà Nội.
Suht nopeasti huomataan, että tuollaisia yksinkertaistuksia sisältävät legacy-koodit kuuluvat sinne roskakoriin kaksinumeroisten vuosilukujen ja 32 bittisten aikaleimojen kanssa.

 

[love_doctor]

Eleganttius ottaa merkittävää osumaa, jos/kun olemassaolevaa koodia menee rikki.

Legacy-koodit eivät tiedä tällaisesta mitään vaan ne on kirjoitettu oletuksella 1 tavu = 1 merkki. On vähän vaikeaa arvioida miten paljon tämän oletuksen särkyminen rikkoo koodia. Eihän esim. alimerkkijonoihin pääse enää käsiksi suoraan indeksoimalla (esim. tekstirivillä 5 saraketta vakiopaikoissa ja halutaan poimia 4. sarakkeessa oleva numero ja konvertoida se liukuluvuksi). Hyvin tavallinen tehtävä, kun luetaan tekstitiedostosta dataa sisään. Toki voi pitäytyä ASCII-merkistössä mutta entäs kun 2. sarakkeessa lukeekin "Hyvinkää"?

Ihanko varmasti, jos käytetään jotain binääriä (esim. vanha kirjasto), jossa nämä kutsut on inline-optimoitu suoraan assembleriksi? Enää näin ei voi tehdä, jolloin suorituskyky kärsii.

Ehkä toimii, jos todella kutsutaan jotain funktiota mutta monet merkkijonofunktiot on tehty inline-assemblerina. Ei taida toimia, jos on koodattu jokin toiminnallisuus itse käsin.

Vanhaa koodia menee jatkuvasti rikki, kun vaatimukset muuttuvat. Esim. merkistöistä jos luet lisää, huomaat että se "vanha" ei ollut 8 bittiä vaan ASCII oli 7 bittiä ja kahdeksas saattoi olla esimerkiksi virheenkorjaukseen pariteetti. 8-bittiset merkistöt kyllä rikkoivat yhteensopivuutta myös jos oletus oli että merkit ovat 7-bittisiä ja esim. kirjaimet ovat väleillä a-z ja A-Z. Ääkköset kun eivät kuulu noihin väleihin. 128 merkkiin on aika paha sovittaa montaakaan kieltä, kun mukana on ohjausmerkkejäkin.

Oikeastaan toit aika hyvin esille parikin virhekäsitystä - C-tyylinen tapa koodata merkkijonot 0-loppuisiksi ilman pituustietoa on tehoton ja tietoturvaongelmille altis paskakoodaus. Samoin tekstin käsittely inline assyllä. Tietoturvasyistä tällainen pitäisi lopettaa kuten myös näitä tekevät koodarit. Toinen pointti on että kovinkaan usein tekstiin ei sovelleta merkkikohtaisella indeksoinnilla hajasaantia vaan teksti käydään läpi kokonaisuutena tai jollain muulla tavalla (esim. rivinvaihdot), jotka kuitenkin vaativat läpikäyntiä. Vaihtelevanpituiset merkit tuovat miinuspuolia, mutta myös etuja. Merkkijonoja kannattaisi C-tyylin sijaan käsitellä aina pituustiedolla, koska vaikka siinä on hieman enemmän kirjanpitoa, strlen-tyylinen nopeutuu O(n)-ajallisesta O(1)-aikaiseksi ja monet oikeasti raskaat operaatiot voi optimoida menemään vektoreilla tai muuten kevyemmällä muistikuormalla, kun ei tarvitse lukea jonoa haarautumisen päättämiseksi.

Digitalisaation kannalta on hyvä jos merkistöt ovat monikäyttöisiä. Se että joku MUMPSin 1960-luvun 8-bittinen paskakoodi toimii vielä 2230 ilman tarvetta muokata jotain 8-bittistä assyä on enemmän joku (kaulaparta)koodarien eroottinen fantasia.

 

[Juha Kokkonen]

Offtopic seis ja keskittykää ketjun aiheeseen, kiitos.

 

[takomo]

Offtopic seis ja keskittykää ketjun aiheeseen, kiitos.

Kun katson ylläolevaa kommentointia, niin minusta alkaa näyttää siltä, että pakkodigitalisaation ydinongelma ei ehkä olekaan analogisen pakottaminen digitaaliseksi vaan yleisemmin kaiken vanhan pakottaminen uudeksi, hinnasta ja seurauksista piittaamatta. Legacy on kirosana ja paskaa riippumatta siitä onko kyse pahvikortistosta, analogisesta radiosta vai VAXille tehdystä, Linuxille portatusta tietokannasta. Pelkkä digitalisaatio ei olekaan riittävää, vaan pitää olla uudenaikaista digitalisaatiota. Lähinnä tällaisesta asennoitumisesta tulee mieleen Maon kulttuurivallankumous, jossa vanha historia tuhottiin aktiivisesti ja yritettiin korvata uudella, kommunistisella tulevaisuudella.

Porukka ilkkuu sille, että uusien maailmanstandardien pakottaminen kaikkeen särkee toimivia tietojärjestelmiä, eikä haitoilla ja kustannuksilla ole väliä. Esim. tällainen, uudenaikaisesti koodattu kartta on tosi hyödyllinen eurooppalaiselle:

 

[Kautium]

...pakkodigitalisaation ydinongelma ei ehkä olekaan analogisen pakottaminen digitaaliseksi vaan yleisemmin kaiken vanhan pakottaminen uudeksi, hinnasta ja seurauksista piittaamatta.

Väärin, ei kukaan ole haluamassa "kaiken vanhan pakottamista uudeksi, hinnasta ja seurauksista piittaamatta". Kyse on siitä, että halutaan vanhentuneiden menetelmien korvaamista tehokkaammilla, nopeammilla, käytettävämmillä ja modulaarisemmilla.

Aina uusi ei tietenkään ole kaikessa parempi, mutta kehitys kehittyy, eikä yleensä kuitenkaan mennä kokonaisuutena taaksepäin, vaikka ei kertalaakista priimaa tulisikaan.

Legacy on kirosana ja paskaa riippumatta siitä onko kyse pahvikortistosta, analogisesta radiosta vai VAXille tehdystä, Linuxille portatusta tietokannasta.

Niin no, lähtökohtaisesti legacy nimenomaan on paskaa, jos ei kyse ole jostakin sellaisesta asiasta, jota ei nykypäivänä ole mahdollista korvata paremmalla. Paikallaan jumittamisen ei pidä olla itseisarvo, eikä varsinkaan jos takana on vain muutosvastarintaa, tai yksittäisten dinosaurusten vanhoillisia ajatusmalleja.

 

[3dfx]

Väärin, ei kukaan ole haluamassa "kaiken vanhan pakottamista uudeksi, hinnasta ja seurauksista piittaamatta". Kyse on siitä, että halutaan vanhentuneiden menetelmien korvaamista tehokkaammilla, nopeammilla, käytettävämmillä ja modulaarisemmilla.

Tuolta se käyttäjälle monesti näyttää että pääasia että vaan uudistetaan. Sen lisäksi kun ne uuden järjestelmän opettelut tulee muiden töiden päälle eikä muita töitä korvaavasti. Hyödytkin jää kysymysmerkiksi käyttäjälle kun pääsääntöisesti käyttöliittymät nykyisin huononee, mikä taas tekee valtavia kustannuksia kun kukaan ei osaa käyttää, ja päivityksessä valikot sotketaan tms.

Ainakin itsellä on ollu ainakin 15 vuotta väsymys turhanpäiväiseen opetteluun erityisesti tietotekniikan kanssa...joskus teininä vielä jaksoi.

 

[Sompi]

Hyöty unicodesta tulee jo ihan siitä, että jokaisen tiedoston mukana ei tarvitse erikseen olla jossain toisaalla metatietona, millä koodisivulla se on kirjoitettu.

Mutta pitää kuitenkin olla metatieto siitä, että se on unicodea - ja myös siitä, mitä unicoden tyyppiä ja versiota se on. Mikään ei siis ole muuttunut.

Hämmentävää lukea, että joku haikailee suppeita merkistöjä, jotka eivät siis kykene kattamaan edes kaikkia länsieurooppalaisten kielien tarvitsemia merkkejä, puhumattakaan muusta maailmasta. Se, että ohjelmoija on paska eikä kykene toimimaan UTF-8:n kanssa ja on saanut oppinsa 80-luvulla ei ole mikään peruste luopua siitä ja palata johonkin puutteellisen Latin-1:een. Devaaja on hyvä ja siirtyy 2000-luvulle. UTF-8-enkoodaus on todella toimiva ratkaisu, eikä ihme että se on saavuttanut laajan tuen.

Edellisessä viestissäni jo kerroin, miksi unicoden pitäminen oletuksena ei ole hyvä asia. Se tekee ihan konkreettisia tietoturvariskejä ja on ongelmallinen myös käyttäjien tuottaman sisällön kanssa esimerkiksi foorumeilla ja vieraskirjoissa. Unicode on kyllä hyvä asia silloin, kun sitä tarvitaan, ja ilman unicodea moni asia olisi hankalampaa. Kuitenkin tuollainen kaikkien pakottaminen unicoden käyttäjiksi on vastenmielistä ja tuottaa enemmän ongelmia kuin ratkaisee niistä.

Ja ovathan ne tasapituiset merkistöt aina myös helpompia implementoida.

Oikeastaan toit aika hyvin esille parikin virhekäsitystä - C-tyylinen tapa koodata merkkijonot 0-loppuisiksi ilman pituustietoa on tehoton

Itse asiassa nollaloppuiset merkkijonot ovat kyllä ainakin x86-alustalla varsin nopeita käsitellä. Siitä voisikin tehdä jonkinlaisen vertailun, että kumpaan menee enemmän kellosyklejä, PASCAL-tyyppisiin merkkijonoihin joissa pituustieto on alussa kokonaislukuna vai C-tyyppisiin merkkijonoihin jotka loppuvat nollatavuun. Edellämainituissa on muuten melko merkittävänä sellainen ongelma, että sen pituustiedon bittileveys pitää tietää jostain, ennen kuin koko merkkijonoa voi edes alkaa käsittelemään.

 

[pulatunnus]

....

Porukka ilkkuu sille, että uusien maailmanstandardien pakottaminen kaikkeen särkee toimivia tietojärjestelmiä, eikä haitoilla ja kustannuksilla ole väliä. Esim. tällainen, uudenaikaisesti koodattu kartta on tosi hyödyllinen eurooppalaiselle:

Nyt ei tuo karttajuttu avaudu, png kuvatiedosto, otsikkoon liittyen haikailetko paperisia.
Digitaaliset kartat ovat olle vuosikausia ihan muuta kuin pikselikuvatiedostoja.

Mutta pitää kuitenkin olla metatieto siitä, että se on unicodea - ja myös siitä, mitä unicoden tyyppiä ja versiota se on. Mikään ei siis ole muuttunut.
....

Ymmärsin että moderointi nimenomaan kielsi merkistö keskustelun

Offtopic seis ja keskittykää ketjun aiheeseen, kiitos.

 

[LaDeX]

Nyt ei tuo karttajuttu avaudu, png kuvatiedosto, otsikkoon liittyen haikailetko paperisia.
Digitaaliset kartat ovat olle vuosikausia ihan muuta kuin pikselikuvatiedostoja.

Veikkaan että tuossa oli pointti että nuo paikkojen nimet on paikallisilla koukeroilla eikä latinalaisilla aakkosilla. Eli merkistöjuttua tämäkin.

 

[Antw]

Digitalisaatio tarkoittaa laajempaa yhteiskunnallista muutosta, joka tapahtuu, kun perinteisiä analogisia toimintoja ja prosesseja korvataan digitaalisilla ratkaisuilla ja teknologioilla. Digitalisaatio voi vaikuttaa monilla eri aloilla, kuten terveydenhuollossa, koulutuksessa, liiketoiminnassa ja julkishallinnossa. Esimerkiksi ostaminen netissä, etätyö ja viranomaisten viestintä sosiaalisessa mediassa ovat digitalisaatiota

Digitalisoinnilla puolestaan tarkoitetaan tietokoneiden ja datan hyödyntämistä toimintaan tai kehittämiseen. Esimerkiksi sähköpostitse viestiminen, verkkokaupan rakentaminen tai valokuvaaminen puhelimella ovat digitalisointia.

Lähde

Eikö olisi jo sama sulkea lopullisesti tämä lanka, kun ei tämä kerta kaikkiaan tunnu pysyvän aiheessa? Tredin aloittaja itse vie kerta toisensa jälkeen keskustelun aivan väärille raiteille, ja sitten porukkaa lähtee mukaan tähän offtopic-vänkäykseen..