> My point was that super fancy IDEs and plain old text editors alike could reuse the same tooling and not have to reimplement things like language parsing, analysis, and refactoring tooling.
Parsing and analysis are great examples: if you accept that batch is the best that can be done, they are completely reusable in lots of different contexts. As soon as you want something interactive, standardization and integration become much more tricky (I know directly from experience in writing interactive parsing and analysis tools).
> Also if you refuse, on account of bias, to understand why people might find such a design (command-line application invoked from different programming environments to augment functionality) then you are damning yourself to be ignorant of how other people think and work.
My early 90s self completely agrees with you. My current self is much more interested in non-batch interactive tooling, the mainstream is also.
> Maybe that's not an ethos at Microsoft or MSR, but it is in the various open source communities I've been in.
Along with much of the OO PL community, please don't forget (though we divide into static easy-to-tool languages and dynamic hard-to-tool languages).
> You clearly have not used Emacs or any of the Haskell tooling I use.
I was a heavy emacs user in the 90s (from about 92 to 2003 or so). It was a fine text editor, I would have never called it an IDE though.
> My Emacs environment of today would be utterly alien to myself-10-years-ago. Or even 3-5 years ago. Or even 2 years ago. A lot of evolution can happen when you've been improving the same tooling over and over for multiple decades.
Please educate me. How about your own workflow: does your emacs IDE provide code assist (I think Haskell Eclipse does right?), does it provide a nice debugger?
> You should really try immersing yourself in how Emacs users work these days, you really have no idea at all.
I used Emacs for 10 years in the 90s, early 00s, I don't miss it at all. Language-aware editing with code completion has been a huge win in PL and I don't see us going back. But these kinds of tools are complicated and not as interoperable as the old text pipe-based batch tooling was in the past.
Parsing and analysis are great examples: if you accept that batch is the best that can be done, they are completely reusable in lots of different contexts. As soon as you want something interactive, standardization and integration become much more tricky (I know directly from experience in writing interactive parsing and analysis tools).
> Also if you refuse, on account of bias, to understand why people might find such a design (command-line application invoked from different programming environments to augment functionality) then you are damning yourself to be ignorant of how other people think and work.
My early 90s self completely agrees with you. My current self is much more interested in non-batch interactive tooling, the mainstream is also.
> Maybe that's not an ethos at Microsoft or MSR, but it is in the various open source communities I've been in.
Along with much of the OO PL community, please don't forget (though we divide into static easy-to-tool languages and dynamic hard-to-tool languages).
> You clearly have not used Emacs or any of the Haskell tooling I use.
I was a heavy emacs user in the 90s (from about 92 to 2003 or so). It was a fine text editor, I would have never called it an IDE though.
> My Emacs environment of today would be utterly alien to myself-10-years-ago. Or even 3-5 years ago. Or even 2 years ago. A lot of evolution can happen when you've been improving the same tooling over and over for multiple decades.
Please educate me. How about your own workflow: does your emacs IDE provide code assist (I think Haskell Eclipse does right?), does it provide a nice debugger?
> You should really try immersing yourself in how Emacs users work these days, you really have no idea at all.
I used Emacs for 10 years in the 90s, early 00s, I don't miss it at all. Language-aware editing with code completion has been a huge win in PL and I don't see us going back. But these kinds of tools are complicated and not as interoperable as the old text pipe-based batch tooling was in the past.