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
Re: warp: a fast C and C++ preprocessor
On Monday, 31 March 2014 at 03:25:37 UTC, justme wrote: On Monday, 31 March 2014 at 00:09:34 UTC, Leandro Lucarella wrote: I mean, if someone wants to have fun, go ahead, but putting community effort on that where there are so many places that are more important to put the effort on seems a bit silly. Agreed. Walter taking 2 weeks to do something comparable to what the clang and gcc guys have done over many years, serves as massive advertising for D. Maybe, but sober observers will realize that Walter could probably have done something similar in C++. That doesn't negate your point though, that it's a good ad for D. Also, here we now have an entire project written by the man himself. That should serve as required reading for anybody who wants to learn how to code in the latest D. I made a first pass through. I notice that almost every 'alias' is of the form alias existing_name new_name; I thought that in the latest D the alias syntax was alias new_name = existing_name; Should I be following Walter's lead with respect to alias?
Re: fold: a replacement for reduce
On Thursday, 27 March 2014 at 13:23:27 UTC, monarch_dodra wrote: On Thursday, 27 March 2014 at 12:48:41 UTC, Simen Kjærås wrote: Your new fold (foldl? Should we have foldr as well?) fold (from what I understood) is what you call foldl. It was discussed to not introduce foldr, as it's just fold!(binaryReverseArgs!Fun)(range.retro);. I'm not sure I was able to understand what the difference between fold and foldl is... In functional languages, fold_left(f, a, [b1, ..., bn]) is f((... (f, (f, a, b1), b2) ...), bn) as you can see, the innermost f call is on the leftmost sequence element, and fold_right(f, [a1, ..., an], b) is f(a1, (f a2 (... f(an, b) ...))) That's how I think of them.
Re: fold: a replacement for reduce
On Thursday, 27 March 2014 at 14:45:05 UTC, monarch_dodra wrote: On Thursday, 27 March 2014 at 14:41:19 UTC, Brian Rogoff wrote: On Thursday, 27 March 2014 at 13:23:27 UTC, monarch_dodra wrote: On Thursday, 27 March 2014 at 12:48:41 UTC, Simen Kjærås wrote: Your new fold (foldl? Should we have foldr as well?) fold (from what I understood) is what you call foldl. It was discussed to not introduce foldr, as it's just fold!(binaryReverseArgs!Fun)(range.retro);. I'm not sure I was able to understand what the difference between fold and foldl is... In functional languages, fold_left(f, a, [b1, ..., bn]) is f((... (f, (f, a, b1), b2) ...), bn) as you can see, the innermost f call is on the leftmost sequence element, and fold_right(f, [a1, ..., an], b) is f(a1, (f a2 (... f(an, b) ...))) That's how I think of them. Right, but what about fold vs fold_left? Is there a difference? There's just fold_left and fold_right, or foldl and foldr if you prefer, though if f is associative they're both the same.
Re: Improve D's syntax to make it more python like
On Saturday, 22 March 2014 at 13:03:06 UTC, Russel Winder wrote: ALGOL60 did not have significant whitespace and an offside rule, just like C, C++ and D don't, whereas Python, OCaml, etc. do. I've programmed in OCaml for many years and I somehow missed the significant whitespace. Even the Revised syntax for OCaml (the improved and unused one) did not use significant whitespace, though I recall that there were unloved projects to provide such a syntax. C++ has a much nastier syntax than D (IMO of course :-) but the SPECS proposal for a resyntaxed C++ never caught on. I liked some of the improvements suggested there, in particular the more Pascal-ish or Scala-ish declaration syntax, and would have liked something like that in D, but there are so many more issues to be fixed that daydreams of improved syntax seem frivolous to me.
Re: Walter's DConf 2014 Talks - Topics in Finance
On Friday, 21 March 2014 at 22:33:37 UTC, TJB wrote: On Friday, 21 March 2014 at 22:28:36 UTC, Walter Bright wrote: It's a good thought, but I have zero knowledge of how C++ is used for high frequency trading. I would be happy to help you with an option pricing example that is commonly used. Let me know if you are interested. This is a very interesting thread that you started. Could you flesh it out more with some example C++ that you'd like compared to D? I'm sure quite a few people would assist with a translation. I'm not expert in high frequency trading, but I was inspired by your post to start poking around here http://www.quantstart.com/articles/european-vanilla-option-pricing-with-c-via-monte-carlo-methods and study some of the algorithms. Nothing there that I wouldn't rather see in D than C++. D's GC is problematic, but the hope is that you can avoid allocating from the GC'ed heap and that eventually (soon? please?) it will be replaced by a better precise GC.
Re: Improve D's syntax to make it more python like
On Saturday, 22 March 2014 at 18:08:01 UTC, evansl wrote: On 03/22/14 11:14, Brian Rogoff wrote: [snip] C++ has a much nastier syntax than D (IMO of course :-) but the SPECS proposal for a resyntaxed C++ never caught on. Brian, could you provide a link for this proposal? I'd appreciate it. -regards, Larry http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html I think there is an expanded version of this report too, but this gives you the flavor. Note that it is based on a fairly old version of C++. I prefer the D !() for templates to their [], but I prefer their declaration and pointer syntax. I don't think D's current syntax is really a problem. Well, there are some things that vex me a bit, like the multiple alias this and also the is syntax. Even though I prefer indentation sensitive syntax to C style syntax, if there were a front end for D that used an alternative syntax I would not use it. I suspect that I'm hardly unique in that either.
Re: Improve D's syntax to make it more python like
On Saturday, 22 March 2014 at 16:28:11 UTC, Paulo Pinto wrote: When F# was still in beta, it had OCaml syntax as default with a significant whitespace mode that could be turned on with a compiler directive #light on. While asking the embryonic F# community which mode should be the default. The significant whitespace mode won and became the default, with the OCaml mode being the optional one. That's not too hard to believe. I like OCaml a lot but its syntax is not its best feature. The OCaml preprocessor (CamlP4) had an improved syntax called Revised as one of its applications. As I recall, Gerard Huet (who publicized 'the zipper') used a subset of Revised he called Pidgin ML in his publications. They looked a lot nicer than regular OCaml. I've never written any F#, since I live in the world of Unix, and never visit Windows. It looks like it has some interesting improvements over OCaml (let!, async stuff, LINQ, some overloading, ...) but has a weak module system compared to OCaml.
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 20:43:24 UTC, Mason McGill wrote: On Friday, 21 March 2014 at 18:47:49 UTC, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks. What draws you to D, if not the syntax? Definitely not the syntax! The promise of a relatively high level statically typed language with low level control and C/C++ levels of performance. That's what I'm looking for with D. I choke down the syntax, telling myself at least it's better than C++. If you're looking for a fast, Python-like language, and you don't mind dependence on the CPython runtime, I'd suggest looking into Cython (http://cython.org/). If you're interested in modern language features and expressive metaprogramming with a Python-like syntax, I'd recommend Julia (http://julialang.org/). You're wrong about Julia. The syntax is most reminiscent of MATLAB and Octave. Others are wrong comparing Ruby/Perl/whatever to Python, at least the syntax. I find Python syntax very readable, it's the type system and semantics of Python that I dislike. Closest language to D with a Pythonesque syntax is Nimrod, nimrod-lang.org It's author, Araq, sometimes reads this forum. I believe that Haskell is the most popular statically typed language with indentation sensitive syntax. But Haskell is a lazy functional language where programming with side effects is more difficult. That's not like D. I doubt there's much interest in a new syntax for D. You may as well find or create a different language if it bothers you. I empathize, but I'm certain you'd be better off just getting used to the existing D syntax.
Re: Final by default?
On Thursday, 13 March 2014 at 12:01:15 UTC, Daniel Murphy wrote: Don wrote in message news:ekymfpqyxasvelcix...@forum.dlang.org... I agree completely. Some things that really should be fixed, don't get fixed because of a paranoid fear of breaking code. And this tends to happen with the issues that can give nice warning messages and are easy to fix... As usual I agree with every single thing in this post, and Sean's. Regressions are bad but have nothing to do with using slow, controlled deprecation to make the language better. It might be worthwhile to consider a compiler switch which would require forced virtual/final annotations on all methods as per https://d.puremagic.com/issues/show_bug.cgi?id=11616#c4 While code compiled with such a switch would be a bit more verbose, it would ensure that programmers were careful with virtual. It was a good transition plan, and the idea has value even if the final by default is delayed or abandoned. I'd like to see final by default in D rather than it's successor. It seems quite a bit easier to fix than some other unfortunate default choices.
Re: Broken?
On Tuesday, 11 March 2014 at 18:33:16 UTC, Daniel Kozák wrote: Steven Schveighoffer píše v Út 11. 03. 2014 v 14:14 -0400: Consider how long Walter resisted the call to make functions final by default, until he suddenly switched sides. I think of it like a dictatorship with 1000 advisors. And no death squads :) If he resisted for a long time, it makes little sense to say he suddenly switched sides. Reviewing the old thread, it looks like Manu's arguments amongst others were convincing that this change is worth it. I have mixed feelings on this topic. I think methods should be final by default, but it is late in the day for these kind of changes, especially given D's unpleasant history with respect to changes. -- Brian
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 14:27:48 UTC, Paulo Pinto wrote: On Friday, 21 February 2014 at 13:08:37 UTC, Francesco Cattoglio wrote: On Friday, 21 February 2014 at 12:56:32 UTC, Paulo Pinto wrote: That is easy to answer, I doubt they could with their rule of not having more than 5 characters per keyword. :) Wait, what? REALLY? What kind of rule is that. ahahahha... are they stuck to the 70's? :D Yes really, http://forum.dlang.org/post/glnafbocwjodiwrqw...@forum.dlang.org I just cannot find the Reddit thread any longer. Obviously, there is no rule in Rust that keywords have no more than 5 letters (return, extern, ...) but the designers favor short keywords, maybe a bit much for my taste. OTOH, I prefer their preference for favoring immutability and expression oriented style to D's statement oriented preference. The latest version of Ada tries to fix Ada a bit in this regard http://www.ada-auth.org/standards/12rat/html/Rat12-1-3-2.html but it's a bit late. I'm glad to hear that Ada use is increasing somewhere, but I don't see it in any market I look at. The Rust designers are targetting C and C++ users, with a different vision than Walter and Andrei's as to what constitutes C++ done right, and some specific applications, like Servo. -- Brian
Re: D as A Better C?
On Wednesday, 12 February 2014 at 15:40:54 UTC, Sean Kelly wrote: This would certainly be a useful feature to have when porting, and Walter clearly uses it himself. Assuming this can be done with minimal work, I'd say make it a DMD thing rather than a D thing in general. Like -profile. And add a switch to enable it in the front-end if possible. Then DMD (and potentially the other compilers) will have the feature in case anyone finds it useful and we can move on. Call it -minimal. Good compiler flag name choice. I have a feeling we've already spent more time talking about this than Walter would have spent implementing it anyway, so it's already taking time away from other things. Let's just give it a nod and move on. By 'nod' you mean Bugzilla entry, right? The flag would have to be documented. While better C is descriptive, it's not very helpful. I like the idea a lot. If it's truly low hanging fruit, then yeah it should be done, but I get the concerns that others have about D and unfinished business. Tough decision!
Re: D as A Better C?
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote: I've toyed with this idea for a while, and wondered what the interest there is in something like this. The idea is to be able to use a subset of D that does not require any of druntime or phobos - it can be linked merely with the C standard library. To that end, there'd be a compiler switch (-betterC) which would enforce the subset. (First off, I hate the name better C, any suggestions?) The subset would disallow use of any features that rely on: 1. moduleinfo 2. exception handling 3. gc 4. Object I've used such a subset before when bringing D up on a new platform, as the new platform didn't have a working phobos. What do you think? Which D metaprogramming (templates, mixins, ctfe, ..) features would be in this D subset? Would the non-gc'ed functional programming features (downward funargs) be in the subset? If the answers are all and yes I'd be very interested, if none and no then much less interested. Please say more about which features you expect to make the cut. D-lite, while already used, is the natural name choiec. As others point out, there's some risk of fragmentation, but there's precedent even in unsubsettable languages like Ada (SPARK) so I don't think the risk is so great. -- Brian
Re: Componentizing D's garbage collector
On Sunday, 12 January 2014 at 10:40:50 UTC, Benjamin Thaut wrote: Am 12.01.2014 11:27, schrieb Rainer Schuetze: I think a moving collector is currently not feasible without restricting the language a lot, probably similar to safe D and more. I'm not sure we want that in general. I'd rather have more restrictions and a working precise GC, and let those who wish to do without the safety ask for it explicitly. Could you give an example which part of the language would not be doable with a moving collector? The only thing that comes to my mind is unions and that problem can be solved by allowing the user to specify manual scanning functions for structs or classes containing unions. How would the moving GC deal with pointer arithmetic? Also I don't think that we can create a GC which performs as good as the one of Java or C# if we are not willing to make the neccessary changes for a moving gc. I agree. Even ignoring the comparison with Java/C#, I think if D is to be a 'fully garbage collected language' then it will have to support a state of the art GC.
Re: Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector
On Thursday, 9 January 2014 at 21:35:45 UTC, qznc wrote: On Thursday, 9 January 2014 at 19:41:43 UTC, H. S. Teoh wrote: because if D can get a GC that's on par with Java's, then D can totally beat Java flat, since the existence of value types greatly reduces the memory pressure on the GC, so the GC will have much less work to do compared to an equivalent Java program. Java will probably gain (something like) value types at some point. Google for packed objects, it provides similar gains as value types. Hopefully, D gets a better GC first. What's the status of all that? There were interesting talks at DConf 2013 about precise and concurrent GCs, and it seemed that work was going on to fold all that into the compilers, and that Walter/Andrei were ready to make changes to the spec and runtime if needed to support precise GC. All very encouraging. Will DMD have a precise GC by the next DConf? -- Brian
Re: Microsoft working on new systems language
On Monday, 30 December 2013 at 12:20:36 UTC, bearophile wrote: But the Oracle JVM has a GC (more than one) way better then the current D one :-) Of course. But Java requires a world class GC and state-of-the-art escape analysis to achieve excellent performance. These would be nice to have in D, especially the super duper GC, but D will be fine IMO once it has a decent precise GC since it won't be pounding the GC as hard as Java would. I hope that after the ICE removal release coming up soon that there will be a 'get the precise GC working' release. As far as escape analysis goes, I rather wish D had stolen some ideas from Ada (95) like 'aliased' and restrictions on address-taking and pointers, but I suppose that will have to wait for D2++. -- Brian
Re: D benchmark code review
On Saturday, 14 December 2013 at 19:32:45 UTC, Chris Cain wrote:
On Saturday, 14 December 2013 at 16:22:41 UTC, Ola Fosheim
Grøstad wrote:
Regarding using the not-operator for non-not-operations:
anything would be better than reusing operators that are
commonly used to affect control-flow. It makes it difficult to
comprehend control flow when you skim code you are not
familiar with. not tends to be used for completely changing
the flow of a program so those ! are attention-seekers when
trying comprehend unfamiliar code.
But still, _what exactly_ should be used instead of the
not-operator? Anything is too vague and not true. You
probably can't use these: ][+=-_,.|`\/';:}{%^*
Composite brackets, a-la the SPECS 'C++ Resyntaxed' ** proposal,
would work. [], [[]] may be a bit heavy but not too bad.
I haven't found the !() syntax for D templates to be a problem
though and prefer it to from C++ and Java. If I were searching
for D blemishes, I wouldn't look there first.
-- Brian
**
http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html
Re: D benchmark code review
On Friday, 13 December 2013 at 16:40:13 UTC, Manu wrote: I'm just saying, if it's code to be compared against other languages, then it should conform to the general standards of the language. I've never seen D code use egyptian braces. You've never read TDPL. .. or Ali Cehreli's D tutorial. ... or looked at the D Rosetta code examples Certainly the vast majority of D code doesn't. I don't care which, but stick with one as a 'standard'. D has clearly chosen C braces, D is not a sentient being and can't choose anything. Some group of D coders chose that brace placement and 8 space indentation. Others have chosen a style which favors less extravagant usage of screen or book page real estate. If you were going to publish some Java code using C braces, how would you feel about that? Feel free! I acknowledge that Phobos has specified a style, but this isn't a Phobos submission. I can read either (and more!) but I have noticed that what you're calling Java style is catching on across a number of languages with C inspired syntax. There are advantages to that. If you feel strongly about this you may prefer Nimrod, which removes the choice from you, like Python. There are advantages to that, too. -- Brian
Re: D benchmark code review
On Friday, 13 December 2013 at 17:30:09 UTC, Manu wrote: On 14 December 2013 03:10, Brian Rogoff brog...@gmail.com You've never read TDPL. Published material, optimised for print. Andrei admits this. He uses C braces in his code. I don't see why 'optimized for print' isn't a strong argument for code being read from a terminal or browser or IDE or whatever, but I accept that this is a matter of taste. .. or Ali Cehreli's D tutorial. Possibly following Andrei's lead, and possible consideration for print? Or possibly Ali just prefers this style? ... or looked at the D Rosetta code examples No, not really. That's a bit sad. I'd make the same argument there if it's as you say though. It is as I say. Also with much of the C++ and Java (as you would guess) submissions. I don't find it sad. I find it sadder that 8 spaces was chosen for the Phobos indentation. If you were going to publish some Java code using C braces, how would you feel about that? Feel free! You're saying you wouldn't find it unconventional, and perhaps ammateur looking? No, I'm not saying that. I would find it unusual. As I said, I've noticed that the publication style indentation is becoming more widely used in C and C++ as well. I'm just saying that I've grown used to reading many different styles, so I wouldn't assume amateurism, but given the code I've been reading and what I said above anything that isn't publication style looks a bit unusual to me. More so in Java, as you say. BTW, I like the term 'Egyptian style', but 'publication style' more accurately suggests its rationale. I only feel strongly about not being ambivalent on the matter. When I write Java, I use egyptian braces, and then it looks like Java code. Most people seem to understand that that's an expectation in Java. When I write C code, I use C braces. I think C became widely confused soon after university CS courses started teaching Java primarily, then you have inexperienced post-grads bring their Java habits into their C code. I remember discussion of this in C long before Java became popular. I learned to just use whatever other programmer's had used on any given project. If there is a choice, some people will make different choices. If D deliberately commits to the 'university post-grad syndrome' principle that C has found itself in, then I find that to be sad. However, clearly, since there's debate on this, D _has_ already inadvertently made that commitment. Oh well. I don't think it's a university thing. Nor am I suggesting that there is debate: the course for Phobos has been charted. What I'm suggesting is that the entire D community isn't committed to that style. You can enforce it on your own projects, but that's your choice. -- Brian
Re: Ensuring template argument is descendant of class
On Friday, 13 December 2013 at 05:55:09 UTC, H. S. Teoh wrote: On Fri, Dec 13, 2013 at 06:42:26AM +0100, Brian Rogoff wrote: I'm sympathetic to this POV, or something similar. For example, a multiyear plan to deprecate the 'is' syntax and replace it with something better, in the current D. I'm not a fan of gratuitous changes which make the language unstable, but if there were a pleasing design to replace 'is' I'd like to think that D users could change the relevant sources given a long enough deprecation window. I vote for this. Good luck convincing Walter, though. Step 1 is to come up with a set of better design alternatives, and a transition plan, etc. I'm pretty sure I've read posts from Walter on this forum that agree with the current 'is' is far from ideal, so maybe convincing him is not as hard as you think, though I imagine he has bigger fish to fry these days. Still, it would be encouraging if the D community could address the general issue of *not* being forced to keep bad designs forever. -- Brian
Re: Ensuring template argument is descendant of class
On Friday, 13 December 2013 at 05:22:26 UTC, Ross Hays wrote: Yeah, is-expression syntax is one of the dark, ugly corners of D that unfortunately we're stuck with, because changing it now will totally break a LOT of code for merely cosmetic reasons. I honestly wish that one day this mess could be cleared up, though I'm not holding my breath for it. T I know this is probably obvious, but if D were allowed to just make one big breaking change for D3 or something, and fix every dark corner it has. Would that really be so bad? I know it would break things but... I kind of long for it. I'm sympathetic to this POV, or something similar. For example, a multiyear plan to deprecate the 'is' syntax and replace it with something better, in the current D. I'm not a fan of gratuitous changes which make the language unstable, but if there were a pleasing design to replace 'is' I'd like to think that D users could change the relevant sources given a long enough deprecation window. Changing every dark corner and every poor choice is too much. For instance, a lot of people think that immutability and 'nothrow' should have been the default, but changing that would be dramatic and probably will have to wait for a D3 or new language. -- Brian
Re: Facebook puts bounties on bugs in the D programming language implementation
On Saturday, 16 November 2013 at 00:45:18 UTC, Andrei Alexandrescu wrote: How do you mean that? The budget is of course much larger than that. I'd just started assigning it. Andrei What's going to be the bounty for getting a precise GC in D? Is it even fair to say there's a single bounty hunter? OK, OK, just kidding! I think it's great that FB does this. -- Brian
Re: Delegate is left with a destroyed stack object
On Wednesday, 30 October 2013 at 20:35:14 UTC, Peter Alexander wrote: I think not running the destructor is the best option (although to be honest, I'm not a huge fan of closures to begin with, for exactly these sorts of reasons -- they only really work well in a pure functional setting). I disagree. Closures work well in Scheme (more generally, Lisps) and ML, which are not purely functional languages. In SICP *, the combination of closures and mutable state is used to model OO. I used closures more than I used OO in OCaml. Things are trickier in D for a trickier of reasons. You may be right about not running the destructor; I'm still thinking about it. -- Brian * The Structure and Interpretation of Computer Programs by Abelson and Sussman, for those who don't know.
Re: matrix business in D
On Friday, 18 October 2013 at 13:04:51 UTC, bearophile wrote: Julia is a very new language, quite newer than D. I don't think it's a good idea to recommend it for real work. I don't think that the simple rule comparing age of the languages in question for risk assessment is very useful. Given all of the other variables, I'd be more likely to recommend Julia for numerical linear algebra today than D for the same role. That's not a slam on D, which I mostly like better than it's competition (C++, Rust, C, ...) but rather an observation that the Julia community is entirely focused on this domain. A really risk averse programmer who wouldn't consider Julia in this domain wouldn't consider D either -- Brian
Re: std.linalg
On Friday, 11 October 2013 at 23:24:00 UTC, Andrej Mitrovic wrote: On Friday, 11 October 2013 at 23:13:34 UTC, Andrei Alexandrescu wrote: Honestly I first thought it was linear-time algorithms. Andrei I thought it was some kind of algae species. Why not just call it std.algebra? Because, amongst people who know, numerical linear algebra algorithms form their own little world of computing apart from what may be called 'algebra'. 'Algebra' could mean any number of things, like symbolic algebra, but the entire world of MATLAB/R programmers know exactly what linalg might be. Numerical linear algebra. See the reference text by Golub and Van Loan. I would try to fit this module under some larger numeric or scientific computing hierarchy, but I don't see one in D yet. The Julia language is the competitor here, and it is already well ahead of D, but who knows how the race will end? -- Brian
Re: Move VisualD to github/d-programming-language ?
On Sunday, 8 September 2013 at 11:48:06 UTC, Paulo Pinto wrote: Am 08.09.2013 13:24, schrieb Russel Winder: On Sun, 2013-09-08 at 00:35 +0200, Paulo Pinto wrote: […] And why is the target audience for D only C and C++ people? Surely the target audience for D is any programmer wanting a native code executable. Because many of us are actually aware of compilers that produce native code for our languages, even if they are not the default way to use them. If you're used to using an IDE, let's say IntelliJ for Java, and you may also want to develop in D, why shouldn't you be able to use that IDE, and not context switch? There may be more of a market for Java/Python/whatever programmers interested in D than you think. To make it more clear, the ML family of languages, Pascal family of languages, even JVM and .NET environments have native compilers available. You just have to look for them. IMO, D has more potential as a native code compilation target than Java, C#, and ML, at least in theory, because I should be able to control and even disable garbage collection. So, even users of managed languages may want to examine D. -- Brian
Re: assert() vs. enforce(), invariant() vs. ... ?
On Saturday, 31 August 2013 at 21:57:37 UTC, Brian Rogoff wrote: On Saturday, 31 August 2013 at 21:30:40 UTC, Andrei That use will stay and is useful and uncontested. Actually, after a bit more experimentation, I don't object to removing the scope on local variable delegates. Replacing those with a nested function declaration and a local pointer to function seems to work fine with no GCing, at a very slight cost in elegance IMO; I prefer the delegates to using '' on a function. It is good to see features being removed from D. -- Brian
Re: assert() vs. enforce(), invariant() vs. ... ?
On Friday, 30 August 2013 at 21:11:32 UTC, Andrei Alexandrescu
wrote:
* scope: cute and dangerous in equal proportions - great for a
movie character, terrible for language design.
I'll argue for it and others can then destroy.
IME, a lot of the value of functional programming (by which I
mean, programming with higher order functions) can be had with
downward funargs, as found in Pascal (and more recently, Ada),
which don't require garbage collection.
The D language expresses closures and higher order functions as
delegates, and uses the heap to manage these. I had assumed that
we could use 'scope' on the delegate being passed to prevent it's
heap allocation, as discussed here:
http://stackoverflow.com/questions/4711309/meaning-of-scope-in-d-for-a-parameter
I wrote a small test case to try this out, in which I construct a
2-D integration function from a 1-D one, and I use Adam Ruppe's
nogc code to seg fault when the GC is hit. Without using a
'scope' on a local variable, I'm forced to pile up the anonymous
function calls to get the behavior I want.
import std.stdio, std.math;
// int delegate(int) adder(int a) { return (int b) { return a +
b;}; }
float integrate(scope float delegate(float x) f, float lo, float
hi, size_t n) {
float result = 0.0;
float dx = (hi - lo) / n;
for (size_t i = 0; i n; i++) {
result += f(lo + i * dx) * dx;
}
return result;
}
float integrate(scope float delegate(float, float) f,
float x0, float x1,
float y0, float y1,
size_t nX, size_t nY) {
scope auto f_y = delegate float(float y) =
integrate(delegate(float x) = f(x,y), x0, x1, nX);
return integrate(f_y, y0, y1, nY);
// I'll have to write it like this to avoid heap allocation
without
// local variable scope
// return integrate((y) = integrate((x) =f(x,y), x0, x1, nX),
y0, y1, nY);
}
The code to test demonstrates the issue better, as I'm forced to
use inline anonymous functions everywhere to avoid the GC calls
(unitCircle and unitSphere omitted for brevity)
void main() {
scope auto funcX_1 = delegate float(float x) = unitCircle(x);
float result1 = integrate(funcX_1 /* (x) = unitCircle(x) */,
-1.0, 1.0, 500);
writefln(integrate(func1, -1.0, 1.0, 500) = %g, result1);
scope auto funcXY_1 = delegate float(float x, float y) =
unitSphere(x,y);
result1 = integrate(funcXY_1 /* (x,y) = unitSphere(x,y) */,
-1.0, 1.0, -1.0, 1.0, 100, 100);
writefln(integrate(funcXY_1, -1.0, 1.0, -1.0, 1.0, 100, 100)
= %g, result1);
}
Yes, it's a toy example, but I do program with higher order
functions a lot in OCaml and I'd probably use them quite a bit in
D, especially if I could avoid impacting the GC.
If scope on local variables is going away, it would be nice if
the compiler could figure out when I'm using delegate args in a
'downward, non escaping' way and not heap allocate. My tests with
DMD indicate that without those 'scope' on the local variable the
GC does in fact get hit, and with them it does not.
-- Brian
PS: I don't really use classes much, so I have little to say
about scope on objects
PPS: If my missive made little sense,
https://en.wikipedia.org/wiki/Funarg_problem
http://stackoverflow.com/questions/581182/what-are-downward-funargs
Re: assert() vs. enforce(), invariant() vs. ... ?
On Saturday, 31 August 2013 at 21:30:40 UTC, Andrei Alexandrescu
wrote:
http://stackoverflow.com/questions/4711309/meaning-of-scope-in-d-for-a-parameter
That use will stay and is useful and uncontested.
Andrei
Sure, but my complaint is that that useful style is cramped by
the inability to have scope on *local variables*. I understand
that scope on function parameters will stay. If you're saying
that scope on local variables for delegates will stay, then
disregard all I've written here, I'm happy! :-).
If you look at the code I posted, try removing scope from the 2-D
integrate and from the local variable declarations in the main()
function, and the program hits the GC, with the scopes, they
don't. The problem occurs when I create the local variables to
name an anonymous function. I tested this with Adam Ruppe's code
which halts when the GC is called.
As I said, I'm not arguing for scope on objects, but for
contrivances which allow me to program easily with downward
funargs and not hit the GC. D goes further than most languages in
this and it would be a shame if this capability is removed with
no substitute.
For those who want to test on their systems, here are the trivial
unitCircle and unitSphere I omitted.
float unitCircle(float x) {
float x2 = x * x;
if (x2 1.0) {
return sqrt(1.0 - x2);
} else {
return 0.0;
}
}
float unitSphere(float x, float y) {
float sum = x*x + y*y;
if (sum = 1.0) {
return sqrt(1.0 - sum);
} else {
return 0.0;
}
}
-- Brian
Re: Question about garbage collector
On Wednesday, 28 August 2013 at 21:28:11 UTC, bioinfornatics wrote: Hi everyone, yesterday i read an article into a french linux journal that in some years garbage collector will disapear. Why ? he explain in very very short as: -- - Moore's law will be not anymore true so only memory will continue to increase ( static and volatil ) - Garbage Collector are not efficient in big memory for some technical reason - Data to manage will continue to grow big data ant full memory stategy will the rule I've had similar thoughts myself for some time. So Develloper will move to a language where they are no garbage collector. There are many different kinds of software and developer, you need to qualify that assertion. GCed languages will not go away. -- In bioinformatic we work with big data or full memory stategy often and that will not stop. So what think D garbage cllector's dev about this ? I hope that D can go either way on this, and allows developers to 'opt out' of GC if they need to, but I don't think it is that easy now. Is there a skeletal 'no GC D' project out there? What is given up (AAs, slices, classes, exceptions, ...) and how easy is it to use? If not, Rust, Ada, and of course, C++ will be there. There are surprisingly few languages being designed to be used without GC these days. -- Brian
Re: Allocators
On Friday, 23 August 2013 at 11:27:06 UTC, Joseph Rushton Wakeling wrote: I recall from discussion a while back that various custom allocators are in the works as alternatives to the GC. Can anyone advise on their status and give a rough idea of what will be offered? It seems you're far from being the only interested party! Has anyone tried porting an existing allocator library from C++? Looking over the dconf proceedings, HeapLayers was mentioned as an inspiration for a future D allocators library; would a port make sense? I remember seeing a D2 region allocator, but it appeared to be abandonware. Assuming you have a really great allocator library, how would that work with the existing GC requiring features of D? For example, could you have all of your slicing, classes, exceptions, etc. handled by a region allocator? -- Brian
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote: There are basically two ways to implement generics. Type erasure (Java,Haskell) or template instantiation (C++,D). Instantiation provides better performance, but sacrifices error messages (fixable?), binary code size, and compilation modularity (template implementation must be available for instantiation). Type safety is not a problem in either approach. See this brief discussion from Greg Morrisett on the topic, with a finer subdivision of approaches http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt that confirms your bad news that monomorphization (C++/D templates) and separate compilation won't play well together. Nor do monomorphization and some advanced type system features work together, but that's less of a worry for D. That said, I like the D approach of putting a lot of power in the macro-like template system. I worry more about the reliance on GC in a systems programming language, as historically that's been a losing proposition. -- Brian
Re: Why I chose D over Ada and Eiffel
On Thursday, 22 August 2013 at 14:37:21 UTC, Dicebot wrote: On Thursday, 22 August 2013 at 14:18:09 UTC, Brian Rogoff wrote: See this brief discussion from Greg Morrisett on the topic, with a finer subdivision of approaches http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt that confirms your bad news that monomorphization (C++/D templates) and separate compilation won't play well together. Nor do monomorphization and some advanced type system features work together, but that's less of a worry for D. Well, in that paper they make a bit too hard statement - such model implies certain limitations for separate compilations (either explicit instantiation or having access to sources) but does not destroy completely. No silver bullet here, every approach has its own pros and cons. Yeah, I agree, there are probably some tricks to make some things better, but overall it's a good description of the problem. Like you say, each approach has tradeoffs. For a systems programming language, I think monomorphization is best. -- Brian
Re: Future of string lambda functions/string predicate functions
On Wednesday, 14 August 2013 at 19:24:43 UTC, w0rp wrote: As mentioned before, for very common lambdas that you don't want to type yourself, you could define those functions as generic functions with a given name, like a 'less' function. Also as mentioned before, the issue is that (anonymous) lambda functions have some subtle issues in regards to templates, because lambda functions cannot be compared for equality (the problem in general is undecidable) while string lambdas can, even though they have the same problem as with some of the unwieldy attempts at comparison (AST comparison after normalization and renaming with De Bruijn indices, or whatever), namely that things that are obviously equal aren't seen as such. That's why you want to name functions, so that templates instantiated with the same function are interoperable. It seems to me that the easiest solution for D would be to deprecate string lambdas, and declare that anonymous lambdas always compare to false. Is the workaround of naming lambdas being used in in separate template instantiations that need to work together so bad?
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 11 August 2013 at 08:22:35 UTC, Walter Bright wrote: http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf Interesting, and certainly D being a wide spectrum language is a reason that many of us investigate it. Julia is aiming at the same space as that mentioned in the paper, so I think that their point that D is the only choice here is not true any more. No comment on the paper's formatting, which seems to its most salient feature :-) -- Brian
Re: D roadmap?
On Tuesday, 23 July 2013 at 00:12:14 UTC, bearophile wrote: ixid: What became of using the comma operator with parens for tuples? I don't know. But I presume Walter is not interested in breaking backwards compatibility with C so much. If that's true, it would be unfortunate. I appreciate the benefits of preserving C compatibility, but that has to be balanced against the benefits of other features. Lightweight tuple syntax is a huge win in every language I've used that has it, and would be a win for D too, even at the expense of compromising syntactic compatibility with C. Not a showstopper if it never shows up, but it would be a disappointment. And yes, commas with parens is probably the ideal syntax. What's the proposed syntax for the types of tuples? A 'blessed' roadmap would also benefit the D world. D the language seems mostly complete at this point, so that many of the exciting advances will be in the runtime (precise GC) and libraries (allocators) and some plan describing when these kinds of things are supposed to make it into the mainstream of D would stir more interest in the language. -- Brian
Re: [OT] Why mobile web apps are slow
On Wednesday, 10 July 2013 at 14:01:51 UTC, Paulo Pinto wrote: On Wednesday, 10 July 2013 at 13:30:26 UTC, bearophile wrote: thedeemon: No mature GCed languages behave that bad. I think there is one JavaVM that manages to avoid part of the problem you explain (and maybe it needs special kernel support). I think all other JavaVMs suffer it, more or less. Bye, bearophile Yes, the C4 garbage collector in the Azul JVM http://www.azulsystems.com/products/zing/whatisit http://www.azulsystems.com/products/zing/c4-java-garbage-collector-wp They used to have special hardware, but now they use standard kernels. RedHat is also planning to have a go at it for the OpenJDK, http://rkennke.wordpress.com/2013/06/10/shenandoah-a-pauseless-gc-for-openjdk/ -- Paulo Interesting. There was some discussion of adding a 'pauseless' GC to Go as well, here https://groups.google.com/forum/#!topic/golang-dev/GvA0DaCI2BU and in that discussion Gil Tene, one of the authors of Azul, opines Starting with a precise and generational stop-the-world implementation that is robust is a must, and a good launching pad towards a concurrent compacting collector (which is what a pauseless collector must be in server-scale environments). Each of those qualities (precise, generational) slaps serious requirements on the execution environment and on the compilers (whether they are pre-compilers or JIT compilers doesn't matter): precise collectors require full identification of all references at code safepoints, and also require a robust safepoint mechanism. Code safepoints must be frequent (usually devolve to being at every method entry and loop back edge), and support in non-compiler-generated code (e.g. library and runtime code written in C/C++) usually involves some form of reference handle support around safepoints. Generational collectors require a write barrier (a ref-store barrier to be precise) with full coverage for any heap reference store operations (in compiler-generated code and in all runtime code). It is my opinion that investing in the above capabilities early in the process (i.e. start now!) is critical. Environments that skip this step for too long and try to live with conservative GC in order to avoid putting in the required work for supporting precise collectors in the compilers and runtime and libraries find themselves heavily invested in compiler code that would need to be completely re-vamped to move forward. ... Sounds like that precise GC talk at DConf was quite timely. Let's hope that prediction about being too heavily invested in conservative GC dependencies isn't too true! -- Brian
Re: [OT] Why mobile web apps are slow
On Tuesday, 9 July 2013 at 20:02:33 UTC, bearophile wrote: On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote: A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ An interesting article, a strong critique of many kinds of garbage collection. Having good enough built-in means to avoid relying on a GC seems quite important to use D where memory is limited. It's not just in the limited memory case of mobile devices that GC is a problem. There are a few domains that come to mind where the ability to escape GC and rely on manual memory management is extremely important. While there was some reference made to an approach to allocators in the closing talk of DConf, I haven't seen much discussion of an approach using D's features. -- Brian PS: That silhouette of the SR-71 at the point allocators are mentioned sets a high bar for the design!
Re: why allocators are not discussed here
On Friday, 28 June 2013 at 10:57:45 UTC, deadalnix wrote: On Thursday, 27 June 2013 at 22:50:47 UTC, John Colvin wrote: Old but perhaps relevant? http://www.linkedin.com/news?viewArticle=articleID=-1gid=86782type=memberitem=253295471articleURL=http%3A%2F%2Fwww%2Eallendowney%2Ecom%2Fss08%2Fhandouts%2Fberger02reconsidering%2Epdfurlhash=96TJgoback=%2Egmr_86782%2Egde_86782_member_253295471 (It's an academic article about memory allocation from 2002) Interesting paper. Still concurrency isn't really addressed, which is a problem to be future proof. http://en.wikipedia.org/wiki/Hoard_memory_allocator
Re: Automatic typing
On Friday, 28 June 2013 at 13:44:19 UTC, ponce wrote: On Friday, 28 June 2013 at 00:34:54 UTC, JS wrote: Would it be possible for a language(specifically d) to have the ability to automatically type a variable by looking at its use cases without adding too much complexity? Well ocaml has it (https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner) and well it's not all that positive, at least in that language. No, OCaml doesn't quite do what the OP is asking for. In particular, the part where x is assigned an int and subsequently assigned a float can not be modeled directly. Even the separate 'auto x' and subsequent use of x is different from how OCaml's let polymorphism works. To model that, you could declare everything as 'a option refs and assign them later, like let main () = let x = ref None in let y = ref None in begin x := Some 1; y := Some (f()); end but if you want to use x as another type later you'll have to shadow the declaration in a new scope. Combined with parametric polymorphism it's nice and sound, except it has the potential to hide a simple typo a lot further from where it is (think mixing up integer operators and FP operators). As it break overloading on leaves, it is the reason ocaml has print_string and print_int which is quite frankly ugly. Yes, and the +., -., *., /. operators are ugly too, as is the requirement that record field labels in the same scope be distinct. Overloading can be dangerous, but no overloading is a PITA. Combining type inference and overloading is problematic. Once you have type inference, the first thing you do to make your code readable is to add back type annotations. There should always be a .mli file with exported decls. I wish OCaml had some ability to have separate type decls from the value, like Haskell. Type inference is most useful inside a function, IMO. I think that even if the feature being requested were feasible, it would be awful for D. -- Brian
Re: why allocators are not discussed here
On Wednesday, 26 June 2013 at 17:25:24 UTC, H. S. Teoh wrote: I was listening to Andrei's talk this morning, but I didn't quite understand what he means by composable allocators. Is he talking about nesting, say, a GC inside a region allocated by a region allocator? Maybe he was talking about a freelist allocator over a reap, as described by the HeapLayers project http://heaplayers.org/ in the paper from 2001 titled 'Composing High-Performance Memory Allocators'. I'm pretty sure that web site was referenced in the talk. A few publications there are from Andrei. I agree that D should support programming without a GC, with different GCs than the default one, and custom allocators, and that features which demand a GC will be troublesome. -- Brian
Re: Ping qznc: Re: A little of coordination for Rosettacode
On Saturday, 22 June 2013 at 21:27:01 UTC, bearophile wrote: Ali Çehreli: The code compiles under 32-bit (e.g. with the -m32 compiler switch) where size_t is an alias of uint. Thanks, Ali! I'm always compiling on 64 bit systems; I'll add the 32 bit switch to my diagnostic approach now. Oh, I see. I compile most of the code on a 32 bit system. I asked Walter to warn d programmers against such mistakes, and Walter closed it down. Someone else has opened the ER again... In general, I think implicit conversions of any kind are a misfeature, but better error messages would be enough for me here. At least in Scala, you need to bring the conversion into scope yourself, or have it accidentally imported... Thanks for your help. -- Brian
Re: Ping qznc: Re: A little of coordination for Rosettacode
On Saturday, 16 February 2013 at 11:30:00 UTC, Jos van Uden wrote:
On 16-2-2013 8:58, qznc wrote:
On Saturday, 16 February 2013 at 06:58:01 UTC, qznc wrote:
On Saturday, 16 February 2013 at 02:23:42 UTC, Jos van Uden
wrote:
On 5-2-2013 20:45, Jos van Uden wrote:
By the way, I think 'Qznc' may want to have a look at 'The
dining
philosophers':
http://rosettacode.org/wiki/Dining_philosophers
I should find the time to solve it this weekend.
Wow, my kid let me do some hacking right now and it was
simpler than expected.
Posted a solution already.
Wow, that was quick. Thanks!
The current D code for Dining philosophers does not compile with
dmd v2.063.2, the error message being
dining.d(34): Error: cannot uniquely infer foreach argument types
The code looks OK to me (but I'm a D newbie) so I wonder if
someone could explain the inference issue. Where should an
annotation be added to allow this to compile?
1 import std.stdio, std.algorithm, std.string,
std.parallelism,
2core.sync.mutex;
3
4 void eat(in uint i, in string name, Mutex[] forks) {
5writeln(name, is hungry.);
6
7immutable j = (i + 1) % forks.length;
8
9 // Take forks i and j. The lower one first to prevent
deadlock.
10auto fork1 = forks[min(i, j)];
11auto fork2 = forks[max(i, j)];
12
13fork1.lock();
14scope(exit) fork1.unlock();
15
16fork2.lock();
17scope(exit) fork2.unlock();
18
19writeln(name, is eating.);
20writeln(name, is full.);
21 }
22
23 void think(in string name) {
24writeln(name, is thinking.);
25 }
26
27 void main() {
28 const philosophers = Aristotle Kant Spinoza Marx
Russell.split();
29Mutex[philosophers.length] forks;
30foreach (ref fork; forks)
31 fork = new Mutex();
32
33defaultPoolThreads = forks.length;
34 foreach (uint i, philo; taskPool.parallel(philosophers))
{
35 foreach (_; 0 .. 100) {
36eat(i, philo, forks);
37think(philo);
38 }
39}
40 }
BTW, I like the coding style being used in the rosetta examples
and TDPL much better than the library style.
-- Brian
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Friday, 24 May 2013 at 19:44:19 UTC, Jonathan M Davis wrote: On Friday, May 24, 2013 20:30:54 Juan Manuel Cabo wrote: I'd like to know if there is interest in a precise garbage collector. There is interest in it, and Rainer Schütze did a talk on it at DConf. At the current pace (assuming that Andrei actually posts one on Monday even though it's a federal holiday in the US), it'll be posted on June 3rd (and if he skips Monday, then it'll probably be June 5th). And actually, the precise GC changes stand a much better chance of making it into druntime in the short term than any concurrency changes do. - Jonathan M Davis That's very promising. The lack of precise garbage collection and the unclear story with regards to programming sans-GC (maybe it's clear to someone, but not to me) is far more of a deal breaker for me than the lack of non-nullable pointers. I hope that you're right and that this gets sorted out soon. -- Brian
Re: D in Academia
On Saturday, 3 March 2012 at 19:02:23 UTC, Chuck Allison wrote: FYI: TDPL is a required text for CS 4450, Analysis of Programming Languages, at Utah Valley University starting Fall 2012. We'll study ML and D (and Prolog if time allows). Slightly off topic digression: Which ML? I ask as an OCaml partisan (and D fan!) who will obviously suggest that you go with that language, since it is probably the more widely used ML variant. -- Brian
