Re: Knowing the approach to solve a D challenge
On Friday, 16 February 2018 at 09:44:27 UTC, aberba wrote: D has tone of features and library solutions. When you encounter a problem, how do you approach solving it in code? 1. Do you first write it in idiomatic D style or a more general approach before porting to idiomatic D? Like always, it depends. Do I attribute up all my functions with const/@safe/nothrow... (is that even idiomatic) no. Do I build a range to process some data... sometimes. Do I utilize std.algorithm/std.range functions to process my data... when available. Even my C# code tends to be more idiomatic D than others. 2. Do you find yourself mostly rolling out your own implementation first before using a library function? I don't know. If a rolled my own I probably don't know of the library function/function combination that does the same thing. 3. Do the use of generics come out of first try or a rewrite? Usually not. If I don't have another use-case I probably don't know what needs to be generic. 4. What rough percentage of phobos knowledge is required for reasonable good problem solving efficiency? I would guess average. The reason I say this because unlike popular languages search doesn't always provide a good example for every question so you kind of need to already know what you're looking for. It doesn't help that sometimes the answer is a combination of this (.reduce!max that isn't found in std.math)
Re: Knowing the approach to solve a D challenge
On Friday, 16 February 2018 at 09:44:27 UTC, aberba wrote: 1. Do you first write it in idiomatic D style or a more general approach before porting to idiomatic D? In micro-level, it's usually fairly idiomatic from get-go. Usually no heap allocations at inner loops, for-looping, static variables etc. Sometimes if I get a bit desperate of frustated I might do this a bit. But at larger level, I often find myself shifting work between functions, structs, modules and so. In other words, redesigning. 2. Do you find yourself mostly rolling out your own implementation first before using a library function? No, the vast majority of my calls are from Phobos or other libraries I use. And in case of Phobos at least, it's stuff is so general that I don't need to design my own function often. An exception is std.algorithm.each, but just to get better error messages (template constraints don't tell why the call did not work). 3. Do the use of generics come out of first try or a rewrite? Rewriting a lot, but that's the case with all coding. With generics, i often tend to forget ! before an alias parameter. 4. What rough percentage of phobos knowledge is required for reasonable good problem solving efficiency? If we talk about experience of the language in general, it's more than with C-style programming, Java or C# but less than with C++ generics. I don't think you have to know Phobos throughout, but you have to know the language and understand the philosophy of ranges quite deeply. Percentages aren't important, I think that as long as you know the general purpose of std.algorithm, std.range, std.stdio, std.conv and std.array that gets you started. Again, if you know the language and understand the range concept.
Re: Knowing the approach to solve a D challenge
On Friday, 16 February 2018 at 09:44:27 UTC, aberba wrote: D has tone of features and library solutions. When you encounter a problem, how do you approach solving it in code? 1. Do you first write it in idiomatic D style or a more general approach before porting to idiomatic D? As idiomatic as possible. But it depends on how big and/or important the method/function is. The more important and/or bigger, the more idiomatic. Sometimes a `foreach` will do in a small function. But D makes it easy to write idiomatic code straight away, although sometimes it can be a bit annoying when you get messages like "cannot implicitly convert x of type y to z". So you have to keep track of what you are chaining. 2. Do you find yourself mostly rolling out your own implementation first before using a library function? I usually start to roll out my own for a few minutes until I say "Hold on, maybe the library already has a function that does exactly that!" And it often does. That's because I get a better understanding of what I need, when I roll my own for a while. Using the library straight away can sometimes result in shooting yourself in the foot. So it's a mix of both. 3. Do the use of generics come out of first try or a rewrite? Depends on the problem at hand. I you know you will have to handle several types down the road, it's a minimal generic that accepts only one type to begin with but that can be extended to others. It's a bit "play by ear". If I'm dealing with HTML and I know that JSON or CSV will be needed later, I write the function in a way that it can easily be extended. If a function returns the user name as a `string`, I won't bother with generics. That's just normal, I think. 4. What rough percentage of phobos knowledge is required for reasonable good problem solving efficiency? You cannot know every function, of course, and new functions are being added all the time. What you need to know is what Phobos can do in general and where to look for it. The cheat sheet should be the first port of call. You can save a lot of time by skimming through the library regularly. Also, it's worth looking at other people's code in the "learn" section. What often happens to me, when I see a solution, I go "Jesus, that's clever, I'll keep that in mind!" The learn section is good because it focuses on one (small) problem at a time.
Re: Knowing the approach to solve a D challenge
I don't write much D code, but here are my answers for _any_ language. On Friday, 16 February 2018 at 09:44:27 UTC, aberba wrote: D has tone of features and library solutions. When you encounter a problem, how do you approach solving it in code? 1. Do you first write it in idiomatic D style or a more general approach before porting to idiomatic D? The style in my head, which sometimes is D function chains, for example, this chain I put in Phobos: https://github.com/dlang/phobos/blob/master/std/datetime/timezone.d#L2501 Compare it to the previously-written non-Android version just below, which could probably be written as such a chain but might be too unwieldy if done that way. 2. Do you find yourself mostly rolling out your own implementation first before using a library function? Look for a library function, and if nothing works, write your own. 3. Do the use of generics come out of first try or a rewrite? I don't really need them for my own functions, so can't say. 4. What rough percentage of phobos knowledge is required for reasonable good problem solving efficiency? Just hunt for something when you need it. Knowing Phobos well is like indexing your data beforehand, you'll find something much quicker. The reason D supports so many styles is so you don't have to force yourself to use only one style. The D idioms are there if you need them though, and you may find using them gives you better code.
Re: Knowing the approach to solve a D challenge
On 16/02/2018 9:44 AM, aberba wrote: D has tone of features and library solutions. When you encounter a problem, how do you approach solving it in code? 1. Do you first write it in idiomatic D style or a more general approach before porting to idiomatic D? 2. Do you find yourself mostly rolling out your own implementation first before using a library function? 3. Do the use of generics come out of first try or a rewrite? 4. What rough percentage of phobos knowledge is required for reasonable good problem solving efficiency? A: Do it any way possible If it needs a rewrite then yes more idiomatic and better designed :)
Knowing the approach to solve a D challenge
D has tone of features and library solutions. When you encounter a problem, how do you approach solving it in code? 1. Do you first write it in idiomatic D style or a more general approach before porting to idiomatic D? 2. Do you find yourself mostly rolling out your own implementation first before using a library function? 3. Do the use of generics come out of first try or a rewrite? 4. What rough percentage of phobos knowledge is required for reasonable good problem solving efficiency?
