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 <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-na >> tive-access/jna the same way we use C with UFFI. >> >> >> >> Smalltalk argument for me is that it makes development bearable (even fun >> and enjoyable would I say) vs the other stacks. That matters. >> >> >> >> Phil >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <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 >> >> >> >> >> >> >> > >
