3 ms·
If only it could do this… f :: YourTestInput -> CorrectAndPerformantAdventOfCodeSolution f = _ --- Seriously though, even after writing Haskell primari
by yakshaving_jgt 5y ago
If only it could do this…
f :: YourTestInput -> CorrectAndPerformantAdventOfCodeSolution
f = _
---
Seriously though, even after writing Haskell primarily for years, I've never done hole-driven development and I'm still not sure what I'm missing. I tried once — granted, that was a long time ago — but I didn't get it. This post[0] suggests I'm not alone in thinking this.
I'm glad Wingman exists and I think branding it nicely like this is the right thing to do, but I think I need to see more concrete examples to really see the magic. Probably something like Gary Bernhardt's Destroy All Software screencast series. It's one thing for someone to tell you that vim is fast, but it's another thing entirely watching the tool come to life in the hands of an expert. I imagine it's a similar thing for Wingman — I still have this mental block where I'm picturing the tool conjuring up an undefined for each hole, which is exactly what the documentation suggests the tool doesn't do. I would love to see someone use Wingman to quickly hammer out an Advent of Code puzzle, or even something more real-world like an Esqueleto query (but is that even possible?)
[0]: https://bitemyapp.com/blog/please-stop-using-typed-holes/ https://bitemyapp.com/blog/please-stop-using-typed-holes/
- sa1 5y agoThe post talks more about usability issues rather than any theoretical issues. There are more fundamental objections to typed holes - but Wingman is kind of the answer to those concerns - with typed holes you're filling in types from the expressions, with Wingman you're doing pretty much the opposite - synthesizing programs from the type. Now there might be usability issues with Wingman as well, but it represents a different direction - more suitable for type-driven development.