On 11 April 2013 08:54, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/8/2013 2:30 AM, Manu wrote:
>
>> ... so where's your dconf talk then? You can have one of my slots, I'm
>> very
>> interested to hear all about it! ;)
>>
>
> I'm not willing to give up any of your slots!
>

:)
Well, it was mostly a joke, but if he does have a lot to say on the matter,
I'm very interested to hear such a talk myself. I'm sure there's room to
slot one more in somewhere ;)

On 11 April 2013 10:53, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/8/2013 5:06 AM, Jacob Carlborg wrote:
>
>> I don't know. The thread safe example probably works better with an
>> annotated
>> type than nogc.
>>
>
> @nogc would have to be enforced by the compiler. Furthermore, it's viral in that much of the runtime library would have to be gone through and marked @nogc, otherwise it would be fairly useless.
>
> It's a fairly intrusive change.
>

As a key user, I can't say I'd even want to use this. I'd rather just see time put into improving the GC, making it more practical/flexible ;)

On 4/10/2013 8:36 PM, Manu wrote:
> As a key user, I can't say I'd even want to use this. I'd rather just see time
> put into improving the GC, making it more practical/flexible ;)

Me too. I shudder at the ugliness of pervasive @nogc attributes.

On Wednesday, 10 April 2013 at 16:08:53 UTC, Andrei Alexandrescu wrote:
> It may as well be a mistake that nonvirtual functions are at all part of a class' methods. This has been quite painfully seen in C++ leading to surprising conclusions: http://goo.gl/dqZrr.

"Non-Member Functions Improve Encapsulation" is invalid for D because of implicit friends.

It was discussed before: http://forum.dlang.org/post/op.wbyg2ywyeav7ka@localhost.localdomain

--
Alexander

On Wednesday, 10 April 2013 at 21:22:30 UTC, Nick Sabalausky wrote:
> On Wed, 10 Apr 2013 16:35:56 -0400
> Jeff Nowakowski <jeff@dilacero.org> wrote:
>> > Keep in mind, I'm using "interactive movie" largely for lack of a
>> > better term. "Videogame" definitely isn't the right word for them.
>> 
>> They're games,
>
> For many (admittedly, not all) of them, I really don't believe "games"
> is an accurate term (Don't misinterpret that into a statement of "Only
> true 'games' are legitimate" because I never said such a thing.)
> They have interactive sections, and they are entertainment, but being
> interactive entertainment does not inherently imply "game".
>
> Keep in mind, even sandbox titles, which are definitely not remotely
> "interactive movie" or cinematic at all (at least any of the ones I've
> seen), have long been debated as to whether or not they are "games".
> And note that nobody ever said that was a bad thing. It might be a bad
> thing if the industry focused too heavily on them, but that would be a
> completely different complaint.

I was frustrated with the all-inclusive term "videogame" until I realized that spoken languages (no to mention programming ones) change over time. The technical definition of "game" is one thing, but if a language starts using a term for something else, eventually that just becomes the definition. I think the original reason it caught on was because video games have a childlike wonder about them which reminds people of "playing". But now that the term's caught on, it's not going away. Therefore video games need not be games, in the traditional sense that they must have rules. All life is a game... and the people are merely players! That's the new sense of the word I think.

On Wed, 10 Apr 2013 19:42:57 -0700
Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/10/2013 3:02 PM, Nick Sabalausky wrote:
> > I have noticed that programming and videogames both scratch the same mental itch, at least for me. If I've been doing a lot of one, I'm less motivated to do the other.
> 
> 
> Oddly for me, programming video games kinda wrecked my enjoyment of them. I keep seeing the man behind the curtain instead of the fantasy :-)
> 

Long ago, when I was an anxious budding indie-game dev (before I got side-tracked on web), I trained myself to analyze games on their various levels: technical, gameplay mechanics, aesthetics, interface, etc. Afterwords, I never did learn how to turn that part of my brain off ;). Personally, though, I find that process entertaining as well, so I haven't found it to hinder my ability to enjoy a good game.

I realize some people may scoff at seeing that last sentence coming
from me, but there really are a lot of games that I do enjoy very much
overall - even when there's things I think could, or even should,
have been done better. I just tend to find "what was done wrong" much
more interesting to discuss them "what was done well". Probably because
"things done right" are problems that have been solved, whereas "things
done wrong" are problems to be solved and signal areas with a ripe
potential for improvement.

On Wed, 10 Apr 2013 15:29:25 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> 
> I wonder if this is why I enjoy retro games more -- they require less concentration and lots of fun can be had for not too much effort. I find that a lot of modern games seem to require a lot of concentration -- keeping track of a convoluted storyline, keeping track of one's 3D surroundings, being on one's toes to react quickly at surprise enemy attacks, etc.. After a full day's worth of coding, that's the last thing I want to be doing. Much better to relax with something that can be played in a more relaxed/casual way.
> 

Strange, I find the exact opposite to true. I always felt this summed it up perfectly:

http://semitwist.com/download/img/funny/digitalunrest-2008-09-29.jpg

(That said, I never thought MM9 was *as* hard as people made it out
to be. At first it seemed the same as all the older megaman's, and
then it wasn't long before I could get through the whole thing in about
an hour. Still one of the best games ever made, though. But if you want
a *really* hard MegaMan, try "MegaMan & Bass". I'm totally stuck in
that.)

The last 10 or so years, big-budget games have tended to be designed specifically so that anyone can get to the end without much effort. The lack of challenge makes them tedious and boring.

For example, the Mario and Zelda games have done nothing but get
progressively easier sine the 80's (compare the battle system in the
original zelda to *any* 3D zelda - the former is an addictive
challenge, the latter is mindless button-mashing/waggle and
*vastly* easier.) New Mario is fun, but notably easier than Mario
1/2/3/64. And then there's the old Kid Icarus. *Phew!* - that's not for
the faint of heart. Most people don't even know that it has
zelda/Metroid-like dungeons or horizontal levels because they never got
past level 3.

As far as "keeping track of a convoluted storyline", I rarely pay attention to the stories/dialog/characters/etc anyway. There are exceptions (like 2D JRPGs or Disgaea), but most games I just skip through the dialog (9 times out of 10 it's both uninteresting and irrelevant to the gameplay), and when a game doesn't let me skip a cutscene or scripted event I'll just grab a drink or snack or hit the can if I need to, or otherwise just hit "Switch Inputs" and find something not-too-horrible on TV while I wait for the tell-tale sound of a level being loaded off disc.

On 2013-04-10 18:49, Andrej Mitrovic wrote:

> Just take a look at the upcoming changelog:
>
> https://github.com/D-Programming-Language/d-programming-language.org/pull/303

It's great to see that we will have, what it looks like, a proper changelog of the next release.

-- 
/Jacob Carlborg

On Wednesday, 10 April 2013 at 22:48:06 UTC, Walter Bright wrote:
> On 4/6/2013 3:10 AM, Paulo Pinto wrote:
>> However there are cases where every byte and every ms matter, in those cases you
>> are still better with C, C++ and Fortran.
>
> This is not correct.
>
> If you care about every byte, you can make D code just as performant.
>
> And by caring about every byte, you'll need to become as familiar with how D generates code, and the cost of what various features entail, as you would be in C++.

Same can be said for JVM and .NET languages.

Some of our consulting projects are conversion of C++ code into one of the said technologies. We usually achieve performance parity with the existing application.

With C, C++ and Fortran it is easier to achieve a certain performance level without effort, while the other languages require a bit of effort knowing the runtime, writing GC friendly data structures and algorithms, and doing performance analysis, but it achievable as well.

Many developers don't want to do this, hence my statement.

--
Paulo

On Wednesday, 10 April 2013 at 22:50:48 UTC, Walter Bright wrote:
> On 4/7/2013 3:59 AM, Paulo Pinto wrote:
>> The current compilers just don't have the amount of investment in more than 20
>> years of code optimization like C++ has. You cannot expect to achieve that from
>> one moment to the other.
>
> This is incorrect, as dmd, gdc, and ldc all use the backends of C++ compilers, and the code generated is as good as that of the corresponding C++ compiler.

Correct, assuming the frontend organizes the intermediate information in a way that the backend can make the best use of it, or am I wrong?