【PHP,Python】ｽｸﾘﾌﾟﾄ,ﾊﾞﾄﾙﾛﾜｲﾔﾙ36【Perl,Ruby】

構文エラーに悩まされてる程度だから
一行書いて、実行（正確には構文ミスしてないか調べる）が
必要なんだろうね。

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

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

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

REPLは初めて使うような関数の動作を見るとか、
簡易なサンプルを書くときに使うもんだろ。

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

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

途中で止まって再開ができるのは構文エラーぐらいだしな。
構文エラーで悩まされる確率が高い時点で初心者だろうな。

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

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

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

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

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

スクリプト言語スレに定期的に現れるスクリプトの存在自体のdis
あんたが大将。スクリプト言語は糞だ。だから出ていってくれないかな
なんだこのスレは？この>>1は？キチガイ荒らしは常に頭が逝ってる

LLスレ時代から何度キチガイ荒らしにスレを潰されただろう。乱立されただろう
プログラミングのプの字も知らないカスに

>>1
てめぇふざけんなよ
スレ建てたことないのかよ？

>>1の時点で仕事を果たさない。感情的になって自分こそが正しいと発狂してるだけ
他人から見たら何を言ってるのか一切理解不能
削除依頼出してこいよ。ま、いつもの乱立連投キチガイ荒しのように立てっぱなしだろうがな

>>4
じゃあ、使ってる言語とREPL。
そして複数のファイルにわかれて複数の関数とクラスを
使ってるレベルのプログラムをREPLで効率的に
開発できる例を見せてくれよ。

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

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

>>9
じゃあ、じゃなくて削除依頼出しこいよキチガイ

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

>>11
REPLで試行錯誤して開発するらしいよ。

使い方間違ってるよね。

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


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

夏休み終了まで、あとたったの40日だから我慢しろお前ら

>>12
その実験環境があるからこそ、試行錯誤的な開発が容易になるんだろ
なんで片一方しか使わない前提で「リカバリどうすんの？」とか言ってんの？池沼か？
削除依頼出してこいクズ

>>14
試行錯誤的な開発は、
REPLでやるものではないという話し。

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

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

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

お前の言葉の定義とか誰も知らない
試行錯誤することを試行錯誤と呼ぶし、それはREPLで効率的に出来る
削除依頼出してこいよクズ

>>14
> 前提で「リカバリどうすんの？」とか言ってんの

しょうがないだろ。

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

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

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

>>16
だったらお前の定義の試行錯誤を書くべきだろ。

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

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


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

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

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

REPLは試行錯誤じゃないという日本語的にも間違ったオレオレ定義のもとで勝手に糞スレ立てないで欲しいんだよね
さっさと削除依頼出してこいクズ

いまどきREPLなんて無いのJavaくらいなのに
何で使った事無いレベルで無知なんだろう
あ…（察し）

静的言語のREPL使ったことないやつｷﾀ━(ﾟ∀ﾟ)━!
REPL向きの言語というものがあるということがなんで理解できないんだろう
あ、察し！

REPLは往々にして短いコードを実験するから
簡単な処理ならコードを圧縮できる関数型言語は静的言語でもREPLは使える
C#とかC/C++のREPLを常用してる奴なんていないだろうな

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

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

関数の使い方はExcelで決まっているもの
関数の中身はコード書く前から一から十までExcel上で決まりきっているもの
これがドカタですよ

>>1
優秀な1だな
どうすればスレが盛り上がるか心得ているな

キチガイの振りしてるつもりなんだろうけど、正真正銘、ただのキチガイなんだよね

>>17
TDD知らないの？

いやTDDならむしろ>>17の言ってることが正しいと思うが

実行中に止めてコード書き直すのとTDDがどうつながるのか

副作用のある関数ばっか作ってる馬鹿には無理

んなことオブジェクト指向スクリプトのスレで言われても

>>32
ここってオブジェクト指向のスクリプトのスレだったのか。
まあshやsed、awkの話題をここでするのは違うか。

>>31
副作用がなんの関係があんの？

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

構文エラーで止めるってそもそもなんなん

[].each do |x|
が
[]...eachd o|x|

とかなってたら、コンパイル（ｽｸﾘﾌﾟﾄの）時にエラー出るから最初の一行目から実行されない

>>35
驚愕的なのは、スクリプトでコンパイルってなんだよ？
コードのパースは実行に含まれるって言ってる奴がいるってこと。

>>34
> 副作用がなんの関係があんの？


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

>>37
話わかってないんじゃね？

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

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

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

いや普通にテストもしますが？
インタープリタでの実験による試行錯誤を使った開発が
いちいちコンパイル実行を繰り返すより楽という至極当然の事実を述べてるだけ
何が最初から最後までテストだよｗアホすぎる
削除依頼出してこいクズ

一気にテストというのは、静的言語ではそうせざるを得ないというだけ
REPLはもうひとつ前の段階として使える

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

こんな糞みたいな>>1はこの板でも唯一無二、この馬鹿だけｗ
どう自己評価してるんだろう。死にたくならないのだろうか

どうすんのこのクソスレ？

>>38
まず日本語を喋ってくれ、構文エラーで〜構文エラーはともかく〜（どっちだよ）
テストを再実行しろ〜（は？何が再なんだ？）
自分が勝手に想定してるこっちに全く見えない前提が多すぎて意味不明
削除依頼出してこい

削除依頼を出せと言ってる人へ。

俺は出しません。
以上

>>38
まったく支離滅裂で何を言ってるのか意味不明なんだが、
何をリカバリしろって言ってるんだ？
お前自分で何書いてるか意味分かってないだろ。

>>45
何をリカバリするかわかんないの？

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

「間違ってコードを実行」って何ｗ

>>1
間違った開発をしてる仮想敵を作ってオラオラ俺のやり方が正しいぞ！と言われてもね
まずお前のやり方って何なのかさっぱり分からんし
仮想敵はお前の都合のいいように間違ってくれてるだけのオナニーショーだし
ちゃんと指摘されたことは受け入れろよ
なんで最初に言った妄想を延々と繰り返し続けるんだ？
完全に会話が噛み合ってないわ
削除依頼出してこいクズ

REPLでの開発が効率的だってさ、
書いてエラーで止まるから
また続きを書けばいいとのこと

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

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

REPLとは全く無関係な問題でREPLを叩いてて頭大丈夫かと本気で心配になる
さっさと削除依頼出してこい池沼

都合のいいところで止まるも何も、評価するたびに表示して止まるんだが
REPL使った事無い上に、REPLが何の略かすら分かってないのか

Ruby Enter Prise Language（松江）

REPLで開発してる奴なんていないだろ

ム板にIDはいらないかもしれないけど
末尾！つけてもらったほうがよくね？

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

末尾! は既に付いている
そこから分かることは海外産は皆無に等しいという事実

Perlは最早Pythonの劣化

Windowsも標準で、もうちょいスクリプト言語いれてくれないかな？
初っぱなから、ある程度使えるlinux、mac とでのマルチプラットホームなやつ
その方向には向かってなさそうだけどね。

Windowsはプログラミングしない人のためのOSだから

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

pyenvじゃ駄目なのか？

>>57
今時、クライアントはLinuxもMacもその方向には向かってないだろ
マルチプラットフォームはブラウザでやれという流れ

ブラウザも種類とバージョンが色々あってウゼーけどな

>>61
なに言ってるの？
Macは開発マシンとして有望だし。

Macなら開発マシンといってもWebかスマホだけどな
どっちにしろ開発者しか使わないので、別途インストールで構わない

Macって標準のRubyが1.86とかだから、本気で開発するなら自分でインストールしないといけないけどなｗ

Macports vs Homebrew vs Fink
の地味な戦い

>>65
Linuxもそうですが。

古っ

コマンドライン一発でインストールできるのに
それすら大変というWindows厨

WindowsはインストーラでインストールするかZIPを展開してパス等を設定するかなどが必要。
32bit/64bit版の選択が必要で、ものによってはVCでビルドしたものとmingwでビルドしたものとかが
存在してわかりづらい。

まあ素人は単独でPHPなんかインストールはしないだろうが、PHPのWindowsバイナリはこんな具合。
http://windows.php.net/download/
いろいろ注意書きを読む必要あり。
yum install phpでインストールできるLinuxとは大違い。

>>57
そこはマルチは無しで、HSPでも入れときゃ良いと思うが
スクリプト言語きっかけにして他のOSに興味でも持たれたらイカンから、windows命のHSPが良い

いまどきドザ厨とか全く面白くないから

WindowsさんにはPowerShellがあるじゃないですか
ShellとPerlとTclを煮つめた感じの…

Rubyの公式サイトは英語版の方がシンプル
WindowsならRubyInstallerをインストールするのがいいでしょう
としか書いてない
VC版とかCygwin版とか、余計なこと書いてないので迷わない

57だが

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

Pythonで作ったところでOSに元々入ってるPythonは当てにならんし
GUIアプリとかだとどうせ色々必要なライブラリを追加しなきゃいけないから
結局のところLinuxやMacでもPythonランタイム丸ごとアプリに同梱することになるんだよね

ならねーよ馬鹿
pypiくらい調べてきてから書け

（赤面）

DropboxとかPython同梱してるよ
Blenderとかもそうだね
Pythonがアプリへの組み込みに適してるのは大きな売りの一つなのに
何を必死に否定する必要があるのか
クライアントに配るなら組み込んだほうが確実だろ

ポータビリティのためにPythonで作って
実行にシステムのPython使ったら台無しだ

それはPythonで作ったからじゃなくて
アプリがPythonを使うからだろｗ

私がPythonを使うのではありません
Pythonが私を使わせるのです

>>81
プラットフォーム依存部分は言語処理系が差異を吸収するのだから、
コード(スクリプト)のポータビリティは保証されるだろ

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

>>82
DropboxはPython製

>>84
同梱したほうがいいという意味で言ったつもりだった

しばらくして彼女から一枚の小包が送られてきた。

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

まあ、Dropboxに同梱されたPython処理系のサイズって高々数10kb程度だし、
同梱しても問題無いサイズではある

>>86
読み直したらその通りで、自分の早とちりだった
ゴメン

>>88
もう、処理系は全部アプリに内蔵すればいいんだよ。

Linuxとか。

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

パッケージ管理システムで管理された
大量のPython製ソフト（当然、処理系は同梱されない）があるのに、
ほんの極一部の例だけで結論を出されてもなぁ……

処理系同梱厨にコード書かせたら
同じ処理でも関数でまとめずに
コピペしまくるんだろうなぁ

一般ユーザーにPyPiとか本気で言ってるの？
だいたいそんなもの使いこなせるユーザーが対象なら元から入ってるPythonなんてそれこそどーでもいいだろ

一般ユーザを馬鹿にしすぎ
皆お前みたいなアホじゃないんだよコピペ厨

一般ユーザーに夢見すぎ
奴らは黒背景にプロンプトの画面見たら恐怖を感じるのに

それ以前に、英語がちょっとでも出てきたらアウトな人が多い。

だったらMind使えばいいじゃない

てｓｔ

Javaと連携できるイケてるスクリプト言語が欲しい

groovy

JavaはAPIがイケてないからなあ
正直、Java系スクリプトやScalaで簡潔に書けてるように感じるのは八割くらい
例外処理が強制されないからだと思う

groovyはイケてるの？

>>22
何それhaskell,ch, cint, pike?

あんまし書き込みなくなってきたね。
動的言語が終わったのか
プログラミング言語自体が安定期に入ったのか
２ｃｈから人いなくなったのか

> 動的言語が終わったのか
ここはスクリプト言語についての話であり、動的静的は関係ないからだろう
動的なコンパイル言語もあれば静的なスクリプト言語もあるし

ふつうに4行目だと思う
一部言語のスレに他言語の原理主義者を装った荒らしが棲みついたせいで
どの言語のユーザも不幸になってる気がする

皆が時間の無駄だと悟って英文のmanual読んでるよ
それよか、RだよR。不毛な言語論争よか統計、機械学習の方が金になるって皆が悟ったんだよ。

本当に必要だったものはfunctional PHPのようなモノだったんだ。きっと.
馬鹿馬鹿しい。本当に馬鹿馬鹿しい。皆、ocaml,erlangあたりに行ったんじゃないの?
今さらベンチャーがPython、Railsってだけでも何か負け犬臭しかしないじゃんね

日本語がお上手ですね

ゼア イズ オンリー 負け犬 スメル

負け犬 イズ ルーザー オア アンダードッグ

RubyとJavascriptを仕事で書いていて「ここが美しくないなー」とかブツブツ不満言っていたけど
先日PHPのソースコード見たら、すげー汚いと感じた。

$var->member

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

どこが汚いのか不明

C言語はポインタと、そのデリファレンスをプログラマに明示的に扱わせるから、
単なるメンバ参照の "." と、それとは別に -> なんてのがあるわけだけど、
近代的な言語なら "." だけで良い（Javaとか）。

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

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

>>114
ひょっとして、-> がシンタックスシュガーって知らないとか？

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

シンタクティックシュガーな。
(*ptr).hoge って書けばいい、って話だろ、カッコが要るだけで。

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

syntactic sugar （シンタクティックシュガー、syntax sugar （シンタックスシュガー ）とも）の訳語で、

というより文字列結合なんかに.を割り当ててるせいじゃないの？

わりとどうでもいい

>>117
> そもそも*が後置なら

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

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

鏡

ポインタが後置ならって有名な話じゃん
エキスパートCプログラミングで出てくる話だっけ

>>121
* は単項演算子であるという知識があるから
前置/後置という>>117の発想ができるわけで、
知らなかった、あるいはつい最近知ったばかりだったのが
>>121であると読めてしかたがない....

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

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

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

>>121 は後置単項演算子を知らないのか？
とすると ++ や -- が演算子だということがわかってない？
++ や -- を前置だけで使っていた？

++や--を持ち出すまでもなく、
「　.　」や「[]」が後置の単項演算子だしな。

別に.でも->でもどっちでもいいよね
array()みたいに7文字もあると[]の方がいいなと思うけどね

if文でどこからどこまでがが条件式で、どこからが真のときに評価されるブロックなのかを示すキーワード({とか:とかthen)を
わざわざ書かなくていい言語はメジャーな中ではRubyしかない。

へぇ
　それはすごいね
end

へぇ
それはすごいね

半角スペース消えた…

>>126
ああ ++ と -- は忘れてたわ。
まあ、オペランド変更するやつまで演算子と言うのはどうかと思わないでもないが。

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

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

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

>>121が自爆だとしても、>>117も同レベルのアホ

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

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

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

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

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

-> はシンタックスシュガーなのだ！

（だからなんなんだろう？）

別になんでもないだろ、引きずってるのはお前だけだし

この手の議論は、わりとどうでもいいという言葉に尽きるなw
クロージャとかクラスとかジェネレーターとかの議論の方がはるかに有意義だったな

http://news.mynavi.jp/news/2013/08/09/019/index.html

ruby

おいruby10位ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>139
7月と何も変わってないけど。数字も読めないの？
http://news.mynavi.jp/news/2013/07/11/126/index.html

安定して低いって意味だろｗ

C、Java、C++、PHP、JSは悪い意味でこれからものこるだろうし
C#(VB)とPythonは総合的にRubyより上だし
Objective-Cは糞言語だけどiOS人気で残るし
Rubyの位置は別に驚きでもないわ。

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

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

>>142
> C、Java、C++、PHP、JSは悪い意味でこれからものこるだろうし
これらが残ることがどう悪い意味なのか説明してくれるか？

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

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

C#　Windowsとの親和性が高く業務に強い　最近ではゲーム開発で大流行
Python　極めて汎用性が高い素直な優等生

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

>>143
単純にC、Java、C++、PHP、JSついでにObjective-Cは言語として洗練されてないもしくは古過ぎる。
そんな言語でも分野によって必須だからこれからも残るんだけど、
コーダーとしてはそういう駄目な子で仕事するのはイライラするだけじゃね。

Cはあれでいいんだよ
低レベルな仕事をこなすという目的に対して極めて洗練されてる
他のは中途半端な失敗作だけど

> 単純にC、Java、C++、PHP、JSついでにObjective-Cは言語として洗練されてないもしくは古過ぎる。

言語マニアか・・・？

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

実用上の明確な目的がある言語は美しい
老害COBOLだって固定長レコードを扱うことに特化した非常によくできた言語だ
コーダーがウンコだけど

いらいらするのなら自分の力で、
ライブラリとか作ればいいと思うんだがねぇ。

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

>>147
自爆兄貴オッスオッス！

まーた意味のないくだらないレスをつけるｗ

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

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


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

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


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


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

サーバーサイドでも今はnode.jsが伸びてきてるが

PHPはWordpressしか使えないへっぽこWebデザイナーには必要不可欠

node.jsが伸びてる理由ってなんでなんだろう
jsのシングルスレッド云々とかが何かしら奇跡的にサーバーサイドと相性良かった
まさかな

言語がエレガントに書けるかどうかなんてどうでもよくて
何が出来るかとか、インフラとして利用価値が高いとかの方が
よっほど意味があると思うんだよな
そう言う意味ならC言語の代替は無いしJavaの代替も無い
JavaScriptの代替も無いし、
PHPと他のライト言語と出来ることの差も無い
言語仕様の些細な差にこだわる奴（自分で言語を設計してるわけでも無いくせに）
ってのは無能にしか見えないね

全然どうでも良くはない
実際jsにクロージャがなかったら今の栄光はない

うん、クロージャの存在は言語設計上の判断として大きいね
実際、「極めて汎用性が高い素直な優等生(>>144)」を自称するPyhtonにおいて、
最大の設計ミスの一つが「クロージャの欠落」だと思う

いや、pythonにクロージャはあるし、pythonが優秀な理由の一つだけど

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

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

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

その大きな負担となる機能とやらはたとえばなに？
nodeはモジュールを組み込んで使うプラットフォームであって、
現在では、たいていの機能はモジュールで提供されているけど？
sinatraライクなフルスタックのフレームワークもあるし

>>160
Twisted や EventMachine が前からやってた非同期プログラミングと
Node.js のそれとではモデルが違うのん？

まあPython2のクロージャは使い物にならなかった
nonlocalで手軽に変数に代入できる3はいいけど

手続き型言語に毒されたウンコには理解出来ないだろうけど、
再代入は本来避けるべきもの
外のスコープの変数なら尚の事

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

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

> node.jsより古参のはずだけどな
比べるなら言語で比べるべきではないの？

>>159
ええっ？Perl・Ruby・Javascriptにクロージャってないんだ！！

そもそもクロージャってそんな頻繁に使うか？

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

非同期処理で大量に使うよ
マルチスレッドじゃない方の非同期な
そんなもん使わないで>>165の言うように言語サポートによって同期っぽく書けるのが理想だけど

数年前華々しく登場したGoてどうなったの？
早くも消滅した？

Go、CoffeeScript、JSX当たりは死亡した。

GoとDartはマジでいらない
MSは言語のセンスあるからごり押しも許せるけどGoogleはどうしようもない

nodeの最大の欠点はコールバック地獄なんかではなく
javascriptの冗長な記述そのもの
alterjs使うと世界が変わる

センスは余りいらない。
実用的装備を整えるべき。
それが普及の大前提。
話はそれからだ。
Googleは実験的に初めて放置しやすい。

>>173
あれしこで冗長ってｗ
お前、そんなにたタイピング速度遅いの？

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

CoffeeScriptは死亡してないだろ
そもそもJavaScriptのシンタックスシュガーに過ぎないから学習コストも0で覚えるのは余裕だし
死なれても問題ないけどさ

CoffeeScriptってあんまりコード量へらないんだよな。
functionとreturnという単語の分は減るけど、
そんなの1関数に1回ぐらいしか使わない定義部分。

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

どう見ても冗長だ
無駄な記述やインデントをしないといけないから
修正も面倒になる
ああもしかして一つの関数に長文書いちゃうタイプか？

お前の言う無駄な記述やインデントは
全然大したことじゃないって話だよ。
単に打つ文字列の違いでしか無いだろ。

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

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")

記述量が減ればコードの見通しが良くなるし
処理を減らす余地も生まれやすいだろ
冗長であることを誇ってどうするんだこの馬鹿は

}); の嵐は Lisp のカッコ以上に凶悪

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

>>181
だから記述量と文字量の違いを区別しろよ。

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

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

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

> 記述量が減ればコードの見通しが良くなるし

これは間違い。

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

>>185
そんなくだらない事言ってないぞ？
冗長の意味履き違えるなよ

>>186
冗長の意味を履き違えてるのは
CoffeeScriptだろ。

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

function キーワードが -> に置き換えられるっていうのは
まさしく、文字を減らしただけだな。

>>184
余計な区切りや括弧やキーワードがあることで
全体の処理の流れが直観的に追えなくなる
記述量が減ることで近くのもの同士の関連がより読み解きやすくなる

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

functionを->にできるのが利点ってならES6普及後はcoffeescriptの利点はなくなることになる。

なんか冗長という言葉を間違って使っている人が
いるんじゃないかなって気づいたかもしれない。

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

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

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

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

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

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

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

>>189
重要な区切りや括弧やキーワードがないことで
全体の処理の流れが直観的に追えなくなる

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

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

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

>>188
>function キーワードが -> に置き換えられるっていうのは
>まさしく、文字を減らしただけだな。
後者が削ってるのは文字だけじゃないよ
そのまま返すって機能がついてるし

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

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

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

>>192
それはその通りだしCのような記述が嫌いなわけではない
ただjavaScriptの用途では匿名関数をその場で作る事が多いのに
処理と関係のない修飾が過剰になって読みにくくなっている
ocamlのlet-inのようなの

>>191
それは確かに処理そのものが冗長でわかりやすいな

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

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

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

一部の動的型付け言語って、IDE使う習慣がないからって
今更冗長な型づけ宣言を導入しようとしているのが笑える。

Object obj = new Object()

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

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

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

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

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

>>199
>しかし、状態を保持しない設計を強制するのは、
>生成・破壊(コピー)コストを考えると、現実的ではない。

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

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

で、結局話に戻るが、スコープの外側の変数を変更するのは普通に有用

スコープの外側の変数を変更はあまりしてほしくない。

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

つまり Pascal サイコーってこと？

>>203
>スコープの外側の変数を変更はあまりしてほしくない。

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

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

あらいぐまPascal

要は一定の処理を別にふって、その振り先に引数渡したり戻り値受け取りたいだけだろ。
そんなことは当たり前にできるべきだし
クロージャーみたいな名前で呼ばれてること自体がおかしいんだよ。

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

例えばこういうクラスがあったとする

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

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

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

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

>>207
>要は一定の処理を別にふって、その振り先に引数渡したり戻り値受け取りたいだけだろ

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

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

でもbar()はクラスAのどこからでも見えるスコープになってしまっている。
bar()はfoo()でしか使わないのだから、こう書いたほうがいいと思うんだ。

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

　　　function bar() {
　　　　　：
　　　}
　}
}

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

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

そもそも>>208-209の例はおかしい。

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

>>208
え
もしかして全ての手続きをmain()の中に（関数内関数等を使って）記述しろといいたい？

つまり Pascal サイコー ですね

>>213
いいえ？

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

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

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

>>210
同じ事だよ。
一般的にクロージャとかわざわざ呼んでる言語がクロージャでしたいことは、処理を投げて
その処理にローカル変数を参照させたいとか戻り値を受け取りたいってだけじゃん。

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

>>198
どの言語が静的型付をいれようとしてるの？

>>216
クロージャーという用語が出来たのは
Javaができるよりも前だよ。

やっぱり >>215 は Pascal サイコー な人だったのですねw

class A {
　function foo()
　{
　　new class B().do();　
　}

　class B {

　function do() {
　　　longMethod();
　{

　function longMethod() {
　}

}



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


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

>>216
え、では(>>210で述べた)C言語で関数ポインタを使うコード設計のことも
(>>216は)クロージャだと見なすのか.....

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

※注意

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

は意味が違います。


はい、続きをどうぞ。

>>220
インデントも括弧の対応も取れてないコードを書かれてもね（苦笑）

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

>>223
普段C#で書いてるからな。

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

>>220
Smalltalkは、そのどちらもできないけど、
Smalltalkがオブジェクト指向言語ではないと言う人は初めてだぜ！！

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

C＃で書いてるのと、自分がミスしたことと
何が関係あるんだろう？

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

>>216
クロージャがない言語（たとえばC）では、関数から抜けたら
ローカル変数の寿命は終わりでいいし、だから効率上スタックを使って
実装されることが多い

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

>>225
Pythonですらカプセル化ができないから完全なオブジェクト指向型言語じゃない。
そういう厳密な定義では、Smalltalkは関数は全てpublicだから不完全。

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

>>224
その意味はオブジェクト指向ではなくて、名前空間ではないのかな？

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

>>220
やっぱり気づいていないんだ？ { がひとつ足りないことにｗ

オブジェクト指向言いたいだけなんだろうなｗ

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

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

>>228
まず最初に「完全なオブジェクト指向型言語」とやらの厳密な定義を示してくれないと
議論にならないよ

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

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

今の主要なオブジェクト指向言語はだいたい、フィールド変数という名の、
スコープ外変数をメソッドから変更しているが、それを全否定か？w

というか、オブジェクト指向という用語を考えて一番始めに使い始めたのって、
Smalltalkの作者だろw
後からストラウストラップのようなバカどもが間違った定義で話を進めたために、
本来の意味とは違う意味になってるようだがw

Smalltalkに向かってオブジェクト指向じゃないってのは、
本当にコントみたいな話だなw

>>232
C#では数値もオブジェクトだぞ

http://e-words.jp/w/E382AAE38396E382B8E382A7E382AFE38388E68C87E59091E8A880E8AA9E.html
オブジェクト指向という用語は1972年にSmalltalkが発表された際に考案されたが、
そのアイデアが初めて現れたのは1967年のSimula 67であるとされる。

http://d.hatena.ne.jp/sumim/20040525/p1

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

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

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

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

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

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

一番重要なのは、その用語を考案したのは誰で、最初にどういう定義をしたかということ
アイディアが現れたのはいつかというのは、ここでは全く重要ではない
言葉の定義の話なのだから
そして、すでに定義があるのに、あとから別人が別の定義で話をはじめたら
混乱が起こるに決まっている
それをやってしまったバカがストラウストラップ

>>236
C#でクラスはオブジェクトかな？
Smalltalkは純粋オブジェクト指向言語だからクラスもオブジェクトだけどね

>>239
たぶん、ストラウストラップ が違う名前をつけていたら、
世の中に普及していたのは、その違う名前のほうで、
オブジェクト指向はメッセージ指向と同じく
マイナーなものになっていただろうな。

インターフェース指向か型指向だろ

>>241
仮にそうなったとしても、少なくともその方がはるかに混乱は少なかっただろうな
まあ、そもそも上に出てきた真のオブジェクト指向とやらは、ストラウストラップの
言ってるオブジェクト指向とも違うようだが

>>241
たられば論だったらお子様にもできる。

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

>>244
ええとね。

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

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


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

たらればではなく、
今普及している概念の話をしている。

ストラウストラップの言ってるカプセル化って、フィールド変数を
パブリックメソッド使って変更するやつのことだしな
つまり、メソッドのスコープ外変数をメソッドから変更するっていう
まさに上で完全否定された処理w
それが柱w

>>245
いや、これはオブジェクト指向と呼ぶんだ呼ばないんだという話をしているのだから、
概念をどういう名前で呼ぶのかという、まさに名前の定義の話だろ
そして、ストラウストラップの定義も、お前の完全なオブジェクト指向とは違うw

>>247
フィールド変数一つに対して
それを変更するだけのメソッドを一つ作ると
考えてるのはお前だけだと思う。

わかってないなぁ。

>>249
誰も変更するだけだとは言ってないし、一つだとも言ってないが？
しかも、スコープ外変数への再代入の話なんだから、
回数やら他の処理やらは議論と何の関係もないが？

>>248
別の名前にするべきといったのはお前じゃん？
同じ名前にするのが悪いんでしょ？

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

>>251
してもいいけど、で？

>>250
そうか？
なら疑問が出るんだが？

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

>>252
別の名前にしたらはっきりする。
ストラウストラップの方の
○○指向が普及しており、
オブジェクト指向は普及していない。

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

>>254
で？
Smalltalkをオブジェクト指向じゃないといった赤っ恥を取り繕ったつもり？w

オブジェクト指向という大分類の中に
・メッセージ指向
・クラス指向
の二つがあるというだけの話だろ。
どっちが完全だの起源だのそんな話はどうでもいい。

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

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

>>255
それ俺じゃないｗ

やはりム板にID制の導入は必要ではなかろうか

ID無いのに決めつける奴が馬鹿なだけ。
決めつけたセリフを言わなければいい。

ぶっちゃけIDある方が騙されやすいんだけどねｗ
だって俺、スマホ以外にプロバイダ2契約してるもの
（バックアップと負荷分散を兼ねて）

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

>>260
プロバイダなんて月々1000円程度しかかからんから複数契約は珍しくない
俺も複数契約してるがバックアップやら負荷分散なんて大仰な目的じゃなくて、
くだらない目的で使ってるだけだがな。

珍しい珍しくないの話じゃなくて
ID制が意味ないって話だろ
頭にウジでも沸いてんのか？

>>262
プロバイダ2つごときで「バックアップと負荷分散♪」なんてドヤ顔してる子を温かい目で見守ってやれるほど大人じゃないんでねｗ

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

>>264
> Smalltalkは別にマイナーではなく、超有名言語
> C＋＋より影響力が大きいかもしれない

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

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

お前のようなくだらない奴のために何で俺がその労力を使わなくちゃいけないんだよw
お前がやってるのはインターネットだろ？なぜ目の前の道具を使わない？w

つ　wikipedia

>>266
議論はハッタリやブラフを競うゲームじゃないんで。
存在しないソースを存在するように見せかけるお遊びはチラシの裏でどうぞ。

>>265,268
ソースが無ければ事実と認めないと言うのなら、

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

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

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 と同様な簡潔なオブジェクトモデルを採用している。

>>270
Smalltalkの影響欄にDartが入ってる理由を具体的に述べてくれますか？

たとえばDartの言語仕様のどの部分がSmalltalkに影響を受けてるのでしょうか？
あなたは「DartはSmalltalkに影響を受けている」と主張なさっているので、
当然その根拠を1つは答えられるはずですよね。

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

>>271
http://www.youtube.com/watch?v=huawCRlo9H4#t=1810s

ツンデレw

>>263
> プロバイダ2つごときで「バックアップと負荷分散♪」なんてドヤ顔してる子を温かい目で見守ってやれるほど大人じゃないんでねｗ

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

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

っていうか元々のレスは
バックアップと負荷分散自慢じゃないじゃねーかｗ

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

低級企業をわざわざゴミカス言語を使わざるを得ない状況に誘い込んでるだけ
言語の良しあし語る前にまずそこから

>>272
えるしってるか？
だーとのさくしゃはすもーるとーくぶいえむのこうそくかでちょうゆうめいなひと。

L知ってるか？

>>278
言語処理系の影響が言語仕様に限定されるという視野狭窄はさておき、
DartがSmalltalkの影響下にあるわけないという272の確信が
無知であること以外のどこから来たものかすごく興味がある
Dartの言語仕様を暗記するくらい読み込んだのかな……

へーSmalltalkって色々なところに影響及ぼしてるんだな。
sumimとかいう奴の解説間違ってるじゃねーかクソが

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

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

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

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

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

俺が悪いのか？

　　　　　　　|::::::|.::.::.::.::.::.:ﾄ､::.::.::.::.::.::.::.::.::.::.::.::.::.::.::ヽ:.::.::.::.::.::.::.::.::.::.::.::.::.',
　　　　　　　|::::::l!::.::.::.::l::.:| ';＼::.:ヽ.::.::.::.::.::.::.::.::.::.::.:..';.::.::.::.::.::.::.::.::.::.::.::.::.::
　　　　　　　|::::くヽ:.l::.::.::.:|,.. -ヾ´:.:.'､.::.::.::.:ヽ:.::.::.::.::.::.l'⌒ヽ:.::.::.::.::.::.::.::.::.::
　　　　　　　|::::::_l_`;:l:::::::l'~ｊ,二二...zヽ_::.::.::.::';::.::.::.::.::.|こ｀ﾍ::.::.::.::.::.::.::.::.::
　　　　　　　|:::::::ﾞLh!:'､::::l:',′_づﾂ火´::.::.::.::.:i:: :: ::::::lヽ r ﾉ::.::.::.::.::.::.::.::.:
　　　　　　　|:::::::::| /ヾ｀､:::`､　 :;　 ;　ヽ::::.::.:.::l::::.::.::::|/　/:::::.::.::.::.::.::.::.::.:.
　　　　　　　l:::::l::::!'　 ｀　ﾞ､:ヽ 　 ';.;　　ﾞ;'､::.::.::.|::.::.:::::|_,ィ:::::::::.::.::.::.::.::.::.::.:
　　　　　　　|!:::|l/　　　　　ヾ;　　 ;.　　 ; `;::.::::|:::::::l:ﾘ: .1::::::.::.::.::.::.::.::.l::.::.
　　　　 　 　 l:::| !｀ヽ｀　　 　 ｀　　';　　 :　l::.::::|:::::/ﾉ　 }::::::i::.::.::.::.::.::.l::.::.:
　　　　　　　　l|　!::ハ ｰ‐- ､_　　　;　ｊ　;　|::.!;:|::/　　 /::::::l::.::.::.::.::.:;'!::::::::
　　　　　　 　　!　l:!　`,　￣￣`　　;　　 ' イｿ ｊ〃　_,/::::::::l::::.::.::.::.:;':l::::::::
　　　　　　　　　　!　　ﾞ,　　　　　　!,.-''´ﾘ///ﾊﾞz'"/::::::::::l::::.::.::.::.::l::l::::::::
　　　　　　　　 　 　 　 l.　　 ,. -''V//////／　　/::::::::::/!:::: :: ::::/!::|::::::::
　　　　　　 　 　 　 　 　 ￣　　　 Y///／　　　/:::::::::/|::!::::.::.::::::! !::ﾄ､:::
　　　　　　　　　　　　　　　　　　　ﾚ:''´ _　-─/:::::::/´ !::!::::.::.:::::l　|::| ヽ
　　　　　　　　　　　　　　　　　／: ; . '´　　　/::.::./　　l::l!::::.::.:::::!　l::l

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

そりゃ、言語設計者からみたら、C++なぞ問題外(^_^;だし、
SmalltalkやLispやHaskell、Prologといった言語に見られるカリスマ性はないだろう
格が違う

>>284
うん。はずかしくて尻尾巻いて逃げてもいいレベル。

C++の深淵をどこまでも追い求めるバチスカーフのようなしぶとさは高評価に値すると思う

>>286
Simula
クラスやガベージコレクション、継承といった
オブジェクト指向言語の「機能」を最初に実装した言語

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

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

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

今のC++って記述はシンプルになってるけど、実際にどんな処理が入ってるのか理解するのが大変
あれ使いこなすのは相当頭良くないと無理じゃないの

C++のスクリプト化がPHPやJavascriptみたいもの。

C++は言語仕様は滅茶苦茶だけども「カプセル化、継承、多態性」という
現代のオブジェクト指向の最重要概念を一番最初に提唱したという功績がある

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

>>289
> Simula
> クラスやガベージコレクション、継承といった
> オブジェクト指向言語の「機能」を最初に実装した言語

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

カプセル化、継承、多態性という概念が本当に専門家の間で
評価されてると思ってるのか？
実際は、糞食らえと思われてるかもよ？
実際Smalltalkの影響より大きいのかと言われると怪しいわけだし

特に継承は悪者扱いされ始めて久しいな
必要ないとは言わないが、乱発はするなとか
最近では多態性も雲行きが怪しいな
javaのテンプレートが失敗だったと言われはじめたり

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

>>296
お前がいくらそう思っても世間はC++由来の「カプセル化、継承、多態性」一色に染まってるからな
ノイジーマイノリティにならないように気をつけな

>>286
まつもとw
懐かしいネタだなw
もう10年以上前になるのか
あの記事もう一度全文見たいな

>>297
お前のいう世間が狭いんじゃね？
かなり遅れてる

「カプセル化、継承、多態性」が含まれてない「オブジェクト指向言語」って例えば何がある？
まともに使われてるのはJavaScriptくらいだろ

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

ふーん。

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

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

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

>>301
ソースは？
韓国人がすべての起源主張してるようにしか見えないんだが
アジャイルがSmalltalkを参考にしてるなんて聞いたことねーよアホが

>>302
知ってるから無視してんだよボケが

> 古くは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なんて全く参考にしてねーよ

>>303
さすがにお前が無知なだけ
Smalltalkも本当は知らなかったんだろ？w

>>305
オブジェクト指向という言葉をSmalltalkを知りもせずに再定義したバカが
ストラウストラップだというのはマジな話しっぽいな
だが、STLのコレクションライブラリを作ったのはステファノフであって、
ストラウストラップではないぞ

>>306
アジャイルがSmalltalk由来って話はほとんど話題にはなってないだろ
少なくとも日本語のソースは見つからない

>>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の原型を形作っていったといいます。

>>309
どこからもリンクされてないページをさらっと出すとか
こんなの知らなくて当然だろ

じゃあとりあえず、「ケントベック」という人物について調べてみろ
彼がSmalltlakの文かとアジャイルの架け橋的な立場にいる一人だということが分かるから

>>305だってどこからもリンクされてないやん

C++なぞ問題外^^;;;
http://web.archive.org/web/20000302001334/http://www.ruby-lang.org/ja/compar.html

>>311
知りもせずってことはさすがにないと思うな。

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

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

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

おまえらプログラムの歴史にも詳しいのか

TDDもアジャイルもSmalltalkが起源ニダ

>>316
おまえらはあらゆることについて恐ろしく詳しいよ
同時にあらゆる事について恐ろしくおバカである

lisp、smalltalk、haskell、prologが4大カリスマ言語
というに前者二つはいろんなものの起源

>>314
ストラウストラップがオブジェクト指向という言葉の人気に便乗したとか
言っても理解できないだろうw
まさか自分の知らなかった言語があの誰もが知ってるc++よりも影響力があって、
そんなに、凄い言語だったなんてw

>>320
あんま他人を馬鹿にするなよ
あしもと掬われるぞ

>>319
あれ以上シンプルにならない Lisp と Prolog だけでいいな

昔は、凄腕のハッカーが好むのがLispで、
口だけ達者でヘボコードしか書けない連中が好むのがSmalltalkだった

Lisp、Smalltalkを好んだ凄腕のハッカーの
名前が知りたいんだが誰か知ってる？
ちゃんとその言語を好んでいたというソースがある人。

で、そのヘボコードしか書かないSmalltalk使いが
ヘボコードを肥だめに積み上げて作ったアジャイルの潮流を
クールな君らが這いつくばって学んでいるわけですね。わかります。

ヘボコードしか書かないSmalltalk使いには
何も生み出せんよ。
Smalltalkを使っていただけのユーザーなんだから。

>>319
４つの言語の中で、Haskellだけは変じゃね？

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

数学や物理は這いつくばってでも学ぶ価値があるが、
ぶっちゃけプログラミングの世界はアホ的思い付きが
大手を振ってるだけで、全然学ぶ価値無いよね
習得だって片手間で余裕だし

プログラミングの世界は習得が目的ではないので・・・。
的外れもいいとこだな。

>>328みたいな奴は
習得した言語自慢でもしてるんだろうか？

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


で、何を作ったの？

大して学ばなくても、出来る奴は最初から出来るし
カスは永遠にカスのまま底辺をさまよう
それがプログラミングの世界

それはプログラミング以外でも同じだと思うが？
勉強だけじゃなくてスポーツでも。

>>324
LISPは他に任せる。Smalltalkだけ。

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

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

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

プログラミングは底が浅い

>>327
Haskell入れるくらいなら史上最も稼いだ言語であるAPLを入れるな。

Haskellコンプレックス全開

なんつうか密度の問題だろうな

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

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

リアルに知ってるSmalltalkerがことごとく
気持ち悪いくらいSmalltalkに心酔してて
実際の言動もリアルに気持ち悪いので、
Smalltalkは特別な言語なんだと心から納得してる。

じゃあ、Lispで俺が知ってるやつな
ジェームス・ゴスリン
円周率計算の当時の世界記録をLispで達成した
またJavaの作者の一人

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

Lispだとガイ・スティールJrも有名人

ガイ・スティール
Schemeの設計
並行アルゴリズム（GCのスティールのアルゴリズム等）

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


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

Lisperには、JITのピーター・ドイチュとかもいれたいね

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

>>338
Smalltalkはある一線を超えると社会復帰が難しくなるからね
廃人直行言語、というかどちらかというと変態OSに近い環境か

>>343
嫉妬うざ

天才プログラマーなら現代の言語javascriptも負けてないよ
Paul Irish、Jeremy Ashkenash、Ryan Dahl
今はこうした若者の時代だよ

老人たちがSmalltalkでの知識と経験でJS爆速化技術を提供し、
若者たちがモダンなクライアントサイド技術を生み出す。
いい連携じゃん。

クライアントサイドって面倒だけど低能でもできる仕事だからね

二人目は言語の作者だし三人目はサーバーサイドだぞw

サーバーサイドってSQL組み立てて
データベースから値を出し入れするだけの
低能でも出来る仕事だからね。

SQLインジェクションを全く発生させずにアプリ作るなんて
低能でも出来る仕事だからね、

大事なのは、JSの爆速化なしには、
CoffeeScriptもnode.jsもないってこと。

爆速化したのは、ブラウザで動く言語がJSしかなかったことと、
ブラウザ競争の渦中で、巨大企業の資本力がこれでもかと
注入されたことが大きいな。ほかのLL言語では真似できないね。

>>350
まったくだ。SQLインジェクションを発生させたら
大問題であることを気づいていない。

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

>>352
LuaJITさんを忘れないであげてほしい

>>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

ほー

もー

やりませんか？

ウフォッ、いい言語

こっちの言語のほうがいい、いやこっちのほうが良い
って何のための議論なんだろうな･･･

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

短期的にはそれが正しいんだけど、
その果てにあるのは老害コボラーやJavaドカタだからねぇ

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

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

発明、発見は、歴史で一回しかない。最初は、ひとつ

言語だけを比較するならHaskellが最強

Haskell > Python > C >> Perl > OCaml > C++ > Ruby >> C# > Java > JS > PHP

このあたりが同じ
C言語の系統なのでいい。


C/C++ JS PHP　 Java　C#

総合評価は分からないけど、関数型プログラミング適性に限定すれば、以下が妥当では？
(すべての言語について精通している訳ではないので、間違いがあれば指摘ヨロ)

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ログチャンネル

F#って全然名前出ないけどずいぶん上に位置してるんだな。

>>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開発環境が
充実していることから、実用性/普及度という点で(個人的には)大いに注目しています

関数型でないのが登録されてるが?

素晴らしい表だ

間違いなくRuby厨

>>370
比較の観点が「関数型言語」ではなく、
「関数型プログラミングの適性」ですので....
XXX型プログラミングはスタイルなので、
関数型プログラミングは非関数型言語でも適用できます

constexprやTMPは駄目ですかそうですか。

Haskellも変数ないけど、変数の壁ってどういうの？
Monadとかも一切使えないってこと？

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

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

>>367
関数がファーストクラスかってのが一番重要な最初の壁だと思うのだが……
その観点だと、OO言語の場合、メソッドがファーストクラスオブジェクトかという
視点は外せないのでは

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

あと、>>367に挙がっていないけど、式志向かどうかってのも
篩として分かりやすい気がするな

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

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

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

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

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

>>381の最終行を訂正

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

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

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

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

>>378
関数やアトムと値を別物だと思ってる時点で
何も分かってない半可通だと分かる

>>378
>値が束縛された名前は変数と呼ばれ
たしかに名前束縛がないならFPのが確かに純粋度？が高いように見えるね
ただ一言言うと、それは名前で束縛された代数的な数ではあるけど変数ではないよ
知ってるならなおさら間違えちゃ駄目でしょ

>>381
その辺の取捨選択や順序づけにやや恣意性を感じると言うか……
カリー化されていることが重要だと思うんなら入れればいいし

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

Rubyを上に持ってきたいんじゃないの？

>>385
言いたい事は分かるのだけれど、「値が束縛された名前」について
「変数」という単語よりも適切な概念の名称について、提案を願う

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

そんなもん、Alias（別名）でいいやん

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

367は、変数束縛をなるべく使わないPointfreeスタイルで書くのが
関数型プログラミングって言いたいワケか？

ラベルっていうのもありかもな。

Java8のSAMタイプの構文糖をクロージャだと思ってる時点で
色んな意味で無知すぎる

>>392
どっちかっていうと言葉尻を捉えて必死になってるお前の方が無知に見えるよ

>>386
>その辺の取捨選択や順序づけにやや恣意性を感じると言うか……

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

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

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

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

> ただし、この恣意性があるから各自の哲学/思想というか立ち位置の差異がかいま見えて、
> 議論(バトル)として楽しめるのではないかと思う

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

変数束縛なんていうから難しくなるけど
要するに、証明の問題とかである

○○をXとおくと〜

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

恣意的な上に無知

お前が無知だろｗ　反論しないのがその証拠

>>389,391
エイリアス(別名)について：
　別名は実名の対比語だと思うけど、そもそも値には名前が無い訳から違和感を感じる

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

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

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

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

「値が束縛された名前」なんて素っ頓狂なこと書いて
自分で疑問にも思わない時点でアホすぎる

>>390
Haskellであれば、Pointfreeスタイルで書くのが関数型プログラミングらしいと思うよ

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

あー、RubyユーザはPointfreeスタイル好きそうだね
なるほどなー

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

>>396
そのとおりだね

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

>>402
どちらかというと、HaskellのPointfreeスタイルよりも、
F#のパイプライン演算子のほうが
Rubyのメソッドチェーンの発想に近いと思う

f x y = 2 * (x + y)

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


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

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

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

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

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

とりあえず、ここまでの指摘について>>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

式指向(条件判定式)の壁って何？

再利用可能な部品に分ける事とPointfreeは全く何の関係もねーよ
ほんと半可通だな

>>410

>>383を参照

>>408
無知は黙っとけよ。
お前のレスが一番中身なくて邪魔。

everything is an object / object oriented の対比として
everything is an expression / expression oriented という言葉がある
Lisp族をはじめとする関数型言語は普通はそうなってる

C++にもJavaにも三項演算子あるじゃん
まさか、三項演算子は読み書きしにくいなんて恣意的な理由？

Python は sortedlist = lst.sort() とかする初心者が後を絶たないから教育言語失格

こんな挙動を示すRubyが式指向とか、無いわー

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

返り値が必要な場合にまで for 使う人はいないんよ

>>417
すげえ直観に反する動作だな
CLのLOOPマクロみたいなリスト内包もどきでもないし
最後に評価した値でもない
何でそうなるんだ？

式指向にわざわざ(条件判定式)って付けてたのは
Rubyが条件式以外はキモい挙動だからか

関数型が優れてるという前提なのか?
関数型はあまり使われてないし、基本文法よりも
有名な、追加のライブラリ次第でシェアや使いやすさは変わるが。

>>419
Rubyの for x in xs; ... end は xs.each{ |x| ... }、つまりメッセージ指向的に言うと
xs への each{ |x| ... } というメッセージ送信のシンタックスシュガーなので
eachというメソッドがレシーバを返す仕様がゆえに for でも xs が返るという流れ。

eachじゃなくてinjectのシンタックスシュガーであるべきだったね > Rubyのfor

>>422
なるほどメソッドチェーン用にselfを返すようになってるメソッドを
そのままforに転用してるからか
説明されれば理屈としては分かるが、for式の値として見ると気持ち悪いな

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

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

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* はあまりおすすめしないと書いてあったのですがその理由がわかる人がいたら
ご教授願います

>>426
マルチ乙

型推論もLispマクロも無いのに
関数型に近づけてもメリット無いよね

つまり、Rubyはウンコ

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

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

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

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

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

>>417-424
反復(for や while の構文)での返り値が不可解であることは、同意する

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

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

>>429
そんなスタイル見たことない

>>431
実装に依存する部分は言語仕様じゃないんじゃないの？

三項演算子を使うやつはバカ

>>434
同意

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

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

>>434,435
なんで？

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

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

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

そもそも不可解ってほどでもないなあ
nil を返されるとそれ以上何もできない
だったら有用性の面から self 返しとくってのは合理的ではないかと

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

>>439
たぶんLispのdolistみたいなものを想定してるんじゃないのかな
アキュミュレータを使わなければただのforeach的なループと同等で、
アキュミュレータを使えばinjectっぽいことができる
dolist式の値はアキュミュレータの最後の値だからコピーのコストは気にする必要はない
foreachっぽいことをやるだけならnilになる

チェインでパイプしてくのが関数的なら
今のjavascriptも変わらんだろ

>>440
ごめんコピーじゃないね
（アキュムレータに）溜めこむ過程のコストって言えばよかった

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

>>429
Rubyにif式と三項演算子の両方があるとか、無いとか、そんな話は全然関係無くて
条件分岐を式で書けるか否か、という話だろ

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

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

あと、Common Lispは末尾再帰最適化する処理系が多いのに、
デフォルトで末尾再帰最適化がオフのCRubyより下に居るのも変だと思うよ

三項演算子で人をバカかどうか判定しているやつはバカ

ただのRuby厨なんだからそっとしといてやれ

パターンマッチの壁が無いあたりが
Ruby厨の限界を表している

>>443
>Rubyにif式と三項演算子の両方があるとか、無いとか、そんな話は全然関係無くて
>条件分岐を式で書けるか否か、という話だろ

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

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

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

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

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

関数型ワナビーのル厨か。
気持ち悪いの二乗だよ。
こりゃまためんどくさいのが居着いたな。

>>444
仕様として明記されているSchemeと区別する意味で未実装と判定したのだけど、
Common Lispの実用的な処理系の大半で、末尾再帰最適化は実装されているのかな？

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

つまり、C++やJavaにif-elseがなければ式指向ということだな?
関数型らしからぬ機能があるのがダメだということはRubyは相当下になるのでは?

> 仕様として明記されているSchemeと区別する意味で未実装と判定したのだけど、

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

>>447
それは思った。名前束縛の件もそう。
やっぱり言う割にまともに関数型言語使ってないんだな。

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

お前、erlangファンを舐めてるのか？あん？

そんなこと言ったら壁0や壁1も一つの言語しか区別してないだろ

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

>>453
しょせんワナビー

AgdaやCoqも加えてあげてください

SBCLは末尾再帰最適化されているな
clispはコンパイルすれば最適化される

>>451
>つまり、C++やJavaにif-elseがなければ式指向ということだな?

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

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


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

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

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

>>360
>if-elseの無いC++やJavaに、プログラミング言語として何の意味があるの？
>無意味な仮定を持ち出して決めつけを行うのは「詭弁(きべん)」だよ
別人だけど俗に言うc-likeなら3項演算子があるだろう

Rubyは適当にパーサ作ったら偶々いろんなものが値を返すようになっただけで、
関数型うんぬんなんて高尚(?)なもんじゃない


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

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

>>461
367は三項演算子で条件分岐できるのが分かってない予感

複数ステートメントについてもC#などラムダのあるC系なら
a = cond1 ?
　　(() => { X; Y; })()
　: cond2 ?
　　(() => { Z; })()
　:
　　W;
と書けないことはないな

>>455,456
わかったw、Erlangファンの意志を尊重し、
>>409を次回更新する時に「パターンマッチの壁」を追加することを約束します

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

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

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

Pythonを下げてRubyを上に上げた意味が一番わからない
食わず嫌いじゃないのか？
それと関数型風に出来ればいいならC++98だってboost-phoenixみたいのもある
基準が変だよ

>>462
何でそうなるんだ？

459は何も450を肯定してねーだろ
しったかなやつだなーと

>>466
これの上の部分の詳細を書くとPython2.5で既にlambdaもif式もあった
それでRubyだけ何で特別扱いなんだ

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

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

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

本当に主観だけで決めてるな
ランク製作者の独断できまるランキングスレなんて初めて見た

>>470
で、Rubyにおいてif-elseの式の値を利用していることはどれくらいあるだろう?
それはC言語における ?: / if-else の割合と比較して有意に大きいと言えるの?

こんなに綺麗な論破初めて見たｗ

>>466
>Pythonを下げてRubyを上に上げた意味が一番わからない
>食わず嫌いじゃないのか？

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

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

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

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

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

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

>>474
>最初から言語仕様として規定されているC++11は上位になります
C++11はconstexprを含んでその位置なのか？
if-elseもないし定数への展開じゃなければ
コンパイラが末尾再帰最適化もしてくれるが

理解できた
パイプでつなぐようなスタイル(Haskellのポイントフリー)が
関数型スタイルだって言ってるのか
心の底からRuby厨だわな
根本的なところで違うんだからそりゃ話が咬み合わないわけだ

>>475
圧倒的に多いと言える根拠は?
三項演算子の一般的な利用頻度にかかわらずC系で三項演算子を使えば関数型っぽくはなるが、
そうではなくて>>470は一般論としてどっちが多いかの話じゃなかったの?

無駄だよ無駄
こいつただのRuby厨だから

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

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

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

つまるところ三項演算子をif-elseで書けるから見やすいと言ってるだけだろう。わかるよ。
でもコードの見やすさなんていう観点を持ち込むんなら
随分とランキングは変わってくると思うけどね。

もうわかっただろ
まともに使ってるのRubyだけなんだって

要するに、

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

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

次スレからRuby使いは排除だな

>>469
Python2.5にはクロージャが無かった(もしくは不完全であった)からだよ

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

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

JavaScriptは？ (・∀・)ﾆﾔﾆﾔ

なんでpythonでnonlocalクロージャができると関数型になるん？
逆じゃないの？

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

>>485
なんでnonlocalがあるとまともなんだ?
Rubyもそうだが、外の変数へ再代入できたらお前の思う関数型に近づくのか
と思ったら487が書いてた

実質機能してない末尾再帰最適化を拠り所にして
Rubyが1.9で壁を越えているのは認められない。
これを許すのなら、C系言語において三項演算子で
関数型条件分岐が可能とか、もっと配慮があってしかるべき。

ここまで論破され続けてもめげないのは評価するけど
本当に宗教なんだなrubyって

Rubyは宗教
Perlは文学

Rubyってコードブロック内から外を呼び出すような再帰は最適化できるの?
多くのケースで当てはまるはずだけど実装難しそう

クロージャが不完全云々という理屈を使っていながら
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]

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

>>492
宗教つーかヤバイ薬じゃね

正直Rubyは体が受け付けない
コード見てオナニーする趣味はないから誰でも似たようなコードになる言語でいいよ

Ruby はいい言語だけど彼のレスは体が受けつけない

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;})));
};

>>495
なんせモルモン教徒が伝道活動を通じて会得した
様々なテクニックを駆使して広めた言語だからね。
喩えとかじゃなくガチで宗教だし、宗教としてもかなり特殊。

>>498
マジでreturnとfunctionがうざすぎる

>>500
タイピングスピード遅いの？

>>501
なんでそうなる

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

>>498 >>503
インデントがないとすごく見づらいってことが
よく分かるなｗ

>>498
やっぱり駄目言語だな

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).

せめて名前と書き方とインデントぐらい調整してやれよ。

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 <))
　　　　)
　　}
}

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, "<") )
　　);
}

プログラミング言語力は、（言語の力で）見やすくなるかどうかだが、
プログラミング力は、（自分の力で）見やすく出来るかどうかだと思う。
言語の力に、自分の力が左右されるうちはまだまだ。

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) "

でもよく考えてほしい。
クイックソートを使うことはたくさんあっても
クイックソートの作成は一回だけだ。


どの言語もクイックソートを作成した後は、

配列 = quicksort(配列)

という一行になることに気づいてほしい。



そう。クイックソートに関する点では、
もはや言語の差がなくなってしまったのだ。

>>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回、最小になった。

>>511
参考まで、Squeak Smalltalkの#middleはこんなふうに定義されています。

SequenceableCollection >> middle
　　"Answer the middle element of the receiver."
　　^self at: self size // 2 + 1

middleありなの？とかちょっと笑える

>>513
middleの仕様を
名前から判断できる？

名前から複数の仕様が考えられ、
複数の言語があったとして、
仕様がばらばらになるようなものは、
わかりにくい名前なんだよ。

ああ、いや、そういうことじゃなく(苦笑

そういうことって？

そもそも「middle」ありなのとは書いてなくて
「middleという名前」ありなの？だろ

お前自分の勘違いに自分で笑ってるのか？

>>509
昇順で書けよ！ｗ

上から目線したら、間違ってるのが自分とわかり
このままフェードアウトするパターンですね。

標準のリスト操作以外はつかったらダメだろ
そんなのがありなら最初からCoffee使えや

>>511
JSよく知らないんですが、
filterCondとかmiddleは
どこにどんな処理として定義されているんですか？

jsはfunctionとreturnに文字数取られてるだけっぽいな

jsにfilterなんて出来たんだ
最近のjsは結構いいな

>>519
普通さ、自分でライブラリ書くだろ？
俺は現実的な開発において
差がでないことに興味はないんだよ。

>>520
5分時間やるから自分で書いてみろ。
処理の内容はquicksortの処理に必要な動作だ。

>>521
> jsはfunctionとreturnに文字数取られてるだけっぽいな
俺もそう思う。

CoffeeScriptは、わざと差が出るようなコードを意図的に書いたのを除けば、
functionとreturnの文字数分、そして括弧だけの行ぐらいしか差が出ないんだよ。
でそれくらいならタイピングにかかる時間の差ぐらいしかうまれない。

タイピングが面倒なんじゃなくて、コードがごちゃごちゃするのがうざい

そんなあなたにそっと寄り添う CoffeeScript

なんでタイピング時間って発想が出てくるの？
もしかして他のlambda式ある言語触ったこと無い？

タイプ時間じゃなければ、
読む時間か？
こっちはもっと差がないと思うが？

あっそ・・
そうやら根本的に相容れない人間らしいな

そのままじゃ動かないコードを貼り付けて「こうかけるよ」とか
何でもありなんだな。

Rubyならこんなシンプルにかけるよ！ｗ

def quicksort(xs)
　　return xs if xs.size <= 1
　　quicksort(xs.smallers) + xs.middles + quicksort(xs.largers)
end

smallers、middles、largersはクイックソートの定義そった操作だから
自分で考えてみろ。…とか許されないだろＪＫ

あ、JSの人は自分一人じゃFizzBuzzも満足に書けない人なので
他人のコードをパクって分からないところは「自分で考えろ」って言うのさ
まともに相手しても仕方ない

まあ、問題はぶっちゃけ510が正解だってことだw

それはない

>>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 とか

だった場合はどうなるの？

Haskellでは普通 \x y -> x * y なんて冗長に書かず (*) と書くので、
Haskellを使った事は無さそうだなって分かる

>>529
Rubyもそれでゆるすし、
JavaScriptもそれで許します。

function quicksort(xs) {
　　return (xs.size <= 1) ? xs :
　　　　quicksort(xs.smallers).add(xs.middles).add(quicksort(xs.largers));
}


結局のところ、ライブラリのほうが重要で
言語自体では差は殆ど出ないのさ。

cpan最強

俺だったら、>>529はダメって言うな。

なぜなら、クイックソートを実装している最中に使う
smallers、middles、largersが
クイックソート専用の関数になっているから。

クイックソートを作るときにクイックソートを実装するために
作られた関数を使ってどうするｗ
汎用関数ではない。


>>511のコードのmiddleは汎用関数
（その根拠はSmalltalkで用意されているから）
だからこっちは問題ない。

>>535
> quicksort(xs.smallers).add(xs.middles).add(quicksort(xs.largers))

おいおい、使わないかもしれないのにxs.smallersやxs.middlesやxs.largersを
メンバとして持ってるのか、すげー無駄だな。
アホのJS厨が考える事は分からんなー。

あ、>>529のRubyは括弧省略してメソッド呼んでるだけだから一緒にすんなよ？

>>538
オマエ馬鹿じゃね？

smallers、middles、largersって
Ruby厨>>529が考えだしたメンバだぞ。
使いもしないのに持ってるんだとさ。

>>539

あ、ほんとうだ！


Ruby厨って馬鹿って確信した事例の一つになった。

>>538はsmallersがメンバ変数になっていることに文句をつけてるんでしょ？

逆に言えば、smallers() なら問題ないって言っているようなもんだ。
くだらね。

ちなみにsmallersのままでもプロパティにしてしまえば
メソッド呼び出しにできるので、Rubyと一緒。

>>534
Scalaでも関数型言語なら演算子は関数扱いが普通
なんつうかGetStart斜め読み程度の知識で議論しようとしてるよな

>>541
>ちなみにsmallersのままでもプロパティにしてしまえば
>メソッド呼び出しにできるので、Rubyと一緒。
pivotとかまでプロパティ作るの？標準リストに？

5分時間やるから自分で書いてみろ。

汎用性の無い関数を山のように積み上げても
ゴミの山になるだけだと思うんだけど、
そんなんで生産性が上がると思ってる奴いるんだな

>>543
↓こいつにレスしてるの？

529 名前：デフォルトの名無しさん[sage] 投稿日：2013/08/17(土) 22:50:02.05
そのままじゃ動かないコードを貼り付けて「こうかけるよ」とか
何でもありなんだな。

Rubyならこんなシンプルにかけるよ！ｗ

def quicksort(xs)
　　return xs if xs.size <= 1
　　quicksort(xs.smallers) + xs.middles + quicksort(xs.largers)
end

smallers、middles、largersはクイックソートの定義そった操作だから
自分で考えてみろ。…とか許されないだろＪＫ

Ruby厨がクソコード書いたおかげで
尻拭いをしてることぐらい
分かれよｗ

>>542
どんな議論だか見えないんだが？

あと、リストのindexの中心をpivotにしてるのって
何か意味あるんだっけ？

xs[Math.floor(xs.length/2)]

こういうやつね。


もしかして、中央値をpivotにしようとして間違ってる？

なにか反論でも有るの？

Rubyならこんなシンプルにかけるよ！ｗ

def quicksort(xs)
　　return xs if xs.size <= 1
　　quicksort(xs.smallers) + xs.middles + quicksort(xs.largers)
end

>>550

使わないかもしれないのにxs.smallersやxs.middlesやxs.largersを
メンバとして持ってるのか、すげー無駄だな。

汎用性の無い関数を山のように積み上げても
ゴミの山になるだけ

pivotとかまでプロパティ作るの？標準リストに？

>>548
立場的にどんな場面でもfunctionとreturnキーワードは有用って主張でしょ？
じゃなきゃいちいち否定する理由がないじゃない。

>>549
うわあ恥ずかしい
お前が

>>553
え？マジで説明してよ

>>549
> もしかして、中央値をpivotにしようとして間違ってる？

中央値ってメディアンのこと？
あれは配列の数が奇数なら、中央値取ってこれるけど、
配列の数が偶数なら、中央に近い二つの値の平均になる。
だからクイックソートのpivotとは違う。

だから計算した方がいいと思ったが、
smalltalkではmiddleというメソッドが有るらしい。
（>>509 >>512 参照）

ならsmalltalkの真似でmiddleという名前を使うのはありかもしれない。
俺自身は一般的ではないと思ってるけどね。


でもさすがに>>550、このRubyコードはダメだｗ

>>552
> 立場的にどんな場面でもfunctionとreturnキーワードは有用って主張でしょ？

だれもfunctionとreturnが有用なんて言ってないと思うけど？
タイプする文字が多い程度の弊害はあると。

>>554
真の中央値調べられる時点でソート終わってるだろ

>>556
だからそれじゃ不要だという事を否定する根拠にならないだろ
言ってることめちゃくちゃだ

>>555
もちろん偶数のときは、中央に近い2つの値のどちらかを取る形式で

>>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

>>557
真の中央値ってなんだ？
もしかしてソートした配列の中で、
真ん中の値だと思ってる？

xs[Math.floor(xs.length/2)]

どうみても、（ソート関係ない）配列の中で
真ん中に位置する添字の値です。

>>557
終わってないよ
中央値はO(n)の計算量で求められるし

>>552
つまり、HaskellやScalaではラムダ式は
文法としてはあるけど実際は使わないから
functionとreturnキーワードをラムダ式に使う
冗長な記述しか認めんって主張をしてるの？

>>561
だからそれを言ってるのに理解力無いな・・。

誰だよ、smaller、largerなんて名前をつけたやつｗ
（※>>529です）

おかげで、>>560がワケの分からないコードを書き始めたぞｗ

>>564
お前が誰だかさっぱりわからん。

「真の中央値」と言い出したのは誰で
どういう意味で、なぜそう思ったのかを
いってくれ。

>>562
それは不勉強だった。すまん。

>>560
xs[1..-1]
なにこれ
全要素って意味？

>>568
xs[0] が hd xs で、xs[1..-1] が tl xs
リストの頭部と尾部のこと

>>569
やるじゃん
後はif文消すだけだな

ほぼ整列済みのときの移動を減らすためだろ。

クイックソートのアルゴリズムをちゃんと知ってないので
>>503が書いた
val pivot = xs(xs.length / 2)
が正しいやり方だと思っていた。

別に配列の最初の値でいいのか。

ならもっとスマートに書けるな。

最初の値でいい。真ん中と平均の処理時間は変わらないはず。

>>572
クイックソートは、smallerとlargerがほぼ同数になるように
分割すると計算量的に有利なので、
pivotはxsの中で最も中央値に近い値を選ぶのがベスト

だけど、馬鹿正直に中央値を計算するのも無駄が多いので、
適当に三点くらいのサンプルをとって、その中央値をpivotにしたりする、らしいよ

>>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回で済ませているのも高速化のキモになる

こうかな。

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]) );
}

そしてここで実用性のないhaskellコードが

qsort [] = []
qsort (x:xs) = qsi (< x) ++ [x] ++ qsi (x <)
　where qsi func = qsort (filter func xs)

標準ライブラリ関数が充実していれば、
どんな言語も大差ないんよね。

標準ライブラリ関数が充実してなければ、
自作ライブラリ関数が充実させればいいだけ。

あ、本当にバグってる
けどいいや

真ん中あたりの値を使うのは、たまたま
ソート済みの配列を与えられた場合の
処理の無駄を恐れてのことだろ？

>>580
正解

別に真ん中あたりの値を使っても
最悪の計算量がO(n^2)になるのは同じよ

>>577
要素の重複もついでに排除してくれるよいコードですね。

>>582
経験的に真ん中の値を使う場合の最悪の並びで与えられるより
ソート済みの配列を与えられる可能性の方がはるかに多い。

再帰が要素と同じ階層になる。

>>583
こ・・このやろう・・馬鹿にしやがって・・

>>577
qslの適用を1回で済ませるように書き直せないかな？

なお、pivotに中央値を使っても平均計算量はO(n log n)で先頭を使ったときと変わらず、
かつ最悪の計算量もO(n log n)になるよ

>>584
×ソート済みの配列を与えられる可能性の方がはるかに多い。
○ソート済みの配列を与えられる可能性の方が相当多い。



そーとー多い

もっとも、クイックソートをこのスタイルで書いてる時点で、
効率が云々とかいう議論はナンセンスなんだけどな。

山田くーん
>>589の座布団ソートして

真ん中あたりの値を使うのは、
データが連結リストだと遅い

>>590
それを言ったら、大抵の言語に標準で存在するソート関数を
こんなとこで議論してどうするよ……

>>586
次からは、たとえ劣等言語であっても、
すでにあるコードをよく読んでから投稿しようね。

>>593
言語組み込みのソートで
クイックソートなんか普通使わんだろ。

>>592
効率気にする奴が連結リストなんかソートするな。

>>587
qsort [] = []
qsort (x:xs) = qsort (fst parted) ++ [x] ++ qsort (snd parted)
　where parted = partition (< x) xs

書いたけど、リストの時点で比較とかの速度気にしても仕方ないと思うよ。

話を戻すと、そもそも「関数型ハイブリッド言語（ｷﾘｯ」とか言って
しょぼいクイックソートのコードを貼る>>498のセンスが悪い

Javascriptのソート。

sort = function (xs) {
return xs.sort();
};

それに比べたら>>576のJavaScriptコードは
相当シンプルになったよ。

言語じゃないんだよね。

そうだな
ArrayExは言語機能じゃないな

そう、ライブラリの力が
開発効率に一番影響する。

JavaScriptの糞コードを出したらボコボコにされたので
必死に話をそらそうとしているの図

他言語との比較目的なのに、いいかげん
架空のライブラリー使って書いたコード貼るのやめろよ。

ArrayExというオレオレライブラリを作るとこうなる（ｷﾘｯ

>>598
禿

でも普通の開発では、足りない部分は
自分でライブラリ作成して補うじゃん？

そのライブラリを作成する機能は
言語の機能じゃん？

現実的な話をしようぜ。

オレオレライブラリーを後出し拡張すれば、
JavaScriptでもSmalltalk程度の表現が可能なのはわかった。

>>608
middleって名前あり？

ありでいいよ。

middleは配列の真ん中の値を返す

だめだ。これ以上は無理だ。

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; })
なんて入れたんだ？

失礼。コピペミス。

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)
　);
};

{1,1,1,1,2,2,2,3,3,3}とか

>>594
何様だ

最近のjavascriptには配列にfilterやreduceなんてもんがあるのか
Ieのバージョンでいえば、いつからの話？

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

bind(カリー化)の導入に続きletの導入が検討されてるさなかで
filterすらやっと導入したieは死んでいい

かなり最近だな
IE9かよ

即時評価だろ?クソじゃん
遅延評価が可能なまともなイテレータの仕組みを導入してから対応するのが筋だろう

そうでもないよ
まあ、generatorならFirefoxで対応してるし、次期javascriptでは入るが

そうでもあるよ
時代遅れのウンコすぎ

Coffeeのリスト内包表記もPythonと違ってジェネレータにできないから所詮サンプルコード専用の飾り

それが致命的だと思ってるのはお前だけじゃね？
そんなに致命的ならCとかですぐにジェネレーターができたはずだろ
まあ、イテレータパターンくらいならどの言語でも普通にライブラリがあるけど
大抵for文で間に合ってるからほとんど使われないねw
パフォーマンスなんて結局そんなもんなんだよ

普通にforループ回すスタイルなら無くても良いよ、確かに

でも、mapやfilterなどの関数を合成するスタイルのプログラミングをするなら、
遅延評価は欲しいよ
関数合成するたびに中間状態でリスト作られるのは、いくら何でも無駄すぎる


まあ「関数型ハイブリッド言語」なら在った方が良いんじゃないのw

>>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

>>623
そういえば、ここまでPythonのコードが見あたらないね

どうして関数型言語陣営は
重複を考慮しないコードを書きたがるの？
ただのバカなの？

>>623
重複を考慮しない、とはどういう意味？
入力リスト内で要素に重複があっても正しくソートできるけど....

- qsort [3,6,1,2,1,5,4,3];
> val it = [1, 1, 2, 3, 3, 4, 5, 6] : int list

アンカをミスった
>>629の>>623は間違いで、>>628が正しい

>>625
どうかなあ、実際リストがそれほど大きいなら関数型スタイル
つかわないでforにするでしょ
ほとんどは1000以下の速度とかどうでもいいリストだろ
ブラウザ画面で1000も表示してたら通信速度もレスポンスも悪い

>>628
おそらく、たまたま>>577のHaskellコードが重複を考慮していなかった(>>583)ので、
すべての関数型スタイルが重複を考慮していない、と(>>628は)早合点したんだろなw

フィルタ(filter)を止めて、リストを二分割するパーティション(partition)という
述語(>>506)、メソッド(>>560)、関数(>>597,626)を導入したことで、
フィルタの抱えていた重複問題が自然に解決できた、という訳だ
しかもリスト探索が1回で済むから効率も改善された

>>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]])))

>>618
どうせブラウザの生存期間はもっと長いので、
polyfillで未対応ブラウザでも
容易に対応できるものはあまり問題視しない。

>>633
他の言語と同様に、標準ライブラリだけで書けないかな？

>>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)

>>633
xs[xs < xs[0]] ってどう解釈されるの？

>>636
他の言語(>>506,560,597,626)と同様に、
1回のqsort呼び出しでリスト要素の全探索処理が1回ですむように書けないかな？

どんなサンドバッグだよ

>>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:], ([],[]))

クイックソートの再帰に関する部分が常に一度きりだったら、それはクイックソートでないだろ。

いやだからね、
array.sort();
で終わる話をいつまで続けてるんだって話なんですよ
言語の違いはライブラリの違い
ぶっちゃけほとんどそれだけ

>>628
関数型陣営と限定してるけど
実は関数型もスクリプトも両方書いてるというオチ

>>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)

読めぬ……

>>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)

>>646
これって>>613と同じ方式？

>>642
清々しいまでにドカタだな

>>640
1行が長すぎて読みづらいんだけど、Pythonは可読性を大切にする言語なんだし、
関数内関数が定義できるという利点を活かして、関数partitionの定義/適用で
書き直しできないかな？

あるいは(>>613みたいに)、適切なインデントで可読性を向上させてもいいと思うよ

f = lambda xss, x: (xss, xss[0 if x < xs[0] else 1].append(x))[0]
ss, ls = reduce(f, xs[1:], ([],[]))

これでわかったけど
次回からPHPやPerlは消していい

>>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

>>651
関数型プログラミングがスクリプト言語のすべてではないから、消す必要はないと思う

クイックそーとなんてどうでも良いんだから
そんなんでPerlとPHPを削られてもな……

今はPHPもPerlも関数型の書き方で書けるはずなのに
書かないという事は人数がいない

まあ、Perlで書こうと思えば書けるけど、
なんかJS厨っぽい奴に粘着されそうでメンドイわ

無理にラムダ式を使っていた>>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

>>657
バトルスレなんだから、それは不戦敗と等しいのでは？

>>656
ああ、うん・・それは同意。

何回も呼ぶ関数の中で関数内定義するのはやだなあ
partition とかよく使う処理だし外でいいよ

馬鹿みたいにリストを作りまくってるのに
今更何言ってんだって話だけどな

クイックソートみたいな処理を何度も呼ぶという感覚がそもそも
おかしいので、まずその辺の教養をつけるといい
土方作業でも何でもいいから

クイックソートは再帰関数なんだから
何度も呼ばれるに決まってんだろ
ドカタはドカタらしくすっこんでろ

>>661
Rubyのメソッド Array#<< は破壊的操作だよ
>>657だと、メソッド inject の引数で配列が2個生成されて、
それらにメソッド << で要素を(破壊的に)追加している
だから、inject内のループで毎回ソート対象の配列全体を再生成している訳ではない
(ただしタプルとして使う2要素の配列は毎回生成してるけどね)

>>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

>>664
Rubyは配列への要素の追加操作で
内部的な配列再生成は伴わないの？
どうやってメモリを確保しているんだろう。

>>663
まずは計算量という言葉を学習してから来い

>>667
まさか、このスレのコードが空間計算量をまともに考えているとでも？

>>666
Rubyの配列は、内部実装としては双方向ポインタによる連想リストだから、
追加(<<)の場合には、追加した要素の分だけしかメモリは確保されない

スクリプト言語の実装は良く分からんけど、関数ってCだとコード領域に
一つだけ定義されてて、全部アドレス呼び出しに変換されてるよな
スクリプト言語だと、まさかいくつも関数の領域を同的に確保して、
時間食ったりするの？

> quicksort(smaller) + [xs[0]] + quicksort(larger)

無駄にリスト作りまくりなのはpartitionじゃなくて、ここ

>>667は空気が読めない人

>>670
言語や実装によるとしか。

>>670
スクリプト言語の関数はクロージャになってるのが多いし、
クロージャは環境も含むから、それぞれ毎に領域を確保する必要はあるだろう
ただ、毎回パースしたりするわけじゃない

Google Chromeのjsだと感覚通り。
http://jsperf.com/generating-simple-closure-test

>>675
一番遅いやつでも一秒間に200万回、、、
こんなの気にしてるやつがバカだなw

>>676
どう受け取ったらそうなるんだよ

クロージャって言っても静的スコープだから
スコープチェーンみたいなものへの
ポインタがあるだけでしょ

>>677
素直に数字見たらそうなるだけだが？
どれも速すぎて全く処理がないと考えていい

初代Pentium 300MHzが理論値300MFLOPSで、浮動小数点演算を秒間300万回できた
それを速すぎると感じた時代もあったね

うまいたとえ話をしたつもりかもわからんが、
関数定義の処理は、時代が進んだらハードも当然変わるんだが

>>688からわかることは、浮動小数点演算が速いと
思われた当時より数年たった今、ますます速いと
思っているように、CPUの進化でどんどん速くなる。

一秒間に200万回。これは今は速い程度だが、
将来は超速い処理ということになるだろう。
つまりますます気にしなくて良くなる。

このことを>>688はいいたいのだろう。

>>498のコードを真面目に比較して書いて5%程度の差。
誤差としていいかもしれんが、全く処理がないはいくらなんでも言い過ぎ。

ベンチマークを過信するとそうなるよね。
あるものに比べて5倍の速度が出ましたとかね。
実際使ってみると5倍も差があるように感じない。

その理由は二つあって、

一つは、プログラム全体の処理時間のうちわずか1%の部分が5倍速くなっただけ。
ベンチマークではわずか1%の部分だけを集中して
計測するようなことをするから5倍さがでるがプログラム全体からすれば
体感できないレベル。

もう一つは、もともと速い処理がもっと速くなっただけ。
0.001秒で終わるものが、0.0001秒で終わっても計測は出来るだろうが
人間にはわからない。

具体的なアプリで何秒の差がでたかというのが人間にとっては重要。

また煙に巻き始めた

煙に巻かれた。の間違いじゃないのか？

また一般論で不毛な議論に持って行こうとしてるんだから間違ってない。
何のために話題用意してると思ってるんだよ低能。

>>685
やっぱもっと宗教的・哲学的・美学的観点から論議したほうがはっきりしていいよね

683は一体どんなベンチマークをして5%差などと言ってるんだ？
それを言わないことには何の価値もないぞ

関数型クイックソート実装はもうあきたから次のお題はよ

そりゃwebやってるドカタからみれば
秒間200万なんて異次元の速度なんだろうな

結局、捨て台詞はいて終わりか

他言語の比較もしろっつってのに
自己顕示欲満たすために議論してる奴は死ね

速度が十分かどうかなんてアプリケーションによって違う

JS厨ってマイクロベンチなんて意味無いって言いながら
JSのJITは速いって事ある毎に言ってて面白い

だからマイクロベンチが意味なくって
JITが速いのは意味があることでしょ？

何を言ってるんだろうかね。

JITが速いってマイクロベンチで比較した結果でしょ？

マイクロベンチマークで比較するのが意味ないではなくて、
秒間200万回とか300万回が十分速いとかいう話じゃないのか？

ま、数値計算なら遅すぎる

もうソートは飽きたから>>409に話戻そうぜ

>>699
つか、ベンチマークの内容をみたところランダムの数値を
作ってる処理が大部分のようだが

>>409に戻すくらいならソートとか速度の話でいい

>>701
え？

>>680
初代 Pentium の 300MHz なんてあるんだ。
200MHz までだと思ってた。

>>703
マジでマジで
return functionのとこなんか特に
Random生成なんて線形合同法のバリエーションか似たような速度の
アルゴリズムだろ
つまり、実質のコストは数値一回足したとか二回演算したとかそんなもん

乱数生成は秒間2400万回くらい実行できてるみたいですがねぇ……

しばらくクイックソートの議論が続いていたので自制していましたが、
要望があったので再開します

ここまでの指摘について、>>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)

環境によって違う数値を比べられてもねえ
自分の数値でどれだけ遅くなってるのかを言ってもらわないと

>>705
randomは全ケースで同じ数だけ呼び出してる

その一番上にあるFPとかいう言語はなんなん？

>>709
で？

誰だよこいつ呼んだ馬鹿・・

>>711
>>706なんだから、randomが処理の大部分を占めるわけがない

>>711
で？って言われても
コード見る限りその上での比較だから最低でも乱数生成より2倍は遅い

他のクロージャ生成のベンチ作ろうぜ

>>713
706なんて他の数値を公表してないから何とも言えん

>>714
俺の環境だと、一番遅いやつで乱数生成の3倍程度
一番早いやつだと1/2だから、乱数生成が大多数を占めてる
特にクイックソートのやつはこれだろ

>>710
Fortranの設計者でありBNF(バッカスナウア記法)の考案者でもある
バッカス氏が考案した関数型言語です
特徴としては変数という概念が存在せず、プログラム構成子と呼ばれる
高階関数を使い、アトム、基本関数(=組み込み関数)、そして
プログラム構成子自身を組み合わせることでプログラミングを進めます

Wkipediaの英語版にも解説があるので、そちらも参考になるでしょう
http://en.wikipedia.org/wiki/FP_(programming_language)

日本語では、以下の書籍で解説されています
・続 新しいプログラミング・パラダイム
　http://www.amazon.co.jp/dp/4320025350/
なお、この書籍は>>575で紹介したGHCや、演繹データベース、
圏論のコンパイラ生成への応用、もう一つの「究極のプログラミング」である
構成的プログラミングなど、興味深いトピックが満載なのでお薦めです

>>717
一番速いやつってJust Return Fixed Functionってヤツ？
これは関数返してるだけで関数内関数を作ってないから違くね？

>>719
作ってるけど、実際の処理は関数内関数を返すだけだから同じじゃね？
まあ正確なところは実際にやってみないと分からんけど

他に試しましたが、結局元のコードが一番対比しやすそうなので戻しました。
http://jsperf.com/generating-simple-closure-test

他の結果が消えてしまったのは一度変更したためです。

>>700
お前、ほんっとバカだなっ

つーか、自演か？

>>707
>・Ruby1.9の末尾再帰最適化について、実装が不完全であるという確定情報が無いので保留(>>490)

この件について、>>369でも書いているように、情報が確定していません
もし不完全であるという確定情報があれば喜んでRuby1.9を下げたいので、情報提供を歓迎します

>>723
デフォルトオフの時点でさっさと下げるべきだろう？

PythonはデフォルトONでif式もクロージャもあるけど
なぜか上に上げてくれないようです
そういうこと

やっばｗやっちまったぜ

>>720
ベンチに関数内関数を作ってるGenerate Function Returns 0ってのがあるので、
それを見ればいいよ

>>726
ヤバいRuby厨を起こしたのお前か！

>>726
猛省しる！

>>724
Ruby1.9で末尾再帰最適化が実装されたのは事実ですので、却下します
ただし、その実装が不完全であるという確定情報があれば採用する、という話です

>>725
もしPyhtonの if式が、他の言語と同様に if <cond>: <true> else <false> という
自然な構文に変更されたなら、式指向であると認めます
この件は過去にも何度か議論されていますが、客観的な意見が無いまま、
言い換えるとPyhton支持者の独りよがりな意見のまま議論を終えているのが実情です

また、クロージャについては(自分の不勉強もあって)議論に混乱が見られたので
思いきって>>707では壁から外しましたから、Pyhtonだけが不利では無いと考えます

>>727
それだと、乱数生成コストとほぼ同じ
結局、関数の中に関数作るのなんて演算数回と変らんってこと
つまり、気にする奴はやはりバカ

>>730
> もしPyhtonの if式が、他の言語と同様に if <cond>: <true> else <false> という
> 自然な構文に変更されたなら、式指向であると認めます

だからよ、自然な構文かどうかを決めてるのはお前の主観だけだろ？
なーにが「客観的な意見が無いまま」だ、アホ

客観的っていうなら、式で条件分岐できるか否かだけで判定しろよ
それ以外は主観だろ

ん？ちょっと待て、pythonのif文は違うのか？

>>730
> 実装が不完全であるという確定情報

Ruby開発者会議20130727Japan
「特殊なケースでtail call optimizationが効かないことがあってもよいか」
https://docs.google.com/document/d/1Ie6HNoxCptIUe52I3XCxDLn52FtE_RWaF8lrDIXAVmc

これなに？

367の無知・主観によってなされた不当なランク付けを
いちいち指摘してたり、情報提供してお伺いをたてて
壁を外させたりランクを上げてもらったりするのを
この後もえんえんと続けるの？

あほらし

くだらんソートコードを書き比べているほうがまだマシだわ

>>372
条件分岐式として不可解な構文を採用しているのはPythonだけ、これが客観性の根拠だよ
不満があれば、過去の議論の一部である以下のカキコへ反論してくれ

====【Perl,PHP】LLバトルロワイヤル19【Ruby,Python】====
711 名前: 682 Mail: sage 投稿日: 2011/12/29(木) 15:05:28.17
>>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開発陣の言語設計ミス、あるいは判断ミスだね

は？構文がどうとか、条件分岐式を持つか否かと関係あんの？

> (それが自然)


でたよ、主観

>>738の先頭にあるアンカーを間違えていたので訂正する

X: >>372
O: >>732-734

Pythonってそんなにダサかったんだ

じゃあ、Rubyにはif修飾子が構文にあるし
これはよく使われてるからランク下げないとな

>>739
>>730の繰り返しになるけど、if-else構文はプログラム言語の基本要素なのだから、
もしPython設計者がPythonを式指向な言語としたのなら、他の式指向言語と同様に
最初から if <cond>: <true> else <false> という構文を採用していた、という話だよ


>>740
それが自然でないなら、>>738にある言語の中でPythonを除く:

　Smalltalk/Lisp/ML/Haskell

の設計者達も(自分と同じく)頭が変なんでしょうね
さて、Pythonのif式が不自然ではないという主張と、どちらが客観性があるのでせうか(棒

Haskell: \x -> x
OCaml: fun x -> x
SML: fn x => x
Scala: (x:Int) => x
Ruby: -> x {x}

どの関数型言語も、ラムダは「引数 矢印 戻値」と並ぶ（それが自然）
それに対して、Rubyだけが「矢印 引数 戻値」と並んでる
矢印が真ん中だから、引数が戻値に変換されるという意図が伝わるのに、
「Rubyだけ」が異端な構文を採用してる
これは明らかにRuby開発陣の言語設計ミス、あるいは判断ミスだね

異端な構文を採用してると、その言語機能を持っていないルールですので、
Rubyはラムダを持ってないということになりました

Pythonのも、
Rubyの「式 if 条件」の形に else 節を
付け足したものだと考えれば、
俺は別に変だとは思わないけどな。
Pythonは else 節をよく活用している
面白い機構も多いからなおさら自然な流れだ。
あくまで主観だけどな。ｗ

>>743
三項演算子の話と同じく「樹を見て森を見ず」だね
プログラム言語の基本である if-else 構文がRubyでは式として定義されているから、
(三項演算子と同様に)オマケであるif修飾子の存在は評価基準からは除外できるよ

ここまでの指摘にもとづいて、>>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

>>747
評価基準から除外できるとか、お前に決める権利はないだろ？
ルールマスターのつもりか？

公平に振る舞いたかったら、せめて「除外できると思うのですが、皆さんどう思いますか？」と訊け

>>747
あのさあ、
「ある言語が関数型プログラミングに活用可能な機能をどの程度有するか」と
「その言語がどのくらい関数型を意識して設計されたか」をごっちゃに
していないか？

その言語にあったパラダイムがあるんだから、
ここで後者を議論したってしょうがないだろう？
前者なら、条件分岐が値を返せればそれでいいじゃん。
構文の自然さとか、お前の主観は関係ないだろ。

それとも関数型を意識せず設計された言語は存在価値無し！とか思ってんの？

真面目に相手できるお前がすごい

>>745
Rubyの -> x { c } という構文は、Ruby2.0から採用されているね
これが違和感のある構文だというのは、自分も認める
この -> は、矢印ではなくてギリシャ文字のラムダを横に倒したものらしいが、
正直言ってコジツケだし、写像関係の矢印とまぎらわしい
素直にOCamlまたはSMLの構文を導入すれば良かったと思うが、
おそらくは fun や fn といったキーワードの導入に抵抗があったのだと憶測する

ただし、以前の(そして、Ruby2.0でも廃止されていない)構文は
lambda { |x| x } であれば矢印は使わず、lambdaという見間違えようのないキーワードが
採用されているから、これをラムダ式と見なさないという判断にも無理があるのではないかと

いや、無理があるとか無いとか、決めるのお前じゃないから

>>752
であれば |X| というブロック引数の違和感、わかりにくさは無視か？

>>752
とにかく、お前が「認める」「認めない」とかいう判断を必要とする
時点で、それはお前の主観に塗れた排除されるべき要素なんだよ。
相手には客観性を求めるくせに、いいかげんアンバランスに気付けよ。

確かにブロック引数は違和感あるな

367に絡んでるだけで自分の意見が何もないやつのほうが邪魔なんだよ

>>746
Rubyの関数型プログラミングではif修飾子は無視できる、ってことだよ
逆に、Pythonの自然な構文 if <cond>: <true> else <false> は、
Pythonの関数型プログラミングでは使えないので不自然なif式を使わざるをえない

これは、クイックソートのコード合戦で、明らかになったのではないかな？

おまえがいちばん邪魔

> これは、クイックソートのコード合戦で、明らかになったのではないかな？

まーた釣り臭い書き込みを……
上手いなーw

>>750
>それとも関数型を意識せず設計された言語は存在価値無し！とか思ってんの？

いや、>>653は自分のカキコだけど、なにか？
>>367の冒頭で書いたように、この議論は「関数型プログラミングの適性」という
限られた条件下での比較だから、誤解は勘弁願いたい

>>761
そのわりに、構文のセンスとか設計までさかのぼって議論しているじゃん。
明らかにおかしいよ。

なんだ？ もう次スレの話か？

立てておいたぞ。

【PHP,Python】ｽｸﾘﾌﾟﾄ,ﾊﾞﾄﾙﾛﾜｲﾔﾙ37【Perl,Ruby,JS】
http://toro.2ch.net/test/read.cgi/tech/1376836047/

>>758
どう明らかになったのか知らんので、説明頼む
Pythonのif式ではクイックソートが書けなかったんだっけ？

何が自然で何が不自然か
何が読みやすくて読みにくいか
これは考え方次第なんじゃね？

例えばCOBOLが自然言語に近いから
わかりやすいという主張があった。
これはある意味間違ってはないと思う。

違いは、数式で表現するか文章で表現するかだよ。
数式で表現すれば簡潔に書け、数式を知っている者にとってはわかりやすいが
知らない者にとってはわかりにくい。
文章だと数式を知らなくてもわかるが、少し文字が多くなる。

どちらがわかりやすいかというのは
場合によりけり。

俺は、なんでも短くかければいいとは思わないな。

>>752
ナリスマシかよw

>>754
樹を見て森を見ず

括弧が省略できれば見やすいか？と聞かれれば、
省略しないほうが見やすい場合もある。
セミコロンも同じ。

コンピュータはルール通りに解釈するから
どんな書き方でも解釈できるが、
人間はそうは行かない。

句読点と一緒で、コンピュータにとっては不要でも
適度に改行やスペースや区切りがあると
人間は見やすくなる。

人間にとって見やすいのは何か？
それはなんでも省略することではないと思う。

> 樹を見て森を見ず

木と森の判定がお前の主観になってんだっつの

>>752
> Rubyの -> x { c } という構文は、Ruby2.0から採用されているね
> これが違和感のある構文だというのは、自分も認める
> この -> は、矢印ではなくてギリシャ文字のラムダを横に倒したものらしいが、
> 正直言ってコジツケだし、写像関係の矢印とまぎらわしい

今はUnicodeが自由に使える時代なんだから、
ASCIIの範囲で書ことうせずに、Unicode使えばいいのにね。

文字が入力できないという問題は
IMEやテキストエディタの問題。

こういう逆ポーランド記法と一緒で、記述位置と内容に違いはなく完全な一対一対応してるだろ。

3 4 +　= 　3 + 4
1 5 + 2 3 + * 　= 　(1 + 5) * (2 + 3)

>>754,756
>>736の引用カキコで書いてあるように、コードの読み手にとって
素直に迷い無く読みとれるか否か？という視点だよ
>>752で書いたように、キーワード lambda が先行するのだから、
それをラムダ式の仮引数以外の何かと誤解するとは考えにくいと思うけど、
いかがかな？

いや、違和感あるし読み難いよ
だからアウトな

>>766
> ナリスマシかよw


　　　AA省略


　　ナリス・マーシー (1900〜)

>>771
ブロック引数にこんな記法使う言語なんかないし、
実際、ブロックローカル宣言と区別付かないし、
素直に迷いなくは読めないからやっぱりアウトな。

>>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 の部分だね

>>775
それPythonのif式で書けちゃってるじゃん

お前、Pythonのif式がダメって結論からスタートしちゃってるよ
それじゃダメな理由が説明出来てない

✕「Pythonは式指向ではない」ことが明らかになった
○「Pythonは私の好みに合わない」ことが明らかになった

表面的などうでもいいこと。
英語で動詞が先に来たり、結論を先に述べるとかと一緒で言語の内部設計と関係がない。

おいおい
「明らかになったのではないかな？」とか言っといて
よくよくきいてみれば「俺好みの順番では書けていない」かよ。
ふざけんな

>>777
---- 壁5. 式指向(条件判定式)の壁 ----

じゃなくて

---- 壁5. 私好みの壁 ----

なんだなw

>>769
その考え方を導入した言語が Fortress だね
　http://ja.wikipedia.org/wiki/Fortress
日本語の解説書も出版されている

・Fortress言語―マルチコア時代の並列化プログラミング言語
　http://www.amazon.co.jp/dp/4765533379/

順番だの自然さだのなんて主観は「樹を見て森を見ず」。
完全に本質を外しているよ！
と言ってあげたい。

>>780
それは400台のレスで既に明らかになってるよ
367の言う「式指向」という言葉は「構文の見た目が私の好みに合っている」という意味

はい終了

>>783
え？そういう話なの？！

>>776
理由については、>>738を参照汁

Ruby1.9のTCO実装は不完全だから壁は越えられないでFA？

Rubyの exec if cond はどう説明するの?
関数型的な機能じゃないから見て見ぬふり?

もう面倒だから、誰かが異質だって言ったら即アウトにしよう

>>788
きゃつの主観で無視できる存在らしいぜ。

少なくとも>>775は上と下で読みやすさに差が無いな
むしろ若干上の方が読みやすいくらい

聞けば聞くほど判断基準が怪しく思えてくるな

>>787
いいよそれで

Haskellのリスト内包表記もどっちかというと>>775の上やexec if condに近いタイプだが、
あれは許せるのか?
ちなみにPythonもほぼ同じ表記を採用している

おまえら暇だなぁｗ
こんなrubyキチに付き合うとはｗ

>>795
別に関数型言語が偉いとか誰も何も言ってないのに、Rubyの順位が高いだけで
脊髄反射のようにRubyキチ扱いする奴ってどうなのかねぇ？

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.

>>796
ここまで見る限り十分論理的な批判ばかりだと思うぞ
誰もRubyをdisってるわけじゃないし

>>796
言ってることがおかしいぞ？
さてはおまえもRubyキチか？

Rubyは一番手に馴染む

左から右へ流れなきゃいけないってむしろ手続き型の頭だろ
SQLとかもそうだけど宣言型では方法より結果を先に書くのが好まれる傾向がある

超訳
結果が左と右に綺麗に分かれていて見やすいし、条件が結果を
コントロールしていることがよく分かる
それに、英語の文法に沿っていて読みやすい
読みやすさは重要だ

つまり、英語のネイティブにとって、英語に近いPythonの方がむしろ
読みやすいという意見があるようだね

式指向()では違うんだとさ。

そもそも、左から右へ流れてる流れてないというのは
どういう基準で決まるんだ。
「もしも~ならこうして、そうでないならこうする」という日本語の
流れに沿ってるのが左から右へ流れてるってこと？
だとすると、英単語を使ってるPythonからしたら噴飯ものだよね

宣言型というよりか、結果が先に来るのは
英語の文法のせいじゃね？

もし、英語が日本語のように
結果を後に書く文法だったら、
右から左なんてものもなかっただろう。

SQLも、「○○テーブルから、○○という条件に合うものを、抽出」という
書き方になっていただろうね。

一行に複数の文を書いたら、
左から右へ処理が進むわけで、
右から左という流れがそもそもおかしいんだろう。

代入式も右から左だし
関数の定義だって入力と出力を先に書いてからそのあと中身書くでしょ

そもそもRubyだって代入は右から左に処理が進む
367が大好きな流れの向きとは逆

そもそも、関数が
function(a,b)みたいな順序になったのも英語のせいだな
動詞、目的語という語順だから
だから、目的語に対して時系列に左から右へと関数が
適用されていくという形を取ることができなかった
このせいでプログラミングの世界は遅れてしまったと思う

それに、配列とただの値を区別するのも英語らしい
全てが配列であり、普通の値は、長さが1の配列として扱えたら
統一的に扱えていいのにと思ったことはいくらでもあるけど、
日本語が主流だったらそういうスクリプト言語ができていたかもね

perlの変数がスカラーと配列で最初の文字が変わってくるのも
英語の単数系と複数形の影響だろうね
Ruby作者が「私には複数か単数かなんてことはどうでもいいので、
Rubyはそうなってない」という話をしてるのを聞いて、ああ、日本人なんだなあ
と妙に納得したよw
多分英語圏の人にとっては、どうでもいいことじゃないんだろうねえ

左から右に流れるのが好きなのは別に構わんが、
Haskell等の関数型言語の関数合成は右から左
だから、関数型プログラミング適正とやらとは無関係ですね

>>811
無関係だろうね
ただし、劣ってると思う
時系列に左から右へと行く方が明らかに便利
英語に引きずられておかしなことになってしまった
全ては英語が劣った言語のせい

関数の語順までいくと、ラテン語のさらに前の言語くらいまで起源が遡りそうだが
まあ欧州圏の言語族ではあるだろうな

だらだら書く分には左から右が好きかな
読むときは左に結果が来てる方が読みやすい

書き捨てコードが主戦場のRubyは左から右であるべきだな

結論が先にきたほうが分かりやすいのは前置きが長い場合かな
そういうのはIdeの機能で飛ばしたり畳んだりとどうとでもなるが

コードが短かったりIDEの入力・表示補助があるなら
どっち向きにコードが流れるかなんて
どうでもいい

基本は上から下、左から右が分かりやすいに決まってるだろ
英語圏のバカどもが、英語の感覚でやるからそれに気づかなかっただけ
英語以外の民族にはいい迷惑
オブジェクト指向が流行ったのも、ぶっちゃけ英語と反対の語順で書けて、
時系列と流れが一致して分かりやすくなったからだ

住所の書き方が一番納得できない

あれ？式指向()が論破されちゃったから
腹いせに英語をdisることにしたの？

流れに逆らうってのはどだい無理が出てくる
あとから参照するために、Itやらthatやらに相当する変数がたくさんいるんだよ
これでプログラミング不必要な変数を乱発しわかりにくいものになった
それもこれも語順が間違ってたせいだ
Jqueyなんかがメソッドチェーンで人気を博しているけど、
最初からそうなるべきだったんだよ

代入が右から左なのに、それ以外が左から右だと
代入する側とされる側が遠く離れて読み難いんだよ

だから、x = y で x が y に代入される言語を作ってから戻ってこい。な？

正直日本語でも
「こうするよ、~ならね。さもなくばこうする。」とは言えるし
時系列もこの場合は関係ないから、Pythonの式でも別に不都合はないよ

パイプは左から右への流れだな。

echo hello | sed 's/$/ world/' | wc -c

関数もこんな表記を採用すればよかったんだよ。

v = foo(bar(baz(123))) みたいなカッコの対応取れてるか？
って問題は発生しない

123 | baz() | bar() | foo() => v

メソッドチェーンみたいで見やすいだろう？

まあ引数が複数になった時どうするかって話があるけど。

処理の流れは左から右がいいが、定義は話が別。

日本語の辞書でもそうだが、
まず単語がでてきて、その説明を書く。

------------------------------
★プログラミング言語
プログラミング言語（プログラミングげんご）とは、
コンピュータに対する一連の動作の指示を記述するための人工言語の総称である
------------------------------

みたいにね。

定義とはC言語で言う#define みたいなもの。
関数の定義もそう。左は右と等価であることを示すもの。
なお代入は定義ではない。

>>824
よく分からない
定義が先に出てくると、なんで左から右じゃないの？

だいたい、代入が右から左とか言ってるけど、それは錯覚だ
矢印を変えればあら不思議
v => 123
左から右だろ？
しかも、これは「vが出て来たら、123に置き換えろ」と読めるから合理的
実は代入の矢印はみんなが考えてるのとは逆にするべきなんだよ

x = y + 1 とは書けても
x + 1 = y とは書けないから、代入は紛れも無く右から左だよ

例えば、x = x + 1 と書くことが出来る。

これが定義であるならば、

x = x + 1
x = (x+1) + 1
x = ( (x+1) +1) + 1
　：
　：
となって意味不明なことになる。

だからこれは定義ではない。

#defineの動きを見てみよう。

#define VALUE foo() + bar() // この時点では処理は実行されない。
int value = foo() + bar() // 処理が実行されvalueに値が入る。

printf("%d", value); // 変数の値を出力するだけ
printf("%d", VALUE); // ここでやっと処理が実行される。


このように、代入と定義は実行されるタイミングが違う。
定義だと必要になるまで実行されない。
すなわち、遅延評価と同じものなのだ

>>826
ソッコーで>>827に論破されててワロス
Ruby厨って存在自体が恥ずかしいね

俺はRuby厨でなんでもないのだが、仮にy+1=xとかけないからと言って
なんで紛れもなく右から左になるのか分からない
単に、方向が固定されてることを示しただけであって、それが右から左なのか
左から右なのかはその議論からは確定しないじゃないか
しかも、y+1=xと書けないのはそういう規則にしているだけの話だろう

y = x + 1 って、時系列的には x + 1が計算されて、その結果がyに代入されるって順番だよね？
まさか、これすら受け入れられないレベル？

>>829
君のネタはとても面白いからコテつけてくれないか

>>832
そういう話ならカッコの有無とか演算子の優先順位で状況次第ってことになる
自分はそういう話をしてるつもりはないんだけど、もともとは
流れ的にそういう話だったみたいだな
多分、文脈と違う話をしてたわ
スマン

>>829
誰も定義と代入が一緒だとは言ってないと思うんだが
なぜに一生懸命そういう説明をしてるんだ？

まあjsとかpythonとかの場合、関数定義を変数に代入したりするから
ややこしいんだが

>>833
面白いならコテつけなくても
見分けつくだろう？

まあ、つける気はないが。

上から下、左から右という手続き型の基本原理に洗脳されてる奴ってことだ。
結論が先で詳細、条件があとは関数型だからあり。
TrueResult if Conditions
TrueResult if Conditions else FalseResult

x = y + z という代入と同じ仕組み。
これは手続き型では特例で本来は、y + z -> xという処理の順序で書かれるべき。

お前ら目を覚ませ

関数型も本来は上から下、左から右であるべき
そうでないから引数に余計な括弧がついたりするんだ

>>838
それは正確には、+演算子の優先順位が代入演算子の優先順位より高いというだけ
別に例外でも何でもなく、よくあること
たとえば、1+2*3などは乗算から先に計算するがこれと全く一緒の理屈

>>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支持派の
意見も聞きたいので、本件の判断は保留、つまり現状維持とさせていただきます

そもそも、結論が先と言ってるわりに、falseResultは一番最後にきてるじゃん

>>841
馬鹿だなぁ。代入の話は演算子優先順位とは全然関係ない
優先順位を弄っても、「y + zの値をxに代入する」という処理で
y + zを=の左側に持って来れるわけじゃないからな

出来るもんならやってみ？

>>707の「式指向の壁」について、結局、>>783の引用カキコに対して
正面からは反論できない、ということでいいのかな？

つまり、Pythonのif式、<true> if <cond> else <false> の読みやすさについて
英語文法として自然である(>>802)とかといった意見はあるけど、
もしそれら意見に客観性があるのならば、

　条件分岐式があるPython以外の言語 Smalltalk/Lisp/ML/Haskell の設計者達も
　Pythonと同様の構文を採用したはずであるのに、実際にはそうならなかった....

この矛盾を説明できない限り、「式指向の壁」は壊せないよ

>>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修飾子は使われていない(=使わずに書けている)ことは実証された

三項演算子の議論と同様に、枝葉の矛盾で幹ごと倒そうとする論法を「詭弁」と言う