[GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> foo = "string" >>> bar = 100 >>> print foo + bar Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: cannot concatenate 'str' and 'int' objects >>>
でさ (スコア:0)
言語としての評価はどうなの?
Re: (スコア:0)
静的な型を選んでしまった事は
rubyやPHPに対する、非常に大きなハンディキャップになると思います。
静的に型を決定するという事は、まつもと御大の言うとおり非現実的な拘束であって
ちょっとメソッド名を間違えただけで、コンパイルすらできない状態になります。
まさに「このプログラムは無害だ、なぜならば、動かないからだ」の状態です。
このおかげで、PCの世界は、理想的な状態に比べ20年以上は遅れているはずだと
勝手に妄想しています。本当に勝手な妄想ですがw
翻って動的型付けの言語は、プログラマに対してもユーザに対しても柔軟で
特にPHPは変数宣言すらも省いてしまい
Re:でさ (スコア:0)
ネタですか?
> ちょっとメソッド名を間違えただけで、コンパイルすらできない状態になります。
動的言語でメソッド名間違えたら実行時にエラーになるだけですよ。
# 全部突っ込み入れたいけど頭悪すぎなので略
Re: (スコア:0)
俺のエスパー的直観だと
int foo;
print_int(foo); // ○
print_str(foo); // ×
みたいな事を言ってるような気がする。
オーバーロードで良いじゃん
Re: (スコア:0)
最近pythonかじった程度な自分には、動的型付けって何が嬉しいのか理解できない。
型を気にせず適当に書くといたるところでstr(count)やらint(input)やら書く羽目になる。
しかも実行するまでわからない。
簡単に実行できるから静的型付け言語にとってのコンパイルするようにテストするのがいいのだろうか?
それでも型ごとのテストケースつくるのだけで面倒くさい気がする。
静的型付け言語よりよっぽど型意識しなきゃならん気がするなーと。
根本的に自分の書き方間違っているような気もするけど、
静的型付け言語に洗脳されてる自分には気が付つけないもっと簡単なやり方でもあるのだろうか
Re: (スコア:0)
それstrとかintした後何に使ってんの?
print("total count is: " + count) とか sum += input ってそのまま書けば良いじゃん
pythonはしらね
Re: (スコア:0)
でした。
pythonは動的型付けではないってことか
Re: (スコア:0)
そうそうwww
型を明示させてくれないくせにチェックはきっちりしてくれちゃうんだよなwww
Re: (スコア:0)
%演算子とかstr()とか使えないレベルで動的言語を語るとかありえねぇレベルの無知だわ。
動的型付けって文字列に整数を足せることだったのか。斬新な定義だなwwwww。
Re: (スコア:0)
ツリーの流れを読んでコメントしてくださいね。
Re: (スコア:0)
> 動的言語でメソッド名間違えたら実行時にエラーになるだけですよ。
そこを通過しない限り、エラーにはなりません。
システム全体としては「あまり問題なく」動き続ける事ができます。
一方、静的言語では、コンパイルエラーが無くなるまでは
システムを全く動かす事が出来ません。
動かない間、機会費用はどんどんかさんで行きます。
なぜそんなにヒステリックに、システム全体の整合性にこだわるんでしょうね?
どうせバグの無いシステムなんてあり得ないわけで
システムはいつだって止まる可能性があるわけで
どれだけ停止期間を短くできるかが重要課題となります。
それが、動的言語の瞬発力であるわけです。
Re: (スコア:0)
ネタかと思ったら本物のバカか。
「あまり問題なく」と言ってるけど、それが決済システムなら致命的。
開発時に分かる問題を運用時に先送りしてるだけ。
そういうバカの発想じゃなくて、
動的言語はそれ以上のメリットがあるから使う。
何かは自分で考えてみることだね。おバカさん。
Re: (スコア:0)
昔から答えの出ない哲学的な問題を考え続ける哲学者に
「答えが出ないなら議論する意味は無い」って言ってるようなもんですね。
まあ、「間違えないこと」が大事だよね。
でも、「間違えるのが人間」なわけで。
# ATMが使えなくて困っちゃったよ