This.

On Mon, 2016-06-06 at 13:07 -0400, Nick Sabalausky via Digitalmars-d wrote:
> 
[…]
> The games industry (with some exceptions) has a very deeply rooted
> mentality of "$$$ matters, everything else is teenagers hacking in
> their
> basement". Naturally leads to: "Rust -> Mozilla -> $$$ -> Valid" vs
> "D
> -> Volunteers -> Kids dinking around -> Worthless bullcrap".
> Honestly, I
> wouldn't even bother trying with that crowd. Let them circle the
> drain
> with their neverending spiral of ballooning-costs.
> 
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, 2016-06-06 at 22:38 -0700, H. S. Teoh via Digitalmars-d wrote:
> 
[…]
> A Decimal type isn't hard to implement as a user-defined type. I
> don't
> understand the obsession with some people that something must be a
> built-in type to be acceptable... user-defined types were invented
> for a
> reason, and in D you have the facilities of making user-defined types
> behave almost like built-in types in a way no other language I know
> of
> can.
> 
> Same thing goes with a fixed point type. People keep complaining
> about
> it, but honestly if I were in the finance sector I'd implement the
> type
> myself in a couple o' days and put it up on code.dlang.org or
> something.
> It's not *that* hard.
>

It is certainly the case that now there is the Dub repository, it is now feasible to think in terms of library solutions of things not in Phobos. Till then if it wasn't it Phobos it didn't exist.

Yes organizations can implement their own, but I bet they would think twice about putting it into the Dub repository.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tue, 2016-06-07 at 05:39 +0000, ketmar via Digitalmars-d wrote:
> 
[…]
> funny thing: those "financial sector" most of the time doesn't give anything back. adding special decimal type complicating the compiler and all backends. i myself never needed that for my whole lifetime (and this is more than two decades of programming, in various free and commercial projects).

Financial organizations generally want all their language infrastructure for free (GCC, Python, Eclipse) anything they write themselves is treated as asset and so theirs not for anyone else.

Show them PyPy is 30x faster than CPython for their use case but needs £50,000 to be production ready, and they carry on using CPython. (And waste millions of £s in staff time waiting for Python codes to finish.)

> i'd say: "you want it? DIY or GTFO."

That leads to them using Java, Scala, C++, C# and Python. Which they do.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tue, 2016-06-07 at 06:23 +0000, Andre Pany via Digitalmars-d wrote:
> 
[…]
> In my opinion passionate D developer will build the missing parts themselves. I also developed my own decimal library. But the developers starting with D and which rather want to build content instead of the missing parts won't. Also there is a much higher trust if a library is provided within phobos than provided from a single person in terms of long time support.

Forget Phobos, be agile: get your stuff out on GitHub and into the Dub repository early, announce it, get people using it and feeding back to improve it. Be first to market and get traction.

The evolution of Go, Rust, and Ceylon has been about library development not in the central library but in easily accessed and used third-party libraries. Yes the central library core is important, but the real development, and traction, action is outside that.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 6 June 2016 at 21:35:20 UTC, DLearner wrote:
> On Monday, 6 June 2016 at 20:19:20 UTC, Observer wrote:
>> And when real-world money is involved, you'd better have arithmetic
>> overflow trigger an exception, not just wrap around silently.
>
> Suggest as compiler option, default=on.

Full compiler-level support is not currently planned, but we've been working on library support for a while now, and it's almost ready:
    https://github.com/dlang/phobos/pull/4407
    https://code.dlang.org/packages/checkedint

It's not as fast as a built-in type could be, but still much faster than BigDecimal.

On Tuesday, 7 June 2016 at 08:21:23 UTC, Russel Winder wrote:
> On Mon, 2016-06-06 at 13:35 -0700, Walter Bright via Digitalmars-d 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.
>
> You are right, your use of integers (even 128-bit ones) will not convince anyone doing anything finance other than household accounting.

It is the same as base 10 floating point, with rounding to N decimals places, you just make the exponent part of the type. Making the exponent and rounding fixed is basically just an optimization where it is statically known.

Anyway, there is no point in having base 10 floating point part of the language unless you target hardware with base 10 floats.

There are already base 10 IEEE754-2008 implementations available for other languages that those in need can:

1. translate to D

2. unit test against the reference implementation

If well-funded industries like finance want it, they can easily do it.

This is quite different from say meta-programming, syntax, tooling, memory management and basic data types which are language related-issues, not small-scale funding issues.

On Tuesday, 7 June 2016 at 08:31:09 UTC, Russel Winder wrote:
> Financial organizations generally want all their language infrastructure for free (GCC, Python, Eclipse) anything they write themselves is treated as asset and so theirs not for anyone else.

So basically no advantage in having them use your tools?


> That leads to them using Java, Scala, C++, C# and Python. Which they do.

How does that benefit C++ if they never contribute anything?

On Tuesday, 7 June 2016 at 08:31:09 UTC, Russel Winder wrote:
> Financial organizations generally want all their language infrastructure for free (GCC, Python, Eclipse) anything they write themselves is treated as asset and so theirs not for anyone else.
...
> That leads to them using Java, Scala, C++, C# and Python. Which they do.

so let 'em use those languages. they will not return anything, thus i see no reason to care about their bussiness needs. i've never seen "this language is used in banking" to be used as the main reason for choosing one language over another (outside the banking, of course ;-).

if they want to contribute and support their contribution — great, they can. but if they want somebody to do the work for 'em for free... two words, seven letters.

On 6/7/2016 1:22 AM, Ola Fosheim Grøstad wrote:
> So this is solved in modern C++.

This is where we diverge. A language isn't safe unless it can mechanically guarantee that unsafe constructs are not used. Saying "don't write unsafe code" in C++ does not make it safe language.

How would you know some random 10,000 line piece of C++ code is using std::vector instead of [ ]? How do you know that some random PR pulled into your project does not have [ ] in it? It's faith-based programming. Faith based programming does not scale and is not the point of @safe.

On Mon, 2016-06-06 at 19:57 +0000, poliklosio via Digitalmars-d wrote:
> […]
> 
> 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.

Indeed. D has a GC by default which can be switched off. This is good. That D needs a better GC is an issue.

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

My feeling is there is no point in over-thinking this, or being abstract. C++ can have a GC but doesn't. Rust can have a GC but doesn't. Python has a GC. Go has a GC. Java has a GC. D has a GC that you can turn off. That seems like a USP to me. Whether this is good or bad for traction is down to the marketing and the domain of use.

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

Productive is way, way more important that native.

[…]
> 
> 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.

Can we drop the unit and just talk about testing. Unit, integration and system testing are all important, focusing always on unit testing is an error.

As to why not use D? The usual answer is that "no else is using D so we won't use D" for everyone except early adopters.

D needs to remanufacture an early adopter feel. It is almost there: LDC announcing 1.0.0, Dub getting some activity, new test frameworks (can they all lose the unit please in a renaming), rising in TIOBE table. This can all be used to try and get activity. However it needs to be activity of an early adopter style because there are so many obvious problems with the toolchains and developer environments. So let's focus on getting these things improved so that then the people who will only come to a language that has sophistication of developer experience.

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

Holes in Phobos can be handled by having third-party things in the Dub repository that are superior to what is in Phobos.

Documentation, guides, and tutorials are a problem, but until someone steps up and contributes this is just going to remain a problem. One that will undermine all attempts to get traction for D. So how to get organizations to put resource into doing this?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder