4 ms·
It’s useful to realize Edit and Continue is not for professional programmers, and the qualities we’d most want are not appropriate to every problem. The horrib
by SteveJS 8y ago
It’s useful to realize Edit and Continue is not for professional programmers, and the qualities we’d most want are not appropriate to every problem.
The horrible code you inherited as the programmer brought on is because some non-professional domain expert made a ‘hairball of extreme utility’ that unlocked product-market fit on back of a mess of experiments.
VB’s persona was ‘Mort’, literally a scientist trying to get an answer, or a business person trying to solve a problem, not a programmer trying to build a system. It’s 99 hairballs of no utility and 1 that wouldn’t have been built otherwise because no one knew it was useful until it exists.
Some categories of UI experience problems lend themselves to simply making the trial loop as quick as possible.
It is also true that understanding a dataset has an initial experimental component. No amount of thinking about code is going to tell you the dataset has a fatal flaw, until you discover it.
- chacham15 8y agoIn the old adage "there are two difficult problems in programming: caching, naming things, and off by one errors" edit and continue drastically helps with the last one (even for "professional programmers"). I loved that feature in C# while I was working at MS, it saved me so much time from checking that all my indexing was correct.
- pjmlp 8y ago> Edit and Continue is not for professional programmers Then I prefer to be called an amateur, as I really like using that feature, instead of loosing my debugging context and starting everything from scratch, some times spending several minutes trying to replicate the issue that landed me there.
- eropple 8y agoNot sure if I'm reading incorrectly into the tone of your response, but, for context, 'SteveJS was a developer on that feature, as he says elsewhere in the comment tree.
- pjmlp 8y agoI sure noticed that, I just think when we work as professional programmers are worthy of having productivity features like "Edit and Continue". I don't have to "enjoy" doing everything the hard way, just for the sake of being professional. UI/UX and language features designed for productivity, help everyone, not only newbies. What I understood from SteveJS's remark, is that although he took part designing that feature, he doesn't share this opinion. If not, I would be gladly corrected.
- SteveJS 8y agoI think it is more than fine to use Edit and Continue as a professional. I’m acknowledging the trade offs and making an argument meant to be heard by a resistant audience that is likely to be the ones making the tool. E&C is a useful tool, just like a debugger in general is a useful tool, despite early enthusiasm for unit testing having people claim you shouldn’t use debuggers anymore, but instead write unit tests to debug every issue. E&C can be misused. If i was using C# i would take generics over edit and continue if I could only have one, but I definitely prefer to have both. The theory behind using personas is you get a better tool or solution by highly focusing on a concrete user rather than spread around a bunch of features across every possible customer. What i expressed is what is necessary to ‘get through’ to someone who hasn’t read a book like ‘the inmates are running the asylum’. That was true of many in Devdiv back at that time. UX is now recognized more firmly as a separable highly valued skill. If you read and understand the persona and still think ‘i’m a programmer, this is a dev tool, my opinion is more import than what the persona would want .. that is the audience for the above. I think that is what is present in the comment to which i was replying, so i was attempting to put it in those terms. I do believe it is helpful to understand who a tool is designed for to see why it works as it does. Edit and continue when done well is incredibly ‘safe’. It does what you expect every single time, even if you don’t know how it is doing it. A good example where there is a hard choice is changing a linq statement. To make E&C in a dev tool that holds true to ‘what is on the page is what runs’ you need to violate aspects of how deferred execution works. If the closure was already captured are all existing instances of them going back to the source as it is on the page now or the source as it was when when captured? I have a strong opinion that it should be the source on the page now to build a good E&C, but that choice is detrimental to learning what is happening with any type of deferred execution. The cost of implementation for my opinion is also probably two or more orders of magnitude in effort. I also think ‘non-professionals’ should be able to program and get to something that works. Particularly in people who write developer tools the bigger chore is gaining empathy for people who deserve to program, but simply aren’t making infrastructure. My reply is counterproductive in trying to model proper empathy so thank you for calling that out.
- fantispug 8y agoThere are lots of interesting problems with interacting with external underdocumented systems. I find edit and continue really useful for making something worm with these. Are these out of the reach of "professional programmers"? Can they only work on systems with fully specified models, with exacting requirements?
- SteveJS 8y agoI agree with you and poorly worded this for a larger audience that doesn’t have the full context of design decisions on the feature. As an example ... for a ‘professional programmer’ there is an argument that allowing E&C to work if you edit in vim or emails is a feature. For what we needed to accomplish that is an anti-feature.
- SteveJS 8y agoI should probably not care, but i do: Emacs, not emails. I should also not write these on an iphone.