Keskustelu: Ohjelmointikysymykset: Eiffel-kielestä muutama kommentti

Eiffel on viimeksi mainittu 2009. Tässä lista kielen luonteesta:

Imperatiivinen, komentorakenteissa ei lohkosulkuja.
Strukturoitu ohjelmointi, ei "käteviä" hyppyjä.
Olioajattelu, mukaanlukien perustyypit, funktio-objektit ja geneeriset luokat.
Moniperintä.
Hoaren teorian mukainen luokan semantiikka, mahdollistaa määrittelyn ja verifioinnin.
Nollapointeriturvallisuus.
Rinnakkaisuus.
Puhdas kieli, suppea ISO-standadi.

Antaa olla lyhyesti, kai tässä on tärkeimmät.

Toisaalla

groovyb kirjoitti:

class
    HELLO_WORLD
create
    make
feature
    make
        do
            print ("Hello, %N%
                    %World%N")
        end
end

Tässä näkyy, että Eiffelillä voi kirjoittaa vain luokkia. Perustyypitkin ovat luokkia. Asiat yksinkertaistuvat siten, että ISO-standardissa on vain 174 sivua, C# 553 sivua.

vinsentti kirjoitti:

Tässä näkyy, että Eiffelillä voi kirjoittaa vain luokkia. Perustyypitkin ovat luokkia. Asiat yksinkertaistuvat siten, että ISO-standardissa on vain 174 sivua, C# 553 sivua.

Joudut keksimään paremman perustelun saadaksesi minut kiinnostumaan Eiffelistä. Mielestäni OOP ei ole mikään kaiken mullistava keksintö, mikä automaattisesti parantaa koodin laatua. Miksi ohjelmoisin Eiffelillä mielummin kuin esim. modernilla Cobolilla?

class-id MainClass.

method-id main static.
procedure division.
  display 'Hello world!'
  invoke type Console::ReadLine()
  goback.
end method.

end class.

jalski kirjoitti:

Joudut keksimään paremman perustelun

Avauksessa luettelin jotakin.

jalski kirjoitti:

saadaksesi minut kiinnostumaan Eiffelistä. Mielestäni OOP ei ole mikään kaiken mullistava keksintö, mikä

OOP on kuitenkin lyönyt läpi. Mielenkiintoista nähdä, miten sitä tehdään kunnolla. Eikä yritetä kaikkea.

jalski kirjoitti:

Miksi ohjelmoisin Eiffelillä mielummin kuin esim. modernilla Cobolilla?

En tunne Cobolia, näkyy olevan end-puoluetta.

miksi ohjelmoida noilla jäänteillä lainkaan? Tietty omaksi ilokseen voi noilla muinaisjäänteillä lottonumerogeneraattoreita väkerrellä, mutta siihen se sitten jääkin. Jos haluaa tutustua uuteen kieleen, kannattaa niihin käyttökelpoisiin tutustua, niistä voi olla jotain oikeaakin hyötyä. Varsinkin jos tätä alaa työkseen harjoittaa.

groovyb kirjoitti:

miksi ohjelmoida noilla jäänteillä lainkaan? Tietty omaksi ilokseen voi noilla muinaisjäänteillä lottonumerogeneraattoreita väkerrellä, mutta siihen se sitten jääkin.

Oletko kokeillut tehdä mitään Visual Cobolilla? Lopppujen lopuksihan sillä työskentelee oikeasti jo ihan mielellään ja koodi on helppolukuista ja helposti ymmärrettävää.

Visual Cobolia kuitenkin mainostetaan pelkästään ajatuksella "sinulla on 40 vuotta vanhaa koodia ylläpidettävänä." Jos Visual Cobolin tekijät pitäisivät sitä kiinnostavana kielellä kokonaan uusiin projekteihin, niin kai ne mainostaisivat sitä siihen itsekin.

groovyb kirjoitti:

Jos haluaa tutustua uuteen kieleen, kannattaa niihin käyttökelpoisiin tutustua, niistä voi olla jotain oikeaakin hyötyä.

Ainut varma kieli on C, se on ja pysyy alemman tason kielenä. Korkeamman tason kielissä tilanne elää. Esimerkiksi Javaa käytetään paljon, mutta sitä ei valita kilpailuetu mielessä.
Yksi investointipankki valitsee Haskellin ja toinen Eiffelin, samoin terveystietojen hallintajärjestelmän kehittäjä. Ne tekevät valinnan kilpailuetu mielessä, eivätkä tyrkytä kilpailijoille.

vinsentti kirjoitti:

Yksi investointipankki valitsee Haskellin ja toinen Eiffelin, samoin terveystietojen hallintajärjestelmän kehittäjä. Ne tekevät valinnan kilpailuetu mielessä, eivätkä tyrkytä kilpailijoille.

Niin ja silti lukemattomat vakuutus -ja pankkialan yritykset maailmalla ajavat ja ylläpitävät vuosikymmeniä vanhaa PL/I ja Cobol koodia. Mitähan kilpailuetua Eiffeliin siirtyminen antaisi, paitsi karmeat kustannukset kun korvattaisiin vuosikymmenien aikana suurkoneympäristössä toimivaksi testattua koodia.

jalski kirjoitti:

Mitähan kilpailuetua Eiffeliin siirtyminen antaisi,

Mikä siirtyminen? Toisinaan on tilaisuus valita.

vinsentti kirjoitti:

Mikä siirtyminen? Toisinaan on tilaisuus valita.

Pointtina oli, että miksi valitsisin Eiffelin esim. PL/I:n sijaan, jos kirjoittaisin finanssipuolen sovelluksia? PL/I:llä ainakin voin käsitellä suoraan desimaalilukuja ilman pyöristysvirheitä haluamallani tarkkuudella.

jalski kirjoitti:

PL/I:llä ainakin voin käsitellä suoraan desimaalilukuja ilman pyöristysvirheitä haluamallani tarkkuudella.

Tällaista perustelua oli paljon 40 vuotta sitten, mutta pitkiin aikoihin en ole kuullut. Puhuttiin teknistieteellisistä ja kaupallishallinnollisista kielistä, mutta ei enää.

vinsentti kirjoitti:

Tällaista perustelua oli paljon 40 vuotta sitten, mutta pitkiin aikoihin en ole kuullut. Puhuttiin teknistieteellisistä ja kaupallishallinnollisista kielistä, mutta ei enää.

Oma perustelusi tuntuu olevan pelkästään OOP Eiffelin eduksi. Miten OOP itsessään mielestäsi parantaa koodin laatua ja tehokkuutta? Vähän sama kuin aina miettisi jotain hienoa tietorakennetta ja oikeasti taulukko riittäisi hommaan.

vinsentti: En ole huomannut, että olisit esittänyt vielä yhtäkään konkreettista hyötyä Eiffelin käytöstä. Olet kertonut end-sanasta ja joistain yksittäisistä rakenteista, jotka kuitenkin ovat todellisen ohjelmoinnin kannalta ihan merkityksettömiä viilauksia ja yleensä jossain muodossa löytyvät muistakin moderneista kielistä. Mitä sellaista Eiffel tarjoaa, että sillä kannattaisi ihan oikeasti tehdä jokin iso sovellus?

Mitä olet itse ohjelmoinut ja millä kielillä, vai oletko ihan teoria- ja fiilispohjalta täällä ”mainostamassa”?

jalski kirjoitti:

Oma perustelusi tuntuu olevan pelkästään OOP

OOP on ohjelmoinnin viimeisin läpimurto ja selvin erottava tekijä matalan tason ja korkeamman tason kielten välillä. Se on tapahtunut tosiasia, josta ei vallitse paljoa erimielisyyttä. Liian laaja aihe tähän kirjoitettavaksi. Erimielisiä on aina.

Lisäys:

Metabolix kirjoitti:

Mitä sellaista Eiffel tarjoaa, että sillä kannattaisi ihan oikeasti tehdä jokin iso sovellus?

Avaukseen laitoin jotakin. Kokonaan omaa on Design by contract, joka voi olla seuraava läpimurto. Tähtäimessä ohjelman speksien mukaisuuden toteaminen kääntäjän toimesta. Lopullinen ratkaisu ei vielä ole saatavilla tavallisille ohjelmoijille soveltuvassa muodossa, mutta suureksi avuksi jo nyt.
Näillä kirjoituksilla ei ole mitään vaikutusta kielivalintoihin, mutta koko ajan tapahtuu.

vinsentti kirjoitti:

OOP on ohjelmoinnin viimeisin läpimurto ja selvin erottava tekijä matalan tason ja korkeamman tason kielten välillä. Se on tapahtunut tosiasia, josta ei vallitse paljoa erimielisyyttä. Liian laaja aihe tähän kirjoitettavaksi. Erimielisiä on aina.

Olio-ohjelmoidahan voi esim. C:llä ja assemblyllä. Ei syntaksinamut tee olio-ohjelmointia.

vinsentti kirjoitti:

Lisäys:

Kokonaan omaa on Design by contract, joka voi olla seuraava läpimurto. Tähtäimessä ohjelman speksien mukaisuuden toteaminen kääntäjän toimesta. Lopullinen ratkaisu ei vielä ole saatavilla tavallisille ohjelmoijille soveltuvassa muodossa, mutta suureksi avuksi jo nyt.
Näillä kirjoituksilla ei ole mitään vaikutusta kielivalintoihin, mutta koko ajan tapahtuu.

Eikös 'design by contract' ole jo 20 vuotta vanha juttu. Assert-makroillahan tuota sovelletaan jo muissa kielissä.

Hansen kirjoitti:

Eikös 'design by contract' ole jo 20 vuotta vanha juttu.

Taitaa olla 30 vuotta ja Meyerin oma juttu, mutta ei ole vielä lyönyt läpi. Hoaren teoria on vieläkin vanhempi.

Hansen kirjoitti:

Assert-makroillahan tuota sovelletaan jo muissa kielissä.

Kyllä, mutta sillä on vähän tekemistä speksauksen ja verifioinnin kanssa. Kääntäjä ei auta, mutta voi tehdä paljon tällaisesta:

draw (amount : INTEGER)
    require
        amount > 0
        saldo >= amount
    do
        saldo := saldo - amount
    ensure
        saldo = old saldo - amount
    end

vinsentti kirjoitti:

Meyer

Kuka tämä Meyer on?

vinsentti kirjoitti:

Hansen kirjoitti:

Assert-makroillahan tuota sovelletaan jo muissa kielissä.

Kyllä, mutta sillä on vähän tekemistä speksauksen ja verifioinnin kanssa.

Sopimuspohjaisessa ohjelmoinnissa(löysin tälläisen suomennoksen) sopimusten suunnittelu ja speksaus on todella samanlaista kaikille kielille.

C:lle ja C++:lle löytyy näköjään kaupallinen verifioija. Syntaksi löytyy monille kielille mm. Perl 6.

Käsittääkseni sopimuspohjainen ohjelmointi on jo lyönyt läpi, muttei vaikuta ohjelmointiin juurikaan eikä siten pidetä ohjelmoinnin merkittävänä kehitysaskeleena.

fergusq kirjoitti:

Kuka tämä Meyer on?

Epäilen nevöhööd-sarkasmia.

kannattaa myös tutustua Aspect orientated programming (AOP) tapaan, joka on myös erittäin käyttökelpoinen.

Mitä tulee ylläoleviin kirjoituksiin, niin PL/I, kuin eiffel,Cobol, Fortran ja muutkin ancient -kielet on vain legacysoftien ylläpitoon. Ei uusiokehitykseen.
Eli käytännössä: mitään uutta niillä ei kehitetä (ei saisi,eikä kuuluisi), ainoa järkevä käyttö on olemassaolevien mammuttisoftien ylläpito, joissa ei rahkeet ole vielä riittänyt modernisointiin.

Softa muuttuu läjäksi legacy -koodia, kun ohjelmistokehittäjiä ko. kieleen ei enää ole saatavilla markkinoilla, eikä uusia kouluteta. Ja tämä on tapahtunut ajansaatossa monille käyttökelpoisille kielille. Tämä taas tarkoittaa, että joko sovellus modernisoidaan vastaamaan nykyosaamisia tai luotetaan että erityisosaajia on jatkossakin saatavilla pienkehitykseen. Suurta kehitystä enää ei voida tehdä, kun tekijöitä ei tarpeeksi ole. Käyttökelpoisilla kielillä viittaan siis kieliin, joilla ei teknisiä rajoituksia ole "nykyaikaisiin" tekniikoihin (esim. TCP, HTTP/S, SOAP jne etc yms).

Syyt miksi softia ei modernisoida ovat monisyiset - ja syy ei ole se että ei nykyaikaisilla kielillä sitä voisi tehdä. Yksi iso syy on raha. Mammuttisoftien uudelleenkoodaus maksaa. ja paljon. Toinen syy on määrittelyiden tarve. Vanhat legacysoftat vaan pyörii, ja kukaan ei välttämättä tiedä miksi, ja miten ne toimii. Ketään ei ole enää kertomassa. Ja samat kompastuskivet jotka aikoinaan ylitettiin, tulisi uudestaan esiin. kolmas syy on luottamus, ei luoteta että uusi voisi toimia yhtä hyvin kuin vanha, onhan se tähänkin asti toiminut hyvin. Miksi sijoittaa 10 miljoonaa softan uudelleenkoodaukseen, jos se kerran vielä toimii?

Eli syy softan modernisointiin ei ole se uusi hieno ohjelmistokieli, joka nyt sattuu olemaan trendikäs. Jos sovelluksen elinkaarta pitää pidentää, pitää myös turvata sen ylläpidettävyys ja jatkokehittäminen. Itsekin olen ollut useissa projekteissa mukana, joissa taakkana painaa vanha legacykoodi, joka ei vaan taivu nykyajan määreisiin. Vai kuulostaako hyvältä esim 80-luvun alkupuolen ERP, joka vastaanottaa vain maksimipituudeltaan 255merkkisiä merkkijonoja. Ei kuulosta, kun pitäisi pystyä vastaanottamaan ketjutettuja tilauksia, joita tulee sanomina muutamien millisekuntien välein. Vaihtoehtona on joko uusi ERP, tai kuten tässä tapauksessa: annetaan tilausten kertyä viestijonoon ja toivotaan että yön hiljaisina tunteina tilausmäärät hetkellisesti tippuvat ja jono purkautuu. Toivossa on hyvä elää.

Meitä ohjelmoijia kaivaa ikuinen taakka. Vie vuosia opetella se oma "pääkieli" siihen pisteeseen, että oikeasti pärjää asiakasprojekteissa, ja työelämän haasteista. Ja kuten aina, ei haluta päästää irti siitä omasta pääosaamisesta, koska omasta mielestä se on yhä parempi kuin moni uusi kilpaileva ohjelmistokieli. Fakta kuitenkin on se, että jossain vaiheessa se meidänkin pääosaaminen jää legacykoodien ylläpitoon, ellei pysytä ajan hengessä mukana ja opetella niitä asioita jotka työelämän määreitä luo.

Hansen kirjoitti:

Olio-ohjelmoidahan voi esim. C:llä ja assemblyllä. Ei syntaksinamut tee olio-ohjelmointia.

Kyllä, mutta on tärkeää, että kääntäjä tekee mahdollisimman paljon työstä.

Hansen kirjoitti:

Sopimuspohjaisessa ohjelmoinnissa(löysin tälläisen suomennoksen) sopimusten suunnittelu ja speksaus on todella samanlaista kaikille kielille.

Mutta kielen ja kääntäjän tuki puuttuu. Se on vähän samaa kuin olio-ohjelmointi C:llä.

Lisäys:

groovyb kirjoitti:

kannattaa ...

Hyvä kirjoitus.

vinsentti kirjoitti:

Kokonaan omaa on Design by contract, joka voi olla seuraava läpimurto.

Voiko sanoa että kokonaan omaa jos parisenkymmentä kieltä tukee sitä ja lähes kaikkiin merkittäviin on olemassa lisäpalikat sille.

Olihan se oma juttu silloin kun Eiffel luotiin, mutta nykyisellään ei mielestäni merkittävä syy valita Eiffeliä uuteen projektiin.

hansen kirjoitti:

Assert-makroillahan tuota sovelletaan jo muissa kielissä.

Ilman Assert-makrojakin tuota voi soveltaa monessa ohjelmointikielessä. Esim. Mooseksen aikaisella PL/I kääntäjällä voi käyttää SELECT lausetta toimimaan halpana korvikkeena (nykypäivänä ASSERT on tuettuna).

groovyb kirjoitti:

Mitä tulee ylläoleviin kirjoituksiin, niin PL/I, kuin eiffel,Cobol, Fortran ja muutkin ancient -kielet on vain legacysoftien ylläpitoon. Ei uusiokehitykseen.
Eli käytännössä: mitään uutta niillä ei kehitetä (ei saisi,eikä kuuluisi), ainoa järkevä käyttö on olemassaolevien mammuttisoftien ylläpito, joissa ei rahkeet ole vielä riittänyt modernisointiin.

Niin Fortran kuin myös PL/I sopivat aivan hyvin uusiokehitykseen. Molemmat myös päivittyvät joka vuosi tukemaan uusia tekniikoita ja uutta rautaa.

Käytännössä jäät legacykoodeja ylläpitämään. Ei ole järkeä toteuttaa isoja projekteja kielivalinnalla, johon ei ole enää normaalia saatavuutta tekijöille. Tuotteen elinkaareen vaikuttaa olennaisesti se, jos kehittäjien määrä on jo valmiiksi laskeva.

groovyb kirjoitti:

Käyttökelpoisilla kielillä viittaan siis kieliin, joilla ei teknisiä rajoituksia ole "nykyaikaisiin" tekniikoihin (esim. TCP, HTTP/S, SOAP jne etc yms).

Tarkoittaa, että ei ongelmia kirjastojen saatavuudessa ja laadussa?
https://groups.google.com/forum/#!topic/eiffel-users/q08jL9xX_M4
Nämä ovat paitsi ongelmia, myös todisteita elävyydestä. Toisaalta saavutuksiakin on, kuten Design Patters kirjastotuki ja joissakin tapauksissa suora kielituki.

Mitä on puhdas oliopohjaisuus?
-perustyypitkin perustuvat luokkiin, BOOLEAN ym
-funktionaalinen ohjelmointi perustuu luokkiin ROUTINE, PROCEDURE ja FUNCTION
-geneerisiä voivat olla vain luokat, niiden parametrit ovat tyyppejä

Hansen kirjoitti:

Käsittääkseni sopimuspohjainen ohjelmointi on jo lyönyt läpi, muttei vaikuta ohjelmointiin juurikaan eikä siten pidetä ohjelmoinnin merkittävänä kehitysaskeleena.

Swiftiinkin on saatu avainsana guard, jonka arvellaan olevan cool.

Natasha ei huomaa elefanttia huoneessa ja jää keskustelussa sivustakatsojaksi.
https://www.natashatherobot.com/swift-guard-better-than-if/