Smalltalk だとテストコード書きやすい。そもそもメソッドが数百行とかならないし、某○#でもまともにコード書けばテストコード書きやすいのだろうけど、きちんとモジュール分割できる人が居ない。すぐ数百行のメソッドとか書いちゃうわ、メンバ変数なんて外部変数状態だわ、クラスは処理を書く入れモノぐらいにしか思ってないらしい。static書きまくりでポリモフィズムなんて出来ないよ！どうすんのこれ！！
そんな人ばっかりで困ったものです。はあ。
マイ○スイー○ーもどき
暇だったので Pharo で作ってみました。
ベースは PharoByExample に出てくる LightsOut です。
まだ点数やプレイ時間を計測する機能はありませんが、一応一通りの機能は作りました。たぶん。
それと、版権にひっかかりそうなのでタイトルは一部伏せましたｗ
ゲーム自体は作者がアホなため全然解けませんｗｗｗ
アイコンは Pharo で使っているものをお借りしてます。
ちなみに、
Smalltalk ui icons
をインスペクトすると、Pharo が持ってるアイコンの一覧がわかります。
URL があるのでアイコンパックをダウンロードして zip の中身を見たほうが良いです。
Pharo で頑張って探すよりも。
SeasideByExample
文章が古いなら古いで、ソースも古ければまだいいのですが、ドキュメントとソースの内容が食い違い過ぎていて面倒くさくなったのでとばしますかね。ドキュメント流し読みで、ソースをメインで読んだほうがいいかな。
Brilliant Stars Project
| rotatePoint calcPoints mergePoints starPoints | rotatePoint := [ :x :y :rad | ((rad cos * x) - (rad sin * y)) @ ((rad cos * y) + (rad sin * x))]. calcPoints := [ :r | (0 to: 8/5 by: 2/5) asOrderedCollection collect: [:each | rotatePoint value: r value: 0 value: (each * Float pi)]]. mergePoints := [ :outer :inner | | points | points := OrderedCollection new. 1 to: outer size do: [ :i | points add: (outer at: i). points add: (inner at: i)]. points]. starPoints := [ : r | | outerPoints innerPoints | outerPoints := (calcPoints value: r) collect: [ :p | p rotateBy: (Float pi / 2) about: 0 @ 0]. innerPoints := (calcPoints value: r / 2) collect: [ :p | p rotateBy: (Float pi / 4) about: 0 @ 0]. mergePoints value: outerPoints value: innerPoints]. (PolygonMorph vertices: (starPoints value: 20) color: Color yellow borderWidth: 2 borderColor: Color black) openInHand
PharoByExample のモーフの章で StarMorph が出てくるのですが Pharo 6.1 (stable) には実装されていないようなので、作ってみました。
ワークスペースに貼り付けて Do It すれば、星モーフ(のように見えるポリゴンモーフ)が現れます。ちょっといびつですが、それはご愛嬌ということでｗ
プロコン
暇な時に過去問を解いたりしています。コンテスト自体は参加してません。
ほとんどのコンテストは、問題を解く早さにばかり傾倒していて自分は面白いと思わないからです。
ビジネスにおいては「早さ」がとても重要なのでしょう。自分もそう思いはしますが、趣味でコードを書くなら、時間に追われるのはご免です。なんで休日にせかせかコーディングしなきゃならないんですかね。休日ですよ、休日？ 自分は楽しさを見い出せないですね。採点基準が「コーディングの早さ」だけですよ。極端な話、紙と鉛筆で解いて、数字を出力するだけのプログラ厶でも正解ですよ。コードの中味なんて関係ないです。でもそんなコードばかりアップしてると、お前ふざけんな！って運営から注意されるのかな？ 真面目に解くコードしか書かないから、どうなるのかわからないですw テストデータ（非公開）を用意してるサイトもありますが、そういうズルをする人用の対策でしょう。
あとはマイナー言語はほとんど使えないところが多く、やはりこれもビジネス前提です。たいてい流行りの今時の言語しか使えません。Scheme や Smalltalk がないとかムカつきますねw 実際に就活にも利用されるみたいですし。まあ、そうですよね。マイナーな言語を常用する人は、「よしよし、やっぱり無いな（ニヤリ」ぐらい言わないといけないのでしょう*1w
というわけで、最近流行っているらしいプログラミングコンテストはあまり面白いとは思いません。ビジネス臭がプンプンして自分は嫌です。
LISP
LISP の名前は「list processor」に由来します。
要するにリストを処理するプログラミング言語です。
リストを入力して、それを処理して、リストを出力します。
一般的なプログラミング言語の場合:
入力データ → [処理] → 出力データ
これが情報処理(プログラミング)の基本ですよね。
でもちょっと待ってください。
LISP の場合は、データはすべてリストです。
実は、処理もリスト*1です
LISPの場合:
入力リスト → [リスト] → 出力リスト
LISP において、コードとは、
リストを入力し解釈してリストを出力するリスト。
となります。みんなリストです。
他言語で言う「処理(コード)」もリストなので、入力が他言語で言う「処理(コード)」でも良いのです。もちろん、出力が他言語で言う「処理(コード)」にもなりえます。
他言語のために書いてみますが:
入力コード → [コード] → 出力コード
は LISP では普通にできます。
「コードを入力して解釈しコードを出力するコード」が簡単に書けます。
先にも言ったとおり、LISP ではデータもコードもリストだからです。
LISP では:
データ = コード = リスト
ですから、
データを入力して解釈しデータを出力するデータ
コードを入力して解釈しコードを出力するコード
は、なんの問題もありません。
コードを入力して解釈しコードを出力するデータ
コードを入力して解釈しデータを出力するコード
コードを入力して解釈しデータを出力するデータ
データを入力して解釈しコードを出力するコード
データを入力して解釈しコードを出力するデータ
データを入力して解釈しデータを出力するコード
すべての組み合わせも実現可能！
(リストを言い替えただけですし)
なぜなら LISP では
データ = コード = リスト
であり区別しないからです。
そして LISP はリストを処理する言語です。
処理はコードじゃなければいけないなんて、誰が決めたんですか？
入力がデータじゃなければいけないなんて、誰が決めたんですか？
出力がデータじゃなければいけないなんて、誰が決めたんですか？
そんな決まりを作ってしまうからプログラムの柔軟性が損なわれるのではないですか？
LISP では
データ = コード = リスト
です。リストを処理する言語。それが LISP です。
この柔軟さが「パワー」を生み出すわけです。
一つ例を挙げると、LISP は LISP だけで LISP が実装できます。
「ソフト」ウェアって言うぐらいですから、柔軟じゃなきゃダメでしょう？
あなたの使っているその言語は石みたいに硬いですよ。
そして、その言語を使うあなたの頭は、固定観念でカチカチなのでしょうね。
石のように。
*1:S式と呼ばれます
