Actually I think James is on to something and we should try and support him.
Having recently played with AWS Lambda and written a few Alexa services in JS, I was intrigued how you would approach such end points in Smalltalk and whether it would be a productive language and environment to run them in. (Btw - the lambda environment is very interesting - scalable infrastructure that is peanuts to run).
To try this, the basic building blocks provided by these services are either JS or Java - so for Smalltalkers that sounds like Smalltalk running on Amber or Redline.
I find Amber and all the JS infrastructure very daunting - gulp, amd etc. And for Lambda you also get caught into this world of package management and loading up JS dependencies.
I'm intrigued how a jvm Smalltalk might approach this problem (as well as many others I'm sure). We seem to achieve a lot with quite a small image of building blocks.
As pharo is a research community, can we help James explore this a bit more? Certainly there is a drive to a minimal Smalltalk image - so that work can immediately feed into this.
To add to the research'y side context - these service infrastructures seem to feel a lot like callable blocks of code. We are used to thinking in this way in our image - we use blocks everywhere. How might they run in a scaleable environment vs straight function call languages?
Tim
Sent from my iPhone
I think what most people would want is to use Java libraries from inside Pharo. You seem to want to bring Pharo classes to Redline Runtime .
I have the opposite idea of bringing Redline Runtime inside Pharo and give us Pharo developers an easy way to use Java libraries and mix pharo with java code. I think also Pharo would serve great as an IDE for Redline Smalltalk.
I already have JNIPort thats does that but none will complain to have another tool around, I am sure it will come very handy.