Another weakness that isn't often mentioned is the lack of true concurrent processing (multithreading). Smalltalk has cooperative multithreading which is better than nothing. But in our world of massively multicore/multiprocessor systems, the lack of true concurrency is a serious shortcoming.

One "weakness" that is frequently mentioned is dynamic typing. But this is a false argument. First of all, static typing is not a panacea and whatever typing system you choose involves an engineering trade-off. It's only a weakness if you make the wrong trade-off.

Second, you can derive most, if not all, benefits of static typing through TDD (or test-driven development). Well-tested Smalltalk systems are every bit as reliable as systems written in C++ or C# or Java.

Another "weakness" that is frequently mentioned is Smalltalk's image-based development model. Supposedly, its isolation from the regular world of file-based development is a disadvantage. Again, this is a question of engineering trade-off. Image-based development offers many advantages but it definitely doesn't integrate well with the file-based world.

As I said in my yet-to-be-published Camp Smalltalk video: Kent Beck famously said, "I mean, source code in files; how quaint, how seventies!"

I'll mention one last weakness: execution performance. At its best, Smalltalk programs run no faster than programs written in Java or C# or Python, all of which are based on byte code execution and virtual machines. If you need the performance capability of C/C++ or Rust, then stay away from Smalltalk. But how many of us get the opportunity to work on operating systems or avionics or high-performance computing?

No programming language is perfect. They all entail engineering trade-offs. The question every developer must ask themselves is: How important is it to complete my software project on time and on budget?