[hilaire]

> the ability to modify a live environment is fine, but it's only just barely better than coding in a file, and only because it saves you a small amount of time.

With experience programming complex applications both on C++ and Smalltalk, I have experienced coding in a live environment is all but a tiny advantage, it is a real productivity booster. The more complex your application the more productivity gain you have. In an interactive geometry application as Dr. Geo (http://drgeo.eu) , the combined use of in-situation inspector, debugger and live code editing on graphic geometry items, ease issues finding and fixing. Fixing issues is much more easier and pleasant thanks to the developer tooling. This is not without mentioning other advantages as a better source code access and understanding thanks to the class browser. In C++ I was using Emacs.

> I have to believe that there's some way to remove the development environment from the final image, It really depends on the Smalltalk implementation. I heard Dolphin Smalltalk (http://www.object-arts.com/) or Smalltalk X (https://www.exept.de/en/smalltalk-x.html) are really good at that. Pharo itself is doing progress in that specific direction.

[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.