アカウント名:
パスワード:
組込みをやっている人って、自分のやっている範囲こそが「組込み」だと信じる傾向があるような気がする。 (車載をやっている人は、車載特有の話を組込みの本質だと思ってたりするし、携帯ばっかりやっているも同様) 実際には、「組込み」の範囲はずっと広くて、リアルタイム性なんか全然いらないような分野もありますよ。 リアルタイム性を要求される部分はCやアセンブラにまかせて、それ以外の部分をrubyという分担をしてもいいわけだし、斜め上というほど悪い筋じゃないと思います。
幸か不幸か、色々なプロジェクトに飛ばされたり火消をさせれたりで、特定の分野だけではなく、そういう組込みもやった経験も踏まえた上で言っているのですけど。 大抵の組込みシステムは、仮にリアルタイム性が不要な分野であっても、パソコンとかに比べてプアなハードやソフトのリソースの上で動かないといけません。当然OSの機能だってWindowsのようにリッチでない場合も多く、対象ハードウェアへの理解や操作などが要求されるのです。アップデートだってパソコンみたいにお気軽に行えるものではありませんから、パソコン用途は違った意味での信頼性も必要です。Rubyのようなものに、これらが担保できるのか甚だ疑問です。
BASICが乗っていたものも結構ありましたしターゲットはありそうだと思います。
＞特定の分野だけではなく、そういう組込みもやった経験も踏まえた上で言っているのですけど。
最近のゲーム機とか携帯電話の経験は無さそうですね。中でLLが走ってるのなんか普通になってきてますけど。
まさに
＞＞自分のやっている範囲こそが「組込み」だと信じる
典型例。
それはさておき、東海道新幹線のATSのトラブルが「組み込みにRubyのようなもの」を使ったのが原因だというソースってどっかにありましたっけ？
>最近のゲーム機とか携帯電話それらは「最新のゲーム機」とか「携帯電話」とかいう分野で組み込みではないよーな気もします。まあ、どこまでを組み込みというのかという線引きの話
傍から見ていて思ったけど，
>> 最近のゲーム機とか携帯電話の経験は無さそうですね。中でLLが走ってるのなんか普通になってきてますけど。
というケースは，組み込みという領域の中でのごく一部のケースにしか見えないんだけど．で，そういう領域を前提にするなら「組み込みプラットフォーム」と言わずに「ゲーム機プラットフォーム」とか「スマートフォン用プラットフォーム」とか言うべき．組み込み一般という前提で議論すべき状況で，一部の特殊な例を挙げて「だからおｋ」みたいなこと言うのも
と同じレベルの思考じゃないの？で，やっぱり何の限定も無く「組み込み」と言われれば
Rubyのようなものに、これらが担保できるのか甚だ疑問です。
という意見に賛成せざるを得ないと思うけどね，俺は．
俺も傍から見ていて思った事なんだけど、
>>> 自分のやっている範囲こそが「組込み」だと信じるのこれとそれとは、同じレベルの思考に思えるね。
でもそれは、>>> 自分のやっている範囲こそが「組込み」だと信じるの証左でしかない。
でさ、やっぱり何の*限定も無く*「組み込み」と言えばって前提の、「Rubyのようなものに、*これら* が担保できるのか甚だ疑問です。」って意見は、想定してる*これら*が違うんだから、双方、話が噛み合わないのも当然だと思う。
で、その程度の論拠を元に、Rubyチップ役にたたねぇって言う人間の意見には、作ろうとしている人がいる以上、賛成しかねるね。俺は。
# ふーん、ぐらいの印象って事ね
>>でさ、やっぱり何の*限定も無く*「組み込み」と言えばって前提の、>>「Rubyのようなものに、*これら* が担保できるのか甚だ疑問です。」>>って意見は、想定してる*これら*が違うんだから、
このときは、より最大公約数的な「組み込み」が想定されるべきでしょう。そして、限定的であればあるほど【何の*限定も無く*「組み込み」】といったときは議論から外されるべきでしょう。それは、そうした限定的な分野の話であり、ここで持ち出される話ではありません。
4bitマイコンでの開発を想定して、だからRubyは使えないとか言えないのと同様にゲーム機のような潤沢なリソースを前提にして、「だからRubyも使える」と言うのもちょっと違う話ですね。
「シチュエーション → Rubyの特徴」論法では有益な結論は得られないと思います。シチュエーションの限定の仕方は人それぞれであり、それについて言い合っても、たぶん、有益な結論は出てこないと思います。「最大公約数的なもの」に限定したとしても、その限定の仕方はひとそれぞれなわけで。
したがって、「Rubyの特徴 → シチュエーション」論法が有益だと思います。具体的には、「Ryby には、○○という特徴があり、組み込み分野での△△といった用途で、有用と思われる」といった主張の仕方です。
それで私は、この○○や△△に具体的に何が入るかが分からないのです。
＞リアルタイム性を要求される部分はCやアセンブラにまかせて、それ以外の部分を＞rubyという分担をしてもいいわけだし、斜め上というほど悪い筋じゃないと思います。
正にそれこそ組み込みJavaでやっていたものだけど、成功した事例はほとんどないと思う。＃「組み込みのスペック的にこれから」という可能性もなくはないけどねえ。。。
Androidは正気の沙汰とは思えないですね。
# そういえば、どっかの元社長もそんなこと言っていたような。
普段Rubyいじってる人は、きっと「ハードの制約」という概念自体がない。さらにハード的なコストに関する認識もないだろう。コストといえば、人件費しか浮かばないような仕事をしてる。はっきり言って、住んでるレイヤが違うんよ。優劣ではなく。
>従来どうりのハードよりの処理はC言語で必要十分だしRubyを採用するメリットなどない。
必ずしも否定しないんだけど、「ハードより」の処理でもSoCを操作するレベルのAPIだとC言語じゃなくてRubyぐらいの高機能言語のほうが生産性が高い気もしてみたり。
C言語もアゼンブラに比べれば、十分「高機能」なわけだから、さらなる「高機能」の代替としての模索もありだとは思う。
＞特定のプロセッサ向けのnativeなRubyを作るベンダーが出てくるような状況になれば話は違ってくるでしょうが.....
話はほとんど逆で汎用FPGAを使ってRuby向けの特定のプロセッサを作ってRuby-nativeなプログラムを書けるようにしようというプロジェクトですね。CPU機能が必要になった所に、IPコア単位で導入できて、プログラミング言語はRubyだけ使えればOKという世界。
「生産性」って具体的に何のことを言っているのでしょう。
まず、言語が選ばれる基準は、「言語仕様」ではなく「ライブラリ群」な気がします。例えば、組み込みLinuxにおける、既存のUnixアプリやプロトコルスタック。GPLの制約があっても選ばれています。WebにおけるJava、Windowsにおける.net、RoRフレームワークのRuby なんかもそうですね。さて、Rubyには、組み込み分野で有用なライブラリ群ってあったりするのでしょうか？Rubyの特徴であるOOPって再利用できるライブラリ群があって活きてくるものですよね。でもそれが自前ライブラリだけだったら嬉しさも半分です。
「言語仕様」に注目しても、ハードウェアを操作するならば、ポインタを包み隠さないCの方が便利です。またガベージコレクタに勝手に動き出された日にはリアルタイム性なんかありゃしません。LLですからハードウェアの負荷も大きいでしょう。
そんなことを考えていると、前述の通り、組み込みで、Rubyを使うことで得られる「生産性」って、具体的に何のことを言っているのか分からなくなってきたりします。生産性の得られる用途って限定的なものかもしれませんね。たとえば、組み込み機器で裏で簡易Webアプリを立ち上げて機器間で情報共有するとか？
前述の通り、組み込みで、Rubyを使うことで得られる「生産性」って、具体的に何のことを言っているのか分からなくなってきたりします。
デバッグ書いてない要件の中で一番デカイのはデバッグだね。
システムの内部状態をモニターしたい。でもモニターのために甚大なソースを書くのは嫌だ。だって最終製品では取り除くんだもの。でも、そういう場合でも、大抵組み込みOSとかは使ってるよね。じゃぁ、組み込みOSが標準でデバッグ環境の一環として Ruby をサポートしていたら?
モニターそのものに Ruby が混ぜ込んであって、必要に応じてスクリプトライブラリをロードしておいて実行時に複雑怪奇な条件がそろったらデータを外部に送り出すというのもいいし、リモートデバッガ側に Ruby のようなプログラミング能力を強力に持たせるのも手だ。malloc()とか free() を呼び出すたびに今現在有効なはずのバッファを記録して、buffer overlap がないかとか、overflow を起こしていないかとかをランダムサンプリングしながら調べる。人間では辛いこの手の調査も機械なら一晩中でもやっててくれる。
ここにある意見のほとんどが、組み込みソフトそのものを Ruby で書く事にこだわって、「組み込みソフトの開発を支援するシステムを Ruby で作る」という発想があり得る、という点をかなり強烈に忘れているような気がします。
.
ちなみに。NASとかも「組み込みソフト」。この手の製品になると、「On Service Monitoring」機能の充実がとても重要なのですが、実は国ごとに「どういう情報が欲しい」という要件がかなり違います。全部実装しようとするとサービスをしている暇がなくなっちゃうぐらい、バラバラで、かつそれぞれがかなりのリソースを喰う。# 中でも日本のお客様のニーズは世界的に見てかなり異端で、それはそれは苦労します。
Rubyが組み込んであって、国ごとにモニタリング対象をチューニングできる、というのは良い解決策です。というか、ガッツリとプログラミングできる人でないと怖くてこの辺をいじれない、というのがコストがむやみと上がる要因なので、そのあたりを解決する方策として考えるべきではないかと ＞ 日本のメーカー
# 海外のメーカーはこのままで行くと Python 辺りを採用するでしょうから、その前に Ruby を業界標準に# する勢いで押す必要がありますが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
斜め上の努力 (スコア:3, すばらしい洞察)
それこそ、東海道新幹線のATSのトラブル [srad.jp]を繰り返すだけでしょう。
そもそも、こんなことに税金を使うなら、こんなことをしなければならないほど組み込み技術者が不足する自体になった原因である劣悪な労働環境や低賃金を改める方向に使ったらどうかと思います。
Re:斜め上の努力 (スコア:3, 興味深い)
(車載をやっている人は、車載特有の話を組込みの本質だと思ってたりするし、携帯ばっかりやっているも同様)
実際には、「組込み」の範囲はずっと広くて、リアルタイム性なんか全然いらないような分野もありますよ。
リアルタイム性を要求される部分はCやアセンブラにまかせて、それ以外の部分をrubyという分担をしてもいいわけだし、斜め上というほど悪い筋じゃないと思います。
Re:斜め上の努力 (スコア:1)
幸か不幸か、色々なプロジェクトに飛ばされたり火消をさせれたりで、特定の分野だけではなく、そういう組込みもやった経験も踏まえた上で言っているのですけど。
大抵の組込みシステムは、仮にリアルタイム性が不要な分野であっても、パソコンとかに比べてプアなハードやソフトのリソースの上で動かないといけません。当然OSの機能だってWindowsのようにリッチでない場合も多く、対象ハードウェアへの理解や操作などが要求されるのです。アップデートだってパソコンみたいにお気軽に行えるものではありませんから、パソコン用途は違った意味での信頼性も必要です。Rubyのようなものに、これらが担保できるのか甚だ疑問です。
Re:斜め上の努力 (スコア:1)
BASICが乗っていたものも結構ありましたし
ターゲットはありそうだと思います。
Re: (スコア:0)
＞特定の分野だけではなく、そういう組込みもやった経験も踏まえた上で言っているのですけど。
最近のゲーム機とか携帯電話の経験は無さそうですね。中でLLが走ってるのなんか普通になってきてますけど。
まさに
＞＞自分のやっている範囲こそが「組込み」だと信じる
典型例。
それはさておき、東海道新幹線のATSのトラブルが「組み込みにRubyのようなもの」を使ったのが原因だというソースってどっかにありましたっけ？
Re: (スコア:0)
>最近のゲーム機とか携帯電話
それらは「最新のゲーム機」とか「携帯電話」とかいう分野で組み込みではないよーな気もします。
まあ、どこまでを組み込みというのかという線引きの話
Re: (スコア:0)
傍から見ていて思ったけど，
>> 最近のゲーム機とか携帯電話の経験は無さそうですね。中でLLが走ってるのなんか普通になってきてますけど。
というケースは，組み込みという領域の中でのごく一部のケースにしか見えないんだけど．で，そういう領域を前提にするなら「組み込みプラットフォーム」と言わずに「ゲーム機プラットフォーム」とか「スマートフォン用プラットフォーム」とか言うべき．組み込み一般という前提で議論すべき状況で，一部の特殊な例を挙げて「だからおｋ」みたいなこと言うのも
＞＞自分のやっている範囲こそが「組込み」だと信じる
と同じレベルの思考じゃないの？
で，やっぱり何の限定も無く「組み込み」と言われれば
Rubyのようなものに、これらが担保できるのか甚だ疑問です。
という意見に賛成せざるを得ないと思うけどね，俺は．
Re:斜め上の努力 (スコア:1, すばらしい洞察)
俺も傍から見ていて思った事なんだけど、
>>> 自分のやっている範囲こそが「組込み」だと信じる
のこれとそれとは、同じレベルの思考に思えるね。
でもそれは、
>>> 自分のやっている範囲こそが「組込み」だと信じる
の証左でしかない。
でさ、やっぱり何の*限定も無く*「組み込み」と言えばって前提の、
「Rubyのようなものに、*これら* が担保できるのか甚だ疑問です。」
って意見は、想定してる*これら*が違うんだから、
双方、話が噛み合わないのも当然だと思う。
で、その程度の論拠を元に、
Rubyチップ役にたたねぇって言う人間の意見には、
作ろうとしている人がいる以上、賛成しかねるね。俺は。
# ふーん、ぐらいの印象って事ね
Re: (スコア:0)
>>でさ、やっぱり何の*限定も無く*「組み込み」と言えばって前提の、
>>「Rubyのようなものに、*これら* が担保できるのか甚だ疑問です。」
>>って意見は、想定してる*これら*が違うんだから、
このときは、より最大公約数的な「組み込み」が想定されるべきでしょう。
そして、限定的であればあるほど【何の*限定も無く*「組み込み」】といったときは
議論から外されるべきでしょう。
それは、そうした限定的な分野の話であり、ここで持ち出される話ではありません。
4bitマイコンでの開発を想定して、だからRubyは使えないとか言えないのと同様に
ゲーム機のような潤沢なリソースを前提にして、「だからRubyも使える」と言うのも
ちょっと違う話ですね。
Re:斜め上の努力 (スコア:1)
「シチュエーション → Rubyの特徴」論法では有益な結論は得られないと思います。
シチュエーションの限定の仕方は人それぞれであり、それについて言い合っても、
たぶん、有益な結論は出てこないと思います。
「最大公約数的なもの」に限定したとしても、その限定の仕方はひとそれぞれなわけで。
したがって、「Rubyの特徴 → シチュエーション」論法が有益だと思います。
具体的には、
「Ryby には、○○という特徴があり、組み込み分野での△△といった用途で、有用と思われる」
といった主張の仕方です。
それで私は、この○○や△△に具体的に何が入るかが分からないのです。
Re: (スコア:0)
Re: (スコア:0)
＞リアルタイム性を要求される部分はCやアセンブラにまかせて、それ以外の部分を
＞rubyという分担をしてもいいわけだし、斜め上というほど悪い筋じゃないと思います。
正にそれこそ組み込みJavaでやっていたものだけど、成功した事例はほとんどないと思う。
＃「組み込みのスペック的にこれから」という可能性もなくはないけどねえ。。。
Re: (スコア:0)
Android系以外のモバイル機器でもアプリ部はJavaでも書けますってのはありますし。
Re:斜め上の努力 (スコア:1, おもしろおかしい)
Androidは正気の沙汰とは思えないですね。
# そういえば、どっかの元社長もそんなこと言っていたような。
Re:斜め上の努力 (スコア:1, 参考になる)
Rubyネイティブでハードリアルタイムな仕様を策定すればいいだけの話でしょう。ハードウェアと使用する言語は別の話ですよ。
Re: (スコア:0)
Re: (スコア:0)
そりゃ、あんまりだろ。組込み系技術者に対する中傷かつ侮辱ではないかと。
組込みの場合、そんな必要な機能に対して余計な重いソフト積む余裕があるならハードウェアコスト削れって世界なんだよ。だからメモリや処理速度とか出てくるんだよ。
もちろん、数百円で買えるマイコンがGHzのクロックで動き、GB単位のメモリを積むようになれば別だが。
Re: (スコア:0)
普段Rubyいじってる人は、きっと「ハードの制約」という概念自体がない。
さらにハード的なコストに関する認識もないだろう。
コストといえば、人件費しか浮かばないような仕事をしてる。
はっきり言って、住んでるレイヤが違うんよ。優劣ではなく。
Re: (スコア:0)
だから組込プロセッサでLinuxを動かしたり，JavaやRubyでアプリケーションを組むというもあり。
ただし福岡県の資料にある
｜Ruby は組込みソフト開発の主流言語の C 言語に比べ生産性が 10 倍程度といわれ
｜ており、Ruby を組込みソフト開発に特化した言語にすることで、これら電子製品の
｜生産性の向上が期待される。
とあるのは見当違いもいいところ。
上位のアプリケーションのレベルでの生産性はRubyの方が良いかもしれないが，従来どうりのハードよりの処理はC言語で必要十分だしRubyを採用するメリットなどない。
Re:斜め上の努力 (スコア:2, 興味深い)
>従来どうりのハードよりの処理はC言語で必要十分だしRubyを採用するメリットなどない。
必ずしも否定しないんだけど、「ハードより」の処理でもSoCを操作するレベルのAPIだと
C言語じゃなくてRubyぐらいの高機能言語のほうが生産性が高い気もしてみたり。
C言語もアゼンブラに比べれば、十分「高機能」なわけだから、さらなる「高機能」の代替としての
模索もありだとは思う。
Re: (スコア:0)
そういう低レベル（下のレイヤー）のコードは細かい制御の論理を記述するのが中心なので，Rubyなどに特徴的な「生産性の高い」コード開発をサポートする機能に大して御利益は無く，そこまでRubyを使うメリットはありません。
しかもハードに密着した低レベルのコードほど信頼性，長期のサポートが必要なので，現時点で組込屋から見て「怪しげな」Rubyは問題外です。 組込用プロセッサのC言語の開発・販売をするベンダー（金を払えばCコンパイラを作ってくれる会社）が複数あるのと同様に，特定のプロセッサ向けのnativeなRubyを作るベンダーが出てくるような状況になれば話は違ってくるでしょうが.....
Re:左斜め上45度の努力 (スコア:1, 興味深い)
＞特定のプロセッサ向けのnativeなRubyを作るベンダーが出てくるような状況になれば話は違ってくるでしょうが.....
話はほとんど逆で
汎用FPGAを使ってRuby向けの特定のプロセッサを作ってRuby-nativeなプログラムを書けるようにしよう
というプロジェクトですね。
CPU機能が必要になった所に、IPコア単位で導入できて、プログラミング言語はRubyだけ使えればOKという世界。
Re: (スコア:0)
ですが、C言語を置き換えるのが目的でなければ(組込最適化された)Rubyが有用な部分は組み込みにもありますし、最後の段に書いてあるように産業としてクリアすべきポイントはある程度見えています。
もちろん普通に一社でやっては実現不可能でしょう。だからこそ、県単位で力を入れて、組み込み屋から見て「真っ当な」Rubyをつくろうという話なわけです。
福岡県は工業で発達してきた下地があるし、悪くないチャレンジだと思います。
Re:斜め上の努力 (スコア:2, 興味深い)
「生産性」って具体的に何のことを言っているのでしょう。
まず、言語が選ばれる基準は、「言語仕様」ではなく「ライブラリ群」な気がします。例えば、組み込みLinuxにおける、既存のUnixアプリやプロトコルスタック。GPLの制約があっても選ばれています。WebにおけるJava、Windowsにおける.net、RoRフレームワークのRuby なんかもそうですね。さて、Rubyには、組み込み分野で有用なライブラリ群ってあったりするのでしょうか？Rubyの特徴であるOOPって再利用できるライブラリ群があって活きてくるものですよね。でもそれが自前ライブラリだけだったら嬉しさも半分です。
「言語仕様」に注目しても、ハードウェアを操作するならば、ポインタを包み隠さないCの方が便利です。またガベージコレクタに勝手に動き出された日にはリアルタイム性なんかありゃしません。LLですからハードウェアの負荷も大きいでしょう。
そんなことを考えていると、前述の通り、組み込みで、Rubyを使うことで得られる「生産性」って、具体的に何のことを言っているのか分からなくなってきたりします。生産性の得られる用途って限定的なものかもしれませんね。たとえば、組み込み機器で裏で簡易Webアプリを立ち上げて機器間で情報共有するとか？
Re:斜め上の努力 (スコア:1)
デバッグ
書いてない要件の中で一番デカイのはデバッグだね。
システムの内部状態をモニターしたい。でもモニターのために甚大なソースを書くのは嫌だ。だって最終製品では取り除くんだもの。でも、そういう場合でも、大抵組み込みOSとかは使ってるよね。じゃぁ、組み込みOSが標準でデバッグ環境の一環として Ruby をサポートしていたら?
モニターそのものに Ruby が混ぜ込んであって、必要に応じてスクリプトライブラリをロードしておいて実行時に複雑怪奇な条件がそろったらデータを外部に送り出すというのもいいし、リモートデバッガ側に Ruby のようなプログラミング能力を強力に持たせるのも手だ。malloc()とか free() を呼び出すたびに今現在有効なはずのバッファを記録して、buffer overlap がないかとか、overflow を起こしていないかとかをランダムサンプリングしながら調べる。人間では辛いこの手の調査も機械なら一晩中でもやっててくれる。
ここにある意見のほとんどが、組み込みソフトそのものを Ruby で書く事にこだわって、「組み込みソフトの開発を支援するシステムを Ruby で作る」という発想があり得る、という点をかなり強烈に忘れているような気がします。
.
ちなみに。NASとかも「組み込みソフト」。この手の製品になると、「On Service Monitoring」機能の充実がとても重要なのですが、実は国ごとに「どういう情報が欲しい」という要件がかなり違います。全部実装しようとするとサービスをしている暇がなくなっちゃうぐらい、バラバラで、かつそれぞれがかなりのリソースを喰う。
# 中でも日本のお客様のニーズは世界的に見てかなり異端で、それはそれは苦労します。
Rubyが組み込んであって、国ごとにモニタリング対象をチューニングできる、というのは良い解決策です。
というか、ガッツリとプログラミングできる人でないと怖くてこの辺をいじれない、というのがコストがむやみと上がる要因なので、そのあたりを解決する方策として考えるべきではないかと ＞ 日本のメーカー
# 海外のメーカーはこのままで行くと Python 辺りを採用するでしょうから、その前に Ruby を業界標準に
# する勢いで押す必要がありますが。
fjの教祖様