August 03
On Thursday, 3 August 2017 at 03:46:38 UTC, Zwargh wrote:
> On Monday, 31 July 2017 at 12:32:52 UTC, Nicholas Wilson wrote:
>> On Sunday, 30 July 2017 at 01:53:15 UTC, Zwargh wrote:
>>> I am using D to develop a system for rational drug design. The main application for D is for protein 3D structure prediction and statistical analysis using Differential Geometry and Knot Theory.
>>
>> Cool! Are you considered using dcompute for this once it has matured a bit?
>
> It is a possibility and MIR as well. In my experience, D could be the perfect replacement for C++ and Java for bioinformatics.

I hope it does, i'll be using it for all my bioinformatics stuff.
August 04
On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote:
> How do you use D?

I use D for pretty much everything in my personal life at the moment. I've found some things that I thought were better in other languages, but either D's ecosystem has improved (which is why I'm rewriting my RSS reader from C# to D -- when I wrote it, vibe.d wasn't a thing) or I was proven false (scraping websites in Python led to a ton of inscrutable encoding errors; implementing a parser in C# was about 900 times slower than the D version until I wrote my own UTF8 string struct and made some other optimizations, at which point it was merely 3.5 times slower).

By count, most of what I'm using it for is small scripts for simple simulations. Recurrences that I can't solve mentally in a reasonable amount of time, so I need a program for it. In ages past, I'd use Python, since it tends to be convenient. However, while it's a bit more convenient than D, type safety is worth a lot.

I tend not to finish projects, but the ones I've worked on in the past week or strongly intend to get back to are:

* An init system (mainly for learning).
* A procedural generator for a witch's spellbook [1]
* A rewrite of my RSS reader (70% complete)
* A MUD involving procedurally generated sky islands

As for the mechanism by which I use D: I've mainly stuck to vim. I've tried out vscode plus code-d, but that doesn't work for me. And in the past, I've used Eclipse plugins for D. Vim, NERDTree, and tmux make for a good editing experience -- it's what I use for Java at work.

> Did you introduce D to your work place?

I used D to write a tool to extract and update vbulletin templates from a directory of templates. This meant we could store things in source control. (Vbulletin stores templates in its database. This makes their hosted solution much better, I'm sure. It makes my life more annoying.)

Unfortunately, I was the only one who preferred source control rather than editing live.


[1] Sample spellbook, only one spell (it needs some work):
> The Book of Vile Darkness
> a witch's guide to necromancy with friends
>
> 𐀛𐀲 𐀔𐀼 𐀗 𐀩𐀴 𐀬𐀤 𐀢𐀂 𐀳𐀘 𐀓𐀝 𐀓𐀴 𐀅 𐀹𐀶, a spell to banish spirits
>
> You will need:
>  * graveyard soil
>  * bronze mirror
>
> reduce graveyard soil to a paste
> boil paste, bronze mirror in a size 6 cauldron
> mix paste thoroughly
August 05
> It is more about marketing. Maybe Go is not a perfect language, maybe not even a good one, but it's sold so good because of a good marketing
>
> So, calling D a "better C++" is a bad advertisement. But if you rename it to '<anything>Script', for example "DatScript" and sell it as "better, statically typed JavaScript dialect which compiles into fast native executables" it will became #1 language on GitHub in no time.

+1

I've suggested exactly the same "easy-to-learn super-powered stronly-typed javascript" and "efficient web server development" advertising approachs to the D leadership, using a more "Python.org"-like website.

Maybe it's because this change would be much too radical, but I've been told that the "Better C++" slogan won't change, despite D could easily be "tweaked" to eat a significant part of Go/Dart's market shares.

And I'm not especially convinced that many C++ developers are currently rushing towards D because of the current website.

For instance, I've personally chosen D *only* it was much better than JavaScript/Node.js, not because it was better than C++, that I still have to use for game and mobile development.

Still waiting that somebody explains me how to _easily_ use D with Unreal Engine, Cocos2D-X, etc... ;)

I know I'm not the general case, but this still proves that "some" C++ developers won't switch to D for long because they are too tied to their ecosystem.

August 06
On Saturday, 5 August 2017 at 21:31:49 UTC, Ecstatic Coder wrote:
>> It is more about marketing. Maybe Go is not a perfect language, maybe not even a good one, but it's sold so good because of a good marketing
>>
>> So, calling D a "better C++" is a bad advertisement. But if you rename it to '<anything>Script', for example "DatScript" and sell it as "better, statically typed JavaScript dialect which compiles into fast native executables" it will became #1 language on GitHub in no time.
>
> +1
>
> I've suggested exactly the same "easy-to-learn super-powered stronly-typed javascript" and "efficient web server development" advertising approachs to the D leadership, using a more "Python.org"-like website.
>
> Maybe it's because this change would be much too radical, but I've been told that the "Better C++" slogan won't change, despite D could easily be "tweaked" to eat a significant part of Go/Dart's market shares.
>
> And I'm not especially convinced that many C++ developers are currently rushing towards D because of the current website.
>
> For instance, I've personally chosen D *only* it was much better than JavaScript/Node.js, not because it was better than C++, that I still have to use for game and mobile development.
>
> Still waiting that somebody explains me how to _easily_ use D with Unreal Engine, Cocos2D-X, etc... ;)
>
> I know I'm not the general case, but this still proves that "some" C++ developers won't switch to D for long because they are too tied to their ecosystem.

In open source, and indeed in entrepreneurial corporations, the way to persuade people is to create the shift you advocate, at least in a small way, so people can see what your early start could become.  Code wins arguments, as they say at Facebook, and not just code but documentation, business plans etc too.

Its work to write it, but on the other hand my experience has been that work is rarely truly wasted.  It might seem so at the time, but for example work I did to persuade somebody that didn't want to listen, and where it seemed like I was pointlessly banging my head against the wall, has ended up being very valuable, even in dollar terms a few years later.  It's not always rational to be excessively calculating about risk reward in the face of genuine, radical  uncertainty when the risk is not that bad.

I agree with you that the benefits of D are not perfectly well communicated to people who aren't C++ programmers looking for salvation.  I had a discussion just last week about that, explaining that D isn't just something they mostly fits only large data sets where performance is key.  And in particular it's a cultural challenge because people have become resigned to the idea of different languages for different purposes, and to a large extent D doesn't fit the mental schema people have.

Nothing much changes in life day to day, and changes that seem to be big often unfold slowly for a long time before being noticed.  The financial crisis unfolding began in Feb 2007 at the latest, but it didn't feel like that to most people at the time.

Similarly, compare D documentation today to that of early 2014 (when I first look at D).  Plenty of it was all perfectly clear if you had a more academic training in computing, but if not then it wasn't the friendliest.  I tried to persuade one chap who was helping me between jobs to learn D, and he was absolutely terrified of it, to a good extent because of the docs!

And it's also because people are used to complexity being hidden from them and things being made very easy.  Since D often involves paying a price upfront to make future things easier, perhaps it's worth bearing in mind that there's a coupling between the degree of development of the tooling and how polished the docs should be.  If you make it so easy to learn D that you draw people who are utterly stuck when they hit dependency problems with dub, that may not be ideal either.   Ie an implicit question of truth in advertising.

And the situation with docs changed over time.  One recent change is thanks to Seb Wilzbach who introduced runnable examples generated automatically from unit tests.  If you look at his pull request it wasn't welcomed entirely with open arms in the beginning because the benefits weren't clear (and some other reasons I forgot).

So if you think we should have friendlier docs appealing to non systems programmers, why not write a mock up so others can see.  It needn't be either or, because you can have an easy or advanced channel from front page.

And it's worth not alienating those who want to go straight to the meat of things - there's nothing more frustrating than a system that talks down to you or breaks things down into little pieces when you're quite used to slaughtering and butchering dinner for yourself, thank you very much...

I really think there's a limit in how much sense it makes to think about D marketshare against other programming languages.

If you have 30% market share it's very difficult just to hold onto it, let alone grow.  At this stage in the development of D it really doesn't need to defeat any other language, but it just needs to become a little more appealing to those who are already receptive to it, maybe already use it, and to the stakeholders that they need to convince to give it a try.  Most programmers in enterprises are not in charge of technical choices of this nature - we need to have a very high appeal to the ones who do and who would want to use D if only they knew because then social factors become less important.  If you look at who has adopted D and how, 
 that seems to me how this has unfolded.

I think C++ programmers in finance are likely to be receptive to using D over time.  There's a lot of FUD put forth on this topic, but in the end if something leads you to  better results then people will adopt it over time, slowly in the beginning, and then faster.  You haven't got much choice because if your competitors are more nimble than you think have a problem.  Similarly it seems than Ethan at Remedy Games has a similar perspective on his industry.

The better Go and Rust do the better it is for us because it opens up thinking about choices and in general they are quite different languages serving different needs (of course there is overlap).

It's a much easier case to make to say we should use a modern language, review them all, and sometimes the best answer will be D than to say we should move from whatever it is we are used to to this "new"  language nobody has heard of.

Remember that social media representation of reality isn't identical with the world itself.  The web guys talk, but enterprise code is a big market and people there often don't talk in public, maybe are forbidden from doing so.  Biggest D commercial users I have talked to at dconf don't say much in public because they have a business to run.  On the other hand I have my doubts about whether some of the biggest and most academic in a certain sense naysayers of D on this forum use the language much at all. Personally I have some skin in the game - I might be wrong in my judgements about some things, but if I am, I'll bear the consequences (but also the upside if I am right).

Downloads of dmd have gone bananas, and I think that started before Netflix announcement.  When will D take off? It's happening right now.  Compound growth doesn't look like much in the beginning, but give it time. (years, but that's how long it takes).

Who is going to be the big sponsor of D? It's my belief probably there won't be a single big sponsor, and that this is probably a good thing.  It's a very ambitious language covering an immense breadth of domains.  How is it possible for one firm to be a sponsor of that nature without distorting the unfolding of the language?

What's better than one enormous sponsor? Lots of sponsors, of varying sizes, and covering various different domains.   That's much less brittle and more balanced, and you'll get much better reach and adoption that way.

And I also think that the generalist nature and breadth of the community is one of the most appealing aspects in an age where everything became hyper fragmented, siloed and specialised.

Success on a grand scale brings its own challenges.  Some day we may be reminiscing about the good old days before the invasion of the careerists.  That's a way away, but it's worth recognising also the benefits of where we are today. It's no longer true that there are no jobs in D, but for the time being people learn D because they care about technical excellence, not yet  because it's a clever route to get a great job..





August 06
On Sunday, 6 August 2017 at 03:30:00 UTC, Laeeth Isharc wrote:
>>
>> I've suggested exactly the same "easy-to-learn super-powered stronly-typed javascript" and "efficient web server development" advertising approachs to the D leadership, using a more "Python.org"-like website.
>>

[snip]

Good long read.
August 06
On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote:
> While the Orgs using D page is very nice ... I hoping to hear more personal stories ...
>
> So
>
> How do you use D?
> In work, (key projects or smaller side projects)
> in your side project, (github, links please)
> just to learn something new? (I would easily argue that learning D will make you a better C++ programmer, maybe not the most efficient way, but I a sure it i very effective)
>
> Did you introduce D to your work place? How? What challenges did you face?
>
> What is you D setup at work, which compiler, which IDE?
>
> And any other fun facts you may want to share :)

I started programming in 1983: BBC BASIC, 6502 assembler, Z80 assembler.  I learnt to program C on an Amstrad PCW running CP/M, and compiler I used had K&R style declarations.

Then I discovered economics, and my life took a different course. 
 I moved into trading and managing money, but I always programmed on the side to help me solve investment and business problems.  Kept it quiet because programming was for a long time low status and clashed with what people expected to see in a money manager.

Late 2013 I recognised that the way our business used technology was completely broken.  The only way to make the most of technology is to combine an understanding of investing, financial instruments, the investment business, and technology in one mind. 
 But where am I going to find a guy like that?  So I looked in the mirror and realised I had to brush up my skills.

So I started building tools to help me invest.  My friends mostly thought it was a crazy course of action, because it's rare if you leave investing even temporarily to return to it, and I love markets, but sometimes the direct approach isn't the right one.  We're drowning in data but don't have good tools to make sense of it.

I learnt python and cython, but kept looking, because I wanted to have my cake and eat it.  Why can I not have all of productivity, performance, static typing/correctness, abstraction, and code readability - I don't think I should have to choose just a couple, and I am not going to. That led me to D in 2014.

At school they used to ask us if everyone else jumped out of the window  would you do it too? And it's a profitable approach in financial markets to develop and learn to trust your own judgement of things.  If a highly respected and very knowledgeable economist tells you "you do realise that there is no basis in economic theory for what you are suggesting", you need to be able to revisit your thinking, see what you might be missing, but in the end trust your own judgement over that of the putative expert.  And he subsequently wrote a very impressive explanation after the fact of how what "couldn't be justified in theory" did in fact happen.  And it's a bit similar with programming language choices and such.  Its way better to appeal to people who make up their own mind and bear the consequences then to those who have to cover their behinds by getting the right ticks in the boxes because the are never going to be earlier adopters except through some unfortunate accident - because you also don't want such people as early adopters!

Since then, one thing led to another, and I ended up hiring a few people from the community to help me as consultant developers.  Maybe a bit more than 10% of Team Phobos, based on a simple calculation.

I have also ended up running technology, amongst other things, for a decent size hedge fund.  I am using D for the project I started beforehand, and we are starting to explore its usefulness in the rest of the firm for some core analytics.  It pays to start small and build on early successes.

Has D been good for me? What have been the consequences of the French Revolution? In both cases it's too early to say with utter confidence since life is complicated and things are not always what they seem to be in the moment, but I have a view on the latter, and I think the answer to the former is definitely yes.

Finance used to be relatively at the leading edge.  The industry got a bit too fat, it hired the wrong people as it expanded too quickly, and then after the crisis people had other things to worry about - first survival, and then an exploding burden of compliance.  At one big bank even the compliance people complain about the number of compliance people they have.  On top of that, there's so much legacy systems that it can be very difficult to do anything creative or new.

So as an industry we fell behind a bit, and when you go through a cycle like that if becomes somewhat self-reinforcing.  To turn things around you need to hire very good people, but it's not so easy to find very good people who are willing to work with the people who created and tolerated the mess in the first place.  But it can be done, and I think based on a view from afar that the banks will do better on this front than they have been.

For a firm like the one I am involved with its different because we are at a post startup stage.  Some legacy but not that much, and it's possible to do new and creative things.  And it's also possible to use languages that might not win on social factors if based on intrinsic factors it's by far the best answer for us.  And we don't need to make a big bet, because we can make a start in a small way for us, and build on successes.

One of the biggest benefits from D is I think a cultural one.  We're in an age of specialists and of the full stack overflow engineer, with people strapping together ready made components.  If that's all programming is about, you don't need to have people with flair, because it really flattens out the differences between people.

But in a business that's highly dynamic, there's also a cost to such a conventional approach.  One loses some ability to adapt to unanticipated change, and you lose coherence in understanding about the total behaviour of your system, and about what the choices are and what the implications might be.  This fragmentation of knowledge that accompanies micro-specialisation isn't entirely healthy.  And maybe if working with framework X for years will make you faster then someone who hasn't experience of framework X, speed of development isn't from a commercial perspective the only, or sometimes the main factor, in determining productivity, which is not a materialist measure (features accomplished per 40 hours), but a measure of economic value added per unit input, and value added relates in this case to long lived capital, and part of the value of capital relates to optionality and the ability to adapt what you have built to an unexpected need, or to change the way you do things in a way you didn't originally plan for but that's better.

In other words you can think about the plasticity of D from the point of view of real options theory.

When I started my career there was an understanding that whilst experience had value, someone capable could often pick things up given a few pointers and a chance to learn.  We somehow forgot that in the years since then, though this way of thinking is making a comeback.

So a benefit of D is that because it attracts people who aren't put off by the tooling etc, one tends to find people who are adaptable and don't mind getting their hands dirty and doing something they never did before because that's what is the most valuable right now from a business perspective.  Lack of polish can itself also be a highly effective filter.

Many seemingly hairy things are not that bad with a bit of experience.  But if you don't get such experience because you spend your life in an environment where things just work then when something doesn't work it's a bit more painful.

Suppose there's part of an application that's slow.  I simply can't imagine finding a good and experienced D developer who wouldn't have put it through a profiler and doesn't already have some idea anyway of bits of the code that are slow.  In some other communities, it really isn't like that at all!  And similarly if you think the GC is a problem in your code somewhere it's just normal to use the instrumentation to check and to use an allocator if that's the case.  Not something you would even give a lightning talk about doing in D land, because it's just what you do.  For some managed languages the norm is quite different.

London used to be a set of villages.  But today any former village that has an underground station has lost its character, whereas those that don't are harder to get to and have somehow preserved it more.  And it's the same with virtual communities - the very difficulty initially of gaining entry can also preserve its character.

Benefits of D? The easiest reasons to adopt something are not necessarily the reasons that ultimately matter most.  Some proximate attractive aspects of D are the ability to write native code in a modern language that can be called from many different languages with wrappers being generated via attributes.  Excel-D is one such tool, but there are other languages we need to target also.

There's a rising interest in alternative data sources in finance. 
 Numerical data is not that big.  Text data can be, if not big, uncomfortably large vs what we are used to working with.  And D is fast with strings, but that's not the case for some other more modern languages used in a finance environment.

Code clarity is worth something too.  It's easy to read well-written D code, to some extent even if you don't know D.  Some other languages not so much, because of the fragmentation of OO code and the verbosity and use of abstraction that isn't doing any useful work but does constitute another layer in the way of understanding what's going on.

I personally use Sublime or vim on Linux.  Others use Visual D.

Biggest challenges? People don't have reference points for D.  It doesn't slot into an existing mental category. "so you're saying D is good for larger data sets".  Well, that's true  but it's not quite only what I am saying.

Other challenges - normal human anxiety about doing something different. And habit - apart from necessity, the most powerful force in the universe.  If someone is in pain, they are going to listen to something that might be an answer. C++ programmers I work with aren't sceptical of the GC, but they're excited about doing things better because they both love C++ and appreciate that it has flaws.

Windows experience is not that great.  Part of it is just native code on Windows rather than D, but expectations are set by languages that do everything for you.  Most of the time installing a library in python is one command.  In D you might have the dub wrapper or binding and then the C library itself.  And installing the latter is not always just one command.

Would be great to have a web front end to D irc, because some companies have to be careful about what chat services are accessed from their systems. Of course I can for me set this up myself but others might not bother to do that.

Thinking about my own experience and that of another commercial user I wonder if there is a market for paid support for compiler plus phobos plus certain libraries.  The first adopter within a firm might be quite ready to persevere, but the others they follow may do better if there is someone they can call when they get stuck.  Not necessary for my group, but in time some might find it valuable.  Not very difficult but just need patience and ability to communicate.

Maybe some value also to training eg python users to show them how they can do similar things in D  and what the benefits are. People learn in different ways and I think it's a minority that learn from reading books unless very motivated.



August 06
Very interesting post.

My bachelor's thesis was a expert system for stock trading implemented with Borland C++ 1.0, and D would have been a good fit as well if had been an option in 1989, so I understand why you think that financial development will make D popular.

But that's the exact opposite of what trending languages do at the moment (Go, Kotlin, etc).

They care to solve the basic problems of the casual developer : implementing desktop, mobile or web applications.

Not the most interesting jobs maybe, but that's what pays the bill of many of us, the "less skilled" developers who are not engineers.

August 06
On Sunday, 6 August 2017 at 06:04:57 UTC, Ecstatic Coder wrote:
> Very interesting post.
>
> My bachelor's thesis was a expert system for stock trading implemented with Borland C++ 1.0, and D would have been a good fit as well if had been an option in 1989, so I understand why you think that financial development will make D popular.

I don't know that I would say finance will make D popular but it's one domain that I know well where I think it can be useful. Popularity isn't only a good thing either.

I think the focus on Go, Rust etc as a competitive threat is misplaced.  If they do something well and it fits us we should without shame copy it, but better.  But just because they are the focus of attention amongst some communities doesn't mean we should otherwise worry about what they are doing.


>
> But that's the exact opposite of what trending languages do at the moment (Go, Kotlin, etc).
>
> They care to solve the basic problems of the casual developer : implementing desktop, mobile or web applications.

Why try to beat them at their own game, or even spend energy wondering about it.  The DNA of the community mostly isn't interested in solving the problems of the casual developer in the same way.  So unless it changes then it's a tough game to expect to beat them on criteria they set.

Looks at the compounded rate of growth of dmd daily downloads.  If it were a stock, I wouldn't be short it, because it's in an uptrend and far from overbought.  Many other contexts you would even call that explosive growth.


> Not the most interesting jobs maybe, but that's what pays the bill of many of us, the "less skilled" developers who are not engineers.

I guess you only need one job.   And there is share of market and share of mind.  It's much easier for talented people to be recognised as such in a smaller community than a vast one.


August 06
For instance, D is my favorite language, and I try to promote it as much as I can (reddit, stackoverflow, even on the go-nuts google groups).

But professionally I still use C++ (#3 TIOBE), PHP (#7), Go (#16) and now Dart (#20).

Not D.

Despite Go and Dart are very recent "post-D" languages, people are already starting to use them a lot these days. Whether you trust or not these "pseudo" rankings, they are probably already more popular than D, despite they are still in their 1.x version.

That's sad, because the same developers who now use Go (including me) could have started to use D instead. But they didn't.

Obviously Google's great support and marketing help a lot, but most developers are not as dumb as you may think.

They just use what solve their daily problems. In the end it's often as simple as that.

That's why now I always use D to develop my command-line tools. It gets the job done quickly and easily.

Same for Go and Dart. Despite I don't really like them actually.

August 06
On Sunday, 6 August 2017 at 06:49:45 UTC, Ecstatic Coder wrote:
> For instance, D is my favorite language, and I try to promote it as much as I can (reddit, stackoverflow, even on the go-nuts google groups).
>
> But professionally I still use C++ (#3 TIOBE), PHP (#7), Go (#16) and now Dart (#20).
>
> Not D.
>
> Despite Go and Dart are very recent "post-D" languages, people are already starting to use them a lot these days. Whether you trust or not these "pseudo" rankings, they are probably already more popular than D, despite they are still in their 1.x version.
>
> That's sad, because the same developers who now use Go (including me) could have started to use D instead. But they didn't.
>
> Obviously Google's great support and marketing help a lot, but most developers are not as dumb as you may think.
>

You have to look at the big picture. Let's ignore for a moment what might improve D's adoption and perception. Let's also ignore this particular moment in time. Let's go back to the beginning and look at the big picture from then until now. From that perspective, it's quite a rosy picture. We've got a wealth of libraries available compared to just a few years ago. Conversations on reddit don't immediately descend into D-bashing like they used to. I see more new people more frequently in the forums than I used to. Multiple companies are using D and talking about their usage, sharing their code, where there used to be none. It's just a vastly different community than it was when I first stumbled into it. Much for the better.

Yes, there are holes to fill, improvements to be made, but there always have been and there always will be. It's an ongoing process that, by the way, has many more people contributing to it than it did a decade ago. It's natural for people to come in along the way, look at the current state of affairs (without the benefit of that longer perspective -- or even those who do have perspective but have lost heart because their major peeves haven't been addressed), and start despairing that if only D did this or did that, or targeted that domain, or had a plugin for that IDE, or whatever, then it would be a better choice than Rust or Go or Javascript and more developers would pick it up. That might even be true. But the thing to remember is that neither the language nor the community has stagnated. Progress is going steadily forward despite all the predictions of doom and gloom (which I've been seeing in these forums since 2003). And if everyone in the community would pick a pet peeve to fix, whether it be making edits to the web site or contributing to an IDE plugin, it all moves that much further forward. As long as we keep our heads down and keep chipping away, things will only continue to improve.
1 2 3 4 5 6 7