Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411278 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 12:51:46 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)(Jon Blow) Ideas about a new programming language for games
Pages: [1] 2
Print
Author Topic: (Jon Blow) Ideas about a new programming language for games  (Read 4575 times)
Boreal
Level 6
*


Reinventing the wheel


View Profile
« on: September 24, 2014, 10:02:50 PM »

WARNING: VERY LONG VIDEO AHEAD







In this video Jon Blow (creator of Braid) discusses some drawbacks to the languages we currently use to program games (mainly C++) and provides some ideas to how a new low-level language could be designed to make things easier without sacrificing performance.  The way this is done is taking C and adding language features while keeping a data-oriented focus - everything a program does can be boiled down to manipulating memory.

Even if you don't believe in making a new language or aren't ready to wait or make it happen yourself, I think there's some useful points that can be applied to programming in existing languages like C or C++.

- Architecture shouldn't be designed with poor programmers in mind.  This is especially important for small teams or one-man-armies; don't limit your architecture for or bother with errors that are faster to fix than to prevent.

- RAII (along with exceptions) breeds needless complexity.  Why is the concept of a "resource" so important, especially in games where your I/O operations are very sparse?  This should be reduced to simply telling the compiler which pieces of memory are owned by the object and which are simply referenced.  This removes the need for complex constructors/destructors and move semantics.

- "Unsafe" code such as pointer arithmetic and void pointer casting should be embraced.  However, their use should be limited to certain well-defined locations so the tough bugs that come with memory tweaking and twiddling are easy to track.

What are your thoughts?
« Last Edit: September 27, 2014, 08:44:07 AM by Boreal » Logged

"In software, the only numbers of significance are 0, 1, and N." - Josh Barczak

magma - Reconstructed Mantle API
Milkybar
Level 0
**



View Profile
« Reply #1 on: September 25, 2014, 05:28:21 AM »

While I would consider myself to be somewhat of a Jon Blow fan unfortunately I found most of the suggestions in this video to be pretty poorly though through. The video is a bit long to go back though and pick out each point individual points I will try to remember of few.

- Static checking of container bounds. In principle for some loops and fixed size containers it should be possible for the compiler to detect if we are going to index outside of a container. While this sounds great it has relativity limited use in practice where the likelihood is that most of our containers are going to relay on dynamically allocated memory or are indexed by data coming from a volatile source. This would require runtime checking incurring an overhead. C++ already can provide pretty good solutions for static and dynamic container cases. We could implement our own container classes to to provide features like iterators. And if we don't mind a runtime overhead we can perform bounds checking at run time inside the operator[] method. There are already several off the shelf containers like this for use if you don't want to write your own.

- Custom symbol for unique pointer. Maybe if you were already writing a new language this might be a helpful feature to pop in but all it ultimately saves is typing a few characters (std::unque_ptr<type> name;).

- Automatic grouped memory allocation for data members. The example we are presents with looks like it saves a few lines of code but its a really simple case. I can't imagine its really going to hold up as soon as we require more complex cases and different allocation strategies depending on constructor overloads. I also think if that be at all piratical Blows idea would need to take allocators into account. Allocating blindly on the heap is all great to show of the idea but if we are making next gen AAA game engines we need to take more care of our memory.

- Safe/unsafe blocks. Really C++ developers should be enforcing this on themselves anyway. Most of the dangerous pointer access should be neatly wrapped into nice container classes that can be thoroughly tested in isolation. Thanks to the STL, Boost and other third parties efficient and tested containers are already available for many cases.


Some points I did like.

- More control over the memory layout of classes. Currently C++ lacks a satisfactory to write truly portable code with strict memory layout requirements (usually needed to interface classes with external C APIs e.g. OpenGL). Usually end up falling back onto #pragma pack() but this is not standard C++ (if supported by all major compilers). Apparently more control of this is coming in C++14.

- Standard support for managing threads. Having to rely on Boost to provide a cross platform solution to creating and managing threads is kinda embracing for a language so widely used. Again apparently coming in C++14.



Ultimately I think most of what he want is already pretty achievable in C++ without much effort. Really not so much effort that it would be worth building a language from the ground up. Not to mention trying to get platform holders on bored and support compilers for their platforms.

That is not to save C++ does not have a lot of room for improvement. Many of the suggested solutions to blows problems rely on template containers and while the C++ templating system provides us with a lot of power the syntax is not nice at all. Its got even worse as c++11 onwards has started to rely on template meta programming techniques to to avoid implementing new language features at all cost. It certainly would be nicer to be able to place constrains on template types and interfaces. It would make it a lot more straight forward and easier to implement user allocators and containers, ultimately allowing us to get more use of the C++ that is already there.


While I don't think Blows suggestions provide a suitable replacement for C++ in terms of game programming. I think there is massive potential for a new language if it is build around the problems of concurrency. CPUs ain't getting much faster and we are getting more and more cores multi-threading is getting more important and brings along a much much worse class of bugs and problems that can be supper hard to find and replicate. Apparently he is doing a follow up talk on this tomorrow night so will be interesting to see if he addresses some of these thoughts.
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #2 on: September 25, 2014, 05:42:17 AM »

I didn't watch the whole talk, but he sounds like most experienced C++ programmers - the ideas behind the language are great, the actual language is clunky, mostly for compatibility or historical reasons. Many people have proposed replacements (D, Rust, Go), but so far not with huge acceptance (as the talk says, they're not the same). I didn't need to hear more complaining on that score, we all know that C++ syntax is not great, or that the toolage could be better.

I don't get the issue with RAII. I think he's not using it property. It's an encapsulation, you don't need write you own destructor very often precisely because RAII is composable, and the lowest level resources already come with wrappers. Nearly all my classes have no copy constructor or destructor, because they only contain smart pointers or raw pointers they don't own.

RAII has bugger all to do with exceptions. If you have return codes, you still want to exit a function halfway through its body, and clean up the stack before doing so. He'd propose duplicating all the cleanup at every exit condition, I guess?

I don't want to go through down the whole thing, but I objected to pretty much every original language proposal that I saw. I've got lots of respect for Blow, but this video is indistinguishable from a lot of directionless muttering I've seen before elsewhere.
Logged
nikki
Level 10
*****


View Profile
« Reply #3 on: September 25, 2014, 01:03:16 PM »

Yeah I've sort of skimmed through the video a while ago (was mentioned on the D forums), the most valid point people made over there imo is that they love his attitude but think it takes another type of freak to actually build a language with all the boring groundwork that goes into that.

but offcourse the more languages and choices the merrier.
« Last Edit: September 25, 2014, 01:14:05 PM by nikki » Logged
baconman
Level 10
*****


Design Guru


View Profile WWW
« Reply #4 on: September 26, 2014, 11:27:51 PM »

One HUGE thing that comes to mind is the (non)nativity of gamepad support. FFS, WHY are we STILL having to define what a gamepad even is, and then having to program that to emulate keyboard functions?! How do we not have a framework that's just... "GAMEPAD_DPADUP.1" or something like this already grounded into languages?

Secondly, modern games have really hit a good stride in their default layout. Therefore, shouldn't there be some kind of default template projects with essential link/flow like this that already exists, waiting for the gaps to be filled in? O.o

PRESS START

#PLAY GAME
-SaveGame Select?
-Hub screen
-Levels/Action
-Evaluation/Grade
-Game Over (general)
-Game Over (you won)

#HOW TO PLAY
-Instructions
-Tutorial stage SHOULD GO HERE

#OPTIONS
-Game Options (difficulty, global abuse)
-Controls (configure/emulate shit here)
-Audio/Video (sound/music volumes, tests, mic on/off, chat on/off)
-Streaming (save replays, configure Twitch/YouTube shit here)

#EXTRAS
-Replay data
-Gallery junk goes here
-DLC store page? Why not?
-Scoreboards and penis contests

#EXIT GAME
-Oh no, you don't really mean this, right?
--You can't leave now, we've barely begun
---BUT THOU MUST!!
----I AM ERROR.


I'm not saying that any of these can't be implemented by people with half a mind. But seriously, if a lingo/IDE is really focused on streamlined game creation; why have all of this busywork remain... busywork!! There's no harm in having a "savegame support screen" implemented if you can simply choose to bypass it when you don't need it! Smiley
« Last Edit: September 26, 2014, 11:40:00 PM by baconman » Logged

Boreal
Level 6
*


Reinventing the wheel


View Profile
« Reply #5 on: September 26, 2014, 11:34:25 PM »

I think you missed the "low-level" part.  Those are all extremely high-level concepts.
Logged

"In software, the only numbers of significance are 0, 1, and N." - Josh Barczak

magma - Reconstructed Mantle API
coah
Level 1
*



View Profile
« Reply #6 on: September 27, 2014, 12:47:56 AM »

I'm no programmer, but I've seen both of the talks he's done so far and I found them to be entertaining and pretty easy to follow. I really like his focus on quality of life in programming, its a nice point to bring up and it seems like the language he's talking about is very much based on that ideal.

[...] love his attitude but think it takes another type of freak to actually build a language with all the boring groundwork that goes into that.

He probably is actually, there is an interview where he mentions his history with programming and he used to be big into making compilers, long before making games.
Logged
gimymblert
Level 10
*****


The archivest master, leader of all documents


View Profile
« Reply #7 on: October 06, 2014, 11:29:12 AM »

http://gamasutra.com/view/news/226953/Insomniacs_engine_guru_expounds_on_his_studios_approach_to_code.php
Logged

tjcbs
Level 1
*


View Profile WWW
« Reply #8 on: October 08, 2014, 03:45:05 AM »

I like his approach and attitude, especially his distrust and distaste for dogmatic programming "best practices".

I did get the sense that the proposed language is tending towards a "Jonathan Blow" language, tailored to the particularities of how he happens to work. While it may seem like coding nirvana to him, it will face too much resistance (or more damaging, indifference) if it shortchanges the features that he seems dismissive of (classes, macros, templates).

That it c++'s greatest strength, I think, that it is a designed-by-committee hodgepodge mess, that imposes nothing and can accommodate anyone. As soon as you start trying to whittle it down, and thus impose your idea of how programming should be done, you leave people behind. The only way to replace it I think is to come up with a bigger, better mess.
Logged

Milkybar
Level 0
**



View Profile
« Reply #9 on: October 08, 2014, 06:37:39 AM »


Kind of interesting that he chose this as a video to support his argument. Its seems like Mike Action doesn't want any high level features at all. He even says at one point that he would prefer it if he could just write in assembly. Especially in contrast to this

where he pretty much suggests writing things as simply and quickly as you can. Insomniac's engines and Braid are quite different in size and scope. How do you create a language that resolves both these two distinct needs.
Logged
gimymblert
Level 10
*****


The archivest master, leader of all documents


View Profile
« Reply #10 on: October 08, 2014, 07:08:05 AM »

Well blow's video is talking specifically by high performance game and takes example of AAA engine, he does not target indie at all and start about a case of why it's fine for them.
Logged

nikki
Level 10
*****


View Profile
« Reply #11 on: October 08, 2014, 07:28:17 AM »

Quote
How do you create a language that resolves both these two distinct needs.
assembly and highlevel ...

The D language blow touches upon in his video supports both these ends of the spectrum very nicely actually
http://dlang.org/iasm.html
http://dlang.org/phobos/std_functional.html
Logged
Boreal
Level 6
*


Reinventing the wheel


View Profile
« Reply #12 on: October 08, 2014, 06:29:12 PM »

I like his approach and attitude, especially his distrust and distaste for dogmatic programming "best practices".

I did get the sense that the proposed language is tending towards a "Jonathan Blow" language, tailored to the particularities of how he happens to work. While it may seem like coding nirvana to him, it will face too much resistance (or more damaging, indifference) if it shortchanges the features that he seems dismissive of (classes, macros, templates).

That it c++'s greatest strength, I think, that it is a designed-by-committee hodgepodge mess, that imposes nothing and can accommodate anyone. As soon as you start trying to whittle it down, and thus impose your idea of how programming should be done, you leave people behind. The only way to replace it I think is to come up with a bigger, better mess.

I don't get the idea that he doesn't like macros/templates, but I can agree that canonical C++ classes are not that great.  I think a class system where PIMPL is explicitly baked into the language is the way to go, or at least a way of explicitly distinguishing between POD and non-POD types.
Logged

"In software, the only numbers of significance are 0, 1, and N." - Josh Barczak

magma - Reconstructed Mantle API
tjcbs
Level 1
*


View Profile WWW
« Reply #13 on: October 08, 2014, 07:21:39 PM »

That sounds like one of the "Big Ideas" that he, I think rightly, wants to avoid.
Logged

Christian Knudsen
Level 10
*****



View Profile WWW
« Reply #14 on: November 01, 2014, 03:59:53 AM »

He's got a demo of his language up and running:





Pretty sweet stuff!
Logged

Laserbrain Studios
Currently working on Hidden Asset (TIGSource DevLog)
eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« Reply #15 on: November 01, 2014, 09:24:45 PM »

I'm pretty impressed so far, he's implemented a lot of stuff. I'll definitely be playing with this once its public. Fully runnable code during compiler stage will be very useful, I've been waiting for proper constexpr support in msvc for a while to do what Jon blow's prototype can already do. Though I'll never leave c++ I look forward to watching this develop.
Logged

GrizzlyNinja
Level 0
*


View Profile
« Reply #16 on: November 03, 2014, 11:46:05 AM »

He's got a demo of his language up and running:





Pretty sweet stuff!

Cool demo!

I think the aspects of this language I like most are that he's designing it with performance, a game developer's happiness and desire for convenience in mind. I'm interested to see where he takes his project from here. I'll probably test it out if he releases it.
Logged
oahda
Level 10
*****



View Profile
« Reply #17 on: November 04, 2014, 12:55:09 AM »

I haven't watched the video far enough to get to any of the game-specific things yet, but defer is kinda qt. I'll be back later when I'm done watching.

- Standard support for managing threads. Having to rely on Boost to provide a cross platform solution to creating and managing threads is kinda embracing for a language so widely used. Again apparently coming in C++14.
Not coming in C++14. Already available in C++11 which is widely enough supported by now. I'm writing my current game in C++11 and it's great.
Logged

Gtoknu
Level 0
***


View Profile
« Reply #18 on: November 04, 2014, 01:03:02 AM »

on the demo, that #run directive seems veeeery nice. Goodbye macros, welcome REAL compile time calculations
Logged

wut
oahda
Level 10
*****



View Profile
« Reply #19 on: November 04, 2014, 01:41:39 AM »

Yeah, I just saw that too. It's great.
Logged

Pages: [1] 2
Print
Jump to:  

Theme orange-lt created by panic