ときどきの雑記帖 めぐりあい電脳空間編

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

一つ前へ 2010年3月(下旬)
一つ後へ 2010年4月(中旬)

ホームへ

2010年04月10日

■_

建安マエストロ!
ようやく買いました(売ってるところがなかなか見つからなかったのよ)。 いやー、面白いわこれ。 三国志ものというとそれだけで割り引いちゃうけど、 曹丕を主役に据えたところとか興味深いです。 あえて難点を一つ言うと、 蒼天航路と同じように関係によっては字を使って相手を呼んだ方が 雰囲気出るんじゃないかなあと思いますが これはまあ作者も考えてのことでしょう。
魏志 文帝紀 建安マエストロ!1 (MFコミックス フラッパーシリーズ)

・Amazon さん
Amazonさんになければ(お届けまで時間がかかるとか) 世の中どこででも品薄だと思ってるような発言を割と見かけるような気がするんだけど、 どーなんでしょね。 そりゃあものにもよるだろうけど(限定版とか限定版とか限定版とか)、 それを除けば特に書籍なんかは大型書店あたれば Amazon になくてもすぐに手に入ったりするのは良くあると思うんだけど。 そういう店に行くのが大変という人にはごめんなさいだけど (あ、でも、結構通販やってるよね。ジュンク堂とか。まあ送料が。という話か)。

・amazonさんその2
…えーと、なんだったっけ。

・暗黒通信団
書泉グランデとかで扱うようになって結構うれしい>暗黒通信団の本 どんな人たちなんだろうか。

■_


【Perl,PHP】LLバトルロワイヤル9【Ruby,Python】 
905 デフォルトの名無しさん [sage] 2010/04/10(土) 00:25:38 ID: Be:
    1年前くらいに応募した会社が東大だか京大だかの学生ベンチャーから始まった会社で
    やたらデザインパターンだ設計理論だを知ってるかどうかばっかり聞かれたあげく
    PHPの仕事やってたんですかプププ
    うちは最近はRubyしか使わないんですよねーとか言い出したんで断った 

906 デフォルトの名無しさん [sage] 2010/04/10(土) 00:43:10 ID: Be:
    >>905
    キミは自分から断ったつもりでいるかもしれないけど、
    それどう見ても相手から先に断られてるから。

    どうしても業界全体に、一つの言語しか使えないやつが使う言語はPHPだ、
    みたいなイメージがあるから、PHPで仕事してたことを強調するのはかえってマイナスになる気がする。
    別にRubyがそんなにすごいとは思わないけど、PHPが蔑まれているのは確かだよ。

907 デフォルトの名無しさん [sage] 2010/04/10(土) 00:55:35 ID: Be:
    >>905
    正解
    あいつら他人を使い捨てることしか考えてない 

908 デフォルトの名無しさん [sage] 2010/04/10(土) 01:04:08 ID: Be:
    >>906
    お互い方針があってないんだから両方から断ったみたいなもんだよ
    ちなみにJavaでECサイト作るようなのが本業でPHPは週末に受託してた仕事くらいしかやってなかったのに
    明らかにPHPを使ったことを見下してたからさ 

909 デフォルトの名無しさん [sage] 2010/04/10(土) 01:05:21 ID: Be:
    俺の勝手なイメージだけど、PHP界隈はPHPしか知らないやつらが
    フレームワークの開発合戦をしている感じ。
    しかもかなり誹謗中傷がすごい。
    それもPHPという閉じた環境の中で。
    そんなことにエネルギーを使うくらいなら、他の言語でも勉強すればいいのにと思う。
    とにかく視野が狭いやつが多すぎで、そいつらがフレームワークの開発をしているんだから、
    質は推して知るべし。 

910 デフォルトの名無しさん [sage] 2010/04/10(土) 01:06:31 ID: Be:
    相手が言ったまま書き起こすとだいたいこんな感じだった
    「PHP、PHPですか(小笑) PHPってちゃんと書けます?いやね、ちょっといじってみたら1日で覚えられたんで、
    仕事で使う言語なのかなって。いや、最近Rubyしか使わないんで、PHPは全く知らないんですけどね(小笑)」 

911 デフォルトの名無しさん [sage] 2010/04/10(土) 01:10:38 ID: Be:
    PHP・・・ふははっ!PHP! 

912 デフォルトの名無しさん [sage] 2010/04/10(土) 01:21:45 ID: Be:
    変な癖が付きそう、バカが伝染りそうと、食わず嫌いな人の多いお手軽言語。
    VBとキャラかぶってんな。 

913 デフォルトの名無しさん [sage] 2010/04/10(土) 01:30:32 ID: Be:
    プログラマのレベルとしてはRubyではちゃんと書けるけど
    PHPではちゃんと書けないってのはかなり低レベルな気がする
    PHPみたいに制限が緩い言語では作れないって事だろ要するに 

914 デフォルトの名無しさん [sage] 2010/04/10(土) 01:30:51 ID: Be:
    >>899
    ダックタイピングは、ある意味全てのクラスが
    インタフェースとでも言うべきか
    型の静的な保証をしない、実行時に決定するというだけ 

915 デフォルトの名無しさん [sage] 2010/04/10(土) 01:51:35 ID: Be:
    どうしてPHPはバカにされるんだろうな
    俺もPHPは嫌いだけど 

917 デフォルトの名無しさん [sage] 2010/04/10(土) 02:10:24 ID: Be:
    PHPでも一応クラスは作れるってんで
    クラスを使ってプログラム書いたら
    理解されなくて困ったことあるお(´・ω・`) 

918 デフォルトの名無しさん [sage] 2010/04/10(土) 02:20:40 ID: Be:
    それはひどいw 

919 デフォルトの名無しさん [sage] 2010/04/10(土) 02:30:37 ID: Be:
    PHPのクラスはわかりやすい方だろ
    C++やJavaやってるやつならPythonとかで作ったのよりぜんぜん見やすい 

920 デフォルトの名無しさん [sage] 2010/04/10(土) 02:32:26 ID: Be:
    >>910
    うっかり python の名を口にしたら
    「なにそれ?誰も使ってねーし」
    見たいな返事が来た可能性があるなw 

921 デフォルトの名無しさん [sage] 2010/04/10(土) 02:54:29 ID: Be:
    >>917
    まあ、それがPHP専業プログラマのレベルなんだろうな 

922 デフォルトの名無しさん [sage] 2010/04/10(土) 02:56:47 ID: Be:
    PHPだってある程度の規模は今時みんなオブジェクト指向だぜ
    ホームページ製作会社が軽い掲示板みたいなの作るイメージみたいなの持ちすぎ 

923 デフォルトの名無しさん [sage] 2010/04/10(土) 03:49:55 ID: Be:
    PHPなら速さで勝負しろよ 


推薦図書/必読書のためのスレッド 55 
727 デフォルトの名無しさん [] 2010/04/10(土) 00:09:37 ID: Be:
    待ち遠しくて濡れ濡れだよ。

    191 名前:デフォルトの名無しさん [sage] 投稿日:2010/04/09(金) 02:01:50
    http://www.artima.com/shop/overview_of_the_new_cpp

    Presentation Materials: Overview of the New C++ (C++0x)
    by Scott Meyers
    Single-user license (personal use only)
    $29.96

    これはなんだー 

728 デフォルトの名無しさん [sage] 2010/04/10(土) 00:26:29 ID: Be:
    三日間トレーニングコースの教材みたいだが
    これがそのまま本になることはなさそうな
    待ち遠しかったから今注文しちゃいなYO 

729 デフォルトの名無しさん [sage] 2010/04/10(土) 03:47:43 ID: Be:
    >>727
    へ~、C++0xではnullptrというのが定義されるんだ。
    和訳はヌルポ? 

730 デフォルトの名無しさん [sage] 2010/04/10(土) 04:19:12 ID: Be:
    >>729 がっ何か言ったぞ 

731 デフォルトの名無しさん [sage] 2010/04/10(土) 07:40:48 ID: Be:
    >>727
    まだC++0xの仕様も定まってないのに本出してどうすんのと思う 

■_ ああ無常

stackoverflow から。 What are things that make a programmer's life miserable? (プログラマーの生活を惨めにさせるものとは?)


What are things that make a programmer's life miserable? - Stack Overflow

What are things that make a programmer's life miserable?


Not having admin rights on my machine.


Nobody here runs as an admin for day to day use, and I don't even do it at home 
(unless UAC is on). What a select few of us get is a second admin account that we can 
use when needed (Run As) to perform administrative taks. It's actually not so bad 
doing it this way, but I'd be stuck with no admin rights at all.

All actual examples that I've encountered in the past five-six years:

    * Having to use corporate standard hardware that may make sense for Joe/Jill in 
      accounts but proactively prevents productivity if you're a programmer and are so
      bad that people bring in their own hardware like monitors or external drives.
      Classic example - "Can I have a bigger harddrive please?" "You're
      not supposed to store stuff on your local harddrive but must use the network
      drive (which is 500MB)" "OK, can I have about 50GB network drive space
      then because that's what it takes to compile the software" "No"

    * Being stuck with hardware that's ten years old because the system you're working 
      on runs only on an OS that is not "corporate standard" anymore so you can't 
      buy any new hardware. But the tools we should be using were not meant to run on
      a box with that low a spec and crawl, if that.

    * Virus scanners that interact so badly with the new corporate standard version 
      control system that check outs take hours (instead of minutes as they do on Linux)

    * The assumption that you don't need additional tools, except the minimum IDE, 
      because "nobody else wants it" and "if you needed it, the IDE
      vendor would ship it". Plus of course the offers of buying it yourself and
      installing it on your machine gets knocked back because you're not allowed to
      install non-approved, non-standard software. OK, I'll go performance tuning
      without a profiler then, no worries

    * Working in a really noisy open plan office so you can't concentrate because 
      people are constantly shouting, then get shouted at because you're not getting
      any work done

Not to mention the usual big corporate style mentality that permeates even small 
companies these days.

Constant interrup...


Lack of specifications.


   1. No Time to learn new things. Sure i can study books, blogs, boards in my offtime. 
      But when i've worked 12 - 14 Hours a day iam not in the mood to turn on my
      notebook and start reading.
   2. No rewards from Team-Leaders (non prgrammers) , they think it is just an easy 
      job to code some nice webapplications.
   3. Working on boring projects
   4. CEO has read this great new book on management and wants everyone else to


    * legacy code with no tests, no docs, etc
    * vendor lock-in (e.g. ancient oracle db)
    * and only for me: CSS and graphics


+1, but might I suggest your add "WRITING legacy code" to your list. 
Maintaining crap code is one thing, doing nothing to shore it up is another, but 
further propagation of bad patterns/practices is grounds for standing in front of
the Nerf firing squad.

Microsoft Access.

    * Bad non-standard SQL engine
    * Poor DDL support
    * Non-standard data types (e.g. Number, Yes/No)
    * Scales badly
    * Version-sensitive
    * Deployment problems


non-programmer managers


"We don't allow STL" (C++ standard template library) The reason? "It is not standard."


Yes, "let's implement our own collection classes that don't throw 
exceptions!"

We had a no inheritance rule (in C++) because you wouldn't know where the 'real' 
function was! 



8 bosses, I have 8 different bosses! Yes I did get the memo.....

みねこあさんがタイムリーなことを。 2010-04-10 - みねこあ 新しい職場・新しい現場になって割り当てられたマシンは、Windows XP でメモリ 256MB と、 ちょっと仕事するには難しい環境でした。C++なぞコンパイルした日には、死んでしまいます。

2010-04-10 - みねこあ

で、The UNIX Time-Sharing System を読みたい気持ちが盛り上がって読んでいたりしています。
(英語なので遅々と進まずなのですが/日本語訳どこかにないかしらん)

ネットに上がってるかどうかはともかくあったような気も。

■_

ジュンク堂のWeb技術本トークセッションに行ってきた - 思っているよりもずっとずっと人生は短い。
http://d.hatena.ne.jp/takahashim/20100408/p1

  そうそう、それとは別に『渕一博―その人とコンピュータサイエンス』という大変素晴らしい
本も出ているのですが、これについては改めて書きます。
  

「とりあえずここだけでも読め」といわれたところは読みましたが これはオススメですね(気が早い)。
渕一博―その人とコンピュータサイエンス

■_ IPv6

IPv6はなぜIPv4と互換性を持たせなかったのですか?(1/1) | OKWave
IPv6はなぜIPv4と互換性を持たせなかったのですか?

IPv6はなぜIPv4と互換性を持たせなかったのですか?
もうすぐ枯渇するIPv4と互換性のないIPv6に、
どうして一生懸命カネと時間を要して対応させようとしているのでしょうか?
しかもこれ、お隣さんが言い出したあやしい代物。
ユビキタスが当たり前になればIPv6も永久的じゃないし。

技術的知識は分かりませんが、
IPv4をそのまま付加する形(NATではなくネットワークアドレスを長くする)でカネと時間を
要して対応させることを考えた方がいいと思うのですが…

(万が一足りなくなれば、ファームアップ1つ、自動更新1つで対応完了!みたいな感じのプロ
トコルを。)

IPv6プロトコルじゃないといけない理由をご教示願います。

どういう「互換性」をお求めなんでしょうかこの方は。 回答者もアレだなーと思ってたけど、さっき見たら割とましな回答がついてた。 にしても「お隣さん」?

■_

2010年04月09日

■_

・東スポ
いくらなんでもこれは…w

人気アニメ「機動戦士ガンダム」の主題歌に“たちあがれ”のフレーズが使われていることから
  既に一部のガンダム世代のハートはつかんでいる新党。選挙では“たちあがれ”
  “たちあがれ○○(候補者名)”と有権者が党や候補者を鼓舞するスタイルの投票になりそうだ。
  

ハートつかんでるんですかっw

■_ 構文糖


【Perl,PHP】LLバトルロワイヤル9【Ruby,Python】 
892 デフォルトの名無しさん [sage] 2010/04/09(金) 09:31:17 ID: Be:
    全ての言語はLispのシンタックスシュガーですが何か? 

893 デフォルトの名無しさん [sage] 2010/04/09(金) 09:40:11 ID: Be:
    ん?アセンブラの文法砂糖 

894 デフォルトの名無しさん [sage] 2010/04/09(金) 17:08:58 ID: Be:
    文法砂糖ってはじめて聞いたわ 

895 デフォルトの名無しさん [sage] 2010/04/09(金) 19:36:06 ID: Be:
    syntax sugar 直訳だな
    普通は構文糖衣 

896 デフォルトの名無しさん [sage] 2010/04/09(金) 20:34:08 ID: Be:
    糖衣構文の方が良く聞く気がした 

897 デフォルトの名無しさん [sage] 2010/04/09(金) 20:39:31 ID: Be:
    どうでもいいけど
    糖衣構文 の検索結果 約 20,500 件
    構文糖衣 の検索結果 約 20,500 件
    ここまで一致するもんなのか?www 

898 デフォルトの名無しさん [sage] 2010/04/09(金) 20:48:35 ID: Be:
    ファジー検索で文節で区切って、結局同じ検索やってるだけだろ
    プロならダブルクォーテーションでくくれ 

syntax sugar じゃなくて、syntactic sugar の方が正しいっぽい。 Wikipedia の項目になってるのも syntactic sugar の方だし、 "syntax sugar" で検索すると、日本語話者のページが上位にやたらと引っかかる。 英語話者でも使ってる人はいるようだけど少数派のよう。


Syntactic sugar - Wikipedia, the free encyclopedia
Syntactic sugar

In computer science, syntactic sugar in a programming language is syntax designed to 
make things easier to read or to express, while alternative ways of expressing them 
exist. It makes the language "sweeter" for humans to use: things can be 
expressed more clearly, or more concisely, or in an alternative style that some may 
prefer.

Specifically, a construct in a language is called syntactic sugar if it can be removed 
from the language without any effect on what the language can do: functionality and 
expressive power will remain the same. All applications of the construct can be 
systematically replaced with equivalents that do not use it. For instance, in 
imperative programming languages, for loops can be systematically replaced with while 
loops, which in turn can be systematically replaced with gotos.

More generally, the term is used to characterize syntax as being designed for ease of 
expression. For instance, in C#, the property construct may be called syntactic sugar: 
it is roughly, but not exactly equivalent to a getter-setter pair of functions. Even 
more broadly, programming languages have been called "machine code with a lot of 
syntactic sugar".

The term was coined by Peter J. Landin, when he was working on a lambda calculus 
enriched with a few operations, such as assignment.[citation needed] Following 
Landin's insights, some later programming languages, such as ML and Scheme, were 
explicitly designed as a language core of essential constructs. The convenient, 
higher-level features could be "desugared" and decomposed into that subset. 
This is, in fact, the usual mathematical practice of building up from primitives.

(略)

つーわけで、直訳どうこうはおいても構文砂糖というのは 糖衣構文とか構文糖衣よりは元の語に意味が近いんじゃないかと。 でも「匿名メソッド」なんかのようにおかしいだろうとか指摘する気はありません。 これはこれでいいと思うし。 あー、話が飛ぶけど jargon file に「構文塩」ってもあったような気がする。 Syntactic Salt

■_ 鉄の男


Lisp Scheme Part29 
944 デフォルトの名無しさん [sage] 2010/04/05(月) 10:11:26 ID: Be:
    大規模規制中にスレ立てると、いろんな意味でもろばれな気がするわけだが 

945 デフォルトの名無しさん [sage] 2010/04/05(月) 12:32:52 ID: Be:
    lispたのしいよー 

946 デフォルトの名無しさん [sage] 2010/04/05(月) 20:56:12 ID: Be:
    Commonとこれとスレ分けるほど需要あるのか 

947 デフォルトの名無しさん [sage] 2010/04/05(月) 21:32:38 ID: Be:
    ム板自体が限界集落みたいなもんだから気にすんな 

948 デフォルトの名無しさん [sage] 2010/04/05(月) 21:54:42 ID: Be:
    処理系つくろうぜー 

949 デフォルトの名無しさん [sage] 2010/04/06(火) 00:08:36 ID: Be:
    人力処理系。 

950 デフォルトの名無しさん [sage] 2010/04/06(火) 00:17:27 ID: Be:
    処理系作るよりもFFIの標準化に努めてくれた方がありがたい。
    少しでも不満があるとすぐにオレオレSchemeを作るのは勘弁してほしい。 

955 デフォルトの名無しさん [sage] 2010/04/06(火) 20:46:57 ID: Be:
    処理系なんかより、利用すること考えないと。新参のF#に早くも負けるんじゃないのw 

956 デフォルトの名無しさん [sage] 2010/04/06(火) 21:17:51 ID: Be:
    開発環境Visual Lispつくろうぜー 

957 デフォルトの名無しさん [sage] 2010/04/06(火) 21:37:00 ID: Be:
    そういえば、autoCADの開発ツールでVisual Lispって名前のあるよね。

    visualに(GUI部品とかをグラフィカルに配置できるとか)開発できる、開発環境っていうと、
    AllegroCLとかLispWorksとかぐらい?
    AllegroCLはHPみると$599~見たいなことが書かれてるけどアカデミックだし、
    配布用ランタイムがオプションみたいだし…

    LispWorksも$1500は高いな。(といってもVS2008Proも13万くらいするから妥当?)
    だれかLispWorks購入ユーザーっている? 

958 デフォルトの名無しさん [sage] 2010/04/06(火) 21:43:31 ID: Be:
    Emacsを使おう
    Emacsに足りないものはマクロで作ろう
    たまにはマクロを役立てよう 

959 デフォルトの名無しさん [sage] 2010/04/06(火) 23:18:08 ID: Be:
    ということでいつも終わっちゃうだよなぁw 

960 912 [sage] 2010/04/07(水) 00:40:50 ID: Be:
    >>956 slime で OK

961 デフォルトの名無しさん [sage] 2010/04/07(水) 02:23:57 ID: Be:
    処理系何使ってる?
    今までguileとgaucheしか試したこと無かったんだけど、
    string->list,string->symbolで日本語が通るgaucheすげーとか思ってたら
    ypsilonやikarusでもできるのな。
    R6RS食わず嫌いだったけど、よく考えたらR5RSの資産なんて持ってないことにも気付いた。
    これからはR6RSで生きていくことにするよ。 

964 デフォルトの名無しさん [sage] 2010/04/07(水) 20:18:08 ID: Be:
    >>961
    自分は
    scm -> mzscheme -> gambit-c -> scheme48 -> guile -> chickenときて
    今はgauche
    2.0がでたらguileを併用するつもり
    それとR6RS対応scheme48がでたらR6RSに徐々に移行するつもり 

965 デフォルトの名無しさん [sage] 2010/04/08(木) 01:51:02 ID: Be:
    >>957
    LispWorks良いんだけど唯一の欠点がIDEから日本語扱えないって事かな
    Slime経由でしか使えないならIDEの分無駄

    ACLはできが良いんだけどそれで何か作っても配布できないのが困る
    結局PC-UnixにSBCLが一番楽だったりする。(俺はwindowsでも使いたいので涙目)

966 デフォルトの名無しさん [sage] 2010/04/08(木) 11:47:10 ID: Be:
    PLT-Schemeがあんまりいないのか 

967 デフォルトの名無しさん [sage] 2010/04/08(木) 11:51:29 ID: Be:
    stalinを本格的に使ってる人をみたことない 

968 デフォルトの名無しさん [sage] 2010/04/08(木) 20:48:50 ID: Be:
    >>967
    schemeだと思うと制限がきついからしょうがないと思う
    あとコンパイル遅いし

969 デフォルトの名無しさん [sage] 2010/04/08(木) 21:07:19 ID: Be:
    stalin を本格的に使い込む方法を書籍にしたら需要あるかもよ。
    題名は『普段着のスターリン』とか『いつでもスターリンと一緒』とかで。 

970 デフォルトの名無しさん [sage] 2010/04/08(木) 21:23:36 ID: Be:
    表紙は岡田真澄? 

971 デフォルトの名無しさん [sage] 2010/04/08(木) 22:24:22 ID: Be:
    >>970
    鼻から珈琲噴いたじゃねぇか 

972 デフォルトの名無しさん [] 2010/04/09(金) 00:20:42 ID: Be:
    >>966
    PLTいいよPLT。GaucheとPLTとIkarus使ってる。
    PLTはライブラリの豊富さが幸せ。 

973 デフォルトの名無しさん [sage] 2010/04/09(金) 18:58:19 ID: Be:
    >>969
    書籍にするほどの情報ないだろ 

974 デフォルトの名無しさん [sage] 2010/04/09(金) 22:35:28 ID: Be:
    おいばかやめろシベリアに送られるぞ。 


関数型プログラミング言語Haskell Part11 
761 デフォルトの名無しさん [sage] 2010/04/09(金) 21:27:54 ID: Be:
    モナドの定義で何をやっているのかぜんぜん分からなかった
    調べてみたら、論文に載るような難しい概念だということが分かった
    それからは、中身は特に考えずにそういうもんだと思い込んで使っている 

762 757 [sage] 2010/04/09(金) 21:32:29 ID: Be:
    >>759

    え? 写経って、本読んで考えながら、手も動かしてみることを
    言うんじゃないの?

    ちなみに、RWHの方が簡単? 

763 デフォルトの名無しさん [sage] 2010/04/09(金) 21:42:02 ID: Be:
    >>762
    写経=コピー
    理解できなくても、考えなくても、文字が読めて書ければ写経できる。

    RWH は応用だから対象読者が違う。 

764 デフォルトの名無しさん [sage] 2010/04/09(金) 21:42:22 ID: Be:
    >>761
    たぶん、「そういうもんだ」と思い込んでいる、その「そういうもんだ」と理解していることが、理解すべきことの全てだと思う。
    Monad クラスは形式的な枠組みを規定しているだけで、それ以上に意味も中身もない。

    イルカとサメが似ているようなもん。外見が似ている、それだけ。 

765 デフォルトの名無しさん [sage] 2010/04/09(金) 21:46:03 ID: Be:
    モナド則によってある程度意味を与えられていると思うが。

    それも含めて形式的な枠組みに過ぎないという事なのか 

766 757 [sage] 2010/04/09(金) 21:48:30 ID: Be:
    >>763

    >写経=コピー
    >理解できなくても、考えなくても、文字が読めて書ければ写経できる。

    写経って言葉を少し間違って使っていたようです スマンコ

    >RWH は応用だから対象読者が違う

    応用≒実践ってことかな?

    それだったら、RWHの方が目的にあってるような気がする・・・ 

767 Mail: sage [sage] 2010/04/09(金) 21:54:49 ID: Be:
    >>761
    モナドそのものについては圏論の初歩で理解できるよ。
    対象、射、(共変)函手、自然変換の4つの概念くらいしか必要ないし。
    あと「図式が可換」っていう意味が分かればモナドが弄れる。

    けど、どうしてこんなにHaskellで利用されているのかをつかむには不十分みたいなんだよね。
    頭で理解するより慣れた方が多分近道。
    あと、おそらくHaskellプログラマかつ非数学者のためのpdfがあるけど、案外不評。
    ttp://lambda-the-ultimate.org/node/1183
    証明に可換図式を使わないとこんなに面倒なのか、って思う。 

768 デフォルトの名無しさん [sage] 2010/04/09(金) 21:55:56 ID: Be:
    >>766
    そういうこと。
    5章から JSON ライブラリを作ってみたり、
    バーコードリーダーを作ってみたりといった実践が始まる。
    その中でテクニックを学んでいく。

    とりあえず RWH を読んでみて、
    説明を端折ってるなって思える部分に出会ったら、
    他の文献を当たるなりすれば良いと思う。 

769 757 [sage] 2010/04/09(金) 22:04:43 ID: Be:
    >>768

    THX 

770 デフォルトの名無しさん [sage] 2010/04/09(金) 22:07:34 ID: Be:
    >>765
    じゃぁ、言い直そう:

    イルカとサメが似ているようなもん。海を泳ぐ、それだけ。 

771 デフォルトの名無しさん [sage] 2010/04/09(金) 22:14:36 ID: Be:
    「中身は特に考えずにそういうもんだと思い込んで使っている」
    その先を目指して理解できると、きっと「より面白い」と感じると思うんだがなぁ

    イルカとサメがどーたらこーたらで止まってしまうのが、
    ちょっとだけもったいない気がする 

772 デフォルトの名無しさん [sage] 2010/04/09(金) 22:25:04 ID: Be:
    >>762
    RWH、と言うかオラ本は全般に説明がくどいね。変な例えとかジョークで厚みが増しトル。読み物的。
    それがイイって人も多いのかもしれないが。

    ついでに池袋ジュンク覗いてきたけど初版がまだ店頭に並んでた 

773 デフォルトの名無しさん [sage] 2010/04/09(金) 22:43:51 ID: Be:
    尼はまだ初版かな?<RWH 

774 Mail: sage [sage] 2010/04/09(金) 22:44:21 ID: Be:
    >>771
    まだ読んでないけど、この論文とかが圏論の言葉少なめ、
    計算機科学の言葉多めで面白いかもね。
    ttp://www.disi.unige.it/person/MoggiE/ftp/lics89.pdf

    もったいないかもしれないが、圏論の言葉をhaskellに翻訳すると、
    対象 = Haskellのすべての型(IntとかMaybe Stringとか)
    射 = Haskellでの関数::a -> b
    函手 = newtype,dataで作られる型Tのコンストラクタ::a -> T a
    自然変換 = t1 a -> t2 aという関数
    Kleisli Triple = 型T, return::a ->T a, =<<:: (a -> Tb) -> T a -> T b

    この後、どう面白くなるのかがまだ分からん。 

最近、英文の記事で「あんまりモナドモナド強調するな」とかゆーのを見た覚えが。 どこだっけ。

■_ 本日の巡回から

■_ ああ、これだ

Tic-Tac-Toe: Haskell ≪ Torquing Wet Strainers

Haskell is seriously packed with modern, interesting, expressive goodies.

But I have a message for the Haskell community: stop trying to “simplify” monads.  
Really, just stop.  I have yet to see an “explanation” of monads that does not add 
to the confusion and fear a novice might feel at approaching the language.  You don't 
need to know what a monad is in order to use the language effectively.  Talking about 
them to a beginner is about as useful as explaining loop unrolling and keyhole 
optimization to a beginning C programmer.  Later, yes, it's helpful.  But it's too 
much information at the start.  A beginner just needs to know that if you want to use 
code that does IO, it has to go inside a do, and if you want to pull out values and 
use them elsewhere, you need the <- operator.  It took me three nights of working 
on this one to learn that one, because the Gentle Introduction relegated I/O to 
chapter 7.

(以下略)

2010年04月08日

■_

・東スポ
「足利氏の大群」とかいう記述(多分誤変換)を見つけてしまって苦笑。 しっかりしてくれー。

・不景気を感じる
R.O.D の BD BOXを引き取りに行ったのですが、 売り場の模様替えがまたあったり (ちょっと前のより規模は小さいですが)で、大変だなあと。

■_

ruby-coreで見かけて興味深かったので。

Ruby - Bug #1240: parser bug in 1.8.7 and 1.9.1p0 - Ruby Issue Tracking System
Bug #1240 [ruby-core:22637]
parser bug in 1.8.7 and 1.9.1p0


ruby 1.9.1p0 (2009-01-30 revision 21907) [i686-linux]

説明

# ruby parser accepts first line, not the second.
x y { "#{}".z { } }
x y { "#{}".z do end }


#3
2009年03月04日 06:44 AM - Dave B

As there's no context for this "bug", I've tried to provide some.

The parser takes different routes depending on what has been seen,
so context is important.

def x(args=nil)
  p [:x_args, args]
  block_given? and (puts '--> x blk'; yield)
end

def y(args=nil)
  p [:y_args, args]
  block_given? and (puts '--> y blk'; yield)
end

class String
  def z(args=nil)
    p [:z_args, args]
    block_given? and (puts '--> z blk'; yield)
  end
end

  x y { "#{}".z  { "GIGO\n".display }   }
# x y { "#{}".z do "GIGO\n".display end }  # parser fail

# Contrasting with ...
p "#{}".z  { "GIGO\n".display }
puts '---'
p "#{}".z do "GIGO\n".display end
# ... what was "do end" in the original report
#  expected to bind to?


daz

#4
2009年03月04日 19:29 PM - Ryan Davis

On Mar 3, 2009, at 13:42 , Dave B wrote:

> As there's no context for this "bug", I've tried to provide some.

This isn't a "bug", it is a bug, as I think I've shown below.

(略)

So really there isn't any reason why this shouldn't be parseable. If  
this isn't solved by the weekend I'll take a whack at it with  
ruby_parser and translate/backport from there. I _hate_ these  
codepaths tho and I haven't gotten around to rewriting the string  
stack yet, so it isn't fun.

#5
2010年04月08日 00:31 AM - Yusuke Endoh

    * 担当者 Yukihiro MatsumotoからYusuke Endohに変更

Hi,

> # ruby parser accepts first line, not the second.
> x y { "#{}".z { } }
> x y { "#{}".z do end }


Interesting.  I found similar bugs:

  while ("#{}".foo { }   ); end # ok
  while ("#{}".foo do end); end # parse error

  while ->{ 1.times { }    }.call; done # ok
  while ->{ 1.times do end }.call; done # parse error

The cause is mishandling of cond_stack and cmdarg_stack.
When "#{}" is parsed, the parser pushes a value into these stacks once
(at #{ (tSTRING_DBEG)), and pops twice (at '}' and action of the rule
`string_content'.)

In addition, the parser forgets to push at ->{ (tLAMBEG).

I think it is better for not parser but lexer to push into the stacks
at tSTRING_DBEG.  See my patch.


BTW, I also noticed that block call with `do' keyword does not work in
`until' condition:

  until begin 1.times { }    end do end # ok
  until begin 1.times do end end do end # parse error
                      ~~
  until if true then 1.times { }    end do end # ok
  until if true then 1.times do end end do end # parse error
                             ~~
  until until true do 1.times { }    end do end # ok
  until until true do 1.times do end end do end # parse error
                              ~~
  until class Foo; 1.times { }   ; end do end # ok
  until class Foo; 1.times do end; end do end # parse error
                           ~~
  until case; when true; 1.times { }   ; end do end # ok
  until case; when true; 1.times do end; end do end # parse error
                                 ~~

This is because the underlined `do's are not considered as block call
but beginning of `until' body.

Although this is confusing a little and can be actually fixed, the fix
needs many COND_PUSH(0)/COND_POP(), which may decrease performance and
code maintenability.  In addition, writing such a long and complex
condition directly is absolutely bad (even insane) style.
So, we should accept the above behaviors as spec, I think.


Here is a patch to fix the issue Thomer reported.
I'll commit it unless there is objection.

diff --git a/parse.y b/parse.y
index 340a825..f234ae3 100644
--- a/parse.y
+++ b/parse.y
@@ -4033,14 +4033,10 @@ string_content	: tSTRING_CONTENT
 			$<node>$ = lex_strterm;
 			lex_strterm = 0;
 			lex_state = EXPR_BEG;
-			COND_PUSH(0);
-			CMDARG_PUSH(0);
 		    }
 		  compstmt '}'
 		    {
 			lex_strterm = $<node>2;
-			COND_LEXPOP();
-			CMDARG_LEXPOP();
 		    /*%%%*/
 			if ($3) $3->flags &= ~NODE_FL_NEWLINE;
 			$ = new_evstr($3);
@@ -5873,6 +5869,8 @@ parser_parse_string(struct parser_params *parser, NODE *quote)
 	    pushback(c);
 	    return tSTRING_DVAR;
 	  case '{':
+	    COND_PUSH(0);
+	    CMDARG_PUSH(0);
 	    return tSTRING_DBEG;
 	}
 	tokadd('#');
@@ -6070,6 +6068,8 @@ parser_here_document(struct parser_params *parser, NODE *here)
 		pushback(c);
 		return tSTRING_DVAR;
 	      case '{':
+		COND_PUSH(0);
+		CMDARG_PUSH(0);
 		return tSTRING_DBEG;
 	    }
 	    tokadd('#');
@@ -7314,6 +7314,8 @@ parser_yylex(struct parser_params *parser)
 	    lex_state = EXPR_BEG;
 	    lpar_beg = 0;
 	    --paren_nest;
+	    COND_PUSH(0);
+	    CMDARG_PUSH(0);
 	    return tLAMBEG;
 	}
 	if (IS_ARG() || lex_state == EXPR_END)

-- 

yacc は大変だ。などと斜め上な反応をしてみる。 このバグレポートはこの後もちょっと続いてるんですけどね。

■_ JavaからC++へ

stackoverflow から。

Shift from Java to c++ - Stack Overflow

Hello,

I have been developing applications based on C# (.net) and Java (J2EE) from the last 3 years.

But, now I feel, Java, C# makes you lame (from learning point of view) and you can develop
your apps quickly but you fail to understand the basic underlying concepts of programming.

So, I am trying to learn C++, but I find it a little "confusing" due to pointer,
multiple inheritance, some conventions and other concepts of C++ which don't exist in Java.
So, what do you guys suggest? How should I got about it?

Thanks

PS: I am a student, so have all the time in the world and actually shift.

とまあこれ自体はそれほど珍しい話でもないと思うのですが


In my opinion, you should learn C first in order to properly understand the base upon 
which C++ is built. Pick up a copy of "The C Programming Language" by 
Kernighan and Ritchie, widely considered the best reference on the language, and start 
reading through it. Once you fully understand C, you'll have the low-level base you 
need.


I totally agree. Learning calling conventions and how functions actually work really 
helped me understand how the C language works as a whole.

The inventor of the C++ language would disagree with you - his words "If you want 
to learn C++, learn C++".
 

Assembler and C don't have generic programming, polymorphic method dispatch, 
exceptions, operator overloading, constructors/destructors etc. So C++ is way more 
high-level than C, and those are the good parts of C++. The "old fashioned" 
part of C++ (the pointers that have the power to trash anything else in the address 
space) is the really bad part; it's perhaps worth understanding if only to get across 
the notion of what a poor choice of abstraction it makes for general programming. 


I disagree with the sentiment that you need to learn C or assembly language first. C++ 
and C may be similar in theory but are very different in terms of practical use. One 
gains little to nothing in the way of C++ idioms by using only C, and while it is good 
to have practical experience in multiple languages, it's an exercise in futility to 
specify prerequisites in language learning. I think the best way to learn the concepts 
of programming is to sit down with someone who understands them well and just talk 
about it, be that on StackOverflow, in forums, or, if you're lucky, in person.

At the end of the day, I think programming really isn't all that hard, and you may 
need someone to explain it right just one time to have everything click. It's all 
about rehashing the same simple concepts over and over to build complex and beautiful 
machines.


I would suggest learning assembly language first. This will give you a very solid 
foundation in what is happening at a low level. This will also help to reinforce the 
idea that "everything is really just an address".

Taking a class which focuses on assembly language is advisable since it will 
"force" you to learn it (personally, I don't think ASM is /that/ fun, but it 
was worthwhile [and a requirement for graduation] for me to take the class).

After you know assembly, go on to C and C++.

Have a lot of fun!

If you want to understand the underlying concepts of programming languages, I would 
suggest a book such as John Mitchell's Concepts in Programming Languages. Follow this 
up by writing a few parsers/interpreters for simple languages. Another good resources 
is SICP, which is specific to Scheme (a LISP dialect), and available in full here. 
Once you've learned a few languages, it doesn't take too long to pick up the syntax 
and semantics of a new one (the core libraries on the other hand, can take quite a 
while to be familiarized with).

If you want to learn about how today's computers work, I'd recommend learning C and 
reading books such as Tanenbaum's Modern Operating Systems. C is useful in this 
context mostly for reading systems level code. Implementing a (very) simple operating 
system can be incredibly educational. However, something as simple as implementing a 
basic shell (like bourne shell, except simpler) is probably a better place to start. 
I'd also recommend learning about how networking works specifically, since it's such 
an integral part of modern computer systems.


Personally, I don't think C++ is any great loss in system development. There are still 
fields in which it is useful, but these are very specialized. C++ was never a good 
general purpose teaching language and while many good engineers started out learning 
C++, I don't believe there's any causality here. If you want to learn about pointers 
and memory management, it's much better to learn C, which doesn't add a plethora of 
other new language features in addition to the pointers and memory management. 

Assembly Language.

Start with the Z-80. Then add 'x86. Then try 68000. Then the TI 320 series of DSP. You 
might also wish to add the Z-8. Just to see how different machines do it.


Understanding the principles of assembly language is very helpful and not difficult 
(registers, 3 address codes, knowing what the instruction sets contain, etc.) will 
help. IMHO the effort of being able to write a program in assembly isn't worth it. You 
rarely ever need to go more low-level than C. 


Set up a performant C++ compiling environment such as Microsoft Visual C++ 2008 
Express and go through all links in Bjarne Strousrup's The C++ Programming Language 
site, beginning with C++ Style and Technique FAQ. If you are experimented in any other 
language you don't need more :-) cheers, AR


C and C++ make some basic underlying programming concepts more evident, but they 
weren't designed by God. I'd second the suggestion to study the actual low-level 
systems behind your low-level code: operating systems, compilers/runtimes (try 
"Essentials of Programming Languages"), and machine architecture.

P.S. In general it may be better to study C++ on its own, rather than starting with C, 
but for your particular purpose -- getting more intimate with low-level, unsafe 
constructs such as pointers, after already learning Java -- I think it's better to 
start with C (and K&R) where these are front and center.


I think you should start with C, but not as a necessary preamble for learning C++. 
Rather, for learning C. In other words, while you learn C put your efforts into 
learning the language, feeling the philosophy of the language and focusing on letting 
it sip into your skin. Be a good C programmer and you will be a good programmer, 
period. Not just a good C++ programmer -- this has nothing to do with learning C -- 
but a good programmer.

There's another reason for learning C first. It's easier than C++, much easier than 
C++, and it bridges well to C++ (in contrast to Java, which doesn't in all aspects but 
the most superficial object-oriented ones). I'm not talking about the syntax 
similarities: I'm talking about low-level programming. I'm talking about the concepts 
of pointers, which exist as themselves and in the form of iterators in C++. You can 
pass around functions in C, and you can pass around function objects in C++. C is fast 
to learn, and it will warm you up very effectively.

Learning C will also eliminate the fear of free functions some pure OO programmers 
tend to have. C++ is a hybrid language, and C truly is a subset of C++, not just by 
syntax but by philosophy as well.

Start by getting yourself the K&R book and drinking it through. You won't regret 
this.

C 先にやれとかアセンブリ言語やれとか。 海の向こうもあまり変わんないみたいですねw

■_ サイアクな hack

What do you consider your "worst" hack? - Stack Overflow

What is the worst hack you've ever written? This is different from What is the worst 
code you've ever written?, because that, as I understand it, revolves around code 
later called worst because of ignorance.

hack: code written, knowing it is horrible code, for the sake of convenience, 
deadlines, working around another broken system or bug, etc., but not ignorance.

If you want, you can describe your co-workers' reaction, how bad your hospital bill 
was after showing them the code, if you felt disappointed in yourself for coming up 
with it or proud of yourself for coming up with a creative and clever solution.

This doesn't have to be shipped code, this could also be code written for personal 
purposes.

んで


Well, this one isn't mine, but I heard about it from a game developer the other day:

#define const


The next line is #define private public.


and #define class struct 

const 教に喧嘩売ってるし。

■_ 本日の巡回から

2010年04月07日

■_

むー
本読みも翻訳もぺーすがあがらんぞなもし。

大家
mixi のコミュで、大家(おおか。おおやじゃないよw) がベイスターズ復帰とか言うのが出てたけど本当なのかな。

■_ しんじらんない

本人にしてみれば入れりゃいいってのかもしれないけど。

IT企業 課題と就職について(1/1) | OKWave

IT企業 課題と就職について

 IT企業の就職選考の課題で電卓とストップウォッチのプログラミングの課題を出されました。
締め切りは4月12日になります。

とりあえず、C#をダウンロードしたのですが、いままで、プログラミング未経験で全く分かりません。

googleでいろいろと検索してもさっぱりです。あと5日でこのプログラミングの課題をクリアす
るのは無謀なんでしょうか?また何かいい解決策はありますでしょうか?

 また今年で大学を卒業してしまった身分なのですが、未経験でIT業界へ既卒として、就職活動
するのは全く無理なのでしょうか?

 この2点について、教えてください。どうぞよろしくお願いします。

「IT企業」つーても、事務やらなんやらプログラミングしない部署もそりゃあるんだろうけども、 こういう「課題」が出される時点でどういう仕事するのか疑問に思わないんだろうか?

1.ネットで探すより参考書を探した方が速いです。ストップウォッチのプログラミングは基本
中の基本ですので。

2.学生時代にプログラミングを学んできた人と比べたら、厳しいでしょう。

  

迅速な対応ありがとうございます。書店でC言語の参考書の内容を調べましたが、ストップウォ
ッチについて載っている参考書はありませんでした。かろうじて、電卓のみが載っているものを
発見し、それを購入して、開いて見ていますが、最終章に電卓のプログラミングが載っており、
なかなか時間がかかりそうだなぁという印象です。この会社は切り捨てて、他の会社にあったて
みることも考えています。

>>1.ネットで探すより参考書を探した方が速いです。ストップウォッチのプログラミン
グは基本中の基本ですので。


職業訓練を経て、資格取得も視野に入れてます。しかし、このご時世かなり不安なものです。
>>2.学生時代にプログラミングを学んできた人と比べたら、厳しいでしょう。
  

「ストップウォッチ」つーても仕様がぜんぜんわからんしなあ。

■_

あ、そうそう。 昨日のHaskellはなんで popular でないのか、ですが、 コメントにこういうのがあったりして。

> I rather suspect all the good ideas of Haskell will be stolen by the likes of C# 
> and hybrids like F# or OCaml,and people still won't ever use Haskell itself. It's
> just too different.

This has sort of been the fate of Smalltalk - it's been strip mined for good ideas 
without ever being widely adopted. Which I guess is slightly better than being ignored :)

Smalltalk と同じ運命をたどる?

■_

美しきObjective-C
Objective-Cというプログラミング言語があります。
C言語をベースにオブジェクト指向言語のSmallTalkの拡張を施した言語です。
オブジェクト指向を取り入れたC言語にC++がありますが
根本から拡張されているC++と違い
Objective-Cは素のままのC言語にSmallTalkを融合させたような形を取ります。

あちゃーw

■_ 日本は

github のコミット情報からさぐるなんとかんとかというやつで。 i'm a lumberjaph ≫ Blog Archive ≫ Github explorer

i'm a lumberjaph » Blog Archive » Github explorer
Japanese hackers community

    properties of the graph: 559 nodes / 5276 edges

Japan community on github

This community is unique on github. In 2007, Yappo created coderepos.org, a repository 
for open source developers in Japan. It was a subversion repository, with Trac as an 
HTTP front-end. It gathered around 900 developers, with all kind of projects (Perl, 
Python, Ruby, Javascript, …). Most of these users have switched to github now.

Three main communities are visible on this graph: Perl; Ruby; PHP. As always, the 
Javascript community as a glue between them. And yes, we can confirm that Perl is big 
in Japan.

We have seen in the previous graph that the Japanese hackers are always isolated. We 
can assume that their language is an obstacle.

This is a really well-connected graph too.

unique と。

2010年04月06日

■_

さくらさくら

ちょっと変わったデジカメで撮影。 変わっているので思い通りに撮れないところがまた楽しい。

■_ Why is Haskell used so little in the industry?

stackoverflow から。 けっこう伸びてるんですが、さいしょのがなげーーーっ

Why is Haskell used so little in the industry? - Stack Overflow

Why is Haskell used so little in the industry?
なぜ Haskell は industry ではほとんど使われていないのでしょうか?

It is a wonderful, very fast, mature and complete language. It exists for a very long 
time and has a big set of libraries. Yet, it appears not to be widely used. Why? I 
suspect it is because it is pretty rough and unforgiving for beginners, and maybe 
because its lazy execution makes it even harder haskell functional-programming subjective

Haskell は worderful で、とても高速で、mature で完全な言語です。非常に長期間存在してい
て、ライブラリのbig set も備えています。それなのに、Haskell はそれほど広く使われている
ようには見えません。なぜでしょうか? わたしは Haskell がビギナーにとって pretty rough 
で unforgiving であり、そしておそらくは遅延実行が Haskell での関数プログラミングをより
難しいものにしているからではないかと考えています。


   1. Nobody's ever heard of it. No one's going to use something they don't know exists.

      誰もその名を聞いたことがなかったから。自分がその存在を認識していないものを使おうとする
      人はいません。

   2. It's unpopular. People assume that the most popular language is the best language,
      because if it wasn't good, it wouldn't be popular. This is actually untrue; as you can
      see, the most popular language is the most popular language. To put it another way,
      Haskell is unpopular because it's unpopular. This is what Haskell programmers refer to
      as "recursion", and despite what imperative programmers tell you, it's extremely
      common in The Real World.

      ポピュラーでない (unpopular だ) から。人は最もポピュラーな言語をベストな言語だとみなし
      ます。なぜなら、その言語が良いものでなかったらポピュラーなものにはなっていないだろうか
      らです。これは現実には真とはいえません。見ればわかるように、最もポピュラーな言語とは最
      もポピュラーな言語なのです。これを言い換えると、Haskell がポピュラーでないのはポピュラ
      ーでないからなのです。これは Haskell プログラマーたちが “再帰”(recursion) とみなして
      いるものであり、命令型のプログラマーがあなたに言っていることに関わらず、現実世界
      (The Real World) においては extermely に一般的 (common) なものです。


   3. It's different. People are always afraid of what's different.

      異質だから。人間は常に異質なものに恐怖感を持ちます。

   4. It's difficult. People think that Haskell is difficult to understand or difficult to
      learn. This is almost certainly related to point #3. It's also related to the fact that
      the Haskell community is populated by people who casually remark "a monad is just 
      a monoid in the category of endofunctors, what's the problem?" and expect normal 
      human beings to comprehend this.

      難しいから。人々は Haskell を理解するのも学習するのも難しいものだと考えています。
      これは#3とかなり関連しています。また、Haskell コミュニティが "a monad is just a monoid
      in the category of endofunctors, what's the problem?" (モナド? 単なる
      category of endofunctors におけるモノイドじゃないか。何か問題でも?) だと
      casually remark      する人たちで溢れていて、そして normal human であってもこれを
      comprehend することを期待されているという事実にも関係しています。

   5. It's risky. Most companies don't want to be the first to use something. Haskell isn't
      being used by many people, so not many people want to try it. (See this recursive
      unpopularity argument again?)

      リスキーだから。大部分の企業は、自分たちが何かを使う最初の企業になろうとは考えません。
      Haskell は多くの人に使われているものではないので、それに挑戦しようという人も多くはない
      のです(これまた unpopularity の話の繰り返し?)。

   6. Can't hire programmers. First, by #2, there aren't many programmers who already know
      Haskell. Second, most people believe #4, which means you can't train programmers to use
      Haskell. (At least, it would if it were actually true.) A language that you can't hire
      programmers for is a very, very risky proposition indeed. (Which leads us back to #5.)

      (Haskellを使えるような)プログラマーを雇えないから。第一に、#2によってすでに Haskellを知
      っているというプログラマーは多くありません。第二に、大部分のプログラマーは#4を信じていま
      す (At least, it would if it were actually true) 。あなたがプログラマーを雇えないような
      言語はとてもとてもリスキーなポジションにあります(Which leads us back to #5)。


   7. Libraries. This is probably the big one, so I'm going to spend some time on it.
      ライブラリ。これはおそらく最重要なものなので、時間をかけます。

      A. Quality. We have the quantity. We do not yet have the quality. Most of Hackage is
         one-man hobby projects with little to no documentation. Some of it is incomplete,
         some of it has long since bit-rotted, some of it malfunctions if used in certain
         ways.

         品質。わたしたちには量 (quantity) はありますが、質 (quality) は未だにありません。
         Most of Hackage は one-man hobby projects で ドキュメントは少ないか皆無だったり
         するものです。ライブラリのうち一部のものは不完全であり、一部のものは bit-ratted 
         してから長時間経過していて、あるものは特定の方法で使ったときに誤動作します。

      B. The Outside World. If you want a binary heap tree, Hackage probably provides a
         dozen implementations. If you want to connect to an RPC server and fire off a few 
         procedure calls... good luck with that. Same deal for talking to databases,
         accessing OS resources, manipulating binary file formats... You'll basically have
         to write everything yourself from scratch. This is a big deal for commercial work.

         The Outside World. あなたがバイナリヒープツリーを必要としているのなら、おそらく
         Hackage には数ダースの実装があることでしょう。RPC サーバーに接続したければ幾つか
         の手続き呼び出しを fire off して… good luck with that. データベースとの対話、
         OS 資源へのアクセス、バイナリファイルフォーマットの操作などについても同じです。
         基本的にはあなたはすべてを自分の手でゼロ (from scratch) から書かなければなりま
         せん。これは commercial work には重大な問題です。

      C. Multiple incompatible libraries. You can, in fact, connect to a database in Haskell.
         Trouble is, at the last count there's about a dozen libraries for doing this, and
         it's bewildering trying to figure out which ones are actively supported and which 
         ones are zombie projects that stopped working years ago. It's also not as simple as 
         hooking up an ODBC connection; there are different backends for each library and
         each DB target. Yay. :-/

         複数のバグ持ちライブラリ。実際問題、データベースへの接続は Haskellでもできます。
         問題はデータベースへの接続を行うライブラリが数ダースもあって、あるものは活発に
         サポートが行われているのに、別のあるものは作業が何年も前に止まってしまっている
         ゾンビプロジェクトといったことを見分けなければならないことに戸惑ってしまうこと
         です。それは ODBC コネクションを hooking up するような単純なものではありません。
         ライブラリやターゲットとなるDBごとに異なるバックエンドが複数存在しているのです。
         Yay. :-/

      D. Windows. Almost all the important libraries (for cryptography, binary file formats,
         network protocols, data compression, talking to databases, etc.) are Haskell wrappers
         around C libraries. And these all fail to build on Windows. Given that Windows is
         the single biggest target platform on the market, this is a big deal.

         Windows。重要なライブラリ (暗号化、バイナリファイルフォーマット、ネットワークプロトコ
         ル、データ圧縮、データベースの取り扱いなどなど) のほとんどすべては C で書かれているラ
         イブラリの Haskellラッパーです。そしてそういったライブラリの全てが Windows 上でのビル
         ドに失敗するのです。Windows は市場における single biggest target platform  でありとて
         も重要です。


   8. Unpredictable performance. This is way, way down at #8. Most people don't know enough
      about Haskell to even know this. Most people just assume that "Haskell is slow".
      This is demonstratably untrue. What is true is that it can be hard to redict the
      performance of a Haskell program. Subtle, apparently irrelevant changes can sometimes
      make big performance differences.

      予測のつかない性能。This is way, way down at #8. 
      ほとんどの人は Haskell to even know this についてさえ十分に知っていません
      大部分の人が“Haskellは遅い”と思い込んでいますが、これは demonstratably に untrue
      です。実際は Haskell プログラムの性能を redict するのが難しい場合があるということ
      なのです。些細で apparently irrelevant な変更が時として大きな性能の変化をもたらす
      場合があります。


   9. Correctness. Most companies don't give a ** about correctness. They don't care about
      quality. They just want to shovel code out the door as fast as possible and earn wads
      of cash. If there are bugs, they'll charge the customer money to fix them. Getting code
      right is of no interest; getting code fast is what counts. Haskell is a language that
      rewards those who sit back and deeply analyse the problem, and them produce a beautiful
      solution. Most companies don't care for this approach; let's just hack something
      together as fast as possible, and worry about fixing it later (i.e., never).

      正確さ。大部分の企業は don't give a ** about correctness です。彼らは品質について無頓
      着です。彼らはただ、可能な限り早くコードをでっち上げて多額の現金を得たいだけなのです。
      もし出荷したプログラムにバグがあれば、彼らはそのバグを修正するためのお金を顧客から徴収 
      (charge) することでしょう。彼らは正しいコードを得るということには何の興味も持っておらず、
      短時間でコードを得ることが重要なのです。Haskell は、sit back して問題を深く解析し、
      そして美しい解決策を編み出すような人たちに報いる言語なのです。大部分の企業はこのような
      アプローチに注意を払いません。ただ単に可能な限り早く何かを一緒にハックして、修正について
      の心配は後回しにしている(あるいはまったく心配しない)のです。正確であることが重要である
      場所が幾つかあります。一般的にはそれは safety-critical systems か financial systems の
      いずれかです。I gather Haskell tends to be quite popular here.

One final pair of data points:

    * I can still remember not so long ago hearing people cry "C++ is a toy language
      for n00bs! You should use a proper programming language like C." Now take a look
      around you and see how many large-scale C++ programs there are.

      それほど遠くない昔、人々が
      "C++ is a toy language for n00bs! You should use a proper programming language like C."
      (C++ は n00bs 向けのおもちゃ言語だ! C みたいな適切なプログラミング言語を使うべき)
      と絶叫していたことをわたしは思い出します。今周囲を見渡してみて、どれほどの large-scale
      C++ programs がいるのか確かめてください。

    * People have been claiming that Lisp is "the next big thing" for, what, 
      40 years now? Lisp is older than almost every programming language in mainstream use. 
      And how many large-scale Lisp programs are there?

      人々は Lisp こそが“次の big thing”だとこの 40年間主張してきました。
      Lisp はメインストリームで使われるほとんどすべての言語よりも古いものです。
      また、どれだけの数の large-scale なLispプログラムが存在しているのでしょうか?


Which fate awaits Haskell, I don't know. I rather suspect all the good ideas of 
Haskell will be stolen by the likes of C# and hybrids like F# or OCaml, and people 
still won't ever use Haskell itself. It's just too different.

どちらの運命が Haskell を待ち受けているのかわたしにはわかりません。むしろわたしは、
Haskell の持つ good ideas すべてが C# のような言語に盗まれていったり、F# や OCaml のよ
うにハイブリッドなものになっていくだろうと考えています。しかしそれでも人々は Haskell 
そのものを使うことはないでしょう。ただ単に (Haskellは他の言語と) 違いすぎるのです。

But anyway, as to why industry doesn't use Haskell, see the points above. It's too 
rare, too unpopular, too weird, and has incomplete libraries. That's basically it, in 
a nutshell.

いずれにしても、industry では Haskell を使っていない理由はすでに述べたとおりです。
It's too rare, too unpopular, too weird, and has incomplete libraries. 
That's basically it, in a nutshell.

■_ さよなら PHP 6

や。本当に欠番になったりするのかわからんですが。

Future of PHP 6 - Johannes Schlüter

Future of PHP 6

Friday, March 12. 2010

Yesterday was a quite thrilling day for the PHP development team and led to some 
imprecise news articles so let's take a look at what happened: Over the last months 
many of the core contributors agreed that the current approach to bring Unicode into 
PHP's engine wasn't the right approach and a good thing would be to rethink it from 
the start. By a provocative move of one contributor the stalled situation got some 
more movement and Rasmus declared the current implementation to be discontinued to 
restart.

昨日はPHP開発チームにとってとてもスリリングな日でした。
and led to some imprecise news articles so let's take a look at what happened:
過去数ヶ月、core contributor たちはUnicode を PHP のエンジンに持ち込むというcurrent 
approach が正しい approach ではなく、good thing would be to rethink it from the start 
だということに同意していました。一人の contributor の provocative move によって停滞し
ていた状況が動きを見せ、そして Rasmus は現状の実装の disconiued to restart を宣言した
のでした

The past 過去

When the foundation of what should have become PHP 6 was created a decision was made 
to use UTF-16 as internal encoding for "everything" inside the engine. The 
choice for UTF-16 was made due to the fact that PHP 6 would use the ICU library which 
is focused on offering UTF-16 string functions. By using UTF-16 as default encoding 
we'd have to convert the script code and all data passed from or to the script 
(request data, database results, output, ...) from another encoding, usually UTF-8, to 
UTF-16 or back. The need for conversion doesn't only require CPU time and more memory 
(a UTF-16 string takes double memory of a UTF-8 string in many cases) but makes the 
implementation rather complex as we always have to figure out which encoding was the 
right one for a given situation. From the userspace point of view the implementation 
brought some backwards compatibility breaks which would require manual review of the 
code. These all are pains for a very small gain for many users where many would be 
happy about a tighter integration of some mbstring-like functionality. This all led to 
a situation for many contributors not willing to use "trunk" as their main 
development tree but either develop using the stable 5.2/5.3 trees or refuse to do 
development at all.

のちに PHP 6になるものが立ち上げられたときにエンジン内部の“すべて”に対する内部エンコ
ーディングとして UTF-16を使用する決定がなされました。このように UTF-16 を選択すること
は PHP 6 が UTF-16 文字列を扱う関数群をfocused on offering している ICU ライブラリを使
おうとしたことから決められました。デフォルトのエンコーディングとして UTF-16を使うこと
によって、わたしたちはスクリプトのコードとスクリプトに渡されたりスクリプトから渡される
すべてのデータ(request data, database results, output, ...) を、他のエンコーディング、
通常は UTF-8から UTF-16へ変換、あるいはその逆変換をしなければならなくなりました。変換
の必要性はCPUタイムとより多くのメモリーを要求する(UTF-16 での文字列は多くの場合におい
て UTF-8 文字列の倍のメモリーを消費します)ばかりでなく、与えられた状況においてエンコー
ディングが正しくはなんであったのかを常に把握していなければならないので実装をより複雑な
ものにしてしまいます。この実装はユーザの視点からすると、マニュアルでのコードのレビュー
が必要になるようななんらかの後方互換性の破壊に繋がるものです。mbstring のような機能の 
tighter integration では多くの人が happy になるのに対してこういった変更すべては多くの
ユーザーにとっては得る所は非常に少ない痛みとなります。これはまた多くのコントリビュータ
ーたちが自分たちの開発ツリーとして
 “trunk” を使わずに stable な 5.2/5.3 を使って開発するかあるいは development at all 
を拒絶するかのいずれかになるシチュエーションに繋がります


The present 現在

Yesterday the stagnation created by the situation has been resolved and it was decided 
that our trunk in svn will be based on 5.3 and we'll merge features from the old trunk 
and new features there so that 5.3 will be a true stable branch. The EOL for 5.2 has 
not yet been defined but I suggest you to really migrate over to 5.3, which usually 
can be done with very little work, as soon as possible.

昨日 stagnation created by the situation が解決し、そしてわたしたちの svn にある trunk 
が 5.3 をベースにしたものになってold trunk からの機能のマージと新しい機能のマージを行
うので5.3 が true stable branch になるという決定がなされました。5.2 の EOL (End of 
Life) はまだ決められていません。しかしわたしは非常にわずかの労力で済ませることが可能な
のでover to 5.3 に可能な限り早く (as soon as possible) migrate することを提案します。

The future 未来

Right now we're starting different discussions to see what kind of Unicode support we 
really want. Many contributors react positive on a proposed "string class" 
which wraps string operations in Unicode and binary forms without going deep in the 
engine. In my opinion such an approach might also be a way to solve some of the often 
criticized inconsistencies in PHP's string APIs without the need to break old code. 
(new code uses the new class, old code the old functions) But that idea is far from a 
proper proposal or even the implementation, current status is about refocusing the 
development and get the requirement and design discussions going. By that it's a bit 
early to decide whether the next version of PHP will be called PHP 5.4, PHP 6 or maybe 
even PHP 7.

正に今、わたしたちはわたしたちが本当に欲している Unicode サポートとはなんなのかを見つ
け出すためのディスカッションを始めました。多くの contirbutors が、エンジンの深いところ
に潜ることなくUnicode や binary forms での文字列操作を wrap する“文字列クラス”の提案
に対して positive な反応を返しています。わたしの意見では、そのようなアプローチは古いコ
ードを壊す必要なしに PHP の持っている文字列 API のofften criticized な一貫性の欠如 
(incosistencies) の一部を解決する手段でもある可能性があります
(new code uses the new class, old code the old functions
 - 新しいコードは新しいクラスを使い、古いコードは古い関数を使う)。
しかしそれは、proper な proposal や proper な実装からさえかけ離れた考えであり、current 
status は開発の refocusing とget the requirement and design discussions going について
なのです。そういったことから、PHP の次のバージョンが、PHP 5.4 と呼ばれるようになるのか
それとも PHP 6 とか PHP 7になったりするのかを決めるのはいささか気の早いことなのです。

PHP is alive and kicking!

Copyright ©1999-2010 Johannes Schlüter. All rights reserved.

■_ベストプラクティス

L'eclat des jours(2010-04-06)

ベストプラクティスってのはなんだろう? イディオムのようだがイディオムではなさそうだ
(たとえばRubyのイディオムならば、val ||= INIT_VALUEとかある)。もう少し考え方(設計方
針というか)が含まれているように見える。かといってデザインパターンではない。もっと遥か
に具体的だ。

プログラミングに関していえば、Perl のそれが最初かなあと思っていたのですが、 さらに前に出ていたものがあるみたいです。 Amazon.co.jp: ベストプラクティス  - 和書: 本

Perlベストプラクティス

■_ 本日の巡回から

2010年04月05日

■_

・つながらない
家に帰ってきて一息ついてからさてネット巡回を。 と思ったら PPPoE に失敗するじゃあありませんか。 んで、PC再起動→終端装置再起動→イーサケーブル交換… とやっても状況は変わらず。 あきらめてしばらく放っておいたらつながるようになりましたが。 なんだったんだろう。

■_ 本日の巡回から

■_

[急募] : JavaScript, PHP, C++ 入門書籍 執筆者&校正スタッフ募集 - Shizuku Blog ~ techbank.jp版~ なんですが、

[急募] : JavaScript, PHP, C++ 入門書籍 執筆者&校正スタッフ募集 - Shizuku Blog ~ techbank.jp版~

■応募条件

1.執筆者、校正スタッフ共、techbank.jp にID登録して頂けること。

2.書籍発売後、読者からの質問にお答え頂けること(techbank.jp掲示板を利用)

3.執筆者については、競合出版社様で同様の書籍を執筆していないこと

4.他言語の執筆者並び、校正スタッフ、監修スタッフ、出版社側の担当者と

  一切のトラブルを起こさず、監修者/出版社の依頼事項に従って素直に執筆作業を進めることができる方

  (著作権の権利主張、自己主張が激しい方はご遠慮ください)

5.担当する言語を使ったプログラミング経験の有無は問いませんが、基礎レベル以上の知識を有していること。

6.メールでの連絡が可能であること

7.日本国内在住されていること

条件の 4. てなに…(^^;

プログラミング入門書 かんたんシリーズ発刊のお知らせ - 戦艦ゆにっき F# は予定にないのかな。

■_ でるふぁい

なんで没落したのか。とか。 結構伸びてますが、最初のほうだけ。


Biggest Delphi nitpicks - Stack Overflow

What sort of minor annoyances do you run into using Delphi? I'm not looking for major 
issues such as "I want a 64-bit compiler." Just little things that can be 
easily worked around but still should have been implemented better so you don't have 
to work around them?

Marking this CW. I'm more interested in the answers than the points.

Definitely the buggy Error Insight!

I guess anybody who uses a D2005 or newer knows this bug... you are writing code that 
compiles well but Error Insight tells you it can't resolve a unit name or you use an 
undeclared identifier etc...

This bug still exists in Rad Studio 2010! Unbelievable (I am experiencing it right now)!

To the shame of Borland/Codegear/Embarcadero/ (funny thing, this bug survived every 
sale :D ) a third party developer managed to fix this bug... Who doesn't know Andreas 
Hausladen?

Edit: This seems to be #QC33546 (the first one I found, but I bet this has been 
reported more than once)

■_ カリー化と関数の部分適用

混同する人は洋の東西を問わず少なくないようです。

The Uncarved Blog: Partial Function Application is not Currying

Partial Function Application is not Currying
(関数の部分適用はカリー化とは違うもの)

These two related concepts are often confused. Until yesterday I thought they were the 
same thing myself.

関数の部分適用とカリー化という関連した二つのコンセプトはしばしば混同されています。
自分自身、昨日までこれら二つが同じものであると考えていたのです。


Often you will see in computer books and articles a pattern where a function is 
applied to some but not all of it's required arguments, resulting in a function of 
fewer arguments. In python, this looks like this (from PEP 309):

あなたはコンピューターの書籍や論文で何かに対して関数を適用するけれどもそのときに要求さ
れる引数全てを渡さないで呼び出し、結果がより引数の数の少ない関数であるといったパターン
を頻繁に見るでしょう。

In python, this looks like this (from PEP 309):
Python では、

def papply(fn, *cargs, **ckwargs):
    def call_fn(*fargs, **fkwargs):
        d = ckwargs.copy()
        d.update(fkwargs)
        return fn(*(cargs + fargs), **d)
    return call_fn

This is called "partial function application" - it returns a function which 
acts like the function you pass in but which takes fewer arguments, the others having 
been "bound in". The author of this code, however, had the (very common) 
misconception that this is currying, and called his function "curry" as a 
result. I shared this misconception for some time, and thought that currying and 
partial application were the same thing. In fact they are to certain extent opposites.

これは“関数の部分適用”と呼ばれています。この部分適用では、あなたが pass した関数のよ
うに振舞うけれどもより少ない引数しか受け取らずにいてそのほかのものは "bound 
in" されている関数を返します。しかしこのコードの auhtor はこれがカリー化であると
いう (非常に良くありがちな) 誤解をしてしまっていて、その結果として彼は自分の関数を “
curry” と呼んでしまったのです。かつてはわたしも同じこの誤解をしていて、カリー化と部分
適用が同じものであると考えていたのです。実際にはこれら二つは certain extent opposites 
なのです。


Where partial application takes a function and from it builds a function which takes 
fewer arguments, currying builds functions which take multiple arguments by 
composition of functions which each take a single argument. Thus we curry in python 
like this:

部分適用が関数を一つとってそこから引数の数がより少ない関数を組み立てる (build) のに対
して、カリー化では各々がただ一つの引数をとる関数を合成 (composition) することによって
複数の引数を取る関数を組み立てます。したがって、Python ではカリー化を次のように行いま
す:

def addN(n):
    return lambda x: x + n

def plus(a, b):
    addA=addN(a)
    return addA(b)


Now why would we ever want to do that? Well, in some pure functional languages this is 
exactly how functions with multiple arguments are built up. In ocaml, a function which 
takes two ints and returns a float is actually a function which takes an int and 
returns a function which takes an int and returns a float. In this world, partial 
application just happens without any extra code:


さて、なぜわたしたちはそういったことを行おうとしているのでしょうか?
一部の pure な関数型言語では複数の引数を取る関数がどのように組み立てられるかが正確にそ
のままになります。OCaml では、二つの int を引数に取って一つの float を返す関数は実際に
は int を一つ引数にとって、一つの int を引数にとって floatを返す関数を返すものです。
OCmal の世界では部分適用は any extra code なしに生じることなのです。

% rlwrap ocaml
    Objective Caml version 3.09.3

# let add a b=a+b;;
val add : int -> int -> int = <fun>

So the type of add is a function which takes an int and returns a function which takes 
an int and returns an int.

結局add の型は、一つの int を受け取り、int を一つ受け取って int を返す関数を返す関数です。


# let add2=add 2;;
val add2 : int -> int = <fun>

add is a curried function, so here we can partially apply by just calling with a 
single arg- it returns the function that takes the other arg and returns the result.

add はカリー化された関数ですから、ここでわたしたちは引数を一つだけ渡して呼び出すことで
部分適用できます。そしてその結果として別の引数を取り結果を返す関数が返ってきます。

# add2 34;;
- : int = 36

...and we can call add2 with a single argument as you would expect. Because ocaml 
curries add for us, the function has been partially applied. It's interesting to note 
that in ocaml if you label your function arguments, they can be partially applied in 
any order.

そして、あなたの期待するであろう通り add2 を引数一つで呼びだせるのです。OCaml がわたし
たちのために add をカリー化してくれているので、この関数は部分適用されました。OCmal で
はあなたが関数の引数にラベルをつけていると、その関数は任意の順序で部分適用を行えること
は書き残しておくべき興味深いことです。

■_ オーバーロードとオーバーライド

Yahoo!辞書 - override
[動](-rode, -rid・den) (他)

1 〈人・意見・決定などを〉くつがえす;…にまさる;…に優先する

	・	override a veto
(議会が)大統領の拒否権を乗り越える.

2 …の上に乗る, を乗り越える

	・	big waves overriding the beach
海岸にかぶさる大波.

3 …を踏みつぶす, 圧倒する.

4 〈馬を〉乗りつぶす.

5 《外科》〈折れた骨が〉〈他の骨に〉重なる.
Yahoo!辞書 - overload
動](他)

1 …に荷を積みすぎる, 負担[負荷]をかけすぎる

	・	be overloaded with heavy duties
重い責任を負わされる.

2 …に容量以上の電気器具をつなぐ;…に過大な電力消費を起こさせる.

まあそゆこと。

2010年04月04日

■_

POD版
出版社でPOD版売ってたりするんだから、この本をやってくれと何回かここで書いてたりしましたが 願いが通じたようです。 ふと検索してみたら、アマゾンさんにPOD版が登録されているのに気がつきました。 2010年3月開始のようなので、つい最近ですね。
数学パズル ものまね鳥をまねる―愉快なパズルと結合子論理の夢の鳥物語

■_ What makes a bad programming language bad?

Stackoverflowから。

What makes a bad programming language bad? - Stack Overflow

We have all seen things like the typing system of JavaScript (There is a funny post 
including a truth table somewhere around here). I consider this one of the main things 
that makes a programming language bad.

Other things that spring to mind:

    * Bad Error messages (Either obfuscated so you can't figure out whats wrong, not 
      existing or simply too long and red)
    * The language wasn't planned and just grew uncontrolled in all directions (PHP?)
    * The language encourages bad programm(er/ing) habits such as: Global variables 
      everywhere, bad variable names
    * Inconsistent naming conventions inside the language

I can't come up with any more at the moment and would be very happy to read what you 
think about this.

    * What shouldn't be missing in a language created to be as bad (from the perspectives of
      the programmer, the company that hires to programmer, the team leader and the customer)
      as possible?

(I ask this because I'm designing a bad, experimental language at the moment)


Bad languages are ones which fail to meet the following "good" guidelines.

(Inspired, in part, by Programming Languages: Principles and Practice, Kenneth C. Louden)

    * Regular
          o Orthogonality - language features don't interact poorly
          o Uniformity - similar features look similar, different features look different
          o Generality - constructs not too specific or too general.
    * Simple
    * Efficient
          o For someone reading the code (clear, no surprises)
          o For someone writing the code (concise, expressive)
          o For a machine reading the code (e.g. regular grammar)
          o For a machine executing the code
    * Safe
          o encourages correct code, discourages errors.
          o has ways of error-detection and handling.
    * Extensible
    * Standard is precise.
          o Platform-independent
          o So you can be sure whether your software will run on all implementations.
    * Plays well with others
          o Uses consistent standards and idioms with other languages.


Community.

We make or break it. Great communities make pain more bearable, and after a while 
every language is full of it.

Bad languages make extremely excessive use of brackets. Cough. Scheme. Cough.

Please avoid white space sensitivity, unless your whole lanugage is whitespace.
http://en.wikipedia.org/wiki/Whitespace_(programming_language)

:)
All programming languages are bad by default.

What makes them good is the product of their features, simlpicity, and their static 
guarantees. The trick is that when a language reaches the ceiling in any category, it 
begins negatively affecting the other categories:

Haskell. Very feature-loaded, very powerful compiler guarantees. A nightmare to learn.

Java. Fairly simple. Decent static guarantees. Not very fully featured. (And the core 
APIs never will be).

C++. Like Haskell, except trading some static guarantees for ease of use.

C. Very few features. Very weak static guarantees. But if your job is to flip bits, 
it's the easiest language to do this in.

Python. Features up the ass. Moderately simple. Very few static guarantees.

Lua. Moderately feature-ful, few static guarantees. But the simplest language you 
could ever use.
Haskell's lack of variables is there for a reason. Purely function programming 
languages do not have the concept of a named state. Just because we tend to think in 
one paradigm (because we're used to it) doesn't make other paradigms bad.

That variables begin with the $-sign in PHP has nothing to do with not supporting 
something for no reason. Identifiers that start without the $ are constants in PHP.
If you don't understand Haskell's take on variables, you don't understand Haskell. And 
the syntactical complaint with PHP, odd comment that JavaScript should be statically 
typed, and odd comment that OO and dynamic typing don't mix -- sounds to me like the 
real criticism isn't so much about what makes these languages bad, but what makes them 
different from C++/C#/Java/Blub/your favorite programming language.
Languages are designed for different needs. Saying sed is bad (for example) because it 
lacks variables and native support for things such as basic arithmetic operations that 
are found almost everywhere else is missing the point. It excels in many domains, and 
I take a guilty pleasure in applying it in places where it was never designed to go 
(because it's Turing complete), and that makes it awesome in my opinion. So what? Who 
needs addition?

@Juliet, that sounds like "If you don't understand PHP's take on $, you don't 
understand PHP" :-)

■_ 大規模規制?

なーんかム板の書き込み数が少ないなあと思ってたら


Rubyについて Part 39 
827 デフォルトの名無しさん [sage] 2010/04/04(日) 07:11:24 ID: Be:
    age/sageなんてどうでもいいじゃんと思うのは俺だけかいな? 

828 デフォルトの名無しさん [sage] 2010/04/04(日) 11:46:52 ID: Be:
    未だにsageろなんて言ってる煩い人は専ブラ使ってないのかな?
    sageろだageろだ言ってる2ch廃人の癖に 

829 デフォルトの名無しさん [sage] 2010/04/04(日) 11:49:28 ID: Be:
    そういう意味じゃないと思うが

    ageてると目立つのは確かだ 

830 デフォルトの名無しさん [sage] 2010/04/04(日) 11:51:30 ID: Be:
    変なのが来ちゃうからだろう

    しかし大規模規制中でム板もIPv6板も閑古鳥だお 

831 デフォルトの名無しさん [sage] 2010/04/04(日) 11:57:04 ID: Be:
    V6板は平常営業だろw
    先日のDDoSアタックの時には生存鯖としてちょっと賑わったがw 

832 デフォルトの名無しさん [sage] 2010/04/04(日) 15:38:51 ID: Be:
    iPadならRubyもサクサク動くのかなぁ。
    脱獄できるかが問題だがw 

833 デフォルトの名無しさん [sage] 2010/04/04(日) 17:03:40 ID: Be:
    > しかし大規模規制中でム板もIPv6板も閑古鳥だお

    いまくらいの方がちょうど良いです 

なるほど。

■_ 本日の巡回から

■_

んーむ、今ひとつ調子があがらん。

■_ こんだけキャラクター作っていったら大変だだろうなw


C++0x 9 

2 デフォルトの名無しさん [sage] 2010/03/27(土) 02:29:18 ID: Be:
    ○禿
    校長先生。
    不老不死も研究していて、350年後に問題点を全て解決した新パラダイムのC++をリリースする事になる。
    ただし頭髪は復活しない。 

3 デフォルトの名無しさん [sage] 2010/03/27(土) 02:33:23 ID: Be:
    C++学園の人々:0a年春の巻

    ○コンセプトさん(幽霊)
    かつての痕跡が校内から着々と消されつつあるのを草葉の影で眺めている。
    彼女の居た14.10番教室はオバケが出るという噂で閉鎖中。

    ○ラムダさん
    そろそろみんな制服の柄にも慣れたらしく、何も言われなくなってきた。
    それどころか、関数さんがラムダさんとお揃いの服を着たいと言いだして物議を醸している。

    ○右辺値参照さん
    ここへ来て急に彼女のせいで校則が変わることになったらしい。
    彼女自身はすっかり学園に馴染みつつあるが、聴講生へのイジメが酷くならないか心配している。

    ○拡張for文さん
    服がクリーニングされそうな様子は一向にない。
    屋上で「死にたい」と虚ろな目をして呟く様子がよく目撃されている。心配である。

    ○constexprさん
    従姉妹のconstさんと同じく地味な実力派。しかし意外と頭が悪く、単純な話しか理解できない。
    「りかーしぶ」の振り回し方次第ではカオスになりかねないので、周りの大人のサポートが大事である。
    なぜかstatic_assertさんとは仲が悪い。

    ○type_traitsさん
    最近ますます調子に乗って手が付けられなくなっている。
    この間は「私だけで良かったんや!コンセプトなんか最初からいらんかったんや!」と言い放ち
    static_assertさんにドロップキックを食らった。

    ○static_assertさん
    暴走するtype_traitsさんとテンプレ部に振り回されて気苦労が絶えない。
    姉貴はリリースコンパイルで逃げ出せるからいいよなーと愚痴りつつ仕事を真面目にこなす苦労人。 

4 デフォルトの名無しさん [sage] 2010/03/27(土) 02:33:55 ID: Be:
    ○initializer_listさん
    「ねえねえ配列さん、なんでコンストラクタさんと仲良くしないの?」「新入生が来たら仲良くするよ!」
    定番と化しつつあるこのやりとりの繰り返しで過剰な期待が勝手に高まりつつある。
    本人はあまり何も考えていない。

    ○テンプレート可変長引数さん
    テンプレ部にはすっかり馴染んだが、相変わらず一般生徒からは「あんた何の役に立つの?」
    と受けが悪い。最近はもう面倒臭いのでいちいち説明するのをやめた。

    ○autoさん
    苦楽を共にしたregisterさんはついにD組に落第してしまった。
    しかし一報を聞いたautoさんの反応は「ふーん、そう」という素っ気ないものだった。
    昔の彼女はもういない。

    ○decltypeさん
    一人前の型としての振る舞いも身につけ、いよいよ活躍が期待される所だが、
    服の違いで性格が変わる悪癖はまだ直っていない。
    いつか必ず問題を起こすと一部の先生からマークされている。

    ○ユーザー定義リテラルさん
    「まだいたのか」と先生に暴言を吐かれ、体育館の陰で泣いていた。

    ○nullptrさん
    誰もNULLさんと見分けが付かないので、既にこっそり通学していると噂されている。

    ○long longさん
    intさんに「ほら!あんたはこっちでしょ!」と間違えて上級生のクラスに連れて行かれた。

    ○Raw String Literalさん
    「お前全然Rawじゃねえじゃん」という状況は、トライグラフさんが譲る形で解決しつつある。
    ちなみにトライグラフさんはしぶとく落第を免れ続けてるらしい。 

5 デフォルトの名無しさん [sage] 2010/03/27(土) 02:34:55 ID: Be:
    ○unique_ptrさん
    コンテナ部とも仲良くできます!あの女とは違うんです!と自分を売り込んでいるが、
    みんなのauto_ptrさんのトラウマはなかなか払拭しきれず、苦戦している。

    ○shared_ptrさん
    ライブラリ部が誇るご存じ優等生中の優等生。早く来てくれ。

    ○unordered_map・unordered_setさん姉妹
    名字はhashが良かったが、大人の事情で付けられなかった。
    おかげでmap・setさん姉妹との違いをいちいち説明する羽目に。

    ○Regular expressionさん
    Perl学園ではバカにされていたが、ここでは大歓迎。
    満更ではないものの、学園の行く末に一抹の不安を抱いている。

    ○Atomic operationさん
    彼女と話していて業を煮やしたとある生徒が「こまけえこたぁいいんだよ!」と叫んで飛び出し
    10分後に未定義動作にボコボコにされて帰ってきた。

    ○threadさん
    最大のライバルであるpthreadさんを蹴落とすべく日々努力しているが、
    親友のラムダさんがpthreadさんとも親しくなりそうで焦っている。

    ○System error supportさん
    ユーザー定義リテラルさんとよく一緒に弁当を食べている。

    ○progress_displayたん
    System error supportさん達と一緒に弁当を食べようとしたら断られた。 

6 デフォルトの名無しさん [sage] 2010/03/27(土) 03:43:10 ID: Be:
    ○attributeさん
    他の学校に、かならず一人はいる娘なので、学校側としても、しかたなく、入校させた。
    服のセンスが、lambdaさんに負けず劣らず、相当悪い。
    lambdaさんと、かぶっている帽子が、見る角度によっては、似ていることがあり、少々問題になっている。
    lambdaさんとの区別は、帽子以外で判断すべきだと叫ばれている。

    ○noexceptちゃん
    入学試験の選考の最後になって、急に合格した赤ちゃん。
    豪華にも、独自の制服を作ってもらった。

    ○Inheriting Constructorさん
    地味にできる娘。何で今までいなかったのか、不思議に思われている。

    ○__VA_ARGS__さん
    クラス分けで、プリプロセッサ組に通うことになった娘。
    プリプロセッサ組は、落ちこぼれだとも、最強だともいわれている、変わったクラス。
    その外見はあまりにもブサイクだが、密かにファンもいるらしい。


    ○exportさん
    進級できなかった。

    ○Exception specificationさん
    進級できなかったが、彼女の産んだ、まだ一歳にもならない赤ちゃんが、いきなり入校してきた。 

7 デフォルトの名無しさん [sage] 2010/03/27(土) 11:15:21 ID: Be:
    C++0F(2015年)までにリリース出来るんでしょうか? 

8 デフォルトの名無しさん [sage] 2010/03/27(土) 11:15:47 ID: Be:
    なんか知らんが乙! 


9 デフォルトの名無しさん [sage] 2010/03/27(土) 12:15:02  ID: Be:
    >>7
    36(ry 

10 デフォルトの名無しさん [sage] 2010/03/27(土) 12:51:43 ID: Be:
    ・progress_displayたん 

11 デフォルトの名無しさん [] 2010/03/27(土) 12:57:11 ID: Be:
    毎度毎度乙wwww 

12 デフォルトの名無しさん [] 2010/03/27(土) 13:22:54 ID: Be:
    ・type_indexさん
    type_info君と仲が良いらしい。
    噂では、いくとこまでいったとかいってないとか。
    ただし、開校前のクラス分けで離ればなれになってしまった。

    ・System error supportさん
    いじめられて転校してきたらしい。
    たぶん、どの学校でも相手にされない子。
    ほとんどの学校には、学校独自の、もっとマシな子がいるし。

    ・Tupleさん
    博愛平等主義者。ほとんどのクラスメートと仲が良い。

    ・Binder姉妹(bind1st,bind2nd)
    落第。一応、まだ学校にはいる。

    ・Function template bindさんと、Polymorphic function wrapperさん
    二人とも、とても頭が良い。
    なんでも、「ぶーすと」という一流の進学校から転校してきたらしい。
    あまりに成績が良かったために偏差値を押し上げて、Binder姉妹を落第させる原因をつくった。

    ・Time utilitieさん
    2038年問題も3000年問題も大丈夫と豪語。

    ・Compile-time rational arithmetic君
    Time utilitieさんと仲が良いらしい。 

2010年04月03日

■_

マエストロ
なんか面白そうなものを見つけたのですが はじめの1巻:「魏志 文帝紀 建安マエストロ!」 新解釈の三国志 若き日の曹丕を描く - MANTANWEB(まんたんウェブ) ふと気になって調べてみた。 マエストロの意味 - 国語辞典 - goo辞書 音楽の)巨匠。 音楽限定なんでしょうか?



アモーレイタリア語辞書
    [形][マエストロ]

    熟練した、熟達した、巧妙な、主要な、最重要な


    [男][マエストロ][英:master,teacher]

    男性教師、(音楽の)マエストロ、指揮者、作曲家、監督、師匠、親方、名人、
    手本、師範

でもないのかな。

なぜか
ExcelでR自由自在
を買いにいったはずなのに、古本屋で コンパイラ設計技法―理論と実践
Thomas Pittman
481018546X
を見つけてそっちを買ってしまったという。 両方買うほどお金がががが。

海軍反省会
ようやく順番が回ってきて、図書館で借りた。

■_ printf

フルスペック(?)のを作ろうと思ったらまあ大変だろうなあ。 にしたって、glibc がだめでも FreeBSDあたりの libc見ればいいような気もするけど どうなんだろう?


C言語なら俺に聞け(入門編)Part 62 
786 デフォルトの名無しさん [sage] 2010/04/03(土) 02:49:44 ID: Be:
    やぁ、いまprintfの勉強をかねて、printfを自前でフルスクラッチで(stdarg.h以外には依存せずに)書いてる最中なのだけど
    細かい部分の挙動や、普段使わないような記号の仕組み(たとえばaqや*)などの具体的な仕様が分からなくて困ってるんだ。

    printfに関する一般的な仕様(posixなど?)を具体的な使用例ソースと共にまとめてあるページって、どこかに無いかな?
    (英語は読めないので、できれば日本語のページが望ましい)

787 デフォルトの名無しさん [sage] 2010/04/03(土) 10:43:35 ID: Be:
    >>786
    manpage printf でググるとか 

788 デフォルトの名無しさん [sage] 2010/04/03(土) 15:21:16 ID: Be:
    >>786
    glibc の printf() のソースを見て自分で仕様書を書く。


    。。。なんてことはしなくても
    JIS X 3010:2003 でぐぐって
    JISC のページの PDF 見れば。
    7.19.6.1 fprintf 関数。

789 デフォルトの名無しさん [sage] 2010/04/03(土) 15:42:11 ID: Be:
    言語、げんげんご、言語! 

790 デフォルトの名無しさん [sage] 2010/04/03(土) 17:33:11 ID: Be:
    >>787
    さっそくググってみたよ。
    わおー、とてもクールなページでprintfのアウトラインをつかめた気がしたよ。ありがとう : )

    >>788
    やっほー、C99の仕様書らしきPDFが出てきやがったぜ。こいつはクールなPDFだね。
    まだ読んでないけど、さっそくダウンロードしてみるよ。
    それにしても書籍で買うと140ドル(!)もするのかい? わおー、やつら俺らの白髪を増やす気かい!

    >>glibc の printf() のソースを見て自分で仕様書を書く。
    glibcの挙動をマネるというアイディアには賛成さ。ボクにとってGNUのlibcはスタンダードlibcと言える存在だからね。
    だけど、ソースを直接閲覧するというアイディアはノーグッド。なぜならglibcのソースはLGPLだからね。
    LGPLコードから、たった一行コピペするだけで、そのコードはもぅ法的観点からGPLコード以外とはマージ不可能になってしまうのだろう?
    恐ろしくてGPLのコードなんて見る気にならないよ

    それにもともと、コーディングに関しては他を参考にせずに、自力でprintfをフルスクラッチするのが目的だしね : )

791 デフォルトの名無しさん [sage] 2010/04/03(土) 18:02:28 ID: Be:
    テンパで度の強いメガネの白人みてえな文章だな
    ハイスクールで背中に蹴ってくださいって紙張られてみんなにけられるタイプ
    好きなおさななじみの女の子の前でしどろもどろ
    声出して自分に話しかけるタイプ
    「いいか、落ち着くんだ、そして言うんだ、デートしてくださいって」
    「ああ、もうなんてお前は意気地なしなんだ、彼女行っちゃったじゃないか」 

792 デフォルトの名無しさん [sage] 2010/04/03(土) 18:21:46 ID: Be:
    >>790
    コピペしなきゃいいじゃん。

    無理やり違う実装で書くのも勉強になるぜw

■_ プログラマーを管理するには

各項目の説明は例によって以下略

How to Manage Programmers | Rants and Apps

How to Manage Programmers

Calendar March 28, 2010 | Posted by Tuomas Pelkonen

This is my view on how programmers (or obnoxious programmers like me) should be 
managed. Almost all of these things are based on my personal experience, especially 
learning from the mistakes made by management.

Everybody knows that programmers are probably the hardest people to manage, because 
the way they work is so different from the norm. The things that are important to them 
are not usually important to business people and vice versa. Programmers are also 
delicate little creatures that remember every single mistake managers make.

I have seen numerous cases of mismanagement that it really raises the question whose 
fault is it? I would say that the finger can almost always be pointed at the upper 
management and in some organizations at the HR. It's their job to pick the best 
managers to manage programmers.

If you are making management decisions in a software company, you have to know your 
personnel. Many companies are managed by sales and business people, and they have no 
idea how to manage programmers, because they don't know what it's like to be a 
programmer.

Usually the best companies, for programmers to work in, were founded by programmers 
and most of the upper management are former programmers themselves. If your upper 
management consists of business people, I will bet that they will drive most of the 
programmer crazy with their stupid decisions.

I do realize that the most important goal of every single company is to make money, 
but at what cost? One buzzword in today's economical situations is cost cutting. 
Companies try to save a little money here and there, but they might not realize that 
cost cutting can actually do more harm than good. Make enough stupid cost cutting 
decisions, and your best programmers will go work for a company that does not make 
stupid decisions to save a few cents here and there.

If you are any kind of manager in a software company, follow these simple instructions 
and you will earn programmers' respect.

Read Peopleware, again, and again
Don't treat programmers like second-class citizens
プログラマーを二等市民として扱ってはいけない

Don't treat programmers like they are all the same
プログラマーを全員同じものとして扱ってはいけない

Don't try to impress them with your business bullshit
あなたの仕事が bullshit な代物だと彼らに印象付けてはいけない

Don't waste their time
彼ら(プログラマーたち)の時間を浪費してはいけない

Don't make their work any harder
彼らによりハードな仕事をさせるようにしてはいけない

Don't treat them like numbers in a spreadsheet
彼らをスプレッドシート上の数値のように扱ってはいけない

Don't ignore their opinions
彼らの意見を無視してはいけない

Don't ignore their efforts
彼らの努力を無視してはいけない

Don't ignore their requests
彼らの成果を無視してはいけない

Don't ever lie to them
彼らに対して嘘をついてはいけない

Don't try to fool them with your limited technical knowledge
あなたの限られた技術的知識でもって彼らを小ばかにしようとしてはいけない

Copyright © 2009 Rants and Apps | All Rights Reserved

Eximius Theme by dkszone.net

■_

こっちもw

Coding Horror: Top 25 Most Dangerous Programming Mistakes
I <3 Steve McConnell*
Coding Horror
programming and human factors
by Jeff Atwood
Enter your search terms Submit search form
Web Coding Horror

Jan 12, 2009

Top 25 Most Dangerous Programming Mistakes

I don't usually do news and current events here, but I'm making an exception for the 
CWE/SANS Top 25 Most Dangerous Programming Errors list. This one is important, and 
deserves a wide audience, so I'm repeating it here -- along with a brief hand-edited 
summary of each error.

If you work on software in any capacity, at least skim this list. I encourage you to 
click through for greater detail on anything you're not familiar with, or that piques 
your interest.
   1. Improper Input Validation
      不適切な入力検査

   2. Improper Encoding or Escaping of Output
      出力の不適切なエンコーディングや不適切なエスケープ

   3. Failure to Preserve SQL Query Structure (aka 'SQL Injection')
      SQL Query 構造の保護の失敗 (“SQLインジェクション”)

   4. Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
      Web ページ構造の保護の失敗 (“クロスサイトスクリプティング”

   5. Failure to Preserve OS Command Structure (aka 'OS Command Injection')

   6. Cleartext Transmission of Sensitive Information

   7. Cross-Site Request Forgery (CSRF)

   8. Race Condition

   9. Error Message Information Leak
      エラーメッセージ情報のリーク

  10. Failure to Constrain Operations within the Bounds of a Memory Buffer

  11. External Control of Critical State Data

  12. External Control of File Name or Path

  13. Untrusted Search Path
      信頼できない検索パス

  14. Failure to Control Generation of Code (aka 'Code Injection')
      

  15. Download of Code Without Integrity Check

  16. Improper Resource Shutdown or Release
      リソースの適切でないシャットダウンもしくはリリース

  17. Improper Initialization
      適切でない初期化

  18. Incorrect Calculation

  19. Improper Access Control (Authorization)
      適切でないアクセス制御 (オーサライゼーション)

  20. Use of a Broken or Risky Cryptographic Algorithm
      壊れている、もしくはリスクを抱えている暗号化アルゴリズムの使用

  21. Hard-Coded Password
      ハードコードされたパスワード

  22. Insecure Permission Assignment for Critical Resource
      クリティカルなリソースに対するセキュアでない許可の付与

  23. Use of Insufficiently Random Values
      性能の足りないな乱数値の仕様

  24. Execution with Unnecessary Privileges
      不必要な権限を伴った実行

  25. Client-Side Enforcement of Server-Side Security
      サーバーサイドのセキュリティのクライアントサイドでの強制

Of course there's nothing truly new here; I essentially went over the same basic list 
in Sins of Software Security almost two years ago. The only difference is the relative 
priorities, as web applications start to dominate mainstream computing.

This list of software security mistakes serves the same purpose as McConnell's list of 
classic development mistakes: to raise awareness. A surprisingly large part of success 
is recognizing the most common mistakes and failure modes. So you can -- at least in 
theory -- realize when your project is slipping into one of them. Ignorance is the 
biggest software project killer of them all.

Heck, even if you are aware of these security mistakes, you might end up committing 
them anyway. I know I have.

Have you?

■_

ぼつ。

■_

ボクの iPad アプリ:iPad 懐疑論への反論 « maclalala2 ボクの iPad アプリ:iPad 懐疑論への反論 « maclalala2

iPad については(iPhoneもそうだったけど)、貶す気はないけど、 必要以上に持ち上げる気にもならない。rest of us のため、というのはその通りで、 その意味ではすばらしいものなのかもしれないけど アラン・ケイが発表したダイナブックそのものだとかいうのは いくらなんでもという気がする。

■_ 正しい資質

機動警察パトレイバーの漫画版は、 連載の最初が Light staff で、最後が Right stuff だったりするんですよね。



ライトスタッフ: つらつらぐさ
映画「ザ・ライトスタッフ」(ライトスタッフとはなっていたけど)を見た。長かった。でも、
その長さをあまり感じなかったというのもある。数年前に NHK で放送されたドラマの「宇宙へ」
は、米ソのロケット開発者を軸とした話だったけれど、こちらはアメリカの最初の宇宙飛行士と
なった人々の話。

(略)

映画を観たあとでこれなど(笑)
The Right Stuff (1983 Film) / North And South (1985 Television Mini-Series) [2 on 1]

■_ 本日の巡回から

2010年04月02日

■_

Dropbox のなんかのリンク貼っとくと、わたしの容量も増えるんだろうか。 まあ2ギガバイトでも半分も使ってないわけなんですが。

明日(4/3)あたりウルトラジャンプの3月19日発売号が再販(というの?)されるらしいんだけど さて。 BASTARD!だけ読めりゃあいいんだけどねえ。 とある漫画喫茶いったら、あるはずのウルジャン最新号の場所に別の雑誌が入ってた(笑)

http://stackoverflow.com/questions/2556954/what-makes-a-bad-programming-language-bad
http://stackoverflow.com/questions/644167/what-is-a-practical-real-world-example-of-the-linked-list
http://stackoverflow.com/questions/2564200/why-might-stable-sort-be-affecting-my-hashtable-values

■_

Programming Related Songs - Stack Overflow
http://stackoverflow.com/questions/354686/programming-related-songs

http://stackoverflow.com/questions/3947/music-to-listen-to-while-coding

http://www.vimeo.com/752979
http://www.weirdal.com/
http://www.jonathancoulton.com/2006/04/14/thing-a-week-29-code-monkey/
http://www.jonathancoulton.com/
http://www.catonmat.net/blog/musical-geek-friday-god-wrote-in-lisp-eternal-flame/
http://www.conchords.co.nz/
http://www.youtube.com/watch?v=WGoi1MSGu64
http://www.youtube.com/watch?v=iWVAiXNnauM
http://www.youtube.com/watch?v=YYvOGPMLVDo
http://uk.youtube.com/watch?v=a0qMe7Z3EYg
http://www.youtube.com/watch?v=Ky-JTAPhmUo
http://www.mcplusplus.com/
http://www.code.linux.fi/SOUNDTRACK/BALLAD/ballad.html
http://www.youtube.com/watch?v=cXkxixWZU3A
http://www.catonmat.net/blog/musical-geek-friday-kill-dash-nine/
http://www.cs.bgu.ac.il/~omri/Humor/write_in_c.html
http://www.musik-base.de/Songtexte/Bad-Religion/i-love-my-computer-106003.html
http://www.youtube.com/watch?v=rBK3zME1aqk
http://www.youtube.com/watch?v=FdYKTek5N1Q
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewAlbum?id=213625435&s=143443
http://loosebrucekerr.libsyn.com/index.php?post_id=411197
http://www.youtube.com/watch?v=YOnJMGRV0yU
http://uk.youtube.com/watch?v=9sJUDx7iEJw
http://www.youtube.com/watch?v=oWxtBVT9C_s
http://linuxbasement.com/content/living-with-a-geek-live
http://www.youtube.com/watch?v=0-MONIvP6kI
http://www.ytcracker.com/nes/
http://uk.youtube.com/watch?v=pzDMXXbP02Q

http://stackoverflow.com/questions/354686?tab=votes&page=2#tab-top

write in C ~♪

■_

訳してみたはいいが、なんかビミョー

Caffeine Coma: Relax. You can (mostly) stop using Interfaces in Java now.
http://garmhold.blogspot.com/2010/03/relax-you-can-mostly-stop-using.html

Saturday, March 6, 2010

Relax. You can (mostly) stop using Interfaces in Java now. Detractors of Java are 
correct to point out a rather unfortunate trend in the Java world- there is a common 
tendency for developers to turn every non-trivial class into an Interface, and then 
create an "Impl" that actually does the work.  As a result, your codebase becomes 
littered with lots of superfluous interfaces that have only a single implementation.

力を抜いて。現在では、あなたは Java でインターフェースを使うのを(ほぼ)止められます。
Java の Detractors は、Java ワールドにおける不幸なトレンドというよりはむしろ correct
to point です。non-trivial なクラスをインターフェースに変更しておき、そのあとで実際に
働く "Impl" を作るという開発者向けの common tendency が存在しています。その結果として、
あなたのコードベースは過剰なまでの数のただ一つだけの実装を持つインターフェースで溢れか
えることになります。


Why do we do this? (なぜわたしたちはそうするのでしょうか?)

Part of it is simple architecture astronautics, but there is actually a very 
legitimate use case for creating interfaces even when there is only a single 
implementation- it allows you to mock out your objects so that other classes can be 
unit tested easily. This is really important in TDD, and so I've come to accept the 
fact that there will always be some extra "interface noise" in the codebase in order 
to support a good test infrastructure.  C'est la vie, right?

その一部分は単純なアーキテクチャの astronautics ですがあなたのオブジェクトの mock out 
を可能にして他のクラスがユニットテストを容易にできるようにするためのただひとつの実装し
か存在しない場合であっても、インターフェースを作ることが非常に正当なユースケースが存在
します。これは TDD においてはとても大切なことで、であるからわたしは良いテストのインフ
ラをサポートするためのコードベースの中にある “インターフェースのノイズ”を受け入れる
ようになったのです。これが人生というものです (C'est la vie)。そうでしょう?

Along comes JMock 2.5, with its ClassImposterizer, backed by cglib.

    "The ClassImposteriser creates mock instances without calling the constructor of the
     mocked class. So classes with constructors that have arguments or call overideable 
     methods of the object can be safely mocked."

     ClassImposteriser は mocked class のコンストラクターの呼び出しをすることなしに mock 
     のインスタンスを生成します。そのため、引数をとるコンストラクターを持ったクラスやオブ
     ジェクトによるオーバーライド可能なメソッドの呼び出しも安全に mock 可能です。

I should point out that this isn't exactly new- JMock 2.5 came out in 2008, so I'm a 
little late to the game here.  But I haven't seen much written about this.  It's a 
really huge change.  It means that you can do things like:

わたしはこれが exactly に new- JMock 2.5 came out in 2008 ではないので
so I'm a little late to the game here であることを指摘しておくべきでしょう。
しかしこれについてかかかれているのをそれほど見ていません。
これはとても大きな変更で、次の例のように書けるようになるのです:


final java.awt.Graphics2D graphics = mockery.mock(java.awt.Graphics2D.class);
    mockery.checking(new Expectations() {{
    one(graphics).getBackground();
    will(returnValue(java.awt.Color.BLUE));
}});

Of course this is great for testing code that uses libraries that weren't designed 
with mocking in mind, but even better than that- you can use it against your own code, 
and save yourself from having to create interfaces.

もちろんこれは mocking を考慮した設計がされていないライブラリを使用しているコードのテ
ストに対しては great ですが、
but even better than that- you can use it against your own code, 
そして、インターフェースを作らなければならないことから自分を save します。


This means you can go ahead and create your concrete MyComplicatedDAO, without having 
to create MyComplicatedDAOIFace, MyComplicatedDAOImpl, MyComplicatedDAODummy, etc.  
When you need to test code that uses it, you just do:

これはつまり、MyComplicatedDAOIFace, MyComplicatedDAOImpl, MyComplicatedDAODummy
などといったものを生成しなくとも、具体的な MyComplicatedDAO を生成できるということ
です。このクラスを使っているコードをテストする必要があるときには
単に次のようにします:


final MyComplicatedDAO dao = mockery.mock(MyComplicatedDAO.class);
    mockery.checking(new Expectations() {{
    one(dao).getLoggedInUsername();
    will(returnValue("user1"));
}});

It's really hard to overstate the significance of this. It's changed the way I write 
and test code. It's very refreshing to be able to start out with a concrete class and 
write code that does stuff, rather than code that merely talks about doing stuff.

このことの重要性はどれほど強調しても足りません。これはわたしのコードの書き方とテストの
やり方を一変させました。この方法では具象クラス (concrete class) から始めて、
merely talks about doing stuff なコードではなく
does stuff なコードを記述するのを可能にするのを非常に促進するのです。

#significance 重大性
#overstate 大げさに
#refreshing 元気づける
# doing stuff と does stuff って?

Of course there are still very legitimate reasons for using interfaces. If you're 
designing a library, using interfaces makes life easier on your users. Interfaces are 
also a great way to decouple code, to remove circular dependencies, and to support 
callbacks.  All of these are legitimate and appropriate uses, and you shouldn't 
abandon them.

もちろん、インターフェースを使うことの非常に正当な理由もまだ残っています。もしあなたが
ライブラリを設計するのなら、インターフェースを使ってそのライブラリのユーザーの人生を楽
にしましょう (life easier on your users)。 インターフェースはまた、コードの decouple 
や 循環している依存関係 (circular dependencies) の除去、コールバックのサポートなどのた
めの優れたやり方 (great way)  なのです。これらはすべて正当かつ適切な使い方 (legitimate 
and appropriate uses)であり、あなたはそれをあきらめるべきではありません。


But use interfaces with reason, and not by reflex.

Posted by George Armhold at 5:56 PM

■_ 定数

string constant とかで、「定数」ってつくのなんか変だよね~ とかゆってみる。


スレ立てるまでもない質問はここで 105匹目 
335 デフォルトの名無しさん [] 2010/04/02(金) 01:02:25 ID: Be:
    3.14から始まる円周率は不変で定数というのはわかるのですが、
    富士山の高さ3776mが定数っていうのは納得できません。
    なんで富士山の高さは定数として扱われるのでしょう?
    山の高さというのは地殻変動、隕石の衝突、噴火などさまざまな要因で、
    時代とともに変化するものだと思うので、変数なのでは?と思うのですが、
    定数と変数の違いについて聞いたとき、定数の例で富士山の高さを持ち出されて、
    それに大して上記のような疑問を持ち突っ込んだのですが、
    うまく説明できないけどそういうもんなんだと、はぐらかされてしまいました。
    なぜ富士山の高さは定数なのでしょう?どなたか説明していただけませんでしょうか? 

336 デフォルトの名無しさん [sage] 2010/04/02(金) 01:12:42 ID: Be:
    よくわからんが、その話は富士山の話が本題で富士山のプログラムだったのだろうか?
    だったら変数だな。 

337 デフォルトの名無しさん [sage] 2010/04/02(金) 01:24:56 ID: Be:
    >>335
    3776以外の数値を使わないのなら定数にすればいい。 

338 デフォルトの名無しさん [sage] 2010/04/02(金) 01:27:43 ID: Be:
    富士山にこだわりすぎ。
    プログラムは3776という数値に対して処理をし、プログラム中で3776の数値が頻出するため
    定数として振舞う識別子を3776に束縛しているだけ。 

339 335 [sage] 2010/04/02(金) 01:38:01 ID: Be:
    レスしてくれた方ありがとうございます。
    頻度と束縛がキーワードですね。
    正直まだ理解できませんがもう少し考えてみます。

    >例えば人の名前や場所の名前などは変化するものではありません。そんな使い方の場合に定数を定義しておくようにします。
    こんなのを例にしてるとこもあり、
    名前は結婚したら変わるし、場所も合併で変わるだろうなぁなんて思ったり。

    ようするに定数にしてたものでも変更(変更がそもそも許されるのかはわかりませんが)があったら、
    ソースを開いて後から定数値を変更する分にはいいってことなんですかね? 

340 デフォルトの名無しさん [sage] 2010/04/02(金) 01:38:02 ID: Be:
    >>333
    ログがないからバグ修正できませんってのは保守できていないから契約違反で金払わなくていいよ
    上客っていうよりもいいようにカモられてる
    立場を明確にしたほうがいい。開発者が怒るようだったら引継ぎ資料作らせて他の会社に委託。 

341 デフォルトの名無しさん [sage] 2010/04/02(金) 01:40:22 ID: Be:
    >>339
    あなたにとって富士山の標高は何メートルですか?
    俺は3776メートル。低くなってるらしいけど、やっぱり3776メートルだと思っている。 

342 デフォルトの名無しさん [sage] 2010/04/02(金) 01:42:38 ID: Be:
    SI系だと1メートルは富士山標高の1/3776に規定されてるらしいよ。
    つまり富士山は常に3776メートル 

343 デフォルトの名無しさん [sage] 2010/04/02(金) 01:54:29 ID: Be:
    それはさすがにないw
    マジレスすると光が1秒で進む距離の約3億分の1(細かい数字忘れた)が1メートルと規定な 

344 デフォルトの名無しさん [sage] 2010/04/02(金) 02:10:10 ID: Be:
    >>339
    初めてプログラムしてんだよね?
    ネタじゃないレスしてやるぜ。
    プログラム実行中に変更の疑いが一切ないデータが定数だ。
    プログラム内と現実をごっちゃにするんじゃねぇ。 

345 335 [sage] 2010/04/02(金) 02:15:14 ID: Be:
    >プログラム実行中に変更の疑いが一切ないデータが定数だ。
    なるほど。
    何か分かった気がします。
    実行中でないときは変更可能なわけですね。(設定の変更などでソースをいじるみたいな感じで)
    それでプログラム中では定数は呼ばれるだけ専門みたいな感じになるわけですね。
    シンプルにa = bという処理がない限り常に定数にしとけばいいということでしょうか? 

346 デフォルトの名無しさん [sage] 2010/04/02(金) 02:24:36 ID: Be:
    いいか。全部自己判断です。
    誰かの名前が変わったときに、名前変更も仕様に加えるかも自己判断。
    富士山の標高変化をプログラムに対応させるかも自己判断。
    何を定数にするかも自己判断。
    そりゃ富士山の観察経過プログラムなら間違いなく変数だよあんた。

    だいたい、それ以前に定数とかどうでもいい。
    変数じゃないから少しだけ読みやすくて少しだけ速いだけ。 

347 >>335 [sage] 2010/04/02(金) 02:25:37 ID: Be:
    >シンプルにa = bという処理がない限り常に定数にしとけばいいということでしょうか?
    すみません。最初の宣言では必ず書きますね。
    2回以上a = 値が出てくることがないという意味でお願いします。

    a = null;
    b = true;
    if (b) {
     a = 1;
    } else {
     a = 0;
    }

    これだけの処理ならbは定数でもいいってことですよね? 

348 デフォルトの名無しさん [sage] 2010/04/02(金) 02:27:52 ID: Be:
    >>345
    全部変数でいいよ。とりあえずそれで作ってけ 

349 335 [sage] 2010/04/02(金) 02:32:14 ID: Be:
    >>346
    まだ自己判断できるようなレベルじゃないので・・・
    せめて何かわかりやすい基準があればいいのですが、
    どこも抽象的でいまいち理解できなくて・・・

    >>348
    わかりました。そのうちわかってくると信じてとりあえず変数でやっていきます。 

350 デフォルトの名無しさん [sage] 2010/04/02(金) 02:32:42 ID: Be:
    これ以上質問されると言語教室になっちまう。
    3時間1万円くらいなら教えるけど。

    そんなどーでもいいこと気にしてないで言語を一通り覚えて、
    なんか実用的なソフトを一つ開発すれば、データの扱いなんたるかだいたいわかるよ。
    今の段階じゃ無理。 

351 デフォルトの名無しさん [sage] 2010/04/02(金) 02:43:11 ID: Be:
    結局まともな説明できるやつはいないみたいだな
    この手の話題はまともに説明できるやつは少ない
    長くやってるとなんだかわからないけどそうなった
    だからそうなんだっていう感じになってしまうから無理もない
    DBの正規化にしてもちゃんと説明できるやつは少ないけど
    特に考えてないけどなんだかまともな正規形になってるなんていうのはよくあること
    デザパタなんかも特に習ったわけではないが
    知らないうちになんかのデザパタを使って問題が解決されてるみたいな感じ
    まぁ何がいいたいかというと経験だな
    はじめたころは定数変数とか細かいことも考えたのかもしれないが
    そのときの感覚は覚えてないし身についたらそういうもんなんだって感じ
    言語を他人にまともに教えられる人間って言語開発者ぐらいしかいないと思う 

352 デフォルトの名無しさん [sage] 2010/04/02(金) 10:20:27 ID: Be:
    プログラミングで言う定数とは値が変わらないもの。0も1も2も定数。
    値が変わらないとは、i = 1, i = 2のような変数では無いということ。
    物理学的・数学的な定数や概念的な定数とは違う。 

■_ 代入と束縛

= と := で区別ってのももうひとつ違いが目立たないような気がしないでもないけど。

Journal of masak (6289)

Plain old assignment, and freaky binding
[ #40246 ]

What happens when we do assignment? When we do $a = 42;, for example.

わたしたちが代入を行ったとき、たとえば $a = 42 を行ったときに起きていることとはなんで
しょうか?


Intuitively, in almost every language, what happens is at least something like this: the 
symbol $a becomes associated with the value 42. In pseudo instruction code, it might look 
something like this:

直感的には、ほぼすべての言語でシンボル $a が値42に結び付けられるといった類のことが行わ
れています。疑似命令コードでは次のようになるでしょう:

my $a; $a = 42;
    $0 = 42
    store '$a', $0

(Feel free to read $0 et al. as "some register in the VM". And to fantasize 
liberally about the opcodes.)

#fantasize 空想する、想像する

From this model, we expect variables to be independent, even when we've assigned from one 
to the other. So in this piece of code...

このモデルでは、ある変数から別の変数への代入を行ったときにもわたしたちは変数が独立であ
ることを期待していてですから次のようなコードでは…

my $a = 42; my $b = $a; $a = 5;
    $0 = 42
    store '$a', $0
    $1 = fetch '$a'
    store '$b', $1
    $2 = 5
    store '$a', $2

...we expect $b to still be associated with the value 42, and not to have suffered some 
freaky action-at-a-distance which causes it to be changed when $a is assigned to 5.

わたしたちは $b が 42 に結び付けられたままであることと、$a に 5 が代入されたときに $b 
に対する変更を引き起こす some freaky action-at-a-distance に耐える必要のないことを期待
しています。


"Well, obviously $b won't do that", you interject. "It can't, if we believe in 
the model in which there are only symbols and their associated values. No freaky 
action-at-a-distance can occur." And that's right, as far as that goes.

“確かに $b が期待通りの動作であることは明らかで、”you interject. 
"シンボルとそれに結び付けられた値だけが存在しているというモデルを使っていると信じ
るならば、そんなことはできませんし、奇妙な action-at-a-distance は起こりえません。" 
#interject 言葉をさしはさむ
And that's right, as far as that goes.


But it turns out that Perl 6 allows a middle abstraction layer between symbols and values. 
The entities occupying this middle layer are usually referred to as "containers", but 
that's a terribly overloaded term. I'll call them "buckets" in this post, hoping I 
won't throw some hash expert into a fit. 哈哈

しかし、Perl 6 ではシンボルと値の間に存在する中間抽象レイヤー (middle abstraction 
layer) が設けられたことが明らかになりました。この中間レイヤー (middle layer) に存在し
ているエンティティは通常は“コンテナー” (containers)として参照されますがこれはあまり
にも多くの意味を持つ用語なのでこのポストでは“バケツ”
(buckets) と呼ぶことにします。
hoping I won't throw some hash expert into a fit. 哈哈


To explain the behavior of (and need for) buckets, let's take an almost identical example 
as the one above:

バケツの振る舞い(とその必要性)を説明するのに一つ前のものとほぼ同じ例を使ってみましょう:

my $a = 42; my $b := $a; $a = 5;
    $0 = 42
    store '$a', $0
    bind '$b', '$a'
    $1 = 5
    store '$a', $1

(Note the two surface differences from the earlier example: := rather than =, and bind 
rather than assign.)
以前の例との表面的な違い二つに注意してください: := と =、束縛 (bind) と
代入 (assign)

The state at the end of this new program is a case of freaky action-at-a-distance. When 
the value of $a is changed to 5 in the last statement, the value of $b will also be changed 
to 5.

この新しいプログラムの終了時の状態は case of freaky action-at-a-distance です。最後の
文で $a の値が 5へと変更されたときに $b の値もまた 5へと変化します。

#freaky 異様な、風変わりな、

The reason for this is simple: the := (and the bind) causes the symbol $b not to have a 
bucket all of its own, but to acquire $a's bucket. When 5 is subsequently stored in that 
bucket, both $a and $b are simultaneously affected, since the two symbols share one and 
the same bucket.

このようになる理由は単純で、:= (と束縛)が $b に固有のバケツを持たせないようにして $a の
バケツを acquire させているからです。束縛のあとでそのバケツに 5 を格納したとき、$a と $b 
は同じように影響を受けます。それは、これら二つのシンボルが同じ一つのバケツを共有してい
るからです。

Now as a language feature, freaky action-at-a-distance may at first seem to be situated 
somewhere on a spectrum between "useless" and "dangerous". But it is 
the feature that makes pass-by-reference parameter passing work:

現在の言語仕様として、freaky action-at-a-distance may at first は "useless" から
"dangerous" までの間の範囲内のどこかに位置しているように思われます。しかしそれは
pass-by-reference によるパラメーターの受け渡しを動作させる機能です:


my $a = 42;
foo($a); # freaky!
say $a;  # 5

sub foo($b is rw) {
    $b = 5;
}

Note how that's practically the same example as the above with binding, except that 
it's now mediated through a layer of parameter passing. But $a and $b still share 
one single bucket, as before.


パラメーターを引き渡すレイヤーを通じて mediate されることを除けば bind を使った先の例
と practically には同じことをしていることに注意してください。それでも $a と $b は先の
例と同じく同じ一つのバケツを共有しています。

I only have two more things to say about this. First, jnthn++ explained in Copenhagen that 
the difference between scalar bucket and an array/hash bucket is that the former always 
forwards method calls to the value it contains. I don't grok that yet, so I may have got 
it wrong.

このことに関して、あと二つだけ書いておきたいことがらがあります。一つ目は jnthn++ が 
Copenhagen で説明したことで、スカラーのバケツと配列やハッシュのバケツとの間の違いは前者
では常にバケツに入っている値のためのメソッド呼び出しを forward するということです。
わたしはまだそれを grok していないので、間違ったことを言っているかもしれません。


Second, there's still a way to circumvent buckets, assigning values directly to symbols:

二番目はシンボルに対して直接値を代入する way to circumvent buckets (バケツへの抜け道?)
があることです:


my $a := 42;
    $0 = 42
    bind '$a', $0

What this means is simply that the variable $a is bound directly to a value, and has no 
buckets to which one can assign new values. It's a bit like a read-only value, except 
that $a can still be rebound to something else.

これは変数 $a が直接ある値に束縛されているということを意味しますが、同時に、新しい値を
代入することのできるバケツを持っていないことを示しています。これは read-only な値と似
ていますが、$a を別の何かに束縛することが可能な点が異なります。


These are the kinds of thoughts one gets when starting to write a time-travelling debugger.

■_ 本日の巡回から

2010年04月01日

■_

新年度になりましたということで、朝の電車の混み方がちょっと違ってました。 三月中はほぼ座れたんだけどなあ。

新入社員は本社のほうへ行ってるので、まだ見ていないのであった。

■_

melancholic afternoon
3月31日_

最近, 靴の裏にローラーが入ったものを履いてる子供をちらほら見かける. それも広い遊び場で
じゃなくて, スーパーや駅とかの場所で. 転んだりぶつかったりしてるの見るとはらはらする. 
ちょっと前は, 柔らかいサンダルを履いててエスカレーターで挟まる事故があったけど, こっち
の方が遥かに危険だろう. なんであんなもの履かせるのか理解できない. 重大な事故にあわない
と分からんのか. 


その手の靴はずいぶん前にも見た覚えがあります。 90年代にもあったんじゃないかなあ。

■_ Haskell で


数字文字列にカンマを入れる - siroccoの日記

ワンライナーっぽく出来た。

Prelude> let addComma numStr = concat $ snd $ foldr (\x t ->(fst t + 1,(if fst t `mod` 3 == 0 && fst t /= 0 then (x++",") else x):snd t)) (0,[]) [[x]|x <-numStr]
Prelude> addComma "1234"
"1,234"
Prelude> addComma "123"
"123"
Prelude> addComma "1234567890123"
"1,234,567,890,123"

こっちの方が短い。

addComma numStr = concat $ snd $ foldr (\x t ->(fst t + 1,(if fst t `mod` 3 == 0 && fst t /= 0 then ([x]++",") else [x]):snd t)) (0,[]) numStr

んー。foldr が肝?

■_ みの虫?


【超高速】C/C++に代わる低級言語を開発したい 
769 58 [sage] 2010/03/31(水) 14:36:01 ID: Be:
    記述力が高くてわかりやすい数式の記法ってのがあれば
    数学はカンタンになるのか? 

770 デフォルトの名無しさん [sage] 2010/03/31(水) 14:46:07 ID: Be:
    >>769
    微分積分の記号がない状態で微分積分の問題を取り扱うのが難しかったように、
    記述力が高い記号は数学を簡単にする助けになる 

771 デフォルトの名無しさん [sage] 2010/03/31(水) 14:50:58 ID: Be:
    微積の記号(インテグラル記号とか)はニュートンがほぼ今の原型を作ってるから
    最初からあるってことだぞ 

772 デフォルトの名無しさん [sage] 2010/03/31(水) 14:52:58 ID: Be:
    ニュートンじゃなくライプニッツな 

773 デフォルトの名無しさん [sage] 2010/03/31(水) 14:54:48 ID: Be:
    イギリスは独自の微分積分の記号を使ってたから
    大陸より発達が遅れたんだよな 

774 デフォルトの名無しさん [sage] 2010/03/31(水) 14:56:31 ID: Be:
    ニュートンもライプニッツもイギリス人なんだが、そうなの? 

775 デフォルトの名無しさん [sage] 2010/03/31(水) 14:58:37 ID: Be:
    ライプニッツはドイツ人かと思われ 

776 デフォルトの名無しさん [sage] 2010/03/31(水) 15:03:10 ID: Be:
    はっきりとは言わなくても、実は数学に疎い人たちが多いって事だけはわかった
    あと、>>769 は数学アレルギーで覚える気も無いって事もわかった

    同じように、きっとJavaやC#のような単純なルールの言語なら覚えられるけど、
    C/C++のようなあれもこれも可能な言語は覚えられない連中が多く、
    そしてそれを認めるのが恥ずかしいって思ってる人たちが多いのもわかった。

    以下、ひまわりスレ 

777 デフォルトの名無しさん [sage] 2010/03/31(水) 15:03:20 ID: Be:
    プライムのことをダッシュって読む人いるよね 

779 デフォルトの名無しさん [sage] 2010/03/31(水) 15:10:00 ID: Be:
    プライムよりダッシュだべ
    英論文でプライムを初めて見たとき何のことだかしばらくわからんかった 

780 デフォルトの名無しさん [sage] 2010/03/31(水) 15:12:25 ID: Be:
    数学の教授が、日本人があんまりダッシュダッシュと言うからダッシュが普及し始めた
    とか冗談言ってたな 

787 デフォルトの名無しさん [sage] 2010/03/31(水) 16:46:27 ID: Be:
    >>777
    俺ミノムシって呼んでる
    '←みのむし
    "←ダブルみのむし
    `←反対のみのむし 

788 デフォルトの名無しさん [sage] 2010/03/31(水) 16:59:42 ID: Be:
    >>787
    俺もそうよんでるw
    流行ってんの? 

789 デフォルトの名無しさん [sage] 2010/03/31(水) 17:02:44 ID: Be:
    俺の会社でもみんなみのむしって呼んでいるぞ 

790 デフォルトの名無しさん [sage] 2010/03/31(水) 17:03:34 ID: Be:
    >>787
    当たり前じゃん。
    ミノムシは世界共通だぜ。 

791 デフォルトの名無しさん [sage] 2010/03/31(水) 17:07:01 ID: Be:
    >>787-790
    おい、誰だ ミノムシ流行らせようとしてるやつw
    俺も明日から使おうかな。

■_ 本日の巡回から


一つ前へ 2010年3月(下旬)
一つ後へ 2010年4月(中旬)

ホームへ


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

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