On Thu, 3 Mar 2005 16:04:23 +1100, Derek Parnell wrote:

> On Wed, 2 Mar 2005 20:49:38 -0800, Andrew Fedoniouk wrote:
> 
>>>
>>> will change enough to cause any D source today to undergo major rewrites? I can answer the latter concern - it isn't going to happen.
>>>
>> 
>> Walter, for the Mars sake and other mebers of Panteon, could you shed a light on future of "external-methods"?
>> 
>> I mean this was supported last time I checked it
>> char[][] split(char[] s, char c) { ... }
>> char[] s = "a b c";
>> char[][] sv = s.split(' ');
>> 
>> May I rely on this trick?
> 
> I sure hope so 'cos I've spent the last couple of weeks writing a whole heap of code that depends on this behaviour.

In fact, I'd like this syntax extended for non-array built-in types too.

bool Foo(real A, char[] B) { . . . }
real x;

if ( x.Foo("abc") ) { . . .};

It would make life *so* much easier rather than special coding for structs, some more for classes, and some more for built-in types.

I mean, these are decisions that the compiler can make with making me work so hard :D

-- 
Derek
Melbourne, Australia
3/03/2005 4:11:36 PM

In article <d05uu7$1gfs$1@digitaldaemon.com>, John Reimer says...
>
>This post shows a lot of good sense!  Very well put, Glen.  I beleive Walter does need to be much more receptive to outside opinion.
>
>My only hesitation would be using slashdot as a resource.... ugh...

>That site is the last place I'd search for a sane evaluation of a language (Although, it is useful for getting general publicity).  I believe language reviewers have to be much more carefully chosen, or there will be chaos.  But such critical evaluation is necessary.
>
>-JJR

Yeah, the first example that popped into my mind wasn't necessarily the best.... ;-) I would hope to have a wide range of experiences represented, though, because a popular language would eventually be USED in far more ways than initially imagined.





>
>Glen Perkins wrote:
>> In article <d04p7a$550$1@digitaldaemon.com>, Walter says...
>> 
>> 
>>>I've found myself wondering over the last few months what "1.0" actually is.
>> 
>> 
>> Having formally participated in the design of Java and Flash ActionScript, I can say that the biggest non-commercial part of the definition of "what 1.0 actually is" was cutting off your ability to ever change your mind about some things. Freezing your mistakes. After 1.0, you are still able to add things, but you can't really remove anything, and the things you add have to be squeezed into the spaces not already occupied by something you can't remove. Having to squeeze new, better ideas into cracks between old, worse ideas makes a language into, well, C++ or Perl 5.
>> 
>> 
>>>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"?
>> 
>> 
>> Yes, many things will still be changeable, but many will not. The "stake in the ground" is a stake thru the heart of anybody who still fervently hopes to pursuade you to change certain things before it's too late. Even though it is true that D will undergo continuous improvement, you will never again be completely free to "do things right" after 1.0 ships.
>> 
>> I don't think it's possible to avoid that outcome entirely (except by never shipping, which would be a tragedy), but I think there are ways to minimize it. When your first priority is to deliver revenue numbers to Wall St. this quarter, or crush Microsoft, or surprise your competitors by unveiling your stealth project, your options are limited.
>> 
>> But if you have the luxury of making the best possible language design your first priority, do whatever you can to get the world to help before committing to 1.0.
>> 
>> No matter how smart you are, the world collectively is smarter. It's also self-contradictory, overwhelming, and chaotic, so taking advantage of that extra smartness isn't trivial, but I think it's a tremendously valuable resource. You've already been engaging the world to some extent via this forum, but maybe one last push would be useful.
>> 
>> Before making the 1.0 committment, you might consider getting some docs together that describe the *goals* for the language (what you're trying to optimize for), and why you believe the existing design decisions to be better than their major alternatives at meeting those goals. Just the process of writing such a thing, as a pursuasive document, not as a declaration of fact, might be useful to you.
>> 
>> Then get the word out (Slashdot, etc.) that you'd like people to read these design arguments, think about them, try writing some code, and then respond with their highest priority requests for any changes.
>> 
>> Then instead of defending your previous decisions, as is a natural temptation, and doing battle with the change suggestions, try to relax and see what emerges. Try to imagine that nothing had been decided (or implemented!) yet, that there was no existing design to defend, and you were free to let a design "emerge" naturally from the data.
>> 
>> This emergence isn't a majority vote, just a sense of what the mass of users were thinking that you could adapt to without legacy constraints on your decision making.
>> 
>> I think the existing design is so close to optimal for what you are optimizing for that the fundamental design of D will be overwhelmingly endorsed. Also, since the existing design would form the basis for discussion, what I think would emerge would simply be minor modifications. People's highest priority change requests would be in the details, I believe.
>> 
>> I really think that if you could relax your commitment to the existing details and dispassionately observe what emerges and implement that, it would be better than what you have now, though I don't know how. (Sort of a stochastic optimization algorithm that isn't best for each individual but is best overall.) I also think it would be so close to what you have that the changes would be relatively minor, though if what emerged did imply a need for big changes, you'd want to know that before 1.0 since it would eventually become obvious later, and later might be too late.
>> 
>> 

In article <1lj4myiqvas8v$.coq7aamqhkac$.dlg@40tude.net>, Derek Parnell says...
>
>On Thu, 3 Mar 2005 16:04:23 +1100, Derek Parnell wrote:
>
>> On Wed, 2 Mar 2005 20:49:38 -0800, Andrew Fedoniouk wrote:
>> 
>>>>
>>>> will change enough to cause any D source today to undergo major rewrites? I can answer the latter concern - it isn't going to happen.
>>>>
>>> 
>>> Walter, for the Mars sake and other mebers of Panteon, could you shed a light on future of "external-methods"?
>>> 
>>> I mean this was supported last time I checked it
>>> char[][] split(char[] s, char c) { ... }
>>> char[] s = "a b c";
>>> char[][] sv = s.split(' ');
>>> 
>>> May I rely on this trick?
>> 
>> I sure hope so 'cos I've spent the last couple of weeks writing a whole heap of code that depends on this behaviour.
>
>In fact, I'd like this syntax extended for non-array built-in types too.
>
>bool Foo(real A, char[] B) { . . . }
>real x;
>
>if ( x.Foo("abc") ) { . . .};
>
>It would make life *so* much easier rather than special coding for structs, some more for classes, and some more for built-in types.
>
>I mean, these are decisions that the compiler can make with making me work so hard :D
>
>-- 
>Derek
>Melbourne, Australia
>3/03/2005 4:11:36 PM


Careful though. I bet this does not work:

class Bar
{
bool Foo(real A, char[] B) { . . . }
}

real x;

if ( x.Bar.Foo("abc") ) { . . .};

This is potentially the kind of thing that /might/ be pulled. Not saying that it will, but the peripheral stuff is often yanked for a major release (as Glen described so well).

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d0651s$1mgp$1@digitaldaemon.com...
> >
> > will change enough to cause any D source today to undergo major
rewrites?
> > I can answer the latter concern - it isn't going to happen.
> >
>
> Walter, for the Mars sake and other mebers of Panteon, could you shed a light on future of "external-methods"?
>
> I mean this was supported last time I checked it
> char[][] split(char[] s, char c) { ... }
> char[] s = "a b c";
> char[][] sv = s.split(' ');
>
> May I rely on this trick?

I don't see any reason to take it out.

>
> I sure hope so 'cos I've spent the last couple of weeks writing a whole heap of code that depends on this behaviour.
>

:)

Thanks a lot, Walter.

>> I mean this was supported last time I checked it
>> char[][] split(char[] s, char c) { ... }
>> char[] s = "a b c";
>> char[][] sv = s.split(' ');
>>
>> May I rely on this trick?
>
> I don't see any reason to take it out.
>

In article <d04p7a$550$1@digitaldaemon.com>, Walter says...
>
>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"?

Are you speaking about the language or the compiler? I think we are ready for a "D language specification 1.0", while for the "Digital Mars D compiler 1.0" you still need some little work (you are close, though).

The real point is: what is D? A language? A language + a reference compiler? Language + compiler + library? Either one is good, but if you want a commercially viable product, I think you should offer more.

I'm still convinced that the big Java success was due to a standard library and a standard GUI. This was the boost that converted a little language to do web pages to one of the most used programming language in the world.

While D is a very good language, we are no more in the 1980s, when C++ was born
(and even that, I think OWL and MFC made most of its success). A language with a
core library can be good only for some niche today, while to appeal the vast
majority of developers (and especially managers) you should provide more.
What? An IDE and a GUI. Do them yourself, let's do them all toghether, find a
company that will do them, but do something.

Ciao

Roberto Mariottini wrote:

>>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"?
> 
> Are you speaking about the language or the compiler? I think we are ready for a
> "D language specification 1.0", while for the "Digital Mars D compiler 1.0" you
> still need some little work (you are close, though).

Excellent comment! If there was only DMD, I know I wouldn't have started with D. Luckily, David Friedman took the frontend and some other patches and turned into something really useful! (which is GDC if you missed it)
http://home.earthlink.net/~dvdfrdmn/d/

I still think D specification needs more work before it can be "frozen"

> The real point is: what is D? A language? A language + a reference compiler?
> Language + compiler + library? Either one is good, but if you want a
> commercially viable product, I think you should offer more.

Java was the one pioneering mixing all terms together in a blender...
And then Sun went on to rename their apps, hardware and their linux ?

Fortunately, it's more sane here in the Digital Mars part of the woods:
D is the language, DMD is a D compiler, Phobos is the D runtime library

But a more clear separation of D, DMD and Phobos could be useful,
as has been suggested before (and partly started upon by several)

> I'm still convinced that the big Java success was due to a standard library and
> a standard GUI. This was the boost that converted a little language to do web
> pages to one of the most used programming language in the world.

Java has changed both their standard library and standard GUI since...

It started out with a small little language (that was Java 1.0) which
changed greatly into the new language (Java 2). The GUI changed from
the native AWT to the all-java Swing, more or less at the same time.
The Collections API also replaced the first simple array/hash classes.
(for some reason they still left all the old stuff in too, deprecated)

So I'm not sure the Java of today is even the same as it was back then ?
(especially not with "Java 2 version 5" and SWT being a AWT/Swing merge)

> What? An IDE and a GUI. Do them yourself, let's do them all toghether, find a
> company that will do them, but do something.

Many IDEs can be "persuaded" into supporting D, as well as C/C++/etc.
And this with out redoing a full development environment from scratch?
http://www.algonet.se/~afb/d/xcode/

As for GUIs, there are a few out there but they're all rather big to
be shipping with the language or even runtime library. Maybe MinWin ?
http://home.comcast.net/~benhinkle/minwin/


I'm not sure that D needs either of a IDE or GUI bundled with it,
and for that matter it can sure use more than just one compiler...

It now mostly seems to be about a) documentation b) co-operation ?
(in order to use the existing IDEs and GUIs with any "D", that is)

--anders

Walter wrote:

> Documentation:
> 
> If someone wants to go through the current spec with a critical eye, and
> send me a detailed critique on it (or at least focus on some particular part
> of it), so that can be improved, it would be a big help. I go through it
> from time to time, each time noticing new things and fixing them, but
> reviewing one's own writing is not so effective since one sees what one
> intended to write, not what is actually there.

Well, you could start with the Wiki4D - since that is the method
of leaving feedback that is recommended on *each* official page,
but still has a lot of typos and other corrections that haven't
made into back into the offical spec pages a few years later ?

Just delete them from the Wiki page, after correcting them...
(leaving just the discussion and controversy on the Wiki4D)

--anders

brad@domain.invalid wrote:
> Walter wrote:
> 
>> <brad@domain.invalid> wrote in message
>> news:d05gbg$11g0$1@digitaldaemon.com...
>>
>>> clayasaurus wrote:
>>>
>>>> I know when I first started out D, I was wondering why all my classes
>>>> would seg fault :-/ (it was because i never 'newed' it).
>>>
>>>
>>> I totally agree.  I still get bitten by segfaults.  I start taking the C
>>>  approach to finding them, by rolling up my sleaves and looking for
>>> possible null pointer references, etc.
>>
>>
>>
>> Too find them, compile with -g and then run it under the debugger. The
>> debugger will point you at which line failed.
> 
> 
> I guess I've gotten out of the habit of using a debugger with D because it initially wasn't supported under Linux.

Old versions of Turbo Pascal used to show the address where the program crashed. Then you'd give this address to the compiler, and it would recompile till it found the address, and then show what source line that corresponds to.

At least on Linux one could install a handler for SIGSEGV to output the offending location.