On Sunday, 20 January 2013 at 09:52:42 UTC, SaltySugar wrote:
> Why it isn't popular?  We must popularize it. There aren't any tutorials with D, books and other stuff. How about writing a D programming forum?



Because the implementation still has very fundamental problems, like structs being bitwise-copied when they shouldn't be.

Even that single issue by _itself_ causes numerous problems.

On Monday, January 21, 2013 02:01:42 Nick Sabalausky wrote:
> D does continue to face an uphill battle for mindshare: These days, most people who write code prefer to use languages that accept ANY grammatically-correct code and deliberately remain silent about all mechanically-checkable problems they can possibly ignore. Apparently this is because they prefer to manually write extra unittests so that only a subset of these errors are actually guaranteed to get caught (if there's any guarantee at all).

In my experience, most programmers don't want to write unit tests, so I suspect that the folks who are pushing for less strict languages generally aren't testing their code any better than the folks using strict languages are. I suspect that the main problem with folks wanting the compiler to just accept stuff is that too many of those folks started with scripting languages where you don't have compilation errors, because you don't compile anything.

- Jonathan M Davis

On Monday, 21 January 2013 at 07:20:59 UTC, Jonathan M Davis wrote:
> On Monday, January 21, 2013 02:01:42 Nick Sabalausky wrote:
>> D does continue to face an uphill battle for mindshare: These days,
>> most people who write code prefer to use languages that accept ANY
>> grammatically-correct code and deliberately remain silent about all
>> mechanically-checkable problems they can possibly ignore. Apparently
>> this is because they prefer to manually write extra unittests so that
>> only a subset of these errors are actually guaranteed to get caught
>> (if there's any guarantee at all).
>
> In my experience, most programmers don't want to write unit tests, so I
> suspect that the folks who are pushing for less strict languages generally
> aren't testing their code any better than the folks using strict languages
> are. I suspect that the main problem with folks wanting the compiler to just
> accept stuff is that too many of those folks started with scripting languages
> where you don't have compilation errors, because you don't compile anything.
>
> - Jonathan M Davis

If the goal is to increase the popularity of D, and if people prefer scripted languages over compiled, then a good place to start is to create an interpreter for D, thus allowing it to be used as a scripted language, and also retain the ability to be compiled for optimal performance.

This will _not_ cheapen D, it will strengthen it, because I can see plenty of serious programmers using the interpreter for faster coding. Later the code can be compiled once the job is done or needs to be tested in compiled form. There are also perfectly sane use cases for having the ability to embed an interpreter directly into an application.

If we can determine what will help move D towards greater adoption, and then prioritize what needs to be done to make it happen, then we'll move forward faster than just randomly bumping around.

--rt

On Monday, January 21, 2013 08:52:23 Rob T wrote:
> If the goal is to increase the popularity of D, and if people prefer scripted languages over compiled, then a good place to start is to create an interpreter for D, thus allowing it to be used as a scripted language, and also retain the ability to be compiled for optimal performance.

You can already do that. Assuming that dmd is installed in the right place, you can make your source file executable, put #!/bin/dmd at the top of it, and then run it. It'll be compiled and run. It's not interpreted, strictly speaking, but given how fast D compiles and how fast D code runs once it's been compiled, it'll be plenty fast.

- Jonathan M Davis

On Monday, 21 January 2013 at 07:20:59 UTC, Jonathan M Davis wrote:
> On Monday, January 21, 2013 02:01:42 Nick Sabalausky wrote:
>> D does continue to face an uphill battle for mindshare: These days,
>> most people who write code prefer to use languages that accept ANY
>> grammatically-correct code and deliberately remain silent about all
>> mechanically-checkable problems they can possibly ignore. Apparently
>> this is because they prefer to manually write extra unittests so that
>> only a subset of these errors are actually guaranteed to get caught
>> (if there's any guarantee at all).
>
> In my experience, most programmers don't want to write unit tests, so I
> suspect that the folks who are pushing for less strict languages generally
> aren't testing their code any better than the folks using strict languages
> are. I suspect that the main problem with folks wanting the compiler to just
> accept stuff is that too many of those folks started with scripting languages
> where you don't have compilation errors, because you don't compile anything.
>
> - Jonathan M Davis

We move from ruby on rail to Node.js for scalability reasons !!!!!!

On Monday, 21 January 2013 at 08:55:00 UTC, deadalnix wrote:
> On Monday, 21 January 2013 at 07:20:59 UTC, Jonathan M Davis wrote:
>> On Monday, January 21, 2013 02:01:42 Nick Sabalausky wrote:
>>> D does continue to face an uphill battle for mindshare: These days,
>>> most people who write code prefer to use languages that accept ANY
>>> grammatically-correct code and deliberately remain silent about all
>>> mechanically-checkable problems they can possibly ignore. Apparently
>>> this is because they prefer to manually write extra unittests so that
>>> only a subset of these errors are actually guaranteed to get caught
>>> (if there's any guarantee at all).
>>
>> In my experience, most programmers don't want to write unit tests, so I
>> suspect that the folks who are pushing for less strict languages generally
>> aren't testing their code any better than the folks using strict languages
>> are. I suspect that the main problem with folks wanting the compiler to just
>> accept stuff is that too many of those folks started with scripting languages
>> where you don't have compilation errors, because you don't compile anything.
>>
>> - Jonathan M Davis
>
> We move from ruby on rail to Node.js for scalability reasons !!!!!!

I always laugh when I read such things.

Back in 1999, I was doing web development in our own TCL Apache module, with a developed in-house framework (C/TCL), which was quite similar to Rails 1.0.

Around 2002, we started to migrate to C++/.NET (at the time only available to Microsoft partner companies like ours), because of scalability issues.

What this taught us is that if you want to really scale, only compiled languages will do a proper job.

Yet people seem not to learn from history.

--
Paulo

On Monday, 21 January 2013 at 08:09:45 UTC, Jonathan M Davis wrote:
> On Monday, January 21, 2013 08:52:23 Rob T wrote:
> You can already do that. Assuming that dmd is installed in the right place,
> you can make your source file executable, put #!/bin/dmd at the top of it, and
> then run it. It'll be compiled and run. It's not interpreted, strictly
> speaking, but given how fast D compiles and how fast D code runs once it's
> been compiled, it'll be plenty fast.


I have been always curious how the debugging occurs in that case? You need to go through gdb? Then, this is a real difference wrt an interpreted language, where the interpreter can be used interactively to examine variables in a given state.

D "script" seems to not allow that.

On Monday, 21 January 2013 at 14:12:30 UTC, eles wrote:
> On Monday, 21 January 2013 at 08:09:45 UTC, Jonathan M Davis wrote:
>> On Monday, January 21, 2013 08:52:23 Rob T wrote:
> I have been always curious how the debugging occurs in that case? You need to go through gdb? Then, this is a real difference wrt an interpreted language, where the interpreter can be used interactively to examine variables in a given state.

And step-by-step execution.

On Sun, Jan 20, 2013 at 11:19:58PM -0800, Jonathan M Davis wrote:
> On Monday, January 21, 2013 02:01:42 Nick Sabalausky wrote:
> > D does continue to face an uphill battle for mindshare: These days, most people who write code prefer to use languages that accept ANY grammatically-correct code and deliberately remain silent about all mechanically-checkable problems they can possibly ignore. Apparently this is because they prefer to manually write extra unittests so that only a subset of these errors are actually guaranteed to get caught (if there's any guarantee at all).
> 
> In my experience, most programmers don't want to write unit tests, so I suspect that the folks who are pushing for less strict languages generally aren't testing their code any better than the folks using strict languages are.
[...]

Before D, I never wanted to write unittests. They were cumbersome, required diversion from the task at hand, consumed extra effort, and were troublesome to remember to run separately every time you make some changes.

D's unittest blocks singlehandedly converted me. :)


T

-- 
Two wrongs don't make a right; but three rights do make a left...

What is best in my opinion - you can start to add tests even to projects that do not yet have them, without any build system tweaks or arguments about what unit test library to use. This makes it a habit - a good habit.
>
> Before D, I never wanted to write unittests. They were cumbersome,
> required diversion from the task at hand, consumed extra effort, and
> were troublesome to remember to run separately every time you make some
> changes.
>
> D's unittest blocks singlehandedly converted me. :)
>
>
> T