一つ前へ
2011年7月(中旬)
一つ後へ
2011年8月(上旬)
ラジオが欲しい。 モノラル音声出力でもいいので小さめのボディで、SDカードから再生できるやつ。 CDも再生できるような大きいのとかポータブルタイプのはあるんだけど、 前者では大きすぎるし後者は基本的にイヤホン(ヘッドホン)で聴くようなものなので。 どっかにいいのないかなあ。 あ、あと乾電池駆動(充電池でもいいけど)希望。
プログラマー必読本
ONE OUTS 13 (ヤングジャンプコミックス)
とかゆってみる。
なぜかという話もしてみたいのだけどねえ
(実はRubyKaigiからひっぱってる話につながってたりする)。
アニメで続きやってくれないかなあ(途中までしかやってない)。
Ruby の本拠地で行われたプレゼン。 http://mew.org/~kazu/material/2011-haskell.pdf
スライドを見ていて
Haskell で map & reduce zip [0..] [10,20,30,40,50] → [(0,10),(1,20),(2,30),(3,40),(4,50)] map (\(i,x) -> x*i) (上記の式) → [0,20,60,120,200] foldl (+) 0 (上記の式) → ((((0 + 0) + 20) + 60) + 120) + 200 → 400 関数を合成する func = foldl (+) 0 . map (\(i,x) -> x*i) . zip [0..] func [10,20,30,40,50] → 400
この func の定義で、zip って引数二つとるんじゃなかったっけ? としばらく悩んでしまうあたりまだまだである ○|￣|＿
で、最後のページ
お勧めの書籍
プログラミングHaskell
オーム社
Learn You a Haskell for Great Good!
No Starch Pr
翻訳される予定です
Real World Haskell
O'REILLY
おー＞翻訳予定
というか原著買ってるじゃん＞わし
ああ、変更点のまとめがまだ途中
awkについて語るスレ $2 620 デフォルトの名無しさん [sage] 2011/07/30(土) 19:46:15.81 ID: Be: 超初心者の質問で申し訳ありません。以下のようなデータを aaa 10 bbb 20 ccc 30 aaa 30 bbb 30 aaa 15 ccc 30 ddd 20 以下のようにまとめたいのですが、どうしたらいいでしょうか？ aaa 55 bbb 50 ccc 60 ddd 25 621 デフォルトの名無しさん [sage] 2011/07/30(土) 19:53:38.97 ID: Be: ddd 20 ではないかと思うがこんな感じかな awk '{a[$1]+=$2} END {for (b in a) {print b " " a[b]}}' | sort 622 デフォルトの名無しさん [sage] 2011/07/30(土) 23:15:27.52 ID: Be: Gawk4ならPROCINFO["sorted_in"]の設定で最後のsortが要らなくなる 623 620 [sage] 2011/07/30(土) 23:22:20.03 ID: Be: >621 ありがとうございます！うまくいきました。
この質問、C スレだか C++ スレでも見たな。というのはおいといて。 PROCINFO に sorted_in とかいうのあったっけ? と疑問に思ったので調べてみると
Changes from 3.1.8 to 4.0.0
---------------------------
29. If PROCINFO["sorted_in"] exists, for(iggy in foo) loops sort the
indices before looping over them. The value of this element
provides control over how the indices are sorted before the loop
traversal starts. See the manual.
30. A new isarray() function exists to distinguish if an item is an array
or not, to make it possible to traverse multidimensional arrays.
31. asort() and asorti() take a third argument specifying how to sort.
See the doc.
おっと、今回のバージョンアップで入ったものか。 β版で気づかなかった。 asort() と asorti() が追加の引数とるようになったともあるなあ。 「ソートしてからひっくり返せ」で対応できなくなったんだろうか。
で、マニュアルにある PROCINFO の記述。
`PROCINFO #'
The elements of this array provide access to information about the
running `awk' program. The following elements (listed alphabetically)
are guaranteed to be available:
(略)
`PROCINFO["sorted_in"]'
If this element exists in `PROCINFO', its value controls the
order in which array indices will be processed by `for (index
in array) ...' loops. Since this is an advanced feature, we
defer the full description until later; see *note Scanning an
Array::.
`PROCINFO["strftime"]'
The default time format string for `strftime()'. Assigning a
new value to this element changes the default. *Note Time
Functions::.
`PROCINFO["uid"]'
The value of the `getuid()' system call.
`PROCINFO["version"]'
The version of `gawk'.
On some systems, there may be elements in the array, `"group1"'
through `"groupN"' for some N. N is the number of supplementary
groups that the process has. Use the `in' operator to test for
these elements (*note Reference to Elements::).
The `PROCINFO' array is also used to cause coprocesses to
communicate over pseudo-ttys instead of through two-way pipes;
this is discussed further in *note Two-way I/O::.
This array is a `gawk' extension. In other `awk' implementations,
or if `gawk' is in compatibility mode (*note Options::), it is not
special.
11.2.1.1 Array Scanning Using A User-defined Function
.....................................................
The value of `PROCINFO["sorted_in"]' can be a function name. This lets
you traverse an array based on any custom criterion. The array
elements are ordered according to the return value of this function.
The comparison function should be defined with at least four arguments:
function comp_func(i1, v1, i2, v2)
{
COMPARE ELEMENTS 1 AND 2 IN SOME FASHION
RETURN < 0; 0; OR > 0
}
Here, I1 and I2 are the indices, and V1 and V2 are the corresponding
values of the two elements being compared. Either V1 or V2, or both,
can be arrays if the array being traversed contains subarrays as
values. The three possible return values are interpreted this way:
`comp_func(i1, v1, i2, v2) < 0'
Index I1 comes before index I2 during loop traversal.
`comp_func(i1, v1, i2, v2) == 0'
Indices I1 and I2 come together but the relative order with
respect to each other is undefined.
`comp_func(i1, v1, i2, v2) > 0'
Index I1 comes after index I2 during loop traversal.
(略)
11.2.1.2 Controlling Array Scanning Order
.........................................
As described in *note Controlling Scanning With A Function::, you can
provide the name of a function as the value of `PROCINFO["sorted_in"]'
to specify custom sorting criteria.
Often, though, you may wish to do something simple, such as "sort
based on comparing the indices in ascending order," or "sort based on
comparing the values in descending order." Having to write a simple
comparison function for this purpose for use in all of your programs
becomes tedious. For the common simple cases, `gawk' provides the
option of supplying special names that do the requested sorting for you.
You can think of them as "predefined" sorting functions, if you like,
although the names purposely include characters that are not valid in
real `awk' function names.
The following special values are available:
`"@ind_str_asc"'
Order by indices compared as strings; this is the most basic sort.
(Internally, array indices are always strings, so with `a[2*5] = 1'
the index is `"10"' rather than numeric 10.)
`"@ind_num_asc"'
Order by indices but force them to be treated as numbers in the
process. Any index with a non-numeric value will end up
positioned as if it were zero.
(略)
確かに「下手」だけいわれてもどうしろという話ですよねえ。
Coqスレ 81 60 [] 2011/07/31(日) 02:52:02.67 ID: Be: .vへのコピペに飽きてきたので暫定公開。 http://www.randmax.jp/sf/Basics_J.html フォーマットがややオリジナルと異なりますが、二つ理由があります。 1. 僕がCSSを少しいじっているため。主に日本語対応。 2. sfのチームはcoqdocをカスタマイズして使っており、それを入手していないため。 単に「お前の翻訳はヘタ」というような批判は勘弁してください。「手伝ってください」としか言いようがありませんので。 具体的な「ここはたぶん誤解してる。正しくはこう」とか「この単語は普通こう訳す」というようなお話は歓迎します。 ここでやるのが不適切なようでしたら、どこかほかのところに場所を借りてもいいかと思っています。 「オレにもやらせろ」はもちろん「オレにやらせろ」も歓迎です。僕にとって翻訳は趣味でも仕事でもないので、日本語の文書が最初からあるなら（誰かが作ってくれるなら）、僕もそれに乗っかりたいぐらいです。 Pierce先生宛てのメールを書いているときにちょっと手がすべって「これから1章／月ぐらいのペースで翻訳を続けていくつもり」などと書いてしまったので・・・誰か助けて・・・ 82 デフォルトの名無しさん [sage] 2011/07/31(日) 03:28:17.28 ID: Be: >>81 翻訳Webページに、参加方法やリポジトリ閲覧方法や訳文投稿窓口を含めておくと、敷居が低くなるかもしれない。 たとえばwikiのようなものとか。 83 デフォルトの名無しさん [sage] 2011/07/31(日) 07:59:42.65 ID: Be: >>81 > Pierce先生宛てのメールを書いているときにちょっと手がすべって「これから1章／月ぐらいのペースで翻訳を続けていくつもり」などと書いてしまったので・・・誰か助けて・・・ 最初に見栄切ってそれをふうふう言いながらも達成することで人は成長するもんだ。頑張れ。 84 デフォルトの名無しさん [sage] 2011/07/31(日) 12:04:46.18 ID: Be: >>82の案を推す 俺もこのページは読んだことあるから多少は助力できるかも
ここしばらくビルドも試してなければバイナリ配布のを試してもいない○|￣|＿
Rakudo Star 2011.07 released | rakudo.org (略) This release of Rakudo Star adds the following features over the previous Star release: * 10%-30% improvement in compile and execution speed * New gcd (greatest common divisor) and lcm (largest common multiple) operators * Int.base * Call counter for Perl 6-level subroutines * Better handling of &infix:<=> right associativity * Fix bug in exponentiation of negative numbers * Fix building on systems with smaller RAM There are some key features of Perl 6 that Rakudo Star does not yet handle appropriately, although they will appear in upcoming releases. Some of the not-quite-there features include: * nested package definitions * binary objects, native types, pack and unpack * typed arrays * macros * state variables * threads and concurrency * Unicode strings at levels other than codepoints * pre and post constraints, and some other phasers * interactive readline that understands Unicode * backslash escapes in regex <[...]> character classes * non-blocking I/O * most of Synopsis 9 * perl6doc or pod manipulation tools
state 変数がまだというのは意外な気が。
typed array ってなんじゃろ。
Alloyが起こした小さなさざ波を、太平洋をまたいだ日本にも伝えられれば本望です。
事業はサービス業です。顧客の名簿や売上、ＤＭ等の管理をしようと思っています。売られているソフトはけっこう高価なので、 無料の顧客管理ソフトをダウンロードして、仕事に役立てたいと思っています。
今月の日経ソフトウェアでScratchというプログラム言語が紹介されていた。記事を少し読んだだけで、 僕が長年探していたモノだとわかったので早速ダウンロードして使ってみた。果たして、それはまさに僕が長年探していたモノだった。<\
しかし "123".match { ... } でコンパイル通らないのは何故なんだぜ？
なかだ師匠（左）と遠藤師匠（右）に感謝。
Tech Party 2011 とは、全国のコミュニティが合同で 8/20(土), 8/27(土) に勉強会を行い、 USTREAM 中継を通じて連携するイベントです。
PHPのround関数はPHP5.3.0で一新されましたが、その挙動は複雑です。
Steffen Zschaler 氏がソースコード変換という乱暴な方法で C と Java のような全然違った言語でライブラリを共有する話など。
何でも逆に考えてみよう、すると全然別物だと思っていた部品が他の部品の逆向きかもしれないよという話。
イカサマータイムめ…
このスレッド(と呼ぶんだろうか)、どこまで伸びるかしらん。 意外にすぐ止まる気もするけど utf 8 - why is there so much overhead when we decide to use UTF-8 for characters outside the 1-127 range? - Stack Overflow
住めば都のコスモス荘 すっとこ大戦ドッコイダー DVD-BOX
これの発売が今月だったのをすっかり忘れていた。
予約していたので(財布に予約票が入っていて思い出した)、
買ったはいいがいろいろきつい。
この手のアイテムは値段ががくっと落ちて楽に買えるようになるのと
すぐになくなるのと極端だからなあ
(ブラックラグーンの期間限定BOXの2nd、それで買い損ねたw)。
というわけであれとかあれとかあれを諦めたわけですよ(しくしく)。
c++ - move semantics and Lifetime of variables when binding lvalue to rvalues reference - Stack Overflow just to be sure to well understand what is under the hood... questions are in the code as comments
move semantics やら rvalues reference についてはその筋の方々がいろいろ書いているので以下略
Javascript: Multiply and Sum Two Arrays - Stack Overflow I have two arrays of equal length, and I need to multiply the corresponding (by index) values in each, and sum the results.
他の言語でもやってみると面白いかも。
coding style - Should class members be sorted? - Stack Overflow On a new project with a new team, should we enforce to sort the members of the classes automatically in a specific order (e.g. by modifier and alphabet) prior to check-in?
いちいち並べ替えるのはやりすぎですよねえ。
getopt やらの紹介をしないのだろう? 使うのが面倒? どこにあるのかわからない?
C言語 文字列比較 | OKWave WindowsAppのコマンドライン引数はLPSTR型ですよね、コマンドライン引数が～だったら、とい うような条件分岐を作りたいのですが、strcmpは使えません。それで、どうすればいいのか分か らなくなってしまい、質問しました。 WindowsAppではあるけど、コマンドラインオプションを使いたいのですが、どうやって文字列を したらいいのでしょうか？ もしstrcmpが使えたとしたら、こういうことをやりたいのです。 int WINAPI WinMain(・・・LPSTR pCmdLine, ・・・) // pCmdLineはコマンドライン引数です。 { ・・・ // 省略 if(strcmp(pCmdLine,"-s") == 0) { ・・・ } ・・・ return 0; } ・・・は省略です。 このようなことをできる関数はありませんか？質問者が選んだベストアンサー ＞strcmpは使えません。 使えますけど。 どういう理由で使えないと判断したかを分析すると、理解の足りない部分があぶりだされると思います。
長形式はともかくとしても、引数とるのとらないの、とるのは必須かオプションか とかいろいろあるし、ライブラリ使うようにアドバイスすべきじゃないのかなあ。 いっぺん自作するのも勉強になるし。
おや、どこかでF#とかいってる声が聞こえる(ような気がする)
関数型言語ML (SML, OCaml, etc.), Part 6 442 デフォルトの名無しさん [sage] 2011/07/30(土) 19:06:44.85 ID: Be: OCamlにしようか、それともHaskellにしようか迷ってます。 こういう用途ならこっちのほうがいいとか、なんかアドバイスお願いします。 443 デフォルトの名無しさん [sage] 2011/07/30(土) 19:45:47.15 ID: Be: >>442 では、用途を教えてくだしあ 444 デフォルトの名無しさん [sage] 2011/07/30(土) 20:08:56.47 ID: Be: >>443 こーいうやつはプログラミングの勉強自体が目的だろ。 445 デフォルトの名無しさん [sage] 2011/07/30(土) 20:16:25.35 ID: Be: >>444 プログラミングの勉強自体が目的ならhaskell一択 446 デフォルトの名無しさん [sage] 2011/07/30(土) 20:42:08.59 ID: Be: >>444 はい、その通りです。 PHPとJavaとJavaScriptはある程度書けますが、関数型言語をなにかひとつみにつけようと思います。 >>445 よろしければ理由を教えてください。 ぐぐった感じでは、haskellはモナドというのが難しくて多くの人が挫折しているようので、OCamlに傾いてます。 447 デフォルトの名無しさん [sage] 2011/07/30(土) 20:52:58.37 ID: Be: >>446 勉強ってことだし、関数な考え方を得ようってなら純粋なHaskellの方を推奨 448 デフォルトの名無しさん [] 2011/07/30(土) 20:54:22.93 ID: Be: 勉強自体が目的ならなんで両方やらないのっていう 449 デフォルトの名無しさん [sage] 2011/07/30(土) 20:56:02.64 ID: Be: あと入門用に、英語読めるなら、比較的平易な英文で書いてある http://learnyouahaskell.com/ を挙げておきます。下の方にあるonlineを選ぶと、売っているものに近い内容が読めますよ。 450 デフォルトの名無しさん [sage] 2011/07/30(土) 21:05:00.48 ID: Be: OCamlの入門書が1冊、Haskellの入門書が数冊出てるからどれか1つ、 とりあえず借りるか買うかして、それぞれ第1章ぐらいやってみなさい。 451 デフォルトの名無しさん [sage] 2011/07/30(土) 21:05:33.97 ID: Be: >>446 関数型言語の特徴が余す事なく取り入れられてる モナドは使う分には難しくない 使う分にはシンプル イズ ベストな書き方がやり易い言語 モナドを分からないと使えるようにならないと勘違いして脱落する人多いけど、モナドの理論的背景を理解する必要は無い 気になるなら気長に勉強しなされ OCamlはループも有るし、副作用対策諦めてるし、手続き型言語に限りなく近い関数型言語って感じ 速いコード吐けるけど、昨今の関数型言語の特徴取り入れた手続き型言語が多い時代に勉強する意味は薄い 452 デフォルトの名無しさん [sage] 2011/07/30(土) 21:07:10.73 ID: Be: 手続きばっかだっし、古典のschemeでいいんじゃねーの？ 453 デフォルトの名無しさん [sage] 2011/07/30(土) 21:10:08.69 ID: Be: Lisp族はLisp族で悪くないけど、関数型プログラミングを今時勉強するならその選択はない。 454 デフォルトの名無しさん [sage] 2011/07/30(土) 21:16:22.99 ID: Be: >>452 カリー分と遅延評価がデフォルトで付いてない 自分で同じ事を再現とかは出来るけど、それじゃ関数型言語の学習とは違う 455 デフォルトの名無しさん [sage] 2011/07/30(土) 21:20:58.25 ID: Be: >>449 haskellスレで翻訳中って聞いたぞ あと、kindleでサンプル読んだ限りじゃプログラミングhaskellの内容を砕けた言葉とイラストで書いてるだけに見える 内容的にはすでに翻訳されてるプログラミングhaskellで十分 456 デフォルトの名無しさん [sage] 2011/07/30(土) 21:28:52.08 ID: Be: みなさん、ありがとうございます。 OCamlスレなのにHaskell勧める人ばかりなので、OCamlに未練はあるけど、思い切ってHaskellやってみようと思います。 457 デフォルトの名無しさん [sage] 2011/07/30(土) 21:34:22.91 ID: Be: >>456 いや。。。 haskellもMLの子孫なんだが。。。
そういや先週開催されたスタート Haskell の感想とか検索してない。 ちょっと気になるところ。 検索しないでも流れてきたのは見たり読んだりしたけれども。
あと大変申し訳ありませんが、「プログラムはあなたにはまだ無理だ」「そんなに簡単にプログラムは組めない」など批判やお叱りの回答はご遠慮してください。
でたらでたでいろいろ叩かれてる気配。 これもそのひとつ(でも「bug」だっていってるなあ)
Lucid Imagination » Don’t Use Java 7, For Anything Don’t Use Java 7, For Anything Posted by hossman Java 7 GA was released today, but as noted by Uwe Schindler, there are some very frightening bugs in HotSpot Loop optimizations that are enabled by default. In the best case scenario, these bugs cause the JVM to crash. In the worst case scenario, they cause incorrect execution of loops. Java 7 GA が本日リリースされました。しかし、Uwe Schindler が警告したように デフォルトで有効にされている HotSpot のループ最適化に いくつかの frightening bug があるのです。最良のケースのシナリオでは、それらのバグは JVMをクラッシュさせます。最悪のケースのシナリオでは、ループの不正確な実行を 引き起こすのです。 Bottom Line: Don't use Java 7 for anything (unless maybe you know you don't have any loops in your java code) Java 7 を一切のものに使わないように(あなたの Java コードにループが全くないとわからない限りは)。 From: Uwe Schindler Date: Thu, 28 Jul 2011 23:13:36 +0200 Subject: [WARNING] Index corruption and crashes in Apache Lucene Core / Apache Solr with Java 7 Hello Apache Lucene & Apache Solr users, Hello users of other Java-based Apache projects, Oracle released Java 7 today. Unfortunately it contains hotspot compiler optimizations, which miscompile some loops. This can affect code of several Apache projects. Sometimes JVMs only crash, but in several cases, results calculated can be incorrect, leading to bugs in applications (see Hotspot bugs 7070134 [1], 7044738 [2], 7068051 [3]). 本日、Oracle は Java 7をリリースしました。 残念なことに、これは hotspot コンパイラーの最適化に関して 一部のループのコンパイルがおかしいというバグを抱えています。 このバグはいくつかのApacheプロジェクトのコードに影響を及ぼす可能性があります。 ただ単にJVMがクラッシュするだけのこともありますが、一部のケースにおいては 計算された結果が正しくなくなる場合があります。これはアプリケーションの バグにつながるものです。Hotspot bugs の 7070134 [1], 7044738 [2], 7068051 [3] をみてください。 Apache Lucene Core and Apache Solr are two Apache projects, which are affected by these bugs, namely all versions released until today. Solr users with the default configuration will have Java crashing with SIGSEGV as soon as they start to index documents, as one affected part is
盛り上がってる Don't use Java 7 for anything : programming が、
しかしなぜ Pike (この言語については @kinaba さんがきっと何か書いてくれるはずだ :)
Don't use Java 7 for anything : programming Not being a Java or Pike programmer myself I always think that Pike is the language most Java or C# programmers actually would like to use if they knew about it and it was more popular. Just what I think though, everyone should use that language that suits him/her. It's way more straight forward, so you maybe shouldn't use it if you get paid for time or SLOC. I like there tutorial. First program: "Hello world", second one is a web browser. Can we see more of these in other languages? :)http://pike.ida.liu.se/docs/tutorial/data_types/variable_definitions.xml wtf??? Insanity.Wow, this makes Perl look like it was designed by someone sane.Definitely squashes that whole "way more straight forward" rumor.
積読山を捜索。
C言語なら俺に聞け（入門編）Part 87 435 デフォルトの名無しさん [sage] 2011/07/28(木) 23:43:04.75 ID: Be: doubleとかの浮動小数点を扱うときに出る誤差って どんなときに注意するものなんでしょうか？ 1桁の整数の四則演算程度ではまったく気にしなくていいのでしょうか？ 436 デフォルトの名無しさん [sage] 2011/07/28(木) 23:46:14.16 ID: Be: >>434 目的に依る お金の勘定とか、誤差のレベルで利害が大きく出る場合は注意が必要 437 デフォルトの名無しさん [sage] 2011/07/28(木) 23:46:48.20 ID: Be: ｽﾏｿ × >>434 ○ >>435 438 デフォルトの名無しさん [sage] 2011/07/28(木) 23:53:39.83 ID: Be: 1桁の整数の四則演算をdoubleでやると誤差が出ることがあるということでしょうか？ 整数の四則演算なので、誤差があってはいけないレベルだと思ってます 具体的には、4つの1桁の整数を元に四則演算で10にするってやつです 439 デフォルトの名無しさん [sage] 2011/07/28(木) 23:57:01.09 ID: Be: >>438 実装依存です たいていの場合には整数のみを扱う限り１５桁までは誤差がまったくでません 440 デフォルトの名無しさん [sage] 2011/07/29(金) 00:20:12.85 ID: Be: 1/3*3が正しく1になる理由が自分には理解できていないことがわかりました とりあえず誤差は出なさそうなので気にしないことにします ありがとうございます 441 デフォルトの名無しさん [sage] 2011/07/29(金) 00:22:23.26 ID: Be: >>440 その演算順序だと整数のみを扱ってないよ 442 デフォルトの名無しさん [sage] 2011/07/29(金) 00:31:04.57 ID: Be: 1桁の整数の四則演算と言っていたのはこういうののことです 実際にいくつか試しても誤差が出なかったので問題が発生するまで保留にしときます 問題が出てくれたほうがちゃんと理解できそうだし 443 デフォルトの名無しさん [sage] 2011/07/29(金) 00:36:39.86 ID: Be: なぜ宿題スレと並行でやってんの？ 446 デフォルトの名無しさん [sage] 2011/07/29(金) 01:22:53.58 ID: Be: 誤差の話なんだが http://ideone.com/SiEB0 これだと結果EQになってるが 自分の環境（gcc version 4.3.4 20090804 (release) 1 (GCC)）だと NEになる 誤差わけわからんな 447 デフォルトの名無しさん [sage] 2011/07/29(金) 02:21:55.75 ID: Be: >>446 自分gcc使い始めて１日目なので勘違いしてるかもだけど、 EQ : -mfpmath=sse NE : -mfpmath=387 だったよ。(gcc 4.6.2/mingw)
446 のリンク先のコードを見ると 447 のいう動作になるのは 例の拡張精度絡みの話なのですかねえ。
Ideone.com | Online C Compiler & Debugging Tool #include <stdio.h> int main(){ double x,y; x = 1; x = x/9 + 1; printf("%s\n",(x*9==(y=x*9))?"EQ":"NE"); }
最適化オプションによっても変わる?
「我慢して」のところに引っかかった人が割りといて気になったので 原文をあたってみたんですが、どの部分なんだろう…
優れたプログラマになる秘訣は「我慢して他人のコードを読む」 - DailyJS | エンタープライズ | マイコミジャーナル 以前からよく言われていることだが、Alex Kessinger氏が7月25日(英国時間)にDailyJSに投稿し たCode Pollutionという記事がそのあたりの話を端的にまとめていてわかりやすい。より優れた プログラマになる最良の方法は、既存のソースコードを読むことだ、と説明している。 他人のソースコードを読み、そこから新しいアイディアを理解する。ここから新しい視点を得る ことができ、自分のプログラミングに反映できるようになる。基本的に他人のソースコードを読 むという行為は苦痛を伴うことが多い。Code Pollutionではその理由としてYahoo!に在籍してい たときの元上司の「すべてのプログラマが他人のプログラマの成果物を嫌悪するのは、それはお 前がほかのプログラマではないからだ」という言葉を引き合いに出して説明している。
にしても、
「すべてのプログラマが他人のプログラマの成果物を嫌悪するのは、それはお前がほかのプログラマではないからだ」
この訳はないんじゃないかなあ。
原文は
“The reason all programmers hate other programmers' work is because you aren't those other programmers.”
でしょう?
すべてのプログラマーが自分以外のプログラマーの成果物 (work) を嫌うのは、
それが自分で書いたものでないからだ。くらい?
DailyJS: Code Pollution Code Pollution 25 Jul 2011 | By Alex Kessinger (略) There is a lot of code duplication here. Sometimes it's work done without actually making the original much better. So, why are many of us compelled to do this? It's the same reason we have all done it – the common illusion that we can make things better. We will always be able to write a better implementation of that framework, or this library; it's hard to stop listening to those urges. Another reason we create is that learning someone else's code is almost universally distasteful. My first manager at Yahoo explained it best: “The reason all programmers hate other programmers' work is because you aren't those other programmers.” Here is the urge that you need to fight. You need to work with someone else's code a little, and begin to learn their way. Then, maybe, you might find yourself with a new point of view, and we all would have less, but higher quality JavaScript libraries. Yes, it sounds reductively simple, but good ideas should be so. Challenge yourself to figure out why a person wrote code a certain way, and you'll either know why it was a bad idea, or why it's a good idea. Both are a win for you. Before you tell me my position is too hardline: here is the caveat. You can't forget about innocent discovery. I can see someone screaming that a good way to get better at programing is to tackle hard problems, and even if you fail, you will learn something. It's hard to argue with that point, but what I'm talking about is every half-launched project on GitHub that purports to be the fix for every problem people in that domain are having. Registering unfinished projects with package managers eats away at all the meaningful package names. Now, I know there will always be a reason to create. The hard route is to figure out how to use someone else's code. Try it the next time you decide to use a new library or framework. The best documentation is the source code itself. Copyright © DailyJS. | Site Source
他人のコードを読むのが distasteful あたりからきているのかなあ＞我慢
Visual Studioプロジェクト向けのPythonツールの一部として、有名なNumPy と SciPy ライブラリが.NETにポートされた。ネイティブなCコアへのC#とCインターフェースを合わせたもので、全.NET言語が利用できるような方法でポートされた。
今回のParallel Nsight 2.0ではPTXレベルのデバグに加えて、SASSと呼ぶ本当のマシン命令でのデバグ機能が含まれているのが1つの目玉である。
いろいろだめだ
福島第一原発の最高幹部がついに語った【フクシマの真実：前編】
福島第一原発の最高幹部がついに語った【フクシマの真実：後編】
COBOL は実はよく知らないが、昔 COBOL プログラマに「お前は関数を使いすぎる」と怒られたことがある。
かなりガッツリと Prolog の言語仕様のディープなところに触れるような話があって、
訳者からの事情のご説明
または経営者になりたければ、とりあえず「もしドラ」でも読んで、イノベーションの意味を考えてみてください。
Coq とか全然知らないんですが(興味はある)
Coqスレ [chaika] 71 60 [] 2011/07/27(水) 10:44:48.98 ID: Be: 時間があったんで、 Software Foundations http://www.cis.upenn.edu/~bcpierce/sf/toc.html の「Basics」の章を全訳したんですけど、 公開するとまずいですよねぇ・・・・きっと。 巷にもう少し日本語の解説があれば普及も進むのでは ないかと思うのですが。 72 デフォルトの名無しさん [sage] 2011/07/27(水) 12:14:00.96 ID: Be: Copyright書いてないね。 型理論の人たちは結構フリーで膨大なページ数のテキスト公開してるから聞いてみれば? 73 Matlab でもクラス記述できるでしょうか [] 2011/07/27(水) 12:49:09.99 ID: Be:1370028454-2BP(0) >> 公開するとまずいですよねぇ・・・・きっと。 原文のドキュメント作成者たちは無償で公開している。多くの方に読んでもらうためだ。 それを翻訳して公開するのに喜びこそすれ、嫌とは言わないだろう もちろん、ドキュメント作成者の了解が前提になるが。 メールを出してみるべき。 74 60 [] 2011/07/27(水) 13:46:38.43 ID: Be: ペンシルバニア大学の先生ですよね。ビビる・・・ CPDTは、「出版間近」って感じなんでさすがにまずそうですが、 Software Foundationsのほうは、これをどうしたいのか、なんで 公開しているのか、どこにも書いてないんですよね。 メール出してもし許可がもらえたら、もう一度見直してボチボチ 公開したいところです。 まぁ、「４０代オッサンの夏休み」になりますが。 75 デフォルトの名無しさん [sage] 2011/07/27(水) 15:36:21.43 ID: Be: >>74 > CPDTは、「出版間近」って感じなんでさすがにまずそうですが、 > Software Foundationsのほうは、これをどうしたいのか、なんで > 公開しているのか、どこにも書いてないんですよね。 自分が担当している講義の為の資料を受講生以外の一般にも公開しているという事です。 このSoftware Foundationsに沿った形での講義をPierceさんらはやってますから。 （PierceさんのHPのTeachingの最初の科目、CIS500とかいう番号が付いてるやつです） CPDTは明らかに本として出版するのを大前提として書かれてますし、本として読める単一ファイルの形でなっていますが、 こちらのSoftware Foundationsは少なくとも今の時点では紙に印刷される（か電子出版される）従来の書籍の形態にはなっていませんね。 マニュアルなどで良くあるWebページとリンクの集合体として現在は組織化されてますから、 当面は普通の書籍としては出版する予定はないように見えます。 もちろん、Pierceさんらが（少なからずが出版を最終目標とする）旧来型のPSやPDFの単一ファイルにしたものを 実は作っているが公開していないという可能性はゼロではありませんが、その可能性は少ないと思います。 76 60 [] 2011/07/27(水) 16:23:12.05 ID: Be: >>75 よく見ると、前書きにその辺のことがチラッと書いてありましたね。跳ばして読んでました。 これによると、この文書を誰かが自分の講義に使うことは否定してませんね。 使う場合には連絡しろとも書いていない。 「ただ、そうするとどこかに直したいところや加筆したいところが出てくるだろうから、 そういうのがあったら連絡してね。subversionのレポジトリ教えてあげるから。」 てなことは書いてありますが。 この雰囲気だと、翻訳の公開を拒絶されそうな気配は無さそうですね、なんとなく。 78 デフォルトの名無しさん [sage] 2011/07/27(水) 23:09:04.95 ID: Be: >>75 coqdocだからPDFにはすぐ出来る。-pdf付けるだけ。 79 60 [] 2011/07/29(金) 00:09:21.97 ID: Be: 昨夜、Pierce先生にメールをしたところ、長文のお返事をいただき、 日本語版の公開を快諾していただきました。 ただ、公開間近の最新版がもうすぐ出来上がる予定で、今のとだいぶ変わって いるので、それも考慮したほうがいいのではないのではとのことです。 ということなので、最新版とその差分が見られるよう、レポジトリの アカウントを作っていただくことになりそうです。 とりあえず最新版を見せてもらって、あんまり変わってないようなら 今手元にあるのをさっさと公開しようと思っています。 80 デフォルトの名無しさん [sage] 2011/07/29(金) 00:37:49.56 ID: Be: やるじゃん
ありがちな勘違い。
javascript - Negative lookahead Regular Expression - Stack Overflow I want to match all strings ending in ".htm" unless it ends in "foo.htm". I'm generally decent with regular expressions, but negative lookaheads have me stumped. Why doesn't this work? /(?!foo)\.htm$/i.test("/foo.htm"); // returns true. I want false. What should I be using instead? I think I need a "negative lookbehind" expression (if JavaScript supported such a thing, which I know it doesn't).Unfortunately, JavaScript does not support "lookbehind" in regular expressionsIt is often better to have a simpler regular expression with a loop or two, rather than a super monstrous (ok what you want isn't super monstrous, but code has a tendency to grow) need I say unmaintainable regular expression.The problem is pretty simple really. This will do it: /^(?!.*foo\.htm$).*\.htm$/iWhat you are describing (your intention) is a negative look-behind, and Javascript has no support for look-behinds. Look-aheads look forward from the character at which they are placed — and you've placed it before the .. So, what you've got is actually saying "anything ending in .htm as long as the first three characters starting at that position (.ht) are not foo" which is always true. Usually, the substitute for negative look-behinds is to match more than you need, and extract only the part you actually do need. This is hacky, and depending on your precise situation you can probably come up with something else, but something like this: // Checks that the last 3 characters before the dot are not foo: /(?!foo).{3}\.htm$/i.test("/foo.htm"); // returns falseYou could emulate the negative lookbehind with something like /(.|..|.*[^f]..|.*f[^o].|.*fo[^o])\.htm$/, but a programmatic approach would be better.
なんというかまとめる時間がなっしんぐ。
Making it stick.: Kotlin == Harry Potter, Scala == LoTR? Friday, July 22, 2011 Kotlin == Harry Potter, Scala == LoTR? kotlin is a new JVM language, from JetBrains. To understand my title, you may want to read a comparison with Scala from the Kotlin perspective, and some of the discussion taking place in the Scala community. kotlin は JetBrains による新たな JVM 言語です。今回のタイトルを理解するために Kotlin 視点からの Scala との違いを読みたくなることでしょう。 そしてまた、Scalaコミュニティにおける論争についても。 Perhaps since I recently saw the final Harry Potter movie, the title of this post came immediately to mind. Harry Potter appears to me to be a fun story, whose details exist mainly to support that story. For example, characters seem to have the abilities they require to meet a specific challenge. たぶんつい最近わたしはハリー・ポッターの映画を観たので今回のポストのタイトルを 思いついたのでしょう。ハリー・ポッターはわたしにとっては、楽しいストーリーであり 主にストーリーをサポートするためのディティールをもったものです。 たとえば登場人物たちは specific challenge に出会うために要求される能力を 持っているように思えます。 On the other hand, the characters in Middle Earth seem be situated in a world that has its own physics. The stories are based on that world, those characters, and the given physics. My understanding is that this is the intention and the process taken to write the books. 一方、Middle Earth の登場人物たちは固有の phsics を有する世界に置かれているように 思えます。ストーリーはその世界と、藤重人物たち、そして与えられた physics に拠って います。わたしの理解では、これは意図的なものであり、またそのプロセスは 本を書くためのものです。 Arguably, Harry Potter is far simpler than LoTR. But, arguably, Harry Potter has less to offer than LoTR. Ten years ago this analogy could have been (and was, essentially) made between Java and Smalltalk. Ten years before *that* the argument had been made between C++ and Smalltalk. Java is not "pure". Java is in essence Smalltalk but with the "magic" its authors deemed necessary to make Java more successful. Javaは“純粋”ではありません。 Harry's world is not pure. Middle Earth is (minus some of the complications that can also be found in Smalltalk and Scala.) ハリーの世界は純粋ではありませんが、Middle Earth は純粋です。 Kotlin is a big improvement over Java, but it is merely Java minus some cruft, plus enough magic to be useful in 2011. Scala on the other hand has its own physics that makes sense, and provides for a more rich future than Kotlin. Kotlin は Java に対する big improvement ですが、それは単に Javaから一部の cruft を 引いて、2011年に有用である magic を十分に加えたものです。 一方Scala は独自の physics を持っています。 それは意味のあるものであり、Kotlin よりも豊かな未来を与えるものです。 Hmmm. Just thinking...
The Principles of Good Programming : programming その内容はというと
The Principles of Good Programming Principles of Good Programming 良いプログラミングの原則 The principles of good programming are closely related to principles of good design and engineering. The following programming principles have helped me over the years become a better programmer, and I believe can help any developer become more efficient and to produce code which is easier to maintain and that has fewer defects. 良いプログラミングの原則は良い設計の原則や良いエンジニアリングの原則と密接に 関係しています。以下にあげた原則はわたしがより優れたプログラマーになるのを 長い間にわたって助けてきました。そしてまた、これがすべてのプログラマーが より効率が良く、保守が容易で欠点の少ないなコードを書くようにするを手助けする とわたしは確信しています。
ということで項目だけ。
DRY - Don't repeat yourself Abstraction Principle KISS (Keep it simple, stupid!) Avoid Creating a YAGNI (You aren't going to need it) Do the simplest thing that could possibly work Don't make me think Open/Closed Principle Write Code for the Maintainer Principle of least astonishment Single Responsibility Principle Minimize Coupling Maximize Cohesion Hide Implementation Details Law of Demeter Avoid Premature Optimization Code Reuse is Good Separation of Concerns Embrace Change
一時はC++やめるつもりでしたが，これらのエントリ見て復帰しました。
今回スタッフ参加して思ったのは、RubyKaigiスタッフチームのホスピタリティの高さです。
Computer science has always been a male-dominated field, right?
C parser and interpreter written in Python with automatic ctypes interface generation
それにつけても以下略
Neopythonic: Before Python Before Python This morning I had a chat with the students at Google's CAPE program. Since I wrote up what I wanted to say I figured I might as well blog it here. Warning: this is pretty unedited (or else it would never be published :-). I'm posting it in my "personal" blog instead of the "Python history" blog because it mostly touches on my career before Python. Here goes. 今朝方わたしは、Google の CAPE program で学生とチャットをしました。 Since I wrote up what I wanted to say I figured I might as well blog it here. 警告: 以下の内容は pretty unedited (さもなくば公にされることは決してなかったでしょう:-)です わたしはこれを "Python history" blog ではなく、 わたしの "personal" blog に投稿します。 なぜなら、その内容が Python 以前のわたしのキャリアに関することがほとんどであるからです。 では始めましょう。 Have you ever written a computer program? Using which language? あなたはこれまでにコンピューターのプログラムを書いたことがありますか? どの言語を使いましたか? HTML Javascript Java Python C++ C Other - which? [It turned out the students had used a mixture of Scratch, App Inventor, and Processing. A few students had also used Python or Java.] Have you ever invented a programming language? :-) あなたはこれまでにプログラミング言語を発明 (invent) したことがありますか? :-) If you have programmed, you know some of the problems with programming languages. Have you ever thought about why programming isn't easier? Would it help if you could just talk to your computer? Have you tried speech recognition software? I have. It doesn't work very well yet. :-) もしプログラムを組んだことがあるのなら、あなたはプログラミング言語についてのいくつかの 問題点を知っているでしょう。あなたはなぜプログラミングが簡単ではないのかについて 考えたことがありますか? コンピューターに話しかけられたらプログラミングの助けになる でしょうか? ソフトウェアの recoginition を語ることに挑戦したことがありますか? わたしはあります。 It doesn't work very well yet. :-) How do you think programmers will write software 10 years from now? Or 30? 50? 今から10年後に、プログラマーはどのようにソフトウェアを書いていると思いますか? 30年後は? 50年後ならどうでしょう? Do you know how programmers worked 30 years ago? 30年前に、プログラマーがどのように働いていたかをあなたはご存知ですか? I do. わたしは知っています。 I was born in Holland in 1956. Things were different. わたしは 1956年に Holland に生まれました。 Things were different. I didn't know what a computer was until I was 18. However, I tinkered with electronics. I built a digital clock. My dream was to build my own calculator. わたしは 18才になるまでコンピューターのことを知りませんでしたが、電子工作にのめりこんでいました。 デジタル時計を組み立てたこともあります。わたしの夢は自分専用の計算機を組み上げることでした。 Then I went to university in Amsterdam to study mathematics and they had a computer that was free for students to use! (Not unlimited though. We were allowed to use something like one second of CPU time per day. :-) その後わたしは数学を学ぶためにアムステルダムにある大学に進んだのですが、 そこには学生たちが自由に使うことのできるコンピューターがあったのです! (もっとも、無制限に使えたわけではなく、わたしたちに許されていたのは 一日あたり1秒ほどのCPU時間でした :-) I had to learn how to use punch cards. There were machines to create them that had a keyboard. The machines were as big as a desk and made a terrible noise when you hit a key: a small hole was punched in the card with a huge force and great precision. If you made a mistake you had to start over. わたしはパンチカードの使い方を学ばねばなりませんでした。キーボードを備えたパンチカードを作るための 機械が何台もありました。その機械は机ほどもあるほど大きなもので、キーを叩いたときには恐ろしい音を立 ててカードに (with a huge force and great precision) 小さな穴をパンチしました。 もし穴を間違ってあけてしまったら、最初からやり直さなければなりませんでした。 I didn't get to see the actual computer for several more years. What we had in the basement of the math department was just an end point for a network that ran across the city. There were card readers and line printers and operators who controlled them. But the actual computer was elsewhere. それからさらに数年の間、わたしがコンピューターそのものを見ることはありませんでした。 the basement of the math department でわたしたちが持っていたのは しないに張り巡らされネットワークの単なる end point でした。 そこにはカードリーダーとラインプリンターがあって、 それらを制御するオペレーターたちがいました。 しかし、コンピューターの本体は別のところにあったのです。 It was a huge, busy place, where programmers got together and discussed their problems, and I loved to hang out there. In fact, I loved it so much I nearly dropped out of university. But eventually I graduated. そこは巨大で、busy place で、プログラマーたちが集い問題について議論している場所でした。 わたしはそこにいくのがとても好きでした。実際、あまりに入り浸っていたために 大学から drop out するところだったのです。なんとか卒業しましたけどね。 Aside: Punch cards weren't invented for computers; they were invented for sorting census data and the like before WW2. [UPDATE: actually much earlier, though the IBM 80-column format I used did originate in 1928.] There were large mechanical machines for sorting stacks of cards. But punch cards are the reason that some software still limits you (or just defaults) to 80 characters per line. Aside: パンチカードはコンピューターのために発明されたものでなく、第二次世界大戦より前に census data のようなものの分類のために発明されたものでした。 更新:実際にはもっと早く、わたしが使っていた IBM の80カラムフォーマットの起源が1928年です。 カードの山を分類するための巨大で mechanical な機械がありました。 パンチカードは一部のソフトウェアがいまだに一行あたり80文字に制限している (あるいは単なるデフォルトになっている)ことの原因です。 My first program was a kind of "hello world" program written in Algol-60. That language was only popular in Europe, I believe. After another student gave me a few hints I learned the rest of the language straight from the official definition of the language, the "Revised Report on the Algorithmic Language Algol-60." That was not an easy report to read! The language was a bit cumbersome, but I didn't mind, I learned the basics of programming anyway: variables, expressions, functions, input/output. わたしの最初に作った "hello world" のようなプログラムは Algol-60 で書きました。 この言語はヨーロッパでのみ popular であった言語であるとわたしは確信しています。 それはとても簡単に読めるような repport ではありませんでした! Algol-60という言語は bit cumbersome でしたが、わたしはそれを気にはしませんでした。 いずれにしてもわたしは Algol-60 でプログラミングの基礎である変数や式、関数、 入出力といったものを学んだのです。 Then a professor mentioned that there was a new programming language named Pascal. There was a Pascal compiler on our mainframe so I decided to learn it. I borrowed the book on Pascal from the departmental library (there was only one book, and only one copy, and I couldn't afford my own). After skimming it, I decided that the only thing I really needed were the "railroad diagrams" at the end of the book that summarized the language's syntax. I made photocopies of those and returned the book to the library. その後、ある教授が Pascal という名を持った新しいプログラミング言語があることを教えてくれました。 わたしたちのマシンには Pascal コンパイラーがあったのでわたしは Pascal を学んでみることにして、 departmental library からPascal についての本を借りました (そこにはPascalの本は一種類だけしかなく、 しかも一冊しかありませんでしたし、自分用のものを持つこともできませんでした)。 それを skimming してからその本の末尾にあった言語構文をサマライズした "railroad diagrams" だけがわたしの本当に必要であったものだと判断し、わたしはその photocopies をとってから本を 図書館に返しました。 Aside: Pascal really had only one new feature compared to Algol-60, pointers. These baffled me for the longest time. Eventually I learned assembly programming, which explained the memory model of a computer for the first time. I realized that a pointer was just an address. Then I finally understood them. Alogol-60 と比較したときに Pascal が持っていた本当に新しいただ一つの機能がポインターです。 これは長いことわたしを悩ませました。 最初にコンピューターのメモリーモデルを説明するために アセンブリ言語を学んだときでさえもです。 わたしはポインターがアドレスに過ぎないことに気がつき、ようやくのことでポインターを 理解したのです。 I guess this is how I got interested in programming languages. I learned the other languages of the day along the way: Fortran, Lisp, Basic, Cobol. With all this knowledge of programming, I managed to get a plum part-time job at the data center maintaining the mainframe's operating system. It was the most coveted job among programmers. It gave me access to unlimited computer time, the fastest terminals (still 80 x 24 though :-), and most important, a stimulating environment where I got to learn from other programmers. I also got access to a Unix system, learned C and shell programming, and at some point we had an Apple II (mostly remembered for hours of playing space invaders). I even got to implement a new (but very crummy) programming language! わたしはこれが、自分がプログラミング言語に興味を持ったきっかけではないかと思っています。 Fortran や Lisp、Bascic、Cobol といったそのほかの言語も学びました。 このプログラミングの知識でもって、わたしはデータセンターで メインフレームのオペレーティングシステムを保守するアルバイト (plum part-time job) を得るために manage しました。 それはプログラマーたちの間で最も熱望されていた仕事でした。 それによってわたしは無制限の computer time、fastest terminals (ただし依然として 80 × 24 でしたが :-)、 そして最も重要な、他のプログラマーから学べるような刺激的な環境を手に入れました。 わたしはまた Unix システムにもアクセスできるようになり、C プログラミングやシェルプログラミング を学びました。さらにあるときにわたしたちは Aplle II を手に入れました。 わたしは新しい (ただし very crummy な)プログラミング言語の実装さえするようになりました! All this time, programming was one of the most fun things in my life. I thought of ideas for new programs to write all the time. But interestingly, I wasn't very interested in using computers for practical stuff! Nor even to solve mathematical puzzles (except that I invented a clever way of programming Conway's Game of Life that came from my understanding of using logic gates to build a binary addition circuit). プログラミングはいつでもわたしの人生における one of the most fun things でした。 そしてわたしは年中新しいプログラムのアイデアを練っていました。 しかし面白いことに、わたしは practical stuff のためにコンピューターを使うことには それほど興味を示さなかったのです! また、数学的なパズルを解くことにさえも興味をひかれませんでした (except that I invented a clever way of programming Conway's Game of Life that came from my understanding of using logic gates to build a binary addition circuit Conway's Game of Life のための clever なプログラミング手法を invent したことを除き binary addition circuit を構築するために論理回路を使った)。 What I liked most though was write programs to make the life of programmers better. One of my early creations was a text editor that was better than the system's standard text editor (which wasn't very hard :-). I also wrote an archive program that helped conserve disk space; it was so popular and useful that the data center offered it to all its customers. I liked sharing programs, and my own principles for sharing were very similar to what later would become Open Source (except I didn't care about licenses -- still don't :-). わたしが最も好んでいたのは the life of programmers を better にするプログラムを書くことでした。 One of my early creations がシステム標準のものよりも優れたテキストエディターでした (それほど難しくはありませんでした :-)。 ディスク使用量の削減を手助けするアーカイブプログラムも作りました。 これはとても popluar になりましたしデータセンターがその顧客すべてに勧めるほど有用なものでした。 わたしはプログラムの共有が好きで、共有に対するわたし自身の principles は 後年オープンソースと呼ばれることとなったもののととてもよく似ているものでした (ただし、わたしはライセンスに関しては気にしていませんでした。それは今も変わりませんが :-)。 As a term project I wrote a static analyzer for Pascal programs with another student. Looking back I think it was a horrible program, but our professor thought it was brilliant and we both got an A+. That's where I learned about parsers and such, and that you can do more with a parser than write a compiler. term project としてわたしは、もう一人の学生と一緒に Pascal プログラム用の statcic analyzer を書きました。思い返してみるとそれは horrible なプログラムだったのですが、 わたしたちの教授はそれが brilliant であると考えたのでわたしたちは A+ を獲得したのです。 That's where I learned about parsers and such, and that you can do more with a parser than write a compiler. I combined pleasure with a good cause when I helped out a small left-wing political party in Holland automate their membership database. This was until then maintained by hand as a collection of metal plates plates into which letters were stamped using an antiquated machine not unlike a steam hammer :-). In the end the project was not a great success, but my contributions (including an emulation of Unix's venerable "ed" editor program written in Cobol) piqued the attention of another volunteer, whose day job was as computer science researcher at the Mathematical Center. (Now CWI.) I combined pleasure with a good cause when I helped out a small left-wing political party in Holland automate their membership database. Holland にある 小さな left-wing political party が彼らの会員データベースを自動化するのを わたしが手助けしたとき わたしはcombine しました good cause と This was until then maintained by hand as a collection of metal plates plates into which letters were stamped using an antiquated machine not unlike a steam hammer :-). これはメンテナンスされました metal plates のごとく手作業で 文字がstamp された antiquated machine を使って steam hammer とは似ていない そのプロジェクトの最後は great success ではありませんでしたが、わたしの contirbuitions は (Cobolで書いた、Unix の venerable "ed" エディタープログラムのエミュレーションを含め) もう一人の volunteer の注意をひいたのでした。 その人は Mathematical Center (現在の CWI) で computer science researcher としての day job を持っていました。 This was Lambert Meertens. It so happened that he was designing his own programming language, named B (later ABC), and when I graduated he offered me a job on his team of programmers who were implementing an interpreter for the language (what we would now call a virtual machine). その人物こそが Lambert Meertens でした。 It so happened that he was designing his own programming language, 彼は自分のプログラミング言語を設計していた named B (later ABC), B (のちにABCとなりましたが)という名前の言語 and when I graduated he offered me a job on his team of programmers そしてわたしが卒業したとき、 彼はその言語のためのインタープリター (現在わたしたちが仮想機械 virtual machineと読んでいるものです) を実装するプログラマーのチームでの仕事を わたしにofferしたのです。 The rest I have written up earlier in my Python history blog. そのあとは Python history blog に書いたとおりです。
むむむ。時間が。 つーことで途中まで。
Ruby のスタイルガイド。
Ruby Style Guide — Gist Original Source: https://github.com/chneukirchen/styleguide = Christian Neukirchen's Ruby Style Guide You may not like all rules presented here, but they work very well for me and have helped producing high quality code. Everyone is free to code however they want, write and follow their own style guides, but when you contribute to my code, please follow these rules: == Formatting: * Use ASCII (or UTF-8, if you have to). ASCII (もしくは不可避の場合に UTF-8) を使いましょう。 * Use 2 space indent, no tabs. スペース2個を単位にインデントを行い、タブは使わないようにしましょう。 * Use Unix-style line endings. Unix形式の改行を使いましょう。 * Use spaces around operators, after commas, colons and semicolons, around { and before }. 演算子の前後、カンマ、コロン、セミコロンのうしろ、{ の前後、}の前にはスペースを置きましょう。 * No spaces after (, [ and before ], ). (、[の後ろ、]、)の前にはスペースを置かないようにしましょう。 * Use two spaces before statement modifiers (postfix if/unless/while/until/rescue). (後置の if/unless/while/until/rescue といった) statement modifiers の前には スペースを二つ置きましょう。 * Indent when as deep as case. when は case と同じ深さにインデントしましょう * Use an empty line before the return value of a method (unless it only has one line), and an empty line between defs. * Use RDoc and its conventions for API documentation. Don't put an empty line between the comment block and the def. * Use empty lines to break up a long method into logical paragraphs. * Keep lines fewer than 80 characters. 行を80文字未満に保ちましょう * Avoid trailing whitespace. 行末の空白は取り除きましょう == Syntax: * Use def with parentheses when there are arguments. 引数がある場合には、カッコ対を伴う def を使いましょう * Never use for, unless you exactly know why. なぜかを正確にわかっていない限り、for を使ってはいけません * Never use then. then を使ってはいけません * Use when x; ... for one-line cases. * Use &&/|| for boolean expressions, and/or for control flow. (Rule of thumb: If you have to use outer parentheses, you are using the wrong operators.) * Avoid multiline ?:, use if. 複数行にわたる ? : を使ってはいけません。if を使いましょう。 * Suppress superfluous parentheses when calling methods, but keep them when calling "functions", i.e. when you use the return value in the same line. x = Math.sin(y) array.delete e * Prefer {...} over do...end. Multiline {...} is fine: having different statement endings (} for blocks, end for if/while/...) makes it easier to see what ends where. But use do...end for "control flow" and "method definitions" (e.g. in Rakefiles and certain DSLs.) Avoid do...end when chaining. * Avoid return where not required. 必要がないのなら return を避けましょう * Avoid line continuation (\) where not required. 不必要な行継続を避けましょう * Using the return value of = is okay: if v = array.grep(/foo/) ... * Use ||= freely. * Use non-OO regexps (they won't make the code better). Freely use =~, $0-9, $~, $` and $' when needed. == Naming: * Use snake_case for methods. メソッドにはスネークケースを使いましょう * Use CamelCase for classes and modules. (Keep acronyms like HTTP, RFC, XML uppercase.) クラスやモジュールにはキャメルケースを使いましょう (HTTP や RFC、XML のような略語の uppercase は保ちましょう)。 * Use SCREAMING_SNAKE_CASE for other constants. * The length of an identifier determines its scope. Use one-letter variables for short block/method parameters, according to this scheme: 識別子の長さはそのスコープを決定付けます。短いブロックやメソッドのパラメーターには 以下の規則に従った一文字の名前の変数を使いましょう。 a,b,c: any object 任意のオブジェクト d: directory names ディレクトリ名 e: elements of an Enumerable Enumerable の要素 ex: rescued exceptions f: files and file names ファイルやファイル名 i,j: indexes 添え字 k: the key part of a hash entry ハッシュのエントリーのキー部 m: methods メソッド o: any object 任意のオブジェクト r: return values of short methods 短いメソッドの戻り値 s: strings 文字列 v: any value 任意の値 v: the value part of a hash entry ハッシュエントリの値部 x,y,z: numbers 数値 And in general, the first letter of the class name if all objects are of that type. そして、すべてのオブジェクトの型が同じであったときにそのクラス名の 最初の一文字 * Use _ or names prefixed with _ for unused variables. * When using inject with short blocks, name the arguments |a, e| (mnemonic: accumulator, element) 短いブロックとともに inject を使うときには引数の名前を |a, e| のようにしましょう (accumlator と element のニーモニック)。 * When defining binary operators, name the argument "other". * Prefer map over collect, find over detect, find_all over select, size over length. == Comments: * Comments longer than a word are capitalized and use punctuation. Use two spaces after periods. * Avoid superfluous comments. == The rest: * Write ruby -w safe code. * Avoid hashes-as-optional-parameters. Does the method do too much? * Avoid long methods. 長いメソッドを避ける * Avoid long parameter lists. 長いパラメーターリストを避ける * Use def self.method to define singleton methods. シングルトンメソッドを定義するために def self.method を使いましょう * Add "global" methods to Kernel (if you have to) and make them private. * Avoid alias when alias_method will do. * Use OptionParser for parsing complex command line options and ruby -s for trivial command line options. 複雑なコマンドラインオプションを解析するには OptionParser を使い、 単純なコマンドラインオプションには ruby -s を使いましょう * Write for 1.8, but avoid doing things you know that will break in 1.9. 1.8 向けに書きましょう。ただし、1.9 で break するとわかっていることをするのは避けましょう * Avoid needless metaprogramming. 不必要なめたプログラミングを避けましょう == General: * Code in a functional way, avoid mutation when it makes sense. * Do not mutate arguments unless that is the purpose of the method. * Do not mess around in core classes when writing libraries. * Do not program defensively. (See http://www.erlang.se/doc/programming_rules.shtml#HDR11.) * Keep the code simple. コードをシンプルに保ちましょう * Don't overdesign. * Don't underdesign. * Avoid bugs. * Read other style guides and apply the parts that don't dissent with this list. * Be consistent. 一貫性を保ちましょう * Use common sense.
新プログラミング言語「Kotlin」登場 - Javaに新しい選択肢 | エンタープライズ | マイコミジャーナル Kotlin == Harry Potter, Scala == LoTR? http://www.reddit.com/r/scala/comments/ixggc/kotlin_harry_potter_scala_lotr/ http://patricklogan.blogspot.com/2011/07/kotlin-harry-potter-scala-lotr.html
なんかこういうのも Five reasons why you should rejoice about Kotlin « Otaku, Cedric's blog
Five reasons why you should rejoice about Kotlin « Otaku, Cedric's blog Five reasons why you should rejoice about Kotlin Kotlin に注目すべき五つの理由 As you probably saw by now, JetBrains just announced that they are working on a brand new statically typed JVM language called Kotlin. I am planning to write a post to evaluate how Kotlin compares to the other existing languages, but first, I'd like to take a slightly different angle and try to answer a question I have already seen asked several times: what's the point? We already have quite a few JVM languages, do we need any more? Here are a few reasons that come to mind.
説明部分は除いて五つの理由を
1) Coolness 2) IDE support 3) Reified generics 4) Commercial support 5) Still no Java successors
仕事が終わってから国会図書館に行ったり。 なにを調べにいったか(コピー取りにいったか)はいずれ。
最後の
The future is much more interesting.
が重いなあ。
prog21: The Nostalgia Trap Programming in the 21st Century The Nostalgia Trap I used to maintain a site about 8-bit game programmers and the games they created. To be fair, I still update the "database" now and then, but changes are few and far between, and I stopped posting news blurbs five years ago. But don't mistake wistful nostalgia for "how things ought to be." Just because you used to love the endless string of platformers for a long-dead game system doesn't mean that recreating them for the iPhone is a worthy endeavor. Just because you get a warm and fuzzy feeling when recalling thirty year-old UNIX command-line programs is different than putting them on a pedestal as model for how to design tools. That doesn't mean you shouldn't learn from the past and avoid repeating expensive mistakes. Just don't get trapped by thinking that older software or technologies are superior because they happened to be entangled with more carefree periods in your life. The future is much more interesting.
先週末にまた新しいプログラマー向けのQ&Aサイトができたようで。 Qiita(キータ) - プログラマ向けQ&Aサイト ちょっと前にできた ANS-prog: プログラマが質問し、プログラマが答える Q&Aフォーラム というのもありますが、 こういったサイトについてもバカ征くの方と RubyKaigi のときに話したりしたんですよね。 需要はあるだろうし(ただしどの程度かは正直言って見当つきません)、 供給側も不足はないと思うのですよね。存在が知られていれば。 裏を返せばいかに知名度(と信頼性)を高めるかが当面の課題じゃないかと思います。 ほかにも回答者の回答に対するモチベーションとか、回答の質やらいろいろあるでしょうけど。
盛況だったようで。 Togetter - 「第0回 スタートHaskell まとめ＃０」
見事だ。
オブジェクト指向で集約と合成と継承の違い教えてください - Yahoo!知恵袋 オブジェクト指向で集約と合成と継承の違い教えてください 補足 ・継承と委譲の違いを具体的な例を挙げて説明せよ、 それから ・java言語において、インターフェースはどのような役割を果たすか、具体的な例をあげながら説明せよ という二つの問題も教えてください。明日の昼までに解答お願いします 質問日時：2011/7/24 19:27:58 補足日時：2011/7/24 19:50:24Copyright (C) 2011 Yahoo Japan Corporation. All Rights Reserved.
なんか興味深そうなことを書いてそうなんだけど読んでいる時間ががが
Dorophone: Duckspeak Vs Smalltalk Duckspeak Vs Smalltalk The Decline of the Xerox PARC Philosophy at Apple Computers Malcolm Gladwell's recent piece, "Creation Myth", in the New Yorker, about innovation and implementation via Xerox PARC, academia and Apple Computers, tells one interesting story about that surprising time in our modern history. But the story of the tensions and synergies between visionaries and businessmen elides a few interesting details about what was going on, and why, at Xerox PARC at the time. Gladwell's version of history features a nimble entrepreneur, Steve Jobs, capitalizing on an idea the value of which a monolithic company, Xerox, can't see. But the story of Apple and Xerox PARC is also that of a design philosophy meant to empower people diverging into one meant to entertain them or to sell them things. When Steve Jobs visited Xerox PARC and saw the first mouse, the system he was looking at, the Alto, was running a programming environment and language called Smalltalk. While the details of this system are glossed over in the Gladwell piece, they deserve more careful attention. Although The Alto bears a superficial resemblance to modern computers, it differed in one major area: the relationship between software developers and users. (略) Copyright J. Vincent Toups 2011
Malcolm Gladwell's recent piece, "Creation Myth", in the New Yorker,
ニューヨークの人がどうこうってのはかすかに記憶が。
高速リリースのこうした問題
Having spent the last eight weeks with unreliable, often very slow, internet connections we'd like to tell you about something we now consider evil — rapid release cycles for web browsers.
興味深いのはAppleのQAでは時系列的に増加する番号が重要な要求であるという点で、 (略) 意外とこの手の機能に依存している人は多い気もする。
「ぼくはこうしてプログラミングを覚えた」を読んで「はて，自分の時はどうだっただろう」と思ったので，思い出しながら記事を書いてみる。
さすが@kakutaniが見ているだけのことはある！
私は超能力者では無いので、あなたの生活環境とか懐具合とかわかりませんから。
ぐはっ。gawk の変遷についてまとめてたんだけどあともうちょい…
今日もひとつ RubyKaigi2011ネタでちょこっと書こうと思ったけど時間切れー (くたばりやがれ＞偽サマータイム)
昨日は見事に寝落ち。
こういうのがあったのねえ。TRIEやらLOUDSの話は聞きたかったかな。 もっとも今日の午後は頭痛でほぼ寝てたけど。 第1回 データ構造と情報検索と言語処理勉強会 #DSIRNLP : ATND 第1回DSIRNLP勉強会に参加しました #dsirnlp - nokunoの日記 melancholic afternoon
・スタートHaskell
第0回 スタートHaskell : ATND
出席者の感想待ち。
・ユニコード戦記
感想や書評をあまり見かけないなあ。
って自分も書いてなかった。
・アジャイルサムライ
飛ばし読みちう。
・やる夫
泳ぐやる夫シアター やる夫で学ぶ第一次世界大戦 第二十夜「叛乱（中編)」
このシリーズを読んでいるとき、「パリは燃えているか」が脳内再生されていたり。
次の問題をC言語にしてもらってほしいです。 - Yahoo!知恵袋 次の問題をC言語にしてもらってほしいです。 fgsergesgsegさん 次の問題をC言語にしてもらってほしいです。 数人でジャンケンをしたときの勝負を判定するプログラムを作ります。 (略)
まあ例によって丸投げですが、 「してもらってほしい」という言い回しが気になった。 「して欲しいです」と「してもらっていいですか」あたりが合体したんだろうか。
Parrot もだいぶバージョンが進んだなあというのはおいといて。
動的言語向け仮想マシン「Parrot 3.6」がリリース - SourceForge.JP Magazine : オープンソースの話題満載 (略) Parrot 3.6の新機能としては次が挙げられている。 * Class.add_vtable_overrideでオーバーライドのオーバーライドが可能になった * 整数や浮動小数点、文字列がレキシカル変数に保存可能になった * 従来のVTABLE_substrが削除され、VTABLE_substr_strがVTABLE_substrにリネームされた * 非推奨となっているEval PMCの代替とすることを目的に、PackfileView PMC型が追加された * String PMC上のis_integer vtableがすべての文字エンコーディングに対し正しく動作するようになった * Windows環境におけるUnicodeのエラーメッセージ表示が正しく動作するようになった * IMCCでのメモリリークが修整された Parrot 3.6はプロジェクトのWebサイトなどからダウンロードできる。
「整数や浮動小数点、文字列がレキシカル変数に保存可能になった」ってどゆこと? と原文に当たるも
Parrot 3.6.0 "Pájaros del Caribe" Released | Parrot VM Parrot 3.6.0 News: - Core + Class.add_vtable_override now allows you to overwrite an override + Integers, floats and strings can now be stored in lexical variables. Previously, only PMCs could be stored in lexicals. + VTABLE_substr has been removed. VTABLE_substr_str has been renamed to VTABLE_substr + Added a new PackfileView PMC type, an intended replacement for the deprecated Eval PMC. + The is_integer vtable on the String PMC now works for all string encodings. + Unicode error messages on Win32 now work correctly. + A memory leak in IMCC was fixed. - Languages + The snaphost of Winxed included with Parrot was updated to version 1.0.0 + Winxed has migrated to Github: https://github.com/NotFound/winxed
やっぱりよくわからんw
Previously, only PMCs could be stored in lexicals.
PMC ってなんだったっけ。
PMC / Perl 6
これかな。やっぱりよくわからん。
type of register that holds objects.
ってことなんだろうけど。
コメント欄でもいろいろ。 hate じゃなくて dislike してるんだとか。
Andrzej on Software: Stop hating Java Friday, July 22, 2011 Stop hating Java Java を憎むのは止めよう I noticed that in the Ruby community “Java” is a synonym of pure evilness. It's often used as an argument against some techniques. わたしは "Java" が Ruby コミュニティにおいて pure evilness の同義語であることに気がつきました。 (Java は?)一部の技法に対する主張として頻繁に使われています。 “It's Java all the way” “If you drop static methods, then welcome to Java and its billions of useless factories.” “Your mention of ‘factories' gives me nightmares about Java-style over/premature abstraction where you need to interact with (and therefore understand) WAY too many different classes to get anything done.” #なんか口語的(当然か)で訳しづらい喃 Those are some quotes that come from only one discussion triggered by Nick, me and Michal only because our ideas sounded a bit Java-like. History (略) Let's stop the hate It's cool that we, as a community, strongly identify with some techniques. What I'd love to see is more tolerance for other technologies. There are smart things in the Java world but we have to be open to reuse what's most cool and replace the bad parts with Ruby awesomeness. When someone starts his talk with “In Java this problem is solved by …” don't laugh and interrupt with quotes like “OMG, XML and factories again”. It didn't happen only to me. I have seen this behavior at Ruby conferences very often. It's childish. Java 世界には smart things があり、わたしたちは most cool なものの再利用と Ruby の awesomeness による bad parts の置き換えに対してオープンであらねばなりません。 誰かが "この問題をJavaではこうやって解決しているのだけど…" と話し始めたときには それを哂ったり “OMG, XML and factories again”といってさえぎったりしてはいけません。 これはわたしに対してのみ起きたことではありません。Ruby カンファレンスにおいて こういった行動を目撃しました。とても子供じみたことです。 Many good things came from the Java world - we should love them for that. 多くの優れたものがJava 世界からやってきました。 わたしたちはそれを快く受け入れるべきなのです。 #should love them むずい There are more large Java systems than Ruby ones. They abstract for reasons. They use IoC and DI for good reasons. AOP is awesome when used in a good way. Let's learn more from Java - it will help us once we work more with larger systems and codebases. They already learnt their lessons. [Discussion on Hacker News: http://news.ycombinator.com/item?id=2793227 ]
きっちり訳すべきかなあ。余裕が…
RubyKaigiで、Python の csv モジュールはほぼ丸ごとCで書かれたものだから 速度の点で Ruby のライブラリと比べるのは～ という発言がありましたが (正確な文面ではありませんが大意はこうだったと思うのでご勘弁)、 確かに C で書かれてはいるけれどもPythonとのインターフェース部分とか 読んでみると良くできている(Pythonぽい)と思います。 うまいこと Python のオブジェクトに仕立てられているというか。 素の C で書かれたプログラムという点からみるとどうか、という点はありますけど あんまりチート扱いするのもひどいんじゃないかなあ。
といまさら思い出したように書いてみた。
なんかのもじりかひっかけ? ＞Perls of Wisdom
Perl 5をどうこうしようという話のようで。
全文読むのはきついなあ(量的に)、
Perls of Wisdom - Blog - July 2011 - veekun: fuzzy notepad Perls of Wisdom Ha, ha! A hilarious and original pun. I've had several conversations now about Perl 5's level of deadness and Perl 6's level of disastrousness. So here is a followup, which surely won't get as much attention because it's not as potentially inflammatory. To recap What does "dead" mean? I have no idea. And neither does anyone else. Everyone agrees that it's a bad thing for their pet language to be called, but I can't really find a definition that applies to, say, COBOL but not Ruby. The best we have is, er, "like COBOL". Let's be more precise then: I feel Perl has a dire problem on its hands, and as a developer raised by Perl, this saddens me. (An aside: one acquaintance told me he doesn't think I even like Perl, having seen me complain about it a bit too frequently. I had to think about this. I suppose I like Perl, but I don't enjoy it, which is precisely what frustrates me here. I want to like Perl, but I don't know that Perl wants me to like it.) The Problem The Problem isn't even so much the language itself. I fear a dark cloud of insulation hangs over the Perl community. I submit the following. * Recall that Perl 5.8 went five and a half years before another major revision. That's nearly a quarter of Perl's entire lifetime, and it happened while PHP and Ruby and Python were eroding Perl's Web development niche. The new release cycle is a breath of fresh air, but there have still been few major improvements. Perl 5.8 は5年半も major revision でした。それはPerlそのものの lifetime の四分の 一にもなろうもので、その間に PHP や Ruby、Python が Perl の持っていた Web development niche を侵食していきました。新たなリリースサイクルは breash of fresh air ではありますが、大きな改良 (major improvements) は わずかなものです。 #最初の文が悩ましい * I just worked for a Perl shop for four years. I have friends involved with Perl. I lurk in #perl. Somehow, I'm still missing out on interesting Perl developments that others imply are happening. I could definitely better educate myself, but the bigger issue is: if someone with a foot in Perl is oblivious to these things, what chance do those outside the community have? * Consider the use of open with bareword filehandles. Unlike some other warts (blockless map and grep, ugh), I'm hard-pressed to find a Perl developer who'll defend bareword filehandles. The #perl bot's "usual stuff" quote includes "use lexical filehandles" as its third bullet point, immediately after strict and warnings. It's universally agreed that this is a misfeature and should be avoided. bareword ファイルハンドルを使った open の使用について考えてみましょう。 ブロックなしの map や grep のようなほかの warts とは違って、bareward ファイルハンドル を守ろうとする Perl developer はほとんど見受けられませんでした。 use strict、use warnings の直後に third bullet point として "use lexical filehandles" を含む quote をするのが #perl ボットの "usual stuff" です。 bareword ファイルハンドルが misfeature であり取り除くべきものであることは universally に同意されています。 #gdgd だあ Yet even a proposal to remove them from a small part of the Perl documentation is contentious! brian d foy (who I believe is the documentation maintainer in some capacity?) argues that bareword filehandles should remain in the tutorial on open because, ultimately, new users will find them simpler and existing users need to know about them. * There's a worrying trend in how both the Perl 5 and 6 communities respond to criticisms of the process or language. Detractors will gripe about the lack of some feature or the lack of a blessed Perl 6 interpreter. Perl 5 will respond with links to CPAN; Perl 6 will explain that the idea of a "finished" language is absurd. Such responses are perfectly rational and correct. However, they don't address what the detractor actually wants: first-class support in core, or a guarantee of reasonable Perl 6 spec compatibility. The Perl community treats these gripes as engineering problems to be worked around, but they're actually a sticky emotional thing: how people feel about Perl. The misunderstanding hints at a deep disconnect within the Perl community. Are you announcing to the world why they should use Perl, or merely that they could use Perl? The latter is a programming issue, easily resolved with more CPAN modules. The former is a human issue, dealing with people and their expectations. From where I'm standing, it looks like the Perl community has taken Perl's usability and success somewhat for granted due to their own close involvement, and thus forgotten to address the needs of those outside the community. Do the core Perl maintainers care that most other languages have, say, a nice object system built in? When the response is generally just "use Moose", it sounds as if nobody close to Perl thinks there's even a problem. Or perhaps that's just the impression I get. I freely admit I'm pulling this out of my ass based on personal anecdotes and a foggy memory of blog posts read over the course of years; I could be wildly off-base. But what is the ultimate goal here? To make Perl better for the people using Perl, or to make Perl better for everyone? Fixing Perl 5 (略)
The Art of Computer Programming 一巻、今のうちに買っておくかねえ。 四巻も欲しいところだけど…分冊全部揃えるのは財布に厳しいな。
達人プログラマーを読もうってのはいいことだと思いますが、
達人プログラマー読書会@札幌-2011.08.01 : ATND
「達人プログラマー システム開発の職人から名匠への道」 の読み合わせを行います。
この「読み合わせ」の使い方間違ってんじゃないかなあ。
読み合わせ - 国語辞書 - goo辞書
「current」といっても1984年のことですが A review of current popular programming languages: COBOL, Pascal, Forth, Logo, and BASIC. : programming 経由で
Programming : Free Download & Streaming : Internet Archive A review of current popular programming languages. Guests: Gary Kildall, DRI; Paul Grady, Microfocus; Dave Eisenberg, Apple; Elizabeth Rather, Forth Products/Demos: COBOLFORTHFORTH Graphics, PASCAL, Apple's Personal COBOL This movie is part of the collection: Computer Chronicles Keywords: Episode year: 1984
おお、ゲーリー・キルドールの名前が。 キルドールと言えば彼が出演した回の新・電子立国を観たいなあ
reddit での反応から抜粋(元記事には面白いやりとりまだあるよ :)。
A review of current popular programming languages: COBOL, Pascal, Forth, Logo, and BASIC. : programming A review of current popular programming languages: COBOL, Pascal, Forth, Logo, and BASIC. (archive.org)It's amazing that they never mention C. The language pre-dates all of these (except BASIC) and is still in use today yet it doesn't even enter into their discussion. Yes, I know COBOL is still around in some legacy applications, but nothing new is ever written in it.It's amazing that they never mention C. The language pre-dates all of these (except BASIC) Except BASIC (64), and COBOL (59) and FORTH (70) and Pascal (68) and Logo (67). All of the languages predate C (72).I stand corrected. Still C was largely contemporaneous with the latter three, since development on it started in the late 60s. I was more making the point that this program was produced in 1984, long after C had established its dominance as a general purpose language, rather than being explicitly factual.In 1984, C had only achieved dominance in the UNIX sphere. At that time, C compilers were big, slow, and expensive. It was just another language on microcomputers, it's popularity among minicomputers was decidely hit-and-miss, and practically nonexistent on mainframes. The workstations was the platform C most dominated.There were far more development jobs available using COBOL than C in 1984. That may have turned around by 1994.Upvoted for "contemporaneous".They did mention C, when they talked about systems programming languages briefly. AFAICT this video was about applications programming languages, so C didn't come up.
1984 年だと Turbo-C はまだなのか。んじゃあ DOS ではまだあまり使われてなかったっぽい。
Borland Turbo C - Wikipedia, the free encyclopedia Version history Turbo C 1.0 * Version 1.0, on May 13, 1987 - It offered the first integrated edit-compile-run development environment for C on IBM PCs. The software was, like many Borland products of the time, bought from another company and branded with the "Turbo" name, in this case Wizard C by Bob Jervis[1][2] (The flagship Borland product at that time, Turbo Pascal, which at this time did not have pull-down menus, would be given a facelift with version 4 released late in 1987 to make it look more like Turbo C.) It ran in 384 kB of memory. It allowed inline assembly with full access to C symbolic names and structures, supported all memory models, and offered optimizations for speed, size, constant folding, and jump elimination.[3]
MS-C は 3.0あたり?
Visual C++ - Wikipedia, the free encyclopedia 16-bit versions * Microsoft C 1.0, based on Lattice C, was Microsoft's first C product in 1983. It was not K&R C. * C 2.0 added large model support. * C 3.0 was the first version developed inside Microsoft. It was extremely compatible with K&R and the later ANSI standard. It was being used inside Microsoft (for Windows and Xenix development) in early 1984. It shipped as a product in 1985. * C 4.0 added optimizations and CodeView, a source level debugger.
RubyKaigi 2011 個人的お気に入りセッション : 僕は発展途上技術者
まつもとさんにも twitter 経由で指摘されてましたが、かずひこさんのことをすっかり忘れておりました。 母語がフランス語という人をイメージしていたのが敗因でした。
[Ruby] 最後のRubyKaigiのメモランダム / Quelques notes sur le dernier RubyKaigi - ふぇみにん日記(2011-07-20) すでにTweetしたのも含めて、思いつくままに。 このへんとかこのへんとかでつっこまれていますが、クロージングでサブスクリーンの上部に 「またお会いしましょう」「See you again」と並んで、フランス語で「Au revoir」と出ていた のは私のせいです。何かメッセージを出したいと（たぶん）june29が提案して、じゃあ「またお 会いしましょう」と「See you again」はどう？って私が提案して、ついでにフランス語だと 「Au revoir」だよと言ったらそれが採用されてしまったと。
この流れにはとても納得しました。 まあ来場者皆の母語でってのは無理な相談ですよね。 それでもポルトガル語あたりは欲しかったかなという気も。
あっちへ行ったりこっちへ行ったり。
nari's essays
2013年に答え合わせしませんか？」
闇RubyKaigiも見たかったけど、そーすっと翌日の懇親会をあきらめないといけなかったしなあ。 最終日もなんかあったけど以下略
TAPLでも出てきてるし、きちんとまとめときたいなあ。
日本語で読めるのだとこの辺?
Lambda Calculus Drills? : haskell I've been interested in learning untyped LC. My goal is to work my way through some LC to have a clue about how at least simply typed LC works, and hopefully have more insight into how Haskell's type system works. My problem is that whenever I read, I find the author explains the laws, introduces the shorthands, and immediately starts developing church numerals. I need them to wait. I need the author to be Sal Kahn for about 20 minutes and work a few simple examples for me and maybe leave me a little drill to do on my own. Maybe between 5 and 15 exercises that are easy. Once I've internalized the low level moves I'll be ready to understand the shorthand and the higher level moves that save my writing hand. Is there something out there I haven't found yet?There are some exercises in Hindley and Seldin's Lambda-Calculus and Combinators: An Introduction.
drill だから「教科書」とはちがうか。
こんなの?
やっぱりこういう話は向こうでもあるのね
productivity - Why don't all companies buy developers the best hardware? - Programmers - Stack Exchange I must be missing something. わたしは何かを失っているはずだ The cost of employing a programmer in my area is $50 to $100 an hour. A top end machine is only $3,000, so the cost of buying a truly great computer every three years comes to $0.50/hour. ($3000/(150 wks * 40 hours)) Do you need a top-end machine? No, the $3000 here is to represent the most that could possibly be spent not the amount that I would expect. That's roughly the cost of a top-end iMac or MacBook (17 inch). So suppose you can save $2000 every three years by buying cheaper computers, and your average developer is making $60. (These are the most charitable numbers that I can offer the bean-counters. If you only save $1000, or $750, it only strengthens my case.) If those cheaper computers only cost you 10 minutes of productivity a day. (Not at all a stretch, I'm sure that my machine costs me more than that.) then over 3 years the 125 lost hours would add up to a loss of $7500. A loss of 1 minute a day ($750) would give a net gain of $1250, which would hardly offset the cost of poor morale. Is this a case of "penny-wise and pound-foolish" or have I oversimplified the question? Why isn't there universal agreement (even in the 'enterprise') that software developers should have great hardware? Edit: I should clarify that I'm not talking about a desire for screaming fast performance that would make my friends envious, and/or a SSD. I'm talking about machines with too little RAM to handle their regular workload, which leads to freezing, rebooting, and (no exageration) approximately 20 minutes to boot and open the typical applications on a normal Monday. (I don't shut down except for weekends.) I'm actually slated to get a new machine soon, and it will improve things somewhat. (I'll be going from 2GB to 3GB RAM, here in 2011.) But since the new machine is mediocre by current standards, it is reasonable to expect that it will also be unacceptable before it's retirement date. Wait! before you answer or comment: 1. $3000 doesn't matter, if the machine you want costs less than that, that's all the more reason that it should have been purchased 2. I'm not asking for more frequent upgrades. Just better hardware on the same schedule. So there is no hidden cost of installation, etc. 3. Please don't discuss the difference between bleeding edge hardware and very good hardware. I'm lobbying for very good hardware, as in a machine that is, at worst, one of the best machines made three years ago. 4. Make sure you are providing new content. Read all 35 answers before providing another one. productivity hardware costI will put my 2 cents in here from the employer's side ... who is also a developer. I agree that low end machines are useless but top end machines are overkill. There are a number of reasons why you don't get the top end machines: 1. Cashflow is a real issue, not just a theory. You might be getting paid $60K-$80K per year, but this month we have a total amount in the bank which has to be split amongst every competing thing in that month. 2. There is a sliding scale of price and benefit. Low end machines are on the whole pretty useless ... if you're getting a celeron or low power chip then whinge away ... mid range machines have good overall performance, once you get into the top you are starting to tune for a given purpose (CAD, Gaming, Video encoding etc) ... and the tuning costs extra. 3. General parts are generally cheaper, replacements, warranties and insurance all play a part in the overall running costs and the down time while you source a replacement. 4. Top end machines depreciate just faster than ones 1/3 the price. 5. If you're doing high end graphics programming or CAD work then the extra grunt is valid; if you're just writing standard business software, running visual studio or eclipse and surfing Stackoverflow for answers then the extra power is cool bragging rights, but realistically a mid range machine will not max out the CPU or memory in a standard box today. 6. Mid range machines built today hammer and in 2 years time they will be twice as fast (well kind of). Seriously, they are lighting quick. 7. At the end of the day most of what you do is type raw text into text files and send it to the compiler ... that bit really hasn't changed since VI in the 1970s and the low end machines today are a millions times faster than the ones back then ... your pace of coding really isn't that different. SO to summarize, you should have good gear and good tooling, it makes a big difference but top end machines are not really justifiable for the "general developer". ... ah, and now I read you edit and that is what you are talking about, I will leave the above cos I have written it now ... Yeah, your machine is underspecced for the tooling. To clarify a mid range machine should have * 2 cores min, 4 cores good anymore at this stage is overkill. * 4GB is a min, 8GB is good and anymore is nice to have. * SSD should be standard but really a 10KRPM WD or seagate 80-100GB drive should do fine. * 2 x 19" monitors is a minimum with a reasonable video card.
RubyKaigi2011 4日目。114回目のmeetupはRuby会議では話さなかったRubyの深い話をしてもらってコミッタに絡んでもらうというのコンセプトに開催した。
普段Asakusa.rbとかに参加していると、ものすごい Hackerたちがたくさんいるんですよね。 そんな中で大したことのない自分には何ができるだろう、と考えたときに、すごいHackerを目の当たりにして 自分はダメだなあ、なんて考えてしまっている人たちへ、少しでも勇気を与えられたらいいなあ、と思って行動を起こしました。
一日が24時間、仕事+通勤時間+睡眠やらを差っ引いてどれだけ残るかというと
一つ前へ
2011年7月(中旬)
一つ後へ
2011年8月(上旬)
リンクはご自由にどうぞ
メールの宛先はこちら
![かってに改蔵 中巻(期間限定版) [Blu-ray]](http://ecx.images-amazon.com/images/I/51QUtAzxiPL._SL160_.jpg)
