トップページ⇒tech
1001コメント270KB

静的型付け言語の潜在開発生産性は今の100倍 ×2

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2013/10/06(日) 00:30:02.59
人間がやっていたことを、コンピュータにやらせる。
これが生産性を上げる最大の方法。
コンピュータは間違わない、同じ事を何度も高速に行える。

その為に、コンピュータがコードの意味を正確に
認識できる方法が必要。実行しないとわからないことは
コンピュータは認識できない。

すなわち静的型付け言語であれば、実行しなくてもわかるので
コンピュータが理解できる。そうすれば様々な
コンピュータの高度な情報支援が得られる。

コンピュータのバックアップを受け、人間の生産性は
限りなく向上する。

静的型付け言語の潜在開発生産性は今の100倍
http://toro.2ch.net/test/read.cgi/tech/1362302249/
0002デフォルトの名無しさん2013/10/06(日) 00:35:23.66
おっつっつ
ポジティブな話題話そうぜ
0003デフォルトの名無しさん2013/10/06(日) 05:59:07.15
で、何なんだったんだあのJS馬鹿は
0004デフォルトの名無しさん2013/10/06(日) 06:05:38.89
JSが嫌いで憎くてたまらないんだろうさ。
0005デフォルトの名無しさん2013/10/06(日) 06:51:40.72
クロージャは関数外の変数を参照できる必要はあるけど、書き換えられる必要は無い

JSerはJSが関数型を取り込んでるとか云うわりに、関数型について無知すぎる
0006デフォルトの名無しさん2013/10/06(日) 12:12:29.38
> クロージャは関数外の変数を参照できる必要はあるけど、書き換えられる必要は無い

無知発見ｗ

書き換えられないと駄目だし、その他の言語も全て書き換えられる。
0007デフォルトの名無しさん2013/10/06(日) 12:17:59.68
それ以前にだな、
JS馬鹿の
外のスコープを参照可能であることとvarのセマンティクスが腐っている事を
混同したアホな議論にいつまで付き合ってやるんだ？
0008デフォルトの名無しさん2013/10/06(日) 12:37:02.05
>varのセマンティクスが腐っている

具体的に
0009デフォルトの名無しさん2013/10/06(日) 12:49:06.19
>>6
＞書き換えられないと駄目だし、その他の言語も全て書き換えられる。

Haskell
0010デフォルトの名無しさん2013/10/06(日) 13:08:41.57
>>9
Haskellは純粋関数型言語なので
変数の書き換えそのものがないだけ。
0011デフォルトの名無しさん2013/10/06(日) 13:11:18.52
「その他の言語も全て書き換えられる」と
言ったからダメなんだろ。

変数を書き換えられる言語であれば、
すべての言語がクロージャーから
クロージャー外の変数を書き換えれられる。
0012デフォルトの名無しさん2013/10/06(日) 13:12:17.57
>>5
> JSerはJSが関数型を取り込んでるとか云うわりに、関数型について無知すぎる

関数型を取り込む ≠ 関数型言語

ですよ？

いつ関数型言語になったといいました？
0013デフォルトの名無しさん2013/10/06(日) 13:30:25.98
完全論破された後のJSerの言い訳ワロス
無知すぎる
0014デフォルトの名無しさん2013/10/06(日) 13:37:44.00
OCamlも再代入はめったに使わない
0015デフォルトの名無しさん2013/10/06(日) 14:52:09.19
関数型言語の低レベルのメリットっていうのは純粋関数型言語でしか得られない
JSの場合関数型「スタイル」っぽくも書けるってだけのこと
0016デフォルトの名無しさん2013/10/06(日) 16:28:55.18
JSerの場合、関数型スタイルの事これっぽっちも分かってないと思うよ
まさかコールバック地獄を関数型スタイルだと思ってんの？
0017デフォルトの名無しさん2013/10/06(日) 16:52:19.10
JSを叩けなくなったら今度は架空のJSer叩きっすか……
凄い執念だぁ
0018デフォルトの名無しさん2013/10/06(日) 17:12:15.39
関数スコープ外の変数を上書き出来ないと困るー
めっちゃ頻繁に上書きしたいわー
上書きにvarとか必要になったら面倒でプログラミングにならんわー
ってのがJSerの主張でしょ？
0019デフォルトの名無しさん2013/10/06(日) 17:17:42.53
>>18
架空のJSer叩きっすかｗ
0020デフォルトの名無しさん2013/10/06(日) 17:22:56.54
関数スコープ外の変数をあまり上書きしないなら
varを付けた場合と付けない場合の振舞いは
逆の方が良いね
0021デフォルトの名無しさん2013/10/06(日) 17:40:17.18
>>20
意味がわからん。

varって変数宣言だぞ？

varを付けた時と付けない時が反対って、
お前、 varを付けなかったら、
変数宣言してないのに
変数が勝手に宣言されるってことか？

変数名間違ってもエラーにならないってことなんだが。
0022デフォルトの名無しさん2013/10/06(日) 17:42:40.03
IDE使わんの？
未使用変数をリアルタイムで色付けしてくれるタイプの
0023デフォルトの名無しさん2013/10/06(日) 17:45:51.65
varを付けなくても勝手に宣言されるとしたら、
名前間違ったら、未使用変数ではなくなってしまうよな。
0024デフォルトの名無しさん2013/10/06(日) 17:46:39.23
んなことないよ
よく考えろよ
0025デフォルトの名無しさん2013/10/06(日) 17:49:07.12
最初に一回宣言しただけで
他から一度も参照されてない変数に色付けする機能があるんだよ
varとか関係なく、便利
0026デフォルトの名無しさん2013/10/06(日) 17:50:00.56
例えばこういうこと。

var i, j;
k=123;

スペルミスでkという名前を使ってしまった場合、
varを付けたとき変数宣言されるならば、
宣言されてないkを使っている・・・スペルミスだろうと警告できる。

だけどvarを付けなくても変数宣言される場合は、
kを使ってるから、kは未使用ではない。
なんの問題もないと判断してしまう。
0027デフォルトの名無しさん2013/10/06(日) 17:50:11.33
グローバルに変数ができちゃうことが問題なわけでそれ以外は問題ない
よってvarとかそういうもので何か変わるもんでもない
0028デフォルトの名無しさん2013/10/06(日) 17:50:47.84
>>26
>>25を読んでね
0029デフォルトの名無しさん2013/10/06(日) 17:54:21.82
JavaScriptにはevalやグローバル変数のハッシュアクセスがあるんだからそれは無理
0030デフォルトの名無しさん2013/10/06(日) 17:55:03.85
>>28
二回間違ったらアウトじゃん？
0031デフォルトの名無しさん2013/10/06(日) 17:56:17.66
そうなんだ、残念だね
0032デフォルトの名無しさん2013/10/06(日) 17:56:35.64
>>27
グローバルに変数ができることなんて無いよ。

>>29
だよね。ソースコード上は変数が一回しか使われてないように見えても
使っていることだってあるし。

たぶん動的言語を知らないから
思いつかないんだろうな。
0033デフォルトの名無しさん2013/10/06(日) 17:57:31.79
>>30
最初の一回目でリアルタイムで色が付くのに、
それに気付かずに二回目も間違えるの？
0034デフォルトの名無しさん2013/10/06(日) 17:57:43.66
は？
x = 1
ってやったらもろxはグローバル変数だろうが
0035デフォルトの名無しさん2013/10/06(日) 17:58:44.93
>>29
関数スコープの変数宣言の話じゃないの？
0036デフォルトの名無しさん2013/10/06(日) 18:01:15.44
>>34
ちゃんと読んでよね。

$ cat a.js
"use strict"
x = 1;

$ node a.js
x = 1;
^
ReferenceError: x is not defined
at Object.<anonymous> (/tmp/a.js:3:3)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:901:3
0037デフォルトの名無しさん2013/10/06(日) 18:02:00.42
>>32
型が動的でもスコープはレキシカルって言語も多いよ
あんまりダイナミックスコープを採用してるメジャー言語って無いんじゃない？
Perl（両方使える）とかEmacs Lispくらい？
0038デフォルトの名無しさん2013/10/06(日) 18:02:30.53
変数がどこのスコープに属してるのか解析するのはかなり大変だと思うぞ
そんじょそこらのエディタのプラグインじゃないだろうし
これからもできないだろう
なんだかんだ言ってやっぱりJSはコンパイルが要らないことを活かして
トライアンドエラーで、ブラウザのコンソールを使ってデバッグしていくしかない
エディタの超高度な支援に期待するのは話がうますぎる
0039デフォルトの名無しさん2013/10/06(日) 18:03:55.16
ブラウザのコンソールってお前・・・。

ブラウザにはデバッガが内蔵されていることも知らんのか？
ブレークポイントもステップ実行もできるぞ。
0040デフォルトの名無しさん2013/10/06(日) 18:04:11.07
>>36
お前こそちゃんと読めよ
strict modeじゃない場合の挙動で
varの効果を逆にすればいいみたいなこと言う輩に言ったんだよ
0041デフォルトの名無しさん2013/10/06(日) 18:05:17.38
>>40
今はstrict modeがデフォです。
今ではとっくに解決してしまった、
昔の話をいつまでしてるんですか？
0042デフォルトの名無しさん2013/10/06(日) 18:06:13.56
さすがにuse strictじゃない挙動は論外だろ……
0043デフォルトの名無しさん2013/10/06(日) 18:06:19.72
>>39
バカはお前だ
当然それも含んでデベロッパーツールのことをIDEとかと対比して分かりやすくコンソールと読んでるいるに決まってるだろうが
言葉の揚げ足取りやめろよ
0044デフォルトの名無しさん2013/10/06(日) 18:06:32.40
馬鹿「varの効果を逆にすればいい（どやっ）」

天才「strict modeをONにすればいいじゃないですか( ﾟ∀ﾟ)ｱﾊﾊハハ八八ﾉヽﾉヽノヽノ＼/＼ 」
0045デフォルトの名無しさん2013/10/06(日) 18:07:10.95
>>43
コンソールの意味もしらんの？

GUIのデバッガを
お前はコンソールって言うわけ？
0046デフォルトの名無しさん2013/10/06(日) 18:07:31.60
>>41
日本語分かんないのか？
話が噛み合ってないぞ
0047デフォルトの名無しさん2013/10/06(日) 18:08:19.24
良く使う＆より危険でない操作の方を短く書けるべきだよね？って話でしょ
全然別の問題が並行して議論されてるんですよ
0048デフォルトの名無しさん2013/10/06(日) 18:08:39.55
>>43
お前の場合、GDB（デバッガ）をIDEじゃないからという理由で
コンソールっていいそうだなｗ
0049デフォルトの名無しさん2013/10/06(日) 18:09:27.39
>>45
言葉尻を捉えるのはもういいから
勘違いしてた、ごめんねでいいだろ
0050デフォルトの名無しさん2013/10/06(日) 18:10:13.76
コンソールはデバッガじゃないですよ。
勘違いしてたごめんねって誤るのはまだ？
0051デフォルトの名無しさん2013/10/06(日) 18:11:00.41
JavaScriptがどうのこうのこのスレで語ることじゃない
ここ行け
http://toro.2ch.net/test/read.cgi/tech/1379350030
0052デフォルトの名無しさん2013/10/06(日) 18:11:40.68
>>50
誤りでした
勘違いしてたごめんね
0053デフォルトの名無しさん2013/10/06(日) 18:12:51.92
>>51
そっちはJS厨に乗っ取られた
0054デフォルトの名無しさん2013/10/06(日) 18:15:02.48
過疎スレでJavaScriptが一番話題に事欠かないってだけでしょ
ここでもそうだけど
0055デフォルトの名無しさん2013/10/06(日) 18:23:49.46
>>38
evalとかバイトコード書き換えを使う場合を除けば
解析できると思うけどねぇ
eval使って解析できないのは自己責任と割り切る
0056デフォルトの名無しさん2013/10/06(日) 18:28:02.40
一応メモ帳でも書ける言語なんだからエディタに期待するのは
言語仕様検討外だからなあ
一応実行時のデバッグサポートについては沢山仕様で入ってるけど
そりゃあ不可能ではないが
JSLintやHintでさえ異常な認識したりするし、現状絵に描いた餅だなあ
0057デフォルトの名無しさん2013/10/06(日) 18:33:30.28
>>54
すげえプラス思考
0058デフォルトの名無しさん2013/10/06(日) 18:38:44.38
LListの場合はサーバサイド−クライアントサイドとして見た時
もしくはそうじゃなくても日常的にWebは皆触れてるし、
大企業が絡んでるのも合って公平に見てもJSが最も話題にしやすい言語かと
HTML5とES6の勧告が来年に控えてる今だからってのもあるけど
0059デフォルトの名無しさん2013/10/06(日) 18:42:00.43
単純にJavaScriptを使っている人が多いのと、サーバーサイドでは別の言語を使っていて
クライアントでJavaScriptを使う、みたいな人が多いだろうから他の言語との比較で色々
話題や不平不満も出てくるんじゃ無いのかな。

言語Aでの作業から言語Bへの作業にスイッチした時に「言語Aではxx出来るのにむき〜」
と感じる場面が自分は時々あるけれども、JavaScriptも例外じゃない。
0060デフォルトの名無しさん2013/10/06(日) 18:47:10.91
Webは日進月歩だしJSの仕様実装もLivingStandardだしね
WebAPIを含めれば毎日何らかの新しいことがあるだろう
個人的にはやっぱりES6で歴代のバージョンUPと比較できないほど
大きく変わるっていうのにワクワクしてる
0061デフォルトの名無しさん2013/10/06(日) 18:51:15.38
俺も土管として使いやすくなりそうでワクワクしてる
0062デフォルトの名無しさん2013/10/06(日) 18:56:44.77
ProxyやReflectionが入ったから色んな代替言語が作りやすくなるだろうね
0063デフォルトの名無しさん2013/10/06(日) 19:04:14.60
なかっち 動画
http://www.youtube.com/watch?v=z2qK2lhk9O0s



みんなで選ぶニコ生重大事件 2012
http://vote1.fc2.com/browse/16615334/2/
2012年　ニコ生MVP
http://blog.with2.net/vote/?m=va&;id=103374&bm=
2012年ニコ生事件簿ベスト10
http://niconama.doorblog.jp/archives/21097592.html


生放送の配信者がFME切り忘れﾌﾟﾗｲﾍﾞｰﾄを晒す羽目に 放送後に取った行動とは?
http://getnews.jp/archives/227112
FME切り忘れた生主が放送終了後､驚愕の行動
http://niconama.doorblog.jp/archives/9369466.html
台湾誌
http://www.ettoday.net/news/20120625/64810.htm
0064デフォルトの名無しさん2013/10/06(日) 19:56:54.77
Reflectってどういう時に使ったらいいんかね？
0065デフォルトの名無しさん2013/10/06(日) 21:36:18.25
Javascriptの生産性が低すぎる件ですが
どうやったら解消できますか？
0066デフォルトの名無しさん2013/10/06(日) 21:44:34.02
具体的には？
というか言語の生産性にそこまでの差なんて無いと思うけど
それDOMがつまらないってだけじゃない？
もちろんスクリプト言語なんだから環境によってぜんぜん違う
UnityのJavaScriptなんてまるっきり別物だし
0067デフォルトの名無しさん2013/10/06(日) 23:16:15.44
>>1
>静的型付け言語の潜在開発生産性は今の100倍

なるほど、今の静的型付け言語は、動的言語の/100の能力って事だな。
スレタイは一見、静的言語を褒めてるように見せてるけど、実は動的言語(´∀｀∩)↑age↑なんだよね。
当面は動的が有望と。
0068デフォルトの名無しさん2013/10/06(日) 23:28:34.07
単純に考えて実行環境は
コア数が増えサンプリング推論技術が高まるほどより動的な言語に有利
0069デフォルトの名無しさん2013/10/06(日) 23:33:52.61
>>67
> >静的型付け言語の潜在開発生産性は今の100倍
>
> なるほど、今の静的型付け言語は、動的言語の/100の能力って事だな。

なんでこんなに馬鹿なんだろう？
論理学の勉強したこと無いのかな。

馬鹿にも分かりやすくたとえてあげよう。

フリーザ「私の戦闘力は今の100倍だ」
ヤムチャ「ということは俺の1/100の戦闘力って事だな」
0070デフォルトの名無しさん2013/10/06(日) 23:35:00.24
世代じゃないから分からん
とある辺りで例えてくれ
0071デフォルトの名無しさん2013/10/06(日) 23:41:08.74
世代じゃないって、60代以上か？
でも俺の親でも知ってるし、
だとしたら、70代以上か？
0072デフォルトの名無しさん2013/10/06(日) 23:43:17.61
２０だ
0073デフォルトの名無しさん2013/10/06(日) 23:44:59.16
頭が悪いからJSしか使わない
動的言語なんて他にもいろいろあるのに
0074デフォルトの名無しさん2013/10/06(日) 23:47:39.68
こりゃまた頭が悪そうな台詞だ
0075デフォルトの名無しさん2013/10/06(日) 23:54:31.22
ほらな
本当に一つしか知らないからこんなレスにも反応してしまうし、
そう思考停止してるから与えられた環境で満足してしまう

それがJS使いの平均だと思われるのが本当に残念だ
0076デフォルトの名無しさん2013/10/06(日) 23:55:41.09
>>75
お前誰にレスしてるんだ？
いきなり出てきてわけのわからんこと言うなよ。
お前の人間性が問われるところだぞ。
0077デフォルトの名無しさん2013/10/07(月) 01:16:50.67
とりあうな
0078デフォルトの名無しさん2013/10/07(月) 01:46:28.22
>>69
100倍もあるなら何故すぐ発現させないんだ？ってところだろ。
いつまでたっても発現しない「潜在性」に縋るのは単なる厨か信者だしな。
0079デフォルトの名無しさん2013/10/07(月) 01:50:00.70
民主の潜在可能性は自民の100倍！
株価は3倍、国民所得は2倍に！
0080デフォルトの名無しさん2013/10/07(月) 09:12:15.81
>>78
> 100倍もあるなら何故すぐ発現させないんだ？ってところだろ。
ツールとか技術がまだ確立されてないから。
すぐに出来ると思うなよｗ
0081デフォルトの名無しさん2013/10/07(月) 09:19:38.08
どの辺りに伸び代があるの？
と建設的な質問をしてみる
0082デフォルトの名無しさん2013/10/07(月) 11:05:44.53
データベースとモデルクラスが一体化すれば楽になる
DDLを定義変更したら自動でモデルクラスが再生成されるとか

もう既にあるんだろうけど
0083デフォルトの名無しさん2013/10/07(月) 15:24:23.75
その辺りはもはや言語と言うよりフレームワークの問題では？
そもそも言語にそんな差があるとは思えない
純粋関数型は特殊さがいろいろあるけど、静的か動的かくらいでねぇ
0084デフォルトの名無しさん2013/10/07(月) 16:44:03.54
>>80
じゃあ動的言語も、ツールとか技術が確立されたら、静的言語を軽く超えるな。
0085デフォルトの名無しさん2013/10/07(月) 18:39:43.99
>>64
ポリフィルに凄い大活躍すること間違いなし
0086デフォルトの名無しさん2013/10/07(月) 20:06:59.73
もう型推論でも使ってろ
これで静的も動的も仲良くなれる
0087デフォルトの名無しさん2013/10/07(月) 20:39:00.13
JavaScriptの著名なエンジンは型推論してるじゃん
0088デフォルトの名無しさん2013/10/07(月) 20:54:13.50
TypeScriptのあまりに御粗末な型推論を見る限り
JavaScriptの型推論には期待出来ない
0089デフォルトの名無しさん2013/10/07(月) 21:14:41.66
TypeScriptの型付けはコンパイル時エラーを出すためのもので
実行時には何の効果も及ぼさないよ
JSのエンジンの型推論は普通に協力
だからこそあの速度を維持できるんだからね
0090デフォルトの名無しさん2013/10/07(月) 21:37:40.21
真面目な話、実行時プロファイルに比べたら効果は微々たるもの
0091デフォルトの名無しさん2013/10/07(月) 21:42:52.87
仮に実行時に効果を及ぼせたとしても、
簡単に数値化と文字列を間違えるようなウンコな型推論じゃ
全く効率的では無いだろうね ＞ TypeScript
0092デフォルトの名無しさん2013/10/07(月) 21:57:02.85
文字列と数値の間違いなんて無い
0093デフォルトの名無しさん2013/10/07(月) 22:00:54.71
馬鹿なんだから、確かめもせずに無いとか書くなよ
>>6で知ったかして恥かいたばかりだろJSerは
0094デフォルトの名無しさん2013/10/07(月) 22:02:46.11
今のCPUじゃ32bitや64bitが扱いやすいんだから
オーバーフローが気になる固い数値型は要らなくて
JSとかDartとかみたいに自動スケーリングのほうがいいと思う
0095デフォルトの名無しさん2013/10/07(月) 22:04:43.82
>>93
エディタの表記が間違うのはエディタのせいであって言語の間違いではない
全てはTSの仕様通りですがなにか？
0096デフォルトの名無しさん2013/10/07(月) 22:08:49.19
これを貼れば良いんだよねw

> function g() : number { return ((x,y) => x + y)(1, "Hello World"); }
> の戻り値は "1Hello World"
0097デフォルトの名無しさん2013/10/07(月) 22:19:23.80
それ型推論関係ないし
TypeScriptの型指定は実行時は関係ない
IDEのサポートのためのものでしかない
0098デフォルトの名無しさん2013/10/08(火) 00:24:47.80
>>84
> じゃあ動的言語も、ツールとか技術が確立されたら、静的言語を軽く超えるな。

それはないよ。

動的言語の定義により、
「実行するまで状態が確定しない」

故に実行前に知ることが出来ない情報が多い。
0099デフォルトの名無しさん2013/10/08(火) 01:24:19.23
コンパイルが要らないから
実行時も開発環境に気楽に入れれるから
状況が違う
0100デフォルトの名無しさん2013/10/08(火) 01:38:39.24
>>99
おいおい、実行って一度実行すれば
いいってもんじゃないぞ。

実行しないと状態が確定しないというのは、
一度実行しても違う実行パターンがあるならば
状態が確定しないということだ。

すべての実行パターンなんて、想定不可能なわけで
事実上いくら時間があっても、状態は確定しないってことだぞ。
0101デフォルトの名無しさん2013/10/08(火) 01:42:04.10
コンパイル時間なんて実行時間に比べりゃ
微々たるもんよ。
0102デフォルトの名無しさん2013/10/08(火) 01:59:43.55
変なことを言うねえ
ライブコーディングは大きな開発生産性じゃない？
0103デフォルトの名無しさん2013/10/08(火) 03:32:24.93
いいえ、何も考えずに行き当たりばったりで
書いてるだけにしか見えませんね。

頭のなかでちゃんと考えていれば
実行しなくてもコードはかけるはずです。

例えば将棋でコマを動かしてから考えるプロがいますか？
そんなことをするのは初心者だけです。
動かしたらやり直しはきかないですからね。

頭の中で瞬時に幾つもの手を考え、その中から
最善の方法を選び、それを書くだけなので動かす必要はありません。
いちいち動かすなんて面倒くさいことしてられませんよ。
0104デフォルトの名無しさん2013/10/08(火) 03:42:13.25
将棋のソフト作る時は予想外のバグがあるもので
何十回も何百回も動かしてみないといけないものだぞ
それは電王戦出るような開発者も言ってるし
自分もつくづく感じてる
0105デフォルトの名無しさん2013/10/08(火) 03:45:41.63
>>104
論点がずれてる。アホ。
0106デフォルトの名無しさん2013/10/08(火) 03:48:45.30
そもそも、ライブコーディングは、ライブでコーディングすることであって
ライブで実行することじゃないからｗ
0107デフォルトの名無しさん2013/10/08(火) 03:57:17.91
ん？いきなりどうした？
0108デフォルトの名無しさん2013/10/08(火) 03:57:41.22
C言語やJavaのライブコーディング動画も
あるのに何を言ってるんだ？って話。
0109デフォルトの名無しさん2013/10/08(火) 04:00:31.97
そりゃそのとおりだね。
0110デフォルトの名無しさん2013/10/08(火) 04:02:10.48
ここまで1100レス消費して
動的型が優れてる証拠は山ほどあるのに静的型については０
静的厨はいつもの様に揚げ足取りにご執心
人の意見は否定してばかりだが自分の意見は言わない
それも当然、ぶつけて負けるのが分かりきっているから
恐怖と不安で脳が混乱し煽り文章しか打つことが出来ない
当に病気
0111デフォルトの名無しさん2013/10/08(火) 04:04:06.95
自演のコメは間隔が約3分あいててわかりやすいね。
0112デフォルトの名無しさん2013/10/08(火) 04:06:25.40
>>111
自分のこと言ってんの？
0113デフォルトの名無しさん2013/10/08(火) 04:08:30.37
もう煽りはいいからね……
前向きな話をしようよ。
このスレで話すべきことはこんな技術があるよってことでしょ？
0114デフォルトの名無しさん2013/10/08(火) 04:11:16.27
煽ってきたのはそっちだってーのｗ

ライブコーディングの意味間違ってるでしょ？
それに対して反論がないなら、
何も言うことはないはずだよ？

誰にレスしてんのさ。
0115デフォルトの名無しさん2013/10/08(火) 04:18:36.31
>>113
言うだけ無駄無駄
こいつら最初から分かり合うつもりなんて一切無いし

折角わざわざ過疎スレに動的言語のネタ投下してやってるのに、こいつら言語と同じで頭まで固い
普通だったら勉強になるなぁってなるとこ

今じゃ色んな言語が色んな言語の特徴を取り入れてるってのに
おまえ自身の思考が潜在能力を潰してることに気づいたときには手遅れｗ
0116デフォルトの名無しさん2013/10/08(火) 04:22:26.11
>>114,117
お得意の記憶操作＆被害妄想いつもご苦労でーすｗｗ
0117デフォルトの名無しさん2013/10/08(火) 04:24:05.36
自演のコメは間隔が約10分あいててわかりやすいね（笑）
0118デフォルトの名無しさん2013/10/08(火) 04:26:48.15
おお、こりゃ自演バレが余程応えたようだｗ
効いてるｗ効いてるｗｗ
0119デフォルトの名無しさん2013/10/08(火) 04:27:24.44
こいつなんで煽るんだろう？

ライブコーディングの間違いを指摘しただけでしょ？
0120デフォルトの名無しさん2013/10/08(火) 04:31:16.25
素直に間違いも認められないし、謝ることも出来ない。
言動がガキそのもので人間性が最悪、最底辺だなーって思うね。
多分本人も気づいてないんだろうけどさ。
社会の落ちこぼれなんだろうな。
だからここでうっぷんを晴らしている。
0121デフォルトの名無しさん2013/10/08(火) 07:17:48.66
頭から読み直してて気になったんだけど、>>96って本当にコンパイル通るの？

>>97
君の考える型推論って何？
0122デフォルトの名無しさん2013/10/08(火) 07:25:38.46
型注釈はあっていいなぁ。あって困る理由がない。
0123デフォルトの名無しさん2013/10/08(火) 08:33:53.33
numberって型注釈を書いてstringが返ってくるくらいなら
何も無いほうがマシ
まじで騙されるわ
0124デフォルトの名無しさん2013/10/08(火) 14:11:18.65
コメントにnumberを返すって書いてあるのにstringが返ってくるくらいなら
コメントなんて無いほうがマシ
まじで騙されるわ

アホでしたか。
0125デフォルトの名無しさん2013/10/08(火) 16:16:27.15
アホはお前だ
0126デフォルトの名無しさん2013/10/08(火) 17:31:07.05
TSはJSに変換されるんだからオーバーヘッドがかからないように
実行時の判断は省略されるのは当たり前
エディタの問題であって言語の問題ではないし
凄く特殊なケースを挙げてまで何がしたいのだろうか？
0127デフォルトの名無しさん2013/10/08(火) 17:36:43.20
型チェックをすり抜けるんだからコンパイラの問題じゃん
0128デフォルトの名無しさん2013/10/08(火) 18:01:52.58
せやな
言語のせいじゃない
0129デフォルトの名無しさん2013/10/08(火) 18:16:58.80
>>106
いや、ライブで実行することだけど？
少なくとも学術論文ではそうなっているよ？
0130デフォルトの名無しさん2013/10/08(火) 18:19:55.04
コンパイラがバグってるんじゃなかったら、
そんなユルユルな型チェックで良しとする言語の問題
0131デフォルトの名無しさん2013/10/08(火) 18:24:44.98
TypeScriptの場合、>>96は仕様通りだよ
0132デフォルトの名無しさん2013/10/08(火) 18:28:01.89
>>129
http://en.wikipedia.org/wiki/Live_coding
0133デフォルトの名無しさん2013/10/08(火) 19:40:26.15
まさかのソースはウィキかw
ほれ、学術系での定義
http://liveprogramming.github.io/2013/papers/liveness.pdf
A system supporting fully live programming is one that permits
a programmer to edit a program while it is running, and furthermore
the system continues the execution immediately and without noticeable
interruption according to the updated version of the program
0134デフォルトの名無しさん2013/10/08(火) 19:50:05.04
LLと同じで必ずしも同じ意味で使われてるとは限らないでしょ
言葉尻捉えるより相手の気持ち汲み取ってあげようよ
0135デフォルトの名無しさん2013/10/08(火) 20:07:10.68
>>134
同意。というわけで>>106は反省するように。
0136デフォルトの名無しさん2013/10/08(火) 21:00:15.73
Java, PHP, 旧VB, 古い時代のPerl, Javascript

この辺りの言語しか経験の無い奴って
ウンコ言語の基準でしか物事考えられないから
議論が噛み合ない
0137デフォルトの名無しさん2013/10/08(火) 21:08:53.33
まあJavaScriptはいくらバージョンを重ねたところで今ブラウザで広くまともに使えるバージョンが
未だウンコなので仕方がない。
0138デフォルトの名無しさん2013/10/08(火) 21:32:30.60
広く使える必要なんて皆無だけどな
広く広まってる分新しいバージョンの人数も多いということでもあるし
そもそもWeb上のものだけのものでもないからね
0139デフォルトの名無しさん2013/10/09(水) 05:10:43.68
ロジックはc++で書いてasmjsにして終わり
早くこんな時代になってほしい
UIはjsでいいかな
0140デフォルトの名無しさん2013/10/09(水) 06:09:48.79
asm.jsで直接扱えるのは数値と真偽値だけです
0141デフォルトの名無しさん2013/10/09(水) 06:26:44.38
>>133
ライブコーディングでなくて、ライブプログラミングだし、
しかもライブコーディングの部分読む限りwikiと変わらんけど。
自分で相手の根拠示すとか、根本的なアホなの？
0142デフォルトの名無しさん2013/10/09(水) 06:27:32.62
今現在一般向けのウェブサイトのUI開発にCoffeeScriptの類を使うのは珍しく
無いけど、ECMAScript6相当を同じ分野に投入できるのはまだまだ先だろうな。

当面はサーバーサイド等の特定実装かマニアの趣味。
ブラウザのバージョンの入れ替わりの速いモバイル向けのHTML5アプリから使わ
れ始めて、PC向けのサイトにも使えるようになるのはGoogleがIE10のサポートを
切る辺りだろうから、まだ数年かかる。
0143デフォルトの名無しさん2013/10/09(水) 06:32:38.79
>>141
ちゃんと論文全文読もうね。
0144デフォルトの名無しさん2013/10/09(水) 07:08:46.87
>>143
ブーメランですね。
0145デフォルトの名無しさん2013/10/09(水) 07:25:37.94
CoffeeScriptやTypeScriptはES6みたいなものだ
CSはESの礎（プロトタイプになったし）
TSのはES.nextを意識して実装してる
classとかアロー関数とか有名なものは皆は同じ
0146デフォルトの名無しさん2013/10/09(水) 07:38:01.16
つまりCoffeeScriptやTypeScript、Haxeを使っておけば良いということか。
0147デフォルトの名無しさん2013/10/09(水) 07:45:44.43
ブラウザではコンパイルしてJSになる言語を使ってればOK
0148デフォルトの名無しさん2013/10/09(水) 07:51:16.95
>>146
今使うのならCSよりはTSにした方がいい
CS使うのならES6simuの方がいい
0149デフォルトの名無しさん2013/10/09(水) 07:55:45.82
でーでもTSの型推論ゴミでしょ？
マトモな型推論ある言語を使った事あったら
草不可避
0150デフォルトの名無しさん2013/10/09(水) 07:58:24.79
まあES6はES5に置き換え不可な機能がいくつか合って
classもそうなんだけどな
とにかくclass構文に関しては導入され次第さっさと使った方がいい

>>142
IE12はおそらくwin7対応だろうし
自動アップデートされるから10とか気にしなくて良くなるよ
Vistaの9が暫く気になるかなー、まあ数少ないし仕方ないかくらい
0151デフォルトの名無しさん2013/10/09(水) 08:00:12.03
TSに型推論なんてないぞ？
型注釈ならあるがあくまで開発サポートのためで
実行時には綺麗サッパリ外れてほぼCSと同じコードになる
0152デフォルトの名無しさん2013/10/09(水) 08:07:38.73
いくらTSの型推論がゴミだからって、全く型推論が無い扱いは可哀想だろうよ
一応、この程度のコードなら型チャックしてくれるんだから

function f(): number {
    var x = 1
    var y = x + "a"
    return y // Cannot convert 'string' to 'number'
}
0153デフォルトの名無しさん2013/10/09(水) 08:08:18.44
うわ、型チャックってなんだ。型チェックだ
0154デフォルトの名無しさん2013/10/09(水) 08:08:47.23
マトモな型推論ある言語を使った事あったら
TypeScriptに型推論があるなんて思うわけがない
上に出てた型推論とは全く関係ない指摘を型推論と思い込んじゃたってのがすぐ分かる
0155デフォルトの名無しさん2013/10/09(水) 08:10:44.24
>>152
型推論っていうのは宣言を明示的にしなくても
勝手に宣言してくれるような機能であってそういう明示的なのとは全く違う
0156デフォルトの名無しさん2013/10/09(水) 08:12:01.27
でもこれは型チェックできない、ワロス

function f(): number {return ((x) => x)("a")}
0157デフォルトの名無しさん2013/10/09(水) 08:12:46.05
>>155
xやyの型はいつ宣言しましたか？
0158デフォルトの名無しさん2013/10/09(水) 08:14:35.63
xやyの型でエラーが出てるんじゃなくて
関数の戻り値の型と合わないエラーでしょ
型推論っていうのはこういうの

var x = [];
x = 1; //error
0159デフォルトの名無しさん2013/10/09(水) 08:17:00.22
>>158
お前本当に何も分かってないな
宣言してないyの型を推論して、その推論した型と戻り値の型が合わないから
エラーを出してるんだろうが

で、>>158のそのxは何で型エラーが出てるの？www
0160デフォルトの名無しさん2013/10/09(水) 08:18:41.96
型推論っていうのは
型を推論することじゃなくて
どの型で宣言されればいいのか推論することです
いい加減恥ずかしいからやめてね
0161デフォルトの名無しさん2013/10/09(水) 08:22:38.27
これでも見て勉強しろ。
http://ja.wikipedia.org/wiki/%E5%9E%8B%E6%8E%A8%E8%AB%96
0162デフォルトの名無しさん2013/10/09(水) 08:28:30.40
>>160
いや、まさに型を推論してるんだけど

で、>>158は何でエラーになったの？答えてよ
あと>>157にもね
0163デフォルトの名無しさん2013/10/09(水) 11:11:27.33
function add_1(x){ return x + 1; }
function add_2(x){ return add_1(add_1(x)); }

add_2("22"); // compile error

こうだろ普通
戻り値型の注釈付けておいて型推論できましたって言われても
0164デフォルトの名無しさん2013/10/09(水) 11:41:27.36
それは何でコンパイルエラーなの？
0165デフォルトの名無しさん2013/10/09(水) 11:50:49.86
>>164
型推論が働くならコンパイルエラーという意味
0166デフォルトの名無しさん2013/10/09(水) 13:03:03.35
JSは文字列と数の加算が定義されてるんだから、
勝手にエラーにしたらダメだろ
0167デフォルトの名無しさん2013/10/09(水) 14:25:23.29
IE11、ES6対応といっても主要な機能だとletとconstへの新規対応だけなんだな。

ES6は凄い -> letとconstが使えます、って事か。実質。
そりゃ凄い。

言語の仕様拡張で夢は広がりんぐは結構だけど肝心の実装とランタイム環境の更新が
伴ってない。

ブラウザ向けは当面別の言語の模索も続くだろうね。Haxeってどうなん?
0168デフォルトの名無しさん2013/10/09(水) 14:40:57.26
>>166
それもまともに型推論働かない理由の一つだな
根本的におかしい機能に固執する
0169デフォルトの名無しさん2013/10/09(水) 15:43:45.77
varはスコープの先頭にまとめるというスタイルも変数巻き上げのトラブルを避けるための
ノウハウはいえ、客観的にみると単にウンコな変数宣言の仕様に巻き込まれて強制されて
いるだけで、見栄え的にも何時の時代のCよという感じではあるな。
0170デフォルトの名無しさん2013/10/09(水) 17:22:36.80
>>163
ローカル変数の型推論は型推論と呼ばない俺ルール発動ですか？
俺ルールじゃないなら信頼できるソースを頂けますか？
0171デフォルトの名無しさん2013/10/09(水) 18:11:14.52
>>170
俺ルール発動か？
そもそも型推論じゃないとは言ってないが
そんな貧弱なチェックであるとドヤ顔されても困ると言ってる
0172デフォルトの名無しさん2013/10/09(水) 19:49:32.66
型推論っていうのは変数の宣言される型を推測することであって
その変数がどんな型かを推論することじゃないだろ
TypeScriptの場合varで宣言したときはJSと同じ任意型であって
型推論で型が決定されているわけじゃない
0173デフォルトの名無しさん2013/10/09(水) 19:54:40.67
>>169
それはJSに慣れてない人のためのもので
知っていれば別になんでもないこと
0174デフォルトの名無しさん2013/10/09(水) 20:07:26.61
>>172広義では型を決め打ちすること全般でいいんじゃ？
0175デフォルトの名無しさん2013/10/09(水) 20:20:03.95
ほかの言語の欠陥はあげつらうのにJavaScriptの欠陥は「知っていればなんともない」
なんですね。巻き上げられて良いことなんて何もない、単なるバグの発生源なのに。
0176デフォルトの名無しさん2013/10/09(水) 20:24:41.48
つーかTSとかの型推論挙げずに素直に関数型言語や.NET系の型推論挙げとけよ
0177デフォルトの名無しさん2013/10/09(水) 20:32:15.72
>>172
いい加減なこと書くなよ
ちゃんと任意型を表すanyがあるし、varで宣言しても任意型にならない
第一任意型なら、>>152はエラーになったらダメだろうが

ここでも読んで出直してこい
TSの型推論ついても書いてあるから
http://phyzkit.net/typescript/
0178デフォルトの名無しさん2013/10/09(水) 20:41:08.15
anyとvarで吐かれるコードは同じ
そんないい加減なもの型推論とはいえない
0179デフォルトの名無しさん2013/10/09(水) 20:42:44.15
>>175
それでバグが起こったことや実際見たことなんて入門したての頃から１０年強一度もないな。
0180デフォルトの名無しさん2013/10/09(水) 20:46:08.43
>>178
型チェックの結果コンパイルエラーになるか否かが違う
0181デフォルトの名無しさん2013/10/09(水) 20:50:05.99
なって無いじゃん
そんなんコンパイラの気休めサービスで言語の機能じゃないだろ
0182デフォルトの名無しさん2013/10/09(水) 20:51:58.89
>>179
宣言を最初にまとめる方が異端な現状を見ると全く説得力がない
ただ気になる人もいるってだけでそりゃ人間の好みって言うもの
lintとかでも途中の宣言を認めないなんてものはないし
実際困ることもない

重複宣言にならないっていう便利なことはある
letなどならこれはエラーになってしまう
要は使い分けの問題
0183デフォルトの名無しさん2013/10/09(水) 20:53:55.14
これはコンパイルエラー

var x = 0
var n : string = x // Cannot convert 'number' to 'string'


こっちはコンパイルエラーじゃない

var x : any = 0
var n : string = x
0184デフォルトの名無しさん2013/10/09(水) 20:56:15.46
>>181
TSの仕様書にも型推論について書かれてるけど……

http://www.typescriptlang.org/Content/TypeScript%20Language%20Specification.pdf
0185デフォルトの名無しさん2013/10/09(水) 20:57:05.49
ES7のguardが導入されるのを待とう。
既に一部ES7候補の仕様を実装してきているFirefoxならそう遠くないはず。
0186デフォルトの名無しさん2013/10/09(水) 20:58:56.02
その通り動かない仕様書なんて便所の落書きと同じｗ
必死だなTS厨ｗｗｗ
0187デフォルトの名無しさん2013/10/09(水) 21:01:48.34
>>186
＞その通り動かない仕様書なんて便所の落書きと同じｗ

仕様書のどの辺りを読んで、仕様通りに動かないと思ったの？
仕様書のその箇所を引用してみて
0188デフォルトの名無しさん2013/10/09(水) 21:02:56.57
TypeScriptは言語じゃなくて「JavaScriptをよりよく書くためもの」だからこんなものだよ。
それで十分役目を果たしてるんだから問題ない。
0189デフォルトの名無しさん2013/10/09(水) 21:06:40.48
>>187その必要はないｗ
こちらにはちゃんとした型推論ではなく気休めサービスでしか無い証拠があるんだからｗ
そちらがちゃんと示してコンパイラの実装不備で今は便所の落書きになってるけれど
将来は期待してくださいお願いしますって弁解してみろよｗｗ出来るもんならｗｗｗｗｗ
0190デフォルトの名無しさん2013/10/09(水) 21:10:10.41
>>189
いや、型推論がゴミなのは仕様通りなので、
コンパイラの実装不備っていう結論はおかしい
そう言える証拠があるなら別だけど
0191デフォルトの名無しさん2013/10/09(水) 21:11:41.60
>>189
仕様書も読まずに仕様について語るなよ……
それでもプログラマかよ
0192デフォルトの名無しさん2013/10/09(水) 21:11:56.46
ゴミの型推論が仕様通りならちゃんと擬似型推論って言えよｗｗ
見え張ってんじゃねえよｗｗ
0193デフォルトの名無しさん2013/10/09(水) 21:13:30.92
>>191
馬鹿かｗ
こっちは型推論が仕様にあるって言葉を信用したんだよｗ
で、実際はゴミだったわけだｗ詐欺だわｗｗｗ
0194デフォルトの名無しさん2013/10/09(水) 21:15:06.78
>>193
うわぁ、仕事できなそう…
0195デフォルトの名無しさん2013/10/09(水) 21:17:30.63
遂にTS厨白旗かｗｗ
もう人格批判がやっとやっとｗｗ
0196デフォルトの名無しさん2013/10/09(水) 21:19:09.20
ていうか、一貫してTSの型推論はゴミだと書いてきたつもりだが…
どのレスを読んでTS厨だと思ったのだろうか
0197デフォルトの名無しさん2013/10/09(水) 21:24:51.87
型推論なんていらない
せっかくの動的型の優位性が失われる
自動変換も知らないやつが悪い
0198デフォルトの名無しさん2013/10/09(水) 21:26:21.49
自動変換？暗黙の型変換のこと？
0199デフォルトの名無しさん2013/10/09(水) 21:28:05.57
JavaScriptの暗黙の型変換や条件評価はものすごく複雑だぞ
まあ普段使う分にはその1/5くらいの知識で十分だろうが
0200デフォルトの名無しさん2013/10/09(水) 21:34:35.57
型推論で失われる動的型の優位性って何？
0201デフォルトの名無しさん2013/10/09(水) 21:38:22.80
型推論をパフォーマンス向上のために使うのなら結構だし、実際されてることだけど、
それを厳格さのために用意されて型エラーが出るようなことになると相性悪いってことじゃない？
やっぱりguardとか「型揃え」の方が考え方として相性いいんじゃないかな。
0202デフォルトの名無しさん2013/10/09(水) 21:39:12.25
連想配列に色んな型を含める
0203デフォルトの名無しさん2013/10/09(水) 21:41:38.17
オブジェクトに入れればいいんとちゃうん？
0204デフォルトの名無しさん2013/10/09(水) 21:46:20.12
連想配列はMapを使えばいい
0205デフォルトの名無しさん2013/10/09(水) 21:48:04.17
>>198 >>200
実を言うと釣りのつもりで書いたのに
擁護多すぎてドン引き中
0206デフォルトの名無しさん2013/10/09(水) 22:06:17.72
まあ本当にそこは言語の「柄」、そうじゃなくなったらその言語じゃないって部分だから
JavaScriptを使う限り前向きに受け入れて使うしか無いでしょう
どんな言語でもそう
0207デフォルトの名無しさん2013/10/09(水) 22:07:43.07
new xcomponent({width:200, height:100, visible: false})　// 使用

動的
xcomponent::constructor(xcis){...}

静的
xcomponentInitStruct {
　int width,
　int height,
　bool visible
}
xcomponent::constructor(xcomponentInitStruct xcis){...}
0208デフォルトの名無しさん2013/10/09(水) 22:15:29.31
既に「エラーの出ない型推論」をエンジンが暗黙的にやってくれてるんだから
JSはそれでいいじゃん
0209デフォルトの名無しさん2013/10/09(水) 22:17:35.88
scalaとかも静的型なんだが
0210デフォルトの名無しさん2013/10/09(水) 22:18:25.61
実行速度だけで言えばそうかもね
もっとも実行速度で比べたらJSも静的型言語に比べたら遅いけど
0211デフォルトの名無しさん2013/10/09(水) 22:20:32.41
まあ、TSの型推論をみれば、JSのエンジンがやってる型推論の程度も想像がつくな
本当に自明なところだけ推論してるんでしょう
0212デフォルトの名無しさん2013/10/09(水) 22:20:57.36
JSは変数使いまわしたら推論効かなくなるっちゅうの
0213デフォルトの名無しさん2013/10/09(水) 22:28:06.13
俺ならこうする
y &= ~(y >> 31);
0214デフォルトの名無しさん2013/10/09(水) 22:29:58.28
型推論というのは二種類あって、
一つは、静的型付け言語用の機能で型を書くのが
面倒だからそれを省略してかけるという機能

これはあくまで省略記法であり型情報は失われておらず
型を書いているのと全く変わりがない。

そのため静的型付け言語用であり、こっちの意味の型推論は
動的型付け言語には存在しない。
一般に言われる型推論というのはこっちの方。


もう一つは動的型付け用の機能で、明らかに特定の型しか
なりえないと判断した時に、動的な言語の遅さをカバーするために
特定の型用に最適化するための機能。

JSなんかの型推論というのはこっちの方。

コンパイラが頑張って型を推論できればいいのだが
現実にはそれが難しいために、型を明確にするために
特殊な書き方をすることがある。
0215デフォルトの名無しさん2013/10/09(水) 22:33:21.31
うーん。それだと実行時に統計情報を収集して
特定の型用の最適化コードを生成するのも含んでしまう感じだな
0216デフォルトの名無しさん2013/10/09(水) 22:33:56.84
HaskellとCoffeeScriptの組み合わせがトレンドなんだろ？
0217デフォルトの名無しさん2013/10/09(水) 22:34:15.28
>>211
プロファイル数に応じて投機度と最適化度を変えてるし、
Firefoxなんかは何個もエンジン積んで使い分けてる。
http://ledyba.org/2013/02/27181531.php
0218デフォルトの名無しさん2013/10/09(水) 22:38:37.67
asm.js使うとネイティブ超える場合もあるしなあ
0219デフォルトの名無しさん2013/10/09(水) 22:38:55.09
後者ってVMで有効になるやつのことでしょ
JSみたいに根幹にハッシュ使ってる言語で型推論で最適化とかいっても焼け石に水だと思うけどなあ
0220デフォルトの名無しさん2013/10/09(水) 22:41:20.55
最適化に邪魔な仕様は意図的に無視して
何らかの不具合が生じた場合にフォールバックするというのが
JS最適化の手法
0221デフォルトの名無しさん2013/10/09(水) 22:43:40.74
既にhotspotが通ってきた道だな
0222デフォルトの名無しさん2013/10/09(水) 22:45:13.22
だってV8の主流メンバって同じ人でしょ？
0223デフォルトの名無しさん2013/10/09(水) 22:47:12.54
>>217はv8じゃなくてmozillaだろ
0224デフォルトの名無しさん2013/10/09(水) 22:47:30.55
いくらJSでも型が途中で変わる方が稀だしな
JSerが型宣言を嫌うのは厳密性よりもむしろ面倒だから
だから型推論は嫌いじゃない
0225デフォルトの名無しさん2013/10/09(水) 22:49:39.11
>>223
>>220-221に対して言ったまでだしV8も基本は同じです
仮想クラスを仮定したり変数や配列なんかのタイプも仮定してる
0226デフォルトの名無しさん2013/10/09(水) 22:51:06.32
asm.jsみたいなのがJSのあるべき姿じゃね？
0227デフォルトの名無しさん2013/10/09(水) 22:51:09.63
そういう人は型推論付きの関数型言語やるとJSが嫌いになる
ソースは俺
0228デフォルトの名無しさん2013/10/09(水) 22:53:48.75
>>226
asm.js式の最適化方法は汎用化されてエンジンに採用されてきてるよ
まあでも要はこれguardだよね、ES7が入ればやっぱりこのへんは良くなるだろうね
0229デフォルトの名無しさん2013/10/09(水) 22:55:28.08
>>226
あんなの使うならVM作ればいいじゃんって思う
emscriptenのために犠牲になってるとしか思えない
0230デフォルトの名無しさん2013/10/09(水) 22:58:28.07
VM作っても型が動的でであるならば
結局遅いんだけどね。
0231デフォルトの名無しさん2013/10/09(水) 23:00:19.13
何回か書いたことあるけど
一番ダメなのはデバッガの表記が解決に繋がりにくいこと
今手で書くとして一番ダメなのはそこ
あとやっぱり形態がモジュール風というか、
ちょっとasm.js関数１つ作りたい時とかには厳かすぎるね
0232デフォルトの名無しさん2013/10/09(水) 23:02:25.13
asm.jsなんて手書きするもんじゃないと思う
0233デフォルトの名無しさん2013/10/09(水) 23:04:43.45
>>232
ぐう正論
0234デフォルトの名無しさん2013/10/09(水) 23:07:09.89
ES7のguardsって何？パターンマッチの出来損ないみたいなもの？
0235デフォルトの名無しさん2013/10/09(水) 23:08:24.66
>>232,233
それは好奇心を制限するものではないさ
自分はまだ手で各可能性を信じてるよ
ようはlintとデバッガさえまともになれば手で書けるんだからね
0236デフォルトの名無しさん2013/10/09(水) 23:11:08.48
>>234マルチ型付け
つまり変数の型を決定するのではなく、入ってくる型を宣言する仕組み
ようするにガード
0237デフォルトの名無しさん2013/10/09(水) 23:13:58.66
>>236
宣言した以外の型が入ってきたときはどうなるの？
0238デフォルトの名無しさん2013/10/09(水) 23:14:16.94
おれはすでにロジックはC++で書いてemscripten
0239デフォルトの名無しさん2013/10/09(水) 23:22:38.30
>>237当然エラー
多分こんな感じになるんじゃない？
let x :: Number | Boolean = value;
0240デフォルトの名無しさん2013/10/09(水) 23:34:12.80
ES7では特に数値型に関してはリテラルもたくさん入る。
それら同士の演算結果の型がどうなるか次第でだいぶイメージ変わる。
そもそもプリミティブ型になるのかvalue-object型になるのかが不明。
0241デフォルトの名無しさん2013/10/09(水) 23:42:16.48
演算子オーバーロードとValueProxyが入るから
ES7からはどんなものでも自由自在に暗黙の型変換できるし
いくつも新たに定義されるだろう
0242デフォルトの名無しさん2013/10/10(木) 00:56:36.30
Mozillaだけが突っ走ってその他のブラウザが実装し始めるのはずっと先だと思うけどね。
そんな未来は来ない可能性だってある。
0243デフォルトの名無しさん2013/10/10(木) 01:07:35.53
ValueObjectはES6に前身が入ったしES7途中経過報告でもう発表されてるし
ES7の３本柱になることが確実なものよ
ES6で実装する時に手間をかけるからES7への移行はスムーズに行くはず

そこんとこプリミティブ型になったらやっぱり厄介だろうね
だから実装負荷も考えてValueObjectで行くことになると思う
Parallelsも他の仕様と絡みにくいWorkerの糖衣APIみたいなものだから実装は容易
ガードもただ実装するだけなら型チェックの変形版だから容易
0244デフォルトの名無しさん2013/10/10(木) 01:24:19.40
ValueObjectってどのブラウザで使えるの？
0245デフォルトの名無しさん2013/10/10(木) 01:44:20.08
FirefoxでValueObjectのコンストラクタ（？）の前身が使える
int8(123)とかfloat32(123)

今これはただint8やfloat32に揃えられたdouble
Numberプリミティブ型が帰ってくるだけで、
ES6ではStructType({ x: uint32, y: uint32 })
とかして構造体っぽいのを作るために専ら使われるものだけど

ES7ではこれが増えて
int64(123)
bignum(123)
decimal(123)
とかしたときはValueObjectというものが帰ってくる予定

そしてそれらを演算子オーバーロードやValueProxyの技術と合わせることによって
オブジェクト間の演算が可能になって、JSに型を増やせるねってこと
0246デフォルトの名無しさん2013/10/10(木) 01:57:16.84
Haskellの先進性に比べると
JSに追加される機能は
時代遅れのウンコと言わざるをえない
0247デフォルトの名無しさん2013/10/10(木) 01:59:49.12
先進過ぎて誰も付いてこれないんじゃないか？
例えるなら鳩山由紀夫みたいなもんだろう
0248デフォルトの名無しさん2013/10/10(木) 02:08:53.50
そりゃあだって今までは単なるブラウザの上で
ちょこちょこっとHTMLを動かすだけのスクリプトだったんだからね

でもこれからは低レベル、高レベル、スクリプト言語として、大規模開発用言語として
幅広く、深く進化していくよ
ES5移行は本当に多くの言語を参考にして作られてる
確かHaskellもどこかの仕様で見たし、議論でも見たよ
遅いかもしれないけど失敗や出戻りが少なくて済む、
馴染み深いものが入ると思えばいい

特にパフォーマンスに関しては貪欲だよ
初めて言語仕様で最適化を明言しようとしてるし、
マルチスレッド化やSIMD系の型も入る

他にもイベントループとそれを扱う仕組みが言語に組み込まれたり
とにかく見てて毎日飽きない
そこがJavaScriptの一番の良さだと思ってる
完成されきっちゃったら話すこと無くてつまんないじゃん
0249デフォルトの名無しさん2013/10/10(木) 03:08:09.06
平和だなあ
0250デフォルトの名無しさん2013/10/10(木) 03:11:24.08
>>182
>宣言を最初にまとめる方が異端な現状を見ると全く説得力がない

これはそうかなぁ。

function(){
var a = ... ,
　　i = 0, ...

......

for(; i < x; i++)

的なのはよく見るでしょ。書き方のスタイルとして。
0251デフォルトの名無しさん2013/10/10(木) 04:06:30.16
おいおいｗ
それは２０００％ないわｗ
ループ複数書く時詰むだろそれｗ
これの間違いだろ……
（書き慣れてないのがすぐ分かるなオイ（笑））

function(){
var i

......
for(i = 0; i < x; i++)
0252デフォルトの名無しさん2013/10/10(木) 05:44:13.14
2000%無いって、jQueryそのものや関連プラグインはこの書き方多いやん・・・

カウンタの類の初期化まで先頭でまとめてやるのは極端にしても関数の初めの方に
変数宣言をまとめる傾向はJavaScriptでは結構目立つと思う。
0253デフォルトの名無しさん2013/10/10(木) 05:46:12.32
jQueryはその上で変数を使い回す
0254デフォルトの名無しさん2013/10/10(木) 05:51:47.11
傾向と徹底するのはぜんぜん違うだろ……
0255デフォルトの名無しさん2013/10/10(木) 06:02:12.24
jQueryがなんぼのものかは知らんが
自分が信頼できるソースでそんなコーディング使われてるのは見たことがない
https://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/v8natives.js
http://mxr.mozilla.org/mozilla-central/source/js/src/builtin/Array.js
https://github.com/joyent/node/blob/master/src/node.js

ESコミュでも
スーパーマンの書いてるコード適当に見ても
ブログ　http://www.2ality.com/
GITHUB　https://github.com/domenic/promises-unwrapping/blob/master/run-tests.js
見当たらない
0256デフォルトの名無しさん2013/10/10(木) 06:15:20.99
NPMスタイルのセミコロンフリーと同じ
合理性を考えてのものだが異端は異端
でもそれを愛するのは素晴らしいこと
俺もセミコロンフリーで貫いてきてる
0257デフォルトの名無しさん2013/10/10(木) 12:08:03.32
JSでセミコロン無しで書く奴はキチガイ
素直にCoffee使えと
0258デフォルトの名無しさん2013/10/10(木) 12:29:08.52
言語仕様で省略が定義されてるんだから不必要なところで省くのは当然。
Coffeeでもいるときはいる
何も変わらない
0259デフォルトの名無しさん2013/10/10(木) 12:35:25.62
そう言えばコンストラクタをnew無しで呼び出すと
グローバルに変数ができたり誤作動起こすから
JSではインスタンス化にnew使うなっていう派閥があったな
それと同じくらい過度に慎重すぎね？
もちろん付けるスタイルもありだと思うが
付けないからといって基地外はないさ
0260デフォルトの名無しさん2013/10/10(木) 14:50:51.20
jsマンセーしてる奴らは静的関数型なんが触ったこともない低濃どもでしょ？
あんなクソ言語で生産性高いとか片腹痛いわw
0261デフォルトの名無しさん2013/10/10(木) 14:54:21.76
>>260
ダメ日本語が流行りなのか？
0262デフォルトの名無しさん2013/10/10(木) 15:00:47.39
>>260
具体的にpls
0263デフォルトの名無しさん2013/10/10(木) 15:06:02.41
実際のところMozilla以外のES6の実装の現況ってどうなの。
letとconstだけ実装されてその他の機能のサポートはベンダーごとにてんでばらばら
というオチにならない保証ってあるの?
0264デフォルトの名無しさん2013/10/10(木) 16:35:56.56
標準があるのにどうしてバラバラになると思うのか？
１１月くらいがラストコールだから
表立った実装は来年来年からってとこでしょう


V8は近々大きな動きありそうだけど
0265デフォルトの名無しさん2013/10/11(金) 03:58:39.03
jsは標準ライブラリの類が貧弱すぎ
c++にすら負けてるって言語として存在価値なし
0266デフォルトの名無しさん2013/10/11(金) 04:46:26.38
標準ライブラリが多くあるべきかどうかは良し悪しあると思う
特にJSは「スクリプト」なんだから環境に応じた
ホストオブジェクトを提供してもらったほうがとても合理的
基本的なものは揃ってると思うし
0267デフォルトの名無しさん2013/10/11(金) 05:17:19.54
ある程度クロスプラットフォームじゃないと
スクリプト使ってる意味ない気がするが
0268デフォルトの名無しさん2013/10/11(金) 05:23:15.45
共通して必要そうなものはひと通り揃ってると思うが……
0269デフォルトの名無しさん2013/10/11(金) 05:40:57.98
具体的に書いてくれんと困るな
具体的に何が不足してると思うのか
0270デフォルトの名無しさん2013/10/11(金) 05:48:53.69
ライブラリの多い少ない以前にJavaScriptはライブラリをimportする機能が言語仕様に
無いじゃん。ライブラリ毎に手作りしたローダー使うとか<script>タグ使うとかバラバラ。

来年か再来年には解決するらしいが。
0271デフォルトの名無しさん2013/10/11(金) 05:51:57.33
ES6にあるからそれを今言われてもどうとも言い様がないな。
１年待ってね、ってくらいか。
0272デフォルトの名無しさん2013/10/11(金) 06:03:37.25
結局ライブラリとは何だったのか……
0273デフォルトの名無しさん2013/10/11(金) 06:10:48.66
つかえねーなw
0274デフォルトの名無しさん2013/10/11(金) 08:26:16.37
JSに代数的データ型とパターンマッチが入るのは何時ですか？
0275デフォルトの名無しさん2013/10/11(金) 09:06:56.87
>>270
そんなもん、requirejsでとっくに解決してるじゃん。
requirejsでscriptタグで読み込むのを想定したライブラリも使える。

実際にライブラリが使えるのであれば、
ライブラリをインポートする機能の有る無しは問題じゃない。
0276デフォルトの名無しさん2013/10/11(金) 09:19:43.77
requireは今は処理系拡張であって言語仕様にないだろ
標準化してから言えよ
0277デフォルトの名無しさん2013/10/11(金) 09:22:45.03
本当に欲しいのはブラウザの上で動くVMであって、いまjsをそのような使い方してるけどこれじゃない感はあるよね。どうしても無理やりにしたりjsの言語仕様に引っ張られる。
その上でjsが実装されたり他の言語やそれをラップしたJVMやCLRが動いてネイティブの移植が格段に楽になるとかなればいいのに。
その上で皆が実装言語としてjsを使うかは見ものではあるけれど。
各社足並み揃えて作ってくんないかなー
0278デフォルトの名無しさん2013/10/11(金) 10:04:49.21
Scalaでappletを書けないものかね？
0279デフォルトの名無しさん2013/10/11(金) 15:08:05.08
>>274
＞データ型
ES7
＞パターンマッチ
意味が広すぎ

>>276
標準化されてるよ

>>277
何も具体的なことがない長文ご苦労
0280デフォルトの名無しさん2013/10/11(金) 15:15:50.50
>>279
パターンマッチつーたらHaskellやMLにあるやつでしょ
0281デフォルトの名無しさん2013/10/11(金) 15:19:33.49
ていうか、ES7に代数的データ型入るの？どんな感じのコードになるの？

あの文脈でパターンマッチが分からないとかいうし、
イマイチ>>279は分かってない気配がするんだけど…
0282デフォルトの名無しさん2013/10/11(金) 15:26:12.21
それでも意味はかなり広いと思うが
ES6の分割代入やらレストパラメータやら、それこそES7のguardとかじゃないか？
0283デフォルトの名無しさん2013/10/11(金) 15:32:59.91
>>281
すまん寝起きで適当に言ったが、まあJS関数型じゃないから
JSっぽく同じようなことは実現できると思うよ
0284デフォルトの名無しさん2013/10/11(金) 15:42:14.53
何れにしても今は無いし使えるようになるのも再来年かそれ以降だな。
0285デフォルトの名無しさん2013/10/11(金) 15:43:20.21
標準ライブラリが少ないみたいな話は、必要なら多くする必要があるかなって思うけど
もう言語の書き方については、
例えばJSにはクラスがないけど、もっと面白い方法が使えるわけで
そこはJS流で書いてねとしか言えんな
もちろんどう足掻いてもやりにくい、不足してることがあるんなら別だけど

>>284
分割代入云々は既にFFで使えるよ
0286デフォルトの名無しさん2013/10/11(金) 15:53:47.98
そんな特定環境の特定実装の特定用途にしか使えないもの「使える」とは言えん。
「試せる」とでも言っておけ。
0287デフォルトの名無しさん2013/10/11(金) 15:56:24.14
じゃあ試せるよ
0288デフォルトの名無しさん2013/10/11(金) 15:57:50.23
素直で結構。
0289デフォルトの名無しさん2013/10/11(金) 16:17:41.46
Firefox、及びそのOS、及びGMのシェアは特定とは言いがたいほど多いだろ
0290デフォルトの名無しさん2013/10/11(金) 16:33:01.02
JSの場合はいっせーので実装が変わるわけじゃなくて日進月歩
機能もV8に１つメソッドが追加されたね
そういうものだからもっと緩く見て欲しい
0291デフォルトの名無しさん2013/10/11(金) 16:38:18.74
>>289
ブラウザ上での用途に関してはFirefoxの機能拡張およびFirefoxでしか動かないサイトの作成というのは
充分に特定用途だと思うが。

サーバサイドに関してはこればかりは実績が伴わないと意味がない。
「使える」とは例えばストック状態のnode.js等で使えるようになってから言ってほしい。
0292デフォルトの名無しさん2013/10/11(金) 16:49:53.98
あー言えばこー言う
ダメだこりゃ話にならん
0293デフォルトの名無しさん2013/10/11(金) 17:19:28.99
FirefoxでES6の仕様通りに使えるものは「使える」と言っていいと思うけどな
仕様通りじゃないものは「使えない」だけど
マクロとしてのJSって未だにES3相当が多いし
そういうのまでとは一緒にできないというか、
そもそも「JavaScript」っていう名称が
EcmaScript準拠＋環境APIっていうくらいの意味しか持ってないと思う

もちろんES3のポンコツ実装からES7にいきかけてるものまで入り乱れてるのがWebだから
そこを考えると必然的に「使えない」「使えない」となってしまいがちだけど
そんな厳しい環境で話をしなくてもいいと思うんだよね

例えOpenGLES3が使えるAndroid端末が当分は数少ないとしても
そういう技術を話してる時にそれを出して使えないと言うのは違うと思うんだ
それと同じだと思う
0294デフォルトの名無しさん2013/10/11(金) 17:58:27.96
そういうのはJS専用のスレでやれ
違うとか言われても実際使えないなら使わんし
0295デフォルトの名無しさん2013/10/11(金) 18:01:24.32
使える環境があり、使おうと思えば使えるのは「使えない」とは言えません
0296デフォルトの名無しさん2013/10/11(金) 18:05:36.83
あほくさ
Mozilla仕様なんてアドオンぐらいでしか使えないだろ
本当ウェブ界隈は似非プログラマ多いな
0297デフォルトの名無しさん2013/10/11(金) 18:08:31.45
まるで働けるとこがあって働こうと思えば働けるのに
言い訳ばかりで働かないニートのようですね^^
0298デフォルトの名無しさん2013/10/11(金) 18:17:36.14
仕様追いかけてるだけで書ける気になってるニート君は
XULでも書いてりゃいいんじゃない
0299デフォルトの名無しさん2013/10/11(金) 18:19:35.12
仕様追いかけてるだけ？？？
実装もされてて使えるじゃん
何言ってんだこいつ
0300デフォルトの名無しさん2013/10/11(金) 18:31:58.05
そりゃあ実際問題Webでは使いにくいだろうけど
意地になって使えないと言うほどのことでもないのに
なんか相手に自分の意見認めさせたら賞金とかでも出るのか？

ここは潜在能力や可能性を語るスレなんだから
こういうのもあるんだでいいんじゃないかな
何かと文句つけて否定してもメリットがないよ
0301デフォルトの名無しさん2013/10/11(金) 18:46:26.30
可能性だけで言うならHaskellが最強ですね
0302デフォルトの名無しさん2013/10/11(金) 18:57:08.91
requireがjsの言語仕様(ecma)で標準化されてるとか
なんでつまらない嘘つくん
0303デフォルトの名無しさん2013/10/11(金) 19:04:54.48
純粋関数型言語はコア増加の流れと相性がいいと思う
この先コアが数十個、百個ってなっていった時、
超並列時代で活きやすいってのは大きな魅力
でも関数型臭さは良くない点でもあるんだよなあ
0304デフォルトの名無しさん2013/10/11(金) 19:06:55.92
>>302ecmaじゃなくてJavaScript
ecmascriptはあらゆる拡張を許してるから
商標はともかくオレオレ言語仕様を入れてJavaScript仕様とするのは自由
UnityのJavaScriptなんてC#バインドの酷いもんだろ？
0305デフォルトの名無しさん2013/10/11(金) 19:25:27.38
JavaScriptが何なのか
それは使ってる人によって全然違うと思う
例え同じV8でもNodeとChromeじゃ書き用が違う
やっぱり標準入出力を持たないESはスクリプト言語であって
環境と合わせて初めて言語といえるんだと思うんだよね
そんな中このスレであえて話題にできる一番しっかりしたものって言うと
勧告間近のES6draftについてじゃなかろうか
もしこのスレで鋭いアドバイスが出たらESコミュに挙げてもいいし
使える使えないの話をするより、どんな仕様や技術がいいのか話すのは
思った以上に有意義なことだと思うよ
0306デフォルトの名無しさん2013/10/11(金) 19:31:17.21
UnityのJSはJSerなら絶対JSと認めないJS
0307デフォルトの名無しさん2013/10/11(金) 19:45:01.23
>>304
どのオレオレJavaScriptで仕様化されているのrequireは
0308デフォルトの名無しさん2013/10/11(金) 19:46:24.65
ジョークにマジレス？！
0309デフォルトの名無しさん2013/10/11(金) 19:53:58.32
都合の悪い発言はジョークとか釣りってことにして有耶無耶にします
0310デフォルトの名無しさん2013/10/11(金) 19:55:01.87
そんな事よりrequireが標準化されてるソースまだー？
0311デフォルトの名無しさん2013/10/11(金) 19:55:55.53
アスペ乙
0312デフォルトの名無しさん2013/10/11(金) 19:57:44.24
相手の言いたいことを察する能力に欠けてる
アスペ可愛く言うとKYです
0313デフォルトの名無しさん2013/10/11(金) 19:59:20.36
アスペってことにして終わりにしたいんですか？
なんでrequireが標準化されてるなんてぶっこいちゃったの？
これだけでまともに触ってないのバレバレじゃん
0314デフォルトの名無しさん2013/10/11(金) 20:02:11.39
誰がそんなこと言ったんだ？
またお得意の被害妄想か！
0315デフォルトの名無しさん2013/10/11(金) 20:05:47.67
でっち上げは玄人()プログラマの得意技だからな
0316デフォルトの名無しさん2013/10/11(金) 20:07:34.68
なんだかんだ言って、あちらこちらで話題になるJavaScriptは凄いと思う
他の言語は一瞬話題に上がってもすぐ途切れちゃうもんね
特に静的型言語はそういう傾向があるように見える
活発なLL人に比べてなんかもう皆冷めてるというか悟ってるイメージ
0317デフォルトの名無しさん2013/10/11(金) 20:14:33.31
>>276
＞標準化されてるよ
本当に話し逸らして何とかなると思ってるの
標準化のソースまだー？ﾏﾁｸﾀﾋﾞﾚﾀﾖ
0318デフォルトの名無しさん2013/10/11(金) 20:19:02.57
もしかして>>279か？
ちゃんとアンカ付けてくれないと誰に愚痴ってるのか分からなくて困惑するんだけど…
0319デフォルトの名無しさん2013/10/11(金) 20:19:58.16
>>318
おっとごめんよ>>279だ
0320デフォルトの名無しさん2013/10/11(金) 20:24:48.59
JSが興味深いから話題になってるんじゃなくて、
JSerが直ぐバレるテキトーな嘘かますから炎上してるだけじゃね？
0321デフォルトの名無しさん2013/10/11(金) 20:45:05.25
>>319
もうしわけない
>>283の通り適当に書いてしまった
どうか許してくれ
0322デフォルトの名無しさん2013/10/11(金) 20:59:43.92
>>321
まともに会話する気がある人の時点で許すよ
心から許すよ
0323デフォルトの名無しさん2013/10/11(金) 21:26:42.03
たまには文句言う前に作ったら？
0324デフォルトの名無しさん2013/10/11(金) 21:46:14.97
JSerの奴らはIEの介護で憔悴しきってるんだからちょっとは夢を見させてやれ
0325デフォルトの名無しさん2013/10/11(金) 22:03:27.98
JS使いの屁理屈っぽさはウェブ系って感じがするよね。
メガネかけてるんだろなあ。
自分で自分のことオサレって思ってる感じがオシャレじゃないねって感じ。
わかる？
0326デフォルトの名無しさん2013/10/11(金) 22:11:15.60
オシャレだからJSやってますとかJSやってるからオシャレだなんて思ってる人はそうそういないと思うよ。
そんなに新しい言語でもないし古臭さも残ってることは残ってるし、
今や定番になってきたけどちょっと前の頃のC#とかobjective-Cがまさにそんな感じじゃない？
JSは「楽しい」んだと思う、もちろん周りの環境、HTML5ムードも合わせて、凄く素敵でやりがいがある。
0327デフォルトの名無しさん2013/10/11(金) 22:13:44.71
うん屁理屈っぽい。
メガネ。
0328デフォルトの名無しさん2013/10/11(金) 22:15:58.48
実際に楽しんでることをメガネって言われても困るな
別に生きとし生けるもの全てがJSが好きになれるとは言わないよ
0329デフォルトの名無しさん2013/10/11(金) 22:19:45.94
でもさ、メガネじゃない眼鏡だって言われてもJS使いなら納得じゃない？
そんな感じしない？
0330デフォルトの名無しさん2013/10/11(金) 22:21:13.22
別にJSerは他の言語を否定したり俺が一番だなんて言ってないんだよなぁ
0331デフォルトの名無しさん2013/10/11(金) 22:22:21.34
JSerは純粋だよ
ここでもJSをフォローして熱を伝えようとしてるだけ
0332デフォルトの名無しさん2013/10/11(金) 22:25:29.64
JSerの発言は20年C言語やってる俺からしたら全て子供の戯言レベル
0333デフォルトの名無しさん2013/10/11(金) 22:25:47.00
関数型の便利さがわからない。
どこがどう便利なのかさっぱり。
もしかして不便になってない？
0334デフォルトの名無しさん2013/10/11(金) 22:30:39.78
制約を儲けることは都合が良くもあり悪くもある
何を取るかという話
何も考えずに見たら当然使いにくいものでしか無い
しっかり考えて関数型がいいな、今回はこれを使おうってなった時に
初めて進化を発揮する
0335デフォルトの名無しさん2013/10/11(金) 22:35:43.24
そうだな
このスレが話が進まないのは言語を限定してないからだ

静的型付け言語っていうのが既存のものなのか
将来生まれる言語を指してるのかもわからない
0336デフォルトの名無しさん2013/10/11(金) 22:48:27.74
>>300
みんなで小銭出し合って賞金用意しない？
それよくない？
0337デフォルトの名無しさん2013/10/11(金) 22:54:11.92
BitCoinならいいよ
0338デフォルトの名無しさん2013/10/12(土) 00:02:26.25
型宣言でも型注釈でもガードでも何でも良いけれども、オプショナルな型付けが追加された
ばあい型付きと形無しどちらのスタイルで書くのがメインになるんだろうね。

JavaScriptに似た言語の事例だとActionScriptが2から3でオプショナルな片付けに以降した
例があるけれども、この場合最終的には型付きできっちり書く人が多かった気がする。
どっちかというとFlex使ったRIA向け関連を見てきたというのもあるけど。
0339デフォルトの名無しさん2013/10/12(土) 00:15:00.40
それはエンジンによる
エンジンの最適化に役立つならそういう場面で書くよ

型の安全性の為にはどうしようかなあ
今まで数値型と文字列型でハマるのは大きなプロジェクトで１回はあって最大限に厄介な部類だけど
普段から付ける手間よりはバグ対処のほうがいいかも
0340デフォルトの名無しさん2013/10/12(土) 00:27:09.07
型注釈入ろうが変わらないだろうな
元からプリミティブよりObjectのチェックコードのが多いだろうし
0341デフォルトの名無しさん2013/10/12(土) 00:29:33.71
asm.jsの威力見るとどうだろうか。
0342デフォルトの名無しさん2013/10/12(土) 01:43:10.38
これから先、当分はtypescriptが主流になると思う
jsの代替っていくつかあるけど、一番筋がいいと思う
0343デフォルトの名無しさん2013/10/12(土) 01:47:49.08
AS2->AS3の事例で言えば単純にFlexその他のAS3向けのライブラリがかっちり型付きで提供されて
いたのと、メソッドのシグネチャを中心に型が決まっている場所では型注釈付けた方がその後も
FlexBuilder上で補完がビシバシ効いて自分が楽が出来るので型注釈付けた方が結果的に楽だった
という事情がある。型書くこと自体は補完も効いて全然手間じゃない。

型無しでやりたい場面は型無しでやれば良いし。
0344デフォルトの名無しさん2013/10/12(土) 01:51:21.06
action scriptは、デザイナーが書くか、プログラマーが書くかで違ってたろう
プログラマーなら当然型を指定した方が書きやすい
0345デフォルトの名無しさん2013/10/12(土) 02:00:07.30
AS3はコンパイル言語だけどJavaScriptは違う
そこはやっぱり大きいよ
0346デフォルトの名無しさん2013/10/12(土) 02:02:12.17
何が大きいのかは答えられんけどね。

とにかく大っきんだ
0347デフォルトの名無しさん2013/10/12(土) 02:08:21.72
コンパイル言語は一々実行させて上手く動いてるか確認するような非効率なことはしない
なるべく多く実行時以前に問題になりそうな箇所を潰そうとするけど
JSは取り敢えず動かしてみて必要なら実行させながら値を確認するデバッグでやってきたし
自分もその一人だけどそれで十分だと思ってる人も多いんじゃないかな
手間暇の問題での話ね
0348デフォルトの名無しさん2013/10/12(土) 02:13:06.53
つまりJSerの性質が大きいってことだな
うーむ、、、
でもなあ、初心者本やサイトに載るかなあ
オプションである限り大抵は応用、発展として先送りされると思うんだよね
やっぱり難しく見えるのもあるし
そうすると積極的に使うようにはならないんじゃないかな
0349デフォルトの名無しさん2013/10/12(土) 02:15:37.03
>>344
補完が効きやすいのはわかるけど、他に書きやすさってあるの？
0350デフォルトの名無しさん2013/10/12(土) 02:16:28.70
補完よりも、影響範囲の把握の方が重要だけどな。
0351デフォルトの名無しさん2013/10/12(土) 02:22:15.31
影響範囲か……イメージ不可能
0352デフォルトの名無しさん2013/10/12(土) 02:39:55.49
影響範囲って何？
実装者は使用者が実装の内部は全く気にせずにいいような実装をして
それを使用者が使って実装をするの繰り返しで物ができるものじゃ？
0353デフォルトの名無しさん2013/10/12(土) 02:41:58.77
>>352
コードを修正した時、
その修正の影響が及ぼす範囲を
知ることが出来るかどうか。
0354デフォルトの名無しさん2013/10/12(土) 02:47:11.94
クラスを変更するとき
そのインスタンスがどこで使われてるか分かるってこと？
0355デフォルトの名無しさん2013/10/12(土) 02:49:41.61
それもわかるし、
メソッドを変えてもわかる。

たまたま同じ名前なのか？
などと調べる必要もない。

これらはコードが大きくなればなるほど
開発時間に直結してくる。
0356デフォルトの名無しさん2013/10/12(土) 02:53:16.00
そういうことを徹底していくとダックタイピングとかいう芸当とは合わないよね？
0357デフォルトの名無しさん2013/10/12(土) 02:54:59.47
多くの場合、ダックタイピングは
ダックタイピングする必要があるからしているのではなく、
ダックタイピングになってしまうというだけ
実際にはダックタイピングの必要性はかなり低い。
0358デフォルトの名無しさん2013/10/12(土) 02:57:59.53
でもJSの標準メソッドとかの多くはクラスを確認しないから
ダックタイピングによく利用されてそれが問題解決を優しくしてることもあるよ
例えばDOMなんかの配列もどきに配列のメソッドを適用したい時とか
0359デフォルトの名無しさん2013/10/12(土) 03:27:29.10
JSにそもそもクラスの概念は無い
オブジェクトが何を継承するか決めるのはプロトタイプオブジェクト
0360デフォルトの名無しさん2013/10/12(土) 04:43:01.40
確かに……
根本的にモデルが違う、というかクラスなんて無いし要らないのか
0361デフォルトの名無しさん2013/10/12(土) 04:59:38.42
動いている途中でtypoとか想定いない値が入ってエラーになって止まる場合、
ファイルやデータが削除したり、書き換わったりで元の状態に戻せないから
仕方なくダックタイピングってのも珍しくないからな。 コンパイラだとそういう
凡ミスを早い段階で潰してくれるからねぇ。凡ミスなんてしょっちゅうするでしょ？
0362デフォルトの名無しさん2013/10/12(土) 05:10:30.85
話のつながりが分からんｗ
しっかり書いてくれｗ
0363デフォルトの名無しさん2013/10/12(土) 06:37:41.05
そういうこと言ってると、例の勘違いJSマンセーくんが
JSでもクラスプログラミングできるもん
とかいいだすぞ…
0364デフォルトの名無しさん2013/10/12(土) 06:38:53.98
>>361はダックタイピングがまるでわかってないな
0365デフォルトの名無しさん2013/10/12(土) 07:53:04.62
そもそも動的言語は実行時のコンテキストとコーディングの手軽さ重視だから
真面目に制御しようとしたら煩わしくなるのは当たり前だわな
0366デフォルトの名無しさん2013/10/12(土) 08:03:03.47
コンパイラ言語ではダックタイピングできないとか思い込んでるアホがいる？
0367デフォルトの名無しさん2013/10/12(土) 08:28:57.08
☓ ダックタイピングできるから便利
○ いいかげんArray.prototype.slice.callの代わりぐらい用意しろボケ
0368デフォルトの名無しさん2013/10/12(土) 10:15:10.41
>>366
文句なく出来るのはOCamlくらい？
Scalaは実行速度にデメリットあるらしいし、C++は記述がメンドイ
0369デフォルトの名無しさん2013/10/12(土) 10:17:18.10
OCamlのは構造部分型。ダックタイピングとは全く別物。
0370デフォルトの名無しさん2013/10/12(土) 10:33:11.08
構造的部分型と別物と言えるほど、厳密な定義がダックタイピングにあるの？
0371デフォルトの名無しさん2013/10/12(土) 10:39:49.66
構造部分型は静的型付けなのだから
ダックタイピングとは完全に別物
0372デフォルトの名無しさん2013/10/12(土) 10:44:25.85
JavaScriptのダックタイピングなどと一緒にされてはOCamlが不憫だ。
0373デフォルトの名無しさん2013/10/12(土) 11:26:01.43
>>366はぱっと見smalltalkの話だと思うが、
なんでOCamlだと思ったんだろうな
あの強力な型を持つOCamlで特定オブジェクトのメソッド入れ替えとかできるのか？
0374デフォルトの名無しさん2013/10/12(土) 11:31:52.41
>>373
＞あの強力な型を持つOCamlで特定オブジェクトのメソッド入れ替えとかできるのか？

特定オブジェクトのメソッド入れ替えがダックタイピングに必要なの？
0375デフォルトの名無しさん2013/10/12(土) 11:37:29.95
>>371
ダックタイピングは動的型付けじゃなきゃダメなの？何で？
0376デフォルトの名無しさん2013/10/12(土) 11:42:16.16
構造的部分型はダックタイピングで出来る事は
全て出来るが、その上で静的型チェックも
やってくれる優れものなので、
定義上区別される
0377デフォルトの名無しさん2013/10/12(土) 12:14:08.04
>>374
ダックタイピングはクラス(型)じゃなくてインスタンスにかかるからダメだろう
逆に言えばインスタンス別への動的変更ができない処理系じゃ
型の構造見てるのとかわらないから構造的部分型と同じだろうね
0378デフォルトの名無しさん2013/10/12(土) 12:19:54.42
静的型付けでもダックタイピングは可能。
だけど、ダックタイピングを使った場所は
静的型付けのメリットが少なくなる。

で、そもそもの話をすると
ダックタイピングが本当に必要な場所ってのは少ない。
だから、本当に必要な場所のみに使うというのが正しい使い方。

ほんの少しの場所のために、全体をダックタイピングにするなんて愚かでしかない。
0379デフォルトの名無しさん2013/10/12(土) 12:26:49.87
いやいや静的型付だけで純粋なダックタイピングは無理だろうよ
言語が静的型だろうと型の決まらないオブジェクトの扱いは動的型だから
0380デフォルトの名無しさん2013/10/12(土) 12:31:05.84
純粋なダックタイピングってなんだ？
0381デフォルトの名無しさん2013/10/12(土) 14:53:45.89
>>378
俺もそう思うわ
ダックタイピングなんてしないに越したことはない
仕方なくそうする
0382デフォルトの名無しさん2013/10/12(土) 15:16:50.89
低能がわめいておるわ
0383デフォルトの名無しさん2013/10/12(土) 15:20:16.65
ダッタイなんてDBとかXMLの構造をフレキシブルにしたままで扱えるっていう
ただいってんだけだろ
0384デフォルトの名無しさん2013/10/12(土) 16:13:25.68
クラスベースと合わないっていうのもあるんじゃない？
>>367
あるよ
あるけど配列っぽいのを配列に治すって時点でどうもね
0385デフォルトの名無しさん2013/10/12(土) 16:29:38.19
ほぼ全ての仕組みがオブジェクトで成り立ってるし
クラスもないし暗黙の型変換が多用されるJavaScriptで
あえてダックタイピングを禁止して無理やりクラスベースっぽく
こだわるのがいつも得策とはとても思えん
0386デフォルトの名無しさん2013/10/12(土) 16:34:45.40
>>385
なるほどケースバイケースであると、しかし、B型のお前としては
ケースバイケースというどっちつかずの玉虫色の答えを出すのも
気に入らぬ、そういうことだな？
0387デフォルトの名無しさん2013/10/12(土) 16:42:41.36
いや違う
はっきり言いたいことを言わせてもらえば
JavaScriptは自由な言語だと思ってる
これまでもいろんな時代があったけど
色んな人が自由に使ってきた

そして今、まあ当たり前の存在へと昇華するには
デザインパターンやらそういうお決まりを決めなきゃいけないものなんだろうが
それでもバッドパーツとか言ってJavaっぽく書かせたり
もしくはJavaっぽさを捨てようとか、いやいや関数型をtwっていすべきとか

自分はとにかく好きに書いていいよっていう言語であって欲しい
だから、原則これはこうみたいなのはやめて欲しい
言語機能を好きなだけフルに使って書かせて欲しい

大規模開発現場でルールを決めるのはいいけど
きほんは個人用のスクリプト言語としてフリーであり続けて欲しい
あとはやっぱりせっかくのプロトタイプベースとか忘れずに活かして欲しい
0388デフォルトの名無しさん2013/10/12(土) 16:43:51.06
>>387
ああ、うん。
他の言語でも同じだから。

違う！っていうのなら、それはお前の思い込み。
0389デフォルトの名無しさん2013/10/12(土) 16:48:37.23
>>388何が言いたいのかよく分からん
0390デフォルトの名無しさん2013/10/12(土) 16:51:52.04
>>388の目にはJavaScriptの
「自由さ」
「本来のオブジェクトモデルのシンプルさ」
がJavaの
「ブルーカラー統制向き」
「根本的な面倒臭さ」
と区別つかないのだろう。
0391デフォルトの名無しさん2013/10/12(土) 16:56:22.21
>>384
slice以外の方法あるの？
ES6とかMozillaのArray.fromとか言ったらぶっ飛ばすぞ
0392デフォルトの名無しさん2013/10/12(土) 17:02:05.59
当然Array.fromだろ
なんでES7のguardの話は織り込み済みでES6のArray.fromはダメなんだよｗ
0393デフォルトの名無しさん2013/10/12(土) 17:03:15.84
いま>>391はぶっ飛ばすために全力疾走してます
0394デフォルトの名無しさん2013/10/12(土) 17:05:59.64
>>392
今JSって言えばHTML5かnodeだろ
なんで普及もしてない限定環境の話してんだよ
0395デフォルトの名無しさん2013/10/12(土) 17:07:29.30
>>390
JavaScriptの自由さｗｗｗ

笑うところですか？

ほんとうの自由とは
マイナーな言語を使って
飯を食ってる人のことですよ？
0396デフォルトの名無しさん2013/10/12(土) 17:13:32.02
>>394
今>>338からの流れの話なのがわからない？
JSにそういうのが追加されたときの話をしてるんだから
当然Array.fromは使えるに決まってるじゃん
アホなの？
0397デフォルトの名無しさん2013/10/12(土) 17:13:50.58
とりあえずポエムは抜きで頼む。
キラキラした目で「JavaScriptは自由な言語っ・・・!」とか語られても他の人はひくだけだから。
0398デフォルトの名無しさん2013/10/12(土) 17:17:23.50
言語の雰囲気は重要だと思うが
0399デフォルトの名無しさん2013/10/12(土) 17:27:59.52
>>398
お前さんも>>338からの流れを読みなさい。

「ダックタイピングなんてしないに越したことはない」なんて話をしているところに
具体的な話もないそんなポエムを持ち出してもハァ? だ。
0400デフォルトの名無しさん2013/10/12(土) 17:32:45.73
>>399
このコーディングスタイルが適切かじゃなくて
実際にそうするようになるだろうかの話なんだから
JSerの性質>>348は大事なポイントじゃないか？
0401デフォルトの名無しさん2013/10/12(土) 17:41:13.55
馬鹿な屁理屈はもう聞き飽きた…
0402デフォルトの名無しさん2013/10/12(土) 17:46:17.09
文化の分裂が起こるかもね。

型付きできっちり書く貴族とあくまで型無しにこだわるボヘミアン。

そしてそんな空中戦はよそに「ECMAScript7なんて絶対ﾑﾘwww Part22」なんてスレも
更新を重ね、大多数のユーザーにとっては単に言語機能やライブラリで用意された
便利なイディオムを反復するだけなので今とたいして変わらん。
0403デフォルトの名無しさん2013/10/12(土) 17:51:45.29
どういう人が型付で書くようになると思う？
静的から来た人はそうしたがるかもしれないけど
自分自身は全てには付けないと思う
型宣言じゃなくてguardだってとこも多少あるけど

１つ検討がつきにくいのは入門者だなあ
言語仕様が肥大化した時どのように教えられて育つようになるんだろう
0404デフォルトの名無しさん2013/10/12(土) 18:01:54.61
今まで見てきたものでいうと
「初めての○○」なのに浅く広く言語仕様を網羅したようなものばかりが出るようになる
そして新規入門者が遠のいて言語が少子高齢化状態になる
そしたらさらに入門者の気持ちがわかるピュアな人が減ってやがては廃れる
0405デフォルトの名無しさん2013/10/12(土) 18:05:44.84
でかいもの。企業が提供するライブラリ。フレームワークの類。
この辺りからずんずん型付きが増える。

メタプログラミング的なことをするものを除いて再利用を目的に開発される物は
型付きが優位になる。
型情報なんて仕様書の一部なので結局どこかに書かないといけないし。
0406デフォルトの名無しさん2013/10/12(土) 18:06:13.15
その廃れていった具体例が○○言語だ

↓あとよろしく
0407デフォルトの名無しさん2013/10/12(土) 18:09:51.33
guardを型付きって呼んでいいのか…
なんか違和感がある
0408デフォルトの名無しさん2013/10/12(土) 18:10:44.98
C言語ですね、分かります
0409デフォルトの名無しさん2013/10/12(土) 18:14:15.86
じゃあガード付きで良いよ。
0410デフォルトの名無しさん2013/10/12(土) 18:18:43.94
彼女が私のボディーガードだ。
0411デフォルトの名無しさん2013/10/12(土) 18:24:48.90
そもそもguardで>>355静的に解析できるもんなのかね？
myGuard = Type.make(guard1, guard2, ...)
var a :: myGuard
みたいなこともできる型宣言と比べ物にならないほど動的なものだし
0412デフォルトの名無しさん2013/10/12(土) 19:01:32.84
クラスの件もそうだけどJSに無理やり当てはめようとしても
上手くいかないことなんて分かりきってるから
諦めてJSはJSとして気持ちを切り替えて使っていくしか無いだろうな
0413デフォルトの名無しさん2013/10/12(土) 19:04:37.63
南米系は全員マリオだよね？
0414デフォルトの名無しさん2013/10/12(土) 19:06:54.37
YES WE ARE.
0415デフォルトの名無しさん2013/10/12(土) 19:13:49.89
実際のところガードってどの程度実現可能性があるの。
MSとかAppleとかGoogleはどの程度コミットメントしていてコンセンサスがとれてるの。
0416デフォルトの名無しさん2013/10/12(土) 19:18:13.08
このスレはhoge禁止ですか？
0417デフォルトの名無しさん2013/10/12(土) 19:22:38.63
現状積極的に議論されてないので何とも言えないが、
他の仕様と矛盾しないし後方互換性も取れるし
やっぱり何らかの型の仕組みを入れたいだろうから
わざわざ否定する人は少ないと思われる
もっといいのが出るか問題がなければ順当に入るんじゃないかな

まあValueObjectよりは下、Parallelsとどっこいくらいのイメージ
0418デフォルトの名無しさん2013/10/12(土) 19:32:05.72
全く新しい試みだから多分長い時間がかかると思うよ
class構文って10年も話し合われてきてprivateの辺りとかようやく最近まとまってきたでしょ
0419デフォルトの名無しさん2013/10/12(土) 19:44:29.39
ガードって何？
0420デフォルトの名無しさん2013/10/12(土) 19:53:53.01
パターンマッチをショボくしたやつ
0421デフォルトの名無しさん2013/10/12(土) 19:57:47.75
それが何で騒がれてるの？
switch文とどう違うの？
0422デフォルトの名無しさん2013/10/12(土) 20:00:45.16
騒がれてない
0423デフォルトの名無しさん2013/10/12(土) 20:03:30.92
ガードで飛躍する人類の未来とか語ってなかったっけ？
0424デフォルトの名無しさん2013/10/12(土) 20:08:27.52
チョットおかしい人の声が大きいのは
よくある事
0425デフォルトの名無しさん2013/10/12(土) 20:22:56.53
普及は少なくとも2010年代後半ひょっとすると2020年代初頭と言ったところか > ガード。
未来技術だなぁ。
0426デフォルトの名無しさん2013/10/12(土) 20:32:06.07
2週くらい周回遅れしてるJSに相応しい機能
0427デフォルトの名無しさん2013/10/12(土) 20:34:52.28
なんでそんな酷いこと言われないといけないのか分からん
0428デフォルトの名無しさん2013/10/12(土) 20:39:30.06
とりあえずF# to javascriptのツールが使い物になりそうなのでな どうでも良い
0429デフォルトの名無しさん2013/10/12(土) 21:00:42.82
意欲的な言語機能云々よりまずテンプレート文字列をちゃんと各社横並びで使えるようにして欲しい。
ちょい書きスクリプト言語として使うのにこれが使えないのは普通に不便。
0430デフォルトの名無しさん2013/10/12(土) 21:19:21.15
javascriptって人間にも解読可能な中間言語でしょ。
C++やJavaなどから変換出力してライブラリはブラウザ互換の物を使う。
0431デフォルトの名無しさん2013/10/12(土) 21:20:10.93
>>428
FunScriptのことならたぶん使ってるうちにガッカリする
簡単にFFI書けるFay-langのがまだマシ
jsのゆるゆる仕様に静的関数型が合わせるのは無理だと悟った
0432デフォルトの名無しさん2013/10/12(土) 21:33:04.35
>>429
後1年ES6まで待ってね
0433デフォルトの名無しさん2013/10/12(土) 22:01:12.67
再来年以降の間違いでしょ。
ES6なんて待っていない。必要な機能を実装したブラウザが広く行き渡るのを待っている。
0434デフォルトの名無しさん2013/10/12(土) 22:37:01.63
いつまでも夢見てろよ
そのまま起きるなｗ
0435デフォルトの名無しさん2013/10/12(土) 22:45:39.35
pcはともかく、Androidやiosは古いバージョンが相当先まで生き残るだろうな
0436デフォルトの名無しさん2013/10/12(土) 22:50:58.92
Android4以降なら大抵Chromeも一緒に載ってる
0437デフォルトの名無しさん2013/10/12(土) 22:56:56.53
スマホはバージョンアップもあるし端末の寿命長くないと思う
当面の問題はVistaのIE9だと思う
IE12だか13だかES6をサポートしてくれるIEがwin7をサポートしてくれるとすれば
Vistaが息絶えた時がES6の始まり
0438デフォルトの名無しさん2013/10/12(土) 23:10:30.18
ES5が気兼ねなく使えるのはXPが死ぬそろそろだろう？
だったらES6が使えるのは時期的にES7の勧告があるくらいだろうな
0439デフォルトの名無しさん2013/10/12(土) 23:17:47.66
>>438
サーバー側ならもっと速く使えるよ。
ブラウザが問題であって
ブラウザを使わない環境であれば、
他の言語と同じだからね。
0440デフォルトの名無しさん2013/10/12(土) 23:38:24.46
んなことは分かってるが認めないとイチャモンつける奴がいるから仕方ないだろ
0441デフォルトの名無しさん2013/10/13(日) 00:09:34.25
老人の面倒を見ないといけないのも若者の務め
0442デフォルトの名無しさん2013/10/13(日) 00:11:07.53
なぜJavascriptが嫌われているのかやっとわかった。
もし俺がLinuxについて今まで触れていたならLinuxが嫌われていただろう。
触れなくてよかった。

今初めてスレタイを見て分かった。
0443デフォルトの名無しさん2013/10/13(日) 00:15:40.48
Linuxｗｗｗとか意味わからんがｗｗｗ
このスレで特定言語、特にLL推せば荒れるに決まってんぞｗ
0444デフォルトの名無しさん2013/10/13(日) 00:30:46.59
>>431
いやWebSharperの方。FunScriptも試したが既存のソース読み込ませたらイミフなコンパイルエラー出てダメだった。
WebSharperはエラー出ても理由とかがわかりやすいし既存のソースもほぼ改変なくいけた。
0445デフォルトの名無しさん2013/10/13(日) 00:38:48.76
北京オリンピックやったばかりなのに次は東京オリンピックやるんだってね。
最近勢いあるね中国。
0446デフォルトの名無しさん2013/10/13(日) 00:39:59.20
>>445
トンキンｗｗｗ
0447デフォルトの名無しさん2013/10/13(日) 03:33:36.21
>>439
>サーバー側ならもっと速く使えるよ。
もうES6使えてるの？
0448デフォルトの名無しさん2013/10/13(日) 04:02:13.69
いくらかね
ほんとに日進月歩で今日はメソッドが１つ増えたー
とかの積み重ねだからねES6は
一気に変わるのはIEくらいのものでしょう
0449デフォルトの名無しさん2013/10/13(日) 04:21:41.37
これはかなりすごい。
目からうろこ。

http://www.youtube.com/watch?v=6p95-kRxF_E
0450デフォルトの名無しさん2013/10/13(日) 04:24:11.02
>>449を見なくてもいいように説明

ジュースの自動販売機で当たりを出す方法【裏技？】

結局外れで、ブラックのコーヒーがでてきて
そんなに甘くないと言いたかっただけ。
0451デフォルトの名無しさん2013/10/13(日) 04:51:25.31
キチガイ増えたな・・
0452デフォルトの名無しさん2013/10/13(日) 08:39:07.10
Ubuntuの新しいバージョンが発表になった
0453デフォルトの名無しさん2013/10/13(日) 10:53:34.88
pcの場合、ブラウザを変えるのも比較的容易だがスマートフォンの場合はそうは行かない
iphone4以前は当分使われ続けるだろう
0454デフォルトの名無しさん2013/10/13(日) 14:27:24.02
逆だと思う
スマホは５年も１０年も使われないが
IEは使われる
0455デフォルトの名無しさん2013/10/13(日) 16:26:03.35
それはないな。
WindowsはLinuxに駆逐されるから。
0456デフォルトの名無しさん2013/10/13(日) 16:46:15.52
そうかもしれないがそれはVista終了には間に合わないな
一応最低ラインではあと５年くらいIE9を見なければならないのは確かだろう
まあ実際はHTML5との兼ね合いでそこまで長くはないだろうが

３年後とするとAndroidではChromeが載ってると思って良くなる
iPhoneもOS更新率が高いからAndroidと比べてそこまで状況は酷くはないだろう
0457デフォルトの名無しさん2013/10/13(日) 17:17:47.55
ところで既定の検索プロバイダをとうとうBingに変更した。
さようならGoogle。
あなたの作ろうとする未来には乗れません。
0458デフォルトの名無しさん2013/10/13(日) 17:28:26.19
MSが作ろうとしている未来には乗るわけかw
0459デフォルトの名無しさん2013/10/13(日) 17:49:04.83
http://www.youtube.com/watch?v=XiqgmAYrd3c
0460デフォルトの名無しさん2013/10/13(日) 18:13:34.77
メリンダさんとゲイツ氏が人々のためにYoutubeを買い取ってくれればなあ。
0461デフォルトの名無しさん2013/10/13(日) 19:48:31.72
>>460
MSも動画サイト作っただろ
0462デフォルトの名無しさん2013/10/13(日) 20:26:50.64
マイクロソフトは人々のために良いものを無償提供すると言えないでしょ。

Googleは対価を求めず人々によいものを提供する。
本来高価なサービスを無償で提供する。
この取り組みにあなたも貢献できる。
貢献すれば人々からあなた自身の価値を認められる。
何かいいことあるかもよ？
使うだけでも貢献しています。

こういう幻想を抱かせることができないと、CGMはうまくいかない。
つまり、基本的に嘘がつけない人には無理。
0463デフォルトの名無しさん2013/10/13(日) 20:31:46.83
あなたの貢献は確かに小さなものかもしれない。
サービスを消費しているにすぎないのだから。
しかし、その小さな貢献がいくつも集まることで、世界をより豊かにするのです。

こういった、あなたがサービスを利用することで社会正義のために役立つ的な
正しいことをしていると納得できる説明も必要なんじゃないかな。
宣伝マンってある種の宗教性があるでしょ。
それで信者と呼ばれたりする。
0464デフォルトの名無しさん2013/10/13(日) 20:37:02.99
マイクロソフトは営利企業にすぎないので、Googleのような社会正義実現を
目指す団体にCGMで勝つことはできない。

これは漠然とした理論のようだけど、たいていのことは計算通りにしか
ならないので、必ずそうなると思う。

良いことをしてると納得させることができないといけない。
サービスが成功して、化けの皮がはがれてきたとしても、悪いことに加担していない
と思わせないと。
その時には、利用者も被害者の一員だと思わせることで、CGMを継続できる。
0465デフォルトの名無しさん2013/10/13(日) 22:15:06.42
Googleってニコニコにすら勝ててないじゃん
0466デフォルトの名無しさん2013/10/13(日) 23:28:07.65
>>462-464
これ同じ人？
Googleが慈善団体なのとでも思ってるん？
0467デフォルトの名無しさん2013/10/13(日) 23:51:04.73
>>466
「教祖になる本」でも読んだんだろ。
0468デフォルトの名無しさん2013/10/13(日) 23:51:58.73
国家を真面目に作ろうとしてるくらいだから単なる営利企業ではないな
自愛団体かもしれんｗ
0469デフォルトの名無しさん2013/10/14(月) 15:16:32.98
JSに変換できる言語処理系で、一番出来の良いヤツを教えてください
なお、TypeScriptは試してみたのですがJS臭が強過ぎてダメでした
0470デフォルトの名無しさん2013/10/14(月) 15:26:37.99
CoffeeScriptやHaxe
0471デフォルトの名無しさん2013/10/14(月) 15:42:53.04
>>469
仕様変更に耐えられるならLiveScriptお勧め
0472デフォルトの名無しさん2013/10/14(月) 16:32:59.50
TSが嫌なら素直にes6ifyでも使っとけ
0473デフォルトの名無しさん2013/10/14(月) 18:14:52.59
えー？なんでそんなウンコ使わなきゃならんの？
0474デフォルトの名無しさん2013/10/14(月) 18:45:23.96
PCはXP世代のマシンでもChromeやFirefoxを使えるけど、スマートフォンは取り残されるからな
GoogleがWebkitから分裂してスマートフォンのブラウザの断片化が進む
0475デフォルトの名無しさん2013/10/14(月) 20:10:35.23
皆がChrome使ってくれるんなら苦労はしないんだけど
0476デフォルトの名無しさん2013/10/14(月) 22:24:50.49
Perl, Ruby, PythonあたりがJSにコンパイル出来れば
JSにまつわる不毛な論争の7割が減る気がする
0477デフォルトの名無しさん2013/10/14(月) 22:38:01.29
>>469
WebSharperお勧め。
0478デフォルトの名無しさん2013/10/14(月) 23:50:05.95
>>477
別人だが、これいいな。
0479デフォルトの名無しさん2013/10/15(火) 07:17:52.99
es6ify以外はまあ良いな。
この文脈で何故なおもJS推すのかよく解らん。
0480デフォルトの名無しさん2013/10/15(火) 08:17:23.21
標準であるということはそれだけで価値高いからな
0481デフォルトの名無しさん2013/10/15(火) 08:29:52.35
標準にこだわって生産性の低い環境を使い続ける連中がいるおかげで
生産性の高い環境を選ぶだけで競争優位に立てる
0482デフォルトの名無しさん2013/10/15(火) 08:35:54.17
お、おう
0483デフォルトの名無しさん2013/10/15(火) 16:59:17.46
汎用性にこだわらない奴はプログラマ向いてないな
0484デフォルトの名無しさん2013/10/15(火) 17:03:07.89
”こだわる”の言葉の意味を知らないとそうなる。
0485デフォルトの名無しさん2013/10/15(火) 17:20:34.57
まあ殆どの奴が「食わず嫌い」なのは間違いなさそうだな
0486デフォルトの名無しさん2013/10/15(火) 17:28:32.29
いろいろ触った上でJavaScriptは糞。
標準が高機能である事は重要。
0487デフォルトの名無しさん2013/10/15(火) 18:15:06.20
言語自体に大した違いなんて無い。
0488デフォルトの名無しさん2013/10/15(火) 18:43:09.62
WebAPIが徹底的に機能を提供する作りになってるから、
言語にいくら大層な機能があっても役に立たない
0489デフォルトの名無しさん2013/10/15(火) 19:36:09.80
意味不明
WebAPI主体ならなおさら標準でURIコンポーネントぐらい用意しとけよ
0490デフォルトの名無しさん2013/10/15(火) 19:37:09.01
>>487
＞言語自体に大した違いなんて無い。

こういう事書く奴に限って、クソ言語しか使った事無いんだよな
お前は判断出来るだけの経験が無いだろっつの
0491デフォルトの名無しさん2013/10/15(火) 19:40:31.93
違いがない？
なら全部Cで書けよ。
0492デフォルトの名無しさん2013/10/15(火) 20:11:06.20
ここって動的言語スレ？
0493デフォルトの名無しさん2013/10/15(火) 20:33:22.07
LLerが過疎スレと頭の硬い言語使いたちに話題を与えてやっているところです
0494デフォルトの名無しさん2013/10/15(火) 20:35:53.70
>>489
笑ったw そりゃそーだ
0495デフォルトの名無しさん2013/10/15(火) 20:38:11.16
>>489
あるだろ節穴

>>490,491
Webで使う上でどうそんなに違うのか説明よろ
こちとら悪魔の証明は出来ないんでね
反証待ってまーすｗｗ
0496デフォルトの名無しさん2013/10/15(火) 20:48:34.77
パッケージングがない言語は総じてクソ
0497デフォルトの名無しさん2013/10/15(火) 20:54:57.45
Lispの後継JavaScriptが素晴らしくないわけない
当初はそう思っていました
0498デフォルトの名無しさん2013/10/15(火) 21:01:12.15
>>495
ほおー。ならjs言語の標準のURLクラスの仕様をぜひ示してくださいな。
0499デフォルトの名無しさん2013/10/15(火) 21:12:01.02
JSにクラスはないしURLコンポーネントが備わってる必要もない
必要がるのなら外部APIとして提供してもらえばいい
それがスクリプト言語って言うもの
0500デフォルトの名無しさん2013/10/15(火) 21:12:35.49
またいつもの糞JSerか
0501デフォルトの名無しさん2013/10/15(火) 21:14:33.80
ES6でclass構文できるんだけど？
そんな詭弁で大丈夫か？
0502デフォルトの名無しさん2013/10/15(火) 21:15:30.76
糞JSerですがなにか？
俺が糞だとしてもJSは神聖なものです
0503デフォルトの名無しさん2013/10/15(火) 21:16:42.46
>>501
前スレだか前々スレだかで嫌というほど説明合っただろう
あれはただの糖衣構文でクラスなんかないのは変わらないと
0504デフォルトの名無しさん2013/10/15(火) 21:16:57.07
488 ：デフォルトの名無しさん：2013/10/15(火) 18:43:09.62
WebAPIが徹底的に機能を提供する作りになってるから、
言語にいくら大層な機能があっても役に立たない

489 ：デフォルトの名無しさん：2013/10/15(火) 19:36:09.80
意味不明
WebAPI主体ならなおさら標準でURIコンポーネントぐらい用意しとけよ


495 ：デフォルトの名無しさん：2013/10/15(火) 20:38:11.16
>>489
あるだろ節穴


早くソース出せよ
0505デフォルトの名無しさん2013/10/15(火) 21:20:25.29
URLWebAPIならあるhttp://url.spec.whatwg.org/#api
0506デフォルトの名無しさん2013/10/15(火) 21:25:04.47
>>504
まず俺の質問に答えろやクズｗｗ

ほらよあったやんけｗｗ
>>505
0507デフォルトの名無しさん2013/10/15(火) 21:35:13.98
まあ例によってまだFirefoxしかそれなりに対応してないんだけどね
URLコンストラクタ自体は他のAPIの為に既に広く使えるけど、ちょっとアレ
0508デフォルトの名無しさん2013/10/15(火) 21:37:31.76
1. WebAPIじゃない
2. 言語標準じゃなくてWeb標準、しかもDOM
3. firefox、chrome、operaで試したけど使える環境一つもない

なめてんの？
0509デフォルトの名無しさん2013/10/15(火) 21:39:11.78
>>212
質問者は質問する気がないのなら帰って、どうぞ。
喧嘩したいのならスレを間違ってますよ。
こっちですよ。
http://toro.2ch.net/test/read.cgi/tech/1379350030/1
0510デフォルトの名無しさん2013/10/15(火) 21:40:28.78
JSerは自分で使った経験から語ってるんじゃなくて、
てきとーにググって返答してる感じだね
0511デフォルトの名無しさん2013/10/15(火) 21:42:30.52
>>508
言語標準？？？
Web標準にあるって話でしょう？
JavaScriptはWebだけのためのものじゃないんだからさ
あとこういうのをWebAPIっていうのよ、URLAPIね
それからFirefoxではそれなりに使えるよ
0512デフォルトの名無しさん2013/10/15(火) 21:44:23.34
>>510
試したことがあるから覚えててURL貼ったんだよ
まあ、今はまだ使えそうにないから将来に期待だなーって感じで
でもこういうAPIを沢山追うのが楽しいんだと思うよ
0513デフォルトの名無しさん2013/10/15(火) 21:44:43.14
>>511
DOM APIだろ虚言癖
Web APIはHTTPのサービスのAPIの事だろうが
0514デフォルトの名無しさん2013/10/15(火) 21:46:42.12
>>512
firefoxのnightlyだとあるのか？
少なくとも安定版はFile APIのURLしか見つからないんだが
0515デフォルトの名無しさん2013/10/15(火) 21:49:41.30
>>513
WebAPIっていうのはDOMAPIを含むHTML5の流れに乗ったAPIのこと全般を指す言葉だよ
https://wiki.mozilla.org/WebAPI
0516デフォルトの名無しさん2013/10/15(火) 21:51:50.03
>>514
nightlyしか入れてないから分からないけど
スタティックメソッドはないよ
URLのインスタンスメソッド（？）がいくつかある
0517デフォルトの名無しさん2013/10/15(火) 21:54:15.19
>>509
JavaScript質問スレを荒らしてる自演厨はここからの派遣か
http://toro.2ch.net/test/read.cgi/hp/1381678387
趣味悪いなおいｗ
0518デフォルトの名無しさん2013/10/15(火) 21:58:04.14
>>515
WebAPIってサーバーサイドだけの単語じゃなくなったんだな
虚言癖なんて言って申し訳ない、単純にこちらが浅学なだけだった
0519デフォルトの名無しさん2013/10/15(火) 21:58:34.95
ありゃ
というかChromeでもURLコンストラクタ機能してるわ
ついこの前試したときは見せかけだと思ってたんだけどどうなんだろう
0520デフォルトの名無しさん2013/10/15(火) 22:00:19.32
>>518
全く気にしてないよ
0521デフォルトの名無しさん2013/10/15(火) 22:08:22.32
// chrome v30
new URL("http://www.google.com";) // => URL {}
var url = new URL("http://www.google.com";) // => undefined
Object.keys(url); // => []
url.path // => undefined

こうなるよ
flagsにも特に関係の有りそうな設定はない
0522デフォルトの名無しさん2013/10/15(火) 22:29:33.56
>>521見つけた
https://code.google.com/p/chromium/issues/detail?id=303152
５日前から少しずつ実装されてきてるっぽい
Chrome Canary 32.0.1671.3でこうなる

Object.keys(url); // =>
["hash", "search", "pathname", "port", "hostname", "host", "password", "username", "protocol", "origin", "href"]
0523デフォルトの名無しさん2013/10/15(火) 22:31:46.89
chromium-dev v32試してみたら

new URL("http://www.google.com";);
// => URL {hash: "", search: "", pathname: "/", port: "", ...

ちょうど境目にあたる時期だったんだな
chromeにもfirefoxにも入ってるならさすがに標準と認めざるを得ないな
0524デフォルトの名無しさん2013/10/15(火) 22:54:06.16
>>522
リンク先読んだ、ありがとう
specからnodeのURLの簡易版だと思ってたけど
なんだか想定してる使い方からして違うみたいだね
0525デフォルトの名無しさん2013/10/15(火) 22:59:44.59
こことか見ると仕様はとても良く似ていると思うけれど
https://developer.mozilla.org/en-US/docs/Web/API/URL.URL
0526デフォルトの名無しさん2013/10/15(火) 23:00:32.85
http://nodejs.jp/nodejs.org_ja/api/url.html
0527デフォルトの名無しさん2013/10/15(火) 23:49:43.19
今更URIクラスを実装しているなんて何周遅れなんだJS。
0528デフォルトの名無しさん2013/10/15(火) 23:58:53.33
今までは必要となる機会がなかったから
0529デフォルトの名無しさん2013/10/16(水) 00:17:01.62
呆れるな……
0530デフォルトの名無しさん2013/10/16(水) 03:34:29.49
今までJavaScriptなぞでずっと満足してた連中が作ってるわけで
いろんな意味でトロくさかったり身の程知らずだったり井の中の蛙だったり要するにバカだったり
誤った判断を繰り返すのは仕方がないと思ってる。

なぜネイティブのようなアプリが作れないのだろう？糞言語と言われるのだろう？と疑問に思い
一つ一つゆっくり気づいていくのを待つしかあるまい。生暖かい目で見守ろう。

ハードルが軽く数十はあってそれぞれに1年くらいかかりそうだけどな。
0531デフォルトの名無しさん2013/10/16(水) 04:13:11.68
何？喧嘩売ってんのお前
0532デフォルトの名無しさん2013/10/16(水) 05:40:19.09
このスレに常駐しているJSerにとってJavaScriptは完全無欠の言語なの?
使っている言語の愚痴の一つも言わないユーザーってなんかキモい。
0533デフォルトの名無しさん2013/10/16(水) 09:01:09.56
不満点は全て将来バージョンの仕様で解決される目処が付いたから
実装が早く進んでくれることを祈るくらいしかない
と、言うか不満を抱く前に色んなAPI覚えることが多いってのもある
今を頑張りながら将来にも期待できる
JSerは充実しています
0534デフォルトの名無しさん2013/10/16(水) 11:26:34.20
今仕様にケチがあるのならここで言わずにメーリングリストに載せるだろJK
0535デフォルトの名無しさん2013/10/16(水) 15:00:45.17
>>533
>不満点は全て将来バージョンの仕様で解決される目処が付いたから

具体的にどんな不満があったの。
0536デフォルトの名無しさん2013/10/16(水) 15:15:08.08
>>535
bignum型
これが長年欲しかった
0537デフォルトの名無しさん2013/10/16(水) 15:21:21.59
普通に未来のES6ES7で予告されている機能のリストは裏返せば現在のJSerの不満の
リストと解釈して問題ない。
0538デフォルトの名無しさん2013/10/16(水) 15:36:47.44
あった方が便利ねっていうのと無いのが不満だわって言うのは分けて考えてる
全て前者には含まれるけど、後者に含まれるのは個人的にかなり少ない

まあ、「新しい規格を作る上」でどうかっていう枠組みで見ると
多くがこれくらい無いと不満だわってなるだろうし、一般論では言えんね
0539デフォルトの名無しさん2013/10/16(水) 16:00:09.03
あった方が便利と言うのは裏返せば無いと多かれ少なかれ不便なわけで、特に他の言語では
あったりごく普通な言語機能が存在しなかったり異常だったりすると他の言語との掛け持ち
組にとっては不満となるでしょ。

特にサーバー側で別の言語を使っていてWebクライアント開発にJavaScriptを使っていると
いう掛け持ち組は多いだろうから他の言語との比較で不満が出てくるのはごく自然。
0540デフォルトの名無しさん2013/10/16(水) 18:15:54.61
サーバ側で使ってる言語にJSへのトランスレータがあれば解決だね
0541デフォルトの名無しさん2013/10/16(水) 18:24:48.87
GWTなんかはそんなフレームワークだけどね。
0542デフォルトの名無しさん2013/10/16(水) 18:28:55.09
Javaはアンチも多いから...
0543デフォルトの名無しさん2013/10/16(水) 19:02:51.32
ウンコ言語からウンコ言語にコンパイルできても
意味ないでしょ
0544デフォルトの名無しさん2013/10/16(水) 22:27:43.64
そうかRubyはウンコ言語だったのか
0545デフォルトの名無しさん2013/10/16(水) 22:37:43.67
おまえらはウンコマニアの変態だってこった
0546デフォルトの名無しさん2013/10/16(水) 23:12:39.72
>>543
ウンコが二つから一つになるのは馬鹿にできないぞ。
0547デフォルトの名無しさん2013/10/16(水) 23:28:52.18
ここは天国板か
0548デフォルトの名無しさん2013/10/17(木) 06:19:13.39
>>539
郷に入っては郷に従え
さっぱりその言語を使えこなせないのに文句をいうのは笑えるｗ
違う言語を使ってて違うのがおかしいとか言い初めた時にはもうね、苦笑
0549デフォルトの名無しさん2013/10/17(木) 06:38:45.82
なるほど。使いこなすとはすなわち無批判になると言うことか。
0550デフォルトの名無しさん2013/10/17(木) 06:51:13.17
>>533でFAだろう
それ以上でも以下でもない
JSerにとって仕様は安泰だが実装が不安
今も昔もこれからも
あとはとにかくAPIを叩いていくことになるから
そのAPIに不満は細々持つが
ここに書いてもJSer以外分かっちゃくれないだろう
そういうスレで解決策話すに決まっている
いずれにしろ言語自体に不満はほぼない
0551デフォルトの名無しさん2013/10/17(木) 06:57:14.07
>>550
> >>533でFAだろう

そうか。

>不満点は全て将来バージョンの仕様で解決される目処が付いたから

つまり現在バージョンには不満点があると言うことだよな。なら現在バージョンを
使っている人が不満を愚痴るのも別にかまわんだろう。

> ここに書いてもJSer以外分かっちゃくれないだろう

恥ずかしからずにその高尚な不満とやらを披露してみればよいのに。
0552デフォルトの名無しさん2013/10/17(木) 07:05:53.22
数値計算関係は完全に腐ってる
新しい標準ライブラリや仕様もできる気配ないし
0553デフォルトの名無しさん2013/10/17(木) 07:14:19.54
>>551
今抱えてる大きな不満は０
しいて挙げるとしたらこれか>>536
今は気にしてないけど、しばしばこれはカバーが大変だからね
あとは正直ぱっと思いつかない
これに関してどう？って聞かれれば沢山細々あるだろうけどね

ES6を見るまでES6の機能が欲しいとは思わなかったのと
既にES6が使える気でいるのが大きい

例えばもしIE8でES3で書かなきゃいけなくなったら
ES3に不満抱かないでしょ？そこは間違いなくIE8に苛立ちが全部行くわけだ
だから今は毎日実装のアップデートをチェックして早くES6実装されないかなと悶々としてる

同じくAPIに付いてだってさ、>>505もそうだけど
「Living Standard」ってのが多いのよ
実装で普及してなんか明らかにこれは失敗だったねってわかった時には
当然その解決策が出てるのよ
だから仕様に文句言うって発想にはなりにくいのよね


>>552
何に困ってるのかよく分からんけど、
NumberやMathの関数はもの凄く増えたよ
0554デフォルトの名無しさん2013/10/17(木) 07:28:18.21
配列のmapやらはちょっと気になるとこはあるな
まずDOM系の配列もどきに使えないのが直感的じゃない
あとは第二引数以降がオプショナルな標準関数にかけると誤爆するってことだな
この２点、どうするのが一番スマートに解決できるかね
0555デフォルトの名無しさん2013/10/17(木) 07:52:15.87
living standardとか格好つけて言ったところで実際に現場でコードを書いている人間は
de factoを相手にしているわけで何も救いにもならんわな。
そのliving standardとやらはどれだけ広くプロダクションで使われているのさ。
机上の空論か単に趣味。

> ES6を見るまでES6の機能が欲しいとは思わなかったのと

ほんと無批判なんだね。
0556デフォルトの名無しさん2013/10/17(木) 08:14:47.65
>>553
増えたよってクッソ少なかった数学関数部分だけやろ
有理数や複素数その他なんて
仕様だけでもrubyやpythonの標準ライブラリ以下
0557デフォルトの名無しさん2013/10/17(木) 08:23:08.67
scipyはもちろん、numpyレベルに到達するのすら
永劫の時間がかかるだろう
0558デフォルトの名無しさん2013/10/17(木) 08:24:24.33
>>555
仕様を批判するかっていう話だろう？
実装を批判することならしょっちゅうだよ
仕様は常に前に進んでる限り批判できるところはない

>>556
ES7まで待ってね
0559デフォルトの名無しさん2013/10/17(木) 08:31:40.51
仕様は自分たちで作っていくものだろうよ
0560デフォルトの名無しさん2013/10/17(木) 08:38:22.10
>>558
> 仕様を批判するかっていう話だろう？

いや全然? いま現場でどれだけ使えますか、関心があるのはそれだけだけど。

> 実装を批判することならしょっちゅうだよ

それなら今現在使える実装で広く無難に使えるJavaScriptの機能には不満だとか
ウンコだと愚痴るのも大目に見て欲しいな。

> ES7まで待ってね

つまり遠い未来に期待しろと。
0561デフォルトの名無しさん2013/10/17(木) 08:42:04.99
>>560
実装批判なら好きなだけどうぞ
実のない話しならJSアンチスレで、実のある解決したいことなら各JSスレでしてね
0562デフォルトの名無しさん2013/10/17(木) 08:50:04.06
このスレでJSについて話してるのは
何もJSがいいぞという話ではなくて
動的言語の可能性を示すための一例だから
ここでJSを愚痴ってもしかたない
0563デフォルトの名無しさん2013/10/17(木) 09:03:06.59
>>561
JSアンチスレはここですが、なにか？
0564デフォルトの名無しさん2013/10/17(木) 10:18:23.11
>>562
既に他の言語ではとっくの昔に実現されてる機能がJSにも(仕様では)存在するって話から
どんな可能性を読み取れば良いの？
0565デフォルトの名無しさん2013/10/17(木) 10:52:57.65
もうjsがクソ言語かどうかは別スレでやれよ(´・ω・｀)
0566デフォルトの名無しさん2013/10/17(木) 10:55:31.30
意味不
誰がいつJavaScriptのそういう仕様が良いと言ったのか
動的言語がいい理由はエンジンの可能性として前スレから散々出ただろう
JavaScriptもV8凄いねって話で出ただけで
仕様の話は足りないという意見とその反論のみで
この趣旨に則って議論されては無いだろう
だから批判は別スレでやれって言ってる
0567デフォルトの名無しさん2013/10/17(木) 13:22:18.18
　 jsは静的言語より柔軟で凄い
→ 実装足りてないよ
→ jsは実装じゃなくて仕様、仕様は安泰
→ 仕様も足りてないよ
→ 仕様の批判は別スレでやれ

なぜなのか
0568デフォルトの名無しさん2013/10/17(木) 15:46:07.10
開発生産性という面であれば例えばGUI開発のようなある程度の規模のAPIを相手に
する開発する場合、IDE上でいわゆるコンテントアシストやインテリセンスの類が
高打率で効いた方が非常に助かる。
そういう点では静的型や動的にしても仕様として型アノテーションを持っていて
きっちり注釈をつける習慣のある言語でないとアシストするにも打率が低すぎる。

IDEやエディタとかでも時々jQuery対応とか謳うものがあるけれども、そもそも論
としてどうしてフレームワーク決め打ちで対応をアピールする必要があるのか。
言語仕様的にフレームワーク決め打ちで実装しないと十分なアシストを提供する
のが難しい部分があるって事じゃないのかな。

今時のJavaScriptフレームワークにテンプレートエンジンを組み合わせた開発に
しても、何年も前のAS3+MXMLに全然追いついていないと思う点も多い。
0569デフォルトの名無しさん2013/10/17(木) 15:54:46.32
型アノテーション無しでもバシバシ補完が決まる
Pythonのjediは凄い
0570デフォルトの名無しさん2013/10/17(木) 16:09:31.29
それは単純だけど依存するモジュールをPythonのコード内で普通にimportで明示
しているのも大きいと思う。
典型的なJavaScriptを使ったWeb向けの開発の場合、どういうコンテキストの中で
今相手にしているコードがロードされるのか解らんと依存範囲が特定できないし
アシストするにも限度がある。

require.jsを使ったところでrequire.js決め打ちでエディタが対応しないとダメ
だろうなぁ。
0571デフォルトの名無しさん2013/10/17(木) 20:26:38.24
JSがウンコだから悪いってことか…
0572デフォルトの名無しさん2013/10/17(木) 20:38:51.81
このスレJSのアンチvs信者スレなのに埋まるの早すぎ
0573デフォルトの名無しさん2013/10/17(木) 21:03:33.30
アンチ対信者というよりもリアルユーザー対未来の仕様を語る趣味の人でしょ。

今現在不便なことを愚痴ると未来の仕様が語られ今現在普及している実装では使えないと
話すと実装の話はスレチとかわされる。
0574デフォルトの名無しさん2013/10/17(木) 21:24:09.39
ES99くらいになれば、型を書かなくても
Pythonくらい補完が効くようになるの？
0575デフォルトの名無しさん2013/10/17(木) 21:49:23.36
>>571
依存性を宣言的に列挙する文法も無ければ依存性の解決方法も仕様化されていない、そういう意味では
今のJavaScriptがウンコなのが悪いということだろう。
0576デフォルトの名無しさん2013/10/17(木) 21:51:18.27
今どき生のJavaScript使ってるからだろ。
Haxeその他有るじゃん。
0577デフォルトの名無しさん2013/10/17(木) 21:55:19.52
C++,C#,Java,Python,Ruby,PHP,Perl,その他マイナー言語を初級くらいで扱えるけど
自分はJavaScriptが一番好きだよ
0578デフォルトの名無しさん2013/10/17(木) 21:55:41.77
>>576
そんなマイナー言語、仕事で使えないじゃん
0579デフォルトの名無しさん2013/10/17(木) 22:06:58.90
>>578
そうそう、その通り！
だから貴方は、今迄の言語を使っていて下さい。
0580デフォルトの名無しさん2013/10/18(金) 00:24:48.20
JavaScriptにコンパイルする言語が山ほど出てくるあたりが今現在のJavaScriptに不満を抱く人が
多いって傍証。

NoSQLじゃなくてNoJavaScriptと言ったところだな。
0581デフォルトの名無しさん2013/10/18(金) 00:56:17.69
だからもうjavascriptの言語がくそかどうとかはどうでもいいよ。
動的の代表格として出すのはいいけど、それ以外の糞仕様について語るのはスレチだ。
0582デフォルトの名無しさん2013/10/18(金) 01:02:54.60
クソなJavascriptが動的言語の代表格ヅラしてるのが
滑稽だと言っているんだよ
0583デフォルトの名無しさん2013/10/18(金) 01:19:43.88
>>580
> JavaScriptにコンパイルする言語が山ほど出てくるあたりが今現在のJavaScriptに不満を抱く人が
> 多いって傍証。

まったく論理的じゃない。

言語というのは山ほど出きるもの。C、C++、Perl、Ruby、PHP、Java
それらは、アセンブラに不満をいだいたから出来たわけじゃない。
0584デフォルトの名無しさん2013/10/18(金) 01:36:27.98
>>583
それでは他にどんな理由があると？ 説得力のある別の理由付けをよろしく。
0585デフォルトの名無しさん2013/10/18(金) 01:49:22.03
CSやTSは次期ESと協調して策定されてるよ
別の派閥ってわけじゃ全くない
どれもより良い機能を追求するJS.nextファミリー
0586デフォルトの名無しさん2013/10/18(金) 01:55:42.00
>>584
プログラミング言語を作る理由？

既存の言語よりも優れているものを作りたいからじゃねーの？

特定の何かがダメだからではなく、他の言語全てよりも優れたもの、
需要にあったものを作りたいだけだよ。

JavaScriptがだめでCoffeeScriptを作ったというところまではいいが、
CoffeeScriptがあるのに、TypeScriptを作ったということは、
CoffeeScriptもだめということになる。○○もだめで□□を作り、
□□もだめだから△△を作り、それもだめだから☆☆を作った。と思う？

違うね。言語が作られるのは、他の言語よりも優れたものを目指して作ってるだけ。
JavaScriptにコンパイルするのはブラウザで動くのがJavaScriptだけだからってだけ。
JavaScriptだけ不満があるから他の言語を作ったのではなく、
その他の言語全てに不満があるから作ってる。
0587デフォルトの名無しさん2013/10/18(金) 01:57:47.35
言語に不満があると言っても、それは主観の話、
個人の考え方の違いであり、その証拠に
JavaScriptは多くの人に使われている。
0588デフォルトの名無しさん2013/10/18(金) 02:09:18.78
考え方の違いの数だけ言語が出来るだけの話。
0589デフォルトの名無しさん2013/10/18(金) 02:23:22.11
JavaScriptも求められる状況が変わってきてそれに合わせて
JavaScript自体も進化しようとしてるし、altJSも出てきている
全て現状をより良くしようとする試みで敵同士ではなく味方
未来を負っているものに対してやれ現実がどうたら後ろ向きな批判されるとそりゃ嫌だわな
しかもとっくに解決の目処が立ってたり、そもそも見当違いなことばかり
>>554みたいな皆で解決策話し合える具体的で前向きな問題定義をしろよ
0590デフォルトの名無しさん2013/10/18(金) 02:37:08.74
必死だねぇ。JSerとしてはひたすらJavaScriptは完全無欠の愛される言語と信じたいわけだ。

んなこと無いよ。
大多数の人は他の言語と同様に良い点悪い点併せ持った持った言語として使っているだけ。
今現在不便なところには普通に文句を言う。
0591デフォルトの名無しさん2013/10/18(金) 02:54:09.33
どんな言語も夢見る未来のバージョンは大抵は完全無欠に見えるもの。
そりゃ今見えている不満を潰すところから取りかかるのだから当然。

そして出た頃には実際使ってみると新たな不満が出てくるのもお約束。
0592デフォルトの名無しさん2013/10/18(金) 03:17:32.52
>>590
このスレは文句を言うスレではありません
不満があるのなら建設的な意見を出してください
そしてその不満の多くには既に解決策が示されていますから
このスレで出しても無駄です
各言語スレ、もしくはHTML5スレのような所で愚痴を必死にやってください
0593デフォルトの名無しさん2013/10/18(金) 04:33:32.20
>>592
だからそもそもjsのことを話すスレじゃねえよ。お前が出てけwww
0594デフォルトの名無しさん2013/10/18(金) 04:48:04.24
こやつ草生やさないとろくに弁解も出来ないほど追い込まれてるな
あと一歩だな
0595デフォルトの名無しさん2013/10/18(金) 04:49:07.67
>>594
お前は何と戦ってるんだw
0596デフォルトの名無しさん2013/10/18(金) 05:28:22.46
何でも首突っ込んでJavaScript(ES)中心で話すのをやめればいいだけ
なんで他言語の後追い仕様を元に優秀とか言っちゃうかね
0597デフォルトの名無しさん2013/10/18(金) 05:43:10.94
>>596
ルビーストの悪口はそこまでだー！
0598デフォルトの名無しさん2013/10/18(金) 05:57:42.84
>>596
Disる対象の言語仕様が劣っていないと余程都合がわるいようだな＾＾
0599デフォルトの名無しさん2013/10/18(金) 06:57:39.17
型推論付きの静的型付け言語かオプショナルな静的型付きの動的型付け言語だな。
0600デフォルトの名無しさん2013/10/18(金) 06:59:55.11
機能が多ければ良いってもんでもない
シンプル・イズ・ザ・ベスト
0601デフォルトの名無しさん2013/10/18(金) 07:06:11.03
(※ただしES6や7で導入される機能は除く)
0602デフォルトの名無しさん2013/10/18(金) 07:22:46.36
型注釈なんて単に機械可読なように仕様化されたドキュメントの断片です。

意固地なJSerはそれがわからんか、単にドキュメントを書く習慣がないのです。
0603デフォルトの名無しさん2013/10/18(金) 07:34:28.31
その話は散々TypeScriptの時にしてむしろ分かってなかったのは
非スクリプターのようだったがな
0604デフォルトの名無しさん2013/10/18(金) 08:03:38.39
TypeScriptの話ってなんだっけ？
型推論がウンコってことしか覚えてない
0605デフォルトの名無しさん2013/10/18(金) 09:06:33.44
計算モデルと言語仕様との区別すら出来てない手合ばっかりだな。
0606デフォルトの名無しさん2013/10/18(金) 09:23:39.43
どの書き込み見てそう思っちゃったの？
0607デフォルトの名無しさん2013/10/18(金) 12:35:07.99
606だろ。
0608デフォルトの名無しさん2013/10/18(金) 13:55:49.99
で、結局動的型+型注釈はどうなの?
御利益はあるし、Enhanced JSの多くが取り入れているあたりからも需要もあると
思うのだけど。
0609デフォルトの名無しさん2013/10/18(金) 14:43:44.00
むしろドキュメントとソースの整合性が取れなくなるから無駄でFAだっただろ
0610デフォルトの名無しさん2013/10/18(金) 15:09:26.70
?
型に関してドキュメントとソースの整合性を静的に機械的にチェック出来る余地
があるのが型注釈の良いところだと思うけど。
型の付記の有無が実行時のセマンティクスに影響を与えるかは言語次第だし、
実行時に型チェックをせずに垂れ流すか型エラーを投げるかは一長一短がある。

それにそういう整合性をとるのは例えばライブラリやフレームワークの開発者が
頑張れば良いことで、彼らが一度頑張ればそのご利益はその成果物のユーザーに
広く行き渡るわけで。

型注釈やオプショナルな静的型を持つ言語では内部の実装は動的型も併用しつつ
柔軟に書いて、公開メソッドのようなAPIの顔の部分はきっちり型付きで書いたり
するのがベストプラクティスだったりするよね。

成果物にきっちり解りやすいドキュメントを書くのと同じだよ。
機械にも読みやすい点が違うだけで。
0611デフォルトの名無しさん2013/10/18(金) 16:05:39.95
型注釈ならjsdocでいいじゃん
0612デフォルトの名無しさん2013/10/18(金) 16:09:44.78
会社では動的型(+オプショナルな型付き)言語のGroovyを使ってGrails上で開発しているけれど、

・モデル: がっちり型付き(DBにマッピングするので結局型は明記する必要があるし)
・サービス: 公開メソッドは型付き
・その上のコントローラーやビュー: 動的型も併用

みたいな感じで回っている。大事なところは型付きで、柔軟性が必要なところやコンパクトに
書きたいところ(ビューのテンプレートの中のインラインコードとか)は動的型で。
実際使っていて静的動的両方使えるのは何かと都合が良い。
あとGroovyとJavaは混ぜることが出来るのでJavaでゴリゴリ書く部分もある。
0613デフォルトの名無しさん2013/10/18(金) 16:16:45.14
Groovy使うとかTypeScript使う並に今はまだ時期尚早だろ
0614デフォルトの名無しさん2013/10/18(金) 16:36:17.55
jsもasm.jsっぽい型指定使うようにすればいいじゃん
注釈ならdocでいいけど前者ならパファーマンス上がる効果も見込めるし
0615デフォルトの名無しさん2013/10/18(金) 16:39:09.43
静的+型推論が一番
実行時速度も動的より早い
0616デフォルトの名無しさん2013/10/18(金) 16:44:29.51
>>613
Groovyはそれなりに古いよ。

どんぐらい古いかというと産みの親が「開発当時Scalaについて知っていたらGroovyなんか
作らなかったのに」とつぶやいてそのままScalaに走った程度には古いw
時期的には同時期。

歴史的にはGrailsはZendやDjangoと同時期にスタートしていて、今もSpringベースの
フルスタックフレームワークとしては一番活発に更新され文書化されているものの一つなので、
特に時期尚早と言うこともない。
0617デフォルトの名無しさん2013/10/18(金) 16:44:45.67
※根拠なし
0618デフォルトの名無しさん2013/10/18(金) 16:59:23.33
Grailsに関連してJavaの世界でのWebフレームワークの流行廃りに関してはこのあたり。61ページぐらいから。
http://www.slideshare.net/mraible/comparing-jvm-web-frameworks-devoxx-france-2013
0619デフォルトの名無しさん2013/10/18(金) 17:39:05.07
asm.jsってネイティブより高速なケースも出てきたし
このまま行くとemscripten＋生JSが最強そうだな
0620デフォルトの名無しさん2013/10/18(金) 18:57:04.00
GroovyにせよScalaにせよJavaにせよJVMファミリーでみな簡単に連携できる。
.netファミリーも同様で、要するに同じ実行環境で場面に応じた言語をシームレスに使い分け
られるのは便利。
0621デフォルトの名無しさん2013/10/18(金) 19:24:05.00
理屈ではそうだが現実は.netが糞なのでどうしようもない
0622デフォルトの名無しさん2013/10/18(金) 20:27:48.51
Groovy時期尚早ってなんだろ。ちゃんと使われているよ。
Androidの次期ビルド環境はGradleだしね。
0623デフォルトの名無しさん2013/10/18(金) 21:11:24.70
まともに使えるのは２、３年後ってとこじゃないかな？
0624デフォルトの名無しさん2013/10/18(金) 21:15:49.09
TypeScriptの方が使えるようになるの早そうだね
http://blogs.msdn.com/b/typescript/archive/2013/10/17/typescript-and-the-road-to-1-0.aspx
0625デフォルトの名無しさん2013/10/18(金) 21:37:37.60
>>624
.NETは元からJScriptがあったからな
0626デフォルトの名無しさん2013/10/18(金) 22:05:29.10
まあまともに使えるまであと3・4年かかるES6とか待つよりも現実的な解ではあるよね・・・ > TypeScript
0627デフォルトの名無しさん2013/10/18(金) 22:08:06.83
ES6は既に半分くらい使えるし９割対応までモダンエンジンならせいぜいあと１年何だが
0628デフォルトの名無しさん2013/10/18(金) 22:20:11.09
IE11のES6対応なんてletとconstだけだし(すごいね!)IE12のスケジュールや更新内容なんて分からんし。
0629デフォルトの名無しさん2013/10/18(金) 22:24:35.55
letに対応してるだけでかなり十分
あとはアロー関数だけあればいい
0630デフォルトの名無しさん2013/10/18(金) 22:30:48.63
だから土管としてはもう十分だって
0631デフォルトの名無しさん2013/10/18(金) 22:30:58.22
来年以降のES12とそれからまた先のES11の絶滅をお待ちください > アロー関数
0632デフォルトの名無しさん2013/10/18(金) 22:32:58.14
なんだESって。IEだ。
0633デフォルトの名無しさん2013/10/18(金) 22:57:10.56
letが使えるってことで、１つあると思うのは
何でもかんでも
(function(){
})
で囲うのやめて
ブロックとletにしないかなーってこと

極力varを使わないで全部letにする
これができるのはそこそこ大きいと自分は思う
0634デフォルトの名無しさん2013/10/18(金) 23:19:03.30
何でもかんでもfunctionで囲んでいる辺りでこの言語何かがおかしいと気づいて欲しい。
0635デフォルトの名無しさん2013/10/18(金) 23:22:50.99
その言い方だと語弊があるな
導入と結論が結びついてないし
バカな煽りにしかなってないよ
0636デフォルトの名無しさん2013/10/18(金) 23:34:44.88
>>635
お前の指摘する内容が
お前の書き込み自身にモロに当てはまっててワロタw
0637デフォルトの名無しさん2013/10/18(金) 23:42:01.10
KY黙っとけ
0638デフォルトの名無しさん2013/10/19(土) 00:20:34.69
JSをクソだと指摘するだけで
発狂する輩がいるのが不思議。事実じゃん
0639デフォルトの名無しさん2013/10/19(土) 00:32:39.26
>>621
それはJVMに比べてクソだ言うてんの？
0640デフォルトの名無しさん2013/10/19(土) 00:32:55.23
633のは弁護出来ないよなぁ。
再来年以降はlet使えるようになって改善するらしいけど。
0641デフォルトの名無しさん2013/10/19(土) 01:57:57.87
しかしながらletはコストが高いんだよなあ
特にfor文では一目瞭然
0642デフォルトの名無しさん2013/10/19(土) 02:05:12.50
来年にはIE11の強制アップデートがあるんじゃないかな
0643デフォルトの名無しさん2013/10/19(土) 06:32:30.56
groovyって日本だとあまり馴染みないけど、海外だと結構名前聞くよな
0644デフォルトの名無しさん2013/10/19(土) 08:40:52.49
Javascriptについて質問です。
どうして以下のような結果になるのですか？
全然意味が分かりません。。。

['1','2','3'].map(parseInt) //[1, NaN, NaN]
0645デフォルトの名無しさん2013/10/19(土) 09:38:28.19
>>644
なんだこれw
0646デフォルトの名無しさん2013/10/19(土) 10:29:24.01
JSウンコ伝説に新たな1ページなの？
0647デフォルトの名無しさん2013/10/19(土) 10:36:01.47
駄々こねてるな。
0648デフォルトの名無しさん2013/10/19(土) 11:34:41.10
ぐうの音も出ない
0649デフォルトの名無しさん2013/10/19(土) 12:10:51.95
JSerの解説マダ〜？
0650デフォルトの名無しさん2013/10/19(土) 12:38:04.79
>>644

function vi(value, index) {return index + ':' + value }
['a','b','c'].map(vi)
=> [ '0:a', '1:b', '2:c' ]


これと同等だから
function p(value, index) {return parseInt(value, index) }
['1','2','3'].map(p)


https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/parseInt

var intValue = parseInt(string[, radix]);

引数

string
パースしたい値を表す文字列

radix
string （第一引数）の基数を表す整数
0651デフォルトの名無しさん2013/10/19(土) 13:11:24.78
Haskellで言うところのmapAccumLなのか
普通のmapは無いの？
0652デフォルトの名無しさん2013/10/19(土) 13:26:14.27
自分で作ればいいんじゃね？

っていうかコアになんでも詰め込もうとするなよ。
コアは最小限で後はライブラリで補う方がいい。

コアだけなら
['1','2','3'].map(v=>parseInt(v))
ってかけるようになるだろ？

今すぐには全てのブラウザで使えない？
うん、だから、自分で作れってことさ。
0653デフォルトの名無しさん2013/10/19(土) 13:42:52.54
JSって引数の数が合わなくても
例外すら出ないんだ
0654デフォルトの名無しさん2013/10/19(土) 13:43:52.80
この場合引数の数あってるだろ。
なんでこう馬鹿は馬鹿なこと言い出すんだろうか。
0655デフォルトの名無しさん2013/10/19(土) 13:50:41.50
え？valueとindexを引数にとる関数がmapの引数になるんじゃないの？
0656デフォルトの名無しさん2013/10/19(土) 13:55:09.28
頭悪すぎｗ
valueとindexって変数名だぞ？

それを言うなら、引数を二つ取る関数がmapの
引数になるという言い方をするべき。
0657デフォルトの名無しさん2013/10/19(土) 13:56:03.41
つまり引数を一つしか取らない関数を
mapに渡したらエラーになって欲しいって
言ってるのか？
0658デフォルトの名無しさん2013/10/19(土) 14:07:10.44
ううん。引数の数が合わなくてもエラーにならないよね？って言ってるだけだよ
0659デフォルトの名無しさん2013/10/19(土) 14:09:22.17
関係ない話はいいから、
mapとpasrseIntの話の続きをしようぜ。

で、結局、なんの問題もないってことか。
0660デフォルトの名無しさん2013/10/19(土) 14:28:17.13
いや、問題無いどころか、ナカナカ良いよ
引数の数が合わなくてもエラーにならない仕様を活かして
mapとmapAccumを一つの関数で実現してる

まあ、静的型ならオーバーロードで簡単に実現できるだろうけど
0661デフォルトの名無しさん2013/10/19(土) 14:46:28.05
JavaScriptは知ってるけどHaskellは知らないから
当然mapAccumLも知らないけど、
>>650の説明はmapAccumLとは違うだろ？
0662デフォルトの名無しさん2013/10/19(土) 15:11:04.80
>>654
mapのcallbackって引数3つじゃね？
0663デフォルトの名無しさん2013/10/19(土) 15:20:51.65
>>656
いちいち言い換えないと理解できないやつの方が頭悪いと思うけどｗ
0664デフォルトの名無しさん2013/10/19(土) 16:52:23.51
バクりやすそうな仕様だな
0665デフォルトの名無しさん2013/10/19(土) 16:55:13.49
>>664
そだな。バグりにくく生産性が高いJavaが
いまのところ最強という結論にどうしても行き着いてしまうな。
0666デフォルトの名無しさん2013/10/19(土) 17:16:30.94
問題はあるよ
>>554でも書いたけど、やっぱり気になる
でもmapが悪いわけでもparseIntが悪いわけでもない
「考えてみれば当然」の動作だし、知っていればいくらでも防げるんだよね
でも気づきにくい初心者落としの穴が増えたってのはやっぱり嬉しくない
何とかしてそこを改善したいんだけど、
map系での自動引数制限みたいなのは互換性が崩れるからもう無理かな
でもこれはいい経験になって、任意数の引数とる関数とかは
mapのためにも第一引数に配列って形にしようって声が出るようになった
まあ難しいね
0667デフォルトの名無しさん2013/10/19(土) 17:19:00.65
素直にインデックス付きが欲しい場合はmapWithIndexとかeachWithIndexじゃダメなの。
あるいはa.zipWithIndex().map(f)とか。
0668デフォルトの名無しさん2013/10/19(土) 17:24:10.16
C言語ですら、ANSI Cになるときに引数の数の整合性をチェックするようになったのに
今の時代にチェックしないJSはマジでクソだな
しかも、今後もチェックするようになる可能性も無い
0669デフォルトの名無しさん2013/10/19(土) 17:26:10.65
typescript使えってことだろ
javascriptはプログラマーだけじゃなくデザイナーウェブマスターも使うんで厳密なプログラミングは好まれないんだろう
0670デフォルトの名無しさん2013/10/19(土) 17:27:28.39
第一引数に配列とか、その場その場で次元というかインデント性というかズラすのはやめてほしい…。構造崩してなんの為のプログラム言語なんだか。ダメ絶対。
0671デフォルトの名無しさん2013/10/19(土) 17:33:29.41
>>667
それなら引数１つのmapを定義すれば済みそうじゃない？
Array.prototype.map2 = function (func, thisArg) {
return this.map(function (val) {return func.call(thisArg, val)})
}

a = ["10px","20px","30px"]
a.map2(parseInt) //[10, 20, 30]
まあ本来parseIntはこういうのに使うべきで無闇矢鱈に使われすぎっていうのもあるんだけどね

>>668
そんな冗長になるもの要らないでしょ
必要なら関数側でチェックすればいいじゃん？
デフォルト引数とかもあるし、柔軟に柔軟にがいいと思うよ

>>670
既存の関数のオーバーライドとしてだから別に自然だよ
0672デフォルトの名無しさん2013/10/19(土) 17:36:19.80
型の弱い言語は総じてゴミだな
0673デフォルトの名無しさん2013/10/19(土) 17:44:41.93
>>669
TypeScriptってこんなコードですらエラーにならないけど

function f(g) { return g(1,2) }
f(function(x){ return x })
0674デフォルトの名無しさん2013/10/19(土) 17:45:04.09
1引数のparseDecimalを新設すれば良いんじゃ無い?
既に1引数のparseFloatをparseNumに改名するのでも良い。

初心者向けにはparseIntの解説に2進数8進数16進数など色々な基数でパースする
無駄に豊富なサンプルをここだけ妙に専門用語満載な解説と一緒にてんこ盛りに
すれば概ね無問題。不思議と自然に使わなくなるはず。
0675デフォルトの名無しさん2013/10/19(土) 17:51:56.11
function asUnaryFunction(x){ return function(n){ return x(n); } }

["0","1","2"].map( asUnaryFunction(parseInt) );
0676デフォルトの名無しさん2013/10/19(土) 17:53:03.49
引数が二つ以上あるって事は、本来役割の違う処理が混ざってるって事なんだよね
どこまでも分けていったら人間がついていけなくなるからしないけど
0677デフォルトの名無しさん2013/10/19(土) 17:53:44.83
引数バインドがあればもっと上手く解決できるんじゃないかな
こんな感じで第二引数だけを固定してやれれば

Function.prototype.bindArg = function (binds) {
var func = this
return function () {
var args = [].map.call(arguments, function (arg, i) {
return i in binds ? binds[i] : arg
})
return func.apply(this, args)
}
}

["10px", "20px", "30px"].map(parseInt.bindArg([,10]))
0678デフォルトの名無しさん2013/10/19(土) 17:54:11.63
じゃあカリー化で
0679デフォルトの名無しさん2013/10/19(土) 17:56:19.89
>>674こういう感じか

parseDecimal = parseInt.bindArg([,10])

["10px", "20px", "30px"].map(parseDecimal) //[10, 20, 30]
0680デフォルトの名無しさん2013/10/19(土) 18:02:38.30
長年ゴミ言語に付き合ってるだけあって
耐性ついてるな
0681デフォルトの名無しさん2013/10/19(土) 18:04:15.92
>>679
うん。でもそこはあくまでとっかかり。

一番大切なのはJavaScriptエディタ上でparseIntにマウスカーソルを乗せると
技術解説やらトリッキーな使用例や過去の仕様書へのリンクも含めた10ページ
ぐらいの長大なツールチップヘルプがポップアップして画面を埋め尽くすこと。
0682デフォルトの名無しさん2013/10/19(土) 18:06:10.03
この手の面倒なのに遭遇するとscalaで書きたくなる
0683デフォルトの名無しさん2013/10/19(土) 18:08:49.53
ES6流の解決方法だと
forMapArityLimitシンボルをparseIntにつけてmapで判断だろうが
mapがES5のもので、この問題が数年置いて置かれたってのが仕様からの解決を難しくしてる
0684デフォルトの名無しさん2013/10/19(土) 18:12:49.85
LiveScriptで十分やった

[ "10px" "20px" "30px" ].map( parseInt _, 10)
0685デフォルトの名無しさん2013/10/19(土) 18:15:16.81
>>681
うーん、まあそこまでするかはさておき
MDNのmapの項目見たら一応乗ってたね
まずは初心者はMDNを参考にするよう徹底したいとこ
0686デフォルトの名無しさん2013/10/19(土) 18:46:38.85
JavaScriptって柔軟だね。
いろんなことが出来る。
0687デフォルトの名無しさん2013/10/19(土) 19:01:50.42
仮にもLispの後継を名乗るのならトリッキーであるべき
0688デフォルトの名無しさん2013/10/19(土) 19:07:55.78
とりあえず各言語のこれからの課題はマルチコアをいかに活かせるかじゃね
0689デフォルトの名無しさん2013/10/19(土) 21:05:32.00
このスレみてたら、やっぱJavascriptはゴミだって確信できた
やっぱりRubyを使い続けてて良かった
0690デフォルトの名無しさん2013/10/19(土) 21:31:38.10
公式HobbyのRubyに言われてもな……
0691デフォルトの名無しさん2013/10/19(土) 21:56:54.27
JavaとかJavascriptってHobby以下だよな...
まあJavaはドカタ向けに、Javascriptは非プログラマ向けに
あえてダメに作られたんだけど
0692デフォルトの名無しさん2013/10/19(土) 22:00:42.67
流石Hobbyプログラマの言うことは一味違うな
0693デフォルトの名無しさん2013/10/19(土) 22:31:33.61
その公式HobbyとHobby以下の合わせ技のような立ち位置が切なくなるのでその辺りで勘弁して下さい

　--- Groovyからのお願い ---
0694デフォルトの名無しさん2013/10/20(日) 12:23:04.41
javascriptはチューリング完全であればなんでもいいよ
他言語から変換すればいいから
0695デフォルトの名無しさん2013/10/20(日) 17:40:53.30
そんなアホなことをしなくてもJavaScriptを使いこなせればいいだけのこと
0696デフォルトの名無しさん2013/10/20(日) 17:48:24.09
使いこなせても使いたくない
0697デフォルトの名無しさん2013/10/20(日) 17:53:42.76
損な性格してんのね
かわいそ〜
0698デフォルトの名無しさん2013/10/20(日) 18:33:12.00
まぁマゾの方が楽しめる場面もあるかもな。
羨ましくはないが。
0699デフォルトの名無しさん2013/10/20(日) 18:49:16.99
JavaScriptとか楽しすぎるんだが
0700デフォルトの名無しさん2013/10/20(日) 18:56:25.15
ブラウザでいろいろできるっていうのがいい
0701デフォルトの名無しさん2013/10/20(日) 19:06:12.31
ブラウザでいろいろできるっていうのが、JSの唯一の利点だからね
ただ、他言語からJSに変換できるようになって
唯一のアドバンテージも無くなっちゃった
0702デフォルトの名無しさん2013/10/20(日) 19:11:06.64
他言語からJSに変換ってはやってないね。
0703デフォルトの名無しさん2013/10/20(日) 19:11:47.25
そんなもん昔からできるし
JSが廃れそうな兆候とか皆無だけどな
まあ、理想を語るのは自由か
0704デフォルトの名無しさん2013/10/20(日) 19:11:47.46
ブラウザで動かすって結局はDOM操作だからね。
他の言語が変換できるといっても
DOMのAPIは変わんないし。
0705デフォルトの名無しさん2013/10/20(日) 19:12:17.00
めっちゃ流行ってる
ttps://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
0706デフォルトの名無しさん2013/10/20(日) 19:12:20.17
むしろJSがブラウザ以外で動かないという
デメリットがなくなった気がする。
0707デフォルトの名無しさん2013/10/20(日) 19:13:00.78
node.jsが出来損ないじゃなければ...
0708デフォルトの名無しさん2013/10/20(日) 19:14:05.03
DOM扱うだけならそれこそJSで十分だけどな
0709デフォルトの名無しさん2013/10/20(日) 19:16:21.08
それは言えてる
0710デフォルトの名無しさん2013/10/20(日) 19:16:51.01
>>705
あぁ、使われてないという意味だよｗ
存在するかどうかじゃない。
0711デフォルトの名無しさん2013/10/20(日) 19:17:29.66
使われてないか、どうやって調べたの？
0712デフォルトの名無しさん2013/10/20(日) 19:17:37.41
やっぱりJSってのは大企業数社が
協力して開発しているっていうのが大きいよ。
0713デフォルトの名無しさん2013/10/20(日) 19:18:28.54
Node.jsはソケット周りの問題をこの度のsocket3で片付けたし
あとはまあ、Webサーバー専用機としてみた時は改善点あるけど
バランス的には出来損ないじゃないと思うけどな

JSとしての課題はそういうのじゃなくてむしろ、
色んな環境でのAPIを揃えていくことにあると思う
ここがちゃんとしないとこの先JSerが困ることになるし
もちろんaltJSの言語にも影響する
0714デフォルトの名無しさん2013/10/20(日) 19:18:31.14
>>711
幾つものランキングを見たら判断できる。
0715デフォルトの名無しさん2013/10/20(日) 19:20:29.51
使われてるって判断したのは
どうやって調べているかというと
調べてないｗ
0716デフォルトの名無しさん2013/10/20(日) 19:22:17.37
そういう煽りはもういいよ
前に進める皆のためになる話題をしよう
今も昔も各言語はいろんな言語を参考に進化してきたろ
プログラマも勿論協力しあうべき
0717デフォルトの名無しさん2013/10/20(日) 19:25:16.48
Dartは生成されるJSコードがマジうんこだから
一目見て使われてるか分かるな
他はコードみてもわからないかも
0718デフォルトの名無しさん2013/10/20(日) 19:31:43.17
>>717
一時期のキチガイレベルと比べ物にならないくらい今はまともなコード書くようになってるよ
更に最適化もしてくれる
JSで適当に書くより早い
https://www.dartlang.org/performance/
0719デフォルトの名無しさん2013/10/20(日) 19:32:08.84
よっぽど簡単なコードでない限り、
どの言語も汚いJSコード吐き出すってーのｗ
0720デフォルトの名無しさん2013/10/20(日) 19:32:42.28
>>718
吐き出したコードが、読めないという意味です。
0721デフォルトの名無しさん2013/10/20(日) 19:35:00.24
まあ最適化とことんしていくつもりみたいだからね
TSやCSに比べたらそうだろうが、
そもそも自分で書いてない変換されたコードは読みにくいし
あんまり読むもんじゃないと思うね
0722デフォルトの名無しさん2013/10/20(日) 19:38:12.32
>>719
例えば？
0723デフォルトの名無しさん2013/10/20(日) 19:41:27.87
まあ人間が書いたコードには敵わないと思いたいな
パフォーマンスと精密さ以外では
0724デフォルトの名無しさん2013/10/20(日) 19:43:09.96
どう書こうがJSのコードは可読性悪いからな
0725デフォルトの名無しさん2013/10/20(日) 19:44:39.15
最近のJSターゲットのトランスレータ系は、結構読めるソース吐くぞ。
つーか、ヘッポコPGが書いたコードより素直で読みやすかったり。
0726デフォルトの名無しさん2013/10/20(日) 19:51:02.56
そりゃあそうだろうな
0727デフォルトの名無しさん2013/10/20(日) 20:10:23.59
altJSってJavaScriptで書くと
冗長になるコードを簡単にかけるのが売りなんで、
変換すると冗長になるのは当たり前なんだが？
やっぱり使ったことないんだろうな。
0728デフォルトの名無しさん2013/10/20(日) 20:14:04.89
それはCoffeeScriptの売りだがaltJS全体の売りではない
0729デフォルトの名無しさん2013/10/20(日) 20:15:34.71
JavaScriptってES6まで配列とかの継承出来なかったけど
ES3だかに変換するaltJSではその問題ずっと引きずらないのかな
0730デフォルトの名無しさん2013/10/20(日) 20:17:07.36
>>727
冗長だけど読めるコードに変換するんじゃん？
0731デフォルトの名無しさん2013/10/20(日) 20:20:00.23
>>730
変換する時に無駄な機能をゴテゴテ付けてくれるから読みにくい。
最初からJSで必要最小限のコードを書いたほうが読みやすい。
0732デフォルトの名無しさん2013/10/20(日) 20:21:49.41
>731
例えば？
0733デフォルトの名無しさん2013/10/20(日) 20:22:31.07
それ以前に自分で読むなら自分で書いたままのコードが一番読みやすいに決まってる
0734デフォルトの名無しさん2013/10/20(日) 20:56:43.89
>>729
ES6が殆どのブラウザで動くようになったら
ES6に変換するようになると思うよ
0735デフォルトの名無しさん2013/10/20(日) 21:54:03.45
それこそ何年かかるんだか
つうかES6で書けるならそっちで書くのでよくね
0736デフォルトの名無しさん2013/10/20(日) 21:58:36.12
今ES5で一番不満なのはProxyだなあ
これが使えなくて本当に参ってる
V8でさっさと使えるようになって欲しいんだけど
V8のProxyは旧Proxyで使いものにならない
１日もはやくDirectProxy実装して欲しい
でないとやりたいことがいつまでたってもできないわ
0737デフォルトの名無しさん2013/10/20(日) 22:00:28.85
>>735
ちゃんとした静的型で書きたい、とか？
TypeScriptはなんちゃってだし
0738デフォルトの名無しさん2013/10/20(日) 22:02:39.77
いや、もちろん多言語を使いたいってのは分かるけど
JSの使いやすさ自体がES6で結構上がるので同仕様もなくaltを使う必要はなくなると思う
0739デフォルトの名無しさん2013/10/20(日) 22:17:23.51
JSは型をチェックするのではなく揃えるようにしたらいいと思う
あとなるべくエラーを出さないってのも良いと思う

例えば数値以外は弾く
if (typeof x !== 'number' || isNaN(x)) throw 'err';

のではなくて本当にできる限り初期化するのでいいように務める
x = +x || 0

弾く必要があるときもできるかぎり抽象度の高い段階、
それこそ入力を受け取ってすぐでチェックする
つまりできるだけ早い段階で型を保証、確定させといてその後は気にしないのがコツかと
これさえ守れはそうそう躓くことは無いはずだし、大変じゃないはず

それで大人数で作るときは出来るだけモジュール化して細部を他者から呼ばせることのないようにする
0740デフォルトの名無しさん2013/10/20(日) 22:20:31.21
あと場合によっては出力値をチェックするだけってのも有効だと思う
0741デフォルトの名無しさん2013/10/20(日) 22:26:13.82
普通だな
0742デフォルトの名無しさん2013/10/20(日) 22:40:20.14
静的厨は型が動的なことを恐れすぎ
0743デフォルトの名無しさん2013/10/20(日) 22:42:57.86
静的でも動的変数使えるのってある？
型推論じゃなくてね
0744デフォルトの名無しさん2013/10/20(日) 22:49:34.59
やろうと思えばレベルならいくらでも
もし動的レベルにできるなら
それは動的言語の枠に入れた方がいい
0745デフォルトの名無しさん2013/10/20(日) 22:52:18.16
>>743
C#のdynamicとかVB.NETのOption Strict Offとか。
0746デフォルトの名無しさん2013/10/20(日) 23:19:23.65
静的動的には拘らないけど、型チェックはキッチリやっていただけると
テストコードが減ります
0747デフォルトの名無しさん2013/10/20(日) 23:25:51.62
型チェック？？？
値をチェックするのに含まれるから別にあえて型チェック意識する必要なんて皆無だろ
0748デフォルトの名無しさん2013/10/20(日) 23:36:56.09
最終的な値が合ってる間違ってるだけの情報じゃ、
関数の深い所で型エラーになってたら
間違った場所を追うのが大変ですよ
0749デフォルトの名無しさん2013/10/20(日) 23:44:54.35
型エラーって何
動的言語での話をしてるんだよね？
で、暗黙の型変換や変数が任意型のせいでエラーが出ないのを問題視してるんじゃないの？
0750デフォルトの名無しさん2013/10/20(日) 23:52:02.00
静的でも関数型のように副作用を極力できないようにしてバグが発生するのを抑えようとする中、値の変更どころか種類まで自由になる動的はないわー
動的の柔軟なところがいい場面もあるけれど、お前らの書いてるコードではほとんど必要ないぞ。
0751デフォルトの名無しさん2013/10/20(日) 23:57:18.18
何でもかんでも厳格である必要はないがな
基本軽量でやろうと思う箇所でチェック入れるので十分だと思う
もちろん動的静的両方あるんだから適時適所だが
少なくとも自分は動的のほうが好きというか便利で使いやすいと感じる
0752デフォルトの名無しさん2013/10/20(日) 23:58:15.68
柔らかいのを活かすんじゃなくて固くある必要がないんだよ
0753デフォルトの名無しさん2013/10/21(月) 00:07:09.45
まぁその辺は好みだろうがF#使ってると変なバグの入り込む余地がほぼ潰されるけど楽に書けるので動的で軽く書けるという利点が全く分からん。
F#やその他の静的関数がたは軽くかけるのに硬さの利点も併せ持つぞ？
0754デフォルトの名無しさん2013/10/21(月) 00:08:26.12
固くある必要が無いってのが皆目わからん(´・ω・｀)
固さでどんだけ助けられたことか。
0755デフォルトの名無しさん2013/10/21(月) 00:10:42.78
動的も静的も使うけど暗黙的なのもあんまり好きじゃないし型とかも明示的に書いたほうがいいわ
0756デフォルトの名無しさん2013/10/21(月) 00:10:50.79
必要があるんなら世の中全て静的型付け言語が蔓延ってないとおかしいがな
0757デフォルトの名無しさん2013/10/21(月) 00:13:28.35
>>756
それは逆も言えるだろ。必要ないならなんで全部動的になってないのよw
0758デフォルトの名無しさん2013/10/21(月) 00:15:09.81
助けられることもあるけど俺の感覚では余計なお世話感が強い
0759デフォルトの名無しさん2013/10/21(月) 00:16:37.00
>>757
適材適所って言葉を知らんのか
メリットとデメリットは表裏一体なのは
プログラマならよく分かってることだろ
0760デフォルトの名無しさん2013/10/21(月) 00:19:58.34
適所があまりないような〜。
0761デフォルトの名無しさん2013/10/21(月) 00:23:28.28
適所はJavaScriptがこれから次々見せてくれるよ
0762デフォルトの名無しさん2013/10/21(月) 00:24:47.28
え？土管がなんだって？
0763デフォルトの名無しさん2013/10/21(月) 00:25:19.22
JSの話はするな
そしていちいち突っかかるな
0764デフォルトの名無しさん2013/10/21(月) 00:25:52.98
土管じゃなくてJavaScript
0765デフォルトの名無しさん2013/10/21(月) 00:28:01.41
JavaScriptは昨今一番可能性を見せてくれている言語だから
話題に挙がるのもしかたがない
具体的な話をしちゃいけないんならこの不毛なスレがもっと不毛になってしまう
0766デフォルトの名無しさん2013/10/21(月) 00:29:01.52
JSはCの二倍速い。
0767デフォルトの名無しさん2013/10/21(月) 00:29:23.56
一番可能性があるのはD言語だろ
0768デフォルトの名無しさん2013/10/21(月) 00:33:21.03
>>759
だから適所だと思って動的使ってるところは多分適所じゃないよって話なんだが。
動的のメリットである柔軟性がバグの温床になりやすいというデメリットになるよというのもそう。
0769デフォルトの名無しさん2013/10/21(月) 00:35:55.36
>>766
asm.js的書き方でが直接対応のFFで２倍、直接非対応のCRで３倍ネイティブより遅い
マクロベンチだとだいたい５〜１０倍くらい遅いって感じが現状じゃね？
http://kripken.github.io/mloc_emscripten_talk/box2d_graph_updated2.png
0770デフォルトの名無しさん2013/10/21(月) 00:37:04.35
>>768
あなたの価値観は尊重するが
大衆とズレてることだけは認識しておいた方がいい
0771デフォルトの名無しさん2013/10/21(月) 00:38:28.68
＞＞マクロベンチだとだいたい５〜１０倍くらい遅い
これは非asm.jsの話ね
0772デフォルトの名無しさん2013/10/21(月) 00:39:14.24
自分が大衆だと思わないことだ。
0773デフォルトの名無しさん2013/10/21(月) 00:40:05.30
JSは動的なコード最適化があるので可能性は無限大。
使えば使うほど速くなる。
0774デフォルトの名無しさん2013/10/21(月) 00:40:55.49
せやな
人の意見に不毛なケチつけるのは無し
へーそういう考え方もあるのねくらいに止めとけ
大人なら
0775デフォルトの名無しさん2013/10/21(月) 00:40:58.64
大衆とは>>770のことである。
この定義は、>>770から聞きました。
0776デフォルトの名無しさん2013/10/21(月) 00:41:05.91
何でここの連中はJSが好きなのかね
Webプログラマー板にでもいればいいのに
0777デフォルトの名無しさん2013/10/21(月) 00:41:50.59
いいから、煽るなって
前向きな話をしようぜ
大衆より体臭を気にしろ
0778デフォルトの名無しさん2013/10/21(月) 00:43:03.81
>>776
使用者や環境とともに成長してきた言語だから
当然
0779デフォルトの名無しさん2013/10/21(月) 00:43:42.75
JS実行一回目でCの二倍高速。
二回目で2.5倍、10回目では3倍程度高速になります。
0780デフォルトの名無しさん2013/10/21(月) 00:45:31.05
スパコンで数値計算してるヤツにこのスレ教えたら
爆笑してた
0781デフォルトの名無しさん2013/10/21(月) 00:47:29.70
スパコンで　←　単なるユーザー、秘孔突かれて爆笑してたんだろ。
ヒデブとか言いそうだね。
0782デフォルトの名無しさん2013/10/21(月) 00:48:12.96
1780レスもあって
静的型付け言語の潜在開発生産性は今の100倍
とやらが一度も話し合われてない
話し合われそうになってもすぐおじゃんになる民度に笑うわ
0783デフォルトの名無しさん2013/10/21(月) 00:50:36.18
JSのVM作ってるヤツなんて、iccで最適化周り作ってる連中から見ればウンコだってさ
0784デフォルトの名無しさん2013/10/21(月) 00:51:06.18
ほとんどJavaScriptじゃねえか
ここにきてやっと本題話してる感じ
0785デフォルトの名無しさん2013/10/21(月) 00:51:16.46
>>779
そうなる可能性はあるよね
まあCのコンパイラも進化するだろうからアレだろうけど
自動スケーリングという策に対して
関数型言語のような厳密性アプローチか
LLのプロファイリングアプローチ、
正直それぞれ期待できると思う
0786デフォルトの名無しさん2013/10/21(月) 00:53:00.73
>>784
え、そうだったの？
動的がいいか静的がいいかって話？
こういう技術で開発が楽になるとか
コンパイラの性能が上がるとか
そういうのと思ってたんだが……
0787デフォルトの名無しさん2013/10/21(月) 00:54:44.51
>>773
> JSは動的なコード最適化があるので可能性は無限大。

動的な最適化っていうのは、
「動的で最適化出来ない」より速いのであって
静的な最適化のほうが速いよ。

なぜかというと、動的な最適化は所詮
実行時に最適化処理をするしかないから。

静的に最適化したコードを複数持っていて
実行時に使用する最適化コードを切り替える方が速い。

例えば、CPUが持っているマルチメディア命令セットごとに
DLLを作っておいて、実行時にCPUを判定して切り替えて使う
なんてものが、静的に最適化＋実行時に動的に切り替える方法の一つ。
0788デフォルトの名無しさん2013/10/21(月) 00:58:18.18
極論話だなそれ
それで済むんなら話が始まる必要すらない
そういうことを自動的にやってくれるのがJITの強みでしょうに
0789デフォルトの名無しさん2013/10/21(月) 00:58:50.07
>>787
イイエ違います。
あなたは最適化の意味を知らない。
0790デフォルトの名無しさん2013/10/21(月) 01:02:23.53
最適化はもっとスピリチュアルで神聖なものです。
0791デフォルトの名無しさん2013/10/21(月) 01:04:11.71
俺も詳しく知らないし、上手く説明できないけど、実行時でこそできる最適化ってのがあるよ
人間の書くコードもコンパイラも完璧なら理屈的に要らないんだろうけどさ
実行環境に対応するってだけじゃなくて、人の書いたコードの意味とでもいうのかな
そういうのに対応するために有効なんだって
あと、マルチコアっていうのは、そういう最適化に１，２スレッドさけやすいってのはあるかと
0792デフォルトの名無しさん2013/10/21(月) 01:04:18.03
JSにマルチスレッドなんてできんの？
0793デフォルトの名無しさん2013/10/21(月) 01:04:31.59
jsの言ってる最適化って中間言語があればいい話で動的である必要なくね？
0794デフォルトの名無しさん2013/10/21(月) 01:11:43.87
JSの言語構造が最適化に最適なのです。
その証拠にJavaはJITがあってもCより20倍しか速くなりません。
JSはそれ以上速くなる可能性があります。

20倍というのは、昔日本の研究者が発表した値で、当時結構話題になりました。
今でも、日本の研究者を馬鹿にするとき、特定国の研究者が持ち出すトピック
として使われます。
ですから、割とあてにならない話で、JSの圧倒的勝ちと言えます。
0795デフォルトの名無しさん2013/10/21(月) 01:13:18.11
>>792
エンジンの話でしょう
JS仕様自体でもマルチスレッド意識してるよ
例のES7の話になってきて、例によって今はプロトタイプがFFにあるだけだけど

>>793
別にJSが言ってるわけではないがｗ
中間言語にする過程でコンテキストが失われたり
やっぱり読めなくなるからな

http://nothingcosmos.blog52.fc2.com/blog-entry-155.html
ここで中間言語化のそういう欠点の片鱗が知れる
0796デフォルトの名無しさん2013/10/21(月) 01:14:16.98
Brainfuckでもやってろ
0797デフォルトの名無しさん2013/10/21(月) 01:16:46.82
llvmは普通にCを中間言語に変換してるね
0798デフォルトの名無しさん2013/10/21(月) 01:19:35.40
いやCPUごとにバイナリを生成すれば
静的のほうが速いからｗ
0799デフォルトの名無しさん2013/10/21(月) 01:22:44.87
同じ話を繰り返さないでいいよ
単なる荒らし目的だろうけど
0800デフォルトの名無しさん2013/10/21(月) 01:24:07.11
動的も静的もみんなちがってみんないい

みつを
0801デフォルトの名無しさん2013/10/21(月) 01:25:35.50
>>795
いや、最適化に必要な情報があるならそれは残せばいいだけで。
V8がやってる最適化はjsでないとできないこととかあるの？
0802デフォルトの名無しさん2013/10/21(月) 01:29:48.30
>>801
結果がすべてを物語っているんじゃないの？
JSはCの2倍以上速い。
これがすべて。
0803デフォルトの名無しさん2013/10/21(月) 01:31:53.90
>>802
同じアルゴリズムで書いたコードで比較してるんですよね？
すごい興味があるので、ソースください
0804デフォルトの名無しさん2013/10/21(月) 01:33:12.11
>>801
それってゆくゆくは中間言語じゃなくてそのままをJITコンパイルすればいいってことになるでしょ？
自分はただJITの可能性と中間言語の問題点を挙げただけでJSがどうとか極論はどうでもいいよ
0805デフォルトの名無しさん2013/10/21(月) 01:33:28.24
>>802

訂正しておくね。

JSはCの2倍以上速い。
ことが一件だけ確認された。
残りの数億件はCの方が速い。
0806デフォルトの名無しさん2013/10/21(月) 01:34:30.36
言語の可能性の話と宗教を絡めるのはやめろ
0807デフォルトの名無しさん2013/10/21(月) 01:35:05.89
Cの方が速いという事例があれば
Cが速いと認めてあげますよ。
0808デフォルトの名無しさん2013/10/21(月) 01:35:23.99
>>805
釣りに構うな
本当のJSerならあんな事言わない
0809デフォルトの名無しさん2013/10/21(月) 01:36:53.49
荒らし目的でJSJS言ってる奴、極端な０か１かばかり主張する
話が通じない奴に餌をやらないでください
0810デフォルトの名無しさん2013/10/21(月) 01:40:53.59
私はJSの良さを皆さんにも教えてあげたいという善意で書きこしてるんですよ
0811デフォルトの名無しさん2013/10/21(月) 01:43:20.68
舐めてんの？
そんなんでJSを布教させられるわけねえだろ
出直して来い
0812デフォルトの名無しさん2013/10/21(月) 01:45:18.61
JSはミスを誘発しやすいクソ構文だけど
実行速度はそこそこ速いので土管に最適ってことでしょ？知ってた
0813デフォルトの名無しさん2013/10/21(月) 01:46:22.14
土管には実行速度が速いことが
一番重要だからな。
0814デフォルトの名無しさん2013/10/21(月) 01:46:54.07
最速コードを書くのはいつも土管だし。
0815デフォルトの名無しさん2013/10/21(月) 01:47:35.66
とりあえず気に食わない相手は
みんな土管と言っておけば、
すっきりするよ。
はいお前土管決定ってな。
0816デフォルトの名無しさん2013/10/21(月) 01:49:04.44
土管がでてきたから俺はさっさと寝るかな。
0817デフォルトの名無しさん2013/10/21(月) 01:49:20.76
いくら土管と言われようが俺はJSが一番好きだし誇りに思う
なのでどーでもいい
0818デフォルトの名無しさん2013/10/21(月) 01:50:38.01
お前のかーちゃんどーかんｗ
0819デフォルトの名無しさん2013/10/21(月) 01:50:45.65
私も誇りを持ってJSを使っています
誇りを持てる言語ってなかなかないと思います
0820デフォルトの名無しさん2013/10/21(月) 01:51:47.11
JavaScriptは全てを受け止めてくれる抱擁力がある
0821デフォルトの名無しさん2013/10/21(月) 01:52:12.41
土方が土管に誇りを持ってるのか
字面がくどいな
0822デフォルトの名無しさん2013/10/21(月) 01:53:04.22
JSを使える優越感。
0823デフォルトの名無しさん2013/10/21(月) 01:55:37.53
どうでもいいけど、追い詰められたら
ドカタって言って逃げるのやめたら？
毎度思うけど、小学生にしか見えん。

何を言うのも勝手だけど、
こっちは小学生かよって思って見てるからね。
そのことを忘れないで欲しい。
0824デフォルトの名無しさん2013/10/21(月) 01:55:55.82
土管を馬鹿にしてるの？
0825デフォルトの名無しさん2013/10/21(月) 01:57:15.55
>>804
んじゃなおさらここで触れるべきことじゃないじゃん。
少なくとも動的ゆえに静的では出来ないような最適化ができるよってことじゃなければ。
0826デフォルトの名無しさん2013/10/21(月) 01:57:22.29
>>823土管としてしかJSを扱えない人達なんだから仕方ない
0827小学生2013/10/21(月) 01:57:30.22
はい、おまえのとーちゃんどかたけってい！！！
うまれるまえから、おまえもどかたけってーい

これでいいですか？
0828デフォルトの名無しさん2013/10/21(月) 01:59:45.94
なんか動的、静的関係なく、
コンパイル言語はコンパイルした時点でのCPUにしか対応できないが、
インタプリタ言語は未知のCPUでも対応できるって話にしか見えないんだが。

実行時にソースをコンパイルする言語なら、
静的言語でも未知のCPUに対応できるよ？
0829デフォルトの名無しさん2013/10/21(月) 01:59:54.16
>>825
JITは必要かどうかっていう話題に対して提示したんだから
このスレで話すべきことだよ
別に動的VS静的スレじゃないし、動的静的の立場で話してないでしょ
0830デフォルトの名無しさん2013/10/21(月) 02:01:35.63
インタプリタは違うな。
実行時にソースをコンパイルする静的言語は
なんて言ったらいいんだ？
0831デフォルトの名無しさん2013/10/21(月) 02:02:20.51
せっかくのスレを正常化するための話題が
静的厨には静的言語への挑戦と受け止められたらしいな
やっぱり>>782の通りになった残念無念
0832デフォルトの名無しさん2013/10/21(月) 02:02:58.72
それらはすべてJSの仲間です
0833デフォルトの名無しさん2013/10/21(月) 02:05:08.16
>>830 実行時と言っても言葉の使われ方としては
実行「中」中心ならJIT
実行「直前」中心ならAOT
コンパイルっていうけど言語としては難しいね
C言語でもやろうと思えばJIT出来るんですって言われればそうかってなるし
0834デフォルトの名無しさん2013/10/21(月) 02:07:33.69
実際にやってるのはJSだけだけどね
絶大な効果があるという意味ではね
0835デフォルトの名無しさん2013/10/21(月) 02:10:12.83
>>831
スレを正常化というけど、スレタイとは全然合ってない話題って気がするよ
そりゃ、実行速度が開発生産性に直結するような分野もあるだろうけど、大抵は違うだろ
0836デフォルトの名無しさん2013/10/21(月) 02:11:21.48
>>834
もとがクッソ遅かったから伸びしろは大きかったね
それでもまだ遅いけど
0837デフォルトの名無しさん2013/10/21(月) 02:13:37.21
>>834 Dartもやってんじゃない？
というかV8とDartエンジンってよく似た最適化導入されてるよね
SMIとか凄く特徴的だよねえ
静的言語の可能性としてはDartに注目すべきなんじゃないかな
V8とのいろんな比較もしやすいだろうし
まあまずはDartがブラウザに乗ってからが本番だけど、
この冬とか前聞いたんだけどどうなのかな
0838デフォルトの名無しさん2013/10/21(月) 02:16:57.89
>>718みるとV8はこの１年で50％以上もスコア伸ばしてるから
マクロベンチではまだまだ伸びしろあるだろうね
0839デフォルトの名無しさん2013/10/21(月) 02:23:53.35
実行時に最適化というのは
要するにJIT積んでいればいいわけだから
JITで有名なJavaやC＃からもわかるように
静的言語でも実行時に最適化できるということ。
0840デフォルトの名無しさん2013/10/21(月) 02:25:46.75
静的型付け言語の型って最大何種類あるの？最小は？
0841デフォルトの名無しさん2013/10/21(月) 02:28:16.02
クラスも入れると無限大
0842デフォルトの名無しさん2013/10/21(月) 02:29:29.09
あれ、JITは必要なくCPU毎にコンパイルすればいいんじゃなかったの？？？
0843デフォルトの名無しさん2013/10/21(月) 02:32:09.93
えぇJITよりもCPUごとにコンパイル
したほうが速いですよ？
何も矛盾しませんが。
0844デフォルトの名無しさん2013/10/21(月) 02:32:56.32
JSの実行速度が速いと言っても、JSを何に使うんだろう
スマートフォンの世界じゃHTML5アプリよりネイティブアプリにするだろう
ウェブのサーバーサイドでPHPなんかをNodeが代替するかといえば、一分にそういうケースもあるだろうけど、主流になるとは
0845デフォルトの名無しさん2013/10/21(月) 02:33:40.17
> スマートフォンの世界じゃHTML5アプリよりネイティブアプリにするだろう

お前は、ウェブサイトを全部ネイティブアプリにしたいのか？
0846デフォルトの名無しさん2013/10/21(月) 02:35:29.69
>>843
まだ同じこと言ってんのか
皆が教えてくれてるのに成長しないやつだな
0847デフォルトの名無しさん2013/10/21(月) 02:36:35.01
FirefoxOSというものがあってだな……
JavaScript＝＝ネイティブなんだが……
0848デフォルトの名無しさん2013/10/21(月) 02:36:46.63
>>846
JITが必要な理由と、
速度は別の話だって
わかりませんか？
0849デフォルトの名無しさん2013/10/21(月) 02:37:31.71
実行速度を気にするような複雑なアプリをJSで書く必要性はない
頑張ってHTML5でゲーム作るより、ネイティブで作る方が遥かに簡単で速く動く
0850デフォルトの名無しさん2013/10/21(月) 02:38:58.53
AndroidすらiPhoneよりオーバーヘッドがあって遅いって批判されてるのに、JS使ってたら話にならないと思われる
0851デフォルトの名無しさん2013/10/21(月) 02:40:56.29
ウェブサイトってのはCPUに依存しないように
しなくてはいけないからJavaScriptが必要で
できるだけ速く動かしたいからJITが必要なだけ。
そしてJITは静的言語でも使える。

速度が必要な物が、ネイティブアプリで
作られていることからもわかるように、
速度重視だとコンパイルしてしまったほうが速い。
0852デフォルトの名無しさん2013/10/21(月) 02:41:25.68
それは固定概念って奴だな
0853デフォルトの名無しさん2013/10/21(月) 02:43:05.53
誰か固定じゃない概念を示してやれ。
そうすれば、俺は勝てる。
皆の力が必要だ。
0854デフォルトの名無しさん2013/10/21(月) 02:43:48.52
だからネイティブって何よ？
ひょっとして静的言語のこと？
速度は静的は昔の話になりつつあるってまだ分かんないのかな
そうじゃなかったらFirefoxOSなんて実現するわけ無いでしょ
スクリプトからAPIを叩いて気楽に作る時代なんですよ今は
0855デフォルトの名無しさん2013/10/21(月) 02:44:20.40
隙があるレスすると
すぐにおちょくられるんだから
気をつけたほうがいいよ。
0856デフォルトの名無しさん2013/10/21(月) 02:44:34.43
>>853
皮肉の通じないアスペ乙
0857デフォルトの名無しさん2013/10/21(月) 02:45:32.74
>>854
> だからネイティブって何よ？

CPUが直接実行できる機械語が
生成済みになっているもの。
だからFirefoxOSのJavScriptはネイティブではない。
0858デフォルトの名無しさん2013/10/21(月) 02:46:02.30
>>855
この風潮ホント嫌だよな
盛り上がるにしてももっと和気あいあいといい方向で盛り上がろうぜ
0859デフォルトの名無しさん2013/10/21(月) 02:47:06.60
http://d.hatena.ne.jp/genius_strategy/20130508/1368002653

> この点を踏まえて、3つの OS のネイティブアプリケーションが実行できるかどうかを下表に示す。
>
> OS ネイティブアプリケーションの実行可否
> Android 可
> Firefox OS 不可
> Tizen OS 可

FirefoxOSはネイティブアプリは実行できないみたいだけど？
ネイティブの定義が大幅にずれてる人だね。
0860デフォルトの名無しさん2013/10/21(月) 02:47:12.22
ははあ
じゃあAndroidのJavaはネイティブでは無いのね
0861デフォルトの名無しさん2013/10/21(月) 02:48:14.65
>>859
そういう屁理屈はいいから
0862デフォルトの名無しさん2013/10/21(月) 02:49:49.05
>>860
当たり前だろ？
JSもJavaもJITを使っている以上
ネイティブではない。

Javaは静的言語だが。

さっきから静的言語とネイティブが
ごっちゃになってる人がいるんだよね。

一番速いのはネイティブ＋静的言語
0863デフォルトの名無しさん2013/10/21(月) 02:50:15.01
JavaはネイティブJSは非ネイティブ
それ以上でも以下でもない
まずは用語を勉強してからスレに来なさい
0864デフォルトの名無しさん2013/10/21(月) 02:52:56.80
>>862
Javaはネイティブじゃないって言い張ってるの君だけだね…
0865デフォルトの名無しさん2013/10/21(月) 02:58:34.82
ネイティブっていうのは直接マシン語に変換される言語
JSとかは生まれはインタプリタ言語だったが
今やLLはJITでアセンブラまでコンパイルされるが基本なのでこの分け方は当てはまらない
スマートフォンでネイティブっていうのは所謂インストールしてウィジェットとかある
つまりOSで直接強くサポートされた言語ってこと
例えばwinやMacでのC言語なんかは当にそうと言える
JavaやLLみたいなどこででも動くことを目指した言語は言語としてはそうは言えないが
その環境ではネイティブだと言っていいと思う
そういうことだよね？
0866デフォルトの名無しさん2013/10/21(月) 03:01:11.35
要するにJSやJavaはネイティブじゃないが
AndroidのJavaやFirefoxのJSはネイティブと呼ばれるってことでFAで？
0867デフォルトの名無しさん2013/10/21(月) 03:03:29.77
普通、C#やJavaはネイティブ、PythonやJSはスクリプトって言うんじゃない
0868デフォルトの名無しさん2013/10/21(月) 03:07:30.07
まあネイティブ上で動くっていうイメージの問題でしょうね
本質的には変わりない
0869デフォルトの名無しさん2013/10/21(月) 03:20:48.14
型無しでも型付きでも書けてメソッド毎に静的型付けの強制をオンオフ出来て静的言語Javaで書かれた
資産を直接利用できる動的言語Groovyはなかなか節操がないぞ。
0870デフォルトの名無しさん2013/10/21(月) 03:30:14.87
Java自体が趣味で書くには好きじゃないな
良くも悪くも土方向け言語って感触
0871デフォルトの名無しさん2013/10/21(月) 04:20:24.53
VM上で動くのをネイティブとは言わんだろ
0872デフォルトの名無しさん2013/10/21(月) 04:27:28.77
それは人間から見た視点であって結局は機械語になって動くわけだし
機械語から機械語を動的生成するみたいなのは多かれ少なかれ
どのコンパイル後コードでも内でやってることだよ
0873デフォルトの名無しさん2013/10/21(月) 05:09:43.87
自分の都合で勝手に用語の意味変えるのやめろや
0874デフォルトの名無しさん2013/10/21(月) 05:15:29.72
OSがそのままロードできもしない物をネイティブとは言わん
0875デフォルトの名無しさん2013/10/21(月) 05:18:42.92
>>864
Java Native Interfaceというものがあってだな……
0876デフォルトの名無しさん2013/10/21(月) 05:30:11.69
結局どっち？VM上で動くのもネイティブって言うの？Javaって機種ごとコンパイルとかしないよね。まあ関係ない話題みたいだけど
0877デフォルトの名無しさん2013/10/21(月) 05:33:04.65
静的型付けは、構造というかルール性の事でOK？チューリング完全な言語であれば、その上にVM的に静的型付言語を走らせる事が出来るんだよね、理屈としては
読んでて分からんくなりそ
0878デフォルトの名無しさん2013/10/21(月) 05:37:59.20
>>876
Javaは実行時にclassを解釈するJITコンパイラが間に入ってるから、
ネイティブじゃない
0879デフォルトの名無しさん2013/10/21(月) 05:48:30.72
>>878
ありがとー！
じゃあ動的言語上で動く静的言語がjava？
プログラムソースはテキスト型(でかいchar)って事で瞬間瞬間は静的な動的コンパイル言語？
難しいわ
0880デフォルトの名無しさん2013/10/21(月) 05:49:25.82
>>876-877
勘違いしてるのお前だけだろ
0881デフォルトの名無しさん2013/10/21(月) 05:52:49.53
>>880
分かってないのに口挟んだゴメン。読んでたら気になってさぁ…
0882デフォルトの名無しさん2013/10/21(月) 05:57:13.69
.NETもマネージコードとネイティブコードを区別してるね。
ネイティブがNative Machine Codeの略称だとするなら
コンパイル時に機械語に変換されるものがネイティブっちゅうことになるんかね。
0883デフォルトの名無しさん2013/10/21(月) 05:58:51.77
結局01の組み合わせで動くんだから両者に明確な違いなど無いよ
0884デフォルトの名無しさん2013/10/21(月) 06:00:11.67
>>883
食べ物を食べてうんこして死んでいくんだから猿も人間も違いなんてないみたいなｗ
0885デフォルトの名無しさん2013/10/21(月) 06:01:13.23
コンパイル時に機械語に変換されるものがネイティブ
いやいや言葉的にそれはおかしいだろ
OSが強くサポートしている言語がそのOS上でのネイティブだよ
0886デフォルトの名無しさん2013/10/21(月) 06:02:18.23
少なくともコンパイル云々とネイティブかどうかは直接的に関係ない
0887デフォルトの名無しさん2013/10/21(月) 06:05:23.46
>>885
それじゃ足りない
実行コード部分はハードウェアが直接解釈できないと
0888デフォルトの名無しさん2013/10/21(月) 06:12:42.13
>>885
そんな屁理屈がまかり通るなら
AndroidはJavaがネイティブってことになるし
Windowsは.NET、Unixはshがネイティブになるだろ
0889デフォルトの名無しさん2013/10/21(月) 06:15:06.23
いつ機械語に翻訳されるかとネイティブという言葉が結びつかないんだが
それに結局はメモリ確保とかでOSコールするんだからVM上で動いてるのと同じだがな
0890デフォルトの名無しさん2013/10/21(月) 06:15:59.94
>>888
そのとおりなんだが
0891デフォルトの名無しさん2013/10/21(月) 06:20:43.35
>>890
もう詭弁の相手するの面倒だから適当にググった
http://e-words.jp/w/Android20NDK.html
0892デフォルトの名無しさん2013/10/21(月) 06:31:49.00
普段はそんな意味で使わないくせに、なんでこういう時だけ頑ななのかな。
0893デフォルトの名無しさん2013/10/21(月) 06:32:46.48
>>891
簡単に言うと、機械語、VM上で実行されるコード、インタプリタで
実行されるソースコードをネイティブコードと呼ぶんだなあ。
知らなかった。
機械語だけを呼ぶと思ってたわ〜。
0894デフォルトの名無しさん2013/10/21(月) 06:33:41.05
プログラマってこんな頑固でいいものなの？
ネイティブとは何かって程度の話題に何百レスも使うスレの住民が
可能性なんて語れるわけないよな
今の環境に固執してるもん
0895デフォルトの名無しさん2013/10/21(月) 07:10:48.55
荒らしてる奴がいるだけだろ
0896デフォルトの名無しさん2013/10/21(月) 07:19:33.90
何かおかしいと思ったら、
HTML5との対比語のネイティブを言ってるのね。
そら文脈依存の言葉を、単独で使っちゃいかんやろ。
0897デフォルトの名無しさん2013/10/21(月) 07:29:56.73
>>894
2chにプログラマの代表が集結してる訳ないだろ。
0898デフォルトの名無しさん2013/10/21(月) 07:39:16.23
>>896
どっからHTML5が出て来た
0899デフォルトの名無しさん2013/10/21(月) 07:46:47.28
>>898
せっかくフォローしてやってるのに…。
0900デフォルトの名無しさん2013/10/21(月) 07:49:54.18
正しさなんてどうでもいいのさ
強弁して押し通すゲームだから
0901デフォルトの名無しさん2013/10/21(月) 08:02:19.79
HTML5だってFFOSならネイティブだ
スマホではアプリの審査とかいろんな特徴上の理由で
ハイブリットアプリとかJavaとHTML5というのを独特に区別してるからな
AndroidではほぼほぼWebアプリと対比したJavaアプリ
iPhoneではほぼほぼWebアプリと対比したo'Cアプリ
のことで単なる代名詞でしか無い
0902デフォルトの名無しさん2013/10/21(月) 08:06:53.71
PerlやPythonがプリインストールされてるLinuxディス鳥では
これらもネイティブだよー
0903デフォルトの名無しさん2013/10/21(月) 08:21:38.11
FFOSではC++もJavaもネイティブじゃないんですね
わかります
0904デフォルトの名無しさん2013/10/21(月) 08:26:22.60
書き換えといて
http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%E3%81%AE%E6%AF%94%E8%BC%83
0905デフォルトの名無しさん2013/10/21(月) 08:51:12.29
>>902
暗黙的にアプリとしての視点で言ってるから基本的にそれらは対象外だな

>>903
対象外
OSでサポートされててアプリが作れる言語ってことでいいでしょう
既存のスマホではできることの差、アプリの種類の名称として>>901で定着しちゃってるけど
0906デフォルトの名無しさん2013/10/21(月) 08:55:49.90
>>904
そこでは一般的な実行モデルの話であって
言語がどう呼ばれるべきかとは直接関係ない
当然文脈で異なる
0907デフォルトの名無しさん2013/10/21(月) 09:12:47.04
>>906
そこに書いてある文脈で呼ぶべきだ。

勝手にオレオレ文脈作って
誰も呼んでない適当な呼び方をするんじゃない。
0908デフォルトの名無しさん2013/10/21(月) 09:14:25.90
実行モデルの話をしていたよなぁ？
>>906は何言ってるんだ。
0909デフォルトの名無しさん2013/10/21(月) 12:15:25.76
ここ数ヶ月JSのステマをし続けてる奴がいる
何の目的かは知らないが
0910デフォルトの名無しさん2013/10/21(月) 13:41:52.12
>>905
そういうのをネイティブというのはウェブ界隈での呼び方だぞ
相当狭い世界で生きてるんだな
0911デフォルトの名無しさん2013/10/21(月) 13:54:57.76
狭いも何も最初からスマホの話>>844-847で
FirefoxOSのJavaScriptをネイティブと呼ぶべきかという話題なんだが
だからJavaScriptはネイティブってことで正しいでしょ
0912デフォルトの名無しさん2013/10/21(月) 14:12:09.10
JSをネイティブというのはさすがに違和感あり過ぎる
それより上がないから比較対象もないし
0913デフォルトの名無しさん2013/10/21(月) 14:38:09.64
だからその常識に挑戦するのがFFOSなんだって
FFOSでだってブラウザ上で動くアプリとパッケージアプリは区別されるべきだし
スマホ一般で言うにはネイティブと言っておけばいいでしょ
ユーザーから見たら変わらないわけだし
0914デフォルトの名無しさん2013/10/21(月) 14:40:48.72
お前らばか？
そんなコンテキストによって意味が変わる言葉の意味についてコンテキスト決めずに論争してもしょうがないだろ。
せめてこのスレではこの意味で使おうというならまだしも。
0915デフォルトの名無しさん2013/10/21(月) 14:43:25.56
ユーザーから見たら詐欺だろ
0916デフォルトの名無しさん2013/10/21(月) 14:48:40.06
ユーザーだけではなく開発者の視点から見ても同じ
0917デフォルトの名無しさん2013/10/21(月) 14:51:18.87
スマホでネイティブアプリと言ったらインストール可能なアプリ程度の意味しかない
ほぼWebViewだけのものとか大いにあるし
0918デフォルトの名無しさん2013/10/21(月) 14:53:58.95
それをネイティブとは言わん
0919デフォルトの名無しさん2013/10/21(月) 14:56:14.63
現にそう使われてるから
今使われてるものに当てはめるなら言えるでしょ
0920デフォルトの名無しさん2013/10/21(月) 14:58:56.53
どうせポシャるプラットフォーム上でJavaScriptやHTML5がネイティブだとか
どうとか実にどうでも良い。

というかJavaScriptやHTML5がネイティブだとか粘着し続けているのJSerという
か単なるMozilla厨かよ。
前置きもなくFFOSとか略されたところでそれが世間一般に普通に通じると思って
いるのならかなり痛い認識だぞ。
0921デフォルトの名無しさん2013/10/21(月) 14:58:57.81
いや言わないって
WevViewアプリがネイティブならSenchaやMonacaのアプリもネイティブだろ
0922デフォルトの名無しさん2013/10/21(月) 15:00:30.47
インストール型Webアプリだとブラウザアプリのこと指すし
ネイティブWebアプリだとハイブリットアプリのことを指すし
素直にネイティブアプリと呼ぶのが一番じゃないかと思う
0923デフォルトの名無しさん2013/10/21(月) 15:00:30.95
>>921
typo
s/WevView/WebView/
それと>>921は>>919へのレス
0924デフォルトの名無しさん2013/10/21(月) 15:01:54.53
OS自身の記述言語がネイティブてある。

「OS」の指す範囲は各自定義してね。
0925デフォルトの名無しさん2013/10/21(月) 15:01:55.97
>>922
ハイブリッドはハイブリッドだろ
ってか自分でハイブリッドって言ってるのに変だと思わないのかｗ
0926デフォルトの名無しさん2013/10/21(月) 15:02:34.43
>>921
それらは出力形態としてはハイブリットアプリ
0927デフォルトの名無しさん2013/10/21(月) 15:04:23.54
>>925
いいや、ネイティブアプリでいいのよ
屁理屈こねない
0928デフォルトの名無しさん2013/10/21(月) 15:08:34.02
>>927
そこまで意味を拡張してしまったら
ネイティブという用語そのものに必要性ないだろｗ
馬鹿すぎて話にならないｗ
0929デフォルトの名無しさん2013/10/21(月) 15:57:00.09
ハイブリットアプリだけは120％ないだろ…
形式が一番近いのはブラウザアプリ、というかほぼまんまで
ブラウザがOSと融合してVM的な機能も提供してるんだから
普通に考えたらネイティブアプリと呼ぶでしょ
どれだけ妥協してもネイティブアプリの風格を持ったブラウザアプリってとこだわ
0930デフォルトの名無しさん2013/10/21(月) 16:01:08.92
プラットフォームがある機能のネイティブサポートをうたうのは単体の出荷状態で
その機能に対応している場合。

なのでFirefoxOSはJavaScriptをネイティブサポートしているといって良い。
だけどそれを走らせるARMだか何だかのCPUにとってJavaやJavaScriptはネイティブ
サポートの対象じゃないね。別途JVMなりJSエンジンが必要。

成果物に関して「ネイティブ」と呼ぶのはプラットフォーム横断的な実行環境との
比較で特定プラットフォーム向けに書かれたものをさすと思うけれども。
なのでJavaScriptで書かれたFirefoxOS向けのアプリはネイティブアプリかな。
ただそれを走らせるCPUにとってはネイティブでも何でもないね。
0931デフォルトの名無しさん2013/10/21(月) 16:01:38.26
ネイティブ（アプリの風格を持ったブラウザ）アプリ
ってことでこの話はもういいよ
0932デフォルトの名無しさん2013/10/21(月) 17:28:36.32
LinuxではshとPerlとPythonはネイティブって結論でいいよね？
0933デフォルトの名無しさん2013/10/21(月) 17:38:02.75
NO
アプリとして一般的か否かは重要
所謂シェルスクリプトはシェルスクリプト
0934デフォルトの名無しさん2013/10/21(月) 18:10:06.97
プラットフォームに特化した言語をネイティブっていうんだろ
他のプラットフォームでも使えたらネイティブとは言わない
0935デフォルトの名無しさん2013/10/21(月) 18:56:30.23
>>933
一般的かどうか、どうやって決めたの？
主観？
0936デフォルトの名無しさん2013/10/21(月) 18:59:48.85
ネイティブコード＝機械語は昔からある用語

ネイティブアプリ＝非ウェブアプリは
ブラウザアプリが増えて区別するために作られた新しい用語
0937デフォルトの名無しさん2013/10/21(月) 19:04:06.51
ネイティブコードにコンプレックス持っちゃったドカタが
ネイティブじゃ無いものをネイティブって呼び出したのが起源
0938デフォルトの名無しさん2013/10/21(月) 19:38:54.94
>>936
そうそう
で、この話題は最初からそっちの方向で話し合われてる
言語ではなく環境も含んでの話だからね
0939デフォルトの名無しさん2013/10/21(月) 19:42:06.94
そんなことはどうでもいいから技術について語ろうぜ
例えばJSONってどうよ
0940デフォルトの名無しさん2013/10/21(月) 20:01:07.91
JSはソースコードがネイティブコードなので超速い。
Cはコンパイルして機械語でやっとネイティブコードなので遅い。
0941デフォルトの名無しさん2013/10/21(月) 20:14:21.23
同じこというやつに突っ込むのだけはやめろよ
0942デフォルトの名無しさん2013/10/21(月) 20:26:00.40
どう見ても荒らしたいだけだから突っ込むのやめた方がいいな
0943デフォルトの名無しさん2013/10/21(月) 20:49:47.85
突っ込む気力すらない
0944デフォルトの名無しさん2013/10/21(月) 20:51:23.76
JIT以前はC言語が速かった
JITの登場でスクリプトのほうが速くなった
0945デフォルトの名無しさん2013/10/21(月) 20:53:25.71
どうせマイクロベンチでしか比較できんだろ
適当なベンチサイトでも見て遊んでろ

ttp://benchmarksgame.alioth.debian.org/
0946デフォルトの名無しさん2013/10/21(月) 21:02:59.70
JSの実行速度は十分、それよりも64bit型とかが必要だし
なんといってもボトルネックなのはDOM操作だから
0947デフォルトの名無しさん2013/10/21(月) 21:08:06.93
もっとIDEを強化すべきだと思う
ドカタ = IDE の図式
0948デフォルトの名無しさん2013/10/21(月) 21:08:50.89
>>939
もっとJSONスキーマを使えるインフラが流行って良い。
0949デフォルトの名無しさん2013/10/21(月) 21:11:09.80
JSONはハッシュのキーに文字列しか使えないところが
最高にうざくて頭悪い
0950デフォルトの名無しさん2013/10/21(月) 21:42:31.37
この前循環参照含むオブジェクトを文字列化できないのかできないかって質問がJS質問スレであって
循環参照を解いたオブジェクトに崩してからJSON化するってので乗り切ってた
確かにJSONは表現能力もそこまで高くないし、それよりもスキーマがかっちりしてないって言うのを見るけど
ちょっと追加パーサー書けばそれなりの拡張は容易だと思う
それよりも取り敢えずシンプルで組み込みやすいって方をとったんじゃないかな
0951デフォルトの名無しさん2013/10/21(月) 22:17:08.08
拡張が容易って・・・JSONの拡張?
0952デフォルトの名無しさん2013/10/21(月) 22:22:40.01
そもそもJSONは規格なんで
勝手に拡張してはいけませんねぇ。
循環参照あるならYAMLを使うべきでしょ。
0953デフォルトの名無しさん2013/10/21(月) 22:24:35.48
循環参照なんてルートに一段かませて
そこに接続してるパス書けばいいだけじゃないの
0954デフォルトの名無しさん2013/10/21(月) 22:39:12.74
JSONの拡張じゃなくて例えば複雑な型が使いたいのなら
{
"type-string":"aaaa"
"value-string":"bbbb"
}
みたいにするとか、アプリケーション側でカバーできるってこと

あんまり高機能だとあらゆる環境での共通フォーマットにはしづらいでしょ

>>953
どういうこと？気になる
0955デフォルトの名無しさん2013/10/21(月) 22:47:44.32
>>954
複雑さの先送りがあとあと効いてきそうな感じ…
0956デフォルトの名無しさん2013/10/21(月) 22:53:49.16
>>954
{
　"object": { 本来のデータ },
　"cyclicRef": [ { "from": ["path"],"to":["path"]}, ... ]
}

>>955
複雑にして失敗したのがXMLだよ
0957デフォルトの名無しさん2013/10/21(月) 23:24:31.54
こんな感じだな
http://ideone.com/Zxp7kN
変換後の文字列も少なくていいと思う
このままだと配列がオブジェクトになってしまうが
それ以外はJSONのパワーアップ版だ
0958デフォルトの名無しさん2013/10/21(月) 23:34:24.58
>>956
そもそも循環参照を持つのはJSON化出来ないのよ
だから本物のデータとやらをJSON.stringifyで文字列化出来ない
だから例の質問では（ライブラリフリーで）一番効率の良い方法として
循環参照のない形にほぐしてJSON化するという手を取った
0959デフォルトの名無しさん2013/10/22(火) 00:24:44.59
>>957
配列に対応しておいた
0960デフォルトの名無しさん2013/10/22(火) 06:19:45.24
>>958
>そもそも循環参照を持つのはJSON化出来ないのよ
>だから本物のデータとやらをJSON.stringifyで文字列化出来ない
いやそれぐらいわかって書いてるよ
元のレスじゃ循環参照を元に戻すとは言ってなかったから
0961デフォルトの名無しさん2013/10/22(火) 06:58:11.85
>>953のレス書いた奴がそんなこと言うんだ
笑えるね
0962デフォルトの名無しさん2013/10/22(火) 07:18:33.30
>>961
え？なんで急に発狂した？
0963デフォルトの名無しさん2013/10/22(火) 07:30:31.76
FilerMakerで1日　＜＜＜　C#ポトペタ+NuGetで1週間　＜＜＜　HTML5+Ruby,PHP,Javaで1ヶ月
http://engawa.2ch.net/test/read.cgi/poverty/1382394266/
0964デフォルトの名無しさん2013/10/22(火) 07:42:55.09
寝起きで頭がまわらないのは理解するがもう少し良く読みよく考えてから書き込んでくれな
0965デフォルトの名無しさん2013/10/22(火) 07:57:05.69
話ぶった切るけどJSONの妥当性検証ってどうしてる?

* JSONスキーマ
* JSONマッパー提供のバリデーション機能
* アプリケーションロジック内でなんとなく
* その他
0966デフォルトの名無しさん2013/10/22(火) 08:04:27.48
>>964
説明する気もないなら黙っとれ
0967デフォルトの名無しさん2013/10/22(火) 08:13:56.30
JSONスキーマ一択
0968デフォルトの名無しさん2013/10/22(火) 08:14:29.00
>>965パース関数にかけて通れば妥当
TwitterのStreamingAPIみたいに断片で続けて送られて来るときはもはやそうするしか無い
0969デフォルトの名無しさん2013/10/22(火) 08:40:31.99
>>968
検証できるよ。
0970デフォルトの名無しさん2013/10/22(火) 08:47:56.99
うん、だからパース関数にかけてみればいいよね
0971デフォルトの名無しさん2013/10/22(火) 09:17:26.46
>>970
うん、だから正当なJSONであるだけじゃなく、
データ構造の妥当性の検証もできるよ。
0972デフォルトの名無しさん2013/10/22(火) 13:56:44.32
灘高校生
http://uni.2ch.net/test/read.cgi/newsplus/1382414731/
「いまさらエクセルを学ぶより、プログラミングを学ぼう。できて当たり前の時代が来る」
0973デフォルトの名無しさん2013/10/22(火) 14:22:26.61
>>970
well-formedとvalidはちがうやろ
0974デフォルトの名無しさん2013/10/22(火) 17:13:33.47
JSONの妥当性と言ったらフォーマットの妥当性の様に聞こえる
0975デフォルトの名無しさん2013/10/22(火) 18:33:23.89
例としてJSONスキーマやアプリケーションロジックでのバリデーションをあげているので
well-formedではなくvalidのチェックだと解ると思うけど。
0976デフォルトの名無しさん2013/10/22(火) 18:36:24.96
HTML5/WebアプリってVBアプリの工数10倍かかるのにの人月1/2だよね。見積書いてる奴バカなの？
http://hayabusa3.2ch.net/test/read.cgi/news/1382432343/
0977デフォルトの名無しさん2013/10/22(火) 18:50:42.69
それJSONあんま関係なくね
0978デフォルトの名無しさん2013/10/22(火) 19:00:49.05
次スレは？
0979デフォルトの名無しさん2013/10/22(火) 19:40:36.94
コンビニのレジと同じくらいの給料なんじゃないの？
0980デフォルトの名無しさん2013/10/22(火) 22:13:50.77
これ今月のスレかよ
むっちゃ伸びてんな
0981デフォルトの名無しさん2013/10/22(火) 23:56:53.88
>>839
そう。このスレでは動的型付けと動的最適化がごっちゃになってる。
0982デフォルトの名無しさん2013/10/23(水) 10:36:01.41
次スレそろそろ要らないな
0983デフォルトの名無しさん2013/10/23(水) 19:02:30.06
>>839
JavaもC#もJITは言語レベルよりずっと下の
静的型付けとか関係ないレイヤで行われるんだけど？
0984デフォルトの名無しさん2013/10/23(水) 19:19:07.44
だから何？
0985デフォルトの名無しさん2013/10/23(水) 19:37:05.58
結局静的言語ならではの何かなんて語るほど無いってことなんだからスレタイが悪いんでしょ
次スレ建てるんなら「プログラミング言語の潜在開発生産性は今の100倍」とかにしてね
0986デフォルトの名無しさん2013/10/23(水) 19:39:48.61
>>985
だから動的は糞て静的関数型の方が遥かに生産性がいいってFAでてんじゃん(´・ω・｀)
0987デフォルトの名無しさん2013/10/23(水) 20:09:43.82
JavaScriptは糞って一応の結論は出た形かな
0988デフォルトの名無しさん2013/10/23(水) 20:31:19.12
JSがクソだから動的型付けはクソっていうなら、
Cがクソだから静的型付けはクソってのと同類だな
0989デフォルトの名無しさん2013/10/23(水) 20:37:14.27
>>1の
＞コンピュータがコードの意味を正確に認識できる方法が必要。
＞実行しないとわからないことはコンピュータは認識できない。
＞静的型付け言語であれば、実行しなくてもわかるのでコンピュータが理解できる。
＞そうすれば様々なコンピュータの高度な情報支援が得られる。

は要するにIDEの、コードを書く時の場合だけど
IDEが100倍も良くなることなんてあるの？
今で十分だと思うんだけど、この辺りが語られてない

あとは最適化についてはそこそこ語られたけど
開発ってのは書いてコンパイルして終わりじゃなくて
もっと運用とかの面も入れたほうがいいと思うから

次スレではそういうとこ話そう
0990デフォルトの名無しさん2013/10/23(水) 20:44:35.91
開発効率を上げる方法について語るスレでええな
0991デフォルトの名無しさん2013/10/23(水) 20:58:10.06
実質はJSを褒め称えるスレなんだけどね。
0992デフォルトの名無しさん2013/10/23(水) 21:34:00.12
JSのエンジンが凄いという話は出たがJSが凄いという話は出てないし
そもそも特定の言語について語るスレではない
どの言語がいいかではなく言語を使うときの開発力向上について話すスレだ
0993デフォルトの名無しさん2013/10/23(水) 21:52:38.30
という建前で、JSを褒め称えるスレなんだけどね。
0994デフォルトの名無しさん2013/10/23(水) 22:01:04.82
というのは幻想で、現実は貶されとそのフォローしか無かったけどね
0995デフォルトの名無しさん2013/10/23(水) 23:50:43.97
>>993
信者のキモいマゾっぷりがさらけ出されただけだがな(´・ω・｀)
0996デフォルトの名無しさん2013/10/23(水) 23:56:40.59
動的も静的も生産性は同じでFA？
0997デフォルトの名無しさん2013/10/24(木) 00:17:36.33
>>996
少なくとも静的関数型も動的もみっちりやった人が言うのでなければ話にならんわ。
ここで動的サイコーとか言ってる奴はロクに静的関数型触ってないし( ´Д`)y━･~~
0998デフォルトの名無しさん2013/10/24(木) 00:35:37.86
どちらもそれなりにやってきたが
結局はどれだけ分かりやすいエラー吐いてくれるかに尽きる
0999デフォルトの名無しさん2013/10/24(木) 01:14:13.25
今使える話と将来使えるよと言う話の間で全く話がかみ合っていない。
1000デフォルトの名無しさん2013/10/24(木) 01:35:47.04
あぁ、次スレ建てなきゃな。
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。