On Sunday, 15 December 2013 at 04:50:20 UTC, Walter Bright wrote:
> Back when there was only one D compiler, people said they wouldn't use it because there was only one. Now people won't use it because there are 3.

Not quite, I think people were unhappy because it wasn't fully open source back then. I am currently (possibly being wrong) perceiving the current D-compiler community to be fragmented. In the same sense that BSD is fragmented. Linux isn't fragmented, and stronger because of it, there is one authoritative kernel and some minor spin-offs. Compilers are usually never 100% compatible so having one dominating compiler that "everybody" use is beneficial.

> Essentially, if you want to find a reason not to use D, you'll find one. But if you want to use D, there are lots of reasons to.

Actually, I wouldn't track dlang.org for years if I wasn't looking for a reason to use it. I do try it from time to time, but it never fits the things I want it to do, because D like Go is claiming to be a better C, but is not giving me the level of control I want. And I really do want a better C/C++, if for no other reason than that header files sucks.

In general I think programming languages get traction, not because they are good languages, but because they are best-fit for a particular application domain. So I think a language like D would benefit from being the best "modern" solution in one particular area, like embedded programming.

When creating a programming environment it is important to realize that human brains are bad at logic, dog slow, it cannot do it. It does approximations to logic, the approximations are worse when you get noise into the system. When you are programming the brain is more or less saturated constantly and stutters because information is relayed in and out of "working memory" (which is a fuzzy process and a source of errors). However, the brain has very powerful "hardwired" spatial/visual subsystems with spatial mapping and classification that work very well if the visual patterns are distinct and tailored to the kind of "visual fields" that you see in landscapes/faces etc which it has be evolved to deal with. You want to utilize that to it's fullest potential. In c++ some symbols are very easy to detect, like "::" and "[", you don't have to think to classify spatial areas where those visual constructs occur as regions of namespacedness and arrayish, because they are not used for other things. So you can train the subconscious cognitive pattern to correctly classify them without doing any resolution. There is a reason for why road signs differ in shape, colours and have very distinct silhouettes as symbols, it supports recognition without disturbing the conscious parts of the brain that deals with avoiding danger while driving. The moment you have to think about what a sign means you are much more likely to make errors, which while driving can be fatal. When programming it isn't fatal, but you get more bugs, or become slower.

IIRC Manu thinks that it is better to have "{" on a separate line. Is he correct? Yes, in terms of pattern recognition he is. Visual marks that are surrounded by open space is more likely to be correctly grouped, detected and visually classified. If you use the Egyptian style you basically don't rely on the braces as symbols to the same extent, you rely on line-detection of indentation. So you need larger indentation in order to establish horisontal lines. Why is that? Because the visual subsystems of the brain is hardwired to detect contours of objects/regions. If the indentation is too small the visual subsystems will fail to detect breaks in the vertical lines and will group nested blocks as one block, until the conscious parts of the brain says "no-no-wait" and has to resolve the error/ambiguity.

When programming in assembly programmers tend to do sketches on paper, why is that? Because that makes it possible for them to utilize the visual cognitive capabilities of the brain in addition to the dog-slow-quasi-logical-reasoning of the human brain. That creates a mental map of the program which assembly doesn

(No edit button? Posted by accident. :)

Continuing:

When programming in assembly programmers tend to do sketches on
paper, why is that? Because that makes it possible for them to
utilize the visual cognitive capabilities of the brain in
addition to the dog-slow-quasi-logical-reasoning of the human
brain. That creates a mental map of the program which assembly
doesn't support very well due to it's poor utilization of distinct visual cues and patterns. Assembly code is visually too uniform to "activate" visual cognition.

On Sunday, 15 December 2013 at 08:05:42 UTC, Philippe Sigaud wrote:
> On Sun, Dec 15, 2013 at 8:59 AM, Joseph Rushton Wakeling
> <joseph.wakeling@webdrake.net> wrote:
>> That's my Spanish program buggered, then.
>
> In Spanish D, we put ¡ *around* template instantiations: auto m =
> map¡(x => x+1)!(myRange);

   auto response = ¿(joke == good)? laughter : bulls;

:-)

On Saturday, 14 December 2013 at 19:46:36 UTC, Ola Fosheim Grøstad wrote:
> Do you think I am unfair?

I don't think it's a matter of fair or unfair.  If a use-case for D doesn't stand out for you, that's your call.

What I do think is that a lot of your arguments are either fairly abstract theoretical ones, or impressions based on a fairly limited amount of experience at a time when D was much less developed compared to where it is today.  Bear in mind you're speaking to someone who had a similar initial experience -- "Hmm, this seems pretty cool but doesn't give me the performance I need and get from C++, file it as 'one to watch'..." and has since come back to the language and used it extensively.  (For me it was the availability of a D2-supporting GDC in Ubuntu 12.04 that did it: ease of access combined with performance on par with C++.)

Your contention about fragmentation due to the 3 compilers is, I think, objectively false, however.  On the contrary, what differences there are have been continuously narrowing for the whole period of time that I've been actively using D, to the point where pretty soon the frontends of GDC, LDC and DMD will be 100% identical code.

Oh, and -- I can't see that rewriting the compilers to output to C++ would really be easier than just implementing better direct support for interfacing with C++ in the language.  It honestly just seems like a good way to introduce a new opportunity for difficulty in debugging performance issues.

Bottom line -- with any language there is a hurdle of initial use that has to be jumped before one can really evaluate its practical usefulness.  If what you see in D today doesn't convince you that it's worth trying to take that jump a second time, then that's your judgement to make.  But I think you might get more out of spending a couple of hours trying things out in a playful way, rather than writing long emails debating fairly abstract philosophical ideas and desires for the language.

TL;DR I don't think it matters whether you're fair to D or not, but it matters that you're fair to yourself in giving yourself the chance to properly assess what D can do for you today :-)

On Sunday, 15 December 2013 at 10:30:36 UTC, Joseph Rushton Wakeling wrote:
> Your contention about fragmentation due to the 3 compilers is, I think, objectively false, however.  On the contrary, what differences there are have been continuously narrowing for the whole period of time that I've been actively using D, to the point where pretty soon the frontends of GDC, LDC and DMD will be 100% identical code.

Ok, that is quite possible, but I that might also be the case for BSD… FreeBSD is probably on par with Linux, but it is still perceived as being part of a fragmented ecosystem. Open source projects that fragment tend to die, so I think people are a bit uneasy about that in general. I agree that it is a superficial measurement.

> Oh, and -- I can't see that rewriting the compilers to output to C++ would really be easier than just implementing better direct support for interfacing with C++ in the language.

If I write an engine in D and then want to port it to iOS…

> practical usefulness.  If what you see in D today doesn't convince you that it's worth trying to take that jump a second time, then that's your judgement to make.  But I think you might get more out of spending a couple of hours trying things out in a playful way, rather than writing long emails debating fairly abstract philosophical ideas and desires for the language.

Actually, my arguments are not philosophical. They are pragmatic.

D is not high level enough to be high level and not low level enough to give sufficient low level control.

I would want a C++-replacement to give me convinient access to hardware-level features such as transactional memory in the Haswell processor etc. Making 3 compiler backends support stuff like that seems a bit unrealistic.

> TL;DR I don't think it matters whether you're fair to D or not, but it matters that you're fair to yourself in giving yourself the chance to properly assess what D can do for you today :-)

Well, if it did support transactional memory and was more clearly dedicated towards low-level programming I would use it to have lock free concurrent programming in a relatively clean programming language.

O.

On 15/12/13 12:40, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>"@puremagic.com wrote:
> If I write an engine in D and then want to port it to iOS…

Again, better I think to create first-class iOS support in D itself.  The alternative you suggest really feels like sticking one's feet in the flames to get out of having to do a firewalk ... :-)

> Actually, my arguments are not philosophical. They are pragmatic.

I was thinking more of your remarks about the semantics/syntax of templates here, although I concede that there is a practical side to that as well.  I agree that e.g. your concerns over real-time control and the GC are pragmatic, but that's only one use-case.  If that's the use-case that matters to you, then fair enough.

> D is not high level enough to be high level and not low level enough to give
> sufficient low level control.

I don't think that your remarks about the low-level side really stand up to scrutiny.  You can go as low as you like, but admittedly this may currently involve having to avoid much of the existing library functionality.

> Well, if it did support transactional memory and was more clearly dedicated
> towards low-level programming I would use it to have lock free concurrent
> programming in a relatively clean programming language.

If that's the use-case you're looking for, fair enough.  What I was concerned with was whether you were overlooking other use-cases that might potentially benefit you, because while looking at D through the prism of "C++ replacement" is valid, it misses a whole load of other things one can do with the language.

Am Sun, 15 Dec 2013 09:55:23 +0100
schrieb "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dlang@gmail.com>:

> (No edit button? Posted by accident. :)

No, the forum is backed by a NNTP server which supports posting and downloading articles, but not editing. Deletion is technically possible, but currently only done by an administrator to remove spam as far as I can tell.

Thanks for your little explanation on why it is important to
support the brain's pattern recognition with the programming
language.
Other than that things have to be easy to type. E.g. BEGIN and
END. might be visually distinct, but { and } are shorter.
<[int]> jumps to the eye, but !int is more concise.

-- 
Marco

On Sunday, 15 December 2013 at 12:29:46 UTC, Joseph Rushton Wakeling wrote:
> Again, better I think to create first-class iOS support in D itself.  The alternative you suggest really feels like sticking one's feet in the flames to get out of having to do a firewalk ... :-)

Yes,  I thought that too for a while, in general, but then it turns out that C++ has kind of become a "portable source-level object format" which most new platforms are claiming support for. And new platforms keep coming in areas where you least expect them to. Like Chrome PNaCl for the web. So, it is a moving target. Not being able to generate C/C++ if you later decide to port is a lock-in unless the runtime is so minimal and simple that you can make do with generic LLVM IR…

> If that's the use-case you're looking for, fair enough.  What I was concerned with was whether you were overlooking other use-cases that might potentially benefit you, because while looking at D through the prism of "C++ replacement" is valid, it misses a whole load of other things one can do with the language.

I am looking for a language that let me do experimental realtime audio. C++ is not a good fit because of the "experimental" part suggest a clean language where you can quickly change the code. C++ is a bit verbose/tedious to be a good fit. There is nothing in D that prevents it from providing very clean low level support, but I sense that this is not the direction the language is going. I could be wrong though, maybe I'll give it a spin after new year. :)

O.

On 15 December 2013 23:25, <"Ola Fosheim Grøstad\" <ola.fosheim.grostad+dlang@gmail.com>"@puremagic.com> wrote:

> On Sunday, 15 December 2013 at 12:29:46 UTC, Joseph Rushton Wakeling wrote:
>
>> Again, better I think to create first-class iOS support in D itself.  The alternative you suggest really feels like sticking one's feet in the flames to get out of having to do a firewalk ... :-)
>>
>
> Yes,  I thought that too for a while, in general, but then it turns out that C++ has kind of become a "portable source-level object format" which most new platforms are claiming support for. And new platforms keep coming in areas where you least expect them to. Like Chrome PNaCl for the web. So, it is a moving target. Not being able to generate C/C++ if you later decide to port is a lock-in unless the runtime is so minimal and simple that you can make do with generic LLVM IR…
>
>
>  If that's the use-case you're looking for, fair enough.  What I was
>> concerned with was whether you were overlooking other use-cases that might potentially benefit you, because while looking at D through the prism of "C++ replacement" is valid, it misses a whole load of other things one can do with the language.
>>
>
> I am looking for a language that let me do experimental realtime audio. C++ is not a good fit because of the "experimental" part suggest a clean language where you can quickly change the code. C++ is a bit verbose/tedious to be a good fit. There is nothing in D that prevents it from providing very clean low level support, but I sense that this is not the direction the language is going. I could be wrong though, maybe I'll give it a spin after new year. :)
>

I think D can do this well. D has fairly nice stream constructs and algorithms, and also has reasonable out-of-the-box threading features. Audio involves so much bit-twiddling, I'd never want to do audio work in a non-native language!

I only worry about the garbage collector. Audio processing is my biggest
fear case when there is a GC involved that is known to execute
unpredictably, often taking a very long time in the rare event it does
execute.
More work, less often, is a workload pattern that is fundamentally
incompatible with realtime software.
Incidentally, this is a significant factor in the reasoning behind calling
for a community music-game side project. I'd like to prove it out.

On Sunday, 15 December 2013 at 14:43:45 UTC, Manu wrote:
> Audio involves so much bit-twiddling, I'd never want to do audio work in a non-native language!

True!

> I only worry about the garbage collector. Audio processing is my biggest
> fear case when there is a GC involved that is known to execute
> unpredictably, often taking a very long time in the rare event it does execute.

On OS-X there are at least two ways to do audio programming. The easiest is to use a large buffer and use a pre made AudioUnit. The low latency option is to write your own AudioUnit which is called as a callback by the kernel on a real time thread (20+ times per second) and communicate with this thread from the main program using CAS instructions to avoid race-conditions. I guess it doesn't matter too much if the main program is under GC if the called from the AudioUnit never is touched by GC and all objects transferred to the AudioUnit is not under GC.

Might be possible, depending on how GC works on OS-X with D.