www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D's commercial weaknesses?

reply Dave <Dave_member pathlink.com> writes:
In article <dpci28$nq$1 digitaldaemon.com>, Kris says...

(Was: Re: Implementation-hiding clarification) All points well taken Kris; implementation hiding is an important topic, but I just don't have anything worthwhile to add. (Not trying to change or confuse the subject, just start a new thread because you brought up another vital point.) <snip>
 We should all understand that there's a lot of inertia against change in IT. 

Ain't that the truth. I could use the features of D as an improvement over ksh/perl/C/++ for quite a bit of what I happen to be doing right now, but I don't think it would fly... Even if they would let me re-compile GCC with D built-in (dmd won't run on this platform), I don't think I could develop anything but throw-away code right now just because of the potential need for someone else to maintain it, and because there is not any sort of formal training offered for D, which is a big thing where I'm at right now. Somehow D has to achieve that "buzz-word" status. How to do that? Writing articles is one way to help - what else?
To get a foot into the commercial segment, D needs as much help as it can 
possibly get in order to avoid being marginalized ~ even just keeping the 
darned lawyers out of the way. Implementation-hiding is one such aspect that 

I agree (not that I'm any more clear on how to actually accommodate mechanical implementation-hiding). "To get a foot into the commercial segment..." is one of the big reasons I'm a stickler about RT perf. "out of the box" if you will (meaning both good optimization and a language that doesn't get in the way). Everything I've been doing the last 5 years has demanded good performance and alot of time is spent on that. This is not a D weak point by any stretch, but I submit that D needs to stand-out in that area to get noticed.
helps. I can tell you that D is /not/ being considered where I work. Hence, 
I have a beef with certain weak attributes of the language and tools.

What else is stopping the adoption of D where you work (Kris and anyone else)? - Dave
Jan 02 2006
next sibling parent reply Fredrik Olsson <peylow treyst.se> writes:
Dave skrev:
 What else is stopping the adoption of D where you work (Kris and anyone else)?
 

there was an easy way to install GDC on Debian Linux. For stuff to out clients not, for these reasons; * Not easy enough to make libraries with header files that can be used from C * Phobos not quite as mature. In general I think D as a language is good to go as it is, but a language is never better than the standard library it comes with. C# is nothing without the .NET libraries, Java needs the 10.000+ classes in java.*, and Objective-C is quite useless without Cocoa/OpenStep. 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. // Fredrik Olsson
Jan 03 2006
parent reply Fredrik Olsson <peylow treyst.se> writes:
Fredrik Olsson skrev:
 Dave skrev:
 What else is stopping the adoption of D where you work (Kris and 
 anyone else)?


 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
Jan 05 2006
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Fredrik Olsson wrote:

 Fredrik Olsson skrev:
 Dave skrev:
 What else is stopping the adoption of D where you work (Kris and
 anyone else)?


 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
Jan 05 2006
prev sibling next sibling parent "Craig Black" <cblack ara.com> writes:
The reason that I don't use D is because it doesn't mesh with my C++ source 
code.  If only there was a good way of doing this.  It would be easier if 
there was link compatibility with VC++.  This would allow interop between 
existing code and D code through a C interface.  Code could be ported to D 
gradually.

I use Qt for cross platform C++ work and as far as I can tell, it doesn't 
compile with Digital Mars C++.  Thus, I simply cannot use D.

-Craig 
Jan 03 2006
prev sibling next sibling parent reply "Kris" <fu bar.com> writes:
"Dave" <Dave_member pathlink.com> wrote
 What else is stopping the adoption of D where you work (Kris and anyone 
 else)?

Do you have a private address to reply on?
Jan 03 2006
parent reply Dave <Dave_member pathlink.com> writes:
In article <dpf5bq$1def$1 digitaldaemon.com>, Kris says...
"Dave" <Dave_member pathlink.com> wrote
 What else is stopping the adoption of D where you work (Kris and anyone 
 else)?

Do you have a private address to reply on?

Sure: godaves yahoo.com - Dave
Jan 03 2006
next sibling parent reply "Kris" <fu bar.com> writes:
"Dave" <Dave_member pathlink.com> wrote
 Sure:

Thx
Jan 03 2006
parent reply "Charles" <noone nowhere.com> writes:
Why not share here where all can benefit ?  I'd personally like to know :).

Charlie


"Kris" <fu bar.com> wrote in message news:dpf797$1hg7$1 digitaldaemon.com...
 "Dave" <Dave_member pathlink.com> wrote
 Sure:

Thx

Jan 09 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Charles wrote:

 Why not share here where all can benefit ?  I'd personally like to know
 :).
 
 Charlie
 
 
 "Kris" <fu bar.com> wrote in message
 news:dpf797$1hg7$1 digitaldaemon.com...
 "Dave" <Dave_member pathlink.com> wrote
 Sure:

Thx


I suppose either Kris' or his company's opinions on the subject shouldn't be exposed in the public. Lars Ivar Igesund
Jan 09 2006
parent reply "Kris" <fu bar.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote ...
 Charles wrote:

 Why not share here where all can benefit ?  I'd personally like to know
 :).

 Charlie


 "Kris" <fu bar.com> wrote in message
 news:dpf797$1hg7$1 digitaldaemon.com...
 "Dave" <Dave_member pathlink.com> wrote
 Sure:

Thx


I suppose either Kris' or his company's opinions on the subject shouldn't be exposed in the public.

The latter ~ I'm quite generous with my own opinion :) Sorry, Charlie.
Jan 09 2006
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Kris wrote:

 
 "Lars Ivar Igesund" <larsivar igesund.net> wrote ...
 Charles wrote:

 Why not share here where all can benefit ?  I'd personally like to know
 :).

 Charlie


 "Kris" <fu bar.com> wrote in message
 news:dpf797$1hg7$1 digitaldaemon.com...
 "Dave" <Dave_member pathlink.com> wrote
 Sure:

Thx


I suppose either Kris' or his company's opinions on the subject shouldn't be exposed in the public.

The latter ~ I'm quite generous with my own opinion :) Sorry, Charlie.

I was sortof thinking of your opinion on your company's opinion ;)
Jan 09 2006
prev sibling parent pragma <pragma_member pathlink.com> writes:
In article <dpf6cf$1fh0$1 digitaldaemon.com>, Dave says...
In article <dpf5bq$1def$1 digitaldaemon.com>, Kris says...
"Dave" <Dave_member pathlink.com> wrote
 What else is stopping the adoption of D where you work (Kris and anyone 
 else)?



I'll bite. :) At my workplace, we're primarily a ColdFusion web shop with growing inclination toward Java. Java is gaining a larger and larger foothold since we got it for free on our webservers since we upgraded to CFMX. Since we have so much riding on this platform already, its unlikely that we'd ever switch unless there was some break-through technology that did stuff nobody's ever seen before. The same goes for any internal utils, as those will eventually have to be maintianed by other developers: so languages outside everyone's core skill set are further discouraged at this level too. D would have to replace the following technologies: - CFMX - Java - J2EE I think most of us here can fill in the blanks on the above, its just going to take more engineering on D/DSP/DDL/Mango/Whatever. D would also have to address the following business concerns as well or you'll never get such an entrenched institution to budge: - Training - Certification - Producivity Gains - Performance Gains - Installation and Maintainence Costs* - FOSS Licensing** Sadly, the confidence of this group can only go so far to address these points. The work simply has to look good on paper, and in a format suitable for non-technical types at that. Its an uphill battle, and it will take considerable effort to breach the current level of understanding for this new crop of technology. * Free, as in beer, still costs employee time. It is a common assumption that "free software" simply forwards the savings at the POS ($0) to the setup and maintanence costs due to it being an "inferior product". This leads to the conclusion that the net gain in savings is an illusion, and could indeed cost you more than a COTS product. Add to that the (sometimes false) security blanket of getting vendor support when purchasing a non-free product and you get a strong institutional opposition to free software. D's saving grace here is Mr. Bright and DigitalMars.com. Sadly, in non C-shops, neither are even close to familiar names. ** - With respect to FOSS, sometimes closed source shops can get the impression that *everything* open-source is GPL. While the GPL is a noble cause, the stigma it has placed on all FOSS (viral licensing) is the single biggest problem (IMO) to the adoption of BSD and Artistic License products -- non OSS-saavy people simply don't know the difference. - EricAnderton at yahoo
Jan 04 2006
prev sibling next sibling parent Carlos Santander <csantander619 gmail.com> writes:
Dave escribió:
 What else is stopping the adoption of D where you work (Kris and anyone else)?
 
 - Dave
 
 

At my work, there'd be three different answers. We're using .Net (C#) for presentation, mostly because it seems so easy (I'm not taking part of that, so I couldn't tell for sure). So if there was a somewhat similar (windowing) library for D with so many third-party controls as there are in .Net, then it could be considered. It's not so likely, though, because my company has some sort of agreement with Microsoft. For the backend, we're using WebSphere MQ/Message Broker/etc. That's were I'm working now. What's missing for D would be, well, all that's offered by those applications, which is basically message queues and the awful loads of integration easiness provided by it. Surely DDL is a step in that direction. But, again, my company has businesses with IBM. The final part would be some assorted programs written in C but need to be really high performant. What's needed for D here would be a 100% working compiler for AIX, HP-UX, Solaris, and many other Unices. So, that's it for getting D in my workplace. -- Carlos Santander Bernal
Jan 04 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Dave wrote:
 What else is stopping the adoption of D where you work (Kris and anyone else)?

The fact that D cannot use third party DLLs that only come with COFF import libs. No kidding. It's an absolute show stopper. Walters last post to this newsgroup has changed this situation completely. Bye-bye C++. (But I'm not really a programmer, it's only a small part of what I do. I'm employed for my knowledge of semiconductor device physics. My choice of programming language doesn't get much more attention than my choice of soldering iron. Noone has looked at any of my source code for about five years).
Jan 04 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
Don Clugston wrote:
 Dave wrote:
 
 What else is stopping the adoption of D where you work (Kris and 
 anyone else)?

The fact that D cannot use third party DLLs that only come with COFF import libs. No kidding. It's an absolute show stopper. Walters last post to this newsgroup has changed this situation completely. Bye-bye C++. (But I'm not really a programmer, it's only a small part of what I do. I'm employed for my knowledge of semiconductor device physics. My choice of programming language doesn't get much more attention than my choice of soldering iron. Noone has looked at any of my source code for about five years).

No wonder you're a mathematical template-programming freak! =P (This is a good thing). We need someone knowledgeable about numerical analysis to come in and fix the implementation and usage of floating point. Walter's already got a great start by separating real and ireal; now we need to propogate that down the line through the standard library/ies.
Jan 09 2006
parent reply John Reimer <terminal.node gmail.com> writes:
James Dunne wrote:
 Don Clugston wrote:
 Dave wrote:

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

The fact that D cannot use third party DLLs that only come with COFF import libs. No kidding. It's an absolute show stopper. Walters last post to this newsgroup has changed this situation completely. Bye-bye C++. (But I'm not really a programmer, it's only a small part of what I do. I'm employed for my knowledge of semiconductor device physics. My choice of programming language doesn't get much more attention than my choice of soldering iron. Noone has looked at any of my source code for about five years).

No wonder you're a mathematical template-programming freak! =P (This is a good thing). We need someone knowledgeable about numerical analysis to come in and fix the implementation and usage of floating point. Walter's already got a great start by separating real and ireal; now we need to propogate that down the line through the standard library/ies.

Ben Hinkle has been around for awhile too... Mathematics seems to be his background training (he has some Phd degree or something... you know, "Post-hole digger"?) ;). But I don't know how much involvement he had in working on these things although he's contributed much to D. -JJR
Jan 09 2006
next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
John Reimer wrote:
 James Dunne wrote:
 
 Don Clugston wrote:

 Dave wrote:

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

The fact that D cannot use third party DLLs that only come with COFF import libs. No kidding. It's an absolute show stopper. Walters last post to this newsgroup has changed this situation completely. Bye-bye C++. (But I'm not really a programmer, it's only a small part of what I do. I'm employed for my knowledge of semiconductor device physics. My choice of programming language doesn't get much more attention than my choice of soldering iron. Noone has looked at any of my source code for about five years).

No wonder you're a mathematical template-programming freak! =P (This is a good thing). We need someone knowledgeable about numerical analysis to come in and fix the implementation and usage of floating point. Walter's already got a great start by separating real and ireal; now we need to propogate that down the line through the standard library/ies.

Ben Hinkle has been around for awhile too... Mathematics seems to be his background training (he has some Phd degree or something... you know, "Post-hole digger"?) ;). But I don't know how much involvement he had in working on these things although he's contributed much to D. -JJR

Didn't mean to single anybody out. Yes, Ben Hinkle is also quite the contributor, but as of the last month or so, Don has really gotten quite excited about template meta-programming. Just an observation :)
Jan 09 2006
parent reply Don Clugston <dac nospam.com.au> writes:
James Dunne wrote:
 John Reimer wrote:
 
 James Dunne wrote:

 Don Clugston wrote:

 Dave wrote:

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

The fact that D cannot use third party DLLs that only come with COFF import libs. No kidding. It's an absolute show stopper. Walters last post to this newsgroup has changed this situation completely. Bye-bye C++. (But I'm not really a programmer, it's only a small part of what I do. I'm employed for my knowledge of semiconductor device physics. My choice of programming language doesn't get much more attention than my choice of soldering iron. Noone has looked at any of my source code for about five years).

No wonder you're a mathematical template-programming freak! =P (This is a good thing).



By a freak combination of events, I was in the local newspapers last week (has never happened before, will probably never happen again), so you can get an idea of what I look like and what I do: http://www.mz-web.de/servlet/ContentServer?pagename=ksta/page&atype=ksArtikel&aid=1135666230139&calledPageId=987490165154 Does that look like a computer scientist to you?? Does it even look like a mathematician??? The only subjects I failed at university were optics and electronics, so solar cells was the obvious career path :-)
 We need someone knowledgeable about numerical 
 analysis to come in and fix the implementation and usage of floating 
 point. Walter's already got a great start by separating real and 
 ireal; now we need to propogate that down the line through the 
 standard library/ies.



It's the real.nan, real.infinity and the NCEG operators that got me interested in D. Walter's done an amazing job at exposing the full glory of IEEE mathematics (better than asm, even!) It deserves *much* better library support. I would like to see the D standard libraries providing at least as good mathematical support as VBA does in Excel... There's a work-in-progress in dsource/mathextra. Some will be in DMD 0.143. The elementary functions sin(), exp(), etc for complex arguments are probably a necessity for D 1.0, and will be moved into Phobos as soon as D gets rid of the problematic implicit conversions real->creal, etc.
 Ben Hinkle has been around for awhile too... Mathematics seems to be 
 his background training (he has some Phd degree or something... you 
 know, "Post-hole digger"?) ;).  But I don't know how much involvement 
 he had in working on these things although he's contributed much to D.


I always thought that PhD stood for "permanent head damage". Ben seems to be almost completely occupied with Cx now, unfortunately.
 Didn't mean to single anybody out.  Yes, Ben Hinkle is also quite the 
 contributor, but as of the last month or so, Don has really gotten quite 
 excited about template meta-programming.  Just an observation :)

My #1 reluctance towards D came from the belief that D templates were much less powerful than C++ templates. I have entirely abandoned that belief :-). I think that if there were a few solid metaprogramming examples in the spec, hardcore C++ programmers wouldn't dismiss D as readily.
Jan 10 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message 
news:dq0can$234k$1 digitaldaemon.com...
 It's the real.nan, real.infinity and the NCEG operators that got me 
 interested in D. Walter's done an amazing job at exposing the full glory 
 of IEEE mathematics (better than asm, even!)

Back when I worked at Boeing, I wrote numerical analysis programs in FORTRAN. It's what made me interested in having good floating point support. Interestingly, about all this stuff was proposed for C at one time around 1990, but it fizzled for reasons I don't understand.
 It deserves *much* better library support. I would like to see the D 
 standard libraries providing at least as good mathematical support as VBA 
 does in Excel...

I agree.
 There's a work-in-progress in dsource/mathextra. Some will be in DMD 
 0.143. The elementary functions sin(), exp(), etc for complex arguments 
 are probably a necessity for D 1.0, and will be moved into Phobos as soon 
 as D gets rid of the problematic implicit conversions real->creal, etc.

Ok <g>.
 My #1 reluctance towards D came from the belief that D templates were much 
 less powerful than C++ templates. I have entirely abandoned that belief 
 :-). I think that if there were a few solid metaprogramming examples in 
 the spec, hardcore C++ programmers wouldn't dismiss D as readily.

I still think there's a killer magazine article here you should write!
Jan 10 2006
parent reply rko <rko_member pathlink.com> writes:
In article <dq10vh$2n82$1 digitaldaemon.com>, Walter Bright says...
"Don Clugston" <dac nospam.com.au> wrote in message 
news:dq0can$234k$1 digitaldaemon.com...
 It's the real.nan, real.infinity and the NCEG operators that got me 
 interested in D. Walter's done an amazing job at exposing the full glory 
 of IEEE mathematics (better than asm, even!)

Back when I worked at Boeing, I wrote numerical analysis programs in FORTRAN. It's what made me interested in having good floating point support. Interestingly, about all this stuff was proposed for C at one time around 1990, but it fizzled for reasons I don't understand.
 It deserves *much* better library support. I would like to see the D 
 standard libraries providing at least as good mathematical support as VBA 
 does in Excel...

I agree.
 There's a work-in-progress in dsource/mathextra. Some will be in DMD 
 0.143. The elementary functions sin(), exp(), etc for complex arguments 
 are probably a necessity for D 1.0, and will be moved into Phobos as soon 
 as D gets rid of the problematic implicit conversions real->creal, etc.

Ok <g>.
 My #1 reluctance towards D came from the belief that D templates were much 
 less powerful than C++ templates. I have entirely abandoned that belief 
 :-). I think that if there were a few solid metaprogramming examples in 
 the spec, hardcore C++ programmers wouldn't dismiss D as readily.

I still think there's a killer magazine article here you should write!

well i am glad that you guys have something to share. how about something usable for the rest of the world. a debugger, gui developer, and a lib for the all of us who do not specialize in math ??? rko rko
Jan 10 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
rko wrote:

 In article <dq10vh$2n82$1 digitaldaemon.com>, Walter Bright says...
"Don Clugston" <dac nospam.com.au> wrote in message
news:dq0can$234k$1 digitaldaemon.com...
 It's the real.nan, real.infinity and the NCEG operators that got me
 interested in D. Walter's done an amazing job at exposing the full glory
 of IEEE mathematics (better than asm, even!)

Back when I worked at Boeing, I wrote numerical analysis programs in FORTRAN. It's what made me interested in having good floating point support. Interestingly, about all this stuff was proposed for C at one time around 1990, but it fizzled for reasons I don't understand.
 It deserves *much* better library support. I would like to see the D
 standard libraries providing at least as good mathematical support as
 VBA does in Excel...

I agree.
 There's a work-in-progress in dsource/mathextra. Some will be in DMD
 0.143. The elementary functions sin(), exp(), etc for complex arguments
 are probably a necessity for D 1.0, and will be moved into Phobos as
 soon as D gets rid of the problematic implicit conversions real->creal,
 etc.

Ok <g>.
 My #1 reluctance towards D came from the belief that D templates were
 much less powerful than C++ templates. I have entirely abandoned that
 belief
 :-). I think that if there were a few solid metaprogramming examples in
 the spec, hardcore C++ programmers wouldn't dismiss D as readily.

I still think there's a killer magazine article here you should write!

well i am glad that you guys have something to share. how about something usable for the rest of the world. a debugger, gui developer, and a lib for the all of us who do not specialize in math ??? rko rko

I don't specialize in maths and find what's already present in the D realm highly usable. If I miss something, I either asks politely someone that seems to be into said subject, or try to fix it myself. As is pointed ut millions of times, Walter has only to arms, even though he has 50 fingers on each. Lars Ivar Igesund
Jan 10 2006
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"rko" <rko_member pathlink.com> wrote in message 
news:dq193m$2uvo$1 digitaldaemon.com...
 how about something usable

 for the rest of the world.
 a debugger,
 gui developer,
 and a lib for the all of us who do not specialize in math

 ???

There's plenty of room for contributions!
Jan 10 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <dpulrv$eo1$1 digitaldaemon.com>, John Reimer says...
Ben Hinkle has been around for awhile too... Mathematics seems to be his 
background training (he has some Phd degree or something... you know, 
"Post-hole digger"?) ;).  But I don't know how much involvement he had 
in working on these things although he's contributed much to D.

"Post-hole digger", LOL. I've always been told it /really/ means "Piled higher and Deeper". <g> B.S. - just that M.S. - More of the Same PhD. - Piled higher and Deeper
-JJR

Jan 09 2006
next sibling parent James Dunne <james.jdunne gmail.com> writes:
Dave wrote:
 In article <dpulrv$eo1$1 digitaldaemon.com>, John Reimer says...
 
Ben Hinkle has been around for awhile too... Mathematics seems to be his 
background training (he has some Phd degree or something... you know, 
"Post-hole digger"?) ;).  But I don't know how much involvement he had 
in working on these things although he's contributed much to D.

"Post-hole digger", LOL.

LOL! I totally missed that in my reply... Long day of work... urgh
 I've always been told it /really/ means "Piled higher and Deeper". <g>
 
 B.S. - just that
 M.S. - More of the Same
 PhD. - Piled higher and Deeper
 
 
-JJR


This brings back memories of one professor in particular who just thought that being a Systems Analyst with a PhD was about the best job you could get. He had this horrible cirlce-enclosing-circle-enclosing-circle diagram that he used to "prove" the difference between a technician, an engineer, and a PhD - want to strangle myself already just recalling it...
Jan 09 2006
prev sibling parent John Reimer <terminal.node gmail.com> writes:
Dave wrote:
 In article <dpulrv$eo1$1 digitaldaemon.com>, John Reimer says...
 Ben Hinkle has been around for awhile too... Mathematics seems to be his 
 background training (he has some Phd degree or something... you know, 
 "Post-hole digger"?) ;).  But I don't know how much involvement he had 
 in working on these things although he's contributed much to D.

"Post-hole digger", LOL. I've always been told it /really/ means "Piled higher and Deeper". <g> B.S. - just that M.S. - More of the Same PhD. - Piled higher and Deeper
 -JJR


:-D I've heard of the "Piled higher and Deeper" one too. Maybe "Post hole Digger" sticks more readily for me because that's exactly what I used to do, in the real sense of the phrase, in my younger days. Hey, there's nothing wrong with post hole digging! We all find purpose somewhere. :-) That list,above, is priceless, Dave. I don't think I've ever seen it summarized quite like that. -JJR
Jan 09 2006
prev sibling next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Dave wrote:

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

Ummm... Microsoft?
Jan 04 2006
parent James Dunne <james.jdunne gmail.com> writes:
John Reimer wrote:
 Dave wrote:
 
 What else is stopping the adoption of D where you work (Kris and 
 anyone else)?

Ummm... Microsoft?

Same here too. I've inquired about the reasons for the choice of platform (.NET). The answer boiled down to: 1) It's cheap through MSDN. 2) We're a Microsoft shop. We know MS SQL 2000, we know C# - the two work together with minimal pain. This is not MY opinion, mind you... ;)
Jan 09 2006
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 05 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Jan 05 2006
parent reply antonio <antonio abrevia.net> writes:
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

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
Jan 06 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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.
Jan 06 2006
parent reply antonio <antonio abrevia.net> writes:
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.

reference about in http://www.digitalmars.com/d/ ? Sorry then. Antonio
Jan 06 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"antonio" <antonio abrevia.net> wrote in message 
news:dpn5cl$24jc$1 digitaldaemon.com...
 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.


Yes, you can look at class members and locals with it. It's still a C debugger, but it does work.
Jan 06 2006
next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
 "antonio" <antonio abrevia.net> wrote in message 
 news:dpn5cl$24jc$1 digitaldaemon.com...
 
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?

Yes, you can look at class members and locals with it. It's still a C debugger, but it does work.

I think that's another "commercial weakness."
Jan 06 2006
prev sibling parent reply "Kris" <fu bar.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote ...
 For the D language? with classes inspection and so on?

Yes, you can look at class members and locals with it. It's still a C debugger, but it does work.

That's good news. Does it know about (and can therefore display) array contents? Delegates? Can it follow the correct source-file for all templates? Is there anything specific for D that it does not handle correctly?
Jan 06 2006
parent reply John Reimer <terminal.node gmail.com> writes:
Kris wrote:
 "Walter Bright" <newshound digitalmars.com> wrote ...
 For the D language? with classes inspection and so on?

debugger, but it does work.

That's good news. Does it know about (and can therefore display) array contents? Delegates? Can it follow the correct source-file for all templates? Is there anything specific for D that it does not handle correctly?

Ahem... I have to agree with Kris. Walter, this is a little bit of false advertising or providing a "shade" of truth. It's a debugger that works with D, but nobody that is new to this newsgroup would deduce from your above statement that the debugger doesn't support the debugging of several critical D features. Providing that statement without specific qualifications isn't fair. -JJR
Jan 06 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
John Reimer wrote:
 Kris wrote:
 
 "Walter Bright" <newshound digitalmars.com> wrote ...

 For the D language? with classes inspection and so on?

Yes, you can look at class members and locals with it. It's still a C debugger, but it does work.

That's good news. Does it know about (and can therefore display) array contents? Delegates? Can it follow the correct source-file for all templates? Is there anything specific for D that it does not handle correctly?

Ahem... I have to agree with Kris. Walter, this is a little bit of false advertising or providing a "shade" of truth. It's a debugger that works with D, but nobody that is new to this newsgroup would deduce from your above statement that the debugger doesn't support the debugging of several critical D features. Providing that statement without specific qualifications isn't fair. -JJR

Agreed. People are looking for a solution for D, not a hack for D pulled from your work with C/C++
Jan 07 2006
parent antonio <antonio abrevia.net> writes:
Kyle Furlong wrote:
 John Reimer wrote:
 Kris wrote:

 "Walter Bright" <newshound digitalmars.com> wrote ...

 For the D language? with classes inspection and so on?

Yes, you can look at class members and locals with it. It's still a C debugger, but it does work.

That's good news. Does it know about (and can therefore display) array contents? Delegates? Can it follow the correct source-file for all templates? Is there anything specific for D that it does not handle correctly?

Ahem... I have to agree with Kris. Walter, this is a little bit of false advertising or providing a "shade" of truth. It's a debugger that works with D, but nobody that is new to this newsgroup would deduce from your above statement that the debugger doesn't support the debugging of several critical D features. Providing that statement without specific qualifications isn't fair. -JJR

Agreed. People are looking for a solution for D, not a hack for D pulled from your work with C/C++

Antonio
Jan 07 2006
prev sibling parent reply kris <fu bar.org> writes:
John Reimer wrote:
 Kris wrote:
 
 "Walter Bright" <newshound digitalmars.com> wrote ...

 For the D language? with classes inspection and so on?

Yes, you can look at class members and locals with it. It's still a C debugger, but it does work.

That's good news. Does it know about (and can therefore display) array contents? Delegates? Can it follow the correct source-file for all templates? Is there anything specific for D that it does not handle correctly?

Ahem... I have to agree with Kris. Walter, this is a little bit of false advertising or providing a "shade" of truth. It's a debugger that works with D, but nobody that is new to this newsgroup would deduce from your above statement that the debugger doesn't support the debugging of several critical D features. Providing that statement without specific qualifications isn't fair. -JJR

Hold on there <g> That was a question; not an assertion :) It may be that Walter's debugger does all the right things?
Jan 07 2006
parent John Reimer <terminal.node gmail.com> writes:
kris wrote:

 Ahem... I have to agree with Kris.

 Walter, this is a little bit of false advertising or providing a 
 "shade" of truth.  It's a debugger that works with D, but nobody that 
 is new to this newsgroup would deduce from your above statement that 
 the debugger doesn't support the debugging of several critical D 
 features.

 Providing that statement without specific qualifications isn't fair.

 -JJR

Hold on there <g> That was a question; not an assertion :) It may be that Walter's debugger does all the right things?

You think so? :) Oh okay, maybe the querying style of getting to the root of the matter shows less aggression. Gentle is good... if that's the true intent. I apologize; I should have spoken for myself rather than appeared to be reinterpreting you. -JJR
Jan 07 2006
prev sibling next sibling parent reply Nick <Nick_member pathlink.com> writes:
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
Jan 06 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
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).
Jan 06 2006
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Dave wrote:

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

While a better installer would help, it's not a major concern. Just continue to ensure that an individual can run it within his own home directory (in case of an obstinate sysadmin). What's needed more is a better way to import C header files. Or a better way to link with C++ code. Or even a better way to smoosh an assemblage of several of the above together. It's good that people are working on native D libraries, but face it...there is a truly immense number of pre-existing libraries that will need to be linked to, and many of them depend on header files that include things like functions specified by macros, and other atrocities. Currently the only reasonable way to handle this is to write a chunk of C code with a nice interface that you call from D and which can handle the calls, but this is often a severe impedance mismatch, and with C++ it gets even worse. I don't know that this needs to be dealt with as a part of the language...and it clearly shouldn't happen before 1.0, but it is VERY important. -- Work in progress
Jan 08 2006
parent reply rko <rko_member pathlink.com> writes:
problems
debugging !!!
c lib reuse !!
easy gui development !!!
phobos should be developed to something like .net or java frameworks !!!!!
reuse of c++ libs !!!

those are the killer at my end, where i can only be boss and yell DO. probably
that will kill me in our project using D.

rko
Jan 09 2006
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
rko wrote:
 problems
 debugging !!!
 c lib reuse !!
 easy gui development !!!
 phobos should be developed to something like .net or java frameworks !!!!!
 reuse of c++ libs !!!
 
 those are the killer at my end, where i can only be boss and yell DO. probably
 that will kill me in our project using D.
 
 rko
 
 

I completly agree with this line: phobos should be developed to something like .net or java frameworks !!!!!
Jan 09 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
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
Jan 06 2006
prev sibling parent antonio <antonio abrevia.net> writes:
Dave wrote:
 In article <dpci28$nq$1 digitaldaemon.com>, Kris says...
 
 (Was: Re: Implementation-hiding clarification)
 
 All points well taken Kris; implementation hiding is an important topic, but I
 just don't have anything worthwhile to add. (Not trying to change or confuse
the
 subject, just start a new thread because you brought up another vital point.)
 
 <snip>
 
 We should all understand that there's a lot of inertia against change in IT. 

Ain't that the truth. I could use the features of D as an improvement over ksh/perl/C/++ for quite a bit of what I happen to be doing right now, but I don't think it would fly... Even if they would let me re-compile GCC with D built-in (dmd won't run on this platform), I don't think I could develop anything but throw-away code right now just because of the potential need for someone else to maintain it, and because there is not any sort of formal training offered for D, which is a big thing where I'm at right now. Somehow D has to achieve that "buzz-word" status. How to do that? Writing articles is one way to help - what else?
 To get a foot into the commercial segment, D needs as much help as it can 
 possibly get in order to avoid being marginalized ~ even just keeping the 
 darned lawyers out of the way. Implementation-hiding is one such aspect that 

I agree (not that I'm any more clear on how to actually accommodate mechanical implementation-hiding). "To get a foot into the commercial segment..." is one of the big reasons I'm a stickler about RT perf. "out of the box" if you will (meaning both good optimization and a language that doesn't get in the way). Everything I've been doing the last 5 years has demanded good performance and alot of time is spent on that. This is not a D weak point by any stretch, but I submit that D needs to stand-out in that area to get noticed.
 helps. I can tell you that D is /not/ being considered where I work. Hence, 
 I have a beef with certain weak attributes of the language and tools.

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

Debugger Framework (multi platform) Who D fundation or similar with A unique project and a lot of participants (D people working in a unique library... framework... the name is not important)... And Walter working in a real debugger... Something similar to "Mono project producing an alternative .Net platform" When As son as possible. Why Because there is a lot of languages produced as "the best one" that offers this 2 main features... and it is the best beginning for professional developments. Actually, I have to use Delphi or c++ for productivity reasons and it's impossible to convince that D is better... because this is false 90%... it could be different when only 50% is false :-) thanks and sorry
Jan 10 2006