2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

【PHP,Python】スクリプト,バトルロワイヤル36【Perl,Ruby】

1 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
構文エラーに悩まされてる程度だから
一行書いて、実行(正確には構文ミスしてないか調べる)が
必要なんだろうね。

>>998
試行錯誤開発ならスクリプト言語じゃなくても出来るだろ。

どうせお前の言ってる試行錯誤って設計レベルではなく
コードを一行一行実行しなくちゃならない
正しく構文かけたかな?の試行錯誤だろw

そんな行単位で試行錯誤することなんてねーよ。
試行錯誤するときはクラスレベルだろ。

2 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
REPLは初めて使うような関数の動作を見るとか、
簡易なサンプルを書くときに使うもんだろ。

あんなので開発や試行錯誤するやつなんていねーよ。

どんだけプログラミング=関数の動きを見るだけのやつなんだ?w
自分で関数書けよ。

3 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
途中で止まって再開ができるのは構文エラーぐらいだしな。
構文エラーで悩まされる確率が高い時点で初心者だろうな。

間違って10かける所を100かけてしまったら、
100で割って再開でもするのか?

データベースを間違って更新してしまったら、
修正して再開すんのか?

バグってのは普通こういうものだ。
途中で止まって再開なんて出来やしない。

REPLでそんな非効率な開発なんかしてねーで
テストコード書いて綺麗な状態から
何度でも実行できるようにしろよ。

4 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
構文エラーで悩まされてるに違いない!という妄想に囚われてる奴に何を言っても無駄
静的言語ではこうやるし、スクリプト言語だとしても他のやり方はありえない
という決め付け、思考停止、REPLの存在否定、IDE至上主義
初めから議論する気はないんだ

5 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
スクリプト言語スレに定期的に現れるスクリプトの存在自体のdis
あんたが大将。スクリプト言語は糞だ。だから出ていってくれないかな
なんだこのスレは?この>>1は?キチガイ荒らしは常に頭が逝ってる

6 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
LLスレ時代から何度キチガイ荒らしにスレを潰されただろう。乱立されただろう
プログラミングのプの字も知らないカスに

7 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>1
てめぇふざけんなよ
スレ建てたことないのかよ?

8 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>1の時点で仕事を果たさない。感情的になって自分こそが正しいと発狂してるだけ
他人から見たら何を言ってるのか一切理解不能
削除依頼出してこいよ。ま、いつもの乱立連投キチガイ荒しのように立てっぱなしだろうがな

9 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>4
じゃあ、使ってる言語とREPL。
そして複数のファイルにわかれて複数の関数とクラスを
使ってるレベルのプログラムをREPLで効率的に
開発できる例を見せてくれよ。

間違ってコードを実行した時、どうリカバリーすんの?

それがないと説得力がないだろ。

10 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>9
じゃあ、じゃなくて削除依頼出しこいよキチガイ

11 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
いや成果物はファイルなのだからエディタにソースコードはあるし
その関数をコンパイルなしに試せる、試し続けられることがメリットだろ
REPLの使い方おかしくね。なにが「どうリカバリすんの?」だよ馬鹿すぎる
削除依頼出してこいクズ

12 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>11
REPLで試行錯誤して開発するらしいよ。

使い方間違ってるよね。

REPLは単に実験するための道具なのに。


単純にテキストエディタのほうがREPLよりも高機能。
それだけで、そんな作成して実行して途中で止まったとこで
また書いて、続きを実行とかいう、
超非効率なやり方をするやつはいない。

13 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
夏休み終了まで、あとたったの40日だから我慢しろお前ら

14 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>12
その実験環境があるからこそ、試行錯誤的な開発が容易になるんだろ
なんで片一方しか使わない前提で「リカバリどうすんの?」とか言ってんの?池沼か?
削除依頼出してこいクズ

15 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>14
試行錯誤的な開発は、
REPLでやるものではないという話し。

実験っていい方が悪かったか?
単に知らない関数の動きを調べるだけだよ。

マニュアル読むのと変わらん。
そんなのは試行錯誤じゃない。

試行錯誤というのは自分の書いたコード、および設計を試行錯誤するもんだ。
関数の使い方を試行錯誤するとかどんだけレベルが低いんだよw

16 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
お前の言葉の定義とか誰も知らない
試行錯誤することを試行錯誤と呼ぶし、それはREPLで効率的に出来る
削除依頼出してこいよクズ

17 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>14
> 前提で「リカバリどうすんの?」とか言ってんの

しょうがないだろ。

だって、書いて実行して、エラーで止まって
続きを書いて、実行を再開するのが、
テストコードを最初から再実行するよりも
効率いいと言ってるバカが居るんだから。

エラーで止まって再開できるのは、構文エラーのみ。
論理エラー、つまり実行したら想定したら違う状態になる。
不正な状態から再実行するにはリカバリが必要なんだよ。

どう考えてもテストコード書いて再実行するほうが
効率がいいに決まってるじゃないか。

18 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>16
だったらお前の定義の試行錯誤を書くべきだろ。

早くREPLで試行錯誤の例を見せてくれ
もちろん関数の使い方を調べる以外のな。

それがファイルに書いて最初から再実行するよりも
効率がいいかどうか判断してやるから。


REPLは関数の使い方を調べるツール
試行錯誤をするツールではない。

19 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>17
それはそういう使い方しか想定してないからだろ
REPLは常に起動して、
しかも自分が編集中の複数のライブラリと自作ファイルを常にすりあわせて実験できる
これが試行錯誤じゃなくて一体なんなのか
削除依頼出してこいクズ

>>18
REPLで関数の使い方を実験して
上手くいったコードを実装に使う
それのどこが試行錯誤的じゃないんだ?
REPLがなければいちいちコンパイルすることだぞ
マニュアルを読むだけじゃできない
削除依頼出してこいクズ

20 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
REPLは試行錯誤じゃないという日本語的にも間違ったオレオレ定義のもとで勝手に糞スレ立てないで欲しいんだよね
さっさと削除依頼出してこいクズ

21 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
いまどきREPLなんて無いのJavaくらいなのに
何で使った事無いレベルで無知なんだろう
あ…(察し)

22 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
静的言語のREPL使ったことないやつキタ━(゚∀゚)━!
REPL向きの言語というものがあるということがなんで理解できないんだろう
あ、察し!

23 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
REPLは往々にして短いコードを実験するから
簡単な処理ならコードを圧縮できる関数型言語は静的言語でもREPLは使える
C#とかC/C++のREPLを常用してる奴なんていないだろうな

24 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
> 早くREPLで試行錯誤の例を見せてくれ
> もちろん関数の使い方を調べる以外のな。

マニュアルで関数の使い方を調べて
呼び出すだけのドカタ仕事しかしてないと、
こういう発想しか出てこないんだな

25 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
関数の使い方はExcelで決まっているもの
関数の中身はコード書く前から一から十までExcel上で決まりきっているもの
これがドカタですよ

26 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>1
優秀な1だな
どうすればスレが盛り上がるか心得ているな

27 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
キチガイの振りしてるつもりなんだろうけど、正真正銘、ただのキチガイなんだよね

28 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>17
TDD知らないの?

29 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
いやTDDならむしろ>>17の言ってることが正しいと思うが

30 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
実行中に止めてコード書き直すのとTDDがどうつながるのか

31 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
副作用のある関数ばっか作ってる馬鹿には無理

32 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
んなことオブジェクト指向スクリプトのスレで言われても

33 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>32
ここってオブジェクト指向のスクリプトのスレだったのか。
まあshやsed、awkの話題をここでするのは違うか。

34 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>31
副作用がなんの関係があんの?

構文エラーで止めてコード修正して進むメソッドは、
関数を最初から再開しないってことなんだよ。

35 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
構文エラーで止めるってそもそもなんなん

[].each do |x|

[]...eachd o|x|

とかなってたら、コンパイル(スクリプトの)時にエラー出るから最初の一行目から実行されない

36 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>35
驚愕的なのは、スクリプトでコンパイルってなんだよ?
コードのパースは実行に含まれるって言ってる奴がいるってこと。

37 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>34
> 副作用がなんの関係があんの?


> 不正な状態から再実行するにはリカバリが必要なんだよ。
馬鹿がリカバリ云々言ってるからさ

38 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>37
話わかってないんじゃね?

構文エラーで止まった所で修正して、
続きを実行する開発方法が
効率がいいとか言ってる馬鹿がいるから
そいつに言ってるんだよ。

副作用全く関係ない。
副作用がない関数であったとしても、
構文エラーはともなく、間違ったコードを実行してしまったら
止まった所からリカバリなしに実行はできない。

俺はそんなアホな開発方法なんかやらないで、
テストを再実行しろと言ってる。
関数をはじめから実行しなおせと言ってる。

39 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
いや普通にテストもしますが?
インタープリタでの実験による試行錯誤を使った開発が
いちいちコンパイル実行を繰り返すより楽という至極当然の事実を述べてるだけ
何が最初から最後までテストだよwアホすぎる
削除依頼出してこいクズ

40 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
一気にテストというのは、静的言語ではそうせざるを得ないというだけ
REPLはもうひとつ前の段階として使える

構文エラーで止まったところで修正して云々という妄想は馬鹿すぎて
削除依頼出してこいクズとしか言えないけど

41 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
こんな糞みたいな>>1はこの板でも唯一無二、この馬鹿だけw
どう自己評価してるんだろう。死にたくならないのだろうか

42 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
どうすんのこのクソスレ?

43 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
>>38
まず日本語を喋ってくれ、構文エラーで〜構文エラーはともかく〜(どっちだよ)
テストを再実行しろ〜(は?何が再なんだ?)
自分が勝手に想定してるこっちに全く見えない前提が多すぎて意味不明
削除依頼出してこい

44 :デフォルトの名無しさん:2013/07/21(日) NY:AN:NY.AN
削除依頼を出せと言ってる人へ。

俺は出しません。
以上

45 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
>>38
まったく支離滅裂で何を言ってるのか意味不明なんだが、
何をリカバリしろって言ってるんだ?
お前自分で何書いてるか意味分かってないだろ。

46 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
>>45
何をリカバリするかわかんないの?

間違ってコードを実行した時、
続きから実行することは出来ないんだよ。

47 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
「間違ってコードを実行」って何w

48 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
>>1
間違った開発をしてる仮想敵を作ってオラオラ俺のやり方が正しいぞ!と言われてもね
まずお前のやり方って何なのかさっぱり分からんし
仮想敵はお前の都合のいいように間違ってくれてるだけのオナニーショーだし
ちゃんと指摘されたことは受け入れろよ
なんで最初に言った妄想を延々と繰り返し続けるんだ?
完全に会話が噛み合ってないわ
削除依頼出してこいクズ

49 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
REPLでの開発が効率的だってさ、
書いてエラーで止まるから
また続きを書けばいいとのこと

そんなことができるのは構文エラーだけ。
実際は論理エラーで間違った計算を実行してしまうのだから
都合のいい場所で止まったりしない。

だからREPLでの開発は非効率なのだ。

50 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
REPLとは全く無関係な問題でREPLを叩いてて頭大丈夫かと本気で心配になる
さっさと削除依頼出してこい池沼

51 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
都合のいいところで止まるも何も、評価するたびに表示して止まるんだが
REPL使った事無い上に、REPLが何の略かすら分かってないのか

52 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
Ruby Enter Prise Language(松江)

53 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
REPLで開発してる奴なんていないだろ

54 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
ム板にIDはいらないかもしれないけど
末尾!つけてもらったほうがよくね?

もしかして…とか疑ってしまう

55 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
末尾! は既に付いている
そこから分かることは海外産は皆無に等しいという事実

56 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
Perlは最早Pythonの劣化

57 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
Windowsも標準で、もうちょいスクリプト言語いれてくれないかな?
初っぱなから、ある程度使えるlinux、mac とでのマルチプラットホームなやつ
その方向には向かってなさそうだけどね。

58 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
Windowsはプログラミングしない人のためのOSだから

59 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
>>57
Linuxはともかく、MacにプリインストールされてるPythonは
OSバージョンによってバージョンが全然違うから共通プラットフォームとしては当てにならないし
結局自分で好きなバージョンをインストールしたらしたで元のと競合したりしてトラブルの元で開発者にはウザがられてるだろ

60 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
pyenvじゃ駄目なのか?

61 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
>>57
今時、クライアントはLinuxもMacもその方向には向かってないだろ
マルチプラットフォームはブラウザでやれという流れ

62 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
ブラウザも種類とバージョンが色々あってウゼーけどな

63 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
>>61
なに言ってるの?
Macは開発マシンとして有望だし。

64 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
Macなら開発マシンといってもWebかスマホだけどな
どっちにしろ開発者しか使わないので、別途インストールで構わない

65 :デフォルトの名無しさん:2013/07/22(月) NY:AN:NY.AN
Macって標準のRubyが1.86とかだから、本気で開発するなら自分でインストールしないといけないけどなw

66 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
Macports vs Homebrew vs Fink
の地味な戦い

67 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
>>65
Linuxもそうですが。

68 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
古っ

69 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
コマンドライン一発でインストールできるのに
それすら大変というWindows厨

70 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
WindowsはインストーラでインストールするかZIPを展開してパス等を設定するかなどが必要。
32bit/64bit版の選択が必要で、ものによってはVCでビルドしたものとmingwでビルドしたものとかが
存在してわかりづらい。

71 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
まあ素人は単独でPHPなんかインストールはしないだろうが、PHPのWindowsバイナリはこんな具合。
http://windows.php.net/download/
いろいろ注意書きを読む必要あり。
yum install phpでインストールできるLinuxとは大違い。

72 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
>>57
そこはマルチは無しで、HSPでも入れときゃ良いと思うが
スクリプト言語きっかけにして他のOSに興味でも持たれたらイカンから、windows命のHSPが良い

73 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
いまどきドザ厨とか全く面白くないから

74 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
WindowsさんにはPowerShellがあるじゃないですか
ShellとPerlとTclを煮つめた感じの…

75 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
Rubyの公式サイトは英語版の方がシンプル
WindowsならRubyInstallerをインストールするのがいいでしょう
としか書いてない
VC版とかCygwin版とか、余計なこと書いてないので迷わない

76 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
57だが

なんか、c#で、いい気がしてしまった。
でも、monoで作ったexe、linuxでもダブルクリック起動が、標準でできないんだよね〜。
愚痴った挙げ句、スレチな事書いてごめん。
でも、最近、python勉強中です。

77 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
Pythonで作ったところでOSに元々入ってるPythonは当てにならんし
GUIアプリとかだとどうせ色々必要なライブラリを追加しなきゃいけないから
結局のところLinuxやMacでもPythonランタイム丸ごとアプリに同梱することになるんだよね

78 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
ならねーよ馬鹿
pypiくらい調べてきてから書け

79 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
(赤面)

80 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
DropboxとかPython同梱してるよ
Blenderとかもそうだね
Pythonがアプリへの組み込みに適してるのは大きな売りの一つなのに
何を必死に否定する必要があるのか
クライアントに配るなら組み込んだほうが確実だろ

81 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
ポータビリティのためにPythonで作って
実行にシステムのPython使ったら台無しだ

82 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
それはPythonで作ったからじゃなくて
アプリがPythonを使うからだろw

83 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
私がPythonを使うのではありません
Pythonが私を使わせるのです

84 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
>>81
プラットフォーム依存部分は言語処理系が差異を吸収するのだから、
コード(スクリプト)のポータビリティは保証されるだろ

エンドユーザ向けアプリに処理系を同梱することの一体何が問題なんだ?

85 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
>>82
DropboxはPython製

86 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
>>84
同梱したほうがいいという意味で言ったつもりだった

87 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
しばらくして彼女から一枚の小包が送られてきた。

そこにはカタロニア語で書かれた一枚の手紙と、分厚いカタロニア語の辞書が入っていた。

88 :デフォルトの名無しさん:2013/07/23(火) NY:AN:NY.AN
まあ、Dropboxに同梱されたPython処理系のサイズって高々数10kb程度だし、
同梱しても問題無いサイズではある

89 :84:2013/07/24(水) NY:AN:NY.AN
>>86
読み直したらその通りで、自分の早とちりだった
ゴメン

90 :デフォルトの名無しさん:2013/07/24(水) NY:AN:NY.AN
>>88
もう、処理系は全部アプリに内蔵すればいいんだよ。

Linuxとか。

システム標準の処理系に依存して動くとか動かないとか
アホらしい。

91 :デフォルトの名無しさん:2013/07/24(水) NY:AN:NY.AN
パッケージ管理システムで管理された
大量のPython製ソフト(当然、処理系は同梱されない)があるのに、
ほんの極一部の例だけで結論を出されてもなぁ……

92 :デフォルトの名無しさん:2013/07/24(水) NY:AN:NY.AN
処理系同梱厨にコード書かせたら
同じ処理でも関数でまとめずに
コピペしまくるんだろうなぁ

93 :デフォルトの名無しさん:2013/07/24(水) NY:AN:NY.AN
一般ユーザーにPyPiとか本気で言ってるの?
だいたいそんなもの使いこなせるユーザーが対象なら元から入ってるPythonなんてそれこそどーでもいいだろ

94 :デフォルトの名無しさん:2013/07/24(水) NY:AN:NY.AN
一般ユーザを馬鹿にしすぎ
皆お前みたいなアホじゃないんだよコピペ厨

95 :デフォルトの名無しさん:2013/07/24(水) NY:AN:NY.AN
一般ユーザーに夢見すぎ
奴らは黒背景にプロンプトの画面見たら恐怖を感じるのに

96 :57:2013/07/24(水) NY:AN:NY.AN
それ以前に、英語がちょっとでも出てきたらアウトな人が多い。

97 :デフォルトの名無しさん:2013/07/24(水) NY:AN:NY.AN
だったらMind使えばいいじゃない

98 :デフォルトの名無しさん:2013/07/26(金) NY:AN:NY.AN
てst

99 :デフォルトの名無しさん:2013/07/27(土) NY:AN:NY.AN
Javaと連携できるイケてるスクリプト言語が欲しい

100 :デフォルトの名無しさん:2013/07/27(土) NY:AN:NY.AN
groovy

101 :デフォルトの名無しさん:2013/07/27(土) NY:AN:NY.AN
JavaはAPIがイケてないからなあ
正直、Java系スクリプトやScalaで簡潔に書けてるように感じるのは八割くらい
例外処理が強制されないからだと思う

102 :デフォルトの名無しさん:2013/07/27(土) NY:AN:NY.AN
groovyはイケてるの?

103 :デフォルトの名無しさん:2013/08/02(金) NY:AN:NY.AN ID:quhddWZK!
>>22
何それhaskell,ch, cint, pike?

104 :デフォルトの名無しさん:2013/08/03(土) NY:AN:NY.AN
あんまし書き込みなくなってきたね。
動的言語が終わったのか
プログラミング言語自体が安定期に入ったのか
2chから人いなくなったのか

105 :デフォルトの名無しさん:2013/08/03(土) NY:AN:NY.AN
> 動的言語が終わったのか
ここはスクリプト言語についての話であり、動的静的は関係ないからだろう
動的なコンパイル言語もあれば静的なスクリプト言語もあるし

106 :デフォルトの名無しさん:2013/08/03(土) NY:AN:NY.AN
ふつうに4行目だと思う
一部言語のスレに他言語の原理主義者を装った荒らしが棲みついたせいで
どの言語のユーザも不幸になってる気がする

107 :デフォルトの名無しさん:2013/08/03(土) NY:AN:NY.AN ID:QuQbJ8u+!
皆が時間の無駄だと悟って英文のmanual読んでるよ
それよか、RだよR。不毛な言語論争よか統計、機械学習の方が金になるって皆が悟ったんだよ。

108 :デフォルトの名無しさん:2013/08/03(土) NY:AN:NY.AN ID:QuQbJ8u+!
本当に必要だったものはfunctional PHPのようなモノだったんだ。きっと.
馬鹿馬鹿しい。本当に馬鹿馬鹿しい。皆、ocaml,erlangあたりに行ったんじゃないの?
今さらベンチャーがPython、Railsってだけでも何か負け犬臭しかしないじゃんね

109 :デフォルトの名無しさん:2013/08/04(日) NY:AN:NY.AN
日本語がお上手ですね

110 :デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
ゼア イズ オンリー 負け犬 スメル

111 :デフォルトの名無しさん:2013/08/05(月) NY:AN:NY.AN
負け犬 イズ ルーザー オア アンダードッグ

112 :デフォルトの名無しさん:2013/08/07(水) NY:AN:NY.AN
RubyとJavascriptを仕事で書いていて「ここが美しくないなー」とかブツブツ不満言っていたけど
先日PHPのソースコード見たら、すげー汚いと感じた。

$var->member

特にこれ。
Cの負の財産だから仕方ないけど。

113 :デフォルトの名無しさん:2013/08/07(水) NY:AN:NY.AN
どこが汚いのか不明

114 :デフォルトの名無しさん:2013/08/07(水) NY:AN:NY.AN
C言語はポインタと、そのデリファレンスをプログラマに明示的に扱わせるから、
単なるメンバ参照の "." と、それとは別に -> なんてのがあるわけだけど、
近代的な言語なら "." だけで良い(Javaとか)。

そういった所を深い考えもなしに -> とか書いてかっこいいとか思っちゃうのが
PHP の感覚なんだと思う。

115 :デフォルトの名無しさん:2013/08/07(水) NY:AN:NY.AN ID:AaxmOBE0!
mooseにinspireされたelkの解説を聞いてきたけど、何のメリットあるんだろう?
ライブコーディングでVimの補完なしにpythonのコードをガリガリとTypeErrorだとか
newbieの記憶には残らないものをガリガリと書いていたけど、あれなら適当な軽量IDEでも使った方がマシで、
わざわざ瑣末なことを記憶するだけの才能があるならperlで書いた方が速いだろとか思ったけれど思っても口にはしない。
そしてまぁ、本業なら何の迷いもなくJavaとPHPで良いね

116 :デフォルトの名無しさん:2013/08/07(水) NY:AN:NY.AN
>>114
ひょっとして、-> がシンタックスシュガーって知らないとか?

いやいや、まさかそんなアホがいるわけないか...

117 :デフォルトの名無しさん:2013/08/07(水) NY:AN:NY.AN
シンタクティックシュガーな。
(*ptr).hoge って書けばいい、って話だろ、カッコが要るだけで。

そもそも*が後置なら(乗算と区別できないから ^ とか別の記号にする必要があるけど)
ptr^.hoge で良かった、ということになるんだけどな。

118 :デフォルトの名無しさん:2013/08/07(水) NY:AN:NY.AN ID:AaxmOBE0!
syntactic sugar (シンタクティックシュガー、syntax sugar (シンタックスシュガー )とも)の訳語で、

119 :デフォルトの名無しさん:2013/08/08(木) NY:AN:NY.AN
というより文字列結合なんかに.を割り当ててるせいじゃないの?

120 :デフォルトの名無しさん:2013/08/09(金) NY:AN:NY.AN
わりとどうでもいい

121 :デフォルトの名無しさん:2013/08/09(金) NY:AN:NY.AN
>>117
> そもそも*が後置なら

ひょっとして、* が単項演算子と言うことを知らないとか?

いやいや、まさかそんなアホがいるわけないか...

122 :デフォルトの名無しさん:2013/08/09(金) NY:AN:NY.AN


123 :デフォルトの名無しさん:2013/08/09(金) NY:AN:NY.AN
ポインタが後置ならって有名な話じゃん
エキスパートCプログラミングで出てくる話だっけ

124 :デフォルトの名無しさん:2013/08/09(金) NY:AN:NY.AN
>>121
* は単項演算子であるという知識があるから
前置/後置という>>117の発想ができるわけで、
知らなかった、あるいはつい最近知ったばかりだったのが
>>121であると読めてしかたがない....

2項演算子の前置/中置/後置を指しているとも思えないし....

もしかして自虐的なギャグだったのか?
高度すぎてついていけない

125 :デフォルトの名無しさん:2013/08/09(金) NY:AN:NY.AN
レベルの違い過ぎる相手に噛みついて、壮絶に自爆って感じだなw

126 :デフォルトの名無しさん:2013/08/09(金) NY:AN:NY.AN
>>121 は後置単項演算子を知らないのか?
とすると ++ や -- が演算子だということがわかってない?
++ や -- を前置だけで使っていた?

127 :デフォルトの名無しさん:2013/08/09(金) NY:AN:NY.AN
++や--を持ち出すまでもなく、
「 . 」や「[]」が後置の単項演算子だしな。

128 :デフォルトの名無しさん:2013/08/09(金) NY:AN:NY.AN
別に.でも->でもどっちでもいいよね
array()みたいに7文字もあると[]の方がいいなと思うけどね

129 :デフォルトの名無しさん:2013/08/09(金) NY:AN:NY.AN
if文でどこからどこまでがが条件式で、どこからが真のときに評価されるブロックなのかを示すキーワード({とか:とかthen)を
わざわざ書かなくていい言語はメジャーな中ではRubyしかない。

130 :デフォルトの名無しさん:2013/08/09(金) NY:AN:NY.AN
へぇ
 それはすごいね
end

131 :.py:2013/08/09(金) NY:AN:NY.AN
へぇ
それはすごいね

132 :.py:2013/08/09(金) NY:AN:NY.AN
半角スペース消えた…

133 :デフォルトの名無しさん:2013/08/09(金) NY:AN:NY.AN
>>126
ああ ++ と -- は忘れてたわ。
まあ、オペランド変更するやつまで演算子と言うのはどうかと思わないでもないが。

>>125
> レベルの違い過ぎる相手に噛みついて、壮絶に自爆って感じだなw

それ、「[]」が後置の単項演算子だしな とか、言ってる奴に言ってやった方がいいぞ

単項演算子すら知らないみたいだしね (w

134 :デフォルトの名無しさん:2013/08/09(金) NY:AN:NY.AN
>>121が自爆だとしても、>>117も同レベルのアホ

そもそも論を語りたいなら、(演算子の前置/後置を持ち出すのではなく)
優先度で話を止めておくべきだった

例:そもそも演算子の優先度について . よりも * が高ければ(....略....)
  ^ptr.hoge で良かった、ということになるんだけどな。

ポインタ参照に後置の上矢印を使うのは、Pascalの流儀
ポインタ参照/メンバ選択に前置の演算子 ! と # を使うMLを含めて以下にまとめる

C:ptr->hoge または (*ptr).hoge /* -> は構文糖 */
Pascal:ptr^.hoge
ML:#hoge (!ptr) (* ! より # の優先度が高いのでカッコが必要 *)

>>117も(>>121と同じく)C言語の前置/後置を
つい最近知ったばかりだったと思われ

135 :デフォルトの名無しさん:2013/08/09(金) NY:AN:NY.AN
-> はシンタックスシュガーなのだ!

(だからなんなんだろう?)

136 :デフォルトの名無しさん:2013/08/09(金) NY:AN:NY.AN
別になんでもないだろ、引きずってるのはお前だけだし

137 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
この手の議論は、わりとどうでもいいという言葉に尽きるなw
クロージャとかクラスとかジェネレーターとかの議論の方がはるかに有意義だったな

138 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
http://news.mynavi.jp/news/2013/08/09/019/index.html

139 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
ruby

おいruby10位wwwwwwwwwwwwwwwwwwww

140 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>139
7月と何も変わってないけど。数字も読めないの?
http://news.mynavi.jp/news/2013/07/11/126/index.html

141 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
安定して低いって意味だろw

142 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
C、Java、C++、PHP、JSは悪い意味でこれからものこるだろうし
C#(VB)とPythonは総合的にRubyより上だし
Objective-Cは糞言語だけどiOS人気で残るし
Rubyの位置は別に驚きでもないわ。

Rubyのライバルは、ActionScript、CoffeeScript、TypeScript、Lua
終わったPerlあたりだし、今後も上がることはないけど。

2.0対応もろくに進んでないのに2.1が本当に年末に出たらまた多くのgemがゴミ化すんだろうなー

143 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>142
> C、Java、C++、PHP、JSは悪い意味でこれからものこるだろうし
これらが残ることがどう悪い意味なのか説明してくれるか?

C 組み込みなど低レベルな領域では必要不可欠
C++ ゲーム開発、処理系開発などパフォーマンス重視な用途では必要不可欠
Java クロスプラットフォームの大規模アプリケーションを作る場合は必要不可欠

PHP, JSは代替言語があるから消えてなくなって問題ないけど。

144 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
C# Windowsとの親和性が高く業務に強い 最近ではゲーム開発で大流行
Python 極めて汎用性が高い素直な優等生

Webしかない言語は敵が多くて大変だね

145 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>143
単純にC、Java、C++、PHP、JSついでにObjective-Cは言語として洗練されてないもしくは古過ぎる。
そんな言語でも分野によって必須だからこれからも残るんだけど、
コーダーとしてはそういう駄目な子で仕事するのはイライラするだけじゃね。

146 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
Cはあれでいいんだよ
低レベルな仕事をこなすという目的に対して極めて洗練されてる
他のは中途半端な失敗作だけど

147 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
> 単純にC、Java、C++、PHP、JSついでにObjective-Cは言語として洗練されてないもしくは古過ぎる。

言語マニアか・・・?

こういう奴に限って、
まともなものを何も作ってないんだよな。

148 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
実用上の明確な目的がある言語は美しい
老害COBOLだって固定長レコードを扱うことに特化した非常によくできた言語だ
コーダーがウンコだけど

149 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
いらいらするのなら自分の力で、
ライブラリとか作ればいいと思うんだがねぇ。

イライラの原因を自分で解決できないうちは
半人前だよ。

150 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>147
自爆兄貴オッスオッス!

151 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
まーた意味のないくだらないレスをつけるw

152 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>143
>PHP, JSは代替言語があるから消えてなくなって問題ないけど。

JavaScriptは「ブラウザ向けに限れば」標準規格化されて盤石の位置にあると思う
言語仕様で問題があり多くの派生言語は生まれているが、JSそのものは必要不可欠
ただし、サーバサイドおよび汎用言語としては、存在価値を見いだすのは難しい


>144
>Python 極めて汎用性が高い素直な優等生

それにもかかわらず、Webだけは適応に失敗したという矛盾w
それにもかかわらず、ワンライナーが苦手で対話型プログラミングには不適という矛盾w


>>146
Cを置き換えるような言語は、今後も登場しないのではないかと思う


>>148
事務処理向けDSLと見れば、今でもCOBOLは優秀な言語だろね

153 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
サーバーサイドでも今はnode.jsが伸びてきてるが

154 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
PHPはWordpressしか使えないへっぽこWebデザイナーには必要不可欠

155 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
node.jsが伸びてる理由ってなんでなんだろう
jsのシングルスレッド云々とかが何かしら奇跡的にサーバーサイドと相性良かった
まさかな

156 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
言語がエレガントに書けるかどうかなんてどうでもよくて
何が出来るかとか、インフラとして利用価値が高いとかの方が
よっほど意味があると思うんだよな
そう言う意味ならC言語の代替は無いしJavaの代替も無い
JavaScriptの代替も無いし、
PHPと他のライト言語と出来ることの差も無い
言語仕様の些細な差にこだわる奴(自分で言語を設計してるわけでも無いくせに)
ってのは無能にしか見えないね

157 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
全然どうでも良くはない
実際jsにクロージャがなかったら今の栄光はない

158 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
うん、クロージャの存在は言語設計上の判断として大きいね
実際、「極めて汎用性が高い素直な優等生(>>144)」を自称するPyhtonにおいて、
最大の設計ミスの一つが「クロージャの欠落」だと思う

159 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
いや、pythonにクロージャはあるし、pythonが優秀な理由の一つだけど

160 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>155
node.js以前のマルチユーザサービスはマルチスレッディングで実装するのが常識だった
それをシングルスレッド上の非同期処理で全面的に実装したnode.jsの登場は、
一つのイノベーション(革新)であり、それが多くのWebデベロッパを引きつけた要因

ただし、node.jsは非同期処理に特化したWebフレームワークであって、
非同期処理とその利点であるスケーラビリティを重視するサービスであれば最適だが、
そうでない多くのサービスでは、node,jsが提供しない機能を自力で実装しなければ
ならないことが大きな負担になる
つまり、多くの用途にはRailsのようなオールインワン型汎用Webフレームワークが
適しているので、node.jsは注目されても普及する(他からシェアを奪う)ことは無い

また非同期処理そのものはJavaScriptでなくても実装できるし、
実際に他の言語でも(node.jsの影響を受けた?)非同期処理向けのライブラリが登場している
非同期処理採用フレームワークの先駆者としてnode.jsの功績は賞賛にふさわしいと思うが、
ただそれだけをもってWebの世界を制覇できるほど甘くはないのが現実

161 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
その大きな負担となる機能とやらはたとえばなに?
nodeはモジュールを組み込んで使うプラットフォームであって、
現在では、たいていの機能はモジュールで提供されているけど?
sinatraライクなフルスタックのフレームワークもあるし

162 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>160
Twisted や EventMachine が前からやってた非同期プログラミングと
Node.js のそれとではモデルが違うのん?

163 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
まあPython2のクロージャは使い物にならなかった
nonlocalで手軽に変数に代入できる3はいいけど

164 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
手続き型言語に毒されたウンコには理解出来ないだろうけど、
再代入は本来避けるべきもの
外のスコープの変数なら尚の事

165 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
node.jsはコルーチン、継続、C#5.0のasync/wait等を使って
非同期処理を同期的に記述できるようにしてあるものに比べると微妙に見えるな
まあV8にyield来るらしいからその辺は改善されていくかもしれんが
あと非同期フレームワークの先駆者というのは嘘

>>162
フレームワークの出来栄え的には巨大でコールバック地獄なtwistedはまさにnode.jsだな
Pythonならコルーチン使ってるgevent/eventletみたいな系統のほうが書きやすいよ
asyncみたいな特殊なキーワードすら要らないし標準のソケットライブラリに
モンキーパッチ当てて非同期化できるんで、同期とほぼ全く同じコードを
透過的に非同期に出来る
node.jsより古参のはずだけどな

166 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
> node.jsより古参のはずだけどな
比べるなら言語で比べるべきではないの?

167 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>159
ええっ?Perl・Ruby・Javascriptにクロージャってないんだ!!

168 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
そもそもクロージャってそんな頻繁に使うか?

どっかの関数ポインタすらない言語は頻繁に匿名クラスを使うしかないから
クロージャが必要になってくるけど

169 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
非同期処理で大量に使うよ
マルチスレッドじゃない方の非同期な
そんなもん使わないで>>165の言うように言語サポートによって同期っぽく書けるのが理想だけど

170 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
数年前華々しく登場したGoてどうなったの?
早くも消滅した?

171 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
Go、CoffeeScript、JSX当たりは死亡した。

172 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
GoとDartはマジでいらない
MSは言語のセンスあるからごり押しも許せるけどGoogleはどうしようもない

173 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
nodeの最大の欠点はコールバック地獄なんかではなく
javascriptの冗長な記述そのもの
alterjs使うと世界が変わる

174 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
センスは余りいらない。
実用的装備を整えるべき。
それが普及の大前提。
話はそれからだ。
Googleは実験的に初めて放置しやすい。

175 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>173
あれしこで冗長ってw
お前、そんなにたタイピング速度遅いの?

俺は冗長な記述よりも
考えるほうが時間が掛かるが?

176 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
CoffeeScriptは死亡してないだろ
そもそもJavaScriptのシンタックスシュガーに過ぎないから学習コストも0で覚えるのは余裕だし
死なれても問題ないけどさ

177 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
CoffeeScriptってあんまりコード量へらないんだよな。
functionとreturnという単語の分は減るけど、
そんなの1関数に1回ぐらいしか使わない定義部分。

中身のコードを減らしたいのに、括弧だけの行が
減るぐらいしか効果がない。

178 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
どう見ても冗長だ
無駄な記述やインデントをしないといけないから
修正も面倒になる
ああもしかして一つの関数に長文書いちゃうタイプか?

179 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
お前の言う無駄な記述やインデントは
全然大したことじゃないって話だよ。
単に打つ文字列の違いでしか無いだろ。

そんな細かい文字数を来にしてないで
本質的なコード量を減らせ
文字数を減らすんじゃない、
処理コードを減らせ。

180 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
http://ja.wikipedia.org/wiki/CoffeeScript

下記は jQuery を使った典型的な JavaScript のコード例である。

$(function() {
 // 初期化のためのコード
});

CoffeeScript では function キーワードが -> で置き換えられている。

$ ->
 # 初期化のためのコード


jQuery などではクロージャを多用するが、CoffeeScript ではクロージャが簡潔に書けるようになっている。
これは /info の内容を取ってきて、#info にそれを入れる場合の jQuery を使ったJavaScript の例である。

$.get("/info", function(txt) { $("#info").text("info = " + txt) }, "text")

CoffeeScript でも以下のように1行で書け、75文字が67文字へと1/10程度文字数が減っている。
$.get("/info", ((txt) -> $("#info").text("info = #{txt}")), "text")

181 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
記述量が減ればコードの見通しが良くなるし
処理を減らす余地も生まれやすいだろ
冗長であることを誇ってどうするんだこの馬鹿は

182 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
}); の嵐は Lisp のカッコ以上に凶悪

183 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>164
手続き型というより、オブジェクト指向かもな
内部に状態変数を持っていて、それを更新する
まあそれと対極の関数型の考え方も理解できないではないが、
主流のスタイルじゃないし、現実問題やっぱり再代入をする
スタイルが必要なことが多いんじゃないかな

184 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>181
だから記述量と文字量の違いを区別しろよ。

やってる処理の内容が同じ場合、
それは文字量が減っているだけ。

記述量の話をお前はしていない。

CoffeeScriptは文字量を減らすだけ
記述量が減る例はごくわずか。

185 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
> 記述量が減ればコードの見通しが良くなるし

これは間違い。

index を idxと略しても
コードの見通しが良くなるとは限らない。

186 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>185
そんなくだらない事言ってないぞ?
冗長の意味履き違えるなよ

187 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>186
冗長の意味を履き違えてるのは
CoffeeScriptだろ。

CoffeeScriptは単に文字を減らしているだけ。
そもそもシンタックスシュガーだろ?
文字を減らしただけって証拠だよ。

188 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
function キーワードが -> に置き換えられるっていうのは
まさしく、文字を減らしただけだな。

189 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>184
余計な区切りや括弧やキーワードがあることで
全体の処理の流れが直観的に追えなくなる
記述量が減ることで近くのもの同士の関連がより読み解きやすくなる

シンプルな方がいいっていうすごく簡単な理屈なんだけどわからないのかな?

190 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
functionを->にできるのが利点ってならES6普及後はcoffeescriptの利点はなくなることになる。

191 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
なんか冗長という言葉を間違って使っている人が
いるんじゃないかなって気づいたかもしれない。

例えば、
$('input').each(function() {
 $(this).prop('disabled', true);
});

こういうコードがあった時、

$("input").each ->
 $(this).prop "disabled", true

CoffeeScriptならこうかける。JavaScriuptは冗長だ!っていう人を俺は
「冗長」という言葉で指摘するのはそこじゃないだろって思うわけ。
括弧が減るのも何かを省略できるのも一緒。
そんなもん書き方を変えただけ。タイプ数が減ったとしか思わない。

冗長というのは(同じ言語において)無駄なことをやっている場合に
指すべきだと思う。最初のコードで言えば、

$('input').prop('disabled', true);

こう書けばいいわけ。こう書かないことについて、俺は「冗長」と表現する。

192 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>189
重要な区切りや括弧やキーワードがないことで
全体の処理の流れが直観的に追えなくなる

セミコロンを省略できたからって
それがいいことだとは思えないんだが。

セミコロンがあれば、そこで終わりとはっきりする。
無いことで終わりなのか続いているのか
”人間が”認識しづらくなる。

そりゃ、機械は認識できるだろうけどさぁ。
俺達は人間なんだぜ?

193 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>188
>function キーワードが -> に置き換えられるっていうのは
>まさしく、文字を減らしただけだな。
後者が削ってるのは文字だけじゃないよ
そのまま返すって機能がついてるし

194 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>183
オブジェクト指向は指向であって、手続き型言語と関数型言語のどちらにも適用できる概念
より正確には、手続き型言語より命令型計算モデル、関数型言語よりも適用型計算モデルだ
両者の違いは、オブジェクトが可変(mutable)であるか不変(immutable)であるかという点
命令型計算モデルにおけるオブジェクト指向では、
  オブジェクトにメッセージを送ると、オブジェクトの内部状態を書き換える(更新する)
適用型計算モデルおけるオブジェクト指向では、
  オブジェクトにメッセージを送ると、内部状態を更新した新しいオブジェクトを返す

そして、不変オブジェクトを多用する関数型プログラミングは、
「まともなクロージャ」を備えたJavaScriptやRubyであれば一般レベルで普及している
JavaScriptであれば、jQueryがだれでも知っている実例になる
Rubyでは、たとえば以下のような関数型プログラミングのスタイルは特異なものではない
  collection.select { |e| ..... }.map { |e| .... }.sort { |x, y| ....}

もちろん可変オブジェクトの使用がゼロ、つまり純粋関数型プログラミングではないが、
大域的な可変オブジェクトを極力減らし、できる限り(Rubyであれば上記コードのような)
不変オブジェクト間の演算で計算を進める方向性が見える

195 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>192
それはその通りだしCのような記述が嫌いなわけではない
ただjavaScriptの用途では匿名関数をその場で作る事が多いのに
処理と関係のない修飾が過剰になって読みにくくなっている
ocamlのlet-inのようなの

196 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>191
それは確かに処理そのものが冗長でわかりやすいな

俺が言っているのはコードの表現が冗長という事
その上でindexをidxとするうようなただ文字数を減らすだけの物は
直感を削ってしまうので冗長を削ったものではないと言った

名前付けそのものに関しては主観と言われれば終わりだが

197 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>194
よくわからない
例えば、jqueryはdomの状態を変更するよ
オブジェクトを返すけど、新しいオブジェクトを作って返してるわけじゃない
だからその例で行けば関数型じゃない方のスタイルだろ
そして、パフォーマンスなどの理由から、そういう新しいオブジェクトをわざわざ作り直して
返す関数型のスタイルは今の主流のスタイルではない

198 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
一部の動的型付け言語って、IDE使う習慣がないからって
今更冗長な型づけ宣言を導入しようとしているのが笑える。

Object obj = new Object()

とか。
動的型付け言語なのに、自明な型推論すら導入しないってアホすぎる。

199 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>197
同意。
オブジェクト指向モデリングで、ステートレス設計もあるので、
一概に関数型言語が、OOPと相容れないとは思わない。
しかし、状態を保持しない設計を強制するのは、
生成・破壊(コピー)コストを考えると、現実的ではない。

200 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>197
jQueryに置けるDOM操作は一般的プログラミングにおけるI/Oであり、
I/Oを含む一切の副作用を許さないのが「純粋関数型プログラミング」と呼ばれ、
これを代表する関数型言語にHaskellがある
そして「純粋でなければ関数型にあらず」という絶対原理主義の主張もあって、
それを鵜呑みにする人も多い(多かった?)けど、>>197はその影響を受けていないかい?
ただし、このスタイルは(>>197が言うように)今の主流スタイルではないし、
もし仮に主流になるとしても遠い未来のことだと(個人的には)考えている

その一方で、部分的な再代入やI/Oといった副作用を許容する立場もあり、
LispやMLといった伝統的な関数型言語の主流の考え方にある
>>194で書いた関数型プログラミングというスタイルも、
(I/Oや限定的な可変オブジェクトを許す)後者の立場を取っている

jQueryもDOMという可変オブジェクトと破壊的操作があるけれど(=純粋ではないけど)、
それ以外の部分では関数型プログラミングのスタイルを積極的に導入していると思う

201 :デフォルトの名無しさん:2013/08/10(土) NY:AN:NY.AN
>>199
>しかし、状態を保持しない設計を強制するのは、
>生成・破壊(コピー)コストを考えると、現実的ではない。

基本的に同意する。
ただし、LispやMLといった伝統的な関数型言語では、
状態を保持しない設計を強制していないし、
Lispでは関数 set-car! 、MLではref型やarray型のように
(メモリやCPUの)効率を考えたコード設計も許容している

>>200で書いたように、状態を保持しない設計を強制するのは、
Haskellのような純粋関数型言語の場合だけだから、
そこは誤解しないでほしいと願う

202 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
で、結局話に戻るが、スコープの外側の変数を変更するのは普通に有用

203 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
スコープの外側の変数を変更はあまりしてほしくない。

だからクロージャではなく
関数内関数が欲しい。
クロージャのように記述できるが
クロージャの中と外は完全に分離されている。

204 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
つまり Pascal サイコーってこと?

205 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>203
>スコープの外側の変数を変更はあまりしてほしくない。

ここまでは賛同するけど、その後が間違っているな
 だからクロージャではなくてもいいから、
 無名関数内で局所変数が欲しい。
だろ

あと、後半の
>クロージャのように記述できるが
>クロージャの中と外は完全に分離されている。
は意味不明
関数内関数であっても、外の関数と内の関数が完全に分離されている点では同じじゃね?

206 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
あらいぐまPascal

207 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
要は一定の処理を別にふって、その振り先に引数渡したり戻り値受け取りたいだけだろ。
そんなことは当たり前にできるべきだし
クロージャーみたいな名前で呼ばれてること自体がおかしいんだよ。

C#はクロージャーってわざわざ名前つけてないけど、普通にそういうことができる。

208 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
例えばこういうクラスがあったとする

class A {
 function foo() {
   :
   : 長い処理
   :
 }
}

関数foo()をリファクタリングしたとき、
foo()の中でやっていた処理を
foo()の外にに出すのは
スコープ的にはおかしいと思うんだ。

209 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
class A {
 function foo() {
   var i = 0;
   :
   bar()
   : 長い処理
   bar()
   :
 }
 function bar() {
   :
 }
}

スコープ的にはおかしいけど、リファクタリングでよくこうやるよね。
で、この場合bar()から i は見えないんだ。
つまりコードの独立性が高いよね。

210 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>207
>要は一定の処理を別にふって、その振り先に引数渡したり戻り値受け取りたいだけだろ

それは、そもそもクロージャではないだろ
ただ単に関数(メソッド)を第一級市民として(=値として)扱いたいだけなら、
C言語にも関数ポインタがあるから記述できるけど、それをクロージャと呼ぶアホはいない

>>207はクロージャが何かを知らないんじゃねえの?

211 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
でもbar()はクラスAのどこからでも見えるスコープになってしまっている。
bar()はfoo()でしか使わないのだから、こう書いたほうがいいと思うんだ。

class A {
 function foo() {
   var i = 0;
   :
   bar()
   : 長い処理
   bar()
   :

   function bar() {
     :
   }
 }
}

でもこう書いてしまった時に、bar()から i が見えてしまったら
今度はコードの独立性が下がってしまうんだ。

foo()の中にfoo()でしか使わないbar()を定義できるが、
そのbar()からは、iが見えないという関数が必要だ。

212 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
そもそも>>208-209の例はおかしい。

そんな複数のメソッド、それも外部からアクセスさせたくないものがあるなら、
それを別個にクラスとして定義するべきだろ。

213 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>208

もしかして全ての手続きをmain()の中に(関数内関数等を使って)記述しろといいたい?

214 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
つまり Pascal サイコー ですね

215 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>213
いいえ?

色んな所から呼ばれる関数はmain()の外。
main()からだけしか呼ばれない関数は
main()の中に記述しろと言ってる。

変数と一緒だよ。
色んな所から書き換える変数は
main()の外。

main()の中でしか使わない変数は
main()の中だろう?

216 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>210
同じ事だよ。
一般的にクロージャとかわざわざ呼んでる言語がクロージャでしたいことは、処理を投げて
その処理にローカル変数を参照させたいとか戻り値を受け取りたいってだけじゃん。

finalつけないと参照できないみたいな糞言語があるせいか
クロージャーとかわざわざ呼んでいるけど

217 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>198
どの言語が静的型付をいれようとしてるの?

218 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>216
クロージャーという用語が出来たのは
Javaができるよりも前だよ。

219 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
やっぱり >>215 は Pascal サイコー な人だったのですねw

220 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
class A {
 function foo()
 {
  new class B().do(); 
 }

 class B {

 function do() {
   longMethod();
 {

 function longMethod() {
 }

}



・class Bがclass Aのみに参照できること
・class Bの関数の中のうちlongMethod()は外部から参照できないこと


以上2つができない言語を使っているアナタに一言 : それはオブジェクト指向型言語ではありません。

221 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>216
え、では(>>210で述べた)C言語で関数ポインタを使うコード設計のことも
(>>216は)クロージャだと見なすのか.....

せめてWikipediaで「クロージャ」を一読してからカキコしてくれ、タノム!!

222 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
※注意

「何かが出来ない」と「何かが出来るのと出来ない機能の両方を備えている」

は意味が違います。


はい、続きをどうぞ。

223 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>220
インデントも括弧の対応も取れてないコードを書かれてもね(苦笑)

おかげで何が言いたいのかさっぱりだ。

224 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>223
普段C#で書いてるからな。

>>208に対する>>220の意味が分からん場合は、多分JSみたいな糞言語使っていて
オブジェクト指向型言語つーのが理解できてないんだと思う。

225 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>220
Smalltalkは、そのどちらもできないけど、
Smalltalkがオブジェクト指向言語ではないと言う人は初めてだぜ!!

いや、それともオブジェクト指向型言語とあるから、
オブジェクト指向言語(OOP)とは別の異世界にある言語族なのかなw

226 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
C#で書いてるのと、自分がミスしたことと
何が関係あるんだろう?

あ、もしかして自分がミスしてることに気づいてない?

227 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>216
クロージャがない言語(たとえばC)では、関数から抜けたら
ローカル変数の寿命は終わりでいいし、だから効率上スタックを使って
実装されることが多い

一方、クロージャの場合、クロージャから参照される外側の関数のローカル変数は
少なくともクロージャの寿命と同じだけは生かさないといけならず
クロージャの寿命は外側の関数からリターンした後も継続するかもしれない
つまりスコープ上はローカルなオブジェクトの寿命(エクステント)が伸びるという
特殊な状況が生じる
こうしたローカル変数を、クロージャにキャプチャされていると呼んだりする
クロージャというのは、このようにキャプチャされた変数と関数の組(オブジェクト)を
指す

228 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>225
Pythonですらカプセル化ができないから完全なオブジェクト指向型言語じゃない。
そういう厳密な定義では、Smalltalkは関数は全てpublicだから不完全。

>>226
C#のインデントスタイルはBSDオールマンが標準なんで、K&R式ではないんですが、そんなことも知らないんですね。

229 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>224
その意味はオブジェクト指向ではなくて、名前空間ではないのかな?

ちなみにRubyでは名前空間としてmodule宣言が、クラス定義としてclass宣言があるから、
名前空間の分離とクラス定義の分離を意識したコードが書けるし、
たまたまClassクラスはModuleクラスのサブクラスだから、
クラス内クラス(あるクラスの名前空間に閉じたクラス)の定義もできる
ただし、それをオブジェクト指向と呼ぶ人は誰もいない

230 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>220
やっぱり気づいていないんだ? { がひとつ足りないことにw

231 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
オブジェクト指向言いたいだけなんだろうなw

俺の知ってるオブジェクト指向が
本物のオブジェクト指向だ。

みたいなこと言ってるし。

232 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>228
まず最初に「完全なオブジェクト指向型言語」とやらの厳密な定義を示してくれないと
議論にならないよ

たとえば純粋オブジェクト指向言語は「あらゆるデータがオブジェクト」と定義できるから、
Smalltalkは純粋オブジェクト指向言語であるけれど、C#はそうじゃない

これと同様に「完全」と呼ぶ性質を定義してくれ

233 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
今の主要なオブジェクト指向言語はだいたい、フィールド変数という名の、
スコープ外変数をメソッドから変更しているが、それを全否定か?w

234 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
というか、オブジェクト指向という用語を考えて一番始めに使い始めたのって、
Smalltalkの作者だろw
後からストラウストラップのようなバカどもが間違った定義で話を進めたために、
本来の意味とは違う意味になってるようだがw

235 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
Smalltalkに向かってオブジェクト指向じゃないってのは、
本当にコントみたいな話だなw

236 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>232
C#では数値もオブジェクトだぞ

237 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
http://e-words.jp/w/E382AAE38396E382B8E382A7E382AFE38388E68C87E59091E8A880E8AA9E.html
オブジェクト指向という用語は1972年にSmalltalkが発表された際に考案されたが、
そのアイデアが初めて現れたのは1967年のSimula 67であるとされる。

238 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
http://d.hatena.ne.jp/sumim/20040525/p1

一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。

アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった
「オブジェクト」をメッセージの受け手とすることで実現(オブジェクトにメッセージ送信)
するアイデアに基づく「メッセージングのオブジェクト指向」と、
ビアルネ・ストラウストラップによる、ユーザー定義型(抽象データ型)を SIMULA67 にあった
「クラス」という言語機能を使って実現(カプセル化、継承、多態性)するアイデアに基づく「抽象データ型のオブジェクト指向」。

この二つの「オブジェクト指向」は、オブジェクト指向という呼称、「クラス」や「オブジェクト」と
いった主軸となる言語機能を共通して使用してはいるものの、考え方の方向性が全く異なっており本来きちんと区別すべきものである。

しかし、教科書的な記述の多くはこれら二つを書き手に都合のよい解釈でごちゃまぜにしてしまっており、
しばしば学習者に対して無用な混乱を生じさせている。

オブジェクト指向言語はこれら二系統のどちらかを比較的厚くサポートすることが多いが、
完全にはサポートできてはいない。また、たいていはどちらかに重きをおきつつつ双方を
不完全ながらサポートする言語が多いため、利用者(プログラマー)がまず先に概念を
理解しどちらの考え方でプログラミングをするかを決めないと機能の間違った使い方になってしまう。

同じ理由で、オブジェクト指向という概念を特定の言語の(「オブジェクト指向」むけと思われる)
機能から外挿して学ぶのは難しいし、間違った「オブジェクト指向」を創造してしまう危険がある。
少し遠回りに思えても、それぞれの考案者自らがその主張を綴った論文を読んで理解を試みるほうがいい。

239 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
一番重要なのは、その用語を考案したのは誰で、最初にどういう定義をしたかということ
アイディアが現れたのはいつかというのは、ここでは全く重要ではない
言葉の定義の話なのだから
そして、すでに定義があるのに、あとから別人が別の定義で話をはじめたら
混乱が起こるに決まっている
それをやってしまったバカがストラウストラップ

240 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>236
C#でクラスはオブジェクトかな?
Smalltalkは純粋オブジェクト指向言語だからクラスもオブジェクトだけどね

241 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>239
たぶん、ストラウストラップ が違う名前をつけていたら、
世の中に普及していたのは、その違う名前のほうで、
オブジェクト指向はメッセージ指向と同じく
マイナーなものになっていただろうな。

242 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
インターフェース指向か型指向だろ

243 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>241
仮にそうなったとしても、少なくともその方がはるかに混乱は少なかっただろうな
まあ、そもそも上に出てきた真のオブジェクト指向とやらは、ストラウストラップの
言ってるオブジェクト指向とも違うようだが

244 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>241
たられば論だったらお子様にもできる。

ある定義の人気に便乗して、その定義を別の人が別の概念で使い始めたことが間違っている、
という>>239の指摘に対して、たられば論は見苦しい言い訳にしか聞こえない。

245 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>244
ええとね。

名前の話ではなく
概念の話をしているの。

名前で混乱してるのはお前だよ?


今普及している概念は
ストラウストラップの方。

246 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
たらればではなく、
今普及している概念の話をしている。

247 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
ストラウストラップの言ってるカプセル化って、フィールド変数を
パブリックメソッド使って変更するやつのことだしな
つまり、メソッドのスコープ外変数をメソッドから変更するっていう
まさに上で完全否定された処理w
それが柱w

248 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>245
いや、これはオブジェクト指向と呼ぶんだ呼ばないんだという話をしているのだから、
概念をどういう名前で呼ぶのかという、まさに名前の定義の話だろ
そして、ストラウストラップの定義も、お前の完全なオブジェクト指向とは違うw

249 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>247
フィールド変数一つに対して
それを変更するだけのメソッドを一つ作ると
考えてるのはお前だけだと思う。

わかってないなぁ。

250 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>249
誰も変更するだけだとは言ってないし、一つだとも言ってないが?
しかも、スコープ外変数への再代入の話なんだから、
回数やら他の処理やらは議論と何の関係もないが?

251 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>248
別の名前にするべきといったのはお前じゃん?
同じ名前にするのが悪いんでしょ?

じゃあ別の名前にしましょうよ。

252 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>251
してもいいけど、で?

253 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>250
そうか?
なら疑問が出るんだが?

プライベートなフィールドを変更するのは
パブリックなメソッド以外何があるんだ?

254 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>252
別の名前にしたらはっきりする。
ストラウストラップの方の
○○指向が普及しており、
オブジェクト指向は普及していない。

これはたらればの話ではなく
事実を言ったまで。

255 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>254
で?
Smalltalkをオブジェクト指向じゃないといった赤っ恥を取り繕ったつもり?w

256 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
オブジェクト指向という大分類の中に
・メッセージ指向
・クラス指向
の二つがあるというだけの話だろ。
どっちが完全だの起源だのそんな話はどうでもいい。

そして現在このスレで語られている概念や、
世間で「オブジェクト指向開発」という場合の概念は、
どちらもクラス指向のことを指していることは明らか。

今Smalltalkの話を持ち出すのは本物のバカ。
どういう脳みそしてればメッセージ指向の話をしていると勘違いできるんだよ。

257 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>255
それ俺じゃないw

258 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
やはりム板にID制の導入は必要ではなかろうか

259 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
ID無いのに決めつける奴が馬鹿なだけ。
決めつけたセリフを言わなければいい。

260 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
ぶっちゃけIDある方が騙されやすいんだけどねw
だって俺、スマホ以外にプロバイダ2契約してるもの
(バックアップと負荷分散を兼ねて)

その気になればID二つ使って一人で会話できるよ?w

261 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>260
プロバイダなんて月々1000円程度しかかからんから複数契約は珍しくない
俺も複数契約してるがバックアップやら負荷分散なんて大仰な目的じゃなくて、
くだらない目的で使ってるだけだがな。

262 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
珍しい珍しくないの話じゃなくて
ID制が意味ないって話だろ
頭にウジでも沸いてんのか?

263 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>262
プロバイダ2つごときで「バックアップと負荷分散♪」なんてドヤ顔してる子を温かい目で見守ってやれるほど大人じゃないんでねw

264 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
ストラウストラップが別の名前をつけていたとしたらそちらが普及していたってのはかなり疑問
例えば、言語設計者がどちらの用語を使うかが普及にとって大きな鍵だが、言語設計者の間では
Smalltalkは別にマイナーではなく、超有名言語
C++より影響力が大きいかもしれない
Objective-Cのオブジェクト指向もJavaのオブジェクト指向も
Smalltalkの影響があるし
このスレの話題に出てきてるJavascriptはクラスベースとも違うだろ
そもそも、C++が登場した当初、
>>220の要件を満たしていたのか?w

265 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>264
> Smalltalkは別にマイナーではなく、超有名言語
> C++より影響力が大きいかもしれない

> Objective-Cのオブジェクト指向もJavaのオブジェクト指向もSmalltalkの影響があるし

ソースくらい出せよ妄想君。

266 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
お前のようなくだらない奴のために何で俺がその労力を使わなくちゃいけないんだよw
お前がやってるのはインターネットだろ?なぜ目の前の道具を使わない?w

267 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
つ wikipedia

268 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>266
議論はハッタリやブラフを競うゲームじゃないんで。
存在しないソースを存在するように見せかけるお遊びはチラシの裏でどうぞ。

269 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>265,268
ソースが無ければ事実と認めないと言うのなら、

>>254
>ストラウストラップの方の
>○○指向が普及しており、
>オブジェクト指向は普及していない。

のソースを提示するのが先ではないのかな
それともストラウストラップうんぬん(>>254)は妄想かな?

270 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
wikipediaより

Smalltalk
Influenced Objective-C, Self, Java, PHP 5, Logtalk, Dylan, AppleScript, Lisaac, NewtonScript, Python, Ruby, Groovy, Scala, Perl 6, Common Lisp Object System, Falcon, Io, Ioke, Fancy, Dart

C++
Influenced Perl, LPC, Lua, Pike, Ada 95, Java, PHP, D, C99, C#, Falcon, Seed7

Objective-C
Objective-C(オブジェクティブ シー)は、プログラミング言語の一種。C言語をベースにSmalltalk型のオブジェクト指向機能を持たせた上位互換言語である。

Java
Smalltalk や Objective-C と同様な簡潔なオブジェクトモデルを採用している。

271 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>270
Smalltalkの影響欄にDartが入ってる理由を具体的に述べてくれますか?

272 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
たとえばDartの言語仕様のどの部分がSmalltalkに影響を受けてるのでしょうか?
あなたは「DartはSmalltalkに影響を受けている」と主張なさっているので、
当然その根拠を1つは答えられるはずですよね。

答えられないのなら尻尾巻いて逃げ出していいですよ。
弱った犬を棒で叩く趣味はないのでね。

273 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>271
http://www.youtube.com/watch?v=huawCRlo9H4#t=1810s

274 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
ツンデレw

275 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>263
> プロバイダ2つごときで「バックアップと負荷分散♪」なんてドヤ顔してる子を温かい目で見守ってやれるほど大人じゃないんでねw

プロバイダ・・・2つ・・・ご と き?

お前、なんの勝負してるんだ?
俺はプロバイダ5つだ!とか数の勝負してんのか?w

276 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
っていうか元々のレスは
バックアップと負荷分散自慢じゃないじゃねーかw

ID自演は簡単って話じゃねーか
バックアップと負荷分散の話はあくまでおまけ。

277 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
低級企業をわざわざゴミカス言語を使わざるを得ない状況に誘い込んでるだけ
言語の良しあし語る前にまずそこから

278 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>272
えるしってるか?
だーとのさくしゃはすもーるとーくぶいえむのこうそくかでちょうゆうめいなひと。

279 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
L知ってるか?

280 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>278
言語処理系の影響が言語仕様に限定されるという視野狭窄はさておき、
DartがSmalltalkの影響下にあるわけないという272の確信が
無知であること以外のどこから来たものかすごく興味がある
Dartの言語仕様を暗記するくらい読み込んだのかな……

281 :272:2013/08/11(日) NY:AN:NY.AN
へーSmalltalkって色々なところに影響及ぼしてるんだな。
sumimとかいう奴の解説間違ってるじゃねーかクソが

> 誤った傾向として、よく、「すべてがオブジェクト」であることのみが強調されがちですが、
> この文脈における「オブジェクト指向」で重要なのはむしろ“メッセージング”のほうです。
> クラスはおろか、オブジェクトですら飾りに過ぎません。
> 偉い人にもそれがわかっとらん人がけっこう多いのです。w
http://d.hatena.ne.jp/sumim/20040525/p1

>>273
の図には「Object/Smalltalk」って書いてあるぞクソが

282 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>272
>答えられないのなら尻尾巻いて逃げ出していいですよ。
>弱った犬を棒で叩く趣味はないのでね。

いくらバトルスレとはいえ、
ここまでムキになって挑発する心理状態が分からないw
夏だからかな?

283 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>281
ケイのメッセージングについてはオブジェクトは関係ない
Smalltalkはケイのメッセージング指向”と”オブジェクトを取り入れた言語
ゆえにお前が引用してる文章は何も矛盾してないぞ

284 :272:2013/08/11(日) NY:AN:NY.AN
俺が悪いのか?

285 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
       |::::::|.::.::.::.::.::.:ト、::.::.::.::.::.::.::.::.::.::.::.::.::.::.::ヽ:.::.::.::.::.::.::.::.::.::.::.::.::.',
       |::::::l!::.::.::.::l::.:| ';\::.:ヽ.::.::.::.::.::.::.::.::.::.::.:..';.::.::.::.::.::.::.::.::.::.::.::.::.::
       |::::くヽ:.l::.::.::.:|,.. -ヾ´:.:.'、.::.::.::.:ヽ:.::.::.::.::.::.l'⌒ヽ:.::.::.::.::.::.::.::.::.::
       |::::::_l_`;:l:::::::l'~j,二二...zヽ_::.::.::.::';::.::.::.::.::.|こ`ヘ::.::.::.::.::.::.::.::.::
       |:::::::゙Lh!:'、::::l:',′_づツ火´::.::.::.::.:i:: :: ::::::lヽ r ノ::.::.::.::.::.::.::.::.:
       |:::::::::| /ヾ`、:::`、  :;  ; ヽ::::.::.:.::l::::.::.::::|/ /:::::.::.::.::.::.::.::.::.:.
       l:::::l::::!'  ` ゙、:ヽ   ';.;  ゙;'、::.::.::.|::.::.:::::|_,ィ:::::::::.::.::.::.::.::.::.::.:
       |!:::|l/     ヾ;   ;.   ; `;::.::::|:::::::l:リ: .1::::::.::.::.::.::.::.::.l::.::.
         l:::| !`ヽ`     `  ';   : l::.::::|:::::/ノ  }::::::i::.::.::.::.::.::.l::.::.:
        l| !::ハ ー‐- 、_   ; j ; |::.!;:|::/   /::::::l::.::.::.::.::.:;'!::::::::
         ! l:! `,  ̄ ̄`  ;   ' イソ j〃 _,/::::::::l::::.::.::.::.:;':l::::::::
          !  ゙,      !,.-''´リ///バz'"/::::::::::l::::.::.::.::.::l::l::::::::
               l.   ,. -''V///////  /::::::::::/!:::: :: ::::/!::|::::::::
                  ̄    Y////   /:::::::::/|::!::::.::.::::::! !::ト、:::
                   レ:''´ _ -─/:::::::/´ !::!::::.::.:::::l |::| ヽ
                 /: ; . '´   /::.::./  l::l!::::.::.:::::! l::l

兄(ケイ)のメッセージングについてはオブジェクトは関係ない
Smalltalkは兄(ケイ)のメッセージング指向”と”オブジェクトを取り入れた言語
ゆえにお前が引用してる文章は何も矛盾してないぞ

286 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
そりゃ、言語設計者からみたら、C++なぞ問題外(^_^;だし、
SmalltalkやLispやHaskell、Prologといった言語に見られるカリスマ性はないだろう
格が違う

287 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>284
うん。はずかしくて尻尾巻いて逃げてもいいレベル。

288 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
C++の深淵をどこまでも追い求めるバチスカーフのようなしぶとさは高評価に値すると思う

289 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>286
Simula
クラスやガベージコレクション、継承といった
オブジェクト指向言語の「機能」を最初に実装した言語

Smalltalk
Simulaを参考にして「メッセージング」という概念を提唱し、
これにオブジェクト指向という「名前」を最初に付けた言語

C++
Simulaを参考にして「カプセル化、継承、多態性」の3点セットが
オブジェクト指向の「定義」であると最初に主張した言語

「カプセル化、継承、多態性」についてはSmalltalkは全く関係なくC++オリジナルの功績
格が違うのはどっちだろうね…w

290 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
今のC++って記述はシンプルになってるけど、実際にどんな処理が入ってるのか理解するのが大変
あれ使いこなすのは相当頭良くないと無理じゃないの

291 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
C++のスクリプト化がPHPやJavascriptみたいもの。

292 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
C++は言語仕様は滅茶苦茶だけども「カプセル化、継承、多態性」という
現代のオブジェクト指向の最重要概念を一番最初に提唱したという功績がある

Smalltalkは名前を付けただけで中身はない

293 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>289
> Simula
> クラスやガベージコレクション、継承といった
> オブジェクト指向言語の「機能」を最初に実装した言語

ガベージコレクションは、オブジェクト指向と直接関連しないし、そもそも実装は Lisp の方が早いでしょ。

294 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
カプセル化、継承、多態性という概念が本当に専門家の間で
評価されてると思ってるのか?
実際は、糞食らえと思われてるかもよ?
実際Smalltalkの影響より大きいのかと言われると怪しいわけだし

295 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
特に継承は悪者扱いされ始めて久しいな
必要ないとは言わないが、乱発はするなとか
最近では多態性も雲行きが怪しいな
javaのテンプレートが失敗だったと言われはじめたり

296 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
言葉の定義を勝手に変えて混乱をもたらした挙句に、
不必要にオブジェクト指向の概念を複雑化させ、
複雑怪奇なテンプレートや多重継承を持ち込み、
多くのプログラマーを困らせた馬鹿という印象しかないわ
Smalltalkのような美しさ、創造性が微塵も感じられない

297 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>296
お前がいくらそう思っても世間はC++由来の「カプセル化、継承、多態性」一色に染まってるからな
ノイジーマイノリティにならないように気をつけな

298 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>286
まつもとw
懐かしいネタだなw
もう10年以上前になるのか
あの記事もう一度全文見たいな

299 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>297
お前のいう世間が狭いんじゃね?
かなり遅れてる

300 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
「カプセル化、継承、多態性」が含まれてない「オブジェクト指向言語」って例えば何がある?
まともに使われてるのはJavaScriptくらいだろ

301 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>292
> Smalltalkは名前を付けただけで中身はない

ふーん。

アジャイル開発手法のアイデアのほとんどはケイのメッセージングのOO…というか
Smalltalkでの開発手法を拠り所にしているし、デザパタだのリファクタリングだの
IDEだの、そもそもGUIのマルチウインドウやポップアップメニュー(特に今の右クリックメニュー
やコピペ)とか、マルチフォントとか、Appleが好んで使うカラムインターフェイスだの、
それらの実装に用いられるMVCフレームワークだの、古くはC++のSTLのころからある
コレクションAPIだのもろもろSmalltalk発祥なんだけど、でも君のOOには功績ゼロなんだね。

302 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
Smalltalkをそこまで持ち上げる必要もないと思うけれど、
古いから知らないからって無視していいとかにはならないと思う。
今はフリーの処理系とかあるわけだから、ちょっとくらい触って
ケイの言う「メッセージング」とか「究極の動的システム」とかの
ワケわからなさにうちひしがれるくらいの経験はしておいてもいいと思う。

http://dotinstall.com/lessons/basic_smalltalk/21103

303 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>301
ソースは?
韓国人がすべての起源主張してるようにしか見えないんだが
アジャイルがSmalltalkを参考にしてるなんて聞いたことねーよアホが

304 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>302
知ってるから無視してんだよボケが

305 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
> 古くはC++のSTLのころからある
> コレクションAPIだのもろもろSmalltalk発祥なんだけど



> ビアルネ・ストラウストラップ(Bjarne Stroustrup)によるC++は、
> オブジェクト指向という考えをSmalltalk経由ではなく、Simulaから直接導入しています。
> 以前お会いしたときに直接聞いたところによると、ストラウストラップは大学院時代に
> Simulaのユーザーであったため、その機能をC言語に取り込みたかったというのが、
> C++の直接の開発動機だったそうです。
http://www.itmedia.co.jp/enterprise/articles/0703/26/news021_2.html

さっそく嘘ばれとるやん
C++はSmalltalkなんて全く参考にしてねーよ

306 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>303
さすがにお前が無知なだけ
Smalltalkも本当は知らなかったんだろ?w

307 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>305
オブジェクト指向という言葉をSmalltalkを知りもせずに再定義したバカが
ストラウストラップだというのはマジな話しっぽいな
だが、STLのコレクションライブラリを作ったのはステファノフであって、
ストラウストラップではないぞ

308 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>306
アジャイルがSmalltalk由来って話はほとんど話題にはなってないだろ
少なくとも日本語のソースは見つからない

309 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>308
とりあえずスクラムとXPだけだけど

http://objectclub.jp/ml-arch/magazine/365.html
先週来日したジム・コプリエンさん[*1]によると、当初、Smalltalkで実装した
フレームワークだったのを、Smalltalk部分を取り去って「なんでも入る箱」に
したのが、現在のスクラムなんだそうです。

http://www.atmarkit.co.jp/fjava/devs_bk060201/bookreview/02/bookreview02_dev.html
ケント・ベックがXPの潜在能力に気が付いたのは、テクトロニクス社の
リーダーと仕事をしていたときだといいます。Smalltalkを使って複雑な
エンジニアリングのアプリケーションをペア・プログラミングで開発している姿に
インスピレーションを受け、ソフトウェア開発の歴史に埋もれてきた多くの
実践を組み合わせながら、XPの原型を形作っていったといいます。

310 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>309
どこからもリンクされてないページをさらっと出すとか
こんなの知らなくて当然だろ

311 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
じゃあとりあえず、「ケントベック」という人物について調べてみろ
彼がSmalltlakの文かとアジャイルの架け橋的な立場にいる一人だということが分かるから

312 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>305だってどこからもリンクされてないやん

313 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
C++なぞ問題外^^;;;
http://web.archive.org/web/20000302001334/http://www.ruby-lang.org/ja/compar.html

314 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>311
知りもせずってことはさすがにないと思うな。

もっとも、ケイの目指す「究極に動的なシステム」っていうのを理解していない、
あるいは、理解は示すが賛同しかねてるっていうのはあるかもしれないけれど。
http://d.hatena.ne.jp/katzchang/20080807/p2

「オブジェクト指向」と名付けたのは、無理解もあるけれど便乗の要素のほうが
大きかったと思う。

315 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
http://zerobase.hateblo.jp/entry/2013/02/24/015610
TDDもアジャイル(XP)もSmalltalkから生まれた、っていうことについて、
徐々に体得的に実感できつつある。
現代のエンジニアリングの潮流がSmalltalkに由来するということは、
そこに何か非常に重要な本質が潜んでいる可能性がある。また何か書きたい。
とりあえず現時点でほとんど確信しているのは、現代のエンジニアは
教養としてSmalltalkをやっとくといい、ということだ。
仕事でSmalltalkを書くかどうかは関係なく。

316 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
おまえらプログラムの歴史にも詳しいのか

317 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
TDDもアジャイルもSmalltalkが起源ニダ

318 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>316
おまえらはあらゆることについて恐ろしく詳しいよ
同時にあらゆる事について恐ろしくおバカである

319 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
lisp、smalltalk、haskell、prologが4大カリスマ言語
というに前者二つはいろんなものの起源

320 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>314
ストラウストラップがオブジェクト指向という言葉の人気に便乗したとか
言っても理解できないだろうw
まさか自分の知らなかった言語があの誰もが知ってるc++よりも影響力があって、
そんなに、凄い言語だったなんてw

321 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>320
あんま他人を馬鹿にするなよ
あしもと掬われるぞ

322 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
>>319
あれ以上シンプルにならない Lisp と Prolog だけでいいな

323 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
昔は、凄腕のハッカーが好むのがLispで、
口だけ達者でヘボコードしか書けない連中が好むのがSmalltalkだった

324 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
Lisp、Smalltalkを好んだ凄腕のハッカーの
名前が知りたいんだが誰か知ってる?
ちゃんとその言語を好んでいたというソースがある人。

325 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
で、そのヘボコードしか書かないSmalltalk使いが
ヘボコードを肥だめに積み上げて作ったアジャイルの潮流を
クールな君らが這いつくばって学んでいるわけですね。わかります。

326 :デフォルトの名無しさん:2013/08/11(日) NY:AN:NY.AN
ヘボコードしか書かないSmalltalk使いには
何も生み出せんよ。
Smalltalkを使っていただけのユーザーなんだから。

327 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
>>319
4つの言語の中で、Haskellだけは変じゃね?

もし型推論を備えた遅延評価を主とする実用的な関数型言語であれば、Mirandaだろ
Haskellの特徴大半はMirandaから引き継いだものであり、
Haskellそのものの功績は型クラスとモナドくらい
あと、Mirandaの前には、実用的な型推論を最初に実装したMLがいることも忘れずに

328 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
数学や物理は這いつくばってでも学ぶ価値があるが、
ぶっちゃけプログラミングの世界はアホ的思い付きが
大手を振ってるだけで、全然学ぶ価値無いよね
習得だって片手間で余裕だし

329 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
プログラミングの世界は習得が目的ではないので・・・。
的外れもいいとこだな。

330 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
>>328みたいな奴は
習得した言語自慢でもしてるんだろうか?

俺、 lisp、smalltalk、haskell、prologを
習得したぜ!って。


で、何を作ったの?

331 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
大して学ばなくても、出来る奴は最初から出来るし
カスは永遠にカスのまま底辺をさまよう
それがプログラミングの世界

332 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
それはプログラミング以外でも同じだと思うが?
勉強だけじゃなくてスポーツでも。

333 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
>>324
LISPは他に任せる。Smalltalkだけ。

ダン・インガルス、アデル・ゴールドバーグ、テッド・ケーラー、
ラリー・テスラー、ブルース・ホーンあたりは比較的名前も知られている
XEROX PARCの元Smallalk開発メンバーでいずれも天才プログラマーの類

ユーザーサイドでは、TDDやXPのケント・ベック、Wikiなどのウォード・
カニンガム、リファクタリングのマーンチン・ファウラーとかが
Smalltalk使いだったことは普通に知られているのでは?
ただ彼らのSmalltalkプログラマとしての実績がどうだったかはよく知らない。

現役Smalltalk使いだとRubyから鞍替えしたSeasideとかのアヴィ・ブライアント、
Perlから出戻りでシュウォーツ変換とかで知られるランダル・シュウォーツとか。
惜しくも先日若くして亡くなられたけど、アンドレアス・ラーブはきっと天才。
あとMVCやDCIの発案者であるトリグヴ・リエンスカウ氏もご高齢ながら現役Smalltalk使い。

334 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
プログラミングは底が浅い

335 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
>>327
Haskell入れるくらいなら史上最も稼いだ言語であるAPLを入れるな。

336 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
Haskellコンプレックス全開

337 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
なんつうか密度の問題だろうな

朝青龍は夢の中で延々と相撲のシミュレーションを繰り返していたらしいけど、

興味ない分野だと、関心を向け続けるだけでも苦痛
その点おまいらは25時間結論の出ない討論を続けてるんだから才能の塊だろ

338 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
リアルに知ってるSmalltalkerがことごとく
気持ち悪いくらいSmalltalkに心酔してて
実際の言動もリアルに気持ち悪いので、
Smalltalkは特別な言語なんだと心から納得してる。

339 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
じゃあ、Lispで俺が知ってるやつな
ジェームス・ゴスリン
円周率計算の当時の世界記録をLispで達成した
またJavaの作者の一人

リチャード・ストールマン
言わずと知れたGnuの創始者
emacs lispやgplなどが有名

340 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
Lispだとガイ・スティールJrも有名人

341 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
ガイ・スティール
Schemeの設計
並行アルゴリズム(GCのスティールのアルゴリズム等)

ピーター・ノーヴィグ
人工知能・分厚いAIの本
Googleの研究部門を率いる


っていうか、ここで話題に出るような言語はどれも有名言語だから
それなりの人物が使ってる事は多いと思うが

342 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
Lisperには、JITのピーター・ドイチュとかもいれたいね

http://www.amazon.co.jp/dp/4274068471

343 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
>>338
Smalltalkはある一線を超えると社会復帰が難しくなるからね
廃人直行言語、というかどちらかというと変態OSに近い環境か

344 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
>>343
嫉妬うざ

345 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
天才プログラマーなら現代の言語javascriptも負けてないよ
Paul Irish、Jeremy Ashkenash、Ryan Dahl
今はこうした若者の時代だよ

346 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
老人たちがSmalltalkでの知識と経験でJS爆速化技術を提供し、
若者たちがモダンなクライアントサイド技術を生み出す。
いい連携じゃん。

347 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
クライアントサイドって面倒だけど低能でもできる仕事だからね

348 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
二人目は言語の作者だし三人目はサーバーサイドだぞw

349 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
サーバーサイドってSQL組み立てて
データベースから値を出し入れするだけの
低能でも出来る仕事だからね。

350 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
SQLインジェクションを全く発生させずにアプリ作るなんて
低能でも出来る仕事だからね、

351 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
大事なのは、JSの爆速化なしには、
CoffeeScriptもnode.jsもないってこと。

352 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
爆速化したのは、ブラウザで動く言語がJSしかなかったことと、
ブラウザ競争の渦中で、巨大企業の資本力がこれでもかと
注入されたことが大きいな。ほかのLL言語では真似できないね。

353 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
>>350
まったくだ。SQLインジェクションを発生させたら
大問題であることを気づいていない。

SQLインジェクションのような簡単な脆弱性は
全く発生させないのが普通。

354 :デフォルトの名無しさん:2013/08/12(月) NY:AN:NY.AN
>>352
LuaJITさんを忘れないであげてほしい

355 :デフォルトの名無しさん:2013/08/13(火) NY:AN:NY.AN
>>345
Paul Irish: Google Chrome Developer Tool, jQuery, Modernizr, Yeoman
Jeremy Ashkenas: Coffee Script, Backbone.js, underscore.js
Ryan Dahl: Node.js

何が衝撃ってCoffee ScriptとBackbonejsとunderscore.jsの作者が同じってことだなw

356 :デフォルトの名無しさん:2013/08/13(火) NY:AN:NY.AN
ほー

357 :デフォルトの名無しさん:2013/08/13(火) NY:AN:NY.AN
もー

358 :デフォルトの名無しさん:2013/08/13(火) NY:AN:NY.AN
やりませんか?

359 :デフォルトの名無しさん:2013/08/13(火) NY:AN:NY.AN
ウフォッ、いい言語

360 :デフォルトの名無しさん:2013/08/14(水) NY:AN:NY.AN
こっちの言語のほうがいい、いやこっちのほうが良い
って何のための議論なんだろうな・・・

ふつーに自分が一番最速で作れる言語を選べよ

361 :デフォルトの名無しさん:2013/08/14(水) NY:AN:NY.AN
短期的にはそれが正しいんだけど、
その果てにあるのは老害コボラーやJavaドカタだからねぇ

362 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
何も無い宇宙空間に浮いている石ころが大きいのか小さいのかは分からない
比較するモノがあって初めてそれが大きいのか小さいのかが分かるのだ
つまり、我々は比較によってモノの価値を決めており
多数の言語があれば当然比較するわけなのだ
これはいわゆる本能なのだ、世界にただ1つだけの花とかチャンチャラおかしい
ことを言って済ませるようなことはしない、かならず比較して優劣を判定している
なぜなら優劣を判定することは生物にとって有益なことだからだ
大多数が良いとするものだけが生き残るのだ
議論とはその過程なのだ

自分1人だけの判定などあまり意味がない
なぜなら1人でできることなど限られているからだ
多様な考えがあればこそ判定がより正確になるのだ
もちろん最終判断をするのはアナタだ
多数ある議論の後にアナタが使う言語はアナタが選ぶのだ

363 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
発明、発見は、歴史で一回しかない。最初は、ひとつ

364 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
言語だけを比較するならHaskellが最強

365 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
Haskell > Python > C >> Perl > OCaml > C++ > Ruby >> C# > Java > JS > PHP

366 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
このあたりが同じ
C言語の系統なのでいい。


C/C++ JS PHP  Java C#

367 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
総合評価は分からないけど、関数型プログラミング適性に限定すれば、以下が妥当では?
(すべての言語について精通している訳ではないので、間違いがあれば指摘ヨロ)

FP
 ---- 壁0. 変数の壁 ----
Haskell
 ---- 壁1. 純粋性(副作用)の壁 ----
F#/OCaml/SML/Scala
 ---- 壁2. 型推論の壁 ----
Scheme/Ruby1.9
 ---- 壁3. 末尾再帰最適化の壁 ----
========<< 越えられない壁 >>========
Common Lisp/Closure/Smalltalk/Ruby1.8
 ---- 壁4. 条件判定式の壁 ----
C++11/Java8/Perl5/JavaScript
 ---- 壁5. クロージャ/ラムダ式の壁 ----
========<< 越えられない壁 >>========
C/C++/Java7/Perl4/Python...etc


[参考] 関数型言語Part5スレ(dat落ち)
http://42ch.blogspot.jp/2013/03/part5.html -- 学ばないブログ
http://fnf.ldblog.jp/archives/5885103.html -- いてつくブログ
http://www.log-channel.com/bbs/tech/1252470706/ -- 2chログチャンネル

368 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
F#って全然名前出ないけどずいぶん上に位置してるんだな。

369 :367:2013/08/15(木) NY:AN:NY.AN
>>367について、いくつか補足

・よく知られた言語で抜けがありました
 Erlangは壁2.の下(Schemeと同列) 、C#は壁4.の下(C++11と同列)になります

・Ruby1.9の末尾再帰最適化はオプション(=デフォルトでは無効)なので、
 その実装が不完全である(=ナンチャッテ実装、TCOモドキ)の可能性があります

・Pyhtonのクロージャは、このスレの>>157以降の議論から不完全であると判断しました

・C++/C++11、Java7/Java8、C#、Perl4/Perl5 に関しては、2chやWikipedia等の
 ネット情報から判断しているので、誤っている可能性が大きいと思います

・壁の優先順序は私の独断と偏見ですので、異論は認めます
 ただし、「壁4.条件判定式の壁」については反論意見が多いのですが、
 これは言語の基本要素であり、設計しようとしている言語が手続き型なのか
 関数型なのかについて、オリジナル言語設計者の選択した結果が反映されており、
 あまりに基本すぎるので後から(付け足しはできても)変更が難しい事柄であると考えます

>>368
F#は関数型言語であるML族の一員であり、特にMSによる.Net実行環境とVS開発環境が
充実していることから、実用性/普及度という点で(個人的には)大いに注目しています

370 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
関数型でないのが登録されてるが?

371 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
素晴らしい表だ

372 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
間違いなくRuby厨

373 :367:2013/08/15(木) NY:AN:NY.AN
>>370
比較の観点が「関数型言語」ではなく、
「関数型プログラミングの適性」ですので....
XXX型プログラミングはスタイルなので、
関数型プログラミングは非関数型言語でも適用できます

374 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
constexprやTMPは駄目ですかそうですか。

375 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
Haskellも変数ないけど、変数の壁ってどういうの?
Monadとかも一切使えないってこと?

376 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
>>369
> ・Pyhtonのクロージャは、このスレの>>157以降の議論から不完全であると判断しました

ほとんどマトモに議論されてないじゃん。もしかしてnonlocalのことか?

377 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
>>367
関数がファーストクラスかってのが一番重要な最初の壁だと思うのだが……
その観点だと、OO言語の場合、メソッドがファーストクラスオブジェクトかという
視点は外せないのでは

378 :367:2013/08/15(木) NY:AN:NY.AN
>>375
値が束縛された名前は変数と呼ばれ、Haskellにはありますが、FPにはありません
そしてラムダ式が束縛された名前は関数と呼ばれますが、この関数とアトムだけを
組み合わせる、つまり変数が存在しないプログラミングスタイルがFPの特徴の一つです

379 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
あと、>>367に挙がっていないけど、式志向かどうかってのも
篩として分かりやすい気がするな

380 :367:2013/08/15(木) NY:AN:NY.AN
>>376
失礼、Python3では予約語nonlocalが追加された事で、
まともな(=不完全ではない)クロージャとラムダ式が使えるようになったみたいですね
次回、>>376を更新するときに訂正しておきます

あと>>376の「超えられない壁」については、上段はRuby1.9が、下段はCを除く
最後尾列の言語すべてが乗り越えてしまったので、見直しが必要かもしれません

381 :367:2013/08/15(木) NY:AN:NY.AN
>>377
「関数が一級市民(ファーストクラス・シチズン)であるか否か」という視点は、
「関数型言語であるか否か」という比較では決定的な要因であると思いますが、
今回の「関数型プログラミングの適性」という比較では重要でないと考えました

ただ単に「関数が一級市民である」ことならラムダ式があれば満足できるし、
ラムダ式でなくともクロージャ(一部OOP言語のブロック)で簡潔に記述できます
また、「関数が一級市民である」ことの最も典型的な応用は関数合成だと思いますが、
カリー化されていない関数では柔軟な関数合成プログラミングには適さず、
その程度であればOOP言語のメソッド結合(チェーン)で簡単に書き換えできます

もしも
・「関数が一級市民である」ことが特徴的なコードの一例を提示でき、そのコードが
・ラムダ式やクロージャでは代用できず、
・カリー化されていない関数でも効果的で、かつメソッド結合では代用できず、
・しかも関数型プログラミングでは一般的なプログラミング技法である
ならば、この重要でない考えを撤回するでしょう

382 :367:2013/08/15(木) NY:AN:NY.AN
>>381の最終行を訂正

X: この重要でない考えを撤回するでしょう
O: この(「関数が一級市民であるか否か」は)重要でないという考えを撤回するでしょう

383 :367:2013/08/15(木) NY:AN:NY.AN
>>379
式指向がどうかっていうのは、「壁4.条件判定式の壁」を一般化したものですね
if や case/switch といった条件判定が構文上で式(expression)として定義されているか、
それとも文(statement)であるか、という差異になります

式指向の他の例には、return文の有無もあります
式指向であれば、return文が存在しないかオプション(省略可能)ですが、
文指向であれば、有効な値を返す手続きではreturn文が必須になります

式指向という単語は便利なので、次回、>>367の更新では採用させてもらいます

384 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
>>378
関数やアトムと値を別物だと思ってる時点で
何も分かってない半可通だと分かる

385 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
>>378
>値が束縛された名前は変数と呼ばれ
たしかに名前束縛がないならFPのが確かに純粋度?が高いように見えるね
ただ一言言うと、それは名前で束縛された代数的な数ではあるけど変数ではないよ
知ってるならなおさら間違えちゃ駄目でしょ

386 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
>>381
その辺の取捨選択や順序づけにやや恣意性を感じると言うか……
カリー化されていることが重要だと思うんなら入れればいいし

一次元的に分けるのがそもそも無理なのではないか、とは思わないの?
言語Aはア、イの要素を満たして言語Bはイ、ウの要素を満たす的な
状況普通にあると思うしね

387 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
Rubyを上に持ってきたいんじゃないの?

388 :367:2013/08/15(木) NY:AN:NY.AN
>>385
言いたい事は分かるのだけれど、「値が束縛された名前」について
「変数」という単語よりも適切な概念の名称について、提案を願う

ここは言語理論板/スレではないし、変数という言葉以外に
直感的で的確なものは(自分には)考えつけないや

389 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
そんなもん、Alias(別名)でいいやん

#define max 100と似たようなもんだから
マクロってのもありかな。

390 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
367は、変数束縛をなるべく使わないPointfreeスタイルで書くのが
関数型プログラミングって言いたいワケか?

391 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
ラベルっていうのもありかもな。

392 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
Java8のSAMタイプの構文糖をクロージャだと思ってる時点で
色んな意味で無知すぎる

393 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
>>392
どっちかっていうと言葉尻を捉えて必死になってるお前の方が無知に見えるよ

394 :367:2013/08/15(木) NY:AN:NY.AN
>>386
>その辺の取捨選択や順序づけにやや恣意性を感じると言うか……

それは>>369で書いたように、私の独断と偏見だから恣意的そのものですよ

>>一次元的に分けるのがそもそも無理なのではないか、とは思わないの?

当然そう思うし、複数の切り口(ファセット)で総合的に評価するのが望ましいと思う
具体的には、横軸に言語を並べ、縦軸に切り口を並べた二次元の表になるだろう
でも、残念ながら2chの1カキコの範囲内では表現には限界があるので、
>>367のような(恣意的に)1次元へと切り取った表現を選ばざるをえなかった

ただし、この恣意性があるから各自の哲学/思想というか立ち位置の差異がかいま見えて、
議論(バトル)として楽しめるのではないかと思う
この表(の哲学/思想)を無理に押し付けるつもりはないし、これとは別の切り口、たとえば
>>377の「関数が一級市民であるか」を加えたり、個々の壁について優先度を変えたりした
(>>367に対する)異論/反論が出る事は、スレ的に歓迎したいし、個人的にも嬉しい

395 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
> ただし、この恣意性があるから各自の哲学/思想というか立ち位置の差異がかいま見えて、
> 議論(バトル)として楽しめるのではないかと思う

まさにその通り。
立場を曖昧にした毒にも薬にもならない表なんて何の価値もない。

396 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
変数束縛なんていうから難しくなるけど
要するに、証明の問題とかである

○○をXとおくと〜

みたいな文章のことだよね?

397 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
恣意的な上に無知

398 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
お前が無知だろw 反論しないのがその証拠

399 :367:2013/08/15(木) NY:AN:NY.AN
>>389,391
エイリアス(別名)について:
 別名は実名の対比語だと思うけど、そもそも値には名前が無い訳から違和感を感じる

マクロについて:
 マクロと「似たようなもの」ということは、変数と同様に厳密性に欠けると思う

ラベル:
 これがイイかもしれないけど、「値が束縛された名前」という概念を指す言葉として、
 変数よりも一般的(常識的/直感的)かは疑問が残る

たとえば、WikipadiaのHaskellページ(日本語)では変数という言葉が使われていて、
その定義も備考で説明されている
おそらくWikipediaは非専門家向けの表現が選ばれていると考えられて、
このページの変数という単語を置き換えても大半の人から賛同できるものを選びたい

他の人の意見も聞きたいので、この件は判断を保留します

400 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
「値が束縛された名前」なんて素っ頓狂なこと書いて
自分で疑問にも思わない時点でアホすぎる

401 :367:2013/08/15(木) NY:AN:NY.AN
>>390
Haskellであれば、Pointfreeスタイルで書くのが関数型プログラミングらしいと思うよ

そして、副作用である「変数への再代入(破壊的代入)を一切許さない」のが、
>>367で下に位置するML族と区別するHaskellの最大の特徴であると考えていて、
それならば「変数そのものの存在を一切許さない」FPは「究極の関数型言語」だと思う

402 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
あー、RubyユーザはPointfreeスタイル好きそうだね
なるほどなー

403 :367:2013/08/15(木) NY:AN:NY.AN
>>392
>>369で書いたようにJavaについては素人だし、その最新動向は無知だね
もしも>>392が正解を知っているのなら、教えて欲しい
>>367の更新に反映させたいので....

404 :367:2013/08/15(木) NY:AN:NY.AN
>>396
そのとおりだね

で、そのXのこと(概念)を
・証明の世界では、どんな名前が命名されていて、
・その名前はプログラミングの世界でも一般的(常識的/直感的)か?
という比較が論点になる

405 :367:2013/08/15(木) NY:AN:NY.AN
>>402
どちらかというと、HaskellのPointfreeスタイルよりも、
F#のパイプライン演算子のほうが
Rubyのメソッドチェーンの発想に近いと思う

406 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
f x y = 2 * (x + y)

g = ((.).(.)) (*2) (+)


fよりgの方が関数型プログラミングらしいの?

407 :367:2013/08/15(木) NY:AN:NY.AN
>>406
Pointfreeスタイルが適切か否かは、扱う問題(対象領域)によりけりだと思う
少なくとも問題が>>406の単純な計算式であれば、f のほうがHaskellらしいでしょ?
でも、問題が大きくなった時に、それをPointfreeスタイルで書けるような部品(関数)へ
適切に分解できるようにする発想(思考の転換)は、究極の関数型プログラミングへの
第一歩だと思うよ

Pointfreeスタイルで書くことは(表現の)手段であって、目的ではない
プログラミングという行為を、再利用可能な部品への分解と見立てることが
関数型プログラミングらしさ、つまりスタイルだと考える

あと、究極への道はFPだけではないよ
関数と写像よりも抽象化した圏と見立てる発想、Haskellのモナドも究極への第一歩
Haskellは圏論の一部を利用しているけど、もし基礎から圏で構成した言語が登場すれば、
それもまた究極に関数型言語と呼ぶにふさわしいのではないかと思う(妄想だけどねw)

408 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
>>367
お前の話はつまらん。
Haskellファンだか関数型ファンだか知らないが、
スクリプト言語語る場にのこのこやってきて
目的外使用を想定した適不適のわけのわからんレッテル貼りして
揚げ足取りして悦に入る以外に何がやりたいのかさっぱり分からない。
関数型したいなら黙ってHaskellでも使ってりゃいいじゃん。こっち来るな。
Haskellだの関数型だのの宣伝がしたいなら、もっと賢いやり方があるだろう。

409 :367:2013/08/15(木) NY:AN:NY.AN
とりあえず、ここまでの指摘について>>367を更新しました

FP
 ---- 壁0. 変数の壁 ----
Haskell
 ---- 壁1. 純粋性(副作用)の壁 ----
F#/OCaml/SML/Scala
 ---- 壁2. 型推論の壁 ----
=====<< 越えられない壁 >>=====
Scheme/Erlang/Ruby1.9
 ---- 壁3. 末尾再帰最適化の壁 ----
Common Lisp/Closure/Smalltalk/Ruby1.8
 ---- 壁4. 式指向(条件判定式)の壁>> ----
=====<< 越えられない壁 >>=====
C++11/Java8/C#/Perl5/Python3/JavaScript
 ---- 壁5. クロージャ/ラムダ式の壁 ----
C/C++/Java7/Perl4/Python2...etc


[変更点]
・Erlang と C# を新規に追加 -- >>369
・PythonをPython3とPython2へ分離 -- >>380
・壁4.の定義を変更 -- >>383
・「越えられない壁」を移動 -- >> 383

・壁0.の「変数」という単語については保留中 --> 399
・Java8については保留中 -- >>403

410 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
式指向(条件判定式)の壁って何?

411 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
再利用可能な部品に分ける事とPointfreeは全く何の関係もねーよ
ほんと半可通だな

412 :367:2013/08/15(木) NY:AN:NY.AN
>>410

>>383を参照

413 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
>>408
無知は黙っとけよ。
お前のレスが一番中身なくて邪魔。

414 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
everything is an object / object oriented の対比として
everything is an expression / expression oriented という言葉がある
Lisp族をはじめとする関数型言語は普通はそうなってる

415 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
C++にもJavaにも三項演算子あるじゃん
まさか、三項演算子は読み書きしにくいなんて恣意的な理由?

416 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
Python は sortedlist = lst.sort() とかする初心者が後を絶たないから教育言語失格

417 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
こんな挙動を示すRubyが式指向とか、無いわー

x = for i in 1..10
        i * i
    end
p x #=> 1..10

418 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
返り値が必要な場合にまで for 使う人はいないんよ

419 :デフォルトの名無しさん:2013/08/15(木) NY:AN:NY.AN
>>417
すげえ直観に反する動作だな
CLのLOOPマクロみたいなリスト内包もどきでもないし
最後に評価した値でもない
何でそうなるんだ?

420 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
式指向にわざわざ(条件判定式)って付けてたのは
Rubyが条件式以外はキモい挙動だからか

421 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
関数型が優れてるという前提なのか?
関数型はあまり使われてないし、基本文法よりも
有名な、追加のライブラリ次第でシェアや使いやすさは変わるが。

422 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
>>419
Rubyの for x in xs; ... end は xs.each{ |x| ... }、つまりメッセージ指向的に言うと
xs への each{ |x| ... } というメッセージ送信のシンタックスシュガーなので
eachというメソッドがレシーバを返す仕様がゆえに for でも xs が返るという流れ。

423 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
eachじゃなくてinjectのシンタックスシュガーであるべきだったね > Rubyのfor

424 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
>>422
なるほどメソッドチェーン用にselfを返すようになってるメソッドを
そのままforに転用してるからか
説明されれば理屈としては分かるが、for式の値として見ると気持ち悪いな

425 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
関数型に売りがあるのはまあ分かるんだけど、
よくよく聞いてみると、その多くにはトレードオフがあって、
結局のところ無理をしたり何かをねじ曲げたりするか(例えば要求仕様とかw)
逆に関数型側の大事な何かを(例えばSchemeやOCamlやScala程度には)
諦めない限り、既存の言語を置き換えるまでには使えない代物って印象だなぁ。

これは半分冗談だけど、本当にそんなに良いことばかりなのであれば
たとえばAPLなみhttp://www.youtube.com/watch?v=a9xAKttWgP4
さくっと、そして関数型の売りの一つである見通しのよさと美しさを
実感できるライフゲームを組んでみて欲しいと常々思う。(反語的に)

426 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
python初心者なんですが、
from OOO import*
として複数のファイルからdef main():
のみ実行している?のですが、
ex.)
main.py
#!/usr/bin/env python
import OOO
p = OOO.OOO
(以下略

OOO.py
class OOO(以下略

とあって form OOO import* とimport OOOについて、
from OOO import* はあまりおすすめしないと書いてあったのですがその理由がわかる人がいたら
ご教授願います

427 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
>>426
マルチ乙

428 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
型推論もLispマクロも無いのに
関数型に近づけてもメリット無いよね

つまり、Rubyはウンコ

429 :367:2013/08/16(金) NY:AN:NY.AN
>>415
三項演算子は少し前に派生スレの「[JavaScript] スクリプト言語34 [Perl,Python,PHP]」で
議論があったけど、条件分岐 if が式で三項演算子もある Ruby であれば、
三項演算子を使うのはその式が1行に収まるくらい単純な分岐の場合、
あるいは条件分岐が入れ子になった時に最も深い分岐で使うのが効果的

a = if cond1
    cond1a ? v11 : v12
  elsif cond2
    cond2a ? v21 : v22
  else
    cond3a ? v31 : v32
  end

430 :367:2013/08/16(金) NY:AN:NY.AN
>>421
>>194でも書いたけど、Rubyでは、たとえば以下のような関数型プログラミングの
スタイルは、すでに特異なものではなくなっている
  collection.select { |e| ..... }.map { |e| .... }.sort { |x, y| ....}
もちろん可変オブジェクトの使用がゼロ、つまり純粋関数型プログラミングではないが、
大域的な可変オブジェクトを極力減らし、できる限り(Rubyであれば上記コードのような)
不変オブジェクト間の演算で計算を進める方向性が見える

関数型が優れているのか?という疑問に関しては、高品質コード設計では優れているが、
効率面では再代入(=破壊的代入)が基本である手続き型に劣るだろう
ただし、これも(Rubyは純粋関数型ではないから、)性能面でボトルネックとなっている
部分を手続き型で書き、それをメソッドやクラスで隠蔽するといったコード設計ができる

あるいは絶対的な効率が重視されるプロジェクトであれば、>>409の壁1.と壁2の間に
位置する静的型付け関数型言語を選ぶことで、コード品質と効率を両立できる
大規模Webサイト開発でサーバサイドのフロントエンドをRailsで、バックエンドを
Scala(およびJava)で採用したという事例があるけど、これはベストマッチだと考える

431 :367:2013/08/16(金) NY:AN:NY.AN
>>417-424
反復(for や while の構文)での返り値が不可解であることは、同意する

言語仕様が実装に依存するというのは、言語設計として好ましい事柄ではない
おそらく(>>423が提案する)injectを基本にした仕様とするか、あるいは
単純に nil を返すという決定を下すだけでよかったと思うが、Rubyの残念な一面だ

ただし、>>418が指摘しているように、Rubyの関数型プログラミングでは、
for/while構文を無理して使うよりも、(>>430のコード例のような)Enumuratorを
使うのが一般的なので、現実のプログラミングでは問題にはならないと思う
実際のところ、他にも不可解な返り値にはクラス/メソッド定義にもあるけど、
反復を含めてこれらの返り値を参照するコードを書いた記憶が(自分には)無い

432 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
>>429
そんなスタイル見たことない

433 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
>>431
実装に依存する部分は言語仕様じゃないんじゃないの?

434 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
三項演算子を使うやつはバカ

435 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
>>434
同意

436 :367:2013/08/16(金) NY:AN:NY.AN
>>432
そりゃそうだろね
条件判定が入れ子になるような複雑なロジックで、なおかつ最も深い条件判定が
1行に収まるケースなんてレアケースだから、見たことないのも無理はない
言い換えると、if ... else ... という条件判定が式指向である言語にとって、
三項演算子の重要性は低いということ

また、そもそも>>409の「式指向の壁」を越えた言語よりも越えられない言語のほうが
利用者の数(=シェア)では圧倒的に多いのだから、関数型プログラミングのスタイルに
とまどいを感じるプログラマが少なくないのも無理からぬ話だと思う

437 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
>>434,435
なんで?

438 :367:2013/08/16(金) NY:AN:NY.AN
>>433
現実世界で「動いているものが仕様である」という考え方はよく見かける
で、このRubyの「不可解な返り値」のように実用上の問題が無いのであれば、
それを「些細な事柄」として無視する現実的な判断は、決して間違いではないと思う

ただし、これが「些細な問題」ではなく「無視できない問題」になるのは言語処理系の開発
たとえばRubyはISO/JIS規格化されたけど、その範囲は全体のごく一部にすぎない
それ以外の多くはMRI(Matzが開発したC実装)の「動いているものが仕様である」に従う
Ruby実装にはMRIの他にいくつか登場しているけど、どれも開発には苦労していると思う

逆に、言語仕様のすべてが文書化されているのは、(自分の知る限り)>>409中ではSMLだけ
SMLは、構文仕様はもちろんのこと、その意味論についても操作的意味論によって
言語のすべての範囲について「形式的仕様」が定義され、文書として出版されている
実用性ではF#やOCamlに劣るかもしれないが、言語処理系の研究者/設計者にとって
SMLは「理想の姿」であり、(日本を含む)世界のあちこちで処理系が開発されている

439 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
そもそも不可解ってほどでもないなあ
nil を返されるとそれ以上何もできない
だったら有用性の面から self 返しとくってのは合理的ではないかと

inject ベースの for が何を指すのかよくわからないけど
新しいオブジェクトを作って返すのならコピーのコストがかかるから
for の用途にはそぐわないだろう

440 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
>>439
たぶんLispのdolistみたいなものを想定してるんじゃないのかな
アキュミュレータを使わなければただのforeach的なループと同等で、
アキュミュレータを使えばinjectっぽいことができる
dolist式の値はアキュミュレータの最後の値だからコピーのコストは気にする必要はない
foreachっぽいことをやるだけならnilになる

441 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
チェインでパイプしてくのが関数的なら
今のjavascriptも変わらんだろ

442 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
>>440
ごめんコピーじゃないね
(アキュムレータに)溜めこむ過程のコストって言えばよかった

いずれにしても for/each はあくまで foreach 的なループができればそれでいいな
ベクトルの異なる複数の機能を詰めこんであると学習しにくくなるしコードが読みにくくなる

443 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
>>429
Rubyにif式と三項演算子の両方があるとか、無いとか、そんな話は全然関係無くて
条件分岐を式で書けるか否か、という話だろ

C++やJavaは三項演算子があるので、条件分岐式が存在する
それにも関わらずC++やJavaが式指向の壁の下に居るのは何故だ?
単に367の主観に過ぎないだろ?

まあ、主観だから100%悪いとは言わないけど、
大体、参照透過や型推論や末尾再帰最適化やクロージャの有無に比べて
主観が入りすぎてて気持ち悪い

444 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
あと、Common Lispは末尾再帰最適化する処理系が多いのに、
デフォルトで末尾再帰最適化がオフのCRubyより下に居るのも変だと思うよ

445 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
三項演算子で人をバカかどうか判定しているやつはバカ

446 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
ただのRuby厨なんだからそっとしといてやれ

447 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
パターンマッチの壁が無いあたりが
Ruby厨の限界を表している

448 :367:2013/08/16(金) NY:AN:NY.AN
>>443
>Rubyにif式と三項演算子の両方があるとか、無いとか、そんな話は全然関係無くて
>条件分岐を式で書けるか否か、という話だろ

もちろんそのとおりで、三項演算子の有無は評価基準とは無関係だ

>C++やJavaは三項演算子があるので、条件分岐式が存在する
>それにも関わらずC++やJavaが式指向の壁の下に居るのは何故だ?

前段で書いたように、三項演算子の存在は評価とは無関係だよ
C++やJavaには条件判定の基本要素として if ... else .... があるけど、
これが構文上で式(expression)ではなく文(statement)として評価されていることを重視する
もしC++やJavaが式指向であれば、HaskellやMLといった関数型言語と同様に
最初の言語設計の時点で、if ... else .... は式として定義する判断がなされていたはず

>大体、参照透過や型推論や末尾再帰最適化やクロージャの有無に比べて
>主観が入りすぎてて気持ち悪い

参照透過性は「壁1. 純粋性(副作用)の壁」に含まれるし、他も評価基準に含まれているよ
>>369,394で書いたように壁の順序には(自分の)恣意性があることは認めている
「気持ち悪い」という主観的な感情を吐くだけよりも、>>443が平等と考える
評価基準と並びを提示するほうが、議論(バトル)として有意義なんジャマイカと....

449 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
関数型ワナビーのル厨か。
気持ち悪いの二乗だよ。
こりゃまためんどくさいのが居着いたな。

450 :367:2013/08/16(金) NY:AN:NY.AN
>>444
仕様として明記されているSchemeと区別する意味で未実装と判定したのだけど、
Common Lispの実用的な処理系の大半で、末尾再帰最適化は実装されているのかな?

もしその通りであれば、言い換えると誰からも反論が無ければ、
自分の無知であったので、>>409を次回に更新する時にCommon Lispの位置を訂正します

451 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
つまり、C++やJavaにif-elseがなければ式指向ということだな?
関数型らしからぬ機能があるのがダメだということはRubyは相当下になるのでは?

452 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
> 仕様として明記されているSchemeと区別する意味で未実装と判定したのだけど、

Rubyだって仕様に明記されてないのに、しれっとSchemeと並べてるのがRuby厨すぎるわ

453 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
>>447
それは思った。名前束縛の件もそう。
やっぱり言う割にまともに関数型言語使ってないんだな。

454 :367:2013/08/16(金) NY:AN:NY.AN
>>443
構造的等値なパターンマッチ機構が便利であることは確かで壁の候補として検討したけど、
>>409の(FPを除く)壁2.より上に位置する言語ではすべて実装されているし、
壁2.より下では Erlang だけのように見える(他にもあるかな?)
だから、Erlangを区別するだけのパターンマッチは、
評価基準として「壁2. 型推論の壁」よりも弱いと考えました

455 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
お前、erlangファンを舐めてるのか?あん?

456 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
そんなこと言ったら壁0や壁1も一つの言語しか区別してないだろ

ていうか壁0って誰得だよ?lazy Kやunlambdaみたいな実用的じゃないものを並べてんじゃねーよ

457 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
>>453
しょせんワナビー

458 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
AgdaやCoqも加えてあげてください

459 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
SBCLは末尾再帰最適化されているな
clispはコンパイルすれば最適化される

460 :367:2013/08/16(金) NY:AN:NY.AN
>>451
>つまり、C++やJavaにif-elseがなければ式指向ということだな?

何を言いたいのか、意味が分からない

if-elseの無いC++やJavaに、プログラミング言語として何の意味があるの?
無意味な仮定を持ち出して決めつけを行うのは「詭弁(きべん)」だよ


>関数型らしからぬ機能があるのがダメだということはRubyは相当下になるのでは?

いちども「関数型らしからぬ機能があるのがダメ」とは言っていないはずだが、
これも何を言いたいのか、意味が分からない

条件判定はあらゆるプログラミング言語に存在する基本要素だよね
関数型プログラミングでも、条件判定式は関数適用式やラムダ式と組み合わせて、
プログラムのあらゆる箇所で使われる
だから if ... else ... という基本構文が式であることを重要視しているだけのこと

461 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
>>360
>if-elseの無いC++やJavaに、プログラミング言語として何の意味があるの?
>無意味な仮定を持ち出して決めつけを行うのは「詭弁(きべん)」だよ
別人だけど俗に言うc-likeなら3項演算子があるだろう

462 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
Rubyは適当にパーサ作ったら偶々いろんなものが値を返すようになっただけで、
関数型うんぬんなんて高尚(?)なもんじゃない


こんな意味不明な動作をする言語だよ?

x = 1
p(x + x = x + x = x + x) #=> 4

463 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
>>461
367は三項演算子で条件分岐できるのが分かってない予感

464 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
複数ステートメントについてもC#などラムダのあるC系なら
a = cond1 ?
  (() => { X; Y; })()
 : cond2 ?
  (() => { Z; })()
 :
  W;
と書けないことはないな

465 :367:2013/08/16(金) NY:AN:NY.AN
>>455,456
わかったw、Erlangファンの意志を尊重し、
>>409を次回更新する時に「パターンマッチの壁」を追加することを約束します

なお、壁0. についても、過去に(関数型言語スレで)指摘されたことで
後から追加したことを補足しておきます

>>458
AgdaやCoqは(プログラミング言語ではなく)証明系なので、却下します

>>459
これは>>450への肯定的なレスですね

466 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
Pythonを下げてRubyを上に上げた意味が一番わからない
食わず嫌いじゃないのか?
それと関数型風に出来ればいいならC++98だってboost-phoenixみたいのもある
基準が変だよ

467 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
>>462
何でそうなるんだ?

468 :デフォルトの名無しさん:2013/08/16(金) NY:AN:NY.AN
459は何も450を肯定してねーだろ
しったかなやつだなーと

469 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>466
これの上の部分の詳細を書くとPython2.5で既にlambdaもif式もあった
それでRubyだけ何で特別扱いなんだ

470 :367:2013/08/17(土) NY:AN:NY.AN
>>461,464
・if-else構文と三項演算子があるC系言語において、使用比率はif-else構文が圧倒的に多い
・C系言語でも(if-else構文をあえて使わず)三項演算子だけでプログラムを
 「書けないことはない」が、if-else構文を使う方がC系らしいプログラミングであるし、
 可読性も(三項演算子だけよりも)if-else構文のほうが優れている

これは事実だと思うけど、いかがかな?

そして、それだけ条件判定としての if-else 構文は重要な要素だと評価したことで、
if-else構文が式であるか否か、すなわち式指向であるか?を壁として選んだ
ただ、それだけのこと

471 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
本当に主観だけで決めてるな
ランク製作者の独断できまるランキングスレなんて初めて見た

472 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>470
で、Rubyにおいてif-elseの式の値を利用していることはどれくらいあるだろう?
それはC言語における ?: / if-else の割合と比較して有意に大きいと言えるの?

473 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
こんなに綺麗な論破初めて見たw

474 :367:2013/08/17(土) NY:AN:NY.AN
>>466
>Pythonを下げてRubyを上に上げた意味が一番わからない
>食わず嫌いじゃないのか?

>>409は「関数型プログラミングの適性」について(>>367)、
「関数型言語が上に手続き型言語が下に並ぶ」よう、壁とその位置を考えただけですよ
Pythonが下にあることがご不満なようですけど、そうであれば
「関数型言語が上に手続き型言語が下に並び」かつ「Pythonが上位に来て」しかも
「客観的な(=できるだけ恣意性を排除した)」ものを提示すればいいんジャマイカと....

>それと関数型風に出来ればいいならC++98だってboost-phoenixみたいのもある
>基準が変だよ

関数型プログラミングはスタイルですから、あらゆるプログラミング言語に適用できます
ただし、その適性度には言語によって差異があるという話です
C++の例であれば、特定のライブラリを利用しなければ関数型プログラミングに
適さないC++98よりも、最初から言語仕様として規定されているC++11は上位になります

475 :367:2013/08/17(土) NY:AN:NY.AN
>>472
Rubyの関数型プログラミングにおいて(変数の再代入を避ける為に)
「if-elseの式の値を利用」することは基本中の基本であり、
その比率は(同「値を利用しない」ケースと比較すれば)圧倒的に多いよ

以下の文書の節「変数を更新してはいけない」と「あらゆるすべてが式である」を参照
・Rubyによる関数型プログラミング -- Functional programming with Ruby
 http://www.h6.dion.ne.jp/~machan/misc/FPwithRuby.html

実際にこの文書に沿って、10数キロステップの実用的なRubyプログラムの開発に
関数型プログラミングの適用を試してみたが、
そのおよそ70%で純粋な(=副作用の無い)コードを書くことができた
その70%の中で「if-elseの式の値を利用」することは当たり前(=100%)だし、
保守性を重視して(コードの短縮よりも)読みやすいコードを意識したから、
三項演算子は一度も利用することは無かった

476 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>474
>最初から言語仕様として規定されているC++11は上位になります
C++11はconstexprを含んでその位置なのか?
if-elseもないし定数への展開じゃなければ
コンパイラが末尾再帰最適化もしてくれるが

477 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
理解できた
パイプでつなぐようなスタイル(Haskellのポイントフリー)が
関数型スタイルだって言ってるのか
心の底からRuby厨だわな
根本的なところで違うんだからそりゃ話が咬み合わないわけだ

478 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>475
圧倒的に多いと言える根拠は?
三項演算子の一般的な利用頻度にかかわらずC系で三項演算子を使えば関数型っぽくはなるが、
そうではなくて>>470は一般論としてどっちが多いかの話じゃなかったの?

479 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
無駄だよ無駄
こいつただのRuby厨だから

480 :367:2013/08/17(土) NY:AN:NY.AN
>>478
「Rubyの関数型プログラミング」において圧倒的だというのは、
>>475で示した(ガイドラインとしての)文書と
(自分の個人的な)実経験が根拠であるというのは、理解してもらえるよね?

そして、「Rubyの手続き型プログラミング」であれば、そもそも
if-else式の値は参照しない、つまりC系言語のif-else構文と同じだ
で、それに関して三項演算子との使用頻度の比較は、RubyもC系も同程度ではないかと

不思議なことは何も無いと思うんだけど、何が不明なの?

481 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
つまるところ三項演算子をif-elseで書けるから見やすいと言ってるだけだろう。わかるよ。
でもコードの見やすさなんていう観点を持ち込むんなら
随分とランキングは変わってくると思うけどね。

482 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
もうわかっただろ
まともに使ってるのRubyだけなんだって

483 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
要するに、

(Ruby厨が考えるRubyの機能の範囲で実現可能な)
関数型っぽいことが一番うまくできるスクリプト言語はRuby!

って話なんだから、こいつをひっくり返すのはかなり難しいよw

484 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
次スレからRuby使いは排除だな

485 :367:2013/08/17(土) NY:AN:NY.AN
>>469
Python2.5にはクロージャが無かった(もしくは不完全であった)からだよ

そしてPython3でまともなクロージャが採用されたことを指摘されたことで、
つまり自分の不勉強によって知らなかったことをふまえて(>>380)、
その指摘を>>409で反映し、Python3を上に位置付けた
それに何かご不満でも?

今後も、誤認の指摘や説得力のある(=客観的な)意見があれば、更新を続けます

486 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
JavaScriptは? (・∀・)ニヤニヤ

487 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
なんでpythonでnonlocalクロージャができると関数型になるん?
逆じゃないの?

488 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>485
きちんと答えておかないと駄目か
>つまり自分の不勉強によって知らなかったことをふまえて(>>380)、
>その指摘を>>409で反映し、Python3を上に位置付けた
>それに何かご不満でも?
関数型のプログラミングに近いかどうかを論点にしてるのに
なんで再代入を良しとするわけ?
その観点からみたら逆でしょ?

489 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>485
なんでnonlocalがあるとまともなんだ?
Rubyもそうだが、外の変数へ再代入できたらお前の思う関数型に近づくのか
と思ったら487が書いてた

490 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
実質機能してない末尾再帰最適化を拠り所にして
Rubyが1.9で壁を越えているのは認められない。
これを許すのなら、C系言語において三項演算子で
関数型条件分岐が可能とか、もっと配慮があってしかるべき。

491 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
ここまで論破され続けてもめげないのは評価するけど
本当に宗教なんだなrubyって

492 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
Rubyは宗教
Perlは文学

493 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
Rubyってコードブロック内から外を呼び出すような再帰は最適化できるの?
多くのケースで当てはまるはずだけど実装難しそう

494 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
クロージャが不完全云々という理屈を使っていながら
C++11 > Python2とするのはよくわからんな
C++は言語仕様的に変数に暗黙的な無限エクステントを与えられないから
C++11でlambda導入されたといっても、funarg問題を解決するために
キャプチャが必要な変数に関する情報を手動で明示しないといけない仕様だぞ

とにかく目的は達成できる、という意味でC++11のクロージャが許容できるのなら
同じ理屈でPython2のnonlocalなしも許容できるだろ
上位のローカル変数に代入できないが参照はできるから、下のように書けばいいだけ

def make_accumulator():
 acc = [0]
 def add(n):
  acc[0] += n
  return acc[0]

ついでに言えばこのように環境を書き換えるのクロージャは参照透明性を持たない訳だが
参照透明性を汚すタイプのクロージャへのサポートが不十分であることが
なぜ関数型プログラミング適性において劣ることになるんだ?
自分で純粋性(副作用)を重視していることと矛盾しているとは思わないのか?

495 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>492
宗教つーかヤバイ薬じゃね

496 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
正直Rubyは体が受け付けない
コード見てオナニーする趣味はないから誰でも似たようなコードになる言語でいいよ

497 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
Ruby はいい言語だけど彼のレスは体が受けつけない

498 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
Javascriptは関数型ハイブリッド言語。


Javascriptのクイックソート。
Quicksort = function (xs) {
if (xs.length <= 1) return xs;
var pivot = xs[Math.floor(xs.length/2)];
return (new Array).concat(
Quicksort(xs.filter( function(x){ return pivot>x;})),
xs.filter( function(x){ return pivot==x;}),
Quicksort(xs.filter( function(x){ return pivot<x;})));
};

499 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>495
なんせモルモン教徒が伝道活動を通じて会得した
様々なテクニックを駆使して広めた言語だからね。
喩えとかじゃなくガチで宗教だし、宗教としてもかなり特殊。

500 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>498
マジでreturnとfunctionがうざすぎる

501 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>500
タイピングスピード遅いの?

502 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>501
なんでそうなる

503 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
Scalaのクイックソート


def sort(xs: Array[Int]): Array[Int] = {
if (xs.length <= 1) xs
else {
val pivot = xs(xs.length / 2)
Array.concat(
sort(xs filter (pivot >)),
xs filter (pivot ==),
sort(xs filter (pivot <)))
}
}

https://sites.google.com/site/scalajp/home/documentation/scala-by-example/chapter2

504 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>498 >>503
インデントがないとすごく見づらいってことが
よく分かるなw

505 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>498
やっぱり駄目言語だな

506 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
Prologのクイックソート

sort([], []).
sort([H|T], S) :- partition(T, H, L1, L2), sort(L1, S1), sort(L2, S2), append(S1, S2, S).
partition([], _, [], []).
partition([X|L], Y, [X|L1], L2) :- X =< Y, partition(L, Y, L1, L2).
partition([X|L], Y, L1, [Y|L2]) :- X > Y, partition(L, Y, L1, L2).

507 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
せめて名前と書き方とインデントぐらい調整してやれよ。

var quicksort = function (xs) {
  if (xs.length <= 1) return xs;
  else {
    var pivot = xs[Math.floor(xs.length/2)];
    return (new Array).concat(
      quicksort( xs.filter( function(x){ return pivot > x } ) ),
      xs.filter( function(x){ return pivot == x } ),
      quicksort( xs.filter( function(x){ return pivot < x } ) )
    );
  }
};



def quicksort(xs: Array[Int]): Array[Int] = {
  if (xs.length <= 1) xs
  else {
    val pivot = xs(xs.length / 2)
    Array.concat(
      quicksort(xs filter (pivot >)),
      xs filter (pivot ==),
      quicksort(xs filter (pivot <))
    )
  }
}

508 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
var quicksort = function (xs) {
  if (xs.length <= 1) return xs;
  else {
    var pivot = xs[Math.floor(xs.length/2)];
    return (new Array).concat(
      quicksort( xs.filter( function(x){ return pivot > x } ) ),
      xs.filter( function(x){ return pivot == x } ),
      quicksort( xs.filter( function(x){ return pivot < x } ) )
    );
  }
};

↓ArrayExというオレオレライブラリを作るとこうなる。

function quicksort(xs) {
  if (xs.length <= 1) return xs;

  var pivot = xs[Math.floor(xs.length / 2)];
  return ArrayEx.concat(
    quicksort( xs.filterCond(pivot, ">") ),
    xs.filterCond(pivot, "=="),
    quicksort( xs.filterCond(pivot, "<") )
  );
}

プログラミング言語力は、(言語の力で)見やすくなるかどうかだが、
プログラミング力は、(自分の力で)見やすく出来るかどうかだと思う。
言語の力に、自分の力が左右されるうちはまだまだ。

509 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
Smalltalkのクイックソート

SequenceableCollection >> qsort
  ^self size < 2 ifTrue: [self] ifFalse: [
    (self select: [:x | x > self middle]) qsort,
      (self select: [:x | x = self middle]),
      (self select: [:x | x < self middle]) qsort]

#(4 2 1 3 10 7 8 6 9 5) qsort "=> #(10 9 8 7 6 5 4 3 2 1) "

510 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
でもよく考えてほしい。
クイックソートを使うことはたくさんあっても
クイックソートの作成は一回だけだ。


どの言語もクイックソートを作成した後は、

配列 = quicksort(配列)

という一行になることに気づいてほしい。



そう。クイックソートに関する点では、
もはや言語の差がなくなってしまったのだ。

511 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>509
middleって名前ありなん?

配列の数が奇数の場合の仕様が
名前からはわかりづらいから避けていたんだけど、
middleという名前がOKならこうかけるよ。

function quicksort(xs) {
  return xs.length <= 1 ? xs :
    ArrayEx.concat(
      quicksort( xs.filterCond(xs.middle, ">") ),
      xs.filterCond(xs.middle, "=="),
      quicksort( xs.filterCond(xs.middle, "<") )
    );
}

functionとreturnを使う数がそれぞれ1回、最小になった。

512 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>511
参考まで、Squeak Smalltalkの#middleはこんなふうに定義されています。

SequenceableCollection >> middle
  "Answer the middle element of the receiver."
  ^self at: self size // 2 + 1

513 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
middleありなの?とかちょっと笑える

514 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>513
middleの仕様を
名前から判断できる?

名前から複数の仕様が考えられ、
複数の言語があったとして、
仕様がばらばらになるようなものは、
わかりにくい名前なんだよ。

515 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
ああ、いや、そういうことじゃなく(苦笑

516 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
そういうことって?

そもそも「middle」ありなのとは書いてなくて
「middleという名前」ありなの?だろ

お前自分の勘違いに自分で笑ってるのか?

517 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>509
昇順で書けよ!w

518 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
上から目線したら、間違ってるのが自分とわかり
このままフェードアウトするパターンですね。

519 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
標準のリスト操作以外はつかったらダメだろ
そんなのがありなら最初からCoffee使えや

520 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>511
JSよく知らないんですが、
filterCondとかmiddleは
どこにどんな処理として定義されているんですか?

521 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
jsはfunctionとreturnに文字数取られてるだけっぽいな

522 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
jsにfilterなんて出来たんだ
最近のjsは結構いいな

523 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>519
普通さ、自分でライブラリ書くだろ?
俺は現実的な開発において
差がでないことに興味はないんだよ。

>>520
5分時間やるから自分で書いてみろ。
処理の内容はquicksortの処理に必要な動作だ。

>>521
> jsはfunctionとreturnに文字数取られてるだけっぽいな
俺もそう思う。

CoffeeScriptは、わざと差が出るようなコードを意図的に書いたのを除けば、
functionとreturnの文字数分、そして括弧だけの行ぐらいしか差が出ないんだよ。
でそれくらいならタイピングにかかる時間の差ぐらいしかうまれない。

524 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
タイピングが面倒なんじゃなくて、コードがごちゃごちゃするのがうざい

525 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
そんなあなたにそっと寄り添う CoffeeScript

526 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
なんでタイピング時間って発想が出てくるの?
もしかして他のlambda式ある言語触ったこと無い?

527 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
タイプ時間じゃなければ、
読む時間か?
こっちはもっと差がないと思うが?

528 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
あっそ・・
そうやら根本的に相容れない人間らしいな

529 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
そのままじゃ動かないコードを貼り付けて「こうかけるよ」とか
何でもありなんだな。

Rubyならこんなシンプルにかけるよ!w

def quicksort(xs)
  return xs if xs.size <= 1
  quicksort(xs.smallers) + xs.middles + quicksort(xs.largers)
end

smallers、middles、largersはクイックソートの定義そった操作だから
自分で考えてみろ。…とか許されないだろJK

530 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
あ、JSの人は自分一人じゃFizzBuzzも満足に書けない人なので
他人のコードをパクって分からないところは「自分で考えろ」って言うのさ
まともに相手しても仕方ない

531 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
まあ、問題はぶっちゃけ510が正解だってことだw

532 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
それはない

533 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
>>526
> もしかして他のlambda式ある言語触ったこと無い?

もし、触ったことがあるlambda式ありの他の言語が

\ x y -> x*y の Haskell とか
->x,y {x*y} の Ruby とか
(x:Int,y:Int) => x*y の Scala とか
[:x :y | x*y] の Smalltalk とか

だった場合はどうなるの?

534 :デフォルトの名無しさん:2013/08/17(土) NY:AN:NY.AN
Haskellでは普通 \x y -> x * y なんて冗長に書かず (*) と書くので、
Haskellを使った事は無さそうだなって分かる

535 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>529
Rubyもそれでゆるすし、
JavaScriptもそれで許します。

function quicksort(xs) {
  return (xs.size <= 1) ? xs :
    quicksort(xs.smallers).add(xs.middles).add(quicksort(xs.largers));
}


結局のところ、ライブラリのほうが重要で
言語自体では差は殆ど出ないのさ。

536 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
cpan最強

537 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
俺だったら、>>529はダメって言うな。

なぜなら、クイックソートを実装している最中に使う
smallers、middles、largersが
クイックソート専用の関数になっているから。

クイックソートを作るときにクイックソートを実装するために
作られた関数を使ってどうするw
汎用関数ではない。


>>511のコードのmiddleは汎用関数
(その根拠はSmalltalkで用意されているから)
だからこっちは問題ない。

538 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>535
> quicksort(xs.smallers).add(xs.middles).add(quicksort(xs.largers))

おいおい、使わないかもしれないのにxs.smallersやxs.middlesやxs.largersを
メンバとして持ってるのか、すげー無駄だな。
アホのJS厨が考える事は分からんなー。

あ、>>529のRubyは括弧省略してメソッド呼んでるだけだから一緒にすんなよ?

539 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>538
オマエ馬鹿じゃね?

smallers、middles、largersって
Ruby厨>>529が考えだしたメンバだぞ。
使いもしないのに持ってるんだとさ。

540 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>539

あ、ほんとうだ!


Ruby厨って馬鹿って確信した事例の一つになった。

541 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>538はsmallersがメンバ変数になっていることに文句をつけてるんでしょ?

逆に言えば、smallers() なら問題ないって言っているようなもんだ。
くだらね。

ちなみにsmallersのままでもプロパティにしてしまえば
メソッド呼び出しにできるので、Rubyと一緒。

542 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>534
Scalaでも関数型言語なら演算子は関数扱いが普通
なんつうかGetStart斜め読み程度の知識で議論しようとしてるよな

543 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>541
>ちなみにsmallersのままでもプロパティにしてしまえば
>メソッド呼び出しにできるので、Rubyと一緒。
pivotとかまでプロパティ作るの?標準リストに?

544 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
5分時間やるから自分で書いてみろ。

545 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
汎用性の無い関数を山のように積み上げても
ゴミの山になるだけだと思うんだけど、
そんなんで生産性が上がると思ってる奴いるんだな

546 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>543
↓こいつにレスしてるの?

529 名前:デフォルトの名無しさん[sage] 投稿日:2013/08/17(土) NY:AN:NY.AN
そのままじゃ動かないコードを貼り付けて「こうかけるよ」とか
何でもありなんだな。

Rubyならこんなシンプルにかけるよ!w

def quicksort(xs)
  return xs if xs.size <= 1
  quicksort(xs.smallers) + xs.middles + quicksort(xs.largers)
end

smallers、middles、largersはクイックソートの定義そった操作だから
自分で考えてみろ。…とか許されないだろJK

547 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
Ruby厨がクソコード書いたおかげで
尻拭いをしてることぐらい
分かれよw

548 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>542
どんな議論だか見えないんだが?

549 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
あと、リストのindexの中心をpivotにしてるのって
何か意味あるんだっけ?

xs[Math.floor(xs.length/2)]

こういうやつね。


もしかして、中央値をpivotにしようとして間違ってる?

550 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
なにか反論でも有るの?

Rubyならこんなシンプルにかけるよ!w

def quicksort(xs)
  return xs if xs.size <= 1
  quicksort(xs.smallers) + xs.middles + quicksort(xs.largers)
end

551 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>550

使わないかもしれないのにxs.smallersやxs.middlesやxs.largersを
メンバとして持ってるのか、すげー無駄だな。

汎用性の無い関数を山のように積み上げても
ゴミの山になるだけ

pivotとかまでプロパティ作るの?標準リストに?

552 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>548
立場的にどんな場面でもfunctionとreturnキーワードは有用って主張でしょ?
じゃなきゃいちいち否定する理由がないじゃない。

553 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>549
うわあ恥ずかしい
お前が

554 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>553
え?マジで説明してよ

555 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>549
> もしかして、中央値をpivotにしようとして間違ってる?

中央値ってメディアンのこと?
あれは配列の数が奇数なら、中央値取ってこれるけど、
配列の数が偶数なら、中央に近い二つの値の平均になる。
だからクイックソートのpivotとは違う。

だから計算した方がいいと思ったが、
smalltalkではmiddleというメソッドが有るらしい。
>>509 >>512 参照)

ならsmalltalkの真似でmiddleという名前を使うのはありかもしれない。
俺自身は一般的ではないと思ってるけどね。


でもさすがに>>550、このRubyコードはダメだw

556 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>552
> 立場的にどんな場面でもfunctionとreturnキーワードは有用って主張でしょ?

だれもfunctionとreturnが有用なんて言ってないと思うけど?
タイプする文字が多い程度の弊害はあると。

557 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>554
真の中央値調べられる時点でソート終わってるだろ

558 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>556
だからそれじゃ不要だという事を否定する根拠にならないだろ
言ってることめちゃくちゃだ

559 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>555
もちろん偶数のときは、中央に近い2つの値のどちらかを取る形式で

560 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>529について、メソッドsmaller, middler, larger を前提としない、
そのまま動くコードに書き直してみた

def quicksort(xs)
  if xs.length <= 1
    xs
  else
    smaller, larger = xs[1..-1].partition { |x| x < xs[0] }

    quicksort(smaller) + [xs[0]] + quicksort(larger)
  end
end

561 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>557
真の中央値ってなんだ?
もしかしてソートした配列の中で、
真ん中の値だと思ってる?

xs[Math.floor(xs.length/2)]

どうみても、(ソート関係ない)配列の中で
真ん中に位置する添字の値です。

562 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>557
終わってないよ
中央値はO(n)の計算量で求められるし

563 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>552
つまり、HaskellやScalaではラムダ式は
文法としてはあるけど実際は使わないから
functionとreturnキーワードをラムダ式に使う
冗長な記述しか認めんって主張をしてるの?

564 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>561
だからそれを言ってるのに理解力無いな・・。

565 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
誰だよ、smaller、largerなんて名前をつけたやつw
(※>>529です)

おかげで、>>560がワケの分からないコードを書き始めたぞw

566 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>564
お前が誰だかさっぱりわからん。

「真の中央値」と言い出したのは誰で
どういう意味で、なぜそう思ったのかを
いってくれ。

567 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>562
それは不勉強だった。すまん。

568 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>560
xs[1..-1]
なにこれ
全要素って意味?

569 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>568
xs[0] が hd xs で、xs[1..-1] が tl xs
リストの頭部と尾部のこと

570 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>569
やるじゃん
後はif文消すだけだな

571 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
ほぼ整列済みのときの移動を減らすためだろ。

572 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
クイックソートのアルゴリズムをちゃんと知ってないので
>>503が書いた
val pivot = xs(xs.length / 2)
が正しいやり方だと思っていた。

別に配列の最初の値でいいのか。

ならもっとスマートに書けるな。

573 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
最初の値でいい。真ん中と平均の処理時間は変わらないはず。

574 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>572
クイックソートは、smallerとlargerがほぼ同数になるように
分割すると計算量的に有利なので、
pivotはxsの中で最も中央値に近い値を選ぶのがベスト

だけど、馬鹿正直に中央値を計算するのも無駄が多いので、
適当に三点くらいのサンプルをとって、その中央値をpivotにしたりする、らしいよ

575 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>565,572
>>560は、>>506のPrologコードをRubyに書き直したもの
Prologを知らないなら、GHC(KL1)かErlangのコードがWikipewdiaにあるから、それを嫁
 http://ja.wikipedia.org/wiki/Guarded_Horn_Clauses
 http://ja.wikipedia.org/wiki/Erlang

>>503やその他のコードでは中央値としてリストの中央に位置する値を選んでいるが、
これは近似値にすぎない
もし正確な中央値を求めたいのなら、リスト全体を探索しなければならない
そんな無駄をするくらいなら、リストの先頭値(頭部)を中央値と仮定してしまえ!と
いうのがミソになる
また、>>503その他では3回のフイルタでリストを全探索しているが、
これをメソッドArray#partitionの1回で済ませているのも高速化のキモになる

576 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
こうかな。

function quicksort(xs) {
  if (xs.length <= 1) return xs;

  var parts = xs.partition(function(x) { return x < xs[0] });
  return ArrayEx.concat( quicksort(parts[0]), xs[0], quicksort(parts[1]) );
}

577 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
そしてここで実用性のないhaskellコードが

qsort [] = []
qsort (x:xs) = qsi (< x) ++ [x] ++ qsi (x <)
 where qsi func = qsort (filter func xs)

578 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
標準ライブラリ関数が充実していれば、
どんな言語も大差ないんよね。

標準ライブラリ関数が充実してなければ、
自作ライブラリ関数が充実させればいいだけ。

579 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
あ、本当にバグってる
けどいいや

580 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
真ん中あたりの値を使うのは、たまたま
ソート済みの配列を与えられた場合の
処理の無駄を恐れてのことだろ?

581 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>580
正解

582 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
別に真ん中あたりの値を使っても
最悪の計算量がO(n^2)になるのは同じよ

583 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>577
要素の重複もついでに排除してくれるよいコードですね。

584 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>582
経験的に真ん中の値を使う場合の最悪の並びで与えられるより
ソート済みの配列を与えられる可能性の方がはるかに多い。

585 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
再帰が要素と同じ階層になる。

586 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>583
こ・・このやろう・・馬鹿にしやがって・・

587 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>577
qslの適用を1回で済ませるように書き直せないかな?

588 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
なお、pivotに中央値を使っても平均計算量はO(n log n)で先頭を使ったときと変わらず、
かつ最悪の計算量もO(n log n)になるよ

589 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>584
×ソート済みの配列を与えられる可能性の方がはるかに多い。
○ソート済みの配列を与えられる可能性の方が相当多い。



そーとー多い

590 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
もっとも、クイックソートをこのスタイルで書いてる時点で、
効率が云々とかいう議論はナンセンスなんだけどな。

591 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
山田くーん
>>589の座布団ソートして

592 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
真ん中あたりの値を使うのは、
データが連結リストだと遅い

593 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>590
それを言ったら、大抵の言語に標準で存在するソート関数を
こんなとこで議論してどうするよ……

594 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>586
次からは、たとえ劣等言語であっても、
すでにあるコードをよく読んでから投稿しようね。

595 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>593
言語組み込みのソートで
クイックソートなんか普通使わんだろ。

596 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>592
効率気にする奴が連結リストなんかソートするな。

597 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>587
qsort [] = []
qsort (x:xs) = qsort (fst parted) ++ [x] ++ qsort (snd parted)
 where parted = partition (< x) xs

書いたけど、リストの時点で比較とかの速度気にしても仕方ないと思うよ。

598 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
話を戻すと、そもそも「関数型ハイブリッド言語(キリッ」とか言って
しょぼいクイックソートのコードを貼る>>498のセンスが悪い

599 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
Javascriptのソート。

sort = function (xs) {
return xs.sort();
};

600 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
それに比べたら>>576のJavaScriptコードは
相当シンプルになったよ。

言語じゃないんだよね。

601 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
そうだな
ArrayExは言語機能じゃないな

602 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
そう、ライブラリの力が
開発効率に一番影響する。

603 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
JavaScriptの糞コードを出したらボコボコにされたので
必死に話をそらそうとしているの図

604 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
他言語との比較目的なのに、いいかげん
架空のライブラリー使って書いたコード貼るのやめろよ。

605 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
ArrayExというオレオレライブラリを作るとこうなる(キリッ

606 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>598
禿

607 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
でも普通の開発では、足りない部分は
自分でライブラリ作成して補うじゃん?

そのライブラリを作成する機能は
言語の機能じゃん?

現実的な話をしようぜ。

608 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
オレオレライブラリーを後出し拡張すれば、
JavaScriptでもSmalltalk程度の表現が可能なのはわかった。

609 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>608
middleって名前あり?

610 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
ありでいいよ。

611 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
middleは配列の真ん中の値を返す

612 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
だめだ。これ以上は無理だ。

function qsort(xs){
 var part = xs.slice(1).reduce(function(pt,e){
  return (e < x ? pt.s : pt.l).push(e) , pt;
 },{l:[],s:[]});

 return !xs.length ? xs : [].concat(
  qsort(part.l),
  [x],
  qsort(part.s)
 );
}

ところで >>498はなんで
.filter(function(x){ pivot == x; })
なんて入れたんだ?

613 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
失礼。コピペミス。

function qsort(xs){
 var part = xs.slice(1).reduce(function(pt,e){
  return (e < xs[0] ? pt.s : pt.l).push(e) , pt;
 },{l:[],s:[]});

 return !xs.length ? xs : [].concat(
  qsort(part.s),
  [xs[0]],
  qsort(part.l)
 );
};

614 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
{1,1,1,1,2,2,2,3,3,3}とか

615 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>594
何様だ

616 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
最近のjavascriptには配列にfilterやreduceなんてもんがあるのか
Ieのバージョンでいえば、いつからの話?

617 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
filter メソッド (JavaScript)
必要条件
Internet Explorer 9 標準、Internet Explorer 10 標準の各ドキュメント モードでサポートされます。
Quirks、Internet Explorer 6 標準、Internet Explorer 7 標準、Internet Explorer 8 標準の各ドキュメント モードでサポートされていません。
http://msdn.microsoft.com/ja-jp/library/ie/ff679973(v=vs.94).aspx



Array.filter - JavaScript | MDN
実装されたバージョン JavaScript 1.6 (Gecko 1.8b2 以降)
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/filter

618 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
bind(カリー化)の導入に続きletの導入が検討されてるさなかで
filterすらやっと導入したieは死んでいい

619 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
かなり最近だな
IE9かよ

620 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
即時評価だろ?クソじゃん
遅延評価が可能なまともなイテレータの仕組みを導入してから対応するのが筋だろう

621 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
そうでもないよ
まあ、generatorならFirefoxで対応してるし、次期javascriptでは入るが

622 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
そうでもあるよ
時代遅れのウンコすぎ

623 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
Coffeeのリスト内包表記もPythonと違ってジェネレータにできないから所詮サンプルコード専用の飾り

624 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
それが致命的だと思ってるのはお前だけじゃね?
そんなに致命的ならCとかですぐにジェネレーターができたはずだろ
まあ、イテレータパターンくらいならどの言語でも普通にライブラリがあるけど
大抵for文で間に合ってるからほとんど使われないねw
パフォーマンスなんて結局そんなもんなんだよ

625 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
普通にforループ回すスタイルなら無くても良いよ、確かに

でも、mapやfilterなどの関数を合成するスタイルのプログラミングをするなら、
遅延評価は欲しいよ
関数合成するたびに中間状態でリスト作られるのは、いくら何でも無駄すぎる


まあ「関数型ハイブリッド言語」なら在った方が良いんじゃないのw

626 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>560>>597を参考にした、SML(Standard ML)のクイックソート

fun
  qsort [] = []
|
  qsort (x::xs) = let
    val (smaller, larger) = List.partition (fn e => e < x) xs
  in
    List.concat [qsort smaller, [x], qsort larger]
  end

627 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>623
そういえば、ここまでPythonのコードが見あたらないね

628 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
どうして関数型言語陣営は
重複を考慮しないコードを書きたがるの?
ただのバカなの?

629 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>623
重複を考慮しない、とはどういう意味?
入力リスト内で要素に重複があっても正しくソートできるけど....

- qsort [3,6,1,2,1,5,4,3];
> val it = [1, 1, 2, 3, 3, 4, 5, 6] : int list

630 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
アンカをミスった
>>629>>623は間違いで、>>628が正しい

631 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>625
どうかなあ、実際リストがそれほど大きいなら関数型スタイル
つかわないでforにするでしょ
ほとんどは1000以下の速度とかどうでもいいリストだろ
ブラウザ画面で1000も表示してたら通信速度もレスポンスも悪い

632 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>628
おそらく、たまたま>>577のHaskellコードが重複を考慮していなかった(>>583)ので、
すべての関数型スタイルが重複を考慮していない、と(>>628は)早合点したんだろなw

フィルタ(filter)を止めて、リストを二分割するパーティション(partition)という
述語(>>506)、メソッド(>>560)、関数(>>597,626)を導入したことで、
フィルタの抱えていた重複問題が自然に解決できた、という訳だ
しかもリスト探索が1回で済むから効率も改善された

633 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>627
Python (with numpy)


qsort = lambda xs: xs if xs.size <= 1 else numpy.concatenate(
        (qsort(xs[xs < xs[0]]), xs[xs==xs[0]], qsort(xs[xs > xs[0]])))

634 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>618
どうせブラウザの生存期間はもっと長いので、
polyfillで未対応ブラウザでも
容易に対応できるものはあまり問題視しない。

635 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>633
他の言語と同様に、標準ライブラリだけで書けないかな?

636 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>635

def qsort(xs):
    if len(xs) <= 1:
        return xs
    ss = [x for x in xs[1:] if x < xs[0]]
    ls = [x for x in xs[1:] if x >= xs[0]]
    return qsort(ss) + xs[:1] + qsort(ls)

637 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>633
xs[xs < xs[0]] ってどう解釈されるの?

638 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>636
他の言語(>>506,560,597,626)と同様に、
1回のqsort呼び出しでリスト要素の全探索処理が1回ですむように書けないかな?

639 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
どんなサンドバッグだよ

640 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>637
[x for x in xs if x < xs[0]]


>>638
>>636のssとlsの生成を以下に置き換え

ss, ls = reduce(lambda (xss), x: (xss, xss[0 if x < xs[0] else 1].append(x))[0], xs[1:], ([],[]))

641 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
クイックソートの再帰に関する部分が常に一度きりだったら、それはクイックソートでないだろ。

642 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
いやだからね、
array.sort();
で終わる話をいつまで続けてるんだって話なんですよ
言語の違いはライブラリの違い
ぶっちゃけほとんどそれだけ

643 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>628
関数型陣営と限定してるけど
実は関数型もスクリプトも両方書いてるというオチ

644 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>640
置き換えてみた

def qsort(xs):
&#xA0;&#xA0;&#xA0;&#xA0;if len(xs) <= 1:
&#xA0;&#xA0;&#xA0;&#xA0;&#xA0;&#xA0;&#xA0;&#xA0;return xs
&#xA0;&#xA0;&#xA0;&#xA0;ss, ls = reduce(lambda (xss), x: (xss, xss[0 if x < xs[0] else 1].append(x))[0], xs[1:], ([],[]))
&#xA0;&#xA0;&#xA0;&#xA0;return qsort(ss) + xs[:1] + qsort(ls)

645 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
読めぬ……

646 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>644はコピペに失敗したのでやり直し

def qsort(xs):
  if len(xs) <= 1:
    return xs
  ss, ls = reduce(lambda (xss), x: (xss, xss[0 if x < xs[0] else 1].append(x))[0], xs[1:], ([],[]))
  return qsort(ss) + xs[:1] + qsort(ls)

647 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>646
これって>>613と同じ方式?

648 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>642
清々しいまでにドカタだな

649 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>640
1行が長すぎて読みづらいんだけど、Pythonは可読性を大切にする言語なんだし、
関数内関数が定義できるという利点を活かして、関数partitionの定義/適用で
書き直しできないかな?

あるいは(>>613みたいに)、適切なインデントで可読性を向上させてもいいと思うよ

650 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
f = lambda xss, x: (xss, xss[0 if x < xs[0] else 1].append(x))[0]
ss, ls = reduce(f, xs[1:], ([],[]))

651 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
これでわかったけど
次回からPHPやPerlは消していい

652 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>642の「言語の違いはライブラリの違い」という意見も一理あると思うので、
>>560のRubyコードにいついて、組込みメソッド Enumerable#partition を利用せず
ユーザ定義メソッドとして書き直してみた

def quicksort2(xs)
  partition = -> array, fn {
    array.inject([[], []]) { |(xs, ys), elem|
      fn[elem] ? [xs << elem, ys] : [xs, ys << elem]
    }
  }

  if xs.length <= 1
    xs
  else
    smaller, larger = partition[xs[1..-1], -> x { x < xs[0] }]

    quicksort(smaller) + [xs[0]] + quicksort(larger)
  end
end

653 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>651
関数型プログラミングがスクリプト言語のすべてではないから、消す必要はないと思う

654 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
クイックそーとなんてどうでも良いんだから
そんなんでPerlとPHPを削られてもな……

655 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
今はPHPもPerlも関数型の書き方で書けるはずなのに
書かないという事は人数がいない

656 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
まあ、Perlで書こうと思えば書けるけど、
なんかJS厨っぽい奴に粘着されそうでメンドイわ

657 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
無理にラムダ式を使っていた>>652が読みづらかったので、
素直に普通のメソッド定義で書き直した

def partition(array, &fn)
  array.inject([[], []]) { |(xs, ys), e|
    fn[e] ? [xs << e, ys] : [xs, ys << e]
  }
end

def quicksort3(xs)
  if xs.length <= 1
    xs
  else
    smaller, larger = partition(xs[1..-1]) { |x| x < xs[0] }

    quicksort(smaller) + [xs[0]] + quicksort(larger)
  end
end

658 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>657
バトルスレなんだから、それは不戦敗と等しいのでは?

659 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>656
ああ、うん・・それは同意。

660 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
何回も呼ぶ関数の中で関数内定義するのはやだなあ
partition とかよく使う処理だし外でいいよ

661 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
馬鹿みたいにリストを作りまくってるのに
今更何言ってんだって話だけどな

662 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
クイックソートみたいな処理を何度も呼ぶという感覚がそもそも
おかしいので、まずその辺の教養をつけるといい
土方作業でも何でもいいから

663 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
クイックソートは再帰関数なんだから
何度も呼ばれるに決まってんだろ
ドカタはドカタらしくすっこんでろ

664 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>661
Rubyのメソッド Array#<< は破壊的操作だよ
>>657だと、メソッド inject の引数で配列が2個生成されて、
それらにメソッド << で要素を(破壊的に)追加している
だから、inject内のループで毎回ソート対象の配列全体を再生成している訳ではない
(ただしタプルとして使う2要素の配列は毎回生成してるけどね)

665 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>657について、partitionの定義本体部分をクイックソート関数内で展開してみた
結局のところ、元の>>560と比べて2ステップ増えただけという、つまらん結果になった

def quicksort4(array)
  if array.length <= 1
    array
  else
    smaller, larger = array[1..-1].inject([[], []]) { |(xs, ys), e|
      e < array[0] ? [xs << e, ys] : [xs, ys << e]
    }

    quicksort(smaller) + [array[0]] + quicksort(larger)
  end
end

666 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>664
Rubyは配列への要素の追加操作で
内部的な配列再生成は伴わないの?
どうやってメモリを確保しているんだろう。

667 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>663
まずは計算量という言葉を学習してから来い

668 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>667
まさか、このスレのコードが空間計算量をまともに考えているとでも?

669 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>666
Rubyの配列は、内部実装としては双方向ポインタによる連想リストだから、
追加(<<)の場合には、追加した要素の分だけしかメモリは確保されない

670 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
スクリプト言語の実装は良く分からんけど、関数ってCだとコード領域に
一つだけ定義されてて、全部アドレス呼び出しに変換されてるよな
スクリプト言語だと、まさかいくつも関数の領域を同的に確保して、
時間食ったりするの?

671 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
> quicksort(smaller) + [xs[0]] + quicksort(larger)

無駄にリスト作りまくりなのはpartitionじゃなくて、ここ

672 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>667は空気が読めない人

673 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>670
言語や実装によるとしか。

674 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>670
スクリプト言語の関数はクロージャになってるのが多いし、
クロージャは環境も含むから、それぞれ毎に領域を確保する必要はあるだろう
ただ、毎回パースしたりするわけじゃない

675 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
Google Chromeのjsだと感覚通り。
http://jsperf.com/generating-simple-closure-test

676 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>675
一番遅いやつでも一秒間に200万回、、、
こんなの気にしてるやつがバカだなw

677 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>676
どう受け取ったらそうなるんだよ

678 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
クロージャって言っても静的スコープだから
スコープチェーンみたいなものへの
ポインタがあるだけでしょ

679 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>677
素直に数字見たらそうなるだけだが?
どれも速すぎて全く処理がないと考えていい

680 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
初代Pentium 300MHzが理論値300MFLOPSで、浮動小数点演算を秒間300万回できた
それを速すぎると感じた時代もあったね

681 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
うまいたとえ話をしたつもりかもわからんが、
関数定義の処理は、時代が進んだらハードも当然変わるんだが

682 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>688からわかることは、浮動小数点演算が速いと
思われた当時より数年たった今、ますます速いと
思っているように、CPUの進化でどんどん速くなる。

一秒間に200万回。これは今は速い程度だが、
将来は超速い処理ということになるだろう。
つまりますます気にしなくて良くなる。

このことを>>688はいいたいのだろう。

683 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>498のコードを真面目に比較して書いて5%程度の差。
誤差としていいかもしれんが、全く処理がないはいくらなんでも言い過ぎ。

684 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
ベンチマークを過信するとそうなるよね。
あるものに比べて5倍の速度が出ましたとかね。
実際使ってみると5倍も差があるように感じない。

その理由は二つあって、

一つは、プログラム全体の処理時間のうちわずか1%の部分が5倍速くなっただけ。
ベンチマークではわずか1%の部分だけを集中して
計測するようなことをするから5倍さがでるがプログラム全体からすれば
体感できないレベル。

もう一つは、もともと速い処理がもっと速くなっただけ。
0.001秒で終わるものが、0.0001秒で終わっても計測は出来るだろうが
人間にはわからない。

具体的なアプリで何秒の差がでたかというのが人間にとっては重要。

685 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
また煙に巻き始めた

686 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
煙に巻かれた。の間違いじゃないのか?

687 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
また一般論で不毛な議論に持って行こうとしてるんだから間違ってない。
何のために話題用意してると思ってるんだよ低能。

688 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>685
やっぱもっと宗教的・哲学的・美学的観点から論議したほうがはっきりしていいよね

689 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
683は一体どんなベンチマークをして5%差などと言ってるんだ?
それを言わないことには何の価値もないぞ

690 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
関数型クイックソート実装はもうあきたから次のお題はよ

691 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
そりゃwebやってるドカタからみれば
秒間200万なんて異次元の速度なんだろうな

692 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
結局、捨て台詞はいて終わりか

693 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
他言語の比較もしろっつってのに
自己顕示欲満たすために議論してる奴は死ね

694 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
速度が十分かどうかなんてアプリケーションによって違う

695 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
JS厨ってマイクロベンチなんて意味無いって言いながら
JSのJITは速いって事ある毎に言ってて面白い

696 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
だからマイクロベンチが意味なくって
JITが速いのは意味があることでしょ?

何を言ってるんだろうかね。

697 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
JITが速いってマイクロベンチで比較した結果でしょ?

698 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
マイクロベンチマークで比較するのが意味ないではなくて、
秒間200万回とか300万回が十分速いとかいう話じゃないのか?

699 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
ま、数値計算なら遅すぎる

700 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
もうソートは飽きたから>>409に話戻そうぜ

701 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>699
つか、ベンチマークの内容をみたところランダムの数値を
作ってる処理が大部分のようだが

702 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>409に戻すくらいならソートとか速度の話でいい

703 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>701
え?

704 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>680
初代 Pentium の 300MHz なんてあるんだ。
200MHz までだと思ってた。

705 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>703
マジでマジで
return functionのとこなんか特に
Random生成なんて線形合同法のバリエーションか似たような速度の
アルゴリズムだろ
つまり、実質のコストは数値一回足したとか二回演算したとかそんなもん

706 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
乱数生成は秒間2400万回くらい実行できてるみたいですがねぇ……

707 :367:2013/08/18(日) NY:AN:NY.AN
しばらくクイックソートの議論が続いていたので自制していましたが、
要望があったので再開します

ここまでの指摘について、>>409を更新しました

FP
 ---- 壁0. 変数の壁 ----
Haskell
 ---- 壁1. 純粋性(副作用)の壁 ----
F#/OCaml/SML/Scala
 ---- 壁2. 型推論の壁 ----
=====<< 越えられない壁 >>=====
Erlang
 ---- 壁3. パターンマッチの壁 ----
Common Lisp/Scheme/Ruby1.9
 ---- 壁4. 末尾再帰最適化の壁 ----
Emacs-lisp/Closure/Smalltalk/Ruby1.8
 ---- 壁5. 式指向(条件判定式)の壁 ----
=====<< 越えられない壁 >>=====
C++/Java/C#/Perl/Python...etc
 ---- 壁6. ラムダ式の壁 ----
C

[変更点]
・Common Lisp を上げ、Emacs-lisp を新規に追加 -- >>444,450,459
・壁3.を新規に変更 -- >>455,456
・壁.「クロージャ/ラムダ式」を「ラムダ式」に変更し、これに伴って
 C++/Java/C#/Perl/Python についてバージョン化も廃止
  ==> これについては、別途説明します

・「壁5.式指向」について、>>480以降で客観的な意見(反論/異論)が無かったので保留
・Ruby1.9の末尾再帰最適化について、実装が不完全であるという確定情報が無いので保留(>>490)

708 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
環境によって違う数値を比べられてもねえ
自分の数値でどれだけ遅くなってるのかを言ってもらわないと

709 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>705
randomは全ケースで同じ数だけ呼び出してる

710 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
その一番上にあるFPとかいう言語はなんなん?

711 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>709
で?

712 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
誰だよこいつ呼んだ馬鹿・・

713 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>711
>>706なんだから、randomが処理の大部分を占めるわけがない

714 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>711
で?って言われても
コード見る限りその上での比較だから最低でも乱数生成より2倍は遅い

715 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
他のクロージャ生成のベンチ作ろうぜ

716 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>713
706なんて他の数値を公表してないから何とも言えん

717 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>714
俺の環境だと、一番遅いやつで乱数生成の3倍程度
一番早いやつだと1/2だから、乱数生成が大多数を占めてる
特にクイックソートのやつはこれだろ

718 :367:2013/08/18(日) NY:AN:NY.AN
>>710
Fortranの設計者でありBNF(バッカスナウア記法)の考案者でもある
バッカス氏が考案した関数型言語です
特徴としては変数という概念が存在せず、プログラム構成子と呼ばれる
高階関数を使い、アトム、基本関数(=組み込み関数)、そして
プログラム構成子自身を組み合わせることでプログラミングを進めます

Wkipediaの英語版にも解説があるので、そちらも参考になるでしょう
http://en.wikipedia.org/wiki/FP_(programming_language)

日本語では、以下の書籍で解説されています
・続 新しいプログラミング・パラダイム
 http://www.amazon.co.jp/dp/4320025350/
なお、この書籍は>>575で紹介したGHCや、演繹データベース、
圏論のコンパイラ生成への応用、もう一つの「究極のプログラミング」である
構成的プログラミングなど、興味深いトピックが満載なのでお薦めです

719 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>717
一番速いやつってJust Return Fixed Functionってヤツ?
これは関数返してるだけで関数内関数を作ってないから違くね?

720 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>719
作ってるけど、実際の処理は関数内関数を返すだけだから同じじゃね?
まあ正確なところは実際にやってみないと分からんけど

721 :675:2013/08/18(日) NY:AN:NY.AN
他に試しましたが、結局元のコードが一番対比しやすそうなので戻しました。
http://jsperf.com/generating-simple-closure-test

他の結果が消えてしまったのは一度変更したためです。

722 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>700
お前、ほんっとバカだなっ

つーか、自演か?

723 :367:2013/08/18(日) NY:AN:NY.AN
>>707
>・Ruby1.9の末尾再帰最適化について、実装が不完全であるという確定情報が無いので保留(>>490)

この件について、>>369でも書いているように、情報が確定していません
もし不完全であるという確定情報があれば喜んでRuby1.9を下げたいので、情報提供を歓迎します

724 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>723
デフォルトオフの時点でさっさと下げるべきだろう?

725 :675:2013/08/18(日) NY:AN:NY.AN
PythonはデフォルトONでif式もクロージャもあるけど
なぜか上に上げてくれないようです
そういうこと

726 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
やっばwやっちまったぜ

727 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>720
ベンチに関数内関数を作ってるGenerate Function Returns 0ってのがあるので、
それを見ればいいよ

728 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>726
ヤバいRuby厨を起こしたのお前か!

729 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>726
猛省しる!

730 :367:2013/08/18(日) NY:AN:NY.AN
>>724
Ruby1.9で末尾再帰最適化が実装されたのは事実ですので、却下します
ただし、その実装が不完全であるという確定情報があれば採用する、という話です

>>725
もしPyhtonの if式が、他の言語と同様に if <cond>: <true> else <false> という
自然な構文に変更されたなら、式指向であると認めます
この件は過去にも何度か議論されていますが、客観的な意見が無いまま、
言い換えるとPyhton支持者の独りよがりな意見のまま議論を終えているのが実情です

また、クロージャについては(自分の不勉強もあって)議論に混乱が見られたので
思いきって>>707では壁から外しましたから、Pyhtonだけが不利では無いと考えます

731 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>727
それだと、乱数生成コストとほぼ同じ
結局、関数の中に関数作るのなんて演算数回と変らんってこと
つまり、気にする奴はやはりバカ

732 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>730
> もしPyhtonの if式が、他の言語と同様に if <cond>: <true> else <false> という
> 自然な構文に変更されたなら、式指向であると認めます

だからよ、自然な構文かどうかを決めてるのはお前の主観だけだろ?
なーにが「客観的な意見が無いまま」だ、アホ

733 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
客観的っていうなら、式で条件分岐できるか否かだけで判定しろよ
それ以外は主観だろ

734 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
ん?ちょっと待て、pythonのif文は違うのか?

735 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>730
> 実装が不完全であるという確定情報

Ruby開発者会議20130727Japan
「特殊なケースでtail call optimizationが効かないことがあってもよいか」
https://docs.google.com/document/d/1Ie6HNoxCptIUe52I3XCxDLn52FtE_RWaF8lrDIXAVmc

736 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
これなに?

367の無知・主観によってなされた不当なランク付けを
いちいち指摘してたり、情報提供してお伺いをたてて
壁を外させたりランクを上げてもらったりするのを
この後もえんえんと続けるの?

あほらし

737 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
くだらんソートコードを書き比べているほうがまだマシだわ

738 :367:2013/08/18(日) NY:AN:NY.AN
>>372
条件分岐式として不可解な構文を採用しているのはPythonだけ、これが客観性の根拠だよ
不満があれば、過去の議論の一部である以下のカキコへ反論してくれ

====【Perl,PHP】LLバトルロワイヤル19【Ruby,Python】====
711 名前: 682 Mail: sage 投稿日: 2011/12/29(木) NY:AN:NY.AN
>>695のPythonコードが読みづらい原因はif演算子の構文にある
条件判定が式である言語に限定して、それらの構文を比較してみる

Ruby:
  if 条件式 then 式1 else 式2 end
Smalltalk:
  条件式 ifTrue: [ 式1 ] ifFalse: [ 式2 ]
Lisp:
  ( if 条件式 式1 式2 )
ML:
  if 条件式 then 式1 else 式2
Haskell:
  if 条件式 then 式1 else 式2

Python:
  式1 if 条件式 else 式2

普通の言語は「条件式 -> 式1 -> 式2」と左から右へ流れる(それが自然)
それに対して「Pythonだけ」は「式1 <- 条件式 -> 式2」と
左へ右へと行ったり来たりしないとコードが読めない

プログラミング言語界の中で「Pythonだけ」が異端な存在で、可読性の悪い構文が採用されている
これは明らかにPython開発陣の言語設計ミス、あるいは判断ミスだね

739 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
は?構文がどうとか、条件分岐式を持つか否かと関係あんの?

740 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
> (それが自然)


でたよ、主観

741 :367:2013/08/18(日) NY:AN:NY.AN
>>738の先頭にあるアンカーを間違えていたので訂正する

X: >>372
O: >>732-734

742 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
Pythonってそんなにダサかったんだ

743 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
じゃあ、Rubyにはif修飾子が構文にあるし
これはよく使われてるからランク下げないとな

744 :367:2013/08/18(日) NY:AN:NY.AN
>>739
>>730の繰り返しになるけど、if-else構文はプログラム言語の基本要素なのだから、
もしPython設計者がPythonを式指向な言語としたのなら、他の式指向言語と同様に
最初から if <cond>: <true> else <false> という構文を採用していた、という話だよ


>>740
それが自然でないなら、>>738にある言語の中でPythonを除く:

 Smalltalk/Lisp/ML/Haskell

の設計者達も(自分と同じく)頭が変なんでしょうね
さて、Pythonのif式が不自然ではないという主張と、どちらが客観性があるのでせうか(棒

745 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
Haskell: \x -> x
OCaml: fun x -> x
SML: fn x => x
Scala: (x:Int) => x
Ruby: -> x {x}

どの関数型言語も、ラムダは「引数 矢印 戻値」と並ぶ(それが自然)
それに対して、Rubyだけが「矢印 引数 戻値」と並んでる
矢印が真ん中だから、引数が戻値に変換されるという意図が伝わるのに、
「Rubyだけ」が異端な構文を採用してる
これは明らかにRuby開発陣の言語設計ミス、あるいは判断ミスだね

異端な構文を採用してると、その言語機能を持っていないルールですので、
Rubyはラムダを持ってないということになりました

746 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
Pythonのも、
Rubyの「式 if 条件」の形に else 節を
付け足したものだと考えれば、
俺は別に変だとは思わないけどな。
Pythonは else 節をよく活用している
面白い機構も多いからなおさら自然な流れだ。
あくまで主観だけどな。w

747 :367:2013/08/18(日) NY:AN:NY.AN
>>743
三項演算子の話と同じく「樹を見て森を見ず」だね
プログラム言語の基本である if-else 構文がRubyでは式として定義されているから、
(三項演算子と同様に)オマケであるif修飾子の存在は評価基準からは除外できるよ

748 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
ここまでの指摘にもとづいて、>>707を更新しました

FP
 ---- 壁0. 変数の壁 ----
Haskell
 ---- 壁1. 純粋性(副作用)の壁 ----
F#/OCaml/SML/Scala
 ---- 壁2. 型推論の壁 ----
=====<< 越えられない壁 >>=====
Erlang
 ---- 壁3. パターンマッチの壁 ----
Common Lisp/Scheme
 ---- 壁4. 末尾再帰最適化の壁 ----
Emacs-lisp/Closure/Smalltalk
 ---- 壁5. 式指向(条件判定式)の壁 ----
=====<< 越えられない壁 >>=====
C++/Java/C#/Perl/Python...etc
 ---- 壁6. ラムダ式の壁 ----
C/Ruby

749 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>747
評価基準から除外できるとか、お前に決める権利はないだろ?
ルールマスターのつもりか?

公平に振る舞いたかったら、せめて「除外できると思うのですが、皆さんどう思いますか?」と訊け

750 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>747
あのさあ、
「ある言語が関数型プログラミングに活用可能な機能をどの程度有するか」と
「その言語がどのくらい関数型を意識して設計されたか」をごっちゃに
していないか?

その言語にあったパラダイムがあるんだから、
ここで後者を議論したってしょうがないだろう?
前者なら、条件分岐が値を返せればそれでいいじゃん。
構文の自然さとか、お前の主観は関係ないだろ。

それとも関数型を意識せず設計された言語は存在価値無し!とか思ってんの?

751 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
真面目に相手できるお前がすごい

752 :367:2013/08/18(日) NY:AN:NY.AN
>>745
Rubyの -> x { c } という構文は、Ruby2.0から採用されているね
これが違和感のある構文だというのは、自分も認める
この -> は、矢印ではなくてギリシャ文字のラムダを横に倒したものらしいが、
正直言ってコジツケだし、写像関係の矢印とまぎらわしい
素直にOCamlまたはSMLの構文を導入すれば良かったと思うが、
おそらくは fun や fn といったキーワードの導入に抵抗があったのだと憶測する

ただし、以前の(そして、Ruby2.0でも廃止されていない)構文は
lambda { |x| x } であれば矢印は使わず、lambdaという見間違えようのないキーワードが
採用されているから、これをラムダ式と見なさないという判断にも無理があるのではないかと

753 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
いや、無理があるとか無いとか、決めるのお前じゃないから

754 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>752
であれば |X| というブロック引数の違和感、わかりにくさは無視か?

755 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>752
とにかく、お前が「認める」「認めない」とかいう判断を必要とする
時点で、それはお前の主観に塗れた排除されるべき要素なんだよ。
相手には客観性を求めるくせに、いいかげんアンバランスに気付けよ。

756 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
確かにブロック引数は違和感あるな

757 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
367に絡んでるだけで自分の意見が何もないやつのほうが邪魔なんだよ

758 :367:2013/08/18(日) NY:AN:NY.AN
>>746
Rubyの関数型プログラミングではif修飾子は無視できる、ってことだよ
逆に、Pythonの自然な構文 if <cond>: <true> else <false> は、
Pythonの関数型プログラミングでは使えないので不自然なif式を使わざるをえない

これは、クイックソートのコード合戦で、明らかになったのではないかな?

759 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
おまえがいちばん邪魔

760 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
> これは、クイックソートのコード合戦で、明らかになったのではないかな?

まーた釣り臭い書き込みを……
上手いなーw

761 :367:2013/08/18(日) NY:AN:NY.AN
>>750
>それとも関数型を意識せず設計された言語は存在価値無し!とか思ってんの?

いや、>>653は自分のカキコだけど、なにか?
>>367の冒頭で書いたように、この議論は「関数型プログラミングの適性」という
限られた条件下での比較だから、誤解は勘弁願いたい

762 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>761
そのわりに、構文のセンスとか設計までさかのぼって議論しているじゃん。
明らかにおかしいよ。

763 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
なんだ? もう次スレの話か?

立てておいたぞ。

【PHP,Python】スクリプト,バトルロワイヤル37【Perl,Ruby,JS】
http://toro.2ch.net/test/read.cgi/tech/1376836047/

764 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>758
どう明らかになったのか知らんので、説明頼む
Pythonのif式ではクイックソートが書けなかったんだっけ?

765 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
何が自然で何が不自然か
何が読みやすくて読みにくいか
これは考え方次第なんじゃね?

例えばCOBOLが自然言語に近いから
わかりやすいという主張があった。
これはある意味間違ってはないと思う。

違いは、数式で表現するか文章で表現するかだよ。
数式で表現すれば簡潔に書け、数式を知っている者にとってはわかりやすいが
知らない者にとってはわかりにくい。
文章だと数式を知らなくてもわかるが、少し文字が多くなる。

どちらがわかりやすいかというのは
場合によりけり。

俺は、なんでも短くかければいいとは思わないな。

766 :367:2013/08/18(日) NY:AN:NY.AN
>>752
ナリスマシかよw

>>754
樹を見て森を見ず

767 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
括弧が省略できれば見やすいか?と聞かれれば、
省略しないほうが見やすい場合もある。
セミコロンも同じ。

コンピュータはルール通りに解釈するから
どんな書き方でも解釈できるが、
人間はそうは行かない。

句読点と一緒で、コンピュータにとっては不要でも
適度に改行やスペースや区切りがあると
人間は見やすくなる。

人間にとって見やすいのは何か?
それはなんでも省略することではないと思う。

768 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
> 樹を見て森を見ず

木と森の判定がお前の主観になってんだっつの

769 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>752
> Rubyの -> x { c } という構文は、Ruby2.0から採用されているね
> これが違和感のある構文だというのは、自分も認める
> この -> は、矢印ではなくてギリシャ文字のラムダを横に倒したものらしいが、
> 正直言ってコジツケだし、写像関係の矢印とまぎらわしい

今はUnicodeが自由に使える時代なんだから、
ASCIIの範囲で書ことうせずに、Unicode使えばいいのにね。

文字が入力できないという問題は
IMEやテキストエディタの問題。

770 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
こういう逆ポーランド記法と一緒で、記述位置と内容に違いはなく完全な一対一対応してるだろ。

3 4 + =  3 + 4
1 5 + 2 3 + *  =  (1 + 5) * (2 + 3)

771 :367:2013/08/18(日) NY:AN:NY.AN
>>754,756
>>736の引用カキコで書いてあるように、コードの読み手にとって
素直に迷い無く読みとれるか否か?という視点だよ
>>752で書いたように、キーワード lambda が先行するのだから、
それをラムダ式の仮引数以外の何かと誤解するとは考えにくいと思うけど、
いかがかな?

772 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
いや、違和感あるし読み難いよ
だからアウトな

773 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>766
> ナリスマシかよw


   AA省略


  ナリス・マーシー (1900〜)

774 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>771
ブロック引数にこんな記法使う言語なんかないし、
実際、ブロックローカル宣言と区別付かないし、
素直に迷いなくは読めないからやっぱりアウトな。

775 :367:2013/08/18(日) NY:AN:NY.AN
>>764
Pythonの最後のコードは>>650で、(不可解な)if式を使っている部分が以下の行

f = lambda xss, x: (xss, xss[0 if x < xs[0] else 1].append(x))[0]

この行は

f = lambda xss, x: (xss, xss[if x < xs[0]: 0 else 1].append(x))[0]

とは書けないから、「Pythonは式指向ではない」ことが明らかになった

if x < xs[0]: 0 else 1 の部分だね

776 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
>>775
それPythonのif式で書けちゃってるじゃん

お前、Pythonのif式がダメって結論からスタートしちゃってるよ
それじゃダメな理由が説明出来てない

777 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
✕「Pythonは式指向ではない」ことが明らかになった
○「Pythonは私の好みに合わない」ことが明らかになった

778 :デフォルトの名無しさん:2013/08/18(日) NY:AN:NY.AN
表面的などうでもいいこと。
英語で動詞が先に来たり、結論を先に述べるとかと一緒で言語の内部設計と関係がない。

779 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
おいおい
「明らかになったのではないかな?」とか言っといて
よくよくきいてみれば「俺好みの順番では書けていない」かよ。
ふざけんな

780 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>777
---- 壁5. 式指向(条件判定式)の壁 ----

じゃなくて

---- 壁5. 私好みの壁 ----

なんだなw

781 :367:2013/08/19(月) NY:AN:NY.AN
>>769
その考え方を導入した言語が Fortress だね
 http://ja.wikipedia.org/wiki/Fortress
日本語の解説書も出版されている

・Fortress言語―マルチコア時代の並列化プログラミング言語
 http://www.amazon.co.jp/dp/4765533379/

782 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
順番だの自然さだのなんて主観は「樹を見て森を見ず」。
完全に本質を外しているよ!
と言ってあげたい。

783 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>780
それは400台のレスで既に明らかになってるよ
367の言う「式指向」という言葉は「構文の見た目が私の好みに合っている」という意味

784 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
はい終了

785 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>783
え?そういう話なの?!

786 :367:2013/08/19(月) NY:AN:NY.AN
>>776
理由については、>>738を参照汁

787 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
Ruby1.9のTCO実装は不完全だから壁は越えられないでFA?

788 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
Rubyの exec if cond はどう説明するの?
関数型的な機能じゃないから見て見ぬふり?

789 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
もう面倒だから、誰かが異質だって言ったら即アウトにしよう

790 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>788
きゃつの主観で無視できる存在らしいぜ。

791 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
少なくとも>>775は上と下で読みやすさに差が無いな
むしろ若干上の方が読みやすいくらい

792 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
聞けば聞くほど判断基準が怪しく思えてくるな

793 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>787
いいよそれで

794 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
Haskellのリスト内包表記もどっちかというと>>775の上やexec if condに近いタイプだが、
あれは許せるのか?
ちなみにPythonもほぼ同じ表記を採用している

795 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
おまえら暇だなぁw
こんなrubyキチに付き合うとはw

796 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>795
別に関数型言語が偉いとか誰も何も言ってないのに、Rubyの順位が高いだけで
脊髄反射のようにRubyキチ扱いする奴ってどうなのかねぇ?

797 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
I like the Python version better,
because it keeps the two options next to the condition itself,
rather than throwing one of the two possible results way over on the other side of the positive result.
It is easier to see the condition as controlling both of the possible expressions,
with one in its left hand and the other in its right.

Plus, it reads very cleanly as English grammar,
and readability is one of the things that drew me to Python in the first place.

798 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>796
ここまで見る限り十分論理的な批判ばかりだと思うぞ
誰もRubyをdisってるわけじゃないし

799 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>796
言ってることがおかしいぞ?
さてはおまえもRubyキチか?

800 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
Rubyは一番手に馴染む

801 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
左から右へ流れなきゃいけないってむしろ手続き型の頭だろ
SQLとかもそうだけど宣言型では方法より結果を先に書くのが好まれる傾向がある

802 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
超訳
結果が左と右に綺麗に分かれていて見やすいし、条件が結果を
コントロールしていることがよく分かる
それに、英語の文法に沿っていて読みやすい
読みやすさは重要だ

つまり、英語のネイティブにとって、英語に近いPythonの方がむしろ
読みやすいという意見があるようだね

803 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
式指向()では違うんだとさ。

804 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
そもそも、左から右へ流れてる流れてないというのは
どういう基準で決まるんだ。
「もしも~ならこうして、そうでないならこうする」という日本語の
流れに沿ってるのが左から右へ流れてるってこと?
だとすると、英単語を使ってるPythonからしたら噴飯ものだよね

805 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
宣言型というよりか、結果が先に来るのは
英語の文法のせいじゃね?

もし、英語が日本語のように
結果を後に書く文法だったら、
右から左なんてものもなかっただろう。

SQLも、「○○テーブルから、○○という条件に合うものを、抽出」という
書き方になっていただろうね。

806 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
一行に複数の文を書いたら、
左から右へ処理が進むわけで、
右から左という流れがそもそもおかしいんだろう。

807 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
代入式も右から左だし
関数の定義だって入力と出力を先に書いてからそのあと中身書くでしょ

808 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
そもそもRubyだって代入は右から左に処理が進む
367が大好きな流れの向きとは逆

809 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
そもそも、関数が
function(a,b)みたいな順序になったのも英語のせいだな
動詞、目的語という語順だから
だから、目的語に対して時系列に左から右へと関数が
適用されていくという形を取ることができなかった
このせいでプログラミングの世界は遅れてしまったと思う

それに、配列とただの値を区別するのも英語らしい
全てが配列であり、普通の値は、長さが1の配列として扱えたら
統一的に扱えていいのにと思ったことはいくらでもあるけど、
日本語が主流だったらそういうスクリプト言語ができていたかもね

810 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
perlの変数がスカラーと配列で最初の文字が変わってくるのも
英語の単数系と複数形の影響だろうね
Ruby作者が「私には複数か単数かなんてことはどうでもいいので、
Rubyはそうなってない」という話をしてるのを聞いて、ああ、日本人なんだなあ
と妙に納得したよw
多分英語圏の人にとっては、どうでもいいことじゃないんだろうねえ

811 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
左から右に流れるのが好きなのは別に構わんが、
Haskell等の関数型言語の関数合成は右から左
だから、関数型プログラミング適正とやらとは無関係ですね

812 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>811
無関係だろうね
ただし、劣ってると思う
時系列に左から右へと行く方が明らかに便利
英語に引きずられておかしなことになってしまった
全ては英語が劣った言語のせい

813 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
関数の語順までいくと、ラテン語のさらに前の言語くらいまで起源が遡りそうだが
まあ欧州圏の言語族ではあるだろうな

814 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
だらだら書く分には左から右が好きかな
読むときは左に結果が来てる方が読みやすい

書き捨てコードが主戦場のRubyは左から右であるべきだな

815 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
結論が先にきたほうが分かりやすいのは前置きが長い場合かな
そういうのはIdeの機能で飛ばしたり畳んだりとどうとでもなるが

816 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
コードが短かったりIDEの入力・表示補助があるなら
どっち向きにコードが流れるかなんて
どうでもいい

817 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
基本は上から下、左から右が分かりやすいに決まってるだろ
英語圏のバカどもが、英語の感覚でやるからそれに気づかなかっただけ
英語以外の民族にはいい迷惑
オブジェクト指向が流行ったのも、ぶっちゃけ英語と反対の語順で書けて、
時系列と流れが一致して分かりやすくなったからだ

818 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
住所の書き方が一番納得できない

819 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
あれ?式指向()が論破されちゃったから
腹いせに英語をdisることにしたの?

820 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
流れに逆らうってのはどだい無理が出てくる
あとから参照するために、Itやらthatやらに相当する変数がたくさんいるんだよ
これでプログラミング不必要な変数を乱発しわかりにくいものになった
それもこれも語順が間違ってたせいだ
Jqueyなんかがメソッドチェーンで人気を博しているけど、
最初からそうなるべきだったんだよ

821 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
代入が右から左なのに、それ以外が左から右だと
代入する側とされる側が遠く離れて読み難いんだよ

だから、x = y で x が y に代入される言語を作ってから戻ってこい。な?

822 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
正直日本語でも
「こうするよ、~ならね。さもなくばこうする。」とは言えるし
時系列もこの場合は関係ないから、Pythonの式でも別に不都合はないよ

823 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
パイプは左から右への流れだな。

echo hello | sed 's/$/ world/' | wc -c

関数もこんな表記を採用すればよかったんだよ。

v = foo(bar(baz(123))) みたいなカッコの対応取れてるか?
って問題は発生しない

123 | baz() | bar() | foo() => v

メソッドチェーンみたいで見やすいだろう?

まあ引数が複数になった時どうするかって話があるけど。

824 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
処理の流れは左から右がいいが、定義は話が別。

日本語の辞書でもそうだが、
まず単語がでてきて、その説明を書く。

------------------------------
★プログラミング言語
プログラミング言語(プログラミングげんご)とは、
コンピュータに対する一連の動作の指示を記述するための人工言語の総称である
------------------------------

みたいにね。

定義とはC言語で言う#define みたいなもの。
関数の定義もそう。左は右と等価であることを示すもの。
なお代入は定義ではない。

825 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>824
よく分からない
定義が先に出てくると、なんで左から右じゃないの?

826 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
だいたい、代入が右から左とか言ってるけど、それは錯覚だ
矢印を変えればあら不思議
v => 123
左から右だろ?
しかも、これは「vが出て来たら、123に置き換えろ」と読めるから合理的
実は代入の矢印はみんなが考えてるのとは逆にするべきなんだよ

827 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
x = y + 1 とは書けても
x + 1 = y とは書けないから、代入は紛れも無く右から左だよ

828 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
例えば、x = x + 1 と書くことが出来る。

これが定義であるならば、

x = x + 1
x = (x+1) + 1
x = ( (x+1) +1) + 1
 :
 :
となって意味不明なことになる。

だからこれは定義ではない。

829 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
#defineの動きを見てみよう。

#define VALUE foo() + bar() // この時点では処理は実行されない。
int value = foo() + bar() // 処理が実行されvalueに値が入る。

printf("%d", value); // 変数の値を出力するだけ
printf("%d", VALUE); // ここでやっと処理が実行される。


このように、代入と定義は実行されるタイミングが違う。
定義だと必要になるまで実行されない。
すなわち、遅延評価と同じものなのだ

830 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>826
ソッコーで>>827に論破されててワロス
Ruby厨って存在自体が恥ずかしいね

831 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
俺はRuby厨でなんでもないのだが、仮にy+1=xとかけないからと言って
なんで紛れもなく右から左になるのか分からない
単に、方向が固定されてることを示しただけであって、それが右から左なのか
左から右なのかはその議論からは確定しないじゃないか
しかも、y+1=xと書けないのはそういう規則にしているだけの話だろう

832 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
y = x + 1 って、時系列的には x + 1が計算されて、その結果がyに代入されるって順番だよね?
まさか、これすら受け入れられないレベル?

833 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>829
君のネタはとても面白いからコテつけてくれないか

834 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>832
そういう話ならカッコの有無とか演算子の優先順位で状況次第ってことになる
自分はそういう話をしてるつもりはないんだけど、もともとは
流れ的にそういう話だったみたいだな
多分、文脈と違う話をしてたわ
スマン

835 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>829
誰も定義と代入が一緒だとは言ってないと思うんだが
なぜに一生懸命そういう説明をしてるんだ?

836 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
まあjsとかpythonとかの場合、関数定義を変数に代入したりするから
ややこしいんだが

837 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>833
面白いならコテつけなくても
見分けつくだろう?

まあ、つける気はないが。

838 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
上から下、左から右という手続き型の基本原理に洗脳されてる奴ってことだ。
結論が先で詳細、条件があとは関数型だからあり。
TrueResult if Conditions
TrueResult if Conditions else FalseResult

x = y + z という代入と同じ仕組み。
これは手続き型では特例で本来は、y + z -> xという処理の順序で書かれるべき。

839 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
お前ら目を覚ませ

840 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
関数型も本来は上から下、左から右であるべき
そうでないから引数に余計な括弧がついたりするんだ

841 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>838
それは正確には、+演算子の優先順位が代入演算子の優先順位より高いというだけ
別に例外でも何でもなく、よくあること
たとえば、1+2*3などは乗算から先に計算するがこれと全く一緒の理屈

842 :367:2013/08/19(月) NY:AN:NY.AN
>>735
RubyのTCO情報について、提供ありがとう
この文書の存在は知らなかったので、興味深く読ませてもらいました

これは、将来的に特殊なケースでTCOが有効化されないという実装の不完全性(バグ)が
発見されたと仮定した時、それをどう扱うのか(=どう判断すべきか)?という話だね
つまり、(Schemeのように)言語仕様としてTCO実装を必須(MUST)にすべきか、
あるいは(Common Lispのように)TCO実装は推奨(SHULD)にするかという判断だ

もし前者であれば、たとえ特殊なケースであってもTCOが有効化されなければ
(仕様として)不完全であると判断されるし、後者であれば、特殊なケースでTCOが
有効化されなくてもTCOが実装されていると判断できる
そして、その質問に対し、Matzは後者であると答えている

>>707に話を戻すと、「末尾再帰最適化の壁」が(前者の)言語仕様を意味するのであれば
Common LispとRuby1.9は「どちらも不完全だから壁は越えられない」となるし、
これが(後者の)実装依存を意味するのであれば
Common LispとRubyは「どちらも壁は越えている」と見なせる

>>787
どちらの判断でも(個人的には)かまわないと思うけど、Common Lisp支持派の
意見も聞きたいので、本件の判断は保留、つまり現状維持とさせていただきます

843 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
そもそも、結論が先と言ってるわりに、falseResultは一番最後にきてるじゃん

844 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>841
馬鹿だなぁ。代入の話は演算子優先順位とは全然関係ない
優先順位を弄っても、「y + zの値をxに代入する」という処理で
y + zを=の左側に持って来れるわけじゃないからな

出来るもんならやってみ?

845 :367:2013/08/19(月) NY:AN:NY.AN
>>707の「式指向の壁」について、結局、>>783の引用カキコに対して
正面からは反論できない、ということでいいのかな?

つまり、Pythonのif式、<true> if <cond> else <false> の読みやすさについて
英語文法として自然である(>>802)とかといった意見はあるけど、
もしそれら意見に客観性があるのならば、

 条件分岐式があるPython以外の言語 Smalltalk/Lisp/ML/Haskell の設計者達も
 Pythonと同様の構文を採用したはずであるのに、実際にはそうならなかった....

この矛盾を説明できない限り、「式指向の壁」は壊せないよ

846 :367:2013/08/19(月) NY:AN:NY.AN
>>794
Pythonのif式とHaskellのリスト内包表記に類似性を見いだせるという意見は理解できし、
リスト内包表記はHaskellとPythonに固有の優れた特徴(個性)だと思う
ただし、プログラム言語の基本要素である条件分岐構文 if <cond> then <true> else <false>
について、Haskellはそれを「式」として定義し、Pythonは「文」として定義した

Haskellにとってif-else式は欠くことのできない基本要素であるのに対して、
リスト内包表記はfilter/mapの組合せ処理を簡便にする構文糖であり、必須の構文ではない
この理屈は、Pythonにも当てはまるはずだ
Pythonにとって「if <cond>: <true> else <false>」というif文は、言語として基本要素なのだから

もし反論があるなら「論よりコード」、クイックソートをif文を使わずif式で書いてみて、
それがPythonらしい可読性のあるコードかどうかを批評するところから始めればいい


>>788
これも上段の説明と同じだ
Rubyにとって条件分岐の基本はif式であって、if修飾子ではない

実際、クイックソートのRubyコードで(>>560,665)if式は使われている(=使わないと書けない)けど、
if修飾子は使われていない(=使わずに書けている)ことは実証された

三項演算子の議論と同様に、枝葉の矛盾で幹ごと倒そうとする論法を「詭弁」と言う

847 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>777
テスト

848 :367:2013/08/19(月) NY:AN:NY.AN
>>432
遅レスになったけど、>>665等で三項演算子を使ってみた
これは>>429の「条件分岐が入れ子になった時に最も深い分岐で使う」ケースになる
普段であれば迷わずif式を使って以下のように書くけど、>>429でそう書いたので、
三項演算子を使っても構わないレアケースとして紹介したつもりだ

三項演算子(>>665):
  e < array[0] ? [xs << e, ys] : [xs, ys << e]

if式:
  if e < array[0] then [xs << e, ys] else [xs, ys << e] end

849 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>846
それこそ詭弁だ。
条件分岐式として使う局面に限定した場合、
Rubyのif修飾子はPythonのif式と違い、
else節がないという致命的な欠陥がある。
致命的欠陥品が使われない(事実上使用できない)ことをもって
それが記述の順による使いにくさに起因すると因果関係すり替え、
Pythonタイプのif式が使いにくいものであるという
結論に持って行くのはフェアーじゃない。

850 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
るいとも

851 :367:2013/08/19(月) NY:AN:NY.AN
またアンカを間違えていた
>>845の先頭行を訂正する

X: 結局、>>783の引用カキコに対して
O: 結局、>>738の引用カキコに対して

852 :367:2013/08/19(月) NY:AN:NY.AN
>>849
たしかにRubyのif修飾子にはそういった欠点がある
だからRubyにとってif修飾子はオマケであって、if式が条件分岐の基本構文という位置付けになる
オマケに欠陥があるからといって、基本を無視するのは間違っているよ、という話であり、
それを「樹を見て森を見ず」と揶揄している

それに対して、Pyhtonでは、条件分岐の基本構文は(式でがなく)if文として定義され、
しかも(オマケ?の)if式には、他言語の常識に反した構文(>>738)という矛盾を抱えている
独りよがりな常識はずれの構文なのに、それを認めることこそ(他言語に対して)アンフェアだと
考えるし、なぜPython特権を認めにゃならんの?という話だ


繰り返しになるけど、(>>845で書いたように、)>>783の矛盾は「誰も説明」できないのかな?

853 :367:2013/08/19(月) NY:AN:NY.AN
またアンカを間違えていた....orz
>>852の最終行を訂正する

X: >>783の矛盾は「誰も説明」できないのかな?
O: >>738の矛盾は「誰も説明」できないのかな?

854 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
どうあっても

367の言う「式指向」という言葉は「構文の見た目が私の好みに合っている」という意味

であることを367本人としても強調したいらしいなw

855 :367:2013/08/19(月) NY:AN:NY.AN
>>852の最終行を(>>854から)再訂正する
>>854では、「何が矛盾なのか」分かりにくい文章だった

X: >>783の矛盾は「誰も説明」できないのかな?
O: >>845(>>738)の矛盾は「誰も説明」できないのかな?

856 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>855
ん。>>854はなにも矛盾していないぞ?

857 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>855
矛盾なんか別にないだろう。

C系言語のif文の列びに準じようとする判断が勝ったか、
英語表現としての自然さを重んじる判断が勝ったか

の違いってだけ

858 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
手続き型のシェアが9割以上とおなじ。
Pyhtonが先駆的なだけだろ。

859 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
人工言語に自然言語の性質を求めてもねぇ

860 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
なんのための形式言語なんだ、って話だよな

861 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
処理の流れと一致する必要はない。
代入(=)や、C/C++のプロトタイプや、本の目次などは処理の流れと一致してない。

862 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
それらはもともと自然言語にない表現だし視認性や可読性もあるしな

英語表現としての自然さを建前に
視認性や可読性を損なってもいいのかということ

863 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
Ruby使用者ってこんなのばっかりなの?
いくら正論で反論して論破しても>>367が屁理屈ゴリ押しで擁護するから
逆にRubyの印象を悪くしているのに

864 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>863
誰一人Ruby言語自体をdisってはいないのにRubyがdisられていると思い込んでいるのがポイント
これぞRubyって感じだね

865 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>誰一人Ruby言語自体をdisってはいない
やめなよそういう言い切りは
君が過去スレまで遡って「Ruby言語自体をdisるレスは一つもなかった」ことを証明しないといけなくなるよ

866 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
Haskellのリスト内包表記
[x*x | x <- list, x < 3]
これ、明らかに式指向()に反してると思うんだけどどう?

867 :367:2013/08/19(月) NY:AN:NY.AN
>>857
Pythonの(不可解な)if式構文の正当性に関する根拠である
「英語表現としての自然さを重んじる判断」には客観性がある ==> 仮説

それ以外の言語では条件分岐式構文として、上記の判断よりも
「C系言語のif文の列びに準じようとする判断」が勝った ==> 事実

もし「仮説」が正しければ、それは「事実」と反する、だから「矛盾」だろ?

しかもPythonのif文の構文は「C系言語のif文の列びに準じようとする判断」で設計された
これはPyhton自身の「内部矛盾」を意味する
つまり、ある時には「英語表現としての....」を、また別の時には「C系言語の....」を言うという、
ご都合主義でPyhtonは設計されたことになるけど、それでもいいの?という話だ

そして、この矛盾を解消(説明)できなければ、仮説「英語表現としての
自然さを重んじる判断」は、独りよがりな主観にすぎない、と言えるのではなかろうか

868 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
別に、Pythonって他の言語が採用してなくても
自分らが読みやすいと思った構文を採用してるだけだろ

たとえば、if式以外でも、 1 < x && x < 10 を 1 < x < 10 と書けるのも
Python以外で殆ど見た事ない

869 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>867
ご都合主義で場当たり的に追加された言語っていうのは
procオブジェクトがあるのにlambdaオブジェクトを追加した
Rubyのような言語を指すんだよ

870 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
はいRuby言語仕様をdisるレスきましたー

871 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>867
if修飾子は?

872 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
procとかlambdaとかで微妙な違いがあったりするのがrubyの嫌らしさ

873 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>867
構文ごとに判断がなされているだけなのに
なんで矛盾なんだ?
非一貫性、非対称性はRubyにだってあるだろうに。

874 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
要するにPythonをdisって、
いや、Pythonに限らず他言語の瑕疵をあげつらって
Rubyを持ち上げたいだけなんだろ?
ほんっっとMatz以下、Ruby信者には虫ずが走るわ。

875 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>867
Rubyにも「式 if 条件」の構文あるけど、Rubyもご都合主義で設計されたの?
しかも367曰く殆ど使われてないみたいだけど、そんな使われない構文を足すなんて
深く考えずに設計されてるんじゃないの?

876 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
そうですね
Ruby信者が絶滅すれば他の言語の使用者は互いにdisったりしないから
このスレも終了ですね

877 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
しかも 式 if 条件 って式じゃなくてステートメントだよね
式志向(笑)

878 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>876
バトル=disり、とは限らない

879 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
主観でしかないものを客観だと言ってるからツッこまれてんだろ
言語のdisりの問題じゃねーわ

880 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
後置のifが見やすい使い方って

return if 条件

以外になんか有る?

881 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
くだらねえ所に食い付きすぎ

882 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>864
言っとくけど、
ifは最初に持ってきても
英語表現だからな。

883 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>867の間違い。

Pythonのif文の構文は「英語のif文の並びに準じようとする判断」で設計された
だから、「if 条件 式」と「式 if 条件」の二つの書き方ができる。
どちらも英語表現だ。

884 :57:2013/08/19(月) NY:AN:NY.AN
ありがとう
英語とpythonの両方に詳しくなりました。

885 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>878
いや、このスレは最後の1言語が残るまでdisりあうスレなんだけどな

886 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
あ、まだ頑張ってたのか

887 :367:2013/08/19(月) NY:AN:NY.AN
>>846
自己レスになるが、Pythonコードでクイックソートは書けないのかな?

「式指向の壁」を越えた言語、Haskell(>>597)、ML(>>626)、Ruby(>>560,665)では、
どれも同じスタイル(パターンマッチまたはif式)でクイックソートのアルゴリズムを表現できている
後出しで条件を追加するのは失礼だから、先に書いておくよ:
1) if文は一切使用せず、if式だけで書くこと <== この条件クリアが式指向であることの証明になる
2) クイックソートのアルゴリズムを表現していること -- >>599はNG
3) 標準ライブラリ(itertoolsやfunctoolsなど)はOKだが、それ以外(numpyなど)はNG -- >>633,635
4) 効率を考慮すること -- >>636,638
5) 可読性に配慮すること -- >>640,649

これら条件は、他の言語との公平性を考慮したつもりだ
論よりコード、「Pythonが式指向言語である」ことの実証を期待したい

888 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>887
色々つっこまれてんだから、先にそれらに答えろよ馬鹿

889 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>887
お前の好みだとPythonのif式は可読性に劣るんだったよな?
1) と 5) という同時に満たせない条件出してなに公平づらしてんだよ。
馬鹿が。

890 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
いいかげん、367はスルーの方針でいいんじゃないのか?

891 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
人の話を訊くつもりが無いなら
自分のブログにでも書いてろって話だよな

892 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
ifとかはまだマシだろ
Pythonのdefや代入は文だからquicksortという関数を定義したければ
globals().__setitem__('quicksort', lambda xs: ....
と書かないといけない
この方法のquicksort定義にはYコンビネータが必要な気がする
あと、例外処理無理すぎる

893 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
Haskellの関数定義(名前束縛)も式じゃないでしょ

894 :デフォルトの名無しさん:2013/08/19(月) NY:AN:NY.AN
>>893
静的型言語のdeclarationはまた異なるカテゴリじゃないのかなぁ
Pythonのdefや代入のようなstatementは実行時に「副作用を目的として使用する」
もんだから関数プログラミング的ではないと言えるし
expression orientedかどうかってのは結局statementとの対比でみてるよね

http://en.wikipedia.org/wiki/Expression-oriented_programming_language

895 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
そもそも例外処理は関数型プログラミングと相性悪い

896 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
Pythonを式志向というのは無理だが、PythonはPascalみたいな
nested functionサポートしてるし、
method含めfunction(Python用語でいうとcallable)は全て第一級オブジェクトだよ
nested functionなんてALGOL68の時代からあるのに意外とサポートしてない言語あるよね
無名関数定義できるだけ、みたいなの

897 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
def partition(xs, f):
    return reduce(lambda xss, x: (xss, xss[0 if f(x) else 1].append(x))[0],
                  xs, ([],[]))

def qsort(xs):
    return (lambda (ss, ls) = partition(xs[1:], lambda x: x < xs[0]):
            qsort(ss) + xs[:1] + qsort(ls))() if len(xs) > 1 else xs

898 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>844
それはできないが、演算子の順位をいじれば、x=y+zで、「左にある=が右にある+
よりも先に行われる」ことはできるよ
+よりあとに代入が行われるのを持って、君は「代入は右から左だ」と
言ってるんじゃなかったの?
どうやらその反論をみると違う理由のようだけど、それを説明してくれないか?
俺にはなぜ君が代入が左から右だといってるのか分からなくなったわ

899 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
訂正
なぜ右から左だと言ってるのか

900 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>898
> +よりあとに代入が行われるのを持って、君は「代入は右から左だ」と
> 言ってるんじゃなかったの?

理解出来ないなら無理に絡んでくるなよ、馬鹿だな

時系列にそって左から右に処理が進むべきって話が>>806あたりの議論で
代入は処理を左に書けないだろうって意見が出たんだろ
だから、「+よりあとに代入が行われるとき、+は代入より左にある」のでなければ、
左から右に処理が進むことにならんだろうが

901 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
y = f(x)は関数型の特徴を表す。

902 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>895
そりゃそうだが、tryだのhandleだのが一種のパターンマッチ式なML族と
ステートメントなC++やPythonとでは式志向かどうかという観点では
全然違うと言わざるを得ない

903 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>900
意味不明だなあ
それはできないけど、+が後の場合は左から右にかける
もちろん、先の場合は無理だよ?
でも、それは代入の演算子の優先順位が高かった場合、同じように
「代入が+より前に行われる時に、代入を右側に書くことは出来ない」
んだけど、なんでそれは左から右と言っちゃいけないんだ?

904 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
すまん、なんかこんがらがって論理の反転の仕方を間違えたようだw
まあでも言いたいことは分かるだろw

905 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>903
あのさ、元々「全部メソッドチェインみたいに書けるべきだな」「おっと代入は無理だったわ」って話なんだぞ?
そのへん理解してる?


あとさ、演算子優先順位は関係ないんだって何度も言ってるだろ

> 「代入が+より前に行われる時に、代入を右側に書くことは出来ない」

これは括弧使えば x + (y = z) って書ける言語はある。でも

> 「+よりあとに代入が行われるとき、+は代入より左にある」

こっちは括弧使って演算子の優先順位変えても書けないだろ?全然違うんだよ馬鹿

906 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
def qsort(xs):
  def qsort_logic(xs):
    ss,ls = [],[]
    for x in xs[1:]:
      (ss if x < xs[0] else ls).append(x)
    return qsort(ss) + xs[:1] + qsort(ls)
  return xs if len(xs) <= 1 else qsort_logic(xs)

907 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
> 代入を右側に書くことは出来ない

これってさ、正確に言えば、
=を挟んで左側のものを、右側に入れることは出来ないって意味でしょ?

通常は変な書き方をしないから、単に代入を右側に書くことはできないって
言ってるのであって、

> x + (y = z)

これって、yにzを入れてるのであって、
zにyを入れてるんじゃないでしょ?

なら、代入を右側に書いていない。

908 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>907
せやな

909 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>907
右側とか左側とかじゃなくて、「右から左へ」「左から右へ」って言い方しろよ

で、確かに代入は「右から左へ」値をコピーする処理だけど、それが何か?

910 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
「文字列」→変数

日本人としては、代入はこう書きたいな。

911 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>906
>>887の要求を全て満たしてるのに、完全に手続き型のコードになっててワロタw
367の言ってる事って関数型プログラミングと関係無いんじゃね?

912 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
ああ、だいたい、どういう意図かわかってきたわ
優先順位関係なく、+がどうやっても左にかけないから、
右側から左側だと言いたいわけね
演算子の順位も関係ないと

でもやっぱり理屈としては間違いだね
+をどうやっても左側に書けない本当の理由は、
+が右辺値にしか作用しないから
それだけの理由だと思う
逆にいえば、左辺値にしか作用できない、Cのポインタ操作にかんする
アドレス加算演算子とかはどうやっても左にしか書けない
それを遅らせなくてはいけない場合でもね
だから、結局判例が出来てしまう

処理が左から右に流れてるとか、右から左になが流れてるとかは、やはり+が左に書けないこととは関係ない

913 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>911
効率を考慮する必要がある時点で関数型は使えないからね

914 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
そして、演算子の優先順位こそが、左が先か右が先かを決定する

915 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>912
メソッドチェインのように「左から右」に書けない処理があるって言ってるだけなのに、
「左から右」の処理を持って来て反例が存在する?
だれも全てが「右から左」だって言ってないだろ
本当に底なしのアホだな

916 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>914
それだと x.foo().bar() と (bar . foo) x は両方「左から右に」処理が流れてることになるけど、そんな話だったっのか?
もうそれで良いならいいや、馬鹿の相手は疲れた

917 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>915
つまり、「代入は右側から左だ」と言っておいて、
その本当の意味は実は「代入は左から右に処理を並べたくても、
書けない場合もあるよ」ってことだったの?
ごめん、完全に誤解してたわw
それなら文句ない
まあ、右から左に処理を並べたくてもかけない場合もあるけどw

918 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
まあ、アドレス加算演算子の適用が「処理」かどうかは意見が分かれるところだが

919 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
ん? Smalltalkのように代入操作をメソッド(例えば --> とか)として
定義できる言語ならメソッドチェインで代入も右に書けるぞ。w

| a b |
a := b := 0.
3 + 4 --> #a * 5 --> #b.
^{a. b} "=> #(7 35) "

920 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
あ、ごめん、アドレス加算演算子は処理だね
アドレス演算子だと思った

ていうか、アドレスとか関係なく、加算演算子を左辺値に書けたっけ?

921 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>916
言われてみれば、演算子の順位だけでは語れない部分もあるねえ
関数合成の場合、あとから合成した関数が呼びだだされる場合の処理の流れも
考慮にはいるかな
この辺はざっくり処理が左から右にかけるといっても曖昧なんだなってことがわかるね
まあでも、演算子の順位も加味されて処理の流れが決まってることに間違いはないけど

922 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>919
おーすげー
動的型言語は代入と宣言が似た構文だからなー
その調子で変数宣言も書いてくれ

923 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
うろ覚えだが、*a++=1みたいな場合だな
1=*a++とはそりゃかけんわ

924 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
MonadやOCamlのletは左から右なのか?
結局右から左って何?

925 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
Lisp使う事が多い俺には、左辺値だの優先順位だのと羨しい話だな

926 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>924
最初に言い出したのは367なので、彼に聞いてください


>>738
> 普通の言語は「条件式 -> 式1 -> 式2」と左から右へ流れる(それが自然)

927 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
英語では自然だというけど、証拠がありませんって
言ってるけど、797を書いた人物はどう見ても
英語が相当できる人物だろ
それでも納得しないのか
嘘をついてるとかネイティブレベルかどうか分からないとか
そういう厳しい基準の議論なの?

928 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
めんどくせーな。リンクぐらい貼れよ
>>797

929 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>912
> アドレス加算演算子とかはどうやっても左にしか書けない
>>923
> 1=*a++とはそりゃかけんわ

???
それってリテラルに代入できないだけだよね?
y = *x++ とは書けるし

930 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
>>929
その場合、*演算子の意味が別物になっとる
cのポインタはこういうところが混乱の元でもあるね

931 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
まあ、確かにリテラルに代入できないだけだよ
x+1に代入できないだけなのと一緒

932 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
*pgr++ = 1

にしてもCにアドレス加算演算子なんてあるんだろうか
ふつうのインクリメント演算子だと思うのだが

933 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
アドレスをインクリメントするから、普通とはちょっと異なるよ
まあ、でも、アドレスも値の一種だとか、よくは知らんが、マジで厳密に
突き詰めれば同じなのかもしれん
ただ、仮にそうだとしても言わんとしてることとは関係あるまい
揚げ足取りの類

934 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
えーと、”無理やり”かけるというのは
自然には書けないとみなします。

935 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
Rだと
1 -> x
x <- 1

936 :デフォルトの名無しさん:2013/08/20(火) NY:AN:NY.AN
左辺値にはインクリメントとか、当然できんね。
あとキャストにも制限があったっけ?

937 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
アドレスの加算も知らなかった馬鹿は黙ってろよ

938 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
おまえがバカ

939 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
Gets!!! (ほんとにあった怖いコード in jQuery)
http://orgachem.hatenablog.com/entry/2013/08/21/030244

いやーこれはひどいw

> Gets???もう、もう意味が分からないです。いったい何をGetsするんですか。
ソースコード読んでますか?

この関数はコレクションに値をset/getする関数ですよ?ってコメントに書いてますよ?
おなじみの、引数があればsetterとして、なければgetterとする関数です。

上にset valueって書いてあるじゃないですか? getsは当然get valueのことでしょう。
このコードはそもそもvalueを読み書きするもの。汎用的なものなので
具体的なvalueが何かはわからない。だからvalueって書くしかない。
valueの読み書きなのは関数のコメント見りゃわかる。なのでvalueを書くまでもない。
ただ、どの部分がsetでgetなのかはわかりにくいから書く必要がある。

> 引数が7つもある香ばしい仕上がり。Multifunctionalにした結果がこれだよ!

はい全然違います。getとsetを分離した所で、引数の数は変わりません。
むしろ重複コードが増えます。重複させない限り分離できません。
自分ならどうコードを書くか、せめて頭のなかで書いてみましょうね

> これがJSで最も有名なライブラリか……誰か助けて…

こんなくだらない点しか指摘できない。さすが有名なライブラリ。

id:devorgachem えらそうにw

940 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
俺tueeeの香りがぷんぷんしますw

941 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
一般的には、Getsというコメントがあれば、
なんの値を取得しているんだよ!取得する”具体的な値”は何か
ちゃんと書けってつっこみを入れる。

だけどこのコードの場合、汎用的な関数なので取得するのは
"値"としか書けない。値は具体的ではない。

Gets valueと書いた所で、なんの値を取得しているんだよ!ってつっこむ。

そもそもこのコメントが書いてある意味を勘違いしている。
これは ”何を取得しているか” ではなく "何をしているか” を説明するためのコメント

この関数は、汎用的な値を代入、取得するものである。
だから"値"を取得するということは、Getsというコメントを
見るまでもなくわかることである。

わからないのは、どの部分がsetterであり、どの部分がgetterであるかということ。
だから、複数の値のsetter、単一の値のsetter、そしてgetter。
”何を取得しているか” ではなく "何をしているか” それを示したかっただけ。

このブログの人は、Getsというコメントを見て
ソースを読まずに脊髄反射をしただけである。
典型的な初心者を抜けたつもりの初心者

942 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
学生らしいし許してやれよ
https://twitter.com/orga_chem/status/314414450293751810

>>941みたいに丁寧に添削してくれる人が身近にいないと、
いつまでも誤った理解が修正されずに「俺って天才かも」という歪んだ自尊心が育っていく典型例だな

943 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
機能の概要も把握せずにコメントにだけ突っ込んで改善方法すら提示しない
典型的なワナビー

944 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
で、なんでこんなの晒したん?

945 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
>>939
さすが何のコメントも資料もなくても関数の内容を全て把握している天才は違うな、言うことが

946 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
>丁寧に添削してくれる人
え…え?
ネチネチいじめまわしてるように見えるんだが…お前優しいな(自分自身に)

947 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
ていうか本人と全く関係ないところで晒してバカにする行為を「丁寧に添削」とは本人以外の誰も言わないwwww

948 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
>>946-947
日本語苦手そうだな。ここで書き込んでることが丁寧ということではないぞ

949 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
>>946
臭い

950 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
こんな簡単な関数にコメントとか資料とかマジで言ってるとしたら初心者向けの本で勉強し直した方がいい

951 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
簡単ではないだろ
jQuery使ってないとわからん

952 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
>>944
> で、なんでこんなの晒したん?
さっきはてなブックマークでみつけた。

「納涼!ほんとにあった怖いコード」シリーズで
面白く読もうとしてたら、俺の大好きなjQueryを
ディスってたから、速攻ありえないと思ってコード見た。

やつのブログでディスり返すつもりだったが、
匿名で書き込めなかったのでここに晒した。

jQueryはショートコーディングでかいてあるから
多少わかりにくくても、短くしているところはあるんだが、
まったく天下のjQuery様がそんなヘボするわけ無いだろ。

これがJSで最も(略)誰か助けて・・・じゃねーよクソガキが
てめーが未熟なだけだ。


>>945
> さすが何のコメントも資料もなくても関数の内容を全て把握している天才は違うな、言うことが
関数にコメントあるじゃんw その上50行程度の関数

>>946
> ネチネチいじめまわしてるように見えるんだが…お前優しいな(自分自身に)
正解! だから匿名で書き込もうと思ったけど、書けなかったから
ここでネチネチいじめたw

953 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
バカ丸出し

954 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
まあ、こいつよりは明らかにjQueryの作者の方が物事をよく知ってるし、
プログラマとして上だろう
つまり、こいつが指摘してることは、的外れか取るに足らないことだと想像できる

955 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
APIの資料は豊富だし、省コード多機能も用途考えれば当たり前だから
普通は突っ込まないけど、汚いことは汚い

ただ実際のコードの内容やその関数のテストコードが無いことに突っ込まないあたり初々しい

956 :デフォルトの名無しさん:2013/08/21(水) NY:AN:NY.AN
汚いというのなら、きれいに書きなおしてくれよ。
たった50行だ。

テストコードがないのは当たり前。
なぜならこのコードはプライベートメソッド相当だから。
この関数は内部で使う非公開関数。だからマニュアル化もされていない。

957 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
そういったいろんな言い分や事情を全く知らないまま
指摘してるのは、想像に固くないな
やはり、実績が違いすぎる

958 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>956
同じ作者の昔のaccessのコード見てこい低能

959 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
JS厨には三項演算子使いまくりのコードが綺麗に見えるらしい

960 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>958
https://github.com/jquery/jquery/blob/1eb1ad616069ab103ceecf48c48514f51dd5d5ac/src/core.js

これか? 昔のコードが書きなおされたのは、
昔のコードに問題があったからなんだけど、
問題が有るコードと比べてなんの意味があるんだ?

俺はきれいに書きなおしてくれといったんだぞ?

綺麗に書き直しました。ただバグがあります。
でも綺麗だからこっちに入れ替えてくださいって
いったらぶち殺されるぞw

>>959
あなたの会社では、三項演算子は禁止ですか?

961 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
今のコードが汚いという話をしてるんだろ。

962 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
だから今のコードを綺麗にしろって話をしてるんだろ?

必要な処理が足りないコードと比較しても
意味が無い。

963 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
何でそんな俺が一銭も得しない事を強要するんだ?
他人のブログほじくり出してきて来るだけあるな。

964 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
> 何でそんな俺が一銭も得しない事を強要するんだ?

お前がコード見て汚いと言ったから
じゃあ汚いというのなら、きれいに書き直せよ
って言われただけだろ?

何逆ギレしてるんだ?

自分の発言に責任をもてってだけだろ。
できなきゃ謝罪しろ。

965 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
あー、これどこかの誰かと自分を同じ立場に置いて見下すタイプのキチガイか。
謝罪要求とか久々に見た。

966 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
話をそらし始めたな。
じゃあ強制的に戻そう。

お前言ったよね?コードが汚いって。
じゃあお前これよりきれいなコードかけるの?
自分ができないことを言うなよ。恥ずかしいやつだ。

967 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
最初に他人のコードをDisった奴は
他人からそれをDisり返されても泣き言言うなってことだな
自分の考えが正しいと思うなら論理的に反論すれば良いと思うよ
なんかモゴモゴ口ごもりながら必死で論点ずらそうとしてる奴らは
関係者かなんかなの?

968 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
> 自分の考えが正しいと思うなら論理的に反論すれば良いと思うよ

まったくだ。

ブログの内容を論理的に指摘した人に
早く汚いといった根拠を示せよ。

969 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>966
なんでそうなるんだ?
極力変数宣言端折ってたりする技巧的で複雑なコードなんだから、
読み手からすりゃ汚くて当然だって言ってるだけなんだけど、理解できない?

970 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
「複雑」と「汚い」は意味が違う
複雑は単に複雑なだけ。複雑な書き方が最善な場合もある。
汚いというのは、それよりも綺麗なコードがあるということ

だが、綺麗なコードは示せていない(笑)

971 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>970
はいはい一番汚ないところだけな。
http://ideone.com/xQChL3

972 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
たしかにこういう三項演算子のネストはやめたほうがいい
あと走らないコードの run code

973 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>971
本当かどうかは知らないが、jQueryがこれでJavaScriptを圧縮してるらしい。

【jQueryコード】76バイト
return chainable?elems:bulk?fn.call(elems):length?fn(elems[0],key):emptyGet;

【お前のコード】129バイト
if(chainable){return elems}else if(bulk){return fn.call(elems)}else if(elem.length){return fn(elems[0],key)}else{return emptyGet}


ここまで考えてなかっただろ?

これは設計方針であって、綺麗汚いとは別の話。

974 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>971は汚いな。

returnしてるんだから、elseいらんだろ。

こういうのを汚いという。

975 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
結局やったらやったでこれ。
ま、わかってたけどね。

976 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
そりゃそうだ。

汚いものを綺麗に直せという話なのに、
バイト数増やして劣化させてるじゃねーか。

977 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
汚いというかWEBベースのスクリプト言語の特性を理解してない感じがする

978 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>973
何使っったんだよ。

979 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>978
ワロタw

書き忘れた。

ついでだからググれwww

しかし、無駄なelseがある汚いコード出されても困るなぁw

980 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>979
jQueryが使ってる奴を使うとその手のif文消えるはずなんだけどなあ
一体何を使ったのか後学のために教えてくださいよ
ねえ

981 :367:2013/08/22(木) NY:AN:NY.AN
>>897
遅くなったがレスありがとう、>>887に挙げた条件をすべてクリアしていると思う
異論はある(>>896)けれど、これをもって「Pythonは式指向の壁を越えている」と判断したい
同様に、(if文を使わず)三項演算子を使った>>613から、「JavaScriptは...(以下略)」としたい

これらについては、>>707の次回更新時に反映させることを約束します


>>906
もともと関数型プログラミングという文脈下でのコード合戦なので、
(for文を使う>>906よりも)関数reduceを使った>>897のほうが望ましいと思われ

982 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
ちなみにjQueryで本当に使われてるはずの物でコンパイルするとこうなる
http://ideone.com/Zqswpw

で、jQueryで使われてるプログラムってなんなんですか?

983 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
PHPだけだろ?
三項演算子がバグってるのは

984 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
JS厨敗走しちゃった?
変な知ったかしなけりゃよかったねw

985 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
こんな簡単な関数にすらドキュメント云々とか言い出すなんて
マジで頭大丈夫か?
プライベート関数にAPI並みのドキュメントを期待する方がどうかしてる

986 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
最悪でもすんなり理解させる程度にはコメント書くだろ。
お前の頭が大丈夫か?

987 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
バカスレw

988 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>986
具体的にどこの処理の意味が分からなかったのか行数で「ここからわからなかった」と明示してくれ

989 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
まだやるのかよ?w

990 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>989
具体的にどこの処理の意味が難しかったのか行数で「ここからわからなかった」と明示してくれ
本当に難しいコードだったのなら簡単に指摘できるだろ?

さぁ。どこが難しかったのか教えてくれよ

991 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>990
bulkの意味答えてみ
あ、あとついでにjQueryで使われてるコード圧縮プログラムもお願いしますね

992 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
いい忘れてたけど圧縮オプション間違えたとか苦しい言い訳辞めてね
jQueryに精通してると主張してる奴がMinifiedコードを見間違えるわけ無いからね
見たこと無いなんてもっとあり得ないし

詭弁のためにわざと低圧縮にしましたと認めるなら許す

993 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
       -‐''''"´ ̄``ヽ、              ____
       /     _     ヽ        //´   __,,>、
     /        ̄ ̄   {        /::/ / ̄:::::::::::::::\
      l _ィニニア二二二ニヽ、j._      /::::l/::::::::::::::::::::::::::::::::l
     | 0Lj/-‐-レノ ノ_ヽ:::`ヽ     l:::::::::::/l/lノノ/_イ:::::l
     レ:r、/ イ゚テ   ピト`|::|      l:::::::::/ rtテ、  .ィtq l::::::|
      l:lヘ  '"   ,j  '"/ノ      |::lヘ!j  ´  ,j   !;:::/
     ヽヽ、   r‐-,   /'         レリー 、    ,....,  lノ/
        lヽ、  ̄ /         `ヽ、lヽ 、  ̄ /´
     _,r┴‐-`v´-‐j-、__   , -‐-、_r┴─'ー‐チト       バルク!!
  / ̄/:.:.:.:| ̄ ̄`T ̄´|:.:.:.:l´ `ヽ /    ヽ ̄`ー-‐'´`''''⌒ヽ
/   ,':.:.:.:.:.l    l   l:.:.:.l    \  _r‐、-、-、r,    、   ',
     |:.:.:.:.:.:.!     !   !:.:.l   ,. -‐ゝ/// 〉 〉 〉 〉 〉    !   ',
    l:.:.:.:.:.:.l     |   l:.:.:l  /  人〈〈〈〈 ' ' ' /っ   l    l
    l:.:.:.:.:.:.!     !   l:.:.:.ト/   /  ```´-ァ‐'''"     /   l
、__/:.:.:.:.:.:l     |    |:.:.:ヽヘ  l    //         / _ ィノ
    /:.:.:.:.:.:.:!    l   |:.:.:.:.:l `ーヽ、_ノ´l、______/lニ二」
____l:.:.:.:.:.:.:.|      l   |:.:.:.:.:!        |_  ( ( ) )_〕|   l
   l`ー‐‐'匸二l ̄ ̄l二フーイ       /   ̄ `‐‐'´ ヽ  |

994 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>992

http://ideone.com/xQChL3

そもそもこれがバグっていただけ。

995 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>991
コードに書いてあるコメント

Bulk operations run against the entire set

↓Google翻訳

一括操作は、セット全体に対して実行


bulkの意味ですか? 一括操作の一括なのでは?

996 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
それはバッチじゃね?
バルクってバラ積みだろ

997 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>995
その変数が格納しているものと名前の関係を教えてくださいな
特に別の型の変数を代入して使いまわしている事について

俺はそういう事するのは汚いコードだと思うんだけど
いくら言っても汚くない綺麗だって言うからさ

998 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
大量

in bulk
(1)ばら荷で,包装しないで.
(2)大口で,大量に:

999 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
>>994
http://ideone.com/Zqswpw
で、jQueryで使われてる圧縮プログラムってなんなんですか?
早く答えてくださいよw知ったかぶりなんですかあー?

1000 :デフォルトの名無しさん:2013/08/22(木) NY:AN:NY.AN
具体的に指摘しても結局答えられないんですねw
ええわかってましたけどw

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

291 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)