Elastic search JSON integration would be another good one. I heard there was a
Kafka integration, is that true? Where could I find that, I used to use Kafka.
Kafka is a great event channel for input to BigData. Using Kafka, it is well in
crafting a Lamda Architecture. Imagine Pharo where Storm resides.
- HH
On Fri, Oct 27, 2017 at 16:51, henry
<[he...@callistohouse.club]("mailto:he...@callistohouse.club";)> wrote:
> How about Kerberos? Can we get a team to look closely at bringing
> integration for enterprise users? That would be helpful, or can you just put
> it behind a Kerberos wrapper? If that would work, collecting a demo, that
> could unlock more corporate wallets , for investment.
>
> - HH
>
> On Fri, Oct 27, 2017 at 16:41, henry
> <[he...@callistohouse.club](""mailto:he...@callistohouse.club"";)> wrote:
>
>> How is there no steering committee to accumulate wrapping 3rd party
>> libraries in Alien to gain benefits of code in other languages? Do not
>> assume that code is not extremely well written in that particular language
>> for that particular task and that particular deployment mechanism.
>>
>> Can Pharo be called as a shared library from Java JNA?
>>
>> - HH
>>
>> On Fri, Oct 27, 2017 at 15:47, Andrew Glynn
>> <[aglyn...@gmail.com](""mailto:aglyn...@gmail.com"";)> wrote:
>>
>>> I’m not claiming I don’t or haven’t been affected, only that I no long
>>> allow myself to be. Does that cause issues? Of course. But I’d rather
>>> deal with those than do things I don’t enjoy. However I only got to that
>>> point after 26 years in the industry, so I don’t expect that everyone will
>>> feel that way.
>>>
>>> Cheers
>>>
>>> Andrew
>>>
>>> Sent from [Mail](""https://go.microsoft.com/fwlink/?LinkId=550986"";) for
>>> Windows 10
>>>
>>> From: [jtuc...@objektfabrik.de](""mailto:jtuc...@objektfabrik.de"";)
>>> Sent: Thursday, October 26, 2017 8:14 AM
>>> To: [pharo-users@lists.pharo.org](""mailto:pharo-users@lists.pharo.org"";)
>>> Subject: Re: [Pharo-users] Smalltalk Argument
>>>
>>> Andrew,
>>>
>>> Am 26.10.17 um 00:46 schrieb Andrew Glynn:
>>>
>>>> There’s other questions that are relevant to me:
>>>
>>> I am glad you opened your words with this sentence. Other peoples’ mileages
>>> may vary a lot.
>>>
>>>> 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.
>>>
>>> Some people can’t. I can’t. I am making my living with a web based
>>> application. And I like 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.>
>>>
>>> So you are in the lucky position that neither mobile nor web nor
>>> integration matters to you or you have enough resources to do all that
>>> stuff yourself. I am envyous. I need to build web pages and people ask me
>>> whether we can ship an iPhone App. I do customer-facing stuff and sex sells
>>> much more than we like to think.
>>>
>>> Your comments on the crappiness of libs in other languages is a great fit
>>> for Smalltalk. Not invented here, therefor rubbish. We came a long way with
>>> this way of thinking. But these rubbish makers dance circles around us
>>> while we try to do our first hello world for an iPad. They laugh at us when
>>> we try to reinvent MVC on top of Seaside (although MVC is closesly related
>>> to Smalltalk). Because they are back home and watch Netflix while we debug
>>> our homegrown base libraries that are, of course, much better than theirs
>>> because they are written in Smalltalk.
>>>
>>> I am not arguing that maintaining Smalltalk code is far superior to most
>>> technolgies out there. But depending on the needs of our projects we have
>>> to learn and use those crappy technologies to accomplish what they offer.
>>> Because, sometimes (especially if you have to pay bills), an existing
>>> library with flaws is better than none.
>>>
>>> So if I have to use Javascript or C# or Dart or Swift to do the frontend
>>> part of my system, is there still much benefit in using these together with
>>> Smalltalk? Or is there - at least from a manager’s point of view - not a
>>> reasonable amount of sense in choosing the frontend technology also for the
>>> logic and compensate the loss in productivity with a gain in avoided
>>> complexity?
>>>
>>> Your answer delivers a lot of food for thought, but I don’t buy all of it.
>>> And I don’t expect you to buy all of mine ;-)
>>>
>>> Joachim
>>>
>>>>
>>>>
>>>> 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"")
>>>
>>> —
>>>
>>> ————————————————————————
>>>
>>> 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 Fax: +49 7141 56 10 86 1
