I referred to a Lambda Architecture, not the availability of Lambdas in the
language. Pharo has the best with BlockClosures.
- HH
> -------- Original Message --------
> Subject: RE: [Pharo-users] Smalltalk Argument
> Local Time: October 27, 2017 11:10 PM
> UTC Time: October 28, 2017 3:10 AM
> From: aglyn...@gmail.com
> To: henry <he...@callistohouse.club>, Any question about pharo iswelcome
> <pharo-users@lists.pharo.org>
>
> Last point. Blocks are already better lambdas than lambdas in Java.
>
> Have a look at this code from rxJava, which includes the Java 8 lambda
> version and a Java 7 version using an anonymous inner class:
>
> Java 8 code
>
> package
>
> rxjava.examples
>
> ;
>
>
>
> import
>
> io.reactivex.*
>
> ;
>
>
>
> public
>
> class
>
> HelloWorld
>
> {
>
>
>
> public
>
> static
>
> void
>
> main
>
> (
>
> String
>
> []
>
> args
>
> ) {
>
>
>
> Flowable
>
> .
>
> just(
>
> "
>
> Hello world
>
> "
>
> )
>
> .
>
> subscribe(
>
> System
>
> .
>
> out
>
> ::
>
> println);
>
> }
>
> }
>
> Java 7 code
>
> import
>
> io.reactivex.functions.Consumer
>
> ;
>
>
>
> Flowable
>
> .
>
> just(
>
> "
>
> Hello world
>
> "
>
> )
>
> .subscribe(
>
> new
>
> Consumer<
>
> String
>
>>
>
> () {
>
>
>
> @Override
>
> public
>
> void
>
> accept
>
> (
>
> String
>
> s
>
> ) {
>
>
>
> System
>
> .
>
> out
>
> .
>
> println(s);
>
> }
>
> });
>
> Are they equivalent? How would you know?
>
> In fact, they aren’t, worse, the results of the difference depend on the
> target, whether it’s Java SE (including Spring based apps) or JavaEE.
>
> The Java 8 version doesn’t create an anonymous inner class but a generically
> named class with generically named methods. As a result, it will be most
> often faster. However it’s less safe, because particularly in clustered
> environments, and unpredictably, it can create conflicts due to the same
> generic names being used by two different JVM’s. The Java 7 version will be
> as fast, in JavaEE, and safer. In Java SE they’re close to equivalently
> safe, but the Java 7 version will be significantly slower in most cases.
>
> RxJava itself, as well, is unnecessary in Pharo, since the Announcer already
> implements the same pattern, and does so in a more efficient and more
> consistent way.
>
> Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows
> 10
>
> From: [henry](mailto:he...@callistohouse.club)
> Sent: Friday, October 27, 2017 5:03 PM
> To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org)
> Subject: Re: [Pharo-users] Smalltalk Argument
>
> 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.
>
> [webkit-fake-url://502df029-af7a-484e-b157-43970b30a0a1/imagejpeg]
>
> - HH
>
> On Fri, Oct 27, 2017 at 16:51, henry <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](%22mailto:he...@callistohouse.club%22)> 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](%22mailto:aglyn...@gmail.com%22)> 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](%22https:/go.microsoft.com/fwlink/?LinkId=550986%22) for
>>>> Windows 10
>>>>
>>>> From: [jtuc...@objektfabrik.de](%22mailto:jtuc...@objektfabrik.de%22)
>>>> Sent: Thursday, October 26, 2017 8:14 AM
>>>> To: [pharo-users@lists.pharo.org](%22mailto:pharo-users@lists.pharo.org%22)
>>>> 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>](%22mailto:pharo-users-boun...@lists.pharo.org%22)
>>>>> on behalf of David Mason
>>>>> [<dma...@ryerson.ca>](%22mailto:dma...@ryerson.ca%22)
>>>>> Reply-To: Any question about pharo is welcome
>>>>> [<pharo-users@lists.pharo.org>](%22mailto:pharo-users@lists.pharo.org%22)
>>>>> Date: Tuesday, October 24, 2017 at 11:52 AM
>>>>> To: Any question about pharo is welcome
>>>>> [<pharo-users@lists.pharo.org>](%22mailto:pharo-users@lists.pharo.org%22)
>>>>> 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](%22http:/pharojs.org%22)
>>>>>
>>>>> 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](%22mailto:jtuc...@objektfabrik.de%22)
>>>>> <[jtuc...@objektfabrik.de](%22mailto:jtuc...@objektfabrik.de%22)> 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](%22mailto:jtuc...@objektfabrik.de%22)
>>>>>> Fliederweg 1
>>>>>> [http://www.objektfabrik.de](%22http:/www.objektfabrik.de%22)
>>>>>> D-71640 Ludwigsburg
>>>>>> [http://joachimtuchel.wordpress.com](%22http:/joachimtuchel.wordpress.com%22)
>>>>>> Telefon: [+49 7141 56 10 86
>>>>>> 0](%22tel:%2B49%207141%2056%2010%2086%200%22) Fax: [+49 7141 56
>>>>>> 10 86 1](%22tel:%2B49%207141%2056%2010%2086%201%22)
>>>>
>>>> —
>>>>
>>>> ————————————————————————
>>>>
>>>> Objektfabrik Joachim Tuchel
>>>> [mailto:jtuc...@objektfabrik.de](%22mailto:jtuc...@objektfabrik.de%22)
>>>>
>>>> Fliederweg 1
>>>> [http://www.objektfabrik.de](%22http:/www.objektfabrik.de%22)
>>>>
>>>> D-71640 Ludwigsburg
>>>> [http://joachimtuchel.wordpress.com](%22http:/joachimtuchel.wordpress.com%22)
>>>>
>>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
