アカウント名:
パスワード:
この提案の最も非現実的な点は, 何十年に渡ってメンテナンス出来る人材を確保・維持することが事実上不可能なことを無視していることです.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
思いっきり素人がなんですが… (スコア:3, すばらしい洞察)
しっかりとした分業体制や継続開発・後々のメンテが出来る体制さえ出来ているならば、使う言語は使い慣れたもので良いやとか、いざとなったら別の言語に乗り換えてしまえと
-+- 想像力を超え「創造力」をも凌駕する、それが『妄想力』!! -+-
Re:思いっきり素人がなんですが… (スコア:1)
> なるような気がします。
私もここがポイントなんだと思います。で一つ問題提起させていただきたい。
大きな企業の場合は大抵信用を重んじるので、既に実績のあるもの、90年代に実績がある Perl, PHP を選択すると思います。そして猛烈な資金を投じて(リファクタリングもさせない、堅いプロセスで)使い捨てプログラムを書かせます。数ヶ月で状況変わるからそ、のたびにプログラムも一から書き直させればよいということなのでしょう。
しかし「メンテナンス費用はかかる。寿命は数ヶ月。そんなものに投資していていいのか」と問いたい。大企業ならともかく、中小は100%ムリ。
だから、中小にははシステムの資産と負債の違いを知って、資産にだけ投資していただきたい。で、その観点から技術基盤の選択をすると、PHP や Perl では綺麗なコードは書きづらいので(負債をせっせと作ってしまう)、永続的なメンテナンスがしやすい Python か Ruby を選択してほしい。そして、何十年にわたって使える資産、リファクタリングされたメンテナンスしやすいコードを書くのがよいでしょう。
Re:思いっきり素人がなんですが… (スコア:2, 参考になる)
Perlはたしかにいろんな書き方ができるし省略記法が多すぎるので
綺麗なコードにはなりにくいですが、PHPはそんなことないのでは?
どちらかというと、PHPの問題は(ほかのコメントにもありますが)
HTMLとロジックとをごちゃごちゃにしてしまいがちという点でしょう。
でもまあ、いちばん綺麗なコードが書けるのはRubyでしょうね。
Javaも綺麗なコードが書けるし汚いコードになりにくいですが、
RubyはJavaに負けず汚いコードになりにくいし、Javaよりはるかに
簡潔に書けるのがうれしい。実行速度に言及されると弱いが。
#Pythonはよくしらんのでパス。
Re:思いっきり素人がなんですが… (スコア:1)
この提案の最も非現実的な点は, 何十年に渡ってメンテナンス出来る人材を確保・維持することが事実上不可能なことを無視していることです.
Re:思いっきり素人がなんですが… (スコア:0)
それが下っ端コーダ君なら派遣でも雇って補充すれば良いのだけど、
リーダークラスの人間が辞めた時のダメージは計り知れない物がありますね。
たとえしっかりとしたドキュメントを残していったとしても、そ
Re:思いっきり素人がなんですが… (スコア:1)
>90年代に実績がある Perl, PHP を選択すると思います。そして猛烈な資金を投じて
>(リファクタリングもさせない、堅いプロセスで)使い捨てプログラムを書かせます。
「かたい(「堅い」というほど肯定的な意味を持たせるのは不適切だと思えるので
「硬い」「固い」のほうがいいと思います。「難い」でもいいかも(藁))プロセス」
は、
「大企業(に限るまいが)が必要とするような信用」に耐えるプロセスではない、と
最近痛感しています。
むしろ逆に、パワーのある企業で、コードを幾らでも使い捨てに出来るというならば
(そんな組織が存在するとは俺には信じ難いですが、それはともかく)、
選択すべきはむしろ「使い捨てにしやすい言語」つまりそれだけ「高速に書ける言語」
じゃないかと思います。
そういう意味ではRubyとかのほうがイケてると思います。Java(や無論C++)より。
ん?ああ。
要するに、大企業も中小企業もどちらもRubyとかのほうがいいじゃん、という話です(笑)
#言語の硬さよりも、柔らか言語+自動テストばりばり、のほうが余程安心できると思うのでG7
#言語の硬さなんて所詮、型とかの「本質とはちょっとずれた」部分しか保証できないんだからさ。
なお、「信用」が「納品物の品質」ではなく(笑)「言語の選択」を指す言葉だと(その大企業が)思っているのだとするなら、
俺に言える一言は「それ、幻想ですよ。」だけです。
「実績ある言語」なんて概念は、あんまり意味がないです。
なんせ言語(メジャーどころ)は「改良」され続けてるんですから。
もし不幸にして改良されてない言語が存在したとしても、そんなもんは最初から選択肢に入れなきゃいいだけなので無視。
----
余談:
字数が嵩む言語も、コピペを多用すれば確かに「書く」時間はそんなに食わないんですが、
コピペすると今度は「読む」のに時間がかかるんですよね。
コピペらしき個所が、以前出た個所と「同じ」ことが書いてるのか「少し違う(バリエーション)」ことが書いてあるのかを
いちいち確認しないとならなくなりますから。
これがLightWeight言語だと、もともと何も書いてない場所にはバリエーションのつけようが有りません(笑)から、
さくさく読める。#WhiteSpace言語じゃないことをお祈りしますが。
RubyとJavaの比較で言えば、まず感じるのは内部イテレータの有無ですね。
Javaには無いので、ループとかを書くときに必ず「余計な」字数を要する。
おまけに余計な変数(イテレータやループカウンタ)まで要する。
そういや、デザインパターンをパターンとしてしか記述できない言語は辛いよね、という話が
Ruby方面で有りましたっけ。
もしパターン(レシピ)じゃなくライブラリ(完成品)として用意できるなら、そのほうが便利に決まってる。
Re:思いっきり素人がなんですが… (スコア:0)
>が余程安心できると思うのでG7
>#言語の硬さなんて所詮、型とかの「本質とはちょっとずれた」
>部分しか保証できないんだからさ。
この比較は、ちょっと不当なんじゃないかという気がしますが。
まさか、硬い言語だからといって、テストし
Re:思いっきり素人がなんですが… (スコア:1)
このへんを勘違いしてるアホどもの実在 (
実際、「そこはテストするまでもないでしょ」と(勝手に)決め付ける奴、居ます。
その見切りを人間じゃ完璧に出来る保証がないからこその、テストだろうに…
ええ。品質は、そりゃもう…(T_T)
) は、さておくとして、
>それとも、硬い言語では、自動テストばりばりは
>難しいということなのでしょうか。
まあそういう言語も(そうでない言語も)ありますが、それもさておき、
問題は、「型(硬さ)」と「テスト」の有効度の違いでしょうね。
「テスト」のほうが結局遥かに役立つ。
それに比べたら「硬さ」の価値なんて霞んでしまう。
霞んでしまうなら、手数が増えるだけの硬さなんて、邪魔。
Re:思いっきり素人がなんですが… (スコア:0)
>問題は、「型(硬さ)」と「テスト」の有効度の違いでしょうね。
>「テスト」のほうが結局遥かに役立つ。
>それに比べたら「硬さ」の価値なんて霞んでしまう。
>霞んでしまうなら、手数が増えるだけの硬さなんて、邪魔。
柔らかい(動的型?)言語では、硬い言語ではコンパイラが行って
くれていたチェックを、テストで行わなければならないと思うん
ですが、それを網羅的にきちんと行うコストって、それほどまで
に小さいものなのでしょうか?例えば、全てのクラスについて、
型エラーを検出するテストコードを入れるとすると、その手間
は小さい
Re:思いっきり素人がなんですが… (スコア:0)
Javaはメンテナンスのためのツールは豊富な気がするのですが…。
# EclipseからVC++.netに戻りたくない症候群
Re:思いっきり素人がなんですが… (スコア:1)
ここでいう大規模っていうのは、大きな資本があって、多くの人にサービスを提供していて、信頼性が一番重要な価値を持つってことですよね。複雑なものなので大規模になるっていうわけじゃない。