Van értelme egy új programozási nyelv kitalálásának és megvalósításának?

Srapnel:

Tudom, hogy igaza van abban, hogy nem ez a munka nagy része, amit példának felhoztam. De azért írtam le, mert ahhoz képest, hogy egy "semmire se jó" nyelv, még ez is munkával jár. Sőt az egyszerűségéhez mérten elég sokkal.

Ezek után naná hogy nem tetszik, hogy leugat.

"bisonc++ segítségével megírt fordító 600+ soros lett"

Nálam ez azt jelenti, hogy az írt kód lett annyi, nem pedig az, amit aztán a parser ebből generál. Mint ahogy a 100 soros c++/pascal/basic/stb. programnál sem a generált tárgykód mérete 100 sor, hanem az, amit a programozó megírt :)

Természetesen van értelme új programozási nyelv kitalálásának, hiszen az utóbbi években is számos nyelv jelent meg, pl. Google-től a Go vagy Dart, de ott vannak a JVM-re épülő nyelvek, mint a Scala, Groovy vagy Clojure, amiket már többé-kevésbé ipari projektekben is használnak. Ha jól tudom a Googlenak nem igazán jött össze a nyelveinek az elterjesztése, de nem is ez a lényeg. A Redhat egy Ceylon nevű nyelvet fejleszt.

Azt viszont fontos hozzátenni, hogy ezeket a nyelveket nem "csak úgy" alapon hozták létre, mert unatkoztak a készítők, hanem olyan elemeket tettek bele a nyelvekbe, amelyek bizonyos visszatérő problémákra adnak magasabb szintű eszközt, hogy kevesebbet kelljen kódolni és gyorsabban látható legyen a programozó szándéka.

Például Clojure-ben alapból vannak a párhuzamos programozást leegyszerűsítő konstrukciók, mint agent, future, promise, STM, atom. Mivel ugyanúgy a JVM-en fut, mint a Java, ezeket értelemszerűen Java-ban is mind meg lehet csinálni, de hosszabb, terjengősebb a kód, tovább tart értelmezni. A Clojure ezt nyelvi szinten támogatja, kevesebbet kell hozzájuk gépelni, a forráskód kompaktabb. De lehetne említeni Groovyból a GStrings-t, ami a stringkezelést könnyíti meg, vagy a GPath-t, ami a kollekciók feldolgozását segíti. Javaban az ekvivalens kód itt is hosszabb.