アカウント名:
パスワード:
「生産性」って具体的に何のことを言っているのでしょう。
まず、言語が選ばれる基準は、「言語仕様」ではなく「ライブラリ群」な気がします。例えば、組み込み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)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
斜め上の努力 (スコア:3, すばらしい洞察)
それこそ、東海道新幹線のATSのトラブル [srad.jp]を繰り返すだけでしょう。
そもそも、こんなことに税金を使うなら、こんなことをしなければならないほど組み込み技術者が不足する自体になった原因である劣悪な労働環境や低賃金を改める方向に使ったらどうかと思います。
Re: (スコア:0)
だから組込プロセッサでLinuxを動かしたり，JavaやRubyでアプリケーションを組むというもあり。
ただし福岡県の資料にある
｜Ruby は組込みソフト開発の主流言語の C 言語に比べ生産性が 10 倍程度といわれ
｜ており、Ruby を組込みソフト開発に特化した言語にすることで、これら電子製品の
｜生産性の向上が期待される。
とあるのは見当違いもいいところ。
上位のアプリケーションのレベルでの生産性はRubyの方が良いかもしれないが，従来どうりのハードよりの処理はC言語で必要十分だし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の教祖様