> COBOL syntax has often been criticized for its verbosity. However, proponents note that this was intentional in the language design because it made the code self-documenting, easing program maintenance.[132] COBOL was intended to be easier for programmers to learn and use,[133] but while being readable to non-technical staff such as managers (despite there being no evidence it would be useful).[134][135][136][137]
それでも銀の弾丸ではない (スコア:3, 興味深い)
静的型付けがあると機械的に検証しやすいのでバグ削減効果があるのはわかるが、それも程度問題じゃないかな?
文法的にも記述的にもなんの問題もないが、その動作では都合が悪いという仕様バグの方がよほど大きな問題であるケースが多数派だと思うのです。
:wq
Re:それでも銀の弾丸ではない (スコア:2, 興味深い)
静的型付けな言語の方がIDEのサポートが強力に作用するってのもある。
Rubyなんかは実行上は型安全だけどIDEがサポートしやすい型安全性が全力で否定されてるのでだいぶキツい。
Re: (スコア:0)
rubyでプログラム組んでるけど、rubyで開発するのは正直地獄だと思う
・実行してみたら、メソッドがないと言われて落ちる
・ある機能を実装→うまくいかない→あるメソッドで渡す型がメソッドの期待するものと違っていた
なんてことが良く起こるし…
ruby推進派に言わせればテスト書けというけど、テスト書くのって面倒なんですよ
(中にはテスト書けないやつもあるし)
Re:それでも銀の弾丸ではない (スコア:3, すばらしい洞察)
Ruby固有の話は特にないようなので、あなたの会社ではPHPもPythonもダメですね。
Re: (スコア:0)
テスト書かないで、そこそこの規模の物を作るの?
正直、信じられんな。
テストないと、デバッグしてるつもりがバグ入れに、
てなっちゃうじゃん。
Re: (スコア:0)
Re: (スコア:0)
テストは書いてるけど、正直言って面倒です
静的言語なら必要ない部分まで書かないといけないので…
Re: (スコア:0)
> テストないと、デバッグしてるつもりがバグ入れに、
の意味がわかってないのか...
あとで作業が増えて結局はるかに面倒になるよってことなのに。
Re: (スコア:0)
世にはテストコード否定するところがあるんですよ。。
しょぼいバグが多いわ見ただけでエラーになるパターンあるわ。
で、言うと切れる、おまえがおかしいと人格攻撃もセットなのが特徴ですね。
ユニットテスト見せたら、あんな奴いらんと会社に言われて切られるというオチも一度。
Re: (スコア:0)
それrubyじゃなくダックタイプ系言語共通の話だよね。
てかテスト書くの面倒って……釣りだよね?
釣りじゃなきゃ、一刻も早くIT業界からドロップアウトすべきだ。
その方が本人にもその会社にも社会全般にもいい。
Re: (スコア:0)
書ける部分はもちろん書いてますし、書かないでリファクタリングなんて恐ろしくてできないんですが…
実物がないとテストができないやつとかあるんですよ
設計が悪いと言われればそれまでですが
Re: (スコア:0)
上の人とは別人ですが。
ある程度の規模ならテストを書いたほうがいいのは当然ですが、書いたところで
>実行してみたら、メソッドがないと言われて落ちる
>ある機能を実装→うまくいかない→あるメソッドで渡す型がメソッドの期待するものと違っていた
というのはあまり有効に排除できませんからねぇ。
テストケース自動生成とかがもっと発達すればどうなるか分かりませんが、そういうのは静的型付けのお家芸ですし。
結局コード内にドキュメントとして型を書くとか、関数の入り口で型チェックするとかいう話になって、
それなら静的型付けでいいんじゃないかということに・・・
個人的にRubyはPythonなどに比べて特に動的型付けの暗黒面が強い印象がありますが、なんででしょうね。
DSLみたいなアクロバティックな部分が多いからでしょうか。
# javascriptはほとんど触ったことないですがあれも大変そう
Re: (スコア:0)
わたしは Python より Ruby のブロックの方に魅力感じますけどねぇ。
Python、書き方よく分からんというのもあるけど。
配列に突っ込むときの型チェックというけど、
動的言語のチェックは、静的言語における型チェックとは違いますよねぇ。
メソッドのあるかなしかのチェックで、型チェックじゃない。
すると、配列に適応する処理の抽出の仕方が、
そもそも動的言語と静的言語とはまったく違う。
同じメソッドがあり、その結果が期待通りでさえあれば、型は違っていていい。
それと相まって、ブロックでの処理ぶん回しって、なかなか魅力あると思うんですけど。
まあ、用もないところでの黒魔術は止めてくれというのは、同意します。
テストは、致命的バグ仕込まない程度の要所要所でいいのでは?
足りない分は、リファクタするとき、慌てて追加www
Re:それでも銀の弾丸ではない (スコア:1)
VBが一番理想的だなと思った
Val型なら動的言語として振る舞い、必要なら型を指定できるという
Re:それでも銀の弾丸ではない (スコア:1)
>スクリプト言語でも、オブジェクト拡張時には性的だとか
拡張時には性的……(ゴクリ)
Re: (スコア:0)
それそのもの(メソッドがあるか自体)のテストはないなど、あきらかに不要なチェックはしないし、昔の単純なコンパイラよりも効率的にテストに織り込まれていくし、すぐに動かしたければコンパイルなしで動き出す。
ただ最近の型推論を備えてきている言語のコンパイラは優秀なので、そんなのコンパイルすりゃわかるじゃんという場面も多いよね。
Re: (スコア:0)
>ruby推進派に言わせればテスト書けというけど、テスト書くのって面倒なんですよ
面倒じゃないやり方もある。
勉強しましょう。
>(中にはテスト書けないやつもあるし)
自動テストの普及前はともかく、
現在ではテストのかけない設計は悪い設計です。
勉強しましょう。
勉強しないで新しいやり方をやると地獄なのは、
Rubyに限らず当たり前ですね。
Re: (スコア:0)
Rubyは過大な勉強を強いるプログラミング言語ってことですね。
もっと楽な他の言語を使います。
Re: (スコア:0)
ヤメテ!
これいじょうPHPの評判を下げるのはやめて!
Re: (スコア:0)
> ある機能を実装→うまくいかない→あるメソッドで渡す型がメソッドの期待するものと違っていた
これは文法エラーと同じレベルのもので、そもそもプログラムとして動かないでしょうから、
commitされることはほとんど無いでしょうし、今回のような評価の場合には、問題としては出てこないでしょうね。
コードを書くのがどれだけ楽かというもっと人間寄りの評価をすれば、この辺りは問題になってくるかも知れませんが。
>commitされることはほとんど無いでしょう (スコア:0)
お前は、プログラマーを、特にPHPerという人種をなめている。
「gitの最新ソースで、型が違うってエラーが出たんだけど」
「eclipseで構文エラーは出ていないので、動くと思ってコミットした。通すの面倒だから動作確認はしていないしテストは面倒なので書いていない(キリッ」
なんてざらですよ。これ一つとっても、コンパイルのある静的型付け言語の方が優れていると感じます。
# そこまで酷くなくても、PHPとかはそもそも変数の型が状況によって変わることがありえてしまうので、このパターンは通ったけど別パターンだと型エラー、みたいなソースが書けてしまうのですよね…
Re: (スコア:0)
やっぱWindows最強だな。
Linuxって動的言語で開発ばっかしてんでしょ?
大体IDEっていってもまともなIDEなんてVisualStudio(.Net)だけなんだよな。
Eclipseとかわざわざ立ち上げるくらいならエディタのがいいってのはわかるもん。
Re:それでも銀の弾丸ではない (スコア:1)
> 大体IDEっていってもまともなIDEなんてVisualStudio(.Net)だけなんだよな。
いやいやそんなことはないですよ!
ソフトもハードも糞しか作れないキングオブ糞企業ことIBM
(DTLAシリーズというHDDカッコンカッコンの悪夢を世界中に振りまき、
DB2とかRationalなどのゴミみたいなソフトウェアを作りつつ、
昨今はhpやDELLよりべらぼうに高いクセにメンテ性がゴミレベルだったx86サーバ事業を支那畜に売り払った)
クソ企業ことIBMが生み出した、プログラマを不幸にするサイバー兵器ことEclipseが最低最悪すぎてそういう印象を与えているだけであって、
JetBrainsのIntelliJ IDEA UltimateなんかはVisual Studioと同等かそれ以上のIDEですよ。
Re: (スコア:0)
eclipseと比べないと褒められないIDEだということはよくわかりました
それにしてもちょっとひどい言いぐさですね
Re:それでも銀の弾丸ではない (スコア:1)
まあ、Eclipseは実際ひどいから。
プロジェクト空で作り直すしかない。でも数回ビルドするとまた壊れて、、、みたいな。
メタデータが不整合起こしてるように思うけど、特定できなくてめげた。
VSだとインポートし直しで直らないケースに遭遇したことありませんし。
壊れるのは仕方ないが、修復に手間がかかりすぎ。
Re: (スコア:0)
> プログラマを不幸にするサイバー兵器ことEclipseが最低最悪すぎてそういう印象を与えているだけであって、
EclipseってそもそもJava/Sunのイメージをおとしめるような悪意のこもった名前ですし、実際、そういう意図があったかも知れませんね:(
Re: (スコア:0)
LinuxはCで書かれているがその点
Re: (スコア:0)
それは原論文の分類では「強い型付け」ではなく「静的な型チェック」
Re:それでも銀の弾丸ではない (スコア:2)
動的型付けには、ある型を関数に渡せるかが、関数の実装に依存してしまう問題がある。
add(x,y)という関数に、文字列を引数として渡せるかは宣言からでは判断できないし、add(x,y)の実装が変更されれば、ある日突然エラーになる。
add(int x,int y)なら、関数の実装者は、整数型以外考慮しなくて済むし、呼び出す側は実装を見なくても関数が扱える型がわかる。
結局存在しないメソッドが呼び出せない以上、動的型付けでも見えなくなるだけで型には制約される。型の前提なしでコードは書けない。
関数が要求するメソッドを指定する方法はあったほうがいい。Goのinterface [golang.jp]や、ポシャったC++のconcept [wikipedia.org]とかね、
Re: (スコア:0)
型推論で、大抵、片がつきませんか?
Re: (スコア:0)
型がつきます。
Re: (スコア:0)
自分は最近PHPしか書かないので他の言語のことは不案内だけど、
typehintingくらい(みんなが嫌いな)PHPにだってあるよ。
今風の言語はそのくらいのことできて当たり前だとおもってたんだけど、違うの?
Re: (スコア:0)
Rubyはそういうのない
Re: (スコア:0)
ありゃ型という概念に全力で喧嘩を売ってるからな
流れ弾を食らいたくなければ全力でテストコードを書き続けなければならないマゾ用言語やで
Re: (スコア:0)
そういう有能なプログラマばかりならそうでしょうけど、
「何とかのリスト型」の変数に「何とか型」を強引に代入する、
みたいなことをするプログラマは実在するんですよ。
Re:それでも銀の弾丸ではない (スコア:2)
それで正常動作する処理系が存在しそうな予感。
Re: (スコア:0)
実在するかどうかが問題になるくらい有能ではないプログラマーには、
もうちょっと有能になってもらえばいい。
そのプログラマーが成長しないことを前提に、
言語の機能を決めることに、
何の意味があるだろうか?
有能ではないプログラマーだけを集めて仕事をしなくてはならないことはあるだろうが、
それを一般論として語るべきではない。
Re:それでも銀の弾丸ではない (スコア:1)
有能ではないプログラマが大勢いる現場(穏当な表現)で働いたことがありますが、自主的に辞めてくれないかなレベルのメンバのフォローに費やされた時間を考えると、一般論どころか前提にしないといけない気がしないでもないです。
なので、バグ回避を支援してくれる機能はどのレベルでも望ましい気がしますが、だからといって、すべてのプログラマがその代償を払う必要はないようにも思うのです。
でもって、次世代 ECMAScript の Optional な型指定はイケてるなあと思っています。
Re: (スコア:0)
>有能ではないプログラマが大勢いる現場(穏当な表現)で働いたことがありますが、自主的に辞めてくれないかなレベルのメンバのフォローに費やされた時間を考えると、一般論どころか前提にしないといけない気がしないでもないです。
そういう職場があることは事実ですし、
そういう職場が多いことも事実かもしれません。
でも一般論で語るにはたりない。
少なくとも言語によるコード品質とか言う話題を語るときには、
特殊例として扱うべきでしょう。
Re: (スコア:0)
これはこれで極論っぽいなぁ。
言わんとすることも分からなくはないけど、
成長しない and 有能ではない プログラマーなんて、山のように居る。
人の成長ばかりに期待するんだったら、
言語なんてアセンブラ言語で止まっちゃって進化しなくても良かったでしょ。
って言えちゃうような気がする。
Re: (スコア:0)
ゴロタン、関係ありそうでない話をするのが好きだぜ
FORTRANは算術IF文みたいなのもありまして、そもそもこれ以前にまともな言語がないわけですから、プログラマは全員アセンブラに通じていてコンパイラがどういうコードを吐くのか熟知していたのだぜ
COBOLはプログラマが社会的な信用のない時代に、上司がプログラムをなんとか理解して不正を見抜けるようにするというのが目標だぜ
Re: (スコア:0)
> COBOLはプログラマが社会的な信用のない時代に、上司がプログラムをなんとか理解して不正を見抜けるようにするというのが目標だぜ
この説は初めて見ました。よろしければ情報元を教えてください。
COBOL のおばちゃまこと Grace Hopper 海軍准将が FLOW-MATIC を経て CODASYL に関わっていったのは「機械語ではなく、英語に近い言語によってプログラミングできるようになるべきである」という彼女の理想があったからというのは諸文献で見ることができます。
コンピュータそのものの黎明期で、大勢の優秀なスタッフが協力してようやく動かすような時代に、不正を恐れる上司という概念はかなり斬新だと思います。
おばちゃまになにがあったんでしょうか??
# そもそも専従プログラマなんて当時はいなかったような。
Re: (スコア:0)
ウィキペディアのCOBOLの項目に
> COBOL syntax has often been criticized for its verbosity. However, proponents note that this was intentional in the language design because it made the code self-documenting, easing program maintenance.[132] COBOL was intended to be easier for programmers to learn and use,[133] but while being readable to non-technical staff such as managers (despite there being no evidence it would be useful).[134][135][136][137]
マネージャーがコードを読めるようにしたとあります
役に立ったというエビ
Re: (スコア:0)
そこは「マネージャのような非技術スタッフにも読めるように」ですね。
広く使ってもらうためには高度な訓練を必要としないように自然言語に近い表現がよいという方針だったという話ではないでしょうか。
最初のターゲットの UNIVAC は 47台出荷だそうですから、ポンコツエンジニアをあてがうようなもったいないことをされたとは思えないのですが。
Re: (スコア:0)
しかしグレース・ホッパーはMATH-MATICも開発してたので
Re: (スコア:0)
残念だが、有能ではないプログラマーは成長しない。
現在、プログラムは複雑化してプロジェクトは大きくなっているが、発注の単位は小さくなっている。
100人を超えるプロジェクトでも、いろんな会社から2,3人づつ寄せ集めでできたプロジェクトというのはそんなに珍しくない。
そうした方がコストが安く上がるから。
ごく一般的に開発現場で見られる光景だよ。
#そして、30歳定年説とか言われてドロップアウトしていく。
Re: (スコア:0)
前者で浮いた時間と労力を、後者に回せるのが大きいんじゃないかな?
もしくは、前者が不良摘出件数として上がってこない分、後者で稼ぐしかないとか・・・
Re: (スコア:0)
無名関数、お前だけは絶許
Re: (スコア:0)
このストーリーで関数型言語を否定する人は他に誰もいないんだが、
つまりアナタは落ちこぼれってことでおk?
Re: (スコア:0)
誰でも思うこと、というのは モデル化して数値化して評価してナンボのものです。思うだけなら 誰でもできるので。
というわけで、あなたの言うことが正しいとして、
仕様バグをモデル化するにはどうしたらいいでしょうね。
顧客や利用者に電極つけて、
使っているうちに モチベーションが下がって行ったり、
怒りで血圧が上がって行ったり
するのを観測して数値化しますかね。
その数値を会社ごとに測定して公開したら、ダメSEの含有率の多い会社を回避できるようになるんですかね。