Smalltalk Argument

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
95 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

kilon.alios
Actually you need to read the small letters bellow the graph

"% of developers who are developing with the language or technology and have expressed interest in continuing to develop with it"

which means basically "Smalltalkers love Smalltalk !!!|" . Actually I am surpised its only 67% of Smalltalkers that actually love Smalltalk and that Rust comes first. I was expecting a 90%. But then Rust has been the most hyped language these past few years. 

But does not change the fact that maybe 99% of the coders have not even heard of Smalltalk and a 60% of Rust.

The bottom line is that the excuses for not using a language can no longer stand in 2017
(1) But I wont find coders for it
(2) But I wont find libraries for it
(3) But I wont find documentation for it

Let's take (1) , why you even need to find someone that already knows the language? Do we realise there are people with zero coding experience that have made built milti million dollar empires . Almost 2 decades ago I remember reading about q surfer that loved to surf but also made surf boards. So inside his naiveness said "well let's make an e-shop" and he made alone one of the first e-shops selling surf boards and he made millions. 

So we have this guy that knows nothing about coding, I think I remember him saying that he did not even know how to use a computer before, on one side that in a period of few years has made a multi million dollars software.

On the other side we have experienced coders, that most likely have battled with code bases of millions of lines of code , university degree, masters and doctorate and they cannot do what a surfer did ? Seriously....

(2) That's my favourite , libraries. We live in 2017 when even my grandmother's language run on JVM and has JS compiler and we still debate libraries availability ? Seriously. You can use ANY library from ANY language and is not even hard. I made Pharo use Python libraries and it took me a few hundreds lines of code just to make a simple socket bridge. 

(3) This one is the most logical, even when I i started coding in Pharo and to be fair Pharo was still on very early releases there was minimal documentation and the one I found was outdated. Still no problemo, I am a coder, I can read code. You will be reading tons and tons of code anyway, documentation in any language will never take you far.
Why ? 
Because the vast majority of users prefer the easy and generic features. A minority of people dive deep into a library and the ones they do rare document it. 
You are more likely to find specialised information in mailing and forums than in documentation documents. Of course even there you may get no answer so you end up testing and learning yourself. Wont mattter even if it is Java.

Plus there are tons and ton of project made in languages very unpopular that did great, Ruby On Rails is an example. One library it was all it took to put Ruby on map. 

Even C was introduce through the Unix operating system. New language, out of nowhere and wait those people using an unknown language wanted to make one of the best OSes of all time. 

So no, even though I rarely get into a language debate because of how religious people , there is no for not using Pharo but any unpopular language out there. Because in the end what it will matter the most is the determination of the coder to output efficient code. If you are passionate about something nothing can stop you and especially these bad excuses. Pretty much the most important ingredient for any very successful software product.

On Fri, Oct 20, 2017 at 11:37 AM Paulo R. Dellani <[hidden email]> wrote:
I also do not believe my eyes:

https://insights.stackoverflow.com/survey/2017#most-loved-dreaded-and-wanted


On 10/20/2017 10:20 AM, Marten Feldtmann wrote:
> I do not want to spoil the party (perhaps I've done this already) - but
> has anyone done a serious inspection of this number: 67%.
>
> They have interviewed 64000 persons and 67% of the people should "love"
> Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the
> user already using Smalltalk "love" that.
>
> By the way - the most loved platform is Linux (69%) ...
>
>
> Marten
>
> Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani:
>
>> The second most loved language by 67% of developers surveyed cannot simply
>> be ruled out because of unfounded concerns. (Thanks again for the
>


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

Peter Fisk
In reply to this post by jtuchel
Thank you Joachim!

That is the most honest assessment of the situation of Smalltalk in 2017 that I have ever seen.

And I agree with you 100%.

We need a new Smalltalk which is both "cool" and can seamlessly integrate with all of the latest web technologies.

I will be releasing a new Smalltalk framework very shortly called "Smalltalk Express".

The interpreter is written in the "Go" language and can run on all of the major web platforms such as Google, Heroku, etc.

I use Pharo to manage the Smalltalk code.

Here is a new blog that I have started to discuss the project.


Also, I have reserved the web address "smalltalk.express" for use once the code goes live.

There is a video in the blog post so you can get an idea of where things stand right now.

-- Peter





On Fri, Oct 20, 2017 at 3:23 AM, [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.


Okay, shoot ;-)

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" value="+4971415610860" target="_blank">+49 7141 56 10 86 0         Fax: <a href="tel:%2B49%207141%2056%2010%2086%201" value="+4971415610861" target="_blank">+49 7141 56 10 86 1



Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

horrido
In reply to this post by itlists@schrievkrom.de
To quote from  The Wisdom of the Crowd
<https://hackernoon.com/the-wisdom-of-the-crowd-c7aff954bd5f>  :

The crowd is indeed wise. This wisdom shows up in the  latest StackOverflow
survey
<https://insights.stackoverflow.com/survey/2017#technology-most-loved-dreaded-and-wanted-languages>
, as well. Under “Most Loved Languages,” Smalltalk shows up in clear second
place (after Rust and before TypeScript, Swift, Go, Python, Elixir, and C#).
This shows that people who’ve used Smalltalk love the language and are loyal
to it.

It also shows, by inference, that the programming community is not aware of
how good Smalltalk is. Most in the community wallow in ignorance over it.
/If they were to try Smalltalk programming, the language would very likely
become popular./



[hidden email] wrote

> I do not want to spoil the party (perhaps I've done this already) - but
> has anyone done a serious inspection of this number: 67%.
>
> They have interviewed 64000 persons and 67% of the people should "love"
> Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the
> user already using Smalltalk "love" that.
>
> By the way - the most loved platform is Linux (69%) ...
>
>
> Marten
>
> Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani:
>
>>
>> The second most loved language by 67% of developers surveyed cannot
>> simply
>> be ruled out because of unfounded concerns. (Thanks again for the
>
>
> --
> Marten Feldtmann





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

horrido
In reply to this post by Pharo Smalltalk Users mailing list
Of all the responses here, I like this one the best because it's right on the
money.

In my long career, I've been dropped into many software projects where I had
to quickly ramp up with a new programming language. The employer didn't hire
me for my language expertise; they hired me for my programming skill and
ability to deliver good quality software on time. The programming tool used
was a mere technicality, and hardly an obstacle.

There is not a software developer alive who can coast through their entire
career without ever needing to pick up another programming language. This is
simply not an issue except for the most myopic of employers.



Pharo Smalltalk Users mailing list wrote

> Hi Paulo,
>
> I think this is not the right question to ask.
> The problem is not "Where to find Smalltalk developers?", the problem is
> rather
> "How much effort does it take to help a good experienced OO developer to
> transition to Smalltalk?"
>
> OO developers have to steadily gain and learn new technologies and
> frameworks...
> So why not Smalltalk?
> Those developers that are not willing to learn a new language just
> because they consider the trade-offs of not finding a job in that field
> that easily, might not be the best choice for your team anyway...
>
> That is my experience... I know more developers missing the "Smalltalk
> experience" than those hating Smalltalk once they left a team...
>
> Sebastian
>
>
> On 2017-10-19 12:04 AM, Paulo R. Dellani wrote:
>> Dear all,
>>
>> after using Smalltalk for several years I developed a passion for the
>> language (how not to?), and Pharo is just so great to develop with.
>> So thank you guys for keeping this wonderful project running.
>>
>> Unfortunately, it is not easy to always point out why Smalltalk
>> should be employed as "main development language" in a team
>> or for a project. In the last discussion of this sort I was confronted
>> with the question "where are we going to get new smalltalk
>> developers if our startup grows or if you go?". Well, I had no
>> good answer to that. What would have you answered?
>>
>> Cheers,
>>
>> Paulo
>>
>>
>>





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

Dave Mason
In reply to this post by jtuchel
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.


Okay, shoot ;-)

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" value="+4971415610860" target="_blank">+49 7141 56 10 86 0         Fax: <a href="tel:%2B49%207141%2056%2010%2086%201" value="+4971415610861" target="_blank">+49 7141 56 10 86 1



Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

aglynn42

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.


Okay, shoot ;-)

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" target="_blank">+49 7141 56 10 86 0         Fax: <a href="tel:%2B49%207141%2056%2010%2086%201" target="_blank">+49 7141 56 10 86 1

 

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

henry
It’s well said, I don’t give a f*** about other languages. NSA-proof, anonymized 2048-bit key rendezvoused connection framework in 33 classes. Includes user definable cipher and encoder. SmalltalkHub talkin ParrotTalk.

http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz


- HH


On Wed, Oct 25, 2017 at 18:46, Andrew Glynn <aglynn42@...> 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, jtuchel@... <jtuchel@...> 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:jtuchel@...
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

 

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

philippeback
In reply to this post by aglynn42
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 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 <[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.


Okay, shoot ;-)

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" target="_blank">+49 7141 56 10 86 0         Fax: <a href="tel:%2B49%207141%2056%2010%2086%201" target="_blank">+49 7141 56 10 86 1

 


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

henry
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, [hidden email] <phil@...> 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 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 <aglynn42@...> 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-bounces@lists.pharo.org> on behalf of David Mason <dmason@...>
Reply-To: Any question about pharo is welcome <pharo-users@...>
Date: Tuesday, October 24, 2017 at 11:52 AM
To: Any question about pharo is welcome <pharo-users@...>
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, jtuchel@... <jtuchel@...> 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:jtuchel@...
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

 


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

philippeback
Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. 

How would you see ParrotTalk work? 

I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW


libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained.

And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support.

Tell me more about your vision. Even better, draw it in some way :-)

Phil


On Thu, Oct 26, 2017 at 8:43 AM, henry <[hidden email]> wrote:
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, [hidden email] <[hidden email]> 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 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 <[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]ro.org> 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.


Okay, shoot ;-)

Joachim



————————————————————————
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

 



Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

dellani
In reply to this post by aglynn42
I like your depiction of the situation and arguments, Andrew.

The inherent volatility of the software industry due to its tendency
to self disruption, as you pointed out, is fertile ground to all kinds of
crap, but we as developers should keep our eyes wide open and
look for the pearls and gems that grow here and there,
like Pharo Smalltalk.

Of course my "vision", as a Smalltalker is inherently biased, but
as you said, when "shit has to work", I think that we have good
cards at our hands.

So yesterday we had another meeting and I think I could make a
good point for Smalltalk, thanks to all your arguments here at the
list. But surely the absolute killer argument is that "this shit really
works" :-)

As pointed out by several of you, integration is key. For my particular
present case, I could successfully integrate the developed tools in
the system, a medical imaging processing pipeline, through the
command line and the filesystem - so no need for fancy looking web
apps at the moment, but it surely will not hurt to have this possibilities
- it would be cool to run part of the code at the front end (internet browser),
in our case, some pre-processing of medical data before it is sent
to the "main processing pipeline" (just one practical example of
many other possible applications). This particular task could be done
with Javascript, but I am afraid that the necessary libraries are not
so good..

Cheers,

Paulo

On 10/26/2017 12:46 AM, Andrew Glynn 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.


Okay, shoot ;-)

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" target="_blank" moz-do-not-send="true">+49 7141 56 10 86 0         Fax: <a href="tel:%2B49%207141%2056%2010%2086%201" target="_blank" moz-do-not-send="true">+49 7141 56 10 86 1

 


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

jtuchel
In reply to this post by aglynn42
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 [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.


Okay, shoot ;-)

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" target="_blank" moz-do-not-send="true">+49 7141 56 10 86 0         Fax: <a href="tel:%2B49%207141%2056%2010%2086%201" target="_blank" moz-do-not-send="true">+49 7141 56 10 86 1

 


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

henry
In reply to this post by philippeback
Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer.

I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. 

Please see the attached diagram, co-locating ParrotTalk with my other components.

ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData.

This means you still need a Kerberos client and I need a Kerberos client. How do we start?

- HH

PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs.


On Thu, Oct 26, 2017 at 03:14, [hidden email] <phil@...> wrote:
Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. 

How would you see ParrotTalk work? 

I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW


libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained.

And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support.

Tell me more about your vision. Even better, draw it in some way :-)

Phil


On Thu, Oct 26, 2017 at 8:43 AM, henry <henry@...> wrote:
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, phil@... <[hidden email]> 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 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 <[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]ro.org> 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.


Okay, shoot ;-)

Joachim



————————————————————————
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

 




53DC7C2C-6241-4D5C-8D5B-1E05B0FA1EAD.PNG (243K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

kilon.alios
In reply to this post by jtuchel
Well all languages have well designed and badly designed libraries , in Pharo you dont even have to look hard just take a look at Morph and Object class and awe at all those irrelevant methods trying to cram in features you will probably never use. Especially my experience with Morphic has been as nightmarish as my experience with MFC. And MFC is a C++ library and made by Microsoft. On the other hand QT is a brilliantly designed GUI API (again for C++) and dont even get me started on DELPHI libraries which to this day I consider top when it comes to OO libraries. together with its IDE (but I never liked its language). 

Web dev may be a messy field mainly because it has grown too fast, after the web explosion ,  based on problematic concepts but desktop libraries and as a consequence mobile dev libraries (iOS is a variable of MacoOS, Android a variant of Linux) in a much , much better position and some of them have stellar designs. Mainly because are far more mature with decades of extremely active development.

Of course many of those great design are the result of a reaction to bad designs and lessons learned from other APIs. There is no good design without a redesign. 

My personal opinion is that as pessimistic it may sound, Smalltalk has very little to offer in the library front. The language is still stellar and live environment is a great concept but from there on there is a decline. Sure if your are low demand kind of person on the library front and dont mind implementing stuff by yourself you wont mind the lack of libraries but most coders , me included , dont have this luxury. Especially making a living with a language is a completely different story from learning it as a hobby, 

I think and that's a personal opinion, that Smalltalk goes the wrong direction. It tries to be a do it all language, but we already have an army of do it all languages. I think it would excel as the backbone in big complex projects. Like the Moose project is doing with code analysis and visualization. I think this is an excellent direction to go with Smalltalk. Reflection is the big strength of Smalltalk the ability to communicate with its code in a direct matter. So I think that a Smalltalk implementation that can analyze and visualize code written in other languages would have been a pretty serious reason for people to learn Smalltalk. 

I am very happy to see Pharo go towards that direction and yes I would definitely recommend it without hesitation  for code analysis and project management tool. Its no coincidence that we have seen a serious growth in our community. When I joined back in 2011 we all were posting at pharo-dev, pharo-users was a dead zone and then the community grow larger and larger we soon may need a third mailing list. 

Code complexity is an issues for all large projects and tools that help manage this without having to convert to another language are very popular.     




On Thu, Oct 26, 2017 at 3:14 PM [hidden email] <[hidden email]> wrote:
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 [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.


Okay, shoot ;-)

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" target="_blank">+49 7141 56 10 86 0         Fax: <a href="tel:%2B49%207141%2056%2010%2086%201" target="_blank">+49 7141 56 10 86 1

 


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

henry
In reply to this post by henry
I try posting with a smaller image.

hubbub.jpg

- HH


-------- Original Message --------
Subject: Re: [Pharo-users] Smalltalk Argument
Local Time: October 26, 2017 8:52 AM
UTC Time: October 26, 2017 12:52 PM
To: [hidden email] <[hidden email]>, Any question about pharo is welcome <[hidden email]>

Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer.

I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. 

Please see the attached diagram, co-locating ParrotTalk with my other components.

ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData.

This means you still need a Kerberos client and I need a Kerberos client. How do we start?

- HH

PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs.


On Thu, Oct 26, 2017 at 03:14, [hidden email] <phil@...> wrote:
Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. 

How would you see ParrotTalk work? 

I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW


libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained.

And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support.

Tell me more about your vision. Even better, draw it in some way :-)

Phil


On Thu, Oct 26, 2017 at 8:43 AM, henry <henry@...> wrote:

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, phil@... <[hidden email]> 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 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 <[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]ro.org> 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.


Okay, shoot ;-)

Joachim



————————————————————————
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

 


Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

henry
I think another good service to integrate well to is Elastic Search.

Of the 4 types of integration, I vote for and step forward to volunteer to help Kerberos integration in Pharo. What to do?


- HH


On Thu, Oct 26, 2017 at 09:06, henry <henry@...> wrote:
I try posting with a smaller image.

"hubbub.jpg"

- HH


——— Original Message ———
Subject: Re: [Pharo-users] Smalltalk Argument
Local Time: October 26, 2017 8:52 AM
UTC Time: October 26, 2017 12:52 PM
To: [hidden email] <[hidden email]>, Any question about pharo is welcome <[hidden email]>

Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer.

I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. 

Please see the attached diagram, co-locating ParrotTalk with my other components.

ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData.

This means you still need a Kerberos client and I need a Kerberos client. How do we start?

- HH

PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs.


On Thu, Oct 26, 2017 at 03:14, [hidden email] <phil@...> wrote:
Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. 

How would you see ParrotTalk work? 

I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW


libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained.

And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support.

Tell me more about your vision. Even better, draw it in some way :-)

Phil


On Thu, Oct 26, 2017 at 8:43 AM, henry <henry@...> wrote:

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, phil@... <[hidden email]> 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 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 <[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]ro.org> 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.


Okay, shoot ;-)

Joachim



————————————————————————
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

 



hubbub.jpg (519K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

henry
Here is a truer diagram of what I want to do. Sideways?

hubbub.jpg

- HH


-------- Original Message --------
Subject: Re: [Pharo-users] Smalltalk Argument
Local Time: October 26, 2017 9:15 AM
UTC Time: October 26, 2017 1:15 PM
To: henry <[hidden email]>
[hidden email] <[hidden email]>, Any question about pharo is welcome <[hidden email]>

I think another good service to integrate well to is Elastic Search.

Of the 4 types of integration, I vote for and step forward to volunteer to help Kerberos integration in Pharo. What to do?



- HH


On Thu, Oct 26, 2017 at 09:06, henry <henry@...> wrote:


——— Original Message ———
Subject: Re: [Pharo-users] Smalltalk Argument
Local Time: October 26, 2017 8:52 AM
UTC Time: October 26, 2017 12:52 PM
To: [hidden email] <[hidden email]>, Any question about pharo is welcome <[hidden email]>

Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer.

I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. 

Please see the attached diagram, co-locating ParrotTalk with my other components.

ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData.

This means you still need a Kerberos client and I need a Kerberos client. How do we start?

- HH

PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs.


On Thu, Oct 26, 2017 at 03:14, [hidden email] <phil@...> wrote:
Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. 

How would you see ParrotTalk work? 

I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW


libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained.

And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support.

Tell me more about your vision. Even better, draw it in some way :-)

Phil


On Thu, Oct 26, 2017 at 8:43 AM, henry <henry@...> wrote:

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, phil@... <[hidden email]> 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 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 <[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]ro.org> 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.


Okay, shoot ;-)

Joachim



————————————————————————
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1


 



Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

henry
In reply to this post by henry
A Kerberos effort will have to be a group effort. Sideways to my main focus and your all’s main focii.


- HH


On Thu, Oct 26, 2017 at 09:15, henry <henry@...> wrote:
I think another good service to integrate well to is Elastic Search.

Of the 4 types of integration, I vote for and step forward to volunteer to help Kerberos integration in Pharo. What to do?


- HH


On Thu, Oct 26, 2017 at 09:06, henry <henry@...> wrote:
I try posting with a smaller image.

""hubbub.jpg""

- HH


——— Original Message ———
Subject: Re: [Pharo-users] Smalltalk Argument
Local Time: October 26, 2017 8:52 AM
UTC Time: October 26, 2017 12:52 PM
To: [hidden email] <[hidden email]>, Any question about pharo is welcome <[hidden email]>

Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer.

I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. 

Please see the attached diagram, co-locating ParrotTalk with my other components.

ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData.

This means you still need a Kerberos client and I need a Kerberos client. How do we start?

- HH

PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs.


On Thu, Oct 26, 2017 at 03:14, [hidden email] <phil@...> wrote:
Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. 

How would you see ParrotTalk work? 

I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW


libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained.

And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support.

Tell me more about your vision. Even better, draw it in some way :-)

Phil


On Thu, Oct 26, 2017 at 8:43 AM, henry <henry@...> wrote:

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, phil@... <[hidden email]> 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 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 <[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]ro.org> 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.


Okay, shoot ;-)

Joachim



————————————————————————
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

 



hubbub.jpg (519K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

henry
The question I propose you is what is necessary to make Pharo eligible to participate in cloud/BigData?


- HH


On Thu, Oct 26, 2017 at 10:38, henry <henry@...> wrote:
A Kerberos effort will have to be a group effort. Sideways to my main focus and your all’s main focii.


- HH


On Thu, Oct 26, 2017 at 09:15, henry <henry@...> wrote:
I think another good service to integrate well to is Elastic Search.

Of the 4 types of integration, I vote for and step forward to volunteer to help Kerberos integration in Pharo. What to do?


- HH


On Thu, Oct 26, 2017 at 09:06, henry <henry@...> wrote:
I try posting with a smaller image.

"""hubbub.jpg"""

- HH


——— Original Message ———
Subject: Re: [Pharo-users] Smalltalk Argument
Local Time: October 26, 2017 8:52 AM
UTC Time: October 26, 2017 12:52 PM
To: [hidden email] <[hidden email]>, Any question about pharo is welcome <[hidden email]>

Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer.

I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. 

Please see the attached diagram, co-locating ParrotTalk with my other components.

ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData.

This means you still need a Kerberos client and I need a Kerberos client. How do we start?

- HH

PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs.


On Thu, Oct 26, 2017 at 03:14, [hidden email] <phil@...> wrote:
Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. 

How would you see ParrotTalk work? 

I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW


libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained.

And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support.

Tell me more about your vision. Even better, draw it in some way :-)

Phil


On Thu, Oct 26, 2017 at 8:43 AM, henry <henry@...> wrote:

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, phil@... <[hidden email]> 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 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 <[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]ro.org> 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.


Okay, shoot ;-)

Joachim



————————————————————————
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

 



hubbub.jpg (519K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Smalltalk Argument

dellani
In reply to this post by henry
This all sounds very interesting. What is the idea? Wrap libkrb5 through UFFI or implement it in Smalltalk?

On 10/26/2017 04:38 PM, henry wrote:
A Kerberos effort will have to be a group effort. Sideways to my main focus and your all’s main focii.


- HH


On Thu, Oct 26, 2017 at 09:15, henry <henry@...> wrote:
I think another good service to integrate well to is Elastic Search.

Of the 4 types of integration, I vote for and step forward to volunteer to help Kerberos integration in Pharo. What to do?


- HH


On Thu, Oct 26, 2017 at 09:06, henry <henry@...> wrote:
I try posting with a smaller image.

""hubbub.jpg""

- HH


——— Original Message ———
Subject: Re: [Pharo-users] Smalltalk Argument
Local Time: October 26, 2017 8:52 AM
UTC Time: October 26, 2017 12:52 PM
To: [hidden email] [hidden email], Any question about pharo is welcome [hidden email]

Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer.

I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. 

Please see the attached diagram, co-locating ParrotTalk with my other components.

ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData.

This means you still need a Kerberos client and I need a Kerberos client. How do we start?

- HH

PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs.


On Thu, Oct 26, 2017 at 03:14, [hidden email] <phil@...> wrote:
Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. 

How would you see ParrotTalk work? 

I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW


libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained.

And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support.

Tell me more about your vision. Even better, draw it in some way :-)

Phil


On Thu, Oct 26, 2017 at 8:43 AM, henry <henry@...> wrote:

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, phil@... <[hidden email]> 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 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
12345