Jai Language Primer
github.com
Jai Language Primer
1–10 of 102 posts
Re: Jai Language Primer
#2I like the idea of a language syntax that allows easier refactoring. I think Rust is especially good at this as well, and I'm happy to see that Jai borrows from that.
Re: Jai Language Primer
#3I wonder if Blow has ever looked at Nim. Sometimes I hallucinate that game devs will have an Awakening and realize it's the way forward.
Re: Jai Language Primer
#4I like the idea of a language syntax that allows easier refactoring. I think Rust is especially good at this as well, and I'm happy to see that Jai borrows from that.
I liked some things I saw which I've only seen in Pascal / Ada.
Edit: Specifically I thought it was the same as what I've seen in Pascal for arrays[0] where you specify the range (in the case of characters) between x and y. I always thought that was kind of interesting, have yet to really see it implemented in another language afaik.
[0]https://en.wikibooks.org/wiki/Ada_Programming/Types/array
Re: Jai Language Primer
#5This is interesting. Recently, I've been doing more c programming again, and everytime I do I find myself thinking about building a language that is essentially c with just a very few pain points removed. #1 is a build/module/package system for making it easier to build modular code without copy/paste that is the defacto c-standard. #2 would be removing the pain points of utf8/unicode support (go seems to get this pretty close to right). And that's really it. (you could throw in an easy way to do closures and all values immutable by default and I wouldn't mind either).
Otherwise, I'm usually completely happy using C. I've tried Rust and Go and they have their use cases, but for most low-level things I do, I don't care that much about everything being perfectly safe (i.e. rust), and I don't want gc, and the high level stuff that Go brings. Really, just give me C with a good module system and I'd be perfectly happy. Maybe I'm alone here though...
Re: Jai Language Primer
#6I wonder if Blow has ever looked at Nim. Sometimes I hallucinate that game devs will have an Awakening and realize it's the way forward.
I've got the same dream but about Lispy languages, preferably Common Lisp.
I'm sure more people around here have the same dream about their favorite language :-)
Re: Jai Language Primer
#7I wonder if Blow has ever looked at Nim. Sometimes I hallucinate that game devs will have an Awakening and realize it's the way forward.
I've got the same dream but about Lispy languages, preferably Common Lisp. I'm sure more people around here have the same dream about their favorite language :-)
Every now and again when I'm really figuratively toked up I go reread the history of Crash Bandicoot and also dream for more Lisp in the games industry (and every other industry). :) But I think Nim is slightly more realistic.
Re: Jai Language Primer
#8This is interesting. Recently, I've been doing more c programming again, and everytime I do I find myself thinking about building a language that is essentially c with just a very few pain points removed. #1 is a build/module/package system for making it easier to build modular code without copy/paste that is the defacto c-standard. #2 would be removing the pain points of utf8/unicode support (go seems to get this pr…
Have you seen dotc [0]?
Re: Jai Language Primer
#9I stopped caring at no garbage collection.
Re: Jai Language Primer
#10> Abstractions like RAII, constructors and destructors, polymorphism, and exceptions were invented with the intention of solving problems that game programmers don’t have
This is the only part of the Jai philosophy I struggle to understand. How is an explicit delete keyword better than deterministic destruction? From my perspective, the former method reintroduces the problem the latter method solves.
Also, polymorphism is bad for games now? I absolutely cringe when I see abstract base classes, virtual functions and classical inheritance, outside of a generic interface in 2016. However, games might be the one case I would strongly consider using those features as part of my design. For example, a Final Fantasy-style job system seems to elegantly lend itself to the "Intro to OOP with C++98" style of runtime polymorphism*
As for exceptions, well I think the reputation of exceptions is one of the great tragedies of C++. Rust, Go, and other new languages seem to have decided that regressing to pervasive error checking boilerplate is more elegant than to have exception handlers.
I think Swift got it right with scoped exceptions and a defer statement - although, they selectively use "error handling" as double speak to avoid saying the e-word.
*Although, I personally think interface/protocol based solutions have proven to be the cleanest way to tackle polymorphism -- this is possibly true even in the case of an rpg with class inherentence as a game mechanic.