digitalmars.D - I wish I could use D for everything
- Steven Schveighoffer (27/27) Apr 29 2009 I've written this handy template in C# called DictionaryValueEnum. It
- BCS (6/10) Apr 29 2009 IIRC this works
- Steven Schveighoffer (6/12) Apr 29 2009 Whaddya know, you are correct :)
- Walter Bright (2/4) Apr 29 2009 Check out Cristi's alpha version of D.net!
- BCS (3/10) Apr 30 2009 I don't care a wit what it runs on. If anything I prefer not running on ...
- Walter Bright (2/16) Apr 30 2009 True, but the D.net compiler works with the .net tools and ecosystem.
- BCS (2/18) Apr 30 2009 auto compleat, syntax highlighting, jump to definition, re factoring, et...
- Walter Bright (2/4) Apr 30 2009 Ask Cristi for a more definitive answer.
- Unknown W. Brackets (9/32) Apr 30 2009 So, really, all you want is a Visual Studio Language Service.
- BCS (2/8) May 02 2009 Yah, I just want the hard stuff. (go figure :-)
- Unknown W. Brackets (9/48) Apr 29 2009 I'm lucky, I'm a technical lead/manager at work, so I get to say "for
- Simen Kjaeraas (4/12) Apr 29 2009 Lucky bastard. :p
- Walter Bright (4/8) Apr 29 2009 You nailed the bottom line - total cost of a project.
- Unknown W. Brackets (10/19) Apr 29 2009 Yep. D does a good job of that.
- bearophile (8/9) Apr 30 2009 I agree that this is very important. Helping the programmer avoid bugs a...
- Steve Teale (3/17) Apr 30 2009 Can't agree about Java. To me, it has always been a pain in the arse. C#...
- Robert Fraser (8/10) Apr 30 2009 Eh.... I'm working on my current project in D because I find development...
- Daniel de Kok (9/18) May 05 2009 The primary thing that is holding me from using D more is the lack of
- Walter Bright (13/33) Apr 30 2009 I've tried to program in Java. It takes me considerably more time to get...
- bearophile (12/21) Apr 30 2009 I agree that D is more expressive than Java, my D programs are quite sho...
- Walter Bright (6/11) Apr 30 2009 I agree that Java is easier to learn than D. But that's all lost when
- dsimcha (11/22) Apr 30 2009 To me a fair assessment of whether a complex feature belongs in a langua...
- Brad Roberts (18/22) Apr 30 2009 I'd like to drill into this 'd2 is a complex language' assertion more. ...
- dsimcha (15/37) Apr 30 2009 Template alias parameters, ref returns, shared (even though it's not imp...
- Brad Roberts (8/47) Apr 30 2009 I'm going to play devils advocate too...
- Jesse Phillips (3/61) Apr 30 2009 I thought this stuff was good enough to deserve its own wiki page: http:...
- Benji Smith (5/9) May 02 2009 Ideally, that would be true.
- Walter Bright (16/24) Apr 30 2009 Andrei and I have talked about this a bit. He points out how Unix
- Christopher Wright (4/34) May 01 2009 Specifically for closures, they are less surprising than d1 delegate
- Walter Bright (10/21) Apr 30 2009 Any fool can design something complicated. Genius is in finding the
- Unknown W. Brackets (10/24) Apr 30 2009 For another real world example, we had a server daemon written in Java
- Brad Roberts (10/49) Apr 30 2009 Don't discount the major advantage of being a second round design and
- Unknown W. Brackets (16/69) May 01 2009 That's true, but there wasn't a lot of second-round design benefit here....
- Jason House (6/8) Apr 30 2009 It really hasn't worked out that way for me with D2. Here's an example f...
- Don (4/16) Apr 30 2009 The latest D2 Phobos is practically an alpha release. Only a couple of
- Walter Bright (4/7) Apr 30 2009 I think it's also important to distinguish a language design issue that
- Steve Teale (4/16) Apr 30 2009 I tend to agree about the obsessive concern in this newsgroup about meta...
- superdan (4/22) Apr 30 2009 so wut only templates have bugs? what's yer problem really.
- Steve Teale (3/31) Apr 30 2009 Interesting prose style! You'll be an old-timer one day, but by then, I'...
- superdan (2/38) Apr 30 2009 no offense meant pops sorry. yer a cool fella all things considered. all...
- Derek Parnell (8/8) Apr 30 2009 On Thu, 30 Apr 2009 13:23:52 -0400, superdan wrote:
- superdan (2/12) Apr 30 2009 misfire dood. i'm 34 so my black ass is prolly older than urs.
- Christopher Wright (5/10) May 01 2009 On those occasions on which I've read a post by superdan, I have found
- Lutger (6/7) Apr 30 2009 on a plain old editor, and writefln() for debugging. I notice that in
- Walter Bright (3/5) Apr 30 2009 Back in the early days of my C compiler, when printf wasn't working I
- Andrei Alexandrescu (17/59) Apr 30 2009 Well I don't know. I agree that to the unwary things could look daunting...
- dsimcha (7/15) Apr 30 2009 Well, one of the niches of D is making template metaprogramming accessib...
- Christopher Wright (7/11) Apr 30 2009 Then I should wait a few revisions before doing anything that depends in...
- Daniel Keep (6/19) Apr 30 2009 None. Use D1 if you want stability.
- grauzone (8/30) Apr 30 2009 I'm using D1, but it's a bug rollercoaster. I'm claiming what D needs is...
- Brad Roberts (7/28) Apr 30 2009 Have you made sure bugs are filed for the issues you've found or run int...
- grauzone (13/40) Apr 30 2009 This goes into the right direction. Some time ago, we didn't even have a...
- Walter Bright (2/4) Apr 30 2009 Lately I've also been getting a stream of patches to fix them, too!
- Daniel Keep (10/24) Apr 30 2009 Would be nice, yes.
- Jesse Phillips (5/10) Apr 30 2009 For me it has been that quoted text is hidden, and am use to newer
- Andrei Alexandrescu (6/17) May 01 2009 Well even one hundred years ago they'd sign a letter even though the
- Simen Kjaeraas (4/8) May 02 2009 Or those people who post a single line at the beginning, then a wall of ...
- Derek Parnell (22/26) May 01 2009 -----BEGIN PGP SIGNED MESSAGE-----
- Walter Bright (10/13) Apr 30 2009 I tend to use printf for debugging because writefln requires a lot of
- Christopher Wright (12/15) Apr 30 2009 I could do that, but D is lacking essentials for me:
- Robert Fraser (4/7) Apr 30 2009 http://www.dsource.org/projects/dmocks
- Christopher Wright (10/19) Apr 30 2009 Selfmock is better than, say, cppmock, but it's still horrible that I
- Christopher Wright (14/16) Apr 30 2009 C# is pretty reasonable. I see a fair number of things in recent
- Steven Schveighoffer (13/27) Apr 30 2009 I'm still stuck on 2.0, but that's mostly because I don't want to port t...
- Robert Fraser (11/14) Apr 30 2009 It's in D, just not standardized. There used to be a project
- Steven Schveighoffer (14/28) May 01 2009 I load executable assemblies dynamically and examine the attributes of
- Paul D. Anderson (7/11) Apr 30 2009 I've had a painful couple of days myself.
- Steve Teale (2/14) May 01 2009 Sympathy waves, sympathy waves! I have worked for organizations where yo...
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
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
On Wed, 29 Apr 2009 23:01:17 -0400, BCS <none anon.com> wrote:Hello Steven,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. -SteveThe 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)
Apr 29 2009
BCS wrote:OTOH, Yah, I'd love to have D as my dev language, but I'd need the toolCheck out Cristi's alpha version of D.net!
Apr 29 2009
Reply to Walter,BCS wrote: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.OTOH, Yah, I'd love to have D as my dev language, but I'd need theCheck out Cristi's alpha version of D.net!
Apr 30 2009
BCS wrote:Reply to Walter,True, but the D.net compiler works with the .net tools and ecosystem.BCS wrote: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.OTOH, Yah, I'd love to have D as my dev language, but I'd need theCheck out Cristi's alpha version of D.net!
Apr 30 2009
Hello Walter,BCS wrote:auto compleat, syntax highlighting, jump to definition, re factoring, etc. ?Reply to Walter,True, but the D.net compiler works with the .net tools and ecosystem.BCS wrote: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.OTOH, Yah, I'd love to have D as my dev language, but I'd need theCheck out Cristi's alpha version of D.net!
Apr 30 2009
BCS wrote:auto compleat, syntax highlighting, jump to definition, re factoring, etc. ?Ask Cristi for a more definitive answer.
Apr 30 2009
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:auto compleat, syntax highlighting, jump to definition, re factoring, etc. ?Reply to Walter,True, but the D.net compiler works with the .net tools and ecosystem.BCS wrote: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.OTOH, Yah, I'd love to have D as my dev language, but I'd need theCheck out Cristi's alpha version of D.net!
Apr 30 2009
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
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
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
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
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
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
bearophile Wrote:Walter Bright:because of the wonderful documentation. But I can still go faster in D just flying by the seat of my pants!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
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
On Fri, May 1, 2009 at 12:56 AM, Robert Fraser <fraserofthenight gmail.com> wrote:bearophile wrote: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, Danielshorten 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
May 05 2009
bearophile wrote: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. 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.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.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
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 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, bearophileD aims to reduce project costs by reducing training time<<
Apr 30 2009
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
== Quote from Walter Bright (newshound1 digitalmars.com)'s articlebearophile 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? 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.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
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
== Quote from Brad Roberts (braddr puremagic.com)'s articledsimcha wrote: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.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
dsimcha wrote:== Quote from Brad Roberts (braddr puremagic.com)'s articleI'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). -- Braddsimcha wrote: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.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
On Thu, 30 Apr 2009 21:20:17 -0700, Brad Roberts wrote:dsimcha wrote:I thought this stuff was good enough to deserve its own wiki page: http:// www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/D2Complexities== Quote from Brad Roberts (braddr puremagic.com)'s articleI'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). -- Braddsimcha wrote: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.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
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
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
dsimcha wrote:== Quote from Brad Roberts (braddr puremagic.com)'s articleSpecifically 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.dsimcha wrote: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.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
May 01 2009
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
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
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
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
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
Jason House wrote:Walter Bright 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.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
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
Jason House Wrote:Walter Bright Wrote: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!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
Steve Teale Wrote:Jason House Wrote: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.Walter Bright Wrote: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.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.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
superdan Wrote:Steve Teale Wrote: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.Jason House Wrote: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.Walter Bright Wrote: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.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.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
Steve Teale Wrote:superdan Wrote: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.Steve Teale Wrote: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.Jason House Wrote: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.Walter Bright Wrote: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.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.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
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
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.parnellmisfire dood. i'm 34 so my black ass is prolly older than urs.
Apr 30 2009
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
Steve Teale wrote: ...Sadly, in the absence of decent development tools for D, many of us dependon 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
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
Steve Teale wrote:Jason House Wrote:By the way, I put the fixed std.conv yesterday in svn :o).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.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
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'sOne 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
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
Christopher Wright wrote:Andrei Alexandrescu wrote: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." -- DanielThere 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
Daniel Keep wrote:Christopher Wright 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.Andrei Alexandrescu wrote:None. Use D1 if you want stability.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?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." -- DanielBy 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
grauzone wrote:Daniel Keep wrote: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, BradChristopher Wright 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.Andrei Alexandrescu wrote:None. Use D1 if you want stability.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
Brad Roberts wrote:grauzone wrote: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.Daniel Keep wrote: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.Christopher Wright 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.Andrei Alexandrescu wrote:None. Use D1 if you want stability.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?Later, Brad
Apr 30 2009
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
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.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. -- DanielThe 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." -- DanielBy 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
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. -- DanielFor 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
Daniel Keep wrote:grauzone wrote:Well even one hundred years ago they'd sign a letter even though the name was in the letterhead and also on the envelope.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.Worse: they quote a large message and they insert a line somewhere in the middle of it. Andrei
May 01 2009
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. -- DanielOr 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
-----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
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
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
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 NHibernatehttp://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
Robert Fraser wrote:Christopher Wright wrote: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).- 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 NHibernatehttp://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
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
On Thu, 30 Apr 2009 06:50:12 -0400, Christopher Wright <dhasenan gmail.com> wrote:Steven Schveighoffer wrote:I'm still stuck on 2.0, but that's mostly because I don't want to port to views I have.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 useYes, 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
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
On Thu, 30 Apr 2009 18:46:47 -0400, Robert Fraser <fraserofthenight gmail.com> wrote:Steven Schveighoffer wrote: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*). -SteveYes, 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.
May 01 2009
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
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. PaulSympathy 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