Building C++ modules

Exil Exil at gmall.com
Thu Aug 15 20:09:33 UTC 2019


On Thursday, 15 August 2019 at 19:30:44 UTC, H. S. Teoh wrote:
> On Thu, Aug 15, 2019 at 06:53:53PM +0000, Exil via 
> Digitalmars-d wrote:
>> On Thursday, 15 August 2019 at 15:00:43 UTC, Atila Neves wrote:
>> > On Thursday, 15 August 2019 at 00:45:06 UTC, matheus wrote:
> [...]
>> > > I can't see a great difference between 1 sec vs 100 ms 
>> > > "while working".
>> > 
>> > I can. It makes me want to punch the wall.
>> 
>> The difference is noticable but really not to that point. What 
>> do you do when you have to wait 30 mins? I guess some people 
>> are just less trigger happy and patient than others.
>
> Keep in mind, you're talking to a long-time D user who has 
> gotten used to lightning-fast compile speeds.
>
> In the old days, when I was still using C/C++ by choice, 
> compilation breaks were an accepted norm. It's just the thing 
> that you do after X minutes of coding, and it's known that it's 
> a slow process.  You just take a coffee break, a washroom 
> break, browse the internet, or whatever, and then resume 
> working when the build is done.  It's just the way things were.
>  Working continuously was unimaginable, and you never missed it 
> because you never experienced such a thing before.
>
> Now that I'm used to D compilation speeds, I find anything 
> longer than 3-5 seconds totally intolerable.  With a <1-2 
> second turnaround time, I find myself in a completely different 
> mode of thought -- I can try out experimental bits of code and 
> get almost instant feedback on the effect it has on the 
> program.  Within a short 5-minute span I can have already 
> tested out 20-25 different implementation ideas and zeroed in 
> on the best one.  Your train of thought can actually proceed 
> uninterrupted, and your coding process gets elevated to a new 
> level of intense focus and productivity.  Whereas back in the 
> day of C/C++ slow compiles, such a process would have taken 
> hours, if not days, and development speed would be 
> tortoise-slow.
>
> Once you've tasted this level of coding focus and productivity, 
> going back to the old way is simply unpalatable.  You find 
> yourself losing your train of thought, distracted by other 
> things during compilation and need to spend (i.e., waste) some 
> time to refocus afterwards to get back in the groove.  
> Productivity is abysmal, relatively speaking.  Too much time 
> wasted redirecting your attention from various distractions 
> back to the problem at hand.  Like having to constantly switch 
> your hand from the keyboard to the mouse instead of a 
> keyboard-driven UI where your fingers are right there and ready 
> to go, having a slow compile just pulls you back an order of 
> magnitude in productivity. (I used to use a mouse-driven GUI 
> for decades -- now I use a 99.99% keyboard-only interface with 
> no distracting frills, and I can tell you productivity has 
> skyrocketed to a whole 'nother level never before imaginable.)
>

See my experience with D is that it still takes over a minute to 
compile my relatively small program. A minute isn't really fast. 
Even worse if you use -O with DMD (I stopped it after 20 mins). D 
really isn't a fast language, or rather the only frontend is 
really really slow especially for CTFE.

> [...]
>> > No, it's not that. It's that it interrupts my train of 
>> > thought. I can work faster if I get faster feedback.
>> 
>> Wouldn't compiler errors do the same.thing, if not worse? Not 
>> only do they interrupt your train of thought they require you 
>> to think about something else entirely. What do you do when 
>> you get a compiler error?
>
> Compile errors that appear instantly means you're still focused 
> and can immediately get on the task of identifying the problem 
> code.  Compile errors that appear after X seconds means you 
> spend an additional Y seconds refocusing your brain on the 
> programming problem at hand, and *then* get on the task of 
> identifying the problem code, thus slowing you down by (X+Y+Z) 
> seconds rather than just spending the Z seconds finding the 
> problem.

Now you have to read and interpret something else entirely. Your 
not waiting 200 ms to continue your line of thought, your wasting 
minutes if not more if you continue to get compiler errors. 
Especially one of those template errors that are difficult to 
interpret. It's the same problem but x10 worse. Your not the 
person I was replying to, so sure maybe its something else to 
you, but the person I was replying to made it pretty clear what 
it was for them.

Just curious, how fast do you type? If it's about wasting time 
for you I imagine you must type pretty quickly then :P.

>
> [...]
>> > > Now imagine waiting ~40 seconds just to open any solution 
>> > > on Visual Studio (Mostly used for projects where I work), 
>> > > on a NOT so old machine, and like 4 ~ 10 seconds every 
>> > > time you run an app while debugging.
>> > > 
>> > > That's is the meaning of pain.
>
> And that is why I don't bother with IDEs, or anything, really, 
> that has needless eye-candy and frills I don't use. Give me vim 
> over an SSH remote connection, and I can be 100% productive 
> anywhere.  A GUI that requires umpteen GBs of RAM and 40s to 
> start?  Not even on my radar.

Haven't use an IDE in a long time either. The only one that's 
ever really been of note is Visual Studio, and their release 
cycles or so slow. They don't really add anything to the IDE 
anymore. It's mostly just the compiler they are updating. 
Compared to other Editors that release a new build every month. 
There's only really a handful of features that make IDEs useful 
for productivity, most editors have a few of those features, even 
less has most of them.

>
>> > I can take waiting 40s once a day. I can't take waiting >1s 
>> > every time I build though.
>> 
>> Feel like you don't have to wait. You can continue to do other 
>> things while it is compiling. I suppose some people aren't as 
>> good at multi tasking.
>
> It's not an issue of multitasking.  It's an issue of wasting 
> time because you have to keep switching mental gears.  
> Context-switching is not free, even in the human brain. :-D  
> (I'd even say *especially* in the human brain -- CPU context 
> switches are basically undetectable as far as human perception 
> is concerned, but switching mental gears definitely takes a 
> much more significant amount of time.)
>
>
> T

You've just described multi tasking. If you have trouble keeping 
multiple things in your head at once and it takes you a long time 
to recall where you were in two unrelated tasks that you were 
doing relatively closely together. Then you aren't very good at 
multi-tasking.


More information about the Digitalmars-d mailing list