5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

やっぱり動的言語では安全なソフトは作れない

1 :デフォルトの名無しさん:2011/05/22(日) 03:22:26.61
型をしっかり明記してこそ
安全で堅牢、バグのないソフトは作れる


852 :デフォルトの名無しさん:2011/05/27(金) 23:34:07.08
>>850
別の話を混ぜるなと言っている

853 :デフォルトの名無しさん:2011/05/27(金) 23:36:42.52
>>849
静的な型付けは問題の一部を解決するだけ
=> 残りの部分はテストを書いたりして解決する必要がある
=> あれ?ちゃんとテスト書いたら一緒に型エラーも見つかるわ
=> 動的型付けでも良くね?


854 :デフォルトの名無しさん:2011/05/27(金) 23:38:17.83
>>850
これは本当
自分、趣味グラマーだが、割とオープンな雰囲気の会社に勤めてた時期が有ったんだが、有能な人は他人のバグを修正しつつ自分の分の開発を進めるって言うのが常で、見てて可哀想だった


855 :デフォルトの名無しさん:2011/05/27(金) 23:38:58.17
静的型付けで
記述が簡潔で
オブジェクト指向が組み込みで
obj.method() の形式でメソッドが呼び出せて
ネイティブコンパイル出来て
出来れば型推論もあると嬉しいんだけど

そんな言語無いかな

動的型付け言語が安全だろうとなかろうと、使いたい言語が全部動的型付けだから困ったもんだ

856 :デフォルトの名無しさん:2011/05/27(金) 23:42:08.44
>>853
大規模になるとテストケースは爆発的に増えて、自動化でも網羅出来なくなる
そこに、最後まで型エラーも拭い去れないとか怖過ぎ


857 :デフォルトの名無しさん:2011/05/27(金) 23:43:23.41
LLスレで教わったんだけどこれなんか

>>855
http://force7.de/nimrod/

858 :デフォルトの名無しさん:2011/05/27(金) 23:48:06.51
かわいそうなのは有能なひとを集められないから

859 :デフォルトの名無しさん:2011/05/27(金) 23:48:47.78
>>851
デプロイという言葉を知っているなら
ホットデプロイって言葉も知っていると思うけど?
開発中ならデプロイはコードを修正すると自動で完了する。

それにユニットテストはデプロイ環境でやるもんじゃない。
まさかいちいち手動でブラウザで実行してテストしてるの?

それから動的言語でも大規模になるとmod_perlや
mod_rubyなどを使うわけで、デプロイと同じように
Apacheの再起動が必要。

デプロイに関しては現実的には大差がない。

860 :デフォルトの名無しさん:2011/05/27(金) 23:49:36.02
>>857
アリガトン
調べてみる!

861 :デフォルトの名無しさん:2011/05/27(金) 23:50:37.54
>>853
> 静的な型付けは問題の一部を解決するだけ


問題の一部を解決するもの > 問題の一部が解決できない物



例:エアバッグ搭載

交通事故の一部を解決するもの > 交通事故の一部が解決できない物


冷静になれよ。銀の弾丸などない。
どちらがベターかで話せ。

862 :デフォルトの名無しさん:2011/05/27(金) 23:53:06.48
>>855
OcamlとF#かな。。。
OcamlはC並のネイティブ吐けるとか言われてるけど、haskellの勉強の過程で入門書読んだだけで、実際に使った事は無い


863 :デフォルトの名無しさん:2011/05/27(金) 23:55:24.80
つーか、エラーは早い段階で分かったほうが
修正も早いってこと知らないのかな?

ソフトウェアだけのことじゃなくてなんでもそうだよ。
ミスは早いうちに対処していれば、リカバリー早くなる。


ユニットテストではすべてのテストを自動化できない。
=> どっちみち人間がすべての機能を実行してテストする必要がある。
=> あれ? 人間がテストするならユニットテストで見つかるエラーも見つかるわ
=> ユニットテストいらなくね?

>>853が言っていることはこれと同じ。



864 :デフォルトの名無しさん:2011/05/27(金) 23:58:57.09
>>863
静的型言語派だが、それも極端杉


865 :デフォルトの名無しさん:2011/05/28(土) 00:01:34.62
※個人の感想です

866 :デフォルトの名無しさん:2011/05/28(土) 00:02:45.56
>>863
俺も静的言語派だが、こんなアホと一緒にされるのは
ごめん被る


867 :デフォルトの名無しさん:2011/05/28(土) 00:03:02.78
>>859
ホットデプロイでもロードに時間かかるじゃん。
コンパイルにも時間かかる。実行するのにも時間かかる。
数秒の時間ではあるけど、積もれば結構な時間だし、
トライ&エラーでサクサク開発というのとはちょっと違う
んだよなぁ。

例えば、この変数の値をちょっとみたいとか、関数の戻り値
を調べたいなと思った時に、デバッガでブレークポイントはって
止めて調べるといった手順をふむより、ちょっとprint文書いて
出力してみるといったことが、Javaの場合、ちょっと億劫に感じる。
ま、数秒の差ではあるんだけど。でも面倒くさい。


868 :デフォルトの名無しさん:2011/05/28(土) 00:03:47.41
俺も静的言語派だが○○○○ ← ここに煽ることしかできなくなったセリフを入れてください。

869 :デフォルトの名無しさん:2011/05/28(土) 00:04:55.11
>>867
> ホットデプロイでもロードに時間かかるじゃん。

だからユニットテストならデプロイは不要。
こっちを無視すんな。

人間がコード上の間違いを捜すほうが時間かかる。
塵も積もればな。

870 :デフォルトの名無しさん:2011/05/28(土) 00:06:27.95
>>867
デバッガでブレークポイントはるだけなら、
コードの修正いらないんだから
デプロイもいらないじゃん。

871 :デフォルトの名無しさん:2011/05/28(土) 00:07:48.09
ユニットテストならデプロイは不要って誰が決めたんだ?

872 :デフォルトの名無しさん:2011/05/28(土) 00:11:45.81
しかし、Eclipseの糞重さは、イライラが積もるな

873 :デフォルトの名無しさん:2011/05/28(土) 00:14:05.06
>>861
型に対して可能なテストは「その変数の指すオブジェクトに対して
これをすることはできるか?」だけだ。
一方、テストは通常オブジェクトの振る舞いについてテストする。
後者の方が明らかに強いテストで、後者を通るなら前者も通る。
だから、型エラーが出るならテストが不十分ってこと。

実際、動的言語で十分なカバレッジを達成したときには型エラー
なんて見ないぞ?実際に動的言語で開発した経験あるのか?


874 :デフォルトの名無しさん:2011/05/28(土) 00:17:07.63
これでも読んで落ち着こうか

Strong Typing vs. Strong Testing
https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk


875 :デフォルトの名無しさん:2011/05/28(土) 00:17:24.04
>>871
そもそも、ユニットテストとはユニットのテストなので
ウェブサーバーはもちろんデータベースなどの
ソースコード以外の外部の何かは使用しないのが常識。
テストを早く実行する妨げにもなる。


876 :デフォルトの名無しさん:2011/05/28(土) 00:18:48.52
>>873
君は両方やるという考えはないのかな?

両方やると二度手間、無駄ではないかの答えは、
エラーは早く検出し早く直す物というのが答えだ。

877 :デフォルトの名無しさん:2011/05/28(土) 00:20:27.92
>>873
> 実際、動的言語で十分なカバレッジを達成したときには型エラー
> なんて見ないぞ?実際に動的言語で開発した経験あるのか?

言い換えると

十分なカバレッジを達成しなければ
型エラーを見ることがあることだろ。

十分なカバレッジを得るまで時間がかかる。

878 :デフォルトの名無しさん:2011/05/28(土) 00:21:26.81
>>873
それは当たり前だがや
そこまで行くのに、コンパイル時にエラーで見つかるのと、テストで見つけるのはどっちが早いかだがや

他のテストは実質的に同じ事するだがや


879 :デフォルトの名無しさん:2011/05/28(土) 00:21:33.61
実際、動的言語で開発した場合に判明する、型不一致に起因する
エラーの割合なんて、全体の不具合の中で1%にも満たないだろ。
それより、動的言語から得られる恩恵の方がはるかに大きいよ。

Javaでありがちなヌルポとかにもお目にかからないしな。


880 :デフォルトの名無しさん:2011/05/28(土) 00:21:37.85
「○○という条件なら問題ない」という言い方は、
「○○という条件を達成しないかぎり問題がある。」
と言い換えられます。

注意しましょうw

881 :デフォルトの名無しさん:2011/05/28(土) 00:22:59.86
> Javaでありがちなヌルポとかにもお目にかからないしな。

え?

$obj = null;
$obj->foo();

これでヌルポにならない言語なんてあるの?
あ、エラーメッセージが違うとかそういう話かw


882 :デフォルトの名無しさん:2011/05/28(土) 00:24:14.19
>>879
> それより、動的言語から得られる恩恵の方がはるかに大きいよ。

動的言語で得られる恩恵の殆どは
静的言語でできるからなぁ。

恩恵? なにそれ?


883 :デフォルトの名無しさん:2011/05/28(土) 00:24:48.46
>>875
いやいやいや、ユニットテストでもWWWやDB周りのテストも当然するだろ。
人がしなくていいんだよ、Mechanizeとか使ってテストケース書いて自動化も
できるし。何ゆってんの?

884 :デフォルトの名無しさん:2011/05/28(土) 00:26:21.41
えーと、見つかるのが早いか遅いかが
争点になってますが、何で早くみつけなきゃいけないの?

静的言語だと、型の不一致が見つかったら
下手すりゃクラス構造とかの設計まで見直す必要が出てきて
修正が大変になるから早く見つかった方が良いだろうけど、
動的言語なら何時見つけても修正の手間は一緒だぞ?


885 :デフォルトの名無しさん:2011/05/28(土) 00:30:37.33
Javaの設定ファイルは糞。XMLというだけで糞。マジキチ

886 :デフォルトの名無しさん:2011/05/28(土) 00:30:52.69
>>883
それは機能テスト。

テスト自動化=ユニットテストのように
間違ってる人多いんだよな。

887 :デフォルトの名無しさん:2011/05/28(土) 00:31:30.98
>>884
> えーと、見つかるのが早いか遅いかが
> 争点になってますが、何で早くみつけなきゃいけないの?

直すまでの時間が短いから

888 :デフォルトの名無しさん:2011/05/28(土) 00:34:51.61
>>884
> 静的言語だと、型の不一致が見つかったら
> 下手すりゃクラス構造とかの設計まで見直す必要が出てきて
> 修正が大変になるから早く見つかった方が良いだろうけど、
> 動的言語なら何時見つけても修正の手間は一緒だぞ?

その例だと、動的言語のほうが時間がかかる。

型の不一致が見つかる場合は、例えばこの変数に入れてはいけない
値をいれた時。一箇所直しても、他の箇所で入れてるかもしれない。

動的言語だと、あるコードを実行してそのことに気づいても、
気づいたところ以外で同じ間違いしている可能性を排除できない。

つまり捜し回ることになる。

889 :デフォルトの名無しさん:2011/05/28(土) 00:34:59.19
>>886

ServletのdoPost()やdoGet()メソッドのテストも、立派な単体テストだろが。
何ゆってんの?

890 :デフォルトの名無しさん:2011/05/28(土) 00:35:25.30
>>881
PythonもRubyもならないよ
Noneやnilのfooを呼んだってCよろしく0番地にアクセスするわけじゃないから

891 :デフォルトの名無しさん:2011/05/28(土) 00:35:39.04
doPostやdoGetを直接呼べや。

892 :デフォルトの名無しさん:2011/05/28(土) 00:36:24.61
>>890
エラーが表面化しないだけで、正しく動いてねーだろうがw

こういう状態が一番困る。

893 :デフォルトの名無しさん:2011/05/28(土) 00:37:07.55
>>884
本気でそう思ってるの?
動的静的関係なく、後から手直しって大変になるのは変わらんぞ?
そりゃあ手直し自体は動的の方が楽だろうさ
でも、その分後から大量に発覚する確率も高いわけよ

一定の規模を超えると、後から発覚するバグの数に違いが大きく出ると感じてるんだがな

どっかで定量的に比較してないもんかね

プログラマが人間だっていう視点から言えば、追い込み時期にバグが見つかるのは心が折れるぞ
実際に逃げる奴も居るらしい


894 :デフォルトの名無しさん:2011/05/28(土) 00:39:05.47
>>891
そんなもんテストになるかw
まぁ、がんばってフォームの入力値や、認証データ、環境変数、クッキーの値など、
想定する環境と同じようにメソッド渡せればいいかもしれんが、そのテストコードを
用意するだけでひと苦労だなw

895 :デフォルトの名無しさん:2011/05/28(土) 00:39:27.95
>>889
えーと、単体テストでは出来る限り単体の
クラスをテストするって知ってるかな?

だから単体テストというわけだけど。

あんた、doPostやdoGetで
いろんな処理をしすぎてない?

コントローラではユーザー入力の値のチェックをする程度で
その後の処理はサービスクラスなどに渡すんだよ。
(そしてサービスクラスをユニットテストする)

896 :デフォルトの名無しさん:2011/05/28(土) 00:40:31.14
動的言語のぬるぽ的なエラーは、Javaほどメンドクサイ事態になることはほとんどない。

897 :デフォルトの名無しさん:2011/05/28(土) 00:43:06.02
>>894
だから、それはユニットテストじゃないってば。

ユニット=単体。
お前がやってるのは単体ではない。

別に機能テストが無駄という意味じゃない
それはユニットテストではないという話だ。

たぶん初心者のようにコントローラで
コードをがしがし書いてるんだろうが、
まあどの言語でもいいからウェブフレームワークを勉強しろ。

今時doGetとかdoPostを使ってる時点で
15年前かよって思ったがな。

898 :デフォルトの名無しさん:2011/05/28(土) 00:43:41.35
Java厨は、複数画面の遷移がある処理のテストも人が手動で動かして目視でやってるのか

899 :デフォルトの名無しさん:2011/05/28(土) 00:44:22.59
○○厨っていってるやつは、
なにか恨みでもあるのか?

900 :デフォルトの名無しさん:2011/05/28(土) 00:44:38.81
>>892
nil.foo()したらその時点で例外吐いて止まるよ

901 :デフォルトの名無しさん:2011/05/28(土) 00:44:58.65
>>900
なんて例外?

902 :デフォルトの名無しさん:2011/05/28(土) 00:45:03.55
ちょっとまて。画面の遷移と表示まで全自動なの?

903 :デフォルトの名無しさん:2011/05/28(土) 00:46:52.67
nil pointer exceptionなんじゃね?

904 :デフォルトの名無しさん:2011/05/28(土) 00:47:12.57
>>893
本音を言うと、型エラーが大量に発覚なんて一度も経験無いから、
そういうことを言う人はどういうコード書いてるのかなって思う。

こっちこそ聞きたいよ。あんたはそんなに型エラー発生させてるの?


905 :デフォルトの名無しさん:2011/05/28(土) 00:47:47.56
C++使いにはあほらしい話題だ

906 :デフォルトの名無しさん:2011/05/28(土) 00:48:06.06
単体テスト = TT

907 :デフォルトの名無しさん:2011/05/28(土) 00:48:18.62
ソースを一番最初に読むのはコンパイラじゃなくて、書いた人
網羅しなくていいなら、検出する早さでも人が圧倒的に早いよ
機械でやるべきことは、多少遅くてもいいから網羅すること

908 :デフォルトの名無しさん:2011/05/28(土) 00:48:29.94
>>897
あぁ、じゃぁStrutsのActionメソッドでもいいよ。Actionメソッドはテストするんだろ?
どっにしても、引数には、HttpServletRequestやHttpServletResponseが含まれるじゃねーか。
この引数とそれに対する挙動が正常なことを確認する単体テストはしないのかよ。気楽なもんだな。


909 :デフォルトの名無しさん:2011/05/28(土) 00:50:20.74
>>896
バカか
ノウハウありゃ大した差では無いわ

それよりデバッグ終盤の自分が修正した箇所が他に影響してないって保証の方が安心感があるわ

自分自身の自信とは別で、保証されてるんだぜ?
デスマじゃ無い時は余裕もってテストを眺めてられるってもんよ


910 :デフォルトの名無しさん:2011/05/28(土) 00:50:28.54
>>888
テストで見つかったところだけ直せば良いんだよ。
どうせ最終的には高いテストカバレッジまで持ってくんだろ?
だったら最終的には全部見つかるさ。


911 :デフォルトの名無しさん:2011/05/28(土) 00:50:43.64
>>908
だから機能テストとしてはするが、
単体テストではしない。

その部分は単体テストをしなくていいように
コードを最小限にする。

912 :デフォルトの名無しさん:2011/05/28(土) 00:51:32.54
>>902
マクロで書けるだろ
動的静的関係ない


913 :デフォルトの名無しさん:2011/05/28(土) 00:51:35.06
結局議論は意味なくてシェアで決まるんだよな
Javascriptが今後どう変化していくかは注目。

914 :デフォルトの名無しさん:2011/05/28(土) 00:52:01.71
>>897
>今時doGetとかdoPostを使ってる

何という俺。
職業プログラマじゃないんでフレームワークとか覚える時間が勿体ない。
どうせ1年に100個も画面を作らないし。

915 :デフォルトの名無しさん:2011/05/28(土) 00:52:22.56
目視のテストで全自動w

916 :デフォルトの名無しさん:2011/05/28(土) 00:53:11.42
お前らテスト書く時間あっていいな。
ゲーム業界なんてプロトタイピング=マスターアップだぞ。

917 :デフォルトの名無しさん:2011/05/28(土) 00:54:34.60
ゲーム業界じゃあ動的言語は実行クソ遅すぎて
別の意味で使い物にならないのでは?


918 :デフォルトの名無しさん:2011/05/28(土) 00:55:33.64
Strutsももう古いと思うがw

919 :デフォルトの名無しさん:2011/05/28(土) 00:55:39.24
>>917
GCあった時点でアウト

920 :デフォルトの名無しさん:2011/05/28(土) 00:55:48.75
>>915
全自動はねーよ
特にデザイン系は人間の感覚しか頼りにならん


921 :デフォルトの名無しさん:2011/05/28(土) 00:58:02.09
いずれにしても、不具合のほとんどは、実行時に発生する。型の不一致をやらかす
ような奴は、学生か新人君ぐらいだろ。

ほとんどの不具合は、論理的なものや、例外の見逃しや、想定外の仕様や、挙動
によるものだ。

Javaだって、文字列に数値いれたはずが、数値に変換する時に例外発生したとか、
日付の書式変換で例外が発生したとか、そんなんが多いんだろ?

922 :デフォルトの名無しさん:2011/05/28(土) 00:58:06.58
>>971
Lua が結構使われていると聞いた気が

923 :デフォルトの名無しさん:2011/05/28(土) 00:58:29.43
Luna

924 :デフォルトの名無しさん:2011/05/28(土) 00:59:05.01
Lua

925 :デフォルトの名無しさん:2011/05/28(土) 00:59:24.91
Luaは使われてるけどデメリット解決されてない

926 :デフォルトの名無しさん:2011/05/28(土) 01:00:04.46
使われているってことはメリットが大きいってことだろ

927 :デフォルトの名無しさん:2011/05/28(土) 01:00:36.79
>>926
メリットが
・ホットスワップ可能
なんだけどね

928 :デフォルトの名無しさん:2011/05/28(土) 01:01:30.65
>>921
> Javaだって、文字列に数値いれたはずが、数値に変換する時に例外発生したとか、
> 日付の書式変換で例外が発生したとか、そんなんが多いんだろ?

いまどきのフレームワークを使えば、
ユーザーの数字入力は数値型変数に直接がはいるイメージになる。
型変換コードは書かない。

型に合わない入力はフレームワークの設定で
簡単にエラーメッセージとして表示できるようになってる。

929 :デフォルトの名無しさん:2011/05/28(土) 01:01:37.41
>>927
総合的なメリットの話をしているんだが

930 :デフォルトの名無しさん:2011/05/28(土) 01:02:29.36
>>929


931 :デフォルトの名無しさん:2011/05/28(土) 01:02:54.62
>>921
想定外の仕様ってか使用だな
これが一番厄介だ
GUI作る時はこれが地獄の元

CUIとか、専用機器の組み込みはこっちが処理の流れ作れるから楽


932 :デフォルトの名無しさん:2011/05/28(土) 01:04:09.97
みんなウィザード気取ってるけどどうしょもないコードしか挙がってこない現実

933 :デフォルトの名無しさん:2011/05/28(土) 01:04:19.36
>>928
なんでフォームからの入力値のチェック限定なんだよ
DBからの読み込み、ファイルからの読み込み、Webサービスの戻り値、リモートコールの呼び出し
INPUTはいろいろあるだろうが。

934 :デフォルトの名無しさん:2011/05/28(土) 01:04:19.67
みんなテストの網羅率そんなに高いのか。
そーするとテストコードの量も増えそうだけど、動的言語はその辺不安じゃないのかな?
テストのテストまで書かないだろうし。
あとは型変換でこけるんじゃなくて、呼び出し元の仕様変更でパラメーター数が
変わらないような時もちょっと怖いかなと思ってるんだけどそうでもないのかな?モックにしてると気づかなさそうで。

935 :デフォルトの名無しさん:2011/05/28(土) 01:05:06.53
new,deleteなんて忘れねーよという奴は信用しない

936 :デフォルトの名無しさん:2011/05/28(土) 01:09:06.77
>>933
例えばファイルからの入力で
ファイルに数値が入っている前提だとして、
間違って文字列が入っていたとする。

静的言語ならすぐさま数値型変数にいれて
プログラムのメイン処理では全部数値型を使う。
だから、入力して変換する部分ですぐにバグがあることが表面化するけど

これが動的言語なら、文字列のまま
プログラムのメイン処理に進んでしまう。
バグが表面化するまで時間がかかる。

937 :デフォルトの名無しさん:2011/05/28(土) 01:11:23.72
>>934
高いわけねーだろw

だがそれを認めると
テストコードがあるから動的言語でも大丈夫
という主張が崩れるんだよw

938 :デフォルトの名無しさん:2011/05/28(土) 01:11:49.66
>>934
んにゃ
素人さん(?)が想像してるより泥臭い人力の場面は多分にあるw
人間の目しか信用出来ない場面って、結構あるべ

第一、ゲーム業界のゲームバランスなんて、人間以外何がやるってんだよwww

自分はプログラマじゃなくてテスターだったんだがなw
(ゲーム業界ではない)


939 :デフォルトの名無しさん:2011/05/28(土) 01:12:56.53
>>936
% ruby -e 'Float("TNOK")'
-e:1:in `Float': invalid value for Float(): "TNOK" (ArgumentError)
% python -c 'float("TNOK")'
ValueError: could not convert string to float: 'TNOK'

940 :デフォルトの名無しさん:2011/05/28(土) 01:14:13.17
>>937
えー、お前の所と一緒にすんなよ
まあテストしないなら静的言語の方が安全なんじゃね?
テストしてある動的言語のプログラムよりはボロいけど


941 :デフォルトの名無しさん:2011/05/28(土) 01:14:21.24
楽したいじゃんといいつつテストは網羅するぜという矛盾

942 :デフォルトの名無しさん:2011/05/28(土) 01:15:43.19
ところが実際は、動的言語でもほとんど問題にならないし、問題があってもたいていはすぐにわかる。

その数値を計算や、書式変換する必要があるなら、そこでエラーになるし。たんに表示するだけなら、
そもそも文字列として扱うだけだし。そのことが問題であれば、データの生成元の責任ということになる。

実際、動的言語で型の不一致で致命的なもんだいを引き起こすことなどほとんどないと言っていい。
ほんとうの不具合は、静的言語も動的言語も他のところにある。
型の不一致にたいして、どんだけ悲観的なんだよ。心配しすぎだろ。 他に心配しなきゃならんことが
いくらでもあるだろが。

943 :デフォルトの名無しさん:2011/05/28(土) 01:16:44.35
どのくらいのコードサイズ前提で語ってるか宣言してから書き込んでくれ

944 :デフォルトの名無しさん:2011/05/28(土) 01:18:03.98
フラットなコードと、きちんとモジュール化されたコードでは
同じサイズのコードでも取り回しが全然違う件

945 :デフォルトの名無しさん:2011/05/28(土) 01:19:27.51
>>941
静的言語ならテストは網羅しなくていいとか冗談きついぜ


946 :デフォルトの名無しさん:2011/05/28(土) 01:19:30.23
さぁ、寝るか

947 :デフォルトの名無しさん:2011/05/28(土) 01:20:06.85
してないくせに何いってんだ

948 :デフォルトの名無しさん:2011/05/28(土) 01:21:00.69
何を持って網羅っていってんの?

949 :デフォルトの名無しさん:2011/05/28(土) 01:22:02.37
業務系に限って言えば、型は数値と文字列と配列と連想配列があれば、ほとんどの処理は大丈夫だな。


950 :デフォルトの名無しさん:2011/05/28(土) 01:24:21.80
>>942
んなの当たり前
問題わな
製品として出した後から修正出来ないとか、修正が難かしい(許可が下りにくいとか時間が掛かるとか)

そういう環境に動的言語は向かないんよ

一回出したらバグが在ろうが何だろうが、余程ひどいバグじゃない限り走らせ続けるってプログラムは大規模でも組み込みでも多いのよ

修正が容易かどうかじゃなくて、どの位の動作が保証出来るか?が重要なんだよ


951 :デフォルトの名無しさん:2011/05/28(土) 01:24:42.81
>>948
たぶんC0カバレッジ


952 :デフォルトの名無しさん:2011/05/28(土) 01:26:31.77
型はbyteしかなくてもいいw

953 :デフォルトの名無しさん:2011/05/28(土) 01:29:50.71
>>950
本番前のテストでの修正が容易いって言ってんだよ
なんで本番後の話になってんだよ
動作の保証はテストでやれよ


954 :デフォルトの名無しさん:2011/05/28(土) 01:30:23.54
机上の空論

955 :デフォルトの名無しさん:2011/05/28(土) 01:40:43.47
実際、動的言語では型はあまり意識しない。という意識はするが、
そこまで神経質に気をはって使うわけではない。だいたい型の種類も
少ないが、基本は文字列。数値として使う場合は、それが数値として
使えればいい。極端にいえば、その変数が数値としての性質もって
いればいい。いわゆる、ダックタイピングってやつで、それが流儀
みたいな感じになってしまった。そいつがガーと鳴けばアヒルだろうと。


956 :デフォルトの名無しさん:2011/05/28(土) 01:42:50.18
>>953
それは本質的に動的も静的も同じだろ
テストも万能ではないのは結構前から知られてるし、そうなると静的型言語が選ばれる事になる

客にとっては開発が容易とか関係無いのよ
客にとって、オペレーターとか、エンドユーザーの奇想天外な操作でも対応出来るかどうかが問題なだけ
テストとは別の形で保証出来るから採用されるんだよ

本質的に同等のクオリティに出来るとしてもね
作ってる側も、本質的に同等のクオリティだと太鼓判押せないし、そんな責任取りたくないし


957 :デフォルトの名無しさん:2011/05/28(土) 01:43:20.74
>>953
動作の保証じゃなくて、
文法の保証はいつやるべき?

958 :デフォルトの名無しさん:2011/05/28(土) 01:44:30.07
100じゃないんだから0でもいっしょだろ!

959 :デフォルトの名無しさん:2011/05/28(土) 01:45:22.76
>>958
詐欺罪でタイーホ


960 :デフォルトの名無しさん:2011/05/28(土) 01:45:32.86
静的言語は動作後が楽になるんじゃなくて
動作までが楽になると考えればいい。

961 :デフォルトの名無しさん:2011/05/28(土) 05:23:43.27
ここまで読んだ。
本気でTDDとかBDDって流行ってないんだね。

962 :デフォルトの名無しさん:2011/05/28(土) 08:31:24.76
>>961
どの言語でもできる手法では優位に立てない
優位に立てないなら安全とは言えない
という論調が強いからね
要は、克己的なことより他人との比較を重視する人が多い

963 :デフォルトの名無しさん:2011/05/28(土) 08:47:58.58
        まもなくここは 乂1000取り合戦場乂 となります。

      \∧_ヘ     / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ,,、,、,,, / \〇ノゝ∩ < 1000取り合戦、いくぞゴルァ!!       ,,、,、,,,
    /三√ ゚Д゚) /   \____________  ,,、,、,,,
     /三/| ゚U゚|\      ,,、,、,,,                       ,,、,、,,,
 ,,、,、,,, U (:::::::::::)  ,,、,、,,,         \オーーーーーーーッ!!/
      //三/|三|\     ∧_∧∧_∧ ∧_∧∧_∧∧_∧∧_∧
      ∪  ∪       (    )    (     )   (    )    )
 ,,、,、,,,       ,,、,、,,,  ∧_∧∧_∧∧_∧ ∧_∧∧_∧∧_∧∧_∧
      ,,、,、,,,       (    )    (    )    (    )    (    )

964 :デフォルトの名無しさん:2011/05/28(土) 09:09:30.72
動的言語でもプログラム中のAPIドキュメントととして関数なりメソッドなりの入り口に
想定される引数の型と戻り値の型を書くと思うんだけど、これを利用しないのって勿体無くない?
少なくとも処理系作る側になると型情報は欲しい。

965 :デフォルトの名無しさん:2011/05/28(土) 09:16:30.94
強力な型システムがあればそれをそのまま型としてコード内で2級以上の市民として扱えるいうのはある
ただプログラマがそれを利用できるかは別問題な

966 :デフォルトの名無しさん:2011/05/28(土) 09:16:53.73
一時期Cで組み込み型排除して全部enumとtypedef用意してた

967 :デフォルトの名無しさん:2011/05/28(土) 09:28:02.28
>>964
Pythonでtype annotationとかそれっぽいのがあった気がする
よくよく調べたらがっかりした覚えがあるけど

968 :デフォルトの名無しさん:2011/05/28(土) 09:32:59.47
annotationでは駄目なのだ
言語内で1級市民として扱える仕組みでないと

969 :デフォルトの名無しさん:2011/05/28(土) 10:00:56.77
Pythonなら俺は、例えば数値を受け取るメソッドを

def foo(n):
    n = int(n)

で書き始めるかな

970 :デフォルトの名無しさん:2011/05/28(土) 10:24:05.73
動的言語は型の扱いがややこしい。
混乱の元だよね。

971 :デフォルトの名無しさん:2011/05/28(土) 10:34:34.79
分かって使ってるとへ思えない
理解するくらいなら他の言語のほうがいい

972 :デフォルトの名無しさん:2011/05/28(土) 10:38:00.96
pythonで
>>> "12"+1
を実行すると
TypeError: cannot concatenate 'str' and 'int' objects
っていうエラーが出てきます。
動的言語なのになんでですか?

973 :964:2011/05/28(土) 10:40:56.80
>>970
処理系が解釈するのも人間が解釈するのも複雑で、デメリットのほうが多いような気がしてる。


974 :デフォルトの名無しさん:2011/05/28(土) 10:42:44.88
静的言語に型推論があれば、動的言語のメリットはなくなるよね。

975 :デフォルトの名無しさん:2011/05/28(土) 10:44:02.94
型推論にメリットがない

976 :デフォルトの名無しさん:2011/05/28(土) 10:45:23.69
>>972
それは実行時の安全装置なので
コンパイル時に比べると劣っているという噂

977 :デフォルトの名無しさん:2011/05/28(土) 10:46:35.64
>>975
plus :: Int -> Int -> Int {- ←型推論でこいつが省略できる -}
plus x y = x + y

978 :デフォルトの名無しさん:2011/05/28(土) 10:48:48.03
>>972
Pythonは型付けが強いから
PerlやPHPは弱くてRubyやPythonは強い

>>976
噂て。

979 :デフォルトの名無しさん:2011/05/28(土) 10:53:06.77
>>978
pythonもperlも型に関しては大差ないよw
違いはプリミティブ関数や演算子の型に対する柔軟さ。

980 :デフォルトの名無しさん:2011/05/28(土) 10:56:24.32
>>979
ん、よくわからない
コード貼って例示おねがい

981 :デフォルトの名無しさん:2011/05/28(土) 11:04:28.13
型推論というか柔軟で安全な暗黙的な型変換は欲しい

たとえば組み込み型のnilとconsで定義されたリスト[]形とユーザー定義のNIL、CONSで定義されるList形があって
これを大抵fromList::List->[]、toList::[]->Listという変換関数を用いる事で混在して使用するところを
[]に対する操作fがListに対しても同じように適用できてその操作をFと仮定すれば
fをListに適用するときに自動的にFを生成してそれを適用することができる

これが安全に適用可能な条件として変換元の型と変換先の型が自然同型であるというのがあるんだけど
その証明をユーザーが提供することでこの自動変換機構を安全に処理系が提供することができる・・・と
再帰的に定義された型同士なんかではそれこそ処理系がその証明を自動で行うことすら可能だ
でこれを応用すると二つの同型である型を行き来しながら処理を行うコードに対して
変換関数の適用回数を多くても一回にする、というような最適化が可能になるという利点も
そこまでいかなくてもformなんとかとtoなんとかが何回も出てくるコードが見やすくなるというのは確実だ

で、これをphpの例でよくある文字列<->数値の相互変換というもので使おうとすると
どう変換関数を定義しても自然同型という性質が証明できないんで、自然同型であるものと比べて危険な変換であるというのがわかる

982 :981:2011/05/28(土) 11:10:38.80
自然同型ってそういうもんだっけ感が・・・
まぁいいやただの思考ダンプなんで雰囲気で

983 :デフォルトの名無しさん:2011/05/28(土) 11:13:45.12
>>981
それはHaskellのShowとかと違うの?
外見的にはそれっぽいんだけど

984 :デフォルトの名無しさん:2011/05/28(土) 11:13:52.35
話し変わるんですけど強く型付けされた軽量言語って何がある?

985 :デフォルトの名無しさん:2011/05/28(土) 11:20:36.68
>>984
>>978


986 :デフォルトの名無しさん:2011/05/28(土) 11:22:00.95
>>983
違う
あれは具体的にユーザーが変換関数を両方定義してその定義したものを使用する際には明示的に書く必要があるんだけど、
これはその性質を証明できればその定義がいらないのと、明示的に書く必要が無い

型の定義の構造が同じであるような自明に近いようなな場合はそういう証明はコンピュータで自動的にできる、あるいは
その証明の一部を人の手ですることで残りをコンピュータに任せられることができるんだよね

987 :デフォルトの名無しさん:2011/05/28(土) 11:32:11.88
>>981
まあ、haskellでも
"122" ++ 45 = "12345"
って言うのは演算子の左側に型を合わせるとか決めれば、型推論の応用で仕様に追加出来るんだろうけど、そのコードが意図的にそう書いたのか、バグなのかはプログラマしか知らないんだよな

明示的に型変換させた方が読む側にとってはバグじゃないって分かって安心出来る


988 :デフォルトの名無しさん:2011/05/28(土) 11:32:34.45
>>985
ごめん、静的型付け言語でお願い。

989 :デフォルトの名無しさん:2011/05/28(土) 11:40:32.01
>>988
軽量 = 動的言語

静的で強い型付けって、最近出てる静的はみんな強い型付けだよ
javaもc#もscalaもhaskellも


990 :デフォルトの名無しさん:2011/05/28(土) 11:41:32.03
静的言語 vs. 動的言語

というより、

コンパイラ vs. インタープリタ

って感じだな。



991 :デフォルトの名無しさん:2011/05/28(土) 11:42:43.54
>>984
haskell

992 :デフォルトの名無しさん:2011/05/28(土) 11:43:09.26
Java厨は、メソッド名の変更が問題ないかコンパイル時に教えてくれれば
満足なんだろう。

993 :デフォルトの名無しさん:2011/05/28(土) 11:43:54.68
>>989
軽量 ≠ 動的言語

軽量言語って対話環境が用意されている言語のことじゃないの?

994 :デフォルトの名無しさん:2011/05/28(土) 11:44:19.15
>>990
haskellやc言語にもインタプリタ有るし、lispにもコンパイラ有るけど、事実上、二つの対決関係はイコールだからな


995 :デフォルトの名無しさん:2011/05/28(土) 11:47:03.38
>>993
関数型言語ならともかく、手続き型言語では≒だが


996 :デフォルトの名無しさん:2011/05/28(土) 11:48:02.47
>>992
おまえは少しは空気読めよ。

997 :デフォルトの名無しさん:2011/05/28(土) 12:04:33.94
>>992

998 :デフォルトの名無しさん:2011/05/28(土) 12:55:53.11
次スレよろ

999 :デフォルトの名無しさん:2011/05/28(土) 12:57:55.15
↓このスレの総括

1000 :デフォルトの名無しさん:2011/05/28(土) 13:01:38.00
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

                  京都大学霊長類研究所

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

227 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)