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.

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

Showing posts with label patents. Show all posts
Showing posts with label patents. Show all posts

Friday, December 21, 2012

patent blues

Give the software patent industry a big, fat raspberry.

Back around 1987, I told a friend who asked me what kind of computer to buy that I didn't like Microsoft for the way they were muscling and hustling the industry.

He asked me if he should then avoid Microsoft, and I admitted that the offerings from Atari and Commodore and the rest of the alternatives, while I liked many of the companies, had the detriment that they were under-represented in the kind of software he needed.

He asked about Apple, and I said, if I didn't like Microsoft, the only reason I didn't hate Apple was that they weren't in the predominant position that Microsoft was.

I told him, I would not like to live in a world where Apple had a defacto monopoly.

Prescience, or what?

So, what did I advise him to do?

Buy the computer for the software he needed, and if he needed more than one, buy more than one.

(If only people had been willing to do that back then, buy the Apple for the kids, for the computer-aided art, etc., buy the IBM compatible for Lotus and WordPerfect, buy Sun for the servers, and learn enough about how to use their computers that they would know to hold their noses when the smelled the stench of anything Microsoft produced.)

It's still good advice, except that I'm going to add Apple to the hold-your-nose category. Buy Apple or Microsoft if you absolutely have to, but don't breathe too deeply, and go to a bit of extra effort to avoid having to.

So, what do I recommend now?

Learn Linux and BSD and the applications that work on those machines. Replace your Apple and Microsoft products as you find reasonable alternatives. Go to a little extra effort to avoid the data-traps Apple and Microsoft lay for you.

Can we trust Google and RedHat? Yes, sort-of, now. More than Apple and Microsoft.

But, and this is the key idea to understand here, systems are dangerous things when they are advocated. (There are historical, psychological, and mathematical reasons for those dangers, and the history goes back well before the beginnings of what we know call the computer industry. Way, way back before that.)

Purveyors of systems, when they get overly anxious to be the one-and-only system, should all be avoided. Google may seem great for now, but once they establish an effective monopoly, give them no more than ten years and they'll be doing the same things that rot out all the good companies, the same things that undid all the good Microsoft and Apple ever did. (Notwithstanding that they do have a better track record than either Microsoft or Apple at this point. Much better track record.)

Any single company that gets that large is going to have this kind of problem.

It would be nice if the Free/Libre software movement could stabilize and provide the technological underpinnings to an industry where there would be lots of small players and lots of consortia, but if Linux-based OSses take over the world, and if the EFF (great players that they are) become the only advocate, we ultimately head for the same problems.

One system to rule them all. That always leads to an evil result.

(Having a triumvirate of Google, Apple, and Microsoft is not a good long-term plan, either, although it's good for now and the next couple of years or so.)

Why must this be so? Why are human systems always going to go south?

Turn the question around: How do you expect humans, even if we can lengthen our life-span to a thousand years, to build anything close to a perfect system?

That kind of perfection literally takes an eternity to achieve. And it should not surprise us that this is so.

Systems are okay to make. In fact, they are good to make, as long as our hubris doesn't prevent us from letting them go when it's time to move on, and as long as our hubris doesn't prevent our systems from getting along with our neighbors' systems, too.

Sunday, November 18, 2012

Software patent limitations

Let's set aside, for the moment, the arguments about software being maths (because too many people are confused by the mathematicians' argument that the whole world is nothing but mathematics).

[Update: I've started a separate blog for this kind of stuff.]

Patents in the physical realm have something that software patents, in their current state, do not have.

Materials.

Structures.

Included devices.

Yeah, limitations.

If we allowed physical patents like the current version of software patents, we'd have patents claiming "materials that have property P" or "materials that perform function F"; claiming "structures that look like S", "structures that perform function F", or "structures that have property P"; claiming "the inclusion of device D", or "devices that look like S", or "devices that perform function F", or "devices that have property P". Etc.

Those who love freedom make a lot of noise about patents on ideas. We'll set those arguments aside for a moment, too.

Surely we can see the problems here. If this kind of patent were allowed, the first patent on any device that reproduced sound would have covered every device that reproduced sound.

Can't you see that?

First, "This patent claims a device that records a physical representation of sound by capturing audio vibrations via a large membrane moving a needle to cut a groove in some plastic medium." paired with, "This patent claims a device that reproduces sound by transferring vibrations recorded in some plastic medium to a physical membrane."



(Don't forget that "plastic" means something besides poly-urethane here.)

These claims would already have been over-broad. (Compare them with history -- think about cylinders vs. discs.)

But the following claims would also have been allowed, most likely in the same patent.

"This patent claims a device that records any representation of sound in any media." paired with, "This patent claims a device that reproduces sound recorded in any media."

Had these claims been allowed, who would have owned the recording industry?

Lock, stock, and barrel. No, broader than that, even.

The courts are trying to restrict these kinds of patents, but they have no guides.

(Perhaps because too many lawyers who conflate maths with human laws have gotten stuck on the software-is-maths argument, drawing the wrong conclusion. The universe is mathematical, but no human has ever yet been able to define the grand unifying theory. The best general theories we have at present are so convoluted they would be subject to patent under the current patent regime -- if we allow software patents in their current form.)

Patents must, absolutely must have some reasonable limitations to be useful. In physical realm patents, materials, structures, included devices, etc., provide the basis for limits. They prevent the patenting of ideas.

(Okay, I snuck that back in. After I showed one of the many problems with patenting ideas, even complicated ideas. So sue me. Wait, someone is likely to do exactly that, so I should set pejorative aside, as well.)

What would be the parallel in software patents? If we absolutely have to have them. (And I think we probably do, at least until we can get our society freed of the atrocity that is the Berne Convention.)

What would provide the basis for limitation?

Source code.

Programming language provides a parallel to materials.

Modules, both physical and program, provide a parallel to included devices. Thus, the libraries linked in, the run-time environment assumed in the compiler, the compiler itself, the operating system, and the physical CPU and peripherals, all those implementation details presently only waved at by the phrase, "implemented in a computer device" provide essential parts of the missing basis for limitation.

("Implemented in which computer device?", for the sake of all that stands before the court.)

And the source code itself is the equivalent of blue-prints, diagrams, methods of assembly, etc. The source code itself is an essential limiting element, and so often missing, except for some symbolic pseudo-code or programming scrap freed from any actual implementation.

Pseudo-code must be unacceptable as a limiting element in patents. You can say anything you want in pseudo-code, because a human gets to figure out the implementation details later. Pseudo-code provides no basis for limitation.

A software patent absolutely must provide compilable source code, and it must be limited by the source code provided, bugs and all. And limited by the compiling environment and the target execution environment, OS specifics and hardware specifics, etc.

All the details of workable implementation, without which, even a very competent computer scientist is hard pressed to reproduce the subject of the patent. Including compilable source code.

These are the missing limitations in the current versions of software patents, and, until we deal with them properly, software patents cannot fail to provide us with an unworkable legal mess.