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, p...@highoctane.be
<[p...@highoctane.be]("mailto:p...@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
> <[aglyn...@gmail.com]("mailto: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]("mailto:pharo-users-boun...@lists.pharo.org";)>
>> on behalf of David Mason <[dma...@ryerson.ca]("mailto:dma...@ryerson.ca";)>
>> Reply-To: Any question about pharo is welcome
>> <[pharo-users@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@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,
>> [jtuc...@objektfabrik.de]("mailto:jtuc...@objektfabrik.de";)
>> <[jtuc...@objektfabrik.de]("mailto: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]("mailto:jtuc...@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")
