61
Vývoj / Re:Investor pro C++ IDE
« kdy: 13. 09. 2021, 21:16:35 »Asi jsem se vyjádřil špatně, protože jste mě pochopil úplně opačně, než jsem to myslel.Obávám se, že je to přesně naopak.Jako cílový jazyk kompilace. Síla Luy je IMO v tom, že je to jednoduchoučký jazyk s malinkým runtimem který se dá jednoduše embednout kamkoliv. Přijde mi trochu zvláštní mít mocný typový systém a v runtime všechny tyhle informace zahodit a všechno to nasypat do jedné univerzální hashmapy. To už by mi přišlo rozumnější, aby si Amulet zrovna interpretoval svůj AST než tohle.Asi nerozumím tvému příspěvku. Extrémně nevhodná na co?Já ho třeba používám protože implementace Amulet (https://amulet.works/) je podobná Haskellu, umí nějaké ty zajímavé featury a kompiluje mi to do Lui. Žádná další zvláštní motivace v tom není.Kompilace do Luy? Proč? Zrovna Lua mi pro tenhle účel přijde extrémně nevhodná. A s dokumentací na stránkách toho jazyka je to takové nijaké.
Tohle kombinuje nevýhody z obou světů. Pro kompilaci potřebuje mocnou parní mlátičku a v runtime platí za nevyužitou flexibility Luy.
V runtime žádné typy nepotřebuju, snad tam ani žádné nejsou (dobře, to není tak docela pravda, ale to je fuk). Mocný typový systém potřebuju jen na začátku, při překladu. Pak už jej prakticky nevyužiju - maximálně se mi tam hodí typy jako tagy při nějakém switchi, což je přesně to co ten Amulet dělá. V runtime se mi naopak hodí to, že tam není žádné zbytečné smetí a může optimalizovat po svém (LuaJIT etc, i když to jsem ještě nezkoušel).
U staticky typovaného jazyka můžete typy zahodit, jen nechat data v paměti a přistupuje k nim kód vygenerovaný na základě typů. A to přesně v dynamicky typované lue moc nejde. Tam musíte jednu každou položku separátně alokovat jako boxovanou dvojici typ + hodnota a celé to nasypat do hierarchie hashmap. Takže v runtime máte hromady zbytečných typových informací.
