12/02/14 12:12:19.93
咥えるって・・・
キャー///エッチー
881:デフォルトの名無しさん
12/02/14 13:04:44.28
くわ・える〔くはへる〕【×銜える／×啣える／×咥える】
［動ア下一］［文］くは・ふ［ハ下二］
１ 口に軽く挟んで支える。「楊枝(ようじ)を―・える」「物欲しそうに指を―・えている」
２ 引き連れる。伴う。
882:デフォルトの名無しさん
12/02/15 08:15:29.00
>>862
Zopeもあったのに、最初から眼中にすら置いてもらえない Python カワイソスwww
883:デフォルトの名無しさん
12/02/15 19:23:46.58
クソコードの後だから煽りも虚しいな...
884:デフォルトの名無しさん
12/02/16 11:28:52.77
amazon
mixi
モバゲー
にちゃんねる
perlってこのぐらいか？
もう役目を終えつつあるな
885:デフォルトの名無しさん
12/02/16 12:53:58.98
満を持していよいよ、Perl6 の出番か
886:デフォルトの名無しさん
12/02/16 13:58:01.59
pythonもperlも仕事増やしたいから互換性なくしたんだろｗｗｗｗｗｗｗｗｗｗｗｗ
賢いなｗｗｗｗｗｗｗｗｗｗ
htmlも大幅に増やしたしなｗｗｗｗｗｗｗｗｗ
887:デフォルトの名無しさん
12/02/16 14:27:25.82
html5は増えたのもあるけど、減ったのもある。
タグ付けとデザインが完全に分離したから、ある意味すっきりしたともいえる。
888:デフォルトの名無しさん
12/02/16 16:48:40.99
Perl5 はコンテキスト依存で 返り値が変わるのが
いまいち、ちゃんと把握してない
あと、リファレンスとかややこしい
Perl6にいたっては到底覚えられそうにもない(覚える気は無いけど)
大幅に増えた演算子をしっかり理解してないと
ソースを読むのもままならない
よくは知らんがAPLやJみたいな暗号言語に近づいた気がする
わかってる人にはコンパクトにコードがかけて効率がいいのかもしれないが
889:デフォルトの名無しさん
12/02/16 18:41:13.11
結局、PHP最強ということか。
マゾっ毛でも無い限りPHPにしとけ。
890:デフォルトの名無しさん
12/02/16 20:30:34.01
>>887
マークアップとスタイルの分離はXHTMLどころかHTML4の頃から意識されてたでしょ。
891:デフォルトの名無しさん
12/02/16 22:08:12.90
>>890
でも、html4はfontタグでフォントや色を指定したり、tableタグのwidthでボーダーの幅を指定したりとかできたよね。
html5では、タグでこれらの指定はできなくて、デザイン要素は全てCSSで指定するようになったから、分離が徹底されてるよ。
892:デフォルトの名無しさん
12/02/17 06:54:13.30
まあ、Perl5のコンテキストって、現状ほとんど使われて無くて、配列のサイズを取得する時ぐらいしか意識する必要ないけどね。
リファレンスはCのポインタが理解できる程度の能力があれば動って事内。
Perl6は型指定可能なスクリプト言語というのが非常に魅力的。
893:デフォルトの名無しさん
12/02/17 08:25:34.11
>>891
HTML5 よりも HTML4 strict の方が徹底されています
894:デフォルトの名無しさん
12/02/17 09:36:36.44
いーや、html5の方が徹底されてるよ。
895:ぱーる列伝
12/02/17 12:56:31.21
LLの連中は人脈つくりに必死に献本送ってますね
トミタさん
トミタ「うひょおおおおおおおおおおおｗｗｗｗｗｗｗｗｗｗｗｗ人脈つくり楽すぎｗｗｗｗｗｗｗｗ
適当に本書いて、上層部Perl使いや、LL企業関係者におくりまくろうぜｗｗｗｗｗｗｗｗｗ」
ってクールなツラして心の中で思ってるからしょうがねーよな
必死におこぼれにあやかろうと色々なやつが、同じLL使いを褒めあってる
ハテブとかなんかで
「尊敬するPerl使いリスト」みたいな
まじおもしれーわ
生き残りかけてる
896:デフォルトの名無しさん
12/02/17 13:06:38.83
忍者か？
897:デフォルトの名無しさん
12/02/18 09:49:37.64
>>848
>そんな暗号の様なコードは読み手に不要な知識を要求するので可読性が低い
言語仕様に型検査や検証機能が含まれていれば、それを「暗号」とは言わないし、
逆にユーザコードで表現(代用)しなければならないRubyよりも優れていると考える
>大規模開発ではこの程度のコード量の増加は誤差の範囲
開発規模とは無関係に、本質の実装コードが検査/検証コードに埋もれる点で、可読性に問題がある
たとえばこのお題であれば、メソッド f の(本質のコードとは) z = x + y であり、
同様にメソッド g であれば print x だけであるけれど、それが一目で認識しずらくなっている
自分なら>>825のお題について、(後置の)unless修飾子と(メリハリを入れる)空行を使って、
以下のように書く
(続く)
898:デフォルトの名無しさん
12/02/18 09:50:19.16
(>>897の続き)
def f(x, y)
raise TypeError unless x.kind_of?(Integer)
raise TypeError unless y.kind_of?(Integer)
z = x + y
raise TypeError unless z.kind_of?(Integer)
z
end
def g(x)
raise RuntimeError unless -1 < x && x < 1
print x
nil
end
899:デフォルトの名無しさん
12/02/18 12:16:14.51
There's more than one way to do it
900:デフォルトの名無しさん
12/02/18 12:42:03.95
其れは方法が多い
901:デフォルトの名無しさん
12/02/18 12:43:44.32
Here is the battle stage.
Let's fight!
902:デフォルトの名無しさん
12/02/18 14:00:14.38
>>900
903:デフォルトの名無しさん
12/02/18 14:35:27.58
theじゃなくてaだろ
904:デフォルトの名無しさん
12/02/18 14:56:45.22
Pythonは見やすさ重視してるかなと思うけど、RubyとPerlは大差ない。
905:デフォルトの名無しさん
12/02/18 17:20:21.02
>>897
Pythonも別に型検査などが言語機能としてあるわけではなく
単にデコレータを使えばそういうことに「も」書く側で対応できるってだけじゃん
そういうデコレータの汎用性はいいと思うけど、直接実装するのと比べるとやっぱりね
どこまでをどの程度の抽象度で表現できるようにするかってのは、難しいけども
906:デフォルトの名無しさん
12/02/18 17:22:36.12
何この低レベルな争い、、、
907:デフォルトの名無しさん
12/02/18 17:36:17.90
javaのクラスライブラリが使えるだろうjruby一択だろjk
pythonなんて、vbみたいに文法がシンプルな割には、
classに毎度毎度、selfと書かなければならないperl臭さがあってダメポ
実際問題、ハッカーの書いたスクリプト言語に、どれほどの信頼性があるのよ？って怖さがある
シンプルな言語でなければ、言語開発者たちが解析木なり構文木なり、
明文化されてないのを良いことに、バグ放ったらかしてそう
だから使うなら、シンプルなscheme系統が良いけれども
clojure/clojure scriptなんかは開発陣がなんかキモい
そんな理由でjavascriptとluaが大勝利
908:デフォルトの名無しさん
12/02/18 17:42:15.36
変な理屈だなあ
909:897
12/02/18 18:15:13.12
>>905
失礼、説明が足りなかった
自分がうらやましかったのは、f(x:int, y:int) -> int という型式風の関数アノテーション構文
で、それをデコレータと組み合わせると型検査/検証を簡潔に書けてイイ！と
（ただし、デコレータは一種のマクロだから「Rubyとは」相性が悪いように思う）
910:デフォルトの名無しさん
12/02/18 18:20:13.58
rhinoが流行らなかったのは、javaのクラスライブラリとjsの相性が悪すぎたせい
rubyの方がpythonよりも言語の機能が豊富だしOOPとしては優れているのは誰の目にも一目瞭然
perlはもう…（笑）これから、4、5年ぐらいはjsが、かつてのperlと同じポストに着く。
廃れるときも、perlと同じ扱い。
javaは文法というか、色々と冗長すぎるので、
kotlinなりceylonなりポストjavaにjvmのメインストリームを奪われる。というか奪われろ。
関数型は大手ITの社内アプリなんかで徐々に使われだし、
ある程度の方法論とノウハウが蓄積後に業務アプリの開発で主流になる。
911:897
12/02/18 18:35:54.36
>>907
全体としてはいくつか異論があるけれど、
>pythonなんて、vbみたいに文法がシンプルな割には、
>classに毎度毎度、selfと書かなければならないperl臭さがあってダメポ
ここだけは同意
912:デフォルトの名無しさん
12/02/18 19:03:47.00
>>911
selfは慣れる。railsずっとやってたおれが保証する。よく忘れるけど。
それより、Pythonは親クラスのメソッド呼び出しがださすぎる。
super(ClassName, self).method() だっけ？最初見たときバカかと思った。
で、そんなはずはないと思ってもう一回みたら、やっぱりバカばかしかった。
はっきりいってPythonのsuperはPHP以下。Pythonでオブジェクト指向したくなくなる。
あとDjangoがいつまでたっても3に対応しない。Railsは早々に1.9に対応済というのに。クソったれ。
913:デフォルトの名無しさん
12/02/18 19:08:24.43
Perl は5.8辺りで上手く枯れて来たなーと思ったところに色々突っ込んじゃった印象
まあ路線的には専門外だったWebから脱却して
ポストawkというかシェルのお供みたいな位置で落ち着きそうだなと思う
914:897
12/02/18 19:10:31.61
(>>898の続きになる)
>>825はお題であるから>>898のコードが適切だと思うけど、
実際の開発で型検査/検証が必要であれば(>>716で簡単に紹介した)表明メソッドを使う
require 'tmdoc/tmstd'
ASSERT = TmStd::Assertion
def f(x, y)
ASSERT.kind_of x, Integer
ASSERT.kind_of y, Integer
z = x + y
ASSERT.kind_of z, Integer
end
def g(x)
ASSERT.assert -1 < x && x < 1
print x
nil
end
メソッド Assertion.kind_of(およびassert)のコード定義については、以下を参照
URLﾘﾝｸ(www.h6.dion.ne.jp)
(続く)
915:デフォルトの名無しさん
12/02/18 19:11:56.46
>>912
まじPython2のsuperはアホ全開だよな
Python3だとsuper().method()だからマシだけど
916:デフォルトの名無しさん
12/02/18 19:12:20.27
>>912
Pythonは多重継承あるから、勝手に継承元決められるより
親クラス明記のが楽かも…まあ、それでも色々くっ付き過ぎだけどw
917:897
12/02/18 19:14:18.80
(>>913の続き)
実行結果は以下のようになる(等幅フォントを使わないとボックスは奇麗に表示されない)
irb(main):006:0> f("Hoge", 1)
+=== ASSERTION FAIL!! : A is a kind of E. ====
|[EXPECTED(E) TYPE]
| Integer
|-----------------------------------------------------
|[ACTUAL(A) TYPE]
| String
|[ACTUAL(A) VALUE]
| Hoge
+=====================================================
TmStd::Exception::AssertionFail: TmStd::Exception::AssertionFail
from /opt/local/lib/ruby/site_ruby/1.8/tmdoc/tmstd/assertion.rb:55:in `kind_of'
from (irb):4:in `f'
from (irb):6
from :0
918:デフォルトの名無しさん
12/02/18 19:19:45.30
>>916
> Pythonは多重継承あるから、勝手に継承元決められるより
> 親クラス明記のが楽かも
ダウト
Python2でのsuperは親クラスじゃなくて自クラスを指定する
信者乙
＃いやこの程度を間違えるなら信者ではないかも？
919:デフォルトの名無しさん
12/02/18 19:22:06.73
>>916
親クラスを指定するんじゃないんだよ。それなら百歩譲って理解できる
そうじゃなくて自身のクラスを書かなきゃダメなわけ。例えばこんな感じで
class C(B):
def meth(self, arg):
super(C, self).meth(arg)
全く意味不明だろ？w
Pythonユーザの俺でも擁護できんわwww
(なお、Pythonのメソッド呼び出し obj.meth() は C.meth(obj) と等しいので
親クラスを選んで呼ぶのは普通に出来る）
920:デフォルトの名無しさん
12/02/18 19:31:45.45
>>918-919
Ω＜ナ、ナンダッテー
いや普段使わない言語に俄か知識でテケトーな事言ってスマンカッタ
921:デフォルトの名無しさん
12/02/18 19:36:15.72
python使っててそういうコードに出くわした記憶がない
922:デフォルトの名無しさん
12/02/18 19:37:10.33
>>912
>PythonのsuperはPHP以下
そんなこというと、Python信者が暴れるだろうが―！
URLﾘﾝｸ(twitter.com)
> Pythonだと、プログラムを綺麗にしようとするモチベーションが働くけど、
> perlやphpではそういったモチベーションが働きにくくてやっつけコードに
> なるのは、俺の個人的な問題なのか、ある程度言語自体が抱えている問題なのか？
URLﾘﾝｸ(twitter.com)
> php使うとcometとかWebSocketとか対応が難しいし、HandlerSocketの性能も引き出せないし、
> Fluentのphpクライアントも他の言語で普通にできているバッファリングが普通には出来なくて
> 苦労してるらしいし、
923:デフォルトの名無しさん
12/02/18 19:38:52.74
URLﾘﾝｸ(twitter.com)
> 「新しい技術に挑戦する」ことを奨励する企業がphpばかり使ってるのは問題だよね。
Python信者の発言こそ問題だけどな。
924:デフォルトの名無しさん
12/02/18 19:47:15.28
大昔にもツイッターのコピペばかりしてる奴がいたけど復活したのか
925:デフォルトの名無しさん
12/02/18 20:56:41.67
>>915はアンチPythonのふりをしたPython信者
自演キモ
926:デフォルトの名無しさん
12/02/18 21:30:44.44
>>909
> （ただし、デコレータは一種のマクロだから「Rubyとは」相性が悪いように思う）
デコレータはただの高階関数（に対する構文糖）
Rubyと相性が悪いとすれば、それは高階関数と相性悪いってこと
927:デフォルトの名無しさん
12/02/18 22:59:25.08
>>905
もっともなご意見有り難う。そんな事言いだしたら、PerlだってMooseで型制約出来るもんな。切りがない。
928:デフォルトの名無しさん
12/02/19 00:18:28.13
URLﾘﾝｸ(twitter.com)
> 社内でPythonをメインで使っていくぞーって吠えてphpをdisったりしてるの、
> 単にガキが暴れてるだけに見えるかもしれませんが、もともと僕自身が
> 引っ込み思案なので自分を追い詰めるために虚勢を張っているのです。
> 察してください。
ワラタｗ
Python信者が言い訳しとるｗｗ
929:Python信者
12/02/19 00:49:15.04
>>918
馬鹿は黙ってろ
>>912
どうしてもPython2でその書き方が嫌なら
super(ClassName, self).method()
の代わりに
SuperClassName.method()
でもいい
さらに
どうせインスタンス作った後はsuper変えることなんてなさそうだから
__init__の中で
__super=super(ClassName, self)
とした上で
__super.method()
って書いても良い
何でobjectクラスの中でそれが定義されてないのかって突っ込むなら
Railsのまねで
object.__super=
930:デフォルトの名無しさん
12/02/19 08:01:58.01
>>929
objectに属性追加出来ないだろ
本当にPython信者か？
931:デフォルトの名無しさん
12/02/19 08:15:29.58
>>929
>どうしてもPython2でその書き方が嫌なら
>super(ClassName, self).method()
>の代わりに
>SuperClassName.method()
>でもいい
ださいことには変わりないけどな
>さらに
>どうせインスタンス作った後はsuper変えることなんてなさそうだから
>__init__の中で
>__super=super(ClassName, self)
>とした上で
>__super.method()
>って書いても良い
素人考えだな
それは継承を2段階行ったら破綻するやり方
932:デフォルトの名無しさん
12/02/19 08:29:06.48
Pythonはこんなにダサいのに
いざコードを書かせるとRubyが圧倒的にダサいのは何故だろう？
933:デフォルトの名無しさん
12/02/19 08:35:15.15
>>932
信者だから
934:デフォルトの名無しさん
12/02/19 09:07:08.15
>>932
まったくの主観で笑えるｗ
Python信者がんばれ！
935:デフォルトの名無しさん
12/02/19 09:11:41.50
>>928
>> 社内でPythonをメインで使っていくぞーって吠えてphpをdisったりしてるの、
disってるという自覚はあるのね
信者って、そういう自覚がないままに行動してると思ってた。
>>929
>super(ClassName, self).method()
>の代わりに
>SuperClassName.method()
SuperClassName.method(self) の間違いだろ
信者がそんなミスするなよな
936:デフォルトの名無しさん
12/02/19 09:29:05.87
>>934
Ruby信者には>>898>>914がダサくないの？
937:デフォルトの名無しさん
12/02/19 09:34:49.37
>SuperClassName.method(self) の間違いだろ
>信者がそんなミスするなよな
それはもちろん気付いてたが
単に()をmethodを代表するものとして付けただけだから
938:デフォルトの名無しさん
12/02/19 10:49:38.33
>>937
苦しーｗ
そんな小さなミスすら、認めようとしないのか
こんな便所の落書きですら自分の体面を保とうとしているとは恐れ入った
939:デフォルトの名無しさん
12/02/19 10:50:09.44
>>926
もしもPythonが高階関数との相性が良いのなら、
高階関数の合成演算(の構文糖)であるメソッドチェーンを
何の不自由も無く使えているはず
でも、現実にはPythonでのメソッドチェーンは使い物にならないから
(あるいは用途が極めて限定されてしまうから)、
「Pythonは高階関数との相性が悪い」とも言えてしまう
だから、>>909では、デコレータがRubyと相性が良くない理由を、
「デコレータが(構文糖である)マクロであるため」と書いている
分かるかな？
940:デフォルトの名無しさん
12/02/19 11:33:07.96
>>939
その主張は「Rubyが高階関数と相性が悪い」の反論になってない
あとデコレータはLipsマクロほど強力じゃない。所詮はただの高階関数
941:デフォルトの名無しさん
12/02/19 11:35:26.31
＞＞936
Rubyもださいね。Pythonのsuperと同じくらいださい。
942:デフォルトの名無しさん
12/02/19 11:38:29.73
>>940
反論になっていないのなら、その理由をkwsk
理由なき主張は、単なる主観だ
943:デフォルトの名無しさん
12/02/19 11:39:59.95
>>942
なんで高階関数に過ぎないデコレータがRubyと相性が悪いの？
もう何度も繰り返してるけどデコレータは高階関数だよ？
「マクロだから」的な反論は間違いだからね
944:デフォルトの名無しさん
12/02/19 11:47:42.48
間違っているのはあなたです。
デコレータのメカニズムは高階関数ですけど、@ほげほげ、という記法は構文糖です。
この構文糖があるからこその「デコレータ」であって、この構文糖がなければ、
デコレータでもなんでもないただの高階関数です。
945:デフォルトの名無しさん
12/02/19 11:49:43.28
お前ん中ではな
946:デフォルトの名無しさん
12/02/19 11:50:08.52
>>944
じゃあ「ただの高階関数」なら使えるってことだよね？
だったら高階関数を使って>>914みたいなダサいコードを
もっと洗練させてよ
直視に耐えないレベルでダサいから
947:デフォルトの名無しさん
12/02/19 11:52:07.09
自分が理解出来ない ＝ ダサい
948:デフォルトの名無しさん
12/02/19 11:57:15.37
>>943
単なる高階関数に過ぎないデコレータ的な機能は、
(Pythonと違って)高階関数との相性が良いRubyであれば
ユーザコードで書ける
(たとえそれが>>898>>914のようにダサいとしても....)
でも、(構文糖である)デコレータ構文そのものの導入は、
ただでさえ複雑なRubyの構文を一層複雑にさせるから、
採用される見込みはないだろうな、という話
関数アノテーションについては、(たとえ構文の追加が必要であっても)、
ぜひとも導入を検討してもらいたいと個人的には思っているけどね
949:デフォルトの名無しさん
12/02/19 11:58:20.06
>>944
Pythonを知らなくてデコレータをマクロだと思ってたんだろ？
指摘されてから「高階関数だって知ってたし」とか笑えるw
じゃあもう一回聞くけど、何故Rubyとデコレータの相性が悪いんだ？
まさか「構文糖だから」か？
950:デフォルトの名無しさん
12/02/19 11:58:53.21
まあ、そもそものRubyの構文がわるいんだろうな。
行き当たりばったりで作ったから、
新しい機能を入れる余地がない。
あー、また互換性切り捨てか。
951:デフォルトの名無しさん
12/02/19 12:02:22.50
>>949
>>948を嫁
952:デフォルトの名無しさん
12/02/19 12:03:36.94
>>950
>行き当たりばったりで作ったから、
そのとおり、Pythonの関数型プログラミング機能と同様に、
行き当たりばったりだね
953:デフォルトの名無しさん
12/02/19 12:08:54.56
>>950
> 行き当たりばったり
> 互換性切り捨て
新旧スタイルクラスに3.0と、Pythonも大概だと思うが…
954:デフォルトの名無しさん
12/02/19 12:33:10.84
950は、よりよい言語にするためだったら互換性は切り捨ててもいいという、
最近のLL系言語に蔓延している風潮それ自体を批判しているんだよ
冒頭のRubyは飾りです、デコレータだけに
955:デフォルトの名無しさん
12/02/19 12:34:34.04
>>928
>URLﾘﾝｸ(twitter.com)
>> 社内でPythonをメインで使っていくぞーって吠えてphpをdisったりしてるの、
>> 単にガキが暴れてるだけに見えるかもしれませんが、もともと僕自身が
>> 引っ込み思案なので自分を追い詰めるために虚勢を張っているのです。
>> 察してください。
さんざん他の悪口を言っておいて、謝りもせず、なにが「察してください」だよ。
自分を追いつめるためなら何を言ってもいいと思ってんのか？
Python信者クズだな。
956:デフォルトの名無しさん
12/02/19 12:35:22.33
pythonのデコレータ自体は高階関数だけど、
@なにがし、はデコレータで関数を置き換える別の機能だと思うけど、、、
957:デフォルトの名無しさん
12/02/19 12:42:37.21
>>955
このスレのPython信者と一緒だね
958:デフォルトの名無しさん
12/02/19 12:46:02.17
>>954
最後のオチ、ワロスw
959:デフォルトの名無しさん
12/02/19 12:47:35.87
>>956
シンタックスシュガーだね
960:デフォルトの名無しさん
12/02/19 13:16:12.46
デコレーションケーキ
961:デフォルトの名無しさん
12/02/19 14:07:40.29
構文論と意味論がごっちゃになるバカとか、このスレにふさわしい隔離対象じゃあないか
962:デフォルトの名無しさん
12/02/19 14:08:29.48
LL ではない重量級の言語は何メインで使ってる？
LL だけって人もいるかもしれないけど、大抵は重量級と LL の両方使うでしょ。
組み合わせに傾向が出たりしないかな？
自分は C と Python です。
963:デフォルトの名無しさん
12/02/19 14:21:02.32
>>961
暴れているガキのことか？
うーん、いくらここが隔離スレだとしても勘弁して欲しい
ガキのお守りは疲れるから
964:デフォルトの名無しさん
12/02/19 14:24:47.80
>>962
漏れは C と Ruby
ただしどちらの言語ともプラットフォームは UNIX(Mac or Linux) だけど
965:デフォルトの名無しさん
12/02/19 16:10:41.76
「LL ではない重量級の言語」ってのがよくわからんけど、
Rubyや、Perlっぽい言語以外、という分類なら、CとかHaskellとか。
Haskellは慣れからくる惰性で使ってるだけだから、OCamlないし
遅延評価が必要ならもっと別の何かでも構わないと思う。
966:デフォルトの名無しさん
12/02/19 18:11:06.40
>>948
仮に@なにがしの構文糖が使えないとしても、>>825のコードは殆ど冗長にならない
def f(x:int, y:int) -> int:
return x + y
f = typecheck(f)
def g(x):
print(x)
g = validate(x=lambda x: -1 < x < 1)(g)
高階関数と相性の良いRubyなら>>914はもっと簡潔に書けるでしょ
ASSERT.kind_of を毎回書くんじゃなくて別のメソッドに隠蔽すべき
967:デフォルトの名無しさん
12/02/19 20:45:16.47
Rubyのメソッドは一級市民じゃないので高階関数とは相性悪いです
デコレータをRubyでやるなら動的なメソッドの再定義になりますね
元のメソッドを別名にしてそれをラッピングしたメソッドを同名で再定義します
def foo(x,y) x+y end
type_assersion(:foo, Integer, Integer)
見たいなのは実現可能です
順序を逆にして
直後に定義されるメソッドに対するデコレータみたいなのも書けなくはありません
type_assersion(Integer, Integer)
def foo(x,y) x+y end
ググって見つけたところだと
type_assersion(Integer, Integer) do
def foo(x,y) x+y end
def bar(x,y) x-y end
def baz(x,y) x*y end
end
って感じのがありました、これはRubyっぽい気がします
わざわざ型をチェックしたりする必要性はよくわかりませんね
そんなのは仕様とテストに書いてあれば十分な気がするので
968:デフォルトの名無しさん
12/02/19 21:28:50.10
>>964
unix環境でcを使うなら当然ながらgdbは必須なので、
gdbの拡張用スクリプトに公式的に選ばれたpythonつかっといた方が
幸せになれるんじゃなイカ？
個人的な考えでは、gdbの拡張用スクリプトは、luaかguileにすべきだった。
インデントが構文の言語は、対話環境でイジるの面倒杉だし、OOPとしてのpythonは失敗策。
あれなら、まだperlを採用した方がマシ
s-expなんてemacsがあってはじめて幸せになれるようなもんで、
インタラクティブな操作に向くとは到底ながら思えないけれど、
デバッガにはgnu公式のスクリプトを採用した方が組織としての一貫性があった。
ソフトウェアに永遠の命をなどとスローガンを掲げているわりに連中は自らその道を外れた。
ここのところ話題に挙がらない後発のgroovyって流行ってんのかな？
mozillaのrustといい、perlのようなものから
rubyのようなものを生み出した功績は素晴らしいと思う
969:デフォルトの名無しさん
12/02/19 21:44:06.10
>>968
元UNIX系だがgdbなんてほとんど使ったことのないオレが通りますよ。
（カーネル空間なんでgdbはパニックダンプ解析でしか使えないし・・・。）
関わって多言語は、
C(コーディング)、Sparcアセンブラ（デバック時）、Forth(レビュー対象)。
今はPerl、PHP、Javascript、Java、ActionScript、VBA、SQL、色々やってますが、PythonとRubyは未経験でつ。
970:デフォルトの名無しさん
12/02/20 00:04:01.82
Klabっていつの間にかソーシャルゲーム屋になってたんだな。