View mode: basic / threaded / horizontal-split · Log in · Help
September 11, 2004
Re: Most important issues for D (MIID)
In article <cht9gl$20m8$1@digitaldaemon.com>, Walter says...
>So I'd like to kick off this thread as an opportunity for all to post their
>two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
>mean pragmatic things like:
>
>1) compiler bugs
>2) language shortcomings with no reasonable workarounds
>3) issues that are fundamentally blocking projects from using or proceeding
>with D
>4) severe library faults

Walter: My top two are as follows:

1) Please solve both the parameter passing and string concatenation
(~) problems when using string literals, plus the handling of parameter 
implicit conversion of char[], wchar[], and dchar[] to functions'
problems.

# int main()
# {
#     char[]  sDynStr   = "";
#     wchar[] wsDynStr  = "";
#     wchar[] wsDynStr2 = "";
#     dchar[] dsDynStr  = "";
#
#     // This works
#     sDynStr   = "Initializing to 8-Bit";
#     wsDynStr  = "Initializing to 16-Bit";
#     wsDynStr2 = "Initializing to 16-Bit";
#     dsDynStr  = "Initializing to 32-bit";
#
#     // This always works
#     sDynStr  = "This is" ~ " a test!";
#
#     /+
#      ' But when I use the ~ operator it forces 
#      ' the 2nd literal string to a char[]
#      ' thus causing the "cannot implicitly convert 
#      ' expression "This is a test!" 
#      ' of type char[15] to wchar[]" error.
#      '
#      +/
#     wsDynStr = "This is" ~ " a test!";
#     dsDynStr = "This is" ~ " a test!";
#
#     // This works - forced to cast() each literal string 
#     wsDynStr = cast(wchar[])"This is" ~ cast(wchar[])" a test!";
#     dsDynStr = cast(dchar[])"This is" ~ cast(dchar[])" a test!";
#
#     // This works -  - forced to cast() a literal string with (x)s
#     wsDynStr = cast(wchar[])( "This is" ~ " a test!" );
#     dsDynStr = cast(dchar[])( "This is" ~ " a test!" );
#
#     return 0;
#
# } // end int main() 

2) Stronger support for DLLs.
----------------------------------------
Here's a part of Matthew's post that touchs on the subject at:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/9166

<partial content>
I see four issues with DLLs and D. I'm interested to hear whether I've missed
any and, especially, what ideas people have for solving these issues in a
"Spirit of D" way (i.e. without all the clodhopping nonsense that is the
Java/.NET infrastructure):

1. Sharing/managing GC - I think this is the most important in the short/medium
term 

2. Being able to talk _classes_ not just _interfaces_ between link units. We can
get a long way with interfaces, methinks, once GC sharing is handled, but still
it'd be nice to work with classes as well, if simply achievable.

3. Versioning, i.e. avoiding DLL Hell

4. Security. Is there something simple and efficient that nonetheless addresses
those handled by the heaving leviathan that is .NET?

Ancilary issues:

1. Serialisation as a part of the language??
</partial content>

Walter, thanks for asking! ;)

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
September 11, 2004
Re: Most important issues for D (MIID)
Walter wrote:

> So I'd like to kick off this thread as an opportunity for all to post
> their two Most Important Issues for D with respect to getting 1.0 done. By
> MIID, I mean pragmatic things like:
> 
> 1) compiler bugs
> 2) language shortcomings with no reasonable workarounds
> 3) issues that are fundamentally blocking projects from using or
> proceeding with D
> 4) severe library faults

A bugzilla (web bug tracking system) would be more apt for this task than a
forum thread, wasn't one about to be set up at dsource?

Walter, the (php) MantisBT can be configured in no more than 20 minutes!
(it's what we're using at work and works really well.):

http://www.mantisbt.org/

The CVS version also allow for voting (sponsorship) of bugs.
September 11, 2004
Re: Most important issues for D (MIID)
1. Put "D language and compiler" in maintainance mode ASAP.
2. Improve Phobos. Phobos right now looks like some 
bunch of crap put together.

- Sai
September 11, 2004
Re: Most important issues for D (MIID)
"Lynn Allan" <l_d_allan@adelphia.net> wrote in message
news:chuk7d$2mrs$1@digitaldaemon.com...
> <alert comment="newbie">
>
> Reasonably stable and mature "official" gui library with enough widgets to
> put simple non-console apps together (may or may not be all that portable)

A gui library will probably be a good idea around version 2.0 or 3.0. A 1.0
language and core library is probably going to be too early to use to build
complex apps or libraries. Look at AWT and how now Java Swing has various
warts because of backwards compatibility with it.

> Reasonably stable and mature ide with symbolic debugger and step-into and
> step-over. If already available, documentation for it.

ah, yeah. that would be very helpful.

>
> </alert>
>
>
September 11, 2004
Re: Most important issues for D (MIID)
Change 0 to 1 in line 58 of parse.c :)
Reference return types would be great :)

You are doing a great job with D, and the above is just one of those
wishes everyone has, but i would like this to be possible:

1)

class A
{
   this(){/*...*/}
   template constr(T)
   {
       this(T x){/*...*/}
   }

   mixin constr!(int);
   mixin constr!(float);
}

This code looks exelent but to turn on name overloading between the default
constructor and the mixed ones, i would have to alias it. But how?

mixin constr!(int) somename;
alias somename.this this; //doesn't work

Someone mentioned something about combining mixin and alias
into one thing like: mixin constr!(int) as this; or something like that,
but i would be prefectlly happy with anything that did the job.

2)
a more usefull Phobos but this can wait, but it can wait until while
you are making a compiler and the language better.



"Walter" <newshound@digitalmars.com> wrote in message
news:cht9gl$20m8$1@digitaldaemon.com...
> In some delightful ways, D is a victim of its own success. There's a lot
of
> traffic in the D newsgroups, sometimes getting to 100 messages per day.
Not
> a day goes by without new proposals for features. It's simply beyond my
> capacity to give these all the attention they deserve, or even to read
them
> all. I probably spend a minimum of 2 hours a day reading messages, and I
> could easilly spend 12 hours a day at it, and accomplish nothing else.
>
> Hence, I inadvertently overlook important issues. I know that this has
been
> frustrating to some people, and I apologize for it.
>
> So I'd like to kick off this thread as an opportunity for all to post
their
> two Most Important Issues for D with respect to getting 1.0 done. By MIID,
I
> mean pragmatic things like:
>
> 1) compiler bugs
> 2) language shortcomings with no reasonable workarounds
> 3) issues that are fundamentally blocking projects from using or
proceeding
> with D
> 4) severe library faults
>
> I don't mean things like:
>
> 1) D 2.0 issues
> 2) feature proposals like "It would be nice if ..."
> 3) minor irritants
> 4) philosophical issues
> 5) issues that have been beaten to death already <g>
>
> If a thread here exists for the topic, a reference to that thread would be
> nice rather than reproducing it.
>
> It's time to prioritize and get us on a rational, sensible path for
> releasing 1.0.
>
>
September 11, 2004
Re: Most important issues for D (MIID)
On Fri, 10 Sep 2004 15:18:03 -0700, Walter wrote:

> So I'd like to kick off this thread as an opportunity for all to post their
> two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
> mean pragmatic things like:
> 
> 1) compiler bugs
> 2) language shortcomings with no reasonable workarounds

I'm not sure if this is a shortcoming, or just a feature request, but I'll
mention it again: D's unit test facility is not usable for test driven
development (because it's unnecessarily difficult to run a subset of
tests) or for automated builds (because a single failure will halt
execution of the test suite). I don't classify this as a showstopper bug,
but I think it's at the very next level. To use D at my company, we would
have to completely drop a significant language feature in favor of a
library, because D doesn't work the way we do.

I have posted thoughts on the wiki about this, with a link to my original
proposal. Even if that feature proposal is not a good solution, I believe
it covers the problems well.

Mike Swieton
__
Following the light of the sun, we left the Old World.
	- Inscribed on Columbus' caravels
September 11, 2004
Re: Most important issues for D (MIID)
"Walter" <newshound@digitalmars.com> wrote in message
news:cht9gl$20m8$1@digitaldaemon.com...
> Hence, I inadvertently overlook important issues. I know that
> this has been frustrating to some people, and I apologize for it.

> So I'd like to kick off this thread as an opportunity for all to post
their
> two Most Important Issues for D with respect to getting 1.0 done.

<alert comment="newbie">

Thanks for asking!

I've been impressed by how well the development model based on a "benevolent
czar with inner sanctum meritocracy" is working with "D".

</alert>
September 11, 2004
Re: Most important issues for D (MIID)
"Ben Hinkle" <bhinkle@mathworks.com> wrote in message
news:chvkmg$2u6$1@digitaldaemon.com...
>
> "Lynn Allan" <l_d_allan@adelphia.net> wrote in message
> news:chuk7d$2mrs$1@digitaldaemon.com...
> > <alert comment="newbie">
> >
> > Reasonably stable and mature "official" gui library with enough widgets
to
> > put simple non-console apps together (may or may not be all that
portable)
>
> A gui library will probably be a good idea around version 2.0 or 3.0. A
1.0
> language and core library is probably going to be too early to use to
build
> complex apps or libraries. Look at AWT and how now Java Swing has various
> warts because of backwards compatibility with it.
>
> > Reasonably stable and mature ide with symbolic debugger and step-into
and
> > step-over. If already available, documentation for it.
>
> ah, yeah. that would be very helpful.
>
> >
> > </alert>

I hesitated to submit the 2 MIID that I did. Clearly they were at least
somewhat outside what "The WB" was asking. And I appreciate your patient,
gentle reply to this newbie.

However ...

I would speculate that any relatively general purpose language will have an
"uphill battle" for acceptance and "critical mass" if gui apps are difficult
to accomplish. Is there really a need for yet another language for embedded
and console apps? I used AWT for a relatively simple freeware app and found
it acceptable. If a gui library equivalent to AWT was available for "D", I
would now be deciding whether to commence development on a freeware app now
in the planning stage, or porting two existing freeware apps to "D".

Similarly, a development tool with a decent debugger is much easier to learn
and use. I probably overuse debuggers, but the ability to step-into code and
directly see what is going on with an object probably facilitates my
"getting up to speed" with a new language by an order of magnitude.
September 11, 2004
Re: Most important issues for D (MIID)
In article <chvtiv$75r$1@digitaldaemon.com>, Lynn Allan says...
>
>I would speculate that any relatively general purpose language will have an
>"uphill battle" for acceptance and "critical mass" if gui apps are difficult
>to accomplish. Is there really a need for yet another language for embedded
>and console apps?

There are very few standalone languages that have shipped with GUI support.  In
fact Java is just about the only one I can think of.  And Java totally scapped
their GUI api and started over around version 1.4.

As for the need for a new system language, I think we do or I wouldn't be here.
C++ is an incredibly powerful but I can't help but feel it could be better if it
weren't stuck with all sorts of legacy issues.  D offers a chance to start fresh
and so far I think Walter has done a tremendous job with the design.  If you
want more out of D you're certainly welcome to make it whatever you want.  There
are plenty of library features I'd like to see, but the groundwork has to be
laid first--language issues, core library support (garbage collection,
exceptions, threading)--before that level of work can really begin.

>Similarly, a development tool with a decent debugger is much easier to learn
>and use. I probably overuse debuggers, but the ability to step-into code and
>directly see what is going on with an object probably facilitates my
>"getting up to speed" with a new language by an order of magnitude.

Agreed.  I think Eclipse may be D's best shot at a native IDE, but I haven't
been able to get the D plugin working yet (though I hope to find more time to
play with it in the next week or so).  Again, this is something that the
community could provide, as it isn't really necessary to get the compiler
finished and such.


Sean
September 11, 2004
Re: Most important issues for D (MIID)
Lynn Allan wrote:
> I hesitated to submit the 2 MIID that I did. Clearly they were at least
> somewhat outside what "The WB" was asking. And I appreciate your patient,
> gentle reply to this newbie.
> 
> However ...
> 
> I would speculate that any relatively general purpose language will have an
> "uphill battle" for acceptance and "critical mass" if gui apps are difficult
> to accomplish. Is there really a need for yet another language for embedded
> and console apps? I used AWT for a relatively simple freeware app and found
> it acceptable. If a gui library equivalent to AWT was available for "D", I
> would now be deciding whether to commence development on a freeware app now
> in the planning stage, or porting two existing freeware apps to "D".
> 
> Similarly, a development tool with a decent debugger is much easier to learn
> and use. I probably overuse debuggers, but the ability to step-into code and
> directly see what is going on with an object probably facilitates my
> "getting up to speed" with a new language by an order of magnitude.

The thing is, neither of these issues are in Walter's hands. :)

Walter is the only one who can make improvements to the compiler itself, 
so it stands to reason that it be his primary focus.  The auxiliary code 
monkeys (that's us!) can handle most everything else.

 -- andy
1 2 3 4 5 6
Top | Discussion index | About this forum | D home