There is something missing in the "simple vs. easy" argument. You need to put things in the perspective of evolution.
Designing an "easy" language is easy because you can usually resort to human intuitions, yours or somebody's else. Everyone can tell your language is easy or not; although there is no single criteria of what is easy, it's still possible to come up with something that many people agree are easy.
Evolving easy languages is also not hard. Just follow the trend and keep making it easy to do whatever just became popular. Statistics, backend development, machine learning, whatever. If some early design choice turns out to be a bad move, just provide alternatives. People don't have very high expectations about the internal coherency of your langauge, so you have much freedom in evolving your language.
Designing a "simple" language is much harder because it requires a very deep understanding of the underlying structure of your runtime environment, the kinds of systems you want to build with the language, and the structure of computer programs in general. Appreciating easiness requires experience and insights, and simple things can appear complex when looking from a different perspective.
Even if you are super smart and came up with a amazingly simple language, that's only the beginning. Sooner or later, whether it's new area of programming or a design mistake surfacing, you need to evolve your language. And that is hard, because blindly adding features will destroy the simpleness and your language degenerates into an "easy" one. Instead, you need to carefully think about the natures of the new requirements, challenge the assumptions underneath the original design, and restructure your design. This process is often slow and can be more challenging than the original design process.
Of course as the article says, "simple" and "easy" is hardly a dichotomy; what I described are extreme cases, and most if not all languages fall somewhere in between and exhibit properties from both sides. But I think it's helpful to think the two dimensions in this way.
Designing an "easy" language is easy because you can usually resort to human intuitions, yours or somebody's else. Everyone can tell your language is easy or not; although there is no single criteria of what is easy, it's still possible to come up with something that many people agree are easy.
Evolving easy languages is also not hard. Just follow the trend and keep making it easy to do whatever just became popular. Statistics, backend development, machine learning, whatever. If some early design choice turns out to be a bad move, just provide alternatives. People don't have very high expectations about the internal coherency of your langauge, so you have much freedom in evolving your language.
Designing a "simple" language is much harder because it requires a very deep understanding of the underlying structure of your runtime environment, the kinds of systems you want to build with the language, and the structure of computer programs in general. Appreciating easiness requires experience and insights, and simple things can appear complex when looking from a different perspective.
Even if you are super smart and came up with a amazingly simple language, that's only the beginning. Sooner or later, whether it's new area of programming or a design mistake surfacing, you need to evolve your language. And that is hard, because blindly adding features will destroy the simpleness and your language degenerates into an "easy" one. Instead, you need to carefully think about the natures of the new requirements, challenge the assumptions underneath the original design, and restructure your design. This process is often slow and can be more challenging than the original design process.
Of course as the article says, "simple" and "easy" is hardly a dichotomy; what I described are extreme cases, and most if not all languages fall somewhere in between and exhibit properties from both sides. But I think it's helpful to think the two dimensions in this way.