On 16/03/2015 10:31 p.m., rumbu wrote:
> 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).


Don't, please don't dare me...
I could totally do this with UDA's and CTFE for function pointers.
Plus my new total secret API could make this trivial to hook into.

On Monday, 16 March 2015 at 08:54:20 UTC, Joakim wrote:
> 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.

I don't necessarily agree with that. I'd say Python and Ruby will dominate among programmers that don't care about efficiency *and* are writing simple scripts. Ruby's my go-to language for writing small scripts to manipulate a little text or to move some files around. D is just a better language once you get into bigger tasks.

With respect to scripting, I see the main documentation problem being one of examples. You shouldn't have to understand how templates work in order to write a script. Documentation related to ranges is a big offender. Ranges are used all over the language, yet there's no way the average Joe is going to figure out how to use functions that return a range, and there's no reason it should be that way. I once proposed a ban on auto as a return type in documentation examples and the response was that you should know how to use the language before reading the documentation.

On Monday, 16 March 2015 at 10:02:46 UTC, Rikki Cattermole wrote:
>>
>> 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).
>
>
> Don't, please don't dare me...
> I could totally do this with UDA's and CTFE for function pointers.
> Plus my new total secret API could make this trivial to hook into.

Been there, done that: https://github.com/rumbu13/sharp/blob/master/src/system/runtime/interopservices/package.d

alias GetVersion = DllImport!("api-ms-win-core-sysinfo-l1-2-1.dll", "GetVersion", DWORD function())

I didn't achieve more than that, i consider this ugly, non-intellisense friendly, that's whay a builtin language construct will be better. Can't wait to see your total super secret API :)

On Monday, 16 March 2015 at 10:12:53 UTC, bachmeier wrote:
> I once proposed a ban on auto as a return type in documentation examples

This. Figuring out the return types in the examples was a daily struggle in the first few weeks.

On Monday, 16 March 2015 at 08:54:20 UTC, Joakim wrote:
> 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.

I hear ya, we have a NodeJS app running that easily eats 100mb of memory. Every week it grows to 200mb and we have a process manager restart it gracefully (which takes another 50mb). Compare that with a vibe.d app we have: 7mb. And it has been running for over 260 days.

On Monday, 16 March 2015 at 09:31:17 UTC, Ola Fosheim Grøstad wrote:
> 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.

This is an interesting assertion, and you have been around here much longer than me.  Of course the above must be generally true of any language (since one develops a better sense for what it is like by using it for a while), and I suppose it is also true that people who stick with D stick for more informed reasons.  Are there reasons to be concerned that the right kind of people don't stick with D, given that it is still maturing as a language, that not everyone can use it at work, and that there are many options available now, so a degree of churn is normal.  A language will be successful by starting with a very high appeal to a certain group, rather than a modest appeal to everyone.

> They key is in understanding why people leave. Retention of the _target audience_ is more important than adoption rate.
Okay, but target audience is an emergent more than a centrally planned property, although one can remove the obvious roadblocks for certain important groups.

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

I don't know if true without the data (is it worth trying a questionnaire on the download page) but supposing it is true is this surprising given it is not yet standard in the enterprise, and most firms are conservative?  Surely most languages get their start in this way.  It is a rational choice for people in this camp because native code, and who wants to deal with C++.   (And I love C, but...)
>
> 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.

See Innovator's Dilemma and Peter Thiel's work.  It needs to have a monopoly of appeal to certain groups, and as it develops spread out from there.  I don't see the link between CTFE and systems level programming.

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

I don't claim to understand the topic well enough, but it looks to me like a relative resource question combined with a desire to do things elegantly (which takes longer even though it is the right way) not a fundamental design question.

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

That's one reason saying "D hasn't gone anywhere, so it won't" seems a misdiagnosis.  It wouldn't have been possible/ the cost would have been higher to move to D2 with a much larger installed base (look at Python), and the language previously perhaps wasn't ready for prime time.  There is a lot of FUD from this talk of D not being finished - it seems like it's more than finished enough to do good work in many domains.  I appreciate for realtime the GC is a problem, but that surely isn't a majority of use cases and can be worked around (viz Sociomantic).  I almost was put off by the complaining (which goes back a decade and is to be expected where people really do care), but am glad I pressed ahead.

I am not sure what more non-system level users would ask for as _language_ features, nor what would lead to fragmentation rather than diversity in the user base.  The forums will suffer in signal:noise at some point, which is a natural cost of growth, and this would need to be dealt with thoughtfully, but that is a good kind of problem to have.  I really don't see how tutorials will hurt the language, because it will bring in more users with resources, and that will also help in the longer run.

D cannot be centrally planned, so one must be careful in speaking of target audience - especially when one cannot know in advance about who will stumble across it and find it useful.

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

That covers a multitude of use cases, and I am not sure that every one of these requires more of those things you mention than are currently available.  Ruppe uses it for web development, I think.  It seems rather defeatist to suggest that because one lacks features in certain domains one should just not even try to develop them, although I can understand the frustration.

On Monday, 16 March 2015 at 08:07:26 UTC, ninja wrote:
> 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

Smart phones seem to have an under allocation of attention to them in the D community given the stakes.  If I had the free cashflow I would pay for someone to work on that full time for a bit, but that's not practicable for the time being.

Interesting to hear about your experience using D for your work.  Would you be willing to write a little more about it and share your experience in a way that could be added to a collection of user stories?

For the GUI, have you considered creating a local web front end ?  Less work than a pure GUI, but people are used to using a browser.

On Monday, 16 March 2015 at 08:54:20 UTC, Joakim wrote:
> 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.

Isn't that implicitly what D is (and it is a compliment that you do a good job of unfolding it).  I agree with the economic understanding, and with the strategy.
>
> 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.

The future is here already, but just not evenly distributed (Gibson).  It hit Andrei's employer early, but I am not sure Facebook is an edge case of no relevance to mortals.

http://www.extremetech.com/computing/165331-intels-former-chief-architect-moores-law-will-be-dead-within-a-decade

Data sets are exploding in size but the marginal dollar value commercially of every byte is collapsing
whilst the free lunch from Moore's Law is over.  That means you have to use a JIT or native code, and the latter is not going to be C++, Go, or Rust for uses within the enterprise that require rapid prototyping and iteration to help answer dynamic commercial questions.

On Monday, 16 March 2015 at 13:16:33 UTC, Laeeth Isharc wrote:
> On Monday, 16 March 2015 at 08:54:20 UTC, Joakim wrote:
>> 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.
>
> Isn't that implicitly what D is (and it is a compliment that you do a good job of unfolding it).  I agree with the economic understanding, and with the strategy.
>>
>> 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.
>
> The future is here already, but just not evenly distributed (Gibson).  It hit Andrei's employer early, but I am not sure Facebook is an edge case of no relevance to mortals.
>
> http://www.extremetech.com/computing/165331-intels-former-chief-architect-moores-law-will-be-dead-within-a-decade
>
> Data sets are exploding in size but the marginal dollar value commercially of every byte is collapsing
> whilst the free lunch from Moore's Law is over.  That means you have to use a JIT or native code, and the latter is not going to be C++, Go, or Rust for uses within the enterprise that require rapid prototyping and iteration to help answer dynamic commercial questions.

Hence why both Java and .NET are getting full AOT compilation to native code on their canonical toolchains in Java 9/10 and .NET 4.6.

--
Paulo

On Monday, 16 March 2015 at 13:16:33 UTC, Laeeth Isharc wrote:
> The future is here already, but just not evenly distributed (Gibson).  It hit Andrei's employer early, but I am not sure Facebook is an edge case of no relevance to mortals.

Facebook is an edge case. Most computers run idle >90% of the time... If you need to complete something fast (but not low latency real time) you can do it in parallel paying by the hour, cheaper and more hassle free than ever before.

> whilst the free lunch from Moore's Law is over.

Not so sure about Moore's Law, keep in mind that Intel has very little pressure from AMD these days.

But faster/bigger things are out there:

http://en.wikipedia.org/wiki/Neurogrid
http://en.wikipedia.org/wiki/Memristor
http://en.wikipedia.org/wiki/Field-programmable_gate_array

But these kinds of technologies are more expensive to develop for.

> That means you have to use a JIT or native code, and the latter is not going to be C++, Go, or Rust for uses within the enterprise that require rapid prototyping and iteration to help answer dynamic commercial questions.

Not very specific, so hard to address, but factor in the increased development cost and you might see that it becomes cheaper to run it on a rented cluster using dedicated tools even if the code is running at half speed.

Average programmers are less and less capable of writing fast code... and the work it takes to write fast code is expensive. Not many are willing to pay for it, so in most cases it is cheaper to buy/rent better tools/hardware. But that's only because hardware is cheap compared to programmer time in most cases! If hardware was expensive then more people would be willing to pay for hand optimised programming?