編集元:プログラマー板「90 名前:仕様書無しさん 投稿日:2008/12/17(水) 15:12:15」より 308 以下、名無しにかわりましてVIPがお送りします :2008/12/17(水) 14:19:06.51 ID:BoD9qabUO
もしプログラミング言語が宗教だったら - // TODO: better nameで知ったのだが、Aegisub: If programming languages were religions...という英語のブログ記事が一部で話題になっているようだ。しかし、日本語圏で見た限り、その概要のみしか訳されておらず、詳細は原文参照というものが大半で、おもしろみがわからなかったので、全訳してみた。 なお、以下は単純な翻訳であり、訳注部分を除いて訳者の考えとは無関係である。 (※訳者補記:この記事に対して、「○○という言語の作者は○○教徒」といった下司なコメントやブックマークをつけて嫌がらせをするような下劣な人が出てこないことを祈ります) ■「もしもプログラミング言語が宗教だったら」 Aegisub: If programming languages were religions... 2008年
Monday, December 15, 2008 If programming languages were religions... By amz at 14:52 And now, for some off-topic:"If programming languages were religions" (Inspired by "If programming languages were cars") C would be Judaism - it's old and restrictive, but most of the world is familiar with its laws and respects them. The catch is, you can't convert into it - you're either into it from the start,
本家/.で、「プログラミング言語が宗教だったら?」というブログ記事が紹介されている。 この記事は、「もしプログラム言語が宗教だったら、それぞれはどんな思想を持っているのか」という形で各言語を紹介するもので、「Cはユダヤ教。歴史があり制限も多いが、もっともメジャーではある」「Javaはキリスト教原理主義」「PHPはカフェテリア式のキリスト教」「C++はイスラム教」「Lispは禅」「Perlはブードゥー教」「Visual Basicは悪魔崇拝」などと紹介されている。 もちろんジョーク記事で宗教的意味はまったく無い。タレコミ子はうまく原文を訳せる自信がないので、詳しくは原文をどうぞ。 そのほか、原文では次のように各言語を宗教にたとえて紹介している。 C#:モルモン教 Haskell:道教 Erlang:ヒンドゥー教 Lua:魔術 Ruby:ネオ異教信仰 Python:人間主義 COBOL:古代の
Javaはわりと素朴な言語だ。 Rubyは簡単な英語をちょっと知っていれば分かってしまうくらい易しい。Perlもまぁだいたい同じくらいだ。 Cなんて、小学生でも、ともすれば幼稚園児でも、理解が可能だ。 C++やC#なんかは慣れない人は戸惑ってしまうかもしれないが、実際は素直だったりする。 OCamlは人によって力を入れる場所が違っていたりして混乱しがちだ。それに比べるとHaskellはブレが少なくて意外と易しい。 Pythonは比較的難しい。SchemeはPythonと同程度かPythonより難しい。 Gaucheはかなり難しい。初めて見た人はどうしても間違った判断を下しがちだ。 うん、まぁ名前の読み方の話なんだけど。
シャイで女性エンジニアな貴女! こんな方法を使った愛の告白はいかがでしょうか? 1. ICMP Echo Requestのボディ部分 ICMP Echo Requestのペイロード部分に愛の告白文を挿入して送信してみましょう。 長い文章は1パケットに収まらなくなってしまうので、文章は短く簡潔にまとめましょう。 例えば、「I love you」というメッセージをIPプロトコル番号1番で送信して、彼からのICMP Echo Replyが「I love you too」になっていれば告白成功です。 この方法には注意しなければならない点があります。 「I love you」と書いた文面がそのまま「I love you」と返って来たのを発見してぬか喜びしないようにしましょう。 多くのOSは、ICMPのペイロード部分をそのままコピーして返信します。 そのため、「I love you」と書いて「I lo
via Twitterオタが非オタの彼女にTwitter世界を軽く紹介するための10ユーザ まあ、どのくらいの数のプログラミング言語オタがそういう彼女をゲットできるかは別にして、 「オタではまったくないんだが、しかし自分のオタ趣味を肯定的に黙認してくれて、 その上で全く知らないプログラミング言語の世界とはなんなのか、ちょっとだけ好奇心持ってる」 ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、プログラミング言語のことを紹介するために 習得させるべき10言語を選んでみたいのだけれど。 (要は「脱オタクファッションガイド」の正反対版だな。彼女にプログラミングを布教するのではなく 相互のコミュニケーションの入口として) あくまで「入口」なので、アーキテクチャに過度に依存するアセンブラ等の低級言語は避けたい。 あと、いくら基礎といってもBrainf*ckやUnlambdaのような難しすぎるも
スクラムチームにおける従来からの役割には、プロダクトオーナー、開発者、スクラムマスターがある。明らかに存在していないのが、チームリーダーの役割で ある。チームは、自己管理することが求められる。同様に、オルフェウス室内管弦楽団(リンク)は、チームでリーダーシップを共有して決定を行うというプロセスを支持 し、指揮者の役割を完全に省いた。その結果、世界で最も有名な室内管弦楽団の1つに成長した。その過程でオルフェウス室内管弦楽団は、スクラムチームが利 益を享受できるような連携方法とレッスンを身につけた。 「IEEE Engineering Management Review」(リンク)の最新版には、「The Conductor-less Orchestra(指揮者のいないオーケストラ)」(リンク)というタイトルの記事が掲載されている。これは、「Leader To Leader Journal」(リ
筆者が現役技術者だった頃はプログラミングは創造的で非常に楽しいものだった。サービス開始直前の相当な忙しさは今も昔も変わらないが、少なくともモチベーション溢れるエンジニア達の姿があった。40年近くの間に何が変わってしまったのか。わが国に定着する「ウォーターフォール(waterfall)型」の開発スタイルに、その一因を探ってみる。 浜口さんが、ウォーターフォールの問題点を指摘している。そして、反復型開発のマイクロソフト版である同期安定化型も今後は検討すべきだとしている。 一方の同期安定化型に話を戻す。こちらは、ソフトウエアをスモールチーム(3?8人)で開発できる単位に分割し、各チームが同時並行的に設計・コーディングを行っていくスタイルである。毎日あるいは一定の期間ごとに、各チームの生産物を統合してテストを行い、品質の安定化を図っていく。 わが国の市場の大半を占める企業向けの個別システムに対して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く