headers
bearophile | 1 Apr 2010 01:04
Picon

Re: Feature suggestion: in-place append to array

Mike S:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

It's a nice read. I don't see them switching to D soon. If you whisper them that D is based on a GC they will run
away screaming :-)

Bye,
bearophile
Permalink | Reply | 8 comments |
headers
4tuu4k002 | 1 Apr 2010 02:16
Picon
Favicon

Unofficial wish list status.(Apr 2010)


Hi

This is the monthly status for the unofficial d wish list: 
http://all-technology.com/eigenpolls/dwishlist/

I am closing this wish list. 
New requests should be posted to bugzilla on http://d.puremagic.com/issues/

It would be a great help, 
if you could help move some of the wish list items to bugzilla.
But please use the same title, so it is easy to avoid duplication.

Right now the wish list looks like this:

214  Stack tracing (#26)
204  Reflection API (#6)
136  vectorization (#10)
115  Multiple return values (tuples (#28)
105  Multiple opCast per class (#24)
98  Debug check for null reference (#52)
91  Native AMD64 codegen (#36)
82  !in (#44)
80  Short syntax for new (#18)
77  unit test after compilation (#1)
74  extra compiler values (#19)
69  Return-type overloading (#49)
59  Explicit out/inout (#38)
57  Foreach on first/on last (#42)
55  Unit test isolation  (#2)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike S | 1 Apr 2010 02:30

Re: Feature suggestion: in-place append to array

bearophile wrote:
> Mike S:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
> 
> It's a nice read. I don't see them switching to D soon. If you whisper them that D is based on a GC they will run
away screaming :-)
> 
> Bye,
> bearophile

Hah...well, there's a reason I'm still just looking into D rather than 
diving in headfirst! :p  Actually though, I do believe the needs of game 
programmers should be taken seriously while considering D's evolution: 
Right now, D hasn't completely found its niche, but it seems to position 
itself as a sane successor to C++ for systems-level programming.  As it 
stands, I believe there are only two major kinds of programmers who 
still use C++, and those are game programmers and masochists. ;)  Odds 
are, D won't be replacing C anytime soon for operating system kernels 
and such.  It's too low-level for scripting tasks, and most website 
designers and non-real-time applications programmers use higher-level 
languages already (C#, Python, PHP...shudder...etc.), and they're 
unlikely to go back.  I think D will eventually be used for writing 
other heavy-duty non-OS frameworks and software systems, but if it's 
really going to become the successor to C++, it's going to have to 
absorb most of C++'s user base...and that includes game programmers.

You're right that the garbage collector is a major issue - probably the 
biggest one inherent to the language design - but I haven't determined 
it's a dealbreaker, at least not yet.  After all, D also allows manual 
memory management, and freeing memory early apparently helps speed
(Continue reading)

Permalink | Reply | 7 comments |
headers
Bane | 1 Apr 2010 02:40
Picon

Re: Solution for Fatal flaw in D design which is holding back widespread

> I have tried that "Universal Indent GUI" with Uncrustify. It seems nice but it has so many options that
finding the correct ones is lot of work, even if you use that GUI:
> http://uncrustify.sourceforge.net/config.txt
> It seems unable to recognize foreach and foreach_reverse.
> 
> Bye,
> bearophile

In my case it breaks class indentation. I guess template syntax is a bit tricky for it too.
Permalink | Reply | 0 comments |
headers
bearophile | 1 Apr 2010 04:00
Picon

Re: Feature suggestion: in-place append to array

Mike S:

>the needs of game programmers should be taken seriously while considering D's evolution:<

The short D1 history shows that designers of small games are willing to use D. Some game designers seem
almost desperate to find an usable language simpler than C++. So I agree with you that D2 can be designed
keeping an eye at game designers too. But that's very demanding people, it's not easy to satisfy them even
with a mature language + compiler + std lib + dev tools. And currently nothing in D2 is mature. For them maybe
not even the most mature thing you can find in D world, the back-end of ldc (llvm), is mature enough :-)

>Right now, D hasn't completely found its niche, but it seems to position itself as a sane successor to C++
for systems-level programming.<

I am not able to tell the future. Some parts of D design are already old-style:
- Some early design decisions make hard to inline D virtual functions (so if you write D code in Java style,
you see a significant slow down compared to similar Java code running with HotSpot). So far no one seems to
care of this, we'll see if I am right to see a problem here;
- Some of D unsafe characteristics are worked on to improve their safety, but there's lot of road to travel
still, for example null-safety and integers-overflow-safety are far away still. People are trying to
explain Walter still why null-safety has some importance.
- D2 defaults to mutables. This can be acceptable, I don't know;
- Currently D2 is not designed from the start to work with an IDE (but I think this problem can be fixed with not
too much work);
- The built-in unit testing and documentation are not fit for professional usage (but the documentation is
easy to extend because they are just comments, so it's a smaller problem).
- etc.

A system language is something that you can use to write very small binaries, that can be used to write a
kernel like Linux, device drivers for a smaller computer+CPU, etc. Such things are hard to do in D2, I don't
see Linus using D2 to write his kernel, he even thinks C++ is unfit. So I see D2 more like a "low-level
(Continue reading)

Permalink | Reply | 6 comments |
headers
bearophile | 1 Apr 2010 04:59
Picon

<at> pinned classes

Thinking more about some of the things I've recently written to Mike S, I think the situation of the D GC can be
improved not teaching the D type system how to tell apart three types of pointers, but introducing the
 <at> pinned for classes:

 <at> pinned class Foo {}

Unpinned memory can be moved, allowing a generational moving GC, that's efficient.

All objects instantiated from a unpinned class are unpinned. This is a little limiting (you can think of
allowing both pinned and unpinned instances) but this keeps the situation simpler for the compiler and
the programmer.

With unpinned classed Java/C# programmers can program in D in a style similar to the one they are used too in
their languages. This is good.

Classes are unpinned on default (the opposite of the current situation) to maximize the amount of unpinned objects.

The  <at> pinned attribute can't be used with structs and enums, they are always pinned becasue Java
programmers don't use them, they are usually used for performance in a lower level way, and because they
don't have a virtual table pointer that the GC can use, etc.

Normal unpinned classes can't contain pointers to their fields or to unpinned memory, in a transitive way.
They can contain pointers to pinned memory.

In system (unsafe) modules you can of course cast a unpinned class referent to a pointer, but this is nearly,
because the GC can move the class in memory in any moment. It can be useful for a short time if you disable the GC.

Pinned classes act as now, they can contain pointers to their fields too.

The GC can move around unpinned objects and must keep in place the pineed ones, the GC has to modify the
(Continue reading)

Permalink | Reply | 12 comments |
headers
Mike S | 1 Apr 2010 05:38

Re: Feature suggestion: in-place append to array

bearophile wrote:
> The short D1 history shows that designers of small games are willing to use D. Some game designers seem
almost desperate to find an usable language simpler than C++. So I agree with you that D2 can be designed
keeping an eye at game designers too. But that's very demanding people, it's not easy to satisfy them even
with a mature language + compiler + std lib + dev tools. And currently nothing in D2 is mature. For them maybe
not even the most mature thing you can find in D world, the back-end of ldc (llvm), is mature enough :-)
> 
Yeah, you're right about the demanding tool and maturity requirements 
that game studios have, but assuming people continue working on D and 
other people adopt it and enhance the tools, those things will flesh out 
over time.  I'm young enough that I look forward to seeing it overtake 
C++ in the game world someday.

> 
> 
> I am not able to tell the future. Some parts of D design are already old-style:
> - Some early design decisions make hard to inline D virtual functions (so if you write D code in Java style,
you see a significant slow down compared to similar Java code running with HotSpot). So far no one seems to
care of this, we'll see if I am right to see a problem here;

Well, writing code Java-style is certainly no problem for game devs, 
considering they already minimize virtual function usage, at least in 
lower code layers. ;)

> <snip>
> 
> A system language is something that you can use to write very small binaries, that can be used to write a
kernel like Linux, device drivers for a smaller computer+CPU, etc. Such things are hard to do in D2, I don't
see Linus using D2 to write his kernel, he even thinks C++ is unfit. So I see D2 more like a "low-level
application language", on a level located somewhere between C and C#. It can also become a numerics
(Continue reading)

Permalink | Reply | 5 comments |
headers
Phil Deets | 1 Apr 2010 05:10
Picon

Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)

On Wed, 31 Mar 2010 11:49:31 -0600, Nick Sabalausky <a <at> a.a> wrote:

>
> Alhough it wouldn't necessarily even need to be a full-fledged source
> formatter. Just something to sanitize the whitespace between  
> start-of-line
> and anything non-whitespace would be a huge improvement *and* be
> cross-language.
>

Crimson Editor (my preferred D text editor) has menu options to convert  
tabs to spaces, convert leading tabs to spaces, convert spaces to tabs,  
and remove trailing spaces.
Permalink | Reply | 1 comment |
headers
Phil Deets | 1 Apr 2010 05:13
Picon

Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)

On Wed, 31 Mar 2010 21:10:22 -0600, Phil Deets <pjdeets2 <at> gmail.com> wrote:

> On Wed, 31 Mar 2010 11:49:31 -0600, Nick Sabalausky <a <at> a.a> wrote:
>
>>
>> Alhough it wouldn't necessarily even need to be a full-fledged source
>> formatter. Just something to sanitize the whitespace between  
>> start-of-line
>> and anything non-whitespace would be a huge improvement *and* be
>> cross-language.
>>
>
> Crimson Editor (my preferred D text editor) has menu options to convert  
> tabs to spaces, convert leading tabs to spaces, convert spaces to tabs,  
> and remove trailing spaces.

Correction: It has leading spaces to tabs, not leading tabs to spaces.
Permalink | Reply | 0 comments |
headers
Justin Spahr-Summers | 1 Apr 2010 06:21
Picon

Re: <at> pinned classes

On Wed, 31 Mar 2010 22:59:08 -0400, bearophile 
<bearophileHUGS <at> lycos.com> wrote:
> 
> Thinking more about some of the things I've recently written to Mike S, I think the situation of the D GC can
be improved not teaching the D type system how to tell apart three types of pointers, but introducing the
 <at> pinned for classes:
> 
>  <at> pinned class Foo {}
> 
> Unpinned memory can be moved, allowing a generational moving GC, that's efficient.
> 
> All objects instantiated from a unpinned class are unpinned. This is a little limiting (you can think of
allowing both pinned and unpinned instances) but this keeps the situation simpler for the compiler and
the programmer.
> 
> With unpinned classed Java/C# programmers can program in D in a style similar to the one they are used too in
their languages. This is good.
> 
> Classes are unpinned on default (the opposite of the current situation) to maximize the amount of
unpinned objects.
> 
> The  <at> pinned attribute can't be used with structs and enums, they are always pinned becasue Java
programmers don't use them, they are usually used for performance in a lower level way, and because they
don't have a virtual table pointer that the GC can use, etc.
> 
> Normal unpinned classes can't contain pointers to their fields or to unpinned memory, in a transitive
way. They can contain pointers to pinned memory.
> 
> In system (unsafe) modules you can of course cast a unpinned class referent to a pointer, but this is
nearly, because the GC can move the class in memory in any moment. It can be useful for a short time if you
(Continue reading)

Permalink | Reply | 10 comments |

Gmane