On Wednesday, 18 March 2015 at 02:00:40 UTC, bachmeier wrote:
> Unfortunately there is little documentation (though I'm working on that). I only use Linux but I would be happy if someone that knows Windows would find that it works there.

Work machine's firewall isn't letting me run install_bitbucket, which doesn't surprise me as I can't get anything like bitbucket/git or whatever to work. I can try it on my home machine when I have time. I can tell that it might be a little challenging to get libgretl1-dev installed. The gretl sourceforge's Windows page only has zips and binaries. I found the Debian source, so I might try making it with Cygwin and see if that works.

I'm sorry to disrupt the conversation, but I feel like I should weigh in since I'm a user the original critic felt D should be attracting. I'm a CS undergrad doing my graduation project in D, and the only other languages I worked with seriously were Python and Java(For personal projects and coursework respectively). I actually knew about D a couple of years ago and I wanted to try it because I saw the nice features and wanted to use them for something, and only recently I got a chance to use it seriously.

I was put off at first(when I learned about it) because the rhetoric was that you need to be a serious programmer to use D, it's not for hobbyists. I dove into it anyway a couple of months ago because the code snippet on the old page showcased some stuff I wanted to try using and I thought they were cool. I don't think I've ever enjoyed programming as much as I did with D. Anything that I needed to do was doable. It's only been a few months programming with it and already I feel very comfortable using it. This is despite the various bugs and weird api design choices of the standard library.

It's only when I actually started seriously programming with it that I actually got a feel for it's features and how they were supposed to be used. This is where it differs from Go as far as I can tell from this thread. I learned D just by doing what I wanted to do in it, and looking up any features I needed or wanted when I wanted to use, and 99 times out of 100 I found them.

This should be how D is sold. It has a higher learning curve than Go or Python, but in the end you can use it in a style you're comfortable with whether you come from C, Java, Haskell, Lisp, whatever.

On Wednesday, 18 March 2015 at 13:27:54 UTC, CraigDillabaugh wrote:
> clip
>
>>> Bearophile,
>>>
>>> You said that "Unfortunately" this thinking is going out of style "for good reasons".   I am confused (sorry, I am at work, and didn't have time to watch the 1+ hour video you linked to - maybe some clues were there)!
>>>
>>> I often find myself feeling a bit like Elazar.  Not long ago I wrote some Python code using a bunch of the functional style programming tools and I was very please with the very concise code I had generated.  Then, I had to make some modifications to the code. It took me an inordinate amount of time just to figure out what the code was doing, and I had written it myself just a few days earlier!
>>>
>>> Craig
>>
>> Maybe your years of practice and deep familiarity with imperative code patterns - both general and individual to yourself - might have skewed the result somewhat.
>>
>> It seems to me that much of practical programming is about having set up "quick paths" in your brain for recognising and manipulating common patterns. There's a big gap between understanding something intellectually and understanding something intuitively.
>
> There is quite possibly something too that, and as I imagine
> with more functional experience it will come easier to me.
>
> However, I still think imperative code is generally easier to
> reason about because (usually) each line of code is performing
> a single task, whereas with functional coding the goal seems
> to be to cram as many operations as possible into a single line
> (I know that isn't the real reason, it just seems that way at
> times).  Trying to 'unroll' everything in your head can be a
> challenge.  Throw in a lambda function or two with
> the mess of braces/symbols and then you have a real puzzler.

Careful formatting is really important for long UFCS chains using lots of lambdas etc. in D for exactly this reason. It's very easy to go "ooooooo, that's so neat, it's all one 1 line!" but it's often better to spread it out to make the semantics more obvious.

On 2015-03-17 08:15, Walter Bright wrote:

> When Voldemort types are returned, they must be by auto. The user isn't
> supposed to know what the return type is, just how to use it.

I still don't like that there's no good way to describe the API. It's not possible to put a name (that can be used in code, or reference in the documentation) on an API like this. Something like this would be nice:

constraint InputRange (E)
{
    E front();
    void popFront();
    bool empty();
}

InputRange!(int) result = [1, 2, 3, 4].map(e => e * 2);

-- 
/Jacob Carlborg

On 2015-03-16 04:25, deadalnix wrote:

> Compiling an hello world is almost instantaneous as far as I experienced
> it. I do think it is interesting for you to share your setup so we can
> understand what is going on and avoid for another newbie to have the
> same experience.

It's most likely linking that takes most of the time. I think most users will just run the compiler (including the linking) and time it. Most won't care if it's the compile time or link time that is slow.

-- 
/Jacob Carlborg

On Friday, 13 March 2015 at 04:49:38 UTC, Walter Bright wrote:

>
> Google does abandon significant projects now and then, such as this one:
>
> http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html

In fairness pretty much everything that was on google-code has moved, mostly to GitHub. E.g. for Go stuff see https://github.com/golang

On 3/18/15 4:53 AM, Elazar Leibovich wrote:
> On Friday, 13 March 2015 at 17:31:09 UTC, Andrei Alexandrescu wrote:
>>
>> For example the expression (assuming s is e.g. a string)
>>
>>   File("/tmp/a").byChunk(4096).joiner.startsWith(s)
>>
>> opens a file, progressively reads chunks of 4KB, stitches them
>> together at no cost, compares against a prefix until it makes a
>> decision, then closes the file and returns the result. A putative Go
>> user wouldn't even dream of using HasPrefix directly on a stream
>> coming from a file; the whole endeavor would be a function that
>> painstakingly takes all of these steps by hand.
>
> I personally, would have no idea what this piece of code is doing
> upon first sight. I'll have to look at the documentation of
> at least two functions to understand that, and I'll have to
> think carefully about what and who would throw in case of an error.

Yah, that's a problem with documentation. Such idioms should be well known.

> Something like
>
>      while (n != EOF) {
>          n = read(fd, buf, sizeof(buf));
>          if (n==-1) throw(...);
>          if (strcmp(buf, PREFIX) == 0) {
>               return buf;
>          }
>      }
>      return NULL;
>
> Requires no prior knowledge, and have similar effect.

And doesn't work. The code that works is a fair amount less trivial than that, and actually needs to do pretty much what the algorithms do.

> I'd rather have a loop written by hand in my production code any day,
> so that when debugging it, and reading it I'll have easier time
> to understand it, even though it would cost me a few more lines
> when writing the code.

No.

> What if this pattern repeats a few times in the code?

So much the better.

> I'd rather have a single function that have the explicit loop than
> having this pattern in slight variations spread in the code.

No.

> Writing code is easy, maintaining it afterwards is costly.

Agreed but works against your point.


Andrei

On Wednesday, 18 March 2015 at 15:13:24 UTC, jmh530 wrote:
> On Wednesday, 18 March 2015 at 02:00:40 UTC, bachmeier wrote:
>> Unfortunately there is little documentation (though I'm working on that). I only use Linux but I would be happy if someone that knows Windows would find that it works there.
>
> Work machine's firewall isn't letting me run install_bitbucket, which doesn't surprise me as I can't get anything like bitbucket/git or whatever to work. I can try it on my home machine when I have time. I can tell that it might be a little challenging to get libgretl1-dev installed. The gretl sourceforge's Windows page only has zips and binaries. I found the Debian source, so I might try making it with Cygwin and see if that works.

I'd greatly appreciate hearing about your experiences. I was lost when I tried it on Windows, but then I don't have any experience developing on Windows (that was a big part of why I moved to Linux). Technically, the gretl dependency isn't needed, but it's got such a nice interface to the matrix algebra and regression routines.

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.

On Wednesday, 18 March 2015 at 11:53:06 UTC, Elazar Leibovich wrote:
> On Friday, 13 March 2015 at 17:31:09 UTC, Andrei Alexandrescu wrote:
>>
>> For example the expression (assuming s is e.g. a string)
>>
>>  File("/tmp/a").byChunk(4096).joiner.startsWith(s)
>>
>> opens a file, progressively reads chunks of 4KB, stitches them together at no cost, compares against a prefix until it makes a decision, then closes the file and returns the result. A putative Go user wouldn't even dream of using HasPrefix directly on a stream coming from a file; the whole endeavor would be a function that painstakingly takes all of these steps by hand.
>
> I personally, would have no idea what this piece of code is doing
> upon first sight. I'll have to look at the documentation of
> at least two functions to understand that, and I'll have to
> think carefully about what and who would throw in case of an error.
>
> Something like
>
>     while (n != EOF) {
>         n = read(fd, buf, sizeof(buf));
>         if (n==-1) throw(...);
>         if (strcmp(buf, PREFIX) == 0) {
>              return buf;
>         }
>     }
>     return NULL;
>
> Requires no prior knowledge, and have similar effect.
>
> I'd rather have a loop written by hand in my production code any day,
> so that when debugging it, and reading it I'll have easier time
> to understand it, even though it would cost me a few more lines
> when writing the code.
>
> What if this pattern repeats a few times in the code?
>
> I'd rather have a single function that have the explicit loop than
> having this pattern in slight variations spread in the code.
>
> Writing code is easy, maintaining it afterwards is costly.

I don't want to come off as rude, but your response sounds like someone who has little to no experience with functional programming(i.e, a C background given your example.)

One of the major ways D parts with the C-family is it has a strong foothold in functional programming and blends it together extremely well. IMO using D like a better C is hurting only yourself - functional programming is great. : )

On Wednesday, 18 March 2015 at 16:26:44 UTC, Bayan Rafeh wrote:

> I don't think I've ever enjoyed programming as much as I did with D. Anything that I needed to do was doable. It's only been a few months programming with it and already I feel very comfortable using it.

I'm with you. Although Guile Scheme is still my favorite language, working with D has been the most fun I've had with a programming language, and I've tried dozens of languages over a period of almost thirty years.

> It's only when I actually started seriously programming with it that I actually got a feel for it's features and how they were supposed to be used. This is where it differs from Go as far as I can tell from this thread. I learned D just by doing what I wanted to do in it, and looking up any features I needed or wanted when I wanted to use, and 99 times out of 100 I found them.

Same for me. When using C, I find myself saying, "I want to do X" for many different values of X. There's always a reason you can't do X. In D I start with the assumption that I can do anything that comes to mind. When using Go, there's a lot of stuff you can't do, but there's only one reason you can't do it. Because the Go team thinks anyone wanting do it doesn't know how to program.

> This should be how D is sold. It has a higher learning curve than Go or Python, but in the end you can use it in a style you're comfortable with whether you come from C, Java, Haskell, Lisp, whatever.

I would characterize it more as a longer learning curve than a higher learning curve. It's not like C++ where you have to master so much complicated sh*t in order to use the language. One of the first things I was told to do when I started with C++ was learn Boost. Bjarne Stroustrup has complained that Boost is excessively complicated, and a beginner's supposed to learn it? You don't get that with D. It was probably six months before I even bothered to learn D's templates. I have seen so many times "big language" and "complicated language" used interchangeably wrt D. It's a big language but not a complicated one IMO.