On Monday, 16 March 2015 at 01:22:47 UTC, cym13 wrote:
> It is anecdotic but after reading everywhere about how fast is compiling D, I was very surprised to see it taking 2s for a regular "Hello World". I understand it better now but at the time I was disapointed.
>

It would be interesting to know why you get these results. This is way slower than what I've experienced myself.

For instance, compiling SDC, and then using this newly compiled SDC to compile its runtime, from scratch, takes ~13s on my old laptop (Core 2 DUO P8700) and ~5s on the macbook pro.

This is tens of thousands of line of code.

Compiling an hello world is almost instantaneous as far as I experienced it. I do think it is interesting for you to share your setup so we can understand what is going on and avoid for another newbie to have the same experience.

On Monday, 16 March 2015 at 01:22:47 UTC, cym13 wrote:
>
> HINT 2: it took me about a month and a good tutorial on templates (btw, thanks G.Willoughby) to start understanding the full prototypes of standard functions. I really recommend putting the constraint part in slight grey so that it is still here and readable but the immediatly useful part of the prototype stands out.
>
> HINT 3: no beginner cares about how exactly it is compiled or advanced metaprogramming options. This should not be more than mentionned in a "getting started" page. It is cool stuff, it should be said, but it definitely does not fit in an introduction to any language.

Its hard to get this across but i too would like to see a simpler and easier to understand tutorial on D rather than seeing all these complicated things. Even Ahlis book isnt that great. Its good, but not great.

> HINT 4: D is great. It is a good language already. Stop mutating it! Fix bugs, improve the standard library, work on the ecosystem, reduce compile-time, but do not try breaking things all the time. Don't even think of improving yield as I suggested before, I'd prefer a standard library based solution at this point.

You definitely have a point. The problem is that everyone else see's D as an open source community driven language so everyone and their mother wants to contribute their own features, stuff like this is bound to happen.
This could also be a bad thing because if D falls behind on its bleeding edge mutation it could cause a collapse on people being interested.

On Monday, 16 March 2015 at 01:22:47 UTC, cym13 wrote:
> If stories are wanted, I might as well tell mine.

I am an attorney and a typical "programming-language-user": I
love to code my own utilities for the job (document-creation,
bookkeeping, etc.), but I use Windows and have an android smart
phone. In the last 15 years, I tried C (which I still use for
specific tasks), C++, C#, Pascal, Java, Perl, Ruby, Lua and D
now. I avoided Python and PHP because a good roofer listens to
his heart, not his wallet* :) My experiences so far:

1. D has to worst docs I happened to meet. I am still having
difficulties figuring out functions like 'any' and 'all', while I
understood the Ruby Enumerables at the first time. Same goes to
string manipulation. Last time I used std.zip I had to read it's
source to make my code work. That's a big warning sign.

2. Please stop changing the (core) language all the time. There
are like 3 new proposals every week in the forums and at least 2
of those are seriously considered. Please, just stop.

3. Improve Windows support. Include
http://www.dsource.org/projects/bindings/wiki/WindowsApi. The
fact that D needs Visual Studio for 64bit apps in 2015 is a shame.

4. D needs some kind of default GUI toolkit. I can't give my
utilities to associates/friends because no one wants to use a
console any more. I know it is not a small feat, but look at Ruby
- they just bundle the last version of Tk with their installer
and maintain a thin wrapper. Tk can be love/hated (I actually
like its flat and winnative theme) but it enables out-of-the-box
platform independent desktop-developement for Ruby.

* sorry for the ancient Star Wars/Clerks reference

On Monday, 16 March 2015 at 00:27:56 UTC, Walter Bright wrote:
> I like the analogy of D being a fully equipped machine shop, as opposed to a collection of basic hand tools.
>
> When I was younger it was hard working on my car, because I could not afford the right tools. So I made do with whatever was available. The results were lots of scrapes and bruises, much time invested, and rather crappy repairs. Now I can buy the right tools, and boy what a difference that makes! I can get professional quality results with little effort.

I agree with this. However, it actually implies a huge amount about what I would call D's brand. The fully equipped machine shop metaphor has some very serious tradeoffs when applied to computer programming languages, the steep learning curve required to use the machines correctly, for instance.

But I see advantage in this, because I can see a brand -- that is, an identity which distinguishes something from its rivals, not by flat-out superiority, but by its commitment to particulars -- for D here. I think D can market itself to a certain type of programmer, and win the language war by empowering this type of programmer, thereby inciting the envy of other types of programmers, who over time grudgingly concede the inferiority of their own styles and follow the herd.

Brands are all about types of people, rather than of products. I would love to see D consciously embrace its own kind of person, and not just because it feels good, but because of its value as a marketing strategy.

I see D attracting *really* good programmers, programmers from, let's say the 90-95th percentile in skill and talent in their field on average. By marketing to these programmers specifically -- that is, telling everyone that while D is for everyone, it is especially designed to give talented and experienced programmers the tools they need to get their work done -- even if you repel several programmers from, say, the 45th percentile or below in exchange for the brand loyalty of one from 92nd percentile or above, it's probably a winning strategy, because that one good programmer will get more done than all the rest combined.

ninja:

> 2. Please stop changing the (core) language all the time. There
> are like 3 new proposals every week in the forums and at least 2
> of those are seriously considered. Please, just stop.

D is not yet finished. Ownership of memory in D is a work-in-progress. Tuples are a hole in a language that wants to be a little functional. Alternative ways to allocate memory are needed by some people. The GC needs improvements. Purity is not yet finished. And there are minor things that can be improved. D3 is not planned, so the only way is to improve D2.

Bye,
bearophile

On Monday, 16 March 2015 at 08:33:43 UTC, Zach the Mystic wrote:
> I see D attracting *really* good programmers, programmers from, let's say the 90-95th percentile in skill and talent in their field on average. By marketing to these programmers specifically -- that is, telling everyone that while D is for everyone, it is especially designed to give talented and experienced programmers the tools they need to get their work done -- even if you repel several programmers from, say, the 45th percentile or below in exchange for the brand loyalty of one from 92nd percentile or above, it's probably a winning strategy, because that one good programmer will get more done than all the rest combined.

Yep, this is what I meant by my Blackberry analogy earlier in this thread.  Blackberry used to own the smartphone market, when it was limited to professionals who emailed and texted a lot.  When the market broadened to include everyone, they decided to go the popular route and sell touch-screen phones without physical keyboards like everyone else.  It was a disaster, from which they're only recently recovering by offering physical keyboards again.  I'm not saying it _had_ to fail, only that RIM clearly didn't have what it took to succeed there.

Similarly, D's never going to do very well with programmers who don't care about the efficiency of their code: simpler, slower languages like python or ruby have that niche sewn up.  The best we can do is point out that if you're already here for the advanced features, it can also be used for scripting and the like.  And of course, we should always strive to make things as easy as we can for both small and large projects, including better documentation.

One day, the tide may turn towards native efficiency again, say because of mobile or more people writing code that runs on large server clusters, and D will be well-positioned to benefit if and when that happens.

On 3/16/2015 5:07 PM, ninja wrote:

> 3. Improve Windows support. Include
> http://www.dsource.org/projects/bindings/wiki/WindowsApi. The
> fact that D needs Visual Studio for 64bit apps in 2015 is a shame.
>

Including the WindowsAPI won't change this. D uses the MS toolchain to generate the final binaries.

On 3/16/2015 6:02 PM, Mike Parker wrote:
> On 3/16/2015 5:07 PM, ninja wrote:
>
>> 3. Improve Windows support. Include
>> http://www.dsource.org/projects/bindings/wiki/WindowsApi. The
>> fact that D needs Visual Studio for 64bit apps in 2015 is a shame.
>>
>
> Including the WindowsAPI won't change this. D uses the MS toolchain to
> generate the final binaries.
>
Rather, DMD uses the MS toolchain.

On Sunday, 15 March 2015 at 14:56:23 UTC, Chris wrote:
> We invariably end up talking about language features and syntax, as if D lost out against Go, because of feature X being (or not being) there. We lose, because we fail to give people that warm glow in their chests. The feeling of "now I have something", which is basically what makes people go for something. I felt like this about D when I first got to know it, after a long period of being frustrated with every other language. Although irrational, my intuition was that D would offer me a lot, and it hasn't failed to do so. But this is, because I was willing to make an effort. Many potential users are either not willing to make an effort or they don't have enough time. So we should make it as easy as possible for them.

Makes a lot of sense. But…

> As was said in a post earlier, the decision to go for language X is often not 100% rational, but also based on subjective positive feelings. To ignore this basic human fact, doesn't help us. Having a great language with advanced features and doing some "feel good" marketing are not mutually exclusive.

This is true, but D's main problem isn't that people haven't come to D with high expectations of getting a better alternative to C++. The problem is that they came for emotional reasons and left for rational reasons.

They key is in understanding why people leave. Retention of the _target audience_ is more important than adoption rate.

It seems that many of those that stays with D either picked it for a hobby, or are not primarily programmers (I am not really sure why they pick D? Does not seem like a rational choice.), then a very small (and vocal) group use it for business.

In my opinion you need to pick a target audience, and with the CTFE focus targeting professional system level programmers is the only thing that makes sense. D needs to deliver on all aspects that C++ is good at before it is marketable, or else it will stay a hobby language for professionals and others. That means matching C++ on stability too.

If it is more work to implement smart pointers in D than in C++, then there are some fundamentally unacceptable limits in the core language. So it is not only marketing... D is not complete.

D needs a redesign to get away from lock-the-world GC without scars... A  language redesign that cannot be done with "last minute patches of special casing hell".

Over focusing on growing the user base by making tutorials, will only make changes harder, and it will attract the wrong kind of people that will ask for the non-system-level features making it even harder to improve the core language.

Why grow the user base before the language is done? You end up with no target audience, a very fragmented user base and equally fragmented eco system. Fragmentation makes it harder to produce professional level things.

It is also completely misguided to push D as a web dev platform. D is up against: Ruby, Python, Dart, node.js+angular, Java, Go etc in an environment where performance is mostly about networking, database/ORM integration and infrastructure AWS/Azure/Google... D is nowhere near being a plausible solution in this space, CTFE is essentially pointless in this domain.

On Monday, 16 March 2015 at 09:02:20 UTC, Mike Parker wrote:
> On 3/16/2015 5:07 PM, ninja wrote:
>
>> 3. Improve Windows support. Include
>> http://www.dsource.org/projects/bindings/wiki/WindowsApi. The
>> fact that D needs Visual Studio for 64bit apps in 2015 is a shame.
>>
>
> Including the WindowsAPI won't change this. D uses the MS toolchain to generate the final binaries.

The WindowsAPI static linking model is obsolete. Since the usage of new Windows API Sets, a dynamic linking model integrated in the language is needed (https://msdn.microsoft.com/en-us/library/windows/desktop/hh802935%28v=vs.85%29.aspx)

Something similar with the external directive from Delphi -> http://docwiki.embarcadero.com/RADStudio/XE6/en/Procedures_and_Functions

So instead of writing:

extern(Windows) DWORD GetVersion(),

we can write:

extern(Windows, "api-ms-win-core-sysinfo-l1-2-1.dll", [optional funcname]) DWORD GetVersion() or
extern(Windows, "kernel32.dll") DWORD GetVersion() for older Windows versions (<8).


I know probably a mixin will partially solve this, but this will save some important boilerplate code (just look at DerelictOrg bindings, thousands LOC just to load some functions from a dll).