May 12, 2012
"Ali Çehreli" <acehreli@yahoo.com> wrote in message news:jok8f1$k1r$1@digitalmars.com...
> 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?
>

Like Timon said, it's a feature of "if". I agree it's weird and confusing, though. At least I'm used to it :/


May 12, 2012
"SomeDude" <lovelydear@mailmetrash.com> wrote in message news:bgrwgspedjiajgoesxgq@forum.dlang.org...
>
> I remember g++ taking dozens of minutes on a SINGLE compilation unit on FreeFEM++, a very heavily templated project. Large C++ projects with lots of templates can take several hours to compile. So one has to be very careful with libraries like Boost on large projects, compilation times can explode.

Yea, it's like compiling GCC. You may as well go buy your groceries, run a few other errands, and go out for dinner. And I'm not even eggagerating. It's rediculous. (Maybe it's gotten better since I last tried though, but even so, it'd still tale a LOOOONG fucking time)

And even that's not even the worst. Mainstream videogames have been known to frequently take at least a full day. I'm not certain, but I seem to remember hearing about ones that took "days" - plural.

And then that leads to "incredibuild", build farms, blah, blah, blah, it's all a big fucking mess.

The longest I've ever had to wait for a D program to comple (DDMD) was about 1.5 to 2 minutes - and that was on a 32-bit single-core.


May 12, 2012
"Ary Manzana" <ary@esperanto.org.ar> wrote in message news:jokmnh$17fl$4@digitalmars.com...
>
> When I read "solve *for* x" I don't understand it. What do you mean "for x"? Like doing a favor to x?
>
> In Spanish we say "hallar el valor de x" which means "find the value of x"...
>
> I'm not a native English speaker so I don't know if "solve for x" sounds natural if you haven't done ecuations before... but for me it doesn't. :-P

You're right, it doesn't. "Find the value of x" would be *much* better. But that's just for beginners. Once they learn how to "Find the value of x", then it should be trivial to learn that "Solve for x" is "Another way to say...the same thing you're already doing."

Along similar lines, my 4th grade teacher used to assign homework and then say "But that's for tomorrow". So that evening I would do some *other* homework (if any) because that obviously *wasn't today's fucking homework*, right? Said *said* it was *tomorrow's*. Then the next day, she would bitch and moan that I didn't do the homework she had *said* was "for tomorrow". Her excuse: "Yea, it was 'Due for tomorrow'."

"DUE FOR TOMORROW"?!?

That's NOT FUCKING ENGLISH! There IS NO "due for"!! Period!

It's either "due {time and/or place}" or it's nothing! "Due" doesn't take any damn preposition, it takes an *object*! "Due for" is grammatical fucking gibberish! There's no such damn thing! So why would anyone ever say "for tomorrow" when they could just as easily say what they fucking mean: "due tomorrow".

It *would* have been somewhat excusable except...She was a native English speaker!

Stupid fucking bitch.



May 12, 2012
On 05/11/2012 05:12 PM, 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'.

WAT. That's an "implicit explicit" conversion, which I have never known existed! :p

Ali

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

May 12, 2012
Well, in most the big C++ projects I was involved in the
past, a full clean build would take at least an hour.

Am 12.05.2012 00:34, schrieb SomeDude:
> On Friday, 11 May 2012 at 21:46:55 UTC, Nick Sabalausky wrote:
>> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message
>> news:op.wd5o86s3eav7ka@steves-laptop...
>> On Fri, 11 May 2012 13:47:05 -0400, Alex Rønne Petersen
>> <xtzgzorex@gmail.com> wrote:
>>>>
>>>> Complicated language structure? Long compilation times?
>>>
>>> I can attest that on certain types of projects (i.e. template heavy),
>>> D's lightning fast compilation time goes out the window. It has
>>> improved greatly, but there are still some improvements that can be
>>> made.
>>>
>>> For instance, dcollections, which is about 10kloc takes 17 seconds to
>>> compile all the unit tests. It used to be well over a minute, till
>>> walter changed a linear lookup to a hash lookup on the symbol table.
>>> There's an outstanding issue which is similar still in bugzilla:
>>
>> Meh, that's still nothing compared to C++. The sample games included with
>> Marmalade and the Marm-based IwGame engine take *serveral* minutes to
>> compile - and those are just sample programs!
>>
>> Template-heavy projects don't throw D's lightning fast compilation
>> times out
>> the window, it just makes them less lightning-like. It's still an
>> order of
>> magnature faster than equivalent, or even merely similar, C++.
>
> I remember g++ taking dozens of minutes on a SINGLE compilation unit on
> FreeFEM++, a very heavily templated project. Large C++ projects with
> lots of templates can take several hours to compile. So one has to be
> very careful with libraries like Boost on large projects, compilation
> times can explode.

May 12, 2012
Your 'nice to have' features are for my type of
work 'must have' features, otherwise I could as
well just use Notepad++.

Having used GUI environments since the early MS-DOS
days, I don't have any issue with my mouse friend. :)

--
Paulo

Am 12.05.2012 02:00, schrieb Timon Gehr:
> On 05/11/2012 07:39 PM, Paulo Pinto wrote:
>>
>> The author of a D based PSP emulator just rewrote
>> the emulator in C#, after being disappointed with D.
>>
>> https://github.com/soywiz/cspspemu
>>
>> The reasons are listed here,
>>
>> https://github.com/soywiz/cspspemu#created-after-4-tries
>>
>> --
>> Paulo
>
> Well, those are not reasons for me.
>
>  > The lack of a good IDE,
>
> Properties of a 'good IDE', as I see it:
>
> some essential properties:
> - starts up instantaneously
> - uses the screen space efficiently
> - supports editing text efficiently
> - accepts keyboard input as given by the user.
> - reasonable support for auto-indentation
> - supports searching the code for some text efficiently
> - keeps all code _readable_, especially the one that has been written
> recently
> - pattern recognition based code completion
>
> - ... by default!
>
> some 'nice to have' properties:
> - code analysis based code completion
> - navigate-to-declaration
> - for those languages that require it: automatic generation of boilerplate.
> - integrated debugger
> - useful refactoring tools
> - visualization of compilation errors (but please don't nag me)
> - actual support for detecting semantic errors as they happen (extremely
> difficult to do properly)
> - any other argument that is commonly used to advertise IDEs
>
> - ... _responsive_ on halfway recent hardware!
>
> some anti-features:
> - splash screen
> - cannot run code if there is no 'project/solution file'
> - sometimes messes up those files
> - build fails - restart IDE - build works
> - fancy GUI
> - requires pointing device
> - accidental hit of obscure keyboard combination ...
> => permanent, extremely annoying configuration change
> => no way to tell what happened
> => no undo operation
> - termination of the debugged program kills the output console
>
>
> As long as IDEs fail to satisfy every single point in the 'essential'
> category and strive to have all of the stated anti-features, they don't
> have much value for me anyway.
>
>  > the complicated structure of the D language,
>
> Cannot really comment on that, I think getting work done in D is simple,
> and with DMD, just slightly harder than that.
>
>  > the horrible compilation times,
>
> wat? The so-fast-I-could-not-grab-a-coffee-during-compilation kind of
> horrible? Otherwise he might have hit a bug there.
>
>  > caused that it taked too much time for everything, and made it
>  > impossible to refactoring the code without days or weeks of work.
>
> I'd have to know what kind of refactorings he carried out to be able to
> comment on this.

May 12, 2012
"Timon Gehr" <timon.gehr@gmx.ch> wrote in message news:jok96k$l7t$1@digitalmars.com...
>
> Properties of a 'good IDE', as I see it:
>
> some essential properties:
> - starts up instantaneously
> - uses the screen space efficiently
> - supports editing text efficiently
> - accepts keyboard input as given by the user.
> - reasonable support for auto-indentation
> - supports searching the code for some text efficiently
> - keeps all code _readable_, especially the one that has been written
> recently
> - pattern recognition based code completion
>
> - ... by default!
>
> some 'nice to have' properties:
> - code analysis based code completion
> - navigate-to-declaration
> - for those languages that require it: automatic generation of
> boilerplate.
> - integrated debugger
> - useful refactoring tools
> - visualization of compilation errors (but please don't nag me)
> - actual support for detecting semantic errors as they happen (extremely
> difficult to do properly)
> - any other argument that is commonly used to advertise IDEs
>
> - ... _responsive_ on halfway recent hardware!
>
> some anti-features:
> - splash screen
> - cannot run code if there is no 'project/solution file'
> - sometimes messes up those files
> - build fails - restart IDE - build works
> - fancy GUI
> - requires pointing device
> - accidental hit of obscure keyboard combination ...
>   => permanent, extremely annoying configuration change
>   => no way to tell what happened
>   => no undo operation
> - termination of the debugged program kills the output console
>
>
> As long as IDEs fail to satisfy every single point in the 'essential' category and strive to have all of the stated anti-features, they don't have much value for me anyway.
>

Hear hear!

Although I'd swap the positions of "pattern recognition based code completion" and "_responsive_ on halfway recent hardware!". In fact, I'd put "responsive" at the top of the "essential" list.


May 12, 2012
awkward is which, backwards read things makes posting top but, ass an be to Not.

"Paulo Pinto" <pjmlp@progtools.org> wrote in message news:joku8g$1kd9$1@digitalmars.com...
> Well, in most the big C++ projects I was involved in the past, a full clean build would take at least an hour.
>
> Am 12.05.2012 00:34, schrieb SomeDude:
>> On Friday, 11 May 2012 at 21:46:55 UTC, Nick Sabalausky wrote:
>>> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message
>>> news:op.wd5o86s3eav7ka@steves-laptop...
>>> On Fri, 11 May 2012 13:47:05 -0400, Alex Rønne Petersen
>>> <xtzgzorex@gmail.com> wrote:
>>>>>
>>>>> Complicated language structure? Long compilation times?
>>>>
>>>> I can attest that on certain types of projects (i.e. template heavy), D's lightning fast compilation time goes out the window. It has improved greatly, but there are still some improvements that can be made.
>>>>
>>>> For instance, dcollections, which is about 10kloc takes 17 seconds to compile all the unit tests. It used to be well over a minute, till walter changed a linear lookup to a hash lookup on the symbol table. There's an outstanding issue which is similar still in bugzilla:
>>>
>>> Meh, that's still nothing compared to C++. The sample games included
>>> with
>>> Marmalade and the Marm-based IwGame engine take *serveral* minutes to
>>> compile - and those are just sample programs!
>>>
>>> Template-heavy projects don't throw D's lightning fast compilation
>>> times out
>>> the window, it just makes them less lightning-like. It's still an
>>> order of
>>> magnature faster than equivalent, or even merely similar, C++.
>>
>> I remember g++ taking dozens of minutes on a SINGLE compilation unit on FreeFEM++, a very heavily templated project. Large C++ projects with lots of templates can take several hours to compile. So one has to be very careful with libraries like Boost on large projects, compilation times can explode.
> 


May 12, 2012
On Saturday, May 12, 2012 02:00:19 Timon Gehr wrote:
> On 05/11/2012 07:39 PM, Paulo Pinto wrote:
> > The author of a D based PSP emulator just rewrote
> > the emulator in C#, after being disappointed with D.
> > 
> > https://github.com/soywiz/cspspemu
> > 
> > The reasons are listed here,
> > 
> > https://github.com/soywiz/cspspemu#created-after-4-tries
> > 
> > --
> > Paulo
> 
> Well, those are not reasons for me.
> 
>  > The lack of a good IDE,
> 
> Properties of a 'good IDE', as I see it:
> 
> some essential properties:
> - starts up instantaneously
> - uses the screen space efficiently
> - supports editing text efficiently
> - accepts keyboard input as given by the user.
> - reasonable support for auto-indentation
> - supports searching the code for some text efficiently
> - keeps all code _readable_, especially the one that has been written
> recently
> - pattern recognition based code completion
> 
> - ... by default!
> 
> some 'nice to have' properties:
> - code analysis based code completion
> - navigate-to-declaration
> - for those languages that require it: automatic generation of boilerplate.
> - integrated debugger
> - useful refactoring tools
> - visualization of compilation errors (but please don't nag me)
> - actual support for detecting semantic errors as they happen (extremely
> difficult to do properly)
> - any other argument that is commonly used to advertise IDEs
> 
> - ... _responsive_ on halfway recent hardware!
> 
> some anti-features:
> - splash screen
> - cannot run code if there is no 'project/solution file'
> - sometimes messes up those files
> - build fails - restart IDE - build works
> - fancy GUI
> - requires pointing device
> - accidental hit of obscure keyboard combination ...
>    => permanent, extremely annoying configuration change
>    => no way to tell what happened
>    => no undo operation
> - termination of the debugged program kills the output console
> 
> 
> As long as IDEs fail to satisfy every single point in the 'essential' category and strive to have all of the stated anti-features, they don't have much value for me anyway.
> 
>  > the complicated structure of the D language,
> 
> Cannot really comment on that, I think getting work done in D is simple, and with DMD, just slightly harder than that.
> 
>  > the horrible compilation times,
> 
> wat? The so-fast-I-could-not-grab-a-coffee-during-compilation kind of horrible? Otherwise he might have hit a bug there.
> 
>  > caused that it taked too much time for everything, and made it
>  > impossible to refactoring the code without days or weeks of work.
> 
> I'd have to know what kind of refactorings he carried out to be able to comment on this.

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
May 12, 2012
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.