To sum up, your idea is to find clear lines between memory allocation, variables initialisation and memory deallocation. Why just not just consider these 3 parts a 3 "functions" you can "override" in your "object" definition ? It could be welcomed to add a keyword for declaring object "immutability" in order to implement compiler optimisations and assume thread safety.
If an object is not aware of how it allocates/optimizes its "fields"/"internal mechanism", I wonder how you will not face performance issues, but I think I must wait for the availability of code samples in Jay language :).
One thing that I don't think came up was implicit destructors. If a stuct contains other structs that do have destructors, are they called recursively, and if so, in what order? Other than that, I assume that no built in types have destructors as that would enable things like double free on aliased pointers. I'm pretty sure that by this point, a compile time linter should be all that's needed to implement Rust's lifetime system in Jai.
That feels wrong, I rarely find myself doing: init(a); init(b); free(a); free(b); But much more commonly: init(a); init(b); free(b); free(a); As it they are living in separate scopes and the scope of b is nested in the scope of a.
When I say it's the same order as constructors, I mean when visiting sub-structs. When scopes close, the order is the reverse of the constructors, just like defer. But these are two different things.
I posit that forward compatibility is actually a non-issue. If you need to add a constructor to a struct, you're fundamentally changing it and every call site should need to be examined for compatibility. This is especially true in Jai given Contexts' ability to override the allocator. I personally see constructors as a gateway drug to the darker side of OOP. They encourage thinking that a struct is a self-aware encapsulation of both data and behavior. I would much rather use factory functions (aka "make_thing functions" mentioned at 19:00), and a "this can only be constructed via a factory function" pragma against a struct. If you did made factory functions return via the stack, you would end up with a more expressive but less "magic" system. Factory functions have many advantages: you can have more than 1 of them, they have names so you can easily work out their purpose by just reading code, applications could define their own factory functions for library structs if needed, they potentially can hook into multiple return values in cases where several structs must be constructed side-by-side, and most importantly: they're just plain old functions with a pragma that makes them return their value on the stack. They are not indicators of a self-aware or black-box data structure.
As one who did program many years in Eiffel, i agree. I never understood why all the new languages don't come up with named constructors. You see that this language designers did not really look around a lot. Eiffel had so much good things. Like class based function/variable memeber access restrictions to certain classes (instead just public/private/protected)
I wish he would fully explain why he doesn't like certain things that are taken for granted as some sort of god-send in main stream programming. For example he mentions smart pointers here and in another steam he mentions entity component systems. I think when people ask these questions of why he doesn't like it he seems super defensive when I think most of the time people are generally curious. I personally never understood the need for smart pointers. Maybe they're nice when code gets so complex it's hard to tell who the owner is, which is just covering up for the fact that the design needs to change so that the owner is obvious and you don't need a smart pointer.
If I build a DLL containing a constructor which has default arguments, the forwarding constructor is baked into the DLL, right? So if I change the default value of an argument between version 1 and version 2 of my library, and I start consuming the v2 DLL in my project, it sounds like the effective parameters would depend on whether I invoke the method explicitly or through a constructor. For example, say I have foo.exe which consumes v1 of nice.dll. nice.dll v1: Thing :: struct { #constructor construct_thing; } construct_thing :: (using thing: *Thing, special := 1) { print("special=% ", special); } Now I want to update my version of nice.dll to the latest version. nice.dll v2: /* Thing is the same as before */ construct_thing :: (using thing: *Thing, special := 2) { print("special=% ", special); } Let's say foo.exe makes the following calls: t1: Thing; t2: Thing = ---; construct_thing(*t2); After I update nice.dll, I'd expect foo.exe to output the following: special=2 special=1 Is that true?
Dude, this is just a general problem. If usage of default arguments means that the compiler patches the untold values into all call sites statically, then your default values will depend on the version of the library of which the _user_ included the header. This is true of C++, and there's no way this can't be true of this language unless Jon deploys ugly runtime hacks.
Why wouldn't the call "construct_thing(*t2)" not use the updated default value of 2? The old default value is not known to the program in any way because you edited the source code and then compiled. I am pretty sure the new output would be: special=2 special=2
The idea is that he _didn't_ recompile the source code. He updated his library, which did indeed update his header file, but the program is still the same, having been compiled against an older version of the header file. The program now dynamically linked to the newer version, so the wrapper function (storing the new default arg in its code in the DLL) will yield different results from the direct function (storing the old default arg at the call site as patched into the program).
before in your videos you'd said that you'd increase your productivity by around 20%, through this programming language. Do you think having a jai os, and a jai ide, would double this value ? Also you think that programming on a commodore 64 type computer, with a non distracted mind, high resource pool, and programming as the main important aspect of the os that someone could increase their productivity ?
Haha, I have no way to estimate how much productivity would go up under those conditions ... too hypothetical. Not sure what you mean by "commodore 64 type computer" but if you mean something that is totally open to the programmer without lots of layers of weird abstraction, then I think yeah, totally.
i have a question, is their anything online, that talks about programming as a whole, you know programmers with 20+ years talking about the limitations of programming, and what the possibilities could be, and its methodology. And also about game design and programming, their are too many games that are just like toys(vaguely term), and aren't like films, that lead and inspire the imagination into awe.
i was looking around trying to find, the creation of programming, and looking for interviews by them trying to get a better understanding of programming, and find what their main goal was. its probably, like trying to get a toaster to work.
i find it very unusual that the c programming language was created a long time ago, and the idea hasn't changed much, everyone is programming like the cave men of before, with little documentation of it(if i'm not wrong). Little has evolved and their is no site, as a nucleus of everything programming.
I took a c++ oop class recently, and the teacher said OOP is the best thing you can use. I interrupted him and asked him, "Why do that when I can just call a procedure and gain those values I need?". He said, "Well, when inheriting, you can gain a persistent value that is needed for later.". That confused me, because I didn't know what he meant. Then I said, "Why not just do that within the procedure?". He couldn't answer that question....
It sounds to me that by "persistent value" he means a member variable on the object. But the non-OO way to do the same thing is to just have it be a member of a struct that you pass to the procedure.
OOP is not inherently bad, it's just misunderstood as a silver bullet and abused too much sometimes, further enhanced by languages like Java where it's pretty much forced onto the developer. It has its uses and applications.
To sum up, your idea is to find clear lines between memory allocation, variables initialisation and memory deallocation.
Why just not just consider these 3 parts a 3 "functions" you can "override" in your "object" definition ?
It could be welcomed to add a keyword for declaring object "immutability" in order to implement compiler optimisations and assume thread safety.
Because the "object" does not know anything about how the application wants to allocate or deallocate (and should not).
If an object is not aware of how it allocates/optimizes its "fields"/"internal mechanism", I wonder how you will not face performance issues, but I think I must wait for the availability of code samples in Jay language :).
If a function expression ( #bake_values ) works, does a function literal work? ie can you say
#constructor (x: *Thing) { ... }
Yes, I am pretty sure I did that at some point in the demo. Then, the quick lambdas x => ... are also function literals.
One thing that I don't think came up was implicit destructors. If a stuct contains other structs that do have destructors, are they called recursively, and if so, in what order?
Other than that, I assume that no built in types have destructors as that would enable things like double free on aliased pointers.
I'm pretty sure that by this point, a compile time linter should be all that's needed to implement Rust's lifetime system in Jai.
Yes, they are called recursively .. in the same order as the constructors. (I don't do the C++ backward thing.)
That feels wrong, I rarely find myself doing:
init(a); init(b); free(a); free(b);
But much more commonly:
init(a); init(b); free(b); free(a);
As it they are living in separate scopes and the scope of b is nested in the scope of a.
When I say it's the same order as constructors, I mean when visiting sub-structs. When scopes close, the order is the reverse of the constructors, just like defer. But these are two different things.
Good to hear regarding scopes. I understand that they are different, but in my view closely related, see:
ｈｔｔｐｓ://ｐａｓｔｅｂｉｎ.ｃｏｍ/ｔ1ｚＡＦＰＺＷ
Yeah, maybe! It's an easy change to make it go in either order.
I posit that forward compatibility is actually a non-issue. If you need to add a constructor to a struct, you're fundamentally changing it and every call site should need to be examined for compatibility. This is especially true in Jai given Contexts' ability to override the allocator.
I personally see constructors as a gateway drug to the darker side of OOP. They encourage thinking that a struct is a self-aware encapsulation of both data and behavior. I would much rather use factory functions (aka "make_thing functions" mentioned at 19:00), and a "this can only be constructed via a factory function" pragma against a struct. If you did made factory functions return via the stack, you would end up with a more expressive but less "magic" system. Factory functions have many advantages: you can have more than 1 of them, they have names so you can easily work out their purpose by just reading code, applications could define their own factory functions for library structs if needed, they potentially can hook into multiple return values in cases where several structs must be constructed side-by-side, and most importantly: they're just plain old functions with a pragma that makes them return their value on the stack. They are not indicators of a self-aware or black-box data structure.
As one who did program many years in Eiffel, i agree. I never understood why all the new languages don't come up with named constructors. You see that this language designers did not really look around a lot. Eiffel had so much good things. Like class based function/variable memeber access restrictions to certain classes (instead just public/private/protected)
I wish he would fully explain why he doesn't like certain things that are taken for granted as some sort of god-send in main stream programming. For example he mentions smart pointers here and in another steam he mentions entity component systems. I think when people ask these questions of why he doesn't like it he seems super defensive when I think most of the time people are generally curious. I personally never understood the need for smart pointers. Maybe they're nice when code gets so complex it's hard to tell who the owner is, which is just covering up for the fact that the design needs to change so that the owner is obvious and you don't need a smart pointer.
Smart Pointers make reference counting more reliable. I hope you don't want to seriously ask why we need reference counting?
If I build a DLL containing a constructor which has default arguments, the forwarding constructor is baked into the DLL, right? So if I change the default value of an argument between version 1 and version 2 of my library, and I start consuming the v2 DLL in my project, it sounds like the effective parameters would depend on whether I invoke the method explicitly or through a constructor.
For example, say I have foo.exe which consumes v1 of nice.dll.
nice.dll v1:
Thing :: struct {
#constructor construct_thing;
}
construct_thing :: (using thing: *Thing, special := 1) {
print("special=%
", special);
}
Now I want to update my version of nice.dll to the latest version.
nice.dll v2:
/* Thing is the same as before */
construct_thing :: (using thing: *Thing, special := 2) {
print("special=%
", special);
}
Let's say foo.exe makes the following calls:
t1: Thing;
t2: Thing = ---;
construct_thing(*t2);
After I update nice.dll, I'd expect foo.exe to output the following:
special=2
special=1
Is that true?
Dude, this is just a general problem.
If usage of default arguments means that the compiler patches the untold values into all call sites statically, then your default values will depend on the version of the library of which the _user_ included the header. This is true of C++, and there's no way this can't be true of this language unless Jon deploys ugly runtime hacks.
Not suggesting that it needs to work differently; just making sure that I understand correctly.
Why wouldn't the call "construct_thing(*t2)" not use the updated default value of 2? The old default value is not known to the program in any way because you edited the source code and then compiled.
I am pretty sure the new output would be:
special=2
special=2
The idea is that he _didn't_ recompile the source code. He updated his library, which did indeed update his header file, but the program is still the same, having been compiled against an older version of the header file. The program now dynamically linked to the newer version, so the wrapper function (storing the new default arg in its code in the DLL) will yield different results from the direct function (storing the old default arg at the call site as patched into the program).
before in your videos you'd said that you'd increase your productivity by around 20%, through this programming language. Do you think having a jai os, and a jai ide, would double this value ? Also you think that programming on a commodore 64 type computer, with a non distracted mind, high resource pool, and programming as the main important aspect of the os that someone could increase their productivity ?
Haha, I have no way to estimate how much productivity would go up under those conditions ... too hypothetical. Not sure what you mean by "commodore 64 type computer" but if you mean something that is totally open to the programmer without lots of layers of weird abstraction, then I think yeah, totally.
i have a question, is their anything online, that talks about programming as a whole, you know programmers with 20+ years talking about the limitations of programming, and what the possibilities could be, and its methodology. And also about game design and programming, their are too many games that are just like toys(vaguely term), and aren't like films, that lead and inspire the imagination into awe.
I guess there is a bunch of stuff like that, it's hard for me to point at anything specific though... maybe some other people here can comment.
i was looking around trying to find, the creation of programming, and looking for interviews by them trying to get a better understanding of programming, and find what their main goal was. its probably, like trying to get a toaster to work.
i find it very unusual that the c programming language was created a long time ago, and the idea hasn't changed much, everyone is programming like the cave men of before, with little documentation of it(if i'm not wrong). Little has evolved and their is no site, as a nucleus of everything programming.
I took a c++ oop class recently, and the teacher said OOP is the best thing you can use. I interrupted him and asked him, "Why do that when I can just call a procedure and gain those values I need?". He said, "Well, when inheriting, you can gain a persistent value that is needed for later.". That confused me, because I didn't know what he meant. Then I said, "Why not just do that within the procedure?". He couldn't answer that question....
I guess I should mention the topic of discussion was using inheritance to compare polymorphic variables from the inheritance.
I am going to show him this demo tomorrow on a 1 on 1 help session (students have those...)
It sounds to me that by "persistent value" he means a member variable on the object. But the non-OO way to do the same thing is to just have it be a member of a struct that you pass to the procedure.
OOP is not inherently bad, it's just misunderstood as a silver bullet and abused too much sometimes, further enhanced by languages like Java where it's pretty much forced onto the developer. It has its uses and applications.
Show us how to make some line puzzles please.