ときどきの雑記帖 i戦士篇

最新ページへのリンク
目次ページへのリンク

一つ前へ 2009年11月(上旬)
一つ後へ 2009年11月(下旬)

ホームへ

2009年11月20日

■_

・Haskellな夜
ということでいってまいりました。Haskellナイト。 アクセスマップを見ていて気がついたんですが、 お台場ガンダムのあった潮風公園からも割と近いっちゃあ近い位置だったんですね。 アクセスマップ TOKYO CULTURE CULTURE:@nifty

まとめを書いている余裕がナッシング。




すぺさるどりんくその1

すぺさるどりんくその2


座談会の参加者の方々。


Programming in Haskell の著者からのメッセージ。
来年4月に来日の予定があるとか
(それにあわせてまたなにかイベントをやるかも?)。

会場の参加者対して「Haskellで練習問題以上のものを作ったことのある人?」
向井さん Haskell一時期使ってたけど飽きた?
RWH 日本語になるだけでも価値がある
720ページで3800円。あまりない値段付け
原書は50ドルくらい?
タイムインターメディアに感謝
原著者に50箇所間違いを指摘した
(反応はすぐに返ってくることも時間がかかることも)
掲載されているプログラムはそのまま実行できるはず
ただし本で想定しているのが GHC 6.8.3、現行の最新が 6.10.4 なのでコンパイルエラーになるものが
316ページ
366ページ
世界で一番わかりにくい再帰の説明
筆者が複数のせいか記述がころころ変わったりすることも
  末尾再帰

Programming in Haskell
10%ルールで輪講しました
訳したら大学で使ってもらえるかも
「またHaskell本か」(RWHもオライリー→オーム社)
RWHの値段の情報が流れてきて再考
かなりがんばりました
通常なら考えられない値段
720ページ以上の内容が詰まってます
キーボードに刻印されていない記号使ってます
13章がわからないという声が
「RWHは好きなところを好きな順序で」
「Programming in Haskellは頭から順に」
Arc Challenge
Lisp
関数合成
setq なしでプログラムを組めるのか?
モナド
なぜモナドは難しいのか
暗闇の中
群盲象を撫でる

>>= は

理解不能な概念を放っておけない



座談会で cut-sea さんが、Programming in Hsakell の原書の値段を見たら 一万円超えていてびっくりしたという話をされたんですけど、それって ハードカバーのやつじゃないかなあ(ジュンク堂にずっと置いてあるしw)。 ペーパーバックのほうは一万円超えたことはないと思うけど。

■_

関数型プログラミング言語Haskell Part11 

228 デフォルトの名無しさん [sage] 2009/11/18(水) 05:09:15 ID: Be:
    Cで書かれたHaskellの1000行程度の小さい処理系ってないのか
    無いなら作る魂発揮できれば良いんだけど 

229 デフォルトの名無しさん [sage] 2009/11/18(水) 07:57:41 ID: Be:
    schemeでも2000行程は掛かるから、
    演算子が色々あるhaskellはその十数倍は見積もらないと。
    haskellの最小コア命令セットってどうなるんだろ?
    schemeだとapply evalに、if set! define lambda beginだったか。(マクロもあるけど) 

230 デフォルトの名無しさん [sage] 2009/11/18(水) 08:34:14 ID: Be:
    >>228
    Haskellの教育向け実装処理系であるGoferはいかが?
    ソースの合計行数(wc -l *.[chy])は、27110行だった。
    作者によるユーザガイドと実装に関する論文も公開されている(ただし英語)。 

231 デフォルトの名無しさん [sage] 2009/11/18(水) 12:17:32 ID: Be:
    >>228
    作れるの? 

235 デフォルトの名無しさん [sage] 2009/11/18(水) 16:38:15 ID: Be:
    いっそhaskell--とか言うサブセットでも定義して実装するとか
    なんか色々なものがclassで実装出来そうな気がする
    つまり標準的な仕様から除外出来そうな。互換性には目を瞑るって事で 

236 デフォルトの名無しさん [sage] 2009/11/18(水) 17:42:21 ID: Be:
    >>235
    良く分からんけどがんばれ 

C で書くというのはまあ大変だろうけど、「最小限の実装」ってどのくらいで 実装できるもんなんだろう(「最小」の定義があれか)。

■_ FizzBuzz ともなど

http://debasishg.blogspot.com/2009/01/fizzbuzz-and-state-monad.html
Ruminations of a Programmer: Fizzbuzz and the State Monad

Fizzbuzz and the State Monad

When I want to learn something I tend to look for examples that articulate the theme 
of the problem directly instead of making it accidentally complex. Simple examples 
make things easier, and I was searching for such an exmaple for understanding the 
State Monad in Haskell.

わたしが何かを学びたいと望んだときに単純な例はものごとを易しくするので、わたしは 
Haskell の State Monad を理解するためのそういった例を探そうと思いました。

The State monad is useful for modeling computations in Haskell that maintain state, 
the bread and butter of programming in an imperative language. Haskell tutorials for 
beginners teach us how to pass on the old value of the state with each call of the 
function, and then extract the new state from the result. Commonly referred to as 
"threading the state through the computation", this strategy works, but tedius .. and 
Haskellers will consider this .. boilerplate.

State モナドは Haskell で命令型言語でのプログラミングのパンとバター (the bread and 
butter)である「状態」を取り扱うような modeling computations に有用です。ビギナー向けの 
Haskell チュートリアルは関数の呼出しごとに state の古い値をどのように渡すかそして新し
い state  をその結果から extract するのかを教えています。この strategy works は一般に
"threading the state through the computation",とされていますが、tedius (tedious 退屈?) 
であり、Haskell 使いはこれを boilerplate と見なすのです。

the bread and butter: 非常に重要なこと、もの。飯の種。
boilerplate: 良くあるパターンの文。とか。

The State monad raises the level of abstraction and decouples the state management 
from the computation itself. I am not going to write yet another tutorial on monads. 
Instead I would like to share the example problem which made me understand the State 
monad quite beautifully.

State モナドは抽象化のレベルを引き上げ (raises the level of abstraction)、computation 
そのものから状態管理を分離します。わたしはモナドについてのyet another なチュートリアル
を書こうとは思っていません。その代わりに、わたしに State モナドをとても美しく理解させ
た問題の例を共有したいと考えているのです。

It is fizzbuzz !! Fizzbuzz has been solved in a multitude of languages of various 
paradigms. The basic problem that fizzbuzz solves is simple enough to be moulded into 
demonstrating various idioms of a programming language. Not all of them are efficient 
or elegant enough, but serves well articulating the idiom in hand - you don't have to 
stretch yourselves to comprehend the problem that you are trying to solve. You can 
focus on the solution itself right from the word go. Even Haskell has quite a few 
solutions to the fizzbuzz problem, but I could not find one that makes use of the 
State monad. The solution below generates the whole fizzbuzz sequence as a side-effect 
using monads. This is not the most elegant of solutions for fizzbuzz, does not work 
for infinite sequences, but I found it quite simple and useful in understanding the 
State monad in Haskell ..

それが fizzbuzz です!! fizzbuzz が解決した基本的な問題とは、プログラミング言語の様々な
イディオムをデモンストレーションするための型として十分すぎるほど単純なものです。そのす
べてが十分に効率的 (efficient) でエレガント (elegant) というわけではありませんがbut 
serves well articulating the idiom in hand -あなたが解こうとしている問題を compprehend 
するために自分自身を stretch する必要はありません。You can focus on the solution 
itself right from the word go. Haskell でさえ fizzbuzz 問題を解く方法はいくつもありま
すが、わたしは State モナドを使ったものを見つけることができませんでした。以下に挙げた
解法では fizzbuzz sequence 全体を藻などを使った副作用として生成しています。これは 
fizzbuzz の解法としては most elegant なものではありませんしinfinite seqences にも対応
していませんが、わたしが Haskell の State モナドを理解するのにとてもシンプルで有用なも
のでした。

Without further ado ..

import Monad
import Control.Monad.State

-- the entire fizzbuzz list is prepared as a side-effect
-- collect prepares the list as the State
-- mapM strips the values part

run_fizzbuzz :: [Integer] -> [[Char]]
run_fizzbuzz list =
    state where (_, state) = runState (do mapM_ collect list) []

collect :: Integer -> State [[Char]] ()

-- gets the old state and cons s the new
collect n = do
    f <- get
    put ((fizzbuzz n):f)

fizzbuzz :: Integer -> [Char]
fizzbuzz n
    | n `rem` 3 == 0 && n `rem` 5 == 0   = "fizzbuzz"
    | n `rem` 3 == 0                     = "fizz"
    | n `rem` 5 == 0                     = "buzz"
    | otherwise                          = show n

main :: IO ()
main = do putStr $ show $ reverse $ run_fizzbuzz [1..100]

Posted by Debasish at 1/18/2009 07:52:00 PM

■_

2009年11月19日

■_

お台場で僕と握手!

・だる
東スポの記事によるとダルビッシュの故障はかなり重傷で、 来シーズンの前半も出場があぶないとかなんとか。

・うっちートレード志願
これも東スポから。もっとも昨日のだけど。 放っておいても来年FAの権利が(多分)得られますが、 年俸交渉で提示された金額が納得いかなかったとか何とか。 まあ選手と球団と両方に言い分はあるだろうけど、 「絶対額」として出せる金額はあまり高くないんじゃないかな。 観客動員はアレだし、TV放送で放映権料なんかもほとんどないだろうし、 一応親会社のTBSは以下略だし。 まあ、「親会社」からの金でどうにかなってる球団経営は変だと思うけどね。

■_ Perl 6

もうよくわからんw http://blog.perlassociation.org/2009/11/perl5-and-perl6.html http://www.shadowcat.co.uk/blog/matt-s-trout/f_ck-perl-6/ http://use.perl.org/~masak/journal/39912

Perl5 and Perl6 - Japan Perl Association運営ブログ

最近CatalystやDBIx::Classで有名なMatt Trout氏とPerl6の開発者の1人であるCarl Masak氏が
IRCでPerl5とPerl6の関係性について色々議論した結果基本的な合意が見られたようで、相次い
でブログをアップしています。

これまでPerl5コミュニティからは「まだまだ実用段階じゃないのにPerl6なんて大々的に言って
いるものだからPerl5のネガティブキャンペーンになってしまっている」、Perl6コミュニティか
らは「なんで開発途上のソフトウェアにこんなにいちゃもんをつけられなければいけないんだ」
というような声があがってきていましたが、これは単純にブランディング的、マーケティング的
な袖の掛け違いであることが書かれています。

彼らのブログに大きな結論としては、

    「Perl6はPerl5とは同じPerlという大家族の一員ではあるが、同じ血統ではない」

ということが強く全面に押し出されています。また、このような話し合いがもたれた結果、
perl6.orgのサイト上でも「次世代のPerl」という表現が削除されたそうです。

Perl6がPerl1~5までの哲学や思想を受け継いだものであることは間違いありませんし、
Perl"6"という名前も今後変更する予定はないということですが、かといってPerl6は
Perl5が突然Perl5に取って代わる事はありえません。

Perl5自体は現在開発者の若返りが多少起こりつつありますが、Perl6や他のLL言語からどんどん
良いところを盗みつつ、独自の開発がどんどん進んでいっています。Perl5の現在の利用状況も
こちらのブログで「絶好調であり、これまでよりもいっそう活発になっている」との報告もあり
ます。


Perl6が出たらPerl5はお払い箱になる、という考えだったひとはひとまずそれを忘れて、Perl5
シリーズを再評価してみるのもいいかもしれません。
Journal of masak (6289)

People's minds weave stories. Stories weave people's minds.

My mind is pretty tied to the Perl 6 story nowadays, and I haven't minded the Perl 5 
story much. Until this week, that is. Last Sunday, I backlogged over a discussion of 
someone coming in from #perl asking people on #perl6 why Perl 6 claimed to be Perl 
when it clearly isn't. My resulting blog post basically asked the #perl people to stop 
telling outsiders biased things.

(略)

Then I learned a bunch of interesting things about the Perl 5 story, things which I 
would probably have figured out by myself sooner, had I not been so influenced by the 
Perl 6 story already. Here I make a partly vain attempt to summarize the Perl 5 take 
on Perl 6:

    * There's Perl 5, and it's pretty awesome. It's fast, well-tested, and has the 
      CPAN, which rocks. People who weave the Perl 5 story are generally not sitting
      around waiting for Perl 6, nor are they particularly interested in making it
      arrive sooner.

    * From the outside, and generalizing, Perl 6 looks like a big failure. It hasn't 
      "arrived" yet, and in the process it has generated massive amounts of bad
      PR for itself and for Perl in general. Parts of the bad PR come from not
      arriving yet, parts of it come from the version thing.

    * The version thing, in essence, is this: 6 is larger than 5. Everyone knows what 
      this means; releases with bigger version numbers (especially major ones) are
      better than, and are meant to replace, releases with smaller version numbers.
      Perl 5 replaced Perl 4, which replaced Perl 3, etc. Perl 6 lambdacamels don't
      think much about this, but Perl 5 folks fielding questions from outsiders about
      Perl 6 sure do.

    * To make matters worse, those Perl 6 people are actually encouraging the delusion 
      that Perl 6 is replacing Perl 5. They have early alpha releases out, and they're 
      making statements about Perl 6 being the "next version of Perl", as if
      they were standing there with the finished product already.

    * When people try what the Perl 6 people have, the find it slow, buggy, and in 
      almost total lack of library. If these people are outsiders, they might well
      associate those bad things with "Perl", and never get to trying out Perl 5,
      the "real" Perl.

(略)

Perl 5 and Perl 6 are two languages in the Perl family, but of different lineages.

It won't entirely remove the damage that the "6 > 5" phenomenon causes the 
Perl 5 crowd, but it will at least mitigate it. Also it shows some serious good will 
from the Perl 6 side.

What we do not want is a conflict, where the Perl 5 community feels the need to assert 
itself against the impostor Perl 6, which threatens it simply by being Perl 6. 
"Rewrite" does not mean "overwrite". Perl 5 isn't going away 
anytime soon. This is actually something we say on the channel a lot, but it hasn't 
been evident in our PR.

The Perl 6 community is taking steps to rectify that. Where the perl6.org page used to 
say "Perl 6, the next major version of the Perl programming language", it 
now says "Perl 6, the spunky little sister of Perl 5. Like her world-famous big 
sister, Perl 6 intends to carry forward the high ideals of the Perl community." 
With this re-wording, things are suddenly much more on equal grounds.

While I'm posting this, mst++ has made a blog post in his inimitable style over at his 
blog, where he defends the Perl 6 story to his peers. I've read it, and while it does 
contain the usual amount of four-letter words, it also makes points very similar to 
this post's, but in a sort of mirror-like Perl 5 universe. Understanding needs to flow 
in from both sides in this matter. You should read it, too.

In an ideal world, we will have Perl 5 and a mature Perl 6 existing side by side, not 
feeling threatened by each other, and competing on cool tech. The Perl 5 and Perl 6 
communities could recognize each other's Perl version as Perl, go to the same 
conferences (as we do already), and feel confident about the other group's assertions 
of superiority, because they're so clearly misguided, while still perfectly fine 
individuals, of course.

Let's try to steer in that direction, and not towards mutual assured destruction. 
That's just mad.

ちょっと頭に血が上り気味の方も。

F-ck Perl 6

Yes, This Is A Rant. You were warned.

Tue, 17 November 2009 22:26

Alright, so, with a bit of luck and a following wind the title of this post is going 
to have segregated my audience into a number of sub-sets:

(1) The people who're seriously into their Perl 5 and want to hear about me having a 
good rant about the useless science project that's screwed over our marketing for 
years and still can't manage to produce a release that anybody can use for anything 
sensible and smile safe in the knowledge that Perl 6 people just Don't Fucking Get It.

(2) The people who're seriously into their Perl 6 and want to see what the hell this 
delusional arrogant fucktard is on about so they can check off all the stupid mistakes 
I make and the inconsistencies and the unfair jibes when Rakudo Star is turning up 
soon and nobody ever said this was ready yet so why are you being such a bitch about 
the fact it isn't and smile safe in the knowledge that Perl 5 people just Don't 
Fucking Get It.

(3) The people who're seriously into either and just went "oh for fuck's sake, 
look, even MORE stupid infighting" and clicked somewhere else in disgust.

So, given those distributions, there's a reasonable chance that you're in group (1) or 
group (2) - the group (3) people have already gone. And that's fine. I wasn't talking 
to them.

(略)

Here's what we need to say, and it's really fucking simple.


Perl 5 and Perl 6 are two different languages.

Perl 5 and Perl 6 are both part of the Perl family.

Perl 5 has a website at http://www.perl.org/ because it was once the only one.

Perl 6 has a website at http://www.perl6.org/ because it started out with Perl 5 already existing.

Then, assuming you're like me, you say: And I use, and love, and intend to continue using Perl 5. That's it. Here, I turned it into a rant-free link for you. That's fucking it. Now move on. You're a Perl 5 guy, right? So fuck Perl 6. Fuck python. Fuck ruby. Fuck PHP in the eye with a rusty nail. Let's actually move the fuck on and talk about why we love Perl 5, why we keep using it even if people seem to declare it dead every so often (just like C, and UNIX, and everything else I care about in production, but anyway), why we're excited about it and all the awesome new things that are happening. And let's celebrate the things we stole from Perl 6, like half the syntax for MooseX::Declare. And let's celebrate the things we stole from python, like the C3 method resolution order. And let's celebrate the things we're experimenting with stealing from ruby, like PerlX::MethodCallWithBlock. And let's celebrate not stealing anything from PHP ... except that I wish we could steal their ease of deployment, but I'll wax lyrical (or scatalogical) on that one another time. Some people may remember an article by Steve Yegge where he said - (略)
Perl5 and Perl6 - TokuLog 改めB日記
■Perl5 and Perl6CommentsAdd Star

http://blog.perlassociation.org/2009/11/perl5-and-perl6.html

まあ、なんだかんだで、Perl5 に対する投資が Perl6 があるというおかげで阻害されてきた部
分はあるので、よい傾向じゃないかとおもいます。

俺は、昨年だかの YAPC の後の飲み会で Larry が「Perl6 はリリースできてもできなくてもど
っちでもええんや」といってたのを聞いてたので、その時点で諦めてたけどね!

なんと?! >どっちでも

■_ Cに参照渡し (call by refernce) はないんだがなあ

C言語なら俺に聞け(入門篇) Part 55 
965 デフォルトの名無しさん [sage] 2009/11/19(木) 16:05:06 ID: Be:
    C言語で、引数 char *bufを書き換えるにはどうするんですか。
    f( char* &buf)
    だと出来ますけど 

966 デフォルトの名無しさん [sage] 2009/11/19(木) 16:07:34 ID: Be:
    DLLなどで、char *buf; int size;

    f(buf, &size);で値を受け取る場合があると思うのですが。

    これは参照使うんですか。

    C言語のDLLで参照は使えるんですか。 

967 デフォルトの名無しさん [sage] 2009/11/19(木) 16:10:29 ID: Be:
    参照を使ったDLLの関数は、純粋なCコンパイラで動作するのかが知りたいです。 

968 デフォルトの名無しさん [sage] 2009/11/19(木) 16:25:12 ID: Be:
    調べたところDLLにすると、
    ポインタ値渡しが、ポインタ参照渡しに自動で変換されるようですね。
    確実かはわからないのですが。 

969 デフォルトの名無しさん [sage] 2009/11/19(木) 16:28:30 ID: Be:
    >>965
    戻り値を使え。
    char *buf;
    buf = f(buf); 

970 デフォルトの名無しさん [sage] 2009/11/19(木) 16:31:12 ID: Be:
    何でもかんでも参照渡しばっかりで
    戻り値を単なる成否チェックにしか使ってないの見るとイラっとくるよな。

971 デフォルトの名無しさん [sage] 2009/11/19(木) 16:37:33 ID: Be:
    DLLでやってた方法は、
    char *in , *out;
    int insz, outsz;
    f(in , insz, out, outsz);という値渡しでした。 だから>>968は間違えました。
    >>969
    その方法でサイズを取得したい場合は構造体にすればいいと思いますが
    C言語から参照を使ったDLLは使えないんですか。
    これがしりたいです。 

972 デフォルトの名無しさん [sage] 2009/11/19(木) 16:40:09 ID: Be:
    安全の為には、構造体の戻り値にすればいいのですが、
    異なる戻り値の関数毎に構造体を定義しないといけないのが不便なのですが。 

973 デフォルトの名無しさん [sage] 2009/11/19(木) 16:43:40 ID: Be:
    もうちょっとまとめて書けよ。
    どれとどれが同じ人の書き込みなんだ? 

974 デフォルトの名無しさん [sage] 2009/11/19(木) 16:48:06 ID: Be:
    >>970
    C に参照なんざないのに、その辺の用語も怪しいのが
    質問乱発してるのはもっとイラっとする。 

975 デフォルトの名無しさん [sage] 2009/11/19(木) 16:54:05 ID: Be:
    mov ax,1000
    mov bx,[ax]

    これがポインタや参照の正体だろ 

976 デフォルトの名無しさん [sage] 2009/11/19(木) 16:54:43 ID: Be:
    >>974
    参照を使ったC++で作ったDLLはC言語で動作するのかしりたいんです。 

977 デフォルトの名無しさん [sage] 2009/11/19(木) 16:55:12 ID: Be:
    以下の○に0個以上2個以下の文字を入れてちょ

    ○○渡し:その変数の複製を参考資料の形で渡すこと。変数を
    呼び出し先が変更しても、呼び出し元の変数には影響が出ない。
    ○渡し:その変数の価値、すなわちその変数そのものを呼び出し先に
    変更することを許可する形式で渡すこと 

978 デフォルトの名無しさん [sage] 2009/11/19(木) 16:55:40 ID: Be:
    >>976
    めんどくさいから、動作しないことにしておけ。 

979 デフォルトの名無しさん [sage] 2009/11/19(木) 17:01:04 ID: Be:
    >>976
    大抵は動くだろうが、何の保証もない以上
    やってみろ、としか言えない。 

980 デフォルトの名無しさん [sage] 2009/11/19(木) 17:01:12 ID: Be:
    出来ないなら、コンパイル時にエラーになるんじゃ 

981 デフォルトの名無しさん [] 2009/11/19(木) 17:04:17 ID: Be:
    他言語との互換性でいちいちエラーにされてたら通るコードも通らんわ 

982 デフォルトの名無しさん [sage] 2009/11/19(木) 17:04:44 ID: Be:
    通常のC/C++環境には無いWindows特有の引数評価順序指示
    C++の特徴の重複名称の改竄
    この難所?をクリアすればC++でもDLLファイルは作れる。
    がこれは完全にWinAPIスレの話題じゃないかと 

983 デフォルトの名無しさん [sage] 2009/11/19(木) 17:05:21 ID: Be:
    >>975
    型のサイズに対してよきにはからってくれる機構の部分が…

    ある場合では
    mov bl,[ax]

    別の場合では
    mov bx,[ax]
    mov cx,[ax+2] 

984 デフォルトの名無しさん [sage] 2009/11/19(木) 17:09:20 ID: Be:
    >>977
    逆じゃね? 

985 デフォルトの名無しさん [sage] 2009/11/19(木) 17:15:20 ID: Be:
    >>980
    DLL のエントリが実際にどういう引数をとるかなど
    コンパイラの知ったこっちゃない。
    プロトタイプに「ポインタである」と書かれていれば、その通りに呼び出す。 

986 デフォルトの名無しさん [sage] 2009/11/19(木) 17:19:02 ID: Be:
    >>984
    造語ってみた 複製渡し 即渡し

    即値じゃ リテラルしか取らない意味になっちゃうからなぁ… 

987 デフォルトの名無しさん [sage] 2009/11/19(木) 17:19:17 ID: Be:
    void func(int& param) 

988 デフォルトの名無しさん [sage] 2009/11/19(木) 17:50:39 ID: Be:
    混乱するんで次の言い方を推奨(但し自己責任で使用)

    参照値複製渡し==>参照値をつまり複製を渡す
    変数内部名称渡し==>変数そのものを渡す
    Cは基本的に参照値複製渡し
    C++で変数内部名称渡しが解禁された。 

989 デフォルトの名無しさん [sage] 2009/11/19(木) 17:52:49 ID: Be:
    lccというcコンパイラで実験してみたところ
    参照渡しは出来なかった。

    >>985
    参照渡しなのにヘッダは値渡しで書いたら無理でした。
    でもLCCが参照に対応してて&をいれたら動作したけど。
    参照非対応、参照対応のどちらのコンパイラでも動作させるのは無理かも。 

990 デフォルトの名無しさん [sage] 2009/11/19(木) 17:57:07 ID: Be:
    >>989
    Cでも記号&は変数に対するアドレス値変換演算子として定義されているお
    C++での参照変数型であることを宣言する型接尾修飾子&とは
    違うんで混同しないやうに 

991 デフォルトの名無しさん [sage] 2009/11/19(木) 17:57:54 ID: Be:
    プロトタイプ宣言せんでDLLの関数呼び出したりするのか 

992 デフォルトの名無しさん [] 2009/11/19(木) 18:04:05 ID: Be:
    >>991
    スレ違いになるので詳細は説明せんが
    もろにそういうのがある 

993 989 [sage] 2009/11/19(木) 18:05:41 ID: Be:
    これだとLCC C++非対応コンパイラで動作するけど、参照削ると動かん 
    だから>>985の説は間違えてる。

    //main.cpp
    #include <windows.h>
    extern "C" int WINAPI add(int &x,int &y){
    int z;
    z=x;x=y;y=z;
    z=x+y;
    return z; }

    //main.def
    LIBRARY DLL
    EXPORTS
    add

    //test.c
    #include<stdio.h>
    #include<windows.h>
    typedef int (WINAPI *fnc)(int&, int&);
    main(){
    HINSTANCE hd = LoadLibrary("dll.DLL");
    fnc add = (fnc)GetProcAddress(hd,"add");
    int a,b;
    a=5; b=4;
    printf("a+b=%d a=%d b=%d\n", add(a,b), a, b);
    getchar(); } 

994 デフォルトの名無しさん [sage] 2009/11/19(木) 18:07:52 ID: Be:
    どのCコンパイラでも、fnc(int&);というのは通るんですか? 

995 デフォルトの名無しさん [sage] 2009/11/19(木) 18:09:56 ID: Be:
    >>993
    >typedef int (WINAPI *fnc)(int&, int&);
    だからこれ参照渡しだっつの阿呆。 

996 デフォルトの名無しさん [sage] 2009/11/19(木) 18:12:50 ID: Be:
    利用側 typedef int (WINAPI *fnc)(int*, int*); で宣言
    add(&a, &b); で実際に呼び出す

    これ以外の文法は Cの範疇外じゃないの? 

997 デフォルトの名無しさん [sage] 2009/11/19(木) 18:23:34 ID: Be:
    >>993 何、その独自変態拡張? 

998 デフォルトの名無しさん [sage] 2009/11/19(木) 18:28:49 ID: Be:
    C++において記号&は2通りの意味で使われる。一つはCと互換。
    もう一つはC++独自の拡張(ただし、ある程度は混同できる)
    Cでは一通りの意味しかない。 

999 999 [sage] 2009/11/19(木) 18:32:15 ID: Be:
    999 

1000 デフォルトの名無しさん [sage] 2009/11/19(木) 18:39:56 ID: Be:
    1000です 

続きw


C言語なら俺に聞け(入門編)Part 56 

2 デフォルトの名無しさん [] 2009/11/19(木) 18:47:37 ID: Be:


    一見正しいように見えて間違っているもの

    「関数に引導を渡すにはどうすればいいのですか」



    デバッグは大抵こんなもんである。 

3 デフォルトの名無しさん [sage] 2009/11/19(木) 19:06:59 ID: Be:
    参照渡しの続きをお願いします 

4 デフォルトの名無しさん [sage] 2009/11/19(木) 19:12:38 ID: Be:
    Cでは値渡し使えない。さらにポインタが使えなければ関数に自分の
    変数を変えてもらうような処理フローが使えない。ただそれだけ。 

6 デフォルトの名無しさん [sage] 2009/11/19(木) 19:14:02 ID: Be:
    >>4
    Cでは値渡ししか使えない
    の間違い 

■_ 本日の巡回から

2009年11月18日

■_

・土木の日
だったそうです。

・ぼっと
ついったのbotですがいろいろあるんですね。 ということで 後藤喜一 (taichoh_bot) on Twitter この方をフォローしてみたり。 Twitterのアニメ・ゲームなどのキャラクターbotまとめ - Twiwiki::TwitterまとめWikiサービス んー。

・縦読み
天地珍: つらつらぐさ 以前、わたしは英語圏の人は本屋なり、図書館の書架や棚に並べられた本の背表紙を見るときに 首を傾けないでもタイトルを認識できるのだろうか不思議に思っていたことがありました。 自分は傾けないと読みづらかったですし。 で、出張でアメリカに行ったときに、現地の書店に行ってみて納得しました(以下略)

■_ Parrot

あーなんか一ヶ月たつのが早い。 もう月例リリースか。

Parrot 1.8.0 "Zygodactyly" Released! - nntp.perl.org

On behalf of the Parrot team, I'm proud to announce Parrot 1.8.0 "Zygodactyly".

(略)

Parrot 1.8.0 News:

- Functionality
  + The FileHandle PMC now exposes the exit code of child process that was run as pipe.
  + Experimental support for overriding VTABLE invoke in PIR objects was added.
  + The method 'type' was added to the PackfileAnnotations PMC.
  + The internals of the parrot calling conventions, PCC, were reworked.
    All call paths now use a CallSignature object for passing arguments and return values.
  + The new API-function  'Parrot_ext_call' was added for calling into C-land.
  + The fixed-size allocator was improved.
  + The files installed by 'make install-dev' are now covered by 'make install' as well.
  + The experimental ops 'fetch' and 'vivify' were added.
  + The -I option to the command 'parrot' now prepends items to the search path.
  + The Context struct was substituted with auto attributes (context_auto_attrs branch).
  + Use the osname determined in auto::arch in subsequent configuration steps (convert_OSNAME branch).
  + Eliminated dependence on Perl 5 '%Config' in auto::format (auto_format_no_Config branch).
  + MultiSub PMCs now stringify to the name of their first candidate,
    instead of the number of candidates.
  + The platform detection at the start of the configuration process was improved.
  + The 'lineof' method on CodeString objects now precomputes line number information
    to be more efficient on variable-width encoded strings.
  + P6object now supports .WHO and .WHERE methods on protoobjects.

(略)

Many thanks to all our contributors for making this possible, and our sponsors
for supporting this project.  Our next scheduled release is December 15th 2009.

Enjoy!

ビルド環境壊しちゃったから(ICUやら必要だし)、もう一回作らないといけないのだけど めんどいなあ。はう。

■_ セキュアコーディング

お、これは。なんか期待しちゃうぞ。

脆弱性体質の改善 ――C/C++セキュアコーディング入門(1):CodeZine

はじめに

 皆さんこんにちは。JPCERTコーディネーションセンターという組織でセキュアコーディングに
関する取り組みに携わる筆者らが、これからこの連載を担当させていただくことになりました。
どうぞよろしくお願いします。なお、JPCERTコーディネーションセンターは、情報セキュリティ
インシデントへの対応支援や、ソフトウエアの脆弱性(いわゆるセキュリティホール)に関する
製品開発者間における公開日の調整や関連情報の公開なども行っています。

 この連載では、バッファーオーバーフロー等の脆弱性をうっかり作り込んでしまったがために、
数千万円ものコストをかけて、ユーザに告知し、製品を回収して、工場でファームウェアをアッ
プデートする事態に陥ったり、あるいは脆弱性を放置してユーザを危険にさらし、それが明るみ
に出て「世間を騒がす」ことになったりしなくても済むように、そもそもの製品開発時からセキ
ュアなプログラムを書くために必要なノウハウをお伝えする予定です。そんな「悲劇」が自分の
身に降りかからないとも限らない、ということを実感していただければ幸いです。

 本連載のベースになっているのは、当組織も参加しているプロジェクトが公開している「CERT 
C セキュアコーディングスタンダード」(以下、CERT C)というドキュメントです。CERT Cは、
米国カーネギーメロン大学SEI/CERTのスタッフを中心に世界中のCのプロフェッショナルが作成
したCのコーディング規約集で、wikiを使って作成されており、現在もなお更新され続けていま
す。

 数あるコーディング規約の中でCERT Cが特徴的なのは、セキュリティの観点から、どのような
コーディングが脆弱性を作り込んでしまうのかをまとめているという点にあります。バグがプロ
グラムの不具合につながるのに対し、脆弱性には単なる不具合にとどまらず、外部の攻撃者が脆
弱性を突いてユーザを危険にさらすリスクがあります。実際に脆弱なコードの多くは、「よくあ
るコーディングエラー」が原因で作り込まれています。そのようなコーディングエラーを特定し、
正しくコーディングする方法をまとめたものが CERT C のルールとレコメンデーションという形
で提供されています。

言語仕様が落とし穴になる

(略)

 次回以降の本連載の構成は、14のカテゴリーに分類された CERT Cのルールから、ポインタ演
算、動的メモリ管理、文字列操作、型変換などのトピックを選んで解説しつつ、セキュアコーデ
ィングに活用できるツールの紹介やセキュアなプログラム開発全般の話題も折り混ぜていく予定
です。お楽しみに。

まあ本も出てるけど(最近日本語訳も出ました)、こういうのがあってもいいと思う。

CERT Cセキュアコーディングスタンダード C/C++セキュアコーディング (SEI SERIES・A CERT BOOK) The CERT C Secure Coding Standard (SEI Series in Software Engineering)

■_ うーむ

知恵袋あたりでありそうな話だけど。



How can I go from noob programmer to Ruby web app developer in a month? : ruby

heya

I have some basic understanding of HTML, PHP and CSS... I wouldn't call myself a 
programmer, and I haven't done a degree in compsci. However I'm planning to create a 
web app within the next month or two and hope to get to the point sometime in the 
future where I can program any kind of web app prototype.

Any idea/links/tips on how I can learn and put together a web app in Ruby within a 
month?

cheers

EDIT: Wow, thanks for the responses all... much appreciated :)

いくつもコメントが付いてますがその中からひとつ。

I have a basic understanding of how to open tins of beans, make toast, and prepare 
microwave popcorn. I wouldn't call myself a gourmand, and I haven't done any chef 
training. However, I'm planning to open my own restaurant within the next month or two, 
and hope to win a Michelin Star sometime in the future.

Any ideas/links/tips on how I can make a complete asshat of myself in public?

Yes, web application development is a skill that may be learned and developed: just 
like gourmet cooking, public speaking, or sword swallowing. But although Ruby is a 
comparatively friendly language, there is almost nothing inherent in its design that 
will save you from having to make informed decisions about the design and architecture 
of an application. Let me save you some time: this is not something you will get from 
a book, because the books people will tell you to read will teach you how to implement, 
not how to think for yourself. Rails won't save you from having to know how to 
optimise your database queries, or load-balance your servers. Rails won't teach you 
how to write a web application any more than a fancy spatula will teach you how to 
make a better omelette.

Yes, you can be a self-taught web developer. But be prepared for a fuckload of work, 
failure, and repetition. Be prepared to spend entire days hunting down a simple typo. 
Be humble, be patient, learn from your mistakes, read everything you can. Exercise 
your lateral thinking skills, because the first way you think to do something is 
almost never the right way, and you have to train yourself to think through several 
alternatives before you touch a keyboard. Draw diagrams. Write notes. Think 
analogously.

Yes, you can build a web application in a month. But don't expect anybody to pay for 
it, or use it, or even see it. Be ready to throw everything away at the end of the 
month except what you've learned about yourself and your own process.

きびしーw

■_ ばんぺいくん

珠玉のプログラミングは旧版(タイトル違いますが)含めて持っているはずなんだけど どこへ行ったのやら。

13 章「探索」 - 珠玉のプログラミング(Programming Pearls) - ひげぽん OSとか作っちゃうかMona-

13.6.7

nullの部分を番兵に置き換える。メリットあるの?

二分木でばんぺいくん使ったらどうかって話ですよね。

    sentinel.value = search_value;
    p = root;
    while (p-> != seach_value)
        if (p-> > seach_value)
           p = p->right;
        else
           p = p>left;

    return p == &sentinel ? FOUND : NOTFOUND;
    

なかんじですか。確かに線形リストみたいにきれいにループ本体の条件判定が 消えないですからねえ。

Amazon.co.jp: ああっ女神さまっ シーグル&ばんぺいくん 通常版: おもちゃ

■_ 上下関係とかあるのか?

from ム板。


【Perl,PHP】LLバトルロワイヤル7【Ruby,Python】
887 デフォルトの名無しさん [sage] 2009/11/18(水) 00:12:24 ID: Be:
    小、中規模のWebアプリをいくつか作らなければならないが、
    同僚がどうしてもPerlが良いという。
    Perl  - 枯れてて信頼性がある
    Java  - 信頼性がない
    Python - 知らん
    Ruby  - 論外
    PHP  - Perlの子分だから、まぁ許せる
    という事だそうなのだが、どうも今更PerlでWebは俺は抵抗を感じる。
    上記の理由にも非常に違和感を感じるが、どう理論立てて反論していいか解らん・・・。
    漠然と、Perlは書き捨てのスクリプトなら書きやすいとは思うが、
    それ以外に向いてると思えない。
    Perl以外を推めるのに、どう説得すれば良いと思います? 

888 デフォルトの名無しさん [sage] 2009/11/18(水) 00:30:44 ID: Be:
    PerlにあってJavaにない信頼性って何ものなんだろう。
    ウェブアプリを作るにあたって、Catalystなりのフレームワークを使うなら別にいいのでは。
    オレオレフレームワークや素のCGIで作る気なら、その後の保守に困るだろうね。
    その同僚がずっと面倒みるならいいけど。 

889 887 [sage] 2009/11/18(水) 00:45:29 ID: Be:
    そうなんです、それ(信頼性)が説明できなくて・・・。
    Catalystも、例えばRailsと比較して、書かなくてもいいことを書かせてる、
    と思えてしまい、あまり好きではないです(これは完全に自分の好みですが)。
    もっとも、Catalystを使う事すら視野に入れてないようでしたが。 

890 デフォルトの名無しさん [sage] 2009/11/18(水) 01:58:32 ID: Be:
    同僚は根拠出してきてないんでしょ
    議論にならんじゃん 

891 デフォルトの名無しさん [sage] 2009/11/18(水) 02:31:15 ID: Be:
    PHPはCの子分ではあってもPerlの子分ではありません。
    どっちかと言うとRubyのほうがPerlの子分と言えるでしょう 

892 デフォルトの名無しさん [sage] 2009/11/18(水) 02:38:19 ID: Be:
    結局まともな言語が一つもないって事でおk?
    今ここで挙げられた欠点を補うようなそれなりの言語作れば決定打になるんじゃね。 

893 デフォルトの名無しさん [sage] 2009/11/18(水) 03:09:27 ID: Be:
    Luaこそ至高。Lua以外のLLは勉強しなくて良い 

894 デフォルトの名無しさん [sage] 2009/11/18(水) 04:38:55 ID: Be:
    >>891
    部分的に文法は似てるとはいえCとは全く異質のものじゃない?
    Perlのモジュールだったから子分って表現したんだろうと思うけど。 

895 デフォルトの名無しさん [sage] 2009/11/18(水) 12:34:09 ID: Be:
    まー、その中ならPHPかなー。
    入社1年目の人にみっちり教えたら書けるようになったし。 

897 デフォルトの名無しさん [sage] 2009/11/18(水) 19:18:57 ID: Be:
    >>890
    それはどっちとものようだが。w

    一方はぜひPerlと主張し、他方はなんか
    違和感があるからと言い訳を探す。
    この争いだったら、ぜひと言ってるほうが
    勝つべき。

899 デフォルトの名無しさん [sage] 2009/11/18(水) 19:50:18 ID: Be:
    >>887
    まず、そこに挙げられている言語なら、どれも十分枯れている。
    どの言語でも、枯れたバージョンと枯れてないバージョンがあり、枯れたバージョンを使うならどれも同じぐらい枯れている。
    もちろん枯れてないバージョンを使えばバグにぶつかる可能性が高いのも、どの言語でも同じ。
    たとえばPythonは2.5系と2.6系はどちらも枯れている。3.xは枯れてない。
    PHPは(私見だが)5.2.11は十分枯れている。5.3はまだ枯れてない。
    Rubyは、1.8.6はすごく枯れている。1.8.7も十分。1.9はまだ。
    JavaはJava5とJava6は十分枯れている。Javaが枯れてないというなら、その根拠を示すよう、その同僚とやらに聞いてみろ。
    大事なのは枯れているバージョンを使うことであって、言語じゃない。

    あと、枯れ具合を気にするべきは言語じゃないくて、フレームワークやライブラリのほう。
    かりに「枯れているから」という理由でPerlを選んだとしても、Moose使ったら意味がない。
    また言語のバグよりもフレームワークのバグの方がずっと多いので、
    フレームワークの枯れ具合を気にしてないのに言語の枯れ具合を気にするのは、はっきりいってバカ。

    まとめ:
    ・枯れているバージョンを使えば、どの言語でも十分枯れているし信頼性はある。
    ・気にすべきはフレームワークの枯れ具合であって、言語のではない。

    ・・・とりあえず、これで言語を選ぶ理由として「枯れ具合」を持ち出すのは止めさせられるだろう。

900 デフォルトの名無しさん [sage] 2009/11/18(水) 20:33:33 ID: Be:
    >>894
    それ言うとPHPer(笑)がファビョるよね。
    RubyやPythonが問題外なのは当然であり格下のPerlがルーツなのは
    自尊心が傷つくらしい。 

901 デフォルトの名無しさん [sage] 2009/11/18(水) 21:26:40 ID: Be:
    >>887
    Ruby論外っていうPerl使いは、大抵、Rubyを使ったことない奴。ちゃんと調べたこともない。
    簡単。お子様仕様。お遊び。とか勝手にイメージ持ってたりしてる。

    Rubyが流行った理由がRailsだから、簡単というのは合ってはいるんだが、
    Perl使いも結局、RailsインスパイアなCatalyst使うわけで。 

902 887 [sage] 2009/11/18(水) 22:04:20 ID: Be:
    様々な意見、ありがとうございます。とても参考になります。
    違和感がある、と言ったのは、特にJavaが信頼性がなくて、
    Perlが信頼性があるとの意見です。
    Javaは基幹系に使われてるのは見聞きますが、Perlで、というのは聞いたことがないですし。
    PerlはMoose使わないとまともにClassっぽいものも書けないし。
    枯れを気にするよりも、自分のプログラム技術の方を心配しろとも思ってます。
    Perlは単純に今の時代のWeb作成には、多言語に比べ劣っている、
    というのが、私のPerlを回避したい理由です。
    実は同僚と言っても、かなり年上で反論し難いので自分の意見が言えなかったことも
    ありますが、明日、意見交換会を行うので、勇気出したいと思います。
    PHPは学びやすい言語で、私もそれなりに好きなんですけども、
    ところどころ、致命的に好きになれない部分もあるので、
    Ruby、Javaを押したいと思っています。
    Pythonも個人的には気になりますが、名前が(うちでは)あまりにも知られていないので・・・。
    Rubyをなぜかすごい嫌ってるんですよね・・・。なんでだろ・・・。 

903 デフォルトの名無しさん [sage] 2009/11/18(水) 22:13:21 ID: Be:
    >>902
    いや、まあ、ここだけでもつっこんでみるけど

    > Rubyをなぜかすごい嫌ってるんですよね・・・。なんでだろ・・・。

    自分のレスを3回くらい読み直して、嫌らしいところが全くないって断言できるんなら、
    あんたにはそれは一生わからんだろうと。
    Perl使いでRubyを嫌ってる人間のほとんどは、言語そのものを嫌ってるわけじゃなかろうと思う。

    > PerlはMoose使わないとまともにClassっぽいものも書けないし。
    「まともにClassっぽいものを書けな」きゃそれでだめってのも能力の幅的にどうかという見方も
    あるっちゃあるだろうしなあ、とも思った。 

904 デフォルトの名無しさん [sage] 2009/11/18(水) 22:13:25 ID: Be:
    LLには信仰心の問題もあるからな

    でもJavaをweb用途に使うことの善し悪しは別として、
    信頼性がないとかいいきっちゃう人の言うことには耳を貸したくないね。
    金が掛かるとかならまあわからんでもないけどw 

905 デフォルトの名無しさん [sage] 2009/11/18(水) 22:15:03 ID: Be:
    rubyは僕みたいな糞でも使える神言語 

906 デフォルトの名無しさん [sage] 2009/11/18(水) 22:19:44 ID: Be:
    俺も糞だけどPythonのほうが使いやすかったな 

907 デフォルトの名無しさん [sage] 2009/11/18(水) 22:28:38 ID: Be:
    >>898
    それがどうかしましたか?

    >>902
    あなたの意見を総合的にまとめると
    Ruby より Python を使った方が良いと思う

908 887 [sage] 2009/11/18(水) 22:40:38 ID: Be:
    同僚がRubyをすごい嫌ってることと、自分が嫌らしい人間だということの
    関連性が解りませんが、Perlは自分もリアルタイムで使ってますので、
    嫌いではありません。
    それでも、Catalystを使うのと、Railsを使うのではRailsを使う方が、
    コードの書きやすや、見やすさから良いと思いました。
    Classっぽいものを書けない、というのは一例です。
    ここがダメ、あそこがダメ、と書いても冗長かと思いましたので。
    当然、Ruby含め、他の言語も一長一短で、Perlの事だけ悪く言ったと思われたなら、
    申し訳ないです、すみません。 

912 デフォルトの名無しさん [sage] 2009/11/18(水) 22:51:13 ID: Be:
    >>908
    その上司は Ruby を嫌ってるんじゃなくて
    お前を嫌ってるんじゃないのか? w 

913 887 [sage] 2009/11/18(水) 22:54:22 ID: Be:
    >>912
    それはあ・・・、いや、実はもう一人Java派の同僚と
    その人が揉めてまして・・・。
    その時自分は日和って、「自分は何でもいいです」というコウモリ君になりました。

914 デフォルトの名無しさん [sage] 2009/11/18(水) 23:01:28 ID: Be:
    Java厨はすっこんでろ。スレ違い 

915 デフォルトの名無しさん [sage] 2009/11/18(水) 23:10:00 ID: Be:
    質問を勝手に自分の理解できる範囲の問題に解釈し直すのはいくない 

916 デフォルトの名無しさん [sage] 2009/11/18(水) 23:13:35 ID: Be:
    >>913

    同僚A=Perl派-(もめてる)-Java派=同僚B

    質問者=観戦者=Ruby派

    ってところか
    参戦するつもりが無いならRubyはあきらめろw 

917 デフォルトの名無しさん [sage] 2009/11/18(水) 23:16:40 ID: Be:
    もうJavaでいいな。Perlの人はその会社では辛そうか
    会社ってのは人が作るもんで、むしろJavaとPerlのエキスパートという
    ニッチで頑張ってもらいたいもんだができるかな 

918 デフォルトの名無しさん [sage] 2009/11/18(水) 23:18:02 ID: Be:
    所詮、雇い主との相性 

919 デフォルトの名無しさん [sage] 2009/11/18(水) 23:28:33 ID: Be:
    JRubyで丸く収まるんじゃね?

920 デフォルトの名無しさん [sage] 2009/11/18(水) 23:34:42 ID: Be:
    なんという落としどころw
    Perl野郎全敗なだけじゃないか。納得しそうで怖いわw 

■_ 本日の巡回から

2009年11月17日

■_

・今日の日めくり
Learn to walk before you run.

・限定版
OADつきの絶望先生19巻、ひとつ前のがちょっとだぶつき気味だったせいか 今回の出荷数は少なめ?

■_ History of Programming Language

Scripting Languages and the Web

Scripting Languages and the Web (スクリプティング言語とWeb)

When Tim Berners-Lee first proposed the “Mesh” (later renamed to the World Wide Web) 
to CERN back in 1989, the concept was much simpler than it has become today.  The 
problem Berners-Lee sought to solve was how to establish links between the massive 
number of related documents generated world-wide by CERN projects, especially the LHC. 
So he focused primarily on hyperlinked text.  In a section of the proposal titled “
Bells and Whistles”, we read:

1989年の CERN で Tim Berners-Lee が最初に“Mesh”(のちに World Wide Web と改名されまし
た) を提案したとき、そのコンセプトは今日のそれよりも格段に単純なものでした。
Berners-Lee が解決を試みた問題とは、CERN プロジェクト、特に LHC によって world-wide に
生成された関連する大量なドキュメント間のリンクをいかにして establish するかというもの
でした。そして彼はハイパーリンクされたテキストにフォーカスしました。
“Bells and Whistles” というタイトルのセクションにこういった部分があります:

    Storage of ASCII text, and display on 24×80 screens, is in the short term sufficient,
    and essential. Addition of graphics would be an optional extra with very much less
    penetration for the moment.

(ASCII テキストのストレージと 24×80 スクリーン上での表示は短期的には十分なものであり
本質的なものです。グラフィックの追加はそれほどの時間をおかずにそれほどのペナルティな
しに行えるようになるでしょう)

Never mind embedded videos or Ajax-driven interactivity.  You request a page, you get 
a page.  But in the section titled “Live links” we get a glimpse of the web's future:

埋め込まれたビデオや Ajax-driven な対話性 (interactivity) を気にすることはありません。
あなたはページをリクエストすれば、ページのデータが得られるのです。しかし “Live links” 
というタイトルのついたセクションでわたしたちは web の将来を glimpse (垣間見る) しまし
た。

    Hypertext allows documents to be linked into “live” data so that every time the link
    is followed, the information is retrieved. If one sacrifices portability, it is
    possible to make following a link fire up a special application, so that diagnostic 
    programs, for example, could be linked directly into the maintenance guide.

(ハイパーテキストではドキュメントの“live”なデータに対するリンクが可能なので
リンクが follow される度に情報の取得が行われます。もし誰かが可搬性 (portability) を
犠牲にして特殊なアプリケーションへリンクする follow を可能にしたならば、
検査プログラム、たとえばメンテナンスガイドへダイレクトにリンクすることも可能になるでしょう。)

Server-side scripting (サーバーサイドスクリプティング)

In usage, it soon became apparent that the more “live” the data, the more useful the 
site.  Nevertheless, it took a few years for server-side programming to standardize on 
the Common Gateway Interface (CGI), which uses environment variables and standard 
input/output to transfer data to/from a separate executable (or later, an embedded 
module of the web server).  All those who have written CGI programs in C or Bourne 
Shell please raise your hands (if you still can).  The Perl language soon proved to be 
a far superior alternative to either of these for CGI programming - partly because it 
combined some of the best features of both, but mostly because of its advanced 
capabilities for manipulating strings and regular expressions.

使っていくうちにすぐにより“live” なデータが見られるようになり、サイトが便利になって
いきました。とはいうものの、ほんの数年でサーバーサイドのプログラミングは Common 
Gateway Interface (CGI) に標準化されました。これはデータの送受信を分割された実行ファイ
ルで行うために環境変数や標準入出力を使うものです(のちに、webサーバーに組み込まれるモジ
ュールにもなりました)。C や Bourne シェルで CGI プログラムを書いたことのある人は手を上
げてください(もし今でも書けるのなら)。Perl という言語がすぐに CGI プログラミングの向け
のもので群を抜いた存在になりました。それは部分的にはいくつかの機能の組み合わせ、とくに
Perl の文字列や正規表現についての advanced capabilities によるものでした。

But using any of these languages requires you to explicitly output the entire returned 
page, even the static parts.  Web developers wanted to be able to write plain HTML, 
and add scripting code where needed for the dynamic bits.

しかしこれらの言語のいずれかを使った場合、あなたは返すページ全体をそれが静的なものであ
ってもはっきりした形で出力することが要求されます。Web 開発者は plain なHTML を書けるよ
うになっていることと、動的要素 (dynamic bits) が必要なところにスクリプティングコードを
追加できることを望んでいました。

PHP arose as an answer to that problem.  Any content in a PHP page that isn't within 
the <%php and %> delimiters is simply output as-is, within the execution context of 
the code that is within those delimiters.  That code is Perl-like - but much simpler 
and less consistent, betraying a history that contains more evolution than intelligent 
design.  Hundreds of inconsistently named base functions in a single, global namespace 
often make finding the right way to do something a lengthy exercise in searching 
php.net.  Yet, PHP powers many of the most visited sites on the web, including 
Wikipedia, Yahoo!, Facebook, and millions of WordPress blogs (including this one), 
perhaps because of its simple (though numerous) functions to access back-end databases.

PHP はこういった問題に対する回答として登場しました。PHP によるページのすべてのコンテン
ツは<%php と %> で区切られ単純に出力されるままの状態で存在していて、実行されるコ
ードはそのデリミターの内側に置かれています。PHP のコードは Perl に似ていますが、Perl 
よりも単純かつ一貫性に欠けるものであって、intelligent design というよりは、 evolution
からできているという歴史をさらけ出しています。統一されていない命名規則による数百の関数
が単一のグローバルな名前空間に存在しているので、何かを行う正しい方法 (right way to do 
something) を見つけ出すために php.net での検索という冗長なエクササイズを嫌というほどや
る羽目になります。それでも PHP は web 上にある most visited sites の多くで力を振るって
います。そういったサイトにはWikipedia、Yahoo!、Facebook、そしてWordPress を使った数多
くのblog (ここも含みます) がありますが、それはおそらく、PHPにはバックエンドのデータベ
ースにアクセスするための関数が、単純ではあっても数がたくさんあるおかげでしょう。

I shouldn't fail to mention a couple of similar but less widely used alternatives:  
JavaServer Pages (JSP) and ColdFusion's CFML.  Both allow the insertion of special 
tags into an HTML-like page to direct the generation of dynamic web content.

二つのよく似てはいるけれどもあまり広くは使われていないものについて言及するのを忘れるべ
きではないでしょう: JavaServer Pages (JSP) と ColdFusion の CFML がそれです。両方とも、
動的な webコンテンツの生成をダイレクトに行うための HTML に似た独自タグを挿入することを
許しています。

Active Server Pages (ASP) provides a capability similar to PHP, but for Microsoft IIS 
Servers.  The <% and %> delimiters demarcate script embedded within HTML.  By 
default, the scripting language is VBScript, though JScript (an implementation of 
JavaScript) and PerlScript (derived from Perl) can be used instead.  The syntax of 
VBScript is, as the name implies, much more like Visual Basic than like C or Perl - 
which means that it's simpler and less expressive than even PHP.
ASP.NET represents a stark departure from the scripting model of web design.  

Active Server Pagese (ASP) はPHPのような能力を提供するものですが Microsoft の IIS 
Server 向けです。HTML 中に埋め込まれたスクリプトの境界は  <% と %> で表します。
デフォルトのスクリプティング言語は VBScript ですが、JScript (JavaScriptの一実装)や
PerlScript (Perlから派生したもの)を代わりに使うこともできました。VBScript の構文はその
名前に暗示されているようにC や Perl よりも Visual Basic にずっと近いものです。そしてそ
れは、PHP よりもさらに単純で、less expressive だということを意味しています。APS.NET は 
web デザインの scripting モデルから完全に departure (逸脱、発展)したものを提供していま
す。

Development of web pages more closely resembles desktop GUI development, and the 
result is a compiled assembly rather than a runtime-interpreted script.  Any .NET CLR 
language can be used for the code behind (for the vast majority, that means Visual 
Basic .NET or C#).  While this model may be more comfortable for programmers who grew 
up on Visual Basic (assuming that's even possible), I find the number of things that 
are done for you behind the curtain to be a little unsettling.

web ページの開発は、デスクトップ GUI の開発にとてもよく似ているもので、その結果は実行
時に解釈されるスクリプト (rutime-interpreted script)というよりはcompiled assembly (コ
ンパイルされたアセンブリ) になっています。すべての .NET CLR 言語を陰に隠れているコード
として使うことができます(for the vast majority, that means Visual Basic .NET or C#)。
このモデルは Visual Basic (それが使えたと仮定して) と共に成長してきたプログラマーにと
ってはより comfortable であったかもしれませんが、
I find the number of things that 
are done for you behind the curtain to be a little unsettling.

Ruby also provides the ability to embed code in HTML, via eRuby.  Several such 
templating systems are available for Python as well.  Both of these languages offer 
excellent support for standard CGI programming, too.

Ruby もまた eRubyを経由して HTML に埋め込む能力を提供しています。同様なテンプレートシ
ステムのいくつかが Python でも使えます。これらの言語の両方ともが、標準的な CGIプログラ
ミングの素晴らしいサポートも一緒に提供しています。

A number of web frameworks have been built on top of these languages, often employing 
the model-view-controller design pattern.  Some of the more popular include Ruby on 
Rails (for Ruby), Django (for Python) and (still in preview) ASP.NET MVC for ASP.NET.  
These frameworks offer the advantage of nearly eliminating duplicated effort between 
projects that more or less follow the standard pattern.

これらの言語を使って数々のwebフレームワークが構築されましたが、それらのほとんどは 
model-view-controller という設計パターンを使用しています。より一般的なものを幾つか挙げ
ると、Ruby 向けの Rubyy on Rails、Python 向けの Django、ASP.NET 向けの ASP.NET MVC (ま
たpreview段階)があります。これらのフレームワークは、標準的なパターンに従っていようとい
まいと複数のプロジェクト間での労力の重複を避けやすい(nearly eliminating duplicated 
effort) という利点があります

Client-side scripting (クライアントサイドスクリプティング)

Generating all your web content on the server side may give you a nice sense of 
control, but it sure makes for some clunky user interface if every update has to be 
achieved by requesting a whole new page.  To make pages more interactive, you want to 
be able to direct the browser's actions by embedding scripts within the page that is 
sent to the client.

あなたの web content をすべてサーバーサイドで生成することはあなたに nice sense of 
control を与えるかもしれませんが、新しいページ全体をリクエストすることによってすべての
更新を行う必要があればそのために確実に some clunky user interface になってしまいます。
ページをより対話的にするために、スクリプトをクライアントに送ったページの中に埋め込むこ
とによって直接ブラウザーのアクションを行えることをユーザーは望んだのです。

Brendan Eich invented the JavaScript language for this purpose, and it was first 
included in Netscape back in 1995.  Despite its name, this language is only 
superficially similar to Java - it's really a much more dynamic and functional 
language than Java could ever be.  It started out in life making little bits of web 
pages more interactive - for instance, if you didn't need to go to the server to 
validate a field, you could alert the user as soon as they modified it.

Brendan Eich がこの目的のために JavaScriptを発明し、1995年に初めて Netscape に取り込ま
れました。JavaScript という名前とは裏腹にこの言語が Java に似ているのは表面だけで、
Java よりももっと動的で関数型的な言語に近いものです。JavaScript は web ページをもっと
対話的なものにするためのものとして始まりました。たとえばサーバーにフィールドのバリデー
ションをやらせる必要がない場合に、ページが変更されたことをユーザーに警告できました。

Internet Explorer added scripting capabilities in two available languages: VBScript 
and JScript.  The latter was similar to JavaScript, with just enough differences to 
drive a web developer crazy.  In recent versions, Internet Explorer has moved closer 
towards more standards compliance, but there are still enough differences to evoke the 
frequent “Curse you, IE!”

Internet Explorerには VBScript と JScript という二つの言語を使用可能にする能力が追加さ
れました。後者は JavaScript に似たものですがweb 開発者を狂気に導くのには十分な違いを持
ったものです。最近のバージョンでは Internet Explorer はより standards compliance にぐ
っと近寄りましたが、それでもまだ “Curse you, IE!”(IE 爆発しろ!) という呪詛の言葉を
吐くのには十分な違いが存在しています。

The standard for the JavaScript language is properly called ECMAScript, after the Ecma 
International organization to whom Netscape passed control of the standardization 
process for JavaScript.  Most modern browsers now support some level of the ECMAScript 
standard.

この JavaScript という言語のための標準は、Netscape がJavaScript の標準化プロセスをコン
トロールを委ねたEcma International organization に由来して ECMAScript と呼ばれることが
あります現時点でのほとんどのモダンなブラウザーは、この ECMAScirpt standard をなんらか
のレベルでサポートしています。

One of the more exciting developments in JavaScript in recent years has been the rise 
of AJAX, which stands for Asynchronous JavaScript And XML (although XML need not 
actually be involved).  The key to this technique is the ability in JavaScript to send 
an HTTP request to the web server and retrieve a result without reloading the current 
page in the browser.  Then the JavaScript can evaluate what it retrieved, and apply 
any necessary changes to the page without a full repaint.  Originally, the data was 
always returned as XML (hence the X), but recent refinements include returning JSON 
instead - a format that is easily converted into JavaScript objects (but not without 
security concerns).

近年における JavaScript を使った more exciting developments の一つが Asynchronous 
JavaScript And XML 、略称して AJAX (実際には XMLは必須ではないのですが) と呼ばれる手法
の流行です。この手法のキーとなるのはwebサーバーにHTTP リクエストを送り、その結果をブラ
ウザーのカレントページのリロードをすることなしに受け取れるというJavaScript の能力です。
JavaScript は受け取ったものを評価してページ全体を再描画することなしに任意に必要な変更
を適用することが可能です。元々データは常にXMLとして返されていましたが最近では代わりに 
JavaScirpt のオブジェクトに間単に変換できるフォーマット(ただしセキュリティの問題があり
ます)である JSON で返されるという改良がありました

I love JavaScript as a language.  When I write something in JavaScript, I feel happy 
for some reason.  It's a light, agile, but powerfully dynamic scripting language.  
However, I've often wondered why more browsers don't support multiple scripting 
languages.  No, I'm not a VBScript fan (far from it), but wouldn't it be nice to be 
able to script both the client and server side in Ruby, for instance?  Unfortunately, 
for any new client-side scripting language to become viable, it would first have to be 
implemented by all of the major browsers.  And I'm afraid the script for that dream is:

わたしは言語として JavaScript が大好きです。JavaScript で何かを書くときはいくつかの理
由で嬉しさを感じます。JavaScript は軽量で agile なものですが、強力で動的なスクリプティ
ング言語でもあります。とはいうものの、わたしは、なぜもっと多くのブラウザーが複数のスク
リプティング言語をサポートしないのだろうかとよく不思議に思うのです。いえ、VBScriptは楽
しくありません (楽しさとはかけ離れたところにあります)が、それでもたとえば Ruby でクラ
イアントサイドとサーバーサイドの両方のスクリプトを書けるようになれば素晴らしいことでは
ないでしょうか? 残念なことにどんな新しいクライアントサイドのスクリプティング言語も、生
き残るためにはまず初めに主要なブラウザー全てで実装される必要があるのです。
And I'm afraid the script for that dream is:

alert("They've got too much to do already");

This post is Part Four in a series on the history of programming languages.  Here are 
links to the previous installments:

    * The Early History of Programming Languages
    * An introduction to object oriented languages
    * The ascent of scripting languages

Related Posts:

   1. The ascent of scripting languages
   2. The Early History of Programming Languages
   3. An introduction to object oriented languages
   4. Internal Software Development Moves to the Web Browser

■_ チカラワザ

ついった経由 Twitter / tnozaki: しかしnawkのdecimal pointもずいぶん ...


Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

===================================================================
RCS file: /ftp/cvs/cvsroot/src/dist/nawk/main.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- src/dist/nawk/main.c	2009/03/01 23:30:52	1.9
+++ src/dist/nawk/main.c	2009/11/15 21:56:06	1.10
@@ -35,7 +35,6 @@ const char	*version = "version 20070501"
 #include <stdlib.h>
 #include <string.h>
 #include <signal.h>
-#include <locale.h>
 #include "awk.h"
 #include "awkgram.h"
 
@@ -102,6 +101,7 @@ static void fpecatch(int n
 int main(int argc, char *argv[])
 {
 	const char *fs = NULL;
+	struct lconv *lconv;
 
 	setlocale(LC_CTYPE, "");
 	setlocale(LC_NUMERIC, "C"); /* for parsing cmdline & prog */
@@ -114,6 +114,9 @@ int main(int argc, char *argv[])
 	}
 
 	(void) setlocale(LC_ALL, "");
+	lconv = localeconv();
+	lconv->decimal_point = ".";
+
 
 #ifdef SA_SIGINFO
 	{

なるほどこれは強引な。

どうも複数の修正がごっちゃになってこんなことになっていた模様。

■_本日の巡回から

2009年11月16日

■_

とある夕刊紙に、ロッテからFAでメジャーリーグに行ったコバマサが ジャイアンツに来るとか何とか載ってたけどどうなんだろか。 あ、ジャイアンツってもサンフランシスコのじゃなくて東京のですw

■_ 2010

マルチコア対応アプリ開発やバグ報告を効率化,MSが「Visual Studio 2010」ベータ2版を一般提供:ITpro

同日,Visual Studio 2010のエディション構成も明らかになった。現行のVisual Studio 2008で
は10種類のエディションを展開しているが,「ユーザーからエディション構成が複雑で機能差が
分かりづらいという意見が多かったため」(近藤氏),次期製品ではエディション数を,「
Ultimate」「Premium」「Professional」の3種類に減らした。「Ultimate」は設計から導入まで
すべての工程に対応する最上位版,「Premium」は開発工程向けエディション,「Professional」
は開発のための基本機能だけを備えるエディションとなる。 

んーむ。そろそろVisutal Studio とお別れか喃。 とりあえず F# だけコンソールから使えるようにとかできんのかなあw

■_ え?

…釣り?

Pythonでチャットや掲示板を作りたいのですが日本語の入門書が見つかりません。 - Yahoo!知恵袋

Pythonでチャットや掲示板を作りたいのですが日本語の入門書が見つかりません。

Perlの入門書を買ってこれば大丈夫ですか?

「入門書」つーんだから、言語の本だよねえ。Perl の?

■_本日の巡回から

■_

CS302 2007S : John McCarthy - History of LISP
John McCarthy - History of LISP

McCarthy, J. (1978). History of LISP. ACM SIGPLAN Notices 13(8), pp. 217-223. DOI=
http://doi.acm.org/10.1145/960118.808387

When discussing about conditional expressions (in pg. 218), McCarthy says that
XIF(M,N1,N2) had to be used sparingly since all three arguments had to be evluated
even if M was either zero or not. He says that it led to the invention of the true
conditional expression which evaluated only one of N1 and N2 depending on whether M
was true of false. What is the difference between representing the value of M as
either 0 or 1, or True and False? How are True and False implemented in LISP? C does
not have explicit True and False in which case we define True and False to be 0 and 1
if we ever need to use it.

conditional expressions (in pg. 218) について議論しているときに、McCarthy は三つの引数
は M がゼロであろうとなかろうと評価されなければならないのでXIF(M,N1,N2)  は sparingly
に使われる必要があるのように主張しました。彼はそれが、 M が true であるか false である
かによって、N1 か N2 のいずれか片方だけが評価される本物の conditional expression の発
明に繋がったと主張しています。M の値を 0 か 1で表現するのか、あるいはTrue か False で
表現するかの間にある違いとはなんでしょうか? LISP では True と False はどのように実装さ
れているのでしょうか? C には明確な値としての True や False を持っておらず、そういった
ものが必要になった場合には1 と 0 を True と False に当てはめています。

It's mostly an order-of-evaluation issue. For a traditional procedure, you evaluate
all the arguments before applying the procedure. In the revised version, you only
evaluate some of the arguments.

これはほぼ評価順序の問題です。伝統的な手続きでは手続きを適用する前にすべての引数が評価
されます。改訂版 (revised version) の場合は、一部の引数だけしか評価されません。

I was wondering whether or not data structures were prevalent during the time Lisp was
developed. It is evident why he makes lists the main data structure (functions
themselves are simply lists) but why did he not include a way to make a struct or a
similar data type?

Lisp が開発されていた時期に、データ構造が広く普及していたかどうかがわたしには疑問でした。
それは 彼がリストを主たるデータ構造としたのかという理由の evident (証拠) になります(関
数それ自体が単純なリストです)。しかしなぜ彼は構造体やそれに類するデータ型を作成する方
法を含めなかったのでしょうか?

No, generic mechanisms for making compound data types had not really been invented at
the time Lisp was first developed.

いいえ。compound data types (複合データ型) を作るための generic mechanisms は
Lisp が最初に開発された時点では発明されていませんでした。

Were macros added after this paper was written? He doesn't seem to mentioned them much,
but the other readings seem to emphasize them a lot.

マクロはこの論文が書かれた後で追加されたのでしょうか? 彼はこの件についてはっきりと言及
はしていないようですが、他の文献ではそのことを強調しているものが多くあるようです。

Macros were not part of the original Lisp. I'm not sure when they were added, but they
were a central part of Common Lisp.

マクロはオリジナル Lisp の一部ではありませんでした。マクロがいつ追加されたものなのかは
わたしにはわかりませんが、マクロは Common Lisp の central part となりました。

Also, what exactly is pornographic programming?

また、 pornographic programming とは一体なんなんでしょうか?

I'll get back to you on that.

When McCarthy discusses the creation of a "LISP environment" does he mean
creating the interpreter for the language or is it something else? Assuming that is
what he means, what reasons were there for LISP to be an interpreted language instead
of a compiled language? McCarthy states that the concern was that producing the
compiler would take too long, but were there any other advantages or disadvantages for
favoring an interpreted language over a compiled language?

McCarthy が  "LISP environment" の作成について論じるとき彼はそれを言語のイン
タープリターを作ったという意味で言っているのでしょうか?それとも別の意味で言っているの
でしょうか?彼の意図していたところを仮定したとして、LISP をコンパイル型言語ではなくイン
タープリター型言語にする理由はなんだったのでしょうか? McCarthy はコンパイラーを作るこ
と (producing the compiler) に非常に手間が掛かることに関心があったと主張していますが、
しかしコンパイル型言語ではなくインタープリター型言語を選択させたその他の advantages や
disadvantages はなかったのでしょうか?

Yes, he generally means the interpreter. The big advantage is that it encourages
experimentation - type a little, see the result, type a little more, see the next
result, and so on and so forth. There's also a bit of encouragement in such a system
to write small procedures, which many of us think are good.

確かに彼はインタープリターのことが念頭にありました。インタープリターの big advantage
はちょっとタイプして結果を確認し、さらにちょっとタイプして新しい結果を見るといった手順
で進めることに対するそれはまた、わたしたちの多くがきちんと考えることのできるような小さ
な手続きを記述するためのシステムを encouragement するものでもあります。

McCarthy says that a large number of computer scientists and programmers regard the
fact that LISP programs are lists to be a disadvantage. Why is that so? And why does
he go on to say that this same feature of the language may have contributed to its
survival?

McCarthy は、コンピューター科学者とプログラマーのうちのかなりの数が LISP のプログラムは
リストが disadvantage になっているとみなしていると主張しています。なぜでしょうか?そし
て、なぜ彼は同じ機能をLISPという言語が生き延びることに寄与したのかもしれないと言ったの
でしょうか?

Let me get back to you on that.

The writer of the History of Lisp says that one could conjecture that LISP owes its
survival specifically to the fact its programs are lists. He says that everyone
including him have regarded as a disadvantage. If it is a disadvantage, why isn't it
changed especially considering its so central to Lisp?

writer of the History of Lisp は、プログラムがリストであるという事実が LISP の持つ 
survival specifically であるということを推測できたものがいたかもしれないと言って
います。
He says that everyone including him have regarded as a disadvantage.
もしそれが disadvantage であるのなら、
そしてそれが central to Lisp であったというのならなおのこと
なぜ変更しなかったのでしょうか?


Because it's also an advantage, and he's exaggerating. As the previous writer mentions,
McCarthy also says that lists were key to Lisp's survival.

なぜならそれは advantage でもあるので、彼は誇張しているのです。先述した writer が言及した
ように、McCarty もリストが Lisp が生き残るためのカギであったと言っています。

McCarthy states, "The first succesful LISP compiler was programmed by Timothy
Hart and Michael Levin. It was written in LISP and was claimed to be the first
compiler written in the language to be compiled" How is it possible to write a
compiler in the same language as the language to be compiled?

「最初の成功した LISP コンパイラーは Timothy Hart と Michael Levin によってプログラムさ
れ、そしてそれは LISP で記述されたものであり、コンパイルされる対象となる言語で記述された
最初のコンパイラーである」と McCarthy は主張しています。

How is it possible to write a compiler in the same language as the language to be compiled?

どのようにすれば、コンパイルされるのと同じ言語でコンパイラーを記述することができるのでしょうか?

There are a number of ways, we'll actually cover this issue on Friday. In terms of the
interpreter, seven key operations (plus or minus) are implemented in assembler.
Everything else can be implemented with those key operations. In addition, if there's
an interpreter, then you can interpret the compiler and have that compile itself to
get an executable compiler.

それには多くのやり方がありますが、we'll actually cover this issue on Friday. インタープ
リターの terms では七つのキーとなるオペレーション (plus or minus) がアセンブラーで実装
されました。それ以外のものは、そのキーオペレーションによって実装することが可能です。そ
れに加えて、インタープリターがあった場合、コンパイラーをインタープリットして実行形式の
コンパイラーを得るために自分自身をコンパイルすることが可能です。

LISP puts the operator first in a mathematical expression because "any other
notation necessarily requires special programming". When an operation is
translated into machine code, why would it require special programming? It seems like
it would be a very simple change. Is it there for other reasons besides making the
programming easier?

LISP は演算子を算術式 (mathematical expression) の先頭に置きます。それは、「その他のど
んな表記法も特殊なプログラミングを必須としてしまう」からです。ある操作が機械語に変換さ
れたときに、なぜそれが特殊なプログラミングを必要とするのでしょうか?それは非常に単純な
変更であったように思われます。プログラミングを簡単にするということ以外の理由が何かある
でしょうか?

It's easier to parse things in which the operator comes first. When you see the
operator, you know its arity, you know the expected types, you know almost everything.

演算子が最初に来ることで解析をすることが簡単になっています。演算子を見つけた時点で、あ
なたはその演算子がとる引数や期待している型、などなどのほとんどすべてのことを知っている
のです。

It's also there because it makes the form of s-expressions a bit simpler, but I
suppose that's incorporated in the previous answer.

S式の form をちょっとだけ単純にするということもありますが、
これは前の回答に incorporated されているとわたしは suppose します。

What are the possible downsides to building a programming language that revolves
around lists?

リストに関連することを解決したプログラミング言語を構築するための
posssible downsides とはなんでしょうか?

You need to do garbage collection, you need to chase pointers (which means that things
that are related may not be nearby in memory), you sometimes succumb to "If the
only tool you have is a hammer, everything looks like a nail.".

ガーベジコレクションをする必要があり、ポインターを追いかける必要があるのなら (関連し
たものがメモリ領域で隣接していないので)、あなたは
"If the only tool you have is a hammer, everything looks like a nail.".
(持っている道具がハンマーだけならば、全てが釘のように見える)
ということに屈することがあるでしょう。

When the paper compares the LISP with Turing Machine, it doesn't provide any example.
Generally, in this paper, I am not familiar with many things such as IBM 704, SDS....
It's hard for students, who are from current programming world, to understand this
paper.

論文で LISP と チューリングマシンとを比較したときに何の例も提供されませんでした。一般
的に言って、この論文にはわたしが良く知らないことがらがたくさんあります。IBM 704 だとか
SDS だとかそのほかいろいろ。この論文を理解することは、現在のプログラミング世界にいる学
生には困難なことです

Well, if understanding the thing seems central to the paper, then you probably need to
a bit of extra research. However, knowing the details of the computer on which LISP
ran is probably not essential. What kind of example would you like in the comparison
of Lisp with a Turing machine? Church's theorem shows them to be equivalent. You must
also realize the audience for whom he was writing.

さて、仮にこの論文の肝心な部分と思える箇所を理解するのなら、多分あなたには多少のextra 
research をする必要があるでしょう。しかし LISP が動作していたコンピューターについての
詳細を知ることはおそらく本質的なことではありません。LISP とチューリングマシンを比較す
るのになにか実例が欲しいですか? チャーチの理論 (Church's theorem) は両者が等価なもので
あることを証明しています。彼の論文がどういった読者を対象として書いたのかもあなたは明確
に理解しなければなりません。

Note that one of the things I want you to gain from this course is a better
understanding of history, and, because I respect you as intelligent learners, I have
no intention of spoon-feeding you that history.

わたしがあなたにこのコースから得て欲しいものの一つが歴史をより理解することであり、そし
てそれはわたしがあなたを intelligent learners であると respect しているからであって、
あなたに歴史を一方的に教え込もうとする意図はないということに注意してください。

John McCarthy credits his work with AI as very influential in his creation of LISP. He
explains that he chose to make a list-based language because of his work with AI.
This brought to mind one of our past readings about how software engineering has
influenced the design of programming languages. It seemed to me that McCarthy's
article also shows how the available hardware influences the design of a programming
language (e.g car and cdr).

John McCarthy は 彼の work を AI がLISP を彼が作成するのに大きな影響があったということ
とともに credit しています。彼の work が AI についてのものだったことがリストベースの言
語(list-based language) にすることを選択させたのだと彼は説明しています。その説明はわた
しに、ソフトウェアエンジニアリングがどのようにプログラミング言語の設計に影響を及ぼすか
について過去に読んだものを思い起こさせました。このことは McCarthy の article が使用可
能なハードウェアがいかにプログラミング言語の設計に影響を及ぼすか (たとえば car や cdr)
を示しているのと同じことのようにわたしには思えるのです。

It is natural to make a language reflect the hardware, at least a bit, particularly if
you care about efficient code.a

少なくともコードの効率というものを考慮したときに、ハードウェアを言語に反映させるのは
自然なことなのです。

The 15 bit sections for address ond decrement make sense. What are the prefix and tag
sections of the word for?

各々15ビットの、アドレスのためのセクションと decrement のためのセクションがあるのには
意味があります。ワード中の prefix や タグといったセクションはなんのためなのでしょうか?

I'll get back to you that.

2009年11月15日

■_

歴史群像(2009年12月号)で 「内臓タイマー」という誤記を見つけてがっくし

なんで世のプログラミング言語は軒並み(COBOLは例外) 実数を扱うのに二進の浮動小数点数を使うのだという意見を見かけた。 同様なことは自分も書いたことがあるような覚えが(笑)

・金融工学
ちょっと読んでみた。 Amazon.co.jp: 「金融工学」は何をしてきたのか(日経プレミアシリーズ): 今野 浩: 本 正確なところは良くわからないけど、取り扱い注意な代物なのはわかった。 しかし Amazon.co.jp: 金融工学 - 和書: 本 ずいぶんとあるもんだなあ。

■_ あんびりーばぼーなコード

たぶん reddit 経由で。



Coding horrors: post the code that makes you laugh (or cry) - The Something Awful Forums

I remember there used to be a thread like this, but I can't find it anymore. Just post 
code that either you or your coworkers/classmates have written that is hilariously bad.

I've been looking through a large system recently, since I just started a new co-op 
and I have to get caught up. This one coder (who I've never met) has stuff like this 
in all his classes:

private static final int FIVE = 5;
private static final int NEG_ONE = -1;
private static final int FIVE_BILLION = 5000000000;
private static final String SPACE_PIPE_EQUALS = " |=";
private static final String ERROR_WITH_CODE = "Error with code";

I was reading one of his classes today that had 50 lines of constants written like 
that. In an 800 line class. Also, in multiple places he does this:

File fw = new File(args[0]);
File fh = new File(args[1]);
File nv = new File(args[2]);
File nh = new File(args[THREE]);
File tw = new File(args[FOUR]);

He does this in multiple classes. 0, 1, 2 are fine, but any number higher than that he 
replaces with a named constant. He also doesn't comment his code, and uses method 
names like "task" and "task2". Then there was this method:

code:

private boolean compareInts(int one, int two)
{
    boolean areEqual = false;
    if(one == two)
    {
        areEqual = true;
    }
    return areEqual;
}

His code is unreadable, and I am considering begging my boss to let me rewrite it, 
since he doesn't have me doing anything else. Of course, if I do that then I need to 
try to understand what exactly his code does, which may be impossible.


I'm sure compared to many of you that this isn't all that bad, so share your own tale 
of horror!

いやどういう思考でこのコードができるのか謎だ。 寄せられた意見の中に


    This pipe not pipe!!

	How come the guy is still employed?

ごもっともな疑問だw

■_ Perl 6

最近ぜんぜんいじってないなあ parrot とか。


blog | Perlgeek.de :: Is Perl 6 really Perl?
Thu, 12 Nov 2009

Is Perl 6 really Perl?

A few days ago masak blogged about the social aspect of the is Perl 6 really Perl? 
question.

→ http://use.perl.org/~masak/journal/39861


He presumes that the answer is yes, but doesn't tell us why. I'll try to give some 
reasons.

Perl 6 started as the successor to Perl 5

Perl 6 started off as the successor to Perl 5, at a Perl 5 meeting, by the Perl crowd. 
It was a plan to escape both the backwards compatibility trap (which meant that broken 
things couldn't be fixed without many people yelling), and the lack of momentum in the 
community.

Perl 6 embraces the Perl philosophy

What makes Perl Perl? In my opinion it's not the sigils on variables that make Perl 
Perl, or that writing a regex only need two characters and so on. It's mostly the 
philosophy that makes the difference.

There are some underlying principles like TIMTOWTDI, context sensitivity, convenience 
over consistency, making simple things easy and hard things possible, often used 
constructs short and less frequent things longer, and so on.

Perl 6 is founded on all those philosophies and ideals, and also shares some technical 
principles. For example sigils on variables (oh, I mentioned them already ...), easy 
access to powerful regexes, that fact that operations coerce their arguments (instead 
of the type of arguments determining the operation like in javascript, where a + can 
either mean addition or string concatenation).

So if you agree with my definition of what makes Perl Perl, Perl 6 is also Perl. If 
not, please tell me what's the essence of Perl!


まあ見た目もなにも別言語といった方がすっきりする気もするけど、 根本的な考えた方はまあ共通なんだろう。

■_ げーん

Amazon さんからお手紙着いた。

このたびは、Amazon.co.jpをご利用いただき、ありがとうございます。

誠に申し訳ございませんが、お客様のご注文内容のうち以下の商品について、商品を
入手できないことがわかりました。

 Guido Van Rossum (著), et al "The Python Programming Language"

Amazon.co.jpでは、この商品につきまして、入荷の可否を継続して確認して参りましたが、
現時点では入荷の見込みがないと判断せざるを得ませんでした。

つきましては、Amazon.co.jp利用規約に基づき、お客様のご注文からキャンセルさせて
いただきましたので、お知らせいたします。
(以下略)
  

Amazon.com でもチェックしとくか。

■_ C++

いなばさんのところでのC++ネタで



d.y.d.
18:56 09/11/13

Hello C++ World

std::cout << "Hello, World!" << std::endl;

C++の話が続くことに特に意味はないのですが、いや、改めて考えると面白いなーと思ったので。 
@DecimalBloat さんのポスト を見て @Cryolite さんのポスト を思い出した上で改めてこの何
の変哲もないハローワールドを見てみると、この1行だけでも、 良くも悪くも C++ の色々な側
面がつまってるんだなあ、 と 蛇に足をはやしたく なった次第です。

std::cout << "Hello, World!" << std::endl;

「名前空間」 で分類することで、名前の衝突を防げます。 標準ライブラリはすべて、std 名前
空間に入っています。

std::cout << "Hello, World!" << std::endl;

ostream という「クラス」のオブジェクトが変数 cout に入っています。 オブジェクト指向な
感じです。 cout は「グローバル変数」です。 全ての変数は必ず何かのクラスに属させる必要
がある Java 等と違い、 グローバルに変数を置いちゃえます。

std::cout << "Hello, World!" << std::endl;

「演算子オーバーロード」。<< という演算子を、 組み込みの意味(シフト演算)と違う
動作をするように多重定義しています。

ただそれだけのように見えますが、実は、ここでは更に、「ADL (Argument Dependent Lookup)」 
と呼ばれる、C++の仕様の中でも一二を争うトリッキーな仕組みが発動しています。 この 
<< 演算子の多重定義、cout のメソッドとかではなく、こんな、

  namespace std { ostream& operator<<(ostream& os, const char* s) {...} }

std 名前空間にあるグローバル関数なんです。名前空間の中にある関数を、 std::<< な
どと修飾せずに呼び出せてしまうのは、本来はおかしい。 これを呼び出せるようにするための
仕組みが ADL です。引数 cout の型が名前空間 std で宣言されている型だったら、たとえ関数
名がstd::修飾されていなくても、 勝手に std:: にも探しに行きます。 演算子のための特殊仕
様というわけでもなく、任意の関数呼び出しでADLは発動します。

(以下面白い部分をさっくりと略)

というわけで、Hello World から眺める C++ をお送りしました。 

<< の名前の解決の話、言われるまで気がつかなかった ○| ̄|_

■_ XXX It!

XXX It もタイトルに統一性をもたせたシリーズだったんですか(にぶちん)。



The Pragmatic Bookshelf | Debug It! in print

Three things are certain: Death. Taxes. Debugging. For those first two you're own 
your own, but if you're a programmer, we can help you handle the third. Debug It! is 
now in print and shipping.

Thanks to everyone who responded to our survey about the Pomodoro cover. Based on the 
survey results and your emails, we've settled on a new cover.

PragProWriMo continues through the month of November, we hope that's going well for 
you. And don't forget to check out the latest issue and back issues of our magazine, 
PragPub.

Debug It!

Author Paul Butcher says, “Debugging is one of the few completely unavoidable 
software development tasks. It's a certainty that at some point, you're going to 
have to write code and at some other point (possibly very soon after the first!) you'
re going to have to debug it.”

These secrets of professional debugging will show you how to handle every stage of the 
bug life-cycle, from constructing software that makes debugging easy, through 
detection, reproduction, diagnosis and rolling out your eventual fix.

Whether you're writing Java or assembly language, targeting servers or embedded 
micro-controllers, using agile or traditional approaches, the same basic bug-fixing 
principles apply.

You'll learn an empirical approach which leverages your software's unique ability to 
show you what's really happening; the importance of finding a reliable and convenient 
means of reproducing a bug; how to avoid common pitfalls. You'll see how to use 
commonly available tools to automatically detect problems before they're reported by 
customers. You'll construct “self-debugging” software that automatically provides 
access to crucial information, and identifies the broken assumptions that lead to bugs.

You can continue to just wing it, or you could start a professional approach to 
debugging today. Debug It! will show you how.

Now available in print and shipping from pragprog.com/titles/pbdp

Enjoy!

Three things are certain: Death. Taxes. Debugging. 三つの避けられないものですか。しかし Death(死) と Taxes (税金)と デバッグが並べられるとは。

■_

The Ruby revolution is over | Merbist
The Ruby revolution is over

According to wikipedia, a revolution (from the latin revolutio, “a turn around”) is 
a fundamental change in power or organizational structures that takes place in a 
relatively short period of time.

Wikipedia によれば革命とは、力によって為された根本的な変化
もしくは比較的短い期間でのorganizational structures の交代となっています。

Somehow, I believe this is exactly what Ruby has done in the programming world, 
especially with the help of Rails. Over the last few years, Ruby lead a mini 
revolution in the midst of software development. Thanks to Ruby, developers now look 
at software development differently. One thing for sure, it pushed DHH to write Rails 
and then convinced thousands of people to develop Ruby based applications on a daily 
basis.

とにかくわたしはこれが、まさしく Ruby が特に Rails の助けを借りてプログラミング世界で
成し遂げたことだと確信しています。ここ数年、Ruby はソフトウェア開発の midst において小
さな革命をリードしてきました。Ruby のおかげで開発者たちは今、ソフトウェア開発を異なる
目で見ているのです。ひとつ確実に言えるのは、Rubyは DHH がRails を書くことを push し、
そしてさらに何千という人に日々使うアプリケーションをRubyで開発させるようにしたというこ
とです。

How did it happen?
(どのように行われたのか?)

Let's take a look at history of revolutions. Some people get frustrated their 
situation, they try to find workarounds until it's just too much and the revolution 
kicks in.

では革命の歴史を見ていくことにしましょう。
一部の人は自分の置かれている状況にに不満を感じて
workaround を探そうとしていました。
until it's just too much and the revolution kicks in.

Ruby came up with a new holistic perspective on things. Unlike most other programming 
languages, one of the main key value of Ruby is that writing code should feel right 
for the developer. You feel good about it because the language was written for humans 
and not machines. Basically, the language was designed to make you productive because 
it's designed to please you.

Ruby は new holistic perspective on things と共に広まりました。他の大部分のプログラミ
ング言語とは異なり、Ruby の main key value の一つはコードを書くことが開発者にとって心
地よいものでなければならないというものです。あなたが Ruby に心地よさを感じるのは、この
言語が機械のためにではなく人間のために書かれたものだからです。基本的にこの Ruby という
言語はあなたをより productive にするためにあなたが心地よさを感じるように設計されました。

As people were discovering web 2.0, Ruby also came with an opinionated framework, 
pushing for productivity, testing, simplicity and elegance. People started to see a 
new way of doing things and it quickly became the new, cool technology. Rails became a 
buzz word, developers were hired to work on cool projects, and books were selling by 
the thousands.

人々が web 2.0 を discovering したのと同じようにRuby also came with an opinionated 
framework, Ruby もまた opinionated framework となってproductivity と testing 、
simplicity、elegance を推進していました。人々は新しいやり方の探索を始め、Ruby はすぐに
新しくてcool な技術となりました。Rails はバズワードとなり、開発者たちは cool なプロジ
ェクトのために雇われました。さらに本が何千冊と売れたのです。

What did it change? (何が変わったのか?)

If you ask my mom, she would probably say: nothing, except that now my son works from 
his home office and he seems to really enjoy what he does for living.

あなたがもしわたしの母に尋ねたら、こう答えるでしょう:
何も変わってないわね。ああ、でも今は、息子が自分の home office で働くようになったし
自分の人生のためにしていることを本当に楽しんでいるように見えるかな。


Relatively speaking, Ruby did not change the way we work or live. However, I believe 
that it has influenced many software developers around the globe. Why else do you 
think that companies like Microsoft, Apple or SAP are working on their own 
implementation of the Ruby language?

Relatively speaking,
Ruby はわたしたちの仕事のやり方や生活を変えてはいません。
しかしわたしは、 Ruby が多くの around the globe の
ソフトウェア開発者に影響を及ぼしたということを確信しているのです。
Why else do you think
that companies like Microsoft,
Apple or SAP are working on their own implementation of the Ruby language?
Microsoft や Apple、SAPのような企業が
自分たちの実装による Ruby 言語を

When I first discovered Ruby, I was amazed at how “right” it felt, at how much fun 
it was to write code using its syntax and idioms. Now, if I don't get that feeling 
when testing a programming language, I think there is something wrong.

わたしが初めて Ruby を見つけたとき、それがどれほど“正しい”と感じさせるものであり、コ
ードを書くのに使っている構文やイディオムがとても楽しいということに驚かされました。もし
今、プログラミング言語をテストしているときにそういった感触が得られなければ、何かが間違
っているとわたしは考えるでしょう。

The Ruby community also revived the Agile/XP world. Testing being a strong value of 
the community, we spent a lot of time discussing TDD, BDD, integration test as well as 
other practices such as pair programming, code review, sprints etc..

Ruby コミュニティは Agile/XP 世界も revive しました。テストはコミュニティの strong 
value となりわたしたちは長い時間をかけてディスカッションしましたTDD、BDD、integration 
test もさることながら、ペアプログラミングやコードレビュー、sprints などについても。

A few years ago, when people were asking me what programming language I would write 
their app in, I would reply Ruby and had to explain what it was, why it is great and 
would have to answer a lot of questions from potential clients. Nowadays, people don't 
even argue, sites like hulu.com, twitter.com, yellowpages.com and many others are 
written in Ruby and it's just part of the tools known to work very well.

ほんの数年前には、誰かがわたしに自分がアプリケーションを書くためのプログラミング言語は
何が良いかと尋ねてきたときにはRuby と答えるだけではなくてRubyが何であるかを説明する必
要がありましたし、なぜ Ruby が great であり potential clients の質問の多くに対する回答
になるのかについて説明しなければなりませんでした。今日、同じように尋ねてくる人は文句を
いうこともありませんし hulu.com, twitter.com, yellowpages.com を始めとした多くのサイト
が Ruby で書かれていて、
and it's just part of the tools known to work very well.


The revolution is over!
(革命は終わった!)

Yes, Ruby made it's revolution and the world “has changed”. But a real movement 
doesn't die after its revolution, that's actually when it has to be strong and defend 
its values.

確かに Ruby は革命を成し遂げ、「世界は変わりました」。
けれども本当の活動 (real movement)はその革命のあとも死んでいなくて、
実際には強くあって、その価値を守るべき時なのです。

This doesn't mean that Ruby is dead or that Rails is “passé”. To the contrary, Ruby 
imposed itself as a new valued and respected player, a new standard if you will.

このことは Ruby が死んだとかRails が “passe”だということを意味してはいません。むしろ
それとは反対に、あなたが望むのならRubyは自身を new valued で respected な player であ
り新しい標準であると impose しています。

Ruby is certainly not the “new kid in the block”anymore nor the“popular kid”, 
however lots of older kids seem to want to have her on their team. (.NET, Java, 
Objective-C can all use Ruby)

たしかに Ruby はもはや “new kid in the block”ではありませんし、“popular kid”
でもありません。それでも数多くの older kids が自分たちのチームに Rubyを加えたがって
いるようです(.NET, Java, Objective-C can all use Ruby)。

The TDD + Ruby combo doesn't surprise anyone anymore and the Enterprise is slowly but 
surely adopting Ruby. Ruby is now just getting better, tools and libraries are 
improving and the amount of users is growing.

TDD (テスト駆動開発) と Ruby とのコンボは最早誰も驚かせるようなことはありませんし、そ
して Enterprise はゆっくりとではありますが確実に Ruby を受け入れてきています。 Ruby は
今まさに改善されているところで、ツールとライブラリは改良されているしユーザーの数も増え
ています。

Certainly the Ruby community is still small compared to other software developer 
communities, but the fundamental change was done and we are now working on improvement 
and keeping things running smoothly, growing and getting new ideas inspired by our 
experience and other communities.

確かに Ruby のコミュニティは他のソフトウェア開発者のコミュニティーに比べればまだまだ小
さいものですが、fundamental な変化はすでに完了していて、わたしたちは現在、ものごとを改
良したりスムーズに行い続けるための作業や、コミュニティを成長させ、わたしたちの経験や他
のコミュニティから inspire された新しいアイデアを得るための作業をしています。

Long live Ruby!

revolution, ruby

This entry was posted on Monday, November 9th, 2009, 00:10 and is filed under Misc, 
ruby. You can follow any responses to this entry through RSS 2.0. You can leave a 
response, or trackback from your own site.

どうも訳がしっくり来ない部分が多々あるなあ。

■_ 本日の巡回から

ここ数日ついったから拾ってくるのが多いな。

gist: 234728 - GitHub HIMA はじめますよー (今回は Typeclassopedia を吊るし上げる会です)

22:01 ikegami__: Applicative は idiom だと、作者自身が言ってるので
22:01 ikegami__: おぼえよう、高校英語のように

聞き覚えのない用語が飛び交っててわけわかりませんでした。 でも泣かない。

2009年11月14日

■_

・まつもとさん
Twitter / Yukihiro Matsumoto: Rubyの成功はDHHがいたからw ちょっw

・最近思うのです
仕事でちまちまと Excelをいじっているときに、 ああ、このシートのデータを R でいじれたらなあなどと。 いやまあ、R の拡張ライブラリに Excel のデータを扱えるようにするのがあるというのは 知っているのですが、マウスでセルをつんつんしながら、適当なところで 一気にコマンド(スクリプト)を書けたら楽できるよなあとかそういう感じです。 VBA はまああれはあれで重宝しますが、マクロとして書くのがちょっと面倒ですよね。 Emacs のミニバッファーみたいのを開いてぽちぽちと入力といったのが☆なーと。

OOo の Calc で、Pythonをその手の操作に使えたらサイコーなんですがw

・飛ばせデータブロック転送~♪
YouTube - 【初音ミク】 Z-80のうた

・意外なところから反応が
って、Smalltalkネタに反応があるのは id:sumim さんだけではなかったのを忘れていた 軌跡は自分で起こすもの - みねこあ

■_ 最近なかなか

きちんと見ている余裕がなっしんぐ。


  C言語なら俺に聞け(入門篇) Part 55 
798 デフォルトの名無しさん [sage] 2009/11/14(土) 19:02:00 ID: Be:
    I/Oがたまに他プロセスに取られて動作しなくなるのですが、
    どうすればI/Oを取り戻せますか。 

800 デフォルトの名無しさん [] 2009/11/14(土) 19:04:52 ID: Be:
    >>798
    ポーリングをやめて割り込み駆動にする 

801 デフォルトの名無しさん [] 2009/11/14(土) 19:08:28 ID: Be:
    微笑み忘れた顔等
    見たくはないさ
    I/O取り戻せ! 

803 デフォルトの名無しさん [sage] 2009/11/14(土) 19:41:36 ID: Be:
    んI/O取り戻~せぃぇ~~ぃぇぃぇ。 

804 デフォルトの名無しさん [sage] 2009/11/14(土) 20:30:26 ID: Be:
    ユーアーショック!
    Iで空が落ちてくる! 

「愛を取り戻せ!」の歌詞は「You は shock!」 なんだよねw >804

C言語なら俺に聞け(入門篇) Part 55 [
805 デフォルトの名無しさん [sage] 2009/11/14(土) 21:59:26 ID: Be:
    個人的に許せへんのは、小文字かつ1文字の変数

    i とか t とか 

806 デフォルトの名無しさん [sage] 2009/11/14(土) 22:08:00 ID: Be:
    なにか問題でも? 

807 デフォルトの名無しさん [] 2009/11/14(土) 22:13:31 ID: Be:
    まあ許せよ、インタープリタ方式の言語が長かった奴の性ってやつよ
    K&R C が長かったり、長くもなかったりする奴の return(0); は許してるんだろ? 

808 デフォルトの名無しさん [sage] 2009/11/14(土) 22:14:55 ID: Be:
    わかりにくい。
    もうちょっと何とかならんのかい。

    long double ConvertGeometryMatrix(void)

    というところでインクリメント用変数を使うのだとしたら、
    ConvertGeometryMatrix_InclementValue
    などとすれば一発で分かるのに。 

809 デフォルトの名無しさん [sage] 2009/11/14(土) 22:16:46 ID: Be:
    なげーよw 

810 デフォルトの名無しさん [sage] 2009/11/14(土) 22:27:43 ID: Be:
    こんな感じか?

    IntegerVariable MainFunction(IntegerVariable ArgumentCount, CharacterVariable *ArgumentVector[])
    {
     return 0;
    }

811 デフォルトの名無しさん [sage] 2009/11/14(土) 22:33:24 ID: Be:
    一文字変数に文句言うやつを何とかしてほしい。 

812 デフォルトの名無しさん [sage] 2009/11/14(土) 22:37:02 ID: Be:
    まあ、ハンガリアンとかも含めて
    中二病みたいなもんだから
    その内に治まるだろ。
    無意味だと気付くまでやりたいようにやらせとけ。 

813 デフォルトの名無しさん [sage] 2009/11/14(土) 22:38:04 ID: Be:
    コーディングスタイルにはいろいろある
    人それぞれ好みが違う
    ンなことは分かりきってるし、散々いろんなところで議論されてきたのに
    やっぱ目の前でモメるとイライラする。それも

    int First, Second;

    なのか、

    int first,
      Second;

    なのか程度で 

814 デフォルトの名無しさん [sage] 2009/11/14(土) 22:48:25 ID: Be:
    >>808
    なんだよInclementって。わかんねーよ 

815 デフォルトの名無しさん [sage] 2009/11/14(土) 22:52:08 ID: Be:
    >>813
    int first;
    int second; 

まあ限定されたスコープなら一文字の名前でもいいと思うけど、 以前書いたみたいに、g 一文字の「グローバル変数」が各所にちりばめられている プログラムをいじったりすると許しがたいものがあるなw



推薦図書/必読書のためのスレッド 52 
821 デフォルトの名無しさん [sage] 2009/11/13(金) 23:52:46 ID: Be:
    Maxima のような数式処理システムの仕組みを理解して簡単なものを作ってみたいです。
    しかし、現時点ではデータ構造の考え方とか基本的なことからよくわかっていません。
    (何となく想像はできるのですが)

    「はじめてのMaxima」に少し考え方が載っていますが、
    数式処理システムを専門に扱った本でいいのは無いでしょうか。
    洋書でも構いません。

    「数式処理システム (ソフトウェア講座) 」は初心者には読みやすいでしょうか。 

822 デフォルトの名無しさん [] 2009/11/14(土) 00:59:07 ID: Be:
    読みやすいね。 

823 デフォルトの名無しさん [sage] 2009/11/14(土) 03:20:52 ID: Be:
    構造体教えて 

824 デフォルトの名無しさん [] 2009/11/14(土) 07:21:57 ID: Be:
    C++でのクラスみたいなもんだゃ 

え”? >824 いやネタ回答でしょうけど。

■_ history of programming language

An introduction to object oriented languages

An introduction to object oriented languages

Object-orientation can refer to a set of design principles, a programming style, or
features of programming languages that support that style. Continuing from an earlier
post on the history of programming languages, let's next concentrate on the purpose
and history of the languages that support OOP.

オブジェクト指向は設計の原則の集まり (set of design principles)、プログラミングのスタ
イル、もしくはそのスタイルをサポートするプログラミング言語の機能と見なすことができます。
Continuing from an earlier post on the history of programming languages,
let's next concentrate on the purpose and history of the languages that support OOP.

The purpose of object orientation is to model, in code, the objects that make up the
application you're writing and the interactions between them. As in human language,
it's impossible to describe any process without referring to the nouns that are
involved. All programming languages provide some nouns, but until object-oriented
languages arrived on the scene, the programmer couldn't create his/her own nouns very
easily. Programming was limited to talking about the set of nouns provided by a
language: numbers, characters, channels, etc. Of course, programmers built more
abstract structures around this limited set of nouns, but the code that described
those abstractions was much more complex than talking about them in English.
Object-oriented languages allow you to define types of objects (called classes) that
are derived from, or composed of, other types. In addition to this data component, the
functions (also called methods) that “belong” to the data are also grouped in the
class. This has at least three benefits:

オブジェクト指向の目的は、コードの中であなたが書くアプリケーションを作り上げるオブジェ
クトとオブジェクト間の相互作用 (interactions) をモデル化することです人間の言語における
それと同様、提供された名詞を参照せずになんらかのプロセスを記述することは不可能です。す
べてのプログラミング言語はなんらかの名詞を提供していますが、オブジェクト指向言語が登場
するまではプログラマーは自分自身の名詞を簡単作り出すということはできなかったのです。プ
ログラミングは、数字、文字、チャンネルなどの言語によって提供されている名詞の集合によっ
て話すことが制限されます。もちろん、プログラマーはこの制限された名詞の集合の下でより抽
象化された構造を構築しますが、しかしそういった抽象化を記述したコードは英語でそれらにつ
いて話すよりもさらに複雑なものだったのです。オブジェクト指向言語ではあなたが別の型から
派生したり、複数の型を集成したオブジェクトの型 (クラスと呼ばれます) を定義することが可
能です。さらにこのデータコンポーネント (data component) に加えて、そのデータに “属す
る” 関数 (メソッドと呼ばれます)もまたそのクラスの中にまとめられます。これには少なくと
も三つの利点があります。


   1. Encapsulation. Functions that are internal to a class can be marked as “private”.
      This means that they're hidden from any code outside the class, so their
      implementation can be changed without bothering any code that uses the class.
      Conversely, the methods that are marked “public” form a well-defined interface
      that should not be changed without due consideration, because client code relies on it.

      Encapsulation. (カプセル化)  あるクラスの内部にある関数は“private”なものと見なせ
      ます。これはそのクラスの外側からのどんなコードからも隠されているということを意味し
      ます。このため、そのクラスを使ってるコードがどんなものなのかを一切気にすることなし
      に実装に対して変更を加えることが可能です。反対に、“public”とマークされたメソッド
      はクライアントコードがそれに依存しているので、正当な consideration 抜きに変更すべき
      ではない well-defined interface (きちんと定義されたインターフェース) を form します。

   2. Inheritance. You can derive one class from another, and the new class automatically
      contains all of the methods and data of the original class. This is useful when some
      subset of your objects needs an additional capability, but you don't want to give
      that capability to all of the other objects.

      Inheritance. (継承) あるクラスを別のクラスから派生 (derive) させることができ、派生した
      新しいクラスは自動的に派生元のクラスのメソッドとデータのすべてを保持します。あなたの
      オブジェクトのなんらかのサブセットが additional capability を必要としているけれどもそ
      ういった capability をその他のすべてのオブジェクトに与えたくないようなときに有用です。

   3. Polymorphism. Polly who? It's a Greek-derived term that means “many forms”.
      In OOP, it means that sending the same message (in most OO languages, this
      means calling a method by name) may evoke different responses depending on type.
      Polymorphism itself has more than one form. The first form is when a derived
      class overrides an inherited method with its own implementation, so that sending
      the same message (calling the same function) on two different objects yields a
      different behavior depending on their types. A second type of polymorphism is
      called “parametric polymorphism”, which means that a class provides different
      implementations for a method depending on the types of parameters passed to it.

      Polymorphism. (多態) Polly って誰? この単語は “many forms”(多様な形式) を意味す
      るギリシャ語からきているものです。オブジェクト指向プログラミングでは、これは同一
      のメッセージを送ったときに型に応じて異なるレスポンスが引き起こされる可能性がある
      という意味です (大部分のオブジェクト指向言語では、これは名前によってメソッドを呼び
      出すことを意味しています)。多態それ自身が二つ以上の form を持っていて、第一の形式
      (form) では派生クラス (derived class) が継承したメソッドを自分自身の実装でオーバー
      ライドしたときに、型に応じて異なる振る舞いをする二つの異なるオブジェクトに同じメッ
      セージを送ります (同じ関数を呼び出す)。多態の二番目のタイプは “parametric
      polymorphism”と呼ばれるもので、渡されたパラメータの型に依存するメソッドのためにそ
      のクラスが異なる実装を提供していることを意味します。

Have I lost you yet? Good.

Many people these days automatically think of Java when they hear “object-oriented
language”, but Java was far from the first object-oriented language. That distinction
belongs to Simula, which was developed back in the 1960's. But even though Simula
introduced the concepts of object-orientation, the first language to be called
“object-oriented” was SmallTalk - and it earned that moniker by making literally
everything an instance of a class, even literals (a feature that Ruby picked up later).

今日、多くの人が“オブジェクト指向言語”という言葉を聞いたときにはJava を即座に思い浮
かべますが、Java は最初のオブジェクト指向言語からはかけ離れたものです。その栄誉は、
1960年代に開発された Simula に帰するものです。しかし Simula でさえもオブジェクト指向の
コンセプトを持ち込んだものではありますが最初の“オブジェクト指向言語”と呼ばれるものは
Smalltalk でした。このSmalltalk では、リテラルも含め、リテラル的なものすべてをあるクラ
スのインスタンスとすることでmoniker を得ていました(のちにRubyが採用した機能です)

Object-orientation made for good theory back in the eighties when I was first
introduced to it, but it didn't receive wide adoption until it became widely available
as extensions to more popular languages like C (as C++) and Pascal (as Object Pascal).
Borland helped to popularize both of these languages on the PC with their Turbo C++
and Turbo Pascal products. Since both C++ and Object Pascal are layered on top of
non-OOP languages, they were often criticized by OO purists as “hybrids” - because
it was still possible to write non-OO code in those languages.

オブジェクト指向はわたしが最初にそれを採用した1980年代に役に立つ優れた理論であると宣伝
されましたが、C や Pascal のようなより一般的な言語に対する拡張(C++ と Object Pascal)
が広く使えるようになるまでは採用が広まることはありませんでしたBorland は Turbo C++ と
Turbo Pascal という製品で、PC におけるこれら両方の言語の普及 (popularize) に貢献しまし
た。C++ と Object Pascal の両方とが非オブジェクト指向言語の上に被さったレイヤーであり、
非オブジェクト指向なコードを記述することがまだ可能であったためにこれらの言語はしばしば
オブジェクト指向純粋主義者 (OO purists) たちから「雑種」(“hybrids”) と criticized さ
れていました。

When Java came along in the early 90's, it introduced a syntax similar to C++, but
simpler in the object-orientation department. It also eliminated the “hybrid”
problem (sort of) by forcing all routines to be members of a class - even the main
routine. Unfortunately, this has led to the creation of gratuitous classes merely to
enclose functions, and thus to an over-abundance of nouns in the code conversation.
But neither is Java a pure OO language, because primitive types are not members of a
class (although they can be coerced to objects). Because of these limitations, and the
casting required by static typing, programming in Java often becomes an exercise in
verbosity. C# is largely a Microsoft-centric variant of Java, though it has introduced
many verbosity-reducing features, some of which have subsequently been copied by Java
in what looks to me like an attempt to keep up with the Joneses.

90年代初めに Java が登場したとき Java は C++ に似た構文を導入していたのですが、
object-orientation department において、より simple でした。Java では、メインルーチン
さえも含むすべてのルーチンをクラスのメンバーにすることを強制することによって“hybrid”
問題(に類するもの)も取り除いていたのです。残念なことに、これは単に関数を enclose する
だけの gratuitous classes (クラスにする意味のないクラス?) を作ることに繋がってしまい、
その結果としてコードの conversation をするときに名詞の氾濫 (over-abundance of nouns) を
招くことになりました。しかし Java は純粋なオブジェクト指向言語 (Java a pure OO
language) でもありませんでした。なぜなら、プリミティブ型がクラスのメンバーになっていな
かったからです (ただしプリミティブ型はオブジェクトに coerce 可能でした)。Java によるプ
ログラミングは、このような制限と静的型付け (static typing) が要求するキャストによってし
ばしば exercise in verbosity となったのでした。C# は多分に Microsoft 風味の Java です
が多くの verbosity を減らすための機能が導入されています。
そのうちの一部はのちに Java にもコピーされています
in what looks to me like an attempt to keep up with the Joneses.

Perhaps the best thing that Java did for object-oriented programming was to
demonstrate by negative example that not every function belongs in a class. If one of
the main goals of object-orientation is to model in code the objects and processes
that comprise the application, then forcing an unnatural discussion of the actor for
every action misses that goal. In English, we often describe a process by saying “
first, do this… then, do that” without mentioning the implied subject (”you”).
More recent languages like Python and Ruby give you the option of using
object-oriented syntax, but they don't force it down your throat. They are called “
multi-paradigmatic” languages, because you can write them in an imperative,
object-oriented, or functional style - and you can mix these styles as you like.

オブジェクト指向プログラミングのために Java が行った best thing は、おそらくすべての関
数が何らかのクラスに属しているということについてのネガティブな実例を示したことでしょう。
仮にオブジェクト指向の目標 (goal) の一つがアプリケーションを構成するオブジェクトとプロ
セスとをコードでモデル化することであるのなら、そういった目標を失っているすべてのアクシ
ョンにアクター (actor) の unnatural discussion を強制します。英語ではわたしたちは 
subject である “you” を省略してしまって“first, do this… then, do that”(最初にこれ
をやって、次にあれをやって)のように言うことがよくあります。より新しい Python や Ruby 
のような言語ではオブジェクト指向構文 (object-oriented syntax) の使用はoption であって、
強制されるものではありません。そういった言語は「マルチパラダイム」言語 (“multi-
paradigmatic” languages) と呼ばれました。それは、あなたがそのような言語を使ってプログ
ラムを命令的にも、オブジェクト指向的にも、はたまた関数的にも書け、さらにはそれらを好き
なように混ぜたスタイルでも書くことができるからです。

So it turns out that the “hybrid” nature of Object Pascal and C++, so criticized by
OO purists, was actually a strength. As OOP has caught on, almost all programming
languages have added capabilities to support it, including even Perl, PHP, Lisp, COBOL,
and a language that I've worked on for many years, Synergy/DE. Because these languages
weren't originally OOP languages, they too are “hybrids”.

Object Pascal や C++ の「雑種」としての性質 (“hybrid” nature) は、オブジェクト指向純
粋主義者たちから criticized されたことで実際には強みとなっていました。Perl, PHP, Lisp,
COBOL、 さらにはわたしが長年にわたった仕事で使ってきた言語であるSynergy/DE さえ含むほと
んどすべてのプログラミング言語がオブジェクト指向プログラミングをサポートするための能力を
追加されています。これらの言語は originally なオブジェクト指向言語ではないので、同様に
“ハイブリッド”なのです。

So object-orientation finds it natural place in the programmer's vocabulary. It isn't
the end-all and be-all that it was originally advertised to be, but it can be quite
useful. You need complex nouns in a hierarchy of abstraction to be able to describe
things well. But you can't be confined to using only one hierarchy of abstraction, nor
to describing all actions in terms of the nouns involved.

こうしてオブジェクト指向はプログラマーのボキャブラリの中で自然な位置を見出したのです。
その位置は元々宣伝されていた end-all でも be-all でもありませんが、とても便利なもので
ある可能性があります。あるものをきちんと記述できるようにするには、抽象化の階層における
複雑な名詞が必要です。しかしあなたは使用する階層を一つに制限することも与えられた terms
of the nouns ですべてのアクションを記述することもできないのです。

#confine 限定する

Related Posts:

   1. The ascent of scripting languages
   2. The Early History of Programming Languages
   3. An introduction to functional programming
   4. Scripting Languages and the Web

■_ 本日の巡回から

■_ 挫けた

Twitter / yt: 2chのC++スレやDスレのGoへの反応が特徴がでて ... ということなので、各スレから拾い集めてみようと思ったが面倒くせー ○| ̄|_

2009年11月13日

■_

途中まで書いてた今日の分が消えちゃったよーーんw Windows update さまが update 完了後に有無を言わさずリブートなさるので…

■_ 至言だなw

stackoverflow で、GPL なソースをどうこういう話。

If my program just sometimes calls to GPL program should all my program be Open Source GPL? - Stack Overflow

If my program just sometimes calls to GPL program (or if we talk about flash my swf 
sometimes sends parameters to other GPL'd swf) should all my program be Open Source 
GPL?

if the component are separable like a swf call another swf but that's two separate 
files your source don't have to be GPL.

There is also the library exception, like your program use a GPL library (linking in C), 
your program can be still be a closed source.

Anyway if you are using those code commercially like selling a product,I advise you to 
see with a lawyer probably the most wise choice.
Do not make business decisions based on legal advice you get on the internet -- 
including mine! Seek a qualified legal professional who knows something about software 
licensing and intellectual property.

That said, there doesn't seem to be any distinction in the GPL license for when your 
code "sometimes" makes calls to GPL code. So I don't think you can get away 
with this.

There is a Lesser GPL, which is related to the library exception @RageZ is referring 
to. However, unless the swf you're using is clear that it uses the LGPL or a library 
exception, you should assume this exception is not available to you.

「自分の意見も含めてインターネットで聞いた意見で決めるな」と。

■_ すげえなあ

よくもまあこんなに。

Summary of all the MIT Introduction to Algorithms lectures - good coders code, great reuse

As you all may know, I watched and posted my lecture notes of the whole MIT 
Introduction to Algorithms course. In this post I want to summarize all the topics 
that were covered in the lectures and point out some of the most interesting things in 
them.

(略)

    * Lectures 1 and 2: Analysis of Algorithms
    * Lecture 3: Divide and Conquer
    * Lectures 4 and 5: Sorting
    * Lecture 6: Order Statistics
    * Lectures 7 and 8: Hashing
    * Lectures 9 and 10: Search Trees
    * Lecture 11: Augmenting Data Structures
    * Lecture 12: Skip Lists
    * Lectures 13 and 14: Amortized Analysis and Self-Organizing Lists
    * Lecture 15: Dynamic Programming
    * Lecture 16: Greedy Algorithms
    * Lectures 17, 18 and 19: Shortest Path Algorithms
    * Lectures 20 and 21: Parallel Algorithms
    * Lectures 22 and 23: Cache Oblivious Algorithms

■_ 参照渡し?

昨日、ついったでつぶやいていた人を見かけたような気もするけど。

グーグル、C/C++に代わる新言語「Go」をOSSで公開 - @IT

 グーグルは2009年11月10日、Cのようにシステム記述に適したプログラミング言語「Go」をBSD
ライセンスの下に公開した。C++のようなC言語の拡張ではないが、Cに似た構文が特徴で、ガベ
ージコレクタ(GC)や並列プリミティブ、イテレータ、実行時リフレクションなどを備えた新し
い設計が目を引く。Goはグーグルの社員7人が「20%の自由時間」を利用して開発した。設計・
実装を行っているのが分散OS「Plan 9」の創案者であるロブ・パイク氏や、Unix、Cの生みの親、
ケン・トンプソン氏、Google ChromeのV8エンジンを開発したロバート・グリースナー氏など錚々
(そうそう)たるメンバーで、こうした点でも注目を集めそうだ。

(略)

 同様にGoでは、アドレスを扱うポインタそのものは参照渡しのために存在しているが、Cのよ
うなポインタ演算がなく、事実上ポインタを排除している。変数宣言でも混乱がないように「
var a, b *int;」のように型宣言を変数名の後ろにもって来ている。

 ポインタ演算による配列アクセスはできないが、Goでは配列や文字列に対して部分列を切り出
せる“スライス”が使える。スライスは配列へのポインタとサイズ、最大サイズの3つの基本デ
ータを持った構造体のようなもので、スライス経由で配列の読み書きができるという。

call by reference を simulate するためにポインターを使うんであって call by refernce を実現するためにポインターが言語仕様にあるんじゃあないと思うけどなあ。 言語仕様に call by reference を入れるためにユーザーにポインターを解放する必要ないし。

Effective Go

A similar approach obviates the need to pass a pointer to a return value to
simulate a reference parameter.
Here's a simple-minded function to grab a number from a position 
in a byte array, returning the number and the next position. 

これはそのものずばりの説明部分ではないけど。

Go For C++ Programmersの勝手に和訳 — ディノオープンラボラトリ

Go For C++ Programmersの勝手に和訳 — ディノオープンラボラトリ

GoとC++の概念的な違い:

    * Goにはコンストラクタやデストラクタをもったクラスはないよ。クラスメソッド・階層的
      なクラスの継承・仮想関数の替わりにGoにはこの後に詳しく説明するインターフェイスが
      るよ。インターフェイスはC++でいうとテンプレートみたいなものだ。

    * Goはガベージコレクションを使うよ。メモリーを明確にリリースする事は必要ないよ。ガ
      ベージコレクションは最近のプロセッサーではますます効果的になっているよ。

    * GOはポインターを持ってるけど、加減算はできないよ。文字列の各バイトを順に調べるの
      にポインタの値を使う事はできないよ。

    * Goの配列は最初のクラス値です。配列が関数のパラメータとしてつかわれると、関数は配
      列のポインター(参照)ではなくコピーを受け取るよ。しかしながら、実用的な関数では、
      よくパラメータにスライスが使われるよ。スライスは配列の元になるポインタをもってい
      るよ。スライスについてはあとで説明するね。

    * 文字列が言語の機能にあるよ。文字列は生成されてから変更されないよ。

    * ハッシュテーブルも言語の機能にあるよ。これらはマップと呼ばれているよ。

    * チャンネルというスレッド間通信も言語の機能にあるよ。これについてはあとで説明するね。

    * いくつかの型(map, channel, etc.)は値渡しではなく参照で渡されるよ。つまり、マップ
      は関数に渡される時にコピーされないし、関数の中で変更されると、呼び出し側も変わるよ。
      C++でいうと参照型ですね。

    * Goはヘッダファイルを使わないよ。かわりに、それぞれのソースファイルは定義されたパ
      ッケージの一部になるよ。パッケージが大文字から始まる名前のオブジェクト(型,定数,
      変数,関数)として定義されると、そのオブジェクトはそのパッケージをインポートした
      他のファイルからも見えるようになるよ。

    * Go は 暗黙の型変換はしないよ。異なる型の変換にはキャストが必要ですよ(Goではコン
      バージョンとよびます)

    * Go は関数のオーバーロードやユーザが定義できる演算子はないよ。

    * Go にはconst や volatile制約はないよ。

    * C++ではNULLや0だったけど、Go無効なポインタにはnilを使うよ。

ふみゅ。

■_ 本日の巡回から

■_ 封筒裏の計算してみればあ?

質問の主、Python でやるのは諦めたのか(笑)

c言語でcsvファイルの処理で、処理速度が速いプログラムを書こうと思っ -OKWave

c言語でcsvファイルの処理で、処理速度が速いプログラムを書こうと思っています。
以下のようなcsvファイル、件数は約10000000件以上あるものを使います

shop,ymd,gend,age,area,amt
20,2008-05-01,3,5,014,128
22,2008-05-01,2,4,015,350
:
二列目の日別、つまりymd別に最後列のamdの小計を出したいんですが、組んだプログラムを実行
してみると、セグメンテーション違反ですと出てしまうんです。以下のようなプログラムを組ん
だんですが

#include <stdio.h>
#include <string.h>
#include <time.h>

#define MM 256

int main()
{
    FILE *fp;
    char str[MM],*p1, *p2,*ymd;
    int num, sum;

    clock_t start,end;
    start = clock();

    fp = fopen("csv.csv","r");

    if(fp == NULL){
        printf("ファイルが開けませんでした。\n");
        return(0);
    }

    sum = 0;
    fgets(str, sizeof(str), fp);
    while(fgets(str, sizeof(str), fp) != NULL){
         p1 = strtok(str, ",");
         p1 = strtok( NULL,",");
         ymd = p1;
         p2 = strrchr(str,',');
         sum[ymd] = atoi(p2+1);
         break;
    }

    while( fgets(str, sizeof(str), fp) != NULL && p1 != NULL){
        p1 = strtok(str, ",");
        p1 = strtok( NULL,",");
        p2 = strrchr(str,',');
        if ( p2 != NULL ) {
            if(ymd == p1){
                sum[ymd] += atoi(p2+1);
            }else{
                printf("%s ,%d \n",ymd,sum[ymd]);
                strcpy(ymd,p1);
            }
        }
    }
    printf("%s ,%d \n",p1,sum);
    fclose(fp);

    end=clock();
    printf("%.2f秒\n",(double)(end-start)/CLOCKS_PER_SEC);
    return(0);
}

うまくいきません。大体、処理速度は3秒以内を目指しています。
どなたかご教授御願いいたします。
>char str[MM],*p1, *p2,*ymd;
>int num, sum;
>sum[ymd] = atoi(p2+1);

sumの定義と使い方が食い違っています。コンパイルエラーは出なかったのですか?
char *型のymdを、配列の添字として使えるのですか?
この回答への補足
コンパイルでは、エラーが出なかったんです。
ただ、実行するとセグメンテーション違反です、とでるだけで。

sumの定義が違いますか...
C言語に触れるのも、結構久しぶりなので使い方を結構忘れていて、うろ覚えな感じで書き出したので。
最初から調べなおしてみたいと思います。
3秒の処理速度を実現するのは、難しそうでしょうねぇ。
対象ファイルのサイズは、200~300MBぐらいはあるのではないでしょうか?
読み出しメディアのスペックが、例えば40MB/secなら、
どれだけプログラムが速くても、5秒以上かかりますよ。
この回答への補足
そうなんですか。
前に、むちゃくちゃに書いたスクリプトで実行したら、15秒以上かかってしまって。
これでは、使い物にならないとの事だったので、さらに早くしようと書き直している最中なんです。
C/C++に連想配列はありません。自作するなり、C++でstlなどを使います。
あと、文字列の扱いがぜんぜんなっていません。
全体的なアルゴリズムも間違っています。
3秒ですか
メモリに余裕があるのならファイルを全部メモリに読み込んでから処理すれば少しは速くなるかも
あと日付が必ず同一日は連続しているとかいう保証があればプログラムも楽になりそうですが
「セグメンテーション違反を直す」のは当然として, 「どこに時間がかかっているのか」をきち
んと把握できていますか? #2 でも書かれていますが, 「どうしても必要な時間」より速くはで
きません.

ちなみに sum[ymd] ではコンパイルエラーにはならないです>#1. C では a[x] において「a と 
x の一方が整数, もう一方がポインタ」なら (その他いくつか条件はあるけど) OK です.
この回答への補足
限界を超えてまで早くしようとは思ってません。
目標は、目標として前回よりも早くなればいいんです。

あの、つまらない質問だと思うんですがポインタとポインタってstrcmpで比較する方法ってないんでしょうか?
ちょっとスクリプトを変えたんですが
#include <stdio.h>
#include <string.h>
#include <time.h>

#define MM 256

int main()
{
    FILE *fp;
    char str[MM],*p1, *p2,ymd1[20], ymd2[20];
    int num, sum=0;

    clock_t start,end;
    start = clock();

    fp = fopen("/data/testdata/journal/j080240.csv","r");

    if(fp == NULL){
        printf("ファイルが開けませんでした。\n");
        return(0);
    }
    num=1;
    fgets(str, sizeof(str), fp);
    while(fgets(str, sizeof(str), fp) != NULL && num==1){
        p1 = strtok(str, ",");
        p1 = strtok( NULL,",");
        ymd1 = p1;
        p2 = strrchr(str,',');
        sum = atoi(p2+1);
        num = 2;
    }
    while( fgets(str, sizeof(str), fp) != NULL && p1 != NULL){
        p1 = strtok(str, ",");
        p1 = strtok(NULL,",");
        p2 = strrchr(str,',');
        ymd2 = p1;
        if ( p2 != NULL ) {
            if(strcmp(ymd1,ymd2) != 0){
                printf("%s ,%d \n",ymd1,sum);
                strcpy(ymd1,ymd2);
            }else{
                sum += atoi(p2+1);
            }
        }
    }
    printf("%s ,%d \n",ymd2,sum);
    fclose(fp);

    end=clock();
    printf("%.2f秒\n",(double)(end-start)/CLOCKS_PER_SEC);
    return(0);
}

という風に変えたんですが、ポインタの比較はできないってコンパイルできないので、ポインタ
の比較ができないなら、別のアプローチを考えなきゃいけないんですが...
>ポインタの比較はできないってコンパイルできないので、
その際にエラーメッセージで行数は表示されませんでしたか?

>char str[MM],*p1, *p2,ymd1[20], ymd2[20];
と定義しているのに、
>ymd1 = p1;
のような使い方はできませんよ。
この回答への補足
エラーの内容は
test4.c: In function ‘main':
test4.c:27: error: incompatible types in assignment
test4.c:36: error: incompatible types in assignment
こう出ます。
やっぱりポインタはイコールでつなげられないんですか。
別の手法でいくしかないみたいですね。
No.6です。

>やっぱりポインタはイコールでつなげられないんですか。
ポインタ同士で代入(右辺のアドレスを左辺に入れる等)はできます。

まず、エラーの意味を理解してください。
簡単に書けば「型が違うから代入できない」と言っているのです。

No.6の
--------
>char str[MM],*p1, *p2,ymd1[20], ymd2[20];
と定義しているのに、
>ymd1 = p1;
のような使い方はできませんよ。
--------
について理解されていますでしょうか?

>char str[MM],*p1, *p2,ymd1[20], ymd2[20];
をわかりやすいように分解します。
--------
char str[MM];
char *p1;
char *p2;
char ymd1[20];
char ymd2[20];
--------
p1、p2は「char型のポインタ」
str[]、ymd1[]、ymd2[]は「char型の配列」です。

>ymd1 = p1;
は、ymd[0]に対してp1に格納されているアドレスを代入しようとしているためエラーとなっています。

ひとつアドバイス。
どんなに短いプログラムでも、どこで何の処理を行うのかコメントは降っておいた方が理解しやすいと思う。
この回答への補足
有難う御座います。
コメントは今度から、振るように心がけたいと思います。
プログラムの直しも早速挑戦したいと思います

これでは、使い物にならないとの事だったので まさか仕事で作れって言われてんのかなあ。 にしたってこのプログラムは…

えいやで一行辺り30バイトとみて 件数は約10000000件以上あるものを使います ということで100万件とすると、300メガバイトくらい? ただ単に fgets で読み込んだのを吐き出すだけでも 3秒じゃあ無理ぽたんじゃなね? mmap (Windows だと CreateFileMapping だっけ?)して、 fgets を使わずに単にメモリをなめていくようなロジックにして全体を走査し終えるのにどのくらいかかるか。

しかしこの質問主、Pythonのときも辞書にこだわってたし、 この質問のCプログラムもそれを引きずったかのような流れになっているのはなぜなんだろう? いや、日付をキーにした連想配列(辞書)ならそれもいいけど、 ヘッダー行にあるキーの名前をキーにして、一行ごとに新しい連想配列作ってたんだよねえ。

2009年11月12日

■_

・今月下旬発売予定のコンパイラー本はすぐに買えないかもだなあ。しくしく。


inforno :: 個人的Go雑感&メモ

http://inforno.net/articles/2009/11/11/go-language
http://inforno.net/articles/2008/05/17/simple-stack-oriented-language-implemented-using-scala

■_

リンク付きリスト (linked list) について。



[Linux Kernel Linked List Explained]

Linux Kernel Linked List Explained

Introduction:

Linux kernel is mostly written in the C language. Unlike many other languages C does 
not have a good collection of data structures built into it or supported by a 
collection of standard libraries. Therefore, you're probably excited to hear that you 
can borrow a good implementation of a circularly-linked list in C from the Linux 
kernel source tree.

Linux カーネルはほとんどが Cで記述されています。他の多くの言語とは異なり、C には言語に
組み込まれていたり標準ライブラリのコレクションによってサポートされているようなよいデー
タ構造のコレクションがありません。ですから、Linux カーネルのソースツリーからC で書かれ
た circularl-linked list の優れた実装を拝借することができるということにあなたはたぶん
興奮を覚えることでしょう。


The file include/linux/list.h in the source tree implements a type oblivious, 
easy-to-use, circularly-linked list in the C language. The implementation is efficient 
and portable-- otherwise it would not have made it into the kernel. Whenever someone 
needs a list in the Linux kernel they rely on this implementation to strung up any 
data structure they have. With very little modifications (removing hardware 
prefetching of list items) we can also use this list in our applications. A usable 
version of this file is available here for download.


Some of the advantages of using this list are:

これを使うことによる利点のいくつかをリストにしてみます:

   1. Type Oblivious: (型を気にしないでいい) 
      This list can be used to strung up any data structure you have in mind.

      このリストはあなたが思い描いたどんなデータ構造でも strung up up するのに使えます

   2. Portable: (移植性がある)
      Though I haven't tried in every platform it is safe to assume the list implementation
      is very portable. Otherwise it would not have made it into the kernel source tree.

      わたしはすべてのプラットフォームでこれが非常に移植性のあるリストの実装であるという
      仮定を確かめたわけではありませんが、もしそうでないのなら、カーネルのソースツリーに
      置かれていることはないでしょう。

   3. Easy to Use: (簡単に使える)
      Since the list is type oblivious same functions are used to initialize, access,
      and  traverse any list of items strung together using this list implementation.

      リストが type oblivious なので任意のアイテムのリストに対する初期化、アクセス、
      トラバースにはそれぞれ同一の関数が使われます。

   4. Readable: (読みやすい)
      The macros and inlined functions of the list implementation makes the resulting 
      code very elegant and readable.

      マクロとインライン化された関数を使ってリストを実装することでコードが非常に
      elegant かつ readable なものとなりました

   5. Saves Time: (時間の節約)
      Stops you from reinventing the wheel. Using the list really saves a lot of
      debugging time and repetitively creating lists for every data structure
      you need to link.

      あなたが車輪を再発明するのを止めます。このリストを使うことでデバッグのための
      時間や、必要となったあらゆるデータ構造にあわせて繰り返しリストを作る手間を
      減らします。

Linux implementation of the linked list is different from the many linked list 
implementations you might have seen.

Linux でのリンクつきリスト (linked list)の実装は、あなたがこれまでに見たことのあるかも
しれない多くのリンクつきリストの実装とは異なるものです。

Usually a linked list contains the items that are to be linked. For example:

通常のリンクつきリストはリンクしたいアイテムを含んでいます。
例をあげましょう:

struct my_list{
	void *myitem;
	struct my_list *next;
	struct my_list *prev;
	};

The kernel's implementation of linked list gives the illusion that the list is 
contained in the items it links! For example, if you were to create a linked list of 
struct my_cool_list you would do the following:

リンクつきリストのカーネルの実装ではリストがアイテムの中に含まれているという illusion 
を提供しています!たとえば、my_cool_list 構造体のリンクつきリストを作ろうとしたときに
次のようにするでしょう:

struct my_cool_list{
	struct list_head list; /* カーネルのリスト構造体 */
	int my_cool_data;
	void* my_cool_void;
	};

Couple of things to note here:
ここで幾つか注意すべきことがあります:

   1. List is inside the data item you want to link together.
      データアイテムの内側にリンクしたいリストがあります。

   2. You can put struct list_head anywhere in your structure.
      list_head 構造体はあなたの定義する構造体のどこにでも置けます。

   3. You can name struct list_head variable anything you wish.
      list_head 構造体の名前を好きなように命名できます

   4. You can have multiple lists!
      複数のリストを持てます!

So for example, the declaration below is also a valid one:

struct todo_tasks{
	char *task_name;
	unsigned int name_len;
	short int status;

	int sub_tasks;

	int subtasks_completed;
	struct list_head completed_subtasks;/* リスト構造体 */

	int subtasks_waiting;
	struct list_head waiting_subtasks; 	/* same or different items の別のリスト! */

	struct list_head todo_list;			/* todo_tasks のリスト */
	};

Here are some examples of such lists from the kernel:

    * include/linux/fs.h:362
    * include/linux/fs.h:429

While we are at this, kernel's list structure is declared as follows in
include/linux/list.h:

カーネルのリスト構造体は include/linux/list.h の中で
以下のように宣言されています。

struct list_head{
	struct list_head *next;
	struct list_head *prev;
	}

Having said that this is probably a good time to delve into the details. First let us 
see how we can use this data structure in our programs. Then, we will see how the data 
structure actually works.

最初にこのデータ構造を自分のプログラムでどのように使えるのかを見てみることにしましょう。
そのあとでこのデータ構造が実際にどのように動作しているのかを見ていきます。

Using the List:

I think the best way to get familiar with the list functions is to simply scan the 
file for them. The file is well commented so there should not be any trouble 
understanding what is available to a user.

わたしは、リストを扱う関数群に親しむ最善の方法はそれらを使ってファイルを単純にスキャン
してみることだと考えています。
The file is well commented so there should not be any trouble 
understanding what is available to a user.


Here is an example of creating, adding, deleting, and traversing the list. You can 
download the source code here.

以下の例は、リストの生成、追加、削除、トラバースを行うものです。


#include <stdio.h>
#include <stdlib.h>

#include "list.h"


struct kool_list{
	int to;
	struct list_head list;
	int from;
	};

int main(int argc, char **argv){

	struct kool_list *tmp;
	struct list_head *pos, *q;
	unsigned int i;

	struct kool_list mylist;
	INIT_LIST_HEAD(&mylist.list);
	/* or you could have declared this with the following macro
	 * LIST_HEAD(mylist); which declares and initializes the list
           あるいはここで、後に LIST_HEAD(mylist) を続けた宣言を置くこともできます。
           これはlist の宣言と初期化を行います。
	 */

	/* mylist に要素を追加 */
	for(i=5; i!=0; --i){
		tmp= (struct kool_list *)malloc(sizeof(struct kool_list));
		
		/* INIT_LIST_HEAD(&tmp->list);
		 *
		 * this initializes a dynamically allocated list_head. 
		 * you can omit this if subsequent call is add_list() or
		 * anything along that line because the next, prev
		 * fields get initialized in those functions.
                   動的に割り当てた list_head の初期化をします。
                   続く呼び出しが add_list() もしくは anything along that
                   line だった場合にはこの呼び出しを省略することができます。
                   それは、そういった関数で next, prev, field の初期化がな
                   されるからです。
		 */
		printf("enter to and from:");
		scanf("%d %d", &tmp->to, &tmp->from);

		/* add the new item 'tmp' to the list of items in mylist */
                   新しいアイテム 'tmp' をアイテムのリスト mylist に追加する
		list_add(&(tmp->list), &(mylist.list));
		/* you can also use list_add_tail() which adds new items to
		 * the tail end of the list
                   リストの末尾にアイテムを追加する list_add_tail() を使うこともできます
		 */
	}
	printf("\n");


	/* now you have a circularly linked list of items of type struct kool_list.
	 * now let us go through the items and print them out
           これで kool_list 構造体型のアイテムのcircularly linked list が手に入りまし
           たからリストをなめていってアイテムをプリントしてみましょう
	 */

	/* list_for_each() is a macro for a for loop.
	 * first parameter is used as the counter in for loop. in other words, inside the
	 * loop it points to the current item's list_head.
	 * second parameter is the pointer to the list. it is not manipulated by the macro.
           list_for_each() は for ループのためのマクロです。第一パラメータは for ループ
           内部でカウンターとして使われます。言い換えると、ループの内側でカレントのアイ
           テムの list_head を指し示しています。第二パラメータはリストへのポインターです。
           これはマクロによって操作されることはありません。
	 */
	printf("traversing the list using list_for_each()\n");
	list_for_each(pos, &mylist.list){

		/* at this point: pos->next points to the next item's 'list' variable and
		 * pos->prev points to the previous item's 'list' variable. Here item is
		 * of type struct kool_list. But we need to access the item itself not the
		 * variable 'list' in the item! macro list_entry() does just that. See "How
		 * does this work?" below for an explanation of how this is done.
                  この時点で pos->next は次のアイテムの 'list' を指し、pos->prev は直前の
                  リストの'list' を指しています。このアイテムは struct kool_list 型のものです。
                  しかしわたしたちはアイテムの中にある 変数 'list' ではなく、アイテムそのもの
                  にアクセスする必要があるのです!
                  list_entry() というマクロがまさにそれをやってくれます
		 */

		  tmp= list_entry(pos, struct kool_list, list);

		 /* given a pointer to struct list_head, type of data structure it is part of,
		  * and it's name (struct list_head's name in the data structure) it returns a
		  * pointer to the data structure in which the pointer is part of.
		  * For example, in the above line list_entry() will return a pointer to the
		  * struct kool_list item it is embedded in!
                    たとえば上の行の list_entry() はlist_head 構造体へのポインター、それを
                    含むデータ構造の型、そしてその名前(データ構造における list_head 構造体
                    型の変数の名前) を与えると、そのリスト構造体へのポインターを含むデータ
                    構造体へのポインターを返します。
                    For example, in the above line list_entry() will return a pointer to
                    the struct kool_list item it is embedded in!
		  */


		 printf("to= %d from= %d\n", tmp->to, tmp->from);

	}
	printf("\n");
	/* since this is a circularly linked list. you can traverse the list in reverse order
	 * as well. all you need to do is replace 'list_for_each' with 'list_for_each_prev'
	 * everything else remain the same!
	 *
	 * Also you can traverse the list using list_for_each_entry() to iterate over a given
	 * type of entries. For example:
           このリストは circularly なリンクつきリストなので、逆方向にトラバースすることが
           可能です。そのときにあなたに必要なのは list_for_each を list_for_each_prev に
           置き換えることだけです。その他のことは全く一緒です!

           与えられたエントリの型を iterate over するのに list_for_each_entry() を使って
           リストのトラバースをすることもできます。
	 */

	printf("traversing the list using list_for_each_entry()\n");
	list_for_each_entry(tmp, &mylist.list, list)
		 printf("to= %d from= %d\n", tmp->to, tmp->from);
	printf("\n");
	

	/* now let's be good and free the kool_list items. since we will be removing items
	 * off the list using list_del() we need to use a safer version of the list_for_each()
	 * macro aptly named list_for_each_safe(). Note that you MUST use this macro if the loop
	 * involves deletions of items (or moving items from one list to another).
	 */
	printf("deleting the list using list_for_each_safe()\n");
	list_for_each_safe(pos, q, &mylist.list){
		 tmp= list_entry(pos, struct kool_list, list);
		 printf("freeing item to= %d from= %d\n", tmp->to, tmp->from);
		 list_del(pos);
		 free(tmp);
	}

	return 0;
}


How Does This Work?

Well most of the implementation is quite trivial but finesse. The finesse relies on 
the fact that somehow we can obtain the address of an item that contains the list 
(struct list_head list) given the pointer to the list. This trick is done by the 
list_entry() macro as we saw above. Let us now understand what it does.

実装の大部分はとても trivial なものですが finesse です。この finesse は与えられたリス
トへのポインターからそのリストが含むアイテムのアドレスを取得することが可能であるという
事実に依存しています。わたしたちはそのリスト (struct list_head list) を含むアイテムの
アドレスの取得をすることができますこのトリックは前述したように list_entry() マクロによ
って行われます。では何をやっているのか理解してみましょう。

#define list_entry(ptr, type, member) \
	((type *)((char *)(ptr)-(unsigned long)(&((type *)0)->member)))

Macro expansion for the above example is as follows:

	((struct kool_list *)((char *)(pos) - (unsigned long)(&((struct kool_list *)0)->list)))

This is what confuses most people but it is quite simple and a well-known technique 
(See Question 2.14). Given a pointer to struct list_head in a data structure, macro 
list_entry() simply computes the pointer of the data structure. To achieve this we 
need to figure out where in the data structure the list_head is (offset of list_head). 
Then, simply deduct the list_head's offset from the actual pointer passed to the macro.

これは大部分の人が混乱する箇所ですがとても単純でよく知られているテクニックです (See 
Question 2.14).データ構造体の中の list_head 構造体へのポインターを与えるとマクロ 
list_entry()は単純に計算しますそのデータ構造体へのポインターをこれを achieve するた
めにわたしたちはlist_head のオフセット、つまりlist_head がデータ構造体のどこにあるのか
を把握しておく必要があります。そうしてから、マクロに渡された実際のポインターから単純に 
list_head のオフセットを減算します。

Now the question is how can we compute the offset of an element in a structure? 
Suppose you have a data structure struct foo_bar and you want to find the offset of 
element boo in it, this is how you do it:

ここで疑問となるのは、構造体の中にある要素のオフセットをどのようにすれば計算できるのか?
ということです。ここであなたが struct foo_bar というデータ構造をもちその中にある要素 
boo のオフセットを求めたいとしましょう:

(unsigned long)(&((struct foo_bar *)0)->boo)

Take memory address 0, and cast it to whatever the type of structure you have-- in 
this case struct foo_bar. Then, take the address of the member you're interested in. 
This gives the offset of the member within the structure. Since we already know the 
absolute memory address of this element for a particular instance of the structure 
(for example, by way of pos) deducting this offset points us to the address of the 
structure itself. That's all there is to it. To get a better handle on this I suggest 
you play around with this piece of code.

0番地アドレスを取り、それをあなたが持っている構造体の型にキャストします-この例では 
struct foo_bar です。そうしてから、こんどはあなたが注目しているメンバーのアドレスを取
得します。これは構造体の中でのそのメンバーのオフセットを与えます。わたしたちはこの要素
があるメモリの絶対番地すでに知っているのでこの構造体のある特定のインスタンスにおけるこ
のオフセット位置から構造体それ自身のアドレスを引いてやります。これですべて完了です。
To get a better handle on this I suggest you play around with this piece of code.

(以下略)

まあCでなにもそこまでという気もしますが、 C++ でもテンプレートがきちんと実装されるまでは プリプロセッサーを使ったテクニックが使われてたりしましたしねえ。

■_ Go

Windows 版ないのかという質問に対して。 Can Go compiler be installed on Windows? - Stack Overflow

Can Go compiler be installed on Windows? - Stack Overflow

It hasn't made it onto the Go Lang FAQ yet, but from the changelog:

    Why doesn't Go run on Windows? We understand that a significant fraction of computers
    in the world run Windows and it would be great if those computers could run Go programs.
    However, the Go team is small and we don't have the resources to do a Windows port at
    the moment. We would be more than willing to answer questions and offer advice to
    anyone willing to develop a Windows version. 
Despite the fact that Go is only two days old, this question has already become a FAQ 
on the Go mailinglist. (Unfortunately, it has not yet been added to the FAQ list on 
the website.)

Basically, Go is done by a very small group of people, so they simply do not have the 
time nor the resources to do a Windows port. That very small group of people also 
happens to be the people who invented Unix, so that was kind of a natural first target.

I don't think they do this on they "spare" time. Rob Pike, Ken Thompson et al are full 
time Google employees.

AFAIK, they develop Go during their 20% time, not full time. (That's what I read, 
anyway.) Anyway, my answer was meant to be very-large-tongue-very-deep-in-cheek.

Actually, the history page states that while it started out as a spare-time project, it is now a full-time project for at least some of the developers. I edited the answer to basically remove the remarks about part-time constraints.

まあさもありなん。

■_ 本日の巡回から

2009年11月11日

■_

・プログラミング Haskell
買いました。 にしても、Real World Haskell が平積みで置かれていたのになぜこの本が棚差しで、 しかも一冊だけしかなかったのだろう。発売日なのに。
プログラミングHaskell
これを探している途中で気がついたのですが、 入門 Haskell って絶版状態なんですね。 Amazon.co.jp: 入門Haskell―はじめて学ぶ関数型言語: 向井 淳: 本 Audrey にサインしてもらったんだよな。この本に。

http://tabesugi.net/memo/2009/ba.html#071336 http://tabesugi.net/memo/2009/ba.html#062322 Show's Hot Corner http://www.asahi-net.or.jp/~ki4s-nkmr/ http://www.reddit.com/r/programming/comments/a2gfk/what_physical_factors_limit_the_size_of_l1_cache/ http://justinbozonier.posterous.com/using-graphs-to-build-your-own-ruby-pattern-m http://www.reddit.com/r/Python/comments/a2qxs/bad_news_google_employees_are_being_discouraged/ http://blogs.itmedia.co.jp/hiranabe/2009/11/gerald-weinberg.html Why do a lot of programming languages put the type *after* the variable name? - Stack Overflow http://stackoverflow.com/questions/1712274/why-do-a-lot-of-programming-languages-put-the-type-after-the-variable-name The Go Programming Language http://golang.org/ How to not be an IT programmer? - Stack Overflow http://stackoverflow.com/questions/1703298/how-to-not-be-an-it-programmer Haskell is beautiful in practice http://monkey.org/~marius/haskell-is-beautiful-in-practice.html 「Trojan.Clampi」の仕組み:ネットワーク通信機能 - 世界のセキュリティ・ラボから:ITpro http://itpro.nikkeibp.co.jp/article/COLUMN/20091101/339919/

■_ これが好き

あなたの好きなプログラミング言語の機能をあげてちょうだい。というお題で。

What programming language features do you like? - Stack Overflow

What programming language features do you like?

I want to make up a program language and write some code for it. Maybe I can use ANTLR 
for syntax checking. What I want to know is what features of a programming language 
you like? I'll start with a few:

    * Python's use of variables.
    * Python lists and dictionaries
    * Python strings
    * Python's multiple return values
    * templates
    * reference
    * operator overloading for return values (c++ ex,
      class AClass { operator MyClass (){ return myClass; } ... }; )
    * compile time functions. I was glad to see it is in the new C++ standard
      http://en.wikipedia.org/wiki/C%2B%2B0x#Generalized%5Fconstant%5Fexpressions
    * Initializer lists http://en.wikipedia.org/wiki/C%2B%2B0x#Initializer%5Flists
    * PHP string literals (echo "foo is $foo";)

Edit:

    * Carry and Overlflows flags! I honestly can't believe I forgot these as I always complain
      about not having them. Credit goes to
      http://stackoverflow.com/questions/440337/programming-language-features-you-like#44081
      5 for reminding me.


Lambda functions. More generally, making executable code a full-fledged object in the 
language as per Lisp.


Reflection.


    * Deterministic destructors (as in C++)
    * Static type system with type inference (Haskell, ML, Boo...)
    * Built-in high level concurency support (Erlang)
    * Modules (Ada, Modula-2)
    * Ability to expose "C" interface to other programming languages (C++, Objective-C)
    * Type-safe containers (C++)


LINQ! Probably one of the most useful features I've seen implemented.


    * Robust Macros (see: Common Lisp)
    * Perl/Ruby's regular expressions sugar
    * Continuations (though I'm still learning about them)
    * The ability to compile to native code with any/all required libraries included 
      (I have a heck of a time distributing Perl or Lisp code to random people.)

    * The ability to extend the language using built in structures.

    * Keep the core minimal and let the users evolve the language by adding various
      libraries on top.

For example, Smalltalk does not need the standard if/then/else construct in the 
language. IfTrue: is just a standard message the boolean object accepts.

Ruby carries Smalltalk's tradition but is less extreme in this case (e.g., you do have 
a built in if() construct but each() is a simple message replacing the traditional for 
loop).

Another example is the nice design of Scala.

    * Compile-time static type-checking (preferably Haskell-esque).
    * Arbitrary precision arithmetic as a language feature, not an afterthought.
    * Write Once Run Anywhere (Java-style)
    * Literal syntax for maps and lists (like Python, unlike Java).
    * Tuples
    * First-class functions.


    * C# auto-properties (public int Foo { get; set; })
    * async { } in F#, that automatically makes closures for asynchronous code


    * S-expressions: completely uniform, unambiguous syntax.
    * Generic functions: which function gets called is not dependent on only the type
      of one of the call's arguments, but on all the involved types.
    * Support for functional idioms: functions as first-class objects, tail call
      optimization
    * I like dynamic typing, with the option to declare types at specific places for
      efficiency.

What I like about VB.NET:

    * Verbosity (I find the verbosity refreshing, and easy for interns to read.)
    * Active sentence like structure (even to the point of its potential
      "left-hand aligned" nature, where nearly any line of code can have a
      primary identifier on the left hand side that quickly identifies the very essence of
      what it does, such as the otherwise unnecessary "Call", "Dim"
      etc... statements.)

    * Obfuscation of most aspects of garbage collection, which downright spoils you
      when you have to go back to non-garbage collected higher level languages.

    * A good mix between potential for Rapid Application Development and powerful
      features previously denied to Visual Basic (such as multithreading).

    * The fact that it, in an overwhelming majority of cases, can perform all of the
      tasks that C# can perform.

    * The ability to better implement object-oriented designs (as opposed to VB6).

    * Easy and intuitive container objects.

What I like about VB6:

    * Utterly Rapid Application Development in a visual environment. Nearly any utility
      that I need to make quickly is still written in VB6 as a result, even after having
      learned Python. For "singular purpose" windowed programs that perform 
      potentially complex tasks, VB6 can be extremely quick to write for.

    * Active sentence like structure (see above)

    * Verbosity (again, see above)

    * Even easier and even more intuitive container objects (even than VB.NET).


My favorite is a real compile-time metalanguage like the one in D. C++ templates were 
a cool start, but having a full compile-time meta-language that supports simple 
constructs like tuples and static ifs natively without hackishness, and allows 
compile-time code generation via string mixins is unbelievably useful.

Don't forget for loops:-)

    * Anonymous delegates like in C#.
    * Currying and the other functional programming features.

For C#: Delegates and lambdas and on a close second: generics. Interfaces are really 
nice as well.

For Perl: Implicit variables which makes the plain vanilla cases really simple to 
implement and of course regexs.

C++: Const references.

Single Assignment to variables. Some languages have it by design, like Erlang. Other 
languages don't enforce it but you can make use of it. When writing Java code almost 
all local variables, and a fair share of instance variables, can usually be declared 
"final". Do it and your code will be more clear and much easier to 
understand for others.

This is a bit radical: everything should be an object. Even integers and dates!

.NET Nullable Types are a step in the right direction. I know there are performance 
reason to use Value Types but why not give them the special designation and make int? 
datetime? the default and use int# and datetime# for the real value types.

Features that let you store data in one place and use it throughout a program. You can 
just change it in one place and have that effect the entire thing.

Like:

    * Constants
    * Inheritance
    * Modules

どれもまあ納得できるかな。このほかにもいくつか挙げられてます。

■_ 軌跡の価値は

丸投げ&マルチ。 Squeak で書けというお題とはいえ「奇跡を描く」のは id:sumim さんでも 無理だろう(笑)



(1) 螺旋(大きさは任意)の奇跡を描くスクリプト(Squeak)を作成して答えよ。なお... - Yahoo!知恵袋

(1) 螺旋(大きさは任意)の奇跡を描くスクリプト(Squeak)を作成して答えよ。
なお、螺旋の描く方向を

(a) 外側に螺旋が広がっていく(最初の奇跡よりも外側に螺旋を描く)
(b) 内側に螺旋が狭まっていく

(最初の奇跡よりも内側に螺旋を描く)
の2つについて作成すること。スクリプトは実際のSqueakの命令文と
同じものとすること(動かしたものを書くことを推奨する)。
なお螺旋の幅は等幅とする。

(2) 教科書のProject 7 にて作成したアクセルとブレーキにおいて、
足が、両方に触れた場合でも、ブレーキが優先して作動するような
スクリプトを作成せよ。

[2] 次の並び替えアルゴリズムについてフローチャートと
アルゴリズムの効率(=平均計算量)を求める計算式を求めよ。
解答には、計算式を導く過程も示すこと
(1) バブルソート
(a) フローチャート
(b) 平均計算量(すなわち比較回数)
(2) Q-Sort (クイックソート)
(a) フローチャート
(b) 平均計算量(すなわち比較回数)

[3] 日常の生活の中で、論理的な思考を要すると思われる
事例について1つ具体的にあげよ。
なお論理的な思考とは、順次・分岐・繰り返しの3つの
パターンの組み合わせで動作が決定されるもので、
説明において、順次・分岐・繰り返しという用語を少なくとも
1つ以上用いること。
(レジの並び方、ルート検索、仕事の片付ける順番とか、具体的な例とすること)

Squeak -OKWave
(1) 螺旋(大きさは任意)の奇跡を描くスクリプト(Squeak)を作成して答えよ。なお、螺旋の描く方向を
   (a) 外側に螺旋が広がっていく(最初の奇跡よりも外側に螺旋を描く)
   (b) 内側に螺旋が狭まっていく(最初の奇跡よりも内側に螺旋を描く)
   の2つについて作成すること。スクリプトは実際のSqueakの命令文と
   同じものとすること(動かしたものを書くことを推奨する)。
   なお螺旋の幅は等幅とする。

(2) アクセルとブレーキにおいて、
   足が、両方に触れた場合でも、ブレーキが優先して作動するような
   スクリプトを作成せよ。

[2] 次の並び替えアルゴリズムについてフローチャートと
  アルゴリズムの効率(=平均計算量)を求める計算式を求めよ。
  解答には、計算式を導く過程も示すこと
 (1) バブルソート
  (a) フローチャート
  (b) 平均計算量(すなわち比較回数)
 (2) Q-Sort (クイックソート)
  (a) フローチャート
  (b) 平均計算量(すなわち比較回数)
[3] 日常の生活の中で、論理的な思考を要すると思われる
   事例について1つ具体的にあげよ。
   なお論理的な思考とは、順次・分岐・繰り返しの3つの
   パターンの組み合わせで動作が決定されるもので、
   説明において、順次・分岐・繰り返しという用語を少なくとも
   1つ以上用いること。
  (レジの並び方、ルート検索、仕事の片付ける順番とか、具体的な例とすること)

■_ 学校では教えてくれなかったこと

それを学校(大学)で教えてくれというのもどうかと思うのもあったりしますが。それはそれ。



What they didn't teach me in college | Surfing in Kansas
What they didn't teach me in college

Warning: This is a bit of a brain dump.

In the software industry there is a lot of back and forth about the value of a college 
degree. This post won't go into that too much, I just want to talk about the notable 
things that were left out of my Computer Science degree. Mostly things that are used 
in the day to day environment outside of a university, but aren't used extensively 
inside of them.

My degree was a more classical CS degree, which focused on algorithms and theory. 
However, there was a decent bit of actual "real world" knowledge that they 
tried to impart. After being at a real job for over a year, I think it is interesting 
to look back on what I wasn't taught.

Software testing

Version Control

Web development

Bug Tracking / Maintenance


Conclusion

I think the really important part is that your code doesn't die. You write code in a 
class, and it is used by other people, or it is kept and brought back up later. This 
you as a student to reach the "aha" moments where you see how much you have 
learned in the past year, by how much your old code sucks. It provides a lot more 
knowledge of useful tools and real workflow. Without too much effort, it makes the 
educational nature of college more valuable and more realistic.

I would be interested to hear people's thoughts. If you got a degree, did they do 
anything similar to this? Are you using up tools and practices?

As a bonus, I think that a lot of the parts missing in universities are missing in 
good real world software shops. There are a lot of software houses that don't use 
version control, write tests, or use a bug tracker. This strikes me as crazy. 

■_ 本日の巡回から

例のはぼちぼちと

グーグル、C/C++に代わる新言語「Go」をOSSで公開 - @IT
http://www.atmarkit.co.jp/news/200911/11/go.html

Let's Go
http://golang.org/doc/go_tutorial.html

The Go Programming Language, by Rob Pike [Google Tech Talk] : programming
http://www.reddit.com/r/programming/comments/a31fx/the_go_programming_language_by_rob_pike_google/

シンプルで高速、Googleの新プログラミング言語「Go」 | エンタープライズ | マイコミジャーナル
http://journal.mycom.co.jp/news/2009/11/11/025/index.html

OOHHHH SNAP! "I have already used the name Go for *MY* programming language" - Google Go issue tracker ticket #9 : programming
http://www.reddit.com/r/programming/comments/a351z/oohhhh_snap_i_have_already_used_the_name_go_for/

Go: an experimental language from Google : programming
http://www.reddit.com/r/programming/comments/a3184/go_an_experimental_language_from_google/

Go For C++ Programmersの勝手に和訳 — ディノオープンラボラトリ
http://openlab.dino.co.jp/2009/11/11/231252628.html

一つ前へ 2009年11月(上旬)
一つ後へ 2009年11月(下旬)

ホームへ


Copyright (C) 2009 KIMURA Koichi (木村浩一)
この文書の無断転載はご遠慮ください(リンクはご自由にどうぞ)。

メールの宛先はこちらkbk AT kt DOT rim DOT or DOT jp