アカウント名:
パスワード:
でも説明できないヤツでも、「C言語が難しいので出来ない」と思いこんでるんだな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
プログラミングの普遍化 (スコア:0)
自力で開発してしまうようになるんでないの。
業務知識を深く反映した強力なロジックを実装して使いながら日々改良していくなんてことができそう。
Javaの最新版いじってみたら、あっけなくいろんな事ができるんでびっくりしたよ。
Re: (スコア:0)
Re: (スコア:3, すばらしい洞察)
たとえば、「EOFがくるまでホワイトスペース区切りで数値を読み込み、平均と分散を計算して出力しろ、というC(でもJAVAでもいいけれど)の課題がわかりません」って学生が居るとする。 そいつに、『じゃ、紙と鉛筆と電卓で、平均と分散を計算する方法を説明してみろ』というと・・・
説明できるヤツ→C言語の技能が足りない
説明できないヤツ→プログラミング以前の問題
でも説明できないヤツでも、「C言語が難しいので出来ない」と思いこんでるんだな。
Re: (スコア:0)
おいおい、C言語よりその数学の方が難しいだろよ。
平均と分散のできる人間がプログラミングを覚えるほうが、プログラミングしかできない人間が
平均と分散を覚えるより楽なんではないの?。
元コメは、プログラミングができるだけのプログラマが仕様を作れるまで客先の
業務を理解するコストと、業務を理解している人間がプログラミングを覚えるコストとどちらが
低いかという話。
インドにでも投げちまえばいい、文系の卒業したてでもできる、なんてレベルまでプログラミングの
敷居が低くなって環境も整備されてるなら、もう客が直接できるだろ。
Re:プログラミングの普遍化 (スコア:0)
確かにこれのほうが楽そうだとは思うんですが、
ただ、Javaに限らずプログラム言語って、
バッドノウハウの塊なんですよね。
それを我慢して覚えることが出来た人間が、
業界でやってられるのであって。
(EUCの成否はいかにバッドノウハウを減らすかに掛かると思う)
というか逆にいえば
顧客側のビジネスルールを覚えるときも、
なにが障害になるって、そのルールにおけるバッドノウハウ(の多さ)です。
例外が少ないか、有っても切り分けし易い例外か、で構成されたルールは、
それに疎い他人にも判り易いです。
つまり、お互い、バッドノウハウを抱えてるわけです。
そしてこのバッドノウハウがゆえに、
両者は業種の越境をやりにくくなり、
それをもって「住み分け」と呼んでいる。