Hacker News new | comments | show | ask | jobs | submit login
Ask HN: What do you do while your code compiles?
16 points by rsp1984 180 days ago | hide | past | web | 26 comments | favorite



Figure out why it's taking so long to compile and what can be done to either shorten it or automate the build and testing process so I'm not waiting for it anymore.

Move things to unit tests with smaller compilation units (so I can compile foo.cpp and a handful of other dependencies, but not the full system) so, other than for deployment or integration testing, my feedback loop is much shorter.

Or if it can't be made shorter, work on another project or read something (presently non-practical/actionable, Weapons of Math Destruction, but typically more practically technically oriented).


A project I'm working on now relies on a third party platform that takes fairly long to reload after changes. I've managed to run some parts standalone which has been super helpful but in general there's a lot of waiting.

In the meantime I do small and very easy coding exercises.


Sword fight with my co-worker!


For the uninitiated: https://xkcd.com/303/


I guess that's one of the advantages of interpreted languages over compiled languages.

I spend no time waiting for compilation to happen (ruby). I used to spend a lot in my previous job (C#), where the time was utilised (wasted) in going through blogs/articles.


(NB: Not a criticism of interpreted languages, they add a lot of value)

While long compilation times are incredibly annoying, compilation offers a first pass test on code: Is this code syntactically correct? Do (at least some of) the semantics make sense?

With an interpreted language, you may be able to test for syntactic correctness with a simple scan over the language, but you're approaching compilation at that point. More likely, syntactic correctness is verified by a test suite that's sufficient to provide 100% code coverage (which can be hard to build and maintain).

It's also harder to know if a reference to foo is valid at any point, until it's executed. Which is where the semantic validity and verification of compilation comes in handy. A tool which can do this for your interpreted language is most of the way to being a compiler, it's simply lacking the translation step.

The nice thing with interpreted languages is that you could put off a lot of this verification/validation, similar to the distinction between dynamic and static typing, until you actually need it. The debate is when you need it and how much value is added by putting it at the start. But languages like go and incremental compilation being adopted by more compiler/toolchain developers is at least cutting down on the time to reduce the time spent idling (as a developer) in the feedback loop.


Yeah, I laugh every time someone says interpreted languages remove the "compile time" step. Once you decide to start working at scale you have to come back and hack in all the static checks the compiler would have given you for free and in my experience those tend to be 10x slower. I know running the python linter + test suite on our basic enterprise CRUD takes longer than all but the biggest C++ projects I've ever seen.


In general I find that C# builds are fairly quick. Nonetheless Ruby is a pleasure to work with.

As for other interpreted languages, JavaScript is a mixed bag. The Webpack/Babel stack can be smooth if hot reloading and such are set up well and work correctly, but things can quickly turn sour when other backend languages are involved with server side rendering and such.


I see you've never worked with mister "creates a project for every class" or any of his friends. C# compiles quickly, but MS build is very slow and it's noticeable when there are a lot of projects.

Just for fun, try compile with csc directly one day, it's an order of magnitude (at least) faster than with msbuild.


Perhaps I'll try your suggestion and compare make against msbuild...


It's much faster (http://flukus.github.io/2016/11/30/2016_11_30_Rediscovering-...), so is nant or just about any build tool. The problem is visual studio (and other developers) only know about .csproj files.


You're still spending time compiling, it's just spread out at run time. Often with dynamic languages you're pushing the compile time down to the users.


Android Studio users-----> Modify the HEAP_SIZE in the gradle file. It will shorten build times by a factor of 3-4.


Carry on as usual.

My code gets offloaded to a build agent, so I don't have to worry about it.


Write tests, Run the "compile" & "test" in the background. Than you can continue working on your tasks (even other tasks while they are working).

Even better, just have a CI that will run it not on your environment.


The largest personal projects i worked on were in the range of 100k lines, which takes 3-4 seconds to fully compile.

So, i dunno. Stare at the screen?


If I'm feeling like being productive, switch to another instance of my dev environment working on a different branch of the source code, in which I'm working on a different problem entirely. It's just two (or more) branches being developed on the same machine in two instance sets of my dev env, side by side.

Usually, though, I do that thing where you open your mouth in different shapes and smack the sides of your face to make noises. I'm trying to play "The Entertainer".


I read through my code to debug it.


Since my computer's working but I am not, I do something NSFW.


Browse HN, d'uh!


Being here in HN!


This.


Minesweeper


Any opportunity to post an XKCD comic...

https://xkcd.com/303/


i take a nap


make -j8




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: