ライバル言語の良いところを教えてください

Question

タイトルには言語と書きましたが、言語でなくてもOKです。OS含むソフトウェア、フレームワーク、技術、システムなど、teratailで扱う話題に関するものならなんでもかまいません。

まず、ご自身が支持する言語Xについて説明してください。

つぎに、対立するライバル言語Yについて、良いところを挙げてください。たとえば「くやしいけどYのこの機能にはXは負ける...」のような感じで。

対立しているのかどうかは、主観でかまいません。

よろしくお願いします!

---

皆様、ご回答、ありがとうございました。
自分の未知の情報がたくさんあって、とても参考になりました。

最初に投稿していただいたのと、期待していた回答にいちばん近かったということで、
nanndemoiikaraさんに進呈させていただきました。

Answer 1

くやしいけどJavaのプラットフォームの多さにはC#は負ける...

C#/.NETもOSS化が進んできたので今後に期待

Comments

[Tak1wa]

危うく全く同じことを投稿するところでした…。
違う方面で考えてみます。

[argius]

ありがとうございます。

初心者の頃も今でも、JavaはWORAなところが私はとても好きです。
でも、.NETとC#で同じことができたら、気持ちが傾いてしまうかも知れません。

JavaはずっとじわじわとC#に追いやられてきていますけど、JVM言語がたくさんあるのでまだ頑張れると信じています。

[sho_cs]

Tak1waさん
やっぱり同じこと考えちゃいますよね。

argiusさん
Scala、Clojureあたりは気になりますね。（.NETにはF#が

[argius]

ちょうどApache Sparkが話題になったことですし、Scalaは少し流行りそうな気配がしますね。

Answer 2

回答依頼をいただき、ありがとうございます。

すでにいくつかの言語について述べられていますので、僕は、携帯情報端末アプリを開発するプラットフォームについて考えてみたいと思います。

**Xcode（Swift）**は
Android にかなわない点がある

１）先日（2015.06.08 WWDC15）、Swiftのオープンソース化が発表されたが、言語の浸透や学習者の増加を Appleが望むのであれば、安価なサードパーティーのハードウェアでも Swiftが動くようにする必要がある。
一方、Javaを学んだことのある者にとって、ありきたりのハードウェアでも動くAndroid Studio（や Eclipse）などの IDEは門戸をおおきく開いているように思える。

２）今や、Androidは携帯情報端末のみならず、ノートパソコンやカメラ、さらには冷蔵庫にまで搭載されている。

ただし、じっさい僕はどちらも使用していますし、両者を対立させて考えることはありません。
また、Appleにも、Googleにも、それぞれの企業哲学と戦略があるのであって、僕はどちらが優れているかということは断定できません。
今回は、質問の趣旨にそって、あえて比較してみました。

Comments

[argius]

お応え＆お答え、ありがとうございます。

そうですね。GoogleとAppleの対立の構図ではGeorgeCohtaさんのおっしゃるようにAndroidが優勢に見えますが、一般開発者から見たら、どっちも対応するに越したことはないでしょうし、私も両方マスターできればと思っています。
私はJavaのほうがメインなので、どうしてもAndroidびいきにはなってしまいますけどね。

[退会済みユーザー]

argiusさん、コメント（返信）をいただきありがとうございます。
モバイルアプリ開発に関していえば、現状においては、どちらのプラットフォームにも対応せざるをえないことがとても悩ましいですね。
開発言語が異なるだけならともかく、Appleも、Googleも、UIに関してはどちらも譲らないポリシーがありますし……

[argius]

UIが1つでも大変なのに、2つも対応しないといけないわけですから、本当に大変ですよね。
現場の情報、とても参考になりました。ありがとうございます。

Answer 3

こんにちは。

支持：ウォーターフォールモデル
ライバル：スパイラルモデル

支持…というか業務上、やむを得なくウォーターフォールが現役です。

品質やら工数やら色々難しい話はあるかもしれませんが、
スパイラルモデルは短い期間で成果を感じながら
反省と成長を繰り返すことが出来そうだなと個人的に感じています。
※色々デメリットもあるのかもしれませんが、開発者モチベーション的な意味において。

悔しいというか、羨ましいですね。

Comments

[argius]

ありがとうございます。

ウォーターフォールモデルは、とりあえずウォーターフォール、みたいのがあるのが残念ですね。もうちょっと選択肢があっても良さそうなのですけれど。

それとウォーターフォールモデルでいつも長い期間のプロジェクトだとつらいかもしれませんね。メリハリがあったほうがモチベーションも維持できるんじゃないかと思うのです。

私は長いのに慣れているので、短いスパンだと逆に締切が間に合うか心配です。

Answer 4

普段UNIXで、仕事をすることが多いのですが、テキスト処理はPerlを使用して解決してしまうことが多いです。
ただ、二次元以上の配列はPerlでは、配列（1次元）の要素に配列のリファレンスを入れる。
みたいな感じで参照も、$array[0]->[1]みたいな感じになります。
見せ掛けだけは、$array[0][1]と省略（Perlの美徳？）することができるのですが。。。

素直に、Rubyの多次元配列が欲しい。。。ｗ

Comments

[argius]

ありがとうございます。

私もUNIXで、最小構成だからかPythonもRubyもbashすら入っていない環境でPerlを使っています。でもJavaを始めるより前にPerlをやっていたので馴染みがあって、特にテキスト処理でライブラリーを駆使しないようなコードなら今でも良く使います。
プロダクションはPerlすら許されないという残念な事情により、解析なんかには重宝しています。

書き方のバリエーションはだいぶ忘れてしまいましたが、個人的には暗黙の$_が大好きです。
あと、Perlの場合はリファレンスを意識するせいか、$array[0]->[1]のほうが私はしっくりきます。C言語のポインターのイメージに引っ張られてせいだと思うんですけどね。

Rubyは最近はご無沙汰です...

Answer 5

プロビジョニングに Ansible を使っとりますが、YAML + Jinja2 というところにハマったり記述力に劣るな―と思うことがあるので、Chef の Ruby という汎用言語の内部DSLなところはいいなぁ、と思います（Chef まともにさわったことは無いですけれども）。

Itamae という Ansible っぽいコンセプトで Ruby の内部DSLなやつが最近出てきだしたようなので少し気になるところです。

Comments

[argius]

ありがとうございます。

プロビジョニングも守備範囲外ですね。それどころかプロビジョニングという言葉に馴染みが無さすぎてちょっと恥ずかしい...

ChefとかAnsibleあたりは目にすることは良くありますが、どう違うのかすら知らなかったので参考になります。
Java付近でいうところのXML地獄みたいなものなのかな？

Answer 6

言語ではなくPHP FWです。

くやしいけど「FuelPHP」や「Laravel」の「ユニットテストのしやすさ」には「CodeIgniter」は負ける
まぁ、でも速いし。。。

Comments

[argius]

回答ありがとうございます!
もちろん、フレームワークでもOKです。

PHP自体詳しくありませんが、CodeIgniterは知りませんでした。高速さが売りなんでしょうか。
いつかPHPのフレームワークを選定することがあったら、CodeIgniterを候補に入れたいと思います。

[nanndemoiikara]

ご返信ありがとうございます。
http://d.hatena.ne.jp/cakephper/20110802/1312275110

これは1例ですが、PHP FWの中でも圧倒的速度です。
Phalconを除けばPHP FW最速かと思います。
(個人的にphpのextension入れなきゃ動かないPhalcon使うくらいならHHMVを使います。)

ただ、速さの理由であるシングルトンが理由でユニットテストが大変手間です。
是非一度候補に入れて頂ければと思います。

何卒よろしくお願い申し上げます。

[argius]

詳しいご解説いただき、とても良く理解できました。
PHPは少なくとも知識として必要とは思っているものの、とっかかりが無くてなかなか学習が進みませんでしたが、今回は良いきっかけになりました。

あと、書き忘れましたが、お題に沿った文章で書いていただいてありがとうございます。
ちょっとクスッとしました。(^-^)

Answer 7

言語の vs. でありがちですが、
Ruby (好きな言語) vs. Python (ライバル言語) です。

1. シェアが広い
   • よく使われているというだけでメリット
2. 速度
   • Python が速いというよりも、 Ruby が遅い
3. C, C++ との親和性
   • mruby の登場で組み込みは変わってきているけど、
     C, C++ での拡張ライブラリーの書きやすさは上
4. 科学技術計算分野
   • 2, 3 の影響もあってか、専門性が高い計算用の
     ライブラリーがそろっているのが、うらやましい。

速度や C との親和性では Lua 、 技術計算では Julia というように個々でみればもっといい言語はいっぱいあって、何かに突出したものはありませんが、 Python はいろんな要素をいいバランスで備えていると思います。
それに比べると Ruby は いびつ に感じます。ただ、そこも好きだったりします。

Comments

[argius]

回答ありがとうございます。

Pythonは安定感がありますよね。スクリプト言語を最終的にひとつに絞るとしたら、Pythonかなーと思います。
今のところはPerlくらいしか比較的自由に使えていないのでPythonとの比較はできませんが、速度という点では、Perlと比べてRubyはちょっと厳しいですね。最新版を確認していないので、現時点でどうなのかは分かりませんけれど。

でも、コードのぱっと見はRubyの方が好きです。

[yohshiy]

いつのバージョンの Ruby を使われていたのかわかりませんが、 1.8 から 1.9 に上がった際に内部的に仮想マシン(VM)を使うようになって 5 倍ほど速度が上がっています。
あまりスクリプト言語の速度に興味がないので、ベンチマークの結果などを調べたわけではないですが、PyPy が速いらしいというだけで、 CPython や Perl と比べて、そこまで遅いということはないはずです。
ただ、 傾向として Ruby は速度よりも書きやすさを優先するところがあるので、速さを求めるときに選ぶ言語ではないとは思います。

[argius]

YARVですね。
以前比較したのは1.8.xと1.9.xのどちらだったのか、環境が失われてしまったので残念ながら分かりません。
いま手元のRuby 2.2.2（WindowsのCygwin版）を少し試したところ、あくまで体感的にですが、以前よりかなり速くなっていると感じました。

これからスクリプト言語で本格的なアプリを書こうと思ったら、少し触ったことのあるRubyかな、と思っています。Pythonはいまのところ教養として学ぶ程度で。

Answer 8

5年程ASP.NET開発をやってきたうえで、Java（JavaEE+JSF）を机上学習したところ気に入りました。
但しJavaによる業務は未経験です。そんな前提になってしまいますが、

JavaEE+JSF

MVCのフレームワークがシンプルに実装されていて、デザインの自由度が高く感じます。デザインがフレームワークの押し付けを受けにくいといいますか。SDKのバージョンアップを想定した場合も、クラス体系がシンプルなので既存ソースの継承など有利なのではないでしょうか
ソースの転用（リファクタリング）も、他言語より有利に感じます。
最初の開発では習得に苦労しそうですが、その後のメンテナンス性や機能拡張、他プロジェクトへの転用において効率向上を期待しています。

ASP.NET

画面にコントロールを張り付けるやり方で、簡単な画面は作り始めることができます。開発メンバーを招集するのはJavaより用意と思われ、チーム内教育なども低コストで済むのでしょう。

Comments

[argius]

ありがとうございます。

JavaEEは過去にJ2EEという黒歴史があるので、よく持ち直したなーと思います。JSFも（まだ勉強不足ですけど）評判は良さそうです。
ASP.NETは、大昔にはよくVB+ASPのプロジェクトに参加していたので、メンバー召集しやすいというのは何となく分かります。

もし、ASP.NETをやっているとJSFに入りやすい何かがあったとしたら、意図的に取り込むためにそうなっていたりするんでしょうか。それともたまたまBlueMoonさんの感覚にJSFがフィットしたんでしょうか。

どちらも詳しくないので自分で評価ができなくてすみません。

[BlueMoon]

コメントにお答えいたします。
ASP.NETで初期に格闘したのは、オブジェクトの生成タイミングと保持の仕組みを踏まえていないと、イベントハンドラが意図通り動かなかったことが有りました。特に動的にオブジェクトを配置した場合でしたが。この点JavaEE6.0のCDIは、オブジェクトをスコープ（session,request）など任意の範囲で保持できるので扱いやすく、ハンドラ記載の際に迷うことが少ないと思います。
余談ですがCDI（ContextDirectInjection）はコンテキスト（オブジェクト）をAPサーバに直接組み込ませることで、オブジェクトを各ページからアクセス可能とする機能のことです。便利な機能なのですが日本語呼称の「依存性注入」で分かりにくくなってる気がしてます。

またASP.NETでは予想外に大きなコード記載が必要になるケースが時々有りました。例えばグリッドを配置してSQLクエリをマップすれば形はできるのですが、colspanを変えたい場合など特定のイベントハンドラに特殊な記述が必要なことなど有りました。

こんなことでASP.NETは簡易なプログラム作成は早くできるのですが、ある程度の規模となると製造量が見積りにくい感じが有ります。JSFはページも背後のJavaロジック（backingBeen）も最初は１から自分で書く必要が有るのですが、プロトタイプが幾つかできれば見積りし易いのではないかと思っています。

[BlueMoon]

私もJavaEEは参考書3冊読んでやっと分かってきた感じがしてます（J2EEの頃からですが）。実務で扱ってれば、もっとしっかり回答できるかと思うのですが済みません。

[argius]

なるほど。
ASP.NETは簡単に書ける反面、応用が利かない。JavaEEのほうが、最終的には、いわゆる「かゆいところに手が届く」ってことなのかな、と思いました。スコープは便利ですよね。

詳しい解説、ありがとうございました。

実務で扱っていないのにそこまで勉強されているんですね。素晴らしいです。
私は最近、机上の学習がおろそかになっているので、反省です...

Answer 9

支持する言語: Java
ライバル言語: C#
(最近は C# メインなので、支持しているかと言われると微妙ですが...)

自動プロパティ と LINQ は良いなーと思います！

Comments

[argius]

ありがとうございます。

C#の機能を2つだけ選んでJavaに取り込むとしたら、私も自動プロパティとLINQを選びます。特にLINQは、SQL使ってるとき、他の言語でもLINQできたらなー、といつも思います。

C#もはやく初心者レベルから脱したいんですけどね。