お手軽プログラミング言語は教育によくない 224
ストーリー by mhatta
アメリカですらそうなのか 部門より
アメリカですらそうなのか 部門より
pinbou 曰く、
NYUはニューヨーク州立大学(SUNY)ではなくニューヨーク大学でした。失礼しました。(by mhatta Fri, 25 Jan 2008 23:52:46 +0900)少々前の本家/.の記事より。ニューヨーク大学(NYU)の名誉教授で、GNU Ada95コンパイラ(GNAT)の開発者として知られるEdmond Schonberg氏とRobert B.K. Dewar氏が、NYUを始めとする最近のアメリカの大学におけるプログラミングの授業のあり方に苦言を呈して話題になっている。「計算機科学教育: 明日のソフトウェアエンジニアはどこに?」と題した彼らの論説では、最近の大学の授業ではCやC++、Lisp、(そしてもちろん)Adaと言った本格的な言語、数学やアルゴリズム、ハードウェアとの密接な関わり方といった難解なテーマを教えず、Javaのような簡単で人気が高く、近年減少気味の受講者数を増やせそうなお手軽な言語とカリキュラムしか教えなくなっていると主張。このままでは海外の安価なアウトソース先にたやすく置き換えられてしまう程度の能力しかない「プロフェッショナル」しか育てられなくなるだろう、と警鐘を鳴らしている。
この問題提起は活発な議論を呼び、最近になって本家/.では2つめのストーリーが立った。Datamationの記事によれば、Dewar教授は、今や計算機科学を専攻して卒業しても「社会学や哲学の学位と同じくらい将来が不安視されるようになってきて」おり、そのため専攻者が減っているが、だからといって受講者数の減少を補うためにカリキュラムを安易に易化するのは危険だと指摘する。氏の元には「よくぞ言ってくれた」という賛同者からのメールが多く届いているそうだ。
Javaって (スコア:5, すばらしい洞察)
Javaっていつからお手軽言語になったんだ?
Re:Javaって (スコア:5, おもしろおかしい)
main(){write(1,"Hello world.\n",13);}
ですむところ、Javaだと
package jp.slashdot.coward.anonymous
import java.io.*;
class Hello{
public static void main(String argv[]){
java.io.Writer stdout
= new java.io.BufferedWriter(new java.io.OutputStreamWriter(System.out));
try{
stdout.write("Hello World.\n");
stdout.flush();
}catch(java.io.IOException ioe){
ioe.printStackTrace();
System.exit(1);
}
System.exit(0);
}
}
ってうっかり書いてしまったり、ちっとも手軽じゃないですよね :-D
# でもJavaで変数1文字とかにするとまわりの白い目が
Re:Javaって (スコア:2, 興味深い)
「各公式の使い方を覚えるだけじゃなく、その証明の仕方もきちんと理解しておけ」
というわけですね。
Re:Javaって (スコア:2, おもしろおかしい)
Re:Javaって (スコア:5, おもしろおかしい)
アセンブラが持っている弱点を、きちんと全部持ち合わせてこそ、初めて一人前の言語です。
ちょっとでも学生が気を抜くとすぐメモリリークが発生したり、バッファーオーバーフローを起こしたり、スタックを踏み抜いたり…そういう緊張感のない言語なんて全部お手軽言語です。
バグの 1/2 を占めるこれらの障害が簡単に起きない言語を、学生の授業や演習で教えるなど言語道断!! アセンブラを教わればいいんだ、アセンブラを!!!
高級言語なんざ、最終コードがどう実装されるのか予測できれば、簡単に理解できるわっ。
-----
はい、そこのあなたー。Prolog を引っ張り出そうとするのはやめてねー。
はい、そっちのあなたー。Lisp を棚から下ろさないー。
あー、君々。バグっていて例外処理が出てくるのに特権命令が含まれている Itanium2 のコードは、学生実験で使うには「熱過ぎる」からねー。
こらー、そのデータフローマシンは高いから手を出しちゃだめだと何度言ったら…
fjの教祖様
「お手軽」ではなく「スイートスポットの大きさ」 (スコア:3, すばらしい洞察)
機械語/アセンブリ言語、C、Lisp はどれも教育に向いていて、Java はそうではない、
というのはおおむねコンセンサスになっているよね?
ならば、Java の批判されるべき点は「お手軽」なことじゃなくて、テニスの
デカラケ(?) に相当するような、上手下手の差が現れにくいことではないか。
聞くところでは、テニスラケットもゴルフクラブでも素人向けにはスイートスポット
の大きいモデルが好まれていて、当りどころが悪くてもそこそこ打てるという性質が
受けているらしい。しかし上達するためには、狭いスイートスポットにきちんと当てる、
という感覚を掴む必要があるでしょ?
似たような話で、松井秀喜は星稜高校にいるとき意識して木製バットを使っていたという話もある。
Re:「お手軽」ではなく「スイートスポットの大きさ」 (スコア:3, すばらしい洞察)
●状況のほうが変わってしまうこともある。
例えばテニスは、デカラケがむしろ(プロにも)普及したことで、
より簡単に強い球を打ったり打ち返したり出来るのが「当然」になってしまい、
その結果みんなのプレイスタイル自体が変化してしまったらしい。ここ数十年で。
もちろん、スイートスポットに当てれる選手のほうが強いのは昔も今も変わらないんだが、
「スイートスポット」の定義自体が変化すれば、色々なことが変わってきてしまうのよ。
プロ野球の金属バット禁止ように「デカラケ禁止」というルールになってれば
話は違ってきたんだろうけど、今実際にデカラケは使われているからね。
＃おかげで男子トッププロのテニスがあまりにも秒殺になっちまった…と。
＃球が速くなる一方で、人間の目と足がそれを追うのは限界があるから
＃ゲームバランスが変化しちまうのよ。
●べつにJavaでだって上手下手の差は出ますよ。
ただ、ありがちな(クソ)企業においては、
「ヘタなほうのコードを書け」
と言われる点が問題です。
本当に不味いのは社員にそういうお手軽(?)な指示を出す企業のほうだと思う。
Re:Javaって (スコア:2, すばらしい洞察)
それは一番最初にやる事でございます。
「いいかー、まずモニターと言うものがあるんだ。こいつは機械のメモリとかCPUの状態を教えてくれるプログラムだ。
で、こいつにはダンプ っていう命令があってだな。メモリのイメージをこうやってほら、16進数で表示してくれるんだー、
で、このメモリイメージの所に命令用のバイト列を書いていくんだなー」
でないと、生徒は自分が何をやってるのかわからないでしょ?
# 最初はハンドアセンブル。これ、基本。
fjの教祖様
別に言語は関係ないと思うけど (スコア:5, すばらしい洞察)
もう随分前から語りつくされてることじゃないのかな？
向き不向きもあるから、自分の目指す道に応じた言語を習得すれば良いと思うけど。
逆にどちらにしても、習得が中途半端なレベルではそもそも使い物にならないわけだし。
母国語を喋るのと同じ感覚でコードが書けるようなレベルまで教育しないと意味が無い。
それができないなら言語に関係なくカリキュラムに問題があるだろうとは思う。
JAVAが引き合いに出されてるが、本当の意味で『JAVAの限界を感じる』程JAVAを使いきれる人間を育ててるかってことが
問われるべきではなかろうか。そこまで極めていればそうそう他の人間に引けをとることはなかろうし、
自分が本当に必要とする言語も見えてくるはずだから。
# BASICでなんでもできると思ってた時代が私にもありました。
# 86ASM/C/C++/JAVAを業務で使ってるけど、まだまだ全然使いきれていない。
# まだまだ功夫が足りんということか・・・
Re:別に言語は関係ないと思うけど (スコア:5, すばらしい洞察)
すくなくとも、JAVAでは領域計算量のセンスを磨かせる演習は困難じゃないですか。
あと、組み込みCPUのブートとか、データセグメントの初期データをROMからRAMに転送するとかいった当たりのセンスの涵養がサッパリ。 某家電メーカーの知人は、そのあたりができる技術者は皆40代以上だと嘆いていました。
教育に使う言語は、将来その言語でプログラミングして喰ってゆくかどうかで選ぶものではありません。 プログラミングの本質を身につけるのが目的。言語は、仕事で使えと言われた言語をその時点で勉強して使えばいいのだし。 将来お手軽言語さえ知ってれば困らない職場で定年まで居られるか、抽象度の低い言語のセンスがないと辛い職に行くか、どちらの可能性もある学生さんを教育するんですから、目先の楽ちんさで将来を限定してしまうのはよくありません。
Re:別に言語は関係ないと思うけど (スコア:5, すばらしい洞察)
Re:別に言語は関係ないと思うけど (スコア:3, すばらしい洞察)
(OSその他が隠蔽している場合と異なり)そのことを端的に理解できる例だと思いますが。
Re:別に言語は関係ないと思うけど (スコア:3, 興味深い)
だったら別にＪＡＶＡでエミュレーター書かしてもいいわけで。（極論すぎますけど）
元コメでも言ってますが、中途半端に色々使えるくらいなら、いっそ何でもＪＡＶＡで書けたほうがいいと。
ＪＡＶＡでは実現が難しいことがわかってから、ＣなりＬＩＳＰなり他の言語をやっても全然遅くはないし、
その方が本質がわかるはずです。
そもそも学生の演習レベルや、アルゴリズムの習得といったレベルで、言語による致命的な差異があるとは思えません。
"Hello World"に毛が生えたようなコードが、ＣとＪＡＶＡでどれほど違うというのか。
もちろん向き不向きがあるので、アルゴリズムによってはＪＡＶＡでは複雑怪奇なコードになるのにＬＩＳＰだと数行で書けるといった違いはあるでしょうけど。
それでも一度ＪＡＶＡで書いて苦労する方が、むしろ勉強になると思います。
『目的次第では、ＪＡＶＡは決して楽な言語ではない。万能な言語ではない』
コレが理解できて、やっとスタートラインだと私は思います。ハンドル握らせるのはそこからです。
元の話がJAVAを引き合いに出してるのでJAVAと書いてますけど、これをＣに変えてもＬＩＳＰに変えてもアセンブラやＣＯＢＯＬに変えても
私のスタンスは変わりません。だって、同じことですから。だから「言語は関係ない」と申し上げております。
以下はちょっと話がそれますが。
実際使ってる人なら痛感してると思いますが、ＪＡＶＡの便利さは時に足枷にすらなります。
これはＣ等でも同じことで、それゆえにインラインアセンブラみたいな技術がありました。
JAVAはVMを使ってコンパイラとインタプリタの両方の利点を持つ中間言語コンパイラですが、
VMとコンパイラの作り方次第でネイティブコンパイルができないわけではありませんし、そういうソリューションも存在します。
これはまぁ極論ですけどね。最終的に動いてるのは何で書こうがマシン語なんです。
# そもそも学生が集まらないでは意味が無いし。
# 最終的に必要な知識が備わっていないというなら、それはやはり教え方の問題でありカリキュラムの問題ではないでしょうか？
Re:別に言語は関係ないと思うけど (スコア:3, 興味深い)
言語による「致命的な差異」など存在しないという点については同意しますが、Javaしか知らないと自らの記述したJavaのコードが「複雑怪奇なものになっている」ということなど、なかなか自分で気づくことができません（「そんなもんだ」と自分自身で納得してしまうから）。 しかし他の言語を知っていると、他言語での実装と簡単に比較できる、つまり「自らのやっていることを振り返りやすい」というメリットが出てくるわけです（実際に実感しています）。
「言語に精通する」という目標を「山の頂上を目指す」という目標になぞらえてみると、Tatenon氏の「まずJavaだけに専念する」という主張も「他の言語とともに言語を学ぶ」という主張も「単なる別ルート」であり、どちらも間違ってはいないと思います。
非線形な世界では、こまめな進路補正が欠かせないのです。しかし、Tatenon氏のルートはかなり険しいのではないかと思います（完全無欠のカリキュラムがあり、神の如く完璧な先生の元で教われば最短距離で頭頂可能だと思いますが、現実問題としてあり得ない）。
Re:別に言語は関係ないと思うけど (スコア:2, 興味深い)
何れの言語も万能ではなく、得手、不得手があるのは同意ですし、そういう意味で、元発言で言われていることの大半には同意なのです。
ただ、その結果として (教育するに当たって)「言語は関係ない」と括られてしまうところには異論がありまして、結果として「どの言語でも良い」と結論付けることはできないと私は思っています。
どの言語も万能でなく、適用領域が異なってくるという面では同意して頂けると思う (コメントを辿ると同様のことを仰っていると思います) のですが、その上で、私が強く感じているのは、それぞれの言語を習熟する過程で身に付くプログラミングのアプローチが異なるのではないか、という点です。
これまで様々な言語を使って (本当の意味で『限界を感じる』程、使い熟すまでには至っていませんが) 来た中で感じていることや、他の様々な言語を習熟されている方々からの話を聞いていても、やはりそれぞれの言語が持つ特性や文化、言語設計の方針などによって、問題領域の捉え方や解法へのアプローチが異なってくる様に感じられるのです。
非常に本質的で抽象度の高い問題意識に関して言えば、「言語なんて皆一緒だ」と括ることができると思うのですが、「教育」という観点に立ったとき、教育対象となる人々に学ばせて実効性のある事柄を考えると、どの言語でも良いとは言えないかなあ、というところでしょうか。
教育の目的がある程度限定的な問題領域に対するプログラミング能力ということになれば、その目的に即した言語を習熟させることになるでしょうが。
また、同じ理由から、何れか一つの言語ではなく、幾つかの言語について学ぶことにも意義があると感じています。これについては、初学者がある程度の素養を身に付けるまでは対象を絞った方が良いという考え方もあるとは思いますが。
どうも上手く説明できなくてすみません。
個人的な意見としては、この様な観点で、プログラミング初学者に最初に学んで貰いたいのは Lisp/Scheme かなあと愚考する次第です。他の方々からは異論もあるでしょうが。
単なる回顧談にしか思えん (スコア:2, すばらしい洞察)
高水準言語がダメっていってる奴は、「自分の問題を解決する」ためにダメって
いうところを自分の世界がすべてだと思い込んでいないか？
エクセルのVBAでも基本的なロジックを教えるためなら、一向にかまわんと思う。
それとも「コンピュータを扱う人は、すべからくコンピュータサイエンスを学ぶ
べきだ」って今の何億台もパソコンが出回っている世界に向かって叫ぶんです
かね。
お手軽プログラミング言語反対派は、自分がタラタラやってきた茨の道の横に
出来た高速道路をぶっとばす連中に腹がたつんでしょうね。一人で死ぬまで
匍匐前進してろ、と思う。
Javaの深奥を知ることはいいことだ。だが、まったく金にならん。それは事実。
みんなのべき論が世の中ではまったく評価されない、ということだ。
なぜか？よく考えたほうがいいと思う。
大学ってそうなんだっけ？ (スコア:5, 興味深い)
オレの知り合い（米国人）の例だが，ちゃんと世界最高峰レベルの某大学（＠米国）の計算機科学で学位を取った優秀な研究者なのに，（ホントかどうかは知らんが，本人曰く）CもC++もJavaもその他LL系言語も含めて一般的なプログラムの類は一切書けないらしい．彼はどうやって計算機を使っているかというと，MatLabで研究をしているのだが，彼自身はMatLabに実装されている各アルゴリズムの意味するところ（≠実装）は完全に理解して使っているから，計算機科学としてはそれで何も問題無いと思う．大学で扱う「計算機科学」ってのは，本来はこういうもんだと思うんだよね．
もちろん上記の話はあまりにも特殊な例で，通常はメジャーな環境でのプログラムが書けないのは困るだろうし，本質的な部分を理解させた上で便利な環境を教えるのは「車輪の再発明」的な問題を避けるためにもアリだと思う．しかし，先の東大の話題 [srad.jp]における議論を見ていても感じるのが，大学に対して「IT業界で使えるプログラミングの教育」みたいなことを期待してる勘違い社会人も多いし，そういう勘違い企業に就職させるために手軽な開発環境のプログラミングだけを教えるようになるのは言語道断だと思う．で，そういう意味でバランスが取れていたのがC言語（百歩譲ってC++）だったんじゃないのかなーと思う今日この頃ですな．
下まで読んで (スコア:4, おもしろおかしい)
って、完全オフトピですね。すみません。
車輪の再発明をさせろ (スコア:4, すばらしい洞察)
ライブラリが無い環境でどうしていいか分からなくなる。
コードは書けるけど、アルゴリズムが無いと何もできない子になる。
一度Cとかのなにもない環境でやらせないとダメ。
無いものは作るというハングリー精神が無くなる。
#最近はPythonでしか書いてないなぁ…
#10行でWebサーバが書けるのには感動。
Re:車輪の再発明をさせろ (スコア:3, すばらしい洞察)
例えば、便利なアルゴリズムや制御構造が揃ってるlispを使ってアルゴリズムに弱くなるかっていうとそんなことないだろう。
Javaの問題は、便利な道具が揃ってることじゃなくて簡単にソースが見れないのと、ライブラリの利用者と製作者を分けるような姿勢が問題なんじゃないかって気がする。
似たようなので、Windowsの世界もそうかな。OSのことを語られるのにあーなんじゃないかこーなんじゃないかって内部構造を想像して終わらない議論になってて、まるで占い師か経済学者の議論を見ているような気分になることがある。
Re:車輪の再発明をさせろ (スコア:3, 興味深い)
学生の雇用面接（@US）をすると、いろいろなアルゴリズムや技術の名前は知っているのだけれど、それをブラックボックスとしてしか理解していない人が驚くほどいるんですよね。ちょっと話すと色々知っているし、レジュメを見てもいろんなものを作っているように見える。でもちょっと掘り下げるとすぐに馬脚を表して、がっかり。そういう人は確かに典型的に Java, そして perl や Python 止まりで C はできるけれどそれほど得意じゃない。そういう感じ。最近立て続けに、The Perils of JavaSchools [joelonsoftware.com] とNYUの先生の記事を読んで、なるほどそういう背景があったのか、ポンっと膝を叩く気分でした。
こっちの期待しているのは車の運転の仕方を知っている人ではなくて、車を作れる人なんだけどな。
Re:車輪の再発明をさせろ (スコア:2, 興味深い)
私が面接をした範囲では、quick sort を O( N * log N ) のアルゴリズムだと思い込んでいる、と言うあたりが馬脚の基本ですね。
# 逆にそこをつついてくる面接を受けた事もあります。
# 多分、あそこの面接官は本当に技術力があったんだろうな。
fjの教祖様
Re:車輪の再発明をさせろ (スコア:2, 参考になる)
クイックソートは『平均』nlognだと教えてはいるのですが、細かい背景をすっ飛ばしてnlognだけ暗記するアンポンタンがおおくて、すみません。
P.S。「quicksortは最悪時O(n^2)」よりも、「quicksortは最良時O(nlogn)」のほうが結構頭からすっかり抜けている落とし穴かも。ちゃんとクイックソートを理解していれば、その場で考えて「最良時もnlognだ」と分かるんですが。
Re:車輪の再発明をさせろ (スコア:3, 参考になる)
Quick Sort の最良値が O( N * log N ) になるのは、理解できると思う。
で、最悪値が O( N^2 ) になるのも(書き込んでいるぐらいだから)理解できると思う。
と言う事は、このアルゴリズムはこの2つの間のどこかの計算量になり、どうなるかは「与えられたデータに強く依存する」と言う事だ。
Quick Sort は決して O( N * log N ) のアルゴリズムではない。単に「係数」部が非常に軽いので、O( N * log N )である事が保証されている他のアルゴリズムを、平均値では追い抜いているのに過ぎない。最悪値比較をすれば、O( N * log N )が保証されている merge sort に負ける。どの方法も(ランダムアルゴリズムを利用する方法でさえも)平均値を良くする以上の効果は無い。つまり、ここに述べられている『実装』の話を全部ぶち込んでも、Quick Sort の数学的な側面は変わらない。並列処理をしても変化するのは結果が出るまでの総時間だけで、計算量は変わりません。もっと言うと、並列処理をするために「データを分配する」段階が O( N ) になるので O( log N )とは、とても呼べません。
# で、分配しない、共有メモリ型にすると、メモリ参照が衝突する。その頻度がO(N)が
# 最悪値保証されてしまう。
# 衝突頻度を下げるために Cache を入れると「Cache 読み込みの段階で」O(N)が保証される。
# と言うわけで、O(N)を切るソート方式はありえないのだよ。
## 厳密な証明は面倒なのでやらないが。
実装レベルでの改良方法を一杯言ってくる人はいます。いろいろ独創的なものを持ってくる人も含めて(最初に一発 table sort を入れる、ってのは面白かった)。
その結果「係数がどんなに小さくなっても、計算量評価の際には無視する」という大前提を理解しているかどうかが判る。
# 「係数が小さいから、この項は次数が大きいけど無視しよう」という判断は、
# ・N の範囲が本当に制約されている事
# ・インターフェース的にきれいに分かれていて、
# Nが万が一でかくなったときにも対処できる事
# という2つの前提が成立しない限り、やってはいけない。で、このセンスは教えられる。
# もし、その前の段階の「計算量」の話が判っているのならば。
fjの教祖様
Re:車輪の再発明をさせろ (スコア:2, すばらしい洞察)
あー、そういうことをいう「試験官」にプログラマーとして有能な奴はいない。テストとは「コスト」と「エラー率」との戦いだ、という事を念頭においていない証拠であり、それ自体プログラマーとして無能な証拠だから。
もちろん、個数と単純に比例はしませんがソートというトピックに対して、1つしか方法が出てこない人は確実に無能です。
# いや、名前は出てこなくてもいいんですよ。「ほら、こういう風にするやつ」でも。
大事なのは、「比較する能力がある」事。そのために「2つ以上述べられる」事。そしてそれぞれの pros/cons が比較できる事です。
ただ、大抵の場合ちゃんと2つ以上述べられる人にソートというテーマを与えると、quick sort と merge sort が出てきて、必要要件に応じてどちらを使うかをパシッと述べる事ができる。これができない人は quick sort しか出てこない。そしてほぼ確実に quick sort を O( N * log N )だと思い込んでいる。
# で、ここでこのネタをばらしていると言う事は、実はもうそろそろ次のネタが
# 見つかったという事なんで、ここを丸暗記したってだめだよ (^o^)。
fjの教祖様
Re:車輪の再発明をさせろ (スコア:2, 興味深い)
ので、お手軽言語だって教えておく意味は十分あると思うよ。
Re:車輪の再発明をさせろ (スコア:2, すばらしい洞察)
ここで得た経験を足がかりにして，応用を利かせられれば良いと思いますが．
特に最近の大学のプログラミング実習は，実用性を中心に考えるのではなくて
取っかかりを掴ませるところに主眼を置いている気がします．
とりあえず誰でも出来るような簡単なところからスタートして動かしてみて，
それで面白がってやる気を起こした学生は，面白がってもっと上を目指すでしょうし，
つまらんと思った学生は逃げていきます．
Re:車輪の再発明をさせろ (スコア:2, すばらしい洞察)
Re:車輪の再発明をさせろ (スコア:1)
std::vectorを知らなくて、自前で可変長配列をがんばって作ってた覚えが。
std::mapを知らなくて、自前で二分木をがんばって作ってた覚えが。
お前が言うな！ (スコア:4, すばらしい洞察)
といっていいのは、車輪を発明できる人だけです、と誰か声高に言ってくれ。
昔Cで文字列操作をゴリゴリやっていた。Javaになって、より手軽にできるようになった。しかし、そのゴリゴリの時に得たノウハウは、文字列操作でなくてもいろいろ役に立つことが多い。だから、文字列操作をしないこととできないことは違うんだが・・・誰かわかって・・・
-- gonta --
"May Macintosh be with you"
大学名が違う (スコア:3, 参考になる)
他にもニューヨーク市立大学(CUNY)なんてのもありますが。
問題は簡単言語ではなくて。。。 (スコア:3, 興味深い)
ちょっとぐぐってみたら、日本の情報○○学科で「データ構造とアルゴリズム」が選択科目になってる学科って存在しますね。
んなこと (スコア:2, 興味深い)
オフトピ (スコア:5, おもしろおかしい)
ちょっとイケメンっぽい一般ウケする奴が全く同じこと言ったとたん、みんな真面目に聞き入れるの。
Re:んなこと (スコア:3, 興味深い)
Re:んなこと (スコア:3, 参考になる)
Re:んなこと (スコア:2, 参考になる)
Javaスクールの危険 [joelonsoftware.com]
Paul Grahamは、普通のやつらの上を行け [practical-scheme.net]でいいのかな？
卒業生です (スコア:2, 興味深い)
他の人も書いてますが、NYUは私立のNew York Universityで、マンハッタンのグリニッジビレッジにあります。ニューヨーク州立大学はState Universtiy of New York, 通称SUNYで、バッファローとかストーニーブルックとかの田舎にあります。
言いたい事はよくわかった (スコア:2, すばらしい洞察)
だから、そんな事はどうでもいいから、
そのスペシャルなスキルで、デスマーチの起こらないミドルウェアを開発してくださいよぉぉぉ！
何となく (スコア:2, 興味深い)
Master Foo and the Ten Thousand Lines [faqs.org]
1行のシェルスクリプトの方が 10000行の C よりも Unix らしさがある。
(邦訳は「The Art of UNIX Programming」に。まだ読んでない...)
お手軽プログラミング言語って、awk や sed や find も含んでいるのかねえ。
確かに (スコア:1)
Ada? (スコア:1, おもしろおかしい)
Re:Ada? (スコア:2, 参考になる)
adaは1979年に企画されてできたのは1993年。UNIXは1969年、Cは1972年。
Re:Ada? (スコア:1)
Re:建前はそうですが (スコア:1)
Re:建前はそうですが (スコア:2, 興味深い)
でも中小企業は
(何か尖がってる一部の企業を除けば)
できない人間しか来ないのですがorz
10年見てて、湯水のように沢山の若者が入っては出ていったが、面白いといえる奴は3人くらいしか居なかったのでAC。
ああそうか。養ってるのではないのだな。
ブックオフのようにロクに評価せず束で購入し、
駄目ならぽんぽん捨てていく。
どちらかというと(社長は)回転率を上げたがっているように見える。
職場に「回転率」ってのもどうかと思うんだが、実際そう見えるorz
まあありがちな偽装(?)請負業者だから、こんなもんなんだろうな。
Re:建前はそうですが (スコア:2, 興味深い)
むしろ経験の無い人を採用したがる企業が多い時代がありましたが、今はそうではないんですかね？
# 変な癖が付いていると困るからだそうで…
Re:建前はそうですが (スコア:2, 興味深い)
当人はJAVAでオブジェクト指向プログラミングをしているつもりだけど、メソッドへのデータ受けわたしにグローバル変数を使う。 とか、 既存のクラスとか関数とかfooのソースをよそからいただいてきて barという機能に換骨奪胎したときに相変わらず名前はfooのままで使ってるとか、そーゆー癖がついているのは？
「僕は自宅のPCでもPASCALコンパイラを持ってるくらい熟練してるんです」と自慢してる奴が、1000行のメインルーチンにだけ(ユーザ関数/ユーザ手続き一切無しでgoto使いまくり)ってプログラミングをしてそれでいいと信じ込んでるとかいうのは？
コンパイルエラーが出なくなったらプログラムは完成だと思ってるとか。
Re:プログラミングの普遍化 (スコア:3, すばらしい洞察)
たとえば、「EOFがくるまでホワイトスペース区切りで数値を読み込み、平均と分散を計算して出力しろ、というC（でもJAVAでもいいけれど）の課題がわかりません」って学生が居るとする。 そいつに、『じゃ、紙と鉛筆と電卓で、平均と分散を計算する方法を説明してみろ』というと・・・
説明できるヤツ→C言語の技能が足りない
説明できないヤツ→プログラミング以前の問題
でも説明できないヤツでも、「C言語が難しいので出来ない」と思いこんでるんだな。
Re:Pascal (スコア:2, 参考になる)
・学生のレベルが下がって、「まず教育向けのコンパクトな仕様の言語で一通り勉強して、実用性を気にするプログラミングの言語は3年生くらいで別途学ぶ」といったことが難しくなってきた。
・入学直後から、聞きかじった今時の言語(社会に出て実際に使いそうな言語)を使いたがるように、学生の風潮が変わってきた。
・会社で使うような言語を大学でも教えておけという、産業界からのプレッシャが強くなってきた(「PASCALでもSCHEMEでも、基礎をしっかり大学で教えてくれれば結構。仕事で使うCOBOLとかCは会社で教えるし」なんていう態度の会社はすっかり減った)
といった背景で、CやJAVAが1年生でまず習う言語として主流になってきたのだと思います。 あと、BASIC(N88とか・・・)はすっかり消えましたが、VisualBASICは教育用としてもかなり使われています。