On Friday, 24 February 2012 at 05:05:29 UTC, James Miller wrote:

> You seem to think that there is "Notepad" or Visual Studio/eclipse,
> when in reality there is a sliding scale, from using cat to output to
> a file to using, well Eclipse or VS. But there are points along the
> way, like Jonathon, I'm a (g)vim user, I tend to develop in gvim and
> do quick edits in vim (tiling window manager, I don't like the switch
> from full-screen to half-a-screen then back again), I have tried all
> sorts of other systems and eventually just worked my way back to the
> terminal. My ongoing quest for productivity has led me to believe
> that, unless you want to be tied to a technology, back to basics is
> the best way.

That's analogous to saying that you don't want to depend on a lighter since you can make your own fire by rubbing a stone with a wood stick. A lighter does tie you to a certain technology but loosing the lighter doesn't make for more productivity. Misuse of the tool or using the wrong one sure could hamper productivity but that's hardly the fault of technology.

>
> I personally believe that any set of tools should be made thinking
> about the use case: "What if this person was developing using a
> Tektronix 4014?", I'm not saying that we should still be coding to 30
> year old terminals, but the idea is that somebody might not having a
> gui should not immediately be a blocker. This has been Windows'
> Achilles' heel for a while, many products don't work without a gui,
> and therefore are difficult - or impossible - to script. If you can
> provide a programmatic interface to your system, then you have just
> allowed a ton more products to be made, at no extra cost to you. Clang
> has built-in support for auto-completion and syntax analysis and the
> front-end is even nicely packaged into a library, so I now have
> C/C++/Objective-C, context-aware, accurate completion in vim, through
> the vim plugin clang-complete, this was not made by the people at
> Clang, they just exposed the functionality (by the way, XCode uses the
> same system, and Code::Blocks is moving their code-model to it too).

The above regarding MS is incorrect. MS has lots of automation and is far better at it than *nix systems are. Its Powershell is superior to the *nix "everything is a file" ideology and there were several attempts to copy the concept to *nix with Python and Ruby.

>
> Programming a craft as much as it is a process. I tend to liken it to
> carpentry, you have set steps, you design and plan and build etc, but
> there's creativity there. As such, programmers (I've found) tend to
> pick an environment that suits them best. I use a minimal system that
> I can configure and hack to my heart's content. My colleague uses a
> Macbook pro that he never shuts down. The designer here uses a Macbook
> Air. And we all work fine, there is no "One True Way" to make a chair,
> why should there be one for writing a program?
>
> My point is that the tools that programmers use, like compilers and
> linkers and parser-generators and build systems and deployment tools
> and source control and x and y and z and .... are going to be used by
> a wide range of people, in a wide range of environments, for a wide
> range of purposes, so they should keep in mind that maybe you /don't/
> have a certain tool or feature available. So you make sure that the
> experience at the lowest common denominator, a vt100 terminal, is
> acceptable, maybe not perfect, but good enough, then you build from
> there. If that means that D is geared towards less typing, then good,
> especially if  you can do the extra typing and not break things. It
> /is/ possible to make everybody mostly happy, and that is by aiming at
> the people using `cat`* to program and hitting the people using VS
> along the way.
>
> * Programming using `cat` is not recommended.**
> ** Even though /real/ programmers use `cat`
>
> --
> James Miller

I disagree. Simply put:

+---------+         +---------+
| Magic   |         | comfort |
| happens |         |  zone   |
| here!   |         +---------+
+---------+

Magic cannot happen here ^.

On Saturday, 25 February 2012 at 17:57:54 UTC, Timon Gehr wrote:
>> class A {
>>     void fun() const { ... }
>> }
>>
>> class B : A {
>>     override void fun() { ... }
>> }
>>
>> Now I change the class A to become :
>>
>> class A {
>>     void fun() const { ... }
>>     void fun() { ... }
>> }
>>
>> And suddenly, the override doesn't override the same thing anymore.
>> Which is unnacceptable.
>
> You didn't try to actually compile this, did you? ;D

You can't compile that now, can you?

On Friday, 24 February 2012 at 05:48:51 UTC, H. S. Teoh wrote:
> On Fri, Feb 24, 2012 at 06:05:20PM +1300, James Miller wrote:
> [...]
>> My ongoing quest for productivity has led me to believe that, unless
>> you want to be tied to a technology, back to basics is the best way.
>
> That's an interesting observation. I have to agree.
>
>
>> I personally believe that any set of tools should be made thinking
>> about the use case: "What if this person was developing using a
>> Tektronix 4014?", I'm not saying that we should still be coding to 30
>> year old terminals, but the idea is that somebody might not having a
>> gui should not immediately be a blocker.
>
> This reminds me of a very insightful quote I found online a while ago:
>
> 	A program should be written to model the concepts of the task it
> 	performs rather than the physical world or a process because
> 	this maximizes the potential for it to be applied to tasks that
> 	are conceptually similar and, more important, to tasks that have
> 	not yet been conceived. -- Michael B. Allen
>
>
>> This has been Windows' Achilles' heel for a while, many products don't
>> work without a gui, and therefore are difficult - or impossible - to
>> script. If you can provide a programmatic interface to your system,
>> then you have just allowed a ton more products to be made, at no extra
>> cost to you.
>
> It's exactly as I quoted above: by limiting yourself to a GUI, you have
> limited the applicability of your program, even if what the program
> actually *does* is not inherently related to a GUI.
>
>
>> Clang has built-in support for auto-completion and syntax analysis and
>> the front-end is even nicely packaged into a library, so I now have
>> C/C++/Objective-C, context-aware, accurate completion in vim, through
>> the vim plugin clang-complete, this was not made by the people at
>> Clang, they just exposed the functionality (by the way, XCode uses the
>> same system, and Code::Blocks is moving their code-model to it too).
>
> "This maximizes the potential for it to be applied ... to tasks that
> have not yet been conceived." :-)
>
>
> [...]
>> * Programming using `cat` is not recommended.**
>> ** Even though /real/ programmers use `cat`
> [...]
>
> Oh? I thought *real* real programmers use a soldering iron, a pair of
> tweezers, a magnifying glass, and really *really* steady hands... Tricky
> things to program, those new-fangled nanometer-scale microprocessors
> they make these days. :-P
>
>
> T

Clearly, the quote above is misapplied since clang's applicability has everything to do with its good modular design and its API and nothing to do with the arguing over GUI vs. CLI. In fact, CLI forces its own set of limitations on the program.

On 2/25/12 11:53 AM, deadalnix wrote:
> class A {
> void fun() const { ... }
> }
>
> class B : A {
> override void fun() { ... }
> }
>
> Now I change the class A to become :
>
> class A {
> void fun() const { ... }
> void fun() { ... }
> }
>
> And suddenly, the override doesn't override the same thing anymore.
> Which is unnacceptable.

I agree that that's a problem.

Andrei

On 2/25/12 11:57 AM, Timon Gehr wrote:
> On 02/25/2012 06:53 PM, deadalnix wrote:
>> class A {
>> void fun() const { ... }
>> }
>>
>> class B : A {
>> override void fun() { ... }
>> }
>>
>> Now I change the class A to become :
>>
>> class A {
>> void fun() const { ... }
>> void fun() { ... }
>> }
>>
>> And suddenly, the override doesn't override the same thing anymore.
>> Which is unnacceptable.
>
> You didn't try to actually compile this, did you? ;D

Apparently me neither.

Andrei

On 02/25/2012 09:05 PM, so wrote:
> On Saturday, 25 February 2012 at 17:57:54 UTC, Timon Gehr wrote:
>>> class A {
>>>     void fun() const { ... }
>>> }
>>>
>>> class B : A {
>>>     override void fun() { ... }
>>> }
>>>
>>> Now I change the class A to become :
>>>
>>> class A {
>>>     void fun() const { ... }
>>>     void fun() { ... }
>>> }
>>>
>>> And suddenly, the override doesn't override the same thing anymore.
>>> Which is unnacceptable.
>>
>> You didn't try to actually compile this, did you? ;D
>
> You can't compile that now, can you?

Exactly, it won't compile. It was an explicit measure to prevent this form of function hijacking.

On 2/25/2012 9:53 AM, deadalnix wrote:
> And suddenly, the override doesn't override the same thing anymore. Which is
> unnacceptable.

class A {
    void fun() const {  }
    void fun() {  }
}

class B : A {
    override void fun() {  }
}

----

dmd -c foo
foo.d(6): Error: class foo.B use of foo.A.fun() hidden by B is deprecated

Le 25/02/2012 21:44, Walter Bright a écrit :
> On 2/25/2012 9:53 AM, deadalnix wrote:
>> And suddenly, the override doesn't override the same thing anymore.
>> Which is
>> unnacceptable.
>
> class A {
> void fun() const { }
> void fun() { }
> }
>
> class B : A {
> override void fun() { }
> }
>
> ----
>
> dmd -c foo
> foo.d(6): Error: class foo.B use of foo.A.fun() hidden by B is deprecated

So, how do someone override the non const version of the function but not the const version ?

On 02/25/2012 10:28 PM, deadalnix wrote:
> Le 25/02/2012 21:44, Walter Bright a écrit :
>> On 2/25/2012 9:53 AM, deadalnix wrote:
>>> And suddenly, the override doesn't override the same thing anymore.
>>> Which is
>>> unnacceptable.
>>
>> class A {
>> void fun() const { }
>> void fun() { }
>> }
>>
>> class B : A {
>> override void fun() { }
>> }
>>
>> ----
>>
>> dmd -c foo
>> foo.d(6): Error: class foo.B use of foo.A.fun() hidden by B is deprecated
>
> So, how do someone override the non const version of the function but
> not the const version ?

By explicitly stating that he is aware of all the overloads:

class B : A {
    alias A.fun fun;
    override void fun() {  }
}

Alternatively:

class B : A{
    override void fun()const{super.fun();}
    override void fun() {  }
}

Le 25/02/2012 22:25, Timon Gehr a écrit :
> On 02/25/2012 10:28 PM, deadalnix wrote:
>> Le 25/02/2012 21:44, Walter Bright a écrit :
>>> On 2/25/2012 9:53 AM, deadalnix wrote:
>>>> And suddenly, the override doesn't override the same thing anymore.
>>>> Which is
>>>> unnacceptable.
>>>
>>> class A {
>>> void fun() const { }
>>> void fun() { }
>>> }
>>>
>>> class B : A {
>>> override void fun() { }
>>> }
>>>
>>> ----
>>>
>>> dmd -c foo
>>> foo.d(6): Error: class foo.B use of foo.A.fun() hidden by B is
>>> deprecated
>>
>> So, how do someone override the non const version of the function but
>> not the const version ?
>
> By explicitly stating that he is aware of all the overloads:
>
> class B : A {
> alias A.fun fun;
> override void fun() { }
> }
>
> Alternatively:
>
> class B : A{
> override void fun()const{super.fun();}
> override void fun() { }
> }

So, back to the example above, someone will have to go throw the whole codebase and add override void fun()const{super.fun();} all over the place to fix the broken code ?

It is better, but still . . .