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 <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 Fax: +49 7141 56 10 86 1 > > > > > > >
