On Saturday, 12 May 2012 at 04:19:57 UTC, Walter Bright wrote:
> On 5/11/2012 3:25 PM, SomeDude wrote:
>> I believe it takes no less than a year of full time programming
>> to become a proficient C++ programmer (by proficient, I mean a
>> programmer who doesn't fall in all the traps that the language
>> offers, and therefore spends more time coding than debugging).
>
> Eh, I'd put it much longer than that. Or maybe I just have a different view of proficient!

Yeah, I didn't want to start a discussion on how much time it takes to make a good C++ programmer because I guess everyone has a different idea on this (definition of a "good" programmer, etc), but I agree. :)

On Saturday, 12 May 2012 at 05:16:33 UTC, Nick Sabalausky wrote:
>
> Stupid fucking bitch.

Wow, you seem to love her. :D Cool down, man, it's over. :)

On Saturday, 12 May 2012 at 06:53:34 UTC, SomeDude wrote:

> Indeed, and Timon forgot the best feature of IDEs for bytecode compilers imho: they compile in the background, so that errors are detected while you type. There is no annoying "write-correct" cycle as compile-time errors are shown in real time. That's a *huge* productivity boost. It's actually better than with interpreted or scripted languages, because once you've finished writing code, it will run ! Basically, with modern IDEs, the productivity with languages like Java/C# is comparable to Python.

> Background compiling shouldn't be too hard to implement for an editor, I guess: run the compiler in background on the current module every other second (or only when a set of simple syntaxic conditions like parentheses/accolades matching are matched, conditions which can easily be checked by the editor itself), and display the error messages in semi real time on screen where they appear.

 Perhaps what could make that better is not only compiling as you type, but if you have unittests already written it will run and test against those giving you feedback instantly on what parts fail.

On Saturday, 12 May 2012 at 00:12:07 UTC, Timon Gehr wrote:
> On 05/12/2012 01:47 AM, Ali Çehreli wrote:
>> On 05/11/2012 02:45 PM, Timon Gehr wrote:
>>> On 05/11/2012 10:10 PM, Nick Sabalausky wrote:
>>>> I use 'in' all the time, and I never even think about it returning a
>>>> pointer. I just do:
>>>>
>>>> if(foo in bar)
>>>>
>>>> And it just works. So I don't see a particularly big problem here.
>>>>
>>>>
>>>
>>> Try this:
>>>
>>> bool fun(){ return foo in bar; }
>>
>> Isn't that an inconsistency in the language then? Are pointer values
>> implicitly convertible to bool or not?
>>
>> Ali
>
> if(condition) { ... }
>
> is equivalent to
>
> if(cast(bool)condition) { ... }
>
> i.e. this conversion is 'explicit'.

I'm not sure what you're talking about, there is no implicit conversion to bool.
dmd returns:

 bug.d(6): Error: cannot implicitly convert expression (foo in bar) of type int* to bool

With the cast(bool), everything works fine.

Am 12.05.2012 08:53, schrieb SomeDude:
> On Saturday, 12 May 2012 at 06:19:37 UTC, Jonathan M Davis wrote:
>>
>> I do have to say that I find it somewhat funny that this is your set of
>> requirements for an IDEA and yet "integrated debugger" is in the "some
>> 'nice
>> to have' features" section. Doesn't an IDE _have_ to have an integrated
>> debugger or it's only a code editor (since it lacks the whole
>> integrated part
>> of Integrated Development Environment).
>>
>> - Jonathan M Davis
>
>
> Indeed, and Timon forgot the best feature of IDEs for bytecode compilers
> imho: they compile in the background, so that errors are detected while
> you type. There is no annoying "write-correct" cycle as compile-time
> errors are shown in real time. That's a *huge* productivity boost.
> It's actually better than with interpreted or scripted languages,
> because once you've finished writing code, it will run ! Basically, with
> modern IDEs, the productivity with languages like Java/C# is comparable
> to Python.
>
> Background compiling shouldn't be too hard to implement for an editor, I
> guess: run the compiler in background on the current module every other
> second (or only when a set of simple syntaxic conditions like
> parentheses/accolades matching are matched, conditions which can easily
> be checked by the editor itself), and display the error messages in semi
> real time on screen where they appear.

Even Eclipse and VS do this, to certain extent, for C and C++.

Nowadays, my use of VIM and Emacs is relegated to quick edit of configuration files and small scripts.

--
Paulo

On 05/12/2012 12:26 AM, SomeDude wrote:
> On Saturday, 12 May 2012 at 00:12:07 UTC, Timon Gehr wrote:
>> On 05/12/2012 01:47 AM, Ali Çehreli wrote:
>>> On 05/11/2012 02:45 PM, Timon Gehr wrote:
>>>> On 05/11/2012 10:10 PM, Nick Sabalausky wrote:
>>>>> I use 'in' all the time, and I never even think about it returning a
>>>>> pointer. I just do:
>>>>>
>>>>> if(foo in bar)
>>>>>
>>>>> And it just works. So I don't see a particularly big problem here.
>>>>>
>>>>>
>>>>
>>>> Try this:
>>>>
>>>> bool fun(){ return foo in bar; }
>>>
>>> Isn't that an inconsistency in the language then? Are pointer values
>>> implicitly convertible to bool or not?
>>>
>>> Ali
>>
>> if(condition) { ... }
>>
>> is equivalent to
>>
>> if(cast(bool)condition) { ... }
>>
>> i.e. this conversion is 'explicit'.
>
> I'm not sure what you're talking about, there is no implicit conversion
> to bool.
> dmd returns:
>
> bug.d(6): Error: cannot implicitly convert expression (foo in bar) of
> type int* to bool
>
> With the cast(bool), everything works fine.

Which example are you testing with?

// With dmd 2.059, this compiles:
void main()
{
    int[int] aa;

    if (42 in aa) {
    }
}

// But this does not compile:
bool foo()
{
    int[int] aa;

    return 42 in aa;
}

Ali

-- 
D Programming Language Tutorial: http://ddili.org/ders/d.en/index.html

On 5/12/12 12:14 PM, Nick Sabalausky wrote:
> "DUE FOR TOMORROW"?!?
>
> That's NOT FUCKING ENGLISH! There IS NO "due for"!! Period!

Hilarious :-)

On 11 May 2012 21:28, Mehrdad <wfunction@hotmail.com> wrote:

> Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic
>

I'd like to think this were true, but the fact that 'ref' barely works makes this almost immediately false when trying to write any non-trivial program.

On Friday, 11 May 2012 at 19:15:54 UTC, Mehrdad wrote:
> Or e.g. C#'s "Any()" method tells you whether the collection is empty, whereas D's "any()" method takes in a predicate. I find C#'s *slightly* more intuitive.

I think, `Any` is one of the most unintuitive names out there.
The best association I have is aaaamon.dll from windows.

On 05/12/2012 10:13 AM, Manu wrote:
> On 11 May 2012 21:28, Mehrdad <wfunction@hotmail.com
> <mailto:wfunction@hotmail.com>> wrote:
>
>     Yes, I agree, but consider that D users should NOT have to work with
>     pointers to do something so basic
>
>
> I'd like to think this were true, but the fact that 'ref' barely works
> makes this almost immediately false when trying to write any non-trivial
> program.

It depends on the coding style.