(Minor features demoed: Array literals, #place directive). Apologies for my big head blocking the view of the code. I had meant to shrink that when the demo began, but didn't!
I have to rewatch this on a day when I'm less tiered and don't fall asleep watching interesting videos. Anyway when I still was awake it was mentioned that it would be convenient to iterate over an array expression like `{1, 2, 3}` and that you can't do that in C++. You can (g++ -std=c++14 -Wall -Wextra -Werror -pedantic): #include int main() { for (auto i : {1, 2, 3}) { std::cout
I just can't get over the fact that I'm watching you talk "inside my video game" (Secret Witness ending). It's really distracting, and kind of awesome. :)
would've been cool to see a performance benchmark. i guess it's pretty straightforward to guess at. this language is going to be faster than C, because these optimizations are too much effort to do there
Would be also cool to have linear indexing (i.e. indexing into a 2D matrix with a single value), as well as slicing s.t. X(:,1) gives you the 1st row, and so on. Also, with matrices, you might want to distinguish elementwise vs matrix product, and operators such as ' (transpose) and ^-1 (invert) together with / and \ for solving Ax = b wouldn't go amiss either. Not sure how relevant they are in games though.
Interesting video, very cool stuff. Though worth pointing out that c++ called their resizable arrays "vectors" from linear algebra where a vector is defined (roughly) as "a matrix with only one column or only one row". However, they have long admitted that was a mistake and that they should have just called it std::array
Damn JoBlo, back at it again with the compiler!Seriously though, I need to watch all of those videos... I know simple C++ from school but I want to learn more about coding in general.
+Elwood How much of what he says do you understand? I'm always curious about this... I program a lot and am too biased to know that perspective anymore.
Iplywittrees I mean, I know structs, functions, loops and stacks (most exercises in my IT class are based on this), but I still don't fully grasp memory allocation stuff or polymorphism. I more or less understand how Jonathan wants to improve the syntax.
+Elwood Exact same boat here, hate the languages I've used in school but this language is so so cool to me and is exactly how I want to code, problem is it's made me kind of lazy cause I'm just sort of waiting for this to get released so that I can use it :/
+Cybon Don't expect any release for beginners, soon. It takes years until a programming language has a sophisticated base, so that you can program in in using only that language. I remember programming in Go, that very often when I wanted some library, I had to write my own wrapper, and writing a cross language wrapper even though not necessarily complicated, it's definitively not beginner stuff, and much more time consuming, that many beginners want to inverst in order to try things out. And even when you will be able to use C libraries without a wrapper, you still need to understand all of c in order to be able to read the c header and interpret what it means in the other language. But with all the features that are proposed here, I really doubt that this language will lack in supporters that are willing to invest some time, to make this language more useable for beginners.
+Cybon, haha I know what you mean, but I would strongly suggest not waiting for Jai to do more programming. It will take some time for the language to mature, and almost everything you pick up by actively learning and doing things with any language in the mean time will help later when you decide to try a new language.
Lol I remember wanting to make a vector/formal sum class in C++, the first thing coming to my mind being "I should have some way of checking this and that". Then learning there is such a thing as concepts planned for C++17, which of course didn't meet the spec ...
Would be really cool if you made it possible to parameterize the arguments to a type in a function: append :: (vec : $T/Vector(N)) -> $U/Vector(N+1) { // ... }
Instead of generating text, wouldn't it be less error prone to generate AST to splice into the body. So for example, instead of generating "1+1", you would generate something like `AST(CALL, [PLUS, 1, 1])`, equivalent to `+(1,1)`, where AST is some struct. You can then programatically generate function bodies without having to do a bunch of string processing.
You can also do this. It is shown in other demos. Thing is, (a) because the language isn't done you can't do it in every context, and probably couldn't do it here yet unless you figure out an interesting hack I haven't thought of, (b) the compiler does not yet generate a textual version of ASTs in order to help you with debugging.
In JavaScript, Python, and JSON, and I'm pretty sure quite a few other places, array literrals use brackets, while curly braces are used for map literals, like this: [1,2,3,4] {1: "hello", 16: "there"} Now I know we don't like maps because they're slow. But maps are incredibly useful things for so many purposes, and you're not always concerned with the kind of performance difference using a map in a particular circumstance is going to make. We want to reach Up And Down with this language, right? It's a language for Good Programmers, not programmers who need to be protected from themselves. Good programmers know that maps are slow, and they only use them where their use is perfectly appropriate - which is a whole lot of places! Say you're defining a system of menus. Nothing about this needs to be super high performance. A user is not going to be able to tell the difference at all if you're storing the definition for your menus in one big nested data structure that was defined by assigning one big multi-line json literal to a variable. using menu_functions; menu_def : Map = {"file": {"exit": ^exit}, "help": {"about": ^about}, ..}; No you can't do a billioin instructions per second with that, but if you can do 10,000, you're way more than fine for the purpose! If your menu has 10,000 items, you've got much bigger problems than the performance hit you took by defining it with slow ordered maps! The only thing I know of that uses curly braces for arrays is C and maybe C++. Aren't we trying to get away from them? Are we going to be stuck in the same muck or are we going to reach for the kind of syntax that higher level languages employ? I know syntax arguments are a pita and everyone has their pedantics about them, but i feel like certain fundamental syntactical things like this are kind of important. It makes a huge difference in the feel of the language. Are we more like C and C++? Or are we more like a JavaScript or a Python that can perform like C if we play our cards right? Isn't the latter more like the kind of language we all want to program games in? The syntax for a literal array vs a litteral map is a Really Big Tell about that, exactly because of this: How easy is it to consume json into your language? Can you create a literal json string, with a bunch of nested substructures and have it be valid syntax in your language? The above syntax only contains maps, but it could just as well have maps nested in arrays nested in maps. It's not SOA, but for a menu definition, or a gui layout definition or a config settings definition for almost anything, Nobody Cares!
Jonathan: all value parameters to types must be known at compile time, is that correct? That is what I understood except that the use of '#dynamic_specialize' for matrix operations (such as at 38:32) made me slow down and second guess myself. But, as you say, you want to generate the functions at compile time. I suppose then I wouldn't be able to use matrix add/multiply on any matrices whose masks might be dynamically generated, even something as simple as adding a matrix to itself in a loop?
+dosboot1 That would work fine at compile-time, because as soon as #dynamic_specialize returns, the new type is created and you can use it. At runtime, the idea doesn't really make sense, since these matrices are strongly-typed things, so you would be very unlikely to be somehow iterating and adding them in a loop (since if the masks are different the types are different, so what container are you getting them from?). In general the whole point of this technique is that you know the masks at compile time.
Few questions - say I have a struct with parameter, and I use that parameter in the struct as the size of an array: 1. Will that array in the struct be (a) a pointer to an array, or will it be (b) in order with the struct itself? 2. If the answer is (a), is it possible in Jai to create an array inline with other members of a struct, and that array would have variable size? In C, for example, as far as I know, that's not possible. An array can be inline if it has constant length, but can only be a pointer if it has variable length. 3. If the answer was (b) or if the answer to 2 is yes, what would be the result of size_of() on that type? I was thinking about the less common way to implement general purpose strings, which would be (instead of using a NUL terminator) saving a size and then the array of chars. Now, of course, this is trivial if you accept that the array is in a different place in memory from the length, and you can do "struct String { int length; char* arr; };", but I want to be able to have them in consecutive memory. That's also easy to do if you say that the first 4 chars of arr are a 32 bit integer, but that's kind of sucky and annoying to deal with in C. So, as a language that intends to have the least amount of friction possible for the developer, what say you about this topic?
1. b 3. It is the same as what size_of would return if you just put the number inside the array brackets. I don't think you want the length and data for a string to be in consecutive memory. If they aren't, then taking substrings of the string is a cheap operation; if they are, then any substring requires an allocation.
Yes, I'm aware of the separation being superior, I'm just wondering. A string is a bad example for what I was getting at. But your answers lead me to further questions - does a struct's parameter have to be a compile time constant? If not, then are you saying there are two versions of size_of(), one at run time and one at compile time?
+Jonathan Blow how would the inferring of the type of the elements in the initialization list play together with what you *could* want to implement, which is initialization of a struct -- which obviously could have different type for different fields?
I find the slash notation rather confusing. Maybe a suggestion on the syntax? Instead of doing: length :: ($T/Vector) I would prefer to write something like this: length :: ($T) So, the general type is specified between angle brackets.
(a) It involves parenthesizing something that doesn't need parenthetical grouping (as currently implemented, anyway) (b) You are claiming that / is confusing (I guess because it's the division operator?) but < and > are also math operators, so really you are just talking about wanting the syntax to be more like C++ for no reason but familiarity ... (c) Except that would be terrible, because the type listed here means a totally different thing than the things that are put between in C++ usually, so whereas this looks slightly more familiar, that is deceptive, and it will just confuse C++ people. (d) < and > is more typing than /, not just being more characters, but also requiring the use of the shift key (on American keyboards at least and probably many others). (e) It potentially uses up both the characters < and > which might otherwise be employed in the future in type expressions in different ways. (f) Syntax bikeshedding is a total waste of everyone's time and I say this almost every video. None of the syntax here is final -- presume the whole language will get a makeover at the end. What we are doing now is determining the language's semantics.
Actually this is awesome. But, why is ; needed? The compiler should know when a statement is ended, right? Excuse me if you have to dumb things down in order to explain it for me. I'm just really excited about this language and i'm interested in it's progression.
+Pär Karlsson It's not necessarily safe to let the compiler figure that out. Javascript doesn't require a semicolon and if it sees a line break after the "return" keyword, it ignores the next line, even if you meant for the function to return the value from the next line.
So, I understood the're no public available versions of the compiler. Is that correct? And if so, why haven't you distributed some extremely unstable versions of it for us to play around with?
In response to one of the questions and your answer: Python has a good way (syntactically) of handling dumping in namespaces from modules: import some_module #keeps the module's namespace separate from some_module import * #dump in the entire namespace from some_module import foo, bar, baz #Only import foo, bar, and baz and dump them into the global namespace import some_module as sm #import and rename module from some_module import foo as bar, baz as foo #import some things from the module and rename them maybe to keep the #import directive consistent, you could reorder the syntax: #import some_module #import * from some_module #import foo, bar, baz from some_module #import some_module as sm #import foo as bar, baz as foo from some_module The last 3 are a good way to import only what you need, keeping the clutter low. As an added bonus, it could be a hint to not add the unused procedures and data to the executable (which it would probably do anyway)
+Beefster09 I feel that Mr. Blow would choose a syntax that is probably something like this: #import "Module" = m; // file load #import m; // global dump #import m.foo; #import m.bar = baz;
I usually try not to hype over things but this, wow
Can't wait for this to be finished and have Vulkan or opengl bindings :)
Twitch now has chat replay - check out the archived twitch VOD for some insightful discussion!
www.twitch.tv/naysayer88/v/54888526
+Menko Thanks bro.
I dont have a time machine :(
@@Lircking Yeah, it sucks
I have to rewatch this on a day when I'm less tiered and don't fall asleep watching interesting videos. Anyway when I still was awake it was mentioned that it would be convenient to iterate over an array expression like `{1, 2, 3}` and that you can't do that in C++. You can (g++ -std=c++14 -Wall -Wextra -Werror -pedantic):
#include
int main() {
for (auto i : {1, 2, 3}) {
std::cout
I just can't get over the fact that I'm watching you talk "inside my video game" (Secret Witness ending). It's really distracting, and kind of awesome. :)
mind = blown @ 36:37 :D amazing work once again
would've been cool to see a performance benchmark. i guess it's pretty straightforward to guess at.
this language is going to be faster than C, because these optimizations are too much effort to do there
I watched this live but let it play in the background while working on other stuff
Would be also cool to have linear indexing (i.e. indexing into a 2D matrix with a single value), as well as slicing s.t. X(:,1) gives you the 1st row, and so on. Also, with matrices, you might want to distinguish elementwise vs matrix product, and operators such as ' (transpose) and ^-1 (invert) together with / and \ for solving Ax = b wouldn't go amiss either. Not sure how relevant they are in games though.
+Dmitri Nesteruk Your pluralsight videos are great!
Francisco Paisana why thank you :)
I am so pumped to try some stuff in this language.
Interesting video, very cool stuff.
Though worth pointing out that c++ called their resizable arrays "vectors" from linear algebra where a vector is defined (roughly) as "a matrix with only one column or only one row". However, they have long admitted that was a mistake and that they should have just called it std::array
Damn JoBlo, back at it again with the compiler!Seriously though, I need to watch all of those videos... I know simple C++ from school but I want to learn more about coding in general.
+Elwood How much of what he says do you understand? I'm always curious about this... I program a lot and am too biased to know that perspective anymore.
Iplywittrees I mean, I know structs, functions, loops and stacks (most exercises in my IT class are based on this), but I still don't fully grasp memory allocation stuff or polymorphism. I more or less understand how Jonathan wants to improve the syntax.
+Elwood Exact same boat here, hate the languages I've used in school but this language is so so cool to me and is exactly how I want to code, problem is it's made me kind of lazy cause I'm just sort of waiting for this to get released so that I can use it :/
+Cybon Don't expect any release for beginners, soon. It takes years until a programming language has a sophisticated base, so that you can program in in using only that language. I remember programming in Go, that very often when I wanted some library, I had to write my own wrapper, and writing a cross language wrapper even though not necessarily complicated, it's definitively not beginner stuff, and much more time consuming, that many beginners want to inverst in order to try things out. And even when you will be able to use C libraries without a wrapper, you still need to understand all of c in order to be able to read the c header and interpret what it means in the other language. But with all the features that are proposed here, I really doubt that this language will lack in supporters that are willing to invest some time, to make this language more useable for beginners.
+Cybon, haha I know what you mean, but I would strongly suggest not waiting for Jai to do more programming.
It will take some time for the language to mature, and almost everything you pick up by actively learning and doing things with any language in the mean time will help later when you decide to try a new language.
Lol I remember wanting to make a vector/formal sum class in C++, the first thing coming to my mind being "I should have some way of checking this and that". Then learning there is such a thing as concepts planned for C++17, which of course didn't meet the spec ...
Would be really cool if you made it possible to parameterize the arguments to a type in a function:
append :: (vec : $T/Vector(N)) -> $U/Vector(N+1) {
// ...
}
+No Pico (Pls)
You can do that.
append :: (vec : $T/Vector) -> $U {
n := (get N)
U = #dynamic_specialize Vector(N = n+1);
}
Can you use the #place directive to unify with members which were pulled in from another struct with a using statement?
Instead of generating text, wouldn't it be less error prone to generate AST to splice into the body.
So for example, instead of generating "1+1", you would generate something like `AST(CALL, [PLUS, 1, 1])`, equivalent to `+(1,1)`, where AST is some struct. You can then programatically generate function bodies without having to do a bunch of string processing.
You can also do this. It is shown in other demos. Thing is, (a) because the language isn't done you can't do it in every context, and probably couldn't do it here yet unless you figure out an interesting hack I haven't thought of, (b) the compiler does not yet generate a textual version of ASTs in order to help you with debugging.
In JavaScript, Python, and JSON, and I'm pretty sure quite a few other places, array literrals use brackets, while curly braces are used for map literals, like this:
[1,2,3,4]
{1: "hello", 16: "there"}
Now I know we don't like maps because they're slow. But maps are incredibly useful things for so many purposes, and you're not always concerned with the kind of performance difference using a map in a particular circumstance is going to make. We want to reach Up And Down with this language, right? It's a language for Good Programmers, not programmers who need to be protected from themselves. Good programmers know that maps are slow, and they only use them where their use is perfectly appropriate - which is a whole lot of places!
Say you're defining a system of menus. Nothing about this needs to be super high performance. A user is not going to be able to tell the difference at all if you're storing the definition for your menus in one big nested data structure that was defined by assigning one big multi-line json literal to a variable.
using menu_functions;
menu_def : Map = {"file": {"exit": ^exit}, "help": {"about": ^about}, ..};
No you can't do a billioin instructions per second with that, but if you can do 10,000, you're way more than fine for the purpose! If your menu has 10,000 items, you've got much bigger problems than the performance hit you took by defining it with slow ordered maps!
The only thing I know of that uses curly braces for arrays is C and maybe C++. Aren't we trying to get away from them? Are we going to be stuck in the same muck or are we going to reach for the kind of syntax that higher level languages employ?
I know syntax arguments are a pita and everyone has their pedantics about them, but i feel like certain fundamental syntactical things like this are kind of important. It makes a huge difference in the feel of the language. Are we more like C and C++? Or are we more like a JavaScript or a Python that can perform like C if we play our cards right? Isn't the latter more like the kind of language we all want to program games in?
The syntax for a literal array vs a litteral map is a Really Big Tell about that, exactly because of this: How easy is it to consume json into your language? Can you create a literal json string, with a bunch of nested substructures and have it be valid syntax in your language? The above syntax only contains maps, but it could just as well have maps nested in arrays nested in maps. It's not SOA, but for a menu definition, or a gui layout definition or a config settings definition for almost anything, Nobody Cares!
Jonathan: all value parameters to types must be known at compile time, is that correct? That is what I understood except that the use of '#dynamic_specialize' for matrix operations (such as at 38:32) made me slow down and second guess myself.
But, as you say, you want to generate the functions at compile time. I suppose then I wouldn't be able to use matrix add/multiply on any matrices whose masks might be dynamically generated, even something as simple as adding a matrix to itself in a loop?
+dosboot1 That would work fine at compile-time, because as soon as #dynamic_specialize returns, the new type is created and you can use it. At runtime, the idea doesn't really make sense, since these matrices are strongly-typed things, so you would be very unlikely to be somehow iterating and adding them in a loop (since if the masks are different the types are different, so what container are you getting them from?). In general the whole point of this technique is that you know the masks at compile time.
Few questions - say I have a struct with parameter, and I use that parameter in the struct as the size of an array:
1. Will that array in the struct be (a) a pointer to an array, or will it be (b) in order with the struct itself?
2. If the answer is (a), is it possible in Jai to create an array inline with other members of a struct, and that array would have variable size? In C, for example, as far as I know, that's not possible. An array can be inline if it has constant length, but can only be a pointer if it has variable length.
3. If the answer was (b) or if the answer to 2 is yes, what would be the result of size_of() on that type?
I was thinking about the less common way to implement general purpose strings, which would be (instead of using a NUL terminator) saving a size and then the array of chars. Now, of course, this is trivial if you accept that the array is in a different place in memory from the length, and you can do "struct String { int length; char* arr; };", but I want to be able to have them in consecutive memory. That's also easy to do if you say that the first 4 chars of arr are a 32 bit integer, but that's kind of sucky and annoying to deal with in C. So, as a language that intends to have the least amount of friction possible for the developer, what say you about this topic?
1. b
3. It is the same as what size_of would return if you just put the number inside the array brackets.
I don't think you want the length and data for a string to be in consecutive memory. If they aren't, then taking substrings of the string is a cheap operation; if they are, then any substring requires an allocation.
Yes, I'm aware of the separation being superior, I'm just wondering. A string is a bad example for what I was getting at.
But your answers lead me to further questions - does a struct's parameter have to be a compile time constant? If not, then are you saying there are two versions of size_of(), one at run time and one at compile time?
Yes, a struct's parameter has to be known at compile time.
+Jonathan Blow how would the inferring of the type of the elements in the initialization list play together with what you *could* want to implement, which is initialization of a struct -- which obviously could have different type for different fields?
+Seltsamster Typ I am not sure I understand the question... ??
I find the slash notation rather confusing.
Maybe a suggestion on the syntax?
Instead of doing:
length :: ($T/Vector)
I would prefer to write something like this:
length :: ($T)
So, the general type is specified between angle brackets.
+APaleDot Why? Because you are used to C++, a language that has terrible syntax that is the result of decades of sediment?
Jonathan Blow
Well... yes, actually. I appreciate your efforts and think you are doing a great job, but why is this terrible syntax, exactly?
(a) It involves parenthesizing something that doesn't need parenthetical grouping (as currently implemented, anyway)
(b) You are claiming that / is confusing (I guess because it's the division operator?) but < and > are also math operators, so really you are just talking about wanting the syntax to be more like C++ for no reason but familiarity ...
(c) Except that would be terrible, because the type listed here means a totally different thing than the things that are put between in C++ usually, so whereas this looks slightly more familiar, that is deceptive, and it will just confuse C++ people.
(d) < and > is more typing than /, not just being more characters, but also requiring the use of the shift key (on American keyboards at least and probably many others).
(e) It potentially uses up both the characters < and > which might otherwise be employed in the future in type expressions in different ways.
(f) Syntax bikeshedding is a total waste of everyone's time and I say this almost every video. None of the syntax here is final -- presume the whole language will get a makeover at the end. What we are doing now is determining the language's semantics.
Actually this is awesome. But, why is ; needed? The compiler should know when a statement is ended, right? Excuse me if you have to dumb things down in order to explain it for me. I'm just really excited about this language and i'm interested in it's progression.
+Pär Karlsson It's not necessarily safe to let the compiler figure that out. Javascript doesn't require a semicolon and if it sees a line break after the "return" keyword, it ignores the next line, even if you meant for the function to return the value from the next line.
So, I understood the're no public available versions of the compiler. Is that correct? And if so, why haven't you distributed some extremely unstable versions of it for us to play around with?
I will buy The Witness only when it is ported to Linux.
+Willy Goat Oh well!
the GIANTEST facecam
do you stream on twitch?
isn't struct with parameters pretty much just like a class?
It doesn't have much to do with parameters...
In response to one of the questions and your answer:
Python has a good way (syntactically) of handling dumping in namespaces from modules:
import some_module #keeps the module's namespace separate
from some_module import * #dump in the entire namespace
from some_module import foo, bar, baz #Only import foo, bar, and baz and dump them into the global namespace
import some_module as sm #import and rename module
from some_module import foo as bar, baz as foo #import some things from the module and rename them
maybe to keep the #import directive consistent, you could reorder the syntax:
#import some_module
#import * from some_module
#import foo, bar, baz from some_module
#import some_module as sm
#import foo as bar, baz as foo from some_module
The last 3 are a good way to import only what you need, keeping the clutter low. As an added bonus, it could be a hint to not add the unused procedures and data to the executable (which it would probably do anyway)
+Beefster09
I feel that Mr. Blow would choose a syntax that is probably something like this:
#import "Module" = m; // file load
#import m; // global dump
#import m.foo;
#import m.bar = baz;
Do you have operator overloading implemented?
+Alexander Programming No, he hasn't
Consider doing the same thing for audio programming. Maybe seeking partnership. Urs Heckmann.
。。。天啊
What was suggested in the chat around 52:30?
How i felt about the Witness is perfectly reflected in this guy's review
th-cam.com/video/hDxxwFLs0d8/w-d-xo.html
p.s. braid is a masterpiece