InfoWorld on Redline Smalltalk

continued from pharo-dev, please keep discussion here.

The smalltalk on jvm situation is exactly like it shouldn't be.
There are three implementations, not working together:
- RTalk
- Gravel
- Redline

The first two are driven by existing commercial smalltalk users
coming from a platform that they feel is not sufficiently
developing (different ones).  This amount of fragmentation is ridiculous.
Of course they have different priorities and needs, but it should be
possible to share the work that all three feel they have to do.
The result is that at least two of them move forward very slowly.

Stephan

I had never heard of RTalk or Gravel. In all my Googling, I've never come across these two. They're obviously not on the minds of very many people. Are they even active projects?

At least Redline is relatively prominent. At least James Ladd is actively working on it. His efforts should be commended and supported.

Let's rally around the Redline project. This should be doable.

Generalissimo

Stephan Eggermont wrote

continued from pharo-dev, please keep discussion here.

The smalltalk on jvm situation is exactly like it shouldn't be.
There are three implementations, not working together:
- RTalk
- Gravel
- Redline

The first two are driven by existing commercial smalltalk users
coming from a platform that they feel is not sufficiently
developing (different ones).  This amount of fragmentation is ridiculous.
Of course they have different priorities and needs, but it should be
possible to share the work that all three feel they have to do.
The result is that at least two of them move forward very slowly.

Stephan

kilon.alios wrote

Porting code to JVM and Javascript has 3 issues

a) you are no longer able to use the libraries of your popular
implementation (see Pharo) unless you wrap those libraries with something
like JNA (a ffi for JAVA)
b) most people would not use JVM unless if they have to and in most cases
it will be more likely their code will be written in JAVA so they use JAVA
c) JVM and Javascript languages are notorious for being slow , so once
again fall back to JAVA and Javascript

Indeed, many organizations have to use JVM, and yes, they probably fall back on Java because that's the "safe" choice. It doesn't mean that we can't persuade them to try Smalltalk. Redline makes it easier to interoperate with the existing Java infrastructure.

If we can't convince these organizations that they'll be much more productive using Smalltalk over Java, and save tons of money in the long run, then how can we ever advance our agenda to the rest of the world??

BTW, JVM and JS aren't that slow any more. They're so well-optimized that, for most use cases, performance is no longer an issue. I know because my brother Robert used to work at IBM (he just quit yesterday!).

So those language ported to JVM act mainly as scripting languages, you got
a JAVA app which is probably quite big and you port small parts of it to
that other language to make your code more managable and less verbose.

So Scala, Groovy, and Clojure are used mainly as scripting languages? That's not what I hear.

So overall I doubt that Smalltalk will ever be a big hit on JVM or
Javascript. The problem with smalltalk that other languages dont have is
that it comes with an IDE , which is both a blessing and a curse. The last
time I checked Pharo was 200k lines of codes, that is huge for a dynamic
language. If we take out the IDE we lose a big advantage as developers, add
to that the fact that other IDEs have very limited supported for Smalltalk
and you end up as a not so cool situation especially if you are used to
code in Pharo. This is something I have against with Amber.

I don't expect Smalltalk to become a big hit on the JVM or JS, either. But if it proves to be as popular as Scala, I'd be very satisfied!

Making Smalltalk available to other domains is not simply a matter of checking off boxes. Strategically, it shows Smalltalk's versatility and that it's not just a one-trick pony. Limiting ourselves to just desktop (or Seaside) applications is rather short-sighted.

So the ideal scenario is for someone to do what Rtalk promised but that
would requires someone or some coder with very deep knowledge of the JVM,
So dont hold your breath.

I won't, which is precisely why I support James Ladd's efforts.

My choice is sticking with Pharo, sure Javascript and Java are nice sirens
singing an irresistible song but I am not willing to give up the comforts
of Pharo just so I have access to Java and Javascript libraries. Tempting
but not that tempting.  Pharo is an excellent choice if you are a lone
coder and you want to be very productive which if you think of it is
completely diffirent to what the JVM aims for which is big coder groups and
big companies.

I certainly don't want to limit Smalltalk to just lone developers and small software houses. That's the very definition of "niche."

On the other hand if there is a real need for Smalltalk on JVM then sooner
or later someone will step up and start something. Right now from what I
see Clojure and Scala are the only two langauge that get some attention ,
again nowhere near as much as other popular languages but they still
somewhat popular. The thing with Clojure is that is not just lisp on JVM ,
there was already lisp for JVM called ABCL and never got popular, Clojure
became popular not because its lisp but because it targeted concurrency and
made it easier . If Smalltalk is to become ever as popular it has to bring
something similar to the table and I think concurency would not be a bad
idea either especially for those that are not big fans of lisp syntax and
prefer something like Smalltalk.

As I intimated previously in my list of essay topics for the Smalltalk community, I believe it's important for us to address concurrency in Smalltalk. Yes, it would not only be a good idea, it would be essential.

I think there's a real need for Smalltalk on JVM, and Mr. Ladd has indeed stepped up. The real question is, who among you will help him?

Generalissimo

Thanks for this link! I always thought there was something not right about Angular, and this article (and its links) clearly lay out the issue.

Obviously, I think Amber is a better solution.

The one big takeaway from these anti-Angular articles, I think, is this...

IT management often make stupid choices based on fad, fashion, and laziness. They can't be bothered to do the actual research and investigation to see which technology best fits their goals and objectives. Presumably, one of their chief objectives is to improve productivity and save on (labour) costs. How can you meet this objective without at least trying one of the premier productivity technologies on the market, namely, Smalltalk? How can you not have heard the oft-repeated claims about Smalltalk's superlative productivity over the years? They've only been made year after year since the 1980s.

All that is required is to run a pilot Smalltalk program. This will definitively answer the question: How much more productive can you be in developing software?

Generalissimo

sebastian@flowingconcept.com wrote

> On Jan 17, 2015, at 3:18 PM, kilon alios <[hidden email]> wrote:
>
> So overall I doubt that Smalltalk will ever be a big hit on JVM or Javascript.

Everybody is a looser if you frame it in that perspective.

That game is not interesting, nor strategy wise.

An interesting alternative is to create the opportunity for people to take their bite on the Java market and if they can do it, as small as it might be that’s all that really counts.

James is already one of those someone will make it when the demand is felt.

If Redline Smalltalk saves significant costs to a company that has invested heavy in something JVM-ish then you will have their attention.

Productivity is one of the strongest opportunities for Smalltalk unless our tools UI/UX sucks so bad it get deteriorated or the world catches up.

And we have control over the UI/UX we provide.

Have you ever thought that AngularJS is essentially a Google strategy to bite Java’s market <http://www.quirksmode.org/blog/archives/2015/01/the_problem_wit.html>?

Hi horrido,

I do not agree with most of yours arguments.
Here is what I picked :

...
"Indeed, many organizations have to use JVM, and yes, they probably
fall back
  on Java because that's the "safe" choice."

Most CEO or IT managers think like that, but this is a false marketing
argument mostly sustained by the fact that the software is good enough
for the majority.
The Java license explicitly states that there is no warranty of
whatever. I remember in the past it was forbidden to use it for nuclear
systems, I don't know if this is still the case ;) .
The same as for several mainstream technologies, and big software vendors.
And when you are beaten by a bug (very rare yes, but it happens), it is
sometimes very hard to deal with it.
Being able to understand and master the system is a key advantage.
By  dropping the vm you will depend on other and loose this advantage.
And I saw several systems choosen only on those criterias be very poor
choices for their users.
...

"If we can't convince these organizations that they'll be much more
productive using Smalltalk over Java, and save tons of money /in the long
run/, then how can we ever advance our agenda to the rest of the world??"

I do not see productivity as very important. It is just an (eventually)
good feature.
Productivity, and cost are the most flawed indicators in software
development and this is the argument I hate the most (I may be a bit
rude about that because I have to maintain some old legacy code and  we
had quite some bugs last years).
Costs in the middle and long run are clearly related to code quality and
to bugs, not to productivity.
And sometimes, the cost of bugs is terrible when you think about how
many people are involved in the chain and what has to be done to solve
customer problems and revert the results of bugs. .. Awful.
For example, about the cost of null  ... "I did it, just because it was
so easy"
http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare


"Strategically, it shows Smalltalk's versatility and that
it's not just a one-trick pony. Limiting ourselves to just desktop (or
Seaside) applications is rather short-sighted."


I do not understand how Smalltalk will be more versatile  by using a jvm
?  doing like others ?

IMHO innovation is related to change, this implies not following the
main path somewhere,
and some risks too.
A very good example here about wheels :)
http://blogs.ubc.ca/etec540sept12/2012/09/16/inventing-the-wheel/


Going on this way, one could ask why not use cloudstack or openstack and
plain java for server side , with an hypervisor-ready jvm (kenai?) ,
plain javascript for the client side and forget about the system.
It will be open to widespread frameworks library and tools, but at what
cost ? That will be safer, but would it still be interesting ?
Would you have fun using it ?


To end, I found your question a good revealer about  one's expectations
about pharo, very interesting :).



--
Regards,

Alain

Le 18/01/2015 10:49, Alain Rastoul a écrit :
> Costs in the middle and long run are clearly related to code quality and
> to bugs, not to productivity.
And of course, I should have said design first

--
Regards,

Alain

Hello people

do you realize that you are poluting the ****PHARO**** users mailing-list?
What is the message we sent to users that are happily hacking in Pharo.
The user mailing-list not an open bar to talk about any topics.

We will create a Pharo-chat mailing-list.
And all these discussions should be moved there.

Stef


Le 18/1/15 01:00, horrido a écrit :

+1 on all of this,



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile

Let us know when Pharo-chat is ready. I'll move everything there.

Thanks.

stepharo wrote

Hello people

do you realize that you are poluting the ****PHARO**** users mailing-list?
What is the message we sent to users that are happily hacking in Pharo.
The user mailing-list not an open bar to talk about any topics.

We will create a Pharo-chat mailing-list.
And all these discussions should be moved there.

Stef


Le 18/1/15 01:00, horrido a écrit :
> Thanks for this link! I always thought there was something not right about
> Angular, and this article (and its links) clearly lay out the issue.
>
> Obviously, I think Amber is a better solution.
>
> The one big takeaway from these anti-Angular articles, I think, is this...
>
> /IT management often make stupid choices based on fad, fashion, and
> laziness./ They can't be bothered to do the actual research and
> investigation to see which technology best fits their goals and objectives.
> Presumably, one of their chief objectives is to improve productivity and
> save on (labour) costs. How can you meet this objective without at least
> trying one of the premier productivity technologies on the market, namely,
> Smalltalk? How can you not have heard the oft-repeated claims about
> Smalltalk's superlative productivity over the years? They've only been made
> year after year since the 1980s.
>
> All that is required is to run a pilot Smalltalk program. This will
> definitively answer the question: How much more productive can you be in
> developing software?
>
> Generalissimo
>
>
> [hidden email] wrote
>>> On Jan 17, 2015, at 3:18 PM, kilon alios <
>> kilon.alios@
>> > wrote:
>>> So overall I doubt that Smalltalk will ever be a big hit on JVM or
>>> Javascript.
>> Everybody is a looser if you frame it in that perspective.
>>
>> That game is not interesting, nor strategy wise.
>>
>> An interesting alternative is to create the opportunity for people to take
>> their bite on the Java market and if they can do it, as small as it might
>> be that’s all that really counts.
>>
>> James is already one of those someone will make it when the demand is
>> felt.
>>
>> If Redline Smalltalk saves significant costs to a company that has
>> invested heavy in something JVM-ish then you will have their attention.
>>
>> Productivity is one of the strongest opportunities for Smalltalk unless
>> our tools UI/UX sucks so bad it get deteriorated or the world catches up.
>>
>> And we have control over the UI/UX we provide.
>>
>> Have you ever thought that AngularJS is essentially a Google strategy to
>> bite Java’s market
>> <http://www.quirksmode.org/blog/archives/2015/01/the_problem_wit.html>?
>
>
>
>
> --
> View this message in context: http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799678p4800193.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>
>

Alain Rastoul-2 wrote

"If we can't convince these organizations that they'll be much more
productive using Smalltalk over Java, and save tons of money /in the long
run/, then how can we ever advance our agenda to the rest of the world??"

I do not see productivity as very important. It is just an (eventually)
good feature.
Productivity, and cost are the most flawed indicators in software
development and this is the argument I hate the most (I may be a bit
rude about that because I have to maintain some old legacy code and  we
had quite some bugs last years).
Costs in the middle and long run are clearly related to code quality and
to bugs, not to productivity.
And sometimes, the cost of bugs is terrible when you think about how
many people are involved in the chain and what has to be done to solve
customer problems and revert the results of bugs. .. Awful.

It's true, the long-term costs of maintenance generally outweigh the initial cost of development. But this is true regardless of which language you use. It does not imply that companies do not care to write their applications quickly and economically.

Smalltalk may offer benefits during maintenance and bug-fixing, too. But that's a lot harder to quantify and therefore harder to sell. It's much easier to make – and demonstrate! – the productivity argument.

"Strategically, it shows Smalltalk's versatility and that
it's not just a one-trick pony. Limiting ourselves to just desktop (or
Seaside) applications is rather short-sighted."

I do not understand how Smalltalk will be more versatile  by using a jvm
?  doing like others ?

IMHO innovation is related to change, this implies not following the
main path somewhere,
and some risks too.

By versatile, I mean that Smalltalk usage is applicable in many other domains, including JVM, .NET, mobile, etc.

I'm all for innovation, but we cannot ignore current needs. For better or worse, the JVM is the de facto enterprise standard platform. If we can't play in their space, then that just looks bad. After all, Java is our biggest competitor.

To end, I found your question a good revealer about  one's expectations
about pharo, very interesting :).



--
Regards,

Alain