> That would only encourage more people to waste days of debugging effort on > their lovely poorly thought out "plugin systems".
With great power comes great responsibility and all that jazz. The whole appeal of Nim is to provide people with the power and expressivity to realize what they want. Just like macros power can lead to poorly thought out and unmaintainable code, yes so does plugins. However, if we wanted to put shackles in the language we could have done Go v2 instead of targeting Lisp expressivity. > "The key point here is our programmers are Googlers, they’re not researchers. > They’re typically, fairly young, fresh out of school, probably learned Java, > maybe learned C or C++, probably learned Python. They’re not capable of > understanding a brilliant language but we want to use them to build good > software. So, the language that we give them has to be easy for them to > understand and easy to adopt." – Rob Pike > > "It must be familiar, roughly C-like. Programmers working at Google are early > in their careers and are most familiar with procedural languages, > particularly from the C family. The need to get programmers productive > quickly in a new language means that the language cannot be too radical." – > Rob Pike There are legitimate use to a plugin system, the solution is to educate not to restrict. > CFO asks CEO: “What happens if we invest in developing our people and then > they leave us?” > CEO: “ What happens if we don’t, and they stay?” A programming language cannot fix system designs and architecture issues.
