Andrew,
Am 26.10.17 um 00:46 schrieb Andrew Glynn:
There’s other questions that are relevant to me:
I am glad you opened your words with this sentence. Other peoples'
mileages may vary a lot.
> Do I give a f*** about cool looking web apps? No, I don’t use web
apps if in any way I can avoid it.
Some people can't. I can't. I am making my living with a web based
application. And I like it.
> Do I give a f*** about mobile apps? No, the screen’s too small to
read anything longer than a twit, or anyone with anything worthwhile to
say.>
So you are in the lucky position that neither mobile nor web nor
integration matters to you or you have enough resources to do all that
stuff yourself. I am envyous. I need to build web pages and people ask
me whether we can ship an iPhone App. I do customer-facing stuff and sex
sells much more than we like to think.
Your comments on the crappiness of libs in other languages is a great
fit for Smalltalk. Not invented here, therefor rubbish. We came a long
way with this way of thinking. But these rubbish makers dance circles
around us while we try to do our first hello world for an iPad. They
laugh at us when we try to reinvent MVC on top of Seaside (although MVC
is closesly related to Smalltalk). Because they are back home and watch
Netflix while we debug our homegrown base libraries that are, of course,
much better than theirs because they are written in Smalltalk.
I am not arguing that maintaining Smalltalk code is far superior to most
technolgies out there. But depending on the needs of our projects we
have to learn and use those crappy technologies to accomplish what they
offer. Because, sometimes (especially if you have to pay bills), an
existing library with flaws is better than none.
So if I have to use Javascript or C# or Dart or Swift to do the frontend
part of my system, is there still much benefit in using these together
with Smalltalk? Or is there - at least from a manager's point of view -
not a reasonable amount of sense in choosing the frontend technology
also for the logic and compensate the loss in productivity with a gain
in avoided complexity?
Your answer delivers a lot of food for thought, but I don't buy all of
it. And I don't expect you to buy all of mine ;-)
Joachim
Do I give a f*** about the number of libraries in other languages?
No, because most of them are crap in every language I’ve had to work
in, and the base languages are crap so they have to keep changing
radically, and libraries and frameworks therefore also have to and
never get any better. The few that are worthwhile I can almost always
use from Smalltalk without a problem (read, Blender, ACT-R and
Synapse, since every other library/framework I’ve used outside
Smalltalk has been a waste of time).
Do I give a f*** about implementing a complex piece of machine
learning software in 22 hours, compared to 3 months for the Java
version? Well, actually yes, I do, because that was 3 months of my
life down the toilet for something that is too slow to be useful in Java.
Any argument depends on your priorities. I’ve written tons of web
apps, because I needed to get paid. I’ve written better shitty mobile
apps than the average shitty mobile apps. However, I’m not going to
do any of that any longer in crap that never improves, because after
26 years the irritability it produces is more than it’s worth.
A few weeks ago, a recruiter that specializes in Smalltalk called me
about a job, although they were well aware I live 1500 miles away from
the city I lived in when I had worked through them, to see if I’d be
willing to move back there for a job. That sounds like another ‘there
aren’t enough Smalltalk developers”, but it wasn’t, because the job
wasn’t writing Smalltalk. It was writing Java.
The person hiring, though, wouldn’t look at anyone who didn’t write
Smalltalk, because “people who grew up with Java don’t know how to
write code”. I don’t agree with that, I’ve known a (very few) good
Java developers. I would say, though, that I’ve known far more
incompetent ones than good ones, and I can’t think of any incompetent
Smalltalk developers off the top of my head.
Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP,
or even C, complain about how hard maintaining state is or coming up
with various hacks to avoid it, which seems to be the main point of
every JavaScript based ‘technology’. An application is by definition
a state-machine, which implies plenty about JS developers on the whole.
If you’re a good developer you can write good code in (nearly)
anything. My question then is why would you want to write in crap?
The better question is why aren’t there more good developers in /any/
language?
Every project I have been able to do in Smalltalk, though, has had one
thing in common, the “shit has to work”. Companies do use it, in fact
I could name 4 large enterprises I’ve worked for who’ve written their
own dialects, and they all use it only when “shit has to work”. They
know it’s more productive, they also know using it for more things
would increase the availability of Smalltalk developers.
Why do they not do it? One reason, though it takes a while to
recognize it, because management doesn’t admit even to themselves why
they do it, or not very often. Being inefficient, as long as it
doesn’t ‘really’ matter, is an advantage to large enterprises because
they have resources smaller competitors don’t.
Why don’t their competitors do it? Because they can’t see past an
hourly rate, what’s fashionable, or just new, or because their
customers can’t. Put more generally, average stupidity that isn’t
corrected by the market. Fashion affects smaller companies more than
larger ones, because they can’t afford a few customers walking away
because they wanted an app in Electron, even if they can’t give any
relevant reason for wanting it, and even the samples on the Electron
site don’t work.
Enterprises can, and do use Smalltalk when it matters. When it
doesn’t, it’s to their advantage to promote things that are
inefficient, buggy and unreliable.
Cost is relevant, but not in the simple way people look at things. A
crucial but rarely mentioned perspective on its relevance is that
while Java based software runs TV set top boxes, Smalltalk based
software runs things like medical equipment, automated defense
systems, tanks, etc. Cost becomes largely irrelevant when ‘shit has
to work’.
Productivity is primarily relevant to less talented developers, in an
inversely sense, since unproductive environments and attitudes have a
leveling tendency in general, and more specifically make accomplishing
what the less talented are capable of in any environment sufficiently
laborious for them to have a role. Capability in Smalltalk, as
implied by the person hiring for the Java role I mentioned, is a
fairly decent means of judging whether someone is a so-so developer or
a good one.
The productivity argument is realistically only relevant in the
context of an already higher hourly cost. Given that it is relevant
at that point, companies that know Smalltalk is more productive would
use it outside things that have to be 100%, /if/ their own
productivity were relevant to the same degree that competitors’
productivity is inversely relevant.
All these ways of looking at it are contingent perspectives though.
Yes, if the number of libraries is relevant to you, Smalltalk is less
attractive, but that’s only a contingent phenomenon based on the
relative popularity of Java and JavaScript, as a result it can’t be
used as explanatory /for/ that popularity. All the ways of looking at
it that are fully determinate are determinate via contingencies of
that kind, which for the most part /are/ precisely the other
perspectives, including productivity, cost, availability of
developers, etc. None of them is /in itself/ anything but a result of
the others.
If availability of developers is contingent on popularity (and
further, popularity contingent on industry attitudes), to use an
example already mentioned in Joachim’s post, then his simultaneous
posit of library availability is if anything more contingent on the
same popularity, so positing it as a cause and not a result, or merely
a correlate, of popularity is incoherent. We can go one step further,
and demonstrate that even when large enterprises make something that
works reliably available, they fail to promote and support it, which
destroys the market for reliable tooling by simultaneously owning it
while not promoting it, something IBM is particularly good at. But
IBM can’t (and if they can’t, neither can any other company) operate
that way without the tacit agreement of the industry.
To understand it in a more general way, software development has to be
looked at in the context where it occurs, and how it’s determined to a
large degree by that context, with a specific difference. That
difference is itself implicit in the context, i.e. capitalism, but
only /purely /effective in software development. It’s a result of
virtualization as an implicit goal of capitalism, and the disruptions
implicit in the virtual but so far only realized completely in
software. In terms of that understanding, the analysis of
virtualization and disruption as inherent to capitalism is better
accomplished in Kapital than in any more recent work.
Or you can simply decide, as I’ve done recently, that working in ways
and with tools that prevent doing good work in a reasonable timeframe
isn’t worthwhile /to you,/ no matter how popular those ways and tools
might be, or what the posited reasons are, since at the end popularity
is only insofar as it /already/ is. What those tools and methods are
depends to a degree on your priorities, but if developers are
/engineers/ those priorities can’t be completely arbitrary. Engineers
are defined by their ability to make things work.
Software as virtual is inherently disruptive, and the software
industry disrupts itself too often and too easily to build on
anything. A further disruption caused by developers, /as/ engineers,
refusing to work with crap that /doesn’t/, i.e. insisting on being
engineers, while in itself merely an aggravation of the disruptive
tendencies, might have an inverse result.
Using a stable core of technologies as the basis for a more volatile
set of products, in the way nearly every other industry does, is the
best means we know of to build things both flexibly and reasonably
efficiently. The computer hardware industry is the extreme example of
this, while the software industry is the extreme contradiction.
*From: *Pharo-users <pharo-users-boun...@lists.pharo.org> 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
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
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0
<tel:%2B49%207141%2056%2010%2086%200> Fax: +49 7141 56 10
86 1 <tel:%2B49%207141%2056%2010%2086%201>
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de
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
