Why Smalltalk is so easy to evangelize

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Why Smalltalk is so easy to evangelize

Offray Vladimir Luna Cárdenas-2
Hi,

(I don't know if there is a netiquete rule of _this list_ about
top-posting inter-posting or bottom-posting, so I will start here).

Is good to see a thread like those with different points, so thanks to
all participants. I agree with several of them.

I think that Smalltalk advocacy is important, but it happens in
different ways, some write prose for that, some code, some both.

In my case, Smalltalk has the strongest point by blurring the frontier
between separate concerns: language, IDE, tools, writing/execution time
and is an experience that may other computing environments, frameworks
and languages are trying to bring (see Svelte, DarkLang, Elm, Clojure
and so on). I still think that the way Smalltalk blurs concerns and the
live coding experience it creates by doing so, is unbeatable. But the
way Smalltalk expose its advantages works in particular domains
(research, prototyping) and not so well in others (mobile) where others
are delivering more and faster apps for the developer and user.

In my case, Smalltalk environments, particularly Pharo, work well
because I used it for my PhD research prototyping and is well suited for
my exploration of new domains (for example I'm now exploring the
Scuttlebutt protocol and social network [1] in Pharo). But I have not
being able to convince any of my coder friends to switch to Pharo
instead of C++, Java or Javacript, which by the way, is the language
they already know and use to put bread on the table on a daily basis. I
have been more successful convincing philosophers, librarians,
journalists in using Pharo and they enjoy it, but I have not any Pharo
related local job proposal and I doubt I will have it.

[1] https://scuttlebutt.nz/

So I think that we deal with a paradox: while Smalltalk advocacy is
better suited for a Blue Ocean Strategy[2], exploring and implementing
new/emerging scenarios and markets, money is already mostly invested in
Red Oceans of constituted technologies and practices ecosystems.
Bridging both is pretty difficult. I will share some Blue Ocean
experiments, but still they are, as usual, weekend and holidays projects
without any promise or resources for a sustained rhythm or deliverables.

[2] https://en.wikipedia.org/wiki/Blue_Ocean_Strategy

Also, there is an important consequence of Richard's (and others)
outreach strategies and is the "inner-reach" echoes of them, so we have
this kind of talks that are worthy and not so frequent about the inter
subjectivities in our community and the ways we think and experience
about Smalltalk in the present and in the future.

Thank you all,

Offray

On 10/01/20 10:53 a. m., Marten Feldtmann wrote:

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


Reply | Threaded
Open this post in threaded view
|

Re: Why Smalltalk is so easy to evangelize

horrido
Offray Vladimir Luna Cárdenas-2 wrote

> But I have not
> being able to convince any of my coder friends to switch to Pharo
> instead of C++, Java or Javacript, which by the way, is the language
> they already know and use to put bread on the table on a daily basis.
>
> So I think that we deal with a paradox: while Smalltalk advocacy is
> better suited for a Blue Ocean Strategy[2], exploring and implementing
> new/emerging scenarios and markets, money is already mostly invested in
> Red Oceans of constituted technologies and practices ecosystems.
> Bridging both is pretty difficult.

Yes, that is the principal obstacle and challenge. When I'm pushing
Smalltalk, I mention the language's simplicity and conciseness, I
mention the purity of the object-oriented model, I mention the
built-in IDE, and so on. But the key advantage that I emphasize
is *programmer productivity*.

I realize it's hard to argue with the availability of jobs for Java, Python,
JavaScript, etc. It's hard to argue with their rich ecosystems. It's
hard to argue with the status quo of established code bases and
IT infrastructures. But we have to make them believe that
Smalltalk can cut their development time in half, if not better.

What is it worth to a company to cut their development time in half?
It means much lower development cost. It means much shorter
"time to market."

Is this not worth investing time and energy in Smalltalk? Even if the
job opportunities aren't there. Even if it means overhauling your
IT infrastructure.

The investment can lead to more users and more jobs. If they don't
believe it, then we have failed.



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

Reply | Threaded
Open this post in threaded view
|

Re: Why Smalltalk is so easy to evangelize

Richard Sargent
Administrator


On Fri, Jan 10, 2020 at 1:52 PM horrido <[hidden email]> wrote:
Offray Vladimir Luna Cárdenas-2 wrote
> But I have not
> being able to convince any of my coder friends to switch to Pharo
> instead of C++, Java or Javacript, which by the way, is the language
> they already know and use to put bread on the table on a daily basis.
>
> So I think that we deal with a paradox: while Smalltalk advocacy is
> better suited for a Blue Ocean Strategy[2], exploring and implementing
> new/emerging scenarios and markets, money is already mostly invested in
> Red Oceans of constituted technologies and practices ecosystems.
> Bridging both is pretty difficult.

Yes, that is the principal obstacle and challenge. When I'm pushing
Smalltalk, I mention the language's simplicity and conciseness, I
mention the purity of the object-oriented model, I mention the
built-in IDE, and so on. But the key advantage that I emphasize
is *programmer productivity*.

I realize it's hard to argue with the availability of jobs for Java, Python,
JavaScript, etc. It's hard to argue with their rich ecosystems. It's
hard to argue with the status quo of established code bases and
IT infrastructures. But we have to make them believe that
Smalltalk can cut their development time in half, if not better.

What is it worth to a company to cut their development time in half?
It means much lower development cost. It means much shorter
"time to market."

It also means much lower error rates. Capers Jones also review errors / lines of code and Smalltalk was substantially better than the C derivative languages. I don't recall the ration, but I think the Namcook report does include it.

Fewer errors means a higher ratio of time spent delivering functionality and a better customer experience. (We can't do anything about bad design and UX practices, of course and unfortunately. Although, I suspect without evidence that Smalltalkers may do a better job of both.)


Is this not worth investing time and energy in Smalltalk? Even if the
job opportunities aren't there. Even if it means overhauling your
IT infrastructure.

The investment can lead to more users and more jobs. If they don't
believe it, then we have failed.



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

Reply | Threaded
Open this post in threaded view
|

Re: Why Smalltalk is so easy to evangelize

horrido
This is exactly why I also push Smalltalk's simplicity. In the 1970s, Per
Brinch Hansen posited that a small, simple language would lead to fewer
programmer errors. The result of his work was the Edison programming
language. It was published in his book, "Programming a Personal Computer,"
which is one of my favourite programming books.

Of course, Per Brinch Hansen wasn't alone in this belief. It was also shared
by Niklaus Wirth who created Pascal and Oberon.

So it's not just Smalltalk's live programming environment that we should
herald. The size and simplicity of the language is a big deal.



Richard Sargent wrote
> On Fri, Jan 10, 2020 at 1:52 PM horrido &lt;

> horrido.hobbies@

> &gt; wrote:
>
>> Offray Vladimir Luna Cárdenas-2 wrote
>> > But I have not
>> > being able to convince any of my coder friends to switch to Pharo
>> > instead of C++, Java or Javacript, which by the way, is the language
>> > they already know and use to put bread on the table on a daily basis.
>> >
>> > So I think that we deal with a paradox: while Smalltalk advocacy is
>> > better suited for a Blue Ocean Strategy[2], exploring and implementing
>> > new/emerging scenarios and markets, money is already mostly invested in
>> > Red Oceans of constituted technologies and practices ecosystems.
>> > Bridging both is pretty difficult.
>>
>> Yes, that is the principal obstacle and challenge. When I'm pushing
>> Smalltalk, I mention the language's simplicity and conciseness, I
>> mention the purity of the object-oriented model, I mention the
>> built-in IDE, and so on. But the key advantage that I emphasize
>> is *programmer productivity*.
>>
>> I realize it's hard to argue with the availability of jobs for Java,
>> Python,
>> JavaScript, etc. It's hard to argue with their rich ecosystems. It's
>> hard to argue with the status quo of established code bases and
>> IT infrastructures. But we have to make them believe that
>> Smalltalk can cut their development time in half, if not better.
>>
>> What is it worth to a company to cut their development time in half?
>> It means much lower development cost. It means much shorter
>> "time to market."
>>
>
> It also means much lower error rates. Capers Jones also review errors /
> lines of code and Smalltalk was substantially better than the C derivative
> languages. I don't recall the ration, but I think the Namcook report does
> include it.
>
> Fewer errors means a higher ratio of time spent delivering functionality
> and a better customer experience. (We can't do anything about bad design
> and UX practices, of course and unfortunately. Although, I suspect without
> evidence that Smalltalkers may do a better job of both.)
>
>
>> Is this not worth investing time and energy in Smalltalk? Even if the
>> job opportunities aren't there. Even if it means overhauling your
>> IT infrastructure.
>>
>> The investment can lead to more users and more jobs. If they don't
>> believe it, then we have failed.
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
>>





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

Reply | Threaded
Open this post in threaded view
|

Re: Why Smalltalk is so easy to evangelize

Offray Vladimir Luna Cárdenas-2
In reply to this post by horrido

On 10/01/20 1:52 p. m., horrido wrote:

> Offray Vladimir Luna Cárdenas-2 wrote
>> But I have not
>> being able to convince any of my coder friends to switch to Pharo
>> instead of C++, Java or Javacript, which by the way, is the language
>> they already know and use to put bread on the table on a daily basis.
>>
>> So I think that we deal with a paradox: while Smalltalk advocacy is
>> better suited for a Blue Ocean Strategy[2], exploring and implementing
>> new/emerging scenarios and markets, money is already mostly invested in
>> Red Oceans of constituted technologies and practices ecosystems.
>> Bridging both is pretty difficult.
> Yes, that is the principal obstacle and challenge. When I'm pushing
> Smalltalk, I mention the language's simplicity and conciseness, I
> mention the purity of the object-oriented model, I mention the
> built-in IDE, and so on. But the key advantage that I emphasize
> is *programmer productivity*.
>
> I realize it's hard to argue with the availability of jobs for Java, Python,
> JavaScript, etc. It's hard to argue with their rich ecosystems. It's
> hard to argue with the status quo of established code bases and
> IT infrastructures. But we have to make them believe that
> Smalltalk can cut their development time in half, if not better.
>
> What is it worth to a company to cut their development time in half?
> It means much lower development cost. It means much shorter
> "time to market."
>
> Is this not worth investing time and energy in Smalltalk? Even if the
> job opportunities aren't there. Even if it means overhauling your
> IT infrastructure.
>
> The investment can lead to more users and more jobs. If they don't
> believe it, then we have failed.
>
I have invested time and energy in Smalltalk. Since 2014 I have
organized 500+ hours of workshops and hackathons which lead us to our
local success story [1].

[1]
https://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/success-story.md

But, from that experience, I see pretty difficult that coders which are
already using other languages and frameworks for their daily jobs, use
Pharo/Smalltalk when precisely their jobs is to maintain and extend the
stuff that they are already using. I have had better experience with non
coders (i.e: librarians, journalists and so on), presenting such "new"
ideas and practices. Grafoscopio is suited at non-coders that don't mind
to code or are curious about coding, but they need to intertwine code
with prose, data and visualization.

I think that a place where coders and non-coders can meet is at Blue
Ocean places (that's why I'm starting to explore Scuttlebutt protocol).
Can we start to find such blue oceans to explore together in a playful
and practical sense, where we can showcase the advantages of
Pharo/Smalltalk ? That could be a pretty good advocacy.

Cheers,

Offray





Reply | Threaded
Open this post in threaded view
|

Re: Why Smalltalk is so easy to evangelize

Richard O'Keefe
In reply to this post by itlists@schrievkrom.de
I wonder how many people in this thread have VisualWorks and/or
VisualAge on their machine as well as Pharo?  They haven't pushed the
user interface the way Squeak and Pharo have, and I personally find
the VisualAge interface to be unpleasant.  But they both offer a ton
of support for connecting to other things.
Let's take this list:
 - lots of good communication libraries into it
yes and yes
 - spread it over Windows, Mac and Linux,
yes and yes
 - make it open source
VW and VA are proprietary, but you can get free versions (if you think
I can afford to pay for
stuff you are sadly mistaken) with all the usual access to the sources.
  - put some XML and JSON
yes and yes
 - and solve printing,
not quite clear, but I think the answer is yes and yes
 - multithreading/multiprocessing (framework) runtime AND (!) debugging,
VW has recently made a lot of progress in that area
- scripting
it is not clear what you want here.
- interconnections with other languages.
yes and yes.  C, and VA also talks to COBOL nicely.
- Try adding a modelling and source code generator
VW: very much so.  VA: I have a lot of exploring to do yet, but I think so.
- Build the whole stuff with concurrency in
mind - offer specific data structure to help you here.
Not clear what you want here.  Smalltalk has had threads since at least 1980.
If you built the whole stuff with concurrency in mind, you would not end up
with Smalltalk, you'd get Erlang/Elixir.   My Smalltalk has concurrent stacks,
sets, bags, and dictionaries, and 'aCollection par
collect:/select:/inject:into:/...'
- Look for suitable persistency options.
VW and VA both support serialisation.  Pharo of course has Fuel.

The big thing that VW and VA offer that Pharo does not -- for obvious reasons --
is stability, with the quantity of documentation that stability makes possible.



On Sat, 11 Jan 2020 at 05:15, Marten Feldtmann <[hidden email]> wrote:

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

12