Re: Converting multiple inheritance code into C ++ for D language
On Friday, 17 February 2017 at 23:24:57 UTC, Nicholas Wilson wrote: Something like this would be a goods use for struct multiple alias this, except that we haven't implemented that yet unfortunately. What's the deal with that? It seems someone made progress on this issue 2 years ago and then vanished. It's a fairly significant feature that's never been implemented!
Re: D 2015/2016 Vision?
On Monday, 5 October 2015 at 17:27:30 UTC, Jonathan M Davis wrote: And features like appending to arrays or allocating closures will always require the GC. Downward only closures should not always require GC. Pascal had these.
Re: A collection of DIPs
On Tuesday, 8 September 2015 at 03:09:20 UTC, Rikki Cattermole
wrote:
On 08/09/15 5:27 AM, Shammah Chancellor wrote:
void main() {
import std.stdio : writeln;
writeln("Hello world!");
}
-Shammah
It's not just an idiomatic way to code with local imports, it's
a compilation performance technique too.
I didn't read the DIP collection thoroughly (yup, D has a some
grotesqueries that would be nice to fix but I doubt will happen)
but local imports are one of the nice features of D (and Ada, and
OCaml) that I wish would be adopted in some other languages, like
Nim and Julia.
I never thought of them as a performance optimization though.
What's the reasoning? Are the observed differences significant?
From my POV restricting the scope of an import makes local
reasoning easier. I'd do it even if it were slightly less
performant!
Re: Points of Failure
On Tuesday, 28 July 2015 at 21:27:32 UTC, Walter Bright wrote: On 7/28/2015 12:30 PM, Jonathan M Davis wrote: LOL. There's a lot of highly subjective stuff on that list, and some of it seems to think that normal practices are bad, like I agree, but it's still worth taking a look at it and seeing if there are any action items we should address. The last time I tried to build dmd from source (on OS X) I found the process pretty clunky compared to building similar languages, like, say OCaml or Nim. I don't recall all of the pain points, but I don't do it any more; I just grab the binary. It would be great if the dmd build from source was just a few simple steps I could run (git clone repo, make, make install, or similar) and be confident that I had a working dmd. If that's how it is now, just disregard this message...
Re: dmd 2.068, 2.069, 2.0xx Evil Plan going forward
On Monday, 20 July 2015 at 19:30:36 UTC, Walter Bright wrote: I'm sad that this discussion on Evil Plans has so quickly turned into a deluge of posts bikeshedding a version number. Is there a timeline for this Evil Plan? What about bug fixes during the 2.068-2.069 period; are these deprioritized in favor of the translation? It's pretty exciting! I hope that after the compiler is all D-ified, there'll be some work on building DMD from source so that it becomes a much simpler process.
Re: Wait, what? What is AliasSeq?
On Wednesday, 15 July 2015 at 11:50:43 UTC, Andrei Alexandrescu wrote: On 7/15/15 4:29 AM, Mike wrote: On Wednesday, 15 July 2015 at 07:50:46 UTC, Dicebot wrote: Good to see another bad name merged in master ^_^ Was there a good name suggested that wasn't vetoed by Walter or Andrei? s/good name/name that I like/ What makes a good name good? Some people thought 'splat' sounded ridiculous, i.e., they didn't like it, but its use in PHP, Ruby, and other scripting operators, where it's really quite similar to its use in D, make it a 'good' candidate IMO. It doesn't have numerous alternative meanings in CS, like List/Tuple/Sequence, and its coinage is relatively recent, so recent that the Wiki entry https://en.wikipedia.org/wiki/Splat doesn't refer to its use as a term in programming yet. It's also short. I liked 'Seq', because it is a bit ambiguous, unlike 'Tuple', which has the same meaning in many popular languages, but by most criteria 'Splat' is better.
Re: Where will D sit in the web service space?
On Wednesday, 15 July 2015 at 06:57:36 UTC, Sebastiaan Koppe wrote: I don't think people care as much about the other stuff (gc, etc). I think a lot of people do care about GC, and the D story there (problematic conservative GC used in libraries, with exceptions, etc.) is worse than the Go story (precise, concurrent, low latency GC with improvements planned) or the Rust story (no GC, like C++ but much safer). There was some noise about a precise GC for D two years ago, with one poster claiming he'd write one over a summer, but nothing happened. Then the Higgs author posted her problems with GC here http://pointersgonewild.com/2014/09/09/ds-garbage-collector-problem/ and there is still this perception in the world that GC is a problem with D.
Re: Wait, what? What is AliasSeq?
On Wednesday, 15 July 2015 at 15:33:53 UTC, Andrei Alexandrescu wrote: Probably this won't be very useful here because the abstraction we describe is rather complex. I'd be happy with something that a dozen of folks around here agree isn't bad. I sense that the disdain for 'splat' was on account of its use as onomatopeia. I understand, and thought the same thing at first (reminded me of the old Batman TV series: Bam! Boffo! Splat!) but we get used to anything. If there's consensus for splat, I'm fine allowing it. I'm personally not very convinced because I'd never heard of the term before and (as I described) I was unable to discover with google what it means. 'splat operator' is how I'd Google it. If you're familiar with Ruby or PHP you'll see that terminology. Coffeescript too; here's an SO entry that gets the idea across http://stackoverflow.com/questions/6201657/what-does-splats-mean-in-the-coffeescript-tutorial
Re: Wait, what? What is AliasSeq?
On Thursday, 9 July 2015 at 19:10:39 UTC, Jonathan M Davis wrote: On Thursday, 9 July 2015 at 18:45:56 UTC, Marc Schütz wrote: Interestingly, it goes on by saying: An n-tuple is defined inductively using the construction of an ordered pair. Although not stated explicitly, this implies (a kind of) auto expanding! = Fits more than perfectly :-P No one who has ever seriously used tuples in any programming language I've ever heard of would expect tuples to auto expand. You're right. And after all of the discussion, I like the name AliasSeq more. The fact that it sometimes elicits a 'WTF' reaction is perfect; it's a D thing (or a 'not normally exposed to the programmer thing') so you need to look up what it does. Using Tuple, List, or Array in the name is unhelpful, as those names are used a lot already.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 19:57:15 UTC, Russel Winder wrote: Please note, OED (which is the definition of the English language whatever any USA upstarts may try to pretend) Glad to hear it. Please tell your countrymen to prefer the '-ize' suffix, as we colonials do, to the '-ise' one, which is a French affectation. http://en.wikipedia.org/wiki/Oxford_spelling
Re: Bug 14666, can we prioritize ?
On Wednesday, 10 June 2015 at 06:55:43 UTC, Walter Bright wrote: On 6/9/2015 10:39 PM, deadalnix wrote: The actual code is far more complex than the presented sample :) That what I'm trying to do in general, but here I'm faced with cases that are very hard to untangle. The 'tangle' of cyclical import graphs, as you so appropriately put, is not only hard on the compiler, it makes it much harder for human readers to make sense of code. Even reading your little code snippet hurts my brain. Go, in one of their better decisions, decided Thou Shalt Not Have Import Cycles. This forces users to untangle their code, and I believe that is A Good Thing. I'd like to do that for D, but of course it is far too late for that. Ada (83 and 95) were also rigid about not allowing any kind of import cycles. At some point, probably after Ada 95 when OO was added, it was decided after much experience that there were some cases where it was better to allow it. If you're interested, in the Ada world this issue was dubbed the with-ing problem and a quick Google search gives http://www.ada95.ch/doc/within/FAQ.html#what http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-4-2.html also in the world of Haskell, this thread https://mail.haskell.org/pipermail/haskell-cafe/2004-September/006885.html and I'm sure in many other places too. I agree with you, Walter, that mutual recursion amongst imports is usually bad, but I think you inadvertently made the right decision by allowing it in D, and that the bug should be fixed. If people overuse it to write messy code then the community should tell them to write that code better.
Re: Self-referential tuples?
On Tuesday, 9 June 2015 at 23:48:05 UTC, Timon Gehr wrote:
'This' is a cute hack, but it doesn't replace a proper template
fixpoint operator.
Could you explain this a bit more, maybe using some pseudo-D for
your proposed template fixpoint operator? Thanks.
I don't think I'd need such a thing for the JSON AST example,
since it isn't parameterized by type. There, the D mapping looks
clumsy because, as Andrei noticed, the 'fields' are not named. If
you map the OCaml straight to D you get something like what I
write below, and you want both the Kind and the internal
structure to be non-private so you can write functions which work
on them. It's the same as tagged unions/variants in other
languages but so much easier to use.
enum Kind {
Bool,
Number,
String,
Null,
Array,
Object
}
alias JSON = JSONStruct *;
struct JSONStruct {
public:
Kind kind;
union {
bool jsonBool;
double jsonNumber;
string jsonString;
JSON[] jsonArray;
JSON[string] jsonObject;
}
this(Kind kind, bool jsonBool)
in { assert(kind == Kind.Bool); }
body {
kind = Kind.Bool;
this.jsonBool = jsonBool;
}
this(Kind kind, double jsonNumber)
in { assert(kind == Kind.Number); }
body {
kind = Kind.Number;
this.jsonNumber = jsonNumber;
}
this(Kind kind, string jsonString)
in { assert(kind == Kind.String); }
body {
kind = Kind.String;
this.jsonString = jsonString;
}
this(Kind kind)
in { assert(kind == Kind.Null); }
body {
kind = Kind.Null;
}
this(Kind kind, JSON[] jsonArray)
in { assert(kind == Kind.Array); }
body {
kind = Kind.Array;
this.jsonArray = jsonArray;
}
this(Kind kind, JSON[string] jsonObject)
in { assert(kind == Kind.Object); }
body {
kind = Kind.Object;
this.jsonObject = jsonObject;
}
}
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 17:34:48 UTC, deadalnix wrote: On Wednesday, 10 June 2015 at 15:13:41 UTC, Brian Rogoff wrote: On Wednesday, 10 June 2015 at 15:09:21 UTC, anonymous wrote: On Wednesday, 10 June 2015 at 15:08:08 UTC, anonymous wrote: any community dumb enough to buy merchandise with a programming language's name on it is full of idiots. bye. p.s., Nim has the absolute worst community out of any of these languages. http://slashdot.org/comments.pl?sid=6771453cid=48860921 You're not doing the D community any great credit with this post, either. Try and stay classy. Translation: Let me try to shame you because I don't have any actual argument... Stick with your day job and leave mind reading and translation to experts! :-) What's the actual argument? Is cherry picking comments from unmoderated fora and posting them here in an effort to put down some other language community supposed to be good behavior, or rather rude and hypocritical? I say the latter, and the general way to deal with rude behavior is to point it out, what you seem to believe is 'shaming'. If you don't think that was rude, we simply disagree. The Rust community is probably the absolute best because tolerance for that is near zero. Too much I think, but perhaps they're right and it's for the best.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 15:09:21 UTC, anonymous wrote: On Wednesday, 10 June 2015 at 15:08:08 UTC, anonymous wrote: any community dumb enough to buy merchandise with a programming language's name on it is full of idiots. bye. p.s., Nim has the absolute worst community out of any of these languages. http://slashdot.org/comments.pl?sid=6771453cid=48860921 You're not doing the D community any great credit with this post, either. Try and stay classy.
Re: Self-referential tuples?
On Tuesday, 9 June 2015 at 15:28:16 UTC, Andrei Alexandrescu wrote: Following the use of This in Algebraic (https://github.com/D-Programming-Language/phobos/pull/3394), we can apply the same idea to Tuple, thus allowing one to create self-referential types with ease. Consider: // A singly-linked list is payload + pointer to list alias List(T) = Tuple!(T, This*); // A binary tree is payload + two children alias Tree(T) = Tuple!(T, This*, This*); // or alias Tree(T) = Tuple!(T, payload, This*, left, This*, right); // A binary tree with payload only in leaves alias Tree2(T) = Algebraic!(T, Tuple!(This*, This*)); Is there interest in this? Other application ideas to motivate the addition? Yes, I'm interested. As a practical example, how would you represent a JSON AST type, which might look something like this in OCaml (type json at the top) http://mjambon.com/yojson-doc/Yojson.Safe.html using Algebraic? And once you've encoded it using Algebraic, how do you operate on it, for example, how would you write a 'toString' on the AST? These are both straightforward in OCaml (the straightforward yet inefficient toString pracitically writes itself from the definition, the efficient version with buffers is only a little more involved) so a D version would be a good test.
Re: D and Nim
On Monday, 5 January 2015 at 10:21:12 UTC, Paulo Pinto wrote: On Monday, 5 January 2015 at 09:51:22 UTC, Suliman wrote: What is kill future of Nim? D is successor of C++, but Nim? Successor of Python? I'm not sure if you're being serious, but I'd say yes. The space where I see Nim being successful is mostly occupied by Python and Go. That it can compete with D in some systems programming, or for games, is nice, but games are dominated by C++ and I don't see how any new language displaces it in the near future. That doesn't mean that the OP shouldn't experiment though. With some effort in the scientific space, I believe that Nim could compete with MATLAB/R/Julia, but currently the libraries just don't exist. But the language would appeal to scientific programmers I think, more so than would D. A C++ successor is any language that earns its place in a OS vendors SDK as the OS official supported language for all OS layers. I think a C++ successor is a language that 'enough' people would choose where before they'd have chosen C++. Java has already cleared that bar.
Re: D and Nim
On Sunday, 4 January 2015 at 18:10:52 UTC, Jonathan wrote: Hey folks, I've been recently checking out Nim/rod and feel like it takes a lot of inspiration from D (I think the creator was in the D community too as some point). I'm pretty sure that D was not a big inspiration to Nim, even though Araq (Andreas Rumpf) has commented here on occasion. How do you think it compares? Overall, I much prefer Nim. The obvious first difference is syntax (Nim uses an offside rule like Python/Haskell/ISWIM) and for some people that's a huge difference which determines which they'll prefer. Nim's parametric polymorphism is less powerful than D's I think (the words 'generic' and 'template' are used differently in the two communities so I'll try and be extra clear) but Nim has a powerful macro system and a (still unfinished) kind of type classes which give it an edge on D. D has a simple class based OO that looks a lot like Java, and ties reference semantics to classes. D has a rather unique multi method based OO system. There are quite a few more things (concurrency, effect system, iterators vs ranges, ..) but I'll just advise you to look. What areas does D, in principle, makes it a better choice? Larger language community. Lower bus factor too, I think. Subjectively, D feels to me like an attempt to fix and improve C++. Nim feels more like a language in the Delphi/Modula-3 tradition with Python syntax. If you can't stand that syntax, stay away. It's not changing. To give you my background, I like creating games (mostly using SDL bindings) using new languages, aiming for the most efficient yet concise way to write the engine and game logic. Nim's GC was designed with games in mind. D's GC (which can be disabled) is not usually considered a strong point of the language implementation. FYI, this is NOT a language war thread. I'm just curious about what separates them from a principle level. Quite a lot separates them, even though they both target similar areas. Best to read a few tutorials and write some small programs in each. You might also try asking on the Nim forum. I realize you say you're not starting a language flame war, but the etiquette of the question is a bit problematic. Hopefully I don't fan any flames with my answer.
Re: D and Nim
On Monday, 5 January 2015 at 01:21:07 UTC, Vlad Levenfeld wrote: Could you elaborate on the difference between D's templates/mixins and Nim's macros/type classes? I'd suggest you read the available documentation on each feature; for example Nim's user defined type classes are described here http://nim-lang.org/manual.html#user-defined-type-classes and the Nim's templates/macros are also described with examples in the manual. One caveat is that user defined type classes are not really useable now and will probably be feature gated (not removed as some other poster here suggested) so it's not fair to talk about them as though they actually exist now. They're more like multiple alias this or D's precise GC ;-). D templates (what is called generics in Nim) are more powerful than Nim generics. Maybe Nim will pick up some of those features (HKTs are a desired feature in Rust and maybe in Nim too) and maybe not. It's really difficult to compare languages and features. Like I said, pick a small project and write some code in each. I found Nim really easy to pick up for small projects; a bit easier than D and much easier than Rust, which I like, but find slow going.
Re: What are the worst parts of D?
On Thursday, 25 September 2014 at 13:49:00 UTC, Andrei Alexandrescu wrote: I've recently used Rust a bit and the curse of D users as of 6-7 years ago reached me: most code I download online doesn't compile for obscure reasons, it's nigh impossible to figure out what the fix is from the compiler error message, searching online finds outdated documentation that tells me the code should work, and often it's random name changes (from_iterator to from_iter and such, or names are moved from one namespace to another). That's more than a bit unfair. Rust's developers have made it abundantly clear that things will keep changing until version 1.0. If you want to play with some Rust that's guaranteed to work, go to http://www.rust-ci.org and find a bit code that interests you which isn't failing, and then download the nightly. The docs on the Rust home page are either for a fixed version (0.11.0) or the nightly. Let's wait for a bit of time after 1.0 is out before you critique the annoying changes; they deliberately are developing in the open to get community input and avoid getting stuck with too many mistakes (though it looks like they are stuck with C++ template syntax, ugh!). So far, I haven't found it too hard to update code, and they've been good at marking breaking changes as breaking changes, which can be searched for with git. In the case of D, the main D2 book was published 4 years ago and that should correspond to Rust 1.0 or even later, since D already had a D1 to shake out the mistakes and bad namings. That's gone perfectly, with no code breakage between releases during those four years, right?
Re: Identifier resolution, the great implementation defined mess.
On Thursday, 18 September 2014 at 23:14:41 UTC, Timon Gehr wrote: On 09/19/2014 12:06 AM, Brian Schott wrote: On Thursday, 18 September 2014 at 21:31:26 UTC, Peter Alexander wrote: Maybe in this case And in every case. DMD's behavior is correct because it consistent with DMD. ??? http://en.wikipedia.org/wiki/Gallows_humor
Re: Why does D rely on a GC?
On Tuesday, 19 August 2014 at 14:13:38 UTC, Andrei Alexandrescu
wrote:
On 8/19/14, 12:25 AM, ketmar via Digitalmars-d wrote:
of course, you'll loose such nice features as closures and
slices, but
hey, C++ doesn't have them too! ok, C++11 has lambdas, and i
don't know
if D lambdas can work without GC and don't leak.
They don't use GC if scoped.
Andrei
And, in 2.066, it works with @nogc. Scoped no-gc downward
closures.
alias dgFloatToFloat = float delegate(float) @nogc;
alias dgFloatPairToFloat = float delegate(float, float) @nogc;
float integrate(scope dgFloatToFloat f,
float lo, float hi, size_t n) @nogc {
float result = 0.0;
float dx = (hi - lo) / n;
float dx2 = dx * 0.5;
for (size_t i = 0; i n; i++) {
result += f(lo + i * dx2) * dx;
}
return result;
}
float integrate(scope dgFloatPairToFloat f,
float x0, float x1, size_t nx,
float y0, float y1, size_t ny) @nogc {
return integrate((y) = integrate((x) = f(x,y), x0, x1, nx),
y0, y1, ny);
}
I was going to ask for an @nogc { fundefs } to reduce the
noise, but I just tried it and it seems to work. Nice!
Re: Software Assurance Reference Dataset
On Tuesday, 22 July 2014 at 21:23:33 UTC, Timon Gehr wrote: On 07/22/2014 09:42 PM, Walter Bright wrote: The point was not at all to criticize Haskell. The point was that D does not need tail recursion because D supports writing loop constructs. Tail call support is still useful. Looping is not the main reason for supporting tail calls. Eg. a tail call might be indirect and only sometimes recurse on the same function and sometimes call another function. Indeed, I recall Matthias Felleisen wrote that OOP makes no sense without TCO because methods will indirectly call each other. See https://blogs.oracle.com/jrose/entry/tail_calls_in_the_vm#comment-1259314984000 http://www.eighty-twenty.org/index.cgi/tech/oo-tail-calls-20111001.html While I don't care much for OOP, D is supposed to support that style.
Re: GCs in the news
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote: If D came without GC, it would have replaced C++ a long time ago! That's overly optimistic I think, but I believe that the adoption rate would have been far greater for a D without GC, or perhaps with a more GC friendly design, as the GC comes up first or close in every D discussion with prospective adopters. However, it's way too late to change that now. IMO, the way forward involves removing all or most hidden allocations from the D libraries, making programming sans GC easier (@nogc everywhere, a compiler switch, documentation for how to work around the lack of GC, etc.) and a much better, precise GC as part of the D release. Any spec changes necessary to support precision should be in a fast path.
Re: Using D
On Sunday, 13 July 2014 at 12:21:13 UTC, Jacob Carlborg wrote: Yeah, there are many features that could have been implemented as macros instead of in the language, if D had had them from the beginning. What's the status of that DIP? What's the process by which something like that would even get added to D? I very much like the idea. Static metaprogramming and powerful compile time capabilities are the killer features of D, so strengthening them further seems worthwhile.
Re: DStyle: Braces on same line
On Sunday, 13 July 2014 at 17:24:40 UTC, Timon Gehr wrote: On 07/13/2014 06:45 PM, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: Wrong. There are things which are simply bad ideas. E.g. in this case, Egyptian-style braces definitely make your code more compact, I.e. you see where everything is. Yes, the same argument for books and slides is also applicable to all other media. This style has also caught on amongst the other curly braced languages that I use, so that most of the code I read (and write) has adopted it (C/C++/Java/Javascript code, that is). The Phobos style is incredibly wasteful IMO, but that's what D has adopted, so if you intend to contribute to Phobos, you had better get used to it. The Rust community appears to have made the right choice with Egyptian for everything. but separate-line opening braces definitely make it easier to see where scopes begin and end. All of this is subjective, of course, but I definitely don't find that the Phobos style provides this advantage. This is the only argument I have heard in favour of doing this, but it is not actually valid. This critique might apply to Lisp style. Not sure I follow you here. Most of the Lisp I've read is indented like Python, the idea being that you learn not to not see all of the parens and rely on tools like paredit to do the trivial balancing. I'd hate to read Lisp with separate lines for parens that open scopes. I'm sure that's not what you mean!
Re: Languages for servers (Go, D, and more)
On Friday, 4 July 2014 at 19:46:40 UTC, Remo wrote: On Friday, 4 July 2014 at 16:16:35 UTC, Meta wrote: With @nogc and the -vgc compiler switch, I think it would fairly easy now to do C-style memory management and know that there are no hidden GC allocations in your program. Whether you would want to do this in D is another story. Who want to use C-style memory management today ? Lots of interesting programs and libraries are written specifically in C, not C++, even today. But, as others have pointed out, you can use RAII in D and as time goes on even more advanced memory management libraries will become available. But my point was merely that D is somewhat hamstrung by virtue of being a garbage collected language with a not so great GC, and some complexities around not using it. Not an insurmountable problem if you're committed to using D, but when you are making a decision about what to use, it is a factor. For writing various server programs, if you want to work with a GC'ed, compiled to native code language, Go may be a much better choice than D right now. This is a problem with being such a wide spectrum language: D has to compete with high level GC'ed languages and will also need to compete with low level languages without GCs. That's a tough row to hoe!
Re: Languages for servers (Go, D, and more)
On Friday, 4 July 2014 at 14:10:29 UTC, bearophile wrote: D: y u no distinguish between ints/longs/floats/doubles and pointers when taking out the trash? You argue that internal pointers make implementing a precise garbage collector (which wouldn’t mistake numbers for pointers) impossible, but Go managed it in spite of also having internal pointers. It is true that a precise (and moving) GC is desirable for long running servers, and that the Go GC has been receiving a lot of love; it's now stack precise with Go 1.3. I don't recall anyone arguing that internal pointers make a precise GC impossible. But there are plenty of D features that complicate a precise GC, amongst them internal pointers. IMO, the D story around GC is currently one of the weaker parts of the language. Sure, there are workarounds, including not using the GC at all, but then so many features are tied to it that the interested developer may just decide to use a language with a more mature and precise GC, like Java or Go, or none at all like C.
Re: DConf Day 1 Panel with Walter Bright and Andrei Alexandrescu
On Friday, 27 June 2014 at 20:39:10 UTC, Walter Bright wrote: On 6/27/2014 12:53 PM, Dicebot wrote: http://youtu.be/TNvUIWFy02I Ack, need to work on my posture :-( I just got a chance to watch this, and one thing that I found more unsettling than your posture was your assertion that destructors and finalizers are the same thing, in contrast to Hans-J. Boehm, who asserts that C++ destructors and Java finalizers are completely different facilities. I assume that you've read Boehm's report http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html and if so I'd be interested in why you think he is mistaken, since both of your statements can't be correct.
Re: [OT] Lifetime elision proposal in Rust ( regex macro)
On Tuesday, 1 July 2014 at 15:06:27 UTC, Elvis Zhou wrote: I like this rustbyexample.com, is there a dbyexample.com? Nothing that I know of that's exactly the same, but I'm quite happy with http://ddili.org/ders/d.en/, and I'm anxiously awaiting that last 5% or so being translated. It's author, Ali Cehreli, is a frequent and helpful contributor to this forum. It has lots of examples that you can type in and run, so it should be close enough to rustbyexample. Maybe a Learn D The Hard Way a-la Zed Shaw would also be nice.
Re: [OT] Lifetime elision proposal in Rust ( regex macro)
On Monday, 30 June 2014 at 17:28:06 UTC, Ary Borenszweig wrote: On 6/30/14, 1:50 PM, Nick Treleaven wrote: Hi, This recent proposal looks like it might clean up typical Rust function What are those 'a all over the place? I never understood them :-( Those are lifetimes, which are a part of the Rust type annotation machinery. The syntax is borrowed (pun intended ;-) from ML family languages, which use type variables like 'a, 'b, 'c (pronounced alpha, beta, gamma, or tick a, tick b, tick c) to express parametric polymorphism. Rather than try to explain Rust's lifetimes, I'll point you here http://rustbyexample.com/lifetime.html Rust is still undergoing development, and the lifetime syntax is a bit noisy, so it may change, but the rustbyexample page has been following the Rust nightly builds closely. It's an interesting language, and the Mozilla backing really helps it, but I find D and Nimrod easier to use right now.
Re: DIP64: Attribute Cleanup
On Saturday, 21 June 2014 at 17:11:24 UTC, Peter Alexander wrote: On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote: http://wiki.dlang.org/DIP64 All things being equal, it would be nicer to have consistency, but do we really I want to break almost all existing code? I know you've proposed a tool to do the transition, but there are lots of unmaintained projects out there that are still used, and tutorials/articles/books/university courses written using the existing syntax. Those likely won't be, or can't be changed easily. One possible compromise might be to leave the old syntax there for legacy reasons, but allow (and encourage) @pure, @nothrow, etc. I completely agree with your point, but if things never get cleaned up we'll need a guy like Scott Meyers to explain the overcomplicated result. I don't know how to resolve this issue, opponents of change will claim that a language will never get traction if it changes too much too quickly, and proponents will claim that not removing inconsistencies leads to a mess. Both are right.
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote: http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1 The arguments against D are pretty weak if I'm honest, but I think it's important we understand what people think of D. I can confirm this sentiment is fairly common in the industry. Notice that in his post and the comments, a recurring (negative) issue is garbage collection. This is pretty common with mentions of D on reddit too, always a few posters mentioning D's GC as a negative. So many of those comments could be made obsolete by a decent precise garbage collector, and perhaps a compiler switch like the 'noruntime' one that Walter proposed a few months ago. On the plus side, D is mentioned prominently and in the comparison with C++ template programming D really shines.
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 12:20:13 UTC, bearophile wrote: Peter Alexander: http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1 From the post: If I have to point at what is most needed for productivity, I'd say interactivity. Interactive visualization, manipulation, REPLs, exploratory programming, live-coding. A language has both ~native efficiency and is usable for that level of interactivity is Julia :-) My own experiments with Julia massively contradict that statement. I wrote some basic scripting programs that read large text files into hash tables which count word occurrences and Julia's performance was abysmal compared to D and Java.
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 16:02:18 UTC, Dicebot wrote: Another thing I have found funny is that how he both mentions GC as an issue an favors Go (with mandatory GC) over Rust (dismissing it memory model as irrelevant). Well, he mentioned that Go's mandatory GC is a negative in game dev, and only a positive vis-a-vis Rust in that Rust requires some advanced type machinery to ensure memory safety sans GC. GC does have large pluses and minuses, so it's easy to contradict ones self when discussing it. I think D would have been better off not requiring it, but trying to be GC friendly (like Rust and Ada), but that ship sailed a long time ago. Now I'd just like to see D acquire a very good GC and the ability to easily write code which doesn't use it, or uses a specialized one, or turns it off, etc. This post really reads more like a casual rant than well-established opinion. Agreed, but it's on a topic dear to all of us :-) I'm pretty optimistic about D's future. The negatives in that rant weren't so bad.
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 20:53:58 UTC, w0rp wrote: I'm going to try my hand at making a game with 2.066, because I believe @nogc is a final piece in a puzzle of making doing that easy. Much like writing bare metal D code without the runtime, I'm going to try my hand at writing D code with the main function marked as @nogc, because I reckon it's going to leave me with a saner set of syntax and semantics than either C or C++ in the end, with none of the drawbracks from the stop the world effect in a game loop. Good luck, I'm sure a lot of people are interested. Having said that, I do think there's some kind of brain malfunction on the part of games programmers that makes them think is slow and can't escape from when they hear garbage collector There's a similar brain malfunction on the part of GC advocates that makes them think GC programs are just as performant as non GC'ed programs at no cost. (**) On the Lang.Next panel, Andrei said something like For the same payload the garbage collected program uses 3 times as much memory and researcher Emery Berger writes that http://people.cs.umass.edu/~emery/plasma/emery/memory-management-studies.html ... a good GC can match the performance of a good allocator, but it takes 5X more space. If physical memory is tight, however, conventional garbage collectors suffer an order-of-magnitude performance penalty. That's not even taking into account the non-determinism of tracing GC or the issues of finalizers vs destructors or ... Being able to turn off GC, and having the libraries not hit the GC, are all important. and makes things more complicated and slower when they hear template. Neither of these things are true. D metaprogramming is a winning feature. But GC has a number of costs as well as a number of benefits. (**) I much prefer working in a GC'ed language with high level features that require a GC (full closures!) but if resources are tight I think you need to give up some pleasant features.
Re: Interview at Lang.NEXT
On Thursday, 5 June 2014 at 12:46:24 UTC, Atila Neves wrote: I don't know, but the only language I've used with no static types that made me comfortable was Common Lisp. That was a long time ago, but I think it was the ease of manually testing the code in a REPL that did it. Obviously today I'd write unit tests anyway. Atila There are languages with good static type systems (OCaml, F#, Scala, to name a few) that have REPLs as well, and they're quite useful there too. I'm fond of Lisp, and I think Lisp macros are very powerful and useful. I like Python's (really ISWIM's) indentation sensitive syntax. But, as someone who uses 'dynamically typed' languages daily, I think static typing is a huge win and don't understand why anyone would not want to use a language with static types, especially if they were mostly inferred and so the annotation burden was minimal. ML is the language of the future ;-)
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Thursday, 29 May 2014 at 18:52:53 UTC, Brian Schott wrote: On Thursday, 29 May 2014 at 18:12:10 UTC, Dmitry Olshansky wrote: And no, it doesn't matter how the current frontend implements it, because you can argue next to any decisions this way. When issues like this come up the spec is almost always changed to match the DMD front end instead of the other way around. I believe that the result of this policy will be that the D community will need to have Scott Meyers or someone like him to explain some of these issues. :-) It may not be as bad as C++, but is that how we want to measure a language design? Sure, it looks bad, but it could have been so much worse! Why are we afraid of breaking code that relied on behavior that was not in the language specification? My guess is that the fear of 'breaking' some users' code is too great right now. That was one of the things I took from Meyers' talk; the D designers still have an opportunity to be bold in introducing changes that make the entire design better (more easily explainable) while in C++ that opportunity has probably passed. That makes it almost impossible to fix accepts-invalid bugs. It's a problem that needs to be addressed. Thanks for your efforts and for continually reminding people. I really liked your lightning talk; it could have followed Meyers' and maybe the right people would have been shamed into action.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Wednesday, 28 May 2014 at 23:07:07 UTC, Walter Bright wrote: Some of the inconsistencies you mentioned and Brian mentioned in his talk are actually the result of consistencies. I know this is a bit of a difficult thing to wrap one's head around, but having something be mathematically consistent and humanly consistent are often at severe odds. Could you elaborate? Using some of the examples Brian gave, which ones do you think are are mathematically consistent/human inconsistent and which the inverse?
Re: Julia vs. D?
On Tuesday, 6 May 2014 at 11:20:33 UTC, Paulo Pinto wrote: On Tuesday, 6 May 2014 at 09:11:30 UTC, Chris wrote: I recently came across this article http://www.wired.com/2014/02/julia/. On the Julia homepage there are some benchmarks times relative to C. I know that bearophile has mentioned Julia several times on this forum. Has anyone compared D's vs Julia's performance as well as design features? I can only comment on design features. You can think of Julia as a dynamic language similar to Python, with optional typing and for such a young language, a quite good JIT compiler backed by the LLVM backend. It is a multi-paradigm language, with an OO approach based on multi-methods and direct support for scientific programming. The target audience are the scientifc community that makes use of R, Python with NumPy and so on, which are currently disappointed with the performance of said systems. Their goal is to keep the programming flexibility of R and Python, while improving the performance without having to be forced to write C code. Excellent summary, one quibble, you omit MATLAB and Octave users from your target audience, when they may be the most important one. Julia reads much more like MATLAB than like R or Python, and numerical linear algebra is one of the things Julia is being aimed at. It has a very rich language of types, and a macro system. Disappointingly, whilst you can annotate function arguments and variables with types, you can't annotate the function itself with a return type. TL;DR MATLAB reimagined by Lisp hackers. I like it! Not really competing in the same space as D. Yes, I know, I'm pigeonholing D, which is supposed to be a wide spectrum language, etc. etc.
Re: Enforced @nogc for dtors?
On Monday, 5 May 2014 at 14:17:04 UTC, Orvid King via Digitalmars-d wrote: Also, the @nogc for destructors is specific to the current GC, and is a limitation that isn't really needed were destructors implemented properly in the current GC. How does one implement destructors (described below) properly in a garbage collector? I'm a bit puzzled by the recent storm over destructors. I think of garbage collected entities (classes in Java) as possibly having finalizers, and scoped things as possibly having destructors. The two concepts are related but distinct. Destructors are supposed to be deterministic, finalizers by being tied to a tracing GC are not. Java doesn't have stack allocated objects, but since 1.7 has try-'with resources' and AutoCloseable to cover some cases in RAII-like fashion. My terminology is from this http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html IMO, since D has a GC, and stack allocated structs, it would make sense to use different terms for destruction and finalization, so what you really want is to properly implement finalizers in your GC. I'm a lot more reluctant to use classes in D now, and I'd like to see a lot more code with @nogc or compiled with a the previously discussed and rejected no runtime switch. Interestingly, Ada finalization via 'controlled' types is actually what we call destructors here. The Ada approach is interesting, but I don't know if a similar approach would fit well with D, which is a much more pointer intensive language.
Re: Enforced @nogc for dtors?
On Monday, 5 May 2014 at 17:46:35 UTC, Orvid King via Digitalmars-d wrote: Destructors and finalizers are the same thing. That is exactly the point that I am arguing against. That they are confused in D (or 'unified', if you think is a good thing) I accept, but I think it's a language design error, or at least an unfortunate omission. Did you read the citation I provided? I think Boehm's argument is convincing; you've provided no rebuttal. The entire brouhaha going on now is because they're different: we assume that destructors will be called at a precise time so we can use them to manage constrained resources and we don't know that about finalizers.
Re: python vs d
On Wednesday, 30 April 2014 at 11:41:29 UTC, logicchains wrote: On Tuesday, 29 April 2014 at 17:05:50 UTC, Brian Rogoff wrote: You must be perpetually perplexed then, because Haskell, Clean, F#, Nimrod and many other languages also use whiitespace to signify indentation. I suppose I haven't found the whitespace in Haskell and F# so bothersome because the static type systems catch most of the mistakes at compile time that would occur in Python. Haskell also allows optional braces instead of whitespace (whitespace is just syntactic sugar for braces), which can be quite useful at times, especially when copying code. Right, it's not the significant indentation which perplexes you, but the complete lack of compile time checking from Python. I'm perplexed that anyone could prefer that too, but I suppose those programmers who are way smarter than me and don't make any mistakes find types burdensome, or are always writing correct code that can't be type checked by any current checker.
Re: python vs d
On Tuesday, 29 April 2014 at 14:01:44 UTC, logicchains wrote: As someone who only occasionally uses D and Python, I just wanted to add as a datapoint that I find the D compilers an order of magnitude more agreeable than the Python interpreter. The thought that anybody could actually enjoy significant whitespace baffles me. You must be perpetually perplexed then, because Haskell, Clean, F#, Nimrod and many other languages also use whiitespace to signify indentation. The argument is roughly like this: if we accept that it would be a good thing if there was a universal indentation/code formatting standard that everyone followed (like gofmt for Go) then punctuation is redundant and the remaining question is whether the added punctuation helps or hinders readability on the whole. I'm guessing you find the lack of punctuation to hinder readability. I find that the opposite is true, and so enjoy reading such code more. I'm also a frequent user of Python and my main issue with it is the lack of static typing, not the syntax. I'm a rather slapdash coder and I benefit greatly from a type system that gets in my way. The same is true of most Lisps too; I'm fine with the syntax, but I suffer from the lack of static typing. BTW, there is even a surface syntax for D2, https://github.com/pplantinga/delight, which uses indentation, though I have to say that I dislike the separation of function and procedure a lot.
Re: Discusssion on the Discussion of the Design for a new GC
On Thursday, 24 April 2014 at 06:10:00 UTC, Rainer Schuetze wrote: On 23.04.2014 20:35, Messenger wrote: What is the state of Rainer Schütze's precise gc? Duplication of effort and all that. The implementation relies on correct RTInfo generation, but that still doesn't work as this pull request is sitting there for 8 months now without getting much review: https://github.com/D-Programming-Language/dmd/pull/2480 So this PR is the main blocker to a working heap-precise GC? Given all of the talk and energy spent around the GC issue I'd have thought this would be on some super duper high priority fast path for inclusion. Nothing wrong with other GC projects but this seems like the lowest hanging fruit. Coincidentally, I updated the PR just a couple of days ago. The precise GC changes for druntime are here: https://github.com/rainers/druntime/tree/gcx_precise2
