I guess because I fall into the first category. I use the same text editor for a wide spectrum of languages that I fiddle with, and feel like the time spent by core language devs on an IDE is better spent on the language itself.
People who work on IDEs / text editors can work on tooling and integrating with languages as they become popular (or before), but developing an IDE from scratch with a language and continuing to support it seems like a waste of time when I personally would never really consider using it and its chances of being a decent text editor are slim.
Which is all not to say that I definitely do like coordination between the two camps.
So I guess I made two arguments, one that I like what I use and prefer to keep using it over having some new perhaps questionable tool, and two that it's a non-trivial amount of work that has already been done, which I feel is better spent by other external parties rather than core devs.
The PL designer can always customize an editor off the shelf (e.g., Eclipse), and this is what happens mostly. However, I find myself implementing an editor now simply because the idea I want to show off requires many features current editors don't support, like projecting code onto program execution rather than have separate windows for code and inspecting run-time state.
He just explained it with the semicolon in Python example. The moment when language designer starts making compromise with the language just because it would be easier to implement an _official_ editor or IDE is the moment that language is effectively stopping to advance.
The history has shown that languages developed without concerns of IDE were the most successful or the most influential languages.
Whoa. That is a crazy assertion. First, not many languages have been designed with the IDE as a concern, and second, all the industrial PL design teams that I know of definitely work closely with their IDE team to ensure harmony between tooling and language. I'm a bit more radical, all of my recent languages have been heavily tied to the IDE, to the point that there is know real boundary between the implementation of the compiler and IDE.
Working closely with the IDE team is a good thing, but core language developers focusing on the IDE and the language in the same time can indeed lead to some compromises that hurt the language.
That's an interesting contention. Any chance you could share some examples?
I don't doubt you, but I do wonder at your benchmarks for success and influence.
FWIW, I use Emacs, which is an editor with a programming language embedded. So does that make me a language maven (as I like emacs lisp and playing with it) or a tool maven, because I am learning about the tool I use to edit code (and almost everything else textual)?
I don't agree that it stops the language from advancing. What is your definition of advancement here, exactly? Lots of successful, productive languages pay attention to tooling as well. I see it as just weighing the costs and benefits of various trade-offs.
People who work on IDEs / text editors can work on tooling and integrating with languages as they become popular (or before), but developing an IDE from scratch with a language and continuing to support it seems like a waste of time when I personally would never really consider using it and its chances of being a decent text editor are slim.
Which is all not to say that I definitely do like coordination between the two camps.
So I guess I made two arguments, one that I like what I use and prefer to keep using it over having some new perhaps questionable tool, and two that it's a non-trivial amount of work that has already been done, which I feel is better spent by other external parties rather than core devs.