Milloin muuten tutustuitte ensimmäisen kerran tietokoneohjelmointiin?

Ja toisena kielenä oli sitten assembly. COM-tiedostoja oli kiva tehdä MS-DOS:ssa kun ei tarvinnut mitään ylimääräistä kuten EXE:ssä, pelkkä koodi.

Ja oli hauskaa kun ohjelma oli jotain 1000 kertaa nopeampi kun kirjoitti GW-BASIC ohjelman assemblyllä.

Ei ollut myöskään mitään häiritseviä muistinsuojauksia - kaikki muisti oli suoraan ohjelman käytettävissä.

Anonyymi kirjoitti:

Ja toisena kielenä oli sitten assembly. COM-tiedostoja oli kiva tehdä MS-DOS:ssa kun ei tarvinnut mitään ylimääräistä kuten EXE:ssä, pelkkä koodi.

Ja oli hauskaa kun ohjelma oli jotain 1000 kertaa nopeampi kun kirjoitti GW-BASIC ohjelman assemblyllä.

Ei ollut myöskään mitään häiritseviä muistinsuojauksia - kaikki muisti oli suoraan ohjelman käytettävissä.

Lue lisää

Minulla oli Basicin jälkeen myös assembly, suorituskykysyistä.

Hullua touhuahan se assembly oli. Optimoiva kääntäjä kun on keksitty.

Anonyymi kirjoitti:

Minulla oli Basicin jälkeen myös assembly, suorituskykysyistä.

Hullua touhuahan se assembly oli. Optimoiva kääntäjä kun on keksitty.

Ei ne kääntäjät optimoineet mitenkään 80-luvulla.

Anonyymi kirjoitti:

Ei ne kääntäjät optimoineet mitenkään 80-luvulla.

Optimoivat kääntäjät keksitiiin 70-luvulla jom ja ihan normi kääntäjissä lisäilivät optimointeja 80-luvulla.

Eli assemblyn hinkkaus oli suurimmaksi osaksi ajan hukkaa kun sen ajan olisi voinut käyttää tekemään ohjelmaa, ja antaa kääntäjän optimoida.

Eikä silläkään väliä ole vaikka heti ei olisi kaikkia optimointeja. Ohjelmat nopeutui ilman että itse näkisi vaivaa päivittämällä kääntäjää ja tietokonetta, ja kääntämällä koodin uusiksi.

Anonyymi kirjoitti:

Optimoivat kääntäjät keksitiiin 70-luvulla jom ja ihan normi kääntäjissä lisäilivät optimointeja 80-luvulla.

Eli assemblyn hinkkaus oli suurimmaksi osaksi ajan hukkaa kun sen ajan olisi voinut käyttää tekemään ohjelmaa, ja antaa kääntäjän optimoida.

Eikä silläkään väliä ole vaikka heti ei olisi kaikkia optimointeja. Ohjelmat nopeutui ilman että itse näkisi vaivaa päivittämällä kääntäjää ja tietokonetta, ja kääntämällä koodin uusiksi.

Lue lisää

Ok. Tuo on sinun mielipide. Ymmärtääkseni assembleria käytettiin 80-luvulla juuri siksi että pystyi tehostamaan muistinkäyttöä ja optimoimaan prosessorin käyttöä. Jos olen väärässä niin silloin miljoonat assembler-koodaritkin olivat ja sinä olit oikeassa?

Anonyymi kirjoitti:

Ok. Tuo on sinun mielipide. Ymmärtääkseni assembleria käytettiin 80-luvulla juuri siksi että pystyi tehostamaan muistinkäyttöä ja optimoimaan prosessorin käyttöä. Jos olen väärässä niin silloin miljoonat assembler-koodaritkin olivat ja sinä olit oikeassa?

Lue lisää

Ja hakusanalla "is assembler better than compiler" löytyy monia mielipiteitä.

Anonyymi kirjoitti:

Ok. Tuo on sinun mielipide. Ymmärtääkseni assembleria käytettiin 80-luvulla juuri siksi että pystyi tehostamaan muistinkäyttöä ja optimoimaan prosessorin käyttöä. Jos olen väärässä niin silloin miljoonat assembler-koodaritkin olivat ja sinä olit oikeassa?

Lue lisää

Sanoin että itsekin aloitin Basicin jälkeen hinkkaamaan assembleriä mutta olenkin nykyään fiksumpi. Tuo oli suurimmaksi osaksi hukkaan heitettyä aikaa koska softa tekee saman.

Niin muistin kuin prosessorin käytön tehostaminen onnistui ihan hyvin korkean tason kielellä, ja päivittämällä kääntäjää ja tietokonetta saatiin tehostus suorituskykyyn ilman koodin kirjoittamista.

Ja mistä tietää assemblerin hinkkaajat oli väärässä?

No siitä että niitä assembler pökäleitä ei käytetä missään. Sen sijaan 80-luvulla kirjoitettuja C-kielisiä ohjelmia on ylläpidetty ja käytetään edelleen ja olivat aikoja sitten nopeutuneet nopeammaksi kuin assemblerviritykset.

Anonyymi kirjoitti:

Sanoin että itsekin aloitin Basicin jälkeen hinkkaamaan assembleriä mutta olenkin nykyään fiksumpi. Tuo oli suurimmaksi osaksi hukkaan heitettyä aikaa koska softa tekee saman.

Niin muistin kuin prosessorin käytön tehostaminen onnistui ihan hyvin korkean tason kielellä, ja päivittämällä kääntäjää ja tietokonetta saatiin tehostus suorituskykyyn ilman koodin kirjoittamista.

Ja mistä tietää assemblerin hinkkaajat oli väärässä?

No siitä että niitä assembler pökäleitä ei käytetä missään. Sen sijaan 80-luvulla kirjoitettuja C-kielisiä ohjelmia on ylläpidetty ja käytetään edelleen ja olivat aikoja sitten nopeutuneet nopeammaksi kuin assemblerviritykset.

Lue lisää

En minäkään nykyään asembleria käyttäisi koska kääntäjä on niin kehittynyt. 80-luvulla asia oli toisin. Optimointi oli tehokkainta assemilla.

Anonyymi kirjoitti:

En minäkään nykyään asembleria käyttäisi koska kääntäjä on niin kehittynyt. 80-luvulla asia oli toisin. Optimointi oli tehokkainta assemilla.

Pointti siis oli se, että softassa riitää yleensä läjäpäin bugeja korjettavaksi, testejä kirjoitettavaksi, toteuttaa puuttuvia ominaisuuksia, optimoida koodia algoritmitasolla, siirtää vaiheittain uudemmalle tekniikalle että siinä vaiheessa kun voisi alkaa optimoida nopeammaksi implementaatiotasolla, se nopeutus tapahtuukin ilman vaivannäköä päivittämällä kääntäjää tai tietokonetta.

Kyllä sillä assemblerin hinkkauksellakin ollut paikkansa mutta melkoisen vähän oikeastaan. Useimmissa asioissa kääntäjän tuottama koodi ratkoo ongelman nopeammin kuin että käyttäisi aikaa assemblerin hinkkaukseen, että laskisi nopeammin. Se assembler optimointi kun kuitenkin vie aikaa.

Anonyymi kirjoitti:

Sanoin että itsekin aloitin Basicin jälkeen hinkkaamaan assembleriä mutta olenkin nykyään fiksumpi. Tuo oli suurimmaksi osaksi hukkaan heitettyä aikaa koska softa tekee saman.

Niin muistin kuin prosessorin käytön tehostaminen onnistui ihan hyvin korkean tason kielellä, ja päivittämällä kääntäjää ja tietokonetta saatiin tehostus suorituskykyyn ilman koodin kirjoittamista.

Ja mistä tietää assemblerin hinkkaajat oli väärässä?

No siitä että niitä assembler pökäleitä ei käytetä missään. Sen sijaan 80-luvulla kirjoitettuja C-kielisiä ohjelmia on ylläpidetty ja käytetään edelleen ja olivat aikoja sitten nopeutuneet nopeammaksi kuin assemblerviritykset.

Lue lisää

Siinä se on taas oikein aasintuntija. Assembly -kieltä on käytetty erittäin paljon ja käytetään edelleen etenkin sulautettujen järjestelmien ohjelmoinnissa. Assemblyä on aina käytetty tilanteissa, joissa on ollut rajalliset resurssit käytettävissä tai on tarvittu aikakriittistä koodia. Sulautetut järjestelmät on vain yksi, mutta erittäin tärkeä esimerkki siitä. Eli jospa olisit suoltamatta mitään potaskaa Assemblyyn liittyen. Niin ja kaikille tiedoksi, kieli on nimeltään Assembly, ei Assembler.

Anonyymi kirjoitti:

Siinä se on taas oikein aasintuntija. Assembly -kieltä on käytetty erittäin paljon ja käytetään edelleen etenkin sulautettujen järjestelmien ohjelmoinnissa. Assemblyä on aina käytetty tilanteissa, joissa on ollut rajalliset resurssit käytettävissä tai on tarvittu aikakriittistä koodia. Sulautetut järjestelmät on vain yksi, mutta erittäin tärkeä esimerkki siitä. Eli jospa olisit suoltamatta mitään potaskaa Assemblyyn liittyen. Niin ja kaikille tiedoksi, kieli on nimeltään Assembly, ei Assembler.

Lue lisää

Mikään ei estä tekemästä softaa rajallisilla resursseilla tai aikakriittistä koodia käyttämällä kääntäjää, että saa parempaa koodia aikaiseksi.

Assemblyä on käytetty lähinnä asioihin joihin ei ole aikoinaan ollut helposti parempia tapoja saatavilla. Sitä löytyy edelleen pieniä määriä rajatusti, kuten joku bootstrapping pätkä tai jotain vastaavaa.

Hienoa! Noita vanhoja juttuja on aina kiva muistella. Ensimmäisen "viruksen" tein joskus 80-luvulla. En muista tarkkaan mutta Amigan käyttöjärjestelmä etsi sisään työnnetystä disketistä heti jonkun diskloader tiedoston ja suoritti sen ainoastaan tarkistaen tiedoston koon. Siihen tiedostoon pystyi itse laittamaan oman koodin kunhan tiedoston koko pysyi tavulleen samana. Kovin vaatimaton oli Amigan tietoturva.

Anonyymi kirjoitti:

Hienoa! Noita vanhoja juttuja on aina kiva muistella. Ensimmäisen "viruksen" tein joskus 80-luvulla. En muista tarkkaan mutta Amigan käyttöjärjestelmä etsi sisään työnnetystä disketistä heti jonkun diskloader tiedoston ja suoritti sen ainoastaan tarkistaen tiedoston koon. Siihen tiedostoon pystyi itse laittamaan oman koodin kunhan tiedoston koko pysyi tavulleen samana. Kovin vaatimaton oli Amigan tietoturva.

Lue lisää

Eipä ollut DOSissakaan tietoturvaa kun virukset hyökkäsivät.
Ensimmäinen tuli Saksasta ostetun ohjelman mukana postipaketissa työkoneelle.
Poisto-ohjelmassa oli listattu 18 kappaletta.

Anonyymi kirjoitti:

Eipä ollut DOSissakaan tietoturvaa kun virukset hyökkäsivät.
Ensimmäinen tuli Saksasta ostetun ohjelman mukana postipaketissa työkoneelle.
Poisto-ohjelmassa oli listattu 18 kappaletta.

Lue lisää

Muistan sen piipaa viiruksen jossa ambulanssi ajeli alalaidassa.
Mutta nehän oli herjapohjalta tehtyjä, ilman isompaa haittaa.

Anonyymi kirjoitti:

Muistan sen piipaa viiruksen jossa ambulanssi ajeli alalaidassa.
Mutta nehän oli herjapohjalta tehtyjä, ilman isompaa haittaa.

Mutta Linuxissa en ole törmännyt yhteenkään haitakeeseen!

Anonyymi kirjoitti:

Mutta Linuxissa en ole törmännyt yhteenkään haitakeeseen!

Eipä niihin törmää jos joku ohjelma ei niitä etsi. Ne haittaohjelmat ovat yleensä suunniteltu niin ettei käyttäjä "törmää".

Anonyymi kirjoitti:

Eipä ollut DOSissakaan tietoturvaa kun virukset hyökkäsivät.
Ensimmäinen tuli Saksasta ostetun ohjelman mukana postipaketissa työkoneelle.
Poisto-ohjelmassa oli listattu 18 kappaletta.

Lue lisää

Latasin joskun 10 vuotta sitten Virolaisen nörtin viruspaketin, 2.4G ja noin 4000 viirusta ja osaan on ohjelma jolla sitä voi muuttaa.
Osa toimii edeleen Windowsissa!

Ihan sama kuin minulla. C64 basic olis ensimmäinen kokeilu. Myöhemmin ohjelmointi alkoi kiinnostaa enemmän. Amigan basic ja assembler ja c. PC kun tuli käyttöön 90-luvun alussa assembler jäi kun se peeceessä tuntui olevan niin sekavaa muistin sivutuksineen ym.

Forth ja Basic ovat kauheita.

C ja Pascal mahdollistavat paremmin strukturoidun ohjelmoinnin, mutta nykyään on kätevämpiäkin kieliä.

Tuo aika hurjaa että vuonna 2022 löytyy joku joka käyttää Basiccia.

Noihin quick and dirty juttuihin löytyy kätevämpiäkin.

Anonyymi kirjoitti:

Forth ja Basic ovat kauheita.

C ja Pascal mahdollistavat paremmin strukturoidun ohjelmoinnin, mutta nykyään on kätevämpiäkin kieliä.

Hmm...
Forth on ongelma-orientoitunut kieli, hieman samaan tapaan kuin Lisp.

Kun tavanomaisissa kielissä ohjelmoija käyttää kääntäjän työkaluja
ongelman ratkaisemiseen, forth-kielessä ohjelmoija tekee työkalut
itse, parhaaksi kätsomallaan tavalla.

Tavalliset kääntäjät kohdatessaan kontrollirakenteita käsittelevät niitä
niin kuin kääntäjään on ohjelmoitu, samoin kääntäjä odottaa kohtaavansa
rivin lopetusmerkin, puolipisteen.

Forthin kääntäjä kontrollirakenteen kohdatessaan ei osaa tehdä sille mitään.
Eikä kääntäjä edes odota kohtaavansa puolipistettä.
Forthissa kyllä käytetään puolipistettä, sen merkitys on erilainen kuin
muissa kielissä.

Aloittajille ei yleensä tätä kerrota, koska he eivät ymmärrä sitä kuin
myöhemmin.
Ohjelmoidessa Forthilla oikeastaan lisätään kääntäjälle uusia ominaisuuksia,
Forthissa ohjelmoidaan kääntäjää.

Eräs hollantilainen yliopisto kokeili oppimisvaikeuksista kärsiville oppilaille
Forthin opettamista, oppilaat halusivat mahdollisimman vähän matikkaa,
jotkut oppilaat olivat kehitelleet näppäriä ratkaisuja, ei kuitenkaan kokeneen
ohjelmoijan tasoista koodia.

Forthissa on äärimmäisen yksinkertainen syntaksi, funktiokutsuja, tai sen tapaisia,
peräkkäin välilyönnillä erotettuna, samaan pötköön funktioden parametrit.

Ohjelmakokonaisuuden faktorointi, mielekkäisiin osiin jakamista, ei C-kielellä
tai Pascalilla edes kannata yrittää. Forthissa se on viety hyvinkin pitkälle
aivan luontevasti.

Jos on käyttänyt HP:n RPN laskinta, siinä on samanlainen periaate kuin
Forthissa, Forth on vain täysiverinen ohjelmointikieli.

Anonyymi kirjoitti:

Tuo aika hurjaa että vuonna 2022 löytyy joku joka käyttää Basiccia.

Noihin quick and dirty juttuihin löytyy kätevämpiäkin.

Käsitämmekö dirty-sanan eri tavalla ?

Mikä olisi kätevämpi vai pitäisikö sanoa dirtympi tapa??

Anonyymi kirjoitti:

Hmm...
Forth on ongelma-orientoitunut kieli, hieman samaan tapaan kuin Lisp.

Kun tavanomaisissa kielissä ohjelmoija käyttää kääntäjän työkaluja
ongelman ratkaisemiseen, forth-kielessä ohjelmoija tekee työkalut
itse, parhaaksi kätsomallaan tavalla.

Tavalliset kääntäjät kohdatessaan kontrollirakenteita käsittelevät niitä
niin kuin kääntäjään on ohjelmoitu, samoin kääntäjä odottaa kohtaavansa
rivin lopetusmerkin, puolipisteen.

Forthin kääntäjä kontrollirakenteen kohdatessaan ei osaa tehdä sille mitään.
Eikä kääntäjä edes odota kohtaavansa puolipistettä.
Forthissa kyllä käytetään puolipistettä, sen merkitys on erilainen kuin
muissa kielissä.

Aloittajille ei yleensä tätä kerrota, koska he eivät ymmärrä sitä kuin
myöhemmin.
Ohjelmoidessa Forthilla oikeastaan lisätään kääntäjälle uusia ominaisuuksia,
Forthissa ohjelmoidaan kääntäjää.

Eräs hollantilainen yliopisto kokeili oppimisvaikeuksista kärsiville oppilaille
Forthin opettamista, oppilaat halusivat mahdollisimman vähän matikkaa,
jotkut oppilaat olivat kehitelleet näppäriä ratkaisuja, ei kuitenkaan kokeneen
ohjelmoijan tasoista koodia.

Forthissa on äärimmäisen yksinkertainen syntaksi, funktiokutsuja, tai sen tapaisia,
peräkkäin välilyönnillä erotettuna, samaan pötköön funktioden parametrit.

Ohjelmakokonaisuuden faktorointi, mielekkäisiin osiin jakamista, ei C-kielellä
tai Pascalilla edes kannata yrittää. Forthissa se on viety hyvinkin pitkälle
aivan luontevasti.

Jos on käyttänyt HP:n RPN laskinta, siinä on samanlainen periaate kuin
Forthissa, Forth on vain täysiverinen ohjelmointikieli.

Lue lisää

"Kun tavanomaisissa kielissä ohjelmoija käyttää kääntäjän työkaluja
ongelman ratkaisemiseen, forth-kielessä ohjelmoija tekee työkalut
itse, parhaaksi kätsomallaan tavalla."

"Kun tavanomaisissa kielissä ohjelmoija käyttää kääntäjän työkaluja
ongelman ratkaisemiseen, forth-kielessä ohjelmoija tekee työkalut
itse, parhaaksi kätsomallaan tavalla."

Ohjelmointikielten tarkoitus on olla formaali kieli millä kirjoitetaan ongelma tietokoneen ymmärtämään muotoon niin että ihminenkin sitä ymmärtää. Se on siis työkalu jolla mallinnetaan se ongelma. Tähän on useita paradigmoja, että jossain kielessä mallinnetaan käsitteitä, jossain taas puretaan ongelma funktioiksi, on deklaratiivinen kuvaus tai sitten on kyselykieli. Ohjelmointikieliä yleisesti käytetään kirjoittamaan välineitä siihen ilmaisuun.

Forth on kovin alkeellinen tässä ja löytyy yksinkertaisesti parempia tapoja näiden työkalujen tekemiseen itse. Työkalujen soveltuvuutta voidaan mitata, että kun on jokin ongelma ja esittää sen ratkaisun koodina, niin analysoi sen koodin vaikka tällä: https://en.wikipedia.org/wiki/Halstead_complexity_measures

Ihan hyvä tapa kehittää itseään ohjelmoijana on pyrkiä ratkaisemaan ongelma mahdollisimman elegantisti laskemalla sen koodin monimutkaisuuden. Sitä pitäisikin osata valita työkalu tehtävään oikein, että sillä esitetty ratkaisu on yksinkertainen. Tuollaisen ohjelman kirjoittaminen on myös yksinkertainen harjoite.

"Ohjelmakokonaisuuden faktorointi, mielekkäisiin osiin jakamista, ei C-kielellä
tai Pascalilla edes kannata yrittää. "

Höpöä.

Tässä pieni opetusvideoita miten C-kielisiä ohjelmakomponentteja on tarkoitus käyttää: https://youtu.be/tc4ROCJYbm0?t=330

C:llä siis palastelee laajankin ohjelmakokonaisuuden helposti uudelleenkäytettäviksi komponenteiksi.

Anonyymi kirjoitti:

Käsitämmekö dirty-sanan eri tavalla ?

Mikä olisi kätevämpi vai pitäisikö sanoa dirtympi tapa??

No siis jos vaan haluaa nopeasti saada ongelman ratkottua. Ei siis tarvitse yhtään välittää siitä miten hieno tai tehokas on vaan kuinka nopeasti saa ongelman ratkaistua.

Ei oikeasti ole mitään sellaista missä olisi kätevintä käyttää Basiccia. Basic olisi kuollut aikoja sitten ellei Microsoft olisi sitä myynyt about joka koneeseen ja sitten se sai jatkoaikaa Visual Basicin muodossa, mikä oli aikoinaan joissakin jutuissa kätevä tapa tehdä käyttöliittymäpuolta mutta mitään ongelmia sillä ei ollut mielekästä ratkoa oikein missään tilantteessa vuosikymmeniin. Yksinkertaisesti liian paska.

Anonyymi kirjoitti:

"Kun tavanomaisissa kielissä ohjelmoija käyttää kääntäjän työkaluja
ongelman ratkaisemiseen, forth-kielessä ohjelmoija tekee työkalut
itse, parhaaksi kätsomallaan tavalla."

"Kun tavanomaisissa kielissä ohjelmoija käyttää kääntäjän työkaluja
ongelman ratkaisemiseen, forth-kielessä ohjelmoija tekee työkalut
itse, parhaaksi kätsomallaan tavalla."

Ohjelmointikielten tarkoitus on olla formaali kieli millä kirjoitetaan ongelma tietokoneen ymmärtämään muotoon niin että ihminenkin sitä ymmärtää. Se on siis työkalu jolla mallinnetaan se ongelma. Tähän on useita paradigmoja, että jossain kielessä mallinnetaan käsitteitä, jossain taas puretaan ongelma funktioiksi, on deklaratiivinen kuvaus tai sitten on kyselykieli. Ohjelmointikieliä yleisesti käytetään kirjoittamaan välineitä siihen ilmaisuun.

Forth on kovin alkeellinen tässä ja löytyy yksinkertaisesti parempia tapoja näiden työkalujen tekemiseen itse. Työkalujen soveltuvuutta voidaan mitata, että kun on jokin ongelma ja esittää sen ratkaisun koodina, niin analysoi sen koodin vaikka tällä: https://en.wikipedia.org/wiki/Halstead_complexity_measures

Ihan hyvä tapa kehittää itseään ohjelmoijana on pyrkiä ratkaisemaan ongelma mahdollisimman elegantisti laskemalla sen koodin monimutkaisuuden. Sitä pitäisikin osata valita työkalu tehtävään oikein, että sillä esitetty ratkaisu on yksinkertainen. Tuollaisen ohjelman kirjoittaminen on myös yksinkertainen harjoite.

"Ohjelmakokonaisuuden faktorointi, mielekkäisiin osiin jakamista, ei C-kielellä
tai Pascalilla edes kannata yrittää. "

Höpöä.

Tässä pieni opetusvideoita miten C-kielisiä ohjelmakomponentteja on tarkoitus käyttää: https://youtu.be/tc4ROCJYbm0?t=330

C:llä siis palastelee laajankin ohjelmakokonaisuuden helposti uudelleenkäytettäviksi komponenteiksi.

Lue lisää

Näytät viittavan C-kieleen.

Siinä ehkä täytyykin lähestyä kuvaamallasi tyylillä, siis kääntäjän
ymmärtämään muotoon.

Forthissa työkalu lähestyminen on täysin luontevaa jo siinä vaiheessa
kun kieltä opetellaan.
Forthissa ohjelmoidaan kääntäjää itseään. Kääntäjä itse tulee ratkaisijaksi.

Forthissa luodaan käsitteellinen malli ongelmasta ja sen mukaan rakennetaan
työkalut, tai näin ainakin keksijä suositteli, sanoen että käsitteellinen malli
on jo ratkaisu ja kieli sitten rakennetaan sellaiseksi että se ratkaisee ongelman.

Forthissa ei edes tarvitse miettiä "työkalujen soveltuvuutta", sopinee hyvin
C-maailmaan.
Niin, C-kielellä on surkea maine bugien lähteenä, Forthin debuggaus on
jotain sellaista mitä C-maailmassa ei olla nähtykään.

Forthin alkeellisuudesta voidaan olla montaa mieltä, ainakin
ammattiohjelmoijat sanovat että Forth on 6-10x tehokkaampi ympäristö
kuin C-kielen vastaava, tai ehkä C-ohjelmoijat tekevät hitaasti koodia.

Ohjelman palastelusta sen verran, ettei siihen tarvita opetusvideoita,
se on vain luonnollinen osa hyvää ohjelmointia, ainakin Forthissa.

Olen kyllä kuullut kritiikkiä C-ohjemoijien taipumuksesta tehdä suuria
järkäleitä, joiden kanssa ollaan sitten vaikeuksissa.

Anonyymi kirjoitti:

No siis jos vaan haluaa nopeasti saada ongelman ratkottua. Ei siis tarvitse yhtään välittää siitä miten hieno tai tehokas on vaan kuinka nopeasti saa ongelman ratkaistua.

Ei oikeasti ole mitään sellaista missä olisi kätevintä käyttää Basiccia. Basic olisi kuollut aikoja sitten ellei Microsoft olisi sitä myynyt about joka koneeseen ja sitten se sai jatkoaikaa Visual Basicin muodossa, mikä oli aikoinaan joissakin jutuissa kätevä tapa tehdä käyttöliittymäpuolta mutta mitään ongelmia sillä ei ollut mielekästä ratkoa oikein missään tilantteessa vuosikymmeniin. Yksinkertaisesti liian paska.

Lue lisää

Kehuit juuri Basicin Quick-and-dirty sopivaksi kieleksi.

Kieliä on joka lähtöön ja lisää tulee, paskakasat vain kasvavat.

Anonyymi kirjoitti:

Näytät viittavan C-kieleen.

Siinä ehkä täytyykin lähestyä kuvaamallasi tyylillä, siis kääntäjän
ymmärtämään muotoon.

Forthissa työkalu lähestyminen on täysin luontevaa jo siinä vaiheessa
kun kieltä opetellaan.
Forthissa ohjelmoidaan kääntäjää itseään. Kääntäjä itse tulee ratkaisijaksi.

Forthissa luodaan käsitteellinen malli ongelmasta ja sen mukaan rakennetaan
työkalut, tai näin ainakin keksijä suositteli, sanoen että käsitteellinen malli
on jo ratkaisu ja kieli sitten rakennetaan sellaiseksi että se ratkaisee ongelman.

Forthissa ei edes tarvitse miettiä "työkalujen soveltuvuutta", sopinee hyvin
C-maailmaan.
Niin, C-kielellä on surkea maine bugien lähteenä, Forthin debuggaus on
jotain sellaista mitä C-maailmassa ei olla nähtykään.

Forthin alkeellisuudesta voidaan olla montaa mieltä, ainakin
ammattiohjelmoijat sanovat että Forth on 6-10x tehokkaampi ympäristö
kuin C-kielen vastaava, tai ehkä C-ohjelmoijat tekevät hitaasti koodia.

Ohjelman palastelusta sen verran, ettei siihen tarvita opetusvideoita,
se on vain luonnollinen osa hyvää ohjelmointia, ainakin Forthissa.

Olen kyllä kuullut kritiikkiä C-ohjemoijien taipumuksesta tehdä suuria
järkäleitä, joiden kanssa ollaan sitten vaikeuksissa.

Lue lisää

"Siinä ehkä täytyykin lähestyä kuvaamallasi tyylillä, siis kääntäjän
ymmärtämään muotoon."

Ei välttämättä. Voihan sitä C:tä käyttää vaikka parserigeneraattoriin ja että sillä sitten ymmärtää sellaista syötettä kuin haluaa.

"Forthissa luodaan käsitteellinen malli ongelmasta ja sen mukaan rakennetaan
työkalut"

Nykyään ne työkalut on jo. Käsitteellinen malli tulee vastaan joka kielellä. Esimerkiksi oliokielillä sitten ohjelmoidaan käsitteitä.

"Niin, C-kielellä on surkea maine bugien lähteenä, Forthin debuggaus on
jotain sellaista mitä C-maailmassa ei olla nähtykään."

Pointtereilla ja heikolla tyypityksellä ne saatu.

C on kuitenkin oikeastaan matalan tason kieli, ja sille toki löytyy työkalut sitten millä varmistetaan että ei tule niitä bugeja mutta en nyt C:llä kävisi mitään quick and dirty ratkaisuja tekemään, oikaisin vain tuota virhettä ei muka pysty faktoroimaan.

"Forthissa ei edes tarvitse miettiä "työkalujen soveltuvuutta"

Tulee se silläkin vastaan. Tuo koodikasan mittaaminen mitä se ongelman ratkaiseminen vaati, käy ihan jokaiseen kieleen, kehittäjään ja toteutukseen.

"Forthin alkeellisuudesta voidaan olla montaa mieltä, ainakin
ammattiohjelmoijat sanovat että Forth on 6-10x tehokkaampi ympäristö
kuin C-kielen vastaava, tai ehkä C-ohjelmoijat tekevät hitaasti koodia."

Mutta miksi pitäisi käyttää kumpaakaan kun on välineitä millä saa nopeammin?

"Olen kyllä kuullut kritiikkiä C-ohjemoijien taipumuksesta tehdä suuria
järkäleitä, joiden kanssa ollaan sitten vaikeuksissa."

Todennäköisemmin kyse on väärin valitusta työkalusta.

Anonyymi kirjoitti:

Kehuit juuri Basicin Quick-and-dirty sopivaksi kieleksi.

Kieliä on joka lähtöön ja lisää tulee, paskakasat vain kasvavat.

"Kehuit juuri Basicin Quick-and-dirty sopivaksi kieleksi."

En kehunut. Paska se on, koska löytyy joka mittapuulla parempia työkaluja.

Anonyymi kirjoitti:

"Siinä ehkä täytyykin lähestyä kuvaamallasi tyylillä, siis kääntäjän
ymmärtämään muotoon."

Ei välttämättä. Voihan sitä C:tä käyttää vaikka parserigeneraattoriin ja että sillä sitten ymmärtää sellaista syötettä kuin haluaa.

"Forthissa luodaan käsitteellinen malli ongelmasta ja sen mukaan rakennetaan
työkalut"

Nykyään ne työkalut on jo. Käsitteellinen malli tulee vastaan joka kielellä. Esimerkiksi oliokielillä sitten ohjelmoidaan käsitteitä.

"Niin, C-kielellä on surkea maine bugien lähteenä, Forthin debuggaus on
jotain sellaista mitä C-maailmassa ei olla nähtykään."

Pointtereilla ja heikolla tyypityksellä ne saatu.

C on kuitenkin oikeastaan matalan tason kieli, ja sille toki löytyy työkalut sitten millä varmistetaan että ei tule niitä bugeja mutta en nyt C:llä kävisi mitään quick and dirty ratkaisuja tekemään, oikaisin vain tuota virhettä ei muka pysty faktoroimaan.

"Forthissa ei edes tarvitse miettiä "työkalujen soveltuvuutta"

Tulee se silläkin vastaan. Tuo koodikasan mittaaminen mitä se ongelman ratkaiseminen vaati, käy ihan jokaiseen kieleen, kehittäjään ja toteutukseen.

"Forthin alkeellisuudesta voidaan olla montaa mieltä, ainakin
ammattiohjelmoijat sanovat että Forth on 6-10x tehokkaampi ympäristö
kuin C-kielen vastaava, tai ehkä C-ohjelmoijat tekevät hitaasti koodia."

Mutta miksi pitäisi käyttää kumpaakaan kun on välineitä millä saa nopeammin?

"Olen kyllä kuullut kritiikkiä C-ohjemoijien taipumuksesta tehdä suuria
järkäleitä, joiden kanssa ollaan sitten vaikeuksissa."

Todennäköisemmin kyse on väärin valitusta työkalusta.

Lue lisää

"Forth on kovin alkeellinen tässä ja löytyy yksinkertaisesti parempia tapoja näiden työkalujen tekemiseen itse. Työkalujen soveltuvuutta voidaan mitata, että kun on jokin ongelma ja esittää sen ratkaisun koodina, niin analysoi sen koodin vaikka tällä: https://en.wikipedia.org/wiki/Halstead_complexity_measures"

Tässä linkissä on C-kielinen esimerkki koodin analysoijasta, kokeilin verrata
sitä Forth-kielen vastaavaan.
Tässä käsittelen asiaa keskiverto ohjelmoijan näkökulmasta, ainakaan Forthille
ei löytynyt mullistavia työkaluja, joten mennään käsipelillä.

main()
{
int a, b, c, avg;
scanf("%d %d %d", &a, &b, &c);
avg = (a b c)/3;
printf("avg = %d", avg);
}

tarpeeksi yksinkertainen vertailun tekemiseen, se laskee kolmen luvun
keskiarvon.

Forthin puolesta koodin voisi tehdä C-henkiseksi, mutta koodi olisi surkeaa
laadultaan, eikä Forth-henkinen.

Verrattuna Forth-koodiin, siinä näkyy C-kääntäjän maailmankuva, kaikki on
funktiota paitsi laskut sen sisällä.

Ensin heitetään C-koodista pois funktioihin kohdistuva koodi, Forth-kääntäjän
mielestä funktioita ei ole olemassa.
'
Joten pois main(), kaarisulkeet, aaltosulkeet, muuttujavaraukset ja käsittely,
forth-kääntäjän maailmankuva on yksinkertainen, ei ole funktioita, ei
proseduureja, ei aliohjemia eikä oikeastaan edes puhtaita operaattoreitakaan.

Koska Forthissa ohjelmoidaan kääntäjää, ohjelmoija katsoo asioita
kääntäjän näkökulmasta, eikä ole pakotettu esittämään asioita kääntäjän
ehdoilla,

Kun C-esimerkki on muutettu Forthkoodiksi, se on tälläinen.

: koe 3 / ." avg = " . ;

Tuollaisena Forth-kääntäjä sen suht mielellään näkisi, tälläisenä se olisi
isomman koodin sisällä.

Tuo on toimiva ohjelma, kaksi merkkiä ja jakoviiva /, käyttäytyvät
kuin operaattorit, toisaalta kääntäjä ja ohjelmoija eivät pidä niitä
vain operaattoreina, ei ainakaan puhtaina sellaisina, niillä on tärkeä
rooli datan liikuttamiseen, jotta data saadaan oikeaan aikaan oikealle
paikalle.
Siksi kielen kehittäjä piti funktioita ja operaattoreita hämäävinä kun
ohjelmoidaan kääntäjää, hän päätti että Forthissa on vain "word",
ohjelmoidaan vain word:jä.

on word, : on word, ; on word

Miten sitten, kun ei ole funktiota, ainakaan puhtaita sellaisia, sitten lasketaan
alussa mainittu koodin analyysi, itse katsoin että se ei ole kovinkaan tärkeä
tässä ympäristössä.

Kyseinen analyysi olettaa hyvin määriteltyjä funktioita ja operaattoreita,
Forthkoodissa niitä ei ole.

Anonyymi kirjoitti:

"Forth on kovin alkeellinen tässä ja löytyy yksinkertaisesti parempia tapoja näiden työkalujen tekemiseen itse. Työkalujen soveltuvuutta voidaan mitata, että kun on jokin ongelma ja esittää sen ratkaisun koodina, niin analysoi sen koodin vaikka tällä: https://en.wikipedia.org/wiki/Halstead_complexity_measures"

Tässä linkissä on C-kielinen esimerkki koodin analysoijasta, kokeilin verrata
sitä Forth-kielen vastaavaan.
Tässä käsittelen asiaa keskiverto ohjelmoijan näkökulmasta, ainakaan Forthille
ei löytynyt mullistavia työkaluja, joten mennään käsipelillä.

main()
{
int a, b, c, avg;
scanf("%d %d %d", &a, &b, &c);
avg = (a b c)/3;
printf("avg = %d", avg);
}

tarpeeksi yksinkertainen vertailun tekemiseen, se laskee kolmen luvun
keskiarvon.

Forthin puolesta koodin voisi tehdä C-henkiseksi, mutta koodi olisi surkeaa
laadultaan, eikä Forth-henkinen.

Verrattuna Forth-koodiin, siinä näkyy C-kääntäjän maailmankuva, kaikki on
funktiota paitsi laskut sen sisällä.

Ensin heitetään C-koodista pois funktioihin kohdistuva koodi, Forth-kääntäjän
mielestä funktioita ei ole olemassa.
'
Joten pois main(), kaarisulkeet, aaltosulkeet, muuttujavaraukset ja käsittely,
forth-kääntäjän maailmankuva on yksinkertainen, ei ole funktioita, ei
proseduureja, ei aliohjemia eikä oikeastaan edes puhtaita operaattoreitakaan.

Koska Forthissa ohjelmoidaan kääntäjää, ohjelmoija katsoo asioita
kääntäjän näkökulmasta, eikä ole pakotettu esittämään asioita kääntäjän
ehdoilla,

Kun C-esimerkki on muutettu Forthkoodiksi, se on tälläinen.

: koe 3 / ." avg = " . ;

Tuollaisena Forth-kääntäjä sen suht mielellään näkisi, tälläisenä se olisi
isomman koodin sisällä.

Tuo on toimiva ohjelma, kaksi merkkiä ja jakoviiva /, käyttäytyvät
kuin operaattorit, toisaalta kääntäjä ja ohjelmoija eivät pidä niitä
vain operaattoreina, ei ainakaan puhtaina sellaisina, niillä on tärkeä
rooli datan liikuttamiseen, jotta data saadaan oikeaan aikaan oikealle
paikalle.
Siksi kielen kehittäjä piti funktioita ja operaattoreita hämäävinä kun
ohjelmoidaan kääntäjää, hän päätti että Forthissa on vain "word",
ohjelmoidaan vain word:jä.

on word, : on word, ; on word

Miten sitten, kun ei ole funktiota, ainakaan puhtaita sellaisia, sitten lasketaan
alussa mainittu koodin analyysi, itse katsoin että se ei ole kovinkaan tärkeä
tässä ympäristössä.

Kyseinen analyysi olettaa hyvin määriteltyjä funktioita ja operaattoreita,
Forthkoodissa niitä ei ole.

Lue lisää

"Kun C-esimerkki on muutettu Forthkoodiksi, se on tälläinen."

Ei toimi. Koodisi ei ole ajettavassa muodossa.

Syötä rimpsusi vaikka tähän niin, että sitä voi ajaa: https://www.tutorialspoint.com/execute_forth_online.php

Minä puolestani nostan rimaa vähän että miten olisi tällainen?

print("avg = ", sum(map(int, input().split())) / 3)

Ja Halstead complixityllä kun laski tuon ohjelman niin saatiin:

V = 50,72
D = 9
E = 456,48

Parempi siis kuin C-kielinen.

"Kyseinen analyysi olettaa hyvin määriteltyjä funktioita ja operaattoreita,
Forthkoodissa niitä ei ole."

Ei oleta. Siinä lasketaan operaattoreita ja operandeja. Ei siis tarvitse mitään funktioita vaan tuolla analysoi vaikka assemblerkoodia. Eli kuinka monta yhteensä, ja monta erilaista käytetty. Ne voidaan laskea ihan mistä tahansa koodista ja saadaan siitä vertailukelpoinen lukema.

Anonyymi kirjoitti:

"Kun C-esimerkki on muutettu Forthkoodiksi, se on tälläinen."

Ei toimi. Koodisi ei ole ajettavassa muodossa.

Syötä rimpsusi vaikka tähän niin, että sitä voi ajaa: https://www.tutorialspoint.com/execute_forth_online.php

Minä puolestani nostan rimaa vähän että miten olisi tällainen?

print("avg = ", sum(map(int, input().split())) / 3)

Ja Halstead complixityllä kun laski tuon ohjelman niin saatiin:

V = 50,72
D = 9
E = 456,48

Parempi siis kuin C-kielinen.

"Kyseinen analyysi olettaa hyvin määriteltyjä funktioita ja operaattoreita,
Forthkoodissa niitä ei ole."

Ei oleta. Siinä lasketaan operaattoreita ja operandeja. Ei siis tarvitse mitään funktioita vaan tuolla analysoi vaikka assemblerkoodia. Eli kuinka monta yhteensä, ja monta erilaista käytetty. Ne voidaan laskea ihan mistä tahansa koodista ja saadaan siitä vertailukelpoinen lukema.

Lue lisää

"Ei toimi. Koodisi ei ole ajettavassa muodossa.

Syötä rimpsusi vaikka tähän niin, että sitä voi ajaa: https://www.tutorialspoint.com/execute_forth_online.php"

No kyllä toimii, ajoit sen väärin. Syötä se näin.

1 2 3 koe.

Ei kait ohjelmointikilpailu ole edessä. en oikein viitsisi.

Anonyymi kirjoitti:

"Ei toimi. Koodisi ei ole ajettavassa muodossa.

Syötä rimpsusi vaikka tähän niin, että sitä voi ajaa: https://www.tutorialspoint.com/execute_forth_online.php"

No kyllä toimii, ajoit sen väärin. Syötä se näin.

1 2 3 koe.

Ei kait ohjelmointikilpailu ole edessä. en oikein viitsisi.

Lue lisää

Ei toimi.

Anonyymi kirjoitti:

"Ei toimi. Koodisi ei ole ajettavassa muodossa.

Syötä rimpsusi vaikka tähän niin, että sitä voi ajaa: https://www.tutorialspoint.com/execute_forth_online.php"

No kyllä toimii, ajoit sen väärin. Syötä se näin.

1 2 3 koe.

Ei kait ohjelmointikilpailu ole edessä. en oikein viitsisi.

Lue lisää

Se ei toimi samalla tavalla, vaan referenssinä oleva C-kielinen ohjelma käynnistyy, kysyy vain ne numerot eikä edelytä mitään "koe" kirjoittamista. Tuossa vähän oikaistaan.

Ymmärrän kyllä forthin logiikan, että joka kielellä on täysin vastaavia tapoja ohjelmoida.

Anonyymi kirjoitti:

Ei toimi.

Hmm.

Tyhjennä pois se hello world juttu.

Kopioi 1. riville koodi., enter
2. riville 1 2 3 koe välilyönti numeroiden ja koe sanan välissä, koe perässä ei pistettä.
sitten execute

numeroiden välissä välilyönti.

Minkälaisia arvoja forth rimpsu sai??

Anonyymi kirjoitti:

Hmm.

Tyhjennä pois se hello world juttu.

Kopioi 1. riville koodi., enter
2. riville 1 2 3 koe välilyönti numeroiden ja koe sanan välissä, koe perässä ei pistettä.
sitten execute

numeroiden välissä välilyönti.

Minkälaisia arvoja forth rimpsu sai??

Lue lisää

Kopioiko selaimesi oikein minun forthkoodin?
Ei siinä pitäisi C-ohjelma käynnistyä, tarkista selaimesi kopio muisti
että siellä on vain minun forthkoodi.

Anonyymi kirjoitti:

Hmm.

Tyhjennä pois se hello world juttu.

Kopioi 1. riville koodi., enter
2. riville 1 2 3 koe välilyönti numeroiden ja koe sanan välissä, koe perässä ei pistettä.
sitten execute

numeroiden välissä välilyönti.

Minkälaisia arvoja forth rimpsu sai??

Lue lisää

Se execute ei kysy niitä numeroita vaan ne pitää kirjoittaa siihen ohjelmaan mukaan, ja pitää kirjoittaa myös "koe".

Jos kirjoittaa kaksi riviä koodia, eli

: koe 3 / ." avg = " . ;
1 2 3 koe

Niin sitten se parsii ensiksi rivin yksi kirjoittamalla sanalle "koe" mitä pitäisi tehdä ja toinen rivi sitten parsii syötteen ja kutsuu sitä sanaa "koe"

Mutta tuohan ei toimi nyt samalla tavalla. Tuo C-kielinen ohjelma lukee syötettä stdin ja kun virta loppuu niin sitten lasketaan tulos.

Tämä on parempi tuohon forthin testailuun: https://www.jdoodle.com/execute-forth-online/

Pitäisi kirjoittaa se ohjelma tuohon ylös, ja stdin inputs -kohtaan sitten 1 2 3

Ja siellä stdin ei pitäisi lukea mikään "koe".

Anonyymi kirjoitti:

Se execute ei kysy niitä numeroita vaan ne pitää kirjoittaa siihen ohjelmaan mukaan, ja pitää kirjoittaa myös "koe".

Jos kirjoittaa kaksi riviä koodia, eli

: koe 3 / ." avg = " . ;
1 2 3 koe

Niin sitten se parsii ensiksi rivin yksi kirjoittamalla sanalle "koe" mitä pitäisi tehdä ja toinen rivi sitten parsii syötteen ja kutsuu sitä sanaa "koe"

Mutta tuohan ei toimi nyt samalla tavalla. Tuo C-kielinen ohjelma lukee syötettä stdin ja kun virta loppuu niin sitten lasketaan tulos.

Tämä on parempi tuohon forthin testailuun: https://www.jdoodle.com/execute-forth-online/

Pitäisi kirjoittaa se ohjelma tuohon ylös, ja stdin inputs -kohtaan sitten 1 2 3

Ja siellä stdin ei pitäisi lukea mikään "koe".

Lue lisää

Kokeilin juuri
https://www.jdoodle.com/execute-forth-online/

Toimi pienen hapuilun jälkeen, päivitin kerran sen sivun, saattoi auttaa.

https://www.tutorialspoint.com/execute_forth_online.php
kun kokeilin tätä, päivitin usein myös tätä sivua, se tuntui auttavan.

Joka tapauksessa, kummallakin sivulla toimii niin kuin pitää,
2. rivillä,

1 2 3 koe sitten execute toimii täysin.

Kysymys, oletko analysoinut sillä testillä myös forthkoodin, minkälaisia
lukemia siitä?

Anonyymi kirjoitti:

Kokeilin juuri
https://www.jdoodle.com/execute-forth-online/

Toimi pienen hapuilun jälkeen, päivitin kerran sen sivun, saattoi auttaa.

https://www.tutorialspoint.com/execute_forth_online.php
kun kokeilin tätä, päivitin usein myös tätä sivua, se tuntui auttavan.

Joka tapauksessa, kummallakin sivulla toimii niin kuin pitää,
2. rivillä,

1 2 3 koe sitten execute toimii täysin.

Kysymys, oletko analysoinut sillä testillä myös forthkoodin, minkälaisia
lukemia siitä?

Lue lisää

Vielä yksi huomio, laitan 1. rivin koodin copylla, en kirjoita mitään siihen.
Sitten painan enteriä, ja jos 2,. rivin kursori häviää, aktivoin sen
ja sitten 2. riville 1 2 3 koe ja execute nappia.

Anonyymi kirjoitti:

Tuo aika hurjaa että vuonna 2022 löytyy joku joka käyttää Basiccia.

Noihin quick and dirty juttuihin löytyy kätevämpiäkin.

Ei kukaan varmaan ja Windowsiin en kyllä koodaa enään yhtään mitään!
Se varasti koodiani!

Anonyymi kirjoitti:

"Ei toimi. Koodisi ei ole ajettavassa muodossa.

Syötä rimpsusi vaikka tähän niin, että sitä voi ajaa: https://www.tutorialspoint.com/execute_forth_online.php"

No kyllä toimii, ajoit sen väärin. Syötä se näin.

1 2 3 koe.

Ei kait ohjelmointikilpailu ole edessä. en oikein viitsisi.

Lue lisää

Ei nykymailmaassa kannata kaikkia itse kirjoittaa, valmiita pätkiä on lähes joka asiaan! Vapaana koodina!

Anonyymi kirjoitti:

Ei kukaan varmaan ja Windowsiin en kyllä koodaa enään yhtään mitään!
Se varasti koodiani!

Et sinä Windowsiin ole mitään koodannutkaan. Se kun ei ole vapaata lähdekoodia, jota käyttäjä voi itse mielensä mukaan muokata.

Ainoa mitä voin jollain tasolla kuvitella sinun tarkoittavan, niin että siinä olisi mitään järkeä, on että olet käyttänyt versionhallintaan Githubia, josta Microsoftin Copilot (ei Windows) on käyttänyt koodiasi tekoälyn kouluttamiseen.

Jos tuota tarkoitit, niin sehän ei taas liity Windowsiin mitenkään, koska mitään Windowsia ei ole ohjelmoitu Copilotin avulla. Copilot on (ainakin toistaiseksi) harrastelijapuuhastelijoiden leikkikalu, joka ennemminkin lisää kuin vähentää työmäärää jos sitä yrittäisi käyttää johonkin vakavahenkiseen projektiin.

Copilotinkaan tapauksessahan Microsoft ei ole kenenkään koodia varastanut, vaan vahingossa (huonon datankäsittelyn seurauksena) saanut aikaan, että moni Copilotin käyttäjä on tietämättään (tai osa tietoisesti) varastanut Githubin käyttäjien koodia, kun Copilot on sitä tarjonnut.

Clojuren muodossa sitä käytetään paljonkin.

Huomauttaisin vain että kielen parsiminen on tunnettu erittäin hyvin vuosikymmenien ajan, ei se ole mitään salatiedettä.

Olen minäkin ohjelmoinut oman pökäleen lispin parsimiseksi ja pientä DSL:ää.

Minun näkemykseni on hyvin vahva siinä, että ohjelmoinnin tarkoitus on siirtää ihmisten ajatuksia ajettavaan muotoon.

Ohjelmointikielen tarkoitus taas on olla työkalu siihen, että niitä ajatuksia voi ilmaista formaalilla kielelellä mitä ihmiset voivat ymmärtää ja mitä voi koneellisesti lukea.

Eri tavat ilmaista onnistuvat käytännössä aivan kaikilla turing täydellisillä kielillä. Esimerkiksi sillä C:llä onnistuu aivan helposti ohjelmoimaan täysin vastaavalla tavalla kuin Forthilla.

Joten se mikä ratkaisee on se, että miten hyvin ilmaisee olemassa olevilla työkaluilla ongelman että se täyttää vaatimukset. Ja niitä asioita voi mitata vaikka staattisella analysoinnilla, mittaamalla aikaa, muistinkulutusta tai mitä nyt keksiikään.

Anonyymi kirjoitti:

Huomauttaisin vain että kielen parsiminen on tunnettu erittäin hyvin vuosikymmenien ajan, ei se ole mitään salatiedettä.

Olen minäkin ohjelmoinut oman pökäleen lispin parsimiseksi ja pientä DSL:ää.

Minun näkemykseni on hyvin vahva siinä, että ohjelmoinnin tarkoitus on siirtää ihmisten ajatuksia ajettavaan muotoon.

Ohjelmointikielen tarkoitus taas on olla työkalu siihen, että niitä ajatuksia voi ilmaista formaalilla kielelellä mitä ihmiset voivat ymmärtää ja mitä voi koneellisesti lukea.

Eri tavat ilmaista onnistuvat käytännössä aivan kaikilla turing täydellisillä kielillä. Esimerkiksi sillä C:llä onnistuu aivan helposti ohjelmoimaan täysin vastaavalla tavalla kuin Forthilla.

Joten se mikä ratkaisee on se, että miten hyvin ilmaisee olemassa olevilla työkaluilla ongelman että se täyttää vaatimukset. Ja niitä asioita voi mitata vaikka staattisella analysoinnilla, mittaamalla aikaa, muistinkulutusta tai mitä nyt keksiikään.

Lue lisää

En kiistä parsereiden roolia.

Sanoin alkuviestissäni, etten pitänyt hyvänä ajatella ongelmia in terms of
c-compiler, kuten amerikkalanen voisi tehokkaasti ilmaista.

Jos luit Mooren haastattelun, siinä on myös minun ajatukseni aika pitkälle,
ei syntaksi kiemurtelua, se että itse täydennetään kääntäjää, se minkä Moore
mainitsee kerran hyvän koodin tunnusmerkkinä, koodin suorituksen flow
tunteen, muissa kielissä sitä en ole kokenut, sen on moni forthkoodaaja maininnut.

Vaikka kääntäjää ohjelmoidaan, voidaan rakentaa toisentyyppinen muuttuja
perusmuuttujan rinnalle, koodin flow suoritus menee edelle, eikä kääntäjän
muuttamisella ole itsetarkoitusta.

Hyvä forth-ohjelmoija tuottaa nuo kaikki ratkaisevat tekijät suoraan forthin ominaisuuksilla.

Kun kerran parametriliikenne menee käyttäjän näkyvissä pinon kautta,
ohjelmoija pyrkii rakentamaan mahdollisimman tehokkaan koodin,
forthmaisen sellaisen. Sellaista C-ohjemoijat eivät heti osaa tehdä siirtyessään
forthin puolelle, he ovat oppineet toiseen ohjelmointityyliin.
On opittava toisenlainen ohjelmointityyli, kaikista ei edes ole sellaiseen.

Anonyymi kirjoitti:

En kiistä parsereiden roolia.

Sanoin alkuviestissäni, etten pitänyt hyvänä ajatella ongelmia in terms of
c-compiler, kuten amerikkalanen voisi tehokkaasti ilmaista.

Jos luit Mooren haastattelun, siinä on myös minun ajatukseni aika pitkälle,
ei syntaksi kiemurtelua, se että itse täydennetään kääntäjää, se minkä Moore
mainitsee kerran hyvän koodin tunnusmerkkinä, koodin suorituksen flow
tunteen, muissa kielissä sitä en ole kokenut, sen on moni forthkoodaaja maininnut.

Vaikka kääntäjää ohjelmoidaan, voidaan rakentaa toisentyyppinen muuttuja
perusmuuttujan rinnalle, koodin flow suoritus menee edelle, eikä kääntäjän
muuttamisella ole itsetarkoitusta.

Hyvä forth-ohjelmoija tuottaa nuo kaikki ratkaisevat tekijät suoraan forthin ominaisuuksilla.

Kun kerran parametriliikenne menee käyttäjän näkyvissä pinon kautta,
ohjelmoija pyrkii rakentamaan mahdollisimman tehokkaan koodin,
forthmaisen sellaisen. Sellaista C-ohjemoijat eivät heti osaa tehdä siirtyessään
forthin puolelle, he ovat oppineet toiseen ohjelmointityyliin.
On opittava toisenlainen ohjelmointityyli, kaikista ei edes ole sellaiseen.

Lue lisää

"Sanoin alkuviestissäni, etten pitänyt hyvänä ajatella ongelmia in terms of
c-compiler, kuten amerikkalanen voisi tehokkaasti ilmaista."

Ei niin pidäkkään ajatella. Ennemminkin pitää ajatella sitä, että on ongelma mikä pitää ratkaista, ratkaisulla kelpoisuusvaatimukset ja miten se käy mahdollisimman elegantisti.

Käytännön elämän kelpoisuusvaatimuksia voi olla vaikka suorituskyky, integrointi toiseen jöärjestelmään ja standardit ja miten varmistetaan laatu että ei ole ihan buginen.

En minä pidä C:tä sopivana monessakaan käytännön asiassa. Se mitä sillä tehdään on systeemitason juttuja että riippuvuudet pysyvät pienenä, tai jotain matalan tason juttua kun on niille mikrokontrollereille SDK:ta jossa se C-kääntäjä. C:llä voi olla käyttökohteensa myös siinä jos tekee niitä hyvin pieniä komponentteja unix putkiin. Eli siinä mihin se on alunperinkin tehty.

Kieli on työkalu joka valitaan ongelman mukaan, sillä ilmaistaan sitä tähän sopivaa paradigmaa ja toteutetaan arkkitehtuuria.

Anonyymi kirjoitti:

"Sanoin alkuviestissäni, etten pitänyt hyvänä ajatella ongelmia in terms of
c-compiler, kuten amerikkalanen voisi tehokkaasti ilmaista."

Ei niin pidäkkään ajatella. Ennemminkin pitää ajatella sitä, että on ongelma mikä pitää ratkaista, ratkaisulla kelpoisuusvaatimukset ja miten se käy mahdollisimman elegantisti.

Käytännön elämän kelpoisuusvaatimuksia voi olla vaikka suorituskyky, integrointi toiseen jöärjestelmään ja standardit ja miten varmistetaan laatu että ei ole ihan buginen.

En minä pidä C:tä sopivana monessakaan käytännön asiassa. Se mitä sillä tehdään on systeemitason juttuja että riippuvuudet pysyvät pienenä, tai jotain matalan tason juttua kun on niille mikrokontrollereille SDK:ta jossa se C-kääntäjä. C:llä voi olla käyttökohteensa myös siinä jos tekee niitä hyvin pieniä komponentteja unix putkiin. Eli siinä mihin se on alunperinkin tehty.

Kieli on työkalu joka valitaan ongelman mukaan, sillä ilmaistaan sitä tähän sopivaa paradigmaa ja toteutetaan arkkitehtuuria.

Lue lisää

Tietenkin kieli on työkalu, tarkoitettu kuitenkin ihmiselle jonka
tiedonkäsittely on kuitenkin omanlaatuisensa. Voisi ajatella että kun
kone ei toimi kuin aivot, niin kielen pitäisi olla ihmisen ajattelun luonteinen
ja kääntäjän sitten tehdä siitä koneelle tehokas koodi.

Kääntäjän rooli pakottaa kuitenkin kielen tietyn tyyppiseksi ja siten ohjelmoijan
toimimaan kääntäjän ehdoilla.
Näyttää siltä että kielen kehittäjän tausta vaikuttaa tehdyn kielen rakenteeseen,
pascalin tekijä oli yliopistoproffa, se näkyykin sitten muodollisudessa ja
syntaksin painotuksessa. Jos syntaksi aiheuttaa eniten virheitä, niin ihmisen
ajattelun suunnasta pascal ja sen seuraajat eivät ole paras mahdollinen kieli.

C-tekijät olivat tietojenkäsittelytieteilijöitä ja työskentelivät Bells labrassa,
he olivat järjestelmärakentajia, ehkä se näkyy sitten C-kääntäjässä.

Forthin kehittäjä oli freelanceohjelmoija, joka kokemuksestaan halusi tehdä
itselleen tehokkaamman työkalun, olisiko hän päässyt lähemmäksi ihmisen
luontaista tapaa ajatella ja rakentaa kone-kieli-kokonaisuus sen mukaan.

Muistan, kun kaverini osti itselleen pienen korttikoneen, siinä oli 3-4 pientä
lediä, sitä ohjelmoitiin numeronäppäimistöllä jolla syötettiin binääriluvut
suoraan muistiin. Hän laski binäärit paperilla katsoi ohjeista mihin muistiin
numerot syötetään, sen äheltämisen jälkeen yksi ledi saatiin syttymään.

Katsottuani sitä, sanoin hänelle " Täytyy olla parempi tapa tehdä tuo", ehkä
siitä on lähtenyt hyvän tietokoneliittymän etsintä.

Lueskellassani "Mestariojelmoijat" teosta, kaikilla tekijöillä oli oma näkemys
kielestä, eräänlainen kielifilosofia, niissä oli aika suuria eroja, kaikki eivät
kylläkään osanneet oikein muotoilla näkemyksiään, vaan miettivät lähinnä
teknisiä asioita, eivät ihmisen ajattelun suunnasta.

Anonyymi kirjoitti:

Tietenkin kieli on työkalu, tarkoitettu kuitenkin ihmiselle jonka
tiedonkäsittely on kuitenkin omanlaatuisensa. Voisi ajatella että kun
kone ei toimi kuin aivot, niin kielen pitäisi olla ihmisen ajattelun luonteinen
ja kääntäjän sitten tehdä siitä koneelle tehokas koodi.

Kääntäjän rooli pakottaa kuitenkin kielen tietyn tyyppiseksi ja siten ohjelmoijan
toimimaan kääntäjän ehdoilla.
Näyttää siltä että kielen kehittäjän tausta vaikuttaa tehdyn kielen rakenteeseen,
pascalin tekijä oli yliopistoproffa, se näkyykin sitten muodollisudessa ja
syntaksin painotuksessa. Jos syntaksi aiheuttaa eniten virheitä, niin ihmisen
ajattelun suunnasta pascal ja sen seuraajat eivät ole paras mahdollinen kieli.

C-tekijät olivat tietojenkäsittelytieteilijöitä ja työskentelivät Bells labrassa,
he olivat järjestelmärakentajia, ehkä se näkyy sitten C-kääntäjässä.

Forthin kehittäjä oli freelanceohjelmoija, joka kokemuksestaan halusi tehdä
itselleen tehokkaamman työkalun, olisiko hän päässyt lähemmäksi ihmisen
luontaista tapaa ajatella ja rakentaa kone-kieli-kokonaisuus sen mukaan.

Muistan, kun kaverini osti itselleen pienen korttikoneen, siinä oli 3-4 pientä
lediä, sitä ohjelmoitiin numeronäppäimistöllä jolla syötettiin binääriluvut
suoraan muistiin. Hän laski binäärit paperilla katsoi ohjeista mihin muistiin
numerot syötetään, sen äheltämisen jälkeen yksi ledi saatiin syttymään.

Katsottuani sitä, sanoin hänelle " Täytyy olla parempi tapa tehdä tuo", ehkä
siitä on lähtenyt hyvän tietokoneliittymän etsintä.

Lueskellassani "Mestariojelmoijat" teosta, kaikilla tekijöillä oli oma näkemys
kielestä, eräänlainen kielifilosofia, niissä oli aika suuria eroja, kaikki eivät
kylläkään osanneet oikein muotoilla näkemyksiään, vaan miettivät lähinnä
teknisiä asioita, eivät ihmisen ajattelun suunnasta.

Lue lisää

"Voisi ajatella että kun kone ei toimi kuin aivot, niin kielen pitäisi olla ihmisen ajattelun luonteinen ja kääntäjän sitten tehdä siitä koneelle tehokas koodi."

Juurikin näin.

Tuo menee käytännössä ratkottavan ongelman mukaan, minkälainen ajatusmalli sen ratkaisuun sopii parhaiten.

Kun on kyse matemaattisemmasta ongelmasta ja algoritmeista, funktionaalinen lähestymistapa on paras.

Oliokieli taas on työkalu jolla mallinnetaan käsitteitä, ja rakennetaan näillä kieltä kommunikointiin.

Melkoisen paljon ratkottavista asioista on parasta kyseiseen ongelmaan suunnatulla kielellä, käyttää niin sanottua domain specific langugea. Näitähän on runsaasti ohjaamaan vaikka projektia, konfiguraatiota, testausta, käyttöliittymää jne. Sitten on query kieliä joiden tarkoitus on ratkaista asia kysymällä tallennettua tietoa.

Niin Pascal kuin C ovat melkoisen kankeita. Forth taas muistuttaa jotain matalan tason parserigeneraattoria. Parserigeneraattorit ovat yleisiä kun rakennetaan jotain domain specific languagea.

C on jäänyt henkiin sinne matalalle tasolle defacto standardina.

"Forthin kehittäjä oli freelanceohjelmoija, joka kokemuksestaan halusi tehdä
itselleen tehokkaamman työkalun, olisiko hän päässyt lähemmäksi ihmisen
luontaista tapaa ajatella ja rakentaa kone-kieli-kokonaisuus sen mukaan."

Sanoisin että ei. Se tapa miten ajatellaan menee niin paljon ratkaistavan ongelman mukaan.

Anonyymi kirjoitti:

"Voisi ajatella että kun kone ei toimi kuin aivot, niin kielen pitäisi olla ihmisen ajattelun luonteinen ja kääntäjän sitten tehdä siitä koneelle tehokas koodi."

Juurikin näin.

Tuo menee käytännössä ratkottavan ongelman mukaan, minkälainen ajatusmalli sen ratkaisuun sopii parhaiten.

Kun on kyse matemaattisemmasta ongelmasta ja algoritmeista, funktionaalinen lähestymistapa on paras.

Oliokieli taas on työkalu jolla mallinnetaan käsitteitä, ja rakennetaan näillä kieltä kommunikointiin.

Melkoisen paljon ratkottavista asioista on parasta kyseiseen ongelmaan suunnatulla kielellä, käyttää niin sanottua domain specific langugea. Näitähän on runsaasti ohjaamaan vaikka projektia, konfiguraatiota, testausta, käyttöliittymää jne. Sitten on query kieliä joiden tarkoitus on ratkaista asia kysymällä tallennettua tietoa.

Niin Pascal kuin C ovat melkoisen kankeita. Forth taas muistuttaa jotain matalan tason parserigeneraattoria. Parserigeneraattorit ovat yleisiä kun rakennetaan jotain domain specific languagea.

C on jäänyt henkiin sinne matalalle tasolle defacto standardina.

"Forthin kehittäjä oli freelanceohjelmoija, joka kokemuksestaan halusi tehdä
itselleen tehokkaamman työkalun, olisiko hän päässyt lähemmäksi ihmisen
luontaista tapaa ajatella ja rakentaa kone-kieli-kokonaisuus sen mukaan."

Sanoisin että ei. Se tapa miten ajatellaan menee niin paljon ratkaistavan ongelman mukaan.

Lue lisää

"Niin Pascal kuin C ovat melkoisen kankeita. Forth taas muistuttaa jotain matalan tason parserigeneraattoria."

Forth muistuttaa sitä, mutta Forth on pinokoneiden kieli ja niissä on päästy
noin pitkälle, syntaksi minimissään.
De facto Forth on pinokoneiden äidinkieli.

Kun ihminen on käsiteajattelija, asia vodaan kuvata yleisesti näin.

Ihmisen tiedonkäsittelyssä ja Forthin toiminnassa on huomattavia
samanlaisuutta, ehkä Forthin kehittäjä on intuitiivisesti matkinut
Forthissaan ihmistä.

Kehittäjä kutsui Forthia ongelma-orientoituneeksi kieleksi, ehkä tästä syystä.

Kun ihminen kohtaa ongelman, hän automaattisesti tarkastaa käsitteistöstään
onko siellä ratkaisuvälineitä, jos ei, niin onko samanlaista asiaa käsitelty
aikaisemmin. Jos ei, niin hän alkaa rakentamaan tarvittavia käsitteitä,
tämä vaihe voi kestää vuosikaupalla. Tämän kaiken hän tekee tietoisuuden
avulla.

Forthissa ei ole tietoisuutta, joten ohjelmoijan on astuttava puikkoihin.
Ohjelmoija tarkistaa sanakirjasta onko siellä työvälineitä ongelman
ratkaisuun, jos ei, niin onko joskus käsitelty saman tyyppistä, eli
onko sanakirjan luvuissa ideoita, jos ei, niin ohjelmoija alkaa rakentamaan
uusia käsitteitä Forth ympäristön sanakirjaan. Rivikoodia enter, koodi on
käännetty ja linkattu sanakirjaan, jokainen uusi sana on kääntäjän käytössä.

Lopputuloksena on Forth-kielen laajennettu versio, joka on viritetty tuon
ongelman ratkaisuun.
Samoin kuin ihmisen ratkaistua oman ongelmansa, hänellä on laajennettu ja
tehostettu käsitekoneisto myös sellaisten ongelmien ratkaisuun.

Epäilen että kehittäjä on vaistonvaraisesti kehitellyt itsessään tunnistamansa
tapahtumaketjun, eräät haastattelukommentit antavat ymmärtää näin.

Amerikkalaiset käyttävät yleisesti ilmaisua "in terms of", kun terms viittaa
käsitteisiin, kehittäjä on varmasti kuullut tämän ilmaisun useasti ja tunnistaa
käsitteiden roolin.

Anonyymi kirjoitti:

"Niin Pascal kuin C ovat melkoisen kankeita. Forth taas muistuttaa jotain matalan tason parserigeneraattoria."

Forth muistuttaa sitä, mutta Forth on pinokoneiden kieli ja niissä on päästy
noin pitkälle, syntaksi minimissään.
De facto Forth on pinokoneiden äidinkieli.

Kun ihminen on käsiteajattelija, asia vodaan kuvata yleisesti näin.

Ihmisen tiedonkäsittelyssä ja Forthin toiminnassa on huomattavia
samanlaisuutta, ehkä Forthin kehittäjä on intuitiivisesti matkinut
Forthissaan ihmistä.

Kehittäjä kutsui Forthia ongelma-orientoituneeksi kieleksi, ehkä tästä syystä.

Kun ihminen kohtaa ongelman, hän automaattisesti tarkastaa käsitteistöstään
onko siellä ratkaisuvälineitä, jos ei, niin onko samanlaista asiaa käsitelty
aikaisemmin. Jos ei, niin hän alkaa rakentamaan tarvittavia käsitteitä,
tämä vaihe voi kestää vuosikaupalla. Tämän kaiken hän tekee tietoisuuden
avulla.

Forthissa ei ole tietoisuutta, joten ohjelmoijan on astuttava puikkoihin.
Ohjelmoija tarkistaa sanakirjasta onko siellä työvälineitä ongelman
ratkaisuun, jos ei, niin onko joskus käsitelty saman tyyppistä, eli
onko sanakirjan luvuissa ideoita, jos ei, niin ohjelmoija alkaa rakentamaan
uusia käsitteitä Forth ympäristön sanakirjaan. Rivikoodia enter, koodi on
käännetty ja linkattu sanakirjaan, jokainen uusi sana on kääntäjän käytössä.

Lopputuloksena on Forth-kielen laajennettu versio, joka on viritetty tuon
ongelman ratkaisuun.
Samoin kuin ihmisen ratkaistua oman ongelmansa, hänellä on laajennettu ja
tehostettu käsitekoneisto myös sellaisten ongelmien ratkaisuun.

Epäilen että kehittäjä on vaistonvaraisesti kehitellyt itsessään tunnistamansa
tapahtumaketjun, eräät haastattelukommentit antavat ymmärtää näin.

Amerikkalaiset käyttävät yleisesti ilmaisua "in terms of", kun terms viittaa
käsitteisiin, kehittäjä on varmasti kuullut tämän ilmaisun useasti ja tunnistaa
käsitteiden roolin.

Lue lisää

"Ihmisen tiedonkäsittelyssä ja Forthin toiminnassa on huomattavia
samanlaisuutta, ehkä Forthin kehittäjä on intuitiivisesti matkinut
Forthissaan ihmistä."

Itseasiassa päin vastoin. Forth on pino orientoitunut kieli ja on käsitteellisesti paljon vaikeampi ihmiselle.

Pino-ohjelmointi ennemminkin matkii sitä miten tietokone käsittelee tietoa. Pino-ohjelmoinnin etu on se, että sellaista kieltä tietokoneen on yksinkertaista tulkita ja generoida mutta ohjelmoinnissa se on yleensä aina huono ratkaisu koska lähdekoodia tulkitsee ensisijaisesti ihminen, ei kone.

Ihmisten tiedonkäsittelyä voi havainnoida parhaiten ihmisten keskenään käyttämässä kielessä. Näissä toistuu vahvana: subjekti - predikaatti - objekti

Toinen ihmisen tiedonkäsittelyyn kuuluva ominaisuus on käsittely symboleina. Se näkyy kirjoitetuksessa jossa jokainen merkki on symboli. Tuota voidaan hyödyntää tekemällä DSL:ää visualisesti helposti hahmoitettavana. Ohjelmointi on useinkin visuaalista vaikka se olisi tekstipohjaista, että IDE:t korostavat väreillä ja käytetään sisennystä havainnollistamaan rakennetta.

"Jos ei, niin hän alkaa rakentamaan tarvittavia käsitteitä,
tämä vaihe voi kestää vuosikaupalla."

No ei vie. Kysehän on käytännössä nimen keksimisestä. Jatkuvasti ohjelmoidessa tehdään uusia käsitteitä ja itse useinkin ohjelmoin käsitteen ensiksi ja nimeän sen vaikka perseeksi jos ei sopivampaa ole, ja keksin ymmärrettävän nimeämisen myöhemmin.

Anonyymi kirjoitti:

"Ihmisen tiedonkäsittelyssä ja Forthin toiminnassa on huomattavia
samanlaisuutta, ehkä Forthin kehittäjä on intuitiivisesti matkinut
Forthissaan ihmistä."

Itseasiassa päin vastoin. Forth on pino orientoitunut kieli ja on käsitteellisesti paljon vaikeampi ihmiselle.

Pino-ohjelmointi ennemminkin matkii sitä miten tietokone käsittelee tietoa. Pino-ohjelmoinnin etu on se, että sellaista kieltä tietokoneen on yksinkertaista tulkita ja generoida mutta ohjelmoinnissa se on yleensä aina huono ratkaisu koska lähdekoodia tulkitsee ensisijaisesti ihminen, ei kone.

Ihmisten tiedonkäsittelyä voi havainnoida parhaiten ihmisten keskenään käyttämässä kielessä. Näissä toistuu vahvana: subjekti - predikaatti - objekti

Toinen ihmisen tiedonkäsittelyyn kuuluva ominaisuus on käsittely symboleina. Se näkyy kirjoitetuksessa jossa jokainen merkki on symboli. Tuota voidaan hyödyntää tekemällä DSL:ää visualisesti helposti hahmoitettavana. Ohjelmointi on useinkin visuaalista vaikka se olisi tekstipohjaista, että IDE:t korostavat väreillä ja käytetään sisennystä havainnollistamaan rakennetta.

"Jos ei, niin hän alkaa rakentamaan tarvittavia käsitteitä,
tämä vaihe voi kestää vuosikaupalla."

No ei vie. Kysehän on käytännössä nimen keksimisestä. Jatkuvasti ohjelmoidessa tehdään uusia käsitteitä ja itse useinkin ohjelmoin käsitteen ensiksi ja nimeän sen vaikka perseeksi jos ei sopivampaa ole, ja keksin ymmärrettävän nimeämisen myöhemmin.

Lue lisää

"Itseasiassa päin vastoin. Forth on pino orientoitunut kieli ja on käsitteellisesti paljon
vaikeampi ihmiselle.
Pino-ohjelmointi ennemminkin matkii sitä miten tietokone käsittelee tietoa. Pino-
ohjelmoinnin etu on se, että sellaista kieltä tietokoneen on yksinkertaista tulkita ja
generoida mutta ohjelmoinnissa se on yleensä aina huono ratkaisu koska
lähdekoodia tulkitsee ensisijaisesti ihminen, ei kone."

Niin, jotkut kääntäjät käyttävät pinomuistia kääntäessään, mutta piilottavat
sen ohjelmoijalta. Pinokoneissa parametriliikenne menee pinon kautta, se
on näkyvissä ja yksinkertaistaa ohjelman tekoa.
Forth ohjelmoija rakentaa moduleita/sanoja ja huolehtii sanojen välisestä
viestinnästä, pinoliikenne on hyvin yksinkertaista ja erittäin helppo testata.

Pinokielten syntaksi on erittäin yksinkertaista, kääntäjä on joustava,
ohjelmoija tekee vain käsitteiden välisen viestien vaihdon pinon kautta
ja testaa helposti että pinoliikenne toimii.
Kun ohjelman faktoroi oikein, eikä kasvata moduleiden/sanojen kokoa
liian suureksi, pinoliikenne pysyy yksinkertaisena.

Ei se ole mutkikasta, jos sen oppii oppimisvaikeudesta kärsivä lapsi,
niin tavallinen aikuinen myös, se on vain tavallisesta eroava tapa
tehdä ohjelmia ja testata niitä.

"Ihmisten tiedonkäsittelyä voi havainnoida parhaiten ihmisten keskenään
käyttämässä kielessä. Näissä toistuu vahvana: subjekti - predikaatti - objekti"

Niin, tuo kuuluu kielen syntaksiin, mutta ei käsitteiden ominaisuuksiin, kun
sanoin että käsitteiden rakentaminen voi kestää vuosikaupalla, tarkoitin
ihmisen omia käsitteitä, että niiden ohjelmointi kestää kauan, en tietokoneen
ohjelmoinnista, jos sitä tekee työkseen, on syytä olla jossain määrin tehokas.

Yksi hassu ero tavallisissa kielissä ja pinokielissä on ohjelman vuokaavio,
tavallisesti kaavio muodostuu laatikoista, jotka on viivoilla ja nuolilla
kytketty yhteen. Forth-ohjelmoijat eivät tavallisesti tee näitä, vaan
omia pinoliikenteen kaavioita, jotka ovat tässä tapauksessa selvempiä.

" Ohjelmointi on useinkin visuaalista vaikka se olisi tekstipohjaista, että IDE:t
korostavat väreillä ja käytetään sisennystä havainnollistamaan rakennetta."

Olen joskus käyttänyt niitä, kun koodin faktorointi on kohdallaan, ei
sisennyksiäkään tarvita, koodin tekee vaikka notepadillä. Kaarisulkeita
tai aaltosulkeita ei oikeastaan tarvita kuin ehkä kommenteissa ja sanojen
nimissä. Hakasulkeita joissakin kääntäjän moduleiden nimissä.

Anonyymi kirjoitti:

"Itseasiassa päin vastoin. Forth on pino orientoitunut kieli ja on käsitteellisesti paljon
vaikeampi ihmiselle.
Pino-ohjelmointi ennemminkin matkii sitä miten tietokone käsittelee tietoa. Pino-
ohjelmoinnin etu on se, että sellaista kieltä tietokoneen on yksinkertaista tulkita ja
generoida mutta ohjelmoinnissa se on yleensä aina huono ratkaisu koska
lähdekoodia tulkitsee ensisijaisesti ihminen, ei kone."

Niin, jotkut kääntäjät käyttävät pinomuistia kääntäessään, mutta piilottavat
sen ohjelmoijalta. Pinokoneissa parametriliikenne menee pinon kautta, se
on näkyvissä ja yksinkertaistaa ohjelman tekoa.
Forth ohjelmoija rakentaa moduleita/sanoja ja huolehtii sanojen välisestä
viestinnästä, pinoliikenne on hyvin yksinkertaista ja erittäin helppo testata.

Pinokielten syntaksi on erittäin yksinkertaista, kääntäjä on joustava,
ohjelmoija tekee vain käsitteiden välisen viestien vaihdon pinon kautta
ja testaa helposti että pinoliikenne toimii.
Kun ohjelman faktoroi oikein, eikä kasvata moduleiden/sanojen kokoa
liian suureksi, pinoliikenne pysyy yksinkertaisena.

Ei se ole mutkikasta, jos sen oppii oppimisvaikeudesta kärsivä lapsi,
niin tavallinen aikuinen myös, se on vain tavallisesta eroava tapa
tehdä ohjelmia ja testata niitä.

"Ihmisten tiedonkäsittelyä voi havainnoida parhaiten ihmisten keskenään
käyttämässä kielessä. Näissä toistuu vahvana: subjekti - predikaatti - objekti"

Niin, tuo kuuluu kielen syntaksiin, mutta ei käsitteiden ominaisuuksiin, kun
sanoin että käsitteiden rakentaminen voi kestää vuosikaupalla, tarkoitin
ihmisen omia käsitteitä, että niiden ohjelmointi kestää kauan, en tietokoneen
ohjelmoinnista, jos sitä tekee työkseen, on syytä olla jossain määrin tehokas.

Yksi hassu ero tavallisissa kielissä ja pinokielissä on ohjelman vuokaavio,
tavallisesti kaavio muodostuu laatikoista, jotka on viivoilla ja nuolilla
kytketty yhteen. Forth-ohjelmoijat eivät tavallisesti tee näitä, vaan
omia pinoliikenteen kaavioita, jotka ovat tässä tapauksessa selvempiä.

" Ohjelmointi on useinkin visuaalista vaikka se olisi tekstipohjaista, että IDE:t
korostavat väreillä ja käytetään sisennystä havainnollistamaan rakennetta."

Olen joskus käyttänyt niitä, kun koodin faktorointi on kohdallaan, ei
sisennyksiäkään tarvita, koodin tekee vaikka notepadillä. Kaarisulkeita
tai aaltosulkeita ei oikeastaan tarvita kuin ehkä kommenteissa ja sanojen
nimissä. Hakasulkeita joissakin kääntäjän moduleiden nimissä.

Lue lisää

"Pinokoneissa parametriliikenne menee pinon kautta, se
on näkyvissä ja yksinkertaistaa ohjelman tekoa."

No ei yksinkertaista, koska ihminen ei käytä pinoa kommunikoidessaan. Jotkut eläimet voivat käyttää pinon kaltaista rakennetta viestinnässä mutta ihminen käytännössä ei.

"Forth ohjelmoija rakentaa moduleita/sanoja ja huolehtii sanojen välisestä
viestinnästä, pinoliikenne on hyvin yksinkertaista ja erittäin helppo testata."

Itseasiassa ei, siinä on sivuvaikutuksena se itse pino joka tallentaa tilaa. Siitä voidaa push tai pull enemmän kuin mitä pitäisi.

Testauksen kannalta yksinkertaisinta on puhtaat funktiot, niissä ei ole sivuvaikutuksia. Seuraavaksi yksinkertaisin tapa on joku monadi tai pipe-filter, jolloin ainoa sivuvaikutus on järjestys missä funktioita kutsutaan. Laadukassa koodissa voidaan siis eristää sivuvaikutuksia tällä tavoin.

"Kun ohjelman faktoroi oikein, eikä kasvata moduleiden/sanojen kokoa
liian suureksi, pinoliikenne pysyy yksinkertaisena."

Mutta senkin voi poistaa kuormittamasta ihmistä joka lukee koodia.

"Niin, tuo kuuluu kielen syntaksiin, mutta ei käsitteiden ominaisuuksiin, kun
sanoin että käsitteiden rakentaminen voi kestää vuosikaupalla, tarkoitin
ihmisen omia käsitteitä, että niiden ohjelmointi kestää kauan, en tietokoneen
ohjelmoinnista, jos sitä tekee työkseen, on syytä olla jossain määrin tehokas."

Nyt en oikein ymmärtänyt, että kerrotko esimerkin?

"Yksi hassu ero tavallisissa kielissä ja pinokielissä on ohjelman vuokaavio,
tavallisesti kaavio muodostuu laatikoista, jotka on viivoilla ja nuolilla
kytketty yhteen. Forth-ohjelmoijat eivät tavallisesti tee näitä, vaan
omia pinoliikenteen kaavioita, jotka ovat tässä tapauksessa selvempiä."

Ei näitä oikein tehdä kun jos on paljon haarautumia, se kertoo siitä että se on huono. Kaavioiden piirtäminen on lähes aina ajanhukkaa.

"Olen joskus käyttänyt niitä, kun koodin faktorointi on kohdallaan, ei
sisennyksiäkään tarvita, koodin tekee vaikka notepadillä."

Värikorostus on ihan ehdoton.

Anonyymi kirjoitti:

"Pinokoneissa parametriliikenne menee pinon kautta, se
on näkyvissä ja yksinkertaistaa ohjelman tekoa."

No ei yksinkertaista, koska ihminen ei käytä pinoa kommunikoidessaan. Jotkut eläimet voivat käyttää pinon kaltaista rakennetta viestinnässä mutta ihminen käytännössä ei.

"Forth ohjelmoija rakentaa moduleita/sanoja ja huolehtii sanojen välisestä
viestinnästä, pinoliikenne on hyvin yksinkertaista ja erittäin helppo testata."

Itseasiassa ei, siinä on sivuvaikutuksena se itse pino joka tallentaa tilaa. Siitä voidaa push tai pull enemmän kuin mitä pitäisi.

Testauksen kannalta yksinkertaisinta on puhtaat funktiot, niissä ei ole sivuvaikutuksia. Seuraavaksi yksinkertaisin tapa on joku monadi tai pipe-filter, jolloin ainoa sivuvaikutus on järjestys missä funktioita kutsutaan. Laadukassa koodissa voidaan siis eristää sivuvaikutuksia tällä tavoin.

"Kun ohjelman faktoroi oikein, eikä kasvata moduleiden/sanojen kokoa
liian suureksi, pinoliikenne pysyy yksinkertaisena."

Mutta senkin voi poistaa kuormittamasta ihmistä joka lukee koodia.

"Niin, tuo kuuluu kielen syntaksiin, mutta ei käsitteiden ominaisuuksiin, kun
sanoin että käsitteiden rakentaminen voi kestää vuosikaupalla, tarkoitin
ihmisen omia käsitteitä, että niiden ohjelmointi kestää kauan, en tietokoneen
ohjelmoinnista, jos sitä tekee työkseen, on syytä olla jossain määrin tehokas."

Nyt en oikein ymmärtänyt, että kerrotko esimerkin?

"Yksi hassu ero tavallisissa kielissä ja pinokielissä on ohjelman vuokaavio,
tavallisesti kaavio muodostuu laatikoista, jotka on viivoilla ja nuolilla
kytketty yhteen. Forth-ohjelmoijat eivät tavallisesti tee näitä, vaan
omia pinoliikenteen kaavioita, jotka ovat tässä tapauksessa selvempiä."

Ei näitä oikein tehdä kun jos on paljon haarautumia, se kertoo siitä että se on huono. Kaavioiden piirtäminen on lähes aina ajanhukkaa.

"Olen joskus käyttänyt niitä, kun koodin faktorointi on kohdallaan, ei
sisennyksiäkään tarvita, koodin tekee vaikka notepadillä."

Värikorostus on ihan ehdoton.

Lue lisää

""Niin, tuo kuuluu kielen syntaksiin, mutta ei käsitteiden ominaisuuksiin, kun
sanoin että käsitteiden rakentaminen voi kestää vuosikaupalla, tarkoitin
ihmisen omia käsitteitä, että niiden ohjelmointi kestää kauan, en tietokoneen
ohjelmoinnista, jos sitä tekee työkseen, on syytä olla jossain määrin tehokas.""

"Nyt en oikein ymmärtänyt, että kerrotko esimerkin?"

Tuo on hyvä kysymys, aihe on mielenkiintoinen, mutta ei sitä tällä palstalla
voi käsitellä.

Jos kiinnostaa, lähetä jotain millä saan sähköpostiyhteyden, sen kautta
voisi yrittää.

Anonyymi kirjoitti:

""Niin, tuo kuuluu kielen syntaksiin, mutta ei käsitteiden ominaisuuksiin, kun
sanoin että käsitteiden rakentaminen voi kestää vuosikaupalla, tarkoitin
ihmisen omia käsitteitä, että niiden ohjelmointi kestää kauan, en tietokoneen
ohjelmoinnista, jos sitä tekee työkseen, on syytä olla jossain määrin tehokas.""

"Nyt en oikein ymmärtänyt, että kerrotko esimerkin?"

Tuo on hyvä kysymys, aihe on mielenkiintoinen, mutta ei sitä tällä palstalla
voi käsitellä.

Jos kiinnostaa, lähetä jotain millä saan sähköpostiyhteyden, sen kautta
voisi yrittää.

Lue lisää

Osaakohan teistä kumpikaan ohjelmoida yhtään mitään millään kielellä, on meinaan sellaista sönkkäämistä, josta paistaa läpi ettei keskustelijoilla ole minkäänlaista käsitystä asiasta.

Anonyymi kirjoitti:

Osaakohan teistä kumpikaan ohjelmoida yhtään mitään millään kielellä, on meinaan sellaista sönkkäämistä, josta paistaa läpi ettei keskustelijoilla ole minkäänlaista käsitystä asiasta.

Lue lisää

Jos haluaa kritisoida, niin voisi hiukan täsmentää.

Anonyymi kirjoitti:

""Niin, tuo kuuluu kielen syntaksiin, mutta ei käsitteiden ominaisuuksiin, kun
sanoin että käsitteiden rakentaminen voi kestää vuosikaupalla, tarkoitin
ihmisen omia käsitteitä, että niiden ohjelmointi kestää kauan, en tietokoneen
ohjelmoinnista, jos sitä tekee työkseen, on syytä olla jossain määrin tehokas.""

"Nyt en oikein ymmärtänyt, että kerrotko esimerkin?"

Tuo on hyvä kysymys, aihe on mielenkiintoinen, mutta ei sitä tällä palstalla
voi käsitellä.

Jos kiinnostaa, lähetä jotain millä saan sähköpostiyhteyden, sen kautta
voisi yrittää.

Lue lisää

En keksi miten saisin rekisteröimättämänä anonyymisti kerrottua anonyymille henkilökohtaisen sähköpostiosoitteeni niin että se ei vuoda ulkopuolisille.

Anonyymi kirjoitti:

En keksi miten saisin rekisteröimättämänä anonyymisti kerrottua anonyymille henkilökohtaisen sähköpostiosoitteeni niin että se ei vuoda ulkopuolisille.

Tässä olisi pari vaihtoehtoa.

1. Aloitetaan uusi keskustelum, otsikolla "käsitteet ja ohjelmointi"
tai filosofiapalstalla "Käsitteet", siellä se olisi aika tavallista.

2. Tehdään lyhytaikainen postilaatikko, johon voi lähettää sähköpostin..
Kirjoitettuna niin ettei systeemi tunnista sitä osoitteeksi.
Ongelma voi olla ettei palsta julkista osoitetta, se pitäisi koodata jotenkin.
Kuten !matti,!muikero!@@!luukku.@fi
tai forthkoodina:
matti @ mulkero ! 2 @ luukku . dup fi !
Tuo käy lähes forthkoodista.

Jos on rekisteröitynyt, välittääkö Suomi24 toiselle pyynnöstä osoitteen?

Anonyymi kirjoitti:

Tässä olisi pari vaihtoehtoa.

1. Aloitetaan uusi keskustelum, otsikolla "käsitteet ja ohjelmointi"
tai filosofiapalstalla "Käsitteet", siellä se olisi aika tavallista.

2. Tehdään lyhytaikainen postilaatikko, johon voi lähettää sähköpostin..
Kirjoitettuna niin ettei systeemi tunnista sitä osoitteeksi.
Ongelma voi olla ettei palsta julkista osoitetta, se pitäisi koodata jotenkin.
Kuten !matti,!muikero!@@!luukku.@fi
tai forthkoodina:
matti @ mulkero ! 2 @ luukku . dup fi !
Tuo käy lähes forthkoodista.

Jos on rekisteröitynyt, välittääkö Suomi24 toiselle pyynnöstä osoitteen?

Lue lisää

Ehkäpä se vaihtoehto 1. olisi helpompi.

Anonyymi kirjoitti:

Ehkäpä se vaihtoehto 1. olisi helpompi.

Joo, aloita keskustelu, filosofiaosasto olisi luonteva, tosin joitakin voi tulla
väliin saarnaamaan.

Anonyymi kirjoitti:

Joo, aloita keskustelu, filosofiaosasto olisi luonteva, tosin joitakin voi tulla
väliin saarnaamaan.

Nimimerkki voisi olla hyvä, tunnistusta varten.

Puhelimiin on saatavissa HP-laskimien emulointia/simulointia.