長く使えるWeb開発言語のおすすめは？ 110
ストーリー by headless
長寿 部門より
長寿 部門より
本家/.「Ask Slashdot: Choosing a Web Language That's Long-Lived, and Not Too Buzzy?」より
私は仕事で古い(脆弱と言う人もいる)Webスクリプト言語(Perl)で書かれた多くのレガシーコードによるWebベースのサービスを扱っている。Mooseのような新しい拡張を使ってはいるものの、この言語は柔軟性に欠けていると感じる。 レガシーコードのサポートを避けることはできないので、当分はサポートを続ける予定にしているが、新たに開発するものに関しては、もっと現代的でWebアプリケーションに使われている言語を使いたいと思う。フレームワークごと変えてしまってもいい。しかし、プロジェクトの規模はかなり大きく、ビジネスにとってはミッションクリティカルなものでもある。今日の新星が明日ゴミ箱行きということもあるので、新しく人気のある言語に飛びついて、5年も持たないということになると困ってしまう。どの言語/フレームワークの導入がお勧めだろうか。
どれでもまぁ (スコア:5, 参考になる)
PHP
フレームワークの衰退が激しいのがリスク。長く使いたいなら公式のZend Frameworkで。
言語自体はアレであるものの、PHPのバージョンアップに対する適切なメンテが出来ればそれなりに使いやすい。
Ruby
フレームワークがRoR一択なので悩まなくてもいいが、JavaScriptを多用したりModelの一気通貫が効かないと苦しくなってくる。
DSLとシンボルの黒魔術をうまく扱える技術者が確保できるなら使いやすい。
Java
フレームワークはJSFがあの有様である現状、Spring MVC / Play frameworkの二択。
SpringはVMwareに切り捨てられなければそう死ぬことは無い。目下Oracleが一番のリスク。
JavaScript
現状ではNodeを使うことになるが、MVCフレームワークはまだ決定打がない状況。
スケールさせたいAPI層をNodeで、と割り切って使う分には良い選択肢。
C#
MVC、API、リアルタイムWebがそれぞれ公式でサポートされる安定感が欲しい場合は良い選択肢。
他と比べて開発環境のコストが高いので、人員を増やしたときのことも考えないと死ぬ。
Scala
技術者の確保に難儀するが、typesafeがPlay frameworkを推しているのが安心の元。
スケーラビリティが必要なときは良い候補ではあるものの、まだ言語自体にバッドノウハウが必要な箇所もあるのが注意点。
メジャーどころだとこんな感じか。
Re:どれでもまぁ (スコア:4, 参考になる)
何もかもが違うZend Framework2が出たでござる
より洗練されて使いやすくなったとはいえ、このバッサリ感はPHPに通じるものがある気がする…
Re:どれでもまぁ (スコア:1)
最近 Docker のお陰か、Go の使用例も少しずつ増えてますね。
Dropbox など Python からの移行組も多いようです。
Re: (スコア:0)
ASPぇ・・・
Re:どれでもまぁ (スコア:1)
いちおう、ASP→ASP.Net→ASP.Net MVCと続いているが、
パラダイムが変わり過ぎで何ともはや。
（そして混在も可能と言うのが……ウガァァ）
Re: (スコア:0)
ASP.NET WebFormsなんてものは無かった。いいね?
Re: (スコア:0)
ASP.NET MVCは全てのASP.NET WebFormを置き換えるものではない
外部から仕事をもらうという意味では厳しいだろうが業務系なんかで使われ続けるケースもありそう
Re: (スコア:0)
それはLightSwitch使いなよ
Re: (スコア:0)
LightSwitchは無いわ。Silverlightだもん。
Re: (スコア:0)
これってどういうこと？DataGridとかコントロールの利便性の事を言ってる？
Re:どれでもまぁ (スコア:1)
逆だろ
どうでも良い画面ならそれこそMVCのテンプレートでやった方がシンプルで楽だし、後から調整したい時も小回りが効く
CRUDっぽいものならLightSwitchとかDynamic Dataを使えば良い
WebFormsの良いところなんて、DataGridが使えるところぐらいだよ
むしろ最近はMS自体がWebFormsを黒歴史扱いし始めて採用すること自体がリスクになってるわ
Re:どれでもまぁ (スコア:1)
Windows Formも要らんよ、WPFでWMMVするし。
っていう人がもっと増えたら面白いんだが、まあそれこそ5年は掛かりそうだ。
しまった (スコア:1)
WMMVってなんだorz
MVVCとWM(WebMatrix)が脳内で謎の融合をした…
Re:どれでもまぁ (スコア:1)
> #あと、ASP.NET MVCはEntityFrameworkとも密接過ぎて、そこら辺でも面食らうと思う。
これは何かの間違いじゃ?
デフォルトテンプレートは確かにEF使ってるけど、RailsとAcriveRedordsみたいな関係の縛りは無いよ。
実際、みんな大好きStackOverflowはASP.NET MVCとDapper Micro-ORMの組み合わせだし。
Re:しまった (スコア:1)
あぁぁ…ドツボだ… これはマズイかな……
Re: (スコア:0)
Clojure・・・
Re: (スコア:0)
Re: (スコア:0)
C#は別に開発環境が高くなるとは限らない気がする。
無料版でも商用利用できるんだし。
超大規模プロジェクトやるならともかく、中小程度のプロジェクトじゃ無料版ですら十分。
事実それでやってる所も沢山ある。
Re:どれでもまぁ (スコア:2, 興味深い)
> あとModelの一気通貫てなんだ？
Railsメインの人が他のMVC FrameworkのAction MethodでのModelの取り扱い仕様をみて「はぁ?」ってなるアレ。
確かにRailsは入力から中の処理までARのModelで貫き通せばRSpecのテストも書きやすくて凄いんだけど、
いちいちMassAssignment脆弱性対策でStrongParameters使うのもだりぃし他のFrameworkみたくForm Modelを使わせてよ、
みたいなレールを外れたことをするとDHHがカールスバーグの割れた瓶持って殺しに来る。
Re:どれでもまぁ (スコア:1)
アプリ経由以外でWebサーバーが攻略されるのは自身の問題ではないのでDB接続情報は平文でもっていたりするわけだし。
セッション変数なんかよりそっちのほうがぞっとしない？
クライアントアプリだと悩むところもWebサーバーと分離されている部分で楽できてる。別途通信の問題とか別の問題を抱えるけどね。
まーた誤訳してるし (スコア:4, 興味深い)
Perlが「脆弱」ってなんのことかと思ったら、原文ではvenerable（「お年を召した」くらいの意味）じゃないか。Vulnerableと間違えたんだろうけど、この程度の英語力しかないんなら機械翻訳でのダブルチェックすることくらいすればいいのに。
5年前かあって5年後もありそうなもの (スコア:3, すばらしい洞察)
JavaScript/Notepad.exe
英語かな？ (スコア:2, おもしろおかしい)
英語かな？
Re:英語かな？ (スコア:5, すばらしい洞察)
いつまでたっても使えるようにならない言語ですね
使い捨て・作り捨て (スコア:1)
身近な例を出すと、オンライン・ショッピングのサイトなどは見た目のデザインを変えるためだけでも数年ごとに作り変えている
変化が早いからwebアプリケーションなんてものは基本的に使い捨て・作り捨て
そういう開発に対応するためにいわゆる「生産性の高い」（少ないコード記述量で豊富な機能を実現できる）言語が使われるわけだが、プログラミング言語の方も流行り廃りや進歩が早くて使い捨てと言って良い
結局は変化に対応してより好み無くどんな言語でもすぐに学習できるだけの基礎知識と経験を身につけるのが一番
＃組込開発なんかとは世界が違うんだから、そもそも長く使える言語など無いと思え
Re:使い捨て・作り捨て (スコア:2)
最近のトレンド (スコア:1)
というか最近の仕事の無いように近い事を箇条書きにしてみたのですが、
フロントエンドだと
-Web APIを使ったシングルページアプリケーション
-Angular JS, Knockout JS等による実装のリッチクライアント
-CoffeeScript/TypeScriptによるJavascript代替記法
-LESS/SCSS,etc...によるCSS代替記法
-JadeによるHTML代替記法
バックエンドだと
MongoDBとかDatastoreみたいなndb系
かなぁ。
ここら辺全部を一言語で網羅できるようになるんでしょうかね?
この分野、日進月歩なんでそもそも設問自体に無理がある様な。
J2EE&JSP (スコア:1)
>プロジェクトの規模はかなり大きく、ビジネスにとってはミッションクリティカルなものでもある。
>5年も持たないということになると困ってしまう。
「Java(J2EE)でフレームワークなし（素のJSP＆サーブレット）で、JavaScriptを使わない」
たぶん、これが最も長く使える言語だと思います。
# Oracleがjavaのサポートをやめても、きっとIBMが……
# ストアドにjavaを使えるようにしているので、Oracleのサポート放棄の可能性は低いと思うけど。
notice : I ignore an anonymous contribution.
PHP＋フレームワークはどんどん変わる (スコア:0)
仕事で10年ぐらいPHPつかってる。
フレームワークはその時務めている会社や周りの環境によってどんどん変わっていった。
会社独自→Mojavi→Zend Framework→symfony→会社独自
PHPはアンチに叩かれまくりだけど、FacebookでHHVMが作られたりけっこう新しい動きがあるような気が。
Re: (スコア:0)
PHPが糞だからHack作ったんでしょうよ
このググラビリティの低い名前をつけたやつはセンス無いと思う
似たようなネタでスレ立てすぎ (スコア:0)
長く使えるとか未来人しかわからないし、必要に応じて技術習得しろとしか言いようがない
Re: (スコア:0)
いや、技術の習得はいいとして、
すでに書いてしまったソフトウェアがまだ現役のうちに、
言語やフレームワークが終了で、バグフィクスもされない。
というのが困るなぁという話では？
未来のことは未来人にしかわからないは賛同しますが。
絶対の勝利者 (スコア:0)
Re: (スコア:0)
Re:絶対の勝利者 (スコア:1)
Almquist Shell使えや
ビジネスプロセスがちゃんとモデリングされてれば言語なんてどれでもいい (スコア:0)
とは思うけど、それでもどうしても挙げろと言われれば
PHP+Zend FWを自分は推す
まず、PHPはとりあえず5年後にメンテナンスされている処理系が手に入らない可能性はあまり高くないと予想される。
そして、大規模プロジェクトをやるにあたって人を集めやすい。
Zendはモデリングのお手本として優れている。MVCだとかを強要されず、部分的に作って置き換えるのがやりやすい。
ただし、前提として、今Perlメンテしてる人はフェードアウトしてもらうというのがあるけど。
Re:ビジネスプロセスがちゃんとモデリングされてれば言語なんてどれでもいい (スコア:1)
> まず、PHPはとりあえず5年後にメンテナンスされている処理系が手に入らない可能性はあまり高くないと予想される。
今使っているバージョンはメンテナンスされていなくて新しいバージョンは互換性がないという可能性は非常に高いと思う。
Re: (スコア:0)
Re: (スコア:0)
Perl6 は中止となり、 Perl5 が互換性を強力に維持(CPAN登録済みのモジュールへの影響がないようにメンテされてます)しつつ毎年4月に新バージョンがリリースされ続けるのでしょう
Re:ビジネスプロセスがちゃんとモデリングされてれば言語なんてどれでもいい (スコア:1)
でたよ。10年(+3年)サポートだってさ
2027年にRHELはバージョンいくつになっているであろうか… 12くらいかな
Re: (スコア:0)
言語なんてどれでもいい、と言う人には心のなかで要注意人物フラグを立てます。
そもそもWEBが５年後あるかどうかという (スコア:0)
つか、なんでもイノベーションで捨てよう！作り直そう！毎年買い替えよう！
とか言ってたじゃん。
５年後ならもう別の言語にチェンジしろって
Re:そもそもWEBが５年後あるかどうかという (スコア:1)
apple。
※個人の感想です。
へ～じゃあ君の思う「柔軟性のある」言語って何さ？ (スコア:0)
> この言語は柔軟性に欠けていると感じる。
そもそも言語の柔軟性とは？
それがないので、この主張には「Perlは古いから」って印象論以上のものを感じないんだよねぇ。
5年10年経ったコードに柔軟性がない、なんてのは言語の問題と違うんじゃないの？
いま流行りのどの言語を使おうが、実運用下である程度の規模の作り込みをした上で5年10年経過すれば、
柔軟性なんてひどく失われてるだろうね。
# mishimaは本田透先生を熱烈に応援しています
Re:へ～じゃあ君の思う「柔軟性のある」言語って何さ？ (スコア:1)
本当に疑問に思ってるんなら原文読めば明らか。
疑問に思ってるんじゃなくて、ケチを付けることで優越感を得たいだけなら、そう書いてくれるとみんな読み飛ばせてハッピー。
Re:へ～じゃあ君の思う「柔軟性のある」言語って何さ？ (スコア:1)
本当に疑問に思ってるんなら原文読めば明らか。
本当に疑問に思ってるし、原文見ても分かんないんだけど。
「明らか」って書いてあるんだから、君には明確なんだよね？
説明してほしいな。この文脈でいうところの柔軟性って何？
# mishimaは本田透先生を熱烈に応援しています
柔軟性？ (スコア:0)
柔軟性という表現されるとperlで作れば良いんじゃないのって書きたくなるなぁ(笑)
今後すぐには衰退しないという意味なのだろうけど
男は黙ってC++ (スコア:0)
ぜんぶ作って抱え込めばいいじゃん。
Re: (スコア:0)
C++は(心理的負担が)重過ぎるからCにしよう。
Javaは多重継承を許している (スコア:2, すばらしい洞察)
よくC++は多重継承が・・・って言う人いますけど
Javaのインターフェースは多重継承の一種なんですよね。
継承に関してC++にあって（7以前の）Javaに無いのは実装の多重継承だけで、
型の多重継承とでも言うべきインターフェースの多重継承はJavaも許しています。
多重継承の欠点として関数名の衝突やダイヤモンド継承がよく挙げられますが、
これらはインターフェースを通してJavaでも起こり得ることです。
そこでJavaは実装の継承を一つに限ることで問題を回避しようとしているわけですが、
一般に同名関数の意味が一致することは期待できないはずです。
例えば、ゲーム内の車両を表すインターフェースが持つrun()と
Runnableインターフェースが持つrun()の意味は違うはずだからです。
最近はJava8のインターフェースのデフォルト実装とかRubyのMix-inとか、
関数実装の多重継承は許して状態の多重継承を許さないのがトレンドだと思います。
なので一概に多重継承は・・・とはもう言えないような気がしています。
# ネタにマジレスごめんなさい
## オフトピっぽくなってしまったけどRubyの話も書いたしまぁいっか