Millaisia kokemuksia, ensimmäinen tehokas kääntäjäni ohjelmoinnissa oli microsoftin quickC, huomatavan paljon nopeampi koodissaq kuin kilpailea ruboC :D
Milloin muuten tutustuitte ensimmäisen kerran tietokoneohjelmointiin?
Anonyymi
741530
0Äänestä
Muut lukivat myös
Ketjusta on poistettu 2 sääntöjenvastaista viestiä.
Odottaa vastausta
Näihin keskusteluihin ei ole vielä vastattu. Ole ensimmäinen.
Vastaukset 74
Vanhimmat
10-vuotiaana, kieli oli GW-BASIC, käyttöjärjestelmä MS-DOS ja tietokone 8086.
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ä.
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.
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.
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?
Ja hakusanalla "is assembler better than compiler" löytyy monia mielipiteitä.
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.
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.
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.
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.
Tuolla väänsin ensimmäinen "Terve mualima" softani :) Vaikka olihan tuo aika köpö.
https://en.wikipedia.org/wiki/Atari_ST_BASIC
Tämä oli jo sitten parempi, tähän siiryinkin jo aika nopeesti tuosta ST Basicista ja varmaan yksi syy siihen miksi tykästyin Delphiin aikoinaan :)
https://en.wikipedia.org/wiki/GFA_BASIC
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.
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.
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!
Eipä niihin törmää jos joku ohjelma ei niitä etsi. Ne haittaohjelmat ovat yleensä suunniteltu niin ettei käyttäjä "törmää".
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!
1970 luvulla ja kielenä olivat fortran ja cobol...
-70 luvun alkupuolella kävin yhden kurssin ja totesin ettei ole minun juttuni.
Ensimmäiseksi C64 Basicillä ja tuli perehdettyä assembleriin😀
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.
Kuten monet muut, olen käynyt linjan VIC-20, C64 ja Amiga.
VIC-20 oli alkeellinen, mutta Basicin pystyi sillä oppimaan.
C64 askel parempaan massamuistien kautta, vaikka Basic oli
vielä aika VIC-20 tyylinen.
Ohjelmointaitojen kasvessa tuli esille hiukan epämiellyttävä asia,
Basicilla ohjelmointi olikin Basic-orientoitunuta ongelman ratkaisua,
Ratkaise ongelma Basicin tyyliin tai et ollenkaan.
Siispä jätin assemblerin kokonaan väliin, assembler-orientoituminen
olisi ollut askel väärään suuntaan.
Siitä alkoi parempien kielien etsintä, Pascal jäi pois muodollisena ja
tiukkapipoisen kääntäjän takia. C oli toisen keksijänsä risuparran tapaan
kuin risuaitaa, C-orientoituminen ei sopinut etsimääni.
C64 omistajana olin tehnyt sprite-editorin Basicilla, toimi mutta aika hidas,
Sitten löysin uuden kielen, jonka manuaali oli täysin käsittämätön, manuaalin esittelyssä kieli lähestyi ohjelmointi ongelmaan täysin uudesta
näkökulmasta. Tämä kieli olikin ongelma-orientoitunut. Tein sillä
sprite-editorin uudestaan, sitten myöhemmin tein makroassemblerilla,
joka kuului kieleen, nopeuttavia osia vauhdin saamiseksi, kyseinen
makroassembler sopi kieleen kuin nenä naamaan.
Tästä kielestä en ollut kuullut aikaisemmin mitään, Pascalin ja C-ohjelmien
mainoksien täyttämistä lehdistä ei löytynyt merkkiäkään siitä.
Tämän kielen käyttäjiä, FORTH, ei ollut kovin paljon, yhteen aikaan
maailmassa oli vain yksi FORTHin käyttäjä, sen keksinyt, joka halusi
tehdä parempia ohjelmia, freelancer ohjelmoija kun oli.
Nykyisin teen quick-and-dirty jutut Basicilla, tietyt taulukkolaskennalla,
mielenkiintoiset ja erikoiset joillain kolmesta FORTH ohjelmastani ja
erikoiset nopeustestit ja kokeet erittäin nopeaa koodia tuottavalla
VFX FORTH:lla.
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.
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.
Käsitämmekö dirty-sanan eri tavalla ?
Mikä olisi kätevämpi vai pitäisikö sanoa dirtympi tapa??
"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.
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.
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.
Kehuit juuri Basicin Quick-and-dirty sopivaksi kieleksi.
Kieliä on joka lähtöön ja lisää tulee, paskakasat vain kasvavat.
"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.
"Kehuit juuri Basicin Quick-and-dirty sopivaksi kieleksi."
En kehunut. Paska se on, koska löytyy joka mittapuulla parempia työkaluja.
"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"
"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.
"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.
Ei toimi.
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.
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??
Kopioiko selaimesi oikein minun forthkoodin?
Ei siinä pitäisi C-ohjelma käynnistyä, tarkista selaimesi kopio muisti
että siellä on vain minun forthkoodi.
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".
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ä?
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.
Ei kukaan varmaan ja Windowsiin en kyllä koodaa enään yhtään mitään!
Se varasti koodiani!
Ei nykymailmaassa kannata kaikkia itse kirjoittaa, valmiita pätkiä on lähes joka asiaan! Vapaana koodina!
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.
Käyttääkös kukaan enää Lispiä?
Clojuren muodossa sitä käytetään paljonkin.
Keskustelussa on mainittu monia kieliä, joista voi löytää mieleisensä.
Kuka muu voisi antaa paremman näkemyksen kieleen ja ohjelmointiin
kuin sen kehittänyt henkilö.
Tuossa linkissä on useiden käytössä olevien kielien kehittäjien
näkemyksiä kehittämästään kielestä ja muistakin kielistä.
Muista poikkeavan kielen kehittänyt Chuck Moore, jonka Forth
antaa uuden näkemyksen ohjelmointiin. Suosittelen.
https://ia802700.us.archive.org/21/items/MastermindsOfProgramming/Masterminds of Programming.pdf
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.
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.
"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.
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.
"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.
"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.
"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.
"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ä.
"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.
""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ää.
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.
Jos haluaa kritisoida, niin voisi hiukan täsmentää.
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?
Ehkäpä se vaihtoehto 1. olisi helpompi.
Joo, aloita keskustelu, filosofiaosasto olisi luonteva, tosin joitakin voi tulla
väliin saarnaamaan.
Nimimerkki voisi olla hyvä, tunnistusta varten.
CP/M käyttöjärjestelmässä oli Fortran kääntäjä.
Ensimmäinen kokemus oli C-64 basic, sen jälkeen AmigaBasic ja C sekä pascal uusille urille siivitti pc i186 gbasic, konekanta kehittyi 286 ja borland turbo C sekä turbo pascal siitä delphiin, c tuli opeteltua, tykkään enemmän delphistä ja kymppi versioon on jäänyt windows sekä linux mint alustalla, sen enempää en nyt tarvi, toki kone kanta on nyt pari vuotta vanha enkä tarvi enempää uutta ja ihmeellistä vääntöä. Maailmalla on nyt niin paljon freewarea ettei mun kannata enää keksiä pyörää.
80-luvun lopussa HP:n RPN-laskimella, kielenä oli RPL, Reverse Polish Lisp, eli Forthin ja Lispin risteytys.
https://en.wikipedia.org/wiki/RPL_(programming_language)
Sääli, ettei aitoja RPN-laskimia enää valmisteta. HP Prime ei ole sellainen.
Puhelimiin on saatavissa HP-laskimien emulointia/simulointia.
Minun ensimmäinen ohjelmointikieleni oli C#, eli olen ilmeisesti tämän keskustelun kommentaattoreiden nuorempaa sukupolvea.
Opiskelin ensin useamman vuoden matematiikkaa ennen IT-tiedekuntaan loikkaamista ja ohjelmointiharrastuksen aloittamista, ja voin suositella tuota polkua muillekin, jotka tätä alaa harkitsevat. On nimittäin helppoa opiskella ohjelmointia, kun algoritminen ajattelu ja looginen ongelmanratkaisu on jo juurtunut alitajuntaan. Sitten riittää opetella syntaksi.
Ensimmäinen livenä nähty toimiva tietokoneohjelma oli kahden luvun yhteenlasku Apple II:n Basicilla.
Ensimmäinen itse tehty ohjelma oli jokin samanlainen Data-Generalin Eclipsellä. Se hakattiin sisään Teletype päätteeltä.
Olin jotain 8 vuotta kun hakkasin Spectravideon Bacikkia..
Ensin muuttelin valmiita ohjelmia ja myöhemmin tein niitä itse.