
Jai Language Primer - aerique
https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md
======
gregstula
> 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.

~~~
alaties
Would you mind explaining or linking to a good document on "C++98 style
runtime polymorphism"?

~~~
autoreleasepool
You can do a google search for this information

------
jfaucett
This 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...

~~~
CyberDildonics
It has been said that everyone wants their favorite language with just one
more feature.

------
CyberDildonics
One language to look at for reference that most people haven't heard of is
Clay. It isn't kept up any more, but it's aim was to be a modern generic C. It
made use of very clean generic programming with move semantics and no garbage
collection. The person who wrote it was using it as a substitution for C at
his work already.

~~~
gnuvince
I remember Clay, it was mentioned on Reddit for the first time around the same
time I first heard about Rust (back when Rust was a very different beast). I
though Clay was very interesting, it's a shame it is more or less abandoned.

~~~
CyberDildonics
Looks like that is the current maintainer. The original designer was someone
name KS Sreeram [http://kssreeram.org/](http://kssreeram.org/)

------
whitegrape
I 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.

~~~
aerique
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 :-)

~~~
davexunit
I look at all these new languages with horrificly complicated syntax and wish
for s-expressions. Lisp is perfectly well suited for game development, too,
and not just for scripting. There are many implementations around with fast
optimizing compilers, JIT compilers, and other modern features that make
things run fast. When I see languages like what Jonathan Blow made, I think
that most of the features can be implemented as extensions to your Lisp of
choice.

~~~
hacker_9
When we look at Lisp we see archaic user interfaces, legacy keywords such as
car, cdr and cons which bear no meaning to us mere mortals. Also no clear
consensus on what extensions to use. Why are there so many dialects? Can you
not agree on something that works? Where is your IDE with error underlining
and autocomplete list that comes up with each keystroke? And finally
s-expressions, which make you twist your mind in order to write and don't give
clear structure of the code meaning to the reader, and not even considering
macros...

Not trying to start an argument, but that's my view from a C#'er who tried
Lisp a while ago. I often see Lisp talked about on HN as though it's the
solution to all our problems, but it's really not. Syntax is a big deal in
programming languages, with lots of trade offs between human readability and
unambiguous parsing by the computer, and s-exps aren't some magic bullet for
this.

~~~
urs2102
Well I think Lisp's biggest strength is also its biggest weakness: macros.

By being able to bend a Lisp to your will, you trade your ability to
standardize the language and build a community of libraries and tools around
it. That being said, there's nothing like having a language which eventually
becomes the best tool for solving the problem you're facing for at hand (as
your Lisp will tend to evolve appropriately).

~~~
lispm
People 'standardize' macros all the time.

1) Invent a new useful macro.

2) Package it as a library

3) Document it.

4) advertize it

Since macros are written in a standard language and many cab be written in a
portable way, it just another way of meta programming.

Stuff like DEFCLASS, DEFMETHOD, ITERATE, WITH-GENSYMS, etc. started as
portable libraries.

What one has to learn: the language does not have a fixed amount of syntax.
That's the price to pay: learning a new level of programming: linguistic meta
programming.

------
danbolt
I 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.

~~~
giancarlostoro
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](https://en.wikibooks.org/wiki/Ada_Programming/Types/array)

~~~
beagle3
Nim is a modern Pascal/Delphi with a Pythonic syntax. You'll probably like it.

------
gcatlin
Jonathan Blow is currently doing an AMA on reddit right now
[https://www.reddit.com/r/IAmA/comments/45fu74/i_am_jonathan_...](https://www.reddit.com/r/IAmA/comments/45fu74/i_am_jonathan_blow_game_development_person_ask_me/)

------
davidgrenier
I stopped caring at no garbage collection.

~~~
greggman
I'm with you on this. I'm an old school gamedev. Shipped games on Atari 800,
C64, NES, and most system since then. I hated garbage collection for the
longest time.

But, I have to acknowledge plenty of games are shipping with garbage
collection. Unreal has garbage collection. Unity games have garbage
collection. They seem to all be running just fine and there's plenty of large
AAA games or close to AAA games made with both engines.

~~~
gregstula
They do not have garbage collection. You're conflating game development with
game engine development. When a big powerful, flexible, C++ engine has been
written for you, you can use C# or JavaScript or BluePrints to use the engine
to make a game.

