My Best Teaching Is One-on-One

一対一が僕のベスト

Of course, I team teach and do special lessons, etc.

当然、先生方と共同レッスンも、特別レッスンの指導もします。

But my best work in the classroom is after the lesson is over --
going one-on-one,
helping individual students with their assignments.

しかし、僕の一番意味あると思っている仕事は、講義が終わってから、
一対一と
個人的にその課題の勉強を応援することです。

It's kind of like with computer programs, walking the client through hands-on.
The job isn't really done until the customer is using the program.

まあ、コンピュータプログラムにすると、得意先の方に出来上がった製品を体験させるようなことと思います。
役に立たない製品はまだ製品になっていないと同様です。

Thursday, August 11, 2011

program bugs in context

A thread in the fedora users list on debugging html pages got me thinking about context, and I ended up posting this. You have to read it in context to follow what I'm talking about (if that's possible), so I'm posting the same here with some explanations:
Ten years ago, Japanese people who used the internet could (more or
less) read English, and Latinized (romaji) spellings of Japanese used
in urls didn't cause many problems either.
Twenty years ago, it was a common assumption in Japan that, programming languages being non-human languages anyway, English was the "proper" context language for all programming. The assumptions was so strong and ingrained that I was never able to sell my idea for a pre-processor for C that would allow the use of Japanese symbols, using headers that would contain suitable mappings between Japanese and English based variable, function, and macro names.

I think I have identified several reasons for that attitude.

One, of course, is that programmers tended to be not overly worried just by the mere sight of stuff that isn't their native language. (Not to say that they are all in love with the English language, just that they are not immediately threatened by discrete foreign symbols.)

Another is that it is (perversely) comfortable for them (and us, too) to isolate the entire technical context from their (our) day-to-day world. And English based symbols helps the isolation when English is not your native language.
These days, ordinary Japanese people use the internet, and the latin
basic set urls are just as meaningless as telephone numbers to them.
Less, perhaps. (Yeah, they get force-fed English in primary grades,
but that doesn't mean it is even comfortable for them to "read" -- and
comprehend -- new combinations of romaji.)
Yeah, that's what I do for a living these days.

(Not much of a living, and, even though I enjoy the work, I have to either change jobs or ask my poor wife to take full-time work. No money in it, no way to certify and get the same pay package that people born in Japan get. Without the bonuses, insurance, Japanese version of tenure, retirement plans, etc., no way to support even just two children through high school. You AET/ALTs who think you want to marry someone Japanese, be warned. You will have to find some other way to make a living, usually just when you get to where you can actually do the AET/ALT job reasonably well.)

Well, I try to avoid the force-feeding approach, but some of the students just aren't ready or interested. There are more teachers like me these days, who can make English less threatening, less of a trial and tribulation, more interesting, more fun. But we each have differing abilities to reach students, and there will always be at least one or two in ten who will not like English. No surprise, there, since even in the US there are students who don't like English.

Heh. I didn't like English in the primary grades. Not until my junior year in high school.

At any rate, the role of Japanese in URLs is not exactly limited to syntactic sugar.
On the other hand, simply allowing Kanji to be used in urls is going
to create as many problems as it solves. It would be almost easy to
fold hiragana and katakana, but not even possible to fold kanji and
kana. As a result, the ads you see in trains tend to show the katakana
or hiragana for a company's name in a search box, with the search
button being clicked.
Katakana is a kind of box-character phonetic writing system. These days it is primarily used for foreign (borrowed) words and emphasis. Kind of like italics are used in English. Hiragana, on the other hand, is more of a cursive phonetic writing system.

The two sets of characters are almost corollary, but native Japanese doesn't have certain sounds that are common in some languages, so there are a few characters (voiced "u", for instance) that exist in the katakana but not in the hiragana.

(I personally would like to research a reformed kana syllabary where all the permutations exist in both sets, but that sort of thing is definitely not in the standard Japanese character sets at this point.)


Just an aside, the roles of katakana and hiragana relative to foreign words sort of reversed before World War One and reversed back after WW II, in the processes of standardization.

And, lest we forget kanji, almost every kanji has more than one pronunciation. And almost every pronunciation that can be mapped to a kanji or a string of kanji has more than one mapping. Endemic one-to-one.
As Paul points out, we should solve our problems in the local context
first, since it's the one we best understand, and the one we probably
need most to work in.
That's such an important rule. It's founded in mathematics, or, at least, provable with advanced mathematics. So many wars and other social problems could be avoided and/or solved if we would all postpone our efforts to solve other people's problems until after we had solved our own.

Not talking about helping other people, taking about trying to solve their problems for them.
And then we try to figure out how to get things working in a broader
context, and at some point we have to resort to a layer of
translations (a human version of an API, perhaps?). 
APIs -- Application Programming Interfaces. These are the methods and definitions that a program module presents to the outside world, the interface by which the outside world "uses" or interacts with the module.
And our minds tend
to handle so much of this so well, that it's often a surprise how much
detail you have to add to mechanical rules. 
Mechanical, as in a context-free grammar or a state machine, with simple, straightforward rules that can generally be analyzed in a finite amount of time.
And then there are
problems that you just have to leave unsolved (and hope something
works out), like the issues with Japanese in urls. And that's when
there are no bugs.
This is the realm of the real world, unprovable systems that we use because, even though they are not proven, they seem to work.

Which is a long rant, just to say that, no matter how hard we try, the real world is never going to match our ideals.

I'm not saying we should give up on our ideals. But we do need a certain amount of flexibility to get along in the real world, including the flexibility to sometimes refine or even re-define our ideals.

The real world will always have plenty of problems to present us.

Monday, August 1, 2011

Ramifications of economic ethics and morals on the environment

Finally found the stuff for developing Google Apps (not Android) again. The free business accounts don't seem to have the link. So you have to look under the Account Settings of your personal google account.



Under Services, you'll see the App Engine, and, to the right of that, "My Applications". That's the link.

Waffling between starting with Java, which I have some experience with, Python, which I have played with, and Google's Go, which I really am not particularly interested in, myself, but, .....

SPLASH!

CRASH!   POW!!    
GASHAN!  GASHEEN!

Okay, okay, I'm still a little backwards on the Japanese onomatopoeia. Not reading enough  manga, I guess.

Daddy! The turtle's out! 

He knocked the tank over!

A family friend who has made an accidental hobby of raising turtles gave us one of the progeny a couple of years back.

Actually, gave us several, but the first two, well, they got stolen when we were keeping them out front. (We hope they went to a good home, anyway.) She later gave us another, and we keep that one on the balconey, and it's getting too big for the tank we have.

So we put water in an old medaka tank and put that on the lid of Spencer's tank, so he can't get out. But today he pushed the lid open far enough to knock the tank off the lid. It was time to go change his water and let him out for some exercise.

Cruelty to turtles. Yes. We can't afford a proper tank, with air pump and filtration, etc. I'd post pictures, but I don't want to get attention from the SPCTA. Bluntly speaking, I don't really make enough money to keep a turtle.

I don't really make enough money to keep a turtle.

There's something wrong in the world when an ordinary Joe can't make enough money to raise two kids and a turtle. 


What's that got to do with the economy and the environment and ethics and morals?

Well, we are getting to the point of having so many people that there's no more place for the critters. But the critters are important for the environment.

No, I'm not a tree-hugger in particular. I just notice that further refinements of our technologies are taking is, in every field, right where?

Biology.

And you say, so what?

Well, whether you call it nature and evolution or whether you call it God, we have a world full of advanced technology that we didn't invent. But we have convinced ourselves that,
if our hand ain't touched it, there ain't no point.
So we get tunnel-vision, focusing only on the inventions of our own hands.

But we keep finding that the things our hands haven't touched yet are the things that have the most value to us.

So, there's the conundrum, the dilemma:

If the economy does not expand, it contracts. If it contracts, scarcity reigns, and control freaks take over.

But we are clearly hitting limits.

Do we really dare risking having to re-boot the environment with our own crude technology?

Leaving a whole lot of questions begging, modern apartment buildings are too small to raise pets, even if the rules allowed it. But we have come to a point that the animals have no place besides where we are living.

Sure, we can talk about how vultures in the financials market force all the builders of apartments to do it as cheaply as possible, but that's just an excuse. Look in the mirror when you say "vulture". Look in the mirror when you excuse your corner-cutting on the competition and your investors.

Today's bottom line is important, but so is tomorrow's.

We need apartments with room for pets, because we, as a society, need the pets.

We need them for the future of the ecology, even if we think we can so casually squeeze people psychologically.

We need to move families out of apartments when we can, to houses with room for gardens, because the economy needs people who are somewhat independent, and because the ecology needs more plants.

We need to pay the guys at the bottom of the wage ladder more so that they can do this kind of stuff that keeps our society from imploding.

And we can afford to do it. The extra money is there, if we refuse to be scared of the mirage of the wolf at the door. If we have to see wolves, there is a wolf in the house and it is eating us alive because we refuse to let other people have enough economic room to make choices.

It is our duty to ourselves to quit trying to squeeze every last dime and penny out of every transaction.

Monday, July 25, 2011

Oracle's patent #6061520

I posted at groklaw on this and I want to keep track of what I wrote.


At the current point in the proxy skirmish that is the patent face-off between Oracle and Google, several patents have been overturned, and one has been allowed, with claims narrowed, as I recall. Several remain in process or waiting in the queue.

The one which I understand to have been allowed, well, for all that the patent office has allowed it, is quite typical of a patent that should not have issued.

US Patent 6061520 describes, rather ambiguously, a series of steps for applying the technique of code optimization known among other things as constant elimination by "pre-playing the code" (or "play executing"), applied to initializing Java classes.

When we write software, we generally include a large number of constants (numbers, text, and other things which don't change while the program is running). Many of these constants are used to set up starting values of stuff the program references (thus, to "initialize variables").

In order to save the computer some calculation time, we often pre-calculate these constants. Say we want to use π. We can approximate it roughly with

22 / 7
but that still is a division the computer has to perform. 3.1416 is much closer, but may not be as accurate as the computer can represent internally. We could also write it as
arctangent( 1 ) * 4
which will be very close to as accurate as the computer can get (without special help).

(Before I go further, I should note that the Java language contains the constant π, as java.lang.Math.PI , so this is a bit of a contrived example when talking about Java, unless we want to talk about the arbitrary precision java.math class, which introduces a whole bunch of arcane programming that this conversation would quickly get lost in. Not entirely irrelevant, but not useful for the conversation at this point.)

But taking the arctangent of 1 does not come completely free.

Wouldn't it be great if we could get the computer to make that calculation once, then use the pre-calculated result everywhere the constant shows up in the program.

Yes, we can. Usually. Sometimes. A lot, with modern languages.

The patent references an example of an array initialization:
static int setup[ ]={1, 2, 3, 4};
and then says some stuff that lets you know why Java has a reputation for slow startup.

In C, that array declaration would be simply the values 1, 2, 3, and 4 stored in sequence in a table of all the initial values constants that the C startup code just reads directly into memory. No calculation whatsoever. No loading constants to the stack just to store them. No dealing with individual values. It's just part of the machine code image and gets loaded en-masse into memory with the machine code for the program.

Pre-calculating 22 / 7 is easy. Most mature compilers of any language, whether byte-code interpreted or compiling down to machine code, have been able to recognize constant expressions like this since time immemorial, or at least since the early-'90s. That is, I used compilers that were developed in the mid-'80s which could do it. If I were in Utah, I have two old AT&T Unix machines there from that time period, which have compilers that do that much. I have with me now a Metrowerks C compiler from the early-90s that does at least that well.

The process is called scanning for invariants, and it often proceeds in two passes. One pass will see the 22 and the 7 as constants and the next pass will see an ordinary arithmetic expression involving nothing but constants, calculate the expression, and leave only the calculated result for the main pass of the compiler to use later.

Calls to functions are a little more difficult, because functions can have side-effects, but some compilers are able to at least work with standard library calls that are known to have no side-effects and are passed constant parameters, and have been able to do so since before Gosling and his friends started working on Java in the late '80s. (Microsoft C claimed it could do proper initialization, but their implementation was incomplete and not really correct during the '80s.)

The language Java is virtual, and is compiled class-by-class to byte-code. Byte code is kind of like standard function calls, and a little hard to predict the side-effects of sometimes. And then there was the question of where the constants should be stored, and, for some reason, with the byte code for the class apparently wasn't an interesting answer. So Java couldn't just generate the constants and store them with the compiled byte code. It had to store them within the instructions to explicitly initialize the array, one element at a time.

If I read the patent right, this patent is a specification for performing initializer invariance analysis in Java by the supposedly cheap method variously known as pre-flighting the constant space, simulated initialization, play execution (Sun's chosen term), and such, and for additional instructions which initialize the various data constructs of Java.

Except it doesn't solve certain difficult problems, just waves its hands about allocating a piece of memory for the initialization code to simulate its work on and building the initialization tables according to the effects on said memory.

I'm not sure why Java needs more than a block copy for the initialization, but they seem to think it helps overcome unnamed issues. Perhaps side-effects, volatile storage, and such?

This may be an improvement on one-at-a-time for Java, but not particularly new to the world of software in general, especially .

Pre-processing the source code for invariants is also conceptually at odds with the idea of interpreting byte-codes. (One of the design goals of Java is to refrain from programming devices like the C macro pre-processor.) In the end, I think it's a culture thing, but anyway, they didn't want to call it that.

At the time of the patent, many of the popular interpreted languages (certain BASICs, perl, etc.) did more-or-less what this patent talks about, and more. Some would set up a limited mock-up of the run-time, and compile the source into the mock-up, turn the initialization code loose, and look for constants that fall out. Then those constants would go into a table.

(Perl has a byte-code compiler, but it has not been very successful, in terms of saving the byte-code and running from that instead of from source. I think they got stuck in the same kind of places Java gets stuck in, and, instead of claiming a -- partial -- solution, just generally recommended not using those features unless you knew what you were doing. Still, Perl does compile to byte-code as it starts up, and it includes initialization constant evaluation as part of the compile phase, as I understand it.)

I re-read their method, and there is nothing either new or original about what they are doing. Maybe it was new to Java, but it was not particularly original. (I suppose I should go dig up the old perl newsgroup posts on the subject to prove it?) And the patent doesn't provide us with any clues as to what specifically was really innovative even if the patent is just to apply to Java as a language (a bit of a stretch) or just to Sun's implementation of Java.

I suppose they could claim that a bytecode instruction that initilizes an array is an innovation, but that would be just playing with words. A bytecode instruction is a function call, and many languages have function calls that do the equivalent. Class and object oriented languages build such functions as necessary for the class instance initialization, as this spec indicates.

Constant pre-evaluation is obvious and part of the state of the art, whether by play (simulated) execution or by the more explicit pre-processing methods of compiled languages. In fact, it is (and was at the time) among the implicit goals pursued as a language matures.

After several read-throughs, I think the innovation claimed is that they pick out the initialization code and execute only that against a pre-cleared, throw-away region of memory. But you still have to track which expressions are known invariant and make sure all the rest get executed after the first constant pass of the initialization. Or you have to limit the expressions allowed in initialization code. Java does both.

As to whether using a throw-away memory allocation to run the initialization code against, coming back from a break bringing in the laundry, I realize --

Any attempt to calculate the results of initialization code has to use a throw-away region of memory. Where else does one store the results?

And, as I said before, it's not really an innovation, when compared to what was available in other languages.

Come to think of it, I remember fighting with the Java compilers and wondering why the code I was writing looked okay by the spec as I read it, but kept being rejected by the compiler as containing non-final code. If I'd read this patent spec first, I'd have had a better idea how far one could go in initializations, and why things I expected from my work in other languages didn't work in Java.

I wonder if the problem is the confusion caused by incompatible use of jargon, as in "pre-flight invarant analysis" versus "play execution". (Or as in byte-code vs. p-code vs. pseudo-code [sic] vs. i-code vs. intermediate code [sic].)

Anyway, that this patent was not overturned is more evidence of the practical results that are making it obvious that software patents are at best wrong in their current form.

Too many software patents are just feature lists lifted from the marketing materials, and dressed up with just enough technical information to make it look interesting and unusual, but not including enough information to implement, and not including enough information to determine the pre-requisites of patentability: originality and innovation. (Whether software patents can be otherwise is a rant for another day.)

Saturday, July 16, 2011

What was the Thriller?

 [This is part of a meta-thread on Love and Romance.]

The 8th grade (middle school second grade in Japanese) English teacher I work with this year used Michael Jackson's Thriller in his relax-before-summer classes last week. (Summer starts a couple of days early this year.)

I was watching, and remembering dancing to it way back when. And I was thinking, man, this is chauvinistic.

Well, okay, it was Michael Jackson, struttin' his stuff, being his version of the alpha male. I would have liked it better if his date had been dancing with the ghouls during the credits. (Maybe she was? Too dark to tell. Who was she, anyway? Ah. Ola Ray, and, no she wasn't dancing in the credits. Darn.)

Working through the lyrics,
Cause this is Thriller Night
isn't bad grammar after all. I remember the lyrics always felt bumpy in my head, but I don't remember whether I figured out back then that the lyrics were saying it was thriller night at the theater. Half-memories there.

The Japanese translation we were working from missed the jokes, and plays it, near as I can read it, as straight horror. The line,
To terrorize y'alls neighborhood
is translated with the familiar form of "you", kimi, but ignores the southern sense of neighborliness in the word. (And Vincent Price did such a good job slipping into the drawl and back out.)

And then there's the give-away stanza,

And whosoever shall be found

without the soul for getting down

must stand and face the hounds of hell

and rot inside a corpse's shell.

that just gets completely lost. The "getting down" is completely missed, and the rest is mixed into other places, as if the translator were looking for some relative/conjunctive pronoun and reference that just isn't there.

It isn't there because this is it, the reference, right here. This is the verse the whole thing pivots on, the lines that bear out Michael Jackson's initial assertion that it isn't intended to encourage a belief in the occult.

David Bowie said it more directly, but this is what the whole video was all about:
Let's dance.
And the difficulty that young men have getting that invitation into words.

Well, one of the problems with horror as a genre is that it is usually misunderstood. Much like the rest of art.

Wednesday, July 6, 2011

this and next

I was talking with one of the teachers I work with about this Friday vs. next Friday and why it may be best to just avoid the word next in general, when teaching English as a foreign language.

And I realized what the semantics issue is.

When you're in between bus stops, it's a little bit hard to talk about a this stop. Maybe you think, going forward in time is closer than going backwards, but most likely that's just thinking too hard. And if you hear someone trying to argue that the next stop is the one after this one coming up, well, maybe you figure someone prefers arguing to communication.

Now it is true that there is always a this Friday, even when it is today or tomorrow. But the ambiguities are there.

Next has at least two, slightly different meanings, and a conversation could get lost in the gap.

Monday, June 20, 2011

meanings of "love"

[This is part of a meta-thread on Love and Romance.]

Lyrics to a song by Heart playing in my head on the way to work this morning:

we gotta look right at at each other and say it
turn on the radio and replay it
and fall in love again
we gotta be friends

 (I think my memory is pretty close there.)
The lyrics to the songs on Dreamboat Annie cover a broad chunk of the spectrum of the meanings of love in blue collar society, some ("Love Me Like Music") relatively positive and some ("Magic Man") not so much so.

The title cut, of course, ...

good music.

Anyway, I was thinking of the people in the band and how misinterpretations of the principles of love tend to be all tangled up in most of what ails society.

Sunday, June 19, 2011

the new greed

(I've said this before, but maybe I can make more sense this time.)

There is a new kind of greed in evidence.

I'm not talking about food. Not talking about money or material things. Not really talking (directly) about power.

Well, yeah, it's about power, and it's indirectly about the rest, but we've learned to hide all those obviously evil greeds from ourselves.

Bill Gates and company, back around the y2k fuss, started a publicity campaign called "Freedom to Innovate". (Links to this kind of stuff tend to disappear as the people who pull these gaffs realize what they've done in public.)

The first time I saw Microsoft waiving the US flag proudly on their web site and demanding their (not our) freedom to innovate, calling the campaign "grassroots", pretending that this was what "the people" wanted, I about fell out of my chair.

At the time I was avoiding blogging like the plague it is. But I sure wanted to jump all over their "Freedom to Innovate Network" and ask

Where is MY freedom to innovate? I have an OS and a runtime and an application paradigm that make the Mac OS in all its expressions look pale and tired. (Should be implicit that Microsoft's software was not even in the same game.)
Fiscal realities are keeping that locked up in my head. Those fiscal realities include Microsoft's anti-competitive behaviors.
You've had your freedom to innovate, you've had it all over the map, and you've blown it in a non-deterministic loop. (Random. Random.) You've had your turn.
Where's my turn?

Well, Gates's blind spot there could be viewed as evidence that he is, in fact, a geek. Hubris. The assumption that, just because it makes sense to you it must be logical to everyone.

And there is the greed:

I want to do it all.

And the reasoning behind the greed:

My thoughts are God's thoughts.

Okay, no one in their right minds is going to be that blatant. How about this:

I understand what is right and wrong.

Actually, that's not a bad point of view. We all have to believe that to a certain extent. It's the applying the logic of sequence to that when we only have the first example (close to) correct.

This is the greed
  • To want what is inside our own head to apply to everyone else. 
  • To want to justify ourselves by (1) justifying our understanding of the world around us (our religion, really) by (2) making it apply to everyone else.
Incidentally, this is not what missionary work is supposed to be all about, even though evangelism is often (mostly, in the present tense?) misunderstood to be the attempt to impose one's personal religion on the rest of the world.

What does this have to do with the economy?

Well, it's the wanting to do it all. The unwillingness to share the "jobs that matter" (whatever we perceive them to be) with other people.

The thing that is most scarce in our current economy is not food, not material stuff.

The thing that is scarcest is jobs.

Now you know why.