- C言語なら俺に聞け（入門編）Part 126
239 ：デフォルトの名無しさん[sage]：2014/07/16(水) 00:55:22.22 ID:m0YcwmXR - >>236
たとえばC言語で「構造体の配列」と「構造体へのポインタの配列」について
要素の並びを変更に要する時間を比較してみると、
前者は構造体の全メンバの値をコピーしなければならないのに対して
後者はポインタの値だけをコピーすればいいから、後者の方が速い
ただし、最近は「PCの処理能力が飛躍的に向上している」から、
よほど巨大な配列でない限り、両者を性能測定しても僅かな差にしかならない
だから(両者の間には)「速度差がない」と言う人がいるのかもしれないが、
学校の演習やアルゴリズムの初歩的な学習過程のように、「まずは動く事が最重要」
という世界であれば、そういった意見も間違いではない（理由は上に書いた）
ただし>>236が社会に出て一人前のC言語プログラマを目指すのなら、
「コードの簡潔さと可読性を損なわない範囲」で論理的に速い手法、
つまりポインタを迷わず選択できる技術レベルを目指したほうがいいと思う
|
- Swift part2
801 ：デフォルトの名無しさん[sage]：2014/07/16(水) 19:53:44.76 ID:m0YcwmXR - >>786
3点、指摘する
まず 1. と 2. の間に、
「1.5 ソースコードを抽象構文木(AST)に変換し、これを評価することで実行される」
という分類が抜けている
これは、Ruby 1.8 までの実装が該当する（1.9 からは YARV へ移行）
また学校の演習課題で作らされる大半の LISP 処理系も、これに該当するだろう
次に、3. はコンパイラの定義であり、インタプリタの定義としては間違っている
3. には「実行時にリンクされ、」という記述があるけれど、
インタプリタはすべてのシンボルのアドレスが解決された中間コードを生成できるから
コンパイラのように外部シンボルを解決するリンカを必要としない
仮想マシン技術を基礎とするすべての処理系はインタプリタであるという
解釈は誤りであって、実行形態によってインタプリタとコンパイラへと分類できる
いいかえると、javac(コンパイラ) と java(仮想マシン処理系)という明解な分離のある
「Java言語処理体系はコンパイラ」であって、これをインタプリタとするのは間違い
なお「javaコマンドはJVMバイトコードのインタプリタ」である、という表現は正しい
最後に、削除した旧 3. に代わって、3'. の定義を追加する
「3'. ソースプログラムはマシンに依存しない中間的なコードにコンパイルされた後、
マシンに依存するコード(機械語)へ再度コンパイルされてから実行される」
これは LLVM ベースのインタプリタ、たとえば MacRuby が該当する
|
- Swift part2
802 ：デフォルトの名無しさん[sage]：2014/07/16(水) 20:19:38.09 ID:m0YcwmXR - >>797
DropBoxクライアントは元々 WxPython で書かれていたから、
OSX移植に PyObjC を利用するのは自然な流れだろうね
ただしこれは特殊なケースであって、Python が App Store で扱うような
「一般の OSX/iOS アプリ開発」にも適しているという結論にはならないのでは....
|
- Swift part2
803 ：デフォルトの名無しさん[sage]：2014/07/16(水) 20:43:30.79 ID:m0YcwmXR - >>796
Ruby のケースだと、RubyMotion（旧 MacRuby） があるよ
旧世代の RubyCocoa や PyObjC では Cocoa をアクセスするには
いちいち ScriptingBridge フレークワークを中継する必要があった
これらに対して新世代の RubyMotion では
Ruby の Object クラスが ObjC の NSObject クラスとして実装されているから、
ブリッジを介することなく直に Cocoa フレームワークを利用できる
結果として、すでに Rails が代表的なWebフレームワークとして
世界で認知されているように、RubyMotion も OSX/iOS 向けの
サードパーティ製スクリプト言語処理系として絶対的な存在になろうとしている
なお RubyMotion は(Swif のような)Apple純正の処理系ではないけれど、
その作者は(Cocoa の内部を知り尽くした？) Apple 所属の社員になる
現実には、プロトタイピングとして RubyMotion を使い
アプリをサクッと作ってはイジってコワすというプロセスを繰り返し、
仕様が固まったら Swift で書き直すという流れが多いだろうと思う
そして Ruby と Swift はどちらもオブジェクト指向はもちろんのこと、
普通のクロージャ(ブロック)を備えるなど関数型プログラミングにも
適しているという共通の特性があるから、両者の相性も良い
|
- 【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ44【pl,rb,php,py】
737 ：デフォルトの名無しさん[sage]：2014/07/16(水) 20:52:42.83 ID:m0YcwmXR - >>735
gosh> (= a (+ (* 2 3) 4)
)
*** ERROR: unbound variable: a
|
- Swift part2
806 ：デフォルトの名無しさん[sage]：2014/07/16(水) 21:11:25.88 ID:m0YcwmXR - >>805
原文の英語だと
1. parse the source code and perform its behavior directly
と正しく記述されているのに、それを翻訳したと思われる日本語版だと
"parse ..." (... を構文解析する)という動詞が抜け落ちて
1. ソースコードを直接実行する。
という意味の異なる間違った文章になってしまっているね
結果として>>786みたいに日本語版の一部をコピペして恥を晒す
可哀想な人があらわれるから、まったく困ったものだ（自業自得かな？）
教訓としては、「Wikipedia を鵜呑みにするなかれ」ではないかと思われ
|
- Swift part2
807 ：デフォルトの名無しさん[sage]：2014/07/16(水) 21:57:04.70 ID:m0YcwmXR - >>806 を補足(蛇足？)すると、日本語版の翻訳者は後に実装例として挙げられる
Tiny Basic の知識不足から誤訳を犯してしまった可能性がある
たしかに Tiny Basic の先祖で最も有名な処理系である Palo Alto Tiny Basic、および
それから派生した東大版 Tiny Basic は、まさに「ソースコードを直接実行」していた
だから翻訳の過程で原文の要点であった動詞 parse が抜け落ちてしまったと思われる
なお、Texas Tiny BASIC と派生した東京版 Tiny Basic はソースコードを中間言語へ
コンパイルしてから実行しているから、>>786 であれば 2. に該当する
（この処理系の中間言語における命令は MCALL/ICALL/JUMP/TEST のたった４つしかない）
その意味では、原文(英語版)の記述も(間違いではないが)不完全とも言える
|
- 【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ44【pl,rb,php,py】
749 ：デフォルトの名無しさん[sage]：2014/07/16(水) 22:37:14.18 ID:m0YcwmXR - >>746
静的型付けには「明示的な静的型付け」と「暗黙的な静的型付け」の
二種類あって >>746 のC言語は前者になる
で、後者を実現する最もよく知られた技法が「型推論」であり、
この型推論を備えた「モダンな静的型付け言語」では
動的型付け言語と同様に変数のデータ型を宣言しなくてもいい
（もちろん文書化を目的に変数の型を明示してもかまわない）
|
- 【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ44【pl,rb,php,py】
769 ：デフォルトの名無しさん[sage]：2014/07/16(水) 23:49:39.69 ID:m0YcwmXR - 型推論という技術が誕生した動機は「データ型に関する完全性の証明」にある
つまりコンパイル時にエラーが無いということは、コードによって与えられた
データ型システムに矛盾(=バグ)が無いことを形式的に証明できた事と同じ意味になる
これが1970年代に起きたことで、誕生した初めてのプログラミング言語がMLである
こうした背景を知っている人からすれば ML や Haskell の型推論こそ「本物」であり、
メソッド引数と戻り値の型を明示しなければならない
C#/Scala/Swift の型推論は「中途半端でいいかげんな代物」であって、
ましてやデータ型システムの正しさを全く検証しようともしない
JavaScript の型推論は「言葉を借用しただけのまがい物」という扱いになる
公平な見方をすれば、本来の目的は「データ型システムの検証」にあり、
これは正しいか正しくないかという単純かつ美しい二値論理の世界観であった
これが発展して一部で矛盾が存在しても実用的であれば認めるというゆるやかな考え方が生まれ、
さらには本来想定していなかった検証以外の応用が考案され普及するまでに理論や技術が発展を遂げ、
型推論の研究そのものが大きな成果を得た、と言える
だから口論になっているみたいだけど、保守派と革新派という立場が違うだけで、
どちらも正しいんだから、お互いの立場を尊重し合って議論しようぜ ..... などと思う
（なお、現在知られるようになった型多相(ポリモリフィズム)の次に普及が期待されていて、
型システムに関し最も研究のホットな目標が、依存型と構成的型理論の世界になる）
|