On 2/23/12 6:46 PM, Andrei Alexandrescu wrote:
> On 2/23/12 6:01 PM, F i L wrote:
>> It's unrealistic to think people (at large) will be writing any sort of
>> serious application outside of a modern IDE.
>
> You'd hate working for Facebook :o).
>
> Andrie

I tried to remove the message above, but Thunderbird doesn't recognize it as coming from me. Is there some recent change in the forum that could be linked to that?

I think Thunderbird recognizes messages by a specific author by comparing email addresses.


Thanks,

Andrei

On 24 February 2012 13:15, F i L <witte2008@gmail.com> wrote:
> H. S. Teoh wrote:
>>>
>>> In all seriousness, I think you're decoupling inherently ingrained pieces: the language and it's tools. The same way you *need* syntax highlighting to distinguish structure,
>>
>>
>> I don't.
>
>
> wait... you don't even use Syntax Highlighting? Are you insane, you'll go blind!

I think my colleague was blind before he start programming, but he doesn't use syntax higlighting

>>> And MS has pulled some really stupid shit in its day, but it's developer tools and support do not fall under that category.
>>
>>
>> True, they have their value. I don't argue with that.
>>
>> But why should anyone be *forced* to use them? They're just tools. A language is a language (a set of syntax and grammar rules with the associated semantics). It's not inherently tied to any tools.
>
>
> The only reason Visual Studio being so closely tied to C#/VB/etc is a bad thing is because it's closed source and ultimately designed as [yet another] developer lock-in (just good business right?). Beyond that it's really silly not to use VS cause of all the productive features it provides. MonoDevelop is catching up, but still quite a ways behind in some areas. No one is stopping anyone from writing code in Notepad.. but then, no one is stopping 3D artists from manually editing .obj files in Notepad either.
>

As Teoh said, Notepad is not a workable text editor, for a start, it doesn't support a massive range of modern features (like unicode, or non CRLF line terminators), doesn't do any useful code-related stuff like indentation or bracket-matching.

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.

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).

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

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

-- 
To err is human; to forgive is not our policy. -- Samuel Adler

On Thursday, February 23, 2012 21:50:27 H. S. Teoh wrote:
> 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

Obligatory XKCD:

http://xkcd.com/378/

:)

- Jonathan M Davis

On 24/02/2012 00:48, Andrei Alexandrescu wrote:
> On 2/23/12 6:46 PM, Andrei Alexandrescu wrote:
>> On 2/23/12 6:01 PM, F i L wrote:
>>> It's unrealistic to think people (at large) will be writing any sort of
>>> serious application outside of a modern IDE.
>>
>> You'd hate working for Facebook :o).
>>
>> Andrie
>
> I tried to remove the message above, but Thunderbird doesn't recognize
> it as coming from me. Is there some recent change in the forum that
> could be linked to that?
>
> I think Thunderbird recognizes messages by a specific author by
> comparing email addresses.
>
>
> Thanks,
>
> Andrei

Obviously it goes by signature now ^^

A...

On 2/23/2012 4:01 PM, F i L wrote:
> Well then I disagree with Walter on this as well. What's wrong with having a
> "standard" toolset in the same way you have standard libraries? It's unrealistic
> to think people (at large) will be writing any sort of serious application
> outside of a modern IDE. I'm not saying it's Walters job to write IDE
> integration, only that the language design shouldn't cater to the smaller
> use-case scenario.

Do you really want a language that the source code isn't readable or browsable outside of an IDE?

Like the switch from command line to GUI, perhaps there are some that are ready to switch from text files to some visually graphy thingy for source code. But D ain't such a language. I don't know what such a language would look like. I've never thought much about it before, though I heard there was a toy language for kids that you "programmed" by moving boxes around on the screen.

Am 24.02.2012 11:43, schrieb Walter Bright:
> On 2/23/2012 4:01 PM, F i L wrote:
>> Well then I disagree with Walter on this as well. What's wrong with
>> having a
>> "standard" toolset in the same way you have standard libraries? It's
>> unrealistic
>> to think people (at large) will be writing any sort of serious
>> application
>> outside of a modern IDE. I'm not saying it's Walters job to write IDE
>> integration, only that the language design shouldn't cater to the smaller
>> use-case scenario.
>
> Do you really want a language that the source code isn't readable or
> browsable outside of an IDE?
>
> Like the switch from command line to GUI, perhaps there are some that
> are ready to switch from text files to some visually graphy thingy for
> source code. But D ain't such a language. I don't know what such a
> language would look like. I've never thought much about it before,
> though I heard there was a toy language for kids that you "programmed"
> by moving boxes around on the screen.

I think you mean Robot Karol, but this uses also a basic like syntax.

Le 18/02/2012 22:18, Timon Gehr a écrit :
> On 02/18/2012 10:06 PM, deadalnix wrote:
>> Le 18/02/2012 16:04, Timon Gehr a écrit :
>>> For them, it is certainly safe. It is questionable how large the
>>> effective benefit is for const, since the const qualifier would be
>>> inherited for the method only, but not for its parameters.
>>>
>>
>> The const qualifier does NEVER qualify a function. This is a
>> misconception.
>
> I don't care whether or not it is a misconception. It is how the
> language is defined. If you want to change this, file an enhancement
> request.
>
>> In what we call const function, what is const is the
>> hhidden parameter "this", not the function.
>
> Both are const. Ask the compiler.
>
> struct S{
> void foo()const{
> static assert(is(typeof(this)==const));
> static assert(is(typeof(foo)==const));
> }
> }
>
> In fact, the incident that the method is const is what enables
> contravariant overriding of mutable/immutable by const methods. (This is
> not supported for the explicit formal parameter types.)

The spec is incosistent.

Either the function isn't const, and only this is const. In this case the inference here doesn't make any sense. const and non const are different and because parameters are differents.

Or we consider that const qualify both the hidden parameter AND the function. In this case, you mustn't be able to define both a const and a non const version of a function. Just like a function is pure or non pure, and you cannot define twice the same function, with one pure version and an impure one. This has the advantage of imporving covariance in overload, but if you can define both const and non const version of a function, then you ends up with crazy situation where all overload change meaning if I add a function is the base class - with no warning, no errors, just a completely fuckup program and hours of happy digging in the code to clean this up.

Le 17/02/2012 17:19, Andrei Alexandrescu a écrit :
> On 2/17/12 8:13 AM, kenji hara wrote:
>> I think the lack of 'override' keyword (filed as bug 3836) should
>> become an error, without the phase of deprecating it. Otherwise
>> following case will be allowed.
>
> Yes. Walter?
>
> Andrei

I'm surprised this isn't even mentionned in http://drdobbs.com/blogs/cpp/232601305

I definitively don't think that pushing stuff like that - I'm suspecting for ego reasons - ignoring some flaw of the idea is a good way to proceed. This even may be armfull for the language on the long run.

With no override keyword, function can just explode on your face for no aparent reason in the source code you are lookign at. This isn't an issue we should ignore.

This has a pretty simple solution : don't inherit thoses attributes of override isn't present.  On the long run, don't allow override without override keyword ?

Le 23/02/2012 21:22, so a écrit :
> On Thursday, 23 February 2012 at 18:32:12 UTC, Walter Bright wrote:
>
>> Not a bad idea, but it would be problematic if there were any overloads.
>
> It is still applicable to return types.
> But i don't like the idea. If you omit arguments and return type, you
> force both yourself and the reader to check the base class for everything.
>
>

The return type can be define according to the function body. This make more sens than with overload : return type can be covariant, and in all cases, the body function will have to return the right type.

So this doesn't provide more than what we already have with auto.