How learning Smalltalk can make you a better developer • Hacker News Board

Re: How learning Smalltalk can make you a better developer

#71

Post by groovy2shoes » Mon, Aug 01, 2016, 11:01 AM UTC

horrido wrote: post #62

groovy2shoes wrote: post #58

Earlier quoted context omitted.

> That was likely Squeak, not Pharo. Pharo has muted a lot of the UI colours to be more appropriate for a business environment. I've used both. Yes, Pharo is considerably more professional-looking, but it's still rather ugly and alien (as in, it looks very odd when juxtaposed with the other applications running on the host system). > Avdi Grimm has written a few books about Ruby. He records his experience trying Phar…

Smalltalk doesn't only rely on OOP. It has lambdas and closures so that you have functional capabilities, too. Not strictly multi-paradigm, but close enough. This is why Smalltalk is so powerful. Multiple inheritance has its problems, too. I prefer the greater simplicity of single inheritance.

Most "problems" with multiple inheritance stem from languages that don't provide a well-defined method resolution scheme. Languages that do have a well-defined hierarchy linearization tend to avoid most of the problems with multiple inheritance.

See, for example: Common Lisp, Dylan, Python (since 2.3), Perl 6, ...

Re: How learning Smalltalk can make you a better developer

#72

Post by hilaire » Tue, Aug 02, 2016, 3:35 AM UTC

groovy2shoes wrote: post #69

hilaire wrote: post #63

Earlier quoted context omitted.

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

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…

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.

Re: How learning Smalltalk can make you a better developer

#73

Post by hilaire » Tue, Aug 02, 2016, 4:00 AM UTC

groovy2shoes wrote: post #67

qwertyuiop924 wrote: post #60

Earlier quoted context omitted.

>I'm familiar and reasonably comfortable with the "image" concept from Lisp, I'm primarily a Schemer, so correct me if I'm wrong, but lisp, at least since the death of the lisp machine, doesn't have an image: it has a live environment in RAM, and there's no easy way to dump that to disk. It's just a REPL. >I have to believe that there's some way to remove the development environment from the final image, but I didn't…

> I'm primarily a Schemer, so correct me if I'm wrong, but lisp, at least since the death of the lisp machine, doesn't have an image: it has a live environment in RAM, and there's no easy way to dump that to disk. It's just a REPL. This is true of many Scheme environments. Some Scheme environments do support the image-based development model, and at least Scheme48 uses it exclusively for compiled code. However, it's…

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