Discussion:
Is D still alive?
(too old to reply)
Fab
2011-01-26 19:25:10 UTC
Permalink
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.
Steven Schveighoffer
2011-01-26 19:39:08 UTC
Permalink
Post by Fab
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).
Post by Fab
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
Post by Fab
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
Post by Fab
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
Steven Schveighoffer
2011-01-26 19:40:11 UTC
Permalink
On Wed, 26 Jan 2011 14:39:08 -0500, Steven Schveighoffer
Post by Steven Schveighoffer
Post by Fab
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
Fab
2011-01-26 19:54:06 UTC
Permalink
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.
Fab
2011-01-26 20:12:43 UTC
Permalink
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.
Nick Sabalausky
2011-01-26 20:32:54 UTC
Permalink
"Fab" <fab-coding at web.de> wrote in message
Post by Fab
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.
Trass3r
2011-01-26 21:03:55 UTC
Permalink
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 :)
Steven Schveighoffer
2011-01-26 20:11:53 UTC
Permalink
Post by Fab
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
Nick Sabalausky
2011-01-26 20:16:03 UTC
Permalink
"Fab" <fab-coding at web.de> wrote in message
Post by Fab
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).
Trass3r
2011-01-26 21:11:29 UTC
Permalink
Post by Fab
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.
Post by Fab
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.
Post by Fab
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.
Nick Sabalausky
2011-01-26 20:11:06 UTC
Permalink
"Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message
Post by Steven Schveighoffer
Post by Fab
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
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?"
Post by Steven Schveighoffer
Post by Fab
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 :)
Post by Steven Schveighoffer
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.
Steven Schveighoffer
2011-01-26 20:35:19 UTC
Permalink
Post by Nick Sabalausky
"Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message
Post by Steven Schveighoffer
Post by Fab
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
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.
Post by Nick Sabalausky
Post by Steven Schveighoffer
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
Tomek Sowiński
2011-01-26 23:16:12 UTC
Permalink
Post by Steven Schveighoffer
Post by Nick Sabalausky
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.
That and networking. I can help with the latter as I had done a bit of network devving, but I don't know what's the current state of affairs (sb working on it already?) and whether Phobos needs another soul on-board.
Post by Steven Schveighoffer
Post by Nick Sabalausky
Post by Steven Schveighoffer
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.
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?
Post by Steven Schveighoffer
[snip]
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.
Sheer curiosity: what will the project be about?
--
Tomek
Trass3r
2011-01-26 23:36:16 UTC
Permalink
Post by Tomek Sowiński
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.
retard
2011-01-27 09:59:18 UTC
Permalink
Post by Steven Schveighoffer
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.
Trass3r
2011-01-27 12:06:29 UTC
Permalink
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.
Steven Schveighoffer
2011-01-28 15:14:04 UTC
Permalink
Post by retard
Post by Steven Schveighoffer
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.
Post by retard
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
retard
2011-01-28 21:25:49 UTC
Permalink
Post by Steven Schveighoffer
Post by retard
Post by Steven Schveighoffer
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.
Post by Steven Schveighoffer
But if I was going to base a software company on D, I'd be very nervous
at this prospect.
Exactly.
Post by Steven Schveighoffer
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.
Post by Steven Schveighoffer
Post by retard
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.
Post by Steven Schveighoffer
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.
Andrei Alexandrescu
2011-01-28 22:04:52 UTC
Permalink
Post by retard
Post by Steven Schveighoffer
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.
Post by Steven Schveighoffer
Post by retard
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.
Post by retard
Post by Steven Schveighoffer
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
Steven Schveighoffer
2011-01-31 16:40:59 UTC
Permalink
Post by retard
Post by Steven Schveighoffer
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.
Post by retard
Post by Steven Schveighoffer
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...
Post by retard
Post by Steven Schveighoffer
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
Ulrik Mikaelsson
2011-01-31 18:06:37 UTC
Permalink
Post by retard
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.
64-bit port for D (at least v1) IS available. I use LDC to build and
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. :)
Trass3r
2011-01-31 18:55:41 UTC
Permalink
Post by Ulrik Mikaelsson
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.
Jesse Phillips
2011-01-31 19:31:29 UTC
Permalink
Post by Trass3r
Post by Ulrik Mikaelsson
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.
Ulrik Mikaelsson
2011-01-31 19:44:43 UTC
Permalink
Post by Jesse Phillips
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.
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.
Jonathan M Davis
2011-01-31 19:53:34 UTC
Permalink
Post by Jesse Phillips
Post by Trass3r
Post by Ulrik Mikaelsson
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
retard
2011-01-31 20:26:22 UTC
Permalink
Post by Jonathan M Davis
Post by Jesse Phillips
Post by Trass3r
Post by Ulrik Mikaelsson
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"
Walter Bright
2011-01-29 01:16:54 UTC
Permalink
Post by Steven Schveighoffer
I can't buy "enterprise" support,
Of course you can!
Jonathan M Davis
2011-01-29 01:32:19 UTC
Permalink
Post by Walter Bright
Post by Steven Schveighoffer
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
Walter Bright
2011-01-29 04:48:22 UTC
Permalink
Post by Jonathan M Davis
Post by Walter Bright
Post by Steven Schveighoffer
I can't buy "enterprise" support,
Of course you can!
Well, since Scotty hasn't been born yet, it's probably a bit premature... ;)
She canna take the power!
Steven Schveighoffer
2011-01-31 16:43:37 UTC
Permalink
On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright
Post by Walter Bright
Post by Steven Schveighoffer
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
Simen kjaeraas
2011-01-31 17:26:56 UTC
Permalink
Post by Steven Schveighoffer
On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright
Post by Walter Bright
Post by Steven Schveighoffer
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
Steven Schveighoffer
2011-01-31 19:24:38 UTC
Permalink
On Mon, 31 Jan 2011 12:26:56 -0500, Simen kjaeraas
Post by Simen kjaeraas
Post by Steven Schveighoffer
On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright
Post by Walter Bright
Post by Steven Schveighoffer
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
retard
2011-01-31 19:52:03 UTC
Permalink
Post by Steven Schveighoffer
On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright
Post by Walter Bright
Post by Steven Schveighoffer
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.
Andrei Alexandrescu
2011-01-31 20:51:38 UTC
Permalink
Post by retard
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 at 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
Walter Bright
2011-01-31 22:12:56 UTC
Permalink
Post by retard
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.
Post by retard
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.
Post by retard
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.
Post by retard
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.
Walter Bright
2011-01-31 21:59:20 UTC
Permalink
Post by Steven Schveighoffer
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.
Post by Steven Schveighoffer
Any estimate you can give on how many such customers you have?
Not many.
retard
2011-01-27 09:50:32 UTC
Permalink
Post by Steven Schveighoffer
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.
Steven Schveighoffer
2011-01-28 15:02:55 UTC
Permalink
Post by retard
Post by Steven Schveighoffer
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
Trass3r
2011-01-26 21:44:31 UTC
Permalink
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.
Walter Bright
2011-01-26 22:09:25 UTC
Permalink
Post by Trass3r
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.
Andrei Alexandrescu
2011-01-26 22:11:06 UTC
Permalink
Post by Walter Bright
Post by Trass3r
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
Trass3r
2011-01-26 22:25:25 UTC
Permalink
Post by Andrei Alexandrescu
Post by Walter Bright
Post by Trass3r
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 ;)
Jonathan M Davis
2011-01-26 22:19:06 UTC
Permalink
Post by Walter Bright
Post by Trass3r
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
Nick Sabalausky
2011-01-26 22:22:59 UTC
Permalink
"Walter Bright" <newshound2 at digitalmars.com> wrote in message
Post by Walter Bright
Post by Trass3r
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.
Nick Sabalausky
2011-01-26 22:28:48 UTC
Permalink
"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
Post by Jonathan M Davis
Post by Walter Bright
Post by Trass3r
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.
Nick Sabalausky
2011-01-26 22:31:15 UTC
Permalink
"Nick Sabalausky" <a at a.a> wrote in message
Post by Nick Sabalausky
"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
Post by Jonathan M Davis
Post by Walter Bright
Post by Trass3r
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. ^^^
Trass3r
2011-01-26 22:33:54 UTC
Permalink
Post by Nick Sabalausky
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.
spir
2011-01-27 00:41:10 UTC
Permalink
Post by Nick Sabalausky
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
Jonathan M Davis
2011-01-27 01:11:08 UTC
Permalink
Post by spir
Post by Trass3r
Post by Nick Sabalausky
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
spir
2011-01-27 01:52:19 UTC
Permalink
Post by Jonathan M Davis
Post by spir
Post by Trass3r
Post by Nick Sabalausky
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 at 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.
Post by Jonathan M Davis
Post by spir
Post by Trass3r
s = 'abc'
s[0:123456789]
'abc'

spir at d:~$ lua
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
Post by Jonathan M Davis
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 ;-)

Denis
--
_________________
vita es estrany
spir.wikidot.com
Jonathan M Davis
2011-01-27 03:06:37 UTC
Permalink
Post by spir
Post by Jonathan M Davis
Post by spir
Post by Trass3r
Post by Nick Sabalausky
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 at 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.
Post by Jonathan M Davis
Post by spir
Post by Trass3r
s = 'abc'
s[0:123456789]
'abc'
spir at d:~$ lua
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
Post by Jonathan M Davis
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
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
Jonathan M Davis
2011-01-27 04:05:06 UTC
Permalink
Post by Jonathan M Davis
Post by spir
Post by Jonathan M Davis
Post by spir
Post by Trass3r
Post by Nick Sabalausky
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 at 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.
Post by Jonathan M Davis
Post by spir
Post by Trass3r
s = 'abc'
s[0:123456789]
'abc'
spir at d:~$ lua
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
Post by Jonathan M Davis
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
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
spir
2011-01-27 13:54:11 UTC
Permalink
Post by Jonathan M Davis
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
Ulrik Mikaelsson
2011-01-27 17:29:22 UTC
Permalink
Post by spir
Post by Jonathan M Davis
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?
bearophile
2011-01-27 17:47:44 UTC
Permalink
Post by 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).
Post by Ulrik Mikaelsson
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
Andrej Mitrovic
2011-01-27 18:09:50 UTC
Permalink
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!
}
Andrej Mitrovic
2011-01-27 18:25:04 UTC
Permalink
This *code* was accepted, not *could*.
Jonathan M Davis
2011-01-27 18:14:43 UTC
Permalink
Post by bearophile
Post by Ulrik Mikaelsson
Isn't the real reason for this that bounds-checking is usually
completely turned-off in release-builds?
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).
Post by Ulrik Mikaelsson
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
bearophile
2011-01-27 18:25:14 UTC
Permalink
Post by 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.
Post by Andrej Mitrovic
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, $).
Post by Andrej Mitrovic
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,
Post by Andrej Mitrovic
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).
Post by Andrej Mitrovic
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
Andrej Mitrovic
2011-01-27 18:31:18 UTC
Permalink
Post by bearophile
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!).
Daniel Gibson
2011-01-27 18:35:06 UTC
Permalink
Post by 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)] ;-)
Post by bearophile
Bye,
bearophile
Cheers,
- Daniel
Peter Alexander
2011-01-29 11:58:30 UTC
Permalink
Post by Jonathan M Davis
Post by bearophile
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.
bearophile
2011-01-29 13:08:11 UTC
Permalink
Post by 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
bearophile
2011-01-27 09:34:04 UTC
Permalink
Post by 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
Jonathan M Davis
2011-01-27 18:09:05 UTC
Permalink
Post by bearophile
Post by 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.
s = "abcdefg"
upper = 20
s2 = s[2 : upper]
assert s2 == "cdefg"
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
bearophile
2011-01-27 18:28:33 UTC
Permalink
Post by 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
Daniel Gibson
2011-01-27 07:10:07 UTC
Permalink
Post by Jonathan M Davis
Post by spir
Post by Trass3r
Post by Nick Sabalausky
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
Daniel Gibson
2011-01-27 07:14:04 UTC
Permalink
Post by Daniel Gibson
Post by Jonathan M Davis
Post by spir
Post by Trass3r
Post by Nick Sabalausky
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 :-)
retard
2011-01-27 10:10:19 UTC
Permalink
Post by Trass3r
Post by Nick Sabalausky
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).
Walter Bright
2011-01-27 19:40:50 UTC
Permalink
Post by retard
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.
bearophile
2011-01-27 21:27:57 UTC
Permalink
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
Walter Bright
2011-01-27 23:41:52 UTC
Permalink
Post by bearophile
Post by Walter Bright
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.
Tomek Sowiński
2011-01-27 23:50:56 UTC
Permalink
Post by Walter Bright
Post by bearophile
Post by Walter Bright
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.
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.
--
Tomek
Walter Bright
2011-01-28 02:02:51 UTC
Permalink
Post by Tomek Sowiński
Post by Walter Bright
Post by bearophile
Post by Walter Bright
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.
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.
Andrej Mitrovic
2011-01-28 02:24:39 UTC
Permalink
Post by Walter Bright
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.
Andrei Alexandrescu
2011-01-28 02:34:01 UTC
Permalink
Post by Walter Bright
Post by Tomek Sowiński
Post by Walter Bright
Post by bearophile
Post by Walter Bright
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.
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!"
Post by Walter Bright
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
Walter Bright
2011-01-28 03:29:59 UTC
Permalink
Post by Andrei Alexandrescu
Post by Walter Bright
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.
Post by Andrei Alexandrescu
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!"
Post by Walter Bright
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.
Jonathan M Davis
2011-01-28 03:48:01 UTC
Permalink
Post by Walter Bright
Post by Andrei Alexandrescu
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
bearophile
2011-01-28 11:36:15 UTC
Permalink
Post by 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
spir
2011-01-28 12:30:51 UTC
Permalink
Post by bearophile
- 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.
Post by bearophile
- 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?
Post by bearophile
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.
Post by bearophile
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
Daniel Gibson
2011-01-28 12:37:35 UTC
Permalink
Post by spir
Post by bearophile
- 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.
Post by bearophile
- 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
bearophile
2011-01-28 12:57:28 UTC
Permalink
Post by 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
Post by spir
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
bearophile
2011-01-28 03:47:52 UTC
Permalink
Post by Andrei Alexandrescu
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
Roman Ivanov
2011-01-28 16:14:27 UTC
Permalink
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
Post by Andrei Alexandrescu
Post by Walter Bright
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.
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/
Andrei Alexandrescu
2011-01-28 18:02:35 UTC
Permalink
Post by Roman Ivanov
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
Post by Andrei Alexandrescu
Post by Walter Bright
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.
DbC opens many interesting possibilities if it's supported by tools other than
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
retard
2011-01-28 21:45:18 UTC
Permalink
Post by Roman Ivanov
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
Post by Andrei Alexandrescu
Post by Walter Bright
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.
DbC opens many interesting possibilities if it's supported by tools
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
bearophile
2011-01-28 03:26:41 UTC
Permalink
Post by 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
Ellery Newcomer
2011-01-28 02:37:31 UTC
Permalink
Post by Walter Bright
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.
Steven Schveighoffer
2011-01-28 15:19:14 UTC
Permalink
On Thu, 27 Jan 2011 21:37:31 -0500, Ellery Newcomer
Post by Ellery Newcomer
Post by Walter Bright
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
Mafi
2011-01-27 12:24:06 UTC
Permalink
Post by spir
Post by Trass3r
Post by Nick Sabalausky
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
What about a[1.. min(x, $)]. (min from std.alorithm)?

Mafi
spir
2011-01-27 14:00:25 UTC
Permalink
Post by Mafi
Post by spir
Post by Trass3r
Post by Nick Sabalausky
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
What about a[1.. min(x, $)]. (min from std.alorithm)?
Yes, that's it.

Denis
--
_________________
vita es estrany
spir.wikidot.com
Trass3r
2011-01-26 22:28:52 UTC
Permalink
Post by Walter Bright
Post by Trass3r
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.
retard
2011-01-27 10:05:00 UTC
Permalink
Post by Walter Bright
Post by Trass3r
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.
Walter Bright
2011-01-27 19:26:48 UTC
Permalink
Post by retard
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.
Andrei Alexandrescu
2011-01-27 19:49:27 UTC
Permalink
Post by Walter Bright
Post by retard
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
darenw
2011-01-28 04:50:19 UTC
Permalink
"the problems C++ has are not necessary in order to get
the powerful things C++ can do."

That thought makes me happy!
Bruno Medeiros
2011-02-04 17:12:36 UTC
Permalink
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
Continue reading on narkive:
Loading...