Anybody using Orca Smalltalk to JavaScript?

---------- Forwarded message ----------
From: Robert Hirschfeld <[hidden email]>
Date: Mon, 14 Aug 2017 12:06:45 +0200
Subject: Re: [squeak-dev] [Pharo-dev] Anybody using Orca Smalltalk to
JavaScript?
To: The general-purpose Squeak developers list
<[hidden email]>

http://www.hpi.uni-potsdam.de/swa/publications/media/ThamsenGulenkoPerscheidKrahnHirschfeldThomas_2012_OrcaASingleLanguageWebFrameworkForCollaborativeDevelopment_IEEE.pdf

Hi Frank--

     I'm working on a different project called Caffeine[1]. It runs
Pharo, Squeak, and Cuis object memories in web browsers, using the
SqueakJS virtual machine. There is support for the Chrome Debugging
Protocol, the A-Frame WebVR framework, and the Snowglobe remote UI
framework (e.g., run Pharo in the cloud and interact with it live in a
web browser), and for peer-to-peer communication and NodeJS server
livecoding.

     The target is large-scale web deployments. The project is currently
in alpha.


     thanks,

-C

[1] https://caffeine.js.org

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
[hidden email]
voice through 2017-09-12:
+ 1 510 833 5799 (SMS ok)
+31  20 893 2796 (no SMS)

>
>      Oh, I'm plenty comfortable discussing it on the Pharo lists. :)  I
> was referring to different context in which someone asked me a question
> here, and I got attacked for responding to it.

I surprised about it.
Because we are welcoming discussions. Now discussions around Pharo are better :)

Stef

Hello Craig,

this approach just as Bert's VM in the browser is/are certainly technically very interesting projects and now comes the big "BUT":

- I see absolutely no sense in this approach for real-world end-user applications
- especially if their sources MUST be closely connected with existing Smalltalk code, which does not run in the client like all the data-driven model definitions etc that I already have
- the Morph UI is out of any question related to what end-users expect (pardon, but end-users would regard this as a bad joke)
- the esponsivness of such a solution in the browser must always be far slower than any "normal" browser UI
- and it's impossible to port my >10.000 framwork and application classes to Squeak.

There are several more reasons, why this would conflict with my future plans, which I do not want to disclose here.

So, I see only academic reasons for this work.

I do thank you for your answer. Should my view be copletely wrong, please let me know.

Best regards
Frank

Hi Frank--

> I see absolutely no sense in this approach for real-world end-user
> applications...

     Smalltalk in a web browser (or NodeJS) makes just as much sense as
any other JS framework, like React, Angular, etc. BitBLT, Morphic, and
even the Smalltalk process scheduler are all entirely optional; since
there is full JavaScript connectivity, one can manipulate the DOM (or
shadow DOM) just like any other framework, using JS functions and
promises (and Smalltalk objects which can stand in for those things).

> ...especially if their sources MUST be closely connected with existing
> Smalltalk code, which does not run in the client like all the
> data-driven model definitions etc that I already have

     There is no such requirement.

> the Morph UI is out of any question related to what end-users expect
> (pardon, but end-users would regard this as a bad joke)

     One need not use Morphic. One can use any JS code one likes.

> the responsivness of such a solution in the browser must always be far
> slower than any "normal" browser UI

     That's not true. For example, at the moment my UI is Mozilla's
A-Frame 3D virtual reality framework, at 90 frames per second.

> and it's impossible to port my >10.000 framwork and application
> classes to Squeak.

     Caffeine can use Pharo, Squeak, or Cuis.

> Should my view be completely wrong, please let me know.

     It actually is. :)

     Best of luck with your project!


-C

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
[hidden email]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

@about this forum at world.st

I have a lot of forum experience from studying "forum psychology and sociology" in three different language and in various forums run by very different software but I have never come about any system that is nearly as crappy, sick and idiotic as this one here:

- various message don't show up here
- masses of emails that I am not interested in are polluting my email client (and I will stop this silly downloading tonight by directing them straight into the delete folder)
- and one is never informed if there is any reply to one's posting, which is standard on almost all forums and comment part of blogs
- and there is no chance to directly reply to some post
- thus there is no branching of the subjects
- which makes following a sib-thread most difficult

I am neither going to write answers in my email clent, not will I continue to pollute my system with 99% unwanted messages.

I just ask myself: Why are Smalltalk people with the "best" IDE of all using such a crappy system!?

Mailing lists are something - in my view - soooo much outdated and just a pain in the....!

Now: Hunt me, shout at me, call me whatever you want! That's fine by me. It would be the normal reaction of a crowd if a new sheep dares to criticise what the crowd has been doing for long. I don't care!

Regards
Frank

Hello Craig,

your answer to my posting to you does not show up here and I only accidentally detected it in the flood of  unwanted messages that came is. See my frustration posting above.

I accidentally saw just your reply come in. This is why I am answering here to the most important points. I hope you receive this answer.

I wrote:

...especially if their sources MUST be closely connected with existing
 Smalltalk code, which does not run in the client like all the
 data-driven model definitions etc that I already have

 
You answered:

There is no such requirement.

Of course, there is, actually it's an absolute necessity in my case.

Almost all UI components relate to some definition data, which exist in my main Smalltalk environment. From this data the DDL is generated, the models created, this data handles at run-time the instance variables, avoid getters and setters, and a huge lot more. It's ALL ONLY in ONE central place, of course. No dedundancies! This also handles versions and different configs.

The UI is just a slightly enhanced extension to the data-definded models in the MVC concept. And all my models are defined ONLY by data.

It would be insane to douplicate this data into the UI parts!

I wrote:

the responsivness of such a solution in the browser must always be far
 slower than any "normal" browser UI

 
You answered:

That's not true. For example, at the moment my UI is Mozilla's
A-Frame 3D virtual reality framework, at 90 frames per second.

Well, what I have seen from the demos, the responsiveness to the cursor alone is so very far away from being acceptable that I only belive, what you are writing, when I have seen a real-word JavaScript UI based on your system. Sorry, over the years, from bad experiences and one's own mistakes, I have become very sceptical and even more careful.
 
I wrote:

 and it's impossible to port my >10.000 framwork and application
 classes to Squeak.

 
You answered:

Caffeine can use Pharo, Squeak, or Cuis.

Well, my Smalltalk code is in neither of these and it would cost many months of work and the loss of very essential tools to port this to any of your supported systems. That is out of any discussion. Such an investment would never pay back and AFAIK a lot of features are missing in Pharo to substitute my current environment (I couldn' be drunk enough to ever consider Squeak alone because of its outregeous UI).

However, I see one advantage in your approach, assuming that no Smalltalk source code must be sent to the client (I have no info about that) and this is in the fact that Smalltalk byte code is, of course, a much better protection of IPR than any obfuscated JavaScript could ever offer. But the price for this advantage would be far to high, as far as I can currently tell.

So, thank you for responding. I tink we can close the case at least for the foreseable future (and I can't wait, I need some working solution during winter 2017/18).

Good luck with your development!

Best regards
Frank

Hi Frank--

> > > ...especially if their sources MUST be closely connected with
> > > existing Smalltalk code, which does not run in the client like
> > > all the data-driven model definitions etc that I already have
> >
> > There is no such requirement.
>
> Of course, there is, actually it's an absolute necessity in my case.

     Oh, I misunderstood you. I thought you were saying that such a
coupling was a bad thing; I didn't realize it's a constraint you already
have. Anyway, Caffeine is a distributed system. As long as your existing
code can use WebSockets, you can use remote messaging between your code
and the object memories running in web browsers. The Snowglobe remote UI
examples, for example, have object memories running in the AWS cloud
which can send messages to objects in a web browser, modifying that web
browser's DOM objects.

> > ...at the moment my UI is Mozilla's A-Frame 3D virtual reality
> > framework, at 90 frames per second.
>
> Well, what I have seen from the demos, the responsiveness to the
> cursor alone is so very far away from being acceptable...

     That must have been the first Smalltalk Morphic demo, in which
Morphic had full unoptimized control of the cursor. Since then, I've
made UIs that use the Zebkit UI framework, morphic.js from the Snap
project, A-Frame, and pure HTML/CSS. As it turns out, I now always use
the web browser's built-in cursor handling for the normal case, even
with Smalltalk Morphic, so one gets the native OS cursor handling speed.

> ...that I only believe, what you are writing, when I have seen a
> real-world JavaScript UI based on your system. Sorry, over the years,
> from bad experiences and one's own mistakes, I have become very
> skeptical and even more careful.

     Sure, no worries; as older demos are replaced with newer ones this
stuff will be obvious.

> > > and it's impossible to port my >10.000 framwork and application
> > > classes to Squeak.
>
> > Caffeine can use Pharo, Squeak, or Cuis.
>
> Well, my Smalltalk code is in neither of these and it would cost many
> months of work and the loss of very essential tools to port this to
> any of your supported systems.

     Oh, since you're not using Pharo, if were were to continue this
conversation it should be off-list in private email. Anyway, you could
use Caffeine's remote UI server component in your Smalltalk environment,
and just use web browsers for the UI.

     I'm currently adapting the remote messaging parts to all the other
Smalltalks.

> However, *I see one advantage in your approach*, assuming that no
> Smalltalk source code must be sent to the client (I have no info
> about that) and this is in the fact that Smalltalk byte code is, of
> course, a much better protection of IPR than any obfuscated
> JavaScript could ever offer. But the price for this advantage would
> be far to high, as far as I can currently tell.

     No, no Smalltalk code need be sent to the client, although you
always have the option of sending remote messages.


     thanks,

-C

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
[hidden email]
voice through 2017-09-12:
+ 1 510 833 5799 (SMS ok)
+31  20 893 2796 (no SMS)

Good morning Craig,

thank you very much for your reply. Your statements sound very good and most interesting!

Please pardon, if I expressed myself improperly and not clear enough, which seems to have brought you on a wrong track.

So, I propose, let's make a total reset to our current conversation and start it all over again! In order to be more successful in this, I would need more details and I will try to acquire them in the next few days.

Is there any link and/or doc where I can get more details on your work and plans than there are available on: https://pharojs.github.io ?

The cause of your last posting is that my interest in your concepts has grown tremendously. You will soon see why.

I will give you a more details about my environment and intentions:
- WebSockets are available and play an essential part in my UI concepts.
- Pharo - I don't mind using Pharo for, let's say, some "intermediate code fractions" as long as the existing server image can keep the sources and generate UI definitions for the client from its definition data. The technical code interchange between Pharo and the Smalltalk I use works quite well. It must just be avoided to port >10.000 application and test classes wtih >200K methods and all my own tools to Pharo. No way!
- User Interface it seems that we are discussing here two levels, which should be seen separately although they closely interact, of course:

1) there is your part, which consists (in my simple words) of some browser add-on

2) there will be another part, which - at least over the next few years - consists of the by far most comprehensive UI library on the market, which is best capable of providing a desk-top look-and-feel and which much later I intend to substitute by a Smalltalk UI library (see below)

3) there partially are already and will soon be much more of my code, which in the near future acts as middle layer with these main purposes to:

3a) Generate all of the UI components using 2) only from definition data, whose original resides in my server image and which is serialized and provided to the client - mainly in a start-up batch procedure and to a smaller part also during run-time by responding to user actions and/or events

I have been using an earlier version of this UI lib a few years ago based on handwritten JS code (what a nightmare for a Smalltalker to write JS code in these stone-age tools [I used Eclipse]) for a smaller project and from there I have some experience, which as far as this lib is concerned is mostly positive and for JS just the opposite primarily for the almost non-existing IDE and the crap of file-based sources in general

Side-remark1: Why don't want these ignorant idiots who develop JavaScript and its primitive tools refuse to learn from Smalltalk?!?! In a JS forum, some of them wanted to explain me what "o-o" means although I made the clear statement that I have mostly Smalltalk experience.

Side-remark2: I used Joose.it, a JavaScript extension that uses a somewhat Smalltalk-like syntax. It was developed by a former HPI student in Potsdam who came from the Smalltalk world. Brilliant!

3b) The middle layer will also act as a generic and data-driven message and data exchange interface with the server, whose purpose is to automate and mostly handle in a generic fashion all the required message passing between the "V" in the client and the "M" in the server as in MVC.

3c) The middle layer will also provide some lower-level "C"ontrollers, which again will mostly consist of data as a first and generic user action control system.

3d) Soon later the data-driven middle layer will be the precondition and technical basis of an UI editor, which is to enable low-skilled programmers, consultants and even somewhat trained and motivated end-users to modify or enhance parts (primarily containers, canvasses) of the prepared UI to their taste and needs. This is the logical extension to and it must work closely together with my long existing user-extendable data models, which constitute an important feature of my applications.

4) My long-term but most important plans (again: the UI iS THE decisive part in standard software) go far beyond this scenario. To cut it short, just the core points:

4a) The JS lib must be fully replaced by a mostly compatible Smalltalk lib (that aint no simple work).

4b) There must be a "private" browser, which offers Smalltalk direct access to the DOM without the current limitations (SOP single origin policy being just one of them) and which sends events straight to Smalltalk.

4c) This private browser should ideally become a technically integrated part of the whole Smalltalk scenario. I know that this is feasable. This will make my mass-market applications independent of the big-G evil giant who is about to extend their monopoly to the browser usages also due to FF's incapabilities to keep it's market share and with G's latest intention to regulate the advertising market by setting their rules in their unfortunately most popular browser.

A few more general notes:

- there is no room for this ugly, insane crap called html in most of my scenarios. It'll all go straight to the DOM.
- the browser in my scenarios comes in two appearances:
a) as a classical browser (to which I have lots of good ideas)
b) as a desk-top like UI, which does not appear to be a browser but technically still is by 100%

- I have lots of concepts and ideas concerning the user interface (those parts that the user really interacts with) and one of my hopes is that in the long-run this will solve Smalltalk's greatest deficiencies, which are in the lack of a really user-friendly and standard-like looking UI. See my posting here above of 13. Aug. 2017 - 22:42.

- I do have a neither finished nor yet presentable white paper, size close to 100 pages, about my UI plans but I do not want to disclose this by now. It's far too early.

- There is an important caveat in the close integration of the definition data with the UI parts, which mainly are an extension to what already exists in the definition data. It will neither be possible nor make any sense to extract some parts of it and use them separately. It's either all or nothing. Also, the learning curve is quite high, because the existing framework simplifies, standardizes and automates lot's of things, which must otherwise be programmed individually, but this causes a lot of learning requirements of the extemely well documented abstract and generic parts of my class tree - and it's not in Pharo.

Best regards
Frank

Craig,

I thought about it and I will send you a personal email with a lot more details. Please give me a few days but you should have it by next weekend.

I would appreciate if we could continue the discussion directly and outside this mailing list, because, as you wrote, it is not really a matter of Pharo.

Best regards
Frank

Phil,  

nice attempt to drill and silence me! My advise: They all failed!

If somebody can't cope with straight critics or unpopular opinions that aint my fault.

Frank
who never worried about being labeled and
from a country where free speech is still welcome

-------- Original Message --------

Subject: Re: [Pharo-dev] @About posting here

Local Time: August 16, 2017 7:40 AM

UTC Time: August 16, 2017 11:40 AM

From: [hidden email]

To: Pharo Dev <[hidden email]>

Am 16.08.2017 um 13:21 schrieb Guillermo Polito <[hidden email]>:

Hi Frank,

I'll just repeat Stef's message: It's not about being straight or having unpopular opinions. It's about being rude and on the limit of the insult. I feel myself some harshness in your messages, it's like you're saying that everybody but you is stupid. I know that you did not say that "explicitly" but that's the way it feels. And I'm sure I'm not the only one feeling like it.

Of course, that did not prevent me to answer you politely, but at the end what will happen is that people will not answer you anymore. Just take into account that if many people think already that your mails are aggressive, there may be some fault on your side too.

That said, this does not mean that I want to "censor" you. Just choose better your words but keep the same content.

+1 to all you said.

And I would like to know why every smalltalk troll is german? That's so sad!

Norbert

On Wed, Aug 16, 2017 at 12:52 PM, Frank-B <[hidden email]> wrote:

Phil,

nice attempt to drill and silence me! My advise: They all failed!

If somebody can't cope with straight critics or unpopular opinions that aint

my fault.

Frank

who never worried about being labeled and

from a country where free speech is still welcome

--

View this message in context: http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p4961628.html

Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

--

Guille Polito Research Engineer French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: +33 06 52 70 66 13

Dear @all three above,

I won't step into such off-topic discussions in a technical forum, especially not if postings contain such stereotype and almost rassist propaganda arguments as above.

I hold it avec le grand Voltaire - and I am expecting the same from everybody I communicate with:

L'original:
"Je hais vos idées, mais je me ferai tuer pour que vous ayez le droit de les exprimer"
Il existes plusieurs versions et je ne sais pas laquelle est la juste.
That is NOT a Google translation. I went to school in France.

In Deutsch:
"Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, daß Sie sie äußern dürfen."

My translation to English:
"Monsieur, I do not share your opinion, but I would give my life to defend that you may express it."

Tempi passati! 
Today, truth and divergent opinions are the new hate crimes as we see here!
I think it would be far more intelligent and useful to welcome what in German is called a "Querdenker" literally translated a "cross thinker" (or lateral thinker?) who in my case does not even expect others to agree.

Très sincèrement - most sincerely - Habe die Ehre!
Frank

From my side: Case closed!

Dimitris,

the case you refer to was closed on my side: I won't comment.

But there was one false quotation on your side:

I never heard or read any pharoer to refer to Pharo as the best IDE.

I did not write that!

I referred to Smalltalk in general and I am deeply convinced that for o-o development Smalltalk in general has by far the "best" development environment based on objective features: It's the only one to tell instantly all senders, implementors, locally or globally, class refs and a lot of other things that others don't even dream of.

BUT: I made not a single judgement on Pharo (except on it's UI for end-user products), simply because I don't know it sufficiently.

And I agree, that Delphi was an extremely good product in my opinion primarily for the UI. I managed a project in Delhi many years ago but I did not code myself.

My intend for writing here was beyond asking for the status of Smalltalk to JavaScript translators and alike to perhaps help to improve this and possibly a few other points.

This is primarily concerning my mid-range plans for a much better user interface. My plans say that my UI will very easily support different Smalltalk dialects simoultaneously and it will be targeting professional business applications both in the browser and for the desk-top based on ONE code-base.

But I am about to continue to do this ONLY in direct correspondance with writers here. I think this is much more productive and successful than having to fight ignorant, discriminatory and almost rasist postings from people who hate any critical and diverting opioins expressed in straight-forward but still correct language or who feel "insulted", because somebody does not agree with what they have been using. Being "pseudo-insulted" is the currently popular retorical attempt to suppress other people's opinions.  Won't work on me!

Frank