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

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 :-)

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.

> 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

 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!"

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...

> - 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--

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.

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

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.