Twitter icon  facebook icon  rss icon  feedly icon
naglly.com > ソフトウェア開発アーカイブ

【2018年更新】心に響く、プログラム、コンピューターに関する優れた格言、名言

 何度か紹介している下記の"Stack Overflow"は、エンジニアのためのQ&Aサイトです。

 このサイトの、人気があるQAの中で、「great programming quotes(凄いプログラミングの格言)」と言うのがありましたので、その中から、特に心に響いたものを抜粋して和訳します(2018.11.15 追記:リンク切れしていたので、魚拓をリンクし直しました)。

 <余談>記事を投稿しようとしたら、このQAに掲載されている格言とオーバーラップしている全く別の記事を見つけてしまいました。しかも、すでに和訳されている文章がかなりあります。まぁ、ここまで作って、途中でやめるわけにも行かなかったので、このまま投稿しようと思います。今回掲載する訳文については、一応、自ら訳したオリジナルです。</余談>

Hofstadter's Law:
It always takes longer than you expect, even when you take into account Hofstadter's Law.
 ( ホフスタッターの法則:作業は、いつだって予測以上に時間がかかるものだ。ホフスタッターの法則を計算に入れても。)

 格言が再帰してます。

Walking on water and developing software from a specification are easy if both are frozen.
-- Edward V Berard
 (水の上を歩くのと、仕様からのソフトウエア開発は、簡単だ。・・・両方とも凍っているならの話だが。)

 「凍っちゃってる仕様は、作ってもあまり意味が無い。」って話もあるけども。

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
-- Brian Kernighan
 (デバッグ作業は、最初にコードを書くときよりも倍難しい。したがって、自らの知恵を出来る限り振り絞って書いたコードは、その定義上、自分自身でデバック出来ない。)

 何にでも余力は必要。

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
-- Rick Osborne
 (コーディングは常にこう、心がけるのだ。出来上がったコードを最後にメンテナンスするのが暴力的な精神病者で、そして、君の住所を知っていると。)

 コードやコメントに、証拠や個性を残すべからず。

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.
--Tom Cargill
 (初めの90%のコードは、開発時間の90%を占める。残りの10%のコードは、他の90%の開発時間を占める。)

 足したら180%。

 これは、下記の格言からの変形。

The first 90% of the code accounts for the first 10% of the development time. The remaining 10% of the code accounts for the other 90% of the development time."
-- Jon Bentley
 (初めの90%のコードは、開発時間の10%を占める。残りの10%のコードは、他の90%の開発時間を占める。)

 これでも十分、心に響く。

Java is to JavaScript what Car is to Carpet.
 (JavaScriptにとってのJavaは、「カーペット」にとっての「カー」。)

 格言と言うか、ジョークの類かも。

 追加で、下記のサイトからの格言を、いくつか抜粋して訳します。

There are only two kinds of programming languages: those people always bitch
about and those nobody uses.
-- Bjarne Stroustrup)
 (この世には、2種類のプログラミング言語しかない。皆が常に不平を言う言語と、誰も使わない言語。)

 言語に限らず何にでも当てはまる。

The trouble with programmers is that you can never tell what a programmer is doing until it's too late.
-- Seymour Cray
 (プログラマーの困った点は、手遅れになるまで、何をしているか、けして分からないことだ。)

 ぐさり。

Don't worry if it doesn't work right. If everything did, you'd be out of a job.
-- Mosher's Law of Software Engineering
 (うまく行かなくても気にするな。全部うまく言ったら、君の仕事はなくなるのだから。)

 自分(もしくは、誰か)が掘った穴を自ら埋める。これがすなわち仕事。

First, solve the problem. Then, write the code.
-- John Johnson
 (まずトラブルを解決し、それからコードを書け。)

 理想:コードとは、仕様を書き落とした物。

To iterate is human, to recurse divine.
-- L. Peter Deutsch
 (繰り返し処理は人の技。再帰的呼び出しは神の業。)

 再帰は、時に人智を超える。

There is no programming language--no matter how structured--that will prevent programmers from making bad programs.
-- Larry Flon
 (下手なプログラムの作成を防げるプログラミング言語は存在しない。たとえどんなに構造化されていても。)

 そして、構造化されすぎた言語は、誰も使いこなせない。

Writing in C or C++ is like running a chain saw with all the safety guards removed.
-- Bob Gray
 (C言語やC++で書くと言う事は、まるで、全ての安全装置が取り外されたチェーンソーで作り上げるようなものだ。)

 斧とも言う。サーバーを真っ二つに割るくらい酷くなる事も。

Good code is its own best documentation.
-- Steve McConnell
 (優れたコードは、コード自身が最良のドキュメントとなっている。)

 優れすぎたコードは、凡人には理解できない、という話もある。

You can't have great software without a great team, and most software teams behave like dysfunctional families.
-- Jim McCarthy
 (素晴らしいチームなしに、素晴らしいソフトウェアは生み出せない。そして、大部分の開発チームは機能不全の家族のように振舞う。)

 確かに。酷いと家出とか引きこもりなど、発生するね。

If debugging is the process of removing bugs, then programming must be the process of putting them in.
-- Edsger W. Dijkstra
 (デバッグ作業が、バグを取り除く過程であるならば、プログラミングとは、バグを入れ込む過程でないとおかしい。)

 リリースとは、「バグ」を「仕様」に変化させる工程である。

But what is it good for?
-- Engineer at the Advanced Computing Systems Division of IBM, commenting on the microchip, 1968
 (で、それは何に使えるの?)

 苦労すればするほど、元のコンセプトから外れていく。

2009.5.23追記

 コメントでアドバイスいただいた点を一部直しました。ありがとうございます。

 この記事のカテゴリは、ソフトウェア開発, プログラミング です。
このエントリーをはてなブックマークに追加

『なぜ、プログラミングは楽しいのか?』に対する素晴らしい答え

 『なぜ、コンピュータープログラミングは楽しいのか。なぜ、僕を含めプログラミングに携わる人々は、何度も辛い目に遭いながらも、この職種から遠ざかる事が出来ないのか・・・?』

 この問いに対する答えが下記のサイトに載っていました。ここには、プログラミングの本質的な楽しさが書かれています。

 この書籍の日本語訳「人月の神話」はこちらです。

4621066080
人月の神話【新装版】

評価:5つ星のうち4.7 4.7点

著者:Jr FrederickP.Brooks,Jr.,Frederick P. Brooks,滝沢 徹,牧野 祐子,富澤 昇

発売日:2014-04-22

Amazon.co.jpで詳しく見る

 以下、抜粋した引用です。難解な部分もある英語ですが、可能な限り、僕のつたない超意訳も併せて載せます。

Why is programming fun?
 (なぜ、プログラミングは楽しいのか?)

The below is an extract from Fred Brooks' (Frederick P. Brooks, Jr.) book, The Mythical Man-Month. This is one of the best explanations of why programming is so interesting. It touches on all aspects of the mystique of programming.
 (下記は、フレッドブルックス(Frederick P. Brooks, Jr.)の本、題名「人月の神話」から抜粋したものです。これは、「なぜプログラミングがこんなにも面白いのか?」と言う問いに対する理由の中で、最も素晴らしい説明の1つです。それは、プログラミングの神秘的な面、全てに言及しています。)

 ...残りの記事を読む

 この記事のカテゴリは、ソフトウェア開発 です。
このエントリーをはてなブックマークに追加

英語とプログラミング言語はかなり似ていると思う

 今読んでいる本です。

 これまで、簡単な英文法の本と単語だけで英文を読もうと思っていたのですが、いよいよ限界を感じ始めてきたので、この本を手に取ってみました。

 この本は英語の構文を品詞ごとに細かく分類して、理論的に英語を読み進める手伝いをしてくれる本です。普段からプログラミング言語に慣れ親しんでいる、理屈っぽい...いや、理論的思考を持った、IT業界の方々にぴったりだと思います。

 ...残りの記事を読む

 この記事のカテゴリは、ソフトウェア開発, 英語学習について です。
このエントリーをはてなブックマークに追加

現場のSE, PGが思いつかないデスマーチになる根本的条件とは

≫ 現場のSE, PGが考えるデスマる条件とは:アルファルファモザイク

1 仕様書無しさん :2008/06/03(火) 22:07:26

当方1年目の新人です。"デスマ"と言うのを最近知りました。
勉強になると思うので箇条書きかなんかで挙げていただけないでしょうか。

答え
 現場の手が決して届かない上層の政治的な部分から来る、長期的な観点から見て、会社が存続するためにやむをえない事情がある場合に起こりやすい。その辺りがそもそもの根本原因。

 ...残りの記事を読む

 この記事のカテゴリは、ソフトウェア開発 です。
このエントリーをはてなブックマークに追加

『プログラマの慢心。IT業界の現状。』を読んで

はてな匿名ダイアリー

 ...残りの記事を読む

 この記事のカテゴリは、ソフトウェア開発 です。
このエントリーをはてなブックマークに追加