アカウント名:
パスワード:
Javaもnode.jsも使っていますが，適材適所で双方を使い分けるのが良いと思います
性能に関しては，まともなプログラマがコーディングすればJavaでもnode.jsでもそれなりの性能がでます．細かいところでは，セッションの生成はnode.jsとか，スループットはJavaとか色々ありますが，それらはケースバイケースで，どちらが良いとかは一概に言えません．
開発効率については大規模，特に複数人で開発をするなら Javaそれ以外，特に一人/数日で開発が終わるようなものは node.js が良いと思います
たとえば，Javaだと，Javadocやアノテーションがあり大規模なものを複数人で開発する際はとても効率良いです反面，小規模なものを短期間で作る場合だと，Javaでクラス設計とかアノテーションをいちいちやっても，工数の無駄でしかありません．自己満足で終わるだけです．
小規模だったアプリが大規模になるパターンは往々にしてあるので、小規模だから○○と分けるのはあまりよろしくないかと思います。初めは小規模だったのでrailsで作っていたのですが、利用者数が拡大するにつれ要望が増え、だんだんと規模が大きくなり、railsではつらくなったという事例を目の当たりにしたことあります
それ何てTwitter
規模が大きくなったら，お金を掛けて，良いエンジニア雇って，システム組み直せば良いのでは？
要望増えて，規模が大きくなれば，それはもう別システムでしょう．
今は大規模開発に耐えうるよう静的型付けに対応させたTypeScriptがあるので開発規模による適正の差はさらに縮まりつつあるさらにJavaは関数が第一級関数でないため最近の関数型の潮流に追随できない致命的とも言える欠点があるそれでもJavaは実績と信頼感が大きいので当分需要は減らないだろうが長期的には言語の進化から取り残されシェアを失うだろう
＞静的型付けに対応させたTypeScriptがあるのでそういうのが非標準で、似たようなのが出ては消えていくのが痛いんだよ。
長期サポートする（つもりの）製品には採用しにくい。＃長期サポートするつもりだったけど、短期でサービスが打ち切られる方が可能性は高いけどさ（涙）
＞長期的には言語の進化から取り残されシェアを失うだろうそういう根拠のない個人的願望を書き連ねるのはいかがなものか。
> そういうのが非標準で、似たようなのが出ては消えていくのが痛いんだよ。TSは「ESの先取り」言語なんだが。HaxeやCoffeeScriptやJSXみたいなクソ言語と一緒にされては困るんだよねぇ。
たまにはActionScriptちゃんのことも思い出してあげて下さい
型注釈の構文は多分変わらないだろうけど、TSの型注釈はあくまでコンパイル時にエラーを出すもので、ES7の型注釈はランタイムにエラーを出すものというのが、どうしても差を生む。特にJSは型としてのクラスが存在しないから、プリミティブの判定はまだ容易だとしても、様々オブジェクトの型をどういう風に区別するかは難題。最も現実的に考えると、如何なるオブジェクトもObjectとしてしか型注釈できないようになるだろう。もしくはJSにクラスベースモードを作るSaneScript/SoundScript構想も現時点で有力だが、それはそれでTSとは異なるものになる。
>Javaは関数が第一級関数でないJava8「」
8ではかなり改善されてScalaっぽくなってます、7までに慣れた人は戸惑うかもしれません。
int sum = Stream.of(1, 2, 3, 4, 5, 6, 7, 8, 9, 10) .filter(e -> {return e >= 5;}) .reduce(Integer::sum).get();
System.out.println(sum);//45
Java8は各日に次の世代の基準点ですよね。あるJava8前提のフレームワークとか最初に見たときはほんとに動くんかいなと思いました。
今のところ自分の範囲では第一級関数であるかどうかは必須条件では無いのでこれがないと致命的欠陥であるという意見は不思議ではあります。書き方面倒でも今までなんとかなってたじゃんとか関数型言語にすればすべての問題が解決するわけでもないじゃんと思います。ま、ケースバイケースということで。
「関数型の機能を取り入れればすべての問題が解決する」なんて誰も言っていないのに、「関数型の機能を取り入れてもすべての問題が解決するわけじゃない」という人が多いのはなぜなんだろうか。
関数型言語の機能は必須じゃないよ。もちろんなくてもコーディングはできる。オブジェクト指向言語の登場以前、クラスやインターフェイスがなくても何とか開発できていたように。ただオブジェクト指向が登場して、オブジェクト指向はすべての問題を解決するわけじゃないけど、すこし開発が楽になった。関数型の機能が導入されて、関数型はすべての問題を解決するわけじゃないけど、また少し開発が楽になる。それだけの話だ。勝手に銀の弾丸に祀り上げて勝手に失望してはいけない。
他の人も言っているけど、「適材適所」「ケースバイケース」「状況に応じて」はとても聞こえの良い言葉だし、間違ってはない。ただ、それは「高度の柔軟性を維持しつつ臨機応変に [nicovideo.jp]」というのと同じくらい具体性がない。何の指針にもならないし、何も言っていないも同然だ。
「関数型の機能を取り入れればすべての問題が解決する」わけじゃないかもしれませんが「関数が第一級関数でないことは致命的欠陥」らしいですよ。
> 何の指針にもならないし、何も言っていないも同然だ。
だから「開発者のマインドシェアを奪い合うJavaとNode.js」ってのは変な話でJavaとNode.js のどちらが良いかなんて議論しなくていいじゃん，って言ってるんですが…
第一級関数の市場価値は再帰と高階関数を使いこなせる開発者を基準に開発できるかによるでしょうね要するにプログラマの平均水準次第です
しっかし無駄が多いなぁStreamは
実際にはSystem.out.println( IntStream.range(1,11) .filter(e->e>=5) .sum());で終わり。なんでこんな冗長記述にしたのか謎。
なお静的型はES7以降のJavaScriptで対応予定となっているTypeScriptは未来のJavaScriptの先行実装として作られているため仮にMSの開発が終了したとしても支障なく開発を継続できるのも強みである
優秀なプログラマなら何を使っても優秀な結果を出すだろうから問題にならない。問題になるのは大多数の普通の(優秀でない)プログラマの場合だから、その前提で議論しないと意味がないと思う。外注に出す場合、名指しや選り好みはできないわけですし。自分が担当したプログラムを墓場まで持っていくつもりがないなら、後々のことも考えなくちゃならない。故人の趣味ならいいけど、職業となると色々制約がついて回りますよね。
優秀なプログラマのただでさえ高い生産性を最大化することは企業利益に直結する例えば優秀なプログラマを揃えた新規開発に今更VBを強制する企業は間違いなく無能だろう開発競争するまでもなく人材を失って倒産する
優秀でないことを前提にしても全体として成長が停止した世界まで前提にするのはあまりに非生産的に過ぎるいずれは高階関数くらい使えるのが普通になるのを見越して言語を整備しなければならないそれが今のJava8進歩を否定する老害になってはいけない
高階関数を扱える程に複雑化した言語が、本当に望まれているのか怪しいところ。進歩だと喚きつつ肥大化＆複雑化した挙句、シンプルな実装に回帰するのはコンピュータの歴史が証明している。
高階関数は既存機能の特化でなく異なるパラダイムの基本機能なのでそれにはあたらない
高階関数を複雑だと思うかどうかで、その人のコーディング能力が推し量れるな
高階関数はごくシンプルな道具だし、プログラミングの基礎中の基礎にすぎない。でも、高階関数を理解していない人ほど、高階関数は複雑で扱うのが難しい機能だと思い込んで恐れている
Cですら高階関数（もどき）が標準関数に現れますしね。qsortとかsignalとか。
> 高階関数を扱える程に複雑化した言語
え？単純化してシンプルな実装に回帰した結果が高階関数なんですが？どこが複雑なんでしょう？
java8のクロージャーが実際に何をクローズしているかすぐ答えらえる？
VBAやVB6と書かずにVBで一まとめにして切り捨てているあたり、貴方が立派な老害になろうとしていると思われるのだが
まあ今でも.NETでC♯じゃなくてVBを強制するなら人は出て行くってのには同感だが
> VBAやVB6と書かずにVBで一まとめにして切り捨てているあたり、貴方が立派な老害になろうとしていると思われるのだが
煽るねえ。そこのコダワリをもうちょっと詳しく話してごらん？なぜこのコンテキストでVBAとVB6を区別する必要があるのか？どうせくっっっっっだらなさすぎるコダワリなんだろうけどｗ
> 故人の趣味ならいいけど、
不慮の事故とかありますからね。仕事でやるなら前任者がいなくても引き継ぎできる環境を… という話？
大規模、大人数なら静的型付っていうのがよくわからない。あとオブジェクト指向は大規模でないと無駄とかいう意見も見ることがあるけど、ああいうのもよくわからない。一人で数十行、数百行程度のコードを書くときにも、静的型やオブジェクト指向でクラス書いたほうがずっと楽に感じる。
> 一人で数十行、数百行程度のコードを書くときにも、静的型やオブジェクト指向でクラス書いたほうがずっと楽に感じる。
http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html [ariel.com.au]のSeasoned professionalぐらいの人ですね．わかります．
簡単な例だと，例えば，画面に文字を出力するプログラムを書くとしましょう．sh なら一行
echo "hello!"
で済みます．
java だと５行です．この５行中の４行，つまり80%は無駄だと思いませんか？
public class Hajimete { public static void main(String[] args){ System.out.println("hello!"); }}
そりゃ、そんな都合のよい例を取り出せばJavaは無駄でしょう。でも、数百行のシェルスクリプトならJavaの方が遥かに楽です。
で、元のJavaScriptとJavaならって話になりますが、複数のクラスが登場しないような、シンプルな処理ならJSの方が楽でしょうよ。でも正直、いくつもの役割が生じるような、そして使い捨てでないソースであれば、Javaのような言語で書きたいです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
大規模ならJava，それ以外はnode.js (スコア:4, 興味深い)
Javaもnode.jsも使っていますが，適材適所で双方を使い分けるのが良いと思います
性能に関しては，まともなプログラマがコーディングすれば
Javaでもnode.jsでもそれなりの性能がでます．
細かいところでは，セッションの生成はnode.jsとか，スループットはJavaとか色々ありますが，
それらはケースバイケースで，どちらが良いとかは一概に言えません．
開発効率については
大規模，特に複数人で開発をするなら Java
それ以外，特に一人/数日で開発が終わるようなものは node.js が良いと思います
たとえば，Javaだと，Javadocやアノテーションがあり
大規模なものを複数人で開発する際はとても効率良いです
反面，小規模なものを短期間で作る場合だと，
Javaでクラス設計とかアノテーションをいちいちやっても，工数の無駄でしかありません．自己満足で終わるだけです．
Re:大規模ならJava，それ以外はnode.js (スコア:3, 参考になる)
小規模だったアプリが大規模になるパターンは往々にしてあるので、小規模だから○○と分けるのはあまりよろしくないかと思います。
初めは小規模だったのでrailsで作っていたのですが、利用者数が拡大するにつれ要望が増え、だんだんと規模が大きくなり、
railsではつらくなったという事例を目の当たりにしたことあります
Re: (スコア:0)
それ何てTwitter
Re: (スコア:0)
規模が大きくなったら，お金を掛けて，良いエンジニア雇って，システム組み直せば良いのでは？
要望増えて，規模が大きくなれば，それはもう別システムでしょう．
Re:大規模ならJava，それ以外はnode.js (スコア:1)
今は大規模開発に耐えうるよう静的型付けに対応させたTypeScriptがあるので開発規模による適正の差はさらに縮まりつつある
さらにJavaは関数が第一級関数でないため最近の関数型の潮流に追随できない致命的とも言える欠点がある
それでもJavaは実績と信頼感が大きいので当分需要は減らないだろうが長期的には言語の進化から取り残されシェアを失うだろう
Re: (スコア:0, 荒らし)
＞静的型付けに対応させたTypeScriptがあるので
そういうのが非標準で、似たようなのが出ては消えていくのが痛いんだよ。
長期サポートする（つもりの）製品には採用しにくい。
＃長期サポートするつもりだったけど、短期でサービスが打ち切られる方が可能性は高いけどさ（涙）
＞長期的には言語の進化から取り残されシェアを失うだろう
そういう根拠のない個人的願望を書き連ねるのはいかがなものか。
Re: (スコア:0)
> そういうのが非標準で、似たようなのが出ては消えていくのが痛いんだよ。
TSは「ESの先取り」言語なんだが。
HaxeやCoffeeScriptやJSXみたいなクソ言語と一緒にされては困るんだよねぇ。
Re: (スコア:0)
たまにはActionScriptちゃんのことも思い出してあげて下さい
Re: (スコア:0)
型注釈の構文は多分変わらないだろうけど、TSの型注釈はあくまでコンパイル時にエラーを出すもので、ES7の型注釈はランタイムにエラーを出すものというのが、どうしても差を生む。
特にJSは型としてのクラスが存在しないから、プリミティブの判定はまだ容易だとしても、様々オブジェクトの型をどういう風に区別するかは難題。
最も現実的に考えると、如何なるオブジェクトもObjectとしてしか型注釈できないようになるだろう。
もしくはJSにクラスベースモードを作るSaneScript/SoundScript構想も現時点で有力だが、それはそれでTSとは異なるものになる。
Re: (スコア:0)
>Javaは関数が第一級関数でない
Java8「」
8ではかなり改善されてScalaっぽくなってます、7までに慣れた人は戸惑うかもしれません。
int sum = Stream.of(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
.filter(e -> {return e >= 5;})
.reduce(Integer::sum).get();
System.out.println(sum);//45
Re: (スコア:0)
Java8は各日に次の世代の基準点ですよね。
あるJava8前提のフレームワークとか最初に見たときはほんとに動くんかいなと思いました。
今のところ自分の範囲では第一級関数であるかどうかは必須条件では無いのでこれがないと致命的欠陥であるという意見は不思議ではあります。
書き方面倒でも今までなんとかなってたじゃんとか関数型言語にすればすべての問題が解決するわけでもないじゃんと思います。
ま、ケースバイケースということで。
Re:大規模ならJava，それ以外はnode.js (スコア:1)
「関数型の機能を取り入れればすべての問題が解決する」なんて誰も言っていないのに、
「関数型の機能を取り入れてもすべての問題が解決するわけじゃない」という人が多いのはなぜなんだろうか。
関数型言語の機能は必須じゃないよ。もちろんなくてもコーディングはできる。
オブジェクト指向言語の登場以前、クラスやインターフェイスがなくても何とか開発できていたように。
ただオブジェクト指向が登場して、オブジェクト指向はすべての問題を解決するわけじゃないけど、すこし開発が楽になった。
関数型の機能が導入されて、関数型はすべての問題を解決するわけじゃないけど、また少し開発が楽になる。それだけの話だ。
勝手に銀の弾丸に祀り上げて勝手に失望してはいけない。
他の人も言っているけど、「適材適所」「ケースバイケース」「状況に応じて」はとても聞こえの良い言葉だし、間違ってはない。
ただ、それは「高度の柔軟性を維持しつつ臨機応変に [nicovideo.jp]」というのと同じくらい具体性がない。
何の指針にもならないし、何も言っていないも同然だ。
Re: (スコア:0)
「関数型の機能を取り入れればすべての問題が解決する」わけじゃないかもしれませんが「関数が第一級関数でないことは致命的欠陥」らしいですよ。
Re: (スコア:0)
> 何の指針にもならないし、何も言っていないも同然だ。
だから「開発者のマインドシェアを奪い合うJavaとNode.js」ってのは変な話で
JavaとNode.js のどちらが良いかなんて議論しなくていいじゃん，って言ってるんですが…
Re: (スコア:0)
第一級関数の市場価値は再帰と高階関数を使いこなせる開発者を基準に開発できるかによるでしょうね
要するにプログラマの平均水準次第です
Re: (スコア:0)
しっかし無駄が多いなぁStreamは
Re: (スコア:0)
実際には
System.out.println(
IntStream.range(1,11)
.filter(e->e>=5)
.sum());
で終わり。
なんでこんな冗長記述にしたのか謎。
Re: (スコア:0)
なお静的型はES7以降のJavaScriptで対応予定となっている
TypeScriptは未来のJavaScriptの先行実装として作られているため
仮にMSの開発が終了したとしても支障なく開発を継続できるのも強みである
Re: (スコア:0)
優秀なプログラマなら何を使っても優秀な結果を出すだろうから問題にならない。
問題になるのは大多数の普通の(優秀でない)プログラマの場合だから、その前提で議論しないと意味がないと思う。
外注に出す場合、名指しや選り好みはできないわけですし。
自分が担当したプログラムを墓場まで持っていくつもりがないなら、後々のことも考えなくちゃならない。
故人の趣味ならいいけど、職業となると色々制約がついて回りますよね。
Re: (スコア:0)
優秀なプログラマのただでさえ高い生産性を最大化することは企業利益に直結する
例えば優秀なプログラマを揃えた新規開発に今更VBを強制する企業は間違いなく無能だろう
開発競争するまでもなく人材を失って倒産する
優秀でないことを前提にしても全体として成長が停止した世界まで前提にするのはあまりに非生産的に過ぎる
いずれは高階関数くらい使えるのが普通になるのを見越して言語を整備しなければならない
それが今のJava8
進歩を否定する老害になってはいけない
Re: (スコア:0)
高階関数を扱える程に複雑化した言語が、本当に望まれているのか怪しいところ。
進歩だと喚きつつ肥大化＆複雑化した挙句、シンプルな実装に回帰するのはコンピュータの歴史が証明している。
Re: (スコア:0)
高階関数は既存機能の特化でなく異なるパラダイムの基本機能なのでそれにはあたらない
Re: (スコア:0)
高階関数を複雑だと思うかどうかで、その人のコーディング能力が推し量れるな
高階関数はごくシンプルな道具だし、プログラミングの基礎中の基礎にすぎない。
でも、高階関数を理解していない人ほど、高階関数は複雑で扱うのが難しい機能だと思い込んで恐れている
Re: (スコア:0)
Cですら高階関数（もどき）が標準関数に現れますしね。
qsortとかsignalとか。
Re: (スコア:0)
> 高階関数を扱える程に複雑化した言語
え？単純化してシンプルな実装に回帰した結果が高階関数なんですが？どこが複雑なんでしょう？
Re: (スコア:0)
java8のクロージャーが実際に何をクローズしているかすぐ答えらえる？
Re: (スコア:0)
VBAやVB6と書かずにVBで一まとめにして切り捨てているあたり、貴方が立派な老害になろうとしていると思われるのだが
まあ今でも.NETでC♯じゃなくてVBを強制するなら人は出て行くってのには同感だが
Re: (スコア:0)
> VBAやVB6と書かずにVBで一まとめにして切り捨てているあたり、貴方が立派な老害になろうとしていると思われるのだが
煽るねえ。
そこのコダワリをもうちょっと詳しく話してごらん？なぜこのコンテキストでVBAとVB6を区別する必要があるのか？
どうせくっっっっっだらなさすぎるコダワリなんだろうけどｗ
Re: (スコア:0)
> 故人の趣味ならいいけど、
不慮の事故とかありますからね。
仕事でやるなら前任者がいなくても引き継ぎできる環境を… という話？
Re: (スコア:0)
大規模、大人数なら静的型付っていうのがよくわからない。
あとオブジェクト指向は大規模でないと無駄とかいう意見も見ることがあるけど、ああいうのもよくわからない。
一人で数十行、数百行程度のコードを書くときにも、静的型やオブジェクト指向でクラス書いたほうがずっと楽に感じる。
Re:大規模ならJava，それ以外はnode.js (スコア:1)
> 一人で数十行、数百行程度のコードを書くときにも、静的型やオブジェクト指向でクラス書いたほうがずっと楽に感じる。
http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html [ariel.com.au]
のSeasoned professionalぐらいの人ですね．わかります．
簡単な例だと，例えば，画面に文字を出力するプログラムを書くとしましょう．sh なら一行
echo "hello!"
で済みます．
java だと５行です．この５行中の４行，つまり80%は無駄だと思いませんか？
public class Hajimete {
public static void main(String[] args){
System.out.println("hello!");
}
}
Re: (スコア:0)
そりゃ、そんな都合のよい例を取り出せばJavaは無駄でしょう。でも、数百行のシェルスクリプトならJavaの方が遥かに楽です。
で、元のJavaScriptとJavaならって話になりますが、複数のクラスが登場しないような、シンプルな処理ならJSの方が楽でしょうよ。
でも正直、いくつもの役割が生じるような、そして使い捨てでないソースであれば、Javaのような言語で書きたいです。