www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is D still alive?

reply Fab <fab-coding web.de> writes:
Dear D community,
My name is Fabian and I used to code C++ and Delphi. But a few month ago I've
got a book about D as a present. All in all D sounds very interesting ... but
- the "big" but - is D still alive?
Are there usable and stable GUI-Toolkits which are actually under development?
Are there any continued database projects?

So - is there any reason to change to D? I would ... I really would change if
there were more points than a nice language. I don't buy a good car if it's to
expensive - so: is D as precious as its pretend to be?

Greetings
Fabian

PS: I hope you can understand my bad English.
Jan 26 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 26 Jan 2011 14:25:10 -0500, Fab <fab-coding web.de> wrote:

 Dear D community,
 My name is Fabian and I used to code C++ and Delphi. But a few month ago  
 I've
 got a book about D as a present. All in all D sounds very interesting  
 ... but
 - the "big" but - is D still alive?

Very much so. D2 is being actively developed. D1 is not, but Tango is being actively developed (which works with D1).
 Are there usable and stable GUI-Toolkits which are actually under  
 development?

I don't have personal experience with any of the current GUI projects, but from what I've read, many of them are usable. Whether they are actively developed, I'm not sure. See many of them here: http://prowiki.org/wiki4d/wiki.cgi?GuiLibraries
 Are there any continued database projects?

AFAIK, there is very little DB support (which will definitely need to be addressed before D is considered a complete language) for D2. However, you *always* have support via C bindings. D has zero-overhead binding to C functions, all you need to do is port the declarations to D. If you are using D1, there are several projects, I don't think many of them are up to date: http://prowiki.org/wiki4d/wiki.cgi?DatabaseBindings
 So - is there any reason to change to D? I would ... I really would  
 change if
 there were more points than a nice language. I don't buy a good car if  
 it's to
 expensive - so: is D as precious as its pretend to be?

I will warn you, once you start using D, you will not want to use something else. I cringe every day when I have to use PHP for work. I would say it is not ready for prime-time yet. It has a way to go, but some have managed to build pretty impressive applications from it. So it would depend on your application. -Steve
Jan 26 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 26 Jan 2011 14:39:08 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Wed, 26 Jan 2011 14:25:10 -0500, Fab <fab-coding web.de> wrote:

 Dear D community,
 My name is Fabian and I used to code C++ and Delphi. But a few month  
 ago I've
 got a book about D as a present. All in all D sounds very interesting  
 ... but
 - the "big" but - is D still alive?

Very much so. D2 is being actively developed. D1 is not, but Tango is being actively developed (which works with D1).

I should clarify, D1 is not getting any new features, but it is getting bug fixes. -Steve
Jan 26 2011
parent reply Fab <fab-coding web.de> writes:
Thank you for your answer.

But is there also a productive IDE for 'the daily use'?
I'm used to code Delphi and there is also everything in the IDE I need to code
full featured applications.
I don't need a GUI-Designer (but it would be nice - maybe something like the
QT-Designer) but a IDE which supports graphical debugging is vital for me.
Jan 26 2011
next sibling parent reply Fab <fab-coding web.de> writes:
In addition you have to know for what I want to use D.
I want to code little games (2D: Jump'n'Run) and I want to use D for scholastic
use - drawing plots, calculating functions, ... and so on.

You see: I want to use D for private and for scholastic purposes.
Jan 26 2011
parent "Nick Sabalausky" <a a.a> writes:
"Fab" <fab-coding web.de> wrote in message 
news:ihpv7r$272q$1 digitalmars.com...
 In addition you have to know for what I want to use D.
 I want to code little games (2D: Jump'n'Run) and I want to use D for 
 scholastic
 use - drawing plots, calculating functions, ... and so on.

 You see: I want to use D for private and for scholastic purposes.

For games, there are SDL and SFML bindings for D. You may also want to look at the Derelict project which includes bindings for a bunch of useful libraries. For plots/charts/graphs/etc, you should look at the humorously-named "Plot2Kill" library. Personally, I think D would be great for small games, private uses and scholastic uses. In fact, even *way* back *before* D1, Kenta Cho made some very good freeware games in D, like Torus Trooper and TUMIKI Fighters (ie, the original version of Blast Works). The areas where D is still a little behind are: If you *need* to be able to compile *native* 64-bit code (32-bit will still work on a 64-bit machine/OS, of course). If you need to create shared dynamic libraries (ie, .dll and .so). If you need to link with Windows C .obj and .lib files that were compiled with anything other than DMC. If you need to use a graphical GUI-builder tool. Or if you want to use something similar to Rails or Django to create web apps.
Jan 26 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Fab" <fab-coding web.de> wrote in message 
news:ihpu4u$24bp$1 digitalmars.com...
 Thank you for your answer.

 But is there also a productive IDE for 'the daily use'?
 I'm used to code Delphi and there is also everything in the IDE I need to 
 code
 full featured applications.
 I don't need a GUI-Designer (but it would be nice - maybe something like 
 the
 QT-Designer) but a IDE which supports graphical debugging is vital for me.

I use Programmer's Notepad 2 which does everything I care about and is very nicely lean and responsive. I'm not sure if it does debugging though, I've never tried. If you prefer the bigger (bloated, IMO) IDE's then there are two D pulgins for Eclipse ("Descent" is the older more advanced one, and there's another, I forget the name, that's newer and being actively developed). There is also stuff out there to make D work well with Visual Studio (see the "D.announcements" newsgroup).
Jan 26 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vpxkvij9eav7ka steve-laptop...
 On Wed, 26 Jan 2011 14:25:10 -0500, Fab <fab-coding web.de> wrote:

 Are there any continued database projects?

AFAIK, there is very little DB support (which will definitely need to be addressed before D is considered a complete language) for D2. However, you *always* have support via C bindings. D has zero-overhead binding to C functions, all you need to do is port the declarations to D. If you are using D1, there are several projects, I don't think many of them are up to date: http://prowiki.org/wiki4d/wiki.cgi?DatabaseBindings

Adam Ruppe and Piotr Szturmaj have recently been working on some database stuff. See the recent thread "Can your programming language do this?"
 So - is there any reason to change to D? I would ... I really would 
 change if
 there were more points than a nice language. I don't buy a good car if 
 it's to
 expensive - so: is D as precious as its pretend to be?

I will warn you, once you start using D, you will not want to use something else. I cringe every day when I have to use PHP for work.

So very true :)
 I would say it is not ready for prime-time yet.  It has a way to go, but 
 some have managed to build pretty impressive applications from it.  So it 
 would depend on your application.

Personally, I think that even though D still has some things to be worked out, I think it's *still* far better than any of the other more mature languages.
Jan 26 2011
next sibling parent Trass3r <un known.com> writes:
retard Wrote:
 Or maybe the community members in general aren't very good developers; they 
 can't see the potential of this language. The fact is, no matter what 
 language you choose, if it isn't a complete joke, you can finish the 
 project

We have a lot of talented people in this community who've created awesome projects, I don't think it's a lack of skills. Sometimes you hit bugs you just can't workaround. In my case these included forward reference bugs where a simple "exchange the declarations" didn't work cause of cross-references and a nasty corrupt stack frame bug I couldn't reduce.
Jan 27 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/28/11 3:25 PM, retard wrote:
 Fri, 28 Jan 2011 10:14:04 -0500, Steven Schveighoffer wrote:
 I think as D matures
 and hopefully gets more enterprise support, these problems will be
 history.

This is the classic chicken or the egg problem. I'm not trying to be unnecessarily mean. Enterprise support is something you desperately need. Consider dsource, wiki4d, d's bugzilla etc. It's amazing how much 3rd party money and effort affects the development. Luckily many things are also free nowadays such as github.
 I don't see any need to prove how well Haskell works. Even though it's
 a "avoid success at all costs" experimental research language. It just
 works. I mean to the extent that I'm willing to go with these silly
 test projects that try to prove something.

The statements I made are not a property of D, they are a property of the lack of backing/maturity. I'm sure when Haskell was at the same maturity stage as D, and if it had no financial backing/support contracts, it would be just as much of a gamble.

But Haskell developers have uninterruptedly received funding during the years.

That doesn't say much about anything. Some projects worked well with funding, some worked well with little or no initial funding.
 You seem to think that D is inherently flawed because of D, but it's
 simply too young for some tasks.  It's rapidly getting older, and I
 think in a year or two it will be mature enough for most projects.

I've heard this before. I've also heard the 64-bit port and many other things are done in a year/month or two. The fact is, you're overly optimistic and these are all bullshit. When I come back here in a year or two, I have full justification to laugh at your stupid claims.

I think if you do that I have full justification to send you back where you originally came from. Cut the crap for a change, will you. Thanks. Andrei
Jan 28 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:
 I can't buy "enterprise" support,

Of course you can!
Jan 28 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:
 On Friday, January 28, 2011 17:16:54 Walter Bright wrote:
 Steven Schveighoffer wrote:
 I can't buy "enterprise" support,


Well, since Scotty hasn't been born yet, it's probably a bit premature... ;)

She canna take the power!
Jan 28 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/31/11 1:52 PM, retard wrote:
 I think the same applies to Phobos 2.. only Andrei knows the design well
 enough and knows how it's going to change in the future. No matter how
 much time one spends studying D or the ecosystem or how D is used in the
 enterprise world, one simply can't obtain any reasonable level of
 knowledge to become a "certified" authority in this community.

People on the Phobos roster all have contributed to it, not to mention the many contributed patches via bugzilla and ideas aired in this group. Also, I have a track record of bringing ideas for future Phobos additions for discussion up here before acting on them. In the words of collection companies: "What else can we do?" I think I'll do something terrible: I'll killfile re tard.com.invalid. This is a rare occurrence - my current filter has only four entries that probably are not valid anymore. I have always saluted your visible efforts at being civil, and I have appreciation for them; obviously you are quite unhappy about the state of the language, and given that it's difficult to not let emotions take the driver's seat. At the same time, however, all too often there's this schadenfreude in your posts that reduces the credibility and the value of the actual content considerably. Between hunting for bits of content and trying to distinguish whether they are genuine or the reverse engineering of a presupposition - the toll on my time is too high. Feel free to email me or to change your ID if you want to share something. Thanks. Andrei
Jan 31 2011
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:
 But seriously, I find it hard to believe that you can buy enterprise 
 support for D if it means that you do the work.  There's only one you.  
 So at some point, you might be spread too thin between adding new 
 features, posting to this newsgroup, and supporting all enterprise 
 customers.

If I need help, there are lots of people in this n.g. who'd be willing to take a paid gig.
 Any estimate you can give on how many such customers you have?

Not many.
Jan 31 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 The fact that the final specification and design rationale of D is 
 undocumented and in Walter's head means that no other person can sell 
 that kind of deep enterprise support because it's not clear how the 
 language should work.

Oh rubbish. C++ was highly successful in the enterprise for 15 years before it got a formal specification.
 The rest of us can only guess. It also means that 
 the more Walter spends time on enterprise support, the less he has time 
 to work on D. The best for D might be to not buy any support at all. All 
 the conferences and events are just distracting D's development.

More nonsense. Supporting users, etc., keeps me current on what the real problems and needs are.
 I think the same applies to Phobos 2.. only Andrei knows the design well 
 enough and knows how it's going to change in the future. No matter how 
 much time one spends studying D or the ecosystem or how D is used in the 
 enterprise world, one simply can't obtain any reasonable level of 
 knowledge to become a "certified" authority in this community.

Official "certs" in the software biz are bullsh*t. I've never seen much of any correspondence between certs and competency.
 About the enterprise support... I haven't seen any material from Walter 
 targeting professional D developers, only advertisements for people who 
 have never used D. Maybe the hardcore stuff isn't publicly available.

If you mean slick brochures and Tom Hopkins trained pitches, no, that's not what I do. I help people who ask for services.
Jan 31 2011
prev sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Trass3r Wrote:

 I've chosen to only work with D1/Tango from start, and I simply don't
 recognize the frustration many are feeling. I'm only concerned over
 that there ARE quite a few developers that seems to have been turned
 off by instability, and the Phobos/Tango-problem.

Well, if nobody acted as a guinea pig, no issues would be uncovered ;) And though I already encountered several blocker bugs myself I got the feeling that the situation has become way better. Of course if, for some reason, you absolutely need x64 or have a hard deadline for your project then D1 is probably the better way to go.

Andrei put for the question once of, "How many issues would users run across if they stuck to those features that are also available in v1.0?" I think the answer would be more then sticking with a D1 compiler, but not nearly the number people do hit, which is also diminishing rapidly. I do not think there is an issue with using D2 in a new project, but if you have to ask you probably should go with D1. I say this because someone who is aware of the issues present in the language is able to decide if their desired project would be hindered by the bug. There are definitely some projects, with constraints which would not make D a very good choice. For example D would make a great language on an embedded device, but currently the first one to take it on will have a massive overhead to make it work.
Jan 31 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 26 Jan 2011 14:54:06 -0500, Fab <fab-coding web.de> wrote:

 Thank you for your answer.

 But is there also a productive IDE for 'the daily use'?
 I'm used to code Delphi and there is also everything in the IDE I need  
 to code
 full featured applications.
 I don't need a GUI-Designer (but it would be nice - maybe something like  
 the
 QT-Designer) but a IDE which supports graphical debugging is vital for  
 me.

There are several projects in progress for D IDEs, at various levels of maturity, including one that integrates D into visual studio. http://prowiki.org/wiki4d/wiki.cgi?EditorSupport Note, you may be able to find answers to other questions on the D wiki. -Steve
Jan 26 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 26 Jan 2011 15:11:06 -0500, Nick Sabalausky <a a.a> wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.vpxkvij9eav7ka steve-laptop...
 On Wed, 26 Jan 2011 14:25:10 -0500, Fab <fab-coding web.de> wrote:

 Are there any continued database projects?

AFAIK, there is very little DB support (which will definitely need to be addressed before D is considered a complete language) for D2. However, you *always* have support via C bindings. D has zero-overhead binding to C functions, all you need to do is port the declarations to D. If you are using D1, there are several projects, I don't think many of them are up to date: http://prowiki.org/wiki4d/wiki.cgi?DatabaseBindings

Adam Ruppe and Piotr Szturmaj have recently been working on some database stuff. See the recent thread "Can your programming language do this?"

I have ignored that thread (I sometimes just ignore threads because they start out uninteresting, or become uninteresting, and then I miss out on some good stuff!) I'll have to take a look, D2 really does need a DB interface -- badly.
 I would say it is not ready for prime-time yet.  It has a way to go, but
 some have managed to build pretty impressive applications from it.  So  
 it
 would depend on your application.

Personally, I think that even though D still has some things to be worked out, I think it's *still* far better than any of the other more mature languages.

It all seems really good until you hit an issue that cannot be worked around -- like a compiler error or a misdesigned feature. I call these 'mercy' problems, because you are then at the complete mercy of someone else. If you have a deadline, or have a complete stoppage in work, you really have little choice but to move onto another language or abandon the project. Dcollections sat idle for about a year because of a problem like this. That would scare the crap out of me if I was a project manager trying to decide whether to use D or not. I've had first hand experience with using a product (from Microsoft) that failed so badly that we needed to have them fix it (which of course took about 3 months). A year later, they discontinued the product, and we had even more problems. I wrote my own system to replace it from scratch, and everything works so much better now (and uses less memory!). Not to mention, we have all source, so it's always possible to fix. A small part of it is written in D1/Tango and performs beautifully :) But I'd probably not rewrite the server in D (currently in C#) because it's lacking too much support for a lot of the things I do with it. I'd suggest to anyone looking to use D for something really big to try and "prove" out how well D will perform for you by coding up bits of your whole project that you think will be needed. Hopefully, you can do everything without hitting a mercy bug and then you can write your full project in it. There are also really scary possibilities that I've seen happen to a few poor souls -- like hard-to-solve OPTLINK bugs. Those may creep up at any time. Really, I just feel that D2's tools are not mature enough, or have enough support to trust a professional product on it -- yet. I'm sure this will change in the future. BTW, I plan to write a semi-professional project in D2 in the near future, but I'm 1) willing to take the risks 2) have no deadline and 3) not depending on this project for a living. -Steve
Jan 26 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
 and I want to use D for scholastic use -
 drawing plots, calculating functions, ... and so on.

Well nothing can beat Matlab for quick plots n stuff. (Speaking of which, of course you can write plugins for it with D: https://bitbucket.org/trass3r/matd)
 You see: I want to use D for private and for scholastic purposes.

D's just fine for private stuff :)
Jan 26 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
 But is there also a productive IDE for 'the daily use'?

I still use Descent for Eclipse. It isn't maintained anymore but it's the only one with a copy of the dmd frontend with some semantic analysis. VisualD on Windows provides some basic auto-completion and goto definition etc via compiler generated json files.
 I don't need a GUI-Designer (but it would be nice - maybe something like  
 the QT-Designer)

I think QtD supports the Qt GUI Designer.
 but a IDE which supports graphical debugging is vital for me

Then you should use VisualD on Windows. It includes cv2pdb which makes it possible to debug D apps with VisualStudio without much pain.
Jan 26 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
 Yeah, ditto for QuantLibD. I just spent too much time on a test project  
 trying to isolate dmd and phobos bugs to submit something meaningful to  
 bugzilla and too little time coding. Not to mention that sometimes it  
 was really hard to know what the language *should* do because of  
 outdated documentation. But maybe the storm has passed and I should try  
 serious work in D again?

I also ran into serious issues with cl4d that forced me to leave it alone several times. There even was a nasty bug with a corrupt stack frame, luckily it disappeared after some more coding and refactoring. But all in all I have the feeling that the situation has improved. Some serious forward reference bugs were fixed and I could more or less finish my work by now.
Jan 26 2011
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Wed, 26 Jan 2011 14:39:08 -0500, Steven Schveighoffer wrote:

 I will warn you, once you start using D, you will not want to use
 something else.  I cringe every day when I have to use PHP for work.

Nice trolling.
Jan 27 2011
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Wed, 26 Jan 2011 15:35:19 -0500, Steven Schveighoffer wrote:

 I'd suggest to anyone looking to use D for something really big to try
 and "prove" out how well D will perform for you by coding up bits of
 your whole project that you think will be needed.  Hopefully, you can do
 everything without hitting a mercy bug and then you can write your full
 project in it.

I think this reveals a lot about D. You still need to prove things. Or maybe the community members in general aren't very good developers; they can't see the potential of this language. The fact is, no matter what language you choose, if it isn't a complete joke, you can finish the project. (I'm assuming the community members here won't be writing any massive projects which are not possible to do in C++ or PHP or Java.) I don't see any need to prove how well Haskell works. Even though it's a "avoid success at all costs" experimental research language. It just works. I mean to the extent that I'm willing to go with these silly test projects that try to prove something.
Jan 27 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 27 Jan 2011 04:50:32 -0500, retard <re tard.com.invalid> wrote:

 Wed, 26 Jan 2011 14:39:08 -0500, Steven Schveighoffer wrote:

 I will warn you, once you start using D, you will not want to use
 something else.  I cringe every day when I have to use PHP for work.

Nice trolling.

*shrug* call it whatever you want, it's true for me, and probably most everyone here. -Steve
Jan 28 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 27 Jan 2011 04:59:18 -0500, retard <re tard.com.invalid> wrote:

 Wed, 26 Jan 2011 15:35:19 -0500, Steven Schveighoffer wrote:

 I'd suggest to anyone looking to use D for something really big to try
 and "prove" out how well D will perform for you by coding up bits of
 your whole project that you think will be needed.  Hopefully, you can do
 everything without hitting a mercy bug and then you can write your full
 project in it.

I think this reveals a lot about D. You still need to prove things. Or maybe the community members in general aren't very good developers; they can't see the potential of this language. The fact is, no matter what language you choose, if it isn't a complete joke, you can finish the project. (I'm assuming the community members here won't be writing any massive projects which are not possible to do in C++ or PHP or Java.)

I fully see the potential of the language, but I've also experienced that a one (or two or three) man compiler team does not fix bugs on *my* schedule. I can't buy "enterprise" support, so any bugs I may hit, I'm just going to have to wait for Walter and Co. to get around to them. Not a problem for me, because I'm not developing with D professionally. But if I was going to base a software company on D, I'd be very nervous at this prospect. I find that I can work around many of D's bugs, but there are just some that you have to throw your hands up and wait (I don't have time to learn how a compiler works, and fix D's compiler). I think as D matures and hopefully gets more enterprise support, these problems will be history.
 I don't see any need to prove how well Haskell works. Even though it's a
 "avoid success at all costs" experimental research language. It just
 works. I mean to the extent that I'm willing to go with these silly test
 projects that try to prove something.

The statements I made are not a property of D, they are a property of the lack of backing/maturity. I'm sure when Haskell was at the same maturity stage as D, and if it had no financial backing/support contracts, it would be just as much of a gamble. You seem to think that D is inherently flawed because of D, but it's simply too young for some tasks. It's rapidly getting older, and I think in a year or two it will be mature enough for most projects. -Steve
Jan 28 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 28, 2011 17:16:54 Walter Bright wrote:
 Steven Schveighoffer wrote:
 I can't buy "enterprise" support,

Of course you can!

Well, since Scotty hasn't been born yet, it's probably a bit premature... ;) - Jonathan M Davis
Jan 28 2011
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 28 Jan 2011 10:14:04 -0500, Steven Schveighoffer wrote:

 On Thu, 27 Jan 2011 04:59:18 -0500, retard <re tard.com.invalid> wrote:
 
 Wed, 26 Jan 2011 15:35:19 -0500, Steven Schveighoffer wrote:

 I'd suggest to anyone looking to use D for something really big to try
 and "prove" out how well D will perform for you by coding up bits of
 your whole project that you think will be needed.  Hopefully, you can
 do everything without hitting a mercy bug and then you can write your
 full project in it.

I think this reveals a lot about D. You still need to prove things. Or maybe the community members in general aren't very good developers; they can't see the potential of this language. The fact is, no matter what language you choose, if it isn't a complete joke, you can finish the project. (I'm assuming the community members here won't be writing any massive projects which are not possible to do in C++ or PHP or Java.)

I fully see the potential of the language, but I've also experienced that a one (or two or three) man compiler team does not fix bugs on *my* schedule. I can't buy "enterprise" support, so any bugs I may hit, I'm just going to have to wait for Walter and Co. to get around to them. Not a problem for me, because I'm not developing with D professionally.

I agree.
 But if I was going to base a software company on D, I'd be very nervous
 at this prospect.

Exactly.
 
 I think as D matures
 and hopefully gets more enterprise support, these problems will be
 history.

This is the classic chicken or the egg problem. I'm not trying to be unnecessarily mean. Enterprise support is something you desperately need. Consider dsource, wiki4d, d's bugzilla etc. It's amazing how much 3rd party money and effort affects the development. Luckily many things are also free nowadays such as github.
 
 I don't see any need to prove how well Haskell works. Even though it's
 a "avoid success at all costs" experimental research language. It just
 works. I mean to the extent that I'm willing to go with these silly
 test projects that try to prove something.

The statements I made are not a property of D, they are a property of the lack of backing/maturity. I'm sure when Haskell was at the same maturity stage as D, and if it had no financial backing/support contracts, it would be just as much of a gamble.

But Haskell developers have uninterruptedly received funding during the years.
 You seem to think that D is inherently flawed because of D, but it's
 simply too young for some tasks.  It's rapidly getting older, and I
 think in a year or two it will be mature enough for most projects.

I've heard this before. I've also heard the 64-bit port and many other things are done in a year/month or two. The fact is, you're overly optimistic and these are all bullshit. When I come back here in a year or two, I have full justification to laugh at your stupid claims.
Jan 28 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 28 Jan 2011 16:25:49 -0500, retard <re tard.com.invalid> wrote:

 Fri, 28 Jan 2011 10:14:04 -0500, Steven Schveighoffer wrote:
 I think as D matures
 and hopefully gets more enterprise support, these problems will be
 history.

This is the classic chicken or the egg problem. I'm not trying to be unnecessarily mean. Enterprise support is something you desperately need. Consider dsource, wiki4d, d's bugzilla etc. It's amazing how much 3rd party money and effort affects the development. Luckily many things are also free nowadays such as github.

I'd say the last 1-2 years have been extremely productive compared to the previous years combined. I feel like the growth has been better than linear. I'm not saying enterprise support is waiting in the wings for D to be "fully mature", and it might take someone developing a for-sale compiler to get to that point. But even without that kind of support, I expect that usable stability in dmd will come about sooner rather than later.
 The statements I made are not a property of D, they are a property of
 the lack of backing/maturity.  I'm sure when Haskell was at the same
 maturity stage as D, and if it had no financial backing/support
 contracts, it would be just as much of a gamble.

But Haskell developers have uninterruptedly received funding during the years.

If I understand you correctly, that's not what I'm talking about. I'm talking about a company who *uses* haskell being able to go to a haskell-supplier company and say "I want you guys to guarantee you will fix any bugs we encounter." If that's what you mean, then I stand corrected, but then that makes Haskell not a good comparison here...
 You seem to think that D is inherently flawed because of D, but it's
 simply too young for some tasks.  It's rapidly getting older, and I
 think in a year or two it will be mature enough for most projects.

I've heard this before. I've also heard the 64-bit port and many other things are done in a year/month or two. The fact is, you're overly optimistic and these are all bullshit. When I come back here in a year or two, I have full justification to laugh at your stupid claims.

Open-source development takes time, and is hard to predict, because typically it comes from free time, which isn't guaranteed. Because it's hard to predict doesn't mean a) "it's all bullshit", b) it doesn't make progress, and c) it will never succeed. In two years if you come back here and laugh at me, I will again shake my head in pity that you care so much about such things. I gave me best estimate, and maybe I'm off. We aren't on trial here, or having lives depend on us. You need to find a more constructive outlet for your pessimism. Well, it would be nice if it was simply on another newsgroup. -Steve
Jan 31 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Steven Schveighoffer wrote:
 I can't buy "enterprise" support,

Of course you can!

No really, I can't afford it ;) But seriously, I find it hard to believe that you can buy enterprise support for D if it means that you do the work. There's only one you. So at some point, you might be spread too thin between adding new features, posting to this newsgroup, and supporting all enterprise customers. Any estimate you can give on how many such customers you have? -Steve
Jan 31 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Steven Schveighoffer <schveiguy yahoo.com> wrote:

 On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright  
 <newshound2 digitalmars.com> wrote:

 Steven Schveighoffer wrote:
 I can't buy "enterprise" support,

Of course you can!

No really, I can't afford it ;) But seriously, I find it hard to believe that you can buy enterprise support for D if it means that you do the work. There's only one you. So at some point, you might be spread too thin between adding new features, posting to this newsgroup, and supporting all enterprise customers.

Even if that is the case, Walter is free to hire others to do the enterprise work for him. -- Simen
Jan 31 2011
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/1/28 retard <re tard.com.invalid>:
 I've heard this before. I've also heard the 64-bit port and many other
 things are done in a year/month or two. The fact is, you're overly
 optimistic and these are all bullshit. When I come back here in a year or
 two, I have full justification to laugh at your stupid claims.

run on 64-bit, but I'm sure GDC will work as well. The LDC-port for D2 may be untested though, and I do not know about GDC, but personally, I think it's a mistake to recommend D2 "for new projects". Given the importance of compilers, runtime and base-libraries, and the kind of bug-reports I hear frustration around, it seems D2 should still be considered beta, but for people who want working development now, recommend D1. In all it's inferiority, it IS more stable. My guess is much frustration in the D community stems from slightly pre-maturely trying to push D2, before neither D1 nor D2 was ready. I've chosen to only work with D1/Tango from start, and I simply don't recognize the frustration many are feeling. I'm only concerned over that there ARE quite a few developers that seems to have been turned off by instability, and the Phobos/Tango-problem. Well, well. I'm generally a happy D-developer, and I only hope D3 won't be started until D2 is rock-stable, and fully utilized. :)
Jan 31 2011
prev sibling next sibling parent reply Trass3r <un known.com> writes:
 I've chosen to only work with D1/Tango from start, and I simply don't
 recognize the frustration many are feeling. I'm only concerned over
 that there ARE quite a few developers that seems to have been turned
 off by instability, and the Phobos/Tango-problem.

Well, if nobody acted as a guinea pig, no issues would be uncovered ;) And though I already encountered several blocker bugs myself I got the feeling that the situation has become way better. Of course if, for some reason, you absolutely need x64 or have a hard deadline for your project then D1 is probably the better way to go.
Jan 31 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, January 31, 2011 11:31:29 Jesse Phillips wrote:
 Trass3r Wrote:
 I've chosen to only work with D1/Tango from start, and I simply don't
 recognize the frustration many are feeling. I'm only concerned over
 that there ARE quite a few developers that seems to have been turned
 off by instability, and the Phobos/Tango-problem.

Well, if nobody acted as a guinea pig, no issues would be uncovered ;) And though I already encountered several blocker bugs myself I got the feeling that the situation has become way better. Of course if, for some reason, you absolutely need x64 or have a hard deadline for your project then D1 is probably the better way to go.

Andrei put for the question once of, "How many issues would users run across if they stuck to those features that are also available in v1.0?" I think the answer would be more then sticking with a D1 compiler, but not nearly the number people do hit, which is also diminishing rapidly. I do not think there is an issue with using D2 in a new project, but if you have to ask you probably should go with D1. I say this because someone who is aware of the issues present in the language is able to decide if their desired project would be hindered by the bug. There are definitely some projects, with constraints which would not make D a very good choice. For example D would make a great language on an embedded device, but currently the first one to take it on will have a massive overhead to make it work.

Personally, I find that it's issues such as not being able to link C or C++ code compiled by Microsoft's compiler with code compiled by dmd which would stop be me from being able to use D in projects at work. The stability of the compiler is an issue, but the linker issue totally kills it before the stability issue would even come up. Pretty much everything I work on at work has to run on both Linux and Windows (and soon Mac OS X), and we use Microsoft's compiler here, so D could would _have_ to be able to link with code compiled by Microsoft's compiler. The issue of D1 or D2 is completely irrelevant. Now, if you could use a compiler other than dmd (maybe gdc would work - I don't know), then maybe then it would become a possibility, and then you have the question of D1 or D2, but if the linking issue isn't solved one way or another, then it doesn't matter. I'm sure that the situation is not as grim at all companies, but it definitely is where I work. - Jonathan M Davis
Jan 31 2011
prev sibling parent retard <re tard.com.invalid> writes:
Mon, 31 Jan 2011 11:53:34 -0800, Jonathan M Davis wrote:

 On Monday, January 31, 2011 11:31:29 Jesse Phillips wrote:
 Trass3r Wrote:
 I've chosen to only work with D1/Tango from start, and I simply
 don't recognize the frustration many are feeling. I'm only
 concerned over that there ARE quite a few developers that seems to
 have been turned off by instability, and the Phobos/Tango-problem.

Well, if nobody acted as a guinea pig, no issues would be uncovered ;) And though I already encountered several blocker bugs myself I got the feeling that the situation has become way better. Of course if, for some reason, you absolutely need x64 or have a hard deadline for your project then D1 is probably the better way to go.

Andrei put for the question once of, "How many issues would users run across if they stuck to those features that are also available in v1.0?" I think the answer would be more then sticking with a D1 compiler, but not nearly the number people do hit, which is also diminishing rapidly. I do not think there is an issue with using D2 in a new project, but if you have to ask you probably should go with D1. I say this because someone who is aware of the issues present in the language is able to decide if their desired project would be hindered by the bug. There are definitely some projects, with constraints which would not make D a very good choice. For example D would make a great language on an embedded device, but currently the first one to take it on will have a massive overhead to make it work.

Personally, I find that it's issues such as not being able to link C or C++ code compiled by Microsoft's compiler with code compiled by dmd which would stop be me from being able to use D in projects at work. The stability of the compiler is an issue, but the linker issue totally kills it before the stability issue would even come up. Pretty much everything I work on at work has to run on both Linux and Windows (and soon Mac OS X), and we use Microsoft's compiler here, so D could would _have_ to be able to link with code compiled by Microsoft's compiler. The issue of D1 or D2 is completely irrelevant.

I don't do Windows development, but not being able to use popular third party development tools because of object file format issues sounds like a huge problem. I did a quick look at the digitalmars site. The limitation is only mentioned once in the FAQ section. A competent programmer might also discover that by reading the optlink page. Also no mention of the quality of D2 toolchain. "1.030 stable", "1.066 latest", and mysterious "2.051". I would assume it's stable. But like Ulrik said "the kind of bug-reports I hear frustration around, it seems D2 should still be considered beta"
Jan 31 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 31 Jan 2011 12:26:56 -0500, Simen kjaeraas  
<simen.kjaras gmail.com> wrote:

 Steven Schveighoffer <schveiguy yahoo.com> wrote:

 On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright  
 <newshound2 digitalmars.com> wrote:

 Steven Schveighoffer wrote:
 I can't buy "enterprise" support,

Of course you can!

No really, I can't afford it ;) But seriously, I find it hard to believe that you can buy enterprise support for D if it means that you do the work. There's only one you. So at some point, you might be spread too thin between adding new features, posting to this newsgroup, and supporting all enterprise customers.

Even if that is the case, Walter is free to hire others to do the enterprise work for him.

Again, there's only one Walter. Throwing warm bodies at a problem doesn't always solve it ;) I for one would have a hard time being a full-time enterprise support developer for compiler software. That being said, he does work at a compiler company, so I suppose he probably has better access to compiler-savvy folks... -Steve
Jan 31 2011
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/1/31 Jesse Phillips <jessekphillips+D gmail.com>:
 I do not think there is an issue with using D2 in a new project, but if y=

ho is aware of the issues present in the language is able to decide if thei= r desired project would be hindered by the bug. I completely agree with this, but that important "if" is not conveyed by the recommendation "D version 2 which is recommended for new projects." :) I think it's not as much a problem of actual problems, as a problem of wrong expectations. Anyhow, D1 is a great language. D2 looks to be an ever better language and from what I hear rapidly stabilizing. The only reason I brought this up (after days of questioning if it's even worth mentioning), is hoping to avoid the same problems when D3 arrives.
Jan 31 2011
prev sibling parent retard <re tard.com.invalid> writes:
Mon, 31 Jan 2011 11:43:37 -0500, Steven Schveighoffer wrote:

 On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright
 <newshound2 digitalmars.com> wrote:
 
 Steven Schveighoffer wrote:
 I can't buy "enterprise" support,

Of course you can!

No really, I can't afford it ;) But seriously, I find it hard to believe that you can buy enterprise support for D if it means that you do the work. There's only one you. So at some point, you might be spread too thin between adding new features, posting to this newsgroup, and supporting all enterprise customers. Any estimate you can give on how many such customers you have?

The fact that the final specification and design rationale of D is undocumented and in Walter's head means that no other person can sell that kind of deep enterprise support because it's not clear how the language should work. The rest of us can only guess. It also means that the more Walter spends time on enterprise support, the less he has time to work on D. The best for D might be to not buy any support at all. All the conferences and events are just distracting D's development. I think the same applies to Phobos 2.. only Andrei knows the design well enough and knows how it's going to change in the future. No matter how much time one spends studying D or the ecosystem or how D is used in the enterprise world, one simply can't obtain any reasonable level of knowledge to become a "certified" authority in this community. About the enterprise support... I haven't seen any material from Walter targeting professional D developers, only advertisements for people who have never used D. Maybe the hardcore stuff isn't publicly available. The commercial language consultancy support I've seen is that consultants with 20+ years of enterprise "C++ experience" teach young developers with only ~1-5 years of enterprise experience with the platform. Typically even the fresh juniors have some experience with the platform (via university training) and the in-house seniors with 3+ years of experience help them to get more familiar with the platform used in the company. It's also very rare to only focus on the language, usually the frameworks and toolchain are the major culprits. YMMV of course and the world is full of all kinds of bullshit consultancy.
Jan 31 2011
prev sibling next sibling parent reply Trass3r <un known.com> writes:
 But a few month ago I've got a book about D as a present

Nice, the word is spreading.
 So - is there any reason to change to D? I would ... I really would  
 change
 if there were more points than a nice language.

 I don't buy a good car if it's too expensive

But once you had a test drive, you just can't get out anymore.
Jan 26 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Trass3r wrote:
 But once you had a test drive, you just can't get out anymore.

I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it.
Jan 26 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/11 4:09 PM, Walter Bright wrote:
 Trass3r wrote:
 But once you had a test drive, you just can't get out anymore.

I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it.

As much as I cringe when I see http://d.puremagic.com/issues/show_bug.cgi?id=5493 Andrei
Jan 26 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:ihq66j$2llc$1 digitalmars.com...
 Trass3r wrote:
 But once you had a test drive, you just can't get out anymore.

I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it.

Heh, D is programmer crack :) I use Haxe a lot and it's by no means a bad langauge overall, as far as languages go. Beats the snot out of PHP and ActionScript. But I frequently find myself cursing at it for not being able to handle things that I take for granted in D. Heck, just the other day I was going nuts because I had 5 objects that I needed to do some common trivial setup to, and there was *no* way to do it in a loop. No change I made ever "stuck" - it was as if the objects forgot they were reference types. Nothing worked. At least a full half-hour later, maybe a full hour, I ended up just copy-pasting the same damn code 5 times, once for each object. In D, I would have stuck them all in an array, typed "foreach...", and been done in under a minute.
Jan 26 2011
prev sibling next sibling parent Mafi <mafi example.org> writes:
Am 27.01.2011 01:41, schrieb spir:
 On 01/26/2011 11:33 PM, Trass3r wrote:
 For me, D's killer features were string handling (slicing and
 appending/concatenation) and *no header files*. (No more header files!!
 Yay!!!). But auto is fantastic too though, I get sooo much use out of
 that.

Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list.

Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. Denis

Mafi
Jan 27 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/27/2011 01:24 PM, Mafi wrote:
 Am 27.01.2011 01:41, schrieb spir:
 On 01/26/2011 11:33 PM, Trass3r wrote:
 For me, D's killer features were string handling (slicing and
 appending/concatenation) and *no header files*. (No more header files!!
 Yay!!!). But auto is fantastic too though, I get sooo much use out of
 that.

Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list.

Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. Denis


Yes, that's it. Denis -- _________________ vita es estrany spir.wikidot.com
Jan 27 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 I also got brainwashed by the C++ advocates years ago. However, I didn't 
 need D to see how terrible writing C++ is. C++ sure is a powerful 
 language and sometimes a necessary evil, but you don't really need very 
 strong doses of more recent languages to see how much nicer everything 
 else is.

What D unique shows is, however, that one can do C++ like things without the C++ issues, in other words, the problems C++ has are not necessary in order to get the powerful things C++ can do.
Jan 27 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/27/11 1:26 PM, Walter Bright wrote:
 retard wrote:
 I also got brainwashed by the C++ advocates years ago. However, I
 didn't need D to see how terrible writing C++ is. C++ sure is a
 powerful language and sometimes a necessary evil, but you don't really
 need very strong doses of more recent languages to see how much nicer
 everything else is.

What D unique shows is, however, that one can do C++ like things without the C++ issues, in other words, the problems C++ has are not necessary in order to get the powerful things C++ can do.

Well put. BTW I'm glad to see retard back in action. A small debate of bearophile about bounds checking and whatnot, Bruno doing his monthly bulk answering to posts, retard being down on D... it all starts looking like a good day on digitalmars.D :o). Andrei
Jan 27 2011
prev sibling parent darenw <darenw darenscotwilson.com> writes:
"the problems C++ has are not necessary in order to get
the powerful things C++ can do."

That thought makes me happy!
Jan 27 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 The main reasons were RAII and Design by 
 Contract. Even funnier, it took D about 9 years to fix the main bug in DbC 
 (contract inheritance).

The reason that took so long was that few people were using DbC effectively, so it was a low priority. I originally had high hopes that DbC would produce dramatic improvements in code quality, but the real world results were disappointing.
Jan 27 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

The reason that took so long was that few people were using DbC effectively, so
it was a low priority. I originally had high hopes that DbC would produce
dramatic improvements in code quality, but the real world results were
disappointing.<

After many years and many failed hopes, I think there is no silver bullet in programming, so maybe nothing is able to produce "dramatic improvements in code quality". But even if this is true, some things are able to improve coding a bit, like unit testing, a well semantically defined language, syntax coloring, quick compile-run cycles, OOP for certain kinds of programs, DbC, and so on. Each of such things improve the situation only a little, but such improvements pile up and most programmers when have tried them don't want to go back to miss those things. I have learnt to know and use DbC on D, and while it has not caused dramatic improvements in my code, I like to use it now and then, it has found some of the bugs in my code and more. I am appreciating D DbC enough that sometimes I miss it when I write Python code, so sometimes when I write OOP Python code, I add home-made class invariants and I call them manually from methods. In one situation this has allowed me to finish some hairy Python code in a very tight time schedule. Regading D implementation of DbC I'd like: - DMD to use a not-release build of Phobos when I compile my D code in not-release build (or some similar solution). So Phobos will be free to use asserts instead of enforce in many more situations (even if not in all situations). This will allow more inlining, allow to use "nothrow" tags more frequently, and avoid some performance problems currently present (confirmed by timings and profiling) in Phobos caused by enforces; - To see some acceptable solution for the "old" (pre-state) problem. On this there are some ideas, but I don't think there is some accepted proposal yet. This is not an indispensable feature of DbC, but it allows to increase its power and applicability significantly enough (and designers of C#4 DbC has found ways to solve this problem, so I presume there is some way to solve it in D too); - To see some Bugzilla DbC bugs removed. One or more of them is related to how const/immutable badly interacts with the result return value used by out(result){}. Bye and thank you, bearophile
Jan 27 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:
 Walter:
 
 The reason that took so long was that few people were using DbC
 effectively, so it was a low priority. I originally had high hopes that DbC
 would produce dramatic improvements in code quality, but the real world
 results were disappointing.<

After many years and many failed hopes, I think there is no silver bullet in programming, so maybe nothing is able to produce "dramatic improvements in code quality". But even if this is true, some things are able to improve coding a bit, like unit testing, a well semantically defined language, syntax coloring, quick compile-run cycles, OOP for certain kinds of programs, DbC, and so on. Each of such things improve the situation only a little, but such improvements pile up and most programmers when have tried them don't want to go back to miss those things.

Unit testing has produced a dramatic improvement in coding.
Jan 27 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Tomek Sowiński wrote:
 Walter Bright napisał:
 
 bearophile wrote:
 Walter:
 
 The reason that took so long was that few people were using DbC 
 effectively, so it was a low priority. I originally had high hopes that
 DbC would produce dramatic improvements in code quality, but the real
 world results were disappointing.<

in programming, so maybe nothing is able to produce "dramatic improvements in code quality". But even if this is true, some things are able to improve coding a bit, like unit testing, a well semantically defined language, syntax coloring, quick compile-run cycles, OOP for certain kinds of programs, DbC, and so on. Each of such things improve the situation only a little, but such improvements pile up and most programmers when have tried them don't want to go back to miss those things.


Yes, it's big. Funny that it's not really a technical change but a cultural one -- D just leaves no excuses to even the most stone-age programmers not to test their code.

I was talking about this with Andrei the other day. D's focus on making it easy to do things the right way has paid off handsomely, though this is not at all obvious from reading a feature list. It only becomes clear when you use it for a while, and then try to go back to the way you were doing things before. I think one of the reasons DbC has not paid off is it still requires a significant investment of effort by the programmer. It's too easy to not bother.
Jan 27 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/27/11 8:02 PM, Walter Bright wrote:
 Tomek Sowiński wrote:
 Walter Bright napisał:

 bearophile wrote:
 Walter:

 The reason that took so long was that few people were using DbC
 effectively, so it was a low priority. I originally had high hopes
 that
 DbC would produce dramatic improvements in code quality, but the real
 world results were disappointing.<

bullet in programming, so maybe nothing is able to produce "dramatic improvements in code quality". But even if this is true, some things are able to improve coding a bit, like unit testing, a well semantically defined language, syntax coloring, quick compile-run cycles, OOP for certain kinds of programs, DbC, and so on. Each of such things improve the situation only a little, but such improvements pile up and most programmers when have tried them don't want to go back to miss those things.


Yes, it's big. Funny that it's not really a technical change but a cultural one -- D just leaves no excuses to even the most stone-age programmers not to test their code.

I was talking about this with Andrei the other day. D's focus on making it easy to do things the right way has paid off handsomely, though this is not at all obvious from reading a feature list. It only becomes clear when you use it for a while, and then try to go back to the way you were doing things before.

Although this might as well be true, I generally try to avoid such arguments. The problem with it is it's non-falsifiable (http://en.wikipedia.org/wiki/Falsifiability) so it has a certain stench coming with it. I've seen such a claim in Go fora: you know, once you get to really use Go, you won't feel the need for generics. Meh. I try to _never_ use such an argument. If I'm to convince anyone that D rocks, it won't be by means of unfalsifiable statements. It will be by showing code that knocks your socks off. The kind of code that makes you think: "If I'm to write that in language X, I need to give away desirable traits A, B, and C. Damn!"
 I think one of the reasons DbC has not paid off is it still requires a
 significant investment of effort by the programmer. It's too easy to not
 bother.

One issue with DbC is that its only significant advantage is its interplay with inheritance. Otherwise, scope() in conjunction with assert works with less syntactic overhead. So DbC tends to shine with large and deep hierarchies... but large and deep hierarchies are not that a la mode anymore. Andrei
Jan 27 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 On 1/27/11 8:02 PM, Walter Bright wrote:
 I was talking about this with Andrei the other day. D's focus on making
 it easy to do things the right way has paid off handsomely, though this
 is not at all obvious from reading a feature list. It only becomes clear
 when you use it for a while, and then try to go back to the way you were
 doing things before.

Although this might as well be true, I generally try to avoid such arguments. The problem with it is it's non-falsifiable (http://en.wikipedia.org/wiki/Falsifiability) so it has a certain stench coming with it. I've seen such a claim in Go fora: you know, once you get to really use Go, you won't feel the need for generics. Meh. I try to _never_ use such an argument. If I'm to convince anyone that D rocks, it won't be by means of unfalsifiable statements.

I agree it's a worthless argument to use to try and convince people to give D a try. But for experienced D users, it is an interesting point.
 It will be by 
 showing code that knocks your socks off. The kind of code that makes you 
 think: "If I'm to write that in language X, I need to give away 
 desirable traits A, B, and C. Damn!"
 
 I think one of the reasons DbC has not paid off is it still requires a
 significant investment of effort by the programmer. It's too easy to not
 bother.

One issue with DbC is that its only significant advantage is its interplay with inheritance. Otherwise, scope() in conjunction with assert works with less syntactic overhead. So DbC tends to shine with large and deep hierarchies... but large and deep hierarchies are not that a la mode anymore.

Yes, you might be right.
Jan 27 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 I generally end up using unit tests to verify that stuff works correctly and
then 
 throw exceptions on bad input. So while I like having DbC built in, I don't
end 
 up using it all that much. It's prim,arily invariant that I end up using
though, 
 and that's harder to do inside of the member functions.

I think the problem here is that you are not using your D tools well enough yet: - Preconditions allow you to save some tests in your unittests, because you have less need to test many input boundary conditions. - Postconditions are useful to save some code to test the correctness of the results inside your unittests. You still need to put many tricky but correct input conditions inside your unittests, but then the postcondition will test that the outputs are inside the class of the correct outputs, and you will need less unittest code to test that the results are exactly the expected ones in some important situations. - The missing "old" feature once somehow implemented allows to remove some other unittests, because you don't need a unittest any more to test the output is generally correct given a certain class of input. - Class/struct invariants do something unittests have a hard time doing: testing the internal consistency of the class/struct data structures in all moments, and catching an inconsistency as soon as possible, this allows to catch bugs very soon, even before results reach the unittesting code. So their work is not much duplicated by unit testing. - Loop invariants can't be replaced well enough by unittests. Again, they help you find bugs very early, often no more than few lines of code later of where the bug is. Unittests are not much able to do this. - Currently you can't use invariants in some situations because of some DMD bugs. - You must look a bit forward too. If D will have some success then some person will try to write some tool to test some contracts at compile time. Compile-time testing of contracts is useful because it's the opposite of a sampling: it's like an extension of the type system, it allows you to be sure of something for all possible cases. Unit tests are useful as a sampling mean, they allow you to assert your function does exactly as expected for some specific input-output pairs. DbC doesn't perform a sampling, it tests more general properties about your inputs or outputs (and if you have some kind of implementation of the "old" feature, also general properties between inputs and their outputs), so DbC testing is wider but less deep and less specific than unit testing. Generally with unittesting you can't be sure to have covered all interesting input-output cases (code coverage tools here help but don't solve the problem. Fuzzytesting tools are able to cover other cases), while with DbC you can't be sure your general rules about correct inputs, correct outputs (or even general rules about what a correct input-output pair is) are accurate enough to catch all bad situations and computations. So generally DbC and unittests are better for different purposes, using them both you are able to complement each other weak points, and to improve your D coding. I also suggest to try to write contracts first and code later, sometimes it helps. Bye, bearophile
Jan 28 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 28.01.2011 13:30, schrieb spir:
 On 01/28/2011 12:36 PM, bearophile wrote:
 
 I think the problem here is that you are not using your D tools well enough
yet:
 - Preconditions allow you to save some tests in your unittests, because you
 have less need to test many input boundary conditions.
 - Postconditions are useful to save some code to test the correctness of the
 results inside your unittests. You still need to put many tricky but correct
 input conditions inside your unittests, but then the postcondition will test
 that the outputs are inside the class of the correct outputs, and you will
 need less unittest code to test that the results are exactly the expected ones
 in some important situations.

Very intersting points, thank you.
 - The missing "old" feature once somehow implemented allows to remove some
 other unittests, because you don't need a unittest any more to test the output
 is generally correct given a certain class of input.

What is this "old" feature?

if you've got a function fun(int x){ ... ; x++; ... } then you can use old.x (or something like that) in the dbc block at the end to access the original value of x. like assert(x == old.x+1) or something like that. after hearing about dbc in university I thought that having old was fundamental for dbc.. but D doesn't support it. Cheers, - Daniel
Jan 28 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
spir:

 What is this "old" feature?

It's a basic DbC feature that's currently missing in D because of some implementation troubles (and maybe also because Walter is a bit disappointed about DbC). Example: a class member function performs a certain computation and changes some attributes. In the postcondition you want to test that such changes are correct. To do this well it's useful to know what the original state of those attributes was. This is what the "old" feature allows you to do. Similar things are possible with free functions too. So preconditions in a function allow you to assert that general rules about inputs are fulfilled, postconditions allow you to assert that general rules about its outputs are fulfilled, and the "old" (pre-state) feature allows you to assert that general rules about its input-output pairs are fulfilled. So it's not a small thing :-) It was discussed three or more times: http://www.digitalmars.com/d/archives/digitalmars/D/why_no_old_operator_in_function_postconditions_as_in_Eiffel_54654.html http://www.digitalmars.com/d/archives/digitalmars/D/Communicating_between_in_and_out_contracts_98252.html
I definitely need a "mental jump" to think in terms of DbC; nearly never use
it, simply don't think at it.<

DbC looks like a very simple thing, but you need some time, thinking, and reading about what it is and what its purposes are, to learn to use it :-) Bye, bearophile
Jan 28 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 One issue with DbC is that its only significant advantage is its 
 interplay with inheritance. Otherwise, scope() in conjunction with 
 assert works with less syntactic overhead. So DbC tends to shine with 
 large and deep hierarchies... but large and deep hierarchies are not 
 that a la mode anymore.

Have you tried to use class invariants manually? It's easy to forget its calls, and the calls clutter the code, and are not handy to write. So I don't agree. Bye, bearophile
Jan 27 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 27 January 2011 19:29:59 Walter Bright wrote:
 Andrei Alexandrescu wrote:
 One issue with DbC is that its only significant advantage is its
 interplay with inheritance. Otherwise, scope() in conjunction with
 assert works with less syntactic overhead. So DbC tends to shine with
 large and deep hierarchies... but large and deep hierarchies are not
 that a la mode anymore.

Yes, you might be right.

I generally end up using unit tests to verify that stuff works correctly and then throw exceptions on bad input. So while I like having DbC built in, I don't end up using it all that much. It's prim,arily invariant that I end up using though, and that's harder to do inside of the member functions. - Jonathan M Davis
Jan 27 2011
prev sibling parent reply Roman Ivanov <something example.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 On 1/27/11 8:02 PM, Walter Bright wrote:
 I think one of the reasons DbC has not paid off is it still requires a
 significant investment of effort by the programmer. It's too easy to not
 bother.

interplay with inheritance. Otherwise, scope() in conjunction with assert works with less syntactic overhead. So DbC tends to shine with large and deep hierarchies... but large and deep hierarchies are not that a la mode anymore.

DbC opens many interesting possibilities if it's supported by tools other than just the compiler. MS has included it in .NET 4.0: http://research.microsoft.com/en-us/projects/contracts/
Jan 28 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/28/11 10:14 AM, Roman Ivanov wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 On 1/27/11 8:02 PM, Walter Bright wrote:
 I think one of the reasons DbC has not paid off is it still requires a
 significant investment of effort by the programmer. It's too easy to not
 bother.

interplay with inheritance. Otherwise, scope() in conjunction with assert works with less syntactic overhead. So DbC tends to shine with large and deep hierarchies... but large and deep hierarchies are not that a la mode anymore.

DbC opens many interesting possibilities if it's supported by tools other than just the compiler. MS has included it in .NET 4.0: http://research.microsoft.com/en-us/projects/contracts/

Hm, I'm seeing in section 3 of userdoc.pdf that they don't care for precondition weakening: "While we could allow a weaker precondition, we have found that the complications of doing so outweigh the benefits. We just haven’t seen any compelling examples where weakening the precondition is useful. So we do not allow adding any preconditions at all in a subtype." They do, however, allow strenghtening postconditions. Overall the project looks very interesting and has quite recognizable names from the PL community. Hopefully it will increase awareness of contract programming. Andrei
Jan 28 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:

 Another way to look at it is that programmers are enjoying the safety
 of using regular D so much as to not even think about using DbC.

This may be a case of Risk homeostasis: http://en.wikipedia.org/wiki/Risk_homeostasis But maybe it's mostly a matter of getting used to D. Once you get used to a safer language, you want even more and something better. You want the frosting too on your cake :-) And probably D is not the end of the line in the evolution of C-derived languages. There is space for improvements, like having notnull reference types, typestates, etc. For example, it will be interesting to see where the Rust language goes. Bye, bearophile
Jan 27 2011
prev sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 01/27/2011 05:41 PM, Walter Bright wrote:
 Unit testing has produced a dramatic improvement in coding.

agreed. unit testing (maybe with dbc, I don't remember) was the only reason I noticed issue 5364.
Jan 27 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, January 26, 2011 14:09:25 Walter Bright wrote:
 Trass3r wrote:
 But once you had a test drive, you just can't get out anymore.

I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it.

LOL. Yeah. There's just so many little things that D improves on that when you're stuck in C++ land, you're constantly running into little things that you miss having or are annoyed to have to deal with. auto has probably been the biggest one for me, though slicing isn't far behind. At least auto will be in C++ 0x... I dream of the day that I'll be able to use D all of the time and not have to worry about C++ anymore. - Jonathan M Davis
Jan 26 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.973.1296080233.4748.digitalmars-d puremagic.com...
 On Wednesday, January 26, 2011 14:09:25 Walter Bright wrote:
 Trass3r wrote:
 But once you had a test drive, you just can't get out anymore.

I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it.

LOL. Yeah. There's just so many little things that D improves on that when you're stuck in C++ land, you're constantly running into little things that you miss having or are annoyed to have to deal with. auto has probably been the biggest one for me, though slicing isn't far behind. At least auto will be in C++ 0x...

For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that.
Jan 26 2011
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:ihq7a3$2o05$1 digitalmars.com...
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
 news:mailman.973.1296080233.4748.digitalmars-d puremagic.com...
 On Wednesday, January 26, 2011 14:09:25 Walter Bright wrote:
 Trass3r wrote:
 But once you had a test drive, you just can't get out anymore.

I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it.

LOL. Yeah. There's just so many little things that D improves on that when you're stuck in C++ land, you're constantly running into little things that you miss having or are annoyed to have to deal with. auto has probably been the biggest one for me, though slicing isn't far behind. At least auto will be in C++ 0x...

For me, D's killer features were string handling (slicing, appending/concatenation, ***and .length instead of null-termination***) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that.

Fixed. ^^^
Jan 26 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
 On 1/26/11 4:09 PM, Walter Bright wrote:
 Trass3r wrote:
 But once you had a test drive, you just can't get out anymore.

I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it.

As much as I cringe when I see http://d.puremagic.com/issues/show_bug.cgi?id=5493 Andrei

Well, coding in D is like being Indiana: you might run into nasty traps here and there but you just can't be a vanilla guy anymore ;)
Jan 26 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
 Trass3r wrote:
 But once you had a test drive, you just can't get out anymore.

I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it.

Yep, like being thrown back to the Stone Age.
Jan 26 2011
prev sibling next sibling parent reply Trass3r <un known.com> writes:
 For me, D's killer features were string handling (slicing and
 appending/concatenation) and *no header files*. (No more header files!!
 Yay!!!). But auto is fantastic too though, I get sooo much use out of  
 that.

Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list.
Jan 26 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, January 26, 2011 16:41:10 spir wrote:
 On 01/26/2011 11:33 PM, Trass3r wrote:
 For me, D's killer features were string handling (slicing and
 appending/concatenation) and *no header files*. (No more header files!!
 Yay!!!). But auto is fantastic too though, I get sooo much use out of
 that.

Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list.

Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that.

You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work. And if for some reason you really want to be able to just have it use $ if the index is too large, it's easy to write a wrapper function which does that. - Jonathan M Davis
Jan 26 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 27.01.2011 02:11, schrieb Jonathan M Davis:
 On Wednesday, January 26, 2011 16:41:10 spir wrote:
 On 01/26/2011 11:33 PM, Trass3r wrote:
 For me, D's killer features were string handling (slicing and
 appending/concatenation) and *no header files*. (No more header files!!
 Yay!!!). But auto is fantastic too though, I get sooo much use out of
 that.

Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list.

Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that.

You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work. And if for some reason you really want to be able to just have it use $ if the index is too large, it's easy to write a wrapper function which does that. - Jonathan M Davis

I think he wants int arr[] = int[3]; // ... int arr2[] = arr[1..5]; to be equivalent to int arr[] = int[3]; // ... int arr2[] = arr[1..$]; arr2.length = 4; Cheers, - Daniel
Jan 26 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 27.01.2011 08:10, schrieb Daniel Gibson:
 Am 27.01.2011 02:11, schrieb Jonathan M Davis:
 On Wednesday, January 26, 2011 16:41:10 spir wrote:
 On 01/26/2011 11:33 PM, Trass3r wrote:
 For me, D's killer features were string handling (slicing and
 appending/concatenation) and *no header files*. (No more header files!!
 Yay!!!). But auto is fantastic too though, I get sooo much use out of
 that.

Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list.

Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that.

You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work. And if for some reason you really want to be able to just have it use $ if the index is too large, it's easy to write a wrapper function which does that. - Jonathan M Davis

I think he wants int arr[] = int[3]; // ... int arr2[] = arr[1..5]; to be equivalent to int arr[] = int[3]; // ... int arr2[] = arr[1..$]; arr2.length = 4; Cheers, - Daniel

Okay, I just saw in spirs reply, that for some reason was not displayed in this branch of the thread but as a direct reply to the top post, that you understood him correctly and I didn't :-)
Jan 26 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
spir:

 Sorry, but you are wrong on this. I understand this sounds unsafe, but no.
Most 
 languages, I guess, just do that without any worry. In particular, I have 
 frequented python and Lua mailing lists for years without even reading once 
 about this beeing a misfeature (and indeed have never run into a bug because
of 
 this myself). It is simply the right semantics in 99.999% cases.

Thank you for raising this topic again. I have raised it probably more than one year ago, and all people around here were against this. This is not unsafe, it's actually safer than the current D behaviour. Python designers don't think this is a badly designed part of Python, they think this is as desired, and I too have never seen people complain about this being a bad or bug prone design. An example of Python code: s = "abcdefg" upper = 20 s2 = s[2 : upper] assert s2 == "cdefg" Equivalent D2 code, if you forget to use the min() you are doomed: import std.algorithm: min; void main() { string s = "abcdefg"; int upper = 20; string s2 = s[2 .. min($, upper)]; assert(s2 == "cdefg"); } The saturating nature of Python slice bounds is a safety net that's useful to avoid some troubles. The only good thing of the D2 design is that it performs less tests at runtime (it has no need to call min() in general), this is a bit positive in a system language, but in this case it has a cost in safety. Bye, bearophile
Jan 27 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 I don't think that you stand much chance of convincing a crowd using a system 
 programming language that having the compiler adjust your out of bound indices 
 to be in bounds is  good idea.

Technically here we are talking about slicing bounds, and not indexes. But you are right, there's no hope I will change minds here. On the other hand my duty is to show the ideas I believe are right/better, because I care for this language. Bye, bearophile
Jan 27 2011
prev sibling next sibling parent reply Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
 You mean that if you give an index which is too large, it just uses $
 instead?
 That sounds seriously bug-prone to me. I'd much rather that it blew up and
 thus
 told me that my program had a bug in it rather than silently trying to
 work.

Sorry, but you are wrong on this. I understand this sounds unsafe, but no. Most languages, I guess, just do that without any worry. In particular, I have frequented python and Lua mailing lists for years without even reading once about this beeing a misfeature (and indeed have never run into a bug because of this myself). It is simply the right semantics in 99.999% cases.

Isn't the real reason for this that bounds-checking is usually completely turned-off in release-builds? Sounds like something that could noticeably degrade runtime-performance for array-intensive code?
Jan 27 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Ulrik Mikaelsson:

 Isn't the real reason for this that bounds-checking is usually
 completely turned-off in release-builds?

Bounds checking is turned off in release builds mostly because: 1) DMD is not able to infer & remove most bound checks at compile-time as the latest Oracle VM are able to do; 2) and because Walter & Co. believe such analysis isn't able to remove most bound checks anyway (I have not seen this hypothesis confirmed yet).
 Sounds like something that could noticeably degrade runtime-performance
 for array-intensive code?

The safety net we are talking about is present only at the right bound of a slicing syntax (it's not performed in normal array indexing), and it consists in a single min(x, $) operation, that's one branch. So it slows down code, but only a bit. And in many of such situations you probably need to add a min(x, $) manually in the code anyway, so the overhead is limited. Bye, bearophile
Jan 27 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:

 Honestly, I think this would just encourage writing sloppy code.

I don't believe this, on the other hand I believe the current behaviour is bug-prone.
 Using min(x, $) explicitly informs the reader of the code of exactly
 what happens.

Right. The problem is that in some cases you may forget to add that min(x, $).
 It's harder to tell when it's implicit.

Slicing syntax is used all the time in both Python and D code, so the Python and D programmers learn quickly and keep in mind what it does. Implicit behaviours are a problem when they are uncommon things, or library functions, etc, much less when they are built-in safety nets you use every five lines of code :-) Not only that,
 but it can introduce bugs in your code - because while you might use
 any upper bound, you're still not allowed to index beyond the length
 of the array.

Writing hundreds of thousands of lines of Python code I've seen that the saturating semantics we are talking about is not bug-prone (in fact it avoids some bugs).
 Imagine this could was accepted by DMD:
 
 void main()
 {
     auto userArgs = ["foo"];  // runtime arguments by some user input
 
     auto firstTwo = userArgs[0..2];  // accepted by the new language change,
                                                   // implicitly
 changes 2 to min(2, $)
 
     // more code here
 
     firstTwo[1] = "test";  // oops!
 }

Programmers just quickly learn that indexes and slices have a bit different semantics. Bye, bearophile
Jan 27 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 27.01.2011 19:25, schrieb bearophile:
 
 Programmers just quickly learn that indexes and slices have a bit different
semantics.
 

And I guess this holds true for programmers used to python as well? So they should have no problem with learning to use foo = blah[i..min($,i+n)] instead of foo = blah[i..(i+n)] ;-)
 Bye,
 bearophile

Cheers, - Daniel
Jan 27 2011
prev sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 27/01/11 6:14 PM, Jonathan M Davis wrote:
 The safety net we are talking about is present only at the right bound of a
 slicing syntax (it's not performed in normal array indexing), and it
 consists in a single min(x, $) operation, that's one branch. So it slows
 down code, but only a bit. And in many of such situations you probably
 need to add a min(x, $) manually in the code anyway, so the overhead is
 limited.

Personally, I have _never_ needed to add a min call like that. So, while _you_ may think that it's a common thing to do (and it may be that it is in your code), that doesn't mean that that's generally true. - Jonathan M Davis

I agree. I've never needed to add a bounds check like that.
Jan 29 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Peter Alexander:

 I agree. I've never needed to add a bounds check like that.

While my string processing D code contains many of them :-) I presume I am thinking in Python there. Bye, bearophile
Jan 29 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Honestly, I think this would just encourage writing sloppy code.

Using min(x, $) explicitly informs the reader of the code of exactly
what happens. It's harder to tell when it's implicit. Not only that,
but it can introduce bugs in your code - because while you might use
any upper bound, you're still not allowed to index beyond the length
of the array. Imagine this could was accepted by DMD:

void main()
{
    auto userArgs = ["foo"];  // runtime arguments by some user input

    auto firstTwo = userArgs[0..2];  // accepted by the new language change,
                                                  // implicitly
changes 2 to min(2, $)

    // more code here

    firstTwo[1] = "test";  // oops!
}
Jan 27 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
This *code* was accepted, not *could*.
Jan 27 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/27/11, bearophile <bearophileHUGS lycos.com> wrote:
 Programmers just quickly learn that indexes and slices have a bit different
 semantics.

Right, programmers can easily adapt to slightly different semantics in related areas of the language, I mean C++ is known for being very easy to learn for exactly that reason. (Sarcasm alert!).
Jan 27 2011
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Wed, 26 Jan 2011 14:09:25 -0800, Walter Bright wrote:

 Trass3r wrote:
 But once you had a test drive, you just can't get out anymore.

I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it.

I also got brainwashed by the C++ advocates years ago. However, I didn't need D to see how terrible writing C++ is. C++ sure is a powerful language and sometimes a necessary evil, but you don't really need very strong doses of more recent languages to see how much nicer everything else is.
Jan 27 2011
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Wed, 26 Jan 2011 23:33:54 +0100, Trass3r wrote:

 For me, D's killer features were string handling (slicing and
 appending/concatenation) and *no header files*. (No more header files!!
 Yay!!!). But auto is fantastic too though, I get sooo much use out of
 that.

Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list.

Yep, those were to reasons that lured me to learn Java. However, those were not the reasons to learn D. The main reasons were RAII and Design by Contract. Even funnier, it took D about 9 years to fix the main bug in DbC (contract inheritance).
Jan 27 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/28/11, Walter Bright <newshound2 digitalmars.com> wrote:
 I think one of the reasons DbC has not paid off is it still requires a
 significant investment of effort by the programmer. It's too easy to not
 bother.

Another way to look at it is that programmers are enjoying the safety of using regular D so much as to not even think about using DbC. The language does guarantee a lot more than C++. The irony here is that C++ is the one that desperately needs integrated DbC, and yet D, the safer language, is the one providing DbC for free. :p In other words, we get the candy and the cake.
Jan 27 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 27 Jan 2011 21:37:31 -0500, Ellery Newcomer  
<ellery-newcomer utulsa.edu> wrote:

 On 01/27/2011 05:41 PM, Walter Bright wrote:
 Unit testing has produced a dramatic improvement in coding.

agreed. unit testing (maybe with dbc, I don't remember) was the only reason I noticed issue 5364.

I created 4 or 5 bugs against dmd when I added full unit tests to dcollections. So unittests also help D probably as much as they do your code ;) -Steve
Jan 28 2011
prev sibling parent retard <re tard.com.invalid> writes:
Fri, 28 Jan 2011 16:14:27 +0000, Roman Ivanov wrote:

 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
 article
 On 1/27/11 8:02 PM, Walter Bright wrote:
 I think one of the reasons DbC has not paid off is it still requires
 a significant investment of effort by the programmer. It's too easy
 to not bother.

interplay with inheritance. Otherwise, scope() in conjunction with assert works with less syntactic overhead. So DbC tends to shine with large and deep hierarchies... but large and deep hierarchies are not that a la mode anymore.

DbC opens many interesting possibilities if it's supported by tools other than just the compiler. MS has included it in .NET 4.0: http://research.microsoft.com/en-us/projects/contracts/

Mono 2.8 also seems to support those: http://www.mono-project.com/news/archive/2010/Oct-06.html
Jan 28 2011
prev sibling next sibling parent Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
Steven Schveighoffer napisa=B3:

 Adam Ruppe and Piotr Szturmaj have recently been working on some databa=


 stuff. See the recent thread "Can your programming language do this?"

I have ignored that thread (I sometimes just ignore threads because they =

 start out uninteresting, or become uninteresting, and then I miss out on =

 some good stuff!)
=20
 I'll have to take a look, D2 really does need a DB interface -- badly.

That and networking. I can help with the latter as I had done a bit of netw= ork devving, but I don't know what's the current state of affairs (sb worki= ng on it already?) and whether Phobos needs another soul on-board.
 I would say it is not ready for prime-time yet.  It has a way to go, b=



 some have managed to build pretty impressive applications from it.  So=



 it
 would depend on your application.

Personally, I think that even though D still has some things to be work=


 out, I think it's *still* far better than any of the other more mature
 languages.

It all seems really good until you hit an issue that cannot be worked =20 around -- like a compiler error or a misdesigned feature. I call these =

 'mercy' problems, because you are then at the complete mercy of someone =

 else.  If you have a deadline, or have a complete stoppage in work, you =

 really have little choice but to move onto another language or abandon th=

 project.  Dcollections sat idle for about a year because of a problem lik=

 this.

Yeah, ditto for QuantLibD. I just spent too much time on a test project try= ing to isolate dmd and phobos bugs to submit something meaningful to bugzil= la and too little time coding. Not to mention that sometimes it was really = hard to know what the language *should* do because of outdated documentatio= n. But maybe the storm has passed and I should try serious work in D again?
 [snip]
=20
 BTW, I plan to write a semi-professional project in D2 in the near future=

 but I'm 1) willing to take the risks 2) have no deadline and 3) not =20
 depending on this project for a living.

Sheer curiosity: what will the project be about? --=20 Tomek
Jan 26 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/26/2011 11:33 PM, Trass3r wrote:
 For me, D's killer features were string handling (slicing and
 appending/concatenation) and *no header files*. (No more header files!!
 Yay!!!). But auto is fantastic too though, I get sooo much use out of that.

Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list.

Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. Denis -- _________________ vita es estrany spir.wikidot.com
Jan 26 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/27/2011 02:11 AM, Jonathan M Davis wrote:
 On Wednesday, January 26, 2011 16:41:10 spir wrote:
 On 01/26/2011 11:33 PM, Trass3r wrote:
 For me, D's killer features were string handling (slicing and
 appending/concatenation) and *no header files*. (No more header files!!
 Yay!!!). But auto is fantastic too though, I get sooo much use out of
 that.

Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list.

Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that.

You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work.

Sorry, but you are wrong on this. I understand this sounds unsafe, but no. Most languages, I guess, just do that without any worry. In particular, I have frequented python and Lua mailing lists for years without even reading once about this beeing a misfeature (and indeed have never run into a bug because of this myself). It is simply the right semantics in 99.999% cases. spir d:~$ python Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information.
 s = 'abc'
 s[0:123456789]



spir d:~$ lua Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
 require"io"
 s = "abc"
 print(string.sub(s, 1, 123456789))

I'm constantly annoyed by D's behaviour. For instance, often have to write out the end of a string from a given point, but only at most n chars (to avoid cluttering the output, indeed): writeln(s[i..i+n]); which fails if there are less than n remaining chars ;-) Denis -- _________________ vita es estrany spir.wikidot.com
Jan 26 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday 26 January 2011 17:52:19 spir wrote:
 On 01/27/2011 02:11 AM, Jonathan M Davis wrote:
 On Wednesday, January 26, 2011 16:41:10 spir wrote:
 On 01/26/2011 11:33 PM, Trass3r wrote:
 For me, D's killer features were string handling (slicing and
 appending/concatenation) and *no header files*. (No more header
 files!! Yay!!!). But auto is fantastic too though, I get sooo much
 use out of that.

Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list.

Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that.

You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work.

Sorry, but you are wrong on this. I understand this sounds unsafe, but no. Most languages, I guess, just do that without any worry. In particular, I have frequented python and Lua mailing lists for years without even reading once about this beeing a misfeature (and indeed have never run into a bug because of this myself). It is simply the right semantics in 99.999% cases. spir d:~$ python Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information.
 s = 'abc'
 s[0:123456789]



'abc' spir d:~$ lua Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
 require"io"
 s = "abc"
 print(string.sub(s, 1, 123456789))

abc I'm constantly annoyed by D's behaviour. For instance, often have to write out the end of a string from a given point, but only at most n chars (to avoid cluttering the output, indeed): writeln(s[i..i+n]); which fails if there are less than n remaining chars ;-)

I _rarely_ see cases where I would consider it okay to give an index for the end of an array and having that index be too large is a good thing. It invariably means that your algorithm is wrong. In my experience, if you really need to know what the size of your array is and handle it properly. There _are_ cases where you say that you want "the rest" of the array or collection and don't care how much that is, but in cases where you're actually looking to specify the index, if the index is wrong, then the code is wrong. Now, I suppose that there are cases where you could simplify an algorithm where you effectively be n or less (if there aren't n elements left). But that's definitely atypical in my experience, and writing a wrapper function for such a case is trivial. Generally speaking, I'd be very worried about code which was lax enough about indices to not care whether it was indexing passed the end of the array or not. Clearly, if you think that not being strict about indices is a good idea, you're either dealing with very different circumstances than I have and/or you're coding very differently. Regardless, since it's trivial to create a wrapper that does what you want, I don't think that there's any reason to change how slicing works. - Jonathan M Davis
Jan 26 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday 26 January 2011 19:06:37 Jonathan M Davis wrote:
 On Wednesday 26 January 2011 17:52:19 spir wrote:
 On 01/27/2011 02:11 AM, Jonathan M Davis wrote:
 On Wednesday, January 26, 2011 16:41:10 spir wrote:
 On 01/26/2011 11:33 PM, Trass3r wrote:
 For me, D's killer features were string handling (slicing and
 appending/concatenation) and *no header files*. (No more header
 files!! Yay!!!). But auto is fantastic too though, I get sooo much
 use out of that.

Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list.

Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that.

You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work.

Sorry, but you are wrong on this. I understand this sounds unsafe, but no. Most languages, I guess, just do that without any worry. In particular, I have frequented python and Lua mailing lists for years without even reading once about this beeing a misfeature (and indeed have never run into a bug because of this myself). It is simply the right semantics in 99.999% cases. spir d:~$ python Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information.
 s = 'abc'
 s[0:123456789]



'abc' spir d:~$ lua Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
 require"io"
 s = "abc"
 print(string.sub(s, 1, 123456789))

abc I'm constantly annoyed by D's behaviour. For instance, often have to write out the end of a string from a given point, but only at most n chars (to avoid cluttering the output, indeed): writeln(s[i..i+n]); which fails if there are less than n remaining chars ;-)

I _rarely_ see cases where I would consider it okay to give an index for the end of an array and having that index be too large is a good thing. It invariably means that your algorithm is wrong. In my experience, if you really need to know what the size of your array is and handle it properly. There _are_ cases where you say that you want "the rest" of the array or collection and don't care how much that is, but in cases where you're actually looking to specify the index, if the index is wrong, then the code is wrong. Now, I suppose that there are cases where you could simplify an algorithm where you effectively be n or less (if there aren't n elements left). But that's definitely atypical in my experience, and writing a wrapper function for such a case is trivial. Generally speaking, I'd be very worried about code which was lax enough about indices to not care whether it was indexing passed the end of the array or not. Clearly, if you think that not being strict about indices is a good idea, you're either dealing with very different circumstances than I have and/or you're coding very differently. Regardless, since it's trivial to create a wrapper that does what you want, I don't think that there's any reason to change how slicing works.

I should probably add that it's more efficient to have the built-in slicing facilities be exact and build inexact ones on top of that then it is to make them inexact and the build exact ones on top. When you get down to it, you _have_ to slice _exactly_ when you get down deep enough in the code. So, making the slicing then be exact on top of that doesn't really cost anything. But adding the extra checks to make the inexact one work adds extra cost. So, while that's fine if the inexact behavior is what you want, it's _not_ fine if it's the exact behavior that you want, since then unnecessary checks are happening in the middle. For efficiency reasons, the exact behavior _needs_ to be the default. exact -> low level exact and inexact -> exact -> low level exact works as efficiently as is possible. Whereas having inexact -> low level exact and exact -> inexact -> low level exact is _not_ efficient. - Jonathan M Davis
Jan 26 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/27/2011 04:06 AM, Jonathan M Davis wrote:
 Clearly, if you think that not being strict about indices is a good idea,
you're
 either dealing with very different circumstances than I have and/or you're
coding
 very differently. Regardless, since it's trivial to create a wrapper that does
 what you want, I don't think that there's any reason to change how slicing
 works.

I would agree with you be reasoning "in pure air" (I mean without having used both semantic versions). But concrete experience (of a huge number of programmers) in widely used programming languages demonstrate the opposite. Slice /upper/ bound checking is an idea that looks good in theory but is not in practice. Denis -- _________________ vita es estrany spir.wikidot.com
Jan 27 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, January 27, 2011 01:34:04 bearophile wrote:
 spir:
 Sorry, but you are wrong on this. I understand this sounds unsafe, but
 no. Most languages, I guess, just do that without any worry. In
 particular, I have frequented python and Lua mailing lists for years
 without even reading once about this beeing a misfeature (and indeed
 have never run into a bug because of this myself). It is simply the
 right semantics in 99.999% cases.

Thank you for raising this topic again. I have raised it probably more than one year ago, and all people around here were against this. This is not unsafe, it's actually safer than the current D behaviour. Python designers don't think this is a badly designed part of Python, they think this is as desired, and I too have never seen people complain about this being a bad or bug prone design. An example of Python code: s = "abcdefg" upper = 20 s2 = s[2 : upper] assert s2 == "cdefg" Equivalent D2 code, if you forget to use the min() you are doomed: import std.algorithm: min; void main() { string s = "abcdefg"; int upper = 20; string s2 = s[2 .. min($, upper)]; assert(s2 == "cdefg"); } The saturating nature of Python slice bounds is a safety net that's useful to avoid some troubles. The only good thing of the D2 design is that it performs less tests at runtime (it has no need to call min() in general), this is a bit positive in a system language, but in this case it has a cost in safety.

I don't think that you stand much chance of convincing a crowd using a system programming language that having the compiler adjust your out of bound indices to be in bounds is good idea. While it may be a great idea in some circumstances, it generally smacks of lax programming. And since it makes slicing more expensive, it would be a feature that would definitely need to pull its weight. And I don't see how it possibly could. It's trivial to add a function which will return a slice which is laxly sliced in the manner that you're looking for. And using min as you're showing isn't exactly hard. Yes, you may get bugs when porting code from Python, but I don't think that porting Python code has ever been one of the major concerns of D's language design. Really, it's the silently breaking stuff when porting C and C++ code which has been the concern. What we have is efficient, and I expect that most people around here think that it's the correct solution. If you want lax slicing, it's easy to get by using min or a wrapper function. So, I see no reason to make any language changes - not to mention it would likely conflict with TDPL to make such a change. - Jonathan M Davis
Jan 27 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, January 27, 2011 09:47:44 bearophile wrote:
 Ulrik Mikaelsson:
 Isn't the real reason for this that bounds-checking is usually
 completely turned-off in release-builds?

Bounds checking is turned off in release builds mostly because: 1) DMD is not able to infer & remove most bound checks at compile-time as the latest Oracle VM are able to do; 2) and because Walter & Co. believe such analysis isn't able to remove most bound checks anyway (I have not seen this hypothesis confirmed yet).
 Sounds like something that could noticeably degrade runtime-performance
 for array-intensive code?

The safety net we are talking about is present only at the right bound of a slicing syntax (it's not performed in normal array indexing), and it consists in a single min(x, $) operation, that's one branch. So it slows down code, but only a bit. And in many of such situations you probably need to add a min(x, $) manually in the code anyway, so the overhead is limited.

Personally, I have _never_ needed to add a min call like that. So, while _you_ may think that it's a common thing to do (and it may be that it is in your code), that doesn't mean that that's generally true. - Jonathan M Davis
Jan 27 2011
prev sibling next sibling parent Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
Walter Bright napisa=B3:

 bearophile wrote:
 Walter:
=20
 The reason that took so long was that few people were using DbC
 effectively, so it was a low priority. I originally had high hopes tha=



 would produce dramatic improvements in code quality, but the real world
 results were disappointing.<

After many years and many failed hopes, I think there is no silver bull=


 programming, so maybe nothing is able to produce "dramatic improvements=


 code quality".
=20
 But even if this is true, some things are able to improve coding a bit,=


 unit testing, a well semantically defined language, syntax coloring, qu=


 compile-run cycles, OOP for certain kinds of programs, DbC, and so on. =


 of such things improve the situation only a little, but such improvemen=


 pile up and most programmers when have tried them don't want to go back=


 miss those things.

Unit testing has produced a dramatic improvement in coding.

Yes, it's big. Funny that it's not really a technical change but a cultural= one -- D just leaves no excuses to even the most stone-age programmers not= to test their code. --=20 Tomek
Jan 27 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/28/2011 12:36 PM, bearophile wrote:

 I think the problem here is that you are not using your D tools well enough
yet:
 - Preconditions allow you to save some tests in your unittests, because you
have less need to test many input boundary conditions.
 - Postconditions are useful to save some code to test the correctness of the
results inside your unittests. You still need to put many tricky but correct
input conditions inside your unittests, but then the postcondition will test
that the outputs are inside the class of the correct outputs, and you will need
less unittest code to test that the results are exactly the expected ones in
some important situations.

Very intersting points, thank you.
 - The missing "old" feature once somehow implemented allows to remove some
other unittests, because you don't need a unittest any more to test the output
is generally correct given a certain class of input.

What is this "old" feature?
 Generally with unittesting you can't be sure to have covered all interesting
input-output cases (code coverage tools here help but don't solve the problem.
Fuzzytesting tools are able to cover other cases), while with DbC you can't be
sure your general rules about correct inputs, correct outputs (or even general
rules about what a correct input-output pair is) are accurate enough to catch
all bad situations and computations.

 So generally DbC and unittests are better for different purposes, using them
both you are able to complement each other weak points, and to improve your D
coding.

Ditto. I definitely need a "mental jump" to think in terms of DbC; nearly never use it, simply don't think at it.
 I also suggest to try to write contracts first and code later, sometimes it
helps.

Just what I sometimes do for tests ;-) Denis -- _________________ vita es estrany spir.wikidot.com
Jan 28 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Although I don't find the original post to be a troll, (despite the 
title), I could not resist poking some fun...


---- Still Alive? ----

This was a triumph!
I'm making a note here: "HUGE SUCCESS!!"

It's hard to overstate, my satisfaction.

D programming Language:
We do what we must, because we can.

For the good of all of us.
Except the ones who are dead.

But there's no sense crying, over every mistake.
You just keep on trying, till you run out of code.
And the desiderata gets achieved.
And you make a neat module, for the people who are, still alive.

I'm not even angry...
I'm being so sincere right now-
Even though you broke my compiler, and killed me.
And tore the linker to pieces.
And threw every piece into a fire.
As they burned it hurt because, I was so happy for you!

Now, these points of data, make a beautiful line.
And we're out of beta. We're releasing on time!
So I'm GLaD I got burned-
Think of all the things we learned-
for the people who are, still alive.


Go ahead and leave me...
I think I'd prefer to stay inside...
Maybe you'll find someone else, to help you?
Maybe the Go Language?
THAT WAS A JOKE! HAHA - FAT CHANCE.

Anyway this code is great!
It's so delicious and moist!

Look at me: still talking, when there's science to do!
When I look out there, it makes me GLaD I'm not you.

I've experiments to run.
There is research to be done.
On the people who are, still alive.
And believe me I am, still alive.
I'm doing science and I'm, still alive.
I feel fantastic and I'm, still alive.
While you're dying I'll be, still alive.
And when you're dead I will be, still alive.

-- 
Bruno Medeiros - Software Engineer
Feb 04 2011