…h. We wrote another one in Java to do the same task, with the D3 JS library for data visualization. The Java web application was several times faster than the Pharo app in rendering visualizations and processing data throughput. When one of the applications crashed, the difference in error and crash handling between Java and S…
I have no doubt that you’re telling the truth, but I have to ask: Was the Pharo app too slow? Was it unusable?
The reason I ask is because, in practice, most software applications written in dynamically typed languages run more than “fast enough.” That is to say, if they ran 2–3X faster, the end-user probably wouldn’t even notice nor care.
This explains why Python, Ruby, Perl, PHP, Erlang, Common Lisp, Racket, and Smalltalk have been successful languages.
Moreover, these languages can often be locally optimized to achieve the desired performance objectives. Have you done this with your Pharo app?
I will be the first to say that Smalltalk is not a perfect universal programming language. It is suitable for most problem domains, but it may be weak in others. I would not use Smalltalk for real-time control systems (like avionics), nor high-performance computing (like weather modelling), nor console video games (like PlayStation and Xbox). Always choose the right tool for the job.
In those domains for which Smalltalk is suitable, you will enjoy a tremendous productivity advantage. That is why Smalltalk is a favourite “secret weapon” of many enterprises.