On Wednesday, 14 February 2018 at 09:28:48 UTC, psychoticRabbit wrote:
> yeah.. even the more modern C++ code still makes me want to stay clear of it...(perhaps even more so).
>
> I just never get the same feeling when I look at D programs.

I get the same feeling from both languages, to be honest.  Average library code for both languages are harder to read than I think should be the norm (granted Python libs can also be somewhat hard to read, but still much easier on average).  Both languages are easier to read when you spend time with them yourself, obviously.  Both languages are easier to read when the programmer has been conservative in his/her use of features.

This situation is what happens when you add features at a high rate in the early years and don't want to clean up because of backwards compatibility. C++ has been at it for longer and are adding more features at a higher rate than D... so C++ becomes harder and harder to master if you read other people's arbitrary code. That doesn't mean D shouldn't clean up... I'd say it is necessary to get ahead.

For both languages you can always stick to your own idioms and write cleaner code than you see on github, and blog posts tend to be feature-show-offs (surprisingly often written by people who don't write a lot of code in the language they are posting about) so I don't think blogs are the right measure. Look at large code bases that are in widespread use to get an idea of what happens over time in terms of maintainability.

Anyway, C++ at this point has slightly better lambdas than D and D will notice the competition if C++ ends up adding stackless coroutines (e.g. Python like generators). Not a big discrepancy in features at this point, but C++ is moving at a higher rate... and that should be a concern if C++ is viewed as a competitor.

If C++ isn't viewed as a competitor, why bother with repetitive complaining about C++?

On Wednesday, 14 February 2018 at 09:50:31 UTC, Ola Fosheim Grøstad wrote:
>
> If C++ isn't viewed as a competitor, why bother with repetitive complaining about C++?

Because it doesn't get enough criticism ;-)

I believe the programming langauges of the future, and the ones people should invest their time learning, are those that can be best understood in the least amount of time.

This is because programs are getting larger and more complex, and to understand them at all, they have to be simple to understand.

C++ is not simple. It never has been. The so called 'modernisation' of it is not helping me to change my mind about it ;-)

And chances are, when you go to work in some C++ environment, you'll have to deal with lots of legacy style code - which you will be expected to understand as well.

It's time to stop 'improving' C++ and redesign it from scratch - or move to D.

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
> Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much

I first looked into C++ and Rust examples, just quickly without thinking them deeply. I thought that wow, the problem is probably more complicated than it looks. Seems to need many functions to solve eleganty.

Then when I saw your example I, of course, concluded that the problem is as simple as it seems. I would really have excepted C++ or at least Rust to come close to D, perhaps even achieve the same LoC count with a bit of luck.

Excellent article all-in-all, because it shown so many D features in a compact AND realistic way. I think a good D programmer might well write programs in that style for everyday use, not just for show. If someone asks "what would then be an unrealistic program then" it would be one that excessively uses introspection.

One improvement proposal: in the "Other features" part, you mention full compatibility with c. I think you should add "and with most of c++" because it might be a killer feature for some potential users.

On Wednesday, 14 February 2018 at 09:42:47 UTC, Russel Winder wrote:
> Seb,
>
> I believe this blog post would make a great article for Overload or CVu.

Cool idea, but I'm not so familiar with these. What can/should I do to make this happen?
We can also talk in private (seb [at] wilzba [dot] ch).

On Wednesday, 14 February 2018 at 08:06:13 UTC, Mike Franklin wrote:
>>> Aren’t you concered that Rust is faster in this benchmark?
>
>> Not at all. The challenge was to write expressive code and if performance really matters I can always opt to optimize the hot path of the program and don’t need to pay a > 4x code duplication cost upfront.
>
> You've gotta address this, IMO.  What's the performance/expressiveness tradeoff like in D?
>
> Mike

Good point. I tried to address this and changed the text to:


> Not at all. The challenge was to write expressive code. When performance really matters D provides the same tools as C or C++ and D even supports native interoperability with C and most of C++.

> In this example, however, I/O is the bottleneck and D provides a few convenience features like using locked file handles, s.t. accessing files is thread-safe by default, or supporting unicode input. However, it’s easy to opt out of such productivity features and for the interested readers I have attached a slightly optimized version at the end.

On Wed, 2018-02-14 at 13:21 +0000, Seb via Digitalmars-d-announce wrote:
> On Wednesday, 14 February 2018 at 09:42:47 UTC, Russel Winder wrote:
> > Seb,
> > 
> > I believe this blog post would make a great article for Overload or CVu.
> 
> Cool idea, but I'm not so familiar with these. What can/should I
> do to make this happen?
> We can also talk in private (seb [at] wilzba [dot] ch).

For the email list record, CVu and Overload are the ACCU journals. Historically Overload has been a C++ language, tools, and techniques vehicle put is now adding detailed technical articles on other languages. CVu has anything else, including some technical stuff.

https://accu.org/index.php/journal

Seb and I have started a personal email exchange and I am getting the
editors of said journals involved.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Wednesday, 14 February 2018 at 10:17:21 UTC, psychoticRabbit wrote:
> I believe the programming langauges of the future, and the ones people should invest their time learning, are those that can be best understood in the least amount of time.

Yes, I would say so, unless they bring something new to the table like formal verification (proven correctness) or some kind of expert system geared towards a set of common domains (e.g. data flow).

> This is because programs are getting larger and more complex, and to understand them at all, they have to be simple to understand.

Right, so which is an argument in favour of agent based systems. Kind of the direction that has happened on the server side with micro services.

> C++ is not simple. It never has been. The so called 'modernisation' of it is not helping me to change my mind about it ;-)

Right, because, even though C was simple, it isn't simple to debug, so C++ has all that + a wide variety of overlapping features. So C++ cannot become simple.

> It's time to stop 'improving' C++ and redesign it from scratch - or move to D.

Well, yes, but then D needs to make a case for itself and do a reset so that the disadvantages in switching is offset by the advantages. Either that or some other language will squeeze in, which is ok too. I don't care who does it, could even be Rust if they add some features, but it should happen. Right.

On Wednesday, 14 February 2018 at 14:17:31 UTC, Seb wrote:
> changed the text to:
>
>> ...and D even supports native interoperability with C and most of C++.

Great!

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
> Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much:
>
> https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d
>
> It's mostly targeted at beginners as I explain many basic D features, but maybe it's helpful for beginners looking into D.

Great article! Thank you!

Typo: "and finally format bundles" --> "and finally std.format bundles".

Another typo: "In the latter article I will also present a solution which only uses 12 lines, but it uses the built-in std.csv module and I think D doesn’t even need to cheat." should probably instead start "Later in this article I'll also present..." or "Further down I'll also present".

But even then, I don't think you should discount or put off using std.csv as "cheating". I'm guessing std.csv handles things like quoted elements containing commas. I realize that maybe you're being pedagogic and wanting to show off D's File byLine and splitter, but I think the first thing a reader will think when they see you rolling your own csv reader by hand is that something must be wrong with D or it's ecosystem if you're resorting to this, and they'll run for the hills (especially in an intro article, *and* one in which you point out that the goal is *expressive* code).

In fact, I'd go so far as to say that, when searching online for how to read in a csv file for a given language (see many examples at <http://rosettacode.org/wiki/CSV_data_manipulation>), if the example involves splitting on commas, I immediately assume it's either old/incorrect, the language is very low-level only, or else maybe the language's std lib must be impoverished.

On Wednesday, 14 February 2018 at 17:13:28 UTC, John Gabriele wrote:
> On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
>> Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much:
>>
>> https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d
>>
>> It's mostly targeted at beginners as I explain many basic D features, but maybe it's helpful for beginners looking into D.
>
> Great article! Thank you!

Thanks for the typos. Fixed them.

> But even then, I don't think you should discount or put off using std.csv as "cheating". I'm guessing std.csv handles things like quoted elements containing commas.

Yes.

> I realize that maybe you're being pedagogic and wanting to show off D's File byLine and splitter,

Yes.

> but I think the first thing a reader will think when they see you rolling your own csv reader by hand is that something must be wrong with D or it's ecosystem if you're resorting to this, and they'll run for the hills (especially in an intro article, *and* one in which you point out that the goal is *expressive* code).

Understood. Fair point.
I changed the motivation of why std.csv isn't used and added a warning that one shouldn't roll one's own CSV parser.

> I immediately assume it's either old/incorrect, the language is very low-level only, or else maybe the language's std lib must be impoverished.

Haha. This could be Rust's or C++'s new slogan ;-)