www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [Semi OT] Language for Game Development talk

reply Max Klyga <max.klyga gmail.com> writes:
Jonathan Blow just recorded a talk about the needs and ideas for a 
programming language for game developer.

https://www.youtube.com/watch?v=TH9VCN6UkyQ

This talk mentions D quite a lot of times.
D is mentioned as the most probable to be adopted if it were possible 
for frictionless interaction with existing codebase.
An interesting talk if you want to look at language design from game 
developer perspective.
Sep 19 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/19/14, 4:47 PM, Max Klyga wrote:
 Jonathan Blow just recorded a talk about the needs and ideas for a
 programming language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were possible
 for frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design from game
 developer perspective.
Awesome, thanks. More evidence that we're putting our chips on seamless C++ compatibility. Andrei
Sep 19 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Max Klyga:

 https://www.youtube.com/watch?v=TH9VCN6UkyQ
I like the focus on correctness of the Rust language (but currently Rust seems to ignore several kinds of correctness, focusing only on two kinds), but I understand that the needs of creating a modern browser (that is a long lived project, where like in a kernel the correctness is very important, and the speed of writing code is not important) are different from the needs of creating a modern video game. So he chooses differently than Rust. It's a long talk. He doesn't like exceptions, not GCs. Several of the things he says are already present in D, but he is looking for a language that is simpler than D. He suggests code like this (the syntax is not so important) in his new language: -------------------------- struct Mesh { Vector3 []! positions; int []! indices; joint positions Vector2 []! uvs; joint positions } mesh.positions.reserve(num_vertices); mesh.indices.reserve(num_indices); mesh.uvs.reserve(num_vertices); -------------------------- "int []" seems like a D dynamic array, it contains the pointer to the data and its length. The "!" means the memory of this array is owned by the Mesh stuct. So when the Mesh instantiation goes out of scope, all the memory it owns gets deallocated. The " joint" annotation means that the memory of "indices" array is allocated in the same chunk of memory used to allocate "positions". The same happens for "uvs" array. So when you create a Mesh you allocate only one chunk of memory for its owned dynamic arrays. "mesh.positions.reserve" allocates memory for the positions array of the instance "mesh", but the compiler sees the (optional) " joint" annotation, and merges the three allocations into a single one and then slices the memory for the three arrays (i think the compiler raises a compilation error if it can't merge them well). He also likes an explicit simple syntax for nullable pointers. I think the compiler enforces the presence of the null test for nullable pointers (perhaps as in the Whiley language): -------------------------- void do_something(Entity ?a) { if (a) { a.x = 0; } } -------------------------- Bye, bearophile
Sep 19 2014
next sibling parent reply "po" <yes no.com> writes:
  He actually talks about Andre around 40' ;0

As a fellow game dev:

I don't agree with him about RAII, I find it useful

He kind of has a point about exceptions, I'm not big on them


I get the impression his C++ knowledge is about the level of C++ 
with classes, ie very low.

He claims using std:: inherently causes slow compilation, my 
experience says otherwise.

He goes on about "freeing free'd memory", this is never something 
that would happen in modern C++, so he is basically proposing an 
inferior language design.


  At one point he says you can't see the contents of std::vector 
in a debugger. What? This is trivial and has worked in every 
version of Visual Studio for the last 5+ years.

  I do agree the build systems used with C++ are idiotic

IMO, C++'s complexity is largely because of the stupid headers 
and all the mind numbing crap associated with it. That and the 
lack of any reflection.
Sep 19 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 20.09.2014 04:25, schrieb po:
   He actually talks about Andre around 40' ;0

 As a fellow game dev:

 I don't agree with him about RAII, I find it useful
He seems to miss the point that it is possible to write general purpose RAII templated classes, since he keeps on talking about specific implementations for each type of resources.
 He kind of has a point about exceptions, I'm not big on them
Exceptions in most programming languages that have them are a good idea. Exceptions in C++ are a broken concept. Having to cope with C semantics, ability to disable them and mixing code bases is what leads to the pain of writing exception safe code in C++.
 I get the impression his C++ knowledge is about the level of C++ with
 classes, ie very low.
At the end he states having only read K&R C, with everything else being learning on the job, it seems.
 He claims using std:: inherently causes slow compilation, my experience
 says otherwise.
Back when I was stil working with C++ at day job, doing a "make world" in a code base with Tools.h++ would cost a few hours. And we were using ClearMake optimized build infrastructure. You can have fast builds, but it requires knowledge of the whole architecture and coding for the build system, e.g. separating modules into real libraries.
 He goes on about "freeing free'd memory", this is never something that
 would happen in modern C++, so he is basically proposing an inferior
 language design.


   At one point he says you can't see the contents of std::vector in a
 debugger. What? This is trivial and has worked in every version of
 Visual Studio for the last 5+ years.
It also surprised me. Visual Studio has the best developer experience in terms of visualizing C++ data structures.
   I do agree the build systems used with C++ are idiotic

 IMO, C++'s complexity is largely because of the stupid headers and all
 the mind numbing crap associated with it. That and the lack of any
 reflection.
I wonder if modules in C++17 will already be too late. By then, when looking at C++ project, it might be pre-C++98, C++11, C++14, C++17 with the accumulated set of semantics, differences and styles each standard revision brings to the table. -- Paulo
Sep 20 2014
prev sibling next sibling parent Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 20/09/2014 04:25, po a écrit :
   He actually talks about Andre around 40' ;0

 As a fellow game dev:

 I don't agree with him about RAII, I find it useful

 He kind of has a point about exceptions, I'm not big on them


 I get the impression his C++ knowledge is about the level of C++ with
 classes, ie very low.

 He claims using std:: inherently causes slow compilation, my experience
 says otherwise.
Maybe on some systems it's almost impossible to use pre-compiled headers?
 He goes on about "freeing free'd memory", this is never something that
 would happen in modern C++, so he is basically proposing an inferior
 language design.


   At one point he says you can't see the contents of std::vector in a
 debugger. What? This is trivial and has worked in every version of
 Visual Studio for the last 5+ years.
Maybe he don't use VS? I am using QtCreator for Android and Windows, I can tell you I have troubles with std::string,... I am waiting for llvm and lld for the replacement of gdb under Windows.
   I do agree the build systems used with C++ are idiotic

 IMO, C++'s complexity is largely because of the stupid headers and all
 the mind numbing crap associated with it. That and the lack of any
 reflection.
Sep 24 2014
prev sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Saturday, 20 September 2014 at 02:25:31 UTC, po wrote:
 As a fellow game dev:

 I don't agree with him about RAII, I find it useful

 He kind of has a point about exceptions, I'm not big on them
...
 He goes on about "freeing free'd memory", this is never 
 something that would happen in modern C++, so he is basically 
 proposing an inferior language design.
It happens when you don't use RAII. Sounds like he should review his concepts. Regarding exceptions, they can be used incorrectly, but I think they tend to provide better error handling than return codes *because no one ever checks return codes*. And when you do pathologically handle error codes, the amount of code duplication can be tremendous, and the chance for errors involving improper cleanup can be quite high. Though again, RAII can be of incredible use here.
  At one point he says you can't see the contents of std::vector 
 in a debugger. What? This is trivial and has worked in every 
 version of Visual Studio for the last 5+ years.
std::string tends to be more complicated because of the small string optimization. Most debuggers I've used don't handle that correctly out of the box, even if sorting it out really isn't difficult.
Sep 25 2014
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 25 September 2014 at 22:52:39 UTC, Sean Kelly wrote:
 On Saturday, 20 September 2014 at 02:25:31 UTC, po wrote:
 As a fellow game dev:

 I don't agree with him about RAII, I find it useful

 He kind of has a point about exceptions, I'm not big on them
...
 He goes on about "freeing free'd memory", this is never 
 something that would happen in modern C++, so he is basically 
 proposing an inferior language design.
It happens when you don't use RAII. Sounds like he should review his concepts.
This is really missing the point. He knows RAII is useful and he knows RAII solves freeing free'd memory. Maybe it's time to re-watch the video.
Sep 25 2014
parent "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 25 September 2014 at 23:04:08 UTC, Peter Alexander 
wrote:
 This is really missing the point. He knows RAII is useful and 
 he knows RAII solves freeing free'd memory. Maybe it's time to 
 re-watch the video.
I was replying to the comments. Sorry if I misunderstood.
Sep 25 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 3:52 PM, Sean Kelly wrote:
 Regarding exceptions, they can be used incorrectly, but I think they tend to
 provide better error handling than return codes *because no one ever checks
 return codes*.  And when you do pathologically handle error codes, the amount
of
 code duplication can be tremendous, and the chance for errors involving
improper
 cleanup can be quite high.  Though again, RAII can be of incredible use here.
Yup. A very common source of bugs in C code is all the incorrectly written "if (error) goto cleanup;" code. Exceptions and RAII take care of most of that.
Sep 25 2014
prev sibling parent reply "po" <yes no.com> writes:
 std::string tends to be more complicated because of the small 
 string optimization.  Most debuggers I've used don't handle 
 that correctly out of the box, even if sorting it out really 
 isn't difficult.
Almost all game developers use Visual Studio, and VS has supported visualization of all STL containers(including string) since VS2005.
This is really missing the point. He knows RAII is useful and he 
knows RAII solves freeing free'd memory. Maybe it's time to 
re-watch the video.
I watched it. None of what he said made much sense. His claims: 1. RAII is bad because exceptions. -Nothing forces to use exceptions, so irrelevant 2. RAII is bad because you must write copy constructor,destructor etc each time. -No you write a few basic template classes and reuse them.
Regarding exceptions, they can be used incorrectly, but I think 
they tend to provide better error handling than return codes 
*because no one ever checks return codes*.  And when you do 
pathologically handle error codes, the amount of code 
duplication can be tremendous, and the chance for errors 
involving improper cleanup can be quite high.  Though again, 
RAII can be of incredible use here.
That is all true, I agree that exceptions are better than error codes. But for games, the general design is that errors are impossible. The game should never fail so exceptions serve little purpose. -ran out of memory? Shut game down, this should not happen -couldn't open a file? Shut game down, this should never happen -out of bounds array access, invalid iterator etc: abort game, found during development, fixed, should never happen. -networking? This is one place where you do need to handle errors, but do you need exceptions just to handle this one case? Probably not
Sep 26 2014
next sibling parent "po" <yes no.com> writes:
  More stupidity from JB:

  At one point he talks about merging the memory of Mesh's 
positions & indices & UV, but he does this manually like a 
friggin moron;0

  The proper way is using an allocator, but I'm guessing JB 
doesn't grok allocators- "cause they be weird templates stuff 
derp!" & "templates r slow, derp!"
Sep 26 2014
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 07:24:48 UTC, po wrote:
  I watched it. None of what he said made much sense.
 His claims:
 1. RAII is bad because exceptions.
   -Nothing forces to use exceptions, so irrelevant
 2. RAII is bad because you must write copy 
 constructor,destructor etc each time.
   -No you write a few basic template classes and reuse them.
The way I interpreted him: - He does not want exceptions. - RAII makes most sense if you have exceptions. - He want to share views to memory blocks without RC - He needs debugging aids to resolve free() issues - He does not want to write new classes to manage resources (not only memory, but shaders etc). - Writing useful classes in C++ => tedious boilerplate. He might not say it explicitly, but he seemed to assume people to hold those views. So that probably means he usually works with people who code in the same patterns.
 -ran out of memory? Shut game down, this should not happen
On IOS or PNaCl you might have to accept that it may happen...
Sep 26 2014
parent reply "po" <yes no.com> writes:
 - RAII makes most sense if you have exceptions.
RAII is orthogonal to exceptions, so his claim is nonsense.
 - He does not want to write new classes to manage resources 
 (not only memory, but shaders etc).
I manage all resources using RAII, it did not require me to write a new RAII class for each resource type. I suspect he thinks that to implement RAII for a Mesh class you would need to create constructor/copy constructor/destructor. This is not how it is actually done. Instead the vertices/indices wrapped by an RAII template type. You can see on one slide he attempts to use std::unique_ptr<> but his syntax is completely wrong, a good indication he doesn't actually have any clue how this stuff works.
 - Writing useful classes in C++ => tedious boilerplate.
I saw his claim, but again it is nonsense. In C++ we rarely if ever manually write copy constructor/move constructor/destructor. These are auto generated 99% of the time. His claim comes out of ignorance of how to properly use C++.
 He might not say it explicitly, but he seemed to assume people 
 to hold those views. So that probably means he usually works 
 with people who code in the same patterns.
I've worked with people who think exactly like him. They are generally somewhat older, and started programming games in the 80/90's. I was not impressed by the coding ability of the individuals I met who had this mentality. If he updated his toolbox he might not have spent 5 years working on his latest game--
Sep 26 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 08:59:04 UTC, po wrote:
  I've worked with people who think exactly like him. They are 
 generally somewhat older, and started programming games in the 
 80/90's. I was not impressed by the coding ability of the 
 individuals I met who had this mentality.
I'm not surprised, but if you are going to create a language for current practices you have to cater to whatever the practice is. They are probably less eager to relearn how to use C/C++. I also think many just don't want to attempt to deal with C++ std:: libs, due to bad experience with them in the past. So they use their own stuff instead.
Sep 26 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 2:11 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Friday, 26 September 2014 at 08:59:04 UTC, po wrote:
  I've worked with people who think exactly like him. They are generally
 somewhat older, and started programming games in the 80/90's. I was not
 impressed by the coding ability of the individuals I met who had this
mentality.
I'm not surprised, but if you are going to create a language for current practices you have to cater to whatever the practice is. They are probably less eager to relearn how to use C/C++. I also think many just don't want to attempt to deal with C++ std:: libs, due to bad experience with them in the past. So they use their own stuff instead.
I can understand the attitude. I tend to do the same thing. Including invent another programming language :-)
Sep 26 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 26 September 2014 at 08:59:04 UTC, po wrote:
 - RAII makes most sense if you have exceptions.
RAII is orthogonal to exceptions, so his claim is nonsense.
 - He does not want to write new classes to manage resources 
 (not only memory, but shaders etc).
I manage all resources using RAII, it did not require me to write a new RAII class for each resource type. I suspect he thinks that to implement RAII for a Mesh class you would need to create constructor/copy constructor/destructor. This is not how it is actually done. Instead the vertices/indices wrapped by an RAII template type. You can see on one slide he attempts to use std::unique_ptr<> but his syntax is completely wrong, a good indication he doesn't actually have any clue how this stuff works.
 - Writing useful classes in C++ => tedious boilerplate.
I saw his claim, but again it is nonsense. In C++ we rarely if ever manually write copy constructor/move constructor/destructor. These are auto generated 99% of the time. His claim comes out of ignorance of how to properly use C++.
 He might not say it explicitly, but he seemed to assume people 
 to hold those views. So that probably means he usually works 
 with people who code in the same patterns.
I've worked with people who think exactly like him. They are generally somewhat older, and started programming games in the 80/90's. I was not impressed by the coding ability of the individuals I met who had this mentality. If he updated his toolbox he might not have spent 5 years working on his latest game--
And I also question his skills given that he admits the only programming book he has ever read was K&R C. So most likely he has very fragile bases from googling around and stuff. -- Paulo
Sep 26 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 08:59:04 UTC, po wrote:
 - RAII makes most sense if you have exceptions.
RAII is orthogonal to exceptions, so his claim is nonsense.
Just a note: this isn't really true. RAII was initially used to deal with exceptions. If you want fast backtracking and just reset the stack pointer (rather than unwinding) then stack-allocated RAII objects won't work since they will be overwritten. You need to maintain a list of "destructors" in thread local memory or close to the stack root so that you can close files etc. Whether RAII is the best option really depends on what kind of execution patterns and performance characteristics you are aiming for.
Sep 26 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 26 September 2014 at 09:24:19 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 26 September 2014 at 08:59:04 UTC, po wrote:
 - RAII makes most sense if you have exceptions.
RAII is orthogonal to exceptions, so his claim is nonsense.
Just a note: this isn't really true. RAII was initially used to deal with exceptions.
This is completely not true, we were using RAII in C++ before any compiler had real support for exceptions. In the 90's exceptions were still being discussed at ANSI/ISO with very few compiler offering support for them. And those that did, suffered from implementation bugs. -- Paulo
Sep 26 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 09:41:09 UTC, Paulo  Pinto wrote:
 This is completely not true, we were using RAII in C++ before 
 any compiler had real support for exceptions.
Well, I haven't read the 1990 edition of the annotated C++ reference by Stroustrup and Ellis since the mid 90s so my memory may be clouded, but that is how I remember it. And wikipedia says the same: «The technique was developed for exception-safe resource management in C++[3] during 1984–89» http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
Sep 26 2014
next sibling parent "po" <yes no.com> writes:
«The technique was developed for exception-safe resource
 management in C++[3] during 1984–89»

 http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
It may have been developed for exceptions, that doesn't mean you have to use them together. Alternative error reporting methods I prefer: -return optional type, is empty if it failed -accept continuation of what to do once operation secedes ie: open_file("blah.txt", [](file& f){..}}//called when it opened successfully //could also have a 2nd lambda for when it fails
Sep 26 2014
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 26 September 2014 at 10:01:32 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 26 September 2014 at 09:41:09 UTC, Paulo  Pinto 
 wrote:
 This is completely not true, we were using RAII in C++ before 
 any compiler had real support for exceptions.
Well, I haven't read the 1990 edition of the annotated C++ reference by Stroustrup and Ellis since the mid 90s so my memory may be clouded, but that is how I remember it. And wikipedia says the same: «The technique was developed for exception-safe resource management in C++[3] during 1984–89» http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
I don't care what Wikipedia says, I was there in the early C++ days happily using Turbo and Borland C++ in MS-DOS. -- Paulo
Sep 26 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 4:02 AM, Paulo Pinto wrote:
 On Friday, 26 September 2014 at 10:01:32 UTC, Ola Fosheim Grøstad wrote:
 On Friday, 26 September 2014 at 09:41:09 UTC, Paulo  Pinto wrote:
 This is completely not true, we were using RAII in C++ before any compiler
 had real support for exceptions.
Well, I haven't read the 1990 edition of the annotated C++ reference by Stroustrup and Ellis since the mid 90s so my memory may be clouded, but that is how I remember it. And wikipedia says the same: «The technique was developed for exception-safe resource management in C++[3] during 1984–89» http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
I don't care what Wikipedia says, I was there in the early C++ days happily using Turbo and Borland C++ in MS-DOS.
I wrote a C++ compiler in 1987. Nobody had ever heard of exceptions. Bjarne's 1986 "The C++ Programming Language" does not mention RAII or exceptions, but does say on pg. 158: "Calling constructors and destructors for static objects serves an extremely important function in C++. It is the way to ensure proper initialization and cleanup of data structures in libraries."
Sep 26 2014
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 26.09.2014 20:46, schrieb Walter Bright:
 On 9/26/2014 4:02 AM, Paulo Pinto wrote:
 On Friday, 26 September 2014 at 10:01:32 UTC, Ola Fosheim Grøstad wrote:
 On Friday, 26 September 2014 at 09:41:09 UTC, Paulo  Pinto wrote:
 This is completely not true, we were using RAII in C++ before any
 compiler
 had real support for exceptions.
Well, I haven't read the 1990 edition of the annotated C++ reference by Stroustrup and Ellis since the mid 90s so my memory may be clouded, but that is how I remember it. And wikipedia says the same: «The technique was developed for exception-safe resource management in C++[3] during 1984–89» http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
I don't care what Wikipedia says, I was there in the early C++ days happily using Turbo and Borland C++ in MS-DOS.
I wrote a C++ compiler in 1987. Nobody had ever heard of exceptions. Bjarne's 1986 "The C++ Programming Language" does not mention RAII or exceptions, but does say on pg. 158: "Calling constructors and destructors for static objects serves an extremely important function in C++. It is the way to ensure proper initialization and cleanup of data structures in libraries."
This is what happens when people take for granted what Wikipedia says. At least in this regard, there are still people alive that lived through the events. -- Paulo
Sep 26 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Sep 26, 2014 at 08:50:06PM +0200, Paulo Pinto via Digitalmars-d wrote:
 Am 26.09.2014 20:46, schrieb Walter Bright:
On 9/26/2014 4:02 AM, Paulo Pinto wrote:
On Friday, 26 September 2014 at 10:01:32 UTC, Ola Fosheim Grøstad wrote:
On Friday, 26 September 2014 at 09:41:09 UTC, Paulo  Pinto wrote:
This is completely not true, we were using RAII in C++ before any
compiler had real support for exceptions.
Well, I haven't read the 1990 edition of the annotated C++ reference by Stroustrup and Ellis since the mid 90s so my memory may be clouded, but that is how I remember it. And wikipedia says the same: «The technique was developed for exception-safe resource management in C++[3] during 1984–89» http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
I don't care what Wikipedia says, I was there in the early C++ days happily using Turbo and Borland C++ in MS-DOS.
I wrote a C++ compiler in 1987. Nobody had ever heard of exceptions. Bjarne's 1986 "The C++ Programming Language" does not mention RAII or exceptions, but does say on pg. 158: "Calling constructors and destructors for static objects serves an extremely important function in C++. It is the way to ensure proper initialization and cleanup of data structures in libraries."
This is what happens when people take for granted what Wikipedia says. At least in this regard, there are still people alive that lived through the events.
[...] Then wikipedia should be edited to be more accurate, while said people are still alive!! Otherwise the distorted version of the events will come to be regarded as fact. T -- Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln
Sep 26 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 11:52 AM, H. S. Teoh via Digitalmars-d wrote:
 Then wikipedia should be edited to be more accurate, while said people
 are still alive!! Otherwise the distorted version of the events will
 come to be regarded as fact.
I've been banned from editing Wikipedia for some reason. Someone else will have to do it :-(
Sep 26 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Sep 26, 2014 at 12:33:06PM -0700, Walter Bright via Digitalmars-d wrote:
 On 9/26/2014 11:52 AM, H. S. Teoh via Digitalmars-d wrote:
Then wikipedia should be edited to be more accurate, while said
people are still alive!! Otherwise the distorted version of the
events will come to be regarded as fact.
I've been banned from editing Wikipedia for some reason.
What, why?
 Someone else will have to do it :-(
I would, except that right now I'm working on a dmd PR. ;-) Do you have references to back up your claims (references deemed acceptable by WP)? Otherwise whatever I (or anyone else) put on there will just get reverted by the editors. Unfortunately, there are a few WP editors around who are overly draconian about deleting "unreferenced" material. (Got burned by them myself a few times -- drove me to put stuff on my own website instead, and then I discovered other people adding links to my website from WP and adding the stuff back on my behalf. Ahhh, sweet revenge. :-P) T -- Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.
Sep 26 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 12:47 PM, H. S. Teoh via Digitalmars-d wrote:
 I would, except that right now I'm working on a dmd PR. ;-)
No hurry.
 Do you have
 references to back up your claims (references deemed acceptable by WP)?
Yes, I quoted from Bjarne's 1986 book "The C++ Programming Language". Bjarne writes in "Possible Directions for C++" he writes "Because of destructors the C solution is insufficient and C++ will eventually be forced to develop an exception handling mechanism." -- Proceedings and Additional Papers C++ Workshop Santa Fe, NM, 1987 That's the first reference I can find to adding EH to C++. It does not propose any syntax. In 1988 and 1990 there are proposals for ways to add EH to C++.
Sep 26 2014
prev sibling parent reply "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Friday, 26 September 2014 at 18:54:14 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 Then wikipedia should be edited to be more accurate, while said 
 people
 are still alive!! Otherwise the distorted version of the events 
 will
 come to be regarded as fact.
Stroustrup was planning for exceptions up till ARM in 1990 and RAII become an idiom through his writings. C++ compilers had ARM exception support at least by 1992/1993: HP, IBM, DEC, maybe SGI. (ARM is the base document for the ISO standard and was regarded as the c++ bible.) Those are not facts?
Sep 26 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 26.09.2014 22:10, schrieb Ola Fosheim Grostad:
 On Friday, 26 September 2014 at 18:54:14 UTC, H. S. Teoh via
 Digitalmars-d wrote:
 Then wikipedia should be edited to be more accurate, while said people
 are still alive!! Otherwise the distorted version of the events will
 come to be regarded as fact.
Stroustrup was planning for exceptions up till ARM in 1990 and RAII become an idiom through his writings. C++ compilers had ARM exception support at least by 1992/1993: HP, IBM, DEC, maybe SGI. (ARM is the base document for the ISO standard and was regarded as the c++ bible.) Those are not facts?
Yes Stroustroup was planning for exceptions and maybe there were even some articles flying around in C++ Report and The C Users Journal. However, we were using MS-DOS systems networked via Novell Netware. I started coding C++ on MS-DOS in 1993 with Turbo C++ 1.0 all the way up to Turbo C++ 1.5 for Windows 3.x. Also used Borland C++ occasionally. I cannot remember any longer which version eventually added support for exceptions, but it was already a Windows 3.x version I would say. The early 90's in Portugal, meant no Internet and no BBS access outside Porto and Lisbon. We just learned on our own, by ourselves, reading books, magazines that sometimes lost their way into our small town or talking with our peers. RAII just seemed a natural way to use destructors. Specially since I was already using this pattern in Turbo Pascal 6.0. -- Paulo
Sep 26 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 20:48:20 UTC, Paulo Pinto wrote:
 I started coding C++ on MS-DOS in 1993 with Turbo C++ 1.0 all 
 the way up to Turbo C++ 1.5 for Windows 3.x. Also used Borland 
 C++ occasionally.

 I cannot remember any longer which version eventually added 
 support for exceptions, but it was already a Windows 3.x 
 version I would say.
Watcom had some exception support around 1993 according to comp.lang.c++, but it was probably not a big selling point to add it for other vendors on the MS platforms. I remember it was very difficult to find a good free C++ implementation though. Cfront was kind of annoying (and did not support exceptions either). In the free software movement C/Unix was the real deal and my impression was that C++ was not viewed as "cool", so it took a while for g++ to get the quality up to acceptable standards. My uni had DEC/SGI with C++, but at home where I preferred to do that type of programming I was stuck with C until g++ had improved by the mid 90s. And… of course… the uni did not teach C++ since it has a horrible design. I was only aware of one lecturer that had a C++ interest. I think they only had C++ available by accident (being part of a standard suite).
 The early 90's in Portugal, meant no Internet and no BBS access 
 outside Porto and Lisbon.
:-/ I did some BBSing in the late 80s, early 90s. It had a special feel to it, compared to the internet I think. More like a house/pub. I was lucky and got good Internet access at the university throughout the 90s (it was connected to ARPAnet/Internet already in 1973 so I think they gave it a high priority).
Sep 26 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Sep 26, 2014 at 09:32:54PM +0000, via Digitalmars-d wrote:
[...]
 I remember it was very difficult to find a good free C++
 implementation though. Cfront was kind of annoying (and did not
 support exceptions either).  In the free software movement C/Unix was
 the real deal and my impression was that C++ was not viewed as "cool",
 so it took a while for g++ to get the quality up to acceptable
 standards.
 
 My uni had DEC/SGI with C++, but at home where I preferred to do that
 type of programming I was stuck with C until g++ had improved by the
 mid 90s.  And… of course… the uni did not teach C++ since it has a
 horrible design. I was only aware of one lecturer that had a C++
 interest. I think they only had C++ available by accident (being part
 of a standard suite).
[...] Whoa, this brings back the memories! I remember taking a course in college where the prof was teaching us this idiom, which by today's standards is rather laughable (and probably no longer compiles -- this dates back to before the first C++ standardization in 1998): class MyClass { ... MyClass &Myclass(Myclass &); ... } // Gotta love the audacious violation of DRY here: MyClass &MyClass::MyClass(MyClass &mc) { ... return *this; } This was on g++ in the early to mid 90's, just around the time C++ templates first became widely available. I still remember trying both c++ (the compiler, not the language) and g++, and perhaps one or two other compilers installed on the lab compute servers, and finding that one compiler would support new feature X but not new feature Y, but the other compiler that supported feature Y had a buggy implementation of feature X. So it was quite frustrating that many of the cool new features couldn't be used together 'cos of buggy compiler implementations. Not to mention subtle differences in dialect that sometimes makes your projects uncompilable with another compiler. Fun times. T -- People tell me I'm stubborn, but I refuse to accept it!
Sep 26 2014
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 26.09.2014 23:32, schrieb "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>":
 On Friday, 26 September 2014 at 20:48:20 UTC, Paulo Pinto wrote:
 I started coding C++ on MS-DOS in 1993 with Turbo C++ 1.0 all the way
 up to Turbo C++ 1.5 for Windows 3.x. Also used Borland C++ occasionally.

 I cannot remember any longer which version eventually added support
 for exceptions, but it was already a Windows 3.x version I would say.
Watcom had some exception support around 1993 according to comp.lang.c++, but it was probably not a big selling point to add it for other vendors on the MS platforms.
Watcom only became big on MS-DOS when they started offering a 32bit MS-DOS extender (remember those?). That feature, coupled with good code generation, made many game studios go for it. But that is the only thing I know from it. In Portugal, Borland and Microsoft ruled the MS-DOS developer tools.
 I remember it was very difficult to find a good free C++ implementation
 though. Cfront was kind of annoying (and did not support exceptions
 either). In the free software movement C/Unix was the real deal and my
 impression was that C++ was not viewed as "cool", so it took a while for
 g++ to get the quality up to acceptable standards.
Back in those days I got to buy my tools. Only knew what FOSS was about around 1995. In 1993 I got hold of Turbo C 2.0 and Turbo C++ 1.0, after a couple of years of doing Turbo Pascal, already with OOP using Turbo Vision. C just looked stone age when compared with Turbo Pascal 6.0 features and I immediately switched to C++ after a few months of pure C. Since then I have been on C++ troop ranks on the usual C vs C++ debates. The sad thing is that nowadays many new C++ programmers behave against languages with automatic memory management, the same way we were seen by C programmers in those days. You quite right about us not being cool in UNIX world. Outside of CORBA, it was always an uphill battle to use C++. Specially in the FOSS front. I wrote one of the first tutorials on how to use yacc/bison and lex/flex with C++ instead of C, as I could not find any. -- Paulo
Sep 27 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 26 Sep 2014 11:52:21 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:

 Then wikipedia should be edited to be more accurate, while said people
 are still alive!! Otherwise the distorted version of the events will
 come to be regarded as fact.
it's very hard to introduce correct facts to wikipedia. the strange this is that it's very easy to introduce incorrect facts if they are looking "normal".
Sep 26 2014
prev sibling next sibling parent "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Friday, 26 September 2014 at 18:46:19 UTC, Walter Bright wrote:
 I wrote a C++ compiler in 1987. Nobody had ever heard of 
 exceptions. Bjarne's 1986 "The C++ Programming Language" does 
 not mention RAII or exceptions, but does say on pg. 158:
Exceptions is chapter 15 in the 1990 edition. I should have it somewhere, a small brown hardcover and expensive!
Sep 26 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 18:46:19 UTC, Walter Bright wrote:
 I wrote a C++ compiler in 1987. Nobody had ever heard of 
 exceptions.
Lisp had exceptions in the 60s. In the 80s exception handling was fashionable in language design. :)
 Bjarne's 1986 "The C++ Programming Language" does not mention 
 RAII or exceptions, but does say on pg. 158:

 "Calling constructors and destructors for static objects serves 
 an extremely important function in C++. It is the way to ensure 
 proper initialization and cleanup of data structures in 
 libraries."
I would not call this RAII, but Simula67 did have the block prefixing idiom which I presume Stroustrup knew about. http://www.olejohandahl.info/papers/Birth-of-S.pdf RAII is a natural extension of block prefixing IMO. BETA, the follow up language to Simula, was developed in the 70s/80s and support RAII-style prefixing through the "inner"-statement. You can probably find many RAII-like idioms in various languages if you dig back in time, though.
Sep 26 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 2:04 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Friday, 26 September 2014 at 18:46:19 UTC, Walter Bright wrote:
 I wrote a C++ compiler in 1987. Nobody had ever heard of exceptions.
Lisp had exceptions in the 60s. In the 80s exception handling was fashionable in language design. :)
I meant in the context of C++.
 Bjarne's 1986 "The C++ Programming Language" does not mention RAII or
 exceptions, but does say on pg. 158:

 "Calling constructors and destructors for static objects serves an extremely
 important function in C++. It is the way to ensure proper initialization and
 cleanup of data structures in libraries."
I would not call this RAII,
I would. The whole point of destructors is to automatically clean up resources when the object goes away, which was (later) dubbed RAII.
Sep 26 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 21:19:29 UTC, Walter Bright wrote:
 I would. The whole point of destructors is to automatically 
 clean up resources when the object goes away, which was (later) 
 dubbed RAII.
Yeah, but RAII takes it to the extreme where you create dummy classes that only consist of constructors/destructors so that the stack unwinding does all cleanup/closing/freeing without any try/catch. Before C++ templates that looked verbose and ugly syntactically, and it is still tedious if you only use the specific resource in one location. "scope(exit)" is often more transparent IMO.
Sep 27 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 27 September 2014 at 10:01:05 UTC, Ola Fosheim 
Grøstad wrote:
 On Friday, 26 September 2014 at 21:19:29 UTC, Walter Bright 
 wrote:
 I would. The whole point of destructors is to automatically 
 clean up resources when the object goes away, which was 
 (later) dubbed RAII.
Yeah, but RAII takes it to the extreme where you create dummy classes that only consist of constructors/destructors so that the stack unwinding does all cleanup/closing/freeing without any try/catch.
This is not necessary in D as we have scope statements.
 Before C++ templates that looked verbose and ugly 
 syntactically, and it is still tedious if you only use the 
 specific resource in one location.  "scope(exit)" is often more 
 transparent IMO.
I guess this is matter of style and various tradeoff. A very common operation to rollback probably deserve its own RAII struct. An uncommon one is better served with scope.
Sep 28 2014
prev sibling next sibling parent reply "po" <yes no.com> writes:
 Just a note: this isn't really true. RAII was initially used to 
 deal with exceptions. If you want fast backtracking and just 
 reset the stack pointer (rather than unwinding) then 
 stack-allocated RAII objects won't work since they will be 
 overwritten. You need to maintain a list of "destructors" in 
 thread local memory or close to the stack root so that you can 
 close files etc. Whether RAII is the best option really depends 
 on what kind of execution patterns and performance 
 characteristics you are aiming for.
Why would you reset the stack pointer? Keep in mind, nobody uses exceptions in games. No exceptions are going to be thrown in a game context.
Sep 26 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 26 September 2014 at 09:42:14 UTC, po wrote:
  Why would you reset the stack pointer? Keep in mind, nobody 
 uses exceptions in games. No exceptions are going to be thrown 
 in a game context.
To backtrack quickly out of deep recursion, but I am not saying this is a typical use case or what JB referred to (hence it was just a side note). I think both RAII, "finally", and more global manager-objects are reasonable solutions depending on the task.
Sep 26 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 2:24 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Friday, 26 September 2014 at 08:59:04 UTC, po wrote:
 - RAII makes most sense if you have exceptions.
RAII is orthogonal to exceptions, so his claim is nonsense.
Just a note: this isn't really true. RAII was initially used to deal with exceptions.
RAII existed in C++ years before exceptions.
Sep 26 2014
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26 September 2014 17:24, po via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 std::string tends to be more complicated because of the small string
 optimization.  Most debuggers I've used don't handle that correctly out of
 the box, even if sorting it out really isn't difficult.
Almost all game developers use Visual Studio, and VS has supported visualization of all STL containers(including string) since VS2005.
 This is really missing the point. He knows RAII is useful and he knows
 RAII solves freeing free'd memory. Maybe it's time to re-watch the video.
I watched it. None of what he said made much sense. His claims: 1. RAII is bad because exceptions. -Nothing forces to use exceptions, so irrelevant 2. RAII is bad because you must write copy constructor,destructor etc each time. -No you write a few basic template classes and reuse them.
 Regarding exceptions, they can be used incorrectly, but I think they tend
 to provide better error handling than return codes *because no one ever
 checks return codes*.  And when you do pathologically handle error codes,
 the amount of code duplication can be tremendous, and the chance for errors
 involving improper cleanup can be quite high.  Though again, RAII can be of
 incredible use here.
That is all true, I agree that exceptions are better than error codes. But for games, the general design is that errors are impossible. The game should never fail so exceptions serve little purpose. -ran out of memory? Shut game down, this should not happen -couldn't open a file? Shut game down, this should never happen -out of bounds array access, invalid iterator etc: abort game, found during development, fixed, should never happen. -networking? This is one place where you do need to handle errors, but do you need exceptions just to handle this one case? Probably not
This. I've never used an exception before. I can't imagine a reason I would ever want to. Networking problems won't be solved with an exception, that requires very comprehensive logic.
Sep 26 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 8:21 AM, Manu via Digitalmars-d wrote:
 I've never used an exception before. I can't imagine a reason I would
 ever want to.
Nothrow is your friend, then! BTW, you need exceptions if there appears in your code things like: if (errorHappened) goto LcleanupCode;
Sep 26 2014
next sibling parent =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
Walter Bright <newshound2 digitalmars.com> wrote:
 On 9/26/2014 8:21 AM, Manu via Digitalmars-d wrote:
 I've never used an exception before. I can't imagine a reason I would
 ever want to.
Nothrow is your friend, then! BTW, you need exceptions if there appears in your code things like: if (errorHappened) goto LcleanupCode;
No you need destructors/RAII/finally. And all those work equally with without exceptions (early return). Tobi
Sep 26 2014
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 27 September 2014 04:20, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 9/26/2014 8:21 AM, Manu via Digitalmars-d wrote:
 I've never used an exception before. I can't imagine a reason I would
 ever want to.
Nothrow is your friend, then!
It certainly is. The only thing that ever ruins my nothrow-ness are phobos calls ;)
 BTW, you need exceptions if there appears in your code things like:

     if (errorHappened) goto LcleanupCode;
Initialisation logic often looks like this, and I buy the value of exceptions in this case. However, I've never successfully implemented it yet though, because the calls that create code like that always seem to be extern-C calls in my experience... :/ I'm not sure why my D code doesn't manifest those patterns, D just seems to produce different code than C/C++...
Sep 26 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-09-27 02:47, Manu via Digitalmars-d wrote:

 Initialisation logic often looks like this, and I buy the value of
 exceptions in this case. However, I've never successfully implemented
 it yet though, because the calls that create code like that always
 seem to be extern-C calls in my experience... :/
Perhaps you should wrap those call an throw an exception. -- /Jacob Carlborg
Sep 27 2014
parent "Sean Kelly" <sean invisibleduck.org> writes:
On Saturday, 27 September 2014 at 09:32:19 UTC, Jacob Carlborg 
wrote:
 On 2014-09-27 02:47, Manu via Digitalmars-d wrote:

 Initialisation logic often looks like this, and I buy the 
 value of
 exceptions in this case. However, I've never successfully 
 implemented it yet though, because the calls that create code 
 like that always seem to be extern-C calls in my experience... 
 :/
Perhaps you should wrap those call an throw an exception.
I often do something like this: proc(someFunc(a, b, c)); proc(anotherFunc(d, e, f)); Where proc() processes the return value and conditionally throws on error. You really need one such function per API, but that's not a big deal. You can kind of get away with macros if you're using C, but all they can really do is jump to an expected Lerror label.
Sep 27 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-09-26 09:24, po wrote:

 -couldn't open a file? Shut game down, this should never happen
It depends on what file it's trying to open and what the failure is. If it can't find the settings file, just recreate it and move on. Perhaps report the error to the user. -- /Jacob Carlborg
Sep 26 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
He also proposes of removing most or all implicit type 
conversions in his language, like bool->int.

D allows code like:

bool foo() { return true; }
void bar(int x) {}
void main() {
     bar(foo());
}


In past, removing implicit conversions from D forced you to write:

bar(cast(int)foo());

That is not much safer than having implicit conversions because 
cast() is a sharp powerful tool. In D programs the usage of 
cast() should be minimized as much as possible.

But if we keep disallowing implicit conversions, but we introduce 
a second kind of static cast that only work if the conversion is 
lossless, then we have code like (currently this is allowed in D 
because the int() syntax rides on the implicit conversions. So 
the semantic is a little different):

bar(int(foo()));

You also need suffixes to express most types with literals (like 
10u8 for an ubyte, or 'c'd for a dchar), to code in a more handy 
way.

Perhaps this new situation (no implicit conversions, plus two 
kinds of casts, and few extra literals) is safer than the current 
D situation (and I think no C code gains a new working meaning in 
this new situation).

Bye,
bearophile
Sep 20 2014
parent reply "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Saturday, 20 September 2014 at 08:38:49 UTC, bearophile wrote:
 Perhaps this new situation (no implicit conversions, plus two 
 kinds of casts, and few extra literals) is safer than the 
 current D situation (and I think no C code gains a new working 
 meaning in this new situation).
He want go-semantics. It also means that literals are untyped until bound, so you can do high precision calculations at compile time. I would also like to see these explicit conversions (and find hacks like "alias this" somewhat annoying). I also think arithmetics on ubytes should be done as ubytes etc to allow SIMD vectorization. Go semantics is described well here: http://blog.golang.org/constants
Sep 20 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Saturday, 20 September 2014 at 08:46:34 UTC, Ola Fosheim 
Grostad wrote:
 I also think arithmetics on ubytes should be done as ubytes etc 
 to allow SIMD vectorization.
Array operations do use SIMD. The code for this is in druntime. https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d
Sep 20 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Brian Schott:

 Array operations do use SIMD.
Array ops aren't used often in most normal D code. Most usages of SIMD should come from auto-vectorization and core.simd (but perhaps core.simd design was not discussed and improved enough, and the implicit upcasting semantics of C could hurt auto-vectorization). Bye, bearophile
Sep 20 2014
parent "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Saturday, 20 September 2014 at 09:09:56 UTC, bearophile wrote:
 Brian Schott:

 Array operations do use SIMD.
Array ops aren't used often in most normal D code. Most usages of SIMD should come from auto-vectorization and core.simd (but perhaps core.simd design was not discussed and improved enough, and the implicit upcasting semantics of C could hurt auto-vectorization).
Yes, I was thinking of auto vectorization/masking. Handcrafted simd is nice too, but I feel it is better done in a way the backend can understand. You might also want the compiler to generate fallback paths for older cpus...
Sep 20 2014
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 9/19/14, 9:52 PM, bearophile wrote:
 but currently Rust
 seems to ignore several kinds of correctness, focusing only on two
 kinds
Could you tell which are those two kinds and which other correctness are ignored? Just to learn more about Rust. Thanks!
Sep 20 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ary Borenszweig:

 Could you tell which are those two kinds and which other 
 correctness are ignored? Just to learn more about Rust. Thanks!
Rust does everything to be memory safe, and avoid data races outside its unsafe code zones. But in the real world there are many other sources of bugs that can wreak a program. Ada (and in a less intense way D) try to help the programmer write correct code for some of them too (and other languages are ATS, Whiley, F*, Idris, etc, cover other forms of correctness). Bye, bearophile
Sep 21 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 21.09.2014 11:30, schrieb bearophile:
 Ary Borenszweig:

 Could you tell which are those two kinds and which other correctness
 are ignored? Just to learn more about Rust. Thanks!
Rust does everything to be memory safe, and avoid data races outside its unsafe code zones. But in the real world there are many other sources of bugs that can wreak a program. Ada (and in a less intense way D) try to help the programmer write correct code for some of them too (and other languages are ATS, Whiley, F*, Idris, etc, cover other forms of correctness). Bye, bearophile
You can handle units of measure via tuples structs, since you mention F#. Not as clean, but workable. -- Paulo
Sep 21 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:

 (and other
 languages are ATS, Whiley, F*, Idris, etc, cover other forms of
 correctness).
...
You can handle units of measure via tuples structs, since you mention F#.
Here I mentioned F*, not F#: http://research.microsoft.com/en-us/projects/fstar/ Bye, bearophile
Sep 21 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 21.09.2014 12:47, schrieb bearophile:
 Paulo Pinto:

 (and other
 languages are ATS, Whiley, F*, Idris, etc, cover other forms of
 correctness).
 ...
You can handle units of measure via tuples structs, since you mention F#.
Here I mentioned F*, not F#: http://research.microsoft.com/en-us/projects/fstar/ Bye, bearophile
Sorry, should have taken more coffee.
Sep 21 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2014 4:01 AM, Paulo Pinto wrote:
 Sorry, should have taken more coffee.
My excuse is I haven't had my beer yet.
Sep 24 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/19/2014 5:52 PM, bearophile wrote:
 The "!" means the memory of this array is owned by the Mesh stuct. So when the
 Mesh instantiation goes out of scope, all the memory it owns gets deallocated.
This stood out for me. Deallocated how? People who write high perf software tend to have multiple allocators for different purposes. I don't think this feature will work.
Sep 24 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 25/09/14 06:18, Walter Bright wrote:

 This stood out for me. Deallocated how? People who write high perf
 software tend to have multiple allocators for different purposes.

 I don't think this feature will work.
He says it's part of the same memory as the enclosing struct. I guess they would need to use the same allocator. -- /Jacob Carlborg
Sep 24 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 This stood out for me. Deallocated how?
Calling free when the struct instance goes out of scope, I presume.
 People who write high perf software tend to have multiple
 allocators for different purposes.
I think that data is used all together, so it's reasonable to allocate it from a single allocator.
 I don't think this feature will work.
I think he's already using this strategy in production code. So I think it works. He's just asking for a language feature that implements this idiom for him in a shorter and cleaner way. Bye, bearophile
Sep 25 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 1:47 AM, bearophile wrote:
 This stood out for me. Deallocated how?
Calling free when the struct instance goes out of scope, I presume.
 People who write high perf software tend to have multiple
 allocators for different purposes.
I think that data is used all together, so it's reasonable to allocate it from a single allocator.
 I don't think this feature will work.
I think he's already using this strategy in production code. So I think it works. He's just asking for a language feature that implements this idiom for him in a shorter and cleaner way.
So how do you tell it to call myfree(p) instead of free(p) ?
Sep 25 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 So how do you tell it to call myfree(p) instead of free(p) ?
I think you can't in the form he has shown. He's far from being a good language designer, after all :-) Bye, bearophile
Sep 25 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 2:32 AM, bearophile wrote:
 Walter Bright:

 So how do you tell it to call myfree(p) instead of free(p) ?
I think you can't in the form he has shown. He's far from being a good language designer, after all :-)
It's not as easy as it looks :-)
Sep 25 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright 
wrote:
 So how do you tell it to call myfree(p) instead of free(p) ?
Maybe stock malloc/free is enough for him?
Sep 25 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/25/14, 4:33 AM, Kagamin wrote:
 On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright wrote:
 So how do you tell it to call myfree(p) instead of free(p) ?
Maybe stock malloc/free is enough for him?
That kind of commitment shouldn't be baked into the language. That's why RAII and scope are better than his notation. -- Andrei
Sep 25 2014
next sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 25 September 2014 at 13:57:17 UTC, Andrei 
Alexandrescu wrote:
 On 9/25/14, 4:33 AM, Kagamin wrote:
 On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright 
 wrote:
 So how do you tell it to call myfree(p) instead of free(p) ?
Maybe stock malloc/free is enough for him?
That kind of commitment shouldn't be baked into the language. That's why RAII and scope are better than his notation.
Allocation is orthogonal to RAII and scope. Allocation creates resource, RAII tracks it.
Sep 25 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/25/14, 8:12 AM, Kagamin wrote:
 On Thursday, 25 September 2014 at 13:57:17 UTC, Andrei Alexandrescu wrote:
 On 9/25/14, 4:33 AM, Kagamin wrote:
 On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright wrote:
 So how do you tell it to call myfree(p) instead of free(p) ?
Maybe stock malloc/free is enough for him?
That kind of commitment shouldn't be baked into the language. That's why RAII and scope are better than his notation.
Allocation is orthogonal to RAII and scope. Allocation creates resource, RAII tracks it.
Affirmative. -- Andrei
Sep 25 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 25 September 2014 at 15:34:31 UTC, Andrei
Alexandrescu wrote:
 On 9/25/14, 8:12 AM, Kagamin wrote:
 On Thursday, 25 September 2014 at 13:57:17 UTC, Andrei 
 Alexandrescu wrote:
 On 9/25/14, 4:33 AM, Kagamin wrote:
 On Thursday, 25 September 2014 at 09:16:27 UTC, Walter 
 Bright wrote:
 So how do you tell it to call myfree(p) instead of free(p) ?
Maybe stock malloc/free is enough for him?
That kind of commitment shouldn't be baked into the language. That's why RAII and scope are better than his notation.
Allocation is orthogonal to RAII and scope. Allocation creates resource, RAII tracks it.
Affirmative. -- Andrei
And in many cases scope statements are simpler, better, harder, stronger !
Sep 25 2014
prev sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 25 September 2014 at 13:57:17 UTC, Andrei 
Alexandrescu wrote:
 On 9/25/14, 4:33 AM, Kagamin wrote:
 On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright 
 wrote:
 So how do you tell it to call myfree(p) instead of free(p) ?
Maybe stock malloc/free is enough for him?
That kind of commitment shouldn't be baked into the language. That's why RAII and scope are better than his notation. -- Andrei
Only if you accept "The Right Way" philosophy. A "Worse is Better" person may disagree. There is no "better", it's all tradeoffs.
Sep 25 2014
parent "Kagamin" <spam here.lot> writes:
On Thursday, 25 September 2014 at 18:38:36 UTC, Peter Alexander 
wrote:
 Only if you accept "The Right Way" philosophy. A "Worse is 
 Better" person may disagree. There is no "better", it's all 
 tradeoffs.
D already has a single allocation strategy built into the language: the `new` operator.
Sep 26 2014
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 19 September 2014 at 23:47:06 UTC, Max Klyga wrote:
 Jonathan Blow just recorded a talk about the needs and ideas 
 for a programming language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were 
 possible for frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design from 
 game developer perspective.
I haven't finished the talk yet, but already this is kind of upsetting. The claim that he want to create a programming language, but is unable to give concrete examples of any case he makes so far, grossly misrepresent what exists in other languages or flat out declare that he doesn't know. If you are going down the road of creating a new programming language, you'd better be sure to know what exists fairly well and what shortcomings you are trying to overcome. That would be true of anything, really, not simply programming language. The fact that, without deep knowledge of what is done in languages outside C++, he can assert of the difficulty of writing a compiler the classroom example of Dunning Kruger. It literally like me saying telling to general motor engineer hey, building a really good car is easy, You screw 4 wheels to a metal cage and done! I'd concede that he is probably right on the fact that writing a front end is certainly easier that a game engine (ie I mean high end game engine with realistic physic, high quality rendering and all the goodies). But it is pretty clear from his talk so far that he grossly underestimate the difficulty to: 1/ Get language design right. It is a mix of technical constraint for the coder, the compiler, and plateform/runtime constraints, the whole thing being made extra hard as success depends on various social dynamics amongst developers. 2/ Getting compiler right. Parsing and dumping C like code into LLVM is one thing. Getting the whole thing to support various advanced features, meaningful errors messages, making it fast, making it resilient enough to wrong code so it can be useful for tooling, generating good quality IR, getting a good quality runtime that work on various platforms and implementing languages specific optimization is much harder.
Sep 19 2014
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
OK so I'm 1h in now. The guy is explaining slices in a languages 
that look like C or C++. But discarded D at the beginning because 
it is too close to C/C++.

Also I love how he keeps mentioning that adding debug support is 
easy.

His ! stuff looks interesting, but I guess this is already being 
discussed in D with uniqueness.

I also love the passage where he mention that you have strings 
everywhere, and you duplicate them and so on, and that you can a 
system to unique them and manage memory, but that would be crazy 
complicated. The obvious question that come to mind: what does he 
think a compiler does ?

OK now using pointer and value type via dot.

1h20 he is on nullable vs non nullable. According to him this is 
not an issue, but stats say otherwise. Still want to look into 
it. Not sure what is his point on that one.

He then goes on concurrency and make some very good points here 
but he doesn't look like he has anything to propose :(

1h25 annotate, serialize, introspect.

1h25 good point about build. All build system I've used so far 
sucks. But no solution.

At the end, I kind of agree on the problems, but the solution he 
mention already exists, and when they do not (or I think they do 
not) he don't have anything to propose.

1h30 now he is talking about CTFE and code generation...

What I take out of this, is that something like unique/isolated 
or whatever is key, and the memory mapping optimization is nice 
but probably realizable in D using code generation. But creating 
a new language instead of participating in existing ones seem 
very misguided and he does seems to realize how hard it is to 
create a language.
Sep 19 2014
prev sibling parent "Piotrek" <none nowhere.pl> writes:
On Saturday, 20 September 2014 at 04:28:58 UTC, deadalnix wrote:
 On Friday, 19 September 2014 at 23:47:06 UTC, Max Klyga wrote:
 Jonathan Blow just recorded a talk about the needs and ideas 
 for a programming language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were 
 possible for frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design 
 from game developer perspective.
I haven't finished the talk yet, but already this is kind of upsetting. The claim that he want to create a programming language, but is unable to give concrete examples of any case he makes so far, grossly misrepresent what exists in other languages or flat out declare that he doesn't know.
I got similar feeling. If he joined D, there would be more value than starting all from the ground. I think D fits well his requirements. He admits it between the lines when defines D as better C++, but not worth switching because of not enough gain. IMHO, D has the best cumulative score across all languages in main 3 categories (despite tooling): 1. Kernel type (mostly no memory allocations) - the winner here 2. Game type (mostly manual memory management) - the winner here 3. Applications/Scripts (mostly automatic memory management))- the winner in large scale apps. In terms of small ones, for most people D places somewhere in 2nd place group because of static typing (but honestly I prefer writing scripts in statically typed languages) After years of codding I think the following topics (pointed in video) will never be solved entirely in any language 1. Resource handling 2. Error handing As for the biggest D rival - Rust, despite all syntax choices I don't accept, here is at least one thing that prevents Rust to be ready for ver 1.0 in the end of year: http://doc.rust-lang.org/guide-pointers.html#gc Gc<T> "In the future, Rust may have a real garbage collected type, and so it has not yet been removed for that reason." In my opinion, as a usual coder, memory model in Rust is not well defined for now. Piotrek
Sep 21 2014
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 20.09.2014 01:47, schrieb Max Klyga:
 Jonathan Blow just recorded a talk about the needs and ideas for a
 programming language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were possible
 for frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design from game
 developer perspective.
Many of his wishes have been answered in Algol68(1973), Modula-2(1978), Cedar(1983), Ada(1983), Turbo Pascal 6.0 (1990), but the industry at large decided to go elsewhere instead. Which in the end boils down to this: "Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions. " -- Dennis Ritche on history of C. Already in 1979 it was clear that C without syntax analysis tooling wasn't a good idea. This of course, also had an impact in C++ and Objective-C. -- Paulo
Sep 20 2014
parent "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Saturday, 20 September 2014 at 11:11:23 UTC, Paulo Pinto wrote:
 Many of his wishes have been answered in Algol68(1973), 
 Modula-2(1978), Cedar(1983), Ada(1983), Turbo Pascal 6.0 
 (1990), but the industry at large decided to go elsewhere 
 instead.
I didn't get that impression. Seems like he wants to cover existing practices in a more time saving package, then add some neat stuff: - automatic region allocator per object - ctfe including executing external programs - uda + static reflection - debugging tools for freeing shared memory (without rc/tracing) - go style literals + type system? - swift style nullable Seems he wants a streamlined nogc/nothrow version of D with a dedicated syntax for his field. D could probably be modified to fit pretty well.
Sep 20 2014
prev sibling next sibling parent "JN" <666total wp.pl> writes:
On Friday, 19 September 2014 at 23:47:06 UTC, Max Klyga wrote:
 Jonathan Blow just recorded a talk about the needs and ideas 
 for a programming language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were 
 possible for frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design from 
 game developer perspective.
Interesting to see him not worship RAII and even bash it a bit. Most game developers sticking with C++ and evaluating other languages swear by RAII and reject every GC-language for the lack of it.
Sep 21 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/19/2014 4:47 PM, Max Klyga wrote:
 Jonathan Blow just recorded a talk about the needs and ideas for a programming
 language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were possible for
 frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design from game developer
 perspective.
Looks like he reinvented D dynamic arrays at 1:02. Sigh.
Sep 25 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 2:27 AM, Walter Bright wrote:
 Looks like he reinvented D dynamic arrays at 1:02. Sigh.
At 1:16 he gives credit to Go for the -> and . becomes . thing. Says its great. And he wants: * D array declaration syntax. * consistently sized integer types * user defined attributes. * multiple files compiled at once. * permissive license. * nested comments * no preprocessor * insert files into the source code (mixins) * compile time function execution And ... ... he's specified D!
Sep 25 2014
next sibling parent reply "currysoup" <sam92cutler hotmail.co.uk> writes:
Would just like to remind you all that he's trying to foster 
conversation rather than declare "this is the most perfect 
language ever". A lot of his ideas don't hold water in their 
current form but I'm sure D wasn't designed in a 2 hour live 
stream :). I'm personally really excited at the prospect of some 
momentum in a language designed specifically for games engineers.

D is really great and solves a lot of the issues raised in the 
video. A lot of D's features (GC in particular) become ugliness 
you've got to avoid. In addition all the  nogc, nothrow, pure, 
etc. becomes crufty.

I quite like the idea of "simple by default" and you enable 
features with annotations ( usegc,  throws,  pure).
Sep 25 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 25 Sep 2014 10:46:59 +0000
currysoup via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I quite like the idea of "simple by default" and you enable=20
 features with annotations ( usegc,  throws,  pure).
" usegc" will be major PITA. for example any function that does string concatenation or format() will need this annotation. i see GC as intergal and widely-used part of language, so " nogc" is ok. what we need though is " gc" to allow things like this: nogc: void foo () { ... some no-gc code ... } void bar () gc { ... some gc code ... } to be able to mark the whole part of the code as nogc but still allow to write one or two gc functions by the way. ah, and the same for 'final'. sure one can just move necessary definitions to top of the file (i.e. they will appear before " nogc:"), but this will hurt code readability.
Sep 25 2014
parent reply "currysoup" <sam92cutler hotmail.co.uk> writes:
On Thursday, 25 September 2014 at 11:30:16 UTC, ketmar via 
Digitalmars-d wrote:
 On Thu, 25 Sep 2014 10:46:59 +0000
 currysoup via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I quite like the idea of "simple by default" and you enable 
 features with annotations ( usegc,  throws,  pure).
" usegc" will be major PITA. for example any function that does string concatenation or format() will need this annotation. i see GC as intergal and widely-used part of language, so " nogc" is ok. what we need though is " gc" to allow things like this: nogc: void foo () { ... some no-gc code ... } void bar () gc { ... some gc code ... } to be able to mark the whole part of the code as nogc but still allow to write one or two gc functions by the way. ah, and the same for 'final'. sure one can just move necessary definitions to top of the file (i.e. they will appear before " nogc:"), but this will hurt code readability.
I wasn't talking about D, just in general.
Sep 25 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 25 Sep 2014 12:16:16 +0000
currysoup via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I wasn't talking about D, just in general.
sorry, it's my frustration speaks. ;-)
Sep 25 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 25 September 2014 at 10:47:00 UTC, currysoup wrote:
 D is really great and solves a lot of the issues raised in the 
 video. A lot of D's features (GC in particular) become ugliness 
 you've got to avoid. In addition all the  nogc, nothrow, pure, 
 etc. becomes crufty.
I'd say nothrow and pure are of marginal utility. nogc can be just nogc: at the top of a module. And the last piece is libraries.
Sep 25 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 3:46 AM, currysoup wrote:
 I quite like the idea of "simple by default" and you enable features with
 annotations ( usegc,  throws,  pure).
I think simple by default doesn't have those annotations - by default meaning "the code works". Those annotations all work to restrict what the code can do.
Sep 25 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 3:46 AM, currysoup wrote:
 Would just like to remind you all that he's trying to foster conversation
rather
 than declare "this is the most perfect language ever". A lot of his ideas don't
 hold water in their current form but I'm sure D wasn't designed in a 2 hour
live
 stream :). I'm personally really excited at the prospect of some momentum in a
 language designed specifically for games engineers.
It is great to have a conversation. It's good to revisit assumptions about what a good language should be. Although I don't agree with him, I thought that it was great that he questioned the value of RAII. But I think it's a waste of time to develop a new language that has 98% overlap with existing ones, like if I proposed a language just like C but with member functions.
Sep 25 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 25/09/14 21:59, Walter Bright wrote:

 But I think it's a waste of time to develop a new language that has 98%
 overlap with existing ones, like if I proposed a language just like C
 but with member functions.
It seems that people won't switch language, or rather create a new language, even though an existing would fit them, just because the existing one lacks one feature. It's like "Yeah, D is great it has 9 of the features I need, but it lacks the 10th. Therefore I can't switch, even though the language I use now doesn't have any of these 10 features." -- /Jacob Carlborg
Sep 25 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2014 11:34 PM, Jacob Carlborg wrote:
 On 25/09/14 21:59, Walter Bright wrote:

 But I think it's a waste of time to develop a new language that has 98%
 overlap with existing ones, like if I proposed a language just like C
 but with member functions.
It seems that people won't switch language, or rather create a new language, even though an existing would fit them, just because the existing one lacks one feature. It's like "Yeah, D is great it has 9 of the features I need, but it lacks the 10th. Therefore I can't switch, even though the language I use now doesn't have any of these 10 features."
People get comfortable with the language they use, and switching languages takes work. But they don't want to say that, so they look for something to use as an excuse. It's perfectly human, and I'm guilty of it too :-)
Sep 26 2014
prev sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 25 September 2014 at 09:58:31 UTC, Walter Bright 
wrote:
 On 9/25/2014 2:27 AM, Walter Bright wrote:
 Looks like he reinvented D dynamic arrays at 1:02. Sigh.
At 1:16 he gives credit to Go for the -> and . becomes . thing. Says its great. And he wants: <snip> And ... ... he's specified D!
Almost, but he also wants a language with the "Worse is Better" philosophy. D does not have this, and I don't think we want it.
Sep 25 2014
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 25 September 2014 at 09:27:16 UTC, Walter Bright
wrote:
 On 9/19/2014 4:47 PM, Max Klyga wrote:
 Jonathan Blow just recorded a talk about the needs and ideas 
 for a programming
 language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were 
 possible for
 frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design 
 from game developer
 perspective.
Looks like he reinvented D dynamic arrays at 1:02. Sigh.
Yes the only thing that seems to be an issue between him and D is the lack of ownership (his ! concept).
Sep 25 2014
prev sibling next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Friday, 19 September 2014 at 23:47:06 UTC, Max Klyga wrote:
 Jonathan Blow just recorded a talk about the needs and ideas 
 for a programming language for game developer.

 https://www.youtube.com/watch?v=TH9VCN6UkyQ

 This talk mentions D quite a lot of times.
 D is mentioned as the most probable to be adopted if it were 
 possible for frictionless interaction with existing codebase.
 An interesting talk if you want to look at language design from 
 game developer perspective.
The sequel: A Programming Language for Games, talk #2 https://www.youtube.com/watch?v=5Nc68IdNKdg
Sep 27 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/27/2014 9:35 AM, ponce wrote:
 The sequel:

 A Programming Language for Games, talk #2
 https://www.youtube.com/watch?v=5Nc68IdNKdg
Yeah, I watched it. He advocates: * pure functions * local functions * local functions with the same syntax as global functions * safety which defaults to off All of which D does right now. The only interesting thing is he describes a way that functions (and blocks) can specify what global data they access, and then have the compiler issue errors for accessing any other global data. He has a way to do that both locally and transitively. However, the same effect can be achieved via pure annotations and passing the globals needed by reference as function parameters. Based on his talks about what he wants in a language, I infer he's not looked at D beyond "D has a GC, can't use it". -------------------------------------- Another thing I found interesting is I had assumed he'd given these talks at a conference. Not so. He simply set up a webcam in his office. It's a great method - we should look into doing that.
Sep 27 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Sep 27, 2014 at 02:51:14PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
 The only interesting thing is he describes a way that functions (and
 blocks) can specify what global data they access, and then have the
 compiler issue errors for accessing any other global data. He has a
 way to do that both locally and transitively.
That sounds like PHP. *shudder*
 However, the same effect can be achieved via pure annotations and
 passing the globals needed by reference as function parameters.
[...] I'm a fan of grouping related globals into structs with module level instances, and passed by reference to functions that need those specific globals. Truly-global globals are nasty, as are open sets of globals where you either don't access a global, or you (potentially) access *all* globals with no finer access granularity. (I had to debug C code that did that once... boy it was mind-bending when every function call could potentially arbitrarily change the global state.) T -- Computers are like a jungle: they have monitor lizards, rams, mice, c-moss, binary trees... and bugs.
Sep 27 2014
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 27 September 2014 at 22:06:00 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 On Sat, Sep 27, 2014 at 02:51:14PM -0700, Walter Bright via 
 Digitalmars-d wrote:
 [...]
 The only interesting thing is he describes a way that 
 functions (and
 blocks) can specify what global data they access, and then 
 have the
 compiler issue errors for accessing any other global data. He 
 has a
 way to do that both locally and transitively.
That sounds like PHP. *shudder*
 However, the same effect can be achieved via pure annotations 
 and
 passing the globals needed by reference as function parameters.
[...] I'm a fan of grouping related globals into structs with module level instances, and passed by reference to functions that need those specific globals. Truly-global globals are nasty, as are open sets of globals where you either don't access a global, or you (potentially) access *all* globals with no finer access granularity. (I had to debug C code that did that once... boy it was mind-bending when every function call could potentially arbitrarily change the global state.) T
A fair amount of HPC code is still written in Fortran with a variables.f90 file that holds most program state as globals. Ick.
Sep 28 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 * local functions with the same syntax as global functions

 * safety which defaults to off

 All of which D does right now.
It could be nice to have a syntax like lambdas for small struct/class methods: https://issues.dlang.org/show_bug.cgi?id=7176 struct Foo { int bar(int x) pure { return x * x; } } Becomes something like:: struct Foo { int bar = (int x) pure => x * x; } Ada2012 and C#6 have something like that (with a different syntax).
 The only interesting thing is he describes a way that functions 
 (and blocks) can specify what global data they access, and then 
 have the compiler issue errors for accessing any other global 
 data. He has a way to do that both locally and transitively.
Unwanted access of global variables is a common source of troubles in my code. Time ago I suggested an optional outer() function annotation: https://d.puremagic.com/issues/show_bug.cgi?id=5007 Bye, bearophile
Sep 27 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/27/2014 3:30 PM, bearophile wrote:
 Walter Bright:

 * local functions with the same syntax as global functions

 * safety which defaults to off

 All of which D does right now.
It could be nice to have a syntax like lambdas for small struct/class methods: https://issues.dlang.org/show_bug.cgi?id=7176 struct Foo { int bar(int x) pure { return x * x; } } Becomes something like:: struct Foo { int bar = (int x) pure => x * x; }
I see no gain from that syntax.
 Unwanted access of global variables is a common source of troubles in my code.
 Time ago I suggested an optional  outer() function annotation:
 https://d.puremagic.com/issues/show_bug.cgi?id=5007
I suggest using 'pure' and passing the globals you actually need as ref parameters.
Sep 27 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 It could be nice to have a syntax like lambdas for small 
 struct/class methods:
 https://issues.dlang.org/show_bug.cgi?id=7176

 struct Foo {
     int bar(int x) pure { return x * x; }
 }

 Becomes something like::

 struct Foo {
     int bar = (int x) pure => x * x;
 }
I see no gain from that syntax.
Issue 7176 has currently seven votes, so someone seems to like it. Now some D code is written in a functional style, this means many function bodies are very small, and sometimes they contain just a UFCS chain. Usually editors (and Phobos style guides) format that bar function like: int bar(int x) pure { return x * x; } So now you have 4 lines instead of 1 line of the lambda-like syntax. Generally the presence of a "return" is regarded as a "code smell" in functional-style code.
 I suggest using 'pure' and passing the globals you actually 
 need as ref parameters.
This is what I usually do in D, but it has some small disadvantages: - It increases the number of function arguments (they are 8 bytes each), increasing the size of the function, adding some stack management instructions. This slows the function a little, if the function is performance-critical. - Sometimes you can't use "pure", for various reasons, like Phobos functions not yet pure, I/O action in your function, or other causes. - If your pure function foo receives two global argument as out and ref, the function bar that calls it needs to access to global variables or it too needs those two ref/out arguments. The current design of outer() is not transitive, so only foo needs to state what global variables are in/out/inout. - outer is more DRY, because you don't need to specify the type of the global variable received by ref, you just need to know its name. - With outer you can tighten some old code, without changing the signature of a function. If you have an old D module (or a C function converted to C) you often can't (or you don't want) to change the function signature to add the global arguments passed by ref. With outer() the function signature doesn't change, so you can improve your legacy code. It allows a simpler refactoring of code. More notes: - SPARK language has added a feature similar to outer, but more verbose. See comment 5 in issue 5007. - outer() is optional and it's fiddly because not it's not meant for small D script-like programs, it's meant as a help for medium-integrity D programs (where you may think about using Ada language instead). Bye, bearophile
Sep 27 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/27/2014 4:20 PM, bearophile wrote:
 Walter Bright:

 It could be nice to have a syntax like lambdas for small struct/class methods:
 https://issues.dlang.org/show_bug.cgi?id=7176

 struct Foo {
     int bar(int x) pure { return x * x; }
 }

 Becomes something like::

 struct Foo {
     int bar = (int x) pure => x * x;
 }
I see no gain from that syntax.
Issue 7176 has currently seven votes, so someone seems to like it.
A feature without a solid rationale is no good in spite of how many votes it has.
 Now some D code is written in a functional style, this means many function
 bodies are very small, and sometimes they contain just a UFCS chain.
 Usually editors (and Phobos style guides) format that bar function like:

 int bar(int x) pure
 {
      return x * x;
 }

 So now you have 4 lines instead of 1 line of the lambda-like syntax. Generally
 the presence of a  "return" is regarded as a "code smell" in functional-style
code.
D has a nice inline lamda syntax, which was needed. It is not needed for separate functions.
 I suggest using 'pure' and passing the globals you actually need as ref
 parameters.
This is what I usually do in D, but it has some small disadvantages: - It increases the number of function arguments (they are 8 bytes each), increasing the size of the function, adding some stack management instructions. This slows the function a little, if the function is performance-critical.
If the function is small enough that parameter setup time is significant, it is likely to be inlined anyway which will erase the penalty. Such arguments can also be passed as template alias parameters, which are zero cost.
 - Sometimes you can't use "pure", for various reasons, like Phobos functions
not
 yet pure, I/O action in your function, or other causes.
Then you really aren't encapsulating the globals the function uses, anyway, and the feature is useless.
 - If your pure function foo receives two global argument as out and ref, the
 function bar that calls it needs to access to global variables or it too needs
 those two ref/out arguments. The current design of  outer() is not transitive,
 so only foo needs to state what global variables are in/out/inout.
Being global variables, they are accessible from everywhere :-) which is why they're an encapsulation problem in the first place.
 -  outer is more DRY, because you don't need to specify the type of the global
 variable received by ref, you just need to know its name.
That's why gawd invented templates.
 - With  outer you can tighten some old code, without changing the signature of
a
 function. If you have an old D module (or a C function converted to C) you
often
 can't (or you don't want) to change the function signature to add the global
 arguments passed by ref. With  outer() the function signature doesn't change,
so
 you can improve your legacy code. It allows a simpler refactoring of code.
You can always wrap it with a template and pass the global by alias.
 More notes:
 - SPARK language has added a feature similar to  outer, but more verbose. See
 comment 5 in issue 5007.
 -  outer() is optional and it's fiddly because not it's not meant for small D
 script-like programs, it's meant as a help for medium-integrity D programs
 (where you may think about using Ada language instead).
Better encapsulation is intended for larger programs - I agree it is useless for small ones.
Sep 27 2014
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/28/2014 01:55 AM, Walter Bright wrote:
 On 9/27/2014 4:20 PM, bearophile wrote:
 Walter Bright:

 It could be nice to have a syntax like lambdas for small
 struct/class methods:
 https://issues.dlang.org/show_bug.cgi?id=7176

 struct Foo {
     int bar(int x) pure { return x * x; }
 }

 Becomes something like::

 struct Foo {
     int bar(int x) pure => x * x; // fixed
 }
I see no gain from that syntax.
Issue 7176 has currently seven votes, so someone seems to like it.
A feature without a solid rationale is no good in spite of how many votes it has.
Uniform syntax for parameter list followed by function body. (int x){ return 2; } function(int x){ return 2; } auto separate(int x){ return 2; } (int x) => 2; function(int x) => 2; auto separate(int x) => 2; auto curriedAdd(int x) => (int y) => x + y; It is a simplification that is also convenient.
Sep 27 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 A feature without a solid rationale is no good in spite of how 
 many votes it has.
I agree that the number of votes alone means very little. But perhaps those persons have reasons. (If votes from people are not important, then better to remove this feature from Bugzilla.)
 D has a nice inline lamda syntax, which was needed. It is not 
 needed for separate functions.
The lambda syntax for function/class methods is not needed, but it's handy and it's sufficiently natural, expecially for many little methods. It's not an important feature, and there are D features that I need far more than this (like syntax to unpack tuples), but some people like it. Apparently C#6 designers agree with that, search for "Expression-bodied members" here: http://www.dotnetcurry.com/showarticle.aspx?ID=1042 The C#6 syntax is the same as the proposed one for D: class Rectangle(int width, int height) { public int Area => width * height; }
 If the function is small enough that parameter setup time is 
 significant, it is likely to be inlined anyway which will erase 
 the penalty.
This is the theory :-) Sometimes I have seen this not to be true.
 Then you really aren't encapsulating the globals the function 
 uses, anyway, and the feature is useless.
The point of having an outer() is to enforce what module-level names a function is using and how it is using them (in/out/inout), so it's useful for _impure_ functions. If your functions can be annotated with "pure" you don't need outer much.
 Being global variables, they are accessible from everywhere :-) 
 which is why they're an encapsulation problem in the first 
 place.
In D we have modules, so variables are module-level, or they are imported from other modules (unfortunately names in a module are public on default when you import the module. I'd like the opposite, to be private to the module, and importable only if they are tagged with "public"). The problem with module-level variables is that sometimes I am using by mistake a global variable when I am instead trying to use a local one. Or on the opposite I am using a local variable by mistake when I'd like to use a module-level one. An attribute like "pure" disallows the access to global mutables, so it solves only half of the problem. Generally knowing exactly what module-level variables (and how) a function is using is very handy to understand the purpose and working of the function itself. So I see outer() as a tool for code understanding, even legacy code because I can add outer() to old code written by other persons.
 -  outer is more DRY, because you don't need to specify the 
 type of the global
 variable received by ref, you just need to know its name.
That's why gawd invented templates.
Templates are a blunt tool to solve the problems faced by outer(). outer() allows you to specify for each variable if it's going to just be read, written, or read-written. And outer() is not named globals() because it works for inner functions too, it allows to control and specify the access of names from the outer scopes, so an inner impure nonstatic function can use outer() to specify what names it can use from the scope of the outer function: void foo() { int x; outer(in x) void bar() { writeln(x); } bar(); }
 You can always wrap it with a template and pass the global by 
 alias.
I think I've never done this. To be tried. Bye, bearophile
Sep 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/28/2014 2:16 AM, bearophile wrote:
 Walter Bright:
 If the function is small enough that parameter setup time is significant, it
 is likely to be inlined anyway which will erase the penalty.
This is the theory :-) Sometimes I have seen this not to be true.
Inlining is not a random thing. If there's a case that doesn't inline, ask about it.
 Then you really aren't encapsulating the globals the function uses, anyway,
 and the feature is useless.
The point of having an outer() is to enforce what module-level names a function is using and how it is using them (in/out/inout), so it's useful for _impure_ functions. If your functions can be annotated with "pure" you don't need outer much.
outer implies purity with a list of exceptions.
 -  outer is more DRY, because you don't need to specify the type of the global
 variable received by ref, you just need to know its name.
That's why gawd invented templates.
Templates are a blunt tool to solve the problems faced by outer(). outer() allows you to specify for each variable if it's going to just be read, written, or read-written.
Again, template functions do that rather nicely, and no type is required.
 And  outer() is not named  globals() because it works for inner
 functions too, it allows to control and specify the access of names from the
 outer scopes, so an inner impure nonstatic function can use  outer() to specify
 what names it can use from the scope of the outer function:

 void foo() {
    int x;
     outer(in x) void bar() {
      writeln(x);
    }
    bar();
 }
This I find to be a bit more lame, because the declarations used will be right there. But if you really wanted to do it, void foo() { int x; static void bar(int x) { writeln(x); } bar(x); }
Sep 28 2014
next sibling parent reply "po" <yes no.com> writes:
  His entire reason for not using C++ lambda, and wanting local 
functions instead, is faulty

His reason: I heard they can perform heap allocation.

Reality: No they do not perform heap allocation, that would only 
happen if you stuffed it into an std::function
Sep 28 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/28/2014 10:57 AM, po wrote:
   His entire reason for not using C++ lambda, and wanting local functions
 instead, is faulty

 His reason: I heard they can perform heap allocation.

 Reality: No they do not perform heap allocation, that would only happen if you
 stuffed it into an std::function
D's will also do heap allocation, but only if you take the address of the local function.
Sep 28 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Inlining is not a random thing. If there's a case that doesn't 
 inline, ask about it.
Even when you use annotations like "forced_inline" and the like you can't be certain the compiler is doing what you ask for. I have seen several critical template functions not inlined even by ldc2 (dmd is usually worse). And if your function is in a pre-compiled object where the source code is not available, inlining doesn't happen.
  outer implies purity with a list of exceptions.
Right, an empty " outer()" equals to the D "weakly pure". But if I put those exceptions then I am essentially stating that a function is not pure. So you usually don't put outer() on pure functions.
 Again, template functions do that rather nicely, and no type is 
 required.
I think templates are blunt tools for this purpose. But I will try to use them for this purpose, to see how they fare. I think I have not seen people use templates for this purpose, so I think it's not very natural.
 void foo() {
   int x;
    outer(in x) void bar() {
     writeln(x);
   }
   bar();
 }
This I find to be a bit more lame, because the declarations used will be right there.
Yes, and a module-level variable can be defined the line before the function definition. Or it can be far from it (it can even be from an imported module). The same is true for the variables defined in the outer function. That's why I have named it outer instead of globals. Even a large function is usually smaller than a whole module (and modern coding practices suggest to avoid very large functions), so the variable definition should be closer (and in D it must be lexically before the definition of the inner function), so the problems with module-level variables is bigger, but it's similar.
 But if you really wanted to do it,

  void foo() {
     int x;
     static void bar(int x) {
       writeln(x);
     }
     bar(x);
  }
As you said, the same is possible with global variables, you can often pass them as arguments, by value or by reference. I agree that the case of using outer() for inner functions is weaker. Bye, bearophile
Sep 28 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Sep 28, 2014 at 10:19:36AM -0700, Walter Bright via Digitalmars-d wrote:
[...]
 Inlining is not a random thing. If there's a case that doesn't inline,
 ask about it.
[...] This is not directly related to this thread, but recently in a Phobos PR we discovered the following case: // This function gets inlined: int func1(int a) { if (someCondition) { return value1; } else { return value2; } } // But this one doesn't: int func2(int a) { if (someCondition) { return value1; } return value2; } IIRC Kenji said something about the first case being convertible to an expression, but the second can't. It would be nice if inlining worked for both cases, since semantically they are the same. T -- Famous last words: I *think* this will work...
Sep 28 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/28/2014 1:25 PM, H. S. Teoh via Digitalmars-d wrote:
 This is not directly related to this thread, but recently in a Phobos PR
 we discovered the following case:

 	// This function gets inlined:
 	int func1(int a) {
 		if (someCondition) {
 			return value1;
 		} else {
 			return value2;
 		}
 	}

 	// But this one doesn't:
 	int func2(int a) {
 		if (someCondition) {
 			return value1;
 		}
 		return value2;
 	}

 IIRC Kenji said something about the first case being convertible to an
 expression, but the second can't. It would be nice if inlining worked
 for both cases, since semantically they are the same.
https://issues.dlang.org/show_bug.cgi?id=7625
Sep 28 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-09-28 00:56, Walter Bright wrote:

 I see no gain from that syntax.
It's very convenient especially when using range based programming. -- /Jacob Carlborg
Sep 28 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Max Klyga:

 https://www.youtube.com/watch?v=TH9VCN6UkyQ
A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Bye, bearophile
Oct 01 2014
next sibling parent reply "po" <yes no.com> writes:
On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote:
 Max Klyga:

 https://www.youtube.com/watch?v=TH9VCN6UkyQ
A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Bye, bearophile
He (deliberately I'd guess)conflates cache friendly data structures and access patterns with his particular preference for a C style. It is a fallacy that he presents as fact. The key to these type of fast code isn't the C style, it is the contiguous data layout, and cache friendly access patterns, both of which are easily enough to perform in modern C++.
Oct 01 2014
next sibling parent reply "currysoup" <sam92cutler hotmail.co.uk> writes:
On Wednesday, 1 October 2014 at 15:17:33 UTC, po wrote:
 On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote:
 Max Klyga:

 https://www.youtube.com/watch?v=TH9VCN6UkyQ
A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Bye, bearophile
He (deliberately I'd guess)conflates cache friendly data structures and access patterns with his particular preference for a C style. It is a fallacy that he presents as fact. The key to these type of fast code isn't the C style, it is the contiguous data layout, and cache friendly access patterns, both of which are easily enough to perform in modern C++.
OOP style and AoS in general does cause cache unfriendly data access. You can separate out your hot and cold data but at that point you're not really programming in an OO style. He doesn't use RTTI, templates, exceptions, etc. for different reasons than cache friendliness. At what point does he say it's difficult to code in a SoA style in C++? He clearly states he sees no advantage to C++ over C.
Oct 01 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
currysoup:

 At what point does he say it's difficult to code in a SoA style 
 in C++?
Perhaps a (part of) language more fit/helpful/nice for that purpose/use can be invented. Bye, bearophile
Oct 01 2014
parent "po" <yes no.com> writes:
 Perhaps a (part of) language more fit/helpful/nice for that 
 purpose/use can be invented.

 Bye,
 bearophile
It isn't as hard as he pretends to write SoA code in C++. In fact it is possible to abstract the underlying data you are operating on, and replace it with vector type Example resembling his butt ugly code: operates only on 1 float at a time struct Vec2{ float x,y; }; void Add2(Vec2* points, int howMany){ for(int i = 0;i<howMany;++i){ points[i].x += 2.0f; points[i].x += 2.0f; } } How I would do it, uses AVX256: template<class T> struct Vec2{ T x,y; }; typedef Vec2<float8> vec2_8f; //float8 is a wrapper around AVX256 8 wide float type that behaves exactly like a //normal float but is actually 8 floats. void Add2(range<vec2_8f> points){ for(auto& p:points){ p += 2.0f; } } C++ can abstract away the fact that float8 is actually implemented using a bunch of AVX intrinsics. Using his approach he'd be manually writing intrinsics until the cows came home.
Oct 01 2014
prev sibling parent reply "po" <yes no.com> writes:
 OOP style and AoS in general does cause cache unfriendly data 
 access. You can separate out your hot and cold data but at that 
 point you're not really programming in an OO style. He doesn't 
 use RTTI, templates, exceptions, etc. for different reasons 
 than cache friendliness.
Modern C++ != OO style. I'd say modern C++ is more generic + functional than OO. He seems to think C++ is about programming in some sort of Java design pattern inspired way.
 At what point does he say it's difficult to code in a SoA style 
 in C++? He clearly states he sees no advantage to C++ over C.
1. He references Design patterns during his tirade against C++, who the hell uses design patterns in C++ these days? 2. He uses Ogre, a 15 year old terrible mess of a rendering engine, written in a nasty Java style, as an example of why C++ is bad
Oct 01 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 01.10.2014 23:03, schrieb po:
 OOP style and AoS in general does cause cache unfriendly data access.
 You can separate out your hot and cold data but at that point you're
 not really programming in an OO style. He doesn't use RTTI, templates,
 exceptions, etc. for different reasons than cache friendliness.
Modern C++ != OO style. I'd say modern C++ is more generic + functional than OO. He seems to think C++ is about programming in some sort of Java design pattern inspired way.
If he is stuck in the late 90's/early 2000's, yes.
 At what point does he say it's difficult to code in a SoA style in
 C++? He clearly states he sees no advantage to C++ over C.
1. He references Design patterns during his tirade against C++, who the hell uses design patterns in C++ these days?
Those architects, specially the CORBA ones, are nowadays doing J2EE and WPF MVVM applications. And the original design patterns were actually targeted at Smalltalk, with C++ on the side as the language was started to get popular in the industry.
 2. He uses Ogre, a 15 year old terrible mess of a rendering engine,
 written in a nasty Java style, as an example of why C++ is bad
I never liked Ogre. A strange mix of OO with too much low level C like stuff still. At least when I looked at it a few years ago. -- Paulo
Oct 01 2014
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 2 October 2014 07:03, po via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 OOP style and AoS in general does cause cache unfriendly data access. You
 can separate out your hot and cold data but at that point you're not really
 programming in an OO style. He doesn't use RTTI, templates, exceptions, etc.
 for different reasons than cache friendliness.
Modern C++ != OO style. I'd say modern C++ is more generic + functional than OO. He seems to think C++ is about programming in some sort of Java design pattern inspired way.
That's what a post-grad often tends to do...
Oct 01 2014
prev sibling next sibling parent reply "currysoup" <sam92cutler hotmail.co.uk> writes:
I certainly believe C++ style and it's community promote the idea 
of zero overhead abstractions and the kind of OOP style which 
_does_ cause cache misses.
Oct 01 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 01.10.2014 17:40, schrieb currysoup:
 I certainly believe C++ style and it's community promote the idea of
 zero overhead abstractions and the kind of OOP style which _does_ cause
 cache misses.
C++ does not imply OOP. And the zero overhead abstractions are a culture heritage from C as it was the only way to sell C++ to most C developers. -- Paulo
Oct 01 2014
prev sibling parent reply "po" <yes no.com> writes:
On Wednesday, 1 October 2014 at 15:40:59 UTC, currysoup wrote:
 I certainly believe C++ style and it's community promote the 
 idea of zero overhead abstractions and the kind of OOP style 
 which _does_ cause cache misses.
Take a look at the STL. See any OOP? Right cause there isn't any. Boost? Nope. C++ jumped off the OOP bandwagon some time ago.
Oct 01 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 01.10.2014 23:16, schrieb po:
 On Wednesday, 1 October 2014 at 15:40:59 UTC, currysoup wrote:
 I certainly believe C++ style and it's community promote the idea of
 zero overhead abstractions and the kind of OOP style which _does_
 cause cache misses.
Take a look at the STL. See any OOP? Right cause there isn't any. Boost? Nope.
I see lots of it. How many examples do you want?
   C++ jumped off the OOP bandwagon some time ago.
That I agree. We have learned to not abuse hierarchies and to take advantage of the multi-paradigm capabilities of the language. -- Paulo
Oct 01 2014
parent reply "po" <yes no.com> writes:
  Take a look at the STL. See any OOP? Right cause there isn't 
 any.
  Boost? Nope.
I see lots of it. How many examples do you want?
Well Boost might have some, I haven't looked at every library. I don't know of any OOP in the STL, unless you mean the 1980's stuff like iostreams and the other shit most people avoid using, but I don't think this is considered part of the STL
Oct 01 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 01.10.2014 23:44, schrieb po:
  Take a look at the STL. See any OOP? Right cause there isn't any.
  Boost? Nope.
I see lots of it. How many examples do you want?
Well Boost might have some, I haven't looked at every library. I don't know of any OOP in the STL, unless you mean the 1980's stuff like iostreams and the other shit most people avoid using, but I don't think this is considered part of the STL
Any use of a class instance is part of OOP. IOStreams, iterators, strings, containers, ranges, filesytem, networking, graphics, traits Being lazy, and counting its occurrences in comments and when used as instead of typename in templates as well /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include $ grep -R class * | uniq | wc -c 15601 STL is a name that stuck from the old days when it wasn't part of the language. Nowadays it is just the C++ standard library. -- Paulo
Oct 01 2014
parent reply "po" <yes no.com> writes:
  I don't know of any OOP in the STL, unless you mean the 
 1980's stuff
 like iostreams and the other shit most people avoid using, but 
 I don't
 think this is considered part of the STL
Any use of a class instance is part of OOP. IOStreams, iterators, strings, containers, ranges, filesytem, networking, graphics, traits Being lazy, and counting its occurrences in comments and when used as instead of typename in templates as well /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include $ grep -R class * | uniq | wc -c 15601 STL is a name that stuck from the old days when it wasn't part of the language. Nowadays it is just the C++ standard library. -- Paulo
According to Stepanov STL author: http://www.stlport.org/resources/StepanovUSA.html "Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people." I'd agree with him, just using a class, because it is the primary abstraction in C++, does not make your code OOP.
Oct 01 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 02.10.2014 00:11, schrieb po:
  I don't know of any OOP in the STL, unless you mean the 1980's stuff
 like iostreams and the other shit most people avoid using, but I don't
 think this is considered part of the STL
Any use of a class instance is part of OOP. IOStreams, iterators, strings, containers, ranges, filesytem, networking, graphics, traits Being lazy, and counting its occurrences in comments and when used as instead of typename in templates as well /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include $ grep -R class * | uniq | wc -c 15601 STL is a name that stuck from the old days when it wasn't part of the language. Nowadays it is just the C++ standard library. -- Paulo
According to Stepanov STL author: http://www.stlport.org/resources/StepanovUSA.html "Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people." I'd agree with him, just using a class, because it is the primary abstraction in C++, does not make your code OOP.
Well I disagree with him and can find examples of static and dynamic polymorphism, data encapsulation and aggregation everywhere in STL, even if he dislikes OO people. Algorithms is probably the only part that is free of OO concepts. -- Paulo
Oct 01 2014
parent reply Max Klyga <max.klyga gmail.com> writes:
On 2014-10-01 22:33:39 +0000, Paulo Pinto said:

 Am 02.10.2014 00:11, schrieb po:
 
 I don't know of any OOP in the STL, unless you mean the 1980's stuff
 like iostreams and the other shit most people avoid using, but I don't
 think this is considered part of the STL
 
Any use of a class instance is part of OOP. IOStreams, iterators, strings, containers, ranges, filesytem, networking, graphics, traits Being lazy, and counting its occurrences in comments and when used as instead of typename in templates as well /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include $ grep -R class * | uniq | wc -c 15601 STL is a name that stuck from the old days when it wasn't part of the language. Nowadays it is just the C++ standard library. -- Paulo
According to Stepanov STL author: http://www.stlport.org/resources/StepanovUSA.html "Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people." I'd agree with him, just using a class, because it is the primary abstraction in C++, does not make your code OOP.
Well I disagree with him and can find examples of static and dynamic polymorphism, data encapsulation and aggregation everywhere in STL, even if he dislikes OO people. Algorithms is probably the only part that is free of OO concepts.
Data encapsulation is not unique to oop. STL is ADT not OOP.
Oct 01 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 02.10.2014 01:07, schrieb Max Klyga:
 On 2014-10-01 22:33:39 +0000, Paulo Pinto said:

 Am 02.10.2014 00:11, schrieb po:
 I don't know of any OOP in the STL, unless you mean the 1980's stuff
 like iostreams and the other shit most people avoid using, but I don't
 think this is considered part of the STL
Any use of a class instance is part of OOP. IOStreams, iterators, strings, containers, ranges, filesytem, networking, graphics, traits Being lazy, and counting its occurrences in comments and when used as instead of typename in templates as well /cygdrive/c/android-sdk/android-ndk/sources/cxx-stl/gnu-libstdc++/4.8/include $ grep -R class * | uniq | wc -c 15601 STL is a name that stuck from the old days when it wasn't part of the language. Nowadays it is just the C++ standard library. -- Paulo
According to Stepanov STL author: http://www.stlport.org/resources/StepanovUSA.html "Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people." I'd agree with him, just using a class, because it is the primary abstraction in C++, does not make your code OOP.
Well I disagree with him and can find examples of static and dynamic polymorphism, data encapsulation and aggregation everywhere in STL, even if he dislikes OO people. Algorithms is probably the only part that is free of OO concepts.
Data encapsulation is not unique to oop. STL is ADT not OOP.
STL was ADT when it was initially written in Ada 83, not any longer. First of all it doesn't exist any longer as such. The International Standard ISO/IEC 14882:2014(E) Programming Language C++ has zero occurrences of the word STL. ADT implies using modules, data structures and functions that operate on those functions. Which in C++ is achieved via separate compilation, namespaces and functions. Basically what Ada 83, Mesa and Modula-2, UCSD Pascal offered as abstraction for organizing algorithms and data structures. If a class is being used, then it already uses the first concept of OOP. Aggregation of data and member functions into a type. A module on steroids. The door is also open to inheritance and aggregation. If a class does not forbid inheritance, then it can have derived classes, even if the author did not intend it. Thus inheritance and dynamic polymorphism came into the picture. Two other OOP concepts. Finally, just for the fact that we have objects, member function invocations are now static dispatch. But if virtual methods are declared, then dynamic dispatch comes into play. Both properties of OOP systems. Given the way C++ allows for function overloading, static multi-method dispatch is also possible when used with NVO. Just because inheritance is not used, it doesn't mean something isn't OOP. There are much more concepts at play. When concepts lite come into the language, then C++ gains another way to deal with interfaces. Which will be used a lot in the standard library as well. As I mentioned in another post. I can easily provide examples of the C++ standard library classes and how they use OOP concepts. -- Paulo
Oct 01 2014
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 2 October 2014 01:17, po via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote:
 Max Klyga:

 https://www.youtube.com/watch?v=TH9VCN6UkyQ
A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need? Bye, bearophile
He (deliberately I'd guess)conflates cache friendly data structures and access patterns with his particular preference for a C style. It is a fallacy that he presents as fact.
He uses C style as an aggressive reminder of what you're actually trying to do at all times. We actually did this in our own engine long before he started giving lectures like this. One of the best ways to stop people doing insane shit in C++ is to ban C++. The engine dev's loved this commitment to C, but the game logic programmers hated us ;) There is a middle ground though...
Oct 01 2014
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote:
 Max Klyga:

 https://www.youtube.com/watch?v=TH9VCN6UkyQ
A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need?
Probably because C++ is good enough and already has mature infrastructure.
Oct 01 2014
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 2 October 2014 00:16, bearophile via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 Max Klyga:

 https://www.youtube.com/watch?v=TH9VCN6UkyQ
A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need?
Most gamedev's aren't quite as staunch as Mike Acton. The principle is there, ingrained in every gamedev, but that doesn't mean we all love flat C (although lots of us do!). I've never used RTTI, I've never used exceptions, certainly never use multiple inheritance, I rarely use templates (in C++)... but I'm still attracted to D!? I often find this strange... but not really. In D, I still don't use RTTI, I still don't use exceptions, I tend to box use of templates into their own worlds, so I would never use them pervasively (like phobos). You'll notice at one point that he talked about using offline text processing tools to do codegen... this is basically because C's preprocessor sucks, and C++ templates suck. D templates have proven to eliminate a lot of those offline tools for me. The code is kept in the same place, and built using the same tool. I suspect even Acton would appreciate features like CTFE. You'll also notice he made repeated reference to build environment complexity and build times. D also offers potential compiler advantages, purity, immutable, etc, which give the optimiser information which it can use to improve codegen which is awkward in C/C++.
Oct 01 2014
parent Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 02/10/2014 08:22, Manu via Digitalmars-d a écrit :
 On 2 October 2014 00:16, bearophile via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 Max Klyga:

 https://www.youtube.com/watch?v=TH9VCN6UkyQ
A third talk (from another person) about related matters: https://www.youtube.com/watch?v=rX0ItVEVjHc He doesn't use RTTI, exceptions, multiple inheritance, STL, templates, and lot of other C++ stuff. On the other hand he writes data-oriented code manually, the compiler and language give him only very limited help, and the code he writes looks twiddly and bug-prone. So why aren't they designing a language without most of the C++ stuff they don't use, but with features that help them write the data-oriented code they need?
Most gamedev's aren't quite as staunch as Mike Acton. The principle is there, ingrained in every gamedev, but that doesn't mean we all love flat C (although lots of us do!). I've never used RTTI, I've never used exceptions, certainly never use multiple inheritance, I rarely use templates (in C++)... but I'm still attracted to D!? I often find this strange... but not really. In D, I still don't use RTTI, I still don't use exceptions, I tend to box use of templates into their own worlds, so I would never use them pervasively (like phobos). You'll notice at one point that he talked about using offline text processing tools to do codegen... this is basically because C's preprocessor sucks, and C++ templates suck. D templates have proven to eliminate a lot of those offline tools for me. The code is kept in the same place, and built using the same tool. I suspect even Acton would appreciate features like CTFE. You'll also notice he made repeated reference to build environment complexity and build times. D also offers potential compiler advantages, purity, immutable, etc, which give the optimiser information which it can use to improve codegen which is awkward in C/C++.
For the application I am working on the 3D developer wrote everything in c++ style, but he made a lot of mistakes that killing performances. We are far away cache miss issues (or polymorphism,...), and more in instancing ones. Last week I removed allocation and deallocation of meshes made in the sort for transparent models. new and delete aren't the main problem, it was the code in constructors and destructors that made heavy use of vectors. Things like vector.erase(vector.find("boo")); One my PC (a gamer one) I just win 20FPS from 10 to 30. For a scene of 700 objects (< 50 000 triangles). YEP this is really bad for my i7 and my 670GTX. I have a lot of work to do, normally on my PC for a such scene I can expect much more than 200 FPS. This is just one of our performances issues, and for me it's not due to only C++ OOP. It's about experience. I had never worked on games or applications need a level of optimization impose me SOA design but reusing chunk of memories and avoiding unnecessary computations are always things I carry on. For those are interested to see more about the application : https://groups.google.com/forum/#!forum/home-design-3d-beta This is also the one that inspired me and my friend for DQuick.
Oct 11 2014