ohjelmoinnista kiinnostunut

Toimiiko toi Visual Basic mun Ubuntussa?

on hän kirjoitti:

Toimiiko toi Visual Basic mun Ubuntussa?

Siispä aloita tästä:
http://www.ohjelmointiputka.net/opas.php?tunnus=python

on hän kirjoitti:

Toimiiko toi Visual Basic mun Ubuntussa?

Jos pitää tulla toimeen halvemmilla välineillä niin sitten varmaan pitää katella jotain enempi puuhasteluun sopivaa systeemiä.

Toisaalta kun upuntuporukka ei muista ees mainita mille näitä haetaan niin ohan se vähän sellaista opettelussa.

Miksi VB, tämän päivän COBOL... Lisäksi, sellaista kieltä, jota vain yksi firma tukee, ei KOSKAAN pidä käyttää. Varsinkaan kun kyseinen firma tekee kaikkensa interoperabilityn heikentämiseksi.

miksi vb? kirjoitti:

Miksi VB, tämän päivän COBOL... Lisäksi, sellaista kieltä, jota vain yksi firma tukee, ei KOSKAAN pidä käyttää. Varsinkaan kun kyseinen firma tekee kaikkensa interoperabilityn heikentämiseksi.

Lue lisää

Sillä voi katos tehä vaikka ohjelmia. Winukalle. Tietty jos uskoo, että toi komentorivi on ainoo oikee tapa niin pitää sit kaivaa noita ohjeita veepeenetin komentoriviin.

Ainiin mut ku pitäs saada linukkaa ja tietyn valmistajan hommat leimataan lähtökohtasesti toimimattomiks.

Minä myös olen tullut siihen käsitykseen, että Python on loistava ensimmäinen kieli ohjelmointiin tutustuttaessa. Olisipa sellainen ollut 70-luvulla! Mutta se on lopultakin nimenomaan scriptikieli, eli sitten kun se on tehnyt tehtävänsä, ja haluaisi toteuttaa vaativampia ohjelmia, python jätetään suosiolla scriptikäyttöön ja valitaan suhteellisen nopeasti toiseksi kieleksi joku muu: java, C , scala, D(?)...

Mutta kun on pythonin oppinut, niitä scripteja kannattaa edelleen tehdä! "Oikeilla kielillä" ei kannata tehdä "pikkusovelluksia" paitsi harjoitukseksi. Oikea kieli oikeaan käyttöön.

Yusa kirjoitti:

Minä myös olen tullut siihen käsitykseen, että Python on loistava ensimmäinen kieli ohjelmointiin tutustuttaessa. Olisipa sellainen ollut 70-luvulla! Mutta se on lopultakin nimenomaan scriptikieli, eli sitten kun se on tehnyt tehtävänsä, ja haluaisi toteuttaa vaativampia ohjelmia, python jätetään suosiolla scriptikäyttöön ja valitaan suhteellisen nopeasti toiseksi kieleksi joku muu: java, C , scala, D(?)...

Mutta kun on pythonin oppinut, niitä scripteja kannattaa edelleen tehdä! "Oikeilla kielillä" ei kannata tehdä "pikkusovelluksia" paitsi harjoitukseksi. Oikea kieli oikeaan käyttöön.

Lue lisää

VB.Net on molemmat, skriptikieli ja oikea kieli. Myös PHP saattaisi toimia molempina.

KN$ kirjoitti:

VB.Net on molemmat, skriptikieli ja oikea kieli. Myös PHP saattaisi toimia molempina.

Se ei kelpaa kun ei oo öypen söyrseä ja muutenkin paha kun se ei ole hyvä upuntuun.

C# taas ei kelpaa siksi kun..

Mun mielestä riippuu siitä mihin tekee ohjelmia. Jos kaveri haluu opetella tekeen ohjelmia vaikka kännyyn niin voip olla ettei mikään ehotetuista pelitä ku pitäs ollakin j2meetä tai jotain muuta.

Jepulis Jeep kirjoitti:

Se ei kelpaa kun ei oo öypen söyrseä ja muutenkin paha kun se ei ole hyvä upuntuun.

C# taas ei kelpaa siksi kun..

Mun mielestä riippuu siitä mihin tekee ohjelmia. Jos kaveri haluu opetella tekeen ohjelmia vaikka kännyyn niin voip olla ettei mikään ehotetuista pelitä ku pitäs ollakin j2meetä tai jotain muuta.

Lue lisää

Vieläkö se J# toimii?

KN$ kirjoitti:

Vieläkö se J# toimii?

JiikaksMeestä puhumattakaan.

Ootko tehnyt tolla joskus jotain? En oo ite pahemmin kuullut sitä käytetyn.

Jepulis Jeep kirjoitti:

JiikaksMeestä puhumattakaan.

Ootko tehnyt tolla joskus jotain? En oo ite pahemmin kuullut sitä käytetyn.

Ajattelin sitä VB:n korvikkeeksi mutta taitaa olla huonosti tuettu kieli.

Yusa kirjoitti:

Minä myös olen tullut siihen käsitykseen, että Python on loistava ensimmäinen kieli ohjelmointiin tutustuttaessa. Olisipa sellainen ollut 70-luvulla! Mutta se on lopultakin nimenomaan scriptikieli, eli sitten kun se on tehnyt tehtävänsä, ja haluaisi toteuttaa vaativampia ohjelmia, python jätetään suosiolla scriptikäyttöön ja valitaan suhteellisen nopeasti toiseksi kieleksi joku muu: java, C , scala, D(?)...

Mutta kun on pythonin oppinut, niitä scripteja kannattaa edelleen tehdä! "Oikeilla kielillä" ei kannata tehdä "pikkusovelluksia" paitsi harjoitukseksi. Oikea kieli oikeaan käyttöön.

Lue lisää

Oikea ja 'oikea'-kieli. On se Pythonkin aivan oikea kieli, eikä mikään lelukieli. Googlekin käyttää sitä hyvin paljon.

Mikä muuten on 'oikean'-kielen määritelmä? Käännös konekoodiksi? Jos näin, niin Java ei ole 'oikea', koska käännetään tavukoodiksi. Käännös konekoodiksi tai tavukoodiksi? No, sitten Pythonkin on 'oikea', koska se käännetään myös tavukoodiksi.

ja perustelu kirjoitti:

Oikea ja 'oikea'-kieli. On se Pythonkin aivan oikea kieli, eikä mikään lelukieli. Googlekin käyttää sitä hyvin paljon.

Mikä muuten on 'oikean'-kielen määritelmä? Käännös konekoodiksi? Jos näin, niin Java ei ole 'oikea', koska käännetään tavukoodiksi. Käännös konekoodiksi tai tavukoodiksi? No, sitten Pythonkin on 'oikea', koska se käännetään myös tavukoodiksi.

Lue lisää

Ohan täälläkin näitä kavereita joiden mielestä .net ja java ovat ikäviä systeemejä kun softat ajetaan välikielellä eikä niitä saa käännettyä pinääreiksi.

Seuraavaksi muistutetaan kuinka hyvä pyyttoni on.

Oikeestaan kielen valinnassa kantsis kysyä ihan ensin sitä, onko vahva tyypitys kooderin mielestä tärkeä vai jopa haitallinen asia. Vai onkos siitä mitään hyötyä. Tohon kun saa vastauksen niin homma alkaa olla pulkassa.

Jepulis Jeep kirjoitti:

Ohan täälläkin näitä kavereita joiden mielestä .net ja java ovat ikäviä systeemejä kun softat ajetaan välikielellä eikä niitä saa käännettyä pinääreiksi.

Seuraavaksi muistutetaan kuinka hyvä pyyttoni on.

Oikeestaan kielen valinnassa kantsis kysyä ihan ensin sitä, onko vahva tyypitys kooderin mielestä tärkeä vai jopa haitallinen asia. Vai onkos siitä mitään hyötyä. Tohon kun saa vastauksen niin homma alkaa olla pulkassa.

Lue lisää

"Oikeestaan kielen valinnassa kantsis kysyä ihan ensin sitä, onko vahva tyypitys kooderin mielestä tärkeä vai jopa haitallinen asia. Vai onkos siitä mitään hyötyä. Tohon kun saa vastauksen niin homma alkaa olla pulkassa."

Vahva tyypitys on melkein kaikissa kielissä joten ei paljon auta. esim. python, vb.net
http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Type_systems

Nopulis Noop kirjoitti:

"Oikeestaan kielen valinnassa kantsis kysyä ihan ensin sitä, onko vahva tyypitys kooderin mielestä tärkeä vai jopa haitallinen asia. Vai onkos siitä mitään hyötyä. Tohon kun saa vastauksen niin homma alkaa olla pulkassa."

Vahva tyypitys on melkein kaikissa kielissä joten ei paljon auta. esim. python, vb.net
http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Type_systems

Lue lisää

Ohan sekin hyvä tieto jos kaveri aattelee vaikka c#:n ja pyyttonin tyypitysten olevan sama asia. Osaa sitten opastaa oikeen.

Tää on oikeestaan se kolmas vaihtoehto sitten.

Jepulis Jeep kirjoitti:

Ohan sekin hyvä tieto jos kaveri aattelee vaikka c#:n ja pyyttonin tyypitysten olevan sama asia. Osaa sitten opastaa oikeen.

Tää on oikeestaan se kolmas vaihtoehto sitten.

Lue lisää

Nyt tekstisikin on niin sekavaa, etten ymmärtänyt lainkaan mitä yritit sanoa. Mutta ei se mitään...

Nopulis Noop kirjoitti:

Nyt tekstisikin on niin sekavaa, etten ymmärtänyt lainkaan mitä yritit sanoa. Mutta ei se mitään...

Ei kato kannata vastata jos asia pitää vääntää rautalangasta.

Jepulis Jeep kirjoitti:

Ei kato kannata vastata jos asia pitää vääntää rautalangasta.

Et sitten keksinyt parempaa hätävaletta? Ja älä ihmeessä vastaa, ethän?

ja perustelu kirjoitti:

Oikea ja 'oikea'-kieli. On se Pythonkin aivan oikea kieli, eikä mikään lelukieli. Googlekin käyttää sitä hyvin paljon.

Mikä muuten on 'oikean'-kielen määritelmä? Käännös konekoodiksi? Jos näin, niin Java ei ole 'oikea', koska käännetään tavukoodiksi. Käännös konekoodiksi tai tavukoodiksi? No, sitten Pythonkin on 'oikea', koska se käännetään myös tavukoodiksi.

Lue lisää

Skriptikielet, kuten Python ja Perl, ovat kaukana lelukielistä, mutta niitä ei ole todellakaan tarkoitettu isojen, kompleksisten sovellusten tekemiseen. Skriptien sujuva luominen lennosta aina tarpeen mukaan on ammattilaisen toimintaa ja skriptikielet ovat ammattilaisen työkaluja.

Mutta "oikeita kieliä" ovat kielet, jotka todella tukevat isojen, monimutkaisten, useiden kehittäjien yhdessä luomien sovellusten tekemistä. Skriptin tekee tyypillisesti yksi kehittäjä alusta loppuun tai vanhaa skriptiä uudelleen soveltamalla. Työmäärä vaihtelee minuteista työpäiviin. Isot sovellukset kuluttavat useita miestyövuosia. Niitä ei yksinkertaisesti pysty toteuttamaan skriptikielillä. Java on oikea kieli. Nykyään sillä ei ole väliä, käyttääkö kieli bytekoodia vai ei.

Yusa kirjoitti:

Skriptikielet, kuten Python ja Perl, ovat kaukana lelukielistä, mutta niitä ei ole todellakaan tarkoitettu isojen, kompleksisten sovellusten tekemiseen. Skriptien sujuva luominen lennosta aina tarpeen mukaan on ammattilaisen toimintaa ja skriptikielet ovat ammattilaisen työkaluja.

Mutta "oikeita kieliä" ovat kielet, jotka todella tukevat isojen, monimutkaisten, useiden kehittäjien yhdessä luomien sovellusten tekemistä. Skriptin tekee tyypillisesti yksi kehittäjä alusta loppuun tai vanhaa skriptiä uudelleen soveltamalla. Työmäärä vaihtelee minuteista työpäiviin. Isot sovellukset kuluttavat useita miestyövuosia. Niitä ei yksinkertaisesti pysty toteuttamaan skriptikielillä. Java on oikea kieli. Nykyään sillä ei ole väliä, käyttääkö kieli bytekoodia vai ei.

Lue lisää

Millä nyt lelukielen määrittelee. Toi sun ryhmittely sellasiin joilla voi tehä isoja hommia ja millä pieniä, on aika hyvä. Javaa, PisteNettiä tai vaikka jotain muuta isomman systeemin mahollistvaa käyttää semmoseen mielellään ja pikkuhommiin sitten noita joilla ei suuria pahemmin kannata lähteä tekeen.

Näiden opettelijoiden pitäs ehkä miettiä sitäkin, meinaavatko tehä lähinnä pikkusoftia vai onko tarkotus olla vaikka töissä ja tehä jotain suurempaakin systeemiä.

Oon kuullut väitteen siitä, että suuria systeemeitä alettaisiin vaatimaan entistä enemmän sellaisiksi, että toteutus pitää ajaa välikielellä. Ei mikään hassumpi ajatus jos tarkotuksena on ylläpitää välikieliympäristöä tietyn raudan sijaan. Vaikka olihan siinä muutakin ideaa kuten hiekkalaatikkoturva, sakkaukset ja standardifreimwörkit tms.

Toi Rupiini kiinnistais kuulla vieläkin, jonkun developerin suusta, mutta ei vaan tule mistään juttua vaikka ei se kuollut ole kuitenkaan. Tuskin niitä kaikkia sentään on täysin vaiennettu?

Jepulis Jeep kirjoitti:

Millä nyt lelukielen määrittelee. Toi sun ryhmittely sellasiin joilla voi tehä isoja hommia ja millä pieniä, on aika hyvä. Javaa, PisteNettiä tai vaikka jotain muuta isomman systeemin mahollistvaa käyttää semmoseen mielellään ja pikkuhommiin sitten noita joilla ei suuria pahemmin kannata lähteä tekeen.

Näiden opettelijoiden pitäs ehkä miettiä sitäkin, meinaavatko tehä lähinnä pikkusoftia vai onko tarkotus olla vaikka töissä ja tehä jotain suurempaakin systeemiä.

Oon kuullut väitteen siitä, että suuria systeemeitä alettaisiin vaatimaan entistä enemmän sellaisiksi, että toteutus pitää ajaa välikielellä. Ei mikään hassumpi ajatus jos tarkotuksena on ylläpitää välikieliympäristöä tietyn raudan sijaan. Vaikka olihan siinä muutakin ideaa kuten hiekkalaatikkoturva, sakkaukset ja standardifreimwörkit tms.

Toi Rupiini kiinnistais kuulla vieläkin, jonkun developerin suusta, mutta ei vaan tule mistään juttua vaikka ei se kuollut ole kuitenkaan. Tuskin niitä kaikkia sentään on täysin vaiennettu?

Lue lisää

Voi tietysti spekuloida, että kaikki ohjelmointikielet ovat vaan työkaluja jonkun oikean homman toteuttamiseen. On olemassa lapiofriikkejä sekä tyyppejä, jotka tekevät niillä lapiolla jotain oikeatakin. Mutta jos haluaisi verrata ohjelmointikieliä erilaisiin lapioihin, niin voisi yritellä vaikka jotain tämänkaltaista: C-kieli: Vanha rautakärkinen lapio puuvarrella - pätevä työkalu, sillä voi tehdä mitä tahansa, mutta raskas käyttää. C -kieli: Hieman modernimpi järeä lapio - kaivuu sujuu nopeammin, mutta saattaa hajota käsiinkin joskus. Java-kieli: Kevytmetallilapio puuvarrella - varsin kestävä, mutta ei sillä mitään soraa kyllä pikään lapioida. Perl: Vanha rautakärkinen puutarhalapio - pienet kolot onistuu tuosta vaan, mutta isompien kuoppien kaivaminen on työlästä ellei mahdotonta. Python: Taskuun taitettava metallinen pikkulapio - kätevä pitää mukana ja tehdä nopeita pikkuhommia, mutta ei sillä mitään kaivosta kaiveta. Visual Basic: Muovinen hiekkalapio - hyvä tapa oppia tekemään kuoppia hiekkalaatikolla, mutta muiden töiden tekeminen voi olla hieman ongelmallista. Mutta jätän vielä muillekin mahdollisuuden keksiä ja kritisoida näitä vertauksia...

K=PH'/S kirjoitti:

Voi tietysti spekuloida, että kaikki ohjelmointikielet ovat vaan työkaluja jonkun oikean homman toteuttamiseen. On olemassa lapiofriikkejä sekä tyyppejä, jotka tekevät niillä lapiolla jotain oikeatakin. Mutta jos haluaisi verrata ohjelmointikieliä erilaisiin lapioihin, niin voisi yritellä vaikka jotain tämänkaltaista: C-kieli: Vanha rautakärkinen lapio puuvarrella - pätevä työkalu, sillä voi tehdä mitä tahansa, mutta raskas käyttää. C -kieli: Hieman modernimpi järeä lapio - kaivuu sujuu nopeammin, mutta saattaa hajota käsiinkin joskus. Java-kieli: Kevytmetallilapio puuvarrella - varsin kestävä, mutta ei sillä mitään soraa kyllä pikään lapioida. Perl: Vanha rautakärkinen puutarhalapio - pienet kolot onistuu tuosta vaan, mutta isompien kuoppien kaivaminen on työlästä ellei mahdotonta. Python: Taskuun taitettava metallinen pikkulapio - kätevä pitää mukana ja tehdä nopeita pikkuhommia, mutta ei sillä mitään kaivosta kaiveta. Visual Basic: Muovinen hiekkalapio - hyvä tapa oppia tekemään kuoppia hiekkalaatikolla, mutta muiden töiden tekeminen voi olla hieman ongelmallista. Mutta jätän vielä muillekin mahdollisuuden keksiä ja kritisoida näitä vertauksia...

Lue lisää

Tosta pisti silmään semmonen, ettei sun mielestäs oo olemassa, ainakaan tossa listassa, kunnollisia lapioita joilla vois tehä oikeesti hommia ellei tota seetä lasketa. Toisaalta taas ei se maailma oo noin yksoikonen. c lla voi tehä hommia joko ihan kelvollisella tasolla tai sitten järjettömän vaikeesti kuten eräissä ympäristöissä joissa hello world tarvii satakunta riviä koodia. Visual pasikki. No taidat niputtaa kutosen ja uudemmat ympäristöt samaan lapioon joten tota analyysiä ei varmaan tartte sen kummemmin käsitellä. C# taas ei oo tossa listalla mutta kun se on 99% samaa kun uus veepee niin kait sekin on muovinen hiekkalapio mutta vähän terävämmällä kovikemuovisella kärjellä. Heh hee...

Yusa kirjoitti:

Skriptikielet, kuten Python ja Perl, ovat kaukana lelukielistä, mutta niitä ei ole todellakaan tarkoitettu isojen, kompleksisten sovellusten tekemiseen. Skriptien sujuva luominen lennosta aina tarpeen mukaan on ammattilaisen toimintaa ja skriptikielet ovat ammattilaisen työkaluja.

Mutta "oikeita kieliä" ovat kielet, jotka todella tukevat isojen, monimutkaisten, useiden kehittäjien yhdessä luomien sovellusten tekemistä. Skriptin tekee tyypillisesti yksi kehittäjä alusta loppuun tai vanhaa skriptiä uudelleen soveltamalla. Työmäärä vaihtelee minuteista työpäiviin. Isot sovellukset kuluttavat useita miestyövuosia. Niitä ei yksinkertaisesti pysty toteuttamaan skriptikielillä. Java on oikea kieli. Nykyään sillä ei ole väliä, käyttääkö kieli bytekoodia vai ei.

Lue lisää

> Python ja Perl, ovat kaukana lelukielistä, mutta > niitä ei ole todellakaan tarkoitettu isojen, > kompleksisten sovellusten tekemiseen. Perlin suhteen en ota kantaa, mutta en väheksyisi Pythonin soveltuvuutta suurempiinkin projekteihin. > Isot sovellukset kuluttavat useita miestyövuosia. Olen ollut itsekin tekemässä tällaisia Pythonilla, eivätkä ne ole lähelläkään oikeasti isoja Python-softia. Esimerkiksi täällä: http://www.python.org/about/success/nexedi/ esitetään Pythonilla rakennettu ERP. Linkin mukaan tyypillinen toimitettava ERP-järjestelmä sisältää noin 100k riviä koodia, kun taas tavanomaisin ohjelmointitekniikoin vastaava järjestelmä olisi helposti 1M riviä. Merkittävästi pienempi koko perustuu koodin generointiin, mikä on dynaamisissa kielissä täysin luonnollista.

TRRY kirjoitti:

> Python ja Perl, ovat kaukana lelukielistä, mutta > niitä ei ole todellakaan tarkoitettu isojen, > kompleksisten sovellusten tekemiseen. Perlin suhteen en ota kantaa, mutta en väheksyisi Pythonin soveltuvuutta suurempiinkin projekteihin. > Isot sovellukset kuluttavat useita miestyövuosia. Olen ollut itsekin tekemässä tällaisia Pythonilla, eivätkä ne ole lähelläkään oikeasti isoja Python-softia. Esimerkiksi täällä: http://www.python.org/about/success/nexedi/ esitetään Pythonilla rakennettu ERP. Linkin mukaan tyypillinen toimitettava ERP-järjestelmä sisältää noin 100k riviä koodia, kun taas tavanomaisin ohjelmointitekniikoin vastaava järjestelmä olisi helposti 1M riviä. Merkittävästi pienempi koko perustuu koodin generointiin, mikä on dynaamisissa kielissä täysin luonnollista.

Lue lisää

Generaatio tarkoittaa ilmeisesti tätä (Ruby): def kolmeKertaa    yield    yield    yield end kolmeKertaa do    print "Heippa" end Tulostus: HeippaHeippaHeippa Näppärän näköistä, mutta mitä hyötyä tästä voisi sitten olla...? No joo, joskus kannattaa tehdä asioita vain kokeillakseen ja testatakseen itseään. Voi olla ihan tervettä sinänsä. Mutta miten tätä voisi käyttää isossa sovelluksessa?

TRRY kirjoitti:

> Python ja Perl, ovat kaukana lelukielistä, mutta > niitä ei ole todellakaan tarkoitettu isojen, > kompleksisten sovellusten tekemiseen. Perlin suhteen en ota kantaa, mutta en väheksyisi Pythonin soveltuvuutta suurempiinkin projekteihin. > Isot sovellukset kuluttavat useita miestyövuosia. Olen ollut itsekin tekemässä tällaisia Pythonilla, eivätkä ne ole lähelläkään oikeasti isoja Python-softia. Esimerkiksi täällä: http://www.python.org/about/success/nexedi/ esitetään Pythonilla rakennettu ERP. Linkin mukaan tyypillinen toimitettava ERP-järjestelmä sisältää noin 100k riviä koodia, kun taas tavanomaisin ohjelmointitekniikoin vastaava järjestelmä olisi helposti 1M riviä. Merkittävästi pienempi koko perustuu koodin generointiin, mikä on dynaamisissa kielissä täysin luonnollista.

Lue lisää

Mielenkiintoista. Onhan Python toki ainakin lähes täysiverinen oliokieli, jolla on vahvoja funkionaalista ohjelmointia tukevia piirteitä. Eli pakko kai se on uskoa. "Merkittävästi pienempi koko perustuu koodin generointiin, mikä on dynaamisissa kielissä täysin luonnollista" Mutta tästä voisit kertoa hieman lisää.

Yusa kirjoitti:

Mielenkiintoista. Onhan Python toki ainakin lähes täysiverinen oliokieli, jolla on vahvoja funkionaalista ohjelmointia tukevia piirteitä. Eli pakko kai se on uskoa. "Merkittävästi pienempi koko perustuu koodin generointiin, mikä on dynaamisissa kielissä täysin luonnollista" Mutta tästä voisit kertoa hieman lisää.

Lue lisää

Oon ihmetellyt paljonkin noita ajonaikana muokattavia kieliä ja itteään uudestaan koodaavia ohjelmia. Ei ole oikein koskaan auennut ne mahtavat edut jota noista on. Enemmän tulee mieleen ongelmia ja mahollisia aukkoja. Jotka on varmaan mietitty umpeen toteutuksissa, ohan varmaan? Koodin generointia. Siitä kuulis mielellään lisää. Nyt se on jäänyt enemmän visionäärien tasolle. Oli sillä kai joku erittäin päteväkin syy, että aikanaan erotettiin koodi ja data toisistaan.

Yusa kirjoitti:

Mielenkiintoista. Onhan Python toki ainakin lähes täysiverinen oliokieli, jolla on vahvoja funkionaalista ohjelmointia tukevia piirteitä. Eli pakko kai se on uskoa. "Merkittävästi pienempi koko perustuu koodin generointiin, mikä on dynaamisissa kielissä täysin luonnollista" Mutta tästä voisit kertoa hieman lisää.

Lue lisää

Koodin generoinnissa ajatuksena on tuottaa ajettavaa ohjelmakoodia. Sitä sanotaan myös metaohjelmoinniksi: kirjoitetaan ohjelma, jonka ajamisen seurauksena on saadaan toinen ohjelma. Koodin generoinnissa ei siis sinällään ole mitään mikä pakottaisi käyttämään dynaamisia ohjelmointikieliä. Generoitava koodi voi olla ihan yhtä hyvin C:tä tai C :aa kuin Pythonia. Mutta monien dynaamisten ohjelmointikielten kanssa koodin generointi on koko ajan aivan käden ulottuvilla. Generoidun koodin saa käyttöön vaikka heti osaksi ohjelmaa, joka on sen itse generoinut. Erillistä käännösvaihetta ei luonnollisesti tarvita. --- Esimerkki 1: lausekkeen evaluointi --- Yksinkertaisimmillaan voisin antaa esimerkin laskimesta. Seuraava Python-ohjelma laskee sulutettuja yhteen-, vähennys-, kerto- ja jakolaskuja. import re lauseke = raw_input("Anna lauseke: ") if not re.match(r'[()- */ 0123456789]*$', lauseke): print "lausekkeessa on kiellettyja merkkeja" else: try: vastaus = eval(lauseke) print "tulos on:", vastaus except: print "virheellinen lauseke" Ohjelma pyytää käyttäjää antamaan lausekkeen. Jos lauseke (merkkijono) ei sisällä mitään epäilyttäviä merkkejä, sitä pidetään Python-koodina ja se koitetaan suorittaa (eval). Jos evaluointi onnistui, eli poikkeusta ei tullut, tulos esitetään käyttäjälle. Suuremmassa mittakaavassa tätä voi soveltaa esimerkiksi siten, että annetaan käyttäjien upottaa Python-koodia ohjelman syötteisiin (tiedostoihin, tietokantaan, jne.) ja evaluoidaan se sitten sopivassa kohdassa ajoaikana. eval-funktion parametreiksi voi antaa mm. erilliset nimiavaruudet, jotka sisältävät evaluoitavissa lausekkeissa mahdollisesti esiintyvät muuttujat arvoineen. --- Esimerkki 2: jäsennys --- Aavistuksen monimutkaisemman esimerkin voisin ottaa jäsennyksen puolelta. Jos syötteen muoto on sopiva, tavanomaisen jäsentäjän tekemisen sijaan voi olla kätevämpää muuttaa syöte Python-koodiksi ja suorittaa se. Jos syöte on esimerkiksi Trek Wars faneja ärsyttävä death star kirk 12 * 10**6 niin sen voisi muuttaa Python-ohjelmaksi ja antaa siten tulkin jäsennettäväksi esimerkiksi seuraavalla ohjelmalla: import sys import re def out(s): sys.stdout.write(s '\n') # muunnetaan syote Python-koodiksi s = sys.stdin.read() s = re.sub(r'', r'\1("', s) s = re.sub(r'', r'")', s) # maaritellaan koodin suoritusympariston funktiot def ship(name): out('laivan nimi: ' name) def captain(name): out('kapteeni: ' name) def speed(expr): out('nopeus: ' str(eval(expr))) # suoritetaan koodi exec(s) Yllä oleva ohjelma muuntaa ensin säännöllisten lausekkeiden avulla edellä annetun syötteen muoton ship("death star") captain("kirk") speed("12 * 10**6") Seuraavaksi ohjelmassa määritellään ship-, captain- ja speed-funktiot joita Python-tulkki sitten kutsuu, kun se lopulta suorittaa Python-lauseet rivillä exec(s). --- Esimerkki 3: toiston vähentäminen --- Lopuksi vielä todellinen esimerkin muutama päivä sitten käyttämästäni koodin generoinnista. Ilman koodin generointia olisin joutunut määrittelemään eräälle Python-luokalle metodit __add__, __sub__, __mul__, ... kaikki siten, että ne tulostavat että niitä on kutsuttu. Tämän jälkeen ne laskevat vastaavan yhteen-, vähennys-, kerto- jne. laskun ja raportoivat lopulta poikkeuksen tai laskun lopputuloksen. Tämä olisi vaatinut vähintään kahdeksan riviä per metodi, joita on paljon (vertailuoperaattorit ja r-versiot laskuoperaattoreista mukaan lukien). Koodin generoinnin avulla nämä kaikki metodit oli määriteltävissä yhdellä noin 15 rivin funktiolla, joka palauttaa merkkijonona metodin koodin ja sitten yhdellä rivillä per metodi. Esimerkiksi exec(annakoodi('__add__', ' ')) exec(annakoodi('__sub__', '-')) exec(annakoodi('__le__', '

KN$ kirjoitti:

Generaatio tarkoittaa ilmeisesti tätä (Ruby): def kolmeKertaa    yield    yield    yield end kolmeKertaa do    print "Heippa" end Tulostus: HeippaHeippaHeippa Näppärän näköistä, mutta mitä hyötyä tästä voisi sitten olla...? No joo, joskus kannattaa tehdä asioita vain kokeillakseen ja testatakseen itseään. Voi olla ihan tervettä sinänsä. Mutta miten tätä voisi käyttää isossa sovelluksessa?

Lue lisää

Tuon Ruby esimerkin tarkoitus on *opettaa alkeita* yieldin käyttöön. Se on siis helloworld-tasoa eikä ole ns. järkevä. "Mutta miten tätä voisi käyttää isossa sovelluksessa?" Metaohjelmointihan tarkoittaa koodin generointia samaan koodiin tai toiseen koodiin. Tällöin esim. kääntäjä tekee juuri sitä (high-level-kieli => konekoodi, tavukoodi) tai IDE tekee sitä (tiputa bushButton formii => koodia generoituu tiedostoihin) tai makrot tekee sitä (saman kielen sisällä), jne... Parempi olisi kysyä mikä iso sovellus EI käytä lainkaan metaohjelmointia? (Ja erityisesti, mikä iso ruby-softa ei käytä yieldiä muuta metaa-kamaa?) Ja jos ei halua edes epäsuorasti hyötyä meta-jutuista, niin sitten pitää koodata suoraan konekoodia ('Olen meta-änkyrä, en halua käyttää kääntäjää'). ps. C#:ssa on myös yield

ööö.... kirjoitti:

Tuon Ruby esimerkin tarkoitus on *opettaa alkeita* yieldin käyttöön. Se on siis helloworld-tasoa eikä ole ns. järkevä. "Mutta miten tätä voisi käyttää isossa sovelluksessa?" Metaohjelmointihan tarkoittaa koodin generointia samaan koodiin tai toiseen koodiin. Tällöin esim. kääntäjä tekee juuri sitä (high-level-kieli => konekoodi, tavukoodi) tai IDE tekee sitä (tiputa bushButton formii => koodia generoituu tiedostoihin) tai makrot tekee sitä (saman kielen sisällä), jne... Parempi olisi kysyä mikä iso sovellus EI käytä lainkaan metaohjelmointia? (Ja erityisesti, mikä iso ruby-softa ei käytä yieldiä muuta metaa-kamaa?) Ja jos ei halua edes epäsuorasti hyötyä meta-jutuista, niin sitten pitää koodata suoraan konekoodia ('Olen meta-änkyrä, en halua käyttää kääntäjää'). ps. C#:ssa on myös yield

Lue lisää

Onhan funktioiden määritteleminenkin metaohjelmointia: function heippa() { print"Heippa"; } heippa();heippa();heippa(); Kyse on vaan siitä mikä on tapa on hallittavin. Skripti-kielissä on monia toimintoja joilla koodia leikataan ja liimataan koodia vähän liiankin vapaasti.

KN$ kirjoitti:

Onhan funktioiden määritteleminenkin metaohjelmointia: function heippa() { print"Heippa"; } heippa();heippa();heippa(); Kyse on vaan siitä mikä on tapa on hallittavin. Skripti-kielissä on monia toimintoja joilla koodia leikataan ja liimataan koodia vähän liiankin vapaasti.

Lue lisää

Onhan funktioiden määritteleminenkin metaohjelmointia: function heippa() { print"Heippa"; } heippa();heippa();heippa(); Kyse on vaan siitä mikä tapa on hallittavin. Skripti-kielissä on monia toimintoja joilla koodia leikataan ja liimataan vähän liiankin vapaasti.

KN$ kirjoitti:

Onhan funktioiden määritteleminenkin metaohjelmointia: function heippa() { print"Heippa"; } heippa();heippa();heippa(); Kyse on vaan siitä mikä on tapa on hallittavin. Skripti-kielissä on monia toimintoja joilla koodia leikataan ja liimataan koodia vähän liiankin vapaasti.

Lue lisää

Sorry, kirjoitin epäselvästi, näin hieman paremmin: Metaohjelmointihan tarkoittaa *ohjelmaa* joka generoi koodia samaan koodiin tai toiseen koodiin (esim. tiedostoon). Joten esimerkkisi *ei ole* metaa, koska se *itse* ei ajettuna tuota mitään koodia (kääntäjä toki tuottaa). Äärisimppeli esimerkki: print "int main() \n{\n\treturn 0;\n}\n" On siis Python-ohjelma joka ajettuna generoi C-kielisen ohjelmakoodin stdoutiin. Asiaan ehkä kannattaisi tutustua ennen kuin kirjoittaa 'varmoja mielipiteitä', vaikkapa tuosta: http://en.wikipedia.org/wiki/Metaprogramming

ööö.... kirjoitti:

Sorry, kirjoitin epäselvästi, näin hieman paremmin: Metaohjelmointihan tarkoittaa *ohjelmaa* joka generoi koodia samaan koodiin tai toiseen koodiin (esim. tiedostoon). Joten esimerkkisi *ei ole* metaa, koska se *itse* ei ajettuna tuota mitään koodia (kääntäjä toki tuottaa). Äärisimppeli esimerkki: print "int main() \n{\n\treturn 0;\n}\n" On siis Python-ohjelma joka ajettuna generoi C-kielisen ohjelmakoodin stdoutiin. Asiaan ehkä kannattaisi tutustua ennen kuin kirjoittaa 'varmoja mielipiteitä', vaikkapa tuosta: http://en.wikipedia.org/wiki/Metaprogramming

Lue lisää

"Metaohjelmointihan tarkoittaa *ohjelmaa* joka generoi koodia samaan koodiin tai toiseen koodiin (esim. tiedostoon). " Ohjelmoija sen koodin vielä tuottaa, suurimmaksi osaksi.

KN$ kirjoitti:

"Metaohjelmointihan tarkoittaa *ohjelmaa* joka generoi koodia samaan koodiin tai toiseen koodiin (esim. tiedostoon). " Ohjelmoija sen koodin vielä tuottaa, suurimmaksi osaksi.

Lue lisää

"Ohjelmoija sen koodin vielä tuottaa, suurimmaksi osaksi." Hmm... tuota noin mietitäänpä .... Kääntäjät (joka ovat tietysti ohjelmia) tuottavat käytännössä kaiken konekoodi ja tavukoodin. Jos verrataan ihmisten tuottamaa koodimäärää tavuina vs. kääntäjien tuottamaa, niin taitaa viedä kääntäjät voiton. Vertaa vaikka oman koodisi kokoa käännetyn koodin kokoon. Saattaa tuntua hölmöltä vertaukselta, mutta muista että aikoinaan (40-50-luvuilla) konekoodi tehtiin kokonaan manuaalisesti. (Ja jossain Lisp-ohjelmassa voi olla makrokoodia, joka tuottaa enemmän täysin normaalia Lisp-koodia kuin se ihmisen tekemä osa. (Makrot ovat normaali käytäntö Lispissä))

ööö.... kirjoitti:

"Ohjelmoija sen koodin vielä tuottaa, suurimmaksi osaksi." Hmm... tuota noin mietitäänpä .... Kääntäjät (joka ovat tietysti ohjelmia) tuottavat käytännössä kaiken konekoodi ja tavukoodin. Jos verrataan ihmisten tuottamaa koodimäärää tavuina vs. kääntäjien tuottamaa, niin taitaa viedä kääntäjät voiton. Vertaa vaikka oman koodisi kokoa käännetyn koodin kokoon. Saattaa tuntua hölmöltä vertaukselta, mutta muista että aikoinaan (40-50-luvuilla) konekoodi tehtiin kokonaan manuaalisesti. (Ja jossain Lisp-ohjelmassa voi olla makrokoodia, joka tuottaa enemmän täysin normaalia Lisp-koodia kuin se ihmisen tekemä osa. (Makrot ovat normaali käytäntö Lispissä))

Lue lisää

"taitaa viedä kääntäjät voiton" Hyvin mahdollista. Koodin tuottaminen on kumminkin sen verran limittynyt koneen ja ihmisen kesken ettei missään kielissä ole mitään yksittäisiä temppuja koodin generoimiseen. Olisivat ne ehtineet yleistyä.

KN$ kirjoitti:

"taitaa viedä kääntäjät voiton" Hyvin mahdollista. Koodin tuottaminen on kumminkin sen verran limittynyt koneen ja ihmisen kesken ettei missään kielissä ole mitään yksittäisiä temppuja koodin generoimiseen. Olisivat ne ehtineet yleistyä.

Lue lisää

"... ettei missään kielissä ole mitään yksittäisiä temppuja koodin generoimiseen." Väärin. Jos kielen esitysmuoto on samaisen kielen primitiivi tietorakenne, niin se on ideaalinen metaohjelmointiin ja tämä temppuilu on mahdollista vain muutamassa kielessä: http://en.wikipedia.org/wiki/Homoiconicity (homoiconicity ~ sama esitysmuotoisuus) "Olisivat ne ehtineet yleistyä." Monesti jätetään metaominaisuuksia (esim. makrot) tarkoituksella pois, koska ne on katsotaan liian vaarallisiksi tai vaikeiksi tai jotain.

ööö.... kirjoitti:

"... ettei missään kielissä ole mitään yksittäisiä temppuja koodin generoimiseen." Väärin. Jos kielen esitysmuoto on samaisen kielen primitiivi tietorakenne, niin se on ideaalinen metaohjelmointiin ja tämä temppuilu on mahdollista vain muutamassa kielessä: http://en.wikipedia.org/wiki/Homoiconicity (homoiconicity ~ sama esitysmuotoisuus) "Olisivat ne ehtineet yleistyä." Monesti jätetään metaominaisuuksia (esim. makrot) tarkoituksella pois, koska ne on katsotaan liian vaarallisiksi tai vaikeiksi tai jotain.

Lue lisää

Joku vois tietysti sanoa, että kun kirjotan c:llä koodia niin kääntäjä tekee pahuksen paljon koodia kun se veivaa printf:n konekoodiks. Oon mä nähnyt kanssa skriptitulkin joka ajo c:tä. Ihan skriptinä. Tekikös se siitä sitten jotenkin skriptikielen ja generoitavan semmosen? Mutta tässä on nyt semmonen homma, että on vähän vaikeeta ymmärtää miks toi skriptin tai vastaavan generointi ois joku erikoinen sampo sinänsä, että samaa hommaa ei vois tehä koodissa muuten. Olioilla tekee kaikkea kivaa jos haluaa lähteä c:stä eteenpäin. Toisaalta tommosten skriptisysteemien avaamat tietoturvariskit kuulostaa melkosilta.

ööö.... kirjoitti:

"... ettei missään kielissä ole mitään yksittäisiä temppuja koodin generoimiseen." Väärin. Jos kielen esitysmuoto on samaisen kielen primitiivi tietorakenne, niin se on ideaalinen metaohjelmointiin ja tämä temppuilu on mahdollista vain muutamassa kielessä: http://en.wikipedia.org/wiki/Homoiconicity (homoiconicity ~ sama esitysmuotoisuus) "Olisivat ne ehtineet yleistyä." Monesti jätetään metaominaisuuksia (esim. makrot) tarkoituksella pois, koska ne on katsotaan liian vaarallisiksi tai vaikeiksi tai jotain.

Lue lisää

http://en.wikipedia.org/wiki/Homoiconicity En ole kuullut tuosta. Siis vähän kuin DOM jolla muokataan HTML-dokumttia? Mutta ei tääkään ominaisuus itsestään generoi sitä järkevää koodia. Jos generoittis niin olis 1960-luvulta asti ollut käytössä.

KN$ kirjoitti:

http://en.wikipedia.org/wiki/Homoiconicity En ole kuullut tuosta. Siis vähän kuin DOM jolla muokataan HTML-dokumttia? Mutta ei tääkään ominaisuus itsestään generoi sitä järkevää koodia. Jos generoittis niin olis 1960-luvulta asti ollut käytössä.

Lue lisää

80-luvulla, kun Atari-ST:n kanssa harjoittelin Logon ja XLISP:n kanssa, tällainen "itseään muuttava koodi" nousi aina välillä esiin, mutta se vaaroista varoitettiin. Ilmeisesti sen järkevä käyttö ei onnistu "tuosta vaan". Se tarvitsisi vahvan metodologisen perustan, uuden paradigman, joka ei ainaakaan kovin julkiseksi ole päässyt, tai kukaan ei ole sellaista edes vielä kehittänytkään. Mutta sillä olisi kovasti käyttöä semanttisen teknologia alueella: miten semanttisesta input-datasta tuotetaan uutta proseduraalista tietämystä, joka on sitten suoraan suoritettavissa... hieno juttu. Pitää yrittää kaivella lisää tietoa, kiitos vihjeistä.

ööö.... kirjoitti:

"... ettei missään kielissä ole mitään yksittäisiä temppuja koodin generoimiseen." Väärin. Jos kielen esitysmuoto on samaisen kielen primitiivi tietorakenne, niin se on ideaalinen metaohjelmointiin ja tämä temppuilu on mahdollista vain muutamassa kielessä: http://en.wikipedia.org/wiki/Homoiconicity (homoiconicity ~ sama esitysmuotoisuus) "Olisivat ne ehtineet yleistyä." Monesti jätetään metaominaisuuksia (esim. makrot) tarkoituksella pois, koska ne on katsotaan liian vaarallisiksi tai vaikeiksi tai jotain.

Lue lisää

> tämä temppuilu on mahdollista vain muutamassa kielessä Mitä ihmettä. Wikipedian sivultahan puuttuvat tavallisista kielistä Python, Javascript ja Ruby. Kaikissa niissä kielen esitysmuoto on kielen primitiivitietotyyppi (merkkijono). > > "Olisivat ne ehtineet yleistyä." Silmät auki! Tioben Top-11:ta on ryöminyt muutaman vuoden sisällä edellä mainitsemani kolme dynaamista kieltä. Kyllä ne todellakin yleistyvät.

TRRY kirjoitti:

> tämä temppuilu on mahdollista vain muutamassa kielessä Mitä ihmettä. Wikipedian sivultahan puuttuvat tavallisista kielistä Python, Javascript ja Ruby. Kaikissa niissä kielen esitysmuoto on kielen primitiivitietotyyppi (merkkijono). > > "Olisivat ne ehtineet yleistyä." Silmät auki! Tioben Top-11:ta on ryöminyt muutaman vuoden sisällä edellä mainitsemani kolme dynaamista kieltä. Kyllä ne todellakin yleistyvät.

Lue lisää

No käytännössä siltä "metaohjelmalta" vaaditaan vähän enemmän ymmärrystä generoitavasta ohjelmasta kuin vain että se on merkkijono. Se tässä kiinnostaakin että mitä se generaattori ymmärtää luomastaan algoritmista lopulta? Minkälaisia generointikäytäntöjä on olemassa? Voisinko syöttää metaohjelmallesi jonkun vanhan ohjelmani ja se parantelisi sitä?