Ideas about a new programming language for games.
ฝัง
- เผยแพร่เมื่อ 18 ก.ย. 2014
- My first talk on designing a programming language for games.
Given September 17, 2014.
An implementation is being built and there have been many demos. See the full playlist at • A Programming Language... . - เกม
Gotta respect Jon. This man talked about a new language and went out and implemented it successfully
Where can I download and use it?
@@gameplayripper It is called jai. Just google it
@@glebfedorov2601 I googled it and it's not open yet
@@gameplayripper its in closed beta now
Too early to say if it will be successful, that depends on people using it.
55:03 Thank you. It's annoying when people think aesthetics don't matter in code. Ugly code is less motivating, more confusing, and usually more typing.
I meticulously align my code and it helps me spot errors. I call it "visual linting".
I literally can't think about improving my program functionality if the code looks ugly
blow'14: "C++ reached critical complexity"
C++'2x: hold my wg21 meetings.
Can you really call conventions that just expand the STL "more complexity"? I mean - it doesn't change shit within the language's grammar.
@@gayusschwulius8490 really stl is only thing you've noticed changing?
I was pleased to hear that C++20 finally implements coroutines after them being invented 70 years ago.
@@____uncompetative c++ is the definition of "how do you do fellow kids"
@FichDich InDemArsch said a person who uses "3edgy5me" and "cringelord" ahhaa
you said you want to get faster than c but according to the theory of relativity that is impossible
wrong, take a look at assembly which is the layer directly before binary practically
@@irina_divine He is making a joke, c is usually used as the constant for light speed (as in E = mc^2)
@@irina_divine That joke went way above your head didn't it? whoosh lol
r/whoosh
@@nexovec you had to add the r/. I thought we were better than this
He takes my favourite features from the languages, adds some good features and boom. I have to give it to you, really cool ideas.
Amazing, not only did he set out 8 years ago to create a new programming language for games, but he is also developing a game through the new language, and it looks top notch. Very few people I have met stick to their goals that determinantly.
What kind of game is he currently developing. Where can I get acquainted with this?
To be honest, this talk doesn't seem to have aged well. Not only he mentions Elon Musk, who we now know is completely crazy. He claimed creating a programming language would be easier than the game he spent 5 years coding, and it's been eight years, and no public release yet.
Eight years developing a sokoban game is ridiculously long. I doubt he actually got much farther than a typical university compiler project built on top of LLVM, and in the best case scenario he would release a preliminary version of D, which didn't see much success.
This dude should snap out of his delusions and stick with game design, which is what he's good at.
@@felipelopes3171 assuming you posted it from the lack of knowledge about this whole topic, which is already a big leap: 1. Sokoban takes ridiculously long, because it's a ridiculously big game with an insane scope, you can see it on streams. 2. The compiler is already in a good shape, there are a lot of people in the beta already, who are using it for all kinds of stuff, including myself.
@@felipelopes3171sounds like someone couldn't put their handy hands on the closed beta of jai
@@kiryls1207 fun fact: I didn't even know that his amazing language had a "closed beta" until you posted this. Besides, even if I tried and didn't get it, it would be like not getting a Tesla Semi truck or a full self driving taxi from Elon. It would make people question my intelligence, but it would not change the fact that he didn't deliver the language anyway.
Very interesting talk; looking forward to further discussion. Thank you.
You can simplify the joint allocation by having a readonly modifier. With it, you can automatically assume that all initialization of readonly can be joined, and have the compiler or runtime decide whether to do so based on arbitrary or explicit block size constraints.
54:51 stud unique putter, gotta love Jon
Interesting to hear his take on rust from 9 years ago, and how the cons still fit it somewhat today
I'm rewatching this quite often
This talk is so legendary
I had to pause the video to hit Like when he said "no header files". Effin' amen.
Personally I like to have a separate place to put a public declaration of a type in. That means I can look at the declaration without caring about the internal implementation details.
@Jens You just want an analyzer to pull those out from the actual code then, such as one you'd have in a sensible IDE.
Jens that's what meta programming is for
What do you mean, I love tons of hidden #ifdefined statements changing how your code gets compiled.
Yeah, I hate headers. I mean C++ is a pretty great language for what it can do, but it's age is really showing. So many antiquated conventions like header files that don't really need to be there. I also love the idea of a compiler only language, no linker or other extra steps.
@1:11:50, in D you would mark class_name and favorite_color as immutable string and they would "slice" constant string values - not copy any data.
character_name would probably copy i.e. "character_name = name.dup;"
all three would be D strings, aka char[], aka arrays. arrays are simply structs with a pointer and length.
Those string structs *could* be allocated with Party_Member itself. Then only the memory referenced by character_name would be additional memory to manage.
D would currently GC this memory. But.. it's important to note that less allocation is being done in the D version, so the GC has less to do. In addition provided you do not allocate in your rendering loop you will never suffer from a collection pause/delay.
As mentioned, there will be more options in the future. However, even now, nothing is stopping you from allocating the memory yourself and slicing character_name from that memory.
Loved the video. Also loved trying to figure out how many things he was drinking too. (I do the same thing at my desk)
Very interesting video! A long watch, but quite worth it.
Atlas78 I have no idea who Jonathan Blow is, but I program for a living and have been programming for about 9 years. I agree with many of the points brought forward in this video, and quite enjoyed this presentation. I think most of Jonathan's ideas are well-founded and well thought out. Programming language designers should definitely take some these things into serious consideration.
Jonathan blow is an indie game developer.
He designed both Braid and The Witness.
I know who Jonathan Blow is now (and had played Braid but didn't know Jon by name when I posted my previous comment). I have been following JAI pretty closely, and The Witness is my all-time favorite video game. I've also met him in person at a few conferences. He's a very intelligent designer / engineer and I love what he's doing to push both himself and the industry forward.
@@dandymcgee Except he describes a lot of what is in C++. But yes C++ syntax sucks. And header files suck too. We could probably get away with switching macro to constexpr which would be nice. And then modules should be what is used by c++ in place of includes.
By ridding yourself of the ordering problems ( which is doable ) we might achieve that. Also built in maybe modnad as sth alike pointer.
it should allow us to do all operations this type would support, but yields monad of return type instead. Multi return is sth I don't see offten but would be awesome (though multi return just returns a struct, it still would be nice if there was a way to return anonymous struct via struct->variable list, variable list-> struct conversion.
Re: Argument naming, Ada allows you to name the parameters passed to subprogram, it also allows you to place them in any order.
Imagine talking ada
Today I started to watch everyhting again from the first video. The main reason I watch again is cause I forgot a lot of awesomeness and my confidince in this project has grown a lot over time.
For the sceptic people. Those who think they can and those who think they can't are both usually right - Confucius
Very interesting, very well presented too I have to say.
Most of the minor things mentioned here are already available in D. Like no header files, fast compilation, more powerful and convenient templates, compile time function execution, int[] arrays and slices of them, very powerful introspection (at compile time, no runtime overhead). But the major one, the way to handle memory, is of course quite different in D compared to what's proposed here.
Ada is even better.
Arena allocation and compile time variables is already available in Zig
@@aksakalaradhita"already" - 9yrs later ☠️
This was fascinating and got me really thinking about all kinds of things regarding how to improve our lives as programmers. I'd love to help you build this new language!
This, this was the day the future of programming was changed for the better.
It may not have looked like it then, or maybe even now.
But I believe when Jai eventually becomes public, it may change programming for the better.
22:20 All the time spent programming and looking at the code, the system could (and should) be parsing and compiling (Java IDEs do it, intellisense does it). We should be able to make it feel instant.
It's interesting to see now, 7 years later, which of these ideas actually worked and which didn't quite make it to the end.
Where could I find a succinct summary of what worked and what didn't make it in the end?
C++ is not a 100% language. C++ is layer upon layer of different programming ideologies implemented in backwards compatible way. It's complexity is akin to the complexity of English orthography.
C++, like English, is super powerful but has some fatal flaws. However, I like having a variety of ways to express my ideas and code, so I'll keep using English and C++.
One way to think about this is that for most programming languages their lead designer knows the full language completely.
It's reasonable that not a single person, including none of the designers knows C++ thoroughly, one might be a master of lambdas, another of pointer dynamics, but each don't know about the other.
Like a multi-story building done by multiple architects, no one is a master of it.
Surely that makes it even more of a language?
@Matias Lmfao
"C++ is not a 100% language" - what is a "100% language" then?
As someone that loves C++, I have to admit that I started watching this video with touch of defenciveness. But I have to say that Jonathan makes some very good arguments here.
Nice ideas!
I do have some proposal on syntax at 1:09:04
struct Mesh {
void* memory_block {
Vector3* positions = NULL;
int* indices = NULL;
Vector2* uvs = NULL;
} = NULL;
int num_indices = 0;
int num_vertices = 0;
}
// this is how we should allocate:
memory_block = new { positions: num_vertices, indices: num_indices, uvs: num_vertices };
// or if we are sure we don't mix up args, we can write just:
memory_block = new { num_vertices, num_indices, num_vertices };
// this is how we should delete:
delete memory_block;
// we should not be able to allocate or delete "joint" pointers, so next lines should not compile:
positions = new char[num_vertices];
delete uvs;
// i don't want to add any complexity, so just clear thing out: there is no such thing as "memory_block.positions" or "memory_block->positions". the all you can do actually with memory_block is to "new" or to "delete" it and the only type it can be is "void*".
Thanks to you I found the D programming language and now I'm in love with it.
@FichDich InDemArsch The D programming language
The D (programming language)
One notable exception in games programming is that they normally don't have that much maintenance effort. As Jon mentioned here, "completion/shipment" is the endpoint in games, while in business-y environment maintenance is a much bigger goal (both technically and financially). So the priorities might be different in those other fields.
That isn't true (at least not as much anymore) because massive games that are multiplayer need constant maintenance and now we have these games that keep adding content as time goes, MMOs would be obvious ones back in the day, but games as Warzone, Fortnite, Overwatch, and even other games that simply add an expansion, they really need maintenance.
@@donkeyy8331or games that get sequels, games that reuse components from prior games, and libraries and engines.
I don't even think this was true in the old days. Titanfall uses a heavily modified source engine, which is just the engine for HL2, which borrows heavily from Gold Source, which is built off of the Quake engine.
Apex Legends is a current game which receives updates to this day, made from Titanfall, which has roots in its engine dating back to Quake. That Quake code has stuck around for 27 years.
I'm so excited for when Jai is available. Hello Sailor !
This is the best youtube video I have watched in a long time
I'm all for this, C++ feels powerful, but also archaic
I wish I could've met you 8 years ago. This definitely would've been something I would want to work on. I've been seeing more and more "agenda" languages cropping up, and it's disappointing. The idea that because a feature is misused by some, or even if by most, that it should be deleted from a language when it is so useful is just astoundingly arrogant and I hate that.
That's okay I am not making my big agenda language for you. In fact, I am only making it for me to use.
No one else.
@@____uncompetative You're likely not one of the people I was referring to. I'm talking about languages that are promoted as being for everybody yet have a stupid score to settle with people they disagree with so they eliminate capability in their language making it harder to do certain things because they deem these things harmful. Java was one of the first I encountered, and their score to settle was removing `goto` from the available features of the language. Now it's almost universal that people falsely believe it's bad, merely because certain people have misused it.
@@anon_y_mousse The first program I ever edited was full of GOTO statements to line numbers and it was comprehensible enough. Then there was ON x GOTO 130, 340, 650 which was quite powerful. Obviously, I've programmed in machine code and assembler and you directly manipulate the Program Counter register there, and you can fill memory with opcodes and then jump into the data. I've written self-modifying code, and code that generates itself, and GOTO is really useful for that. Lexers benefit from Finite State Machines that use GOTOs and Virtual Machines which use ON op GOTO versus CASE OF op WHEN, WHEN, WHEN tend to be faster. FORTRAN 77 had a nice computed GOTO, but FORTRAN 90 got rid of it, replacing it with EXIT (essentially BREAK). Kotlin has a form of BREAK which can escape beyond the immediately enclosing block, which makes it a lot more like a GOTO in the case of nested loops, but it lacks the utility of a true GOTO that is able to jump anywhere including into assembly.
The solution should be to allow it in UNSAFE code as the places where it tends to be needed are adjacent to assembler, or to circumvent superfluous nested loop iterations (Frank Rubin's letter *"GOTO Considered Harmful" Considered Harmful* in the March 1987 Communications of the ACM was an open reply to Edgar Dijkstra's *Go To Statement Considered Harmful* from March 1968 in which he starts off moderately observing that "For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of *go to* statements in the programs they produce." which seems like he is saying people overuse them and implies that this causes "Spaghetti Code" which became a serious problem prior to the introduction of Structured Programming in ALGOL 60 and has been generally more beneficial to software quality than overused OOP or the overly abstract FP with its strict type systems, Dijkstra just seems pragmatic and reasonable and advocating to use GOTO sparingly if you must, until you read on and he says "I became convinced that the *go to* statement should be abolished from all "higher level" programming languages." he asserts this opinion without any statistical evidence or firm rationale, just whining about it making it harder for the programmer to conceive of the dynamical state of their program's variables, as it is non-linear in its execution outside of the local structures of the flow chart), allowing it in UNSAFE code along with assembly / intermediate code for the Virtual Machine, and any exposed references that might be needed through PEEK & POKE of relative virtualised word aligned memory addresses, ought to be enough for all "high level" code outside of stuff intended for embedded systems or device drivers, which may as well be assembly anyway as it doesn't need to be platform independent.
I have a *go* in my language and was loath to remove it as I had used it with zero issues in the past, and have welcomed your comment as it prompted me to read the relevant letters for and against this feature, and have resolved to keep it _within_ a module that is marked with *unsafe* and all functions are non-recursive, with static memory allocations, so it doesn't matter if *go* is used to jump out of a nested loop inside of a function inside of a function within that module as whatever mess it makes affects its local state which doesn't grow in extent or need collection as garbage at any point (which would kinda defeat the whole purpose of using *go* to be efficient).
The total prohibition of this feature, however well intentioned, seemed silly, lacking in rigorous justification, and not mindful that the Structured Programming methodology which purged it from some language syntaxes (or only left vestigial CONTINUE and BREAK statements), whilst helpful, brought with it an awkward cost which can impact efficiency in both expression, and computation of some problems. OOP by comparison is far worse than SP, and I still regard SP as a net gain. FP ought to be simpler than SP and far, far simpler than OOP, but typically ends up overcomplicating itself with Category Theory, with Simon Peyton Jones admitting Haskell is currently useless:
th-cam.com/video/iSmkqocn0oQ/w-d-xo.html
There are some aspects of SP, FP and to a lesser extent OOP that are salvageable and will boost productivity whilst increasing code quality and therefore code maintenance due to improvements in code readability. So, I totally agree with you that these Big Agenda languages which force the adoption of one paradigm without nuance or exception are dogmatic and restrictive to personal expression, and I think the combination of multiple paradigms is a mishandled mess in C++ so my Big Agenda is to reduce the syntax (how much you need to input), yet allow alternative defaults to be set so it remains articulate (i.e. it isn't like _JavaScript_ where numbers are all 64-bit floats and you can't choose anything else), and I know C/C++ fans will hate it for not being C-like, so I'm not even going to let them use it. They seem to think their language is so fantastic, and want to ensure job security by being rare in having mastered C++ Templates, so I'm happy to leave them to it and boost my productivity with my own tool for my own project.
This has been thought provoking to think up how to answer this. Thank you.
Nice Video and awesome suggestions
Still waiting to try it!
Only know Jon Blow this many years later. If I know him when I started CS degree in 2013, I would have become a much better one now.
-Multiple return types are available in c++11 using tuples and tie().
-unique_ptr notational issues can be fixed using an template alias. Optimization is not a PL problem but a compiler one.
-Custom allocation techniques can be provided through overloading new operator or allocators.
But if you still want this notational features can be achieved programming a frontend that compiles to C++11
Conflation of allocation and initialization in c++ is a default but you can separate them.
Just Thought I'd let you know its an awesome idea. Plus your little "turny do hicky" is the green circle on top of the selected area lol.
This language is second only to TempleOS
Another idea: Just like LLVM solves a lot of problems - could a language 'middle', maybe defined by an AST, do the job of some common subset of Rust & C++ perhaps, be another layer for allowing a customised language front end. A lot of what I personally want could just be a slightly cleaned up syntax for C++ (imagine if the *! pointer was just sugar for unique_ptr, or if the [] syntax was repurposed, etc etc...)
As a developer I can agree with him. I remember I was assign a project, it was me and a group of about 20 people and we were tasked with creating a robust game engine from scratch. We broke off into groups of 4's with each group having a team lead n each group creating a core for the game engine... I was team lead for the UI core of the engine... It was fun and we were successful with the engine. The down side was we had a tight timeline which is the reason why developers won't try to change or create a new language because it does save you A LOT of time but it would be fun to do so.
I am glad you have a TH-cam channel. I will subscribe.
Some nice ideas and syntactical sugars in here - but I do wonder whether an entire new language is the answer, rather than incremental changes to C++ and the improvements to dev tools and compiler errors in particular.
It'd be a huge undertaking, much more than just a compiler - a modern IDE on many platforms with a debugger, auto-completion, refactoring, inline documentation, etc. Then there are standard libraries to consider - does it take on file IO, network sockets, system timing, memory allocation, etc. in some cross-platform way? We'd need the major APIs ported over - operating systems (Windows, Mac, Linux OS & windowing systems, console OS's, mobile platforms, etc.), graphics (DirectX/OpenGL), audio hardware APIs. Not to mention a huge amount of work porting companies' engines, both commercial (Source engine, Unreal, ID tech, etc.) and in-house.
Also - I'd miss C++'s applicability to so many situations. I can make a desktop application, a PS4 game, or an embedded program for a tiny 8-bit microcontroller with the same language. The ecosystem and libraries that have been built up over 30 or so years is enormous. I guess in some ways C++ is like the QWERTY keyboard - DVORAK may be superior on paper, but in the larger context, QWERTY has an enormous advantage in utility, because it's what you already find everywhere and what everybody already knows.
Well here we are lol, he’s going for it
Have you considered Ada?
To quote the Ada Reference Manual: "Ada was originally designed with three overriding concerns: program reliability and maintenance,
programming as a human activity, and efficiency" and I think it knocks out all of these goals.
It might not seem so at first, but it definitely has nearly all the goals and sub-goals you wanted in a language.
Specifically I don't think you'll like how strict it's syntax and compiler are, but over time you'll save costs as it starts causing you to automatically prevent bugs. You can write any program you want, but the problems with your initial design end up becoming obvious because your program starts looking hacky and ugly. If you take some time and think deeply about how the interfaces of your packages, writing your program will be orgasmic.
This is the problem of ada, no one considers ada, it's 4 years since your comment and people still don't consider ada at all, even tho ada with spark being a amazing language. And now everything is being pushed to be replaced with Rust that even tho is a great language has such a bad syntax that i wonder years from now when it becomes legacy how will people maintain it.
All in all, ada is probably another one of the good languages that no one paid attention like D and Lisp for example.
@@talesvinicius598 recent video by streamer Tsoding made me try out Ada and i'm already in love with this language
Really interesting video
You can transfer data in Go without channels. There really is nothing stopping you sharing a structure between the Goroutines and accessing the structure with mutex. It is really similar afterwards to regular C/C++ threading.
Interesting, I never imagined Jonathan Blow like this, I thought he was more of a wispy, hipsterish designer-guy, nice to see he's more of an actual programmer.
damn he even had hair when he started working on this
The goal is to prevent memory handling issues statically. Checking memory handling at runtime requires a lot of testing to cover all code paths.
And it's never possible, because after extensive testing, someone will eventually come along and make a tweak that introduces new paths.
I support the idea of a domain specific language but I think some of the gripes in this talk can be mitigated by good coding practices. For example when you mention APIs with a high degree of arity that become cumbersome to invoke because of default parameters etc. IMO functions that take more than a couple of arguments indicate a violation of SRP, or an oversight as to the relationship between these arguments in context that might be better represented using a containing type or typed wrapper around them - thus lowering the arity and making your type hierarchy more accurate/expressive.
I understand the rationale in game programming to stuff functions with arguments and have them perform long-winded logic in one invocation to minimise the cost of extra frames on the call stack. However, I think the actual question you should be pondering is how can we design a language such that we minimise this overhead for function invocations altogether so that our source code can maintain modularity and simplicity (making it easier to refactor, unit test, understand etc).
The problem of how to deal with those aforementioned complex function signatures then goes away because the programmer is not deterred from composing short, simple and clear functions by the idiosyncrasies/deficiencies of the language's runtime (call stack architecture). On the contrary, such practices are encouraged by the spec/compiler.
+1 for "no god damn header files"
Btw. your "C++11 style" Mesh class is much more C++98-like. Not a fair comparison.
Not even C++98! C more like...
Tomalak Geret'kal There's C++98 and then there's C++98. The modern style use (or abuse) of C++ features didn't come before Alexandrescu's 2001 book. In turn many C++0x/later features are inspired by Alexandrescu's library Loki and its descendent, Boost.
Siana Gearz That's complete nonsense. Examples of "modern" idioms are even in the standard itself for goodness's sake! C++98 standardised what sensible people were actually writing by 1998. Here's just one example of contemporary code that I've randomly plucked from the first page of Google results (www.cs.duke.edu/~ola/ap/exams/cplus98.html). No antiquated redundant syntax and plenty of RAII. Lovely! And from 1998.
Tomalak Geret'kal Yeah i fired too quickly. I got to the spot now, BUT... i think his example conveys the point across. I didn't perceive it as REAL C++ but as a fictional language as a design guideline, which shares syntax with C++ just as an example of what the programmer would type out at the lowest effort, as a starting point for consideration on what's needed to make it work, from the standpoint of language features as opposed to library features. Of course those things have library solutions in modern C++, but the whole premise of the video is to explore an alternative approach. If folded into the language, compile times can be shorter, code can be potentially more expressive and better compile time verifiable, and error messages and debugging can be simpler.
Also those are toy examples you link to, TreeNode and friends aren't proper solid code either - ownership not solved, no protection against copying or assignment etc etc. It's hard to call it "plenty of RAII".
Siana Gearz Okay well he's teaching so he shouldn't take shortcuts. And I don't think you write in antiquated idioms even as a "starting point" .. you start as you mean to go on! Write brief and concise code before filling it out, sure, but by using antiquated idioms you're just making your next steps more painful for no good reason. Modern programming begins at the initial design stage.
48:25, but still there's a good defensive constructor you could use here, from C++03: that 1 which you specify which value, from a complete initialization from outside, will go to which class-member variable. It prevents the bug arising from switching variables places inside the class.
And this should be a class, because the character will keep those informations for a long time. So you should prevent yourself from messing them.
49:00, you could use a stack C-buffer, if you constrain the name length to 1
1:04:10 -- Debuggers can, and currently do, do that for template based arrays.
They have been able to do that for quite a while.
Multiple return values is something I would love to see in Java. Nicer code & even less GC action
Or tuples for that matter. :)
For multiple return values in Java I just use an array or return an object with the values I need.
Just found this in Jan 2020. I'm finding myself saying "Omg, preach it brother! Amen!" quit a lot. I think I'm just going to listen to this entire playlist from beginning to end. I'm not sure exactly what he's talking about with the 80% thing. Hopefully he'll explain that here shortly.. I'll be Very Interested in hearing about how he envisions dealing with memory management.
What I want is a language that arguably competes with C as far as performance goes (so it compiles to native code and doesn't garbage collect), and reaches toward trying a lot harder than C++.. and I think Rust, too.. to compete with something like JavaScript or Python for ease of use / rapidity. I want low friction, and I don't care that much about "safety," at least as far as the kind of "safety" that you have with a language like Rust. When I fight with bugs, it's either not the sort of thing that any amount of that kind of safety is going to be able to prevent, or I find and fix them pretty quickly. So the "safety" stuff just bogs me down. I absolutely love his description, the "joy of programming just isn't there when it feels like you're filling out tax forms" (paraphrased). Ha. Amen brother. But it's more than that, it's.. that the time cost of satisfying the safety natzi actually feels to me like it's way, way more than the time saved by the safety natzi. Anway, onward..
Oh boy, you're in for a wild ride if you start going through the demo videos. Just one month after he gave this talk he already had a prototype that blew my mind.
Rust is a good example of 100% solution. It emphasizes memory safety but it's awkward to work with. C++ would be 85% solution : it's type system and newer features like smart pointers give developers tools for safer code but they don't shackle you. C would be 0% because everything regresses to int pointer.
also there are already languages that are written with principles listed in this video like Zig, Crystal and Nim.
Forth was used in the past for writing lots of games, Atari for example had a Forth devoted department for games only. You should check this out. Thanks for this video ! Thumbs up.
Great video! I would have loved to see a comparison with nim, but perhaps you had a reason to exclude it? :)
Your only really working around the pointer issues. You want to abstract out the pointer to some point, such that you can use pointers but you don't have to use pointer arithmetic to use them. The language should provide ways of indexing such that the compiler provides the pointer arithmetic code. Ada does this.
Good name for the new language: Jon
Why not Blow It Up Your?
I think Blow is a better name.
How about B?
gameprojectX B is already taken. It's the one C improved upon. en.wikipedia.org/wiki/B_(programming_language)
Pyry Kontio Maybe C--? "C!"?
Very interesting guy, and the only comment I would make is that programming languages are certainly ideally designed to create or deal with certain types of constructs, but also everybody has there preferred programming "style" they prefer so it's also a bit like "I think this cake tastes better". This means that ideally a large number of people with a common goal (in this case games) need to get together to define the language for the task at hand. Only that way will it achieve the wide appeal it needs for success.
I prefer to stick with C because it lets me do all the really low level stuff easily, lets me add complexity everywhere I need it, and I can just create functions for specific tasks as I need them. It lets you do lousy code or good code, it's up to you.
Done properly I only find it difficult the first time I do something.
+etmax1 That, and there isn't anything really stopping one from gluing-on other languages, when they happen to be better at getting a particular task done (e.g. the rise of Lua and more rarely Python for scripting certain parts of a game, making them easily extensible and moddable).
Use the right tool for the job and all that. I suppose in this case the point of the video is more along the lines of, "we have knives, even some small and really sharp ones, but what we really would like to have is a scalpel".
I'm only a casual programmer, and certainly not in games but rather the heavily embedded world where a lot of assembler might get used in conjunction with C, but I have to say after listening to this that there would be a lot to gain from this.
The only thing that I have to stress is that you need a language that hits the sweet spot of as many game programmers as possible as fragmentation of this "space" will ensure failure. C/C++ is the main language for this it would seem, but only because it has such a large base of programmers, so this language needs to be a uniting force rather than something only a handful of "purists" end up using. Your position seems ideal to achieving that goal, I hope you get enough people on your side to achieve it.
This guy is very smart
You MUST try Valgrind. Those double-free, deref-after-free, unitialized-vars are easily detected. (tells you where it was free'd , where it was created uninitialized, etc).
Automatic memory freeing/management by the language will be tricky with multithreading. Lots of game code might become multithreaded, and atomic refcount decrements/increments are too heavy.
I loved these 2 hours. Thanks.
Another option is Dr.Memory which works for Windows.
I know this is a really old comment, but Valgrind is painfully slow when working with any sort of GUI program (ex. Valgrind + SDL2 takes 30 seconds to show a window).
Have you considered reference counting pointers? Basically, so long as there is at least one 'strong pointer' pointing to a piece of memory, that memory remains allocated. As soon as that counter reaches 0, the memory is freed.
Of course, there is the necessary performance overhead of maintaining the counter, which may be objectionable if performance is very important. And you have to be careful not to create 'strong pointer cycles', since they will never be collected.
But this fixes the "freeing free memory" and "dereferencing free memory" problems as long as you're working with 'strong pointers'. Their counterpart is 'weak pointers', which do not hold onto the memory, but are set to NULL when the memory is freed. Making them work requires additional overhead, though.
20:00 those goals made me think about Lua, but without performance.
Fork Rust?
eg imagine an 'unsafe build' that just gets rid of all safety. (debug -> release -> unsafe_release). thats just optionally disabling features.
and maybe more sugar oriented toward productivity/rapid iteration/readbility. (e.g. optional full inference & duck type traits)
Rust is very close already, IMO, its just a few philosophical pillars they have that we need leeway on to make it the perfect language for games.
The syntax is spot on. Close enough to C++ to be familiar, but cleaner
80:00 When you talk about concurrency, you'll appreciate Rusts' restrictions more. e.g. unsafe{} is also required for accessing global variables.
Rusts' borrow check etc is very useful for ensuring code is safe for concurrency.
this is actually a driving force behind the language, from the Servo *parallel* layout engine,
45:00 r.e. RAII+Exceptions problem:-
thats not the rust way, it uses Option/Result types etc - and is certainly in line with what you say you like about Go
Sounds like you're criticising exceptions rather than RAII. I for one have never used exceptions in C++.
49:00, 56:05, 62:00 ugliness of C++ unique_ptr:
rust originally had ~T as an owning pointer, ~[T] as std::vector,@T for a gc'd ptr, and they replaced it with Box,Vec ... etc
I wish they kept it, but its doing the same job. I wish you were around in the discussion on that :(
we could put this back into a 'rust for games'..
again the @T would have had its uses, you could have prototyped things with @T everywhere and its syntactically easy to just swap in &/T once you know whats going on, also there are cases where productivity > performance is ok.. writing tools, and you might want to move code back & forth between tools & engine.
65:35 concatenated allocations, custom pointer use:-
thanks for explaining this well for people who insist raw pointers are "evil", and 'std::vector'/Vec is all you'll ever need.
rust macros are extremely good and might help here?
e.g. you could write something like
concatenated_struct!( Mesh{ vertices:[Vector3], indices:[int], material_id:int } )
expanding to struct Mesh{raw_data:Vec, vertices:*Vector3, indices:*int, material_id:int} and it would roll all the allocation stuff for you.
unlike C macros, the same macro can have multiple invocation forms, custom separators, repeat patterns.
76:56 lambda syntax:-
IMO actually Rusts' lambda syntax is extremely good, makes internal-iteration code (which in turn is great for data-parallel multicore programming) very pleasing. its one of my favourite things about the language.
Again they used to have 'do' notation which they sadly lost e.g. "do par_foreach(some_collection) |&x|{...do stuff with x}"
general comment:-
one downside to writing a whole new language is tooling; the one thing that stops rust being as nice as C++ for me right now is, lack of an IDE, which isn't a fault of the language, but rather the momentum and userbase.
Any new language faces the same uphill struggle to build its ecosystem, and rust has a head start there. contributing an IDE to Rust would benefit a larger number of people directly now
walter0bz Patrick Walton (Rust core developer) says he is interested in maybe a 'loosened' form of the language. Rust would still be a great language, even without the borrow checker. I don't kniw if he speaks for all the team though. See this comment: www.reddit.com/r/rust/comments/2gwi11/jonathan_blow_ideas_about_a_new_programming/ckn98he
***** that is very encouraging, thanks
The joint stuff is interesting - I think it would be possible for Rust to develop as a library-fied syntax extension, invoked via attributes on the fields. Anyway, the power of Rust is that it has a simple, powerful core, with the ability to extend it based on your use case.
You don't need to start over or fork it to add features tailored to your problem domain.
Re. ~T, one of the problems was that it could not be used with custom allocators (something really important for gamedev). The philosophy of Rust is heading towards shifting most stuff to libraries. By forcing themselves to write these things as library features, the language designers have opened up the possibility to extend the language in ways that they could not have foreseen.
*****
I realise the syntax is subjective. (googleable word vs compact/obscure sigil)
I would have thought ~ could have been 'overloaded' or just synonymous for a certain symbol "~T" == "Box"; much like how + is associated with 'Add::add".
C++ does custom allocators by associating allocation with the types (imagine if you could overload ~ project wide, and further customise the allocator per type).
1:51:26 C: "I'm not even in my final form!"
Regarding the memory point, you've articulated beautiful something that's been bugging me for years.
Tracking ownership of all freed memory blocks (as in, "who freed this block we're mistakenly referencing now") is surprisingly heavy task.
Golang GC pauses are 1000x shorter now in 1.5. Literally. And now it targets Android and iOS.
I don't think Go will do for AAA games, tho. But I think it's by far the lowest friction system language out there. And could be great for simpler games.
To address what you were saying about 'safety'. C# makes great use of this by allowing the use of the safe/unsafe keyword that, unfortunately, not many people know about.
Rust does it too, and I think that it's a nice thing to have. I program C# as my day job, and found Rust just a few weeks ago. Gonna try some personal project with it soon, I'm pretty hyped about it. Go was very nice, but dayum, Rust makes me ooze.
One thing to avoid with the debug allocator is the creation of incompatible runtimes. This is a huge pain point when developing in C++ on windows.
I had no idea I was subscribed to you. Well this should be interesting.
What I've seen with GC languages, it does reduce the number of memory bugs but it doesn't eliminate them. And what memory bugs do remain are incredibly hard to diagnose and fix because you're playing cat and mouse with the GC.
Hey,
Great talk!
A note I wanted to add, on 85% vs "100%" solutions: this is probably what is called "worse is better" vs. "the right thing". There's a great essay about the problem by Richard P. Gabriel, and particularly, the part "The Rise of "Worse is Better": www.jwz.org/doc/worse-is-better.html
Thanks boo boo
Regarding optional pointer params: where I work pointer parameters should generally be null checked. If the pointer should never be null then we pass it by reference. References are never null checked.
This guy is a legend
I'm only at @37m so far but I really think D's goals are your goals... It's not where you need it to be, yet, but it's definitely heading there.
The 2 biggest short term goals for D are better memory management and better C++ integration. So, this means actually being able to disable the GC without having to forgo most of the standard library, allowing a selection of memory management models including GC, RC, etc where this selection would apply to all of the standard library and built in constructs (string/array/associative array etc)
Better integration with C++ would allow more tightly coupled re-use of existing code bases and libraries. You can already link D with C libraries and there is some support for C++ integration (D is ABI- and mangling-compatible with C++).
There is at least 1 game dev company using D (Remedy Games). Their use IIRC was limited to smaller pluggable modules - which they plugged into their main C/C++ code base. The motivation for them was that D allowed faster development cycles with it's faster compile times and in addition gave better modeling power with no drop in performance etc etc.
The D compiler is so fast that I would even imagine you could use it for an internal "scripting" language for game resources.. now that would be pretty cool IMO.
You might find this interesting:
forum.dlang.org/thread/ckegrcmbwqkztywaqeit@forum.dlang.org
You should explore D some more, and maybe get involved. I'm a gamedev, working with D for years now. One of D's greatest features is it's malleability by motivated or significant users. If you still don't find that a valid option, maybe consider a D fork. I've been thinking of this for some years now with gamedev as a specific context. I think it would be possible to rally a community around this...
9:53 "I want to switch before 10 years from now" - as of writing he said this 8 years ago, and I've been eager to try this out. Right now I unfortunately wouldn't be surprised if it's not in open beta before 2030. At this point I just don't know if Jai is worth the extremely long wait, but I understand why it's still in closed beta.
I agree with most of this. One part I don't agree with is the need for a contiguous allocator as part of the language itself. This is both a relatively infrequent operation I think, even in games, and is achievable easily enough with a templated or c-style function, with the parameters specifying the layout you want, and the pointers you want the offsets stored in. If you've been doing all that tedious pointer arithmetic yourself all this time, that's on you!
This is the Alexandrescu presentation he talks about: th-cam.com/video/kaI4R0Ng4E8/w-d-xo.html
i dream of haskell with a IO() typed "collectGarbage" function. :'(
At 56:52, you could do something like add support for the *! and have a pre-compile step to replace them all to std::unique_ptr, like a C++ PolyFill, that would solve part of the problem, but I understand what you are trying to say :)
Cool, I'm creating my own programming language based around simplicity and readability. I'm messing about with a way to almost force a standard for readability without it feeling like you can't write anything.
26:22 "If you spend more time programming around the constraints than it would be taken to fix the bugs than the total completion is going up"
That's true, of course. However, the cost of completion is not the only metrics. If you have millions of customers being hacked due to a memory bug, you may see things a bit differently. At least, your customers certainly will. Obviously, not all programs have same safety requirements, but there are plenty cases where extra cost of preventing bugs is more than justified if you take into account the cost of dealing with a security breach. So it is not all about how much time takes to fix a bug later.
He's talking about game development, not server development. I realise that customers getting hacked due to a memory bug is not impossible in a computer game, but it just doesn't seem anywhere near proportionate to other realms of development. In any case, he's probably making improvements in memory safety with respect to C++, which most games are written in these days, so I'd hardly argue that he needs to do even more.
I found D a lot more like working with Python than C++.
Is it true 2020? I think of diving in a more lower language than Python which is my job programming lagnuage
@@MurtagBY In 2020, I think looking at Go may be more useful.
Given that this was written 9 years ago, I wonder what Jon would think of languages like Zig and Odin
Odin seems to have many things in common with Jai
Mr Blow, PLEASE have a look at Zig-Lang, a programming language with similar design goals as JAI & an increasing momentum which is also still in its alpha/development phase for the simple reason so as to avoid reinventing the wheel or missing out interesting new ideas in language design. Andrew Kelly, its main designer, is also a game developer who actually builds programs he's using.
One of the main design goals of Zig over other languages is that it doesn't try to prevent you to do low-level things, but instead tries to make it obvious & explicit what you're actually doing & allow arbitrary compile-time execution. It also has a lot of promising ideas around basic integer & bit field types which I haven't seen in any other language. Zig also reuses the LLVM compiler infrastructure so it reuses its mid-end optimization & back end modules so it can currently produce code for any platform which LLVM can run on.
C# is a good language. C++ with syntax and designed in similar ways would be awesome!
+Kelda Hanson C# is an alright language, it's feature rich but it has too much boilerplate (adds to the demoralization).
What would you say about Nim?
Anton Shvab nim syntax is weird only that is the problem
I just started using Nim. I will never go back to C++! :D
1:02 yay for javascript (yeah the memory is already allocated but the point is that it makes it easy to work with arrays)
Im constantly working on a Game Editor in blitzmax
and I sure hope your language will do whay I expect..
Im not a pro programmer but I know what I want from a Game Framework..
Also the Editor of code it self arnt good.
as they are..
no arguments would matter when a guy wants not a good language but his own language
Everything is basically C. Von Neumann machine based.
11:13 base like C, but cleaned up; & with nicer syntax, better semantics, then build sensible higher level things from there
9:00 "As I look at D and the philosophy behind it..." -- the philosophy is the key thing here. The philosophy determines the language.
Heh, I recognized your avatar and went back to check the name, and sure enough, it's the same Lion I was thinking of. Hi there. :)