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

1 ：2013/10/25 〜 最終レス ：2013/10/28

人間がやっていたことを、コンピュータにやらせる。
これが生産性を上げる最大の方法。
コンピュータは間違わない、同じ事を何度も高速に行える。
その為に、コンピュータがコードの意味を正確に
認識できる方法が必要。実行しないとわからないことは
コンピュータは認識できない。
すなわち静的型付け言語であれば、実行しなくてもわかるので
コンピュータが理解できる。そうすれば様々な
コンピュータの高度な情報支援が得られる。
コンピュータのバックアップを受け、人間の生産性は
限りなく向上する。
前スレ
静的型付け言語の潜在開発生産性は今の100倍 ×2
http://toro.2ch.net/test/read.cgi/tech/1380987002/

2 ：

タイトル変えることになってただろ
糞スレのまま立てんな

3 ：

>>1
サンクス。
やったけど、立てられなかったんだ。
>>2
なんでも自分の意見が同意を得られてると
思うんじゃないよ。

4 ：

生産性が高いんじゃなくて速度が速いだけだよね？

5 ：

いいや再利用性によって開発効率を底上げできる

6 ：

再利用なんてしない
毎回作ったほうがその度に良くなるし、スキルも上達する

7 ：

マシン語でも使ってろ

8 ：

生産工数は生産物の耐用期間数の平方根に比例するとか何とか言っとけばみんあ平和

9 ：

自分は再利用はするがコピペはしないな
見て良いように変えながら移す
一手間をかけるといつどんなコード書いてきたか思い出せるから便利よ

10 ：

本当に再利用する箇所はコンポーネント化しとく
これはDelphiやってた頃に習慣になった
一度作るとずっと使えるし、修正したいときも継承すりゃいいだけ

11 ：

型さえ合えばそのまま流用できるとか
どこまでお花畑なんだろ静的厨はw

12 ：

>>6
それはスキルが伸び続けるのが条件だよね
ここにいるのは、もう成長曲線が平らか下がってるようなおっさんばかりだぞ

13 ：

関数型ならわかるけど
動的から静的型付けにすると再利用性あがるの？

14 ：

まず上がらないね。

15 ：

ソフトウェアの価値は高くなるね
そういう意味では再利用性は上がると言えなくもない

16 ：

静的型付け言語でも再利用をする気がないやつには無理
そもそもそういう奴には動的型付けが向いている

17 ：

再利用性は動的のほうが高い。
静的型で真面目に仕様から型を抽出してマメに設計してあればしてあるほど
別のプロジェクトで再利用できる可能性は低くなっていく。
案件ごとに型名も型の実装も全然別ものになるからな。
気がついたらスクラッチから書き直したほうが早かったなんてことになる。
動的型ならメソッドなど再利用する部分について必要な部分だけ置き換えて
合わせてやればいいから、簡単。

18 ：

一般化したものを抽出する知能がなく特殊化したクラスを抽出することしかできない奴に噛みつかれてしまった

19 ：

リファクタリング最高だぜヒャッハー！
これは動的型付けには真似できんだろ

20 ：

ではPOS分析システムの「顧客」型を扱う売上集計用の関数を
証券システムの「顧客」型に適用できるのかい？

21 ：

>>19
リファクタリングって元は動的型言語から生まれた技術だってことは
もう過去スレで何度も出てきているのに読めない文盲のバカですか？
お大事に。

22 ：

起源と優劣の区別すらつかないの？

23 ：

リファクタリングもコンプリーションもユニットテストも
動的言語が元だねw

24 ：

>>22
何も生み出せない静的型言語ぷぷぷ

25 ：

静的型の最大のメリットは
ドカタが仕事した気になれることw

26 ：

ドカタ言語の代表格 PHP,Perl,Ruby,Javascript
あれ?

27 ：

>>19
その2つに共通するものを抽出した上位クラスを作って
次のシステムに再利用する顧客ベースクラスをつくろう
という発想が皆無な時点で
脳に一般化を妨げるある傾向がみられる

28 ：

アンカー間違ってた
>>19じゃなくて>>20

29 ：

>>27
ぷぷぷ
じゃあPOSでの「顧客」と証券での「顧客」の上位クラスって何を定義するんだい？
いっとくがPOSでの顧客なんて一意性すらないぞw

30 ：

今の動的言語のほとんどはCで作られてるからCが最強だな
を地で行ってるのが>>24

31 ：

>>27
こういう場合普通はAdaptorパタンだと思うが

32 ：

今時の動的言語でC実装しかない言語なんて少数派だと思うが。
PythonにすらPyPyがあるしRubyにもRubiniusがあるし。

33 ：

再利用の一般論を話してるのに
反証にすらならない特殊な事情に引きずり込みたいらしい
POSの顧客がどうなってるかなんか知らんよ

34 ：

>>33
中身を知りもしないのに型の名前が同じなら再利用できそうな気になっちゃう静的脳w

35 ：

論理の飛躍を指摘したのに、
今度は存在するだけでそれが主流という飛躍した論理で反論するのか
会話の通じない相手とは話したくないな

36 ：

動的型言語は賢くなくても使いこなせるのがメリットだと、煽りじゃなくそう思う

37 ：

POSの顧客だけじゃなく案件ごとに違うものなんていくらでもある
「商品」だって案件ごとに違うし
「取引」だって案件ごとに違う
「名前」だって案件ごとに違うぐらいだw

38 ：

動的型って言っても型注釈がないだけでメタ的な型はあるから
実はよく訓練された静的型脳じゃないとまともに扱えないという矛盾

39 ：

なんだよ動的静的関わりなく
そもそも再利用できない例だったの？(顧客の例)
イヤらしいな

40 ：

動的型なら売上引っ張るラッパー書けば一発じゃないの？

41 ：

あ

42 ：

型付け関係ないな

43 ：

C++方式が一番いいんじゃないの？
動的と言っても言語の設計者が決めたルールで動的でしょ？
C++なら変換関数を自分で書けるじゃないの。
RTTIもあるし。

44 ：

いまのところおまえしか解らん顧客に関する特殊な事情をもっと具体的にコードレベルで頼む

45 ：

ダックタイピングって的確な表現だよな
ほんとに型を前提にしない動的言語のコードなんてほぼ存在しない

46 ：

C++ RTTI＝互換性低下させるだけのゴミ

47 ：

スクリプト言語こそ型判定しまくりで本末転倒なことになってるけどね

48 ：

>>47
そりゃお前が下手糞なだけw

49 ：

>>44
わかってないのは君だけw

50 ：

うわぁ捨て台詞を吐いて逃げやがった

51 ：

顧客や商品なんてどこも似たようなもんだぞ
レシート見てみ？どこも大差ないぞ

52 ：

動的型付け言語は、
* メリット
** ライブラリを作成時、型に縛られないから使いまわしがしやすい
** バグがありそうなロジックにブレークポイントを仕込んどけば、デバッグ中に動的にコードの修正をしながら、ステップを進めたり戻したり、データをデバッグ用に差し替えたりが用意
** 汎用性のある連想配列
** ビルド時間皆無
* デメリット
** 静的とは相対的に遅い
** リファクタリングの時に困る
** うっかりミス(Typoとか型間違えとか)の時にやばい
静的型付け言語は、
* メリット
** コンパイル成功 ≠ バグが取れた
* デメリット
** UI、ソケット、非同期等、大抵のシステムではメリットのコンパイル成功 ≠ バグが取れた、の恩恵にありつけない
** 動的型付けのメリットにありつけない
ピュアなJavascriptの開発に限界感じてるのはGoogleも表明してるし、げんにDartとかも登場してるし、
C#にもReflectionで動的なプログラミングを可能にしたり、
HaxeでもDynamic使ってJavascriptとの橋渡しを、提供したり、
ケースバイケースで双方良いとこは取り入れて入ってる感がある、
動的onlyや静的onlyはむしろ最近じゃめずらしい。

53 ：

>>52
やっぱりわかってないな。
静的型付け言語の一番のメリットは
影響範囲が正しく分かるってことだろ。
大規模のアプリで、オブジェクトがあちこちにわたっていたり、
使われていたりする時に、何かを変更した結果が
どの範囲に影響を及ぼすかがわかる。
そんなこまごまとしたメリットなんてどうでもいいよ。

54 ：

動的型付け言語で困るのが、
これ？変更しても大丈夫だろうか？っていうこと。
どこで使われているかわからないから
不用意に変更できない。
かといって、調査に時間が掛かる。
たまたま同じ名前なのか本当に同じなのか。
この関数を呼び出しているのはどこかのか
同じ名前の違う関数ではないのか、
これの引数に入っているオブジェクトは何なのか
それ以外にありえないのか。
大規模になればなるほど調査に時間がかかり、
それぐらいのコストを掛けるぐらいならと
場当たり的な対応をし、すぐにコードが汚くなり
保守が不可能になる。

55 ：

>>29
実際に何かをリファクタするとしてそれらを共通化しようとするバカいねーよw
そんな例しか出てこないところに無能っぷりがかいまみえる。

56 ：

>>52
>動的型付け言語は、
>* メリット
>** ライブラリを作成時、型に縛られないから使いまわしがしやすい
暗に静的言語同様のインターフェース決めとかないと使い回しできない。
前もってインターフェース決めていいなら静的型付けでも実現可能。
>** バグがありそうなロジックにブレークポイントを仕込んどけば、デバッグ中に動的にコードの修正をしながら、ステップを進めたり戻したり、データをデバッグ用に差し替えたりが用意
嬉しいか？静的型付け言語でもデバッガでブレークポイント貼れるが。
>** 汎用性のある連想配列
静的型付け言語で連想配列がかけないとでも？
>** ビルド時間皆無
ほんのちょっと嬉しいかもしれないが下記デメリットの前にはどうでも良いレベル。
>* デメリット
>** 静的とは相対的に遅い
>** リファクタリングの時に困る
>** うっかりミス(Typoとか型間違えとか)の時にやばい
>静的型付け言語は、
>* メリット
>** コンパイル成功 ≠ バグが取れた
ニアリーイコールっていう意味か？
静的型付けだろうが動的型付けだろうがエラーなく動いたぐらいでバグがとれたとは言えない。
>* デメリット
>** UI、ソケット、非同期等、大抵のシステムではメリットのコンパイル成功 ≠ バグが取れた、の恩恵にありつけない
同上。
>** 動的型付けのメリットにありつけない
当たり前。動的型付けのメリットにありつけたらそれは静的型付けに比べた動的型付けの
メリットではない。

57 ：

誰かが呟いてたけど動的の人は型を制約として捉えるけど静的な人は保証と捉えると。
互いのその認識踏まえた上で話しないと何時迄も平行線だろ。
自分は静的の人ですけどね(´・ω・｀)

58 ：

だから静的も動的も型推論も使える言語が一番いいんだよ

59 ：

>>52
>** バグがありそうなロジックにブレークポイントを仕込んどけば、デバッグ中に動的にコードの修正をしながら、ステップを進めたり戻したり、データをデバッグ用に差し替えたりが用意
へー。動的型付け言語ってステップ戻せるんだ。
確かにレジスタとかメモリアドレスとかコンパイル時に決められるわけじゃないから、
ある程度は可能か。それはいいかも。

60 ：

>>58
C++/CLIですね、わかります。

61 ：

デバッグ時にステップ戻せる言語って何？

62 ：

>>61
それは言語じゃなくて動作環境含むデバッグ環境だろ。
c#だって技術的にはできると思うよ？

63 ：

思うとか、言語じゃなくてと言われても。
環境でも何でもいいけど、実際にできる言語って何よ。

64 ：

OCamlのocamldebugとかかな

65 ：

>>64
おーすげえ。教えてくれてありがとう。

66 ：

>>61
VB6
http://homepage1.nifty.com/rucio/main/dotnet/shokyu/standard41.htm
> さらにステップ実行中にコードの左側に表示されている黄色い矢印をマウスを使って
> 上下に移動させることもできます。移動させると移動先の行から実行を
> 再開することができます。もう一度処理を実行させて試したい場合や、
> 処理を飛ばして先のほうを実行したい場合などに便利な機能です。
しかも静的型付け言語でありながら、動的型付け言語の機能も備えている。
コンパイルもできるし、インタプリタ実行もできる。
イミディエイトウィンドウで作った関数を
すぐに実行したりできる。

67 ：

VB6じゃほぼ動的言語じゃねえか。

68 ：

だから両対応だって。
型をちゃんと書けば
静的になる。

69 ：

型指定なんて直接API触る時ぐらいだったよ。
大多数がまともに使ってないだろ。

70 ：

>>69
型指定なしでどうやってインターフェース継承使うんだよ？
お前が使ってないからって、みんなお前のレベルだと思うな。

71 ：

そんな時のObject

72 ：

>>66
> ただし、飛ばした部分のプログラムは一切実行されないなど
> 通常のプログラムとは異なる特別な順番で実行することになりますので
> その点には注意を払ってください。
良く知らんが、すげーいい加減なんだな
ステップを戻したときに、ちゃんと全ての状態を巻き戻して実行してんのか疑問なんですけど

73 ：

>>70
少なくとも自分の周りでまともにクラス設計してる奴なんていなかったよ。
平均的なVB6プログラマなんてこの程度だと思ってたけど違うんか？

74 ：

VB6使うプロジェクトって、VBAでExcelとか?

75 ：

>>72
ステップをもどしても一切巻き戻したりしませんが？
>>73
お前の周りではそうだったとしても、みんながそうだと思うなよ
型指定しない変数を普通に使うやつは平均以下のプログラマだ
すくなくとも俺の周りではな

76 ：

型推論により省略可能な場合はどうなりますか

77 ：

>>75
> ステップをもどしても一切巻き戻したりしませんが？
だっせぇ。よくそんなんで話に入ってこようと思ったな
しょせんVBか

78 ：

>>75
俺はATLでコンポーネント作る担当だったんだけど、
てっきりVB6自体がそういうツールなんだと思ってた。
真面目に書いてる人もいたのか。

79 ：

>>78
君に賛同する

80 ：

日本のソフトウェア技術力が
低いのなんて今に始まったことではない。
少なくとも言えることは、
使ってない人が多いという話（人間の問題）と
言語自体の機能の話は分けて考えるべきだ。
言語の話を使ってい時に、そんなの使ってる人
いねーよというのは反論でも何でもない。

81 ：

>>77
そのVBができることが
出来ない言語が大半なんですが？
動的言語であってもね。

82 ：

巻き戻せないのなら意味ない
うっかり飛ばしてしまったように２，３ステップ分記録を持っとけばいいだけ

83 ：

InteliTrace便利ですし

84 ：

未だに動的言語ではリファクタリングできないと思い込んでる馬鹿がいるんだね

85 ：

>>61
GEMSTONE

86 ：

静的型マンセーしてる人って、本物の動的型を使ったことない人ばかりだよねw

87 ：

>>86
本物の動的型てなんぞ？

88 ：

最低でもLISP, PROLOG, SmallTalkの3つはマスターしてないと
動的型なんて語れないでそ

89 ：

>>88
その3つをマスターしてる人なんているのかな。
マイナーなものばかり、生産性が高いんだったらもっと使われててもいいような気もするが。

90 ：

>>88はマスターしてないと思うが、
自分が知ってる動的型プログラマは3つとも使える人が多い。
どれも言語仕様はすごくシンプルだしね。

91 ：

>>90
マスターしてないんだったら語れないじゃんｗ

92 ：

生産性低いに決まってるだろ。
ああだから生産性は高い、こうだから優れているって言い訳ばかりで、
何の実績もないまま20年経った。

93 ：

>>92
どの言語も実績はある。おまえが知らないだけ。

94 ：

そういやルンバはLISPで動いてるんだっけ？

95 ：

>>93
PROLOGはシグマプロジェクトで大活躍したって聞きました（皮肉）

96 ：

静的厨って、第五世代とΣの違いもわかってないアホ揃いなんですねw

97 ：

プロトタイプベースが分かってない奴は多いし
JavaScriptなんかでは理解しなくても一見クラスベースっぽくできるからね

98 ：

93
誰も知らない無名ソフトならそりゃどんな言語でもあるだろ。

99 ：

>>96
どっちでもいいよｗ

100 ：

>>99
わかりやすい勝利宣言、おめでとう！

101 ：

プロトタイプベースでJSなんかを例に出すのはニワカだな
通はSelfを使うものだ

102 ：

>>88
関数型も論理型もオブジェクト指向も本質は動的型なんだな。

103 ：

一人で開発するならまだしも多人数で開発するとなると
自分が作った関数がどっから呼ばれるのかわからないから
引数をチェックして対応できるか判断するのが当然なんだけどね。
開発の規模が大きくなるにつれて型を書かなくていいってことが裏目に出る。
TypeScriptで型が導入されたのはそういう理由だろう。

104 ：

JSに変換する言語なんてコンパイルまでの間にいかに恩恵があるかってことだから
TSは型を入れてみましたってとこで必要急務だからってわけではないかと

105 ：

>>104
恩恵のために型を入れたんだろ？
何を言ってるかいみふ(´・ω・｀)

106 ：

Selfってプロトタイプ付け替えたり簡単に出来ないじゃん
二流だよ

107 ：

>>105
別にお前に話してないんだが
絡んでくるなよ気持ち悪い

108 ：

>>105
動的型言語からJSへの変換なんてのもあるが？

109 ：

>>98
自分の無知を動的言語のせいにするのって
最高にカッコイイですね
今日の君は最高に輝いているよ！



くすくす

110 ：

>>107
独り言ならちっちゃい声で言えよ。
大声で>>104のようなことを言われると何事かと思うだろ（ささやき声）

111 ：

CSとTSは特殊でベターJSを目指して作られたものだろう？
他言語のトランスレーションとはまた異なるよ

112 ：

だってよ
独り言気をつけろよ>>103

113 ：

>>110
一人芝居乙

114 ：

>>102
Haskell、OCaml、F＃「……」

115 ：

HaskellもF＃今では動的型を取り入れて完全な静的型じゃなくなってる

116 ：

>>112
>>103は独り言じゃないが。お前らに対して言ったことだが。
返信してくれても全然構わない。自分の殻に閉じこもってお前に話してないだ
なんていう冷たい態度は取らないし気持ち悪いとも思わない。安心してかかってこい。

117 ：

お前がそう思うってだけの戯言に付き合う奴が居ると思ってんの？
一般的に言えるならソースを示せ
そうじゃないんならここはお前の日記帳じゃないんだがら自重しろ

118 ：

命令型の始祖は機械語
関数型の始祖はLISP
オブジェクト指向の始祖はSmallTalk
論理型の始祖はProlog
計算の本質に静的型は不要
静的型はしょせん検査にすぎない

119 ：

世の中にVB6以上の開発環境があるだろうか
プログラマのわがままのほとんどを受け入れてくれた
唯一不可能はのは単独exe配布だけだな

120 ：

>>115
Haskellはライブラリレベルのサポートじゃないの？
ライブラリで良ければ、いくらでも動的型をエミュレートできるよ

121 ：

>>117
俺はソース出さなくてもいいという立場だからソースを出さなくてもいいが、
お前は付き合って欲しければ一般的な事柄でありソースが必要だという立場なんだから
ここが俺の日記帳じゃないことのソースを出せｗ

122 ：

チューリング完全なんだし当たり前

123 ：

>>120
違うよ。
型クラスのメソッドの名前解決に実行時型情報が必要な場合があるから。

124 ：

それって実行時型情報が合わなくて実行時エラーが出たりするの？
それとも、静的型OOPのポリモーフィズムみたいなもん？

125 ：

実行時エラーにはならない。名前解決可能であることは型検査で保障されている。

126 ：

型付けをオプションにすればいいじゃんというけど
書く人によって様変わりする言語はそれはそれで問題がある
習得後個人で使う分には良いんだけど

127 ：

入門書が糞な書き方ばかり紹介してるのはどうにかしたい

128 ：

>>125
動的型なのに型エラーが出ないなんて完璧ですね
他のウンコ言語も見習うべきだと思います

129 ：

は？
むしろ動的型では暗黙の型変換でエラーが出ないっていうのが
見つけにくいバグにつながって困るよねって話だろ？？？

130 ：

>オブジェクト指向の始祖はSmallTalk
オブジェクト指向の元祖はSimula。
SmallTalkがオブジェクト指向の元祖だと思ってる奴はニワカ。

131 ：

>>128
そうだね、動的型を使えないウンコ言語は
動的型を取り入れたHaskellのように
動的型言語を見習うべきだと思います

132 ：

>>130
Simulaはクラスの元祖ではあるけどオブジェクト指向の元祖じゃないよ
この違い、わからないのかなー？

133 ：

>>130
チューリング賞受賞者をニワカ呼ばわりですか？
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

134 ：

実行時になるまで型エラーが見つからないなんて
劣ってるよね間違いなく

135 ：

Simulaもチューリング賞をsmalltalkより先にもらってるわけだが。

136 ：

>>135
で、そのSimulaの2人が「俺達こそがOOの発明者だ」と主張しているの？
それとも単に尻馬に乗った他人が「Simulaが元祖だい！」とわめいているだけなの？

137 ：

実行時の型エラーというか
実行時に想定外の型が入ってくるのを事前にチェックしづらいってのが問題
でもそのかわり関数の戻り値とかを
型にこだわらないバラエティに富んだものにして
柔軟な思想で設計ができる
それと、確かに型チェックも重要だが、
そもそも値が適切か調べる過程に型チェックを十分内包させられるという考え方もできる

138 ：

同じマイナー言語でも、Haskellと比べたらSmalltalkは時代遅れ
もはや存在意義なし

139 ：

>>123
動的バインディングにしたらtemplate使えなくなるよね
もっと具体的にどういう場合か教えてほしい。

140 ：

あ、意味がわかった。
OCamlと同じ仕組みの事を言ってるのか。
なーんだ。

141 ：

>>115
F#っでってなんのこと言っとる？
どう的要素の取り入れなんてあったっけ？

142 ：

>>118
型がなくて困ったことが起きたから型が出てきたんだろw

143 ：

型がないとコード書けないドカタが増えたからな…

144 ：

ドカタで十分な仕事も増えたぜ…

145 ：

そう言う割に型チェック演算子とかnilとかhasattrとか普通に使ってるけど
型推論を持ってる静的型使えばいいだけじゃないの？

146 ：

型推論があっても型付けできないけど
動的型ならちゃんと動くコードってのもあるからなー

147 ：

>>146
そういうコードって結局テスト必要jになるんじゃないの？
外部で書いてたら意味ないじゃん。

148 ：

静的型だってテストは必要だが？

149 ：

世の中には2種類のテストがある

150 ：

>>148
そういう曖昧な型のためのテストは必要なくなるでしょ。

151 ：

俺が書いたテストとそうでないテストだ

152 ：

>>150
ポリモーフィックな型ならどのみち異なる型の組み合わせに対するテストは必要だろ？

153 ：

>>152
静的型は想定していない型は受け付けないから、動作見るだけでいいけど、
動的型は想定していないオブジェクトを受け入れるかどうかの境界のテストも必要になる。

154 ：

静的型はコンパイルさえできれば型の問題はないことが保証される。
動的型は型のチェックをちまちま書いてテストして型の問題が
見つからないことが確認できるだけ。業務では使えないよ。

155 ：

>>154
つまり、実行時に NullPointerException が発生しうる
JavaやC#は業務では使えない、ということだよね！
すごく説得力があるな

156 ：

>>155
そういう曲解して楽しいもんなのかね。理解できんわー。

157 ：

>>155
Maybeモナドも知らんのか。
皮肉のつもりが無知を晒してるだけだな。

158 ：

曲解なのかどうか検証してみようw
>>154
>静的型はコンパイルさえできれば型の問題はないことが保証される。
これは正しい
ただし、JavaやC#では、実行時にNullPointerExceptionが発生しうるから、
コンパイルを通過しても型に問題がないことを保証できない

>動的型は型のチェックをちまちま書いてテストして型の問題が
>見つからないことが確認できるだけ。
同様に、JavaやC#でも、テストによってNullPointerExceptionが
起きないことを確認できるだけ

>業務では使えないよ。
動的型と同様に、静的型として欠陥品のC#やJavaも、業務では使えない

159 ：

>>158
>ただし、JavaやC#では、実行時にNullPointerExceptionが発生しうるから、
>コンパイルを通過しても型に問題がないことを保証できない
なんでそうなるんだよ。
型に問題ないのが保証できなきゃコンパイル通らないよ。
お前が言ってる事は静的型・動的型なんて関係なく、
Null値を許容している限り、実行時エラーは起こりうるという事だろ？
それでもまだ突っ込みどころがあるわけだが。

160 ：

>>159
Null値のデータ型は？www

161 ：

警告ゼロでコンパイルが通るのに動かないコードなんて山ほどあるし動的と静的で
テストの記述量が極端に違うとも実感としてはあまり思えない。
テストの両云々は両者の差を語る視点としてはやや弱い気がする。
それでも自分は型をつけて記述するけどね。そっちの方が楽だから。

162 ：

>>159
おまえがバカだということはよくわかった

163 ：

>>158
nullpointerexceptionが型が原因の例外だと思ってるのか？
値の例外だが。

164 ：

>>163
nullの型を言ってみろw

165 ：

このスレの静的厨って本当に型理論をまるっきり知らないんだなw

166 ：

>>158
だからこそMaybeやoptionとかでより厳しい型を組み込もうとしてるんだが。
nullプギャーwとか言ってるのは自由な値を許容してる動的型に対して天つばしてるのと同じだぞ(´・ω・｀)

167 ：

dynamic example = (dynamic)String.Empty;

168 ：

>>166
nullを受け入れておいて動的型プギャーwとか言ってる馬鹿に言ってやれw

169 ：

静的厨ってほんと自分の無知を棚に上げた独善ばっかり

170 ：

結局C++方式が一番良かったってことじゃないの？

171 ：

性的口付けこそ最強

172 ：

JVM方式が現実的。
言語間の優越を問うよりも必要に応じて言語を使い分け。
後は言語間で如何にスムーズに連携できるかが大切。

173 ：

JVMってSmallTalkのアーキテクチャの劣化コピーだってね

174 ：

時代はPolyglot programmingですよ。
そのための実行基盤としてはJVMと.Netが一番実績がある。
最近はクライアントサイドを中心にJavaScriptエンジンもそんな立ち位置になりつつある。
Smalltalk?

175 ：

JVMは欠陥品だからダメだな
JavaScript使うよりSchemeのほうがマシだ

176 ：

反論できなくなると連投するからすぐわかるなこいつｗ

177 ：

>>165
型理論を根拠に反論おねがいします

178 ：

Smalltalkのtを大文字にしてたらそいつは100％ニワカ

179 ：

SmalltalK
↑かっこよくなった。

180 ：

型っていうのは競技にもあるんだよね、空手の種目。
つまり、大事なものなんだよね。

181 ：

>>168
だから静的関数型には関係ないじゃん(´・ω・｀)
静的は型を絞ったけど値の抜けまではチェック出来てなかった。静的関数型は値のチェックまでいれた完成体。何もできない動的は不完全にもほどがある。
別に静的関数型であることは必須事項ではないけれど。

182 ：

完璧じゃなければ、意味は無いんですよ！？

183 ：

完璧に近ければ良い、
道中のバグはしょうがないものとして対応出来る範囲に収まってればそれで良い

184 ：

完璧に近いって俺のことか？
なんか用あった？

185 ：

いつのまにか静的型＝静的関数型みたいな前提でうわごといってるアホ=181がいるし

186 ：

>>181
>静的関数型は値のチェックまでいれた完成体。
完成体になった結果、やっと動的型を取り入れたんだねw (>>115)

187 ：

そりゃ静的と動的の両方ができるから
完全体だろう？
静的が出来ないのはゴミだが。

188 ：

静的型が存在しない言語なんてあるのかな？
大抵の言語にはリテラルがあって、リテラルの型はコンパイル時に検査されるよなー

189 ：

Pythonのメソッドも第一引数は静的型がついてるなあ。
Schemeは型推論できたりするしなあ。

190 ：

>>188
まったくだ。
> 大抵の言語にはリテラルがあって、リテラルの型はコンパイル時に検査されるよなー
動的至上主義なら、それをやめろといいたいのか？
馬鹿だ。静的に、つまりコンパイル時に検査できる項目は
多ければ多いほどいいに決まっているだろう。

191 ：

言語仕様はミニマリストでいい
検査もミニマリストでいい
最低限の検査をやったら、あとは邪魔すんな

192 ：

>>191
誰のために？っていうのが抜けてるぞ。

193 ：

まあ結論としては、マギシステムが完成するまではC++方式でいいんじゃないか？って
ことだよね。

194 ：

>>185
お前みたいな意見もなくただ批判するだけの奴は楽でいいな
議論には邪魔なだけの存在だけど

195 ：

議論だったことに驚いた。
議論だったんだ。
へ〜。
驚き！

196 ：

煽り合いかと思った

197 ：

皮肉しか言えないんだな
つまらん奴だ

198 ：

いや〜半分くらい意味わかんないから読めるとこだけ読んでると、煽りあいに見えてたんだよ〜。

199 ：

動的型付けが糞って言うよりJavascriptが糞なんだよな。

200 ：

俺もJavascriptの良さがさっぱりわからない。
どこがいいんだろう？
prototype.jsが流行った時も苦肉の策にしか見えなかったんだけど。
なんかJSはすごいってみんな言ってたよね。

201 ：

年寄りにはわからないんだよ
おまえらベーマガ世代だろ

202 ：

いやjsは普通に糞やし
あんなの使うならlispやschemeのがいいし

203 ：

そりゃ言語使って遊ぶだけなら
珍しいものを使うほうが楽しいよ。

204 ：

JavaScriptは理不尽さがない
まさにWebの様にフリー
優れたハッカーは静的型に無駄と理不尽さを感じる

205 ：

ということにしたいんです！！！

206 ：

偉い人がそう言ってるんです。
優れたハッカーがそう言ってるんです。

207 ：

いや、俺そんなこと言ってないけど。

208 ：

痛いところを疲れると人に覆いかぶさって茶化そうとするの見苦しいな
言いたいことがあるならちゃんと自分の言葉で真正面から言えばいいのに

209 ：

僕もJavaScriptでグリーからフリーになりました(白目)

210 ：

まったくだよ。何が優れたハッカーなんだかｗ
俺は理不尽さを感じるって言えばいいじゃねーか。
どうせお前の主観なんだし。

211 ：

クラスもどきを作る関数とか便利だよね〜みたいな理不尽さを感じたことはあるな。

212 ：

え、ちょっと面白おかしく言ったら何この叩かれよう
異様で怖いわぁ……

213 ：

だよね。
俺もシャレだと思った。

214 ：

>>211
JSではクラスを作ろうとする時点で考え方が間違ってるんじゃないかとおもった方がいい
自作クラスとnewは極めて少なくなるはず、というか無くても十分設計できるのがJS

215 ：

それがクラスもどきを作る関数を持つライブラリが流行って、JSってすごいよね〜
みたいな話になるから理不尽な世界だなってことだな。

216 ：

JSを指して動的最高、ヌルポｗｗとか言ってたの？
よりによってundefinedｗｗなJSを根拠に？

217 ：

クラスもどきを作る関数を持つライブラリが流行ってる？
どれのことだ？

218 ：

「JS クラスもどき」と単純に検索するだけで何言ってるかわかると思うよ。
こんな手抜きな検索は普通適切じゃないでしょ。
それでも検索できちゃうから相当流行ってるんだよ、クラスもどき。

219 ：

>>214
ないわ
使い捨てしか作ったことないんだな

220 ：

使い捨て主義でカタカタ高速タイピングでコピペ脳内からしてると俺凄げ〜って気になるのはわかるよ。

221 ：

>>217多分クラスベースの継承の手法が無いから
そういうのを用意してくれるライブラリのことを言ってるんじゃないか？
だからこそ「もどき」のクラスを多用せずプロトタイプベースで書こうと言ってるわけなんだが
JSer以外にはわからないんだろうね
>>219
JSではnew無しでも十分オブジェクト指向ができる

222 ：

クラスがないと使い捨てになると思ってる時点で驚き
そもそもJavaScriptにはクラスはないから

223 ：

JSはプラットフォームの力を借りる言語なんだよ。
そのために特化してる。
だからプラットフォームで儲ける側はJS押せばいい。
そこに縛り付けることができるんだから。
それ以上のことをされたら自分のライバルにすらなれるんだから。
プラットフォーム上で「JS便利だね便利だね」と踊らされてる子ザルは
頭悪すぎでしょ。
プラットフォームを作る側にならなきゃ。

224 ：

JSってVBAと大して変わらないんだよね。

225 ：

>>223
それを言うならむしろ「JSは特化してなくて柔軟」だと思うんだけどな

226 ：

>>221
{}.callでnewと同等の処理が代替できるからとか言っちゃうのかな
欺瞞が大好きJSer

227 ：

標準メソッドに習うときは
new 〜〜()が見栄え的にもいいと思うけど
その他は
create〜〜()
にして
function create〜〜() {
var obj = Object.create(proto)
〜〜〜
return obj
}
ってやるのがプロトタイプベースっぽいな

228 ：

JSを開発したネットスケープはCSSの解釈をJSにやらせたわけ。
でも大失敗だったよね。
開発元でさえちょっと大きなものを作ろうとするとうまくいかなかったわけ。
これ言語としての限界だよね。
限界低すぎるわ〜。

229 ：

いまではフラッシュプレイヤーやPDFリーダーがJSで書かれてブラウザに載る時代ですが…

230 ：

>>>822
プリミティブは別だと言ったよ。
それについてはこっちの非だから謝るけどさ、
わざわざ蒸し返してまでレスすんなよ。

231 ：

正直、VBAと一般のプログラミング言語では土俵が違うでしょ。
まあ土俵って板のことでもあるんだけどね。
JSはHTML板？まあそういうとこ行けばいいんじゃないの？
JSはどっか行けって板ルールにも書いてあるし。

232 ：

どこからきたんだよ

233 ：

※JavaScriptが板違いと言いたい人へ
運営サイドから次のような見解が出ています。
|459 飛べない削除屋 ★ sage ：04/05/30 15:38 ID:???
|>‍>458
|ローカルルールにはひどく単純化されて書かれていますが、
|Javascript という言語そのものが板違いなのではありません。
|用途によって板違いかどうかを判断してください。

234 ：

Javascriptって子供のおもちゃでしょ？
ここは大人の板だから。
大きくなったらおいで。

235 ：

すみません、誤爆しました。

236 ：

ここは誤爆しても大丈夫なんだよ〜。

237 ：

JSを駆逐するには新言語のエンジンを搭載したアドオン作れば良いの？

238 ：

いつも思うんだけどJSerが自分から長々と語り出したわけじゃなくて
JavaScriptという単語に過剰反応する人が話をこじらせてるだけだよね

239 ：

それでは無理だろうなあ。
新言語を使ういかしたプラットフォームが必要なんじゃないの？
ブラウザに変わる何かとか。
ネットスケープも変なもん残したもんだよなあ。

240 ：

既にJSはマルチプラットフォーム化の道を進んでるから
もう歩みを止めるのは無理

241 ：

それも無理だろな。
限界が低いから。
ブラウザから大きく踏み出すのは無理だと思う。

242 ：

むしろJavaScript規格を良くすることを考えたら？
新しい言語を普及させるより早いでしょ

243 ：

あ〜、それも無理だわ。
JSなくなんねーかなってみんな思ってるから。
ウンコを食えるようにとか、余程のウンコ好きじゃないと考えないでしょ。
普通ウンコ好きってないから。

244 ：

JSが嫌いなんじゃなくてJSerが嫌い

245 ：

>>214
違う
ブラウザ自体、Web自体が色んな所に進出してきてる
この度OSにも進出してAPI的には出来ないことがないほど揃ってきてる

246 ：

>>241
だった

247 ：

なんか理屈抜きで、感情でJSは嫌いって言ってるだけみたいだな。
何が嫌いかではなく、何が好きかで自分を語れよｗ

248 ：

>>244
俺もそんな感じだわ。
まあでも、JSも糞だな〜って思うわ〜。

249 ：

>>247
Haskellはいいね。

250 ：

>>243,244
参考までにどういう所が何で気に食わない？

251 ：

>>250
互換性の名のもとに、変な仕様を残している所。

252 ：

もてはやされるものが嫌いって
人間の性質としては分かるけど
プログラマとしては失格だな

253 ：

なんかへ理屈こねながらム板に来るけど、よく読むと結局ウェブじゃねーかってとこかな。

254 ：

OCamlと同じ型付ができるようになったら服従のポーズする
今のままだと、あまり速くない高級アセンブラ程度の認識
書いててだるい

255 ：

ウェブが嫌い。デスクトップとコンソールの時代に戻れ

256 ：

>>251
それは新しいもの使うことで解決できないこと？
例えばvarの巻き上げはlet使うとか

257 ：

好きな言語で仕事ができたらいいな。

258 ：

もてはやされていないのに、もてはやされているとか主張するとこ。
Cより速いとかわけわからんことぬかすとこ。
それを連日延々と書き連ねるとこ。
板違い、スレ違いなとこ。

259 ：

俺の新言語には完璧な無限ループ防止アルゴリズムがある。
ブラウザをフリーズさせる悪質なスクリプトとか防止できるぞw

260 ：

>>254
確かにだるいね。

261 ：

話を戻すけどJSではクラスもどきを使うのが良くないんじゃなくて
現状のクラスもどきの仕組みが悪いからそれに頼るなってことね
ES6のclass構文はクラスもどきとして凄いすぐれものだからどんどん使っていい

262 ：

>>259
突っ込まないぞ＾＾

263 ：

なんだ、結局クラス欲しかったんじゃねーかってとこ。
すべてが屁理屈。

264 ：

>>259
> 俺の新言語には完璧な無限ループ防止アルゴリズムがある。
その言語で円周率の計算は
どこまでできるの？

265 ：

>>258
わけわからんこと書いてるのはどう見てもアンチJSerの荒らしだけど
あんたにはあれが本当にまともな人に見えるのかい？

266 ：

>>250
Cより速いとか、全般で使えるとか、大げさに言うところ
ブラウザ周りの操作ならお手の物ってぐらいが実情だろう
テキスト処理もバイナリ処理も不得手だよ

267 ：

>>263
JavaScriptにとって、クラスはシンタックスシュガーにすぎないでしょ？

268 ：

>>266
それわかるわ〜。

269 ：

>>266
> テキスト処理もバイナリ処理も不得手だよ
なんの機能が不足しているというの？

270 ：

>>264
やったことございません。っていうか円周率を求める無限級数の公式によって格段に結果が変わってくるからな。
最新の無限級数は知らんし。

271 ：

>>267
いらないんなら構文作るなよ。
いるんだろ？
屁理屈っぽいんだよ。
実際みんな感じてるだろ。
だりーなって。

272 ：

>>270
いや、そうではなくてね。
無限ループ防止アルゴリズムがあるのに
円周率（無限に続く）は計算できるのか？
矛盾しているのではないのかってことなんだが？

273 ：

>>263クラスっぽいのを実現するためには
現状のプロトタイプがはみ出す形はどうも見栄えが悪いから
現状の質の悪いもどきを改善するために欲しかった
それと同時にES6にはプロトタイプベースでやりやすいようにもなってる
あとES6のclass構文での継承は特殊オブジェクトの内部プロパティを
適切にインスタンスに付加するという重要な役割を兼ねてる

274 ：

>>271
要らないって言ってないでしょ？
シンタックスシュガーというのは
既存のある機能を、もっと簡単に書ける機能。
君が、（すでにある）クラスが欲しかったんじゃねーかって
いっているから、その理屈は理屈がおかしいって言ってるの。
あるものはある。欲しいのはクラスではなく
クラスを簡単に書けるシンタックスシュガー

275 ：

ほんと頭悪いなあ。

276 ：

俺は頭がいいのにね。

277 ：

http://toro.2ch.net/test/read.cgi/tech/1296214398/707-
こんな感じだな。

278 ：

>>269
組み込みの特定サイズの数値型やエンコード変換もないし、すぐ型変換しちゃう
ざっくりした処理にはいいけど、細かい処理には使いにくいよ

279 ：

>>278
それって、ライブラリで持つべき機能では？
言語仕様はミニマムでやれっていうだろう？

280 ：

>>272
ループ上限は定数で必ず指定しなければいけない仕様になっている。
アイドリングはループではなく同期処理で行う。
永遠に動きつづけるプログラムは仕様で書けないようになっている。

281 ：

そのうちJSはアセンブラより速いとか言い出すんだろうなあ。
そりゃアセンブラでJSより遅く書くことは簡単だけどさ。

282 ：

>>271
今まで、特にES3までは確かに確かに悪かった
それは、プロトタイプベースなのにプロトタイプの仕組みを
クラスベースっぽいので覆い、クラスもどきも劣悪だったから
そういう中途半端のでいろんな混乱と面倒があったのは本当に確か
つまりJSにはクラスのようなことを実現する良くて分かりやすい方法が
クラスベース視点でもプロトタイプベース視点でも不足していた
でもその両者の問題もだんだん減ってきてES6で一応解決かなってとこ

283 ：

なんか何でもへ理屈で言い負かせば勝ちみたいな感じ。
そこが嫌われてるんだろうなあ。
自分の板に帰ればいいのに。
そして出てくんなって思うよ。

284 ：

>>278
int8(num)でint8に揃うよ

285 ：

>>280
1回のループが1分ぐらいかかるのと
1回のループが0.01msで終わるのとでは、
全然違うからループ回数で決めるのは公平性がない。
こういうのは定数よりも、実行時間でやった方がいい。
つまり、何秒とか何分以上処理が続いていれば、
プログラムがビジーです。停止しますかって聞く。
何かに似ている気がするかもしれんが気にするなｗ

286 ：

>>279
外部ライブラリ使えって、
もうそれクソって認めてるようなもんじゃん
外部ライブラリを含めるならそれこそ他の言語のが多機能だよ

287 ：

>>286
なんで、外部ライブラリを使うと糞なの？
お前、言語の役割全然わかってないじゃないか。
実は、プログラム言語の勉強だけしか
してないんじゃないのか？
学生にありがちな実践知らん奴。
どこに外部ライブラリを使わないで作る
アプリがあるのさ。

288 ：

型変換はあるね

289 ：

実践ってウェブ？

290 ：

ウェブでじゃばじゃば〜って中学生でもできるよこれ。

291 ：

文字コードの変換のこと言ってるんだよね？
これは標準でどの程度まで持つべきだと思う？
特にJISみたいな国際系にはどのくらいまで？

292 ：

実践知らん奴が、何言い出したｗ

293 ：

>>287
結局こうやって真面目に話しても煙にまいたり、レッテル貼るんだよね
だからJSerが嫌いなんだよ

294 ：

Excelプログラマです！（誇らしげ）とかないのになあ。
どこで間違っちゃったんだろねこの人たち。

295 ：

>>285
A,ループ時間を決めることができる
このアイディアはよいな。

296 ：

>>293
おい、正当な反論に言い返せなくなったからって
逃げるな。

297 ：

>>293
その感じわかるわ〜。

298 ：

>>297
さっきもその自演みたよ。

299 ：

みてみて、このわざとらしさｗ
266 名前：デフォルトの名無しさん[sage] 投稿日：2013/10/27(日) 00:31:16.83
>>250
Cより速いとか、全般で使えるとか、大げさに言うところ
ブラウザ周りの操作ならお手の物ってぐらいが実情だろう
テキスト処理もバイナリ処理も不得手だよ

268 名前：デフォルトの名無しさん[] 投稿日：2013/10/27(日) 00:32:18.76
>>266
それわかるわ〜。

293 名前：デフォルトの名無しさん[sage] 投稿日：2013/10/27(日) 00:50:16.10
>>287
結局こうやって真面目に話しても煙にまいたり、レッテル貼るんだよね
だからJSerが嫌いなんだよ

297 名前：デフォルトの名無しさん[] 投稿日：2013/10/27(日) 00:51:25.61
>>293
その感じわかるわ〜。

300 ：

JSerには極悪人しかいない
よく分かんだね

301 ：

全然自演じゃないよ。
俺も同じことを感じてる。
共感。
みんな同じことを感じてるんじゃないの？

302 ：

>>300
それわかるわ〜。

303 ：

>>301
それわかるわ〜。

304 ：

煽り合いはいいから真面目に話そうよ
具体的にどういう機能がJSに標準であるべきって言ってるの？

305 ：

>>296
反論できてないのはお前だよ。
外部ライブラリ使っても、テキストやバイナリ操作が不得手なのは解決はしないよ。

306 ：

どう不得意？

307 ：

>>304
JSにプラスになること言うわけ無いじゃんｗ
単にディスりたいだけなんだからさ。
あー、酒が旨いｗ

308 ：

>>297
もしかして、わざとやってんのか？

309 ：

>>307
そういうのはいいから

310 ：

>>308
大人げないぞ
もう終わりにしろ

311 ：

だめだめ言うばかりで、どうできればいいかは言わないんだよね。
具体的なことを言うと、反論されるのがわかってるから。

312 ：

JS無くなんねえかなって思ってる。
生産性低い言語を使わせたいとか。
プラットフォームを作れない言語。
これがJSを推す理由でしょ。
頭悪すぎ。
踊らされてるだけ。

313 ：

>>306
レスツリーぐらい遡れ。

314 ：

どうできればいいか。
JSがなくなってほかの本物の言語に変わる。
これでみんな幸せ。
MSとググル涙目。

315 ：

JSを推す？？？
無慈悲な批判煽りに対抗してるだけで推していないが

316 ：

>>313
レスツリーを遡ると、
ライブラリで解決できる問題という結論になってたね。
>>314
そんなのはもういいから。

317 ：

>>313
>>284,291
で話に乗ったつもりだけど反応ない

318 ：

>>315
君は踊らされてるみじめな子ザル。
まさか君はMSやググルの意思決定を担っているのかい？
そうなのかい？
それなら推すのもわかる。
踊らされてる側なんじゃないのかい？

319 ：

今度は踊るとか言い始めた。
頭悪すぎ。

320 ：

>>316
では外部ライブラリにない機能で画像処理をしたい時はどうする？

321 ：

>>320
C言語でも好きな言語でもいいから置き換えてみろ。

322 ：

画像処理って具体的に何？
Canvas使っていいんだよね？

323 ：

JSで画像処理を書く。
JSって素晴らしい。
ユーザーは使わない。
そういう仕組み。

324 ：

Canvasを駆使して、Nシステムを書き上げる。
JSって素晴らしい。

325 ：

画像処理ってとどのつまり、
バイナリ処理にすぎないんだが。
バイナリ処理であれば、例えばJavaScriptで実装された
Gzipなんてのがある。
http://ja.softuses.com/68583

326 ：

バイナリが入力されてバイナリを返すのなら
標準でArrayBufferやDataViewがあるから出来るよ

327 ：

バイナリ処理がJavaScriptで出来るできないの話をするならば、
できるが答えになる。
だから遅いという話に持っていかなくてはいけないが、
以外に早かったりするから困る。

328 ：

度々言うがJSに不足してるのはint64とbignum
ES7までこれには苦しむ

329 ：

そういう感じが嫌われてるんじゃないの？
JSでNシステムを書ける。
だからJSは優れてる。
そんな結論にするから嫌われる。
JSはNシステムをかける言語じゃないだろ？
たとえ書けたとしても。

330 ：

できると言ってるだけにしか見えないが……

331 ：

言い負かせば勝ちってルールはウェブ板のルールだろ。
ここに持ち込まれても困る。
嫌われるのは自然の成り行きなんだろうなあ。

332 ：

とりあえずバイナリの話はもう終わり？

333 ：

http://toro.2ch.net/test/read.cgi/tech/1296214398/707-
こういう感じなんだよなあ。

334 ：

>>317
ごめんね。見落としてた。
int8は知らなかった。どうやればいいの？
テキストの方は変換APIがあるだけでいい
そのOS標準のエンコーディングに変換できれば実用性としては十分

335 ：

>>321 >>325
速度的に使い物にならないよ。

336 ：

>>335
速度はCより速いと言い張られるし無理ぽ。

337 ：

>>334
前者はES6のValueType
あとMath.froundとかもちょっとある
後者はファイルに保存するAPIが持つものじゃないかな
例えば今のところブラウザから任意のファイル保存させる手段は少ないけど
Blobコンストラクタで一応エンコードの指定ができる
それが守られてるかどうかは不明
あとNode.jsとかの環境ではベタであるね
SJISはiconvとかのライブラリ使わないと無理だけど

338 ：

こんなのもあるが……
http://log.deconcepter.jp/2013/09/clmtrackr/
速度は悪くないんじゃない？

339 ：

これは速いね。
認識精度もなかなかいい。
ソニーのデジカメに積めると思う。

340 ：

>>337
int8ってどうやって使うの？
Blobは苦肉の策だし、容易に変換もできないから無しで。
そういう使いにくい物を素直に標準APIとしてほしいと言ってるわけで。

341 ：

とか言ってたらほんとにソニーのデジカメがJSで動いてた。
時代は変わったんだなあ。

342 ：

>>338
これ凄え！確かに速え！
って中身見たらほぼopenglじゃねーか

343 ：

>>340
int8(127) //127
int8(128) //-127
読み込みはDataView系でオクテット単位でバイト列を自在に読み込める
バイナリを操作するってとこまでは標準であるけど
ファイルの読込保存までは標準であるべきとは思わないな
一応IOから切り離されたスクリプト言語っていう存在だし
これから先DOMAPIが発展しきったら使用されるかもしれないけど
まだまだファイル操作が許される現場は特殊な方だからね
あとは文字コードの変換っていうのは例えばutf8のバイト列を
utf16にするような関数が欲しいってことだった？
そういうのはあっていいかもね

344 ：

そうですね。
Javascriptはセキュリティを重んじるのでローカルリソースへのアクセスは
限定的であるべきです。

345 ：

>>342OpenGLは表示部分だけで行列の演算とかは全部JSだろ

346 ：

>>344
まあ標準で合ったとしても
ブラウザ用はまた確認や制限があるAPI使ってねってなるだろうから
同じことだな

347 ：

すでにファイルという概念が過去のものとなっていますから、これからの
コンピューティングシステムは厳格に管理されるクラウド上のリソースのみ
扱うべきでしょう。
そういった意味で、多くの言語と比べJSは優れていると言えます。
標準で危険な動作から保護されているのですから。

348 ：

こういう書き方をする人が張り付いているからJSのイメージ悪い。

349 ：

別に2chの標準的な書き込みだと思うが

350 ：

単にネタでしょ。笑えない時点でイミフなのは否定できんけど。

351 ：

>>338
ごめんよ。これだけだと他言語との速度差がわからないから、処理が得意かはわからない。
ただ、このプログラムはすごいね。読みふけってしまった。
教えてくれてありがとう。
>>343
Chromeだと対応してないみたいだよ。

352 ：

>>351明示的には>>343だけどそもそも
バイナリの読み書きに関しては暗黙的に同等な事をやってくれるから要らない
ab = new ArrayBuffer(10)
i8 = new Int8Array(ab)
i8[0] = 127
i8[0] //127
i8[0] = 128
i8[0] //-128
dv = new DataView(ab)
dv.setInt8(0,127)
dv.getInt8(0) //127
dv.setInt8(0,128)
dv.getInt8(0) //-128

353 ：

>>352
できないならできないでいいじゃんよ。
なんで無理にやろうとするのかな。

354 ：

何が出来ないのか不明
32bit単位までの読み書きは標準で揃ってるよ

355 ：

いえできますよ。
できるけれども必要がないと言っているのです。
この違いわかりますか？
出来るよりも必要ないのほうが高度なのです。
それだけJSが優れているということです。

356 ：

>>338
ある処理が人間にとって問題ない速さで動くのを"速い"っていうのはなんか違うと思うけど。
現状JSは画像(バイナリ)処理苦手でしょ。並列処理できないし。
だからgoogleもNaClとか開発してる。

357 ：

女子小学生

358 ：

数値の型変換はES6まで気軽にできないけど
バイト列の操作はそれなりにできるってことでしょ

359 ：

>>354
なんでint8なんてのを出したの。
できないよ。

360 ：

>>356
並列処理はWorkerで出来る
配列のパラレル処理もWorkerなラッパーで実現するライブラリがあって
ES7で標準にも取り入れられてきている
Firefoxならもう使える

361 ：

>>359
ES6でChromeはまだ対応していない

362 ：

得意とは言えませんが問題なく操作できます。
処理系の高速さと相まって全体として他の多くの言語より優秀な性能を発揮するのです。
簡潔に書け、バグを生みにくく、高速に動作する。
これらの特徴によって多くの人がJSはバイナリ操作の言語であると考えるのです。
JS自体は決してバイナリ操作のために設計されていません。
しかしながら他の言語よりも上手にバイナリを扱えるのです。

363 ：

もうMozillaScriptって呼べばいいのに。

364 ：

親切のつもりで方法を書いたら屁理屈か何かと勘違いされてしまったのか
非常に悲しいな

365 ：

Mozillaの前身であるNetscape社はJavascriptを人々のために解放しました。
ですからMozillascriptとは呼ばないのです。
感謝してありがたく使わせていただきましょう。

366 ：

二、三時間でスレの半分もレスすんじゃねえ
読むの追いつかないだろうが

367 ：

>>365
いつの世も先人は凡人に理解されにくいものです。
大衆が追い付いてくるのを静かに待ちましょう。

368 ：

>>364
親切心で答えてくれたのなら、感謝する。
ただ、int8で(扱いやすく)できるって言ってたのに、
迂回する方法示されて、できますって言われても、
使いにくいっていうのが元の主張なんだから、噛み合わないよ。

369 ：

>>368
いやいやいや
それは勘違いしてるよ
int8は>>284
「組み込みの特定サイズの数値型」っぽいのがあるよという紹介で出しただけであって
バッファの読み書き自体はもうすでにあるAPIで簡単に出来るんだよ
APIの各メソッドにもう機能が内蔵されちゃってるようなものだから
ファイル操作に関しては別にint8の出番は特にないよ

370 ：

>>360
Workerってちゃんと性能スケールするの？それは知らんかった。
以前使ったときは全然性能スケールしなくて、Workerって非同期処理とかに使うものかと思ってた。
まぁ仮に現状スケールしなくても原理的に並列化できないわけじゃないから実装が追いついてないって
ことなんだろうけど。
Vector処理はまだだよね？こっちも原理的にできないわけじゃないんだろうけど。
それでもJSでプログラムしたいとは思わないが。

371 ：

>>369そもそもこのint8っていうのはES6の間では
StructTypeとかArrayTypeっていう構造体っぽいのを作るために使われるもので
見かけの型変換は副産物ね
実際はdoubleでしかない
これらはES7になってint64やbignum等など、
そして数値型を調整する仕様が入って初めて型変換として活きるもの

372 ：

全然スケールしないよ
うんこだよ

373 ：

>>370
Workerそのもの自体にスケール機能はない
ライブラリやES7のDataParallelではやってくれる
Vectorは不明

374 ：

>>369
教えてくれようとした事には感謝するけど、
ArrayBufferやBlobは知ってた。ごめんよ。
jsは固定配列より、単体の組み込み型の他に、構造体とか、特定のチャンク構造を、
簡単に読み出せる方法があると、処理の汎用性が上がると思うよ。
そろそろ落ちる。答えてくれた人ありがとう。

375 ：

スケールしないというより必要ないというのが正解
充分な性能があるからスケールする必要性自体ない

376 ：

んな馬鹿な
シングルスレッド性能ですら静的型より遅いのに

377 ：

>>374
固定じゃないのはDataViewを使う
特定の構造を簡単にはES6のStructTypeｍでおあずけ

378 ：

静的型ってたとえば？
JSより速い言語はないはずだけど

379 ：

そんだけJSerが語るJSの使用と実際の現場で使えるJSには差があるってこった。
JSの一番の適用領域であるウェブではIE8とか9の存在も考慮して開発せんといかん。
そんな相手にJSerがあと何年かかるかわからんES7やMozillaScriptのローカル実装を
語ったところで現状単なる夢物語と捉えられるのは不思議じゃない。
コレは別に皮肉でも何でも無く、言語仕様のバージョン遅れがより深刻な問題になる
のはJavaScriptがスクリプト言語である以上本質的な問題。
言語仕様のバージョン=ランタイム上のインタプリタやJITコンパイラのバージョン
なんだから。
クライアントサイドで広く使われるJavaScriptのランタイム=言語仕様のバージョンを
如何にコンスタントに最新仕様に更新していくか、その方法の答えは現状まだ出て
いないように思う。実際IEで滞っているわけだし。

380 ：

でもSIMD演算もJSに入るんでしょ？
300%早くなるのは魅力的

381 ：

いっそのことJavaScriptエンジンはプラグイン方式で良かったのかも。
「最新のJavaScriptPlayerに更新してください」とポップアップを出せばOKだし。

382 ：

>>380
ES6から入るみたいだね
これでJSで動画のリアルタイム編集などが可能になる

383 ：

今のMozilla仕様なんてFirefox3の頃でひと通り出てた気が
出遅れすぎだ

384 ：

>>379
XPとVistaの8と9はもう気に死にことも多いよ、特にIE12がでるあたりではそうだろう
ES6勧告後に出るだろうIE12がwin7に流石に対応してくれると考えれば
あとは自動アップデート後はES6だけ考えればいい
だからあと２年くらいの辛抱だと思う

385 ：

>>383
結構色んな所が変わってJS1.xとES6は互換性がない

386 ：

IE自体がすでに死に体で使ってる人もほとんどいないから切り捨てでいい
基本的にFirefoxとChromeに対応しておけば90%以上カバーできる

387 ：

自分とこのサーバにくるUAくらいちゃんと見とけよ

388 ：

うちはハイブロウな人しか相手にしていないのでSafariとChromeだけ相手にしていれば十分です。

389 ：

JSだけではなくてAPIの問題もあるのでいつまでも古いIEを相手にしていられない

390 ：

実際のところFirefoxは開発ターゲットの基準と出来るほどドミナントなシェアが無い。
マニアックなイメージこそあれ軽快だったりオシャレなイメージは残念ながら作り損ねたし、
そういうものを求める層はChromeやOSX標準のSafariを使っているでしょ。
そしてモバイルではWebkit系統以外のブラウザはFF含め存在感皆無だし。
仮にIE無視できたところでChromeやSafariは無視できないわけで、いくらFirefoxが規格の
実装で先行したところでベースラインとしてはこの二者に合わせる必要がある。

391 ：

ベースがそこなら上等じゃん
このスレではベースの話にこだわる必要性なんて無いけどね

392 ：

2年後には流石に各ブラウザの最新バージョンはES6に対応してると思うぞ

393 ：

>>392
MSだけ仕様をちょっとねじ曲げるのが慣例なんだけどな。

394 ：

>>391
だから夢物語と言われる。

395 ：

IE11でES6の一部に対応したんだから、
２年後は順当に行けばほとんど対応してくれていると見るのが自然

396 ：

ES6が大きく変わる恐れが有るのは
11月第4週のミーティングだけ
その後ラストコールで１年後勧告

397 ：

ShiftJIS,j++,html,css,Unicode などなど
必ず仕様をねじまげてねじこんでくるのがMSという会社

398 ：

ES6はMSも策定に加わってるし問題ない
昔めちゃくちゃだったのはIEのJSがJScriptだっただけ

399 ：

まあそのあたりは実際に出そろってから話そうや。

400 ：

ES6って他言語に比べて2週くらい周回遅れだったのが
1週遅れ程度になるだけですよ

401 ：

他言語って具体的にどの言語？

402 ：

Smalltalk, Lisp, Ruby

403 ：

>>402
それらの言語に対して、
足りない機能は何？
これがでれば、1周の内容が判明するよね？

404 ：

>>402で複数の言語でてきたが、
どの言語も全ての点で優れているものは
ないってことだろう。
仮に数値化すればこんな感じ
Smalltalk 5 4 2 3 1
Lisp 3 4 5 3 1
Ruby 4 2 2 1 5
そう。どの言語もオール5なんてのはなく
何かの点で劣っているもの、優れているものがある。
今のJavaScriptはこんな感じか。ウェブに
特化しているからその点では有利。
JavaScript 3 3 5 3 3
それがES6ではこうなる。
JavaScript 4 4 5 4 4
そう、まさに二周遅れ(5 vs 3)だったのが
一周遅れ( 5 vs 4 )になったわけだが、
全ての点が平均的に上がっているというのが重要。

405 ：

５周遅れだろうが１００周遅れだろうが
ES6に入る機能の殆どが本当にしっかり練られてて
失敗はないだろうからclass構文とかものによっては十数年
待ったかいはあったと思うよ

406 ：

他の言語の機能をまんべんなく取り入れてるってのがいいよね。
最高ではない、だが最良である。
それが実践主義、現実主義であるのJavaScriptというもの
HTML5もそうだった。理想であったはずのXHTMLよりも
より使えるものを目指して進化し続けている。

407 ：

>>404
何の根拠もない数値でも、数値が書いてあれば説得力が増すと考えるのって
典型的な文系脳だよね

408 ：

根拠も何も何の項目かも書いてない
ただの数値に文句つける人ってw

409 ：

いや、アスペだろ
数値に病的にこだわる

410 ：

>>408
横レスだけど、>>407は数値に文句をつけているのではなく、
意味の無い数値から根拠を導く>>404の似非科学的思考を批判している
日・本・語・ワ・カ・リ・マ・ス・カ ？

411 ：

急にファビョられても困るわぁ……

412 ：

夜中だけ盛り上がるスレ。

413 ：

平日の日中に盛り上がるような与太に価値があるとでも思っている?

414 ：

平日の昼間も盛り上がってたんだね。
夜中と昼間だけ盛り上がるスレ。
俺参加できないスレ。
悲しい。

415 ：

飽くなきJS信者が寝てる時間帯と思われる

416 ：

>>410
俺は数字なんて大した意味が無いと思ってるから
消していいよ？
----ここから書き直し
どの言語も全ての点で優れているものは
ないってことだろう。
どの言語も完璧なものなんてのはなく
機能によって劣っているもの、優れているものがある。
今のJavaScriptはウェブに
特化しているからウェブの機能ではほかよりも優れている
それ以外では劣っているが、それがES6では底上げされる
そう、まさに二周遅れだったのが 一周遅れになったわけだが、
全ての機能が平均的に上がっているというのが重要。
劣っている所がかなり減った。
----ここまで書き直し
まさか、説明をわかりやすくするためだけに書いた点数に
ここまで病的に反応するとは思わなかった。
数値にこだわるのはアスペなん？ｗ

417 ：

金曜日の午前8時にスレが建ちスタートダッシュ。
夕方から夜は静まり返り深夜になるとまた盛り上がる。

418 ：

生産性を上げる≒開発環境の支援を最大限に受ける
動的言語の優れた開発環境教えて

419 ：

>>416
結局、数値を取り除くと残ったのは、>>416の主観的な願望や妄想だけw
技術的な裏付けのある主張はどこにも無い
>>416の「ES6はこうあるべきだ...」という願望から導かれた結論ありきの内容

420 ：

>>419
そもそも、Smalltalk, Lisp, Ruby が
優れているってのが主観だからね。
事実、何が優れているかが
でてこない。

421 ：

二周遅れっていうのも、主観や願望だろうが。
数字として示せよ。

422 ：

>>418
SmallTalk

423 ：

同じ議論何回も繰り返さないでいいよ
そういうのを不毛っていうんだぞ

424 ：

>>422
Smalltalkには演算子の優先順位がないってマジなの？

425 ：

そんな言語があるとは思えんな

426 ：

Smalltalkの何が優れているかって
結局言えないんだよね。

427 ：

Smalltalkは優れているよ。

428 ：

Smalltalkは優れているよ。 （主観 願望）

429 ：

Javascriptより優れているね

430 ：

主観、願望

431 ：

優れてるってのは分かったから
どこがどうってのを聞きたい

432 ：

標準ライブラリは優れてるよね

433 ：

つまりJavaやC#が最強と
そういうことですね?

434 ：

Javaの標準ライブラリはガチでゴミ

435 ：

Javascriptの標準ライブラリってなんもないね

436 ：

Javaの標準ライブラリは酷いよなあ
オブジェクト指向や直交性などの手段が目的化してる最悪の例

437 ：

（ここまでいえば、具体的と認めてくれるだろう？）

438 ：

実際には具体的なことを何も言ってないけどなｗ

439 ：

議論では何度やっても勝てないから煽って誤摩化すわけね
ほんと関数厨って頭悪いわw

440 ：

動的型言語で一番関数やメソッドの補完が優れた
開発環境を持つ言語って何？
やっぱりSmalltalkなの？

441 ：

Smalltalkかぁ、言語はいいんだけどね。
普通のテキストエディタで書けないし・・・。

442 ：

Smalltalkは環境自体がIDEと言ってもいいだろうね

443 ：

>>440
JavaScript+VisualStudio

444 ：

>>424
そもそも演算子がない。
メソッドの評価順に優先順位がある。

445 ：

Smalltalkは特殊すぎて実用的でないというか。
なんだろう。OSすべてSmalltalkの世界が来れば
なにか変わるかもしれないが。

446 ：

Smalltalkに演算子がないって
欠点なんじゃね？
演算子が無いことのメリットがあるかもしれんが、
わかりやすさとしてはデメリットでしょう？

447 ：

本当なのか・・・。
http://jijixi.azito.com/cgi-bin/diary/index.rb?date=20070202
>
> % [Smalltalk] とりあえず Smalltalk で最初にびっくりすべきところ
> % rlwrap gst
> GNU Smalltalk ready
>
> st> 2 * 4 + 1!
> 9
> st> 1 + 4 * 2!
> 10
> な、なんだってー!?
>
> 要は演算子だろうが何だろうが全部メッセージで、優先順位とかは特別扱いしないよ…
> ってことなんだろうけど、知らないとビビるよ、これ。 ある意味 LISP に近いかも。
> 優先順位関係無しに、先に計算されるべきところはカッコで囲まざるを得ないところが。
> まあ、算数へのこだわりが無ければ、こっちの方があいまいさが無くて嬉しいという見方もできるけど。

448 ：

MSにはPythonの開発環境を本気で作ってほしい
Pythonって解析しやすい方だろうしコミュニティも静的解析ウェルカムな感じだし
設計思想もC#と似通ったところがあったりしてMSとは相性良さそう

449 ：

Visual StudioのPython開発環境ってそこそこ出来良くなかったっけ？
そりゃ補完はjediに及ばないだろうけど

450 ：

>>446
いちいちカッコで括って面倒なのは、数値計算するときぐらいだな。
前から順に評価されるだけなので、こういうのを把握するよりよほど楽。
http://www.rubylife.jp/ini/if/index5.html

451 ：

pdbがものすごくいいらしいのでPython使ってみたけど、printと変わらなかった。

452 ：

>>449
だってあれ元々MSが作ってたからなw
コミュニティベースに移行してからはパッとしないけど

453 ：

>>451
pdbなんて全然良くないと思う
ていうかデバッガなんて真面目に使ってないでしょ誰も

454 ：

>>450
それは全然意味が違う。
四則演算の優先順位は
小学校で習う常識だ。
Smalltalkは小学校の
常識から外れているだろう

455 ：

Javascriptを使えばホームページに動きを取り入れられます

456 ：

それどころかJavaScriptでなんでもできます。

457 ：

>>453
使ってたら優れたデバッガと言わなかっただろね
正味、printと変わらない

458 ：

Javascriptを使えば起業もできるって考えてあのスレをたてたのか。

459 ：

テスト書いてればデバッガのお世話になることなんて殆ど無いと思うけど（例外で落ちればスタックトレースも出るし）、
どうせ使うならIDEのデバッガを使うか、コンソールが好きだとしてもpudbくらい使うべき

460 ：

デバッガに拘るやつの無能率は異常

461 ：

粒度が違うからどっちも必要だけどね

462 ：

> テスト書いてればデバッガのお世話になることなんて殆ど無いと思うけど
テストはエラーを見つけるもの。
デバッガは見つけたエラーを直すもの
全然役割が違うと思いますが？

463 ：

自分自身がデバッガそのものなので必要ありません。

464 ：

デバッガで実行しながらじゃないとエラー直せないとか
どこまで無能宣言すれば気が済むの？

465 ：

>>462
>>460
デバッガ使うやつはエラーの発生原因

466 ：

デバッガを無くせばバグは世界から消える

467 ：

デバッガがないとプログラム書けない低能プログラマが死滅すれば
バグのあるコードが世界から減ると思う

468 ：

>>454
優先順位の紹介のために、2 + 3 * 4 を見せられて初見で面食らう「わかりにくさ」と、実際に使用する上での「わかりにくさ」は分けてくれ。
コード上は通常、2+(3 * 4)と書く。

469 ：

>>468
違った。この例だと、 (2 + 3) * 4 だな。

470 ：

>>467
だよな
printのほうが高機能

471 ：

>>468,469
お前も間違ってるんじゃねえかｗｗｗ

472 ：

>>456
デバッガを使えないほうが無能。
理由は、お前が言ってないので
俺も言わないｗ

473 ：

道具を使えない人間は
無能ってことでいいんじゃねーの？ｗ

474 ：

デバッガは不要。

なんでそんな機能作っちゃったんですかｗｗｗｗｗ >>ほぼすべての言語

475 ：

>>472
JSでなんでもできるとか書く馬鹿が無能なのは
わざわざ言われなくても分かるよ

476 ：

言語設計者はテストの重要性を理解していないんだろうな

477 ：

普及した言語の設計者は、言語の普及のために
無能を取り込むことの重要性を理解している

478 ：

非コンパイル言語ではデバッガで初期エラーも見るしなぁ
まあそれこそSmalltalkみたいなIDE一体型言語なら間に合うのかもしれないけど

479 ：

>>471
どちらにせよ、算術計算のときは意志が伝わるようにカッコで括るのが常識ということな。

480 ：

初心者がデバッガ使うのは仕方ない部分もあるね

481 ：

一発で完全なコードを書けないのはプロとして失格だろ

482 ：

デバッガである地点の値を知りたいなら、
ブレークポイントなんか設置しないで、
pritf文を書けばいいじゃないか。
どっちが面倒か比べるまでもないね

483 ：

一発で完全なコード書けるような奴がプログラミングとか勿体無すぎる
人類にとって大損失だ

484 ：

そういう発想になる時点で無能なんだよね
わりとマジで

485 ：

>>482
その考え方が間違っているんだよ
ある地点の値を知りたいということは、ある地点の値をある範囲に保証しなければいけないからだろ
ということはそれを保証するテストを書くべき

486 ：

今はテストのテストまで書く時代だからね
デバッガは過去の遺物

487 ：

printf文を入れて実行。
ここまではちゃんとした値が入っているよな？
printf文を追加して、再実行。
ここまではちゃんとした値が入っているよな？
printf文を追加して、再実行・・・
うわっ、ループの中だったからたくさんprintf文が・・・
条件付きでprintf文実行されるようにしなくちゃ
以下数回繰り返す。

VS ステップ実行

488 ：

>>485
開発中の値の確認の話でしょ

489 ：

>>485
ある地点って、関数の中のある地点ですよ。
テストは関数単位でしか調べることは出来ません。
なんでprintf文を使っていると思ってるんですか？

490 ：

どうしょうもなく追い詰められたときデバッガ使うけど大抵は凡ミスなのでコード眺めてれば自然に解決してしまうぞw

491 ：

>>488
開発中に値を確認するのはプロとして失格
今自分が書いたコードが何をするか把握していない証拠
デバッガは初心者の学習補助として存在する

492 ：

>>490
君には複雑なシステムを、眺めてて欲しい。

493 ：

>>491
スゲー真似できんわ

494 ：

>>491
お前何と戦っているの？
値を見たほうが、問題解決するのはやってーの。
目的は問題を解決すること。
プロとかプライドとかどうでもいいよ。

495 ：

デバッガはテストが失敗したときの話だろ?
そりゃデバッガが必要ないほどテスト可能な処理単位が細かく分けられてて
テストも完全に書けてればそれがもちろんベストだが
現実的じゃないね

496 ：

>>489
関数程度の大きさで値を調べたいというのがそもそも間違い
その程度一発で書けないのは初心者
もしも把握できない大きさになっているのであれば関数を分割するべき

497 ：

この中でprintfデバッグをしたことがない人だけが、
デバッガをことを悪く言いなさい。

498 ：

>>496
一発でかけないお前は無能ってことだよな？
あれあれ？ 俺はミスしないって言っちゃうの？

499 ：

printデバッグすら自由にやらせてもらえない職場だってあるんだぞ
そしてテスト単位は数千ステップのバッチ

500 ：

煽りじゃなく、本当にデバッガ君は無能だから
初心者じゃないなら別の仕事探すべき

501 ：

以上、スクリプター同士の真剣な議論でした

502 ：

>>487
そうだよね。言語的にデバッガが使いにくいから
そうやってprint文を入れたり消したりしながら
デバッグしてるけど、実際は途中で止めたほうがいいんだよね。
テスト書いていても、テスト実行の途中で止めたいことってよくあるし。
（できないから、他のテストを実行されないようにソースコード書き換えてる）

503 ：

プログラムに慣れてくると直感でバーっと書いて
思い通りに動くかどうか値を出力して確認しないのか？？

504 ：

>>500
でも、その根拠がはっきりしないから、
それはお前の思い込みでしか無いって
話なんだがね。

505 ：

電車の中で原因を考えてるとふとあそこが間違ってんじゃんと思いつく。
これが俺のデバッグ法。スマホとかいじってるやつはアホ。

506 ：

休むことも仕事のうちです。

507 ：

間違ってるって気付く一番手っ取り早い方法がプリントだろ？

508 ：

>>496
関数の中で呼んでる別の関数に絶対にテスト漏れがないと言い切れるのならそうだね
ありえないけどね

509 ：

少なくとも現在開発中のコードは全て頭の中に入っていて動作を脳内トレースできなければならない。

510 ：

print文を入れてソースコード汚すのはダサい

511 ：

いちいち値を確認しなきゃデバッグできないなら無能ですよって主張に対し
printとか何度も書いてるアホは何なのでしょうね？アホの中のアホですか？

512 ：

print文いれてソースコードを汚くするぐらいなら
デバッガを使えば良い。
print文の目的は、ある地点での値を見ることなんだから
それはブレークポイントを設置すればいい話なのだ。
ブレークポイントで止まって、そこからステップ実行
できるから、print文を調整して再実行をする必要もないぞ。

513 ：

きちんとテストを書けない雑魚がデバッガに頼るんだよね

514 ：

>>511
だから何と戦ってるんだよｗ
バグが起きた時点で、
何が起きてるのかわかってない状態だろ。
その状態になったら、何が起きてるのか
状況を把握するのが重要だろ。
問題が起きましたが、どの地点で起きてるのかわかりません！
いま脳内でトレースしてますが、時間がかかります。
じゃプロとしてだめだろ。

515 ：

そもそも関数型は値が不変なのでデバッグの必要がない

516 ：

なるほど、デバッガ君は副作用満載のウンココードを書いてるってことか

517 ：

想定した値と違うとき、
どういう値になったかがわかれば
問題解決するのも早いってことよくあるよね？

518 ：

自演発見ｗ

515 名前：デフォルトの名無しさん[sage] 投稿日：2013/10/27(日) 23:15:18.30
そもそも関数型は値が不変なのでデバッグの必要がない

516 名前：デフォルトの名無しさん[sage] 投稿日：2013/10/27(日) 23:15:58.48
なるほど、デバッガ君は副作用満載のウンココードを書いてるってことか

519 ：

コード書いてブレークポイント設定して実行して確認するより
コードにプリント書いて実行して表示を見るほうが手間ないよ
もちろんブレークポイント書くのがいい時もあるけど

520 ：

Pythonに良いデバッガが無いのは優れた特徴だということ

521 ：

>>515
計算を遅延してるだけなのにそれを不変と言えるのか？

522 ：

>>521
何かと勘違いしてない？

523 ：

よくあるデバッグログなんかも
途中の値を見ることが
問題解決の糸口になるからなんだが。

524 ：

開発環境は言語の一部

525 ：

>>520
Pythonは初心者向け言語なのでデバッガは充実してる
標準デバッガがプリミティブなのは別の話

526 ：

>>519
> コード書いてブレークポイント設定して実行して確認するより
> コードにプリント書いて実行して表示を見るほうが手間ないよ
ブレークポイントの何倍も楽だけど？
よくいるのがツール使えないからと
原始的な方法を続けてる人。

527 ：

値を確認する必要があるならデバッガ使うさ
問題は、そんな必要は殆ど無いって話でさ

528 ：

printデバッグなんてわざわざ無駄なコード書いて今度は消さないといけない
確かにテストである程度のバグを取る必要があるけどそれで対応できない場合がある
そういうときにデバッガは役に立つ

529 ：

値を確認するのはプロ失格

530 ：

初心者や低能はプログラムの把握能力が低いから
値を見ないと何やってんのか分からない、ということだろうね

531 ：

テストをきちんと書かないからデバッガが必要になる

532 ：

Visual Studioのデバッガが恐ろしいほど充実してるのを見ればわかる
デバッガは悪の根源ということ

533 ：

でも、デバッガはあんまり使わないヤツでも
REPLは使うよね

534 ：

じゃあ値確認しないテスト至上派は
def f(m, n):
　x = a(m)
　y = b(n)
　return x + y
assert 5 == f(1, 2)
が失敗したとき、aとbのどっちを疑うべきかどうやって判断するの?
テスト漏れなわけだからaとbのテストケースを追加してaとbのテストをやり直すの?

535 ：

使わないね
そんな実験みたいなことしてたらお客様に失礼だろう

536 ：

>>534
a,bのコード見ればいいじゃん

537 ：

JavaScriptの為の各ブラウザのインスペクターほど優秀なデバッガはない

538 ：

テストを書く段階では意味が無い
テストの前の書きかけの状態でこそ活きる

539 ：

値を確認する暇があるならテスト書けよっていつも思う

540 ：

>>536
aがさらに別の関数を呼び出してたらその先もそのまた先も読むの?
a以下を掘って掘って全部読んで結局間違いが見つからなかったとして
間違いはbにあると自信を持って言える?
そしてそれからまたbを読むんでしょ?
そんな無駄な時間をかけてお客様に失礼だとは思わないの?

541 ：

>>534
aとbがテストをパスしてるなら、まず疑うべきは「return x + y」

542 ：

>>538
コードを書きかけのときは、コードスニペットを実行する機能とかREPLの方が便利だよ
でもこれも広義ではデバッガみたいなもんかな

543 ：

REPLもデバッガの一部として話してるし
プリントっていうのはテストの一形態だと思う

544 ：

初心者にはそうだろうね
そのレベルでお金もらうのは無謀だけど

545 ：

仮説：REPLがしょぼい言語ほどデバッガが充実している

546 ：

>>540
それってaもbもテストしてないってことだろ。テストの必要が生じた時点でやるべきだろ。

547 ：

デバッガは初心者がHello World!書くときしか使い道がない
デバッガ脳は早めに卒業しないと

548 ：

>>546
無いの?テスト漏れ
本当に?ww

549 ：

テスト漏れする程度の人間はテストのテストも検討するべき

550 ：

そうだね
結論：バグのないプログラムを書けばデバッガもprintfもいらない

551 ：

その考え方が間違っている
バグのあるプログラムを書いてはいけない
これがプロとしての最低限の常識
そのためにはどうしたらよいか
1、Javascriptを正しく学ぶ
2、テストを正しく実行する
たった二つ実践するだけでバグがなくなる

552 ：

バグがないのならテストなんて要らねえじゃん

553 ：

デバッガは害悪です。

554 ：

テストに頼らないとバグのないプログラムが書けない程度の人間が
完全なテストを作れるわけがない

555 ：

バグってのは９割そいつの脳の欠陥による。
俺の場合目が悪いことによる凡ミスが多い。

556 ：

JSerってaltJSに対して二言めにはデバッガがー、デバッガがーって言ってるから
デバッガ無いとコード書けない低能だと思ってたけど、だいたい合ってた

557 ：

釣られるなよ

558 ：

デバッガの話をすると
それが出来ない言語使いが
ファビョるから面白いね。
定期的に出そう。

559 ：

デバッガが害悪ならVisualStudioは普及してねーよ

560 ：

デバッガが害悪なら
GDBなんてできてねーよ

561 ：2013/10/28

gdbみたいなインターフェースのデバッガって高機能だけど
>>451みたいな馬鹿には使いこなせないから今時流行らんよな