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

[Curt Sampson <cjs@example.com>]

On 2008-07-26 16:29 +0900 (Sat), Stephen J. Turnbull wrote:

> 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.

I'm sorry if I gave that impression. Let me make it clear: I don't think
you could do the research at O(1) cost, any more than I could.

But this sort of research and argument is a lot of work. I just went
back to find one particular paper, and it took me about fifteen minutes.
I'd love to go back over all of the research I've done on advanced
programming languages over the last couple of years, build an annotated
bibliography, and write up a summary. Unfortunately, I just don't have a
week or two to spare to do that.

At this point, you appear to be using the time-honoured "cavil until the
other guy in the argument goes away" strategy. That's going to work;
I really don't have much more time to put into this. But you might
consider: I've done a fair amount of research into this, albeit I've
not documented it, and in chosing a new programming language for a not
insignificant application (an automated trading system that reads a
market feed and generates orders), I've put my professional reputation
on the line, especially because it will be compared directly with a
previous Java version. That should tell you a lot.

> So what you are really doing is...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.

Yup. It's about time someone else did some work around here. :-)

Anyway, here's a paper for you:

    Hudak, Paul, Mark P. Jones
    Haskell vs. Ada vs. C++ vs. Awk vs. ...
	An Experiment in Software Prototyping Productivity
    http://web.cecs.pdx.edu/~apt/cs457_2005/hudak-jones.pdf

Short summary: this particular prototype was developed by various
teams in nine different programming languages. C++ was the largest
implementation, with over a thousand lines of code, the Haskell version
written by experienced Haskell programmers was 85 lines. A newly hired
college graduate with no Haskell experience learned the language and
wrote a prototype in 8 days; his solution was 156 lines.

Particularly interesting was this:

    In conducting the independent design review at Intermetrics, there
    was a significance sense of disbelief. We quote from [CHJ93]: "It is
    significant that Mr. Domanski, Mr. Banowetz and Dr. Brosgol were all
    surprised and suspicious when we told them that Haskell prototype
    P1 (see appendix B) is a complete tested executable program. We
    provided them with a copy of P1 without explaining that it was a
    program, and based on preconceptions from their past experience,
    they had studied P1 under the assumption that it was a mixture of
    requirements specification and top level design. They were convinced
    it was incomplete because it did not address issues such as data
    structure design and execution order."

Yes, there are a lot of issues related to using programming languages in
real-world situations that this does not cover. I have examined a lot of
those, as well, and Haskell came out quite well.

A couple of other points:

> 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?

You're screwed. As long as you put poor programmers on a task, you'll
get poor results. The solution is to increase the productivity of your
good programmers so you don't need to start hiring poor programmers.

>  > 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.

You miss my point here: Python *is* in the same situation, because there
aren't a pile of books out there about good Python style.

> [Library stuff.]

The libraries stuff I'm just going to bail on; if my experience with doing
these things both ways doesn't convince you that I may have a point, you'll
just have to remain unconvinced.

>  > > 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.

a) Sometimes this is a necessary learning experience.

b) Some people do, some people don't. I often re-implement stuff just to
learn about things, as well as make them better.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com