Jan-Eric Duden wrote:

> Who wants to ship the whole JRE to their customers?
> That only works well in controlled environments.

Actually, I only ship the .jar file these days.
Most people know where to get the Java runtime,
if they all haven't got it installed already ?

And those .jar's are actually really small:
>  12K    hello_c
> Hello, World!
>         0.04 real         0.00 user         0.01 sys
> 
> 368K    hello_cpp
> Hello, World!
>         0.06 real         0.00 user         0.03 sys
> 
> 104K    hello_d
> Hello, World!
>         0.05 real         0.00 user         0.01 sys
> 
> 4.0K    hello.jar
> Hello, World!
>         0.67 real         0.31 user         0.16 sys

Especially with the built-in compression.
The JVM startup is not that fun, though.
(as can be seen from the runtimes above)

> That's why I like D.

Me too. :-)

We've started a page to help going from Java to D:
http://www.prowiki.org/wiki4d/wiki.cgi?JavaToD
If you can help with filling it out, it'd be great.

There's also the "Molt" project on Dsource:
http://www.dsource.org/projects/molt/
(although I can't get the XSLT working here)

--anders

Regan Heath wrote:
> On Fri, 04 Mar 2005 09:45:59 +0100, Jan-Eric Duden <jeduden@whisset.com>  wrote:
> 
>>>> But if you want to abstact from the encoding you need a class,
>>>> or there is another D feature, that helps with that? :>
>>>
>>>   Why do you want to abstract the encoding? Can you give me an example  where  it's useful?
>>>  Regan
>>
>> For example:
>> You have a library A that works utf8 characters and
>> you have a library B that works utf16 characters.
>>
>> And you are writing a program using A and B,
>> then you need to write either a wrapper around A or B or you need to  make conversion calls in every call of functions that belong to these  libraries.
> 
> 
> Correct. But, all you'd be achieving is shorter code which hides the fact  that it's converting strings all the time.
> 
> Ideally we should only convert on input and output.
> Ideally we use the most efficient format (depends on our task) internally.
> 
> Of course things seldom happen that way and I guess if efficiency isn't  that important then a string class might be nice, but it's not essential.
> 
> Question, I believe opCast can only be overloaded for one type, so, how  you return char[], wchar[] and dchar[] without using method calls?
> 
>> Furthermore a string class can help implementing the concept "copy only  if changes are made".
> 
> 
> "Copy On Write"
> 
>> This is pretty important since D doesn't support the keyword const.
> 
> 
> I think the need for const is obviated somewhat by in, out and inout.
> It would be obviated further if constness was enforced when 'in' was used.
> eg.
> 
> If you see: void foo(inout char[] a), you know foo will/might modify 'a'
> If you see: void foo(char[] a), you know foo won't modify 'a' (not  actually true*)
> 
> *foo can modify the data but not the reference, eg.
> 
> void foo(char[] a) {
>   a[0] = '1';
> }
> 
> will modify the first char of a.
And that what you don't want.
If you pass a string you don't want anyone to change the contents of the string.

> 
> I think the constness of 'in' idea is very important, it gives us some  assurances and allows us to implement "Copy On Write" more confidently.
> 
>> Otherwise every single class that wants to store a string needs to copy  the string!
> 
> 
> Correction, every single class that wants "to modify" a string *it has  stored* needs to copy the string. In other words "Copy On Write".
> 
> Regan

But this is cannot be enforced by the char array.

Roberto Mariottini wrote:
> In article <d06p3m$2c55$1@digitaldaemon.com>, Stewart Gordon says...
<snip>
>> How did Java "do web pages" before it had a "standard GUI"?
> 
> I was somewhat unclear, I mean that since it had a standard library and a standard GUI from the beginning, after having been used to do web pages (and showed to be useful) it has been used to do serious development.

Do you mean it enabled it to be taken up by purists who like to use only the 'standard' aspects of a language, and not depend on any third-party or proprietary libraries?

There are other contributing factors, such as its being designed to write cross-platform apps (hence the importance of standard GUI features) and its being a relatively powerful and robust OO language.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

On Fri, 04 Mar 2005 11:44:36 +0100, Jan-Eric Duden <jeduden@whisset.com> wrote:
> Regan Heath wrote:
>> On Fri, 04 Mar 2005 09:45:59 +0100, Jan-Eric Duden <jeduden@whisset.com>  wrote:
>>
>>>>> But if you want to abstact from the encoding you need a class,
>>>>> or there is another D feature, that helps with that? :>
>>>>
>>>>   Why do you want to abstract the encoding? Can you give me an example  where  it's useful?
>>>>  Regan
>>>
>>> For example:
>>> You have a library A that works utf8 characters and
>>> you have a library B that works utf16 characters.
>>>
>>> And you are writing a program using A and B,
>>> then you need to write either a wrapper around A or B or you need to  make conversion calls in every call of functions that belong to these  libraries.
>>
>>
>> Correct. But, all you'd be achieving is shorter code which hides the fact  that it's converting strings all the time.
>>
>> Ideally we should only convert on input and output.
>> Ideally we use the most efficient format (depends on our task) internally.
>>
>> Of course things seldom happen that way and I guess if efficiency isn't  that important then a string class might be nice, but it's not essential.
>>
>> Question, I believe opCast can only be overloaded for one type, so, how  you return char[], wchar[] and dchar[] without using method calls?
>>
>>> Furthermore a string class can help implementing the concept "copy only  if changes are made".
>>
>>
>> "Copy On Write"
>>
>>> This is pretty important since D doesn't support the keyword const.
>>
>>
>> I think the need for const is obviated somewhat by in, out and inout.
>> It would be obviated further if constness was enforced when 'in' was used.
>> eg.
>>
>> If you see: void foo(inout char[] a), you know foo will/might modify 'a'
>> If you see: void foo(char[] a), you know foo won't modify 'a' (not  actually true*)
>>
>> *foo can modify the data but not the reference, eg.
>>
>> void foo(char[] a) {
>>   a[0] = '1';
>> }
>>
>> will modify the first char of a.
> And that what you don't want.

Not in this case.

> If you pass a string you don't want anyone to change the contents of the string.

Unless that's the point of the function.

>> I think the constness of 'in' idea is very important, it gives us some  assurances and allows us to implement "Copy On Write" more confidently.
>>
>>> Otherwise every single class that wants to store a string needs to copy  the string!
>>
>>
>> Correction, every single class that wants "to modify" a string *it has  stored* needs to copy the string. In other words "Copy On Write".
>>
>> Regan
>
> But this is cannot be enforced by the char array.

True, but it's not intended to.

Regan

Jan-Eric Duden wrote:

>> "Copy On Write"
>> void foo(char[] a) {
>>   a[0] = '1';
>> }
>>
>> will modify the first char of a.
> 
> And that what you don't want.
> If you pass a string you don't want anyone to change the contents of the string.

Strings in D are protected from overwriting by the Honor System™...
If you touch someone elses strings, you get to stand in the corner. :-)

Or in case of string literals, you just might trigger a segfault.
(depending on whether or not string literals are stored read-only)


Enforcing Copy-on-Write, is a D issue that is remaining to be solved.
(it needs to be able to separate between read-only and read-write ?)

Hopefully it can be done without a 'String' class (like in Java), and
without the 'const' type modifier (like in C/C++). Or done at all...


Meanwhile, we all need to be nice little children and CoW as told ?
(note that being an equally bad boy in C is only a cast away, too)

Maybe Walter has an ace up the sleeve? (I'm thinking "in" vs. "out" ?)
Solving this one, and the "out variadic" problem, would be very nice!

--anders

Anders F Björklund wrote:
> Jan-Eric Duden wrote:
> 

> Actually, I only ship the .jar file these days.
> Most people know where to get the Java runtime,
> if they all haven't got it installed already ?

That wholly depends on your user base. The reason I am so hung up on D right now is precisely because of the difficulties of distributing Java games to the general public online. PuppyGames (http://www.puppygames.com/) is a pioneer in this area, and has seen dismal failures when distributing both via WebStart and without on Windows and Linux (the Mac market has proven to be the perfect environment for Java applications - Java support is integrated with the OS these days). I can point you to a thread where other independent game developers, people you who are quite tech-savy (but otherwise non-Java users), had quite some difficulty testing PuppyGames' most recent release - until they opted to ship the game with a stripped down VM (which violates the Sun license agreement big time) in order to avoid shipping the whole JRE. Now it works right out of the box.

In this respect, D is as close to a Holy Grail as you can get. It's the perfect answer for any Java developer who has faced support issues related to JRE penetration in the Windows world (which Sun has been overly optimistic about, apparently). That's why I think Phobos is so important to bring these people in - without a solid library akin to the one they have become accustomed to, many will be reluctant to make the switch in spite of the easier distribution.

In article <d04ccv$2nh7$1@digitaldaemon.com>, Jason Mills says...
>
>I have been reading this newsgroup for several years. Although I post rarely I do read it every day. Early on I was so enthusiastic about D I could barely contain myself. I could not wait to use D at work, replacing C++ and Java. I'm still patiently waiting for that day. With

Don't have time to read every reply so for. But many of us can't use beta products at work for real projects.  D needs to get to 1.0 sooner then later.

Believe it or not, it would also be helpful if Walter sells a $25-50 CD version (to cover production costs) so the suits think they have actually bought something.  They allow us to get our updates via the net.

I agree with Stewart about the library stuff, phobos is good enough for version 1.0.

In article <d04p7a$550$1@digitaldaemon.com>, Walter says...
>
>
>"Jason Mills" <jmills@cs.mun.ca> wrote in message news:d04ccv$2nh7$1@digitaldaemon.com...
>> I have been reading this newsgroup for several years. Although I post rarely I do read it every day. Early on I was so enthusiastic about D I could barely contain myself. I could not wait to use D at work, replacing C++ and Java. I'm still patiently waiting for that day. With C++/CLI soon a reality, improvements to C++ coming, together with existing versions of C# and Java, all with huge libraries ready to use out of the box, will D every be able to compete?
>
>I've found myself wondering over the last few months what "1.0" actually is. Since D will undergo continuous improvement regardless, why don't we just drive a stake in the ground and call what we have "1.0"?

absolutely,  make sure there no major bugs then ship it. By the way I guess I am really referring to DMD 1.0.  D Language standard itself could use the year or something else to stamp it.  Hopefully the "D Language standard" won't change every 3 months.

>** Euphoria-to-D translator
>---------------------------
>I love using the Euphoria language for applications that don't need blistering speed (its an interpreted language). It is sort of like a dynamically typed D. But there are two aspects that irk me though.
>  (a) Sometimes a bit of speed is required, but not As Fast As Possible
>type speed. So translating Euphoria to D then compiling the D code should help speed up things.
>  (b) It is not open source, and the "Walter"-type that controls its
>evolution is really slow to add anything useful, and resists 'modernization'. Euphoria was designed in 1993 and is still only at v2.4.
>
>So this is my first step in creating an open source version of a language translator. This will be a springboard for creating an alternative interpreter. Currently, I'm implementing the built-in data types (all four of them) supported by Euphoria - integer, atom, sequence and object. This is progressing well and I'm about 50% done with that phase.
>

please post link to this language.

Anders F Björklund wrote:
> Jan-Eric Duden wrote:
> 
>>> "Copy On Write"
>>> void foo(char[] a) {
>>>   a[0] = '1';
>>> }
>>>
>>> will modify the first char of a.
>>
>>
>> And that what you don't want.
>> If you pass a string you don't want anyone to change the contents of the string.
> 
> 
> Strings in D are protected from overwriting by the Honor System™...
> If you touch someone elses strings, you get to stand in the corner. :-)
> 
> Or in case of string literals, you just might trigger a segfault.
> (depending on whether or not string literals are stored read-only)

How can a D coder know if it is safe to store just the reference or if
he needs to make a copy.
Right now, to be on the safe side - he actually needs to make a copy.
Otherwise, somewhere in her system or in external libraries the string might get changed without her knowledge.

D has everything it needs to make strings fast and safe-
 why does Walter not want a standardized string interface?

Is it that difficult to understand that either const or a string class is needed to support secure programming?