Re: Is D still alive?
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
Re: Is D still alive?
On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright newshou...@digitalmars.com wrote: Steven Schveighoffer wrote: I can't buy enterprise support, Of course you can! No really, I can't afford it ;) But seriously, I find it hard to believe that you can buy enterprise support for D if it means that you do the work. There's only one you. So at some point, you might be spread too thin between adding new features, posting to this newsgroup, and supporting all enterprise customers. Any estimate you can give on how many such customers you have? -Steve
Re: Is D still alive?
On Fri, 28 Jan 2011 16:25:49 -0500, retard r...@tard.com.invalid wrote: Fri, 28 Jan 2011 10:14:04 -0500, Steven Schveighoffer wrote: I think as D matures and hopefully gets more enterprise support, these problems will be history. This is the classic chicken or the egg problem. I'm not trying to be unnecessarily mean. Enterprise support is something you desperately need. Consider dsource, wiki4d, d's bugzilla etc. It's amazing how much 3rd party money and effort affects the development. Luckily many things are also free nowadays such as github. I'd say the last 1-2 years have been extremely productive compared to the previous years combined. I feel like the growth has been better than linear. I'm not saying enterprise support is waiting in the wings for D to be fully mature, and it might take someone developing a for-sale compiler to get to that point. But even without that kind of support, I expect that usable stability in dmd will come about sooner rather than later. The statements I made are not a property of D, they are a property of the lack of backing/maturity. I'm sure when Haskell was at the same maturity stage as D, and if it had no financial backing/support contracts, it would be just as much of a gamble. But Haskell developers have uninterruptedly received funding during the years. If I understand you correctly, that's not what I'm talking about. I'm talking about a company who *uses* haskell being able to go to a haskell-supplier company and say I want you guys to guarantee you will fix any bugs we encounter. If that's what you mean, then I stand corrected, but then that makes Haskell not a good comparison here... You seem to think that D is inherently flawed because of D, but it's simply too young for some tasks. It's rapidly getting older, and I think in a year or two it will be mature enough for most projects. I've heard this before. I've also heard the 64-bit port and many other things are done in a year/month or two. The fact is, you're overly optimistic and these are all bullshit. When I come back here in a year or two, I have full justification to laugh at your stupid claims. Open-source development takes time, and is hard to predict, because typically it comes from free time, which isn't guaranteed. Because it's hard to predict doesn't mean a) it's all bullshit, b) it doesn't make progress, and c) it will never succeed. In two years if you come back here and laugh at me, I will again shake my head in pity that you care so much about such things. I gave me best estimate, and maybe I'm off. We aren't on trial here, or having lives depend on us. You need to find a more constructive outlet for your pessimism. Well, it would be nice if it was simply on another newsgroup. -Steve
Re: Is D still alive?
Steven Schveighoffer schvei...@yahoo.com wrote: On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright newshou...@digitalmars.com wrote: Steven Schveighoffer wrote: I can't buy enterprise support, Of course you can! No really, I can't afford it ;) But seriously, I find it hard to believe that you can buy enterprise support for D if it means that you do the work. There's only one you. So at some point, you might be spread too thin between adding new features, posting to this newsgroup, and supporting all enterprise customers. Even if that is the case, Walter is free to hire others to do the enterprise work for him. -- Simen
Re: Is D still alive?
2011/1/28 retard r...@tard.com.invalid: I've heard this before. I've also heard the 64-bit port and many other things are done in a year/month or two. The fact is, you're overly optimistic and these are all bullshit. When I come back here in a year or two, I have full justification to laugh at your stupid claims. 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. :)
Re: Is D still alive?
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.
Re: Is D still alive?
On Mon, 31 Jan 2011 12:26:56 -0500, Simen kjaeraas simen.kja...@gmail.com wrote: Steven Schveighoffer schvei...@yahoo.com wrote: On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright newshou...@digitalmars.com wrote: Steven Schveighoffer wrote: I can't buy enterprise support, Of course you can! No really, I can't afford it ;) But seriously, I find it hard to believe that you can buy enterprise support for D if it means that you do the work. There's only one you. So at some point, you might be spread too thin between adding new features, posting to this newsgroup, and supporting all enterprise customers. Even if that is the case, Walter is free to hire others to do the enterprise work for him. Again, there's only one Walter. Throwing warm bodies at a problem doesn't always solve it ;) I for one would have a hard time being a full-time enterprise support developer for compiler software. That being said, he does work at a compiler company, so I suppose he probably has better access to compiler-savvy folks... -Steve
Re: Is D still alive?
Trass3r Wrote: I've chosen to only work with D1/Tango from start, and I simply don't recognize the frustration many are feeling. I'm only concerned over that there ARE quite a few developers that seems to have been turned off by instability, and the Phobos/Tango-problem. Well, if nobody acted as a guinea pig, no issues would be uncovered ;) And though I already encountered several blocker bugs myself I got the feeling that the situation has become way better. Of course if, for some reason, you absolutely need x64 or have a hard deadline for your project then D1 is probably the better way to go. Andrei put for the question once of, How many issues would users run across if they stuck to those features that are also available in v1.0? I think the answer would be more then sticking with a D1 compiler, but not nearly the number people do hit, which is also diminishing rapidly. I do not think there is an issue with using D2 in a new project, but if you have to ask you probably should go with D1. I say this because someone who is aware of the issues present in the language is able to decide if their desired project would be hindered by the bug. There are definitely some projects, with constraints which would not make D a very good choice. For example D would make a great language on an embedded device, but currently the first one to take it on will have a massive overhead to make it work.
Re: Is D still alive?
2011/1/31 Jesse Phillips jessekphillip...@gmail.com: 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.
Re: Is D still alive?
Mon, 31 Jan 2011 11:43:37 -0500, Steven Schveighoffer wrote: On Fri, 28 Jan 2011 20:16:54 -0500, Walter Bright newshou...@digitalmars.com wrote: Steven Schveighoffer wrote: I can't buy enterprise support, Of course you can! No really, I can't afford it ;) But seriously, I find it hard to believe that you can buy enterprise support for D if it means that you do the work. There's only one you. So at some point, you might be spread too thin between adding new features, posting to this newsgroup, and supporting all enterprise customers. Any estimate you can give on how many such customers you have? The fact that the final specification and design rationale of D is undocumented and in Walter's head means that no other person can sell that kind of deep enterprise support because it's not clear how the language should work. The rest of us can only guess. It also means that the more Walter spends time on enterprise support, the less he has time to work on D. The best for D might be to not buy any support at all. All the conferences and events are just distracting D's development. I think the same applies to Phobos 2.. only Andrei knows the design well enough and knows how it's going to change in the future. No matter how much time one spends studying D or the ecosystem or how D is used in the enterprise world, one simply can't obtain any reasonable level of knowledge to become a certified authority in this community. About the enterprise support... I haven't seen any material from Walter targeting professional D developers, only advertisements for people who have never used D. Maybe the hardcore stuff isn't publicly available. The commercial language consultancy support I've seen is that consultants with 20+ years of enterprise C++ experience teach young developers with only ~1-5 years of enterprise experience with the platform. Typically even the fresh juniors have some experience with the platform (via university training) and the in-house seniors with 3+ years of experience help them to get more familiar with the platform used in the company. It's also very rare to only focus on the language, usually the frameworks and toolchain are the major culprits. YMMV of course and the world is full of all kinds of bullshit consultancy.
Re: Is D still alive?
On Monday, January 31, 2011 11:31:29 Jesse Phillips wrote: Trass3r Wrote: I've chosen to only work with D1/Tango from start, and I simply don't recognize the frustration many are feeling. I'm only concerned over that there ARE quite a few developers that seems to have been turned off by instability, and the Phobos/Tango-problem. Well, if nobody acted as a guinea pig, no issues would be uncovered ;) And though I already encountered several blocker bugs myself I got the feeling that the situation has become way better. Of course if, for some reason, you absolutely need x64 or have a hard deadline for your project then D1 is probably the better way to go. Andrei put for the question once of, How many issues would users run across if they stuck to those features that are also available in v1.0? I think the answer would be more then sticking with a D1 compiler, but not nearly the number people do hit, which is also diminishing rapidly. I do not think there is an issue with using D2 in a new project, but if you have to ask you probably should go with D1. I say this because someone who is aware of the issues present in the language is able to decide if their desired project would be hindered by the bug. There are definitely some projects, with constraints which would not make D a very good choice. For example D would make a great language on an embedded device, but currently the first one to take it on will have a massive overhead to make it work. Personally, I find that it's issues such as not being able to link C or C++ code compiled by Microsoft's compiler with code compiled by dmd which would stop be me from being able to use D in projects at work. The stability of the compiler is an issue, but the linker issue totally kills it before the stability issue would even come up. Pretty much everything I work on at work has to run on both Linux and Windows (and soon Mac OS X), and we use Microsoft's compiler here, so D could would _have_ to be able to link with code compiled by Microsoft's compiler. The issue of D1 or D2 is completely irrelevant. Now, if you could use a compiler other than dmd (maybe gdc would work - I don't know), then maybe then it would become a possibility, and then you have the question of D1 or D2, but if the linking issue isn't solved one way or another, then it doesn't matter. I'm sure that the situation is not as grim at all companies, but it definitely is where I work. - Jonathan M Davis
Re: Is D still alive?
Mon, 31 Jan 2011 11:53:34 -0800, Jonathan M Davis wrote: On Monday, January 31, 2011 11:31:29 Jesse Phillips wrote: Trass3r Wrote: I've chosen to only work with D1/Tango from start, and I simply don't recognize the frustration many are feeling. I'm only concerned over that there ARE quite a few developers that seems to have been turned off by instability, and the Phobos/Tango-problem. Well, if nobody acted as a guinea pig, no issues would be uncovered ;) And though I already encountered several blocker bugs myself I got the feeling that the situation has become way better. Of course if, for some reason, you absolutely need x64 or have a hard deadline for your project then D1 is probably the better way to go. Andrei put for the question once of, How many issues would users run across if they stuck to those features that are also available in v1.0? I think the answer would be more then sticking with a D1 compiler, but not nearly the number people do hit, which is also diminishing rapidly. I do not think there is an issue with using D2 in a new project, but if you have to ask you probably should go with D1. I say this because someone who is aware of the issues present in the language is able to decide if their desired project would be hindered by the bug. There are definitely some projects, with constraints which would not make D a very good choice. For example D would make a great language on an embedded device, but currently the first one to take it on will have a massive overhead to make it work. Personally, I find that it's issues such as not being able to link C or C++ code compiled by Microsoft's compiler with code compiled by dmd which would stop be me from being able to use D in projects at work. The stability of the compiler is an issue, but the linker issue totally kills it before the stability issue would even come up. Pretty much everything I work on at work has to run on both Linux and Windows (and soon Mac OS X), and we use Microsoft's compiler here, so D could would _have_ to be able to link with code compiled by Microsoft's compiler. The issue of D1 or D2 is completely irrelevant. I don't do Windows development, but not being able to use popular third party development tools because of object file format issues sounds like a huge problem. I did a quick look at the digitalmars site. The limitation is only mentioned once in the FAQ section. A competent programmer might also discover that by reading the optlink page. Also no mention of the quality of D2 toolchain. 1.030 stable, 1.066 latest, and mysterious 2.051. I would assume it's stable. But like Ulrik said the kind of bug-reports I hear frustration around, it seems D2 should still be considered beta
Re: Is D still alive?
On 1/31/11 1:52 PM, retard wrote: I think the same applies to Phobos 2.. only Andrei knows the design well enough and knows how it's going to change in the future. No matter how much time one spends studying D or the ecosystem or how D is used in the enterprise world, one simply can't obtain any reasonable level of knowledge to become a certified authority in this community. People on the Phobos roster all have contributed to it, not to mention the many contributed patches via bugzilla and ideas aired in this group. Also, I have a track record of bringing ideas for future Phobos additions for discussion up here before acting on them. In the words of collection companies: What else can we do? I think I'll do something terrible: I'll killfile r...@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
Re: Is D still alive?
Steven Schveighoffer wrote: But seriously, I find it hard to believe that you can buy enterprise support for D if it means that you do the work. There's only one you. So at some point, you might be spread too thin between adding new features, posting to this newsgroup, and supporting all enterprise customers. If I need help, there are lots of people in this n.g. who'd be willing to take a paid gig. Any estimate you can give on how many such customers you have? Not many.
Re: Is D still alive?
retard wrote: The fact that the final specification and design rationale of D is undocumented and in Walter's head means that no other person can sell that kind of deep enterprise support because it's not clear how the language should work. Oh rubbish. C++ was highly successful in the enterprise for 15 years before it got a formal specification. The rest of us can only guess. It also means that the more Walter spends time on enterprise support, the less he has time to work on D. The best for D might be to not buy any support at all. All the conferences and events are just distracting D's development. More nonsense. Supporting users, etc., keeps me current on what the real problems and needs are. I think the same applies to Phobos 2.. only Andrei knows the design well enough and knows how it's going to change in the future. No matter how much time one spends studying D or the ecosystem or how D is used in the enterprise world, one simply can't obtain any reasonable level of knowledge to become a certified authority in this community. Official certs in the software biz are bullsh*t. I've never seen much of any correspondence between certs and competency. About the enterprise support... I haven't seen any material from Walter targeting professional D developers, only advertisements for people who have never used D. Maybe the hardcore stuff isn't publicly available. If you mean slick brochures and Tom Hopkins trained pitches, no, that's not what I do. I help people who ask for services.
Re: Is D still alive?
On 27/01/11 6:14 PM, Jonathan M Davis wrote: The safety net we are talking about is present only at the right bound of a slicing syntax (it's not performed in normal array indexing), and it consists in a single min(x, $) operation, that's one branch. So it slows down code, but only a bit. And in many of such situations you probably need to add a min(x, $) manually in the code anyway, so the overhead is limited. Personally, I have _never_ needed to add a min call like that. So, while _you_ may think that it's a common thing to do (and it may be that it is in your code), that doesn't mean that that's generally true. - Jonathan M Davis I agree. I've never needed to add a bounds check like that.
Re: Is D still alive?
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
Re: Is D still alive?
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
Re: Is D still alive?
On 01/28/2011 12:36 PM, bearophile wrote: I think the problem here is that you are not using your D tools well enough yet: - Preconditions allow you to save some tests in your unittests, because you have less need to test many input boundary conditions. - Postconditions are useful to save some code to test the correctness of the results inside your unittests. You still need to put many tricky but correct input conditions inside your unittests, but then the postcondition will test that the outputs are inside the class of the correct outputs, and you will need less unittest code to test that the results are exactly the expected ones in some important situations. Very intersting points, thank you. - The missing old feature once somehow implemented allows to remove some other unittests, because you don't need a unittest any more to test the output is generally correct given a certain class of input. What is this old feature? Generally with unittesting you can't be sure to have covered all interesting input-output cases (code coverage tools here help but don't solve the problem. Fuzzytesting tools are able to cover other cases), while with DbC you can't be sure your general rules about correct inputs, correct outputs (or even general rules about what a correct input-output pair is) are accurate enough to catch all bad situations and computations. So generally DbC and unittests are better for different purposes, using them both you are able to complement each other weak points, and to improve your D coding. Ditto. I definitely need a mental jump to think in terms of DbC; nearly never use it, simply don't think at it. I also suggest to try to write contracts first and code later, sometimes it helps. Just what I sometimes do for tests ;-) Denis -- _ vita es estrany spir.wikidot.com
Re: Is D still alive?
Am 28.01.2011 13:30, schrieb spir:
On 01/28/2011 12:36 PM, bearophile wrote:
I think the problem here is that you are not using your D tools well enough
yet:
- Preconditions allow you to save some tests in your unittests, because you
have less need to test many input boundary conditions.
- Postconditions are useful to save some code to test the correctness of the
results inside your unittests. You still need to put many tricky but correct
input conditions inside your unittests, but then the postcondition will test
that the outputs are inside the class of the correct outputs, and you will
need less unittest code to test that the results are exactly the expected
ones
in some important situations.
Very intersting points, thank you.
- The missing old feature once somehow implemented allows to remove some
other unittests, because you don't need a unittest any more to test the
output
is generally correct given a certain class of input.
What is this old feature?
if you've got a function fun(int x){ ... ; x++; ... }
then you can use old.x (or something like that) in the dbc block at the end to
access the original value of x.
like assert(x == old.x+1) or something like that.
after hearing about dbc in university I thought that having old was fundamental
for dbc.. but D doesn't support it.
Cheers,
- Daniel
Re: Is D still alive?
spir: What is this old feature? It's a basic DbC feature that's currently missing in D because of some implementation troubles (and maybe also because Walter is a bit disappointed about DbC). Example: a class member function performs a certain computation and changes some attributes. In the postcondition you want to test that such changes are correct. To do this well it's useful to know what the original state of those attributes was. This is what the old feature allows you to do. Similar things are possible with free functions too. So preconditions in a function allow you to assert that general rules about inputs are fulfilled, postconditions allow you to assert that general rules about its outputs are fulfilled, and the old (pre-state) feature allows you to assert that general rules about its input-output pairs are fulfilled. So it's not a small thing :-) It was discussed three or more times: http://www.digitalmars.com/d/archives/digitalmars/D/why_no_old_operator_in_function_postconditions_as_in_Eiffel_54654.html http://www.digitalmars.com/d/archives/digitalmars/D/Communicating_between_in_and_out_contracts_98252.html I definitely need a mental jump to think in terms of DbC; nearly never use it, simply don't think at it. DbC looks like a very simple thing, but you need some time, thinking, and reading about what it is and what its purposes are, to learn to use it :-) Bye, bearophile
Re: Is D still alive?
On Thu, 27 Jan 2011 04:50:32 -0500, retard r...@tard.com.invalid wrote: Wed, 26 Jan 2011 14:39:08 -0500, Steven Schveighoffer wrote: I will warn you, once you start using D, you will not want to use something else. I cringe every day when I have to use PHP for work. Nice trolling. *shrug* call it whatever you want, it's true for me, and probably most everyone here. -Steve
Re: Is D still alive?
On Thu, 27 Jan 2011 04:59:18 -0500, retard r...@tard.com.invalid wrote: Wed, 26 Jan 2011 15:35:19 -0500, Steven Schveighoffer wrote: I'd suggest to anyone looking to use D for something really big to try and prove out how well D will perform for you by coding up bits of your whole project that you think will be needed. Hopefully, you can do everything without hitting a mercy bug and then you can write your full project in it. I think this reveals a lot about D. You still need to prove things. Or maybe the community members in general aren't very good developers; they can't see the potential of this language. The fact is, no matter what language you choose, if it isn't a complete joke, you can finish the project. (I'm assuming the community members here won't be writing any massive projects which are not possible to do in C++ or PHP or Java.) I fully see the potential of the language, but I've also experienced that a one (or two or three) man compiler team does not fix bugs on *my* schedule. I can't buy enterprise support, so any bugs I may hit, I'm just going to have to wait for Walter and Co. to get around to them. Not a problem for me, because I'm not developing with D professionally. But if I was going to base a software company on D, I'd be very nervous at this prospect. I find that I can work around many of D's bugs, but there are just some that you have to throw your hands up and wait (I don't have time to learn how a compiler works, and fix D's compiler). I think as D matures and hopefully gets more enterprise support, these problems will be history. I don't see any need to prove how well Haskell works. Even though it's a avoid success at all costs experimental research language. It just works. I mean to the extent that I'm willing to go with these silly test projects that try to prove something. The statements I made are not a property of D, they are a property of the lack of backing/maturity. I'm sure when Haskell was at the same maturity stage as D, and if it had no financial backing/support contracts, it would be just as much of a gamble. You seem to think that D is inherently flawed because of D, but it's simply too young for some tasks. It's rapidly getting older, and I think in a year or two it will be mature enough for most projects. -Steve
Re: Is D still alive?
On Thu, 27 Jan 2011 21:37:31 -0500, Ellery Newcomer ellery-newco...@utulsa.edu wrote: On 01/27/2011 05:41 PM, Walter Bright wrote: Unit testing has produced a dramatic improvement in coding. agreed. unit testing (maybe with dbc, I don't remember) was the only reason I noticed issue 5364. I created 4 or 5 bugs against dmd when I added full unit tests to dcollections. So unittests also help D probably as much as they do your code ;) -Steve
Re: Is D still alive?
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article On 1/27/11 8:02 PM, Walter Bright wrote: I think one of the reasons DbC has not paid off is it still requires a significant investment of effort by the programmer. It's too easy to not bother. 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/
Re: Is D still alive?
On 1/28/11 10:14 AM, Roman Ivanov wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article On 1/27/11 8:02 PM, Walter Bright wrote: I think one of the reasons DbC has not paid off is it still requires a significant investment of effort by the programmer. It's too easy to not bother. 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/ 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
Re: Is D still alive?
Fri, 28 Jan 2011 10:14:04 -0500, Steven Schveighoffer wrote: On Thu, 27 Jan 2011 04:59:18 -0500, retard r...@tard.com.invalid wrote: Wed, 26 Jan 2011 15:35:19 -0500, Steven Schveighoffer wrote: I'd suggest to anyone looking to use D for something really big to try and prove out how well D will perform for you by coding up bits of your whole project that you think will be needed. Hopefully, you can do everything without hitting a mercy bug and then you can write your full project in it. I think this reveals a lot about D. You still need to prove things. Or maybe the community members in general aren't very good developers; they can't see the potential of this language. The fact is, no matter what language you choose, if it isn't a complete joke, you can finish the project. (I'm assuming the community members here won't be writing any massive projects which are not possible to do in C++ or PHP or Java.) I fully see the potential of the language, but I've also experienced that a one (or two or three) man compiler team does not fix bugs on *my* schedule. I can't buy enterprise support, so any bugs I may hit, I'm just going to have to wait for Walter and Co. to get around to them. Not a problem for me, because I'm not developing with D professionally. I agree. But if I was going to base a software company on D, I'd be very nervous at this prospect. Exactly. I think as D matures and hopefully gets more enterprise support, these problems will be history. This is the classic chicken or the egg problem. I'm not trying to be unnecessarily mean. Enterprise support is something you desperately need. Consider dsource, wiki4d, d's bugzilla etc. It's amazing how much 3rd party money and effort affects the development. Luckily many things are also free nowadays such as github. I don't see any need to prove how well Haskell works. Even though it's a avoid success at all costs experimental research language. It just works. I mean to the extent that I'm willing to go with these silly test projects that try to prove something. The statements I made are not a property of D, they are a property of the lack of backing/maturity. I'm sure when Haskell was at the same maturity stage as D, and if it had no financial backing/support contracts, it would be just as much of a gamble. But Haskell developers have uninterruptedly received funding during the years. You seem to think that D is inherently flawed because of D, but it's simply too young for some tasks. It's rapidly getting older, and I think in a year or two it will be mature enough for most projects. I've heard this before. I've also heard the 64-bit port and many other things are done in a year/month or two. The fact is, you're overly optimistic and these are all bullshit. When I come back here in a year or two, I have full justification to laugh at your stupid claims.
Re: Is D still alive?
Fri, 28 Jan 2011 16:14:27 +, Roman Ivanov wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article On 1/27/11 8:02 PM, Walter Bright wrote: I think one of the reasons DbC has not paid off is it still requires a significant investment of effort by the programmer. It's too easy to not bother. 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/ Mono 2.8 also seems to support those: http://www.mono-project.com/news/archive/2010/Oct-06.html
Re: Is D still alive?
On 1/28/11 3:25 PM, retard wrote: Fri, 28 Jan 2011 10:14:04 -0500, Steven Schveighoffer wrote: I think as D matures and hopefully gets more enterprise support, these problems will be history. This is the classic chicken or the egg problem. I'm not trying to be unnecessarily mean. Enterprise support is something you desperately need. Consider dsource, wiki4d, d's bugzilla etc. It's amazing how much 3rd party money and effort affects the development. Luckily many things are also free nowadays such as github. I don't see any need to prove how well Haskell works. Even though it's a avoid success at all costs experimental research language. It just works. I mean to the extent that I'm willing to go with these silly test projects that try to prove something. The statements I made are not a property of D, they are a property of the lack of backing/maturity. I'm sure when Haskell was at the same maturity stage as D, and if it had no financial backing/support contracts, it would be just as much of a gamble. But Haskell developers have uninterruptedly received funding during the years. That doesn't say much about anything. Some projects worked well with funding, some worked well with little or no initial funding. You seem to think that D is inherently flawed because of D, but it's simply too young for some tasks. It's rapidly getting older, and I think in a year or two it will be mature enough for most projects. I've heard this before. I've also heard the 64-bit port and many other things are done in a year/month or two. The fact is, you're overly optimistic and these are all bullshit. When I come back here in a year or two, I have full justification to laugh at your stupid claims. I think if you do that I have full justification to send you back where you originally came from. Cut the crap for a change, will you. Thanks. Andrei
Re: Is D still alive?
Steven Schveighoffer wrote: I can't buy enterprise support, Of course you can!
Re: Is D still alive?
On Friday, January 28, 2011 17:16:54 Walter Bright wrote: Steven Schveighoffer wrote: I can't buy enterprise support, Of course you can! Well, since Scotty hasn't been born yet, it's probably a bit premature... ;) - Jonathan M Davis
Re: Is D still alive?
Jonathan M Davis wrote: On Friday, January 28, 2011 17:16:54 Walter Bright wrote: Steven Schveighoffer wrote: I can't buy enterprise support, Of course you can! Well, since Scotty hasn't been born yet, it's probably a bit premature... ;) She canna take the power!
Re: Is D still alive?
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
Re: Is D still alive?
Wed, 26 Jan 2011 14:39:08 -0500, Steven Schveighoffer wrote: I will warn you, once you start using D, you will not want to use something else. I cringe every day when I have to use PHP for work. Nice trolling.
Re: Is D still alive?
Wed, 26 Jan 2011 15:35:19 -0500, Steven Schveighoffer wrote: I'd suggest to anyone looking to use D for something really big to try and prove out how well D will perform for you by coding up bits of your whole project that you think will be needed. Hopefully, you can do everything without hitting a mercy bug and then you can write your full project in it. I think this reveals a lot about D. You still need to prove things. Or maybe the community members in general aren't very good developers; they can't see the potential of this language. The fact is, no matter what language you choose, if it isn't a complete joke, you can finish the project. (I'm assuming the community members here won't be writing any massive projects which are not possible to do in C++ or PHP or Java.) I don't see any need to prove how well Haskell works. Even though it's a avoid success at all costs experimental research language. It just works. I mean to the extent that I'm willing to go with these silly test projects that try to prove something.
Re: Is D still alive?
Wed, 26 Jan 2011 14:09:25 -0800, Walter Bright wrote: Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. I also got brainwashed by the C++ advocates years ago. However, I didn't need D to see how terrible writing C++ is. C++ sure is a powerful language and sometimes a necessary evil, but you don't really need very strong doses of more recent languages to see how much nicer everything else is.
Re: Is D still alive?
Wed, 26 Jan 2011 23:33:54 +0100, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Yep, those were to reasons that lured me to learn Java. However, those were not the reasons to learn D. The main reasons were RAII and Design by Contract. Even funnier, it took D about 9 years to fix the main bug in DbC (contract inheritance).
Re: Is D still alive?
retard Wrote: Or maybe the community members in general aren't very good developers; they can't see the potential of this language. The fact is, no matter what language you choose, if it isn't a complete joke, you can finish the project We have a lot of talented people in this community who've created awesome projects, I don't think it's a lack of skills. Sometimes you hit bugs you just can't workaround. In my case these included forward reference bugs where a simple exchange the declarations didn't work cause of cross-references and a nasty corrupt stack frame bug I couldn't reduce.
Re: Is D still alive?
Am 27.01.2011 01:41, schrieb spir: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. Denis What about a[1.. min(x, $)]. (min from std.alorithm)? Mafi
Re: Is D still alive?
On 01/27/2011 04:06 AM, Jonathan M Davis wrote: Clearly, if you think that not being strict about indices is a good idea, you're either dealing with very different circumstances than I have and/or you're coding very differently. Regardless, since it's trivial to create a wrapper that does what you want, I don't think that there's any reason to change how slicing works. I would agree with you be reasoning in pure air (I mean without having used both semantic versions). But concrete experience (of a huge number of programmers) in widely used programming languages demonstrate the opposite. Slice /upper/ bound checking is an idea that looks good in theory but is not in practice. Denis -- _ vita es estrany spir.wikidot.com
Re: Is D still alive?
On 01/27/2011 01:24 PM, Mafi wrote: Am 27.01.2011 01:41, schrieb spir: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. Denis What about a[1.. min(x, $)]. (min from std.alorithm)? Yes, that's it. Denis -- _ vita es estrany spir.wikidot.com
Re: Is D still alive?
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?
Re: Is D still alive?
Ulrik Mikaelsson: Isn't the real reason for this that bounds-checking is usually completely turned-off in release-builds? Bounds checking is turned off in release builds mostly because: 1) DMD is not able to infer remove most bound checks at compile-time as the latest Oracle VM are able to do; 2) and because Walter Co. believe such analysis isn't able to remove most bound checks anyway (I have not seen this hypothesis confirmed yet). Sounds like something that could noticeably degrade runtime-performance for array-intensive code? The safety net we are talking about is present only at the right bound of a slicing syntax (it's not performed in normal array indexing), and it consists in a single min(x, $) operation, that's one branch. So it slows down code, but only a bit. And in many of such situations you probably need to add a min(x, $) manually in the code anyway, so the overhead is limited. Bye, bearophile
Re: Is D still alive?
On Thursday, January 27, 2011 01:34:04 bearophile wrote:
spir:
Sorry, but you are wrong on this. I understand this sounds unsafe, but
no. Most languages, I guess, just do that without any worry. In
particular, I have frequented python and Lua mailing lists for years
without even reading once about this beeing a misfeature (and indeed
have never run into a bug because of this myself). It is simply the
right semantics in 99.999% cases.
Thank you for raising this topic again. I have raised it probably more than
one year ago, and all people around here were against this. This is not
unsafe, it's actually safer than the current D behaviour. Python designers
don't think this is a badly designed part of Python, they think this is as
desired, and I too have never seen people complain about this being a bad
or bug prone design.
An example of Python code:
s = abcdefg
upper = 20
s2 = s[2 : upper]
assert s2 == cdefg
Equivalent D2 code, if you forget to use the min() you are doomed:
import std.algorithm: min;
void main() {
string s = abcdefg;
int upper = 20;
string s2 = s[2 .. min($, upper)];
assert(s2 == cdefg);
}
The saturating nature of Python slice bounds is a safety net that's useful
to avoid some troubles. The only good thing of the D2 design is that it
performs less tests at runtime (it has no need to call min() in general),
this is a bit positive in a system language, but in this case it has a
cost in safety.
I don't think that you stand much chance of convincing a crowd using a system
programming language that having the compiler adjust your out of bound indices
to be in bounds is good idea. While it may be a great idea in some
circumstances, it generally smacks of lax programming. And since it makes
slicing more expensive, it would be a feature that would definitely need to
pull
its weight. And I don't see how it possibly could. It's trivial to add a
function which will return a slice which is laxly sliced in the manner that
you're looking for. And using min as you're showing isn't exactly hard.
Yes, you may get bugs when porting code from Python, but I don't think that
porting Python code has ever been one of the major concerns of D's language
design. Really, it's the silently breaking stuff when porting C and C++ code
which has been the concern.
What we have is efficient, and I expect that most people around here think that
it's the correct solution. If you want lax slicing, it's easy to get by using
min or a wrapper function. So, I see no reason to make any language changes -
not to mention it would likely conflict with TDPL to make such a change.
- Jonathan M Davis
Re: Is D still alive?
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!
}
Re: Is D still alive?
On Thursday, January 27, 2011 09:47:44 bearophile wrote: Ulrik Mikaelsson: Isn't the real reason for this that bounds-checking is usually completely turned-off in release-builds? Bounds checking is turned off in release builds mostly because: 1) DMD is not able to infer remove most bound checks at compile-time as the latest Oracle VM are able to do; 2) and because Walter Co. believe such analysis isn't able to remove most bound checks anyway (I have not seen this hypothesis confirmed yet). Sounds like something that could noticeably degrade runtime-performance for array-intensive code? The safety net we are talking about is present only at the right bound of a slicing syntax (it's not performed in normal array indexing), and it consists in a single min(x, $) operation, that's one branch. So it slows down code, but only a bit. And in many of such situations you probably need to add a min(x, $) manually in the code anyway, so the overhead is limited. Personally, I have _never_ needed to add a min call like that. So, while _you_ may think that it's a common thing to do (and it may be that it is in your code), that doesn't mean that that's generally true. - Jonathan M Davis
Re: Is D still alive?
Andrej Mitrovic:
Honestly, I think this would just encourage writing sloppy code.
I don't believe this, on the other hand I believe the current behaviour is
bug-prone.
Using min(x, $) explicitly informs the reader of the code of exactly
what happens.
Right. The problem is that in some cases you may forget to add that min(x, $).
It's harder to tell when it's implicit.
Slicing syntax is used all the time in both Python and D code, so the Python
and D programmers learn quickly and keep in mind what it does. Implicit
behaviours are a problem when they are uncommon things, or library functions,
etc, much less when they are built-in safety nets you use every five lines of
code :-)
Not only that,
but it can introduce bugs in your code - because while you might use
any upper bound, you're still not allowed to index beyond the length
of the array.
Writing hundreds of thousands of lines of Python code I've seen that the
saturating semantics we are talking about is not bug-prone (in fact it avoids
some bugs).
Imagine this could was accepted by DMD:
void main()
{
auto userArgs = [foo]; // runtime arguments by some user input
auto firstTwo = userArgs[0..2]; // accepted by the new language change,
// implicitly
changes 2 to min(2, $)
// more code here
firstTwo[1] = test; // oops!
}
Programmers just quickly learn that indexes and slices have a bit different
semantics.
Bye,
bearophile
Re: Is D still alive?
This *code* was accepted, not *could*.
Re: Is D still alive?
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
Re: Is D still alive?
On 1/27/11, bearophile bearophileh...@lycos.com wrote: Programmers just quickly learn that indexes and slices have a bit different semantics. Right, programmers can easily adapt to slightly different semantics in related areas of the language, I mean C++ is known for being very easy to learn for exactly that reason. (Sarcasm alert!).
Re: Is D still alive?
Am 27.01.2011 19:25, schrieb bearophile: Programmers just quickly learn that indexes and slices have a bit different semantics. And I guess this holds true for programmers used to python as well? So they should have no problem with learning to use foo = blah[i..min($,i+n)] instead of foo = blah[i..(i+n)] ;-) Bye, bearophile Cheers, - Daniel
Re: Is D still alive?
retard wrote: I also got brainwashed by the C++ advocates years ago. However, I didn't need D to see how terrible writing C++ is. C++ sure is a powerful language and sometimes a necessary evil, but you don't really need very strong doses of more recent languages to see how much nicer everything else is. What D unique shows is, however, that one can do C++ like things without the C++ issues, in other words, the problems C++ has are not necessary in order to get the powerful things C++ can do.
Re: Is D still alive?
retard wrote: The main reasons were RAII and Design by Contract. Even funnier, it took D about 9 years to fix the main bug in DbC (contract inheritance). The reason that took so long was that few people were using DbC effectively, so it was a low priority. I originally had high hopes that DbC would produce dramatic improvements in code quality, but the real world results were disappointing.
Re: Is D still alive?
On 1/27/11 1:26 PM, Walter Bright wrote: retard wrote: I also got brainwashed by the C++ advocates years ago. However, I didn't need D to see how terrible writing C++ is. C++ sure is a powerful language and sometimes a necessary evil, but you don't really need very strong doses of more recent languages to see how much nicer everything else is. What D unique shows is, however, that one can do C++ like things without the C++ issues, in other words, the problems C++ has are not necessary in order to get the powerful things C++ can do. Well put. BTW I'm glad to see retard back in action. A small debate of bearophile about bounds checking and whatnot, Bruno doing his monthly bulk answering to posts, retard being down on D... it all starts looking like a good day on digitalmars.D :o). Andrei
Re: Is D still alive?
Walter:
The reason that took so long was that few people were using DbC effectively,
so it was a low priority. I originally had high hopes that DbC would produce
dramatic improvements in code quality, but the real world results were
disappointing.
After many years and many failed hopes, I think there is no silver bullet in
programming, so maybe nothing is able to produce dramatic improvements in code
quality.
But even if this is true, some things are able to improve coding a bit, like
unit testing, a well semantically defined language, syntax coloring, quick
compile-run cycles, OOP for certain kinds of programs, DbC, and so on. Each of
such things improve the situation only a little, but such improvements pile up
and most programmers when have tried them don't want to go back to miss those
things.
I have learnt to know and use DbC on D, and while it has not caused dramatic
improvements in my code, I like to use it now and then, it has found some of
the bugs in my code and more. I am appreciating D DbC enough that sometimes I
miss it when I write Python code, so sometimes when I write OOP Python code, I
add home-made class invariants and I call them manually from methods. In one
situation this has allowed me to finish some hairy Python code in a very tight
time schedule.
Regading D implementation of DbC I'd like:
- DMD to use a not-release build of Phobos when I compile my D code in
not-release build (or some similar solution). So Phobos will be free to use
asserts instead of enforce in many more situations (even if not in all
situations). This will allow more inlining, allow to use nothrow tags more
frequently, and avoid some performance problems currently present (confirmed by
timings and profiling) in Phobos caused by enforces;
- To see some acceptable solution for the old (pre-state) problem. On this
there are some ideas, but I don't think there is some accepted proposal yet.
This is not an indispensable feature of DbC, but it allows to increase its
power and applicability significantly enough (and designers of C#4 DbC has
found ways to solve this problem, so I presume there is some way to solve it in
D too);
- To see some Bugzilla DbC bugs removed. One or more of them is related to how
const/immutable badly interacts with the result return value used by
out(result){}.
Bye and thank you,
bearophile
Re: Is D still alive?
bearophile wrote: Walter: The reason that took so long was that few people were using DbC effectively, so it was a low priority. I originally had high hopes that DbC would produce dramatic improvements in code quality, but the real world results were disappointing. After many years and many failed hopes, I think there is no silver bullet in programming, so maybe nothing is able to produce dramatic improvements in code quality. But even if this is true, some things are able to improve coding a bit, like unit testing, a well semantically defined language, syntax coloring, quick compile-run cycles, OOP for certain kinds of programs, DbC, and so on. Each of such things improve the situation only a little, but such improvements pile up and most programmers when have tried them don't want to go back to miss those things. Unit testing has produced a dramatic improvement in coding.
Re: Is D still alive?
Walter Bright napisał: bearophile wrote: Walter: The reason that took so long was that few people were using DbC effectively, so it was a low priority. I originally had high hopes that DbC would produce dramatic improvements in code quality, but the real world results were disappointing. 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
Re: Is D still alive?
Tomek Sowiński wrote: Walter Bright napisał: bearophile wrote: Walter: The reason that took so long was that few people were using DbC effectively, so it was a low priority. I originally had high hopes that DbC would produce dramatic improvements in code quality, but the real world results were disappointing. 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.
Re: Is D still alive?
On 1/28/11, Walter Bright newshou...@digitalmars.com wrote: I think one of the reasons DbC has not paid off is it still requires a significant investment of effort by the programmer. It's too easy to not bother. Another way to look at it is that programmers are enjoying the safety of using regular D so much as to not even think about using DbC. The language does guarantee a lot more than C++. The irony here is that C++ is the one that desperately needs integrated DbC, and yet D, the safer language, is the one providing DbC for free. :p In other words, we get the candy and the cake.
Re: Is D still alive?
On 1/27/11 8:02 PM, Walter Bright wrote: Tomek Sowiński wrote: Walter Bright napisał: bearophile wrote: Walter: The reason that took so long was that few people were using DbC effectively, so it was a low priority. I originally had high hopes that DbC would produce dramatic improvements in code quality, but the real world results were disappointing. 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! 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
Re: Is D still alive?
On 01/27/2011 05:41 PM, Walter Bright wrote: Unit testing has produced a dramatic improvement in coding. agreed. unit testing (maybe with dbc, I don't remember) was the only reason I noticed issue 5364.
Re: Is D still alive?
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
Re: Is D still alive?
Andrei Alexandrescu wrote: On 1/27/11 8:02 PM, Walter Bright wrote: I was talking about this with Andrei the other day. D's focus on making it easy to do things the right way has paid off handsomely, though this is not at all obvious from reading a feature list. It only becomes clear when you use it for a while, and then try to go back to the way you were doing things before. Although this might as well be true, I generally try to avoid such arguments. The problem with it is it's non-falsifiable (http://en.wikipedia.org/wiki/Falsifiability) so it has a certain stench coming with it. I've seen such a claim in Go fora: you know, once you get to really use Go, you won't feel the need for generics. Meh. I try to _never_ use such an argument. If I'm to convince anyone that D rocks, it won't be by means of unfalsifiable statements. I agree it's a worthless argument to use to try and convince people to give D a try. But for experienced D users, it is an interesting point. It will be by showing code that knocks your socks off. The kind of code that makes you think: If I'm to write that in language X, I need to give away desirable traits A, B, and C. Damn! I think one of the reasons DbC has not paid off is it still requires a significant investment of effort by the programmer. It's too easy to not bother. One issue with DbC is that its only significant advantage is its interplay with inheritance. Otherwise, scope() in conjunction with assert works with less syntactic overhead. So DbC tends to shine with large and deep hierarchies... but large and deep hierarchies are not that a la mode anymore. Yes, you might be right.
Re: Is D still alive?
On Thursday 27 January 2011 19:29:59 Walter Bright wrote: Andrei Alexandrescu wrote: One issue with DbC is that its only significant advantage is its interplay with inheritance. Otherwise, scope() in conjunction with assert works with less syntactic overhead. So DbC tends to shine with large and deep hierarchies... but large and deep hierarchies are not that a la mode anymore. Yes, you might be right. I generally end up using unit tests to verify that stuff works correctly and then throw exceptions on bad input. So while I like having DbC built in, I don't end up using it all that much. It's prim,arily invariant that I end up using though, and that's harder to do inside of the member functions. - Jonathan M Davis
Re: Is D still alive?
Andrei: One issue with DbC is that its only significant advantage is its interplay with inheritance. Otherwise, scope() in conjunction with assert works with less syntactic overhead. So DbC tends to shine with large and deep hierarchies... but large and deep hierarchies are not that a la mode anymore. Have you tried to use class invariants manually? It's easy to forget its calls, and the calls clutter the code, and are not handy to write. So I don't agree. Bye, bearophile
Re: Is D still alive?
the problems C++ has are not necessary in order to get the powerful things C++ can do. That thought makes me happy!
Is D still alive?
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.
Re: Is D still alive?
On Wed, 26 Jan 2011 14:25:10 -0500, Fab fab-cod...@web.de wrote: Dear D community, My name is Fabian and I used to code C++ and Delphi. But a few month ago I've got a book about D as a present. All in all D sounds very interesting ... but - the big but - is D still alive? Very much so. D2 is being actively developed. D1 is not, but Tango is being actively developed (which works with D1). Are there usable and stable GUI-Toolkits which are actually under development? I don't have personal experience with any of the current GUI projects, but from what I've read, many of them are usable. Whether they are actively developed, I'm not sure. See many of them here: http://prowiki.org/wiki4d/wiki.cgi?GuiLibraries Are there any continued database projects? AFAIK, there is very little DB support (which will definitely need to be addressed before D is considered a complete language) for D2. However, you *always* have support via C bindings. D has zero-overhead binding to C functions, all you need to do is port the declarations to D. If you are using D1, there are several projects, I don't think many of them are up to date: http://prowiki.org/wiki4d/wiki.cgi?DatabaseBindings So - is there any reason to change to D? I would ... I really would change if there were more points than a nice language. I don't buy a good car if it's to expensive - so: is D as precious as its pretend to be? I will warn you, once you start using D, you will not want to use something else. I cringe every day when I have to use PHP for work. I would say it is not ready for prime-time yet. It has a way to go, but some have managed to build pretty impressive applications from it. So it would depend on your application. -Steve
Re: Is D still alive?
On Wed, 26 Jan 2011 14:39:08 -0500, Steven Schveighoffer schvei...@yahoo.com wrote: On Wed, 26 Jan 2011 14:25:10 -0500, Fab fab-cod...@web.de wrote: Dear D community, My name is Fabian and I used to code C++ and Delphi. But a few month ago I've got a book about D as a present. All in all D sounds very interesting ... but - the big but - is D still alive? Very much so. D2 is being actively developed. D1 is not, but Tango is being actively developed (which works with D1). I should clarify, D1 is not getting any new features, but it is getting bug fixes. -Steve
Re: Is D still alive?
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.
Re: Is D still alive?
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.
Re: Is D still alive?
On Wed, 26 Jan 2011 14:54:06 -0500, Fab fab-cod...@web.de wrote: Thank you for your answer. But is there also a productive IDE for 'the daily use'? I'm used to code Delphi and there is also everything in the IDE I need to code full featured applications. I don't need a GUI-Designer (but it would be nice - maybe something like the QT-Designer) but a IDE which supports graphical debugging is vital for me. There are several projects in progress for D IDEs, at various levels of maturity, including one that integrates D into visual studio. http://prowiki.org/wiki4d/wiki.cgi?EditorSupport Note, you may be able to find answers to other questions on the D wiki. -Steve
Re: Is D still alive?
Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.vpxkvij9eav7ka@steve-laptop... On Wed, 26 Jan 2011 14:25:10 -0500, Fab fab-cod...@web.de wrote: Are there any continued database projects? AFAIK, there is very little DB support (which will definitely need to be addressed before D is considered a complete language) for D2. However, you *always* have support via C bindings. D has zero-overhead binding to C functions, all you need to do is port the declarations to D. If you are using D1, there are several projects, I don't think many of them are up to date: http://prowiki.org/wiki4d/wiki.cgi?DatabaseBindings Adam Ruppe and Piotr Szturmaj have recently been working on some database stuff. See the recent thread Can your programming language do this? So - is there any reason to change to D? I would ... I really would change if there were more points than a nice language. I don't buy a good car if it's to expensive - so: is D as precious as its pretend to be? I will warn you, once you start using D, you will not want to use something else. I cringe every day when I have to use PHP for work. So very true :) I would say it is not ready for prime-time yet. It has a way to go, but some have managed to build pretty impressive applications from it. So it would depend on your application. Personally, I think that even though D still has some things to be worked out, I think it's *still* far better than any of the other more mature languages.
Re: Is D still alive?
Fab fab-cod...@web.de wrote in message news:ihpu4u$24bp$1...@digitalmars.com... Thank you for your answer. But is there also a productive IDE for 'the daily use'? I'm used to code Delphi and there is also everything in the IDE I need to code full featured applications. I don't need a GUI-Designer (but it would be nice - maybe something like the QT-Designer) but a IDE which supports graphical debugging is vital for me. I use Programmer's Notepad 2 which does everything I care about and is very nicely lean and responsive. I'm not sure if it does debugging though, I've never tried. If you prefer the bigger (bloated, IMO) IDE's then there are two D pulgins for Eclipse (Descent is the older more advanced one, and there's another, I forget the name, that's newer and being actively developed). There is also stuff out there to make D work well with Visual Studio (see the D.announcements newsgroup).
Re: Is D still alive?
Fab fab-cod...@web.de wrote in message news:ihpv7r$272q$1...@digitalmars.com... In addition you have to know for what I want to use D. I want to code little games (2D: Jump'n'Run) and I want to use D for scholastic use - drawing plots, calculating functions, ... and so on. You see: I want to use D for private and for scholastic purposes. For games, there are SDL and SFML bindings for D. You may also want to look at the Derelict project which includes bindings for a bunch of useful libraries. For plots/charts/graphs/etc, you should look at the humorously-named Plot2Kill library. Personally, I think D would be great for small games, private uses and scholastic uses. In fact, even *way* back *before* D1, Kenta Cho made some very good freeware games in D, like Torus Trooper and TUMIKI Fighters (ie, the original version of Blast Works). The areas where D is still a little behind are: If you *need* to be able to compile *native* 64-bit code (32-bit will still work on a 64-bit machine/OS, of course). If you need to create shared dynamic libraries (ie, .dll and .so). If you need to link with Windows C .obj and .lib files that were compiled with anything other than DMC. If you need to use a graphical GUI-builder tool. Or if you want to use something similar to Rails or Django to create web apps.
Re: Is D still alive?
On Wed, 26 Jan 2011 15:11:06 -0500, Nick Sabalausky a@a.a wrote: Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.vpxkvij9eav7ka@steve-laptop... On Wed, 26 Jan 2011 14:25:10 -0500, Fab fab-cod...@web.de wrote: Are there any continued database projects? AFAIK, there is very little DB support (which will definitely need to be addressed before D is considered a complete language) for D2. However, you *always* have support via C bindings. D has zero-overhead binding to C functions, all you need to do is port the declarations to D. If you are using D1, there are several projects, I don't think many of them are up to date: http://prowiki.org/wiki4d/wiki.cgi?DatabaseBindings Adam Ruppe and Piotr Szturmaj have recently been working on some database stuff. See the recent thread Can your programming language do this? I have ignored that thread (I sometimes just ignore threads because they start out uninteresting, or become uninteresting, and then I miss out on some good stuff!) I'll have to take a look, D2 really does need a DB interface -- badly. I would say it is not ready for prime-time yet. It has a way to go, but some have managed to build pretty impressive applications from it. So it would depend on your application. Personally, I think that even though D still has some things to be worked out, I think it's *still* far better than any of the other more mature languages. It all seems really good until you hit an issue that cannot be worked around -- like a compiler error or a misdesigned feature. I call these 'mercy' problems, because you are then at the complete mercy of someone else. If you have a deadline, or have a complete stoppage in work, you really have little choice but to move onto another language or abandon the project. Dcollections sat idle for about a year because of a problem like this. That would scare the crap out of me if I was a project manager trying to decide whether to use D or not. I've had first hand experience with using a product (from Microsoft) that failed so badly that we needed to have them fix it (which of course took about 3 months). A year later, they discontinued the product, and we had even more problems. I wrote my own system to replace it from scratch, and everything works so much better now (and uses less memory!). Not to mention, we have all source, so it's always possible to fix. A small part of it is written in D1/Tango and performs beautifully :) But I'd probably not rewrite the server in D (currently in C#) because it's lacking too much support for a lot of the things I do with it. I'd suggest to anyone looking to use D for something really big to try and prove out how well D will perform for you by coding up bits of your whole project that you think will be needed. Hopefully, you can do everything without hitting a mercy bug and then you can write your full project in it. There are also really scary possibilities that I've seen happen to a few poor souls -- like hard-to-solve OPTLINK bugs. Those may creep up at any time. Really, I just feel that D2's tools are not mature enough, or have enough support to trust a professional product on it -- yet. I'm sure this will change in the future. BTW, I plan to write a semi-professional project in D2 in the near future, but I'm 1) willing to take the risks 2) have no deadline and 3) not depending on this project for a living. -Steve
Re: Is D still alive?
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 :)
Re: Is D still alive?
But is there also a productive IDE for 'the daily use'? I still use Descent for Eclipse. It isn't maintained anymore but it's the only one with a copy of the dmd frontend with some semantic analysis. VisualD on Windows provides some basic auto-completion and goto definition etc via compiler generated json files. I don't need a GUI-Designer (but it would be nice - maybe something like the QT-Designer) I think QtD supports the Qt GUI Designer. but a IDE which supports graphical debugging is vital for me Then you should use VisualD on Windows. It includes cv2pdb which makes it possible to debug D apps with VisualStudio without much pain.
Re: Is D still alive?
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.
Re: Is D still alive?
Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it.
Re: Is D still alive?
On 1/26/11 4:09 PM, Walter Bright wrote: Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. As much as I cringe when I see http://d.puremagic.com/issues/show_bug.cgi?id=5493 Andrei
Re: Is D still alive?
On Wednesday, January 26, 2011 14:09:25 Walter Bright wrote: Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. LOL. Yeah. There's just so many little things that D improves on that when you're stuck in C++ land, you're constantly running into little things that you miss having or are annoyed to have to deal with. auto has probably been the biggest one for me, though slicing isn't far behind. At least auto will be in C++ 0x... I dream of the day that I'll be able to use D all of the time and not have to worry about C++ anymore. - Jonathan M Davis
Re: Is D still alive?
Walter Bright newshou...@digitalmars.com wrote in message news:ihq66j$2llc$1...@digitalmars.com... Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. Heh, D is programmer crack :) I use Haxe a lot and it's by no means a bad langauge overall, as far as languages go. Beats the snot out of PHP and ActionScript. But I frequently find myself cursing at it for not being able to handle things that I take for granted in D. Heck, just the other day I was going nuts because I had 5 objects that I needed to do some common trivial setup to, and there was *no* way to do it in a loop. No change I made ever stuck - it was as if the objects forgot they were reference types. Nothing worked. At least a full half-hour later, maybe a full hour, I ended up just copy-pasting the same damn code 5 times, once for each object. In D, I would have stuck them all in an array, typed foreach..., and been done in under a minute.
Re: Is D still alive?
Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. Yep, like being thrown back to the Stone Age.
Re: Is D still alive?
On 1/26/11 4:09 PM, Walter Bright wrote: Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. As much as I cringe when I see http://d.puremagic.com/issues/show_bug.cgi?id=5493 Andrei Well, coding in D is like being Indiana: you might run into nasty traps here and there but you just can't be a vanilla guy anymore ;)
Re: Is D still alive?
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.973.1296080233.4748.digitalmar...@puremagic.com... On Wednesday, January 26, 2011 14:09:25 Walter Bright wrote: Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. LOL. Yeah. There's just so many little things that D improves on that when you're stuck in C++ land, you're constantly running into little things that you miss having or are annoyed to have to deal with. auto has probably been the biggest one for me, though slicing isn't far behind. At least auto will be in C++ 0x... For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that.
Re: Is D still alive?
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.
Re: Is D still alive?
Nick Sabalausky a@a.a wrote in message news:ihq7a3$2o05$1...@digitalmars.com... Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.973.1296080233.4748.digitalmar...@puremagic.com... On Wednesday, January 26, 2011 14:09:25 Walter Bright wrote: Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. LOL. Yeah. There's just so many little things that D improves on that when you're stuck in C++ land, you're constantly running into little things that you miss having or are annoyed to have to deal with. auto has probably been the biggest one for me, though slicing isn't far behind. At least auto will be in C++ 0x... For me, D's killer features were string handling (slicing, appending/concatenation, ***and .length instead of null-termination***) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Fixed. ^^^
Re: Is D still alive?
Steven Schveighoffer napisał: 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. 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? [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
Re: Is D still alive?
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.
Re: Is D still alive?
On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. Denis -- _ vita es estrany spir.wikidot.com
Re: Is D still alive?
On Wednesday, January 26, 2011 16:41:10 spir wrote: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work. And if for some reason you really want to be able to just have it use $ if the index is too large, it's easy to write a wrapper function which does that. - Jonathan M Davis
Re: Is D still alive?
On 01/27/2011 02:11 AM, Jonathan M Davis wrote: On Wednesday, January 26, 2011 16:41:10 spir wrote: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work. Sorry, but you are wrong on this. I understand this sounds unsafe, but no. Most languages, I guess, just do that without any worry. In particular, I have frequented python and Lua mailing lists for years without even reading once about this beeing a misfeature (and indeed have never run into a bug because of this myself). It is simply the right semantics in 99.999% cases. spir@d:~$ python Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) [GCC 4.4.5] on linux2 Type help, copyright, credits or license for more information. s = 'abc' s[0:123456789] 'abc' spir@d:~$ lua Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio requireio 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
Re: Is D still alive?
On Wednesday 26 January 2011 17:52:19 spir wrote: On 01/27/2011 02:11 AM, Jonathan M Davis wrote: On Wednesday, January 26, 2011 16:41:10 spir wrote: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work. Sorry, but you are wrong on this. I understand this sounds unsafe, but no. Most languages, I guess, just do that without any worry. In particular, I have frequented python and Lua mailing lists for years without even reading once about this beeing a misfeature (and indeed have never run into a bug because of this myself). It is simply the right semantics in 99.999% cases. spir@d:~$ python Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) [GCC 4.4.5] on linux2 Type help, copyright, credits or license for more information. s = 'abc' s[0:123456789] 'abc' spir@d:~$ lua Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio requireio s = abc print(string.sub(s, 1, 123456789)) abc I'm constantly annoyed by D's behaviour. For instance, often have to write out the end of a string from a given point, but only at most n chars (to avoid cluttering the output, indeed): writeln(s[i..i+n]); which fails if there are less than n remaining chars ;-) I _rarely_ see cases where I would consider it okay to give an index for the end of an array and having that index be too large is a good thing. It invariably means that your algorithm is wrong. In my experience, if you really need to know what the size of your array is and handle it properly. There _are_ cases where you say that you want the rest of the array or collection and don't care how much that is, but in cases where you're actually looking to specify the index, if the index is wrong, then the code is wrong. Now, I suppose that there are cases where you could simplify an algorithm where you effectively be n or less (if there aren't n elements left). But that's definitely atypical in my experience, and writing a wrapper function for such a case is trivial. Generally speaking, I'd be very worried about code which was lax enough about indices to not care whether it was indexing passed the end of the array or not. Clearly, if you think that not being strict about indices is a good idea, you're either dealing with very different circumstances than I have and/or you're coding very differently. Regardless, since it's trivial to create a wrapper that does what you want, I don't think that there's any reason to change how slicing works. - Jonathan M Davis
Re: Is D still alive?
On Wednesday 26 January 2011 19:06:37 Jonathan M Davis wrote: On Wednesday 26 January 2011 17:52:19 spir wrote: On 01/27/2011 02:11 AM, Jonathan M Davis wrote: On Wednesday, January 26, 2011 16:41:10 spir wrote: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work. Sorry, but you are wrong on this. I understand this sounds unsafe, but no. Most languages, I guess, just do that without any worry. In particular, I have frequented python and Lua mailing lists for years without even reading once about this beeing a misfeature (and indeed have never run into a bug because of this myself). It is simply the right semantics in 99.999% cases. spir@d:~$ python Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) [GCC 4.4.5] on linux2 Type help, copyright, credits or license for more information. s = 'abc' s[0:123456789] 'abc' spir@d:~$ lua Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio requireio s = abc print(string.sub(s, 1, 123456789)) abc I'm constantly annoyed by D's behaviour. For instance, often have to write out the end of a string from a given point, but only at most n chars (to avoid cluttering the output, indeed): writeln(s[i..i+n]); which fails if there are less than n remaining chars ;-) I _rarely_ see cases where I would consider it okay to give an index for the end of an array and having that index be too large is a good thing. It invariably means that your algorithm is wrong. In my experience, if you really need to know what the size of your array is and handle it properly. There _are_ cases where you say that you want the rest of the array or collection and don't care how much that is, but in cases where you're actually looking to specify the index, if the index is wrong, then the code is wrong. Now, I suppose that there are cases where you could simplify an algorithm where you effectively be n or less (if there aren't n elements left). But that's definitely atypical in my experience, and writing a wrapper function for such a case is trivial. Generally speaking, I'd be very worried about code which was lax enough about indices to not care whether it was indexing passed the end of the array or not. Clearly, if you think that not being strict about indices is a good idea, you're either dealing with very different circumstances than I have and/or you're coding very differently. Regardless, since it's trivial to create a wrapper that does what you want, I don't think that there's any reason to change how slicing works. I should probably add that it's more efficient to have the built-in slicing facilities be exact and build inexact ones on top of that then it is to make them inexact and the build exact ones on top. When you get down to it, you _have_ to slice _exactly_ when you get down deep enough in the code. So, making the slicing then be exact on top of that doesn't really cost anything. But adding the extra checks to make the inexact one work adds extra cost. So, while that's fine if the inexact behavior is what you want, it's _not_ fine if it's the exact behavior that you want, since then unnecessary checks are happening in the middle. For efficiency reasons, the exact behavior _needs_ to be the default. exact - low level exact and inexact - exact - low level exact works as efficiently as is possible. Whereas having inexact - low level exact and exact - inexact - low level exact is _not_ efficient. - Jonathan M Davis
Re: Is D still alive?
Am 27.01.2011 02:11, schrieb Jonathan M Davis: On Wednesday, January 26, 2011 16:41:10 spir wrote: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work. And if for some reason you really want to be able to just have it use $ if the index is too large, it's easy to write a wrapper function which does that. - Jonathan M Davis I think he wants int arr[] = int[3]; // ... int arr2[] = arr[1..5]; to be equivalent to int arr[] = int[3]; // ... int arr2[] = arr[1..$]; arr2.length = 4; Cheers, - Daniel
Re: Is D still alive?
Am 27.01.2011 08:10, schrieb Daniel Gibson: Am 27.01.2011 02:11, schrieb Jonathan M Davis: On Wednesday, January 26, 2011 16:41:10 spir wrote: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work. And if for some reason you really want to be able to just have it use $ if the index is too large, it's easy to write a wrapper function which does that. - Jonathan M Davis I think he wants int arr[] = int[3]; // ... int arr2[] = arr[1..5]; to be equivalent to int arr[] = int[3]; // ... int arr2[] = arr[1..$]; arr2.length = 4; Cheers, - Daniel Okay, I just saw in spirs reply, that for some reason was not displayed in this branch of the thread but as a direct reply to the top post, that you understood him correctly and I didn't :-)
