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-25 06:19 +0900 (Fri), Stephen J. Turnbull wrote:

 > > And what problem does use of Haskell solve for Google?
 > 
 > Programmer productivity, pure and simple.
 > 
 > I could spend an hour or two writing here to get into the details,
 > but there's already plenty of material out there, and I'm sure you're
 > perfectly capable of doing the research yourself.

This is a perfect example of why I keep questioning your opinion on
large tasks.  You write as if "I" could do the research myself at an
O(1) cost.  But personal benefit is not why I'm writing on TLUG, I
would take it private if I thought it were appropriate.  So what you
are really doing is either (1) imposing an O(n) cost on the interested
TLUGgers to do the research, or (2) imposing the O(1) cost of
researching and writing on somebody else to do the (socially)
beneficial thing of either writing an introduction to "Productivity
Gains by Using Haskell" or pointing out accessible resource to same.

I conclude that you're treating this as a "pair economics" task.  It's
not.

 > > Google's big problem is concurrency. So is STM a standard part of GHC 6.8?
 > 
 > Yes. Not to mention very good threading support. It's getting the first
 > non-research parallel GC in 6.10 this fall. Scaling up for massively
 > multicore machines is a one of the big research thrusts in GHC.
 > 
 > Of course, all of this addresses only part of Google's concurrency
 > problem. They really need systems distributed over networks to truly
 > scale. And that's where Haskell would shine over C++ and Java; they
 > could develop better ones, with fewer bugs, in less time.

STM has nothing to do with that?  Then how is this done in Haskell?

 > > Can you refer me to the HOWTOs on using it to solve google-sized
 > > problems?
 > 
 > Yeah, right, like Google needs HOWTOs.

Uh, who doesn't need HOWTOs when confronted with a new technology?
Especially if you're a technically Neanderthal boss trying to figure
out whether the requests from the trenches make business sense?

 > As far as concurrency goes, if you can cons up combinators in Haskell
 > that use these things in other languages, it works just fine. If not,
 > well, you're kinda stuck. Rewrite in Haskell. It doesn't take long.

That depends on how well you know Haskell.

 > But all these are sort of an aside; little points that miss the big
 > picture. Even if Haskell doesn't work out, if you're sitting there
 > saying, "We're planning to work at our current level in C++ for the
 > forseeable future," you're stuck, and someone's going to start working
 > with better tools and come and eat your lunch one day. In this area,
 > Google has stopped innovating, as far as I can tell.

Google never started innovating in those areas AFAICT.  So the
questions are when should they start, and how close to that are they
going to get?

 > > We now return you to your on-going discussion.
 > > 
 > > 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.
 > 
 > And when it's coming from the top? When I talk to CEOs who firmly
 > believe that the solution to increasing the company's programming
 > productivity is to add more programmers, outsourcing to India to add a
 > *lot* more programmers when you need a lot more productivity, what am I
 > supposed to do then?

Well, they sure as hell had better understand the difference between
output (which you can increase by adding programmers) and productivity
(which usually decreases when you add programmers, for MM-M reasons as
well as standard decreasing marginal product reasons).

 > The CEOs are often not technical guys.

I thought we were talking about Google?

 > It's the responsiblity of the tech. and research staff below them
 > to bring them up to speed.

What makes you think they're not up to speed?  The CEO will often have
a good sense of what are proven technologies in software development.
When the TRS comes after them to introduce Haskell or agile
programming they go "show me the white papers", they look at them and
they say "does this really apply to us" and the TRS says, "well, we
hope so but we can't prove it".

 > > 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.
 > 
 > I don't think I'm making it out to be simple. I'm not saying, "dump
 > all of your current project management systems move immediately to
 > agile instead." I'm not saying "dump all of your languages and move
 > immediately Haskell instead." I'm just saying, "stop with the attitude
 > that you've got the right systems right now, and start experimenting to
 > find out where you can improve things."

And how do you know that Google *doesn't* have groups internally doing
that?  Sure, they stick to the tried and true technology by policy
company-wide, but who knows what their research groups are doing?

A friend of mine went to them and said "Hel-lo-o!  You do a lot of
Java stuff, you need a Mr. Java to interface with the language
development committees!  Hire me!" and they did.  They clearly do have
a clue about technology R&D, not necessarily in the areas you
concentrate on, but a small clue.  OTOH, obviously they don't have
SP-J working for them 'cause he's at MSFT, but how do you know that
they don't have (a few, small) groups internally playing with various
languages?  Maybe they *do* have the right systems right now, as
represented by their policies saying production software is written in
Python, Java, or C++, and are preparing to make the move to add a
"more powerful" language later.

 > Indeed. So let me say explicitly now:
 > 
 >     Do Not Jump On The Current Trendy Technology.
 > 
 > Keep in mind, from this point on, I have never said that, and never
 > will say that. (Not to mention that the current "trendy" technology is
 > usually re-hashed twenty year old stuff that the world has a lot of
 > experience with. Java being the classic example, chunks of it having
 > re-iterated the twenty-five years of Smalltalk previous to it.)

Oh, come on.  Java is *popular* but I don't think anybody would call
it "trendy".

 > Most of this stuff isn't even new anyway, and has never been trendy.
 > Jane Street has managed to become a very successful company in a
 > relatively short period of time partly because they did try this, with
 > OCaml. You can ask them about it, if you don't believe me.

These folks?  "Founded in 1999, Jane Street now employs over 100
professionals in offices in New York, Chicago, Tokyo, London, and
Rhinebeck, and has a presence on several major exchanges. Our desk and
floor traders seek out and profit from temporary pricing
inefficiencies in financial markets."

Really Google scale here, aren't we!  On the order of a dozen
programmers supporting 100 traders where you can afford to spend
$100,000/workstation, with calculations that can be done very fast
using conventional software technologies on a single CPU based on data
sets measured in megabytes (ie, almost fits in on-chip cache on
commodity CPUs).  Google is 100 times that scale, no?  And its core
competence is measured in petabytes by now.

 > > Where is the Kernighan and Plauger, or even the Kernighan and Pike,
 > > of Haskell?

 > Yup. There would be two reasons for this:
 > 
 >     1. Haskell is a much less widely used langauge, and in real-world
 >     programming situations tends to be used by better programmers who
 >     already know the importance of "style." Thus, books that discuss
 >     when you should comment, the correct naming of variables, and
 >     suchlike have very little (no?) demand.

This may be a genuine point.  But I don't know whether it's in your
favor or otherwise.  The fact that these languages are used by better
programmers but not very widely suggests that hiring them is going to
be hard.  Also, one thing I've learned from Python is that having a
common set of idioms is very useful.  It's often not obvious that one
idiom is more efficient than another, etc.

Also, at Google scale you can't just hire in a bunch of new
programmers if you expect to make a transition in time to forestall a
more agile (in both the general and the trendy senses) entrant.  You
need to convert your existing programmers, to.

 >     2. Haskell doesn't have a lot of the style issues that, say,
 >     Java would have, due to the style of the language. If you can do
 >     something in a third or a quarter the amount of code, you need pay
 >     less attention to code organization. If your parser looks pretty
 >     much like a BNF description of the language, the idea of what sort
 >     of "coding style" you should be using for it becomes silly: you're
 >     using BNF style now.

Well, no.  In fact my experience is that the same people who write
500-line functions in C also write 250-line functions in Lisp and even
50-line autobumf macros.  I think you're comparing the average Haskell
program with the average Java program but it's your point that that
this moment in time Haskell programmers on averge are much better.
What happens when the two populations are the same scale and
regression to the mean takes over?

 > to whom "where to put the braces" books are irrelevant. I think that
 > Java and Ruby make a good comparison in this; even without IDEs, people
 > don't write Ruby style books. (I'd imagine that Python is in the same
 > situation.)

It's not.  I don't know of an "Elements of Style" book, but Python
people are always concerned with what's good style, and there's a
rough consensus about the applicable principles of style, both for the
future development of Python and for ongoing development in Python.

 > > I do not think that failure to adopt Haskell "now" can kill Google.
 > 
 > Not the failure to adopt Haskell specifically, no. But the failure to
 > developing internal expertise in better languages in general, and how
 > they can be applied to Google's business, will unquestionably hurt them.

Maybe.

 > > 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?
 > 
 > Why not? As someone I can't recall once said, "If your idea is any good,
 > you won't have to worry about anybody stealing it. You'll have to shove
 > it down their throats." As far as I can tell, the advantages you get
 > from having a lot of people look at your idea, comment on it, and offer
 > improvements outweigh the disadvantages of having others in the world
 > know details about what you're working on.

Sure, but Google has 10,000 programmers.  That's more than are working
on the Linux kernel.

 > > The problem is the massive infrastructure of libraries that languages
 > > like Java, Python, and C++ bring with them,
 > 
 > Actually, that whole library argument is what the Java folks use, I used
 > to think it was a good thing myself, and since I've become a better
 > programmer I've come to the conclusion that it's a load of rubbish.

[...]

 > But you yourself have seen a situation recently where starting off with
 > a library for parsing mail headers seemed like a good idea, and this is
 > a library that's less than a thousand lines of code and comments.

Yeah, well the library you chose is an undergraduate exercise, not
production quality.

 > > ...and the well-known idioms for doing things in those languages.
 > 
 > Right. That's something that has to be learned. Again: start now, and
 > figure out what works and develop external expertise. Don't just ignore
 > the issue and say you're going to stick with Java for the rest of your
 > company's existence.

You have an URL for a press release where Google announced that?

 > > But it's typically not true; every programming language community
 > > seems to reinvent things like web frameworks multiple times.
 > 
 > And for good reason. Continuation-based web frameworks work very
 > differently from REST-based ones, and are suited for different kinds
 > of applications. Starling built its own web framework for very good
 > reasons: ours probably works better for internationalized keitai
 > applications than anything else out there. But I can think of plenty of
 > situations where I'd even recommend Rails to someone, much as I despise
 > it myself.

Sure, but my point was that (a) overlapping, basic functionality gets
reimplemented in the same style multiple times, while (b) they don't
learn from the successes and failures of other communities very well.