On Thursday, 19 March 2015 at 00:52:12 UTC, Walter Bright wrote:
> On 3/18/2015 5:34 PM, cym13 wrote:
>> Maybe there should be a "part 2" to the C-to-D little tutorial, one that shows
>> how to code at a higher level introducing gently functional structures instead
>> of just teaching how to write C in D. To stop thinking about steps to think
>> about transformations isn't an easy thing.
>
> Andrei and I talked about this, how we are failing to point out how to idiomatically use D to advantage. We need to do a lot better at this.

One underused resource seems to be all the examples bearophile has put on Rosetta Code:

http://rosettacode.org/wiki/Category:D

If he, Adam, or some other proficient D user were to do a weekly series breaking down each of those 733 examples one at a time- what idioms were used, why certain variations were more efficient- that could go a long way to introduce the language and its idioms to beginners.  It would provide enough examples for 14 years of such a weekly series, by which time D3 will be getting started!

On 3/19/15 10:40 AM, weaselcat wrote:
> On Thursday, 19 March 2015 at 16:59:36 UTC, Ola Fosheim Grøstad wrote:
>> On Thursday, 19 March 2015 at 00:42:51 UTC, weaselcat wrote:
>>> On Wednesday, 18 March 2015 at 12:59:17 UTC, bearophile wrote:
>>>> High level constructs in D are often slower than low-level code, so
>>>> in some cases you don't want to use them.
>>>
>>> I actually found that LDC does an _amazing_ job of optimizing high
>>> level constructs and converting "low level" code to higher level
>>> functional code resulted in minor speedups in a lot of cases.
>>>
>>>
>>> (Other performance benefits include the algorithm primitives being
>>> extensively optimized in phobos.)
>>
>> If the code/compiler generates suboptimal code in the first place then
>> improvements can be somewhat random. But if you write code with good
>> cache locality, filling the pipeline properly then  there is no
>> alternative to going low level.
>>
>> Btw, take a look at this:
>> http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d
>>
>>
>> That's really bad marketing...
>
> python:
> time python2 wc.py enwiki-latest-pages-articles1.xml-p000000010p000010000
> There are 1245473 lines
> python2 wc.py enwiki-latest-pages-articles1.xml-p000000010p000010000
> 0.21s user 0.08s system 99% cpu 0.294 total
>
> wc -l:
> time wc -l enwiki-latest-pages-articles1.xml-p000000010p000010000
> 1245472 enwiki-latest-pages-articles1.xml-p000000010p000010000
> wc -l enwiki-latest-pages-articles1.xml-p000000010p000010000 0.05s user
> 0.02s system 96% cpu 0.072 total
>
>
> iterative version:
> ldc -O5 -inline -release -boundscheck=off wc.d
> time ./wc
> There are 1245473 lines.
> ./wc enwiki-latest-pages-articles1.xml-p000000010p000010000 0.59s user
> 0.07s system 99% cpu 0.661 total
>
> functional version:
> writeln("There are ",
> (cast(string)read(args[1])).splitter('\n').array.length, " lines.");
>
> ldc -O5 -inline -release -boundscheck=off wc.d
> time ./wc enwiki-latest-pages-articles1.xml-p000000010p000010000
> There are 1245473 lines.
> ./wc enwiki-latest-pages-articles1.xml-p000000010p000010000 0.04s user
> 0.08s system 98% cpu 0.125 total

You may want to answer there, not here. I've also posted a response.

Andrei

On Thursday, 19 March 2015 at 10:07:06 UTC, John Colvin wrote:
> On Tuesday, 17 March 2015 at 18:29:20 UTC, Almighty Bob wrote:
>> On Tuesday, 17 March 2015 at 11:48:15 UTC, Nick Treleaven wrote:
>>> On 17/03/2015 10:31, Almighty Bob wrote:
>>>> It's far more useful for csvReader to return a type I know and
>>>> can use than it is to obscure the return type for the sake of
>>>> some philosophical ideal of increasing encapsulation.
>>>
>>> Part of the art of API design is to hide implementation where it's not necessarily needed. Designers might err on the side of hiding things, because how you expose something is important as it has to be maintained indefinitely. If they expose everything then the internals can never be redesigned for better performance, etc.
>>
>> They don't increase encapsulation. The public members of a voldomort type are still public, you still have to code to the API of the return type whether it's a regular or voldomort type. You can keep as much private or public in either case as you like.
>>
>> All they do take the typename out of circulation, they make life harder for the user. There's no benefit. None.
>>
>> But at least the library author can stroke his chin a feel smug that there's one less type in the modules' namespace.
>
> Totally missing the point. The crux of the matter is this: changing a voldemort type (assuming the public semantics are the same) is not a breaking API change, because no-one else's code ever names it.

Seriously? You cant have a public API and private implementation with a regular type? That's something specific to voldomort types?

Ask yourself what exactly do voldomort types enable you to hide that cant be hidden with a regular type? Just one thing. Their name. As you said no one else can ever name the type.

That is no benefit to me the user. No-one has been able to even describe a benefit. Walters article on Dr Dobbs doesn't describe a benefit. It "increases encapsulation" you all squawk.

No it doesn't. The private bits are still private, the public bits are still public.

All it does is complicate the user side.

Its the emperor's new clothes.

On Thursday, 19 March 2015 at 20:43:55 UTC, Almighty Bob wrote:
> On Thursday, 19 March 2015 at 10:07:06 UTC, John Colvin wrote:
>> On Tuesday, 17 March 2015 at 18:29:20 UTC, Almighty Bob wrote:
>>> On Tuesday, 17 March 2015 at 11:48:15 UTC, Nick Treleaven wrote:
>>>> On 17/03/2015 10:31, Almighty Bob wrote:
>>>>> It's far more useful for csvReader to return a type I know and
>>>>> can use than it is to obscure the return type for the sake of
>>>>> some philosophical ideal of increasing encapsulation.
>>>>
>>>> Part of the art of API design is to hide implementation where it's not necessarily needed. Designers might err on the side of hiding things, because how you expose something is important as it has to be maintained indefinitely. If they expose everything then the internals can never be redesigned for better performance, etc.
>>>
>>> They don't increase encapsulation. The public members of a voldomort type are still public, you still have to code to the API of the return type whether it's a regular or voldomort type. You can keep as much private or public in either case as you like.
>>>
>>> All they do take the typename out of circulation, they make life harder for the user. There's no benefit. None.
>>>
>>> But at least the library author can stroke his chin a feel smug that there's one less type in the modules' namespace.
>>
>> Totally missing the point. The crux of the matter is this: changing a voldemort type (assuming the public semantics are the same) is not a breaking API change, because no-one else's code ever names it.
>
> Seriously? You cant have a public API and private implementation with a regular type? That's something specific to voldomort types?
>
> Ask yourself what exactly do voldomort types enable you to hide that cant be hidden with a regular type? Just one thing. Their name. As you said no one else can ever name the type.
>
> That is no benefit to me the user. No-one has been able to even describe a benefit. Walters article on Dr Dobbs doesn't describe a benefit. It "increases encapsulation" you all squawk.
>
> No it doesn't. The private bits are still private, the public bits are still public.
>
> All it does is complicate the user side.
>
> Its the emperor's new clothes.

It's not possible to construct a voldemort type outside of the function where it was declared, and you can't know what that type is, just what the API is. You can force type deduction so the type returned can be changed without breaking code, so long as the API is the same. That's how it increases encapsulation.

On Thursday, 19 March 2015 at 23:02:07 UTC, w0rp wrote:
> On Thursday, 19 March 2015 at 20:43:55 UTC, Almighty Bob wrote:
>> On Thursday, 19 March 2015 at 10:07:06 UTC, John Colvin wrote:
>>> On Tuesday, 17 March 2015 at 18:29:20 UTC, Almighty Bob wrote:
>>>> On Tuesday, 17 March 2015 at 11:48:15 UTC, Nick Treleaven wrote:
>>>>> On 17/03/2015 10:31, Almighty Bob wrote:
>>>>>> It's far more useful for csvReader to return a type I know and
>>>>>> can use than it is to obscure the return type for the sake of
>>>>>> some philosophical ideal of increasing encapsulation.
>>>>>
>>>>> Part of the art of API design is to hide implementation where it's not necessarily needed. Designers might err on the side of hiding things, because how you expose something is important as it has to be maintained indefinitely. If they expose everything then the internals can never be redesigned for better performance, etc.
>>>>
>>>> They don't increase encapsulation. The public members of a voldomort type are still public, you still have to code to the API of the return type whether it's a regular or voldomort type. You can keep as much private or public in either case as you like.
>>>>
>>>> All they do take the typename out of circulation, they make life harder for the user. There's no benefit. None.
>>>>
>>>> But at least the library author can stroke his chin a feel smug that there's one less type in the modules' namespace.
>>>
>>> Totally missing the point. The crux of the matter is this: changing a voldemort type (assuming the public semantics are the same) is not a breaking API change, because no-one else's code ever names it.
>>
>> Seriously? You cant have a public API and private implementation with a regular type? That's something specific to voldomort types?
>>
>> Ask yourself what exactly do voldomort types enable you to hide that cant be hidden with a regular type? Just one thing. Their name. As you said no one else can ever name the type.
>>
>> That is no benefit to me the user. No-one has been able to even describe a benefit. Walters article on Dr Dobbs doesn't describe a benefit. It "increases encapsulation" you all squawk.
>>
>> No it doesn't. The private bits are still private, the public bits are still public.
>>
>> All it does is complicate the user side.
>>
>> Its the emperor's new clothes.
>
> It's not possible to construct a voldemort type outside of the function where it was declared, and you can't know what that type is, just what the API is. You can force type deduction so the type returned can be changed without breaking code, so long as the API is the same. That's how it increases encapsulation.

voldemort types sort of feel like a hack to work around the lack of real compile-time interfaces(concepts,) the same thing IMO currently plaguing template constraints and honestly causes a lot of compiler errors to be confusing.

I believe a few major patches in phobos were related to removing constraints and rewriting them as static asserts for better error handling.

see:

http://forum.dlang.org/thread/jronroxajqkrqitxwzlj@forum.dlang.org

On Thursday, 19 March 2015 at 23:02:07 UTC, w0rp wrote:
>
>>
>> No it doesn't. The private bits are still private, the public bits are still public.
>>
>> All it does is complicate the user side.
>>
>> Its the emperor's new clothes.
>
> It's not possible to construct a voldemort type outside of the function where it was declared, and you can't know what that type is, just what the API is. You can force type deduction so the type returned can be changed without breaking code, so long as the API is the same. That's how it increases encapsulation.

Ok I can see the benefit of having a return type that can only be constructed by the function returning it. ***In some cases***

But being able to change the return type doesnt actualy increase encapsulation. you still have to return something with the same public API. Only now you have ***less*** guarantees over what your getting than you did before. Could be an array could be a linked list. Who knows?

Maybe I'm a bit long in the tooth but for something like cvsReader I want an array of records, there's isnt anything else that would ever make any sense. So the idea that I now how to jump through hoops to keep hold of whatever that function returns, just in case some divvy might want change what kind of structure it returns one day, is frankly absurd.

On Thursday, 19 March 2015 at 20:43:55 UTC, Almighty Bob wrote:
> Its the emperor's new clothes.

Type inference is useful. Deal with it.

On Friday, 20 March 2015 at 00:30:25 UTC, deadalnix wrote:
> On Thursday, 19 March 2015 at 20:43:55 UTC, Almighty Bob wrote:
>> Its the emperor's new clothes.
>
> Type inference is useful. Deal with it.

I like type inference.

I dont like voldomort types, the cost/benefit is fail.

Andrei Alexandrescu:

> You may want to answer there, not here. I've also posted a response.

There is this, with an attach:
https://issues.dlang.org/show_bug.cgi?id=11810

Bye,
bearophile

On Wednesday, 18 March 2015 at 18:48:59 UTC, bachmeier wrote:
> On Wednesday, 18 March 2015 at 15:13:24 UTC, jmh530 wrote:
>
> You might be able to download the zip here:
>
> https://bitbucket.org/bachmeil/dmdinline/downloads
>
> and then install from a USB disk using install_local.

I ended up trying this on my home computer because it makes life much easier.

The Debian file I was trying to get for libgretl-dev was a package rather than the source, I think, and I couldn't find the source or any sort of Windows version. Anyway commands like
> install_librtod2(gretl="usr/lib/libgretl-1.0.so", libr="usr/lib/R/lib/libR.so")
don't make much sense as .so is only for linux. I tried it anyway and got an error about the cd command not being found (wasn't the error I expected, but oh well).

I seem to be able to import the dmdinline library just fine. When I run
compileD("foo", txt)
I get

Error in file(filename, "r", encoding = encoding) :
  cannot open the connection
In addition: Warning message:
In file(filename, "r", encoding = encoding) :
  cannot open file 'C:/Users/John/Documents/.rtod2/config.R': No such file or directory

I don't know where the config.R file is located.