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