Hacker News Reader

Comment by efnx | Hacker News Reader

I'm not sure that a "programming language for games" would be a subset of a general purpose language. I can't think of an operation that a general purpose lang can do that I would not want to use in a game. In that case, how could you specialize for games? A game is kind of an abstract concept - it could be anything. Maybe try constructing a language that lets you choose a subset of its total functionality for your specific game, possibly through extensions. Haskell does that well.

View on HN

I think the idea is that the language is focused towards games. Games generally have some inherent shared qualities, mainly that they need to be real time and the language should be minimal overhead. On the otherhand, a language focused on enterprise software would sacrifice speed and low overhead to instead add some safety features like a garbage collector.

Its not a language only for games, but it is a general purpose language where the main feature set is chosen to benefit professional game development.

Yes I agree that the games he's designing the Lang for have certain shared qualities, but IMHO those concerns are best dealt with using libraries or (E)DSLs in a host language. That way you can still support games like zork, which don't have to be real time - as well as games that transcend what the "game specific Lang" was designed for. I personally don't see why there is a distinction between "a game" and "an enterprise app" - some enterprise apps need real time rendering and low overhead (unity, blender, arcgis, cad, etc). My point being - a language that is good at describing all games is good at describing all programs.

1. It will still be turing complete. In that sense its always going to be a general purpose language.

2. From what I've been taking away, all he is looking for is a way to remove some of the redundant parts of his day to day C++ code/process. Nothing more. Thats why, while I get that it is a full compiler, very intentionally (I think), a lot of the time it just seems like very nice syntax sugar (maybe "program sugar") for C++.

A language that tries to be good for describing all games, will end up not being good at describing any of them, because different types of programs require different tradeoffs

Exactly - and those trade offs will be handles at the library level.

A lot of modern game frameworks go in a similar direction. It's all about having entity-component systems where the designers (and not the programmers) can put together the objects dynamically. And those all fight with similar problems. One is about making the system cache efficient. Another is about how to add new components. I suppose the latter might be a reason he put so much power into the preprocessor that he even created a VM for that. Current complete solutions tend to have the problem that you have to repeat the class-names of your components often and that type-safety get's lost at some point when ini-files in any format are involved. Having more power in the preprocessor might help to fight this.

I don't know what he has planned for his language, but if I hear about a language that's specific for programming games, then entity-component systems would be the use-case I would have in mind.

I'd like to point out though, that I commend the effort of writing a Lang, I'm not try to discourage - just adding my thoughts! We need more language choices!

Reply on news.ycombinator.com