What was your trajectory along the correct-by-design vs. debugger-first axis?
Posted by ImYoric@reddit | ExperiencedDevs | View on Reddit | 8 comments
One of the ways I like to describe programming languages and technologies is debugger-first vs. correct-by-design. A perfect example is Go (designed to let you write your code quickly, then write tests and hop into your debugger) vs. Rust (designed to encourage you to clarify your invariants as types, then hopefully not need a debugger at all).
With experience, many of us come to the conclusion that we can use any tool to fulfill the requirement, but we also have preferences and realize that some tools align better with how we think.
So I'm curious: how has experience influenced your preferences on this debug-first / correct-by-design axis?
I, personally, have started debugger-first, took a sharp turn towards correct-by-design as soon as I discovered it, then progressively mellowed out towards debugger-first, to progressively conclude that I can work with either but still prefer correct-by-design.
What about you?
jedilowe@reddit
I grew up in Ada which may be the Queen of strong declarative languages. It was said it may take you 45 minutes to get it to compile but it was working 5 minutes later. I think the reason folks don't prefer these languages is it forces your to plan out your solution early and know a lot of language details before you get that first run. Running is a sense of progress that engages our intuitive brain right away. Particularly for newer programmers it avoids them feeling incapable.
It isn't the language's fault so much as how we teach it. The old days (and sometimes still) is full of classes that have you sit through syntax and semantics lectures assuming you will memorize all those rules and be off. We don't really learn that way. Thus the perceived ease at learning Python or Javascript. It swaps progress for understanding, which is not inherently bad, so long as you come back to ensure you understand what just happened. Compilers are mean because they make you need to consciously understand before it does anything, even run and break, or use AI, stack overflow, or your friend to get something working you may not understand yet.
I think that early experience taunts perception and lingers!
ImYoric@reddit (OP)
Generally, I agree, but I'm a counter-example.
I started with BASIC, then moved to Pascal, C, x86 asm, then I entered university and discovered OCaml, which was a revelation. Then I was taught Java, which was a bit weird, as I had already released a commercial application in that language.
I'm never going to program again in BASIC and probably not much in Pascal, C or x86. If you offer me a job based on a programming language with the expressivity of OCaml, though? I'll be tempted to take it.
Ab_Initio_416@reddit
I second that. Once your mind has been bent into the proper shape by Ada, every other approach (of which Python, JavaScript, and, back in the day, BASIC, are bright shining examples) seems almost suicidal.
elprophet@reddit
This isn't a dichotomy? But if we're insisting on treating it as such, I'd make it a triangle. Design, automated test, debug. I find myself right in the middle; or, going clockwise. Start with the design, capturing it in types. Write a test and implementation. In rust, maybe 20% of the time I made a mistake in the design that shows up in something funky in the test, and attaching the debugger shows very quickly what the design should have been. From there, iterate clockwise.
ImYoric@reddit (OP)
I think it's a dichotomy as of this day, because I don't know of any language optimized for both. One could perhaps argue TypeScript or OCaml?
daron_@reddit
Since I moved to scala I even forgot that debugger exists.
ImYoric@reddit (OP)
Fun fact: About two years ago, I had a job interview at Canonical for a Rust-based position. One of their exercises had me reimplement a GNU tool, which involved a FSM to handle all the combinations of command-line options. After a few hours of trying to figure out what went wrong with my code, I tried to start my debugger, only to realize that I had never bothered installing a Rust debugger on that machine in the first place. Took me about 10 minutes to find out the FSM error. Since then, I haven't used a Rust debugger.
AccomplishedGift7840@reddit
You should aim to make your design as close to correct as possible without debugging. Long term this gives you a better understanding of your code base, forces you to think about edge cases, and gives you more confidence in your design since you will have a clear mental model of how it should work. If you run into issues during testing feel free to pull out your debugger then - but ensure you update your mental models to avoid making the same mistake again.
Measure twice, cut once!