June 27, 2007
Walter Bright wrote:
> Daniel Keep wrote:
>>
>> Walter Bright wrote:
>>> ... A lot of people use Python, and are forced
>>> to mix in C++ to speed up the slow parts. It would be much simpler for
>>> them if they could use the same language for both.
>>
>> I'll have to disagree on this.  I used Python for my third year
>> comp.sci. group project, and it made things a hell of a lot easier.
>> Most of the code was dealing with the GUI, with only a few math-heavy
>> parts written by myself.
>>
>> Using Python for the mathy parts made them so much easier to debug it
>> wasn't funny, and I've never seen anything that could touch Python for
>> writing sane GUI code.
>>
>> In the end, I had to convert some of the slower code from Python to C,
>> but that was basically a trivial exercise.  Pyrex allows you to write
>> "Python-like" code that compiles directly to C that makes writing the
>> native module wrapping C code a non-issue.
>>
>> If I'd used just C++, the GUI coding would have driven me completely
>> insane.  If I'd been restricted to an interpreted language, our app
>> would have been slow as molasses.  By using Python, we got the best of
>> both worlds :)
> 
> Everyone knows that C++ sucks for writing GUIs, I hope to do much better with D.
> 
>>
>> In a wacky kind of way, one of the reasons I chose Python was *because*
>> it could be easily optimised.  True, it had to be done in a different
>> language, but there was almost no effort required to do so, so I never
>> had to fear hitting a performance ceiling.
> 
> But you did hit a performance ceiling. You had to convert the bottlenecks to C. Wouldn't it be nice not to have to do that? <g>


Yes, but "dynamic everything" is a big part of what makes GUIs so easy to write in a language like Python.  At the end of the day D is still going to be a statically typed language, so I don't think it'll ever be able to compete with a scripting language when it comes to the malleability of the code.

For example in the program I'm writing in Python now I realized that it would be convenient to get some notification any time any member of a particular class got modified.  In Python it's a snap.  Just make a 10-line subclass that overrides __setattribute__ and use that instead of the original class and you're done.  None of the rest of the code I had written had to change a whit.  With D, the conversion would not be so easy, and in the end I'd still have to change client code here and there because foo.x+=5 doesn't work with D properties.

That said, it's already a lot less painful writing GUI code in D than it is in C++ (GC, delegates, 'auto', and 'with' come to mind).  I just don't think a statically typed, compiled language will ever really be able to compete with a scripting language on the GUI front.

On the other hand, a dynamic scripting language will never be able to compete with D on the speed front.  So you need both.  The price I pay for the convenience of being able to override __setattribute__ occasionally is that *all* attribute accesses have to happen via string lookups *all the time*.

I tried Pyrex for the first time last week because I was worried my core math routines would become a bottleneck.  It's pretty impressive.  I really didn't think it would be so easy to use.  I don't even know if I have a bottleneck in the math yet, but Pyrex turned out to be so easy to use it was like "heck! why not?".

I think the take home message is that people are quite willing to write/re-write performance critical parts of their code in a slightly restricted dialect if they can have unbounded expressiveness in the rest of their code.

What does it mean for D?  Well maybe For D maybe this could mean a third flavor of aggregate --
- struct: low-level value aggregate
- class: static polymorphic aggregate
- dclass: dynamic polymorphic aggregate (new!)

The difference would be that dclass would do everything dynamically ('d' for "dynamic").  All member lookups via strings.  All property accesses via special methods that can be overridden.  In that way you could start coding with dclass, and as bottlenecks appear, you just have to transition the performance critical things from 'dclass' to 'class'. Another alternative is to allow some syntax for dynamic members in a class.  But that seems messier to me somehow.  For instance, from my experience using Qt I was constantly asking myself "should this be a slot? should that be a QProperty?"  Why worry?  Just make 'em all slots/properties.  If you need some non-dynamic things in your dclass, make an inner class that's not dynamic.


You mentioned games as a big area where every ounce of speed is important.  But game developers are also some of the biggest consumers of scripting languages today.  I'm not so sure game developers would say they'd like to use the same language for everything, even if they could.    For big system stuff, static typing can really eliminate a ton of typical errors (little typos and thinkos especially).  For low-level rendering code it's critical.  But for designing the content of the game, dynamic tweakability and flexibility is more important, and forcing everything to be declared all the time can be counter-productive (especially when we're talking about artists doing the coding).


I was kinda surprised by the comment that speed was so important, because from the buzz I've been hearing more and more over recent years, the picture is quite the opposite.  Computers are now faster than they need to be for most jobs.  Sure there are exceptions, but they are just that, exceptions.  If you want to play to the numbers, the arena to be in is not performance critical code.  Java probably wouldn't be #1 on Tiobe if performance were the most important thing.  In fact, among the top 10 on Tiobe right now, interpreted languages have a combined score of 56%, with compiled languages (C/C++) only pulling in 27%.


--bb
June 27, 2007
Walter Bright wrote:
> Daniel Keep wrote:
>> In a wacky kind of way, one of the reasons I chose Python was *because*
>> it could be easily optimised.  True, it had to be done in a different
>> language, but there was almost no effort required to do so, so I never
>> had to fear hitting a performance ceiling.
> 
> But you did hit a performance ceiling. You had to convert the bottlenecks to C. Wouldn't it be nice not to have to do that? <g>

I rather like to think you can convert those bottlenecks to D. :-)

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
June 27, 2007
Kirk McDonald wrote:
> Walter Bright wrote:
>> Daniel Keep wrote:
>>> In a wacky kind of way, one of the reasons I chose Python was *because*
>>> it could be easily optimised.  True, it had to be done in a different
>>> language, but there was almost no effort required to do so, so I never
>>> had to fear hitting a performance ceiling.
>>
>> But you did hit a performance ceiling. You had to convert the bottlenecks to C. Wouldn't it be nice not to have to do that? <g>
> 
> I rather like to think you can convert those bottlenecks to D. :-)
> 

I'd rather just do it all in D and leave Python and C on the shelf <g>
June 27, 2007
Walter Bright wrote:
> 
>> or 'readonlyview' considered as an alternative for 'const'? I kind of like the sound of 'readonly', and it doesn't make you think of C++ 'const'... but maybe that's bad.
> 
> readonlyview is too long.

And why not just 'view' again?  It's short and seems to imply what's being done.


Sean
June 27, 2007
Walter Bright wrote:
> Oskar Linde wrote:
>> Walter Bright skrev:
>>>
>>> readonly is a synonym for const, so no improvement there.
>>
>> Read-only isn't synonymous with constant.
> 
> Consider ROM, i.e. "Read Only Memory".

"read only" doesn't say anything about the scope of the property.  It's only equivalent to "constant" if that scope is equal to the scope of the data it references.


Sean
June 27, 2007
Walter Bright wrote:

>> If I'd used just C++, the GUI coding would have driven me completely
>> insane.  If I'd been restricted to an interpreted language, our app
>> would have been slow as molasses.  By using Python, we got the best of
>> both worlds :)
> 
> Everyone knows that C++ sucks for writing GUIs, I hope to do much better with D.

On the other hand, Objective-C is very nice for writing GUIs with and
is what I am using while the D language and the D libraries grows up.

It also allows for interfacing with C (reads C headers) and with C++
(understands C++ objects), so I don't have to wrap or port those over.


The best part is still the IDE (Project Builder/Xcode) and the RAD tool
(Interface Builder), but the objc language blends very well with these.

Much nicer than how it was in legacy environments like Win32 or MacOS,
and less writing than what I get with lowlevel tools like C and GTK+...


If only it was more portable and open source, it would be the solution.
Meanwhile, I'll have to make do with D (and Code::Blocks and wxWidgets).

But when the language specification and standard library issues with D
are sorted, some GUI APIs are looking good: http://clarographics.org/

--anders
June 27, 2007
I don't like "view"... it's too verby and doesn't really imply "you can't touch this" to me. readonly gets my vote, but then again, Walter was able to put const/final/invariant into D without adding a new keyword. On the other hand, he _did_ add ref when a more descriptive one (inout) was already in use... but that's a different issue.

Sean Kelly Wrote:

> Walter Bright wrote:
> > 
> >> or 'readonlyview' considered as an alternative for 'const'? I kind of like the sound of 'readonly', and it doesn't make you think of C++ 'const'... but maybe that's bad.
> > 
> > readonlyview is too long.
> 
> And why not just 'view' again?  It's short and seems to imply what's being done.
> 
> 
> Sean

June 27, 2007
On Wed, 27 Jun 2007 03:18:58 -0400, Robert Fraser wrote:

> I don't like "view"... it's too verby and doesn't really imply "you can't touch this" to me.
> readonly gets my vote, but then again, Walter was able to put const/final/invariant
> into D without adding a new keyword. On the other hand, he _did_ add ref when
> a more descriptive one (inout) was already in use... but that's a different issue.

Let's face it, there isn't a single word in English that means "write access for you using this symbol is denied" which is what the 'const' keyword is trying to express.

If we really must use 'const' (and I'm pretty sure Walter ain't ever, ever, ever going to change his mind) we must start thinking of it as meaning 'constrained' rather than 'constant'. That is, our access to the data represented by the symbol is constrained to just being able to look at it.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
27/06/2007 6:03:39 PM
June 27, 2007
Oskar Linde wrote:

> Apologies for being so harsh (and hyperbolic), but I feel this is (as
> strange as it may sound) a quite important issue.

No reason to apologize, the current implementation is far from perfect, even ignoring the plethora of keywords involved.

Let me try to list some that I have been able to pick up, even in my ignorance:

 * constant don't mean read only, so even though const can be considered to
mean constrained, it don't, and should thus not be used to mean read only.
Oskar's suggestion readonly is the best yet. Add to the damage of the new
const that it in 1.0 always mean immutable. Looking to C++/listening to C++
users in this respect may be the worst mistake in D's history yet.
 * invariant as the keyword for immutable/constant would have been ok, if it
hadn't been for the fact that it is used in another context, where empty ()
had to be added to separate from the immutable meaning. The easy fix is of
course to use const to mean immutable/constant, since readonly should be
used to mean read only.
 * const-by-default has been completely ignored/put down, even if _everyone_
giving their opinion in the newsgroup said "give it a try"

Then there are some things that at least appears to be inconsistent:

 * why are D string literals invariant(char)[] whereas C string literals are
invariant(char*) ? This probably ties in with why invariant(char*) and
invariant(char[]) behaves differently in the first place.

I'm sure there are other questions to ask, or that have already been asked.

Walter, I think it's time to pick up your promise again, to have D go wherever the community wants it to go. This don't currently seem to be happening. It was mentioned on IRC that D 2.000 don't seem to have got much praise yet, and as far as I can see, there are good reasons for this. D is having it's biggest change yet, and the community in general seems to have more or less qualms with the current implementation.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
June 27, 2007
 >  * constant don't mean read only, so even though const can be considered to
> mean constrained, it don't, and should thus not be used to mean read only.
> Oskar's suggestion readonly is the best yet. Add to the damage of the new
> const that it in 1.0 always mean immutable. Looking to C++/listening to C++
> users in this respect may be the worst mistake in D's history yet.
>  * invariant as the keyword for immutable/constant would have been ok, if it
> hadn't been for the fact that it is used in another context, where empty ()
> had to be added to separate from the immutable meaning. The easy fix is of
> course to use const to mean immutable/constant, since readonly should be
> used to mean read only.
>  * const-by-default has been completely ignored/put down, even if _everyone_
> giving their opinion in the newsgroup said "give it a try"
> 

Up to here, I totally agree with you.

> Then there are some things that at least appears to be inconsistent:
> 
>  * why are D string literals invariant(char)[] whereas C string literals are
> invariant(char*) ? This probably ties in with why invariant(char*) and
> invariant(char[]) behaves differently in the first place.
> 

Not sure about the C string thing, but now that I understand the difference, I think it's important that invariant(char[]) and invariant(char)[], and specifying it like that seems a hell of a lot easier than some C++ism along the lines of "invariant char invariant[]".

> I'm sure there are other questions to ask, or that have already been asked.
> 
> Walter, I think it's time to pick up your promise again, to have D go wherever the community wants it to go. This don't currently seem to be happening. It was mentioned on IRC that D 2.000 don't seem to have got much praise yet, and as far as I can see, there are good reasons for this. D is having it's biggest change yet, and the community in general seems to have more or less qualms with the current implementation.

I think the implementation is all right, I just think the syntax needs to be reconsidered. Personally, I think the whole const-final-invariant thing is quite a bit nicer than any other implementation I've seen: being able to mark an object as invariant makes writing threadsafe code a lot easier. If there was a way to mark a class/struct as "invariant after being constructed," then it'd be unbeatable.