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 <[aglyn...@gmail.com]("mailto:aglyn...@gmail.com";)> wrote: > There’s other questions that are relevant to me: > > Do I give a f*** about cool looking web apps? No, I don’t use web apps if in > any way I can avoid it. > > Do I give a f*** about mobile apps? No, the screen’s too small to read > anything longer than a twit, or anyone with anything worthwhile to say. > > Do I give a f*** about the number of libraries in other languages? No, > because most of them are crap in every language I’ve had to work in, and the > base languages are crap so they have to keep changing radically, and > libraries and frameworks therefore also have to and never get any better. The > few that are worthwhile I can almost always use from Smalltalk without a > problem (read, Blender, ACT-R and Synapse, since every other > library/framework I’ve used outside Smalltalk has been a waste of time). > > Do I give a f*** about implementing a complex piece of machine learning > software in 22 hours, compared to 3 months for the Java version? Well, > actually yes, I do, because that was 3 months of my life down the toilet for > something that is too slow to be useful in Java. > > Any argument depends on your priorities. I’ve written tons of web apps, > because I needed to get paid. I’ve written better shitty mobile apps than > the average shitty mobile apps. However, I’m not going to do any of that any > longer in crap that never improves, because after 26 years the irritability > it produces is more than it’s worth. > > A few weeks ago, a recruiter that specializes in Smalltalk called me about a > job, although they were well aware I live 1500 miles away from the city I > lived in when I had worked through them, to see if I’d be willing to move > back there for a job. That sounds like another ‘there aren’t enough > Smalltalk developers", but it wasn’t, because the job wasn’t writing > Smalltalk. It was writing Java. > > The person hiring, though, wouldn’t look at anyone who didn’t write > Smalltalk, because "people who grew up with Java don’t know how to write > code". I don’t agree with that, I’ve known a (very few) good Java > developers. I would say, though, that I’ve known far more incompetent ones > than good ones, and I can’t think of any incompetent Smalltalk developers off > the top of my head. > > Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or even > C, complain about how hard maintaining state is or coming up with various > hacks to avoid it, which seems to be the main point of every JavaScript based > ‘technology’. An application is by definition a state-machine, which implies > plenty about JS developers on the whole. > > If you’re a good developer you can write good code in (nearly) anything. My > question then is why would you want to write in crap? The better question is > why aren’t there more good developers in any language? > > Every project I have been able to do in Smalltalk, though, has had one thing > in common, the "shit has to work". Companies do use it, in fact I could name > 4 large enterprises I’ve worked for who’ve written their own dialects, and > they all use it only when "shit has to work". They know it’s more > productive, they also know using it for more things would increase the > availability of Smalltalk developers. > > Why do they not do it? One reason, though it takes a while to recognize it, > because management doesn’t admit even to themselves why they do it, or not > very often. Being inefficient, as long as it doesn’t ‘really’ matter, is an > advantage to large enterprises because they have resources smaller > competitors don’t. > > Why don’t their competitors do it? Because they can’t see past an hourly > rate, what’s fashionable, or just new, or because their customers can’t. Put > more generally, average stupidity that isn’t corrected by the market. > Fashion affects smaller companies more than larger ones, because they can’t > afford a few customers walking away because they wanted an app in Electron, > even if they can’t give any relevant reason for wanting it, and even the > samples on the Electron site don’t work. > > Enterprises can, and do use Smalltalk when it matters. When it doesn’t, it’s > to their advantage to promote things that are inefficient, buggy and > unreliable. > > Cost is relevant, but not in the simple way people look at things. A crucial > but rarely mentioned perspective on its relevance is that while Java based > software runs TV set top boxes, Smalltalk based software runs things like > medical equipment, automated defense systems, tanks, etc. Cost becomes > largely irrelevant when ‘shit has to work’. > > Productivity is primarily relevant to less talented developers, in an > inversely sense, since unproductive environments and attitudes have a > leveling tendency in general, and more specifically make accomplishing what > the less talented are capable of in any environment sufficiently laborious > for them to have a role. Capability in Smalltalk, as implied by the person > hiring for the Java role I mentioned, is a fairly decent means of judging > whether someone is a so-so developer or a good one. > > The productivity argument is realistically only relevant in the context of an > already higher hourly cost. Given that it is relevant at that point, > companies that know Smalltalk is more productive would use it outside things > that have to be 100%, if their own productivity were relevant to the same > degree that competitors’ productivity is inversely relevant. > > All these ways of looking at it are contingent perspectives though. Yes, if > the number of libraries is relevant to you, Smalltalk is less attractive, but > that’s only a contingent phenomenon based on the relative popularity of Java > and JavaScript, as a result it can’t be used as explanatory for that > popularity. All the ways of looking at it that are fully determinate are > determinate via contingencies of that kind, which for the most part are > precisely the other perspectives, including productivity, cost, availability > of developers, etc. None of them is in itself anything but a result of the > others. > > If availability of developers is contingent on popularity (and further, > popularity contingent on industry attitudes), to use an example already > mentioned in Joachim’s post, then his simultaneous posit of library > availability is if anything more contingent on the same popularity, so > positing it as a cause and not a result, or merely a correlate, of popularity > is incoherent. We can go one step further, and demonstrate that even when > large enterprises make something that works reliably available, they fail to > promote and support it, which destroys the market for reliable tooling by > simultaneously owning it while not promoting it, something IBM is > particularly good at. But IBM can’t (and if they can’t, neither can any > other company) operate that way without the tacit agreement of the industry. > > To understand it in a more general way, software development has to be looked > at in the context where it occurs, and how it’s determined to a large degree > by that context, with a specific difference. That difference is itself > implicit in the context, i.e. capitalism, but only purely effective in > software development. It’s a result of virtualization as an implicit goal of > capitalism, and the disruptions implicit in the virtual but so far only > realized completely in software. In terms of that understanding, the > analysis of virtualization and disruption as inherent to capitalism is better > accomplished in Kapital than in any more recent work. > > Or you can simply decide, as I’ve done recently, that working in ways and > with tools that prevent doing good work in a reasonable timeframe isn’t > worthwhile to you, no matter how popular those ways and tools might be, or > what the posited reasons are, since at the end popularity is only insofar as > it already is. What those tools and methods are depends to a degree on your > priorities, but if developers are engineers those priorities can’t be > completely arbitrary. Engineers are defined by their ability to make things > work. > > Software as virtual is inherently disruptive, and the software industry > disrupts itself too often and too easily to build on anything. A further > disruption caused by developers, as engineers, refusing to work with crap > that doesn’t, i.e. insisting on being engineers, while in itself merely an > aggravation of the disruptive tendencies, might have an inverse result. > > Using a stable core of technologies as the basis for a more volatile set of > products, in the way nearly every other industry does, is the best means we > know of to build things both flexibly and reasonably efficiently. The > computer hardware industry is the extreme example of this, while the software > industry is the extreme contradiction. > > From: Pharo-users <pharo-users-boun...@lists.pharo.org> on behalf of David > Mason <dma...@ryerson.ca> > Reply-To: Any question about pharo is welcome <pharo-users@lists.pharo.org> > Date: Tuesday, October 24, 2017 at 11:52 AM > To: Any question about pharo is welcome <pharo-users@lists.pharo.org> > Subject: Re: [Pharo-users] Smalltalk Argument > > PharoJS is working to give you that mobile app/browser app experience. As > with others, we’re not there yet, but getting there. See > [http://pharojs.org]("http://pharojs.org";) > > The 67% loved means that 67% of people using Smalltalk (or perhaps have ever > used it) want to continue - so it’s presumably a high percentage of a > smallish number of people. > > On 20 October 2017 at 03:23, > [jtuc...@objektfabrik.de]("mailto:jtuc...@objektfabrik.de";) > <[jtuc...@objektfabrik.de]("mailto:jtuc...@objektfabrik.de";)> wrote: > >> First of all: I’d say the question itself is not a question but an excuse. I >> am not arguing there are enough Smalltalkers or cheap ones. But I think the >> question is just a way of saying "we don’t want to do it for reasons that we >> ourselves cannot really express". If you are a good developer, learning >> Smalltalk is easy. If you are a good developer you’ve heard the sentence >> "we’ve taken the goos parts from x,y,z and Smalltalk" at least twice a year. >> So you most likely would like to learn it anyways. >> >> A shortage of developers doesn’t exist. What exists is an unwillingness of >> companies to get people trained in a technology. If Smalltalk was cool and >> great in their opinion, they wouldn’t care. It’s that simple. As a >> consultant, I’ve heard that argument so often. Not ferom Startups, but from >> insurance companies, Banks or Car manufacturers who spend millions on >> useless, endless meetings and stuff instead of just hiring somebody to teach >> a couple of developers Smalltalk. It’s just a lie: the shortage of Smalltalk >> developers is not a problem. >> >> And, to be honest: what is it we actually are better in by using Smalltalk? >> Can we build cool looking web apps in extremely short time? No. >> Can we build mobile Apps with little effort? No. >> Does our Smalltalk ship lots of great libraries for all kinds of things that >> are not availabel in similar quality in any other language? >> Are we lying when we say we are so extremely over-productive as compared to >> other languages? >> >> I know, all that live debugging stuff and such is great and it is much >> faster to find & fix a bug in Smalltalk than in any other environment I’ve >> used so far. But that is really only true for business code. When I need to >> connect to things or want to build a modern GUI or a web application with a >> great look&feel, I am nowhere near productive, because I simply have to >> build my own stuff or learn how to use other external resources. If I want >> to build something for a mobile device, I will only hear that somebody >> somewhere has done it before. No docs, no proof, no ready-made tool for me. >> >> Shortage of developers is not really the problem. If Smalltalk was as cool >> as we like to make ourselves believe, this problem would be non-existent. If >> somebody took out their iPad and told an audience: "We did this in Smalltalk >> in 40% of the time it would have taken in Swift", and if that something was >> a must-have for people, things would be much easier. But nobody has. >> >> I am absolutely over-exaggerating, because I make my living with an SaaS >> product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk >> and - as you - am convince that many parts of what we’ve done so far >> would’ve taken much longer or even be impossible in other languages. But the >> advantage was eaten by our extremely steep learning curve for web >> technologies and for building something that works almost as well as tools >> like Angular or jQuery Mobile. >> >> Smalltalk is cool, and the day somebody shows me something like Google’s >> flutter in Smalltalk, I am ready to bet a lot on a bright future for >> Smalltalk. But until then, I’d say these arguments about productivity are >> just us trying to make ourselves believe we’re still the top of the food >> chain. We’ve done that for almost thirty years now and still aren’t ready to >> stop it. But we’ve been lying to ourselves and still do so. >> >> I don’t think there is a point in discussing about the usefulness of a >> language using an argument like the number or ready-made developers. That is >> just an argument they know you can’t win. The real question is and should >> be: what is the benefit of using Smalltalk. Our productivity argument is a >> lie as soon as we have to build something that uses or runs on technology >> that has been invented after 1990. >> >> Okay, shoot ;-) >> >> Joachim >> >> — >> ———————————————————————— >> Objektfabrik Joachim Tuchel >> mailto:[jtuc...@objektfabrik.de]("mailto:jtuc...@objektfabrik.de";) >> Fliederweg 1 >> [http://www.objektfabrik.de]("http://www.objektfabrik.de";) >> D-71640 Ludwigsburg >> [http://joachimtuchel.wordpress.com]("http://joachimtuchel.wordpress.com";) >> Telefon: [+49 7141 56 10 86 0]("tel:%2B49%207141%2056%2010%2086%200") >> Fax: [+49 7141 56 10 86 1]("tel:%2B49%207141%2056%2010%2086%201")
