[Top Page][Edit][Article][Edit History][All Pages][Recent Changes][->Japanese]

Note:HSPvsHOGE

企画趣旨

  • 新しい企画を始めてみた。うまくいけば、HSPの本質が見えてくるかも。くに
    • 言語毎のサンプルコードも必要ですね。
    • Hello,World!のソースくらいで大丈夫かな? そのくらいなら何とかなるかも。 むしろ、知っている方がいたら、書き込んでほしい。くに
    • いやむしろ、「Hello,World!」を比較して何の意味があるのかと思うのですが、 例えば何かのアルゴリズムの実装とかのほうが良いのでは? Shark++
    • http://shootout.alioth.debian.org/ のどれかをHSPで書けばいいのでは。対抗言語のコードもあるようですし。
    • 確かに、Hello,World!を比較しても意味ないですね。ほとんどの言語で、 大差ないですね。ベンチマークの意味合いで、http://shootout.alioth.debian.org/ の Ackermann を作ろうとしたんですけど、僕の実力では、ちょっと無理っぽいです。 作ってみましたが、動かないです。 HSPベンチマーク にソースを置いておきます。くに
    • HSPに再帰は鬼門です。ループに展開しないと。とコードも読まずに応答するテスト。

正規表現

  • よく考えてみると、正規表現を標準搭載していないHSPにとっては、文字列処理に 関しては、PerlやRubyなどに対して不利なように思う。くに
    • 専用のDLLもあるんだし、わざわざ実装する必要はないのでは? 実装するとランタイムが膨れ上がる気がしますが Shark++
    • 多少、ランタイムを大きくしても、言語そのものに、正規表現を組み込めば、 正規表現を前提にプログラムをかけて、便利なように思います。 別に、ランタイムにしなくても、Shark++さんの言うDLLを標準で 組み込めば、問題ないと思います。くに
    • 知らなかったんですがCOMにも正規表現が実装されているのですね Shark++
    • そうですね。そのうち、普通に、HSPで正規表現を使う日が来るかもしれません。くに

比較スクリプト

  • スネークゲームでの比較がいいように思います。言語によって3行でいけるなど比較に適しているのでは?Charlotte
    • くにさんスネーク得意そうだしw
    • いえいえ、得意ではありませんよ。くに
  • 何を比較すれば、いいのか分からなくなってきました。何か、ないでしょうか? くに
    • Rogue系RPGでも書いてみたら?あのシステム、結構勉強になりそう...。(ASCIIテキストのみのシンプルなゲームなのでPerlなどのテキスト処理系スクリプト言語でも十分記述可能だと思います)
    • それこそアルゴリズムもへったくれもないような。議論する意義がありそうなのはダンジョンの自動生成くらいじゃないでしょうか。
    • もっと、単純なもので、分かりやすく比較できればいいのですが、 なかなか難しいですね。くに
    • 個人的には「Hello,World!」はスクリプトの見た目の雰囲気の違いが感じられればいい、程度に受け止めてます。初心者だった頃を思い出すと、見た目のとっつきやすさは気にしてしましたので。
       ここではHSPに有利な面も不利な面も両方見たい気がします。そうなると1つのプログラムだけで比較しようとすると、長く複雑化し、また見るほうにも分かりにくくなってしまうんじゃないでしょうか?[謎の覆面ライター]
    • 各言語で毛色がそれぞれあって、「全ての言語でHello World」みたいに全部を同じ基準で比較しようとすると、その言語の特徴が出なかったり、何を比較しているか分からなくなったりするので、一対一で似ている所・違う所を比較するだけでも良いんじゃないかと思います。あと、こういった物は一気に広げると(経験的に)無理がでるので、知ってる範囲でひとつづつ増やしてくのがいいです。(HSPだから/HSPなのに から移動、加筆修正。)

言語としてのHSP

  • 上の文と関係あるかどうか分からないですが、これからのHSPって、 どんな言語になるんでしょうか? 関数と命令が共存しているので、 予想が付かないです。やはり、関数を好む人と、命令を好む人で、 異なる書き方をし、2つの流派に分かれるのでしょうか? くに
    • 関数には関数の使い方があるので、住み分けられるんじゃないかなぁ。関数的記述をする言語でも、命令的にしか動作しない(値を返さない)ものもありますから。
      関数になった命令とそうでない命令を見比べれば、何をどちらで実装すべきか見えてくるはず。
    • 僕は、関数で統一して、命令は、マクロにしたほうがいいように思うのですが、 かってでしょうか? くに
    • 値を返さない関数は、結局命令と同じにしか働きません。その場合、記述方式を統一するのも一つですし、わざわざ区別して違いを意識させるのも一つです。HSPの場合は単に後者を選択しただけだと思います。それでも関数で統一したいと思うとしたら、その理由は何でしょうか。参考にさせてください。
      (以降、ややこしいので読み飛ばしてもらってもかまいません。実は↑↑の文章で嘘を書いてます。話を分かりやすくするため「命令=値を返さない」としましたが、必ず「命令が値を返さない」というわけではありません。なので、「値を返す/返さない」が関数/命令の区別とはなりません。何が違うかというと「状態を変えないもの/変えるもの」の違いです。状態を変えないもの=関数は、値を取得するくらいにしか使えません。なので、わざわざシステム変数を経由するより、直接値が返せると便利です。一方、命令は何かを変える事が目的なので、必ず値を返す必要はないし、返してもそれがいつも必要だとは限りません。なのに「aaa = method(bbb)」と書くと、aaaを取得するためにmethodを実行してる風にも見えます。だから、わざわざ取得できなくする事で、値の取得が目的じゃないことをはっきりさせてます。また、状態(主に引数)が変わるか変わらないかの区別も簡単になります。これが関数と命令が両方あるメリットです。HSPの設計者ではないですが、HSP3をみると、私にはそう意図してるように見えます。)
    • HSPでは、関数=状態を変更せず、値だけを返すもの。命令=状態を変更して、値を返さないもの。というような、位置づけになるということでしょうか?(おにたまさんが 実際そう思っているかどうかは、分かりませんが。)確かに、目的によって、 書法が違えば、分かりやすいかもしれません。
      それで、僕が、なぜ関数にこだわるかというと、HSPの記述が僕には、アセンブラのように、見えてしまうので、関数を取り入れたほうがより簡単に、プログラムを書けるのではないかと思っているからです。(すごく個人的な話で、すいません。) つまり、アセンブラ->構造化された言語のように、命令だけのHSP->関数も使えるHSPとなったほうが、よりいいと考えていますし、命令よりも関数の方を推奨したほうが、 他の言語への以降に際しても、分かりやすいかと思います。(やはり、個人的な意見に なってます。すいません。) くに
    • HSPの文法は確かにアセンブラにも似てますよね。(2.xまでの命令のみの文法やコメントの";"なんか特に)関数の場合は値を他の命令や関数の引数としてとる可能性が高い機能に関してのみで基本スタイルは命令でいいと思います。そもそも、値を返さない機能に対して関数にする意味が分かりません。Cのvoid関数はすべてを関数で記述するという(サブルーチンに相当するものがない)Cの規約上の理由から敢えて実装されているのだと思います。なので本来、値を返さないのなら関数ではなく命令であるべきです。値を返す場合においては「命令実行->システム変数から値を取得」とするよりも「関数で値を取得」の方が楽ですので関数化には基本的に賛成です。
      • 僕が、すべてを関数で記述するほうがいいと思うのは、そのほうが一貫していて、 覚えやすいからでしょうか。このあたりのことは、個人の好みも入りますから、 一概に何が正しいとは言えないので、難しいです。関数と命令で、書法を変えるのも、 すべて関数、または、命令で記述するのも、個人の好みの問題でしょうか。 くに
      • HSPはBASICがモデルです。そのBASICは戻り値が必要な機能のみを関数で用意し戻り値が不要なのはすべて命令で実装しています。明らかに命令の方が概念的には分かりやすく扱いもしやすいですが不便なことがあります。関数は便はいいですが分かりにくくて扱いづらいです。(HSPの関数は戻り値必須のため戻り値を返す必要がない機能まで関数化すると戻り値を受け取るための変数が必要になってしまうなど)この辺を考慮しながら組んでいくしかないと思います。そういう意味でPerlのように命令としても関数としても記述できる言語はすごいですね。統一としちゃうとifなどまで関数化しちゃうことになりかねないですよ。用途にあった機能を選択していくしかないでしょう。すごく妥当で最も論理的だと思うんですけどね。(Cのように何でも関数化というのもちょっと疑問に思っています)
      • 「関数」と言う日本語の呼び方が問題なのであって、実体はパラメータ&戻り値つきサブルーチンですよね。
        functionという単語は「関数」と言う意味もあるにはありますが、最も主要な意味は「機能」です。
        関数と命令を別物だと思うから難しいのであって、関数も命令も同じものだと悟れば何の問題も無いのではないでしょうか?
        同じ物に対する二通りの記述を許可する事による混乱を重視するか利便性を重視するか、Perlは一貫して利便性を重視するポリシーですね。
      • 上の主張のレスとしてはちょっとずれますが、コンピュータ用語としては、機能=featureで、関数=functionとなると思います。少なくとも、HSP組み込みのものでは、関数と命令は明確に分かれてますね。その辺りも含めてガイドラインを明確に・・・的な事をみんなでやりたいと考えてるので、Wikiページが出来た際にはご意見お願いします。(さらに考えると、上の方の丸括弧内に書いた事もちょっとずれてたので、個人的にはその辺りの整理も。)
      • featureは「特徴」では?あまりfeature=機能と言うのは聞いたことがありませんが。
      • 確かにfeatureを訳すとすると「特徴」を選ぶかも。。。自分の中では、コンピュータ用語の機能=特徴的機能=featureってなってるのかな?

雑談

  • あかん…レス多すぎてわけくちゃわからんようなってきた(^ ^;[謎の覆面ライター]