80年代に全盛期だった元プログラマが復活を果たすには 138
ストーリー by soara
まずは修造botに tweetしてみるのがいいんじゃないかな 部門より
まずは修造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諸兄方ならどんなアドバイスを送る?
80年代から比べると (スコア:5, 興味深い)
80年代からずっとプログラマを続けている私としては、今の環境はかなり楽だと思います。
GUIと言っても、ほとんどはデータの入力で、ある意味3270と変わらないし、ライブラリが豊富な分ずっと楽です。
言語はオブジェクト指向化したと言っても、それ以前の言語でも、きっちりしたモジュール化の概念を持っていれば、本質部分は何も変わりません。
80年代より厳しい部分があるとすれば、仕様が思いっきり膨らんだときに、マシン性能の限界を盾に断る事ができなくなってきた事かな。
まあ、昔に比べて、マシン性能は信じられないくらいあるので、メモリ節約とかのバッドノウハウは必要ないので(それはそれで面白かったですが)、プログラムの本質部分に集中できるので気持ちいいですね。
なんと言っても、80年代と最も違うのは、インターネットの発達とオープンソースが多くなった事によって、参照できるソースの量が莫大になった事ですね。多少、リファレンスが不親切でも、ある程度使われているものならちょっと探せば使い方が出てくるし、オープンソースならソースを読めばよいというのは本当に有り難い。
昔は、いろいろ自分で書いてみて、動作を調べるとか、場合によっては、逆アセンブルは日常茶飯事。(Z80は頭の中に裏レジスタまで考慮に入れながら、ダンプ見ながら人間トレースとか、ある程度ですが、出来るようになりました。家の納戸の奥の方に、もしかしたら、手書きのX1 TurboのROMのリストがあったりして。)
もちろん、長い間はなれていると勘を取り戻すのに、多少時間がかかりますが、プログラミングの本質がわかっている人には、割合簡単に勘は復活しますね。
Re:80年代から比べると (スコア:2)
メモリ節約とかのバッドノウハウは必要ないので(それはそれで面白かったですが)、プログラムの本質部分に集中できるので気持ちいいですね。
メモリ節約って、プログラムの本質的部分だと思うんだよね。使用するメモリの量で計算量の上限を見積もることも可能なのだし。
って、富豪的プログラミング [srad.jp]を紹介しておいてナンですが(笑)。
プログラミングの本質がわかっている人には、割合簡単に勘は復活しますね。
自転車に乗るようなもんですかね。
Re:80年代から比べると (スコア:2, すばらしい洞察)
当時の1バイトを削る「バッドノウハウ」は全く別物。
「バッドノウハウ」は元コメにあるように、それはそれで面白いけど。
Re:80年代から比べると (スコア:2)
> 当時の1バイトを削る「バッドノウハウ」は全く別物。
まさにその通りです。バンク切り替えで1バンクのサイズが16Kとかで…
> 「バッドノウハウ」は元コメにあるように、それはそれで面白いけど。
もう、2バイトとか節約できた時、むっちゃ快感。
Re:80年代から比べると (スコア:4, おもしろおかしい)
> もう、2バイトとか節約できた時、むっちゃ快感。
思いついたんだけど、年を表すのって10進4桁じゃなくても10進2桁で十分じゃね?
Re:80年代から比べると (スコア:1)
〜後悔先に立たず・後悔役に立たず・後悔後を絶たず〜
Re:80年代から比べると (スコア:2, おもしろおかしい)
この人のソースは読み辛そうだ
楽勝です (スコア:5, すばらしい洞察)
第一線のエンジニアという言が真ならば、今時のプログラムなんて楽勝です。
GUIだってネットワークだってLLだって、一皮向けばC言語とアセンブリの世界に突入です。
ゼロから始めた初学者がJavaで「同じ単語を格納したstringの比較が真にならない」件で悩んでる間に、
たぶんJavaに加えてP*言語ぐらいはマスターできてるんじゃないかな。
きちんと基礎の基礎が身についてる人っていうのは、応用習得はびっくりするぐらい早いもんです。
私の実例でも、Cとアセンブリしかやってこなかった人が、わずか1週間で、経験3年の奴に勝るとも劣らない
C#コードを書いていましたよ。さすがにOOな所は厳しかったけど、delegateやクロージャをばりばり使いこなしてました。
もちろん今時の、オープンフレームワークを切り貼りするプログラムについては
数多のライブラリを時間をかけて1つ1つ知っていくしかないのだけど、それは必要になったときにすれば充分じゃないかと。
あ、でもC++には近づかない方がいい。あれを真に使いこなすには少なくとも10年かかる。
Re:楽勝です (スコア:1, 荒らし)
Javaに加えてP*言語
p-System [wikipedia.org]のことかー!
Re:楽勝です (スコア:1, すばらしい洞察)
雑誌広告みたい・・・
一週間そこらで3年もC#書いてたやつに追いつくとは思えん。
Re:楽勝です (スコア:2)
嘘くさいけど実話です。
C -> C# だから文法的には親和性が高いというのも大きいと思います。
さらに付け加えるなら、GtkというCによるOO実装なるものを使いこなしていた方だというのも
あるかもしれません。
あと本人は凄く優秀な方でしたが、比較対象の3年目若手がタコだという可能性も低くないかも ;-p
これは私が個人的に思うことなんですが、今の言語の進化ってのは、
C言語プログラマの中でも熟練者のみ書けた「美しいコード」を誰にでも実現できるように進化してきた、
とも言えるのでは無いかと。
であれば元から「美しいコード」が書ける人なら、Cでない言語の、言語設計者の気持ちが判る。
だから、どんな言語でもその本質を理解しやすくなる、ということでは無いかなと勝手に思っています。
Re:楽勝です (スコア:2, 興味深い)
Re:楽勝です (スコア:1)
そいや、Cでも
char foo="foo";
char bar="foo";
がコンパイラの設定によってfooとbarが同一アドレスになったり非同一アドレスになったりするケースがありますな。
# 定数なのにどっか(外部DLLとか)で書き換えらされてて、関係ないはずのモジュールが巻き添えになったりとか・・・
Re:楽勝です (スコア:1)
Re:楽勝です (スコア:2, 参考になる)
それだけだとaがnullの場合にNullPointerExceptionを投げるので、
以下のようにする場合もあります。
if((a == null) ? (b == null) : a.equals(b)) {...}
あるいは、こういうのを定義しておいて、
public static boolean eq(Object lhs, Object rhs) {
return (lhs == null) ? (rhs == null) : lhs.equals(rhs);
}
こうするとか。
if(eq(a, b)) {...}
手段の目的化(残念ながら無理でしょう) (スコア:4, 興味深い)
それ自体が目的であると言っている時点で、残念ながらこの人はある種の迷宮に
入り込んでいると思う。このままじゃ無理です。
それこそ Android 端末でも何でもいいから「自分がほしい小物ソフト」を
一つ作れば、それをもってプログラマとして復活なのでは。
別にWindowsでもなんでもよいから、ほしい機能を実装するために何が最適か
しらべて、開発環境を入手して、って、そこからだと思います。
膨大なライブラリと言ったって、自分がやりたいことにつながってるものは
そんなに多くない。
欲しい物が無くなるような涸れ方をして、知識欲を失ったときが
プログラマ/エンジニアとしての終わりなんじゃないかと思っています。
ショック療法 (スコア:3, おもしろおかしい)
納期まで残り2カ月を切ったダメプロジェクトのデスマーチに放り込む。
@却下
Re:ショック療法 (スコア:1)
序に
「ユーザー認証がWindowsのActiveDirectoryで引っ張ってきて特定権限の判定が必要とか」
「Windows向け業務アプリを移植しないといけない」とか
「しかも当然、仕様書なしor改定されてなく誤植だらけ・動作と一致しない」
とかいう素敵オプションも追加しましょう!
# ユーザーが作ったうえに退職済みで怒りをブツケル訳にも行かず更に(精神的な)過酷度Up!
後は
「よくわからないけどiPhoneとか、iPodとかいうの?にも対応しておいて。」
「なんか最近風の便りで聞いたあんどろいど?とかいうのにも。」
「ネットスケープ4.Xにも対応して。」
とか。
# 実話じゃないですよ?
ググりかたを覚える (スコア:2)
ググれば大抵やりたいことのサンプルコードが大抵出てくると思います。
うそや古い情報も混じってるので見分けてね。
本当に知りたい事は (スコア:2, 興味深い)
この老人は、どうして戻って来ることになったんだ?
どうすればいいか判らないなんて言ってる時点で、
自分の意思ではないんでありましょう?
FORTRAN、COBOLはまだ売れる (スコア:2)
現役で動いているシステムはたくさんあります。
メンテナンスが必要なときは、退職した人を呼び出して支援してもらっています。
そんな状況ですから、探せばFORTRAN、COBOLで食っている会社はあると思います。
それと、開発に精通した人なら、他の言語の習熟は大した手間ではありません。
過去の常識や栄光を忘れれば、一週間くらいで書けるようになります。
概念を翻訳するのは良くない? (スコア:2, 興味深い)
かなり一般論ですけど、歳を取った人、他分野で既に一定のスキルや知識がある人が
未経験の分野に手を出すと、その分野の概念を
今まで自分が居たところの概念フレームワークに勝手に翻訳して理解するということをやってしまうことがよくあります。
そうすると表面上は理解したような感じになるんですけど、
なんか微妙にずれた感じになっちゃうんですよね。
例えばこの人の場合で言うんなら
「これはCOBOLで言う○○だね」「アセンブラで言うところの○○だ」
とか勝手に早合点しないで、新しい概念に先入観なしでどれだけ裸で向き合えるかがカギじゃないでしょうか。
まぁプログラミングの分野は言語間で共有されている概念が多いですし、
昔から変わらない仕組みも多いのでマシな方なんですけどね。
魔法の使い方を覚えるのが先決 (スコア:2)
他の方も言われていますが、筋金入りのプログラマーであればアルゴリズムや組み込みなどコーディングに関して問題はないでしょう。むしろ楽になっているはずです。
# 戸惑うだろうが、習得は非常に楽なはず。
その為、現代の必須技法である「魔法」を覚えるのが良いと思います。
何の冗談でもなく「魔法のような体験」は技術の一種です。
酷く単純な例ですが、iPhoneに最初から入っている「電卓」は、起動時は数値の表示窓が暗いです。明るくなれば入力可能になる。しかし、起動時に見えているのは実際には単なる画像です。
その手の「本来はもっさりしている部分を、そう感じさせない」というのは技術の一種です。
# これはAppleの専売特許ではなく、例えばPlayStationのFF7戦闘開始シーンなどはあの手の技術の究極でしょう。
この手の体感速度を錯覚させる手法が使えるかどうかが、現代では重要になってきているかと。
Re:魔法の使い方を覚えるのが先決 (スコア:1)
尊敬するんだが・・・ (スコア:2)
80年代、様々な方面でバリバリやっていた人って尊敬する。
パソコンだったら、もうハードのこと全部わかって、機能を絞り出すように使っていただろうし。そのときのノウハウを、今の高級言語に当てはめたら、とんでもないレベルでのコードが書けるんじゃないか、と思う。
以前、libgdによる画像の自動生成をやったけど、言語が変わっただけで、やっていたことはPC-88時代のドットを打つ作業(Oh!PCや、ざべに投稿画像があった、アレ)と変わらなかった。
ローテク・錆び付いた技術(とそれに伴う経験)こそ、逆にハードウエアリソースが充実している今、求められているんじゃないかな?と思う。
#一方的な見方してます?
-- gonta --
"May Macintosh be with you"
言語よりもフレームワーク (スコア:2, すばらしい洞察)
の方が習得が大変だと思うです。
はっきり言えば、JavaやC#やPHPなんて簡単です。オブジェクト指向は、初めてだとちょっと躓くかもしれませんが、使っていればすぐ慣れます。
.
それよりも、J2EEとか、Strutsとか、ASP.NETとか、WindowsFormsとか、なんとかPHPとか、なんとかonRailsとか、言語そのものは簡単だけど、「言語に付随する周辺技術」の方が難儀します。フレームワークの流儀に馴染んでくるのに何倍も時間を食われる気がします。
移植 (スコア:1, 参考になる)
高級言語は楽だが (スコア:1, 参考になる)
低級言語のアセンブリ言語より今の高級言語の方が言語的にはかなり楽。
ただし
一つの事だけで完結するシステムではなくて複数の物を組み合わせる必要があったりするね。
・データ保存
XMLやDB(SQL)。
・UI設計
Web系ならHTML+CSS+JavaScript。通常のOSアプリにしてもGUI設計のためにリソースエディタを使いこなさないといけない。
さらにはそのUIとしてのユーザビリティも考慮に入れる必要も
・開発環境
そもそもIDEの使い方も複雑になってきているからそれを覚える必要もあったりね。
言語の説明ではなくてIDEの説明の本すら出ていますからね。
Eclipseなんて何冊も出ているし
Visual Studioにいたって各言語の本を買ってきても本の大部分でIDEの使い方中心で言語の説明は少ないって事も
Re:高級言語は楽だが (スコア:1, すばらしい洞察)
なにそれ、おいしいの?
くだらん、と思ったけど、Makefile の書き方を学んだり、 configure をだます bad know how を考えたりするのと大して変わらないことに、 今気づいてしまった。
Re:高級言語は楽だが (スコア:1)
> Eclipseなんて何冊も出ているし
と言いつつ、大半は超初心者向けの気も………。
エディタはEmacsキーバインド、ビルドはant、デバッグはアサートとロギングみたいな使い方でも、
開発者としては特に問題ないと思いますね。むしろそっちの方が生産性は高かったりするし。
唯一、昔と明らかに異なるのはリファクタリング機能くらいだけど、綺麗なコードを書ける人に
とってはそんなに難しい機能でもない。
小手先よりも (スコア:1, 興味深い)
とにかく、ネットワークに関して調べまくるべき。そこが一番違う。
言語とかそういうのは、基本変わってない。昔書いたのがスパゲッティばっかじゃなければ通用する。
どれを選べばいいかは、現状を調べてるうちにわかる。
初心者になるのを恐れない (スコア:1, すばらしい洞察)
自分が知っている言語、プラットフォームならできることが、新しい環境では勉強しないとできない。
なぜ玄人の自分が勉強しないと理解できないの?
それは新しい環境が糞だからだ!
文章にすると馬鹿としか思えませんが、実際そういう人は多いですし自分もそうなってしまうことがあります。
他人はともかくとして、新しい知識や概念を積極的に取り入れていきたいものです。
習うより慣れろが基本ですね (スコア:1)
勉強しようと思うのではなく、とにかく、使ってみて
慣れてしまうことです。
かく言う私は、80年代は、6809のアセンブラーを作ったりしていた
単なる生意気な学生でした。
Re:習うより慣れろが基本ですね (スコア:1)
6809のアセンブラーを作ったりしていた単なる生意気な学生
アドレッシングモードの豊富な6809のアセンブラを作れるんだったら、たいしたもんだ。単なる生意気じゃないと思うなあ。
アセンブリ言語でプログラミングする程度のことなら、大したことはないけど。
Re:習うより慣れろが基本ですね (スコア:1)
生意気でしょ。
システムも女も同じ (スコア:1)
言う事きかせたければ、相手のことを理解してから命令の仕方を覚えればいい
--
#プラットフォームを理解せずにプログラム組んでるやつは3流
組み込みなら (スコア:1)
今でもメガデモ的なカリカリチューンが現役ですから。
第3回 : 8bitマスク生成 その2 [aya.or.jp]
Windowsなのに、APIをアセンブリレベルコールとか。
ARMやCortex-M/Aなど組んでいると、スリープ・ハイパネーションモード遷移の
割合をいかに増やすかで、電池持ちにものすごく効くからな。
そういう考えは80年代プログラマの方が強いと思ってみたり。
#メモリクリアなどはリピート命令やブロック命令使うよりスタック命令使うのは基本
Re:組み込みなら (スコア:1)
>それは10年も前の記事で、しかも車輪の再発明だし。
>今日日そんな木を見て森を見ないのは流行んないよ。
貴女はコイン電池1個で10年持たせるモニタリング機器とか、
5~7年も電池で待機し、いざという時は300Jのパワーを
放出できる街中のAEDとか、そういうの勉強しなおした方がいい。
内部のプログラミングとか、使用しているCPU、周辺の使い方など。
その記事自体は考え方の例を引用しただけ。
#こういった脊髄反射コメントが返ってくるのは夏休みだからなのでしょうね。しょうがないか
Re:組み込みなら (スコア:1)
>AEDがどうたらって、つっこまれてからあわてて考えた後出しだろ、どうせ。
つ「ARMやCortex-M/Aなど組んでいると、スリープ・ハイパネーションモード遷移の
割合をいかに増やすかで、電池持ちにものすごく効く」
きっと思い通りにいかないと思う (スコア:1)
プログラムの状態を文字列に持たせて、各サブルーチンでパースして状態変化させたり。 今だと当たり前に提供されている連想配列とかを、自前のバブルソートのライブラリで持ってたりとか。 COBOLのプログラムで、連想配列をファイルのレコードに実現して、挿入法でソートしたり、毎回馬鹿サーチするプログラムは見たことがある。
当時覚えなければならない言語仕様と、今覚えなければならない言語仕様の量が全然違うので、昔の感覚だと現代風の言語を覚えるのは骨なんじゃないかなぁ……
-- 哀れな日本人専用(sorry Japanese only) --
Re:マジでキチガイ (スコア:2, 興味深い)
人月100万を遥かに割り込む「SE」は酷かったよ。作業マニュアルに手順を1~10まで書いてその通りやればいいようにしてあることを、遂行できない。10の仕事をやらしたら、1~2は手順をすっ飛ばしてくれた。
ってのは10年前の経験なので、今ではデフレで何割か値下がりしてるかもしれない。
某国産メインフレーム・メーカーの子会社の話 (スコア:2, 参考になる)
をしたことがありますが、1人/月100万円って、いわゆる「SE」より下のク
ラスの人員の単価でした。
だいたい、どこも150万くらいだったけど、一社だけ250万というところがあ
りました(某国産メインフレーム・メーカーの子会社)。
その会社が作業していたシステムは、私の前任者が契約していたところだったけど、
計画よりも1年半以上も本稼働が遅れていた上に、性能も十分に出せず、と
いうところで、マシンの能力が足りないんじゃ?と訊くと、「ソフト会社な
ので、プログラムの改良で性能を出します。キリッ」とかいいつつ、本稼働も
性能確保も遅れに遅れというところでした。結局、私が担当していた三年間
では、当初の計画を実現できなかったですね。あとからサーバのメモリを増設
して性能は確保できたけど・・・。
それ以来、その某国産メインフレーム・メーカーの関連会社は信頼しないこ
とにしてます。
まあ、公共系に強いところなので、そのあとも何回かユーザーの立場ので関
わっていますが、そのたびに基本的なところで「なんだ、これ?」という事例
に出くわしてます。
なんか、プライドが高いし、費用も高い割に内容が伴っていない感じですね。
個人的にはIBM系、NEC系はユーザーのことをバカにしないで話を聞いてくれる
と感じてます。
Re:マジでキチガイ (スコア:2, すばらしい洞察)
Re:マジでキチガイ (スコア:1)
私、こういうの好きです。
コンサルティングマネージャが紺色の猿だったとは、目から鱗です。
ただ歳を取っただけで自分が偉いと思い込んで説教らしきことをする人は
私の職場にも居ますね。
アークトゥルスのタイニの港町の宿にいたおじさんみたいに
薄っぺらな体験談を、さも、得意げな冒険譚として語ってくれる。
これにファンクラブが出来たりして、もう、よもすえ状態です。
Re:マジでキチガイ (スコア:1, 既出)
スキル無いのにSEやんなよ、アナリストやるなよ。<<略>>程度の人間が人月100万とか提示するなって
SEとかアナリストとかコンサルタントとかの単価としては安すぎる気がするんですが。
文句は適正価格を支払ってから言った方がいいんじゃないかと。
Re:マジでキチガイ (スコア:1, 参考になる)
という意味ね。
Re:マジでキチガイ (スコア:1)
Re:マジでキチガイ (スコア:1)
Re:gdgd 言ってないで書け (スコア:1)
どれが一番金を貰えそうか、gdgd 言ってないで書け。
Re:gdgd 言ってないで書け (スコア:1, すばらしい洞察)
報酬を貰えるかはともかく、マスターする方法はただ一つ。
プログラムを書くこと
何をするかは自分で決められるだろう。現代のプログラミング言語は目的別に細分化されていて、目的が分からなければ決められない。
敢えて挙げるならば、C→C++でプログラミングをやればよい。C言語は古いし、OSのカーネルの記述から、コマンドまで作れる。
主流ではないが今でも現役だ。その延長上にC++があると思えば良い。「より良いC言語」から「オブジェクト指向言語」まで
いくらでもハマることができる。汎用性があるので、GUIでも、デバイスドライバでも、ネットワーク系ソフトでも作れる。面倒だが。
目的がはっきりしていれば、絞れるだろう。
GUIならばJava。あるいは簡単なものならVBでも良い。(もちろんCやC++)
文字列操作なら、Perl。WebならPHP。データベースならSQL。
他にもpython,rubyなどいろいろある。逆に自分で調べられないなら、おそらく何をやっても大したことはできない。