Keskustelu: Projektit: Staattinen syntax translater hybridikielille

Olen jonkin aikaa pohtinut sitä, että miksi eri ohjelmointikielillä on eri syntaksia samaan toiminallisuuteen, kuten esimerkiksi auto vs let tai def fun_name vs fun_name.

No sitten ajattelin, että eikö olisi kivaa, jos voisi kirjoittaa eri abstraktion kieliä samantyyppisellä syntaksilla.

Esimerkiksi:

C++:

return_type function_name( parameter list ) {
   body of the function;
   return val_of_return_type;
}

ja Python:

def function_name( parameter list ):
    body of the function
    return val_of_some_type

Yhdistettäisiin siten, että C++ pysyy samana, mutta "C++-Python:ia" voisi kirjoittaa:

function_name( parameter list )
    body of the function
    return val_of_some_type

Tämä on käytännössä suurinpiirtein C++:n ja Python:n leikkaus (intersection).

Näin Python:iin siirryttessä oleellista on, että bracketit poistuivat ja whitespace on käytössä sekä että return antaa palauttaa mitä tyyppiä vain, koska Python on dynaaminen. "def" (ja semicolonit) tulkittiin redundantiksi syntaksiksi, ja ilman sitä Python muistuttaa enemmän C++:aa, mutta muutettuna "oleellisin osin", jotta Python:in edut näkyvät.

Joku varmaan yrittäisi tälle jotain tulkkeja tms., mutta ajattelin, että miksi tämmöistä ei voisi toteuttaa staattisena analysaattorina, jolle vaan annetaan sinun hybridikieliset tiedostot ja joka lisää tai poistaa syntaksia. Eli kun C++-Python -ohjelma annetaan sille, niin se osaisi lisätä snippetiin def:n, jotta koodi kääntyy nykyisillä Python-kääntäjillä.

---

Yleisiä vasta-argumentteja:

"Tämä pilaa kielen X puhtaan syntaksin"

Koska kaikilla kielillä on omasta mielestään paras ja puhtain syntaksi ja silti kielet eivät ole samalla syntaksilla, niin parhaaksi voi mieltää myös näiden kaikkien yhdistelmän tai leikkauksen, erityisesti sekakielisissä projekteissa.

Yksi kompastuskivi voi olla, että esim. "def" ei ole oikeasti ihmisille tarkoitettu, vaan sen funktio on signaloida kääntäjälle/tulkille, että mikä on funktion määritelmä ja mikä on jotain muuta.

Tällöinkin tietysti sen voisi lisätä koneellisesti, mutta on eri asia, että voiko kirjoittaa sellaista analysaattoria, joka osaa tunnistaa paikat "def":lle.

Naiivisti oletan, että esim.:

function_name( parameter list )
    body of the function
    return val_of_some_type

sekoittuu ekalla rivillä funktiokutsuun, joten sen selvittäminen funktioksi vaatii whitespacen tulkkaamisen ja lopun "return"-lauseen löytämisen.

Toisaalta tälle voisi ehkä tehdä jonkin metakielen, jossa funktio-block merkataan kaikissa muokattavissa kielissä esimerkiksi:

#function

#/function

tai

#begin function

#end function

Eli esimerkiksi:

#function
function_name( parameter list )
    body of the function
    return val_of_some_type
#/function

Nyt ensimmäisen rivin (ellei se ole kommentti) on pakko olla funktion määritelmä.

Java:ssa esim.:

#function[public]
int function_name(int a) {
  body of the function;
  return val_of_int;
}
#/function[public]

Tässä huomattiin, että kun eri kielissä on myös eri syntaksi scopeille. Muilta osin tämähän näyttää C/C++:lta.

Ihanko tosissasi meinaat, että joku kirjoittaa mielummin:

#function
...
#/function

Meinaatko, että tuo säästää paljonkin aikaa sen sijaan, että vaan kirjoittaisi sanan "def"? ;D

En muutenkaan ymmärrä fetissiäsi C:n syntaksiin.

jalski kirjoitti:

Ihanko tosissasi meinaat, että joku kirjoittaa mielummin:

#function
...
#/function

Meinaatko, että tuo säästää paljonkin aikaa sen sijaan, että vaan kirjoittaisi sanan "def"? ;D

Arvasin, että joku tarttuu tuohon, mutta ohitit sen, että metakieli on sama _kaikille kielille_. Se siis poistaa tarpeen muistaa se, miten eri kielissä tehdään ko. asia, ja antaa käyttää kaikille kielille yhtenäistä syntaksia. Kirjoitamme siis kaikissa hybridikielissä #function ja #/function.

Joudut ehkä kirjoittamaan joissain tapauksissa enemmän merkkejä, mutta säästät sen, ettei sinun tarvitse muistaa kunkin kielen omaa tapaa tehdä ko. asia, vaan riittää, että muistat metakielen ja "C-variantin", joka on usein helppo päätellä.

jalski kirjoitti:

En muutenkaan ymmärrä fetissiäsi C:n syntaksiin.

Se on suurin yhteinen nimittäjä. Esimerkiksi Python:in helppo muokattavuus hybridikieleksi on osoitus tästä.

Tietysti hybridikieliä voi tällä tehdä myös muihin suuntiin, mutta ajattelin, että C/C++:n ollessa melkein kaikessa alin nimittäjä projektin päätavoite olisi sen säilyttäminen ylemmän abstraktion kieliin.

Näin saamme esimerkiksi stackista:

C/C++ - Java - Python - JavaScript

variantin

C/C++ - "C++-Java" - "C++-Python" - "C++-JavaScript"

Ja koska kyseessä on staattinen analyysi, niin mihinkään nykyisiin kääntäjiin tms. ei tarvitse koskea.

mavavilj kirjoitti:

Se on suurin yhteinen nimittäjä. Esimerkiksi Python:in helppo muokattavuus hybridikieleksi on osoitus tästä.

Miksi ihmeessä Python kehittäjä haluaisi vaihtaa ilmaisukykyisemmän ohjelmointikielen syntaksin C:n kankeaan syntaksiin?

jalski kirjoitti:

mavavilj kirjoitti:

Se on suurin yhteinen nimittäjä. Esimerkiksi Python:in helppo muokattavuus hybridikieleksi on osoitus tästä.

Miksi ihmeessä Python kehittäjä haluaisi vaihtaa ilmaisukykyisemmän ohjelmointikielen syntaksin C:n kankeaan syntaksiin?

Syy tämän projekti-idean postaamiseen oli saada tämä näkemys. Ymmärrän sen, että Python-syntaksilla on arvoa pelkästään Python-kehittäjille, eikä tämä projekti muutakaan sitä lainkaan.

Projekti vaan kysyy sitä, että onko hybridikielistä arvoa "sekakieli"-devaajille. Niiden etu on, että tällöin kaikki kielet näyttävät oleellisilta osiltaan samalta ja oleellisilta parannuksiltaan erilaisilta, riippumatta siitä, että millä ne käännetään. Tämä on kuin Java:n WORA; mutta sovellettuna eri asiaan. Learn Once Write Anything tai Write Once Be Anything, kun huomataan, että esim. staattisesti tyypitetystä metakieliohjelmasta pääsee helposti dynaamiseen vaan muuttamalla tyypit.

Esimerkiksi "C++-Python" -syntaksiin pääsee muistamalla, että "Python on dynaaminen ja siinä käytetään whitespacea lukemisen helpottamiseksi" (<- oleelliset parannukset), kaikki muu säilyy. Ei tarvitse muistaa, että miten se funktio määriteltiin yms.

Suurimman osan ohjelmointikielten syntakseista oppii viikonlopussa sille tasolle, että pystyy sillä työskentelemään.

Miten esimerkiksi miettimäsi hybridi syntaksi suoriutuisi seuraavasta PL/I-ohjelmointikielellä mahdollisesta toistorakenteesta?

do k = 1 to 10, 9 to 1 by -1, 2 repeat 2*i while (i <= 1024);
   ...
end;

jalski kirjoitti:

(02.04.2024 13:53:37): Suurimman osan ohjel­moin­ti­kielten...

Avaa ensin, miten tuo jäsentyy, koska en osaa PL/I-kieltä. Lisäksi minusta täällä ei ole tuota konstruktiota: https://www.ibm.com/docs/en/wdfrhcw/1.4.0?topic­=commands-do-command-pli

Onko esim. k:ta kaksi muuttujaa? Onko se tuple vai jotain muuta?

Suoritetaanko do ennen repeat:ia? Ovatko ne itsenäisiä?

Oleellista on, että tuolle pitäisi muotoilla vastaava C/C++ -looppi, ja miettiä, että voiko sen ja tuon yhdistää.

Tämä tosin alleviivaa esimerkin, että kaikissa tapauksissa hybridikielestä ei välttämättä ole etua. Siitä voi olla etua "sekakieli"-projekteissa, mutta PL/I ei näytä siltä, että sitä edes käytettäisiin C-kielten kanssa.

Metakieli tosin antaisi tehdä myös toisinpäin. Eli jos esimerkiksi mielestäsi PL/I:n syntaksi tuohon kyseiseen kohtaan on parempi, niin voisit käyttää tuota osaa C++-ohjelmassa. Analysaattori vaihtaisi PL/I -loopin C++ -loopiksi.

Metakielen voitto on siis sama kuin DSL:ien yleensä. Mutta se painottaa sitä, että kaikkien käytettyjen kielien joukkojen leikkaus on samaa.

Minusta myös syntaksit oppii sinänsä nopeasti, mutta on haastavaa muistaa jokaisen kielen "nyansseja", jos käyttää monia kieliä.

Potentiaalisesti metakieli voisi helpottaa myös muita polkuja, kuten vaikkapa kääntäjien tehostamista yms.

Yksi keksimäni sovellusalue on Android-ohjelmointi niille, joiden pääasiallinen intressi on NDK, ja joiden rasitteena on Java SDK, jota he eivät sinänsä haluaisi käyttää.

Kyseisellä analysaattorilla olisi hypoteettisesti mahdollista kirjoittaa JNI:n Java-puoli "C++-Java:lla", joka ehkä toimisi "middle-ground":ina Androidilla oleville pääasiassa C/C++ -kehittäjille. Koska näitä kehittäjiä ei oikeasti kiinnosta Java:n syntaksi lainkaan.

Toimii toiseenkin suuntaan eli jos olet Java-ohjelmoija ja sinua rasittaa NDK:n C/C++ ja toivoisit, että sitä voisi tuottaa enemmän kuin Java:aa.

Myös WebView on vähän rasittava, koska jos JS:llä tekee jotain muuta kuin DOM:ia, niin ainakin itse toivon, että se muistuttaisi enemmän C:tä.

Staattisena analysaattorina tämä ei voi myöskään tuottaa käännösvirheitä, toisin kuin transpilerit.

Olen kuullut, että on tehty projekteja, missä kieleen on tehty erilaisia laajennuksia kommentteihin. Nämä sitten käännetään erillisellä ohjelmalla, joka tuottaa toimivaa ohjelmakoodia, jonka voi sitten kääntää tai ajaa. Katso https://trac.cc.jyu.fi/projects/comtest/wiki/ComTestInEnglish . Tuolla voi tehdä testejä koodille, mutta samaa ideaa voinee käyttää generoimaan koodia, joka on helposti muistettavaa. Kuulin myös ohjelmoijasta, joka on kuormittanut alkuperäisen kielen metodeja, jotta hän voi kirjoittaa omalla tyylillään ja tuottaa firman tyyliohjeen mukaista koodia.

Jos kielistä löytyy myös osia, jotka ovat samankaltaisia tai itse kielet ovat strukturaalisesti samankaltaisia, niin on mahdollista, että analysaattori voisi tehdä myös source-to-source -käännöksen, mikäli siis ainoat puuttuvat asiat molemmissa kielissä ovat sellaisia, jotka analysaattori lisää. Python <-> JS luulisi onnistuvan johonkin asti.

Muita käyttöesimerkkejä:

taulukot, listat ja vektorit yms. voitaisiin pakata yhden syntaksin alle, ja tuottaa analysaattorilla kohdekielen oikea syntaksi.

yleisille standardikirjastofunktioille voisi olla myös vain yksi syntaksi.

Tämä on vähän niinku https://haxe.org/, mutta ilman kääntämistä.

Potentiaalisesti tämänkaltainen työkalu on parempi kuin Haxe joissain tapauksissa, kuten:

"Generated source code tends to be rather verbose. The HelloWorldexample up above generated 15 lines of Python for what could be done in two, and 102 lines of C++."

https://peterfraedrich.medium.com/haxe-the-good-the-bad-and-the-ugly-bdb6bdbdb23e

Koska kuten ilmaistu:

class HelloWorld {

    public static function main() : Void {
        trace('Hello world!');
    }

}

Olisi metakielellä:

#class
HelloWorld {
#function[public,static]
    void main() {
        print('Hello world!');
    }
#/function
}
#/class

TJSP.

Josta voi päätellä, että C++ -versio (ja Java myös!) on itseasiassa täysin sama:

#class
HelloWorld {
#function[public,static]
    void main() {
        print('Hello world!');
    }
#/function
}
#/class

(ehkä string-tyypillä pitäisi tehdä jotain muutakin)

Joten esimerkiksi nyt ei tarvitsi tietää, miten Haxe/C++/Java käännetään tai suoritettaan, kun annettais vaan analysaattorin tehdä se.

Pythoniin täydennettäessä vähän hankaluuksia, kun tulisi:

class HelloWorld:
    @staticmethod
    def main(args):
        print("Hello world!")

mutta tämä ei vielä printaa mitään käännettäessä.

Optiona nähdään jo, että staattisesti tyypitetystä voidaan kääntää suoraan dynaamiseen (tyypit vain pudotetaan pois).

Erona kaikkiin muihin kieliin on, että metakieli itseasiassa sallii kirjoittaa samanaikaisesti staattisesti tyypitettyä ja dynaamisesti tyypitettyä kunhan ne muunnetaan niitä vastaaviin kieliin.

Näin metakielessä voidaan esimerkiksi kirjoittaa toisiinsa liittyvät asiat samaan tiedostoon ja samaan kohtaan ja toteuttaa käännökset vain ajoa varten.

Metakieli sallisi siis esimerkiksi C++:n ja Python:n sekoittamisen samassa tiedostossa, kunhan vastaavat tekstilohkot päätyvät .h/.cpp tai .py tiedostoiksi.

Tämän voi myös mieltää eräänlaiseksi semanttiseksi kieleksi, koska tämä "markupaa" kaikki yhteensopivat kielet siten, että niiden ohjelmista voi selvittää esimerkiksi funktioiden määrän yms.

https://www.ionos.ca/digitalguide/fileadmin/DigitalGuide/Schaubilder/semantic-web-with-its-semantic-components.png

Metakielessä on potentiaalisesti se etu, että se voidaan myös luoda mille sopivalle alustalle tahansa, mutta prototyyppi on metakielellä.

Metakielessä ei siis välttämättä tarvitse lyödä lukkoon tyypitystä.

Eräs laajempi ideani oli myös sallia GC ja non-GC -koodi samassa tiedostossa, mutta en ole varma onnistuuko tämä. Käytännössä kuitenkin jo C++:n ja Java:n (yllä jo näytettiin, että niiden Hello World -syntaksi on sama) saa joiltain osin samaan tiedostoon.

Mutta esim.:

#newobject
int Array arr = new Array(10);
#/newobject

voisi tuottaa sekä C:n int-arrayn tai Java:n vektorin.

Eli esimerkiksi C:n esimerkki:

int *arr = malloc(10 * sizeof(int));
...
free(array);

Tässä olisi jo vaikeutena kuitenkin tietää, mihin kohtaan lätkäistä free.

Java:

int arr[] = new int[10];

Tässä on nyt esimerkiksi se etu, että meidän ei tarvitse tietää, mikä konstruktio vastaa mitäkin, vaan voimme kirjoittaa new Vector, joka toteuttaa kohdekielen vektoriluokan tms.

Voisimme siten myös esimerkiksi valita haluamamme indeksoinnin, kunhan se on määritelty metakielessä.

arr[0]

vai

arr[1]

vai

arr.get(1)

vai

...

Metakieli siis sisällyttäisi myös 0-pohjaisen indeksoinnin vaihtamisen 1-pohjaiseen, mikä on usein toteutettu kirjastolla kohdekieleen.

Koska Haxe on avoimella lisenssillä, niin tämän voisi ehkä liittää sen osaksi, kuten:

https://haxe.org/manual/std.html

Haxe:lla on enemmänkin etuja kuin esim. Javalla.

Miksi koodin kirjoittamisen "tyylillä" on väliä? C++-koodia ei suoriteta sellaisenaan vaan se käännetään ensin käyttöjärjestelmän / suorittimen ymmärtämään muotoon. Python-koodiakaan ei suoriteta sellaisenaan vaan tulkki kääntää sen ensin tavukoodiksi.

Eikö olisi paljon mukavampaa, jos voisit kirjoittaa koodia millä kielellä tahansa, oman makusi mukaan, ja se toimisi yhdessä toisella kielellä kirjoitetun koodin kanssa? No ei tietenkään, koska sinähän inhoat JVM:ää.

muuskanuikku kirjoitti:

(05.04.2024 08:13:07): Miksi koodin kirjoit­ta­misen "tyylillä­" on...

Koska tämä pitäisi saada ilman virtuaalikonetta ja roskienkeruuta.

muuskanuikku kirjoitti:

Eikö olisi paljon mukavampaa, jos voisit kirjoittaa koodia millä kielellä tahansa, oman makusi mukaan, ja se toimisi yhdessä toisella kielellä kirjoitetun koodin kanssa? No ei tietenkään, koska sinähän inhoat JVM:ää.

No tämä oli tämän metakielen idea.

Mutta https://fusion-lang.org/ tulee lähelle. Siinä ei vaan voi valita syntaksia. Tai voi sinänsä. Siirtymällä kohdekielen lähdekoodiin.

Yllä olevan PL/I -esimerkin innoittamana ajattelin, että mitä jos haluaisi kirjoittaa:

#class
HelloWorld {
#function[public,static]
    void main() {
        #loop.PLI
        DO i = 1 REPEAT 2*i UNTIL (i = 256); END;
        #/loop.PLI
    }
#/function
}
#/class

Lisäksi keksin jo, että lukemisen helpottamiseksi #-lauseet pitäisi saada piilotettua halutessa. Jolloin tämä on:

HelloWorld {
    void main() {
        DO i = 1 REPEAT 2*i UNTIL (i = 256); END;
    }
}

Kysymys on, että mitä tuolla PL/I-lauseella pitäisi tehdä? Tuottaa siitä PL/I "moduuli", ajaa se ja antaa paluuarvo tälle ohjelmalle? Vai tulkata PL/I lause esim. C:ksi?

Fusion tai Haxe eivät ole kuten tämä muuten.

Haxe:ssa ongelmana on, että käännöksen tuottama lähdekoodi on lukukelvotonta, vaikka se toteuttaisikin toimivan ohjelman.

Fusion:ssa käännöksen tuottama koodi on luettavaa, mutta Fusion:n tarkoitus on tuottaa kirjastoja kohdekieliin, eikä olla ohjelmointikieli sinänsä. Lisäksi se sallii epätriviaalisti vaihtoehtoiset syntaksit.

Oman kielen suunnittelu ja toteuttaminen on todella opettavaista. Onnea matkaan.

jlaire kirjoitti:

Oman kielen suunnittelu ja toteuttaminen on todella opettavaista. Onnea matkaan.

En minä tätä sen takia pohtinut, vaan koska tämän tulisi olla helpompaa kuin esimerkiksi C/C++ + Java/Kotlin monikieliprojekti.

Myös olen jo todennut, että tämä on lopulta lyhyempää tai ei paljoa monisanaisempaa kuin esimerkiksi Ruby:n FFI-koodi:

floor = Fiddle::Function.new(
  libm['floor'],
  [Fiddle::TYPE_DOUBLE],
  Fiddle::TYPE_DOUBLE
)

Mutta FFI:tä käytelleenä olen sitä mieltä, että se, että monikielikoodista toteutetaan moduuleja on varmasti yksinkertaisempaa kuin FFI. Eli että esim. yo. PL/I rivi on PL/I-moduuli.

Tällöin ei tarvita esim. sitä wrapperi-koodia, eikä FFI:n infraa.

mavavilj kirjoitti:

Mutta FFI:tä käytelleenä olen sitä mieltä, että se, että monikielikoodista toteutetaan moduuleja on varmasti yksinkertaisempaa kuin FFI.

Nämähän ovat ratkaisemassa täysin eri ongelmaa, FFI on tarkoitettu valmiiden binäärimuodossa olevien vieraiden kirjastojen hödyntämiseen.

Esimerkiksi 8th:lla kirjoitin joskus minimaalisen tuen SDL2:n hyödyntämiseen ja sen render osassa oli:

ns: SDL

"PPN4U" "SDL_CreateRenderer" func: CreateRenderer
"NP" "SDL_RenderClear" func: RenderClear
"VP" "SDL_RenderPresent" func: RenderPresent
"NPPbb" "SDL_RenderCopy" func: RenderCopy
"VP" "SDL_DestroyRenderer" func: DestroyRenderer
"PPP" "SDL_CreateTextureFromSurface" func: CreateTextureFromSurface
"VP" "SDL_DestroyTexture" func: DestroyTexture
"NP1U1U1U1U" "SDL_SetRenderDrawColor" func: SetRenderDrawColor
"NPb" "SDL_RenderFillRect" func: RenderFillRect

\ Renderer flags
0x00000001 constant RENDERER_SOFTWARE
0x00000002 constant RENDERER_ACCELERATED
0x00000004 constant RENDERER_PRESENTVSYNC
0x00000008 constant RENDERER_TARGETTEXTURE

Kyllähän tuo helpompi on kertoa vaan kääntäjälle miten DLL tuontikirjastoja käsitellään kuin kirjoittaa koko kirjasto uusiksi toisella ohjelmointikielellä.

jalski kirjoitti:

(07.04.2024 13:31:54): ”– –” Nämähän ovat ratkai­se­massa täysin eri...

Nojaa?

Tämä illustroimani multikieli antaisi kirjoittaa koodin lähdekoodin kielessä, eikä tarvitsisi wrapata lähdekoodia "hostikieleen". Tarvittaisiin vain tyyppikonversio.

mavavilj kirjoitti:

jalski kirjoitti:

(07.04.2024 13:31:54): ”– –” Nämähän ovat ratkai­se­massa täysin eri...

Nojaa?

Tämä illustroimani multikieli antaisi kirjoittaa koodin lähdekoodin kielessä, eikä tarvitsisi wrapata lähdekoodia "hostikieleen". Tarvittaisiin vain tyyppikonversio.

Tässä tapauksessa olisi sitten ehkä parasta vain kirjoittaa kirjaston toiminnallisuus uusiksi yhdelle ohjelmointikielelle ja poistaa tarve useammalle ohjelmointikielelle.

jalski kirjoitti:

(07.04.2024 18:51:17): ”– –” Tässä tapauksessa olisi sitten ehkä parasta...

Niinhän voi tehdä muutenkin.

Ajattelin, että se olisi hedelmällistä vaan kyetä upottamaan lainattu koodi sen luontikielen idioomalla vieraskieliseen ohjelmaan, kuten C++ upottaa C:n. Näin voitaisiin kunnioittaa luontikieltä sellaisenaan ja hostikieliä sellaisenaan. Joskus wrappaaminen on sellainen "no ei me oikeasti haluttu tätä C:lle, joten wrapataanpa Java:lle".

Eikös tälle ole monessa kielessä tuki muutenkin? esim c# ja dllimport + extern:

[DllImport("CircleGPU2_32.DLL", EntryPoint = "Test",
    CallingConvention = CallingConvention.StdCall)]
public static extern int Test();

groovyb kirjoitti:

Eikös tälle ole monessa kielessä tuki muutenkin? esim c# ja dllimport + extern:

[DllImport("CircleGPU2_32.DLL", EntryPoint = "Test",
    CallingConvention = CallingConvention.StdCall)]
public static extern int Test();

Jaaha, no C# nyt on muutenkin ollut parempi kuin Java tai Ruby, mutta C#:sta ei ole alustatuen takia hyötyä.

Tämä ei ole Fusion:in tai Haxe:nkaan nykytilanteeseen liittyvä idea.

Täytyy sanoa että mulle tulee tästä viestiketjusta väkisinkin fiilis, että keksitään ratkaisu ja sitten mietitään että mihin ongelmaan.
Kielestä toiseen vaihtaminen on lopulta pienimpiä murheita mitä ohjelmoinnin saralla vastaan tulee.
Proseduraalisesta ohjelmoinnista olio ohjelmointiin hyppääminen oli kloppina toki haaste, mutta siinäkään haaste ei johtunut kielestä vaan siitä että piti muuttaa ajattelutapaa.

Lähtökohtaisesti on vaan erittäin typerää vaihtaa jo toimivaa syntaksia toiseen. Sitä paitsi Fusion ja Haxe on kehitetty nimenomaan sen takia, ettei tarvitsisi kirjoittaa jokaista syntaksia erikseen, ja erityisesti Haxe:lla on vahva käyttäjäkunta.

Huomasin myös, että esimerkiksi Svelte:ssä käytetään hieman samanlaista # ja / syntaksia.

Tajusin tänään, että ideani mukailee hieman Go:n design goal:ia.

Go tiputtaa C:stä puolipisteet yms. turhaa syntaksia.

Åäö

Joka päivä oppii jotain uutta. Itse opin, että jauhenlihaa kannattaa ostaa pakkaseen jemmaan, kun ne ovat 1.99e/paketti tarjouksessa (tänään hinta oli 3.49e).

mpni kirjoitti:

Joka päivä oppii jotain uutta. Itse opin, että jauhenlihaa kannattaa ostaa pakkaseen jemmaan, kun ne ovat 1.99e/paketti tarjouksessa (tänään hinta oli 3.49e).

Seuraavaksi tulet oppimaan, ettei viimeisen käyttöpäivän lihan pakastaminen ja syöminen kuukautta myöhemmin ollutkaan hyvä idea.

Joskus tajusin että Bentsojen ja viinan sekoitus sopivassa suhteessa on loistava idea; se suhde osoittautui olevan 0/1.

muuskanuikku kirjoitti:

Seuraavaksi tulet oppimaan, ettei viimeisen käyttöpäivän lihan pakastaminen ja syöminen kuukautta myöhemmin ollutkaan hyvä idea.

Olipas sittenkin

muuskanuikku kirjoitti:

(28.06.2024 07:11:06): ”– –” Seuraavaksi tulet oppimaan, ettei viimeisen...

Kyllä täällä on lihat jemmattu ihan hirvenlihasta lähtien ja hyvin on maistunut, mutta nyt pois offtopic-aiheesta.

Kannattaa opetella Lisp- ja/tai Forth-sukuisia kieliä jos C-sukuisten kielten triviaalit syntaksierot ärsyttävät ja DSL:t kiinnostavat.

Esim. Racket mainostaa ihan etusivullaan tukea uusien kielten määrittelyyn. Ehkä mavaviljin idea on tätä parempi, mutta vaikea sanoa, kun github-repossa ei vielä ole paljoa sisältöä. Kannattaa pushata lokaalit muutokset silloin tällöin.

En ole lukenut tätä kirjaa, mutta sopisi varmasti mavaviljille: https://beautifulracket.com/ :D

Common Lispin makroillakin voi tehdä vaikka mitä, esim. lisätä kieleen Haskell-tyylisiä ominaisuuksia: Coalton. Mavaviljin mukaan hyvät koodarit kirjoittavat esimerkiksi "Haskell-tyyppistä C++:aa", joten ehkä tämäkin on hyvä idea.