Discussion:
Smalltalk Argument
(too old to reply)
Paulo R. Dellani
2017-10-19 07:04:55 UTC
Permalink
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
James Ladd
2017-10-19 07:51:09 UTC
Permalink
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
Post by 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
stephan
2017-10-19 08:16:03 UTC
Permalink
Post by Paulo R. Dellani
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
James Ladd
2017-10-19 08:19:20 UTC
Permalink
Nice response

Sent from my Commodore 64
Post by James Ladd
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
Post by 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
Davorin Rusevljan
2017-10-19 08:21:02 UTC
Permalink
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
Post by 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
i***@schrievkrom.de
2017-10-19 10:57:46 UTC
Permalink
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
Post by 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
j***@objektfabrik.de
2017-10-20 07:23:53 UTC
Permalink
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&feel, 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:***@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
Paulo R. Dellani
2017-10-20 07:46:26 UTC
Permalink
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
Post by j***@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&feel, 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
"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
stephan
2017-10-20 08:53:43 UTC
Permalink
Post by j***@objektfabrik.de
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
Peter Fisk
2017-10-20 14:21:26 UTC
Permalink
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
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&feel, 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
--
-----------------------------------------------------------------------
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
j***@objektfabrik.de
2017-11-06 07:11:44 UTC
Permalink
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
Post by 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
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&feel, 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         
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
<http://joachimtuchel.wordpress.com>
Telefon: +49 7141 56 10 86 0 <tel:%2B49%207141%2056%2010%2086%200>
   Fax: +49 7141 56 10 86 1 <tel:%2B49%207141%2056%2010%2086%201>
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:***@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
Peter Fisk
2017-11-07 19:32:23 UTC
Permalink


Hello Joachim,

This is my first post since 2017-10-20, so that may explain some of the
missing replies ;).

​Smalltalk Express is syntax compatible with Pharo although much of the
class structure is very different because of the foundation technologies. I
will add a blog post soon to explain the differences.

Above is an image and a short video showing a test of the desktop version
with some animations.

In the next few days, I hope to have another demo ready of Smalltalk
running inside a Facebook page.
Once that is working, I can use the Google server to connect client game
apps using sockets.

We all know that Smalltalk is a great language.

If we can make it available where people spend their time (Facebook,
Google), I am sure that it
will become popular again.

Maybe we can even connect Smalltalk applications through Twitter :)

Here is my latest blog post.
https://smalltalkexpress.quora.com/Graphic-Animation-for-Games-and-Education

-- Peter
Post by j***@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
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
Post by j***@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&feel, 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
--
-----------------------------------------------------------------------
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
--
-----------------------------------------------------------------------
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
David Mason
2017-10-24 15:51:29 UTC
Permalink
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.
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&feel, 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
--
-----------------------------------------------------------------------
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
Andrew Glynn
2017-10-25 22:46:22 UTC
Permalink
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 any way I can avoid 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.



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’.  An application is by definition a state-machine, which implies plenty about JS developers on the whole.



If you’re a good developer you can write good code in (nearly) anything.  My question then is why would you want to write in crap?  The better question is why aren’t there more good developers in any language?



Every project I have been able to do in Smalltalk, though, has had one thing in common, the “shit has to work”.  Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when “shit has to work”.  They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers. 



Why do they not do it?  One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often.  Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t. 



Why don’t their competitors do it?  Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t.  Put more generally, average stupidity that isn’t corrected by the market.  Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work. 



Enterprises can, and do use Smalltalk when it matters.  When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.



Cost 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-***@lists.pharo.org> on behalf of David Mason <***@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-***@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, ***@objektfabrik.de <***@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&feel, 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:***@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
henry
2017-10-25 23:09:13 UTC
Permalink
It’s well said, I don’t give a f*** about other languages. NSA-proof, anonymized 2048-bit key rendezvoused connection framework in 33 classes. Includes user definable cipher and encoder. SmalltalkHub talkin ParrotTalk.

http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz

- HH
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.
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.
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work". They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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]("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.
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&feel, 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
—
————————————————————————
Fliederweg 1 [http://www.objektfabrik.de]("http://www.objektfabrik.de")
D-71640 Ludwigsburg [http://joachimtuchel.wordpress.com]("http://joachimtuchel.wordpress.com")
Telefon: [+49 7141 56 10 86 0]("tel:%2B49%207141%2056%2010%2086%200") Fax: [+49 7141 56 10 86 1]("tel:%2B49%207141%2056%2010%2086%201")
p***@highoctane.be
2017-10-26 06:17:29 UTC
Permalink
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
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.
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.
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’. An application is by definition a
state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything.
My question then is why would you want to write in crap? The better
question is why aren’t there more good developers in *any* language?
Every project I have been able to do in Smalltalk, though, has had one
thing in common, the “shit has to work”. Companies do use it, in fact I
could name 4 large enterprises I’ve worked for who’ve written their own
dialects, and they all use it only when “shit has to work”. They know it’s
more productive, they also know using it for more things would increase the
availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize
it, because management doesn’t admit even to themselves why they do it, or
not very often. Being inefficient, as long as it doesn’t ‘really’ matter,
is an advantage to large enterprises because they have resources smaller
competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly
rate, what’s fashionable, or just new, or because their customers can’t.
Put more generally, average stupidity that isn’t corrected by the market.
Fashion affects smaller companies more than larger ones, because they can’t
afford a few customers walking away because they wanted an app in Electron,
even if they can’t give any relevant reason for wanting it, and even the
samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t,
it’s to their advantage to promote things that are inefficient, buggy and
unreliable.
Cost 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.
*Reply-To: *Any question about pharo is welcome <
*Date: *Tuesday, October 24, 2017 at 11:52 AM
*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.
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&feel, 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
--
-----------------------------------------------------------------------
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
henry
2017-10-26 06:43:15 UTC
Permalink
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
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]("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
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.
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.
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work". They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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]("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.
Post by Andrew Glynn
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&feel, 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
—
————————————————————————
Fliederweg 1 [http://www.objektfabrik.de]("http://www.objektfabrik.de")
D-71640 Ludwigsburg [http://joachimtuchel.wordpress.com]("http://joachimtuchel.wordpress.com")
Telefon: [+49 7141 56 10 86 0]("tel:%2B49%207141%2056%2010%2086%200") Fax: [+49 7141 56 10 86 1]("tel:%2B49%207141%2056%2010%2086%201")
p***@highoctane.be
2017-10-26 07:14:52 UTC
Permalink
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
Post by henry
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
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
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.
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.
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’. An application is by definition a
state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything.
My question then is why would you want to write in crap? The better
question is why aren’t there more good developers in *any* language?
Every project I have been able to do in Smalltalk, though, has had one
thing in common, the "shit has to work". Companies do use it, in fact I
could name 4 large enterprises I’ve worked for who’ve written their own
dialects, and they all use it only when "shit has to work". They know it’s
more productive, they also know using it for more things would increase the
availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize
it, because management doesn’t admit even to themselves why they do it, or
not very often. Being inefficient, as long as it doesn’t ‘really’ matter,
is an advantage to large enterprises because they have resources smaller
competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly
rate, what’s fashionable, or just new, or because their customers can’t.
Put more generally, average stupidity that isn’t corrected by the market.
Fashion affects smaller companies more than larger ones, because they can’t
afford a few customers walking away because they wanted an app in Electron,
even if they can’t give any relevant reason for wanting it, and even the
samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t,
it’s to their advantage to promote things that are inefficient, buggy and
unreliable.
Cost 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.
*Reply-To: *Any question about pharo is welcome <
*Date: *Tuesday, October 24, 2017 at 11:52 AM
*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.
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&feel, 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
—
————————————————————————
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
henry
2017-10-26 12:52:09 UTC
Permalink
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.
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]("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]("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
Post by henry
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
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
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.
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.
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work". They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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.
Post by Andrew Glynn
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&feel, 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
—
————————————————————————
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
henry
2017-10-26 13:06:02 UTC
Permalink
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
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.
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]("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]("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
Post by henry
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
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
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.
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.
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work". They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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.
Post by Andrew Glynn
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&feel, 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
—
————————————————————————
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
henry
2017-10-26 13:15:34 UTC
Permalink
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
Post by henry
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
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.
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](""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](""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
Post by henry
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
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
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.
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.
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work". They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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.
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&feel, 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
—
————————————————————————
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
henry
2017-10-26 13:37:54 UTC
Permalink
Here is a truer diagram of what I want to do. Sideways?

[hubbub.jpg]

- HH
-------- Original Message --------
Subject: Re: [Pharo-users] Smalltalk Argument
Local Time: October 26, 2017 9:15 AM
UTC Time: October 26, 2017 1:15 PM
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
——— Original Message ———
Subject: Re: [Pharo-users] Smalltalk Argument
Local Time: October 26, 2017 8:52 AM
UTC Time: October 26, 2017 12:52 PM
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.
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](""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](""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
Post by henry
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
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
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.
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.
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work". They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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.
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&feel, 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
—
————————————————————————
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
henry
2017-10-26 14:38:49 UTC
Permalink
A Kerberos effort will have to be a group effort. Sideways to my main focus and your all’s main focii.

- HH
Post by henry
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
Post by henry
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
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.
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]("""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]("""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
Post by henry
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
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
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.
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.
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work". They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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.
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&feel, 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
—
————————————————————————
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
henry
2017-10-26 15:07:32 UTC
Permalink
The question I propose you is what is necessary to make Pharo eligible to participate in cloud/BigData?

- HH
Post by henry
A Kerberos effort will have to be a group effort. Sideways to my main focus and your all’s main focii.
- HH
Post by henry
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
Post by henry
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
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.
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](""""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](""""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
Post by henry
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
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
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.
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.
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work". They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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.
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&feel, 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
—
————————————————————————
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
Paulo R. Dellani
2017-10-26 15:39:53 UTC
Permalink
This all sounds very interesting. What is the idea? Wrap libkrb5 through
UFFI or implement it in Smalltalk?
Post by henry
A Kerberos effort will have to be a group effort. Sideways to my main
focus and your all’s main focii.
- HH
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
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
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.
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
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
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
henry
2017-10-26 16:23:45 UTC
Permalink
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
This all sounds very interesting. What is the idea? Wrap libkrb5 through UFFI or implement it in Smalltalk?
Post by henry
A Kerberos effort will have to be a group effort. Sideways to my main focus and your all’s main focii.
- HH
Post by henry
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
Post by henry
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
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.
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
Post by henry
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
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
p***@highoctane.be
2017-10-26 22:06:07 UTC
Permalink
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
Post by 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
This all sounds very interesting. What is the idea? Wrap libkrb5 through
UFFI or implement it in Smalltalk?
A Kerberos effort will have to be a group effort. Sideways to my main
focus and your all’s main focii.
- HH
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
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
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.
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
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
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-na
tive-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
Andrew Glynn
2017-10-28 03:10:46 UTC
Permalink
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: ***@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 <***@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 <***@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 <***@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 <***@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: ***@callistohouse.club
To: ***@highoctane.be <***@highoctane.be>, Any question about pharo is welcome <pharo-***@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, ***@highoctane.be <***@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 <***@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, ***@highoctane.be < ***@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 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
henry
2017-10-27 13:49:29 UTC
Permalink
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
Post by 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
Post by 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
This all sounds very interesting. What is the idea? Wrap libkrb5 through UFFI or implement it in Smalltalk?
Post by henry
A Kerberos effort will have to be a group effort. Sideways to my main focus and your all’s main focii.
- HH
Post by henry
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
Post by henry
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
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.
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
Post by henry
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
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
Andrew Glynn
2017-10-28 03:09:42 UTC
Permalink
F-Script screenshots I promised. Look familiar to anyone?



Sent from Mail for Windows 10

From: henry
Sent: Friday, October 27, 2017 9:50 AM
To: ***@highoctane.be; Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument

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, ***@highoctane.be <***@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" <***@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 <***@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 <***@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 <***@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: ***@callistohouse.club
To: ***@highoctane.be <***@highoctane.be>, Any question about pharo is welcome <pharo-***@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, ***@highoctane.be <***@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 <***@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, ***@highoctane.be < ***@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 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
Andrew Glynn
2017-10-28 00:30:27 UTC
Permalink
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: ***@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 <***@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 any way I can avoid 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.
 
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’.  An application is by definition a state-machine, which implies plenty about JS developers on the whole.
 
If you’re a good developer you can write good code in (nearly) anything.  My question then is why would you want to write in crap?  The better question is why aren’t there more good developers in any language?
 
Every project I have been able to do in Smalltalk, though, has had one thing in common, the “shit has to work”.  Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when “shit has to work”.  They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers. 
 
Why do they not do it?  One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often.  Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t. 
 
Why don’t their competitors do it?  Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t.  Put more generally, average stupidity that isn’t corrected by the market.  Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work. 
 
Enterprises can, and do use Smalltalk when it matters.  When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
 
Cost 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-***@lists.pharo.org> on behalf of David Mason <***@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-***@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, ***@objektfabrik.de <***@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&feel, 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:***@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
 
Ben Coman
2017-10-28 00:42:53 UTC
Permalink
Post by Andrew Glynn
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
Stephane Ducasse
2017-10-28 09:05:39 UTC
Permalink
Hi andrew

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

Stef
Post by Andrew Glynn
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
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
*Sent: *Thursday, October 26, 2017 2:19 AM
*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
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.
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.
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’. An application is by definition a
state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything.
My question then is why would you want to write in crap? The better
question is why aren’t there more good developers in *any* language?
Every project I have been able to do in Smalltalk, though, has had one
thing in common, the “shit has to work”. Companies do use it, in fact I
could name 4 large enterprises I’ve worked for who’ve written their own
dialects, and they all use it only when “shit has to work”. They know it’s
more productive, they also know using it for more things would increase the
availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize
it, because management doesn’t admit even to themselves why they do it, or
not very often. Being inefficient, as long as it doesn’t ‘really’ matter,
is an advantage to large enterprises because they have resources smaller
competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly
rate, what’s fashionable, or just new, or because their customers can’t.
Put more generally, average stupidity that isn’t corrected by the market.
Fashion affects smaller companies more than larger ones, because they can’t
afford a few customers walking away because they wanted an app in Electron,
even if they can’t give any relevant reason for wanting it, and even the
samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t,
it’s to their advantage to promote things that are inefficient, buggy and
unreliable.
Cost 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.
*Reply-To: *Any question about pharo is welcome <
*Date: *Tuesday, October 24, 2017 at 11:52 AM
*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.
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&feel, 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
--
-----------------------------------------------------------------------
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
Stephane Ducasse
2017-10-28 09:08:26 UTC
Permalink
Hi andrew

please take a project that would help to bring more companies and that you
want to push and push it with us :).


Stef
Post by Stephane Ducasse
Hi andrew
you should contact esteban because he is writing an objective-C bridge.
Stef
Post by Andrew Glynn
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
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
*Sent: *Thursday, October 26, 2017 2:19 AM
*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-na
tive-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
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.
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.
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’. An application is by definition a
state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything.
My question then is why would you want to write in crap? The better
question is why aren’t there more good developers in *any* language?
Every project I have been able to do in Smalltalk, though, has had one
thing in common, the “shit has to work”. Companies do use it, in fact I
could name 4 large enterprises I’ve worked for who’ve written their own
dialects, and they all use it only when “shit has to work”. They know it’s
more productive, they also know using it for more things would increase the
availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize
it, because management doesn’t admit even to themselves why they do it, or
not very often. Being inefficient, as long as it doesn’t ‘really’ matter,
is an advantage to large enterprises because they have resources smaller
competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly
rate, what’s fashionable, or just new, or because their customers can’t.
Put more generally, average stupidity that isn’t corrected by the market.
Fashion affects smaller companies more than larger ones, because they can’t
afford a few customers walking away because they wanted an app in Electron,
even if they can’t give any relevant reason for wanting it, and even the
samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t,
it’s to their advantage to promote things that are inefficient, buggy and
unreliable.
Cost 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.
*Reply-To: *Any question about pharo is welcome <
*Date: *Tuesday, October 24, 2017 at 11:52 AM
*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.
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&feel, 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
--
-----------------------------------------------------------------------
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
Andrew Glynn
2017-10-28 13:12:08 UTC
Permalink
Writing that kind of code is another of the reasons I decided I don’t want to work in anything else 😊. Maybe more important than some of the others, both to myself and to other users.

I’ve gained so much personally, mostly for nothing, even just considering the relatively few projects I have been able to work on in Pharo and previously in Squeak, VW and VA. Unfortunately in most I haven’t been able to make the code public, since they were for entities like the government, DoD, etc.

Not that VA attracts me quite so much to give back all that strongly, when a license is $8500+. Were it possible to give back to VA C++ or VA Java, it might be different, but neither were OSS although they weren’t expensive. More relevantly, both are now abandonware (hence my comment about IBM, which is applicable to OS/2 as well, although that has quietly had a 5.0 version released in June of this year).

I would, though, love a chance to give back to Pharo primarily, although I may port anything relevant to Squeak, and if I have sufficient time port it to VW, which although not OSS is at least affordable to most developers.

I’m nearly there on a couple of projects – one I’m testing and making final tweaks, another is about 2/3d’s of the way.

The first project you (and others on the list) may be more immediately interested in testing, since it requires little to no additional work to use it, and even if not perfect, since it’s intended to directly help work you are doing in Pharo, it may worthwhile. I’m hoping to have it ready for public consumption by the middle of November.

On a different but related topic, the article I wrote got a fair amount of interest considering I don’t write nearly as well as Kenneth, for example. Including direct interest from some well known industry people, which can’t hurt. In an indirect way it may even be helpful, but not in the real, direct way decent code is.

Capabilities that won’t be available in anything else in an really usable way (because to be efficient they depend on capabilities not found in anything else), and in any case nowhere near as useful in anything else, will hopefully be more use than any article can be, never mind one I wrote, not just to me but also to other Pharo users and to Pharo itself.

Cheers
Andrew Glynn


Sent from Mail for Windows 10

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

Hi andrew

please take a project that would help to bring more companies and that you want to push and push it with us :).


Stef


On Sat, Oct 28, 2017 at 11:05 AM, Stephane Ducasse <***@gmail.com> wrote:
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 <***@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: ***@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 <***@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 any way I can avoid 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.
 
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’.  An application is by definition a state-machine, which implies plenty about JS developers on the whole.
 
If you’re a good developer you can write good code in (nearly) anything.  My question then is why would you want to write in crap?  The better question is why aren’t there more good developers in any language?
 
Every project I have been able to do in Smalltalk, though, has had one thing in common, the “shit has to work”.  Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when “shit has to work”.  They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers. 
 
Why do they not do it?  One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often.  Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t. 
 
Why don’t their competitors do it?  Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t.  Put more generally, average stupidity that isn’t corrected by the market.  Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work. 
 
Enterprises can, and do use Smalltalk when it matters.  When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
 
Cost 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-***@lists.pharo.org> on behalf of David Mason <***@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-***@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, ***@objektfabrik.de <***@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&feel, 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:***@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
 
 
 
henry
2017-10-28 14:01:51 UTC
Permalink
Hi Andrew,

Are you working to bring a Capabilities model to Pharo? This is precisely what I am working to bring with Hubbub, running on top of my ParrotTalk. I derived these from erights.org's ELib and have been working on them for many years. Now that ParrotTalk has stabilized (layer 5) I am shifting to implementing marshalling of layer 6 objects using STON all to run on top of ParrotTalk. Once I get marshalling with scope substitutions, I will debug Hubbub to offer distributed Capabilities.

What work are you undertaking?

Regards,
- HH
-------- Original Message --------
Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment
Local Time: October 28, 2017 9:12 AM
UTC Time: October 28, 2017 1:12 PM
Writing that kind of code is another of the reasons I decided I don’t want to work in anything else 😊. Maybe more important than some of the others, both to myself and to other users.
I’ve gained so much personally, mostly for nothing, even just considering the relatively few projects I have been able to work on in Pharo and previously in Squeak, VW and VA. Unfortunately in most I haven’t been able to make the code public, since they were for entities like the government, DoD, etc.
Not that VA attracts me quite so much to give back all that strongly, when a license is $8500+. Were it possible to give back to VA C++ or VA Java, it might be different, but neither were OSS although they weren’t expensive. More relevantly, both are now abandonware (hence my comment about IBM, which is applicable to OS/2 as well, although that has quietly had a 5.0 version released in June of this year).
I would, though, love a chance to give back to Pharo primarily, although I may port anything relevant to Squeak, and if I have sufficient time port it to VW, which although not OSS is at least affordable to most developers.
I’m nearly there on a couple of projects – one I’m testing and making final tweaks, another is about 2/3d’s of the way.
The first project you (and others on the list) may be more immediately interested in testing, since it requires little to no additional work to use it, and even if not perfect, since it’s intended to directly help work you are doing in Pharo, it may worthwhile. I’m hoping to have it ready for public consumption by the middle of November.
On a different but related topic, the article I wrote got a fair amount of interest considering I don’t write nearly as well as Kenneth, for example. Including direct interest from some well known industry people, which can’t hurt. In an indirect way it may even be helpful, but not in the real, direct way decent code is.
Capabilities that won’t be available in anything else in an really usable way (because to be efficient they depend on capabilities not found in anything else), and in any case nowhere near as useful in anything else, will hopefully be more use than any article can be, never mind one I wrote, not just to me but also to other Pharo users and to Pharo itself.
Cheers
Andrew Glynn
Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10
Sent: Saturday, October 28, 2017 5:09 AM
Subject: Re: [Pharo-users] Smalltalk Argument
Hi andrew
please take a project that would help to bring more companies and that you want to push and push it with us :).
Stef
Post by Stephane Ducasse
Hi andrew
you should contact esteban because he is writing an objective-C bridge.
Stef
Post by Andrew Glynn
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.
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
Sent: Thursday, October 26, 2017 2:19 AM
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
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.
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.
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the “shit has to work”. Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when “shit has to work”. They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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.
Post by Andrew Glynn
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&feel, 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
--
-----------------------------------------------------------------------
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: [+49 7141 56 10 86 0](tel:%2B49%207141%2056%2010%2086%200) Fax: [+49 7141 56 10 86 1](tel:%2B49%207141%2056%2010%2086%201)
Andrew Glynn
2017-10-28 15:25:53 UTC
Permalink
I’m not working on that specifically, although what I am working on could definitely use that and vice versa, which would increase the capabilities of each.

One thing I’m working on is using Vert.x for service registration and discovery, mapped to Apache River (JINI) to propagate that over non-local network segments that require fully authenticated security (as a result, it also provides things such as Kerberos to Pharo apps). The mapping between the two is very straightforward, almost direct, but I’ve added the Synapse micro service bus to control data flows and secure access to remote services.

It enables things like automatic configuration/integration of Pharo based mobile apps with newer cars that support that kind of autoconfiguration, since they all use JINI to do so. Thus a Pharo mobile or IoT app can automatically be configured to work with any of the car’s subsystems that are relevant to it.

JINI is far more used than people realize, partly because it ‘just works’ and as a result doesn’t get the public ‘squeaky wheel’ effect. The fact that the authors of Vert.x reimplemented half of the features of JINI, in a less comprehensive and less reliable way, rather than just using it (especially considering it’s open source) shows the degree to which that effect is operative.

There’s probably a couple dozen other general use cases where the integration will allow Pharo apps to ‘just work’ in a JINI or Vert.x environment, as well as thousands of industry/company specific ones. I’d have to mode-switch to think of them off the top of my head though 😊.

Andrew

Sent from Mail for Windows 10

From: henry
Sent: Saturday, October 28, 2017 10:02 AM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment

Hi Andrew,

Are you working to bring a Capabilities model to Pharo? This is precisely what I am working to bring with Hubbub, running on top of my ParrotTalk. I derived these from erights.org's ELib and have been working on them for many years. Now that ParrotTalk has stabilized (layer 5) I am shifting to implementing marshalling of layer 6 objects using STON all to run on top of ParrotTalk. Once I get marshalling with scope substitutions, I will debug Hubbub to offer distributed Capabilities.

What work are you undertaking?

Regards,
- HH


-------- Original Message --------
Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment
Local Time: October 28, 2017 9:12 AM
UTC Time: October 28, 2017 1:12 PM
From: ***@gmail.com
To: Any question about pharo is welcome <pharo-***@lists.pharo.org>

Writing that kind of code is another of the reasons I decided I don’t want to work in anything else 😊.  Maybe more important than some of the others, both to myself and to other users.
 
I’ve gained so much personally, mostly for nothing, even just considering the relatively few  projects I have been able to work on in Pharo and previously in Squeak, VW and VA.  Unfortunately in most I haven’t been able to make the code public, since they were for entities like the government, DoD, etc.  
 
Not that VA attracts me quite so much to give back all that strongly, when a license is $8500+.  Were it possible to give back to VA C++ or VA Java, it might be different, but neither were OSS although they weren’t expensive.  More relevantly, both are now abandonware (hence my comment about IBM, which is applicable to OS/2 as well, although that has quietly had a 5.0 version released in June of this year).
 
I would, though, love a chance to give back to Pharo primarily, although I may port anything relevant to Squeak, and if I have sufficient time port it to VW, which although not OSS is at least affordable to most developers.
 
I’m nearly there on a couple of projects – one I’m testing and making final tweaks, another is about 2/3d’s of the way. 
 
The first project you (and others on the list) may be more immediately interested in testing, since it requires little to no additional work to use it, and even if not perfect, since it’s intended to directly help work you are doing in Pharo, it may worthwhile.  I’m hoping to have it ready for public consumption by the middle of November. 
 
On a different but related topic, the article I wrote got a fair amount of interest considering I don’t write nearly as well as Kenneth, for example.  Including direct interest from some well known industry people, which can’t hurt.  In an indirect way it may even be helpful, but not in the real, direct way decent code is.
 
Capabilities that won’t be available in anything else in an really usable way (because to be efficient they depend on capabilities not found in anything else), and in any case nowhere near as useful in anything else, will hopefully be more use than any article can be, never mind one I wrote, not just to me but also to other Pharo users and to Pharo itself.
 
Cheers
Andrew Glynn
 
 
Sent from Mail for Windows 10
 
From: Stephane Ducasse
Sent: Saturday, October 28, 2017 5:09 AM
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Smalltalk Argument
 
Hi andrew
 
please take a project that would help to bring more companies and that you want to push and push it with us :).
 
 
Stef
 
 
On Sat, Oct 28, 2017 at 11:05 AM, Stephane Ducasse <***@gmail.com> wrote:
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 <***@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: ***@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 <***@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 any way I can avoid 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.
 
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’.  An application is by definition a state-machine, which implies plenty about JS developers on the whole.
 
If you’re a good developer you can write good code in (nearly) anything.  My question then is why would you want to write in crap?  The better question is why aren’t there more good developers in any language?
 
Every project I have been able to do in Smalltalk, though, has had one thing in common, the “shit has to work”.  Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when “shit has to work”.  They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers. 
 
Why do they not do it?  One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often.  Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t. 
 
Why don’t their competitors do it?  Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t.  Put more generally, average stupidity that isn’t corrected by the market.  Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work. 
 
Enterprises can, and do use Smalltalk when it matters.  When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
 
Cost 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-***@lists.pharo.org> on behalf of David Mason <***@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-***@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, ***@objektfabrik.de <***@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&feel, 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:***@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
 
 
 
 
 
 
henry
2017-10-28 17:23:13 UTC
Permalink
I used to use JINI, a fine system. I didn’t know it had been rereleased as Apache River, I’ve been out of it awhile. This was the broker system that got me interested in Linda. Now I have an eventual Linda project called eLinda, which you can find in the Cryptography repository, no prerequisites needed.

- HH
Post by Andrew Glynn
I’m not working on that specifically, although what I am working on could definitely use that and vice versa, which would increase the capabilities of each.
One thing I’m working on is using Vert.x for service registration and discovery, mapped to Apache River (JINI) to propagate that over non-local network segments that require fully authenticated security (as a result, it also provides things such as Kerberos to Pharo apps). The mapping between the two is very straightforward, almost direct, but I’ve added the Synapse micro service bus to control data flows and secure access to remote services.
It enables things like automatic configuration/integration of Pharo based mobile apps with newer cars that support that kind of autoconfiguration, since they all use JINI to do so. Thus a Pharo mobile or IoT app can automatically be configured to work with any of the car’s subsystems that are relevant to it.
JINI is far more used than people realize, partly because it ‘just works’ and as a result doesn’t get the public ‘squeaky wheel’ effect. The fact that the authors of Vert.x reimplemented half of the features of JINI, in a less comprehensive and less reliable way, rather than just using it (especially considering it’s open source) shows the degree to which that effect is operative.
There’s probably a couple dozen other general use cases where the integration will allow Pharo apps to ‘just work’ in a JINI or Vert.x environment, as well as thousands of industry/company specific ones. I’d have to mode-switch to think of them off the top of my head though 😊.
Andrew
Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10
Sent: Saturday, October 28, 2017 10:02 AM
Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment
Hi Andrew,
Are you working to bring a Capabilities model to Pharo? This is precisely what I am working to bring with Hubbub, running on top of my ParrotTalk. I derived these from erights.org's ELib and have been working on them for many years. Now that ParrotTalk has stabilized (layer 5) I am shifting to implementing marshalling of layer 6 objects using STON all to run on top of ParrotTalk. Once I get marshalling with scope substitutions, I will debug Hubbub to offer distributed Capabilities.
What work are you undertaking?
Regards,
- HH
-------- Original Message --------
Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment
Local Time: October 28, 2017 9:12 AM
UTC Time: October 28, 2017 1:12 PM
Writing that kind of code is another of the reasons I decided I don’t want to work in anything else 😊. Maybe more important than some of the others, both to myself and to other users.
I’ve gained so much personally, mostly for nothing, even just considering the relatively few projects I have been able to work on in Pharo and previously in Squeak, VW and VA. Unfortunately in most I haven’t been able to make the code public, since they were for entities like the government, DoD, etc.
Not that VA attracts me quite so much to give back all that strongly, when a license is $8500+. Were it possible to give back to VA C++ or VA Java, it might be different, but neither were OSS although they weren’t expensive. More relevantly, both are now abandonware (hence my comment about IBM, which is applicable to OS/2 as well, although that has quietly had a 5.0 version released in June of this year).
I would, though, love a chance to give back to Pharo primarily, although I may port anything relevant to Squeak, and if I have sufficient time port it to VW, which although not OSS is at least affordable to most developers.
I’m nearly there on a couple of projects – one I’m testing and making final tweaks, another is about 2/3d’s of the way.
The first project you (and others on the list) may be more immediately interested in testing, since it requires little to no additional work to use it, and even if not perfect, since it’s intended to directly help work you are doing in Pharo, it may worthwhile. I’m hoping to have it ready for public consumption by the middle of November.
On a different but related topic, the article I wrote got a fair amount of interest considering I don’t write nearly as well as Kenneth, for example. Including direct interest from some well known industry people, which can’t hurt. In an indirect way it may even be helpful, but not in the real, direct way decent code is.
Capabilities that won’t be available in anything else in an really usable way (because to be efficient they depend on capabilities not found in anything else), and in any case nowhere near as useful in anything else, will hopefully be more use than any article can be, never mind one I wrote, not just to me but also to other Pharo users and to Pharo itself.
Cheers
Andrew Glynn
Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10
Sent: Saturday, October 28, 2017 5:09 AM
Subject: Re: [Pharo-users] Smalltalk Argument
Hi andrew
please take a project that would help to bring more companies and that you want to push and push it with us :).
Stef
Post by Stephane Ducasse
Hi andrew
you should contact esteban because he is writing an objective-C bridge.
Stef
Post by Andrew Glynn
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.
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
Sent: Thursday, October 26, 2017 2:19 AM
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
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.
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.
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work". They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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.
Post by Andrew Glynn
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&feel, 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
--
-----------------------------------------------------------------------
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: [+49 7141 56 10 86 0](tel:%2B49%207141%2056%2010%2086%200) Fax: [+49 7141 56 10 86 1](tel:%2B49%207141%2056%2010%2086%201)
henry
2017-10-29 00:39:29 UTC
Permalink
Here is a diagram of the various components I am working on integrating,.

[hubbub.jpg]

- HH
-------- Original Message --------
Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment
Local Time: October 28, 2017 1:23 PM
UTC Time: October 28, 2017 5:23 PM
I used to use JINI, a fine system. I didn’t know it had been rereleased as Apache River, I’ve been out of it awhile. This was the broker system that got me interested in Linda. Now I have an eventual Linda project called eLinda, which you can find in the Cryptography repository, no prerequisites needed.
- HH
Post by Andrew Glynn
I’m not working on that specifically, although what I am working on could definitely use that and vice versa, which would increase the capabilities of each.
One thing I’m working on is using Vert.x for service registration and discovery, mapped to Apache River (JINI) to propagate that over non-local network segments that require fully authenticated security (as a result, it also provides things such as Kerberos to Pharo apps). The mapping between the two is very straightforward, almost direct, but I’ve added the Synapse micro service bus to control data flows and secure access to remote services.
It enables things like automatic configuration/integration of Pharo based mobile apps with newer cars that support that kind of autoconfiguration, since they all use JINI to do so. Thus a Pharo mobile or IoT app can automatically be configured to work with any of the car’s subsystems that are relevant to it.
JINI is far more used than people realize, partly because it ‘just works’ and as a result doesn’t get the public ‘squeaky wheel’ effect. The fact that the authors of Vert.x reimplemented half of the features of JINI, in a less comprehensive and less reliable way, rather than just using it (especially considering it’s open source) shows the degree to which that effect is operative.
There’s probably a couple dozen other general use cases where the integration will allow Pharo apps to ‘just work’ in a JINI or Vert.x environment, as well as thousands of industry/company specific ones. I’d have to mode-switch to think of them off the top of my head though 😊.
Andrew
Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10
Sent: Saturday, October 28, 2017 10:02 AM
Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment
Hi Andrew,
Are you working to bring a Capabilities model to Pharo? This is precisely what I am working to bring with Hubbub, running on top of my ParrotTalk. I derived these from erights.org's ELib and have been working on them for many years. Now that ParrotTalk has stabilized (layer 5) I am shifting to implementing marshalling of layer 6 objects using STON all to run on top of ParrotTalk. Once I get marshalling with scope substitutions, I will debug Hubbub to offer distributed Capabilities.
What work are you undertaking?
Regards,
- HH
-------- Original Message --------
Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment
Local Time: October 28, 2017 9:12 AM
UTC Time: October 28, 2017 1:12 PM
Writing that kind of code is another of the reasons I decided I don’t want to work in anything else 😊. Maybe more important than some of the others, both to myself and to other users.
I’ve gained so much personally, mostly for nothing, even just considering the relatively few projects I have been able to work on in Pharo and previously in Squeak, VW and VA. Unfortunately in most I haven’t been able to make the code public, since they were for entities like the government, DoD, etc.
Not that VA attracts me quite so much to give back all that strongly, when a license is $8500+. Were it possible to give back to VA C++ or VA Java, it might be different, but neither were OSS although they weren’t expensive. More relevantly, both are now abandonware (hence my comment about IBM, which is applicable to OS/2 as well, although that has quietly had a 5.0 version released in June of this year).
I would, though, love a chance to give back to Pharo primarily, although I may port anything relevant to Squeak, and if I have sufficient time port it to VW, which although not OSS is at least affordable to most developers.
I’m nearly there on a couple of projects – one I’m testing and making final tweaks, another is about 2/3d’s of the way.
The first project you (and others on the list) may be more immediately interested in testing, since it requires little to no additional work to use it, and even if not perfect, since it’s intended to directly help work you are doing in Pharo, it may worthwhile. I’m hoping to have it ready for public consumption by the middle of November.
On a different but related topic, the article I wrote got a fair amount of interest considering I don’t write nearly as well as Kenneth, for example. Including direct interest from some well known industry people, which can’t hurt. In an indirect way it may even be helpful, but not in the real, direct way decent code is.
Capabilities that won’t be available in anything else in an really usable way (because to be efficient they depend on capabilities not found in anything else), and in any case nowhere near as useful in anything else, will hopefully be more use than any article can be, never mind one I wrote, not just to me but also to other Pharo users and to Pharo itself.
Cheers
Andrew Glynn
Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10
Sent: Saturday, October 28, 2017 5:09 AM
Subject: Re: [Pharo-users] Smalltalk Argument
Hi andrew
please take a project that would help to bring more companies and that you want to push and push it with us :).
Stef
Post by Stephane Ducasse
Hi andrew
you should contact esteban because he is writing an objective-C bridge.
Stef
Post by Andrew Glynn
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.
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
Sent: Thursday, October 26, 2017 2:19 AM
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
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.
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.
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work". They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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.
Post by Andrew Glynn
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&feel, 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
--
-----------------------------------------------------------------------
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: [+49 7141 56 10 86 0](tel:%2B49%207141%2056%2010%2086%200) Fax: [+49 7141 56 10 86 1](tel:%2B49%207141%2056%2010%2086%201)
Stephane Ducasse
2017-10-29 18:13:14 UTC
Permalink
Ok tell us when you release something.
having a little example would be really nice.
Post by Andrew Glynn
I’m not working on that specifically, although what I am working on could
definitely use that and vice versa, which would increase the capabilities
of each.
One thing I’m working on is using Vert.x for service registration and
discovery, mapped to Apache River (JINI) to propagate that over non-local
network segments that require fully authenticated security (as a result, it
also provides things such as Kerberos to Pharo apps). The mapping between
the two is very straightforward, almost direct, but I’ve added the Synapse
micro service bus to control data flows and secure access to remote
services.
It enables things like automatic configuration/integration of Pharo based
mobile apps with newer cars that support that kind of autoconfiguration,
since they all use JINI to do so. Thus a Pharo mobile or IoT app can
automatically be configured to work with any of the car’s subsystems that
are relevant to it.
JINI is far more used than people realize, partly because it ‘just works’
and as a result doesn’t get the public ‘squeaky wheel’ effect. The fact
that the authors of Vert.x reimplemented half of the features of JINI, in a
less comprehensive and less reliable way, rather than just using it
(especially considering it’s open source) shows the degree to which that
effect is operative.
There’s probably a couple dozen other general use cases where the
integration will allow Pharo apps to ‘just work’ in a JINI or Vert.x
environment, as well as thousands of industry/company specific ones. I’d
have to mode-switch to think of them off the top of my head though 😊.
Andrew
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows 10
*Sent: *Saturday, October 28, 2017 10:02 AM
*Subject: *Re: [Pharo-users] Actual Code to Improve the Pharo environment
Hi Andrew,
Are you working to bring a Capabilities model to Pharo? This is precisely
what I am working to bring with Hubbub, running on top of my ParrotTalk. I
derived these from erights.org's ELib and have been working on them for
many years. Now that ParrotTalk has stabilized (layer 5) I am shifting to
implementing marshalling of layer 6 objects using STON all to run on top of
ParrotTalk. Once I get marshalling with scope substitutions, I will debug
Hubbub to offer distributed Capabilities.
What work are you undertaking?
Regards,
- HH
-------- Original Message --------
Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment
Local Time: October 28, 2017 9:12 AM
UTC Time: October 28, 2017 1:12 PM
Writing that kind of code is another of the reasons I decided I don’t want
to work in anything else 😊. Maybe more important than some of the
others, both to myself and to other users.
I’ve gained so much personally, mostly for nothing, even just considering
the relatively few projects I *have* been able to work on in Pharo and
previously in Squeak, VW and VA. Unfortunately in most I haven’t been able
to make the code public, since they were for entities like the government,
DoD, etc.
Not that VA attracts me quite so much to give back all that strongly, when
a license is $8500+. Were it possible to give back to VA C++ or VA Java,
it might be different, but neither were OSS although they weren’t
expensive. More relevantly, both are now abandonware (hence my comment
about IBM, which is applicable to OS/2 as well, although that has quietly
had a 5.0 version released in June of this year).
I would, though, love a chance to give back to Pharo primarily, although I
may port anything relevant to Squeak, and if I have sufficient time port it
to VW, which although not OSS is at least affordable to most developers.
I’m nearly there on a couple of projects – one I’m testing and making
final tweaks, another is about 2/3d’s of the way.
The first project you (and others on the list) may be more immediately
interested in testing, since it requires little to no additional work to
use it, and even if not perfect, since it’s intended to directly help work
you *are* doing in Pharo, it may worthwhile. I’m hoping to have it ready
for public consumption by the middle of November.
On a different but related topic, the article I wrote got a fair amount of
interest considering I don’t write nearly as well as Kenneth, for example.
Including direct interest from some well known industry people, which can’t
hurt. In an indirect way it may even be helpful, but not in the real,
direct way decent code is.
Capabilities that won’t be available in anything else in an really usable
way (because to be efficient they depend on capabilities not found in
anything else), and in any case nowhere near as useful in anything else,
will hopefully be more use than any article can be, never mind one I wrote,
not just to me but also to other Pharo users and to Pharo itself.
Cheers
Andrew Glynn
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows 10
*Sent: *Saturday, October 28, 2017 5:09 AM
*Subject: *Re: [Pharo-users] Smalltalk Argument
Hi andrew
please take a project that would help to bring more companies and that you
want to push and push it with us :).
Stef
On Sat, Oct 28, 2017 at 11:05 AM, Stephane Ducasse <
Hi andrew
you should contact esteban because he is writing an objective-C bridge.
Stef
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
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
*Sent: *Thursday, October 26, 2017 2:19 AM
*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
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.
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.
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’. An application is by definition a
state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything.
My question then is why would you want to write in crap? The better
question is why aren’t there more good developers in *any* language?
Every project I have been able to do in Smalltalk, though, has had one
thing in common, the “shit has to work”. Companies do use it, in fact I
could name 4 large enterprises I’ve worked for who’ve written their own
dialects, and they all use it only when “shit has to work”. They know it’s
more productive, they also know using it for more things would increase the
availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize
it, because management doesn’t admit even to themselves why they do it, or
not very often. Being inefficient, as long as it doesn’t ‘really’ matter,
is an advantage to large enterprises because they have resources smaller
competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly
rate, what’s fashionable, or just new, or because their customers can’t.
Put more generally, average stupidity that isn’t corrected by the market.
Fashion affects smaller companies more than larger ones, because they can’t
afford a few customers walking away because they wanted an app in Electron,
even if they can’t give any relevant reason for wanting it, and even the
samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t,
it’s to their advantage to promote things that are inefficient, buggy and
unreliable.
Cost 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.
*Reply-To: *Any question about pharo is welcome <
*Date: *Tuesday, October 24, 2017 at 11:52 AM
*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.
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&feel, 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
--
-----------------------------------------------------------------------
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
Andrew Glynn
2017-10-28 18:14:03 UTC
Permalink
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 <***@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: ***@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 <***@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 any way I can avoid 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.
 
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’.  An application is by definition a state-machine, which implies plenty about JS developers on the whole.
 
If you’re a good developer you can write good code in (nearly) anything.  My question then is why would you want to write in crap?  The better question is why aren’t there more good developers in any language?
 
Every project I have been able to do in Smalltalk, though, has had one thing in common, the “shit has to work”.  Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when “shit has to work”.  They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers. 
 
Why do they not do it?  One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often.  Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t. 
 
Why don’t their competitors do it?  Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t.  Put more generally, average stupidity that isn’t corrected by the market.  Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work. 
 
Enterprises can, and do use Smalltalk when it matters.  When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
 
Cost 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-***@lists.pharo.org> on behalf of David Mason <***@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-***@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, ***@objektfabrik.de <***@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&feel, 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:***@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
 
 
 
Todd Blanchard
2017-11-08 08:59:25 UTC
Permalink
Post by Stephane Ducasse
Hi andrew
you should contact esteban because he is writing an objective-C bridge.
Stef
Another one? I think we've written half a dozen now, no? There is some code in the VM libs that allows calling out. I worked on one with Avi for a bit about ten years ago. The callbacks/delegate bit was always problematic. It is one thing to call Objective C (really easy) but another thing to integrate with Cocoa and accept callbacks while keeping the VM live.

I would really love one that let me write Cocoa from Pharo (especially iPhone apps).

I do wonder if this new capability with Objective C blocks wouldn't maybe make things easier. http://www.friday.com/bbum/2011/03/17/ios-4-3-imp_implementationwithblock/
j***@objektfabrik.de
2017-11-06 07:21:17 UTC
Permalink
Phil,
Post by 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.
Post by p***@highoctane.be
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 ;-)
Post by p***@highoctane.be
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:***@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
Dimitris Chloupis
2017-11-06 07:33:54 UTC
Permalink
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.
Post by j***@objektfabrik.de
Phil,
Post by 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.
Post by p***@highoctane.be
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 ;-)
Post by p***@highoctane.be
Think about being able to call Pharo from JNA
https://github.com/java-native-access/jna the same way we use C with
UFFI.
Post by p***@highoctane.be
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
--
-----------------------------------------------------------------------
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
Andrew Glynn
2017-11-06 08:36:13 UTC
Permalink
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 ***@objektfabrik.de <***@objektfabrik.de> wrote:

Phil,
Post by 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.
Post by p***@highoctane.be
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 ;-)
Post by p***@highoctane.be
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:***@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
Dimitris Chloupis
2017-11-06 10:28:22 UTC
Permalink
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.
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
*Sent: *Monday, November 6, 2017 2:35 AM
*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.
Phil,
Post by 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.
Post by p***@highoctane.be
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 ;-)
Post by p***@highoctane.be
Think about being able to call Pharo from JNA
https://github.com/java-native-access/jna the same way we use C with
UFFI.
Post by p***@highoctane.be
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
--
-----------------------------------------------------------------------
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
Hans N Beck
2017-11-06 11:39:24 UTC
Permalink
Hi Dimitris,

you have pointed out some good thoughts.

However, for me any technical thing can have two aspects:

- solve a problem, provide a product which has value (for get things done)
- take the concepts (of applied technics and computer science forward)

For me, both things are important. Experience from doing gives new impulses for better concepts, better concepts may help to solve unsolvable problems.

I like your example of libraries. Yes, I think too reinventing everything is not necessary. But I believe libraries as „live“ objects providing protocol and capabilities would be an important improvement. For me, Morphic in it’s essence could be great for the AR world to come.

So in principle I agree with you, but I hope that we not stop to search also for better concepts in a world, where privacy and self will is called in the age of big data and AI. Just my personal view 😇

Cheers

Hans
Post by 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.
Post by 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.
Phil,
Post by 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.
Post by p***@highoctane.be
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 ;-)
Post by p***@highoctane.be
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
--
-----------------------------------------------------------------------
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
Andrew Glynn
2017-11-06 11:46:50 UTC
Permalink
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 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 <***@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 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 ***@objektfabrik.de <***@objektfabrik.de> wrote:

Phil,
Post by 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.
Post by p***@highoctane.be
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 ;-)
Post by p***@highoctane.be
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:***@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
 
Paulo R. Dellani
2017-10-26 07:40:15 UTC
Permalink
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.

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, through the
command line and the filesystem - so no need for fancy looking web
apps at the moment, but it surely will not hurt to have this possibilities
- it would be cool to run part of the code at the front end (internet
browser),
in our case, some pre-processing of medical data before it is sent
to the "main processing pipeline" (just one practical example of
many other possible applications). This particular task could be done
with Javascript, but I am afraid that the necessary libraries are not
so good..

Cheers,

Paulo
Post by Andrew Glynn
 
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.
 
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.
 
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’.  An application is by definition
a state-machine, which implies plenty about JS developers on the whole.
 
If you’re a good developer you can write good code in (nearly)
anything.  My question then is why would you want to write in crap?
 The better question is why aren’t there more good developers in /any/
language?
 
Every project I have been able to do in Smalltalk, though, has had one
thing in common, the “shit has to work”.  Companies do use it, in fact
I could name 4 large enterprises I’ve worked for who’ve written their
own dialects, and they all use it only when “shit has to work”.  They
know it’s more productive, they also know using it for more things
would increase the availability of Smalltalk developers. 
 
Why do they not do it?  One reason, though it takes a while to
recognize it, because management doesn’t admit even to themselves why
they do it, or not very often.  Being inefficient, as long as it
doesn’t ‘really’ matter, is an advantage to large enterprises because
they have resources smaller competitors don’t. 
 
Why don’t their competitors do it?  Because they can’t see past an
hourly rate, what’s fashionable, or just new, or because their
customers can’t.  Put more generally, average stupidity that isn’t
corrected by the market.  Fashion affects smaller companies more than
larger ones, because they can’t afford a few customers walking away
because they wanted an app in Electron, even if they can’t give any
relevant reason for wanting it, and even the samples on the Electron
site don’t work. 
 
Enterprises can, and do use Smalltalk when it matters.  When it
doesn’t, it’s to their advantage to promote things that are
inefficient, buggy and unreliable.
 
Cost 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.
 
*Reply-To: *Any question about pharo is welcome
*Date: *Tuesday, October 24, 2017 at 11:52 AM
*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.
 
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&feel, 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         
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                 
http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0
<tel:%2B49%207141%2056%2010%2086%200>         Fax: +49 7141 56 10
86 1 <tel:%2B49%207141%2056%2010%2086%201>
 
Ben Coman
2017-10-27 04:26:22 UTC
Permalink
Post by Paulo R. Dellani
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


* Running Pharo on the GemStone VM



"Develop on Pharo, Deploy on Gemstone" seems to be a growing meme.
Post by Paulo R. Dellani
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
j***@objektfabrik.de
2017-10-26 12:13:16 UTC
Permalink
Andrew,
I am glad you opened your words with this sentence. Other peoples'
mileages may vary a lot.
Post by Andrew Glynn
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.
Post by Andrew Glynn
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
Post by Andrew Glynn
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’.  An application is by definition
a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly)
anything.  My question then is why would you want to write in crap?
 The better question is why aren’t there more good developers in /any/
language?
Every project I have been able to do in Smalltalk, though, has had one
thing in common, the “shit has to work”.  Companies do use it, in fact
I could name 4 large enterprises I’ve worked for who’ve written their
own dialects, and they all use it only when “shit has to work”.  They
know it’s more productive, they also know using it for more things
would increase the availability of Smalltalk developers.
Why do they not do it?  One reason, though it takes a while to
recognize it, because management doesn’t admit even to themselves why
they do it, or not very often. Being inefficient, as long as it
doesn’t ‘really’ matter, is an advantage to large enterprises because
they have resources smaller competitors don’t.
Why don’t their competitors do it?  Because they can’t see past an
hourly rate, what’s fashionable, or just new, or because their
customers can’t.  Put more generally, average stupidity that isn’t
corrected by the market.  Fashion affects smaller companies more than
larger ones, because they can’t afford a few customers walking away
because they wanted an app in Electron, even if they can’t give any
relevant reason for wanting it, and even the samples on the Electron
site don’t work.
Enterprises can, and do use Smalltalk when it matters.  When it
doesn’t, it’s to their advantage to promote things that are
inefficient, buggy and unreliable.
Cost 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.
*Reply-To: *Any question about pharo is welcome
*Date: *Tuesday, October 24, 2017 at 11:52 AM
*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.
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&feel, 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
--
-----------------------------------------------------------------------
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0
<tel:%2B49%207141%2056%2010%2086%200>         Fax: +49 7141 56 10
86 1 <tel:%2B49%207141%2056%2010%2086%201>
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:***@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
Dimitris Chloupis
2017-10-26 12:53:41 UTC
Permalink
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.
Post by j***@objektfabrik.de
Andrew,
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’. An application is by definition a
state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything.
My question then is why would you want to write in crap? The better
question is why aren’t there more good developers in *any* language?
Every project I have been able to do in Smalltalk, though, has had one
thing in common, the “shit has to work”. Companies do use it, in fact I
could name 4 large enterprises I’ve worked for who’ve written their own
dialects, and they all use it only when “shit has to work”. They know it’s
more productive, they also know using it for more things would increase the
availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize
it, because management doesn’t admit even to themselves why they do it, or
not very often. Being inefficient, as long as it doesn’t ‘really’ matter,
is an advantage to large enterprises because they have resources smaller
competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly
rate, what’s fashionable, or just new, or because their customers can’t.
Put more generally, average stupidity that isn’t corrected by the market.
Fashion affects smaller companies more than larger ones, because they can’t
afford a few customers walking away because they wanted an app in Electron,
even if they can’t give any relevant reason for wanting it, and even the
samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t,
it’s to their advantage to promote things that are inefficient, buggy and
unreliable.
Cost 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.
*Reply-To: *Any question about pharo is welcome
*Date: *Tuesday, October 24, 2017 at 11:52 AM
*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.
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&feel, 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
--
-----------------------------------------------------------------------
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 <%2B49%207141%2056%2010%2086%200>
Fax: +49 7141 56 10 86 1 <%2B49%207141%2056%2010%2086%201>
--
-----------------------------------------------------------------------
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
Andrew Glynn
2017-10-28 00:05:40 UTC
Permalink
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 ***@objektfabrik.de <***@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.
Post by Andrew Glynn
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.
 
Post by Andrew Glynn
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’.  An application is by definition a state-machine, which implies plenty about JS developers on the whole.
 
If you’re a good developer you can write good code in (nearly) anything.  My question then is why would you want to write in crap?  The better question is why aren’t there more good developers in any language?
 
Every project I have been able to do in Smalltalk, though, has had one thing in common, the “shit has to work”.  Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when “shit has to work”.  They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers. 
 
Why do they not do it?  One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often.  Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t. 
 
Why don’t their competitors do it?  Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t.  Put more generally, average stupidity that isn’t corrected by the market.  Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work. 
 
Enterprises can, and do use Smalltalk when it matters.  When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
 
Cost 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-***@lists.pharo.org> on behalf of David Mason <***@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-***@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, ***@objektfabrik.de <***@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&feel, 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:***@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
 
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:***@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
Andrew Glynn
2017-10-28 03:09:34 UTC
Permalink
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 ***@objektfabrik.de <***@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.
Post by Andrew Glynn
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.
 
Post by Andrew Glynn
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’.  An application is by definition a state-machine, which implies plenty about JS developers on the whole.
 
If you’re a good developer you can write good code in (nearly) anything.  My question then is why would you want to write in crap?  The better question is why aren’t there more good developers in any language?
 
Every project I have been able to do in Smalltalk, though, has had one thing in common, the “shit has to work”.  Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when “shit has to work”.  They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers. 
 
Why do they not do it?  One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often.  Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t. 
 
Why don’t their competitors do it?  Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t.  Put more generally, average stupidity that isn’t corrected by the market.  Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work. 
 
Enterprises can, and do use Smalltalk when it matters.  When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
 
Cost 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-***@lists.pharo.org> on behalf of David Mason <***@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-***@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, ***@objektfabrik.de <***@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&feel, 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:***@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
 
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:***@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
Dimitris Chloupis
2017-10-28 08:53:55 UTC
Permalink
Post by 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.
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
branch of desktop development known as "mobile development") that has
brought more sanity and uniformity into the development process.

Unfortunately companies still play a very big role in the glacial evolution
of the web that is fortunately dimisihing with the emergence of free
software.
Offray Vladimir Luna Cárdenas
2017-10-29 18:00:33 UTC
Permalink
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.
Post by Dimitris Chloupis
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, seems
a way to deploy the Smalltalk Argument by example into the world, which
is a pretty powerful way to argument against skeptics.

Cheers,

Offray
henry
2017-10-29 18:13:14 UTC
Permalink
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
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, seems a way to deploy the Smalltalk Argument by example into the world, which is a pretty powerful way to argument against skeptics. Cheers, Offray
Offray Vladimir Luna Cárdenas
2017-10-29 20:59:30 UTC
Permalink
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
Post by 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
Post by 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, seems a way to deploy
the Smalltalk Argument by example into the world, which is a pretty
powerful way to argument against skeptics. Cheers, Offray
henry
2017-10-29 22:00:38 UTC
Permalink
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
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
Post by 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
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 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/]("http://hackbo.co/") [3] [http://mutabit.com/dataweek/]("http://mutabit.com/dataweek/") So finding a niche and bootstrapping tools and communities in it, seems a way to deploy the Smalltalk Argument by example into the world, which is a pretty powerful way to argument against skeptics. Cheers, Offray
Offray Vladimir Luna Cárdenas
2017-10-29 22:06:38 UTC
Permalink
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
Post by 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
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
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 <
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, seems a way to
deploy the Smalltalk Argument by example into the world,
which is a pretty powerful way to argument against
skeptics. Cheers, Offray
p***@highoctane.be
2017-10-29 21:17:04 UTC
Permalink
Pharo can read Avro when this will be UFFI'ed

https://avro.apache.org/docs/1.7.3/api/c/index.html

But that is eminently doable.

Phiil
Post by 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 <
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, seems a way to deploy the Smalltalk Argument by
example into the world, which is a pretty powerful way to argument against
skeptics. Cheers, Offray
henry
2017-10-29 22:01:19 UTC
Permalink
Interesting. Very.

Thank you.

- HH
Post by p***@highoctane.be
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
Post by 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
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 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/]("http://hackbo.co/") [3] [http://mutabit.com/dataweek/]("http://mutabit.com/dataweek/")So finding a niche and bootstrapping tools and communities in it, seems a way to deploy the Smalltalk Argument by example into the world, which is a pretty powerful way to argument against skeptics. Cheers, Offray
Andrew Glynn
2017-10-27 19:47:57 UTC
Permalink
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: ***@objektfabrik.de
Sent: Thursday, October 26, 2017 8:14 AM
To: pharo-***@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.
Post by Andrew Glynn
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.
 
Post by Andrew Glynn
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’.  An application is by definition a state-machine, which implies plenty about JS developers on the whole.
 
If you’re a good developer you can write good code in (nearly) anything.  My question then is why would you want to write in crap?  The better question is why aren’t there more good developers in any language?
 
Every project I have been able to do in Smalltalk, though, has had one thing in common, the “shit has to work”.  Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when “shit has to work”.  They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers. 
 
Why do they not do it?  One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often.  Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t. 
 
Why don’t their competitors do it?  Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t.  Put more generally, average stupidity that isn’t corrected by the market.  Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work. 
 
Enterprises can, and do use Smalltalk when it matters.  When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
 
Cost 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-***@lists.pharo.org> on behalf of David Mason <***@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-***@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, ***@objektfabrik.de <***@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&feel, 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:***@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


 
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:***@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
henry
2017-10-27 20:41:53 UTC
Permalink
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
Post by Andrew Glynn
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
Sent: Thursday, October 26, 2017 8:14 AM
Subject: Re: [Pharo-users] Smalltalk Argument
Andrew,
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work". They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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.
Post by Andrew Glynn
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&feel, 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
--
-----------------------------------------------------------------------
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: [+49 7141 56 10 86 0](tel:%2B49%207141%2056%2010%2086%200) Fax: [+49 7141 56 10 86 1](tel:%2B49%207141%2056%2010%2086%201)
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel
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
henry
2017-10-27 20:51:01 UTC
Permalink
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
Post by 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
Post by Andrew Glynn
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
Sent: Thursday, October 26, 2017 8:14 AM
Subject: Re: [Pharo-users] Smalltalk Argument
Andrew,
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work". They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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]("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.
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&feel, 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
—
————————————————————————
Fliederweg 1 [http://www.objektfabrik.de]("http://www.objektfabrik.de")
D-71640 Ludwigsburg [http://joachimtuchel.wordpress.com]("http://joachimtuchel.wordpress.com")
Telefon: [+49 7141 56 10 86 0]("tel:%2B49%207141%2056%2010%2086%200") Fax: [+49 7141 56 10 86 1]("tel:%2B49%207141%2056%2010%2086%201")
—
————————————————————————
Objektfabrik Joachim Tuchel
Fliederweg 1
[http://www.objektfabrik.de]("http://www.objektfabrik.de")
D-71640 Ludwigsburg
[http://joachimtuchel.wordpress.com]("http://joachimtuchel.wordpress.com")
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
henry
2017-10-27 21:02:27 UTC
Permalink
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
Post by 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
Post by 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
Post by Andrew Glynn
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
Sent: Thursday, October 26, 2017 8:14 AM
Subject: Re: [Pharo-users] Smalltalk Argument
Andrew,
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work". They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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](""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.
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&feel, 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
—
————————————————————————
Fliederweg 1 [http://www.objektfabrik.de](""http://www.objektfabrik.de"")
D-71640 Ludwigsburg [http://joachimtuchel.wordpress.com](""http://joachimtuchel.wordpress.com"")
Telefon: [+49 7141 56 10 86 0](""tel:%2B49%207141%2056%2010%2086%200"") Fax: [+49 7141 56 10 86 1](""tel:%2B49%207141%2056%2010%2086%201"")
—
————————————————————————
Objektfabrik Joachim Tuchel
Fliederweg 1
[http://www.objektfabrik.de](""http://www.objektfabrik.de"")
D-71640 Ludwigsburg
[http://joachimtuchel.wordpress.com](""http://joachimtuchel.wordpress.com"")
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Andrew Glynn
2017-10-28 03:09:52 UTC
Permalink
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 <***@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 <***@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 <***@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: ***@objektfabrik.de
Sent: Thursday, October 26, 2017 8:14 AM
To: pharo-***@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.
Post by Andrew Glynn
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.
 
Post by Andrew Glynn
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’.  An application is by definition a state-machine, which implies plenty about JS developers on the whole.
 
If you’re a good developer you can write good code in (nearly) anything.  My question then is why would you want to write in crap?  The better question is why aren’t there more good developers in any language?
 
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work".  Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work".  They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers. 
 
Why do they not do it?  One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often.  Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t. 
 
Why don’t their competitors do it?  Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t.  Put more generally, average stupidity that isn’t corrected by the market.  Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work. 
 
Enterprises can, and do use Smalltalk when it matters.  When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
 
Cost 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-***@lists.pharo.org> on behalf of David Mason <***@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-***@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, ***@objektfabrik.de <***@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&feel, 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:***@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

 
 
—
————————————————————————
Objektfabrik Joachim Tuchel          mailto:***@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
 
 
Andrew Glynn
2017-10-28 03:10:00 UTC
Permalink
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 <***@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 <***@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 <***@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: ***@objektfabrik.de
Sent: Thursday, October 26, 2017 8:14 AM
To: pharo-***@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.
Post by Andrew Glynn
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.
 
Post by Andrew Glynn
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’.  An application is by definition a state-machine, which implies plenty about JS developers on the whole.
 
If you’re a good developer you can write good code in (nearly) anything.  My question then is why would you want to write in crap?  The better question is why aren’t there more good developers in any language?
 
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work".  Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work".  They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers. 
 
Why do they not do it?  One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often.  Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t. 
 
Why don’t their competitors do it?  Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t.  Put more generally, average stupidity that isn’t corrected by the market.  Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work. 
 
Enterprises can, and do use Smalltalk when it matters.  When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
 
Cost 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-***@lists.pharo.org> on behalf of David Mason <***@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-***@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, ***@objektfabrik.de <***@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&feel, 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:***@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

 
 
—
————————————————————————
Objektfabrik Joachim Tuchel          mailto:***@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
 
 
Andrew Glynn
2017-10-28 03:10:16 UTC
Permalink
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 <***@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 <***@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 <***@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: ***@objektfabrik.de
Sent: Thursday, October 26, 2017 8:14 AM
To: pharo-***@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.
Post by Andrew Glynn
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.
 
Post by Andrew Glynn
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’.  An application is by definition a state-machine, which implies plenty about JS developers on the whole.
 
If you’re a good developer you can write good code in (nearly) anything.  My question then is why would you want to write in crap?  The better question is why aren’t there more good developers in any language?
 
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work".  Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work".  They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers. 
 
Why do they not do it?  One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often.  Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t. 
 
Why don’t their competitors do it?  Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t.  Put more generally, average stupidity that isn’t corrected by the market.  Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work. 
 
Enterprises can, and do use Smalltalk when it matters.  When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
 
Cost 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-***@lists.pharo.org> on behalf of David Mason <***@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-***@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, ***@objektfabrik.de <***@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&feel, 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:***@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

 
 
—
————————————————————————
Objektfabrik Joachim Tuchel          mailto:***@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
 
 
henry
2017-10-28 14:05:13 UTC
Permalink
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
The Kafka integration is right in the Pharo catalog.
Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10
Sent: Friday, October 27, 2017 5:03 PM
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
Post by 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
Post by 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
Post by Andrew Glynn
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
Sent: Thursday, October 26, 2017 8:14 AM
Subject: Re: [Pharo-users] Smalltalk Argument
Andrew,
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work". They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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](%22http:/pharojs.org%22)
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.
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&feel, 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
—
————————————————————————
Fliederweg 1 [http://www.objektfabrik.de](%22http:/www.objektfabrik.de%22)
D-71640 Ludwigsburg [http://joachimtuchel.wordpress.com](%22http:/joachimtuchel.wordpress.com%22)
Telefon: [+49 7141 56 10 86 0](%22tel:%2B49%207141%2056%2010%2086%200%22) Fax: [+49 7141 56 10 86 1](%22tel:%2B49%207141%2056%2010%2086%201%22)
—
————————————————————————
Objektfabrik Joachim Tuchel
Fliederweg 1
[http://www.objektfabrik.de](%22http:/www.objektfabrik.de%22)
D-71640 Ludwigsburg
[http://joachimtuchel.wordpress.com](%22http:/joachimtuchel.wordpress.com%22)
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Andrew Glynn
2017-10-28 03:10:23 UTC
Permalink
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 <***@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 <***@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 <***@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: ***@objektfabrik.de
Sent: Thursday, October 26, 2017 8:14 AM
To: pharo-***@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.
Post by Andrew Glynn
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.
 
Post by Andrew Glynn
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’.  An application is by definition a state-machine, which implies plenty about JS developers on the whole.
 
If you’re a good developer you can write good code in (nearly) anything.  My question then is why would you want to write in crap?  The better question is why aren’t there more good developers in any language?
 
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work".  Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work".  They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers. 
 
Why do they not do it?  One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often.  Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t. 
 
Why don’t their competitors do it?  Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t.  Put more generally, average stupidity that isn’t corrected by the market.  Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work. 
 
Enterprises can, and do use Smalltalk when it matters.  When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
 
Cost 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-***@lists.pharo.org> on behalf of David Mason <***@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-***@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, ***@objektfabrik.de <***@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&feel, 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:***@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

 
 
—
————————————————————————
Objektfabrik Joachim Tuchel          mailto:***@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
 
 
Andrew Glynn
2017-10-28 03:10:08 UTC
Permalink
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 <***@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 <***@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 <***@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: ***@objektfabrik.de
Sent: Thursday, October 26, 2017 8:14 AM
To: pharo-***@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.
Post by Andrew Glynn
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.
 
Post by Andrew Glynn
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’.  An application is by definition a state-machine, which implies plenty about JS developers on the whole.
 
If you’re a good developer you can write good code in (nearly) anything.  My question then is why would you want to write in crap?  The better question is why aren’t there more good developers in any language?
 
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work".  Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work".  They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers. 
 
Why do they not do it?  One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often.  Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t. 
 
Why don’t their competitors do it?  Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t.  Put more generally, average stupidity that isn’t corrected by the market.  Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work. 
 
Enterprises can, and do use Smalltalk when it matters.  When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
 
Cost 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-***@lists.pharo.org> on behalf of David Mason <***@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-***@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, ***@objektfabrik.de <***@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&feel, 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:***@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

 
 
—
————————————————————————
Objektfabrik Joachim Tuchel          mailto:***@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
 
 
Andrew Glynn
2017-10-28 03:10:31 UTC
Permalink
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 <***@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 <***@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 <***@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: ***@objektfabrik.de
Sent: Thursday, October 26, 2017 8:14 AM
To: pharo-***@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.
Post by Andrew Glynn
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.
 
Post by Andrew Glynn
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’.  An application is by definition a state-machine, which implies plenty about JS developers on the whole.
 
If you’re a good developer you can write good code in (nearly) anything.  My question then is why would you want to write in crap?  The better question is why aren’t there more good developers in any language?
 
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work".  Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work".  They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers. 
 
Why do they not do it?  One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often.  Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t. 
 
Why don’t their competitors do it?  Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t.  Put more generally, average stupidity that isn’t corrected by the market.  Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work. 
 
Enterprises can, and do use Smalltalk when it matters.  When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
 
Cost 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-***@lists.pharo.org> on behalf of David Mason <***@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-***@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, ***@objektfabrik.de <***@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&feel, 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:***@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

 
 
—
————————————————————————
Objektfabrik Joachim Tuchel          mailto:***@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
 
 
henry
2017-10-28 14:08:13 UTC
Permalink
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
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
Sent: Friday, October 27, 2017 5:03 PM
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
Post by 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
Post by 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
Post by Andrew Glynn
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
Sent: Thursday, October 26, 2017 8:14 AM
Subject: Re: [Pharo-users] Smalltalk Argument
Andrew,
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’. An application is by definition a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why aren’t there more good developers in any language?
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work". They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t. Put more generally, average stupidity that isn’t corrected by the market. Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
Cost 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.
Date: Tuesday, October 24, 2017 at 11:52 AM
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](%22http:/pharojs.org%22)
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.
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&feel, 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
—
————————————————————————
Fliederweg 1 [http://www.objektfabrik.de](%22http:/www.objektfabrik.de%22)
D-71640 Ludwigsburg [http://joachimtuchel.wordpress.com](%22http:/joachimtuchel.wordpress.com%22)
Telefon: [+49 7141 56 10 86 0](%22tel:%2B49%207141%2056%2010%2086%200%22) Fax: [+49 7141 56 10 86 1](%22tel:%2B49%207141%2056%2010%2086%201%22)
—
————————————————————————
Objektfabrik Joachim Tuchel
Fliederweg 1
[http://www.objektfabrik.de](%22http:/www.objektfabrik.de%22)
D-71640 Ludwigsburg
[http://joachimtuchel.wordpress.com](%22http:/joachimtuchel.wordpress.com%22)
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Andrew Glynn
2017-10-28 03:10:39 UTC
Permalink
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 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 <***@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 <***@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 <***@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: ***@objektfabrik.de
Sent: Thursday, October 26, 2017 8:14 AM
To: pharo-***@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.
Post by Andrew Glynn
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.
 
Post by Andrew Glynn
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’.  An application is by definition a state-machine, which implies plenty about JS developers on the whole.
 
If you’re a good developer you can write good code in (nearly) anything.  My question then is why would you want to write in crap?  The better question is why aren’t there more good developers in any language?
 
Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work".  Companies do use it, in fact I could name 4 large enterprises I’ve worked for who’ve written their own dialects, and they all use it only when "shit has to work".  They know it’s more productive, they also know using it for more things would increase the availability of Smalltalk developers. 
 
Why do they not do it?  One reason, though it takes a while to recognize it, because management doesn’t admit even to themselves why they do it, or not very often.  Being inefficient, as long as it doesn’t ‘really’ matter, is an advantage to large enterprises because they have resources smaller competitors don’t. 
 
Why don’t their competitors do it?  Because they can’t see past an hourly rate, what’s fashionable, or just new, or because their customers can’t.  Put more generally, average stupidity that isn’t corrected by the market.  Fashion affects smaller companies more than larger ones, because they can’t afford a few customers walking away because they wanted an app in Electron, even if they can’t give any relevant reason for wanting it, and even the samples on the Electron site don’t work. 
 
Enterprises can, and do use Smalltalk when it matters.  When it doesn’t, it’s to their advantage to promote things that are inefficient, buggy and unreliable.
 
Cost 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-***@lists.pharo.org> on behalf of David Mason <***@ryerson.ca>
Reply-To: Any question about pharo is welcome <pharo-***@lists.pharo.org>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-***@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, ***@objektfabrik.de <***@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&feel, 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:***@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

 
 
—
————————————————————————
Objektfabrik Joachim Tuchel          mailto:***@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
 
 
henry
2017-10-28 14:09:07 UTC
Permalink
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
Last point. Blocks are already better lambdas than lambdas in Java.
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
Sent: Friday, October 27, 2017 5:03 PM
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
Post by 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
Post by 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
Post by Andrew Glynn
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
Sent: Thursday, October 26, 2017 8:14 AM
Subject: Re: [Pharo-users] Smalltalk Argument
Andrew,
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. H