hilaire

Racket is very exemplary with its documentation: https://docs.racket-lang.org/

GUI documentation will likely never show up: the current graphic framework is outdated, subject to deprecation and no subject to improvement since Athens low level layer was left as it is. It may or may not be replaced by Bloc or something else. I don't thing anyone is willing to write documentation when there is not clear direction regarding the GUI framework.

One thing to understand regarding Smalltalk, it is the paradigm shift compared to file based environment: - with the later, you deal with characters (ascii, utf8) - with the former, you deal with object (an internal object representation).

So indeed the tooling is different. One deal with text processing, the other with object processing. The benefits you get are different. The browsers in Eclipse and Smalltalk are not processing the same thing, an Object is a far more abstracted representation of your source code, for example the browser can ask to an Object can you do 'that' kind of processing, or do you accept I send this message (method call in other language), etc.

When developing, the image is your sandbox environment with object representation of your code, but of course Smalltalk developers also save their code in text file representation, but it is only mean as a backup and transportation scheme from an image to another image. AFAIK, it is never uses for anything else than transporting or comparing source code version; not because we can't do it, but because we don't need to it.

The question regarding the source code file arises very often on Smalltalk. Not because Smalltalk is doing wrong there, but because it is a paradigm shift, and as you know we are all more or less conservative regarding changes or different point of view; some fellow free software activists disregard me to use such an awkward environment, but at least RMS did not get problem GNU DrGeo moved to the Pharo platform once I explain the underneath system, and that the access to the source code from the VM up to the Pharo environment was plain free software licensed as MIT licence.

To sum up: - the image is the sandbox where you deal with object - we save code in file (one monolithic file, or small granulated one file per method) for back up, versioning, transportation - the developer may from time to time, decide to take a fresh image and reload his source code - delivered Smalltalk application are built from a fresh image and source code installation from the source file of the code. For http://drgeo.eu I use a combination of Smalltalk script and Bash script to build the delivered application for GNU-Linux/MacOSX/Windows. -

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.

I like a lot this small code example http://math.stackexchange.com/questions/726369/when-does-the...

It results in an interactive diagram of the Newton Raphson method to search for a zero of a function. The user explores with mouse how the algorithm is working.

It is only a few lines of Smalltalk code over the Dr. Geo interface. IMHO, the Smalltalk message system brings well balanced expressiveness on the resulting code.

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

I learn Smalltalk a few years ago to port a C++ interactive geometry software (http://drgeo.eu) to Squeak/Etoys then Pharo. I can testify documentation was never an issue, there are plenty of free books to learn from and a very helpful and talented community.

Smalltalk is still so revolutionary in its concepts, I am afraid you have to do your home work to get it and work on the text book.

Great!