3 ms·
Hey Michael, been a fan since reading 'Legacy Code'. Do you believe that refactoring a large APL codebase would be inherently easier than something like, a lar
by nickpeterson 10y ago
Hey Michael, been a fan since reading 'Legacy Code'.
Do you believe that refactoring a large APL codebase would be inherently easier than something like, a large legacy C++ codebase?
What is the relative complexity of comparing, say 1000 lines of APL to 10K lines of C++?
I remember reading an interview between Arthur Whitney and Bryan Cantrill where they mentioned something about recognizing idioms in the dense code much more easily in K than in something like C because it took so many less characters. Do you see any sort of refactoring advantage to that?
I've also recently seen work on the Co-dfns compiler in APL where the author mentioned that APL allowed him to easily refactor compared to traditional codebase, and looking at the github library, there is something like 3 million edited lines over the span of several years in a codebase this is a few thousand lines of code. I find this fascinating because my hope is to eventually start a small software business and I think reducing complexity in the number one priority in order to make it sustainable in the small (the goal isn't to have a team of 50 developers).
Thoughts?
- michaelfeathers 10y agoNick, I think that the primary win is referential transparency. APL idioms raise the level on that base. The tradeoff, though, is the same as we have for functional but further along the road: if you develop a codebase that doesn't use common idioms it's harder to hire people to work in it. I think array languages, or at least their operation set and idioms, will move into the mainstream in the same way that functional is, but it will take time. Sustainability for your business would be more an issue of hiring and retaining talent. Reach out if you want to talk about this more: @mfeathers