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