October 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Binary Decision Diagram Package in Smalltalk

by Ben Coman

On Thu, Oct 26, 2017 at 3:39 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi andrew > > I think that Avi did a package about BDD (but I thought it was special > binary trees) so this is probably the same. > Did you check on Squeaksource? > http://www.squeaksource.com/BTree.html > If this is what you are looking for I can help porting it to Pharo. > > Stef > > BTree is a database indexing implementation. Actually it would be a good feature to have available with Pharo. BDD is diagram[1] . Roassal would be the best bet. If it doesn't have an out of the box BDD, all the pieces are there make one. And the Roassal guys love new use cases. [1] https://www.lucidchart.com/pages/decision-tree cheers -ben > > On Wed, Oct 25, 2017 at 9:02 PM, Prof. Andrew P. Black <black(a)cs.pdx.edu> > wrote: > > Does anyone know of a BDD â thatâs Binary Decision Diagram â package > written in Smalltalk? > > > > Andrew > > > > > >

Oct. 27, 2017

UFFI and Fortran

by horrido

Can UFFI be used to call into a Fortran library? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 27, 2017

Re: [Pharo-users] Smalltalk Argument

by phil＠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 On Thu, Oct 26, 2017 at 6:23 PM, henry <henry(a)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 <dellani(a)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 <henry(a)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 <henry(a)callistohouse.club> wrote: > > 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 > From: henry(a)callistohouse.club > To: phil(a)highoctane.be <phil(a)highoctane.be> <phil(a)highoctane.be>, Any > question about pharo is welcome <pharo-users(a)lists.pharo.org> > <pharo-users(a)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, phil(a)highoctane.be <phil(a)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/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 > > > On Thu, Oct 26, 2017 at 8:43 AM, henry <henry(a)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, phil(a)highoctane.be < phil(a)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-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 > >

Oct. 26, 2017

Re: [Pharo-users] Cryptography and hashing in Pharo

by Paul DeBruicker

I made this port/copy of the squeaksource package: http://smalltalkhub.com/#!/~Cryptography/Cryptography Is that the version you were thinking of and couldn't find? What is ifs? I don't understand what you want to do with the hashing. Are you talking about hashing domain objects for external storage? Do you have to interact with another system or just have hashed data in the image or stored somewhere internally to your project? What OS are you going to use? I think you can get to the point where your objects can be hashed by any of the backends you mention and just change among them as your needs change. That being said NaCl seems the most generally useful. Cryptographic hashing in Pharo is slower than C, so depending on the volume of data to hash a Pharo implementation may be too slow. hope this helps Paul CÃ©drick BÃ©ler wrote > Hi again, > > > Concerning cryptography in Pharo, there are to my knowledge : > => a package developed in squeak [1] that was I think ported/forked for > Pharo. I cannot find the Pharo version > => a binding to the sodium library (NaCl) [2] > > With one would you recommend ? Maybe another option ? > > > Concerning hashing (Iâd like to hash information content a bit like this > is done in ifs with their multihash lib [3]) > => I found a keccak implication with I think would do the [4]. Any > feedback ? Other implementations available ? > => Do you think having something like ifs multihash would be interesting > in Pharo ? > > > Again, thanks in advance for your comments/advices. > > CÃ©drick > > > [1] http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html> > [2] > http://catalog.pharo.org/catalog/project/Nacl?_s=54MCZlmxc6F08Ht4&_k=HxcBD1… > <http://catalog.pharo.org/catalog/project/Nacl?_s=54MCZlmxc6F08Ht4&_k=HxcBD1pRVtXkfVFM> > [3] https://github.com/multiformats/multihash > <https://github.com/multiformats/multihash> > [4] https://github.com/sbragagnolo/Keccak > <https://github.com/sbragagnolo/Keccak> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 26, 2017

Re: [Pharo-users] Business process (declaration and orchestration), ontology/taxonomy,

by Paul DeBruicker

Maybe the package described here has what you're looking for : http://forum.world.st/Ann-Workflow-td4963635.html CÃ©drick BÃ©ler wrote > Hi again, this is my last question and the more general one of the day :-) > > > Iâm looking for way of representing and executing simple "business > processes" in Pharo and a way of declaring domain ontologies/taxonomies. > > I didnât find any lib around this subjects except some projects in other > smalltalk dialects. > > I just wander if somebody has done some work in these field. Iâm also > interested in (KISS) design discussions around these topics, hence this > email. > > I donât want to do a full fledged business process middleware. > > I would need : > - a way to represent simple business processes (succession of activities > with logic gates (and/or/xor) => I might be able to do that by myself). > - a way to execute these processes (routines) in a semi-aotumatic manner > => This looks more difficult to do to me. > => my aim is to execute recurrent routines (my routines) with the help of > a Pharo application > > > For such a system, I also need a way to categorize information context. > Again, I donât think I need a full fledged ontology implementation like > Description Logic (or whatever). I think Iâll be happy with information > tagging according to a predefined taxonomy. Instead of flat tags, Iâd like > them to implement some sort of multiple inheritance. For instance, I may > need a tag #soccer that "inherit" #sport. > > Any information regarding taxonomy tagging in Pharo ? (Or eventually > ontology?). > > > > TIA, > > CÃ©drick -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

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 On Thu, Oct 26, 2017 at 11:39, Paulo R. Dellani <dellani(a)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 <[henry@callistohouse.club](%22mailto:henry@callistohouse.club%22)> 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 <[henry@callistohouse.club](%22%22mailto:henry@callistohouse.club%22%22)> wrote: >>> >>>> 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 >>>>> From: henry(a)callistohouse.club >>>>> To: phil(a)highoctane.be [<phil(a)highoctane.be>](mailto:phil@highoctane.be), Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](mailto:pharo-users@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, phil(a)highoctane.be <[phil@highoctane.be](%22%22%22mailto:phil@highoctane.be%22%22%22)> 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/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1… >>>>>> >>>>>> 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… >>>>>> >>>>>> 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 <[henry@callistohouse.club](%22%22%22mailto:henry@callistohouse.club%22%22%22)> 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, [phil@highoctane.be](%22%22%22mailto:phil@highoctane.be%22%22%22) < phil(a)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

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by Paulo R. Dellani

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 <henry(a)callistohouse.club > <%22mailto:henry@callistohouse.club%22>> 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 <henry(a)callistohouse.club > <%22%22mailto:henry@callistohouse.club%22%22>> wrote: > > 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 > From: henry(a)callistohouse.club > To: phil(a)highoctane.be <phil(a)highoctane.be>, Any question > about pharo is welcome <pharo-users(a)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, phil(a)highoctane.be > <phil(a)highoctane.be > <%22%22%22mailto:phil@highoctane.be%22%22%22>> 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/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1… > <%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 > <henry(a)callistohouse.club > <%22%22%22mailto:henry@callistohouse.club%22%22%22>> > 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, phil(a)highoctane.be > <%22%22%22mailto:phil@highoctane.be%22%22%22> > <phil(a)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 >

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

The question I propose you is what is necessary to make Pharo eligible to participate in cloud/BigData? - HH On Thu, Oct 26, 2017 at 10:38, henry <[henry(a)callistohouse.club]("mailto:henry@callistohouse.club")> 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 <[henry(a)callistohouse.club](""mailto: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 <[henry(a)callistohouse.club]("""mailto:henry@callistohouse.club""")> wrote: >> >>> 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 >>>> From: henry(a)callistohouse.club >>>> To: phil(a)highoctane.be <phil(a)highoctane.be>, Any question about pharo is welcome <pharo-users(a)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, phil(a)highoctane.be <[phil(a)highoctane.be](""""mailto:phil@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/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…""""https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…"""") >>>>> >>>>> 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 >>>>> >>>>> On Thu, Oct 26, 2017 at 8:43 AM, henry <[henry(a)callistohouse.club](""""mailto: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, [phil(a)highoctane.be](""""mailto:phil@highoctane.be"""") <phil(a)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 >>>>>>> >>>>>>> On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)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-bounces(a)lists.pharo.org> on behalf of David Mason <dmason(a)ryerson.ca> >>>>>>>> Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>>>>>> Date: Tuesday, October 24, 2017 at 11:52 AM >>>>>>>> To: Any question about pharo is welcome <pharo-users(a)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, jtuchel(a)objektfabrik.de <jtuchel(a)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:jtuchel@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

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

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 <[henry(a)callistohouse.club]("mailto: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 <[henry(a)callistohouse.club](""mailto:henry@callistohouse.club"")> wrote: > >> 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 >>> From: henry(a)callistohouse.club >>> To: phil(a)highoctane.be <phil(a)highoctane.be>, Any question about pharo is welcome <pharo-users(a)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, phil(a)highoctane.be <[phil(a)highoctane.be]("""mailto:phil@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/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…"""https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…""") >>>> >>>> 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 >>>> >>>> On Thu, Oct 26, 2017 at 8:43 AM, henry <[henry(a)callistohouse.club]("""mailto: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, [phil(a)highoctane.be]("""mailto:phil@highoctane.be""") <phil(a)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 >>>>>> >>>>>> On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)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-bounces(a)lists.pharo.org> on behalf of David Mason <dmason(a)ryerson.ca> >>>>>>> Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>>>>> Date: Tuesday, October 24, 2017 at 11:52 AM >>>>>>> To: Any question about pharo is welcome <pharo-users(a)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, jtuchel(a)objektfabrik.de <jtuchel(a)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:jtuchel@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

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

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 > From: henry(a)callistohouse.club > To: henry <henry(a)callistohouse.club> > phil(a)highoctane.be <phil(a)highoctane.be>, Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > 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 <[henry(a)callistohouse.club]("mailto:henry@callistohouse.club")> wrote: > >>> âââ 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: henry(a)callistohouse.club >>> To: phil(a)highoctane.be <phil(a)highoctane.be>, Any question about pharo is welcome <pharo-users(a)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, phil(a)highoctane.be <[phil(a)highoctane.be](""mailto:phil@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/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…""https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…"") >>>> >>>> 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 >>>> >>>> On Thu, Oct 26, 2017 at 8:43 AM, henry <[henry(a)callistohouse.club](""mailto: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, [phil(a)highoctane.be](""mailto:phil@highoctane.be"") <phil(a)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 >>>>>> >>>>>> On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)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-bounces(a)lists.pharo.org> on behalf of David Mason <dmason(a)ryerson.ca> >>>>>>> Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>>>>> Date: Tuesday, October 24, 2017 at 11:52 AM >>>>>>> To: Any question about pharo is welcome <pharo-users(a)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, jtuchel(a)objektfabrik.de <jtuchel(a)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:jtuchel@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

Oct. 26, 2017