Languages are not islands that can be considered in isolation. They have to be part of a development environment and it is time that this was fully recognized. A language isn't just syntax and semantics. A language is syntax, semantics and an IDE. 

People keep on inventing languages to make up for some defect or other in existing languages but many of these perceived shortcomings can be fixed without inventing a new language. The point is that a language isn't something used in isolation.

When the merits of a language are considered it is very often the case that it is the bare unsupported language. Language is pitted against language but it is usual that a language is used with a set of tools that enhances its behavior in all sort of ways. This is a bad enough distortion but it gets worse. Because problems are see as language problems they are often "improved" to include cumbersome or restrictive features that would be much better provided by a suitable tool.

We need to consider the entire ecosystem that surrounds a language before we evaluate it or "improve" it.

Okay, so English spelling is terrible.

Really, really terrible.

So what is to be done?

We could reinvent the spelling system so that every word had a perfectly logical spelling that was next to impossible to get wrong. This is an approach that fits in with the "hard line" language mind set. The problem is that changing the spelling would mean we couldn't access all the years of literature that had built up unless we went in for a huge conversion project.

No - changing the spelling rules is not a good idea. What is a good idea is inventing the spell checker and corrector. In practice this brings the level of correctness up to something beyond what you might expect with a logical spelling system but no spell checker. 

More cartoon fun at xkcd a webcomic of romance,sarcasm, math, and language

As it is with natural languages so it is with computer languages but we tend to forget this because computer languages are perceived to be more changeable and far less permanent.

If there is a perceived problem with the language we can fix it in version x.y+1 and so on but there comes a point where the changes needed mount up and there seems to be nothing more we can do other than throw the whole thing away and start again.

This seems harmless but the proliferation of languages is not a good thing. Which one to learn? Should you stick with C89 or  move to C23? C is terrible lets use Rust instead! What's the deal with Perl 5 and 6 are they even the same language? As it turned out the answer was no. Creating a new language is as damaging as changing the spelling rules of English.

This is not a very common view point because for a complicated set of reasons there are lots, perhaps even the majority of programmers who just don't believe that tools exist or should exist or could exist. These are minimalist masochists proud of their ability to create code using nothing but an editor.

How often have you heard or said "I program using just Notepad, Emacs, Notepad++, vi or that utility I created while waiting for a compile to complete. 

There is both a macho culture about building programs with as little visible support as possible and a very read psychological dependence on the first set of editing keystrokes you learn. As long as you use the editor often enough and for long enough just about anything can seem productive to the point of excluding an alternative. 

When you change to a new programming environment it all seems strange and clunky and you immediately think that your original way was better. And of course the macho payoff in saying "we don't need no stinking IDEs" and returning to a text editor and flying by the seat of the pants is huge. Yes I really do think its a "bro" thing.

Partly to blame is the way that popular language distributions are just that - language distributions. I tried to "get into" Ruby recently and after downloading the language implementation was dismayed to find that all I had to get started was an interactive REPL. If you download Python at least you get IDLE which calls itself a Python GUI. This is not a GUI this is a minimal code editor with a run button - better than nothing but it could be so much more. 

IDLE is better than nothing but as an IDE it is just a start - and it needs to get more ambition

There are so many languages that you have to ask the community how best do I work with this?

What is really surprising is that you will usually not get a single clear answer. 

I'm not picking on any particular language here - they all suffer from "the language is enough" syndrome. JavaScript, Java, Lisp, Lua, R, Go, C++, Rust and so on all come as they are and expect you to find or work out a suitable development environment to use them in. When they do have a standard development system it is usually, like IDLE a minimally viable product. If you think that any of these do come with a development environment then either you have low expectations of a development environment or you have provided your own.

The one big exception to this picture is the Microsoft languages C, C++, C#, Visual Basic, F# and so on have all been delivered with a full IDE in the form of Visual Studio and if you learned programming via this route you will perhaps not fully understand my concern when it comes to other languages. Move away from the Microsoft environment and you will be hard pressed to find and IDE as good as Visual Studio - Eclipse and its derivatives sometimes get close and NetBeans used to try but they all lack so many of the features that you take for granted in Visual Studio. And don't talk to me about Visual Studio Code - its an editor and should be ashamed of itself for using "Visual Studio" in its name.

This is something Microsoft has got right for some time. It has packaged its languages complete with an IDE and seen the system very much as a whole. 

Yes I guess that there are a few people who swear by using C# with the command line compiler but the majority know better and pity the poor fools.

The problem is that even Visual Studio is just a step on the road to the sort of help that IDEs and other tools could provide the programmer. We have hardly got started in crafting the tools we need and you tell that this is not a wide spread opinion by the way language communities simply don't bother to provide IDEs to wrap their languages in. Ruby is just Ruby not Ruby plus an IDE.