On Monday, 6 June 2016 at 21:36:52 UTC, Seb wrote:
> On Monday, 6 June 2016 at 16:10:29 UTC, bob belcher wrote:
>> Hello,
>>
>> why not a poll, and ask the community that they want first.
>
> http://www.rkursem.com/poll/view.php?id=7f7ebc16c280d0c3c

Btw current intermediate results:

Immature tooling	                                11.4%	18	
Holes in the Standard Library: Images, Containers ...	10.8%	17	
Weak tutorials and documentation	                9.5%	15	
Garbage collector	                                7.6%	12	
Unwillingness to break old code to improve the lan...	7.6%	12	
Excessive memory usage during compilation	        7.0%	11
Missing sophisticated DLL support	                5.7%	9	
No (big) corporate support	                        4.4%	7	
Unfinished and/or inadequate language features	        4.4%	7	
Small job market	                                4.4%	7
Large size of binaries	                                4.4%	7	
Holes and bugs in safety	                        3.8%	6	
No compelling debugger support	                        3.8%	6	
No web services framework	                        3.8%	6	
No compelling plugin for wide-spread IDEs (Intelli...	3.2%	5	
General unwillingness of Andrei&Walter to listen t...	2.5%	4	
No compelling Visual Studio plugin	                1.3%	2	
Not enough advantages/features	                        1.3%	2	
General unwillingness of Andrei&Walter to listen t...	1.3%	2	
compile times do not justify coffee breaks	        1.3%	2	
Too fast	                                        0.6%	1

On 6/7/2016 12:40 AM, Ola Fosheim Grøstad wrote:
> On Tuesday, 7 June 2016 at 07:17:04 UTC, Walter Bright wrote:
>> Granted, one can certainly have other reasons to prefer C++. But memory safety
>> isn't one of them.
> That's true, but memory safety isn't a big problem in C++ if one sticks to what
> one can do in @safe code.

Obviously, code that doesn't do unsafe things is safe.

I used to write programs that corrupted memory for years and years in C++. Over time, I gradually evolved practices that avoided those sorts of bugs, and now I rarely have a corrupted memory issue in my code.

It's not that C++ got any safer. All that old code will still compile and crash. It's that I got better, which should not be confused with the language getting better. I learned not to stick my fingers into the high voltage section of the power supply.

C++ still suffers from:

http://www.digitalmars.com/articles/b44.html

and probably always will.

On Mon, 2016-06-06 at 13:19 -0700, David Soria Parra via Digitalmars-d wrote:
> 
[…]
> 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.

I think it is slightly more complicated than that, but these are the major issues. Go arrived with an easy way for early adopters to try it out (clone the repository and type make) which cause some of them to start writing libraries, which caused more people to try it out which caused documentation to be written. Then came the debates about how crap the system was which eventually led to the go command, etc. So it was about rapid evolution and acreting more and more people creating an active and constructive community. But in the background was that fact that the core team were fully funded to work on the project full time. This cannot be underestimated in the rapid rise of Go. Go evolution over the 7 years it has been public has had many rough rides, not dissimilar to D, but always there was the team of full-time people. This is what D is missing, and is unlikely to have in the foreseeable future.

Lessons can be learned not only from Go, but also Groovy, which has seen all forms of activity in it's 13 years.

Swift will I suspect go the same way as Go exactly because it is funded and has a hype behind it. Swift also has the ready made market of being the anointed replacement for Objective-C(++) for iOS applications development.

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

I am not sure this is entirely the case, but yes there is a distinct element of soundbyte first impressions. There is a clear relationship between language age and expectation of sophistication of the installation and development support. Go got away with zero support initially because it was so young, and it got the early adopters in to do the leg work of enabling the sophisticated set ups no there.

Without active, full time development of Eclipse/DDT, IntelliJ IDEA, CLion, etc. support for D, D will always be seen as an old language with no sophisticated tooling.

The organizations currently using D could easily chip in and make this full time activity happen, and whilst a cost should bear fruit in better development for themselves.

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

So don't focus on them for D traction, let them come in their own time.

-- 
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 16:56 +0000, Wyatt via Digitalmars-d wrote:
> On Monday, 6 June 2016 at 14:27:52 UTC, Steven Schveighoffer wrote:
> > I agree. It's telling that nearly all real-world examples we've seen (sociomantic, remedy games, etc.) use D without GC or with specialized handling of GC.
> 
> I doubt either of the two you named would change, but I wonder how different the tenor of conversation would be in general if D's GC wasn't a ponderous relic?

So instead of debating this endlessly, I think this is about the tenth time this has come up in the last two years, why doesn't a group of people who know about GC algorithms get together and write a new one?

Java has had a large number of GCs over the years: new knowledge, new algorithms, new implementation lead to better performance.

Go has had at least three GCs as new knowledge, new algorithms, new implementation lead to better performance.

D has had lots of discussion on email lists but no-one has followed this up with actually doing something that resulted in a change.

-- 
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 6/7/2016 12:43 AM, Ola Fosheim Grøstad wrote:
> Well, it is a lot of work to get the base 10 IEEE 754-2008 implementation
> conformant. Fortunately IBM has already done it under a BSD license:
>
> http://www.bytereef.org/mpdecimal/index.html
>
> So all you base-10 dudes have to do is to translate it into D.
>

Nice link. It isn't even necessary to translate it to D. Just put a D wrapper around it (it is a C library, after all).

Since it is BSD licensed, it probably shouldn't go into Phobos itself, but as an add-on library there should be no problem.

On Tuesday, 7 June 2016 at 07:57:09 UTC, Walter Bright wrote:
> C++ still suffers from:
>
> http://www.digitalmars.com/articles/b44.html
>
> and probably always will.

template< size_t size > void function( char ( &array )[ size ] );

It's horrible syntax (no surprise), and being a templated function means it's recompiled N times... but there's at least something for it now.

(Of note is that it's how you're expected to handle string literals at compile time with constexp, but it doesn't make string manipulation at compile time any easier. Go figure.)

On Mon, 2016-06-06 at 13:10 +0000, jmh530 via Digitalmars-d wrote:
> On Monday, 6 June 2016 at 05:49:53 UTC, Ethan Watson wrote:
> > 
> > Echoing the need for decimal support. I won't use it myself, but I know it's critical for finance.
> 
> You can always round something to two digits if you need to.

For graphics cards this approach to floating point may work: in fact we know it does, graphics card floating point is fast but really quite inaccurate, but it is accurate enough that the final rounding leads to the right result (usually). For finance, you have to have very high accuracy all the way through calculations: floating point rounding errors are a serious problem solvable only with arbitrary size/precision numbers. Hence Java's BigDecimal, GNU's gmp and all the other realizations. This is not just an abstract technical debate, it is a matter of compliance with legal and regulatory requirements.

And no you can't do it with integers, at least not hardware ones.

-- 
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 21:35 +0000, DLearner via Digitalmars-d wrote:
> 
[…]
> IBM PL/I had a _FIXED DECIMAL_ datatype, many many years ago. Could it be used as a model?

That will almost certainly be because IBM hardware has a decimal ALU as well as a binary ALU.

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

-- 
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 Tuesday, 7 June 2016 at 07:57:09 UTC, Walter Bright wrote:
> It's not that C++ got any safer. All that old code will still compile and crash. It's that I got better, which should not be confused with the language getting better. I learned not to stick my fingers into the high voltage section of the power supply.

Well, I don't know how newbies approach C++ and what problems they run into, but when I learned C++ in the 90s most of my problems were related to using the C-subset of C++. Often for performance reasons as compilers weren't as good back then so even simple compile-time abstractions could give significantly lower performance.

Of course, I knew C++98 and was a proficient programmer before I started using C++14/17 18 months ago and the learning curve for becoming proficient in C++14/17 is quite steep and involves both learning, inventing (going where people haven't gone before) and unlearning. There are just way too many ways of doing the same thing in C++ to be certain that one does something the best-possible way.

Which is rather costly compared to say Go or the direction D1 took, which focus on being simpler than C++ and generally offers one way to do something. Work on making D simpler (easier to use and easier to read) and you may find new markets.

Simpler does not mean less powerful. The best way to get a simple and consistent language is to create a simple high level IR that can represent all language constructs you are interested in (by "lowering").


> C++ still suffers from:
>
> http://www.digitalmars.com/articles/b44.html

The array issue is solved. I only use std::array<Type, Dim>. I never use Type[Dim]...
I also use gsl::span<Type, Dim> or gsl::span<Type> for array parameters. I also have my own array types for special use cases (forcing heap allocation etc).

So this is solved in modern C++.

I don't think it is "idiomatic" to write C-code in C++14/17.

What really irks me about C++/D is that they don't focus on making it easy to write readable code (making complex code more readable). I don't think it is difficult to fix, but it requires significant breaking changes.