Mikä on WikiWiki?
nettipäiväkirja
koko wiki (etsi)
viime muutokset
Ohjelmointiin liittyvät sivut.
(nettipäiväkirja 28.10.2024) Keskiviikkona on funktionaalisen ohjelmoinnin tapaaminen (https://www.meetup.com/helsinki-clojure-meetup/events/303937843/), jossa ajattelin pitää esityksen rekursiosta: (...)
Heuristiikka tarkoittaa tapaa, jolla voi arvioida asian kannattavuutta ilman, että tarvitsee tutkia perin pohjin sen kaikkia seurauksia ja vaikutuksia. Tämä(kin) on ensisijaisesti pelitermi, mutta sitä voi soveltaan hyvin tosielämään. (...)
Pilvilaskenta (cloud computing) ja pilvipalvelut (cloud services) ovat käsitteitä, joiden määrittely käy helpoimmin esimerkkien kautta: (...)
(nettipäiväkirja 18.03.2024) Tein pienen teorian siitä, miten musiikin teorian eri käsitteet toimivat tyyppeinä (ohjelmointimielessä). Jokainen solmu alla olevassa graafissa on musiikin teorian ''tyyppi'', ja jokainen nuolen nimi on ''funktiotyyppi'' eli tyyppi niille funktioille, jotka kuvaavat määrittelyjoukkonsa (nuolen alkupää) arvoja tulosjoukkonsa (nuolen loppupää) arvoiksi. (Muuten, funktio on myös musiikin termi, mutta tässä tarkoitan sitä ohjelmointimielessä tai matemaattisessa mielessä.) (...)
(nettipäiväkirja 25.08.2023) Tajusin vihdoin ja viimein, miten Clojuressa nimien uudelleenmäärittely toimii! Tää on tosi tärkeää, koska tästä on kiinni, pystyykö Clojuressa saamaan lähdekoodissa muutetut määrittelyt heti käyttöön, vai pitääkö jokin osa sovelluksesta (tai koko runtime) käynnistää uudelleen. Ja Clojuren käynnistäminen uudelleen on _tosi_ hidasta. (...)
Testaa henkinen pukusuolesi -testi on täällä: http://sange.fi/~atehwa/cgi-bin/pukusuoli.cgi (...)
Jotenkin häiritsee se, että puhe tekoälystä on vieläkin aika samanlaista kuin silloin kun olin pieni. Toistuvia hahmotustapoja, jotka tuntuvat minusta jotenkin väärinkäsityksiin perustuvilta, ovat ainakin seuraavat: (...)
Tämä on tuotantotapa, jossa tuotetta valmistetaan pienissä erissä ja jokaisen jälkeen uusi toiminnallisuus on nähtävissä ja kokeiltavissa. Tämä edellyttää paljon intuitiota ja asioiden hajottamista järkeviksi kokonaisuuksiksi. Mutta se kulkee nätisti käsi kädessä prototyypityksen, alhaalta-ylös-ohjelmoinnin ja testipohjaisen ohjelmoinnin kanssa. (...)
[[Image iterated.png]] (nettipäiväkirja 19.10.2019) My son often makes games with Löve (https://love2d.org/wiki/Main_Page). We are on a trip together, and I had an idea that I wanted to implement. (...)
Muistan, että joskus pienenä pirpanana, kun harjoittelin ohjelmoimaan, pidin tiettyjä kieliä "leluina" (Basic, Logo) ja toisia jotenkin "ammattimaisina" tai "asiallisina" (C, C++). (Myöhemmin tein näistä ja muista ennakkoluuloista näyttelyn, [näyttely: ohjelmointikielten kuvat].) Samanlaisia jaotteluita tulee vastaan muissakin työvälineissä: Centos on "vakavasti otettava" Linux-jakelu kun Ubuntu on "lelu", Oracle "todellinen" tietokanta, PostgreSQL "lelu" (tai MySQL "oikea", SQLite "lelu", riippuen keneltä kysyy). Jossain vaiheessa CORBA oli vakavasti otettava teknologia ja HTTP-kyselyiden tekeminen suoraan taustapalveluihin epäilyttävää h4xxorointia, vaikka sittemmin tämä jälkemmäinen onneksi lanseerattiin uudella nimellä (REST), ja sitten se onkin ollut katu-uskottavaa. Jos vain ihmiset suostuisivat vielä uskomaan, että skeemallinen JSON ei ole yhtään sen ammattimaisempaa kuin skeematon. (...)
"Hark! a vagrant" -sarjakuvassa mainostettiin tätä käytösopasta, joka onkin oikeasti aika hienoa luettavaa: (...)
Olennaisesti, nämä ovat aiheita, joista voi järjestää esityksiä / keskusteluita / työpajoja [nörtti ja geek] -henkisille ihmisille. (...)
Löysin hauskan kielen, Dynan (http://cs.jhu.edu/~darcey/dyna-tutorial.pdf). En nykyään löydä kovin usein kieliä, joissa törmäisin uusiin ajatuksiin. Dynassa logiikkaohjelmointiydin on liitetty funktionaalistyyppiseen lausekesyntaksiin (vähän niin kuin GF:ssä) ja lisäksi määritelmät ovat aggregoivia eli koska jokaisesta lauseesta voi olla monta tulosta niin määritelmissä kerrotaan miten ne tulokset yhdistellään. (...)
(nettipäiväkirja 31.01.2018) I found a handy way to use the Clojure threading macros (->, ->>, etc). Just to give some background, these macros provide a very nice clojure-flavoured alternative to the ($) operator of haskell, i.e. they allow for writing nested function calls without the nesting. The following are equivalent: (...)
SmallFP-muistiinpanot. (...)
Olen aina ollut sitä mieltä, että [Haskell] on yksinkertainen kieli ja siinä vain tarvitsee kertoa, miten asiat ovat (esimerkiksi, x `nand` y = not $ x && y). Mutta nyt olen alkanut kiinnittää huomiota siihen, että ihmiset teettävät Haskellilla aikamoisen määrän koodia käyttäen avukseen sen tyyppijärjestelmässä olevia oletusmäärittelyitä erilaisille tyyppiluokille. Nämä tyyppiluokat taas on osittain nimetty matemaattisilla termeillä, osittain ohjelmointitermeillä, ja niillä on kirjastossa hirveä määrä instansseja, jotka pitäisi tuntea, jotta ymmärtää, mitä tapahtuu. Melko kevyt esimerkki: (...)
Löysin koneeltani jotain satunnaisia obfuskoidun Pythonin esimerkkejä :) (...)
(nettipäiväkirja 26.02.2018) Tänään on näemmä tällainen kirjallisuus-WTF-päivä. Olen nähnyt monessa paikassa lainatun tutkimustulosta, jonka mukaan pariohjelmointi vie 15% enemmän aikaa kuin yksin ohjelmointi (saman tehtävän toteuttamiseen), mutta tuottaa 15% vähemmän ohjelmavirheitä. Tämän väitteen lähde on ilmeisesti https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF . (...)
(nettipäiväkirja 26.02.2018) Luin populaaritiedeteoksesta ''Linked'' (Barabási 2002), jonka tiedot sinänsä ovat vanhentuneita, että ''n'' solmun satunnaisesti muodostettuun verkkoon on yleensä muodostunut yksi iso yhdistetty klusteri, mikäli linkkejä on vähintään saman verran kuin solmuja. Olisi kiva verifioida tämä itse. (...)
Sain mielestäni hyvän ajatuksen. Tausta: olen ohjelmoijien dynaaminen vs staattinen tyypitys -kiistassa melkein niin paljon dynaamisen tyypityksen puolella kuin voi olla, ja siksi tutkin mielelläni argumentteja staattisen tyypityksen puolesta. Yksi niistä on se, että tyypeistä saa valmiiksi jonkinlaisen käsityksen siitä datasta, jota ohjelma käsittelee, joten datan kulkeutumista ohjelmassa ei tarvitse seurata niin pitkälle ymmärtääkseen tietyn koodinpätkän. (...)
(nettipäiväkirja 01.02.2018) As it seems I'm now sharing all kinds of things related to clojure, I think I'll also share my ~/.lein/profiles.clj: (...)
(nettipäiväkirja 26.01.2018) Tajusin juuri, että on oikeastaan tosi sääli, ettei ole juuri ollenkaan esimerkkejä ohjelmista, jotka on kirjoitettu merkkijonojen uudelleenkirjoitusjärjestelmillä (Semi-Thue-järjestelmillä). No, tässä on yksi esimerkki, binäärilukujen yhteenlasku. Sen voi tietenkin kirjoittaa tosi monella muullakin tavalla. Syötteeksi annetaan esimerkiksi merkkijono "plus(11,11)" ja tuloksena on merkkijono "110". (...)
Huoh. Luulin, että Clojurescript ja Clojure toimii ainakin perusprimitiivien osalta samalla tavalla, mutta ei: (...)
Näillä harjoituksilla voit omatoimisesti opiskella ohjelmointia ja ohjelmien suunnittelua Logo-kielellä. Oppimasi asiat ovat sovellettavissa myös muihin ohjelmointikieliin - joko suoraan, niin että voit käyttää samoja tekniikoita eri kielissä, tai epäsuorasti, siten, että toteutat jonkin Logo-komennon toisessa ohjelmointikielessä ja sitten pääset käyttämään sitä. (...)
Varoitus: tämä sivu liittyy ohjelmointiin! (...)
Näiden selittäminen on kesken. Termeille, joissa ei ole linkkiä, en ole vielä kirjoittanut selitystä. (...)
Opin tällä viikolla asian, jonka minua coolimmat tyypit ovat varmaan tienneet jo kauan: jokainen toisentyyppisiä tietoja sisältävä induktiivinen tietotyyppi ja jokainen tällaisen tietotyypin derivaatta (niinkutsuttu "zipper") toteuttavat komonadin. Ja komonadia taas voi käyttää laskemaan tietorakenteesta uuden tietorakenteen, jossa jokaisen solun sisältö voi riippua koko tietorakenteesta. Zipperien lisähyöty on siinä, että tulos voi riippua myös laskettavan kohdan ulkopuolella olevista asioista, kun taas induktiivisten tietorakenteiden komonadissa se voi riippua vain laskettavan kohdan alla olevista asioista. (...)
Tässä on aika hyvä artikkeli yhdestä näppärästä fronttidevaustyylistä: (...)
LOL, olen ollut "early adopter" monadien suhteen :) Ei olisi kyllä joskus 2002 tullut mieleenkään nähdä asia niin, mutta nythän listakeräelmät, geneerinen map() ynnä muu monaditauhka on tulossa yleiseen tietoisuuteen pikku hiljaa. (...)
(nettipäiväkirja 09.02.2016) Olen nähnyt viime aikoina useiden koodereiden kirjoittavan, että heidän mielestään hyvä koodi on eleganttia ja että he haluavat kirjoittaa eleganttia koodia. Olen jotenkin onnellinen, että tämä näkökulma on pinnalla, mutta täytyy silti sanoa, että ''elegantti'' on aika huonosti määritelty sana eikä oikeastaan ohjaa koodin kirjoittamista yhtään mihinkään. Elegantti tarkoittaa "näppärää, tyylikästä, hienoa". Miksi kukaan haluaisi kirjoittaa epäeleganttia koodia? Lähinnä sanan arvo on siinä, että se korostaa, että koodin ei pidä olla ''vain'' toimivaa vaan myös kaunista. Mutta eikö kauneus ole katsojan silmässä? (...)
Ihan mahtava ohjelmointikielivertailu! http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprtTR.pdf . Periaatteessa köyhempi kuin shootout (http://benchmarksgame.alioth.debian.org/), mutta mitattu myös kehitykseen menevää aikaa ja joka kielellä on monta toteutusta - erittäin arvokas kontribuutio siis, metodisista heikkouksista huolimatta. (...)
(nettipäiväkirja 23.08.2015) Pidän töissä koulutuksen ohjelmistokehityksen periaatteista, joten ajattelin linkittää materiaalin tännekin: http://members.sange.fi/~atehwa/slides/pomsd.html (...)
(nettipäiväkirja 22.10.2015) Olen aina inhonnut ORMeja (object-relational mapper). TL;DR: voit käyttää ORMia tietojen päivittämiseen mutta älä käytä sitä kyselyihin. (...)
(nettipäiväkirja 23.10.2015) Tapahtumapohjaiset palvelimet (eli niin sanottu "asynkroninen ohjelmointi") ovat nousseet kovasti viime aikoina. Oikeasti tapahtumapohjaisuus on mahdotonta erottaa säikeistä, jos kieliympäristö (esim. Erlang tai Haskell) abstrahoi sen tarpeeksi hyvin. Kyseessä on oikeastaan kaksi erillistä kysymystä: 1) mikä on luonteva tapa ''kirjoittaa'' rinnakkaiskoodia ja 2) mikä on hyvä tapa ''toteuttaa'' se rinnakkaismalli, joka kielessä esitellään. (...)
(nettipäiväkirja 20.08.2015) Ennustan, että Linux-säiliöt (''Linux containers'') tai säiliöt ylipäänsä tulevat olemaan tosi, tosi iso juttu. Tämä ennustus on tavallaan aika helppo tehdä, koska niihin perustuvat "virtuaalipalvelimet" ovat jo kaupallinen menestys ja todennäköisesti monen pilvipalvelun taustalla (ks. [pilvilaskennasta ja pilvipalveluista]). Väitän silti, että Linuxin nimiavaruusisoloinnin mahdollisuuksia on vasta vähän kokeiltu. (...)
(nettipäiväkirja 02.08.2015) Viime aikoina olen ajatellut jatkaa [CSC:n ohjelmointikerho]a. Ongelma on se, että haluaisin opettaa lapsille jotain hyödyllisempää kuin Scratch, jossa on suorituskykyongelmia ja lisäksi ohjelmat kirjoitetaan komentosarjoina. Tässä on muutamia visioita, mitä voisi olla sen sijaan: (...)
Tämä sivu käsittelee sitä, millaista on olla "erikoinen" ja miten ihmiset suhtautuvat siihen. Minun on paljon vaikeampi puhua tästä kuin useimmista muista asioista, koska aihe on tulisten mielipiteitten ja sosiaalisten odotusten kyllästämä ja koskee minua suoraan. Eli siis, miten voisi kirjoittaa omasta erikoisuudestaan ilman, että vaikuttaa omahyväiseltä kusipäältä? Tai olematta sellainen? ([Yli-ihminen]?) (...)
(nettipäiväkirja 30.06.2015) Teimme Purrrrrrin kanssa kokeeksi muutamia ohjelmointiin liittyviä haikurunoja. Tässä esimerkkejä. (...)
(nettipäiväkirja 12.05.2015) Olen aina aika ällikällä lyöty, jos jokin opiskelemani asia on oikeasti hyödyksi työssäni. Viimeksi se tapahtui, kun totesin, että muodollinen [logiikka] on oikeasti hyödyllinen taustatieto, kun kehittelee ja sovittaa yhteen metatietomääritelmiä. Nyt olen saanut todeta, että jopa [seminaari esoteerisista ohjelmointikielistä] on sovelluskelpoinen: sen verran omituinen on se kieli, jolla Novell/NetIQ Identity manageriin tehdään sääntöjä. Kielen nimi on DirXML-script. (...)
(nettipäiväkirja 28.04.2015) Kun selailee Ylen uutisia, tulee sellainen vaikutelma, että konstruktionismi opetuksessa (ja sen lievempi ellei suorastaan vaihtoehtoinen muoto, [tutkiva oppiminen]) on vihdoinkin lyömässä läpi kouluissa. Ja se on onneksi konkretisoitumassa sitä kautta, mistä se syntyikin, nimittäin ohjelmoinnista: vanhempien ja opettajien sukupolvenvaihdos on ajamassa läpi sen, että [ohjelmointi on perustaito] ja että koulussa on opittava [ohjelmointia lasten ehdoilla]. (...)
Työpaikan kirjahyllystä löytyi hämmentävä opus: "Visual programming / systems and paradigms". Se oli kirjoitettu 90-luvulla, jolloin visuaaliset käyttöympäristöt olivat kuitenkin aika uusi juttu (ainakin mainstreamissa). Siinä esiteltiin vaikka mitä visuaalisia notaatioita ihan mille sattuu, lähtien virtapiirien suunnittelukaavioista erilaisiin graafisiin tietokantakyselykieliin ja tilakonemäärittelyihin. Kaikenlaisia historiallisia kummajaisia, kuten rekursiivisia ATN-verkkoja ja unifikaatiokaarin yhdistettyjä logiikkaohjelmia, sivuttiin myös. (...)
Tänään osuin moneen mielenkiintoiseen blogikirjoitukseen. En ole tehnyt www-kehitystä nyt pariin vuoteen (koska työtehtävät eivät ole sattuneet juuri siihen) ja halusin ottaa selvää erityisesti siitä, miten nykyään kannattaa tehdä mahdollisimman yksinkertainen www-sovellus (eli mitä on tarjolla esim. CGI-rajapinnan ja mod_python-rajapinnan tilalle). Tällainen etsintä toi esiin Node.js:n, CherryPy:n jne. kaltaisia teknologioita. Yritin siis väistellä megalomaanisia "full stack" -www-kehitys-ympäristöjä, koska minua ei tällä erää kiinnostanut, millä tavalla hoidetaan tietokantayhteydet, www-sivujen generointi aihioista jne. Etsintä toi vastaan mm. seuraavia artikkeleita: (...)
'''Huom. Varsinainen sivu on siirretty tänne:''' https://confluence.csc.fi/display/virkistys/CSC%3an%20ohjelmointikerho (...)
(nettipäiväkirja 25.11.2014) I just realised it might be worth advertising in English that I've implemented multiturtle/dynaturtle functionality for UCBLogo. I've been searching for the documentation of UCBLogo's experimental object system and this seems to be something of a FAQ... (...)
Ohjelmointia voi opettaa hyvin monella tavalla. On hyvin keskeistä, kuinka paljon pitää kirjoittaa (virheetöntä) tekstiä, ennen kuin pystyy jollain tavalla testaamaan tuloksia. Joissakin ohjelmointiympäristöissä tulosten näkeminen on niin paljon tulevaisuudessa, että jopa suoritusvuon mallintamiseen opetetaan käyttämään apukeinoja, [vuokaavio]ita. Tällä sivulla yritän listata, mitä tarvitaan siihen, että ohjelmoijat pystyvät keskittymään mielenkiintoisiin asioihin, sen sijaan, että tappelevat saadakseen tietokoneen ymmärtämään edes jotain. (...)
Olen taas sluibaillut omien lasteni opettamisesta erikseen, koska olen pyörittänyt [CSC:n ohjelmointikerho]a. Mutta aina joskus opetan myös erikseen omia lapsiani. Tänään kysyin keskimmäiseltä, onko jotain, mitä hän erityisesti haluaisi opetella, ja hän näytti käsillään "semmoinen, jossa kuva pyörii tälleen". Tämä oli mielenkiintoinen haaste, ja koska sellaisen toteuttaminen ei oikeasti vaadi kovin pitkää ohjelmaa, katsoimme. (...)
(nettipäiväkirja 14.10.2014) Oletteko ehkä joskus kuulleet kielestä nimeltä awk? Jos olet käyttänyt Unixia (ks. [Unix-aiheisia artikkeleita]), olet varmaankin törmännyt siihen ainakin ohimennen. Haluan hiukan mainostaa awkia. (...)
(Tähän juttuun on kuvitusta tarjolla: https://www.flickr.com/photos/myscience/sets/72157644742760547/) (...)
Nyt tulee [Skrolli]in juttu [Linkki]-resurssikeskuksesta: [ohjelmointia lasten ehdoilla]. (...)
Aikoinani, 7-vuotiaana vuonna 1986, opettelin ohjelmointia ala-asteellani Logo-ympäristössä. Tämä ohjelmointiympäristö on edelleen mielestäni yksi parhaita opetusympäristöjä niin ohjelmoinnin kuin ajattelunkin kannalta. Sen ainoa varsinainen "puute" oli se, että komennot koostuivat kirjaimista ja numeroista; tämä teki ohjelmoinnin oppimisen vaikeaksi niille, jotka eivät vielä olleet tajunneet kirjaimia ja numeroita. (...)
(nettipäiväkirja 15.07.2012) En tajua, miksi moniajavien graafisten käyttöjärjestelmien [käyttöliittymäsuunnittelu] ei ota huomioon sitä, että koneen ollessa kuormittunut (tai netti- tai oheislaiteyhteyksien ollessa hitaita) ohjelman saama syötevirta ei edusta tarkalleen käyttäjän toimien aikasarjaa. Kun kone on ylikuormittunut, tapahtuu tyypillisesti kaksi asiaa: (...)
(nettipäiväkirja 14.05.2013) [Factor] ja muun konkatenatiiviset kielet ovat hyvin tiiviitä. On tarkastelemisen arvoista, miten nämä kielet onnistuvat olemaan ilmaisultaan niin lyhyitä kuin ovat. Yksi tärkeä syy on se, että funktioiden parametreja ei deklaroida eikä merkitä. Mutta kombinatorinen logiikka eliminoi myös lokaalit muuttujat, ja silti lausekkeet ovat siinä monimutkaisempia kuin konkatenatiivisissa kielissä. Lisäksi tulokset ovat ainakin minusta vaikeampia lukea. (...)
Olen suhtautunut skeptisesti siihen, että hierarkia-sanaa voisi käyttää mihinkään muuhun kuin epäselvään vihjaamiseen, mistä on kysymys. Olen pitänyt tätä sanaa niin huonosti määriteltynä, että esimerkiksi [anarkismi]n määrittelyssä olen tukeutunut toisenlaisiin sosiaalisten suhteiden mittareihin. Mutta nyt olen ehkä muuttanut mieltäni. (...)
Hih, ei pitäisi koskaan alkaa tehdä jotain addiktiivista ohjelmointihommaa... Kaivoin [Lambda ry]:n tapaamista varten netistä viime postauksessa mainitsemani Tron-tekoälyjen testausjärjestelmän ja olen jatkokehittänyt sitä. Työn tulokset ovat saatavilla suoraan versiohallinnasta (http://members.sange.fi/~atehwa/vc/prod/tronserver/) ja dokumentaatio on täällä: (...)
Minulla on projekti opettaa lapset tekemään hauskoja ja hyödyllisiäkin asioita niillä välineillä, joilla oikeasti saa jotain aikaan, toisin sanoen komentoriviohjelmilla. Yritän muistaa blogata projektin etenemisestä. (...)
Pidin taas muutamia oppitunteja lapsille. Mukavaa, kun on joululoma, niin ehtii tekemään tällaista. Yksityistunnit ovat lisäksi käteviä sikäli, että muut lapset saavat puuhailla mieleisiään asioita, kun yhdellä on oppitunti, eikä kukaan ylikuormitu (paitsi ehkä minä?). (...)
On olemassa monta erilaista tapaa ohjelmoida. Ohjelmoijana voi kehittyä tutustumalla uusiin ohjelmointitapoihin. ''Ohjelmointiparadigmat'' ovat keskenään täysin erilaisia tapoja kirjoittaa ohjelma. (...)
Käsitys siitä, mitä tietokoneelta voi odottaa, on muuttunut ajan kuluessa. Enimmäkseen vaatimukset ovat kasvaneet: tietokoneilta odotetaan aina vain suurempaa laskentatehoa, tallennus- ja tiedonvälityskykyä. On kuitenkin asioita, joissa ihmisten odotukset tietokoneiden suhteen ovat laskeneet. Lähes kukaan ei enää odota tietokoneiden ymmärtävän ihmisten kieltä, tunnistavan, näkyykö kuvassa vettä, tai arvioivan eri lähteiden luotettavuutta. Nykyajan tietokoneilla lasketaan kymmeniä kolmiulotteisen maailman projektioita sekunnissa, mutta 70--90-luvulla vaativimmat ohjelmat olivat ne, jotka yrittivät ymmärtää monimutkaista maailmaa. Tässä artikkelissa tarkastellaan yleisellä tasolla näiden ohjelmien toimintaa. (...)
Olen törmännyt nyt pariinkin otteeseen ohjelmoinnin tyyliohjeisiin tms., jossa on poikkeusten käytöstä suunnilleen tällainen suositus: (...)
Konseptuaalisesti eheä [LISP]-variantti. Itse tykkään nykyään tehdä koodikokeiluni Schemellä ja lisäksi olen suunnitellut [Scheme-käyttis]tä. Tähän liittyy muutenkin pohdintaa siitä, minkälainen tietokoneiden käyttöympäristön pitäisi ''tosissaan'' olla. (...)
Minun mielestäni olio-ohjelmointi ei tarkoita mitään aivan tiettyä. Olen nähnyt niin monta erilaista oliopohjaiseksi kutsuttua kieltä, että tiedän kyllä aika monta asiaa, joita sillä tarkoitetaan eri yhteyksissä. Ja koska olio-ohjelmoinnista puhutaan yhä, voisi olla hyvinkin vaivan arvoista kertoa, mitkä olio-ohjelmoinniksi kutsutut ajatukset ovat minusta tutustumisen väärtejä. (...)
Symboli on ihan loistava tietotyyppi, mutta useimmat ohjelmoijat eivät edes tiedä niiden olemassaolosta; tai ovat tottuneet pärjäämään ilman niitä, jolloin eivät osaa hyödyntää niitä edes, vaikka ne olisivat tarjolla. Tämän kirjoituksen pointti on selittää, mitä hyötyä symboleista on, ja innostaa ihmiset käyttämään symboleita enemmän ohjelmissaan. (...)
Nykyään ohjelmoijat pitävät jotenkin itsestään selvänä seuraavaa jakoa: on olemassa lukuja, sitten on olemassa merkkejä, ja merkeistä koostuu merkkijonoja. Luvuilla voi osoittaa merkkijonoista kohtia, mutta se onkin ainoa, miten ne liittyvät merkkijonoihin. (...)
Chatterbot on ohjelma, joka keskustelee käyttäjän kanssa. Tyypillisesti se sisältää jonkinlaista tekoälyä. Erotukseksi vakavasti otettavasta kieliteknologiasta, joka pyrkii tosissaan ymmärtämään käyttäjän kommentit (conversational AI, [GOFAI]-teknologiaa), niitä kutsutaan "tekohöpötykseksi": niiden tarkoitus on vain antaa ''vaikutelma'' käyttäjän kanssa keskustelemisesta. (...)
Huomasin jotain mielenkiintoista: Brian Harvey ja kumppanit ovat tehneet [Scratch]ista laajennetun version nimeltä BYOB, http://byob.berkeley.edu/ . Tämä on hyvä, koska Scratchissa minua häiritsee eniten sen rajoittuneisuus. (...)
([kategoria: ohjelmointi]) (...)
Vaihdettavien komponenttien olemassaolo edellyttää, että ohjelma / tehtävä on jaettu niin hyvin erilaisiin osiin, että jollekin näistä osista voi olla useampia toteutuksia. Jos loput ohjelmasta toimii näiden vaihtoehtoisten komponenttien kanssa, se on yleensä osoitus siitä, että osiin jako on tehty oikeaoppisesti ja selkeästi, ja että eri toiminteiden vastuut on delegoitu softassa järkevästi. (...)
Tämän kurssin tämänhetkinen virallinen sivu on http://www.ling.helsinki.fi/kit/2008s/clt230/ (...)
As we probably all know, monads are handy programming constructs that let us express different "execution environments" and operations therein in a uniform way. Every monad gives the programmer some kind of environment where it is possible perform arbitrary computations in the ordinary way, while the monad controls the workings of the environment and usually provides some additional services specific to that environment. For instance, the ''state monad'' provides an environment with two additional services, storing a value for later reference and querying the stored value. The monad takes care of threading this stored value through the whole computation, including recursive calls, etc. Any kind of effect that could be achieved through "side effects" (violations of functional purity) can be modelled as services in a monad that is specifically designed to be able to provide those services. (...)
Tällaisia kieliä ei juurikaan käytetä, koska suuntaamattomista verkoista on "vain haittaa" verrattuna suunnattuihin. Yleensä, jos haluaa kuvata jotain verkkorakenteena, '''ei''' halua ottaa huomioon symmetrioita ja sitä, että jotenkin toisin päin käännettynä (toisesta näkökulmasta katsoen) verkkosi voikin tarkoittaa jotain muuta. Niinpä kaikki todella käytetyt verkkojen uudelleenkirjoituskielet ovat suunnattujen verkkojen uudelleenkirjoituskieliä. Suunnattujen verkkojen uudelleenkirjoituskieliin kuuluvat myös puiden uudelleenkirjoituskielet, jotka ovat funktionaalisia ohjelmointikieliä. (Puu on käytännössä sellainen asyklisen suunnatun verkon osa, johon kuuluvat kaikki solmut, joihin pääsee annetusta solmusta ulosmeneviä kaaria pitkin.) Mutta, jos ei tarvitse miettiä käytännöllisyyttä, suuntaamattomien verkkojen uudelleenkirjoituskielet ovat hauskoja. Sitä paitsi suunnatun verkon voi koodata suuntaamattomaksi korvaamalla jokaisen kaaren jonkinlaisella asymmetrisella solmuyhdistelmällä, esimerkiksi {{{ a -> b -> c -> d }}} muuttuu muotoon {{{ a - o - o - b - o - o - c - o - o - d \ \ \ o o o }}} (...)
Aiheeseen liittyvät myös: * [yhdistetyt merkkien kaltaiset tietotyypit] * [Forth] * [symbolien kontekstualisointi] (...)
Funktionaalisissa kielissä ja järjestelmissä: säännöt siitä, missä järjestyksessä kaavan osia suoritetaan. (...)
Tässä listataan, mitä elementtejä "perinteisessä" käyttöliittymäsuunnittelussa erilaiset laiteriippumattomat widgetit vastaavat. Katso [laiteriippumaton käyttöliittymä]. (...)
Yritän tässä listata tämän nettipäiväkirjan sisältöä aihepiireittäin. (...)
Noin lähtökohtaisesti Haskell on paras ohjelmointikieli, joka on olemassa. Sen kuvausvoima on suuri, käyttö hauskaa ja toteutus selkein käytännön osoitus siitä, että sivuvaikutukseton ohjelmointi ("pure functional programming") voi olla käytännöllistä. On tarvittu melkoinen määrä tutkimustyötä, että asiat on saatu käytännöllisiksi Haskellin lähtökohdista; nyt, kun tuo tutkimustyö on tehty, ihmiset pystyvät kirjoittamaan ihan oikeasti käyttökelpoisia ohjelmia ympäristössä, jossa samalla voi käyttää äärettömiä tietorakenteita, automaattista tyyppitarkistusta ja kaikkea muuta kivaa. Haskelliin upotettu tutkimustyö on myös tuottanut lisää ymmärrystä ja ennen kaikkea käytännön kokemusta predikaattilogiikkaa vahvemmista logiikoista sekä kategoriateoreettisista rakenteista. (...)
Huom! Tämä on [nillitys]. Ja tässä mainitut asiat on korjattu Python3:ssa: http://docs.python.org/release/3.0.1/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit (...)
Monet ohjelmoinnin [metodologia]sta mielipiteitä esittävät kirjoitukset tekevät pohjaoletuksia siitä, millaisessa ympäristössä ja millaisilla taustaehdoilla ohjelmointityötä tehdään. Tämä on tietenkin ymmärrettävää, koska ihmiset tekevät ohjelmointityötään tietyssä ympäristössä eivätkä välttämättä kuluta aikaansa sen miettimiseen, mitkä kaikki kontekstuaaliset piirteet ''voisivat'' olla toisin siitä huolimatta, että työ miellettäisiin edelleen ohjelmointityöksi. Tässä on muutamia asioita, jotka ovat toisin, kun ohjelmistokehitys ei olekaan kaupallista. (...)
Ohjelmointiin liittyvät sivut. (...)
('''Huom.''' Tämän materiaalin kirjoittaminen on kesken, mutta koska tärkeät osat siitä ovat jo valmiita, se on nyt clt230:n "virallista" oppimateriaalia.) (...)
"Good Old-Fashioned Artificial Intelligence". (...)
This interesting book by F. Bergadano and D. Gunetti provides a mixture of theoretical results and practical advice / opinions in a way that makes me wonder about their intended audience. Basically, what they seem to have in mind is a major shift in software development methodology: the tools and procedures they develop are aimed at practical program induction. What this means in practice is that programming languages would not be formalisms to specify exact input-output behaviours, but rather sets of constraints (examples of input-output pairs, constraints on program structure etc.) from which the actual program is induced. (...)
Mitä kauempana ohjelmointikielen ajattelutaso on siitä, miten ohjelman suoritus varsinaisesti etenee, sitä helpommin siinä kirjoittaa vahingossa tehottomia ohjelmamäärittelyitä. Ohjelma on tehoton, mikäli sen [kompleksisuus] suhteessa syötteeseen on korkeaa luokkaa. Itse asiassa tämä ei ole mikään ongelma, koska on paljon helpompaa korjata toimiva mutta tehoton ohjelma tehokkaaksi ''ja'' toimivaksi ohjelmaksi kuin korjata "tehokas" mutta toimimaton ohjelma sellaiseksi. (...)
''Peliteoria'' tutkii [peli]tilanteita. (...)
Ainoa mahdollisuus ikinä tehdä tietokoneista muuta kuin työkaluja. (...)
{{{ Ma tiedot järkkään listoiksi ja luvut taulukkoon en tarkkuudesta tingi, siksi ohjelmoija oon Ma oppinut oon metodit ja kauhut deadlinen Oon kopperossain aina vain mutt' vapaa sittenkin Mun sanat muuttaa maailmaa saan tiedolla sen valloittaa ja tulokset mun koodaustyön valona kiitää läpi yön Vaikk' järkeeni mä tukeudun, myös luotan kohtaloon: oon ohjelmoijaks' syntynyt, siis ohjelmoija oon. (...)
(Hahaa, otin käyttöön tämän termin ennen kuin m$ lanseerasi sen!) (...)
Teknologia on jonkinlaista suurta ja tarkkaa hommaa, jolla saadaan aikaan jotain, mitä muuten ei saataisi. Teknologiaa ovat myös ne sosiokulttuurilliset ilmiöt, mitä tämä aikaansaaminen aiheuttaa. Meidän kulttuurimme on (ollut noin 500 viime vuotta) pitkälti teknologian ohjailemaa, mikä ei ole ollenkaan epäoikeudenmukaista, koska teknologiamme on (ollut aina) kulttuurimme ohjailemaa. (...)
([automatisoitu testi] on jatkoa tälle sivulle.) (...)
Olen muutamaankin otteeseen päässyt selittämään, miksi PHP on paska kieli. Sanon tässä nopeasti puuttumatta yksityiskohtiin (mutta saa kysyä): (...)
Metodologia on sen tutkimista, miten jokin asia pitäisi tehdä. [ATK]-alalla metodologiat sisältävät niin suunnittelutapoja, suunnitteluprosesseja kuin sosiaalisia menettelyjä. Tässä on yksi nousemassa oleva trendimetodologia: http://c2.com/cgi/wiki?ExtremeProgramming (...)
Tämä sivu yrittää olla jatkoa [testausstrategioista]-sivulle. (...)
(tarkoituksena luokitella tekstejä siten, ettei luokittelualgoritmia tarvitse opettaa eikä sille tarvitse kertoa, mihin luokkiin luokitellaan) (...)
Scsh, eli Scheme shell, on [LISP]in erään variantin Schemen alavariantti, joka on erityisesti suunniteltu toimimaan hyvin yhteen Unix-ympäristön kanssa. Se sisältää muun muassa seuraavat ominaisuudet: (...)
Tehty näin: (...)
Äänien tuottamisessa sampledatana on tällainen ongelma: äänidataa pitää aina olla saatavilla, kun sitä tarvitaan, muuten ääni katkeaa - mutta jos äänidataa tekee hirmuisesti etukäteen, äänien muutoksiin tulee hirmuinen latenssi. Hmm. (...)
Ensinnäkin pieni kertaus: irrationaaliluvut ovat lukuja, joita ei voi ilmaista (tarkasti) kahden luvun suhteena, eli siis joita ei voi ilmaista murtolukuna. Tämä tarkoittaa myös, ettei niitä voi ilmaista desimaalilukuina, koska jokainen desimaaliluku on muunnettavissa murtoluvuksi, esimerkiksi 0,00374 = (...)
Ohjelmointikieliperhe, jonka jäsenet ovat tyypillisesti: (...)
Tämä ohjelma perustuu ajatukseen, että tulevien kirjaimien (foneemien, ...) ennustaminen antaa olennaista tietoa kielen morfologisesta rakenteesta. (...)
Lyhimmän polun löytämiseen tarkoitettu algoritmi mielivaltaisissa (mutta yleensä selkeän geometrisissa) graafeissa. Dijkstra-algoritmi lisättynä jäljellä olevaa matkaa laskevalla heuristiikalla. (...)