- Lisp Scheme Part38
832 ：はちみつ餃子 ◆8X2XSCHEME [sage]：2014/06/21(土) 13:14:23.01 ID:P7AT9cRE - gcc くらいに高度なコンパイラになるとどんな風に最適化したコードを吐くか予測するのが難しくて、
癖をよく知ってないとチューンナップのつもりが逆効果ってこともあるし、
かといって最適化をオフにすると他の箇所全部が遅くなるわけなんで、俺も >>831 に一票。
|
- 関数型プログラミング言語Haskell Part25
870 ：デフォルトの名無しさん[sage]：2014/06/21(土) 13:21:28.22 ID:P7AT9cRE - 動的型だから緩いということもないと思うが。
エラーが出るのが実行時かコンパイル時かという違いだけで、
型が合わなきゃまともに動かないのは同じだよ。
Common Lisp は型を明示することも出来るけど、
それは型チェックのためのものじゃなくてコンパイラに最適化のヒントを与えるためだったりするし、
宣言した型に特化したコードにコンパイルするので宣言通りでない型のオブジェクトがくると SEGV ったりしやすくなる。
緩いと言えば緩いのかもしれないけど、処理系のチェックが入らない分だけプログラマにとってはハードな部分もある。
|
- 関数型プログラミング言語Haskell Part25
872 ：デフォルトの名無しさん[sage]：2014/06/21(土) 15:42:40.48 ID:P7AT9cRE - Common Lisp は機能不足だったり遅くてもいいからざっくりと動くものを書いてから改良するというスタンス。
そのために必要なプロファイラや逆アセンブラも充実してる。
動的型だから事前にどんな型のオブジェクトが渡されるかわかんないけど、
プログラマは知っているという前提で型の特定はプログラマが宣言するという形でさせる。
プログラマがチューニングするための道具を提供するという方向で進化したから、
歴史が長い割に処理系がやってくれる最適化はそれほど強力ではなかったりする。
そんなわけで、動かしながら改良するというやり方なんで、
型が合わない場合も含めて問題に気付き易いし、
どうしてもよくわかんなくなったら戻ってやり直しすればいい。
ようするに開発手順も含めて考えないと評価できんぽよ。
|