Re: work times & accommodation @tokyo, WAS: Re: [tlug] Embedded linux dev wanting to find work in Tokyo.. Seeking advice.

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:
 > On 2008-07-24 16:26 +0900 (Thu), Stephen J. Turnbull wrote:
 > > Curt Sampson writes:

Taking things out of order, here's the executive summary.

 > >  > As for languages themselves, there is ample evidence that some
 > >  > are more powerful than others,
 > > 
 > > Well, feel free to set up your straw man.  Which set of languages
 > > would you choose?
 > 
 > C++, Java, Ruby and Haskell, since I have reasonable knowledge of all of
 > those.

But you say below that in Google's situation, you see no reason not to
substitute Python for Ruby, and every reason to do so.  So what you're
saying is that Google's whole mistake is not to add a modern
functional language to the mix.  How about a declarative language like
Prolog?  More to the point, where's SQL?  Surely Google uses SQL out
the wazoo.

And what problem does use of Haskell solve for Google?  Google's big
problem is concurrency.  So is STM a standard part of GHC 6.8?  How
well-debugged is it?  Can you refer me to the HOWTOs on using it to
solve google-sized problems?  How does this interface with modules
written in other languages that don't have STM?  Is it as efficient as
SP-J's chapter in "Beautiful Code" would suggest, or does it require
problems that are as easy to factor in your head as the toy problem he
presents there?

We now return you to your on-going discussion.

 > >  > It appears to be a matter of people's comfort level with change.
 > > 
 > > Well, that's a resource cost.  If, as a manager, you consistently
 > > ignore people's comfort levels....
 > 
 > I think you're talking about quite different situations from the ones
 > I'm talking about. The situations I've seen have managers that don't
 > appear to care particularly about employee's comfort levels, and they're
 > not implementing this better stuff because the *managers* are not
 > comfortable with it, not the employees.

Well, then, iterate the problem.  It's the managers' managers who need
to deal with comfort levels, and guide their people (the first level
managers) through change.

 > The world is much closer to Dilbert than your representation of managers
 > making the best possible decisions that they can for their companyies
 > and employees.

Sure.  However the world is also a lot more complicated than you make
it out to be.  Agile programming is a very local technology.  That's
not to say it can't be applied enterprise-wide, but it has to be done
by smallish groups on a group by group basis.

Training is an investment in future performance at the expense of
current.  A group that refuses to invest in training can often do
better on its current task.  This may get it more resources in the
future.  That tradeoff has to be managed very carefully, and it is
rarely managed well.  So what we have is people who are responding
pretty well to the incentives they face *and still getting the wrong
answer*.[1]

If you want to call that "closer to Dilbert," well, guess what?
You're right.  So what?  "Dilbert" is a caricature, not analysis.  It
leads to a situation where you say that Google has the dumbest and
smartest people in the industry, and they're the same people.  A nice
ko-an, but satori generally leads to leaving the rat race, not to
teaching the rats how to run faster with less fatigue.

 > > Also, we weren't talking about general change.
 > 
 > I think we were, back a ways in this thread.

Again, you were, but that's hijacking the thread.

No, we were talking about disruptive innovation, which is a problem
caused by the fact that the system is in a local optimum, which
remains locally optimal even though the global optimum has changed.
Mathematically this is known as a catastrophe, aptly enough.

People are quite accurate in seeking local optima based on selfish
motives.  There are a number of heuristics (altruism, benefit-cost
analysis) for jumping to a better local optimum, but finding a global
optimum is a risky business.

 > > This means that not only do you have to make your own people happy
 > > with the change, you also need to get your clients and suppliers and
 > > complementers on board.
 > 
 > Yup. Which is exactly why you should be starting off on this kind of
 > thing early, rather than doing nothing about it until you've fallen
 > behind the rest of the industry.

Everybody knows that.  Everybody also knows that jumping on the
current trendy technology is likely to cause a catastrophic loss.  So
what you're saying is that you've identified the "silver bullet that
works," and Google is being stupid to not adopt it.  Reread your
Brooks recently?

 > > BTW, one of the reasons why Google sticks to those languages, I'm
 > > told, is that they work very well together.  It's relatively easy to
 > > port from Python to Java to C++, or to write portions of your Python
 > > programs in C++, as you need more performance.
 > 
 > Sure. But then again, speaking of Haskell (since I happen to be
 > particularly familiar with it), it produces standard binaries just like
 > C++ does, has more or less equivalant performance, is better than Python
 > at interfacing with C when you have to (which you generally don't need
 > to do for performance reasons), and is at least as compact and quick to
 > code in as Python. This stuff is out there, and if you happen to decide
 > that your future is a language without a good compiler and run-time
 > system currently, you can also dedicate a hacker or two to it.

It's possible to write unreadable Python, but I haven't seen much.
There are very strong customs in the Python community (the "Zen") that
lead to readable code.  On the other hand, have you read Darcs's code?
I don't think it's an accident that it's that hard to grok, in the
sense that it was written by a single idiosyncratic individual with
little to guide him in the way of style.  Where is the Kernighan and
Plauger, or even the Kernighan and Pike, of Haskell?  Try going to
Amazon and typing "programming style C/C++/Pascal/Python/Smalltalk/
Lisp" (yes, even Lisp!) and then try "programming style Haskell".  The
second group is 90% conference proceedings!

And Haskell, like Lisp, is very amenable to exponential recursion.  As
anybody who's had much exposure to Darcs knows.

Most problems already have Python solutions, and if you spend a month
lurking on c.l.python and python-dev, you'll surely find a list of
posters whose ideas you trust.  Many of them have written books on how
to solve problems relevant to you.  Is that true for Haskell or Ocaml
or Standard ML?

Finally, Python has a path forward.  Yes, it has problems and lacks,
but many of these are being addressed in Python 3 (which is, I
predict, going to be a disruptive innovation ... many existing Python
2 shops are going to get their butts whupped by upstart Python 3
firms).  Python 3 development is very much driven by the experiences
of Python programmers in large-scale enterprises (including Guido van
Rossum of Google who is very pointedly *not* free to work *on* Python
itself most of the time, because he spends most of his time
programming *in* Python for his employer).  Can you say the same for
any of these advanced languages, except maybe Erlang?

Don't get me wrong: Haskell is everything you say it is technically,
and more, as far as I can tell in my limited experience, especially
with Haskell.  My point is that propagating those advantages in a
large enterprise is not going to be as easy as you think.

Again, we end up at the same point: a large enterprise can't adopt
technologies like Haskell very easily (even though it can promote them
as Microsoft does).  However, I don't think a programming language or
a deployment scheme can be as disruptive as you seem to think.  I do
not think that failure to adopt Haskell "now" can kill Google.

 > Heck, MS, who you'd think would not be nearly as technologically
 > advanced as Google,

Why in the world would you think Microsoft would have anything less
than the most technically advanced labs in the world?  Cf. AT&T Bell
Laboratories.  The question is does it show up in the practices of the
programmers who use their systems?

 > not only has squirrelled away in one of their research labs a
 > couple of very, very smart researchers/hackers dedicated to Haskell
 > and GHC (the most advanced of the Haskell compilers) full time, but
 > has gone so far as to start building OCaml into .NET in the guise
 > of F#. I don't see much like this coming out of Google.

Yeah, I know where Simon Peyton-Jones works, and he's not the only
Haskell hacker at Microsoft Labs.  But how many of those Nobel Prizes
at Bell Labs actually made it to telephone company practice?  As for
Google, Google prefers to squirrel away Linux kernel hackers.

And coming out of Google?  Surely you jest; if there is any really
high-tech stuff happening at Google, the last thing they want is for
it to get out, no?

 > ROM? At any rate, a programmer experienced with Python who's reasonably
 > smart ought to have no trouble picking up Ruby fairly quickly. I can't
 > see any reason to bother, since if you already have a full Python
 > infrastructure in place and people experienced with Python to go with
 > it, you might as well move your Ruby guys to Python. Neither language
 > offers enough over the other to make it worth changing from one to the
 > other, as far as I can see.

Heh, heh, heh.

 > > Do you propose that each new Haskell programmer who knows little about
 > > Java spend at least half her time porting old Java programs just
 > > so that when maintenance is actually needed, she'll already have a
 > > program written in a language she understands?
 > 
 > This is a thoroughly ridiculous scenario.

No, it's a disruptive scenario.  That is the kind of thing that has to
happen when a disruptive innovation is introduced, although
Christensen assumes it happens in marketing rather than engineering.
I don't see why that should be a necessary constraint, though.

 > Consider the following:
 > 
 >     1. If you're moving away from Java, yes, you want to start porting
 >     any programs that require heavy maintenance and modification to
 >     your new preferrred systems.
 > 
 >     2. Google has massive reserves of Java talent; anybody who doesn't
 >     can find a decent programmer who knows Java reasonably well quite
 >     easily.
 > 
 >     3. It would be pretty darn unusual for someone who knows Haskell not
 >     to have a reasonably decent understanding of Java, or be able to
 >     pick it up quite quickly.

It's not a language issue per se.  Certainly most people who are
interested enough in languages to learn Haskell are going to be able
to learn Java syntax.  The problem is the massive infrastructure of
libraries that languages like Java, Python, and C++ bring with them,
and the well-known idioms for doing things in those languages.  Those
things will take them years to pick up, just like anybody else.
Faster, yes, but same kind of O(f(n)).

To the extent that these are just 3rd-party facilities that are
SWIG-able, it won't be a problem.  But it's typically not true; every
programming language community seems to reinvent things like web
frameworks multiple times.

Footnotes: 
[1]  While "the market" doesn't have the answers to all economic
problems, it's such a good answer to many of them that even ordinary
people no longer consider them "interesting problems" most of the
time.  Nevertheless, we don't really understand markets very well, as
we see from Vernon Smith's Three Laws of experimental markets:
1. Experimental subjects do not do the calculations economists use to
   characterize market behavior.
2. We don't know what they do do.
3. The subjects get the right answers anyway!
Note the similarity of Law 3 to "still get the wrong answer."  But now
we need to know what they're doing wrong, otherwise we have little
hope of improving the situation.
P.S. Smith enunciated those laws in about 1983.  We now know a lot
more about why markets work in the face of the failure of experimental
subjects and others to compute.