PSA: these have since been scrapped from the language. default values in the bodies of structs still work, but not #constructor and #destructor.

@tech6hutch

3 жыл бұрын

What does he use instead? Regular functions, like Rust?

@10e999

3 жыл бұрын

What was the thinking ?

@lm1338

3 жыл бұрын

@@10e999 I've replied to this like three times but KZread seems to be taking the liberty to delete my comments for some reason kzread.info/dash/bejne/p46bxK2rdKjgcdY.html

@10e999

3 жыл бұрын

@@lm1338 Thanks for your time..

"So I have a... thing. It's not unlike the thing I showed before." Jonathon Blow 2017

@sssstupidkid1234

6 жыл бұрын

lol

14:45 Thank you! I never realized where the idea to have the constructor and destructor be made with the name of the class came from. Simply writing "constructor" and "destructor" just makes so much sense

there's some interesting sugar for declaring structs & constructors simultaneously I've seen somewhere that might be nice to copy.. struct (args){ fields with initialiser expressions } . omit args and it's just plain value initialisers. how about adding a haskell-esque 'where block' after such a struct to make this 'inbuilt default constructor' more capable. struct (args) { fields with initilializer expressions } where {more declarations using 'args' that the initialiser expressions can read}

Your courageous idea of writing Jai is inspiring even in 2019. The motivation bringing the constructors is good, but then one should face the consequences of impact on object copying procedure. I couldn't hear anything on that throughout the stream... so the danger of copying an already allocated resource instantly diminishes the benefit of having the c-tor at all. Resolving the issue of copying has 2 ways: the C++ way of operator overloading or the more restricted way by imposing a rule: a Jai object with the constructor is not copyable, the user must take ownership of the resource themselves. I wonder what will be the Jai's choice. Cheers.

Would just freeing the memory of heap allocated Things (with New) leak the memory of any buffer allocated within Thing? Destructor doesn't run on those then? (not calling Delete). Or am I confused?

@jblow888

7 жыл бұрын

Yeah, if you free without calling the destructor, then you are not calling the destructor!

I like the init thing because i can handle the failure. you could leverage the meta program to apply the 'check for init' thing if i wanted it in my build. i am against constructors, because of the (c++) locking that occurs (ie local static). In the end with singletons. you end up constructing, then calling an Init function anyway. To handle the cases where multiple singletons are inter connected.

@jblow888

7 жыл бұрын

The problem with 'check for init' is that it restricts the ways in which the user can instantiate the struct. Say you want to bury it 3 structs deep inside your own thing, that gets allocated at some time that the compiler has no visiblity into. How can your metaprogram check this?

@adama7752

7 жыл бұрын

Sorry, I was referring using the metaprogramming to add the bool 'wasInit' to the structure, and in all of the functions that use that structure. In a Debug build. Then in a Release build, remove all of that overhead. I think constructors add a lot of problems/corner cases with c++. C++ just makes me sad, because I _have_ to 1) use try/catch to handle any 'errors' that could occur from calling the constructor. or 2) have a 'bool failed' that can be checked after a constructor is called to ensure it was properly constructed. or 3) have a crazy style of always use some static function (think factory) to create an instance, and check for null. In the end, the program is calling an Init Function (Constructor). It's just a question of implicitly or explicitly, and how to handle errors. I hope that whatever you land on, it is as 'easy as possible' to handle error conditions, because I too am tired of dropped frames/crappy software. I'm just happy that you are making a difference; and you deserve a big thank you.

@jblow888

7 жыл бұрын

Oof. I think that is an intervention that is too heavyweight and that you don't want to do automatically. A lot of things might break. For example, the size of the struct is now different, and serialization/deserialization of the struct probably do not work unless people develop a lot of conventions around this kind of thing (which may happen, I don't know!)

Is there a quick summary article somewhere?

@ivanbraidi

7 жыл бұрын

github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md But this is not official or endorsed by Jon in any way.

I think the forward compatibility argument does not hold for many cases how about when you need more parameters for the initialization of thing? at some point you might for instance specifiy the allocator you whant to use at that point peaple who use your library have to call an init function with all the information required and it would be very easy to add the is_init flag at that point and assert on it now with a nice assert message you might hint at the user what was missing or that a change in the api happend go 80%-solution! :D

For the Buffer example, could you simply declare something like `current_buffer: *Buffer := base_buffer;` instead of using a constructor?

@jblow888

7 жыл бұрын

Not really, since base_buffer is not a constant -- it depends on the address of the struct. I had the option of programming some kind of special case for things like this, but it would make the language more confusing in other ways, and probably would not cover the majority of the cases that people need.

@LtLollo

7 жыл бұрын

if you wanted to extend Thing in a back compatible way you could stick in a relative pointer to the containing struct, with a syntax that allowed that. It would also be backwards compatible in the case if you where to returning Thing.

@blarghblargh

7 жыл бұрын

Gruel, that sort of thing would technically work for the initialization case, assuming the compiler could do it, but it would only work if you never plan to have the pointer point at something random on the heap in the non-initial case.

@LtLollo

7 жыл бұрын

yes, you are right, oh well...

what about you jon are you a constructor or a destructor?

@gettem6341

4 жыл бұрын

definitely a destructor

hey john, it would be so cool if you implemented an old school mode in your language, where you can only access 1.023 Mhz of cpu, 64 kb of ram, and like 1.5mb of drive space, so people can learn how to use new and delete, the correct way. lol lmao :D

@nameguy101

7 жыл бұрын

Most programs couldn't even be loaded into that amount of memory, because executables nowadays are shipped with runtimes that are fucking megabytes in size.

@needlessoptions

7 жыл бұрын

Just write your own VM if you want to do that

48:00 I really don't like the idea of the caller using a forwarder to fill out default arguments. Wouldn't it be simpler to have the function initialize its arguments to their defaults only if no value was provided? Or better yet, at compile time you could fudge the function call by having it autopopulate with the extra default arguments. Skip the middle man.

@jblow888

7 жыл бұрын

Iplywittrees If you try to write out the implementation details for how these things happen, you'll find they don't work.

Is it just me, or is there some weird desyncing going on between the audio and the video?

@HiAdrian

7 жыл бұрын

Yup, there is.

@nameguy101

7 жыл бұрын

Usually, audio lags behind video, which our brains are used to for distant sound sources. When video lags behind audio like it does here, it's totally inscrutable.

@derstreber2

7 жыл бұрын

The Light Mage yeah, if you find it too distracting, running the video at 1.25 X speed seems to improve it somewhat.

@linkVIII

7 жыл бұрын

I wonder how many game developers are bothered when they see a twitch export on youtube with desynched game audio

@ivanbraidi

7 жыл бұрын

I think they want nuke it! XD

09:27 Thing :: struct { value := 42; other_value := 5.7; name := "Hello, Sailor!"; buffer: Buffer; current_buffer: *Buffer; serial_number: int; } Why wouldn't it be possible to preserve the declarative way of initializing structs by allowing their members to be set to non-constant expressions and refer to other members of the struct? Thing :: struct { value := 42; other_value := 5.7; name := "Hello, Sailor!"; buffer: Buffer; current_buffer: *Buffer = *buffer; // *self.buffer, *this.buffer, or something. serial_number: int = next_serial_number + 1; // or get_next_serial_number() } { thing: Thing; do_somthing_with(*thing); }

@jblow888

7 жыл бұрын

Well, you'd be adding this into the language as a special hack, and the question is whether it actually solves a wide enough spectrum of problems to be worth having there.

Watch as he reimplements all the features of the other programming languages /jk

@SimGunther

7 жыл бұрын

Mauricio Fidalgo Hopefully he'll even implement lambda functions from haskell and write machine instructions in assembly like you can in c lol Also would want to be careful about avoiding the mistakes that php made with constructors/destructors that could potentially lead to huge security holes in your code - __ -

What I don't like about Jai, is the use of "::" i.e Something:: (....) why can't you just have Something: (....) or I prefer just Something.somethingelse. ? what is the design consideration for this?

@lm1338

5 жыл бұрын

the first colon means declaration, the second means constant. so `foo : int : 5` is an integer constant, `foo :: 5` is automatically inferred as an integer constant, `foo : int = 5` is a mutable integer, and `foo := 5` is inferred as a mutable integer.

I like un-readable code. I applaud the use of 0x7ffff_ffff as some constant. It's evil.

Just use D lang. That is allready complete language and 10x times better than c++.

@jblow888

7 жыл бұрын

D is better than C++ in most ways. But they made some unfortunate decisions. And my biggest problem with it is that it's still trying to be the same kind of thing C++ is. What I have realized is that this is the wrong target for the kind of field I like to work in. So a better version of C++ is just the wrong thing for me.

@collerblade

7 жыл бұрын

"But they made some unfortunate decisions" What are does? Im courius. "And my biggest problem with it is that it's still trying to be the same kind of thing C++ is" This sentense has no meaining at all. Besides that i would like to add a few comments on your language. 1. Remove "::" from everywhere. U are using them at least in 3 separated place [constant/define declarations (BUFFER_SIZE :: 1024), type definitions (Buffer :: struct) and function definitions (write_string :: .....)]. Using the same symbol in 3 different meaning is confusing to the user. Also u can freely remove them at will and the language is still easy to parse, because they have no meaning at all. 2. Remove ":" from type declarations. They has also no meaning. Just sugar. 3. Same with the function return type arrow sign ("->"). Its difficult to type and has no meaning at all. 4. Declarations are backwards. I played with pascal many years, so i have no problem with that. But anyone else who came from the C/C++/Java type languages are doomed to learn your way. In contrast D doesnt have any syntactic sugar, symbols means only one thing and it is very familiar with C sintax. So it is easy to understand, and fast to use for anyone. I have seen many people doing unnessesery work for years. This language is the same like mozilla's rust. They "invented" a language with 95% D in it. The leftover part is different but it is the worst part of the language, and they still changing that part constantly. This situation is very similar to the pointless heap of the linux distributions.....

@needlessoptions

7 жыл бұрын

collerblade So all your complaints are about the syntax rather than the actual language design and features lmao

@collerblade

7 жыл бұрын

just suggestions. And yes, language syntax matters. Somebody will use it (hopefuly)

@jblow888

7 жыл бұрын

You don't yet have enough programming language experience to be telling people how to design languages. It's fine to not have experience; everybody learns somehow. But it's not fine if, despite this, you go around telling people what to do; mainly, you will just look like a goofus and people will take you less-seriously in the future. Later in life, you want to be able to look back and not cringe at the things you said and did.