A Few More Lessons from Fetchmail
Fetchmailista saatuja opetuksia
On koetettava löytää tapa otsikoida tämä luku kiinnostavasti. - Jopi
Before we go back to general software-engineering issues, there are a couple more specific lessons from the fetchmail experience to ponder. Nontechnical readers can safely skip this section.
On syytä käydä läpi vielä muutama Fetchmailin kehityksestä opittu asia ennen kuin palataan yleisiin ohjelmistosuunnittelun kysymyksiin. Tämän luvun voi jättää väliin, jos ei ole kiinnostunut ohjelmistotekniikasta.
Kuulostaa melko kankealta: mieluummin "Käydään vielä lävitse muutama Fetchmailista opittu asia, ennenkuin palataan ohjelmistokehitystä yleisesti käsitteleviin aiheisiin."
The rc (control) file syntax includes optional `noise' keywords that are entirely ignored by the parser. The English-like syntax they allow is considerably more readable than the traditional terse keyword-value pairs you get when you strip them all out.
Fetchmailin asetustiedostossa on vaihtoehtoja kuvailevia sanoja, jotka ohjelman jäsentäjä jättää huomioimatta. Tämä tekee mahdolliseksi luonnolliseen kieleen kuuluvien ilmauksien käytön. Ihmisen on helpompi lukea tällaisia asetuksia kuin perinteisiä avain-arvo -pareja, jotka jäävät jäljelle, kun kuvailevat sanat jätetään pois.
'Englanti' kannattaa tässä luvussa kääntää 'luonnolliseksi kieleksi'. - Jopi.
Sopiiko asetustiedosto tähän? Jep.
Näyttää pasremmalta, jos kirjoittaa "häly-avainsanoja" eli laittaa koko merkkijonon lainausmerkkeihin.
These started out as a late-night experiment when I noticed how much the rc file declarations were beginning to resemble an imperative minilanguage. (This is also why I changed the original popclient server keyword to poll).
Kuvailusanojen käyttö sai alkunsa eräänä iltana kun huomasin, että asetustiedoston määritykset alkoivat muistuttaa yksinkertaista käskykieltä. Tässä on myös yksi syy siihen, miksi vaihdoin POP-asiakasohjelman avainsanan 'palvelin' muotoon 'kysely'.
Avainsanojen käännökset?!
It seemed to me that trying to make that imperative minilanguage more like English might make it easier to use. Now, although I'm a convinced partisan of the make it a language school of design as exemplified by Emacs and HTML and many database engines, I am not normally a big fan of English-like syntaxes.
Tuntui, että ohjelmasta saisi helppokäyttöisemmän, jos sen typistetyn käskykielen ilmauksia muutettaisiin luonnollisen kielen kaltaisiksi. Luonnolliseen kieleen kuuluvia ilmauksia käytetään Emacs-tekstiohjelmassa, HTML:ssä ja monissa tietokantamoottoreissa, ja olen periaatteen vannoutunut kannattaja, mutta yleensä en ole ollut ihastunut periaatteen käytännön toteutuksiin.
"helpomman käyttää" =>"helppokäyttöisemmän" Aika hankala kääntää fiksusti tuo viimeinen lause.. -- Olit kääntänyt sen vahingossa negaatioksi, siitä ehkä ongelma 
"Syntax" - syntaksi, lauseoppi (kieliopin osa-alue)5.12.2008 (JP)
Traditionally programmers have tended to favor control syntaxes that are very precise and compact and have no redundancy at all. This is a cultural legacy from when computing resources were expensive, so parsing stages had to be as cheap and simple as possible. English, with about 50% redundancy, looked like a very inappropriate model then.
Vanhastaan ohjelmoijat ovat suosineet äärimmäisen täsmällisiä ja tiukkoja asetusmäärittelyjä, joissa ei ole mitään ylimääräistä. Tämä on perua ajalta, jolloin tietokoneen suorituskyky oli niukka resurssi ja syötteen jäsentämisestä piti tehdä mahdollisimman halpaa ja yksinkertaista. Oli mahdotonta käyttää luonnollista kieltä, koska sen vaatimasta tilasta noin puolet on turhaa.
"Parse" - jäsentää (syntaksi) "oli siinä valossa täysin mahdoton hyväksyä." => "vaikutti hyvin huonosti soveltuvalta tuohon tarkoitukseen."
This is not my reason for normally avoiding English-like syntaxes; I mention it here only to demolish it. With cheap cycles and core, terseness should not be an end in itself. Nowadays it's more important for a language to be convenient for humans than to be cheap for the computer.
Tämä ei kuitenkaan ole syy, jonka vuoksi itse yleensä vältän luonnollista kieltä muistuttavia ohjelmointikieliä. Mainitsin edellä esitetyn perustelun ainoastaan jotta voisin nyt kumota sen. Nykyään kun prosessorien kapasiteetti on halpaa, ohjelmointikielen tiukkuus ei ole itseisarvo. On tärkeämpää, että ohjelmointikieli on helppoa ihmiselle kuin että se on nopeaa koneelle.
There remain, however, good reasons to be wary. One is the complexity cost of the parsing stage—you don't want to raise that to the point where it's a significant source of bugs and user confusion in itself. Another is that trying to make a language syntax English-like often demands that the English it speaks be bent seriously out of shape, so much so that the superficial resemblance to natural language is as confusing as a traditional syntax would have been. (You see this bad effect in a lot of so-called fourth generation and commercial database-query languages.)
On kuitenkin edelleen hyviä syitä olla varovainen. Ensimmäinen syy on luonnollisen kielen kaltaisen kielen jäsentämisen monimutkaisuus. Jäsentämisestä ei saa tulla ohjelmavirheiden ja käyttäjien ongelmien aiheuttajaa. Toiseksi käy usein niin, että luonnollista kieltä hyödyntävä ohjelmointikieli joutuu käyttämään niin omalaatuisia ilmauksia, että tulos on yhtä vaikeaselkoinen kuin tavallinen ohjelmointikieli. Tämä on selvästi nähtävissä tietokannoissa käytetyissä kaupallisissa ja niin sanotuissa "neljännen sukupolven" kyselykielissä.
Neljäs sukupolvi? "Tämä näkyy selkeästi niin kutsutuissa "neljännen sukupolven" ja kaupallisten tietokantojen kielissä." => "Tämä monimutkaisuus näkyy selkeästi niin kutsutuissa "neljännen sukupolven" ja kaupallisten tietokantojen kyselykielissä."
The fetchmail control syntax seems to avoid these problems because the language domain is extremely restricted. It's nowhere near a general-purpose language; the things it says simply are not very complicated, so there's little potential for confusion in moving mentally between a tiny subset of English and the actual control language. I think there may be a broader lesson here:
Fetchmailin asetuksissa käytetty syntaksi näyttää välttävän nämä ongelmat, koska se on rajattu tiukasti omaan tarkoitukseensa. Se on kaukana yleiskäyttöisestä kielestä. Sillä ilmaistavat asiat eivät ole kovinkaan monimutkaisia, joten ei ole todennäköistä, että asetustiedoston kielen ja luonnollisen kielen eroista tulisi ongelmia. Mielestäni tarinan yleinen opetus on:
"Mielestäni tarinan opetus on:" => "Mielestäni tarinan yleisopetus on:"
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
16. Jos kehittämäsi ohjelmointikieli ei ole läheskään Turing-täydellinen, sitä kannattaa ehkä makeuttaa luonnollisen kielen ilmauksilla.
Ks. http://fi.wikipedia.org/wiki/Turing-vahva. - Jopi.
Another lesson is about security by obscurity. Some fetchmail users asked me to change the software to store passwords encrypted in the rc file, so snoopers wouldn't be able to casually see them.
Lisäksi saatiin opetus näennäisen tietoturvan houkutuksista. Jotkut Fetchmailin käyttäjät pyysivät minua muuttamaan ohjelmaa siten, että salasanat tallennettaisiin asetustiedostoon salatussa muodossa, jotta urkkijat eivät saisi niitä haltuunsa.
by obscurity? -- olisiko "security by obscurity" = "tietoturvaa salailemalla"? Tällaisen käännöksen löysin jostain ja se toimii minusta hyvin. HM - Hyvältä vaikuttaa, mutta pitäisi lopputuotteessa ehkä selittää viitteellä; laitoin lainausmerkkeihin 5.12.2008 (JP)
I didn't do it, because this doesn't actually add protection. Anyone who's acquired permissions to read your rc file will be able to run fetchmail as you anyway—and if it's your password they're after, they'd be able to rip the necessary decoder out of the fetchmail code itself to get it.
En tehnyt muutosta, sillä se ei olisi oikeasti parantanut tietoturvaa. Kuka tahansa, jolla on oikeudet lukea käyttäjän asetustiedostoa, voi myös ajaa Fetchmailia käyttäjän oikeuksilla. Ja jos tällainen henkilö haluaa saada selville käyttäjän salasanan, hän voi hakea ohjelman lähdekoodista salasanan purkamiseen tarvittavan osan.
muutin tässä että "decoder" = "koodin osa", onko ok? - tai sityten vain "salauksenpurkaja", kuten siellä jo onkin vähän eri muodossa 5.12.2008 (JP)
All .fetchmailrc password encryption would have done is give a false sense of security to people who don't think very hard. The general rule here is:
Asetustiedoston (.fetchmailrc) salasanojen kryptaus olisi luonut valheellisen turvallisuuden tunteen sellaisille käyttäjille, jotka eivät ajattele asioita loppuun asti. Tästä saadaan yleinen sääntö:
17. A security system is only as secure as its secret. Beware of pseudo-secrets.
17. Turvajärjestelmä ei pysty tarjoamaan parempaa suojaa kuin mitä sen oma salaisuus nauttii. Varo puolisalaisuuksia.
pseudo-secrets? --näennäissalaisuus. Voisiko se tässä yhteydessä olla "näennäissalaus" tai "näennäinen salaus"