I suggested the idea to search for examples in the code in the stream, but I didn't expect that he could implement it so quickly and that it could scan so fast. It really says a lot about how usable Jai is for quickly prototyping something despite being as fine grained as C, how useful the metaprogramming is, and how much thought Jon is putting into each decision. I'm really looking forward to using Jai!
I knew that this kind of thing would be possible to do with the compiler, but actually seeing you doing it in 36 minutes from scratch, without lots of preperation is kind of amazing. Looking forward to the language!
If pointer arithmetic is based on the size of the type, i.e. it automatically multiplies by sizeof, then difference should be number of elements, so that it is the inverse of pointer addition: p1 + (p2 - p1) = p2. If pointer arithmetic is based solely on bytes , then difference should also be solely in bytes. The operations should be consistent with each other.
Do you feel like, over time, as you develop this language and internalize the ramifications of certain decisions... that you see the semantics and syntax of this language trending towards what's already available? Put another way, are there demons you'd hoped to expel by creating Jai, but realized they were necessary evils after fully exploring them?
I think as you develop a language from first principles, you understand why other languages solve problems a certain way. The necessary evils you mention, I think are hard problems, maybe unsolvable ones. It then is of course easy to copy the way other languages have manoeuvred around the problem. But as jon has shown us, novel ideas to these hard problems can be found. I believe it just takes a lot of trial and error to find good solutions. I’m of course not working on JAI, so it’ll be interesting to see what jon has to say.
this video was really good demonstration of the type of source code analysis that I've always wanted out of a performance oriented language. The way you found pointer instances felt like lisp. I always found it weird that procedural languages never did good compile time meta programming considering, it's the only real "zero cost abstraction"
The number of times I've used pointer difference as some kind of index is close to zero, relative to the number of times I've casted to byte* to get a real offset.
I'm late to this discussion, but I think you should approach this problem with the same mentality of people who use different types for duration and time, or positions and distances. You (as far as I've seen) never want to add two pointers, you always want to add a pointer and an offset to get a pointer or find the difference between two pointers to find an offset. I know you don't care for academia (which is why I motivated this with practical examples), but this idea has a basis in algebra with the concept of group actions.
The idea pointer= integer. is not always true. Old processors had segment registers. Some new designs combine pointers with memory protection data. In comparing: Pointers can point to the same place while being different. Pointer type conversion can also be difficult in some cases. And what if your pointer is to a memory page in the video-card? Or shared with a very different language? While these are all special cases, I think it can be easily solved by adding a "hardware_pointer" type or something, that deals with hardware addresses. It can start as a simple integer, but when necessary it can be extended for certain hardware.
I asked him about a separate type for pointer math and he wasn't a fan of the idea, because he's trying to keep type system complexity down. Every new type you introduce has a cost.
@@jblow888 Simple integer pointer arithmetic is great. I just think about interactions with future or special hardware. I am a hardware guy. Let me explain: certain microprocessors have different (non-integer) type pointers. (1) The Mill CPU or (2) Digital Signal Processors or Parallel processors (maybe CELL) . The creator of Mill CPU specifically complained about pointers being treated as integers. Just a different type-name will solve this I think, That way, the gaming hardware companies or people working with high-specialized high performance hardware, can easier identify the problem areas. They can and should program their own compiler extension or compiler version to work with these weird pointer types. . But that way, I think more companies will choose your programming language over C / C++ / Rust / Fortran. Because it will deliver more performance.
Hey, it appears youtube has lost my comment, so I'll post it again: Interesting idea to have pointer differences be based on bytes. What exactly are the benefits for non byte pointers though? As an alternative you mentioned casting to U64, I find casting to a byte pointer is a better solution: Differences are unambiguous and you don't have the 128 bit pointer problem. Disallowing pointer arithmetic on non-byte pointers is an interesting idea too. Sure it's inconvenient to first cast to a byte pointer, but (apparently) it's not exactly common, plus it makes you think more about what you're doing. Functionality isn't lost either since you can still use subscripts for pointer + count offset.
This is stuff that I really would like to do also. I did this kind of stuff in Java long time ago. Basic Java course got annoyed about OOreligion, and tried to parody it by using heavily the class Class. I didn't want to design levels for text adventure so I used java class library as the level. Of course this is far more advanced than what I did in Java.
I didn't say couldn't do OO programming, I actually said I did OO Metaprogramming extreme. But what I really hated about OOP of the time was the insane amount of boilerplate it required to do things according to one true way of making OOP at the basic programming courses compared to using other paradigms.
You know, sometimes writing the code for a job that only runs once is a bit tedious. My personal preference once you got the first list of paths would have been to copy those in , and then just use the editor built in tools to sort lines, and unique lines to get rid of duplicates.
pointer arithmetic always confused me in c, because I came from assembler and so I always wanted to do x += sizeof(MyStruct). I the c way is SUPER CONFUSING. it should *always* be the number of bytes
Sorry for asking this, but is there a relesed version version of rhe compiler or are there things still missing till realease? If yes could someone please post a link. Just startet watching the journey from beginning. And I am hyped for things I have seen so far.
It should also be noted that on some platforms such as X86/amd64 unaligned accesses are completely legal; they don't even incur any performance hits (anymore). So depending on what you're trying to achieve this is actually a feature.
What is the benefit of the name: type = value; syntax? To me it would seem like it's adding friction since it's more typing, especially since you need to press two buttons to produce a :
@@ilyabogdanov7505 Why wouldn't simply foo = 5 work? Let the compiler check if foo hasn't previously been initialized, and if it hasn't then set foo to an int with value 5
@@Wand2Fishes That would lead to more implicit, behind-the-scenes or things that could be explicit. It would be less obvious what's happening in a piece of code, thus making it harder to skim through.
Think about what you want to make, and then do that, but never allow yourself to give up when you get stuck on something technical. Don't be afraid to throw it all away and start again if it comes to that.
I am also curious about this! Maybe the second operand is the type, which is somehow hidden or sugared away? Edit: looking harder at the code, my best guess is that the operator is, like, dereference-and-add, which is sort of an odd way to think about it but might make sense in terms of the underlying machine?
@Simon Farre Are you being sarcastic? At 16:13 somebody in the chat asks him if dereference is really a binary operator, and he says it is. And then his code works, so...
@@dingolover6969 No, Simon Farre is just an idiot who likes to speak ill of Jon Blow and the Handmade Network. Not sure who pissed in his cereal, but I see this guy writing the same old garbage on every video concerning these guys.... it's starting to get old.
Jon definitely you need help on Jai development ! Open the code and ask for help, there are thousands of devs who could help you ! P.S. Thanks for Braid, it's the best game ever, you're on the hall of fame !
"Pointer difference are divided by the size of the thing". Why is this even a thing in high level languages? Surely the point of having a high level language is the language should handle this so it isn't a thing?
I just saw the 2014 talk that started all this. Sounded really fantastic. So I have been skimming some other videos up to this point. So "two years" in the talk is now going on six years. And a number of games is one game. And neither compiler or game is done. Still I'm sure it is better than anything I could have done. At this rate you will be retired before this endeavor will ever prove cost effective. And yet anything worth doing involves sacrifice. I'm glad that I did not board this ship back in 2014. I think that you took the wrong approach. In my opinion I think that you should have come out with an open source toy compiler that would have done some good for hobbyist. What I have seen in this hour of further investigation gives me no reason to come back.
I guess pointers arithmitics should be like in C , bc that's what you expect by default , people are used to that ... also if you don't make it C-like people will endup most of the time deviding by sizeof(struct) which would be very annoying
I suggested the idea to search for examples in the code in the stream, but I didn't expect that he could implement it so quickly and that it could scan so fast. It really says a lot about how usable Jai is for quickly prototyping something despite being as fine grained as C, how useful the metaprogramming is, and how much thought Jon is putting into each decision.
I'm really looking forward to using Jai!
I knew that this kind of thing would be possible to do with the compiler, but actually seeing you doing it in 36 minutes from scratch, without lots of preperation is kind of amazing. Looking forward to the language!
Can I just say, I love how well commented the code is. Damn that's some code porn right there.
If pointer arithmetic is based on the size of the type, i.e. it automatically multiplies by sizeof, then difference should be number of elements, so that it is the inverse of pointer addition: p1 + (p2 - p1) = p2. If pointer arithmetic is based solely on bytes , then difference should also be solely in bytes. The operations should be consistent with each other.
Do you feel like, over time, as you develop this language and internalize the ramifications of certain decisions... that you see the semantics and syntax of this language trending towards what's already available? Put another way, are there demons you'd hoped to expel by creating Jai, but realized they were necessary evils after fully exploring them?
I think as you develop a language from first principles, you understand why other languages solve problems a certain way. The necessary evils you mention, I think are hard problems, maybe unsolvable ones. It then is of course easy to copy the way other languages have manoeuvred around the problem. But as jon has shown us, novel ideas to these hard problems can be found. I believe it just takes a lot of trial and error to find good solutions.
I’m of course not working on JAI, so it’ll be interesting to see what jon has to say.
Not really, no.
@@jblow888 Fair enough! I appreciate the response, and the window into language development you're giving us documenting all this work on Jai :)
Where can I go to catch one of your streams?
this video was really good demonstration of the type of source code analysis that I've always wanted out of a performance oriented language. The way you found pointer instances felt like lisp. I always found it weird that procedural languages never did good compile time meta programming considering, it's the only real "zero cost abstraction"
The number of times I've used pointer difference as some kind of index is close to zero, relative to the number of times I've casted to byte* to get a real offset.
I'm late to this discussion, but I think you should approach this problem with the same mentality of people who use different types for duration and time, or positions and distances. You (as far as I've seen) never want to add two pointers, you always want to add a pointer and an offset to get a pointer or find the difference between two pointers to find an offset. I know you don't care for academia (which is why I motivated this with practical examples), but this idea has a basis in algebra with the concept of group actions.
The idea pointer= integer. is not always true. Old processors had segment registers. Some new designs combine pointers with memory protection data. In comparing: Pointers can point to the same place while being different. Pointer type conversion can also be difficult in some cases. And what if your pointer is to a memory page in the video-card? Or shared with a very different language?
While these are all special cases, I think it can be easily solved by adding a "hardware_pointer" type or something, that deals with hardware addresses. It can start as a simple integer, but when necessary it can be extended for certain hardware.
What if your pointer is in base -367 and located in the core of the moon???
I asked him about a separate type for pointer math and he wasn't a fan of the idea, because he's trying to keep type system complexity down. Every new type you introduce has a cost.
@@jblow888 Simple integer pointer arithmetic is great. I just think about interactions with future or special hardware.
I am a hardware guy. Let me explain: certain microprocessors have different (non-integer) type pointers. (1) The Mill CPU or (2) Digital Signal Processors or Parallel processors (maybe CELL) . The creator of Mill CPU specifically complained about pointers being treated as integers.
Just a different type-name will solve this I think, That way, the gaming hardware companies or people working with high-specialized high performance hardware, can easier identify the problem areas.
They can and should program their own compiler extension or compiler version to work with these weird pointer types.
.
But that way, I think more companies will choose your programming language over C / C++ / Rust / Fortran. Because it will deliver more performance.
Hey, it appears youtube has lost my comment, so I'll post it again:
Interesting idea to have pointer differences be based on bytes. What exactly are the benefits for non byte pointers though?
As an alternative you mentioned casting to U64, I find casting to a byte pointer is a better solution: Differences are unambiguous and you don't have the 128 bit pointer problem.
Disallowing pointer arithmetic on non-byte pointers is an interesting idea too. Sure it's inconvenient to first cast to a byte pointer, but (apparently) it's not exactly common, plus it makes you think more about what you're doing. Functionality isn't lost either since you can still use subscripts for pointer + count offset.
This is stuff that I really would like to do also. I did this kind of stuff in Java long time ago. Basic Java course got annoyed about OOreligion, and tried to parody it by using heavily the class Class. I didn't want to design levels for text adventure so I used java class library as the level. Of course this is far more advanced than what I did in Java.
I didn't say couldn't do OO programming, I actually said I did OO Metaprogramming extreme.
But what I really hated about OOP of the time was the insane amount of boilerplate it required to do things according to one true way of making OOP at the basic programming courses compared to using other paradigms.
You know, sometimes writing the code for a job that only runs once is a bit tedious. My personal preference once you got the first list of paths would have been to copy those in , and then just use the editor built in tools to sort lines, and unique lines to get rid of duplicates.
There's also the unix pipeline
$ find $(pwd) -type f | sort -u
pointer arithmetic always confused me in c, because I came from assembler and so I always wanted to do x += sizeof(MyStruct). I the c way is SUPER CONFUSING. it should *always* be the number of bytes
Sorry for asking this, but is there a relesed version version of rhe compiler or are there things still missing till realease? If yes could someone please post a link. Just startet watching the journey from beginning. And I am hyped for things I have seen so far.
He just started a closed beta.
OK thanks for your answer.
Is there a way for me to get in on some beta for the language? Would absolutely love to get my hands on it for use in a game related project.
Lol at the riot references
Good video man!
Wait a minute i can then do lots of unaligned accesses?
E.g i could move my i32 by 3 bytes and not 4 bytes horrible idea.
You can already do that in C, it's just slightly more inconvenient.
It should also be noted that on some platforms such as X86/amd64 unaligned accesses are completely legal; they don't even incur any performance hits (anymore). So depending on what you're trying to achieve this is actually a feature.
What is the benefit of the name: type = value; syntax?
To me it would seem like it's adding friction since it's more typing, especially since you need to press two buttons to produce a :
If the compiler can guess type of variable by value provided, you don't need to write type. It won't work with C's syntax.
@@ilyabogdanov7505 Why wouldn't simply foo = 5 work? Let the compiler check if foo hasn't previously been initialized, and if it hasn't then set foo to an int with value 5
@@Wand2Fishes That would lead to more implicit, behind-the-scenes or things that could be explicit. It would be less obvious what's happening in a piece of code, thus making it harder to skim through.
Is there a way to actually learn how to code I don't know how to code
Think about what you want to make, and then do that, but never allow yourself to give up when you get stuck on something technical. Don't be afraid to throw it all away and start again if it comes to that.
@@tauraamui what?
Why is dereference a binary operator? Seems like a unary one to me
He must have misspoke.
Also curious about this! Is the second operand the struct member name?
I am also curious about this! Maybe the second operand is the type, which is somehow hidden or sugared away? Edit: looking harder at the code, my best guess is that the operator is, like, dereference-and-add, which is sort of an odd way to think about it but might make sense in terms of the underlying machine?
@Simon Farre Are you being sarcastic? At 16:13 somebody in the chat asks him if dereference is really a binary operator, and he says it is. And then his code works, so...
@@dingolover6969 No, Simon Farre is just an idiot who likes to speak ill of Jon Blow and the Handmade Network. Not sure who pissed in his cereal, but I see this guy writing the same old garbage on every video concerning these guys.... it's starting to get old.
Jon definitely you need help on Jai development ! Open the code and ask for help, there are thousands of devs who could help you ! P.S. Thanks for Braid, it's the best game ever, you're on the hall of fame !
I just don't understand why you keep your status bar on the side like this.. I feel that it is kind of distracting there right next to the code.
Vertical real estate is more important than horizontal real estate since there's less of it.
I have mine on the side like that, I can't go back to having it on the bottom. Once you get used to it, it's so nice (imo at least).
What is that 'console' terminal you're using to compile?
Cmder
Cmder with vim afaik
@@nebulium6641 he uses emacs not vim
"Pointer difference are divided by the size of the thing".
Why is this even a thing in high level languages? Surely the point of having a high level language is the language should handle this so it isn't a thing?
Nice to see a fellow emacs user doing interesting work. Where do I get the best jai mode for emacs?
It will probably come into being after jai is released :^)
@@dingolover6969 when in 2050?
it was my understanding that the lack of pointer arithmetic kept Fortran alive for 60 years...
Please Link for Dowload (I'm not coding but I love create the game)
@@Kaleidosium Why? Please Link
@@Kaleidosium aha ok
I just saw the 2014 talk that started all this. Sounded really fantastic. So I have been skimming some other videos up to this point. So "two years" in the talk is now going on six years. And a number of games is one game. And neither compiler or game is done. Still I'm sure it is better than anything I could have done. At this rate you will be retired before this endeavor will ever prove cost effective. And yet anything worth doing involves sacrifice. I'm glad that I did not board this ship back in 2014. I think that you took the wrong approach. In my opinion I think that you should have come out with an open source toy compiler that would have done some good for hobbyist. What I have seen in this hour of further investigation gives me no reason to come back.
I wonder if Jai would do Delaunay triangulation even faster than c++/rust?
See comparison in this video:
ruclips.net/video/owcvg2YZ7Y8/видео.html
At 5:20
I guess pointers arithmitics should be like in C , bc that's what you expect by default , people are used to that ... also if you don't make it C-like people will endup most of the time deviding by sizeof(struct) which would be very annoying
he addressed this in the video 16:25
@@lm1338 I know he did , just confirming the importance of the point