Much sympathy for your life situation.
Most of the Smalltalk code I personally develop is developed using a classic text
editor, is batch compiled, and runs headless.�� Smalltalk is *STILL* an amazing language
without the "addictive" IDE.�� (In fact the more "conventional" Smalltalk systems I use
have sufficiently different IDEs that I experience considerable friction using the IDE.)

I'm on the fringes of the High Performance Computing world.�� This is quite dramatically
different from most programming, and in some interesting ways.�� The dominant languages
are Fortran, C, and C++ with extensions such as OpenMP and OpenACC and of course "transport"
layers like MPI.�� These languages have *serious* optimising compilers working hard to get
the best out of vectorised instructions, GPUs, even FPGAs, and clusters.�� There are also
dialects like SYCL and Cilk.�� As an example of the kind of application, consider the
COVID epidemiological model developed by Neil Ferguson's team in the UK, which was very
influential in setting UK government policy (lockdowns).�� This is about 10 000 SLOC of
C++ with much use of OpenMP for parallelism.�� This isn't "bet your business" software;
this is "bet your whole ECONOMY" software.�� It is, in the 1970s sense, "structured".�� It
is, in the peculiarly C++ sense, "object oriented".�� And it is very hard for me to
figure out what is going on (despite having tracked C++ since cfront days).

What does this have to do with Smalltalk?

First, Smalltalk is not an HPC language.�� If you want to develop computationally
demanding code, you might prototype it in Smalltalk, but you are not going to deploy.

Second, that doesn't necessarily preclude the use of Smalltalk in HPC environments.
People seriously use Python (despite Python's single-thread slowness), Matlab, and
R for HPC problems.�� What they do is wrap Fortran/C/C++ data structures and call
Fortran/C/C++ code to manipulate them, basically using Python or Matlab or whatever
to direct the low level code.

Third, just imagine the fun of debugging code like this.�� You don't really want to
write Fortran (even Fortran'08) or C++ (even C++17) by hand; it's ok as "portable
parallel assembler".

Fourth, in order to configure and customise software like this, you really want
a decent interactive modelling language.�� (For example, the CovidSim program uses
data loaded *once* from WorldPop.�� I haven't yet found anything in the distribution
to update this.)

Fifth, there's the whole "Embedded Domain-Specific Language" thing.�� There has been
some impressive work done on generating low level code inside functinoal programming
languages.

Thus I hypothesise that there is room for Smalltalk as a tool for *generating* and
configuring HPC code.

My main worry is that when it comes to "bet your whole economy" software and
worse still, "bet the entire global economy and human happiness for centuries"
software like climate models, it's appropriate to use the very highest quality
assurance tools practical, including *serious* verification.�� That's not common
practice.�� CovidSim has 'assert' statements in just two files.�� Generation via
Smalltalk wouldn't be *worse*.�� But could it be *better* ?

What is the state of the art in verification tools
��- written in Smalltalk?
��- available (via FFI or otherwise) *through* Smalltalk?
��- available in any form *for* Smalltalk?

(I should probably be looking at MOOSE but am too stupid to know how to start.)

On Sun, 15 Jan 2023 at 19:11, mayuresh@kathe.in via Pharo-users <pharo-users@lists.pharo.org> wrote:
Hello,

In response to my email below, I received 5 interesting responses. I thank those people for writing-in.

Here is my take on what I've understood and why I am still hesitant to go along.
My comments on those responses are further below, but, at the moment, let me explain my situation.

I am a 46 year-old who has been programming computers since the age of 16.
I used to be a highly sought-after programmer till the year 2000, when due to circumstances beyond my control, my life and career got destroyed completely.
In fact, I was so highly valued, that in spite of me being from India, I was pursued by Verizon US.
I am now confined to my home (mostly) and I have very little to do, in the past 12 years I have not programmed anything beyond a basic prime-number tester and a fibonacci-sequence generator in C.
I am getting my life back in order and I need some occupation, though, not necessarily one from which I would demand financial returns.
I have been dilly-dallying on a decision, primarily because I am unable to take a call on whether to pursue my love for the low-level (x64 assembler + Forth) or the extremely high-level (work involving reasoning using symbolic inference) using a Smalltalk (either Squeak or Pharo).

The above is not meant to elicit sympathy, but has been tacked-in just to give potential advisers an idea about my state.

Onward to my take on the responses I received to my first email.

As Noury Bouraqadi and Stephane Ducasse mentioned:
It's not about what you can do, but it's about how you do it.
I'd say, that is the basic problem with all Smalltalk aficionados.
The whole environment is such a joy to work with that it is addictive, to the extent that developers forget that it is the "what you can do" which is of utmost importance.

Jupiter Jones email provided the most amount of real-world use-cases.
Though, I am interested in understanding how to use Pharo as the development tool to be able to release code via GemStone Smalltalk.
Is it so that Seaside runs identically on Pharo as well as GemStone Smalltalk?
So, in a sense, Seaside would to Smalltalk, what "Ruby on Rails" is to Ruby.

Tim Mackinnon is very correct in observing that relative to C# and Swift, Smalltalk (and hence Pharo) is very compact, simple and approachable.
Though, I did not understand his statement about conditional logic becoming easier to understand after working especially with Smalltalk. Would he care to elaborate?
Also, on Tim's allusion to Lisp being a cousin, well, Smalltalkers had better acknowledge the fact that most Lispers "look down" upon Smalltalk and do not spare any opportunity to berate its users/developers (this is from personal experience).

Along those lines, I would also like to get an explanation from Jupiter Jones' for "how do you do an if/then?" which as he states leads to a "mind-blown" moment.

Thank you,

~Mayuresh

On Saturday, January 14, 2023 01:31 PM IST, "mayuresh@kathe.in via Pharo-users" <pharo-users@lists.pharo.org> wrote:

> Hello,
>
> This isn't a mail intended to troll this community.
>
> I am genuinely curious about what would be the type of use cases which would be exemplary for Pharo?
>
> Now-a-days, anything one could have accomplished solely with Smalltalk (and hence Pharo) can be accomplished with a number of modern programming languages and their associated frameworks, e.g. Google's Dart with Flutter, Apple Swift with SwiftUI, Microsoft's C# with WinUI.
> And such languages and their associated frameworks are built from the ground-up for a particular platform, while Pharo does not have any such targets, which usually renders graphical applications built using Pharo to "look like" aliens.
>
> What does stand-out regarding Smalltalk (and hence Pharo) is the superior developer experience furnished as a result of the true object system combined with a full graphical environment.
> In addition to that, Pharo, specifically, provides advanced tools like Git integration, etc.
>
> But, are these things all that there are to be considered enough for highlighting the full inherent power of Pharo?
>
> Again, apologies if anyone found the subject line as well as the message body to be troll-ish. That has not been the intent.
>
> Kind regards,
>
> ~Mayuresh