Demo: Iteration and arrays, uninitialized values, enums
ฝัง
- เผยแพร่เมื่อ 9 ธ.ค. 2014
- Further work on the programming language.
Features shown:
1: Build process
2: Syntax changes
3: Default values, explicit uninitialization
4: Array types
5: Iteration
6: Enum types
7: Inlining
The Q&A will be uploaded as a separate video.
Other pieces mentioned:
"C's Biggest Mistake", Walter Bright, December 2009.
www.drdobbs.com/architecture-a...
Chandler Carruth, "Optimizing the Emergent Structures of C++"
• 2013 Keynote: Chandler... - เกม
What do you guys think about Jon Blow's outfit? I realize it's not set in stone or anything and may even change in the future, and right now it's not even a part of his body really it's just something he adds in the morning when he gets dressed, but I think that as a general direction I prefer it to Stroustrup's or Alexandrescu's outfits, and I think it will allow us to get a lot done in a short amount of time, and doesn't have so many layers as to be stifling.
Exactly what I was thinking. As he mentioned several times, the syntax and all that user level interface is just a temporary thing to have someting tanglible in hand. All these might change in time even if they would have the smell of those above.
That shirt seems to say "I'm a dreamy guy that creates mystical game experiences yet deep inside I'm just a rational as fuck coder".
Had it been a t-shirt, he would have looked like a hippie.
Had it had a tropical print, he would have looked like stoner.
Had it lacked the tie die, he would have looked too plain.
It strikes the perfect balance.
As a game artist, I find these videos absolutely fascinating and highly insightful. Thank you for taking the time to bring our general knowledge base up and treating us as decent humans. I appreciate you, John
I need this language so bad
I never really think about it, but there are tons of times where non-local break and continue would be super useful. Very much looking forward to this language releasing!
Love the simple looping he has added, the it and it_index simplifies so much nonsense one often have to resort to in most programming languages. Good array support in the actual language is a great feature - as Jon say, when programming one is almost always just iterating over arrays all over the place.
You are full with surprising ideas!!!
Keep the good stuff going
I can't wait
Very impressed with how the language is coming along
Remove keyword in a loop. This is a nice idea. All ways I've used to remove element during iteration were weird.
IIDEA: remove could be implicit, like break and continue. if you don't specifiy the variable, it's the most inner loop.
keep it up, you brilliant man
47:51 - why not support iterating over multiple arrays simultaneously? You'd then have one variable storing the index and one array storing the value of all arrays at that index (or alternatively let the user define a name for the variable storing the value of each array).
So in this example you'd have something like:
for (enum.names, enum.values) {
printf("name: %s, value: %d", it[0], it[1]);
}
Then define a syntax for iterating over an enum like so:
for enum {
printf("name: %s, value: %d", it[0], it[1]);
}
Or:
for enum {
printf("name: %s, value: %d", name, value);
}
What you could do is use a number after break or continue to specify how many loops you want to break/continue. This removes the problem with unnamed loops. In your case, break 2; would break the inner and the outer loop.
The problem is that the meaning of "break 2" changes as soon as you paste that code or insert a loop around it.
hmmm,interesting point.
have you considered giving loops return values. One aspect of Rust I like a lot is the expression oriented syntax, great for avoiding (uninitialised) temporaries. I thought it would be nice to complete that with break expressions, and for...else. Then the question is how to combine with nested breaks.. "just syntax" but it seems syntax is a huge part of the exercise here. break label=value? break break value ('returning a break..') break(value) label, i'm sure there must be a pleasing option
+Jonathan Blow
Basic gives you slightly more control over what you want to break out of by saying "Exit For", "Exit Do", "Exit Select", etc.
Though again this doesn't work with multiple nested loops of the same kind.
Did you find a good solution to this yet? I have yet to see the newer videos and a lot of things can happen in 10 months.
Also I'd like to add that I love the pointer syntax with the ^ symbol. I might actually adapt this. Though I'll probably change the symbol because on qwertz keyboards it is just below the escape key. And it doesn't appear on screen immediately because it can be used to enter characters like ô or â (like ´ with í, ó, á and so on).
I have thought about the thing with the arrays too. I agree that the way C handles this is counterproductive. But at the same time I can't find a nice solution.
I like your reasoning behind a lot of this stuff. The hat ^ seems like a good bet for pointers, you'd say that using < and > for pointing towards and away from the type would also make sense but that's probably also used for templates/generics.
As for initialising default values - it would be great to have this like you've implemented. Just initialize everything unless I specifically tell you not to makes much more sense than the other way around. I also like how you did declare the Vector3 to have default values but later on you can still decide that it should not initialize those given values - so you can have the option to set this behaviour at the struct declaration level or at the variable itself which is pretty neat.
The way you talk about adding remove in an iterator loop sounds godsend to me. Every time you have the manipulate the array (or similar) you're iterating over is just a pain. Iterating over Lists in c# where you just .ToArray() the thing and remove it in the original list by object is just highly inefficient but on non-performant parts it keeps things simpler than to manipulate the index like that. Having it be an integral part of the loop itself sounds more logical and keeps things readable.
Also 'double' loops with both the index and the value at the same time - pretty neat.
Again with the inlining, having ultimate control over what the compiler does is desirable, if you know what you're doing. I wonder if there's a way to categorize different functions into groups based on their specifics so you can have a more generic way of addressing the inlining per category in your platform specific directives file, instead of having to define inlining per function - if that's even useful, I don't know.
In c# you can always loop through the array backwards with an index and then do RemoveAt(i).
for(int i=array.Count-1; i>=0; --i) { array.RemoveAt(i); }
Fredrik Malmer Good one hadn't thought of that. Still a pain when using foreach loops though?
Ralph Schaafsma
Which is why the c-up language (www.c-up.net) has foreachr to iterate in reverse.
his approach spares the repeat referencing of array.. i wonder if there'd be a way to generalise it almost like nested 'this's
+Phx Vyper (Loli Nekogirl) If you watch later videos you will find this statement is untrue (lack of generics). I just think C++ did a terrible job of implementing them (this is not a controversial opinion).
hey. in the next talk, i would love to hear your thoughts on the problems the compiler has with inlining in more depth.
Have you made any documents or specifications from your implementation?
Having a length attribute on an array is useful! But I wonder how well the language implementation works with memory alignment. How are arrays-of-arrays aligned, are there periodically "size_t" bytes stored? It wouldn't be the first time I've batch-uploaded stuff to the CPU or thrown over a socket.
The -run build_release() stuff is very similiar to how Unity does command-line builds. And it works very well there. A difference though is that in Unity the actual build is started by whatever you call, making it possible to do things after the build, such as handle errors or run code signing tools or whatever. In this language there are two ways I see this could be made. One is to go the unity route and have a specific build call made somewhere in the run function. Then one can put other things afterwards. An other option (which I think is better) is to have a -postrun or -successrun (or similiar) argument where one can specify what should be run after a successful build.
I think the directive for postrun is the cleanest of the options you named, maybe even shorten it to -post because chances are that will not be used anywhere else.
Originally, all functions/procedures were going to be closures however, the change in declaration for a function (:= to ::) has make be wonder if this closure behaviour has changed.
Also, will there be a style convention fix (like Go)? I notice that he using a variant of K&R indent style. If this is the case, that is fine as it is not hard to change styles but as long as it is not Whitesmiths or GNU indent style.
Hi. I think your videos are really cool. I thin you would benefit from looking at the Elixir language. Jose Valim has done an excellent job there, and although the languages serve different purposes, you seem to share some beliefs. Even so, my feeling is that Elixir is a few steps ahead of you..
1. The mix build system: Simple configuration management and the build in an elixir script file. The thing you showed with debug/release is basically standard here.
2. Metaprogramming: Elixir like yor system runs at compile time and runtime. But the way Elixir handles generated code as an AST is probably something you could use as well.
What's the rationale behind not having hashmaps in the compiler and providing it instead through the standard library? I realise thats a lot less work that could be spent on more pressing tasks but i dont really see any drawbacks provided all the more important work has been done
28:00 This is an old video but wasn't array decaying to pointer inherited from B? Not fair to blame C for that.
Being able to program the build process in the language itself is wonderful. I'm less sure about ^ for pointers. I mean, I just don't understand the benefits/motivation behind that: Even though it's the same character, I don't think anyone would confuse the meaning of * in the type signature with a dereference operator, just as they wouldn't confuse the meaning of ^ in your language (when used in the type signature) with an XOR operator.
I have spend a few months programming in C, and although I do not get confused about the meaning of *, I still do not like the way it works. I am sure that I would be more comfortable with using the address operator in the type definition of pointers.
Benjamin Pedersen Well ... now that I really think about it, I guess it's more sensible.
Benjamin Pedersen i accept it, because multiple pointer types are useful IMO. * carries no restrictions, but '&' tells you its' non-zero, non-offsetable. [] tells you its' offsetable, non-zero. C++ needs & to make overloads work well. Rust has '&' being a bit more like a restricted * but coming from C++ it does feel weird having to take addresses everywhere.. you begin to take it for granted that the cheapest possible parameter pass can be the least verbose
emacs for windows 7 ultimate x64 bits ? seeing just 32 bits version
Are you going to reimplement your compiler in your new language?
Has he tried using Go syntax highlighting rather than C++? This language is closer to Go than C++ so it would highlight better.
Does your language have "unlimited" stack depth?
Could you add more info about you on the video description? Like where you do your streams, and a web page?
not sure about a webpage but streams are twitch.tv/naysayer88 and twitter (if you use it) is twitter.com/Jonathan_Blow
Your progress looks very good. There are a few cpu/C system caveats that are not acknowledged here and I feel at least one is important.
while ( A ) {A--};
While A is non-zero decrement A. Many hardware tests of a variable versus zero are fast. Baked in as it were. Losing those would be a concern. What you specifically are handling with thing.count or thing.length was handled in arrays by having NULL pointers.
while ( *structure_ptr ) { /* do stuff */; structure_ptr = structure_ptr.next };
Your way (as of talk #4) could well produce fewer bugs but how fast is it compared to NULL pointer comparison. If that is never done in gaming than this is less of an issue. In my software it is a very, very common code sequence.
The other item, certainly less important, is that C was originally just a high level DEC assembly language. Specifically *(dst++) = *(src++); was one instruction of DEC code. Pre and post decrement were bits in the opcode so you could do both for source and destination (if I recall that particular one correctly, although why is unknown). Those functions might not be as important today but others might well be. Just food for thought.
I like the explicit uninitialization. It falls in line with the concepts I think languages should work towards. Languages should be safe by default, but permit you to discard the safeties for performance by explicitly telling the compiler that you know what you're doing.
Yay a new vid :D
Isn't "void" a better token than "---" to avoid default initialization like D langage do? Can be search with "= void" I think.
PS: If I am correct Visual Compiler add some memory checks and initialization when used in debug. I also notice than when you launch your game built in release from visual studio you have noticeable lower performances than when doing it manually outside of VS.
I'll love to be able to avoid initialization only in few particular cases during the declaration of the value.
Yes, D gives you names of enum values at compile time ("enum x = to!string(Foo.hello);"), if there is nothing for the runtime, just generate the translation table at compile time with traits (D doesn't give much for runtime reflexion as it is ease to do with compile time introspection. So there is libraries).
"void" already means something too different and there would be semantically ambiguous situations.
I know you may have very ambivalent feelings about Java, but I like the way they handle initialization. Nothing is initialized by default, but the compiler won't let you access (read) values of anything that's uninitialized, because there's never really a legitimate reason you would want to do this. More work for the compiler, but clean and simple but very safe.
+B1CL0PS | Fields in Java are initialized to 0, false, or null depending. Locals are left uninitialized, sure, but it's not "nothing".
Epic
You genius.
Remove in for loops is just so nice! I'm getting slightly annoyed every time I have to do otherwise!
I just noticed: nowhere in your code function declaration does define type of returned value. Is it that it is deduced or you just used void functions all the time?
Unless he made changes to this part of the syntax, "()" is the type of a function that takes no variables and has void as return-value. To give it an int as return value append " -> int".
For some reason it feels very strange to have f : float = 1; instead of float : f = 1; order. Maybe too used to C++ but I think the language could gain more momentum later on within game development if some of those things were slightly more C++:ish unless there are big benefits to change things around. I know there are reasons for changing it for the syntax to be clean but old dogs and all that. Will be fun to play around with this though, so looking forward to see how it develops in the coming months.
C-style notation leads to the "clockwise spiral rule" of parsing which leads to very difficult to read code. That's why the Go language chose a better declaration syntax.
I get your hesitance and why it looks weird, but personally I think this new style will be more appealing in the long run. The identifier is often the focus of the code, e.g. we multiply *x* and *y* regardless of their type/template, so it's nice to start with the name and specify its properties after.
thats the thing. if you defend every last aspect if C++ you'll be stuck with its' problems forever. it is hard to refactor code because the declaration syntax is so awkward. I'm with Blow on this - this superficial 'interface' issue is actually hugely important. Under the hood I actually like C++ a lot more than he does, but agree that the interface problems (syntax & headers) warrant a change. In my case , I think I'd simply be satisfied with something in the spirit of SPECS ... a resyntax of almost exactly the same language (tweaks like UFCS). But I can also see something quite a bit simpler, almost go minus the Gc could also be as productive for a lot less effort. if the language just has slices and intrinsic float4 you could still do a lot with a lot less complexity.
Great and a lot of promise. But "array.count" is confusing when all others are calling it "len" or "length".
Why do you not use emacs shell-mode rather than switching between a cmd window and emacs? I find emacs shell-mode very useful, and there's actually a cmd history.
Why not just make pointers an explicit data type?
ISnt handmade Hero the guy who helped on Braid?
He helped on The Witness. (Not sure about Braid).
why not just prefix pointers with an additional dot (point)?
"^" is also used as "and" in math and binary-XOR in java...
I would first get rid of semicolons. Imagine a for-loop with 1 extremely long lines or one line with "missing" semicolon:
for( variableName = veryVeryLongVariableName_orConstant; //+ tiny semicolon
variableName < someValueToCompareTo; //+ tiny semicolon
variableName++){ // without semicolon => confusing newbies which aren't already confused by the sequence in the for-brackets.
Just responding as though this were published yesterday.. probably my comments are complete irrelevant now, 5 years later, but you never know..
YAY for forced inlining! YES!
array.remove doesn't preserve the order? it's certainly more performant if it doesn't, I guess. What if you need a directly indexed structure that preserves its order across removes without developing holes?
remove is a keyword tied to the loop, like break and continue.
we went from := to ::, whats the difference?
:= means declaring a variable. :: is for declaring constants (you want procedures to be constant for performance reasons).
Conceptually the first colon means that we are declaring a variable, the second character specifies whether it is constant or not.
I kept staring at him thinking something's different but can't... quite... pinpoint it... hair! Hah. All right settling down. Newbie programmer here but still find it very interesting.
Maybe I missed the point here, but is there any special reason not to use the new c++ type initialization brackets { }? I find them very flexible and they would allow you to initialize the vector with different values than the default ones without using a constructor.
It is counter-productive to use the word "vector" to refer to a dynamic array. A vector is a matrix with one column or a quantity with magnitude and direction.
Top comments are about syntax... smdh
Kotlin 2.0