また枯れた言語でもそれを用いることが理にかなっている場合はそれを使用しますか?
私はいわゆる社内情シスと呼ばれる所にいまして
現場からちょっとしたツールをチャチャッと作ってほしいと要求されることが多々あります。
そのときに私は、手軽で小回りが利き、自身がDBにもなり、レポート印刷、Excel出力なども
容易であるAccessを選択することがあります。
(AccessVBAを言語と呼んでいいのかどうかわかりませんが)
ですが、作りながら「自分は今いわゆる"枯れた言語"で開発しているんだなあ。
この「スマフォ対応化」とか「クラウド化」とかいうご時世に…」と思うと
ちょっと気持ち的に萎えたりします。
なのでAccessで作ればすぐにできるものを
あえてPerl,PHP等で作って提供したりもしています。
ですがやはり現場密着の小規模ツール作成で
一番使いやすいのはAccessなのかなと最近よく思います。
(エクセル操作性など)
こういった葛藤も踏まえて何かアドバイスなどありましたら
よろしくお願いします。
また業務アプリにおいておすすめ言語などありましたら
教えてください。
コメントが無効になっているので、回答で失礼します。
「枯れた言語(技術)」というのは悪い意味ではなく、バグや不具合が出尽くした
(修正され尽くした)安定したものという意味です。
最新の技術は、目新しさや新しい機能はありますが、未知の不具合や組み合わせに
よる実績なども乏しく、必ずしもそれを使うことがよいとは限りません。
新しい技術を習得することはそれはそれでよいことだと思いますが、いろいろな
選択肢の中で本当に最適な解を提供できることこそ、技術力の高さだと思います。
新しいものを使っても、使いづらいものしかできないのであれば、それは技術が
あるとは言えないですね。
弘法筆を選ばずではありませんが、「作業効率を如何によくするか」を意識し、
それに対するユーザインタフェースや保守性、拡張性を考慮した設計、ツールの
提供ができることこそが、プロフェッショナルの条件ではないでしょうか。
>また業務アプリにおいておすすめ言語などありましたら教えてください。
これは社内で誰もがすぐに使いやすいものだと思います。
Office が入っているのであれば、Access や Excel は有力な選択肢ですし、
部署間で大勢が扱うデータの処理をするのであれば、PHP やデータベースを
使用してWeb アプリケーションとすることもよい選択肢だと思います。
これはケースバイケースではないでしょうか。
業務アプリ開発において「枯れた言語」とはどこからどこまでを言うのでしょうか?
言語仕様の変更がほとんど見込まれないという点では、COBOL, FORTRAN, C/C++, Java, Perl, VisualBasic あたりですかね。
また枯れた言語でもそれを用いることが理にかなっている場合はそれを使用しますか?
使用します。
個人的には、ミニツールを作るときには以下のような“枯れたと思われる”言語を使っています。
Webアプリ | Perl |
C/S | VBScript(※ただしWindows環境限定) |
スタンドアロン | C(BCC) |
この中ではBCCが好きで、「Borland C++開発環境ポータブル化」によって開発環境をUSBメモリの中に入れています。そのUSBメモリにはこの他にも複数のツールを入れてあって、システムのメンテナンス用にドライバセットと一緒に持ち歩いています。
AccessVBAも便利なのですが、職場や顧客の中にはAccessを入れていない端末が多いので、私はそれほど使いません。
コメントが無効になっているので、回答で失礼します。
「枯れた言語(技術)」というのは悪い意味ではなく、バグや不具合が出尽くした
(修正され尽くした)安定したものという意味です。
最新の技術は、目新しさや新しい機能はありますが、未知の不具合や組み合わせに
よる実績なども乏しく、必ずしもそれを使うことがよいとは限りません。
新しい技術を習得することはそれはそれでよいことだと思いますが、いろいろな
選択肢の中で本当に最適な解を提供できることこそ、技術力の高さだと思います。
新しいものを使っても、使いづらいものしかできないのであれば、それは技術が
あるとは言えないですね。
弘法筆を選ばずではありませんが、「作業効率を如何によくするか」を意識し、
それに対するユーザインタフェースや保守性、拡張性を考慮した設計、ツールの
提供ができることこそが、プロフェッショナルの条件ではないでしょうか。
>また業務アプリにおいておすすめ言語などありましたら教えてください。
これは社内で誰もがすぐに使いやすいものだと思います。
Office が入っているのであれば、Access や Excel は有力な選択肢ですし、
部署間で大勢が扱うデータの処理をするのであれば、PHP やデータベースを
使用してWeb アプリケーションとすることもよい選択肢だと思います。
これはケースバイケースではないでしょうか。
ぼくは、「枯れた言語」って言い方はしなくって、質問と同じ意味で使うとしたら「カビの生えた言語」かな。
境界線は、「動的にメモリの割り当てができるかどうかと、スタックがあるかどうか」かな。
これが無いと話に作る気にならない。COBOL や Fortran は、この時点でさようなら。
データ量の最大値を決めないと作れないとか、サブルーチンを再帰で呼び出せないとか、縛りがきつ過ぎて、やる気が起きない。
それ以外は、言語の好き嫌いはあるけど、やりたいことに合わせて、作りやすい言語を選ぶことは結構ある。
IE を制御しながら、データを拾い集めるようなツールを Ruby で作ろうとは思わないし、
複雑な計算があっても、帳票の体裁を整えなきゃいけないなら、c++ で作ろうとは思わない。
# 作れなくは無いけど。
作りやすい、ってことは、それだけ障害を作り込むことが少なくなるわけだから、「理にかなってる」ということになるのかな。
因みに、「枯れてる」って形容詞は、ぼくは悪い意味で使うことが(あまり)無い。
障害がある程度、出尽くしているライブラリなんかを、信用して使えるという意味を込めて、
「あのライブラリは枯れている」というような使い方をするかな。
コメント(3件)
やっぱりネットで調べる→課題のクリアまでは、おっしゃっている枯れた言語のほうが圧倒的に早いですよね。
出来る手で、業務に負荷を与えずにクリアしていくことは必須。
ゆとりがあるなら新しいことを。そうやっていくしかないですよね。
Excelも帳票のみなら結構使えるし、ちょっと複雑な抽出するならAccessがいいと思います。
複雑な帳票出したいときはDBにクエリ作って半分はExcelのVBAってこともあります。
使用者にとって出力されたものが再利用しやすいというのもメリットかも。
社内全体(規模にもよるけど)で使用する抽出&ビューオンリーの作業はPHPが向いてたり。
メンテやセキュリティ考慮してもそうなりますよね。
細かいとこではDBのライセンスなどの絡みもあります。
ブラウザベースのPHPだと入力効率なんかも制限出ます。
それぞれいいとこどりするのがスキルなんじゃないかなぁと思います。
自分は現状で選べるほどスキルないですけど。
Officeの仕様に左右されて2007ではExcelVBAで再帰処理が無くなって大わらわです。
Mook様の回答のように「枯れた」というのはバグが出尽くして仕様も固まった安心して使えるものだと考えます。
皆さんご回答ありがとうございます。
また、closeした後までコメント頂きありがとうございます。
質問では文字数制限で大事なニュアンスをお伝えできてなかったのですが、
正にkia_44さんのおっしゃるように、現場ユーザは出力結果をExcelでほしがる
ことが多いので、Excelに細かく指示を出せることが必須です。
ですのでAccessVBA⇒ExcelVBA連携などを多様したりしています。
そして仰るように抽出&ビューオンリー(+マスタメンテ画面くらい)
のものはPHPなどで作って、バージョンアップのたびに全端末に
セットアップして回らなくて済むようにしています。
状況に合わせて選択することが大事だとよくわかりました。
「枯れた言語」の正しい意味も知らぬまま質問をしてしまいましたが
親切でわかりやすい回答ばかりで本当に感謝です。