Not that this debate has any value, since const, et al are currently being implemented and that's not remotely likely to change, but here's my opinion, for what it's worth:

For any non-trivial application, const (and it's stronger brother invariant) is a must to allow me and the people I work with to both specify the behavior of routines in their signature, and to actually provide enforcement.  I can't consider a language without the ability to make these sorts of guarantees without stupid work around like copying data left and right a usable language.  It's an interesting toy, but it can't graduate to anything besides toy apps.  I recognize that non-toy apps have been written with D, and that's great.  So, for me, const is an 'every app' layer feature, or at least any library / application of significant size.  There's no way in hell that 'const' can be called a nerd feature.

Reflection, while a very very powerful feature, is something that's useful in a subset of applications.  Additionally, it's not like reflection has been totally ignored.  The features of it have _also_ been increasing over time.  D might not match Java yet, but few features of this weight are black and white.  Between CTFE, Mixins, and the compile time reflection that's already available, I suspect it's possible to write a reflection library that covers a high percentage of java's functionality.  I highly encourage anyone who is in serious need of runtime reflection take a stab at it and report back a prioritized list of what's missing.

Later,
Brad

BLS wrote:
> I agree. (and I am afraid that reflection will take along long time) Bjoern
> 
> bobef Wrote:
> 
>> Without any disrespect to the great work you are doing, let me put
>> it in another way: In order to make a good, *usable* application,
>> is this "const final scope" thing more important or having a good
>> GUI library? There are not many console applications these days,
>> you know. And they are not very *usable*. And, as we all know,
>> choosing a GUI for D is not like choosing a GUI for C++. So why
>> instead of adding nerd stuff to the language, make it sooooo much
>> more *usable*, by fixing the reflection stuff that Tioport needs to
>> produce libraries which are not 10mb or 20mb? Or... it kind of
>> sucks when half of my code won't compile, or compiles in specific
>> order only, because of some forward reference errors. I don't even
>> know what forward reference is, but I know that using (simple)
>> consts and aliases is something perfectly legal. I don't know if
>> this second example is more usable than the final cosnt thing, just
>> because I can't think of any use of it, but this is because I
>> rarely use fancy stuff that breaks my code in the next version of
>> DMD... But I am making this example to show that D (or DMD) still
>> have so many things to fix the way it is now, we don't need some
>> new fancy stuff before the old things work....
>> 

bobef wrote:
> Although many geeks won't believe it times are changing
> and the console interface has no future.

Hmm. That's as smart as saying that typewriters will obsolete the pen.

They are both needed. Neither will completely replace the other.

I use pen twice a year. People have all this pocket PCs with digital pens and stuff. Voice recognition is evolving too. Who knows in few years someone may come up with a mind reading machine... I know it is hard to change one's habits but loot at things from another view point. Even if you and me don't want to give up the console (yes, I am still using it too), we are aging and the newer people don't have such habits like consoles and pens... So these tools are indeed fading away... Nothing is permanent, you know...

Georg Wrede Wrote:

> bobef wrote:
> > Although many geeks won't believe it times are changing
> > and the console interface has no future.
> 
> Hmm. That's as smart as saying that typewriters will obsolete the pen.
> 
> They are both needed. Neither will completely replace the other.

Brad Roberts wrote:
> For any non-trivial application, const (and it's stronger brother invariant) is a must to allow me and the people I work with to both specify the behavior of routines in their signature, and to actually provide enforcement.

The combination of const, invariant, final, and scope will allow one to be much more expressive on the intended usage of a variable than C++ does, along with enforcement of it.

One downside is there's no dipping one's toe into const-correctness. It's got to be done whole hog.

On Sun, 20 May 2007 00:21:40 +0200, bobef <asd@asd.com> wrote:
>> bobef wrote:
>> > Although many geeks won't believe it times are changing
>> > and the console interface has no future.
>>
>> Hmm. That's as smart as saying that typewriters will obsolete the pen.
>>
>> They are both needed. Neither will completely replace the other.
>

Even if every PC had voice recognition, I don't think it would be perfect, because even humans often misunderstand what another fellow meant to say. Language is pretty complex, and there can be a lot of ambiguity even in simple sentences. I wouldn't feel very comfortable about telling my PC to delete a certain folder, while it could very well destroy the wrong one. Maybe the computer could ask you to confirm the command every time before it is executed, or even allow you to edit the command in a pop-up text box before execution. I'm not sure though where the added benefit of a CPU-intensive voice-recognition program is, whilst it should be more effective to directly type the command that is on your mind in the console. So I don't think that the console is unnecessary or that it will be replaced by anything else anytime soon. It would be better to enhance it rather than get rid of it. To my mind the console is absolutely indispensible for certain tasks, and it is often much easier to type in a series of commands than to accomplish the same with a GUI driven program. I don't think the console and the GUI are in conflict, but they very much complement each other. When I switched to Linux I really began to appreciate how powerful a console can be, that's why I have to cringe every time I have to use the Windows abomination of a console :-)

Aziz K. wrote:
> On Sun, 20 May 2007 00:21:40 +0200, bobef <asd@asd.com> wrote:
>>> bobef wrote:
>>> > Although many geeks won't believe it times are changing
>>> > and the console interface has no future.
>>>
>>> Hmm. That's as smart as saying that typewriters will obsolete the pen.
>>>
>>> They are both needed. Neither will completely replace the other.
>>
> 
> Even if every PC had voice recognition, I don't think it would be perfect, because even humans often misunderstand what another fellow meant to say. Language is pretty complex, and there can be a lot of ambiguity even in simple sentences. I wouldn't feel very comfortable about telling my PC to delete a certain folder, while it could very well destroy the wrong one. Maybe the computer could ask you to confirm the command every time before it is executed, or even allow you to edit the command in a pop-up text box before execution. I'm not sure though where the added benefit of a CPU-intensive voice-recognition program is, whilst it should be more effective to directly type the command that is on your mind in the console. So I don't think that the console is unnecessary or that it will be replaced by anything else anytime soon. It would be better to enhance it rather than get rid of it. To my mind the console is absolutely indispensible for certain tasks, and it is often much easier to type in a series of commands than to accomplish the same with a GUI driven program. I don't think the console and the GUI are in conflict, but they very much complement each other. When I switched to Linux I really began to appreciate how powerful a console can be, that's why I have to cringe every time I have to use the Windows abomination of a console :-)

Agreed. My experience of D has really reinforced to me that GUIs are evil for development. When developing logic or algorithms, it's a hundred times easier doing it with a console app. Run your GUI for testing and developing your GUI, and for *nothing else*.

Don Clugston wrote:
> 
> Agreed. My experience of D has really reinforced to me that GUIs are evil for development. When developing logic or algorithms, it's a hundred times easier doing it with a console app. Run your GUI for testing and developing your GUI, and for *nothing else*.

Many of the C/C++ examples in MSDN are terrible for exactly this reason.  There are perhaps 5-10 lines of useful information buried in pages of useless stuff.  What I tend to do is develop algorithms and such separately in a console app and only move it into the real app once I've got it working properly.


Sean

Chris Nicholson-Sauls wrote:
> bobef wrote:
>> Do you think that any user cares about if you use consts in your code or not? This is what I mean when I talk about usability. We write applications not code. We should focus on the usability. If it is easier to write - good, but the application is what is important, no the code (yes, of course it matters too). Plus what consts are you talking about in C++? Just cast them to void* and back to the type without const... If you want to modify it nothing is stopping you, if not just don't do it :)
>>
> 
> No, I don't think users care if I use const.  I do think they care if the program runs quickly and is stable -- both of which const contributes to, by avoiding unnecessary copies of data and pre-empting bugs before they happen.  Yes I can use trickery and break the type system to get around it -- but if I'm doing that, there's probably something wrong with the design to begin with.  This /is/ aiding library writers, and app writers. Once this is done, hopefully the major issues will be the next to get attention.
> 
> I really don't think the console is going away anytime soon.  A friend recently needed a new log parsing utility.  The one we tossed together in an afternoon in D, on the console, finished within minutes -- compared to the old (GUI) app he'd been using that took hours.  GUI isn't always a blessing.  (All this program even need as input was a filename. Adding GUI to something like that is merely bloat and slowdown.)
> 
> Usability is important, I agree.  But software that's quick and easy to write, is also quicker and easier to /make/ usable.  And GUI isn't always the answer to usability. That's my stance in a tiny overly restrictive nutshell.  (Walnut?  Maybe pecan...)
> 
> -- Chris Nicholson-Sauls

May be, Walter could be centered solving bugs and closely working with debugger developpements (ddbg?).

anyway, "in" is a good hight level pogramming feature for people that uses D as hight level language (is expressive of an intention)