Rantings on the Computer Industry
Copyright 1999 Joel Matthew Rees
Takino-cho, Kato-gun, Hyogo-ken, Japan
Always Under Construction
発行元:ジョエル マシュー リース
日本 兵庫県加東郡滝野町

The Fanatic Rants and Rambles on 狂諦観者のあてもなく怒鳴り散らす

Computers and Games:
My cousin Ben once told me that the only real purpose for computers was to play games. Games are, of course, a very important use. (One of my favorites is a game called infotron. I wonder if the authors are still supporting it?) I somehow made it past adolescence rather weak on my risk-taking skills, and computer games helped me to, well, learn a little about how to take risks. I myself think games are significantly more important an application area than programs that print reports that are only used to tell employees there isn't enough money to do anything right.
従弟のベンが昔言ってくれた言葉です。「コンピュータはゲームを遊ぶために存在している。 意味在る用途はそれ以外にない。」 無論、コンピュータの用途の中にゲームが大きな位置を占めていると思います。 (「Infotron」というゲームが僕の好きな一つです。著者はまだ製品として支えてくれているかな?) 失敗を冒す腕前をあんまり身に漬けずに思春期を通ってしまったのですが、 コンピュータゲームがそういう、危険を冒すような勇気を助けてくれたものです。 兎に角、僕個人の意見ですが、 計算機の応用領域として、 従業員にちゃんとした仕上げのために資産が間に合わないようなことを信じさせるような通知表などを 作り出すような業務用ソフトよりは、ゲームの方がずっと意味あると思っています。

Computer Languages for Business:
CoBOL is my favorite language to hate. No real constants, no natural parameters, no support for local variables, no built-in stacking machinery, very much oriented to the finite state machine, very little support for anything more complex than the simplest context free grammars. Undos are among the many useful context-sensitive functions that are difficult to implement well in CoBOL. (Maybe that's why accountants like it.)
僕の嫌うに一番に思っている言語がコボルでしょう。 本当の常数が出来なく、 引き数や毋数(媒介変数)の扱いが不自然し、局所変数を支える構造も無く、 情報を積み重ねる容器が組み込みの機能に含まれていなく、 可能な状態が狭く限定された機械の向きばかりで、 複雑で無く非常に簡単な文脈無依存の文法(前後無関係の手順)以外には対応する仕組みが無いのです。 「取り消し」の機能を例として取り上げるが、 とても便利で前後関係するコボルで実現しにくい処理は山程あります。 (多分、計理士がコボルを好む理由は、 取り消しのような複雑な処理が作り難いためでしょうか。)
Some people are calling Visual BASIC the CoBOL of the 90s. This is nonsense. VB goes so far to the other extreme in trying to support complexity that it is hard to understand your own code, even on the same day you wrote it. CoBOL was designed by a genius. VB is a kludge of drastically disparate parts, requiring a large group of skilled mathematicians to hold it together.
ビジュアルベーシックのことを90年代のコボルと唱える人が居るらしい。 まさか。 複雑性を支えるために正反対の姿勢をとって、 作成したその日に読み直しても理解しにくい程です。 コボルは天才により構築された言語です。 「ビジュアルベーシック」とは、 極端に異なった、接触面の狭い部品の即築組み合わせで、 保守に、熟練した数学者の大集団の手を要するものです。
VB and CoBOL have this in common: Once you get used to them within a specific, restricted operating environment, they are both very convenient for writing quick-and-dirty, throw-away programs. (Scripting languages are even more convenient, however.)
ビジュアルベーシックとコボルはこの共通点があります。 特定の狭い操作範囲内に慣れたら、 双方が荒れ模様の使い捨てプログラムを短期に開発するのにとても便利なのです。 (但、スクリプト言語の方がさらに便利に思っています。)
VB does happen to be good for building mock-ups of real applications. Unfortunately, it does not contain the machinery for directly converting the mock-up to a real application. To build a real application that doesn't eat your lunch with bugs and fixes, you have to start over from scratch with a real application language, and a lot of middle-managers in software don't have the training to understand why.
具然でも無いのですが、計画中のアプリケーションの模擬版を組み合わせることに、 ビジュアルベーシックが役に立ちます。 期待外れ、そのまま使って本物のアプリケーションの開発を進ませるような仕組みではありません。 修正の繰り返しと昆虫類の普及に昼食が食われてしまわないような、 本版のアプリケーションに持っていくためには、 また別の本格的な応用言語を利用して再実現する手段が必要です。 そして本格的な応用言語の必要性を理解する程の訓練を受けている中間管理職が数足りないのが現実です。
If you are a middle manager and VB is eating your lunch, get yourself a good book on the theoretical and practical foundations of complexity. Ask your nearest mathematician why context-free is not very free, and why tools that map to unrestricted grammars usually do not get high marks for manageability.
お仕事が中間管理職ですか? ビジュアルベーシックに昼飯食われていますか? 複雑性の基礎を学理上や実用上に説く本を手に入れることをお勧め致します。 又、お隣の数学者に、文脈無依存性が何の訳で自由ではないのかを聞いてみて下さい。 その序でに、無制限文法に適う道具がどう言う面で管理しにくいかをも。
What do I recommend for a database language, to replace CoBOL? I used to recommend C. But we now have dedicated database engines with their own languages (SQL, 4th Dimension, Filemaker Pro, etc.) and scripting/editing languages like Perl, in addition to C/C++/Java. At the present time the question turns out not to be which one. The general solution is to combine a dedicated database engine with a scripting language, adding special functions in C/C++/Java.
コボルの代わりに何のデータベース言語を推薦しますか? 以前はCでしたが、考えていることを若干換えつつです。 C/C++/ジャヴァ以外に、 独特の言語を持つデータベース専用エンジンも(豊富に)、 パールのようなスクリプト(台本)・エディット(修正)言語も在ります。 ですから、「どちら」と言う質問ではないようになりました。 データベース専用エンジンにスクリプト言語を加えて、 特殊機能をC/C++/ジャヴァを使って埋めて行くやり方が雑多な応答でしょう。

Companies That Are Too Big:

When a friend asked me to help translate The Secret Diary of Bill G. into Japanese, I wasn't sure I wanted to. One, why should I help give Mr. Gates and his company any free press? Two, Bill Gates is neither God nor the devil, but giving him too much negative attention could sure help push him too far into the wrong camp.

But I figured a friend is a friend, so I ocassionally advised him about the meanings of some of the really difficult idioms. (His translation of the book far exceeds my efforts to help.) I have since seen some other paperbacks in similar vein, and I decided Bill G.'s work was probably necessary to counter some of the really mean things others are saying. It may be Mr. Gate's best defense. (I actually would not be surprised if Mr. G. turned out to be Mr. Gates.)

I really wish our industry could do without Microsoft. They have helped slow progress down so we can spread the base of our technology (which is a good thing), but right now they are sucking up all the profits we need for new research.

We really don't yet know enough about computers. Back off, will you, Bill?

(Added 15 April 2000:) My opinion on the anti-trust action. Split Microsoft along every product line, so that each product is put back on equal footing with it's least-integrated competitor. Require each company and product to be renamed, dis-allowing the names that include "Microsoft". Forbid Bill Gates from participating in the management of the resulting companies. Finally, ban both Mr. Gates and the resulting companies from any involvement in standards processes for the next five years.

This might be hard on the industry, but we deserve it, for co-operating with Microsoft. In the end, though, the Microsoft products that survive will improve significantly, along with the competition. Our industry's a ghetto right now.

(Added 2 Feb 2000:) Mr. Gates is just an ordinary joe who got lucky, or unlucky, depending on your point of view. Microsoft will eventually be just another GM. The real problem is us. We buy the software. We buy the hardware. That's bad enough, but we also buy the sales pitch. We throw good money after bad trying to learn the incantations to make the junk perform. We buy the illusion.

So don't blame Bill, just quit buying the illusion.

Computers and the Japanese Economy (Winter 2000):

The Japanese economy has continued on its downhill slide for ten years, now, and shows no real signs of recovering. The Japanese just don't seem to get it. They are still chasing the bubble, wondering why things can't return to a way they never were (and never can be). They (as a society) can't seem to understand that when you ride the boom, the bust will always throw you; that real money represents real value, and real value is the product of real work.

Computer companies in the USA have led on both fronts on the economics battle. While the open source community has been busy supporting the world's economy with hard work, certain overly-large corporations have been busily making up rules for other people to live by. As a result, the US economy moves sluggishly forward. But money flows, so we all think it's OK.

Japanese society has trouble understanding freedom. They still think freedom, like good food, is only for people at the extremes of the economic scale. They still don't perceive a difference between being free and being arbitrary. Where the American computer industry includes people of both camps, most of the Japanese computer industy seems to be seeking to make people operate according to strictly context-free rules. The programmer makes the rules and the users jump through the hoops. For most of them, Macintoshi, for instance, are for "creative" people, and are therefore taboo for ordinary people. A general-purpose tool is for artists and weekend mechanics, not for professionals.

(How are Americans different? It's a matter of degree, mostly. We are closer to the pioneer spirit, so there is more acceptance in the US of the fact that ordinary people must to be creative just to survive, much less be happy.)

The entire reason for the existence of computers is to enable, not enforce; to enoble, not enslave. A real computer is a tool for the user to wield. A real computer does not force users into any mold, whether the mold is a corporate policy (employees) or a business plan based on enforced patronage (customers). Apple struggled when management tried to enforce a sort of "Apple way" on programmers, and Microsoft will lose all that black ink if it continues its monopolistic activities, unless government steps in and does something really bad.

What does the Japanese economy need? The same as any country, more people who would rather work than jump through hoops; less business-as-usual and more voluntarism; less rank and tenure, more personal progress through service, especially in management; less selling the latest icon and more empowering the consumer.

If business is not service, it is nothing.

My Preferences in Computers:

The perfect computer does not exist. Of course not. It's a mathematical impossibility. Anyway, I'm saving up to get one of the new (bottom of the line) Macs that are scheduled to run Mac OS X. In the meantime, I am considering replacing the 68LC040 in this Performa 630 with a straight 68040, re-partitioning this ridiculously huge 4GB HD, and installing NetBSD. I like UNIX and I like the Mac. I wish I had the extra money to buy my wife her strawberry iMac. (She hates computers, but she says she'd love to be able to show off an iMac. Why no iBooks in Strawberry?) While I'm at it, I might as well wish for a dedicated digital line and someone to sponsor my research in OSes, computer languages, and character sets. Research nodes don't need near as much power as provider sites, so I could power the site on some old second-hand Macs with one of the pseudo-public-domain UNIXes. Dreams are free, or are they?

The year after I started college at Odessa College, we were excited that administration had sprung budget for a 100MB drive. We students were each allocated 4 KB program space on that old UNIVAC 1106, which meant we didn't have to cart punched card decks around so much. My second year at BYU, one or two of the CS department's VAXen had 100 M drives. My first Mac, a Performa 550 (which my brother-in-law now plays games on) had a 32 MHz 68030, 8MB RAM, and 160MB HD. Now my 2GB disk at work is packed to the gills and the 80MHz Power PC attached to it really isn't quite fast enough for CyberStudio.

I told my CoBOL teacher at OC that my M6802 protoboard with its hand-wired BASIC ROM and 64KB dram was not that far behind the 1106. I thought I was mostly joking. I didn't really want to believe the implications myself. I couldn't imagine how I could compete in a world where programs took more than would fit in that M6802 protoboard.

If there is anything that is sure in this world, it is change. I think if I had read The Citadel and the Bazar, I might have felt some relief, but I might not have. I don't think I would have understood. I'll have to comment on that essay sometime.

My Preferences in Languages:
(Revised 19 May 2000.)

The perfect programming language also does not exist. I like C, but I think the ANSI standard was a wash. So is C9X. I like some of the promise of C++, but the original idea missed the mark, and then Microsoft got hold of it. Objective C looks a lot better, but the foundations, C, itself, needs some re-work.

Number one on the list is stripping out the predefined types. The fundamental type must be unsigned bit field. (If we can handle non-linear addressing and the complexities of address boundary alignment, why can't we handle free-standing bit fields and bit field arrays in plain C?) The extraction method (sign fill/extension, padding, offsetting, etc., and byte order, etc.) must be declareable as part of the type, and the default (or native) types explicitly declared somewhere. Constructor functions in C++/JAVA come close to filling this need, but types must be also be queriable, in some manner such as macros are queriable.

Name spaces are obvious. Not so obvious is that the compiler should be optimized for small name spaces, even if this means punishing large name spaces. Name mangling may be appropriate for overloading definitions, but real name spaces must not be implemented by mangling or overloading. (I know this means abandoning that favorite standard, the hash table, not to be confused with Perl hashes.)

But I myself don't really want to get involved in re-working C. I have been fascinated by FORTH ever since the days of the fig model. I typed in the hex object on that M6802 protoboard my brother gave me, and I re-implemented the fig model on the 6809 (Radio Shack's venerable Color Computer) with (direct page, woops) direct threading and a symbol table that was a forest of ordered binary trees. What I really want to do is re-implement FORTH as a collection of libraries clustered around a parameter stack that is independent of the control stack, and a collection of interpreters that includes in-fix and pre-fix grammars as well as post-fix. I am describing some of the (really) low-level details in my ramblings on run-time architecture. I am also working (?) on the high-level description of the language.

C as a Database Language

(I should note here that, as I learn Perl, I get the impression that it is reasonable to call Perl a unified and simplified interface to practically all the C libraries available in the UNIX world. Which would mean that Perl actually succeeds at what C++ tries to do.)

There are two approaches to reading data from files in C: column free format and column restricted.

Hand-edited files tend to pick up column shifts and ragged line endings, despite the best intentions of those entering the data, so column free format is for files created and edited by hand with ordinary text editors. It is a must for data like program source code which must be handled by hand.

My program ranbunhyo is an example of a database using a column-free format. The word databases are written with a text editor, one word to a line. The quiz databases are also written up with an ordinary text editor, using flag characters to show where each question starts.

Restricting a column format is the easiest way to give structure to a database, but is not very amenable to hand-editing. HTML links are an example of methods for structuring data in column-free format files, but searching and sorting, and even linking, the data in HTML and other column-free format takes a lot more time than searching, sorting, and linking data in column-structured files. Summing and averaging fields and maintaining dependencies between fields is the same. Basically, all automatic functions are significantly faster when the data has a column-restricted format. When you have large amounts of data with complex internal structure and complex internal dependencies and interactions, column-restricted formats seem to work better. The price is not being able to use simple editors to work on the data. You have to build special editors.

Restricted column formatting is for mechanical database files, files generally neither created not edited by hand. The format restrictions are primarily to allow high-speed handling of large volumes of data with a complex but regular format. A customer database can be kept using either appraoch, but when the database is large, or the record fields are numerous and the interactions complex, the restricted format yields a better response time.

Many experienced UNIX users suggest that restricted format databases should never really be necessary, but I think they are talking about an ideal world where companies are small and customer relations semi-formal.

(This is called leaving off just when it gets interesting.)


^v:computer c00.00.06ej 2000.05.19