アカウント名:
パスワード:
>従来どうりのハードよりの処理は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)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
斜め上の努力 (スコア:3, すばらしい洞察)
それこそ、東海道新幹線のATSのトラブル [srad.jp]を繰り返すだけでしょう。
そもそも、こんなことに税金を使うなら、こんなことをしなければならないほど組み込み技術者が不足する自体になった原因である劣悪な労働環境や低賃金を改める方向に使ったらどうかと思います。
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の教祖様