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.

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

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.

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.

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

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

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 = TextBox(parent, size=(400, 200), multiline=1, readonly=0, wrap=1, justify='left')

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; }

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

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com

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.

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.

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.