> Pascal has a lesser "complexity budget" than C. Well, the point of the "complexity budget" idea is that you just have a fixed budget, and can spend it on thi

> Pascal has a lesser "complexity budget" than C. Well, the point of the "complexity budget" idea is that you just have a fixed budget, and can spend it on things. So everybody gets the same budget - maybe Pascal just didn't spend parts of what'd been available. Regardless, as I said, this is not about good or bad programmers. The shell (i.e., not the horrible abomination called "command line" on Windows) is not a complex tool. The number of different concepts in a shell like bash is actually quite low - commands, functions, environment variables, substitution, globbing, if, for, pipes & streams. Escaping is a bit idiosyncratic, but hey. I'd even argue that using a well designed shell command is actually simpler than using a Windows wizard - the number of concepts and hoops you have to jump through are less, you just have to learn a limited number of concepts once. Same goes for Erlang. That's actually a remarkably simple language. Once you wrap your head around functional programming, to the point where it could use some more complexity IMHO (like better typing/structs). Understood like that, the "complexity budget" is actually a valid concept. Languages have features (concepts), and they tend to interact with each other (e.g. static, initializers, final and constructors in Java). If you have to many of them, the interactions get unpredictable and messy, and the language has too many concepts to keep in mind easily at the same time. I'm not arguing for dumbing things down to the minimum here. Complex features are fine if they give power, but having too many of them, and possibly ill designed ones, will yield an unnecessarily difficult language. The difficulty of language design is IMHO what to take, what to leave out, and how to pick features to give a maximum of power/expressivity with the minimum complexity.