digitalmars.D - D dropped in favour of C# for PSP emulator
- Paulo Pinto (7/7) May 11 2012 The author of a D based PSP emulator just rewrote
- =?ISO-8859-15?Q?Alex_R=F8nne_Petersen?= (16/23) May 11 2012 Complicated language structure? Long compilation times?
- Mehrdad (32/34) May 11 2012 I'd have to agree...
- Mehrdad (10/12) May 11 2012 Just a note: I believe I *had* seen SortedRange in the docs, but
- Andrei Alexandrescu (7/18) May 11 2012 At the same time it clarifies, documents, and statistically verifies
- Mehrdad (7/13) May 11 2012 Right, right, I understand all of that...
- Chris Cain (3/8) May 11 2012 You want a language that you can program in without ever looking
- Mehrdad (23/32) May 11 2012 lol I think you're exaggerating my point. :P
- Jonathan M Davis (8/11) May 11 2012 That's definitely an example of something that depends on your backgroun...
- Mehrdad (6/9) May 11 2012 Well, I know some FP (Scheme/newLISP) but they don't have an
- Jonathan M Davis (8/19) May 11 2012 I know that haskell has such a function, and there were a number of comp...
- Mehrdad (11/18) May 11 2012 Again, I know enough FP to know what predicates are, and of
- Andre Artus (9/29) Aug 03 2013 In .NET 3.5, and later, 'Any()' has an overload that takes a
- Jacob Carlborg (6/17) Aug 02 2013 Ruby has a function like that as well. It works like the Haskell
- Ary Manzana (7/16) May 11 2012 Ruby has any?:
- Andre Artus (3/25) Aug 03 2013 This is in fact the exact behaviour of .NET's Any (on
- Walter Bright (6/10) May 11 2012 That is amusing. I've been writing a bunch of range/algorithm code mysel...
- Jacob Carlborg (6/13) May 14 2012 This one exists in Ruby as well. But in Ruby the block/lambda is
- Kagamin (3/6) May 12 2012 I think, `Any` is one of the most unintuitive names out there.
- Andrei Alexandrescu (9/24) May 11 2012 Totally agreed. Intuition is supported by having seen the same or a
- Mehrdad (2/10) May 11 2012 Awesome!
- Ary Manzana (4/24) May 11 2012 Add a binarySearch(range, object) method that does all of that?
- Andrei Alexandrescu (4/7) May 12 2012 assumeSorted(range).contains(object)
- Ary Manzana (4/12) May 12 2012 Ok. When more people start saying that they can't find a binarySearch
- H. S. Teoh (8/23) May 12 2012 [...]
- bearophile (7/9) May 13 2012 It's self-explanatory if the name there contains something like
- Peter Alexander (14/24) May 14 2012 100% agree with this.
- Simen Kjaeraas (8/26) May 14 2012 It is not intuitive, I agree. It is, however, documenting. You're not
- Kirill (16/50) May 15 2012 How about users who don't know what binary search is. binary
- "Anders =?UTF-8?B?U2rDtmdyZW4i?= <anders sjogren.info> (20/20) May 16 2012 Since this post is about inuition, I'll raise my voice even
- Mehrdad (11/12) May 16 2012 Either that, or just the plain algorithm. Then the issue isn't
- bearophile (13/18) May 16 2012 Even if you don't know the name "binary search" (something that
- Timon Gehr (5/19) May 16 2012 I agree, that the explanation does not hold water, not because of other
- Andrei Alexandrescu (4/18) May 16 2012 Just trying my best to do the right thing by everyone. Not much else to
- Tobias Pankrath (4/4) May 16 2012 Andrei you are against an in-operator for array, because it would
- Steven Schveighoffer (11/15) May 16 2012 No it's not the same.
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (7/22) May 16 2012 People aren't using 'in' in generic code at all, so I'm not sure this
- Andrei Alexandrescu (3/7) May 16 2012 It is. That's why there's no contains with linear complexity.
- Tobias Pankrath (10/12) May 16 2012 I missed that. However SortedRange needs better documentation.
- Walter Bright (2/3) May 16 2012 May the schwartz be with you.
- Jordi Sayol (5/10) May 16 2012 Very appropriate :-)
- Lars T. Kyllingstad (3/12) May 17 2012 Walter's quote was from "Spaceballs". :-)
- Regan Heath (6/17) May 17 2012 Ahh.. I see your schwartz is as big as mine :p
- Peter Alexander (23/27) May 17 2012 If you don't know about binary search, you won't write
- Andrei Alexandrescu (15/38) May 17 2012 Doesn't compile.
- bearophile (14/19) May 17 2012 Names are very important, they are the fist and most important
- Jonathan M Davis (13/31) May 17 2012 Yes, names are important, but you'll also never get people to agree on t...
- Peter Alexander (3/46) May 18 2012 As far as I'm aware, no one has proposed any breaking changes.
- H. S. Teoh (14/27) May 17 2012 [...]
- Peter Alexander (9/14) May 17 2012 No need to change anything, just add something:
- H. S. Teoh (5/21) May 17 2012 Great minds think alike. ;-)
- Jonathan M Davis (5/23) May 17 2012 Yeah, but then we've added a function which adds no real functionality, ...
- Andrei Alexandrescu (5/17) May 17 2012 I don't see much benefit in this - just lateral walking. As long as the
- Peter Alexander (5/31) May 18 2012 It's not just for newcomers discoverability, it's also for
- Andrei Alexandrescu (3/27) May 18 2012 I guess it is now :o).
- Mehrdad (5/7) May 18 2012 lol
- Andrei Alexandrescu (6/14) May 18 2012 It is, and the decision (after a good amount of deliberation) is
- Mehrdad (4/10) May 18 2012 Okay; only pointed it out because I remembered it was also the
- Jerry (6/23) May 28 2012 This is posted long after the conversation, but a partial solution to
- Brad Anderson (9/18) May 18 2012 I fairly often get confused about whether to look in std.range or
- H. S. Teoh (10/13) May 18 2012 What about the latest prerelease docs for std.range? I did clean up a
- Brad Anderson (11/24) May 18 2012 I like it. Looks like it's already up on the website and was included w...
- Jonathan M Davis (8/21) May 18 2012 Making improvements to the docs is great and definitely a good idea (I d...
- jerro (5/14) May 11 2012 Maybe the documentation changed since, but currently the
- Mehrdad (4/18) May 11 2012 Yeah, either I missed, or I just didn't look at it, and skipped
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (18/47) May 11 2012 Right, D's template system is definitely inspired by C++, no argument
- Mehrdad (19/46) May 11 2012 Not sure I agree.
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (12/56) May 11 2012 True. I'm just speaking from a purely language perspective. But D is a
- Nick Sabalausky (6/19) May 11 2012 I use 'in' all the time, and I never even think about it returning a
- Timon Gehr (3/25) May 11 2012 Try this:
- Jonathan M Davis (12/44) May 11 2012 Then you do
- Mehrdad (2/4) May 11 2012 cast() scares the **** out of me
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (5/11) May 11 2012 bool fun() { return !!(foo in bar); }
- Mehrdad (3/13) May 11 2012 lol
- Timon Gehr (2/8) May 11 2012 cast(bool) is peaceful.
- Timon Gehr (12/24) May 11 2012 I didn't claim it was. Still, most issues people seem to have with D are...
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (6/17) May 11 2012 Isn't that an inconsistency in the language then? Are pointer values
- Timon Gehr (5/22) May 11 2012 if(condition) { ... }
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (6/30) May 11 2012 WAT. That's an "implicit explicit" conversion, which I have never known
- SomeDude (7/34) May 12 2012 I'm not sure what you're talking about, there is no implicit
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (18/53) May 12 2012 Which example are you testing with?
- Nick Sabalausky (4/20) May 11 2012 Like Timon said, it's a feature of "if". I agree it's weird and confusin...
- Manu (4/6) May 12 2012 I'd like to think this were true, but the fact that 'ref' barely works
- Timon Gehr (2/9) May 12 2012 It depends on the coding style.
- Jonathan M Davis (9/21) May 12 2012 I rarely end up passing by either ref or pointer, and the only issues th...
- Manu (5/18) May 12 2012 If the distinction is whether one likes to have data structures in their
- Timon Gehr (7/28) May 12 2012 Classes and dynamic arrays can be used to build data structures as well,...
- Jonathan M Davis (7/25) May 12 2012 Since structs are generally value types, it's extremely common to just p...
- Manu (37/60) May 12 2012 struct X
- H. S. Teoh (27/65) May 11 2012 Templates are stencils for generating code. There's nothing confusing
- Mehrdad (6/8) May 11 2012 "Stencils for generating code"? _This_??! :O
- H. S. Teoh (30/43) May 11 2012 Yes, that's exactly how stencils work. You're essentially generating a
- Mehrdad (11/29) May 11 2012 That's not how you see it when you're learning though.
- H. S. Teoh (16/50) May 11 2012 Well, it *should* be seen that way. The fact that it isn't means that
- SomeDude (6/39) May 11 2012 I think TypeTuples originate from Andrei's famous book "Modern
- SomeDude (3/36) May 11 2012 BTW, don't forget to have a look at the articles on the left:
- Walter Bright (5/16) May 11 2012 I tend to agree. I think this is better (I've never gotten around to
- Mehrdad (4/8) May 11 2012 Mmmm... I like the idea/syntax, but not the word "enum". It
- Nick Sabalausky (5/16) May 11 2012 While do I agree 100% that 'enum' is a horrid name (*much* worse than
- Philippe Sigaud (8/12) May 11 2012 I wrote a tutorial on templates, any comment is welcome:
- Dejan Lekic (5/22) May 12 2012 Philippe, I have already went through that draft 3/4 times.
- Marco Leise (5/25) May 17 2012 Your PDF is my reference manual on templates for quite a while. Thanks f...
- Philippe Sigaud (8/9) May 17 2012 Glad to hear it :-)
- Andrei Alexandrescu (3/12) May 17 2012 You may want to set up scripts that extract and compile code samples.
- Philippe Sigaud (12/15) May 18 2012 I did, as per your advice, and a very good one at that (levelled
- Nick Sabalausky (5/9) May 11 2012 Geez, I think I need a vacation: My mind parsed that as a ternary operat...
- Simen Kjaeraas (4/17) May 13 2012 What did your mind do to the trigraph?
- Jonathan M Davis (15/27) May 11 2012 Templates are a code-generation tool. They're "templates" for code. I re...
- Nick Sabalausky (4/9) May 11 2012 https://semitwist.com/articles/article/view/template-primer-in-d
- H. S. Teoh (8/23) May 11 2012 [...]
- Jonathan M Davis (5/10) May 11 2012 Really? That's pretty much exactly what I would have expected, and it wo...
- Mehrdad (3/10) May 11 2012 Again, try to see it from the perspective of a Python user, not a
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (5/16) May 11 2012 Speaking of which, 'in' on arrays.........
- Jonathan M Davis (5/22) May 11 2012 Except that it would break the generally expected algoritmic complexity ...
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (9/31) May 11 2012 'in' isn't useful in generic code. How it's defined (return type and
- SomeDude (4/18) May 11 2012 I think this has been discussed several times already, and you
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (5/23) May 11 2012 Then you probably didn't read the replies to the other (sub-)thread
- Timon Gehr (7/29) May 11 2012 The main use case I see is replacing tedious
- H. S. Teoh (7/22) May 11 2012 I always use this idiom:
- Andrei Alexandrescu (4/37) May 11 2012 Yes, "in" for statically-sized arrays does make sense because the
- jerro (19/22) May 11 2012 But complexity is not the only problem with the proposed
- Andrei Alexandrescu (4/11) May 11 2012 That's a good argument, but then you may think of the array as a small
- Andrej Mitrovic (9/11) May 11 2012 As do I. Generally when I end up repeating myself all the time I write
- Jonathan M Davis (8/21) May 11 2012 Sure, what your used to has a huge effect on what you expect. But I've d...
- Chris Cain (33/41) May 11 2012 I really have to disagree on this. I programmed in C++ for awhile
- Mehrdad (5/9) May 11 2012 Yes, D's templates are a great improvement over C++'s. I
- H. S. Teoh (30/61) May 11 2012 Yeah, I remember when I first read about template metaprogramming and
- Era Scarecrow (15/37) May 11 2012 I remember reading from that book a bit on the ranges, and it
- Jonathan M Davis (3/7) May 11 2012 http://ddili.org/ders/d.en/ranges.html
- Walter Bright (15/22) May 11 2012 Back when Andrei was writing TDPL, I suggested that he avoid using the w...
- Mehrdad (2/5) May 11 2012 Same thing happens to me when I see a transistor symbol. :P
- Andrej Mitrovic (3/6) May 11 2012 Well that's funny, here in europe we've learned to use 'x' since
- Joseph Rushton Wakeling (17/19) May 11 2012 Dangerous to speak for a whole group, I've met plenty of Europeans terri...
- Ary Manzana (7/13) May 11 2012 When I read "solve *for* x" I don't understand it. What do you mean "for...
- Walter Bright (2/17) May 11 2012 It's normal English mathematical jargon.
- Nick Sabalausky (22/28) May 11 2012 You're right, it doesn't. "Find the value of x" would be *much* better. ...
- SomeDude (2/3) May 12 2012 Wow, you seem to love her. :D Cool down, man, it's over. :)
- Ary Manzana (2/4) May 12 2012 Hilarious :-)
- Walter Bright (2/7) May 12 2012 Due-be-due-be-due! -- Sinatra
- akaz (19/27) May 11 2012 Partially, this also can be told about D, too. It started as a
- SomeDude (17/45) May 11 2012 There is no arguing that D is a big and complex language. If it
- Walter Bright (3/7) May 11 2012 Eh, I'd put it much longer than that. Or maybe I just have a different v...
- SomeDude (5/12) May 11 2012 Yeah, I didn't want to start a discussion on how much time it
- Steven Schveighoffer (14/28) May 11 2012 I can attest that on certain types of projects (i.e. template heavy), D'...
-
Nick Sabalausky
(10/19)
May 11 2012
"Steven Schveighoffer"
wrote in message - SomeDude (6/33) May 11 2012 I remember g++ taking dozens of minutes on a SINGLE compilation
- Nick Sabalausky (13/18) May 11 2012 Yea, it's like compiling GCC. You may as well go buy your groceries, run...
- Paulo Pinto (3/35) May 11 2012 Well, in most the big C++ projects I was involved in the
- Nick Sabalausky (4/42) May 11 2012 awkward is which, backwards read things makes posting top but, ass an be...
- Timon Gehr (46/58) May 11 2012 Properties of a 'good IDE', as I see it:
- Adam D. Ruppe (11/14) May 11 2012 My work project takes about 8 seconds to compile and link
- Paulo Pinto (8/71) May 11 2012 Your 'nice to have' features are for my type of
-
Simen Kjaeraas
(10/98)
May 13 2012
On Sat, 12 May 2012 08:05:26 +0200, Paulo Pinto
= - Nick Sabalausky (6/45) May 11 2012 Hear hear!
- Timon Gehr (6/60) May 12 2012 The - ... points were meant to apply to all the other points in their
- Jonathan M Davis (7/85) May 11 2012 I do have to say that I find it somewhat funny that this is your set of
- SomeDude (17/27) May 11 2012 Indeed, and Timon forgot the best feature of IDEs for bytecode
- Era Scarecrow (5/21) May 12 2012 Perhaps what could make that better is not only compiling as you
- Paulo Pinto (6/31) May 12 2012 Even Eclipse and VS do this, to certain extent, for C and C++.
- Timon Gehr (16/43) May 12 2012 Probably I didn't express myself properly, but this was meant to be
- Nick Sabalausky (6/10) May 12 2012 I find the sluggish text-editing that inevitably implies to be MUCH more...
- Bruno Medeiros (7/12) May 18 2012 So just starting up the IDE is more important than actually writing code...
- Mehrdad (3/13) May 18 2012 Latency vs. Throughput.
- =?ISO-8859-15?Q?Alex_R=F8nne_Petersen?= (8/18) May 18 2012 I shouldn't have to keep my IDE open all the time when I'm not using it....
- Jesse Phillips (5/8) May 18 2012 My oversimplification of it is, IDEs like the fundimental
- Era Scarecrow (18/27) May 19 2012 I'll have to agree. You can skip the editor entirely and use
- Bruno Medeiros (17/21) May 30 2012 Oh yeah, I'd like to see you do those things using just one hand. Or
- Manu (15/27) May 19 2012 No, writing code and fixing bugs is more important than sitting around a...
- Era Scarecrow (13/46) May 19 2012 Perhaps to be a hard-core hacker? I've done a GUI-less
- Timon Gehr (21/31) May 20 2012 No, you misunderstand.
- Manu (3/43) May 20 2012 It's also worth noting that this guy dropped D for C#. That's a pretty
- Timon Gehr (3/5) May 20 2012 It is important to me as well. I would drop C#/VisualStudio for D/GNU
- Regan Heath (23/28) May 21 2012 It really all depends on where each person is coming from. I have used ...
- Bruno Medeiros (9/13) May 30 2012 I am not misunderstanding. No one is saying there is no value in saving
- =?ISO-8859-15?Q?Alex_R=F8nne_Petersen?= (11/23) May 30 2012 I'm just going to add that Visual Studio 11 can start up in less than a
- Jonathan M Davis (16/90) May 12 2012 So, basically it's just the issue with neither ref nor const ref taking
- Timon Gehr (6/96) May 12 2012 I don't see why 'const' should make a difference there anyway. It is
- Manu (41/76) May 12 2012 And the local references, and the bug.
- Dmitry Olshansky (5/31) May 12 2012 Brr... most ranges are structs. And yes, they are passed by value
- Nick Sabalausky (5/16) May 12 2012 There was a big discussion of recently on the dmd beta mailing list . On...
- Jonathan M Davis (23/58) May 12 2012 I believe that you can do it with a pointer.
- Nick Sabalausky (4/12) May 12 2012 IIRC, this was also explained in the big discussion on the dmd beta mail...
- Nick Sabalausky (19/24) May 12 2012 (Heh, now that Time Warner is no longer destroying GitHub for me and I c...
- =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (7/36) May 12 2012 You know, my project consisting of 130-ish source files and 24.000-ish
- Jakob Bornecrantz (15/20) May 14 2012 Try using GDC the compiler that can actually produce good code,
- Marco Leise (19/47) May 17 2012 This is true. Once you decide to use GDC for whatever reason (chances of...
- soywiz (22/22) Aug 02 2013 I just replied here with my motivations:
- bearophile (9/18) Aug 02 2013 That's mostly a tools/ecosystem problem, but perhaps the language
The author of a D based PSP emulator just rewrote https://github.com/soywiz/cspspemu The reasons are listed here, https://github.com/soywiz/cspspemu#created-after-4-tries -- Paulo
May 11 2012
On 11-05-2012 19:39, Paulo Pinto wrote:The author of a D based PSP emulator just rewrote https://github.com/soywiz/cspspemu The reasons are listed here, https://github.com/soywiz/cspspemu#created-after-4-tries -- PauloComplicated language structure? Long compilation times? wat. but then you've barely been exposed to interesting language design at all IMHO. I can agree on it being harder to refactor things in D than in other languages, but this completely depends on how much CTFE/CT reflection magic you're using. Now, this being said, .NET is interesting for an emulator exactly because he can just throw CIL at the runtime and it will emit native code for him at runtime. This makes portability *extremely* easy, because the CIL he emits will run anywhere Mono and MS.NET can run. Doing a similar thing with LLVM is certainly possible, but much more tedious. -- - Alex
May 11 2012
On Friday, 11 May 2012 at 17:47:06 UTC, Alex Rønne Petersen wrote:Complicated language structure? Long compilation times? wat.I'd have to agree... Several things in D are really hard to understand if you don't already have a C++ background: 1. "templates": they seem to take in just about anything, and return just about anything. They can be pretty confusing, especially when you have to worry about overloading vs. specialization vs. constraints, or types vs. aliases... 2. Tuples (I'm referring to both tuple() and TypeTuple()) are very confusing if you don't happen to suddenly "get" them. 3. Ranges aren't confusing, but USING them certainly is. Don't believe me? array. It's VERY straightforward. In D, it's VERY CONFUSING -- there *is* no way to do this directly! Which led me to ask this question: http://stackoverflow.com/questions/4622377 and the solution indeed was NOT something I would've found by myself without spending hours on it (which I already had partially done). 4. is(typeof(foo) U) is very confusing; it's completely unintuitive 5. For that matter, is() is completely unintuitive 6. The 'in' operator returns a pointer (instead of a boolean). Which is fine, except that it's not what you'd expect in any languages other than C/C++. i.e. Non-intuitive 7. __traits() are confusing 8. there's more but I just can't think of them right now
May 11 2012
On Friday, 11 May 2012 at 18:05:58 UTC, Mehrdad wrote:and the solution indeed was NOT something I would've found by myself without spending hours on it.Just a note: I believe I *had* seen SortedRange in the docs, but I'd never realized there's something called assumeSorted() that I was supposed to call... so I was searching up and down for how to search an *arbitrary* container, not how to search something which was already pre-sorted for me. (In retrospect, I probably should've just coded binary search myself...) It's very counterintuitive to have to make a new object (or struct) just to do binary search on an array...
May 11 2012
On 5/11/12 1:10 PM, Mehrdad wrote:On Friday, 11 May 2012 at 18:05:58 UTC, Mehrdad wrote:At the same time it clarifies, documents, and statistically verifies that you pass a sorted range. Also, D's binary search works with sorted only by convention). I think we copiously made the right call there. Andreiand the solution indeed was NOT something I would've found by myself without spending hours on it.Just a note: I believe I *had* seen SortedRange in the docs, but I'd never realized there's something called assumeSorted() that I was supposed to call... so I was searching up and down for how to search an *arbitrary* container, not how to search something which was already pre-sorted for me. (In retrospect, I probably should've just coded binary search myself...) It's very counterintuitive to have to make a new object (or struct) just to do binary search on an array...
May 11 2012
On Friday, 11 May 2012 at 18:18:21 UTC, Andrei Alexandrescu wrote:At the same time it clarifies, documents, and statistically verifies that you pass a sorted range. Also, D's binary search (which it assumes sorted only by convention). I think we copiously made the right call there. AndreiRight, right, I understand all of that... But just because the *reasons* are correct that doesn't mean it's more intuitive. ("Intuitive", by definition, means that you have a good chance of getting it right without needing to look it up. Binary searching in D failed this miserably for me.)
May 11 2012
On Friday, 11 May 2012 at 18:33:06 UTC, Mehrdad wrote:But just because the *reasons* are correct that doesn't mean it's more intuitive. ("Intuitive", by definition, means that you have a good chance of getting it right without needing to look it up. Binary searching in D failed this miserably for me.)You want a language that you can program in without ever looking at docs? How exactly would that work? o_O
May 11 2012
On Friday, 11 May 2012 at 19:03:56 UTC, Chris Cain wrote:On Friday, 11 May 2012 at 18:33:06 UTC, Mehrdad wrote:lol I think you're exaggerating my point. :P I said a "reasonable chance". For example, in std.algorithm, "joiner" is NOT what I expected the method to be called -- I expected "join". (Again, I *do* understand why it's called that.) Or in std.range, no one in a million years expects to see a method called "moveFront()". You're not "moving" a range... What we call "moveFront()" should, IMO, have been called "popFront()". Or maybe just "next()". But of course that was taken, so there wasn't a choice. Still, not intuitive. it's called "Except". (Like, items.except(otherItems).) empty, whereas D's "any()" method takes in a predicate. I find D's std.algorithm.completeSort() definitely does NOT have an intuitive name. etc. (But, actually, what you said WOULD work if you had a good enough IDE, like Visual Studio, that gave you the descriptions right there, instantly. That wasn't my point though.)But just because the *reasons* are correct that doesn't mean it's more intuitive. ("Intuitive", by definition, means that you have a good chance of getting it right without needing to look it up. Binary searching in D failed this miserably for me.)You want a language that you can program in without ever looking at docs? How exactly would that work? o_O
May 11 2012
On Friday, May 11, 2012 21:15:53 Mehrdad wrote:empty, whereas D's "any()" method takes in a predicate. I findThat's definitely an example of something that depends on your background. std.algorithm.any does _exactly_ what it would do in a functional language. How intuitive an API is depends a lot on how much the person writing the API thinks like you. It's definitely something to strive for, but the best that you can generally do is hit the majority of your target audience. You can never hit everyone. - Jonathan M Davis
May 11 2012
On Friday, 11 May 2012 at 20:20:36 UTC, Jonathan M Davis wrote:That's definitely an example of something that depends on your background. std.algorithm.any does _exactly_ what it would do in a functional language.Well, I know some FP (Scheme/newLISP) but they don't have an Are you thinking of a language in particular that has D's behavior? Or is this just a guess?
May 11 2012
On Friday, May 11, 2012 22:40:08 Mehrdad wrote:On Friday, 11 May 2012 at 20:20:36 UTC, Jonathan M Davis wrote:I know that haskell has such a function, and there were a number of complaints previously that we _didn't_ have an any function which does exactly what std.algorithm.any now does. It's a very functional approach to use predicates like that and I get the impression that it's common in other functional languages based on other's comments. The only one off the top of my head that I _know_ has such a function though is haskell. - Jonathan M DavisThat's definitely an example of something that depends on your background. std.algorithm.any does _exactly_ what it would do in a functional language.Well, I know some FP (Scheme/newLISP) but they don't have an Are you thinking of a language in particular that has D's behavior? Or is this just a guess?
May 11 2012
On Friday, 11 May 2012 at 21:53:06 UTC, Jonathan M Davis wrote:I know that haskell has such a function, and there were a number of complaints previously that we _didn't_ have an any function which does exactly what std.algorithm.any now does. It's a very functional approach to use predicates like that and I get the impression that it's common in other functional languages based on other's comments. The only one off the top of my head that I _know_ has such a function though is haskell.Again, I know enough FP to know what predicates are, and of course, this is common in functional languages. Even Scheme has a 'there-exists?' function just for this purpose. I wasn't saying having "such a function" is weird -- I was just asking if you know of any languages in which the NAME is "any()", since I would've imagined it to be something more intuitive like "exists()" or "contains" or "has" or whatever. "are there any elements in this list?", NOT with the meaning D uses.)
May 11 2012
On Friday, 11 May 2012 at 23:51:47 UTC, Mehrdad wrote:On Friday, 11 May 2012 at 21:53:06 UTC, Jonathan M Davis wrote:In .NET 3.5, and later, 'Any()' has an overload that takes a predicate so it behaves identical to 'any' in Haskell and D. public static bool Any<TSource>( this IEnumerable<TSource> source, Func<TSource, bool> predicate ) The Exists method is an older construct with a more limited application (List vs IEnumerable)I know that haskell has such a function, and there were a number of complaints previously that we _didn't_ have an any function which does exactly what std.algorithm.any now does. It's a very functional approach to use predicates like that and I get the impression that it's common in other functional languages based on other's comments. The only one off the top of my head that I _know_ has such a function though is haskell.Again, I know enough FP to know what predicates are, and of course, this is common in functional languages. Even Scheme has a 'there-exists?' function just for this purpose. I wasn't saying having "such a function" is weird -- I was just asking if you know of any languages in which the NAME is "any()", since I would've imagined it to be something more intuitive like "exists()" or "contains" or "has" or whatever. "are there any elements in this list?", NOT with the meaning D uses.)
Aug 03 2013
On Friday, 11 May 2012 at 21:53:06 UTC, Jonathan M Davis wrote:I know that haskell has such a function, and there were a number of complaints previously that we _didn't_ have an any function which does exactly what std.algorithm.any now does. It's a very functional approach to use predicates like that and I get the impression that it's common in other functional languages based on other's comments. The only one off the top of my head that I _know_ has such a function though is haskell.Ruby has a function like that as well. It works like the Haskell version if you pass a predicate. If you don't pass an argument it -- /Jacob Carlborg
Aug 02 2013
On 5/12/12 3:40 AM, Mehrdad wrote:On Friday, 11 May 2012 at 20:20:36 UTC, Jonathan M Davis wrote:Ruby has any?: http://ruby-doc.org/core-1.9.3/Enumerable.html#method-i-any-3F And it's the best of the two worlds: given a block (a lambda) it works like D. Give no lambda and it just returns true if the enumerable has any elements. Ruby wins again. :-PThat's definitely an example of something that depends on your background. std.algorithm.any does _exactly_ what it would do in a functional language.Well, I know some FP (Scheme/newLISP) but they don't have an "any" Are you thinking of a language in particular that has D's behavior? Or is this just a guess?
May 11 2012
On Saturday, 12 May 2012 at 03:42:10 UTC, Ary Manzana wrote:On 5/12/12 3:40 AM, Mehrdad wrote:This is in fact the exact behaviour of .NET's Any (on IEnumerable). This is a library thing, not a language thing.On Friday, 11 May 2012 at 20:20:36 UTC, Jonathan M Davis wrote:Ruby has any?: http://ruby-doc.org/core-1.9.3/Enumerable.html#method-i-any-3F And it's the best of the two worlds: given a block (a lambda) it works like D. Give no lambda and it just returns true if the enumerable has any elements. Ruby wins again. :-PThat's definitely an example of something that depends on your background. std.algorithm.any does _exactly_ what it would do in a functional language.Well, I know some FP (Scheme/newLISP) but they don't have an "any" would do Are you thinking of a language in particular that has D's behavior? Or is this just a guess?
Aug 03 2013
On 5/11/2012 1:20 PM, Jonathan M Davis wrote:That's definitely an example of something that depends on your background. std.algorithm.any does _exactly_ what it would do in a functional language. How intuitive an API is depends a lot on how much the person writing the API thinks like you.That is amusing. I've been writing a bunch of range/algorithm code myself lately, and I find it's a struggle because it is simply not how I think about code. I think in terms of C style loops, and solutions just pop out of my fingers on the keyboard. With ranges, I have to forcibly think in a different way, it's a lot like transitioning from walking to using a snowboard.
May 11 2012
On 2012-05-11 22:20, Jonathan M Davis wrote:That's definitely an example of something that depends on your background. std.algorithm.any does _exactly_ what it would do in a functional language. How intuitive an API is depends a lot on how much the person writing the API thinks like you. It's definitely something to strive for, but the best that you can generally do is hit the majority of your target audience. You can never hit everyone. - Jonathan M DavisThis one exists in Ruby as well. But in Ruby the block/lambda is optional. If it's not passed it will return a bool indicating if the collection is empty or not, just as Mehrdad expected. -- /Jacob Carlborg
May 14 2012
On Friday, 11 May 2012 at 19:15:54 UTC, Mehrdad wrote:empty, whereas D's "any()" method takes in a predicate. I findI think, `Any` is one of the most unintuitive names out there. The best association I have is aaaamon.dll from windows.
May 12 2012
On 5/11/12 1:33 PM, Mehrdad wrote:On Friday, 11 May 2012 at 18:18:21 UTC, Andrei Alexandrescu wrote:Totally agreed. Intuition is supported by having seen the same or a similar pattern before. In this case D takes an unusual approach, which I think is better than the established approach. I have added a reference (https://github.com/andralex/phobos/commit/650609be9b4146db3526b 0ccfca6776fed73b51) such that searching the page std.algorithm for "binary search" will lead to the correct reference. AndreiAt the same time it clarifies, documents, and statistically verifies that you pass a sorted range. Also, D's binary search works with sorted only by convention). I think we copiously made the right call there. AndreiRight, right, I understand all of that... But just because the *reasons* are correct that doesn't mean it's more intuitive. ("Intuitive", by definition, means that you have a good chance of getting it right without needing to look it up. Binary searching in D failed this miserably for me.)
May 11 2012
On Friday, 11 May 2012 at 21:40:44 UTC, Andrei Alexandrescu wrote:Totally agreed. Intuition is supported by having seen the same or a similar pattern before. In this case D takes an unusual approach, which I think is better than the established approach. I have added a reference (https://github.com/andralex/phobos/commit/650609be9b4146db3526b 0ccfca6776fed73b51) such that searching the page std.algorithm for "binary search" will lead to the correct reference. AndreiAwesome!
May 11 2012
On 5/12/12 1:18 AM, Andrei Alexandrescu wrote:On 5/11/12 1:10 PM, Mehrdad wrote:Add a binarySearch(range, object) method that does all of that? I mean, I don't want to write more than a single line of code to do a binarySearch...On Friday, 11 May 2012 at 18:05:58 UTC, Mehrdad wrote:At the same time it clarifies, documents, and statistically verifies that you pass a sorted range. Also, D's binary search works with sorted only by convention). I think we copiously made the right call there. Andreiand the solution indeed was NOT something I would've found by myself without spending hours on it.Just a note: I believe I *had* seen SortedRange in the docs, but I'd never realized there's something called assumeSorted() that I was supposed to call... so I was searching up and down for how to search an *arbitrary* container, not how to search something which was already pre-sorted for me. (In retrospect, I probably should've just coded binary search myself...) It's very counterintuitive to have to make a new object (or struct) just to do binary search on an array...
May 11 2012
On 5/11/12 10:38 PM, Ary Manzana wrote:Add a binarySearch(range, object) method that does all of that? I mean, I don't want to write more than a single line of code to do a binarySearch...assumeSorted(range).contains(object) is still one line, safer, and IMHO more self-explanatory. Andrei
May 12 2012
On 5/13/12 4:13 AM, Andrei Alexandrescu wrote:On 5/11/12 10:38 PM, Ary Manzana wrote:Ok. When more people start saying that they can't find a binarySearch method... will you change your mind? :-) (but let's first wait until that moment comes)Add a binarySearch(range, object) method that does all of that? I mean, I don't want to write more than a single line of code to do a binarySearch...assumeSorted(range).contains(object) is still one line, safer, and IMHO more self-explanatory. Andrei
May 12 2012
On Sun, May 13, 2012 at 07:34:19AM +0700, Ary Manzana wrote:On 5/13/12 4:13 AM, Andrei Alexandrescu wrote:[...] Things like this just needs to be properly documented. Just because it isn't called "binarySearch" doesn't mean anything. We aren't trying to T -- Marketing: the art of convincing people to pay for what they didn't need before which you can't deliver after.On 5/11/12 10:38 PM, Ary Manzana wrote:Ok. When more people start saying that they can't find a binarySearch method... will you change your mind? :-)Add a binarySearch(range, object) method that does all of that? I mean, I don't want to write more than a single line of code to do a binarySearch...assumeSorted(range).contains(object) is still one line, safer, and IMHO more self-explanatory. Andrei
May 12 2012
Andrei Alexandrescu:assumeSorted(range).contains(object) is still one line, safer, and IMHO more self-explanatory.It's self-explanatory if the name there contains something like "binarySearch". Otherwise it is NOT self-explanatory, I can't assume it will use a binary search. So it's surely not intuitive. Bye, bearophile
May 13 2012
On Sunday, 13 May 2012 at 10:08:47 UTC, bearophile wrote:Andrei Alexandrescu:100% agree with this. How anyone can possibly think that using assumeSorted(r).contains(x) to do a binary search is more self-explanatory than just writing binarySearch(r, x) is beyond me. It's mind-boggling. We have proof that it is not intuitive: the fact that people frequently ask how to do a binary search in std.algorithm. If it was intuitive, they wouldn't need to ask. If it was self-explanatory, it wouldn't need to be explicitly mentioned in the documentation. Needing documentation is precisely the opposite of self-explanatory. Andrei, you are a reasonable person. What evidence would it take to convince you that this design for doing binary searches is bad?assumeSorted(range).contains(object) is still one line, safer, and IMHO more self-explanatory.It's self-explanatory if the name there contains something like "binarySearch". Otherwise it is NOT self-explanatory, I can't assume it will use a binary search. So it's surely not intuitive. Bye, bearophile
May 14 2012
On Mon, 14 May 2012 12:01:06 +0200, Peter Alexander <peter.alexander.au gmail.com> wrote:On Sunday, 13 May 2012 at 10:08:47 UTC, bearophile wrote:It is not intuitive, I agree. It is, however, documenting. You're not calling binarySearch on any old array, you assume it is sorted, *then* search it. Perhaps it would be better to have a binarySearch function, which can only take a SortedRange, and gives an explanatory error message when used with a NonSortedRange.Andrei Alexandrescu:100% agree with this. How anyone can possibly think that using assumeSorted(r).contains(x) to do a binary search is more self-explanatory than just writing binarySearch(r, x) is beyond me. It's mind-boggling.assumeSorted(range).contains(object) is still one line, safer, and IMHO more self-explanatory.It's self-explanatory if the name there contains something like "binarySearch". Otherwise it is NOT self-explanatory, I can't assume it will use a binary search. So it's surely not intuitive. Bye, bearophile
May 14 2012
On Monday, 14 May 2012 at 10:31:47 UTC, Simen Kjaeraas wrote:On Mon, 14 May 2012 12:01:06 +0200, Peter Alexander <peter.alexander.au gmail.com> wrote:How about users who don't know what binary search is. binary search is an intuitive concept for people who have good programming experience but assumeSorted(r).contains(x) is more intuitive to higher level users. see how many searches you get with binary search on google and how many with contains and sorted. I'm not a developer, I do quantum chemistry and write based on formulas and algorithms in papers, not on libraries. I would prefer people to write code in more general concepts so it's easier for me to understand and learn. And if you know binary search, it's not that much harder to change your style to assumeSorted(r).contains(x); in comparison, to a newbie learning binary search. Also having multiple ways of doing the same thing makes usage more confusing, so it should be avoided unless really needed. So in short, I support that Andrei aims for larger audience.On Sunday, 13 May 2012 at 10:08:47 UTC, bearophile wrote:It is not intuitive, I agree. It is, however, documenting. You're not calling binarySearch on any old array, you assume it is sorted, *then* search it. Perhaps it would be better to have a binarySearch function, which can only take a SortedRange, and gives an explanatory error message when used with a NonSortedRange.Andrei Alexandrescu:100% agree with this. How anyone can possibly think that using assumeSorted(r).contains(x) to do a binary search is more self-explanatory than just writing binarySearch(r, x) is beyond me. It's mind-boggling.assumeSorted(range).contains(object) is still one line, safer, and IMHO more self-explanatory.It's self-explanatory if the name there contains something like "binarySearch". Otherwise it is NOT self-explanatory, I can't assume it will use a binary search. So it's surely not intuitive. Bye, bearophile
May 15 2012
Since this post is about inuition, I'll raise my voice even etc.). From my point of view, the AssumeSorted way makes sense, but without getting a hit on it when searching for BinarySearch it's a bit cryptic. On the other hand, with search hits on the subject in the documenation, anyone should be able to use it. It's a matter of choosing if you want to express what should be done or how it should be done. The concern I can see is about the difference in contract. BinarySearch explains how the operation is being performed and _promises_ to do a binary search. Contain does not promise how it's performed (that's the whole point, right?) and you're at the mercy of the library writer. For carefully profiled code, that can be a disadvantage, since any implementation change could lead to hidden changes in performance characteristics. Then you might want the control over exactly how the operation is performed. The way I see it, both AssumeSorted.Contains and BinarySearch are overlapping in functionality (i.e. a fast search) but not equivalent in contract.
May 16 2012
On Wednesday, 16 May 2012 at 07:05:29 UTC, Anders Sjögren wrote:For carefully profiled code, that can be a disadvantageEither that, or just the plain algorithm. Then the issue isn't profiling -- it's the time complexity. e.g. You can't simply "pretend" it's doing the best thing possible, because libraries never get it right *all* the time. So IMHO saying /how/ to do it is a lot more useful than /what/ to do, since it lets you choose whether your algorithm is O(log(n)) vs. O(n) vs. O(1). (Yes, this means I don't like C++'s std::map or std::unordered_set either, because they tell you nothing about the time complexity. Java did it correct there.)
May 16 2012
Kirill:How about users who don't know what binary search is. binary search is an intuitive concept for people who have good programming experience but assumeSorted(r).contains(x) is more intuitive to higher level users.Even if you don't know the name "binary search" (something that all CS students learn very early in their studies, a concept that is also taught in "Unplugged CS" to little children) how can you be sure that "assumeSorted(r).contains(x)" will perform a "fast search" like when you search people names in a sorted sequence?So in short, I support that Andrei aims for larger audience.Then why is Andrei using the name std.algorithm.schwartzSort? For every 20 CS students and programmers that know what a "binary search" is, you probably get only 1-4 that know what a "Schwartz Sorting" is. So I think your explanation of Andrei aim doesn't hold water. Bye, bearophile
May 16 2012
On 05/16/2012 09:29 AM, bearophile wrote:Kirill:By assuming the library writer is sane, or by reading the documentation.How about users who don't know what binary search is. binary search is an intuitive concept for people who have good programming experience but assumeSorted(r).contains(x) is more intuitive to higher level users.Even if you don't know the name "binary search" (something that all CS students learn very early in their studies, a concept that is also taught in "Unplugged CS" to little children) how can you be sure that "assumeSorted(r).contains(x)" will perform a "fast search" like when you search people names in a sorted sequence?I agree, that the explanation does not hold water, not because of other parts of the API, but simply because binary search is such a basic concept that I wouldn't trust a programmer who does not understand it.So in short, I support that Andrei aims for larger audience.Then why is Andrei using the name std.algorithm.schwartzSort? For every 20 CS students and programmers that know what a "binary search" is, you probably get only 1-4 that know what a "Schwartz Sorting" is. So I think your explanation of Andrei aim doesn't hold water.
May 16 2012
On 5/16/12 2:29 AM, bearophile wrote:Kirill:Just trying my best to do the right thing by everyone. Not much else to read into it. AndreiHow about users who don't know what binary search is. binary search is an intuitive concept for people who have good programming experience but assumeSorted(r).contains(x) is more intuitive to higher level users.Even if you don't know the name "binary search" (something that all CS students learn very early in their studies, a concept that is also taught in "Unplugged CS" to little children) how can you be sure that "assumeSorted(r).contains(x)" will perform a "fast search" like when you search people names in a sorted sequence?So in short, I support that Andrei aims for larger audience.Then why is Andrei using the name std.algorithm.schwartzSort? For every 20 CS students and programmers that know what a "binary search" is, you probably get only 1-4 that know what a "Schwartz Sorting" is. So I think your explanation of Andrei aim doesn't hold water.
May 16 2012
Andrei you are against an in-operator for array, because it would provide a uniform interface for arrays and AA with different complexity. Is contains with different complexity for ranges and for SortedRange not the same?
May 16 2012
On Wed, 16 May 2012 10:47:23 -0400, Tobias Pankrath <panke tzi.de> wrote:Andrei you are against an in-operator for array, because it would provide a uniform interface for arrays and AA with different complexity. Is contains with different complexity for ranges and for SortedRange not the same?No it's not the same. It all depends on what the function advertises as its complexity. It's OK for a function that advertises O(n) complexity to be applied to a type that's optimized into O(lgn) complexity. But it's NOT OK for a function that advertises O(lgn) complexity to be applied to a type that requires O(n) complexity. It all depends on what the existing situation is. Generic code is written against the documentation, because it doesn't know what's actually going to be implemented underneath. -Steve
May 16 2012
On 16-05-2012 17:28, Steven Schveighoffer wrote:On Wed, 16 May 2012 10:47:23 -0400, Tobias Pankrath <panke tzi.de> wrote:People aren't using 'in' in generic code at all, so I'm not sure this comparison makes sense anyway. -- Alex Rønne Petersen alex lycus.org http://lycus.orgAndrei you are against an in-operator for array, because it would provide a uniform interface for arrays and AA with different complexity. Is contains with different complexity for ranges and for SortedRange not the same?No it's not the same. It all depends on what the function advertises as its complexity. It's OK for a function that advertises O(n) complexity to be applied to a type that's optimized into O(lgn) complexity. But it's NOT OK for a function that advertises O(lgn) complexity to be applied to a type that requires O(n) complexity. It all depends on what the existing situation is. Generic code is written against the documentation, because it doesn't know what's actually going to be implemented underneath. -Steve
May 16 2012
On 5/16/12 9:47 AM, Tobias Pankrath wrote:Andrei you are against an in-operator for array, because it would provide a uniform interface for arrays and AA with different complexity. Is contains with different complexity for ranges and for SortedRange not the same?It is. That's why there's no contains with linear complexity. Andrei
May 16 2012
It is. That's why there's no contains with linear complexity. AndreiI missed that. However SortedRange needs better documentation. Before I wrote this, I tried to look it up and it took some time, because I was looking in std.algorithm but SortedRange resides in std.range. The only reference to SortedRange from std.algorithm I could find, was the use of assumeSorted (with no link). So I think the first line of the description of std.algorithm.find should be sometihng like: for binarySearch look at SortedRange. Or include SortedRange in the table at the top, but link to std.range.
May 16 2012
On 5/16/2012 12:29 AM, bearophile wrote:Then why is Andrei using the name std.algorithm.schwartzSort?May the schwartz be with you.
May 16 2012
Al 17/05/12 03:32, En/na Walter Bright ha escrit:On 5/16/2012 12:29 AM, bearophile wrote:Very appropriate :-) On 27 May is the 35 anniversary of the first released film from the Star Wars series. -- Jordi SayolThen why is Andrei using the name std.algorithm.schwartzSort?May the schwartz be with you.
May 16 2012
On Thursday, 17 May 2012 at 03:15:47 UTC, Jordi Sayol wrote:Al 17/05/12 03:32, En/na Walter Bright ha escrit:Walter's quote was from "Spaceballs". :-) -LarsOn 5/16/2012 12:29 AM, bearophile wrote:Very appropriate :-) On 27 May is the 35 anniversary of the first released film from the Star Wars series.Then why is Andrei using the name std.algorithm.schwartzSort?May the schwartz be with you.
May 17 2012
On Thu, 17 May 2012 09:50:44 +0100, Lars T. Kyllingstad <public kyllingen.net> wrote:On Thursday, 17 May 2012 at 03:15:47 UTC, Jordi Sayol wrote:Ahh.. I see your schwartz is as big as mine :p R -- Using Opera's revolutionary email client: http://www.opera.com/mail/Al 17/05/12 03:32, En/na Walter Bright ha escrit:Walter's quote was from "Spaceballs". :-)On 5/16/2012 12:29 AM, bearophile wrote:Very appropriate :-) On 27 May is the 35 anniversary of the first released film from the Star Wars series.Then why is Andrei using the name std.algorithm.schwartzSort?May the schwartz be with you.
May 17 2012
On Tuesday, 15 May 2012 at 17:23:28 UTC, Kirill wrote:How about users who don't know what binary search is. binary search is an intuitive concept for people who have good programming experience but assumeSorted(r).contains(x) is more intuitive to higher level users.If you don't know about binary search, you won't write assumeSorted(r).contains(x) you'll just write r.contains(x) because you have no idea that binary search exists. Why would you bother typing extra characters for a benefit that you are unaware of? If you do know that binary search exists then the obvious algorithm name is binarySearch. If I use .contains to coax a binarySearch then I'm relying on a little bit of faith. In what situations does it give a binary search? [1, 2, 3].contains(2); // does the compiler infer that 1, 2, 3 is sorted? iota(10).contains(5); // is iota implicitly a sorted range? assumeSorted([1, 2, 3]).map!(x => x + 1).contains(3); // does Phobos know that the map is order preserving? assumeSorted([1, 2, 3]).filter!("a & 1").contains(2); // does Phobos know that filters always preserve order? I'd have to read the documentation to find out which of these uses binary search. In fact, I'd probably have to read the Phobos source. If I just used binarySearch then I would be 100% guaranteed that it will use a binary search. I don't have to second guess the compiler -- I just *know*.
May 17 2012
On 5/17/12 4:00 AM, Peter Alexander wrote:On Tuesday, 15 May 2012 at 17:23:28 UTC, Kirill wrote:Doesn't compile.How about users who don't know what binary search is. binary search is an intuitive concept for people who have good programming experience but assumeSorted(r).contains(x) is more intuitive to higher level users.If you don't know about binary search, you won't write assumeSorted(r).contains(x) you'll just write r.contains(x) because you have no idea that binary search exists. Why would you bother typing extra characters for a benefit that you are unaware of? If you do know that binary search exists then the obvious algorithm name is binarySearch. If I use .contains to coax a binarySearch then I'm relying on a little bit of faith. In what situations does it give a binary search? [1, 2, 3].contains(2); // does the compiler infer that 1, 2, 3 is sorted?iota(10).contains(5); // is iota implicitly a sorted range?Doesn't compile.assumeSorted([1, 2, 3]).map!(x => x + 1).contains(3); // does Phobos know that the map is order preserving?Doesn't compile, this would: assumeSorted([1, 2, 3].map!(x => x + 1)).contains(3) (which is quite a trick; map figures the input is a random-access range and exposes a random-access interface as well. Good luck doing that in other languages.)assumeSorted([1, 2, 3]).filter!("a & 1").contains(2); // does Phobos know that filters always preserve order?Doesn't compile, and couldn't because filter() cannot preserve random access.I'd have to read the documentation to find out which of these uses binary search. In fact, I'd probably have to read the Phobos source. If I just used binarySearch then I would be 100% guaranteed that it will use a binary search. I don't have to second guess the compiler -- I just *know*.I agree binarySearch is more precise, but I also think it's a minor issue not worth the cost of changing at this point. Improving names of things in the standard library is a quest that could go forever, make everybody happy we're making progress, and achieve no substantial gain. Andrei
May 17 2012
Andrei Alexandrescu:I agree binarySearch is more precise, but I also think it's a minor issue not worth the cost of changing at this point. Improving names of things in the standard library is a quest that could go forever, make everybody happy we're making progress, and achieve no substantial gain.Names are very important, they are the fist and most important part of an API, they are the first handle for human programmers and their minds. The amount of care Python development group gives to the choice of names is visible and it makes a difference in Python usability. Important names can't be chosen by a single person, because single persons have quirks (they overstate how much common a word or concept is, etc etc). So important names are better chosen by groups, that allow to average out those quirks. I suggest to stick somewhere inside Phobos a name like "binarySearch". Bye, bearophile
May 17 2012
On Thursday, May 17, 2012 18:00:40 bearophile wrote:Andrei Alexandrescu:Yes, names are important, but you'll also never get people to agree on them. They're a classic bikeshedding issue. Unless a name is patently bad, if changing it is going to break code, then you usually shouldn't change it - not when we're talking about a public API (_especially_ when it's the standard library of a language). All of the changes that we made to make Phobos' function names actually follow Phobos' official naming conventions were disruptive enough as it is. We're really trying to read language and library stability, so breaking changes need greater and greater justification for them to be worth it, and simply renaming a function generally isn't going to cut it anymore - not without a _very_ good reason. - Jonathan M DavisI agree binarySearch is more precise, but I also think it's a minor issue not worth the cost of changing at this point. Improving names of things in the standard library is a quest that could go forever, make everybody happy we're making progress, and achieve no substantial gain.Names are very important, they are the fist and most important part of an API, they are the first handle for human programmers and their minds. The amount of care Python development group gives to the choice of names is visible and it makes a difference in Python usability. Important names can't be chosen by a single person, because single persons have quirks (they overstate how much common a word or concept is, etc etc). So important names are better chosen by groups, that allow to average out those quirks. I suggest to stick somewhere inside Phobos a name like "binarySearch".
May 17 2012
On Thursday, 17 May 2012 at 18:46:11 UTC, Jonathan M Davis wrote:On Thursday, May 17, 2012 18:00:40 bearophile wrote:As far as I'm aware, no one has proposed any breaking changes. It's just a new function.Andrei Alexandrescu:Yes, names are important, but you'll also never get people to agree on them. They're a classic bikeshedding issue. Unless a name is patently bad, if changing it is going to break code, then you usually shouldn't change it - not when we're talking about a public API (_especially_ when it's the standard library of a language). All of the changes that we made to make Phobos' function names actually follow Phobos' official naming conventions were disruptive enough as it is. We're really trying to read language and library stability, so breaking changes need greater and greater justification for them to be worth it, and simply renaming a function generally isn't going to cut it anymore - not without a _very_ good reason. - Jonathan M DavisI agree binarySearch is more precise, but I also think it's a minor issue not worth the cost of changing at this point. Improving names of things in the standard library is a quest that could go forever, make everybody happy we're making progress, and achieve no substantial gain.Names are very important, they are the fist and most important part of an API, they are the first handle for human programmers and their minds. The amount of care Python development group gives to the choice of names is visible and it makes a difference in Python usability. Important names can't be chosen by a single person, because single persons have quirks (they overstate how much common a word or concept is, etc etc). So important names are better chosen by groups, that allow to average out those quirks. I suggest to stick somewhere inside Phobos a name like "binarySearch".
May 18 2012
On Thu, May 17, 2012 at 10:26:18AM -0500, Andrei Alexandrescu wrote:On 5/17/12 4:00 AM, Peter Alexander wrote:[...][...] Why not just add something like this then: E binarySearch(R,K)(R range, K key) { return assumeSorted(range).contains(key); } Nobody says we have to change the names of existing code. Adding a wrapper with a nice name works just fine, and doesn't break any existing code, etc.. T -- Who told you to swim in Crocodile Lake without life insurance??I'd have to read the documentation to find out which of these uses binary search. In fact, I'd probably have to read the Phobos source. If I just used binarySearch then I would be 100% guaranteed that it will use a binary search. I don't have to second guess the compiler -- I just *know*.I agree binarySearch is more precise, but I also think it's a minor issue not worth the cost of changing at this point. Improving names of things in the standard library is a quest that could go forever, make everybody happy we're making progress, and achieve no substantial gain.
May 17 2012
On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu wrote:I agree binarySearch is more precise, but I also think it's a minor issue not worth the cost of changing at this point. Improving names of things in the standard library is a quest that could go forever, make everybody happy we're making progress, and achieve no substantial gain.No need to change anything, just add something: bool binarySearch(Range, Value)(Range range, Value value) { return assumeSorted(range).contains(value); } (constraints, predicates and the myriad of qualifiers/decorations omitted for clarity).
May 17 2012
On Thu, May 17, 2012 at 06:52:26PM +0200, Peter Alexander wrote:On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu wrote:Great minds think alike. ;-) T -- It said to install Windows 2000 or better, so I installed Linux instead.I agree binarySearch is more precise, but I also think it's a minor issue not worth the cost of changing at this point. Improving names of things in the standard library is a quest that could go forever, make everybody happy we're making progress, and achieve no substantial gain.No need to change anything, just add something: bool binarySearch(Range, Value)(Range range, Value value) { return assumeSorted(range).contains(value); } (constraints, predicates and the myriad of qualifiers/decorations omitted for clarity).
May 17 2012
On Thursday, May 17, 2012 18:52:26 Peter Alexander wrote:On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu wrote:Yeah, but then we've added a function which adds no real functionality, and we generally try to avoid that. So, it _might_ be reasonable to add it, but it tends to go against how we're trying to function. - Jonathan M DavisI agree binarySearch is more precise, but I also think it's a minor issue not worth the cost of changing at this point. Improving names of things in the standard library is a quest that could go forever, make everybody happy we're making progress, and achieve no substantial gain.No need to change anything, just add something: bool binarySearch(Range, Value)(Range range, Value value) { return assumeSorted(range).contains(value); } (constraints, predicates and the myriad of qualifiers/decorations omitted for clarity).
May 17 2012
On 5/17/12 11:52 AM, Peter Alexander wrote:On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu wrote:I don't see much benefit in this - just lateral walking. As long as the keyphrase "binary search" is present in the documentation, that's all that's needed as far as newcomers discoverability is concerned. AndreiI agree binarySearch is more precise, but I also think it's a minor issue not worth the cost of changing at this point. Improving names of things in the standard library is a quest that could go forever, make everybody happy we're making progress, and achieve no substantial gain.No need to change anything, just add something: bool binarySearch(Range, Value)(Range range, Value value) { return assumeSorted(range).contains(value); } (constraints, predicates and the myriad of qualifiers/decorations omitted for clarity).
May 17 2012
On Thursday, 17 May 2012 at 19:19:04 UTC, Andrei Alexandrescu wrote:On 5/17/12 11:52 AM, Peter Alexander wrote:It's not just for newcomers discoverability, it's also for readability. Reading the assumeSorted version, it's not clear that a binary search is done.On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu wrote:I don't see much benefit in this - just lateral walking. As long as the keyphrase "binary search" is present in the documentation, that's all that's needed as far as newcomers discoverability is concerned.I agree binarySearch is more precise, but I also think it's a minor issue not worth the cost of changing at this point. Improving names of things in the standard library is a quest that could go forever, make everybody happy we're making progress, and achieve no substantial gain.No need to change anything, just add something: bool binarySearch(Range, Value)(Range range, Value value) { return assumeSorted(range).contains(value); } (constraints, predicates and the myriad of qualifiers/decorations omitted for clarity).
May 18 2012
On 5/18/12 4:11 PM, Peter Alexander wrote:On Thursday, 17 May 2012 at 19:19:04 UTC, Andrei Alexandrescu wrote:I guess it is now :o). AndreiOn 5/17/12 11:52 AM, Peter Alexander wrote:It's not just for newcomers discoverability, it's also for readability. Reading the assumeSorted version, it's not clear that a binary search is done.On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu wrote:I don't see much benefit in this - just lateral walking. As long as the keyphrase "binary search" is present in the documentation, that's all that's needed as far as newcomers discoverability is concerned.I agree binarySearch is more precise, but I also think it's a minor issue not worth the cost of changing at this point. Improving names of things in the standard library is a quest that could go forever, make everybody happy we're making progress, and achieve no substantial gain.No need to change anything, just add something: bool binarySearch(Range, Value)(Range range, Value value) { return assumeSorted(range).contains(value); } (constraints, predicates and the myriad of qualifiers/decorations omitted for clarity).
May 18 2012
On Friday, 18 May 2012 at 21:28:45 UTC, Andrei Alexandrescu wrote:I guess it is now :o). Andreilol One more thing that's also annoying about this is that it's not in std.algorithms, but std.range... Asn't binary search an algorithm?
May 18 2012
On 5/18/12 4:36 PM, Mehrdad wrote:On Friday, 18 May 2012 at 21:28:45 UTC, Andrei Alexandrescu wrote:It is, and the decision (after a good amount of deliberation) is arbitrary. Some rationale was that SortedRange has enough structure to make it an "interesting" range, so I put it in std.range. The argument could go either way. Now it's gone one way. Let's move on. AndreiI guess it is now :o). Andreilol One more thing that's also annoying about this is that it's not in std.algorithms, but std.range... Asn't binary search an algorithm?
May 18 2012
On Friday, 18 May 2012 at 22:18:35 UTC, Andrei Alexandrescu wrote:It is, and the decision (after a good amount of deliberation) is arbitrary. Some rationale was that SortedRange has enough structure to make it an "interesting" range, so I put it in std.range. The argument could go either way. Now it's gone one way. Let's move on. AndreiOkay; only pointed it out because I remembered it was also the subject of another one of my SO questions (stackoverflow.com/questions/6975670).
May 18 2012
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:On 5/18/12 4:36 PM, Mehrdad wrote:This is posted long after the conversation, but a partial solution to the confusion could be handled in the docs. Add a section in std.algorithms referring to std.range, so that newcomers can find what they're looking for with less confusion. JerryOn Friday, 18 May 2012 at 21:28:45 UTC, Andrei Alexandrescu wrote:It is, and the decision (after a good amount of deliberation) is arbitrary. Some rationale was that SortedRange has enough structure to make it an "interesting" range, so I put it in std.range. The argument could go either way. Now it's gone one way. Let's move on.I guess it is now :o). Andreilol One more thing that's also annoying about this is that it's not in std.algorithms, but std.range... Asn't binary search an algorithm?
May 28 2012
On Fri, May 18, 2012 at 3:36 PM, Mehrdad <wfunction hotmail.com> wrote:On Friday, 18 May 2012 at 21:28:45 UTC, Andrei Alexandrescu wrote:I fairly often get confused about whether to look in std.range or std.algorithm for something. filter is in algorithm but recurrence is in range, for instance. I can see why but I still sometimes go to the wrong module's documentation to look something up. There should probably be a lot more cross referencing between the two in the documentation. Also, I think std.algorithm could use a mini-FAQ. std.range is long overdue for an entire article explaining ranges but that's a well known omission that pretty much everyone agrees on.I guess it is now :o). Andreilol One more thing that's also annoying about this is that it's not in std.algorithms, but std.range... Asn't binary search an algorithm?
May 18 2012
On Fri, May 18, 2012 at 04:24:47PM -0600, Brad Anderson wrote: [...]Also, I think std.algorithm could use a mini-FAQ. std.range is long overdue for an entire article explaining ranges but that's a well known omission that pretty much everyone agrees on.What about the latest prerelease docs for std.range? I did clean up a lot of stuff there and tried to explain the basic idea of what a range is, and included a link to Andrei's article that describes the idea of ranges in-depth. Or is that still not good enough? How can we improve the docs further? T -- Computers aren't intelligent; they only think they are.
May 18 2012
On Fri, May 18, 2012 at 5:06 PM, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:On Fri, May 18, 2012 at 04:24:47PM -0600, Brad Anderson wrote: [...]I like it. Looks like it's already up on the website and was included with 2.059 unless there are further changes beyond what's on http://dlang.org/phobos/std_range.html It's very clean now and the link to Andrei's article definitely helps. Also, good thinking linking to the print version instead of the difficult to read and confusing non-print version. People I link to Andrei's articles on InformIT sometimes don't realize there is more than one page. It's a great improvement to the documentation. I do agree with Jonathan, though, that a official article on dlang.org like Steven's arrays article would be a nice addition but what you've done helps enormously.Also, I think std.algorithm could use a mini-FAQ. std.range is long overdue for an entire article explaining ranges but that's a well known omission that pretty much everyone agrees on.What about the latest prerelease docs for std.range? I did clean up a lot of stuff there and tried to explain the basic idea of what a range is, and included a link to Andrei's article that describes the idea of ranges in-depth. Or is that still not good enough? How can we improve the docs further? T -- Computers aren't intelligent; they only think they are.
May 18 2012
On Friday, May 18, 2012 16:06:41 H. S. Teoh wrote:On Fri, May 18, 2012 at 04:24:47PM -0600, Brad Anderson wrote: [...]Making improvements to the docs is great and definitely a good idea (I don't think that I've looked what you've done yet though, so I can't comment on the specifics of what's there), but we really should have an in-depth article on ranges in D and Phobos similar to Steven's article on arrays. Solid documentation is a good starting point, but I don't think that it would be appropriate to go as in-depth with the documentation as a good article would. - Jonathan M DavisAlso, I think std.algorithm could use a mini-FAQ. std.range is long overdue for an entire article explaining ranges but that's a well known omission that pretty much everyone agrees on.What about the latest prerelease docs for std.range? I did clean up a lot of stuff there and tried to explain the basic idea of what a range is, and included a link to Andrei's article that describes the idea of ranges in-depth. Or is that still not good enough? How can we improve the docs further?
May 18 2012
Just a note: I believe I *had* seen SortedRange in the docs, but I'd never realized there's something called assumeSorted() that I was supposed to call... so I was searching up and down for how to search an *arbitrary* container, not how to search something which was already pre-sorted for me. (In retrospect, I probably should've just coded binary search myself...) It's very counterintuitive to have to make a new object (or struct) just to do binary search on an array...Maybe the documentation changed since, but currently the documentation for SortedRange says: "To construct a SortedRange from a range r that is known to be already sorted, use assumeSorted described below." And there is assumeSorted in the example.
May 11 2012
On Friday, 11 May 2012 at 19:01:25 UTC, jerro wrote:Yeah, either I missed, or I just didn't look at it, and skipped it entirely just by the header (I don't remember). The point was that it simply wasn't what/where I expected to be.Just a note: I believe I *had* seen SortedRange in the docs, but I'd never realized there's something called assumeSorted() that I was supposed to call... so I was searching up and down for how to search an *arbitrary* container, not how to search something which was already pre-sorted for me. (In retrospect, I probably should've just coded binary search myself...) It's very counterintuitive to have to make a new object (or struct) just to do binary search on an array...Maybe the documentation changed since, but currently the documentation for SortedRange says: "To construct a SortedRange from a range r that is known to be already sorted, use assumeSorted described below." And there is assumeSorted in the example.
May 11 2012
On 11-05-2012 20:05, Mehrdad wrote:On Friday, 11 May 2012 at 17:47:06 UTC, Alex Rønne Petersen wrote:Right, D's template system is definitely inspired by C++, no argument there. But in the vast majority of code, you really don't have to use templates for everything.Complicated language structure? Long compilation times? wat.I'd have to agree... Several things in D are really hard to understand if you don't already have a C++ background: 1. "templates": they seem to take in just about anything, and return just about anything. They can be pretty confusing, especially when you have to worry about overloading vs. specialization vs. constraints, or types vs. aliases...2. Tuples (I'm referring to both tuple() and TypeTuple()) are very confusing if you don't happen to suddenly "get" them.I don't know about that. They seemed simple enough to me.3. Ranges aren't confusing, but USING them certainly is.On the contrary, I actually think we're lacking proper documentation on what ranges are.Don't believe me? It's VERY straightforward. In D, it's VERY CONFUSING -- there *is* no way to do this directly! Which led me to ask this question: http://stackoverflow.com/questions/4622377 and the solution indeed was NOT something I would've found by myself without spending hours on it (which I already had partially done).Library issue.4. is(typeof(foo) U) is very confusing; it's completely unintuitive 5. For that matter, is() is completely unintuitiveDefinitely. is() is an abomination.6. The 'in' operator returns a pointer (instead of a boolean). Which is fine, except that it's not what you'd expect in any languages other than C/C++. i.e. Non-intuitiveI've always found it very intuitive actually... and it saves me from having to write extra code to do the actual lookup (speed isn't even the point here, I just want concise code).7. __traits() are confusingI have the same stance WRT __traits as I do for is(). We need a better solution to metaprogramming. But again, most code really won't be doing all that much low-level metaprogramming.8. there's more but I just can't think of them right now-- - Alex
May 11 2012
On Friday, 11 May 2012 at 18:16:02 UTC, Alex Rønne Petersen wrote:On 11-05-2012 20:05, Mehrdad wrote:Not sure I agree. Templates are almost *impossible* to ignore when working with ranges.1. "templates": they seem to take in just about anything, and return just about anything. They can be pretty confusing, especially when youhave to worry about overloading vs. specialization vs. constraints, or types vs. aliases...Right, D's template system is definitely inspired by C++, no argument there. But in the vast majority of code, you really don't have to use templates for everything.Me too, as a matter of fact. But they definitely aren't intuitive (just judge by the number of questions about them that pop up on StackOverflow or elsewhere...)2. Tuples (I'm referring to both tuple() and TypeTuple()) are very confusing if you don't happen to suddenly "get" them.I don't know about that. They seemed simple enough to me.Yeah probably.3. Ranges aren't confusing, but USING them certainly is.>On the contrary, I actually think we're lacking proper documentation on what ranges are.Yeah, you got me there... But in practice it doesn't make a difference what the cause is, so much as what the effect is...array. It's VERY straightforward. In D, it's VERY CONFUSINGLibrary issue.Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic, like testing to see if something is in an associative array! The mere fact that it uses a pointer makes it unintuitive to a6. The 'in' operator returns a pointer (instead of a boolean). Which is fine, except that it's not what you'd expect in any languages other than C/C++. i.e. Non-intuitiveI've always found it very intuitive actually... and it saves me from having to write extra code to do the actual lookup (speed isn't even the point here, I just want concise code).But again, most code really won't be doing all that much low-level metaprogramming.That's the hope, but I keep on finding myself putting __traits(compiles, ...) on template conditions and such...
May 11 2012
On 11-05-2012 20:28, Mehrdad wrote:On Friday, 11 May 2012 at 18:16:02 UTC, Alex Rønne Petersen wrote:True, but I think what we lack is clear and concise documentation on them.On 11-05-2012 20:05, Mehrdad wrote:Not sure I agree. Templates are almost *impossible* to ignore when working with ranges.1. "templates": they seem to take in just about anything, and return just about anything. They can be pretty confusing, especially when youhave to worry about overloading vs. specialization vs. constraints, or types vs. aliases...Right, D's template system is definitely inspired by C++, no argument there. But in the vast majority of code, you really don't have to use templates for everything.Me too, as a matter of fact. But they definitely aren't intuitive (just judge by the number of questions about them that pop up on StackOverflow or elsewhere...)2. Tuples (I'm referring to both tuple() and TypeTuple()) are very confusing if you don't happen to suddenly "get" them.I don't know about that. They seemed simple enough to me.True. I'm just speaking from a purely language perspective. But D is a batteries-included language, so if the standard library has problems, you could arguably say D has problems as a whole...Yeah probably.3. Ranges aren't confusing, but USING them certainly is.>On the contrary, I actually think we're lacking proper documentation on what ranges are.Yeah, you got me there... But in practice it doesn't make a difference what the cause is, so much as what the effect is...It's VERY straightforward. In D, it's VERY CONFUSINGLibrary issue.I agree that the fact that it returns a *pointer* is probably not ideal. Maybe if D had proper pattern matching, it could have returned some kind of Option!T type or whatever...Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic, like testing to see if something is in an associative array!6. The 'in' operator returns a pointer (instead of a boolean). Which is fine, except that it's not what you'd expect in any languages other than C/C++. i.e. Non-intuitiveI've always found it very intuitive actually... and it saves me from having to write extra code to do the actual lookup (speed isn't even the point here, I just want concise code).The mere fact that it uses a pointer makes it unintuitive to a largeI've actually found that std.traits and if () constraints on declarations tend to work for most of my cases. But YMMV and all that. -- - AlexBut again, most code really won't be doing all that much low-level metaprogramming.That's the hope, but I keep on finding myself putting __traits(compiles, ...) on template conditions and such...
May 11 2012
"Mehrdad" <wfunction hotmail.com> wrote in message news:oksltzwvkdrrjidcnqnm forum.dlang.org...On Friday, 11 May 2012 at 18:16:02 UTC, Alex Rønne Petersen wrote:I use 'in' all the time, and I never even think about it returning a pointer. I just do: if(foo in bar) And it just works. So I don't see a particularly big problem here.On 11-05-2012 20:05, Mehrdad wrote:Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic, like testing to see if something is in an associative array! The mere fact that it uses a pointer makes it unintuitive to a large6. The 'in' operator returns a pointer (instead of a boolean). Which is fine, except that it's not what you'd expect in any languages other than C/C++. i.e. Non-intuitiveI've always found it very intuitive actually... and it saves me from having to write extra code to do the actual lookup (speed isn't even the point here, I just want concise code).
May 11 2012
On 05/11/2012 10:10 PM, Nick Sabalausky wrote:"Mehrdad"<wfunction hotmail.com> wrote in message news:oksltzwvkdrrjidcnqnm forum.dlang.org...Try this: bool fun(){ return foo in bar; }On Friday, 11 May 2012 at 18:16:02 UTC, Alex Rønne Petersen wrote:I use 'in' all the time, and I never even think about it returning a pointer. I just do: if(foo in bar) And it just works. So I don't see a particularly big problem here.On 11-05-2012 20:05, Mehrdad wrote:Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic, like testing to see if something is in an associative array! The mere fact that it uses a pointer makes it unintuitive to a large6. The 'in' operator returns a pointer (instead of a boolean). Which is fine, except that it's not what you'd expect in any languages other than C/C++. i.e. Non-intuitiveI've always found it very intuitive actually... and it saves me from having to write extra code to do the actual lookup (speed isn't even the point here, I just want concise code).
May 11 2012
On Friday, May 11, 2012 23:45:30 Timon Gehr wrote:On 05/11/2012 10:10 PM, Nick Sabalausky wrote:Then you do bool fun() { return cast(bool)(foo in bar); } It's not a big deal at all. It's just that if you expect in to return bool rather than a pointer, you're going to be surprised at what happens when you write a function like that rather than use it in an if condition. But since the documentation clearly states that it returns a pointer, it shouldn't really surprise anyone - unless they failed to read either the documentation or TDPL and go completely off of what they _think_ the code should mean without actually reading anything which would teach them the language (which is a bad idea anyway). - Jonathan M Davis"Mehrdad"<wfunction hotmail.com> wrote in message news:oksltzwvkdrrjidcnqnm forum.dlang.org...Try this: bool fun(){ return foo in bar; }On Friday, 11 May 2012 at 18:16:02 UTC, Alex Rønne Petersen wrote:I use 'in' all the time, and I never even think about it returning a pointer. I just do: if(foo in bar) And it just works. So I don't see a particularly big problem here.On 11-05-2012 20:05, Mehrdad wrote:Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic, like testing to see if something is in an associative array! The mere fact that it uses a pointer makes it unintuitive to a large6. The 'in' operator returns a pointer (instead of a boolean). Which is fine, except that it's not what you'd expect in any languages other than C/C++. i.e. Non-intuitiveI've always found it very intuitive actually... and it saves me from having to write extra code to do the actual lookup (speed isn't even the point here, I just want concise code).
May 11 2012
On Friday, 11 May 2012 at 21:58:02 UTC, Jonathan M Davis wrote:Then you do bool fun() { return cast(bool)(foo in bar); }cast() scares the **** out of me
May 11 2012
On 12-05-2012 00:05, Mehrdad wrote:On Friday, 11 May 2012 at 21:58:02 UTC, Jonathan M Davis wrote:bool fun() { return !!(foo in bar); } *flees* -- - AlexThen you do bool fun() { return cast(bool)(foo in bar); }cast() scares the **** out of me
May 11 2012
On Friday, 11 May 2012 at 22:11:21 UTC, Alex Rønne Petersen wrote:On 12-05-2012 00:05, Mehrdad wrote:lolOn Friday, 11 May 2012 at 21:58:02 UTC, Jonathan M Davis wrote:bool fun() { return !!(foo in bar); } *flees*Then you do bool fun() { return cast(bool)(foo in bar); }cast() scares the **** out of me
May 11 2012
On 05/12/2012 12:05 AM, Mehrdad wrote:On Friday, 11 May 2012 at 21:58:02 UTC, Jonathan M Davis wrote:cast(bool) is peaceful.Then you do bool fun() { return cast(bool)(foo in bar); }cast() scares the **** out of me
May 11 2012
On 05/11/2012 11:57 PM, Jonathan M Davis wrote:Then you do bool fun() { return cast(bool)(foo in bar); } It's not a big deal at all.I didn't claim it was. Still, most issues people seem to have with D are trivial syntactic ones.It's just that if you expect in to return bool rather than a pointer, you're going to be surprised at what happens when you write a function like that rather than use it in an if condition. But since the documentation clearly states that it returns a pointer, it shouldn't really surprise anyoneI was surprised when I read the relevant parts of the documentation.- unless they failed to read either the documentation or TDPL and go completely off of what they _think_ the code should mean without actually reading anything which would teach them the language (which is a bad idea anyway).Well I fully agree with that last point (having read the entire language documentation before the first attempt to install the compiler), but 1. that is perhaps not how the 'average programmer' works. it seems to be the case that many programmers who fail to rtfm blame the tool. (bringing up fuzzy terms like 'intuitive' to defend their pov) 2. 'in' is certainly a very non-descriptive name for what it does. It is similar to eg. naming subtraction '<'. 3. why are we always discussing syntax on this NG?
May 11 2012
On 05/11/2012 02:45 PM, Timon Gehr wrote:On 05/11/2012 10:10 PM, Nick Sabalausky wrote:Isn't that an inconsistency in the language then? Are pointer values implicitly convertible to bool or not? Ali -- D Programming Language Tutorial: http://ddili.org/ders/d.en/index.htmlI use 'in' all the time, and I never even think about it returning a pointer. I just do: if(foo in bar) And it just works. So I don't see a particularly big problem here.Try this: bool fun(){ return foo in bar; }
May 11 2012
On 05/12/2012 01:47 AM, Ali Çehreli wrote:On 05/11/2012 02:45 PM, Timon Gehr wrote:if(condition) { ... } is equivalent to if(cast(bool)condition) { ... } i.e. this conversion is 'explicit'.On 05/11/2012 10:10 PM, Nick Sabalausky wrote:Isn't that an inconsistency in the language then? Are pointer values implicitly convertible to bool or not? AliI use 'in' all the time, and I never even think about it returning a pointer. I just do: if(foo in bar) And it just works. So I don't see a particularly big problem here.Try this: bool fun(){ return foo in bar; }
May 11 2012
On 05/11/2012 05:12 PM, Timon Gehr wrote:On 05/12/2012 01:47 AM, Ali Çehreli wrote:WAT. That's an "implicit explicit" conversion, which I have never known existed! :p Ali -- D Programming Language Tutorial: http://ddili.org/ders/d.en/index.htmlOn 05/11/2012 02:45 PM, Timon Gehr wrote:if(condition) { ... } is equivalent to if(cast(bool)condition) { ... } i.e. this conversion is 'explicit'.On 05/11/2012 10:10 PM, Nick Sabalausky wrote:Isn't that an inconsistency in the language then? Are pointer values implicitly convertible to bool or not? AliI use 'in' all the time, and I never even think about it returning a pointer. I just do: if(foo in bar) And it just works. So I don't see a particularly big problem here.Try this: bool fun(){ return foo in bar; }
May 11 2012
On Saturday, 12 May 2012 at 00:12:07 UTC, Timon Gehr wrote:On 05/12/2012 01:47 AM, Ali Çehreli wrote:I'm not sure what you're talking about, there is no implicit conversion to bool. dmd returns: bug.d(6): Error: cannot implicitly convert expression (foo in bar) of type int* to bool With the cast(bool), everything works fine.On 05/11/2012 02:45 PM, Timon Gehr wrote:if(condition) { ... } is equivalent to if(cast(bool)condition) { ... } i.e. this conversion is 'explicit'.On 05/11/2012 10:10 PM, Nick Sabalausky wrote:Isn't that an inconsistency in the language then? Are pointer values implicitly convertible to bool or not? AliI use 'in' all the time, and I never even think about it returning a pointer. I just do: if(foo in bar) And it just works. So I don't see a particularly big problem here.Try this: bool fun(){ return foo in bar; }
May 12 2012
On 05/12/2012 12:26 AM, SomeDude wrote:On Saturday, 12 May 2012 at 00:12:07 UTC, Timon Gehr wrote:Which example are you testing with? // With dmd 2.059, this compiles: void main() { int[int] aa; if (42 in aa) { } } // But this does not compile: bool foo() { int[int] aa; return 42 in aa; } Ali -- D Programming Language Tutorial: http://ddili.org/ders/d.en/index.htmlOn 05/12/2012 01:47 AM, Ali Çehreli wrote:I'm not sure what you're talking about, there is no implicit conversion to bool. dmd returns: bug.d(6): Error: cannot implicitly convert expression (foo in bar) of type int* to bool With the cast(bool), everything works fine.On 05/11/2012 02:45 PM, Timon Gehr wrote:if(condition) { ... } is equivalent to if(cast(bool)condition) { ... } i.e. this conversion is 'explicit'.On 05/11/2012 10:10 PM, Nick Sabalausky wrote:Isn't that an inconsistency in the language then? Are pointer values implicitly convertible to bool or not? AliI use 'in' all the time, and I never even think about it returning a pointer. I just do: if(foo in bar) And it just works. So I don't see a particularly big problem here.Try this: bool fun(){ return foo in bar; }
May 12 2012
"Ali Çehreli" <acehreli yahoo.com> wrote in message news:jok8f1$k1r$1 digitalmars.com...On 05/11/2012 02:45 PM, Timon Gehr wrote:Like Timon said, it's a feature of "if". I agree it's weird and confusing, though. At least I'm used to it :/On 05/11/2012 10:10 PM, Nick Sabalausky wrote:Isn't that an inconsistency in the language then? Are pointer values implicitly convertible to bool or not?I use 'in' all the time, and I never even think about it returning a pointer. I just do: if(foo in bar) And it just works. So I don't see a particularly big problem here.Try this: bool fun(){ return foo in bar; }
May 11 2012
On 11 May 2012 21:28, Mehrdad <wfunction hotmail.com> wrote:Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basicI'd like to think this were true, but the fact that 'ref' barely works makes this almost immediately false when trying to write any non-trivial program.
May 12 2012
On 05/12/2012 10:13 AM, Manu wrote:On 11 May 2012 21:28, Mehrdad <wfunction hotmail.com <mailto:wfunction hotmail.com>> wrote: Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic I'd like to think this were true, but the fact that 'ref' barely works makes this almost immediately false when trying to write any non-trivial program.It depends on the coding style.
May 12 2012
On Saturday, May 12, 2012 11:26:37 Timon Gehr wrote:On 05/12/2012 10:13 AM, Manu wrote:I rarely end up passing by either ref or pointer, and the only issues that I've ever had with ref relate to the fact that you can't pass it rvalues. Obviously both pointers and ref have their uses, but I'd definitely have to concur that it depends on your coding style and what you're doing. Also, I really don't know what's wrong with ref such that anyone could say that it "barely works" other than the issues with rvalues and functions which take ref or const ref. - Jonathan M DavisOn 11 May 2012 21:28, Mehrdad <wfunction hotmail.com <mailto:wfunction hotmail.com>> wrote: Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic I'd like to think this were true, but the fact that 'ref' barely works makes this almost immediately false when trying to write any non-trivial program.It depends on the coding style.
May 12 2012
On 12 May 2012 12:26, Timon Gehr <timon.gehr gmx.ch> wrote:On 05/12/2012 10:13 AM, Manu wrote:If the distinction is whether one likes to have data structures in their code or not, I reckon there's a reasonably large user base in the former? :) Once you use 'struct' you can't avoid pointers, given that ref just doesn't work in many (perhaps most) situations.On 11 May 2012 21:28, Mehrdad <wfunction hotmail.com <mailto:wfunction hotmail.com>**> wrote: Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic I'd like to think this were true, but the fact that 'ref' barely works makes this almost immediately false when trying to write any non-trivial program.It depends on the coding style.
May 12 2012
On 05/12/2012 11:37 AM, Manu wrote:On 12 May 2012 12:26, Timon Gehr <timon.gehr gmx.ch <mailto:timon.gehr gmx.ch>> wrote: On 05/12/2012 10:13 AM, Manu wrote: On 11 May 2012 21:28, Mehrdad <wfunction hotmail.com <mailto:wfunction hotmail.com> <mailto:wfunction hotmail.com <mailto:wfunction hotmail.com>>__> wrote: Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic I'd like to think this were true, but the fact that 'ref' barely works makes this almost immediately false when trying to write any non-trivial program. It depends on the coding style. If the distinction is whether one likes to have data structures in their code or not,Classes and dynamic arrays can be used to build data structures as well, so whether or not you usually use pointers is a matter of style. (FWIW, I use them too.)I reckon there's a reasonably large user base in the former? :) Once you use 'struct' you can't avoid pointers, given that ref just doesn't work in many (perhaps most) situations.The assertion was "Yes, I agree, but consider that D users should NOT *have to* work with pointers *to do something so basic*"
May 12 2012
On Saturday, May 12, 2012 12:37:12 Manu wrote:On 12 May 2012 12:26, Timon Gehr <timon.gehr gmx.ch> wrote:Since structs are generally value types, it's extremely common to just pass them by value - so no refs or pointers are involved. I _rarely_ need pointers for structs, and I don't need ref for them all that often either. And aside from the need to duplicate functions which take const ref so that they work with rvalues, I don't know what about ref you could think doesn't work. - Jonathan M DavisOn 05/12/2012 10:13 AM, Manu wrote:If the distinction is whether one likes to have data structures in their code or not, I reckon there's a reasonably large user base in the former? :) Once you use 'struct' you can't avoid pointers, given that ref just doesn't work in many (perhaps most) situations.On 11 May 2012 21:28, Mehrdad <wfunction hotmail.com <mailto:wfunction hotmail.com>**> wrote: Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic I'd like to think this were true, but the fact that 'ref' barely works makes this almost immediately false when trying to write any non-trivial program.It depends on the coding style.
May 12 2012
On 12 May 2012 12:37, Jonathan M Davis <jmdavisProg gmx.com> wrote:On Saturday, May 12, 2012 11:26:37 Timon Gehr wrote:struct X { int i; X opBinary(string op)(const ref X b) if(op == "+") { return X(i + b.i); } ref X opOpAssign(string op)(const ref X b) if(op == "+") { i += b.i; return this; } ...etc } ref X func(ref X x) { return x; } bool maybe() { return (time() & 1) != 0; } void test() { X a,b,c; X v[]; func(a); // this is basically the only expression that works X t = a + (b + c); // fail a += b + c; // fail ref X t = func(a); // fail func(a + b); // fail func(maybe() ? a : b); // this generates bad code: http://forum.dlang.org/thread/cnwpmhihmckpjhlaszzy forum.dlang.org ref X t = v[some + complex * (expression + that_i_dont_want_to_repeat())]; // fail foreach(i; 0..10) { ref X t = v[some + expression * involving - i]; // fail } } Just a couple of extremely common usage patterns that come to mind. I'm sure there are many more...On 05/12/2012 10:13 AM, Manu wrote:withOn 11 May 2012 21:28, Mehrdad <wfunction hotmail.com <mailto:wfunction hotmail.com>> wrote: Yes, I agree, but consider that D users should NOT have to worknon-trivialpointers to do something so basic I'd like to think this were true, but the fact that 'ref' barely works makes this almost immediately false when trying to write anyI rarely end up passing by either ref or pointer, and the only issues that I've ever had with ref relate to the fact that you can't pass it rvalues. Obviously both pointers and ref have their uses, but I'd definitely have to concur that it depends on your coding style and what you're doing. Also, I really don't know what's wrong with ref such that anyone could say that it "barely works" other than the issues with rvalues and functions which take ref or const ref.program.It depends on the coding style.
May 12 2012
On Fri, May 11, 2012 at 08:05:57PM +0200, Mehrdad wrote:On Friday, 11 May 2012 at 17:47:06 UTC, Alex Rønne Petersen wrote:Templates are stencils for generating code. There's nothing confusing about that, unless you try to shoehorn them into a preconceived mental model of functions that take parameters and return something. Granted, proper tutorials need to be written and put in a prominent place so that newbies start on the right footing.Complicated language structure? Long compilation times? wat.I'd have to agree... Several things in D are really hard to understand if you don't already have a C++ background: 1. "templates": they seem to take in just about anything, and return just about anything. They can be pretty confusing, especially when you have to worry about overloading vs. specialization vs. constraints, or types vs. aliases...2. Tuples (I'm referring to both tuple() and TypeTuple()) are very confusing if you don't happen to suddenly "get" them.Again, the problem is lack of proper introductory documentation for them. Actually, I find that to be a consistent problem with much of the current D docs. They appear to be written for people who already know what the thing is, and as such is very unhelpful to a newbie.3. Ranges aren't confusing, but USING them certainly is. Don't believe me? array. It's VERY straightforward. In D, it's VERY CONFUSING -- there *is* no way to do this directly! Which led me to ask this question: http://stackoverflow.com/questions/4622377 and the solution indeed was NOT something I would've found by myself without spending hours on it (which I already had partially done).Again, this is due to poor (or lack of) introductory docs. Really, things like Ali's excellent D book need to be put in a prominent place on dlang.org, rather than relegated to a secondary source. Most of the stuff on dlang.org is written as reference material rather than tutorial material. It does serve its purpose -- it's there for reference when you need to look something up. But it's very unhelpful for someone trying to get started with the language.4. is(typeof(foo) U) is very confusing; it's completely unintuitive 5. For that matter, is() is completely unintuitiveis() syntax is a horrible mess. Walter has said that he'd like to redesign it eventually... but it's not going to happen in the near future because it's a breaking change.6. The 'in' operator returns a pointer (instead of a boolean). Which is fine, except that it's not what you'd expect in any languages other than C/C++. i.e. Non-intuitiveActually, that is a WAT even for somebody coming from C/C++.7. __traits() are confusing[...] But they are advanced stuff that you generally don't need until you're familiar with the language. I don't see this as a problem. T -- Two American lawyers went down to the beach for a swim. Seeing a canoe rental nearby, one asked the other, "Roe, or Wade?"
May 11 2012
On Friday, 11 May 2012 at 18:21:24 UTC, H. S. Teoh wrote:Templates are stencils for generating code. There's nothing confusing about that."Stencils for generating code"? _This_??! :O template hasMember(T, string name) { enum hasMember = __traits(hasMember, T, name); } Imagine a new user's confusion when seeing something like this. (Not sure I got it exactly right, but my point is there.)
May 11 2012
On Fri, May 11, 2012 at 08:38:41PM +0200, Mehrdad wrote:On Friday, 11 May 2012 at 18:21:24 UTC, H. S. Teoh wrote:Yes, that's exactly how stencils work. You're essentially generating a declaration of the form: enum hasMember = ...; where what's in the ... depends on the parameters you passed to the template. So for example, if T is say MyClass, and name is myfield, then the stencil stamps out: enum hasMember = __traits(hasMember, MyClass, myfield); Now, bad __traits syntax aside (and I do agree with you that __traits() could've had more intuitive syntax), this is just a piece of code that depends on some compile-time knowledge. So if MyClass has a field called myfield, then the final code produced is just: enum hasMember = true; Otherwise, the code produced is: enum hasMember = false; You could've typed out the final code yourself, and the effect is exactly the same. The only difference is that capturing the process of producing this code inside a template allows you to do generic programming, that is, instead of checking each class for a particular member in every instance, you define a template that, in effect, replicates this process for you. And once you have this automation, you can build upon it -- whence comes templates that call other templates, function signatures constraints, etc.. If newbies had the proper introduction to the concept of templates (instead of being dunked in the deep end of the pool with signature constraints that use templates, nested templates, etc., with no prior warning), they wouldn't have such a hard time with them. T -- There are 10 kinds of people in the world: those who can count in binary, and those who can't.Templates are stencils for generating code. There's nothing confusing about that."Stencils for generating code"? _This_??! :O template hasMember(T, string name) { enum hasMember = __traits(hasMember, T, name); } Imagine a new user's confusion when seeing something like this. (Not sure I got it exactly right, but my point is there.)
May 11 2012
On Friday, 11 May 2012 at 18:53:57 UTC, H. S. Teoh wrote:On Fri, May 11, 2012 at 08:38:41PM +0200, Mehrdad wrote:That's not how you see it when you're learning though. It's more like, I can imagine someone asking these: 1. Why the heck do I see "hasMember" twice? 2. What does this have to do with enums? 3. Where is anything getting "returned"??? 4. So you mean templates are THINGS?? I thought you needed a template SOMETHING, like a template struct, template function, etc... 5. What the heck is TypeTuple!()? Where's the blueprint? etc.On Friday, 11 May 2012 at 18:21:24 UTC, H. S. Teoh wrote:Yes, that's exactly how stencils work. You're essentially generating a declaration of the form: enum hasMember = ...; <snip>Templates are stencils for generating code. There's nothing confusing about that."Stencils for generating code"? _This_??! :O template hasMember(T, string name) { enum hasMember = __traits(hasMember, T, name); } Imagine a new user's confusion when seeing something like this. (Not sure I got it exactly right, but my point is there.)
May 11 2012
On Fri, May 11, 2012 at 09:02:52PM +0200, Mehrdad wrote:On Friday, 11 May 2012 at 18:53:57 UTC, H. S. Teoh wrote:Well, it *should* be seen that way. The fact that it isn't means that the user didn't get a proper introduction to the concept.On Fri, May 11, 2012 at 08:38:41PM +0200, Mehrdad wrote:That's not how you see it when you're learning though.On Friday, 11 May 2012 at 18:21:24 UTC, H. S. Teoh wrote:Yes, that's exactly how stencils work. You're essentially generating a declaration of the form: enum hasMember = ...; <snip>Templates are stencils for generating code. There's nothing confusing about that."Stencils for generating code"? _This_??! :O template hasMember(T, string name) { enum hasMember = __traits(hasMember, T, name); } Imagine a new user's confusion when seeing something like this. (Not sure I got it exactly right, but my point is there.)It's more like, I can imagine someone asking these: 1. Why the heck do I see "hasMember" twice?It should be more like, "there's a template keyword, I wonder what it means -- <look up docs, which has a proper intro to the concept> -- ohhh so that's what it means. The fact that this first step failed means the documentation has failed.2. What does this have to do with enums? 3. Where is anything getting "returned"???Return? Why should templates return anything?4. So you mean templates are THINGS?? I thought you needed a template SOMETHING, like a template struct, template function, etc...A stencil is a thing. What you stamp out depends on what's in it.5. What the heck is TypeTuple!()? Where's the blueprint?[...] Now, TypeTuples are a completely different kettle o' fish. They need their own proper introduction. :-) Trying to understand TypeTuple before you understand templates is like trying to run before you can stand. T -- "A man's wife has more power over him than the state has." -- Ralph Emerson
May 11 2012
On Friday, 11 May 2012 at 19:02:53 UTC, Mehrdad wrote:On Friday, 11 May 2012 at 18:53:57 UTC, H. S. Teoh wrote:I think TypeTuples originate from Andrei's famous book "Modern C++ Design"(chapter 3: Typelists), so it's essentially known by C++ programmers. Indeed, it does need some introduction if you haven't been exposed to these before.On Fri, May 11, 2012 at 08:38:41PM +0200, Mehrdad wrote:That's not how you see it when you're learning though. It's more like, I can imagine someone asking these: 1. Why the heck do I see "hasMember" twice? 2. What does this have to do with enums? 3. Where is anything getting "returned"??? 4. So you mean templates are THINGS?? I thought you needed a template SOMETHING, like a template struct, template function, etc... 5. What the heck is TypeTuple!()? Where's the blueprint? etc.On Friday, 11 May 2012 at 18:21:24 UTC, H. S. Teoh wrote:Yes, that's exactly how stencils work. You're essentially generating a declaration of the form: enum hasMember = ...; <snip>Templates are stencils for generating code. There's nothing confusing about that."Stencils for generating code"? _This_??! :O template hasMember(T, string name) { enum hasMember = __traits(hasMember, T, name); } Imagine a new user's confusion when seeing something like this. (Not sure I got it exactly right, but my point is there.)
May 11 2012
On Friday, 11 May 2012 at 19:02:53 UTC, Mehrdad wrote:On Friday, 11 May 2012 at 18:53:57 UTC, H. S. Teoh wrote:BTW, don't forget to have a look at the articles on the left: http://dlang.org/tuple.htmlOn Fri, May 11, 2012 at 08:38:41PM +0200, Mehrdad wrote:That's not how you see it when you're learning though. It's more like, I can imagine someone asking these: 1. Why the heck do I see "hasMember" twice? 2. What does this have to do with enums? 3. Where is anything getting "returned"??? 4. So you mean templates are THINGS?? I thought you needed a template SOMETHING, like a template struct, template function, etc... 5. What the heck is TypeTuple!()? Where's the blueprint? etc.On Friday, 11 May 2012 at 18:21:24 UTC, H. S. Teoh wrote:Yes, that's exactly how stencils work. You're essentially generating a declaration of the form: enum hasMember = ...; <snip>Templates are stencils for generating code. There's nothing confusing about that."Stencils for generating code"? _This_??! :O template hasMember(T, string name) { enum hasMember = __traits(hasMember, T, name); } Imagine a new user's confusion when seeing something like this. (Not sure I got it exactly right, but my point is there.)
May 11 2012
On 5/11/2012 12:02 PM, Mehrdad wrote:On Friday, 11 May 2012 at 18:53:57 UTC, H. S. Teoh wrote:I tend to agree. I think this is better (I've never gotten around to implementing it): enum hasMember(T, string name) = __traits(hasMember, T, name); I.e. analogously to struct templates.On Fri, May 11, 2012 at 08:38:41PM +0200, Mehrdad wrote:[...] It's more like, I can imagine someone asking these: 1. Why the heck do I see "hasMember" twice? 2. What does this have to do with enums? 3. Where is anything getting "returned"??? 4. So you mean templates are THINGS?? I thought you needed a template SOMETHING, like a template struct, template function, etc...template hasMember(T, string name) { enum hasMember = __traits(hasMember, T, name); }
May 11 2012
On Friday, 11 May 2012 at 23:47:18 UTC, Walter Bright wrote:I tend to agree. I think this is better (I've never gotten around to implementing it): enum hasMember(T, string name) = __traits(hasMember, T, name); I.e. analogously to struct templates.Mmmm... I like the idea/syntax, but not the word "enum". It certainly has nothing to do with enums, so I think it'd be even more confusing in that regard. :)
May 11 2012
"Mehrdad" <wfunction hotmail.com> wrote in message news:hnottedhszpplpbqtvyx forum.dlang.org...On Friday, 11 May 2012 at 23:47:18 UTC, Walter Bright wrote:While do I agree 100% that 'enum' is a horrid name (*much* worse than calling immutables "invariant" - that at least had *some* logic to it), that is a completely separate issue.I tend to agree. I think this is better (I've never gotten around to implementing it): enum hasMember(T, string name) = __traits(hasMember, T, name); I.e. analogously to struct templates.Mmmm... I like the idea/syntax, but not the word "enum". It certainly has nothing to do with enums, so I think it'd be even more confusing in that regard. :)
May 11 2012
On Fri, May 11, 2012 at 8:55 PM, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:If newbies had the proper introduction to the concept of templates (instead of being dunked in the deep end of the pool with signature constraints that use templates, nested templates, etc., with no prior warning), they wouldn't have such a hard time with them.I wrote a tutorial on templates, any comment is welcome: https://github.com/PhilippeSigaud/D-templates-tutorial Direct link to the pdf: https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf?raw=true I need to get back to it, I was side-tracked by other projects and still have things to add to the doc. Philippe
May 11 2012
On Friday, 11 May 2012 at 19:02:50 UTC, Philippe Sigaud wrote:On Fri, May 11, 2012 at 8:55 PM, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:Philippe, I have already went through that draft 3/4 times. Even though I am in the D world for a decade, I always learn something new about D templates and related. Amazing work! Thank you!If newbies had the proper introduction to the concept of templates (instead of being dunked in the deep end of the pool with signature constraints that use templates, nested templates, etc., with no prior warning), they wouldn't have such a hard time with them.I wrote a tutorial on templates, any comment is welcome: https://github.com/PhilippeSigaud/D-templates-tutorial Direct link to the pdf: https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf?raw=true I need to get back to it, I was side-tracked by other projects and still have things to add to the doc. Philippe
May 12 2012
Am Fri, 11 May 2012 21:02:40 +0200 schrieb Philippe Sigaud <philippe.sigaud gmail.com>:On Fri, May 11, 2012 at 8:55 PM, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:Your PDF is my reference manual on templates for quite a while. Thanks for putting it up! -- MarcoIf newbies had the proper introduction to the concept of templates (instead of being dunked in the deep end of the pool with signature constraints that use templates, nested templates, etc., with no prior warning), they wouldn't have such a hard time with them.I wrote a tutorial on templates, any comment is welcome: https://github.com/PhilippeSigaud/D-templates-tutorial Direct link to the pdf: https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf?raw=true I need to get back to it, I was side-tracked by other projects and still have things to add to the doc. Philippe
May 17 2012
On Thu, May 17, 2012 at 7:00 PM, Marco Leise <Marco.Leise gmx.de> wrote:Your PDF is my reference manual on templates for quite a while. Thanks for putting it up!Glad to hear it :-) *Sigh* It's only 2-3 months old and is already lagging behind the current D spec. Things like is(T t = U!(Args), Args...) are now possible (I say otherwise in the appendix). The 'Args...' part is new. Also, UFCS. I should read it anew, really, and complete the missing parts. Do not hesitate to write an issue on GitHub if you see any mistakes.
May 17 2012
On 5/17/12 5:44 PM, Philippe Sigaud wrote:On Thu, May 17, 2012 at 7:00 PM, Marco Leise<Marco.Leise gmx.de> wrote:You may want to set up scripts that extract and compile code samples. AndreiYour PDF is my reference manual on templates for quite a while. Thanks for putting it up!Glad to hear it :-) *Sigh* It's only 2-3 months old and is already lagging behind the current D spec. Things like is(T t = U!(Args), Args...) are now possible (I say otherwise in the appendix). The 'Args...' part is new. Also, UFCS. I should read it anew, really, and complete the missing parts. Do not hesitate to write an issue on GitHub if you see any mistakes.
May 17 2012
On Fri, May 18, 2012 at 3:01 AM, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:I did, as per your advice, and a very good one at that (levelled dozens of bugs in my examples). About 200 samples get extracted from the doc, compiled and logged. They all passed for 2.058, I don't think 2.059 changed anything that could affect my samples. That was that extracting and compiling work that pushed me to write a parser generator, btw. The problem is not so much the code I show as what DMD now allows. For example, I offer a poor man's UFCS mixin in an example somewhere. But now that DMD integrates UFCS, there is no real need for this mixin. And so on.I should read it anew, really, and complete the missing parts. Do not hesitate to write an issue on GitHub if you see any mistakes.You may want to set up scripts that extract and compile code samples.
May 18 2012
"Mehrdad" <wfunction hotmail.com> wrote in message news:ynstshvzpaiusjyyoipo forum.dlang.org...On Friday, 11 May 2012 at 18:21:24 UTC, H. S. Teoh wrote:Geez, I think I need a vacation: My mind parsed that as a ternary operator expression. Only when it tried to apply semantics did reality snap into focus.Templates are stencils for generating code. There's nothing confusing about that."Stencils for generating code"? _This_??! :O
May 11 2012
On Fri, 11 May 2012 22:17:07 +0200, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:"Mehrdad" <wfunction hotmail.com> wrote in message news:ynstshvzpaiusjyyoipo forum.dlang.org...What did your mind do to the trigraph? Reminded me of the WTF operator: ??!??!On Friday, 11 May 2012 at 18:21:24 UTC, H. S. Teoh wrote:Geez, I think I need a vacation: My mind parsed that as a ternary operator expression. Only when it tried to apply semantics did reality snap into focus.Templates are stencils for generating code. There's nothing confusing about that."Stencils for generating code"? _This_??! :O
May 13 2012
On Friday, May 11, 2012 20:38:41 Mehrdad wrote:On Friday, 11 May 2012 at 18:21:24 UTC, H. S. Teoh wrote:Templates are a code-generation tool. They're "templates" for code. I really think that the majority of programmers don't quite get that, even when they've programmed in C++ quite a bit. Templates are frequently used for stuff like making it so that you can construct a container with a different element type than another container of the same type or letting functions take a variety of argument types. Actually actively trying to _generate_ code with them is getting into template metaprogramming land, which is very ugly in C++ and therefore very foreign to many (most?) programmers. D makes it _much_ easier and _much_ more sane, so we end up doing it all the time, and it's definitely something that many programmers coming to D are going to have to learn as opposed to it being completely intuitive. Much of it really isn't all that complicated or difficult IMHO, but it's definitely new and different for many programmers. - Jonathan M DavisTemplates are stencils for generating code. There's nothing confusing about that."Stencils for generating code"? _This_??! :O template hasMember(T, string name) { enum hasMember = __traits(hasMember, T, name); } Imagine a new user's confusion when seeing something like this. (Not sure I got it exactly right, but my point is there.)
May 11 2012
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message news:mailman.597.1336760569.24740.digitalmars-d puremagic.com...Templates are stencils for generating code. There's nothing confusing about that, unless you try to shoehorn them into a preconceived mental model of functions that take parameters and return something. Granted, proper tutorials need to be written and put in a prominent place so that newbies start on the right footing.https://semitwist.com/articles/article/view/template-primer-in-d Written. It'd just need to be linked from somewhere, or copied somewhere.
May 11 2012
On Fri, May 11, 2012 at 05:27:11PM -0400, Nick Sabalausky wrote:"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message news:mailman.597.1336760569.24740.digitalmars-d puremagic.com...[...] Ah, I remember that. Yes, we do need to link to this from somewhere prominent, so that newbies have a higher chance of reading it *before* they decide to dive off the 3-storey diving board into std.algorithm. T -- It's amazing how careful choice of punctuation can leave you hanging:Templates are stencils for generating code. There's nothing confusing about that, unless you try to shoehorn them into a preconceived mental model of functions that take parameters and return something. Granted, proper tutorials need to be written and put in a prominent place so that newbies start on the right footing.https://semitwist.com/articles/article/view/template-primer-in-d Written. It'd just need to be linked from somewhere, or copied somewhere.
May 11 2012
On Friday, May 11, 2012 11:22:13 H. S. Teoh wrote:Really? That's pretty much exactly what I would have expected, and it would really suck if it returned a bool. It's like what you get with find on std::map, only it's a pointer instead of an iterator. - Jonathan M Davis6. The 'in' operator returns a pointer (instead of a boolean). Which is fine, except that it's not what you'd expect in any languages other than C/C++. i.e. Non-intuitiveActually, that is a WAT even for somebody coming from C/C++.
May 11 2012
On Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:Again, try to see it from the perspective of a Python user, not a C++ user.Actually, that is a WAT even for somebody coming from C/C++.Really? That's pretty much exactly what I would have expected, and it would really suck if it returned a bool. It's like what you get with find on std::map, only it's a pointer instead of an iterator. - Jonathan M Davis
May 11 2012
On 11-05-2012 20:34, Mehrdad wrote:On Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:Speaking of which, 'in' on arrays......... *hint hint* -- - AlexAgain, try to see it from the perspective of a Python user, not a C++ user.Actually, that is a WAT even for somebody coming from C/C++.Really? That's pretty much exactly what I would have expected, and it would really suck if it returned a bool. It's like what you get with find on std::map, only it's a pointer instead of an iterator. - Jonathan M Davis
May 11 2012
On Friday, May 11, 2012 21:02:46 Alex Rønne Petersen wrote:On 11-05-2012 20:34, Mehrdad wrote:Except that it would break the generally expected algoritmic complexity of in, so it'll never happen ( O(n) for arrays, whereas the worst case that would be acceptable would be O(lg n) - e.g. what a binary tree could achieve). - Jonathan M DavisOn Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:Speaking of which, 'in' on arrays......... *hint hint*Again, try to see it from the perspective of a Python user, not a C++ user.Actually, that is a WAT even for somebody coming from C/C++.Really? That's pretty much exactly what I would have expected, and it would really suck if it returned a bool. It's like what you get with find on std::map, only it's a pointer instead of an iterator. - Jonathan M Davis
May 11 2012
On 11-05-2012 22:29, Jonathan M Davis wrote:On Friday, May 11, 2012 21:02:46 Alex Rønne Petersen wrote:'in' isn't useful in generic code. How it's defined (return type and parameter type) depends entirely on the type being operated on (who says it's an AA? Or a map-like type at all?), so it cannot be used generically in any sensible way. As such, maintaining any specific algorithmic complexity for it serves no purpose IMHO. -- - AlexOn 11-05-2012 20:34, Mehrdad wrote:Except that it would break the generally expected algoritmic complexity of in, so it'll never happen ( O(n) for arrays, whereas the worst case that would be acceptable would be O(lg n) - e.g. what a binary tree could achieve). - Jonathan M DavisOn Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:Speaking of which, 'in' on arrays......... *hint hint*Again, try to see it from the perspective of a Python user, not a C++ user.Actually, that is a WAT even for somebody coming from C/C++.Really? That's pretty much exactly what I would have expected, and it would really suck if it returned a bool. It's like what you get with find on std::map, only it's a pointer instead of an iterator. - Jonathan M Davis
May 11 2012
On Friday, 11 May 2012 at 20:35:53 UTC, Alex Rønne Petersen wrote:I think this has been discussed several times already, and you still haven't convinced any of us.Except that it would break the generally expected algoritmic complexity of in, so it'll never happen ( O(n) for arrays, whereas the worst case that would be acceptable would be O(lg n) - e.g. what a binary tree could achieve). - Jonathan M Davis'in' isn't useful in generic code. How it's defined (return type and parameter type) depends entirely on the type being operated on (who says it's an AA? Or a map-like type at all?), so it cannot be used generically in any sensible way. As such, maintaining any specific algorithmic complexity for it serves no purpose IMHO.
May 11 2012
On 11-05-2012 23:41, SomeDude wrote:On Friday, 11 May 2012 at 20:35:53 UTC, Alex Rønne Petersen wrote:Then you probably didn't read the replies to the other (sub-)thread about it. -- - AlexI think this has been discussed several times already, and you still haven't convinced any of us.Except that it would break the generally expected algoritmic complexity of in, so it'll never happen ( O(n) for arrays, whereas the worst case that would be acceptable would be O(lg n) - e.g. what a binary tree could achieve). - Jonathan M Davis'in' isn't useful in generic code. How it's defined (return type and parameter type) depends entirely on the type being operated on (who says it's an AA? Or a map-like type at all?), so it cannot be used generically in any sensible way. As such, maintaining any specific algorithmic complexity for it serves no purpose IMHO.
May 11 2012
On 05/11/2012 10:29 PM, Jonathan M Davis wrote:On Friday, May 11, 2012 21:02:46 Alex Rønne Petersen wrote:The main use case I see is replacing tedious if(foo == 'a' || foo == 'b' || foo == 'c' || foo == 'd') { ... } with if(foo in "abcd") { .... } And here the counter-argument cannot apply, because the operation is in O(1).On 11-05-2012 20:34, Mehrdad wrote:Except that it would break the generally expected algoritmic complexity of in, so it'll never happen ( O(n) for arrays, whereas the worst case that would be acceptable would be O(lg n) - e.g. what a binary tree could achieve). - Jonathan M DavisOn Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:Speaking of which, 'in' on arrays......... *hint hint*Again, try to see it from the perspective of a Python user, not a C++ user.Actually, that is a WAT even for somebody coming from C/C++.Really? That's pretty much exactly what I would have expected, and it would really suck if it returned a bool. It's like what you get with find on std::map, only it's a pointer instead of an iterator. - Jonathan M Davis
May 11 2012
On Sat, May 12, 2012 at 12:43:00AM +0200, Timon Gehr wrote:On 05/11/2012 10:29 PM, Jonathan M Davis wrote:[...]I always use this idiom: if ("abcd".canFind(foo)) { ... } T -- It only takes one twig to burn down a forest.Except that it would break the generally expected algoritmic complexity of in, so it'll never happen ( O(n) for arrays, whereas the worst case that would be acceptable would be O(lg n) - e.g. what a binary tree could achieve). - Jonathan M DavisThe main use case I see is replacing tedious if(foo == 'a' || foo == 'b' || foo == 'c' || foo == 'd') { ... } with if(foo in "abcd") { .... }
May 11 2012
On 5/11/12 5:43 PM, Timon Gehr wrote:On 05/11/2012 10:29 PM, Jonathan M Davis wrote:Yes, "in" for statically-sized arrays does make sense because the complexity if bound at compilation time. AndreiOn Friday, May 11, 2012 21:02:46 Alex Rønne Petersen wrote:The main use case I see is replacing tedious if(foo == 'a' || foo == 'b' || foo == 'c' || foo == 'd') { ... } with if(foo in "abcd") { .... } And here the counter-argument cannot apply, because the operation is in O(1).On 11-05-2012 20:34, Mehrdad wrote:Except that it would break the generally expected algoritmic complexity of in, so it'll never happen ( O(n) for arrays, whereas the worst case that would be acceptable would be O(lg n) - e.g. what a binary tree could achieve). - Jonathan M DavisOn Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:Speaking of which, 'in' on arrays......... *hint hint*Again, try to see it from the perspective of a Python user, not a C++ user.Actually, that is a WAT even for somebody coming from C/C++.Really? That's pretty much exactly what I would have expected, and it would really suck if it returned a bool. It's like what you get with find on std::map, only it's a pointer instead of an iterator. - Jonathan M Davis
May 11 2012
Yes, "in" for statically-sized arrays does make sense because the complexity if bound at compilation time. AndreiBut complexity is not the only problem with the proposed operator in for arrays. That operator does not represent the same operation as operator in for associative arrays. Looking up an element based on its key is different from looking it up based on its value. The following would be true for the proposed operator in for arrays: !(a in b) || *(a in b) == a And the following is true for operator in for associative arrays: !(a in b) || *(a in b) == b[a] The same operator should not be used for fundamentally different operations. I don't think using operator in to look up array elements based on their value is any better than using left shift operator to write to streams or using plus to concatenate strings. If operator in worked on arrays, it should actually take an index as the left operand and return a pointer to the element at that index if the index was less than array length and null otherwise. But that wouldn't be very useful.
May 11 2012
On 5/11/12 9:55 PM, jerro wrote:That's a good argument, but then you may think of the array as a small set, which would have the same semantics. AndreiYes, "in" for statically-sized arrays does make sense because the complexity if bound at compilation time. AndreiBut complexity is not the only problem with the proposed operator in for arrays. That operator does not represent the same operation as operator in for associative arrays.
May 11 2012
On 5/12/12, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:I always use this idiom: if ("abcd".canFind(foo)) { ... }As do I. Generally when I end up repeating myself all the time I write a helper function.. or if it's something more complicated than that - a template. Anyway hasn't this thread gone completely off tracks? Maybe Carlos (pspemu author) should try and elaborate exactly which issues he's faced, if he's reading this thread. You can't improve language/tools unless you know what's wrong with them. More real-world feedback about D would be great methinks.
May 11 2012
On Friday, May 11, 2012 20:34:07 Mehrdad wrote:On Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:Sure, what your used to has a huge effect on what you expect. But I've done very little with python whereas I've done a lot with C++, so my expectations are strongly influenced by C++ but aren't influenced by python at all. I didn't even know that python _had_ an in operator. But when you're dealing with people from a variety of backgrounds, you're invariably going to end up making choices that fit what one set of people expects but confounds another. - Jonathan M DavisAgain, try to see it from the perspective of a Python user, not a C++ user.Actually, that is a WAT even for somebody coming from C/C++.Really? That's pretty much exactly what I would have expected, and it would really suck if it returned a bool. It's like what you get with find on std::map, only it's a pointer instead of an iterator. - Jonathan M Davis
May 11 2012
On Friday, 11 May 2012 at 18:05:58 UTC, Mehrdad wrote:1. "templates": they seem to take in just about anything, and return just about anything. They can be pretty confusing, especially when you have to worry about overloading vs. specialization vs. constraints, or types vs. aliases...I really have to disagree on this. I programmed in C++ for awhile and templates were always a huge stumbling block for me. The syntax didn't sync up for me and they were extremely difficult to implement well, which made any generic programming I attempted feel half-hearted (IMO). When I started looking at D's templates, I was _afraid_ that it would be as much of a pain in the ass. After putting it off and shying away from it, I decided to dive in and discovered that they were significantly easier to work with ... and more importantly, it was nearly straightforward to implement them _well_. It's absolutely no problem specifying that data type with certain properties should use this function and everything else should use this other function. In C++, you have to learn complicated, arbitrary idioms such as SFINAE to get any serious work done at all ... and it looks like all of it was written in another language when you're done, making maintenance a nightmare. It's not surprising that entire C++ books are dedicated to teaching the absurd complexities of C++ templates. If anything, my experience with C++ templates hindered me.3. Ranges aren't confusing, but USING them certainly is. ... an array.There's definitely not enough info on how to get stuff done with ranges. I knew about assumeSorted and the fact that std.algorithm.sort returns a sorted range, but only because I carefully combed through the libraries looking for stuff like that. That said, the D way is actually very well designed once you discover it. Like Andrei said, the code clarifies its intentions. Hilariously, this style also makes the code look more magical. You want to say something is unique and, thus, can be legitimately made immutable? assumeUnique. Oh, you want to have a memoized version of funct? memoize!funct. I leave my friends wondering how D knew how to do all this stuff just by being "told" to. Magic API, that's how.
May 11 2012
On Friday, 11 May 2012 at 19:01:26 UTC, Chris Cain wrote:I really have to disagree on this. I programmed in C++ for awhile and templates were always a huge stumbling block for me. [...]Yes, D's templates are a great improvement over C++'s. I completely agree. Just pointing out why there are still a few things confusing about them, though.Hilariously, this style also makes the code look more magical.Yup, that's what attracted me to D when I learned about it. :)
May 11 2012
On Fri, May 11, 2012 at 09:01:25PM +0200, Chris Cain wrote: [...]I really have to disagree on this. I programmed in C++ for awhile and templates were always a huge stumbling block for me. The syntax didn't sync up for me and they were extremely difficult to implement well, which made any generic programming I attempted feel half-hearted (IMO).Yeah, I remember when I first read about template metaprogramming and expression templates and stuff, and I was all riled up about finally being able to write matrix expressions in an intuitive way and still have peak performance... until I actually sat down to code the thing. Let's just say I didn't get very far before I got completely lost in deep jungle that is C++ template syntax.When I started looking at D's templates, I was _afraid_ that it would be as much of a pain in the ass. After putting it off and shying away from it, I decided to dive in and discovered that they were significantly easier to work with ... and more importantly, it was nearly straightforward to implement them _well_. It's absolutely no problem specifying that data type with certain properties should use this function and everything else should use this other function. In C++, you have to learn complicated, arbitrary idioms such as SFINAE to get any serious work done at all ... and it looks like all of it was written in another language when you're done, making maintenance a nightmare.Yeah, one of the biggest problems with C++ template syntax is that it looks like an alien language. I remember going, "wait, you have to type *that* to achieve what can written as a simple loop in normal C++ code?!" I couldn't tell you how delighted I was when I saw D's much cleaner and clearer template syntax. I mean, it looks just like normal, non-template code! Gee, what a concept!It's not surprising that entire C++ books are dedicated to teaching the absurd complexities of C++ templates. If anything, my experience with C++ templates hindered me.Or the absurdity of C++ itself. What started out as C with classes started acquiring this feature and that feature until the whole thing is just a haphazard heap of misfitting self-contradictory pieces, which requires an enormous amount of essentially-arbitrary rules just to clarify something as simple as, for example, automatic type conversions. [...]There's definitely not enough info on how to get stuff done with ranges. I knew about assumeSorted and the fact that std.algorithm.sort returns a sorted range, but only because I carefully combed through the libraries looking for stuff like that.Again, helpful tutorials like Ali's book really need to be on the forefront of D. Newbies *need* to read that stuff before they get dunked into the deep end of the pool that is the current dlang.org docs.That said, the D way is actually very well designed once you discover it. Like Andrei said, the code clarifies its intentions. Hilariously, this style also makes the code look more magical. You want to say something is unique and, thus, can be legitimately made immutable? assumeUnique. Oh, you want to have a memoized version of funct? memoize!funct. I leave my friends wondering how D knew how to do all this stuff just by being "told" to. Magic API, that's how.+1. Sufficiently advanced programming language syntax is indistinguishible from magic. ;-) T -- "Computer Science is no more about computers than astronomy is about telescopes." -- E.W. Dijkstra
May 11 2012
On Friday, 11 May 2012 at 19:39:55 UTC, H. S. Teoh wrote:On Fri, May 11, 2012 at 09:01:25PM +0200, Chris Cain wrote:I remember reading from that book a bit on the ranges, and it all made wonderful sense when I did. That was something like a year ago, now I can't remember anything on it except it was good. Not having a good link to it does hinder your work quite a bit.There's definitely not enough info on how to get stuff done with ranges. I knew about assumeSorted and the fact that std.algorithm.sort returns a sorted range, but only because I carefully combed through the libraries looking for stuff like that.Again, helpful tutorials like Ali's book really need to be on the forefront of D. Newbies *need* to read that stuff before they get dunked into the deep end of the pool that is the current dlang.org docs.http://freefall.purrsia.com/ff300/fv00255.htm Safe to say documentation needs to be updated and added to. Here's a catch-22 we have here. We need those that know the system and language and compiler to work on it and give us a working set of tools, but we need those people to update and make the documentation for everyone that wants to use it or it will be a dead language. Hmmm... Unfortunately I don't have sufficient knowledge of all of D to make documentation for updated and newer changes to the language. :(That said, the D way is actually very well designed once you discover it. Like Andrei said, the code clarifies its intentions. Hilariously, this style also makes the code look more magical. You want to say something is unique and, thus, can be legitimately made immutable? assumeUnique. Oh, you want to have a memoized version of funct? memoize!funct. I leave my friends wondering how D knew how to do all this stuff just by being "told" to. Magic API, that's how.+1. Sufficiently advanced programming language syntax is indistinguishible from magic. ;-)
May 11 2012
On Friday, May 11, 2012 22:01:33 Era Scarecrow wrote:I remember reading from that book a bit on the ranges, and it all made wonderful sense when I did. That was something like a year ago, now I can't remember anything on it except it was good. Not having a good link to it does hinder your work quite a bit.http://ddili.org/ders/d.en/ranges.html - Jonathan M Davis
May 11 2012
On 5/11/2012 12:40 PM, H. S. Teoh wrote:Yeah, one of the biggest problems with C++ template syntax is that it looks like an alien language. I remember going, "wait, you have to type *that* to achieve what can written as a simple loop in normal C++ code?!" I couldn't tell you how delighted I was when I saw D's much cleaner and clearer template syntax. I mean, it looks just like normal, non-template code! Gee, what a concept!Back when Andrei was writing TDPL, I suggested that he avoid using the word 'template' completely - to simply include type parameters as if they were completely natural. I think this was a very successful approach. I got the idea after listening to a friend of mine who taught remedial algebra to college students. She said that peoples' brains freeze up when they see "x" in an equation. If she wrote: x + 3 = 5 on the board and asked people to "solve for x", they would fail completely. But, if she wrote: ( ) + 3 = 5 and asked them to "fill in the circle with the number that makes it work", they all went "of course, it's 2!" C++ has produced a "gee, templates are hard" mentality, and consequently many people just shut down when they see the word "template".
May 11 2012
On Friday, 11 May 2012 at 20:24:40 UTC, Walter Bright wrote:C++ has produced a "gee, templates are hard" mentality, and consequently many people just shut down when they see the word "template".Same thing happens to me when I see a transistor symbol. :P
May 11 2012
On 5/11/12, Walter Bright <newshound2 digitalmars.com> wrote:If she wrote: x + 3 = 5 on the board and asked people to "solve for x", they would fail completely.Well that's funny, here in europe we've learned to use 'x' since junior school so that's more intuitive for us. :)
May 11 2012
On 12/05/12 01:01, Andrej Mitrovic wrote:Well that's funny, here in europe we've learned to use 'x' since junior school so that's more intuitive for us. :)Dangerous to speak for a whole group, I've met plenty of Europeans terrified of mathematical notation. Some people -- maybe even most people -- automatically freeze up when confronted with a notation that they associate with difficult stuff, or stuff that was too hard (or humiliating) for them at some point in the past. Maths-phobia is very common in a lot of people who are able to solve the exact same problems if they're not presented in "maths-y" clothing. By contrast look at how some mathematically gifted people freeze up in social situations! I saw a violin-playing friend in school freeze up once when she was asked to sightread a short piece with chords in it. She was adamant that she wasn't skilled enough to play chords properly. Yet a few seconds' calm examination of the notes on the page would have revealed that all she had to do was draw the bow across a pair of open strings, which is something that just about every violinist, even a beginner, does every day without even thinking about it. She couldn't see it, because "Oh my God!! Chords!!" got in the way of even trying to consider the problem.
May 11 2012
On 5/12/12 3:24 AM, Walter Bright wrote:x + 3 = 5 on the board and asked people to "solve for x", they would fail completely. But, if she wrote: ( ) + 3 = 5 and asked them to "fill in the circle with the number that makes it work", they all went "of course, it's 2!"When I read "solve *for* x" I don't understand it. What do you mean "for x"? Like doing a favor to x? In Spanish we say "hallar el valor de x" which means "find the value of x"... I'm not a native English speaker so I don't know if "solve for x" sounds natural if you haven't done ecuations before... but for me it doesn't. :-P
May 11 2012
On 5/11/2012 8:51 PM, Ary Manzana wrote:On 5/12/12 3:24 AM, Walter Bright wrote:It's normal English mathematical jargon.x + 3 = 5 on the board and asked people to "solve for x", they would fail completely. But, if she wrote: ( ) + 3 = 5 and asked them to "fill in the circle with the number that makes it work", they all went "of course, it's 2!"When I read "solve *for* x" I don't understand it. What do you mean "for x"? Like doing a favor to x? In Spanish we say "hallar el valor de x" which means "find the value of x"... I'm not a native English speaker so I don't know if "solve for x" sounds natural if you haven't done ecuations before... but for me it doesn't. :-P
May 11 2012
"Ary Manzana" <ary esperanto.org.ar> wrote in message news:jokmnh$17fl$4 digitalmars.com...When I read "solve *for* x" I don't understand it. What do you mean "for x"? Like doing a favor to x? In Spanish we say "hallar el valor de x" which means "find the value of x"... I'm not a native English speaker so I don't know if "solve for x" sounds natural if you haven't done ecuations before... but for me it doesn't. :-PYou're right, it doesn't. "Find the value of x" would be *much* better. But that's just for beginners. Once they learn how to "Find the value of x", then it should be trivial to learn that "Solve for x" is "Another way to say...the same thing you're already doing." Along similar lines, my 4th grade teacher used to assign homework and then say "But that's for tomorrow". So that evening I would do some *other* homework (if any) because that obviously *wasn't today's fucking homework*, right? Said *said* it was *tomorrow's*. Then the next day, she would bitch and moan that I didn't do the homework she had *said* was "for tomorrow". Her excuse: "Yea, it was 'Due for tomorrow'." "DUE FOR TOMORROW"?!? That's NOT FUCKING ENGLISH! There IS NO "due for"!! Period! It's either "due {time and/or place}" or it's nothing! "Due" doesn't take any damn preposition, it takes an *object*! "Due for" is grammatical fucking gibberish! There's no such damn thing! So why would anyone ever say "for tomorrow" when they could just as easily say what they fucking mean: "due tomorrow". It *would* have been somewhat excusable except...She was a native English speaker! Stupid fucking bitch.
May 11 2012
On Saturday, 12 May 2012 at 05:16:33 UTC, Nick Sabalausky wrote:Stupid fucking bitch.Wow, you seem to love her. :D Cool down, man, it's over. :)
May 12 2012
On 5/12/12 12:14 PM, Nick Sabalausky wrote:"DUE FOR TOMORROW"?!? That's NOT FUCKING ENGLISH! There IS NO "due for"!! Period!Hilarious :-)
May 12 2012
On 5/12/2012 1:13 AM, Ary Manzana wrote:On 5/12/12 12:14 PM, Nick Sabalausky wrote:Due-be-due-be-due! -- Sinatra"DUE FOR TOMORROW"?!? That's NOT FUCKING ENGLISH! There IS NO "due for"!! Period!Hilarious :-)
May 12 2012
What started out as C with classes started acquiring this feature and that feature until the whole thing is just a haphazard heap of misfitting self-contradictory pieces, which requires an enormous amount of essentially-arbitrary rules just to clarify something as simple as, for example, automatic type conversions.Partially, this also can be told about D, too. It started as a cleaner C++ (I think) and grew up a bit complicated. Before arguing the contrary, please remember that C++ looks not complicated to Stroustrup. Maybe simply addressing the most bitter drawbacks and inconsistencies of C++ (and when I say that, I say notably syntax stupidities, *then* conceptual stupidities) was enough for, let's say, D_v1. Then, more, for D_v2. Maybe trying to address too much at once? My feeling (I tried to port and work something in D) is that it is a good language. But a complicate one and the learning time tends to be limited today. C caught in the first place for its simplicity. Java, too ("hey, no pointers!"). Annotations and other hell were added later, complicated beast, but *gradually*. At the beginning, it was not. D does not have that gradualism in growing complicated. Not for its developers, but for its (mass) users.
May 11 2012
On Friday, 11 May 2012 at 21:55:37 UTC, akaz wrote:There is no arguing that D is a big and complex language. If it wasn't, there wouldn't be huge discussions here about interactions between features. It's complex because there is so many new concepts to assimilate for newcomers from other languages. The former Java programmers will have to face advanced concepts coming from C++, the former C++ programmers will learn to master concepts coming from Python and functional languages, and former Python programmers will have to face lots of hurdles associated to static languages. So basically, everyone has a different learning curve. I believe it takes no less than a year of full time programming to become a proficient C++ programmer (by proficient, I mean a programmer who doesn't fall in all the traps that the language offers, and therefore spends more time coding than debugging). I can't tell for D, I believe D is a net gain for C++ programmers, but still a big investment.What started out as C with classes started acquiring this feature and that feature until the whole thing is just a haphazard heap of misfitting self-contradictory pieces, which requires an enormous amount of essentially-arbitrary rules just to clarify something as simple as, for example, automatic type conversions.Partially, this also can be told about D, too. It started as a cleaner C++ (I think) and grew up a bit complicated. Before arguing the contrary, please remember that C++ looks not complicated to Stroustrup. Maybe simply addressing the most bitter drawbacks and inconsistencies of C++ (and when I say that, I say notably syntax stupidities, *then* conceptual stupidities) was enough for, let's say, D_v1. Then, more, for D_v2. Maybe trying to address too much at once? My feeling (I tried to port and work something in D) is that it is a good language. But a complicate one and the learning time tends to be limited today. C caught in the first place for its simplicity. Java, too ("hey, no pointers!"). Annotations and other hell were added a complicated beast, but *gradually*. At the beginning, it was not. D does not have that gradualism in growing complicated. Not for its developers, but for its (mass) users.
May 11 2012
On 5/11/2012 3:25 PM, SomeDude wrote:I believe it takes no less than a year of full time programming to become a proficient C++ programmer (by proficient, I mean a programmer who doesn't fall in all the traps that the language offers, and therefore spends more time coding than debugging).Eh, I'd put it much longer than that. Or maybe I just have a different view of proficient!
May 11 2012
On Saturday, 12 May 2012 at 04:19:57 UTC, Walter Bright wrote:On 5/11/2012 3:25 PM, SomeDude wrote:Yeah, I didn't want to start a discussion on how much time it takes to make a good C++ programmer because I guess everyone has a different idea on this (definition of a "good" programmer, etc), but I agree. :)I believe it takes no less than a year of full time programming to become a proficient C++ programmer (by proficient, I mean a programmer who doesn't fall in all the traps that the language offers, and therefore spends more time coding than debugging).Eh, I'd put it much longer than that. Or maybe I just have a different view of proficient!
May 11 2012
On Fri, 11 May 2012 13:47:05 -0400, Alex R=C3=B8nne Petersen = <xtzgzorex gmail.com> wrote:On 11-05-2012 19:39, Paulo Pinto wrote:I can attest that on certain types of projects (i.e. template heavy), D'= s = lightning fast compilation time goes out the window. It has improved = greatly, but there are still some improvements that can be made. For instance, dcollections, which is about 10kloc takes 17 seconds to = compile all the unit tests. It used to be well over a minute, till walt= er = changed a linear lookup to a hash lookup on the symbol table. There's a= n = outstanding issue which is similar still in bugzilla: http://d.puremagic.com/issues/show_bug.cgi?id=3D4900 -SteveThe author of a D based PSP emulator just rewrote https://github.com/soywiz/cspspemu The reasons are listed here, https://github.com/soywiz/cspspemu#created-after-4-tries -- PauloComplicated language structure? Long compilation times?
May 11 2012
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message news:op.wd5o86s3eav7ka steves-laptop... On Fri, 11 May 2012 13:47:05 -0400, Alex Rønne Petersen <xtzgzorex gmail.com> wrote:Meh, that's still nothing compared to C++. The sample games included with Marmalade and the Marm-based IwGame engine take *serveral* minutes to compile - and those are just sample programs! Template-heavy projects don't throw D's lightning fast compilation times out the window, it just makes them less lightning-like. It's still an order of magnature faster than equivalent, or even merely similar, C++.Complicated language structure? Long compilation times?I can attest that on certain types of projects (i.e. template heavy), D's lightning fast compilation time goes out the window. It has improved greatly, but there are still some improvements that can be made. For instance, dcollections, which is about 10kloc takes 17 seconds to compile all the unit tests. It used to be well over a minute, till walter changed a linear lookup to a hash lookup on the symbol table. There's an outstanding issue which is similar still in bugzilla:
May 11 2012
On Friday, 11 May 2012 at 21:46:55 UTC, Nick Sabalausky wrote:"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message news:op.wd5o86s3eav7ka steves-laptop... On Fri, 11 May 2012 13:47:05 -0400, Alex Rønne Petersen <xtzgzorex gmail.com> wrote:I remember g++ taking dozens of minutes on a SINGLE compilation unit on FreeFEM++, a very heavily templated project. Large C++ projects with lots of templates can take several hours to compile. So one has to be very careful with libraries like Boost on large projects, compilation times can explode.Meh, that's still nothing compared to C++. The sample games included with Marmalade and the Marm-based IwGame engine take *serveral* minutes to compile - and those are just sample programs! Template-heavy projects don't throw D's lightning fast compilation times out the window, it just makes them less lightning-like. It's still an order of magnature faster than equivalent, or even merely similar, C++.Complicated language structure? Long compilation times?I can attest that on certain types of projects (i.e. template heavy), D's lightning fast compilation time goes out the window. It has improved greatly, but there are still some improvements that can be made. For instance, dcollections, which is about 10kloc takes 17 seconds to compile all the unit tests. It used to be well over a minute, till walter changed a linear lookup to a hash lookup on the symbol table. There's an outstanding issue which is similar still in bugzilla:
May 11 2012
"SomeDude" <lovelydear mailmetrash.com> wrote in message news:bgrwgspedjiajgoesxgq forum.dlang.org...I remember g++ taking dozens of minutes on a SINGLE compilation unit on FreeFEM++, a very heavily templated project. Large C++ projects with lots of templates can take several hours to compile. So one has to be very careful with libraries like Boost on large projects, compilation times can explode.Yea, it's like compiling GCC. You may as well go buy your groceries, run a few other errands, and go out for dinner. And I'm not even eggagerating. It's rediculous. (Maybe it's gotten better since I last tried though, but even so, it'd still tale a LOOOONG fucking time) And even that's not even the worst. Mainstream videogames have been known to frequently take at least a full day. I'm not certain, but I seem to remember hearing about ones that took "days" - plural. And then that leads to "incredibuild", build farms, blah, blah, blah, it's all a big fucking mess. The longest I've ever had to wait for a D program to comple (DDMD) was about 1.5 to 2 minutes - and that was on a 32-bit single-core.
May 11 2012
Well, in most the big C++ projects I was involved in the past, a full clean build would take at least an hour. Am 12.05.2012 00:34, schrieb SomeDude:On Friday, 11 May 2012 at 21:46:55 UTC, Nick Sabalausky wrote:"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message news:op.wd5o86s3eav7ka steves-laptop... On Fri, 11 May 2012 13:47:05 -0400, Alex Rønne Petersen <xtzgzorex gmail.com> wrote:I remember g++ taking dozens of minutes on a SINGLE compilation unit on FreeFEM++, a very heavily templated project. Large C++ projects with lots of templates can take several hours to compile. So one has to be very careful with libraries like Boost on large projects, compilation times can explode.Meh, that's still nothing compared to C++. The sample games included with Marmalade and the Marm-based IwGame engine take *serveral* minutes to compile - and those are just sample programs! Template-heavy projects don't throw D's lightning fast compilation times out the window, it just makes them less lightning-like. It's still an order of magnature faster than equivalent, or even merely similar, C++.Complicated language structure? Long compilation times?I can attest that on certain types of projects (i.e. template heavy), D's lightning fast compilation time goes out the window. It has improved greatly, but there are still some improvements that can be made. For instance, dcollections, which is about 10kloc takes 17 seconds to compile all the unit tests. It used to be well over a minute, till walter changed a linear lookup to a hash lookup on the symbol table. There's an outstanding issue which is similar still in bugzilla:
May 11 2012
awkward is which, backwards read things makes posting top but, ass an be to Not. "Paulo Pinto" <pjmlp progtools.org> wrote in message news:joku8g$1kd9$1 digitalmars.com...Well, in most the big C++ projects I was involved in the past, a full clean build would take at least an hour. Am 12.05.2012 00:34, schrieb SomeDude:On Friday, 11 May 2012 at 21:46:55 UTC, Nick Sabalausky wrote:"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message news:op.wd5o86s3eav7ka steves-laptop... On Fri, 11 May 2012 13:47:05 -0400, Alex Rønne Petersen <xtzgzorex gmail.com> wrote:I remember g++ taking dozens of minutes on a SINGLE compilation unit on FreeFEM++, a very heavily templated project. Large C++ projects with lots of templates can take several hours to compile. So one has to be very careful with libraries like Boost on large projects, compilation times can explode.Meh, that's still nothing compared to C++. The sample games included with Marmalade and the Marm-based IwGame engine take *serveral* minutes to compile - and those are just sample programs! Template-heavy projects don't throw D's lightning fast compilation times out the window, it just makes them less lightning-like. It's still an order of magnature faster than equivalent, or even merely similar, C++.Complicated language structure? Long compilation times?I can attest that on certain types of projects (i.e. template heavy), D's lightning fast compilation time goes out the window. It has improved greatly, but there are still some improvements that can be made. For instance, dcollections, which is about 10kloc takes 17 seconds to compile all the unit tests. It used to be well over a minute, till walter changed a linear lookup to a hash lookup on the symbol table. There's an outstanding issue which is similar still in bugzilla:
May 11 2012
On 05/11/2012 07:39 PM, Paulo Pinto wrote:The author of a D based PSP emulator just rewrote https://github.com/soywiz/cspspemu The reasons are listed here, https://github.com/soywiz/cspspemu#created-after-4-tries -- PauloWell, those are not reasons for me.The lack of a good IDE,Properties of a 'good IDE', as I see it: some essential properties: - starts up instantaneously - uses the screen space efficiently - supports editing text efficiently - accepts keyboard input as given by the user. - reasonable support for auto-indentation - supports searching the code for some text efficiently - keeps all code _readable_, especially the one that has been written recently - pattern recognition based code completion - ... by default! some 'nice to have' properties: - code analysis based code completion - navigate-to-declaration - for those languages that require it: automatic generation of boilerplate. - integrated debugger - useful refactoring tools - visualization of compilation errors (but please don't nag me) - actual support for detecting semantic errors as they happen (extremely difficult to do properly) - any other argument that is commonly used to advertise IDEs - ... _responsive_ on halfway recent hardware! some anti-features: - splash screen - cannot run code if there is no 'project/solution file' - sometimes messes up those files - build fails - restart IDE - build works - fancy GUI - requires pointing device - accidental hit of obscure keyboard combination ... => permanent, extremely annoying configuration change => no way to tell what happened => no undo operation - termination of the debugged program kills the output console As long as IDEs fail to satisfy every single point in the 'essential' category and strive to have all of the stated anti-features, they don't have much value for me anyway.the complicated structure of the D language,Cannot really comment on that, I think getting work done in D is simple, and with DMD, just slightly harder than that.the horrible compilation times,wat? The so-fast-I-could-not-grab-a-coffee-during-compilation kind of horrible? Otherwise he might have hit a bug there.caused that it taked too much time for everything, and made it impossible to refactoring the code without days or weeks of work.I'd have to know what kind of refactorings he carried out to be able to comment on this.
May 11 2012
On Saturday, 12 May 2012 at 00:00:20 UTC, Timon Gehr wrote:My work project takes about 8 seconds to compile and link in my normal build if there's RAM available, and can be much longer if there isn't. Since the compile takes upwards of 512 MB peak, having enough memory for the fast build doesn't happen many times. The build also takes well over a full minute if I use -O. The emulator might be using -O and getting brutally slow, or being run on a box without a billion terabytes of RAM. ...or perhaps I just think ~10 second build times are slow because I've been spoiled by all the other D I do. lolthe horrible compilation times,wat? The so-fast-I-could-not-grab-a-coffee-during-compilation kind of horrible? Otherwise he might have hit a bug there.
May 11 2012
Your 'nice to have' features are for my type of work 'must have' features, otherwise I could as well just use Notepad++. Having used GUI environments since the early MS-DOS days, I don't have any issue with my mouse friend. :) -- Paulo Am 12.05.2012 02:00, schrieb Timon Gehr:On 05/11/2012 07:39 PM, Paulo Pinto wrote:The author of a D based PSP emulator just rewrote https://github.com/soywiz/cspspemu The reasons are listed here, https://github.com/soywiz/cspspemu#created-after-4-tries -- PauloWell, those are not reasons for me. > The lack of a good IDE, Properties of a 'good IDE', as I see it: some essential properties: - starts up instantaneously - uses the screen space efficiently - supports editing text efficiently - accepts keyboard input as given by the user. - reasonable support for auto-indentation - supports searching the code for some text efficiently - keeps all code _readable_, especially the one that has been written recently - pattern recognition based code completion - ... by default! some 'nice to have' properties: - code analysis based code completion - navigate-to-declaration - for those languages that require it: automatic generation of boilerplate. - integrated debugger - useful refactoring tools - visualization of compilation errors (but please don't nag me) - actual support for detecting semantic errors as they happen (extremely difficult to do properly) - any other argument that is commonly used to advertise IDEs - ... _responsive_ on halfway recent hardware! some anti-features: - splash screen - cannot run code if there is no 'project/solution file' - sometimes messes up those files - build fails - restart IDE - build works - fancy GUI - requires pointing device - accidental hit of obscure keyboard combination ... => permanent, extremely annoying configuration change => no way to tell what happened => no undo operation - termination of the debugged program kills the output console As long as IDEs fail to satisfy every single point in the 'essential' category and strive to have all of the stated anti-features, they don't have much value for me anyway. > the complicated structure of the D language, Cannot really comment on that, I think getting work done in D is simple, and with DMD, just slightly harder than that. > the horrible compilation times, wat? The so-fast-I-could-not-grab-a-coffee-during-compilation kind of horrible? Otherwise he might have hit a bug there. > caused that it taked too much time for everything, and made it > impossible to refactoring the code without days or weeks of work. I'd have to know what kind of refactorings he carried out to be able to comment on this.
May 11 2012
On Sat, 12 May 2012 08:05:26 +0200, Paulo Pinto <pjmlp progtools.org> = wrote: =CB=99=CA=87sod-do=CA=87 =CA=87ou op =C7=9Ds=C9=90=C7=9Dl=D4=80 =CB=99u=CA=8Dop-=C7=9Dp=C4=B1sdn s=C4=B1 =CA=87sod =C9=B9no=CA=8E =C7=9D= =CA=9E=C4=B1l s=C9=AF=C7=9D=C7=9Ds =CA=87=C4=B1 =CA=87nq 'no=CA=8E =C9=AF= =C9=B9=C9=90l=C9=90 o=CA=87 =CA=87oNYour 'nice to have' features are for my type of work 'must have' features, otherwise I could as well just use Notepad++. Having used GUI environments since the early MS-DOS days, I don't have any issue with my mouse friend. :) -- Paulo Am 12.05.2012 02:00, schrieb Timon Gehr:On 05/11/2012 07:39 PM, Paulo Pinto wrote:The author of a D based PSP emulator just rewrote https://github.com/soywiz/cspspemu The reasons are listed here, https://github.com/soywiz/cspspemu#created-after-4-tries -- PauloWell, those are not reasons for me. > The lack of a good IDE, Properties of a 'good IDE', as I see it: some essential properties: - starts up instantaneously - uses the screen space efficiently - supports editing text efficiently - accepts keyboard input as given by the user. - reasonable support for auto-indentation - supports searching the code for some text efficiently - keeps all code _readable_, especially the one that has been written=recently - pattern recognition based code completion - ... by default! some 'nice to have' properties: - code analysis based code completion - navigate-to-declaration - for those languages that require it: automatic generation of =elyboilerplate. - integrated debugger - useful refactoring tools - visualization of compilation errors (but please don't nag me) - actual support for detecting semantic errors as they happen (extrem=difficult to do properly) - any other argument that is commonly used to advertise IDEs - ... _responsive_ on halfway recent hardware! some anti-features: - splash screen - cannot run code if there is no 'project/solution file' - sometimes messes up those files - build fails - restart IDE - build works - fancy GUI - requires pointing device - accidental hit of obscure keyboard combination ... =3D> permanent, extremely annoying configuration change =3D> no way to tell what happened =3D> no undo operation - termination of the debugged program kills the output console As long as IDEs fail to satisfy every single point in the 'essential'='tcategory and strive to have all of the stated anti-features, they don=le,have much value for me anyway. > the complicated structure of the D language, Cannot really comment on that, I think getting work done in D is simp=and with DMD, just slightly harder than that. > the horrible compilation times, wat? The so-fast-I-could-not-grab-a-coffee-during-compilation kind of=tohorrible? Otherwise he might have hit a bug there. > caused that it taked too much time for everything, and made it > impossible to refactoring the code without days or weeks of work. I'd have to know what kind of refactorings he carried out to be able =comment on this.
May 13 2012
"Timon Gehr" <timon.gehr gmx.ch> wrote in message news:jok96k$l7t$1 digitalmars.com...Properties of a 'good IDE', as I see it: some essential properties: - starts up instantaneously - uses the screen space efficiently - supports editing text efficiently - accepts keyboard input as given by the user. - reasonable support for auto-indentation - supports searching the code for some text efficiently - keeps all code _readable_, especially the one that has been written recently - pattern recognition based code completion - ... by default! some 'nice to have' properties: - code analysis based code completion - navigate-to-declaration - for those languages that require it: automatic generation of boilerplate. - integrated debugger - useful refactoring tools - visualization of compilation errors (but please don't nag me) - actual support for detecting semantic errors as they happen (extremely difficult to do properly) - any other argument that is commonly used to advertise IDEs - ... _responsive_ on halfway recent hardware! some anti-features: - splash screen - cannot run code if there is no 'project/solution file' - sometimes messes up those files - build fails - restart IDE - build works - fancy GUI - requires pointing device - accidental hit of obscure keyboard combination ... => permanent, extremely annoying configuration change => no way to tell what happened => no undo operation - termination of the debugged program kills the output console As long as IDEs fail to satisfy every single point in the 'essential' category and strive to have all of the stated anti-features, they don't have much value for me anyway.Hear hear! Although I'd swap the positions of "pattern recognition based code completion" and "_responsive_ on halfway recent hardware!". In fact, I'd put "responsive" at the top of the "essential" list.
May 11 2012
On 05/12/2012 08:04 AM, Nick Sabalausky wrote:"Timon Gehr"<timon.gehr gmx.ch> wrote in message news:jok96k$l7t$1 digitalmars.com...The - ... points were meant to apply to all the other points in their group. Eg. navigate-to-declaration is extremely annoying if after the click, there is a pause of multiple seconds.Properties of a 'good IDE', as I see it: some essential properties: - starts up instantaneously - uses the screen space efficiently - supports editing text efficiently - accepts keyboard input as given by the user. - reasonable support for auto-indentation - supports searching the code for some text efficiently - keeps all code _readable_, especially the one that has been written recently - pattern recognition based code completion - ... by default! some 'nice to have' properties: - code analysis based code completion - navigate-to-declaration - for those languages that require it: automatic generation of boilerplate. - integrated debugger - useful refactoring tools - visualization of compilation errors (but please don't nag me) - actual support for detecting semantic errors as they happen (extremely difficult to do properly) - any other argument that is commonly used to advertise IDEs - ... _responsive_ on halfway recent hardware! some anti-features: - splash screen - cannot run code if there is no 'project/solution file' - sometimes messes up those files - build fails - restart IDE - build works - fancy GUI - requires pointing device - accidental hit of obscure keyboard combination ... => permanent, extremely annoying configuration change => no way to tell what happened => no undo operation - termination of the debugged program kills the output console As long as IDEs fail to satisfy every single point in the 'essential' category and strive to have all of the stated anti-features, they don't have much value for me anyway.Hear hear! Although I'd swap the positions of "pattern recognition based code completion" and "_responsive_ on halfway recent hardware!".In fact, I'd put "responsive" at the top of the "essential" list.I have to agree. It could be argued that responsiveness was included in 'starts up instantaneously'/'supports editing text efficiently'.
May 12 2012
On Saturday, May 12, 2012 02:00:19 Timon Gehr wrote:On 05/11/2012 07:39 PM, Paulo Pinto wrote:I do have to say that I find it somewhat funny that this is your set of requirements for an IDEA and yet "integrated debugger" is in the "some 'nice to have' features" section. Doesn't an IDE _have_ to have an integrated debugger or it's only a code editor (since it lacks the whole integrated part of Integrated Development Environment). - Jonathan M DavisThe author of a D based PSP emulator just rewrote https://github.com/soywiz/cspspemu The reasons are listed here, https://github.com/soywiz/cspspemu#created-after-4-tries -- PauloWell, those are not reasons for me. > The lack of a good IDE, Properties of a 'good IDE', as I see it: some essential properties: - starts up instantaneously - uses the screen space efficiently - supports editing text efficiently - accepts keyboard input as given by the user. - reasonable support for auto-indentation - supports searching the code for some text efficiently - keeps all code _readable_, especially the one that has been written recently - pattern recognition based code completion - ... by default! some 'nice to have' properties: - code analysis based code completion - navigate-to-declaration - for those languages that require it: automatic generation of boilerplate. - integrated debugger - useful refactoring tools - visualization of compilation errors (but please don't nag me) - actual support for detecting semantic errors as they happen (extremely difficult to do properly) - any other argument that is commonly used to advertise IDEs - ... _responsive_ on halfway recent hardware! some anti-features: - splash screen - cannot run code if there is no 'project/solution file' - sometimes messes up those files - build fails - restart IDE - build works - fancy GUI - requires pointing device - accidental hit of obscure keyboard combination ... => permanent, extremely annoying configuration change => no way to tell what happened => no undo operation - termination of the debugged program kills the output console As long as IDEs fail to satisfy every single point in the 'essential' category and strive to have all of the stated anti-features, they don't have much value for me anyway. > the complicated structure of the D language, Cannot really comment on that, I think getting work done in D is simple, and with DMD, just slightly harder than that. > the horrible compilation times, wat? The so-fast-I-could-not-grab-a-coffee-during-compilation kind of horrible? Otherwise he might have hit a bug there. > caused that it taked too much time for everything, and made it > impossible to refactoring the code without days or weeks of work. I'd have to know what kind of refactorings he carried out to be able to comment on this.
May 11 2012
On Saturday, 12 May 2012 at 06:19:37 UTC, Jonathan M Davis wrote:I do have to say that I find it somewhat funny that this is your set of requirements for an IDEA and yet "integrated debugger" is in the "some 'nice to have' features" section. Doesn't an IDE _have_ to have an integrated debugger or it's only a code editor (since it lacks the whole integrated part of Integrated Development Environment). - Jonathan M DavisIndeed, and Timon forgot the best feature of IDEs for bytecode compilers imho: they compile in the background, so that errors are detected while you type. There is no annoying "write-correct" cycle as compile-time errors are shown in real time. That's a *huge* productivity boost. It's actually better than with interpreted or scripted languages, because once you've finished writing code, it will run ! Basically, with modern IDEs, the productivity with languages like Background compiling shouldn't be too hard to implement for an editor, I guess: run the compiler in background on the current module every other second (or only when a set of simple syntaxic conditions like parentheses/accolades matching are matched, conditions which can easily be checked by the editor itself), and display the error messages in semi real time on screen where they appear.
May 11 2012
On Saturday, 12 May 2012 at 06:53:34 UTC, SomeDude wrote:Indeed, and Timon forgot the best feature of IDEs for bytecode compilers imho: they compile in the background, so that errors are detected while you type. There is no annoying "write-correct" cycle as compile-time errors are shown in real time. That's a *huge* productivity boost. It's actually better than with interpreted or scripted languages, because once you've finished writing code, it will run ! Basically, with comparable to Python.Background compiling shouldn't be too hard to implement for an editor, I guess: run the compiler in background on the current module every other second (or only when a set of simple syntaxic conditions like parentheses/accolades matching are matched, conditions which can easily be checked by the editor itself), and display the error messages in semi real time on screen where they appear.Perhaps what could make that better is not only compiling as you type, but if you have unittests already written it will run and test against those giving you feedback instantly on what parts fail.
May 12 2012
Am 12.05.2012 08:53, schrieb SomeDude:On Saturday, 12 May 2012 at 06:19:37 UTC, Jonathan M Davis wrote:Even Eclipse and VS do this, to certain extent, for C and C++. Nowadays, my use of VIM and Emacs is relegated to quick edit of configuration files and small scripts. -- PauloI do have to say that I find it somewhat funny that this is your set of requirements for an IDEA and yet "integrated debugger" is in the "some 'nice to have' features" section. Doesn't an IDE _have_ to have an integrated debugger or it's only a code editor (since it lacks the whole integrated part of Integrated Development Environment). - Jonathan M DavisIndeed, and Timon forgot the best feature of IDEs for bytecode compilers imho: they compile in the background, so that errors are detected while you type. There is no annoying "write-correct" cycle as compile-time errors are shown in real time. That's a *huge* productivity boost. It's actually better than with interpreted or scripted languages, because once you've finished writing code, it will run ! Basically, with to Python. Background compiling shouldn't be too hard to implement for an editor, I guess: run the compiler in background on the current module every other second (or only when a set of simple syntaxic conditions like parentheses/accolades matching are matched, conditions which can easily be checked by the editor itself), and display the error messages in semi real time on screen where they appear.
May 12 2012
On 05/12/2012 08:53 AM, SomeDude wrote:On Saturday, 12 May 2012 at 06:19:37 UTC, Jonathan M Davis wrote:Probably I didn't express myself properly, but this was meant to be included at the ' - visualization of compilation errors (but please don't nag me)' point.I do have to say that I find it somewhat funny that this is your set of requirements for an IDEA and yet "integrated debugger" is in the "some 'nice to have' features" section. Doesn't an IDE _have_ to have an integrated debugger or it's only a code editor (since it lacks the whole integrated part of Integrated Development Environment). - Jonathan M DavisIndeed, and Timon forgot the best feature of IDEs for bytecode compilers imho: they compile in the background, so that errors are detected while you type.There is no annoying "write-correct" cycle as compile-time errors are shown in real time. That's a *huge* productivity boost.* When I fail to write code that actually compiles, a few seconds of additional waiting time seem to be deserved. (it might be a longer time for eg. C++ though, so there this argument might not apply). If a programmer usually cannot write code that compiles, what are the chances that his code will be correct when it is run? * The write-correct cycle is still there (actually it is a write-run-correct cycle), because current IDEs only catch trivial errors.It's actually better than with interpreted or scripted languages, because once you've finished writing code, it will run ! comparable to Python.If I have to develop in Java, emacs or even gedit usually do just fine.Background compiling shouldn't be too hard to implement for an editor, I guess: run the compiler in background on the current module every other second (or only when a set of simple syntaxic conditions like parentheses/accolades matching are matched, conditions which can easily be checked by the editor itself), and display the error messages in semi real time on screen where they appear.This is too simplistic and very wasteful. The same data will be processed all over again. I don't know how IDEs manage to make modern2GHZ quad-core systems appear slow, but it might well be that kind ofcoding.
May 12 2012
"SomeDude" <lovelydear mailmetrash.com> wrote in message news:icvpcsajlyvsubowpqxo forum.dlang.org...Indeed, and Timon forgot the best feature of IDEs for bytecode compilers imho: they compile in the background, so that errors are detected while you type. There is no annoying "write-correct" cycle as compile-time errors are shown in real time. That's a *huge* productivity boost.I find the sluggish text-editing that inevitably implies to be MUCH more destructive to my productivity than an occasional few seconds compiling after I'm done typing. The former interferes with my mental processes, the latter does not.
May 12 2012
On 12/05/2012 01:00, Timon Gehr wrote:some essential properties: - starts up instantaneously....some 'nice to have' properties: - code analysis based code completion - integrated debuggerSo just starting up the IDE is more important than actually writing code or fixing bugs?... Seriously, I'm never going to understand you "editor" people.. -- Bruno Medeiros - Software Engineer
May 18 2012
On Friday, 18 May 2012 at 16:59:41 UTC, Bruno Medeiros wrote:On 12/05/2012 01:00, Timon Gehr wrote:Latency vs. Throughput. Both of them matter.some essential properties: - starts up instantaneously....some 'nice to have' properties: - code analysis based code completion - integrated debuggerSo just starting up the IDE is more important than actually writing code or fixing bugs?... Seriously, I'm never going to understand you "editor" people..
May 18 2012
On 18-05-2012 18:59, Bruno Medeiros wrote:On 12/05/2012 01:00, Timon Gehr wrote:I shouldn't have to keep my IDE open all the time when I'm not using it. I should be able to just open it at any point where I need it and close it immediately when I'm done.some essential properties: - starts up instantaneously.....some 'nice to have' properties: - code analysis based code completion> - integrated debugger So just starting up the IDE is more important than actually writing code or fixing bugs?...Seriously, I'm never going to understand you "editor" people..-- Alex Rønne Petersen alex lycus.org http://lycus.org
May 18 2012
On Friday, 18 May 2012 at 16:59:41 UTC, Bruno Medeiros wrote:So just starting up the IDE is more important than actually writing code or fixing bugs?...I'd like to see you do those things without starting your IDE.Seriously, I'm never going to understand you "editor" people..My oversimplification of it is, IDEs like the fundimental component of writing software. A text editor. Sure it has this text insertion thing, but it just looks like they forgot about it.
May 18 2012
On Saturday, 19 May 2012 at 01:33:55 UTC, Jesse Phillips wrote:On Friday, 18 May 2012 at 16:59:41 UTC, Bruno Medeiros wrote:I'll have to agree. You can skip the editor entirely and use nothing but cat, or Joe but I personally have not; I make too many mistakes on a single pass usually. Having a good base working environment that is both easy to use, and combines everything you need in one spot is actually quite crucial; and this does include an editor which may (hopefully) be part of an IDE. True I can probably do all the C/C++/D programming I want in notepad++, but doing all the extra work manually or only being able to rely on the language reference without any intellisense or something does leave a bit of a problem. The biggest deterrent to using D/D2 up to now was lacking a good debugger. With VisualD around I have just enough in the VS IDE to write and use my own code; True it has a lot of work to be done on it, but It's usable. An improved IDE and debugger later will greatly speed up not only bug fixing but programming in general using D.So just starting up the IDE is more important than actually writing code or fixing bugs?...I'd like to see you do those things without starting your IDE.Seriously, I'm never going to understand you "editor" people..My oversimplification of it is, IDEs like the fundamental component of writing software. A text editor. Sure it has this text insertion thing, but it just looks like they forgot about it.
May 19 2012
On 19/05/2012 02:33, Jesse Phillips wrote:On Friday, 18 May 2012 at 16:59:41 UTC, Bruno Medeiros wrote:Oh yeah, I'd like to see you do those things using just one hand. Or with your eyes closed!... ...do you understand why I made that satire above? Yes, my productivity would take a huge hit if I didn't have an IDE. Coding without an IDE for me is like coding with just one hand, or something like that. But why would I code without an IDE? I see no point in adding such restrictions to my development activity, I am not the kind of software developer that sees value in artificial limitations to show off your hacksmanship or mad coding skillz (hey, I'm editing inodes by hand... ...WITH MAGNETS!!!) If you are such a developer, if you like tricks and artificial challenges, then that's fine, let's just call it a difference in goals. But my main goal and interest in software development is to produce high quality software in the most efficient way. -- Bruno Medeiros - Software EngineerSo just starting up the IDE is more important than actually writing code or fixing bugs?...I'd like to see you do those things without starting your IDE.
May 30 2012
On 18 May 2012 19:59, Bruno Medeiros <brunodomedeiros+dng gmail.com> wrote:On 12/05/2012 01:00, Timon Gehr wrote:No, writing code and fixing bugs is more important than sitting around and operating your computer. I can hit F7 or F5 way faster than I can type a full line of some command on the shell. I can tap tab and instantly complete typing the crap I waste time typing repeatedly (typing almost all identifiers become just 1 or 2 key strokes). I can hit ctrl-space and have the documentation for a function appear INSTANTLY much faster than I can swap out and refer to some reference manual. I can step and debug and inspect the value of variables, deep in structures containing a heap of indirection way faster than I can operate GDB. I will seriously never understand anyone who will try and honestly say typing shit on a command line, feeding commands to GDB manually, and looking up references in some external manual can possibly be faster... under ANY circumstances... ever.some essential properties: - starts up instantaneously.... some 'nice to have' properties:- code analysis based code completion - integrated debuggerSo just starting up the IDE is more important than actually writing code or fixing bugs?... Seriously, I'm never going to understand you "editor" people..
May 19 2012
On Saturday, 19 May 2012 at 20:42:13 UTC, Manu wrote:On 18 May 2012 19:59, Bruno Medeiros <brunodomedeiros+dng gmail.com> wrote:Perhaps to be a hard-core hacker? I've done a GUI-less programming before, using GDB, typing the commands, all that jazz. But it's about the same as jogging to work every day that's say 15 Miles away; you 'COULD' do it, but if there's a better way like a bike or a car or segway, then why continue to do it the longer more busy route? With a good editor and having data 10-50x faster and more available, you can get more work done, and thereby fix more bugs and program more. You'd have to actually use a decent IDE (like eclipse for java) to realize how useful it can be. Course if you have an awesome memory then perhaps it isn't quite as important; but honestly I have a horrible memory.On 12/05/2012 01:00, Timon Gehr wrote:No, writing code and fixing bugs is more important than sitting around and operating your computer. I can hit F7 or F5 way faster than I can type a full line of some command on the shell. I can tap tab and instantly complete typing the crap I waste time typing repeatedly (typing almost all identifiers become just 1 or 2 key strokes). I can hit ctrl-space and have the documentation for a function appear INSTANTLY much faster than I can swap out and refer to some reference manual. I can step and debug and inspect the value of variables, deep in structures containing a heap of indirection way faster than I can operate GDB. I will seriously never understand anyone who will try and honestly say typing shit on a command line, feeding commands to GDB manually, and looking up references in some external manual can possibly be faster... under ANY circumstances... ever.some essential properties: - starts up instantaneously.... some 'nice to have' properties:- code analysis based code completion - integrated debuggerSo just starting up the IDE is more important than actually writing code or fixing bugs?... Seriously, I'm never going to understand you "editor" people..
May 19 2012
On 05/18/2012 06:59 PM, Bruno Medeiros wrote:On 12/05/2012 01:00, Timon Gehr wrote:No, you misunderstand. - Time spent starting up the IDE is lost time that could be spent doing something productive instead. Hardware is fast. There is simply no excuse for poor start up times/poor responsiveness. - The current IDEs have poor support for editing and navigating text. Furthermore, 'pattern recognition based code completion' was on my list as well. - I am more efficient at bug-chasing by sending relevant data to stdout instead of setting breakpoints and fighting the GUI until I understand what is going on. (I think that one of the most useful features of eclipse is the built-in console.) Furthermore, in my experience, almost all bugs are trivial regressions and/or caught immediately by reasonably good assertions. YMMV. - I concur that when faced with a new code base, or just poorly written code not written by oneself, some of the IDE features are very useful in order to get up to speed. But why does this functionality have to come in a GUI app, fully integrated with other components that may have drawbacks even if they are not explicitly used?some essential properties: - starts up instantaneously....some 'nice to have' properties: - code analysis based code completion> - integrated debugger So just starting up the IDE is more important than actually writing code or fixing bugs?...Seriously, I'm never going to understand you "editor" people..I do not see how this is relevant. Is your misunderstanding of the post deliberate?
May 20 2012
On 20 May 2012 17:19, Timon Gehr <timon.gehr gmx.ch> wrote:On 05/18/2012 06:59 PM, Bruno Medeiros wrote:clear indication the environment was important to him.On 12/05/2012 01:00, Timon Gehr wrote:No, you misunderstand. - Time spent starting up the IDE is lost time that could be spent doing something productive instead. Hardware is fast. There is simply no excuse for poor start up times/poor responsiveness. - The current IDEs have poor support for editing and navigating text. Furthermore, 'pattern recognition based code completion' was on my list as well. - I am more efficient at bug-chasing by sending relevant data to stdout instead of setting breakpoints and fighting the GUI until I understand what is going on. (I think that one of the most useful features of eclipse is the built-in console.) Furthermore, in my experience, almost all bugs are trivial regressions and/or caught immediately by reasonably good assertions. YMMV. - I concur that when faced with a new code base, or just poorly written code not written by oneself, some of the IDE features are very useful in order to get up to speed. But why does this functionality have to come in a GUI app, fully integrated with other components that may have drawbacks even if they are not explicitly used? Seriously, I'm never going to understand you "editor" people..some essential properties: - starts up instantaneously....some 'nice to have' properties: - code analysis based code completion> - integrated debugger So just starting up the IDE is more important than actually writing code or fixing bugs?...I do not see how this is relevant. Is your misunderstanding of the post deliberate?
May 20 2012
On 05/20/2012 08:47 PM, Manu wrote:clear indication the environment was important to him.Linux any day.
May 20 2012
On Sun, 20 May 2012 20:43:15 +0100, Timon Gehr <timon.gehr gmx.ch> wrote:On 05/20/2012 08:47 PM, Manu wrote:It really all depends on where each person is coming from. I have used windows/msvc all my career and I know how to do what I want to do without having to think about it, or go hunting for it, etc. If you're that comfortable on another OS using other tools, then I can see why you wouldn't want to change. The only motivator I can see for change is if the existing system is broken, or a new system brings /significant/ improvement. I've worked with guys who had a good familiarity with GNU tools/environments and so requested the flexibility to switch their desktop/development environments from Windows/MSVC to linux/GNU or similar. Permission was granted and off they went. I can't honestly say they became more productive, but they were happier. The cost was the downtime as they switched, and all those problems which cropped up after the fact - like how to get source in/out of existing systems to their new desktops etc. Ultimately you'll be most productive using something which will: a. do the job b. in a way you're most familiar/used to End of story. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/clear indication the environment was important to him.Linux any day.
May 21 2012
On 20/05/2012 15:19, Timon Gehr wrote:No, you misunderstand. - Time spent starting up the IDE is lost time that could be spent doing something productive instead. Hardware is fast. There is simply no excuse for poor start up times/poor responsiveness.I am not misunderstanding. No one is saying there is no value in saving that start up time. But you listed that as *more* important than many other features that actually help a lot (and thus save time a lot) when you code, or debug programs. Oh and there are excuses for poor start up times. I am not gonna explain them because it would get technical and long. -- Bruno Medeiros - Software Engineer
May 30 2012
On 30-05-2012 17:30, Bruno Medeiros wrote:On 20/05/2012 15:19, Timon Gehr wrote:I'm just going to add that Visual Studio 11 can start up in less than a second. Visual Studio 2010 could take well towards 10 seconds (and sometimes more if you have many extensions). They solved the problem simply by lazy-loading almost everything they could. It turns out that the majority of stuff that most IDEs load on startup isn't going to be used during a session, so it's just wasted time. -- Alex Rønne Petersen alex lycus.org http://lycus.orgNo, you misunderstand. - Time spent starting up the IDE is lost time that could be spent doing something productive instead. Hardware is fast. There is simply no excuse for poor start up times/poor responsiveness.I am not misunderstanding. No one is saying there is no value in saving that start up time. But you listed that as *more* important than many other features that actually help a lot (and thus save time a lot) when you code, or debug programs. Oh and there are excuses for poor start up times. I am not gonna explain them because it would get technical and long.
May 30 2012
On Saturday, May 12, 2012 13:03:26 Manu wrote:On 12 May 2012 12:37, Jonathan M Davis <jmdavisProg gmx.com> wrote:So, basically it's just the issue with neither ref nor const ref taking lvalues. If you duplicate the functions (or use auto ref if they're templated functions), then it's not an issue. It sucks to have to duplicate stuff, but ref works just fine as long as you don't assume that it's going to allow you to pass rvalues to it. Personally, I almost always just have functions take structs by value, so it's a non-issue except for stuff like opEquals, which requires const ref (for at least one overload anyway). However, given the ridiculousness of having to duplicate functions to make ref usuable for any case where you're specifically trying to avoid a copy rather than use it to pass a value out, Andrei and Walter are looking at making ref work with rvalues. They just have to sort out how to avoid the issues that C++ has due to allow const& to take rvalues (which is why const ref in D doesn't currently take rvalues). So, there's a good chance that the situation will improve considerably sometime soon. - Jonathan M DavisOn Saturday, May 12, 2012 11:26:37 Timon Gehr wrote:struct X { int i; X opBinary(string op)(const ref X b) if(op == "+") { return X(i + b.i); } ref X opOpAssign(string op)(const ref X b) if(op == "+") { i += b.i; return this; } ...etc } ref X func(ref X x) { return x; } bool maybe() { return (time() & 1) != 0; } void test() { X a,b,c; X v[]; func(a); // this is basically the only expression that works X t = a + (b + c); // fail a += b + c; // fail ref X t = func(a); // fail func(a + b); // fail func(maybe() ? a : b); // this generates bad code: http://forum.dlang.org/thread/cnwpmhihmckpjhlaszzy forum.dlang.org ref X t = v[some + complex * (expression + that_i_dont_want_to_repeat())]; // fail foreach(i; 0..10) { ref X t = v[some + expression * involving - i]; // fail } } Just a couple of extremely common usage patterns that come to mind. I'm sure there are many more...On 05/12/2012 10:13 AM, Manu wrote:withOn 11 May 2012 21:28, Mehrdad <wfunction hotmail.com <mailto:wfunction hotmail.com>> wrote: Yes, I agree, but consider that D users should NOT have to worknon-trivialpointers to do something so basic I'd like to think this were true, but the fact that 'ref' barely works makes this almost immediately false when trying to write anyI rarely end up passing by either ref or pointer, and the only issues that I've ever had with ref relate to the fact that you can't pass it rvalues. Obviously both pointers and ref have their uses, but I'd definitely have to concur that it depends on your coding style and what you're doing. Also, I really don't know what's wrong with ref such that anyone could say that it "barely works" other than the issues with rvalues and functions which take ref or const ref.program.It depends on the coding style.
May 12 2012
On 05/12/2012 12:13 PM, Jonathan M Davis wrote:On Saturday, May 12, 2012 13:03:26 Manu wrote:I don't see why 'const' should make a difference there anyway. It is completely orthogonal. It could be argued that the callee might assume that his changes will be visible for the caller, but if the point of passing an rvalue by reference is to gain performance, forbidding the callee to use it as scratch space is just ridiculous.On 12 May 2012 12:37, Jonathan M Davis<jmdavisProg gmx.com> wrote:So, basically it's just the issue with neither ref nor const ref taking lvalues. If you duplicate the functions (or use auto ref if they're templated functions), then it's not an issue. It sucks to have to duplicate stuff, but ref works just fine as long as you don't assume that it's going to allow you to pass rvalues to it. Personally, I almost always just have functions take structs by value, so it's a non-issue except for stuff like opEquals, which requires const ref (for at least one overload anyway). However, given the ridiculousness of having to duplicate functions to make ref usuable for any case where you're specifically trying to avoid a copy rather than use it to pass a value out, Andrei and Walter are looking at making ref work with rvalues. They just have to sort out how to avoid the issues that C++ has due to allow const& to take rvalues (which is why const ref in D doesn't currently take rvalues). So, there's a good chance that the situation will improve considerably sometime soon. - Jonathan M DavisOn Saturday, May 12, 2012 11:26:37 Timon Gehr wrote:struct X { int i; X opBinary(string op)(const ref X b) if(op == "+") { return X(i + b.i); } ref X opOpAssign(string op)(const ref X b) if(op == "+") { i += b.i; return this; } ...etc } ref X func(ref X x) { return x; } bool maybe() { return (time()& 1) != 0; } void test() { X a,b,c; X v[]; func(a); // this is basically the only expression that works X t = a + (b + c); // fail a += b + c; // fail ref X t = func(a); // fail func(a + b); // fail func(maybe() ? a : b); // this generates bad code: http://forum.dlang.org/thread/cnwpmhihmckpjhlaszzy forum.dlang.org ref X t = v[some + complex * (expression + that_i_dont_want_to_repeat())]; // fail foreach(i; 0..10) { ref X t = v[some + expression * involving - i]; // fail } } Just a couple of extremely common usage patterns that come to mind. I'm sure there are many more...On 05/12/2012 10:13 AM, Manu wrote:withOn 11 May 2012 21:28, Mehrdad<wfunction hotmail.com <mailto:wfunction hotmail.com>> wrote: Yes, I agree, but consider that D users should NOT have to worknon-trivialpointers to do something so basic I'd like to think this were true, but the fact that 'ref' barely works makes this almost immediately false when trying to write anyI rarely end up passing by either ref or pointer, and the only issues that I've ever had with ref relate to the fact that you can't pass it rvalues. Obviously both pointers and ref have their uses, but I'd definitely have to concur that it depends on your coding style and what you're doing. Also, I really don't know what's wrong with ref such that anyone could say that it "barely works" other than the issues with rvalues and functions which take ref or const ref.program.It depends on the coding style.
May 12 2012
On 12 May 2012 13:13, Jonathan M Davis <jmdavisProg gmx.com> wrote:So, basically it's just the issue with neither ref nor const ref taking lvalues.And the local references, and the bug. If you duplicate the functions (or use auto ref if they're templatedfunctions), then it's not an issue.Yes it is. Passing by value is NOT passing by reference, it's a totally different operation. And what about non-const ref? 'in ref' would be very nice if it worked. It would basically replace 'const ref'. It sucks to have to duplicate stuff, butref works just fine as long as you don't assume that it's going to allow you to pass rvalues to it.Well there's the bugs we've seen in optimised codegen. Duplicating with non-ref is not a solution. It's not even a workaround. The only workaround is to receive a pointer, which ruins all those cases in terms of syntax anyway. Personally, I almost always just have functions takestructs by value, so it's a non-issue except for stuff like opEquals, which requires const ref (for at least one overload anyway).Well I think it's safe to say most people pass data structs by reference. If I saw someone pass a struct by val, I'd consider it a bug/typo and fix it. You might say to use a class in D, but classes aren't a pure data structure like they are in C; I see them as being for fundamentally different purposes, and I wouldn't use a class to express a struct. Classes also ruin strict data layout and alignment of members. I don't think that's a valid workaround either, it's effectively abusing the very _concept_ of classes in D. However, given the ridiculousness of having to duplicate functions to makeref usuable for any case where you're specifically trying to avoid a copy rather than use it to pass a value out, Andrei and Walter are looking at making ref work with rvalues.Awesome, although it doesn't end there. Local references are also very important. They just have to sort out how to avoid the issues that C++has due to allow const& to take rvalues (which is why const ref in D doesn't currently take rvalues). So, there's a good chance that the situation will improve considerably sometime soon.What are these issues I keep hearing about? I'm not aware of any fundamental problem with ref in C++... Can you show an example of the problem the design is trying to avoid?That's not a solution, it's not even a work around, it's a totallyWell, in my line of work, if the cost of passing by value is greater than the cost of passing by reference, then the correct thing to do is to pass by reference. There is zero tolerance for wasting memory accesses on such a trivial operation. The only case where the cost of passing by value is ever less than by reference is if the struct contains a single primitive value for which the CPU has a dedicated register type. This is the only time we would ever tolerate passing by value. But there's no question that the situation with const ref needs to bedifferent operation. I may not want to, or can't, pass my data by value.Whether passing by value makes sense depends on the struct. If it has lots of members, then no, passing by value doesn't work very well (though still not as badly as C++98 thanks to the fact that D can move structs far more often due to its different copy semantics). But almost all of the structs that I deal with only have a handful of member variables at most, so the cost of passing by value isn't high. In most cases, if I have a lot, I probably wanted a reference type anyway, in which case, I'm almost certainly going to use a class.improved (it was discussed quite a bit on the beta list during the last beta). Fortunately, that's likely to happen sometime soon.That's a shame, it's been coming up every day for me the last couple of weeks. I have workarounds in almost every source file, and some cases where a workaround is impossible, which pollutes the code at the point of use.
May 12 2012
On 12.05.2012 14:39, Manu wrote:On 12 May 2012 13:13, Jonathan M Davis <jmdavisProg gmx.com <mailto:jmdavisProg gmx.com>> wrote: So, basically it's just the issue with neither ref nor const ref taking lvalues. And the local references, and the bug. If you duplicate the functions (or use auto ref if they're templated functions), then it's not an issue. Yes it is. Passing by value is NOT passing by reference, it's a totally different operation. And what about non-const ref? 'in ref' would be very nice if it worked. It would basically replace 'const ref'. It sucks to have to duplicate stuff, but ref works just fine as long as you don't assume that it's going to allow you to pass rvalues to it. Well there's the bugs we've seen in optimised codegen. Duplicating with non-ref is not a solution. It's not even a workaround. The only workaround is to receive a pointer, which ruins all those cases in terms of syntax anyway. Personally, I almost always just have functions take structs by value, so it's a non-issue except for stuff like opEquals, which requires const ref (for at least one overload anyway). Well I think it's safe to say most people pass data structs by reference. If I saw someone pass a struct by val, I'd consider it a bug/typo and fix it.Brr... most ranges are structs. And yes, they are passed by value (rightfully so). -- Dmitry Olshansky
May 12 2012
"Manu" <turkeyman gmail.com> wrote in message news:mailman.647.1336819289.24740.digitalmars-d puremagic.com...On 12 May 2012 13:13, Jonathan M Davis <jmdavisProg gmx.com> wrote:There was a big discussion of recently on the dmd beta mailing list . One of Andrei's posts there explained it all. (Sorry, I don't have a link handy ATM. Shouldn't be too hard to find, though.)They just have to sort out how to avoid the issues that C++ has due to allow const& to take rvalues (which is why const ref in D doesn't currently take rvalues). So, there's a good chance that the situation will improve considerably sometime soon.What are these issues I keep hearing about? I'm not aware of any fundamental problem with ref in C++... Can you show an example of the problem the design is trying to avoid?
May 12 2012
On Saturday, May 12, 2012 15:17:22 Manu wrote:On 12 May 2012 14:03, Jonathan M Davis <jmdavisProg gmx.com> wrote:I believe that you can do it with a pointer. auto t = &someFunc(); And as long as you don't try to increment the pointer, it's safe. It doesn't even require different semantics when calling member functions, unlike C++ (though you'd still have to dereference it if you want to copy it, so the code would still differ somewhat from what you want in terms of syntax). Regardless, unfortunately, I don't remember why Walter doesn't want ref local variables. You'd have to get him to explain that. I just remember that he doesn't want them and I don't think that it wasn't really up for discussion. Maybe you can find an argument to convince him. I don't know. But from what I recall, there isn't much chance of that.On Saturday, May 12, 2012 13:39:54 Manu wrote:So what's the work around then? Using pointers pollute your usage with pointer assignment problems, and leads to many redundant instances of &, *, and parentheses all over the place. Another scenario to consider: given: ref X someFunc(); ref X t = someFunc(); // fail Without ref locals, there is no way to hold a local reference to something returned by a function, which defeats the purpose... And if ref is not a type constructor, auto and templates will never work properly either.Awesome, although it doesn't end there. Local references are also very important.Never going to happen. Walter doesn't like them (they also cause issues with the proposal to let ref take rvalues in D IMHO), but I don't remember the details. Regardless, I'd be shocked if they were ever introduced into D.Well, while I'm sure that your use cases are very important and may beC++ is not D. The semantics of passing arguments are not the same (thanks primary to postblit vs copy constructors). D creates fewer copies than C++. And actually, with C++'s move constructors, as I understand it, the advice is to no longer use const& for passing objects because it screws up the compiler's ability to optimize out temporaries (and the C++11 situation is much closer to D's situation than C++98 was). But regardless, I was never advocating that you _always_ pass structs by value. I was pointing out that for smaller structs (those with only a few members), it generally works just fine - except maybe in cases where you're worrying about absolutely every CPU cycle. - Jonathan M Davisnormal in your industry, I don't think that they're normal in the programming world in general.I've never met a C++ programmer (other than yourself apparently) that doesn't pass structs/classes by ref. That's generally considered absurd. And if you want evidence, just look at the STL, Boost, or any other C++ library you care to pick.
May 12 2012
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.657.1336847061.24740.digitalmars-d puremagic.com...Regardless, unfortunately, I don't remember why Walter doesn't want ref local variables. You'd have to get him to explain that. I just remember that he doesn't want them and I don't think that it wasn't really up for discussion. Maybe you can find an argument to convince him. I don't know. But from what I recall, there isn't much chance of that.IIRC, this was also explained in the big discussion on the dmd beta mailing list.
May 12 2012
"Paulo Pinto" <pjmlp progtools.org> wrote in message news:jojish$2cm2$1 digitalmars.com...The author of a D based PSP emulator just rewrote https://github.com/soywiz/cspspemu The reasons are listed here, https://github.com/soywiz/cspspemu#created-after-4-tries(Heh, now that Time Warner is no longer destroying GitHub for me and I can actually *see* that page...) "The lack of a good IDE, the complicated structure of the D language, the horrible compilation times, caused that it taked too much time for everything, and made it impossible to refactoring the code without days or weeks of work." That almost sounds like he's talking about some completely different D programming language. And I know it's been discussed here already, but seriously, "horrible compilation times"? What hell is he smoking? Hmm, actually, you know what? I bet he was probably trying to do the C/C++ thing and compile one...source...file...at...a...time. THAT would certainly do it. You can easily get nearly-C++-level speeds that way. Or maybe using rebuild: even with one-at-a-time disabled, rebuild can still be pretty slow compared to say, rdmd. LOL, *or*...He didn't say "horribly SLOW compilation times", he just said "horrible compilation times". Maybe he just hates fast compiles? Not even enough time to go grab a coffee, let alone catch a movie and dinner. ;)
May 12 2012
On 13-05-2012 00:20, Nick Sabalausky wrote:"Paulo Pinto"<pjmlp progtools.org> wrote in message news:jojish$2cm2$1 digitalmars.com...You know, my project consisting of 130-ish source files and 24.000-ish lines of code compiles from scratch in ~20 seconds on my machine, building one file at a time... I honestly have not managed to come up with a build system for D that is actually slow, if compared to C/C++.The author of a D based PSP emulator just rewrote https://github.com/soywiz/cspspemu The reasons are listed here, https://github.com/soywiz/cspspemu#created-after-4-tries(Heh, now that Time Warner is no longer destroying GitHub for me and I can actually *see* that page...) "The lack of a good IDE, the complicated structure of the D language, the horrible compilation times, caused that it taked too much time for everything, and made it impossible to refactoring the code without days or weeks of work." That almost sounds like he's talking about some completely different D programming language. And I know it's been discussed here already, but seriously, "horrible compilation times"? What hell is he smoking? Hmm, actually, you know what? I bet he was probably trying to do the C/C++ thing and compile one...source...file...at...a...time. THAT would certainly do it. You can easily get nearly-C++-level speeds that way. Or maybe using rebuild: even with one-at-a-time disabled, rebuild can still be pretty slow compared to say, rdmd.LOL, *or*...He didn't say "horribly SLOW compilation times", he just said "horrible compilation times". Maybe he just hates fast compiles? Not even enough time to go grab a coffee, let alone catch a movie and dinner. ;)-- - Alex
May 12 2012
On Saturday, 12 May 2012 at 23:27:15 UTC, Alex Rønne Petersen wrote:You know, my project consisting of 130-ish source files and 24.000-ish lines of code compiles from scratch in ~20 seconds on my machine, building one file at a time... I honestly have not managed to come up with a build system for D that is actually slow, if compared to C/C++.Try using GDC the compiler that can actually produce good code, or using -inline -release flags. Debug build (GDC, multi invocation, 3 threads) real 0m42.452s Release build (GDC, multi invocation, 3 threads) real 1m0.140s Debug build (GDC, single invocation) real 0m22.151s Release build (GDC, single invocation) real 0m54.960s $ find src/ -name "*.d" | xargs wc -l | tail --lines 1 46057 total Cheers, Jakob.
May 14 2012
Am Mon, 14 May 2012 10:19:40 +0200 schrieb "Jakob Bornecrantz" <wallbraker gmail.com>:On Saturday, 12 May 2012 at 23:27:15 UTC, Alex R=C3=B8nne Petersen wrote:This is true. Once you decide to use GDC for whatever reason (chances of in= clusion into GCC, better optimization, ...) you are also about 1 revision b= ehind the DMD release. I usually assume that GDC 2.057 code will compile on= DMD 2.059, but not the reverse. So I never actually use DMD any more to re= member how fast it compiles. He could have made a similar experience. Also I see a lot of you compare D with C/C++ compilation times, whereas the= and it probably has a compiler with comparable speed to DMD (e.g. much fas= for a VM with much less real world constraints. Often compilers for VM lang= uages come with the compiler integrated into the standard library, allowing= for easy integration into IDEs and further optimizations of the compile ti= me. I remember Delphi (not as a VM language) had the compiler and linker in= tegrated into the IDE which made single file rebuilds practically instantan= eous. --=20 MarcoYou know, my project consisting of 130-ish source files and=20 24.000-ish lines of code compiles from scratch in ~20 seconds=20 on my machine, building one file at a time... I honestly have=20 not managed to come up with a build system for D that is=20 actually slow, if compared to C/C++.=20 Try using GDC the compiler that can actually produce good code, or using -inline -release flags. =20 Debug build (GDC, multi invocation, 3 threads) real 0m42.452s =20 Release build (GDC, multi invocation, 3 threads) real 1m0.140s =20 Debug build (GDC, single invocation) real 0m22.151s =20 Release build (GDC, single invocation) real 0m54.960s =20 $ find src/ -name "*.d" | xargs wc -l | tail --lines 1 46057 total =20 Cheers, Jakob.
May 17 2012
I just replied here with my motivations: https://github.com/soywiz/pspemu/issues/1 "D is just fine to create an emulator. The problem was that I was doing emergent design, so I was refactoring a lot. And design flaws caused the refactorings to be massive. D didn't had a good IDE allowing refactoring by that moment (not sure about that now). That was the main reason for me to change the technology. Also there was minor flaws: Compilation times were huge. I was using lot of compile-time code generation and at least at that time, that code was interpreted or not enought fast for me. Also I didn't get incremental compilation working, it failed everytime probably because that compilation-time stuff causing the compilation to take stuff like 1 entire minute. And that was unacceptable too for me. I needed to run it lots of times to doing research. Also I needed a needed to chaneg the emulator to perform dynamic recompilation instead easily. In the case of D I would have to creaet a emitter per supported platform (mostly x86, x64 and ARM). fact, I liked D a lot, that much that I started an emulator using it."
Aug 02 2013
soywiz:D didn't had a good IDE allowing refactoring by that momentThat's mostly a tools/ecosystem problem, but perhaps the language design could help a little to perform the refactoring. How can a language help refactoring?Compilation times were huge. I was using lot of compile-time code generation and at least at that time, that code was interpreted or not enought fast for me.This is a known problem, it can be solved, people are working on it, and I think eventually it will be partially solved.Also I needed a needed to chaneg the emulator to perform could do portable dynarec very easily. In the case of D I would have to creaet a emitter per supported platform (mostly x86, x64 and ARM).I think this is mostly a library problem. Bye, bearophile
Aug 02 2013