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

80年代に全盛期だった元プログラマが復活を果たすには 138

ストーリー by soara
まずは修造botに tweetしてみるのがいいんじゃないかな 部門より

あるAnonymous Coward 曰く、

本家/.「How Can an Old-School Coder Regain His Chops?」より。

80年代の自分は第一線のソフトウェアエンジニアであった。ALGOL、FORTRAN、COBOL、Pascal、と何十万行というコードを書き、370アセンブラや8080アセンブラを使い、プレRDBMSを触ったりもしてきた。

自分がプログラマーではなくなったのは、設計者かつアナリストとしてフリーランスで独立した頃だろうか、90年代初期には完全に引退していた。 今またこの世界に再び足を入れようとしているのだが、最近の言語やプログラミングツール、コンピューティング環境にはてんで疎くなっている。C++やPHP、Java、HTML5、PERLなどどうやって手をつければいいのかお手上げだし、どんな時にどの言語を選べばいいかだって検討つかない。

GUI以前の時代のプログラマーがブランクを経てまたスキルを身につけようとしているのは私だけではないと思うのだが、どうやってWindowsや iOS、Android時代のスキルを身につけることができるだろうか?

ちなみに本家/.では「スキルアップする必要はないのでは? COBOLや FORTRANを使っているシステムはまだあり、プログラマーは少ない」といった意見や「まずその『どこから始めればいいか分からない』という年寄りくさい態度を改めるべき」といった辛辣な(?)アドバイスなどが寄せられている。

/.J諸兄方に同じような道を辿った方はいらっしゃるだろうか? また、/.J諸兄方ならどんなアドバイスを送る?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by manmos (29892) on 2010年08月07日 10時44分 (#1806371) 日記

    80年代からずっとプログラマを続けている私としては、今の環境はかなり楽だと思います。

    GUIと言っても、ほとんどはデータの入力で、ある意味3270と変わらないし、ライブラリが豊富な分ずっと楽です。
    言語はオブジェクト指向化したと言っても、それ以前の言語でも、きっちりしたモジュール化の概念を持っていれば、本質部分は何も変わりません。

    80年代より厳しい部分があるとすれば、仕様が思いっきり膨らんだときに、マシン性能の限界を盾に断る事ができなくなってきた事かな。
    まあ、昔に比べて、マシン性能は信じられないくらいあるので、メモリ節約とかのバッドノウハウは必要ないので(それはそれで面白かったですが)、プログラムの本質部分に集中できるので気持ちいいですね。

    なんと言っても、80年代と最も違うのは、インターネットの発達とオープンソースが多くなった事によって、参照できるソースの量が莫大になった事ですね。多少、リファレンスが不親切でも、ある程度使われているものならちょっと探せば使い方が出てくるし、オープンソースならソースを読めばよいというのは本当に有り難い。
    昔は、いろいろ自分で書いてみて、動作を調べるとか、場合によっては、逆アセンブルは日常茶飯事。(Z80は頭の中に裏レジスタまで考慮に入れながら、ダンプ見ながら人間トレースとか、ある程度ですが、出来るようになりました。家の納戸の奥の方に、もしかしたら、手書きのX1 TurboのROMのリストがあったりして。)

    もちろん、長い間はなれていると勘を取り戻すのに、多少時間がかかりますが、プログラミングの本質がわかっている人には、割合簡単に勘は復活しますね。

  • 楽勝です (スコア:5, すばらしい洞察)

    by ikotom (20155) on 2010年08月07日 11時05分 (#1806386)

    第一線のエンジニアという言が真ならば、今時のプログラムなんて楽勝です。
    GUIだってネットワークだってLLだって、一皮向けばC言語とアセンブリの世界に突入です。
    ゼロから始めた初学者がJavaで「同じ単語を格納したstringの比較が真にならない」件で悩んでる間に、
    たぶんJavaに加えてP*言語ぐらいはマスターできてるんじゃないかな。

    きちんと基礎の基礎が身についてる人っていうのは、応用習得はびっくりするぐらい早いもんです。
    私の実例でも、Cとアセンブリしかやってこなかった人が、わずか1週間で、経験3年の奴に勝るとも劣らない
    C#コードを書いていましたよ。さすがにOOな所は厳しかったけど、delegateやクロージャをばりばり使いこなしてました。

    もちろん今時の、オープンフレームワークを切り貼りするプログラムについては
    数多のライブラリを時間をかけて1つ1つ知っていくしかないのだけど、それは必要になったときにすれば充分じゃないかと。

    あ、でもC++には近づかない方がいい。あれを真に使いこなすには少なくとも10年かかる。

    • by Ryo.F (3896) on 2010年08月07日 12時10分 (#1806408) 日記

      Javaに加えてP*言語

      p-System [wikipedia.org]のことかー!

      親コメント
    • Re:楽勝です (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2010年08月07日 19時02分 (#1806528)

      雑誌広告みたい・・・

      一週間そこらで3年もC#書いてたやつに追いつくとは思えん。

      親コメント
      • by ikotom (20155) on 2010年08月09日 13時49分 (#1807090)

        嘘くさいけど実話です。
        C -> C# だから文法的には親和性が高いというのも大きいと思います。
        さらに付け加えるなら、GtkというCによるOO実装なるものを使いこなしていた方だというのも
        あるかもしれません。
        あと本人は凄く優秀な方でしたが、比較対象の3年目若手がタコだという可能性も低くないかも ;-p

        これは私が個人的に思うことなんですが、今の言語の進化ってのは、
        C言語プログラマの中でも熟練者のみ書けた「美しいコード」を誰にでも実現できるように進化してきた、
        とも言えるのでは無いかと。
        であれば元から「美しいコード」が書ける人なら、Cでない言語の、言語設計者の気持ちが判る。
        だから、どんな言語でもその本質を理解しやすくなる、ということでは無いかなと勝手に思っています。

        親コメント
  • 「プログラマとして復活」というのは何かを果たすための手段であって、
    それ自体が目的であると言っている時点で、残念ながらこの人はある種の迷宮に
    入り込んでいると思う。このままじゃ無理です。

    それこそ Android 端末でも何でもいいから「自分がほしい小物ソフト」を
    一つ作れば、それをもってプログラマとして復活なのでは。
    別にWindowsでもなんでもよいから、ほしい機能を実装するために何が最適か
    しらべて、開発環境を入手して、って、そこからだと思います。
    膨大なライブラリと言ったって、自分がやりたいことにつながってるものは
    そんなに多くない。

    欲しい物が無くなるような涸れ方をして、知識欲を失ったときが
    プログラマ/エンジニアとしての終わりなんじゃないかと思っています。
  • ショック療法 (スコア:3, おもしろおかしい)

    by saab9000 (31344) on 2010年08月07日 10時14分 (#1806363) ホームページ 日記
    C++やPHP、Java、HTML5、PERLを万遍無くプラットフォーム(言語の)として採用した、
    納期まで残り2カ月を切ったダメプロジェクトのデスマーチに放り込む。

    @却下
    • by kei100 (5854) on 2010年08月07日 23時45分 (#1806610)

      序に
      「ユーザー認証がWindowsのActiveDirectoryで引っ張ってきて特定権限の判定が必要とか」
      「Windows向け業務アプリを移植しないといけない」とか
      「しかも当然、仕様書なしor改定されてなく誤植だらけ・動作と一致しない」
      とかいう素敵オプションも追加しましょう!
      # ユーザーが作ったうえに退職済みで怒りをブツケル訳にも行かず更に(精神的な)過酷度Up!

      後は
      「よくわからないけどiPhoneとか、iPodとかいうの?にも対応しておいて。」
      「なんか最近風の便りで聞いたあんどろいど?とかいうのにも。」
      「ネットスケープ4.Xにも対応して。」
      とか。
      # 実話じゃないですよ?

      親コメント
  • ググれば大抵やりたいことのサンプルコードが大抵出てくると思います。
    うそや古い情報も混じってるので見分けてね。

  • by Sukoya (33993) on 2010年08月07日 13時13分 (#1806431) 日記

    この老人は、どうして戻って来ることになったんだ?

    どうすればいいか判らないなんて言ってる時点で、
    自分の意思ではないんでありましょう?

  • by NOBAX (21937) on 2010年08月07日 15時34分 (#1806480)
    ほかの言語は知りませんがFORTRAN、COBOLなら、
    現役で動いているシステムはたくさんあります。
    メンテナンスが必要なときは、退職した人を呼び出して支援してもらっています。

    そんな状況ですから、探せばFORTRAN、COBOLで食っている会社はあると思います。

    それと、開発に精通した人なら、他の言語の習熟は大した手間ではありません。
    過去の常識や栄光を忘れれば、一週間くらいで書けるようになります。
  • by Anonymous Coward on 2010年08月07日 20時29分 (#1806552)

    かなり一般論ですけど、歳を取った人、他分野で既に一定のスキルや知識がある人が
    未経験の分野に手を出すと、その分野の概念を
    今まで自分が居たところの概念フレームワークに勝手に翻訳して理解するということをやってしまうことがよくあります。
    そうすると表面上は理解したような感じになるんですけど、
    なんか微妙にずれた感じになっちゃうんですよね。

    例えばこの人の場合で言うんなら
    「これはCOBOLで言う○○だね」「アセンブラで言うところの○○だ」
    とか勝手に早合点しないで、新しい概念に先入観なしでどれだけ裸で向き合えるかがカギじゃないでしょうか。
    まぁプログラミングの分野は言語間で共有されている概念が多いですし、
    昔から変わらない仕組みも多いのでマシな方なんですけどね。

  • 他の方も言われていますが、筋金入りのプログラマーであればアルゴリズムや組み込みなどコーディングに関して問題はないでしょう。むしろ楽になっているはずです。
    # 戸惑うだろうが、習得は非常に楽なはず。

    その為、現代の必須技法である「魔法」を覚えるのが良いと思います。
    何の冗談でもなく「魔法のような体験」は技術の一種です。
    酷く単純な例ですが、iPhoneに最初から入っている「電卓」は、起動時は数値の表示窓が暗いです。明るくなれば入力可能になる。しかし、起動時に見えているのは実際には単なる画像です。
    その手の「本来はもっさりしている部分を、そう感じさせない」というのは技術の一種です。
    # これはAppleの専売特許ではなく、例えばPlayStationのFF7戦闘開始シーンなどはあの手の技術の究極でしょう。

    この手の体感速度を錯覚させる手法が使えるかどうかが、現代では重要になってきているかと。

  • 80年代、様々な方面でバリバリやっていた人って尊敬する。

    パソコンだったら、もうハードのこと全部わかって、機能を絞り出すように使っていただろうし。そのときのノウハウを、今の高級言語に当てはめたら、とんでもないレベルでのコードが書けるんじゃないか、と思う。

    以前、libgdによる画像の自動生成をやったけど、言語が変わっただけで、やっていたことはPC-88時代のドットを打つ作業(Oh!PCや、ざべに投稿画像があった、アレ)と変わらなかった。

    ローテク・錆び付いた技術(とそれに伴う経験)こそ、逆にハードウエアリソースが充実している今、求められているんじゃないかな?と思う。
    #一方的な見方してます?

    --
    -- gonta --
    "May Macintosh be with you"
  • by paprika (5024) on 2010年08月08日 10時54分 (#1806701) 日記

    の方が習得が大変だと思うです。

    はっきり言えば、JavaやC#やPHPなんて簡単です。オブジェクト指向は、初めてだとちょっと躓くかもしれませんが、使っていればすぐ慣れます。

    .

    それよりも、J2EEとか、Strutsとか、ASP.NETとか、WindowsFormsとか、なんとかPHPとか、なんとかonRailsとか、言語そのものは簡単だけど、「言語に付随する周辺技術」の方が難儀します。フレームワークの流儀に馴染んでくるのに何倍も時間を食われる気がします。

  • 移植 (スコア:1, 参考になる)

    by Anonymous Coward on 2010年08月07日 9時39分 (#1806357)
    過去に自身が作成したプログラムを、現代の言語、ツール類に合うように移植する・・・というのはどうでしょう。その過程で、過去に習い覚えたノウハウの記憶を取り戻すと共に、現代のノウハウを学ぶ、ということで。
  • by Anonymous Coward on 2010年08月07日 9時40分 (#1806358)

    低級言語のアセンブリ言語より今の高級言語の方が言語的にはかなり楽。
    ただし
    一つの事だけで完結するシステムではなくて複数の物を組み合わせる必要があったりするね。
    ・データ保存
    XMLやDB(SQL)。
    ・UI設計
    Web系ならHTML+CSS+JavaScript。通常のOSアプリにしてもGUI設計のためにリソースエディタを使いこなさないといけない。
    さらにはそのUIとしてのユーザビリティも考慮に入れる必要も
    ・開発環境
    そもそもIDEの使い方も複雑になってきているからそれを覚える必要もあったりね。
    言語の説明ではなくてIDEの説明の本すら出ていますからね。
    Eclipseなんて何冊も出ているし
    Visual Studioにいたって各言語の本を買ってきても本の大部分でIDEの使い方中心で言語の説明は少ないって事も

    • Re:高級言語は楽だが (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2010年08月07日 10時50分 (#1806376)

      リソースエディタ

      なにそれ、おいしいの?

      ・開発環境

      くだらん、と思ったけど、Makefile の書き方を学んだり、 configure をだます bad know how を考えたりするのと大して変わらないことに、 今気づいてしまった。

      親コメント
    • by firewheel (31280) on 2010年08月07日 19時28分 (#1806533)

      > Eclipseなんて何冊も出ているし
      と言いつつ、大半は超初心者向けの気も………。

      エディタはEmacsキーバインド、ビルドはant、デバッグはアサートとロギングみたいな使い方でも、
      開発者としては特に問題ないと思いますね。むしろそっちの方が生産性は高かったりするし。

      唯一、昔と明らかに異なるのはリファクタリング機能くらいだけど、綺麗なコードを書ける人に
      とってはそんなに難しい機能でもない。

      親コメント
  • by Anonymous Coward on 2010年08月07日 10時23分 (#1806368)

    とにかく、ネットワークに関して調べまくるべき。そこが一番違う。

    言語とかそういうのは、基本変わってない。昔書いたのがスパゲッティばっかじゃなければ通用する。
    どれを選べばいいかは、現状を調べてるうちにわかる。

  • by Anonymous Coward on 2010年08月07日 11時02分 (#1806383)

    自分が知っている言語、プラットフォームならできることが、新しい環境では勉強しないとできない。
    なぜ玄人の自分が勉強しないと理解できないの?
    それは新しい環境が糞だからだ!

    文章にすると馬鹿としか思えませんが、実際そういう人は多いですし自分もそうなってしまうことがあります。
    他人はともかくとして、新しい知識や概念を積極的に取り入れていきたいものです。

  • 今も昔もプログラミングの基本は、変わりません。
    勉強しようと思うのではなく、とにかく、使ってみて
    慣れてしまうことです。
    かく言う私は、80年代は、6809のアセンブラーを作ったりしていた
    単なる生意気な学生でした。
  • 言う事きかせたければ、相手のことを理解してから命令の仕方を覚えればいい

    --
    #プラットフォームを理解せずにプログラム組んでるやつは3流

  • by wakatonoo2 (30019) on 2010年08月08日 0時30分 (#1806627) 日記

    今でもメガデモ的なカリカリチューンが現役ですから。

    第3回 : 8bitマスク生成 その2 [aya.or.jp]

    1命令減ってますね。

    しか~し、僕はあまりのショックで悔しかったので考えに考えましたですよ。その結果、さらに素晴らしい(おそらく最速)のコードを思いつきました。仕組みは次のとおり。

    (中略)
    簡単ですね。これをコードにすれば、

    (中略)

    これでオッケーです。1命令減りました。 u パイプでしか実行できないシフト命令を減らすことができるのはいーんですが、いかんせん、一つのレジスタに連続でアクセスしなければいけないのがつらいとこです。

    ふと気がつきましたが、ここで書いてる内容って、ペアリングまでしないのなら、言語レベルでも使うことができるんですね~。おお、お徳。上のコードだったら、
    (以下略)

    Windowsなのに、APIをアセンブリレベルコールとか。

    ARMやCortex-M/Aなど組んでいると、スリープ・ハイパネーションモード遷移の
    割合をいかに増やすかで、電池持ちにものすごく効くからな。
    そういう考えは80年代プログラマの方が強いと思ってみたり。

    #メモリクリアなどはリピート命令やブロック命令使うよりスタック命令使うのは基本

  • 80年代だと、俺流のバッドノウハウがイコール飯のタネになってたりしないだろうか? 前聞いた話だと、COBOLプログラマーがCのプログラムを書くと union だらけになるとか。当時は言語仕様の裏ワザとかいろいろ使うのが普通だったし。

    プログラムの状態を文字列に持たせて、各サブルーチンでパースして状態変化させたり。 今だと当たり前に提供されている連想配列とかを、自前のバブルソートのライブラリで持ってたりとか。 COBOLのプログラムで、連想配列をファイルのレコードに実現して、挿入法でソートしたり、毎回馬鹿サーチするプログラムは見たことがある。

    当時覚えなければならない言語仕様と、今覚えなければならない言語仕様の量が全然違うので、昔の感覚だと現代風の言語を覚えるのは骨なんじゃないかなぁ……

    --
    -- 哀れな日本人専用(sorry Japanese only) --
typodupeerror

Stay hungry, Stay foolish. -- Steven Paul Jobs

読み込み中...