Fredrik Olsson skrev:
> Dave skrev:
>> What else is stopping the adoption of D where you work (Kris and anyone else)?
>>
<snip>
> There are allot of project that are meant to "replace" or "merge into" Phobos. But perhaps what is needed is for Phobos to become an open project with many commiters, responsible for their parts. And a clear idea of what Phobos should be, if there where a clear goal I am sure I could make my company dedicate some resources to work towards it.
> 

Thought it over, we could dedicate one person full time (40 hours/week) from the beginning of April and then for about ten weeks for the task of writing and fixing code in Phobos.

But before we do, the big question is, where should the effort be made, and how so the time is not wasted?

// Fredrik Olsson

Dave wrote:

> What else is stopping the adoption of D where you work (Kris and anyone else)?

"const"    (as in http://en.wikipedia.org/wiki/Const_correctness, etc.)

Or maybe the C++ aficionados are just hiding behind such similar issues.
(like Multiple Inheritance or whatever else C++ has that D doesn't have)

--anders

Dave wrote:
> 
> What else is stopping the adoption of D where you work (Kris and anyone else)?

On the Windows side, that would be Microsoft.  We've got a relationship with the company and there was a big push to move to .NET a few years back.  That aside, it would be a tremendous task to convince the build team to maintain a server with software on it that had no support license and that they knew nothing about.  I had a hard enough time getting them to allow public library code--adding the need for new build scripts into the mix would give them fits.

On the Unix side, things are a bit more complex, but the real showstopper is that no D compilers currently target
64-bit machines.  Other issues would be compatibility with a fairly massive codebase in C++ and potentially the memory overhead required by GC bookkeeping as well.  Training is also a concern, though this may not be a huge problem as we have no official policy here.


Sean

Fredrik Olsson wrote:

> Fredrik Olsson skrev:
>> Dave skrev:
>>> What else is stopping the adoption of D where you work (Kris and
>>> anyone else)?
>>>
> <snip>
>> There are allot of project that are meant to "replace" or "merge into" Phobos. But perhaps what is needed is for Phobos to become an open project with many commiters, responsible for their parts. And a clear idea of what Phobos should be, if there where a clear goal I am sure I could make my company dedicate some resources to work towards it.
>> 
> 
> Thought it over, we could dedicate one person full time (40 hours/week) from the beginning of April and then for about ten weeks for the task of writing and fixing code in Phobos.
> 
> But before we do, the big question is, where should the effort be made, and how so the time is not wasted?
> 
> // Fredrik Olsson

This sounds really great! Although IMO, you should target Ares and not Phobos. Sean DO seem to have a plan, but not enough time. In any case, your time frame give us some time to plan.

I can see that working on the "official" standard library might be a better choice politically from your company, but I think that the development processes used in Phobos today, makes it hard to make fulltime contributions.

You should in any case take this question to the Ares forum over at dsource.

Other tasks that could be considered, involves working with the infrastructure, improving tools, e.g. debugger.

Lars Ivar Igesund

In article <dpcvfn$19g6$1@digitaldaemon.com>, Dave says...
>
>What else is stopping the adoption of D where you work (Kris and anyone else)?
>
>- Dave
>

I currently "work" at a university (I'm taking a master degree in physics, but will hopefully be a Ph.D. student by the end of this year.) The situation here is probably a lot different from a "normal" workplace.

Computer programming at my faculty is almost exclusively used for nummerical calculations and simulations, in everything from weather simulation to pure mathematics. Most simulation programs are relatively short, and designed specifically for solving exactly one task. That means that new, fresh programs are written all the time, and most people here aren't that good on code reuse. This means that the threshold for new languages should be low, since backward compatability and "baggage" isn't much of a problem. So I would say the main hindrance to D here is that nobody knows it, or has even heard about it.

The people here are not really that computer litterate, and not that "into" learning new languages and computer skills. Most people stick to the language they once learned to program in for the rest of their lives. The profs still use Fortran, new students mostly use C++, or Matlab for smaller tasks. (And I will probably use D for the rest of my life :-)

Another barrier is the lack of a preinstalled D compiler on university computers, although this can change if enough people demand it. (We would need a stable dmd 1.0 branch first, though.)

However, I think D is perfectly suited for nummerical programming: gc (don't have to worry (that much) about memory management), "safe" and easy to use dynamic arrays, modules, more sensible operator overloading, native complex numbers, writefln (easier than both printf and cout, we do a lot of text output), and it's as fast as C++. These are all features that make the language easier to use for an audience that's not really interested in learning the more complex aspects of programming. The only things that are lacking, in my opinion, are ports of the large math libraries like blitz++.

In conclusion, I think D might have a bright (no pun intended) future in nummerical computing, it only has to become more common and accepted first. The usual chicken-and-egg situation that all new inventions face at some point.

Nick

In article <dplmt0$10c1$1@digitaldaemon.com>, Nick says...
>
>In article <dpcvfn$19g6$1@digitaldaemon.com>, Dave says...
>>
>>What else is stopping the adoption of D where you work (Kris and anyone else)?
>>
>>- Dave
>>
>
>I currently "work" at a university (I'm taking a master degree in physics, but will hopefully be a Ph.D. student by the end of this year.) The situation here is probably a lot different from a "normal" workplace.
>
>Computer programming at my faculty is almost exclusively used for nummerical calculations and simulations, in everything from weather simulation to pure mathematics. Most simulation programs are relatively short, and designed specifically for solving exactly one task. That means that new, fresh programs are written all the time, and most people here aren't that good on code reuse. This means that the threshold for new languages should be low, since backward compatability and "baggage" isn't much of a problem. So I would say the main hindrance to D here is that nobody knows it, or has even heard about it.
>
>The people here are not really that computer litterate, and not that "into" learning new languages and computer skills. Most people stick to the language they once learned to program in for the rest of their lives. The profs still use Fortran, new students mostly use C++, or Matlab for smaller tasks. (And I will probably use D for the rest of my life :-)
>
>Another barrier is the lack of a preinstalled D compiler on university computers, although this can change if enough people demand it. (We would need a stable dmd 1.0 branch first, though.)
>
>However, I think D is perfectly suited for nummerical programming: gc (don't have to worry (that much) about memory management), "safe" and easy to use dynamic arrays, modules, more sensible operator overloading, native complex numbers, writefln (easier than both printf and cout, we do a lot of text output), and it's as fast as C++. These are all features that make the language easier to use for an audience that's not really interested in learning the more complex aspects of programming. The only things that are lacking, in my opinion, are ports of the large math libraries like blitz++.
>
>In conclusion, I think D might have a bright (no pun intended) future in nummerical computing, it only has to become more common and accepted first. The usual chicken-and-egg situation that all new inventions face at some point.
>
>Nick
>

Do you also think it would be a big help to have an easy-to-use installation package for Windows and Linux for the compiler, linker and base libs.?

I don't know if you've seen the posts on these topics or not, but some things for "version next" that may be of interest for numerical computing have been discussions on:

- Array operations. Besides the coding advantages, these should also allow for
optimizations like out-of-order execution, vectorization and avoiding aliasing
'de-optimizations'.
- Compilers (and libraries) may be able to use D first class arrays to better
optimize code. The current compilers are based on backends optimized for C/++.
- D GC's could perhaps be built to help provide better locality of reference
than malloc/free for things like large arrays allocated on the heap.
- Native machine precision for the real datatype (this is already part of the
language but the compiler backends don't take advantage of it right now,
optimization-wise).

Nick wrote:
> 
> In conclusion, I think D might have a bright (no pun intended) future in
> nummerical computing, it only has to become more common and accepted first. The
> usual chicken-and-egg situation that all new inventions face at some point.

I very much agree.  And I've always said that D would make an excellent teaching language, though getting it into the classroom might require a good book or two on D.


Sean

Sean Kelly wrote:
> Dave wrote:
>>
>> What else is stopping the adoption of D where you work (Kris and anyone else)?
> 
> On the Windows side, that would be Microsoft.  We've got a relationship with the company and there was a big push to move to .NET a few years back.  That aside, it would be a tremendous task to convince the build team to maintain a server with software on it that had no support license and that they knew nothing about.  I had a hard enough time getting them to allow public library code--adding the need for new build scripts into the mix would give them fits.
> 
> On the Unix side, things are a bit more complex, but the real showstopper is that no D compilers currently target
> 64-bit machines.  Other issues would be compatibility with a fairly massive codebase in C++ and potentially the memory overhead required by GC bookkeeping as well.  Training is also a concern, though this may not be a huge problem as we have no official policy here.
> 
> 
> Sean
Where is the real prof support?

  Standard good framework (libraries).

  Debugger... why there is not a good standard debugger?... I Can't think in a compiler without debugger... and D is producing complex structures that need some specific good debugger.

Antonio

"antonio" <antonio@abrevia.net> wrote in message news:dpmrjv$1tm1$1@digitaldaemon.com...
>   Debugger... why there is not a good standard debugger?...

There is, it comes on the Digital Mars CD.

Walter Bright wrote:
> "antonio" <antonio@abrevia.net> wrote in message news:dpmrjv$1tm1$1@digitaldaemon.com...
>>   Debugger... why there is not a good standard debugger?...
> 
> There is, it comes on the Digital Mars CD. 
> 
> 
For the D language? with classes inspection and so on?  is there any reference about in http://www.digitalmars.com/d/ ?

Sorry then.
Antonio