On Monday, 6 June 2016 at 18:47:25 UTC, Karabuta wrote:
> On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote:
>> [...]
>
> Tutorial, tutorials, tutorials ....
>
> Serach youtube for D tutorials and you will find none that is helpful to many people. Check rust tutorials, yeah .... JavaScript tutorials, abundance. Go tutorials, plenty..... Java tutorials, yeah.
>
> Clearly there seem to be a problem with tutorials.

For instance, Apple pretty posted a great series of tutorials within a week (days?) of launching Swift.

On Monday, 6 June 2016 at 18:36:37 UTC, Observer wrote:
> It's more complicated than that.  Part of what you need is to
> be able to declare a variable as (say) having two significant
> fractional digits, and have the rounding rules be implicitly
> applied when saving to that variable, producing an exact
> representation of the rounded result in storage.

Yes, but if you want accurate representation of two fractional digits on storage only, then it makes most sense to do all calculations on cents (scale everything by 100) and store as integers.

On Monday, 6 June 2016 at 18:55:22 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 6 June 2016 at 18:36:37 UTC, Observer wrote:
>> It's more complicated than that.  Part of what you need is to
>> be able to declare a variable as (say) having two significant
>> fractional digits, and have the rounding rules be implicitly
>> applied when saving to that variable, producing an exact
>> representation of the rounded result in storage.
>
> Yes, but if you want accurate representation of two fractional digits on storage only, then it makes most sense to do all calculations on cents (scale everything by 100) and store as integers.

That's only a workaround.  It's probably best to think of decimal
arithmetic as an accountant would, not as a computer geek would.
Intermediate arithmetic results should perhaps also be rounded/
truncated, though it depends on the particular calculation.  For
instance, I might have an interest percentage that gets carried
to 4 sig figs (fractional digits), but when applied to a currency
amount with only 2 sig figs, the result should end up with 2 sig
figs, not 6.  And then that result should continue to be used in
later arithmetic in the same larger expression, even without an
explicit save operation to invoke the rounding/truncation.  If
you tried this using float for the percentage and integer for
the amount, once the conversion to float happened it would not
revert in the middle of the expression.

Also, keeping values as only integers complicates input/output
formatting.  I want 123456 pennies to show up as either 1234.56
or perhaps 1,234.56 (at least, I want that punctuation in a U.S.
locale), and this should happen without my needing to manually
rescale during i/o operations.

On Monday, 6 June 2016 at 19:30:52 UTC, Observer wrote:
> Also, keeping values as only integers complicates input/output
> formatting.  I want 123456 pennies to show up as either 1234.56
> or perhaps 1,234.56 (at least, I want that punctuation in a U.S.
> locale), and this should happen without my needing to manually
> rescale during i/o operations.

You can solve all these things with static typing, unless you want to vary the number of significant decimals at runtime. (well, you can then as well, but need 2 values)

On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote:
> * Hiring people who know D is a problem.
>
> * Documentation and tutorials are weak.
>
> * There's no web services framework (by this time many folks know of D, but of those a shockingly small fraction has even heard of vibe.d). I have strongly argued with Sönke to bundle vibe.d with dmd over one year ago, and also in this forum. There wasn't enough interest.

All three of those are affected by documentation and tutorials. From this list, this seems to be the biggest issue.

Personally, this is surprising to me. I have read lots of complaints here in the forum, but I never experienced it myself. I think my first contact with D was in 2009 or 2010 and the documentation was certainly not better then. My conclusion is that I'm not normal. This also means I have a hard time to see where it should be improved.

On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote:
> Andrei posted this on another thread. I felt it deserved its own thread. It's very important.
> -----------------------------------------------------------------------------
> I go to conferences. Train and consult at large companies. Dozens every year, cumulatively thousands of people. I talk about D and ask people what it would take for them to use the language. Invariably I hear a surprisingly small number of reasons:
>
> * The garbage collector eliminates probably 60% of potential users right off.
>
> * Tooling is immature and of poorer quality compared to the competition.
>
> * Safety has holes and bugs.
>
> * Hiring people who know D is a problem.
>
> * Documentation and tutorials are weak.
>
> * There's no web services framework (by this time many folks know of D, but of those a shockingly small fraction has even heard of vibe.d). I have strongly argued with Sönke to bundle vibe.d with dmd over one year ago, and also in this forum. There wasn't enough interest.
>
> * (On Windows) if it doesn't have a compelling Visual Studio plugin, it doesn't exist.
>
> * Let's wait for the "herd effect" (corporate support) to start.
>
> * Not enough advantages over the competition to make up for the weaknesses above.


(I'm work as a C/C++ programmer for military sector in the area of the information and communication infrastructure and electronic warfare)

When I told of D to my boss he had a couple of reasons why not to use D for development of our products.

* Backward compatibility with existing code.
* D is much more complex than C++
* Not enough tutorials and solved problems in D on stack overflow (LOL)
* We have problem to recruit a good C++ not a good D programmer. (1/100 is good)
* My boss does not have free time to learn new things...
* Using GC is strictly prohibited in realtime apps. And D does not have an compiler supported ARC
* D without GC or ARC is not powerful as it can be.
* More and more people are dumber, we must write our programs for later re-usage by any junior what we must employ. C++ is in this way much more easier than D, cuz you know what every line of your program do. Employ C++ junior programmer and let him to learn D and then work on our projects is not a good (and cost-effective) idea.
* Not everyone is interested in programming, sometimes people are doing it just for money.

On Monday, 6 June 2016 at 19:30:52 UTC, Observer wrote:
> On Monday, 6 June 2016 at 18:55:22 UTC, Ola Fosheim Grøstad wrote:
>> On Monday, 6 June 2016 at 18:36:37 UTC, Observer wrote:
>>> It's more complicated than that.  Part of what you need is to
>>> be able to declare a variable as (say) having two significant
>>> fractional digits, and have the rounding rules be implicitly
>>> applied when saving to that variable, producing an exact
>>> representation of the rounded result in storage.
>>
>> Yes, but if you want accurate representation of two fractional digits on storage only, then it makes most sense to do all calculations on cents (scale everything by 100) and store as integers.
>
> That's only a workaround.  It's probably best to think of decimal
> arithmetic as an accountant would, not as a computer geek would.
> Intermediate arithmetic results should perhaps also be rounded/
> truncated, though it depends on the particular calculation.  For
> instance, I might have an interest percentage that gets carried
> to 4 sig figs (fractional digits), but when applied to a currency
> amount with only 2 sig figs, the result should end up with 2 sig
> figs, not 6.  And then that result should continue to be used in
> later arithmetic in the same larger expression, even without an
> explicit save operation to invoke the rounding/truncation.  If
> you tried this using float for the percentage and integer for
> the amount, once the conversion to float happened it would not
> revert in the middle of the expression.
>
> Also, keeping values as only integers complicates input/output
> formatting.  I want 123456 pennies to show up as either 1234.56
> or perhaps 1,234.56 (at least, I want that punctuation in a U.S.
> locale), and this should happen without my needing to manually
> rescale during i/o operations.

Entirely agree.
Scaling everything internally to force things to integers, and then re-scaling on output is just bending the language because it cannot properly address the problem.  The result is just creating something more to go wrong - consider large accounting program maintained over several years, not always by original author.

If we allow _int foo;_ to declare an integer variable foo, then suggest we have
_dec bar(a,b);_ to declare a decimal variable bar with a units in total length, b units of decimal places.
D language then defines how (for example) assignment is carried out (by default), and also provides mechanisms for alternatives (ie some sort of dec_trunc() and dec_round() functions).

On Monday, 6 June 2016 at 08:42:55 UTC, Russel Winder wrote:
> On Mon, 2016-06-06 at 06:50 +0000, poliklosio via Digitalmars-d wrote:
>> 
>> […]
>
>> Please, elliminate GC.
>
> Let's not. It is a USP against C++ and Rust. It forges a new route to traction, cf. Go, Java, etc.

I should have been more specific here. I mean I want to elliminate GC in my code. I don't mind if you or anyone else uses GC. Even I use GC languages when writing things like scripts, so I'm not a no-GC-because-I-say-so person.

Is it a unique selling point (USP) against C++ or Rust? I don't think so. People who use the GC languages for business/scientific apps don't care what is behind the scenes. Also, the relationship between GC and productivity is a subtle point that requires some CompSci background to grasp. I think D is far too complicated to be marketed as even simpler than python or Go. Low-latency people do care what is behind the scenes and they understandably want no GC. That leaves high-performance high-latency people. If you think you can find a niche there, fair enough, otherwise its not a USP.
D's power is in its native-but-productive approach. This is an improvement in C++ niches, not a simplified language for banging end-user apps.

>> This also hurts the open source community. Why would I
>> write/opensource a high performance library if I know that
>> projects like AAA games are not going to use it anyway due to GC
>> in D? On the other hand if I can write a library that guarantees
>> to not use and not need garbage collector then even C and C++
>> projects can use it.
>> With GC, D doesn't play nice with existing C/C++ code.
>
> There may be some instances where this is the case. Let them use C++ or Rust. Fine. If AAA games people want C++ they will use C++, for D they are a lost market.

Why would they not use D? D is a much better language for them as well. To give some examples, in C++ code there is a ton of boilerplate, while D code hardly has any. Also, the number of bugs in a D program is smaller due to easier unittesting. Also, templates don't cause day-long stop-and-learn sessions as in C++. I don't think those people are a lost market.

> And anyway D has a GC if you want and a no-GC if you want. Thus this is not actually an issue anyway.

This is a big issue now due to lack of a comprehensive guide, as well as holes in the language and phobos (strings, exceptions, delegates). C++ doesn't have those holes.

On Sun, Jun 05, 2016 at 07:20:52PM -0700, Walter Bright via Digitalmars-d wrote:
> Andrei posted this on another thread. I felt it deserved its own thread. It's very important.
> -----------------------------------------------------------------------------
> I go to conferences. Train and consult at large companies. Dozens every year, cumulatively thousands of people. I talk about D and ask people what it would take for them to use the language. Invariably I hear a surprisingly small number of reasons:

>From my personal perspective:
 - Compiler bugs are a real issue. At one point I had to have a dev-build of DMD around.

> * The garbage collector eliminates probably 60% of potential users right off.

 - If you think as  a C++ competitor you are right, I personally think D is more a Python
   competitor. I think about it as Python in fast. Or "GO" with better C compatibility. So
   I consider it more a glue language than trying to compete with the lowest layer of an architecture (C++)
   which creats a lot of architectual dependencies to change it.

> 
> * There's no web services framework (by this time many folks know of D, but of those a shockingly small fraction has even heard of vibe.d). I have strongly argued with Sönke to bundle vibe.d with dmd over one year ago, and also in this forum. There wasn't enough interest.

 - Yes please

 - Debian/Fedora packages for DMD, LDC, GDC, should be a one click away to get stuff installed.

 - Better libraries. Like "batteries" included. Like a proper DB interface is missing for example,
   besides that it's already a great tool for glueing stuff together in fast.

   - Other missing things: nice HTTP api that is not curl, but easier. Protbuf/Thrift integration (thrift exists).


Just my 2cents,

On Monday, 6 June 2016 at 10:54:41 UTC, Guillaume Piolat wrote:
> On Monday, 6 June 2016 at 08:18:20 UTC, Russel Winder wrote:
>> (...)
>> This should be marketed as a major feature of D: the language with a GC for those situations where you want it, and manual memory management for those cases where you do not want a GC.
>
> Having the GC for the UI is very pleasant, while @nogc time-critical code won't use it.
>
> It think the problem is that the message then become more complicated.
> GC is easily victim of the "holier-than-thou" fallacy, because evidently less GC is supposed to translate into faster programs. Er... right?

I'm just worried how usable this approach really is at scale. If you combine 20 D libraries, 17 of which use GC, are you able to control the GC well enough for a low-latency app? The problem with GC is that its a global (per process) resource so it poisons everything in the program with its unpredictable time consumption. I would be hesitant to market this without designing and testing a viable development methodology first. And then there is reference counting which is another way to be productive that doesn't have this problem.