昔のプログラミングスキルは今も大事? 129
ストーリー by hylom
温故知新 部門より
温故知新 部門より
cheez 曰く、
本家/.「What Today's Coders Don't Know and Why It Matters」より。
今日のプログラマーの扱う言語はより進歩しているし、ハードウェア要件だってそれほど厳しくない。
新たにプログラミングの世界に入ってきた人々はハードウェアの制約やハードウェアエラーに慣れておらず、コーディング前の仕様段階から開発していくことや、アセンブリ言語などの低級言語のスキルに長けていないことが多い。時代遅れのスキルかもしれないが、こういった知識や経験が突然必要になることだってあるだろう。
例えば14.4Kbpsのモデム時代にウェブ関連のプログラミングを始めた人々は、ラグの多いワイヤレスネットワーク向けのアプリケーションの開発において始めから一歩先んじていると言えるのではないだろうか?
長年プログラミングに携わってきている/.Jer、比較的新しいプログラマー/.Jer、双方の所感はいかがだろうか。
ところによって違う (スコア:5, すばらしい洞察)
例えば、組み込み系でODMなんかだと、チップやメモリの価格と開発費とはバランスを計算しなければいけないし、標準ライブラリすら使用できないC言語で開発なんて事例も多々あります。
そういう時は古いノウハウが実に実に有効です。
あとは、Windowsで.NET Frameworkで開発するとしても、下層にはWin32/64やOSの制約が居るので、そんなAPIバイブルな時期のノウハウもデバッグ時に力を発揮するでしょう。
あるいは、気を付けて作っていてもリリースビルドでのみ発症する不具合などが出た場合、レジスタやスタックやダンプの見かたを理解しているのとそうでない場合とでは、解決までに要する時間は違うかもしれません。もしくは、最適化というもの自体に対する理解は武器ともなりえます。
最適なアルゴリズムを選択するには、やはりアルゴリズム自体を理解していることは重要でしょう。
しかし、最近の若者の中にも飲みこみの早い人は多いので、昔我々が苦労した点や注意点を少し伝えれば、要点を理解して同じ轍を踏まないなんてこともよくあるわけで。
古参のプログラマが一歩先んじている、というのはある面からの事実だけど、我々が消費したのと同じ時間を若者に消費させちゃいけないというのがポイントと思われます。
ノウハウは継承してゆくものじゃないかと。
そして、継承した上で次のモノを習得して待ち構えて、いつまでも先輩であり続けてやりたいと思います。
あまり役にたつことはないが (スコア:5, おもしろおかしい)
そういう知識があるとなぜか酒の席で話が弾む
Re:あまり役にたつことはないが (スコア:1, おもしろおかしい)
Re:あまり役にたつことはないが (スコア:2)
これ系の話はさすがに振れら無いと話さないですね~。
若い人に言っても意味分からないだろうし、こういう話はもっぱら自分より年上の人に限定されてます。
身も蓋もない言い方だけど (スコア:3, すばらしい洞察)
必要な物はのこったし、入らない物は捨てた
そういうことの積み重ねが経験を積んだプログラマなのであって、新人がいきなりDeepな世界に突っ込まれたら右往左往してもしかたないだろう。
自分も昔は右往左往したし、そのとき指導できる人は今ほどプログラマ数が多くないが故に少なかったけど、CQ出版と指導してくれた先輩に負けないように新人を導くのが先達になった僕らのしごとじゃないのだろうか?
やっぱりSQL (スコア:2)
素のSQLを書かなければならないことは
この20年間変わらない真実。
Re:やっぱりSQL (スコア:2, 興味深い)
数万件程度のテーブルの単純な結合を、戯れに全件メモリに読み込んでハッシュでやってみたら、
処理速度が劇的に上がったのは笑った。
隣人は、何もかも無理やり1つの巨大なSQL文で済ましているコードに四苦八苦していたりします。
それは今はいない前任者の残したコードなので、ちょっと気の毒です。
そういう自分も、動作条件も考えずに、何もかもストアドプロシージャーで書いていた時期もありました。若かった...。
#存在自体がホラー
一応若いもんには (スコア:2)
通信プログラムをつくるときには、その通信内容が、電気的にどうなっているか、までは問わないけど、イーサネットに流れるビットレベルくらいは想像がつくようになっておけ、とは言ってます。
プログラムも、概念的にどういうマシン語に落ちるかを理解しておくと、最近のマルチスレッドプログラムとかで、競合や粒度などが直感でわかるようになり、バグは減らせます。
Re:一応若いもんには (スコア:3, 興味深い)
なんか kbps の世界で痛い目にあって、 Mbps の世界で叫んだのと同じ内容を、Gbpsの世界でも叫ぶ必要があった一昨日…。
# きっと Tbps の世界でも叫ぶ必要が出るに違いない、と直感した。
fjの教祖様
Re:一応若いもんには (スコア:2, 荒らし)
地面が混雑しているなら、空を走ればいいじゃない。
教祖様は保守的に過ぎます。
誤記 FireFox
巫女 Firefox [mozdev.org]
Re:一応若いもんには (スコア:1)
空を飛んでコーナーをそんなに効率よく曲がれるもんなら曲がってみなはれ。
# それで効率よく曲がれるなら、グリップを失った後に壁にぶつかったりせんわい
fjの教祖様
Re:一応若いもんには (スコア:1, 荒らし)
http://www.toranoana.jp/mailorder/article/04/0000/04/91/040000049121.html [toranoana.jp]
これが時代の違いですよ、教祖様
誤記 FireFox
巫女 Firefox [mozdev.org]
Re:一応若いもんには (スコア:1)
そんなスパイダーマン [wikipedia.org]のパチモンみたいな手は通用せんっ。
オーバルコースには「天井がない」のだよ(そこっ?? 突っ込む所はそこと違うっっ)
あ、もちろん、高いビルもないぞ。
だから、西新宿のせんべい屋の主だって、空を飛んだりはできんのだ。
fjの教祖様
Re:一応若いもんには (スコア:2)
つまり、限界までの高速化のためには
限りあるバス帯域を使うのが一番のネックなので
専用のメモリをオンボード実装し
メモリコントローラーはボード搭載のCPU内蔵のものを使う
そんなデバイスじゃないと、余所様に迷惑な実装だということですね。
そして、システムバスには「42」とだけ返答を流すと。
誤記 FireFox
巫女 Firefox [mozdev.org]
Re:一応若いもんには (スコア:1, 興味深い)
なんてか、長年やっているといろいろな所で、機能自体が隠蔽されるのと明示的に考慮が必要なのが交互に来ている気がする。
まあどんな新機能でも最初は実装優先のフェーズが有り、そこから利便性の向上をめざし、更にスペックアップ…となるとそれも必然なのかも知れないとか思ったり。
Re:一応若いもんには (スコア:2, すばらしい洞察)
それって昔のスキルというよりも下位レイヤのスキルの話だよね。
下位レイヤも知っといた方がいいよ、というのは同意。
Re:一応若いもんには (スコア:2)
> 今は「知っといたほうがいい」程度だけど、昔は知らなければ仕事にならなかったという意味で昔のスキル。
その通りです。昔は、周辺機器もバグが多くて、本来は自分の範囲でないところでも理解しておかないと、それを避けたり、可能であれば自分で修正したりしないと、仕事が前に進まなかったのです。
Re:一応若いもんには (スコア:3, 参考になる)
そうそう。
どこまでも知って行って損はないですね。
例えば、組み込み系やってるときなんかは、ハードが疑わしい問題が発生するとオシロ繋いで電気的に信号を捕まえて、もっともシンプルなプログラムで発症させてハード担当者に調査をお願いする。
なんていうのが普通の手続き。
オシロの使い方を理解していたら、次は回路の動作を理解するとさらに問題解決は早くなる。
回路自体を読んだり、そのうち自分は開発中のCPUのマイクロコードを書くところまで降りて行った。
そして次は・・・
と、知れば知るほど、知らないことの地平がどこまでも続いていることを知る。という状態くらいが技術者にはちょうどいいと思います。
ネットワーク方面だって、安定につながったネットワーク上で動くものばかりじゃありません。
遅延、欠落、輻輳などを発生させた状態で、要求仕様を満たすパフォーマンスが出るかどうか。
何で試験すればいいか。何で確認すればいいか。中で何をやってるのか。エラーの原因は何か。
など、学校を出たばかりの若者なんかは、スクリプトや.NETやJavaVMなどの十分にラップされたソフトウェアの上の例外でしか知らないから、エラーリカバリーなんかは教えるべきところが多々ありました。
知っている事と両手で届く範囲の安定にもたれかかっているだけでは、技術者としての成長は乏しいでしょう。
若い人にも、世界の広さを探求しながら、今の業務に必要な技術を突き詰めてもらいたいですね。
開拓の終わっているところは、古参者に尋ねてくれれば教えるのは厭いませんし。
記憶力もスキルのうち? (スコア:2)
若い頃は、開発中の 500行くらいのコードなら憶えていられたものですが…
記憶だけで、電話口でのデバッグとかやったものです。
最近はスクリプトレベルのものしか書かないからなあ。
# もっと古い人だと、「紙テープやパンチカードが読める」とか、
# 「マシン語の逆アセンブルができる」とかの逸話を聞いたことが
# ありますが。
Re:記憶力もスキルのうち? (スコア:4, 興味深い)
逸話と言うか、目の前で見てきました。うちの親父がそういうプログラマでした。
私は二代目プログラマです。幼少期に親父の働く様を見て育っております。
パンチの入った紙テープのプログラムも読んでましたし、デバッグと称してテープを切断し、別のコードが書かれたテープを切り張りする様などは、今考えるととても古風で、でも新鮮でした。
磁気記録が使われるようになってからもしばらくは、アセンブラシートに命令を手で書いて、その命令に対応する2進数を作成し、最後に手で16進数変換。
それを別の人に預けて入力させてから、大抵深夜に端末を借りてデバッグしてました。
当然ながら、コード表さえあれば逆アセンブルすることもよくありました。
親父は言います。
「今はCut&Tryで試せるからデバッグが甘いコードが多い。昔は、バグを出すと次にホストが空くまで1日待たされるから、机上でほぼすべてのデバッグを済ませたもんだが。」
もちろん、今ほどの規模のプログラムに過去の常識を強要するつもりは本人も無いようですが。
近年においてはVisualStudioを駆使してエディットコンティニューでさくさくとデバッグしております。
親父の担当個所は、リリース後の不具合がほぼ出ないので、現役のころの顧客からの信頼はそれはそれは高かった事を覚えています。
今、親父は還暦プログラマとして、C#でオーディオ系のソフトウェアを書いて余生を送っております。
肉より骨 (スコア:1, すばらしい洞察)
あとアドレス・ポインタみたいなコンピューターの基礎の基礎も意外と…
なんらかの理由で過去のBADノウハウが役に立つ事も無いとは言わないけどね
自動車免許の前に原付免許を取るような感じ (スコア:1)
肝心な部分は一からやる必要があるので履修内容は大差無いかと
#古い技術を知ってる年寄りよりも、勘の良い新人の方を採用すべきかと
無意味かつ無駄な質問 (スコア:1)
現在一般的なプラットフォーム上で、必要な要件を実現出来る言語であれば予算と期間が許す限り何でも良い
古い言語とか新しい言語とか全く関係ない
#つまりどんな言語が使えようとOS/2は許されざるよ!
つくるだけなら今のスキルだけで出来る (スコア:1)
問題はトラブルが発生したとき。
障害の切り分けには,現代プログラミングが隠蔽してくれている「プリミティブレベルの動作」の知識がものを言う。
Re:つくるだけなら今のスキルだけで出来る (スコア:1)
>「プリミティブレベルの動作」の知識がものを言う。
「プリミティブレベルの動作」がトラブルシュートに役立つこと自体は否定しませんが。。
そもそも「トラブルシュートできる人材」の地位が低下していて
「プリミティブレベルの動作」の知識も「役に立たないスキル」だったりしませんかね。。。。
#「プリミティブレベルの動作」を分かって作業している人が「使い捨て人材」
#だったりすると「プリミティブレベルの動作」なんて知ってても無駄だな、と思われたり。。
現在だと「トラブルシュート」をする状況を発生させない仕組みを作るほう
を重視されている気がします。
だから「トラブルシュート」をする人の評価が下がってる気がするのですがどうでしょうか。
歴史は繰り返す (スコア:1)
プラットフォームが変わる事に歴史を繰り返してるような
- 省メモリ/高速化のセコテク
- ハードウェア透過色でなくANDやORを駆使した透過合成
- 自前3D描画
などなど
PC
Java applet
iアプリ
Flash
Javascript+Canvas
webアプリで言えば
SQLDBが使えない環境でファイルやDBMで何とかする -> KVS
そんなのスキル()の内容次第だろ (スコア:0)
DEFINT A-Z
なんか昔は必須だったけどw
# 以下ロートルの昔話スレでおながいします
Re:そんなのスキル()の内容次第だろ (スコア:1)
最初の行にCLSと書かないとか!!!
Re:そんなのスキル()の内容次第だろ (スコア:3, 興味深い)
20 ...
F-BASICのRENUMは、行番号の参照が一度もないとプログラムを破壊するというバグがあってな。
Re:そんなのスキル()の内容次第だろ (スコア:3, おもしろおかしい)
key 5,"new"+chr$(13)
あ~の~や~ろ~(((( ̄▽ ̄#
Re:そんなのスキル()の内容次第だろ (スコア:2)
Re:視点の差だけなんだがな (スコア:3, すばらしい洞察)
そんな状況あるかよとは言えないのがなー。
ある種のDBのチューニングってそういうアプローチな気もする。
#存在自体がホラー
Re:視点の差だけなんだがな (スコア:2, おもしろおかしい)
よし、バブルソートをアセンブラで書きなおそう!
気晴らしにはいいかもしんない。
Re:知識の棚卸し (スコア:3, 興味深い)
不自由な環境やハードがらみのプログラミングの経験が全然無いのだから仕方ありません。
今の組込は,昔で言えば組込ならざるアプリケーション・レベルの上流開発ですから。
そういうわけで低レベルの組込開発はごく少数の専門家しか関与しない特殊な閉じた世界になってしまってるわけですが。
#ARMで富豪的プログラミングなんて組込じゃない
Re:知識の棚卸し (スコア:1, 興味深い)
15年前のプログラマーをそのまま現在に持ってきてもほとんど役に立たないけど、
新しい知識を覚える一方で古くなった知識を整理した結果、
選りすぐりの知識が身についている人は役立つんじゃないかな。
よりすぐった結果怠け者になりました。
昔の自分が書くコードは今よりも良いコードに見えます。(´・ω・`)
# 昔のコードに手を入れるときにいつも感じる新鮮な驚き
Re:知識の棚卸し (スコア:1)
役に立つバッドノウハウ (スコア:2)
「Cプログラミング診断室」で得た「下手糞なプログラミング」に関する知識は、
JavaやPHPの時代になっても、とっても非常に毎日のように役立ってます。
本音を言えば、こんな知識は役に立って欲しくなかったよ。
できればベストプラクティスや専門知識を役立たせたい今日この頃。
Re:バッドノウハウを (スコア:1)
「VSS使ったことありますか?」キリッ
「あっ、コード修正したら、変更前の部分はわかりやすいようにコメントにしておいてください」キリッ
とか言われてもんにょりしている私が通りますよ。ええ、いろいろな意味で。
コの業界、文明以前の呪術的な状態がまだ続いているところもあるんだなあ。
おかげで、帰ってから趣味のプログラミングがはかどる事。
#存在自体がホラー
Re:バッドノウハウを (スコア:1)
「テスト項目は(Excelの)仕様書をコピーして、記述の後ろに■と日付を入れていってください」キリッ
まあ、何が言いたかったかというと、それはもう十年くらい前に自分が通過してはまってきた道だという事と、
このタイムスリップした感をどうやって修正してくかね。
#存在自体がホラー
Re:バッドノウハウを (スコア:2)
テスト項目はFirefoxをインストールしてこの拡張機能をインストールすると
SQlite+Windowsファイル共有でグループ全体で共有できます(キリ
ならやったことあります。
DBファイルをファイルとして共有とかバッドノウハウ
誤記 FireFox
巫女 Firefox [mozdev.org]
Re:バッドノウハウですらねえ (スコア:1, おもしろおかしい)
Re:絵描きにも昔の知識は必要 (スコア:1)
昭和生まれですが、「不祝儀敷き」と言われて何だか判りませんでした。
(Wikipediaの図を見て、「ああ、コレかあ」と思うレベル)
実家は和室のある家ですが、上にじゅうたんなど敷いているので
実際には殆ど目にしなかったんですよね。
だから畳の掃除の仕方も判らず、学生時代に教わりました。
#平成生まれに限らず、身近になければ判らないってことで
☆大きい羊は美しい☆
Re:絵描きにも昔の知識は必要 (スコア:1, すばらしい洞察)
# 検索できることは覚えなくて良いってアインシュタインが言ってた
Re:絵描きにも昔の知識は必要 (スコア:1)
平成生まれというより、和室で生活していないだけでは?
Re:絵描きにも昔の知識は必要 (スコア:1, すばらしい洞察)
古臭いイメージがこびりついてんだなー
Re:数学で使える概念と比べると、今の言語も十分に古く感じる。 (スコア:2, おもしろおかしい)
Re:数学で使える概念と比べると、今の言語も十分に古く感じる。 (スコア:1)
なんかの釣りなのかな?
一つのクラスで定義できる手続きは幾つでも許されるが、型は一つのみ。<<略>>「高級」言語というのなら、数学で使える概念体系と比較してから言って欲しい。
一つのクラスで定義できる型が一つのみでは表現できない数学の概念、って何ですか?具体的に比較して言ってもらわないと検討できないなあ。
だからといって日本語や英語は欠陥言語だ、とは言わない。
日本語は論理的な言語ではない、と言うような意見はありますよ。
Re:HowToをためたものは所詮HowToでしかない。 (スコア:2)
> 某メーカー系の巨大プロジェクトに居るけど、プロパーで30後半のやつらはほとんど使えない。
私の周囲にも、以前そういう30代後半が居たので、わかります。
私が30代後半になった今、こんな風に言われないよう頑張りつづけなきゃいけないですね。
もちろん理論的実践も重要です。
対症療法的な記述などは、どんどんきれいなプログラムに書き換えるべきだと私も信じます。
が、残念ながらまだ泥臭い部分を完全に排除できるほど、開発の現場は進歩してないとは思います。
CPUとメモリの間だけで物事が解決することが少ないからです。
例えば、通信やデバイス回りのところをロートルが担当すること、多くないですか?
デバッグ手法を含め、ルーキーには難易度が高いところを背負っているってのも結構ある話じゃないでしょうか。
通信の世界もOSもレガシーなものは残っていて、そこに対するHowToは、結局使わざるを得ない実態もあるかなと思います。
ロジカルな話だけで解決する時代が来ると良いのですが。エラーレスな回線とか。ほぼ尽きないメモリ空間とか。
Re:一日の長はそんなに無い (スコア:2, 興味深い)
ここにぶら下げよう。
ハードウェア故障を想定していないデバイスドライバーがあることに悲しみを感じる。
インテル Centrino Advanced-N + WiMAX 6250 用のドライバーとか。めったに壊れるモジュールじゃないけど。
Re:スキルを仕入れるソ~スが以前とは違ってきてる (スコア:2, 興味深い)
10年ほど前だったか、 apacheのログを処理するperlスクリプトで月例処理をしていたのですが、年度末に1年分のデータをまとめて喰わせたら死にました。 データ全体を一旦メモリ(配列)に読み込んでから処理するというロジックだった。ん100万円のサーバー機ですらメインメモリ1GB積むのが贅沢だった時期です。1年分のログは2GBくらいあったかなぁ。とにかく、サーバに搭載した物理メモリ量より大きかった。