日本語プログラミング言語「ひまわり」 207
ストーリー by Oliver
動け、動け、思い通りに動けぇぇぇぇ 部門より
動け、動け、思い通りに動けぇぇぇぇ 部門より
Anonymous Coward曰く、"MYCOM PC Webに日本語プログラミング言語「ひまわり」の紹介記事が載っている。日本語によるプログラミング環境の実現は、古くからもMINDとか日本語版LOGOとかいった形で地道にしぶとく受け継がれてきたジャンルであるが、いずれもベンダーとユーザー双方から支持がえられなかったせいもあってか、普及には至らなかった。こうしたかたちでまたこのジャンルに果敢にも挑戦してきた言語が現われたことを、率直に面白いと思いたいところだ。"
関連行事 (スコア:2, 参考になる)
Lisp でマクロ組むなどの飛び道具は禁止ですかね :-)
昔は (スコア:2, 参考になる)
Re:昔は (スコア:1)
AppleScriptが日本語で書けたのかな?
あれ?
妖精哲学の三信
「だらしねぇ」という戒めの心、「歪みねぇ」という賛美の心、「仕方ない」という許容の心
小学生向け (スコア:2, 興味深い)
トをしていました。 その中で、私の雇主(つまり教室長やな)や子供たちの保護者から、
「プログラムを教えることはできないか?」
というお話がありました。 で、一応、教室でVB4.0(なぜかEnterorise版)を買って見たのです
が、さすがに小学生にはちょっとキビシイ。 なんかないかな~と探し当てたのがロゴ坊 [logob.com](LOGOの日本語版?)でした。
子供からすると、「プログラムを書いて、そのとおりに動く!」
というのが新鮮だったようです。 ひまわりに関しても、そう言った方面で、子供向けの入門のその
また入門という辺りで活用できるのではないでしょうか?
Re:小学生向け (スコア:1)
プログラムを子供に教えたいとき、別に プログラム言語にこだわる必要は無いと思います。
自分の意図したロジックの通りに動くことをわからせることが 目的なのだから、LEGOのマインドストームみたいな、 ブロックを組み合わせて動かす奴の方が入門としては 向いてるんじゃないですかね。
マインドストームなら小学生でもプログラムできてる わけですし、日本語だから入門とは限らないのでは。
#その後、不満が出てきたらNQCを教え、さらにCからC++もしくは Javaに進む・・・とか。Re:小学生向け (スコア:1)
同じく小学生にいいのでは思いましたね。
プログラミングを教える前に、まず英単語を教えなければならないんですよね。
「やってみたい!」って好奇心がある子どもに、「まず英語を…」とか、出鼻挫きたくないですし。
かといってそこで中途半端に英単語教えてしまうと言うのも怖いです。
(できれば一般教育はちゃんと学校で学友と一緒に学んで欲しいですし)
「正しいロジックを書けば正しく動く、間違って書けば動かない」
基本部分を理解して貰うのに、教えやすいのではないでしょうか。
私の世代だと初等英語教育は中学校入ってからだったのですけど。
今はどうなのかな?
そろそろ自分の子どもとかの教育を考えないとなぁ・・・(怖
代入を明確にしたいのであれば (スコア:2, すばらしい洞察)
10 REM cにa+bの結果を入れる
20 LET c = a + b
30 REM aにcの値を入れる
40 LET a = c
とやればだいぶんましと思う
#自分でやるのは冗長でいやだが
絶対誰もが考えそうなネタ (スコア:2, おもしろおかしい)
・縦読みをコーディングにしのばせる
・これでWebサーバーを作ってみる
・ひまわりで動くWikiエンジンを作ってみる
・気象衛星を作ってみる(名前が一緒なだけだろ!)
・C/C++、Java等の他言語にコンバートするプログラムを作ってみる
・もしくはその逆
本当に使い物になるのか? (スコア:2)
私の場合は,Smalltalkはなんとか.MindとAppleScriptで懲りたのだけど,自然言語の複雑な文法の一部をプログラミング言語にしたところで初心者が少しだけ慣れやすい以上の効果はなくて,別の言い換えもできたり,できなかったりしてしまうためにかえって,よくわからなくなってしまう面があります,また,最後はやはり問題となる計算やデータ構造の方を意識しないといけなくなります.そうなると視覚的な見やすさを気にしていない自然言語風では,記述がものすごく冗長になってしまったりして,実に不利になってしまうわけです.
たとえば,Lispなんて自然言語のどれにも似てないのにとても使いやすい(ある種の人とある種のドメインでは(?))ところを見ると,自然言語のどれかに似ているとか似てないとかいうことは,プロが使う意味での使いやすさとは結びつかないのではないでしょうか.
現われた? (スコア:1, 参考になる)
2001年からある言語環境なので誤解を招く表現かなと思います。 (窓の杜の初紹介記事 [impress.co.jp])
取り上げること自体に意味がないと言うつもりはありませんが。
# MIND、LOGOに比べれば新顔? ごもっとも……。
IPAの未踏ユース (スコア:1, 参考になる)
ネーミングセンスがなんとも (スコア:1)
逆にしょぼい感があります。もっと日本語らしいイキなネーミングだと良かったかなと、私はカタチから入るクチなんでネーミングが格好いいのを使いたい(多少使いづらくても)と思います。
あと何か気持ち悪い感があるなーと思っていたら
これを思い出しました。--->http://home.m04.itscom.net/himawari/index-w.html
その趣味は無いのでID
スタック言語 (スコア:1)
#今夏風邪ひいたお馬鹿さん状態なので、適当な例が思いつかん…
Re:スタック言語 (スコア:2, 興味深い)
いわゆる卜書きってやつなんですが、
シナリオ、戯曲の台詞以外の状況説明ですね。あれなんかわりと
プログラミング言語化しやすいんじゃないかと思ったことがあったなあ。
最初の登場人物説明がいわゆる「宣言」
舞台説明とかはほとんど定型文書な体だし(かえって変な文体で書かれるとわかりにくいんだ)
男1、上手から登場
みたいな書き方って、「男1」をオブジェクトに見立てればいい感じにオブジェクト指向してませんかね?
問題は分岐とか条件つきループ、あと変数なんかの扱いなんだけど、
以下、女1が怒り狂うまでつづける
とか
みそしるがまずかったらちゃぶ台をひっくり返す
とか、要はオブジェクトのとらえ方だと思うんだけど。
誰かやってくんねえもんかと思いつつ、
俺はこういうのはもう懲りたんで(笑)
Re:スタック言語 (スコア:1)
日本語には、もう、戻れません。 (スコア:1)
足す数=1
100回(
答え=答え+足す数
足す数=足す数+1
)
答えと、言う。
。。。だめだ。よけい分かりにくい。
sum とか i にしてくれないとw
もう戻れない体になってしまったんだなーとつくづく(^^;
んでも、
「1から100までの加算の結果と、言う」
はできへんのかいな?
Re:日本語には、もう、戻れません。 (スコア:1)
>足す数=1
>sum とか i にしてくれないとw
変数なんて「い」とか「ろ」とかでいいのに.
日本語プログラミング言語「名」 (スコア:1)
「織田信長の意味論」
「織田信長の優先度」
「織田信長の実行モデル」
「織田信長の実装方針」
・・・いかん、なんか頭に変なイメージが・・・
プログラミング言語としての表現力 (スコア:1)
如何に簡潔に記述できるか。
制御構造なりデータ構造なり、今までに無いシンプルで理解しやすい
強力な構文が利用できるならベースとなる言語は英語だろうが日本語だろうが
問題にはならないだろう。
その目的に日本語の特質が利用できれば素晴らしい。
その点で現在の「ひまわり」は僕には魅力的には思えない。
(作ってる人は楽しんでるんだろうな)
Re:プログラミング言語としての表現力 (スコア:1)
また、そういう特殊な言語を習得するのが楽しくて
やってるんだと言うだけだと思う。
なんか、クリンゴン語がどーのとか、エルフ語が
どーのとか、それをISO割り当てしました、
論文書いてみましたとか、そういうのと本質的には
変わらないでしょう。
Re:プログラミング言語としての表現力 (スコア:1)
例えば、ポインタがウザいから全部参照にしちゃおうとか、 型の扱いはどうしようとか、細かく見ると機能の一つですが、 巨視的に見ると、プログラミング言語っていうのはその時代のプログラミング文化みたいなのを反映してるもんだと思います。
だから、「COBOL みたいな Java を書く」って表現が通じるわけで。
Java に interface 構文がありますが、これがあるとないとで、OO的なコードの見栄えがかなり変わってくると思います。 こういうのをすっきりと書けるってのは表現力でしょう。例外処理とか、構文がないと、ぐちゃぐちゃになりそう。
# Delphi の with 構文とか、Perl の foreach とか syntactic sugar は便利で楽しい。
# Java の哲学なら with が必要なら継承しろ、ってことなんだろうけど。
Re:日本語ベースの開発言語の需要? (スコア:1)
既存の言語っぽいモノを直訳したようなモノって、結局「読んで内容は理解できるけど、実際に書くのはすごく面倒」てなコトになりやすいかと。
実際この「ひまわり」にしても妙な「日本語っぽい別の何か」で記述されているような感じですし。
むしろ、VBとか各種スクリプト言語やマクロ言語などを受け取って日本語表記にして、極力手入力なしでいじれるようにし、いじった内容を元の言語に再翻訳して差し戻す、みたいな、別レイヤー的な機能のモノの方が良いのかもしれませんね。
#てか、既にどこかにありそうですな。
#ん? ひまわりってのが、そういうモノなの? 違うよなぁ?
-+- 想像力を超え「創造力」をも凌駕する、それが『妄想力』!! -+-
Re:日本語ベースの開発言語の需要? (スコア:1)
昔々、桐の一括処理を書いてたのですが、それなりに
入力支援環境があったのでなんとかなりました。
ひまわりも支援のない素朴なエディタで入力するのは
厳しいでしょうね。
桐の一括処理の場合、英語表記の別名があったので、
日本語表記のみというわけではありませんでしたが。
Re:日本語ベースの開発言語の需要? (スコア:1, 参考になる)
(コーディングルールも無いまま○年使われてるプログラムに
消費税の内税対応ロジックを追加する改造、
1モジュールだけ関数が日本語だった)
関数入力の時に日本語モードに切り替えながら
プログラミングしましたが、
はっきり言って非常に面倒で非効率的だと感じました。
Re:日本語ベースの開発言語の需要? (スコア:1, すばらしい洞察)
皆さん、プログラム自体に用いる単語レベルで「英語だから...」っていう敷居の高さを感じるんでしょうか?プログラム自体が日本語だろうと英語だろうと、そこに出てくる用語や概念の正確な意味や使い方の敷居には関係ないですし、例えば用語が全て日本語になったからって何かが改善されるとは思えないんですけど。例えば、オブジェクト指向なんてサッパリ知らない俺に(ご丁寧に日本語で)「継承」とか言われても、「それが何を意味するのかわからない」という点で、日本語でも英語でも全く変わらないっつーか...
#日本語プログラムになると、プログラムを書く際に、EUC派とか、SJIS派とか、いやこれからは先を見据えてUTF派とか、何言ってんだ昔はJISでないと色々大変で派とか、無駄な勢力争いが生まれそうな... ;-)
Re:日本語ベースの開発言語の需要? (スコア:2, すばらしい洞察)
二つの壁のうちのひとつが取り除けるならば、読みもしないドキュメントのような何かを
作成する作業を省けるので、日本語プログラムもよいかもしれません。
Re:日本語ベースの開発言語の需要? (スコア:1)
> 作成する作業を省けるので、日本語プログラムもよいかもしれません。
考えたこともなかった! 画期的なアイディアかも!
# 個人的には Emacs にひまわり-mode ができたら考えるかもよん
Re:日本語ベースの開発言語の需要? (スコア:1, 興味深い)
ローマ字入力だと、圧倒的に鍵打数が多く、かつ文字変換という作業が入ってしまいます。
対応環境があればそこそこ楽になるのでしょうが、やはり
ライン数/日 が大幅に低下することは、実務では見逃せません。
これは、入門用言語以上にはなれないのでは。
Re:日本語ベースの開発言語の需要? (スコア:1)
そこでT-CODE [openlab.jp]ですよ。
Re:日本語ベースの開発言語の需要? (スコア:1)
「タイプしてる時間>=考えてる時間」な達人だと話は別でしょうけれど…
それに、実務の上でも日本語が使える部分に日本語が使ってあると可読性も上がってよいように思います。ローマ字表記された読むに読めない識別子名とか、誤用している英語の識別子名を使われるよりは日本語の識別子が使ってあるほうが可読性は明らかに上です。(混在してると気持ち悪いとかの問題もありますが…)
RDBのテーブルやフィールドの名称に日本語が使われるのとかは、見やすいですよね??
Re:日本語ベースの開発言語の需要? (スコア:1)
「果敢にも挑戦」と言いますが、それは過去の失敗例から
何かを学んだ上で再び挑戦する場合であって、
ひまわりはこの問題を克服できるような新しい何かを持っているのでしょうか。
過去に学ばない挑戦は、果敢ではなく無謀と言います。
Re:日本語ベースの開発言語の需要? (スコア:1)
int 会計年度算出(int 年, int 月, int 日)
Re:日本語ベースの開発言語の需要? (スコア:1)
とりあえず「求める」は曖昧だから命名法としては良くないですよ~。
もしかして戻り値が求めた結果として返されるのかなと推測はするけど、それならもっと明確に「返す」と書かないと。
私は…… getFoo やら setFoo やらに毒されているのでダメです。
Re:日本語ベースの開発言語の需要? (スコア:1)
日本語で入力することでかえって、一昔前のテキストアドベンチャーで感じた苛立ちを作業中感じることになるのではないでしょうか?
「これ日本語的にはOKなのに受け付けないじゃん!」なんていう初心者は多いと思います。
人工知能でも搭載したらいいのかも?
それよりはブロックを組むようにGUIを徹底させた作りの方が理解しやすいような気がします。
Re:日本語ベースの開発言語の需要? (スコア:1)
みんなの役に立つかどうかとかを考えなくてもいいんじゃないでしょうか。
どこかの兄さんが言ってませんでしたっけ? Just for fun って。
まあ、普及する方がしないより(たぶん)いいんでしょうが。
ところで、リンク先からも飛べますが、似たようなものに
http://hp.vector.co.jp/authors/VA021321/
なんていうのもありますね。
Re:英語が嫌いなプログラマ (スコア:2, すばらしい洞察)
それはプログラマ失格というのでは?
そういう方達は、英文マニュアルの日本語プログラミング言語もまっぴらごめんなのではないでしょうか。
あまり肯定な意見がないのは、英語のプログラミング言語を使う英語圏の人達が、結局英語でコメントを追加しないと後でわけ分からなくなるのと同じように、ひまわりも本質的にそれが変わらないからではないかなーと、個人的には思うのでありました。
Re:英語が嫌いなプログラマ (スコア:1)
英文マニュアルは大好きだけど、書くコードがボロボロ、というのに比べればずっとまし(笑)。
Re:英語が嫌いなプログラマ (スコア:1)
あはははw そりゃそうだw
んでも、やっぱ新技術に無関心でないなら英語は外せなくて、苦手でも取り組む人ならスキルもやっぱ上。
と思うので、「英文マニュアルを読まなくていいプロジェクトに投入」される人材って。。。と思ってしまう。(^^;
Re:英語が嫌いなプログラマ (スコア:1)
下手な日本語で書かれているとプログラム言語の字面と合わないので結局「日→英」脳内翻訳 (泣
簡潔で明瞭なサンプルコード付きなら英語がいいな。
Re:日本語ベーシックを思い出すな (スコア:1)
歳を取った証拠なんでしょうかねー...orz
しかしよく言われることですが、ぴゅう太って
日本初の16ビットPCだったんだそうですね。
そういうことを感じさせない素敵なコンピュータでした。
#ファミリーベーシックは日本語じゃなかったよね...記憶あやふや
And now for something completely different...
Re:日本語ベーシックを思い出すな (スコア:1)
日本初は『三菱電機MULTI 16』 [dion.ne.jp]です。
オフトピついでですけど、当時あるライターさんが色んなマイコンで演算ベンチマークを実行したら、ぴゅう太がダントツに速くて「さすが16bit」と言う事で納得したそうです。
(と言う話を工学社の編集部で聞いた)
いまだにあれのマシン語が使えるようになっていなかったのが悔やまれます。
李 露星
Re:日本語ベーシックを思い出すな (スコア:1)
Re:欲しい関数 (スコア:2, 興味深い)
欲しい関数といえば (スコア:2, おもしろおかしい)
お約束 (スコア:1, おもしろおかしい)
Re:ひいたけ (スコア:1)
「よまわり」
Re:ひいたけ (スコア:1)
「こまわり」
Re:ひいたけ (スコア:1)
親が片方、江戸っ子です。
子供の私は「敷く、引く」など言い(聞き)分ける事は出来るものの、とっさの時に「この場合どっちを使うんだっけ?」一瞬脳内辞書を引くという遠回りをする事がたまにあります。
# 「7」は「ひち」、「disney」は「デズニー」と思っていた(<片方、江戸っ子と関係無い)
Re: スクラッチ (スコア:1)
模型部な人には、"scratch built"という思い入れのある表現がありますから、訳したくないでしょうね。改造や、大規模な流用がないんだ、と言いたい時とか。
Re:もう10年以上昔の話だと思いますが (スコア:1)
MINDコンパイラをMINDで実装できる程度には実用的。と。
まぁ、一般的に認知されてるかというと答えはNOだと思うけれども。。
どちらかというと、実際のコーディングとプログラムの構成を分離(eUMLとか)して、自然言語的なアプローチはコンバータを使うのが個人的には正解な気がする。
# c2txt2c [personal.sip.fi]なんてのも有るし(ぉ
もちろん、多様なプログラム表現手法を手にするのはいいことだと思うし、ひまわりの有用性もある程度は認めるんだけども。