[groovy2shoes]

What do you think about the proposition that a good chunk of the difference in productivity was due to the fact that you were no longer dealing with such a shitty language as C++? ;)

The way you explain the advantages, it seems like the live environment is much more beneficial when developing highly interactive applications, perhaps GUI applications especially, but the advantages of the live environment wouldn't come into play so much when developing non-interactive, "batch mode" applications. Do you think that's a fair assessment?

If so, then perhaps one reason I didn't find much value in the Smalltalk environment is that I wasn't developing interactive applications. With batch applications, I've come to find that even classical debuggers aren't quite as helpful as they are with interactive applications, because depending on how long it takes your program to run, it can often be faster to run a test case and inspect the log than to set a few breakpoints and step until you find your problem.

[hilaire]

AFAIK, in Java or Python, I don't find this live environment either. Also I found these languages to be over-complex or inconsistent in their paradigm. I remember Java to be overequiped in its Object representation or Python to be inconsistent with its String object. In Smalltalk I don't need to question my self with the language itself: it is always consistent, rooted to a few set of rules. Only questioning is when dealing with the functionality of a class or method, but in that case I can look in the live environment itself use case of a class or method new to me.

In my experience live environment brings added values when you need to fix issues arising in the middle of a complex process of data and state computation or manipulation. In such situation, logging errors, fixing, rebuild, rerun, positioning the program states where the errors raised is very time consuming (and frustrating) than fixing in the live environment where you just need to recompile the faulty code (method granularity), adjust the data and resume the execution of the program from there.

In my experience it is true for GUI interactive application, fixing non interactive algorithm, processing data, web application.

By batch mode, I guess you mean processing data. If the process is complex, the live environment will help to get more quickly a proper and safer code. But may be in that case, you want a small script or executable you can move along easier than the Smalltalk environment. That's an area of use I don't know with Smalltalk and Smaltalk was not designed for that use case, although it seems people are using it too as a script tool. I will interested to read about that use cases too.