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

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

An easy way of accomplishing what you want is to use Stamp to communicate with Synapse. It also has the advantage of being able to throttle queries that are too fast for the JVM to process. Iâve used precisely that method a number of times to connect to Hadoop. 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

F-Script screenshots I promised. Look familiar to anyone? Sent from Mail for Windows 10 From: henry Sent: Friday, October 27, 2017 9:50 AM To: philippe.back(a)highoctane.be; Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument I confuse easily, as you say freeipa works wonderfully well, then point out sun support to the api is hidden and itâs tricky to use. Do you mean Hadoopâs use is iffy? If freeipa works wonderfully can we find the right api and sequence of calls, building our own model in image side? Then that model we compute on and it makes the right calls. Modeling is our strength, I have always thought. What is achievable? This would benefit ParrotTalk I think. - HH On Thu, Oct 26, 2017 at 16:28, philippe.back(a)highoctane.be <philippe.back(a)gmail.com> wrote: 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 Oct 26, 2017 18:23, "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

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. You can see the results in REST / ROA. Neither could work at all without the underlying stateful, complex (in terms of behavior), and very well written code that runs DNS, the main registrars, TCP/IP itself (which is not, like REST, a very limited protocol turned into an interface), etc. One hilarious aspect of REST is that, due to being HTTP redone, it continues to have the POST method, which happens to contradict ROA completely, yet they were defined together by the same person. Sent from Mail for Windows 10 From: Dimitris Chloupis Sent: Thursday, October 26, 2017 8:54 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Well all languages have well designed and badly designed libraries , in Pharo you dont even have to look hard just take a look at Morph and Object class and awe at all those irrelevant methods trying to cram in features you will probably never use. Especially my experience with Morphic has been as nightmarish as my experience with MFC. And MFC is a C++ library and made by Microsoft. On the other hand QT is a brilliantly designed GUI API (again for C++) and dont even get me started on DELPHI libraries which to this day I consider top when it comes to OO libraries. together with its IDE (but I never liked its language).Â Web dev may be a messy field mainly because it has grown too fast, after the web explosion ,Â based on problematic concepts but desktop libraries and as a consequence mobile dev libraries (iOS is a variable of MacoOS, Android a variant of Linux) in a much , much better position and some of them have stellar designs. Mainly because are far more mature with decades of extremely active development. Of course many of those great design are the result of a reaction to bad designs and lessons learned from other APIs. There is no good design without a redesign.Â 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.Â Â Â On Thu, Oct 26, 2017 at 3:14 PM jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: 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] Enterprise authentication with Kerberos (was Re: Smalltalk Argument)

by Ben Coman

> On Thu, Oct 26, 2017 at 3:14 PM, 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. > > > On Thu, Oct 26, 2017 at 9:15 PM, henry <henry(a)callistohouse.club> wrote: >> >> Of the 4 types of integration, I vote for and step forward to volunteer to help Kerberos integration in Pharo. What to do? > > > On Thu, Oct 26, 2017 at 11:39 PM, 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 Fri, Oct 27, 2017 at 6:06 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >> >> 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.. >> >> >> 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. > > > On Sat, Oct 28, 2017 at 4:51 AM, 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. >> >> I'm not very familiar with the domain, but maybe we should consider GSSAPI & SSPI. "The dominant GSSAPI mechanism implementation in use is Kerberos. Unlike the GSSAPI, the Kerberos API has not been standardized and various existing implementations use incompatible APIs. The GSSAPI allows Kerberos implementations to be API compatible." [1] "SSPI is a proprietary variant of GSSAPI with extensions and very Windows-specific data types" [2] SSPI/Kerberos Interoperability with GSSAPI https://msdn.microsoft.com/en-us/library/ms995352.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa380496(v=vs.85).… [1] https://en.wikipedia.org/wiki/Generic_Security_Services_Application_Program… [2] https://en.wikipedia.org/wiki/Security_Support_Provider_Interface cheers -ben

Oct. 28, 2017

Enterprise authentication with Kerberos (was Re: Smalltalk Argument)

by Ben Coman

Kerberos deserves its own topic rather than mixing in with the Smalltalk Argument one that now stands at 53 posts. Hopefully I've managed to extract pertinent parts of this thread. On Thu, Oct 26, 2017 at 3:14 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Sure. Current main issue is to have Pharo work with Kerberos as secured > Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole > of crypto things. > > How would you see ParrotTalk work? > > I made a XmppTalk thing (binding for libstrophe) for having Pharo images > and other stuff talk together (currently using OpenFire/Gajim/Profanity) > FWIW > > See https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tm > uxyZz1UaX5ikEU/edit?usp=sharing > > libstrophe does the SSL thing under the hood (using OpenSSL) and is > actively maintained. > https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c > > And I currently work with Kafka so, Pharo as a consumer or producer, sure > am interested. But need Kerberos support. > > Tell me more about your vision. Even better, draw it in some way :-) > > Phil > On Thu, Oct 26, 2017 at 8:52 PM, henry <henry(a)callistohouse.club> wrote: > 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 9:15 PM, 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? > > On Thu, Oct 26, 2017 at 10:38 PM, henry <henry(a)callistohouse.club> wrote: > A Kerberos effort will have to be a group effort. Sideways to my main > focus and your allâs main focii. On Thu, Oct 26, 2017 at 11:39 PM, 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 Fri, Oct 27, 2017 at 6:06 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > 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. > > On Sat, Oct 28, 2017 at 4:51 AM, 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 >

Oct. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Ben Coman

On Sat, Oct 28, 2017 at 8: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. > It would be really interesting to see a blog post and/or video of working like this with OS level objects. Also its something that might capture the curiosity of hackers outside the Pharo community. cheers -ben

Oct. 28, 2017

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

One point: ânot invented hereâ, though related to my notion of âbuilding on rather than building withâ, is not exactly the same. There are instances where itâs valid, unfortunately that helps to give the impression that invalid but related ideas are also valid. Cisco for instance is an extreme of ânot invented hereâ. In terms of designing an ASR-9010, thatâs valid, in terms of building their own website, not so much. As a metaphor, consider the difference between hand built, perhaps small relative volume, but still mass produced cars, such as Jaguar pre-Fordâs buyout, and truly small volume niche cars, such as Lamborghiniâs. Jaguars simply gained a rep for being unreliable and very difficult to work on, and the company nearly went out of business. Lamborghini on the other hand has a multi-year waiting list to buy their cars, despite the enormous cost, and that you have to pay that cost just to get on the waiting list. Progressing to more complex and more crucial systems, would you want the Defense Automation System in the F-35 written in JavaScript? To make the reasoning more obvious - that system automatically uses every available weapon on the plane to defend itself without pilot involvement, and can even take over control in order to perform evasive actions beyond the capabilities of most human pilots. In turn, the above implies that on the sub-millisecond level, it has to be able to distinguish between enemy and friendly objects, via nothing but 15 x 3-part sensors. If it seems a little dicey in any system, how would you want to implement it in JavaScript, or GO, or any number of other recent languages? And what libraries would you trust in terms of implementing it in any language? 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

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] Smalltalk Argument

by Andrew Glynn

Your points are, as usual, very accurate. However the percentage of rarely used methods in JavaEE makes those in Morphic look nearly irrelevant. The more important question for me is whether they interfere or not. Sent from Mail for Windows 10 From: Dimitris Chloupis Sent: Thursday, October 26, 2017 8:54 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Well all languages have well designed and badly designed libraries , in Pharo you dont even have to look hard just take a look at Morph and Object class and awe at all those irrelevant methods trying to cram in features you will probably never use. Especially my experience with Morphic has been as nightmarish as my experience with MFC. And MFC is a C++ library and made by Microsoft. On the other hand QT is a brilliantly designed GUI API (again for C++) and dont even get me started on DELPHI libraries which to this day I consider top when it comes to OO libraries. together with its IDE (but I never liked its language).Â Web dev may be a messy field mainly because it has grown too fast, after the web explosion ,Â based on problematic concepts but desktop libraries and as a consequence mobile dev libraries (iOS is a variable of MacoOS, Android a variant of Linux) in a much , much better position and some of them have stellar designs. Mainly because are far more mature with decades of extremely active development. Of course many of those great design are the result of a reaction to bad designs and lessons learned from other APIs. There is no good design without a redesign.Â 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.Â Â Â On Thu, Oct 26, 2017 at 3:14 PM jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: 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âve never needed or seen any reason to implement MVC on Seaside, since it has a superior model to begin with. It would seem to me like implementing Vert.x over JINI, rather than the inverse. Iâm curious though why you see a need to do so, i.e. what requirements youâre being given that make it necessary. 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. 27, 2017

[ANN] Grafoscopio is now also an indexed publication

by Offray Vladimir Luna CÃ¡rdenas

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. 27, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

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]("mailto:henry@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](""mailto:henry@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](""mailto:aglynn42@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](""https://go.microsoft.com/fwlink/?LinkId=550986"") for Windows 10 >>> >>> From: [jtuchel(a)objektfabrik.de](""mailto:jtuchel@objektfabrik.de"") >>> Sent: Thursday, October 26, 2017 8:14 AM >>> To: [pharo-users(a)lists.pharo.org](""mailto:pharo-users@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>](""mailto:pharo-users-bounces@lists.pharo.org"") on behalf of David Mason [<dmason(a)ryerson.ca>](""mailto:dmason@ryerson.ca"") >>>> Reply-To: Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](""mailto:pharo-users@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>](""mailto:pharo-users@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](""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](""mailto:jtuchel@objektfabrik.de"") <[jtuchel(a)objektfabrik.de](""mailto:jtuchel@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](""mailto:jtuchel@objektfabrik.de"") >>>>> Fliederweg 1 [http://www.objektfabrik.de](""http://www.objektfabrik.de"") >>>>> D-71640 Ludwigsburg [http://joachimtuchel.wordpress.com](""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"") >>> >>> â >>> >>> ââââââââââââââââââââââââ >>> >>> Objektfabrik Joachim Tuchel >>> [mailto:jtuchel@objektfabrik.de](""mailto:jtuchel@objektfabrik.de"") >>> >>> Fliederweg 1 >>> [http://www.objektfabrik.de](""http://www.objektfabrik.de"") >>> >>> D-71640 Ludwigsburg >>> [http://joachimtuchel.wordpress.com](""http://joachimtuchel.wordpress.com"") >>> >>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Oct. 27, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

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]("mailto:henry@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]("mailto:aglynn42@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]("https://go.microsoft.com/fwlink/?LinkId=550986") for Windows 10 >> >> From: [jtuchel(a)objektfabrik.de]("mailto:jtuchel@objektfabrik.de") >> Sent: Thursday, October 26, 2017 8:14 AM >> To: [pharo-users(a)lists.pharo.org]("mailto:pharo-users@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>]("mailto:pharo-users-bounces@lists.pharo.org") on behalf of David Mason [<dmason(a)ryerson.ca>]("mailto:dmason@ryerson.ca") >>> Reply-To: Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>]("mailto:pharo-users@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>]("mailto:pharo-users@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]("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]("mailto:jtuchel@objektfabrik.de") <[jtuchel(a)objektfabrik.de]("mailto:jtuchel@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]("mailto:jtuchel@objektfabrik.de") >>>> Fliederweg 1 [http://www.objektfabrik.de]("http://www.objektfabrik.de") >>>> D-71640 Ludwigsburg [http://joachimtuchel.wordpress.com]("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") >> >> â >> >> ââââââââââââââââââââââââ >> >> Objektfabrik Joachim Tuchel >> [mailto:jtuchel@objektfabrik.de]("mailto:jtuchel@objektfabrik.de") >> >> Fliederweg 1 >> [http://www.objektfabrik.de]("http://www.objektfabrik.de") >> >> D-71640 Ludwigsburg >> [http://joachimtuchel.wordpress.com]("http://joachimtuchel.wordpress.com") >> >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Oct. 27, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

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](https://go.microsoft.com/fwlink/?LinkId=550986) 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>](mailto:pharo-users-bounces@lists.pharo.org) on behalf of David Mason [<dmason(a)ryerson.ca>](mailto:dmason@ryerson.ca) >> Reply-To: Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](mailto:pharo-users@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>](mailto:pharo-users@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) > > -- > > ----------------------------------------------------------------------- > > 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. 27, 2017

Re: [Pharo-users] Teapot and Websockets

by Hans

Attila Magyar wrote > Teapot already supports conditional routes, maybe using them instead of > adding the WS: message would be better. > > I'm thinking domething like: > > Teapot on > GET: '/chat' -> whatever; when: [:req | req isWebSocket]; > start. > > or just > > Teapot on > GET: '/chat' -> whatever; when: #isWebSocket > start. > > I'll play with this idea sometime. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html I've played a little bit with this: GET: '/chat' -> [:req | Teapot forward: aReq toWebSocket: '/chat' ]; when: ... The class method of Teapot does the "ZnWebSocketDelegate map: ... to... " thing. It could handle the instances of the delegate per url. Don't know it this matches the Teapot philosophy, it was just another variant to play with. Cheers Hans -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 27, 2017

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

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. 27, 2017

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

by Offray Vladimir Luna CÃ¡rdenas

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. 27, 2017

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

by Sebastian Heidbrink

Hi Offray! 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. Is you phd thesis public? I tried to explore software ecosystems in the context of methiation theory by Peter-Paul Verbeek, but I was not able to design an applied mater thesis based on such philosopical theory. This is why the modeling of ecosystems services is a new broad scope that I will have to narrow down during the next quater. Sebastian Am 27.10.2017 um 11:01 schrieb Offray Vladimir Luna CÃ¡rdenas: > Hi, > > > On 27/10/17 10:48, Sebastian Heidbrink via Pharo-users wrote: >> While the ambitions behind GT seem to be developer centric, I wonder >> if there is also research or development done to support non-developer >> pharo users. > Yes. We're trying to bridge the gap between developers and > non-developers (like myself) using moldable environments like Pharo. Our > use case is data activism, visualization and storytelling. So our > intended users are people coming from any of such fields that don't > develop app, but try to tell factual stories supported by data and/or > visualizations. For that I have developed the Grafoscopio[1] tool and > the Data Week workshop+hackathon [2], were we approach the gap between > devs and other users from the point of critical data & software literacy > (pretty far away from the "Hello World" introduction to programming[3]). > > [1] http://mutabit.com/grafoscopio/index.en.html > [2] http://mutabit.com/dataweek/ > [3] http://mutabit.com/offray/blog/en/entry/dumb-hello-world > > Pharo, agile visualization and moldable tools have allowed me to explore > my PhD question about "How we can change the digital tools that change > us?" from this critical approach to data/tech, tools and literacy > for/from activism. > > Cheers, > > Offray > > >

Oct. 27, 2017

Re: [Pharo-users] UFFI and Fortran

by Dimitris Chloupis

Maybe you talk about TalkFFI which aumatically wrapped C libraries for Pharo and i think Squeak as well but used Nativeboos, i think http://forum.world.st/TalkFFI-automatic-FFI-generation-for-Pharo-td4662239.… On the subject of Fortran yes you can use UFFI if Fortran code is compiled as a DLL (or equivelant non Windoom OSes) https://software.intel.com/en-us/node/535305 Dynamic Library format are not exclusive to C for generation , many languages can generate them so even though UFFI is used predominatly for C any language that can generate a DLL without any name mangling should be accessible via UFFI. if DLL generation is not possible, then you can drop down to my solution of Shared Memory Mapped Files. Which means you make an executable in Frotran (or any other language) that contains the code you want to access and creates a shared memory region and you can access that region from Pharo via UFFI. This is how I built my CPPBridge project. Which one can use as a template for generating similar bridge for Fortran or any other language where the generation of DLLs is not practical or possible. The shared memory region can be used also as a means of communication additional to sharing live state, memory mapped files automatically save the live state so next time you open the file it behaves as you would expect a Pharo image to behave by restoring the live state. A means to extend Pharo image to include memory not managed by the VM. Because memory mapped files is mechanism of the OS Kernel and is also the mechanism used for the loading of dynamic libraries like DLLs there is also no loss of performance and is the fastest way of communication between languages, libraries and applications. So yes using Fortran code is possible via UFFI in more than one way. But in the end it should be noted here that because IPC mechanisms (common way of using libraries from other languages) are based on core OS functionality like , memory managment, sockets , pipes, etc its not hard to use libraries from any language from inside any language. So Pharo can use Fortran libraries and Fortran can use Pharo libraries, its also possible to retain live coding even when executing code written in another language through various means. Recently I was succesful in making Python into a basic live coding enviroment , meaning code that when changed in the source file it updates also existing live intances as you expect in Pharo. Python also supports memory mapped files so its possible to create a joined live coding enviroment and live image that containes both Pharo and Python bytecode. Of course without touching VM source code. Even though live state is not tricky to retain for compiled languages, live code can be a bit trickier to do but still not impossible or that hard as most would assume. Sky is the limit. Bottom line is that if you have a favorite library in any language you can use it from inside Pharo with at worst a few hundrend lines of setup code you can create as a library and of coure reuse next time you want to use again a library from another language without having to write a line of additional code. The technology is available is just a matter of learning how to use it. Especially if its a very large libraries it will be thousands times easier than trying to replicate the functionality in Pharo. On Fri, Oct 27, 2017 at 6:26 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Ben Coman wrote > > it seems to hint how to do it from Pharo UFFI. > > Slightly OT: I remember years ago, someone (Dave Mason?) demoed a library > which automatically created FFI wrappers for C libs. I never heard anything > about it after that, which is sad, because I was amazed and wanted to use > it! > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 27, 2017

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

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 27/10/17 10:48, Sebastian Heidbrink via Pharo-users wrote: > While the ambitions behind GT seem to be developer centric, I wonder > if there is also research or development done to support non-developer > pharo users. Yes. We're trying to bridge the gap between developers and non-developers (like myself) using moldable environments like Pharo. Our use case is data activism, visualization and storytelling. So our intended users are people coming from any of such fields that don't develop app, but try to tell factual stories supported by data and/or visualizations. For that I have developed the Grafoscopio[1] tool and the Data Week workshop+hackathon [2], were we approach the gap between devs and other users from the point of critical data & software literacy (pretty far away from the "Hello World" introduction to programming[3]). [1] http://mutabit.com/grafoscopio/index.en.html [2] http://mutabit.com/dataweek/ [3] http://mutabit.com/offray/blog/en/entry/dumb-hello-world Pharo, agile visualization and moldable tools have allowed me to explore my PhD question about "How we can change the digital tools that change us?" from this critical approach to data/tech, tools and literacy for/from activism. Cheers, Offray

Oct. 27, 2017

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

by Stephane Ducasse

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. 27, 2017

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

by Stephane Ducasse

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. 27, 2017

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

by Stephane Ducasse

Cedric This code should be a bit documented. If you have some tests I would be interested And we should add tests to the repo. 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. 27, 2017

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

by Tim Mackinnon

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. 27, 2017

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

by Paul DeBruicker

there is a History package Esteban Maringolo developed here: http://smalltalkhub.com/#!/~emaringolo/History It stores objects at times and allows fast-ish point in time based lookups. Maybe they're similar in purpose/function. CÃ©drick BÃ©ler 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 Ã©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 Ã©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 >>> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 27, 2017

[GT] moldable tools for non-developers

by Sebastian Heidbrink

Hi all! There is this strong movement within Pharo now, that allows developers to expand the individual development process with the help of moldable dev tools based on GlamourToolkit (GT). This allows for a much more effective communication between stakeholders and developers resulting in a more cost effective development. While the ambitions behind GT seem to be developer centric, I wonder if there is also research or development done to support non-developer pharo users. Are there projects that try to integrate/interface "modeling" into/with GT? (e.g. likeÂ STELLA [1]) I am also wondering if aspect oriented programming could help closing the full cycle of an adaptive development/management process. Anybody researching on something like this? Thank you for any hint! Sebastian [1] https://www.iseesystems.com/

Oct. 27, 2017

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

by Sean P. DeNigris

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. 27, 2017

Re: [Pharo-users] UFFI and Fortran

by Sean P. DeNigris

Ben Coman wrote > it seems to hint how to do it from Pharo UFFI. Slightly OT: I remember years ago, someone (Dave Mason?) demoed a library which automatically created FFI wrappers for C libs. I never heard anything about it after that, which is sad, because I was amazed and wanted to use it! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 27, 2017

Re: [Pharo-users] QCMagritte on Github

by laurent laffont

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. 27, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

I confuse easily, as you say freeipa works wonderfully well, then point out sun support to the api is hidden and itâs tricky to use. Do you mean Hadoopâs use is iffy? If freeipa works wonderfully can we find the right api and sequence of calls, building our own model in image side? Then that model we compute on and it makes the right calls. Modeling is our strength, I have always thought. What is achievable? This would benefit ParrotTalk I think. - HH On Thu, Oct 26, 2017 at 16:28, philippe.back(a)highoctane.be <philippe.back(a)gmail.com> wrote: > 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 Oct 26, 2017 18:23, "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. >>>>>> >>>>>> [""hubbub.jpg""] >>>>>> >>>>>> - HH >>>>>> >>>>>>> âââ Original Message âââ >>>>>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>>>>> Local Time: October 26, 2017 8:52 AM >>>>>>> UTC Time: October 26, 2017 12:52 PM >>>>>>> From: henry(a)callistohouse.club >>>>>>> To: phil(a)highoctane.be [<phil(a)highoctane.be>](mailto:phil@highoctane.be), Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](mailto:pharo-users@lists.pharo.org) >>>>>>> >>>>>>> Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer. >>>>>>> >>>>>>> I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. >>>>>>> >>>>>>> Please see the attached diagram, co-locating ParrotTalk with my other components. >>>>>>> >>>>>>> ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData. >>>>>>> >>>>>>> This means you still need a Kerberos client and I need a Kerberos client. How do we start? >>>>>>> >>>>>>> - HH >>>>>>> >>>>>>> PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs. >>>>>>> >>>>>>> On Thu, Oct 26, 2017 at 03:14, phil(a)highoctane.be <phil(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. 27, 2017

Netstyle/Workflow Package discovery - (was: Business process (declaration and orchestration), ontology/taxonomy)

by CÃ©drick BÃ©ler

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. 27, 2017

Re: [Pharo-users] QCMagritte on Github

by HernÃ¡n Morales Durand

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. 27, 2017

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

by Steffen MÃ¤rcker

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. 27, 2017

UK Smalltalk User Group Meeting - Monday, October 30th - PharoLambda: Smalltalk running serverless on AWS

by Tim Mackinnon

The next meeting of the UK Smalltalk User Group Meeting will be on Monday, 30th October. We'll meet at The City Pride, London ( http://www.cityprideclerkenwell.co.uk/ <http://www.cityprideclerkenwell.co.uk/> ) at 7pm. Tim Mackinnon will show how recent Pharo advances with a small footprint 64bit image allow for Smalltalk to run happily on AWS Lambda and power things like an Alexa skill. While serverless architecture is interesting in its own right, the neat twist is using standard Smalltalk tooling to "~live" debug a failed execution and step through a post mortem stack. We will take a peak at the GitLab CI setup to deploy an Alexa application, look at how a simple lambda function can be hooked up and then discuss how we might leverage other Smalltalk strengths in a serverless world. If you'd like to join us, you can just show up at the pub. You can also sign up in advance at the meeting's Meetup page: https://www.meetup.com/UKSTUG/events/244451089/ <https://www.meetup.com/UKSTUG/events/244451089/>. See you there!

Oct. 27, 2017

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo Consortium New Platinum Member: JPMorgan Chase

by Ben Coman

Wow! Thats three new platinum announcements in as many days. Great work guys. For me this is not just about the money it brings in for additional engineering resources to improve Pharo Its the implicit endorsement of the future value these companies expect to gain from Pharo, and of the open-source consortium model. Thank you to those that had the vision in the early years to create and support the consortium. The future looks bright for me to keep hacking on my favourite programming environment. cheers -ben On Thu, Oct 26, 2017 at 2:45 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > The Pharo Consortium is very happy to announce that JPMorgan Chase > has joined the Consortium as a Platinum Member. > > About > - JPMorgan Chase: https://www.jpmorganchase.com > - Pharo Consortium: http://consortium.pharo.org > > The goal of the Pharo Consortium is to allow companies and institutions to > support the ongoing development and future of Pharo. > > Individuals can support Pharo via the Pharo Association: > > - http://association.pharo.org > >

Oct. 27, 2017

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

by CÃ©drick BÃ©ler

> > Existing implementations out there seems to uses whatever nodes on the network to replicate the information. > > Yes, because that makes them decentralized :) Yes :) But couldn't we limit the decentralized networks to some nodes (my node + nodes of persons/organization I trust) + eventually node they trusts. I have the feeling that limiting the networks would simplify the implementation cost as the underlying cryptographic system (I have a very naive understanding of such systems but I know I need them to sign/crypt information). I have no idea of a minimal node number that is acceptable to do content addressing. > > > Iâd like to control nodes where it is replicated. My nodes (all my app instances + nodes of person Iâm exchanging information with + eventually friend of friend). > > We've done recent work on capability-based content adressing, but, first it's very slow (so you use a two level cryptosystem: the crypted header contains the key to decrypt the content, and the crypted header can only be decrypted if your private key has the right level of capabilities on the data item. Interesting ! I need to get more knowledge on that. BTW, I found these introduction courses well done on cryptography in information theory (https://khanacademy.org/computing/computer-science <https://khanacademy.org/computing/computer-science>) Just thinking loud: I donât actually need a quick implementation as the default is to have not synced version that get synchronized on opportunistic connection. What if each node has by default private keys and all public key of the external node I have relation with ? Wouldnât it be simpler ? To prototype stuff, I think I can consider naive crypto and even do symmetric cryptography (and use Cryptography package or NaCL binding). I think Iâll do a very naive approach to sign and encrypt. If you know some existing applications that could help, please, let me know. > > > What hash function would you use ? > > Anything that is fast, bonus points if it uses CPU special instructions (that you can't use from Pharo, of course ;)), and has the right cryptographic properties. Unless you go into a specific cryptosystem, I'd say that it is not important. :) ok > > > To get something compatible with ipfs, Iâd need something like: https://github.com/multiformats/multihash <https://github.com/multiformats/multihash> > It looks to me quite universal as self describing. But any (existing) hash method compatible with content hashing would do the job. > > Interesting, but it looks like a minor issue in the overall scheme. Makes some of your system robust to evolution in the hash used, but, since first bytes are not well distributed, can you use it safely to build a multi-hash function system? Probably not. Yes I agree. One idea was to use only ipfs for public information shared with everybody (even outside of nodes I have relation with). Clearly, not a central point. > > > >> I wouldn't be against a slightly higher granularity when dealing with object transfers, however. > > You mean at the pharo level ? Higher granularity means having more control on the exchange/merge ? > > No, just that the content-based address scheme is costly... and that a practical implementation would probably look to provide addresses only to large enough entities (a page containing objects, for example, or a large objects containing smaller ones). So that you donc create an address for each character of the string object describing the name of a person, say). Oh ok. I think this is how I was seeing itâ¦ says I exchange my phone number with somebody, the content hashed would be the full information (full content + version number + (maybe) its model hash + its geolocalized timestamp). Thanks a lot for the exchange, CÃ©drick > > Regards, > > Thierry > > > Cheers, > > CÃ©drick >

Oct. 27, 2017

QCMagritte on Github

by laurent laffont

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. 27, 2017

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

by Thierry Goubier

2017-10-27 11:28 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: > > Hi Cedric, > > a short answer: some of what you're trying to do has been traditionnally > handled by object databases - multiple images retrieving and updating > objects on a central store ensuring lots of good properties : see Gemstone. > > > Yes , Iâd like to avoid this centralized approach. > I mean that they have already some of the mechanisms in place, even if centralized. > > > Another answer, since you're looking at content-addressable distributed > file systems. You can resolve the offline mode with object duplications > (duplicate all objects in the images using them), and, when coming back > online, have a merge approach to reconcile changes between versions of > shared objects. Content-based hashes as identifiers in a distributed store > have very nice properties for that purpose, because, if image C has > modified object 0xcdaff3, then that object has in fact become object > 0xee345d for that image (and the unmodified object is still 0xcdaff3 for > images A and B). > > > You nailed it. This is what Iâd like to reproduce. > > Existing implementations out there seems to uses whatever nodes on the > network to replicate the information. > Yes, because that makes them decentralized :) > > Iâd like to control nodes where it is replicated. My nodes (all my app > instances + nodes of person Iâm exchanging information with + eventually > friend of friend). > We've done recent work on capability-based content adressing, but, first it's very slow (so you use a two level cryptosystem: the crypted header contains the key to decrypt the content, and the crypted header can only be decrypted if your private key has the right level of capabilities on the data item. > > What hash function would you use ? > Anything that is fast, bonus points if it uses CPU special instructions (that you can't use from Pharo, of course ;)), and has the right cryptographic properties. Unless you go into a specific cryptosystem, I'd say that it is not important. > > To get something compatible with ipfs, Iâd need something like: > https://github.com/multiformats/multihash > It looks to me quite universal as self describing. But any (existing) hash > method compatible with content hashing would do the job. > Interesting, but it looks like a minor issue in the overall scheme. Makes some of your system robust to evolution in the hash used, but, since first bytes are not well distributed, can you use it safely to build a multi-hash function system? Probably not. > > > I wouldn't be against a slightly higher granularity when dealing with > object transfers, however. > > > You mean at the pharo level ? Higher granularity means having more control > on the exchange/merge ? > No, just that the content-based address scheme is costly... and that a practical implementation would probably look to provide addresses only to large enough entities (a page containing objects, for example, or a large objects containing smaller ones). So that you donc create an address for each character of the string object describing the name of a person, say). Regards, Thierry > > Cheers, > > CÃ©drick >

Oct. 27, 2017

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

by Norbert Hartl

Super! Thanks for that! Norbert > Am 27.10.2017 um 11:36 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > 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. 27, 2017

[ANN] Iceberg 0.6.2 backported to Pharo 6.1

by Esteban Lorenzano

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. 27, 2017

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

by CÃ©drick BÃ©ler

> > Hi Cedric, > > a short answer: some of what you're trying to do has been traditionnally handled by object databases - multiple images retrieving and updating objects on a central store ensuring lots of good properties : see Gemstone. Yes , Iâd like to avoid this centralized approach. > > Another answer, since you're looking at content-addressable distributed file systems. You can resolve the offline mode with object duplications (duplicate all objects in the images using them), and, when coming back online, have a merge approach to reconcile changes between versions of shared objects. Content-based hashes as identifiers in a distributed store have very nice properties for that purpose, because, if image C has modified object 0xcdaff3, then that object has in fact become object 0xee345d for that image (and the unmodified object is still 0xcdaff3 for images A and B). You nailed it. This is what Iâd like to reproduce. Existing implementations out there seems to uses whatever nodes on the network to replicate the information. Iâd like to control nodes where it is replicated. My nodes (all my app instances + nodes of person Iâm exchanging information with + eventually friend of friend). What hash function would you use ? To get something compatible with ipfs, Iâd need something like: https://github.com/multiformats/multihash <https://github.com/multiformats/multihash> It looks to me quite universal as self describing. But any (existing) hash method compatible with content hashing would do the job. > I wouldn't be against a slightly higher granularity when dealing with object transfers, however. You mean at the pharo level ? Higher granularity means having more control on the exchange/merge ? Cheers, CÃ©drick

Oct. 27, 2017

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

by Thierry Goubier

Hi Cedric, a short answer: some of what you're trying to do has been traditionnally handled by object databases - multiple images retrieving and updating objects on a central store ensuring lots of good properties : see Gemstone. Another answer, since you're looking at content-addressable distributed file systems. You can resolve the offline mode with object duplications (duplicate all objects in the images using them), and, when coming back online, have a merge approach to reconcile changes between versions of shared objects. Content-based hashes as identifiers in a distributed store have very nice properties for that purpose, because, if image C has modified object 0xcdaff3, then that object has in fact become object 0xee345d for that image (and the unmodified object is still 0xcdaff3 for images A and B). I wouldn't be against a slightly higher granularity when dealing with object transfers, however. Regards, Thierry 2017-10-27 10:43 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: > > Nothing complex about two images exchanging messages, its not even complex > to transmit objects via fuel, you even transmit a debugger or any part of > the live environment or even make an "internet" of images that join objects > together. Sky is the limit. Pharo already provides you will all the > tools/libraries to do this. > > > Yes. Thatâs why I asked for better practices. > > > A streamsocket (not to be confused with regular sockets) will delay the > messages (a collection of bytes) until they arrive to the receiver or until > they have reached the timeout period. Offline mode is pretty much > obligatory even for plain old internet web apps because of drops in > connection or the plain fact a connection can become slow. > > > Offline mode is to me of first importance. > > Letâs say I have a sets of Pharo app (nodes). > Each one are independent running on different devices/computers. > > I want to exchange information between them according to some kind of > contracts and also on connection availability. > > What I find different from usual message exchanges between two images is > that I want to have full control on it. Plus I consider images offline by > default (meaning two images have different versions of the same info). So > conflict is the norm. > > Also, I donât want to send message remotely (with behavior), I just want > to send/share an information and sync them (when possible). > > Connection between 2 images can be through a network but eventually > through a serial connection (usb cable, Bluetooth,...). > > So what I try to do as a proto is having connection controlled by my apps > (I put the app offline (not by switching off wifi but by switching > logically). I can see nodes availability and activate connexion manually > then see if conflict resolution is ok, + I log every connecitions changes > and exchanges). This is my plans for now but it may change ! ^^ > > > I used streamsockets in my Pharo to Python bridge (Atlas) because the > execution was not necessary synchronous , I was sending Python command to a > 3d application from Pharo and I had to make sure that the bridge was > working even in the case of a command that could take hours to execute like > a rendering process. > > > Iâll look at stream sockets and mq stuffs. > > > Cheers, > > CÃ©drick > > > One cool trick I did was to send the Python errors back to Pharo and > trigger them as Pharo's regular MessageNotUnderstood , this is a nice way > to make sure that you can fix a wrong message after it has been executing > without going to the image that is executing it. > > The limitation with sockets which what every frameworks uses because AFAIK > they are the only means to communicate remotely is that they are not top > performance so that mean that you can send long loops but executing > communication inside long loops will either slow you down considerably or > simply timeout your socket. Sockets can timeout from both ends if they feel > that for some reason they lost communication with the other side and > reached their timeout period. Timeout period is customization. > > This is a problem I did not tackle with my implementation because I dont > think there can be an actual practical solution better than avoiding this > scenario. > > Only shared memory seems to overcome this but it can be used only locally > and not remotely (aka on same computer) . > > On Wed, Oct 25, 2017 at 4:41 PM CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > >> I had a look and this is not (natively) possible. >> >> The idea of the off-line mode would be to delay messages that are sent to >> the peer until a connection is established. >> >> I think I have to try to do it by myself (like having a list of >> information exchange that wait until a connexion is established). >> >> What I try to do is not as complex as two general image exchanging >> messages on objects (like on TelePharo). >> >> I just want a repository of information (mainly a collection of static >> information/data versions) on both peers to be synchronized when a >> connection is established. >> >> >> >> >> >> Le 25 oct. 2017 Ã 15:31, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit >> : >> >> What is offline mode? >> >> 2017-10-25 15:10 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: >> >>> Thanks Denis. I will ! I knew I have seen a telephoto component that >>> could help but forgot about it ! >>> >>> Do you know if itâs possible to handle offline mode ? >>> >>> >>> >>> Le 25 oct. 2017 Ã 15:05, Denis Kudriashov <dionisiydk(a)gmail.com> a >>> Ã©crit : >>> >>> Look at Seamless https://github.com/dionisiydk/Seamless. >>> >>> 2017-10-25 14:21 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: >>> >>>> Hi all, >>>> >>>> I want to connect two applications (1 by image, each one on a different >>>> computer) so as as to exchange information (data) between them. >>>> >>>> So my question is about the best (smalltalk) practices to connect two >>>> app/image and exchange data. >>>> >>>> I imagine either with a direct connection through a network (TCP >>>> Socket, Web socket, pure HTTP with Zinc) and/or with a serial connection. >>>> At first, without any Â« security Â». But later, information exchanges >>>> will be encrypted. >>>> >>>> Iâve seen some information on how to use SerialPort, or even FileStream. >>>> I could do it (or at least simulate it with HTTP). What are the other >>>> options ? Socket ? >>>> Do we have P2P libs (I couldnât find) with eventually discovery >>>> features ? >>>> >>>> Any comment / suggestion / pointers are greatly welcome. >>>> >>>> TIA. >>>> >>>> CÃ©drick >>>> >>> >>> >>> >> >>

Oct. 27, 2017

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

by CÃ©drick BÃ©ler

An interesting read on P2P content distribution. https://medium.com/paratii/a-brief-history-of-p2p-content-distribution-in-1… To me Smalltalk fits naturally in this paradigm (isnât it gemstone adn?). My naive thought would be to push on such development. Better scalability, resilience ... Does it exists Pharo developments that falls in this category (p2p content distribution) ? Would it be interesting to have DHT in Pharo ? For which usage ? Just thinking loud ! ^^ Cheers, CÃ©drick > Le 27 oct. 2017 Ã 10:04, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> a Ã©crit : > > > >> Le 26 oct. 2017 Ã 20:35, Paul DeBruicker <pdebruic(a)gmail.com> a Ã©crit : >> >> I made this port/copy of the squeaksource package: >> >> http://smalltalkhub.com/#!/~Cryptography/Cryptography >> >> >> Is that the version you were thinking of and couldn't find? > > Oh probably. I might have overlooked, and maybe only on Github. > > >> >> What is ifs? >> > > Sorry this was a typo. I meant ipfs (a distributed file system). > > It works like GIT. Under the hood is a (distributed) Merkle DAG that store content hash. > > https://ipfs.io/ > > The official implantation is in GO and I think the js (node) version is quite complete too. > > I see it as a source of inspiration (and eventually a kind of âeternalâ backend). > > >> I don't understand what you want to do with the hashing. Are you talking >> about hashing domain objects for external storage? Do you have to interact >> with another system or just have hashed data in the image or stored >> somewhere internally to your project? What OS are you going to use? > > Not sure yet what I want to do with that. I see content hashing as a digital fingerprint of information exchanged by two systems. > > What I try to demo is a personal information system (several personal nodes representing it simulates by several Pharo apps) that interact (exchange info) with others person personal information system. > > Iâd like to embrace the distributed/decentralized programming paradigms which if I understand well would allow to build such system without a centralized point of failure. > So no real db, only nodes that replicates information once shared. Amongst other things, Iâd like to show that if a node is lost (stolen smartphone for instance), one can rebuilt it from other nodes. All non shared info are lost forever though. There can be later some special node acting as storage. > > >> >> >> I think you can get to the point where your objects can be hashed by any of >> the backends you mention and just change among them as your needs change. >> That being said NaCl seems the most generally useful. Cryptographic hashing >> in Pharo is slower than C, so depending on the volume of data to hash a >> Pharo implementation may be too slow. > > At start, I can do without cryptography but Iâd like soon to think about a way to encrypt information exchange between nodes. Maybe symmetric crypto will be enough. > > Hashing on the other one would be more to have a way to index information. Cryto to encrypt exchanges. > >> >> >> >> hope this helps >> > > Yes sure. > > I hope I was clearer in my explanations ! > > Cheers, > > CÃ©drick > >> >> Paul >> >> >> CÃ©drick BÃ©ler wrote >>> Hi again, >>> >>> >>> Concerning cryptography in Pharo, there are to my knowledge : >>> => a package developed in squeak [1] that was I think ported/forked for >>> Pharo. I cannot find the Pharo version >>> => a binding to the sodium library (NaCl) [2] >>> >>> With one would you recommend ? Maybe another option ? >>> >>> >>> Concerning hashing (Iâd like to hash information content a bit like this >>> is done in ifs with their multihash lib [3]) >>> => I found a keccak implication with I think would do the [4]. Any >>> feedback ? Other implementations available ? >>> => Do you think having something like ifs multihash would be interesting >>> in Pharo ? >>> >>> >>> Again, thanks in advance for your comments/advices. >>> >>> CÃ©drick >>> >>> >>> [1] http://www.squeaksource.com/Cryptography.html >>> <http://www.squeaksource.com/Cryptography.html> >>> [2] >>> http://catalog.pharo.org/catalog/project/Nacl?_s=54MCZlmxc6F08Ht4&_k=HxcBD1… >>> <http://catalog.pharo.org/catalog/project/Nacl?_s=54MCZlmxc6F08Ht4&_k=HxcBD1pRVtXkfVFM> >>> [3] https://github.com/multiformats/multihash >>> <https://github.com/multiformats/multihash> >>> [4] https://github.com/sbragagnolo/Keccak >>> <https://github.com/sbragagnolo/Keccak> >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>

Oct. 27, 2017

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

by CÃ©drick BÃ©ler

> Nothing complex about two images exchanging messages, its not even complex to transmit objects via fuel, you even transmit a debugger or any part of the live environment or even make an "internet" of images that join objects together. Sky is the limit. Pharo already provides you will all the tools/libraries to do this. Yes. Thatâs why I asked for better practices. > > A streamsocket (not to be confused with regular sockets) will delay the messages (a collection of bytes) until they arrive to the receiver or until they have reached the timeout period. Offline mode is pretty much obligatory even for plain old internet web apps because of drops in connection or the plain fact a connection can become slow. Offline mode is to me of first importance. Letâs say I have a sets of Pharo app (nodes). Each one are independent running on different devices/computers. I want to exchange information between them according to some kind of contracts and also on connection availability. What I find different from usual message exchanges between two images is that I want to have full control on it. Plus I consider images offline by default (meaning two images have different versions of the same info). So conflict is the norm. Also, I donât want to send message remotely (with behavior), I just want to send/share an information and sync them (when possible). Connection between 2 images can be through a network but eventually through a serial connection (usb cable, Bluetooth,...). So what I try to do as a proto is having connection controlled by my apps (I put the app offline (not by switching off wifi but by switching logically). I can see nodes availability and activate connexion manually then see if conflict resolution is ok, + I log every connecitions changes and exchanges). This is my plans for now but it may change ! ^^ > > I used streamsockets in my Pharo to Python bridge (Atlas) because the execution was not necessary synchronous , I was sending Python command to a 3d application from Pharo and I had to make sure that the bridge was working even in the case of a command that could take hours to execute like a rendering process. Iâll look at stream sockets and mq stuffs. Cheers, CÃ©drick > > One cool trick I did was to send the Python errors back to Pharo and trigger them as Pharo's regular MessageNotUnderstood , this is a nice way to make sure that you can fix a wrong message after it has been executing without going to the image that is executing it. > > The limitation with sockets which what every frameworks uses because AFAIK they are the only means to communicate remotely is that they are not top performance so that mean that you can send long loops but executing communication inside long loops will either slow you down considerably or simply timeout your socket. Sockets can timeout from both ends if they feel that for some reason they lost communication with the other side and reached their timeout period. Timeout period is customization. > > This is a problem I did not tackle with my implementation because I dont think there can be an actual practical solution better than avoiding this scenario. > > Only shared memory seems to overcome this but it can be used only locally and not remotely (aka on same computer) . > >> On Wed, Oct 25, 2017 at 4:41 PM CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: >> I had a look and this is not (natively) possible. >> >> The idea of the off-line mode would be to delay messages that are sent to the peer until a connection is established. >> >> I think I have to try to do it by myself (like having a list of information exchange that wait until a connexion is established). >> >> What I try to do is not as complex as two general image exchanging messages on objects (like on TelePharo). >> >> I just want a repository of information (mainly a collection of static information/data versions) on both peers to be synchronized when a connection is established. >> >> >> >> >> >>> Le 25 oct. 2017 Ã 15:31, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit : >>> >>> What is offline mode? >>> >>> 2017-10-25 15:10 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: >>>> Thanks Denis. I will ! I knew I have seen a telephoto component that could help but forgot about it ! >>>> >>>> Do you know if itâs possible to handle offline mode ? >>>> >>>> >>>> >>>>> Le 25 oct. 2017 Ã 15:05, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit : >>>>> >>>>> Look at Seamless https://github.com/dionisiydk/Seamless. >>>>> >>>>> 2017-10-25 14:21 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: >>>>>> Hi all, >>>>>> >>>>>> I want to connect two applications (1 by image, each one on a different computer) so as as to exchange information (data) between them. >>>>>> >>>>>> So my question is about the best (smalltalk) practices to connect two app/image and exchange data. >>>>>> >>>>>> I imagine either with a direct connection through a network (TCP Socket, Web socket, pure HTTP with Zinc) and/or with a serial connection. >>>>>> At first, without any Â« security Â». But later, information exchanges will be encrypted. >>>>>> >>>>>> Iâve seen some information on how to use SerialPort, or even FileStream. >>>>>> I could do it (or at least simulate it with HTTP). What are the other options ? Socket ? >>>>>> Do we have P2P libs (I couldnât find) with eventually discovery features ? >>>>>> >>>>>> Any comment / suggestion / pointers are greatly welcome. >>>>>> >>>>>> TIA. >>>>>> >>>>>> CÃ©drick >>>>> >>>> >>> >>

Oct. 27, 2017

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

by CÃ©drick BÃ©ler

> Le 26 oct. 2017 Ã 20:35, Paul DeBruicker <pdebruic(a)gmail.com> a Ã©crit : > > I made this port/copy of the squeaksource package: > > http://smalltalkhub.com/#!/~Cryptography/Cryptography > > > Is that the version you were thinking of and couldn't find? Oh probably. I might have overlooked, and maybe only on Github. > > What is ifs? Sorry this was a typo. I meant ipfs (a distributed file system). It works like GIT. Under the hood is a (distributed) Merkle DAG that store content hash. https://ipfs.io/ The official implantation is in GO and I think the js (node) version is quite complete too. I see it as a source of inspiration (and eventually a kind of âeternalâ backend). > I don't understand what you want to do with the hashing. Are you talking > about hashing domain objects for external storage? Do you have to interact > with another system or just have hashed data in the image or stored > somewhere internally to your project? What OS are you going to use? Not sure yet what I want to do with that. I see content hashing as a digital fingerprint of information exchanged by two systems. What I try to demo is a personal information system (several personal nodes representing it simulates by several Pharo apps) that interact (exchange info) with others person personal information system. Iâd like to embrace the distributed/decentralized programming paradigms which if I understand well would allow to build such system without a centralized point of failure. So no real db, only nodes that replicates information once shared. Amongst other things, Iâd like to show that if a node is lost (stolen smartphone for instance), one can rebuilt it from other nodes. All non shared info are lost forever though. There can be later some special node acting as storage. > > > I think you can get to the point where your objects can be hashed by any of > the backends you mention and just change among them as your needs change. > That being said NaCl seems the most generally useful. Cryptographic hashing > in Pharo is slower than C, so depending on the volume of data to hash a > Pharo implementation may be too slow. At start, I can do without cryptography but Iâd like soon to think about a way to encrypt information exchange between nodes. Maybe symmetric crypto will be enough. Hashing on the other one would be more to have a way to index information. Cryto to encrypt exchanges. > > > > hope this helps > Yes sure. I hope I was clearer in my explanations ! Cheers, CÃ©drick > > Paul > > > CÃ©drick BÃ©ler wrote >> Hi again, >> >> >> Concerning cryptography in Pharo, there are to my knowledge : >> => a package developed in squeak [1] that was I think ported/forked for >> Pharo. I cannot find the Pharo version >> => a binding to the sodium library (NaCl) [2] >> >> With one would you recommend ? Maybe another option ? >> >> >> Concerning hashing (Iâd like to hash information content a bit like this >> is done in ifs with their multihash lib [3]) >> => I found a keccak implication with I think would do the [4]. Any >> feedback ? Other implementations available ? >> => Do you think having something like ifs multihash would be interesting >> in Pharo ? >> >> >> Again, thanks in advance for your comments/advices. >> >> CÃ©drick >> >> >> [1] http://www.squeaksource.com/Cryptography.html >> <http://www.squeaksource.com/Cryptography.html> >> [2] >> http://catalog.pharo.org/catalog/project/Nacl?_s=54MCZlmxc6F08Ht4&_k=HxcBD1… >> <http://catalog.pharo.org/catalog/project/Nacl?_s=54MCZlmxc6F08Ht4&_k=HxcBD1pRVtXkfVFM> >> [3] https://github.com/multiformats/multihash >> <https://github.com/multiformats/multihash> >> [4] https://github.com/sbragagnolo/Keccak >> <https://github.com/sbragagnolo/Keccak> > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Oct. 27, 2017

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

by CÃ©drick BÃ©ler

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. 27, 2017

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

by Prof. Andrew P. Black

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. 27, 2017

"sourcetrail" a code browser for C++/Java

by Holger Freyther

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. 27, 2017

Re: [Pharo-users] UFFI and Fortran

by Ben Coman

Always starting by assuming someone in another language wants to do the same ;) googling... fortran ffi python second result... https://maurow.bitbucket.io/notes/calling_fortran_from_misc.html I only skimmed quickly, but it seems to hint how to do it from Pharo UFFI. cheers -ben P.S. Interesting concept. All too often its C libraries used as an example, but IIUC, Fortran still provides the highest performance of all the numerical libraries, with a many-year pedigree of reliability.

Oct. 27, 2017

Re: [Pharo-users] Smalltalk Argument

by Ben Coman

On Thu, Oct 26, 2017 at 3:40 PM, Paulo R. Dellani <dellani(a)pobox.com> wrote: > I like your depiction of the situation and arguments, Andrew. > > The inherent volatility of the software industry due to its tendency > to self disruption, as you pointed out, is fertile ground to all kinds of > crap, but we as developers should keep our eyes wide open and > look for the pearls and gems that grow here and there, > like Pharo Smalltalk. > > Of course my "vision", as a Smalltalker is inherently biased, but > as you said, when "shit has to work", I think that we have good > cards at our hands. > If that is a key requirement, share these with your stakeholders... * GemStone:64 Update and Roadmap https://www.youtube.com/watch?v=ejtXqJoSrb4&list=PLJ5nSnWzQXi_THfKwhzxFwbXy… * Running Pharo on the GemStone VM https://www.youtube.com/watch?v=TkvjUXn3tGs&list=PLJ5nSnWzQXi_THfKwhzxFwbXy… "Develop on Pharo, Deploy on Gemstone" seems to be a growing meme. > So yesterday we had another meeting and I think I could make a > good point for Smalltalk, thanks to all your arguments here at the > list. But surely the absolute killer argument is that "this shit really > works" :-) > > As pointed out by several of you, integration is key. For my particular > present case, I could successfully integrate the developed tools in > the system, a medical imaging processing pipeline, > Juan might be able to advise on the suitability of Smalltalk for image processing... * https://news.squeak.org/2017/05/24/satellogic-hyperspectral-cameras-geometr… * https://www.nature.com/articles/n-12305964 Regarding the reality of Pharo having less libraries than mainstream languages. I am reminded of this interesting perspective... * https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-s… that reuse is not always an advantage. Certainly FFI provides access to a large selection of pre-made libraries - but it opens applications to memory protection faults and other quirks that make debugging more difficult. As always, its "horses for courses". cheers -ben

Oct. 27, 2017

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

by Ben Coman

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

Oct. 27, 2017

UFFI and Fortran

by horrido

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

Oct. 27, 2017

Re: [Pharo-users] Smalltalk Argument

by phil＠highoctane.be

There are two key Kerberos implementations one can use with Hadoop. One is the FreeIpa/RedHat IdM. The other is ActiveDirectory. I am using FreeIPA which bundles MIT Kerberos/389/sssd and more for making a CA etc. Works wonderfullÃ½ well. AD is well ... part of the corporate landdscape. Most of Kerberos needs are done with Java in Hadoop. But details are buried in private Sun classes.. Google Madness beyond the gate hadoop for some Lovecraftian quotes describing the situation along educated info. Phil On Thu, Oct 26, 2017 at 6:23 PM, henry <henry(a)callistohouse.club> wrote: > I have no idea which is best. For being able to say we use industry > standard Kerberos, calling an accepted implementation seems wise, like > OpenSSL support. > > - HH > > > On Thu, Oct 26, 2017 at 11:39, Paulo R. Dellani <dellani(a)pobox.com> wrote: > > This all sounds very interesting. What is the idea? Wrap libkrb5 through > UFFI or implement it in Smalltalk? > > On 10/26/2017 04:38 PM, henry wrote: > > A Kerberos effort will have to be a group effort. Sideways to my main > focus and your allâs main focii. > > > - HH > > > On Thu, Oct 26, 2017 at 09:15, henry <henry(a)callistohouse.club> wrote: > > I think another good service to integrate well to is Elastic Search. > > Of the 4 types of integration, I vote for and step forward to volunteer to > help Kerberos integration in Pharo. What to do? > > > - HH > > > On Thu, Oct 26, 2017 at 09:06, henry <henry(a)callistohouse.club> wrote: > > I try posting with a smaller image. > > [image: ""hubbub.jpg""] > > - HH > > > âââ Original Message âââ > Subject: Re: [Pharo-users] Smalltalk Argument > Local Time: October 26, 2017 8:52 AM > UTC Time: October 26, 2017 12:52 PM > From: henry(a)callistohouse.club > To: phil(a)highoctane.be <phil(a)highoctane.be> <phil(a)highoctane.be>, Any > question about pharo is welcome <pharo-users(a)lists.pharo.org> > <pharo-users(a)lists.pharo.org> > > Perhaps not, or not yet. Perhaps it is the communications foundation for > an always-on cloud/bigData control layer. > > I would position ParrotTalk as a Kerberos transport. ParrotTalk does > 2048-bin key negotiation and subsequent encryption/encoding, both > user-supplied. > > Please see the attached diagram, co-locating ParrotTalk with my other > components. > > ParrotTalk does not do user authentication/authorization. Which means to > me that I should consider Kerberos authorization/authentication to > establish as an integratable transport to play in bigData. > > This means you still need a Kerberos client and I need a Kerberos client. > How do we start? > > - HH > > PS: I did much work integrating Kafka into a framework. I was thinking of > inserting msg sending replication to a partition count of replicate queues > for sending and receiving Hubbub traffic, thus inserting right where > Kerberos is in the diagram. I would love to see client coupling for > Kerberos, Kafka and Hadoop, while I figure out proper security to make that > group happy with this as a possible control layer solution, forking off > jobs. > > > On Thu, Oct 26, 2017 at 03:14, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > > Sure. Current main issue is to have Pharo work with Kerberos as secured > Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole > of crypto things. > > How would you see ParrotTalk work? > > I made a XmppTalk thing (binding for libstrophe) for having Pharo images > and other stuff talk together (currently using OpenFire/Gajim/Profanity) > FWIW > > See https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tm > uxyZz1UaX5ikEU/edit?usp=sharing > > libstrophe does the SSL thing under the hood (using OpenSSL) and is > actively maintained. > https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c > > And I currently work with Kafka so, Pharo as a consumer or producer, sure > am interested. But need Kerberos support. > > Tell me more about your vision. Even better, draw it in some way :-) > > Phil > > > On Thu, Oct 26, 2017 at 8:43 AM, henry <henry(a)callistohouse.club> wrote: > > This is a goal of ParrotTalk, to bring bit-compatible communications to > Squeak, Pharo and Java. This is not an invocation bridge you speak of but a > communications bridge to be able to run against Hadoop or whichever big > data needs integration with (Kafka). I had hoped it might be adopted for > such. Yet again this is not exactly what you were looking for but yet > interesting perhaps? > > > - HH > > > On Thu, Oct 26, 2017 at 02:17, phil(a)highoctane.be < phil(a)highoctane.be> > wrote: > > I like that piece a lot, seeing exactly the described situation in large > enterprises. > > I made a strategic decision to go with Pharo for the long run for my > solutions because it is a stable base on which to build (ok, there are > evolutions, but fundamentally, I can rely on it being under control and can > maintain solutions in a version). > > The rationale is that at a deep level I am really fed up with having to > deal with accidental complexity (now having to deal with > Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology > drag and 20% net business contribution. > > One key thing is that a team needs guidance and Smalltalk makes it easier > due to well known ways of doing things. > > Now we miss the boat on mobile and bigdata, but this is solvable. > > If we had an open Java bridge (and some people in the community have it > for Pharo but do not open source it - so this is eminently doable) + Pharo > as an embeddable piece (e.g. like Tcl and Lua) and not a big executable we > would have a way to embed Pharo in a lot of places (e.g. in the Hadoop > ecosystem where fast starting VMs and small footprint would make the > cluster capacity x2 or x3 vs uberjars all over the place) this would be a > real disruption. > > Think about being able to call Pharo from JNA https://github.com/java-na > tive-access/jna the same way we use C with UFFI. > > Smalltalk argument for me is that it makes development bearable (even fun > and enjoyable would I say) vs the other stacks. That matters. > > Phil > >

Oct. 26, 2017

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

by Paul DeBruicker

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

Oct. 26, 2017

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

by Paul DeBruicker

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

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

I have no idea which is best. For being able to say we use industry standard Kerberos, calling an accepted implementation seems wise, like OpenSSL support. - HH On Thu, Oct 26, 2017 at 11:39, Paulo R. Dellani <dellani(a)pobox.com> wrote: > This all sounds very interesting. What is the idea? Wrap libkrb5 through UFFI or implement it in Smalltalk? > > On 10/26/2017 04:38 PM, henry wrote: > >> A Kerberos effort will have to be a group effort. Sideways to my main focus and your allâs main focii. >> >> - HH >> >> On Thu, Oct 26, 2017 at 09:15, henry <[henry@callistohouse.club](%22mailto:henry@callistohouse.club%22)> wrote: >> >>> I think another good service to integrate well to is Elastic Search. >>> >>> Of the 4 types of integration, I vote for and step forward to volunteer to help Kerberos integration in Pharo. What to do? >>> >>> - HH >>> >>> On Thu, Oct 26, 2017 at 09:06, henry <[henry@callistohouse.club](%22%22mailto:henry@callistohouse.club%22%22)> wrote: >>> >>>> I try posting with a smaller image. >>>> >>>> [""hubbub.jpg""] >>>> >>>> - HH >>>> >>>>> âââ Original Message âââ >>>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>>> Local Time: October 26, 2017 8:52 AM >>>>> UTC Time: October 26, 2017 12:52 PM >>>>> From: henry(a)callistohouse.club >>>>> To: phil(a)highoctane.be [<phil(a)highoctane.be>](mailto:phil@highoctane.be), Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](mailto:pharo-users@lists.pharo.org) >>>>> >>>>> Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer. >>>>> >>>>> I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. >>>>> >>>>> Please see the attached diagram, co-locating ParrotTalk with my other components. >>>>> >>>>> ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData. >>>>> >>>>> This means you still need a Kerberos client and I need a Kerberos client. How do we start? >>>>> >>>>> - HH >>>>> >>>>> PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs. >>>>> >>>>> On Thu, Oct 26, 2017 at 03:14, phil(a)highoctane.be <[phil@highoctane.be](%22%22%22mailto:phil@highoctane.be%22%22%22)> wrote: >>>>> >>>>>> Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. >>>>>> >>>>>> How would you see ParrotTalk work? >>>>>> >>>>>> I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW >>>>>> >>>>>> See [https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1… >>>>>> >>>>>> libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained. >>>>>> [https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c](%22%22… >>>>>> >>>>>> And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support. >>>>>> >>>>>> Tell me more about your vision. Even better, draw it in some way :-) >>>>>> >>>>>> Phil >>>>>> >>>>>> On Thu, Oct 26, 2017 at 8:43 AM, henry <[henry@callistohouse.club](%22%22%22mailto:henry@callistohouse.club%22%22%22)> wrote: >>>>>> >>>>>>> This is a goal of ParrotTalk, to bring bit-compatible communications to Squeak, Pharo and Java. This is not an invocation bridge you speak of but a communications bridge to be able to run against Hadoop or whichever big data needs integration with (Kafka). I had hoped it might be adopted for such. Yet again this is not exactly what you were looking for but yet interesting perhaps? >>>>>>> >>>>>>> - HH >>>>>>> >>>>>>> On Thu, Oct 26, 2017 at 02:17, [phil@highoctane.be](%22%22%22mailto:phil@highoctane.be%22%22%22) < phil(a)highoctane.be> wrote: >>>>>>> >>>>>>>> I like that piece a lot, seeing exactly the described situation in large enterprises. >>>>>>>> >>>>>>>> I made a strategic decision to go with Pharo for the long run for my solutions because it is a stable base on which to build (ok, there are evolutions, but fundamentally, I can rely on it being under control and can maintain solutions in a version). >>>>>>>> >>>>>>>> The rationale is that at a deep level I am really fed up with having to deal with accidental complexity (now having to deal with Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology drag and 20% net business contribution. >>>>>>>> >>>>>>>> One key thing is that a team needs guidance and Smalltalk makes it easier due to well known ways of doing things. >>>>>>>> >>>>>>>> Now we miss the boat on mobile and bigdata, but this is solvable. >>>>>>>> >>>>>>>> If we had an open Java bridge (and some people in the community have it for Pharo but do not open source it - so this is eminently doable) + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big executable we would have a way to embed Pharo in a lot of places (e.g. in the Hadoop ecosystem where fast starting VMs and small footprint would make the cluster capacity x2 or x3 vs uberjars all over the place) this would be a real disruption. >>>>>>>> >>>>>>>> Think about being able to call Pharo from JNA https://github.com/java-native-access/jna the same way we use C with UFFI. >>>>>>>> >>>>>>>> Smalltalk argument for me is that it makes development bearable (even fun and enjoyable would I say) vs the other stacks. That matters. >>>>>>>> >>>>>>>> Phil

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by Paulo R. Dellani

This all sounds very interesting. What is the idea? Wrap libkrb5 through UFFI or implement it in Smalltalk? On 10/26/2017 04:38 PM, henry wrote: > A Kerberos effort will have to be a group effort. Sideways to my main > focus and your allâs main focii. > > > - HH > > > On Thu, Oct 26, 2017 at 09:15, henry <henry(a)callistohouse.club > <%22mailto:henry@callistohouse.club%22>> wrote: > > I think another good service to integrate well to is Elastic Search. > > Of the 4 types of integration, I vote for and step forward to > volunteer to help Kerberos integration in Pharo. What to do? > > > - HH > > > On Thu, Oct 26, 2017 at 09:06, henry <henry(a)callistohouse.club > <%22%22mailto:henry@callistohouse.club%22%22>> wrote: > > I try posting with a smaller image. > > ""hubbub.jpg"" > > - HH > > > âââ Original Message âââ > Subject: Re: [Pharo-users] Smalltalk Argument > Local Time: October 26, 2017 8:52 AM > UTC Time: October 26, 2017 12:52 PM > From: henry(a)callistohouse.club > To: phil(a)highoctane.be <phil(a)highoctane.be>, Any question > about pharo is welcome <pharo-users(a)lists.pharo.org> > > Perhaps not, or not yet. Perhaps it is the communications > foundation for an always-on cloud/bigData control layer. > > I would position ParrotTalk as a Kerberos transport. > ParrotTalk does 2048-bin key negotiation and subsequent > encryption/encoding, both user-supplied.Â > > Please see the attached diagram, co-locating ParrotTalk > with my other components. > > ParrotTalk does not do user authentication/authorization. > Which means to me that I should consider Kerberos > authorization/authentication to establish as an > integratable transport to play in bigData. > > This means you still need a Kerberos client and I need a > Kerberos client. How do we start? > > - HH > > PS: I did much work integrating Kafka into a framework. I > was thinking of inserting msg sending replication to a > partition count of replicate queues for sending and > receiving Hubbub traffic, thus inserting right where > Kerberos is in the diagram. I would love to see client > coupling for Kerberos, Kafka and Hadoop, while I figure > out proper security to make that group happy with this as > a possible control layer solution, forking off jobs. > > > On Thu, Oct 26, 2017 at 03:14, phil(a)highoctane.be > <phil(a)highoctane.be > <%22%22%22mailto:phil@highoctane.be%22%22%22>> wrote: > > Sure. Current main issue is to have Pharo work with > Kerberos as secured Hadoop uses the UGI > (UserGroupInformation) thing and that is a black hole > of crypto things.Â > > How would you see ParrotTalk work?Â > > I made a XmppTalk thing (binding for libstrophe) for > having Pharo images and other stuff talk together > (currently using OpenFire/Gajim/Profanity) FWIW > > See > https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1… > <%22%22%22https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1UaX5ikEU/edit?usp=sharing%22%22%22> > > > libstrophe does the SSL thing under the hood (using > OpenSSL) and is actively maintained. > https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c > <%22%22%22https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c%22%22%22> > > > And I currently work with Kafka so, Pharo as a > consumer or producer, sure am interested. But need > Kerberos support. > > Tell me more about your vision. Even better, draw it > in some way :-) > > Phil > > > On Thu, Oct 26, 2017 at 8:43 AM, henry > <henry(a)callistohouse.club > <%22%22%22mailto:henry@callistohouse.club%22%22%22>> > wrote: > > ThisÂ is a goal ofÂ ParrotTalk, to bring > bit-compatible communications to Squeak, Pharo and > Java. This is not an invocation bridge you speak > of but a communications bridge to be able to run > against Hadoop or whichever big data needs > integration with (Kafka). I had hoped it might be > adopted for such. Yet again this is not exactly > what you were looking for but yet interesting > perhaps? > > > - HH > > > On Thu, Oct 26, 2017 at 02:17, phil(a)highoctane.be > <%22%22%22mailto:phil@highoctane.be%22%22%22> > <phil(a)highoctane.be> wrote: > > I like that piece a lot, seeing exactly the > described situation in large enterprises. > > I made a strategic decision to go with Pharo > for the long run for my solutions because it > is a stable base on which to build (ok, there > are evolutions, but fundamentally, I can rely > on it being under control and can maintain > solutions in a version). > > The rationale is that at a deep level I am > really fed up with having to deal with > accidental complexity (now having to deal with > Spark/Scala/sbt/Java/maven stuff) that makes > the dev focus 80% technology drag and 20% net > business contribution. > > One key thing is that a team needs guidance > and Smalltalk makes it easier due to well > known ways of doing things. > > Now we miss the boat on mobile and bigdata, > but this is solvable.Â > > If we had an open Java bridge (and some people > in the community have it for Pharo but do not > open source it - so this is eminently doable) > + Pharo as an embeddable piece (e.g. like Tcl > and Lua) and not a big executable we would > have a way to embed Pharo in a lot of places > (e.g. in the Hadoop ecosystem where fast > starting VMs and small footprint would make > the cluster capacity x2 or x3 vs uberjars all > over the place) Â this would be a real disruption. > > Think about being able to call Pharo from > JNAÂ https://github.com/java-native-access/jna > the same way we use C with UFFI. > > Smalltalk argument for me is that it makes > development bearable (even fun and enjoyable > would I say) vs the other stacks. That matters. > > Phil >

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

The question I propose you is what is necessary to make Pharo eligible to participate in cloud/BigData? - HH On Thu, Oct 26, 2017 at 10:38, henry <[henry(a)callistohouse.club]("mailto:henry@callistohouse.club")> wrote: > A Kerberos effort will have to be a group effort. Sideways to my main focus and your allâs main focii. > > - HH > > On Thu, Oct 26, 2017 at 09:15, henry <[henry(a)callistohouse.club](""mailto:henry@callistohouse.club"")> wrote: > >> I think another good service to integrate well to is Elastic Search. >> >> Of the 4 types of integration, I vote for and step forward to volunteer to help Kerberos integration in Pharo. What to do? >> >> - HH >> >> On Thu, Oct 26, 2017 at 09:06, henry <[henry(a)callistohouse.club]("""mailto:henry@callistohouse.club""")> wrote: >> >>> I try posting with a smaller image. >>> >>> ["""hubbub.jpg"""] >>> >>> - HH >>> >>>> âââ Original Message âââ >>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>> Local Time: October 26, 2017 8:52 AM >>>> UTC Time: October 26, 2017 12:52 PM >>>> From: henry(a)callistohouse.club >>>> To: phil(a)highoctane.be <phil(a)highoctane.be>, Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>> >>>> Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer. >>>> >>>> I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. >>>> >>>> Please see the attached diagram, co-locating ParrotTalk with my other components. >>>> >>>> ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData. >>>> >>>> This means you still need a Kerberos client and I need a Kerberos client. How do we start? >>>> >>>> - HH >>>> >>>> PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs. >>>> >>>> On Thu, Oct 26, 2017 at 03:14, phil(a)highoctane.be <[phil(a)highoctane.be](""""mailto:phil@highoctane.be"""")> wrote: >>>> >>>>> Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. >>>>> >>>>> How would you see ParrotTalk work? >>>>> >>>>> I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW >>>>> >>>>> See [https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…""""https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…"""") >>>>> >>>>> libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained. >>>>> [https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c](""""https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c"""") >>>>> >>>>> And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support. >>>>> >>>>> Tell me more about your vision. Even better, draw it in some way :-) >>>>> >>>>> Phil >>>>> >>>>> On Thu, Oct 26, 2017 at 8:43 AM, henry <[henry(a)callistohouse.club](""""mailto:henry@callistohouse.club"""")> wrote: >>>>> >>>>>> This is a goal of ParrotTalk, to bring bit-compatible communications to Squeak, Pharo and Java. This is not an invocation bridge you speak of but a communications bridge to be able to run against Hadoop or whichever big data needs integration with (Kafka). I had hoped it might be adopted for such. Yet again this is not exactly what you were looking for but yet interesting perhaps? >>>>>> >>>>>> - HH >>>>>> >>>>>> On Thu, Oct 26, 2017 at 02:17, [phil(a)highoctane.be](""""mailto:phil@highoctane.be"""") <phil(a)highoctane.be> wrote: >>>>>> >>>>>>> I like that piece a lot, seeing exactly the described situation in large enterprises. >>>>>>> >>>>>>> I made a strategic decision to go with Pharo for the long run for my solutions because it is a stable base on which to build (ok, there are evolutions, but fundamentally, I can rely on it being under control and can maintain solutions in a version). >>>>>>> >>>>>>> The rationale is that at a deep level I am really fed up with having to deal with accidental complexity (now having to deal with Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology drag and 20% net business contribution. >>>>>>> >>>>>>> One key thing is that a team needs guidance and Smalltalk makes it easier due to well known ways of doing things. >>>>>>> >>>>>>> Now we miss the boat on mobile and bigdata, but this is solvable. >>>>>>> >>>>>>> If we had an open Java bridge (and some people in the community have it for Pharo but do not open source it - so this is eminently doable) + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big executable we would have a way to embed Pharo in a lot of places (e.g. in the Hadoop ecosystem where fast starting VMs and small footprint would make the cluster capacity x2 or x3 vs uberjars all over the place) this would be a real disruption. >>>>>>> >>>>>>> Think about being able to call Pharo from JNA https://github.com/java-native-access/jna the same way we use C with UFFI. >>>>>>> >>>>>>> Smalltalk argument for me is that it makes development bearable (even fun and enjoyable would I say) vs the other stacks. That matters. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: >>>>>>> >>>>>>>> Thereâs other questions that are relevant to me: >>>>>>>> >>>>>>>> Do I give a f*** about cool looking web apps? No, I donât use web apps if in any way I can avoid it. >>>>>>>> >>>>>>>> Do I give a f*** about mobile apps? No, the screenâs too small to read anything longer than a twit, or anyone with anything worthwhile to say. >>>>>>>> >>>>>>>> Do I give a f*** about the number of libraries in other languages? No, because most of them are crap in every language Iâve had to work in, and the base languages are crap so they have to keep changing radically, and libraries and frameworks therefore also have to and never get any better. The few that are worthwhile I can almost always use from Smalltalk without a problem (read, Blender, ACT-R and Synapse, since every other library/framework Iâve used outside Smalltalk has been a waste of time). >>>>>>>> >>>>>>>> Do I give a f*** about implementing a complex piece of machine learning software in 22 hours, compared to 3 months for the Java version? Well, actually yes, I do, because that was 3 months of my life down the toilet for something that is too slow to be useful in Java. >>>>>>>> >>>>>>>> Any argument depends on your priorities. Iâve written tons of web apps, because I needed to get paid. Iâve written better shitty mobile apps than the average shitty mobile apps. However, Iâm not going to do any of that any longer in crap that never improves, because after 26 years the irritability it produces is more than itâs worth. >>>>>>>> >>>>>>>> A few weeks ago, a recruiter that specializes in Smalltalk called me about a job, although they were well aware I live 1500 miles away from the city I lived in when I had worked through them, to see if Iâd be willing to move back there for a job. That sounds like another âthere arenât enough Smalltalk developers", but it wasnât, because the job wasnât writing Smalltalk. It was writing Java. >>>>>>>> >>>>>>>> The person hiring, though, wouldnât look at anyone who didnât write Smalltalk, because "people who grew up with Java donât know how to write code". I donât agree with that, Iâve known a (very few) good Java developers. I would say, though, that Iâve known far more incompetent ones than good ones, and I canât think of any incompetent Smalltalk developers off the top of my head. >>>>>>>> >>>>>>>> Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or even C, complain about how hard maintaining state is or coming up with various hacks to avoid it, which seems to be the main point of every JavaScript based âtechnologyâ. An application is by definition a state-machine, which implies plenty about JS developers on the whole. >>>>>>>> >>>>>>>> If youâre a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why arenât there more good developers in any language? >>>>>>>> >>>>>>>> Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises Iâve worked for whoâve written their own dialects, and they all use it only when "shit has to work". They know itâs more productive, they also know using it for more things would increase the availability of Smalltalk developers. >>>>>>>> >>>>>>>> Why do they not do it? One reason, though it takes a while to recognize it, because management doesnât admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesnât âreallyâ matter, is an advantage to large enterprises because they have resources smaller competitors donât. >>>>>>>> >>>>>>>> Why donât their competitors do it? Because they canât see past an hourly rate, whatâs fashionable, or just new, or because their customers canât. Put more generally, average stupidity that isnât corrected by the market. Fashion affects smaller companies more than larger ones, because they canât afford a few customers walking away because they wanted an app in Electron, even if they canât give any relevant reason for wanting it, and even the samples on the Electron site donât work. >>>>>>>> >>>>>>>> Enterprises can, and do use Smalltalk when it matters. When it doesnât, itâs to their advantage to promote things that are inefficient, buggy and unreliable. >>>>>>>> >>>>>>>> Cost is relevant, but not in the simple way people look at things. A crucial but rarely mentioned perspective on its relevance is that while Java based software runs TV set top boxes, Smalltalk based software runs things like medical equipment, automated defense systems, tanks, etc. Cost becomes largely irrelevant when âshit has to workâ. >>>>>>>> >>>>>>>> Productivity is primarily relevant to less talented developers, in an inversely sense, since unproductive environments and attitudes have a leveling tendency in general, and more specifically make accomplishing what the less talented are capable of in any environment sufficiently laborious for them to have a role. Capability in Smalltalk, as implied by the person hiring for the Java role I mentioned, is a fairly decent means of judging whether someone is a so-so developer or a good one. >>>>>>>> >>>>>>>> The productivity argument is realistically only relevant in the context of an already higher hourly cost. Given that it is relevant at that point, companies that know Smalltalk is more productive would use it outside things that have to be 100%, if their own productivity were relevant to the same degree that competitorsâ productivity is inversely relevant. >>>>>>>> >>>>>>>> All these ways of looking at it are contingent perspectives though. Yes, if the number of libraries is relevant to you, Smalltalk is less attractive, but thatâs only a contingent phenomenon based on the relative popularity of Java and JavaScript, as a result it canât be used as explanatory for that popularity. All the ways of looking at it that are fully determinate are determinate via contingencies of that kind, which for the most part are precisely the other perspectives, including productivity, cost, availability of developers, etc. None of them is in itself anything but a result of the others. >>>>>>>> >>>>>>>> If availability of developers is contingent on popularity (and further, popularity contingent on industry attitudes), to use an example already mentioned in Joachimâs post, then his simultaneous posit of library availability is if anything more contingent on the same popularity, so positing it as a cause and not a result, or merely a correlate, of popularity is incoherent. We can go one step further, and demonstrate that even when large enterprises make something that works reliably available, they fail to promote and support it, which destroys the market for reliable tooling by simultaneously owning it while not promoting it, something IBM is particularly good at. But IBM canât (and if they canât, neither can any other company) operate that way without the tacit agreement of the industry. >>>>>>>> >>>>>>>> To understand it in a more general way, software development has to be looked at in the context where it occurs, and how itâs determined to a large degree by that context, with a specific difference. That difference is itself implicit in the context, i.e. capitalism, but only purely effective in software development. Itâs a result of virtualization as an implicit goal of capitalism, and the disruptions implicit in the virtual but so far only realized completely in software. In terms of that understanding, the analysis of virtualization and disruption as inherent to capitalism is better accomplished in Kapital than in any more recent work. >>>>>>>> >>>>>>>> Or you can simply decide, as Iâve done recently, that working in ways and with tools that prevent doing good work in a reasonable timeframe isnât worthwhile to you, no matter how popular those ways and tools might be, or what the posited reasons are, since at the end popularity is only insofar as it already is. What those tools and methods are depends to a degree on your priorities, but if developers are engineers those priorities canât be completely arbitrary. Engineers are defined by their ability to make things work. >>>>>>>> >>>>>>>> Software as virtual is inherently disruptive, and the software industry disrupts itself too often and too easily to build on anything. A further disruption caused by developers, as engineers, refusing to work with crap that doesnât, i.e. insisting on being engineers, while in itself merely an aggravation of the disruptive tendencies, might have an inverse result. >>>>>>>> >>>>>>>> Using a stable core of technologies as the basis for a more volatile set of products, in the way nearly every other industry does, is the best means we know of to build things both flexibly and reasonably efficiently. The computer hardware industry is the extreme example of this, while the software industry is the extreme contradiction. >>>>>>>> >>>>>>>> From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> on behalf of David Mason <dmason(a)ryerson.ca> >>>>>>>> Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>>>>>> Date: Tuesday, October 24, 2017 at 11:52 AM >>>>>>>> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>>>>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>>>>>> >>>>>>>> PharoJS is working to give you that mobile app/browser app experience. As with others, weâre not there yet, but getting there. See http://pharojs.org >>>>>>>> >>>>>>>> The 67% loved means that 67% of people using Smalltalk (or perhaps have ever used it) want to continue - so itâs presumably a high percentage of a smallish number of people. >>>>>>>> >>>>>>>> On 20 October 2017 at 03:23, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: >>>>>>>> >>>>>>>>> First of all: Iâd say the question itself is not a question but an excuse. I am not arguing there are enough Smalltalkers or cheap ones. But I think the question is just a way of saying "we donât want to do it for reasons that we ourselves cannot really express". If you are a good developer, learning Smalltalk is easy. If you are a good developer youâve heard the sentence "weâve taken the goos parts from x,y,z and Smalltalk" at least twice a year. So you most likely would like to learn it anyways. >>>>>>>>> >>>>>>>>> A shortage of developers doesnât exist. What exists is an unwillingness of companies to get people trained in a technology. If Smalltalk was cool and great in their opinion, they wouldnât care. Itâs that simple. As a consultant, Iâve heard that argument so often. Not ferom Startups, but from insurance companies, Banks or Car manufacturers who spend millions on useless, endless meetings and stuff instead of just hiring somebody to teach a couple of developers Smalltalk. Itâs just a lie: the shortage of Smalltalk developers is not a problem. >>>>>>>>> >>>>>>>>> And, to be honest: what is it we actually are better in by using Smalltalk? >>>>>>>>> Can we build cool looking web apps in extremely short time? No. >>>>>>>>> Can we build mobile Apps with little effort? No. >>>>>>>>> Does our Smalltalk ship lots of great libraries for all kinds of things that are not availabel in similar quality in any other language? >>>>>>>>> Are we lying when we say we are so extremely over-productive as compared to other languages? >>>>>>>>> >>>>>>>>> I know, all that live debugging stuff and such is great and it is much faster to find & fix a bug in Smalltalk than in any other environment Iâve used so far. But that is really only true for business code. When I need to connect to things or want to build a modern GUI or a web application with a great look&feel, I am nowhere near productive, because I simply have to build my own stuff or learn how to use other external resources. If I want to build something for a mobile device, I will only hear that somebody somewhere has done it before. No docs, no proof, no ready-made tool for me. >>>>>>>>> >>>>>>>>> Shortage of developers is not really the problem. If Smalltalk was as cool as we like to make ourselves believe, this problem would be non-existent. If somebody took out their iPad and told an audience: "We did this in Smalltalk in 40% of the time it would have taken in Swift", and if that something was a must-have for people, things would be much easier. But nobody has. >>>>>>>>> >>>>>>>>> I am absolutely over-exaggerating, because I make my living with an SaaS product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk and - as you - am convince that many parts of what weâve done so far wouldâve taken much longer or even be impossible in other languages. But the advantage was eaten by our extremely steep learning curve for web technologies and for building something that works almost as well as tools like Angular or jQuery Mobile. >>>>>>>>> >>>>>>>>> Smalltalk is cool, and the day somebody shows me something like Googleâs flutter in Smalltalk, I am ready to bet a lot on a bright future for Smalltalk. But until then, Iâd say these arguments about productivity are just us trying to make ourselves believe weâre still the top of the food chain. Weâve done that for almost thirty years now and still arenât ready to stop it. But weâve been lying to ourselves and still do so. >>>>>>>>> >>>>>>>>> I donât think there is a point in discussing about the usefulness of a language using an argument like the number or ready-made developers. That is just an argument they know you canât win. The real question is and should be: what is the benefit of using Smalltalk. Our productivity argument is a lie as soon as we have to build something that uses or runs on technology that has been invented after 1990. >>>>>>>>> >>>>>>>>> Okay, shoot ;-) >>>>>>>>> >>>>>>>>> Joachim >>>>>>>>> >>>>>>>>> â >>>>>>>>> ââââââââââââââââââââââââ >>>>>>>>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >>>>>>>>> Fliederweg 1 http://www.objektfabrik.de >>>>>>>>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>>>>>>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

A Kerberos effort will have to be a group effort. Sideways to my main focus and your allâs main focii. - HH On Thu, Oct 26, 2017 at 09:15, henry <[henry(a)callistohouse.club]("mailto:henry@callistohouse.club")> wrote: > I think another good service to integrate well to is Elastic Search. > > Of the 4 types of integration, I vote for and step forward to volunteer to help Kerberos integration in Pharo. What to do? > > - HH > > On Thu, Oct 26, 2017 at 09:06, henry <[henry(a)callistohouse.club](""mailto:henry@callistohouse.club"")> wrote: > >> I try posting with a smaller image. >> >> [""hubbub.jpg""] >> >> - HH >> >>> âââ Original Message âââ >>> Subject: Re: [Pharo-users] Smalltalk Argument >>> Local Time: October 26, 2017 8:52 AM >>> UTC Time: October 26, 2017 12:52 PM >>> From: henry(a)callistohouse.club >>> To: phil(a)highoctane.be <phil(a)highoctane.be>, Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>> >>> Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer. >>> >>> I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. >>> >>> Please see the attached diagram, co-locating ParrotTalk with my other components. >>> >>> ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData. >>> >>> This means you still need a Kerberos client and I need a Kerberos client. How do we start? >>> >>> - HH >>> >>> PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs. >>> >>> On Thu, Oct 26, 2017 at 03:14, phil(a)highoctane.be <[phil(a)highoctane.be]("""mailto:phil@highoctane.be""")> wrote: >>> >>>> Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. >>>> >>>> How would you see ParrotTalk work? >>>> >>>> I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW >>>> >>>> See [https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…"""https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…""") >>>> >>>> libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained. >>>> [https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c]("""https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c""") >>>> >>>> And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support. >>>> >>>> Tell me more about your vision. Even better, draw it in some way :-) >>>> >>>> Phil >>>> >>>> On Thu, Oct 26, 2017 at 8:43 AM, henry <[henry(a)callistohouse.club]("""mailto:henry@callistohouse.club""")> wrote: >>>> >>>>> This is a goal of ParrotTalk, to bring bit-compatible communications to Squeak, Pharo and Java. This is not an invocation bridge you speak of but a communications bridge to be able to run against Hadoop or whichever big data needs integration with (Kafka). I had hoped it might be adopted for such. Yet again this is not exactly what you were looking for but yet interesting perhaps? >>>>> >>>>> - HH >>>>> >>>>> On Thu, Oct 26, 2017 at 02:17, [phil(a)highoctane.be]("""mailto:phil@highoctane.be""") <phil(a)highoctane.be> wrote: >>>>> >>>>>> I like that piece a lot, seeing exactly the described situation in large enterprises. >>>>>> >>>>>> I made a strategic decision to go with Pharo for the long run for my solutions because it is a stable base on which to build (ok, there are evolutions, but fundamentally, I can rely on it being under control and can maintain solutions in a version). >>>>>> >>>>>> The rationale is that at a deep level I am really fed up with having to deal with accidental complexity (now having to deal with Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology drag and 20% net business contribution. >>>>>> >>>>>> One key thing is that a team needs guidance and Smalltalk makes it easier due to well known ways of doing things. >>>>>> >>>>>> Now we miss the boat on mobile and bigdata, but this is solvable. >>>>>> >>>>>> If we had an open Java bridge (and some people in the community have it for Pharo but do not open source it - so this is eminently doable) + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big executable we would have a way to embed Pharo in a lot of places (e.g. in the Hadoop ecosystem where fast starting VMs and small footprint would make the cluster capacity x2 or x3 vs uberjars all over the place) this would be a real disruption. >>>>>> >>>>>> Think about being able to call Pharo from JNA https://github.com/java-native-access/jna the same way we use C with UFFI. >>>>>> >>>>>> Smalltalk argument for me is that it makes development bearable (even fun and enjoyable would I say) vs the other stacks. That matters. >>>>>> >>>>>> Phil >>>>>> >>>>>> On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: >>>>>> >>>>>>> Thereâs other questions that are relevant to me: >>>>>>> >>>>>>> Do I give a f*** about cool looking web apps? No, I donât use web apps if in any way I can avoid it. >>>>>>> >>>>>>> Do I give a f*** about mobile apps? No, the screenâs too small to read anything longer than a twit, or anyone with anything worthwhile to say. >>>>>>> >>>>>>> Do I give a f*** about the number of libraries in other languages? No, because most of them are crap in every language Iâve had to work in, and the base languages are crap so they have to keep changing radically, and libraries and frameworks therefore also have to and never get any better. The few that are worthwhile I can almost always use from Smalltalk without a problem (read, Blender, ACT-R and Synapse, since every other library/framework Iâve used outside Smalltalk has been a waste of time). >>>>>>> >>>>>>> Do I give a f*** about implementing a complex piece of machine learning software in 22 hours, compared to 3 months for the Java version? Well, actually yes, I do, because that was 3 months of my life down the toilet for something that is too slow to be useful in Java. >>>>>>> >>>>>>> Any argument depends on your priorities. Iâve written tons of web apps, because I needed to get paid. Iâve written better shitty mobile apps than the average shitty mobile apps. However, Iâm not going to do any of that any longer in crap that never improves, because after 26 years the irritability it produces is more than itâs worth. >>>>>>> >>>>>>> A few weeks ago, a recruiter that specializes in Smalltalk called me about a job, although they were well aware I live 1500 miles away from the city I lived in when I had worked through them, to see if Iâd be willing to move back there for a job. That sounds like another âthere arenât enough Smalltalk developers", but it wasnât, because the job wasnât writing Smalltalk. It was writing Java. >>>>>>> >>>>>>> The person hiring, though, wouldnât look at anyone who didnât write Smalltalk, because "people who grew up with Java donât know how to write code". I donât agree with that, Iâve known a (very few) good Java developers. I would say, though, that Iâve known far more incompetent ones than good ones, and I canât think of any incompetent Smalltalk developers off the top of my head. >>>>>>> >>>>>>> Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or even C, complain about how hard maintaining state is or coming up with various hacks to avoid it, which seems to be the main point of every JavaScript based âtechnologyâ. An application is by definition a state-machine, which implies plenty about JS developers on the whole. >>>>>>> >>>>>>> If youâre a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why arenât there more good developers in any language? >>>>>>> >>>>>>> Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises Iâve worked for whoâve written their own dialects, and they all use it only when "shit has to work". They know itâs more productive, they also know using it for more things would increase the availability of Smalltalk developers. >>>>>>> >>>>>>> Why do they not do it? One reason, though it takes a while to recognize it, because management doesnât admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesnât âreallyâ matter, is an advantage to large enterprises because they have resources smaller competitors donât. >>>>>>> >>>>>>> Why donât their competitors do it? Because they canât see past an hourly rate, whatâs fashionable, or just new, or because their customers canât. Put more generally, average stupidity that isnât corrected by the market. Fashion affects smaller companies more than larger ones, because they canât afford a few customers walking away because they wanted an app in Electron, even if they canât give any relevant reason for wanting it, and even the samples on the Electron site donât work. >>>>>>> >>>>>>> Enterprises can, and do use Smalltalk when it matters. When it doesnât, itâs to their advantage to promote things that are inefficient, buggy and unreliable. >>>>>>> >>>>>>> Cost is relevant, but not in the simple way people look at things. A crucial but rarely mentioned perspective on its relevance is that while Java based software runs TV set top boxes, Smalltalk based software runs things like medical equipment, automated defense systems, tanks, etc. Cost becomes largely irrelevant when âshit has to workâ. >>>>>>> >>>>>>> Productivity is primarily relevant to less talented developers, in an inversely sense, since unproductive environments and attitudes have a leveling tendency in general, and more specifically make accomplishing what the less talented are capable of in any environment sufficiently laborious for them to have a role. Capability in Smalltalk, as implied by the person hiring for the Java role I mentioned, is a fairly decent means of judging whether someone is a so-so developer or a good one. >>>>>>> >>>>>>> The productivity argument is realistically only relevant in the context of an already higher hourly cost. Given that it is relevant at that point, companies that know Smalltalk is more productive would use it outside things that have to be 100%, if their own productivity were relevant to the same degree that competitorsâ productivity is inversely relevant. >>>>>>> >>>>>>> All these ways of looking at it are contingent perspectives though. Yes, if the number of libraries is relevant to you, Smalltalk is less attractive, but thatâs only a contingent phenomenon based on the relative popularity of Java and JavaScript, as a result it canât be used as explanatory for that popularity. All the ways of looking at it that are fully determinate are determinate via contingencies of that kind, which for the most part are precisely the other perspectives, including productivity, cost, availability of developers, etc. None of them is in itself anything but a result of the others. >>>>>>> >>>>>>> If availability of developers is contingent on popularity (and further, popularity contingent on industry attitudes), to use an example already mentioned in Joachimâs post, then his simultaneous posit of library availability is if anything more contingent on the same popularity, so positing it as a cause and not a result, or merely a correlate, of popularity is incoherent. We can go one step further, and demonstrate that even when large enterprises make something that works reliably available, they fail to promote and support it, which destroys the market for reliable tooling by simultaneously owning it while not promoting it, something IBM is particularly good at. But IBM canât (and if they canât, neither can any other company) operate that way without the tacit agreement of the industry. >>>>>>> >>>>>>> To understand it in a more general way, software development has to be looked at in the context where it occurs, and how itâs determined to a large degree by that context, with a specific difference. That difference is itself implicit in the context, i.e. capitalism, but only purely effective in software development. Itâs a result of virtualization as an implicit goal of capitalism, and the disruptions implicit in the virtual but so far only realized completely in software. In terms of that understanding, the analysis of virtualization and disruption as inherent to capitalism is better accomplished in Kapital than in any more recent work. >>>>>>> >>>>>>> Or you can simply decide, as Iâve done recently, that working in ways and with tools that prevent doing good work in a reasonable timeframe isnât worthwhile to you, no matter how popular those ways and tools might be, or what the posited reasons are, since at the end popularity is only insofar as it already is. What those tools and methods are depends to a degree on your priorities, but if developers are engineers those priorities canât be completely arbitrary. Engineers are defined by their ability to make things work. >>>>>>> >>>>>>> Software as virtual is inherently disruptive, and the software industry disrupts itself too often and too easily to build on anything. A further disruption caused by developers, as engineers, refusing to work with crap that doesnât, i.e. insisting on being engineers, while in itself merely an aggravation of the disruptive tendencies, might have an inverse result. >>>>>>> >>>>>>> Using a stable core of technologies as the basis for a more volatile set of products, in the way nearly every other industry does, is the best means we know of to build things both flexibly and reasonably efficiently. The computer hardware industry is the extreme example of this, while the software industry is the extreme contradiction. >>>>>>> >>>>>>> From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> on behalf of David Mason <dmason(a)ryerson.ca> >>>>>>> Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>>>>> Date: Tuesday, October 24, 2017 at 11:52 AM >>>>>>> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>>>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>>>>> >>>>>>> PharoJS is working to give you that mobile app/browser app experience. As with others, weâre not there yet, but getting there. See http://pharojs.org >>>>>>> >>>>>>> The 67% loved means that 67% of people using Smalltalk (or perhaps have ever used it) want to continue - so itâs presumably a high percentage of a smallish number of people. >>>>>>> >>>>>>> On 20 October 2017 at 03:23, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: >>>>>>> >>>>>>>> First of all: Iâd say the question itself is not a question but an excuse. I am not arguing there are enough Smalltalkers or cheap ones. But I think the question is just a way of saying "we donât want to do it for reasons that we ourselves cannot really express". If you are a good developer, learning Smalltalk is easy. If you are a good developer youâve heard the sentence "weâve taken the goos parts from x,y,z and Smalltalk" at least twice a year. So you most likely would like to learn it anyways. >>>>>>>> >>>>>>>> A shortage of developers doesnât exist. What exists is an unwillingness of companies to get people trained in a technology. If Smalltalk was cool and great in their opinion, they wouldnât care. Itâs that simple. As a consultant, Iâve heard that argument so often. Not ferom Startups, but from insurance companies, Banks or Car manufacturers who spend millions on useless, endless meetings and stuff instead of just hiring somebody to teach a couple of developers Smalltalk. Itâs just a lie: the shortage of Smalltalk developers is not a problem. >>>>>>>> >>>>>>>> And, to be honest: what is it we actually are better in by using Smalltalk? >>>>>>>> Can we build cool looking web apps in extremely short time? No. >>>>>>>> Can we build mobile Apps with little effort? No. >>>>>>>> Does our Smalltalk ship lots of great libraries for all kinds of things that are not availabel in similar quality in any other language? >>>>>>>> Are we lying when we say we are so extremely over-productive as compared to other languages? >>>>>>>> >>>>>>>> I know, all that live debugging stuff and such is great and it is much faster to find & fix a bug in Smalltalk than in any other environment Iâve used so far. But that is really only true for business code. When I need to connect to things or want to build a modern GUI or a web application with a great look&feel, I am nowhere near productive, because I simply have to build my own stuff or learn how to use other external resources. If I want to build something for a mobile device, I will only hear that somebody somewhere has done it before. No docs, no proof, no ready-made tool for me. >>>>>>>> >>>>>>>> Shortage of developers is not really the problem. If Smalltalk was as cool as we like to make ourselves believe, this problem would be non-existent. If somebody took out their iPad and told an audience: "We did this in Smalltalk in 40% of the time it would have taken in Swift", and if that something was a must-have for people, things would be much easier. But nobody has. >>>>>>>> >>>>>>>> I am absolutely over-exaggerating, because I make my living with an SaaS product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk and - as you - am convince that many parts of what weâve done so far wouldâve taken much longer or even be impossible in other languages. But the advantage was eaten by our extremely steep learning curve for web technologies and for building something that works almost as well as tools like Angular or jQuery Mobile. >>>>>>>> >>>>>>>> Smalltalk is cool, and the day somebody shows me something like Googleâs flutter in Smalltalk, I am ready to bet a lot on a bright future for Smalltalk. But until then, Iâd say these arguments about productivity are just us trying to make ourselves believe weâre still the top of the food chain. Weâve done that for almost thirty years now and still arenât ready to stop it. But weâve been lying to ourselves and still do so. >>>>>>>> >>>>>>>> I donât think there is a point in discussing about the usefulness of a language using an argument like the number or ready-made developers. That is just an argument they know you canât win. The real question is and should be: what is the benefit of using Smalltalk. Our productivity argument is a lie as soon as we have to build something that uses or runs on technology that has been invented after 1990. >>>>>>>> >>>>>>>> Okay, shoot ;-) >>>>>>>> >>>>>>>> Joachim >>>>>>>> >>>>>>>> â >>>>>>>> ââââââââââââââââââââââââ >>>>>>>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >>>>>>>> Fliederweg 1 http://www.objektfabrik.de >>>>>>>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>>>>>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

Here is a truer diagram of what I want to do. Sideways? [hubbub.jpg] - HH > -------- Original Message -------- > Subject: Re: [Pharo-users] Smalltalk Argument > Local Time: October 26, 2017 9:15 AM > UTC Time: October 26, 2017 1:15 PM > From: henry(a)callistohouse.club > To: henry <henry(a)callistohouse.club> > phil(a)highoctane.be <phil(a)highoctane.be>, Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > I think another good service to integrate well to is Elastic Search. > > Of the 4 types of integration, I vote for and step forward to volunteer to help Kerberos integration in Pharo. What to do? > > - HH > > On Thu, Oct 26, 2017 at 09:06, henry <[henry(a)callistohouse.club]("mailto:henry@callistohouse.club")> wrote: > >>> âââ Original Message âââ >>> Subject: Re: [Pharo-users] Smalltalk Argument >>> Local Time: October 26, 2017 8:52 AM >>> UTC Time: October 26, 2017 12:52 PM >>> From: henry(a)callistohouse.club >>> To: phil(a)highoctane.be <phil(a)highoctane.be>, Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>> >>> Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer. >>> >>> I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. >>> >>> Please see the attached diagram, co-locating ParrotTalk with my other components. >>> >>> ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData. >>> >>> This means you still need a Kerberos client and I need a Kerberos client. How do we start? >>> >>> - HH >>> >>> PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs. >>> >>> On Thu, Oct 26, 2017 at 03:14, phil(a)highoctane.be <[phil(a)highoctane.be](""mailto:phil@highoctane.be"")> wrote: >>> >>>> Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. >>>> >>>> How would you see ParrotTalk work? >>>> >>>> I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW >>>> >>>> See [https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…""https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…"") >>>> >>>> libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained. >>>> [https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c](""https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c"") >>>> >>>> And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support. >>>> >>>> Tell me more about your vision. Even better, draw it in some way :-) >>>> >>>> Phil >>>> >>>> On Thu, Oct 26, 2017 at 8:43 AM, henry <[henry(a)callistohouse.club](""mailto:henry@callistohouse.club"")> wrote: >>>> >>>>> This is a goal of ParrotTalk, to bring bit-compatible communications to Squeak, Pharo and Java. This is not an invocation bridge you speak of but a communications bridge to be able to run against Hadoop or whichever big data needs integration with (Kafka). I had hoped it might be adopted for such. Yet again this is not exactly what you were looking for but yet interesting perhaps? >>>>> >>>>> - HH >>>>> >>>>> On Thu, Oct 26, 2017 at 02:17, [phil(a)highoctane.be](""mailto:phil@highoctane.be"") <phil(a)highoctane.be> wrote: >>>>> >>>>>> I like that piece a lot, seeing exactly the described situation in large enterprises. >>>>>> >>>>>> I made a strategic decision to go with Pharo for the long run for my solutions because it is a stable base on which to build (ok, there are evolutions, but fundamentally, I can rely on it being under control and can maintain solutions in a version). >>>>>> >>>>>> The rationale is that at a deep level I am really fed up with having to deal with accidental complexity (now having to deal with Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology drag and 20% net business contribution. >>>>>> >>>>>> One key thing is that a team needs guidance and Smalltalk makes it easier due to well known ways of doing things. >>>>>> >>>>>> Now we miss the boat on mobile and bigdata, but this is solvable. >>>>>> >>>>>> If we had an open Java bridge (and some people in the community have it for Pharo but do not open source it - so this is eminently doable) + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big executable we would have a way to embed Pharo in a lot of places (e.g. in the Hadoop ecosystem where fast starting VMs and small footprint would make the cluster capacity x2 or x3 vs uberjars all over the place) this would be a real disruption. >>>>>> >>>>>> Think about being able to call Pharo from JNA https://github.com/java-native-access/jna the same way we use C with UFFI. >>>>>> >>>>>> Smalltalk argument for me is that it makes development bearable (even fun and enjoyable would I say) vs the other stacks. That matters. >>>>>> >>>>>> Phil >>>>>> >>>>>> On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: >>>>>> >>>>>>> Thereâs other questions that are relevant to me: >>>>>>> >>>>>>> Do I give a f*** about cool looking web apps? No, I donât use web apps if in any way I can avoid it. >>>>>>> >>>>>>> Do I give a f*** about mobile apps? No, the screenâs too small to read anything longer than a twit, or anyone with anything worthwhile to say. >>>>>>> >>>>>>> Do I give a f*** about the number of libraries in other languages? No, because most of them are crap in every language Iâve had to work in, and the base languages are crap so they have to keep changing radically, and libraries and frameworks therefore also have to and never get any better. The few that are worthwhile I can almost always use from Smalltalk without a problem (read, Blender, ACT-R and Synapse, since every other library/framework Iâve used outside Smalltalk has been a waste of time). >>>>>>> >>>>>>> Do I give a f*** about implementing a complex piece of machine learning software in 22 hours, compared to 3 months for the Java version? Well, actually yes, I do, because that was 3 months of my life down the toilet for something that is too slow to be useful in Java. >>>>>>> >>>>>>> Any argument depends on your priorities. Iâve written tons of web apps, because I needed to get paid. Iâve written better shitty mobile apps than the average shitty mobile apps. However, Iâm not going to do any of that any longer in crap that never improves, because after 26 years the irritability it produces is more than itâs worth. >>>>>>> >>>>>>> A few weeks ago, a recruiter that specializes in Smalltalk called me about a job, although they were well aware I live 1500 miles away from the city I lived in when I had worked through them, to see if Iâd be willing to move back there for a job. That sounds like another âthere arenât enough Smalltalk developers", but it wasnât, because the job wasnât writing Smalltalk. It was writing Java. >>>>>>> >>>>>>> The person hiring, though, wouldnât look at anyone who didnât write Smalltalk, because "people who grew up with Java donât know how to write code". I donât agree with that, Iâve known a (very few) good Java developers. I would say, though, that Iâve known far more incompetent ones than good ones, and I canât think of any incompetent Smalltalk developers off the top of my head. >>>>>>> >>>>>>> Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or even C, complain about how hard maintaining state is or coming up with various hacks to avoid it, which seems to be the main point of every JavaScript based âtechnologyâ. An application is by definition a state-machine, which implies plenty about JS developers on the whole. >>>>>>> >>>>>>> If youâre a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why arenât there more good developers in any language? >>>>>>> >>>>>>> Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises Iâve worked for whoâve written their own dialects, and they all use it only when "shit has to work". They know itâs more productive, they also know using it for more things would increase the availability of Smalltalk developers. >>>>>>> >>>>>>> Why do they not do it? One reason, though it takes a while to recognize it, because management doesnât admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesnât âreallyâ matter, is an advantage to large enterprises because they have resources smaller competitors donât. >>>>>>> >>>>>>> Why donât their competitors do it? Because they canât see past an hourly rate, whatâs fashionable, or just new, or because their customers canât. Put more generally, average stupidity that isnât corrected by the market. Fashion affects smaller companies more than larger ones, because they canât afford a few customers walking away because they wanted an app in Electron, even if they canât give any relevant reason for wanting it, and even the samples on the Electron site donât work. >>>>>>> >>>>>>> Enterprises can, and do use Smalltalk when it matters. When it doesnât, itâs to their advantage to promote things that are inefficient, buggy and unreliable. >>>>>>> >>>>>>> Cost is relevant, but not in the simple way people look at things. A crucial but rarely mentioned perspective on its relevance is that while Java based software runs TV set top boxes, Smalltalk based software runs things like medical equipment, automated defense systems, tanks, etc. Cost becomes largely irrelevant when âshit has to workâ. >>>>>>> >>>>>>> Productivity is primarily relevant to less talented developers, in an inversely sense, since unproductive environments and attitudes have a leveling tendency in general, and more specifically make accomplishing what the less talented are capable of in any environment sufficiently laborious for them to have a role. Capability in Smalltalk, as implied by the person hiring for the Java role I mentioned, is a fairly decent means of judging whether someone is a so-so developer or a good one. >>>>>>> >>>>>>> The productivity argument is realistically only relevant in the context of an already higher hourly cost. Given that it is relevant at that point, companies that know Smalltalk is more productive would use it outside things that have to be 100%, if their own productivity were relevant to the same degree that competitorsâ productivity is inversely relevant. >>>>>>> >>>>>>> All these ways of looking at it are contingent perspectives though. Yes, if the number of libraries is relevant to you, Smalltalk is less attractive, but thatâs only a contingent phenomenon based on the relative popularity of Java and JavaScript, as a result it canât be used as explanatory for that popularity. All the ways of looking at it that are fully determinate are determinate via contingencies of that kind, which for the most part are precisely the other perspectives, including productivity, cost, availability of developers, etc. None of them is in itself anything but a result of the others. >>>>>>> >>>>>>> If availability of developers is contingent on popularity (and further, popularity contingent on industry attitudes), to use an example already mentioned in Joachimâs post, then his simultaneous posit of library availability is if anything more contingent on the same popularity, so positing it as a cause and not a result, or merely a correlate, of popularity is incoherent. We can go one step further, and demonstrate that even when large enterprises make something that works reliably available, they fail to promote and support it, which destroys the market for reliable tooling by simultaneously owning it while not promoting it, something IBM is particularly good at. But IBM canât (and if they canât, neither can any other company) operate that way without the tacit agreement of the industry. >>>>>>> >>>>>>> To understand it in a more general way, software development has to be looked at in the context where it occurs, and how itâs determined to a large degree by that context, with a specific difference. That difference is itself implicit in the context, i.e. capitalism, but only purely effective in software development. Itâs a result of virtualization as an implicit goal of capitalism, and the disruptions implicit in the virtual but so far only realized completely in software. In terms of that understanding, the analysis of virtualization and disruption as inherent to capitalism is better accomplished in Kapital than in any more recent work. >>>>>>> >>>>>>> Or you can simply decide, as Iâve done recently, that working in ways and with tools that prevent doing good work in a reasonable timeframe isnât worthwhile to you, no matter how popular those ways and tools might be, or what the posited reasons are, since at the end popularity is only insofar as it already is. What those tools and methods are depends to a degree on your priorities, but if developers are engineers those priorities canât be completely arbitrary. Engineers are defined by their ability to make things work. >>>>>>> >>>>>>> Software as virtual is inherently disruptive, and the software industry disrupts itself too often and too easily to build on anything. A further disruption caused by developers, as engineers, refusing to work with crap that doesnât, i.e. insisting on being engineers, while in itself merely an aggravation of the disruptive tendencies, might have an inverse result. >>>>>>> >>>>>>> Using a stable core of technologies as the basis for a more volatile set of products, in the way nearly every other industry does, is the best means we know of to build things both flexibly and reasonably efficiently. The computer hardware industry is the extreme example of this, while the software industry is the extreme contradiction. >>>>>>> >>>>>>> From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> on behalf of David Mason <dmason(a)ryerson.ca> >>>>>>> Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>>>>> Date: Tuesday, October 24, 2017 at 11:52 AM >>>>>>> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>>>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>>>>> >>>>>>> PharoJS is working to give you that mobile app/browser app experience. As with others, weâre not there yet, but getting there. See http://pharojs.org >>>>>>> >>>>>>> The 67% loved means that 67% of people using Smalltalk (or perhaps have ever used it) want to continue - so itâs presumably a high percentage of a smallish number of people. >>>>>>> >>>>>>> On 20 October 2017 at 03:23, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: >>>>>>> >>>>>>>> First of all: Iâd say the question itself is not a question but an excuse. I am not arguing there are enough Smalltalkers or cheap ones. But I think the question is just a way of saying "we donât want to do it for reasons that we ourselves cannot really express". If you are a good developer, learning Smalltalk is easy. If you are a good developer youâve heard the sentence "weâve taken the goos parts from x,y,z and Smalltalk" at least twice a year. So you most likely would like to learn it anyways. >>>>>>>> >>>>>>>> A shortage of developers doesnât exist. What exists is an unwillingness of companies to get people trained in a technology. If Smalltalk was cool and great in their opinion, they wouldnât care. Itâs that simple. As a consultant, Iâve heard that argument so often. Not ferom Startups, but from insurance companies, Banks or Car manufacturers who spend millions on useless, endless meetings and stuff instead of just hiring somebody to teach a couple of developers Smalltalk. Itâs just a lie: the shortage of Smalltalk developers is not a problem. >>>>>>>> >>>>>>>> And, to be honest: what is it we actually are better in by using Smalltalk? >>>>>>>> Can we build cool looking web apps in extremely short time? No. >>>>>>>> Can we build mobile Apps with little effort? No. >>>>>>>> Does our Smalltalk ship lots of great libraries for all kinds of things that are not availabel in similar quality in any other language? >>>>>>>> Are we lying when we say we are so extremely over-productive as compared to other languages? >>>>>>>> >>>>>>>> I know, all that live debugging stuff and such is great and it is much faster to find & fix a bug in Smalltalk than in any other environment Iâve used so far. But that is really only true for business code. When I need to connect to things or want to build a modern GUI or a web application with a great look&feel, I am nowhere near productive, because I simply have to build my own stuff or learn how to use other external resources. If I want to build something for a mobile device, I will only hear that somebody somewhere has done it before. No docs, no proof, no ready-made tool for me. >>>>>>>> >>>>>>>> Shortage of developers is not really the problem. If Smalltalk was as cool as we like to make ourselves believe, this problem would be non-existent. If somebody took out their iPad and told an audience: "We did this in Smalltalk in 40% of the time it would have taken in Swift", and if that something was a must-have for people, things would be much easier. But nobody has. >>>>>>>> >>>>>>>> I am absolutely over-exaggerating, because I make my living with an SaaS product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk and - as you - am convince that many parts of what weâve done so far wouldâve taken much longer or even be impossible in other languages. But the advantage was eaten by our extremely steep learning curve for web technologies and for building something that works almost as well as tools like Angular or jQuery Mobile. >>>>>>>> >>>>>>>> Smalltalk is cool, and the day somebody shows me something like Googleâs flutter in Smalltalk, I am ready to bet a lot on a bright future for Smalltalk. But until then, Iâd say these arguments about productivity are just us trying to make ourselves believe weâre still the top of the food chain. Weâve done that for almost thirty years now and still arenât ready to stop it. But weâve been lying to ourselves and still do so. >>>>>>>> >>>>>>>> I donât think there is a point in discussing about the usefulness of a language using an argument like the number or ready-made developers. That is just an argument they know you canât win. The real question is and should be: what is the benefit of using Smalltalk. Our productivity argument is a lie as soon as we have to build something that uses or runs on technology that has been invented after 1990. >>>>>>>> >>>>>>>> Okay, shoot ;-) >>>>>>>> >>>>>>>> Joachim >>>>>>>> >>>>>>>> â >>>>>>>> ââââââââââââââââââââââââ >>>>>>>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >>>>>>>> Fliederweg 1 http://www.objektfabrik.de >>>>>>>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>>>>>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Oct. 26, 2017

Re: [Pharo-users] Annual online conference?

by Dimitris Chloupis

indeed excellent idea Having a polished website like they did, is the way to go. +1 On Thu, Oct 26, 2017 at 11:54 AM Tudor Girba <tudor(a)tudorgirba.com> wrote: > Nice idea, indeed. > > Doru > > > > On Oct 26, 2017, at 10:18 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > > > > Thatâs a nice idea! > > > > I will check how they did it and we should see if that makes sense in > the future. > > (for Pharo Days) > > > > Marcus > > > >> On 25 Oct 2017, at 23:17, PAUL DEBRUICKER <pdebruic(a)gmail.com> wrote: > >> > >> Laravel.com is a PHP web framework. > >> > >> > >> Their community organizes an online conference: > https://laracon.net/2017 > >> > >> > >> Seems like it could be worthy of mimicking in the Smalltalk community. > >> > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > > > >

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

I think another good service to integrate well to is Elastic Search. Of the 4 types of integration, I vote for and step forward to volunteer to help Kerberos integration in Pharo. What to do? - HH On Thu, Oct 26, 2017 at 09:06, henry <[henry(a)callistohouse.club]("mailto:henry@callistohouse.club")> wrote: > I try posting with a smaller image. > > ["hubbub.jpg"] > > - HH > >> âââ Original Message âââ >> Subject: Re: [Pharo-users] Smalltalk Argument >> Local Time: October 26, 2017 8:52 AM >> UTC Time: October 26, 2017 12:52 PM >> From: henry(a)callistohouse.club >> To: phil(a)highoctane.be <phil(a)highoctane.be>, Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >> >> Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer. >> >> I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. >> >> Please see the attached diagram, co-locating ParrotTalk with my other components. >> >> ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData. >> >> This means you still need a Kerberos client and I need a Kerberos client. How do we start? >> >> - HH >> >> PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs. >> >> On Thu, Oct 26, 2017 at 03:14, phil(a)highoctane.be <[phil(a)highoctane.be](""mailto:phil@highoctane.be"")> wrote: >> >>> Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. >>> >>> How would you see ParrotTalk work? >>> >>> I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW >>> >>> See [https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…""https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…"") >>> >>> libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained. >>> [https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c](""https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c"") >>> >>> And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support. >>> >>> Tell me more about your vision. Even better, draw it in some way :-) >>> >>> Phil >>> >>> On Thu, Oct 26, 2017 at 8:43 AM, henry <[henry(a)callistohouse.club](""mailto:henry@callistohouse.club"")> wrote: >>> >>>> This is a goal of ParrotTalk, to bring bit-compatible communications to Squeak, Pharo and Java. This is not an invocation bridge you speak of but a communications bridge to be able to run against Hadoop or whichever big data needs integration with (Kafka). I had hoped it might be adopted for such. Yet again this is not exactly what you were looking for but yet interesting perhaps? >>>> >>>> - HH >>>> >>>> On Thu, Oct 26, 2017 at 02:17, [phil(a)highoctane.be](""mailto:phil@highoctane.be"") <phil(a)highoctane.be> wrote: >>>> >>>>> I like that piece a lot, seeing exactly the described situation in large enterprises. >>>>> >>>>> I made a strategic decision to go with Pharo for the long run for my solutions because it is a stable base on which to build (ok, there are evolutions, but fundamentally, I can rely on it being under control and can maintain solutions in a version). >>>>> >>>>> The rationale is that at a deep level I am really fed up with having to deal with accidental complexity (now having to deal with Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology drag and 20% net business contribution. >>>>> >>>>> One key thing is that a team needs guidance and Smalltalk makes it easier due to well known ways of doing things. >>>>> >>>>> Now we miss the boat on mobile and bigdata, but this is solvable. >>>>> >>>>> If we had an open Java bridge (and some people in the community have it for Pharo but do not open source it - so this is eminently doable) + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big executable we would have a way to embed Pharo in a lot of places (e.g. in the Hadoop ecosystem where fast starting VMs and small footprint would make the cluster capacity x2 or x3 vs uberjars all over the place) this would be a real disruption. >>>>> >>>>> Think about being able to call Pharo from JNA https://github.com/java-native-access/jna the same way we use C with UFFI. >>>>> >>>>> Smalltalk argument for me is that it makes development bearable (even fun and enjoyable would I say) vs the other stacks. That matters. >>>>> >>>>> Phil >>>>> >>>>> On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: >>>>> >>>>>> Thereâs other questions that are relevant to me: >>>>>> >>>>>> Do I give a f*** about cool looking web apps? No, I donât use web apps if in any way I can avoid it. >>>>>> >>>>>> Do I give a f*** about mobile apps? No, the screenâs too small to read anything longer than a twit, or anyone with anything worthwhile to say. >>>>>> >>>>>> Do I give a f*** about the number of libraries in other languages? No, because most of them are crap in every language Iâve had to work in, and the base languages are crap so they have to keep changing radically, and libraries and frameworks therefore also have to and never get any better. The few that are worthwhile I can almost always use from Smalltalk without a problem (read, Blender, ACT-R and Synapse, since every other library/framework Iâve used outside Smalltalk has been a waste of time). >>>>>> >>>>>> Do I give a f*** about implementing a complex piece of machine learning software in 22 hours, compared to 3 months for the Java version? Well, actually yes, I do, because that was 3 months of my life down the toilet for something that is too slow to be useful in Java. >>>>>> >>>>>> Any argument depends on your priorities. Iâve written tons of web apps, because I needed to get paid. Iâve written better shitty mobile apps than the average shitty mobile apps. However, Iâm not going to do any of that any longer in crap that never improves, because after 26 years the irritability it produces is more than itâs worth. >>>>>> >>>>>> A few weeks ago, a recruiter that specializes in Smalltalk called me about a job, although they were well aware I live 1500 miles away from the city I lived in when I had worked through them, to see if Iâd be willing to move back there for a job. That sounds like another âthere arenât enough Smalltalk developers", but it wasnât, because the job wasnât writing Smalltalk. It was writing Java. >>>>>> >>>>>> The person hiring, though, wouldnât look at anyone who didnât write Smalltalk, because "people who grew up with Java donât know how to write code". I donât agree with that, Iâve known a (very few) good Java developers. I would say, though, that Iâve known far more incompetent ones than good ones, and I canât think of any incompetent Smalltalk developers off the top of my head. >>>>>> >>>>>> Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or even C, complain about how hard maintaining state is or coming up with various hacks to avoid it, which seems to be the main point of every JavaScript based âtechnologyâ. An application is by definition a state-machine, which implies plenty about JS developers on the whole. >>>>>> >>>>>> If youâre a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why arenât there more good developers in any language? >>>>>> >>>>>> Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises Iâve worked for whoâve written their own dialects, and they all use it only when "shit has to work". They know itâs more productive, they also know using it for more things would increase the availability of Smalltalk developers. >>>>>> >>>>>> Why do they not do it? One reason, though it takes a while to recognize it, because management doesnât admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesnât âreallyâ matter, is an advantage to large enterprises because they have resources smaller competitors donât. >>>>>> >>>>>> Why donât their competitors do it? Because they canât see past an hourly rate, whatâs fashionable, or just new, or because their customers canât. Put more generally, average stupidity that isnât corrected by the market. Fashion affects smaller companies more than larger ones, because they canât afford a few customers walking away because they wanted an app in Electron, even if they canât give any relevant reason for wanting it, and even the samples on the Electron site donât work. >>>>>> >>>>>> Enterprises can, and do use Smalltalk when it matters. When it doesnât, itâs to their advantage to promote things that are inefficient, buggy and unreliable. >>>>>> >>>>>> Cost is relevant, but not in the simple way people look at things. A crucial but rarely mentioned perspective on its relevance is that while Java based software runs TV set top boxes, Smalltalk based software runs things like medical equipment, automated defense systems, tanks, etc. Cost becomes largely irrelevant when âshit has to workâ. >>>>>> >>>>>> Productivity is primarily relevant to less talented developers, in an inversely sense, since unproductive environments and attitudes have a leveling tendency in general, and more specifically make accomplishing what the less talented are capable of in any environment sufficiently laborious for them to have a role. Capability in Smalltalk, as implied by the person hiring for the Java role I mentioned, is a fairly decent means of judging whether someone is a so-so developer or a good one. >>>>>> >>>>>> The productivity argument is realistically only relevant in the context of an already higher hourly cost. Given that it is relevant at that point, companies that know Smalltalk is more productive would use it outside things that have to be 100%, if their own productivity were relevant to the same degree that competitorsâ productivity is inversely relevant. >>>>>> >>>>>> All these ways of looking at it are contingent perspectives though. Yes, if the number of libraries is relevant to you, Smalltalk is less attractive, but thatâs only a contingent phenomenon based on the relative popularity of Java and JavaScript, as a result it canât be used as explanatory for that popularity. All the ways of looking at it that are fully determinate are determinate via contingencies of that kind, which for the most part are precisely the other perspectives, including productivity, cost, availability of developers, etc. None of them is in itself anything but a result of the others. >>>>>> >>>>>> If availability of developers is contingent on popularity (and further, popularity contingent on industry attitudes), to use an example already mentioned in Joachimâs post, then his simultaneous posit of library availability is if anything more contingent on the same popularity, so positing it as a cause and not a result, or merely a correlate, of popularity is incoherent. We can go one step further, and demonstrate that even when large enterprises make something that works reliably available, they fail to promote and support it, which destroys the market for reliable tooling by simultaneously owning it while not promoting it, something IBM is particularly good at. But IBM canât (and if they canât, neither can any other company) operate that way without the tacit agreement of the industry. >>>>>> >>>>>> To understand it in a more general way, software development has to be looked at in the context where it occurs, and how itâs determined to a large degree by that context, with a specific difference. That difference is itself implicit in the context, i.e. capitalism, but only purely effective in software development. Itâs a result of virtualization as an implicit goal of capitalism, and the disruptions implicit in the virtual but so far only realized completely in software. In terms of that understanding, the analysis of virtualization and disruption as inherent to capitalism is better accomplished in Kapital than in any more recent work. >>>>>> >>>>>> Or you can simply decide, as Iâve done recently, that working in ways and with tools that prevent doing good work in a reasonable timeframe isnât worthwhile to you, no matter how popular those ways and tools might be, or what the posited reasons are, since at the end popularity is only insofar as it already is. What those tools and methods are depends to a degree on your priorities, but if developers are engineers those priorities canât be completely arbitrary. Engineers are defined by their ability to make things work. >>>>>> >>>>>> Software as virtual is inherently disruptive, and the software industry disrupts itself too often and too easily to build on anything. A further disruption caused by developers, as engineers, refusing to work with crap that doesnât, i.e. insisting on being engineers, while in itself merely an aggravation of the disruptive tendencies, might have an inverse result. >>>>>> >>>>>> Using a stable core of technologies as the basis for a more volatile set of products, in the way nearly every other industry does, is the best means we know of to build things both flexibly and reasonably efficiently. The computer hardware industry is the extreme example of this, while the software industry is the extreme contradiction. >>>>>> >>>>>> From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> on behalf of David Mason <dmason(a)ryerson.ca> >>>>>> Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>>>> Date: Tuesday, October 24, 2017 at 11:52 AM >>>>>> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>>>> >>>>>> PharoJS is working to give you that mobile app/browser app experience. As with others, weâre not there yet, but getting there. See http://pharojs.org >>>>>> >>>>>> The 67% loved means that 67% of people using Smalltalk (or perhaps have ever used it) want to continue - so itâs presumably a high percentage of a smallish number of people. >>>>>> >>>>>> On 20 October 2017 at 03:23, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: >>>>>> >>>>>>> First of all: Iâd say the question itself is not a question but an excuse. I am not arguing there are enough Smalltalkers or cheap ones. But I think the question is just a way of saying "we donât want to do it for reasons that we ourselves cannot really express". If you are a good developer, learning Smalltalk is easy. If you are a good developer youâve heard the sentence "weâve taken the goos parts from x,y,z and Smalltalk" at least twice a year. So you most likely would like to learn it anyways. >>>>>>> >>>>>>> A shortage of developers doesnât exist. What exists is an unwillingness of companies to get people trained in a technology. If Smalltalk was cool and great in their opinion, they wouldnât care. Itâs that simple. As a consultant, Iâve heard that argument so often. Not ferom Startups, but from insurance companies, Banks or Car manufacturers who spend millions on useless, endless meetings and stuff instead of just hiring somebody to teach a couple of developers Smalltalk. Itâs just a lie: the shortage of Smalltalk developers is not a problem. >>>>>>> >>>>>>> And, to be honest: what is it we actually are better in by using Smalltalk? >>>>>>> Can we build cool looking web apps in extremely short time? No. >>>>>>> Can we build mobile Apps with little effort? No. >>>>>>> Does our Smalltalk ship lots of great libraries for all kinds of things that are not availabel in similar quality in any other language? >>>>>>> Are we lying when we say we are so extremely over-productive as compared to other languages? >>>>>>> >>>>>>> I know, all that live debugging stuff and such is great and it is much faster to find & fix a bug in Smalltalk than in any other environment Iâve used so far. But that is really only true for business code. When I need to connect to things or want to build a modern GUI or a web application with a great look&feel, I am nowhere near productive, because I simply have to build my own stuff or learn how to use other external resources. If I want to build something for a mobile device, I will only hear that somebody somewhere has done it before. No docs, no proof, no ready-made tool for me. >>>>>>> >>>>>>> Shortage of developers is not really the problem. If Smalltalk was as cool as we like to make ourselves believe, this problem would be non-existent. If somebody took out their iPad and told an audience: "We did this in Smalltalk in 40% of the time it would have taken in Swift", and if that something was a must-have for people, things would be much easier. But nobody has. >>>>>>> >>>>>>> I am absolutely over-exaggerating, because I make my living with an SaaS product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk and - as you - am convince that many parts of what weâve done so far wouldâve taken much longer or even be impossible in other languages. But the advantage was eaten by our extremely steep learning curve for web technologies and for building something that works almost as well as tools like Angular or jQuery Mobile. >>>>>>> >>>>>>> Smalltalk is cool, and the day somebody shows me something like Googleâs flutter in Smalltalk, I am ready to bet a lot on a bright future for Smalltalk. But until then, Iâd say these arguments about productivity are just us trying to make ourselves believe weâre still the top of the food chain. Weâve done that for almost thirty years now and still arenât ready to stop it. But weâve been lying to ourselves and still do so. >>>>>>> >>>>>>> I donât think there is a point in discussing about the usefulness of a language using an argument like the number or ready-made developers. That is just an argument they know you canât win. The real question is and should be: what is the benefit of using Smalltalk. Our productivity argument is a lie as soon as we have to build something that uses or runs on technology that has been invented after 1990. >>>>>>> >>>>>>> Okay, shoot ;-) >>>>>>> >>>>>>> Joachim >>>>>>> >>>>>>> â >>>>>>> ââââââââââââââââââââââââ >>>>>>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >>>>>>> Fliederweg 1 http://www.objektfabrik.de >>>>>>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>>>>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

I try posting with a smaller image. [hubbub.jpg] - HH > -------- Original Message -------- > Subject: Re: [Pharo-users] Smalltalk Argument > Local Time: October 26, 2017 8:52 AM > UTC Time: October 26, 2017 12:52 PM > From: henry(a)callistohouse.club > To: phil(a)highoctane.be <phil(a)highoctane.be>, Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer. > > I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. > > Please see the attached diagram, co-locating ParrotTalk with my other components. > > ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData. > > This means you still need a Kerberos client and I need a Kerberos client. How do we start? > > - HH > > PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs. > > On Thu, Oct 26, 2017 at 03:14, phil(a)highoctane.be <[phil(a)highoctane.be]("mailto:phil@highoctane.be")> wrote: > >> Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. >> >> How would you see ParrotTalk work? >> >> I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW >> >> See [https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…"https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…") >> >> libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained. >> [https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c]("https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c") >> >> And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support. >> >> Tell me more about your vision. Even better, draw it in some way :-) >> >> Phil >> >> On Thu, Oct 26, 2017 at 8:43 AM, henry <[henry(a)callistohouse.club]("mailto:henry@callistohouse.club")> wrote: >> >>> This is a goal of ParrotTalk, to bring bit-compatible communications to Squeak, Pharo and Java. This is not an invocation bridge you speak of but a communications bridge to be able to run against Hadoop or whichever big data needs integration with (Kafka). I had hoped it might be adopted for such. Yet again this is not exactly what you were looking for but yet interesting perhaps? >>> >>> - HH >>> >>> On Thu, Oct 26, 2017 at 02:17, [phil(a)highoctane.be]("mailto:phil@highoctane.be") <phil(a)highoctane.be> wrote: >>> >>>> I like that piece a lot, seeing exactly the described situation in large enterprises. >>>> >>>> I made a strategic decision to go with Pharo for the long run for my solutions because it is a stable base on which to build (ok, there are evolutions, but fundamentally, I can rely on it being under control and can maintain solutions in a version). >>>> >>>> The rationale is that at a deep level I am really fed up with having to deal with accidental complexity (now having to deal with Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology drag and 20% net business contribution. >>>> >>>> One key thing is that a team needs guidance and Smalltalk makes it easier due to well known ways of doing things. >>>> >>>> Now we miss the boat on mobile and bigdata, but this is solvable. >>>> >>>> If we had an open Java bridge (and some people in the community have it for Pharo but do not open source it - so this is eminently doable) + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big executable we would have a way to embed Pharo in a lot of places (e.g. in the Hadoop ecosystem where fast starting VMs and small footprint would make the cluster capacity x2 or x3 vs uberjars all over the place) this would be a real disruption. >>>> >>>> Think about being able to call Pharo from JNA https://github.com/java-native-access/jna the same way we use C with UFFI. >>>> >>>> Smalltalk argument for me is that it makes development bearable (even fun and enjoyable would I say) vs the other stacks. That matters. >>>> >>>> Phil >>>> >>>> On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: >>>> >>>>> Thereâs other questions that are relevant to me: >>>>> >>>>> Do I give a f*** about cool looking web apps? No, I donât use web apps if in any way I can avoid it. >>>>> >>>>> Do I give a f*** about mobile apps? No, the screenâs too small to read anything longer than a twit, or anyone with anything worthwhile to say. >>>>> >>>>> Do I give a f*** about the number of libraries in other languages? No, because most of them are crap in every language Iâve had to work in, and the base languages are crap so they have to keep changing radically, and libraries and frameworks therefore also have to and never get any better. The few that are worthwhile I can almost always use from Smalltalk without a problem (read, Blender, ACT-R and Synapse, since every other library/framework Iâve used outside Smalltalk has been a waste of time). >>>>> >>>>> Do I give a f*** about implementing a complex piece of machine learning software in 22 hours, compared to 3 months for the Java version? Well, actually yes, I do, because that was 3 months of my life down the toilet for something that is too slow to be useful in Java. >>>>> >>>>> Any argument depends on your priorities. Iâve written tons of web apps, because I needed to get paid. Iâve written better shitty mobile apps than the average shitty mobile apps. However, Iâm not going to do any of that any longer in crap that never improves, because after 26 years the irritability it produces is more than itâs worth. >>>>> >>>>> A few weeks ago, a recruiter that specializes in Smalltalk called me about a job, although they were well aware I live 1500 miles away from the city I lived in when I had worked through them, to see if Iâd be willing to move back there for a job. That sounds like another âthere arenât enough Smalltalk developers", but it wasnât, because the job wasnât writing Smalltalk. It was writing Java. >>>>> >>>>> The person hiring, though, wouldnât look at anyone who didnât write Smalltalk, because "people who grew up with Java donât know how to write code". I donât agree with that, Iâve known a (very few) good Java developers. I would say, though, that Iâve known far more incompetent ones than good ones, and I canât think of any incompetent Smalltalk developers off the top of my head. >>>>> >>>>> Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or even C, complain about how hard maintaining state is or coming up with various hacks to avoid it, which seems to be the main point of every JavaScript based âtechnologyâ. An application is by definition a state-machine, which implies plenty about JS developers on the whole. >>>>> >>>>> If youâre a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why arenât there more good developers in any language? >>>>> >>>>> Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises Iâve worked for whoâve written their own dialects, and they all use it only when "shit has to work". They know itâs more productive, they also know using it for more things would increase the availability of Smalltalk developers. >>>>> >>>>> Why do they not do it? One reason, though it takes a while to recognize it, because management doesnât admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesnât âreallyâ matter, is an advantage to large enterprises because they have resources smaller competitors donât. >>>>> >>>>> Why donât their competitors do it? Because they canât see past an hourly rate, whatâs fashionable, or just new, or because their customers canât. Put more generally, average stupidity that isnât corrected by the market. Fashion affects smaller companies more than larger ones, because they canât afford a few customers walking away because they wanted an app in Electron, even if they canât give any relevant reason for wanting it, and even the samples on the Electron site donât work. >>>>> >>>>> Enterprises can, and do use Smalltalk when it matters. When it doesnât, itâs to their advantage to promote things that are inefficient, buggy and unreliable. >>>>> >>>>> Cost is relevant, but not in the simple way people look at things. A crucial but rarely mentioned perspective on its relevance is that while Java based software runs TV set top boxes, Smalltalk based software runs things like medical equipment, automated defense systems, tanks, etc. Cost becomes largely irrelevant when âshit has to workâ. >>>>> >>>>> Productivity is primarily relevant to less talented developers, in an inversely sense, since unproductive environments and attitudes have a leveling tendency in general, and more specifically make accomplishing what the less talented are capable of in any environment sufficiently laborious for them to have a role. Capability in Smalltalk, as implied by the person hiring for the Java role I mentioned, is a fairly decent means of judging whether someone is a so-so developer or a good one. >>>>> >>>>> The productivity argument is realistically only relevant in the context of an already higher hourly cost. Given that it is relevant at that point, companies that know Smalltalk is more productive would use it outside things that have to be 100%, if their own productivity were relevant to the same degree that competitorsâ productivity is inversely relevant. >>>>> >>>>> All these ways of looking at it are contingent perspectives though. Yes, if the number of libraries is relevant to you, Smalltalk is less attractive, but thatâs only a contingent phenomenon based on the relative popularity of Java and JavaScript, as a result it canât be used as explanatory for that popularity. All the ways of looking at it that are fully determinate are determinate via contingencies of that kind, which for the most part are precisely the other perspectives, including productivity, cost, availability of developers, etc. None of them is in itself anything but a result of the others. >>>>> >>>>> If availability of developers is contingent on popularity (and further, popularity contingent on industry attitudes), to use an example already mentioned in Joachimâs post, then his simultaneous posit of library availability is if anything more contingent on the same popularity, so positing it as a cause and not a result, or merely a correlate, of popularity is incoherent. We can go one step further, and demonstrate that even when large enterprises make something that works reliably available, they fail to promote and support it, which destroys the market for reliable tooling by simultaneously owning it while not promoting it, something IBM is particularly good at. But IBM canât (and if they canât, neither can any other company) operate that way without the tacit agreement of the industry. >>>>> >>>>> To understand it in a more general way, software development has to be looked at in the context where it occurs, and how itâs determined to a large degree by that context, with a specific difference. That difference is itself implicit in the context, i.e. capitalism, but only purely effective in software development. Itâs a result of virtualization as an implicit goal of capitalism, and the disruptions implicit in the virtual but so far only realized completely in software. In terms of that understanding, the analysis of virtualization and disruption as inherent to capitalism is better accomplished in Kapital than in any more recent work. >>>>> >>>>> Or you can simply decide, as Iâve done recently, that working in ways and with tools that prevent doing good work in a reasonable timeframe isnât worthwhile to you, no matter how popular those ways and tools might be, or what the posited reasons are, since at the end popularity is only insofar as it already is. What those tools and methods are depends to a degree on your priorities, but if developers are engineers those priorities canât be completely arbitrary. Engineers are defined by their ability to make things work. >>>>> >>>>> Software as virtual is inherently disruptive, and the software industry disrupts itself too often and too easily to build on anything. A further disruption caused by developers, as engineers, refusing to work with crap that doesnât, i.e. insisting on being engineers, while in itself merely an aggravation of the disruptive tendencies, might have an inverse result. >>>>> >>>>> Using a stable core of technologies as the basis for a more volatile set of products, in the way nearly every other industry does, is the best means we know of to build things both flexibly and reasonably efficiently. The computer hardware industry is the extreme example of this, while the software industry is the extreme contradiction. >>>>> >>>>> From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> on behalf of David Mason <dmason(a)ryerson.ca> >>>>> Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>>> Date: Tuesday, October 24, 2017 at 11:52 AM >>>>> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>>> >>>>> PharoJS is working to give you that mobile app/browser app experience. As with others, we're not there yet, but getting there. See http://pharojs.org >>>>> >>>>> The 67% loved means that 67% of people using Smalltalk (or perhaps have ever used it) want to continue - so it's presumably a high percentage of a smallish number of people. >>>>> >>>>> On 20 October 2017 at 03:23, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: >>>>> >>>>>> First of all: I'd say the question itself is not a question but an excuse. I am not arguing there are enough Smalltalkers or cheap ones. But I think the question is just a way of saying "we don't want to do it for reasons that we ourselves cannot really express". If you are a good developer, learning Smalltalk is easy. If you are a good developer you've heard the sentence "we've taken the goos parts from x,y,z and Smalltalk" at least twice a year. So you most likely would like to learn it anyways. >>>>>> >>>>>> A shortage of developers doesn't exist. What exists is an unwillingness of companies to get people trained in a technology. If Smalltalk was cool and great in their opinion, they wouldn't care. It's that simple. As a consultant, I've heard that argument so often. Not ferom Startups, but from insurance companies, Banks or Car manufacturers who spend millions on useless, endless meetings and stuff instead of just hiring somebody to teach a couple of developers Smalltalk. It's just a lie: the shortage of Smalltalk developers is not a problem. >>>>>> >>>>>> And, to be honest: what is it we actually are better in by using Smalltalk? >>>>>> Can we build cool looking web apps in extremely short time? No. >>>>>> Can we build mobile Apps with little effort? No. >>>>>> Does our Smalltalk ship lots of great libraries for all kinds of things that are not availabel in similar quality in any other language? >>>>>> Are we lying when we say we are so extremely over-productive as compared to other languages? >>>>>> >>>>>> I know, all that live debugging stuff and such is great and it is much faster to find & fix a bug in Smalltalk than in any other environment I've used so far. But that is really only true for business code. When I need to connect to things or want to build a modern GUI or a web application with a great look&feel, I am nowhere near productive, because I simply have to build my own stuff or learn how to use other external resources. If I want to build something for a mobile device, I will only hear that somebody somewhere has done it before. No docs, no proof, no ready-made tool for me. >>>>>> >>>>>> Shortage of developers is not really the problem. If Smalltalk was as cool as we like to make ourselves believe, this problem would be non-existent. If somebody took out their iPad and told an audience: "We did this in Smalltalk in 40% of the time it would have taken in Swift", and if that something was a must-have for people, things would be much easier. But nobody has. >>>>>> >>>>>> I am absolutely over-exaggerating, because I make my living with an SaaS product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk and - as you - am convince that many parts of what we've done so far would've taken much longer or even be impossible in other languages. But the advantage was eaten by our extremely steep learning curve for web technologies and for building something that works almost as well as tools like Angular or jQuery Mobile. >>>>>> >>>>>> Smalltalk is cool, and the day somebody shows me something like Google's flutter in Smalltalk, I am ready to bet a lot on a bright future for Smalltalk. But until then, I'd say these arguments about productivity are just us trying to make ourselves believe we're still the top of the food chain. We've done that for almost thirty years now and still aren't ready to stop it. But we've been lying to ourselves and still do so. >>>>>> >>>>>> I don't think there is a point in discussing about the usefulness of a language using an argument like the number or ready-made developers. That is just an argument they know you can't win. The real question is and should be: what is the benefit of using Smalltalk. Our productivity argument is a lie as soon as we have to build something that uses or runs on technology that has been invented after 1990. >>>>>> >>>>>> Okay, shoot ;-) >>>>>> >>>>>> Joachim >>>>>> >>>>>> â >>>>>> ââââââââââââââââââââââââ >>>>>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >>>>>> Fliederweg 1 http://www.objektfabrik.de >>>>>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>>>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by Dimitris Chloupis

Well all languages have well designed and badly designed libraries , in Pharo you dont even have to look hard just take a look at Morph and Object class and awe at all those irrelevant methods trying to cram in features you will probably never use. Especially my experience with Morphic has been as nightmarish as my experience with MFC. And MFC is a C++ library and made by Microsoft. On the other hand QT is a brilliantly designed GUI API (again for C++) and dont even get me started on DELPHI libraries which to this day I consider top when it comes to OO libraries. together with its IDE (but I never liked its language). Web dev may be a messy field mainly because it has grown too fast, after the web explosion , based on problematic concepts but desktop libraries and as a consequence mobile dev libraries (iOS is a variable of MacoOS, Android a variant of Linux) in a much , much better position and some of them have stellar designs. Mainly because are far more mature with decades of extremely active development. Of course many of those great design are the result of a reaction to bad designs and lessons learned from other APIs. There is no good design without a redesign. 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. On Thu, Oct 26, 2017 at 3:14 PM jtuchel(a)objektfabrik.de < jtuchel(a)objektfabrik.de> wrote: > 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> > <pharo-users-bounces(a)lists.pharo.org> on behalf of David Mason > <dmason(a)ryerson.ca> <dmason(a)ryerson.ca> > *Reply-To: *Any question about pharo is welcome > <pharo-users(a)lists.pharo.org> <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> > <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 <%2B49%207141%2056%2010%2086%200> > Fax: +49 7141 56 10 86 1 <%2B49%207141%2056%2010%2086%201> > > > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <jtuchel(a)objektfabrik.de> > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > >

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer. I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. Please see the attached diagram, co-locating ParrotTalk with my other components. ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData. This means you still need a Kerberos client and I need a Kerberos client. How do we start? - HH PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs. On Thu, Oct 26, 2017 at 03:14, phil(a)highoctane.be <[phil(a)highoctane.be]("mailto:phil@highoctane.be")> wrote: > Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. > > How would you see ParrotTalk work? > > I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW > > See [https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…"https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1…") > > libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained. > [https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c]("https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c") > > And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support. > > Tell me more about your vision. Even better, draw it in some way :-) > > Phil > > On Thu, Oct 26, 2017 at 8:43 AM, henry <[henry(a)callistohouse.club]("mailto:henry@callistohouse.club")> wrote: > >> This is a goal of ParrotTalk, to bring bit-compatible communications to Squeak, Pharo and Java. This is not an invocation bridge you speak of but a communications bridge to be able to run against Hadoop or whichever big data needs integration with (Kafka). I had hoped it might be adopted for such. Yet again this is not exactly what you were looking for but yet interesting perhaps? >> >> - HH >> >> On Thu, Oct 26, 2017 at 02:17, [phil(a)highoctane.be]("mailto:phil@highoctane.be") <phil(a)highoctane.be> wrote: >> >>> I like that piece a lot, seeing exactly the described situation in large enterprises. >>> >>> I made a strategic decision to go with Pharo for the long run for my solutions because it is a stable base on which to build (ok, there are evolutions, but fundamentally, I can rely on it being under control and can maintain solutions in a version). >>> >>> The rationale is that at a deep level I am really fed up with having to deal with accidental complexity (now having to deal with Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology drag and 20% net business contribution. >>> >>> One key thing is that a team needs guidance and Smalltalk makes it easier due to well known ways of doing things. >>> >>> Now we miss the boat on mobile and bigdata, but this is solvable. >>> >>> If we had an open Java bridge (and some people in the community have it for Pharo but do not open source it - so this is eminently doable) + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big executable we would have a way to embed Pharo in a lot of places (e.g. in the Hadoop ecosystem where fast starting VMs and small footprint would make the cluster capacity x2 or x3 vs uberjars all over the place) this would be a real disruption. >>> >>> Think about being able to call Pharo from JNA https://github.com/java-native-access/jna the same way we use C with UFFI. >>> >>> Smalltalk argument for me is that it makes development bearable (even fun and enjoyable would I say) vs the other stacks. That matters. >>> >>> Phil >>> >>> On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: >>> >>>> Thereâs other questions that are relevant to me: >>>> >>>> Do I give a f*** about cool looking web apps? No, I donât use web apps if in any way I can avoid it. >>>> >>>> Do I give a f*** about mobile apps? No, the screenâs too small to read anything longer than a twit, or anyone with anything worthwhile to say. >>>> >>>> Do I give a f*** about the number of libraries in other languages? No, because most of them are crap in every language Iâve had to work in, and the base languages are crap so they have to keep changing radically, and libraries and frameworks therefore also have to and never get any better. The few that are worthwhile I can almost always use from Smalltalk without a problem (read, Blender, ACT-R and Synapse, since every other library/framework Iâve used outside Smalltalk has been a waste of time). >>>> >>>> Do I give a f*** about implementing a complex piece of machine learning software in 22 hours, compared to 3 months for the Java version? Well, actually yes, I do, because that was 3 months of my life down the toilet for something that is too slow to be useful in Java. >>>> >>>> Any argument depends on your priorities. Iâve written tons of web apps, because I needed to get paid. Iâve written better shitty mobile apps than the average shitty mobile apps. However, Iâm not going to do any of that any longer in crap that never improves, because after 26 years the irritability it produces is more than itâs worth. >>>> >>>> A few weeks ago, a recruiter that specializes in Smalltalk called me about a job, although they were well aware I live 1500 miles away from the city I lived in when I had worked through them, to see if Iâd be willing to move back there for a job. That sounds like another âthere arenât enough Smalltalk developers", but it wasnât, because the job wasnât writing Smalltalk. It was writing Java. >>>> >>>> The person hiring, though, wouldnât look at anyone who didnât write Smalltalk, because "people who grew up with Java donât know how to write code". I donât agree with that, Iâve known a (very few) good Java developers. I would say, though, that Iâve known far more incompetent ones than good ones, and I canât think of any incompetent Smalltalk developers off the top of my head. >>>> >>>> Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or even C, complain about how hard maintaining state is or coming up with various hacks to avoid it, which seems to be the main point of every JavaScript based âtechnologyâ. An application is by definition a state-machine, which implies plenty about JS developers on the whole. >>>> >>>> If youâre a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why arenât there more good developers in any language? >>>> >>>> Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises Iâve worked for whoâve written their own dialects, and they all use it only when "shit has to work". They know itâs more productive, they also know using it for more things would increase the availability of Smalltalk developers. >>>> >>>> Why do they not do it? One reason, though it takes a while to recognize it, because management doesnât admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesnât âreallyâ matter, is an advantage to large enterprises because they have resources smaller competitors donât. >>>> >>>> Why donât their competitors do it? Because they canât see past an hourly rate, whatâs fashionable, or just new, or because their customers canât. Put more generally, average stupidity that isnât corrected by the market. Fashion affects smaller companies more than larger ones, because they canât afford a few customers walking away because they wanted an app in Electron, even if they canât give any relevant reason for wanting it, and even the samples on the Electron site donât work. >>>> >>>> Enterprises can, and do use Smalltalk when it matters. When it doesnât, itâs to their advantage to promote things that are inefficient, buggy and unreliable. >>>> >>>> Cost is relevant, but not in the simple way people look at things. A crucial but rarely mentioned perspective on its relevance is that while Java based software runs TV set top boxes, Smalltalk based software runs things like medical equipment, automated defense systems, tanks, etc. Cost becomes largely irrelevant when âshit has to workâ. >>>> >>>> Productivity is primarily relevant to less talented developers, in an inversely sense, since unproductive environments and attitudes have a leveling tendency in general, and more specifically make accomplishing what the less talented are capable of in any environment sufficiently laborious for them to have a role. Capability in Smalltalk, as implied by the person hiring for the Java role I mentioned, is a fairly decent means of judging whether someone is a so-so developer or a good one. >>>> >>>> The productivity argument is realistically only relevant in the context of an already higher hourly cost. Given that it is relevant at that point, companies that know Smalltalk is more productive would use it outside things that have to be 100%, if their own productivity were relevant to the same degree that competitorsâ productivity is inversely relevant. >>>> >>>> All these ways of looking at it are contingent perspectives though. Yes, if the number of libraries is relevant to you, Smalltalk is less attractive, but thatâs only a contingent phenomenon based on the relative popularity of Java and JavaScript, as a result it canât be used as explanatory for that popularity. All the ways of looking at it that are fully determinate are determinate via contingencies of that kind, which for the most part are precisely the other perspectives, including productivity, cost, availability of developers, etc. None of them is in itself anything but a result of the others. >>>> >>>> If availability of developers is contingent on popularity (and further, popularity contingent on industry attitudes), to use an example already mentioned in Joachimâs post, then his simultaneous posit of library availability is if anything more contingent on the same popularity, so positing it as a cause and not a result, or merely a correlate, of popularity is incoherent. We can go one step further, and demonstrate that even when large enterprises make something that works reliably available, they fail to promote and support it, which destroys the market for reliable tooling by simultaneously owning it while not promoting it, something IBM is particularly good at. But IBM canât (and if they canât, neither can any other company) operate that way without the tacit agreement of the industry. >>>> >>>> To understand it in a more general way, software development has to be looked at in the context where it occurs, and how itâs determined to a large degree by that context, with a specific difference. That difference is itself implicit in the context, i.e. capitalism, but only purely effective in software development. Itâs a result of virtualization as an implicit goal of capitalism, and the disruptions implicit in the virtual but so far only realized completely in software. In terms of that understanding, the analysis of virtualization and disruption as inherent to capitalism is better accomplished in Kapital than in any more recent work. >>>> >>>> Or you can simply decide, as Iâve done recently, that working in ways and with tools that prevent doing good work in a reasonable timeframe isnât worthwhile to you, no matter how popular those ways and tools might be, or what the posited reasons are, since at the end popularity is only insofar as it already is. What those tools and methods are depends to a degree on your priorities, but if developers are engineers those priorities canât be completely arbitrary. Engineers are defined by their ability to make things work. >>>> >>>> Software as virtual is inherently disruptive, and the software industry disrupts itself too often and too easily to build on anything. A further disruption caused by developers, as engineers, refusing to work with crap that doesnât, i.e. insisting on being engineers, while in itself merely an aggravation of the disruptive tendencies, might have an inverse result. >>>> >>>> Using a stable core of technologies as the basis for a more volatile set of products, in the way nearly every other industry does, is the best means we know of to build things both flexibly and reasonably efficiently. The computer hardware industry is the extreme example of this, while the software industry is the extreme contradiction. >>>> >>>> From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> on behalf of David Mason <dmason(a)ryerson.ca> >>>> Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>> Date: Tuesday, October 24, 2017 at 11:52 AM >>>> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>> >>>> PharoJS is working to give you that mobile app/browser app experience. As with others, we're not there yet, but getting there. See http://pharojs.org >>>> >>>> The 67% loved means that 67% of people using Smalltalk (or perhaps have ever used it) want to continue - so it's presumably a high percentage of a smallish number of people. >>>> >>>> On 20 October 2017 at 03:23, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: >>>> >>>>> First of all: I'd say the question itself is not a question but an excuse. I am not arguing there are enough Smalltalkers or cheap ones. But I think the question is just a way of saying "we don't want to do it for reasons that we ourselves cannot really express". If you are a good developer, learning Smalltalk is easy. If you are a good developer you've heard the sentence "we've taken the goos parts from x,y,z and Smalltalk" at least twice a year. So you most likely would like to learn it anyways. >>>>> >>>>> A shortage of developers doesn't exist. What exists is an unwillingness of companies to get people trained in a technology. If Smalltalk was cool and great in their opinion, they wouldn't care. It's that simple. As a consultant, I've heard that argument so often. Not ferom Startups, but from insurance companies, Banks or Car manufacturers who spend millions on useless, endless meetings and stuff instead of just hiring somebody to teach a couple of developers Smalltalk. It's just a lie: the shortage of Smalltalk developers is not a problem. >>>>> >>>>> And, to be honest: what is it we actually are better in by using Smalltalk? >>>>> Can we build cool looking web apps in extremely short time? No. >>>>> Can we build mobile Apps with little effort? No. >>>>> Does our Smalltalk ship lots of great libraries for all kinds of things that are not availabel in similar quality in any other language? >>>>> Are we lying when we say we are so extremely over-productive as compared to other languages? >>>>> >>>>> I know, all that live debugging stuff and such is great and it is much faster to find & fix a bug in Smalltalk than in any other environment I've used so far. But that is really only true for business code. When I need to connect to things or want to build a modern GUI or a web application with a great look&feel, I am nowhere near productive, because I simply have to build my own stuff or learn how to use other external resources. If I want to build something for a mobile device, I will only hear that somebody somewhere has done it before. No docs, no proof, no ready-made tool for me. >>>>> >>>>> Shortage of developers is not really the problem. If Smalltalk was as cool as we like to make ourselves believe, this problem would be non-existent. If somebody took out their iPad and told an audience: "We did this in Smalltalk in 40% of the time it would have taken in Swift", and if that something was a must-have for people, things would be much easier. But nobody has. >>>>> >>>>> I am absolutely over-exaggerating, because I make my living with an SaaS product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk and - as you - am convince that many parts of what we've done so far would've taken much longer or even be impossible in other languages. But the advantage was eaten by our extremely steep learning curve for web technologies and for building something that works almost as well as tools like Angular or jQuery Mobile. >>>>> >>>>> Smalltalk is cool, and the day somebody shows me something like Google's flutter in Smalltalk, I am ready to bet a lot on a bright future for Smalltalk. But until then, I'd say these arguments about productivity are just us trying to make ourselves believe we're still the top of the food chain. We've done that for almost thirty years now and still aren't ready to stop it. But we've been lying to ourselves and still do so. >>>>> >>>>> I don't think there is a point in discussing about the usefulness of a language using an argument like the number or ready-made developers. That is just an argument they know you can't win. The real question is and should be: what is the benefit of using Smalltalk. Our productivity argument is a lie as soon as we have to build something that uses or runs on technology that has been invented after 1990. >>>>> >>>>> Okay, shoot ;-) >>>>> >>>>> Joachim >>>>> >>>>> â >>>>> ââââââââââââââââââââââââ >>>>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >>>>> Fliederweg 1 http://www.objektfabrik.de >>>>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by jtuchel＠objektfabrik.de

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 > <mailto:jtuchel@objektfabrik.de> <jtuchel(a)objektfabrik.de > <mailto:jtuchel@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 > <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> > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1Â Â Â Â Â Â Â Â Â Â Â Â Â http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0Â Â Â Â Â Fax: +49 7141 56 10 86 1

Oct. 26, 2017

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

by Dimitris Chloupis

Nothing complex about two images exchanging messages, its not even complex to transmit objects via fuel, you even transmit a debugger or any part of the live environment or even make an "internet" of images that join objects together. Sky is the limit. Pharo already provides you will all the tools/libraries to do this. A streamsocket (not to be confused with regular sockets) will delay the messages (a collection of bytes) until they arrive to the receiver or until they have reached the timeout period. Offline mode is pretty much obligatory even for plain old internet web apps because of drops in connection or the plain fact a connection can become slow. I used streamsockets in my Pharo to Python bridge (Atlas) because the execution was not necessary synchronous , I was sending Python command to a 3d application from Pharo and I had to make sure that the bridge was working even in the case of a command that could take hours to execute like a rendering process. One cool trick I did was to send the Python errors back to Pharo and trigger them as Pharo's regular MessageNotUnderstood , this is a nice way to make sure that you can fix a wrong message after it has been executing without going to the image that is executing it. The limitation with sockets which what every frameworks uses because AFAIK they are the only means to communicate remotely is that they are not top performance so that mean that you can send long loops but executing communication inside long loops will either slow you down considerably or simply timeout your socket. Sockets can timeout from both ends if they feel that for some reason they lost communication with the other side and reached their timeout period. Timeout period is customization. This is a problem I did not tackle with my implementation because I dont think there can be an actual practical solution better than avoiding this scenario. Only shared memory seems to overcome this but it can be used only locally and not remotely (aka on same computer) . On Wed, Oct 25, 2017 at 4:41 PM CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > I had a look and this is not (natively) possible. > > The idea of the off-line mode would be to delay messages that are sent to > the peer until a connection is established. > > I think I have to try to do it by myself (like having a list of > information exchange that wait until a connexion is established). > > What I try to do is not as complex as two general image exchanging > messages on objects (like on TelePharo). > > I just want a repository of information (mainly a collection of static > information/data versions) on both peers to be synchronized when a > connection is established. > > > > > > Le 25 oct. 2017 Ã 15:31, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit : > > What is offline mode? > > 2017-10-25 15:10 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: > >> Thanks Denis. I will ! I knew I have seen a telephoto component that >> could help but forgot about it ! >> >> Do you know if itâs possible to handle offline mode ? >> >> >> >> Le 25 oct. 2017 Ã 15:05, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit >> : >> >> Look at Seamless https://github.com/dionisiydk/Seamless. >> >> 2017-10-25 14:21 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: >> >>> Hi all, >>> >>> I want to connect two applications (1 by image, each one on a different >>> computer) so as as to exchange information (data) between them. >>> >>> So my question is about the best (smalltalk) practices to connect two >>> app/image and exchange data. >>> >>> I imagine either with a direct connection through a network (TCP Socket, >>> Web socket, pure HTTP with Zinc) and/or with a serial connection. >>> At first, without any Â« security Â». But later, information exchanges >>> will be encrypted. >>> >>> Iâve seen some information on how to use SerialPort, or even FileStream. >>> I could do it (or at least simulate it with HTTP). What are the other >>> options ? Socket ? >>> Do we have P2P libs (I couldnât find) with eventually discovery features >>> ? >>> >>> Any comment / suggestion / pointers are greatly welcome. >>> >>> TIA. >>> >>> CÃ©drick >>> >> >> >> > >

Oct. 26, 2017

Re: [Pharo-users] Annual online conference?

by Tudor Girba

Nice idea, indeed. Doru > On Oct 26, 2017, at 10:18 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Thatâs a nice idea! > > I will check how they did it and we should see if that makes sense in the future. > (for Pharo Days) > > Marcus > >> On 25 Oct 2017, at 23:17, PAUL DEBRUICKER <pdebruic(a)gmail.com> wrote: >> >> Laravel.com is a PHP web framework. >> >> >> Their community organizes an online conference: https://laracon.net/2017 >> >> >> Seems like it could be worthy of mimicking in the Smalltalk community. >> > > -- www.tudorgirba.com www.feenk.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

Oct. 26, 2017

Re: [Pharo-users] Annual online conference?

by Marcus Denker

Thatâs a nice idea! I will check how they did it and we should see if that makes sense in the future. (for Pharo Days) Marcus > On 25 Oct 2017, at 23:17, PAUL DEBRUICKER <pdebruic(a)gmail.com> wrote: > > Laravel.com is a PHP web framework. > > > Their community organizes an online conference: https://laracon.net/2017 > > > Seems like it could be worthy of mimicking in the Smalltalk community. >

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by Paulo R. Dellani

I like your depiction of the situation and arguments, Andrew. The inherent volatility of the software industry due to its tendency to self disruption, as you pointed out, is fertile ground to all kinds of crap, but we as developers should keep our eyes wide open and look for the pearls and gems that grow here and there, like Pharo Smalltalk. Of course my "vision", as a Smalltalker is inherently biased, but as you said, when "shit has to work", I think that we have good cards at our hands. So yesterday we had another meeting and I think I could make a good point for Smalltalk, thanks to all your arguments here at the list. But surely the absolute killer argument is that "this shit really works" :-) As pointed out by several of you, integration is key. For my particular present case, I could successfully integrate the developed tools in the system, a medical imaging processing pipeline, through the command line and the filesystem - so no need for fancy looking web apps at the moment, but it surely will not hurt to have this possibilities - it would be cool to run part of the code at the front end (internet browser), in our case, some pre-processing of medical data before it is sent to the "main processing pipeline" (just one practical example of many other possible applications). This particular task could be done with Javascript, but I am afraid that the necessary libraries are not so good.. Cheers, Paulo On 10/26/2017 12:46 AM, Andrew Glynn 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 > <mailto:jtuchel@objektfabrik.de> <jtuchel(a)objektfabrik.de > <mailto:jtuchel@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 <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. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by phil＠highoctane.be

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 > > > > > > > > > On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)gmail.com> > wrote: > > Thereâs other questions that are relevant to me: > > > > Do I give a f*** about cool looking web apps? No, I donât use web apps if > in any way I can avoid it. > > > > Do I give a f*** about mobile apps? No, the screenâs too small to read > anything longer than a twit, or anyone with anything worthwhile to say. > > > > Do I give a f*** about the number of libraries in other languages? No, > because most of them are crap in every language Iâve had to work in, and > the base languages are crap so they have to keep changing radically, and > libraries and frameworks therefore also have to and never get any better. > The few that are worthwhile I can almost always use from Smalltalk without > a problem (read, Blender, ACT-R and Synapse, since every other > library/framework Iâve used outside Smalltalk has been a waste of time). > > > > Do I give a f*** about implementing a complex piece of machine learning > software in 22 hours, compared to 3 months for the Java version? Well, > actually yes, I do, because that was 3 months of my life down the toilet > for something that is too slow to be useful in Java. > > > > Any argument depends on your priorities. Iâve written tons of web apps, > because I needed to get paid. Iâve written better shitty mobile apps than > the average shitty mobile apps. However, Iâm not going to do any of that > any longer in crap that never improves, because after 26 years the > irritability it produces is more than itâs worth. > > > > A few weeks ago, a recruiter that specializes in Smalltalk called me about > a job, although they were well aware I live 1500 miles away from the city I > lived in when I had worked through them, to see if Iâd be willing to move > back there for a job. That sounds like another âthere arenât enough > Smalltalk developers", but it wasnât, because the job wasnât writing > Smalltalk. It was writing Java. > > > > The person hiring, though, wouldnât look at anyone who didnât write > Smalltalk, because "people who grew up with Java donât know how to write > code". I donât agree with that, Iâve known a (very few) good Java > developers. I would say, though, that Iâve known far more incompetent ones > than good ones, and I canât think of any incompetent Smalltalk developers > off the top of my head. > > > > Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or > even C, complain about how hard maintaining state is or coming up with > various hacks to avoid it, which seems to be the main point of every > JavaScript based âtechnologyâ. An application is by definition a > state-machine, which implies plenty about JS developers on the whole. > > > > If youâre a good developer you can write good code in (nearly) anything. > My question then is why would you want to write in crap? The better > question is why arenât there more good developers in *any* language? > > > > Every project I have been able to do in Smalltalk, though, has had one > thing in common, the "shit has to work". Companies do use it, in fact I > could name 4 large enterprises Iâve worked for whoâve written their own > dialects, and they all use it only when "shit has to work". They know itâs > more productive, they also know using it for more things would increase the > availability of Smalltalk developers. > > > > Why do they not do it? One reason, though it takes a while to recognize > it, because management doesnât admit even to themselves why they do it, or > not very often. Being inefficient, as long as it doesnât âreallyâ matter, > is an advantage to large enterprises because they have resources smaller > competitors donât. > > > > Why donât their competitors do it? Because they canât see past an hourly > rate, whatâs fashionable, or just new, or because their customers canât. > Put more generally, average stupidity that isnât corrected by the market. > Fashion affects smaller companies more than larger ones, because they canât > afford a few customers walking away because they wanted an app in Electron, > even if they canât give any relevant reason for wanting it, and even the > samples on the Electron site donât work. > > > > Enterprises can, and do use Smalltalk when it matters. When it doesnât, > itâs to their advantage to promote things that are inefficient, buggy and > unreliable. > > > > Cost is relevant, but not in the simple way people look at things. A > crucial but rarely mentioned perspective on its relevance is that while > Java based software runs TV set top boxes, Smalltalk based software runs > things like medical equipment, automated defense systems, tanks, etc. Cost > becomes largely irrelevant when âshit has to workâ. > > > > Productivity is primarily relevant to less talented developers, in an > inversely sense, since unproductive environments and attitudes have a > leveling tendency in general, and more specifically make accomplishing what > the less talented are capable of in any environment sufficiently laborious > for them to have a role. Capability in Smalltalk, as implied by the person > hiring for the Java role I mentioned, is a fairly decent means of judging > whether someone is a so-so developer or a good one. > > > > The productivity argument is realistically only relevant in the context of > an already higher hourly cost. Given that it is relevant at that point, > companies that know Smalltalk is more productive would use it outside > things that have to be 100%, *if* their own productivity were relevant to > the same degree that competitorsâ productivity is inversely relevant. > > > > All these ways of looking at it are contingent perspectives though. Yes, > if the number of libraries is relevant to you, Smalltalk is less > attractive, but thatâs only a contingent phenomenon based on the relative > popularity of Java and JavaScript, as a result it canât be used as > explanatory *for* that popularity. All the ways of looking at it that > are fully determinate are determinate via contingencies of that kind, which > for the most part *are* precisely the other perspectives, including > productivity, cost, availability of developers, etc. None of them is *in > itself* anything but a result of the others. > > > > If availability of developers is contingent on popularity (and further, > popularity contingent on industry attitudes), to use an example already > mentioned in Joachimâs post, then his simultaneous posit of library > availability is if anything more contingent on the same popularity, so > positing it as a cause and not a result, or merely a correlate, of > popularity is incoherent. We can go one step further, and demonstrate that > even when large enterprises make something that works reliably available, > they fail to promote and support it, which destroys the market for reliable > tooling by simultaneously owning it while not promoting it, something IBM > is particularly good at. But IBM canât (and if they canât, neither can any > other company) operate that way without the tacit agreement of the > industry. > > > > To understand it in a more general way, software development has to be > looked at in the context where it occurs, and how itâs determined to a > large degree by that context, with a specific difference. That difference > is itself implicit in the context, i.e. capitalism, but only *purely *effective > in software development. Itâs a result of virtualization as an implicit > goal of capitalism, and the disruptions implicit in the virtual but so far > only realized completely in software. In terms of that understanding, the > analysis of virtualization and disruption as inherent to capitalism is > better accomplished in Kapital than in any more recent work. > > > > Or you can simply decide, as Iâve done recently, that working in ways and > with tools that prevent doing good work in a reasonable timeframe isnât > worthwhile *to you,* no matter how popular those ways and tools might be, > or what the posited reasons are, since at the end popularity is only > insofar as it *already* is. What those tools and methods are depends to > a degree on your priorities, but if developers are *engineers* those > priorities canât be completely arbitrary. Engineers are defined by their > ability to make things work. > > > > Software as virtual is inherently disruptive, and the software industry > disrupts itself too often and too easily to build on anything. A further > disruption caused by developers, *as* engineers, refusing to work with > crap that *doesnât*, i.e. insisting on being engineers, while in itself > merely an aggravation of the disruptive tendencies, might have an inverse > result. > > > > Using a stable core of technologies as the basis for a more volatile set > of products, in the way nearly every other industry does, is the best means > we know of to build things both flexibly and reasonably efficiently. The > computer hardware industry is the extreme example of this, while the > software industry is the extreme contradiction. > > > > *From: *Pharo-users <pharo-users-bounces(a)lists.pharo.org> on behalf of > David Mason <dmason(a)ryerson.ca> > *Reply-To: *Any question about pharo is welcome < > pharo-users(a)lists.pharo.org> > *Date: *Tuesday, October 24, 2017 at 11:52 AM > *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject: *Re: [Pharo-users] Smalltalk Argument > > > > PharoJS is working to give you that mobile app/browser app experience. As > with others, we're not there yet, but getting there. See > http://pharojs.org > > > > The 67% loved means that 67% of people using Smalltalk (or perhaps have > ever used it) want to continue - so it's presumably a high percentage of a > smallish number of people. > > > > On 20 October 2017 at 03:23, jtuchel(a)objektfabrik.de < > jtuchel(a)objektfabrik.de> wrote: > > First of all: I'd say the question itself is not a question but an excuse. > I am not arguing there are enough Smalltalkers or cheap ones. But I think > the question is just a way of saying "we don't want to do it for reasons > that we ourselves cannot really express". If you are a good developer, > learning Smalltalk is easy. If you are a good developer you've heard the > sentence "we've taken the goos parts from x,y,z and Smalltalk" at least > twice a year. So you most likely would like to learn it anyways. > > A shortage of developers doesn't exist. What exists is an unwillingness of > companies to get people trained in a technology. If Smalltalk was cool and > great in their opinion, they wouldn't care. It's that simple. As a > consultant, I've heard that argument so often. Not ferom Startups, but from > insurance companies, Banks or Car manufacturers who spend millions on > useless, endless meetings and stuff instead of just hiring somebody to > teach a couple of developers Smalltalk. It's just a lie: the shortage of > Smalltalk developers is not a problem. > > And, to be honest: what is it we actually are better in by using > Smalltalk? > Can we build cool looking web apps in extremely short time? No. > Can we build mobile Apps with little effort? No. > Does our Smalltalk ship lots of great libraries for all kinds of things > that are not availabel in similar quality in any other language? > Are we lying when we say we are so extremely over-productive as compared > to other languages? > > I know, all that live debugging stuff and such is great and it is much > faster to find & fix a bug in Smalltalk than in any other environment I've > used so far. But that is really only true for business code. When I need to > connect to things or want to build a modern GUI or a web application with a > great look&feel, I am nowhere near productive, because I simply have to > build my own stuff or learn how to use other external resources. If I want > to build something for a mobile device, I will only hear that somebody > somewhere has done it before. No docs, no proof, no ready-made tool for me. > > > Shortage of developers is not really the problem. If Smalltalk was as cool > as we like to make ourselves believe, this problem would be non-existent. > If somebody took out their iPad and told an audience: "We did this in > Smalltalk in 40% of the time it would have taken in Swift", and if that > something was a must-have for people, things would be much easier. But > nobody has. > > > I am absolutely over-exaggerating, because I make my living with an SaaS > product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk > and - as you - am convince that many parts of what we've done so far > would've taken much longer or even be impossible in other languages. But > the advantage was eaten by our extremely steep learning curve for web > technologies and for building something that works almost as well as tools > like Angular or jQuery Mobile. > > Smalltalk is cool, and the day somebody shows me something like Google's > flutter in Smalltalk, I am ready to bet a lot on a bright future for > Smalltalk. But until then, I'd say these arguments about productivity are > just us trying to make ourselves believe we're still the top of the food > chain. We've done that for almost thirty years now and still aren't ready > to stop it. But we've been lying to ourselves and still do so. > > I don't think there is a point in discussing about the usefulness of a > language using an argument like the number or ready-made developers. That > is just an argument they know you can't win. The real question is and > should be: what is the benefit of using Smalltalk. Our productivity > argument is a lie as soon as we have to build something that uses or runs > on technology that has been invented after 1990. > > > Okay, shoot ;-) > > Joachim > > > â > ââââââââââââââââââââââââ > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > > > >

Oct. 26, 2017

[ANN] Pharo Consortium New Platinum Member: JPMorgan Chase

by Marcus Denker

The Pharo Consortium is very happy to announce that JPMorgan Chase has joined the Consortium as a Platinum Member. About - JPMorgan Chase: https://www.jpmorganchase.com - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: - http://association.pharo.org

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

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]("mailto:phil@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]("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]("mailto:aglynn42@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]("mailto:pharo-users-bounces@lists.pharo.org")> on behalf of David Mason <[dmason(a)ryerson.ca]("mailto:dmason@ryerson.ca")> >> Reply-To: Any question about pharo is welcome <[pharo-users(a)lists.pharo.org]("mailto:pharo-users@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]("mailto:pharo-users@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]("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]("mailto:jtuchel@objektfabrik.de") <[jtuchel(a)objektfabrik.de]("mailto:jtuchel@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]("mailto:jtuchel@objektfabrik.de") >>> Fliederweg 1 [http://www.objektfabrik.de]("http://www.objektfabrik.de") >>> D-71640 Ludwigsburg [http://joachimtuchel.wordpress.com]("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. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by phil＠highoctane.be

I like that piece a lot, seeing exactly the described situation in large enterprises. I made a strategic decision to go with Pharo for the long run for my solutions because it is a stable base on which to build (ok, there are evolutions, but fundamentally, I can rely on it being under control and can maintain solutions in a version). The rationale is that at a deep level I am really fed up with having to deal with accidental complexity (now having to deal with Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology drag and 20% net business contribution. One key thing is that a team needs guidance and Smalltalk makes it easier due to well known ways of doing things. Now we miss the boat on mobile and bigdata, but this is solvable. If we had an open Java bridge (and some people in the community have it for Pharo but do not open source it - so this is eminently doable) + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big executable we would have a way to embed Pharo in a lot of places (e.g. in the Hadoop ecosystem where fast starting VMs and small footprint would make the cluster capacity x2 or x3 vs uberjars all over the place) this would be a real disruption. Think about being able to call Pharo from JNA https://github.com/java-native-access/jna the same way we use C with UFFI. Smalltalk argument for me is that it makes development bearable (even fun and enjoyable would I say) vs the other stacks. That matters. Phil On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > Thereâs other questions that are relevant to me: > > > > Do I give a f*** about cool looking web apps? No, I donât use web apps if > in any way I can avoid it. > > > > Do I give a f*** about mobile apps? No, the screenâs too small to read > anything longer than a twit, or anyone with anything worthwhile to say. > > > > Do I give a f*** about the number of libraries in other languages? No, > because most of them are crap in every language Iâve had to work in, and > the base languages are crap so they have to keep changing radically, and > libraries and frameworks therefore also have to and never get any better. > The few that are worthwhile I can almost always use from Smalltalk without > a problem (read, Blender, ACT-R and Synapse, since every other > library/framework Iâve used outside Smalltalk has been a waste of time). > > > > Do I give a f*** about implementing a complex piece of machine learning > software in 22 hours, compared to 3 months for the Java version? Well, > actually yes, I do, because that was 3 months of my life down the toilet > for something that is too slow to be useful in Java. > > > > Any argument depends on your priorities. Iâve written tons of web apps, > because I needed to get paid. Iâve written better shitty mobile apps than > the average shitty mobile apps. However, Iâm not going to do any of that > any longer in crap that never improves, because after 26 years the > irritability it produces is more than itâs worth. > > > > A few weeks ago, a recruiter that specializes in Smalltalk called me about > a job, although they were well aware I live 1500 miles away from the city I > lived in when I had worked through them, to see if Iâd be willing to move > back there for a job. That sounds like another âthere arenât enough > Smalltalk developersâ, but it wasnât, because the job wasnât writing > Smalltalk. It was writing Java. > > > > The person hiring, though, wouldnât look at anyone who didnât write > Smalltalk, because âpeople who grew up with Java donât know how to write > codeâ. I donât agree with that, Iâve known a (very few) good Java > developers. I would say, though, that Iâve known far more incompetent ones > than good ones, and I canât think of any incompetent Smalltalk developers > off the top of my head. > > > > Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or > even C, complain about how hard maintaining state is or coming up with > various hacks to avoid it, which seems to be the main point of every > JavaScript based âtechnologyâ. An application is by definition a > state-machine, which implies plenty about JS developers on the whole. > > > > If youâre a good developer you can write good code in (nearly) anything. > My question then is why would you want to write in crap? The better > question is why arenât there more good developers in *any* language? > > > > Every project I have been able to do in Smalltalk, though, has had one > thing in common, the âshit has to workâ. Companies do use it, in fact I > could name 4 large enterprises Iâve worked for whoâve written their own > dialects, and they all use it only when âshit has to workâ. They know itâs > more productive, they also know using it for more things would increase the > availability of Smalltalk developers. > > > > Why do they not do it? One reason, though it takes a while to recognize > it, because management doesnât admit even to themselves why they do it, or > not very often. Being inefficient, as long as it doesnât âreallyâ matter, > is an advantage to large enterprises because they have resources smaller > competitors donât. > > > > Why donât their competitors do it? Because they canât see past an hourly > rate, whatâs fashionable, or just new, or because their customers canât. > Put more generally, average stupidity that isnât corrected by the market. > Fashion affects smaller companies more than larger ones, because they canât > afford a few customers walking away because they wanted an app in Electron, > even if they canât give any relevant reason for wanting it, and even the > samples on the Electron site donât work. > > > > Enterprises can, and do use Smalltalk when it matters. When it doesnât, > itâs to their advantage to promote things that are inefficient, buggy and > unreliable. > > > > Cost is relevant, but not in the simple way people look at things. A > crucial but rarely mentioned perspective on its relevance is that while > Java based software runs TV set top boxes, Smalltalk based software runs > things like medical equipment, automated defense systems, tanks, etc. Cost > becomes largely irrelevant when âshit has to workâ. > > > > Productivity is primarily relevant to less talented developers, in an > inversely sense, since unproductive environments and attitudes have a > leveling tendency in general, and more specifically make accomplishing what > the less talented are capable of in any environment sufficiently laborious > for them to have a role. Capability in Smalltalk, as implied by the person > hiring for the Java role I mentioned, is a fairly decent means of judging > whether someone is a so-so developer or a good one. > > > > The productivity argument is realistically only relevant in the context of > an already higher hourly cost. Given that it is relevant at that point, > companies that know Smalltalk is more productive would use it outside > things that have to be 100%, *if* their own productivity were relevant to > the same degree that competitorsâ productivity is inversely relevant. > > > > All these ways of looking at it are contingent perspectives though. Yes, > if the number of libraries is relevant to you, Smalltalk is less > attractive, but thatâs only a contingent phenomenon based on the relative > popularity of Java and JavaScript, as a result it canât be used as > explanatory *for* that popularity. All the ways of looking at it that > are fully determinate are determinate via contingencies of that kind, which > for the most part *are* precisely the other perspectives, including > productivity, cost, availability of developers, etc. None of them is *in > itself* anything but a result of the others. > > > > If availability of developers is contingent on popularity (and further, > popularity contingent on industry attitudes), to use an example already > mentioned in Joachimâs post, then his simultaneous posit of library > availability is if anything more contingent on the same popularity, so > positing it as a cause and not a result, or merely a correlate, of > popularity is incoherent. We can go one step further, and demonstrate that > even when large enterprises make something that works reliably available, > they fail to promote and support it, which destroys the market for reliable > tooling by simultaneously owning it while not promoting it, something IBM > is particularly good at. But IBM canât (and if they canât, neither can any > other company) operate that way without the tacit agreement of the > industry. > > > > To understand it in a more general way, software development has to be > looked at in the context where it occurs, and how itâs determined to a > large degree by that context, with a specific difference. That difference > is itself implicit in the context, i.e. capitalism, but only *purely *effective > in software development. Itâs a result of virtualization as an implicit > goal of capitalism, and the disruptions implicit in the virtual but so far > only realized completely in software. In terms of that understanding, the > analysis of virtualization and disruption as inherent to capitalism is > better accomplished in Kapital than in any more recent work. > > > > Or you can simply decide, as Iâve done recently, that working in ways and > with tools that prevent doing good work in a reasonable timeframe isnât > worthwhile *to you,* no matter how popular those ways and tools might be, > or what the posited reasons are, since at the end popularity is only > insofar as it *already* is. What those tools and methods are depends to > a degree on your priorities, but if developers are *engineers* those > priorities canât be completely arbitrary. Engineers are defined by their > ability to make things work. > > > > Software as virtual is inherently disruptive, and the software industry > disrupts itself too often and too easily to build on anything. A further > disruption caused by developers, *as* engineers, refusing to work with > crap that *doesnât*, i.e. insisting on being engineers, while in itself > merely an aggravation of the disruptive tendencies, might have an inverse > result. > > > > Using a stable core of technologies as the basis for a more volatile set > of products, in the way nearly every other industry does, is the best means > we know of to build things both flexibly and reasonably efficiently. The > computer hardware industry is the extreme example of this, while the > software industry is the extreme contradiction. > > > > *From: *Pharo-users <pharo-users-bounces(a)lists.pharo.org> on behalf of > David Mason <dmason(a)ryerson.ca> > *Reply-To: *Any question about pharo is welcome < > pharo-users(a)lists.pharo.org> > *Date: *Tuesday, October 24, 2017 at 11:52 AM > *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject: *Re: [Pharo-users] Smalltalk Argument > > > > PharoJS is working to give you that mobile app/browser app experience. As > with others, we're not there yet, but getting there. See > http://pharojs.org > > > > The 67% loved means that 67% of people using Smalltalk (or perhaps have > ever used it) want to continue - so it's presumably a high percentage of a > smallish number of people. > > > > On 20 October 2017 at 03:23, jtuchel(a)objektfabrik.de < > jtuchel(a)objektfabrik.de> wrote: > > First of all: I'd say the question itself is not a question but an excuse. > I am not arguing there are enough Smalltalkers or cheap ones. But I think > the question is just a way of saying "we don't want to do it for reasons > that we ourselves cannot really express". If you are a good developer, > learning Smalltalk is easy. If you are a good developer you've heard the > sentence "we've taken the goos parts from x,y,z and Smalltalk" at least > twice a year. So you most likely would like to learn it anyways. > > A shortage of developers doesn't exist. What exists is an unwillingness of > companies to get people trained in a technology. If Smalltalk was cool and > great in their opinion, they wouldn't care. It's that simple. As a > consultant, I've heard that argument so often. Not ferom Startups, but from > insurance companies, Banks or Car manufacturers who spend millions on > useless, endless meetings and stuff instead of just hiring somebody to > teach a couple of developers Smalltalk. It's just a lie: the shortage of > Smalltalk developers is not a problem. > > And, to be honest: what is it we actually are better in by using Smalltalk? > Can we build cool looking web apps in extremely short time? No. > Can we build mobile Apps with little effort? No. > Does our Smalltalk ship lots of great libraries for all kinds of things > that are not availabel in similar quality in any other language? > Are we lying when we say we are so extremely over-productive as compared > to other languages? > > I know, all that live debugging stuff and such is great and it is much > faster to find & fix a bug in Smalltalk than in any other environment I've > used so far. But that is really only true for business code. When I need to > connect to things or want to build a modern GUI or a web application with a > great look&feel, I am nowhere near productive, because I simply have to > build my own stuff or learn how to use other external resources. If I want > to build something for a mobile device, I will only hear that somebody > somewhere has done it before. No docs, no proof, no ready-made tool for me. > > > Shortage of developers is not really the problem. If Smalltalk was as cool > as we like to make ourselves believe, this problem would be non-existent. > If somebody took out their iPad and told an audience: "We did this in > Smalltalk in 40% of the time it would have taken in Swift", and if that > something was a must-have for people, things would be much easier. But > nobody has. > > > I am absolutely over-exaggerating, because I make my living with an SaaS > product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk > and - as you - am convince that many parts of what we've done so far > would've taken much longer or even be impossible in other languages. But > the advantage was eaten by our extremely steep learning curve for web > technologies and for building something that works almost as well as tools > like Angular or jQuery Mobile. > > Smalltalk is cool, and the day somebody shows me something like Google's > flutter in Smalltalk, I am ready to bet a lot on a bright future for > Smalltalk. But until then, I'd say these arguments about productivity are > just us trying to make ourselves believe we're still the top of the food > chain. We've done that for almost thirty years now and still aren't ready > to stop it. But we've been lying to ourselves and still do so. > > I don't think there is a point in discussing about the usefulness of a > language using an argument like the number or ready-made developers. That > is just an argument they know you can't win. The real question is and > should be: what is the benefit of using Smalltalk. Our productivity > argument is a lie as soon as we have to build something that uses or runs > on technology that has been invented after 1990. > > > Okay, shoot ;-) > > Joachim > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > >

Oct. 26, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

Itâs well said, I donât give a f*** about other languages. NSA-proof, anonymized 2048-bit key rendezvoused connection framework in 33 classes. Includes user definable cipher and encoder. SmalltalkHub talkin ParrotTalk. http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz - HH On Wed, Oct 25, 2017 at 18:46, Andrew Glynn <[aglynn42(a)gmail.com]("mailto:aglynn42@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]("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]("mailto:jtuchel@objektfabrik.de") <[jtuchel(a)objektfabrik.de]("mailto:jtuchel@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]("mailto:jtuchel@objektfabrik.de") >> Fliederweg 1 [http://www.objektfabrik.de]("http://www.objektfabrik.de") >> D-71640 Ludwigsburg [http://joachimtuchel.wordpress.com]("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. 25, 2017

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

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. 25, 2017

Annual online conference?

by PAUL DEBRUICKER

Laravel.com is a PHP web framework. Their community organizes an online conference: https://laracon.net/2017 Seems like it could be worthy of mimicking in the Smalltalk community.

Oct. 25, 2017

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

by Tim Mackinnon

Phil presented an Xmpp integration at Pharo days - I understood that was a common comms mechanism too. Tim Sent from my iPhone > On 25 Oct 2017, at 20: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. 25, 2017

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

by Stephane Ducasse

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. 25, 2017

Binary Decision Diagram Package in Smalltalk

by Prof. Andrew P. Black

Does anyone know of a BDD â thatâs Binary Decision Diagram â package written in Smalltalk? Andrew

Oct. 25, 2017

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

by Marten Feldtmann

Am 25.10.2017 um 15:52 schrieb CÃ©drick BÃ©ler: > Ok. > > I wonder also if Basys is not enough to experiment. > https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… > > Iâll also try Sebastian suggestion. > ZeroMQ is a wonderful library. We used it together with Gemstone/s to build an "Event data bus" based on ZeroMQ ... and with each successful commit our Gemstone/S send events on this "bus". On the "bus" several different programs written in different languages are listening and do some reaction based on the events they were interested in. Marten Feldtmann

Oct. 25, 2017

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

by henry

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. 25, 2017

Re: [Pharo-users] Glorp: #includesKey:

by Herby VojÄÃk

Niall Ross wrote: > Dear Herby, > adding #includesKey: is certainly doable. If you look at callers above > and subcallers below #anySatisfyDefault: you will see the issues > involved. Your includesKey: needs the same degree of platform-awareness > that Glorp's #anySatisfy: and #allSatisfy: implementations use. But > since #anySatisfy: is there, you have a ready template to follow. I don't feel competent enough, from what I looked, Glorp innards are a bit complex. > Alternatively, I may well add #includesKey: - though not as my most > urgent task. :-) I did a fair amount of work to extend the usability of > DictionaryMappings in Glorp three years ago (part of demonstrating the > ObjectStudio business-mapping/Glorp-generating tools - see my ESUG 2014 > presentation for details) but I did not then think of providing > #includesKey:. Thanks for suggesting the idea. My pleasure. :-) As I wrote elsewhere, also #keys is something (probably the most general) one that could be added as a matter of allowing to work with the key field - as far as I was able to find out, there is no way to actually get to the key, for which I found workaround since I mapped object, but would be out of luck if I mapped single primitive value. For the moment, it is not pressing, but yes, it would be nice to be able to have #keys mapping to key field and #includesKey: as an idiomatic way to do keys includes:. Thanks again, Herby > If you were to work on this, be aware: > > - always reinitialise FunctionExpression class after adding/changing any > Glorp function (or just close and reopen your image, of course) > > - If (and only if) you construct Query whereClauses in stages (e.g. you > have code like > > myQuery AND: [:customer | customer orders includesKey: #onlineOrders] > > or similar) then, using its callers in GlorpTest as a guide, know when > you might need to send #setUpBaseFromSession: to your query while doing > so. (N.B. that method is a Glorp version 8.2.1 addition; you will not > have it in older Glorp.) The point is that stage-constructed where > clauses must convert from block to expression before execution, to > combine the stages. Any that use #anySatisfy:/#allSatisfy: need > platform-specific information to do this; I would expect any > #includesKey: implementation to be the same. > > HTH > Niall Ross > > > Tom Robinson wrote: > > Hi Herby, > > In my opinion, the way you found to make it work is the way it should > be. The reason is that the first way doesn't translate into SQL and the > second one does. It might be possible to add includesKey: functionality > but resolving that to SQL would be more complex. I would not call this a > bug. I would call it a limitation of the implementation. I don't know of > anyone planning to add this feature to Glorp right now. > > Regards, > > Tom > > On 10/24/2017 12:27 PM, Herby VojÄÃk wrote: > >> Hello! >> >> I am using a DictionaryMapping in my code, and I wanted to use >> #includesKey: in #where: clause (something akin >> >> each tools includesKey: aToolId >> >> ) to select only rows for which DictionaryMapping uses certain key. It >> failed with the error in the lines of "#tools does not resolve to >> field". I had to come up with >> >> each tools anySatisfy: [ :tool | tool id = aToolId ] >> >> Is it the bug / feature / problem in my approach? If bug, is it >> planned to add #includesKey: translation to DictionaryMapping? >> >> Thanks, Herby >

Oct. 25, 2017

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

by CÃ©drick BÃ©ler

Ok. I wonder also if Basys is not enough to experiment. https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… <https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre…> Iâll also try Sebastian suggestion. Cheers, CÃ©drick > Le 25 oct. 2017 Ã 15:47, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit : > > Yes, it is not part of Seamless. > > 2017-10-25 15:40 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com>>: > I had a look and this is not (natively) possible. > > The idea of the off-line mode would be to delay messages that are sent to the peer until a connection is established. > > I think I have to try to do it by myself (like having a list of information exchange that wait until a connexion is established). > > What I try to do is not as complex as two general image exchanging messages on objects (like on TelePharo). > > I just want a repository of information (mainly a collection of static information/data versions) on both peers to be synchronized when a connection is established. > > > > > >> Le 25 oct. 2017 Ã 15:31, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> a Ã©crit : >> >> What is offline mode? >> >> 2017-10-25 15:10 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com>>: >> Thanks Denis. I will ! I knew I have seen a telephoto component that could help but forgot about it ! >> >> Do you know if itâs possible to handle offline mode ? >> >> >> >>> Le 25 oct. 2017 Ã 15:05, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> a Ã©crit : >>> >>> Look at Seamless https://github.com/dionisiydk/Seamless <https://github.com/dionisiydk/Seamless>. >>> >>> 2017-10-25 14:21 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com>>: >>> Hi all, >>> >>> I want to connect two applications (1 by image, each one on a different computer) so as as to exchange information (data) between them. >>> >>> So my question is about the best (smalltalk) practices to connect two app/image and exchange data. >>> >>> I imagine either with a direct connection through a network (TCP Socket, Web socket, pure HTTP with Zinc) and/or with a serial connection. >>> At first, without any Â« security Â». But later, information exchanges will be encrypted. >>> >>> Iâve seen some information on how to use SerialPort, or even FileStream. >>> I could do it (or at least simulate it with HTTP). What are the other options ? Socket ? >>> Do we have P2P libs (I couldnât find) with eventually discovery features ? >>> >>> Any comment / suggestion / pointers are greatly welcome. >>> >>> TIA. >>> >>> CÃ©drick >>> >> >> > >

Oct. 25, 2017

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

by Denis Kudriashov

Yes, it is not part of Seamless. 2017-10-25 15:40 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: > I had a look and this is not (natively) possible. > > The idea of the off-line mode would be to delay messages that are sent to > the peer until a connection is established. > > I think I have to try to do it by myself (like having a list of > information exchange that wait until a connexion is established). > > What I try to do is not as complex as two general image exchanging > messages on objects (like on TelePharo). > > I just want a repository of information (mainly a collection of static > information/data versions) on both peers to be synchronized when a > connection is established. > > > > > > Le 25 oct. 2017 Ã 15:31, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit : > > What is offline mode? > > 2017-10-25 15:10 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: > >> Thanks Denis. I will ! I knew I have seen a telephoto component that >> could help but forgot about it ! >> >> Do you know if itâs possible to handle offline mode ? >> >> >> >> Le 25 oct. 2017 Ã 15:05, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit >> : >> >> Look at Seamless https://github.com/dionisiydk/Seamless. >> >> 2017-10-25 14:21 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: >> >>> Hi all, >>> >>> I want to connect two applications (1 by image, each one on a different >>> computer) so as as to exchange information (data) between them. >>> >>> So my question is about the best (smalltalk) practices to connect two >>> app/image and exchange data. >>> >>> I imagine either with a direct connection through a network (TCP Socket, >>> Web socket, pure HTTP with Zinc) and/or with a serial connection. >>> At first, without any Â« security Â». But later, information exchanges >>> will be encrypted. >>> >>> Iâve seen some information on how to use SerialPort, or even FileStream. >>> I could do it (or at least simulate it with HTTP). What are the other >>> options ? Socket ? >>> Do we have P2P libs (I couldnât find) with eventually discovery features >>> ? >>> >>> Any comment / suggestion / pointers are greatly welcome. >>> >>> TIA. >>> >>> CÃ©drick >>> >> >> >> > >

Oct. 25, 2017

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

by Sebastian Heidbrink

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. There is a lot of documentation around and it should be easy for you to dive into this. http://zguide.zeromq.org/page:all Cheers! Sebastian On 2017-10-25 05:21 AM, CÃ©drick BÃ©ler wrote: > Hi all, > > I want to connect two applications (1 by image, each one on a > different computer) so as as to exchange information (data) between them. > > So my question is about the best (smalltalk) practices to connect two > app/image and exchange data. > > I imagine either with a direct connection through a network (TCP > Socket, Web socket, pure HTTP with Zinc) and/or with a serial connection. > At first, without any Â«Â securityÂ Â». But later, information exchanges > will be encrypted. > > Iâve seen some information on how to use SerialPort, or even FileStream. > I could do it (or at least simulate it with HTTP). What are the other > options ? Socket ? > Do we have P2P libs (I couldnât find) with eventually discovery features ? > > Any comment / suggestion / pointers are greatly welcome. > > TIA. > > CÃ©drick

Oct. 25, 2017

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

by CÃ©drick BÃ©ler

I had a look and this is not (natively) possible. The idea of the off-line mode would be to delay messages that are sent to the peer until a connection is established. I think I have to try to do it by myself (like having a list of information exchange that wait until a connexion is established). What I try to do is not as complex as two general image exchanging messages on objects (like on TelePharo). I just want a repository of information (mainly a collection of static information/data versions) on both peers to be synchronized when a connection is established. > Le 25 oct. 2017 Ã 15:31, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit : > > What is offline mode? > > 2017-10-25 15:10 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com>>: > Thanks Denis. I will ! I knew I have seen a telephoto component that could help but forgot about it ! > > Do you know if itâs possible to handle offline mode ? > > > >> Le 25 oct. 2017 Ã 15:05, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> a Ã©crit : >> >> Look at Seamless https://github.com/dionisiydk/Seamless <https://github.com/dionisiydk/Seamless>. >> >> 2017-10-25 14:21 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com>>: >> Hi all, >> >> I want to connect two applications (1 by image, each one on a different computer) so as as to exchange information (data) between them. >> >> So my question is about the best (smalltalk) practices to connect two app/image and exchange data. >> >> I imagine either with a direct connection through a network (TCP Socket, Web socket, pure HTTP with Zinc) and/or with a serial connection. >> At first, without any Â« security Â». But later, information exchanges will be encrypted. >> >> Iâve seen some information on how to use SerialPort, or even FileStream. >> I could do it (or at least simulate it with HTTP). What are the other options ? Socket ? >> Do we have P2P libs (I couldnât find) with eventually discovery features ? >> >> Any comment / suggestion / pointers are greatly welcome. >> >> TIA. >> >> CÃ©drick >> > >

Oct. 25, 2017

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

by Denis Kudriashov

What is offline mode? 2017-10-25 15:10 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: > Thanks Denis. I will ! I knew I have seen a telephoto component that > could help but forgot about it ! > > Do you know if itâs possible to handle offline mode ? > > > > Le 25 oct. 2017 Ã 15:05, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit : > > Look at Seamless https://github.com/dionisiydk/Seamless. > > 2017-10-25 14:21 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: > >> Hi all, >> >> I want to connect two applications (1 by image, each one on a different >> computer) so as as to exchange information (data) between them. >> >> So my question is about the best (smalltalk) practices to connect two >> app/image and exchange data. >> >> I imagine either with a direct connection through a network (TCP Socket, >> Web socket, pure HTTP with Zinc) and/or with a serial connection. >> At first, without any Â« security Â». But later, information exchanges will >> be encrypted. >> >> Iâve seen some information on how to use SerialPort, or even FileStream. >> I could do it (or at least simulate it with HTTP). What are the other >> options ? Socket ? >> Do we have P2P libs (I couldnât find) with eventually discovery features ? >> >> Any comment / suggestion / pointers are greatly welcome. >> >> TIA. >> >> CÃ©drick >> > > >

Oct. 25, 2017

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

by CÃ©drick BÃ©ler

Thanks Denis. I will ! I knew I have seen a telephoto component that could help but forgot about it ! Do you know if itâs possible to handle offline mode ? > Le 25 oct. 2017 Ã 15:05, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit : > > Look at Seamless https://github.com/dionisiydk/Seamless <https://github.com/dionisiydk/Seamless>. > > 2017-10-25 14:21 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com>>: > Hi all, > > I want to connect two applications (1 by image, each one on a different computer) so as as to exchange information (data) between them. > > So my question is about the best (smalltalk) practices to connect two app/image and exchange data. > > I imagine either with a direct connection through a network (TCP Socket, Web socket, pure HTTP with Zinc) and/or with a serial connection. > At first, without any Â« security Â». But later, information exchanges will be encrypted. > > Iâve seen some information on how to use SerialPort, or even FileStream. > I could do it (or at least simulate it with HTTP). What are the other options ? Socket ? > Do we have P2P libs (I couldnât find) with eventually discovery features ? > > Any comment / suggestion / pointers are greatly welcome. > > TIA. > > CÃ©drick >

Oct. 25, 2017

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

by Denis Kudriashov

Look at Seamless https://github.com/dionisiydk/Seamless. 2017-10-25 14:21 GMT+02:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: > Hi all, > > I want to connect two applications (1 by image, each one on a different > computer) so as as to exchange information (data) between them. > > So my question is about the best (smalltalk) practices to connect two > app/image and exchange data. > > I imagine either with a direct connection through a network (TCP Socket, > Web socket, pure HTTP with Zinc) and/or with a serial connection. > At first, without any Â« security Â». But later, information exchanges will > be encrypted. > > Iâve seen some information on how to use SerialPort, or even FileStream. > I could do it (or at least simulate it with HTTP). What are the other > options ? Socket ? > Do we have P2P libs (I couldnât find) with eventually discovery features ? > > Any comment / suggestion / pointers are greatly welcome. > > TIA. > > CÃ©drick >

Oct. 25, 2017

Business process (declaration and orchestration), ontology/taxonomy,

by CÃ©drick BÃ©ler

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

Oct. 25, 2017

Cryptography and hashing in Pharo

by CÃ©drick BÃ©ler

Hi again, Concerning cryptography in Pharo, there are to my knowledge : => a package developed in squeak [1] that was I think ported/forked for Pharo. I cannot find the Pharo version => a binding to the sodium library (NaCl) [2] With one would you recommend ? Maybe another option ? Concerning hashing (Iâd like to hash information content a bit like this is done in ifs with their multihash lib [3]) => I found a keccak implication with I think would do the [4]. Any feedback ? Other implementations available ? => Do you think having something like ifs multihash would be interesting in Pharo ? Again, thanks in advance for your comments/advices. CÃ©drick [1] http://www.squeaksource.com/Cryptography.html <http://www.squeaksource.com/Cryptography.html> [2] http://catalog.pharo.org/catalog/project/Nacl?_s=54MCZlmxc6F08Ht4&_k=HxcBD1… <http://catalog.pharo.org/catalog/project/Nacl?_s=54MCZlmxc6F08Ht4&_k=HxcBD1…> [3] https://github.com/multiformats/multihash <https://github.com/multiformats/multihash> [4] https://github.com/sbragagnolo/Keccak <https://github.com/sbragagnolo/Keccak>

Oct. 25, 2017

Exchanging information between 2 pharo applications (2 images running on two different computers)

by CÃ©drick BÃ©ler

Hi all, I want to connect two applications (1 by image, each one on a different computer) so as as to exchange information (data) between them. So my question is about the best (smalltalk) practices to connect two app/image and exchange data. I imagine either with a direct connection through a network (TCP Socket, Web socket, pure HTTP with Zinc) and/or with a serial connection. At first, without any Â« security Â». But later, information exchanges will be encrypted. Iâve seen some information on how to use SerialPort, or even FileStream. I could do it (or at least simulate it with HTTP). What are the other options ? Socket ? Do we have P2P libs (I couldnât find) with eventually discovery features ? Any comment / suggestion / pointers are greatly welcome. TIA. CÃ©drick

Oct. 25, 2017

Re: [Pharo-users] Glorp: #includesKey:

by Herby VojÄÃk

jtuchel(a)objektfabrik.de wrote: > Herby, > > I must admit I've never used Dictionary Mappings with Glorp, so I don't > have an answer. > But I am a bit confused by your code examples. See below > > > Am 24.10.17 um 20:27 schrieb Herby VojÄÃk: >> Hello! >> >> I am using a DictionaryMapping in my code, and I wanted to use >> #includesKey: in #where: clause (something akin >> >> each tools includesKey: aToolId > > What SQL expression would you expect here? SELECT * FROM AGENT a WHERE a.tool_id = :aToolId AFAICT, DISTINCT is not needed as <id, tool_id> are fks to other table's compound primary key <agent_id, id>, so they are known to be unique. > I would guess that you want to build a subquery like exists, because the > way I understand the query, you want to find all instances of (whatever > each is) that hold an Association in their tools dictionary where the > key is aToolId. Yes. Maybe it needs EXISTS, I don't know. Semantics is clear, though. >> >> ) to select only rows for which DictionaryMapping uses certain key. It >> failed with the error in the lines of "#tools does not resolve to >> field". I had to come up with >> > >> each tools anySatisfy: [ :tool | tool id = aToolId ] > Hmm. This makes me wonder. Is #tools really a Dictionary? Inside the > Block, I'd expect the :tool parameter to be an Association, and that > doesn't understand #id,does it? I guess @each is the parameter within an > Block like in > > self session read: MyClass where: [:each| each tools ...] > > If so, I have a hard time believing that anySatisfy: would work (never > tried)... Yes, it works. Dictionary enumerates values, as I have written in reply to Tom's post. >> Is it the bug / feature / problem in my approach? If bug, is it >> planned to add #includesKey: translation to DictionaryMapping? >> > I don't know, but would guess it is not currently on the Todo-list. > > My first tip would be to try and find some slides (most likely made by > Niall and presented at an ESUG) including the words "subquery", "glorp" > and "exists". You won't find much, but that may be a starting point. I actually managed to get there, but a) using ugly workaround IMO, #includesKey: is part of dictionary's protocol, should be known; b) as I wrote in Tom's reply, the workaround only worked because mapping was to object. If the mapping was to primitive value (number, string), I would not have any 'tool id' ready to use and I would be left .... without option. There is no way to construct such query atm in Glorp, afaict, if I cannot use #keys not #includesKey: in where clause. Is that not a bug? > Not sure this helps, ;-) > > > Joachim Thanks, Herby

Oct. 25, 2017

Re: [Pharo-users] Glorp: #includesKey:

by Herby VojÄÃk

Tom Robinson wrote: > Hi Herby, > > In my opinion, the way you found to make it work is the way it should > be. The reason is that the first way doesn't translate into SQL and the > second one does. It might be possible to add includesKey: functionality > but resolving that to SQL would be more complex. I would not call this a I think I disagree with this, but correct me if I am wrong. With DictionaryMapping, you map a set of (key, value) pairs into appropriate fields in a table. In essence, it does not differ at all to mapping any other collection containing objects with fields (actually, from what I understood, it does internal tricks to do just that - create internal "class mapping" for an association of that particular dictionary mapping). In case of primitive value dictionaries, it even _is_ the same: key is mapped to one field, value is mapped to different field. If I want to create subquery using value, I can freely use things like #anySatisfy: to filter on that value (which I did in my case, but I come to that later). Since Dictionary enumerates values in do:, select:, collect: (and anySatisfy:), writing each tools anySatisfy: [...] is the same as writing each tools values anySatisfy: [...] but what if I wanted to write each tools keys anySatisfy: [...] ? I cannot, Glorp fails on 'keys' (I tried to use `keys includes:` instead of `includesKey:`, to no avail). So what I want to point here is, that in DictionaryMapping I map keys and values to different fields in table (values can be complex, in which keys they are mapped to more fields, but that is not important distinction here), but Glorp only allows me to use values (and only implicitly) in where clauses; I have no way to use keys at all there. So I assert here that "resolving that to SQL would be more complex" is not true. Key is mapped the same way value is; if I can use where clause that uses value in certain way, I should be able to use key as well - SQL generating from one or the other have same level of difficulty (in fact, I think key is easier, as you do not actually need to join the foreign table); the generated SQL could be something like SELECT * FROM AGENT a WHERE a.tool_id = <toolId asDbValue> The fact that I found a each tools anySatisfy: [ :tool | tool id = aToolId ] is in fact only because non-primitive mappings are processed differently in DictionaryMapping, a non-primitive values are _required_ to have a field defined (not in table, that is understandable, I need to be able to make a join, but in descriptor) a mapping that contains the key. So in essence, that could be represented as SELECT * FROM AGENT a WHERE a.tool_id IN (SELECT * FROM TOOL t WHERE t.agent_id = a.id AND t.id = a.tool_id AND t.id = <aToolId asDbValue>) which is basically same as above, as actually, "a.tool_id = <aToolId asDbValue>" is executed here as well (plus checking that such dictionary actually exists at all; maybe that should be present in previous case as well, but Glorp can generate the join, that's not the question here). It is actually interesting question what SQL Glorp actually generated for "TgAgent readOneOf: [:a|a tools anySatisfy: [:t|t id = toolId]]". Point here is: 1. Why do I need to work it around via [:tool | tool id = aToolId] when I am only interested on "which tools the agent uses" (in fact, give me all agents using this tool). 2. Should this be key -> primitive value mapping, I have simple _no way_ to ask the equivalent of #includesKey: at all (as the value is, for example, a String or an Integer, so no `tool id` is available). > bug. I would call it a limitation of the implementation. I don't know of > anyone planning to add this feature to Glorp right now. That's why I would say #keys (and, ideally, #includesKey:) are actually needed addition to Glorp's set of known-and-translated selectors in case of DictionaryMapping. > Regards, > > Tom Thanks, Herby

Oct. 25, 2017

Re: [Pharo-users] Territorial loading problems & alternative ways of loading data for making a choropleth map

by Tudor Girba

You can directly use the Roassal presentation gtInspectorExtension: composite <gtInspectorPresentationOrder: 20> composite roassal2 title: â...' initializeView: [ YourViewOrBuilder ]; painting: [ :yourViewOrBuilder | â¦ ] Doru > On Oct 25, 2017, at 5:57 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > 2017-10-24 15:24 GMT-03:00 Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com>: >> Gracias HernÃ¡n! >> > > No problema :) > >> This is working fine. I would like to put the displayed map inside the >> GT playground right panel, to get something similar to what you get when >> you execute "RTMapLocationExample new exampleSeismOnEarth" from a >> playground. Do you have any planned support for that? >> > > I know this should be as easy as adding a > <gtInspectorPresentationOrder: ... > pragma > > gtInspectorViewIn: composite > <gtInspectorPresentationOrder: 60> > > composite morph > title: 'Territorial Map'; > display: [ view build ] > > but still I have to investigate how to connect a RTView or TRMorph > with GT inspector > >> I could try to use some similar approach to the one I take on the Panama >> Papers choropleth map [1][2] to export some Territorial data for >> visualizations in a light format (120kb file example at: [3]), if you're >> interested. >> >> [1] http://mutabit.com/offray/blog/en/entry/panama-papers-1 >> [2] http://mutabit.com/repos.fossil/panama-papers/doc/tip/index.html >> [3] http://mutabit.com/repos.fossil/panama-papers/doc/tip/territories.ston >> > > Super! It would be nice to see usage in other scenarios! > Let me know how it goes. > > Cheers, > > HernÃ¡n > >> Cheers, >> >> Offray >> >> >> On 23/10/17 23:21, HernÃ¡n Morales Durand wrote: >>> Hola Offray, >>> >>> I tried loading in Windows 8.1 and it loads fine using: >>> >>> Metacello new >>> smalltalkhubUser: 'hernan' project: 'Territorial'; >>> configuration: 'Territorial'; >>> version: #bleedingEdge; >>> load. >>> >>> Then load TerritorialData-AMCharts-HernanMoralesDurand.2 from the repository. >>> >>> I published some "fixes" related to Spec and Roassal. (I have to >>> review them because I'm porting other packages to Pharo 6.1, but it >>> should work for displaying maps). >>> >>> The following expression displays a window with Colombia departments: >>> >>> TerritorialAMChartsMapsProvider viewHighResCountry: 'Colombia' >>> >>> For a choropleth with a heatmap or centroids have a look at how I did >>> it in PhyloclassTalk in SmalltalkHub, again I should update it to work >>> in Pharo 6.1. >>> >>> Cheers, >>> >>> HernÃ¡n >>> >>> >>> >>> 2017-10-23 22:59 GMT-03:00 Offray Vladimir Luna CÃ¡rdenas >>> <offray.luna(a)mutabit.com>: >>>> Hi, >>>> >>>> I would like a choropleth map of Colombian departments [1]. The first >>>> approach would be to use Territorial, but loading it is not working on >>>> Pharo 6.1 (used on Manjaro Linux): It doesn't appears in the Catalog, >>>> Gopher load gives me: "XMLFileException: File does does not exist: >>>> /home/offray/Programas/Pharo/6.1a/Dev24/territorial_files/fao/fao_country_names.xml" >>>> and loading Monticello bleeding edge gives me "FileDoesNotExist: File @ >>>> /home/offray/Programas/Pharo/6.1a/Dev24/territorial_files/opengeocode/wc-ASCII.csv". >>>> There is another way to make such choropleth map? >>>> >>>> [1] https://en.wikipedia.org/wiki/Departments_of_Colombia >>>> >>>> Thanks, >>>> >>>> Offray >>>> >>>> >>>> >> >> >> > -- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."

Oct. 25, 2017

Re: [Pharo-users] CodeCity like visualization in Linux

by Stephane Ducasse

you can show them cvs file 'my.cvs' asFileReference and inspect you get a table :) but it is still a file reference Same with zip file Check the videos of the mooc on GTInspector Stef On Wed, Oct 25, 2017 at 11:35 AM, Rafael Luque <rafael.luque.leiva(a)gmail.com> wrote: > Great! Thank you Doru. > > > > â > > 2017-10-25 10:36 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >> Hi, >> >> Indeed, the image was for Mac, but unfortunately I do not know if it works >> on Linux. >> >> But, for your talk, there are other cool things that you can show in the >> latest Moose. If you are interested, please contact me directly. >> >> Cheers, >> Doru >> >> >> > On Oct 25, 2017, at 9:39 AM, Rafael Luque <rafael.luque.leiva(a)gmail.com> >> > wrote: >> > >> > Thank you for your help Tudor. >> > >> > I'm trying with the CodeCity image I've downloaded from your post >> > (http://www.humane-assessment.com/blog/communicating-changes-in-pharo-3-0) >> > and I get the error "MessageNotUnderstood: receiver of "platformId" is nil" >> > in the NBMacGLContextDriver class>>supportsCurrentPlatform method. >> > >> > By this reason I thought it only works on Mac or maybe I must previously >> > configure something to get the NativeBoost working on Linux. >> > >> > Thank you. >> > >> > >> > >> > â >> > >> > 2017-10-25 9:02 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> > CodeCity only works in Pharo 3 (or maybe also 4). >> > >> > Doru >> > >> > >> > > On Oct 25, 2017, at 1:38 AM, Rafael Luque >> > > <rafael.luque.leiva(a)gmail.com> wrote: >> > > >> > > Hi all, >> > > >> > > I'm working on an introductory talk about Pharo for a software >> > > craftsmanship local meetup. >> > > >> > > The presentation will be mainly driven by demos and I'd like to show a >> > > CodeCity-like visualization. I've been able to load it in Pharo 5, but it >> > > get an error when select the "City" tag in GTInspector. It seems that >> > > NBOpenGL does not work in Linux. >> > > >> > > Do you know any way to make it work in Linux? >> > > >> > > Thank you. >> > > â >> > >> > -- >> > www.tudorgirba.com >> > www.feenk.com >> > >> > "Presenting is storytelling." >> > >> > >> > >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Being happy is a matter of choice." >> >> >> >> >> >

Oct. 25, 2017

Re: [Pharo-users] CodeCity like visualization in Linux

by Rafael Luque

Great! Thank you Doru. â 2017-10-25 10:36 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Indeed, the image was for Mac, but unfortunately I do not know if it works > on Linux. > > But, for your talk, there are other cool things that you can show in the > latest Moose. If you are interested, please contact me directly. > > Cheers, > Doru > > > > On Oct 25, 2017, at 9:39 AM, Rafael Luque <rafael.luque.leiva(a)gmail.com> > wrote: > > > > Thank you for your help Tudor. > > > > I'm trying with the CodeCity image I've downloaded from your post ( > http://www.humane-assessment.com/blog/communicating-changes-in-pharo-3-0) > and I get the error "MessageNotUnderstood: receiver of "platformId" is nil" > in the NBMacGLContextDriver class>>supportsCurrentPlatform method. > > > > By this reason I thought it only works on Mac or maybe I must previously > configure something to get the NativeBoost working on Linux. > > > > Thank you. > > > > > > > > â > > > > 2017-10-25 9:02 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > CodeCity only works in Pharo 3 (or maybe also 4). > > > > Doru > > > > > > > On Oct 25, 2017, at 1:38 AM, Rafael Luque < > rafael.luque.leiva(a)gmail.com> wrote: > > > > > > Hi all, > > > > > > I'm working on an introductory talk about Pharo for a software > craftsmanship local meetup. > > > > > > The presentation will be mainly driven by demos and I'd like to show a > CodeCity-like visualization. I've been able to load it in Pharo 5, but it > get an error when select the "City" tag in GTInspector. It seems that > NBOpenGL does not work in Linux. > > > > > > Do you know any way to make it work in Linux? > > > > > > Thank you. > > > â > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Presenting is storytelling." > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Being happy is a matter of choice." > > > > > >

Oct. 25, 2017

[ANN] LAM Research upgraded to Platinum Membership

by Marcus Denker

The Pharo Consortium is very happy to announce that LAM Research has upgraded to Platinum Member status. About - LAM Research: http://www.lamresearch.com - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

Oct. 25, 2017

Re: [Pharo-users] CodeCity like visualization in Linux

by Tudor Girba

Hi, Indeed, the image was for Mac, but unfortunately I do not know if it works on Linux. But, for your talk, there are other cool things that you can show in the latest Moose. If you are interested, please contact me directly. Cheers, Doru > On Oct 25, 2017, at 9:39 AM, Rafael Luque <rafael.luque.leiva(a)gmail.com> wrote: > > Thank you for your help Tudor. > > I'm trying with the CodeCity image I've downloaded from your post (http://www.humane-assessment.com/blog/communicating-changes-in-pharo-3-0) and I get the error "MessageNotUnderstood: receiver of "platformId" is nil" in the NBMacGLContextDriver class>>supportsCurrentPlatform method. > > By this reason I thought it only works on Mac or maybe I must previously configure something to get the NativeBoost working on Linux. > > Thank you. > > > > â > > 2017-10-25 9:02 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > CodeCity only works in Pharo 3 (or maybe also 4). > > Doru > > > > On Oct 25, 2017, at 1:38 AM, Rafael Luque <rafael.luque.leiva(a)gmail.com> wrote: > > > > Hi all, > > > > I'm working on an introductory talk about Pharo for a software craftsmanship local meetup. > > > > The presentation will be mainly driven by demos and I'd like to show a CodeCity-like visualization. I've been able to load it in Pharo 5, but it get an error when select the "City" tag in GTInspector. It seems that NBOpenGL does not work in Linux. > > > > Do you know any way to make it work in Linux? > > > > Thank you. > > â > > -- > www.tudorgirba.com > www.feenk.com > > "Presenting is storytelling." > > > -- www.tudorgirba.com www.feenk.com "Being happy is a matter of choice."

Oct. 25, 2017