Re: [Pharo-users] Smalltalk Argument

[Andrew Glynn]

Engineers don’t innovate often in core technologies, because they’re careful.  

Of course that also means they generally make terrible marketers .  

They also don’t generally compete, which is part of the problem in this 
industry.  The semiconductor industry, for instance, provides money to an 
independent institute, ISMI, that advances the core technologies they all use.

We do love shiny new toys though, that’s half the reason we became engineers.

You don’t ‘need’ an image by any means, but the fact that my live coding 
environments in Eclipse have been running, hiding behind modal dialogs, for 
332, 468, and 992 hours respectively, due to constantly comparison between 
in-memory data and on-disk data combined with a crappy eventing model, implies 
that it’s at the very least much easier.  Granted they’re building parts of a 
huge program, an ERP, and using JPA with it.  Still, I have 3  Eclipse 
environments on 3 Sun servers with 64 threads each that have been untouchable 
for many days. 

Smalltalk is ‘a’ way, a way that doesn’t have the massive discrepancies between 
its syntactical appearance and dynamic implementation that C++ and Java suffer 
from, discrepancies that dynamically propagate depending on different 
libraries, frameworks, internal system states and external environments.

Python is another way, it has plenty of strengths.  Its weakness is that it 
doesn’t scale in terms of either data size or complexity.  Odoo is a great 
case, most usable ERP out there for the end user, but if you try to run more 
than a few of the 40 odd modules it craps out.  Largely that’s lack of time or 
investment, if you haven’t the latter, you need the former.  IMO Python is 
closer to Smalltalk than GNU Smalltalk.  

But why compete?  Where Python has strengths I use it, where there are 
reliable, stable technologies in Java I use them (Synapse and JINI are two main 
ones).  If I have to do work in a browser I have to write JS, I just don’t try 
to do things it’s not reliably capable of.  If I’m using ACT-R for modeling, I 
use LISP, for Wordnet I use Prolog.  

Writing any language in another, especially a language like C, is not going to 
work well in the long term, because while writing the language, one can’t be in 
that language’s proper mindset.  As a result Ruby looks like Smalltalk but 
works like Java, except a Java without the massive investment that make actual 
Java somewhat reliable.  

Funny you mentioned Alan Kay, given I had a disagreement with him last night. 
His argument was that we need to think beyond Smalltalk, beyond anything out 
there at the moment. My argument was that we haven’t yet caught up to 
Smalltalk, never mind LISP, and that despite nearly everything we use having 
originated in those, most don’t even recognize it. We’re nowhere near ready for 
a new paradigm when we haven’t digested the old one yet.  

It was a polite disagreement. Nevertheless, AFAIK only God is God, and I don’t 
speak with him personally all that regularly .

Pharo is far from the Smallltalk I began with in ’88.  Morphic is well beyond 
MVC and the improvements to it, combined with the things built on it, are keys 
to why I use Pharo. The JIT compiler is a another big improvement, which 
originated with Strongtalk - the PoC for the Java JIT compiler written by Sun.  

But when my first language, Forth, is still better than 90% of the ‘new’ 
languages out there, using those new languages as core technologies is 
problematic.  

New is better only if its actually better.

Andrew







Sent from Mail for Windows 10

From: Dimitris Chloupis
Sent: Monday, November 6, 2017 5:29 AM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument

all people like popular choices, including engineers.

Engineers may be more careful but they are not known exactly for their talent 
to innovate. 

We are pact animals, we are social animals. 

This is far from a coding problem, its pretty much coded right inside our DNA, 
not just for us but also for any other animal.

And we have our trends too, our resistance to git is an excellent example. A 
general fixation of avoiding files and especially text files. The unreasonable 
argument that you need an image to preserve a live coding enviroment. The idea 
that just because you have access to the complete source code , life becomes 
easier for some weird way as if people are likely to mess with the internals of 
a system. That for some weird reason you cannot have access to source code in 
other languages or that is hard to do so. The notion that live coding is only 
possible or only easy in Smalltalk. That reimplementing everything in Smalltalk 
is a great idea. That minimal syntax equals softer learning curve. That 
Smalltalk is the only sensible way of doing OOP. 

Finally but not least, "Alan Kay is god".  

People love to stick to their beliefs (me included) and not feel comfortable 
questioning them. It's no surpise it tooks us

Re: [Pharo-users] Smalltalk Argument

[Hans N Beck]

want your next flight to be on an aircraft running on JavaScript?  
>> I wouldn’t eat from a microwave running JavaScript. 
>> 
>>  
>> 
>> I’d rather be an engineer than a popularity contestant or a fashion victim.
>> 
>>  
>> 
>> In any case, more often than not it’s management that chooses technologies, 
>> generally based on who they have lunch with more than anything else. 
>> 
>>  
>> 
>> Andrew
>> 
>>  
>> 
>> Sent from Mail for Windows 10
>> 
>>  
>> 
>> From: Dimitris Chloupis
>> Sent: Monday, November 6, 2017 2:35 AM
>> 
>> 
>> To: Any question about pharo is welcome
>> Subject: Re: [Pharo-users] Smalltalk Argument
>> 
>>  
>> 
>> Another way of promoting Pharo is copying its advantages to other languages. 
>> The ideal way is for people to get straight to Pharo and fall in love with 
>> it. But sometimes this may be possible for several reasons. The most usual 
>> being that people simple are not in the mood of learning a new language 
>> unless they have to. As the saying goes "People love progress , its just 
>> that they equally hate change"
>> 
>>  
>> 
>> Introducing similar features to another language, like I did with 
>> introducing live coding enviroment to Python with direct reference back to 
>> Pharo is a very good way to promote the language. Just because you cannot 
>> code in Pharo at your work does not mean you cannot code the Pharo way. Just 
>> put a huge tag in your documentation, comments and anywhere you mention your 
>> code "inspired by Pharo ( https://pharo.org)" and you will get their 
>> attention whether they like the idea of learning a new language or not. 
>> 
>>  
>> 
>> Its like watching an ad, using sex, humour and even unrelated stuff to grab 
>> your attention to a product. The idea here is to get the attention, once you 
>> do that, the rest follows. 
>> 
>>  
>> 
>> A huge problem with Smalltalk in general is that even though every language, 
>> enviroment, tool, IDE has been copying it , it is rarely mentioned. If it 
>> did , I have no doubt it would have been masively more popular than it is 
>> right now. 
>> 
>>  
>> 
>> On Mon, Nov 6, 2017 at 9:22 AM jtuc...@objektfabrik.de 
>> <jtuc...@objektfabrik.de> wrote:
>> 
>> 
>> Phil,
>> 
>> Am 26.10.17 um 08:17 schrieb p...@highoctane.be:
>> >
>> >
>> > Now we miss the boat on mobile and bigdata, but this is solvable.
>> 
>> You know, "It's solvable, and it's even easy in Smalltalk" has been what
>> we've been shouting down at those worms in the C++/Java swamp for
>> decades. We just never really proved it. We also missed the boat on web.
>> Seaside was the last real innovation in that field, almost 15 years ago.
>> When Javascript took over the frontend, we lost pace.
>> 
>> >
>> > If we had an open Java bridge (and some people in the community have
>> > it for Pharo but do not open source it - so this is eminently doable)
>> > + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big
>> > executable we would have a way to embed Pharo in a lot of places (e.g.
>> > in the Hadoop ecosystem where fast starting VMs and small footprint
>> > would make the cluster capacity x2 or x3 vs uberjars all over the
>> > place)  this would be a real disruption.
>> 
>> To it sounds like a big ball of mud to me, but that is opinion ;-)
>> 
>> >
>> > Think about being able to call Pharo from JNA
>> > https://github.com/java-native-access/jna the same way we use C with UFFI.
>> >
>> > Smalltalk argument for me is that it makes development bearable (even
>> > fun and enjoyable would I say) vs the other stacks. That matters.
>> >
>> Yep. As long as there is no mobile, web or big data involved ;-) To me
>> that is not enough for convincing project managers these days, because
>> web, mobile and big data as well ass AI (oh, is that probably no. 4 on
>> our list of missed boats?) are the topics of what we consider
>> future-proof projects... I am not only dissing the Pharo community here,
>> this is a problem for all Smalltalk vendors in my opinion.
>> 
>> 
>> Joachim
>> 
>> 
>> 
>> --
>> ---
>> Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
>> 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
>> 
>> 
>>  

Re: [Pharo-users] Smalltalk Argument

[Dimitris Chloupis]

all people like popular choices, including engineers.

Engineers may be more careful but they are not known exactly for their
talent to innovate.

We are pact animals, we are social animals.

This is far from a coding problem, its pretty much coded right inside our
DNA, not just for us but also for any other animal.

And we have our trends too, our resistance to git is an excellent example.
A general fixation of avoiding files and especially text files. The
unreasonable argument that you need an image to preserve a live coding
enviroment. The idea that just because you have access to the complete
source code , life becomes easier for some weird way as if people are
likely to mess with the internals of a system. That for some weird reason
you cannot have access to source code in other languages or that is hard to
do so. The notion that live coding is only possible or only easy in
Smalltalk. That reimplementing everything in Smalltalk is a great idea.
That minimal syntax equals softer learning curve. That Smalltalk is the
only sensible way of doing OOP.

Finally but not least, "Alan Kay is god".

People love to stick to their beliefs (me included) and not feel
comfortable questioning them. It's no surpise it tooks us hundrends of
thousands of years to get to this point.

JS is chosen as a language for the same reason its so hated, its third
party libraries. As coders we have to rely a lot more to libraries than we
have to rely on languages. Sure a language can solve many potential problem
but a powerful library support can practically give you code on a plate.
Hence also why JS is practically non existant outside web dev and that is
pretty rare for a language.

So sure popularity plays a major role but in the end the preference for JS
is not insanity, its the right choice for what it focuses on. A difficult/
not that well designed language + big library support will always be easier
to use than a super ease elegant language without such big library support.
The time when we were relying on our code and our own libraries has passed
long time ago.



On Mon, Nov 6, 2017 at 10:37 AM Andrew Glynn <aglyn...@gmail.com> wrote:

> Btw, I think we gained *pace* when JS took over the front end, but lost
> visibility.  Nothing is slower than coding a client/server app with the
> front end in JS. The ‘rise’ of JS is a side effect of the fact that the web
> was designed, built and continues to be built by ‘coders’ who don’t know
> enough to be called amateurs.
>
>
>
> What puts 'coders’ off though is related to way JS is and (mostly doesn’t)
> work.  You can’t just sit down and ‘hack on’ Smalltalk until it ‘sorta
> kinda’ does what you want.  You can’t grab code from some random website
> and ‘fiddle with it’ until it ‘sorta kinda’ works. ‘Coders’ *can’t* make
> it ‘sorta kinda’ work, and they don’t know how to *write* code that works.
>
>
>
> One of the better JS programmers I’ve worked with said at one point
> “Engineers can’t write JavaScript because it doesn’t fit their mentality.
> I used to be a retoucher, I’d spend hours and hours getting one pixel
> right.  There’s no good reason that one pixel had to be that way, but the
> image didn’t ‘go’ otherwise. JavaScript is like that, you spend hours and
> hours messing with it, getting it to work, and at the end you don’t know
> why it works, nor why it didn’t.  That’s not an engineer’s mindset.”
>
>
>
> Do aviation engineers choose tools based on ‘popularity’? At the same
> time, would you want your next flight to be on an aircraft running on
> JavaScript?  I wouldn’t eat from a microwave running JavaScript.
>
>
>
> I’d rather be an engineer than a popularity contestant or a fashion victim.
>
>
>
> In any case, more often than not it’s management that chooses
> technologies, generally based on who they have lunch with more than
> anything else.
>
>
>
> Andrew
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Dimitris Chloupis <kilon.al...@gmail.com>
> *Sent: *Monday, November 6, 2017 2:35 AM
>
>
> *To: *Any question about pharo is welcome <pharo-users@lists.pharo.org>
> *Subject: *Re: [Pharo-users] Smalltalk Argument
>
>
>
> Another way of promoting Pharo is copying its advantages to other
> languages. The ideal way is for people to get straight to Pharo and fall in
> love with it. But sometimes this may be possible for several reasons. The
> most usual being that people simple are not in the mood of learning a new
> language unless they have to. As the saying goes "People love progress ,
> its just that they equally hate change"
>
>
>
> Introducing similar features to another language, like I did with
> introducing live coding enviroment to Python with direct r

Re: [Pharo-users] Smalltalk Argument

[Andrew Glynn]

Btw, I think we gained pace when JS took over the front end, but lost 
visibility.  Nothing is slower than coding a client/server app with the front 
end in JS. The ‘rise’ of JS is a side effect of the fact that the web was 
designed, built and continues to be built by ‘coders’ who don’t know enough to 
be called amateurs.

What puts 'coders’ off though is related to way JS is and (mostly doesn’t) 
work.  You can’t just sit down and ‘hack on’ Smalltalk until it ‘sorta kinda’ 
does what you want.  You can’t grab code from some random website and ‘fiddle 
with it’ until it ‘sorta kinda’ works. ‘Coders’ can’t make it ‘sorta kinda’ 
work, and they don’t know how to write code that works.

One of the better JS programmers I’ve worked with said at one point “Engineers 
can’t write JavaScript because it doesn’t fit their mentality.  I used to be a 
retoucher, I’d spend hours and hours getting one pixel right.  There’s no good 
reason that one pixel had to be that way, but the image didn’t ‘go’ otherwise. 
JavaScript is like that, you spend hours and hours messing with it, getting it 
to work, and at the end you don’t know why it works, nor why it didn’t.  That’s 
not an engineer’s mindset.”

Do aviation engineers choose tools based on ‘popularity’? At the same time, 
would you want your next flight to be on an aircraft running on JavaScript?  I 
wouldn’t eat from a microwave running JavaScript.  

I’d rather be an engineer than a popularity contestant or a fashion victim.

In any case, more often than not it’s management that chooses technologies, 
generally based on who they have lunch with more than anything else.  

Andrew

Sent from Mail for Windows 10

From: Dimitris Chloupis
Sent: Monday, November 6, 2017 2:35 AM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument

Another way of promoting Pharo is copying its advantages to other languages. 
The ideal way is for people to get straight to Pharo and fall in love with it. 
But sometimes this may be possible for several reasons. The most usual being 
that people simple are not in the mood of learning a new language unless they 
have to. As the saying goes "People love progress , its just that they equally 
hate change"

Introducing similar features to another language, like I did with introducing 
live coding enviroment to Python with direct reference back to Pharo is a very 
good way to promote the language. Just because you cannot code in Pharo at your 
work does not mean you cannot code the Pharo way. Just put a huge tag in your 
documentation, comments and anywhere you mention your code "inspired by Pharo ( 
https://pharo.org)" and you will get their attention whether they like the idea 
of learning a new language or not. 

Its like watching an ad, using sex, humour and even unrelated stuff to grab 
your attention to a product. The idea here is to get the attention, once you do 
that, the rest follows. 

A huge problem with Smalltalk in general is that even though every language, 
enviroment, tool, IDE has been copying it , it is rarely mentioned. If it did , 
I have no doubt it would have been masively more popular than it is right now. 

On Mon, Nov 6, 2017 at 9:22 AM jtuc...@objektfabrik.de 
<jtuc...@objektfabrik.de> wrote:

Phil,

Am 26.10.17 um 08:17 schrieb p...@highoctane.be:
>
>
> Now we miss the boat on mobile and bigdata, but this is solvable.

You know, "It's solvable, and it's even easy in Smalltalk" has been what
we've been shouting down at those worms in the C++/Java swamp for
decades. We just never really proved it. We also missed the boat on web.
Seaside was the last real innovation in that field, almost 15 years ago.
When Javascript took over the frontend, we lost pace.

>
> If we had an open Java bridge (and some people in the community have
> it for Pharo but do not open source it - so this is eminently doable)
> + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big
> executable we would have a way to embed Pharo in a lot of places (e.g.
> in the Hadoop ecosystem where fast starting VMs and small footprint
> would make the cluster capacity x2 or x3 vs uberjars all over the
> place)  this would be a real disruption.

To it sounds like a big ball of mud to me, but that is opinion ;-)

>
> Think about being able to call Pharo from JNA
> https://github.com/java-native-access/jna the same way we use C with UFFI.
>
> Smalltalk argument for me is that it makes development bearable (even
> fun and enjoyable would I say) vs the other stacks. That matters.
>
Yep. As long as there is no mobile, web or big data involved ;-) To me
that is not enough for convincing project managers these days, because
web, mobile and big data as well ass AI (oh, is that probably no. 4 on
our list of missed boats?) are the topics of what we consider
future-proof projects... I am not only dissing the 

Re: [Pharo-users] Smalltalk Argument

[Dimitris Chloupis]

Another way of promoting Pharo is copying its advantages to other
languages. The ideal way is for people to get straight to Pharo and fall in
love with it. But sometimes this may be possible for several reasons. The
most usual being that people simple are not in the mood of learning a new
language unless they have to. As the saying goes "People love progress ,
its just that they equally hate change"

Introducing similar features to another language, like I did with
introducing live coding enviroment to Python with direct reference back to
Pharo is a very good way to promote the language. Just because you cannot
code in Pharo at your work does not mean you cannot code the Pharo way.
Just put a huge tag in your documentation, comments and anywhere you
mention your code "inspired by Pharo ( https://pharo.org)" and you will get
their attention whether they like the idea of learning a new language or
not.

Its like watching an ad, using sex, humour and even unrelated stuff to grab
your attention to a product. The idea here is to get the attention, once
you do that, the rest follows.

A huge problem with Smalltalk in general is that even though every
language, enviroment, tool, IDE has been copying it , it is rarely
mentioned. If it did , I have no doubt it would have been masively more
popular than it is right now.

On Mon, Nov 6, 2017 at 9:22 AM jtuc...@objektfabrik.de <
jtuc...@objektfabrik.de> wrote:

>
> Phil,
>
> Am 26.10.17 um 08:17 schrieb p...@highoctane.be:
> >
> >
> > Now we miss the boat on mobile and bigdata, but this is solvable.
>
> You know, "It's solvable, and it's even easy in Smalltalk" has been what
> we've been shouting down at those worms in the C++/Java swamp for
> decades. We just never really proved it. We also missed the boat on web.
> Seaside was the last real innovation in that field, almost 15 years ago.
> When Javascript took over the frontend, we lost pace.
>
> >
> > If we had an open Java bridge (and some people in the community have
> > it for Pharo but do not open source it - so this is eminently doable)
> > + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big
> > executable we would have a way to embed Pharo in a lot of places (e.g.
> > in the Hadoop ecosystem where fast starting VMs and small footprint
> > would make the cluster capacity x2 or x3 vs uberjars all over the
> > place)  this would be a real disruption.
>
> To it sounds like a big ball of mud to me, but that is opinion ;-)
>
> >
> > Think about being able to call Pharo from JNA
> > https://github.com/java-native-access/jna the same way we use C with
> UFFI.
> >
> > Smalltalk argument for me is that it makes development bearable (even
> > fun and enjoyable would I say) vs the other stacks. That matters.
> >
> Yep. As long as there is no mobile, web or big data involved ;-) To me
> that is not enough for convincing project managers these days, because
> web, mobile and big data as well ass AI (oh, is that probably no. 4 on
> our list of missed boats?) are the topics of what we consider
> future-proof projects... I am not only dissing the Pharo community here,
> this is a problem for all Smalltalk vendors in my opinion.
>
>
> Joachim
>
>
>
> --
> ---
> Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
> 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
>
>
>

Re: [Pharo-users] Smalltalk Argument

[jtuc...@objektfabrik.de]

Peter,

our mail provider decided to move all of the pharo mailing list messages 
to the spam folder, so I haven't seen many messages in the last days. I 
was already starting to wonder why nobody ever answered my posts ;-)


Your smalltalk express idea sounds interesting. I look forward to trying 
it.



Joachim


Am 20.10.17 um 16:21 schrieb Peter Fisk:

Thank you Joachim!

That is the most honest assessment of the situation of Smalltalk in 
2017 that I have ever seen.


And I agree with you 100%.

We need a new Smalltalk which is both "cool" and can seamlessly 
integrate with all of the latest web technologies.


I will be releasing a new Smalltalk framework very shortly called 
"Smalltalk Express".


The interpreter is written in the "Go" language and can run on all of 
the major web platforms such as Google, Heroku, etc.


I use Pharo to manage the Smalltalk code.

Here is a new blog that I have started to discuss the project.

https://smalltalkexpress.quora.com/

Also, I have reserved the web address "smalltalk.express" for use once 
the code goes live.


There is a video in the blog post so you can get an idea of where 
things stand right now.


-- Peter





On Fri, Oct 20, 2017 at 3:23 AM, jtuc...@objektfabrik.de 
 > wrote:


First of all: I'd say the question itself is not a question but an
excuse. I am not arguing there are enough Smalltalkers or cheap
ones. But I think the question is just a way of saying "we don't
want to do it for reasons that we ourselves cannot really
express". If you are a good developer, learning Smalltalk is easy.
If you are a good developer you've heard the sentence "we've taken
the goos parts from x,y,z and Smalltalk" at least twice a year. So
you most likely would like to learn it anyways.

A shortage of developers doesn't exist. What exists is an
unwillingness of companies to get people trained in a technology.
If Smalltalk was cool and great in their opinion, they wouldn't
care. It's that simple. As a consultant, I've heard that argument
so often. Not ferom Startups, but from insurance companies, Banks
or Car manufacturers who spend millions on useless, endless
meetings and stuff instead of just hiring somebody to teach a
couple of developers Smalltalk. It's just a lie: the shortage of
Smalltalk developers is not a problem.

And, to be honest: what is it we actually are better in by using
Smalltalk?
Can we build cool looking web apps in extremely short time? No.
Can we build mobile Apps with little effort? No.
Does our Smalltalk ship lots of great libraries for all kinds of
things that are not availabel in similar quality in any other
language?
Are we lying when we say we are so extremely over-productive as
compared to other languages?

I know, all that live debugging stuff and such is great and it is
much faster to find & fix a bug in Smalltalk than in any other
environment I've used so far. But that is really only true for
business code. When I need to connect to things or want to build a
modern GUI or a web application with a great look, I am
nowhere near productive, because I simply have to build my own
stuff or learn how to use other external resources. If I want to
build something for a mobile device, I will only hear that
somebody somewhere has done it before. No docs, no proof, no
ready-made tool for me.


Shortage of developers is not really the problem. If Smalltalk was
as cool as we like to make ourselves believe, this problem would
be non-existent. If somebody took out their iPad and told an
audience: "We did this in Smalltalk in 40% of the time it would
have taken in Swift", and if that something was a must-have for
people, things would be much easier. But nobody has.


I am absolutely over-exaggerating, because I make my living with
an SaaS product written in Smalltalk (not Pharo). I have lots of
fun with Smalltalk and - as you - am convince that many parts of
what we've done so far would've taken much longer or even be
impossible in other languages. But the advantage was eaten by our
extremely steep learning curve for web technologies and for
building something that works almost as well as tools like Angular
or jQuery Mobile.

Smalltalk is cool, and the day somebody shows me something like
Google's flutter in Smalltalk, I am ready to bet a lot on a bright
future for Smalltalk. But until then, I'd say these arguments
about productivity are just us trying to make ourselves believe
we're still the top of the food chain. We've done that for almost
thirty years now and still aren't ready to stop it. But we've been
lying to ourselves and still do so.

I don't think there is a point in discussing about the usefulness
of a language using 

Re: [Pharo-users] Smalltalk Argument

[Hans]

Hi all, 

an argument for Smalltalk, an discussion coming up many times in my history.
It is also something I'm asking myself from time to time. It is very actual
in the moment. 

Many good arguments were mentioned this discussion. I want to provide you my
2 cents on this.

First, I'm taking the view of an hobby enthusiast. That's were I started.
All the time I was excited by the Smalltalk concept. Live debugging, VM
system, the possibility to look at and understand every code from systems
completely new to me was so great. No installation, and nice people in the
community. Conclusion: I want to do all in Smalltalk. Elegance is what rules
only.

Now, I'm in the perspective of an employed software developer. Everywhere
that crazy C++, sometimes Fortran or C. Delphi.  The people told "that's
old, that was the beginning years ago, that is given,  we have nothing
else". And we have no time to redesign or port to something better, so fate
catched us and we have to continue on the road to hell. Most of my life
colleagues were physicists who learned C++ for its thesis, or engineers of
the embedded domain. No or only a few computer scientists. The rule now on
these days: get ready, it should work somehow, costs. Elegance or sound
design is no value. Not at this time.  SW is just a part of my component as
any screw and nail too.

Continuing as a team leader. My goal is to fit budget. I have some time, and
I have some people in the team. And I have to report and sell to my manager
above me. I'm looking for get the job done, but I have also some strategic
view. I've read some articles about this new .Net, with big potential, many
libraries. Easy Web. Web is the future. I ask my team how to solve the task.
Ony guy talks about Pearl. I hat Pearl. Another colleagues tells something
about Smalltalk. Never heared of it, I ask if this is compatible to .Net
My rules of success are in what I belief - and what can I sell to my big
boss. And I belief only what I see...


I could continue this. My point is: the Smalltalk Argument is depending on
the perspective. And therefore, to communicate and argue about Smalltalk is
what the receiver of the argument needs. Superiour technique can be an
argument, but not always. Missing developer can be an argument, but not in
every company and every project. 

My personal conclusion and look to Smalltalk is this: 

- for my soul which want to  bring science and technology to the future, I
look at the elegance and power of Smalltalk. That's why I'm looking at
TeaTime and OpenCroquet again in the age of AR.
- if I want to learn from top coders, the way of developing in Smalltalk
(live debugging)
- if I want to get a job done (for example a web site), I'm looking what the
world offers me. And it may not be Smalltalk. In my current work, Game
Engines matter. So coding a Game Engine in Smalltalk ? May be, but there are
a lot of good products already...

Having said that, the Smalltalk Argument has to sides, and they have both
their value:
- Smalltalk as an technique, as a matter of research and getting things
better, an philosophy
- Smalltalk as a product for people who want things get done. 

My personal opinion is that sometimes the point Smalltalk (or better now:
Pharo) as a product is not so much in concern as it could. Pharo evolved
wonderfully, the consortium and the organisation and the community have the
right direction, yes. But as an industrial user of software I only can hope:
keep the Smalltalk as a Product in the same focus as Smalltalk as the better
technology. And product means: look at the needs the product is indented
for, look at the "market". What are the problems out there ? If you can fit
the needs, and provide a productive and integrable technology, you need no
argument for Smalltalk.

Off topic: thanks for the big effort of the community, it is really really
fun today to work on and with Pharo. Much happend, and much is possible ;)

Cheers

Hans




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

Re: [Pharo-users] Smalltalk Argument

[Offray Vladimir Luna Cárdenas]

Read the User Manual [1] to install it and learn the basics of its
workings. Once you have created your first document or hit the first
bump, ask on this list. I will be around ;-).

[1]
http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Manual/manual.pdf

Cheers,

Offray

On 29/10/17 17:00, henry wrote:
> How could I get started documenting my components with Grafoscopio? I
> am interested in learning.
>
> I just got ASN.1 lengths right, in Java. I am looking to Pharo and
> Java with an encrypted connection between them.
>
>
> - HH
>
>
> On Sun, Oct 29, 2017 at 16:59, Offray Vladimir Luna Cárdenas
> > wrote:
>
> Well is more "build and they will come, if you build also a
> community who will come", which is hard, but data storytelling and
> visualization as filed and dynamic moldable tools give us a
> advantage point to tackle such hard problems.
>
> Cheers,
>
> Offray
>
>
> On 29/10/17 13:13, henry wrote:
>
> I have heard this summarized by the term: "build it and they
> will come". I think the data visualization aspect is where
> Pharo entering BigData space could really payoff. That comes
> down to data manipulation. Can Pharo read Avro?
>
> - HH
>
>
> On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna Cárdenas <
> offray.l...@mutabit.com
> <%22mailto:offray.l...@mutabit.com%22>> wrote:
>
> Thanks a lot Paulo for starting this thread and all the
> participants for the clever and enlightening answers. I
> just want to add my two cents. On 26/10/17 07:53, Dimitris
> Chloupis wrote: > > My personal opinion is that as
> pessimistic it may sound, Smalltalk has > very little to
> offer in the library front. The language is still >
> stellar and live environment is a great concept but from
> there on > there is a decline. Sure if your are low demand
> kind of person on the > library front and dont mind
> implementing stuff by yourself you wont > mind the lack of
> libraries but most coders , me included , dont have > this
> luxury. Especially making a living with a language is a >
> completely different story from learning it as a hobby,  >
> > I think and that’s a personal opinion, that Smalltalk
> goes the wrong > direction. It tries to be a do it all
> language, but we already have an > army of do it all
> languages. I think it would excel as the backbone in > big
> complex projects. Like the Moose project is doing with
> code > analysis and visualization. I think this is an
> excellent direction to > go with Smalltalk. Reflection is
> the big strength of Smalltalk the > ability to communicate
> with its code in a direct matter. So I think > that a
> Smalltalk implementation that can analyze and visualize
> code > written in other languages would have been a pretty
> serious reason for > people to learn Smalltalk.  > > I am
> very happy to see Pharo go towards that direction and yes
> I would > definitely recommend it without hesitation  for
> code analysis and > project management tool. Its no
> coincidence that we have seen a > serious growth in our
> community. When I joined back in 2011 we all > were
> posting at pharo-dev, pharo-users was a dead zone and then
> the > community grow larger and larger we soon may need a
> third mailing list.  > > Code complexity is an issues for
> all large projects and tools that > help manage this
> without having to convert to another language are > very
> popular. About finding  niche where you can learn Pharo
> and make a living from it, I think that I may be behind a
> sweet spot in the field of reproducible research and data
> storytelling and visualization, for different fields like
> activism, journalism, science and engineering. I’m
> "working in my PhD", so I don’t get paid for using Pharo &
> friends (well if fact I’m in a loan to finish my PhD), but
> using Pharo have allowed my to get more dynamic results
> that with previous technologies (mostly Python and Web
> ones). By being able to prototype quickly I have improved
> my research experience and results, which is a way to
> improve research (self) funding. Also, activists,
> journalist, researchers and other novices interested in
> data storytelling and visualization, care little about
> popularity of the language or being able to make apps
> 

Re: [Pharo-users] Smalltalk Argument

[henry]

Interesting. Very.

Thank you.

- HH

On Sun, Oct 29, 2017 at 17:17, p...@highoctane.be 
<[p...@highoctane.be]("mailto:p...@highoctane.be;)> wrote:

> Pharo can read Avro when this will be UFFI'ed
>
> [https://avro.apache.org/docs/1.7.3/api/c/index.html]("https://avro.apache.org/docs/1.7.3/api/c/index.html;)
>
> But that is eminently doable.
>
> Phiil
>
> On Sun, Oct 29, 2017 at 7:13 PM, henry 
> <[he...@callistohouse.club]("mailto:he...@callistohouse.club;)> wrote:
>
>> I have heard this summarized by the term: "build it and they will come". I 
>> think the data visualization aspect is where Pharo entering BigData space 
>> could really payoff. That comes down to data manipulation. Can Pharo read 
>> Avro?
>>
>> - HH
>>
>> On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna Cárdenas 
>> <[offray.l...@mutabit.com]("mailto:offray.l...@mutabit.com;)> wrote:
>>
>>> Thanks a lot Paulo for starting this thread and all the participants for 
>>> the clever and enlightening answers. I just want to add my two cents. On 
>>> 26/10/17 07:53, Dimitris Chloupis wrote: > > My personal opinion is that as 
>>> pessimistic it may sound, Smalltalk has > very little to offer in the 
>>> library front. The language is still > stellar and live environment is a 
>>> great concept but from there on > there is a decline. Sure if your are low 
>>> demand kind of person on the > library front and dont mind implementing 
>>> stuff by yourself you wont > mind the lack of libraries but most coders , 
>>> me included , dont have > this luxury. Especially making a living with a 
>>> language is a > completely different story from learning it as a hobby,  > 
>>> > I think and that's a personal opinion, that Smalltalk goes the wrong > 
>>> direction. It tries to be a do it all language, but we already have an > 
>>> army of do it all languages. I think it would excel as the backbone in > 
>>> big complex projects. Like the Moose project is doing with code > analysis 
>>> and visualization. I think this is an excellent direction to > go with 
>>> Smalltalk. Reflection is the big strength of Smalltalk the > ability to 
>>> communicate with its code in a direct matter. So I think > that a Smalltalk 
>>> implementation that can analyze and visualize code > written in other 
>>> languages would have been a pretty serious reason for > people to learn 
>>> Smalltalk.  > > I am very happy to see Pharo go towards that direction and 
>>> yes I would > definitely recommend it without hesitation  for code analysis 
>>> and > project management tool. Its no coincidence that we have seen a > 
>>> serious growth in our community. When I joined back in 2011 we all > were 
>>> posting at pharo-dev, pharo-users was a dead zone and then the > community 
>>> grow larger and larger we soon may need a third mailing list.  > > Code 
>>> complexity is an issues for all large projects and tools that > help manage 
>>> this without having to convert to another language are > very popular. 
>>> About finding  niche where you can learn Pharo and make a living from it, I 
>>> think that I may be behind a sweet spot in the field of reproducible 
>>> research and data storytelling and visualization, for different fields like 
>>> activism, journalism, science and engineering. I'm "working in my PhD", so 
>>> I don't get paid for using Pharo & friends (well if fact I'm in a loan to 
>>> finish my PhD), but using Pharo have allowed my to get more dynamic results 
>>> that with previous technologies (mostly Python and Web ones). By being able 
>>> to prototype quickly I have improved my research experience and results, 
>>> which is a way to improve research (self) funding. Also, activists, 
>>> journalist, researchers and other novices interested in data storytelling 
>>> and visualization, care little about popularity of the language or being 
>>> able to make apps (mobile or web). What they care is about being able to 
>>> tell the story and Pharo, agile visualization and moldable tools, have a 
>>> lot to offer in this front. They're easy to learn and to adapt to fit the 
>>> needs of the problems behind those stories, as we have done with 
>>> Grafoscopio[1]. So, is nice to be part of a "trend", (data science, 
>>> reproducible research, data storytelling and data visualization) but not 
>>> being part of one that doesn't give you the freedom to use tools that 
>>> matter to you, because of the ideas they embody and the added value they 
>>> create for you and your community. [1] 
>>> [http://mutabit.com/grafoscopio/index.en.html]("http://mutabit.com/grafoscopio/index.en.html;)
>>>  Also, being in Latin America, means that we can bootstrap ourselves into 
>>> alternative futures by using alternative (digital) infrastructures and 
>>> tools, without to much worry about the deep investments in money and/or 
>>> expertise on bloated/popular technologies (we don't have such investments 
>>> here!). We can learn from the experience of the "Global North", without 
>>> 

Re: [Pharo-users] Smalltalk Argument

[henry]

How could I get started documenting my components with Grafoscopio? I am 
interested in learning.

I just got ASN.1 lengths right, in Java. I am looking to Pharo and Java with an 
encrypted connection between them.

- HH

On Sun, Oct 29, 2017 at 16:59, Offray Vladimir Luna Cárdenas 
<[offray.l...@mutabit.com]("mailto:offray.l...@mutabit.com;)> wrote:

> Well is more "build and they will come, if you build also a community who 
> will come", which is hard, but data storytelling and visualization as filed 
> and dynamic moldable tools give us a advantage point to tackle such hard 
> problems.
>
> Cheers,
>
> Offray
>
> On 29/10/17 13:13, henry wrote:
>
>> I have heard this summarized by the term: "build it and they will come". I 
>> think the data visualization aspect is where Pharo entering BigData space 
>> could really payoff. That comes down to data manipulation. Can Pharo read 
>> Avro?
>>
>> - HH
>>
>> On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna Cárdenas < 
>> [offray.l...@mutabit.com]("mailto:offray.l...@mutabit.com;)> wrote:
>>
>>> Thanks a lot Paulo for starting this thread and all the participants for 
>>> the clever and enlightening answers. I just want to add my two cents. On 
>>> 26/10/17 07:53, Dimitris Chloupis wrote: > > My personal opinion is that as 
>>> pessimistic it may sound, Smalltalk has > very little to offer in the 
>>> library front. The language is still > stellar and live environment is a 
>>> great concept but from there on > there is a decline. Sure if your are low 
>>> demand kind of person on the > library front and dont mind implementing 
>>> stuff by yourself you wont > mind the lack of libraries but most coders , 
>>> me included , dont have > this luxury. Especially making a living with a 
>>> language is a > completely different story from learning it as a hobby,  > 
>>> > I think and that’s a personal opinion, that Smalltalk goes the wrong > 
>>> direction. It tries to be a do it all language, but we already have an > 
>>> army of do it all languages. I think it would excel as the backbone in > 
>>> big complex projects. Like the Moose project is doing with code > analysis 
>>> and visualization. I think this is an excellent direction to > go with 
>>> Smalltalk. Reflection is the big strength of Smalltalk the > ability to 
>>> communicate with its code in a direct matter. So I think > that a Smalltalk 
>>> implementation that can analyze and visualize code > written in other 
>>> languages would have been a pretty serious reason for > people to learn 
>>> Smalltalk.  > > I am very happy to see Pharo go towards that direction and 
>>> yes I would > definitely recommend it without hesitation  for code analysis 
>>> and > project management tool. Its no coincidence that we have seen a > 
>>> serious growth in our community. When I joined back in 2011 we all > were 
>>> posting at pharo-dev, pharo-users was a dead zone and then the > community 
>>> grow larger and larger we soon may need a third mailing list.  > > Code 
>>> complexity is an issues for all large projects and tools that > help manage 
>>> this without having to convert to another language are > very popular. 
>>> About finding  niche where you can learn Pharo and make a living from it, I 
>>> think that I may be behind a sweet spot in the field of reproducible 
>>> research and data storytelling and visualization, for different fields like 
>>> activism, journalism, science and engineering. I’m "working in my PhD", so 
>>> I don’t get paid for using Pharo & friends (well if fact I’m in a loan to 
>>> finish my PhD), but using Pharo have allowed my to get more dynamic results 
>>> that with previous technologies (mostly Python and Web ones). By being able 
>>> to prototype quickly I have improved my research experience and results, 
>>> which is a way to improve research (self) funding. Also, activists, 
>>> journalist, researchers and other novices interested in data storytelling 
>>> and visualization, care little about popularity of the language or being 
>>> able to make apps (mobile or web). What they care is about being able to 
>>> tell the story and Pharo, agile visualization and moldable tools, have a 
>>> lot to offer in this front. They’re easy to learn and to adapt to fit the 
>>> needs of the problems behind those stories, as we have done with 
>>> Grafoscopio[1]. So, is nice to be part of a "trend", (data science, 
>>> reproducible research, data storytelling and data visualization) but not 
>>> being part of one that doesn’t give you the freedom to use tools that 
>>> matter to you, because of the ideas they embody and the added value they 
>>> create for you and your community. [1] 
>>> [http://mutabit.com/grafoscopio/index.en.html]("http://mutabit.com/grafoscopio/index.en.html;)
>>>  Also, being in Latin America, means that we can bootstrap ourselves into 
>>> alternative futures by using alternative (digital) infrastructures and 
>>> tools, without to much worry about the deep 

Re: [Pharo-users] Smalltalk Argument

[Offray Vladimir Luna Cárdenas]

Well is more "build and they will come, if you build also a community
who will come", which is hard, but data storytelling and visualization
as filed and dynamic moldable tools give us a advantage point to tackle
such hard problems.

Cheers,

Offray


On 29/10/17 13:13, henry wrote:
> I have heard this summarized by the term: "build it and they will
> come". I think the data visualization aspect is where Pharo entering
> BigData space could really payoff. That comes down to data
> manipulation. Can Pharo read Avro?
>
> - HH
>
>
> On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna Cárdenas
> > wrote:
>> Thanks a lot Paulo for starting this thread and all the participants
>> for the clever and enlightening answers. I just want to add my two
>> cents. On 26/10/17 07:53, Dimitris Chloupis wrote: > > My personal
>> opinion is that as pessimistic it may sound, Smalltalk has > very
>> little to offer in the library front. The language is still > stellar
>> and live environment is a great concept but from there on > there is
>> a decline. Sure if your are low demand kind of person on the >
>> library front and dont mind implementing stuff by yourself you wont >
>> mind the lack of libraries but most coders , me included , dont have
>> > this luxury. Especially making a living with a language is a >
>> completely different story from learning it as a hobby,  > > I think
>> and that's a personal opinion, that Smalltalk goes the wrong >
>> direction. It tries to be a do it all language, but we already have
>> an > army of do it all languages. I think it would excel as the
>> backbone in > big complex projects. Like the Moose project is doing
>> with code > analysis and visualization. I think this is an excellent
>> direction to > go with Smalltalk. Reflection is the big strength of
>> Smalltalk the > ability to communicate with its code in a direct
>> matter. So I think > that a Smalltalk implementation that can analyze
>> and visualize code > written in other languages would have been a
>> pretty serious reason for > people to learn Smalltalk.  > > I am very
>> happy to see Pharo go towards that direction and yes I would >
>> definitely recommend it without hesitation  for code analysis and >
>> project management tool. Its no coincidence that we have seen a >
>> serious growth in our community. When I joined back in 2011 we all >
>> were posting at pharo-dev, pharo-users was a dead zone and then the >
>> community grow larger and larger we soon may need a third mailing
>> list.  > > Code complexity is an issues for all large projects and
>> tools that > help manage this without having to convert to another
>> language are > very popular. About finding  niche where you can learn
>> Pharo and make a living from it, I think that I may be behind a sweet
>> spot in the field of reproducible research and data storytelling and
>> visualization, for different fields like activism, journalism,
>> science and engineering. I'm "working in my PhD", so I don't get paid
>> for using Pharo & friends (well if fact I'm in a loan to finish my
>> PhD), but using Pharo have allowed my to get more dynamic results
>> that with previous technologies (mostly Python and Web ones). By
>> being able to prototype quickly I have improved my research
>> experience and results, which is a way to improve research (self)
>> funding. Also, activists, journalist, researchers and other novices
>> interested in data storytelling and visualization, care little about
>> popularity of the language or being able to make apps (mobile or
>> web). What they care is about being able to tell the story and Pharo,
>> agile visualization and moldable tools, have a lot to offer in this
>> front. They're easy to learn and to adapt to fit the needs of the
>> problems behind those stories, as we have done with Grafoscopio[1].
>> So, is nice to be part of a "trend", (data science, reproducible
>> research, data storytelling and data visualization) but not being
>> part of one that doesn't give you the freedom to use tools that
>> matter to you, because of the ideas they embody and the added value
>> they create for you and your community. [1]
>> http://mutabit.com/grafoscopio/index.en.html Also, being in Latin
>> America, means that we can bootstrap ourselves into alternative
>> futures by using alternative (digital) infrastructures and tools,
>> without to much worry about the deep investments in money and/or
>> expertise on bloated/popular technologies (we don't have such
>> investments here!). We can learn from the experience of the "Global
>> North", without following that path, but by taking a critical
>> approach to it (for example regarding overcomplex, non-dynamic,
>> bloated technologies). On the community front, I think is important
>> to do something to break the circular logic of popularity: Smalltalk
>> is unpopular, so we don't get developers, so we don't have libraries,
>> and this makes such 

Re: [Pharo-users] Smalltalk Argument

[henry]

I have heard this summarized by the term: "build it and they will come". I 
think the data visualization aspect is where Pharo entering BigData space could 
really payoff. That comes down to data manipulation. Can Pharo read Avro?

- HH

On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna Cárdenas 
 wrote:

> Thanks a lot Paulo for starting this thread and all the participants for the 
> clever and enlightening answers. I just want to add my two cents. On 26/10/17 
> 07:53, Dimitris Chloupis wrote: > > My personal opinion is that as 
> pessimistic it may sound, Smalltalk has > very little to offer in the library 
> front. The language is still > stellar and live environment is a great 
> concept but from there on > there is a decline. Sure if your are low demand 
> kind of person on the > library front and dont mind implementing stuff by 
> yourself you wont > mind the lack of libraries but most coders , me included 
> , dont have > this luxury. Especially making a living with a language is a > 
> completely different story from learning it as a hobby,  > > I think and 
> that's a personal opinion, that Smalltalk goes the wrong > direction. It 
> tries to be a do it all language, but we already have an > army of do it all 
> languages. I think it would excel as the backbone in > big complex projects. 
> Like the Moose project is doing with code > analysis and visualization. I 
> think this is an excellent direction to > go with Smalltalk. Reflection is 
> the big strength of Smalltalk the > ability to communicate with its code in a 
> direct matter. So I think > that a Smalltalk implementation that can analyze 
> and visualize code > written in other languages would have been a pretty 
> serious reason for > people to learn Smalltalk.  > > I am very happy to see 
> Pharo go towards that direction and yes I would > definitely recommend it 
> without hesitation  for code analysis and > project management tool. Its no 
> coincidence that we have seen a > serious growth in our community. When I 
> joined back in 2011 we all > were posting at pharo-dev, pharo-users was a 
> dead zone and then the > community grow larger and larger we soon may need a 
> third mailing list.  > > Code complexity is an issues for all large projects 
> and tools that > help manage this without having to convert to another 
> language are > very popular. About finding  niche where you can learn Pharo 
> and make a living from it, I think that I may be behind a sweet spot in the 
> field of reproducible research and data storytelling and visualization, for 
> different fields like activism, journalism, science and engineering. I'm 
> "working in my PhD", so I don't get paid for using Pharo & friends (well if 
> fact I'm in a loan to finish my PhD), but using Pharo have allowed my to get 
> more dynamic results that with previous technologies (mostly Python and Web 
> ones). By being able to prototype quickly I have improved my research 
> experience and results, which is a way to improve research (self) funding. 
> Also, activists, journalist, researchers and other novices interested in data 
> storytelling and visualization, care little about popularity of the language 
> or being able to make apps (mobile or web). What they care is about being 
> able to tell the story and Pharo, agile visualization and moldable tools, 
> have a lot to offer in this front. They're easy to learn and to adapt to fit 
> the needs of the problems behind those stories, as we have done with 
> Grafoscopio[1]. So, is nice to be part of a "trend", (data science, 
> reproducible research, data storytelling and data visualization) but not 
> being part of one that doesn't give you the freedom to use tools that matter 
> to you, because of the ideas they embody and the added value they create for 
> you and your community. [1] http://mutabit.com/grafoscopio/index.en.html 
> Also, being in Latin America, means that we can bootstrap ourselves into 
> alternative futures by using alternative (digital) infrastructures and tools, 
> without to much worry about the deep investments in money and/or expertise on 
> bloated/popular technologies (we don't have such investments here!). We can 
> learn from the experience of the "Global North", without following that path, 
> but by taking a critical approach to it (for example regarding overcomplex, 
> non-dynamic, bloated technologies). On the community front, I think is 
> important to do something to break the circular logic of popularity: 
> Smalltalk is unpopular, so we don't get developers, so we don't have 
> libraries, and this makes such tech unpopular. We're a nascent community of 
> data storytellers and activists learning how to use Pharo to tell our voices 
> and how to modify the tools to tell them in more potent/fluid ways. We have 
> done this mostly by ourselves, without any support from industry or 
> government and mostly none from academy. Despite of the fragility of our 
> 

Re: [Pharo-users] Smalltalk Argument

[Offray Vladimir Luna Cárdenas]

Thanks a lot Paulo for starting this thread and all the participants for
the clever and enlightening answers.

I just want to add my two cents.


On 26/10/17 07:53, Dimitris Chloupis wrote:
>
> My personal opinion is that as pessimistic it may sound, Smalltalk has
> very little to offer in the library front. The language is still
> stellar and live environment is a great concept but from there on
> there is a decline. Sure if your are low demand kind of person on the
> library front and dont mind implementing stuff by yourself you wont
> mind the lack of libraries but most coders , me included , dont have
> this luxury. Especially making a living with a language is a
> completely different story from learning it as a hobby, 
>
> I think and that's a personal opinion, that Smalltalk goes the wrong
> direction. It tries to be a do it all language, but we already have an
> army of do it all languages. I think it would excel as the backbone in
> big complex projects. Like the Moose project is doing with code
> analysis and visualization. I think this is an excellent direction to
> go with Smalltalk. Reflection is the big strength of Smalltalk the
> ability to communicate with its code in a direct matter. So I think
> that a Smalltalk implementation that can analyze and visualize code
> written in other languages would have been a pretty serious reason for
> people to learn Smalltalk. 
>
> I am very happy to see Pharo go towards that direction and yes I would
> definitely recommend it without hesitation  for code analysis and
> project management tool. Its no coincidence that we have seen a
> serious growth in our community. When I joined back in 2011 we all
> were posting at pharo-dev, pharo-users was a dead zone and then the
> community grow larger and larger we soon may need a third mailing list. 
>
> Code complexity is an issues for all large projects and tools that
> help manage this without having to convert to another language are
> very popular.

About finding  niche where you can learn Pharo and make a living from
it, I think that I may be behind a sweet spot in the field of
reproducible research and data storytelling and visualization, for
different fields like activism, journalism, science and engineering. I'm
"working in my PhD", so I don't get paid for using Pharo & friends (well
if fact I'm in a loan to finish my PhD), but using Pharo have allowed my
to get more dynamic results that with previous technologies (mostly
Python and Web ones). By being able to prototype quickly I have improved
my research experience and results, which is a way to improve research
(self) funding. Also, activists, journalist, researchers and other
novices interested in data storytelling and visualization, care little
about popularity of the language or being able to make apps (mobile or
web). What they care is about being able to tell the story and Pharo,
agile visualization and moldable tools, have a lot to offer in this
front. They're easy to learn and to adapt to fit the needs of the
problems behind those stories, as we have done with Grafoscopio[1]. So,
is nice to be part of a "trend", (data science, reproducible research,
data storytelling and data visualization) but not being part of one that
doesn't give you the freedom to use tools that matter to you, because of
the ideas they embody and the added value they create for you and your
community.

[1] http://mutabit.com/grafoscopio/index.en.html

Also, being in Latin America, means that we can bootstrap ourselves into
alternative futures by using alternative (digital) infrastructures and
tools, without to much worry about the deep investments in money and/or
expertise on bloated/popular technologies (we don't have such
investments here!). We can learn from the experience of the "Global
North", without following that path, but by taking a critical approach
to it (for example regarding overcomplex, non-dynamic, bloated
technologies).

On the community front, I think is important to do something to break
the circular logic of popularity: Smalltalk is unpopular, so we don't
get developers, so we don't have libraries, and this makes such tech
unpopular. We're a nascent community of data storytellers and activists
learning how to use Pharo to tell our voices and how to modify the tools
to tell them in more potent/fluid ways. We have done this mostly by
ourselves, without any support from industry or government and mostly
none from academy. Despite of the fragility of our hackerspace[2], this
has been done in a consistent way since almost two years[3] (I started
to learn Pharo, in a sparse way, 3 years ago). So, there are ways to
break the circular logic and bootstrap communities around the advantages
of the Pharo/Smalltalk environment in places where it can be aligned to
the trends but also take a critical approach to them by providing added
value.

[2] http://hackbo.co/
[3] http://mutabit.com/dataweek/

So finding a niche and bootstrapping tools and communities in it, 

Re: [Pharo-users] Smalltalk Argument

[Andrew Glynn]

I will, although in some ways the two may be more complementary than anything.  

Sent from Mail for Windows 10

From: Stephane Ducasse
Sent: Saturday, October 28, 2017 5:06 AM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument

Hi andrew

you should contact esteban because he is writing an objective-C bridge. 

Stef

On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglyn...@gmail.com> wrote:
One thing I’m working on is a bridge between Pharo and F-Script.  F-Script is, 
basically, a Smalltalk dialect, as is obvious from the screenshot.  However for 
MacOS and iOS, it allows you to bypass the static Objective-C API interface and 
debug / modify or even write applications directly in the system.  To do that 
you ‘inject’ F-Script into the OS.  The ability to so has a specific 
implication, though.  MacOS and iOS are themselves written in and as a dialect 
of Smalltalk.  (were it simply an overlay on Objective-C, it wouldn’t be able 
to do things that are impossible in Objective-C, and it wouldn’t need to be 
‘injected’ in order to run).  Every implementation of Objective-C , bar GNU’s 
useless imitation, compiles to Smalltalk.  No surprise that Apple’s does, as 
well.
 
In any event, it will allow Pharo code to be mapped to MacOS and iOS objects, 
injected into the system dynamically, and modified / debugged dynamically using 
the Pharo tools.  The result, at least as far as iOS is concerned, may make 
Pharo actually the most powerful way to program it, well beyond XCode alone, 
along with doing the same for MacOS.  Android is another issue, although the 
Raspbian port of Pharo should be relatively easy to port to it. For me, unless 
someone had a use case, I don’t have one myself for Android.  I’ve tried nearly 
every version, because I’d love to support an OSS ecosystem, unfortunately 
using it compared to the iPhone is still like driving a Fiero based kit car 
compared to an actual Ferrari.
 
As far as JNI, while I see your point, JNI is such a PITA that few Java 
developers know it.  My usual workaround is to use Stamp and Synapse, which has 
the further advantage of allowing Java to ‘throttle’ data that the JVM can’t 
deal with at full speed.
 
As far as dealing with other JVM languages, PetitParser or SmaCC can generate 
bytecode rather than Java or other JVM code, and that allows libs to be written 
that utilize Synapse to talk to Pharo.  It isn’t necessarily an ideal solution, 
but a possible one without having to support umpteen environments.  Another 
potential way of accomplishing that is to use NetRexx, a declarative JVM 
language, which is both easy and terse, and like SQL, generates the actual 
bytecode rather than precompiling to it.  For instance, imagine the code needed 
for a simple ‘hello world’ in Java, then compare:
 
Say ‘hello world’
 
Since it generates virtually the same bytecode, it may be an easy way to do it.
 
With the last statement, that expresses really well the exact reason I no 
longer want to work in most other environments .
 
Tc
Andrew
 
 
 
Sent from Mail for Windows 10
 
From: p...@highoctane.be
Sent: Thursday, October 26, 2017 2:19 AM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument
 
I like that piece a lot, seeing exactly the described situation in large 
enterprises.
 
I made a strategic decision to go with Pharo for the long run for my solutions 
because it is a stable base on which to build (ok, there are evolutions, but 
fundamentally, I can rely on it being under control and can maintain solutions 
in a version).
 
The rationale is that at a deep level I am really fed up with having to deal 
with accidental complexity (now having to deal with Spark/Scala/sbt/Java/maven 
stuff) that makes the dev focus 80% technology drag and 20% net business 
contribution.
 
One key thing is that a team needs guidance and Smalltalk makes it easier due 
to well known ways of doing things.
 
Now we miss the boat on mobile and bigdata, but this is solvable. 
 
If we had an open Java bridge (and some people in the community have it for 
Pharo but do not open source it - so this is eminently doable) + Pharo as an 
embeddable piece (e.g. like Tcl and Lua) and not a big executable we would have 
a way to embed Pharo in a lot of places (e.g. in the Hadoop ecosystem where 
fast starting VMs and small footprint would make the cluster capacity x2 or x3 
vs uberjars all over the place)  this would be a real disruption.
 
Think about being able to call Pharo from JNA 
https://github.com/java-native-access/jna the same way we use C with UFFI.
 
Smalltalk argument for me is that it makes development bearable (even fun and 
enjoyable would I say) vs the other stacks. That matters.
 
Phil
 
 
 
 
 
 
 
 
On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglyn...@gmail.com> wrote:
There’s other questions that are relevant to me:
 
Do I give a f*** about cool looking web apps?  No, I don’t use web apps if in 
a

Re: [Pharo-users] Smalltalk Argument

[henry]

I referred to a Lambda Architecture, not the availability of Lambdas in the 
language. Pharo has the best with BlockClosures.

- HH

>  Original Message 
> Subject: RE: [Pharo-users] Smalltalk Argument
> Local Time: October 27, 2017 11:10 PM
> UTC Time: October 28, 2017 3:10 AM
> From: aglyn...@gmail.com
> To: henry <he...@callistohouse.club>, Any question about pharo iswelcome 
> <pharo-users@lists.pharo.org>
>
> Last point.  Blocks are already better lambdas than lambdas in Java.
>
> Have a look at this code from rxJava, which includes the Java 8 lambda 
> version and a Java 7 version using an anonymous inner class:
>
> Java 8 code
>
> package
>
> rxjava.examples
>
> ;
>
>
>
> import
>
> io.reactivex.*
>
> ;
>
>
>
> public
>
> class
>
> HelloWorld
>
> {
>
>
>
> public
>
> static
>
> void
>
> main
>
> (
>
> String
>
> []
>
> args
>
> ) {
>
>
>
> Flowable
>
> .
>
> just(
>
> "
>
> Hello world
>
> "
>
> )
>
> .
>
> subscribe(
>
> System
>
> .
>
> out
>
> ::
>
> println);
>
> }
>
> }
>
> Java 7 code
>
> import
>
> io.reactivex.functions.Consumer
>
> ;
>
>
>
> Flowable
>
> .
>
> just(
>
> "
>
> Hello world
>
> "
>
> )
>
>   .subscribe(
>
> new
>
> Consumer<
>
> String
>
>>
>
> () {
>
>
>
> @Override
>
> public
>
> void
>
> accept
>
> (
>
> String
>
> s
>
> ) {
>
>
>
> System
>
> .
>
> out
>
> .
>
> println(s);
>
>   }
>
>   });
>
> Are they equivalent?  How would you know?
>
> In fact, they aren’t, worse, the results of the difference depend on the 
> target, whether it’s Java SE (including Spring based apps) or JavaEE.
>
> The Java 8 version doesn’t create an anonymous inner class but a generically 
> named class with generically named methods.  As a result, it will be most 
> often faster.  However it’s less safe, because particularly in clustered 
> environments, and unpredictably, it can create conflicts due to the same 
> generic names being used by two different JVM’s.  The Java 7 version will be 
> as fast, in JavaEE, and safer.  In Java SE they’re close to equivalently 
> safe, but the Java 7 version will be significantly slower in most cases.
>
> RxJava itself, as well, is unnecessary in Pharo, since the Announcer already 
> implements the same pattern, and does so in a more efficient and more 
> consistent way.
>
> Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 
> 10
>
> From: [henry](mailto:he...@callistohouse.club)
> Sent: Friday, October 27, 2017 5:03 PM
> To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org)
> Subject: Re: [Pharo-users] Smalltalk Argument
>
> Elastic search JSON integration would be another good one. I heard there was 
> a Kafka integration, is that true? Where could I find that, I used to use 
> Kafka.
>
> Kafka is a great event channel for input to BigData. Using Kafka, it is well 
> in crafting a Lamda Architecture. Imagine Pharo where Storm resides.
>
> [webkit-fake-url://502df029-af7a-484e-b157-43970b30a0a1/imagejpeg]
>
> - HH
>
> On Fri, Oct 27, 2017 at 16:51, henry <he...@callistohouse.club> wrote:
>
>>  How about Kerberos? Can we get a team to look closely at bringing 
>> integration for enterprise users? That would be helpful, or can you just put 
>> it behind a Kerberos wrapper? If that would work, collecting a demo, that 
>> could unlock more corporate wallets , for investment.
>>
>> - HH
>>
>> On Fri, Oct 27, 2017 at 16:41, henry 
>> <[he...@callistohouse.club](%22mailto:he...@callistohouse.club%22)> wrote:
>>
>>> How is there no steering committee to accumulate wrapping 3rd party 
>>> libraries in Alien to gain benefits of code in other languages? Do not 
>>> assume that code is not extremely well written in that particular language 
>>> for that particular task and that particular deployment mechanism.
>>>
>>> Can Pharo be called as a shared library from Java JNA?
>>>
>>> - HH
>>>
>>> On Fri, Oct 27, 2017 at 15:47, Andrew Glynn 
>>> <[aglyn...@gmail.com](%22mailto:aglyn...@gmail.com%22)> wrote:
>>>
>>>> I’m not claiming I don’t or haven’t been affected, only that I no long 
>>>> allow myself to be.  Does that cause issues?  Of course.  But I’d rather 

Re: [Pharo-users] Smalltalk Argument

[henry]

I used Kafka as was illustrated in the image, as a durable event source for 
BigData to RDB, Hadoop and other facilities. Our Kafka consumers were writing 
into Hadoop and had no concept of map/reduce.

I agree that if we had a map/reduce feature then Pharo could operate against 
HDB and Hadoop in the Hadoop constellation of tools. That would be powerful.

I need and wish to ask your opinion, for steering Pharo into an enterprise 
solution, what features does Pharo need to be a better player?

- HH

>  Original Message 
> Subject: RE: [Pharo-users] Smalltalk Argument
> Local Time: October 27, 2017 11:10 PM
> UTC Time: October 28, 2017 3:10 AM
> From: aglyn...@gmail.com
> To: henry <he...@callistohouse.club>, Any question about pharo iswelcome 
> <pharo-users@lists.pharo.org>
>
> There’s a million ways of accomplishing such things, but you need to pick the 
> appropriate way to do  it, given restrictions in Pharo and limitations in 
> what’s it’s calling.
>
> You can utilize Kafka or Kerberos authentication via Synapse, for instance, 
> you can access virtually any authentication mechanism via WSO2 IS (itself 
> built on Synapse).
>
> Another way of accessing the same things (plus numerous others) is via 
> Vert.x, also directly supported from the Pharo catalog.  I’ve used that 
> methodology as well, though I had to overcome Vert.x’s own limitations by 
> mapping it to the more capable Apache River (formerly JINI).
>
> You can access Hadoop / Cassandra / MongoDB via the same methods Kafka, Storm 
> and Spark do, without the problems introduced by the JVM.  MongoDB and 
> Cassandra have libraries already available in Pharo, and they work better 
> than those available elsewhere.
>
> There are even ways to directly access the Open Telephony API in ERLAN.
>
> Sometimes you need to be creative, and every time you need to understand the 
> strengths and limitations of both what you’re using, and what you’re 
> accessing.
>
> Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 
> 10
>
> From: [henry](mailto:he...@callistohouse.club)
> Sent: Friday, October 27, 2017 5:03 PM
> To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org)
> Subject: Re: [Pharo-users] Smalltalk Argument
>
> Elastic search JSON integration would be another good one. I heard there was 
> a Kafka integration, is that true? Where could I find that, I used to use 
> Kafka.
>
> Kafka is a great event channel for input to BigData. Using Kafka, it is well 
> in crafting a Lamda Architecture. Imagine Pharo where Storm resides.
>
> [webkit-fake-url://502df029-af7a-484e-b157-43970b30a0a1/imagejpeg]
>
> - HH
>
> On Fri, Oct 27, 2017 at 16:51, henry <he...@callistohouse.club> wrote:
>
>>  How about Kerberos? Can we get a team to look closely at bringing 
>> integration for enterprise users? That would be helpful, or can you just put 
>> it behind a Kerberos wrapper? If that would work, collecting a demo, that 
>> could unlock more corporate wallets , for investment.
>>
>> - HH
>>
>> On Fri, Oct 27, 2017 at 16:41, henry 
>> <[he...@callistohouse.club](%22mailto:he...@callistohouse.club%22)> wrote:
>>
>>> How is there no steering committee to accumulate wrapping 3rd party 
>>> libraries in Alien to gain benefits of code in other languages? Do not 
>>> assume that code is not extremely well written in that particular language 
>>> for that particular task and that particular deployment mechanism.
>>>
>>> Can Pharo be called as a shared library from Java JNA?
>>>
>>> - HH
>>>
>>> On Fri, Oct 27, 2017 at 15:47, Andrew Glynn 
>>> <[aglyn...@gmail.com](%22mailto:aglyn...@gmail.com%22)> wrote:
>>>
>>>> I’m not claiming I don’t or haven’t been affected, only that I no long 
>>>> allow myself to be.  Does that cause issues?  Of course.  But I’d rather 
>>>> deal with those than do things I don’t enjoy.  However I only got to that 
>>>> point after 26 years in the industry, so I don’t expect that everyone will 
>>>> feel that way.
>>>>
>>>> Cheers
>>>>
>>>> Andrew
>>>>
>>>> Sent from [Mail](%22https:/go.microsoft.com/fwlink/?LinkId=550986%22) for 
>>>> Windows 10
>>>>
>>>> From: [jtuc...@objektfabrik.de](%22mailto:jtuc...@objektfabrik.de%22)
>>>> Sent: Thursday, October 26, 2017 8:14 AM
>>>> To: [pharo-users@lists.pharo.org](%22mailto:pharo-users@lists.pharo.org%22)
>>>> Subject: Re: [Pharo-users] Smalltalk Argument
>>>>
>>&

Re: [Pharo-users] Smalltalk Argument

[henry]

I looked and was not able to find it. Which version of Pharo are we talking 
about? What is the name of the kafka integration?

- HH

>  Original Message 
> Subject: RE: [Pharo-users] Smalltalk Argument
> Local Time: October 27, 2017 11:10 PM
> UTC Time: October 28, 2017 3:10 AM
> From: aglyn...@gmail.com
> To: henry <he...@callistohouse.club>, Any question about pharo iswelcome 
> <pharo-users@lists.pharo.org>
>
> The Kafka integration is right in the Pharo catalog.
>
> Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 
> 10
>
> From: [henry](mailto:he...@callistohouse.club)
> Sent: Friday, October 27, 2017 5:03 PM
> To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org)
> Subject: Re: [Pharo-users] Smalltalk Argument
>
> Elastic search JSON integration would be another good one. I heard there was 
> a Kafka integration, is that true? Where could I find that, I used to use 
> Kafka.
>
> Kafka is a great event channel for input to BigData. Using Kafka, it is well 
> in crafting a Lamda Architecture. Imagine Pharo where Storm resides.
>
> [webkit-fake-url://502df029-af7a-484e-b157-43970b30a0a1/imagejpeg]
>
> - HH
>
> On Fri, Oct 27, 2017 at 16:51, henry <he...@callistohouse.club> wrote:
>
>>  How about Kerberos? Can we get a team to look closely at bringing 
>> integration for enterprise users? That would be helpful, or can you just put 
>> it behind a Kerberos wrapper? If that would work, collecting a demo, that 
>> could unlock more corporate wallets , for investment.
>>
>> - HH
>>
>> On Fri, Oct 27, 2017 at 16:41, henry 
>> <[he...@callistohouse.club](%22mailto:he...@callistohouse.club%22)> wrote:
>>
>>> How is there no steering committee to accumulate wrapping 3rd party 
>>> libraries in Alien to gain benefits of code in other languages? Do not 
>>> assume that code is not extremely well written in that particular language 
>>> for that particular task and that particular deployment mechanism.
>>>
>>> Can Pharo be called as a shared library from Java JNA?
>>>
>>> - HH
>>>
>>> On Fri, Oct 27, 2017 at 15:47, Andrew Glynn 
>>> <[aglyn...@gmail.com](%22mailto:aglyn...@gmail.com%22)> wrote:
>>>
>>>> I’m not claiming I don’t or haven’t been affected, only that I no long 
>>>> allow myself to be.  Does that cause issues?  Of course.  But I’d rather 
>>>> deal with those than do things I don’t enjoy.  However I only got to that 
>>>> point after 26 years in the industry, so I don’t expect that everyone will 
>>>> feel that way.
>>>>
>>>> Cheers
>>>>
>>>> Andrew
>>>>
>>>> Sent from [Mail](%22https:/go.microsoft.com/fwlink/?LinkId=550986%22) for 
>>>> Windows 10
>>>>
>>>> From: [jtuc...@objektfabrik.de](%22mailto:jtuc...@objektfabrik.de%22)
>>>> Sent: Thursday, October 26, 2017 8:14 AM
>>>> To: [pharo-users@lists.pharo.org](%22mailto:pharo-users@lists.pharo.org%22)
>>>> Subject: Re: [Pharo-users] Smalltalk Argument
>>>>
>>>> Andrew,
>>>>
>>>> Am 26.10.17 um 00:46 schrieb Andrew Glynn:
>>>>
>>>>> There’s other questions that are relevant to me:
>>>>
>>>> I am glad you opened your words with this sentence. Other peoples’ 
>>>> mileages may vary a lot.
>>>>
>>>>> Do I give a f*** about cool looking web apps?  No, I don’t use web apps 
>>>>> if in any way I can avoid it.
>>>>
>>>> Some people can’t. I can’t. I am making my living with a web based 
>>>> application. And I like it.
>>>>
>>>>> Do I give a f*** about mobile apps?  No, the screen’s too small to read 
>>>>> anything longer than a twit, or anyone with anything worthwhile to say.>
>>>>
>>>> So you are in the lucky position that neither mobile nor web nor 
>>>> integration matters to you or you have enough resources to do all that 
>>>> stuff yourself. I am envyous. I need to build web pages and people ask me 
>>>> whether we can ship an iPhone App. I do customer-facing stuff and sex 
>>>> sells much more than we like to think.
>>>>
>>>> Your comments on the crappiness of libs in other languages is a great fit 
>>>> for Smalltalk. Not invented here, therefor rubbish. We came a long way 
>>>> with this way of thinking. But these rubbish makers dance circles a

Re: [Pharo-users] Smalltalk Argument

[Stephane Ducasse]

Hi andrew

you should contact esteban because he is writing an objective-C bridge.

Stef

On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglyn...@gmail.com> wrote:

> One thing I’m working on is a bridge between Pharo and F-Script.  F-Script
> is, basically, a Smalltalk dialect, as is obvious from the screenshot.
> However for MacOS and iOS, it allows you to bypass the static Objective-C
> API interface and debug / modify or even write applications directly in the
> system.  To do that you ‘inject’ F-Script into the OS.  The ability to so
> has a specific implication, though.  MacOS and iOS are themselves written
> in and as a dialect of Smalltalk.  (were it simply an overlay on
> Objective-C, it wouldn’t be able to do things that are impossible in
> Objective-C, and it wouldn’t need to be ‘injected’ in order to run).  Every
> implementation of Objective-C , bar GNU’s useless imitation, compiles to
> Smalltalk.  No surprise that Apple’s does, as well.
>
>
>
> In any event, it will allow Pharo code to be mapped to MacOS and iOS
> objects, injected into the system dynamically, and modified / debugged
> dynamically using the Pharo tools.  The result, at least as far as iOS is
> concerned, may make Pharo actually the most powerful way to program it,
> well beyond XCode alone, along with doing the same for MacOS.  Android is
> another issue, although the Raspbian port of Pharo should be relatively
> easy to port to it. For me, unless someone had a use case, I don’t have one
> myself for Android.  I’ve tried nearly every version, because I’d love to
> support an OSS ecosystem, unfortunately using it compared to the iPhone is
> still like driving a Fiero based kit car compared to an actual Ferrari.
>
>
>
> As far as JNI, while I see your point, JNI is such a PITA that few Java
> developers know it.  My usual workaround is to use Stamp and Synapse, which
> has the further advantage of allowing Java to ‘throttle’ data that the JVM
> can’t deal with at full speed.
>
>
>
> As far as dealing with other JVM languages, PetitParser or SmaCC can
> generate bytecode rather than Java or other JVM code, and that allows libs
> to be written that utilize Synapse to talk to Pharo.  It isn’t necessarily
> an ideal solution, but a possible one without having to support umpteen
> environments.  Another potential way of accomplishing that is to use
> NetRexx, a declarative JVM language, which is both easy and terse, and like
> SQL, generates the actual bytecode rather than precompiling to it.  For
> instance, imagine the code needed for a simple ‘hello world’ in Java, then
> compare:
>
>
>
> Say ‘hello world’
>
>
>
> Since it generates virtually the same bytecode, it may be an easy way to
> do it.
>
>
>
> With the last statement, that expresses really well the exact reason I no
> longer want to work in most other environments .
>
>
>
> Tc
>
> Andrew
>
>
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *p...@highoctane.be
> *Sent: *Thursday, October 26, 2017 2:19 AM
> *To: *Any question about pharo is welcome <pharo-users@lists.pharo.org>
> *Subject: *Re: [Pharo-users] Smalltalk Argument
>
>
>
> I like that piece a lot, seeing exactly the described situation in large
> enterprises.
>
>
>
> I made a strategic decision to go with Pharo for the long run for my
> solutions because it is a stable base on which to build (ok, there are
> evolutions, but fundamentally, I can rely on it being under control and can
> maintain solutions in a version).
>
>
>
> The rationale is that at a deep level I am really fed up with having to
> deal with accidental complexity (now having to deal with
> Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology
> drag and 20% net business contribution.
>
>
>
> One key thing is that a team needs guidance and Smalltalk makes it easier
> due to well known ways of doing things.
>
>
>
> Now we miss the boat on mobile and bigdata, but this is solvable.
>
>
>
> If we had an open Java bridge (and some people in the community have it
> for Pharo but do not open source it - so this is eminently doable) + Pharo
> as an embeddable piece (e.g. like Tcl and Lua) and not a big executable we
> would have a way to embed Pharo in a lot of places (e.g. in the Hadoop
> ecosystem where fast starting VMs and small footprint would make the
> cluster capacity x2 or x3 vs uberjars all over the place)  this would be a
> real disruption.
>
>
>
> Think about being able to call Pharo from JNA https://github.com/java-
> native-access/jna the same way we use C with UFFI.
>
>
>

Re: [Pharo-users] Smalltalk Argument

[Dimitris Chloupis]

On Sat, Oct 28, 2017 at 6:10 AM Andrew Glynn  wrote:

> Web dev is a messy field.  Not because it has grown too fast, but because
> it was designed by amateurs, developed by amateurs, and continues to be so,
> while depending on an underlying expertly designed system, the internet.
>

 Non sense. Companies have been heavily involved in the developing of the
web since day one. Javascript was not designed by an amateur and pretty
much no web dev technologies out there not only are produced since day 1
from professional coders , web standards committess played a crucial  role
in the developing of web technologies.

The web has always been a huge cash cow.

The very fact that Javascript has the name Java is not as many developers
will be quick to point unrelated Java. It is very much related. . Sun for a
considerable amount of time was working on Javascript as a scripting engine
targeting the web working hand in hand with Java. The relationship was sort
lived but for a very long time Java was the de facto language for
developing powerful web application / websites. The well known Java applets
that exist even today.

The reason why the web followed its own road is quite sensible. The
internet was viewed as nothing more than a display of documents and made
sense to use a document format (HTML) for it at the time. It was easy and
accesible to anyone. None could predict the explosion of the web at the
time and the future needs for much greater degree of dynamism. Neither
could I and I am vicious critic of web dev.

The technology evolved very fast that not even up for debate, good designs
require redesigns. Redesigns require time.

The web was nothing really new neither was the internet. BBS were
dominating online communication and function in a very similar way that the
web did later on providing, email, messages, forumes, download directories,
blog posts, articles and a wealth of information through the use of a model
and a regular telophone line. BBS were based on desktop technology and far
better designed but they could not keep up with the incrasing demands of
massive online communication so the web and the internet ignated even
though internet was create far earlier than BBS. Much less likely to find
cat videos because BBS was based on P2P kind of technology and was working
on very limited hardware where every byte was precious.

It was the failure of desktop technologies to adjust to the need for a web
that lead to its seperate evolution. Java was the only language that took a
serious interest into web developing and even Java was unwilling to adjust
to the needs of the web leading to the massive failure of the Java applet.
On the other hand Flash that was specifically designed for the web ,
flourished for many years till HTML and JS finally caught up.

Amateurs also play a very importan role in the evolution of graphics and
guis. Teenage hackers were the ones to ignite the trend of computer
graphics that lead to the establishment of GUI and 3d graphics as well as
computer audio even though those technologies have existed far earlier it
was their innovation that managed to take advantage of clever solution to
overcome extreme limitations of the hardware. This happened through the
developing of "demos" giving rise to a completely new community of extrmely
knowledgable amateurs knows as "demoscene" and hackers. 3d graphics to this
day remain the most fast moving / evolving field of computer science
challanged only by AI.

Plus Amateurs play a vital role in many other fields like Astronomy , their
contribution is so substabtial that many celestial bodies are named after
them. Amateurs have usually far higher level of knowledge of a field mainly
because they tend to avoid specialisation and they do not operate on the
time constraints or have to fight a backward thinking management department
that want to do things "the popular" way. For similar reason they pay far
more respect to designs as well.

So it was both the failure of desktop to take into serious consideration
the new web needs and the rapid evolution of the web based on the format
that it was already problematic.

It was companies themselves that hindered and keep hindering its evolution
with being stuck on bad design for the shake of backward compatibility.

On the other hand desktop has it own share of ugliness and "amateurism"
biggest example being MFC , Microsoft's Official GUI API, that was so ugly
and heavily disliked that none even question the existence of HTML because
no coder in his right mind could consider imposing such a terrible design
to a new technology.

On similar note web is not all that bad, JS has heavily improved as a
language , HTML has become extremely flexible and there are many well
designed libraries like Bootstrap , D3 etc . Also desktop language learned
their lesson and now fully embreace web dev at least on the back end.

Finally nowdays we see the merging of web and desktop technlogies (and the

Re: [Pharo-users] Smalltalk Argument

[Andrew Glynn]

The Kafka integration is right in the Pharo catalog.

Sent from Mail for Windows 10

From: henry
Sent: Friday, October 27, 2017 5:03 PM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument

Elastic search JSON integration would be another good one. I heard there was a 
Kafka integration, is that true? Where could I find that, I used to use Kafka.

Kafka is a great event channel for input to BigData. Using Kafka, it is well in 
crafting a Lamda Architecture. Imagine Pharo where Storm resides.



- HH


On Fri, Oct 27, 2017 at 16:51, henry <he...@callistohouse.club> wrote:
 How about Kerberos? Can we get a team to look closely at bringing integration 
for enterprise users? That would be helpful, or can you just put it behind a 
Kerberos wrapper? If that would work, collecting a demo, that could unlock more 
corporate wallets , for investment. 


- HH


On Fri, Oct 27, 2017 at 16:41, henry <he...@callistohouse.club> wrote:
How is there no steering committee to accumulate wrapping 3rd party libraries 
in Alien to gain benefits of code in other languages? Do not assume that code 
is not extremely well written in that particular language for that particular 
task and that particular deployment mechanism.

Can Pharo be called as a shared library from Java JNA?

- HH


On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglyn...@gmail.com> wrote:
I’m not claiming I don’t or haven’t been affected, only that I no long allow 
myself to be.  Does that cause issues?  Of course.  But I’d rather deal with 
those than do things I don’t enjoy.  However I only got to that point after 26 
years in the industry, so I don’t expect that everyone will feel that way.
  
Cheers
Andrew
  
Sent from Mail for Windows 10
  
From: jtuc...@objektfabrik.de 
Sent: Thursday, October 26, 2017 8:14 AM 
To: pharo-users@lists.pharo.org 
Subject: Re: [Pharo-users] Smalltalk Argument
  
Andrew,

Am 26.10.17 um 00:46 schrieb Andrew Glynn: 
There’s other questions that are relevant to me: 
I am glad you opened your words with this sentence. Other peoples’ mileages may 
vary a lot. 
> Do I give a f*** about cool looking web apps?  No, I don’t use web apps if in 
> any way I can avoid it. 
  
Some people can’t. I can’t. I am making my living with a web based application. 
And I like it. 
  
> Do I give a f*** about mobile apps?  No, the screen’s too small to read 
> anything longer than a twit, or anyone with anything worthwhile to say.>

So you are in the lucky position that neither mobile nor web nor integration 
matters to you or you have enough resources to do all that stuff yourself. I am 
envyous. I need to build web pages and people ask me whether we can ship an 
iPhone App. I do customer-facing stuff and sex sells much more than we like to 
think.

Your comments on the crappiness of libs in other languages is a great fit for 
Smalltalk. Not invented here, therefor rubbish. We came a long way with this 
way of thinking. But these rubbish makers dance circles around us while we try 
to do our first hello world for an iPad. They laugh at us when we try to 
reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). 
Because they are back home and watch Netflix while we debug our homegrown base 
libraries that are, of course, much better than theirs because they are written 
in Smalltalk.

I am not arguing that maintaining Smalltalk code is far superior to most 
technolgies out there. But depending on the needs of our projects we have to 
learn and use those crappy technologies to accomplish what they offer. Because, 
sometimes (especially if you have to pay bills), an existing library with flaws 
is better than none.

So if I have to use Javascript or C# or Dart or Swift to do the frontend part 
of my system, is there still much benefit in using these together with 
Smalltalk? Or is there - at least from a manager’s point of view - not a 
reasonable amount of sense in choosing the frontend technology also for the 
logic and compensate the loss in productivity with a gain in avoided 
complexity? 

Your answer delivers a lot of food for thought, but I don’t buy all of it. And 
I don’t expect you to buy all of mine ;-)


Joachim








  
  
Do I give a f*** about the number of libraries in other languages?  No, because 
most of them are crap in every language I’ve had to work in, and the base 
languages are crap so they have to keep changing radically, and libraries and 
frameworks therefore also have to and never get any better. The few that are 
worthwhile I can almost always use from Smalltalk without a problem (read, 
Blender, ACT-R and Synapse, since every other library/framework I’ve used 
outside Smalltalk has been a waste of time).  
  
Do I give a f*** about implementing a complex piece of machine learning 
software in 22 hours, compared to 3 months for the Java version?  Well, 
actually yes, I do, because that was 3 months of my life down the toile

Re: [Pharo-users] Smalltalk Argument

[Andrew Glynn]

There’s a million ways of accomplishing such things, but you need to pick the 
appropriate way to do  it, given restrictions in Pharo and limitations in 
what’s it’s calling.  

You can utilize Kafka or Kerberos authentication via Synapse, for instance, you 
can access virtually any authentication mechanism via WSO2 IS (itself built on 
Synapse).  

Another way of accessing the same things (plus numerous others) is via Vert.x, 
also directly supported from the Pharo catalog.  I’ve used that methodology as 
well, though I had to overcome Vert.x’s own limitations by mapping it to the 
more capable Apache River (formerly JINI).

You can access Hadoop / Cassandra / MongoDB via the same methods Kafka, Storm 
and Spark do, without the problems introduced by the JVM.  MongoDB and 
Cassandra have libraries already available in Pharo, and they work better than 
those available elsewhere.

There are even ways to directly access the Open Telephony API in ERLAN.  

Sometimes you need to be creative, and every time you need to understand the 
strengths and limitations of both what you’re using, and what you’re accessing. 



Sent from Mail for Windows 10

From: henry
Sent: Friday, October 27, 2017 5:03 PM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument

Elastic search JSON integration would be another good one. I heard there was a 
Kafka integration, is that true? Where could I find that, I used to use Kafka.

Kafka is a great event channel for input to BigData. Using Kafka, it is well in 
crafting a Lamda Architecture. Imagine Pharo where Storm resides.



- HH


On Fri, Oct 27, 2017 at 16:51, henry <he...@callistohouse.club> wrote:
 How about Kerberos? Can we get a team to look closely at bringing integration 
for enterprise users? That would be helpful, or can you just put it behind a 
Kerberos wrapper? If that would work, collecting a demo, that could unlock more 
corporate wallets , for investment. 


- HH


On Fri, Oct 27, 2017 at 16:41, henry <he...@callistohouse.club> wrote:
How is there no steering committee to accumulate wrapping 3rd party libraries 
in Alien to gain benefits of code in other languages? Do not assume that code 
is not extremely well written in that particular language for that particular 
task and that particular deployment mechanism.

Can Pharo be called as a shared library from Java JNA?

- HH


On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglyn...@gmail.com> wrote:
I’m not claiming I don’t or haven’t been affected, only that I no long allow 
myself to be.  Does that cause issues?  Of course.  But I’d rather deal with 
those than do things I don’t enjoy.  However I only got to that point after 26 
years in the industry, so I don’t expect that everyone will feel that way.
  
Cheers
Andrew
  
Sent from Mail for Windows 10
  
From: jtuc...@objektfabrik.de 
Sent: Thursday, October 26, 2017 8:14 AM 
To: pharo-users@lists.pharo.org 
Subject: Re: [Pharo-users] Smalltalk Argument
  
Andrew,

Am 26.10.17 um 00:46 schrieb Andrew Glynn: 
There’s other questions that are relevant to me: 
I am glad you opened your words with this sentence. Other peoples’ mileages may 
vary a lot. 
> Do I give a f*** about cool looking web apps?  No, I don’t use web apps if in 
> any way I can avoid it. 
  
Some people can’t. I can’t. I am making my living with a web based application. 
And I like it. 
  
> Do I give a f*** about mobile apps?  No, the screen’s too small to read 
> anything longer than a twit, or anyone with anything worthwhile to say.>

So you are in the lucky position that neither mobile nor web nor integration 
matters to you or you have enough resources to do all that stuff yourself. I am 
envyous. I need to build web pages and people ask me whether we can ship an 
iPhone App. I do customer-facing stuff and sex sells much more than we like to 
think.

Your comments on the crappiness of libs in other languages is a great fit for 
Smalltalk. Not invented here, therefor rubbish. We came a long way with this 
way of thinking. But these rubbish makers dance circles around us while we try 
to do our first hello world for an iPad. They laugh at us when we try to 
reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). 
Because they are back home and watch Netflix while we debug our homegrown base 
libraries that are, of course, much better than theirs because they are written 
in Smalltalk.

I am not arguing that maintaining Smalltalk code is far superior to most 
technolgies out there. But depending on the needs of our projects we have to 
learn and use those crappy technologies to accomplish what they offer. Because, 
sometimes (especially if you have to pay bills), an existing library with flaws 
is better than none.

So if I have to use Javascript or C# or Dart or Swift to do the frontend part 
of my system, is there still much benefit in using these together with 
Smalltalk? Or is there - at lea

Re: [Pharo-users] Smalltalk Argument

[Andrew Glynn]

Last point.  Blocks are already better lambdas than lambdas in Java.

Have a look at this code from rxJava, which includes the Java 8 lambda version 
and a Java 7 version using an anonymous inner class:

Java 8 code

package rxjava.examples;

import io.reactivex.*;

public class HelloWorld {
public static void main(String[] args) {
Flowable.just("Hello world").subscribe(System.out::println);
}
}

Java 7 code

import io.reactivex.functions.Consumer;

Flowable.just("Hello world")
  .subscribe(new Consumer() {
  @Override public void accept(String s) {
  System.out.println(s);
  }
  });

Are they equivalent?  How would you know?

In fact, they aren’t, worse, the results of the difference depend on the 
target, whether it’s Java SE (including Spring based apps) or JavaEE.

The Java 8 version doesn’t create an anonymous inner class but a generically 
named class with generically named methods.  As a result, it will be most often 
faster.  However it’s less safe, because particularly in clustered 
environments, and unpredictably, it can create conflicts due to the same 
generic names being used by two different JVM’s.  The Java 7 version will be as 
fast, in JavaEE, and safer.  In Java SE they’re close to equivalently safe, but 
the Java 7 version will be significantly slower in most cases.

RxJava itself, as well, is unnecessary in Pharo, since the Announcer already 
implements the same pattern, and does so in a more efficient and more 
consistent way.


Sent from Mail for Windows 10

From: henry
Sent: Friday, October 27, 2017 5:03 PM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument

Elastic search JSON integration would be another good one. I heard there was a 
Kafka integration, is that true? Where could I find that, I used to use Kafka.

Kafka is a great event channel for input to BigData. Using Kafka, it is well in 
crafting a Lamda Architecture. Imagine Pharo where Storm resides.



- HH


On Fri, Oct 27, 2017 at 16:51, henry <he...@callistohouse.club> wrote:
 How about Kerberos? Can we get a team to look closely at bringing integration 
for enterprise users? That would be helpful, or can you just put it behind a 
Kerberos wrapper? If that would work, collecting a demo, that could unlock more 
corporate wallets , for investment. 


- HH


On Fri, Oct 27, 2017 at 16:41, henry <he...@callistohouse.club> wrote:
How is there no steering committee to accumulate wrapping 3rd party libraries 
in Alien to gain benefits of code in other languages? Do not assume that code 
is not extremely well written in that particular language for that particular 
task and that particular deployment mechanism.

Can Pharo be called as a shared library from Java JNA?

- HH


On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglyn...@gmail.com> wrote:
I’m not claiming I don’t or haven’t been affected, only that I no long allow 
myself to be.  Does that cause issues?  Of course.  But I’d rather deal with 
those than do things I don’t enjoy.  However I only got to that point after 26 
years in the industry, so I don’t expect that everyone will feel that way.
  
Cheers
Andrew
  
Sent from Mail for Windows 10
  
From: jtuc...@objektfabrik.de 
Sent: Thursday, October 26, 2017 8:14 AM 
To: pharo-users@lists.pharo.org 
Subject: Re: [Pharo-users] Smalltalk Argument
  
Andrew,

Am 26.10.17 um 00:46 schrieb Andrew Glynn: 
There’s other questions that are relevant to me: 
I am glad you opened your words with this sentence. Other peoples’ mileages may 
vary a lot. 
> Do I give a f*** about cool looking web apps?  No, I don’t use web apps if in 
> any way I can avoid it. 
  
Some people can’t. I can’t. I am making my living with a web based application. 
And I like it. 
  
> Do I give a f*** about mobile apps?  No, the screen’s too small to read 
> anything longer than a twit, or anyone with anything worthwhile to say.>

So you are in the lucky position that neither mobile nor web nor integration 
matters to you or you have enough resources to do all that stuff yourself. I am 
envyous. I need to build web pages and people ask me whether we can ship an 
iPhone App. I do customer-facing stuff and sex sells much more than we like to 
think.

Your comments on the crappiness of libs in other languages is a great fit for 
Smalltalk. Not invented here, therefor rubbish. We came a long way with this 
way of thinking. But these rubbish makers dance circles around us while we try 
to do our first hello world for an iPad. They laugh at us when we try to 
reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). 
Because they are back home and watch Netflix while we debug our homegrown base 
libraries that are, of course, much better than theirs because they are written 
in Smalltalk.

I am not arguing that maintaining Smalltalk code is far superior to most 
technolgies out there. But depending on the needs o

Re: [Pharo-users] Smalltalk Argument

[Andrew Glynn]

I refer to it as “Craptive Directory”, the only reliable way I’ve found to use 
it is to federate it via WSO2 IS or OpenIDM.

You forgot Sun’s implementation, btw, which is cleaner than either.

Sent from Mail for Windows 10

From: p...@highoctane.be
Sent: Thursday, October 26, 2017 6:07 PM
To: henry; Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument

There are two key Kerberos implementations one can use with Hadoop.

One is the FreeIpa/RedHat IdM.
The other is ActiveDirectory.

I am using FreeIPA which bundles MIT Kerberos/389/sssd and more for making a CA 
etc. Works wonderfullý well.

AD is well ... part of the corporate landdscape.

Most of Kerberos needs are done with Java in Hadoop. But details are buried in 
private Sun classes..

Google Madness beyond the gate hadoop for some Lovecraftian quotes describing 
the situation along educated info.

Phil

On Thu, Oct 26, 2017 at 6:23 PM, henry <he...@callistohouse.club> wrote:
I have no idea which is best. For being able to say we use industry standard 
Kerberos, calling an accepted implementation seems wise, like OpenSSL support.

- HH


On Thu, Oct 26, 2017 at 11:39, Paulo R. Dellani <dell...@pobox.com> wrote:
This all sounds very interesting. What is the idea? Wrap libkrb5 through UFFI 
or implement it in Smalltalk? 
On 10/26/2017 04:38 PM, henry wrote: 
A Kerberos effort will have to be a group effort. Sideways to my main focus and 
your all’s main focii. 


- HH


On Thu, Oct 26, 2017 at 09:15, henry <he...@callistohouse.club> wrote: 
I think another good service to integrate well to is Elastic Search. 

Of the 4 types of integration, I vote for and step forward to volunteer to help 
Kerberos integration in Pharo. What to do? 


- HH 


On Thu, Oct 26, 2017 at 09:06, henry <he...@callistohouse.club> wrote: 
I try posting with a smaller image. 



- HH 


——— Original Message ——— 
Subject: Re: [Pharo-users] Smalltalk Argument 
Local Time: October 26, 2017 8:52 AM 
UTC Time: October 26, 2017 12:52 PM 
From: he...@callistohouse.club 
To: p...@highoctane.be <p...@highoctane.be>, Any question about pharo is 
welcome <pharo-users@lists.pharo.org> 

Perhaps not, or not yet. Perhaps it is the communications foundation for an 
always-on cloud/bigData control layer. 

I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin 
key negotiation and subsequent encryption/encoding, both user-supplied.  

Please see the attached diagram, co-locating ParrotTalk with my other 
components. 

ParrotTalk does not do user authentication/authorization. Which means to me 
that I should consider Kerberos authorization/authentication to establish as an 
integratable transport to play in bigData. 

This means you still need a Kerberos client and I need a Kerberos client. How 
do we start? 

- HH 

PS: I did much work integrating Kafka into a framework. I was thinking of 
inserting msg sending replication to a partition count of replicate queues for 
sending and receiving Hubbub traffic, thus inserting right where Kerberos is in 
the diagram. I would love to see client coupling for Kerberos, Kafka and 
Hadoop, while I figure out proper security to make that group happy with this 
as a possible control layer solution, forking off jobs. 


On Thu, Oct 26, 2017 at 03:14, p...@highoctane.be <p...@highoctane.be> wrote: 
Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop 
uses the UGI (UserGroupInformation) thing and that is a black hole of crypto 
things.  

How would you see ParrotTalk work?  

I made a XmppTalk thing (binding for libstrophe) for having Pharo images and 
other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW 

See 
https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1UaX5ikEU/edit?usp=sharing
 

libstrophe does the SSL thing under the hood (using OpenSSL) and is actively 
maintained. 
https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c 

And I currently work with Kafka so, Pharo as a consumer or producer, sure am 
interested. But need Kerberos support. 

Tell me more about your vision. Even better, draw it in some way :-) 

Phil 


On Thu, Oct 26, 2017 at 8:43 AM, henry <he...@callistohouse.club> wrote: 

This is a goal of ParrotTalk, to bring bit-compatible communications to Squeak, 
Pharo and Java. This is not an invocation bridge you speak of but a 
communications bridge to be able to run against Hadoop or whichever big data 
needs integration with (Kafka). I had hoped it might be adopted for such. Yet 
again this is not exactly what you were looking for but yet interesting 
perhaps? 


- HH 


On Thu, Oct 26, 2017 at 02:17, p...@highoctane.be < p...@highoctane.be> wrote: 
I like that piece a lot, seeing exactly the described situation in large 
enterprises. 

I made a strategic decision to go with Pharo for the long run for my solutions 
because it is a s

Re: [Pharo-users] Smalltalk Argument

[Andrew Glynn]

Unfortunately I can’t make it available since it was a government project, but 
I used Pharo to do streaming analytics on XML streams from Cisco ASR’s, and the 
analyzed data was streamed directly to Hadoop, which was magnitudes faster than 
Spark, Storm or Kafka, never mind HDB or the PostgreSQL overlay.

Sent from Mail for Windows 10

From: henry
Sent: Friday, October 27, 2017 5:03 PM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument

Elastic search JSON integration would be another good one. I heard there was a 
Kafka integration, is that true? Where could I find that, I used to use Kafka.

Kafka is a great event channel for input to BigData. Using Kafka, it is well in 
crafting a Lamda Architecture. Imagine Pharo where Storm resides.



- HH


On Fri, Oct 27, 2017 at 16:51, henry <he...@callistohouse.club> wrote:
 How about Kerberos? Can we get a team to look closely at bringing integration 
for enterprise users? That would be helpful, or can you just put it behind a 
Kerberos wrapper? If that would work, collecting a demo, that could unlock more 
corporate wallets , for investment. 


- HH


On Fri, Oct 27, 2017 at 16:41, henry <he...@callistohouse.club> wrote:
How is there no steering committee to accumulate wrapping 3rd party libraries 
in Alien to gain benefits of code in other languages? Do not assume that code 
is not extremely well written in that particular language for that particular 
task and that particular deployment mechanism.

Can Pharo be called as a shared library from Java JNA?

- HH


On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglyn...@gmail.com> wrote:
I’m not claiming I don’t or haven’t been affected, only that I no long allow 
myself to be.  Does that cause issues?  Of course.  But I’d rather deal with 
those than do things I don’t enjoy.  However I only got to that point after 26 
years in the industry, so I don’t expect that everyone will feel that way.
  
Cheers
Andrew
  
Sent from Mail for Windows 10
  
From: jtuc...@objektfabrik.de 
Sent: Thursday, October 26, 2017 8:14 AM 
To: pharo-users@lists.pharo.org 
Subject: Re: [Pharo-users] Smalltalk Argument
  
Andrew,

Am 26.10.17 um 00:46 schrieb Andrew Glynn: 
There’s other questions that are relevant to me: 
I am glad you opened your words with this sentence. Other peoples’ mileages may 
vary a lot. 
> Do I give a f*** about cool looking web apps?  No, I don’t use web apps if in 
> any way I can avoid it. 
  
Some people can’t. I can’t. I am making my living with a web based application. 
And I like it. 
  
> Do I give a f*** about mobile apps?  No, the screen’s too small to read 
> anything longer than a twit, or anyone with anything worthwhile to say.>

So you are in the lucky position that neither mobile nor web nor integration 
matters to you or you have enough resources to do all that stuff yourself. I am 
envyous. I need to build web pages and people ask me whether we can ship an 
iPhone App. I do customer-facing stuff and sex sells much more than we like to 
think.

Your comments on the crappiness of libs in other languages is a great fit for 
Smalltalk. Not invented here, therefor rubbish. We came a long way with this 
way of thinking. But these rubbish makers dance circles around us while we try 
to do our first hello world for an iPad. They laugh at us when we try to 
reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). 
Because they are back home and watch Netflix while we debug our homegrown base 
libraries that are, of course, much better than theirs because they are written 
in Smalltalk.

I am not arguing that maintaining Smalltalk code is far superior to most 
technolgies out there. But depending on the needs of our projects we have to 
learn and use those crappy technologies to accomplish what they offer. Because, 
sometimes (especially if you have to pay bills), an existing library with flaws 
is better than none.

So if I have to use Javascript or C# or Dart or Swift to do the frontend part 
of my system, is there still much benefit in using these together with 
Smalltalk? Or is there - at least from a manager’s point of view - not a 
reasonable amount of sense in choosing the frontend technology also for the 
logic and compensate the loss in productivity with a gain in avoided 
complexity? 

Your answer delivers a lot of food for thought, but I don’t buy all of it. And 
I don’t expect you to buy all of mine ;-)


Joachim








  
  
Do I give a f*** about the number of libraries in other languages?  No, because 
most of them are crap in every language I’ve had to work in, and the base 
languages are crap so they have to keep changing radically, and libraries and 
frameworks therefore also have to and never get any better. The few that are 
worthwhile I can almost always use from Smalltalk without a problem (read, 
Blender, ACT-R and Synapse, since every other library/framework I’ve used 
outside Smalltalk has

Re: [Pharo-users] Smalltalk Argument

[Andrew Glynn]

And btw, Kafka, like Storm and Spark, is a very limited, and very slow way of 
accessing Hadoop data stores.

Sent from Mail for Windows 10

From: henry
Sent: Friday, October 27, 2017 5:03 PM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument

Elastic search JSON integration would be another good one. I heard there was a 
Kafka integration, is that true? Where could I find that, I used to use Kafka.

Kafka is a great event channel for input to BigData. Using Kafka, it is well in 
crafting a Lamda Architecture. Imagine Pharo where Storm resides.



- HH


On Fri, Oct 27, 2017 at 16:51, henry <he...@callistohouse.club> wrote:
 How about Kerberos? Can we get a team to look closely at bringing integration 
for enterprise users? That would be helpful, or can you just put it behind a 
Kerberos wrapper? If that would work, collecting a demo, that could unlock more 
corporate wallets , for investment. 


- HH


On Fri, Oct 27, 2017 at 16:41, henry <he...@callistohouse.club> wrote:
How is there no steering committee to accumulate wrapping 3rd party libraries 
in Alien to gain benefits of code in other languages? Do not assume that code 
is not extremely well written in that particular language for that particular 
task and that particular deployment mechanism.

Can Pharo be called as a shared library from Java JNA?

- HH


On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglyn...@gmail.com> wrote:
I’m not claiming I don’t or haven’t been affected, only that I no long allow 
myself to be.  Does that cause issues?  Of course.  But I’d rather deal with 
those than do things I don’t enjoy.  However I only got to that point after 26 
years in the industry, so I don’t expect that everyone will feel that way.
  
Cheers
Andrew
  
Sent from Mail for Windows 10
  
From: jtuc...@objektfabrik.de 
Sent: Thursday, October 26, 2017 8:14 AM 
To: pharo-users@lists.pharo.org 
Subject: Re: [Pharo-users] Smalltalk Argument
  
Andrew,

Am 26.10.17 um 00:46 schrieb Andrew Glynn: 
There’s other questions that are relevant to me: 
I am glad you opened your words with this sentence. Other peoples’ mileages may 
vary a lot. 
> Do I give a f*** about cool looking web apps?  No, I don’t use web apps if in 
> any way I can avoid it. 
  
Some people can’t. I can’t. I am making my living with a web based application. 
And I like it. 
  
> Do I give a f*** about mobile apps?  No, the screen’s too small to read 
> anything longer than a twit, or anyone with anything worthwhile to say.>

So you are in the lucky position that neither mobile nor web nor integration 
matters to you or you have enough resources to do all that stuff yourself. I am 
envyous. I need to build web pages and people ask me whether we can ship an 
iPhone App. I do customer-facing stuff and sex sells much more than we like to 
think.

Your comments on the crappiness of libs in other languages is a great fit for 
Smalltalk. Not invented here, therefor rubbish. We came a long way with this 
way of thinking. But these rubbish makers dance circles around us while we try 
to do our first hello world for an iPad. They laugh at us when we try to 
reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). 
Because they are back home and watch Netflix while we debug our homegrown base 
libraries that are, of course, much better than theirs because they are written 
in Smalltalk.

I am not arguing that maintaining Smalltalk code is far superior to most 
technolgies out there. But depending on the needs of our projects we have to 
learn and use those crappy technologies to accomplish what they offer. Because, 
sometimes (especially if you have to pay bills), an existing library with flaws 
is better than none.

So if I have to use Javascript or C# or Dart or Swift to do the frontend part 
of my system, is there still much benefit in using these together with 
Smalltalk? Or is there - at least from a manager’s point of view - not a 
reasonable amount of sense in choosing the frontend technology also for the 
logic and compensate the loss in productivity with a gain in avoided 
complexity? 

Your answer delivers a lot of food for thought, but I don’t buy all of it. And 
I don’t expect you to buy all of mine ;-)


Joachim








  
  
Do I give a f*** about the number of libraries in other languages?  No, because 
most of them are crap in every language I’ve had to work in, and the base 
languages are crap so they have to keep changing radically, and libraries and 
frameworks therefore also have to and never get any better. The few that are 
worthwhile I can almost always use from Smalltalk without a problem (read, 
Blender, ACT-R and Synapse, since every other library/framework I’ve used 
outside Smalltalk has been a waste of time).  
  
Do I give a f*** about implementing a complex piece of machine learning 
software in 22 hours, compared to 3 months for the Java version?  Well, 
actually yes, I do, bec

Re: [Pharo-users] Smalltalk Argument

[Andrew Glynn]

An easy way of accomplishing what you want is to use Stamp to communicate with 
Synapse.  It also has the advantage of being able to throttle queries that are 
too fast for the JVM to process.  I’ve used precisely that method a number of 
times to connect to Hadoop.

Sent from Mail for Windows 10

From: henry
Sent: Friday, October 27, 2017 5:03 PM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument

Elastic search JSON integration would be another good one. I heard there was a 
Kafka integration, is that true? Where could I find that, I used to use Kafka.

Kafka is a great event channel for input to BigData. Using Kafka, it is well in 
crafting a Lamda Architecture. Imagine Pharo where Storm resides.



- HH


On Fri, Oct 27, 2017 at 16:51, henry <he...@callistohouse.club> wrote:
 How about Kerberos? Can we get a team to look closely at bringing integration 
for enterprise users? That would be helpful, or can you just put it behind a 
Kerberos wrapper? If that would work, collecting a demo, that could unlock more 
corporate wallets , for investment. 


- HH


On Fri, Oct 27, 2017 at 16:41, henry <he...@callistohouse.club> wrote:
How is there no steering committee to accumulate wrapping 3rd party libraries 
in Alien to gain benefits of code in other languages? Do not assume that code 
is not extremely well written in that particular language for that particular 
task and that particular deployment mechanism.

Can Pharo be called as a shared library from Java JNA?

- HH


On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglyn...@gmail.com> wrote:
I’m not claiming I don’t or haven’t been affected, only that I no long allow 
myself to be.  Does that cause issues?  Of course.  But I’d rather deal with 
those than do things I don’t enjoy.  However I only got to that point after 26 
years in the industry, so I don’t expect that everyone will feel that way.
  
Cheers
Andrew
  
Sent from Mail for Windows 10
  
From: jtuc...@objektfabrik.de 
Sent: Thursday, October 26, 2017 8:14 AM 
To: pharo-users@lists.pharo.org 
Subject: Re: [Pharo-users] Smalltalk Argument
  
Andrew,

Am 26.10.17 um 00:46 schrieb Andrew Glynn: 
There’s other questions that are relevant to me: 
I am glad you opened your words with this sentence. Other peoples’ mileages may 
vary a lot. 
> Do I give a f*** about cool looking web apps?  No, I don’t use web apps if in 
> any way I can avoid it. 
  
Some people can’t. I can’t. I am making my living with a web based application. 
And I like it. 
  
> Do I give a f*** about mobile apps?  No, the screen’s too small to read 
> anything longer than a twit, or anyone with anything worthwhile to say.>

So you are in the lucky position that neither mobile nor web nor integration 
matters to you or you have enough resources to do all that stuff yourself. I am 
envyous. I need to build web pages and people ask me whether we can ship an 
iPhone App. I do customer-facing stuff and sex sells much more than we like to 
think.

Your comments on the crappiness of libs in other languages is a great fit for 
Smalltalk. Not invented here, therefor rubbish. We came a long way with this 
way of thinking. But these rubbish makers dance circles around us while we try 
to do our first hello world for an iPad. They laugh at us when we try to 
reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). 
Because they are back home and watch Netflix while we debug our homegrown base 
libraries that are, of course, much better than theirs because they are written 
in Smalltalk.

I am not arguing that maintaining Smalltalk code is far superior to most 
technolgies out there. But depending on the needs of our projects we have to 
learn and use those crappy technologies to accomplish what they offer. Because, 
sometimes (especially if you have to pay bills), an existing library with flaws 
is better than none.

So if I have to use Javascript or C# or Dart or Swift to do the frontend part 
of my system, is there still much benefit in using these together with 
Smalltalk? Or is there - at least from a manager’s point of view - not a 
reasonable amount of sense in choosing the frontend technology also for the 
logic and compensate the loss in productivity with a gain in avoided 
complexity? 

Your answer delivers a lot of food for thought, but I don’t buy all of it. And 
I don’t expect you to buy all of mine ;-)


Joachim








  
  
Do I give a f*** about the number of libraries in other languages?  No, because 
most of them are crap in every language I’ve had to work in, and the base 
languages are crap so they have to keep changing radically, and libraries and 
frameworks therefore also have to and never get any better. The few that are 
worthwhile I can almost always use from Smalltalk without a problem (read, 
Blender, ACT-R and Synapse, since every other library/framework I’ve used 
outside Smalltalk has been a waste of time).  
  
Do I give a 

Re: [Pharo-users] Smalltalk Argument

[Andrew Glynn]

Btw, I don’t need to assume it’s not well written. I’ve both tested it and 
looked at the code.  

And in the vast majority of cases, It’s not.

Sent from Mail for Windows 10

From: henry
Sent: Friday, October 27, 2017 5:03 PM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument

Elastic search JSON integration would be another good one. I heard there was a 
Kafka integration, is that true? Where could I find that, I used to use Kafka.

Kafka is a great event channel for input to BigData. Using Kafka, it is well in 
crafting a Lamda Architecture. Imagine Pharo where Storm resides.



- HH


On Fri, Oct 27, 2017 at 16:51, henry <he...@callistohouse.club> wrote:
 How about Kerberos? Can we get a team to look closely at bringing integration 
for enterprise users? That would be helpful, or can you just put it behind a 
Kerberos wrapper? If that would work, collecting a demo, that could unlock more 
corporate wallets , for investment. 


- HH


On Fri, Oct 27, 2017 at 16:41, henry <he...@callistohouse.club> wrote:
How is there no steering committee to accumulate wrapping 3rd party libraries 
in Alien to gain benefits of code in other languages? Do not assume that code 
is not extremely well written in that particular language for that particular 
task and that particular deployment mechanism.

Can Pharo be called as a shared library from Java JNA?

- HH


On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglyn...@gmail.com> wrote:
I’m not claiming I don’t or haven’t been affected, only that I no long allow 
myself to be.  Does that cause issues?  Of course.  But I’d rather deal with 
those than do things I don’t enjoy.  However I only got to that point after 26 
years in the industry, so I don’t expect that everyone will feel that way.
  
Cheers
Andrew
  
Sent from Mail for Windows 10
  
From: jtuc...@objektfabrik.de 
Sent: Thursday, October 26, 2017 8:14 AM 
To: pharo-users@lists.pharo.org 
Subject: Re: [Pharo-users] Smalltalk Argument
  
Andrew,

Am 26.10.17 um 00:46 schrieb Andrew Glynn: 
There’s other questions that are relevant to me: 
I am glad you opened your words with this sentence. Other peoples’ mileages may 
vary a lot. 
> Do I give a f*** about cool looking web apps?  No, I don’t use web apps if in 
> any way I can avoid it. 
  
Some people can’t. I can’t. I am making my living with a web based application. 
And I like it. 
  
> Do I give a f*** about mobile apps?  No, the screen’s too small to read 
> anything longer than a twit, or anyone with anything worthwhile to say.>

So you are in the lucky position that neither mobile nor web nor integration 
matters to you or you have enough resources to do all that stuff yourself. I am 
envyous. I need to build web pages and people ask me whether we can ship an 
iPhone App. I do customer-facing stuff and sex sells much more than we like to 
think.

Your comments on the crappiness of libs in other languages is a great fit for 
Smalltalk. Not invented here, therefor rubbish. We came a long way with this 
way of thinking. But these rubbish makers dance circles around us while we try 
to do our first hello world for an iPad. They laugh at us when we try to 
reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). 
Because they are back home and watch Netflix while we debug our homegrown base 
libraries that are, of course, much better than theirs because they are written 
in Smalltalk.

I am not arguing that maintaining Smalltalk code is far superior to most 
technolgies out there. But depending on the needs of our projects we have to 
learn and use those crappy technologies to accomplish what they offer. Because, 
sometimes (especially if you have to pay bills), an existing library with flaws 
is better than none.

So if I have to use Javascript or C# or Dart or Swift to do the frontend part 
of my system, is there still much benefit in using these together with 
Smalltalk? Or is there - at least from a manager’s point of view - not a 
reasonable amount of sense in choosing the frontend technology also for the 
logic and compensate the loss in productivity with a gain in avoided 
complexity? 

Your answer delivers a lot of food for thought, but I don’t buy all of it. And 
I don’t expect you to buy all of mine ;-)


Joachim








  
  
Do I give a f*** about the number of libraries in other languages?  No, because 
most of them are crap in every language I’ve had to work in, and the base 
languages are crap so they have to keep changing radically, and libraries and 
frameworks therefore also have to and never get any better. The few that are 
worthwhile I can almost always use from Smalltalk without a problem (read, 
Blender, ACT-R and Synapse, since every other library/framework I’ve used 
outside Smalltalk has been a waste of time).  
  
Do I give a f*** about implementing a complex piece of machine learning 
software in 22 hours, compared to 3 months for the Java ve

Re: [Pharo-users] Smalltalk Argument

[Andrew Glynn]

Web dev is a messy field.  Not because it has grown too fast, but because it 
was designed by amateurs, developed by amateurs, and continues to be so, while 
depending on an underlying expertly designed system, the internet.

You can see the results in REST / ROA.  Neither could work at all without the 
underlying stateful, complex (in terms of behavior), and very well written code 
that runs DNS, the main registrars, TCP/IP itself (which is not, like REST, a 
very limited protocol turned into an interface), etc.

One hilarious aspect of REST is that, due to being HTTP redone, it continues to 
have the POST method, which happens to contradict ROA completely, yet they were 
defined together by the same person.

Sent from Mail for Windows 10

From: Dimitris Chloupis
Sent: Thursday, October 26, 2017 8:54 AM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument

Well all languages have well designed and badly designed libraries , in Pharo 
you dont even have to look hard just take a look at Morph and Object class and 
awe at all those irrelevant methods trying to cram in features you will 
probably never use. Especially my experience with Morphic has been as 
nightmarish as my experience with MFC. And MFC is a C++ library and made by 
Microsoft. On the other hand QT is a brilliantly designed GUI API (again for 
C++) and dont even get me started on DELPHI libraries which to this day I 
consider top when it comes to OO libraries. together with its IDE (but I never 
liked its language). 

Web dev may be a messy field mainly because it has grown too fast, after the 
web explosion ,  based on problematic concepts but desktop libraries and as a 
consequence mobile dev libraries (iOS is a variable of MacoOS, Android a 
variant of Linux) in a much , much better position and some of them have 
stellar designs. Mainly because are far more mature with decades of extremely 
active development.

Of course many of those great design are the result of a reaction to bad 
designs and lessons learned from other APIs. There is no good design without a 
redesign. 

My personal opinion is that as pessimistic it may sound, Smalltalk has very 
little to offer in the library front. The language is still stellar and live 
environment is a great concept but from there on there is a decline. Sure if 
your are low demand kind of person on the library front and dont mind 
implementing stuff by yourself you wont mind the lack of libraries but most 
coders , me included , dont have this luxury. Especially making a living with a 
language is a completely different story from learning it as a hobby, 

I think and that's a personal opinion, that Smalltalk goes the wrong direction. 
It tries to be a do it all language, but we already have an army of do it all 
languages. I think it would excel as the backbone in big complex projects. Like 
the Moose project is doing with code analysis and visualization. I think this 
is an excellent direction to go with Smalltalk. Reflection is the big strength 
of Smalltalk the ability to communicate with its code in a direct matter. So I 
think that a Smalltalk implementation that can analyze and visualize code 
written in other languages would have been a pretty serious reason for people 
to learn Smalltalk. 

I am very happy to see Pharo go towards that direction and yes I would 
definitely recommend it without hesitation  for code analysis and project 
management tool. Its no coincidence that we have seen a serious growth in our 
community. When I joined back in 2011 we all were posting at pharo-dev, 
pharo-users was a dead zone and then the community grow larger and larger we 
soon may need a third mailing list. 

Code complexity is an issues for all large projects and tools that help manage 
this without having to convert to another language are very popular.     




On Thu, Oct 26, 2017 at 3:14 PM jtuc...@objektfabrik.de 
<jtuc...@objektfabrik.de> wrote:
Andrew,

Am 26.10.17 um 00:46 schrieb Andrew Glynn:
There’s other questions that are relevant to me:
I am glad you opened your words with this sentence. Other peoples' mileages may 
vary a lot.

> Do I give a f*** about cool looking web apps?  No, I don’t use web apps if in 
> any way I can avoid it.

Some people can't. I can't. I am making my living with a web based application. 
And I like it.
 
> Do I give a f*** about mobile apps?  No, the screen’s too small to read 
> anything longer than a twit, or anyone with anything worthwhile to say.>
So you are in the lucky position that neither mobile nor web nor integration 
matters to you or you have enough resources to do all that stuff yourself. I am 
envyous. I need to build web pages and people ask me whether we can ship an 
iPhone App. I do customer-facing stuff and sex sells much more than we like to 
think.

Your comments on the crappiness of libs in other languages is a great fit for 
Smalltalk. Not invented here, therefor rubbish. We came a lo

Re: [Pharo-users] Smalltalk Argument

[Ben Coman]

On Sat, Oct 28, 2017 at 8:30 AM, Andrew Glynn  wrote:

> One thing I’m working on is a bridge between Pharo and F-Script.  F-Script
> is, basically, a Smalltalk dialect, as is obvious from the screenshot.
> However for MacOS and iOS, it allows you to bypass the static Objective-C
> API interface and debug / modify or even write applications directly in the
> system.  To do that you ‘inject’ F-Script into the OS.  The ability to so
> has a specific implication, though.  MacOS and iOS are themselves written
> in and as a dialect of Smalltalk.  (were it simply an overlay on
> Objective-C, it wouldn’t be able to do things that are impossible in
> Objective-C, and it wouldn’t need to be ‘injected’ in order to run).  Every
> implementation of Objective-C , bar GNU’s useless imitation, compiles to
> Smalltalk.  No surprise that Apple’s does, as well.
>
>
>
> In any event, it will allow Pharo code to be mapped to MacOS and iOS
> objects, injected into the system dynamically, and modified / debugged
> dynamically using the Pharo tools.  The result, at least as far as iOS is
> concerned, may make Pharo actually the most powerful way to program it,
> well beyond XCode alone, along with doing the same for MacOS.
>

It would be really interesting to see a blog post and/or video of working
like this with OS level objects.
Also its something that might capture the curiosity of hackers outside the
Pharo community.

cheers -ben

Re: [Pharo-users] Smalltalk Argument

[Andrew Glynn]

Your points are, as usual, very accurate.  However the percentage of rarely 
used methods in JavaEE makes those in Morphic look nearly irrelevant.

The more important question for me is whether they interfere or not.

Sent from Mail for Windows 10

From: Dimitris Chloupis
Sent: Thursday, October 26, 2017 8:54 AM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument

Well all languages have well designed and badly designed libraries , in Pharo 
you dont even have to look hard just take a look at Morph and Object class and 
awe at all those irrelevant methods trying to cram in features you will 
probably never use. Especially my experience with Morphic has been as 
nightmarish as my experience with MFC. And MFC is a C++ library and made by 
Microsoft. On the other hand QT is a brilliantly designed GUI API (again for 
C++) and dont even get me started on DELPHI libraries which to this day I 
consider top when it comes to OO libraries. together with its IDE (but I never 
liked its language). 

Web dev may be a messy field mainly because it has grown too fast, after the 
web explosion ,  based on problematic concepts but desktop libraries and as a 
consequence mobile dev libraries (iOS is a variable of MacoOS, Android a 
variant of Linux) in a much , much better position and some of them have 
stellar designs. Mainly because are far more mature with decades of extremely 
active development.

Of course many of those great design are the result of a reaction to bad 
designs and lessons learned from other APIs. There is no good design without a 
redesign. 

My personal opinion is that as pessimistic it may sound, Smalltalk has very 
little to offer in the library front. The language is still stellar and live 
environment is a great concept but from there on there is a decline. Sure if 
your are low demand kind of person on the library front and dont mind 
implementing stuff by yourself you wont mind the lack of libraries but most 
coders , me included , dont have this luxury. Especially making a living with a 
language is a completely different story from learning it as a hobby, 

I think and that's a personal opinion, that Smalltalk goes the wrong direction. 
It tries to be a do it all language, but we already have an army of do it all 
languages. I think it would excel as the backbone in big complex projects. Like 
the Moose project is doing with code analysis and visualization. I think this 
is an excellent direction to go with Smalltalk. Reflection is the big strength 
of Smalltalk the ability to communicate with its code in a direct matter. So I 
think that a Smalltalk implementation that can analyze and visualize code 
written in other languages would have been a pretty serious reason for people 
to learn Smalltalk. 

I am very happy to see Pharo go towards that direction and yes I would 
definitely recommend it without hesitation  for code analysis and project 
management tool. Its no coincidence that we have seen a serious growth in our 
community. When I joined back in 2011 we all were posting at pharo-dev, 
pharo-users was a dead zone and then the community grow larger and larger we 
soon may need a third mailing list. 

Code complexity is an issues for all large projects and tools that help manage 
this without having to convert to another language are very popular.     




On Thu, Oct 26, 2017 at 3:14 PM jtuc...@objektfabrik.de 
<jtuc...@objektfabrik.de> wrote:
Andrew,

Am 26.10.17 um 00:46 schrieb Andrew Glynn:
There’s other questions that are relevant to me:
I am glad you opened your words with this sentence. Other peoples' mileages may 
vary a lot.

> Do I give a f*** about cool looking web apps?  No, I don’t use web apps if in 
> any way I can avoid it.

Some people can't. I can't. I am making my living with a web based application. 
And I like it.
 
> Do I give a f*** about mobile apps?  No, the screen’s too small to read 
> anything longer than a twit, or anyone with anything worthwhile to say.>
So you are in the lucky position that neither mobile nor web nor integration 
matters to you or you have enough resources to do all that stuff yourself. I am 
envyous. I need to build web pages and people ask me whether we can ship an 
iPhone App. I do customer-facing stuff and sex sells much more than we like to 
think.

Your comments on the crappiness of libs in other languages is a great fit for 
Smalltalk. Not invented here, therefor rubbish. We came a long way with this 
way of thinking. But these rubbish makers dance circles around us while we try 
to do our first hello world for an iPad. They laugh at us when we try to 
reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). 
Because they are back home and watch Netflix while we debug our homegrown base 
libraries that are, of course, much better than theirs because they are written 
in Smalltalk.

I am not arguing that maintaining Smalltalk code is far superior to 

Re: [Pharo-users] Smalltalk Argument

[Andrew Glynn]

I’ve never needed or seen any reason to implement MVC on Seaside, since it has 
a superior model to begin with.  It would seem to me like implementing Vert.x 
over JINI, rather than the inverse.  

I’m curious though why you see a need to do so, i.e. what requirements you’re 
being given that make it necessary.

Sent from Mail for Windows 10

From: jtuc...@objektfabrik.de
Sent: Thursday, October 26, 2017 8:14 AM
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] Smalltalk Argument

Andrew,

Am 26.10.17 um 00:46 schrieb Andrew Glynn:
There’s other questions that are relevant to me:
I am glad you opened your words with this sentence. Other peoples' mileages may 
vary a lot.
> Do I give a f*** about cool looking web apps?  No, I don’t use web apps if in 
> any way I can avoid it.

Some people can't. I can't. I am making my living with a web based application. 
And I like it.
 
> Do I give a f*** about mobile apps?  No, the screen’s too small to read 
> anything longer than a twit, or anyone with anything worthwhile to say.>

So you are in the lucky position that neither mobile nor web nor integration 
matters to you or you have enough resources to do all that stuff yourself. I am 
envyous. I need to build web pages and people ask me whether we can ship an 
iPhone App. I do customer-facing stuff and sex sells much more than we like to 
think.

Your comments on the crappiness of libs in other languages is a great fit for 
Smalltalk. Not invented here, therefor rubbish. We came a long way with this 
way of thinking. But these rubbish makers dance circles around us while we try 
to do our first hello world for an iPad. They laugh at us when we try to 
reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). 
Because they are back home and watch Netflix while we debug our homegrown base 
libraries that are, of course, much better than theirs because they are written 
in Smalltalk.

I am not arguing that maintaining Smalltalk code is far superior to most 
technolgies out there. But depending on the needs of our projects we have to 
learn and use those crappy technologies to accomplish what they offer. Because, 
sometimes (especially if you have to pay bills), an existing library with flaws 
is better than none.

So if I have to use Javascript or C# or Dart or Swift to do the frontend part 
of my system, is there still much benefit in using these together with 
Smalltalk? Or is there - at least from a manager's point of view - not a 
reasonable amount of sense in choosing the frontend technology also for the 
logic and compensate the loss in productivity with a gain in avoided 
complexity? 

Your answer delivers a lot of food for thought, but I don't buy all of it. And 
I don't expect you to buy all of mine ;-)


Joachim









 
 
Do I give a f*** about the number of libraries in other languages?  No, because 
most of them are crap in every language I’ve had to work in, and the base 
languages are crap so they have to keep changing radically, and libraries and 
frameworks therefore also have to and never get any better. The few that are 
worthwhile I can almost always use from Smalltalk without a problem (read, 
Blender, ACT-R and Synapse, since every other library/framework I’ve used 
outside Smalltalk has been a waste of time).  
 
Do I give a f*** about implementing a complex piece of machine learning 
software in 22 hours, compared to 3 months for the Java version?  Well, 
actually yes, I do, because that was 3 months of my life down the toilet for 
something that is too slow to be useful in Java.
 
Any argument depends on your priorities. I’ve written tons of web apps, because 
I needed to get paid.  I’ve written better shitty mobile apps than the average 
shitty mobile apps.  However, I’m not going to do any of that any longer in 
crap that never improves, because after 26 years the irritability it produces 
is more than it’s worth.  
 
A few weeks ago, a recruiter that specializes in Smalltalk called me about a 
job, although they were well aware I live 1500 miles away from the city I lived 
in when I had worked through them, to see if I’d be willing to move back there 
for a job.  That sounds like another ‘there aren’t enough Smalltalk 
developers”, but it wasn’t, because the job wasn’t writing Smalltalk.  It was 
writing Java.
 
The person hiring, though, wouldn’t look at anyone who didn’t write Smalltalk, 
because “people who grew up with Java don’t know how to write code”.  I don’t 
agree with that, I’ve known a (very few) good Java developers.  I would say, 
though, that I’ve known far more incompetent ones than good ones, and I can’t 
think of any incompetent Smalltalk developers off the top of my head.  
 
Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or even C, 
complain about how hard maintaining state is or coming up with various hacks to 
avoid it, which seems to be the main point of every JavaScript based 
‘technology’. 

Re: [Pharo-users] Smalltalk Argument

[henry]

Elastic search JSON integration would be another good one. I heard there was a 
Kafka integration, is that true? Where could I find that, I used to use Kafka.

Kafka is a great event channel for input to BigData. Using Kafka, it is well in 
crafting a Lamda Architecture. Imagine Pharo where Storm resides.

- HH

On Fri, Oct 27, 2017 at 16:51, henry 
<[he...@callistohouse.club]("mailto:he...@callistohouse.club;)> wrote:

>  How about Kerberos? Can we get a team to look closely at bringing 
> integration for enterprise users? That would be helpful, or can you just put 
> it behind a Kerberos wrapper? If that would work, collecting a demo, that 
> could unlock more corporate wallets , for investment.
>
> - HH
>
> On Fri, Oct 27, 2017 at 16:41, henry 
> <[he...@callistohouse.club](""mailto:he...@callistohouse.club";)> wrote:
>
>> How is there no steering committee to accumulate wrapping 3rd party 
>> libraries in Alien to gain benefits of code in other languages? Do not 
>> assume that code is not extremely well written in that particular language 
>> for that particular task and that particular deployment mechanism.
>>
>> Can Pharo be called as a shared library from Java JNA?
>>
>> - HH
>>
>> On Fri, Oct 27, 2017 at 15:47, Andrew Glynn 
>> <[aglyn...@gmail.com](""mailto:aglyn...@gmail.com";)> wrote:
>>
>>> I’m not claiming I don’t or haven’t been affected, only that I no long 
>>> allow myself to be.  Does that cause issues?  Of course.  But I’d rather 
>>> deal with those than do things I don’t enjoy.  However I only got to that 
>>> point after 26 years in the industry, so I don’t expect that everyone will 
>>> feel that way.
>>>
>>> Cheers
>>>
>>> Andrew
>>>
>>> Sent from [Mail](""https://go.microsoft.com/fwlink/?LinkId=550986";) for 
>>> Windows 10
>>>
>>> From: [jtuc...@objektfabrik.de](""mailto:jtuc...@objektfabrik.de";)
>>> Sent: Thursday, October 26, 2017 8:14 AM
>>> To: [pharo-users@lists.pharo.org](""mailto:pharo-users@lists.pharo.org";)
>>> Subject: Re: [Pharo-users] Smalltalk Argument
>>>
>>> Andrew,
>>>
>>> Am 26.10.17 um 00:46 schrieb Andrew Glynn:
>>>
>>>> There’s other questions that are relevant to me:
>>>
>>> I am glad you opened your words with this sentence. Other peoples’ mileages 
>>> may vary a lot.
>>>
>>>> Do I give a f*** about cool looking web apps?  No, I don’t use web apps if 
>>>> in any way I can avoid it.
>>>
>>> Some people can’t. I can’t. I am making my living with a web based 
>>> application. And I like it.
>>>
>>>> Do I give a f*** about mobile apps?  No, the screen’s too small to read 
>>>> anything longer than a twit, or anyone with anything worthwhile to say.>
>>>
>>> So you are in the lucky position that neither mobile nor web nor 
>>> integration matters to you or you have enough resources to do all that 
>>> stuff yourself. I am envyous. I need to build web pages and people ask me 
>>> whether we can ship an iPhone App. I do customer-facing stuff and sex sells 
>>> much more than we like to think.
>>>
>>> Your comments on the crappiness of libs in other languages is a great fit 
>>> for Smalltalk. Not invented here, therefor rubbish. We came a long way with 
>>> this way of thinking. But these rubbish makers dance circles around us 
>>> while we try to do our first hello world for an iPad. They laugh at us when 
>>> we try to reinvent MVC on top of Seaside (although MVC is closesly related 
>>> to Smalltalk). Because they are back home and watch Netflix while we debug 
>>> our homegrown base libraries that are, of course, much better than theirs 
>>> because they are written in Smalltalk.
>>>
>>> I am not arguing that maintaining Smalltalk code is far superior to most 
>>> technolgies out there. But depending on the needs of our projects we have 
>>> to learn and use those crappy technologies to accomplish what they offer. 
>>> Because, sometimes (especially if you have to pay bills), an existing 
>>> library with flaws is better than none.
>>>
>>> So if I have to use Javascript or C# or Dart or Swift to do the frontend 
>>> part of my system, is there still much benefit in using these together with 
>>> Smalltalk? Or is there - at least from a manager’s point of view - not a 
>>> reasonable amount of sense i

Re: [Pharo-users] Smalltalk Argument

[henry]

How about Kerberos? Can we get a team to look closely at bringing integration 
for enterprise users? That would be helpful, or can you just put it behind a 
Kerberos wrapper? If that would work, collecting a demo, that could unlock more 
corporate wallets , for investment.

- HH

On Fri, Oct 27, 2017 at 16:41, henry 
<[he...@callistohouse.club]("mailto:he...@callistohouse.club;)> wrote:

> How is there no steering committee to accumulate wrapping 3rd party libraries 
> in Alien to gain benefits of code in other languages? Do not assume that code 
> is not extremely well written in that particular language for that particular 
> task and that particular deployment mechanism.
>
> Can Pharo be called as a shared library from Java JNA?
>
> - HH
>
> On Fri, Oct 27, 2017 at 15:47, Andrew Glynn 
> <[aglyn...@gmail.com]("mailto:aglyn...@gmail.com;)> wrote:
>
>> I’m not claiming I don’t or haven’t been affected, only that I no long allow 
>> myself to be.  Does that cause issues?  Of course.  But I’d rather deal with 
>> those than do things I don’t enjoy.  However I only got to that point after 
>> 26 years in the industry, so I don’t expect that everyone will feel that way.
>>
>> Cheers
>>
>> Andrew
>>
>> Sent from [Mail]("https://go.microsoft.com/fwlink/?LinkId=550986;) for 
>> Windows 10
>>
>> From: [jtuc...@objektfabrik.de]("mailto:jtuc...@objektfabrik.de;)
>> Sent: Thursday, October 26, 2017 8:14 AM
>> To: [pharo-users@lists.pharo.org]("mailto:pharo-users@lists.pharo.org;)
>> Subject: Re: [Pharo-users] Smalltalk Argument
>>
>> Andrew,
>>
>> Am 26.10.17 um 00:46 schrieb Andrew Glynn:
>>
>>> There’s other questions that are relevant to me:
>>
>> I am glad you opened your words with this sentence. Other peoples’ mileages 
>> may vary a lot.
>>
>>> Do I give a f*** about cool looking web apps?  No, I don’t use web apps if 
>>> in any way I can avoid it.
>>
>> Some people can’t. I can’t. I am making my living with a web based 
>> application. And I like it.
>>
>>> Do I give a f*** about mobile apps?  No, the screen’s too small to read 
>>> anything longer than a twit, or anyone with anything worthwhile to say.>
>>
>> So you are in the lucky position that neither mobile nor web nor integration 
>> matters to you or you have enough resources to do all that stuff yourself. I 
>> am envyous. I need to build web pages and people ask me whether we can ship 
>> an iPhone App. I do customer-facing stuff and sex sells much more than we 
>> like to think.
>>
>> Your comments on the crappiness of libs in other languages is a great fit 
>> for Smalltalk. Not invented here, therefor rubbish. We came a long way with 
>> this way of thinking. But these rubbish makers dance circles around us while 
>> we try to do our first hello world for an iPad. They laugh at us when we try 
>> to reinvent MVC on top of Seaside (although MVC is closesly related to 
>> Smalltalk). Because they are back home and watch Netflix while we debug our 
>> homegrown base libraries that are, of course, much better than theirs 
>> because they are written in Smalltalk.
>>
>> I am not arguing that maintaining Smalltalk code is far superior to most 
>> technolgies out there. But depending on the needs of our projects we have to 
>> learn and use those crappy technologies to accomplish what they offer. 
>> Because, sometimes (especially if you have to pay bills), an existing 
>> library with flaws is better than none.
>>
>> So if I have to use Javascript or C# or Dart or Swift to do the frontend 
>> part of my system, is there still much benefit in using these together with 
>> Smalltalk? Or is there - at least from a manager’s point of view - not a 
>> reasonable amount of sense in choosing the frontend technology also for the 
>> logic and compensate the loss in productivity with a gain in avoided 
>> complexity?
>>
>> Your answer delivers a lot of food for thought, but I don’t buy all of it. 
>> And I don’t expect you to buy all of mine ;-)
>>
>> Joachim
>>
>>>
>>>
>>> Do I give a f*** about the number of libraries in other languages?  No, 
>>> because most of them are crap in every language I’ve had to work in, and 
>>> the base languages are crap so they have to keep changing radically, and 
>>> libraries and frameworks therefore also have to and never get any better. 
>>> The few that are worthwhile I can almost always use from Smalltalk without 
>>> a problem (read, Blender, ACT-R and Syn

Re: [Pharo-users] Smalltalk Argument

[henry]

How is there no steering committee to accumulate wrapping 3rd party libraries 
in Alien to gain benefits of code in other languages? Do not assume that code 
is not extremely well written in that particular language for that particular 
task and that particular deployment mechanism.

Can Pharo be called as a shared library from Java JNA?

- HH

On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglyn...@gmail.com> wrote:

> I’m not claiming I don’t or haven’t been affected, only that I no long allow 
> myself to be.  Does that cause issues?  Of course.  But I’d rather deal with 
> those than do things I don’t enjoy.  However I only got to that point after 
> 26 years in the industry, so I don’t expect that everyone will feel that way.
>
> Cheers
>
> Andrew
>
> Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 
> 10
>
> From: jtuc...@objektfabrik.de
> Sent: Thursday, October 26, 2017 8:14 AM
> To: pharo-users@lists.pharo.org
> Subject: Re: [Pharo-users] Smalltalk Argument
>
> Andrew,
>
> Am 26.10.17 um 00:46 schrieb Andrew Glynn:
>
>> There’s other questions that are relevant to me:
>
> I am glad you opened your words with this sentence. Other peoples' mileages 
> may vary a lot.
>
>> Do I give a f*** about cool looking web apps?  No, I don’t use web apps if 
>> in any way I can avoid it.
>
> Some people can't. I can't. I am making my living with a web based 
> application. And I like it.
>
>> Do I give a f*** about mobile apps?  No, the screen’s too small to read 
>> anything longer than a twit, or anyone with anything worthwhile to say.>
>
> So you are in the lucky position that neither mobile nor web nor integration 
> matters to you or you have enough resources to do all that stuff yourself. I 
> am envyous. I need to build web pages and people ask me whether we can ship 
> an iPhone App. I do customer-facing stuff and sex sells much more than we 
> like to think.
>
> Your comments on the crappiness of libs in other languages is a great fit for 
> Smalltalk. Not invented here, therefor rubbish. We came a long way with this 
> way of thinking. But these rubbish makers dance circles around us while we 
> try to do our first hello world for an iPad. They laugh at us when we try to 
> reinvent MVC on top of Seaside (although MVC is closesly related to 
> Smalltalk). Because they are back home and watch Netflix while we debug our 
> homegrown base libraries that are, of course, much better than theirs because 
> they are written in Smalltalk.
>
> I am not arguing that maintaining Smalltalk code is far superior to most 
> technolgies out there. But depending on the needs of our projects we have to 
> learn and use those crappy technologies to accomplish what they offer. 
> Because, sometimes (especially if you have to pay bills), an existing library 
> with flaws is better than none.
>
> So if I have to use Javascript or C# or Dart or Swift to do the frontend part 
> of my system, is there still much benefit in using these together with 
> Smalltalk? Or is there - at least from a manager's point of view - not a 
> reasonable amount of sense in choosing the frontend technology also for the 
> logic and compensate the loss in productivity with a gain in avoided 
> complexity?
>
> Your answer delivers a lot of food for thought, but I don't buy all of it. 
> And I don't expect you to buy all of mine ;-)
>
> Joachim
>
>>
>>
>> Do I give a f*** about the number of libraries in other languages?  No, 
>> because most of them are crap in every language I’ve had to work in, and the 
>> base languages are crap so they have to keep changing radically, and 
>> libraries and frameworks therefore also have to and never get any better. 
>> The few that are worthwhile I can almost always use from Smalltalk without a 
>> problem (read, Blender, ACT-R and Synapse, since every other 
>> library/framework I’ve used outside Smalltalk has been a waste of time).
>>
>> Do I give a f*** about implementing a complex piece of machine learning 
>> software in 22 hours, compared to 3 months for the Java version?  Well, 
>> actually yes, I do, because that was 3 months of my life down the toilet for 
>> something that is too slow to be useful in Java.
>>
>> Any argument depends on your priorities. I’ve written tons of web apps, 
>> because I needed to get paid.  I’ve written better shitty mobile apps than 
>> the average shitty mobile apps.  However, I’m not going to do any of that 
>> any longer in crap that never improves, because after 26 years the 
>> irritability it produces is more than it’s worth.
>>
>> A few weeks ago, a recruiter that specializes in Small

Re: [Pharo-users] Smalltalk Argument

[henry]

I confuse easily, as you say freeipa works wonderfully well, then point out sun 
support to the api is hidden and it’s tricky to use. Do you mean Hadoop’s use 
is iffy?

If freeipa works wonderfully can we find the right api and sequence of calls, 
building our own model in image side? Then that model we compute on and it 
makes the right calls. Modeling is our strength, I have always thought.

What is achievable? This would benefit ParrotTalk I think.

- HH

On Thu, Oct 26, 2017 at 16:28, philippe.b...@highoctane.be 
<philippe.b...@gmail.com> wrote:

> There are two key Kerberos implementations one can use with Hadoop.
>
> One is the FreeIpa/RedHat IdM.
> The other is ActiveDirectory.
>
> I am using FreeIPA which bundles MIT Kerberos/389/sssd and more for making a 
> CA etc. Works wonderfullý well.
>
> AD is well ... part of the corporate landdscape.
>
> Most of Kerberos needs are done with Java in Hadoop. But details are buried 
> in private Sun classes..
>
> Google Madness beyond the gate hadoop for some Lovecraftian quotes describing 
> the situation along educated info.
>
> Phil
>
> On Oct 26, 2017 18:23, "henry" <he...@callistohouse.club> wrote:
>
>> I have no idea which is best. For being able to say we use industry standard 
>> Kerberos, calling an accepted implementation seems wise, like OpenSSL 
>> support.
>>
>> - HH
>>
>> On Thu, Oct 26, 2017 at 11:39, Paulo R. Dellani <dell...@pobox.com> wrote:
>>
>>> This all sounds very interesting. What is the idea? Wrap libkrb5 through 
>>> UFFI or implement it in Smalltalk?
>>>
>>> On 10/26/2017 04:38 PM, henry wrote:
>>>
>>>> A Kerberos effort will have to be a group effort. Sideways to my main 
>>>> focus and your all’s main focii.
>>>>
>>>> - HH
>>>>
>>>> On Thu, Oct 26, 2017 at 09:15, henry <he...@callistohouse.club> wrote:
>>>>
>>>>> I think another good service to integrate well to is Elastic Search.
>>>>>
>>>>> Of the 4 types of integration, I vote for and step forward to volunteer 
>>>>> to help Kerberos integration in Pharo. What to do?
>>>>>
>>>>> - HH
>>>>>
>>>>> On Thu, Oct 26, 2017 at 09:06, henry <he...@callistohouse.club> wrote:
>>>>>
>>>>>> I try posting with a smaller image.
>>>>>>
>>>>>> [""hubbub.jpg""]
>>>>>>
>>>>>> - HH
>>>>>>
>>>>>>> ——— Original Message ———
>>>>>>> Subject: Re: [Pharo-users] Smalltalk Argument
>>>>>>> Local Time: October 26, 2017 8:52 AM
>>>>>>> UTC Time: October 26, 2017 12:52 PM
>>>>>>> From: he...@callistohouse.club
>>>>>>> To: p...@highoctane.be 
>>>>>>> [<p...@highoctane.be>](mailto:p...@highoctane.be), Any question about 
>>>>>>> pharo is welcome 
>>>>>>> [<pharo-users@lists.pharo.org>](mailto:pharo-users@lists.pharo.org)
>>>>>>>
>>>>>>> Perhaps not, or not yet. Perhaps it is the communications foundation 
>>>>>>> for an always-on cloud/bigData control layer.
>>>>>>>
>>>>>>> I would position ParrotTalk as a Kerberos transport. ParrotTalk does 
>>>>>>> 2048-bin key negotiation and subsequent encryption/encoding, both 
>>>>>>> user-supplied.
>>>>>>>
>>>>>>> Please see the attached diagram, co-locating ParrotTalk with my other 
>>>>>>> components.
>>>>>>>
>>>>>>> ParrotTalk does not do user authentication/authorization. Which means 
>>>>>>> to me that I should consider Kerberos authorization/authentication to 
>>>>>>> establish as an integratable transport to play in bigData.
>>>>>>>
>>>>>>> This means you still need a Kerberos client and I need a Kerberos 
>>>>>>> client. How do we start?
>>>>>>>
>>>>>>> - HH
>>>>>>>
>>>>>>> PS: I did much work integrating Kafka into a framework. I was thinking 
>>>>>>> of inserting msg sending replication to a partition count of replicate 
>>>>>>> queues for sending and receiving Hubbub traffic, thus inserting right 
>>>>>>> where Kerberos is in the 

Re: [Pharo-users] Smalltalk Argument

[Ben Coman]

On Thu, Oct 26, 2017 at 3:40 PM, Paulo R. Dellani  wrote:

> I like your depiction of the situation and arguments, Andrew.
>
> The inherent volatility of the software industry due to its tendency
> to self disruption, as you pointed out, is fertile ground to all kinds of
> crap, but we as developers should keep our eyes wide open and
> look for the pearls and gems that grow here and there,
> like Pharo Smalltalk.
>
> Of course my "vision", as a Smalltalker is inherently biased, but
> as you said, when "shit has to work", I think that we have good
> cards at our hands.
>

If that is a key requirement, share these with your stakeholders...
* GemStone:64 Update and Roadmap

https://www.youtube.com/watch?v=ejtXqJoSrb4=PLJ5nSnWzQXi_THfKwhzxFwbXy00YTi0uv=28
* Running Pharo on the GemStone VM

https://www.youtube.com/watch?v=TkvjUXn3tGs=PLJ5nSnWzQXi_THfKwhzxFwbXy00YTi0uv=3

"Develop on Pharo, Deploy on Gemstone" seems to be a growing meme.



> So yesterday we had another meeting and I think I could make a
> good point for Smalltalk, thanks to all your arguments here at the
> list. But surely the absolute killer argument is that "this shit really
> works" :-)
>
> As pointed out by several of you, integration is key. For my particular
> present case, I could successfully integrate the developed tools in
> the system, a medical imaging processing pipeline,
>

Juan might be able to advise on the suitability of Smalltalk for image
processing...
*
https://news.squeak.org/2017/05/24/satellogic-hyperspectral-cameras-geometric-and-spectral-processing-software-written-in-cuis-smalltalk/
* https://www.nature.com/articles/n-12305964

Regarding the reality of Pharo having less libraries than mainstream
languages.  I am reminded of this interesting perspective...
*
https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/

that reuse is not always an advantage.  Certainly FFI provides access to a
large selection of pre-made libraries - but it opens applications to memory
protection faults and other quirks that make debugging more difficult.  As
always, its "horses for courses".

cheers -ben

Re: [Pharo-users] Smalltalk Argument

[p...@highoctane.be]

There are two key Kerberos implementations one can use with Hadoop.

One is the FreeIpa/RedHat IdM.
The other is ActiveDirectory.

I am using FreeIPA which bundles MIT Kerberos/389/sssd and more for making
a CA etc. Works wonderfullý well.

AD is well ... part of the corporate landdscape.

Most of Kerberos needs are done with Java in Hadoop. But details are buried
in private Sun classes..

Google Madness beyond the gate hadoop for some Lovecraftian quotes
describing the situation along educated info.

Phil

On Thu, Oct 26, 2017 at 6:23 PM, henry <he...@callistohouse.club> wrote:

> I have no idea which is best. For being able to say we use industry
> standard Kerberos, calling an accepted implementation seems wise, like
> OpenSSL support.
>
> - HH
>
>
> On Thu, Oct 26, 2017 at 11:39, Paulo R. Dellani <dell...@pobox.com> wrote:
>
> This all sounds very interesting. What is the idea? Wrap libkrb5 through
> UFFI or implement it in Smalltalk?
>
> On 10/26/2017 04:38 PM, henry wrote:
>
> A Kerberos effort will have to be a group effort. Sideways to my main
> focus and your all’s main focii.
>
>
> - HH
>
>
> On Thu, Oct 26, 2017 at 09:15, henry <he...@callistohouse.club> wrote:
>
> I think another good service to integrate well to is Elastic Search.
>
> Of the 4 types of integration, I vote for and step forward to volunteer to
> help Kerberos integration in Pharo. What to do?
>
>
> - HH
>
>
> On Thu, Oct 26, 2017 at 09:06, henry <he...@callistohouse.club> wrote:
>
> I try posting with a smaller image.
>
> [image: ""hubbub.jpg""]
>
> - HH
>
>
> ——— Original Message ———
> Subject: Re: [Pharo-users] Smalltalk Argument
> Local Time: October 26, 2017 8:52 AM
> UTC Time: October 26, 2017 12:52 PM
> From: he...@callistohouse.club
> To: p...@highoctane.be <p...@highoctane.be> <p...@highoctane.be>, Any
> question about pharo is welcome <pharo-users@lists.pharo.org>
> <pharo-users@lists.pharo.org>
>
> Perhaps not, or not yet. Perhaps it is the communications foundation for
> an always-on cloud/bigData control layer.
>
> I would position ParrotTalk as a Kerberos transport. ParrotTalk does
> 2048-bin key negotiation and subsequent encryption/encoding, both
> user-supplied.
>
> Please see the attached diagram, co-locating ParrotTalk with my other
> components.
>
> ParrotTalk does not do user authentication/authorization. Which means to
> me that I should consider Kerberos authorization/authentication to
> establish as an integratable transport to play in bigData.
>
> This means you still need a Kerberos client and I need a Kerberos client.
> How do we start?
>
> - HH
>
> PS: I did much work integrating Kafka into a framework. I was thinking of
> inserting msg sending replication to a partition count of replicate queues
> for sending and receiving Hubbub traffic, thus inserting right where
> Kerberos is in the diagram. I would love to see client coupling for
> Kerberos, Kafka and Hadoop, while I figure out proper security to make that
> group happy with this as a possible control layer solution, forking off
> jobs.
>
>
> On Thu, Oct 26, 2017 at 03:14, p...@highoctane.be <p...@highoctane.be>
> wrote:
>
> Sure. Current main issue is to have Pharo work with Kerberos as secured
> Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole
> of crypto things.
>
> How would you see ParrotTalk work?
>
> I made a XmppTalk thing (binding for libstrophe) for having Pharo images
> and other stuff talk together (currently using OpenFire/Gajim/Profanity)
> FWIW
>
> See https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tm
> uxyZz1UaX5ikEU/edit?usp=sharing
>
> libstrophe does the SSL thing under the hood (using OpenSSL) and is
> actively maintained.
> https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c
>
> And I currently work with Kafka so, Pharo as a consumer or producer, sure
> am interested. But need Kerberos support.
>
> Tell me more about your vision. Even better, draw it in some way :-)
>
> Phil
>
>
> On Thu, Oct 26, 2017 at 8:43 AM, henry <he...@callistohouse.club> wrote:
>
> This is a goal of ParrotTalk, to bring bit-compatible communications to
> Squeak, Pharo and Java. This is not an invocation bridge you speak of but a
> communications bridge to be able to run against Hadoop or whichever big
> data needs integration with (Kafka). I had hoped it might be adopted for
> such. Yet again this is not exactly what you were looking for but yet
> interesting perhaps?
>
>
> - HH
>
>
> On Thu, Oct 26, 2017 at 02:17, p...@highoctane.be < p...@highoctane.be&g

Re: [Pharo-users] Smalltalk Argument

[henry]

I have no idea which is best. For being able to say we use industry standard 
Kerberos, calling an accepted implementation seems wise, like OpenSSL support.

- HH

On Thu, Oct 26, 2017 at 11:39, Paulo R. Dellani <dell...@pobox.com> wrote:

> This all sounds very interesting. What is the idea? Wrap libkrb5 through UFFI 
> or implement it in Smalltalk?
>
> On 10/26/2017 04:38 PM, henry wrote:
>
>> A Kerberos effort will have to be a group effort. Sideways to my main focus 
>> and your all’s main focii.
>>
>> - HH
>>
>> On Thu, Oct 26, 2017 at 09:15, henry 
>> <[he...@callistohouse.club](%22mailto:he...@callistohouse.club%22)> wrote:
>>
>>> I think another good service to integrate well to is Elastic Search.
>>>
>>> Of the 4 types of integration, I vote for and step forward to volunteer to 
>>> help Kerberos integration in Pharo. What to do?
>>>
>>> - HH
>>>
>>> On Thu, Oct 26, 2017 at 09:06, henry 
>>> <[he...@callistohouse.club](%22%22mailto:he...@callistohouse.club%22%22)> 
>>> wrote:
>>>
>>>> I try posting with a smaller image.
>>>>
>>>> [""hubbub.jpg""]
>>>>
>>>> - HH
>>>>
>>>>> ——— Original Message ———
>>>>> Subject: Re: [Pharo-users] Smalltalk Argument
>>>>> Local Time: October 26, 2017 8:52 AM
>>>>> UTC Time: October 26, 2017 12:52 PM
>>>>> From: he...@callistohouse.club
>>>>> To: p...@highoctane.be [<p...@highoctane.be>](mailto:p...@highoctane.be), 
>>>>> Any question about pharo is welcome 
>>>>> [<pharo-users@lists.pharo.org>](mailto:pharo-users@lists.pharo.org)
>>>>>
>>>>> Perhaps not, or not yet. Perhaps it is the communications foundation for 
>>>>> an always-on cloud/bigData control layer.
>>>>>
>>>>> I would position ParrotTalk as a Kerberos transport. ParrotTalk does 
>>>>> 2048-bin key negotiation and subsequent encryption/encoding, both 
>>>>> user-supplied.
>>>>>
>>>>> Please see the attached diagram, co-locating ParrotTalk with my other 
>>>>> components.
>>>>>
>>>>> ParrotTalk does not do user authentication/authorization. Which means to 
>>>>> me that I should consider Kerberos authorization/authentication to 
>>>>> establish as an integratable transport to play in bigData.
>>>>>
>>>>> This means you still need a Kerberos client and I need a Kerberos client. 
>>>>> How do we start?
>>>>>
>>>>> - HH
>>>>>
>>>>> PS: I did much work integrating Kafka into a framework. I was thinking of 
>>>>> inserting msg sending replication to a partition count of replicate 
>>>>> queues for sending and receiving Hubbub traffic, thus inserting right 
>>>>> where Kerberos is in the diagram. I would love to see client coupling for 
>>>>> Kerberos, Kafka and Hadoop, while I figure out proper security to make 
>>>>> that group happy with this as a possible control layer solution, forking 
>>>>> off jobs.
>>>>>
>>>>> On Thu, Oct 26, 2017 at 03:14, p...@highoctane.be 
>>>>> <[p...@highoctane.be](%22%22%22mailto:p...@highoctane.be%22%22%22)> wrote:
>>>>>
>>>>>> Sure. Current main issue is to have Pharo work with Kerberos as secured 
>>>>>> Hadoop uses the UGI (UserGroupInformation) thing and that is a black 
>>>>>> hole of crypto things.
>>>>>>
>>>>>> How would you see ParrotTalk work?
>>>>>>
>>>>>> I made a XmppTalk thing (binding for libstrophe) for having Pharo images 
>>>>>> and other stuff talk together (currently using OpenFire/Gajim/Profanity) 
>>>>>> FWIW
>>>>>>
>>>>>> See 
>>>>>> [https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1UaX5ikEU/edit?usp=sharing](%22%22%22https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1UaX5ikEU/edit?usp=sharing%22%22%22)
>>>>>>
>>>>>> libstrophe does the SSL thing under the hood (using OpenSSL) and is 
>>>>>> actively maintained.
>>>>>> [https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c](%22%22%22https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c%

Re: [Pharo-users] Smalltalk Argument

[Paulo R. Dellani]

This all sounds very interesting. What is the idea? Wrap libkrb5 through
UFFI or implement it in Smalltalk?

On 10/26/2017 04:38 PM, henry wrote:
> A Kerberos effort will have to be a group effort. Sideways to my main
> focus and your all’s main focii.
>
>
> - HH
>
>
> On Thu, Oct 26, 2017 at 09:15, henry <he...@callistohouse.club
> <%22mailto:he...@callistohouse.club%22>> wrote:
>
> I think another good service to integrate well to is Elastic Search.
>
> Of the 4 types of integration, I vote for and step forward to
> volunteer to help Kerberos integration in Pharo. What to do?
>
>
> - HH
>
>
> On Thu, Oct 26, 2017 at 09:06, henry <he...@callistohouse.club
> <%22%22mailto:he...@callistohouse.club%22%22>> wrote:
>
> I try posting with a smaller image.
>
> ""hubbub.jpg""
>
> - HH
>
>
> ——— Original Message ———
> Subject: Re: [Pharo-users] Smalltalk Argument
> Local Time: October 26, 2017 8:52 AM
> UTC Time: October 26, 2017 12:52 PM
> From: he...@callistohouse.club
> To: p...@highoctane.be <p...@highoctane.be>, Any question
> about pharo is welcome <pharo-users@lists.pharo.org>
>
> Perhaps not, or not yet. Perhaps it is the communications
> foundation for an always-on cloud/bigData control layer.
>
> I would position ParrotTalk as a Kerberos transport.
> ParrotTalk does 2048-bin key negotiation and subsequent
> encryption/encoding, both user-supplied. 
>
> Please see the attached diagram, co-locating ParrotTalk
> with my other components.
>
> ParrotTalk does not do user authentication/authorization.
> Which means to me that I should consider Kerberos
> authorization/authentication to establish as an
> integratable transport to play in bigData.
>
> This means you still need a Kerberos client and I need a
> Kerberos client. How do we start?
>
> - HH
>
> PS: I did much work integrating Kafka into a framework. I
> was thinking of inserting msg sending replication to a
> partition count of replicate queues for sending and
> receiving Hubbub traffic, thus inserting right where
> Kerberos is in the diagram. I would love to see client
> coupling for Kerberos, Kafka and Hadoop, while I figure
> out proper security to make that group happy with this as
> a possible control layer solution, forking off jobs.
>
>
> On Thu, Oct 26, 2017 at 03:14, p...@highoctane.be
> <p...@highoctane.be
> <%22%22%22mailto:p...@highoctane.be%22%22%22>> wrote:
>
> Sure. Current main issue is to have Pharo work with
> Kerberos as secured Hadoop uses the UGI
> (UserGroupInformation) thing and that is a black hole
> of crypto things. 
>
> How would you see ParrotTalk work? 
>
> I made a XmppTalk thing (binding for libstrophe) for
> having Pharo images and other stuff talk together
> (currently using OpenFire/Gajim/Profanity) FWIW
>
> See
> 
> https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1UaX5ikEU/edit?usp=sharing
> 
> <%22%22%22https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1UaX5ikEU/edit?usp=sharing%22%22%22>
>
>
> libstrophe does the SSL thing under the hood (using
> OpenSSL) and is actively maintained.
> 
> https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c
> 
> <%22%22%22https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c%22%22%22>
>
>
> And I currently work with Kafka so, Pharo as a
> consumer or producer, sure am interested. But need
> Kerberos support.
>
> Tell me more about your vision. Even better, draw it
> in some way :-)
>
> Phil
>
>
> On Thu, Oct 26, 2017 at 8:43 AM, henry
> <he...@callistohouse.club
> <%22%22%22mailto:he...@callistohouse.club%22%22%22>>
> wrote:
>
> This is a goal of ParrotTalk, to bring
> bit-compatible communications to 

Re: [Pharo-users] Smalltalk Argument

[Dimitris Chloupis]

ned perspective on its relevance is that while
> Java based software runs TV set top boxes, Smalltalk based software runs
> things like medical equipment, automated defense systems, tanks, etc.  Cost
> becomes largely irrelevant when ‘shit has to work’.
>
>
>
> Productivity is primarily relevant to less talented developers, in an
> inversely sense, since unproductive environments and attitudes have a
> leveling tendency in general, and more specifically make accomplishing what
> the less talented are capable of in any environment sufficiently laborious
> for them to have a role.  Capability in Smalltalk, as implied by the person
> hiring for the Java role I mentioned, is a fairly decent means of judging
> whether someone is a so-so developer or a good one.
>
>
>
> The productivity argument is realistically only relevant in the context of
> an already higher hourly cost.  Given that it is relevant at that point,
> companies that know Smalltalk is more productive would use it outside
> things that have to be 100%, *if* their own productivity were relevant to
> the same degree that competitors’ productivity is inversely relevant.
>
>
>
> All these ways of looking at it are contingent perspectives though.  Yes,
> if the number of libraries is relevant to you, Smalltalk is less
> attractive, but that’s only a contingent phenomenon based on the relative
> popularity of Java and JavaScript, as a result it can’t be used as
> explanatory *for* that popularity.  All the ways of looking at it that
> are fully determinate are determinate via contingencies of that kind, which
> for the most part *are* precisely the other perspectives, including
> productivity, cost, availability of developers, etc.  None of them is *in
> itself* anything but a result of the others.
>
>
>
> If availability of developers is contingent on popularity (and further,
> popularity contingent on industry attitudes), to use an example already
> mentioned in Joachim’s post, then his simultaneous posit of library
> availability is if anything more contingent on the same popularity, so
> positing it as a cause and not a result, or merely a correlate, of
> popularity is incoherent.  We can go one step further, and demonstrate that
> even when large enterprises make something that works reliably available,
> they fail to promote and support it, which destroys the market for reliable
> tooling by simultaneously owning it while not promoting it, something IBM
> is particularly good at.  But IBM can’t (and if they can’t, neither can any
> other company) operate that way without the tacit agreement of the
> industry.
>
>
>
> To understand it in a more general way, software development has to be
> looked at in the context where it occurs, and how it’s determined to a
> large degree by that context, with a specific difference.  That difference
> is itself implicit in the context, i.e. capitalism, but only *purely 
> *effective
> in software development. It’s a result of virtualization as an implicit
> goal of capitalism, and the disruptions implicit in the virtual but so far
> only realized completely in software.  In terms of that understanding, the
> analysis of virtualization and disruption as inherent to capitalism is
> better accomplished in Kapital than in any more recent work.
>
>
>
> Or you can simply decide, as I’ve done recently, that working in ways and
> with tools that prevent doing good work in a reasonable timeframe isn’t
> worthwhile *to you,* no matter how popular those ways and tools might be,
> or what the posited reasons are, since at the end popularity is only
> insofar as it *already* is.  What those tools and methods are depends to
> a degree on your priorities, but if developers are *engineers* those
> priorities can’t be completely arbitrary.  Engineers are defined by their
> ability to make things work.
>
>
>
> Software as virtual is inherently disruptive, and the software industry
> disrupts itself too often and too easily to build on anything. A further
> disruption caused by developers, *as* engineers, refusing to work with
> crap that *doesn’t*, i.e. insisting on being engineers, while in itself
> merely an aggravation of the disruptive tendencies, might have an inverse
> result.
>
>
>
> Using a stable core of technologies as the basis for a more volatile set
> of products, in the way nearly every other industry does, is the best means
> we know of to build things both flexibly and reasonably efficiently.  The
> computer hardware industry is the extreme example of this, while the
> software industry is the extreme contradiction.
>
>
>
> *From: *Pharo-users <pharo-users-boun...@lists.pharo.org>
> <pharo-users-boun...@lists.pharo.org> on beha

Re: [Pharo-users] Smalltalk Argument

[Paulo R. Dellani]

> isn’t worthwhile /to you,/ no matter how popular those ways and tools
> might be, or what the posited reasons are, since at the end popularity
> is only insofar as it /already/ is.  What those tools and methods are
> depends to a degree on your priorities, but if developers are
> /engineers/ those priorities can’t be completely arbitrary.  Engineers
> are defined by their ability to make things work.
>
>  
>
> Software as virtual is inherently disruptive, and the software
> industry disrupts itself too often and too easily to build on
> anything. A further disruption caused by developers, /as/ engineers,
> refusing to work with crap that /doesn’t/, i.e. insisting on being
> engineers, while in itself merely an aggravation of the disruptive
> tendencies, might have an inverse result.
>
>  
>
> Using a stable core of technologies as the basis for a more volatile
> set of products, in the way nearly every other industry does, is the
> best means we know of to build things both flexibly and reasonably
> efficiently.  The computer hardware industry is the extreme example of
> this, while the software industry is the extreme contradiction.
>
>  
>
> *From: *Pharo-users <pharo-users-boun...@lists.pharo.org> on behalf of
> David Mason <dma...@ryerson.ca>
> *Reply-To: *Any question about pharo is welcome
> <pharo-users@lists.pharo.org>
> *Date: *Tuesday, October 24, 2017 at 11:52 AM
> *To: *Any question about pharo is welcome <pharo-users@lists.pharo.org>
> *Subject: *Re: [Pharo-users] Smalltalk Argument
>
>  
>
> PharoJS is working to give you that mobile app/browser app
> experience.  As with others, we're not there yet, but getting there. 
> See http://pharojs.org
>
>  
>
> The 67% loved means that 67% of people using Smalltalk (or perhaps
> have ever used it) want to continue - so it's presumably a high
> percentage of a smallish number of people.
>
>  
>
> On 20 October 2017 at 03:23, jtuc...@objektfabrik.de
> <mailto:jtuc...@objektfabrik.de> <jtuc...@objektfabrik.de
> <mailto:jtuc...@objektfabrik.de>> wrote:
>
> First of all: I'd say the question itself is not a question but an
> excuse. I am not arguing there are enough Smalltalkers or cheap
> ones. But I think the question is just a way of saying "we don't
> want to do it for reasons that we ourselves cannot really
> express". If you are a good developer, learning Smalltalk is easy.
> If you are a good developer you've heard the sentence "we've taken
> the goos parts from x,y,z and Smalltalk" at least twice a year. So
> you most likely would like to learn it anyways.
>
> A shortage of developers doesn't exist. What exists is an
> unwillingness of companies to get people trained in a technology.
> If Smalltalk was cool and great in their opinion, they wouldn't
> care. It's that simple. As a consultant, I've heard that argument
> so often. Not ferom Startups, but from insurance companies, Banks
> or Car manufacturers who spend millions on useless, endless
> meetings and stuff instead of just hiring somebody to teach a
> couple of developers Smalltalk. It's just a lie: the shortage of
> Smalltalk developers is not a problem.
>
> And, to be honest: what is it we actually are better in by using
> Smalltalk?
> Can we build cool looking web apps in extremely short time? No.
> Can we build mobile Apps with little effort? No.
> Does our Smalltalk ship lots of great libraries for all kinds of
> things that are not availabel in similar quality in any other
> language?
> Are we lying when we say we are so extremely over-productive as
> compared to other languages?
>
> I know, all that live debugging stuff and such is great and it is
> much faster to find & fix a bug in Smalltalk than in any other
> environment I've used so far. But that is really only true for
> business code. When I need to connect to things or want to build a
> modern GUI or a web application with a great look, I am
> nowhere near productive, because I simply have to build my own
> stuff or learn how to use other external resources. If I want to
> build something for a mobile device, I will only hear that
> somebody somewhere has done it before. No docs, no proof, no
> ready-made tool for me.
>
>
> Shortage of developers is not really the problem. If Smalltalk was
> as cool as we like to make ourselves believe, this problem would
> be non-existent. If somebody took out their iPad and told an
> audience: "We did this in Smalltalk in 40% of the time it would
> have taken in Swift", 

Re: [Pharo-users] Smalltalk Argument

[p...@highoctane.be]

ttitudes), to use an example already
> mentioned in Joachim’s post, then his simultaneous posit of library
> availability is if anything more contingent on the same popularity, so
> positing it as a cause and not a result, or merely a correlate, of
> popularity is incoherent.  We can go one step further, and demonstrate that
> even when large enterprises make something that works reliably available,
> they fail to promote and support it, which destroys the market for reliable
> tooling by simultaneously owning it while not promoting it, something IBM
> is particularly good at.  But IBM can’t (and if they can’t, neither can any
> other company) operate that way without the tacit agreement of the
> industry.
>
>
>
> To understand it in a more general way, software development has to be
> looked at in the context where it occurs, and how it’s determined to a
> large degree by that context, with a specific difference.  That difference
> is itself implicit in the context, i.e. capitalism, but only *purely 
> *effective
> in software development. It’s a result of virtualization as an implicit
> goal of capitalism, and the disruptions implicit in the virtual but so far
> only realized completely in software.  In terms of that understanding, the
> analysis of virtualization and disruption as inherent to capitalism is
> better accomplished in Kapital than in any more recent work.
>
>
>
> Or you can simply decide, as I’ve done recently, that working in ways and
> with tools that prevent doing good work in a reasonable timeframe isn’t
> worthwhile *to you,* no matter how popular those ways and tools might be,
> or what the posited reasons are, since at the end popularity is only
> insofar as it *already* is.  What those tools and methods are depends to
> a degree on your priorities, but if developers are *engineers* those
> priorities can’t be completely arbitrary.  Engineers are defined by their
> ability to make things work.
>
>
>
> Software as virtual is inherently disruptive, and the software industry
> disrupts itself too often and too easily to build on anything. A further
> disruption caused by developers, *as* engineers, refusing to work with
> crap that *doesn’t*, i.e. insisting on being engineers, while in itself
> merely an aggravation of the disruptive tendencies, might have an inverse
> result.
>
>
>
> Using a stable core of technologies as the basis for a more volatile set
> of products, in the way nearly every other industry does, is the best means
> we know of to build things both flexibly and reasonably efficiently.  The
> computer hardware industry is the extreme example of this, while the
> software industry is the extreme contradiction.
>
>
>
> *From: *Pharo-users <pharo-users-boun...@lists.pharo.org> on behalf of
> David Mason <dma...@ryerson.ca>
> *Reply-To: *Any question about pharo is welcome <
> pharo-users@lists.pharo.org>
> *Date: *Tuesday, October 24, 2017 at 11:52 AM
> *To: *Any question about pharo is welcome <pharo-users@lists.pharo.org>
> *Subject: *Re: [Pharo-users] Smalltalk Argument
>
>
>
> PharoJS is working to give you that mobile app/browser app experience.  As
> with others, we're not there yet, but getting there.  See
> http://pharojs.org
>
>
>
> The 67% loved means that 67% of people using Smalltalk (or perhaps have
> ever used it) want to continue - so it's presumably a high percentage of a
> smallish number of people.
>
>
>
> On 20 October 2017 at 03:23, jtuc...@objektfabrik.de <
> jtuc...@objektfabrik.de> wrote:
>
> First of all: I'd say the question itself is not a question but an excuse.
> I am not arguing there are enough Smalltalkers or cheap ones. But I think
> the question is just a way of saying "we don't want to do it for reasons
> that we ourselves cannot really express". If you are a good developer,
> learning Smalltalk is easy. If you are a good developer you've heard the
> sentence "we've taken the goos parts from x,y,z and Smalltalk" at least
> twice a year. So you most likely would like to learn it anyways.
>
> A shortage of developers doesn't exist. What exists is an unwillingness of
> companies to get people trained in a technology. If Smalltalk was cool and
> great in their opinion, they wouldn't care. It's that simple. As a
> consultant, I've heard that argument so often. Not ferom Startups, but from
> insurance companies, Banks or Car manufacturers who spend millions on
> useless, endless meetings and stuff instead of just hiring somebody to
> teach a couple of developers Smalltalk. It's just a lie: the shortage of
> Smalltalk developers is not a problem.
>
> And, to be honest: what is it we actually are better in by using
&

Re: [Pharo-users] Smalltalk Argument

[henry]

t is relevant, but not in the simple way people look at things.  A crucial 
> but rarely mentioned perspective on its relevance is that while Java based 
> software runs TV set top boxes, Smalltalk based software runs things like 
> medical equipment, automated defense systems, tanks, etc.  Cost becomes 
> largely irrelevant when ‘shit has to work’.
>
> Productivity is primarily relevant to less talented developers, in an 
> inversely sense, since unproductive environments and attitudes have a 
> leveling tendency in general, and more specifically make accomplishing what 
> the less talented are capable of in any environment sufficiently laborious 
> for them to have a role.  Capability in Smalltalk, as implied by the person 
> hiring for the Java role I mentioned, is a fairly decent means of judging 
> whether someone is a so-so developer or a good one.
>
> The productivity argument is realistically only relevant in the context of an 
> already higher hourly cost.  Given that it is relevant at that point, 
> companies that know Smalltalk is more productive would use it outside things 
> that have to be 100%, if their own productivity were relevant to the same 
> degree that competitors’ productivity is inversely relevant.
>
> All these ways of looking at it are contingent perspectives though.  Yes, if 
> the number of libraries is relevant to you, Smalltalk is less attractive, but 
> that’s only a contingent phenomenon based on the relative popularity of Java 
> and JavaScript, as a result it can’t be used as explanatory for that 
> popularity.  All the ways of looking at it that are fully determinate are 
> determinate via contingencies of that kind, which for the most part are 
> precisely the other perspectives, including productivity, cost, availability 
> of developers, etc.  None of them is in itself anything but a result of the 
> others.
>
> If availability of developers is contingent on popularity (and further, 
> popularity contingent on industry attitudes), to use an example already 
> mentioned in Joachim’s post, then his simultaneous posit of library 
> availability is if anything more contingent on the same popularity, so 
> positing it as a cause and not a result, or merely a correlate, of popularity 
> is incoherent.  We can go one step further, and demonstrate that even when 
> large enterprises make something that works reliably available, they fail to 
> promote and support it, which destroys the market for reliable tooling by 
> simultaneously owning it while not promoting it, something IBM is 
> particularly good at.  But IBM can’t (and if they can’t, neither can any 
> other company) operate that way without the tacit agreement of the industry.
>
> To understand it in a more general way, software development has to be looked 
> at in the context where it occurs, and how it’s determined to a large degree 
> by that context, with a specific difference.  That difference is itself 
> implicit in the context, i.e. capitalism, but only purely effective in 
> software development. It’s a result of virtualization as an implicit goal of 
> capitalism, and the disruptions implicit in the virtual but so far only 
> realized completely in software.  In terms of that understanding, the 
> analysis of virtualization and disruption as inherent to capitalism is better 
> accomplished in Kapital than in any more recent work.
>
> Or you can simply decide, as I’ve done recently, that working in ways and 
> with tools that prevent doing good work in a reasonable timeframe isn’t 
> worthwhile to you, no matter how popular those ways and tools might be, or 
> what the posited reasons are, since at the end popularity is only insofar as 
> it already is.  What those tools and methods are depends to a degree on your 
> priorities, but if developers are engineers those priorities can’t be 
> completely arbitrary.  Engineers are defined by their ability to make things 
> work.
>
> Software as virtual is inherently disruptive, and the software industry 
> disrupts itself too often and too easily to build on anything. A further 
> disruption caused by developers, as engineers, refusing to work with crap 
> that doesn’t, i.e. insisting on being engineers, while in itself merely an 
> aggravation of the disruptive tendencies, might have an inverse result.
>
> Using a stable core of technologies as the basis for a more volatile set of 
> products, in the way nearly every other industry does, is the best means we 
> know of to build things both flexibly and reasonably efficiently.  The 
> computer hardware industry is the extreme example of this, while the software 
> industry is the extreme contradiction.
>
> From: Pharo-users <pharo-users-boun...@lists.pharo.org> on behalf of David 
>

Re: [Pharo-users] Smalltalk Argument

[Andrew Glynn]

, is a fairly decent means of judging whether someone is a so-so 
developer or a good one.

 

The productivity argument is realistically only relevant in the context of an 
already higher hourly cost.  Given that it is relevant at that point, companies 
that know Smalltalk is more productive would use it outside things that have to 
be 100%, if their own productivity were relevant to the same degree that 
competitors’ productivity is inversely relevant.

 

All these ways of looking at it are contingent perspectives though.  Yes, if 
the number of libraries is relevant to you, Smalltalk is less attractive, but 
that’s only a contingent phenomenon based on the relative popularity of Java 
and JavaScript, as a result it can’t be used as explanatory for that 
popularity.  All the ways of looking at it that are fully determinate are 
determinate via contingencies of that kind, which for the most part are 
precisely the other perspectives, including productivity, cost, availability of 
developers, etc.  None of them is in itself anything but a result of the 
others.  

 

If availability of developers is contingent on popularity (and further, 
popularity contingent on industry attitudes), to use an example already 
mentioned in Joachim’s post, then his simultaneous posit of library 
availability is if anything more contingent on the same popularity, so positing 
it as a cause and not a result, or merely a correlate, of popularity is 
incoherent.  We can go one step further, and demonstrate that even when large 
enterprises make something that works reliably available, they fail to promote 
and support it, which destroys the market for reliable tooling by 
simultaneously owning it while not promoting it, something IBM is particularly 
good at.  But IBM can’t (and if they can’t, neither can any other company) 
operate that way without the tacit agreement of the industry.  

 

To understand it in a more general way, software development has to be looked 
at in the context where it occurs, and how it’s determined to a large degree by 
that context, with a specific difference.  That difference is itself implicit 
in the context, i.e. capitalism, but only purely effective in software 
development. It’s a result of virtualization as an implicit goal of capitalism, 
and the disruptions implicit in the virtual but so far only realized completely 
in software.  In terms of that understanding, the analysis of virtualization 
and disruption as inherent to capitalism is better accomplished in Kapital than 
in any more recent work.

 

Or you can simply decide, as I’ve done recently, that working in ways and with 
tools that prevent doing good work in a reasonable timeframe isn’t worthwhile 
to you, no matter how popular those ways and tools might be, or what the 
posited reasons are, since at the end popularity is only insofar as it already 
is.  What those tools and methods are depends to a degree on your priorities, 
but if developers are engineers those priorities can’t be completely arbitrary. 
 Engineers are defined by their ability to make things work.

 

Software as virtual is inherently disruptive, and the software industry 
disrupts itself too often and too easily to build on anything. A further 
disruption caused by developers, as engineers, refusing to work with crap that 
doesn’t, i.e. insisting on being engineers, while in itself merely an 
aggravation of the disruptive tendencies, might have an inverse result.

 

Using a stable core of technologies as the basis for a more volatile set of 
products, in the way nearly every other industry does, is the best means we 
know of to build things both flexibly and reasonably efficiently.  The computer 
hardware industry is the extreme example of this, while the software industry 
is the extreme contradiction.

 

From: Pharo-users <pharo-users-boun...@lists.pharo.org> on behalf of David 
Mason <dma...@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Subject: Re: [Pharo-users] Smalltalk Argument

 

PharoJS is working to give you that mobile app/browser app experience.  As with 
others, we're not there yet, but getting there.  See http://pharojs.org

 

The 67% loved means that 67% of people using Smalltalk (or perhaps have ever 
used it) want to continue - so it's presumably a high percentage of a smallish 
number of people.

 

On 20 October 2017 at 03:23, jtuc...@objektfabrik.de <jtuc...@objektfabrik.de> 
wrote:

First of all: I'd say the question itself is not a question but an excuse. I am 
not arguing there are enough Smalltalkers or cheap ones. But I think the 
question is just a way of saying "we don't want to do it for reasons that we 
ourselves cannot really express". If you are a good developer, learning 
Smalltalk is easy. If you are a good developer you've heard the sentence

Re: [Pharo-users] Smalltalk Argument

[David Mason]

PharoJS is working to give you that mobile app/browser app experience.  As
with others, we're not there yet, but getting there.  See http://pharojs.org

The 67% loved means that 67% of people using Smalltalk (or perhaps have
ever used it) want to continue - so it's presumably a high percentage of a
smallish number of people.

On 20 October 2017 at 03:23, jtuc...@objektfabrik.de <
jtuc...@objektfabrik.de> wrote:

> First of all: I'd say the question itself is not a question but an excuse.
> I am not arguing there are enough Smalltalkers or cheap ones. But I think
> the question is just a way of saying "we don't want to do it for reasons
> that we ourselves cannot really express". If you are a good developer,
> learning Smalltalk is easy. If you are a good developer you've heard the
> sentence "we've taken the goos parts from x,y,z and Smalltalk" at least
> twice a year. So you most likely would like to learn it anyways.
>
> A shortage of developers doesn't exist. What exists is an unwillingness of
> companies to get people trained in a technology. If Smalltalk was cool and
> great in their opinion, they wouldn't care. It's that simple. As a
> consultant, I've heard that argument so often. Not ferom Startups, but from
> insurance companies, Banks or Car manufacturers who spend millions on
> useless, endless meetings and stuff instead of just hiring somebody to
> teach a couple of developers Smalltalk. It's just a lie: the shortage of
> Smalltalk developers is not a problem.
>
> And, to be honest: what is it we actually are better in by using Smalltalk?
> Can we build cool looking web apps in extremely short time? No.
> Can we build mobile Apps with little effort? No.
> Does our Smalltalk ship lots of great libraries for all kinds of things
> that are not availabel in similar quality in any other language?
> Are we lying when we say we are so extremely over-productive as compared
> to other languages?
>
> I know, all that live debugging stuff and such is great and it is much
> faster to find & fix a bug in Smalltalk than in any other environment I've
> used so far. But that is really only true for business code. When I need to
> connect to things or want to build a modern GUI or a web application with a
> great look, I am nowhere near productive, because I simply have to
> build my own stuff or learn how to use other external resources. If I want
> to build something for a mobile device, I will only hear that somebody
> somewhere has done it before. No docs, no proof, no ready-made tool for me.
>
>
> Shortage of developers is not really the problem. If Smalltalk was as cool
> as we like to make ourselves believe, this problem would be non-existent.
> If somebody took out their iPad and told an audience: "We did this in
> Smalltalk in 40% of the time it would have taken in Swift", and if that
> something was a must-have for people, things would be much easier. But
> nobody has.
>
>
> I am absolutely over-exaggerating, because I make my living with an SaaS
> product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk
> and - as you - am convince that many parts of what we've done so far
> would've taken much longer or even be impossible in other languages. But
> the advantage was eaten by our extremely steep learning curve for web
> technologies and for building something that works almost as well as tools
> like Angular or jQuery Mobile.
>
> Smalltalk is cool, and the day somebody shows me something like Google's
> flutter in Smalltalk, I am ready to bet a lot on a bright future for
> Smalltalk. But until then, I'd say these arguments about productivity are
> just us trying to make ourselves believe we're still the top of the food
> chain. We've done that for almost thirty years now and still aren't ready
> to stop it. But we've been lying to ourselves and still do so.
>
> I don't think there is a point in discussing about the usefulness of a
> language using an argument like the number or ready-made developers. That
> is just an argument they know you can't win. The real question is and
> should be: what is the benefit of using Smalltalk. Our productivity
> argument is a lie as soon as we have to build something that uses or runs
> on technology that has been invented after 1990.
>
>
> Okay, shoot ;-)
>
> Joachim
>
>
> --
> ---
> Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
> 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
>
>
>

Re: [Pharo-users] Smalltalk Argument

[horrido]

Of all the responses here, I like this one the best because it's right on the
money.

In my long career, I've been dropped into many software projects where I had
to quickly ramp up with a new programming language. The employer didn't hire
me for my language expertise; they hired me for my programming skill and
ability to deliver good quality software on time. The programming tool used
was a mere technicality, and hardly an obstacle.

There is not a software developer alive who can coast through their entire
career without ever needing to pick up another programming language. This is
simply not an issue except for the most myopic of employers.



Pharo Smalltalk Users mailing list wrote
> Hi Paulo,
> 
> I think this is not the right question to ask.
> The problem is not "Where to find Smalltalk developers?", the problem is 
> rather
> "How much effort does it take to help a good experienced OO developer to 
> transition to Smalltalk?"
> 
> OO developers have to steadily gain and learn new technologies and 
> frameworks...
> So why not Smalltalk?
> Those developers that are not willing to learn a new language just 
> because they consider the trade-offs of not finding a job in that field 
> that easily, might not be the best choice for your team anyway...
> 
> That is my experience... I know more developers missing the "Smalltalk 
> experience" than those hating Smalltalk once they left a team...
> 
> Sebastian
> 
> 
> On 2017-10-19 12:04 AM, Paulo R. Dellani wrote:
>> Dear all,
>>
>> after using Smalltalk for several years I developed a passion for the
>> language (how not to?), and Pharo is just so great to develop with.
>> So thank you guys for keeping this wonderful project running.
>>
>> Unfortunately, it is not easy to always point out why Smalltalk
>> should be employed as "main development language" in a team
>> or for a project. In the last discussion of this sort I was confronted
>> with the question "where are we going to get new smalltalk
>> developers if our startup grows or if you go?". Well, I had no
>> good answer to that. What would have you answered?
>>
>> Cheers,
>>
>> Paulo
>>
>>
>>





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

Re: [Pharo-users] Smalltalk Argument

[horrido]

To quote from  The Wisdom of the Crowd
  :

The crowd is indeed wise. This wisdom shows up in the  latest StackOverflow
survey

 
, as well. Under “Most Loved Languages,” Smalltalk shows up in clear second
place (after Rust and before TypeScript, Swift, Go, Python, Elixir, and C#).
This shows that people who’ve used Smalltalk love the language and are loyal
to it.

It also shows, by inference, that the programming community is not aware of
how good Smalltalk is. Most in the community wallow in ignorance over it.
/If they were to try Smalltalk programming, the language would very likely
become popular./



itli...@schrievkrom.de wrote
> I do not want to spoil the party (perhaps I've done this already) - but
> has anyone done a serious inspection of this number: 67%.
> 
> They have interviewed 64000 persons and 67% of the people should "love"
> Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the
> user already using Smalltalk "love" that.
> 
> By the way - the most loved platform is Linux (69%) ...
> 
> 
> Marten
> 
> Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani:
> 
>> 
>> The second most loved language by 67% of developers surveyed cannot
>> simply
>> be ruled out because of unfounded concerns. (Thanks again for the
> 
> 
> -- 
> Marten Feldtmann





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

Re: [Pharo-users] Smalltalk Argument

[Peter Fisk]

Thank you Joachim!

That is the most honest assessment of the situation of Smalltalk in 2017
that I have ever seen.

And I agree with you 100%.

We need a new Smalltalk which is both "cool" and can seamlessly integrate
with all of the latest web technologies.

I will be releasing a new Smalltalk framework very shortly called
"Smalltalk Express".

The interpreter is written in the "Go" language and can run on all of the
major web platforms such as Google, Heroku, etc.

I use Pharo to manage the Smalltalk code.

Here is a new blog that I have started to discuss the project.

https://smalltalkexpress.quora.com/

Also, I have reserved the web address "smalltalk.express" for use once the
code goes live.

There is a video in the blog post so you can get an idea of where things
stand right now.

-- Peter





On Fri, Oct 20, 2017 at 3:23 AM, jtuc...@objektfabrik.de <
jtuc...@objektfabrik.de> wrote:

> First of all: I'd say the question itself is not a question but an excuse.
> I am not arguing there are enough Smalltalkers or cheap ones. But I think
> the question is just a way of saying "we don't want to do it for reasons
> that we ourselves cannot really express". If you are a good developer,
> learning Smalltalk is easy. If you are a good developer you've heard the
> sentence "we've taken the goos parts from x,y,z and Smalltalk" at least
> twice a year. So you most likely would like to learn it anyways.
>
> A shortage of developers doesn't exist. What exists is an unwillingness of
> companies to get people trained in a technology. If Smalltalk was cool and
> great in their opinion, they wouldn't care. It's that simple. As a
> consultant, I've heard that argument so often. Not ferom Startups, but from
> insurance companies, Banks or Car manufacturers who spend millions on
> useless, endless meetings and stuff instead of just hiring somebody to
> teach a couple of developers Smalltalk. It's just a lie: the shortage of
> Smalltalk developers is not a problem.
>
> And, to be honest: what is it we actually are better in by using Smalltalk?
> Can we build cool looking web apps in extremely short time? No.
> Can we build mobile Apps with little effort? No.
> Does our Smalltalk ship lots of great libraries for all kinds of things
> that are not availabel in similar quality in any other language?
> Are we lying when we say we are so extremely over-productive as compared
> to other languages?
>
> I know, all that live debugging stuff and such is great and it is much
> faster to find & fix a bug in Smalltalk than in any other environment I've
> used so far. But that is really only true for business code. When I need to
> connect to things or want to build a modern GUI or a web application with a
> great look, I am nowhere near productive, because I simply have to
> build my own stuff or learn how to use other external resources. If I want
> to build something for a mobile device, I will only hear that somebody
> somewhere has done it before. No docs, no proof, no ready-made tool for me.
>
>
> Shortage of developers is not really the problem. If Smalltalk was as cool
> as we like to make ourselves believe, this problem would be non-existent.
> If somebody took out their iPad and told an audience: "We did this in
> Smalltalk in 40% of the time it would have taken in Swift", and if that
> something was a must-have for people, things would be much easier. But
> nobody has.
>
>
> I am absolutely over-exaggerating, because I make my living with an SaaS
> product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk
> and - as you - am convince that many parts of what we've done so far
> would've taken much longer or even be impossible in other languages. But
> the advantage was eaten by our extremely steep learning curve for web
> technologies and for building something that works almost as well as tools
> like Angular or jQuery Mobile.
>
> Smalltalk is cool, and the day somebody shows me something like Google's
> flutter in Smalltalk, I am ready to bet a lot on a bright future for
> Smalltalk. But until then, I'd say these arguments about productivity are
> just us trying to make ourselves believe we're still the top of the food
> chain. We've done that for almost thirty years now and still aren't ready
> to stop it. But we've been lying to ourselves and still do so.
>
> I don't think there is a point in discussing about the usefulness of a
> language using an argument like the number or ready-made developers. That
> is just an argument they know you can't win. The real question is and
> should be: what is the benefit of using Smalltalk. Our productivity
> argument is a lie as soon as we have to build something that uses or runs
> on technology that has been invented after 1990.
>
>
> Okay, shoot ;-)
>
> Joachim
>
>
> --
> ---
> Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
> Fliederweg 1 

Re: [Pharo-users] Smalltalk Argument

[Dimitris Chloupis]

Actually you need to read the small letters bellow the graph

"% of developers who are developing with the language or technology and
have expressed interest in continuing to develop with it"

which means basically "Smalltalkers love Smalltalk !!!|" . Actually I am
surpised its only 67% of Smalltalkers that actually love Smalltalk and that
Rust comes first. I was expecting a 90%. But then Rust has been the most
hyped language these past few years.

But does not change the fact that maybe 99% of the coders have not even
heard of Smalltalk and a 60% of Rust.

The bottom line is that the excuses for not using a language can no longer
stand in 2017
(1) But I wont find coders for it
(2) But I wont find libraries for it
(3) But I wont find documentation for it

Let's take (1) , why you even need to find someone that already knows the
language? Do we realise there are people with zero coding experience that
have made built milti million dollar empires . Almost 2 decades ago I
remember reading about q surfer that loved to surf but also made surf
boards. So inside his naiveness said "well let's make an e-shop" and he
made alone one of the first e-shops selling surf boards and he made
millions.

So we have this guy that knows nothing about coding, I think I remember him
saying that he did not even know how to use a computer before, on one side
that in a period of few years has made a multi million dollars software.

On the other side we have experienced coders, that most likely have battled
with code bases of millions of lines of code , university degree, masters
and doctorate and they cannot do what a surfer did ? Seriously

(2) That's my favourite , libraries. We live in 2017 when even my
grandmother's language run on JVM and has JS compiler and we still debate
libraries availability ? Seriously. You can use ANY library from ANY
language and is not even hard. I made Pharo use Python libraries and it
took me a few hundreds lines of code just to make a simple socket bridge.

(3) This one is the most logical, even when I i started coding in Pharo and
to be fair Pharo was still on very early releases there was minimal
documentation and the one I found was outdated. Still no problemo, I am a
coder, I can read code. You will be reading tons and tons of code anyway,
documentation in any language will never take you far.
Why ?
Because the vast majority of users prefer the easy and generic features. A
minority of people dive deep into a library and the ones they do rare
document it.
You are more likely to find specialised information in mailing and forums
than in documentation documents. Of course even there you may get no answer
so you end up testing and learning yourself. Wont mattter even if it is
Java.

Plus there are tons and ton of project made in languages very unpopular
that did great, Ruby On Rails is an example. One library it was all it took
to put Ruby on map.

Even C was introduce through the Unix operating system. New language, out
of nowhere and wait those people using an unknown language wanted to make
one of the best OSes of all time.

So no, even though I rarely get into a language debate because of how
religious people , there is no for not using Pharo but any unpopular
language out there. Because in the end what it will matter the most is the
determination of the coder to output efficient code. If you are passionate
about something nothing can stop you and especially these bad excuses.
Pretty much the most important ingredient for any very successful software
product.

On Fri, Oct 20, 2017 at 11:37 AM Paulo R. Dellani  wrote:

> I also do not believe my eyes:
>
>
> https://insights.stackoverflow.com/survey/2017#most-loved-dreaded-and-wanted
>
>
> On 10/20/2017 10:20 AM, Marten Feldtmann wrote:
> > I do not want to spoil the party (perhaps I've done this already) - but
> > has anyone done a serious inspection of this number: 67%.
> >
> > They have interviewed 64000 persons and 67% of the people should "love"
> > Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the
> > user already using Smalltalk "love" that.
> >
> > By the way - the most loved platform is Linux (69%) ...
> >
> >
> > Marten
> >
> > Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani:
> >
> >> The second most loved language by 67% of developers surveyed cannot
> simply
> >> be ruled out because of unfounded concerns. (Thanks again for the
> >
>
>
>

Re: [Pharo-users] Smalltalk Argument

[stephan]

On 20-10-17 09:23, jtuc...@objektfabrik.de wrote:


And, to be honest: what is it we actually are better in by using Smalltalk?


Making software that stays maintainable. It might be survivor bias, but 
smalltalk systems continue to be maintained by far smaller groups of 
developers than competing technologies.


Stephan

Re: [Pharo-users] Smalltalk Argument

[Paulo R. Dellani]

On 10/20/2017 10:38 AM, Pavel Krivanek wrote:
>
>
> 2017-10-20 10:20 GMT+02:00 Marten Feldtmann  >:
>
> I do not want to spoil the party (perhaps I've done this already)
> - but
> has anyone done a serious inspection of this number: 67%.
>
> They have interviewed 64000 persons and 67% of the people should
> "love"
> Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the
> user already using Smalltalk "love" that.
>
>
> As far as I understand it, the question was different. They asked, if
> you use Smalltalk, would you like to use it the next year too (or
> something like that). Then the number makes more sense.
>

You are right, look at the legend of the graphic:

"% of developers who are developing with the language
or technology and have expressed interest in continuing
to develop with it"

Cheers, Paulo

Re: [Pharo-users] Smalltalk Argument

[Pavel Krivanek]

2017-10-20 10:20 GMT+02:00 Marten Feldtmann :

> I do not want to spoil the party (perhaps I've done this already) - but
> has anyone done a serious inspection of this number: 67%.
>
> They have interviewed 64000 persons and 67% of the people should "love"
> Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the
> user already using Smalltalk "love" that.
>

As far as I understand it, the question was different. They asked, if you
use Smalltalk, would you like to use it the next year too (or something
like that). Then the number makes more sense.

-- Pavel



>
> By the way - the most loved platform is Linux (69%) ...
>
>
> Marten
>
> Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani:
>
> >
> > The second most loved language by 67% of developers surveyed cannot
> simply
> > be ruled out because of unfounded concerns. (Thanks again for the
>
>
> --
> Marten Feldtmann
>
>

Re: [Pharo-users] Smalltalk Argument

[Paulo R. Dellani]

I think you have nailed it, Joachim!

The development environment is per se very productive and easy to use
and learn
but at the moment you need something that isn't present in your code
library,
things can get very hard. Well, that's not really new and not only a
problem
that concerns Smalltalk, but with the greater number of developers in
other languages
chances are that someone already wrote some code concerning your needs.

Well I will go back to my coding here now ;-)

Cheers,

Paulo

On 10/20/2017 09:23 AM, jtuc...@objektfabrik.de wrote:
> First of all: I'd say the question itself is not a question but an
> excuse. I am not arguing there are enough Smalltalkers or cheap ones.
> But I think the question is just a way of saying "we don't want to do
> it for reasons that we ourselves cannot really express". If you are a
> good developer, learning Smalltalk is easy. If you are a good
> developer you've heard the sentence "we've taken the goos parts from
> x,y,z and Smalltalk" at least twice a year. So you most likely would
> like to learn it anyways.
>
> A shortage of developers doesn't exist. What exists is an
> unwillingness of companies to get people trained in a technology. If
> Smalltalk was cool and great in their opinion, they wouldn't care.
> It's that simple. As a consultant, I've heard that argument so often.
> Not ferom Startups, but from insurance companies, Banks or Car
> manufacturers who spend millions on useless, endless meetings and
> stuff instead of just hiring somebody to teach a couple of developers
> Smalltalk. It's just a lie: the shortage of Smalltalk developers is
> not a problem.
>
> And, to be honest: what is it we actually are better in by using
> Smalltalk?
> Can we build cool looking web apps in extremely short time? No.
> Can we build mobile Apps with little effort? No.
> Does our Smalltalk ship lots of great libraries for all kinds of
> things that are not availabel in similar quality in any other language?
> Are we lying when we say we are so extremely over-productive as
> compared to other languages?
>
> I know, all that live debugging stuff and such is great and it is much
> faster to find & fix a bug in Smalltalk than in any other environment
> I've used so far. But that is really only true for business code. When
> I need to connect to things or want to build a modern GUI or a web
> application with a great look, I am nowhere near productive,
> because I simply have to build my own stuff or learn how to use other
> external resources. If I want to build something for a mobile device,
> I will only hear that somebody somewhere has done it before. No docs,
> no proof, no ready-made tool for me.
>
>
> Shortage of developers is not really the problem. If Smalltalk was as
> cool as we like to make ourselves believe, this problem would be
> non-existent. If somebody took out their iPad and told an audience:
> "We did this in Smalltalk in 40% of the time it would have taken in
> Swift", and if that something was a must-have for people, things would
> be much easier. But nobody has.
>
>
> I am absolutely over-exaggerating, because I make my living with an
> SaaS product written in Smalltalk (not Pharo). I have lots of fun with
> Smalltalk and - as you - am convince that many parts of what we've
> done so far would've taken much longer or even be impossible in other
> languages. But the advantage was eaten by our extremely steep learning
> curve for web technologies and for building something that works
> almost as well as tools like Angular or jQuery Mobile.
>
> Smalltalk is cool, and the day somebody shows me something like
> Google's flutter in Smalltalk, I am ready to bet a lot on a bright
> future for Smalltalk. But until then, I'd say these arguments about
> productivity are just us trying to make ourselves believe we're still
> the top of the food chain. We've done that for almost thirty years now
> and still aren't ready to stop it. But we've been lying to ourselves
> and still do so.
>
> I don't think there is a point in discussing about the usefulness of a
> language using an argument like the number or ready-made developers.
> That is just an argument they know you can't win. The real question is
> and should be: what is the benefit of using Smalltalk. Our
> productivity argument is a lie as soon as we have to build something
> that uses or runs on technology that has been invented after 1990.
>
>
> Okay, shoot ;-)
>
> Joachim
>
>

Re: [Pharo-users] Smalltalk Argument

[jtuc...@objektfabrik.de]

First of all: I'd say the question itself is not a question but an 
excuse. I am not arguing there are enough Smalltalkers or cheap ones. 
But I think the question is just a way of saying "we don't want to do it 
for reasons that we ourselves cannot really express". If you are a good 
developer, learning Smalltalk is easy. If you are a good developer 
you've heard the sentence "we've taken the goos parts from x,y,z and 
Smalltalk" at least twice a year. So you most likely would like to learn 
it anyways.


A shortage of developers doesn't exist. What exists is an unwillingness 
of companies to get people trained in a technology. If Smalltalk was 
cool and great in their opinion, they wouldn't care. It's that simple. 
As a consultant, I've heard that argument so often. Not ferom Startups, 
but from insurance companies, Banks or Car manufacturers who spend 
millions on useless, endless meetings and stuff instead of just hiring 
somebody to teach a couple of developers Smalltalk. It's just a lie: the 
shortage of Smalltalk developers is not a problem.


And, to be honest: what is it we actually are better in by using Smalltalk?
Can we build cool looking web apps in extremely short time? No.
Can we build mobile Apps with little effort? No.
Does our Smalltalk ship lots of great libraries for all kinds of things 
that are not availabel in similar quality in any other language?
Are we lying when we say we are so extremely over-productive as compared 
to other languages?


I know, all that live debugging stuff and such is great and it is much 
faster to find & fix a bug in Smalltalk than in any other environment 
I've used so far. But that is really only true for business code. When I 
need to connect to things or want to build a modern GUI or a web 
application with a great look, I am nowhere near productive, 
because I simply have to build my own stuff or learn how to use other 
external resources. If I want to build something for a mobile device, I 
will only hear that somebody somewhere has done it before. No docs, no 
proof, no ready-made tool for me.



Shortage of developers is not really the problem. If Smalltalk was as 
cool as we like to make ourselves believe, this problem would be 
non-existent. If somebody took out their iPad and told an audience: "We 
did this in Smalltalk in 40% of the time it would have taken in Swift", 
and if that something was a must-have for people, things would be much 
easier. But nobody has.



I am absolutely over-exaggerating, because I make my living with an SaaS 
product written in Smalltalk (not Pharo). I have lots of fun with 
Smalltalk and - as you - am convince that many parts of what we've done 
so far would've taken much longer or even be impossible in other 
languages. But the advantage was eaten by our extremely steep learning 
curve for web technologies and for building something that works almost 
as well as tools like Angular or jQuery Mobile.


Smalltalk is cool, and the day somebody shows me something like Google's 
flutter in Smalltalk, I am ready to bet a lot on a bright future for 
Smalltalk. But until then, I'd say these arguments about productivity 
are just us trying to make ourselves believe we're still the top of the 
food chain. We've done that for almost thirty years now and still aren't 
ready to stop it. But we've been lying to ourselves and still do so.


I don't think there is a point in discussing about the usefulness of a 
language using an argument like the number or ready-made developers. 
That is just an argument they know you can't win. The real question is 
and should be: what is the benefit of using Smalltalk. Our productivity 
argument is a lie as soon as we have to build something that uses or 
runs on technology that has been invented after 1990.



Okay, shoot ;-)

Joachim


--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
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

Re: [Pharo-users] Smalltalk Argument

[Paulo R. Dellani]

Dear Ben, Jimmie, Stephane, Tim, Dimitris, Marten, Davorin, Stephan,
Sebastian and James,

thank you for your feedback! Your excellent replies will sure help me with
my "Smalltalk Argument". Obviously the language cannot be employed to
efficiently implement solutions for problems in all domains, but it cannot
simply be ruled out just because it is not so visible as other languages
clamoring for the spotlight, as Jimmie pointed out.

So far I got good results that can talk for themselves thanks to
Pharo/Smalltalk.
So the problem here, I believe, is really Smalltalk not being the "cool
kid in town",
which leads to a misperception of the language by the non-versed. This
can be
certainly be blamed to the lack of a good business oriented OSS
Smalltalk years ago,
as Ben guessed, but certainly there are other factors, which are not the
scope
of this discussion.

The fact that a good OO-software developer can learn and start to get
productive
in Smalltalk in a relatively short amount of time, as pointed out by
several of you,
will make a good argument against the concerns of my colleagues here, which
are mainly non-software developers. And surely the willingness to learn
a new
language is a sign to be looked at in a candidate, as pointed by you too.

The second most loved language by 67% of developers surveyed cannot simply
be ruled out because of unfounded concerns. (Thanks again for the
information,
Jimmie). I think there is really a great potential here, and surely
there is a greater
pool of developer candidates to "draw from" than one can initially
imagine/see.

Cheers,

Paulo

On 10/20/2017 12:17 AM, Ben Coman wrote:
>
>
> On Thu, Oct 19, 2017 at 3:04 PM, Paulo R. Dellani  > wrote:
>
> Dear all,
>
> after using Smalltalk for several years I developed a passion for the
> language (how not to?), and Pharo is just so great to develop with.
> So thank you guys for keeping this wonderful project running.
>
> Unfortunately, it is not easy to always point out why Smalltalk
> should be employed as "main development language" in a team
> or for a project. In the last discussion of this sort I was confronted
> with the question "where are we going to get new smalltalk
> developers if our startup grows or if you go?". Well, I had no
> good answer to that. What would have you answered?
>
> Cheers,
>
> Paulo
>
>
>
> When Smalltalk comes up on reddit, news.ycombinator, etc,
> I often see comments "Used Smalltalk 10 years ago, loved it, but not
> in my day job for years ..."
> The guess the lack of a good business oriented OSS Smalltalk years ago
> may be to blame.
> Only supposition, but with the long history of Smalltalker, the pool
> to draw from may be greater than first apparent.
> The main problem may be that these people are not searching for
> Smalltalk jobs due to the perceived availability of jobs.
>
>
> There would obviously be some lag, but for longer term planning, talk
> to your local education providers about introducing Smalltalk as the
> "best" environment for teaching OO,
> and then take the talented students from there.  Consider contacting
> the academic partners here...
> http://consortium.pharo.org/
>
>
> Another approach depending on the project structure might be to "just"
> prototype in Smalltalk (because its highly productive to explore a
> domain with its built in data persistence)
> and per Fred Brooks plan to throw it away to cleanly implement in a
> mainstream language once you "know" what needs to be done.  
> I remember seeing one case reported here that the prototype worked so
> well that the client didn't bother with the second step.
>
>
> cheers -ben

Re: [Pharo-users] Smalltalk Argument

[Ben Coman]

On Thu, Oct 19, 2017 at 3:04 PM, Paulo R. Dellani  wrote:

> Dear all,
>
> after using Smalltalk for several years I developed a passion for the
> language (how not to?), and Pharo is just so great to develop with.
> So thank you guys for keeping this wonderful project running.
>
> Unfortunately, it is not easy to always point out why Smalltalk
> should be employed as "main development language" in a team
> or for a project. In the last discussion of this sort I was confronted
> with the question "where are we going to get new smalltalk
> developers if our startup grows or if you go?". Well, I had no
> good answer to that. What would have you answered?
>
> Cheers,
>
> Paulo
>
>
>
When Smalltalk comes up on reddit, news.ycombinator, etc,
I often see comments "Used Smalltalk 10 years ago, loved it, but not in my
day job for years ..."
The guess the lack of a good business oriented OSS Smalltalk years ago may
be to blame.
Only supposition, but with the long history of Smalltalker, the pool to
draw from may be greater than first apparent.
The main problem may be that these people are not searching for Smalltalk
jobs due to the perceived availability of jobs.


There would obviously be some lag, but for longer term planning, talk to
your local education providers about introducing Smalltalk as the "best"
environment for teaching OO,
and then take the talented students from there.  Consider contacting the
academic partners here...
http://consortium.pharo.org/


Another approach depending on the project structure might be to "just"
prototype in Smalltalk (because its highly productive to explore a domain
with its built in data persistence)
and per Fred Brooks plan to throw it away to cleanly implement in a
mainstream language once you "know" what needs to be done.
I remember seeing one case reported here that the prototype worked so well
that the client didn't bother with the second step.


cheers -ben

Re: [Pharo-users] Smalltalk Argument

[Jimmie Houchin]

In addition to the excellent replies you have already received I would 
like to offer this from Stack Overflow.


In their 2017 Developer Survey,  Smalltalk was the second most loved 
language at 67% of developers surveyed. This is a regular occurrence.


Now if you look at the rest of the survey you will see that these are 
not people using Smalltalk in their job. Smalltalk doesn't appear 
elsewhere in the survey. It isn't on the radar. However, developers love 
Smalltalk. Should a shop be open minded enough to use Smalltalk, I do 
not think it would be difficult to find people who would love to have 
that opportunity.


A good developer can become proficient at Smalltalk in a reasonable 
amount of time. In addition to the natural virtues of Smalltalk. You 
also have wonderful communities eager and ready to help people join the 
family and become productive. The Pharo and Squeak mailing lists are 
very friendly, with plenty of extremely knowledgeable programmers ready 
to help.


The other nice thing about Smalltalk is that it has history. It is not a 
fad. It is not an immature child. Many Smalltalkers have more years 
experience in Smalltalk than some of the creators of other languages 
have birthdays. There is a vast amount of knowledge and experience in 
this community that doesn't exist in most places. Because of this 
environment, an experienced programmer can receive wisdom and 
understanding and become a better programmer. Do not underestimate the 
value of gray beard Smalltalkers.


A person can read the survey and come away thinking that Smalltalk is 
irrelevant. It is very relevant. It just isn't as visible as other 
languages clamoring for the spotlight. It is mature. It doesn't care to 
be the cool kid.


Yes, OSS Smalltalks have some weaknesses that are actively being worked 
on. We haven't arrived. But we are well on the journey. And to quote our 
favorite prophet Alan Kay, "The best way to predict the future is to 
invent it."


Join us. Help invent the future. Use Pharo to invent the future you want.

There are people out there who want to be a part of this. But they have 
to pay the bills. Help more people pay the bills with Smalltalk. :)



Jimmie



On 10/19/2017 02:04 AM, Paulo R. Dellani wrote:

Dear all,

after using Smalltalk for several years I developed a passion for the
language (how not to?), and Pharo is just so great to develop with.
So thank you guys for keeping this wonderful project running.

Unfortunately, it is not easy to always point out why Smalltalk
should be employed as "main development language" in a team
or for a project. In the last discussion of this sort I was confronted
with the question "where are we going to get new smalltalk
developers if our startup grows or if you go?". Well, I had no
good answer to that. What would have you answered?

Cheers,

Paulo

Re: [Pharo-users] Smalltalk Argument

[Stephane Ducasse]

This is super easy.
- You ask here,
- Second then you try to grab the best open-minded guys you know and
they will use the super cool mooc and learn Pharo in a week or two.
You can tell them that we are not teaching Pharo and still students
good in Java learn it before their internships.
For a good dev it takes really no time to catch up.

Stef

On Thu, Oct 19, 2017 at 9:04 AM, Paulo R. Dellani  wrote:
> Dear all,
>
> after using Smalltalk for several years I developed a passion for the
> language (how not to?), and Pharo is just so great to develop with.
> So thank you guys for keeping this wonderful project running.
>
> Unfortunately, it is not easy to always point out why Smalltalk
> should be employed as "main development language" in a team
> or for a project. In the last discussion of this sort I was confronted
> with the question "where are we going to get new smalltalk
> developers if our startup grows or if you go?". Well, I had no
> good answer to that. What would have you answered?
>
> Cheers,
>
> Paulo
>
>

Re: [Pharo-users] Smalltalk Argument

[Tim Mackinnon]

I'm sure this comes up with many less main stream languages - I think there is 
a strong argument (particularly if we get the GitHub piece operating smoothly) 
that the language is so simple that what you creating is domain understanding 
(not language/tools prowess).

Any good developer (particularly a Ruby, Groovy, JS, Objective C or even 
Python) dev will find Smalltalk a doddle. The complexity is actually in the 
domain.

We also have a vibrant and active community that has been around a long time 
and is willing to help as well as lots of free online training materials.

Put another way - you can use a language like Java but if you left, the 
complexity of build and deployment and understanding the domain is a huge 
hurdle even though it's s popular language.

I've dipped in and out of Smalltalk throughout my career and a few years ago 
came back after 10+ years (so had basically forgotten most of it) and was 
stunned that I was productive in that team after 1 day once they showed me how 
to inspect items in the UI and navigate to tests.

I've never encountered that on a project before.

Tim

Sent from my iPhone

> On 19 Oct 2017, at 08:04, Paulo R. Dellani  wrote:
> 
> Dear all,
> 
> after using Smalltalk for several years I developed a passion for the
> language (how not to?), and Pharo is just so great to develop with.
> So thank you guys for keeping this wonderful project running.
> 
> Unfortunately, it is not easy to always point out why Smalltalk
> should be employed as "main development language" in a team
> or for a project. In the last discussion of this sort I was confronted
> with the question "where are we going to get new smalltalk
> developers if our startup grows or if you go?". Well, I had no
> good answer to that. What would have you answered?
> 
> Cheers,
> 
> Paulo
> 
> 

Re: [Pharo-users] Smalltalk Argument

[Dimitris Chloupis]

I would have followed the Python approach.

When Guido created Python , it did not try to convince his co-workers about
how superior it was compared to other languages. At the time he did not
intend to use it even as programming language. That worked to his
advantage. Instead it used it for small tasks, usually tiny command line
utilities that none would notice. But some did notice and expressed
interest , they tried Python for small tiny tasks again mainly command line
utilities. The co workers came back with suggestions how to improve it and
the rest as they say it’s history.

Any project has cracks that you can squeeze another language , the curious
will the express interest and wonder “what this Pharo is ?”. I think that
probably the best way to promote a language instead of trying to convince
them how great it is. When language is used for such small tasks none will
ask where they will find Smalltalk devs because it’s easy to learn any
language for very simple tasks.  Humans are curious by nature and they love
a nice mystery.

You don’t have to convert an entire project to Pharo, the import thing is
to ignite interest.

Or as the saying goes “actions speak louder than words” ;)

On Thu, 19 Oct 2017 at 10:05, Paulo R. Dellani  wrote:

> Dear all,
>
> after using Smalltalk for several years I developed a passion for the
> language (how not to?), and Pharo is just so great to develop with.
> So thank you guys for keeping this wonderful project running.
>
> Unfortunately, it is not easy to always point out why Smalltalk
> should be employed as "main development language" in a team
> or for a project. In the last discussion of this sort I was confronted
> with the question "where are we going to get new smalltalk
> developers if our startup grows or if you go?". Well, I had no
> good answer to that. What would have you answered?
>
> Cheers,
>
> Paulo
>
>
>

Re: [Pharo-users] Smalltalk Argument

[itli...@schrievkrom.de]

Hello Paulo,

its a problem to get Smalltalkers - simple as it is. I had contacts with
Smalltalkers who wanted to do Smalltalk-"only" jobs - thats impossible
to guarantee in a smaller company and perhaps a mind I would not expect
from Smalltalker.

And the point about "Main Development Language" ... well, the other
developers have also their "beloved" language and it would be a much
better idea to put their "loved" together with your "loved" language.

There are *very* good reason out there to write Windows FAT-Clients in
.NET languages or even Mac/Linux/Windows Clients with Xamarin/Microsoft
tools or even Java-world languages and HTML-Clients with some good
JS-libraries.

You have to have very good reasons (and this is NOT productivity) to
argue against this and tell the other developers, that you develop
superior solutions just because you are doing Smalltalk. This may be
true for very specific libraries (and thats not only Roassal) - not
available in other systems - but in the normal case, they will simply
win (because of the huge amount software written in other languages).

The only Smalltalk technology I found out to be worthwhile fighting for
(because other are not able to offer a similar solution) today is an
object oriented database (e.g. Gemstone/S).

Perhaps the Smalltalk community should concentrate on the idea to make
their technology open/accessable for other languages in an easy way.
This is especially true for database vendors.

Database vendors offering Java, C# and python object support and
Smalltalk as an integrated script language - that could be a very good
argument and a place where Smalltalk can survive.

So, the answer is: don't depend on the language, look for developers
working with more than one language and insert Smalltalk technology
where you *really* get benefit. And the area where Smalltalk is so much
better is getting smaller and smaller these days.


Marten


Am 19.10.2017 um 09:04 schrieb Paulo R. Dellani:
> Dear all,
> 
> after using Smalltalk for several years I developed a passion for the
> language (how not to?), and Pharo is just so great to develop with.
> So thank you guys for keeping this wonderful project running.
> 
> Unfortunately, it is not easy to always point out why Smalltalk
> should be employed as "main development language" in a team
> or for a project. In the last discussion of this sort I was confronted
> with the question "where are we going to get new smalltalk
> developers if our startup grows or if you go?". Well, I had no
> good answer to that. What would have you answered?
> 
> Cheers,
> 
> Paulo
> 
> 


-- 
Marten Feldtmann

Re: [Pharo-users] Smalltalk Argument

[Davorin Rusevljan]

One way to address this issue is to factor in your development grooming of
young Smalltalk developers, which can act as pool of potential full
developers for your project. If you can add some of your domain specific
issues to their grooming, you could increase your project HR safety quite a
lot.

Davorin Rusevljan




On Thu, Oct 19, 2017 at 9:04 AM, Paulo R. Dellani  wrote:

> Dear all,
>
> after using Smalltalk for several years I developed a passion for the
> language (how not to?), and Pharo is just so great to develop with.
> So thank you guys for keeping this wonderful project running.
>
> Unfortunately, it is not easy to always point out why Smalltalk
> should be employed as "main development language" in a team
> or for a project. In the last discussion of this sort I was confronted
> with the question "where are we going to get new smalltalk
> developers if our startup grows or if you go?". Well, I had no
> good answer to that. What would have you answered?
>
> Cheers,
>
> Paulo
>
>
>

Re: [Pharo-users] Smalltalk Argument

[James Ladd]

Nice response 

Sent from my Commodore 64

> On 19 Oct 2017, at 7:02 pm, Sebastian Heidbrink  wrote:
> 
> Hi Paulo,
> 
> I think this is not the right question to ask.
> The problem is not "Where to find Smalltalk developers?", the problem is 
> rather
> "How much effort does it take to help a good experienced OO developer to 
> transition to Smalltalk?"
> 
> OO developers have to steadily gain and learn new technologies and 
> frameworks...
> So why not Smalltalk?
> Those developers that are not willing to learn a new language just because 
> they consider the trade-offs of not finding a job in that field that easily, 
> might not be the best choice for your team anyway...
> 
> That is my experience... I know more developers missing the "Smalltalk 
> experience" than those hating Smalltalk once they left a team...
> 
> Sebastian
> 
> 
>> On 2017-10-19 12:04 AM, Paulo R. Dellani wrote:
>> Dear all,
>> 
>> after using Smalltalk for several years I developed a passion for the
>> language (how not to?), and Pharo is just so great to develop with.
>> So thank you guys for keeping this wonderful project running.
>> 
>> Unfortunately, it is not easy to always point out why Smalltalk
>> should be employed as "main development language" in a team
>> or for a project. In the last discussion of this sort I was confronted
>> with the question "where are we going to get new smalltalk
>> developers if our startup grows or if you go?". Well, I had no
>> good answer to that. What would have you answered?
>> 
>> Cheers,
>> 
>> Paulo
>> 
>> 
>> 
> 
> 

Re: [Pharo-users] Smalltalk Argument

[stephan]

On 19-10-17 09:04, Paulo R. Dellani wrote:

Unfortunately, it is not easy to always point out why Smalltalk
should be employed as "main development language" in a team
or for a project. In the last discussion of this sort I was confronted
with the question "where are we going to get new smalltalk
developers if our startup grows or if you go?". Well, I had no
good answer to that. What would have you answered?


Regularly I go to the Esug Conference and the Pharo Days, and this year 
I had to cancel plans to go to Smalltalks. Those are places where I talk 
to smalltalkers, new and experienced. Every year there are good 
developers there who are looking for work, as intern, as a contractor or 
as an employee. By being there regularly I know who to talk to for 
different kinds of jobs, and for recommendations. Once in a while I also 
visit RMoD and HPI, to talk with people teaching smalltalk. The Pharo 
consortium maintains a list of consultants doing smalltalk work.


For a company dependent on Smalltalk, I'd develop a systematic approach 
to ensuring attractiveness to smalltalk developers. Participation in the 
Pharo Consortium and presenting at conferences about open source 
contributions would be part of that, as might be defining research 
topics or summer jobs for students.


Stephan

Re: [Pharo-users] Smalltalk Argument

[Sebastian Heidbrink via Pharo-users]

--- Begin Message ---

Hi Paulo,

I think this is not the right question to ask.
The problem is not "Where to find Smalltalk developers?", the problem is 
rather
"How much effort does it take to help a good experienced OO developer to 
transition to Smalltalk?"


OO developers have to steadily gain and learn new technologies and 
frameworks...

So why not Smalltalk?
Those developers that are not willing to learn a new language just 
because they consider the trade-offs of not finding a job in that field 
that easily, might not be the best choice for your team anyway...


That is my experience... I know more developers missing the "Smalltalk 
experience" than those hating Smalltalk once they left a team...


Sebastian


On 2017-10-19 12:04 AM, Paulo R. Dellani wrote:

Dear all,

after using Smalltalk for several years I developed a passion for the
language (how not to?), and Pharo is just so great to develop with.
So thank you guys for keeping this wonderful project running.

Unfortunately, it is not easy to always point out why Smalltalk
should be employed as "main development language" in a team
or for a project. In the last discussion of this sort I was confronted
with the question "where are we going to get new smalltalk
developers if our startup grows or if you go?". Well, I had no
good answer to that. What would have you answered?

Cheers,

Paulo






--- End Message ---

Re: [Pharo-users] Smalltalk Argument

[James Ladd]

Hi Paulo,

That is a really good question and I hope to do it justice.

What if you chose Elixir, Ruby, Closure, Go or Pony or Smalltalk - where would 
you get developers?

There is some validity to this question as it can be hard to get developers but 
in Smalltalk’s case there is a heritage that can help with that more so than 
say others that are too new to have a large community following and of course a 
reputation.

Smalltalk has a reputation as a very productive environment and on average a 
better class (pardon the pun) of developers. There is something about Smalltalk 
developers that in my experience outshines developers from other backgrounds.

Personally I’d see Smalltalk as a draw card to join a company but I’m biased.

While it is important in a startup to attract good developers I would say that 
‘good’ developers are more interested in the problem being solved than 
specifically the language being used. The goal w be to get something out and 
make revenue. You will most likely re-write at a future point that makes sense 
using what you have learned anyways.

Of all the languages I have used over 30 years I find Smalltalk the easiest to 
pick up and run w so should you leave others should be able to continue in your 
absence.
Besides depending on their position and background you w want them to own the 
solution and if changing language is part of that then so be it.

That said, if they use Smalltalk for any reasonable amount of time and in anger 
I’d be surprised if they like you didn’t come to love it.

In a nutshell - language choice is the least of your worries

- James 



Sent from my Commodore 64

> On 19 Oct 2017, at 6:04 pm, Paulo R. Dellani  wrote:
> 
> Dear all,
> 
> after using Smalltalk for several years I developed a passion for the
> language (how not to?), and Pharo is just so great to develop with.
> So thank you guys for keeping this wonderful project running.
> 
> Unfortunately, it is not easy to always point out why Smalltalk
> should be employed as "main development language" in a team
> or for a project. In the last discussion of this sort I was confronted
> with the question "where are we going to get new smalltalk
> developers if our startup grows or if you go?". Well, I had no
> good answer to that. What would have you answered?
> 
> Cheers,
> 
> Paulo
> 
>