2017/09/18(月) [n年前の日記]
#1 [prog] Kuinなるプログラミング言語を少し触ってみたり
Kuinなるプログラミング言語が公開されてるらしいので、なんとなく触ってみたり。Windows専用のプログラミング言語。エディタ付き。
_Kuinのダウンロードと紹介 - プログラミング言語「Kuin」 - Kuina-chan
_Kuinチュートリアル1 はじめてのKuin - プログラミング言語「Kuin」 - Kuina-chan
_Kuinのダウンロードと紹介 - プログラミング言語「Kuin」 - Kuina-chan
_Kuinチュートリアル1 はじめてのKuin - プログラミング言語「Kuin」 - Kuina-chan
◎ 第一印象。 :
エディタがついてるあたりはグッドだなと。
_HSP
や
_Small Basic
等もそうなのだけど、これさえDLすればとりあえず始められる、てのは初学者向けを意識した場合、超大事だなと思ったり。導入ハードルは低ければ低いほど好ましい。
とりあえず、チュートリアルを眺めつつ写経してみたけれど。
う、うむ…。どうしてこうなった…。
疑問に思ってドキュメントを眺めてみたら、どれもこれも設計理由が書いてあった。どうやら Pascalの圧倒的なコンパイル速度を強く意識したことで、Pascal由来の記述や、コンパイル処理の最適化に繋がる不思議な記述が増えたっぽい。言われてみれば、たしかにコンパイル速度が速い、ような気もする。
既存言語をガン無視してこうなったのかなと邪推したけど、むしろ逆のようで。C、Pascal、Basic、Python等を例に出しつつ設計理由を説明してあったので、色々意識しまくったら結果こうなったのだ、ということらしい…。
とりあえず、チュートリアルを眺めつつ写経してみたけれど。
- 「=」が「::」だったり。
- 「0xffffff00」が「16#FFFFFF00」だったり。
- 「@」だらけだったり。
- 1行書くたびに頭に「do」が入ったり。
う、うむ…。どうしてこうなった…。
疑問に思ってドキュメントを眺めてみたら、どれもこれも設計理由が書いてあった。どうやら Pascalの圧倒的なコンパイル速度を強く意識したことで、Pascal由来の記述や、コンパイル処理の最適化に繋がる不思議な記述が増えたっぽい。言われてみれば、たしかにコンパイル速度が速い、ような気もする。
既存言語をガン無視してこうなったのかなと邪推したけど、むしろ逆のようで。C、Pascal、Basic、Python等を例に出しつつ設計理由を説明してあったので、色々意識しまくったら結果こうなったのだ、ということらしい…。
◎ 感想。 :
(感想には個人差があります)
個人的には、一つの言語と各種ライブラリを揃えるパワフルさに、まず素直に脱帽。よくまあここまで作れるなあ…。言語・環境を作れる人達って尊敬します…。
ただ、しかし。コンパイル速度と、ソースの入力のし易さを優先した結果、可読性が悪く、また、他の言語に移行しづらい独特な記述スタイルになって、習得しても潰しが効かない、そんな雰囲気も感じてしまったり。ていうかぶっちゃけ、「そんなにPascalが大好きなら、Pascalそのままじゃダメなのかのう…」などと身も蓋もないことを…。
でもまあ、プログラマーって、えてしてこういう方向に最適化しちゃう人が多いから…。意味のある文字列を打つより謎記号を1文字打って済んだほうが早いだろ、みたいな。Markdownとwiki記法を比較して「Markdownは機能が少ないからダメだ」「wiki記法のほうが文字数が少ない上に機能も豊富だから優れている」みたいな判断を下すノリとでもいうか。それはそれで分かるし、そういう方向性もアリと言えばアリだよなと。
もっとも、自分は…。ソースの可読性が悪くなったらバグが混入する可能性が高くなって、結局デバッグ作業で余計に時間がかかるのだから、打鍵数の少なさを気にしてもアレだし、まともなIDEを使えるなら打鍵数は意外とどうでもよくなるし、自分が最後までそのソースをメンテナンスできるとも限らないから、となると優先すべきは、誰でもざっくり眺めただけで「ハイハイ。なるほど」と理解できる優れた可読性を実現することだろうし、そのためには既存言語への慣れを積極的に利用して奇抜な記述・文法は最小限に、などと思ってしまうのだけど。
とは言えもちろん、色んな言語があったほうが色々なことに気付けるし、多様性があったほうが面白いので、こういう言語が存在することは当然肯定するわけですが。いいぞもっとやれ。みたいな。
プログラミング言語マニアの意見感想を、眺めてみたい気もする…。例えば、屈指の言語マニアであろうRuby作者様あたりが言及したら、全然違う視点やアイデアがチラチラ見えてきて、めっちゃ勉強になるのだろうな、などと妄想を。
(感想には個人差があります)
個人的には、一つの言語と各種ライブラリを揃えるパワフルさに、まず素直に脱帽。よくまあここまで作れるなあ…。言語・環境を作れる人達って尊敬します…。
ただ、しかし。コンパイル速度と、ソースの入力のし易さを優先した結果、可読性が悪く、また、他の言語に移行しづらい独特な記述スタイルになって、習得しても潰しが効かない、そんな雰囲気も感じてしまったり。ていうかぶっちゃけ、「そんなにPascalが大好きなら、Pascalそのままじゃダメなのかのう…」などと身も蓋もないことを…。
でもまあ、プログラマーって、えてしてこういう方向に最適化しちゃう人が多いから…。意味のある文字列を打つより謎記号を1文字打って済んだほうが早いだろ、みたいな。Markdownとwiki記法を比較して「Markdownは機能が少ないからダメだ」「wiki記法のほうが文字数が少ない上に機能も豊富だから優れている」みたいな判断を下すノリとでもいうか。それはそれで分かるし、そういう方向性もアリと言えばアリだよなと。
もっとも、自分は…。ソースの可読性が悪くなったらバグが混入する可能性が高くなって、結局デバッグ作業で余計に時間がかかるのだから、打鍵数の少なさを気にしてもアレだし、まともなIDEを使えるなら打鍵数は意外とどうでもよくなるし、自分が最後までそのソースをメンテナンスできるとも限らないから、となると優先すべきは、誰でもざっくり眺めただけで「ハイハイ。なるほど」と理解できる優れた可読性を実現することだろうし、そのためには既存言語への慣れを積極的に利用して奇抜な記述・文法は最小限に、などと思ってしまうのだけど。
とは言えもちろん、色んな言語があったほうが色々なことに気付けるし、多様性があったほうが面白いので、こういう言語が存在することは当然肯定するわけですが。いいぞもっとやれ。みたいな。
プログラミング言語マニアの意見感想を、眺めてみたい気もする…。例えば、屈指の言語マニアであろうRuby作者様あたりが言及したら、全然違う視点やアイデアがチラチラ見えてきて、めっちゃ勉強になるのだろうな、などと妄想を。
(感想には個人差があります)
◎ サンプルソースのウインドウサイズ。 :
言語仕様とは全然関係ない話だけど。チュートリアルのソースや、サンプルソース群で指定されてる、1600x900というウインドウサイズに首を捻ったり。何故、このサイズ…。
この話は長くなりそうなので、別記事でメモ。
この話は長くなりそうなので、別記事でメモ。
[ ツッコむ ]
#2 [prog] サンプルソースのウインドウサイズについて少し考え込んでしまったり
Kuinというプログラミング言語を少し触ってみた際に、チュートリアルのソースや、サンプルソース群で指定されてる、1600x900というウインドウサイズに首を捻ってしまったり。何故、あえて、そのウインドウサイズを選んだのだろう…。
というのも、サンプルの類は、興味を持ってくれた人達に、「コレはこういうことができますよ」と伝える・宣伝するためのソレだから、できるだけ多くの環境で動かせることを意識したほうがいいだろう、であれば、そこで指定するウインドウサイズは、どの環境でも表示できるサイズであることが望ましいのではあるまいか、と自分は思っているからで。
例えば…。ペルソナだか顧客ストーリーだかを提示してみるけど…。
小中学生がお小遣いやお年玉を貯めて、自分専用のノートPCを買ったとする。あるいは、親御さんにお願いしてノートPCを買ってもらうとする。
お小遣いやお年玉で買えるPCとなれば、それほど高額でゴイスなスペックのPCは選べないだろう。だって、他にも買いたいものがたくさんあるはずだし。
あるいは、親御さんが子供に買い与えるとしたら、最初からゴイスなPCは買わないだろう。子供が使うのだからと、比較的安いPCを「とりあえず」で選んでしまうのではないか。
ということで、安いノートPCの画面解像度を眺めてみると…。
_価格.com - ノートパソコン スペック検索・性能比較
1366x768とか、1280x800とか、そんな画面解像度のノートPCがゴロゴロしてる。つまり、そのぐらいの画面解像度のPCを、お子さん達が入手している可能性は否定できない。
さて、そのお子さんが、「えっ？ コレを使うとゲームが作れるの！？」と、めっちゃワクワクしながら、何かしらのプログラミング言語・ツール等をDLしてインストールしたとして。
期待に胸を膨らませながら、サンプルソースを実行してみたら、1600x900でウインドウがバーン。1366x768の画面解像度のノートPC上で、1600x900のウインドウがバーン。
そのお子さんはどう思うだろうか。「クソが！」「画面(ウインドウの中身)が全部見えないじゃん！」と思うわなと。印象最悪ですがな…。どんなに言語やライブラリを作り込んでいたとしても、サンプルのウインドウサイズが1600x900だったというただそれだけで「コイツ使えねー」扱い。トホホ。
であるから、サンプルの類は、あまり大きなウインドウサイズを指定しないほうが良いのだろうなー、と自分は思うわけで。
じゃあ、どの程度のウインドウサイズならいいのか。一般的にこの手のソレは、640x480とか800x600が多いような気がする。 _Windows 10 のシステム要件と仕様 を眺めると、「最低でも800x600のディスプレイを用意してくれよな」と書いてあるし、 _Windows 8 と Windows 8.1 のシステム要件 を眺めると、「1024x768は欲しいッスねー」と書いてあるので、どんなに酷い環境でもWindowsを使ってる以上、640x480や800x600のウインドウサイズなら確実に表示できるはず。
でも…。2Dゲームっぽい何かしらを表示したいとなると、今時、640x480なんてちょっと寂しいよね、悲しいよねえ、Windows95を使ってた時代ならともかくねえ、てな印象が無きにしも非ず。
もうちょっとリッチに行きたいよなあ…。であれば。一昔前のゲーム機の「HD画質」てのは1280x720だったらしいし、TVアニメ制作時の解像度も1280x720だったりするらしいので、せめてその程度はあってもいいんじゃないか。800x600のディスプレイを使ってる人には「ゴメン！」するしかないけれど、いくらなんでも今時そんな環境は少数派だろう。大体は、最安ノートPC群の1366x768や1280x800のディスプレイが最低ラインじゃないかしらん。だったら、1280x720のウインドウが表示できるよなと。たぶんできると思う。できるんじゃないかな。
てなことを考えながら、普段、サンプルスクリプトのウインドウサイズを640x480とか1280x720で指定してる自分からすると、なんでコレ1600x900にしたんだろうなー、と疑問に思ってしまったわけです。
まあ、大きな画面でグリグリ高速に動いたらビックリしてくれるだろう、てなノリかなと想像したりもするのですが。でも、「クソが！」と思われちゃったら元もこうもないよな…。みたいな。さて、どうなんですかね。
いやまあ、そもそも今時の子供さんは「ゲームを作れるの！？」なんてワクワクしないだろ、と根底から否定されそうでもあるけど。「ゲームを作る…？ うへえ、メンドクサ…」としか思わないんじゃないか…。ワクワクするのって、ファミコンで遊んでたおじさんぐらいじゃないの…ってソレを言っちゃあ…。
というのも、サンプルの類は、興味を持ってくれた人達に、「コレはこういうことができますよ」と伝える・宣伝するためのソレだから、できるだけ多くの環境で動かせることを意識したほうがいいだろう、であれば、そこで指定するウインドウサイズは、どの環境でも表示できるサイズであることが望ましいのではあるまいか、と自分は思っているからで。
例えば…。ペルソナだか顧客ストーリーだかを提示してみるけど…。
小中学生がお小遣いやお年玉を貯めて、自分専用のノートPCを買ったとする。あるいは、親御さんにお願いしてノートPCを買ってもらうとする。
お小遣いやお年玉で買えるPCとなれば、それほど高額でゴイスなスペックのPCは選べないだろう。だって、他にも買いたいものがたくさんあるはずだし。
あるいは、親御さんが子供に買い与えるとしたら、最初からゴイスなPCは買わないだろう。子供が使うのだからと、比較的安いPCを「とりあえず」で選んでしまうのではないか。
ということで、安いノートPCの画面解像度を眺めてみると…。
_価格.com - ノートパソコン スペック検索・性能比較
1366x768とか、1280x800とか、そんな画面解像度のノートPCがゴロゴロしてる。つまり、そのぐらいの画面解像度のPCを、お子さん達が入手している可能性は否定できない。
さて、そのお子さんが、「えっ？ コレを使うとゲームが作れるの！？」と、めっちゃワクワクしながら、何かしらのプログラミング言語・ツール等をDLしてインストールしたとして。
期待に胸を膨らませながら、サンプルソースを実行してみたら、1600x900でウインドウがバーン。1366x768の画面解像度のノートPC上で、1600x900のウインドウがバーン。
そのお子さんはどう思うだろうか。「クソが！」「画面(ウインドウの中身)が全部見えないじゃん！」と思うわなと。印象最悪ですがな…。どんなに言語やライブラリを作り込んでいたとしても、サンプルのウインドウサイズが1600x900だったというただそれだけで「コイツ使えねー」扱い。トホホ。
であるから、サンプルの類は、あまり大きなウインドウサイズを指定しないほうが良いのだろうなー、と自分は思うわけで。
じゃあ、どの程度のウインドウサイズならいいのか。一般的にこの手のソレは、640x480とか800x600が多いような気がする。 _Windows 10 のシステム要件と仕様 を眺めると、「最低でも800x600のディスプレイを用意してくれよな」と書いてあるし、 _Windows 8 と Windows 8.1 のシステム要件 を眺めると、「1024x768は欲しいッスねー」と書いてあるので、どんなに酷い環境でもWindowsを使ってる以上、640x480や800x600のウインドウサイズなら確実に表示できるはず。
でも…。2Dゲームっぽい何かしらを表示したいとなると、今時、640x480なんてちょっと寂しいよね、悲しいよねえ、Windows95を使ってた時代ならともかくねえ、てな印象が無きにしも非ず。
もうちょっとリッチに行きたいよなあ…。であれば。一昔前のゲーム機の「HD画質」てのは1280x720だったらしいし、TVアニメ制作時の解像度も1280x720だったりするらしいので、せめてその程度はあってもいいんじゃないか。800x600のディスプレイを使ってる人には「ゴメン！」するしかないけれど、いくらなんでも今時そんな環境は少数派だろう。大体は、最安ノートPC群の1366x768や1280x800のディスプレイが最低ラインじゃないかしらん。だったら、1280x720のウインドウが表示できるよなと。たぶんできると思う。できるんじゃないかな。
てなことを考えながら、普段、サンプルスクリプトのウインドウサイズを640x480とか1280x720で指定してる自分からすると、なんでコレ1600x900にしたんだろうなー、と疑問に思ってしまったわけです。
まあ、大きな画面でグリグリ高速に動いたらビックリしてくれるだろう、てなノリかなと想像したりもするのですが。でも、「クソが！」と思われちゃったら元もこうもないよな…。みたいな。さて、どうなんですかね。
いやまあ、そもそも今時の子供さんは「ゲームを作れるの！？」なんてワクワクしないだろ、と根底から否定されそうでもあるけど。「ゲームを作る…？ うへえ、メンドクサ…」としか思わないんじゃないか…。ワクワクするのって、ファミコンで遊んでたおじさんぐらいじゃないの…ってソレを言っちゃあ…。
◎ サイズが変えられるのがベストではあるのだろうな。 :
そういえば、cocos2dを触っていて感心した点があるのだけど。
_特定のショートカットキーを押す
と、フルスクリーン表示とウインドウ表示を切り替えられたり、FPS表示のON/OFFができるあたりが便利だなと。640x480の小さいウインドウで表示されても、ショートカットキーを押すだけで全画面表示される。迫力満点。大体にして、そのあたりの機能はえてして必ず欲しくなるものだし、最初から機能として実装済みのほうがいいよな、毎回個別に実装するのもアレだよなとも思えるわけで。cocos2dって、そういうところは賢い。
あるいは、昔のTVゲームのエミュレータ関係を試用してみると、ウインドウサイズを自由に変更できるものがたまにあったりして感心したり。ウインドウ内のドット絵がボケたりジャギったりするデメリットはあるものの、画質よりゲーム画面の大きさを優先したい人は、ウインドウ枠をドラッグするだけで目的が果たせる。こりゃ便利。
考えてみれば、ウインドウサイズ変更、ウインドウ表示とフルスクリーン表示の切り替え、てなあたりは、PC上で動かしてるからこそ得られるメリットなのだよな…。家庭用ゲーム機で、そういうことはフツーできないわけで。
例えばWebブラウザなどは、Ctrl+ + や Ctrl + - を叩くとページが拡大したり縮小したりするけれど。そういう機能を盛り込んでみた2Dゲーム制作ライブラリ、なんてのも実はアリだったりするのかもしれないな、てな妄想を。
そして、そういう機能があれば、サンプルソース内のウインドウサイズの指定なんて、結構どうでもいい話になるはずで…。ウインドウサイズを変更できない作りが前提になってるから、デフォルトサイズってかなり大事ですやん、という話になっちゃうけれど、ユーザがいつでも好きなように変更できるなら、デフォルトサイズはなんでもいいよね、ということに…。
などと書いているうちにふと気づいたけど。Kuinのウインドウって、枠をドラッグしてサイズを変更すると、中に描画されたアレコレもサイズ変更されるのだな…。ああ、なるほど。それで最初から件のサイズが指定してあるのか。見えなかったら枠をドラッグして小さくすりゃええやん、と。そういうことか…。
となると残る問題は、ユーザがその機能の存在に気づくかどうか…。自分は、「いやー言われなきゃ気付かないんじゃないか？」とネガティブな想像をしちゃうけど、作者さん的には「何言ってんだよ気づくに決まってるだろ。だからこれで問題無し」と思っているからこのサイズ、なのだろう…。
まあ、例えばフルHDのディスプレイを使ってる環境等では迫力が感じられるサイズなので、「迫力があるほうが訴求力もある。だからこのサイズがグッド」てな判断もアリなのかもしれず。
しかし、迫力があるほうがいいなら、最初からフルスクリーン表示のほうが更に良かったりしないか。と思ったけど、その場合は終了のさせ方が分からなくて「クソが！」と思われちゃうか…。なかなか難しい。
てな感じで、サンプル類のウインドウサイズ決定って、考え込んでしまうと意外とどこまでも悩むことができちゃうので、「あーもうめんどくせーからVGA(640x480)で」「こんなところでグダグダ悩んでる暇あったらガンガンソース書いてサンプルの本数増やしたほうがいいわ」てのもアリだよなと思えてきちゃったりなんかしちゃったりなんかして(広川太一郎風に)。
このへん、典型的な _自転車置き場の議論 ですわ。たぶん。
あるいは、昔のTVゲームのエミュレータ関係を試用してみると、ウインドウサイズを自由に変更できるものがたまにあったりして感心したり。ウインドウ内のドット絵がボケたりジャギったりするデメリットはあるものの、画質よりゲーム画面の大きさを優先したい人は、ウインドウ枠をドラッグするだけで目的が果たせる。こりゃ便利。
考えてみれば、ウインドウサイズ変更、ウインドウ表示とフルスクリーン表示の切り替え、てなあたりは、PC上で動かしてるからこそ得られるメリットなのだよな…。家庭用ゲーム機で、そういうことはフツーできないわけで。
例えばWebブラウザなどは、Ctrl+ + や Ctrl + - を叩くとページが拡大したり縮小したりするけれど。そういう機能を盛り込んでみた2Dゲーム制作ライブラリ、なんてのも実はアリだったりするのかもしれないな、てな妄想を。
そして、そういう機能があれば、サンプルソース内のウインドウサイズの指定なんて、結構どうでもいい話になるはずで…。ウインドウサイズを変更できない作りが前提になってるから、デフォルトサイズってかなり大事ですやん、という話になっちゃうけれど、ユーザがいつでも好きなように変更できるなら、デフォルトサイズはなんでもいいよね、ということに…。
などと書いているうちにふと気づいたけど。Kuinのウインドウって、枠をドラッグしてサイズを変更すると、中に描画されたアレコレもサイズ変更されるのだな…。ああ、なるほど。それで最初から件のサイズが指定してあるのか。見えなかったら枠をドラッグして小さくすりゃええやん、と。そういうことか…。
となると残る問題は、ユーザがその機能の存在に気づくかどうか…。自分は、「いやー言われなきゃ気付かないんじゃないか？」とネガティブな想像をしちゃうけど、作者さん的には「何言ってんだよ気づくに決まってるだろ。だからこれで問題無し」と思っているからこのサイズ、なのだろう…。
まあ、例えばフルHDのディスプレイを使ってる環境等では迫力が感じられるサイズなので、「迫力があるほうが訴求力もある。だからこのサイズがグッド」てな判断もアリなのかもしれず。
しかし、迫力があるほうがいいなら、最初からフルスクリーン表示のほうが更に良かったりしないか。と思ったけど、その場合は終了のさせ方が分からなくて「クソが！」と思われちゃうか…。なかなか難しい。
てな感じで、サンプル類のウインドウサイズ決定って、考え込んでしまうと意外とどこまでも悩むことができちゃうので、「あーもうめんどくせーからVGA(640x480)で」「こんなところでグダグダ悩んでる暇あったらガンガンソース書いてサンプルの本数増やしたほうがいいわ」てのもアリだよなと思えてきちゃったりなんかしちゃったりなんかして(広川太一郎風に)。
このへん、典型的な _自転車置き場の議論 ですわ。たぶん。
[ ツッコむ ]
以上、1 日分です。