On Thu, Apr 19, 2012 at 10:42:27PM -0500, Andrei Alexandrescu wrote:
> On 4/19/12 3:05 PM, H. S. Teoh wrote:
> >Yeah, I've been working with C++ for almost 2 decades, and I really can't say I'd recommend it for new projects. At my day job, for example, we actually migrated from C++ back to plain old C, due to an incredibly over-engineered C++ codebase that was slow, bloated, and unmaintainable.  It sounds laughable to the casual observer, but I have to say that there was actually a lot gained by this migration. We are much more productive with the new C-based system than C++. There are just too many ways to write bad code in C++. C makes everything simple and clear, if a bit tedious at times (due to basically partially reimplementing a class system in C).
> 
> This is interesting. We use C++ at Facebook all over the place, and gainfully. If we were to use C, we'd have major difficulties with e.g. containers. The thought of using a hashtable in C... ouch.
[...]

Hashtables in C aren't *that* nasty, if you do it right. (But of course, D's AA's trumps them all, even in its current buggy state.)

But I suppose my experience has been colored by the trauma of working with an over-engineered C++ system that only one guy understands, resulting in people who came after him rewriting their own versions of code that they didn't dare reuse 'cos they didn't understand it, eventually ending up in a patch-upon-bandaid-upon-patch codebase with umpteen ways of doing the same thing that *nobody* understands, not even the original guy.

One example. The system had this elaborate database abstraction class hierarchy that could do wonders: automatically populate data structures, automatically ensure data consistency, periodically do self-maintenance, replicate itself and sync with backup servers, etc., -- if we only knew how to use it.  Problem is, only the guy who wrote it knew which obscure class objects to instantiate to make the thing sing to our tune, so somebody got frustrated and wrote what is essentially a wrapper function that takes a raw SQL string and executes it, thus bypassing the entire beautiful database abstraction code completely. Since everybody else didn't understand the original code either, they started using this SQL bypass function everywhere... only to discover that the system broke in subtle ways when you didn't go through its beautifully over-engineered abstractions. So more and more dirty hacks were introduced that piled on top of each other like festering infected bandages that fail to address the real wound underneath.

At the end of its miserable life, the system had places where useful work was done in dtors(!), and was so bloated that the developers of other modules were so scared of linking in the C++ API library that they preferred instead to make function calls to the C++ code by fwrite()ing function parameters into a file, fork() and exec()ing a helper utility that linked to the C++ library, which fread()'d function parameters from the file, then called a library function that then serialized said parameters so that it can do an IPC call to a C++ daemon. The return value of the function took a similar route to pass back to the C code. This was done for *every* function call made from C to the C++ code.

My previous supervisor, who was involved in the rewrite effort in C, was so elated when the new system was finally ready and he could go into the source tree and gleefully delete every single one of those C++ files that constituted the old system. I have to admit I shared the same sentiment. (Heck, I could re-checkout the old code and then delete it all over again -- it was that gratifying to see it die an overdue death.)


T

-- 
Tech-savvy: euphemism for nerdy.

On Thursday, 19 April 2012 at 19:37:28 UTC, Nick Sabalausky wrote:
> "Paulo Pinto" <pjmlp@progtools.org> wrote in message
> news:jmpl39$1oa1$1@digitalmars.com...
>> Hi,
>>
>> just wanted to announce that Sony has finally made the new Playstation
>> Vita SDK available, as we were discussing some months ago.
>>
>> http://www.playstation.com/pss/index_e.html
>>
>> The gamming industry seems to be slowing moving to C#. Would we still
>> be able to convince developers to move to D instead?
>>
>
> Yes. I suspect that the movement to C# is somewhat of a compromise due to
> the fact that C/C++ has been the *only* real systems language usable for
> most gaming systems. Obviously, something better than C++ is needed, and
> thanks to the moronic VM/interpreted obsessions from the last decade or so
> that rendered most new languages impotent, there was no real alternative to
> C++. So, I suspect, that's why they made the compromise of going with C#.
>
> But D is *real* systems language, unlike C#. And frankly, it beats the snot
> out of C#. I'm not just saying that subjectively as D fan: Five years ago
> (if not less) I considered C# and D tied as my favorite languages. But the
> more I used both, the more I got fed up with C#'s dumb limitations and MS's
> disinterest in addressing them, and the more I liked D.
>
> If D can't be made to attract game devs away from C++/C#, then I'll loose
> what little faith I have left in mainstream games development.

As a C# game developer very interested in D, I'll chime in on this. The contrast from C++ is definitely a part of it. C# is very pleasant to work in for the most part. C# is actually quite fast, but would I prefer to also reap the full benefit of native speed? Absolutely, that's why I'm so interested in D.

I think there's more to it though. I mentioned this in the Fibers thread, but C# provides a limited form of coroutine built into the language. The utility of coroutines in game logic cannot be overstated. Being able to do things like:

{
    WalkTo(pos);
    WaitForSeconds(3);
    FireMyLaser(target);
}

And have it JUST WORK like you want is huge. You can get this by delegating out to a script language that supports it like LUA, but then we're back in JIT territory. Expressing this kind of thing in the native language itself would be ideal.

I think D is sitting on a game dev goldmine with core.thread.Fiber. Especially the bit about being able to migrate them across threads. Having 10,000 entity coroutines active and being able to load balance them across all your cores with a taskpool would be amazing. I'm just worried that since Fiber seems to be such a low-key feature that it won't survive a refactor of the library or fall out of favor over time and be deprecated.

I also find it interesting.

Personally I will only use C if I really have to, as the language is just too low
level for what I am used to. I have been following C++ since the late 80's and
used to work with it professionaly until around 2006. As such I am not lost
in C++ complexity and I like to be able to use STL and Boost.

All languages that are able to provide proper set abstractions are complex,
even D for that matter.

While I worked at NSN there was a project that did migrate from Java to C,
but it was only due to hardware restrictions on some network elements for
the specific unit. Just to give another example of migration to C.

--
Paulo

"Andrei Alexandrescu"  wrote in message news:jmqlu9$mov$1@digitalmars.com...

On 4/19/12 3:05 PM, H. S. Teoh wrote:
> Yeah, I've been working with C++ for almost 2 decades, and I really
> can't say I'd recommend it for new projects. At my day job, for example,
> we actually migrated from C++ back to plain old C, due to an incredibly
> over-engineered C++ codebase that was slow, bloated, and unmaintainable.
> It sounds laughable to the casual observer, but I have to say that there
> was actually a lot gained by this migration. We are much more productive
> with the new C-based system than C++. There are just too many ways to
> write bad code in C++. C makes everything simple and clear, if a bit
> tedious at times (due to basically partially reimplementing a class
> system in C).

This is interesting. We use C++ at Facebook all over the place, and
gainfully. If we were to use C, we'd have major difficulties with e.g.
containers. The thought of using a hashtable in C... ouch.

Andrei 

On 2012-04-20 01:11, Sean Kelly wrote:

> Alan Wake, for example, uses classic cinematic techniques for scaring the player, and to make sure they're experienced, railroads the player through the predetermined route, even if the rational choice would be to do something else.  In movies this technique is effective because seeing the protagonist do something stupid creates a sense of tension as the viewer anticipates the Bad Thing that is sure to happen.  In a game, the player just has the choice that should be provided to them taken away, creating a sense of frustration at not being able to do something sensible.  What follows is a tedious plod towards the inevitable Scary Moment, which still relies on the player walking along the correct path so the event is triggered from the intended position.

In some games these paths and positions can be moved depending on that the player does to make sure they are triggered.

-- 
/Jacob Carlborg

Well, C# can also be real systems programming language, see Singularity.
And native code compilers are also available (Bartok, Mono AOT, NGEN).

D names itself a system programming language, but I am yet to see any OS
coded on it. Without system programming examples, it becomes just another
application level language.

On the other hand I confess this is a very hard task, as most of systems programming
languages that manage to exist as such (PL/I, Ada, C, C++, Mac Pascal), did so because
there was an OS vendor that made use of them.

Now that I mention this, does anyone know if D is being used as research
language in any operating system department in some university? I remember
there were some posts about it long time ago.

What I see going for D in terms of language features:

- scope
- compile time metaprogramming
- mixin as a kind of macro mechanism
- inline assembler (this one might be a bit debatable)
- delegation via subtyping
- all available implementations compile straight to native code

--
Paulo


"Nick Sabalausky"  wrote in message news:jmpphn$20s9$1@digitalmars.com...

"Paulo Pinto" <pjmlp@progtools.org> wrote in message
news:jmpl39$1oa1$1@digitalmars.com...
> Hi,
>
> just wanted to announce that Sony has finally made the new Playstation
> Vita SDK available, as we were discussing some months ago.
>
> http://www.playstation.com/pss/index_e.html
>
> The gamming industry seems to be slowing moving to C#. Would we still
> be able to convince developers to move to D instead?
>

Yes. I suspect that the movement to C# is somewhat of a compromise due to
the fact that C/C++ has been the *only* real systems language usable for
most gaming systems. Obviously, something better than C++ is needed, and
thanks to the moronic VM/interpreted obsessions from the last decade or so
that rendered most new languages impotent, there was no real alternative to
C++. So, I suspect, that's why they made the compromise of going with C#.

But D is *real* systems language, unlike C#. And frankly, it beats the snot
out of C#. I'm not just saying that subjectively as D fan: Five years ago
(if not less) I considered C# and D tied as my favorite languages. But the
more I used both, the more I got fed up with C#'s dumb limitations and MS's
disinterest in addressing them, and the more I liked D.

If D can't be made to attract game devs away from C++/C#, then I'll loose
what little faith I have left in mainstream games development.

On 20-04-2012 08:43, Paulo Pinto wrote:
> Well, C# can also be real systems programming language, see Singularity.

No, this is actually a common misconception.

Singularity does *not* use plain C#. It uses Sing#, which is an extension of Spec# adding message-passing, compile-time reflection, and safe manual memory management features. Spec# is a version of C# heavily based on design-by-contract (I'd argue its DbC is far superior to D's in fact).

Plain C# out of the box is not useful for systems-level programming, and especially not in a kernel.

> And native code compilers are also available (Bartok, Mono AOT, NGEN).
>
> D names itself a system programming language, but I am yet to see any OS
> coded on it. Without system programming examples, it becomes just another
> application level language.

https://github.com/xomboverlord/xomb

>
> On the other hand I confess this is a very hard task, as most of systems
> programming
> languages that manage to exist as such (PL/I, Ada, C, C++, Mac Pascal),
> did so because
> there was an OS vendor that made use of them.
>
> Now that I mention this, does anyone know if D is being used as research
> language in any operating system department in some university? I remember
> there were some posts about it long time ago.
>
> What I see going for D in terms of language features:
>
> - scope
> - compile time metaprogramming
> - mixin as a kind of macro mechanism
> - inline assembler (this one might be a bit debatable)
> - delegation via subtyping
> - all available implementations compile straight to native code
>
> --
> Paulo
>
>
> "Nick Sabalausky" wrote in message news:jmpphn$20s9$1@digitalmars.com...
>
> "Paulo Pinto" <pjmlp@progtools.org> wrote in message
> news:jmpl39$1oa1$1@digitalmars.com...
>> Hi,
>>
>> just wanted to announce that Sony has finally made the new Playstation
>> Vita SDK available, as we were discussing some months ago.
>>
>> http://www.playstation.com/pss/index_e.html
>>
>> The gamming industry seems to be slowing moving to C#. Would we still
>> be able to convince developers to move to D instead?
>>
>
> Yes. I suspect that the movement to C# is somewhat of a compromise due to
> the fact that C/C++ has been the *only* real systems language usable for
> most gaming systems. Obviously, something better than C++ is needed, and
> thanks to the moronic VM/interpreted obsessions from the last decade or so
> that rendered most new languages impotent, there was no real alternative to
> C++. So, I suspect, that's why they made the compromise of going with C#.
>
> But D is *real* systems language, unlike C#. And frankly, it beats the snot
> out of C#. I'm not just saying that subjectively as D fan: Five years ago
> (if not less) I considered C# and D tied as my favorite languages. But the
> more I used both, the more I got fed up with C#'s dumb limitations and MS's
> disinterest in addressing them, and the more I liked D.
>
> If D can't be made to attract game devs away from C++/C#, then I'll loose
> what little faith I have left in mainstream games development.
>


-- 
- Alex

> As for C#: I've always seen it as...maybe not "Java done right" because I'm

It's also Delphi.

Delphi + Java

"Paulo Pinto" <pjmlp@progtools.org> wrote in message news:jmr0j7$1h5g$1@digitalmars.com...
> Well, C# can also be real systems programming language, see Singularity. And native code compilers are also available (Bartok, Mono AOT, NGEN).
>

Even so, the C# language itself can't really handle many native/systems-level tasks. For example, while I've heard that it's technically possible to reinterpret-cast a piece of memory, actually doing it involves some dark obscure corner of the API.

At least it actually has pointers though, unline a certain other flagship VM language...

> D names itself a system programming language, but I am yet to see any OS coded on it. Without system programming examples, it becomes just another application level language.
>

Many people would argue that systems-langauge doesn't necessarily mean "OS written in it". Not that I intend to nit-pick the point: Just FWIW.

On Friday, 20 April 2012 at 06:43:51 UTC, Paulo Pinto wrote:
> D names itself a system programming language, but I am yet to see any OS
> coded on it. Without system programming examples, it becomes just another
> application level language.

The XOmB project has been around since forever:

    https://github.com/xomboverlord/xomb

On 2012-04-20 08:43, Paulo Pinto wrote:

> Now that I mention this, does anyone know if D is being used as research
> language in any operating system department in some university? I remember
> there were some posts about it long time ago.
>

http://prowiki.org/wiki4d/wiki.cgi?KernelWithD

I think there are a couple of other ones as well, don't recall their name though.

-- 
/Jacob Carlborg