@@marcelstrzalka Yeah, you would think, I mean, hello, STD:: just has the BKNs ("best known methods") a bunch of common idioms, but I don't know. I certainly have noticed that for whatever reason, when STD starts getting used, that's when compile times start really ramping up and performance starts going through the floor. Then you add BOOST in, and both those things get exponentially worse.
I'm studying CS right now and as such I would never have anything to add to this but I gotta say that it is awesome to watch this and slowly feel that I understand more and more of it and then also learn a lot of new stuff at the same time. Perticulary to see where your next thoughts go after a perticular idea, what next thoughts you have after another. That is something you only learn by experience, something I hope to have one day.
Not sure if I agree with SOA vs AOS being defined at the struct level. It doesn't define any behavior for the struct itself it just defines how an array should map them out in memory. So wouldn't it make more sense for that to be something placed on the array instead? Especially if there's cases where you want to use the same struct in both capacities in a program.
I don't think size_of(type_of(val)) makes the whole thing any easier. By definition, size_of(val) is already the "size of type of val". So size_of(type_of(val)) reads in a misleading way, where actually it means "size of type of type of val" which is size_of(Type).
+Ivan Leben I think you are missing the problem. If size_of(val) always means "size of type of val", then how do you get the size of a type that is actually named by the variable (for example, a type parameter to a struct or some type T that was matched as [] *$T as a procedure parameter).
I have a question about syntax, sorry! :) isn't it be more logical to use this style for function and structs declaration? foo : (x: float) -> float = { ... } Vector3 : struct = { ... } analogous to the variable declaration: a : int = 5; P.S. as a reminder current style goes as foo := (x: float) -> float { ... } Vector3 := struct { ... }
I really appreciate these, you've given me such novel perspectives while I've been designing my own language. I started wanting to create a C superset and now I'm designing a statically typed functional meta-programming language and a bytecode VM 😂. I look forward to the public Jai release! Edit: can someone tell me what's the point of bake? I imagine you'd always want to bake unless it's a question of adding too much compilation time or bloating executable size
Time for a rant. Go has the 'short variable declaration' construct which I guess can be likened to 'auto'. I've found it to be profoundly annoying because you can look at a piece of code, say example code from the documentation, and not have any idea of what types are involved! I find its specification a bit handwavey too. It meshes poorly with shadowing, and for some reason you can't 'short declare' a member of a struct because quote "The := notation is a shorthand for common cases. It's not meant to cover every possible declaration one may write" (issue #6842). On top of that, the pervasive use of short declarations for things like 'err' in combination with the compile errors associated with redeclaration means you're likely to run into compile errors just because you moved a line a short distance. It's a poor worker who blames his tools, but some times maybe the tool wasn't designed properly.
+eloj imo That's due to bad programming, not necessarily a bad feature. Just like if you have variables named "asdf" you aren't going to have any idea what it's for (unless asdf _happens_ to be descriptive given your specific context). Same with auto thing = whatever.thing; rather than auto thing = new TypeNameThatTakesUpSpaceAndShouldntBeTypedTwice(... Which is when something like auto is helpful without losing any information. Or as demonstrated in the video, something like this to make sure two variables have the same type over time and code changes. Type a = ; type_of(a) b = ; // obviously will/should have same type as a // aka // auto b = a; b = ; // ^ extra typing, but still safer than just // type b = ; // which does not obviously state that the types should stay the same // of course, without implicit conversions that probably doesn't matter nearly as much Disclaimer: I'm not really a programmer though I've written very basic intro-things in C and watched tutorials for other languages like C++.
+Upyrev Vladimir He said he will release it to his circle of friends first in the near future, then enlarge that circle until an open "beta" I can't wait to try it out honestly, it's actually a hit on my productivity now that I think how much better the tools I use could be
@@ExCyberinoIt's still on private state. In one of the previous streams, Jonathan talked about wanting to iron out all the issues. He said that the more people adopt his language, the more time is wasted because of early errors and unfinished parts of the language. So he not so interested in expanding he's beta tester size. Yes, some people use it daily, but a minority. I suggest to relax and prepare to wait for more than few years.
I fell asleep at like 10:30 (est) last night during this. Then I woke up 4 hours later and couldn't fall back asleep till around 8. what a failure of a night for me. Could watch the vod back with chat on twitch but that would require using flash.
***** I use livestreamer for live streams with pop out chat. (made a ipython wrapper to complete names I follow and quality options so `t nay m` -> `livestreamer twitch.tv/naysayer99 medium`. typing is hard ya know)
If "stong typing" is defined as you say it around 2:40, then C is definitely not a strongly typed language. Implicit casting can cause a lot of confusion, as can variadic arguments (where type errors **can't** be caught and **will** subsequently cause undefined behaviour). And although they're becoming less commonplace in C++, C++ also includes some of these C semantics, and in turn could be argued to not exhibit "strong typing".
+Jonathan Blow | Where one doesn't cast, I feel like C has strong types. But it gives you the ability to cast so many things to so many other things and I personally don't see that as strong.
Kai Kyouretsu I was actually referring to the implicit casting rules rather than the explicit ones. I think explicit casting doesn't counter strong typing. I'm really talking about the rules that make CERT INT02-C a thing (e.g. `int si = -1; unsigned int ui = 1; assert(si < ui);` fails), which I think is the exact opposite of "when you pass a function something of the wrong type, the compiler will complain" (in this sense, I take < to be a function).
Stijn van Drongelen | I definitely understood you, just giving my own input. Allowing crazy casts sounds terrible to me :p (though I use them occasionally, of course...)
+Kai Kyouretsu C is strongly types exactly because it requires those explicit casts. Weak/Strong typing is about the how the languages deals with mismatched types. In a weakly typed language a type mismatch will either result in undefined behavior or implicit type conversion (also called coercion) (like what C does with floats and doubles). The trick is that C does it very rarely, while weakly typed languages like Javascript, Python, and PHP do it a lot (you can add strings to integers in PHP for example, and PHP will make the string into an int using a parse function). Explicit casts can be said to "weaken" or compromise the type system, but you are still strongly typed, because once you have a type you keep that type until you make it something else explicitly.
+Jonathan Blow can the array literal be extended -- or does that even already work -- to work with structs? as in Foo :: struct { a: u32; b: string; } foo := {:Foo: 10, "blah" };
I see 2 cases in this video where member-functions (or should I rather say "member-procedures") would make things easier: 1. When you do something like this: put :: (table: *$T/Table, key: T.Key_Type, value: T.Value_Type) { ... put :: (table: Table($K, $V), key: K, value: V) { ... Then having these procedures inside the struct could look like this: Table :: struct (Key_Type: Type, Value_Type: Type) { put :: (key: Key_Type, value: Value_Type) { ... } Key_Type on the procedure refers to Key_Type on the struct. 2. The size_of function would be less confusing. Type :: struct { size :: () -> int { return the size here } } print(u8.size()); // 8 a : u8 = 123; print(type_of(a).size()); // 8 b : Type = u8; print(b.size()); // 8 print(type_of(b).size()); // b is a Type and the Type struct is 4 bytes big so this outputs 4 print(type_of(b8)); // 4 So maybe that's a thing you might want to consider. I am not a game developer but how do you seperate different parts of your program? I am not only talking about namespaces like in .NET or Java, but I mean procedures which "belong to" a struct. Like the put-procedure belongs to the Table-struct. I imagine it would get pretty messy if all functions are available at all times. Say you are using the Table-class. You'll have procedures like put, remove, index_of and probably some way of getting the number of items stored. If you also need some other collection-like struct then you'll have procedures very similar in name. Wouldn't you get easily confused about what procedure to use on what list? And what if you have procedures which are "implementation details" of some struct? If you need to put them in the same scope as the struct itself then you'll be able to access it even though it is never intended to be used from "outside the struct". Think about something like Intellisense in Visual Studio. With member-procedures you can very quickly see what you can do with an object: a := new Table(string, int); a. When you type the dot after "a" in the second line, Intellisense will list you all member-procedures of the Table-struct. This is very helpful when you want to get a quick overview of what the struct can do. And private procedures are not visible here because whoever uses the Table-struct should not rely on the fact that these private methods are there.
+Ihrbekommtmeinen Richtigennamennicht Xtend (www.eclipse.org/xtend/) or also extension Methods in C# are a good example of separating the functions from data structures, but still preserving the dot notation. You can write: put(table, "a", 12) or table.put("a", 12) in first case it is "obvious" what will be called, in second case the compiler finds put which has table as first argument and calls it. I favour the clean separation between data and behaviour. Putting procedures in structs would be a step in the wrong direction IMHO. However I totally agree that discoverability is much simpler with dot notation. Or dot like notation, e.g ObjectiveC or SmallTalk don't have dot notation but the discoverability in those languages works the same. You write the "subject" and you can see what you can do with it. As a former IDE developer I can say that it will be an interesting challenge to bring good discoverability to a procedural language. I guess if something like dot notation is not desirable, the IDE would need a new paradigms. E.g. you write put and see all the types which can be used with it. Putting cursor on a literal hitting a shortcut and seeing a list of all procedures you can use it with in current context. Something like this.
Maxim Zaks Yes, I am very familiar with extension methods in C# and VB.NET (and the problems they come with). As I use mostly .NET I very rarely have types which are actually "plain old data types". But I can see how there are much more of these in low-level programs and that one would rather see them as "just data". I really hope Jon gives this a good thought.
+Ihrbekommtmeinen Richtigennamennicht the biggest problem with extension methods that I am stumbled upon was dereferencing NULL pointer inside the function/procedure. This gives me always a WTF moment even if I know that it could happen. I haven't seen Jai addressing, what Tony Hoare calls "my billion-dollar mistake". I think Swift solves it quite elegantly even under the circumstances that it has to bridge to C and ObjectiveC. +Jonathan Blow any comment on NULL pointers?
Maxim Zaks Yes, that's kinda surprising at first, but makes sense when you know how extension methods are called. There are two MSIL-OpCodes to call methods: call and callvirt. The latter one cares about overridden methods. "callvirt" cares about overridden methods. This obviously only works on instance methods and only if the instance is not null, which is why the C#-compiler also uses callvirt for most calls to non-virtual instance-methods. "call" however does not care about overridden methods and it can be used to call any method (both static and instance), not jsut instance ones. Extension methods are always static and what would normally be "this" is now just a normal argument. That's why it's not possible to use the callvirt opcode (which would do the null-check automatically). To get around the problem it would be necessary to emit code which explicitly checks for null and manually throws, either inside the extension method (which is weird when you call the extension like a normal method) or at every callsite (which is unnecessary when you already know that the receiver cannot be null). That seems like a lot of unnecessary work for little benefit which is probably why they did not do it. Also there may be reasonable scenarios where you want to be able to call extension methods on null or where it's not a problem (like treating null as an empty list). Regarding nulls in JAI (Jai? jai?): How much danger is there in a null-dereference? Does it just segfault and you don't know what happened or does it give you some form of stacktrace? Because dereferencing a null-pointer is always a bug in the code which should be fixed, I think the question should be "How easily can those bugs be found?". If it's "finding the hay in a needle-bale" hard then it may be worthwile to invent some way of working without null-pointers.
+Ihrbekommtmeinen Richtigennamennicht I guess virtual tables is why Jai doesn't have it in the first place. They complicate things, lookups can be very slow, you have to keep them in memory etc... This is also why I suggested extension methods, because those are just functions and you can keep things simple. About the null checks, there is no exception handling in Jai and I think Jon told in one of his video that he doesn't plan to implement those. Same reasons as virtual tables. It complicates the language enormously. I am not sure if Optional type for Jai is a good idea because it introduces a lot of additional concepts as well. The whole wrapping and und wrapping business brings a lot to a table. However extension methods on value types might be light enough. Value types has no problem of NULL pointer deref. What I suggested was something that Swift3 will introduce for C structs and there companion functions. github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md
I would like to download the source to follow along a little better. Sorry that I missed the timing of the stream, if someone would link the source for me I would appreciate it.
+Scy Certainly, if maximal rigour is the goal; but following that logic, it would have to be "bool1" and "bool4", which goes against at least my aesthetic preference.
+Engloutie. Then again, there is also "int" which is equivalent to "s64", but lets you express that "this variable is an integer, but i am not stating anything about its size". I think that would be consistent with "bool" (
Question about the enum for entity type stuff: to me what he was doing is almost textbook example for virtual functions. I'm trying to understand why traditionally the enum stuff is necessary. Is it simply because having a virtual function for everything is way too much? Or is following the vtblptr is already too slow? There is definitely something I'm missing, if someone could kindly point it out to me.
I've been programming computers since the early 80's, and I've done a lot of programming in all sorts of languages, and I completely disagree with the idea that programming in a loosely typed language is less rapid than programming in a strongly typed language. I diametricaly oppose that view. My experience is most definitely that loosely typed languages are a lot more rapid than strongly typed ones. However - I would not be in favor of making Jai a loosely typed language. Over the last.. 4 decades almost? ;O Gawd, I'm old! I've done a lot of programming in each of C, C++, C#, Python, PHP, and JavaScript, so I've had quite a bit of experience with strictly typed languages and loosely typed languages. For years I kind of went back and forth about which I preferred to use. The strict typing absolutely does reduce the amount of debugging you have to do, and it helps reduce the amount of time you spend wondering / trying to remember things like what types a method is expecting and what type it returns. If I've been programming in a strict language, and I have to maintain someone's loosly typed code, i find it incredibly annoying and frustrating that I can't tell right away what types something is expecting and returning! It feels like it takes a lot longer to figure out how some existing thing works. Despite all that, I have definitely come to the conclusion that loosely typed languages end up winning the rapidity contest by quite a wide margin, in the end. You absolutely can program a lot faster in a loosely typed language, despite all the advantages of strict typing because: It's so much easier to produce a working solution for a typical real world programming problem that the time saved by that ease just ends up dwarfing the time spent doing the debugging and "what is this and how does this work" kind of research that strict typing saves you from. It just really does. Let's say I find myself faced with some kind of buggery programming challenge, and I spend a morning trying to come up with a solution in C#. After several hours, I finish producing a program that is almost, but not quite all the way there. And then I think "Man, this shouldn't be be this hard. It shouldn't take this long. It shouldn't be be this awkward and involved. It shouldn't require this much code! I must not really be doing this in a good way. There's got to be better way to do it." So I'll cast about on the Internet and in books and try and see how other people have tried to do things like what I'm trying to do, and I'll spend the afternoon evolving the code, I may even completely start over a time or two and try out some different approaches, but as the day approaches it's end and the overtime is getting over-taxing, I still haven't really quite gotten it over the top. It handles most of the requirements, but not all of them, and while the code may be in much better shape than when I started, it still just feels like I'm having to go to a lot of trouble that I shouldn't be having to go to. So then I'll have kind of a rebellious thought: "What would a solution to this problem look like in JavaScript?" 20 or 30 minutes later I'll have a fully working program, and the amount of code is a lot less voluminous and actually a lot more clear. Because I didn't have to twist and bend and wrangle and scrape and/or use a whole bunch of kind of verbose and obtuse syntax to get the job done. And I find the same thing to be true of Python. The loose typing and ultra-convenient data structure handling and easy string manipulation and so on and so forth really does make it that much easier for me. And I'm no C# neophyte, either. I've spent years writing code in C# all day every day. So it's not that I don't know how to use C#. It really just is that much easier to solve typical problems using JavaScript or Python than C, C++ or C#. Now of course it may simply be that my intelligence is such that that's just the case for me personally, and a smarter person would be able to solve the problem just as quickly or nearly as quickly in a strictly typed language. That may certainly be. It wouldn't surprise me. (It might surprise people who know me, but not me.) But as I said to begin with, I would not advocate that Jai do loose typing. Because real loose typing can't really be achieved in a reasonable way by generating all the combinatorial boogles of versions of things at compile time! That's just a total fool's errand, imo. A wild goose chase. The only reasonable approach is for the binary code to react to discovered types at run time, and do the appropriate things depending on what it finds, and that's just not going to be possible to do in a way that performs nearly as well as binary code that doesn't need to do that. And while I want rapidity very badly, I want high performance more.
I think a lot of large Python projects end up kind of imploding under their own weight because as a Python program gets larger, the memory footprint gets out of control, and things like module namespace trees get to be unwieldly because of all the way overblown instantiation costs. Even if Python could somehow be made to perform well enough, I can imagine it taking 5 or 6 years instead of 3 or whatever to do The Witness in Python because of just fighting a losing battle with problems like that. Such an effort would probably devolve into efforts to embed Python in a C++ program or something, and split up the work done by Python into small chunks, and maybe even end up with multiple interpreter instances running simultaneously. So by the time you were done you would've spent a lot more time fighting with the tools than writing code. But as far as rapidity goes, my experience using both strict and loose languages has me solidly convinced that strict typing somehow ends up costing more than it saves. Because I know beyond a shadow of a doubt that I can write a program in 3 weeks in Python or JavaScript that would take me several months to produce in C# or C++. Despite all the help strict typing brings. It just makes it that much harder to produce a working solution. Now I haven't tried Jai. And from watching these videos, I see a lot of effort has been put into supporting a kind of duck typing and polymorphic programming. I don't know that I would use introspection and code generation much, because my goal would not be to change the program when varying circumstances arise, but rather to make my program do the right thing in varying circumstances. I might use introspecting to detect types at run time, but probably not, because I would just build in my own system for identifying my program's types to itself because consuming my domain specific type identification would require less code than doing all the navigation and drilling down and so on that accomplishing the same thing with generalized introspection would require. And probably a lot of my varying types would use the same structs anyway. I would do things with #place (unions) and such. But it may be that the duck typing and polymorphic support will make the kind of difference that using a loosly typed language makes. I'm very anxious to try it and see!
Having a "Type" type is great, imo. It's definitely needed and I feel like it's "the right thing to do". I don't know about using it at compile time to generate a gazillion versions of things. It would probably be me doing that. But if duck typing for whatever reason doesn't go far enough, in some particular circumstance, this way there's always just branching or switching based on a Type value.
Please don't confuse static typing with strong typing - what you are speaking of in the beginning of the video is static typing i.e. typechecking statically - before runtime. Dynamic typing is the opposite of static, where you typecheck at runtime. Both don't exclude strong or weak typing; strong typing is about guaranteeing something about the underlying value from the type of it, weak typing doesn't guarantee much.. I guess one of the best examples must be pointers in C, where the underlying value can come from anywhere - therefore weakly typed in this case. It is statically typed - and can in C be correctly "typed" but there is a weak binding to the value behind the type.
+Jonathan Blow Sorry if my comment came out in an annoying way - just believe that language and concepts are important; else we are just speaking 'past' each other. Also I think it's important to be very correct when one adresses a lot of people looking up to oneself
+somename When someone comes along and presumes that I don't understand what dynamic typing is and starts explaining it, that is just more tiring internet annnoyingness. *Several* times in the video I go out of my way to say "strong static typechecking" and "strong compile-time typechecking" -- there is no confusion on my part between strong/weak and static/dynamic -- but you decided there was because ... you felt like it based on one particular sentence where I wasn't pedantic enough? I don't even know. I am not sure how you expect I could have built this compiler without knowing the difference between strong and weak typing, or static and dynamic typing. Then you fall into the same trap as a lot of people and think that casting in C-like languages is "weak typing". It isn't. It is the ability to tell the compiler to change its mind about what the type of an expression is, which is necessary to get real work done in the real world. Several times in comments to these videos people have said that this makes C++ weakly typed, implying that languages would be better if they didn't let you cast, or at least that "strong typing" is only strong in the absence of casting, otherwise it is weak -- and that is just misguided, sorry.
The size_of confuses me a bit. I'm still not entirely clear on what it does. And by the looks of it, it seems like you aren't either :D Anyway, does size_of measure the size of the actual data represented by an instance of the type (what I'd expect, similar to C/C++), or does it measure the type instance associated with the type? I think it measures the former, but what throws me off is that you expected size_of(type_of(f : float)) to put the size of the Type type. If I understand correctly (maybe I misunderstand the type_of operator), that statement evaluates such that type_of(f) is float (the type, not the instance) and then size_of(float) and size_of(type_of(f)) should be identical exactly. What am I missing here? Side note - why do you have the underscore in size_of and type_of? I feel like that's just being pedantic. Maybe a remnant of when you had the extended literal size_of_X but seems unnecessary and annoying to leave on there after the fact. Please consider removing the underscore. Out of curiosity, what do you have in the Type struct? Do you plan (or have you already) on adding instance literals (that would be stored on the stack)? I mean similar to how your array literal is, but for classes/structs. So let's say you have: foo :: struct { a: int; b: bool; } Now I want to do something like: f: foo = { a: 1, b: true }; Or alternatively: f: foo = { 1, true }; Or: f: foo = new foo { 1, true }; Now, another thing that isn't entirely clear to me is the OOP side of things. You show usage of structs, which is great, but do you plan (or have you already) on adding traditional OOP classes to Jai? Like with member functions, a constructor, destructor, etc.? Also, does Jai use some header file system or do files directly #import other .Jai source files? What does the name Jai stand for? Or is it just the nicest sounding unused 3 letter word you could come up with? Would you consider switching the := operator to just be a simple =, or alternatively provide (or point to) an argument in favor of this symbol? Seems to me like an unnecessary extra character I'd put on 50% of my variables... Could you talk (or point to) more information about the build system? I saw this github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md which talks about the build somewhere, but I want to see a more thorough explanation. I'd really like some more technical clarification on what you have so far. Thanks a lot in advance. Is there somewhere to pull what you have and sniff around myself? Finally, I think this is my first comment on your videos, but I discovered your channel (and project...) a couple months back and although I haven't watched all the podcast-like-demo-thingies, I really love what you're doing. I love the language so far, for the most part, and genuinely appreciate that someone is actually doing this (I saw all of your videos where you pitch the idea of a language and talk about "someone needs to do it" and so on :). It's awesome, keep it up (I mean it, not just a cliche)!
+sharir1701 It is the same as sizeof in C, when acting on a type. It tells you how many bytes are required to store one instance of that type. The 4 that comes back from size_of(type_of(f)) is size_of(float), not size_of(Type). (Well, it happens to be size_of(Type) as well, but that is a coincidence.) I do not plan on doing OOP-related things. However, constructors and destructors might happen. (These are not necessarily OOP, if there is not a notion of inheritance and overriding and whatever else). There are already implicit constructors for data structures that initialize members to default values; the question is whether there will be user-definable constructors. There are no header files in this language. := is not an operator; the first : is the one that separates the identifier from the type definition; the = is an assignment. Writing := means you are omitting the type and letting type inference kick in. If you look at the playlist that contains this video, the first Demo in there will go into the build system in some detail. (Actually there are a couple later on that do this as well).
+Jonathan Blow First, thanks for responding. As for the size_of, I thought so, but in this video you seemed confused and say that the size_of(type_of(f)) should have returned size_of(Type). Oh really? That's surprising to me... I mean, I think most people would agree that OOP tools such as inheritance and polymorphism and interfacing is pretty convenient... I write a lot of C code, and I like C, don't get me wrong, but I think for a language that is supposed to be as frictionless and as fun to work with as possible, certain OOP options are a pretty big thing you should at least consider. I understand the two parts of : and = being different operators. What I meant is that you could make an "implicit" type inference work with just a =. It might make parsing ever so slightly harder, but really, it should be a big deal to have the assignment operator on a new variable name also be the declaration. I understand the counter argument for readability and marginal compiler speed increase, but I would personally rather have "f = 7.0;" instead of "f := 7.0;". Thanks!
John: Early on in the streams you mentioned how you disliked the variable-names like "this" because its ambiguous. Now you're doing something similar with the variable-type "type"? Why not something like "vartype" instead? Ex: 'This variable is a vartype type'.
+Kevin J. I don't understand the question. How is 'this' ambiguous? You might be taking something I made as a throwaway comment in one particular case and treating it as more serious than intended.
Yes, I could be mistaken but the issue lies with every-day language. While I'm no professional (come & gone), may I pose this example of something I encountered in collage: "This needs to be of type Person." "What does?" "This 'this' ... the instance." (... thanks Stroustrup). --- With the type Type, a similar play of works takes place: "What type is it?" "Type." "What type?" "The type is 'Type'." When reading the language, this isn't an issue but when two or more are discussing it, this strange double-meaning seems to contradict the simplicity of the language. It may just be small-potatoes though. I'll trust your opinion. Loving the language.
honest question: why don't you take a look at Zig language [1] and maybe look about teaming up with its creator? You REALLY seem to think alike about many things and you're arriving at similar enough solutions for almost everything! Also Zig is already gaining adoption and has chances of being popular outside of gaming too... We'd love to see nice clean "systems + gaming & simulations" language that would also end up working fine for ML/data-sci with some extra work! And whether you realize it or not, what you're building *is* a pretty damn good systems and data programming language. Anyway, keep up the good work regardless of what you choose to do! [1]: github.com/ziglang/zig
"... as I avoid all STDs in real life"... Savage.
Maybe you can tell us about your favorite cpp "remove-erase idiom"? This is pure nonsense.
@@marcelstrzalka Yeah, you would think, I mean, hello, STD:: just has the BKNs ("best known methods") a bunch of common idioms, but I don't know. I certainly have noticed that for whatever reason, when STD starts getting used, that's when compile times start really ramping up and performance starts going through the floor. Then you add BOOST in, and both those things get exponentially worse.
I'm studying CS right now and as such I would never have anything to add to this but I gotta say that it is awesome to watch this and slowly feel that I understand more and more of it and then also learn a lot of new stuff at the same time. Perticulary to see where your next thoughts go after a perticular idea, what next thoughts you have after another. That is something you only learn by experience, something I hope to have one day.
How’s your CS study going?
I second that@@nintendude794
This is awesome. You're slowly approaching the power of dependent types here. Can't wait to try out using JAI for some type theory stuff :^)
One day he'll put in enough features to match Haskell :^^))))
Is it too much now ? lolllllllllllllll
@@nameguy101
Hang on, I'll grab something to eat before I watch the video.
I'm always super excited to see a new one of this series.
Not sure if I agree with SOA vs AOS being defined at the struct level. It doesn't define any behavior for the struct itself it just defines how an array should map them out in memory. So wouldn't it make more sense for that to be something placed on the array instead? Especially if there's cases where you want to use the same struct in both capacities in a program.
137213 is not prime. It's 43*3191. 137219 is the smallest prime greater than 137213.
I don't think size_of(type_of(val)) makes the whole thing any easier. By definition, size_of(val) is already the "size of type of val". So size_of(type_of(val)) reads in a misleading way, where actually it means "size of type of type of val" which is size_of(Type).
+Ivan Leben I think you are missing the problem. If size_of(val) always means "size of type of val", then how do you get the size of a type that is actually named by the variable (for example, a type parameter to a struct or some type T that was matched as [] *$T as a procedure parameter).
I have a question about syntax, sorry! :)
isn't it be more logical to use this style for function and structs declaration?
foo : (x: float) -> float = {
...
}
Vector3 : struct = {
...
}
analogous to the variable declaration:
a : int = 5;
P.S. as a reminder current style goes as
foo := (x: float) -> float {
...
}
Vector3 := struct {
...
}
+Upyrev Vladimir No, because then the thing on the right doesn't have a complete type outside the context of the thing on the left.
I really appreciate these, you've given me such novel perspectives while I've been designing my own language. I started wanting to create a C superset and now I'm designing a statically typed functional meta-programming language and a bytecode VM 😂. I look forward to the public Jai release!
Edit: can someone tell me what's the point of bake? I imagine you'd always want to bake unless it's a question of adding too much compilation time or bloating executable size
You cannot bake if the value to bake isn't known at compile time.
Time for a rant. Go has the 'short variable declaration' construct which I guess can be likened to 'auto'. I've found it to be profoundly annoying because you can look at a piece of code, say example code from the documentation, and not have any idea of what types are involved!
I find its specification a bit handwavey too. It meshes poorly with shadowing, and for some reason you can't 'short declare' a member of a struct because quote "The := notation is a shorthand for common cases. It's not meant to cover every possible declaration one may write" (issue #6842).
On top of that, the pervasive use of short declarations for things like 'err' in combination with the compile errors associated with redeclaration means you're likely to run into compile errors just because you moved a line a short distance.
It's a poor worker who blames his tools, but some times maybe the tool wasn't designed properly.
+eloj imo That's due to bad programming, not necessarily a bad feature. Just like if you have variables named "asdf" you aren't going to have any idea what it's for (unless asdf _happens_ to be descriptive given your specific context).
Same with
auto thing = whatever.thing;
rather than
auto thing = new TypeNameThatTakesUpSpaceAndShouldntBeTypedTwice(...
Which is when something like auto is helpful without losing any information. Or as demonstrated in the video, something like this to make sure two variables have the same type over time and code changes.
Type a = ;
type_of(a) b = ; // obviously will/should have same type as a
// aka
// auto b = a; b = ;
// ^ extra typing, but still safer than just
// type b = ;
// which does not obviously state that the types should stay the same
// of course, without implicit conversions that probably doesn't matter nearly as much
Disclaimer: I'm not really a programmer though I've written very basic intro-things in C and watched tutorials for other languages like C++.
Jonathan, could you estimate when the compiler for jai will be available for the public? Will it be available in 2016?
+Upyrev Vladimir He said he will release it to his circle of friends first in the near future, then enlarge that circle until an open "beta"
I can't wait to try it out honestly, it's actually a hit on my productivity now that I think how much better the tools I use could be
so how's the waiting?
@@AlFredo-sx2yy Still not opened to public. I'll wait and see what's to offer here :)
what about now ?@@MrKinein
@@ExCyberinoIt's still on private state.
In one of the previous streams, Jonathan talked about wanting to iron out all the issues. He said that the more people adopt his language, the more time is wasted because of early errors and unfinished parts of the language.
So he not so interested in expanding he's beta tester size. Yes, some people use it daily, but a minority.
I suggest to relax and prepare to wait for more than few years.
I fell asleep at like 10:30 (est) last night during this. Then I woke up 4 hours later and couldn't fall back asleep till around 8. what a failure of a night for me. Could watch the vod back with chat on twitch but that would require using flash.
*****
I use livestreamer for live streams with pop out chat. (made a ipython wrapper to complete names I follow and quality options so `t nay m` -> `livestreamer twitch.tv/naysayer99 medium`. typing is hard ya know)
If "stong typing" is defined as you say it around 2:40, then C is definitely not a strongly typed language. Implicit casting can cause a lot of confusion, as can variadic arguments (where type errors **can't** be caught and **will** subsequently cause undefined behaviour). And although they're becoming less commonplace in C++, C++ also includes some of these C semantics, and in turn could be argued to not exhibit "strong typing".
+Stijn van Drongelen I think you are picking nits. My definition of strong typing definitely includes C and C++.
+Jonathan Blow | Where one doesn't cast, I feel like C has strong types. But it gives you the ability to cast so many things to so many other things and I personally don't see that as strong.
Kai Kyouretsu I was actually referring to the implicit casting rules rather than the explicit ones. I think explicit casting doesn't counter strong typing. I'm really talking about the rules that make CERT INT02-C a thing (e.g. `int si = -1; unsigned int ui = 1; assert(si < ui);` fails), which I think is the exact opposite of "when you pass a function something of the wrong type, the compiler will complain" (in this sense, I take < to be a function).
Stijn van Drongelen | I definitely understood you, just giving my own input. Allowing crazy casts sounds terrible to me :p (though I use them occasionally, of course...)
+Kai Kyouretsu C is strongly types exactly because it requires those explicit casts. Weak/Strong typing is about the how the languages deals with mismatched types. In a weakly typed language a type mismatch will either result in undefined behavior or implicit type conversion (also called coercion) (like what C does with floats and doubles). The trick is that C does it very rarely, while weakly typed languages like Javascript, Python, and PHP do it a lot (you can add strings to integers in PHP for example, and PHP will make the string into an int using a parse function).
Explicit casts can be said to "weaken" or compromise the type system, but you are still strongly typed, because once you have a type you keep that type until you make it something else explicitly.
+Jonathan Blow can the array literal be extended -- or does that even already work -- to work with structs? as in
Foo :: struct {
a: u32;
b: string;
}
foo := {:Foo: 10, "blah" };
I see 2 cases in this video where member-functions (or should I rather say "member-procedures") would make things easier:
1. When you do something like this:
put :: (table: *$T/Table, key: T.Key_Type, value: T.Value_Type) { ...
put :: (table: Table($K, $V), key: K, value: V) { ...
Then having these procedures inside the struct could look like this:
Table :: struct (Key_Type: Type, Value_Type: Type) {
put :: (key: Key_Type, value: Value_Type) { ...
}
Key_Type on the procedure refers to Key_Type on the struct.
2. The size_of function would be less confusing.
Type :: struct {
size :: () -> int { return the size here }
}
print(u8.size()); // 8
a : u8 = 123;
print(type_of(a).size()); // 8
b : Type = u8;
print(b.size()); // 8
print(type_of(b).size()); // b is a Type and the Type struct is 4 bytes big so this outputs 4
print(type_of(b8)); // 4
So maybe that's a thing you might want to consider.
I am not a game developer but how do you seperate different parts of your program? I am not only talking about namespaces like in .NET or Java, but I mean procedures which "belong to" a struct. Like the put-procedure belongs to the Table-struct. I imagine it would get pretty messy if all functions are available at all times. Say you are using the Table-class. You'll have procedures like put, remove, index_of and probably some way of getting the number of items stored. If you also need some other collection-like struct then you'll have procedures very similar in name. Wouldn't you get easily confused about what procedure to use on what list? And what if you have procedures which are "implementation details" of some struct? If you need to put them in the same scope as the struct itself then you'll be able to access it even though it is never intended to be used from "outside the struct".
Think about something like Intellisense in Visual Studio. With member-procedures you can very quickly see what you can do with an object:
a := new Table(string, int);
a.
When you type the dot after "a" in the second line, Intellisense will list you all member-procedures of the Table-struct. This is very helpful when you want to get a quick overview of what the struct can do. And private procedures are not visible here because whoever uses the Table-struct should not rely on the fact that these private methods are there.
+Ihrbekommtmeinen Richtigennamennicht Xtend (www.eclipse.org/xtend/) or also extension Methods in C# are a good example of separating the functions from data structures, but still preserving the dot notation.
You can write: put(table, "a", 12) or table.put("a", 12)
in first case it is "obvious" what will be called, in second case the compiler finds put which has table as first argument and calls it.
I favour the clean separation between data and behaviour. Putting procedures in structs would be a step in the wrong direction IMHO.
However I totally agree that discoverability is much simpler with dot notation. Or dot like notation, e.g ObjectiveC or SmallTalk don't have dot notation but the discoverability in those languages works the same. You write the "subject" and you can see what you can do with it.
As a former IDE developer I can say that it will be an interesting challenge to bring good discoverability to a procedural language. I guess if something like dot notation is not desirable, the IDE would need a new paradigms. E.g. you write put and see all the types which can be used with it. Putting cursor on a literal hitting a shortcut and seeing a list of all procedures you can use it with in current context. Something like this.
Maxim Zaks
Yes, I am very familiar with extension methods in C# and VB.NET (and the problems they come with).
As I use mostly .NET I very rarely have types which are actually "plain old data types". But I can see how there are much more of these in low-level programs and that one would rather see them as "just data".
I really hope Jon gives this a good thought.
+Ihrbekommtmeinen Richtigennamennicht the biggest problem with extension methods that I am stumbled upon was dereferencing NULL pointer inside the function/procedure. This gives me always a WTF moment even if I know that it could happen. I haven't seen Jai addressing, what Tony Hoare calls "my billion-dollar mistake". I think Swift solves it quite elegantly even under the circumstances that it has to bridge to C and ObjectiveC. +Jonathan Blow any comment on NULL pointers?
Maxim Zaks
Yes, that's kinda surprising at first, but makes sense when you know how extension methods are called. There are two MSIL-OpCodes to call methods: call and callvirt. The latter one cares about overridden methods. "callvirt" cares about overridden methods. This obviously only works on instance methods and only if the instance is not null, which is why the C#-compiler also uses callvirt for most calls to non-virtual instance-methods.
"call" however does not care about overridden methods and it can be used to call any method (both static and instance), not jsut instance ones.
Extension methods are always static and what would normally be "this" is now just a normal argument. That's why it's not possible to use the callvirt opcode (which would do the null-check automatically).
To get around the problem it would be necessary to emit code which explicitly checks for null and manually throws, either inside the extension method (which is weird when you call the extension like a normal method) or at every callsite (which is unnecessary when you already know that the receiver cannot be null). That seems like a lot of unnecessary work for little benefit which is probably why they did not do it. Also there may be reasonable scenarios where you want to be able to call extension methods on null or where it's not a problem (like treating null as an empty list).
Regarding nulls in JAI (Jai? jai?): How much danger is there in a null-dereference? Does it just segfault and you don't know what happened or does it give you some form of stacktrace? Because dereferencing a null-pointer is always a bug in the code which should be fixed, I think the question should be "How easily can those bugs be found?". If it's "finding the hay in a needle-bale" hard then it may be worthwile to invent some way of working without null-pointers.
+Ihrbekommtmeinen Richtigennamennicht I guess virtual tables is why Jai doesn't have it in the first place. They complicate things, lookups can be very slow, you have to keep them in memory etc... This is also why I suggested extension methods, because those are just functions and you can keep things simple. About the null checks, there is no exception handling in Jai and I think Jon told in one of his video that he doesn't plan to implement those. Same reasons as virtual tables. It complicates the language enormously. I am not sure if Optional type for Jai is a good idea because it introduces a lot of additional concepts as well. The whole wrapping and und wrapping business brings a lot to a table. However extension methods on value types might be light enough. Value types has no problem of NULL pointer deref. What I suggested was something that Swift3 will introduce for C structs and there companion functions. github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md
I would like to download the source to follow along a little better. Sorry that I missed the timing of the stream, if someone would link the source for me I would appreciate it.
How about "boole" or "boolean" and "bool" rather than "bool1"?
+Engloutie. indicating memory size sometimes helps optimization. "bool" doesn't necessarily mean it only stores 1 bit.
+Scy Certainly, if maximal rigour is the goal; but following that logic, it would have to be "bool1" and "bool4", which goes against at least my aesthetic preference.
+Engloutie. It is for consistency with the other types: s8, s32, s64, float64, etc.
+Jonathan Blow I was mainly taken aback by the inconsistency of "bool and bool1", but I suppose nobody really suggested that explicitly.
+Engloutie. Then again, there is also "int" which is equivalent to "s64", but lets you express that "this variable is an integer, but i am not stating anything about its size". I think that would be consistent with "bool" (
Question about the enum for entity type stuff: to me what he was doing is almost textbook example for virtual functions. I'm trying to understand why traditionally the enum stuff is necessary. Is it simply because having a virtual function for everything is way too much? Or is following the vtblptr is already too slow? There is definitely something I'm missing, if someone could kindly point it out to me.
+Buken Li The simple answer is that it comes down to performance. Virtual functions are slower, one of the cases for this is branch mispredictions.
+Jonathan Blow please provide the link to the demo.jai in the description to this video.
+Serge Ratke dl.dropboxusercontent.com/u/2970717/demo.jai
+clankill3r guys, i already have the file. however, someone who's not following jon on twitter won't be able to get the file.
+Serge Ratke Then why didn't you provide the link :)
+clankill3r because i hope jon does that in the information to this video, instead of it being buried somewhere in the comments?
@@freiherrvonundzu but now it’s further buried in a comment on your comment instead :p
I've been programming computers since the early 80's, and I've done a lot of programming in all sorts of languages, and I completely disagree with the idea that programming in a loosely typed language is less rapid than programming in a strongly typed language. I diametricaly oppose that view. My experience is most definitely that loosely typed languages are a lot more rapid than strongly typed ones. However - I would not be in favor of making Jai a loosely typed language.
Over the last.. 4 decades almost? ;O Gawd, I'm old! I've done a lot of programming in each of C, C++, C#, Python, PHP, and JavaScript, so I've had quite a bit of experience with strictly typed languages and loosely typed languages. For years I kind of went back and forth about which I preferred to use. The strict typing absolutely does reduce the amount of debugging you have to do, and it helps reduce the amount of time you spend wondering / trying to remember things like what types a method is expecting and what type it returns. If I've been programming in a strict language, and I have to maintain someone's loosly typed code, i find it incredibly annoying and frustrating that I can't tell right away what types something is expecting and returning! It feels like it takes a lot longer to figure out how some existing thing works.
Despite all that, I have definitely come to the conclusion that loosely typed languages end up winning the rapidity contest by quite a wide margin, in the end. You absolutely can program a lot faster in a loosely typed language, despite all the advantages of strict typing because: It's so much easier to produce a working solution for a typical real world programming problem that the time saved by that ease just ends up dwarfing the time spent doing the debugging and "what is this and how does this work" kind of research that strict typing saves you from. It just really does.
Let's say I find myself faced with some kind of buggery programming challenge, and I spend a morning trying to come up with a solution in C#. After several hours, I finish producing a program that is almost, but not quite all the way there. And then I think "Man, this shouldn't be be this hard. It shouldn't take this long. It shouldn't be be this awkward and involved. It shouldn't require this much code! I must not really be doing this in a good way. There's got to be better way to do it." So I'll cast about on the Internet and in books and try and see how other people have tried to do things like what I'm trying to do, and I'll spend the afternoon evolving the code, I may even completely start over a time or two and try out some different approaches, but as the day approaches it's end and the overtime is getting over-taxing, I still haven't really quite gotten it over the top. It handles most of the requirements, but not all of them, and while the code may be in much better shape than when I started, it still just feels like I'm having to go to a lot of trouble that I shouldn't be having to go to. So then I'll have kind of a rebellious thought:
"What would a solution to this problem look like in JavaScript?"
20 or 30 minutes later I'll have a fully working program, and the amount of code is a lot less voluminous and actually a lot more clear. Because I didn't have to twist and bend and wrangle and scrape and/or use a whole bunch of kind of verbose and obtuse syntax to get the job done.
And I find the same thing to be true of Python. The loose typing and ultra-convenient data structure handling and easy string manipulation and so on and so forth really does make it that much easier for me. And I'm no C# neophyte, either. I've spent years writing code in C# all day every day. So it's not that I don't know how to use C#. It really just is that much easier to solve typical problems using JavaScript or Python than C, C++ or C#.
Now of course it may simply be that my intelligence is such that that's just the case for me personally, and a smarter person would be able to solve the problem just as quickly or nearly as quickly in a strictly typed language. That may certainly be. It wouldn't surprise me. (It might surprise people who know me, but not me.)
But as I said to begin with, I would not advocate that Jai do loose typing. Because real loose typing can't really be achieved in a reasonable way by generating all the combinatorial boogles of versions of things at compile time! That's just a total fool's errand, imo. A wild goose chase. The only reasonable approach is for the binary code to react to discovered types at run time, and do the appropriate things depending on what it finds, and that's just not going to be possible to do in a way that performs nearly as well as binary code that doesn't need to do that.
And while I want rapidity very badly, I want high performance more.
I think a lot of large Python projects end up kind of imploding under their own weight because as a Python program gets larger, the memory footprint gets out of control, and things like module namespace trees get to be unwieldly because of all the way overblown instantiation costs. Even if Python could somehow be made to perform well enough, I can imagine it taking 5 or 6 years instead of 3 or whatever to do The Witness in Python because of just fighting a losing battle with problems like that. Such an effort would probably devolve into efforts to embed Python in a C++ program or something, and split up the work done by Python into small chunks, and maybe even end up with multiple interpreter instances running simultaneously. So by the time you were done you would've spent a lot more time fighting with the tools than writing code.
But as far as rapidity goes, my experience using both strict and loose languages has me solidly convinced that strict typing somehow ends up costing more than it saves. Because I know beyond a shadow of a doubt that I can write a program in 3 weeks in Python or JavaScript that would take me several months to produce in C# or C++. Despite all the help strict typing brings. It just makes it that much harder to produce a working solution.
Now I haven't tried Jai. And from watching these videos, I see a lot of effort has been put into supporting a kind of duck typing and polymorphic programming. I don't know that I would use introspection and code generation much, because my goal would not be to change the program when varying circumstances arise, but rather to make my program do the right thing in varying circumstances. I might use introspecting to detect types at run time, but probably not, because I would just build in my own system for identifying my program's types to itself because consuming my domain specific type identification would require less code than doing all the navigation and drilling down and so on that accomplishing the same thing with generalized introspection would require. And probably a lot of my varying types would use the same structs anyway. I would do things with #place (unions) and such. But it may be that the duck typing and polymorphic support will make the kind of difference that using a loosly typed language makes. I'm very anxious to try it and see!
Having a "Type" type is great, imo. It's definitely needed and I feel like it's "the right thing to do". I don't know about using it at compile time to generate a gazillion versions of things. It would probably be me doing that. But if duck typing for whatever reason doesn't go far enough, in some particular circumstance, this way there's always just branching or switching based on a Type value.
@@shavais33 Where do the types really get into your way, can you give an example?
Please don't confuse static typing with strong typing - what you are speaking of in the beginning of the video is static typing i.e. typechecking statically - before runtime.
Dynamic typing is the opposite of static, where you typecheck at runtime. Both don't exclude strong or weak typing; strong typing is about guaranteeing something about the underlying value from the type of it, weak typing doesn't guarantee much.. I guess one of the best examples must be pointers in C, where the underlying value can come from anywhere - therefore weakly typed in this case. It is statically typed - and can in C be correctly "typed" but there is a weak binding to the value behind the type.
+somename Sigh.
+Jonathan Blow Sorry if my comment came out in an annoying way - just believe that language and concepts are important; else we are just speaking 'past' each other. Also I think it's important to be very correct when one adresses a lot of people looking up to oneself
+somename When someone comes along and presumes that I don't understand what dynamic typing is and starts explaining it, that is just more tiring internet annnoyingness. *Several* times in the video I go out of my way to say "strong static typechecking" and "strong compile-time typechecking" -- there is no confusion on my part between strong/weak and static/dynamic -- but you decided there was because ... you felt like it based on one particular sentence where I wasn't pedantic enough? I don't even know. I am not sure how you expect I could have built this compiler without knowing the difference between strong and weak typing, or static and dynamic typing. Then you fall into the same trap as a lot of people and think that casting in C-like languages is "weak typing". It isn't. It is the ability to tell the compiler to change its mind about what the type of an expression is, which is necessary to get real work done in the real world. Several times in comments to these videos people have said that this makes C++ weakly typed, implying that languages would be better if they didn't let you cast, or at least that "strong typing" is only strong in the absence of casting, otherwise it is weak -- and that is just misguided, sorry.
The size_of confuses me a bit. I'm still not entirely clear on what it does. And by the looks of it, it seems like you aren't either :D
Anyway, does size_of measure the size of the actual data represented by an instance of the type (what I'd expect, similar to C/C++), or does it measure the type instance associated with the type? I think it measures the former, but what throws me off is that you expected size_of(type_of(f : float)) to put the size of the Type type. If I understand correctly (maybe I misunderstand the type_of operator), that statement evaluates such that type_of(f) is float (the type, not the instance) and then size_of(float) and size_of(type_of(f)) should be identical exactly. What am I missing here?
Side note - why do you have the underscore in size_of and type_of? I feel like that's just being pedantic. Maybe a remnant of when you had the extended literal size_of_X but seems unnecessary and annoying to leave on there after the fact. Please consider removing the underscore.
Out of curiosity, what do you have in the Type struct?
Do you plan (or have you already) on adding instance literals (that would be stored on the stack)? I mean similar to how your array literal is, but for classes/structs. So let's say you have:
foo :: struct {
a: int;
b: bool;
}
Now I want to do something like:
f: foo = { a: 1, b: true };
Or alternatively:
f: foo = { 1, true };
Or:
f: foo = new foo { 1, true };
Now, another thing that isn't entirely clear to me is the OOP side of things. You show usage of structs, which is great, but do you plan (or have you already) on adding traditional OOP classes to Jai? Like with member functions, a constructor, destructor, etc.?
Also, does Jai use some header file system or do files directly #import other .Jai source files?
What does the name Jai stand for? Or is it just the nicest sounding unused 3 letter word you could come up with?
Would you consider switching the := operator to just be a simple =, or alternatively provide (or point to) an argument in favor of this symbol? Seems to me like an unnecessary extra character I'd put on 50% of my variables...
Could you talk (or point to) more information about the build system? I saw this github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md which talks about the build somewhere, but I want to see a more thorough explanation.
I'd really like some more technical clarification on what you have so far. Thanks a lot in advance. Is there somewhere to pull what you have and sniff around myself?
Finally, I think this is my first comment on your videos, but I discovered your channel (and project...) a couple months back and although I haven't watched all the podcast-like-demo-thingies, I really love what you're doing. I love the language so far, for the most part, and genuinely appreciate that someone is actually doing this (I saw all of your videos where you pitch the idea of a language and talk about "someone needs to do it" and so on :). It's awesome, keep it up (I mean it, not just a cliche)!
+sharir1701 It is the same as sizeof in C, when acting on a type. It tells you how many bytes are required to store one instance of that type. The 4 that comes back from size_of(type_of(f)) is size_of(float), not size_of(Type). (Well, it happens to be size_of(Type) as well, but that is a coincidence.)
I do not plan on doing OOP-related things. However, constructors and destructors might happen. (These are not necessarily OOP, if there is not a notion of inheritance and overriding and whatever else). There are already implicit constructors for data structures that initialize members to default values; the question is whether there will be user-definable constructors.
There are no header files in this language.
:= is not an operator; the first : is the one that separates the identifier from the type definition; the = is an assignment. Writing := means you are omitting the type and letting type inference kick in.
If you look at the playlist that contains this video, the first Demo in there will go into the build system in some detail. (Actually there are a couple later on that do this as well).
+Jonathan Blow First, thanks for responding.
As for the size_of, I thought so, but in this video you seemed confused and say that the size_of(type_of(f)) should have returned size_of(Type).
Oh really? That's surprising to me... I mean, I think most people would agree that OOP tools such as inheritance and polymorphism and interfacing is pretty convenient... I write a lot of C code, and I like C, don't get me wrong, but I think for a language that is supposed to be as frictionless and as fun to work with as possible, certain OOP options are a pretty big thing you should at least consider.
I understand the two parts of : and = being different operators. What I meant is that you could make an "implicit" type inference work with just a =. It might make parsing ever so slightly harder, but really, it should be a big deal to have the assignment operator on a new variable name also be the declaration. I understand the counter argument for readability and marginal compiler speed increase, but I would personally rather have "f = 7.0;" instead of "f := 7.0;".
Thanks!
Do you know when the next stream will happen?
+Nameguy Probably within a week
+clankill3r Longer now, he wants to get more things done.
mr blow in what program do you make yout videogames?
ok thank you bro
+Mr Raybeik Dunno if you took that as the game development program "Scratch", what he meant is that he writes his own engines and editors in C++.
Thank you too bro
John: Early on in the streams you mentioned how you disliked the variable-names like "this" because its ambiguous. Now you're doing something similar with the variable-type "type"? Why not something like "vartype" instead?
Ex: 'This variable is a vartype type'.
+Kevin J. I dunno, for me Type is fine
+Kevin J. I don't understand the question. How is 'this' ambiguous? You might be taking something I made as a throwaway comment in one particular case and treating it as more serious than intended.
Yes, I could be mistaken but the issue lies with every-day language. While I'm no professional (come & gone), may I pose this example of something I encountered in collage: "This needs to be of type Person." "What does?" "This 'this' ... the instance." (... thanks Stroustrup). --- With the type Type, a similar play of works takes place: "What type is it?" "Type." "What type?" "The type is 'Type'."
When reading the language, this isn't an issue but when two or more are discussing it, this strange double-meaning seems to contradict the simplicity of the language.
It may just be small-potatoes though. I'll trust your opinion. Loving the language.
"While I'm no professional" aaand here it comes
Menko, I don't know what you are adding to the conversation here but my point their is that I no longer program professionally.
honest question: why don't you take a look at Zig language [1] and maybe look about teaming up with its creator? You REALLY seem to think alike about many things and you're arriving at similar enough solutions for almost everything! Also Zig is already gaining adoption and has chances of being popular outside of gaming too... We'd love to see nice clean "systems + gaming & simulations" language that would also end up working fine for ML/data-sci with some extra work! And whether you realize it or not, what you're building *is* a pretty damn good systems and data programming language.
Anyway, keep up the good work regardless of what you choose to do!
[1]: github.com/ziglang/zig