Hi Andrew, Are you working to bring a Capabilities model to Pharo? This is precisely what I am working to bring with Hubbub, running on top of my ParrotTalk. I derived these from erights.org's ELib and have been working on them for many years. Now that ParrotTalk has stabilized (layer 5) I am shifting to implementing marshalling of layer 6 objects using STON all to run on top of ParrotTalk. Once I get marshalling with scope substitutions, I will debug Hubbub to offer distributed Capabilities.
What work are you undertaking? Regards, - HH > -------- Original Message -------- > Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment > Local Time: October 28, 2017 9:12 AM > UTC Time: October 28, 2017 1:12 PM > From: aglyn...@gmail.com > To: Any question about pharo is welcome <pharo-users@lists.pharo.org> > > Writing that kind of code is another of the reasons I decided I don’t want to > work in anything else 😊. Maybe more important than some of the others, both > to myself and to other users. > > I’ve gained so much personally, mostly for nothing, even just considering the > relatively few projects I have been able to work on in Pharo and previously > in Squeak, VW and VA. Unfortunately in most I haven’t been able to make the > code public, since they were for entities like the government, DoD, etc. > > Not that VA attracts me quite so much to give back all that strongly, when a > license is $8500+. Were it possible to give back to VA C++ or VA Java, it > might be different, but neither were OSS although they weren’t expensive. > More relevantly, both are now abandonware (hence my comment about IBM, which > is applicable to OS/2 as well, although that has quietly had a 5.0 version > released in June of this year). > > I would, though, love a chance to give back to Pharo primarily, although I > may port anything relevant to Squeak, and if I have sufficient time port it > to VW, which although not OSS is at least affordable to most developers. > > I’m nearly there on a couple of projects – one I’m testing and making final > tweaks, another is about 2/3d’s of the way. > > The first project you (and others on the list) may be more immediately > interested in testing, since it requires little to no additional work to use > it, and even if not perfect, since it’s intended to directly help work you > are doing in Pharo, it may worthwhile. I’m hoping to have it ready for > public consumption by the middle of November. > > On a different but related topic, the article I wrote got a fair amount of > interest considering I don’t write nearly as well as Kenneth, for example. > Including direct interest from some well known industry people, which can’t > hurt. In an indirect way it may even be helpful, but not in the real, direct > way decent code is. > > Capabilities that won’t be available in anything else in an really usable way > (because to be efficient they depend on capabilities not found in anything > else), and in any case nowhere near as useful in anything else, will > hopefully be more use than any article can be, never mind one I wrote, not > just to me but also to other Pharo users and to Pharo itself. > > Cheers > > Andrew Glynn > > Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows > 10 > > From: [Stephane Ducasse](mailto:stepharo.s...@gmail.com) > Sent: Saturday, October 28, 2017 5:09 AM > To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org) > Subject: Re: [Pharo-users] Smalltalk Argument > > Hi andrew > > please take a project that would help to bring more companies and that you > want to push and push it with us :). > > Stef > > On Sat, Oct 28, 2017 at 11:05 AM, Stephane Ducasse <stepharo.s...@gmail.com> > wrote: > >> Hi andrew >> >> you should contact esteban because he is writing an objective-C bridge. >> >> Stef >> >> On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglyn...@gmail.com> wrote: >> >>> One thing I’m working on is a bridge between Pharo and F-Script. F-Script >>> is, basically, a Smalltalk dialect, as is obvious from the screenshot. >>> However for MacOS and iOS, it allows you to bypass the static Objective-C >>> API interface and debug / modify or even write applications directly in the >>> system. To do that you ‘inject’ F-Script into the OS. The ability to so >>> has a specific implication, though. MacOS and iOS are themselves written >>> in and as a dialect of Smalltalk. (were it simply an overlay on >>> Objective-C, it wouldn’t be able to do things that are impossible in >>> Objective-C, and it wouldn’t need to be ‘injected’ in order to run). Every >>> implementation of Objective-C , bar GNU’s useless imitation, compiles to >>> Smalltalk. No surprise that Apple’s does, as well. >>> >>> In any event, it will allow Pharo code to be mapped to MacOS and iOS >>> objects, injected into the system dynamically, and modified / debugged >>> dynamically using the Pharo tools. The result, at least as far as iOS is >>> concerned, may make Pharo actually the most powerful way to program it, >>> well beyond XCode alone, along with doing the same for MacOS. Android is >>> another issue, although the Raspbian port of Pharo should be relatively >>> easy to port to it. For me, unless someone had a use case, I don’t have one >>> myself for Android. I’ve tried nearly every version, because I’d love to >>> support an OSS ecosystem, unfortunately using it compared to the iPhone is >>> still like driving a Fiero based kit car compared to an actual Ferrari. >>> >>> As far as JNI, while I see your point, JNI is such a PITA that few Java >>> developers know it. My usual workaround is to use Stamp and Synapse, which >>> has the further advantage of allowing Java to ‘throttle’ data that the JVM >>> can’t deal with at full speed. >>> >>> As far as dealing with other JVM languages, PetitParser or SmaCC can >>> generate bytecode rather than Java or other JVM code, and that allows libs >>> to be written that utilize Synapse to talk to Pharo. It isn’t necessarily >>> an ideal solution, but a possible one without having to support umpteen >>> environments. Another potential way of accomplishing that is to use >>> NetRexx, a declarative JVM language, which is both easy and terse, and like >>> SQL, generates the actual bytecode rather than precompiling to it. For >>> instance, imagine the code needed for a simple ‘hello world’ in Java, then >>> compare: >>> >>> Say ‘hello world’ >>> >>> Since it generates virtually the same bytecode, it may be an easy way to do >>> it. >>> >>> With the last statement, that expresses really well the exact reason I no >>> longer want to work in most other environments 😊. >>> >>> Tc >>> >>> Andrew >>> >>> Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for >>> Windows 10 >>> >>> From: p...@highoctane.be >>> Sent: Thursday, October 26, 2017 2:19 AM >>> To: [Any question about pharo is >>> welcome](mailto:pharo-users@lists.pharo.org) >>> >>> Subject: Re: [Pharo-users] Smalltalk Argument >>> >>> I like that piece a lot, seeing exactly the described situation in large >>> enterprises. >>> >>> I made a strategic decision to go with Pharo for the long run for my >>> solutions because it is a stable base on which to build (ok, there are >>> evolutions, but fundamentally, I can rely on it being under control and can >>> maintain solutions in a version). >>> >>> The rationale is that at a deep level I am really fed up with having to >>> deal with accidental complexity (now having to deal with >>> Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology >>> drag and 20% net business contribution. >>> >>> One key thing is that a team needs guidance and Smalltalk makes it easier >>> due to well known ways of doing things. >>> >>> Now we miss the boat on mobile and bigdata, but this is solvable. >>> >>> If we had an open Java bridge (and some people in the community have it for >>> Pharo but do not open source it - so this is eminently doable) + Pharo as >>> an embeddable piece (e.g. like Tcl and Lua) and not a big executable we >>> would have a way to embed Pharo in a lot of places (e.g. in the Hadoop >>> ecosystem where fast starting VMs and small footprint would make the >>> cluster capacity x2 or x3 vs uberjars all over the place) this would be a >>> real disruption. >>> >>> Think about being able to call Pharo from JNA >>> https://github.com/java-native-access/jna the same way we use C with UFFI. >>> >>> Smalltalk argument for me is that it makes development bearable (even fun >>> and enjoyable would I say) vs the other stacks. That matters. >>> >>> Phil >>> >>> On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglyn...@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-boun...@lists.pharo.org> on behalf of David >>>> Mason <dma...@ryerson.ca> >>>> Reply-To: Any question about pharo is welcome <pharo-users@lists.pharo.org> >>>> Date: Tuesday, October 24, 2017 at 11:52 AM >>>> To: Any question about pharo is welcome <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, jtuc...@objektfabrik.de >>>> <jtuc...@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:jtuc...@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)
