3 ms·
> […] e.g. because understanding the code practically requires jump-to-definition. Wait… so the code you write makes me magically able to know the record field
by runeks 5y ago
> […] e.g. because understanding the code practically requires jump-to-definition.
Wait… so the code you write makes me magically able to know the record field names of your data types without looking at their definition?
Your statement may be true if it’s talking only about the core logic of an application, but when we get to the part that interfaces with the rest of the world, things always get somewhat messy. An IDE is a huge help here.
I mean, sure, you may be able to memorize the arguments that “readCreateProcess” takes (https://www.stackage.org/haddock/lts-18.19/process-1.6.13.2/System-Process.html#t:CreateProcess https://www.stackage.org/haddock/lts-18.19/process-1.6.13.2/...), but sometimes it’s really handy to have an IDE help you with this.
- wyager 5y ago> I mean, sure, you may be able to memorize the arguments that “readCreateProcess” takes How frequently would you use and subsequently forget how to use this function? If I use a library function like this, I most likely write it exactly once in my codebase. The cognitive overhead of going on hackage one time per project-library is very small. I agree an IDE makes you marginally faster in this case - just pointing out that this marginal benefit need not be significant.
- whateveracct 5y agoKnowing record field names without looking at the definition isn't a critical path of coding worth optimizing. Amdahl's Law applies to code editing too. Hoogle and even a simple "rg -A10 'data TheRecordName'" work perfectly fine. No reason to shave seconds with an entirely different tool. For readCreateProcess, I just..look at the Haddocks while I program :)