パスワードを忘れた? アカウント作成
352043 story
プログラミング

昔のプログラミングスキルは今も大事? 129

ストーリー by hylom
温故知新 部門より

cheez 曰く、

本家/.「What Today's Coders Don't Know and Why It Matters」より。

今日のプログラマーの扱う言語はより進歩しているし、ハードウェア要件だってそれほど厳しくない。

新たにプログラミングの世界に入ってきた人々はハードウェアの制約やハードウェアエラーに慣れておらず、コーディング前の仕様段階から開発していくことや、アセンブリ言語などの低級言語のスキルに長けていないことが多い。時代遅れのスキルかもしれないが、こういった知識や経験が突然必要になることだってあるだろう。

例えば14.4Kbpsのモデム時代にウェブ関連のプログラミングを始めた人々は、ラグの多いワイヤレスネットワーク向けのアプリケーションの開発において始めから一歩先んじていると言えるのではないだろうか?

長年プログラミングに携わってきている/.Jer、比較的新しいプログラマー/.Jer、双方の所感はいかがだろうか。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • ところによって違う (スコア:5, すばらしい洞察)

    by nenaaki (37609) on 2011年08月08日 20時47分 (#1999647)

    例えば、組み込み系でODMなんかだと、チップやメモリの価格と開発費とはバランスを計算しなければいけないし、標準ライブラリすら使用できないC言語で開発なんて事例も多々あります。
    そういう時は古いノウハウが実に実に有効です。

    あとは、Windowsで.NET Frameworkで開発するとしても、下層にはWin32/64やOSの制約が居るので、そんなAPIバイブルな時期のノウハウもデバッグ時に力を発揮するでしょう。

    あるいは、気を付けて作っていてもリリースビルドでのみ発症する不具合などが出た場合、レジスタやスタックやダンプの見かたを理解しているのとそうでない場合とでは、解決までに要する時間は違うかもしれません。もしくは、最適化というもの自体に対する理解は武器ともなりえます。

    最適なアルゴリズムを選択するには、やはりアルゴリズム自体を理解していることは重要でしょう。

    しかし、最近の若者の中にも飲みこみの早い人は多いので、昔我々が苦労した点や注意点を少し伝えれば、要点を理解して同じ轍を踏まないなんてこともよくあるわけで。
    古参のプログラマが一歩先んじている、というのはある面からの事実だけど、我々が消費したのと同じ時間を若者に消費させちゃいけないというのがポイントと思われます。

    ノウハウは継承してゆくものじゃないかと。
    そして、継承した上で次のモノを習得して待ち構えて、いつまでも先輩であり続けてやりたいと思います。

  • by iwakuralain (33086) on 2011年08月08日 22時39分 (#1999719)

    そういう知識があるとなぜか酒の席で話が弾む

  • by Anonymous Coward on 2011年08月08日 21時07分 (#1999668)

    必要な物はのこったし、入らない物は捨てた
    そういうことの積み重ねが経験を積んだプログラマなのであって、新人がいきなりDeepな世界に突っ込まれたら右往左往してもしかたないだろう。

    自分も昔は右往左往したし、そのとき指導できる人は今ほどプログラマ数が多くないが故に少なかったけど、CQ出版と指導してくれた先輩に負けないように新人を導くのが先達になった僕らのしごとじゃないのだろうか?

  • OODBとかXML DBとかいろいろあったけど、
    素のSQLを書かなければならないことは
    この20年間変わらない真実。
    • by matlay (32743) on 2011年08月09日 0時06分 (#1999759) 日記
      ただ、SQLで書くべき部分の境界は結構変わってきてるんじゃないかと思う。
      数万件程度のテーブルの単純な結合を、戯れに全件メモリに読み込んでハッシュでやってみたら、
      処理速度が劇的に上がったのは笑った。

      隣人は、何もかも無理やり1つの巨大なSQL文で済ましているコードに四苦八苦していたりします。
      それは今はいない前任者の残したコードなので、ちょっと気の毒です。

      そういう自分も、動作条件も考えずに、何もかもストアドプロシージャーで書いていた時期もありました。若かった...。
      --
      #存在自体がホラー
      親コメント
  • by manmos (29892) on 2011年08月08日 23時37分 (#1999748) 日記

    通信プログラムをつくるときには、その通信内容が、電気的にどうなっているか、までは問わないけど、イーサネットに流れるビットレベルくらいは想像がつくようになっておけ、とは言ってます。

    プログラムも、概念的にどういうマシン語に落ちるかを理解しておくと、最近のマルチスレッドプログラムとかで、競合や粒度などが直感でわかるようになり、バグは減らせます。

    • by okky (2487) on 2011年08月09日 0時35分 (#1999773) ホームページ 日記

      PCIeが並行して複数のデバイス間データ転送を実行できるとしても、DMAは全部物理メモリ相手なんだから、結局メモリコントローラーの取り合いで衝突するに決まってるだろっ!!

      「PCIe 上に載っているデバイスは高速に応答するから大丈夫だ」って馬鹿かお前は。高速に応答するデバイスに次々とリクエスト投げたら、バスを占有しまくって、周囲のデバイスがDMA転送できなくなるだろうがっ。その、無駄にディレイさせられたデバイス上でバッファオーバーフローを起こしたら何が起こると思ってるんだっ。

      最高パフォーマンスを出したかったら、「速けりゃいい」っていう発想をやめろっ!!!
      インディ500のオーバルコースでさえ、カーブの所ではスロットルを緩めるだろうがっ!! それと一緒だっっ。
      コントロールを失った「高速」はクラッシュの原因でしか無いわっっ!!!

      なんか kbps の世界で痛い目にあって、 Mbps の世界で叫んだのと同じ内容を、Gbpsの世界でも叫ぶ必要があった一昨日…。

      # きっと Tbps の世界でも叫ぶ必要が出るに違いない、と直感した。

      --
      fjの教祖様
      親コメント
    • Re:一応若いもんには (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2011年08月09日 4時12分 (#1999800)

      それって昔のスキルというよりも下位レイヤのスキルの話だよね。

      下位レイヤも知っといた方がいいよ、というのは同意。

      親コメント
  • 若い頃は、開発中の 500行くらいのコードなら憶えていられたものですが…
    記憶だけで、電話口でのデバッグとかやったものです。
    最近はスクリプトレベルのものしか書かないからなあ。

    # もっと古い人だと、「紙テープやパンチカードが読める」とか、
    # 「マシン語の逆アセンブルができる」とかの逸話を聞いたことが
    # ありますが。

    • by nenaaki (37609) on 2011年08月09日 14時25分 (#2000030)

      逸話と言うか、目の前で見てきました。うちの親父がそういうプログラマでした。
      私は二代目プログラマです。幼少期に親父の働く様を見て育っております。

      パンチの入った紙テープのプログラムも読んでましたし、デバッグと称してテープを切断し、別のコードが書かれたテープを切り張りする様などは、今考えるととても古風で、でも新鮮でした。

      磁気記録が使われるようになってからもしばらくは、アセンブラシートに命令を手で書いて、その命令に対応する2進数を作成し、最後に手で16進数変換。
      それを別の人に預けて入力させてから、大抵深夜に端末を借りてデバッグしてました。

      当然ながら、コード表さえあれば逆アセンブルすることもよくありました。

      親父は言います。
      「今はCut&Tryで試せるからデバッグが甘いコードが多い。昔は、バグを出すと次にホストが空くまで1日待たされるから、机上でほぼすべてのデバッグを済ませたもんだが。」

      もちろん、今ほどの規模のプログラムに過去の常識を強要するつもりは本人も無いようですが。
      近年においてはVisualStudioを駆使してエディットコンティニューでさくさくとデバッグしております。

      親父の担当個所は、リリース後の不具合がほぼ出ないので、現役のころの顧客からの信頼はそれはそれは高かった事を覚えています。

      今、親父は還暦プログラマとして、C#でオーディオ系のソフトウェアを書いて余生を送っております。

      親コメント
  • 肉より骨 (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2011年08月08日 20時07分 (#1999632)
    時代と共に流行り廃れる技術より基本的なアルゴリズムや思考方法が財産になる
    あとアドレス・ポインタみたいなコンピューターの基礎の基礎も意外と…
    なんらかの理由で過去のBADノウハウが役に立つ事も無いとは言わないけどね
  • スタート位置が少し前というだけで、
    肝心な部分は一からやる必要があるので履修内容は大差無いかと

    #古い技術を知ってる年寄りよりも、勘の良い新人の方を採用すべきかと
  • 現在一般的なプラットフォーム上で、必要な要件を実現出来る言語であれば予算と期間が許す限り何でも良い
    古い言語とか新しい言語とか全く関係ない

    #つまりどんな言語が使えようとOS/2は許されざるよ!

  • 問題はトラブルが発生したとき。

    障害の切り分けには,現代プログラミングが隠蔽してくれている「プリミティブレベルの動作」の知識がものを言う。

    • >「プリミティブレベルの動作」の知識がものを言う。

      「プリミティブレベルの動作」がトラブルシュートに役立つこと自体は否定しませんが。。

      そもそも「トラブルシュートできる人材」の地位が低下していて
      「プリミティブレベルの動作」の知識も「役に立たないスキル」だったりしませんかね。。。。

      #「プリミティブレベルの動作」を分かって作業している人が「使い捨て人材」
      #だったりすると「プリミティブレベルの動作」なんて知ってても無駄だな、と思われたり。。

      現在だと「トラブルシュート」をする状況を発生させない仕組みを作るほう
      を重視されている気がします。

      だから「トラブルシュート」をする人の評価が下がってる気がするのですがどうでしょうか。

      親コメント
  • by bero (5057) on 2011年08月09日 20時28分 (#2000260) 日記

    プラットフォームが変わる事に歴史を繰り返してるような

    - 省メモリ/高速化のセコテク
    - ハードウェア透過色でなくANDやORを駆使した透過合成
    - 自前3D描画
    などなど

    PC
    Java applet
    iアプリ
    Flash
    Javascript+Canvas

    webアプリで言えば
    SQLDBが使えない環境でファイルやDBMで何とかする -> KVS

  • by Anonymous Coward on 2011年08月08日 19時15分 (#1999609)
    例えば
    DEFINT A-Z
    なんか昔は必須だったけどw
    # 以下ロートルの昔話スレでおながいします
typodupeerror

ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家

読み込み中...