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 -- View this message in context: http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799678p4800179.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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 <

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.

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-Mistak... "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

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

-- View this message in context: http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799678p4800277.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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

sebastian@

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.

-- View this message in context: http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799678p4800233.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.