Why Smalltalk is so easy to evangelize

Hi Richard,

Regardless of the reasoning behind the title of the article, I don't
like the tone of the last paragraph, it is not necessary, and probably
not recommended either, to demote other languages in order to promote
yours. In particular languages that have their own merits and
capabilities to which Smalltalk/Pharo can't fulfill today, and by
design won't neither.

Regards,


Esteban A. Maringolo

On Thu, Jan 9, 2020 at 1:07 PM Richard Kenneth Eng
<[hidden email]> wrote:
>
> https://itnext.io/why-smalltalk-is-so-easy-to-evangelize-2b88b4d4605c
>
>

It depends on how one interprets the last paragraph. Yours is one
interpretation, and one that never occurred to me.

I didn't see it as "demoting" other languages. The paragraph in no way
criticizes other languages. It simply suggests that Smalltalk offers many
more resources for evangelism. It's all relative.

I happen to like Dart, Elixir, Golang, Julia, and Rust. But be honest: do
these languages provide nearly as many reasons to choose them? I'm not being
deprecatory.



Esteban A. Maringolo wrote
> horrido.hobbies@

> &gt; wrote:
>>
>> https://itnext.io/why-smalltalk-is-so-easy-to-evangelize-2b88b4d4605c
>>
>>





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

On Thu, Jan 9, 2020 at 2:23 PM horrido <[hidden email]> wrote:

> I happen to like Dart, Elixir, Golang, Julia, and Rust. But be honest: do
> these languages provide nearly as many reasons to choose them?
> I'm not being deprecatory.

I don't know about Julia nor Elixir, but Dart has Flutter, Golang
drives a good chunk of the high-availability internet and Rust is
becoming the most secure programming language and several critical
applications are being rewritten in Rust.

Their user base is huge (and so is their funding), but it's not only
about funding, the reasons to choose them are a lot, there is no
silver bullet.

Regards,

Esteban A. Maringolo

This rant states once again that in Smalltalk everything is an object. Alas, it is not (but should). This is a shortlist of things which is currently not objects in smalltalk:

Absolutely correct. Each of those languages do have good reasons to choose
them. I have never said otherwise.

My point is that Smalltalk gives me many more reasons, many more ways to
evangelize it. Smalltalk is very easy to evangelize. That's the premise of
the entire article, and if it's wrong, then I should delete the entire
article.

Is it wrong?



Esteban A. Maringolo wrote
> On Thu, Jan 9, 2020 at 2:23 PM horrido &lt;

> horrido.hobbies@





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Which rant is that???

To me, what's really nice is the supremely simple language *and* the easily
accessible programming environment *and* live coding *and* metaprogramming
*and* the functional aspect (lambdas). It's not just one thing. It's the
synergy that comes from the totality.

However, there's no question that Smalltalk isn't perfect. There is
certainly room for improvement, as you point out. But if there is a
programming language that can come closer to perfection, I don't know what
it is. And I've used a lot of languages.

Such is the current state of affairs.



Kasper Osterbye wrote




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Kasper Osterbye wrote
> in Smalltalk everything is [not] an object
> ...
> * Message categories

I agree with the thrust of your post and would like many of the items you
suggest. That said, one semantic nitpick: "everything is an object" means as
opposed to primitive types i.e. Date is an object that receives messages
like any other, unlike in a language where it's a primitive  type with
hidden restrictions on how to interact with it. What you seem to be saying
is that our objects are not always appropriate/optimal reflections of the
domain, which is true but different.



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Hi Richard,

I don't find Smalltalk easy to evangelize, and in my experience the
appeal to history (a variation of the "argumentum ad antiquitatem"
fallacy) proved ineffective.

People don't care about who invented MVC, bitblt or JIT, and so make
decisions looking into the future, they weight in the past of course,
but looking forward is what matters for any decision you take now.

That's why things like Flutter or Elixir and other "new" technologies
get the attention they get these days, even when there are no "huge"
success cases. I can't judge whether these techs have value, are hyped
and/or there is a lot of FOMO in the decision making process. And no,
I don't believe it is because of Google shoving it through people
throats, it's people finding something valuable and trying to get an
professional advantage by learning/adopting it early.

Smalltalk adoption in the last decade has grown by its own merits,
_despite_ of the efforts to promote it.

I would bet that any appeal to emotion could be more effective, since
most developers get frustrated and any modern Smalltalk dialect can
ease that inherent frustration of software development, or even
better, turn it into an enjoyable experience (as it's been my case for
over a decade).

Have some reasonable big tech/company saying they're going to use X,
and you'll have flocks of users trying X.

Esteban A. Maringolo

On Thu, Jan 9, 2020 at 5:03 PM horrido <[hidden email]> wrote:

Oddly enough, I've had better results by appealing to history. I guess it has
more to do with *how* I did it, my style and creativity.

Things like Flutter and Elixir and Kotlin (for Android) are anomalies.
Essentially, they benefitted from luck and word of mouth. You can't rely on
that.

While Smalltalk adoption has grown, if only slightly, it's still so far
behind that much of the public continues to believe Smalltalk is dying. For
me, that simply isn't good enough.

It would be really nice to have some big tech company adopt Smalltalk, like
Amazon, Apple, Facebook, Google, Microsoft, Netflix, Uber, etc. That would
hit the ball right out of the park. Alas, I don't see that happening. I'm
afraid JP Morgan, Siemens, and Thales aren't good enough.



Esteban A. Maringolo wrote
> horrido.hobbies@





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

On 10/01/20 12:25 AM, Kasper Østerbye wrote:
> This rant states once again that in Smalltalk everything is an object.

The word 'object' has been bandied about with multiple meanings, so it
is understandable that you would challenge this claim. Smalltalk uses
the term 'object' with a specific meaning - see chapter 30 of bluebook
(Formal Specification of Object Memory)[1] for a concrete definition.

The image is an object graph. The allocated memory in a heap consists
entirely of a list objects which can be iterated through first/next
messages.

You need only two tools - Inspector and Explorer. Inspect to examine a
single object and the explorer to trace interconnections in the object
graph.

Implementations like Squeak or Pharo may use strings instead of fully
reifying programmable entities but that doesn't mean that they cannot.
Also, some 'objects' may be managed entirely within the VM interpreter
for pragmatic reasons.

> To me, what really is nice about Smalltalk is NOT the language - it is
> the image and live programming. And I can get around all the problems
> with the language because of it. I miss:

Bingo! Smalltalk is best understood as a virtual machine with live
programming facility. Language is only a small part of it.

[1] http://www.mirandabanda.org/bluebook/bluebook_chapter30.html

Regards .. Subbu

That happened once in the history of Smalltalk and the big player was
IBM ... and actually that really showed impact to the Smalltalk market.
Lots of consultings were running around, get pretty much money to teach
COBOL programmers how to use Smalltalk (or to be more precise: learn how
to click programs together).

That hype perhaps lasted a few years ... and then IBM switched to Java
... so they never can go back.




Marten

Am 09.01.20 um 23:16 schrieb horrido:

>
> It would be really nice to have some big tech company adopt Smalltalk, like
> Amazon, Apple, Facebook, Google, Microsoft, Netflix, Uber, etc. That would
> hit the ball right out of the park. Alas, I don't see that happening. I'm
> afraid JP Morgan, Siemens, and Thales aren't good enough.


--
Marten Feldtmann

Am 10.01.20 um 10:16 schrieb Marten Feldtmann:
> That happened once in the history of Smalltalk and the big player was
> IBM ...

Well, twice actually ;-)
Many people might not know that HP once was a Smalltalk vendor with
their distributed Smalltalk (which was actually a white-label copy of
VisualWorks iirc/iiuc)...

Big corporations do not warrant the success of a technology. We'd still
be using OS/2, BS2000, whatever...  today if that was the case.

The much bigger impact on Smalltalk's demise was that all vendors back
in the nineties told their customers to switch somewehere else. One of
them even never delivered what they had suggested as a replacement...


I tried not to jump in here, but I am still a bit surprised how many
people state that Smalltalk was so superior to (whatever hyped thing of
the day).

How many of us have built a nice iOS or Android App in Smalltalk? Do we
even havy anything that might allow to do that in a power efficient way?
How many of us have built a modern-looking SPA web application in
Smalltalk? Smalltalk-only?

These are areas where Smalltalk is quite weak and may not excel in any
time soon. Let's be honest about it. None of the commercial vendors have
announced anything in that direction, and to my knowledge, none of the
open-source ones have anything more that the usual JS bridging.

Dart/Flutter promises to finally be a platform on which you can write
apps for both mobile platforms, the web and maybe even native with one
single code base. Does that sound like a dream to developers who need to
pick a tool? I guess so.

Is there any point in telling people how great Smalltalk is when writing
a mobile app or an SPA is hard to almost impossible?
I know there are prototypes and even shipped apps on mobile platforms.
Some are available and can be used, but are complex and mostly
undocumented. One is private and doesn't even have a (public) price tag
(yet?).
Not really comparable to downloading Flutter and starting to write your
first mobile app on a Saturday afternoon. Not sure the productivity
advantage we keep praising (be it existent or not) will be noted much by
somebody who needs to pick a tool now.

So let's stop trying to convince people with things that mattered some
20 years ago. Even the function point thingie we keep carrying in front
of our bellies (Capers-Jones was it?) is a lie when you want to build an
application for today's markets.

Smalltalk is great. If you don't need a mobile app to accompany your
product. It's great if your GUI doesn't have to be sexy as hell or you
are happy reinventing wheels. It is great if you only ship to PCs or on
the web and don't need a lot of interaction in the browser. Anything
else is hard in Smalltalk. If it's not, it is undocumented.

I am not sure if energy spent on these "syntax fits on a postcard and,
btw,  we have the balloon" articles could be better spent doing
something about the problems I mention here. I was in the same boat in
the late 90ies and early 2000's with my blog and articles and stuff. All
I found out was that nobody actually cares about these old hat stories.
Heck, a lot of people these days don't even care about maintainability.
You don't like it any more? No prob, we can redo it in this great new
(JS) framework anyways.


I am not saying anything is wrong about the maintainability of Smalltalk
code or greatness of our IDE support. I like it and use it every day. I
love programming in Smalltalk and hunting bugs in Smalltalk and fixing
customers' problems in Smalltalk. I can fix a bug while the user tells
me about theit problem and I am convinced not many other technologies
can support me in this as good as Smalltalk does. But, unfortunately, I
spend way too much time reinventing GUI glue code fo the web. And,
unfortunately, I need to implement a lot of stuff in Javascript. Oh, and
unfortunately, there is nothing as good as this if I wanted to ship a
nice mobile app to augment our service. When it comes to these, I am not
productive. I am not even close to any bleeding edge, and if I want to
be, I need to do it on my own. Is it more productive to reinvent a
Smalltalk version of VueJS just do be able to do the same as VueJS in JS
than it would be to learn JS and VueJS and do some part of my work in
those?

I wanted to stay out of this thread, because it leads nowhere. But now
that I've typed all this, I will push the send button and regret it in a
few minutes...

Joachim






 >and actually that really showed impact to the Smalltalk market.
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

The problem is that IBM and HP adopted Smalltalk at a time when Smalltalk
wasn't ready nor deserving. There was no major open source Smalltalk. There
were several commercial Smalltalk vendors sniping at each other. Smalltalk
was totally unprepared for the nascent web. Smalltalk was too heavy to run
on the hardware of the day. And C++ had a much stronger OOP narrative.

Today, we have many open source Smalltalks. The commercial vendors are more
civil. Smalltalk is most definitely web-ready. Smalltalk runs well on the
Raspberry Pi. And C++ is in decline, according to TIOBE.

Today, we need major tech adoption. Today's generation doesn't care about
who adopted what a quarter century ago. There's no reason IBM and HP
couldn't pick up the Smalltalk mantle again if they wanted to — the
Smalltalk landscape is totally different. The outlook for Smalltalk is a
brand new story.

Major tech companies are just as vulnerable to hype and marketing as human
beings are. They need to be persuaded to adopt Smalltalk. We can do our part
to help Amazon, Apple, HP, IBM, and others to see the light.



[hidden email] wrote




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

On 9 January 2020 at 17.07.25, Richard Kenneth Eng ([hidden email]) wrote:

https://itnext.io/why-smalltalk-is-so-easy-to-evangelize-2b88b4d4605c 

On Fri, Jan 10, 2020 at 6:53 AM [hidden email]
<[hidden email]> wrote:

> I wanted to stay out of this thread, because it leads nowhere. But now
> that I've typed all this, I will push the send button and regret it in a
> few minutes...

Don't regret it, I like how you wrote and I agree with most of what
you said, maybe because we deal with similar kind of software
solutions.

It's only when you use something to solve a real problem, usually with
economic constraints, that you find its strengths and limitations. And
Smalltalk has both.

Regards,

Esteban A. Maringolo

jtuchel wrote
True, but major tech adoption *can* greatly increase public mindshare.
C#, TypeScript, Golang, Kotlin, Swift, and Rust are good examples.


> So let's stop trying to convince people with things that mattered some
> 20 years ago. Even the function point thingie we keep carrying in front
> of our bellies (Capers-Jones was it?) is a lie when you want to build an
> application for today's markets.

I disagree that it's a lie. The study is based on thousands of projects and
millions of lines of code over a period of several decades, including recent
years with languages like C#, Ceylon, Dart, Elixir, F#, Golang, Haskell,
Haxe, Julia, and LiveScript. Some of these are cutting-edge languages
used for modern applications.


> Smalltalk is great. If you don't need a mobile app to accompany your
> product. It's great if your GUI doesn't have to be sexy as hell or you
> are happy reinventing wheels. It is great if you only ship to PCs or on
> the web and don't need a lot of interaction in the browser. Anything
> else is hard in Smalltalk. If it's not, it is undocumented.

Well, perhaps not for ALL mobile apps, but Cordova is certainly used for
cross-platform mobile development. I've used it with Amber and PharoJS
and the documentation is pretty good.

People also use React Native, so there's no real reason to avoid JS.


> I am not sure if energy spent on these "syntax fits on a postcard and,
> btw,  we have the balloon" articles could be better spent doing
> something about the problems I mention here. I was in the same boat in
> the late 90ies and early 2000's with my blog and articles and stuff. All
> I found out was that nobody actually cares about these old hat stories.
> Heck, a lot of people these days don't even care about maintainability.
> You don't like it any more? No prob, we can redo it in this great new
> (JS) framework anyways.

It's not an either-or situation. We can market Smalltalk *and* address the
technical weaknesses of Smalltalk. For example, I'm doing the former
and you guys are doing the latter. What's the problem?

It would be nice if more Smalltalkers got involved with Smalltalk marketing.
I can't do this forever.





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

On Fri, Jan 10, 2020 at 10:52:51AM +0100, [hidden email] wrote:
>
> I wanted to stay out of this thread, because it leads nowhere. But now
> that I've typed all this, I will push the send button and regret it in a
> few minutes...

Joachim,

Thanks for pushing the send button.

Dave

Am 10.01.20 um 15:42 schrieb horrido:

>
>> So let's stop trying to convince people with things that mattered some
>> 20 years ago. Even the function point thingie we keep carrying in front
>> of our bellies (Capers-Jones was it?) is a lie when you want to build an
>> application for today's markets.
>
> I disagree that it's a lie. The study is based on thousands of projects and
> millions of lines of code over a period of several decades, including recent

Well, naming it a "lie" is perhaps too strong - but Joachim (did you
have a bad Smalltalk day ?????) statement is from my point of view
correct - this talking about function point and productivity is an
academic point.

If I am a Java developer and my productivity is around 10% compared to
Smalltalk developer it is still useful to use Java - because for my
problem there might exists already dozen of libraries and solutions.

Using Smalltalk today is matter of personal taste and love - like many
other developers in other languages.

Joachim mentioned the critical points and for me perhaps the following
statements are true:

* Smalltalk development over the last decade ran in circles

and due to that

* Smalltalk is not solving the biggest problems any more

So many time has been wasted to make a Smalltalk dialect running in a
browser.

I would use (my loved) Smalltalk today only, if

* I have an application, which was written in Smalltalk (and I have one)

* Smalltalk is superior to other solutions in a specific topic (and with
Gemstone I have one topic)

When I would start from scratch ... build a headless Smalltalk, put lots
of good communication libraries into it, spread it over Windows, Mac and
Linux, make it open source and put some XML and JSON and solve printing,
multithreading/multiprocessing (framework) runtime AND (!) debugging,
scripting, interconnections with other languages. Try adding a modelling
and source code generator. Build the whole stuff with concurrency in
mind - offer specific data structure to help you here. Look for suitable
persistency options.

Go back to the time, where Smalltalk source code was hold in a
repository to manually work with it and and not getting software via
Github with some broken relationships between packages and nobody knows why.

Use the browser (with Javascript) as the main UI and build a superior
interface in Javascript to the backend Smalltalk. Use the Electron
framework and build some specific support for Smalltalk into that.

But even with that in mind you will not catch the Javascript developers
(because they are on that way already and they do not need Smalltalk),
but you may survive as a Smalltalk developer.

Spread the word around, that multi-language development is a MUST and
one should support it.

So, to summarize - this is my personal view of Smalltalk today - since
1986, where I first met Georg Heeg on a Atari fair in Düsseldorf seeing
the first Smalltalk system in my life.

Marten




--
Marten Feldtmann

[hidden email] wrote
Not so academic. After all, the study was based on a huge number of software
projects for dozens of programming languages over many years. It doesn't get
any more practical than that.

The analysis was simplified by adopting the "function points" model which
provides a level playing field for all the languages. It's about the amount
of
time needed to do a certain amount of work, whether that work is specific to
a few domains or to many. Some people may take issue with the analysis, but
it's there for your consideration at any rate.

Since there is no other study of its kind in the world, I choose to use it
in my
advocacy. Readers can make their own judgement.




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html