Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/hkoba/tcltk-gui-starters-ja

Collection of skeletons to write Tcl/Tk + snit based GUI Apps.
https://github.com/hkoba/tcltk-gui-starters-ja

Last synced: about 2 months ago
JSON representation

Collection of skeletons to write Tcl/Tk + snit based GUI Apps.

Awesome Lists containing this project

README

        

# tcltk-gui-starters-ja

Tcl/Tk と snit で、サーバー作業用の GUI アプリを
雑にでっち上げたい時のための、
雛形になりそうなスクリプトをここに集めて行きます。

## お断り

### 今さら Tcl/Tk、したいのですか? 本当に?

今の時代に Tcl/Tk を使って新たにアプリを書き始めることは、
時代錯誤とみなされるリスクがあります。

あなたがこれから作ろうとするものが、果たして本当に Tcl/Tk で書くべきものか、
トレードオフを自分で判断できる人だけ、この道をお進み下さい。

### あくまで hkoba 流です

残念ながら、私は長く独りで開発を続けていたため、
コミュニティ界隈・他の現場の事情を全く存じ上げません。

ですので、ここで私が書くものは、今現在の私が知る範囲ではこう、
という程度のものです。〇〇の方が良いのでは?という意見をお待ちしています。

# 一覧

これから徐々に足していきます。

* [その1](01/snitex1.tcl) Snit + BWidget

まだ一個だけですよ…

# 技術の選択に関して、その理由

## Why Tcl/Tk (still)?

確かに、Ruby/Python/Perl/PHP ... など他の LL よりは
制限の多い言語ですが、それでも bash で頑張るよりは、以下の点で遥かに
マシだからです。

* ちゃんと例外処理がある。
* テストが書きやすい
* イベントループが言語組み込み
* 言語自体がシリアライザに基づいているので、メタプログラミングや、
リモート処理が容易
* 他の LL と比べて、文字列の quote が不要なケースが多い分、色々と雑に書きやすい。
* ちょっとした GUI が必要になった時に、大騒ぎしなくて済む。

### Why not use Tcl/Tk everywhere?

私は Tcl/Tk で全てを書くことには賛同しません。
大抵の技術には『スイートスポット』というか、
それが一番輝く働き場所があります。

例えば、ファイル操作や外部プロセス呼び出しは Tcl/Tk で書くより
Zsh で書いたほうが遥かに短く、楽に書けます。
言い換えれば、最初から Tcl/Tk で書くことは
Zsh で書くよりもコストが掛かります。
もしそのコードがどの程度使われるか分からないなら、
プロトタイプは Zsh で書いてしまって構わないと私は考えます。

同様に、Tcl/Tk は本質的に入れ子データ構造の操作が弱い上に、
Perl の "use strict"/"use fields" に相当する静的検査も欠けています。
ですので Tcl/Tk で大きめの、長期間、進化を伴いながら使われるソフトを
書くときには、他の LL 同様、大量のテストコードを書く必要があります。
そのようなケースでは、私なら Perl を選択します。
(もしかしたら、今後は OCaml に移行するかもしれませんが…)

要は適材適所をお忘れなく、ということです。

### I heard Tcl is a bad language. Is it still true?

* global, global!
* 可変長引数の扱い
* 無名関数
* No Scope::Guard, really?

### So, what is remaining weakpoints of Tcl and Snit?

* 木構造(の葉要素)を表現する方法が標準化されていない。
Tcl の list は一見、木構造を自由に扱える良い仕組みに見えますが、
残念なことに、『葉要素』に関する定義がありません。
これは任意の部分木が、葉であるか、internal node であるかを
判定する方法を、言語が用意していないことを意味します。後は察して下さい。
* 上記の理由により、Tcl で複雑なデータ構造を扱うには、
Tcl の namespace 自体を使うしかない。ですがこの方法では、
GC が不可能になります。
(幸い、Tk の場合は widget の木構造を活用できるため、実害は少ないが)

## Why Snit?

Tcl には OOP のための枠組みが複数ありますが、
私は以下の理由で Snit を使っています。

* Pure Tcl かつ Tcl 8.4, 8.5, 8.6 をカバーしているので、導入に困らない
* delegation ベースの部品化
* Tk の組み込み widget と同じ API を持った widget を自作するための支援が
しっかりしている。
* どんなクラスにまとめたら良いか悩むものでも、
とりあえず snit::macro で部品化出来てしまう。