On Monday, 6 June 2016 at 19:55:53 UTC, DLearner wrote:
> 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).

And when real-world money is involved, you'd better have arithmetic
overflow trigger an exception, not just wrap around silently.

On Mon, Jun 06, 2016 at 09:23:05AM +0100, Russel Winder via Digitalmars-d wrote:
> On Mon, 2016-06-06 at 06:24 +0000, Mithun Hunsur via Digitalmars-d wrote:
> > […]
> 
> > The problem is that D is targeted as a multi-paradigm systems programming language, and while it's largely successful at that, the GC doesn't fit in with that domain by nature of its existence.
> > 
> > There's no problem with _having_ a GC, it just shouldn't be the default case for what's meant to be a systems language, especially when language and standard library features become dependent upon it.
> 
> No. As evidence I give you Go. The whole "it's a systems programming language so it cannot have GC" is just so wrong in 2016 (as it was in 2004). Having a GC for a time critical real-time streaming application is probably a bad idea, so turn GC off for that. D can do that.
> 

Go is the perfect example here. The traction that Go has and D has not doesn't come from GC
or not, it comes from accessible documentation, easy installation, good libraries and community support.

New developerse will give a language 10-60min max, if it is compelling and you feel productive and decently fast then you are set.

sure there are outlines where you watn to replace C++ or C, but those areas are much harder to get traction on due to dependencies in the existing architecture and a (correctly so) risk-aversity.

On Monday, 6 June 2016 at 15:06:49 UTC, Carl Vogel wrote:
> (...) Also, the idea that more people will adopt D if you just "get rid of the GC" ignores the fact that you don't just "get rid of the GC," you replace it with another memory management scheme (manual, RAII, RC). If you replace all the parts of the language and phobos that rely on GC with, e.g., a poor implementation of RC, then you're just going to get another round of complaints, and no real adoption.

I think you are going to get some adoption it you replace good GC with clunky RC.
The key difference is a call to a function that uses GC is incomplete: some of it will execute later, after the call has finished.
On the other hand a call to an equivalent function that uses RC has only local (in time) consequences: once you finished the call, it stopped executing. If it returned something that needs to be freed later, you know what it is.
Of course people can write arbitrarily messed up things like singletons etc. but I'm not counting those because good libraries are usually free of those.
This means you have control over all the OTHER code, however inefficient the call is.
Hence, the second is acceptable in low-latency code, but the first is not.

On 6/6/2016 12:44 PM, Satoshi wrote:
> 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++

More complex? Wow!


> * 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.

C++ for junior programmers is easier? Wow!

> * Not everyone is interested in programming, sometimes people are doing it just
> for money.

On 6/6/2016 11:36 AM, 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.  And part of
> the reason for that is that if you compare "3.499" to "3.501"
> (as the originally computed numbers) when only 2 sig figs
> should be in play, they must compare equal.  This is very much
> unlike what happens with binary floating point, where exact
> comparisons are rarely possible due to low-order bit differences.
> In commercial decimal-arithmetic applications (think "money"),
> the low-order bits are supposed to be discarded for almost all
> values that actually represent an amount of currency.  For
> reliability of the application, this has to be built into the
> data type, not dependent on programmer vigilance.  That is,
> just like certain other language features, a decimal type
> without implicit truncation would be thought of as "doesn't
> scale well".

What I've done, though I know that I won't convince any users of BigDecimal, is use longs and have them represent pennies instead of dollars. Then they're all exact to two places.

On Monday, 6 June 2016 at 20:33:14 UTC, Walter Bright wrote:
> On 6/6/2016 12:44 PM, Satoshi wrote:
>> [...]
>
> More complex? Wow!
>
>
>> [...]
>
> C++ for junior programmers is easier? Wow!
>
>> [...]

Most learn C++ in college. So they have a 'headstart'

On Monday, 6 June 2016 at 20:35:26 UTC, Walter Bright wrote:
> What I've done, though I know that I won't convince any users of BigDecimal, is use longs and have them represent pennies instead of dollars. Then they're all exact to two places.

I loaned out my copy of TDPL, so I don't have it nearby to
check, but if that's your approach, you need to ensure that
your underlying integral type is *always* 64-bits, not 32-bits.
The reason is that otherwise, you've just limited your apps
to handling a maximum amount of $21,474,836.48.  But banks
can accept checks up to $99,999,999.99 (yes, they do have
a limit, or at least they used to when I was working in that
field).

On Monday, 6 June 2016 at 20:56:04 UTC, Observer wrote:
> On Monday, 6 June 2016 at 20:35:26 UTC, Walter Bright wrote:
>> What I've done, though I know that I won't convince any users of BigDecimal, is use longs and have them represent pennies instead of dollars. Then they're all exact to two places.
>
> I loaned out my copy of TDPL, so I don't have it nearby to
> check, but if that's your approach, you need to ensure that
> your underlying integral type is *always* 64-bits, not 32-bits.
> The reason is that otherwise, you've just limited your apps
> to handling a maximum amount of $21,474,836.48.  But banks
> can accept checks up to $99,999,999.99 (yes, they do have
> a limit, or at least they used to when I was working in that
> field).

Silly me, I meant $21,474,836.47, of course.

On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote:
> * Let's wait for the "herd effect" (corporate support) to start.

We should make a Slack community and another kind of forum like this one http://elixirforum.com/.

They make really easy for starter to learn or question anything related to D.

On Monday, 6 June 2016 at 19:43:13 UTC, qznc wrote:
> 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.

Same here. I'm perfectly fine with the tools and docs as they are now, they wouldn't make my top 20 priorities. It's a common complaint, and therefore this must be important for other people, but I just don't get it. Conversely, Go is usually brought up as an example of a language with good tools. I've written some Go and I also don't understand what people mean when they say that. Why are they good? What's easier?

This thread itself has had multiple people say that Phobos lacks proper examples of usage, which is the exact opposite of what I'd say. I'd rather have runnable documentation (unit tests) than static-could-be-lying-cos-it-hasn't-been-updated docs any day of the week and twice on Sundays.

I read TDPL cover-to-cover in an afternoon, started writing code and never looked back. Conclusion? I'm weird.

Atila