Re: Knowing the approach to solve a D challenge

2018-02-16 Thread Jesse Phillips via Digitalmars-d

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

2018-02-16 Thread Dukc via Digitalmars-d

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

2018-02-16 Thread Chris via Digitalmars-d

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

2018-02-16 Thread Joakim via Digitalmars-d
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

2018-02-16 Thread rikki cattermole via Digitalmars-d

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

2018-02-16 Thread aberba via Digitalmars-d
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?