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
