「変数に型がない」はメリットなのか、それともデメリットなのか。宗教戦争勃発 193
ストーリー by reo
若い山彦 部門より
若い山彦 部門より
insiderman 曰く、
プログラミング言語どうしの優劣を比較する「宗教戦争」は定期的に勃発するが、今回話題になっているのは「変数に型がない」ことはメリットなのか、それともデメリットなのか、という点だ。
発端となったのは、「サンプルコードによる Perl 入門とは」というブログの「変数に型がないということの利点について考える」という記事。ここでは Perl や Java、C++ などの例を使い、変数に型がないことの利点として「どのような型の値でも代入できる」「記述量がとても短くなる」「変数に型がないと変更に強い」「関数のオーバーロードが不要になる」「複数の型を受け取りたいときに、インターフェースを実装する必要がない」「C++ のテンプレートのような機能も必要がない」などが挙げられている。
これに対し、「型がないというのはデメリットだ」という意見もコメントやはてなブックマークで多数寄せられている。型がないデメリットとしてあげられているのは、「コンパイル時に型の不整合を検出できない」「型がある言語でも型推論を使えば記述量を減らせる」「保守性が高くなる」などのようだ。
個人的には C++ でキャスト地獄を味わったことがある体験から、近年は変数に型のない言語のほうが好みにはなっているのだが、十分かつできの良い仕様書があってそれを元にコードを書くのなら型ありの言語も良いとは思う。/.J 読者のご意見はいかがだろうか?
キャスト『地獄』? (スコア:5, すばらしい洞察)
＞ C++ でキャスト地獄を味わったことがある経験から
それって型の有無によるメリットデメリット以前に、適切なクラス設計が出来ていないのでは…
ちゃんとクラス設計出来ているのにキャスト『地獄』とまで言うような状況になることってあるのだろうか。
型有りなのに (スコア:5, おもしろおかしい)
せっかくの型チェックが形無しだな。
Re: (スコア:0)
誰が上手いこと言えと
Re:キャスト『地獄』? (スコア:5, すばらしい洞察)
「それはお前の使い方が悪いんだ、適切にやれば問題はおきない」と
言う人が出るのも、この手の宗教論争の定番ですね。
Re:キャスト『地獄』? (スコア:1)
そして事実そうであっても、初心者や老害（やマネージャーや経営者や顧客）には
全く理解されないことも定番なのです。
これは一応フィクションだけど、
http://el.jibun.atmarkit.co.jp/pressenter/2010/11/3-bc3f.html [atmarkit.co.jp]
＞ 「だからね」三浦マネージャは子供に言い聞かせるようにゆっくり言った。
＞「どうしてわざわざ違う型で宣言しなくちゃいけないの？ おかしいでしょ、普通？
＞整数使うのにfloatとか使う？ 使わないでしょ？」
＞ ――いやいやいや、それは違うでしょう。型の違いと、インターフェイスと具象クラスの違いをごっちゃにしてます。
＞ 「ArrayListを使うんなら、素直にArrayListで宣言すればいいじゃない。
＞どうしてわざわざこういう分かりにくいことをするかなあ。カッコつけか？」
みたいな感じで。
Re:キャスト『地獄』? (スコア:4, 興味深い)
プロトタイピングや、アジャイルな開発をしていると、クラスの整理法をガラリと変えないといけない時がたまに来ます。
そんな時、型なしだとちょっとずつの変更が楽なんですが、型有りだと、全コード書き直しに近い再設計が待っています。で、それをごまかすためのキャスト地獄ということは、経験があります。
はじめから仕様がかっちりしているのなら、地獄に陥らないように設計できますが。
もちろん、型なしで中途半端に変更したままにほっておくと、後々スパゲッティ同然の理解不能コードが出来上がるわけですが。
Re:キャスト『地獄』? (スコア:1)
プロトタイプ限定ならそれもありかもしれませんけどね、
「プロトタイプ限定だから型システムなんかなしでいいよね！」
「リリースする時は静的型システムのある言語で書き直すから問題ないよね！」
なんて言って、本当に書き直したことってどれくらいあるんだろう？
＃身近な事例では、書き直しが必要でありながら実際に書き直した例は見たことが無い。残念ながら。
Re:キャスト『地獄』? (スコア:2)
ずっと疑問なんですが、
なぜ最初から型無し型付け両方に対応した言語で書かないのかわかりません。
型なし版を書いて、動いたらそのまま型宣言をつければいいだけのこと。
バージョン管理しておいて、プロトタイピングに戻りたくなったら型なしバージョンに戻せばいい。
型なしを許容するけど、型をつけると早くなるというのが一番ですよ。
ついでに言えば、型をつければネイティブに静的型付けでコンパイルしてくれる言語。
まあ、外部の問題のせいで型を書き換えまくる必要が出るというのは、
スパゲッティみたいに依存しまくったクラス設計のせいだとは思いますが・・・。
新人。プログラマレベルをポケモンで言うと、コラッタぐらい
Re:キャスト『地獄』? (スコア:1)
個人的には、そうなる（型なし言語で作っているけど、型あり言語に素直に移行できるように、採集t系には持っていく）ようにしている。
希望としては、型なし言語（例えば ruby) とかで、静的型あり言語に移行できるかどうかをチェックしてくれる機構が欲しい。
Re:キャスト『地獄』? (スコア:2)
リファクタリングするときに、まずあるクラス群を整理して、次に別のクラス群を整理していく、ということをやったりしません？
そういう時には、スパゲッティにはならない（やろうと思えばなりますが）で整理できると思うのだが。
もちろん、この方法が万能ではないけれど、個人的には有用。
Re:キャスト『地獄』? (スコア:1)
プロセッサが演算するのにいちばん都合の良いビット数か、もしくは、
コンパイラを実装するのにいちばん都合の良いビット数です。
もしかすると、それは8の倍数ですらないかもしれません。
Re:キャスト『地獄』? (スコア:1)
Multicsの系統のACOS6だけだけどね
投稿フィルタにひっかかってリンクを張れないから、4と2は自分で読みに行って
http://ja.wikipedia.org/wiki/ACOS-6 [wikipedia.org]
十分かつできの良い仕様書があってそれを元にコードを書くのなら (スコア:3, おもしろおかしい)
仕様書なんて常に不足しているか間違っているかのどちらか(たいていは両方)だろ。
みたいな仕事振られたときのために型が必要なんだろうがw
型情報を使えるなら使った方がコーディングは楽 (スコア:3, すばらしい洞察)
IDEの性能にもよるのでしょうが、型情報があった方がコードの補完が効くのでお手軽にコーディングできると感じています。
型がない場合、確かに記述量は短くなるのかもしれないですけど、どう記述すればいいのかマニュアル見ないといけなかったりして面倒に感じることはあります。
＃文字列に変換するのは、to_str? to_s? to_string? とか悩まなくて済むだけでもありがたい。
デフォルト型変換は悪 (スコア:3)
「型がない」ポリシーを貫いてもらえばいいのだが
中には「デフォルト型変換」というものを持つのも
あり・・・。
「デフォルト型は数値型」という言語で文字列比較
をした場合、頭に空白や０を付加していてもTrue
になるという、とんでもない事例がありました。
最後の段落の意味? (スコア:2)
十分かつできの良い仕様書があってそれを元にコードを書くのなら型ありの言語も良いとは思う。
これは何を言っているんだろう?
逆に不十分なドキュメントしかない環境では,
動的型付けの言語の方が優れていると言いたい?
私の理解が間違いでなければ,
動的型付けであれば, 開発者が意図していない型をもつ入力が与えられても,
なんとなく動作しているように見えることがある,
という話になるのだと思います.
そして変な入力が与えられたら, その時は実行時にコケればいい.
「ドキュメントに書かれてないし, それはそれでいいんだよ」という考え方でしょうか?
たぶん, この宗教論争で一つの争点の中心になるのは,
これを「正しい」とするか「誤り」とするかの違いだと思います.
# 私はこれは誤りで,
# 発覚した時点でドキュメントの修正に戻るのが本筋だと思います.
# その具体的なタイミングを測るために,
# コンパイルエラーとして怒られた方がいい
実行効率 (スコア:2)
一般論として型がある方が実行効率に優れると思ってるんですが、いまどきのリソース潤沢な環境だとんなの論点にはならないんですかねえ。
コーディング上の理由だけじゃなくてさ。
Re:実行効率 (スコア:1)
んなことはないと思う。
Javaの高いパフォーマンスを支えてるのが静的型システムで、サーバーサイドでパフォーマンスが
欲しい分野だとJavaがデファクトスタンダードになる理由の一つだ。
でも型システムの有効性も理解できない程度の人が、静的型システムとVMのパフォーマンスとの
関係など理解できるはずも無く、議論に登ることも無いだけでは。
一長一短かな～とは思う (スコア:2)
お手軽な言語でちょっとしたものなら型がないほうが扱いやすいと思うし
お堅いモノをつくるならキッチリしてたほうがいいと思うし
プログラムはあくまで道具なので作るものにあわせて用途を選べばいいんじゃないかと思う。
Re:一長一短かな～とは思う (スコア:1)
たとえば、Ruby on Railsでよく使われるORマッパーであるActiveRecord。Rubyにおける型が動的であるがゆえに、簡潔なのに強力な使い勝手を実現しています。
これは、動的型付け言語であるRubyのメタプログラミングや柔軟なクラス実装ができる特長によるものです。
RoRは、Rubyの特長に依存しており、不可分なのです。
もとより、大規模なRoRがRubyで実装されていることや、RoRでそこそこ大規模なWebサービスが作れることこそが、その証明であると思います。
一長一短で、適材適所であることは同意です。
そこを鋭い目で見分ける勘が重要。
AS3.0は型宣言が必須になって一瞬泡食ったっけ。 (スコア:2)
型宣言必須ってのは、やっぱりTPOに合わせられなくって面倒かなあ。
スクリプト的な簡単かつ汎用的な物なら、型宣言なしでぶち込めた方が便利だろうしなあ。
Re:AS3.0は型宣言が必須になって一瞬泡食ったっけ。 (スコア:2)
「Win/Mac両対応かつ，そんなに予算がない場合で，そんなに複雑じゃないやつ」
なので，厳密な型宣言にされるよりは，ある程度なんとなく動いてくれる方がよいんだけどねえ。
社内何でも屋を標榜する私めには「目的がラクに達成されるなら，多少のアレは許される」のである。
まあ，日頃如何にたるんでいたかを再認識すると共に，「他の使うことにしよう」と思ったきっかけですな。
現状は開発環境はQtに落ち着いておるですよ。
結局C++に里帰りｗ
えー本業プログラマーじゃないのにー
車で言えば (スコア:1)
スポーツカーとワゴン車、どっちがいいかっていう話と似ているような。
Re:車で言えば (スコア:1)
てことは、次に出てくるのはスポーティーなワゴン()。
なんだホンダ車か。 (スコア:2)
たいとるおんりー？
Re:なんだホンダ車か。 (スコア:2)
「スピードワゴンはクールに去るぜ」じゃないの？
Re:なんだホンダ車か。 (スコア:1)
159は全然売れなかったよ。
売れたのはスポーツワゴン（後に156スポーツワゴンに改名）。
どっちも可能な (スコア:1)
VBが最高ってことでおk？
Re:どっちも可能な (スコア:1)
# yes, fly. no, fry.
Python,Ruby,PHP,JavaScriptなどなど (スコア:1)
お手軽にプログラミングするなら型がない方がいいとはおもいます。
プログラミング技術のコモディティ化にもすごく貢献してると思われます。
ただ、変数の型がない言語で書かれたミドルウェアには若干の不安を覚えますね。
言語仕様というよりもインタプリタの問題の気もしますけど。
若者が楽しそうにやっとるじゃないか。 (スコア:1)
この手の話はLisper連中が、３０年くらい前にさんざんやってたね。
結果Common Lispは見ての通り、中途半端な蝙蝠状態なわけだが。
静的型付けは規模が大きい（というか複数人開発）のときの抑止力かな？ (スコア:1)
個人的見解ですが、動的型付けだと規模が大きい、というかもうそれこそ2人以上からのレベルで「こうさせたくない」という意思表示が難しくなるのでちょっといやだなという印象です。ダック・タイピングでヒャッハー解釈されたそれこそ目も当てられない(ﾉ∀`)ｱﾁｬｰ
なので、そういう局面ではコメントで「絶対するなよ、絶対だぞ」と書いているのに、後年のサポートでそれを無視したあげくに落ちるんですけど的なご指摘が。。。(´・ω・｀)
以前のPHP、Javascriptなんやらの議論でも話題になってた記憶があるのですが、開発コストの中に便利機能（ライブラリとか型のauto casting/convertとか）に対するテスト工数が含まれていない気がしてなりませんし、逆に、それをしっかりやるためにドキュメントやテストをがっちりやろうとすると、「なんで動的型付け言語（LL）なのにそんなに時間かかるん？」とかestimation時に言われてがっかりします。なので、そこいらへんは純粋主義的な感情をぬぎすててやる必要があるんじゃないかと私は思います(´・ω・｀)
Re:静的型付けは規模が大きい（というか複数人開発）のときの抑止力かな？ (スコア:2)
自分がコードを書くなら容易に組めるので型は不要、他人のコードを読むなら情報や制約がわかりやすい型は必要。
そういう派閥ですとも。
関連リンクに (スコア:1)
こちらはいかがでしょうか( ´∀｀)つ ミ
GNOMEでもJavaScriptによるアプリケーション開発を推奨？ [srad.jp]
やめた (スコア:1)
他人がどう思おうが勝手だが、部下や上司には居て欲しくない。
私は強めの型制約言語が好きです。
Copyright (c) 2001-2014 Parsley, All rights reserved.
IntelliSense (スコア:1)
っていう簡単な意見が意外とないのが不思議。
発端の記事自体は… (スコア:1)
自分は動的型付言語も静的型付言語もどちらも好きですが，少なくとも発端となった記事自体で主張していることは動的型付言語（ここではPerl）の良い点としては見当外れかなぁとおもいますね．
今回の件は宗教論争ではなく，元記事の見当外れな点を多くの人が指摘，訂正しているものかと．
この件で静的型付言語の利点を主張している人も，おそらく用途によっては動的型付言語を利用しているのではないかと思います．
多くの人が指摘していますが，静的型付言語でも型推論によって変数の型を明示的に記述する必要がない言語もあります．
これらの言語では，元の記事で主張している「型の変更時に記述を変更する部分が少なくて済む」というメリットが確かにあるでしょう．
「型推論によって変数宣言時に型を明記する必要がないことのメリット」という見方をすれば一部頷ける部分もあるのではないでしょうか．
立場の違いから (スコア:0)
記述する人間からみたら、暗黙の了解で宜しくやってね。
と、型情報は処理系にお任せにしたい。
暗黙の了解で実行したら、ちがう、そうぢゃない、となることもある。
処理系の実装からしたら、実行の効率化のため付加情報として型もほしい。
だから、記述効率、デバッグ効率、実行効率、を勘案して、
バランスの取れるところに落ち着く。
様は適材適所だが、そのバランスを測るのは難しいけど人間様がやるしかない。
プロトタイプは形無しでやっつけてみて、効率化(ハンド最適化)は型情報を与えて
人間がやるとか、その辺がシームレスにできたらいいんじゃないかな。
別の視点 (スコア:1)
>記述する人間からみたら、
後から読む人間からみたら、
「型よ、あってくれー！」と、心の叫び。
馬鹿馬鹿しい宗教戦争 (スコア:0)
ひたすら大量のコードを効率よく作りまくるのに適したスクリプト言語のたぐいと、信頼性重視の開発に使うプログラミング言語をちゃんぽんに議論してもはじまらない
型無しでお気楽な方が良い場合もあれば、コンパイル時のチェックが厳密にかかる方が良い場合もある
Re:馬鹿馬鹿しい宗教戦争 (スコア:1)
スクリプト言語が効率いいって前提に異論が出てるのに、こういうこうとを言う人がいるからループして「宗教論争」になるんだろうな。
用途による (スコア:0)
メモリの使い方をカタにはめてるのは、
現在のコンピュータの性質とか、能力の限界によるものと思ってるので
現在はベターな手法だけど、将来は改善されるかもしれない。
ソフトを作ることを考えると、
コンピュータに密着してる方が都合がよいかもしれないし、
型を隠蔽した言語の方が簡単でよろしいかもしれ
環境も信条も個人によりけりなので、まさに宗教戦争やないか…
Re:用途による (スコア:2)
Re:動的型の言語のファンも内心はチェックが利かないのは欠点だと思ってるらしい (スコア:1)
これはひどい信者。
せっかくの親切なコメントをくれた人に対してその感想とか…。
Re:関連性がわからない (スコア:1)
仕様に曖昧さがなく、途中で変わらないってことでしょう。
仕様変更による設計の手戻りや、一部の設計を保留にしたまま開発を進行するといった状況が発生する場合だと、
最初に型を定義しなくてはいけない静的言語は不利になると。
C++の設計者であるストラウトラシップも「抽象化は遅れてくるプロセスだ」って言ってますね。
具体事象を抽象した存在であるところの型は、具体事象が不明確だったり変動する場合には適切に定義できないということだと思います。
動的言語は変数に型がないだけで、型というコンセプト自体は（OO言語であれば）あるわけですが、
最初にコンパイルを通せるところまで型を厳密に定義する必要がない分、仕様が曖昧な状況では動的言語が有利だと。
現実には仕様が曖昧なケースも多いわけで、まあ理解できる意見だと思います。
Re:変数名に型を入れると少し楽になる (スコア:1)
I,J,K,L,M,Lで始まる変数名は整数
Re:表現力の幅 (スコア:1)
C# なら Nullable<T> 型 [microsoft.com]でどうぞ。
int? i;
i = 1;
i = null;
こんな使い方ができる。
Re:表現力の幅 (スコア:2)
Maybeモナドの考え方だ。
あんたHaskell使いだな…（ニヤリ
Re:動的型の良さはオープンさ (スコア:1)
＞例えばJavaだとどっかから拾ってきたライブラリのクラスが必要なインターフェースを実装してなくて泣きながらアダプタを書くことがよくあるわけです
＞その点、動的型ならずっと自由度が高い
ダウト。
インターフェースが実装されてなければ、それは当然実行時エラーになるだけ。
エラーを見逃しやすいという致命的なデメリットですよ、それは。
Re:いかなくちゃ (スコア:2, おもしろおかしい)
今朝来た日経の片隅に書いてある
だけども問題は今日の仕事 仕様書が無い
行かなくちゃ 客に会いに行かなくちゃ
客の前に行かなくちゃ 電車乗り
上司の顔が 今日は心に浸みる
コードのこと以外は考えられなくなる
それはいいことだろ?
会議では現場のデスマの問題を
部下が深刻な顔をしてしゃべってる
だけども問題は今日の仕事 型が無い
(以下無限地獄)