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

Re: [Pharo-users] What is code 137 / how to gracefully shut down via SIGTERM?

by Herby VojÄÃk

Esteban Lorenzano wrote: > Hi, > > I donât know if is useful in your case, but you made me remember I made > a small tool to trap unix signals within Pharo. I uploaded then to github. > > https://github.com/estebanlm/pharo-posix-signal Cannot load it. See attachment. Tried the on the current Pharo6.1-win. Herby

Oct. 31, 2017

Re: [Pharo-users] Microsoft COM

by tesonep＠gmail.com

Hi Ben, first sorry for answering late, I have seen your mail before, but the tons of mails of Pharo got over it. I will tell you the state of what I have and what maybe you will need. But, before my plan is to improve this, but as with everything it is easier to push it if I have some users. - I have implemented a way of expressing FFI calls to COM objects, I have solved all the problems of the Vtable and the different types. So it is possible to create a wrapper for any of the COM objects. I have done so for the objects used in the "reflective" API of COM. - My idea is to use the reflective API to generate automatically the Pharo Wrappers to the objects. This is nice, but if you need to use some known objects you don't need all this transparency as using known instances can be easily implemented. - I have some examples using the IE COM object as it is a nice thing to use, and also it uses many different things in the API (properties, variant, optional parameters, etc). However, the support in the Variant type is not full yet. You can receive and send variant type values, but reading the different contents is not implemented (it has like 30 different payloads in the type, I have only the basics). I have to check what I have know, because I have been working a little more, but I have to put it in Github and organize it a little. Now it is working in Pharo 6 32Bits. My plan is to first migrate it to Pharo7 also (I think it should be straight forward) and then implement it for 64 bits (this part is possible that requires a big rewritting, as the API has some changes from 32 to 64 bits). In the next days I will try to make a couple of examples to show how to map a known class. I remember that the reflective part now can query the interface and perform dynamic calls but the way of interacting with it should be improved. I really will love to have somebody using it, so I will try to help you if you (or other) has a use case. Usually having a use case is easy to move a project. Cheers, Pablo On Mon, Oct 30, 2017 at 6:11 PM, Ben Coman <btc(a)openinworld.com> wrote: > Hi Pablo, > > At work I managed to remote control Internet Explorer with Excel VBA like > this... > [1] http://www.automateexcel.com/vba/automate-internet-explorer > > and went looking for how similar might be achieved from Pharo. IIUC I > discovered this would be done via Microsoft's Component Object Model, and > then I bumped into your repo... > [2] https://github.com/tesonep/pharo-com > > Could you advise the status and your plans for this? Since I see its only > a few months old I've probably stumbled onto it prematurely, but I see no > documentation or tests to discover how to use it. So I'll curious whether > it makes something like [1] possible? And could you show how that would be > done? > > cheers -ben > > > P.S. For context, at work I automated IE since the intranet document > management system (OpenText) does authentication via a javascript function > in the browser, which doesn't compute with Microsoft's MSXML.DOMDocument > component. So I use IE to do the authentication and grab the raw XML from > IE to then stuff it into MSXML.DOMDocument from which I pull the data I > need. > > But I'd love to do it with Pharo instead (if I can get IT to white list it) > > cheers -ben > -- Pablo Tesone. tesonep(a)gmail.com

Oct. 31, 2017

Re: [Pharo-users] "sourcetrail" a code browser for C++/Java

by rainer.winkler＠poaceae.de

Hi Holger, thanks for mentioning the Software Exploration Tool Sourcetrail. I use it when I develop in C, it is now free for non commercial using. I already contactedÂ Eberhard GrÃ¤ther to discuss using Sourcetrail for other languages than C, C++ and Java. But this will probably at best take some time. So I am still using the Open Source Software Exploration Tool Moose2Model (www.moose2model.org) I developed. I use it for Smalltalk and SAP ABAP. It can be used in a similar way to Sourcetrail, but gives also the option to build commented and customized maps that can be stored and updated with new coding versions. Sourcetrail on the other hand gives much more details on the analyzed coding. I mentioned Sourcetrail in my talk at ESUG 2017 (https://www.slideshare.net/esug/do-visualizations-help-during-development-u… andÂ https://youtu.be/0ttLYM1tkek?list=PLJ5nSnWzQXi_THfKwhzxFwbXy00YTi0uv&t=1008 ) Cheers Rainer -----Original-Nachricht----- > Betreff: Pharo-users Digest, Vol 54, Issue 175 > Message: 5 > Date: Fri, 27 Oct 2017 13:11:26 +0800 > From: Holger Freyther <holger(a)freyther.de> > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: [Pharo-users] "sourcetrail" a code browser for C++/Java > Message-ID: <30393F2B-BEC7-4FF4-AFDD-E467934D98B8(a)freyther.de> > Content-Type: text/plain; charset=us-ascii > > Hi, > > I was just watching some videos and stumbled across sourcetrail[1][2]. The visualizations look pretty neat. Maybe it can be used an inspiration? > > cheers > > Â Â Â Â Â holger > > > [1] https://www.youtube.com/watch?v=r8S6V6U5Vr4 > [2] https://www.sourcetrail.com

Oct. 31, 2017

Re: [Pharo-users] What is code 137 / how to gracefully shut down via SIGTERM?

by David T. Lewis

On Sat, Oct 28, 2017 at 01:39:56PM +0200, Herby Voj????k wrote: > Hi, > > I had to find out how to automatically deploy the backend written in > Pharo, and so far it uses docker-compose stop to stop the instance (and > later docker-compose up -d to get everything up again). > > I noticed the stop phase takes a while and ends with status code 137. I > presume it ended forcefully and not gracefully. > > What is the idiomatic way to wait on SIGTERM and close the process > gracefully? > > Thanks, Herby Try this: mySemaphore := OSProcess accessor forwardSigTerm. mySemaphore wait. "wait eg in a process until SIGTERM is detected" Typically you would use #forwardSigTerm to set up the signal handler, then start a Smalltalk process that waits on the semaphore and does whatever you want to do when the Unix signal is detected. You can do signal forwarding for any Unix signal, the #forwardSigTerm is just a convenience method. Dave

Oct. 31, 2017

Re: [Pharo-users] Pharo 6.1 - Apple signing

by Stephane Ducasse

We tried to get signing for the Pharo association but it did not work. So ZweiDenker proposed that we can use their key. Now esteban was busy with consulting for Pharo + iceberg + tonel. Stef On Tue, Oct 31, 2017 at 3:38 PM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > If it would be a help, I can sign the apps. > > > > Cheers > > Andrew > > > > > > From: Todd Blanchard > Sent: Tuesday, October 31, 2017 10:36 AM > To: Any question about pharo is welcome > Subject: Re: [Pharo-users] Pharo 6.1 > > > > Actually, it is in Applications > > > > Sent from the road > > > >> On Oct 31, 2017, at 02:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> > >> > >> > >>> On 30 Oct 2017, at 20:30, Todd Blanchard <tblanchard(a)mac.com> wrote: > >>> > >>> I was just preparing a similar post. Just downloaded latest Pharo >>> 6.1-64 for Mac > >>> > >>> I was greeted with a walkback when it failed to create directory >>> /private/var/folders/ks/wg6l98bj64q6hgvs23wwqypr0000gn/T/AppTranslocation/DAA5EA3A-374D-4ADE-9E04-BBB7433BB6C8/d/Pharo6.1-64.app/Contents/Resources/pharo-local > >>> > >>> Definitely not the right directory to resolve pharo-local to. > >> > >> not related :) > >> this is because you didnât put Pharo under /Applications as indicated when >> you download Pharo. > >> at the same time, this is because we are still not signing Pharo, then >> apple moves it to a sandbox, which is bad. I have in my TODO signing the >> apps, but still no time to do it :/ > >> > >> Esteban > >> > >>> > >>> -Todd Blanchard > >>> > >>>> On Oct 30, 2017, at 12:27 PM, ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð² >>>> <vikenti.potapov(a)gmail.com> wrote: > >>>> > >>>> > >>>> I've just downloaded Pharo 6.1 from pharo.org, unzipped it and started. >>>> And i've got an error: > >>>> "UTF8InvalidText: Invalid utf8 input detected" > >>>> > >>>> Whether i save image or not, every time i start it i get the same error. > >>>> > >>>> System: win 7 professional x64 on 6-core Athlon Phenom. > >>>> Locale: russian (cyrillic). > >>>> > >>>> Can i fix it by myself or i should forget about 6.1 until global bugfix? > >>>> > >>>> Vikenti Potapov > >>>> > >>> > >>> > >> > >> > > > >

Oct. 31, 2017

Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/designchange considerations

by Andrew Glynn

Congrats :) Sent from Mail for Windows 10 From: henry Sent: Tuesday, October 31, 2017 1:56 PM To: henry Cc: Pharo-users list; Pharo Development List; Squeak-dev Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/designchange considerations I wanted to share my good news, though I have not yet gotten Pharo, Squeak and Java talking. What I was able to accomplish, after finishing the port of Cryptography's ASN1Types, Module and Streams is to get Java's rendezvous and key exchange working. After I got that connecting, I looked at the ciphers, ivSequences and MAC and got that working. In Java, I am now able to encrypt and decrypt "hello world". *Celebrates* - HH -------- Original Message -------- Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations Local Time: October 25, 2017 12:00 PM UTC Time: October 25, 2017 4:00 PM From: henry(a)callistohouse.club To: Ben Coman <btc(a)openinworld.com>, Squeak-dev <squeak-dev(a)lists.squeakfoundation.org>, Pharo-users list <pharo-users(a)lists.pharo.org> Pharo Development List <pharo-dev(a)lists.pharo.org> I disabled vatId authorization in version 3, located in SessionOperations>>processIWant | SessionOperations>>processIAm:. I was asked to disseminate my news to Pharo Users, hello there. I was asked to describe ParrotTalk well, provide use cases and adopters of its use. Alright, I will give an attempt. ParrotTalk is an encrypted connection framework. Currently allowing anonymous 2048-bit key negotiation to establish user-provided encryption cipher and user-provided encoding and decoding, both through a provided SessionAgentMap to a starting SessionAgent server. Please look in the test case ThunkHelloWorldTest for building these maps and running a connection iwth data passing after encryption is established. There is a 4-way negotiation, from ProtocolOffered/Accepted to Go/GoToo. In using RSA 2048 signature validation and DH 2048 primes to establish the key used within the selected Cipher. The Cipher and Encoder are selected by name through the negotiation protocol. Currently three Ciphers are selectable, AESede, DESede, and DES. There are two encoders tested, asn1der, and Bytes. This protocol is described here, in this document. https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFr… For as to use cases, this encrypted connection has no third party, man-in-the-middle situation by not using Certificates. As such, this is a tight implementation of NSA-proof encryption without explicit authorization beyond knowledge of a host:port. The use cases involve any communication desired to be encrypted with such high encryption. The support will last my lifetime, so we have a settled solution, here in the third version, provided here. It requires version 111 of Cryptography, as a prerequisite. Both run on Squeak and Pharo. http://www.squeaksource.com/Cryptography/Cryptography-zzz.111.mcz http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz The current use is with my hubbub system, a promise-based distributed object implementation. I am working to bring ParrotTalk to Java and allow hubbub to operate interdependently between Squeak, Pharo, Java and any other languages which can support ParrotTalk and STON. My latest efforts with hubbub are to bring STON as the Layer 6 encoding. Hubbub depends on eLinda. http://www.squeaksource.com/Cryptography/elinda-HenryHouse.14.mcz http://www.squeaksource.com/Oceanside/hubbub-HenryHouse.38.mcz Hubbub currently fails to load correctly in Pharo. In Squeak the two ParrotRemoteTestCases: LookupTestCase and OperationalTestCase really screw everything up, do not save an image after running. I never run these tests until I get a better handle of serialization. Currently, do to a shift in progress to STON, the serialization tests fail, just the way we like it. Fix the tests then the system starts to work right. The shift away from vatId authorization should not adversely affect hubbub, we hope! When STON starts to work, and I think I need to turn off jsonMode, then traffic between vats can start to be analyzed and figure out how resolving is working with redirectors invoked remotely. - HH -------- Original Message -------- Subject: Re: [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations Local Time: October 25, 2017 12:43 AM UTC Time: October 25, 2017 4:43 AM From: btc(a)openinworld.com To: henry <henry(a)callistohouse.club>, Pharo Development List <pharo-dev(a)lists.pharo.org> Stephane Ducasse <stepharo.self(a)gmail.com> If I google... parrottalk protocol nothing seems related.Â So what is ParrotTalk?Â P.S... since this is not "part of" pharo, [pharo-users] would be a better place for discussion than [pharo-dev]. Could you re-announce there, with some description of use cases and who/where the protocol is used? cheers -ben On Wed, Oct 25, 2017 at 1:42 AM, henry <henry(a)callistohouse.club> wrote: Please excuse all the low-level detail, if inappropriate to the discussion. The protocol changes are here specified. - HH On Tue, Oct 24, 2017 at 13:40, henry <henry(a)callistohouse.club> wrote: In order to bring ParrotTalk-3.6 support, alongside historical 3.5 support, the frame header stays the same and the processing of the ProtocolOffered would select "ParrotTalk-3.6" to use the compact protocol ofÂ - ProtocolOffered { offered, preferred } - ProtocolAccepted { accepted } -Â IWant|GiveInfo|ReplyInfoÂ {Â vatId, domain, publicKey, cryptoProtocols, dataEncodersÂ } - IAm|ReplyInfoÂ { vatId, domain, publicKey, cryptoProtocol, dataEncoder, dhParamÂ } - Go {Â cryptoProtocol, dataEncoder, dhParam, signature } - GoToo { signature } Using eLinda : http://www.squeaksource.com/Cryptography/elinda-HenryHouse.14.mcz Above the FrameBuffer, below the SessionOperations for each version of the protocol, an ELindaSession could be inserted. This session think would have the stacks for each protocol version SessionOperation registered by protocol in a Tuple, for eventual callback. When the ProtocolOffered comes in we publish the tuple frame,Â with set selectedÂ version, to route to the correct SessionOperation to support each version of the protocol. With a non-specific vatId required, anonymous connections would be supported. - HH On Tue, Oct 24, 2017 at 12:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: Hi henry thanks for this announce. Can you tell where such protocols are used? Stef On Tue, Oct 24, 2017 at 6:33 PM, henry wrote: > Hi all, > > I am happy to announce the release of version 3.5 of ParrotTalk, for Squeak > and Pharo, found here: > > http://www.squeaksource.com/Cryptography/ParrotTalk-zzz.2.mcz > > It follows this specification: > https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFr… > > One item of note, in version 3.5, the system connecting to a server, sending > the IWant msg, must know the vatId of the system being connected to. I am > considering changing this to version 3.6 by removing one round-trip in > messaging. Therefore, these messages would be combined: IWant/GiveInfo, > IAm/ReplyInfo. I will keep ProtocolOffered and ProtocolAccepted to allow > eLindaSession to support both versions: 3.5 and 3.6. > > Thoughts please? > > - HH

Oct. 31, 2017

Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations

by henry

I wanted to share my good news, though I have not yet gotten Pharo, Squeak and Java talking. What I was able to accomplish, after finishing the port of Cryptography's ASN1Types, Module and Streams is to get Java's rendezvous and key exchange working. After I got that connecting, I looked at the ciphers, ivSequences and MAC and got that working. In Java, I am now able to encrypt and decrypt "hello world". *Celebrates* - HH > -------- Original Message -------- > Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations > Local Time: October 25, 2017 12:00 PM > UTC Time: October 25, 2017 4:00 PM > From: henry(a)callistohouse.club > To: Ben Coman <btc(a)openinworld.com>, Squeak-dev <squeak-dev(a)lists.squeakfoundation.org>, Pharo-users list <pharo-users(a)lists.pharo.org> > Pharo Development List <pharo-dev(a)lists.pharo.org> > > I disabled vatId authorization in version 3, located in SessionOperations>>processIWant | SessionOperations>>processIAm:. > > I was asked to disseminate my news to Pharo Users, hello there. I was asked to describe ParrotTalk well, provide use cases and adopters of its use. Alright, I will give an attempt. > > ParrotTalk is an encrypted connection framework. Currently allowing anonymous 2048-bit key negotiation to establish user-provided encryption cipher and user-provided encoding and decoding, both through a provided SessionAgentMap to a starting SessionAgent server. Please look in the test case ThunkHelloWorldTest for building these maps and running a connection iwth data passing after encryption is established. There is a 4-way negotiation, from ProtocolOffered/Accepted to Go/GoToo. In using RSA 2048 signature validation and DH 2048 primes to establish the key used within the selected Cipher. The Cipher and Encoder are selected by name through the negotiation protocol. Currently three Ciphers are selectable, AESede, DESede, and DES. There are two encoders tested, asn1der, and Bytes. This protocol is described here, in this document. > > https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFr… > > For as to use cases, this encrypted connection has no third party, man-in-the-middle situation by not using Certificates. As such, this is a tight implementation of NSA-proof encryption without explicit authorization beyond knowledge of a host:port. The use cases involve any communication desired to be encrypted with such high encryption. The support will last my lifetime, so we have a settled solution, here in the third version, provided here. It requires version 111 of Cryptography, as a prerequisite. Both run on Squeak and Pharo. > > http://www.squeaksource.com/Cryptography/Cryptography-zzz.111.mcz > http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz > > The current use is with my hubbub system, a promise-based distributed object implementation. I am working to bring ParrotTalk to Java and allow hubbub to operate interdependently between Squeak, Pharo, Java and any other languages which can support ParrotTalk and STON. My latest efforts with hubbub are to bring STON as the Layer 6 encoding. Hubbub depends on eLinda. > > http://www.squeaksource.com/Cryptography/elinda-HenryHouse.14.mcz > http://www.squeaksource.com/Oceanside/hubbub-HenryHouse.38.mcz > > Hubbub currently fails to load correctly in Pharo. In Squeak the two ParrotRemoteTestCases: LookupTestCase and OperationalTestCase really screw everything up, do not save an image after running. I never run these tests until I get a better handle of serialization. Currently, do to a shift in progress to STON, the serialization tests fail, just the way we like it. Fix the tests then the system starts to work right. > > The shift away from vatId authorization should not adversely affect hubbub, we hope! When STON starts to work, and I think I need to turn off jsonMode, then traffic between vats can start to be analyzed and figure out how resolving is working with redirectors invoked remotely. > > - HH > >> -------- Original Message -------- >> Subject: Re: [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations >> Local Time: October 25, 2017 12:43 AM >> UTC Time: October 25, 2017 4:43 AM >> From: btc(a)openinworld.com >> To: henry <henry(a)callistohouse.club>, Pharo Development List <pharo-dev(a)lists.pharo.org> >> Stephane Ducasse <stepharo.self(a)gmail.com> >> >> If I google... parrottalk protocol >> nothing seems related. So what is ParrotTalk? >> >> P.S... since this is not "part of" pharo, [pharo-users] would be a better place for discussion than [pharo-dev]. >> Could you re-announce there, with some description of use cases and who/where the protocol is used? >> >> cheers -ben >> >> On Wed, Oct 25, 2017 at 1:42 AM, henry <henry(a)callistohouse.club> wrote: >> >>> Please excuse all the low-level detail, if inappropriate to the discussion. The protocol changes are here specified. >>> >>> - HH >>> >>> On Tue, Oct 24, 2017 at 13:40, henry <henry(a)callistohouse.club> wrote: >>> >>>> In order to bring ParrotTalk-3.6 support, alongside historical 3.5 support, the frame header stays the same and the processing of the ProtocolOffered would select "ParrotTalk-3.6" to use the compact protocol of >>>> >>>> - ProtocolOffered { offered, preferred } >>>> - ProtocolAccepted { accepted } >>>> - IWant|GiveInfo|ReplyInfo { vatId, domain, publicKey, cryptoProtocols, dataEncoders } >>>> - IAm|ReplyInfo { vatId, domain, publicKey, cryptoProtocol, dataEncoder, dhParam } >>>> - Go { cryptoProtocol, dataEncoder, dhParam, signature } >>>> - GoToo { signature } >>>> >>>> Using eLinda : >>>> >>>> http://www.squeaksource.com/Cryptography/elinda-HenryHouse.14.mcz >>>> >>>> Above the FrameBuffer, below the SessionOperations for each version of the protocol, an ELindaSession could be inserted. This session think would have the stacks for each protocol version SessionOperation registered by protocol in a Tuple, for eventual callback. When the ProtocolOffered comes in we publish the tuple frame, with set selected version, to route to the correct SessionOperation to support each version of the protocol. >>>> >>>> With a non-specific vatId required, anonymous connections would be supported. >>>> >>>> - HH >>>> >>>> On Tue, Oct 24, 2017 at 12:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> >>>>> Hi henry thanks for this announce. Can you tell where such protocols are used? Stef On Tue, Oct 24, 2017 at 6:33 PM, henry wrote: > Hi all, > > I am happy to announce the release of version 3.5 of ParrotTalk, for Squeak > and Pharo, found here: > > http://www.squeaksource.com/Cryptography/ParrotTalk-zzz.2.mcz > > It follows this specification: > https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFr… > > One item of note, in version 3.5, the system connecting to a server, sending > the IWant msg, must know the vatId of the system being connected to. I am > considering changing this to version 3.6 by removing one round-trip in > messaging. Therefore, these messages would be combined: IWant/GiveInfo, > IAm/ReplyInfo. I will keep ProtocolOffered and ProtocolAccepted to allow > eLindaSession to support both versions: 3.5 and 3.6. > > Thoughts please? > > - HH

Oct. 31, 2017

Re: [Pharo-users] What is code 137 / how to gracefully shut down via SIGTERM?

by Herby VojÄÃk

Bruce O'Neel wrote: > Hi, > > Well, not so scary. That's the mac list. From a not so recent mac with > Xcode 7 installed it looks like the below. > > The good news here is that the common signals have the same numbers. > And how often do you get an SIGXCPU? I was think of SIGUSR1, can be used to useful things (IIRC nginx or apache reload when sent), but that one is not common. :-( Of course, SIGTERM/SIGINT/SIGHUP are, so, yes, these are most important. Herby > cheers > > bruce > > #define SIGHUP 1 /* hangup */ > > #define SIGINT 2 /* interrupt */ > > #define SIGQUIT 3 /* quit */ > > #define SIGILL 4 /* illegal instruction (not reset when caught) */ > > #define SIGTRAP 5 /* trace trap (not reset when caught) */ > > #define SIGABRT 6 /* abort() */ > > #if (defined(_POSIX_C_SOURCE) && !defined(_DARWIN_C_SOURCE)) > > #define SIGPOLL 7 /* pollable event ([XSR] generated, not > supported) */ > > #else /* (!_POSIX_C_SOURCE || _DARWIN_C_SOURCE) */ > > #define SIGIOT SIGABRT /* compatibility */ > > #define SIGEMT 7 /* EMT instruction */ > > #endif /* (!_POSIX_C_SOURCE || _DARWIN_C_SOURCE) */ > > #define SIGFPE 8 /* floating point exception */ > > #define SIGKILL 9 /* kill (cannot be caught or ignored) */ > > #define SIGBUS 10 /* bus error */ > > #define SIGSEGV 11 /* segmentation violation */ > > #define SIGSYS 12 /* bad argument to system call */ > > #define SIGPIPE 13 /* write on a pipe with no one to read it */ > > #define SIGALRM 14 /* alarm clock */ > > #define SIGTERM 15 /* software termination signal from kill */ > > #define SIGURG 16 /* urgent condition on IO channel */ > > #define SIGSTOP 17 /* sendable stop signal not from tty */ > > #define SIGTSTP 18 /* stop signal from tty */ > > #define SIGCONT 19 /* continue a stopped process */ > > #define SIGCHLD 20 /* to parent on child stop or exit */ > > #define SIGTTIN 21 /* to readers pgrp upon background tty read */ > > #define SIGTTOU 22 /* like TTIN for output if (tp->t_local&LTOSTOP) */ > > #if (!defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)) > > #define SIGIO 23 /* input/output possible signal */ > > #endif > > #define SIGXCPU 24 /* exceeded CPU time limit */ > > #define SIGXFSZ 25 /* exceeded file size limit */ > > #define SIGVTALRM 26 /* virtual time alarm */ > > #define SIGPROF 27 /* profiling time alarm */ > > #if (!defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)) > > #define SIGWINCH 28 /* window size changes */ > > #define SIGINFO 29 /* information request */ > > #endif > > #define SIGUSR1 30 /* user defined signal 1 */ > > #define SIGUSR2 31 /* user defined signal 2 */ > > > /31 October 2017 14:56 Herby VojÄÃk <herby(a)mailbox.sk> wrote:/ > > Bruce O'Neel wrote: > > Hi, > > > > Posix requires that if the process is killed the return status is > > greater than 128. > > > > What is convention on linux systems is that if the process is sent a > > signal then the signal number is added to 128. Therefore 137 is > SIGKILL > > (kill -9). SIGTERM is 143, SIGABRT is 134, SIGSEGV is 139, and so > on. > > I've not seen an exception to this but there could be. > > > > Signals off of my closest linux system look like: > > > > #define SIGHUP 1 > > #define SIGINT 2 > > #define SIGQUIT 3 > > #define SIGILL 4 > > #define SIGTRAP 5 > > #define SIGABRT 6 > > #define SIGIOT 6 > > #define SIGBUS 7 > > #define SIGFPE 8 > > #define SIGKILL 9 > > #define SIGUSR1 10 > > #define SIGSEGV 11 > > #define SIGUSR2 12 > > #define SIGPIPE 13 > > #define SIGALRM 14 > > #define SIGTERM 15 > > Scary, because Esteban's sigtrapping package has them defined a bit > differently: > > { #category : #'class initialization' } > POSIXSignal class >> initialize [ > SIGHUP := 1. > SIGINT := 2. > SIGQUIT := 3. > SIGILL := 4. > SIGTRAP := 5. > SIGABRT := 6. > SIGPOLL := 7. > SIGIOT := SIGABRT. > SIGEMT := 7. > SIGFPE := 8. > SIGKILL := 9. > SIGBUS := 10. > SIGSEGV := 11. > SIGSYS := 12. > SIGPIPE := 13. > SIGALRM := 14. > SIGTERM := 15. > SIGURG := 16. > SIGSTOP := 17. > SIGTSTP := 18. > SIGCONT := 19. > SIGCHLD := 20. > SIGTTIN := 21. > SIGTTOU := 22. > SIGIO := 23. > SIGXCPU := 24. > SIGXFSZ := 25. > SIGVTALRM := 26. > SIGPROF := 27. > SIGWINCH := 28. > SIGINFO := 29. > SIGUSR1 := 30. > SIGUSR2 := 31. > ] > > >

Oct. 31, 2017

Failure with ZdcPluginSSLSession on latest Pharo 32 bit/Win

by Raffaello Giulietti

Hi Pharo 32 bit/Win users, I'm on the latest stock Pharo 32 bit/Win downloaded from http://files.pharo.org/platform/Pharo6.1-win.zip which contains the latest 60518 image. When evaluating Metacello new smalltalkhubUser: 'Moose' project: 'GToolkit'; configuration: 'GToolkit'; version: #development; load. I get an exception roughly stating: PrimitiveFailed: primitive #primitiveSSLCreate in ZdcPluginSSLSession failed I cross-checked the presence of all the .dlls in the Pharo6.1 folder, they are all there, including SqueakSSL and ssleay32. Anybody experiencing similar problems? Any idea on how to overcome it or on how to dive deeper? Greetings Raffaello

Oct. 31, 2017

potentially useful diagrams

by Stephane Ducasse

Hi during the last sprint we were brainstorming how we can help people to understand the git hub setup. I produced these two diagrams with christophe. Are they useful for you? Stef

Oct. 31, 2017

Re: [Pharo-users] Pharo 6.1

by Marcus Denker

What actually happens is that moving (with the finder) a file to /Applications removes the com.apple.quarantine flag. you could try: xattr -d com.apple.quarantine <file> (this is related to signing, too, but not the signing of the app, but the container the files are downloaded. We need to use .dmg files and sign them on the build server). Marcus > On 31 Oct 2017, at 15:35, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Actually, it is in Applications > > Sent from the road > >> On Oct 31, 2017, at 02:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> >>> On 30 Oct 2017, at 20:30, Todd Blanchard <tblanchard(a)mac.com> wrote: >>> >>> I was just preparing a similar post. Just downloaded latest Pharo 6.1-64 for Mac >>> >>> I was greeted with a walkback when it failed to create directory /private/var/folders/ks/wg6l98bj64q6hgvs23wwqypr0000gn/T/AppTranslocation/DAA5EA3A-374D-4ADE-9E04-BBB7433BB6C8/d/Pharo6.1-64.app/Contents/Resources/pharo-local >>> >>> Definitely not the right directory to resolve pharo-local to. >> >> not related :) >> this is because you didnât put Pharo under /Applications as indicated when you download Pharo. >> at the same time, this is because we are still not signing Pharo, then apple moves it to a sandbox, which is bad. I have in my TODO signing the apps, but still no time to do it :/ >> >> Esteban >> >>> >>> -Todd Blanchard >>> >>>> On Oct 30, 2017, at 12:27 PM, ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð² <vikenti.potapov(a)gmail.com> wrote: >>>> >>>> >>>> I've just downloaded Pharo 6.1 from pharo.org, unzipped it and started. And i've got an error: >>>> "UTF8InvalidText: Invalid utf8 input detected" >>>> >>>> Whether i save image or not, every time i start it i get the same error. >>>> >>>> System: win 7 professional x64 on 6-core Athlon Phenom. >>>> Locale: russian (cyrillic). >>>> >>>> Can i fix it by myself or i should forget about 6.1 until global bugfix? >>>> >>>> Vikenti Potapov >>>> >>> >>> >> >> >

Oct. 31, 2017

Re: [Pharo-users] Pharo 6.1 - Apple signing

by Andrew Glynn

If it would be a help, I can sign the apps. Cheers Andrew From: Todd Blanchard Sent: Tuesday, October 31, 2017 10:36 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Pharo 6.1 Actually, it is in Applications Sent from the road > On Oct 31, 2017, at 02:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 30 Oct 2017, at 20:30, Todd Blanchard <tblanchard(a)mac.com> wrote: >> >> I was just preparing a similar post. Just downloaded latest Pharo 6.1-64 for Mac >> >> I was greeted with a walkback when it failed to create directory /private/var/folders/ks/wg6l98bj64q6hgvs23wwqypr0000gn/T/AppTranslocation/DAA5EA3A-374D-4ADE-9E04-BBB7433BB6C8/d/Pharo6.1-64.app/Contents/Resources/pharo-local >> >> Definitely not the right directory to resolve pharo-local to. > > not related :) > this is because you didnât put Pharo under /Applications as indicated when you download Pharo. > at the same time, this is because we are still not signing Pharo, then apple moves it to a sandbox, which is bad. I have in my TODO signing the apps, but still no time to do it :/ > > Esteban > >> >> -Todd Blanchard >> >>> On Oct 30, 2017, at 12:27 PM, ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð² <vikenti.potapov(a)gmail.com> wrote: >>> >>> >>> I've just downloaded Pharo 6.1 from pharo.org, unzipped it and started. And i've got an error: >>> "UTF8InvalidText: Invalid utf8 input detected" >>> >>> Whether i save image or not, every time i start it i get the same error. >>> >>> System: win 7 professional x64 on 6-core Athlon Phenom. >>> Locale: russian (cyrillic). >>> >>> Can i fix it by myself or i should forget about 6.1 until global bugfix? >>> >>> Vikenti Potapov >>> >> >> > >

Oct. 31, 2017

Re: [Pharo-users] What is code 137 / how to gracefully shut down via SIGTERM?

by Bruce O'Neel

Hi, Well, not so scary. Â That's the mac list. Â From a not so recent mac with Xcode 7 installed it looks like the below. The good news here is that the common signals have the same numbers. Â And how often do you get an SIGXCPU? cheers bruce #define SIGHUPÂ 1 Â Â Â /* hangup */ #define SIGINTÂ 2 Â Â Â /* interrupt */ #define SIGQUIT 3 Â Â Â /* quit */ #define SIGILLÂ 4 Â Â Â /* illegal instruction (not reset when caught) */ #define SIGTRAP 5 Â Â Â /* trace trap (not reset when caught) */ #define SIGABRT 6 Â Â Â /* abort() */ #define SIGPOLL 7 Â Â Â /* pollable event ([XSR] generated, not supported) */ #else Â /* (!_POSIX_C_SOURCE || _DARWIN_C_SOURCE) */ #define SIGIOTÂ SIGABRT /* compatibility */ #define SIGEMTÂ 7 Â Â Â /* EMT instruction */ #endifÂ /* (!_POSIX_C_SOURCE || _DARWIN_C_SOURCE) */ #define SIGFPEÂ 8 Â Â Â /* floating point exception */ #define SIGKILL 9 Â Â Â /* kill (cannot be caught or ignored) */ #define SIGBUSÂ 10Â Â Â /* bus error */ #define SIGSEGV 11Â Â Â /* segmentation violation */ #define SIGSYSÂ 12Â Â Â /* bad argument to system call */ #define SIGPIPE 13Â Â Â /* write on a pipe with no one to read it */ #define SIGALRM 14Â Â Â /* alarm clock */ #define SIGTERM 15Â Â Â /* software termination signal from kill */ #define SIGURGÂ 16Â Â Â /* urgent condition on IO channel */ #define SIGSTOP 17Â Â Â /* sendable stop signal not from tty */ #define SIGTSTP 18Â Â Â /* stop signal from tty */ #define SIGCONT 19Â Â Â /* continue a stopped process */ #define SIGCHLD 20Â Â Â /* to parent on child stop or exit */ #define SIGTTIN 21Â Â Â /* to readers pgrp upon background tty read */ #ifÂ (!defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)) #define SIGIO Â 23Â Â Â /* input/output possible signal */ #endif #define SIGXCPU 24Â Â Â /* exceeded CPU time limit */ #define SIGXFSZ 25Â Â Â /* exceeded file size limit */ #define SIGVTALRM 26Â Â /* virtual time alarm */ #define SIGPROF 27Â Â Â /* profiling time alarm */ #ifÂ (!defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)) #define SIGWINCH 28 Â Â /* window size changes */ #define SIGINFO 29Â Â Â /* information request */ #endif #define SIGUSR1 30Â Â Â /* user defined signal 1 */ #define SIGUSR2 31Â Â Â /* user defined signal 2 */ > Bruce O'Neel wrote: > > Hi, > > > > Posix requires that if the process is killed the return status is > > greater than 128. > > > > What is convention on linux systems is that if the process is sent a > > signal then the signal number is added to 128. Therefore 137 is SIGKILL > > (kill -9). SIGTERM is 143, SIGABRT is 134, SIGSEGV is 139, and so on. > > I've not seen an exception to this but there could be. > > > > Signals off of my closest linux system look like: > > > > #define SIGHUP 1 > > #define SIGINT 2 > > #define SIGQUIT 3 > > #define SIGILL 4 > > #define SIGTRAP 5 > > #define SIGABRT 6 > > #define SIGIOT 6 > > #define SIGBUS 7 > > #define SIGFPE 8 > > #define SIGKILL 9 > > #define SIGUSR1 10 > > #define SIGSEGV 11 > > #define SIGUSR2 12 > > #define SIGPIPE 13 > > #define SIGALRM 14 > > #define SIGTERM 15 > > Scary, because Esteban's sigtrapping package has them defined a bit > differently: > > { #category : #'class initialization' } > POSIXSignal class >> initialize [ > SIGHUP := 1. > SIGINT := 2. > SIGQUIT := 3. > SIGILL := 4. > SIGTRAP := 5. > SIGABRT := 6. > SIGPOLL := 7. > SIGIOT := SIGABRT. > SIGEMT := 7. > SIGFPE := 8. > SIGKILL := 9. > SIGBUS := 10. > SIGSEGV := 11. > SIGSYS := 12. > SIGPIPE := 13. > SIGALRM := 14. > SIGTERM := 15. > SIGURG := 16. > SIGSTOP := 17. > SIGTSTP := 18. > SIGCONT := 19. > SIGCHLD := 20. > SIGTTIN := 21. > SIGTTOU := 22. > SIGIO := 23. > SIGXCPU := 24. > SIGXFSZ := 25. > SIGVTALRM := 26. > SIGPROF := 27. > SIGWINCH := 28. > SIGINFO := 29. > SIGUSR1 := 30. > SIGUSR2 := 31. > ]

Oct. 31, 2017

Re: [Pharo-users] Pharo 6.1

by Todd Blanchard

Actually, it is in Applications Sent from the road > On Oct 31, 2017, at 02:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 30 Oct 2017, at 20:30, Todd Blanchard <tblanchard(a)mac.com> wrote: >> >> I was just preparing a similar post. Just downloaded latest Pharo 6.1-64 for Mac >> >> I was greeted with a walkback when it failed to create directory /private/var/folders/ks/wg6l98bj64q6hgvs23wwqypr0000gn/T/AppTranslocation/DAA5EA3A-374D-4ADE-9E04-BBB7433BB6C8/d/Pharo6.1-64.app/Contents/Resources/pharo-local >> >> Definitely not the right directory to resolve pharo-local to. > > not related :) > this is because you didnât put Pharo under /Applications as indicated when you download Pharo. > at the same time, this is because we are still not signing Pharo, then apple moves it to a sandbox, which is bad. I have in my TODO signing the apps, but still no time to do it :/ > > Esteban > >> >> -Todd Blanchard >> >>> On Oct 30, 2017, at 12:27 PM, ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð² <vikenti.potapov(a)gmail.com> wrote: >>> >>> >>> I've just downloaded Pharo 6.1 from pharo.org, unzipped it and started. And i've got an error: >>> "UTF8InvalidText: Invalid utf8 input detected" >>> >>> Whether i save image or not, every time i start it i get the same error. >>> >>> System: win 7 professional x64 on 6-core Athlon Phenom. >>> Locale: russian (cyrillic). >>> >>> Can i fix it by myself or i should forget about 6.1 until global bugfix? >>> >>> Vikenti Potapov >>> >> >> > >

Oct. 31, 2017

Re: [Pharo-users] What is code 137 / how to gracefully shut down via SIGTERM?

by Herby VojÄÃk

Bruce O'Neel wrote: > Hi, > > Posix requires that if the process is killed the return status is > greater than 128. > > What is convention on linux systems is that if the process is sent a > signal then the signal number is added to 128. Therefore 137 is SIGKILL > (kill -9). SIGTERM is 143, SIGABRT is 134, SIGSEGV is 139, and so on. > I've not seen an exception to this but there could be. > > Signals off of my closest linux system look like: > > #define SIGHUP 1 > #define SIGINT 2 > #define SIGQUIT 3 > #define SIGILL 4 > #define SIGTRAP 5 > #define SIGABRT 6 > #define SIGIOT 6 > #define SIGBUS 7 > #define SIGFPE 8 > #define SIGKILL 9 > #define SIGUSR1 10 > #define SIGSEGV 11 > #define SIGUSR2 12 > #define SIGPIPE 13 > #define SIGALRM 14 > #define SIGTERM 15 Scary, because Esteban's sigtrapping package has them defined a bit differently: { #category : #'class initialization' } POSIXSignal class >> initialize [ SIGHUP := 1. SIGINT := 2. SIGQUIT := 3. SIGILL := 4. SIGTRAP := 5. SIGABRT := 6. SIGPOLL := 7. SIGIOT := SIGABRT. SIGEMT := 7. SIGFPE := 8. SIGKILL := 9. SIGBUS := 10. SIGSEGV := 11. SIGSYS := 12. SIGPIPE := 13. SIGALRM := 14. SIGTERM := 15. SIGURG := 16. SIGSTOP := 17. SIGTSTP := 18. SIGCONT := 19. SIGCHLD := 20. SIGTTIN := 21. SIGTTOU := 22. SIGIO := 23. SIGXCPU := 24. SIGXFSZ := 25. SIGVTALRM := 26. SIGPROF := 27. SIGWINCH := 28. SIGINFO := 29. SIGUSR1 := 30. SIGUSR2 := 31. ]

Oct. 31, 2017

Re: [Pharo-users] What is code 137 / how to gracefully shut down via SIGTERM?

by Bruce O'Neel

Hi, Posix requires that if the process is killed the return status is greater than 128. What is convention on linux systems is that if the process is sent a signal then the signal number is added to 128. Â Therefore 137 is SIGKILL (kill -9). Â SIGTERM is 143, SIGABRT is 134, SIGSEGV is 139, and so on. Â I've not seen an exception to this but there could be. Signals off of my closest linux system look like: #define SIGHUP Â Â Â Â Â 1 #define SIGINT Â Â Â Â Â 2 #define SIGQUITÂ Â Â Â Â 3 #define SIGILL Â Â Â Â Â 4 #define SIGTRAPÂ Â Â Â Â 5 #define SIGABRTÂ Â Â Â Â 6 #define SIGIOT Â Â Â Â Â 6 #define SIGBUS Â Â Â Â Â 7 #define SIGFPE Â Â Â Â Â 8 #define SIGKILLÂ Â Â Â Â 9 #define SIGUSR1 Â Â Â Â 10 #define SIGSEGV Â Â Â Â 11 #define SIGUSR2 Â Â Â Â 12 #define SIGPIPE Â Â Â Â 13 #define SIGALRM Â Â Â Â 14 #define SIGTERM Â Â Â Â 15 SIGHUP is the phone hung up. Â SIGINT is interrupt (^C) SIGILL is you tried to execute an illegal instruction, SIGBUS is Bus error, normally you tried to read a 32 bit value on a non-32 bit boundary and uncommon on x86, SIGFPE is a floating point error, SIGKILL is too bad, you're dead, SIGSEGV is you tried to read/write memory that was not allowed, and SIGTERM is the normal "please exit" signal. cheers bruce > werner kassens wrote: > > Hi Herby, > > eventually you might want to look at > > https://github.com/moby/moby/issues/1063 > > but then i dont know anything about these things. > > Hopefully they have this solved already... but I learned 137 means > "killed". generally; did not know. :-) > > > werner > > Herby Hi,

Oct. 31, 2017

Re: [Pharo-users] Smalltalk Argument

by Hans

Hi all, an argument for Smalltalk, an discussion coming up many times in my history. It is also something I'm asking myself from time to time. It is very actual in the moment. Many good arguments were mentioned this discussion. I want to provide you my 2 cents on this. First, I'm taking the view of an hobby enthusiast. That's were I started. All the time I was excited by the Smalltalk concept. Live debugging, VM system, the possibility to look at and understand every code from systems completely new to me was so great. No installation, and nice people in the community. Conclusion: I want to do all in Smalltalk. Elegance is what rules only. Now, I'm in the perspective of an employed software developer. Everywhere that crazy C++, sometimes Fortran or C. Delphi. The people told "that's old, that was the beginning years ago, that is given, we have nothing else". And we have no time to redesign or port to something better, so fate catched us and we have to continue on the road to hell..... Most of my life colleagues were physicists who learned C++ for its thesis, or engineers of the embedded domain. No or only a few computer scientists. The rule now on these days: get ready, it should work somehow, costs. Elegance or sound design is no value. Not at this time. SW is just a part of my component as any screw and nail too. Continuing as a team leader. My goal is to fit budget. I have some time, and I have some people in the team. And I have to report and sell to my manager above me. I'm looking for get the job done, but I have also some strategic view. I've read some articles about this new .Net, with big potential, many libraries. Easy Web. Web is the future. I ask my team how to solve the task. Ony guy talks about Pearl. I hat Pearl. Another colleagues tells something about Smalltalk. Never heared of it, I ask if this is compatible to .Net.... My rules of success are in what I belief - and what can I sell to my big boss. And I belief only what I see... I could continue this. My point is: the Smalltalk Argument is depending on the perspective. And therefore, to communicate and argue about Smalltalk is what the receiver of the argument needs. Superiour technique can be an argument, but not always. Missing developer can be an argument, but not in every company and every project. My personal conclusion and look to Smalltalk is this: - for my soul which want to bring science and technology to the future, I look at the elegance and power of Smalltalk. That's why I'm looking at TeaTime and OpenCroquet again in the age of AR. - if I want to learn from top coders, the way of developing in Smalltalk (live debugging) - if I want to get a job done (for example a web site), I'm looking what the world offers me. And it may not be Smalltalk. In my current work, Game Engines matter. So coding a Game Engine in Smalltalk ? May be, but there are a lot of good products already... Having said that, the Smalltalk Argument has to sides, and they have both their value: - Smalltalk as an technique, as a matter of research and getting things better, an philosophy - Smalltalk as a product for people who want things get done. My personal opinion is that sometimes the point Smalltalk (or better now: Pharo) as a product is not so much in concern as it could. Pharo evolved wonderfully, the consortium and the organisation and the community have the right direction, yes. But as an industrial user of software I only can hope: keep the Smalltalk as a Product in the same focus as Smalltalk as the better technology. And product means: look at the needs the product is indented for, look at the "market". What are the problems out there ? If you can fit the needs, and provide a productive and integrable technology, you need no argument for Smalltalk. Off topic: thanks for the big effort of the community, it is really really fun today to work on and with Pharo. Much happend, and much is possible ;) Cheers Hans -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 31, 2017

Re: [Pharo-users] Smalltalk Argument

by Hans

Hi all, an argument for Smalltalk, an discussion coming up many times in my history. It is also something I'm asking myself from time to time. It is very actual in the moment. Many good arguments were mentioned this discussion. I want to provide you my 2 cents on this. First, I'm taking the view of an hobby enthusiast. That's were I started. All the time I was excited by the Smalltalk concept. Live debugging, VM system, the possibility to look at and understand every code from systems completely new to me was so great. No installation, and nice people in the community. Conclusion: I want to do all in Smalltalk. Elegance is what rules only. Now, I'm in the perspective of an employed software developer. Everywhere that crazy C++, sometimes Fortran or C. Delphi. The people told "that's old, that was the beginning years ago, that is given, we have nothing else". And we have no time to redesign or port to something better, so fate catched us and we have to continue on the road to hell..... Most of my life colleagues were physicists who learned C++ for its thesis, or engineers of the embedded domain. No or only a few computer scientists. The rule now on these days: get ready, it should work somehow, costs. Elegance or sound design is no value. Not at this time. SW is just a part of my component as any screw and nail too. Continuing as a team leader. My goal is to fit budget. I have some time, and I have some people in the team. And I have to report and sell to my manager above me. I'm looking for get the job done, but I have also some strategic view. I've read some articles about this new .Net, with big potential, many libraries. Easy Web. Web is the future. I ask my team how to solve the task. Ony guy talks about Pearl. I hat Pearl. Another colleagues tells something about Smalltalk. Never heared of it, I ask if this is compatible to .Net.... My rules of success are in what I belief - and what can I sell to my big boss. And I belief only what I see... I could continue this. My point is: the Smalltalk Argument is depending on the perspective. And therefore, to communicate and argue about Smalltalk is what the receiver of the argument needs. Superiour technique can be an argument, but not always. Missing developer can be an argument, but not in every company and every project. My personal conclusion and look to Smalltalk is this: - for my soul which want to bring science and technology to the future, I look at the elegance and power of Smalltalk. That's why I'm looking at TeaTime and OpenCroquet again in the age of AR. - if I want to learn from top coders, the way of developing in Smalltalk (live debugging) - if I want to get a job done (for example a web site), I'm looking what the world offers me. And it may not be Smalltalk. In my current work, Game Engines matter. So coding a Game Engine in Smalltalk ? May be, but there are a lot of good products already... Having said that, the Smalltalk Argument has to sides, and they have both their value: - Smalltalk as an technique, as a matter of research and getting things better, an philosophy - Smalltalk as a product for people who want things get done. My personal opinion is that sometimes the point Smalltalk (or better now: Pharo) as a product is not so much in concern as it could. Pharo evolved wonderfully, the consortium and the organisation and the community have the right direction, yes. But as an industrial user of software I only can hope: keep the Smalltalk as a Product in the same focus as Smalltalk as the better technology. And product means: look at the needs the product is indented for, look at the "market". What are the problems out there ? If you can fit the needs, and provide a productive and integrable technology, you need no argument for Smalltalk. Off topic: thanks for the big effort of the community, it is really really fun today to work on and with Pharo. Much happend, and much is possible ;) Cheers Hans -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 31, 2017

Re: [Pharo-users] Pharo 6.1

by Esteban Lorenzano

> On 30 Oct 2017, at 20:30, Todd Blanchard <tblanchard(a)mac.com> wrote: > > I was just preparing a similar post. Just downloaded latest Pharo 6.1-64 for Mac > > I was greeted with a walkback when it failed to create directory /private/var/folders/ks/wg6l98bj64q6hgvs23wwqypr0000gn/T/AppTranslocation/DAA5EA3A-374D-4ADE-9E04-BBB7433BB6C8/d/Pharo6.1-64.app/Contents/Resources/pharo-local > > Definitely not the right directory to resolve pharo-local to. not related :) this is because you didnât put Pharo under /Applications as indicated when you download Pharo. at the same time, this is because we are still not signing Pharo, then apple moves it to a sandbox, which is bad. I have in my TODO signing the apps, but still no time to do it :/ Esteban > > -Todd Blanchard > >> On Oct 30, 2017, at 12:27 PM, ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð² <vikenti.potapov(a)gmail.com> wrote: >> >> >> I've just downloaded Pharo 6.1 from pharo.org, unzipped it and started. And i've got an error: >> "UTF8InvalidText: Invalid utf8 input detected" >> >> Whether i save image or not, every time i start it i get the same error. >> >> System: win 7 professional x64 on 6-core Athlon Phenom. >> Locale: russian (cyrillic). >> >> Can i fix it by myself or i should forget about 6.1 until global bugfix? >> >> Vikenti Potapov >> > >

Oct. 31, 2017

Re: [Pharo-users] QCMagritte on Github

by laurent

Hi Diego, we used this process to migrate: https://github.com/peteruhnak/git-migration. So we have all history of QCMagritte (including ConfigurationOf). We created the BaselineOf but it only loads latest packages (see https://github.com/Afibre/QCMagritte/blob/master/src/BaselineOfQCMagritte.p… ). So there should be made branches for the different Pharo versions. If you give me your github I can give you write access to the github repository. Laurent Le dim. 29 oct. 2017 Ã 13:42, Diego Lont <diego.lont(a)delware.nl> a Ã©crit : > Hi, > > It was somewhere on my todo list to migrate to Github, but not very > highâ¦ > > but I guess if someone else does this for me, I should be happy about > this. > > So thank you, I will look up my gut hub account and also change the > job. I hope to do this somewhere next week. > > I know there a different configurations for different versions of > pharo, so did you import only one version, or should there be made > branches for the different pharo version? > > Regards, > Diego > >> On 27 Oct 2017, at 16:50, laurent laffont >> <laurent.laffont(a)gmail.com> wrote: >> >> I've added loading instructions in README: >> >> Metacello new >> githubUser: 'Afibre' project: 'QCMagritte' commitish: 'master' >> path: 'src'; >> baseline: 'QCMagritte'; >> load. >> >> >> For the QCMagritte version, there's actually one branch master. If >> you >> need a previous version, I suppose the right way is to create a >> github >> branch from the desired commit in git history and adapt the >> BaselineOf... >> >> Laurent >> >> On Fri, Oct 27, 2017 at 2:12 PM, HernÃ¡n Morales Durand >> <hernan.morales(a)gmail.com> wrote: >>> Nice to know Laurent, >>> >>> Could you please comment or share how to install this version >>> uploaded >>> to GitHub? >>> Any way to check the installed or current QCMagritte version? >>> >>> Cheers, >>> >>> HernÃ¡n >>> >>> >>> >>> >>> 2017-10-27 7:39 GMT-03:00 laurent laffont >>> <laurent.laffont(a)gmail.com>: >>>> Hi, >>>> >>>> my team starts to use QCMagritte. For our needs we have imported >>>> SmalltalkHub repository to Github here: >>>> https://github.com/Afibre/QCMagritte >>>> >>>> I don't know if you (Diego, Stephan, Tobias) plan to use Github >>>> instead of SmalltalkHub. At least Github allows branches & pull >>>> request. >>>> >>>> Regards, >>>> >>>> Laurent Laffont >>>> >>> >> > >

Oct. 31, 2017

Re: [Pharo-users] UK Smalltalk User Group Meeting - Monday, October 30th - PharoLambda: Smalltalk running serverless on AWS

by Tim Mackinnon

I promised to give a little summary of the meetup. After some initial âsmalltalkâ (in the talking sense - where we covered chrome books, cloud development, squeakjs and how you might develop in smalltalk on a Chromebook in a web worldâ¦. I did say smalltalk right)â¦. I did a quick intro to the components of writing a traditional Alexa Skill and Lambda functions on AWS using Node JSâ¦ this wasnât Smalltalk related but it set the context of what the environment is like and was quite interesting to the group to give some some background. We had some interesting side conversations on the social aspects of having a device like an Echo Dot in your living room (is it like the revolution weâve had with phones? Does it feel natural etc). Some interesting debate on this. Then we covered how the recentâish advancement with an OpenSmalltalk 64bit vm have given the ability to easily run Smalltalk no Lambda where you donât have a lot of control on what is installed on your target instance (essentially you upload a zip file of your environment) We then walked through the GitLab CI/build system I used to automatically create a zip file to upload (the minimal image work done here was the power behind this - and GitLab ci is quite a nice build system that is fast/efficient and simple to use). Then the real eye-opener was looking at the small amount of code needed to create a service (not so amazing actually) - but the kicker being the implications of how you can easily debug a failed service. This got the conversation flowing. The 2 interesting points that came out: - restarting a failed service (and being able to keep restarting it in a debugger) is neat - but services often have other elements like a database or other service that also need rewinding. Given the tiny amount of code that I showed that serialises the context to S3 (again, sponsored by this community - thanks) its not unimaginable to snapshot a database and be able to restore it when you dematerialise your execution context (and also do it again if you decide to restart again). These are things developers in other communities donât even dream of doing it seems. (As a side point - how hard would it be for our debugger to truly let you rewind memory when you step back in the stack?) - AWS feels like a new operating system. And just like we handle restoring windows and other resources on an OS like windows - should we be viewing AWS as a similar thing we should run on (albeit in a slightly different way). But can our tooling/environment make for a more pleasant and cohesive view on top of a cloud OS? It feels like it could somehow. - Another side point - I recall early demos of IBM distributed smalltalk where you could literally highlight nodes of execution that were slow because they were far apart and just drag them near to each other so that message calls didnât have the same network latency. This feels like the new cloud world might benefit from some of these old ideasâ¦ not sure if there are any video of this in action to inspire people. Anyway - not sure if any of this is useful to anyone reading, but it may be a reminder to me of things to follow up on. Tim > On 27 Oct 2017, at 17:58, Tim Mackinnon <tim(a)testit.works> wrote: > > Thanks Sean - hoping to do a bit of deeper dive into the Screencast I posted a while back - but Iâm also hoping we can get some discussion around the kinds of things we can do with serverless that match the strengths of Smalltalk. > > Iâve got a few ideas - but wondering what others think - and weâll share the results here. > > Tim > > NOTE for anyone that is coming and is reading this: Weâve had to change the venue to the pub around the corner - The Crown Tavern. > >> On 27 Oct 2017, at 16:31, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Tim Mackinnon wrote >>> Tim Mackinnon will showâ¦ >> >> So jealous! That sounds like an awesome presentation :) >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > >

Oct. 31, 2017

Re: [Pharo-users] Pharo 6.1

by Ben Coman

On Tue, Oct 31, 2017 at 3:27 AM, ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð² <vikenti.potapov(a)gmail.com > wrote: > > I've just downloaded Pharo 6.1 from pharo.org, unzipped it and started. > And i've got an error: > "UTF8InvalidText: Invalid utf8 input detected" > > Whether i save image or not, every time i start it i get the same error. > > System: win 7 professional x64 on 6-core Athlon Phenom. > Locale: russian (cyrillic). > > Can i fix it by myself or i should forget about 6.1 until global bugfix? > > Vikenti Potapov > > I downloaded yesterday and again just now and no problem unzipping and running. URL: http://files.pharo.org/platform/Pharo6.1-win.zip System: Win 10 Professional x64 What folder do you unzip into? Does it contain any non-ASCII characters? Double check copy-pasting into somewhere like http://asciivalue.com/ Could you create folder C:\Pharo ensuring all ASCII characters, and try unzipping into there? cheers -ben

Oct. 31, 2017

Re: [Pharo-users] Pharo 6.1

by Todd Blanchard

I was just preparing a similar post. Just downloaded latest Pharo 6.1-64 for Mac I was greeted with a walkback when it failed to create directory /private/var/folders/ks/wg6l98bj64q6hgvs23wwqypr0000gn/T/AppTranslocation/DAA5EA3A-374D-4ADE-9E04-BBB7433BB6C8/d/Pharo6.1-64.app/Contents/Resources/pharo-local Definitely not the right directory to resolve pharo-local to. -Todd Blanchard > On Oct 30, 2017, at 12:27 PM, ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð² <vikenti.potapov(a)gmail.com> wrote: > > > I've just downloaded Pharo 6.1 from pharo.org, unzipped it and started. And i've got an error: > "UTF8InvalidText: Invalid utf8 input detected" > > Whether i save image or not, every time i start it i get the same error. > > System: win 7 professional x64 on 6-core Athlon Phenom. > Locale: russian (cyrillic). > > Can i fix it by myself or i should forget about 6.1 until global bugfix? > > Vikenti Potapov >

Oct. 30, 2017

Pharo 6.1

by ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð²

I've just downloaded Pharo 6.1 from pharo.org, unzipped it and started. And i've got an error: "UTF8InvalidText: Invalid utf8 input detected" Whether i save image or not, every time i start it i get the same error. System: win 7 professional x64 on 6-core Athlon Phenom. Locale: russian (cyrillic). Can i fix it by myself or i should forget about 6.1 until global bugfix? Vikenti Potapov

Oct. 30, 2017

Microsoft COM

by Ben Coman

Hi Pablo, At work I managed to remote control Internet Explorer with Excel VBA like this... [1] http://www.automateexcel.com/vba/automate-internet-explorer and went looking for how similar might be achieved from Pharo. IIUC I discovered this would be done via Microsoft's Component Object Model, and then I bumped into your repo... [2] https://github.com/tesonep/pharo-com Could you advise the status and your plans for this? Since I see its only a few months old I've probably stumbled onto it prematurely, but I see no documentation or tests to discover how to use it. So I'll curious whether it makes something like [1] possible? And could you show how that would be done? cheers -ben P.S. For context, at work I automated IE since the intranet document management system (OpenText) does authentication via a javascript function in the browser, which doesn't compute with Microsoft's MSXML.DOMDocument component. So I use IE to do the authentication and grab the raw XML from IE to then stuff it into MSXML.DOMDocument from which I pull the data I need. But I'd love to do it with Pharo instead (if I can get IT to white list it) cheers -ben

Oct. 30, 2017

Re: [Pharo-users] Return value of a FFI call to a external function is its 2`s complement

by Paulo R. Dellani

Hi Pablo, correcting the type declaration in the ffiCall solved the problem, thanks! Cheers, Paulo On 10/30/2017 05:24 PM, tesonep(a)gmail.com wrote: > Hi,Â > Â the problem is that the Zq function has the following signature: > > int zmq_msg_recv (zmq_msg_t *msg, void *socket, int flags); > > And in your ffiCall you are putting #long.Â > > You should use the correct size of integers, as the binary numbers > need to extend the size when they are negatives.Â > > 0xFFFFFFFF is a valid positive for a long, but a -1 for an int.Â > > Cheers. > > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com>

Oct. 30, 2017

Re: [Pharo-users] Return value of a FFI call to a external function is its 2`s complement

by tesonep＠gmail.com

Hi, the problem is that the Zq function has the following signature: int zmq_msg_recv (zmq_msg_t *msg, void *socket, int flags); And in your ffiCall you are putting #long. You should use the correct size of integers, as the binary numbers need to extend the size when they are negatives. 0xFFFFFFFF is a valid positive for a long, but a -1 for an int. Cheers. On Mon, Oct 30, 2017 at 4:26 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Ah ok I know that one, just did not know it was named "two's complement" , > looks to me normal error. I have seen this value many times in case of > errors while debugging C code with GBP > > It returns error probably because of the reason I outlined in my previous > reply. > > On Mon, Oct 30, 2017 at 3:51 PM Paulo R. Dellani <dellani(a)pobox.com> > wrote: > >> "Two`s complement" is one possible way to represent signed integers in >> binary form (1). >> >> When the message apiZmqMsgRecv: message socket: socket withFlags: flags is >> sent, as >> shown in my prior message, a function from libzmq, zmq_msg_recv (2) is >> called >> and the return value should be either the number of bytes in the received >> message >> or -1, in case of an error. Well, I was expecting to get a -1 as return >> value when >> calling the function in non-blocking mode, but it returns 0xFFFFFFFF, >> which happens >> to be the 2's complement representation of -1. At least the old code for >> libZMQ >> was not expecting that. >> >> Cheers, Paulo >> >> (1) https://en.wikipedia.org/wiki/Two's_complement >> (2) http://api.zeromq.org/4-2:zmq-msg-recv >> >> >> On 10/30/2017 02:13 PM, Dimitris Chloupis wrote: >> >> >> I have no idea what you mean by "2's complement" >> >> In any case bare in mind that UFFI has a limited range of C types that >> does support. Here you use 2 custom types , ZmqApiMessage and ZmqApiSocket >> , both are pointers because of * . Now these types are definetly not >> included with UFFI so if you have not done so you will have to >> >> 1) Define a class that inherits from FFIExternalObject and make sure your >> class handles the pointer properly >> 2) Replace the custom type with an equivelant type that is supported by >> UFFI >> >> The type of the pointer does not affect the pointer itself, usually, but >> rather the data it points to. So a pointer knows from it type that the data >> consumes a x amount of bytes and is of specific type , this can help also >> with indexing as C arrays are nothing more than a pointer that uses the >> index as an offset depending on its type of x amount of bytes. >> >> So its crucial that you get these right or else you going have some super >> weird results and even crashes. >> >> Because if you use improper types the pointer will give access to an area >> of memory bigger or smaller than the inteded type . Smaller will give you >> corrupted data (you will be missing bytes of data), bigger may crash >> because it may extend to area of memory not allowed to access. >> >> Technically speaking you can use even incorrect types if you know what >> you doing because UFFI pointers have great flexibility allowing you define >> real time the excact position of the memory and the range. >> >> Bare in mind that C is a high level language (and not low level as many >> incorrect assume) and deal with types that is NOT a low level concept >> (excepts types that have to do only with the size/ amount of bits) . So the >> type gives crucial information to C how exactly to access the memory. >> On Mon, Oct 30, 2017 at 2:03 PM Paulo R. Dellani <dellani(a)pobox.com> >> wrote: >> >>> Dear uFFI experts, >>> >>> I am dealing with the port of the ZeroMQ >>> <http://smalltalkhub.com/#%21/%7Epanuw/zeromq> code to Pharo 6 and >>> found >>> something unexpected to me, at least: >>> >>> Zmq4Api>>apiZmqMsgRecv: message socket: socket withFlags: flags >>> ^ self ffiCall: #(long zmq_msg_recv (ZmqApiMessage* message, >>> ZmqApiSocket* socket, long flags ) ) >>> >>> Calling this returns the 2's complement of the return value >>> of the external function call. Is it expected that the code calling >>> this do the decoding of the 2'complement representation of >>> the return value? >>> >>> Cheers, >>> >>> Paulo >>> >> >> -- Pablo Tesone. tesonep(a)gmail.com

Oct. 30, 2017

Re: [Pharo-users] Return value of a FFI call to a external function is its 2`s complement

by Dimitris Chloupis

Ah ok I know that one, just did not know it was named "two's complement" , looks to me normal error. I have seen this value many times in case of errors while debugging C code with GBP It returns error probably because of the reason I outlined in my previous reply. On Mon, Oct 30, 2017 at 3:51 PM Paulo R. Dellani <dellani(a)pobox.com> wrote: > "Two`s complement" is one possible way to represent signed integers in > binary form (1). > > When the message apiZmqMsgRecv: message socket: socket withFlags: flags is > sent, as > shown in my prior message, a function from libzmq, zmq_msg_recv (2) is > called > and the return value should be either the number of bytes in the received > message > or -1, in case of an error. Well, I was expecting to get a -1 as return > value when > calling the function in non-blocking mode, but it returns 0xFFFFFFFF, > which happens > to be the 2's complement representation of -1. At least the old code for > libZMQ > was not expecting that. > > Cheers, Paulo > > (1) https://en.wikipedia.org/wiki/Two's_complement > (2) http://api.zeromq.org/4-2:zmq-msg-recv > > > On 10/30/2017 02:13 PM, Dimitris Chloupis wrote: > > > I have no idea what you mean by "2's complement" > > In any case bare in mind that UFFI has a limited range of C types that > does support. Here you use 2 custom types , ZmqApiMessage and ZmqApiSocket > , both are pointers because of * . Now these types are definetly not > included with UFFI so if you have not done so you will have to > > 1) Define a class that inherits from FFIExternalObject and make sure your > class handles the pointer properly > 2) Replace the custom type with an equivelant type that is supported by > UFFI > > The type of the pointer does not affect the pointer itself, usually, but > rather the data it points to. So a pointer knows from it type that the data > consumes a x amount of bytes and is of specific type , this can help also > with indexing as C arrays are nothing more than a pointer that uses the > index as an offset depending on its type of x amount of bytes. > > So its crucial that you get these right or else you going have some super > weird results and even crashes. > > Because if you use improper types the pointer will give access to an area > of memory bigger or smaller than the inteded type . Smaller will give you > corrupted data (you will be missing bytes of data), bigger may crash > because it may extend to area of memory not allowed to access. > > Technically speaking you can use even incorrect types if you know what you > doing because UFFI pointers have great flexibility allowing you define real > time the excact position of the memory and the range. > > Bare in mind that C is a high level language (and not low level as many > incorrect assume) and deal with types that is NOT a low level concept > (excepts types that have to do only with the size/ amount of bits) . So the > type gives crucial information to C how exactly to access the memory. > On Mon, Oct 30, 2017 at 2:03 PM Paulo R. Dellani <dellani(a)pobox.com> > wrote: > >> Dear uFFI experts, >> >> I am dealing with the port of the ZeroMQ >> <http://smalltalkhub.com/#%21/%7Epanuw/zeromq> code to Pharo 6 and found >> something unexpected to me, at least: >> >> Zmq4Api>>apiZmqMsgRecv: message socket: socket withFlags: flags >> ^ self ffiCall: #(long zmq_msg_recv (ZmqApiMessage* message, >> ZmqApiSocket* socket, long flags ) ) >> >> Calling this returns the 2's complement of the return value >> of the external function call. Is it expected that the code calling >> this do the decoding of the 2'complement representation of >> the return value? >> >> Cheers, >> >> Paulo >> > >

Oct. 30, 2017

Re: [Pharo-users] Return value of a FFI call to a external function is its 2`s complement

by Paulo R. Dellani

"Two`s complement" is one possible way to represent signed integers in binary form (1). When the message apiZmqMsgRecv: message socket: socket withFlags: flagsis sent, as shown in my prior message, a function from libzmq, zmq_msg_recv (2) is called and the return value should be either the number of bytes in the received message or -1, in case of an error. Well, I was expecting to get a -1 as return value when calling the function in non-blocking mode, but it returns 0xFFFFFFFF, which happens to be the 2's complement representation of -1. At least the old code for libZMQ was not expecting that. Cheers, Paulo (1) https://en.wikipedia.org/wiki/Two's_complement (2) http://api.zeromq.org/4-2:zmq-msg-recv On 10/30/2017 02:13 PM, Dimitris Chloupis wrote: > > I have no idea what you mean by "2's complement"Â > > In any case bare in mind that UFFI has a limited range of C types that > does support. Here you use 2 custom types , ZmqApiMessage and > ZmqApiSocket , both are pointers because of * . Now these types are > definetly not included with UFFI so if you have not done so you will > have to > Â > 1) Define a class that inherits from FFIExternalObject and make sure > your class handles the pointer properlyÂ > 2) Replace the custom type with an equivelant type that is supported > by UFFI > > The type of the pointer does not affect the pointer itself, usually, > but rather the data it points to. So a pointer knows from it type that > the data consumes a x amount of bytes and is of specific type , this > can help also with indexing as C arrays are nothing more than a > pointer that uses the index as an offset depending on its type of x > amount of bytes.Â > > So its crucial that you get these right or else you going have some > super weird results and even crashes.Â > > Because if you use improper types the pointer will give access to an > area of memory bigger or smaller than the inteded type . Smaller will > give you corrupted data (you will be missing bytes of data), bigger > may crash because it may extend to area of memory not allowed to access.Â > > Technically speaking you can use even incorrect types if you know what > you doing because UFFI pointers have great flexibility allowing you > define real time the excact position of the memory and the range.Â > > Bare in mind that C is a high level language (and not low level as > many incorrect assume) and deal with types that is NOT a low level > concept (excepts types that have to do only with the size/ amount of > bits) . So the type gives crucial information to C how exactly to > access the memory.Â > On Mon, Oct 30, 2017 at 2:03 PM Paulo R. Dellani <dellani(a)pobox.com > <mailto:dellani@pobox.com>> wrote: > > Dear uFFI experts, > > I am dealing with the port of the ZeroMQ > <http://smalltalkhub.com/#%21/%7Epanuw/zeromq> code to Pharo 6 and > found > something unexpected to me, at least: > > Zmq4Api>>apiZmqMsgRecv: message socket: socket withFlags: flags > Â Â Â ^ self ffiCall: #(long zmq_msg_recv (ZmqApiMessage* message, > ZmqApiSocket* socket, long flags ) ) > > Calling this returns the 2's complement of the return value > of the external function call. Is it expected that the code calling > this do the decoding of the 2'complement representation of > the return value? > > Cheers, > > Paulo >

Oct. 30, 2017

Re: [Pharo-users] Return value of a FFI call to a external function is its 2`s complement

by Dimitris Chloupis

I have no idea what you mean by "2's complement" In any case bare in mind that UFFI has a limited range of C types that does support. Here you use 2 custom types , ZmqApiMessage and ZmqApiSocket , both are pointers because of * . Now these types are definetly not included with UFFI so if you have not done so you will have to 1) Define a class that inherits from FFIExternalObject and make sure your class handles the pointer properly 2) Replace the custom type with an equivelant type that is supported by UFFI The type of the pointer does not affect the pointer itself, usually, but rather the data it points to. So a pointer knows from it type that the data consumes a x amount of bytes and is of specific type , this can help also with indexing as C arrays are nothing more than a pointer that uses the index as an offset depending on its type of x amount of bytes. So its crucial that you get these right or else you going have some super weird results and even crashes. Because if you use improper types the pointer will give access to an area of memory bigger or smaller than the inteded type . Smaller will give you corrupted data (you will be missing bytes of data), bigger may crash because it may extend to area of memory not allowed to access. Technically speaking you can use even incorrect types if you know what you doing because UFFI pointers have great flexibility allowing you define real time the excact position of the memory and the range. Bare in mind that C is a high level language (and not low level as many incorrect assume) and deal with types that is NOT a low level concept (excepts types that have to do only with the size/ amount of bits) . So the type gives crucial information to C how exactly to access the memory. On Mon, Oct 30, 2017 at 2:03 PM Paulo R. Dellani <dellani(a)pobox.com> wrote: > Dear uFFI experts, > > I am dealing with the port of the ZeroMQ > <http://smalltalkhub.com/#%21/%7Epanuw/zeromq> code to Pharo 6 and found > something unexpected to me, at least: > > Zmq4Api>>apiZmqMsgRecv: message socket: socket withFlags: flags > ^ self ffiCall: #(long zmq_msg_recv (ZmqApiMessage* message, > ZmqApiSocket* socket, long flags ) ) > > Calling this returns the 2's complement of the return value > of the external function call. Is it expected that the code calling > this do the decoding of the 2'complement representation of > the return value? > > Cheers, > > Paulo >

Oct. 30, 2017

Re: [Pharo-users] Return value of a FFI call to a external function is its 2`s complement

by Paulo R. Dellani

P.S.: some details of the setup follow. pharo --version: 5.0-201707201942Â Thu Jul 20 20:40:54 UTC 2017 gcc 4.6.3 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Linux testing-gce-74d10329-bbfd-42e5-8995-b0e3a68c73cb 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /opt/smalltalk/pharo6.1/pharo-vm/lib/pharo/5.0-201707201942 [default: /opt/smalltalk/pharo6.1/pharo-vm/lib/pharo/5.0-201707201942/] uname -a Linux neutrino 4.13.8-100.fc25.x86_64 #1 SMP Wed Oct 18 17:10:31 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux On 10/30/2017 01:02 PM, Paulo R. Dellani wrote: > Dear uFFI experts, > > I am dealing with the port of the ZeroMQ > <http://smalltalkhub.com/#%21/%7Epanuw/zeromq> code to Pharo 6 and found > something unexpected to me, at least: > > Zmq4Api>>apiZmqMsgRecv: message socket: socket withFlags: flags > Â Â Â ^ self ffiCall: #(long zmq_msg_recv (ZmqApiMessage* message, > ZmqApiSocket* socket, long flags ) ) > > Calling this returns the 2's complement of the return value > of the external function call. Is it expected that the code calling > this do the decoding of the 2'complement representation of > the return value? > > Cheers, > > Paulo

Oct. 30, 2017

Return value of a FFI call to a external function is its 2`s complement

by Paulo R. Dellani

Dear uFFI experts, I am dealing with the port of the ZeroMQ <http://smalltalkhub.com/#%21/%7Epanuw/zeromq> code to Pharo 6 and found something unexpected to me, at least: Zmq4Api>>apiZmqMsgRecv: message socket: socket withFlags: flags Â Â Â ^ self ffiCall: #(long zmq_msg_recv (ZmqApiMessage* message, ZmqApiSocket* socket, long flags ) ) Calling this returns the 2's complement of the return value of the external function call. Is it expected that the code calling this do the decoding of the 2'complement representation of the return value? Cheers, Paulo

Oct. 30, 2017

Re: [Pharo-users] The start of this article is a problem for me. I hope this can be re-thought.

by David Mason

Hear! Hear! To be fair, the person who wrote the article has no direct role in the Amber team (or Pharo, or PharoJS), he is simply a Smalltalk fan who is trying to help build the community. But you make an excellent point.! On 29 October 2017 at 17:17, PAUL DEBRUICKER <pdebruic(a)gmail.com> wrote: > https://medium.com/smalltalk-talk/a-gentle-introduction-to- > amber-8c532631e9ab > > > > Smalltalk is a programming language/environment etc. Physical > attractiveness of people doesn't really affect anything we're doing here. > And using it for marketing is offensive a significant number of people. > I'm hopeful we can do better as a community. >

Oct. 29, 2017

Re: [Pharo-users] Smalltalk Argument

by Offray Vladimir Luna CÃ¡rdenas

Read the User Manual [1] to install it and learn the basics of its workings. Once you have created your first document or hit the first bump, ask on this list. I will be around ;-). [1] http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Manual/ma… Cheers, Offray On 29/10/17 17:00, henry wrote: > How could I get started documenting my components with Grafoscopio? I > am interested in learning. > > I just got ASN.1 lengths right, in Java. I am looking to Pharo and > Java with an encrypted connection between them. > > > - HH > > > On Sun, Oct 29, 2017 at 16:59, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <%22mailto:offray.luna@mutabit.com%22>> wrote: > > Well is more "build and they will come, if you build also a > community who will come", which is hard, but data storytelling and > visualization as filed and dynamic moldable tools give us a > advantage point to tackle such hard problems. > > Cheers, > > Offray > > > On 29/10/17 13:13, henry wrote: > > I have heard this summarized by the term: "build it and they > will come". I think the data visualization aspect is where > Pharo entering BigData space could really payoff. That comes > down to data manipulation. Can Pharo read Avro? > > - HH > > > On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna CÃ¡rdenas < > offray.luna(a)mutabit.com > <%22mailto:offray.luna@mutabit.com%22>> wrote: > > Thanks a lot Paulo for starting this thread and all the > participants for the clever and enlightening answers. I > just want to add my two cents. On 26/10/17 07:53, Dimitris > Chloupis wrote: > > My personal opinion is that as > pessimistic it may sound, Smalltalk has > very little to > offer in the library front. The language is still > > stellar and live environment is a great concept but from > there on > there is a decline. Sure if your are low demand > kind of person on the > library front and dont mind > implementing stuff by yourself you wont > mind the lack of > libraries but most coders , me included , dont have > this > luxury. Especially making a living with a language is a > > completely different story from learning it as a hobby,Â > > > I think and thatâs a personal opinion, that Smalltalk > goes the wrong > direction. It tries to be a do it all > language, but we already have an > army of do it all > languages. I think it would excel as the backbone in > big > complex projects. Like the Moose project is doing with > code > analysis and visualization. I think this is an > excellent direction to > go with Smalltalk. Reflection is > the big strength of Smalltalk the > ability to communicate > with its code in a direct matter. So I think > that a > Smalltalk implementation that can analyze and visualize > code > written in other languages would have been a pretty > serious reason for > people to learn Smalltalk.Â > > I am > very happy to see Pharo go towards that direction and yes > I would > definitely recommend it without hesitationÂ for > code analysis and > project management tool. Its no > coincidence that we have seen a > serious growth in our > community. When I joined back in 2011 we all > were > posting at pharo-dev, pharo-users was a dead zone and then > the > community grow larger and larger we soon may need a > third mailing list.Â > > Code complexity is an issues for > all large projects and tools that > help manage this > without having to convert to another language are > very > popular. About findingÂ niche where you can learn Pharo > and make a living from it, I think that I may be behind a > sweet spot in the field of reproducible research and data > storytelling and visualization, for different fields like > activism, journalism, science and engineering. Iâm > "working in my PhD", so I donât get paid for using Pharo & > friends (well if fact Iâm in a loan to finish my PhD), but > using Pharo have allowed my to get more dynamic results > that with previous technologies (mostly Python and Web > ones). By being able to prototype quickly I have improved > my research experience and results, which is a way to > improve research (self) funding. Also, activists, > journalist, researchers and other novices interested in > data storytelling and visualization, care little about > popularity of the language or being able to make apps > (mobile or web). What they care is about being able to > tell the story and Pharo, agile visualization and moldable > tools, have a lot to offer in this front. Theyâre easy to > learn and to adapt to fit the needs of the problems behind > those stories, as we have done with Grafoscopio[1]. So, is > nice to be part of a "trend", (data science, reproducible > research, data storytelling and data visualization) but > not being part of one that doesnât give you the freedom to > use tools that matter to you, because of the ideas they > embody and the added value they create for you and your > community. [1] > http://mutabit.com/grafoscopio/index.en.html Also, being > in Latin America, means that we can bootstrap ourselves > into alternative futures by using alternative (digital) > infrastructures and tools, without to much worry about the > deep investments in money and/or expertise on > bloated/popular technologies (we donât have such > investments here!). We can learn from the experience of > the "Global North", without following that path, but by > taking a critical approach to it (for example regarding > overcomplex, non-dynamic, bloated technologies). On the > community front, I think is important to do something to > break the circular logic of popularity: Smalltalk is > unpopular, so we donât get developers, so we donât have > libraries, and this makes such tech unpopular. Weâre a > nascent community of data storytellers and activists > learning how to use Pharo to tell our voices and how to > modify the tools to tell them in more potent/fluid ways. > We have done this mostly by ourselves, without any support > from industry or government and mostly none from academy. > Despite of the fragility of our hackerspace[2], this has > been done in a consistent way since almost two years[3] (I > started to learn Pharo, in a sparse way, 3 years ago). So, > there are ways to break the circular logic and bootstrap > communities around the advantages of the Pharo/Smalltalk > environment in places where it can be aligned to the > trends but also take a critical approach to them by > providing added value. [2] http://hackbo.co/ [3] > http://mutabit.com/dataweek/ So finding a niche and > bootstrapping tools and communities in it, seems a way to > deploy the Smalltalk Argument by example into the world, > which is a pretty powerful way to argument against > skeptics. Cheers, Offray > >

Oct. 29, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

Interesting. Very. Thank you. - HH On Sun, Oct 29, 2017 at 17:17, phil(a)highoctane.be <[phil(a)highoctane.be]("mailto:phil@highoctane.be")> wrote: > Pharo can read Avro when this will be UFFI'ed > > [https://avro.apache.org/docs/1.7.3/api/c/index.html]("https://avro.apache.org/docs/1.7.3/api/c/index.html") > > But that is eminently doable. > > Phiil > > On Sun, Oct 29, 2017 at 7:13 PM, henry <[henry(a)callistohouse.club]("mailto:henry@callistohouse.club")> wrote: > >> I have heard this summarized by the term: "build it and they will come". I think the data visualization aspect is where Pharo entering BigData space could really payoff. That comes down to data manipulation. Can Pharo read Avro? >> >> - HH >> >> On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna CÃ¡rdenas <[offray.luna(a)mutabit.com]("mailto:offray.luna@mutabit.com")> wrote: >> >>> Thanks a lot Paulo for starting this thread and all the participants for the clever and enlightening answers. I just want to add my two cents. On 26/10/17 07:53, Dimitris Chloupis wrote: > > My personal opinion is that as pessimistic it may sound, Smalltalk has > very little to offer in the library front. The language is still > stellar and live environment is a great concept but from there on > there is a decline. Sure if your are low demand kind of person on the > library front and dont mind implementing stuff by yourself you wont > mind the lack of libraries but most coders , me included , dont have > this luxury. Especially making a living with a language is a > completely different story from learning it as a hobby, > > I think and that's a personal opinion, that Smalltalk goes the wrong > direction. It tries to be a do it all language, but we already have an > army of do it all languages. I think it would excel as the backbone in > big complex projects. Like the Moose project is doing with code > analysis and visualization. I think this is an excellent direction to > go with Smalltalk. Reflection is the big strength of Smalltalk the > ability to communicate with its code in a direct matter. So I think > that a Smalltalk implementation that can analyze and visualize code > written in other languages would have been a pretty serious reason for > people to learn Smalltalk. > > I am very happy to see Pharo go towards that direction and yes I would > definitely recommend it without hesitation for code analysis and > project management tool. Its no coincidence that we have seen a > serious growth in our community. When I joined back in 2011 we all > were posting at pharo-dev, pharo-users was a dead zone and then the > community grow larger and larger we soon may need a third mailing list. > > Code complexity is an issues for all large projects and tools that > help manage this without having to convert to another language are > very popular. About finding niche where you can learn Pharo and make a living from it, I think that I may be behind a sweet spot in the field of reproducible research and data storytelling and visualization, for different fields like activism, journalism, science and engineering. I'm "working in my PhD", so I don't get paid for using Pharo & friends (well if fact I'm in a loan to finish my PhD), but using Pharo have allowed my to get more dynamic results that with previous technologies (mostly Python and Web ones). By being able to prototype quickly I have improved my research experience and results, which is a way to improve research (self) funding. Also, activists, journalist, researchers and other novices interested in data storytelling and visualization, care little about popularity of the language or being able to make apps (mobile or web). What they care is about being able to tell the story and Pharo, agile visualization and moldable tools, have a lot to offer in this front. They're easy to learn and to adapt to fit the needs of the problems behind those stories, as we have done with Grafoscopio[1]. So, is nice to be part of a "trend", (data science, reproducible research, data storytelling and data visualization) but not being part of one that doesn't give you the freedom to use tools that matter to you, because of the ideas they embody and the added value they create for you and your community. [1] [http://mutabit.com/grafoscopio/index.en.html]("http://mutabit.com/grafoscopio/index.en.html") Also, being in Latin America, means that we can bootstrap ourselves into alternative futures by using alternative (digital) infrastructures and tools, without to much worry about the deep investments in money and/or expertise on bloated/popular technologies (we don't have such investments here!). We can learn from the experience of the "Global North", without following that path, but by taking a critical approach to it (for example regarding overcomplex, non-dynamic, bloated technologies). On the community front, I think is important to do something to break the circular logic of popularity: Smalltalk is unpopular, so we don't get developers, so we don't have libraries, and this makes such tech unpopular. We're a nascent community of data storytellers and activists learning how to use Pharo to tell our voices and how to modify the tools to tell them in more potent/fluid ways. We have done this mostly by ourselves, without any support from industry or government and mostly none from academy. Despite of the fragility of our hackerspace[2], this has been done in a consistent way since almost two years[3] (I started to learn Pharo, in a sparse way, 3 years ago). So, there are ways to break the circular logic and bootstrap communities around the advantages of the Pharo/Smalltalk environment in places where it can be aligned to the trends but also take a critical approach to them by providing added value. [2] [http://hackbo.co/]("http://hackbo.co/") [3] [http://mutabit.com/dataweek/]("http://mutabit.com/dataweek/")So finding a niche and bootstrapping tools and communities in it, seems a way to deploy the Smalltalk Argument by example into the world, which is a pretty powerful way to argument against skeptics. Cheers, Offray

Oct. 29, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

How could I get started documenting my components with Grafoscopio? I am interested in learning. I just got ASN.1 lengths right, in Java. I am looking to Pharo and Java with an encrypted connection between them. - HH On Sun, Oct 29, 2017 at 16:59, Offray Vladimir Luna CÃ¡rdenas <[offray.luna(a)mutabit.com]("mailto:offray.luna@mutabit.com")> wrote: > Well is more "build and they will come, if you build also a community who will come", which is hard, but data storytelling and visualization as filed and dynamic moldable tools give us a advantage point to tackle such hard problems. > > Cheers, > > Offray > > On 29/10/17 13:13, henry wrote: > >> I have heard this summarized by the term: "build it and they will come". I think the data visualization aspect is where Pharo entering BigData space could really payoff. That comes down to data manipulation. Can Pharo read Avro? >> >> - HH >> >> On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna CÃ¡rdenas < [offray.luna(a)mutabit.com]("mailto:offray.luna@mutabit.com")> wrote: >> >>> Thanks a lot Paulo for starting this thread and all the participants for the clever and enlightening answers. I just want to add my two cents. On 26/10/17 07:53, Dimitris Chloupis wrote: > > My personal opinion is that as pessimistic it may sound, Smalltalk has > very little to offer in the library front. The language is still > stellar and live environment is a great concept but from there on > there is a decline. Sure if your are low demand kind of person on the > library front and dont mind implementing stuff by yourself you wont > mind the lack of libraries but most coders , me included , dont have > this luxury. Especially making a living with a language is a > completely different story from learning it as a hobby, > > I think and thatâs a personal opinion, that Smalltalk goes the wrong > direction. It tries to be a do it all language, but we already have an > army of do it all languages. I think it would excel as the backbone in > big complex projects. Like the Moose project is doing with code > analysis and visualization. I think this is an excellent direction to > go with Smalltalk. Reflection is the big strength of Smalltalk the > ability to communicate with its code in a direct matter. So I think > that a Smalltalk implementation that can analyze and visualize code > written in other languages would have been a pretty serious reason for > people to learn Smalltalk. > > I am very happy to see Pharo go towards that direction and yes I would > definitely recommend it without hesitation for code analysis and > project management tool. Its no coincidence that we have seen a > serious growth in our community. When I joined back in 2011 we all > were posting at pharo-dev, pharo-users was a dead zone and then the > community grow larger and larger we soon may need a third mailing list. > > Code complexity is an issues for all large projects and tools that > help manage this without having to convert to another language are > very popular. About finding niche where you can learn Pharo and make a living from it, I think that I may be behind a sweet spot in the field of reproducible research and data storytelling and visualization, for different fields like activism, journalism, science and engineering. Iâm "working in my PhD", so I donât get paid for using Pharo & friends (well if fact Iâm in a loan to finish my PhD), but using Pharo have allowed my to get more dynamic results that with previous technologies (mostly Python and Web ones). By being able to prototype quickly I have improved my research experience and results, which is a way to improve research (self) funding. Also, activists, journalist, researchers and other novices interested in data storytelling and visualization, care little about popularity of the language or being able to make apps (mobile or web). What they care is about being able to tell the story and Pharo, agile visualization and moldable tools, have a lot to offer in this front. Theyâre easy to learn and to adapt to fit the needs of the problems behind those stories, as we have done with Grafoscopio[1]. So, is nice to be part of a "trend", (data science, reproducible research, data storytelling and data visualization) but not being part of one that doesnât give you the freedom to use tools that matter to you, because of the ideas they embody and the added value they create for you and your community. [1] [http://mutabit.com/grafoscopio/index.en.html]("http://mutabit.com/grafoscopio/index.en.html") Also, being in Latin America, means that we can bootstrap ourselves into alternative futures by using alternative (digital) infrastructures and tools, without to much worry about the deep investments in money and/or expertise on bloated/popular technologies (we donât have such investments here!). We can learn from the experience of the "Global North", without following that path, but by taking a critical approach to it (for example regarding overcomplex, non-dynamic, bloated technologies). On the community front, I think is important to do something to break the circular logic of popularity: Smalltalk is unpopular, so we donât get developers, so we donât have libraries, and this makes such tech unpopular. Weâre a nascent community of data storytellers and activists learning how to use Pharo to tell our voices and how to modify the tools to tell them in more potent/fluid ways. We have done this mostly by ourselves, without any support from industry or government and mostly none from academy. Despite of the fragility of our hackerspace[2], this has been done in a consistent way since almost two years[3] (I started to learn Pharo, in a sparse way, 3 years ago). So, there are ways to break the circular logic and bootstrap communities around the advantages of the Pharo/Smalltalk environment in places where it can be aligned to the trends but also take a critical approach to them by providing added value. [2] [http://hackbo.co/]("http://hackbo.co/") [3] [http://mutabit.com/dataweek/]("http://mutabit.com/dataweek/") So finding a niche and bootstrapping tools and communities in it, seems a way to deploy the Smalltalk Argument by example into the world, which is a pretty powerful way to argument against skeptics. Cheers, Offray

Oct. 29, 2017

The start of this article is a problem for me. I hope this can be re-thought.

by PAUL DEBRUICKER

https://medium.com/smalltalk-talk/a-gentle-introduction-to-amber-8c532631e9… Smalltalk is a programming language/environment etc. Physical attractiveness of people doesn't really affect anything we're doing here. And using it for marketing is offensive a significant number of people. I'm hopeful we can do better as a community.

Oct. 29, 2017

Re: [Pharo-users] Smalltalk Argument

by phil＠highoctane.be

Pharo can read Avro when this will be UFFI'ed https://avro.apache.org/docs/1.7.3/api/c/index.html But that is eminently doable. Phiil On Sun, Oct 29, 2017 at 7:13 PM, henry <henry(a)callistohouse.club> wrote: > I have heard this summarized by the term: "build it and they will come". I > think the data visualization aspect is where Pharo entering BigData space > could really payoff. That comes down to data manipulation. Can Pharo read > Avro? > > - HH > > > On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna CÃ¡rdenas < > offray.luna(a)mutabit.com> wrote: > > Thanks a lot Paulo for starting this thread and all the participants for > the clever and enlightening answers. I just want to add my two cents. On > 26/10/17 07:53, Dimitris Chloupis wrote: > > My personal opinion is that as > pessimistic it may sound, Smalltalk has > very little to offer in the > library front. The language is still > stellar and live environment is a > great concept but from there on > there is a decline. Sure if your are low > demand kind of person on the > library front and dont mind implementing > stuff by yourself you wont > mind the lack of libraries but most coders , > me included , dont have > this luxury. Especially making a living with a > language is a > completely different story from learning it as a hobby, > > > I think and that's a personal opinion, that Smalltalk goes the wrong > > direction. It tries to be a do it all language, but we already have an > > army of do it all languages. I think it would excel as the backbone in > > big complex projects. Like the Moose project is doing with code > analysis > and visualization. I think this is an excellent direction to > go with > Smalltalk. Reflection is the big strength of Smalltalk the > ability to > communicate with its code in a direct matter. So I think > that a Smalltalk > implementation that can analyze and visualize code > written in other > languages would have been a pretty serious reason for > people to learn > Smalltalk. > > I am very happy to see Pharo go towards that direction and > yes I would > definitely recommend it without hesitation for code analysis > and > project management tool. Its no coincidence that we have seen a > > serious growth in our community. When I joined back in 2011 we all > were > posting at pharo-dev, pharo-users was a dead zone and then the > community > grow larger and larger we soon may need a third mailing list. > > Code > complexity is an issues for all large projects and tools that > help manage > this without having to convert to another language are > very popular. > About finding niche where you can learn Pharo and make a living from it, I > think that I may be behind a sweet spot in the field of reproducible > research and data storytelling and visualization, for different fields like > activism, journalism, science and engineering. I'm "working in my PhD", so > I don't get paid for using Pharo & friends (well if fact I'm in a loan to > finish my PhD), but using Pharo have allowed my to get more dynamic results > that with previous technologies (mostly Python and Web ones). By being able > to prototype quickly I have improved my research experience and results, > which is a way to improve research (self) funding. Also, activists, > journalist, researchers and other novices interested in data storytelling > and visualization, care little about popularity of the language or being > able to make apps (mobile or web). What they care is about being able to > tell the story and Pharo, agile visualization and moldable tools, have a > lot to offer in this front. They're easy to learn and to adapt to fit the > needs of the problems behind those stories, as we have done with > Grafoscopio[1]. So, is nice to be part of a "trend", (data science, > reproducible research, data storytelling and data visualization) but not > being part of one that doesn't give you the freedom to use tools that > matter to you, because of the ideas they embody and the added value they > create for you and your community. [1] http://mutabit.com/ > grafoscopio/index.en.html Also, being in Latin America, means that we can > bootstrap ourselves into alternative futures by using alternative (digital) > infrastructures and tools, without to much worry about the deep investments > in money and/or expertise on bloated/popular technologies (we don't have > such investments here!). We can learn from the experience of the "Global > North", without following that path, but by taking a critical approach to > it (for example regarding overcomplex, non-dynamic, bloated technologies). > On the community front, I think is important to do something to break the > circular logic of popularity: Smalltalk is unpopular, so we don't get > developers, so we don't have libraries, and this makes such tech unpopular. > We're a nascent community of data storytellers and activists learning how > to use Pharo to tell our voices and how to modify the tools to tell them in > more potent/fluid ways. We have done this mostly by ourselves, without any > support from industry or government and mostly none from academy. Despite > of the fragility of our hackerspace[2], this has been done in a consistent > way since almost two years[3] (I started to learn Pharo, in a sparse way, 3 > years ago). So, there are ways to break the circular logic and bootstrap > communities around the advantages of the Pharo/Smalltalk environment in > places where it can be aligned to the trends but also take a critical > approach to them by providing added value. [2] http://hackbo.co/ [3] > http://mutabit.com/dataweek/ So finding a niche and bootstrapping tools > and communities in it, seems a way to deploy the Smalltalk Argument by > example into the world, which is a pretty powerful way to argument against > skeptics. Cheers, Offray > >

Oct. 29, 2017

Re: [Pharo-users] Smalltalk Argument

by Offray Vladimir Luna CÃ¡rdenas

Well is more "build and they will come, if you build also a community who will come", which is hard, but data storytelling and visualization as filed and dynamic moldable tools give us a advantage point to tackle such hard problems. Cheers, Offray On 29/10/17 13:13, henry wrote: > I have heard this summarized by the term: "build it and they will > come". I think the data visualization aspect is where Pharo entering > BigData space could really payoff. That comes down to data > manipulation. Can Pharo read Avro? > > - HH > > > On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: >> Thanks a lot Paulo for starting this thread and all the participants >> for the clever and enlightening answers. I just want to add my two >> cents. On 26/10/17 07:53, Dimitris Chloupis wrote: > > My personal >> opinion is that as pessimistic it may sound, Smalltalk has > very >> little to offer in the library front. The language is still > stellar >> and live environment is a great concept but from there on > there is >> a decline. Sure if your are low demand kind of person on the > >> library front and dont mind implementing stuff by yourself you wont > >> mind the lack of libraries but most coders , me included , dont have >> > this luxury. Especially making a living with a language is a > >> completely different story from learning it as a hobby,Â > > I think >> and that's a personal opinion, that Smalltalk goes the wrong > >> direction. It tries to be a do it all language, but we already have >> an > army of do it all languages. I think it would excel as the >> backbone in > big complex projects. Like the Moose project is doing >> with code > analysis and visualization. I think this is an excellent >> direction to > go with Smalltalk. Reflection is the big strength of >> Smalltalk the > ability to communicate with its code in a direct >> matter. So I think > that a Smalltalk implementation that can analyze >> and visualize code > written in other languages would have been a >> pretty serious reason for > people to learn Smalltalk.Â > > I am very >> happy to see Pharo go towards that direction and yes I would > >> definitely recommend it without hesitationÂ for code analysis and > >> project management tool. Its no coincidence that we have seen a > >> serious growth in our community. When I joined back in 2011 we all > >> were posting at pharo-dev, pharo-users was a dead zone and then the > >> community grow larger and larger we soon may need a third mailing >> list.Â > > Code complexity is an issues for all large projects and >> tools that > help manage this without having to convert to another >> language are > very popular. About findingÂ niche where you can learn >> Pharo and make a living from it, I think that I may be behind a sweet >> spot in the field of reproducible research and data storytelling and >> visualization, for different fields like activism, journalism, >> science and engineering. I'm "working in my PhD", so I don't get paid >> for using Pharo & friends (well if fact I'm in a loan to finish my >> PhD), but using Pharo have allowed my to get more dynamic results >> that with previous technologies (mostly Python and Web ones). By >> being able to prototype quickly I have improved my research >> experience and results, which is a way to improve research (self) >> funding. Also, activists, journalist, researchers and other novices >> interested in data storytelling and visualization, care little about >> popularity of the language or being able to make apps (mobile or >> web). What they care is about being able to tell the story and Pharo, >> agile visualization and moldable tools, have a lot to offer in this >> front. They're easy to learn and to adapt to fit the needs of the >> problems behind those stories, as we have done with Grafoscopio[1]. >> So, is nice to be part of a "trend", (data science, reproducible >> research, data storytelling and data visualization) but not being >> part of one that doesn't give you the freedom to use tools that >> matter to you, because of the ideas they embody and the added value >> they create for you and your community. [1] >> http://mutabit.com/grafoscopio/index.en.html Also, being in Latin >> America, means that we can bootstrap ourselves into alternative >> futures by using alternative (digital) infrastructures and tools, >> without to much worry about the deep investments in money and/or >> expertise on bloated/popular technologies (we don't have such >> investments here!). We can learn from the experience of the "Global >> North", without following that path, but by taking a critical >> approach to it (for example regarding overcomplex, non-dynamic, >> bloated technologies). On the community front, I think is important >> to do something to break the circular logic of popularity: Smalltalk >> is unpopular, so we don't get developers, so we don't have libraries, >> and this makes such tech unpopular. We're a nascent community of data >> storytellers and activists learning how to use Pharo to tell our >> voices and how to modify the tools to tell them in more potent/fluid >> ways. We have done this mostly by ourselves, without any support from >> industry or government and mostly none from academy. Despite of the >> fragility of our hackerspace[2], this has been done in a consistent >> way since almost two years[3] (I started to learn Pharo, in a sparse >> way, 3 years ago). So, there are ways to break the circular logic and >> bootstrap communities around the advantages of the Pharo/Smalltalk >> environment in places where it can be aligned to the trends but also >> take a critical approach to them by providing added value. [2] >> http://hackbo.co/ [3] http://mutabit.com/dataweek/ So finding a niche >> and bootstrapping tools and communities in it, seems a way to deploy >> the Smalltalk Argument by example into the world, which is a pretty >> powerful way to argument against skeptics. Cheers, Offray

Oct. 29, 2017

New Pharo Booklet

by Stephane Ducasse

Hi guys I just published a new little booklet on Pharo tips and tricks! Available at: http://books.pharo.org Feedback and contributions are welcome as usual. Stef

Oct. 29, 2017

Re: [Pharo-users] [GT] moldable tools for non-developers

by Offray Vladimir Luna CÃ¡rdenas

Hi Stef, Is kind of strange, but I didn't use Polymath at all for my prototypes on medicine data visualization[1] Panama Papers[2] or Twitter Data Selfies[3] or the book on Data Driven Journalism[4]. I just use Roassal, UDBC with Sqlite, NeoJSON and STON. So it may sound strange, but I think that Pharo is already a pretty good contestant on the area of Data Driven Storytelling, if we provide a more integrated "end user" experience (that's what I'm trying to do with Grafoscopio). Things like a better support for Markup languages with syntax highlighting and orthographic corrector (via GT-Documenter?), better GUI for querying data in SQL, are a felt needs and also integration with R has been asked.Â [1] http://mutabit.com/offray/blog/en/entry/sdv-infomed [2] http://mutabit.com/offray/blog/en/entry/panama-papers-1 [3] http://mutabit.com/offray/blog/en/entry/ds-twitter-mockup [4] http://mutabit.com/repos.fossil/mapeda/ That being said, I think that if we have something like Polymath integration and Math rendering inside Pharo, something like a Mathematica/Jupyter/TeXmacs notebook can be just around the corner, with a pretty superior DOM (live objects all the way down) and environment. I think that we could have a killer app for a growing niche! The main issue now is to provide researchers and data driven storytellers with a mature enough default experience to make them to bet on that Pharo powered vision of the future. Cheers, Offray On 29/10/17 15:26, Stephane Ducasse wrote: > Hi offray > > What I would like to know is what are the kind of mathematical support you need > for your data analyses and that is not support by polymath. > > I'm "working" (well sweet dream) on future book on collective > intelligence, basic AI stuff > and I think that roassal is cool but you need to have also filtering > and empowering the data. > > So what did you miss? > I want powerful data journalists (they are important for our world). > > > Stef > > On Fri, Oct 27, 2017 at 8:38 PM, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com> wrote: >> Hi Sebastian, >> >> >> On 27/10/17 13:15, Sebastian Heidbrink via Pharo-users wrote: >>> that is kind of what I am looking for. Would you mind if I contacted >>> you directly? >>> I am in the process of formulizing a master thesis and would love to >>> bring Pharo into the mix. >>> >> No problem. Contact me. This weekend is a little bit busy with some >> deadlines I need to reach, but next week is fine. >> >>> Is you phd thesis public? >> It is at [1], with a public repository of the research artifacts since >> 2011 (before open research was in fashion :-P), but it is in Spanish. >> Sorry. I didn't have the time to clarify my mind about this research and >> also improve my English. But I would be glad to discuss it in English >> with you or anyone interested. You're very welcomed. >> >> [1] http://mutabit.com/repos.fossil/doctorado-offray/ >> >> Cheers, >> >> Offray >> >> >

Oct. 29, 2017

Re: [Pharo-users] [GT] moldable tools for non-developers

by Stephane Ducasse

Hi offray What I would like to know is what are the kind of mathematical support you need for your data analyses and that is not support by polymath. I'm "working" (well sweet dream) on future book on collective intelligence, basic AI stuff and I think that roassal is cool but you need to have also filtering and empowering the data. So what did you miss? I want powerful data journalists (they are important for our world). Stef On Fri, Oct 27, 2017 at 8:38 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Hi Sebastian, > > > On 27/10/17 13:15, Sebastian Heidbrink via Pharo-users wrote: >> that is kind of what I am looking for. Would you mind if I contacted >> you directly? >> I am in the process of formulizing a master thesis and would love to >> bring Pharo into the mix. >> > > No problem. Contact me. This weekend is a little bit busy with some > deadlines I need to reach, but next week is fine. > >> Is you phd thesis public? > It is at [1], with a public repository of the research artifacts since > 2011 (before open research was in fashion :-P), but it is in Spanish. > Sorry. I didn't have the time to clarify my mind about this research and > also improve my English. But I would be glad to discuss it in English > with you or anyone interested. You're very welcomed. > > [1] http://mutabit.com/repos.fossil/doctorado-offray/ > > Cheers, > > Offray > >

Oct. 29, 2017

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

by Stephane Ducasse

Thanks I think that the sets will be known since the scanner definition should not changed once defined. Now andrew told me that he could use an existing solution but not build one because he should make progress on his compiler. But Steffen if you know how to build such package it would be a nice addition and we will use it. Stef On Sat, Oct 28, 2017 at 5:37 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > Does that mean the sets/bdd would be constructed mainly at comile time? > Anyway, Andrew, feel free to contact me, I might help you with this. > > Best, Steffen > > > Am .10.2017, 16:05 Uhr, schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > >> I think that andrew would like to improve smacc when parsing inputs >> containing utf-8 characters. >> >> >> On Sat, Oct 28, 2017 at 1:46 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: >>> >>> I see. What is the task in detail? Are some of the set fixed or known in >>> advance? What's the argument against a bitset-based solution? >>> >>> Cheers, Steffen >>> >>> >>> >>> Am 27. Oktober 2017 19:10:35 MESZ schrieb Stephane Ducasse >>> <stepharo.self(a)gmail.com>: > > <---Schnitt---> >>> >>> >> > > >

Oct. 29, 2017

Re: [Pharo-users] Actual Code to Improve the Pharo environment

by Stephane Ducasse

Ok tell us when you release something. having a little example would be really nice. On Sat, Oct 28, 2017 at 5:25 PM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > Iâm not working on that specifically, although what I am working on could > definitely use that and vice versa, which would increase the capabilities > of each. > > > > One thing Iâm working on is using Vert.x for service registration and > discovery, mapped to Apache River (JINI) to propagate that over non-local > network segments that require fully authenticated security (as a result, it > also provides things such as Kerberos to Pharo apps). The mapping between > the two is very straightforward, almost direct, but Iâve added the Synapse > micro service bus to control data flows and secure access to remote > services. > > > > It enables things like automatic configuration/integration of Pharo based > mobile apps with newer cars that support that kind of autoconfiguration, > since they all use JINI to do so. Thus a Pharo mobile or IoT app can > automatically be configured to work with any of the carâs subsystems that > are relevant to it. > > > > JINI is far more used than people realize, partly because it âjust worksâ > and as a result doesnât get the public âsqueaky wheelâ effect. The fact > that the authors of Vert.x reimplemented half of the features of JINI, in a > less comprehensive and less reliable way, rather than just using it > (especially considering itâs open source) shows the degree to which that > effect is operative. > > > > Thereâs probably a couple dozen other general use cases where the > integration will allow Pharo apps to âjust workâ in a JINI or Vert.x > environment, as well as thousands of industry/company specific ones. Iâd > have to mode-switch to think of them off the top of my head though ð. > > > > Andrew > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > > *From: *henry <henry(a)callistohouse.club> > *Sent: *Saturday, October 28, 2017 10:02 AM > *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject: *Re: [Pharo-users] Actual Code to Improve the Pharo environment > > > > Hi Andrew, > > > > Are you working to bring a Capabilities model to Pharo? This is precisely > what I am working to bring with Hubbub, running on top of my ParrotTalk. I > derived these from erights.org's ELib and have been working on them for > many years. Now that ParrotTalk has stabilized (layer 5) I am shifting to > implementing marshalling of layer 6 objects using STON all to run on top of > ParrotTalk. Once I get marshalling with scope substitutions, I will debug > Hubbub to offer distributed Capabilities. > > > > What work are you undertaking? > > > > Regards, > > - HH > > > > > > -------- Original Message -------- > > Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment > > Local Time: October 28, 2017 9:12 AM > > UTC Time: October 28, 2017 1:12 PM > > From: aglynn42(a)gmail.com > > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > > > Writing that kind of code is another of the reasons I decided I donât want > to work in anything else ð. Maybe more important than some of the > others, both to myself and to other users. > > > > Iâve gained so much personally, mostly for nothing, even just considering > the relatively few projects I *have* been able to work on in Pharo and > previously in Squeak, VW and VA. Unfortunately in most I havenât been able > to make the code public, since they were for entities like the government, > DoD, etc. > > > > Not that VA attracts me quite so much to give back all that strongly, when > a license is $8500+. Were it possible to give back to VA C++ or VA Java, > it might be different, but neither were OSS although they werenât > expensive. More relevantly, both are now abandonware (hence my comment > about IBM, which is applicable to OS/2 as well, although that has quietly > had a 5.0 version released in June of this year). > > > > I would, though, love a chance to give back to Pharo primarily, although I > may port anything relevant to Squeak, and if I have sufficient time port it > to VW, which although not OSS is at least affordable to most developers. > > > > Iâm nearly there on a couple of projects â one Iâm testing and making > final tweaks, another is about 2/3dâs of the way. > > > > The first project you (and others on the list) may be more immediately > interested in testing, since it requires little to no additional work to > use it, and even if not perfect, since itâs intended to directly help work > you *are* doing in Pharo, it may worthwhile. Iâm hoping to have it ready > for public consumption by the middle of November. > > > > On a different but related topic, the article I wrote got a fair amount of > interest considering I donât write nearly as well as Kenneth, for example. > Including direct interest from some well known industry people, which canât > hurt. In an indirect way it may even be helpful, but not in the real, > direct way decent code is. > > > > Capabilities that wonât be available in anything else in an really usable > way (because to be efficient they depend on capabilities not found in > anything else), and in any case nowhere near as useful in anything else, > will hopefully be more use than any article can be, never mind one I wrote, > not just to me but also to other Pharo users and to Pharo itself. > > > > Cheers > > Andrew Glynn > > > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > > *From: *Stephane Ducasse <stepharo.self(a)gmail.com> > > *Sent: *Saturday, October 28, 2017 5:09 AM > > *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > *Subject: *Re: [Pharo-users] Smalltalk Argument > > > > Hi andrew > > > > please take a project that would help to bring more companies and that you > want to push and push it with us :). > > > > > > Stef > > > > > > On Sat, Oct 28, 2017 at 11:05 AM, Stephane Ducasse < > stepharo.self(a)gmail.com> wrote: > > Hi andrew > > > > you should contact esteban because he is writing an objective-C bridge. > > > > Stef > > > > On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > > One thing Iâm working on is a bridge between Pharo and F-Script. F-Script > is, basically, a Smalltalk dialect, as is obvious from the screenshot. > However for MacOS and iOS, it allows you to bypass the static Objective-C > API interface and debug / modify or even write applications directly in the > system. To do that you âinjectâ F-Script into the OS. The ability to so > has a specific implication, though. MacOS and iOS are themselves written > in and as a dialect of Smalltalk. (were it simply an overlay on > Objective-C, it wouldnât be able to do things that are impossible in > Objective-C, and it wouldnât need to be âinjectedâ in order to run). Every > implementation of Objective-C , bar GNUâs useless imitation, compiles to > Smalltalk. No surprise that Appleâs does, as well. > > > > In any event, it will allow Pharo code to be mapped to MacOS and iOS > objects, injected into the system dynamically, and modified / debugged > dynamically using the Pharo tools. The result, at least as far as iOS is > concerned, may make Pharo actually the most powerful way to program it, > well beyond XCode alone, along with doing the same for MacOS. Android is > another issue, although the Raspbian port of Pharo should be relatively > easy to port to it. For me, unless someone had a use case, I donât have one > myself for Android. Iâve tried nearly every version, because Iâd love to > support an OSS ecosystem, unfortunately using it compared to the iPhone is > still like driving a Fiero based kit car compared to an actual Ferrari. > > > > As far as JNI, while I see your point, JNI is such a PITA that few Java > developers know it. My usual workaround is to use Stamp and Synapse, which > has the further advantage of allowing Java to âthrottleâ data that the JVM > canât deal with at full speed. > > > > As far as dealing with other JVM languages, PetitParser or SmaCC can > generate bytecode rather than Java or other JVM code, and that allows libs > to be written that utilize Synapse to talk to Pharo. It isnât necessarily > an ideal solution, but a possible one without having to support umpteen > environments. Another potential way of accomplishing that is to use > NetRexx, a declarative JVM language, which is both easy and terse, and like > SQL, generates the actual bytecode rather than precompiling to it. For > instance, imagine the code needed for a simple âhello worldâ in Java, then > compare: > > > > Say âhello worldâ > > > > Since it generates virtually the same bytecode, it may be an easy way to > do it. > > > > With the last statement, that expresses really well the exact reason I no > longer want to work in most other environments ð. > > > > Tc > > Andrew > > > > > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > > *From: *phil(a)highoctane.be > > *Sent: *Thursday, October 26, 2017 2:19 AM > > *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > *Subject: *Re: [Pharo-users] Smalltalk Argument > > > > 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. 29, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

I have heard this summarized by the term: "build it and they will come". I think the data visualization aspect is where Pharo entering BigData space could really payoff. That comes down to data manipulation. Can Pharo read Avro? - HH On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Thanks a lot Paulo for starting this thread and all the participants for the clever and enlightening answers. I just want to add my two cents. On 26/10/17 07:53, Dimitris Chloupis wrote: > > My personal opinion is that as pessimistic it may sound, Smalltalk has > very little to offer in the library front. The language is still > stellar and live environment is a great concept but from there on > there is a decline. Sure if your are low demand kind of person on the > library front and dont mind implementing stuff by yourself you wont > mind the lack of libraries but most coders , me included , dont have > this luxury. Especially making a living with a language is a > completely different story from learning it as a hobby, > > I think and that's a personal opinion, that Smalltalk goes the wrong > direction. It tries to be a do it all language, but we already have an > army of do it all languages. I think it would excel as the backbone in > big complex projects. Like the Moose project is doing with code > analysis and visualization. I think this is an excellent direction to > go with Smalltalk. Reflection is the big strength of Smalltalk the > ability to communicate with its code in a direct matter. So I think > that a Smalltalk implementation that can analyze and visualize code > written in other languages would have been a pretty serious reason for > people to learn Smalltalk. > > I am very happy to see Pharo go towards that direction and yes I would > definitely recommend it without hesitation for code analysis and > project management tool. Its no coincidence that we have seen a > serious growth in our community. When I joined back in 2011 we all > were posting at pharo-dev, pharo-users was a dead zone and then the > community grow larger and larger we soon may need a third mailing list. > > Code complexity is an issues for all large projects and tools that > help manage this without having to convert to another language are > very popular. About finding niche where you can learn Pharo and make a living from it, I think that I may be behind a sweet spot in the field of reproducible research and data storytelling and visualization, for different fields like activism, journalism, science and engineering. I'm "working in my PhD", so I don't get paid for using Pharo & friends (well if fact I'm in a loan to finish my PhD), but using Pharo have allowed my to get more dynamic results that with previous technologies (mostly Python and Web ones). By being able to prototype quickly I have improved my research experience and results, which is a way to improve research (self) funding. Also, activists, journalist, researchers and other novices interested in data storytelling and visualization, care little about popularity of the language or being able to make apps (mobile or web). What they care is about being able to tell the story and Pharo, agile visualization and moldable tools, have a lot to offer in this front. They're easy to learn and to adapt to fit the needs of the problems behind those stories, as we have done with Grafoscopio[1]. So, is nice to be part of a "trend", (data science, reproducible research, data storytelling and data visualization) but not being part of one that doesn't give you the freedom to use tools that matter to you, because of the ideas they embody and the added value they create for you and your community. [1] http://mutabit.com/grafoscopio/index.en.html Also, being in Latin America, means that we can bootstrap ourselves into alternative futures by using alternative (digital) infrastructures and tools, without to much worry about the deep investments in money and/or expertise on bloated/popular technologies (we don't have such investments here!). We can learn from the experience of the "Global North", without following that path, but by taking a critical approach to it (for example regarding overcomplex, non-dynamic, bloated technologies). On the community front, I think is important to do something to break the circular logic of popularity: Smalltalk is unpopular, so we don't get developers, so we don't have libraries, and this makes such tech unpopular. We're a nascent community of data storytellers and activists learning how to use Pharo to tell our voices and how to modify the tools to tell them in more potent/fluid ways. We have done this mostly by ourselves, without any support from industry or government and mostly none from academy. Despite of the fragility of our hackerspace[2], this has been done in a consistent way since almost two years[3] (I started to learn Pharo, in a sparse way, 3 years ago). So, there are ways to break the circular logic and bootstrap communities around the advantages of the Pharo/Smalltalk environment in places where it can be aligned to the trends but also take a critical approach to them by providing added value. [2] http://hackbo.co/ [3] http://mutabit.com/dataweek/ So finding a niche and bootstrapping tools and communities in it, seems a way to deploy the Smalltalk Argument by example into the world, which is a pretty powerful way to argument against skeptics. Cheers, Offray

Oct. 29, 2017

Re: [Pharo-users] Smalltalk Argument

by Offray Vladimir Luna CÃ¡rdenas

Thanks a lot Paulo for starting this thread and all the participants for the clever and enlightening answers. I just want to add my two cents. On 26/10/17 07:53, Dimitris Chloupis wrote: > > My personal opinion is that as pessimistic it may sound, Smalltalk has > very little to offer in the library front. The language is still > stellar and live environment is a great concept but from there on > there is a decline. Sure if your are low demand kind of person on the > library front and dont mind implementing stuff by yourself you wont > mind the lack of libraries but most coders , me included , dont have > this luxury. Especially making a living with a language is a > completely different story from learning it as a hobby,Â > > I think and that's a personal opinion, that Smalltalk goes the wrong > direction. It tries to be a do it all language, but we already have an > army of do it all languages. I think it would excel as the backbone in > big complex projects. Like the Moose project is doing with code > analysis and visualization. I think this is an excellent direction to > go with Smalltalk. Reflection is the big strength of Smalltalk the > ability to communicate with its code in a direct matter. So I think > that a Smalltalk implementation that can analyze and visualize code > written in other languages would have been a pretty serious reason for > people to learn Smalltalk.Â > > I am very happy to see Pharo go towards that direction and yes I would > definitely recommend it without hesitationÂ for code analysis and > project management tool. Its no coincidence that we have seen a > serious growth in our community. When I joined back in 2011 we all > were posting at pharo-dev, pharo-users was a dead zone and then the > community grow larger and larger we soon may need a third mailing list.Â > > Code complexity is an issues for all large projects and tools that > help manage this without having to convert to another language are > very popular. About findingÂ niche where you can learn Pharo and make a living from it, I think that I may be behind a sweet spot in the field of reproducible research and data storytelling and visualization, for different fields like activism, journalism, science and engineering. I'm "working in my PhD", so I don't get paid for using Pharo & friends (well if fact I'm in a loan to finish my PhD), but using Pharo have allowed my to get more dynamic results that with previous technologies (mostly Python and Web ones). By being able to prototype quickly I have improved my research experience and results, which is a way to improve research (self) funding. Also, activists, journalist, researchers and other novices interested in data storytelling and visualization, care little about popularity of the language or being able to make apps (mobile or web). What they care is about being able to tell the story and Pharo, agile visualization and moldable tools, have a lot to offer in this front. They're easy to learn and to adapt to fit the needs of the problems behind those stories, as we have done with Grafoscopio[1]. So, is nice to be part of a "trend", (data science, reproducible research, data storytelling and data visualization) but not being part of one that doesn't give you the freedom to use tools that matter to you, because of the ideas they embody and the added value they create for you and your community. [1] http://mutabit.com/grafoscopio/index.en.html Also, being in Latin America, means that we can bootstrap ourselves into alternative futures by using alternative (digital) infrastructures and tools, without to much worry about the deep investments in money and/or expertise on bloated/popular technologies (we don't have such investments here!). We can learn from the experience of the "Global North", without following that path, but by taking a critical approach to it (for example regarding overcomplex, non-dynamic, bloated technologies). On the community front, I think is important to do something to break the circular logic of popularity: Smalltalk is unpopular, so we don't get developers, so we don't have libraries, and this makes such tech unpopular. We're a nascent community of data storytellers and activists learning how to use Pharo to tell our voices and how to modify the tools to tell them in more potent/fluid ways. We have done this mostly by ourselves, without any support from industry or government and mostly none from academy. Despite of the fragility of our hackerspace[2], this has been done in a consistent way since almost two years[3] (I started to learn Pharo, in a sparse way, 3 years ago). So, there are ways to break the circular logic and bootstrap communities around the advantages of the Pharo/Smalltalk environment in places where it can be aligned to the trends but also take a critical approach to them by providing added value. [2] http://hackbo.co/ [3] http://mutabit.com/dataweek/ So finding a niche and bootstrapping tools and communities in it, seems a way to deploy the Smalltalk Argument by example into the world, which is a pretty powerful way to argument against skeptics. Cheers, Offray

Oct. 29, 2017

Re: [Pharo-users] Exchanging information between 2 pharo applications (2 images running on two different computers)

by Paulo R. Dellani

well, I downloaded the .mcz package <http://smalltalkhub.com/mc/panuw/zeromq/main/ZeroMQ-PanuWetterstrand.31.mcz>, unzipped it and changed the source code accordingly using a text editor (Smalltalkers can use text editors to edit code too!). Later on I could successfully file-in the file in a new Pharo 6 image. The code need more changes to work, however. Lets see how long it takes to get a few ZeroMQ examples running. I will publish my "fork". Cheers, Paulo On 10/29/2017 03:09 PM, Paulo R. Dellani wrote: > Dear all, > > I would like to give ZeroMQ a try in Smalltalk, but am unable to > load it on a new image successfully. In Pharo 5, I loaded the package > ConfigurationOfZeroMQ from therepository in smalltalkhub > <http://smalltalkhub.com/#%21/%7Epanuw/zeromq> and > evaluated the following to load the code: > > ConfigurationOfZeroMQ loadBleedingEdge > > It seems to load everything well, but when I try to look at the source > code of the methods that call the C routines from libzmq using the > system browser, the system exhibits the following error message: > > UndefinedObject(Object)>>doesNotUnderstand: #keywords > RBFFICallPragma(RBPragmaNode)>>selectorParts > RubSHTextStylerST80(SHRBTextStyler)>>visitPragmaNode: > RBFFICallPragma(RBPragmaNode)>>acceptVisitor: > RubSHTextStylerST80(SHRBTextStyler)>>visitNode: > [ :each | self visitNode: each ] in > RubSHTextStylerST80>>visitMethodNode: in Block: [ :each | self > visitNode: each ] > OrderedCollection>>do: > > (its a long stack, cutting here) > > When loading ZeroMQ on Pharo 6, a window pops-up with the title > 'Syntax Error: Literal constant expected' showing the source code > of a method defining a call to a routine from a C library: > > apiDeleteDC: aHDC > Â Â Â <apicall: Literal constant expected -> bool 'DeleteDC' (Win32HDC) > module:'gdi32.dll'> > Â Â Â ^self externalCallFailed > > If I update the syntax, re-writing the code above as > > apiDeleteDC: aHDC > Â Â Â ^self ffiCall: #( bool DeleteDC (Win32HDC aHDC) ) module:'gdi32.dll' > > the compiler accepts it and the process can go on, but eventually > the system will become unstable... > > Any ideas on how to solve this problems? Is this syntax still supported > in Pharo5 & 6? > > Cheers, > > Paulo > > On 10/25/2017 03:47 PM, Sebastian Heidbrink via Pharo-users wrote: >> ForwardedMessage.eml >> >> Subject: >> Re: [Pharo-users] Exchanging information between 2 pharo applications >> (2 images running on two different computers) >> From: >> Sebastian Heidbrink <sheidev(a)yahoo.de> >> Date: >> 10/25/2017 03:47 PM >> >> To: >> pharo-users(a)lists.pharo.org >> >> >> Hi Cederik, >> >> you should have a look at http://smalltalkhub.com/#!/~panuw/zeromq >> ZeroMQ is a networking library. Nice thing about it is that all the >> networking related workload is dealt with in a second process. That >> can save you some resources within Smalltalk. >

Oct. 29, 2017

Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations

by Andrew Glynn

Thanks, great description ð. From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of henry Sent: Sunday, October 29, 2017 1:56 AM To: Ben Coman <btc(a)openinworld.com> Cc: Pharo-users list <pharo-users(a)lists.pharo.org>; Pharo Development List <pharo-dev(a)lists.pharo.org>; Squeak-dev <squeak-dev(a)lists.squeakfoundation.org> Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations Yes well it is an extension to what you found as I combined with eventual references such that it computes in a single thread. - HH On Sat, Oct 28, 2017 at 23:59, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com> > wrote: On Thu, Oct 26, 2017 at 12:00 AM, henry <henry(a)callistohouse.club <mailto:henry@callistohouse.club> > wrote: I disabled vatId authorization in version 3, located in SessionOperations>> processIWant | SessionOperations>>processIAm: . I was asked to disseminate my news to Pharo Users, hello there. I was asked to describe ParrotTalk well, provide use cases and adopters of its use. Alright, I will give an attempt. ParrotTalk is an encrypted connection framework. Currently allowing anonymous 2048-bit key negotiation to establish user-provided encryption cipher and user-provided encoding and decoding, both through a provided SessionAgentMap to a starting SessionAgent server. Please look in the test case ThunkHelloWorldTest for building these maps and running a connection iwth data passing after encryption is established. There is a 4-way negotiation, from ProtocolOffered/Accepted to Go/GoToo. In using RSA 2048 signature validation and DH 2048 primes to establish the key used within the selected Cipher. The Cipher and Encoder are selected by name through the negotiation protocol. Currently three Ciphers are selectable, AESede, DESede, and DES. There are two encoders tested, asn1der, and Bytes. This protocol is described here, in this document. https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFr… For as to use cases, this encrypted connection has no third party, man-in-the-middle situation by not using Certificates. As such, this is a tight implementation of NSA-proof encryption without explicit authorization beyond knowledge of a host:port. The use cases involve any communication desired to be encrypted with such high encryption. The support will last my lifetime, so we have a settled solution, here in the third version, provided here. It requires version 111 of Cryptography, as a prerequisite. Both run on Squeak and Pharo. http://www.squeaksource.com/Cryptography/Cryptography-zzz.111.mcz http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz The current use is with my hubbub system, a promise-based distributed object implementation. I am working to bring ParrotTalk to Java and allow hubbub to operate interdependently between Squeak, Pharo, Java and any other languages which can support ParrotTalk and STON. My latest efforts with hubbub are to bring STON as the Layer 6 encoding. Hubbub depends on eLinda. Took me a while to track down what eLinda was. I presume its an implementation of Linda "a model of coordination and communication among several parallel processes operating upon objects stored in and retrieved from shared, virtual, associative memory" https://en.wikipedia.org/wiki/Linda_(coordination_language) http://www.cs.yale.edu/publications/techreports/tr984.pdf cheers -ben

Oct. 29, 2017

Re: [Pharo-users] Exchanging information between 2 pharo applications (2 images running on two different computers)

by Paulo R. Dellani

Dear all, I would like to give ZeroMQ a try in Smalltalk, but am unable to load it on a new image successfully. In Pharo 5, I loaded the package ConfigurationOfZeroMQ from therepository in smalltalkhub <http://smalltalkhub.com/#%21/%7Epanuw/zeromq> and evaluated the following to load the code: ConfigurationOfZeroMQ loadBleedingEdge It seems to load everything well, but when I try to look at the source code of the methods that call the C routines from libzmq using the system browser, the system exhibits the following error message: UndefinedObject(Object)>>doesNotUnderstand: #keywords RBFFICallPragma(RBPragmaNode)>>selectorParts RubSHTextStylerST80(SHRBTextStyler)>>visitPragmaNode: RBFFICallPragma(RBPragmaNode)>>acceptVisitor: RubSHTextStylerST80(SHRBTextStyler)>>visitNode: [ :each | self visitNode: each ] in RubSHTextStylerST80>>visitMethodNode: in Block: [ :each | self visitNode: each ] OrderedCollection>>do: (its a long stack, cutting here) When loading ZeroMQ on Pharo 6, a window pops-up with the title 'Syntax Error: Literal constant expected' showing the source code of a method defining a call to a routine from a C library: apiDeleteDC: aHDC Â Â Â <apicall: Literal constant expected -> bool 'DeleteDC' (Win32HDC) module:'gdi32.dll'> Â Â Â ^self externalCallFailed If I update the syntax, re-writing the code above as apiDeleteDC: aHDC Â Â Â ^self ffiCall: #( bool DeleteDC (Win32HDC aHDC) ) module:'gdi32.dll' the compiler accepts it and the process can go on, but eventually the system will become unstable... Any ideas on how to solve this problems? Is this syntax still supported in Pharo5 & 6? Cheers, Paulo On 10/25/2017 03:47 PM, Sebastian Heidbrink via Pharo-users wrote: > ForwardedMessage.eml > > Subject: > Re: [Pharo-users] Exchanging information between 2 pharo applications > (2 images running on two different computers) > From: > Sebastian Heidbrink <sheidev(a)yahoo.de> > Date: > 10/25/2017 03:47 PM > > To: > pharo-users(a)lists.pharo.org > > > Hi Cederik, > > you should have a look at http://smalltalkhub.com/#!/~panuw/zeromq > ZeroMQ is a networking library. Nice thing about it is that all the > networking related workload is dealt with in a second process. That > can save you some resources within Smalltalk.

Oct. 29, 2017

Re: [Pharo-users] What is code 137 / how to gracefully shut down via SIGTERM?

by Herby VojÄÃk

werner kassens wrote: > Hi Herby, > eventually you might want to look at > https://github.com/moby/moby/issues/1063 > but then i dont know anything about these things. Hopefully they have this solved already... but I learned 137 means "killed". generally; did not know. :-) > werner Herby

Oct. 29, 2017

Re: [Pharo-users] What is code 137 / how to gracefully shut down via SIGTERM?

by Herby VojÄÃk

Esteban Lorenzano wrote: > Hi, > > I donât know if is useful in your case, but you made me remember I made > a small tool to trap unix signals within Pharo. I uploaded then to github. > > https://github.com/estebanlm/pharo-posix-signal > > is very easy to use and it will allow you to trap any signal and do what > you want ;) Thanks, looks that it'll help. > Esteban > > >> On 28 Oct 2017, at 13:39, Herby VojÄÃk <herby(a)mailbox.sk >> <mailto:herby@mailbox.sk>> wrote: >> >> Hi, >> >> I had to find out how to automatically deploy the backend written in >> Pharo, and so far it uses docker-compose stop to stop the instance >> (and later docker-compose up -d to get everything up again). >> >> I noticed the stop phase takes a while and ends with status code 137. >> I presume it ended forcefully and not gracefully. >> >> What is the idiomatic way to wait on SIGTERM and close the process >> gracefully? >> >> Thanks, Herby >> >

Oct. 29, 2017

Re: [Pharo-users] QCMagritte on Github

by Diego Lont

Hi, It was somewhere on my todo list to migrate to Github, but not very highâ¦ but I guess if someone else does this for me, I should be happy about this. So thank you, I will look up my gut hub account and also change the job. I hope to do this somewhere next week. I know there a different configurations for different versions of pharo, so did you import only one version, or should there be made branches for the different pharo version? Regards, Diego > On 27 Oct 2017, at 16:50, laurent laffont <laurent.laffont(a)gmail.com> wrote: > > I've added loading instructions in README: > > Metacello new > githubUser: 'Afibre' project: 'QCMagritte' commitish: 'master' path: 'src'; > baseline: 'QCMagritte'; > load. > > > For the QCMagritte version, there's actually one branch master. If you > need a previous version, I suppose the right way is to create a github > branch from the desired commit in git history and adapt the > BaselineOf... > > Laurent > > On Fri, Oct 27, 2017 at 2:12 PM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: >> Nice to know Laurent, >> >> Could you please comment or share how to install this version uploaded >> to GitHub? >> Any way to check the installed or current QCMagritte version? >> >> Cheers, >> >> HernÃ¡n >> >> >> >> >> 2017-10-27 7:39 GMT-03:00 laurent laffont <laurent.laffont(a)gmail.com>: >>> Hi, >>> >>> my team starts to use QCMagritte. For our needs we have imported >>> SmalltalkHub repository to Github here: >>> https://github.com/Afibre/QCMagritte >>> >>> I don't know if you (Diego, Stephan, Tobias) plan to use Github >>> instead of SmalltalkHub. At least Github allows branches & pull >>> request. >>> >>> Regards, >>> >>> Laurent Laffont >>> >> >

Oct. 29, 2017

Re: [Pharo-users] What is code 137 / how to gracefully shut down via SIGTERM?

by werner kassens

Hi Herby, eventually you might want to look at https://github.com/moby/moby/issues/1063 but then i dont know anything about these things. werner On 10/28/2017 01:39 PM, Herby VojÄÃk wrote: > Hi, > > I had to find out how to automatically deploy the backend written in > Pharo, and so far it uses docker-compose stop to stop the instance > (and later docker-compose up -d to get everything up again). > > I noticed the stop phase takes a while and ends with status code 137. > I presume it ended forcefully and not gracefully. > > What is the idiomatic way to wait on SIGTERM and close the process > gracefully? > > Thanks, Herby > >

Oct. 29, 2017

Re: [Pharo-users] What is code 137 / how to gracefully shut down via SIGTERM?

by Esteban Lorenzano

Hi, I donât know if is useful in your case, but you made me remember I made a small tool to trap unix signals within Pharo. I uploaded then to github. https://github.com/estebanlm/pharo-posix-signal <https://github.com/estebanlm/pharo-posix-signal> is very easy to use and it will allow you to trap any signal and do what you want ;) Esteban > On 28 Oct 2017, at 13:39, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > Hi, > > I had to find out how to automatically deploy the backend written in Pharo, and so far it uses docker-compose stop to stop the instance (and later docker-compose up -d to get everything up again). > > I noticed the stop phase takes a while and ends with status code 137. I presume it ended forcefully and not gracefully. > > What is the idiomatic way to wait on SIGTERM and close the process gracefully? > > Thanks, Herby >

Oct. 29, 2017

Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations

by henry

Yes well it is an extension to what you found as I combined with eventual references such that it computes in a single thread. - HH On Sat, Oct 28, 2017 at 23:59, Ben Coman <[btc(a)openinworld.com]("mailto:btc@openinworld.com")> wrote: > On Thu, Oct 26, 2017 at 12:00 AM, henry <[henry(a)callistohouse.club]("mailto:henry@callistohouse.club")> wrote: > >> I disabled vatId authorization in version 3, located in SessionOperations>> processIWant | SessionOperations>>processIAm: . >> >> I was asked to disseminate my news to Pharo Users, hello there. I was asked to describe ParrotTalk well, provide use cases and adopters of its use. Alright, I will give an attempt. >> >> ParrotTalk is an encrypted connection framework. Currently allowing anonymous 2048-bit key negotiation to establish user-provided encryption cipher and user-provided encoding and decoding, both through a provided SessionAgentMap to a starting SessionAgent server. Please look in the test case ThunkHelloWorldTest for building these maps and running a connection iwth data passing after encryption is established. There is a 4-way negotiation, from ProtocolOffered/Accepted to Go/GoToo. In using RSA 2048 signature validation and DH 2048 primes to establish the key used within the selected Cipher. The Cipher and Encoder are selected by name through the negotiation protocol. Currently three Ciphers are selectable, AESede, DESede, and DES. There are two encoders tested, asn1der, and Bytes. This protocol is described here, in this document. >> >> [https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFr…"https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFr…") >> >> For as to use cases, this encrypted connection has no third party, man-in-the-middle situation by not using Certificates. As such, this is a tight implementation of NSA-proof encryption without explicit authorization beyond knowledge of a host:port. The use cases involve any communication desired to be encrypted with such high encryption. The support will last my lifetime, so we have a settled solution, here in the third version, provided here. It requires version 111 of Cryptography, as a prerequisite. Both run on Squeak and Pharo. >> >> [http://www.squeaksource.com/Cryptography/Cryptography-zzz.111.mcz]("http://www.squeaksource.com/Cryptography/Cryptography-zzz.111.mcz") >> [http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz]("http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz") >> >> The current use is with my hubbub system, a promise-based distributed object implementation. I am working to bring ParrotTalk to Java and allow hubbub to operate interdependently between Squeak, Pharo, Java and any other languages which can support ParrotTalk and STON. My latest efforts with hubbub are to bring STON as the Layer 6 encoding. Hubbub depends on eLinda. > > Took me a while to track down what eLinda was. I presume its an implementation of Linda "a model of coordination and communication among several parallel processes operating upon objects stored in and retrieved from shared, virtual, associative memory" > [https://en.wikipedia.org/wiki/Linda_(coordination_language)]("https://en.wikipedia.org/wiki/Linda_(coordination_language)") > [http://www.cs.yale.edu/publications/techreports/tr984.pdf]("http://www.cs.yale.edu/publications/techreports/tr984.pdf") > > cheers -ben

Oct. 29, 2017

Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations

by Ben Coman

On Thu, Oct 26, 2017 at 12:00 AM, henry <henry(a)callistohouse.club> wrote: > I disabled vatId authorization in version 3, located in SessionOperations>>processIWant > | SessionOperations>>processIAm:. > > I was asked to disseminate my news to Pharo Users, hello there. I was > asked to describe ParrotTalk well, provide use cases and adopters of its > use. Alright, I will give an attempt. > > ParrotTalk is an encrypted connection framework. Currently allowing > anonymous 2048-bit key negotiation to establish user-provided encryption > cipher and user-provided encoding and decoding, both through a provided > SessionAgentMap to a starting SessionAgent server. Please look in the test > case ThunkHelloWorldTest for building these maps and running a connection > iwth data passing after encryption is established. There is a 4-way > negotiation, from ProtocolOffered/Accepted to Go/GoToo. In using RSA 2048 > signature validation and DH 2048 primes to establish the key used within > the selected Cipher. The Cipher and Encoder are selected by name through > the negotiation protocol. Currently three Ciphers are selectable, AESede, > DESede, and DES. There are two encoders tested, asn1der, and Bytes. This > protocol is described here, in this document. > > https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ > ParrotTalkFrameDesign-3.5.pdf > > For as to use cases, this encrypted connection has no third party, > man-in-the-middle situation by not using Certificates. As such, this is a > tight implementation of NSA-proof encryption without explicit authorization > beyond knowledge of a host:port. The use cases involve any communication > desired to be encrypted with such high encryption. The support will last my > lifetime, so we have a settled solution, here in the third version, > provided here. It requires version 111 of Cryptography, as a prerequisite. > Both run on Squeak and Pharo. > > http://www.squeaksource.com/Cryptography/Cryptography-zzz.111.mcz > http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz > > The current use is with my hubbub system, a promise-based distributed > object implementation. I am working to bring ParrotTalk to Java and allow > hubbub to operate interdependently between Squeak, Pharo, Java and any > other languages which can support ParrotTalk and STON. My latest efforts > with hubbub are to bring STON as the Layer 6 encoding. Hubbub depends on > eLinda. > Took me a while to track down what eLinda was. I presume its an implementation of Linda "a model of coordination and communication among several parallel processes operating upon objects stored in and retrieved from shared, virtual, associative memory" https://en.wikipedia.org/wiki/Linda_(coordination_language) http://www.cs.yale.edu/publications/techreports/tr984.pdf cheers -ben

Oct. 29, 2017

[ANN] OpenSSL wrapper

by Pierce Ng

Hi all, I've put up the _beginnings_ of a wrapper for OpenSSL on STH: Metacello new baseline: 'OpenSSL'; smalltalkhubUser: 'PierceNg' project: 'OpenSSL-Pharo'; load. Verified on Pharo 6 32- and 64-bit. My near term goal is to wrap enough libcrypto functionality to implement the client-side of Let's Encrypt. I meant to put it up on GH, for the ease of forking and PRs, but I couldn't get Iceberg to work, and gitfiletree also failed to load, so STH it is. Â¯\_(ã)_/Â¯ Collaboration welcome. Pierce

Oct. 29, 2017

Re: [Pharo-users] Actual Code to Improve the Pharo environment

by henry

Here is a diagram of the various components I am working on integrating,. [hubbub.jpg] - HH > -------- Original Message -------- > Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment > Local Time: October 28, 2017 1:23 PM > UTC Time: October 28, 2017 5:23 PM > From: henry(a)callistohouse.club > To: Andrew Glynn <aglynn42(a)gmail.com>, Any question about pharo iswelcome <pharo-users(a)lists.pharo.org> > > I used to use JINI, a fine system. I didnât know it had been rereleased as Apache River, Iâve been out of it awhile. This was the broker system that got me interested in Linda. Now I have an eventual Linda project called eLinda, which you can find in the Cryptography repository, no prerequisites needed. > > - HH > > On Sat, Oct 28, 2017 at 11:25, Andrew Glynn <aglynn42(a)gmail.com> wrote: > >> Iâm not working on that specifically, although what I am working on could definitely use that and vice versa, which would increase the capabilities of each. >> >> One thing Iâm working on is using Vert.x for service registration and discovery, mapped to Apache River (JINI) to propagate that over non-local network segments that require fully authenticated security (as a result, it also provides things such as Kerberos to Pharo apps). The mapping between the two is very straightforward, almost direct, but Iâve added the Synapse micro service bus to control data flows and secure access to remote services. >> >> It enables things like automatic configuration/integration of Pharo based mobile apps with newer cars that support that kind of autoconfiguration, since they all use JINI to do so. Thus a Pharo mobile or IoT app can automatically be configured to work with any of the carâs subsystems that are relevant to it. >> >> JINI is far more used than people realize, partly because it âjust worksâ and as a result doesnât get the public âsqueaky wheelâ effect. The fact that the authors of Vert.x reimplemented half of the features of JINI, in a less comprehensive and less reliable way, rather than just using it (especially considering itâs open source) shows the degree to which that effect is operative. >> >> Thereâs probably a couple dozen other general use cases where the integration will allow Pharo apps to âjust workâ in a JINI or Vert.x environment, as well as thousands of industry/company specific ones. Iâd have to mode-switch to think of them off the top of my head though ð. >> >> Andrew >> >> Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 >> >> From: [henry](mailto:henry@callistohouse.club) >> Sent: Saturday, October 28, 2017 10:02 AM >> To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org) >> Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment >> >> Hi Andrew, >> >> Are you working to bring a Capabilities model to Pharo? This is precisely what I am working to bring with Hubbub, running on top of my ParrotTalk. I derived these from erights.org's ELib and have been working on them for many years. Now that ParrotTalk has stabilized (layer 5) I am shifting to implementing marshalling of layer 6 objects using STON all to run on top of ParrotTalk. Once I get marshalling with scope substitutions, I will debug Hubbub to offer distributed Capabilities. >> >> What work are you undertaking? >> >> Regards, >> >> - HH >> >>> -------- Original Message -------- >>> >>> Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment >>> >>> Local Time: October 28, 2017 9:12 AM >>> >>> UTC Time: October 28, 2017 1:12 PM >>> >>> From: aglynn42(a)gmail.com >>> >>> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>> >>> Writing that kind of code is another of the reasons I decided I donât want to work in anything else ð. Maybe more important than some of the others, both to myself and to other users. >>> >>> Iâve gained so much personally, mostly for nothing, even just considering the relatively few projects I have been able to work on in Pharo and previously in Squeak, VW and VA. Unfortunately in most I havenât been able to make the code public, since they were for entities like the government, DoD, etc. >>> >>> Not that VA attracts me quite so much to give back all that strongly, when a license is $8500+. Were it possible to give back to VA C++ or VA Java, it might be different, but neither were OSS although they werenât expensive. More relevantly, both are now abandonware (hence my comment about IBM, which is applicable to OS/2 as well, although that has quietly had a 5.0 version released in June of this year). >>> >>> I would, though, love a chance to give back to Pharo primarily, although I may port anything relevant to Squeak, and if I have sufficient time port it to VW, which although not OSS is at least affordable to most developers. >>> >>> Iâm nearly there on a couple of projects â one Iâm testing and making final tweaks, another is about 2/3dâs of the way. >>> >>> The first project you (and others on the list) may be more immediately interested in testing, since it requires little to no additional work to use it, and even if not perfect, since itâs intended to directly help work you are doing in Pharo, it may worthwhile. Iâm hoping to have it ready for public consumption by the middle of November. >>> >>> On a different but related topic, the article I wrote got a fair amount of interest considering I donât write nearly as well as Kenneth, for example. Including direct interest from some well known industry people, which canât hurt. In an indirect way it may even be helpful, but not in the real, direct way decent code is. >>> >>> Capabilities that wonât be available in anything else in an really usable way (because to be efficient they depend on capabilities not found in anything else), and in any case nowhere near as useful in anything else, will hopefully be more use than any article can be, never mind one I wrote, not just to me but also to other Pharo users and to Pharo itself. >>> >>> Cheers >>> >>> Andrew Glynn >>> >>> Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 >>> >>> From: [Stephane Ducasse](mailto:stepharo.self@gmail.com) >>> >>> Sent: Saturday, October 28, 2017 5:09 AM >>> >>> To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org) >>> >>> Subject: Re: [Pharo-users] Smalltalk Argument >>> >>> Hi andrew >>> >>> please take a project that would help to bring more companies and that you want to push and push it with us :). >>> >>> Stef >>> >>> On Sat, Oct 28, 2017 at 11:05 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>>> Hi andrew >>>> >>>> you should contact esteban because he is writing an objective-C bridge. >>>> >>>> Stef >>>> >>>> On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: >>>> >>>>> One thing Iâm working on is a bridge between Pharo and F-Script. F-Script is, basically, a Smalltalk dialect, as is obvious from the screenshot. However for MacOS and iOS, it allows you to bypass the static Objective-C API interface and debug / modify or even write applications directly in the system. To do that you âinjectâ F-Script into the OS. The ability to so has a specific implication, though. MacOS and iOS are themselves written in and as a dialect of Smalltalk. (were it simply an overlay on Objective-C, it wouldnât be able to do things that are impossible in Objective-C, and it wouldnât need to be âinjectedâ in order to run). Every implementation of Objective-C , bar GNUâs useless imitation, compiles to Smalltalk. No surprise that Appleâs does, as well. >>>>> >>>>> In any event, it will allow Pharo code to be mapped to MacOS and iOS objects, injected into the system dynamically, and modified / debugged dynamically using the Pharo tools. The result, at least as far as iOS is concerned, may make Pharo actually the most powerful way to program it, well beyond XCode alone, along with doing the same for MacOS. Android is another issue, although the Raspbian port of Pharo should be relatively easy to port to it. For me, unless someone had a use case, I donât have one myself for Android. Iâve tried nearly every version, because Iâd love to support an OSS ecosystem, unfortunately using it compared to the iPhone is still like driving a Fiero based kit car compared to an actual Ferrari. >>>>> >>>>> As far as JNI, while I see your point, JNI is such a PITA that few Java developers know it. My usual workaround is to use Stamp and Synapse, which has the further advantage of allowing Java to âthrottleâ data that the JVM canât deal with at full speed. >>>>> >>>>> As far as dealing with other JVM languages, PetitParser or SmaCC can generate bytecode rather than Java or other JVM code, and that allows libs to be written that utilize Synapse to talk to Pharo. It isnât necessarily an ideal solution, but a possible one without having to support umpteen environments. Another potential way of accomplishing that is to use NetRexx, a declarative JVM language, which is both easy and terse, and like SQL, generates the actual bytecode rather than precompiling to it. For instance, imagine the code needed for a simple âhello worldâ in Java, then compare: >>>>> >>>>> Say âhello worldâ >>>>> >>>>> Since it generates virtually the same bytecode, it may be an easy way to do it. >>>>> >>>>> With the last statement, that expresses really well the exact reason I no longer want to work in most other environments ð. >>>>> >>>>> Tc >>>>> >>>>> Andrew >>>>> >>>>> Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 >>>>> >>>>> From: phil(a)highoctane.be >>>>> >>>>> Sent: Thursday, October 26, 2017 2:19 AM >>>>> >>>>> To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org) >>>>> >>>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>>> >>>>> 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](tel:%2B49%207141%2056%2010%2086%200) Fax: [+49 7141 56 10 86 1](tel:%2B49%207141%2056%2010%2086%201)

Oct. 29, 2017

Re: [Pharo-users] [ANN] Grafoscopio is now also an indexedpublication

by Offray

Thanks Andrew. I'm glad to know that Grafoscopio has been useful to you and to meet new users. I'll be waiting for your release and to learn from it. Those use cases where the tool itself is changed are really valuable and worthy to me. Cheers, Offray El 28 de octubre de 2017 10:37:01 GMT-05:00, Andrew Glynn <aglynn42(a)gmail.com> escribiÃ³: >Btw, thank you personally. In another project Iâve started to use both >Grafoscopio itself (from a developer perspective) but also >programmatically to improve that project. Hopefully Iâll be able to >release that project soon (i.e. in the next couple of weeks) and youâll >be able to see how Grafoscopio improvise it, but also how it increases >the capabilities of Grafoscopio. > >Andrew Glynn > >Sent from Mail for Windows 10 > >From: Offray Vladimir Luna CÃ¡rdenas >Sent: Saturday, October 28, 2017 11:02 AM >To: pharo-users(a)lists.pharo.org >Subject: Re: [Pharo-users] [ANN] Grafoscopio is now also an >indexedpublication > >Thanks Stephan, > >As told many times. This community has been really empowering to >prototype the artifacts for my PhD (which is *not* in software [1]). Is >good to count with such proactive and helpful community. > >[1] http://www.doctoradoendiseno.com/en > >This learning process is just starting. > >Cheers, > >Offray > >On 28/10/17 09:27, Stephane Ducasse wrote: >> well done. >> >> >> On Sat, Oct 28, 2017 at 12:58 AM, Offray Vladimir Luna CÃ¡rdenas >> <offray.luna(a)mutabit.com> wrote: >>> Hi, >>> >>> I would like to share with you the recent acceptation of Grafoscopio >in the >>> Journal of Open Source Software (JOSS), which makes it also an >indexed >>> publication. More details at: >>> >>> http://joss.theoj.org/papers/10.21105/joss.00251 >>> >>> I would like to thank Serge Stinchwich (from this community) and >Arfon >>> Smith (from JOSS) for reviewing the software and helping me with the >>> publication process. >>> >>> Cheers, >>> >>> Offray >>> >>> === >>> >>> About JOSS (http://joss.theoj.org/about) >>> >>> "The Journal of Open Source Software (JOSS) is a developer friendly >journal >>> for research software packages. >>> >>> [...] The Journal of Open Source Software (JOSS) is an academic >journal >>> (ISSN 2475-9066) with a formal peer review process that is designed >to >>> improve the quality of the software submitted. Upon acceptance into >JOSS, a >>> CrossRef DOI is minted and we list your paper on the JOSS website." >>> >>> === >> -- Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

Oct. 28, 2017

Re: [Pharo-users] [ANN] Iceberg 0.6.2 backported to Pharo 6.1

by Herby VojÄÃk

Thanks. I did not yet try if I can use it for push, but it's great already as I could remove all the workarounds I needed before to work with the local repo. Herby Esteban Lorenzano wrote: > Hi, > > I backported lastest Iceberg version to Pharo 6.1 to allow people to benefit for latest changes. > This version has an important amount of tweak and fixes, but most important is the inclusion of tonel file format (this is default for Pharo 7.0, optional for Pharo 6.1) and introduces a file-per-class format. > The advantages of this format has everything to do with the speed of access (is easier to reconstruct a package like) and the space on disk (methods are usually small but minimum space in disk is usually 4k so we waste a lot of space). Is also a better format for SSD disks. > > To backport Iceberg 0.6.2 I also needed to backport latest version of Metacello, so Pharo 6.1 and Pharo7+ users now also have the latest version of it available :) > > cheers! > Esteban > > > > >

Oct. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

I will, although in some ways the two may be more complementary than anything. Sent from Mail for Windows 10 From: Stephane Ducasse Sent: Saturday, October 28, 2017 5:06 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Hi andrew you should contact esteban because he is writing an objective-C bridge.Â Stef On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: One thing Iâm working on is a bridge between Pharo and F-Script.Â F-Script is, basically, a Smalltalk dialect, as is obvious from the screenshot.Â However for MacOS and iOS, it allows you to bypass the static Objective-C API interface and debug / modify or even write applications directly in the system.Â To do that you âinjectâ F-Script into the OS.Â The ability to so has a specific implication, though.Â MacOS and iOS are themselves written in and as a dialect of Smalltalk.Â (were it simply an overlay on Objective-C, it wouldnât be able to do things that are impossible in Objective-C, and it wouldnât need to be âinjectedâ in order to run).Â Every implementation of Objective-C , bar GNUâs useless imitation, compiles to Smalltalk.Â No surprise that Appleâs does, as well. Â In any event, it will allow Pharo code to be mapped to MacOS and iOS objects, injected into the system dynamically, and modified / debugged dynamically using the Pharo tools.Â The result, at least as far as iOS is concerned, may make Pharo actually the most powerful way to program it, well beyond XCode alone, along with doing the same for MacOS.Â Android is another issue, although the Raspbian port of Pharo should be relatively easy to port to it. For me, unless someone had a use case, I donât have one myself for Android.Â Iâve tried nearly every version, because Iâd love to support an OSS ecosystem, unfortunately using it compared to the iPhone is still like driving a Fiero based kit car compared to an actual Ferrari. Â As far as JNI, while I see your point, JNI is such a PITA that few Java developers know it.Â My usual workaround is to use Stamp and Synapse, which has the further advantage of allowing Java to âthrottleâ data that the JVM canât deal with at full speed. Â As far as dealing with other JVM languages, PetitParser or SmaCC can generate bytecode rather than Java or other JVM code, and that allows libs to be written that utilize Synapse to talk to Pharo.Â It isnât necessarily an ideal solution, but a possible one without having to support umpteen environments.Â Another potential way of accomplishing that is to use NetRexx, a declarative JVM language, which is both easy and terse, and like SQL, generates the actual bytecode rather than precompiling to it.Â For instance, imagine the code needed for a simple âhello worldâ in Java, then compare: Â Say âhello worldâ Â Since it generates virtually the same bytecode, it may be an easy way to do it. Â With the last statement, that expresses really well the exact reason I no longer want to work in most other environments ð. Â Tc Andrew Â Â Â Sent from Mail for Windows 10 Â From: phil(a)highoctane.be Sent: Thursday, October 26, 2017 2:19 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Â 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. 28, 2017

Re: [Pharo-users] perspective request for those earning a living fromSmalltalk

by Richard Sargent

Thank you , Andrew, for that back-story! I really liked OS/2 and was extremely reluctant to give it up; it had a really good design. On Sat, Oct 28, 2017 at 10:59 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > Your history is accurate, but thereâs a few things Iâd like to add, due > to having been employed by IBM at exactly that period working specifically > on VisualAge, not only for Smalltalk, but for Java, C++ and Cobol as well. > (my NDAâs finally having expired also helps ð). Itâs not a correction > or contradiction, but a complement to your description, providing a > relevant but different perspective. > > > > IBM *did* tell some of their customers to move to Java, but that was > partly based on the existence of VisualAge for Java, which in some ways > went beyond VA Smalltalk, in others not as far, but did make migration to > Java easier, and in some cases possible at all. Its replacement, Eclipse, > simply doesnât. And it could do so, because as with all VisualAge > products, it was written in Smalltalk. One of the things that annoys me > about the whole thing the most is that the biggest complaint, which was a > partial but significant reason it wasnât more popular, was from developers > who âcouldnât see their filesâ, i.e. couldnât edit them in vi(le) and build > on the command line. I heard that complaint on a project using both the > Java and C++ versions so many times I finally responded ânobody gives a > shit about your f*cking filesâ, in the middle of the office at Pratt & > Whitney Aerospace, lol. > > > > Since VA for Java (and VA C++) are now abandonware, itâs an example of > what I meant by owning a market, failing to promote it, and thereby > destroying it, and also the reason I referred to IBM specifically as being > âvery good at it' > > > > I was involved in writing a major application in both Java and C++ using > CORBA in 2000-2002, and on that we also used both VA C++ and VA Java. > Otherwise, quite honestly, we may not have finished it despite having some > brilliant people on the team, since doing CORBA manually, especially with > object trees that use C++ multiple inheritance, can be near impossible to > get working reliably. > > > > Unfortunately, due to being abandoned, the core of the app is no longer > even buildable with current tools. If you look at the binary jars in the > latest release (2016) the dates on them are still mid-2002. The most > surprising thing to me is that they still run at all, particularly with > Java 8 on current platforms (mainly Solaris 11 and Windows 10), considering > they were written and built on Java 1.3.1, and although they targeted > Windows and Solaris/AIX, were in fact written on OS/2 v. 4, because Solaris > didnât run at the time on any laptop, and Windows 2000 *loaded* on a high > spec laptop for the time but couldnât really be judged to be *running*, > i.e. it loaded and proceeded to thrash to the degree that nothing further > got accomplished. > > > > VA Smalltalk as itâs publicly available (at the not insignificant cost of > ~$8500+ per license), is written on a base IBM Smalltalk thatâs ~26 years > old. Instantiations has improved some things, but the core is vastly out > of date. Meanwhile, IBM themselves have a fully current version (the last > version I saw, when visiting a former colleague at the lab, was released > early last year, but is only available internally. This wasnât one of the > four I referred to in my other post, but nearly qualifies as âpublicly > unavailableâ, since the available version is not nearly the same. > > > > VA is also very out of date in comparison with VW, Pharo, F-Script and > Squeak, not only in comparison with the internal version. In particular > the UI doesnât fully incorporate the improvements made (largely via the > Announcer) in Morphic and the other current Smalltalk GUIâs. Like Swing > and SWT, part of those improvements are there, but that in many ways only > makes things worse. That WindowBuilder (available free for Java in > Eclipse, but not for free in VA Smalltalk) is in fact a simple port of the > original Smalltalk version is demonstration enough that the UI is not > significantly different than the UI in Eclipse itself, or in Swing, since > Swing is also supported by WindowBuilder. > > > > As an example of the remaining problems, I recently reverse engineered a > complex legacy database via the Eclipse Dali JPA tools in order to make it > available to BIRT / Talend for reporting. On an i7 with the DB on an SSD, > it took over 950 CPU hours to complete. As of today, it has been in > process of exiting for another 140 CPU hours, trying to catch up with the > events triggered by Dali. > > > > Perhaps that helps understand why Iâm not thrilled with even some of the > better libraries in many other environments. > > > > Outside Smalltalk and languages with IDEâs written in it. OS/2 is a > great example of owning a market, then destroying it by not promoting it. > OS/2 never owned the mainstream market of course, but what it did largely > own was the smaller but sometimes crucial market for PC based systems that > could run complex software reliably. Despite having âkilledâ OS/2 13 years > ago, version 5.0 came out in June, released by a âcompanyâ of former IBM > people financed by IBM, whose company name means ânew boxâ. > > > > The reason IBM canât completely kill it is that companies who canât move > software off it, because every attempt to do so (to either Windows Server > or different forms of *nix) has failed, in some cases over a dozen times, > include such small entities as Boeing, MIT, NASA, the US government, > including all four branches of the military, all of the worldâs airlines, > GE, Rolls Royce, Pratt & Whitney, GM, Siemens, AT&T, and Citibank, just to > name a few I know of (and none are exactly publicizing the fact). Despite > the existence, today, of both Linux and Solaris on x86, and the > improvements between Windows NT in the 1990âs and Windows Server today, > institutions with fairly capable developers, such as MIT and Bell Labs, > just to name two, canât port software they simultaneously canât be without, > to any of those platforms. There *is* a specific technology in OS/2 not > available elsewhere that is the main culprit, the Distributed System Object > Model. Somewhat ironically though, one of the main uses of SOM/DSOM is to > provide the type of live object manipulation and debugging to the core > environment (and in a distributed manner) common in dialects of Smalltalk > but virtually unknown otherwise. > > > > The person I learned Java RMI, JINI and J2EE architecture from was, by > happenstance, the same person who architected OS/2. A somewhat humorous > story is that IBM dropped out of a project begun with Sun in the late > 1990âs to write a pure JavaOS. IBMâs reason for dropping out was > embarrassment at the fact that pure Java apps ran faster on OS/2 than on > the pure JavaOS. Sun couldnât at the time afford to complete it on their > own so it disappeared, as unreleased products do, without even the marginal > trace of existing on abandonware sites. That person was also, > unsurprisingly, one of the key developers of IBM Smalltalk. > > > > Iâm not claiming that IBM or anyone else does such things in a completely > aware way. Rather, the fact that efficient environments are difficult to > build without significant time and resources (both are necessary because no > matter how many resources are available, rushing the development will > result in mistakes that have to be fixed later, giving the environment an > unstable base to build on), combined with the advantage industry > inefficiencies provide to the companies *with* those resources, makes the > situation relatively easy to reinforce *without *really needing to admit > what youâre doing, particularly to yourself. > > > > Andrew > > > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > > *From: *jtuchel(a)objektfabrik.de > *Sent: *Monday, October 23, 2017 3:32 AM > *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject: *Re: [Pharo-users] perspective request for those earning a > living fromSmalltalk > > > > Petr, > > > > I've been working as a Consultant for many big corporations (mainly in > > VA Smalltalk) since 1996. The situation you describe is very well known > > to me. But in my opinion there is no technical reason for this. It's a > > managerial problem. Ever since IBM went out to their customers and told > > them to move to Java for the better ini the mid-90ies, managers wanted > > the Smalltalk projects to go away as fast as possible. Nobody asked why > > IBM was still happily using VisualAge Smalltalk internally at that time > > frame.... > > > > So the Smalltalk projects were declared legacy by Management. > > Replacement projects were started with big efforts and optimism. Some > > went well, some somewhat came to fly in a bit more than double the time > > and much more times the costthan planned, some failed miserably. One > > thing was in common to the replacement projects all over the place: they > > took much longer, turned out to be much mor complicated and took a lot > > more manpower than anybody had ever imagined. > > > > So two important things happened: > > > > 1) People were told the old Smalltalk stuff would be gone soon, so if > > you wanted to be a valued and appreciated staff member, you better stay > > away from these projects > > 2) The people who knew the business and technical side of the existing > > projects were moved to the new projects. Some liked it (because of 1) > > some were frustrated (because they knew / feared the new project was > > going to be a death march) > > > > > > Over the first 2 years or so, nobody realized how bad the situation > > really was. It was easy to postpone user requirements to the new > > project, accumulate more and more manpower in the new project and still > > keep up green flags everywhere. > > > > ...until yellow was the new green and users/stakeholders wanted the new > > features NOW - and not one day when the replacement project would become > > real. > > > > So the remaining manpower in the old project (not the ones with lots of > > experience and knowledge) had to extend the old system, integrate it > > with the new system (thereby implementing all the stuff that IBM once > > told their management would never be possible in Smalltalk) and keep it > > up and ranning year after year. Nobody ever said Thank You or would > > appreciate the work they did. Because that was old stuff anyways and was > > already irrelevant. > > > > > > Some of these old systems still exist today, serving users every single > > day, while some of the new systems never appeared. No manpower was ever > > added to these projects, and never would anybody ever say: okay, guys, > > you won. They still work on legacy code and try to do their best to > > fulfill user requirements. While on other projects that never see the > > light of day, people get appreciation, are allowed to work with new > > technologies and do cool stuff. Nobody ever asked the Smalltalkers > > whether they could do that as well, because "if you want to do web, you > > need to do Java". IBM said so, you know (and many other consultants as > > well). > > > > So this is why new people try to stay away from these old projects. This > > is why the remaining staff is frustrated and this is why nobody allows > > them to do the cool things that Smalltalk can do as well as the others. > > They are just required to fix bugs, add new features in the old GUIs and > > else keep silent. Some of them were trying to fight this and tried to > > prove Smalltalk's strengths, but back then nobody would listen. One day > > they gave up. > > > > > > Management still frustrates people every. single. day. > > > > > > Just my opinion > > > > > > Joachim > > > > > > > > > > Am 22.10.17 um 18:56 schrieb Petr Fischer: > > > Here. (But from one point of view, it's a litte misery, 10-20 year old > code sometimes, a mess, old VAST, absolutely no interest from young > colleagues with no experience to willingly learn something about Smalltalk > etc etc.). > > > > > > If I bring up enough arguments, we will use Gemstone+Pharo tools in the > future, which is a dream for me... but, we will see... > > > > > > pf > > > > > >> At https://news.ycombinator.com/item?id=15523807 > > >> the question is asked... "Does anyone on here program in Smalltalk > > >> professionally? Not to get off topic, but I'm curious and would like to > > >> know how it stacks up compared to what they did previously? " > > >> > > >> If you've earning a living from programming Smalltalk, please drop a > > >> comment there. > > >> > > >> cheers -ben > > > > > > > -- > > ----------------------------------------------------------------------- > > 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. 28, 2017

Re: [Pharo-users] perspective request for those earning a living fromSmalltalk

by Andrew Glynn

Your history is accurate, but thereâs a few things Iâd like to add, due to having been employed by IBM at exactly that period working specifically on VisualAge, not only for Smalltalk, but for Java, C++ and Cobol as well. (my NDAâs finally having expired also helps ð). Itâs not a correction or contradiction, but a complement to your description, providing a relevant but different perspective. IBM did tell some of their customers to move to Java, but that was partly based on the existence of VisualAge for Java, which in some ways went beyond VA Smalltalk, in others not as far, but did make migration to Java easier, and in some cases possible at all. Its replacement, Eclipse, simply doesnât. And it could do so, because as with all VisualAge products, it was written in Smalltalk. One of the things that annoys me about the whole thing the most is that the biggest complaint, which was a partial but significant reason it wasnât more popular, was from developers who âcouldnât see their filesâ, i.e. couldnât edit them in vi(le) and build on the command line. I heard that complaint on a project using both the Java and C++ versions so many times I finally responded ânobody gives a shit about your f*cking filesâ, in the middle of the office at Pratt & Whitney Aerospace, lol. Since VA for Java (and VA C++) are now abandonware, itâs an example of what I meant by owning a market, failing to promote it, and thereby destroying it, and also the reason I referred to IBM specifically as being âvery good at it' I was involved in writing a major application in both Java and C++ using CORBA in 2000-2002, and on that we also used both VA C++ and VA Java. Otherwise, quite honestly, we may not have finished it despite having some brilliant people on the team, since doing CORBA manually, especially with object trees that use C++ multiple inheritance, can be near impossible to get working reliably. Unfortunately, due to being abandoned, the core of the app is no longer even buildable with current tools. If you look at the binary jars in the latest release (2016) the dates on them are still mid-2002. The most surprising thing to me is that they still run at all, particularly with Java 8 on current platforms (mainly Solaris 11 and Windows 10), considering they were written and built on Java 1.3.1, and although they targeted Windows and Solaris/AIX, were in fact written on OS/2 v. 4, because Solaris didnât run at the time on any laptop, and Windows 2000 loaded on a high spec laptop for the time but couldnât really be judged to be running, i.e. it loaded and proceeded to thrash to the degree that nothing further got accomplished. VA Smalltalk as itâs publicly available (at the not insignificant cost of ~$8500+ per license), is written on a base IBM Smalltalk thatâs ~26 years old. Instantiations has improved some things, but the core is vastly out of date. Meanwhile, IBM themselves have a fully current version (the last version I saw, when visiting a former colleague at the lab, was released early last year, but is only available internally. This wasnât one of the four I referred to in my other post, but nearly qualifies as âpublicly unavailableâ, since the available version is not nearly the same. VA is also very out of date in comparison with VW, Pharo, F-Script and Squeak, not only in comparison with the internal version. In particular the UI doesnât fully incorporate the improvements made (largely via the Announcer) in Morphic and the other current Smalltalk GUIâs. Like Swing and SWT, part of those improvements are there, but that in many ways only makes things worse. That WindowBuilder (available free for Java in Eclipse, but not for free in VA Smalltalk) is in fact a simple port of the original Smalltalk version is demonstration enough that the UI is not significantly different than the UI in Eclipse itself, or in Swing, since Swing is also supported by WindowBuilder. As an example of the remaining problems, I recently reverse engineered a complex legacy database via the Eclipse Dali JPA tools in order to make it available to BIRT / Talend for reporting. On an i7 with the DB on an SSD, it took over 950 CPU hours to complete. As of today, it has been in process of exiting for another 140 CPU hours, trying to catch up with the events triggered by Dali. Perhaps that helps understand why Iâm not thrilled with even some of the better libraries in many other environments. Outside Smalltalk and languages with IDEâs written in it. OS/2 is a great example of owning a market, then destroying it by not promoting it. OS/2 never owned the mainstream market of course, but what it did largely own was the smaller but sometimes crucial market for PC based systems that could run complex software reliably. Despite having âkilledâ OS/2 13 years ago, version 5.0 came out in June, released by a âcompanyâ of former IBM people financed by IBM, whose company name means ânew boxâ. The reason IBM canât completely kill it is that companies who canât move software off it, because every attempt to do so (to either Windows Server or different forms of *nix) has failed, in some cases over a dozen times, include such small entities as Boeing, MIT, NASA, the US government, including all four branches of the military, all of the worldâs airlines, GE, Rolls Royce, Pratt & Whitney, GM, Siemens, AT&T, and Citibank, just to name a few I know of (and none are exactly publicizing the fact). Despite the existence, today, of both Linux and Solaris on x86, and the improvements between Windows NT in the 1990âs and Windows Server today, institutions with fairly capable developers, such as MIT and Bell Labs, just to name two, canât port software they simultaneously canât be without, to any of those platforms. There is a specific technology in OS/2 not available elsewhere that is the main culprit, the Distributed System Object Model. Somewhat ironically though, one of the main uses of SOM/DSOM is to provide the type of live object manipulation and debugging to the core environment (and in a distributed manner) common in dialects of Smalltalk but virtually unknown otherwise. The person I learned Java RMI, JINI and J2EE architecture from was, by happenstance, the same person who architected OS/2. A somewhat humorous story is that IBM dropped out of a project begun with Sun in the late 1990âs to write a pure JavaOS. IBMâs reason for dropping out was embarrassment at the fact that pure Java apps ran faster on OS/2 than on the pure JavaOS. Sun couldnât at the time afford to complete it on their own so it disappeared, as unreleased products do, without even the marginal trace of existing on abandonware sites. That person was also, unsurprisingly, one of the key developers of IBM Smalltalk. Iâm not claiming that IBM or anyone else does such things in a completely aware way. Rather, the fact that efficient environments are difficult to build without significant time and resources (both are necessary because no matter how many resources are available, rushing the development will result in mistakes that have to be fixed later, giving the environment an unstable base to build on), combined with the advantage industry inefficiencies provide to the companies with those resources, makes the situation relatively easy to reinforce without really needing to admit what youâre doing, particularly to yourself. Andrew Sent from Mail for Windows 10 From: jtuchel(a)objektfabrik.de Sent: Monday, October 23, 2017 3:32 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] perspective request for those earning a living fromSmalltalk Petr, I've been working as a Consultant for many big corporations (mainly in VA Smalltalk) since 1996. The situation you describe is very well known to me. But in my opinion there is no technical reason for this. It's a managerial problem. Ever since IBM went out to their customers and told them to move to Java for the better ini the mid-90ies, managers wanted the Smalltalk projects to go away as fast as possible. Nobody asked why IBM was still happily using VisualAge Smalltalk internally at that time frame.... So the Smalltalk projects were declared legacy by Management. Replacement projects were started with big efforts and optimism. Some went well, some somewhat came to fly in a bit more than double the time and much more times the costthan planned, some failed miserably. One thing was in common to the replacement projects all over the place: they took much longer, turned out to be much mor complicated and took a lot more manpower than anybody had ever imagined. So two important things happened: 1) People were told the old Smalltalk stuff would be gone soon, so if you wanted to be a valued and appreciated staff member, you better stay away from these projects 2) The people who knew the business and technical side of the existing projects were moved to the new projects. Some liked it (because of 1) some were frustrated (because they knew / feared the new project was going to be a death march) Over the first 2 years or so, nobody realized how bad the situation really was. It was easy to postpone user requirements to the new project, accumulate more and more manpower in the new project and still keep up green flags everywhere. ...until yellow was the new green and users/stakeholders wanted the new features NOW - and not one day when the replacement project would become real. So the remaining manpower in the old project (not the ones with lots of experience and knowledge) had to extend the old system, integrate it with the new system (thereby implementing all the stuff that IBM once told their management would never be possible in Smalltalk) and keep it up and ranning year after year. Nobody ever said Thank You or would appreciate the work they did. Because that was old stuff anyways and was already irrelevant. Some of these old systems still exist today, serving users every single day, while some of the new systems never appeared. No manpower was ever added to these projects, and never would anybody ever say: okay, guys, you won. They still work on legacy code and try to do their best to fulfill user requirements. While on other projects that never see the light of day, people get appreciation, are allowed to work with new technologies and do cool stuff. Nobody ever asked the Smalltalkers whether they could do that as well, because "if you want to do web, you need to do Java". IBM said so, you know (and many other consultants as well). So this is why new people try to stay away from these old projects. This is why the remaining staff is frustrated and this is why nobody allows them to do the cool things that Smalltalk can do as well as the others. They are just required to fix bugs, add new features in the old GUIs and else keep silent. Some of them were trying to fight this and tried to prove Smalltalk's strengths, but back then nobody would listen. One day they gave up. Management still frustrates people every. single. day. Just my opinion Joachim Am 22.10.17 um 18:56 schrieb Petr Fischer: > Here. (But from one point of view, it's a litte misery, 10-20 year old code sometimes, a mess, old VAST, absolutely no interest from young colleagues with no experience to willingly learn something about Smalltalk etc etc.). > > If I bring up enough arguments, we will use Gemstone+Pharo tools in the future, which is a dream for me... but, we will see... > > pf > >> At https://news.ycombinator.com/item?id=15523807 >> the question is asked... "Does anyone on here program in Smalltalk >> professionally? Not to get off topic, but I'm curious and would like to >> know how it stacks up compared to what they did previously? " >> >> If you've earning a living from programming Smalltalk, please drop a >> comment there. >> >> cheers -ben > -- ----------------------------------------------------------------------- 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. 28, 2017

Re: [Pharo-users] Actual Code to Improve the Pharo environment

by henry

I used to use JINI, a fine system. I didnât know it had been rereleased as Apache River, Iâve been out of it awhile. This was the broker system that got me interested in Linda. Now I have an eventual Linda project called eLinda, which you can find in the Cryptography repository, no prerequisites needed. - HH On Sat, Oct 28, 2017 at 11:25, Andrew Glynn <aglynn42(a)gmail.com> wrote: > Iâm not working on that specifically, although what I am working on could definitely use that and vice versa, which would increase the capabilities of each. > > One thing Iâm working on is using Vert.x for service registration and discovery, mapped to Apache River (JINI) to propagate that over non-local network segments that require fully authenticated security (as a result, it also provides things such as Kerberos to Pharo apps). The mapping between the two is very straightforward, almost direct, but Iâve added the Synapse micro service bus to control data flows and secure access to remote services. > > It enables things like automatic configuration/integration of Pharo based mobile apps with newer cars that support that kind of autoconfiguration, since they all use JINI to do so. Thus a Pharo mobile or IoT app can automatically be configured to work with any of the carâs subsystems that are relevant to it. > > JINI is far more used than people realize, partly because it âjust worksâ and as a result doesnât get the public âsqueaky wheelâ effect. The fact that the authors of Vert.x reimplemented half of the features of JINI, in a less comprehensive and less reliable way, rather than just using it (especially considering itâs open source) shows the degree to which that effect is operative. > > Thereâs probably a couple dozen other general use cases where the integration will allow Pharo apps to âjust workâ in a JINI or Vert.x environment, as well as thousands of industry/company specific ones. Iâd have to mode-switch to think of them off the top of my head though ð. > > Andrew > > Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 > > From: [henry](mailto:henry@callistohouse.club) > Sent: Saturday, October 28, 2017 10:02 AM > To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org) > Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment > > Hi Andrew, > > Are you working to bring a Capabilities model to Pharo? This is precisely what I am working to bring with Hubbub, running on top of my ParrotTalk. I derived these from erights.org's ELib and have been working on them for many years. Now that ParrotTalk has stabilized (layer 5) I am shifting to implementing marshalling of layer 6 objects using STON all to run on top of ParrotTalk. Once I get marshalling with scope substitutions, I will debug Hubbub to offer distributed Capabilities. > > What work are you undertaking? > > Regards, > > - HH > >> -------- Original Message -------- >> >> Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment >> >> Local Time: October 28, 2017 9:12 AM >> >> UTC Time: October 28, 2017 1:12 PM >> >> From: aglynn42(a)gmail.com >> >> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >> >> Writing that kind of code is another of the reasons I decided I donât want to work in anything else ð. Maybe more important than some of the others, both to myself and to other users. >> >> Iâve gained so much personally, mostly for nothing, even just considering the relatively few projects I have been able to work on in Pharo and previously in Squeak, VW and VA. Unfortunately in most I havenât been able to make the code public, since they were for entities like the government, DoD, etc. >> >> Not that VA attracts me quite so much to give back all that strongly, when a license is $8500+. Were it possible to give back to VA C++ or VA Java, it might be different, but neither were OSS although they werenât expensive. More relevantly, both are now abandonware (hence my comment about IBM, which is applicable to OS/2 as well, although that has quietly had a 5.0 version released in June of this year). >> >> I would, though, love a chance to give back to Pharo primarily, although I may port anything relevant to Squeak, and if I have sufficient time port it to VW, which although not OSS is at least affordable to most developers. >> >> Iâm nearly there on a couple of projects â one Iâm testing and making final tweaks, another is about 2/3dâs of the way. >> >> The first project you (and others on the list) may be more immediately interested in testing, since it requires little to no additional work to use it, and even if not perfect, since itâs intended to directly help work you are doing in Pharo, it may worthwhile. Iâm hoping to have it ready for public consumption by the middle of November. >> >> On a different but related topic, the article I wrote got a fair amount of interest considering I donât write nearly as well as Kenneth, for example. Including direct interest from some well known industry people, which canât hurt. In an indirect way it may even be helpful, but not in the real, direct way decent code is. >> >> Capabilities that wonât be available in anything else in an really usable way (because to be efficient they depend on capabilities not found in anything else), and in any case nowhere near as useful in anything else, will hopefully be more use than any article can be, never mind one I wrote, not just to me but also to other Pharo users and to Pharo itself. >> >> Cheers >> >> Andrew Glynn >> >> Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 >> >> From: [Stephane Ducasse](mailto:stepharo.self@gmail.com) >> >> Sent: Saturday, October 28, 2017 5:09 AM >> >> To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org) >> >> Subject: Re: [Pharo-users] Smalltalk Argument >> >> Hi andrew >> >> please take a project that would help to bring more companies and that you want to push and push it with us :). >> >> Stef >> >> On Sat, Oct 28, 2017 at 11:05 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >>> Hi andrew >>> >>> you should contact esteban because he is writing an objective-C bridge. >>> >>> Stef >>> >>> On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: >>> >>>> One thing Iâm working on is a bridge between Pharo and F-Script. F-Script is, basically, a Smalltalk dialect, as is obvious from the screenshot. However for MacOS and iOS, it allows you to bypass the static Objective-C API interface and debug / modify or even write applications directly in the system. To do that you âinjectâ F-Script into the OS. The ability to so has a specific implication, though. MacOS and iOS are themselves written in and as a dialect of Smalltalk. (were it simply an overlay on Objective-C, it wouldnât be able to do things that are impossible in Objective-C, and it wouldnât need to be âinjectedâ in order to run). Every implementation of Objective-C , bar GNUâs useless imitation, compiles to Smalltalk. No surprise that Appleâs does, as well. >>>> >>>> In any event, it will allow Pharo code to be mapped to MacOS and iOS objects, injected into the system dynamically, and modified / debugged dynamically using the Pharo tools. The result, at least as far as iOS is concerned, may make Pharo actually the most powerful way to program it, well beyond XCode alone, along with doing the same for MacOS. Android is another issue, although the Raspbian port of Pharo should be relatively easy to port to it. For me, unless someone had a use case, I donât have one myself for Android. Iâve tried nearly every version, because Iâd love to support an OSS ecosystem, unfortunately using it compared to the iPhone is still like driving a Fiero based kit car compared to an actual Ferrari. >>>> >>>> As far as JNI, while I see your point, JNI is such a PITA that few Java developers know it. My usual workaround is to use Stamp and Synapse, which has the further advantage of allowing Java to âthrottleâ data that the JVM canât deal with at full speed. >>>> >>>> As far as dealing with other JVM languages, PetitParser or SmaCC can generate bytecode rather than Java or other JVM code, and that allows libs to be written that utilize Synapse to talk to Pharo. It isnât necessarily an ideal solution, but a possible one without having to support umpteen environments. Another potential way of accomplishing that is to use NetRexx, a declarative JVM language, which is both easy and terse, and like SQL, generates the actual bytecode rather than precompiling to it. For instance, imagine the code needed for a simple âhello worldâ in Java, then compare: >>>> >>>> Say âhello worldâ >>>> >>>> Since it generates virtually the same bytecode, it may be an easy way to do it. >>>> >>>> With the last statement, that expresses really well the exact reason I no longer want to work in most other environments ð. >>>> >>>> Tc >>>> >>>> Andrew >>>> >>>> Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 >>>> >>>> From: phil(a)highoctane.be >>>> >>>> Sent: Thursday, October 26, 2017 2:19 AM >>>> >>>> To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org) >>>> >>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>> >>>> 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](tel:%2B49%207141%2056%2010%2086%200) Fax: [+49 7141 56 10 86 1](tel:%2B49%207141%2056%2010%2086%201)

Oct. 28, 2017

Re: [Pharo-users] Linear solvers

by Ben Coman

thx for the tip. cheers -ben On Sat, Oct 28, 2017 at 11:47 PM, werner kassens <wkassens(a)libello.com> wrote: > On 10/28/2017 04:23 PM, Ben Coman wrote: > > btw, what does PolyMath/SciSmalltalk offer in the way of linear solvers? > Hi Ben, > so far no linear solvers in PolyMath. i made a small constraint solver > for PolyMath that is not restricted to linear problems, hence > necessarily slower than linear solvers & not fast enough for > UI-layout-problems. a general overview of what that package does is > here: > https://github.com/SergeStinckwich/SciSmalltalk/wiki/RealInterval-Example- > Algos > . the constraint solver is described somewhere in the middle of that page. > werner > >

Oct. 28, 2017

Re: [Pharo-users] Linear solvers

by werner kassens

On 10/28/2017 04:23 PM, Ben Coman wrote: > btw, what does PolyMath/SciSmalltalk offer in the way of linear solvers? Hi Ben, so far no linear solvers in PolyMath. i made a small constraint solver for PolyMath that is not restricted to linear problems, hence necessarily slower than linear solvers & not fast enough for UI-layout-problems. a general overview of what that package does is here: https://github.com/SergeStinckwich/SciSmalltalk/wiki/RealInterval-Example-A… . the constraint solver is described somewhere in the middle of that page. werner

Oct. 28, 2017

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

by Steffen MÃ¤rcker

Does that mean the sets/bdd would be constructed mainly at comile time? Anyway, Andrew, feel free to contact me, I might help you with this. Best, Steffen Am .10.2017, 16:05 Uhr, schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > I think that andrew would like to improve smacc when parsing inputs > containing utf-8 characters. > > > On Sat, Oct 28, 2017 at 1:46 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: >> I see. What is the task in detail? Are some of the set fixed or known in >> advance? What's the argument against a bitset-based solution? >> >> Cheers, Steffen >> >> >> >> Am 27. Oktober 2017 19:10:35 MESZ schrieb Stephane Ducasse >> <stepharo.self(a)gmail.com>: <---Schnitt---> >> >

Oct. 28, 2017

Re: [Pharo-users] [ANN] Grafoscopio is now also an indexedpublication

by Andrew Glynn

Btw, thank you personally. In another project Iâve started to use both Grafoscopio itself (from a developer perspective) but also programmatically to improve that project. Hopefully Iâll be able to release that project soon (i.e. in the next couple of weeks) and youâll be able to see how Grafoscopio improvise it, but also how it increases the capabilities of Grafoscopio. Andrew Glynn Sent from Mail for Windows 10 From: Offray Vladimir Luna CÃ¡rdenas Sent: Saturday, October 28, 2017 11:02 AM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] [ANN] Grafoscopio is now also an indexedpublication Thanks Stephan, As told many times. This community has been really empowering to prototype the artifacts for my PhD (which is *not* in software [1]). Is good to count with such proactive and helpful community. [1] http://www.doctoradoendiseno.com/en This learning process is just starting. Cheers, Offray On 28/10/17 09:27, Stephane Ducasse wrote: > well done. > > > On Sat, Oct 28, 2017 at 12:58 AM, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com> wrote: >> Hi, >> >> I would like to share with you the recent acceptation of Grafoscopio in the >> Journal of Open Source Software (JOSS), which makes it also an indexed >> publication. More details at: >> >> http://joss.theoj.org/papers/10.21105/joss.00251 >> >> I would like to thank Serge Stinchwich (from this community) and Arfon >> Smith (from JOSS) for reviewing the software and helping me with the >> publication process. >> >> Cheers, >> >> Offray >> >> === >> >> About JOSS (http://joss.theoj.org/about) >> >> "The Journal of Open Source Software (JOSS) is a developer friendly journal >> for research software packages. >> >> [...] The Journal of Open Source Software (JOSS) is an academic journal >> (ISSN 2475-9066) with a formal peer review process that is designed to >> improve the quality of the software submitted. Upon acceptance into JOSS, a >> CrossRef DOI is minted and we list your paper on the JOSS website." >> >> === >

Oct. 28, 2017

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

by Andrew Glynn

Part of the reasoning is that by writing JVM bytecode, the differences between the various JVM languages become largely irrelevant, though in some ways it becomes slightly less convenient if calling, for example, Scala or Clojure code from Pharo. The other is inherent JVM limitations and discrepancies between Java as a semantic spec and various specific implementations as dynamic systems, particularly since the latter differ both by Java version and by which frameworks might be in use, and dynamically create further discrepancies contingently based not only on the above, but also specifics of the system and its current state. Cheers Andrew Sent from Mail for Windows 10 From: Stephane Ducasse Sent: Saturday, October 28, 2017 10:06 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Binary Decision Diagram Package in Smalltalk I think that andrew would like to improve smacc when parsing inputs containing utf-8 characters. On Sat, Oct 28, 2017 at 1:46 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > I see. What is the task in detail? Are some of the set fixed or known in > advance? What's the argument against a bitset-based solution? > > Cheers, Steffen > > > > Am 27. Oktober 2017 19:10:35 MESZ schrieb Stephane Ducasse > <stepharo.self(a)gmail.com>: >> >> It was for test inclusion of UTF-8 characters so we do not want to >> rely on external libraries. >> >> On Fri, Oct 27, 2017 at 1:54 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: >>> >>> Dear Andrew, >>> >>> I didn't find time to answer earlier. Some time ago, I was looking for a >>> (MT)BDD package in ST as well. I didn't found one. So the only two >>> options >>> left are >>> >>> 1) implementing a new BDD lib in ST and >>> 2) doing FFI to some existing lib, e.g. CUDD, Sylvan, Jinc >>> >>> I'd prefer 2) since the existing libraries are feature-rich and highly >>> optimized - which took quite some time. As a bonus, a solution could >>> potentially switch between those backends. The biggest hurdle, in my >>> option, >>> is memory management, since most libs use some sort of reference >>> counting. >>> And you do not want to end up with nightmarish dozens of ref(bddNode) >>> deref(bddNode) in your application code (like the probabilistic model >>> checker PRISM does). This introduces hard to track bugs easily. However, >>> I >>> have an idea in mind how to tackle this but I didn't found the time to >>> put >>> it into code yet. >>> >>> May I ask, which sort of application do you have in mind? >>> >>> Best, Steffen >>> >>> >>> >>> >>> Am .10.2017, 07:54 Uhr, schrieb Prof. Andrew P. Black >>> <black(a)cs.pdx.edu>: >>> >>>> Thanks for the responses so far. I see that I need to clarify my >>>> enquiry. >>>> >>>> B-Trees and BDDs are not the same. BDDs are an efficient and compact >>>> representations for Boolean functions, sometimes used in SAT-solvers >>>> and >>>> electronics design. The key idea is that since the output must be 0 >>>> or 1, >>>> you can represent any Boolean function as a tree whose depth is the >>>> same as >>>> the number of bits in the input. >>>> >>>> To make the tree small and efficient, though, you need to eliminate any >>>> node whose two children are the same, and to share subtrees, so that >>>> you >>>> really get a DAG, not a tree. The full name for these efficient >>>> compressed >>>> trees is âReduced Order Binary Decision Diagramsâ, or ROBDDs. I was >>>> hoping >>>> that someone else had implemented the algorithms necessary to build >>>> this >>>> representation. >>>> >>>> Because sets can be considered to be Booleans functions (true => >>>> argument >>>> is in the set), you can use ROBDDs to efficiently represent large sets. >>>> >>>> To be clear, despite the word âdiagramâ in the name, one is not >>>> normally >>>> interested in drawing the BDD â except in the documentation for the >>>> package >>>> ;-). Normally, BDDs they are used to represent sets, or functions, >>>> where >>>> the drawing would be hopelessly large. >>>> >>>> The BuDDy package (http://buddy.sourceforge.net/manual/main.html) is an >>>> example of what Iâm looking for, but unfortunately itâs in C++. >>>> >>>> Andrew >>>> >>>> >>>>> On 25 Oct 2017, at 21:39 , 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 >>>>> >>>>> >>>>> 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. 28, 2017

Re: [Pharo-users] Actual Code to Improve the Pharo environment

by Andrew Glynn

Iâm not working on that specifically, although what I am working on could definitely use that and vice versa, which would increase the capabilities of each. One thing Iâm working on is using Vert.x for service registration and discovery, mapped to Apache River (JINI) to propagate that over non-local network segments that require fully authenticated security (as a result, it also provides things such as Kerberos to Pharo apps). The mapping between the two is very straightforward, almost direct, but Iâve added the Synapse micro service bus to control data flows and secure access to remote services. It enables things like automatic configuration/integration of Pharo based mobile apps with newer cars that support that kind of autoconfiguration, since they all use JINI to do so. Thus a Pharo mobile or IoT app can automatically be configured to work with any of the carâs subsystems that are relevant to it. JINI is far more used than people realize, partly because it âjust worksâ and as a result doesnât get the public âsqueaky wheelâ effect. The fact that the authors of Vert.x reimplemented half of the features of JINI, in a less comprehensive and less reliable way, rather than just using it (especially considering itâs open source) shows the degree to which that effect is operative. Thereâs probably a couple dozen other general use cases where the integration will allow Pharo apps to âjust workâ in a JINI or Vert.x environment, as well as thousands of industry/company specific ones. Iâd have to mode-switch to think of them off the top of my head though ð. Andrew Sent from Mail for Windows 10 From: henry Sent: Saturday, October 28, 2017 10:02 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment Hi Andrew, Are you working to bring a Capabilities model to Pharo? This is precisely what I am working to bring with Hubbub, running on top of my ParrotTalk. I derived these from erights.org's ELib and have been working on them for many years. Now that ParrotTalk has stabilized (layer 5) I am shifting to implementing marshalling of layer 6 objects using STON all to run on top of ParrotTalk. Once I get marshalling with scope substitutions, I will debug Hubbub to offer distributed Capabilities. What work are you undertaking? Regards, - HH -------- Original Message -------- Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment Local Time: October 28, 2017 9:12 AM UTC Time: October 28, 2017 1:12 PM From: aglynn42(a)gmail.com To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Writing that kind of code is another of the reasons I decided I donât want to work in anything else ð.Â Maybe more important than some of the others, both to myself and to other users. Â Iâve gained so much personally, mostly for nothing, even just considering the relatively fewÂ projects I have been able to work on in Pharo and previously in Squeak, VW and VA.Â Unfortunately in most I havenât been able to make the code public, since they were for entities like the government, DoD, etc. Â Â Not that VA attracts me quite so much to give back all that strongly, when a license is $8500+. Â Were it possible to give back to VA C++ or VA Java, it might be different, but neither were OSS although they werenât expensive. Â More relevantly, both are now abandonware (hence my comment about IBM, which is applicable to OS/2 as well, although that has quietly had a 5.0 version released in June of this year). Â I would, though, love a chance to give back to Pharo primarily, although I may port anything relevant to Squeak, and if I have sufficient time port it to VW, which although not OSS is at least affordable to most developers. Â Iâm nearly there on a couple of projects â one Iâm testing and making final tweaks, another is about 2/3dâs of the way.Â Â The first project you (and others on the list) may be more immediately interested in testing, since it requires little to no additional work to use it, and even if not perfect, since itâs intended to directly help work you are doing in Pharo, it may worthwhile.Â Iâm hoping to have it ready for public consumption by the middle of November.Â Â On a different but related topic, the article I wrote got a fair amount of interest considering I donât write nearly as well as Kenneth, for example.Â Including direct interest from some well known industry people, which canât hurt.Â In an indirect way it may even be helpful, but not in the real, direct way decent code is. Â Capabilities that wonât be available in anything else in an really usable way (because to be efficient they depend on capabilities not found in anything else), and in any case nowhere near as useful in anything else, will hopefully be more use than any article can be, never mind one I wrote, not just to me but also to other Pharo users and to Pharo itself. Â Cheers Andrew Glynn Â Â Sent from Mail for Windows 10 Â From: Stephane Ducasse Sent: Saturday, October 28, 2017 5:09 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Â Hi andrew Â please take a project that would help to bring more companies and that you want to push and push it with us :). Â Â Stef Â Â On Sat, Oct 28, 2017 at 11:05 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: Hi andrew Â you should contact esteban because he is writing an objective-C bridge.Â Â Stef Â On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: One thing Iâm working on is a bridge between Pharo and F-Script.Â F-Script is, basically, a Smalltalk dialect, as is obvious from the screenshot.Â However for MacOS and iOS, it allows you to bypass the static Objective-C API interface and debug / modify or even write applications directly in the system.Â To do that you âinjectâ F-Script into the OS.Â The ability to so has a specific implication, though.Â MacOS and iOS are themselves written in and as a dialect of Smalltalk.Â (were it simply an overlay on Objective-C, it wouldnât be able to do things that are impossible in Objective-C, and it wouldnât need to be âinjectedâ in order to run).Â Every implementation of Objective-C , bar GNUâs useless imitation, compiles to Smalltalk.Â No surprise that Appleâs does, as well. Â In any event, it will allow Pharo code to be mapped to MacOS and iOS objects, injected into the system dynamically, and modified / debugged dynamically using the Pharo tools.Â The result, at least as far as iOS is concerned, may make Pharo actually the most powerful way to program it, well beyond XCode alone, along with doing the same for MacOS.Â Android is another issue, although the Raspbian port of Pharo should be relatively easy to port to it. For me, unless someone had a use case, I donât have one myself for Android.Â Iâve tried nearly every version, because Iâd love to support an OSS ecosystem, unfortunately using it compared to the iPhone is still like driving a Fiero based kit car compared to an actual Ferrari. Â As far as JNI, while I see your point, JNI is such a PITA that few Java developers know it.Â My usual workaround is to use Stamp and Synapse, which has the further advantage of allowing Java to âthrottleâ data that the JVM canât deal with at full speed. Â As far as dealing with other JVM languages, PetitParser or SmaCC can generate bytecode rather than Java or other JVM code, and that allows libs to be written that utilize Synapse to talk to Pharo.Â It isnât necessarily an ideal solution, but a possible one without having to support umpteen environments.Â Another potential way of accomplishing that is to use NetRexx, a declarative JVM language, which is both easy and terse, and like SQL, generates the actual bytecode rather than precompiling to it.Â For instance, imagine the code needed for a simple âhello worldâ in Java, then compare: Â Say âhello worldâ Â Since it generates virtually the same bytecode, it may be an easy way to do it. Â With the last statement, that expresses really well the exact reason I no longer want to work in most other environments ð. Â Tc Andrew Â Â Â Sent from Mail for Windows 10 Â From: phil(a)highoctane.be Sent: Thursday, October 26, 2017 2:19 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Â 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. 28, 2017

Re: [Pharo-users] [ANN] Grafoscopio is now also an indexed publication

by Offray Vladimir Luna CÃ¡rdenas

Thanks Stephan, As told many times. This community has been really empowering to prototype the artifacts for my PhD (which is *not* in software [1]). Is good to count with such proactive and helpful community. [1] http://www.doctoradoendiseno.com/en This learning process is just starting. Cheers, Offray On 28/10/17 09:27, Stephane Ducasse wrote: > well done. > > > On Sat, Oct 28, 2017 at 12:58 AM, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com> wrote: >> Hi, >> >> I would like to share with you the recent acceptation of Grafoscopio in the >> Journal of Open Source Software (JOSS), which makes it also an indexed >> publication. More details at: >> >> http://joss.theoj.org/papers/10.21105/joss.00251 >> >> I would like to thank Serge Stinchwich (from this community) and Arfon >> Smith (from JOSS) for reviewing the software and helping me with the >> publication process. >> >> Cheers, >> >> Offray >> >> === >> >> About JOSS (http://joss.theoj.org/about) >> >> "The Journal of Open Source Software (JOSS) is a developer friendly journal >> for research software packages. >> >> [...] The Journal of Open Source Software (JOSS) is an academic journal >> (ISSN 2475-9066) with a formal peer review process that is designed to >> improve the quality of the software submitted. Upon acceptance into JOSS, a >> CrossRef DOI is minted and we list your paper on the JOSS website." >> >> === >

Oct. 28, 2017

Re: [Pharo-users] [ANN] Grafoscopio is now also an indexed publication

by Stephane Ducasse

well done. On Sat, Oct 28, 2017 at 12:58 AM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Hi, > > I would like to share with you the recent acceptation of Grafoscopio in the > Journal of Open Source Software (JOSS), which makes it also an indexed > publication. More details at: > > http://joss.theoj.org/papers/10.21105/joss.00251 > > I would like to thank Serge Stinchwich (from this community) and Arfon > Smith (from JOSS) for reviewing the software and helping me with the > publication process. > > Cheers, > > Offray > > === > > About JOSS (http://joss.theoj.org/about) > > "The Journal of Open Source Software (JOSS) is a developer friendly journal > for research software packages. > > [...] The Journal of Open Source Software (JOSS) is an academic journal > (ISSN 2475-9066) with a formal peer review process that is designed to > improve the quality of the software submitted. Upon acceptance into JOSS, a > CrossRef DOI is minted and we list your paper on the JOSS website." > > ===

Oct. 28, 2017

Linear solvers

by Ben Coman

While reading around on Cassowary for constraint based UI, I noticed the original author and others expanded their work to a more general linear solver system Balsberg. Maybe something useful to many business, so just thought I'd drop some links... * Solving Interactive Logic Puzzles With Object-Constraints https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/GraberFelgentr… * https://github.com/babelsberg/babelsberg-s * https://homes.cs.washington.edu/~borning/papers/felgentreff-babelsberg-sema… * https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/FelgentreffLeh… btw, what does PolyMath/SciSmalltalk offer in the way of linear solvers? cheers -ben

Oct. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

I referred to a Lambda Architecture, not the availability of Lambdas in the language. Pharo has the best with BlockClosures. - HH > -------- Original Message -------- > Subject: RE: [Pharo-users] Smalltalk Argument > Local Time: October 27, 2017 11:10 PM > UTC Time: October 28, 2017 3:10 AM > From: aglynn42(a)gmail.com > To: henry <henry(a)callistohouse.club>, Any question about pharo iswelcome <pharo-users(a)lists.pharo.org> > > Last point. Blocks are already better lambdas than lambdas in Java. > > Have a look at this code from rxJava, which includes the Java 8 lambda version and a Java 7 version using an anonymous inner class: > > Java 8 code > > package > > rxjava.examples > > ; > > > > import > > io.reactivex.* > > ; > > > > public > > class > > HelloWorld > > { > > > > public > > static > > void > > main > > ( > > String > > [] > > args > > ) { > > > > Flowable > > . > > just( > > " > > Hello world > > " > > ) > > . > > subscribe( > > System > > . > > out > > :: > > println); > > } > > } > > Java 7 code > > import > > io.reactivex.functions.Consumer > > ; > > > > Flowable > > . > > just( > > " > > Hello world > > " > > ) > > .subscribe( > > new > > Consumer< > > String > >> > > () { > > > > @Override > > public > > void > > accept > > ( > > String > > s > > ) { > > > > System > > . > > out > > . > > println(s); > > } > > }); > > Are they equivalent? How would you know? > > In fact, they arenât, worse, the results of the difference depend on the target, whether itâs Java SE (including Spring based apps) or JavaEE. > > The Java 8 version doesnât create an anonymous inner class but a generically named class with generically named methods. As a result, it will be most often faster. However itâs less safe, because particularly in clustered environments, and unpredictably, it can create conflicts due to the same generic names being used by two different JVMâs. The Java 7 version will be as fast, in JavaEE, and safer. In Java SE theyâre close to equivalently safe, but the Java 7 version will be significantly slower in most cases. > > RxJava itself, as well, is unnecessary in Pharo, since the Announcer already implements the same pattern, and does so in a more efficient and more consistent way. > > Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 > > From: [henry](mailto:henry@callistohouse.club) > Sent: Friday, October 27, 2017 5:03 PM > To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org) > Subject: Re: [Pharo-users] Smalltalk Argument > > Elastic search JSON integration would be another good one. I heard there was a Kafka integration, is that true? Where could I find that, I used to use Kafka. > > Kafka is a great event channel for input to BigData. Using Kafka, it is well in crafting a Lamda Architecture. Imagine Pharo where Storm resides. > > [webkit-fake-url://502df029-af7a-484e-b157-43970b30a0a1/imagejpeg] > > - HH > > On Fri, Oct 27, 2017 at 16:51, henry <henry(a)callistohouse.club> wrote: > >> How about Kerberos? Can we get a team to look closely at bringing integration for enterprise users? That would be helpful, or can you just put it behind a Kerberos wrapper? If that would work, collecting a demo, that could unlock more corporate wallets , for investment. >> >> - HH >> >> On Fri, Oct 27, 2017 at 16:41, henry <[henry@callistohouse.club](%22mailto:henry@callistohouse.club%22)> wrote: >> >>> How is there no steering committee to accumulate wrapping 3rd party libraries in Alien to gain benefits of code in other languages? Do not assume that code is not extremely well written in that particular language for that particular task and that particular deployment mechanism. >>> >>> Can Pharo be called as a shared library from Java JNA? >>> >>> - HH >>> >>> On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <[aglynn42@gmail.com](%22mailto:aglynn42@gmail.com%22)> wrote: >>> >>>> Iâm not claiming I donât or havenât been affected, only that I no long allow myself to be. Does that cause issues? Of course. But Iâd rather deal with those than do things I donât enjoy. However I only got to that point after 26 years in the industry, so I donât expect that everyone will feel that way. >>>> >>>> Cheers >>>> >>>> Andrew >>>> >>>> Sent from [Mail](%22https:/go.microsoft.com/fwlink/?LinkId=550986%22) for Windows 10 >>>> >>>> From: [jtuchel@objektfabrik.de](%22mailto:jtuchel@objektfabrik.de%22) >>>> Sent: Thursday, October 26, 2017 8:14 AM >>>> To: [pharo-users@lists.pharo.org](%22mailto:pharo-users@lists.pharo.org%22) >>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>> >>>> Andrew, >>>> >>>> Am 26.10.17 um 00:46 schrieb Andrew Glynn: >>>> >>>>> Thereâs other questions that are relevant to me: >>>> >>>> I am glad you opened your words with this sentence. Other peoplesâ mileages may vary a lot. >>>> >>>>> 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. >>>> >>>> Some people canât. I canât. I am making my living with a web based application. And I like 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.> >>>> >>>> So you are in the lucky position that neither mobile nor web nor integration matters to you or you have enough resources to do all that stuff yourself. I am envyous. I need to build web pages and people ask me whether we can ship an iPhone App. I do customer-facing stuff and sex sells much more than we like to think. >>>> >>>> Your comments on the crappiness of libs in other languages is a great fit for Smalltalk. Not invented here, therefor rubbish. We came a long way with this way of thinking. But these rubbish makers dance circles around us while we try to do our first hello world for an iPad. They laugh at us when we try to reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). Because they are back home and watch Netflix while we debug our homegrown base libraries that are, of course, much better than theirs because they are written in Smalltalk. >>>> >>>> I am not arguing that maintaining Smalltalk code is far superior to most technolgies out there. But depending on the needs of our projects we have to learn and use those crappy technologies to accomplish what they offer. Because, sometimes (especially if you have to pay bills), an existing library with flaws is better than none. >>>> >>>> So if I have to use Javascript or C# or Dart or Swift to do the frontend part of my system, is there still much benefit in using these together with Smalltalk? Or is there - at least from a managerâs point of view - not a reasonable amount of sense in choosing the frontend technology also for the logic and compensate the loss in productivity with a gain in avoided complexity? >>>> >>>> Your answer delivers a lot of food for thought, but I donât buy all of it. And I donât expect you to buy all of mine ;-) >>>> >>>> Joachim >>>> >>>>> >>>>> >>>>> 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>](%22mailto:pharo-users-bounces@lists.pharo.org%22) on behalf of David Mason [<dmason(a)ryerson.ca>](%22mailto:dmason@ryerson.ca%22) >>>>> Reply-To: Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](%22mailto:pharo-users@lists.pharo.org%22) >>>>> Date: Tuesday, October 24, 2017 at 11:52 AM >>>>> To: Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](%22mailto:pharo-users@lists.pharo.org%22) >>>>> 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](%22http:/pharojs.org%22) >>>>> >>>>> 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@objektfabrik.de](%22mailto:jtuchel@objektfabrik.de%22) <[jtuchel@objektfabrik.de](%22mailto:jtuchel@objektfabrik.de%22)> 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](%22mailto:jtuchel@objektfabrik.de%22) >>>>>> Fliederweg 1 [http://www.objektfabrik.de](%22http:/www.objektfabrik.de%22) >>>>>> D-71640 Ludwigsburg [http://joachimtuchel.wordpress.com](%22http:/joachimtuchel.wordpress.com%22) >>>>>> Telefon: [+49 7141 56 10 86 0](%22tel:%2B49%207141%2056%2010%2086%200%22) Fax: [+49 7141 56 10 86 1](%22tel:%2B49%207141%2056%2010%2086%201%22) >>>> >>>> â >>>> >>>> ââââââââââââââââââââââââ >>>> >>>> Objektfabrik Joachim Tuchel >>>> [mailto:jtuchel@objektfabrik.de](%22mailto:jtuchel@objektfabrik.de%22) >>>> >>>> Fliederweg 1 >>>> [http://www.objektfabrik.de](%22http:/www.objektfabrik.de%22) >>>> >>>> D-71640 Ludwigsburg >>>> [http://joachimtuchel.wordpress.com](%22http:/joachimtuchel.wordpress.com%22) >>>> >>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Oct. 28, 2017

Re: [Pharo-users] Netstyle/Workflow Package discovery - (was: Business process (declaration and orchestration), ontology/taxonomy)

by Stephane Ducasse

Hi I do not see why these classes would be mandatory for a workflow. There seems to be left over from the extraction. stef On Sat, Oct 28, 2017 at 12:11 PM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > >> ok for now publish your changes on smalltalkhub somewhere so that they >> do not stay on your machine. > > Even if very very experimental :) > > Iâll do. Just need a bit more work and comment what I did. > > I have unsolved references to this classes too. > DomBuilder > IDBasicManager > IDCurrentManager > > Any ideas ? > Iâll read more carefully the white paper and see if XMLParser can help here. But is someone knows about this classesâ¦ > > Cheers, > > CÃ©drick > > > >> >> On Sat, Oct 28, 2017 at 7:52 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: >>> >>>> >>>> Did you send pull requests? >>> >>> Euh, actually I still donât really know how to use git. >>> >>> I loaded it through metacello. Can I simply a sunlit code that way ? >>> >>> The code is quite documented already and there are tests. >>> >>> I kind of fixed some tests but not sure this was the way to do so (beginHistory has no action for instance). >>> >>> All the xpdl import/export fail but this is due to one method that need a DOMbuilder and two other class I have no clue. >>> >>> And I still havenât find how to execute a process ^^ >>> >>> Iâll have another look today. >>> >>> Cheers, >>> >>> CÃ©drick >>> >>>> >>>> Stef >>>> >>>>> On Fri, Oct 27, 2017 at 2:32 PM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: >>>>> A pleasure to discover ! To me, a wonderful(ly engineered) library. >>>>> >>>>> Big thanks to Netstyle ! >>>>> >>>>> Iâm just getting my hands around, but it looks to me like a great general purpose BP tool (modeling + engine + xpdl import export). >>>>> It would be very useful for IS in industrial contexts (*). And before all a superb starting point to model my simple personal routines as executable processes. >>>>> >>>>> On the practical aspects, just a problem loading because of WADynamicVariable, but it kinds of load on Pharo 6. >>>>> Running tests, there are (naturally) some failures. I think most come from the removed links to Omnibase/History support and seaside (WADynamicVariable). >>>>> >>>>> Some stuffs that are missing: >>>>> #isOmniBaseTransaction >>>>> #markDirty >>>>> A reference to TimeStamp fixed: >>>>> #beginInHistory >>>>> â¦ >>>>> >>>>> Need to fix WADynamicVariable with shouldnât be hard. >>>>> The History link (persistence) is a bit more difficult as I donât know its importance in the engine. >>>>> All Workflow object are managed object which (if I understand well) are persistent object. So maybe It need a (local) persistent alternative, a stub ? >>>>> >>>>> Anyway, I need to understand more and I will probably come back with some questions about the dependencies and how to fix them. >>>>> >>>>> >>>>> Cheers and thanks again, enligthening code :) >>>>> >>>>> CÃ©drick >>>>> >>>>> >>>>> >>>>> * Interoperability of is a field I try carefully not to enter because I found not really fun (as most of the tool Iâve soon were java based â¦ and slowâ¦ and java world !) but if only I had similar tools in pharo that could bring the fun back :) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Le 27 oct. 2017 Ã 09:37, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> a Ã©crit : >>>>>> >>>>>> Thank you! >>>>>> >>>>>> I thons this just perfect as a starting point ! >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Cedrick >>>>>> >>>>>> EnvoyÃ© de mon iPhone >>>>>> >>>>>>> Le 26 oct. 2017 Ã 19:38, Paul DeBruicker <pdebruic(a)gmail.com> a Ã©crit : >>>>>>> >>>>>>> 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. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

I used Kafka as was illustrated in the image, as a durable event source for BigData to RDB, Hadoop and other facilities. Our Kafka consumers were writing into Hadoop and had no concept of map/reduce. I agree that if we had a map/reduce feature then Pharo could operate against HDB and Hadoop in the Hadoop constellation of tools. That would be powerful. I need and wish to ask your opinion, for steering Pharo into an enterprise solution, what features does Pharo need to be a better player? - HH > -------- Original Message -------- > Subject: RE: [Pharo-users] Smalltalk Argument > Local Time: October 27, 2017 11:10 PM > UTC Time: October 28, 2017 3:10 AM > From: aglynn42(a)gmail.com > To: henry <henry(a)callistohouse.club>, Any question about pharo iswelcome <pharo-users(a)lists.pharo.org> > > Thereâs a million ways of accomplishing such things, but you need to pick the appropriate way to do it, given restrictions in Pharo and limitations in whatâs itâs calling. > > You can utilize Kafka or Kerberos authentication via Synapse, for instance, you can access virtually any authentication mechanism via WSO2 IS (itself built on Synapse). > > Another way of accessing the same things (plus numerous others) is via Vert.x, also directly supported from the Pharo catalog. Iâve used that methodology as well, though I had to overcome Vert.xâs own limitations by mapping it to the more capable Apache River (formerly JINI). > > You can access Hadoop / Cassandra / MongoDB via the same methods Kafka, Storm and Spark do, without the problems introduced by the JVM. MongoDB and Cassandra have libraries already available in Pharo, and they work better than those available elsewhere. > > There are even ways to directly access the Open Telephony API in ERLAN. > > Sometimes you need to be creative, and every time you need to understand the strengths and limitations of both what youâre using, and what youâre accessing. > > Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 > > From: [henry](mailto:henry@callistohouse.club) > Sent: Friday, October 27, 2017 5:03 PM > To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org) > Subject: Re: [Pharo-users] Smalltalk Argument > > Elastic search JSON integration would be another good one. I heard there was a Kafka integration, is that true? Where could I find that, I used to use Kafka. > > Kafka is a great event channel for input to BigData. Using Kafka, it is well in crafting a Lamda Architecture. Imagine Pharo where Storm resides. > > [webkit-fake-url://502df029-af7a-484e-b157-43970b30a0a1/imagejpeg] > > - HH > > On Fri, Oct 27, 2017 at 16:51, henry <henry(a)callistohouse.club> wrote: > >> How about Kerberos? Can we get a team to look closely at bringing integration for enterprise users? That would be helpful, or can you just put it behind a Kerberos wrapper? If that would work, collecting a demo, that could unlock more corporate wallets , for investment. >> >> - HH >> >> On Fri, Oct 27, 2017 at 16:41, henry <[henry@callistohouse.club](%22mailto:henry@callistohouse.club%22)> wrote: >> >>> How is there no steering committee to accumulate wrapping 3rd party libraries in Alien to gain benefits of code in other languages? Do not assume that code is not extremely well written in that particular language for that particular task and that particular deployment mechanism. >>> >>> Can Pharo be called as a shared library from Java JNA? >>> >>> - HH >>> >>> On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <[aglynn42@gmail.com](%22mailto:aglynn42@gmail.com%22)> wrote: >>> >>>> Iâm not claiming I donât or havenât been affected, only that I no long allow myself to be. Does that cause issues? Of course. But Iâd rather deal with those than do things I donât enjoy. However I only got to that point after 26 years in the industry, so I donât expect that everyone will feel that way. >>>> >>>> Cheers >>>> >>>> Andrew >>>> >>>> Sent from [Mail](%22https:/go.microsoft.com/fwlink/?LinkId=550986%22) for Windows 10 >>>> >>>> From: [jtuchel@objektfabrik.de](%22mailto:jtuchel@objektfabrik.de%22) >>>> Sent: Thursday, October 26, 2017 8:14 AM >>>> To: [pharo-users@lists.pharo.org](%22mailto:pharo-users@lists.pharo.org%22) >>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>> >>>> Andrew, >>>> >>>> Am 26.10.17 um 00:46 schrieb Andrew Glynn: >>>> >>>>> Thereâs other questions that are relevant to me: >>>> >>>> I am glad you opened your words with this sentence. Other peoplesâ mileages may vary a lot. >>>> >>>>> 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. >>>> >>>> Some people canât. I canât. I am making my living with a web based application. And I like 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.> >>>> >>>> So you are in the lucky position that neither mobile nor web nor integration matters to you or you have enough resources to do all that stuff yourself. I am envyous. I need to build web pages and people ask me whether we can ship an iPhone App. I do customer-facing stuff and sex sells much more than we like to think. >>>> >>>> Your comments on the crappiness of libs in other languages is a great fit for Smalltalk. Not invented here, therefor rubbish. We came a long way with this way of thinking. But these rubbish makers dance circles around us while we try to do our first hello world for an iPad. They laugh at us when we try to reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). Because they are back home and watch Netflix while we debug our homegrown base libraries that are, of course, much better than theirs because they are written in Smalltalk. >>>> >>>> I am not arguing that maintaining Smalltalk code is far superior to most technolgies out there. But depending on the needs of our projects we have to learn and use those crappy technologies to accomplish what they offer. Because, sometimes (especially if you have to pay bills), an existing library with flaws is better than none. >>>> >>>> So if I have to use Javascript or C# or Dart or Swift to do the frontend part of my system, is there still much benefit in using these together with Smalltalk? Or is there - at least from a managerâs point of view - not a reasonable amount of sense in choosing the frontend technology also for the logic and compensate the loss in productivity with a gain in avoided complexity? >>>> >>>> Your answer delivers a lot of food for thought, but I donât buy all of it. And I donât expect you to buy all of mine ;-) >>>> >>>> Joachim >>>> >>>>> >>>>> >>>>> 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>](%22mailto:pharo-users-bounces@lists.pharo.org%22) on behalf of David Mason [<dmason(a)ryerson.ca>](%22mailto:dmason@ryerson.ca%22) >>>>> Reply-To: Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](%22mailto:pharo-users@lists.pharo.org%22) >>>>> Date: Tuesday, October 24, 2017 at 11:52 AM >>>>> To: Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](%22mailto:pharo-users@lists.pharo.org%22) >>>>> 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](%22http:/pharojs.org%22) >>>>> >>>>> 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@objektfabrik.de](%22mailto:jtuchel@objektfabrik.de%22) <[jtuchel@objektfabrik.de](%22mailto:jtuchel@objektfabrik.de%22)> 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](%22mailto:jtuchel@objektfabrik.de%22) >>>>>> Fliederweg 1 [http://www.objektfabrik.de](%22http:/www.objektfabrik.de%22) >>>>>> D-71640 Ludwigsburg [http://joachimtuchel.wordpress.com](%22http:/joachimtuchel.wordpress.com%22) >>>>>> Telefon: [+49 7141 56 10 86 0](%22tel:%2B49%207141%2056%2010%2086%200%22) Fax: [+49 7141 56 10 86 1](%22tel:%2B49%207141%2056%2010%2086%201%22) >>>> >>>> â >>>> >>>> ââââââââââââââââââââââââ >>>> >>>> Objektfabrik Joachim Tuchel >>>> [mailto:jtuchel@objektfabrik.de](%22mailto:jtuchel@objektfabrik.de%22) >>>> >>>> Fliederweg 1 >>>> [http://www.objektfabrik.de](%22http:/www.objektfabrik.de%22) >>>> >>>> D-71640 Ludwigsburg >>>> [http://joachimtuchel.wordpress.com](%22http:/joachimtuchel.wordpress.com%22) >>>> >>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Oct. 28, 2017

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

by Stephane Ducasse

I think that andrew would like to improve smacc when parsing inputs containing utf-8 characters. On Sat, Oct 28, 2017 at 1:46 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > I see. What is the task in detail? Are some of the set fixed or known in > advance? What's the argument against a bitset-based solution? > > Cheers, Steffen > > > > Am 27. Oktober 2017 19:10:35 MESZ schrieb Stephane Ducasse > <stepharo.self(a)gmail.com>: >> >> It was for test inclusion of UTF-8 characters so we do not want to >> rely on external libraries. >> >> On Fri, Oct 27, 2017 at 1:54 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: >>> >>> Dear Andrew, >>> >>> I didn't find time to answer earlier. Some time ago, I was looking for a >>> (MT)BDD package in ST as well. I didn't found one. So the only two >>> options >>> left are >>> >>> 1) implementing a new BDD lib in ST and >>> 2) doing FFI to some existing lib, e.g. CUDD, Sylvan, Jinc >>> >>> I'd prefer 2) since the existing libraries are feature-rich and highly >>> optimized - which took quite some time. As a bonus, a solution could >>> potentially switch between those backends. The biggest hurdle, in my >>> option, >>> is memory management, since most libs use some sort of reference >>> counting. >>> And you do not want to end up with nightmarish dozens of ref(bddNode) >>> deref(bddNode) in your application code (like the probabilistic model >>> checker PRISM does). This introduces hard to track bugs easily. However, >>> I >>> have an idea in mind how to tackle this but I didn't found the time to >>> put >>> it into code yet. >>> >>> May I ask, which sort of application do you have in mind? >>> >>> Best, Steffen >>> >>> >>> >>> >>> Am .10.2017, 07:54 Uhr, schrieb Prof. Andrew P. Black >>> <black(a)cs.pdx.edu>: >>> >>>> Thanks for the responses so far. I see that I need to clarify my >>>> enquiry. >>>> >>>> B-Trees and BDDs are not the same. BDDs are an efficient and compact >>>> representations for Boolean functions, sometimes used in SAT-solvers >>>> and >>>> electronics design. The key idea is that since the output must be 0 >>>> or 1, >>>> you can represent any Boolean function as a tree whose depth is the >>>> same as >>>> the number of bits in the input. >>>> >>>> To make the tree small and efficient, though, you need to eliminate any >>>> node whose two children are the same, and to share subtrees, so that >>>> you >>>> really get a DAG, not a tree. The full name for these efficient >>>> compressed >>>> trees is âReduced Order Binary Decision Diagramsâ, or ROBDDs. I was >>>> hoping >>>> that someone else had implemented the algorithms necessary to build >>>> this >>>> representation. >>>> >>>> Because sets can be considered to be Booleans functions (true => >>>> argument >>>> is in the set), you can use ROBDDs to efficiently represent large sets. >>>> >>>> To be clear, despite the word âdiagramâ in the name, one is not >>>> normally >>>> interested in drawing the BDD â except in the documentation for the >>>> package >>>> ;-). Normally, BDDs they are used to represent sets, or functions, >>>> where >>>> the drawing would be hopelessly large. >>>> >>>> The BuDDy package (http://buddy.sourceforge.net/manual/main.html) is an >>>> example of what Iâm looking for, but unfortunately itâs in C++. >>>> >>>> Andrew >>>> >>>> >>>>> On 25 Oct 2017, at 21:39 , 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 >>>>> >>>>> >>>>> 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. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

I looked and was not able to find it. Which version of Pharo are we talking about? What is the name of the kafka integration? - HH > -------- Original Message -------- > Subject: RE: [Pharo-users] Smalltalk Argument > Local Time: October 27, 2017 11:10 PM > UTC Time: October 28, 2017 3:10 AM > From: aglynn42(a)gmail.com > To: henry <henry(a)callistohouse.club>, Any question about pharo iswelcome <pharo-users(a)lists.pharo.org> > > The Kafka integration is right in the Pharo catalog. > > Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 > > From: [henry](mailto:henry@callistohouse.club) > Sent: Friday, October 27, 2017 5:03 PM > To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org) > Subject: Re: [Pharo-users] Smalltalk Argument > > Elastic search JSON integration would be another good one. I heard there was a Kafka integration, is that true? Where could I find that, I used to use Kafka. > > Kafka is a great event channel for input to BigData. Using Kafka, it is well in crafting a Lamda Architecture. Imagine Pharo where Storm resides. > > [webkit-fake-url://502df029-af7a-484e-b157-43970b30a0a1/imagejpeg] > > - HH > > On Fri, Oct 27, 2017 at 16:51, henry <henry(a)callistohouse.club> wrote: > >> How about Kerberos? Can we get a team to look closely at bringing integration for enterprise users? That would be helpful, or can you just put it behind a Kerberos wrapper? If that would work, collecting a demo, that could unlock more corporate wallets , for investment. >> >> - HH >> >> On Fri, Oct 27, 2017 at 16:41, henry <[henry@callistohouse.club](%22mailto:henry@callistohouse.club%22)> wrote: >> >>> How is there no steering committee to accumulate wrapping 3rd party libraries in Alien to gain benefits of code in other languages? Do not assume that code is not extremely well written in that particular language for that particular task and that particular deployment mechanism. >>> >>> Can Pharo be called as a shared library from Java JNA? >>> >>> - HH >>> >>> On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <[aglynn42@gmail.com](%22mailto:aglynn42@gmail.com%22)> wrote: >>> >>>> Iâm not claiming I donât or havenât been affected, only that I no long allow myself to be. Does that cause issues? Of course. But Iâd rather deal with those than do things I donât enjoy. However I only got to that point after 26 years in the industry, so I donât expect that everyone will feel that way. >>>> >>>> Cheers >>>> >>>> Andrew >>>> >>>> Sent from [Mail](%22https:/go.microsoft.com/fwlink/?LinkId=550986%22) for Windows 10 >>>> >>>> From: [jtuchel@objektfabrik.de](%22mailto:jtuchel@objektfabrik.de%22) >>>> Sent: Thursday, October 26, 2017 8:14 AM >>>> To: [pharo-users@lists.pharo.org](%22mailto:pharo-users@lists.pharo.org%22) >>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>> >>>> Andrew, >>>> >>>> Am 26.10.17 um 00:46 schrieb Andrew Glynn: >>>> >>>>> Thereâs other questions that are relevant to me: >>>> >>>> I am glad you opened your words with this sentence. Other peoplesâ mileages may vary a lot. >>>> >>>>> 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. >>>> >>>> Some people canât. I canât. I am making my living with a web based application. And I like 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.> >>>> >>>> So you are in the lucky position that neither mobile nor web nor integration matters to you or you have enough resources to do all that stuff yourself. I am envyous. I need to build web pages and people ask me whether we can ship an iPhone App. I do customer-facing stuff and sex sells much more than we like to think. >>>> >>>> Your comments on the crappiness of libs in other languages is a great fit for Smalltalk. Not invented here, therefor rubbish. We came a long way with this way of thinking. But these rubbish makers dance circles around us while we try to do our first hello world for an iPad. They laugh at us when we try to reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). Because they are back home and watch Netflix while we debug our homegrown base libraries that are, of course, much better than theirs because they are written in Smalltalk. >>>> >>>> I am not arguing that maintaining Smalltalk code is far superior to most technolgies out there. But depending on the needs of our projects we have to learn and use those crappy technologies to accomplish what they offer. Because, sometimes (especially if you have to pay bills), an existing library with flaws is better than none. >>>> >>>> So if I have to use Javascript or C# or Dart or Swift to do the frontend part of my system, is there still much benefit in using these together with Smalltalk? Or is there - at least from a managerâs point of view - not a reasonable amount of sense in choosing the frontend technology also for the logic and compensate the loss in productivity with a gain in avoided complexity? >>>> >>>> Your answer delivers a lot of food for thought, but I donât buy all of it. And I donât expect you to buy all of mine ;-) >>>> >>>> Joachim >>>> >>>>> >>>>> >>>>> 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>](%22mailto:pharo-users-bounces@lists.pharo.org%22) on behalf of David Mason [<dmason(a)ryerson.ca>](%22mailto:dmason@ryerson.ca%22) >>>>> Reply-To: Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](%22mailto:pharo-users@lists.pharo.org%22) >>>>> Date: Tuesday, October 24, 2017 at 11:52 AM >>>>> To: Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](%22mailto:pharo-users@lists.pharo.org%22) >>>>> 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](%22http:/pharojs.org%22) >>>>> >>>>> 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@objektfabrik.de](%22mailto:jtuchel@objektfabrik.de%22) <[jtuchel@objektfabrik.de](%22mailto:jtuchel@objektfabrik.de%22)> 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](%22mailto:jtuchel@objektfabrik.de%22) >>>>>> Fliederweg 1 [http://www.objektfabrik.de](%22http:/www.objektfabrik.de%22) >>>>>> D-71640 Ludwigsburg [http://joachimtuchel.wordpress.com](%22http:/joachimtuchel.wordpress.com%22) >>>>>> Telefon: [+49 7141 56 10 86 0](%22tel:%2B49%207141%2056%2010%2086%200%22) Fax: [+49 7141 56 10 86 1](%22tel:%2B49%207141%2056%2010%2086%201%22) >>>> >>>> â >>>> >>>> ââââââââââââââââââââââââ >>>> >>>> Objektfabrik Joachim Tuchel >>>> [mailto:jtuchel@objektfabrik.de](%22mailto:jtuchel@objektfabrik.de%22) >>>> >>>> Fliederweg 1 >>>> [http://www.objektfabrik.de](%22http:/www.objektfabrik.de%22) >>>> >>>> D-71640 Ludwigsburg >>>> [http://joachimtuchel.wordpress.com](%22http:/joachimtuchel.wordpress.com%22) >>>> >>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Oct. 28, 2017

Re: [Pharo-users] Actual Code to Improve the Pharo environment

by henry

Hi Andrew, Are you working to bring a Capabilities model to Pharo? This is precisely what I am working to bring with Hubbub, running on top of my ParrotTalk. I derived these from erights.org's ELib and have been working on them for many years. Now that ParrotTalk has stabilized (layer 5) I am shifting to implementing marshalling of layer 6 objects using STON all to run on top of ParrotTalk. Once I get marshalling with scope substitutions, I will debug Hubbub to offer distributed Capabilities. What work are you undertaking? Regards, - HH > -------- Original Message -------- > Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment > Local Time: October 28, 2017 9:12 AM > UTC Time: October 28, 2017 1:12 PM > From: aglynn42(a)gmail.com > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > Writing that kind of code is another of the reasons I decided I donât want to work in anything else ð. Maybe more important than some of the others, both to myself and to other users. > > Iâve gained so much personally, mostly for nothing, even just considering the relatively few projects I have been able to work on in Pharo and previously in Squeak, VW and VA. Unfortunately in most I havenât been able to make the code public, since they were for entities like the government, DoD, etc. > > Not that VA attracts me quite so much to give back all that strongly, when a license is $8500+. Were it possible to give back to VA C++ or VA Java, it might be different, but neither were OSS although they werenât expensive. More relevantly, both are now abandonware (hence my comment about IBM, which is applicable to OS/2 as well, although that has quietly had a 5.0 version released in June of this year). > > I would, though, love a chance to give back to Pharo primarily, although I may port anything relevant to Squeak, and if I have sufficient time port it to VW, which although not OSS is at least affordable to most developers. > > Iâm nearly there on a couple of projects â one Iâm testing and making final tweaks, another is about 2/3dâs of the way. > > The first project you (and others on the list) may be more immediately interested in testing, since it requires little to no additional work to use it, and even if not perfect, since itâs intended to directly help work you are doing in Pharo, it may worthwhile. Iâm hoping to have it ready for public consumption by the middle of November. > > On a different but related topic, the article I wrote got a fair amount of interest considering I donât write nearly as well as Kenneth, for example. Including direct interest from some well known industry people, which canât hurt. In an indirect way it may even be helpful, but not in the real, direct way decent code is. > > Capabilities that wonât be available in anything else in an really usable way (because to be efficient they depend on capabilities not found in anything else), and in any case nowhere near as useful in anything else, will hopefully be more use than any article can be, never mind one I wrote, not just to me but also to other Pharo users and to Pharo itself. > > Cheers > > Andrew Glynn > > Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 > > From: [Stephane Ducasse](mailto:stepharo.self@gmail.com) > Sent: Saturday, October 28, 2017 5:09 AM > To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org) > Subject: Re: [Pharo-users] Smalltalk Argument > > Hi andrew > > please take a project that would help to bring more companies and that you want to push and push it with us :). > > Stef > > On Sat, Oct 28, 2017 at 11:05 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > >> Hi andrew >> >> you should contact esteban because he is writing an objective-C bridge. >> >> Stef >> >> On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: >> >>> One thing Iâm working on is a bridge between Pharo and F-Script. F-Script is, basically, a Smalltalk dialect, as is obvious from the screenshot. However for MacOS and iOS, it allows you to bypass the static Objective-C API interface and debug / modify or even write applications directly in the system. To do that you âinjectâ F-Script into the OS. The ability to so has a specific implication, though. MacOS and iOS are themselves written in and as a dialect of Smalltalk. (were it simply an overlay on Objective-C, it wouldnât be able to do things that are impossible in Objective-C, and it wouldnât need to be âinjectedâ in order to run). Every implementation of Objective-C , bar GNUâs useless imitation, compiles to Smalltalk. No surprise that Appleâs does, as well. >>> >>> In any event, it will allow Pharo code to be mapped to MacOS and iOS objects, injected into the system dynamically, and modified / debugged dynamically using the Pharo tools. The result, at least as far as iOS is concerned, may make Pharo actually the most powerful way to program it, well beyond XCode alone, along with doing the same for MacOS. Android is another issue, although the Raspbian port of Pharo should be relatively easy to port to it. For me, unless someone had a use case, I donât have one myself for Android. Iâve tried nearly every version, because Iâd love to support an OSS ecosystem, unfortunately using it compared to the iPhone is still like driving a Fiero based kit car compared to an actual Ferrari. >>> >>> As far as JNI, while I see your point, JNI is such a PITA that few Java developers know it. My usual workaround is to use Stamp and Synapse, which has the further advantage of allowing Java to âthrottleâ data that the JVM canât deal with at full speed. >>> >>> As far as dealing with other JVM languages, PetitParser or SmaCC can generate bytecode rather than Java or other JVM code, and that allows libs to be written that utilize Synapse to talk to Pharo. It isnât necessarily an ideal solution, but a possible one without having to support umpteen environments. Another potential way of accomplishing that is to use NetRexx, a declarative JVM language, which is both easy and terse, and like SQL, generates the actual bytecode rather than precompiling to it. For instance, imagine the code needed for a simple âhello worldâ in Java, then compare: >>> >>> Say âhello worldâ >>> >>> Since it generates virtually the same bytecode, it may be an easy way to do it. >>> >>> With the last statement, that expresses really well the exact reason I no longer want to work in most other environments ð. >>> >>> Tc >>> >>> Andrew >>> >>> Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 >>> >>> From: phil(a)highoctane.be >>> Sent: Thursday, October 26, 2017 2:19 AM >>> To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org) >>> >>> Subject: Re: [Pharo-users] Smalltalk Argument >>> >>> 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](tel:%2B49%207141%2056%2010%2086%200) Fax: [+49 7141 56 10 86 1](tel:%2B49%207141%2056%2010%2086%201)

Oct. 28, 2017

Re: [Pharo-users] Actual Code to Improve the Pharo environment

by Andrew Glynn

Writing that kind of code is another of the reasons I decided I donât want to work in anything else ð. Maybe more important than some of the others, both to myself and to other users. Iâve gained so much personally, mostly for nothing, even just considering the relatively few projects I have been able to work on in Pharo and previously in Squeak, VW and VA. Unfortunately in most I havenât been able to make the code public, since they were for entities like the government, DoD, etc. Not that VA attracts me quite so much to give back all that strongly, when a license is $8500+. Were it possible to give back to VA C++ or VA Java, it might be different, but neither were OSS although they werenât expensive. More relevantly, both are now abandonware (hence my comment about IBM, which is applicable to OS/2 as well, although that has quietly had a 5.0 version released in June of this year). I would, though, love a chance to give back to Pharo primarily, although I may port anything relevant to Squeak, and if I have sufficient time port it to VW, which although not OSS is at least affordable to most developers. Iâm nearly there on a couple of projects â one Iâm testing and making final tweaks, another is about 2/3dâs of the way. The first project you (and others on the list) may be more immediately interested in testing, since it requires little to no additional work to use it, and even if not perfect, since itâs intended to directly help work you are doing in Pharo, it may worthwhile. Iâm hoping to have it ready for public consumption by the middle of November. On a different but related topic, the article I wrote got a fair amount of interest considering I donât write nearly as well as Kenneth, for example. Including direct interest from some well known industry people, which canât hurt. In an indirect way it may even be helpful, but not in the real, direct way decent code is. Capabilities that wonât be available in anything else in an really usable way (because to be efficient they depend on capabilities not found in anything else), and in any case nowhere near as useful in anything else, will hopefully be more use than any article can be, never mind one I wrote, not just to me but also to other Pharo users and to Pharo itself. Cheers Andrew Glynn Sent from Mail for Windows 10 From: Stephane Ducasse Sent: Saturday, October 28, 2017 5:09 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Hi andrew please take a project that would help to bring more companies and that you want to push and push it with us :). Stef On Sat, Oct 28, 2017 at 11:05 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: Hi andrew you should contact esteban because he is writing an objective-C bridge.Â Stef On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: One thing Iâm working on is a bridge between Pharo and F-Script.Â F-Script is, basically, a Smalltalk dialect, as is obvious from the screenshot.Â However for MacOS and iOS, it allows you to bypass the static Objective-C API interface and debug / modify or even write applications directly in the system.Â To do that you âinjectâ F-Script into the OS.Â The ability to so has a specific implication, though.Â MacOS and iOS are themselves written in and as a dialect of Smalltalk.Â (were it simply an overlay on Objective-C, it wouldnât be able to do things that are impossible in Objective-C, and it wouldnât need to be âinjectedâ in order to run).Â Every implementation of Objective-C , bar GNUâs useless imitation, compiles to Smalltalk.Â No surprise that Appleâs does, as well. Â In any event, it will allow Pharo code to be mapped to MacOS and iOS objects, injected into the system dynamically, and modified / debugged dynamically using the Pharo tools.Â The result, at least as far as iOS is concerned, may make Pharo actually the most powerful way to program it, well beyond XCode alone, along with doing the same for MacOS.Â Android is another issue, although the Raspbian port of Pharo should be relatively easy to port to it. For me, unless someone had a use case, I donât have one myself for Android.Â Iâve tried nearly every version, because Iâd love to support an OSS ecosystem, unfortunately using it compared to the iPhone is still like driving a Fiero based kit car compared to an actual Ferrari. Â As far as JNI, while I see your point, JNI is such a PITA that few Java developers know it.Â My usual workaround is to use Stamp and Synapse, which has the further advantage of allowing Java to âthrottleâ data that the JVM canât deal with at full speed. Â As far as dealing with other JVM languages, PetitParser or SmaCC can generate bytecode rather than Java or other JVM code, and that allows libs to be written that utilize Synapse to talk to Pharo.Â It isnât necessarily an ideal solution, but a possible one without having to support umpteen environments.Â Another potential way of accomplishing that is to use NetRexx, a declarative JVM language, which is both easy and terse, and like SQL, generates the actual bytecode rather than precompiling to it.Â For instance, imagine the code needed for a simple âhello worldâ in Java, then compare: Â Say âhello worldâ Â Since it generates virtually the same bytecode, it may be an easy way to do it. Â With the last statement, that expresses really well the exact reason I no longer want to work in most other environments ð. Â Tc Andrew Â Â Â Sent from Mail for Windows 10 Â From: phil(a)highoctane.be Sent: Thursday, October 26, 2017 2:19 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Â 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. 28, 2017

Re: [Pharo-users] Read-only images / how to deploy new image as fast as possible?

by Tim Mackinnon

Hi Herby - for #1, yes you can do that (I do this in PharoLambda) - there was a snippet from Sven on how to do it (you need to override 2 classes I seem to recall) , if you search in the archives you should find it. I'm not near a computer to give you the exact bit - but if you can't find it I'll pop a reply tomorrow. Tim Sent from my iPhone > On 28 Oct 2017, at 12:46, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > Hi, > > I came to the phase where I actually deploy the small backend written in Pharo, and I wonder about two things: > > 1. Is it possible to make .image / .changes read-only? Will Pharo just work (not writing the image, but that is not needed, all data are in sqlite file)? > > 2. How to "switch" images as fast as possible? I presume there is no way to tell vm to "stop doing this and reload different image" or something like that? I need to stop the runninng one and then start the new one? Or is it possible to "swap" the read-only image for new one and tell VM to reload (just wanting to minimize the off-time). > > Thanks, Herby >

Oct. 28, 2017

Read-only images / how to deploy new image as fast as possible?

by Herby VojÄÃk

Hi, I came to the phase where I actually deploy the small backend written in Pharo, and I wonder about two things: 1. Is it possible to make .image / .changes read-only? Will Pharo just work (not writing the image, but that is not needed, all data are in sqlite file)? 2. How to "switch" images as fast as possible? I presume there is no way to tell vm to "stop doing this and reload different image" or something like that? I need to stop the runninng one and then start the new one? Or is it possible to "swap" the read-only image for new one and tell VM to reload (just wanting to minimize the off-time). Thanks, Herby

Oct. 28, 2017

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

by Steffen MÃ¤rcker

I see. What is the task in detail? Are some of the set fixed or known in advance? What's the argument against a bitset-based solution? Cheers, Steffen Am 27. Oktober 2017 19:10:35 MESZ schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: >It was for test inclusion of UTF-8 characters so we do not want to >rely on external libraries. > >On Fri, Oct 27, 2017 at 1:54 PM, Steffen MÃ¤rcker <merkste(a)web.de> >wrote: >> Dear Andrew, >> >> I didn't find time to answer earlier. Some time ago, I was looking >for a >> (MT)BDD package in ST as well. I didn't found one. So the only two >options >> left are >> >> 1) implementing a new BDD lib in ST and >> 2) doing FFI to some existing lib, e.g. CUDD, Sylvan, Jinc >> >> I'd prefer 2) since the existing libraries are feature-rich and >highly >> optimized - which took quite some time. As a bonus, a solution could >> potentially switch between those backends. The biggest hurdle, in my >option, >> is memory management, since most libs use some sort of reference >counting. >> And you do not want to end up with nightmarish dozens of ref(bddNode) >> deref(bddNode) in your application code (like the probabilistic model >> checker PRISM does). This introduces hard to track bugs easily. >However, I >> have an idea in mind how to tackle this but I didn't found the time >to put >> it into code yet. >> >> May I ask, which sort of application do you have in mind? >> >> Best, Steffen >> >> >> >> >> Am .10.2017, 07:54 Uhr, schrieb Prof. Andrew P. Black ><black(a)cs.pdx.edu>: >> >>> Thanks for the responses so far. I see that I need to clarify my >enquiry. >>> >>> B-Trees and BDDs are not the same. BDDs are an efficient and >compact >>> representations for Boolean functions, sometimes used in SAT-solvers >and >>> electronics design. The key idea is that since the output must be >0 or 1, >>> you can represent any Boolean function as a tree whose depth is the >same as >>> the number of bits in the input. >>> >>> To make the tree small and efficient, though, you need to eliminate >any >>> node whose two children are the same, and to share subtrees, so that >you >>> really get a DAG, not a tree. The full name for these efficient >compressed >>> trees is âReduced Order Binary Decision Diagramsâ, or ROBDDs. I was >hoping >>> that someone else had implemented the algorithms necessary to build >this >>> representation. >>> >>> Because sets can be considered to be Booleans functions (true => >argument >>> is in the set), you can use ROBDDs to efficiently represent large >sets. >>> >>> To be clear, despite the word âdiagramâ in the name, one is not >normally >>> interested in drawing the BDD â except in the documentation for the >package >>> ;-). Normally, BDDs they are used to represent sets, or functions, >where >>> the drawing would be hopelessly large. >>> >>> The BuDDy package (http://buddy.sourceforge.net/manual/main.html) is >an >>> example of what Iâm looking for, but unfortunately itâs in C++. >>> >>> Andrew >>> >>> >>>> On 25 Oct 2017, at 21:39 , 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 >>>> >>>> >>>> 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. 28, 2017

What is code 137 / how to gracefully shut down via SIGTERM?

by Herby VojÄÃk

Hi, I had to find out how to automatically deploy the backend written in Pharo, and so far it uses docker-compose stop to stop the instance (and later docker-compose up -d to get everything up again). I noticed the stop phase takes a while and ends with status code 137. I presume it ended forcefully and not gracefully. What is the idiomatic way to wait on SIGTERM and close the process gracefully? Thanks, Herby

Oct. 28, 2017

Re: [Pharo-users] Netstyle/Workflow Package discovery - (was: Business process (declaration and orchestration), ontology/taxonomy)

by CÃ©drick BÃ©ler

> ok for now publish your changes on smalltalkhub somewhere so that they > do not stay on your machine. Even if very very experimental :) Iâll do. Just need a bit more work and comment what I did. I have unsolved references to this classes too. DomBuilder IDBasicManager IDCurrentManager Any ideas ? Iâll read more carefully the white paper and see if XMLParser can help here. But is someone knows about this classesâ¦ Cheers, CÃ©drick > > On Sat, Oct 28, 2017 at 7:52 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: >> >>> >>> Did you send pull requests? >> >> Euh, actually I still donât really know how to use git. >> >> I loaded it through metacello. Can I simply a sunlit code that way ? >> >> The code is quite documented already and there are tests. >> >> I kind of fixed some tests but not sure this was the way to do so (beginHistory has no action for instance). >> >> All the xpdl import/export fail but this is due to one method that need a DOMbuilder and two other class I have no clue. >> >> And I still havenât find how to execute a process ^^ >> >> Iâll have another look today. >> >> Cheers, >> >> CÃ©drick >> >>> >>> Stef >>> >>>> On Fri, Oct 27, 2017 at 2:32 PM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: >>>> A pleasure to discover ! To me, a wonderful(ly engineered) library. >>>> >>>> Big thanks to Netstyle ! >>>> >>>> Iâm just getting my hands around, but it looks to me like a great general purpose BP tool (modeling + engine + xpdl import export). >>>> It would be very useful for IS in industrial contexts (*). And before all a superb starting point to model my simple personal routines as executable processes. >>>> >>>> On the practical aspects, just a problem loading because of WADynamicVariable, but it kinds of load on Pharo 6. >>>> Running tests, there are (naturally) some failures. I think most come from the removed links to Omnibase/History support and seaside (WADynamicVariable). >>>> >>>> Some stuffs that are missing: >>>> #isOmniBaseTransaction >>>> #markDirty >>>> A reference to TimeStamp fixed: >>>> #beginInHistory >>>> â¦ >>>> >>>> Need to fix WADynamicVariable with shouldnât be hard. >>>> The History link (persistence) is a bit more difficult as I donât know its importance in the engine. >>>> All Workflow object are managed object which (if I understand well) are persistent object. So maybe It need a (local) persistent alternative, a stub ? >>>> >>>> Anyway, I need to understand more and I will probably come back with some questions about the dependencies and how to fix them. >>>> >>>> >>>> Cheers and thanks again, enligthening code :) >>>> >>>> CÃ©drick >>>> >>>> >>>> >>>> * Interoperability of is a field I try carefully not to enter because I found not really fun (as most of the tool Iâve soon were java based â¦ and slowâ¦ and java world !) but if only I had similar tools in pharo that could bring the fun back :) >>>> >>>> >>>> >>>> >>>> >>>>> Le 27 oct. 2017 Ã 09:37, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> a Ã©crit : >>>>> >>>>> Thank you! >>>>> >>>>> I thons this just perfect as a starting point ! >>>>> >>>>> Cheers, >>>>> >>>>> Cedrick >>>>> >>>>> EnvoyÃ© de mon iPhone >>>>> >>>>>> Le 26 oct. 2017 Ã 19:38, Paul DeBruicker <pdebruic(a)gmail.com> a Ã©crit : >>>>>> >>>>>> 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. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Stephane Ducasse

Hi andrew please take a project that would help to bring more companies and that you want to push and push it with us :). Stef On Sat, Oct 28, 2017 at 11:05 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi andrew > > you should contact esteban because he is writing an objective-C bridge. > > Stef > > On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > >> One thing Iâm working on is a bridge between Pharo and F-Script. >> F-Script is, basically, a Smalltalk dialect, as is obvious from the >> screenshot. However for MacOS and iOS, it allows you to bypass the static >> Objective-C API interface and debug / modify or even write applications >> directly in the system. To do that you âinjectâ F-Script into the OS. The >> ability to so has a specific implication, though. MacOS and iOS are >> themselves written in and as a dialect of Smalltalk. (were it simply an >> overlay on Objective-C, it wouldnât be able to do things that are >> impossible in Objective-C, and it wouldnât need to be âinjectedâ in order >> to run). Every implementation of Objective-C , bar GNUâs useless >> imitation, compiles to Smalltalk. No surprise that Appleâs does, as well. >> >> >> >> In any event, it will allow Pharo code to be mapped to MacOS and iOS >> objects, injected into the system dynamically, and modified / debugged >> dynamically using the Pharo tools. The result, at least as far as iOS is >> concerned, may make Pharo actually the most powerful way to program it, >> well beyond XCode alone, along with doing the same for MacOS. Android is >> another issue, although the Raspbian port of Pharo should be relatively >> easy to port to it. For me, unless someone had a use case, I donât have one >> myself for Android. Iâve tried nearly every version, because Iâd love to >> support an OSS ecosystem, unfortunately using it compared to the iPhone is >> still like driving a Fiero based kit car compared to an actual Ferrari. >> >> >> >> As far as JNI, while I see your point, JNI is such a PITA that few Java >> developers know it. My usual workaround is to use Stamp and Synapse, which >> has the further advantage of allowing Java to âthrottleâ data that the JVM >> canât deal with at full speed. >> >> >> >> As far as dealing with other JVM languages, PetitParser or SmaCC can >> generate bytecode rather than Java or other JVM code, and that allows libs >> to be written that utilize Synapse to talk to Pharo. It isnât necessarily >> an ideal solution, but a possible one without having to support umpteen >> environments. Another potential way of accomplishing that is to use >> NetRexx, a declarative JVM language, which is both easy and terse, and like >> SQL, generates the actual bytecode rather than precompiling to it. For >> instance, imagine the code needed for a simple âhello worldâ in Java, then >> compare: >> >> >> >> Say âhello worldâ >> >> >> >> Since it generates virtually the same bytecode, it may be an easy way to >> do it. >> >> >> >> With the last statement, that expresses really well the exact reason I no >> longer want to work in most other environments ð. >> >> >> >> Tc >> >> Andrew >> >> >> >> >> >> >> >> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for >> Windows 10 >> >> >> >> *From: *phil(a)highoctane.be >> *Sent: *Thursday, October 26, 2017 2:19 AM >> *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >> *Subject: *Re: [Pharo-users] Smalltalk Argument >> >> >> >> 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 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 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. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Stephane Ducasse

Hi andrew you should contact esteban because he is writing an objective-C bridge. Stef On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > One thing Iâm working on is a bridge between Pharo and F-Script. F-Script > is, basically, a Smalltalk dialect, as is obvious from the screenshot. > However for MacOS and iOS, it allows you to bypass the static Objective-C > API interface and debug / modify or even write applications directly in the > system. To do that you âinjectâ F-Script into the OS. The ability to so > has a specific implication, though. MacOS and iOS are themselves written > in and as a dialect of Smalltalk. (were it simply an overlay on > Objective-C, it wouldnât be able to do things that are impossible in > Objective-C, and it wouldnât need to be âinjectedâ in order to run). Every > implementation of Objective-C , bar GNUâs useless imitation, compiles to > Smalltalk. No surprise that Appleâs does, as well. > > > > In any event, it will allow Pharo code to be mapped to MacOS and iOS > objects, injected into the system dynamically, and modified / debugged > dynamically using the Pharo tools. The result, at least as far as iOS is > concerned, may make Pharo actually the most powerful way to program it, > well beyond XCode alone, along with doing the same for MacOS. Android is > another issue, although the Raspbian port of Pharo should be relatively > easy to port to it. For me, unless someone had a use case, I donât have one > myself for Android. Iâve tried nearly every version, because Iâd love to > support an OSS ecosystem, unfortunately using it compared to the iPhone is > still like driving a Fiero based kit car compared to an actual Ferrari. > > > > As far as JNI, while I see your point, JNI is such a PITA that few Java > developers know it. My usual workaround is to use Stamp and Synapse, which > has the further advantage of allowing Java to âthrottleâ data that the JVM > canât deal with at full speed. > > > > As far as dealing with other JVM languages, PetitParser or SmaCC can > generate bytecode rather than Java or other JVM code, and that allows libs > to be written that utilize Synapse to talk to Pharo. It isnât necessarily > an ideal solution, but a possible one without having to support umpteen > environments. Another potential way of accomplishing that is to use > NetRexx, a declarative JVM language, which is both easy and terse, and like > SQL, generates the actual bytecode rather than precompiling to it. For > instance, imagine the code needed for a simple âhello worldâ in Java, then > compare: > > > > Say âhello worldâ > > > > Since it generates virtually the same bytecode, it may be an easy way to > do it. > > > > With the last statement, that expresses really well the exact reason I no > longer want to work in most other environments ð. > > > > Tc > > Andrew > > > > > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > > *From: *phil(a)highoctane.be > *Sent: *Thursday, October 26, 2017 2:19 AM > *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject: *Re: [Pharo-users] Smalltalk Argument > > > > 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. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Dimitris Chloupis

On Sat, Oct 28, 2017 at 6:10 AM Andrew Glynn <aglynn42(a)gmail.com> wrote: > Web dev is a messy field. Not because it has grown too fast, but because > it was designed by amateurs, developed by amateurs, and continues to be so, > while depending on an underlying expertly designed system, the internet. > Non sense. Companies have been heavily involved in the developing of the web since day one. Javascript was not designed by an amateur and pretty much no web dev technologies out there not only are produced since day 1 from professional coders , web standards committess played a crucial role in the developing of web technologies. The web has always been a huge cash cow. The very fact that Javascript has the name Java is not as many developers will be quick to point unrelated Java. It is very much related. . Sun for a considerable amount of time was working on Javascript as a scripting engine targeting the web working hand in hand with Java. The relationship was sort lived but for a very long time Java was the de facto language for developing powerful web application / websites. The well known Java applets that exist even today. The reason why the web followed its own road is quite sensible. The internet was viewed as nothing more than a display of documents and made sense to use a document format (HTML) for it at the time. It was easy and accesible to anyone. None could predict the explosion of the web at the time and the future needs for much greater degree of dynamism. Neither could I and I am vicious critic of web dev. The technology evolved very fast that not even up for debate, good designs require redesigns. Redesigns require time. The web was nothing really new neither was the internet. BBS were dominating online communication and function in a very similar way that the web did later on providing, email, messages, forumes, download directories, blog posts, articles and a wealth of information through the use of a model and a regular telophone line. BBS were based on desktop technology and far better designed but they could not keep up with the incrasing demands of massive online communication so the web and the internet ignated even though internet was create far earlier than BBS. Much less likely to find cat videos because BBS was based on P2P kind of technology and was working on very limited hardware where every byte was precious. It was the failure of desktop technologies to adjust to the need for a web that lead to its seperate evolution. Java was the only language that took a serious interest into web developing and even Java was unwilling to adjust to the needs of the web leading to the massive failure of the Java applet. On the other hand Flash that was specifically designed for the web , flourished for many years till HTML and JS finally caught up. Amateurs also play a very importan role in the evolution of graphics and guis. Teenage hackers were the ones to ignite the trend of computer graphics that lead to the establishment of GUI and 3d graphics as well as computer audio even though those technologies have existed far earlier it was their innovation that managed to take advantage of clever solution to overcome extreme limitations of the hardware. This happened through the developing of "demos" giving rise to a completely new community of extrmely knowledgable amateurs knows as "demoscene" and hackers. 3d graphics to this day remain the most fast moving / evolving field of computer science challanged only by AI. Plus Amateurs play a vital role in many other fields like Astronomy , their contribution is so substabtial that many celestial bodies are named after them. Amateurs have usually far higher level of knowledge of a field mainly because they tend to avoid specialisation and they do not operate on the time constraints or have to fight a backward thinking management department that want to do things "the popular" way. For similar reason they pay far more respect to designs as well. So it was both the failure of desktop to take into serious consideration the new web needs and the rapid evolution of the web based on the format that it was already problematic. It was companies themselves that hindered and keep hindering its evolution with being stuck on bad design for the shake of backward compatibility. On the other hand desktop has it own share of ugliness and "amateurism" biggest example being MFC , Microsoft's Official GUI API, that was so ugly and heavily disliked that none even question the existence of HTML because no coder in his right mind could consider imposing such a terrible design to a new technology. On similar note web is not all that bad, JS has heavily improved as a language , HTML has become extremely flexible and there are many well designed libraries like Bootstrap , D3 etc . Also desktop language learned their lesson and now fully embreace web dev at least on the back end. Finally nowdays we see the merging of web and desktop technlogies (and the branch of desktop development known as "mobile development") that has brought more sanity and uniformity into the development process. Unfortunately companies still play a very big role in the glacial evolution of the web that is fortunately dimisihing with the emergence of free software.

Oct. 28, 2017

Re: [Pharo-users] Netstyle/Workflow Package discovery - (was: Business process (declaration and orchestration), ontology/taxonomy)

by Stephane Ducasse

ok for now publish your changes on smalltalkhub somewhere so that they do not stay on your machine. On Sat, Oct 28, 2017 at 7:52 AM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > >> >> Did you send pull requests? > > Euh, actually I still donât really know how to use git. > > I loaded it through metacello. Can I simply a sunlit code that way ? > > The code is quite documented already and there are tests. > > I kind of fixed some tests but not sure this was the way to do so (beginHistory has no action for instance). > > All the xpdl import/export fail but this is due to one method that need a DOMbuilder and two other class I have no clue. > > And I still havenât find how to execute a process ^^ > > Iâll have another look today. > > Cheers, > > CÃ©drick > >> >> Stef >> >>> On Fri, Oct 27, 2017 at 2:32 PM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: >>> A pleasure to discover ! To me, a wonderful(ly engineered) library. >>> >>> Big thanks to Netstyle ! >>> >>> Iâm just getting my hands around, but it looks to me like a great general purpose BP tool (modeling + engine + xpdl import export). >>> It would be very useful for IS in industrial contexts (*). And before all a superb starting point to model my simple personal routines as executable processes. >>> >>> On the practical aspects, just a problem loading because of WADynamicVariable, but it kinds of load on Pharo 6. >>> Running tests, there are (naturally) some failures. I think most come from the removed links to Omnibase/History support and seaside (WADynamicVariable). >>> >>> Some stuffs that are missing: >>> #isOmniBaseTransaction >>> #markDirty >>> A reference to TimeStamp fixed: >>> #beginInHistory >>> â¦ >>> >>> Need to fix WADynamicVariable with shouldnât be hard. >>> The History link (persistence) is a bit more difficult as I donât know its importance in the engine. >>> All Workflow object are managed object which (if I understand well) are persistent object. So maybe It need a (local) persistent alternative, a stub ? >>> >>> Anyway, I need to understand more and I will probably come back with some questions about the dependencies and how to fix them. >>> >>> >>> Cheers and thanks again, enligthening code :) >>> >>> CÃ©drick >>> >>> >>> >>> * Interoperability of is a field I try carefully not to enter because I found not really fun (as most of the tool Iâve soon were java based â¦ and slowâ¦ and java world !) but if only I had similar tools in pharo that could bring the fun back :) >>> >>> >>> >>> >>> >>>> Le 27 oct. 2017 Ã 09:37, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> a Ã©crit : >>>> >>>> Thank you! >>>> >>>> I thons this just perfect as a starting point ! >>>> >>>> Cheers, >>>> >>>> Cedrick >>>> >>>> EnvoyÃ© de mon iPhone >>>> >>>>> Le 26 oct. 2017 Ã 19:38, Paul DeBruicker <pdebruic(a)gmail.com> a Ã©crit : >>>>> >>>>> 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. 28, 2017

Re: [Pharo-users] [Pharo-dev] [ANN] Iceberg 0.6.2 backported to Pharo 6.1

by Tudor Girba

Great work! Doru > On Oct 27, 2017, at 11:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > I backported lastest Iceberg version to Pharo 6.1 to allow people to benefit for latest changes. > This version has an important amount of tweak and fixes, but most important is the inclusion of tonel file format (this is default for Pharo 7.0, optional for Pharo 6.1) and introduces a file-per-class format. > The advantages of this format has everything to do with the speed of access (is easier to reconstruct a package like) and the space on disk (methods are usually small but minimum space in disk is usually 4k so we waste a lot of space). Is also a better format for SSD disks. > > To backport Iceberg 0.6.2 I also needed to backport latest version of Metacello, so Pharo 6.1 and Pharo7+ users now also have the latest version of it available :) > > cheers! > Esteban > > > > > -- www.tudorgirba.com www.feenk.com "We cannot reach the flow of things unless we let go."

Oct. 28, 2017

Re: [Pharo-users] Netstyle/Workflow Package discovery - (was: Business process (declaration and orchestration), ontology/taxonomy)

by CÃ©drick BÃ©ler

> > Did you send pull requests? Euh, actually I still donât really know how to use git. I loaded it through metacello. Can I simply a sunlit code that way ? The code is quite documented already and there are tests. I kind of fixed some tests but not sure this was the way to do so (beginHistory has no action for instance). All the xpdl import/export fail but this is due to one method that need a DOMbuilder and two other class I have no clue. And I still havenât find how to execute a process ^^ Iâll have another look today. Cheers, CÃ©drick > > Stef > >> On Fri, Oct 27, 2017 at 2:32 PM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: >> A pleasure to discover ! To me, a wonderful(ly engineered) library. >> >> Big thanks to Netstyle ! >> >> Iâm just getting my hands around, but it looks to me like a great general purpose BP tool (modeling + engine + xpdl import export). >> It would be very useful for IS in industrial contexts (*). And before all a superb starting point to model my simple personal routines as executable processes. >> >> On the practical aspects, just a problem loading because of WADynamicVariable, but it kinds of load on Pharo 6. >> Running tests, there are (naturally) some failures. I think most come from the removed links to Omnibase/History support and seaside (WADynamicVariable). >> >> Some stuffs that are missing: >> #isOmniBaseTransaction >> #markDirty >> A reference to TimeStamp fixed: >> #beginInHistory >> â¦ >> >> Need to fix WADynamicVariable with shouldnât be hard. >> The History link (persistence) is a bit more difficult as I donât know its importance in the engine. >> All Workflow object are managed object which (if I understand well) are persistent object. So maybe It need a (local) persistent alternative, a stub ? >> >> Anyway, I need to understand more and I will probably come back with some questions about the dependencies and how to fix them. >> >> >> Cheers and thanks again, enligthening code :) >> >> CÃ©drick >> >> >> >> * Interoperability of is a field I try carefully not to enter because I found not really fun (as most of the tool Iâve soon were java based â¦ and slowâ¦ and java world !) but if only I had similar tools in pharo that could bring the fun back :) >> >> >> >> >> >>> Le 27 oct. 2017 Ã 09:37, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> a Ã©crit : >>> >>> Thank you! >>> >>> I thons this just perfect as a starting point ! >>> >>> Cheers, >>> >>> Cedrick >>> >>> EnvoyÃ© de mon iPhone >>> >>>> Le 26 oct. 2017 Ã 19:38, Paul DeBruicker <pdebruic(a)gmail.com> a Ã©crit : >>>> >>>> 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. 28, 2017

Re: [Pharo-users] Netstyle/Workflow Package discovery - (was: Business process (declaration and orchestration), ontology/taxonomy)

by CÃ©drick BÃ©ler

I found a WfHistory package but donât know how to write the beginHistory stuff. It seems to be a repository of versions of a process (maybe each step gives another version ?). > Le 27 oct. 2017 Ã 19:07, Stephane Ducasse <stepharo.self(a)gmail.com> a Ã©crit : > > Did you send pull requests? > > Stef > >> On Fri, Oct 27, 2017 at 2:32 PM, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: >> A pleasure to discover ! To me, a wonderful(ly engineered) library. >> >> Big thanks to Netstyle ! >> >> Iâm just getting my hands around, but it looks to me like a great general purpose BP tool (modeling + engine + xpdl import export). >> It would be very useful for IS in industrial contexts (*). And before all a superb starting point to model my simple personal routines as executable processes. >> >> On the practical aspects, just a problem loading because of WADynamicVariable, but it kinds of load on Pharo 6. >> Running tests, there are (naturally) some failures. I think most come from the removed links to Omnibase/History support and seaside (WADynamicVariable). >> >> Some stuffs that are missing: >> #isOmniBaseTransaction >> #markDirty >> A reference to TimeStamp fixed: >> #beginInHistory >> â¦ >> >> Need to fix WADynamicVariable with shouldnât be hard. >> The History link (persistence) is a bit more difficult as I donât know its importance in the engine. >> All Workflow object are managed object which (if I understand well) are persistent object. So maybe It need a (local) persistent alternative, a stub ? >> >> Anyway, I need to understand more and I will probably come back with some questions about the dependencies and how to fix them. >> >> >> Cheers and thanks again, enligthening code :) >> >> CÃ©drick >> >> >> >> * Interoperability of is a field I try carefully not to enter because I found not really fun (as most of the tool Iâve soon were java based â¦ and slowâ¦ and java world !) but if only I had similar tools in pharo that could bring the fun back :) >> >> >> >> >> >>> Le 27 oct. 2017 Ã 09:37, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> a Ã©crit : >>> >>> Thank you! >>> >>> I thons this just perfect as a starting point ! >>> >>> Cheers, >>> >>> Cedrick >>> >>> EnvoyÃ© de mon iPhone >>> >>>> Le 26 oct. 2017 Ã 19:38, Paul DeBruicker <pdebruic(a)gmail.com> a Ã©crit : >>>> >>>> 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. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

Hadoop, if one wanted to utilize it in a similar way to Spark, Storm, Kafka, HDB, or the PostgreSQL overlay (the latter can be done now using either Garage + GLORP, or slightly faster using the newer GLORP PostgreSQL integration), might be best implemented as a SQL driver. Using GLORP with Garage via the other methods mentioned would give a similar ability to avoid map/reduce. Map/reduce, though, is 2/3âds of the advantage of Hadoop, so avoiding it seems counterproductive if writing new code (simply using the PostgreSQL requires no new code). Granted, thinking how to do numerous things that have well known SQL solutions is not necessarily easy via map/reduce, which somewhat explains the proliferation of ways of avoiding it. On the other hand, not using it somewhat cripples the effectiveness of Hadoop, which is exacerbated by the concurrency limitations of using a JVM language, whether Java, Scala, or anything else that compiles to JVM bytecode. Sent from Mail for Windows 10 From: henry Sent: Friday, October 27, 2017 5:03 PM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Elastic search JSON integration would be another good one. I heard there was a Kafka integration, is that true? Where could I find that, I used to use Kafka. Kafka is a great event channel for input to BigData. Using Kafka, it is well in crafting a Lamda Architecture. Imagine Pharo where Storm resides. - HH On Fri, Oct 27, 2017 at 16:51, henry <henry(a)callistohouse.club> wrote: Â How about Kerberos? Can we get a team to look closely at bringing integration for enterprise users? That would be helpful, or can you just put it behind a Kerberos wrapper? If that would work, collecting a demo, that could unlock more corporate wallets , for investment. - HH On Fri, Oct 27, 2017 at 16:41, henry <henry(a)callistohouse.club> wrote: How is there no steering committee to accumulate wrapping 3rd party libraries in Alien to gain benefits of code in other languages? Do not assume that code is not extremely well written in that particular language for that particular task and that particular deployment mechanism. Can Pharo be called as a shared library from Java JNA? - HH On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglynn42(a)gmail.com> wrote: Iâm not claiming I donât or havenât been affected, only that I no long allow myself to be.Â Does that cause issues?Â Of course.Â But Iâd rather deal with those than do things I donât enjoy.Â However I only got to that point after 26 years in the industry, so I donât expect that everyone will feel that way. Â Cheers Andrew Â Sent from Mail for Windows 10 Â From: jtuchel(a)objektfabrik.de Sent: Thursday, October 26, 2017 8:14 AM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] Smalltalk Argument Â Andrew, Am 26.10.17 um 00:46 schrieb Andrew Glynn: Thereâs other questions that are relevant to me: I am glad you opened your words with this sentence. Other peoplesâ mileages may vary a lot. > 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. Â Some people canât. I canât. I am making my living with a web based application. And I like 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.> So you are in the lucky position that neither mobile nor web nor integration matters to you or you have enough resources to do all that stuff yourself. I am envyous. I need to build web pages and people ask me whether we can ship an iPhone App. I do customer-facing stuff and sex sells much more than we like to think. Your comments on the crappiness of libs in other languages is a great fit for Smalltalk. Not invented here, therefor rubbish. We came a long way with this way of thinking. But these rubbish makers dance circles around us while we try to do our first hello world for an iPad. They laugh at us when we try to reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). Because they are back home and watch Netflix while we debug our homegrown base libraries that are, of course, much better than theirs because they are written in Smalltalk. I am not arguing that maintaining Smalltalk code is far superior to most technolgies out there. But depending on the needs of our projects we have to learn and use those crappy technologies to accomplish what they offer. Because, sometimes (especially if you have to pay bills), an existing library with flaws is better than none. So if I have to use Javascript or C# or Dart or Swift to do the frontend part of my system, is there still much benefit in using these together with Smalltalk? Or is there - at least from a managerâs point of view - not a reasonable amount of sense in choosing the frontend technology also for the logic and compensate the loss in productivity with a gain in avoided complexity? Your answer delivers a lot of food for thought, but I donât buy all of it. And I donât expect you to buy all of mine ;-) Joachim Â Â 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 Â Â â ââââââââââââââââââââââââ 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. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

I refer to it as âCraptive Directoryâ, the only reliable way Iâve found to use it is to federate it via WSO2 IS or OpenIDM. You forgot Sunâs implementation, btw, which is cleaner than either. Sent from Mail for Windows 10 From: phil(a)highoctane.be Sent: Thursday, October 26, 2017 6:07 PM To: henry; Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument 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. - 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> 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 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-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. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

Last point. Blocks are already better lambdas than lambdas in Java. Have a look at this code from rxJava, which includes the Java 8 lambda version and a Java 7 version using an anonymous inner class: Java 8 code package rxjava.examples; import io.reactivex.*; public class HelloWorld { public static void main(String[] args) { Flowable.just("Hello world").subscribe(System.out::println); } } Java 7 code import io.reactivex.functions.Consumer; Flowable.just("Hello world") .subscribe(new Consumer<String>() { @Override public void accept(String s) { System.out.println(s); } }); Are they equivalent? How would you know? In fact, they arenât, worse, the results of the difference depend on the target, whether itâs Java SE (including Spring based apps) or JavaEE. The Java 8 version doesnât create an anonymous inner class but a generically named class with generically named methods. As a result, it will be most often faster. However itâs less safe, because particularly in clustered environments, and unpredictably, it can create conflicts due to the same generic names being used by two different JVMâs. The Java 7 version will be as fast, in JavaEE, and safer. In Java SE theyâre close to equivalently safe, but the Java 7 version will be significantly slower in most cases. RxJava itself, as well, is unnecessary in Pharo, since the Announcer already implements the same pattern, and does so in a more efficient and more consistent way. Sent from Mail for Windows 10 From: henry Sent: Friday, October 27, 2017 5:03 PM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Elastic search JSON integration would be another good one. I heard there was a Kafka integration, is that true? Where could I find that, I used to use Kafka. Kafka is a great event channel for input to BigData. Using Kafka, it is well in crafting a Lamda Architecture. Imagine Pharo where Storm resides. - HH On Fri, Oct 27, 2017 at 16:51, henry <henry(a)callistohouse.club> wrote: Â How about Kerberos? Can we get a team to look closely at bringing integration for enterprise users? That would be helpful, or can you just put it behind a Kerberos wrapper? If that would work, collecting a demo, that could unlock more corporate wallets , for investment. - HH On Fri, Oct 27, 2017 at 16:41, henry <henry(a)callistohouse.club> wrote: How is there no steering committee to accumulate wrapping 3rd party libraries in Alien to gain benefits of code in other languages? Do not assume that code is not extremely well written in that particular language for that particular task and that particular deployment mechanism. Can Pharo be called as a shared library from Java JNA? - HH On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglynn42(a)gmail.com> wrote: Iâm not claiming I donât or havenât been affected, only that I no long allow myself to be.Â Does that cause issues?Â Of course.Â But Iâd rather deal with those than do things I donât enjoy.Â However I only got to that point after 26 years in the industry, so I donât expect that everyone will feel that way. Â Cheers Andrew Â Sent from Mail for Windows 10 Â From: jtuchel(a)objektfabrik.de Sent: Thursday, October 26, 2017 8:14 AM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] Smalltalk Argument Â Andrew, Am 26.10.17 um 00:46 schrieb Andrew Glynn: Thereâs other questions that are relevant to me: I am glad you opened your words with this sentence. Other peoplesâ mileages may vary a lot. > 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. Â Some people canât. I canât. I am making my living with a web based application. And I like 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.> So you are in the lucky position that neither mobile nor web nor integration matters to you or you have enough resources to do all that stuff yourself. I am envyous. I need to build web pages and people ask me whether we can ship an iPhone App. I do customer-facing stuff and sex sells much more than we like to think. Your comments on the crappiness of libs in other languages is a great fit for Smalltalk. Not invented here, therefor rubbish. We came a long way with this way of thinking. But these rubbish makers dance circles around us while we try to do our first hello world for an iPad. They laugh at us when we try to reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). Because they are back home and watch Netflix while we debug our homegrown base libraries that are, of course, much better than theirs because they are written in Smalltalk. I am not arguing that maintaining Smalltalk code is far superior to most technolgies out there. But depending on the needs of our projects we have to learn and use those crappy technologies to accomplish what they offer. Because, sometimes (especially if you have to pay bills), an existing library with flaws is better than none. So if I have to use Javascript or C# or Dart or Swift to do the frontend part of my system, is there still much benefit in using these together with Smalltalk? Or is there - at least from a managerâs point of view - not a reasonable amount of sense in choosing the frontend technology also for the logic and compensate the loss in productivity with a gain in avoided complexity? Your answer delivers a lot of food for thought, but I donât buy all of it. And I donât expect you to buy all of mine ;-) Joachim Â Â 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 Â Â â ââââââââââââââââââââââââ 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. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

Thereâs a million ways of accomplishing such things, but you need to pick the appropriate way to do it, given restrictions in Pharo and limitations in whatâs itâs calling. You can utilize Kafka or Kerberos authentication via Synapse, for instance, you can access virtually any authentication mechanism via WSO2 IS (itself built on Synapse). Another way of accessing the same things (plus numerous others) is via Vert.x, also directly supported from the Pharo catalog. Iâve used that methodology as well, though I had to overcome Vert.xâs own limitations by mapping it to the more capable Apache River (formerly JINI). You can access Hadoop / Cassandra / MongoDB via the same methods Kafka, Storm and Spark do, without the problems introduced by the JVM. MongoDB and Cassandra have libraries already available in Pharo, and they work better than those available elsewhere. There are even ways to directly access the Open Telephony API in ERLAN. Sometimes you need to be creative, and every time you need to understand the strengths and limitations of both what youâre using, and what youâre accessing. Sent from Mail for Windows 10 From: henry Sent: Friday, October 27, 2017 5:03 PM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Elastic search JSON integration would be another good one. I heard there was a Kafka integration, is that true? Where could I find that, I used to use Kafka. Kafka is a great event channel for input to BigData. Using Kafka, it is well in crafting a Lamda Architecture. Imagine Pharo where Storm resides. - HH On Fri, Oct 27, 2017 at 16:51, henry <henry(a)callistohouse.club> wrote: Â How about Kerberos? Can we get a team to look closely at bringing integration for enterprise users? That would be helpful, or can you just put it behind a Kerberos wrapper? If that would work, collecting a demo, that could unlock more corporate wallets , for investment. - HH On Fri, Oct 27, 2017 at 16:41, henry <henry(a)callistohouse.club> wrote: How is there no steering committee to accumulate wrapping 3rd party libraries in Alien to gain benefits of code in other languages? Do not assume that code is not extremely well written in that particular language for that particular task and that particular deployment mechanism. Can Pharo be called as a shared library from Java JNA? - HH On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglynn42(a)gmail.com> wrote: Iâm not claiming I donât or havenât been affected, only that I no long allow myself to be.Â Does that cause issues?Â Of course.Â But Iâd rather deal with those than do things I donât enjoy.Â However I only got to that point after 26 years in the industry, so I donât expect that everyone will feel that way. Â Cheers Andrew Â Sent from Mail for Windows 10 Â From: jtuchel(a)objektfabrik.de Sent: Thursday, October 26, 2017 8:14 AM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] Smalltalk Argument Â Andrew, Am 26.10.17 um 00:46 schrieb Andrew Glynn: Thereâs other questions that are relevant to me: I am glad you opened your words with this sentence. Other peoplesâ mileages may vary a lot. > 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. Â Some people canât. I canât. I am making my living with a web based application. And I like 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.> So you are in the lucky position that neither mobile nor web nor integration matters to you or you have enough resources to do all that stuff yourself. I am envyous. I need to build web pages and people ask me whether we can ship an iPhone App. I do customer-facing stuff and sex sells much more than we like to think. Your comments on the crappiness of libs in other languages is a great fit for Smalltalk. Not invented here, therefor rubbish. We came a long way with this way of thinking. But these rubbish makers dance circles around us while we try to do our first hello world for an iPad. They laugh at us when we try to reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). Because they are back home and watch Netflix while we debug our homegrown base libraries that are, of course, much better than theirs because they are written in Smalltalk. I am not arguing that maintaining Smalltalk code is far superior to most technolgies out there. But depending on the needs of our projects we have to learn and use those crappy technologies to accomplish what they offer. Because, sometimes (especially if you have to pay bills), an existing library with flaws is better than none. So if I have to use Javascript or C# or Dart or Swift to do the frontend part of my system, is there still much benefit in using these together with Smalltalk? Or is there - at least from a managerâs point of view - not a reasonable amount of sense in choosing the frontend technology also for the logic and compensate the loss in productivity with a gain in avoided complexity? Your answer delivers a lot of food for thought, but I donât buy all of it. And I donât expect you to buy all of mine ;-) Joachim Â Â 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 Â Â â ââââââââââââââââââââââââ 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. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

Btw, I donât need to assume itâs not well written. Iâve both tested it and looked at the code. And in the vast majority of cases, Itâs not. Sent from Mail for Windows 10 From: henry Sent: Friday, October 27, 2017 5:03 PM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Elastic search JSON integration would be another good one. I heard there was a Kafka integration, is that true? Where could I find that, I used to use Kafka. Kafka is a great event channel for input to BigData. Using Kafka, it is well in crafting a Lamda Architecture. Imagine Pharo where Storm resides. - HH On Fri, Oct 27, 2017 at 16:51, henry <henry(a)callistohouse.club> wrote: Â How about Kerberos? Can we get a team to look closely at bringing integration for enterprise users? That would be helpful, or can you just put it behind a Kerberos wrapper? If that would work, collecting a demo, that could unlock more corporate wallets , for investment. - HH On Fri, Oct 27, 2017 at 16:41, henry <henry(a)callistohouse.club> wrote: How is there no steering committee to accumulate wrapping 3rd party libraries in Alien to gain benefits of code in other languages? Do not assume that code is not extremely well written in that particular language for that particular task and that particular deployment mechanism. Can Pharo be called as a shared library from Java JNA? - HH On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglynn42(a)gmail.com> wrote: Iâm not claiming I donât or havenât been affected, only that I no long allow myself to be.Â Does that cause issues?Â Of course.Â But Iâd rather deal with those than do things I donât enjoy.Â However I only got to that point after 26 years in the industry, so I donât expect that everyone will feel that way. Â Cheers Andrew Â Sent from Mail for Windows 10 Â From: jtuchel(a)objektfabrik.de Sent: Thursday, October 26, 2017 8:14 AM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] Smalltalk Argument Â Andrew, Am 26.10.17 um 00:46 schrieb Andrew Glynn: Thereâs other questions that are relevant to me: I am glad you opened your words with this sentence. Other peoplesâ mileages may vary a lot. > 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. Â Some people canât. I canât. I am making my living with a web based application. And I like 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.> So you are in the lucky position that neither mobile nor web nor integration matters to you or you have enough resources to do all that stuff yourself. I am envyous. I need to build web pages and people ask me whether we can ship an iPhone App. I do customer-facing stuff and sex sells much more than we like to think. Your comments on the crappiness of libs in other languages is a great fit for Smalltalk. Not invented here, therefor rubbish. We came a long way with this way of thinking. But these rubbish makers dance circles around us while we try to do our first hello world for an iPad. They laugh at us when we try to reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). Because they are back home and watch Netflix while we debug our homegrown base libraries that are, of course, much better than theirs because they are written in Smalltalk. I am not arguing that maintaining Smalltalk code is far superior to most technolgies out there. But depending on the needs of our projects we have to learn and use those crappy technologies to accomplish what they offer. Because, sometimes (especially if you have to pay bills), an existing library with flaws is better than none. So if I have to use Javascript or C# or Dart or Swift to do the frontend part of my system, is there still much benefit in using these together with Smalltalk? Or is there - at least from a managerâs point of view - not a reasonable amount of sense in choosing the frontend technology also for the logic and compensate the loss in productivity with a gain in avoided complexity? Your answer delivers a lot of food for thought, but I donât buy all of it. And I donât expect you to buy all of mine ;-) Joachim Â Â 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 Â Â â ââââââââââââââââââââââââ 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. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

The Kafka integration is right in the Pharo catalog. Sent from Mail for Windows 10 From: henry Sent: Friday, October 27, 2017 5:03 PM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Elastic search JSON integration would be another good one. I heard there was a Kafka integration, is that true? Where could I find that, I used to use Kafka. Kafka is a great event channel for input to BigData. Using Kafka, it is well in crafting a Lamda Architecture. Imagine Pharo where Storm resides. - HH On Fri, Oct 27, 2017 at 16:51, henry <henry(a)callistohouse.club> wrote: Â How about Kerberos? Can we get a team to look closely at bringing integration for enterprise users? That would be helpful, or can you just put it behind a Kerberos wrapper? If that would work, collecting a demo, that could unlock more corporate wallets , for investment. - HH On Fri, Oct 27, 2017 at 16:41, henry <henry(a)callistohouse.club> wrote: How is there no steering committee to accumulate wrapping 3rd party libraries in Alien to gain benefits of code in other languages? Do not assume that code is not extremely well written in that particular language for that particular task and that particular deployment mechanism. Can Pharo be called as a shared library from Java JNA? - HH On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglynn42(a)gmail.com> wrote: Iâm not claiming I donât or havenât been affected, only that I no long allow myself to be.Â Does that cause issues?Â Of course.Â But Iâd rather deal with those than do things I donât enjoy.Â However I only got to that point after 26 years in the industry, so I donât expect that everyone will feel that way. Â Cheers Andrew Â Sent from Mail for Windows 10 Â From: jtuchel(a)objektfabrik.de Sent: Thursday, October 26, 2017 8:14 AM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] Smalltalk Argument Â Andrew, Am 26.10.17 um 00:46 schrieb Andrew Glynn: Thereâs other questions that are relevant to me: I am glad you opened your words with this sentence. Other peoplesâ mileages may vary a lot. > 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. Â Some people canât. I canât. I am making my living with a web based application. And I like 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.> So you are in the lucky position that neither mobile nor web nor integration matters to you or you have enough resources to do all that stuff yourself. I am envyous. I need to build web pages and people ask me whether we can ship an iPhone App. I do customer-facing stuff and sex sells much more than we like to think. Your comments on the crappiness of libs in other languages is a great fit for Smalltalk. Not invented here, therefor rubbish. We came a long way with this way of thinking. But these rubbish makers dance circles around us while we try to do our first hello world for an iPad. They laugh at us when we try to reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). Because they are back home and watch Netflix while we debug our homegrown base libraries that are, of course, much better than theirs because they are written in Smalltalk. I am not arguing that maintaining Smalltalk code is far superior to most technolgies out there. But depending on the needs of our projects we have to learn and use those crappy technologies to accomplish what they offer. Because, sometimes (especially if you have to pay bills), an existing library with flaws is better than none. So if I have to use Javascript or C# or Dart or Swift to do the frontend part of my system, is there still much benefit in using these together with Smalltalk? Or is there - at least from a managerâs point of view - not a reasonable amount of sense in choosing the frontend technology also for the logic and compensate the loss in productivity with a gain in avoided complexity? Your answer delivers a lot of food for thought, but I donât buy all of it. And I donât expect you to buy all of mine ;-) Joachim Â Â 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 Â Â â ââââââââââââââââââââââââ 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. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

Unfortunately I canât make it available since it was a government project, but I used Pharo to do streaming analytics on XML streams from Cisco ASRâs, and the analyzed data was streamed directly to Hadoop, which was magnitudes faster than Spark, Storm or Kafka, never mind HDB or the PostgreSQL overlay. Sent from Mail for Windows 10 From: henry Sent: Friday, October 27, 2017 5:03 PM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Elastic search JSON integration would be another good one. I heard there was a Kafka integration, is that true? Where could I find that, I used to use Kafka. Kafka is a great event channel for input to BigData. Using Kafka, it is well in crafting a Lamda Architecture. Imagine Pharo where Storm resides. - HH On Fri, Oct 27, 2017 at 16:51, henry <henry(a)callistohouse.club> wrote: Â How about Kerberos? Can we get a team to look closely at bringing integration for enterprise users? That would be helpful, or can you just put it behind a Kerberos wrapper? If that would work, collecting a demo, that could unlock more corporate wallets , for investment. - HH On Fri, Oct 27, 2017 at 16:41, henry <henry(a)callistohouse.club> wrote: How is there no steering committee to accumulate wrapping 3rd party libraries in Alien to gain benefits of code in other languages? Do not assume that code is not extremely well written in that particular language for that particular task and that particular deployment mechanism. Can Pharo be called as a shared library from Java JNA? - HH On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglynn42(a)gmail.com> wrote: Iâm not claiming I donât or havenât been affected, only that I no long allow myself to be.Â Does that cause issues?Â Of course.Â But Iâd rather deal with those than do things I donât enjoy.Â However I only got to that point after 26 years in the industry, so I donât expect that everyone will feel that way. Â Cheers Andrew Â Sent from Mail for Windows 10 Â From: jtuchel(a)objektfabrik.de Sent: Thursday, October 26, 2017 8:14 AM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] Smalltalk Argument Â Andrew, Am 26.10.17 um 00:46 schrieb Andrew Glynn: Thereâs other questions that are relevant to me: I am glad you opened your words with this sentence. Other peoplesâ mileages may vary a lot. > 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. Â Some people canât. I canât. I am making my living with a web based application. And I like 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.> So you are in the lucky position that neither mobile nor web nor integration matters to you or you have enough resources to do all that stuff yourself. I am envyous. I need to build web pages and people ask me whether we can ship an iPhone App. I do customer-facing stuff and sex sells much more than we like to think. Your comments on the crappiness of libs in other languages is a great fit for Smalltalk. Not invented here, therefor rubbish. We came a long way with this way of thinking. But these rubbish makers dance circles around us while we try to do our first hello world for an iPad. They laugh at us when we try to reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). Because they are back home and watch Netflix while we debug our homegrown base libraries that are, of course, much better than theirs because they are written in Smalltalk. I am not arguing that maintaining Smalltalk code is far superior to most technolgies out there. But depending on the needs of our projects we have to learn and use those crappy technologies to accomplish what they offer. Because, sometimes (especially if you have to pay bills), an existing library with flaws is better than none. So if I have to use Javascript or C# or Dart or Swift to do the frontend part of my system, is there still much benefit in using these together with Smalltalk? Or is there - at least from a managerâs point of view - not a reasonable amount of sense in choosing the frontend technology also for the logic and compensate the loss in productivity with a gain in avoided complexity? Your answer delivers a lot of food for thought, but I donât buy all of it. And I donât expect you to buy all of mine ;-) Joachim Â Â 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 Â Â â ââââââââââââââââââââââââ 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. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

And btw, Kafka, like Storm and Spark, is a very limited, and very slow way of accessing Hadoop data stores. Sent from Mail for Windows 10 From: henry Sent: Friday, October 27, 2017 5:03 PM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Elastic search JSON integration would be another good one. I heard there was a Kafka integration, is that true? Where could I find that, I used to use Kafka. Kafka is a great event channel for input to BigData. Using Kafka, it is well in crafting a Lamda Architecture. Imagine Pharo where Storm resides. - HH On Fri, Oct 27, 2017 at 16:51, henry <henry(a)callistohouse.club> wrote: Â How about Kerberos? Can we get a team to look closely at bringing integration for enterprise users? That would be helpful, or can you just put it behind a Kerberos wrapper? If that would work, collecting a demo, that could unlock more corporate wallets , for investment. - HH On Fri, Oct 27, 2017 at 16:41, henry <henry(a)callistohouse.club> wrote: How is there no steering committee to accumulate wrapping 3rd party libraries in Alien to gain benefits of code in other languages? Do not assume that code is not extremely well written in that particular language for that particular task and that particular deployment mechanism. Can Pharo be called as a shared library from Java JNA? - HH On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglynn42(a)gmail.com> wrote: Iâm not claiming I donât or havenât been affected, only that I no long allow myself to be.Â Does that cause issues?Â Of course.Â But Iâd rather deal with those than do things I donât enjoy.Â However I only got to that point after 26 years in the industry, so I donât expect that everyone will feel that way. Â Cheers Andrew Â Sent from Mail for Windows 10 Â From: jtuchel(a)objektfabrik.de Sent: Thursday, October 26, 2017 8:14 AM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] Smalltalk Argument Â Andrew, Am 26.10.17 um 00:46 schrieb Andrew Glynn: Thereâs other questions that are relevant to me: I am glad you opened your words with this sentence. Other peoplesâ mileages may vary a lot. > 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. Â Some people canât. I canât. I am making my living with a web based application. And I like 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.> So you are in the lucky position that neither mobile nor web nor integration matters to you or you have enough resources to do all that stuff yourself. I am envyous. I need to build web pages and people ask me whether we can ship an iPhone App. I do customer-facing stuff and sex sells much more than we like to think. Your comments on the crappiness of libs in other languages is a great fit for Smalltalk. Not invented here, therefor rubbish. We came a long way with this way of thinking. But these rubbish makers dance circles around us while we try to do our first hello world for an iPad. They laugh at us when we try to reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). Because they are back home and watch Netflix while we debug our homegrown base libraries that are, of course, much better than theirs because they are written in Smalltalk. I am not arguing that maintaining Smalltalk code is far superior to most technolgies out there. But depending on the needs of our projects we have to learn and use those crappy technologies to accomplish what they offer. Because, sometimes (especially if you have to pay bills), an existing library with flaws is better than none. So if I have to use Javascript or C# or Dart or Swift to do the frontend part of my system, is there still much benefit in using these together with Smalltalk? Or is there - at least from a managerâs point of view - not a reasonable amount of sense in choosing the frontend technology also for the logic and compensate the loss in productivity with a gain in avoided complexity? Your answer delivers a lot of food for thought, but I donât buy all of it. And I donât expect you to buy all of mine ;-) Joachim Â Â 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 Â Â â ââââââââââââââââââââââââ 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. 28, 2017