www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Necessities for Adoption of D

reply "Hans W. Uhlig" <huhlig clickconsulting.com> writes:
Good morning everyone,
	I am new to the D forums but I have been following D's progress for a 
good while.

The topic seems to pop up quite a bit and was mentioned in the very long 
Standard Library Concerns thread about adoption for new users. Coming 
from C and then Java and now Looking at D. There are many things sun did 
  right with Java and some things that they still need to work on but I 
figure I will toss in my .02 and let people shoot each one down in turn.

1) Lots of example code & documentation - This one may sound silly, but 
if you want to do nearly anything in Java as a programmer, you can enter 
in Google "Java <thing I want to do>" and find something from sun on the 
topic. This makes it simple for new users.

2) A single standard library for most tasks - The whole Phobos here and 
Tango there and DWT someplace else makes picking up a language 
difficult. Not only that but as a Java Instructor I can simply point to 
the Sun java & javax library sets available and say here is something 
that can do that. In Suns case it may not do it well but its there.

3) Good automatic documentation library for EVERYTHING - Being able to 
search and find all the information on a Java library in the same format 
and the same style no matter what library I look at makes using the 
language easier and usually faster for development.

3) Good, native parallelism - With dual core, quad core, or in IBM's 
Cell  processor Obscene core processors, none of the current C Syntax 
family is parallelism handled natively and "well".

4) Write once, run everywhere. - This one may make me sound like a loon 
but Sun had the right idea. Just not the bast implementation. I will 
clarify however I said Write once, not compile once. Most system 
specific tasks for application level programming are handled by the 
standard library. This includes gui integration, simple and native cross 
compile tools and integrated tar/compression support.

5) A library packager - The scripting languages got it right with cpan, 
simple quick, easy, no complex installation instructions, just cpan 
install x. Being able to do this and keep your libraries up-to-date 
quickly and easily is a godsend to most programmers. DSource is nice, 
but it lacks a lot in usability, and being able to figure out core from 
cruft.

6) Well supported exterainious libs - In java if you need an xml library 
there are 30, in perl if you need a mysql link, there is one that is 
regularly updates. This one takes people using the language and doing 
such things but its important none the less. There is no reason to 
reinvent the wheel 10 times when someone has done it for you. (I am well 
aware that many programmers will reinvent the wheel 'right' again anyway)

7) A Good IDE, with debugging, stress testing & Benchmarking - Sounds 
odd but being able to time a function or stress test something across 
all possible values from your IDE is a beautiful thing, as is good 
debugging, syntax coloring and all the other nifty little things that 
Eclipse and Visual Studio have done right.

And my final bullet for this memo which is far longer then I thought it 
would be

8) Unified Thought in Paradime - Right now I see in the community a 
divergence in idea between C style functions, C++ style classes and a 
cleaner java style classes. (My preference is C functions and java 
classes but thats just me) Choose your options and unify that in the 
library. Do what perl did in premise and have oo or function style(yes I 
am aware this is older libs like CGI but I dont care for the argument). 
Integrate Both paradimes into the core logic of your libraries or focus 
on one. But don't develop libraries that compete.

Feel free to shoot and flame all you like but I figured a Pointy Haired 
Programmers opinion from a newcomer might spark some valuable discussion.

Hans W. Uhlig
Engineer
Click Consulting, Inc.
Feb 09 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Hans W. Uhlig:

 3) Good automatic documentation library for EVERYTHING


The ddoc seems a good starting point, do you know it? (But I think such things
don't need to built in the compiler).



 This includes gui integration,


Having a standard GUI toolkit built-in in the standard library is quite
positive (like Delphi, Python, etc).

Bye,
bearophile
Feb 09 2008
prev sibling next sibling parent reply "Tyro[a.c.edwards]" <no spam.com> writes:
Hans W. Uhlig さんは書きました:

 Good morning everyone,
     I am new to the D forums but I have been following D's progress for 
 a good while.
 
 2) A single standard library for most tasks - The whole Phobos here and 
 Tango there and DWT someplace else makes picking up a language 
 difficult. Not only that but as a Java Instructor I can simply point to 
 the Sun java & javax library sets available and say here is something 
 that can do that. In Suns case it may not do it well but its there.
 


I boggles the hell out of me every time someone comes and complains that 
there are more than one standard library. I have never had that problem 
and I can attest to you that my programming experience pales in 
comparison to anyone on this newsgroup. There has only ever been one 
standard library. Tango and its predecessor "Mango" was created because 
patches submitted to Phobos were not readily implemented. But instead of 
sitting around and complain about it, people actually took a positive 
step to address the situation. It grew into what it is today because the 
creators believe in what they are doing and continue to develop their 
product. Of course, a good following (aka user base) is always a morale 
booster. But if I recall correctly, the Tango Team has never claimed 
that they are the standard and Walter has never endorsed it as the 
"Other Standard". Don't get me wrong, it is a damn good library and 
could easily become the standard. But as I sit here typing this message 
it is most definitely not a standard.

This is plain asinine. Most, if not all complaints of this sort claim 
that new users are hampered because the website is badly designed, there 
are two standard libraries, there is no IDE, debugging support is 
nonexistent or under par and the list goes on and on. As a novice 
programmer, I’m here to tell you that these claims do not apply to 
people who really want to learn the language. I really doesn’t even 
require you to understand what you are doing to learn this language. 
I’ve ported the Mersenne Twister on two separate occasions (both 
original and SIMD versions) to D, and while I learned a little more 
about D in the process of doing so, I still do not understand a whole 
lot about programming. The amazing thing about this is that I learned 
and did it all without any documentation other than the D website, the 
source code, and asking a few questions here and there. My debugger was 
me, my IDE was first notepad then I upgraded to UltraEdit because the 
job paid for it. I used the only standard library D has: Phobos.

I've been able to do in D what I still cannot do in C++ which has only 
one "STANDARD LIBRARY" and thousands of volumes of books dedicated to 
explaining its every intricate detail. I've spent in excess of $5000 
dollars to learn C++ and still cannot do in it what I can do in D on 
which I've spent $0. Sorry, make that $10 since I did buy "Learn to 
Tango with D". The language is not that difficult to learn especially if 
you are a novice and have no preconceived ideas about what programming 
should be. For those who come across with preconceived ideas, the site 
provides enough to explain differences between D and C, D and C++, D and 
JAVA and so on… To me, that is all you should require if you are an 
experienced programmer.

Yes, bells and whistles can make easier. But is that truly a 
showstopper? I don’t think so.

Regards,
Andrew
Feb 09 2008
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Tyro[a.c.edwards] wrote:
[ snip ]

 Yes, bells and whistles can make easier. But is that truly a 
 showstopper? I don’t think so.


It can be a showstopper if you're trying to get stuff done. It's not a 
showstopper if you want to learn the language.

To give an example, MonoDevelop in Linux doesn't have a decent GUI 
designer[1], which would be a showstopper for many companies attempting 


designer; it just takes a lot longer and ends up with worse results.


[1] Your mileage may vary. I found it quite difficult to use.
Feb 09 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Christopher Wright wrote:

 To give an example, MonoDevelop in Linux doesn't have a decent GUI 
 designer[1], ...


My mistake. It has a halfway decent GUI designer, and I just didn't 
understand how Gtk works.
Feb 10 2008
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Sun, 10 Feb 2008 08:26:42 +0900, Tyro[a.c.edwards] wrote:


 Hans W. Uhlig さんは書きました:

 Good morning everyone,
     I am new to the D forums but I have been following D's progress for
 a good while.
 
 2) A single standard library for most tasks - The whole Phobos here and
 Tango there and DWT someplace else makes picking up a language
 difficult. Not only that but as a Java Instructor I can simply point to
 the Sun java & javax library sets available and say here is something
 that can do that. In Suns case it may not do it well but its there.
 
 


 I boggles the hell out of me every time someone comes and complains that
 there are more than one standard library. I have never had that problem
 and I can attest to you that my programming experience pales in
 comparison to anyone on this newsgroup. There has only ever been one
 standard library. Tango and its predecessor "Mango" was created because
 patches submitted to Phobos were not readily implemented. But instead of
 sitting around and complain about it, people actually took a positive
 step to address the situation. It grew into what it is today because the
 creators believe in what they are doing and continue to develop their
 product. Of course, a good following (aka user base) is always a morale
 booster. But if I recall correctly, the Tango Team has never claimed
 that they are the standard and Walter has never endorsed it as the
 "Other Standard". Don't get me wrong, it is a damn good library and
 could easily become the standard. But as I sit here typing this message
 it is most definitely not a standard.
 
 This is plain asinine. Most, if not all complaints of this sort claim
 that new users are hampered because the website is badly designed, there
 are two standard libraries, there is no IDE, debugging support is
 nonexistent or under par and the list goes on and on. As a novice
 programmer, I’m here to tell you that these claims do not apply to
 people who really want to learn the language. I really doesn’t even
 require you to understand what you are doing to learn this language.
 I’ve ported the Mersenne Twister on two separate occasions (both
 original and SIMD versions) to D, and while I learned a little more
 about D in the process of doing so, I still do not understand a whole
 lot about programming. The amazing thing about this is that I learned
 and did it all without any documentation other than the D website, the
 source code, and asking a few questions here and there. My debugger was
 me, my IDE was first notepad then I upgraded to UltraEdit because the
 job paid for it. I used the only standard library D has: Phobos.
 
 I've been able to do in D what I still cannot do in C++ which has only
 one "STANDARD LIBRARY" and thousands of volumes of books dedicated to
 explaining its every intricate detail. I've spent in excess of $5000
 dollars to learn C++ and still cannot do in it what I can do in D on
 which I've spent $0. Sorry, make that $10 since I did buy "Learn to
 Tango with D". The language is not that difficult to learn especially if
 you are a novice and have no preconceived ideas about what programming
 should be. For those who come across with preconceived ideas, the site
 provides enough to explain differences between D and C, D and C++, D and
 JAVA and so on… To me, that is all you should require if you are an
 experienced programmer.
 
 Yes, bells and whistles can make easier. But is that truly a
 showstopper? I don’t think so.
 
 Regards,
 Andrew


Your right, if someone wants to learn D they will. The problem is that we 
have to convince people that they want to learn the language. This my not 
sound to hard because of D's simplicity and power compared to its 
competition.

The conflicts and things that are missing will drive people away, or it 
give them something to point at to explain why they don't want to spend 
time learning it. These people are looking at D and are saying, "I have 
all these tools in my language, and know what I am doing." Then you have 
the new programmers that aren't set in their ways. The problem here is 
that one company is hiring D coders.
Feb 09 2008
prev sibling parent reply "Hans W. Uhlig" <huhlig clickconsulting.com> writes:
Tyro[a.c.edwards] wrote:

 Hans W. Uhlig さんは書きました:

 Good morning everyone,
     I am new to the D forums but I have been following D's progress 
 for a good while.

 2) A single standard library for most tasks - The whole Phobos here 
 and Tango there and DWT someplace else makes picking up a language 
 difficult. Not only that but as a Java Instructor I can simply point 
 to the Sun java & javax library sets available and say here is 
 something that can do that. In Suns case it may not do it well but its 
 there.


 
 I boggles the hell out of me every time someone comes and complains that 
 there are more than one standard library. 


Having several libraries that do the same thing, are fully community 
supported and do things radically different are wonderful for confusing 
new users. As was mentioned in another thread, the concept of objects is 
radically different between the two "standard" libraries, this is an 
aweful way to unify your platform and make it "popular" which is what 
deems any language to success or failure in use.


 I have never had that problem 
 and I can attest to you that my programming experience pales in 
 comparison to anyone on this newsgroup. There has only ever been one 
 standard library. Tango and its predecessor "Mango" was created because 
 patches submitted to Phobos were not readily implemented. 


For a "supplementary library" I find it funny that its not released as a 
set of source files to be added to a compiler or a set of libs for 
version x, for version y, or version zed. Its distributed as a set of 
libs, compiler, linker, make & debugger. This to me smacks not only of a 
standard library but nearly a full fork based on said library.


 But instead of 
 sitting around and complain about it, people actually took a positive 
 step to address the situation. It grew into what it is today because the 
 creators believe in what they are doing and continue to develop their 
 product. Of course, a good following (aka user base) is always a morale 
 booster. But if I recall correctly, the Tango Team has never claimed 
 that they are the standard and Walter has never endorsed it as the 
 "Other Standard". 


Well I will address this as two pieces, First, having a community driven 
project is a wonderful thing. It tends to do two things, increase 
submitted code and exponentially increase scope creep. Now, neither is 
bad for a standard library as long as someone is managing all these 
pieces and cleaning them up afterwards. However since the majority of 
vocal users here seem to think tango is the future and phobos was a 
wonderful stepping stone development library for Dv1, perhaps its time 
to look at what will get solidified for D2 and ensure some common 
standards for the future.

As to the second comment you made, even if the Tango Team does not say 
we are the new standard, the community seems to have made up its mind 
that it is. Since Phobos is not being updated well and needs some code 
rewrites(noting the IO speeds and a few other areas) perhaps this isnt a 
bad thing. As D is a growing language it can go through changes and even 
entire library sets.


 Don't get me wrong, it is a damn good library and 
 could easily become the standard. But as I sit here typing this message 
 it is most definitely not a standard.
 


Perhaps you should look at why your peers seem to think it is.



 This is plain asinine. Most, if not all complaints of this sort claim 
 that new users are hampered because the website is badly designed, there 
 are two standard libraries, there is no IDE, debugging support is 
 nonexistent or under par and the list goes on and on. 


All of those are killers to your average code money, remember, they are 
told to code, not think. D seems to sit where linux is right now, It is 
a beautiful product with lots of future, proven ideas, a good community 
and about as much continuity and polish as a train wreck.
No quality IDE(some are getting there but not there yet), no good 
debuggers or the IDE to use with them,and a badly designed website 
without good documentation wont attract the attention of companies. 
These same companies who say "I need to use D! It will decrease 
development time, increase productivity and lower my support costs." and 
then funnel large amounts of money into developing the few rough areas. 
This includes mainstream IDE support, and loads of other things.



 As a novice
 programmer, I’m here to tell you that these claims do not apply to 
 people who really want to learn the language. 


My comment is for anyone who wishes to learn the language for usage, not 
necessarily for pleasure. If you learn said languages for pleasure then 
your niche of people will be small and your languages usage will be so 
as well. If your language is powerful, easy to use and easy to learn by 
ANYONE including the 9-5 code monkeys who their boss says we need X 
written in Zed then it serves a far larger crowd.


 I really doesn’t even
 require you to understand what you are doing to learn this language. 


I beg to differ. Most lower end programmers don't understand a command 
line let alone linkers, and debuggers. Visual Studio, Komodo and 
Eclipse/Netbeans are as far as they go.


 I’ve ported the Mersenne Twister on two separate occasions (both 
 original and SIMD versions) to D, and while I learned a little more 
 about D in the process of doing so, I still do not understand a whole 
 lot about programming. 


To write that complex an algorithm and no know much about programming 
you are either an idiot savant or a liar.


 The amazing thing about this is that I learned
 and did it all without any documentation other than the D website, the 
 source code, and asking a few questions here and there. My debugger was 
 me, my IDE was first notepad then I upgraded to UltraEdit because the 
 job paid for it. I used the only standard library D has: Phobos.


And my father walked up hills both ways in the snow & rocks without 
shoes because thats what he had. So when it came to us, he paved the 
road, bought us shoes and gave us a segway. Were learn a whole lot more 
  at school now then he did.


 
 I've been able to do in D what I still cannot do in C++ which has only 
 one "STANDARD LIBRARY" and thousands of volumes of books dedicated to 
 explaining its every intricate detail. I've spent in excess of $5000 
 dollars to learn C++ and still cannot do in it what I can do in D on 
 which I've spent $0. 


Notice my argument failed to mention C++. I have written code in c++ and 
found its object orientation and standard library to be painful to use. 
http://www.phy.duke.edu/~rgb/Beowulf/c++_interview/c++_interview.html 
while tongue in cheek seems to be very poignant. C++ was an attempt to 
bring OO to a procedural language without breaking anything. I find most 
real systems programmers still prefer C over C++. Isn't this why Walter 
Wrote D rather then C+2?

I will however note that spending loads of money on books at this point 
in free communication is a laugh. You can learn C from 50-100 sites on 
the internet without spending a dime on direct material. Same goes for 
most any language you care to learn. So the number of trees you cut down 
for your library in this argument has very little sway, times have changed.


 Sorry, make that $10 since I did buy "Learn to 
 Tango with D". The language is not that difficult to learn especially if 
 you are a novice and have no preconceived ideas about what programming 
 should be. 


Since this is plesant conversation, how is the book? I was looking to 
pick it up as a reference since there is a limit on the online material 
available.


 For those who come across with preconceived ideas, the site 
 provides enough to explain differences between D and C, D and C++, D and 
 JAVA and so on… To me, that is all you should require if you are an 
 experienced programmer.


Preconceived ideas, tested solutions and methods seem to be what D is 
sold as. 30 years of experience from all languages brought together in 
one tight clean package written to be easy to learn and easy to use. Or 
perhaps I misread Walter's sales pitch.


 
 Yes, bells and whistles can make easier. But is that truly a 
 showstopper? I don’t think so.


Bells, whistles, the entire percussion section, and a missing lead 
singer could stop the show, or at least delay it. Perhaps we should let 
the band in, and let the understudy take the stage.


 
 Regards,
 Andrew


Sincerely,
   Hans W. Uhlig
Feb 09 2008
next sibling parent "Neil Vice" <psgdg swiftdsl.com.au> writes:
 Having several libraries that do the same thing, are fully community 
 supported and do things radically different are wonderful for confusing 
 new users. As was mentioned in another thread, the concept of objects is 
 radically different between the two "standard" libraries, this is an 
 aweful way to unify your platform and make it "popular" which is what 
 deems any language to success or failure in use.


My only complaint with the "two standard libs" issue is their 
incompatibility. The idea of writing a library for a language that replaces 
Object thereby breaking compatibility with any "standard" code sounds like 
madness to me.

Besides that, as wonderful as it would be to have all the tools you'll ever 
need already written for you in exactly the manner you'd choose, that is 
very unlikely to ever occur no matter what the development model. I like the 
idea that people write libraries for themselves and make them publicly 
available. If you like them, use them; if you don't, don't. It only affects 
me negtively when a library like Tango breaks compatibility.


 This is plain asinine. Most, if not all complaints of this sort claim 
 that new users are hampered because the website is badly designed, there 
 are two standard libraries, there is no IDE, debugging support is 
 nonexistent or under par and the list goes on and on.


 All of those are killers to your average code money, remember, they are 
 told to code, not think. D seems to sit where linux is right now, It is a 
 beautiful product with lots of future, proven ideas, a good community and 
 about as much continuity and polish as a train wreck.
 No quality IDE(some are getting there but not there yet), no good 
 debuggers or the IDE to use with them,and a badly designed website without 
 good documentation wont attract the attention of companies. These same 
 companies who say "I need to use D! It will decrease development time, 
 increase productivity and lower my support costs." and then funnel large 
 amounts of money into developing the few rough areas. This includes 
 mainstream IDE support, and loads of other things.


A would love to see a great D IDE with all the features mentioned and more. 
Of course I'd also love a great C++ IDE - I've still yet to find one. It 
strikes me as a massive project and one that IMHO comes second to polishing 
the language itself.


 I beg to differ. Most lower end programmers don't understand a command 
 line let alone linkers, and debuggers. Visual Studio, Komodo and 
 Eclipse/Netbeans are as far as they go.


More's the pity.


 The amazing thing about this is that I learned
 and did it all without any documentation other than the D website, the 
 source code, and asking a few questions here and there. My debugger was 
 me, my IDE was first notepad then I upgraded to UltraEdit because the job 
 paid for it. I used the only standard library D has: Phobos.


 And my father walked up hills both ways in the snow & rocks without shoes 
 because thats what he had. So when it came to us, he paved the road, 
 bought us shoes and gave us a segway. Were learn a whole lot more at 
 school now then he did.


Whereas I'm still struggling to make it up the hill at all. I'd much rather 
sufficient tools soon than ideal tools eventually. Every time I go to write 
a struct I come across some language or compiler "odity" that isn't 
explained in the brief specification, crashes the compiler or is even a 
legitimate, though unintuitive initially to me, language feature that I'd 
love to have explained to me but haven't.

Now as much as some of my complaints may apply to 1.0 admittedly I am 
working with 2.0. It is of course an alpha and you expect plenty of hiccups, 
but I would have thought you should also expect to be able to have some way 
of going about getting them resolved. The open source front-end is little 
help if I can't compile it to attempt patches and, for example, nobody has 
yet explained to me why I need to write a redundant opCall just to make a 
copy of a struct?

Please excuse my rant but I find myself quickly losing patience with D2 and 
thinking about 'going back' to C++ primarily due to a lack of documentation 
and not because of a lack of IDE or complete std-lib.

*vent complete*
Feb 09 2008
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Sat, 09 Feb 2008 19:10:14 -0800, Hans W. Uhlig wrote:


 Since this is plesant conversation, how is the book? I was looking to
 pick it up as a reference since there is a limit on the online material
 available.
 
 Sincerely,
    Hans W. Uhlig


Hans, the book is great. I wouldn't say it is a great reference though, 
its missing an index. I'll have to do some more coding before I know its 
reference quality.
Feb 09 2008
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Hans W. Uhlig wrote:


 I have never had that problem
 and I can attest to you that my programming experience pales in
 comparison to anyone on this newsgroup. There has only ever been one
 standard library. Tango and its predecessor "Mango" was created because
 patches submitted to Phobos were not readily implemented.


 
 For a "supplementary library" I find it funny that its not released as a
 set of source files to be added to a compiler or a set of libs for
 version x, for version y, or version zed. Its distributed as a set of
 libs, compiler, linker, make & debugger. This to me smacks not only of a
 standard library but nearly a full fork based on said library.


This has nothing to do with forking, but rather the fact that to use Tango
you need to replace the parts of the DMD package that makes D tick. Of
course we want people to use our library, and it will be easier for them if
they can download all they need in a step less. We did go pretty please
with Walter to make this happen. An additional facet of this is that every
few releases of DMD, it gains a bug that breaks Tango, and by distributing
the compiler ourselves, we can better minimize questions related to faulty
compilers.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Feb 10 2008
prev sibling parent reply "Tyro[a.c.edwards]" <no spam.com> writes:
Hans W. Uhlig さんは書きました:

 Tyro[a.c.edwards] wrote:

 Hans W. Uhlig さんは書きました:





 I’ve ported the Mersenne Twister on two separate occasions (both 
 original and SIMD versions) to D, and while I learned a little more 
 about D in the process of doing so, I still do not understand a whole 
 lot about programming. 


 
 To write that complex an algorithm and no know much about programming 
 you are either an idiot savant or a liar.


I am many thing... but a liar is absolutely not one of them. If I'm made
to conform to your prolarized concept of human knowledge and programming
ability, then I will have to say I stand in the camp of idiot savants
all by my lonesome. I tend to think I can simply read and follow the
simple instructions provided by on the website, which in my mind take
common sense, not understanding.


  > The amazing thing about this is that I learned

 and did it all without any documentation other than the D website, the 
 source code, and asking a few questions here and there. My debugger 
 was me, my IDE was first notepad then I upgraded to UltraEdit because 
 the job paid for it. I used the only standard library D has: Phobos.


 
 And my father walked up hills both ways in the snow & rocks without 
 shoes because thats what he had. So when it came to us, he paved the 
 road, bought us shoes and gave us a segway. Were learn a whole lot more 
  at school now then he did.
 


And ofcourse if we should lose our road due to an unfortunate earthquake
most of us would all sit around complaining because we've never walked
over a hill in our life. Those that took the time to walk up a few hills
eventhough the didn't have to would have not be hampered by this
problems and would simply fall back on this experience until such time
when the roads were rebuiled.


 Sorry, make that $10 since I did buy "Learn to Tango with D". The 
 language is not that difficult to learn especially if you are a novice 
 and have no preconceived ideas about what programming should be. 


 
 Since this is plesant conversation, how is the book? I was looking to 
 pick it up as a reference since there is a limit on the online material 
 available.


It is great to the point I've read. I've not yet complete reading it so
I cannot give you a complete review. I'd venture to say that if they
wrap things up they way they started, it will turn out to be a very good
book indeed.


 

 For those who come across with preconceived ideas, the site provides 
 enough to explain differences between D and C, D and C++, D and JAVA 
 and so on… To me, that is all you should require if you are an 
 experienced programmer.


 
 Preconceived ideas, tested solutions and methods seem to be what D is 
 sold as. 30 years of experience from all languages brought together in 
 one tight clean package written to be easy to learn and easy to use. Or 
 perhaps I misread Walter's sales pitch.


It took those other languages 30 years to reach where they have the
backing of the best marketing teams and billions of dollars in support
from the largest companies outfitted with paid professionals whose job
it was to develop and improve those languages. I'm sure that D will pale
in comparison to those languages with regard to commercial acceptance
and viability. I simply hope that people would lend a hand at fixing the 
problems they encounter rather than always complaining about them.


 

 Yes, bells and whistles can make easier. But is that truly a 
 showstopper? I don’t think so.


 
 Bells, whistles, the entire percussion section, and a missing lead 
 singer could stop the show, or at least delay it. Perhaps we should let 
 the band in, and let the understudy take the stage.
 

 Regards,
 Andrew


 
 Sincerely,
   Hans W. Uhlig
Feb 10 2008
parent reply "Neil Vice" <sardonicpresence gmail.com> writes:
 It took those other languages 30 years to reach where they have the
 backing of the best marketing teams and billions of dollars in support
 from the largest companies outfitted with paid professionals whose job
 it was to develop and improve those languages. I'm sure that D will pale
 in comparison to those languages with regard to commercial acceptance
 and viability. I simply hope that people would lend a hand at fixing the 
 problems they encounter rather than always complaining about them.


I probably fall in the camp of the complainers. I would love to lend a hand 
at fixing problems if only I had code I could modify, compile and test to 
that end.
Feb 11 2008
parent "Tyro[a.c.edwards]" <no spam.com> writes:
Neil Vice $B$5$s$O=q$-$^$7$?(B:

 It took those other languages 30 years to reach where they have the
 backing of the best marketing teams and billions of dollars in support
 from the largest companies outfitted with paid professionals whose job
 it was to develop and improve those languages. I'm sure that D will pale
 in comparison to those languages with regard to commercial acceptance
 and viability. I simply hope that people would lend a hand at fixing the 
 problems they encounter rather than always complaining about them.


 
 I probably fall in the camp of the complainers. I would love to lend a hand 
 at fixing problems if only I had code I could modify, compile and test to 
 that end. 
 
 


There are a number of projects at dsource.org atrophying from a lack of
attention. I'm sure you can find one there that peaks your curiosity.
More than likely the developer(s) would gladly welcome the help.
Feb 11 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Hans W. Uhlig wrote:

 7) A Good IDE, with debugging, stress testing & Benchmarking - Sounds 
 odd but being able to time a function or stress test something across 
 all possible values from your IDE is a beautiful thing, as is good 
 debugging, syntax coloring and all the other nifty little things that 
 Eclipse and Visual Studio have done right.


Funny you mention that, since I'm sowking on a unittest feature in 
Descent right now that includes the ability to time test runs.
Feb 09 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Robert Fraser wrote:

 Hans W. Uhlig wrote:

 7) A Good IDE, with debugging, stress testing & Benchmarking - Sounds 
 odd but being able to time a function or stress test something across 
 all possible values from your IDE is a beautiful thing, as is good 
 debugging, syntax coloring and all the other nifty little things that 
 Eclipse and Visual Studio have done right.


 
 Funny you mention that, since I'm sowking on a unittest feature in 
 Descent right now that includes the ability to time test runs.


sowking = working. Not a giant talking pig with a crown.
Feb 09 2008
parent reply "Hans W. Uhlig" <huhlig clickconsulting.com> writes:
Robert Fraser wrote:

 Robert Fraser wrote:

 Hans W. Uhlig wrote:

 7) A Good IDE, with debugging, stress testing & Benchmarking - Sounds 
 odd but being able to time a function or stress test something across 
 all possible values from your IDE is a beautiful thing, as is good 
 debugging, syntax coloring and all the other nifty little things that 
 Eclipse and Visual Studio have done right.


 Funny you mention that, since I'm sowking on a unittest feature in 
 Descent right now that includes the ability to time test runs.


 
 sowking = working. Not a giant talking pig with a crown.


I will take a look at that, last time I looked at Descent was a few 
months back.
Feb 09 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Hans W. Uhlig wrote:

 Robert Fraser wrote:

 Robert Fraser wrote:

 Hans W. Uhlig wrote:

 7) A Good IDE, with debugging, stress testing & Benchmarking - 
 Sounds odd but being able to time a function or stress test 
 something across all possible values from your IDE is a beautiful 
 thing, as is good debugging, syntax coloring and all the other nifty 
 little things that Eclipse and Visual Studio have done right.


 Funny you mention that, since I'm sowking on a unittest feature in 
 Descent right now that includes the ability to time test runs.


 sowking = working. Not a giant talking pig with a crown.


 
 I will take a look at that, last time I looked at Descent was a few 
 months back.


It's not in the app just yet; it needs a builder before it's useful.
Feb 09 2008
prev sibling parent reply BCS <ao pathlink.com> writes:
Reply to Robert,


 Hans W. Uhlig wrote:
 

 7) A Good IDE, with debugging, stress testing & Benchmarking - Sounds
 odd but being able to time a function or stress test something across
 all possible values from your IDE is a beautiful thing, as is good
 debugging, syntax coloring and all the other nifty little things that
 Eclipse and Visual Studio have done right.
 


 Funny you mention that, since I'm sowking on a unittest feature in
 Descent right now that includes the ability to time test runs.
 


How about a "color by time in line" feature. the more time spent in that 
line of code the darker it is.
Feb 09 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
BCS wrote:

 Reply to Robert,
 

 Hans W. Uhlig wrote:


 7) A Good IDE, with debugging, stress testing & Benchmarking - Sounds
 odd but being able to time a function or stress test something across
 all possible values from your IDE is a beautiful thing, as is good
 debugging, syntax coloring and all the other nifty little things that
 Eclipse and Visual Studio have done right.


 Funny you mention that, since I'm sowking on a unittest feature in
 Descent right now that includes the ability to time test runs.


 
 How about a "color by time in line" feature. the more time spent in that 
 line of code the darker it is.


Bookmarked for far-far-future reference (as in when the robots take over).
Feb 09 2008
prev sibling next sibling parent reply "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Sat, 09 Feb 2008 23:42:27 +0200, Hans W. Uhlig <huhlig clickconsulting.com>
wrote:

I'll reply to some points that haven't been replied to.


 4) Write once, run everywhere. - This one may make me sound like a loon but
Sun had the right idea. Just not the bast implementation. I will clarify
however I said Write once, not compile once. Most system specific tasks for
application level programming are handled by the standard library. This
includes gui integration, simple and native cross compile tools and integrated
tar/compression support.


About GUI integration - I don't think it should be the burden of the language
to provide that. There are several binding libraries for cross-platform GUI
libraries which work pretty well (an example: http://wxd.sourceforge.net/ )


 5) A library packager - The scripting languages got it right with cpan, simple
quick, easy, no complex installation instructions, just cpan install x. Being
able to do this and keep your libraries up-to-date quickly and easily is a
godsend to most programmers. DSource is nice, but it lacks a lot in usability,
and being able to figure out core from cruft.


We have this with Gregor's excellent DSSS ( D Shared Source System,
http://dsource.org/projects/dsss/ ).

-- 
Best regards,
 Vladimir                          mailto:thecybershadow gmail.com
Feb 09 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Vladimir Panteleev:

 About GUI integration - I don't think it should be the burden of the language
to provide that. There are several binding libraries for cross-platform GUI
libraries which work pretty well (an example: http://wxd.sourceforge.net/ )


A built-in standard GUI toolkit has some advantages, it's a standard, so it
hopefully gets developed to a refined state instead of having 5-10 half-baked
GUI toolkits that are of little use, like the current situation. And if you
don't like the standard one, you are free still to develop/install a different
one.

Regarding WxD, I suggest their developers to take a good look at the now dead
"Wax", it shows a way to write a better wrapper for Wx (it's not meant to
replace the normal Wx API, but to offer an alternative, a simper one):
http://zephyrfalcon.org/labs/wax.html

Wax was developed for Python, that has named arguments too, so that Python code
may look like:

tb = TextBox(parent, size=(400, 200), multiline=1, readonly=0, wrap=1,
justify='left')

Named arguments are quite useful for such GUI-style code, but not available in
D yet (they are in the D Wish List), so some alternative solution has to be
found:

auto tb = TextBox(parent).size(400,
200).multiline(1).readonly(0).wrap(1).justify("left");

Or:

auto tb = TextBox(parent, ["nx":400, "ny":200, "multiline":1, "readonly":0,
"wrap":1, "justify": LEFT]);

auto tb = TextBox(parent).opts(["nx":400, "ny":200, "multiline":1,
"readonly":0, "wrap":1, "justify": LEFT]);

Bye,
bearophile
Feb 10 2008
parent reply "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Sun, 10 Feb 2008 14:47:00 +0200, bearophile <bearophileHUGS lycos.com=

 wrote:



 Wax was developed for Python, that has named arguments too, so that Py=


thon code may look like:

 =



 tb =3D TextBox(parent, size=3D(400, 200), multiline=3D1, readonly=3D0,=


 wrap=3D1, justify=3D'left')

D isn't too far off with "with" statements. Example DFL code:
with(tb =3D new TextBox) { bounds =3D Rect(100, 100, 200, 200); multilin=
e =3D true; readOnly =3D false; wordWrap =3D true; parent =3D this; }

And with the new full closures, you can implement event handlers inline,=
 too.

-- =

Best regards,
 Vladimir                          mailto:thecybershadow gmail.com
Feb 10 2008
next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Vladimir Panteleev <thecybershadow gmail.com> wrote:


 On Sun, 10 Feb 2008 14:47:00 +0200, bearophile  =



 <bearophileHUGS lycos.com> wrote:


 Wax was developed for Python, that has named arguments too, so that  =





 Python code may look like:

 tb =3D TextBox(parent, size=3D(400, 200), multiline=3D1, readonly=3D0=




, wrap=3D1,  =


 justify=3D'left')


 D isn't too far off with "with" statements. Example DFL code:
 with(tb =3D new TextBox) { bounds =3D Rect(100, 100, 200, 200); multil=


ine =3D  =


 true; readOnly =3D false; wordWrap =3D true; parent =3D this; }


Now if only you could declare a new variable within a with statement. It=
's  =

not strictly necessary, but I find

	with (auto tb =3D new TextBox()) { ... }

to be more aesthetically pleasing than

	auto tb =3D new TextBox();
	with (tb) { ... }

of course, given that with introduces a separate scope, tb might go out =
of  =

scope the moment the with statement exits. This might be open to  =

interpretation though, seeing as tb is declared outside the curly braces=
.


 And with the new full closures, you can implement event handlers inlin=


e,  =


 too.
Feb 10 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Vladimir Panteleev Wrote:

 D isn't too far off with "with" statements. Example DFL code:
 with(tb = new TextBox) { bounds = Rect(100, 100, 200, 200); multiline = true;
readOnly = false; wordWrap = true; parent = this; }


This is shorter and I think it looks better, with less syntax:
auto tb = TextBox(space1).size(400,
200).multiline(1).readonly(0).wrap(1).justify("left");

In D you may want to use camelCase to move your fingers a bit more:
auto tb = TextBox(space1).size(400,
200).multiLine(1).readOnly(0).wrap(1).justify("left");



 And with the new full closures, you can implement event handlers inline, too.


I don't use D 2.x, but I presume a good Wax-like wrapper can be written for D
too :-)

Bye,
bearophile
Feb 10 2008
prev sibling next sibling parent reply Clay Smith <clayasaurus gmail.com> writes:
Hans W. Uhlig wrote:

 Good morning everyone,
     I am new to the D forums but I have been following D's progress for 
 a good while.


Hello.



 1) Lots of example code & documentation - This one may sound silly, but 
 if you want to do nearly anything in Java as a programmer, you can enter 
 in Google "Java <thing I want to do>" and find something from sun on the 
 topic. This makes it simple for new users.


I do not think D lacks examples or documentation. When I was a newer 
user, http://www.digitalmars.com/d/1.0/lex.html and 
http://www.dsource.org/projects/tutorials/wiki got me by pretty well. If 
the documentation is good enough for newbie hobby programmers, I think 
professionals should be able to understand it.


 
 2) A single standard library for most tasks - The whole Phobos here and 
 Tango there and DWT someplace else makes picking up a language 
 difficult. Not only that but as a Java Instructor I can simply point to 
 the Sun java & javax library sets available and say here is something 
 that can do that. In Suns case it may not do it well but its there.


I sort of agree, but...

1) While Tango / Phobos situation is not up to par, ... the situation 
would be a whole lot worse if Tango didn't exist. Tango is pretty great, 
and I think just by its existence it will help get phobos up to speed, 
as well as provide a good alternative lib that decent programmers can 
have a sense of ownership with.

2) It probably is not smart to have a big GUI in a standard library, 
because if the GUI is buggy and incomplete, people will think the same 
of the whole standard lib. Plus, someone may write a better GUI and then 
the standard lib won't be able to use it.



 
 3) Good automatic documentation library for EVERYTHING - Being able to 
 search and find all the information on a Java library in the same format 
 and the same style no matter what library I look at makes using the 
 language easier and usually faster for development.


We have that http://www.digitalmars.com/d/2.0/ddoc.html


 
 3) Good, native parallelism - With dual core, quad core, or in IBM's 
 Cell  processor Obscene core processors, none of the current C Syntax 
 family is parallelism handled natively and "well".


I'm pretty sure the D community is very aware of this.


 
 4) Write once, run everywhere. - This one may make me sound like a loon 
 but Sun had the right idea. Just not the bast implementation. I will 
 clarify however I said Write once, not compile once. Most system 
 specific tasks for application level programming are handled by the 
 standard library. This includes gui integration, simple and native cross 
 compile tools and integrated tar/compression support.


Both phobos and Tango are cross platform...


 
 5) A library packager - The scripting languages got it right with cpan, 
 simple quick, easy, no complex installation instructions, just cpan 
 install x. Being able to do this and keep your libraries up-to-date 
 quickly and easily is a godsend to most programmers. DSource is nice, 
 but it lacks a lot in usability, and being able to figure out core from 
 cruft.


I think DSSS http://www.dsource.org/dsss has the potential to become 
this, although lack of a 'dsss update' feature prevents it. DSSS is a 
great way to fetch libraries however.


 
 6) Well supported exterainious libs - In java if you need an xml library 
 there are 30, in perl if you need a mysql link, there is one that is 
 regularly updates. This one takes people using the language and doing 
 such things but its important none the less. There is no reason to 
 reinvent the wheel 10 times when someone has done it for you. (I am well 
 aware that many programmers will reinvent the wheel 'right' again anyway)


I'm not sure what you mean by well supported, but D does have plenty of 
libraries that do a pretty good job of gettings things done 
http://www.dsource.org/projects


 
 7) A Good IDE, with debugging, stress testing & Benchmarking - Sounds 
 odd but being able to time a function or stress test something across 
 all possible values from your IDE is a beautiful thing, as is good 
 debugging, syntax coloring and all the other nifty little things that 
 Eclipse and Visual Studio have done right.
 
 And my final bullet for this memo which is far longer then I thought it 
 would be


I don't know anything about this really, but D did recently get a d.ide 
newsgroup, so its on the radar it looks like.


 
 8) Unified Thought in Paradime - Right now I see in the community a 
 divergence in idea between C style functions, C++ style classes and a 
 cleaner java style classes. (My preference is C functions and java 
 classes but thats just me) Choose your options and unify that in the 
 library. Do what perl did in premise and have oo or function style(yes I 
 am aware this is older libs like CGI but I dont care for the argument). 
 Integrate Both paradimes into the core logic of your libraries or focus 
 on one. But don't develop libraries that compete.


I don't think library competition is necessarily a bad thing. It adds 
some sport into the process and if a library has to compete, it will 
become stronger.

As with unified style,... I think 
http://www.digitalmars.com/d/2.0/dstyle.html tries to be it, but 
honestly, you can't control someone to do exactly how you want. People 
will just use the style they feel confortable with and its nice to know 
that D attracts C, C++, and Java programmers.
Feb 10 2008
parent "Hans W. Uhlig" <huhlig clickconsulting.com> writes:
Clay Smith wrote:

 Hans W. Uhlig wrote:

 Good morning everyone,
     I am new to the D forums but I have been following D's progress 
 for a good while.


 
 Hello.
 
 

 1) Lots of example code & documentation - This one may sound silly, 
 but if you want to do nearly anything in Java as a programmer, you can 
 enter in Google "Java <thing I want to do>" and find something from 
 sun on the topic. This makes it simple for new users.


 
 I do not think D lacks examples or documentation. When I was a newer 
 user, http://www.digitalmars.com/d/1.0/lex.html and 
 http://www.dsource.org/projects/tutorials/wiki got me by pretty well. If 
 the documentation is good enough for newbie hobby programmers, I think 
 professionals should be able to understand it.
 

 2) A single standard library for most tasks - The whole Phobos here 
 and Tango there and DWT someplace else makes picking up a language 
 difficult. Not only that but as a Java Instructor I can simply point 
 to the Sun java & javax library sets available and say here is 
 something that can do that. In Suns case it may not do it well but its 
 there.


 
 I sort of agree, but...
 
 1) While Tango / Phobos situation is not up to par, ... the situation 
 would be a whole lot worse if Tango didn't exist. Tango is pretty great, 
 and I think just by its existence it will help get phobos up to speed, 
 as well as provide a good alternative lib that decent programmers can 
 have a sense of ownership with.
 
 2) It probably is not smart to have a big GUI in a standard library, 
 because if the GUI is buggy and incomplete, people will think the same 
 of the whole standard lib. Plus, someone may write a better GUI and then 
 the standard lib won't be able to use it.
 


You would be surprised what a crappy GUI in a standard library can do, I 
reference AWT & Swing as an example. It did miles to help Java.


 3) Good automatic documentation library for EVERYTHING - Being able to 
 search and find all the information on a Java library in the same 
 format and the same style no matter what library I look at makes using 
 the language easier and usually faster for development.


 
 We have that http://www.digitalmars.com/d/2.0/ddoc.html
 

 3) Good, native parallelism - With dual core, quad core, or in IBM's 
 Cell  processor Obscene core processors, none of the current C Syntax 
 family is parallelism handled natively and "well".


 
 I'm pretty sure the D community is very aware of this.
 

 4) Write once, run everywhere. - This one may make me sound like a 
 loon but Sun had the right idea. Just not the bast implementation. I 
 will clarify however I said Write once, not compile once. Most system 
 specific tasks for application level programming are handled by the 
 standard library. This includes gui integration, simple and native 
 cross compile tools and integrated tar/compression support.


 
 Both phobos and Tango are cross platform...
 

 5) A library packager - The scripting languages got it right with 
 cpan, simple quick, easy, no complex installation instructions, just 
 cpan install x. Being able to do this and keep your libraries 
 up-to-date quickly and easily is a godsend to most programmers. 
 DSource is nice, but it lacks a lot in usability, and being able to 
 figure out core from cruft.


 
 I think DSSS http://www.dsource.org/dsss has the potential to become 
 this, although lack of a 'dsss update' feature prevents it. DSSS is a 
 great way to fetch libraries however.
 


I will look into DSSS but it sounds like something that should come with 
the base package including your standard lib, and toolchain.


 6) Well supported exterainious libs - In java if you need an xml 
 library there are 30, in perl if you need a mysql link, there is one 
 that is regularly updates. This one takes people using the language 
 and doing such things but its important none the less. There is no 
 reason to reinvent the wheel 10 times when someone has done it for 
 you. (I am well aware that many programmers will reinvent the wheel 
 'right' again anyway)


 
 I'm not sure what you mean by well supported, but D does have plenty of 
 libraries that do a pretty good job of gettings things done 
 http://www.dsource.org/projects
 

 7) A Good IDE, with debugging, stress testing & Benchmarking - Sounds 
 odd but being able to time a function or stress test something across 
 all possible values from your IDE is a beautiful thing, as is good 
 debugging, syntax coloring and all the other nifty little things that 
 Eclipse and Visual Studio have done right.

 And my final bullet for this memo which is far longer then I thought 
 it would be


 
 I don't know anything about this really, but D did recently get a d.ide 
 newsgroup, so its on the radar it looks like.
 

 8) Unified Thought in Paradime - Right now I see in the community a 
 divergence in idea between C style functions, C++ style classes and a 
 cleaner java style classes. (My preference is C functions and java 
 classes but thats just me) Choose your options and unify that in the 
 library. Do what perl did in premise and have oo or function style(yes 
 I am aware this is older libs like CGI but I dont care for the 
 argument). Integrate Both paradimes into the core logic of your 
 libraries or focus on one. But don't develop libraries that compete.


 
 I don't think library competition is necessarily a bad thing. It adds 
 some sport into the process and if a library has to compete, it will 
 become stronger.
 
 As with unified style,... I think 
 http://www.digitalmars.com/d/2.0/dstyle.html tries to be it, but 
 honestly, you can't control someone to do exactly how you want. People 
 will just use the style they feel confortable with and its nice to know 
 that D attracts C, C++, and Java programmers.
 


Its not that all peoples code should be but the language should follow 
the same paradime for the "accepted" and "core" code and libraries.
Feb 10 2008
prev sibling parent reply Burton Radons <burton-radons shaw.ca> writes:
Hans W. Uhlig Wrote:


 3) Good, native parallelism - With dual core, quad core, or in IBM's 
 Cell  processor Obscene core processors, none of the current C Syntax 
 family is parallelism handled natively and "well".


Do you mean in the library or in the language? I don't think D can be a
magically-parallelising language; it's not constructed for it, and while it's a
cool trick in those languages which do it I'd be worried about it not
parallelising important code because of some functional test incorrectly
failing and making it run sequentially. But it could handle something like
OpenMP more elegantly, where you tell the compiler what can be parallelised, a
la:

	// The compiler can and probably should split this into pieces.
	parallel foreach (i, foo)
	
	// The compiler can also do these two tasks at the same time.
	parallel
	{
		// Pause any other worker threads so that only this thread can work during
this statement.
		synchronized
		{
		}

		// But this only causes us to pause this thread if another thread is using
the object.
		synchronized (object)
		{
		}
	}
	
	parallel bar ();

	// But everything's gotta be done before calling this!
	baz ();

That would be a quick addition to the compiler that could be expanded over time
(both in how well the compiler handles the instruction and semantics) rather
than taking a month just to get it to a semi-working state, it's something that
would retain its usefulness even if the compiler starts to learn how to
automatically parallelise code, and it's simple (probably too simple, I haven't
explored OpenMP much) while still making a material contribution to the
language.

I'm working on this issue in a library, but there's a limit to how elegant I
can make it. Also I have no freaking idea what I'm doing. It hasn't stopped me
before, but it does slow me down.


 6) Well supported exterainious libs - In java if you need an xml library 
 there are 30, in perl if you need a mysql link, there is one that is 
 regularly updates. This one takes people using the language and doing 
 such things but its important none the less. There is no reason to 
 reinvent the wheel 10 times when someone has done it for you. (I am well 
 aware that many programmers will reinvent the wheel 'right' again anyway)


I half agree and half disagree. I can see how this allows outsiders to get a
simple, cohesive view of a language. On the other hand, there are often
manifest problems or deficiencies in a library, and variations on a theme allow
us to explore different ways to address the issue and find the best way to
implement it. This is particularly important with D, which has certain features
which no other language has and needs implementing in new ways. It's not
pointless reinvention.
Feb 10 2008
next sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Sun, 10 Feb 2008 22:59:49 -0500, Burton Radons wrote:


 Hans W. Uhlig Wrote:
 

 3) Good, native parallelism - With dual core, quad core, or in IBM's
 Cell  processor Obscene core processors, none of the current C Syntax
 family is parallelism handled natively and "well".


 
 Do you mean in the library or in the language? I don't think D can be a
 magically-parallelising language; it's not constructed for it, and while
 it's a cool trick in those languages which do it I'd be worried about it
 not parallelising important code because of some functional test
 incorrectly failing and making it run sequentially.


Well that's what D2 is getting ready for, magically-paralleling programs. 
It already supports threading which is explicit. Granted its not the 
simplest to use, but I think paralleling will be evolving soon for D. 
(And by soon I mean later)
Feb 10 2008
parent reply Burton Radons <burton-radons shaw.ca> writes:
Jesse Phillips Wrote:


 On Sun, 10 Feb 2008 22:59:49 -0500, Burton Radons wrote:
 

 Hans W. Uhlig Wrote:
 

 3) Good, native parallelism - With dual core, quad core, or in IBM's
 Cell  processor Obscene core processors, none of the current C Syntax
 family is parallelism handled natively and "well".


 
 Do you mean in the library or in the language? I don't think D can be a
 magically-parallelising language; it's not constructed for it, and while
 it's a cool trick in those languages which do it I'd be worried about it
 not parallelising important code because of some functional test
 incorrectly failing and making it run sequentially.


 
 Well that's what D2 is getting ready for, magically-paralleling programs. 
 It already supports threading which is explicit. Granted its not the 
 simplest to use, but I think paralleling will be evolving soon for D. 
 (And by soon I mean later)


Reference? I don't use 2.0. Anyway what I said holds IMO - when you want code
to be executed in parallel, it's not something that should be left to an
overly-cautious safety check. For instance, it'd be extremely hard to prove
that asm blocks containing SIMD code can be safely parallelised since they may
or may not be utilising their own output as input. Yet that's precisely the
situation in which parallelisation needs to be done most aggressively. You can
also make better decisions about when an array is going to get long enough to
merit splitting, while the compiler can only do this after instrumenting. And
when I'm optimising code, the last thing I want is for seemingly harmless
changes to suddenly cause jumps of 30% in execution speed, which is what could
happen with automatic parallelisation.
Feb 10 2008
parent Jesse Phillips <jessekphillips gmail.com> writes:
On Mon, 11 Feb 2008 02:07:29 -0500, Burton Radons wrote:


 Jesse Phillips Wrote:
 

 On Sun, 10 Feb 2008 22:59:49 -0500, Burton Radons wrote:
 

 Hans W. Uhlig Wrote:
 

 3) Good, native parallelism - With dual core, quad core, or in IBM's
 Cell  processor Obscene core processors, none of the current C
 Syntax family is parallelism handled natively and "well".


 
 Do you mean in the library or in the language? I don't think D can be
 a magically-parallelising language; it's not constructed for it, and
 while it's a cool trick in those languages which do it I'd be worried
 about it not parallelising important code because of some functional
 test incorrectly failing and making it run sequentially.


 
 Well that's what D2 is getting ready for, magically-paralleling
 programs. It already supports threading which is explicit. Granted its
 not the simplest to use, but I think paralleling will be evolving soon
 for D. (And by soon I mean later)


 
 Reference? I don't use 2.0. Anyway what I said holds IMO - when you want
 code to be executed in parallel, it's not something that should be left
 to an overly-cautious safety check. For instance, it'd be extremely hard
 to prove that asm blocks containing SIMD code can be safely parallelised
 since they may or may not be utilising their own output as input. Yet
 that's precisely the situation in which parallelisation needs to be done
 most aggressively. You can also make better decisions about when an
 array is going to get long enough to merit splitting, while the compiler
 can only do this after instrumenting. And when I'm optimising code, the
 last thing I want is for seemingly harmless changes to suddenly cause
 jumps of 30% in execution speed, which is what could happen with
 automatic parallelisation.


I don't recall the news posts that discussed such possibilities, but it 
relates to the fact that D is heading towards adding more functional 
style programming. This is where const and invariant are playing a big 
roll. I don't know if Walter has come out and said it will allow for 
automatic paralleling, but any move toward function coding lends to such 
possibilities.
Feb 11 2008
prev sibling parent "Hans W. Uhlig" <huhlig clickconsulting.com> writes:
Burton Radons wrote:

 Hans W. Uhlig Wrote:
 

 3) Good, native parallelism - With dual core, quad core, or in
 IBM's Cell  processor Obscene core processors, none of the current
 C Syntax family is parallelism handled natively and "well".


 
 Do you mean in the library or in the language? I don't think D can be
 a magically-parallelising language; it's not constructed for it, and
 while it's a cool trick in those languages which do it I'd be worried
 about it not parallelising important code because of some functional
 test incorrectly failing and making it run sequentially. But it could
 handle something like OpenMP more elegantly, where you tell the
 compiler what can be parallelised, a la:
 
 // The compiler can and probably should split this into pieces. 
 parallel foreach (i, foo)  // The compiler can also do these two
 tasks at the same time. parallel { // Pause any other worker threads
 so that only this thread can work during this statement. synchronized
  { }
 
 // But this only causes us to pause this thread if another thread is
 using the object. synchronized (object) { } }  parallel bar ();
 
 // But everything's gotta be done before calling this! baz ();
 
 That would be a quick addition to the compiler that could be expanded
 over time (both in how well the compiler handles the instruction and
 semantics) rather than taking a month just to get it to a
 semi-working state, it's something that would retain its usefulness
 even if the compiler starts to learn how to automatically parallelise
 code, and it's simple (probably too simple, I haven't explored OpenMP
 much) while still making a material contribution to the language.
 
 I'm working on this issue in a library, but there's a limit to how
 elegant I can make it. Also I have no freaking idea what I'm doing.
 It hasn't stopped me before, but it does slow me down.
 


Yes, With both where computers are going and where they already are, 
native parallelism is one of the prime areas where a language will have 
to shine.


 6) Well supported exterainious libs - In java if you need an xml
 library there are 30, in perl if you need a mysql link, there is
 one that is regularly updates. This one takes people using the
 language and doing such things but its important none the less.
 There is no reason to reinvent the wheel 10 times when someone has
 done it for you. (I am well aware that many programmers will
 reinvent the wheel 'right' again anyway)


 
 I half agree and half disagree. I can see how this allows outsiders
 to get a simple, cohesive view of a language. On the other hand,
 there are often manifest problems or deficiencies in a library, and
 variations on a theme allow us to explore different ways to address
 the issue and find the best way to implement it. This is particularly
 important with D, which has certain features which no other language
 has and needs implementing in new ways. It's not pointless
 reinvention.


very true but when you move from hobbier to production you need a single 
accepted standard you can show a Pointy haired project manager and say 
we are using X from Y. we can rely on them supporting it for x years. 
Personal Development vs Corporate development have very different 
standards.
Feb 11 2008