www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - I wish I could use D for everything

reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:

returns an Enumerator for a Dictionary that enumerates only the values.

The sole purpose of this enum is so I can have something reasonable when  
iterating through the values in a dictionary instead of:

foreach(KeyValuePair<KeyType, ValueType> kvp in myDictionary)
{
   ValueType vt = kvp.Value;
   ...
}


encapsulate everything in a class, so my code looks like this:

foreach(ValueType vt in DictionaryValueEnum.enumerate(myDictionary))
{
   ...
}

Oh, how nice it would be to avoid all that crap and just type:

foreach(vt; myDictionary)
{
   ...
}

And I just typed about the 5 billionth time:

if(ReferenceEquals(myObj, blah))

Written in D would be:

if(myObj is blah)

I can't wait for D to take over the world, so I no longer have to write in  
this horrid language ;)

-Steve
Apr 29 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Steven,


 The sole purpose of this enum is so I can have something reasonable
 when  iterating through the values in a dictionary instead of:
 
 foreach(KeyValuePair<KeyType, ValueType> kvp in myDictionary)


IIRC this works

foreach(ValueType v in myDictionary.Values)

but I can't check that right now

OTOH, Yah, I'd love to have D as my dev language, but I'd need the tool chain
Apr 29 2009
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 29 Apr 2009 23:01:17 -0400, BCS <none anon.com> wrote:


 Hello Steven,


 The sole purpose of this enum is so I can have something reasonable
 when  iterating through the values in a dictionary instead of:
  foreach(KeyValuePair<KeyType, ValueType> kvp in myDictionary)


 IIRC this works

 foreach(ValueType v in myDictionary.Values)


Whaddya know, you are correct :)

http://msdn.microsoft.com/en-us/library/0yxt5h4s.aspx

Thanks, that makes life slightly easier, at least I don't have to have  
some stupid wrapper enumerator.

-Steve
Apr 29 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 OTOH, Yah, I'd love to have D as my dev language, but I'd need the tool 



Check out Cristi's alpha version of D.net!
Apr 29 2009
parent reply BCS <ao pathlink.com> writes:
Reply to Walter,


 BCS wrote:
 

 OTOH, Yah, I'd love to have D as my dev language, but I'd need the

 


 Check out Cristi's alpha version of D.net!
 


I don't care a wit what it runs on. If anything I prefer not running on the 
CLR. It's the tools that are the hangup.
Apr 30 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 Reply to Walter,
 

 BCS wrote:


 OTOH, Yah, I'd love to have D as my dev language, but I'd need the



 Check out Cristi's alpha version of D.net!


 
 I don't care a wit what it runs on. If anything I prefer not running on 
 the CLR. It's the tools that are the hangup.
 
 


True, but the D.net compiler works with the .net tools and ecosystem.
Apr 30 2009
parent reply BCS <none anon.com> writes:
Hello Walter,


 BCS wrote:
 

 Reply to Walter,
 

 BCS wrote:
 

 OTOH, Yah, I'd love to have D as my dev language, but I'd need the

 


 Check out Cristi's alpha version of D.net!
 


 I don't care a wit what it runs on. If anything I prefer not running
 on the CLR. It's the tools that are the hangup.
 


 True, but the D.net compiler works with the .net tools and ecosystem.
 


auto compleat, syntax highlighting, jump to definition, re factoring, etc. ?
Apr 30 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 auto compleat, syntax highlighting, jump to definition, re factoring, 
 etc. ?



Ask Cristi for a more definitive answer.
Apr 30 2009
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
So, really, all you want is a Visual Studio Language Service.

Jump to definition and syntax highlighting are relatively easy. 
Refactoring is a bit more complex, and autocomplete is probably the most 
complicated (to get right.)

It's really not impossible to write your own language service, and I 
know there have been a couple attempts (I've even done some, but only 
syntax really.)

-[Unknown]


BCS wrote:

 Hello Walter,
 

 BCS wrote:


 Reply to Walter,


 BCS wrote:


 OTOH, Yah, I'd love to have D as my dev language, but I'd need the



 Check out Cristi's alpha version of D.net!


 I don't care a wit what it runs on. If anything I prefer not running
 on the CLR. It's the tools that are the hangup.


 True, but the D.net compiler works with the .net tools and ecosystem.


 
 auto compleat, syntax highlighting, jump to definition, re factoring, 
 etc. ?
Apr 30 2009
parent BCS <none anon.com> writes:
Hello Unknown,


 So, really, all you want is a Visual Studio Language Service.
 
 Jump to definition and syntax highlighting are relatively easy.
 Refactoring is a bit more complex, and autocomplete is probably the
 most complicated (to get right.)
 


Yah, I just want the hard stuff. (go figure :-)
May 02 2009
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
I'm lucky, I'm a technical lead/manager at work, so I get to say "for 
this project, we're using D."  And then it happens.  Muhahaha.  We're a 
small shop but I enjoy my small amount of power.

Soon it will happen, just have to lay in the ground work.  I know other 
managers at my company have no problem with it, as long as we can find 
other people who know the language it's less expensive to use D.  That's 
really the most important thing.

-[Unknown]


Steven Schveighoffer wrote:


 returns an Enumerator for a Dictionary that enumerates only the values.
 
 The sole purpose of this enum is so I can have something reasonable when 
 iterating through the values in a dictionary instead of:
 
 foreach(KeyValuePair<KeyType, ValueType> kvp in myDictionary)
 {
   ValueType vt = kvp.Value;
   ...
 }
 

 encapsulate everything in a class, so my code looks like this:
 
 foreach(ValueType vt in DictionaryValueEnum.enumerate(myDictionary))
 {
   ...
 }
 
 Oh, how nice it would be to avoid all that crap and just type:
 
 foreach(vt; myDictionary)
 {
   ...
 }
 
 And I just typed about the 5 billionth time:
 
 if(ReferenceEquals(myObj, blah))
 
 Written in D would be:
 
 if(myObj is blah)
 
 I can't wait for D to take over the world, so I no longer have to write 
 in this horrid language ;)
 
 -Steve
Apr 29 2009
next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 30 Apr 2009 05:04:43 +0200, Unknown W. Brackets
<unknown simplemachines.org> wrote:


 I'm lucky, I'm a technical lead/manager at work, so I get to say "for  
 this project, we're using D."  And then it happens.  Muhahaha.  We're a  
 small shop but I enjoy my small amount of power.

 Soon it will happen, just have to lay in the ground work.  I know other  
 managers at my company have no problem with it, as long as we can find  
 other people who know the language it's less expensive to use D.  That's  
 really the most important thing.

 -[Unknown]


Lucky bastard. :p

--
 Simen
Apr 29 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Unknown W. Brackets wrote:

 I know other 
 managers at my company have no problem with it, as long as we can find 
 other people who know the language it's less expensive to use D.  That's 
 really the most important thing.


You nailed the bottom line - total cost of a project.

D aims to reduce project costs by reducing training time and shortening 
development time.
Apr 29 2009
next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Yep.  D does a good job of that.

One project we ended up walking away having completed the project in 
1/5th the estimated hours (we use a blended rate, so in the end, hours 
are all we care about) that was partially in D.

It just takes people realizing this.  And, some libraries will come from 
that - once someone realizes that it can take less time throughout, it's 
not hard to invest some upfront time.  Especially during slow seasons. 
It just has to get over the toppling point.

-[Unknown]


Walter Bright wrote:

 Unknown W. Brackets wrote:

 I know other managers at my company have no problem with it, as long 
 as we can find other people who know the language it's less expensive 
 to use D.  That's really the most important thing.


 
 You nailed the bottom line - total cost of a project.
 
 D aims to reduce project costs by reducing training time and shortening 
 development time.
Apr 29 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

D aims to reduce project costs by reducing training time and shortening
development time.<


I agree that this is very important. Helping the programmer avoid bugs and
helping her to follow good design practices are among the most important
qualities of a programming language, because in practical programming often
most time (= money) is spent debugging programs and updating them.

But you are comparing D with C++, because programming in D1 is faster and often
simpler than doing the same in C++.


developing time even more than D1.
D1 is almost a system language, so it's not easy to compete with the
productivity of application languages designed to put the programmer first and
the CPU second.

And D2 is not an easy&simple language, you need a good amount of time to
learn/teach it, more than Java for example.

Bye,
bearophile
Apr 30 2009
next sibling parent Steve Teale <steve.teale britseyeview.com> writes:
bearophile Wrote:


 Walter Bright:

D aims to reduce project costs by reducing training time and shortening
development time.<


 
 I agree that this is very important. Helping the programmer avoid bugs and
helping her to follow good design practices are among the most important
qualities of a programming language, because in practical programming often
most time (= money) is spent debugging programs and updating them.
 
 But you are comparing D with C++, because programming in D1 is faster and
often simpler than doing the same in C++.
 

developing time even more than D1.
 D1 is almost a system language, so it's not easy to compete with the
productivity of application languages designed to put the programmer first and
the CPU second.
 
 And D2 is not an easy&simple language, you need a good amount of time to
learn/teach it, more than Java for example.
 
 Bye,
 bearophile



because of the wonderful documentation.

But I can still go faster in D just flying by the seat of my pants!
Apr 30 2009
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
bearophile wrote:


developing time even more than D1.
 D1 is almost a system language, so it's not easy to compete with the
productivity of application languages designed to put the programmer first and
the CPU second.


Eh.... I'm working on my current project in D because I find development 

projects. The metaprogramming features, in particular, are nice. I used 

runtime config files for stuff that really should have been 
compile-time. With CTFE+mixins, this is a non-issue. The fact that D is 
a "systems language" wasn't a factor in my decision at all.
Apr 30 2009
parent Daniel de Kok <me danieldk.org> writes:
On Fri, May 1, 2009 at 12:56 AM, Robert Fraser
<fraserofthenight gmail.com> wrote:

 bearophile wrote:


 shorten developing time even more than D1.
 D1 is almost a system language, so it's not easy to compete with the
 productivity of application languages designed to put the programmer first
 and the CPU second.


 Eh.... I'm working on my current project in D because I find development



The primary thing that is holding me from using D more is the lack of
up-to-date x86_64 D2 compiler. We often work with large data sets, so
a virtual address space of 4GB is too small.

Other than that it seems very useful for many NLP tasks: nearly as
fast as C++, but much quicker to write.

Take care,
Daniel
May 05 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 Walter Bright:

 D aims to reduce project costs by reducing training time and
 shortening development time.<


 
 I agree that this is very important. Helping the programmer avoid
 bugs and helping her to follow good design practices are among the
 most important qualities of a programming language, because in
 practical programming often most time (= money) is spent debugging
 programs and updating them.
 
 But you are comparing D with C++, because programming in D1 is faster
 and often simpler than doing the same in C++.
 

 shorten developing time even more than D1. D1 is almost a system
 language, so it's not easy to compete with the productivity of
 application languages designed to put the programmer first and the
 CPU second.


I've tried to program in Java. It takes me considerably more time to get 
things done in it. That time is lost writing much more code because it 
is a less expressive language.

The other problem those "CPU second" languages have is that people often 
use them in a hybrid manner - Python for the logic, with C++ to speed up 
the slow parts. Doing that is a sign of desperation, as neither language 
is fulfilling the needs of the programmer.



 And D2 is not an easy&simple language, you need a good amount of time
 to learn/teach it, more than Java for example.


Being a simple language does not imply being a productive language. 
Heck, 6800 assembly is very simple (about 40 instructions), but it takes 
a lot of work to get simple programs correctly coded.

Pascal is another language that can be mastered in a few hours, yet is 
very unproductive because it's hard to get anything done in it.
Apr 30 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
This is a post of mostly chat. If you have better things to do you can ignore
it.

Walter Bright:

 I've tried to program in Java. It takes me considerably more time to get 
 things done in it. That time is lost writing much more code because it 
 is a less expressive language.


I agree that D is more expressive than Java, my D programs are quite shorter
than Java ones, and I need less time to write D1 programs (especially when I
use my dlibs).

But expressiveness isn't the only factor to consider if you want to measure a
programmer productivity, you have to consider debugging time too: one of the

classes of errors, this leads to less memory-related bugs, and this leads to a
shorter total (development+debug) time.

The purpose of SafeD is to help in this regard, to gain another of the


I have seen that when I write a small Java program, when it compiles it's often
correct. This is less often true compared to D1 programs (and they say it's
more quite often true in Haskell). D1 compiler tries to be partially compatible
with C and this makes it "more tolerating" than the Java compiler. Several
examples can be shown.



 The other problem those "CPU second" languages have is that people often 
 use them in a hybrid manner - Python for the logic, with C++ to speed up 
 the slow parts. Doing that is a sign of desperation, as neither language 
 is fulfilling the needs of the programmer.


I agree. I have started learning D for the limits of C and Python.

tries to be an example of such hybrid languages.



Being a simple language does not imply being a productive language.<


I agree, but you have said:

D aims to reduce project costs by reducing training time<<




D doesn't reduce training time compared to Java because I think you need more
time to learn D compared to learning Java, because Java is simpler (and at the
university they teach Java, so you are likely to find/hire a person that
already knows Java, but this is partially beside the point).

Bye,
bearophile
Apr 30 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 D doesn't reduce training time compared to Java because I think you
 need more time to learn D compared to learning Java, because Java is
 simpler (and at the university they teach Java, so you are likely to
 find/hire a person that already knows Java, but this is partially
 beside the point).


I agree that Java is easier to learn than D. But that's all lost when 
you have to write a lot more code to get things done because Java lacks 
power.

It takes 10 years, however, to learn C++ and it still takes longer to 
write C++ solutions than D solutions.
Apr 30 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 bearophile wrote:

 D doesn't reduce training time compared to Java because I think you
 need more time to learn D compared to learning Java, because Java is
 simpler (and at the university they teach Java, so you are likely to
 find/hire a person that already knows Java, but this is partially
 beside the point).


 I agree that Java is easier to learn than D. But that's all lost when
 you have to write a lot more code to get things done because Java lacks
 power.
 It takes 10 years, however, to learn C++ and it still takes longer to
 write C++ solutions than D solutions.


To me a fair assessment of whether a complex feature belongs in a language is
the
following:

Given the target audience, will the average person save more time by using the
new
feature than he/she spends learning it?

The assumption here is that you will have to learn most or all of the features
of
your language of choice, because you will have to understand other people's
code.
 D2 is a complex language, but it's not complex in a haphazard way.  It's
complex
because it statically proves stuff about your code (const, etc), and allows
extremely powerful, generic user-defined types.  These are the kinds of things
that most people only dream about.
Apr 30 2009
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
dsimcha wrote:

  D2 is a complex language, but it's not complex in a haphazard way.  It's
complex
 because it statically proves stuff about your code (const, etc), and allows
 extremely powerful, generic user-defined types.  These are the kinds of things
 that most people only dream about.


I'd like to drill into this 'd2 is a complex language' assertion more.  Can we
build a factual list of the delta of complexity between d1 and d2?

The primary area is the type system:
  1) introduction of const
      -- optional and doesn't affect callers of api's that declare const params
  2) introduction of immutable
      -- less optional since it's not as coercable, but also less frequently
used in apis.
  3) introduction of pure
      -- optional, will not affect callers of apis
  4) introduction of nothrow
      -- optional, will not affect callers of apis

Others:
5) template if clause


I'm specifically leaving out Phobos and other library layer issues, though feel
free to count the runtime as part of the language when adding to this list.

-- Brad
Apr 30 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Brad Roberts (braddr puremagic.com)'s article

 dsimcha wrote:

  D2 is a complex language, but it's not complex in a haphazard way.  It's
complex
 because it statically proves stuff about your code (const, etc), and allows
 extremely powerful, generic user-defined types.  These are the kinds of things
 that most people only dream about.


 I'd like to drill into this 'd2 is a complex language' assertion more.  Can we
 build a factual list of the delta of complexity between d1 and d2?
 The primary area is the type system:
   1) introduction of const
       -- optional and doesn't affect callers of api's that declare const params
   2) introduction of immutable
       -- less optional since it's not as coercable, but also less frequently
 used in apis.
   3) introduction of pure
       -- optional, will not affect callers of apis
   4) introduction of nothrow
       -- optional, will not affect callers of apis
 Others:
 5) template if clause
 I'm specifically leaving out Phobos and other library layer issues, though feel
 free to count the runtime as part of the language when adding to this list.
 -- Brad


Template alias parameters, ref returns, shared (even though it's not
implemented,
it's on its way, so it still counts), closures, alias this, template literals,
struct ctors and dtors (and in general structs becoming more like classes) to
name
a few.  I love all of these, and I personally think the complexity is justified.
It's just that I don't know how easy it would be to convince someone coming from
Java of this, so I'm playing devil's advocate a little.

On the other hand, I do see a pattern here:  Most of these features are things
you
only need to care about if you're writing near the tip of the pyramid, stuff
like
generic, reusable code.  In fact, I've realized that my mindset when coding in D
is completely different when working on something that aims to be extremely
generic (like rangeextra or dstats, stuff I wouldn't even be able to do in any
language besides D) vs. when working on day-to-day code that just has to solve
one
problem well.  The latter is a lot easier, but also a lot less fun, from a
programming perspective.
Apr 30 2009
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
dsimcha wrote:

 == Quote from Brad Roberts (braddr puremagic.com)'s article

 dsimcha wrote:

  D2 is a complex language, but it's not complex in a haphazard way.  It's
complex
 because it statically proves stuff about your code (const, etc), and allows
 extremely powerful, generic user-defined types.  These are the kinds of things
 that most people only dream about.


 I'd like to drill into this 'd2 is a complex language' assertion more.  Can we
 build a factual list of the delta of complexity between d1 and d2?
 The primary area is the type system:
   1) introduction of const
       -- optional and doesn't affect callers of api's that declare const params
   2) introduction of immutable
       -- less optional since it's not as coercable, but also less frequently
 used in apis.
   3) introduction of pure
       -- optional, will not affect callers of apis
   4) introduction of nothrow
       -- optional, will not affect callers of apis
 Others:
 5) template if clause
 I'm specifically leaving out Phobos and other library layer issues, though feel
 free to count the runtime as part of the language when adding to this list.
 -- Brad


 
 Template alias parameters, ref returns, shared (even though it's not
implemented,
 it's on its way, so it still counts), closures, alias this, template literals,
 struct ctors and dtors (and in general structs becoming more like classes) to
name
 a few.  I love all of these, and I personally think the complexity is
justified.
 It's just that I don't know how easy it would be to convince someone coming
from
 Java of this, so I'm playing devil's advocate a little.
 
 On the other hand, I do see a pattern here:  Most of these features are things
you
 only need to care about if you're writing near the tip of the pyramid, stuff
like
 generic, reusable code.  In fact, I've realized that my mindset when coding in
D
 is completely different when working on something that aims to be extremely
 generic (like rangeextra or dstats, stuff I wouldn't even be able to do in any
 language besides D) vs. when working on day-to-day code that just has to solve
one
 problem well.  The latter is a lot easier, but also a lot less fun, from a
 programming perspective.


I'm going to play devils advocate too...

struct ctor/dtor's are simplifiers.  They remove a hard to explain difference
and aren't even a little bit hard to understand.

I'm tempted to say the same about ref return, but we can leave it in the adds
column.

The rest I'll agree with (at least enough not to quibble much).


-- Brad
Apr 30 2009
next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Thu, 30 Apr 2009 21:20:17 -0700, Brad Roberts wrote:


 dsimcha wrote:

 == Quote from Brad Roberts (braddr puremagic.com)'s article

 dsimcha wrote:

  D2 is a complex language, but it's not complex in a haphazard way. 
  It's complex
 because it statically proves stuff about your code (const, etc), and
 allows extremely powerful, generic user-defined types.  These are the
 kinds of things that most people only dream about.


 I'd like to drill into this 'd2 is a complex language' assertion more.
  Can we build a factual list of the delta of complexity between d1 and
 d2? The primary area is the type system:
   1) introduction of const
       -- optional and doesn't affect callers of api's that declare
       const params
   2) introduction of immutable
       -- less optional since it's not as coercable, but also less
       frequently
 used in apis.
   3) introduction of pure
       -- optional, will not affect callers of apis
   4) introduction of nothrow
       -- optional, will not affect callers of apis
 Others:
 5) template if clause
 I'm specifically leaving out Phobos and other library layer issues,
 though feel free to count the runtime as part of the language when
 adding to this list. -- Brad


 
 Template alias parameters, ref returns, shared (even though it's not
 implemented, it's on its way, so it still counts), closures, alias
 this, template literals, struct ctors and dtors (and in general structs
 becoming more like classes) to name a few.  I love all of these, and I
 personally think the complexity is justified. It's just that I don't
 know how easy it would be to convince someone coming from Java of this,
 so I'm playing devil's advocate a little.
 
 On the other hand, I do see a pattern here:  Most of these features are
 things you only need to care about if you're writing near the tip of
 the pyramid, stuff like generic, reusable code.  In fact, I've realized
 that my mindset when coding in D is completely different when working
 on something that aims to be extremely generic (like rangeextra or
 dstats, stuff I wouldn't even be able to do in any language besides D)
 vs. when working on day-to-day code that just has to solve one problem
 well.  The latter is a lot easier, but also a lot less fun, from a
 programming perspective.


 
 I'm going to play devils advocate too...
 
 struct ctor/dtor's are simplifiers.  They remove a hard to explain
 difference and aren't even a little bit hard to understand.
 
 I'm tempted to say the same about ref return, but we can leave it in the
 adds column.
 
 The rest I'll agree with (at least enough not to quibble much).
 
 
 -- Brad


I thought this stuff was good enough to deserve its own wiki page: http://
www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/D2Complexities
Apr 30 2009
prev sibling parent Benji Smith <dlanguage benjismith.net> writes:
Brad Roberts wrote:

 I'm going to play devils advocate too...
 
 struct ctor/dtor's are simplifiers.  They remove a hard to explain difference
 and aren't even a little bit hard to understand.


Ideally, that would be true.

But there are some wonky rules abound struct ctors, static opCall, and 
struct literals that I can never quite remember.

--benji
May 02 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:

 On the other hand, I do see a pattern here:  Most of these features are things
you
 only need to care about if you're writing near the tip of the pyramid, stuff
like
 generic, reusable code.  In fact, I've realized that my mindset when coding in
D
 is completely different when working on something that aims to be extremely
 generic (like rangeextra or dstats, stuff I wouldn't even be able to do in any
 language besides D) vs. when working on day-to-day code that just has to solve
one
 problem well.  The latter is a lot easier, but also a lot less fun, from a
 programming perspective.


Andrei and I have talked about this a bit. He points out how Unix 
programming revolves around the notion of a file, and how the Unix 
utilities all plug into each other like building blocks to create 
powerful programs.

With D generic programming, the idea is to enable the creation of such 
snap-in components. Andrei has made a huge step forward with the range 
based library and the set of algorithms to go with them. Many of the 
seemingly arbitrary new language features of D2 are necessary to support 
this style of programming.

OOP and STL were also attempts at such snap-in component programming, 
and they both were modestly successful. We aim to take it considerably 
farther with ranges.

(One of the nice things about Phobos ranges is Andrei has taken a 
no-compromise approach with regard to performance. There's not going to 
be a tradeoff between power and performance, you'll get both.)
Apr 30 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
dsimcha wrote:

 == Quote from Brad Roberts (braddr puremagic.com)'s article

 dsimcha wrote:

  D2 is a complex language, but it's not complex in a haphazard way.  It's
complex
 because it statically proves stuff about your code (const, etc), and allows
 extremely powerful, generic user-defined types.  These are the kinds of things
 that most people only dream about.


 I'd like to drill into this 'd2 is a complex language' assertion more.  Can we
 build a factual list of the delta of complexity between d1 and d2?
 The primary area is the type system:
   1) introduction of const
       -- optional and doesn't affect callers of api's that declare const params
   2) introduction of immutable
       -- less optional since it's not as coercable, but also less frequently
 used in apis.
   3) introduction of pure
       -- optional, will not affect callers of apis
   4) introduction of nothrow
       -- optional, will not affect callers of apis
 Others:
 5) template if clause
 I'm specifically leaving out Phobos and other library layer issues, though feel
 free to count the runtime as part of the language when adding to this list.
 -- Brad


 
 Template alias parameters, ref returns, shared (even though it's not
implemented,
 it's on its way, so it still counts), closures, alias this, template literals,
 struct ctors and dtors (and in general structs becoming more like classes) to
name
 a few.  I love all of these, and I personally think the complexity is
justified.
 It's just that I don't know how easy it would be to convince someone coming
from
 Java of this, so I'm playing devil's advocate a little.


Specifically for closures, they are less surprising than d1 delegate 
literals for people coming from most other languages (besides C++0x, maybe).

Most everything else works to eliminate surprises.
May 01 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:

 To me a fair assessment of whether a complex feature belongs in a language is
the
 following:
 
 Given the target audience, will the average person save more time by using the
new
 feature than he/she spends learning it?


Not a bad definition.


 The assumption here is that you will have to learn most or all of the features
of
 your language of choice, because you will have to understand other people's
code.
  D2 is a complex language, but it's not complex in a haphazard way.  It's
complex
 because it statically proves stuff about your code (const, etc), and allows
 extremely powerful, generic user-defined types.  These are the kinds of things
 that most people only dream about.


Any fool can design something complicated. Genius is in finding the 
underlying simplicity. For example, in C++, function overloading is done 
with a very complicated set of rules and a mass of special cases. But 
C++ function template overloading is done with one simple rule: partial 
ordering. C++ couldn't go back and fix function overloading, but D can. 
D overloads both functions and function templates with partial ordering, 
which is a simple rule that gives results equal to or better than the 
complex rules.
Apr 30 2009
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
For another real world example, we had a server daemon written in Java 
and it took forever, had huge problems, cost us quite a bit, etc. etc.

We decided to have the same server rewritten in D, and it took 
significantly less time, works correctly according to spec, doesn't 
crash/hang half as often (the Java server would die in a way that made 
it appear to still be up, made us crazy), and more.

Sure, maybe this is a reflection of the programmer who worked on it - 
but in the end, D was by far the better route for us.

-[Unknown]


bearophile wrote:

 Walter Bright:

 D aims to reduce project costs by reducing training time and shortening
development time.<


 
 I agree that this is very important. Helping the programmer avoid bugs and
helping her to follow good design practices are among the most important
qualities of a programming language, because in practical programming often
most time (= money) is spent debugging programs and updating them.
 
 But you are comparing D with C++, because programming in D1 is faster and
often simpler than doing the same in C++.
 

developing time even more than D1.
 D1 is almost a system language, so it's not easy to compete with the
productivity of application languages designed to put the programmer first and
the CPU second.
 
 And D2 is not an easy&simple language, you need a good amount of time to
learn/teach it, more than Java for example.
 
 Bye,
 bearophile
Apr 30 2009
parent reply Brad Roberts <braddr puremagic.com> writes:
Don't discount the major advantage of being a second round design and
implementation as well.  I'm sure you learned a lot in the first iteration that
fed directly into not making the same set of mistakes again.

Not that D isn't the better language, but there's so many variables in
situations like this that you really can't draw significant conclusions from
them.

All that said.. yay for going with D and having success with it, for whatever
the reasons. :)

Later,
Brad

Unknown W. Brackets wrote:

 For another real world example, we had a server daemon written in Java
 and it took forever, had huge problems, cost us quite a bit, etc. etc.
 
 We decided to have the same server rewritten in D, and it took
 significantly less time, works correctly according to spec, doesn't
 crash/hang half as often (the Java server would die in a way that made
 it appear to still be up, made us crazy), and more.
 
 Sure, maybe this is a reflection of the programmer who worked on it -
 but in the end, D was by far the better route for us.
 
 -[Unknown]
 
 
 bearophile wrote:

 Walter Bright:

 D aims to reduce project costs by reducing training time and
 shortening development time.<


 I agree that this is very important. Helping the programmer avoid bugs
 and helping her to follow good design practices are among the most
 important qualities of a programming language, because in practical
 programming often most time (= money) is spent debugging programs and
 updating them.

 But you are comparing D with C++, because programming in D1 is faster
 and often simpler than doing the same in C++.


 shorten developing time even more than D1.
 D1 is almost a system language, so it's not easy to compete with the
 productivity of application languages designed to put the programmer
 first and the CPU second.

 And D2 is not an easy&simple language, you need a good amount of time
 to learn/teach it, more than Java for example.

 Bye,
 bearophile
Apr 30 2009
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
That's true, but there wasn't a lot of second-round design benefit here. 
  It was pretty much the same specs sent to both people.  The Java 
programmer continued to try to fix the crashing bugs, which were really 
a design issue and not anything to do with scoping.

We used a contractor for both, and both were loosely managed, so there 
wasn't a lot of design experience that carried over either.

Worse, when the D project was near complete (it did start after the Java 
server)... we discovered a few bugs in the Java implementation that we 
needed to replicate, because development of client components was 
already underway using it.  So, the D programmer had to reverse engineer 
bugs (departures from the scope document) in the Java version.

Yes, second round does help, but it was not nearly so clean cut in this 
case.  I don't have any question that the project would've gone worse if 
we had just hired another Java programmer for it to start over.

-[Unknown]


Brad Roberts wrote:

 Don't discount the major advantage of being a second round design and
 implementation as well.  I'm sure you learned a lot in the first iteration that
 fed directly into not making the same set of mistakes again.
 
 Not that D isn't the better language, but there's so many variables in
 situations like this that you really can't draw significant conclusions from
them.
 
 All that said.. yay for going with D and having success with it, for whatever
 the reasons. :)
 
 Later,
 Brad
 
 Unknown W. Brackets wrote:

 For another real world example, we had a server daemon written in Java
 and it took forever, had huge problems, cost us quite a bit, etc. etc.

 We decided to have the same server rewritten in D, and it took
 significantly less time, works correctly according to spec, doesn't
 crash/hang half as often (the Java server would die in a way that made
 it appear to still be up, made us crazy), and more.

 Sure, maybe this is a reflection of the programmer who worked on it -
 but in the end, D was by far the better route for us.

 -[Unknown]


 bearophile wrote:

 Walter Bright:

 D aims to reduce project costs by reducing training time and
 shortening development time.<


 I agree that this is very important. Helping the programmer avoid bugs
 and helping her to follow good design practices are among the most
 important qualities of a programming language, because in practical
 programming often most time (= money) is spent debugging programs and
 updating them.

 But you are comparing D with C++, because programming in D1 is faster
 and often simpler than doing the same in C++.


 shorten developing time even more than D1.
 D1 is almost a system language, so it's not easy to compete with the
 productivity of application languages designed to put the programmer
 first and the CPU second.

 And D2 is not an easy&simple language, you need a good amount of time
 to learn/teach it, more than Java for example.

 Bye,
 bearophile
May 01 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:
 

 D aims to reduce project costs by reducing training time and shortening 
 development time.


It really hasn't worked out that way for me with D2. Here's an example from
yesterday:

I picked up where I left off with creating a weak ref library, something most
other GC'd languages have as part of their standard library. It probably comes
as no surprise that I was getting seg faults. Of course, those are supposed to
be trivial to solve. I run the app through gdb, and catch the crash. I can see
the stack but can't figure out which line the fault occurred on or what the
important local variables are set to. 

I make up an incorrect theory of what could be going on and start a detailed
sifting through all actions of the gc. Everything was fine :( I somehow notice
later in the night a small usage difference between my code and the GC. I fix
that and try a better test to ensure things work.

I see previously working code is now broken. I start checking code and settle
on std.conv being broken. Out of the 15 candidates for to!(T), I overlook the
one that should be used, but do spot what is incorrectly being used. The code
looks legit - do a conversion to a string from a struct, but only if it lacks a
toString function. I have a to string function! I test the logic with a static
assert and it's wrong. Is this a compiler bug? I remember some screwy is
expression syntax and try that instead. Looks like the screwy syntax is needed.
I have always hated the is syntax because it's non-intuitive. It looks like Mr.
Metaprogramming (Andrei) got it wrong.
Apr 30 2009
next sibling parent reply Don <nospam nospam.com> writes:
Jason House wrote:

 Walter Bright Wrote:
  

 D aims to reduce project costs by reducing training time and shortening 
 development time.


 
 It really hasn't worked out that way for me with D2. Here's an example from
yesterday:
 
 I picked up where I left off with creating a weak ref library, something most
other GC'd languages have as part of their standard library. It probably comes
as no surprise that I was getting seg faults. Of course, those are supposed to
be trivial to solve. I run the app through gdb, and catch the crash. I can see
the stack but can't figure out which line the fault occurred on or what the
important local variables are set to. 
 
 I make up an incorrect theory of what could be going on and start a detailed
sifting through all actions of the gc. Everything was fine :( I somehow notice
later in the night a small usage difference between my code and the GC. I fix
that and try a better test to ensure things work.
 
 I see previously working code is now broken. I start checking code and settle
on std.conv being broken. Out of the 15 candidates for to!(T), I overlook the
one that should be used, but do spot what is incorrectly being used. The code
looks legit - do a conversion to a string from a struct, but only if it lacks a
toString function. I have a to string function! I test the logic with a static
assert and it's wrong. Is this a compiler bug? I remember some screwy is
expression syntax and try that instead. Looks like the screwy syntax is needed.
I have always hated the is syntax because it's non-intuitive. It looks like Mr.
Metaprogramming (Andrei) got it wrong. 


The latest D2 Phobos is practically an alpha release. Only a couple of 
weeks ago, it wouldn't compile on any extant compiler! There's just no 
way that you'll get reduced project costs while using an alpha release.
Apr 30 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:

 The latest D2 Phobos is practically an alpha release. Only a couple of 
 weeks ago, it wouldn't compile on any extant compiler! There's just no 
 way that you'll get reduced project costs while using an alpha release.


I think it's also important to distinguish a language design issue that 
saps productivity versus a bug in the compiler or library that causes 
problems.
Apr 30 2009
prev sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
Jason House Wrote:


 Walter Bright Wrote:
  

 D aims to reduce project costs by reducing training time and shortening 
 development time.


 
 It really hasn't worked out that way for me with D2. Here's an example from
yesterday:
 
 I picked up where I left off with creating a weak ref library, something most
other GC'd languages have as part of their standard library. It probably comes
as no surprise that I was getting seg faults. Of course, those are supposed to
be trivial to solve. I run the app through gdb, and catch the crash. I can see
the stack but can't figure out which line the fault occurred on or what the
important local variables are set to. 
 
 I make up an incorrect theory of what could be going on and start a detailed
sifting through all actions of the gc. Everything was fine :( I somehow notice
later in the night a small usage difference between my code and the GC. I fix
that and try a better test to ensure things work.
 
 I see previously working code is now broken. I start checking code and settle
on std.conv being broken. Out of the 15 candidates for to!(T), I overlook the
one that should be used, but do spot what is incorrectly being used. The code
looks legit - do a conversion to a string from a struct, but only if it lacks a
toString function. I have a to string function! I test the logic with a static
assert and it's wrong. Is this a compiler bug? I remember some screwy is
expression syntax and try that instead. Looks like the screwy syntax is needed.
I have always hated the is syntax because it's non-intuitive. It looks like Mr.
Metaprogramming (Andrei) got it wrong. 


I tend to agree about the obsessive concern in this newsgroup about
meta-programming. In my view, the whole focus of that is to automate code
generation that really can't be automated if you care about speed and
efficiency because it always has to assume worst case. Usually, when
programmers in a conventional shop do use it, they use it to generalize a quite
narrow case - KISS.

When it aims for the wider case, it often ends up being buggy, like
std.stdio.writefln(...) has been from time to time.

Sadly, in the absence of decent development tools for D, many of us depend on a
plain old editor, and writefln() for debugging.  I notice that in Phobos,
Walter tends to prefer printf(...) - go figure!
Apr 30 2009
next sibling parent reply superdan <super dan.org> writes:
Steve Teale Wrote:


 Jason House Wrote:
 

 Walter Bright Wrote:
  

 D aims to reduce project costs by reducing training time and shortening 
 development time.


 
 It really hasn't worked out that way for me with D2. Here's an example from
yesterday:
 
 I picked up where I left off with creating a weak ref library, something most
other GC'd languages have as part of their standard library. It probably comes
as no surprise that I was getting seg faults. Of course, those are supposed to
be trivial to solve. I run the app through gdb, and catch the crash. I can see
the stack but can't figure out which line the fault occurred on or what the
important local variables are set to. 
 
 I make up an incorrect theory of what could be going on and start a detailed
sifting through all actions of the gc. Everything was fine :( I somehow notice
later in the night a small usage difference between my code and the GC. I fix
that and try a better test to ensure things work.
 
 I see previously working code is now broken. I start checking code and settle
on std.conv being broken. Out of the 15 candidates for to!(T), I overlook the
one that should be used, but do spot what is incorrectly being used. The code
looks legit - do a conversion to a string from a struct, but only if it lacks a
toString function. I have a to string function! I test the logic with a static
assert and it's wrong. Is this a compiler bug? I remember some screwy is
expression syntax and try that instead. Looks like the screwy syntax is needed.
I have always hated the is syntax because it's non-intuitive. It looks like Mr.
Metaprogramming (Andrei) got it wrong. 


 
 I tend to agree about the obsessive concern in this newsgroup about
meta-programming. In my view, the whole focus of that is to automate code
generation that really can't be automated if you care about speed and
efficiency because it always has to assume worst case. Usually, when
programmers in a conventional shop do use it, they use it to generalize a quite
narrow case - KISS.


yerself said yer dun understand wut's goin' on, ol' timer. really if u wanna
stick to the ol' times grow an afro & write in c. d without no meta would be a
greasespot in language town. it's meta that keeps d goin' and no meta no honey.
an' wut's jasons problem. saw the bug. it's a fuckin' typo. mr. metamuthafucka
could make a fuckin' typo. so who gives a shit. why read anything into it. just
put a unittest there and move on. conv is akshully kewl btw.


 When it aims for the wider case, it often ends up being buggy, like
std.stdio.writefln(...) has been from time to time.


so wut only templates have bugs? what's yer problem really.


 Sadly, in the absence of decent development tools for D, many of us depend on
a plain old editor, and writefln() for debugging.  I notice that in Phobos,
Walter tends to prefer printf(...) - go figure!


yer do me a favor sherlock. yer figure that out fer us all.
Apr 30 2009
next sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
superdan Wrote:


 Steve Teale Wrote:
 

 Jason House Wrote:
 

 Walter Bright Wrote:
  

 D aims to reduce project costs by reducing training time and shortening 
 development time.


 
 It really hasn't worked out that way for me with D2. Here's an example from
yesterday:
 
 I picked up where I left off with creating a weak ref library, something most
other GC'd languages have as part of their standard library. It probably comes
as no surprise that I was getting seg faults. Of course, those are supposed to
be trivial to solve. I run the app through gdb, and catch the crash. I can see
the stack but can't figure out which line the fault occurred on or what the
important local variables are set to. 
 
 I make up an incorrect theory of what could be going on and start a detailed
sifting through all actions of the gc. Everything was fine :( I somehow notice
later in the night a small usage difference between my code and the GC. I fix
that and try a better test to ensure things work.
 
 I see previously working code is now broken. I start checking code and settle
on std.conv being broken. Out of the 15 candidates for to!(T), I overlook the
one that should be used, but do spot what is incorrectly being used. The code
looks legit - do a conversion to a string from a struct, but only if it lacks a
toString function. I have a to string function! I test the logic with a static
assert and it's wrong. Is this a compiler bug? I remember some screwy is
expression syntax and try that instead. Looks like the screwy syntax is needed.
I have always hated the is syntax because it's non-intuitive. It looks like Mr.
Metaprogramming (Andrei) got it wrong. 


 
 I tend to agree about the obsessive concern in this newsgroup about
meta-programming. In my view, the whole focus of that is to automate code
generation that really can't be automated if you care about speed and
efficiency because it always has to assume worst case. Usually, when
programmers in a conventional shop do use it, they use it to generalize a quite
narrow case - KISS.


 
 yerself said yer dun understand wut's goin' on, ol' timer. really if u wanna
stick to the ol' times grow an afro & write in c. d without no meta would be a
greasespot in language town. it's meta that keeps d goin' and no meta no honey.
an' wut's jasons problem. saw the bug. it's a fuckin' typo. mr. metamuthafucka
could make a fuckin' typo. so who gives a shit. why read anything into it. just
put a unittest there and move on. conv is akshully kewl btw.
 

 When it aims for the wider case, it often ends up being buggy, like
std.stdio.writefln(...) has been from time to time.


 
 so wut only templates have bugs? what's yer problem really.
 

 Sadly, in the absence of decent development tools for D, many of us depend on
a plain old editor, and writefln() for debugging.  I notice that in Phobos,
Walter tends to prefer printf(...) - go figure!


 
 yer do me a favor sherlock. yer figure that out fer us all.


Interesting prose style! You'll be an old-timer one day, but by then, I'll be
dead and gone. Maybe I'll be a fly on the wall.

Love you too.
Apr 30 2009
parent superdan <super dan.org> writes:
Steve Teale Wrote:


 superdan Wrote:
 

 Steve Teale Wrote:
 

 Jason House Wrote:
 

 Walter Bright Wrote:
  

 D aims to reduce project costs by reducing training time and shortening 
 development time.


 
 It really hasn't worked out that way for me with D2. Here's an example from
yesterday:
 
 I picked up where I left off with creating a weak ref library, something most
other GC'd languages have as part of their standard library. It probably comes
as no surprise that I was getting seg faults. Of course, those are supposed to
be trivial to solve. I run the app through gdb, and catch the crash. I can see
the stack but can't figure out which line the fault occurred on or what the
important local variables are set to. 
 
 I make up an incorrect theory of what could be going on and start a detailed
sifting through all actions of the gc. Everything was fine :( I somehow notice
later in the night a small usage difference between my code and the GC. I fix
that and try a better test to ensure things work.
 
 I see previously working code is now broken. I start checking code and settle
on std.conv being broken. Out of the 15 candidates for to!(T), I overlook the
one that should be used, but do spot what is incorrectly being used. The code
looks legit - do a conversion to a string from a struct, but only if it lacks a
toString function. I have a to string function! I test the logic with a static
assert and it's wrong. Is this a compiler bug? I remember some screwy is
expression syntax and try that instead. Looks like the screwy syntax is needed.
I have always hated the is syntax because it's non-intuitive. It looks like Mr.
Metaprogramming (Andrei) got it wrong. 


 
 I tend to agree about the obsessive concern in this newsgroup about
meta-programming. In my view, the whole focus of that is to automate code
generation that really can't be automated if you care about speed and
efficiency because it always has to assume worst case. Usually, when
programmers in a conventional shop do use it, they use it to generalize a quite
narrow case - KISS.


 
 yerself said yer dun understand wut's goin' on, ol' timer. really if u wanna
stick to the ol' times grow an afro & write in c. d without no meta would be a
greasespot in language town. it's meta that keeps d goin' and no meta no honey.
an' wut's jasons problem. saw the bug. it's a fuckin' typo. mr. metamuthafucka
could make a fuckin' typo. so who gives a shit. why read anything into it. just
put a unittest there and move on. conv is akshully kewl btw.
 

 When it aims for the wider case, it often ends up being buggy, like
std.stdio.writefln(...) has been from time to time.


 
 so wut only templates have bugs? what's yer problem really.
 

 Sadly, in the absence of decent development tools for D, many of us depend on
a plain old editor, and writefln() for debugging.  I notice that in Phobos,
Walter tends to prefer printf(...) - go figure!


 
 yer do me a favor sherlock. yer figure that out fer us all.


 
 Interesting prose style! You'll be an old-timer one day, but by then, I'll be
dead and gone. Maybe I'll be a fly on the wall.
 
 Love you too.
 
 


no offense meant pops sorry. yer a cool fella all things considered. all i'm
sayin' is if yer dun grok, try to grok. don't piss on it. fer all i know walt
is older than yer & has all rights to behave like an old fart. but he ain't.
bangs like a youngster. he could be a template for yer. ew i just shat a pun.
Apr 30 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 30 Apr 2009 13:23:52 -0400, superdan wrote: 
 (actually who cares what he wrote ...)

"superdan", when you grow up I'm certain that you will be an important
person. I just hope we don't have to wait too long.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Apr 30 2009
next sibling parent superdan <super dan.org> writes:
Derek Parnell Wrote:


 On Thu, 30 Apr 2009 13:23:52 -0400, superdan wrote: 
  (actually who cares what he wrote ...)
 
 "superdan", when you grow up I'm certain that you will be an important
 person. I just hope we don't have to wait too long.
 
 -- 
 Derek Parnell
 Melbourne, Australia
 skype: derek.j.parnell


misfire dood. i'm 34 so my black ass is prolly older than urs.
Apr 30 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Derek Parnell wrote:

 On Thu, 30 Apr 2009 13:23:52 -0400, superdan wrote: 
  (actually who cares what he wrote ...)
 
 "superdan", when you grow up I'm certain that you will be an important
 person. I just hope we don't have to wait too long.


On those occasions on which I've read a post by superdan, I have found 
it to be no less enlightening than the average comment in this 
newsgroup, and much more enlightening than your comment. Moreover, he is 
quite laid-back and tolerant. You and he make a sharp contrast, it seems.
May 01 2009
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Steve Teale wrote:
...

 Sadly, in the absence of decent development tools for D, many of us depend 


on a plain old editor, and writefln() for debugging.  I notice that in 
Phobos, Walter tends to prefer printf(...) - go figure!

I'm quite sure Walter does not prefer printf. He uses it to not depend on a 
working phobos for 'printf' debugging.
Apr 30 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Lutger wrote:

 I'm quite sure Walter does not prefer printf. He uses it to not depend on a 
 working phobos for 'printf' debugging. 


Back in the early days of my C compiler, when printf wasn't working I 
had to resort to putchar <g>.
Apr 30 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steve Teale wrote:

 Jason House Wrote:
 

 Walter Bright Wrote:
 

 D aims to reduce project costs by reducing training time and
 shortening development time.


 It really hasn't worked out that way for me with D2. Here's an
 example from yesterday:
 
 I picked up where I left off with creating a weak ref library,
 something most other GC'd languages have as part of their standard
 library. It probably comes as no surprise that I was getting seg
 faults. Of course, those are supposed to be trivial to solve. I run
 the app through gdb, and catch the crash. I can see the stack but
 can't figure out which line the fault occurred on or what the
 important local variables are set to.
 
 I make up an incorrect theory of what could be going on and start a
 detailed sifting through all actions of the gc. Everything was fine
 :( I somehow notice later in the night a small usage difference
 between my code and the GC. I fix that and try a better test to
 ensure things work.
 
 I see previously working code is now broken. I start checking code
 and settle on std.conv being broken. Out of the 15 candidates for
 to!(T), I overlook the one that should be used, but do spot what is
 incorrectly being used. The code looks legit - do a conversion to a
 string from a struct, but only if it lacks a toString function. I
 have a to string function! I test the logic with a static assert
 and it's wrong. Is this a compiler bug? I remember some screwy is
 expression syntax and try that instead. Looks like the screwy
 syntax is needed. I have always hated the is syntax because it's
 non-intuitive. It looks like Mr. Metaprogramming (Andrei) got it
 wrong.




By the way, I put the fixed std.conv yesterday in svn :o).


 I tend to agree about the obsessive concern in this newsgroup about
 meta-programming. In my view, the whole focus of that is to automate
 code generation that really can't be automated if you care about
 speed and efficiency because it always has to assume worst case.
 Usually, when programmers in a conventional shop do use it, they use
 it to generalize a quite narrow case - KISS.


Well I don't know. I agree that to the unwary things could look daunting 
at first, but really it all ends up in a much better place than before. 
One thing I've always admired about Walter is his willingness and 
capacity to learn new things. He once told me something that surprised 
me - that he believes many language designers don't get the power of 
templates. They would read about templates, work through a couple of 
examples, and remain unimpressed. Some languages do seem to suggest 
that. It took Walter several passes to actually "get" templates. 
Remember, at a time there were no templates in D and Walter said he'll 
never put them in, to the joy of some.


 When it aims for the wider case, it often ends up being buggy, like
 std.stdio.writefln(...) has been from time to time.


There have been quite a few bugs in the I/O functions because the 
infrastructure underneath them has gone through a few major revisions. 
As Don said, D2 is an alpha and it cannot be held to the stability 
standards of a finished product.


Andrei
Apr 30 2009
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s

 One thing I've always admired about Walter is his willingness and
 capacity to learn new things. He once told me something that surprised
 me - that he believes many language designers don't get the power of
 templates. They would read about templates, work through a couple of
 examples, and remain unimpressed. Some languages do seem to suggest
 that. It took Walter several passes to actually "get" templates.
 Remember, at a time there were no templates in D and Walter said he'll
 never put them in, to the joy of some.


Well, one of the niches of D is making template metaprogramming accessible to
the
masses.  While you can do it in C++, doing anything beyond simple generics with
templates is so messy that 99% of the programming population never would.  If I
had only seen C++ templates and had not been able to envision what the D
template
system might become, would still miss the ability to write simple generic
functions, but not much else.
Apr 30 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Andrei Alexandrescu wrote:

 There have been quite a few bugs in the I/O functions because the 
 infrastructure underneath them has gone through a few major revisions. 
 As Don said, D2 is an alpha and it cannot be held to the stability 
 standards of a finished product.


Then I should wait a few revisions before doing anything that depends in 
any significant way on Phobos?

I think there's no point in releasing a product that is known to be 
unstable. But I guess it's intended as a preview / request for testing. 
What versions of D2 and Phobos are recommended to use for something 
vaguely stable and usable?
Apr 30 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Christopher Wright wrote:

 Andrei Alexandrescu wrote:

 There have been quite a few bugs in the I/O functions because the
 infrastructure underneath them has gone through a few major revisions.
 As Don said, D2 is an alpha and it cannot be held to the stability
 standards of a finished product.


 
 Then I should wait a few revisions before doing anything that depends in
 any significant way on Phobos?
 
 I think there's no point in releasing a product that is known to be
 unstable. But I guess it's intended as a preview / request for testing.
 What versions of D2 and Phobos are recommended to use for something
 vaguely stable and usable?


None.  Use D1 if you want stability.

The D2 website needs a big red label on the front sayin' "Warning:
lark's vomit."

Or "Warning: pre-release software; do not use for anything, ever."

  -- Daniel
Apr 30 2009
parent reply grauzone <none example.net> writes:
Daniel Keep wrote:

 
 Christopher Wright wrote:

 Andrei Alexandrescu wrote:

 There have been quite a few bugs in the I/O functions because the
 infrastructure underneath them has gone through a few major revisions.
 As Don said, D2 is an alpha and it cannot be held to the stability
 standards of a finished product.


 Then I should wait a few revisions before doing anything that depends in
 any significant way on Phobos?

 I think there's no point in releasing a product that is known to be
 unstable. But I guess it's intended as a preview / request for testing.
 What versions of D2 and Phobos are recommended to use for something
 vaguely stable and usable?


 
 None.  Use D1 if you want stability.


I'm using D1, but it's a bug rollercoaster. I'm claiming what D needs is 
not new spiffy features, that solve all currently known problems of the 
computer science world, but a rock stable toolchain.


 The D2 website needs a big red label on the front sayin' "Warning:
 lark's vomit."
 
 Or "Warning: pre-release software; do not use for anything, ever."
 
   -- Daniel


By the way, why do people feel the need to "sign" their posts, even 
though the news protocol already provides a "From: " field, that not 
only makes the signature redundant, but is also better to spot, is 
recognized by the news readers, and usually provides more information?
Apr 30 2009
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
grauzone wrote:

 Daniel Keep wrote:

 Christopher Wright wrote:

 Andrei Alexandrescu wrote:

 There have been quite a few bugs in the I/O functions because the
 infrastructure underneath them has gone through a few major revisions.
 As Don said, D2 is an alpha and it cannot be held to the stability
 standards of a finished product.


 Then I should wait a few revisions before doing anything that depends in
 any significant way on Phobos?

 I think there's no point in releasing a product that is known to be
 unstable. But I guess it's intended as a preview / request for testing.
 What versions of D2 and Phobos are recommended to use for something
 vaguely stable and usable?


 None.  Use D1 if you want stability.


 
 I'm using D1, but it's a bug rollercoaster. I'm claiming what D needs is
 not new spiffy features, that solve all currently known problems of the
 computer science world, but a rock stable toolchain.


Have you made sure bugs are filed for the issues you've found or run into?  Have
you voted for those you feel are the most important?

D1 receives a steady stream of bug fixes every few weeks based on some
combination of user feedback and Walter's whims.

Later,
Brad
Apr 30 2009
next sibling parent grauzone <none example.net> writes:
Brad Roberts wrote:

 grauzone wrote:

 Daniel Keep wrote:

 Christopher Wright wrote:

 Andrei Alexandrescu wrote:

 There have been quite a few bugs in the I/O functions because the
 infrastructure underneath them has gone through a few major revisions.
 As Don said, D2 is an alpha and it cannot be held to the stability
 standards of a finished product.


 Then I should wait a few revisions before doing anything that depends in
 any significant way on Phobos?

 I think there's no point in releasing a product that is known to be
 unstable. But I guess it's intended as a preview / request for testing.
 What versions of D2 and Phobos are recommended to use for something
 vaguely stable and usable?


 None.  Use D1 if you want stability.


 I'm using D1, but it's a bug rollercoaster. I'm claiming what D needs is
 not new spiffy features, that solve all currently known problems of the
 computer science world, but a rock stable toolchain.


 
 Have you made sure bugs are filed for the issues you've found or run into? 
Have
 you voted for those you feel are the most important?
 
 D1 receives a steady stream of bug fixes every few weeks based on some
 combination of user feedback and Walter's whims.


This goes into the right direction. Some time ago, we didn't even have a 
stable language specification. Now, the language and the compiler are 
supposed to be stable, but actually they still need a lot of work. The 
language specification is full of glaring holes, especially in tricky 
areas like .stringof or CTFE. The compiler has some bugs/deficiencies 
that probably never will be fixed. For example, the enum forward 
referencing bug is known since 2 years.

Sometimes I wonder how much better dmd and D (D1) would be, if the D 
Gods would concentrate all their energy on fixing bugs or closing the 
language spec by figuring out what some language constructs actually are 
supposed to do? Sure, they'd find this boring, but I'd just like to use 
D for real stuff.


 Later,
 Brad
Apr 30 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:

 D1 receives a steady stream of bug fixes every few weeks based on some
 combination of user feedback and Walter's whims.


Lately I've also been getting a stream of patches to fix them, too!
Apr 30 2009
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
grauzone wrote:

 I'm using D1, but it's a bug rollercoaster. I'm claiming what D needs is
 not new spiffy features, that solve all currently known problems of the
 computer science world, but a rock stable toolchain.


Would be nice, yes.

That said, we've got buildable source for DMD now, so more people are
starting to help squash bugs.


 The D2 website needs a big red label on the front sayin' "Warning:
 lark's vomit."

 Or "Warning: pre-release software; do not use for anything, ever."

   -- Daniel


 
 By the way, why do people feel the need to "sign" their posts, even
 though the news protocol already provides a "From: " field, that not
 only makes the signature redundant, but is also better to spot, is
 recognized by the news readers, and usually provides more information?


Force of habit?  Holdover from the days when we wrote things on bits of
pulped trees which didn't have a convenient "From:" field.

What I want to know is why people quote multi-page messages only to add
a single line to the bottom that's only tangentially related to the
message they're responding to.

  -- Daniel
Apr 30 2009
next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Fri, 01 May 2009 15:15:25 +1000, Daniel Keep wrote:


 What I want to know is why people quote multi-page messages only to add
 a single line to the bottom that's only tangentially related to the
 message they're responding to.
 
   -- Daniel


For me it has been that quoted text is hidden, and am use to newer 
readers like Google groups where you don't need the quoted text as it is 
already shown above. It is also easier to leave it than figure out what 
should be deleted. But I'll start limiting mine to what I replay to.
Apr 30 2009
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Daniel Keep wrote:

 grauzone wrote:

 By the way, why do people feel the need to "sign" their posts, even
 though the news protocol already provides a "From: " field, that not
 only makes the signature redundant, but is also better to spot, is
 recognized by the news readers, and usually provides more information?


 
 Force of habit?  Holdover from the days when we wrote things on bits of
 pulped trees which didn't have a convenient "From:" field.


Well even one hundred years ago they'd sign a letter even though the 
name was in the letterhead and also on the envelope.


 What I want to know is why people quote multi-page messages only to add
 a single line to the bottom that's only tangentially related to the
 message they're responding to.


Worse: they quote a large message and they insert a line somewhere in 
the middle of it.

Andrei
May 01 2009
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Daniel Keep wrote:


 What I want to know is why people quote multi-page messages only to add
 a single line to the bottom that's only tangentially related to the
 message they're responding to.

   -- Daniel


Or those people who post a single line at the beginning, then a wall of quoted
text, leaving the poor reader to first fine-comb the text for a hidden line,
then realize there might be text at the top. I can accept that some people do
that out of habit or ignorance, but when newsreaders force such idocy upon
their users...

--
  Simen (who likes signatures)
May 02 2009
prev sibling parent Derek Parnell <derek psych.ward> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, 01 May 2009 06:16:28 +0200, grauzone wrote:
 

 By the way, why do people feel the need to "sign" their posts, even 
 though the news protocol already provides a "From: " field, that not 
 only makes the signature redundant, but is also better to spot, is 
 recognized by the news readers, and usually provides more information?


I thought that the purpose of the 'signature' was to provide *proof* of who
sent it rather than just "who sent it".

In this digital age its not nearly so effective though.
- -- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.6.3 (Build 3017) - not licensed for commercial use:
www.pgp.com

wsBVAwUBSftq/gKfaWXNfYnxAQgoNggAonUoJX4haoUkMyMH44ZdDwM5lr96rCSL
kiaAUOT5QIx19+DxjBgLVQ1UWSZ/i967073hBXVU/QyUJstNGiUqr2DqDMXXdnnK
FCfUGL6cV8yIMdFgeoJBSl4k5LV6rGjCU0kCOqCuz3a/hyf2lGhCObcnwMnbni5E
3W8sHXeQGUv/dQKDEh69dapQeIXEn6vfCDp5sZSTSuCuA9VBz8r3noyX0j9M+osU
SBCOKCyQorYb7wjoMAGA3KakKP9vFBzWs79++9dJODUuv29GPj4VdI5bJYCZ/yjc
aqYTaYh17RlGoVLA1gc2e+rSnC+mf24A2bCD+KHjQDL5jn5ZMK4+HQ==
=1H+K
-----END PGP SIGNATURE-----
May 01 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Steve Teale wrote:

 Sadly, in the absence of decent development tools for D, many of us
 depend on a plain old editor, and writefln() for debugging.  I notice
 that in Phobos, Walter tends to prefer printf(...) - go figure!


I tend to use printf for debugging because writefln requires a lot of 
the compiler/library to be working correctly for it to work. printf 
requires practically nothing in D to work correctly, so it is ideal for 
debugging the compiler and the library.

I use writefln pretty much exclusively when developing an app in D, for 
the straightforward reason that writefln is much simpler, safer, and 
more powerful than printf.

Some of my older D app code uses printf because writefln didn't exist 
way back.
Apr 30 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Unknown W. Brackets wrote:

 I'm lucky, I'm a technical lead/manager at work, so I get to say "for 
 this project, we're using D."  And then it happens.  Muhahaha.  We're a 
 small shop but I enjoy my small amount of power.


I could do that, but D is lacking essentials for me:
  - a message bus that integrates with NServiceBus
  - a web toolkit comparable to Castle Monorail
  - a mock object library that doesn't force me to gouge my eyes out 
(which I could probably do by now)
  - CruiseControl.NET integration (which I could write, if I had a 
machine that could run CC.NET)
  - an ORM library comparable to NHibernate

If I had that, I could use D in some projects at work. In point of fact, 
I could skip the web toolkit for some projects, and I could skip ORM for 
some projects. But these days, we're using NServiceBus almost everywhere.
Apr 30 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Christopher Wright wrote:

  - a mock object library that doesn't force me to gouge my eyes out 
 (which I could probably do by now)
  - an ORM library comparable to NHibernate


http://www.dsource.org/projects/dmocks

Not sure if the Sleeper is "comparable to NHibernate", but my eyes are 
perfectly intact despite using SelfMock.
Apr 30 2009
parent Christopher Wright <dhasenan gmail.com> writes:
Robert Fraser wrote:

 Christopher Wright wrote:

  - a mock object library that doesn't force me to gouge my eyes out 
 (which I could probably do by now)
  - an ORM library comparable to NHibernate


 
 http://www.dsource.org/projects/dmocks
 
 Not sure if the Sleeper is "comparable to NHibernate", but my eyes are 
 perfectly intact despite using SelfMock.


Selfmock is better than, say, cppmock, but it's still horrible that I 
can't just give it a type and have it do the right thing. That means 
additional effort to create the mock objects, and some effort to 
maintain them -- though if you're following the open/closed principle, 
this should be less problematic. Far better than nothing, but not as 
good as it should be.

Sleeper is vaporware, and would do me no good since I can't even get 
ddbi to work on my machine (64-bit linux; the mysql driver always claims 
the packets I send are too long).
Apr 30 2009
prev sibling next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Steven Schveighoffer wrote:

 I can't wait for D to take over the world, so I no longer have to write 
 in this horrid language ;)



versions that have been in D for a while, and some other vaguely neat 
things that D doesn't have on occasion.


capabilities. For example, I find that I often need two classes that are 
extremely similar with some minor exceptions, and in D I could just use 

(Think arguments to attributes.) The foreach situation you mentioned is 
just silly, too.

On the other hand, my main complaint with D is the lack of reflection, 

extensive use of libraries that use reflection a lot (Rhino Mocks, the 
Castle project, NHibernate...)
Apr 30 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 30 Apr 2009 06:50:12 -0400, Christopher Wright  
<dhasenan gmail.com> wrote:


 Steven Schveighoffer wrote:

 I can't wait for D to take over the world, so I no longer have to write  
 in this horrid language ;)



 versions that have been in D for a while, and some other vaguely neat  
 things that D doesn't have on occasion.


I'm still stuck on 2.0, but that's mostly because I don't want to port to  

views I have.



 capabilities. For example, I find that I often need two classes that are  
 extremely similar with some minor exceptions, and in D I could just use  



Yes, and generics are noticably inferior.  They aren't even close to  
templates.  I hate how you have to specify the base class in order to use  
any methods on a parameterized type.

I was surprised to learn it had some sort of equivalent to IFTI.


 On the other hand, my main complaint with D is the lack of reflection,  

 extensive use of libraries that use reflection a lot (Rhino Mocks, the  
 Castle project, NHibernate...)


Yes, I use reflection in some of my code, and it definitely has to come to  
D sometime.  At least if I wanted to port my current project to D it would  
have to ;)

-Steve
Apr 30 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Steven Schveighoffer wrote:

 Yes, I use reflection in some of my code, and it definitely has to come 
 to D sometime.  At least if I wanted to port my current project to D it 
 would have to ;)


It's in D, just not standardized. There used to be a project 
"flectioned" by Thomas Khune that allowed reflection by either importing 
the map file or adding debug symbols in Windows (in Linux, it worked 
even on non-debug builds). It doesn't compile on the newer versions of 
D, but it shouldn't be too hard to fix up.

A different option would be to use some template/mixin magic to add 
specified classes to a set of exported/reflectable types. A good example 
of this is MiniD's binding libraries or PyD, which allow you to very 
easily wrap a module/class/etc. and make the names visible to a dynamic 
language.
Apr 30 2009
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 30 Apr 2009 18:46:47 -0400, Robert Fraser  
<fraserofthenight gmail.com> wrote:


 Steven Schveighoffer wrote:

 Yes, I use reflection in some of my code, and it definitely has to come  
 to D sometime.  At least if I wanted to port my current project to D it  
 would have to ;)


 It's in D, just not standardized. There used to be a project  
 "flectioned" by Thomas Khune that allowed reflection by either importing  
 the map file or adding debug symbols in Windows (in Linux, it worked  
 even on non-debug builds). It doesn't compile on the newer versions of  
 D, but it shouldn't be too hard to fix up.

 A different option would be to use some template/mixin magic to add  
 specified classes to a set of exported/reflectable types. A good example  
 of this is MiniD's binding libraries or PyD, which allow you to very  
 easily wrap a module/class/etc. and make the names visible to a dynamic  
 language.


I load executable assemblies dynamically and examine the attributes of  
classes to determine how to process them.  I don't think D is quite there,  
but I have faith it will be.

And one of the things you said is key: "used to be"...

besides, I'm using a lot of .Net APIs and it would be difficult to switch  
them to D, so I sort of am not giving you the *only* thing that would have  
to be done to port my project to D ;)

As a side note though, one of the clients that uses the server is  
completely written in D because it runs on a very small Linux OS.  It is  
actually the reason I started learning D in the first place (Didn't want  
to install C++ libs, didn't want to do network programming in C *shudder*).

-Steve
May 01 2009
prev sibling parent reply Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
I've had a painful couple of days myself.

I've been coding in Java for the last several years, but am now working on a
project in C++. It had been a while (8 years?) since I did any serious C++ work
and I didn't do much then. So I bought a copy of "C++ for Java Programmers" and
got stuck in. Mostly what I do is write Java code in my head and transmogrify
it into C++, relying heavily on frequent compilation to let me know when I've
gone off the rails.

My lead comes by my desk the other day and (this could only happen in a large,
bureaucratic, schizophrenic corporation...) and he tells me that, in spite of
the fact that we are using a C++ development environment, we are not going to
actually USE C++, so everything needs to be rewritten in C.  ??!!

He described this as a "disconnect".

Welcome to 1999.

Paul


Steven Schveighoffer Wrote:


 I can't wait for D to take over the world, so I no longer have to write in  
 this horrid language ;)
 
 -Steve
Apr 30 2009
parent Steve Teale <steve.teale britseyeview.com> writes:
Paul D. Anderson Wrote:


 I've had a painful couple of days myself.
 
 I've been coding in Java for the last several years, but am now working on a
project in C++. It had been a while (8 years?) since I did any serious C++ work
and I didn't do much then. So I bought a copy of "C++ for Java Programmers" and
got stuck in. Mostly what I do is write Java code in my head and transmogrify
it into C++, relying heavily on frequent compilation to let me know when I've
gone off the rails.
 
 My lead comes by my desk the other day and (this could only happen in a large,
bureaucratic, schizophrenic corporation...) and he tells me that, in spite of
the fact that we are using a C++ development environment, we are not going to
actually USE C++, so everything needs to be rewritten in C.  ??!!
 
 He described this as a "disconnect".
 
 Welcome to 1999.
 
 Paul
 


Sympathy waves, sympathy waves! I have worked for organizations where you'd get
a nasty email from management if you made a comment like that on a public
newsgroup. Watch your step, Big Brother is watching you ;=)
May 01 2009