On Tue, Sep 29, 2015 at 09:54:34PM -0700, Walter Bright via Digitalmars-d wrote:
> On 9/29/2015 7:24 AM, Atila Neves wrote:
> >That's as true as saying that D is similar enough to Java that it wouldn't be a big jump. You'd end up with code that looks like C++ or Java that no seasoned D developer would write.
> >
> >The difference is actually quite big. If it weren't, why would any of us bother?
> 
> It's interesting looking at the ddmd source code. It's translated from C++, and it shows. It doesn't look much like D code.

Are we accepting PRs to convert ddmd to be more D-like?


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry

On Wednesday, 30 September 2015 at 05:00:11 UTC, H. S. Teoh wrote:
> On Tue, Sep 29, 2015 at 09:54:34PM -0700, Walter Bright via Digitalmars-d wrote:
>> On 9/29/2015 7:24 AM, Atila Neves wrote:
>> >That's as true as saying that D is similar enough to Java that it wouldn't be a big jump. You'd end up with code that looks like C++ or Java that no seasoned D developer would write.
>> >
>> >The difference is actually quite big. If it weren't, why would any of us bother?
>> 
>> It's interesting looking at the ddmd source code. It's translated from C++, and it shows. It doesn't look much like D code.
>
> Are we accepting PRs to convert ddmd to be more D-like?
>
>
> T

Sure, you can submit PR here : https://github.com/SDC-Developers/SDC

;)

On Wednesday, 30 September 2015 at 05:17:59 UTC, deadalnix wrote:
> On Wednesday, 30 September 2015 at 05:00:11 UTC, H. S. Teoh wrote:
>> Are we accepting PRs to convert ddmd to be more D-like?
>>
>>
>> T
>
> Sure, you can submit PR here : https://github.com/SDC-Developers/SDC
>
> ;)

LOL.

- Jonathan M Davis

On Tuesday, 29 September 2015 at 16:19:19 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 29 September 2015 at 15:31:30 UTC, Laeeth Isharc wrote:
>> On Sunday, 27 September 2015 at 09:51:42 UTC, Ola Fosheim Grøstad wrote:
>>> But even after years of polish Go is still perceived as risky:
>>
>> Of course it's risky.  Yet why do people who are sensible commercial people who aren't in the business of gambling use it?  Because it's a very good tool for certain kinds of job, and the benefits outweight the costs, risks being one of those costs.
>
> Yet people are looking at creating a derivative language of Go for operating system development:
>
> https://groups.google.com/d/topic/golang-nuts/6dI4vIxRgn8/discussion
>
> Why did they not go with D?

I have no idea - perhaps you should ask them.  I don't see how the 'yet' follows, but on the other hand it is not entirely unexpected that it doesn't.  People are right to perceive Go as risky - anything new is - but that doesn't mean that it's not a sound commercial decision to use it.  To this point, you don't seem to be inclined to respond.

>> observation.  He wrote _adopting_ and rather than actually address what he said, you strawmanned it and said _playing with_.
>>  I hardly need to point out the difference.
>
> Playing with is the starting point for adoption. That is how programming languages gain traction. You start playing with it, then make some small things with it, if it does not disappoint it moves up the chain. C++ didn't start out big, neither did Python or most other languages. This is also how tools are adopted in larger projects. You make small projects (or pilots) first. But if you want to use tools in big projects you actually require external support for it from multiple parties to avoid lock-in and many other factors.

Gates made an interesting point a decade or more back about people impatiently overestimating what can be achieved in a couple of years and underestimating what can be achieved in a decade.  Humans have a bad intuition about the effects of compounded growth.  D seems to be growing quite quickly, but some people expect things to fall into a rigid stencil for what they think should happen when these things don't work like that - life unfolds at its own pace.

I hardly think lock-in is a relevant consideration for the present context.  I don't know what the threshold for big is these days either.


>> But you certainly have made many blanket statements about how others behave and should behave and it's my belief that you don't have a proper basis for doing so.
>
> I am describing how best practices affects decision making priorities. This is not "prescriptive", it is "descriptive".

Hume's distinction between is and ought is often misapplied.  But one can't get to ought from is, and what you call descriptive may reflect a slightly unusual perception of the world and certainly some value-judgements.  Nothing wrong with that, so long as one recognizes that.

> It does not relate to any particular party, but I certainly defend the viewpoint that long running projects in general better off picking a base that is supported and where the solutions to problems are known in advance.

One can speak in generalities, but perhaps it rather depends on what you are trying to accomplish.

>> We know that you think D is a toy language, although you also say that you aren't calling it a toy language.
>
> That's a rather manipulative assertion.

That's a statement about intent that is based on a poor reading.  And my statement - whatever you may perceive its intent to be - is based purely on what you have said (both that D is a toy language - in your view this being an entirely factual assertion - and that you are not calling D a toy language).

http://forum.dlang.org/search?q=ola+toy&scope=forum


>> Empirically speaking, some very smart people have built their business around D.
>
> And so they have around Visual Basic, Php, Javascript and just about any language imaginable.

Indeed, and each of these languages do have their merits, whether or not they are your or my cup of tea.  But the particular use cases are intriguing since they don't entirely fit with your narrative.

>> When you tell people like that that in effect they are idiots, you ought to have some basis if you wish to be taken seriously.
>
> Another manipulative assertion. I've never said anything about people who adopt D. They have their reasons, and their strategy. I have no interest in forming an opinion about what they do.

It's a constellation of points that doesn't fit with your theory.  When I see those, I wonder what I am missing.


>
>> You imply that this is a pattern, when I am not aware of such, and indeed, as Walter pointed out, a significant shift a few years back was from people saying "I'm a Java guy at work, but I use D for side projects" to "Here is how I use D at work".
>
> Walter has in the past been excruciatingly clear on D being a system level programming language and that competing with C# and other similar application level languages would be futile and not within the goals for him.
>
> If that has changed, I'd like to see him spell it out.

Interesting, but doesn't so much relate to your implication that C# &c programmers are driven away to which what I wrote was a response.  Languages have a life of their own, and intent changes as conditions change.  Pinning a label of applications language, scripting language, systems language etc seems to be much less useful in our age than previously.


>> avoid speaking about the ecosystem.  If Go didn't have nice networking libraries, its adoption would have been rather different.  These things are a package deal.
>
> Go is not a system level language as per today.

Indeed not, but we were talking about something different up to this point.  (You had said you didn't care about libraries, when that clearly makes a difference to the adoption of a language, understood as an ecosystem not a spec, and that was the topic at hand).


>> It's a big world, and even Andrei and Walter should not pretend that they understand all the possible ways in which people might use D and what might be important to them.  (And they don't).
>
> Actually, they should try to understand this for a defined target group. If not they will not be able to build a solid language that is competitive.

Thank you for your view.


Laeeth.

On Tuesday, 29 September 2015 at 17:22:30 UTC, jmh530 wrote:
> On Tuesday, 29 September 2015 at 15:31:30 UTC, Laeeth Isharc wrote:
>>
>> In my experience, risk is the excuse, and habit and human dislike of change is a much more powerful reason.
>>
>
> I love this line.

Thank you.  The sentiment I am sure came from someone else, but this has become etched in my consciousness through painful experience.

On Tuesday, 29 September 2015 at 17:33:04 UTC, Chris wrote:
> On Tuesday, 29 September 2015 at 05:52:13 UTC, Ola Fosheim Grøstad wrote:
>
>> This logic is very difficult to follow. Software project management is often done by people who are programmers. From a project health point of view D2 suffers from the same issues as C++, the language feature set makes it easy to create a mess, and therefore the demands of investments in the development process gets higher.
>
> You can create a mess in any language. Having written significant amounts of D code, I can tell you that D is very good at avoiding a mess.

I found this too, but would you care to elaborate on why specifically you think this is?  (I think it's perhaps not one big thing, but lots of little things.  One thinks almost of Isiah Berlin's Fox vs the Hedgehog - grand conceptual narratives vs vast knowing many little related things).  Small frictions have big consequences in the world we inhabit, and perhaps for that reason it's easy to underestimate the benefits of things that superficially seem to be nothing new.

>> This aspect is one significant reason for why languages like Go and Java are getting traction.
>
> Which confirms what I've observed. People prefer set menus, rules and strict guidelines - and D seems not to appeal to them due to the lack of an ideology.

That's also just a matter of time because there isn't much written on blogs etc.  (Not necessarily an ideology, I hope, but perhaps a culture of how to do things that is easier to perceive from the outside).  I think in a strange way the 2008 crisis was the beginning of the end for ideology - people are waking up and you can see it beginning to unleash this very creative new era.

> This is not my impression. Even "geeks" don't touch D (I know this from personal experience), even when there's no risk involved, e.g. when writing a small internal tool. As soon as they hear they have to learn about ranges and map!(a => to!string(a)) and the like, they lose interest. Fear or plain laziness ("couldn't be ar*sed"), one of the two. "I certainly won't learn D" is a comment I've heard myself.

Probably right today.  As a student of social trends though, it's funny how things shift though in ways that are utterly surprising and yet far from unpredictable if you are looking clearly and closely.

>> What tools can D successfully replace? Give a focused answer to that and you can improve on D to a level where it becomes attractive.
>
> One example that come immediately to mind is data processing in Python. A lot of it is parsing and counting which is much faster and often easier to do in D/Phobos.

Yes - see Andy Smith.  That's partly my own use too.  It's so much more pleasant to know that straight not particularly clever code I write will be reasonably efficient, and isn't hard to make efficient with a bit of effort from someone else.  Plus no dealing with runtime dependencies.  (If you think the D experience on Windows is subpar, try installing some python libraries - it doesn't always 'just work' in my experience, and the ready-made distros are great till you run into a snag).

I'm amazed not to see more discussion of the implications for relative trends in storage, network bandwidth, data generation vs memory bandwidth (and to an extent memory speed and CPU power).

I was searching for something the other day and came across some unix forum posts from 2006.  Apparently, a 1Tb SSD then cost more than a million bucks (maybe 1.5).  Looks like I can get one for not much more than 500 bucks today from Amazon.  The world hasn't yet adjusted to a 2,000 fold reduction in price.  If one struggles with python today with ordinary sized data sets, I wonder how things look in a decade?  (Which is why I asked if Facebook is an edge case or Gibson's unevenly distributed future).


>
>> But keep it real. Fear among programmers is not D's main issue.
>
> I think it is. It took me a while to realize this. Why is there this passionate hostility towards D? I don't go to a Go or Rust forum to tell them that I don't like this or that feature and that it's all crap. I've decided they're not the right tools for what I need and that's it.

That is certainly a puzzling feature of the world, one for which I don't have any answer.  I have noticed that people trying to achieve something difficult must often endure relentless criticism.  (Pick your favourite reform-minded political leader of the past viewed favourably today and go back and read the press of that time).

On Tuesday, 29 September 2015 at 17:52:54 UTC, Chris wrote:
>
> And don't forget a*se covering, risk aversion is often not much more than that. It's one of the most common things in organizations. If things go wrong, at least you stuck to the protocol, the the well-established, widely used language. So they can't get you there. If not they fry you, even if the failure is due to other things.

Yes - that is most of it.  The way that changes is some people are less driven by social factors, whether because of who they are or the situation they are in.  Some of these succeed, slowly perceptions change, and after a while it's the best thing since sliced bread.  But these things take time, and it's senseless to think one can know the moment of inflection points based on logical reasoning (since the timing depends on many other factors out of the scope of things one is familiar with - these factors are easier to spot with hindsight than in real time).

On Wednesday, 30 September 2015 at 04:59:22 UTC, H. S. Teoh wrote:
> I find these kinds of comments rather humorous, actually. Every once in a while, somebody would barge into the forum and decry the current state of things, bemoaning that D is too Linux-centric and that Windows gets no love.
>
> Then some time later, somebody else barges in, complaining about why he failed to install D on his Linux box and that the D developers must therefore be Windows people and D needs more Linux love.
>
> I've seen both types of complaints. So which is it? Is D Windows-centric or Linux-centric? Maybe the answer is neither, it's the PBCAK problem. ;-)
>

D is complaints-centric :)

On Tuesday, 29 September 2015 at 05:52:13 UTC, Ola Fosheim Grøstad wrote:
> D2 does not solve C++'s issues

Heartbleed?

On Wednesday, 30 September 2015 at 04:59:22 UTC, H. S. Teoh wrote:
> On Wed, Sep 30, 2015 at 04:32:52AM +0000, Mike Parker via Digitalmars-d wrote:
>> On Tuesday, 29 September 2015 at 22:05:48 UTC, rumbu wrote:
>> >My main complaints are also the compiler error messages ("Out of memory" is the most annoying one) and the Linux-centric approach of the development, but I'm far from being disgruntled.
>> 
>> I've never understood the "Linux-centric" complaint. I've been using D on Windows for 11 years with no problems. Hell, in the early days, Linux was the red-headed stepchild. DMD may not be deeply integrated into the MS ecosystem of dev tools (which could certainly be an issue for a Windows-only dev shop that uses Visual Studio and peripherals for everything), but that hardly makes it Linux-centric.
>
> I find these kinds of comments rather humorous, actually. Every once in a while, somebody would barge into the forum and decry the current state of things, bemoaning that D is too Linux-centric and that Windows gets no love.
>
> Then some time later, somebody else barges in, complaining about why he failed to install D on his Linux box and that the D developers must therefore be Windows people and D needs more Linux love.
>
> I've seen both types of complaints. So which is it? Is D Windows-centric or Linux-centric? Maybe the answer is neither, it's the PBCAK problem. ;-)
>
>
> T

I would believe that when core.sys.windows will have the same amount of code like core.sys.posix after the default installation. Or when the number of "This function is Windows only" remarks from phobos docs will surpass the number of "This function is posix only" remarks. Or when mscoff32 libs will be included in setup. Or when the libs from windows\lib will not have a content from 15 years ago.