ときどきの雑記帖 2012

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

一つ前へ 2012年5月(上旬)
一つ後へ 2012年5月(下旬)

ホームへ

2012年05月20日

■_

まだ名乗りを上げた人いないみたいね 誰かDHH氏のキーノートを翻訳しませんか? - ITは芸術だ David Heinemeier Hansson Keynote JA · newhavenrb/railsconf2012 Wiki

しまった見逃した 次回のOBSLiveは5/19(土)、8bit特集で芸夢狂人さん、TinyProject Hashiさんが登場 - おにたま(オニオンソフト)のおぼえがき

Facebook とか Google+ とかどうしたものかと

■_ My Road to the Python Commit Bit

comit bit を 得るまでの道程

My Road to the Python Commit Bit — Hynek Schlawack

My Road to the Python Commit Bit 

May 19, 2012 

Like many FOSS fans, I always wanted to be an active part of the movement. My last 
big pro­ject was for the Amiga in the past millennium though. Nowadays I'm happy 
that after years of small-scale dabbling on var­i­ous pro­jects I've found my haven. 
I'd like to share my way to my recent gain of push privileges on the Python 
project and hope to in­spire some of you to do the same. 

The Problem 

It isn't easy to start contributing to FOSS. Some projects seem even not to be 
particularly interested in new contributors – because everyone wants to contribute for
fame and glory. Others could use help but aren't eager to get new patches because of
ample amounts of code rotting in the bug tracker. But there are 
plenty of projects that want you to help. 

And yes, even CPython needs your help! That's the reason it's active in its 
outreach to new con­tributors. Please note I said “contributors”, you don't 
have to be a programmer – or do programmer's work – to help. 
略

© 2005–2012 Hynek Schlawack 
All Rights Reserved 

■_

■_

明日(もう今日か)のアレのため早じまいw

2012年05月19日

■_

23日発売だから今日辺りあそことかあそこに…と思ったが空振りだった(謎)

■_ C11

C11のはなし

The New C Standard Explored | Dr Dobb's
The New C Standard Explored

By Tom Plum, May 08, 2012

C11 specifies many security features that require minimal changes to existing code. They
greatly reduce unexpected behavior and prevent many kinds of common attacks.

C11 では既存のコードの変更を最小限にするような security features を多く規定しています。
それらは主に予期しない振る舞いを少なくし、一般的な攻撃法の多くを防ぎます。

C and C++ are members of the same family of languages. The evolutionary boldness of C++ removes
some of the marketplace pressure on C; people who are continually pushing for innovation are
naturally drawn to the C++ development process. Each language had a coherent original design
(by Dennis Ritchie and Bjarne Stroustrup, respectively), followed by successive refinement in a
very competitive marketplace of ideas. Both languages share an extreme concern for performance,
with the slogan "don't leave space for a more-efficient systems-programming language
underneath our language (C or C++)." However, it's unfair to complain that the original
designs assigned too little importance to cybersecurity; both languages pre-date the beginnings
of concern for security. But in recent years, as the marketplace has started to emphasize 
cybersecurity, C and C++ have been responding in several ways.

C と C++ は同じ言語ファミリーのメンバーです。C++ の evolutionary boldness は
C に関する marketplace pressure の一部を取り除きました。
継続的にイノベーションを行っている人たちは自然に C++ を使った開発プロセスに引きつけられました。
いずれの言語も coherent な original design を持ち、継続した refinment が
competitive marketplace of ideas で行われてきました。
どちらの言語も性能に関して非常に関心を払っていて、それは
"don't leave space for a more-efficient systems-programming language underneath our language (C or C++)."
というスローガンに現れています。
しかし、もともとの設計で cybercecurity にあまり関心を払わなかったことを責めるのは
フェアではありません。
どちらの言語にしてもセキュリティが注目されるようになる前に作られたものなのですから。
とはいえ、近年においては市場でもセキュリティが重大な関心事となってきていますから、
C と C++ もいくつかの手段で対応してきています。

In early 2002, Bill Gates' famous "battleship-turning" memo made cybersecurity a top
goal for Microsoft. About a year later, Microsoft proposed a new "bounds-checking"
library to WG14, which eventually became Technical Report 24731-1. It now is part of C11 as the
(optional) Annex K. (An almost-final draft of C11 is available here [PDF].)

The C11 Annex K Functions

I'll start my tour of Annex K with the fopen_s function. The main innovation is that 
files are opened with exclusive (also known as non-shared) access. Furthermore, if the 
mode string doesn't begin with u (such as with code being updated from the older fopen 
), then to the extent that the underlying system supports it, the file gets a file 
permission that prevents other users on the system from accessing the file.

(以下略)

■_ まぜると

What happens when you mix three research programming languages together : haskell

What happens when you mix three research programming languages together : Inside 233

What happens when you mix three research programming languages together
三つの実験的なプログラミング言語を一緒に使ったときに起きること

by Edward Z. Yang

  “...so that's what we're going to build!”

  “Cool! What language are you going to write it in?”

  “Well, we were thinking we were going to need three programming languages...”

  “...three?”

  “...and they'll be research programming languages too...”

  “Are you out of your mind?”

This was the conversation in streaming through my head when I decided that I would be writing my
latest software project in Coq, Haskell and Ur/Web. I had reasonably good reasons for the choice:
I wanted Coq because I didn't actually want to implement a theorem prover from scratch, I wanted
Ur/Web because I didn't actually want to hand write JavaScript to get an AJAX interface, and I
wanted Haskell because I didn't want to write a bucket of C to get Ur/Web and Coq to talk to
each other. But taken altogether the whole thing seemed a bit ludicrous, like an unholy fusion
of a trinity of research programming languages.

この選択をしたのにはきちんとした理由がありました。
Coq を選んだのは一からきちんと理論を実装することはやりたくなかったからですし、
AJAX インターフェースを手に入れるために JavaScript をごりごり書くのを避けたいから
Ur/Web を使いたかったのだし、Ur/Web と Coq を互いにやり取りさせるために
やまほど C で書くのは望まなかったので Haskell を必要としたのです。
しかし、これらすべてを一緒に扱うことは少々滑稽で、
三位一体の実験的プログラミング言語の unholy な融合のようなものでした。


In the end, it worked out quite well. Now, what this means depends on your expectations: it was
not the case that “everything worked out of the box and had very nice instructions attached.”
However, if it was the case that:

    No single issue ended up requiring an unbounded amount of time and yak shaving,
    

    Any patches written made it into upstream, improving the situation of the software for
    future developers, and

    The time spent on engineering grease is less than the time it would have taken to build the
    system with inferior languages,

    engineering grease に要する時間が低水準言語でシステムを構築したときに要したであろう時間
    よりも少なく

    Everyone involved in the project is willing to learn all of the languages involved (easy if
    it's only one person),
    プロジェクトの全員が挙げられたすべての言語を学ぶことを望んでいる

then yes, it worked “quite well”. In this post, I'd like to describe in a little more detail
what happened when I put these three languages together and speculate wildly about general
maxims that might apply when someone is doing something similar. (A description of what the
project actually is will unfortunately have to wait a little; it's not quite done yet.)

このポストでは三つの言語をまとめて使ったときに起きたことの詳細を説明し、
ほかの人が同様なことをしようとしたときに教訓 (maxims) となるでろうことを書こうと考えています。



(略)

Conclusion

I've presented six maxims of research polyglottism:
research polyglottism (どう訳したものか) について六つの格言 (maxims) を挙げました

    Interchange formats will be undocumented and just good enough to get the job done.
    中間フォーマットはアンドキュメンッテドでとりあえず役目を果たすものになるだろう

    In ML-like languages, it's very easy to make simple but far reaching changes to a codebase,
    due to the assistance of the typechecker.
    ML のような言語では型チェッカーの助けがとても便利

    A deterministically reproducible bug in some core functionality will get fixed very quickly
    by an active original author of the code.
    core functionality にある deterministicall に再現できるバグは
    active な code の original author によってすばやく修正されるだろう

    The less interesting a problem is to the academic, the more likely it is you'll be able to
    fix it yourself.

    An FFI is a crucial feature for any DSL, and should be a top priority among tasks involved
    in preparing a language for general usage.
    FFI はすべての DSL にとって重要な機能 (crucial feature) であり、
    広く使われる言語を得るために必要なタスクで最高の優先順位となるべきものである

    Make sure you know how to do parsing in all of the languages involved.
    すべての言語でパージングがどのように行われるのかを熟知すること

If you keep all of these maxims in mind, I believe that the tradeoff between some extra bugfixing
and yak shaving for the benefits of the research programming language is a compelling one, and
one that should be considered seriously. Yes, you have to be willing to muck around with the
innards of all the tools you use, but for any sufficiently important tool, this is inevitably
true. And what is a more important tool than your compiler?

■_

2012年05月18日

■_

encapsuraltion を 「カプセル化」とするのも問題ありじゃね? とは思うものの、これをさすがに今から変えろというのも無理な話か。

boxing → ボックス化と同じ違和感なんですよね。これも。 最近まで気にならなかったんだけど。

それがなんで気になるようになったかというと、boxing だったりするんですが。

■_ Pythonista

という呼称について。

degrading → 下劣な、不真面目な。

Does anyone else hate the term `Pythonista`? : Python

Does anyone else hate the term `Pythonista`? (self.Python)


Why do people call themselves this? It's degrading, whatever you use Python for you shouldn't
bring yourself down to the level of a barista.


    shouldn't bring yourself down to the level of a barista

What an asshole thing to say.


Relevant username perhaps? Either way, you're totally right.


Ha! I didn't actually think about that, maybe I'll become the defender of all things coffee-related.


It doesn't come from barista. "-ista" is a suffix which when added to a noun denotes
someone who practices, believes or is adept in that noun.

http://en.wiktionary.org/wiki/-ista


Shouldn't a barista then be a bartender? or lawyer?


Maybe. In that sense I would think someone who goes to bars would be a barista.


A barista works a coffee bar you could say.


You mean like 'barrister', maybe?


That is what it means: barista is the Italian word for barman or barmaid. I guess owing to
coffee's Italian heritage, somebody thought it would be funny to refer to the person who
works behind the bar at a coffee shop as an Italian bartender. It was probably Starbucks,
who loves to co-opt Italian words, such as venti, the Italian word for twenty, since that
cup size is 20 fl.oz.

Edit: As far as I can tell (and this could be wrong), barrister also derives from bar, but
the meaning here is the railing in a UK courtroom that separates the spectators from those
that are actually part of the court (judges, defendant, witnesses, etc.) Since it separated
those trained in the law from the rest, the word bar became a metonym for the practice of
being a lawyer, leading to the licensing exam being called "the bar", and the
professional association being called "the Bar Association" and so on.

    someone at Starbucks thought it funny to call their personel barista

A bar in Italy is something quite different than what you think of in the US. Their most
important function is to sell coffee. Since Italians take their coffee very seriously a
barista is a well trained profession and so internationally a barista has to come to mean
a person trained to operate a professional Italian coffee machine.

Now, given the poor quality of coffee at Starbucks I don't think their personel actually
deserve the title barista at all.

The more you know!


    yourself down to the level of a barista.

You aren't better than anyone.


I consider myself to be Pythonesque, but I only ever use the word Pythonista ironically.


I just call myself a Pythoner.


I'm not a fan of the term and don't use it, I always assumed it was derived more from 
"fashionista", not barista.

My biggest gripe with the term is that it's a gender specific (feminine) noun used to 
describe a gender agnostic group.


You could call yourself a "pythonisto," right? It is feminine because of the "a"
attached to the end of the word. I agree with you, it's not attached to barista, but fashionista.


We need more Python Ninjas too.

展開が良くわからんけど、 それはさておきなんでもかんでも -er (-or) ですませがちなのは(ry

■_

10 ways to improve your programming skills : programming ←で話題になってたので 10 ways to improve your programming skills — AntoArts ←リンクを辿ってみたのだけど どうも見覚えがあるし、昨年の日付だからもしやとぐぐると

プログラミングのスキルを鍛える10の方法 | TRIVIAL TECHNOLOGIES on CLOUD

■_

■_

BS プレミアムで斎藤隆を取り上げた番組をやってまして、 そこでこんな言葉が(自分で作った言葉だそうですが) 雲上在天[d2][d1]衰えゆく自身の体細部の筋肉を毎日3時間のマッサージトレーナーに指示する迄の勉強研究

2012年05月17日

■_

オライリーの ScyPy and NumPy 本まだだったのね。

■_ R, SAS, SPSS

SPSS って結構使われてるんですね。 まあ今は天下の IBM から出てるものだしなあ

How long before R overtakes SAS and SPSS? | (R news & tutorials)

How long before R overtakes SAS and SPSS?
May 15, 2012
By David Smith

(This article was first published on Revolutions, and kindly contributed to R-bloggers)

Based on an analysis of Google Scholar data on usage of statistical software, Bob Muenchen
makes a forecast: R will overtake SAS and SPSS in 2015. Forecasting is extrapolation —
always a tricky business — so Bob also provides these qualitative reasons why R will
continue to grow at the expense of SAS and SPSS:

R が伸び続ける理由

    The continued rapid growth in add-on packages (Figure 10)
    アドオンパッケージ(の数)が伸び続ける

    The attraction of R's powerful language
    強力な言語としての R の魅力

    The near monopoly R has on the latest analytic methods
    最近の analytic methods においてほぼ独占状態にある

    Its free price
    無料

    The freedom to teach with real-world examples from outside organizations, which is 
    forbidden to academics by SAS and SPSS licenses (it benefits those organizations, so 
    the vendors say they should have their own software license).
    SAS や SPSS のアカデミックライセンスにはいろいろ不自由がある

See how Bob comes up with this forecast (using R, of course!) at the link below.

2015 年に追い抜く。と。

Will 2015 be the Beginning of the End for SAS and SPSS? | (R news & tutorials)

■_ coding standard

で、これ。 Joint Strike Fighter (F-35) C++ Coding Standard : programming F-35 Joint Strike Fighter Coding Standard Documentation | Hacker News conding standard は → http://www2.research.att.com/~bs/JSF-AV-rules.pdf

140ページもあると目を通すのも少々手間がかかるけど、ちまちま眺めてたり。

1 INTRODUCTION

The intent of this document is to provide direction and guidance to C++ programmers that
will enable them to employ good programming style and proven programming practices leading
to safe, reliable, testable, and maintainable code. Consequently, the rules contained in
this document are required for Air Vehicle C++ development and recommended for non-Air
Vehicle C++ development.

As indicated above, portions of Air Vehicle (AV) code will be developed in C++. C++ was
designed to support data abstraction, object-oriented programming, and generic programming
while retaining compatibility with traditional C programming techniques. For this reason,
the AV Coding Standards will focus on the following:

1. Motor Industry Software Reliability Association (MISRA) Guidelines For The Use Of The C
   Language In Vehicle Based Software,

2. Vehicle Systems Safety Critical Coding Standards for C, and

3. C++ language-specific guidelines and standards.

The MISRA Guidelines were written specifically for use in systems that contain a safety
aspect to them. The guidelines address potentially unsafe C language features, and provide
programming rules to avoid those pitfalls. The Vehicle Systems Safety Critical Coding
Standards for C, which are based on the MISRA C subset, provide a more comprehensive set
of language restrictions that are applied uniformly across Vehicle Systems safety critical
applications. The AV Coding Standards build on the relevant portions of the previous two
documents with an additional set of rules specific to the appropriate use C++ language
features (e.g. inheritance, templates, namespaces, etc.) in safety-critical environments.

Overall, the philosophy embodied by the rule set is essentially an extension of C++'s 
philosophy with respect to C. That is, by providing “safer” alternatives to “unsafe” 
facilities, known problems with low-level

  
3 GENERAL DESIGN

This coding standards document is intended to help programmers develop code that conforms
to safety-critical software principles, i.e., code that does not contain defects that could
lead to catastrophic failures resulting in significant harm to individuals and/or equipment.
In general, the code produced should exhibit the following important qualities:

Reliability: Executable code should consistently fulfill all requirements in a predictable manner.
信頼性

Portability: Source code should be portable (i.e. not compiler or linker dependent).
移植性

Maintainability: Source code should be written in a manner that is consistent, readable, simple
in design, and easy to debug.
保守性
ソースコードは一貫したマナーのもと、読みやすく、単純な設計で、かつデバッグが容易であるように
書かれるべきである。

Testability: Source code should be written to facilitate testability. Minimizing the 
following characteristics for each software module will facilitate a more testable and 
maintainable module:
テスト容易性

1. code size
2. complexity
3. static path count (number of paths through a piece of code)

Reusability: The design of reusable components is encouraged. Component reuse can eliminate
redundant development and test activities (i.e. reduce costs).
再利用可能性
再利用可能なコンポーネントの設計が推奨される。
コンポーネントの再利用は無駄な開発や test activeties を抑制する
(つまりはコストを下げる)。

Extensibility: Requirements are expected to evolve over the life of a product. Thus, a 
system should be developed in an extensible manner (i.e. perturbations in requirements may
be managed through local extensions rather than wholesale modifications).
拡張可能性

Readability: Source code should be written in a manner that is easy to read, understand and comprehend.
可読性 ソースコードは、読みやすく、理解しやすく記述すべきである


Note that following the guidelines contained within this document will not guarantee the
production of an error-free, safe product. However, adherence to these guidelines, as well
as the processes defined in the Software Development Plan [12], will help programmers produce
clean designs that minimize common sources of mistakes and errors.
  

Ada では人を思うように集められないとかでC++を採用したといったような 記事を以前に見た覚えがありますが、C++ を使い、かつ、 このような conding standard を設けることで Ada を使わない(使えない)ことの デメリットは解消できるんでしょうか。 見た感じ項目の一つ一つは納得できるものばかりのようだし、 確かにバグが入り込む余地は少なくするように見えます。 が、実際問題どの程度効果があるものなのか知りたいなあと。 どこかにこういった conding standard を採用した場合とそうでない場合の コードの質について論じたものとかないもんだろか。

conding standard の詳細も気が向いたらいずれ取り上げます。

■_ \?

メタキャラクターのはなし

どさにっき

 \?

    _ "a?hoge" という文字列の頭の a? を削る。

    _ 期待する挙動。

        > echo 'a?hoge' | sed 's/a\?//'
        hoge

    FreeBSD の sed はちゃんとこのように動く。

    _ GNU sed。

        $ echo 'a?hoge' | sed 's/a\?//'
        ?hoge

    a? ではなく a の1文字だけが削られる。なんで?

        $ echo 'a?hoge' | sed --posix 's/a\?//'
        hoge
        $ sed --version
        GNU sed version 4.2.1

    debian squeeze などに入ってる GNU sed 4.2 なら --posix で意図した挙動になるが、

        $ echo 'a?hoge' | sed --posix 's/a\?//'
        ?hoge
        $ sed --version
        GNU sed version 4.1.5

    centos5 などに入ってる 4.1 だとそれでもやっぱりおかしい。

    _ GNU sed でも

        $ echo '?hoge' | sed 's/\?//'
        hoge

    頭の "a?hoge" から "a?" を削るのではなく、"?hoge" から "?" を削るのは問題なく動く。

        $ echo 'a*hoge' | sed 's/a\*//'
        hoge

    ? ではなく * であれば問題ない。

    _ とりあえず、

        $ echo 'a?hoge' | sed -r 's/a\?//'
        hoge

    のように -r とすれば GNU sed でも問題なく動くが、

        > echo 'a?hoge' | sed -r 's/a\?//'
        sed: illegal option -- r
        usage: sed script [-Ealn] [-i extension] [file ...]
               sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...]

    今度は FreeBSD で動かなくなる。-r は拡張正規表現を使うということなんだけど、\? って拡張か?

    _ ? が正規表現的に特殊な意味を持つ記号であることはもちろん承知してるが、その特殊な意味を持たせないように \? と表記してるにもかかわらず謎の挙動になる。今のところ sed -r 以外のまともな解決策が見つかってないんだけど、どうするのが正しいんだべ。

<< = >>

\? は GNU 固有(たぶん)の拡張です。 --posix オプション指定時に動作が変わるのはこの指定によりGNU拡張が disable されるからです(4.2と4.1で違うのは仕様変更かなあ)。 -r オプションは egrep に準ずる正規表現を使うよう指示するオプションなので この場合も \? がメタキャラクターでなくなります。 $ echo '?hoge' | sed 's/\?//' このケースは、 先行するものがないのに繰り返し指定のメタキャラクターがあるために エラーになり、結果的にリテラルとしての ? を置いたのと同じ解釈になっているためです。

GNU sed の Info から。


`\+'
     As `*', but matches one or more.  It is a GNU extension.

`\?'
     As `*', but only matches zero or one.  It is a GNU extension.

  `\{I\}'
     As `*', but matches exactly I sequences (I is a decimal integer;
     for portability, keep it between 0 and 255 inclusive).

`\{I,J\}'
     Matches between I and J, inclusive, sequences.

`\{I,\}'
     Matches more than or equal to I sequences.

`\(REGEXP\)'
     Groups the inner REGEXP as a whole, this is used to:

        * Apply postfix operators, like `\(abcd\)*': this will search
          for zero or more whole sequences of `abcd', while `abcd*'
          would search for `abc' followed by zero or more occurrences
          of `d'.  Note that support for `\(abcd\)*' is required by
          POSIX 1003.1-2001, but many non-GNU implementations do not
          support it and hence it is not universally portable.
`REGEXP1\|REGEXP2'
     Matches either REGEXP1 or REGEXP2.  Use parentheses to use complex
     alternative regular expressions.  The matching process tries each
     alternative in turn, from left to right, and the first one that
     succeeds is used.  It is a GNU extension.
  

POSIX 的には、sed で使用する正規表現 (Basic Regular Expression) には ? (0回または1回) +(1回以上の繰り返し) | (選択) に類するメタキャラクターはありません、

■_

2012年05月16日

■_

ほかにもあるだろうけど zed のは読まねば。

パタンランゲージ
読んだ。というかまだ途中なんだけど、次の予約が入ってしまったので延長できない ○| ̄|_

結構面白く読めているのだけど(「ミニバス」の話とか)、 正直これからなにがどうやってデザインパターンに言ったのかが良くわからないw 深く考えるだけ無駄な類のものなのかもしれないけど。

パタン・ランゲージ―環境設計の手引 オブジェクト指向における再利用のためのデザインパターン

■_

ちょっとの変更で実行速度が大違いという話

c# - Why does adding local variables make .NET code slower - Stack Overflow

Why does commenting out the first two lines of this for loop and uncommenting the third result
in a 42% speedup?

  int count = 0;
  for (uint i = 0; i < 1000000000; ++i) {
      var isMultipleOf16 = i % 16 == 0;
      count += isMultipleOf16 ? 1 : 0;
      //count += i % 16 == 0 ? 1 : 0;
  }

Behind the timing is vastly different assembly code: 13 vs. 7 instructions in the loop. The
platform is Windows 7 running .NET 4.0 x64. Code optimization is enabled, and the test app was
run outside VS2010. [Update: Repro project, useful for verifying project settings.]

Eliminating the intermediate boolean is a fundamental optimization, one of the simplest in my
1980's era Dragon Book. How did the optimization not get applied when generating the CIL or
JITing the x64 machine code?

Is there a "Really compiler, I would like you to optimize this code, please" switch?
While I sympathize with the sentiment that premature optimization is akin to the love of money,
I could see the frustration in trying to profile a complex algorithm that had problems like
this scattered throughout its routines. You'd work through the hotspots but have no hint of the
broader warm region that could be vastly improved by hand tweaking what we normally take for
granted from the compiler. I sure hope I'm missing something here.

Update: Speed differences also occur for x86, but depend on the order that methods are 
just-in-time compiled. See Why does JIT order affect performance?

Assembly code (as requested):

      var isMultipleOf16 = i % 16 == 0;
  00000037  mov         eax,edx 
  00000039  and         eax,0Fh 
  0000003c  xor         ecx,ecx 
  0000003e  test        eax,eax 
  00000040  sete        cl 
      count += isMultipleOf16 ? 1 : 0;
  00000043  movzx       eax,cl 
  00000046  test        eax,eax 
  00000048  jne         0000000000000050 
  0000004a  xor         eax,eax 
  0000004c  jmp         0000000000000055 
  0000004e  xchg        ax,ax 
  00000050  mov         eax,1 
  00000055  lea         r8d,[rbx+rax] 

      count += i % 16 == 0 ? 1 : 0;
  00000037  mov         eax,ecx 
  00000039  and         eax,0Fh 
  0000003c  je          0000000000000042 
  0000003e  xor         eax,eax 
  00000040  jmp         0000000000000047 
  00000042  mov         eax,1 
  00000047  lea         edx,[rbx+rax] 

■_

Woz が Aplle についてなにか言ったらしく。 Wozniak calls for open Apple - Strategy - Business - News - iTnews.com.au

Wozniak calls for open Apple | Hacker News

Here is a nice comparison. Buy a mobile device and try to use the standard developer tools to
put Hello World on it.

Android: Download Eclipse (Windows, Linux or Mac) and the Android SDK (Windows, Linux or Mac)
- no accounts or registration needed for either of these. In your phone menus enable
development and connect via USB. In Eclipse make your hello world project, and hit Run or Debug.
Enjoy.

Apple: You must buy a Mac. In the App Store (requires an account) or the developer 
site (requires an account and registration) download Xcode. Create your project. 
Connect the phone via USB. Right click to enable it for development and then do some 
song and dance with Apple to get permission to use "your" device for 
development. (I haven't yet worked out the exact dance required and how much it costs.)

I don't know what it looks like for WP7 but assume it is substantially similar to Apple.


Apple was hope . now its the new MS ...

comes with the territory . if you the one and in bed with CIA who's to say open up ...


DEC is the new Unisys.

IBM is the new DEC.

Microsoft is the new IBM.

Apple is the new Microsoft.

Linux is the new... err ahh...

BSD is the new.. err umm...

Screw opening corporations. Break the cycle entirely I say.


You forgot one: Java is the new COBOL.

Now, more seriously, such cycles do exist and we can observe them easily. History repeats
imperfectly in subtly different ways. If Apple is to be the new Microsoft, it won't be exactly
like it just as Microsoft is not exactly the new IBM - both have learned from their
predecessors. Will they make mistakes that doom themselves? Eventually yes, but they won't be
the same mistakes that doomed their predecessors.


At the momenent, Apple is even worse than Microsoft.

Two ways I can think of now.

Microsoft got docked for just bundling IE with their OS. I just installed Netscape 
back in the day(before switching to IE coz Netscape started sucking). Apple bans all 
competing browsers. (Windows RT is a different story).

The iOS app store forces developers to use their in-app purchasing with a 30% cut for 
Apple and bans any links to the developer websites to sell services. The Windows App 
Store does not require this.

■_

2012年05月15日

■_

耳鼻科
実はまだ通ってます。 中耳炎はもう問題ないのですが、 耳鳴りが続いてるので(とはいえこっちもだいぶ良くなった)。 通っている耳鼻科がなかなか興味深くて、気が向いたらその辺を書いてみようかと。

ませまちか
ぽんと買えるくらいの稼ぎにはしたいわねえ。

■_

今日の十個のなんのとか

Bertrand Russell's 10 Commandments for Teachers — Marginal Revolution
Marginal Revolution 

Bertrand Russell's 10 Commandments for Teachers 
by Alex Tabarrok on May 6, 2012 at 7:03 am
 
  Do not feel absolutely certain of anything.

  Do not think it worth while to proceed by concealing evidence, for the evidence is sure
  to come to light.

  Never try to discourage thinking for you are sure to succeed.

  When you meet with opposition, even if it should be from your husband or your children,
  endeavour to overcome it by argument and not by authority, for a victory dependent upon
  authority is unreal and illusory.

  Have no respect for the authority of others, for there are always contrary authorities
  to be found.

  Do not use power to suppress opinions you think pernicious, for if you do the opinions
  will suppress you.

  Do not fear to be eccentric in opinion, for every opinion now accepted was once eccentric.

  Find more pleasure in intelligent dissent that in passive agreement, for, if you value
  intelligence as you should, the former implies a deeper agreement than the latter.

  Be scrupulously truthful, even if the truth is inconvenient, for it is more inconvenient
  when you try to conceal it.

  Do not feel envious of the happiness of those who live in a fool's paradise, for only a
  fool will think that it is happiness. 
 

■_ puzzule

C++ むずい

A C++ program puzzle | Pixelstech.net

A C++ program puzzle 
 
Source : Peter Date : 2012-05-13 02:31:26 

Recently I came across a question asked by wang2191195 on a Chinese IT forum CSDN which asks
about a C++ program puzzle. He has a code snippet which cannot be compiled. The code is: 

  #include <cstdlib> 
  #include <iostream> 

  using namespace std; 

  class Base{ 
  public: 
      virtual void func(){ 
          cout << "Base::func()" << endl; 
      } 
 
      virtual int func( int num ){ 
          cout << "Base::func( int " << num << " )" << endl; 
          return 0; 
      } 
  }; 
 
  class Derived : public Base{ 
  public: 
      virtual void func(){ 
          cout << "Derived::func()" << endl; 
     }
  };
 
  int main(){ 
 
      Derived d; 
      d.func(); 
      d.func(1); 
      system("PAUSE"); 
  } 
 
The compile result is : 
(略)



Pixelstech.net © 2011-2012 All rights reserved 

■_

言及先の pdf がなんともすごかった → http://www.softwarepreservation.org/projects/FORTRAN/BackusEtAl-Preliminary%20Report-1954.pdf

こういうのが公開されてるのね。

FORTRAN should virtually eliminate coding and debugging | Hacker News

Well, it did eliminate some kinds of coding (the part where human produces machine 
code from block diagrams) and debugging (the part where you look for errors in the 
above translation.)

Half a century later, people are still overly optimistic about software development. According
to recent studies, this is true for everything (and society at large is actually in favor of it).

Yet it is particulary visible in computing. Why is that?

Side note: bullshit in marketing brochure is here to stay.


Half a century later the change isn't from assembly to an actually useful level of 
abstraction. The bullshit-o-meter is damped further when half the document shows code 
examples that would be much more difficult in assembly.

■_

■_

2012年05月14日

■_

ボレル集合ってなんですかーっ○| ̄|_

■_ D

D のイケてる機能

Cool features of the D language « Michael Larouche – The Day Dreamer


Cool features of the D language
12 05 2012

Since several weeks, I gave a second look at the D programming language after watching 
videos of talk gave by Andrei Alexandrescu and Walter Bright at Lang.NEXT conference 
(see Walter video and Andrei video). I decided to explain my favorite and cool 
features of the language. Of course there's many more, I invite you to take a look at 
the website to find more information about the language.

scope guard statement

scope guard statement allows you to write code that will be executed either at the exit of the
function, when the function succeeds (when they are no error or expection raised) and when you
get failure by error or an exception.

スコープガード文は関数を脱出するときに
関数が成功したとき、エラーもしくは例外によって失敗させるとき
のいずれかによって実行されるコードを書けるようにします。


It can be used to simulate the RAII pattern. Say you need to write data coming from a database
into a File and the API isn't RAII friendly. You could use try-catch-finally statements like
this

これは RAII パターンをシミュレートするのに使えます。
データベースから持ってきたデータをファイルに書き出す必要があるけれども
API が RAII フレンドリーなものでない状況にあるとしましょう。
try-catch-finally 文を使って次のように書けます

	auto file = new std.stream.File("test.txt", FileMode.In);
	auto db = new SqlDatabase();
	 
	try
	{
	    db.open();
	}
	catch(SqlException e)
	{
	    writeln(e);
	    return;
	}
	 
	try
	{
	    db.callFunctionThatFails(file);
	}
	catch(SqlException e)
	{
	    writeln(e);
	}
	finally
	{
	    db.close();
	    file.close();
	}

It's a simple code with some flaws (the File object is never closed).If we nest various
try-catch statement, code can become pretty cluttered and hard to read. Here's the version with
the scope(exit) statement

上記のコードは(Fileオブジェクトが決してクローズされない)いくつかのフローを持った単純なコードです。
いくつかの try-catch 文がネストした場合、コードは pretty cluttered なものとなり
読むのが困難になります。
次のコードは scope(exit) 文を使ったバージョンです。

	auto file = new std.stream.File("test.txt", FileMode.In);
	auto db = new SqlDatabase();
	 
	scope(exit)
	{
	    file.close();
	    db.close();
	}
	 
	try
	{
	    db.open();
	    db.callFunctionThatFails(file);
	}
	catch(SqlException e)
	{
	    writeln(e);
	}

Behind the scene, the compiler will write the correct try-catch statement for you.

((略)

Conclusion

The D language is powerful and deep and they are many things to learn about this language. For
go further, I suggest you read the official documentation on the website and to read Andrei's
book The D Programming Language. As for me, I think I've finally found a worthy successor of
C++ for my projects that required C++ in the past. I'm currently investigating doing DirectX 11
code using D.

D は強力かつ deep であり、この言語について学ぶことはたくさんあります。
web にある公式ドキュメントを読み、さらに Andrei の本 The D Programming Lanugage を
読むことをお勧めします。
わたしは自分がようやく
過去わたしが C++ を必要としていたプロジェクトのための
C++ の worthy successor (良い後継者?) を見つけたと考えています。
現在わたしは D を使った DirectX 11 のコードを試しているところです。

なかなか痒いところに手が届く機能がいろいろと

■_ coding standard

F-35 のソフトウェア(具体的にどこのというのはなし)で使われた コーディング標準が公開? されているらしく。 Joint Strike Fighter (F-35) C++ Coding Standard : programming F-35 Joint Strike Fighter Coding Standard Documentation | Hacker News

ちょっと目を通したけど、いかんせん大きい(140ページくらいある)ので結構大変。

■_

■_ quotemeta

正規表現についてひとつ覚えた: つらつらぐさ

Perl なら quotemeta 、Ruby なら Regexp.quote なんてのがありまする。 Python は re.escape かな 7.2. re — Regular expression operations — Python v2.7.3 documentation

2012年05月13日

■_

Stallman のその後は?

読んだ
浜村渚の計算ノート (講談社文庫)
浜村渚の計算ノート (講談社文庫)
近々新刊のでるアレのようには数学数学してないけど結構面白かった。 が、ラノベマスターいなばさんによると二巻の方が面白かったらしい。 これから読もう。
浜村渚の計算ノ-ト 2さつめ ふしぎの国の期末テスト (講談社文庫)
浜村渚の計算ノ-ト 2さつめ ふしぎの国の期末テスト (講談社文庫)
三巻ももうすぐ(というか別の版型ですでに出ているんだけど) 浜村渚の計算ノート 3さつめ 浜村渚の水色コンパス (講談社文庫)
浜村渚の計算ノート 3さつめ 浜村渚の水色コンパス (講談社文庫)

■_ TAPL読書会

昨日ありまして。

前回は体調が絶不調で欠席しておりまして、今回は二ヶ月ぶり。

前回が Chapter 20で、今回は Chapter 21 の途中まで。

21 Metatheory of Recursive Types

21.1 Induction and Coinduction

inductive definition/coinductive definition

P(U) パワーセット 巾集合

21.1.1
定義

generating function とは?

21.1.2
1. F-closed
2. F-consistent
3. fixed

21.1.3
U = {a,b,c};
E1(Φ) = {c}
  ...
E1({a,b,c,}) = {a,b,c}


21.1.4
TARSKI 1955
1
2 The union of all F-consistent sets is the greatest fixed point of F.

C = {X | X ⊆ F(X)}
P = U(C)

21.1.5
21.1.6

21.1.7 Exercise
Suppose a generating function E2 on the universe {a.b,c} is defined by the following inference rules.

                   c       a     b
        ---       ---     --------
         a         b          c

E2(Φ)
…
E2({a,b,c}) = {a,b,c}

21.1.8
COROLLARY
1 principle of induction
2 prinsiple of coinduction

21.1.9
F(X) = {0} ∪ {i+1| i ∈ X}

21.2 Finite and Infinite Types
  → × Top

21.2.1
definition
T(・)
T(π,σ)
T(π)
T(π)

21.2.2
exercise
Define a tree to be a partial function T ∈ {1,2}* → {→,×,Top}
satisfying the following constraints:

T(・) is defined;
if T(π,σ) is defined then T(π) is defined

U すべてのtree の集合
F(X) =  {Top}
     ∪ {T1 × T2 | T1,T2 ∈ X}
     ∪ {T1 → T2 | T1,T2 ∈ X}

21.3 Subtyping

21.3.1
definition [Finite subtyping]

Sf(R) = {(T,Top)|T ∈ Tf}

-----------
  T <: Top

S1 <: T1    S2 <:T2
-------------------------
S1 × S2 <: T1 × T2

T1 <: S1    S2 <:T2
-------------------------
S1 → S2 <: T1 → T2

21.3.3 exercise
(Top, Top×Top)

21.3.4
Is there a pair of types (S,T)
無限の型(Top×Top×Top…)を考える

21.3.5
definition

21.3.6
lemma
proof
νF = F(νF) ←
TR(νF) = TR(F(νF))

TR(νF) ⊆ νF

21.3.7
Theorem νS is transitive

Proof
case U = Top
case U = U1 × U2
case U = U1 → U2


21.3.8
subtype relation

21.4 A Digression on Transitivity
「two useful roles」


21.4.1
Propsitions
proof

うははまるで意味のわからんメモ ○| ̄|_

■_ プログラミング言語の進化とは

The March of Progress (in programming language syntax :) : programming

alan dipert - The March of Progress

Jul 31st Fri
The March of Progress

    1980: C

    printf("%10.2f", x);

    1988: C++

    cout << setw(10) << setprecision(2) << showpoint << x;

    1996: Java

    java.text.NumberFormat formatter = java.text.NumberFormat.getNumberInstance();
    formatter.setMinimumFractionDigits(2);
    formatter.setMaximumFractionDigits(2);
    String s = formatter.format(x);
    for (int i = s.length(); i < 10; i++)
        System.out.print(' ');
    System.out.print(s);

    2004: Java

    System.out.printf("%10.2f", x);

    2008: Scala and Groovy

    printf("%10.2f", x)

いろいろと反響が

    Uyt

    28 years to lose semicolons
  
    Marcelk

    Funny, because the semi-colons were in these places not needed in BCPL, the predecessor of C.
  
    Christophe de Dinechin

    C was not widely used on PCs before the 1980s. Back then, we used Pascal, and before that, BASIC.

    10 PRINT USING "#######.##", X
  
    And1hotsauce

    Or in Python:

    print "%10.2f" % x
  
    Aaron Peschel

    Here is the modern Python alternative:

    print("{0:10.2f}".format(x))
  

    pre 1980: Smalltalk
    x asFloat printShowingDecimalPlaces: 2
  
    Jarppe

    Clojure ftw: (format "%10.2f" x)
    One character less than Scala and Goovy :)
  
rbanffy In FORTRAN you could say: write (*, 10) x 10 format (f10.2) but, at least, you didn't need to use semicolons ;-)
    In modern Fortran you just do:

    print "(f10.2)", x

■_ split

split - odz buffer しかし、末尾の空文字を削除するのは何なんだろな。

awkの仕様から来たのかなあ。ってどうだったっけか。

perlfunc - Perl 組み込み関数 【perldoc.jp】

split /PATTERN/,EXPR,LIMIT
split /PATTERN/,EXPR
split /PATTERN/
split

    文字列 EXPR を文字列のリストに分割して、リストを返します。 デフォルトでは、行頭の空白は
    保存され、末尾の空白は削除されます。

(略)

    正の数の LIMIT を指定した場合には、EXPR が分割されるフィールドの最大数を 表しますが、実
    際に返されるフィールドの数は EXPR の中で何回 PATTERN が マッチするかに依存します。 LIMIT
    を指定しないかゼロなら、末尾の空フィールドを捨ててしまいます (pop を行なうときには気を付
    けないといけません)。 LIMIT が負ならば、LIMIT に任意の大きな数を指定したのと同じことにな
    ります。 空文字列に評価される EXPR を分割する場合、LIMIT での指定に関わらず 常に空のリス
    トが返ることに注意してください。

    空文字列にマッチするパターン (ヌルパターン // と混同しないでください。 これは、空文字列に
    マッチするパターンの一つでしかありません) は、 どの場所にもマッチし、EXPR の値を1 文字ず
    つに分割します。 例えば:

        print join(':', split(/ */, 'hi there'));

    は、'h:i:t:h:e:r:e' という出力になります。

(以下略)

まあいやらしいっちゃあいやらしい仕様ですねえ> LIMIT に与える値で変わる振る舞い

■_

Is an open-source pacemaker safer than closed-source? - William Edwards, Coder
Friday, May 11, 2012

Is an open-source pacemaker safer than closed-source?

Richard Stallman recently collapsed; he's OK.  But it did of course get attention in the programming world.

For those not in the know, Richard - rms - is the leading light in the Free software movement
(Free as in ownership, not free as in no-cost) and he really divides programmers into the camps
- the minority who follow, the majority who admire without trying to understand, and the vocal
minority dead against him.

Now him collapsing raises an interesting question: if he needed a medical device that wasn't
running Free software, would he use it?

He answered a similar question once:

(以下略)

もし Stallman が不自由なソフトウェアで制御されている医療デバイスを必要とする事態になったら? で、どうなるかという仮定のお話

■_

2012年05月12日

■_

読書会後カレー

いぬ

■_ 可視化

日本の投手でこれやるとどんな感じになるか → Mariano Rivera's baseball prowess, illustrated with R | (R news & tutorials)

■_

C++ じゃなくて C を使ったのは~というページに対する反応が活発に Why should I have written ZeroMQ in C, not C++ | Hacker News Why should I have written ZeroMQ in C, not C++ : programming

こっちからもおもしろい(と思う)ものをピックアップしてみようかな。

■_ s

■_

channel9 の記事も結構翻訳して欲しいのあるんだよなあ (後ろ向き発言)。 いやまあ、PCに張り付いて動画再生見てるのがあまり好きじゃないってのがあるんだけど (それはいいPCを使っていないからかもしれない)。

Martin O. comments on Scala collections (Lang.NEXT 2012) : haskell

Here is an excerpt from the Expert Panel discussion at Lang.NEXT 2012.
This excerpt occur at approx. 16:40:

http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Panel-Web-and-Cloud-Programming

"Erik M.: So, Martin, there has been a lot of comments about the Scala libraries where
people say you need a Ph.D. to understand the types of, like, inserting into a collection.

Martin O.: So I really have to say that nothing could be futher from the truth. You 
can pick up Scala collections in half an hour. It will make you much more productive 
than anything else. It's precisely what Java wants with Java 8, so essentially we have 
it all today. And the point is - so the thing that gets me so upset is that we made a 
really big break through is Scala that we could have this amazing ease of use in 
purely functional collections, and we did it with some pretty clever types. But the 
users never sees the types. So the types are essentially hidden.
(略)
Which I think is precisely the wrong way. We worked very hard to get the right way, and
everyone says you need a Ph.D. to use it which is exactly the opposite from the truth
because that we did it to make is easier, not harder."

To the point that Martin makes at the end, how does Scala collections differ from the 
way collections are implemented in Haskell?

(note - transcription and any errors are mine)

The complexity of Scala's collections are an immediate result of the fact that they 

have to deal with the Liskov substitution principle as it applies to higher ordered 
types. This isn't something that you can resolve by better programming, the types are 
really just that complicated.

Note that Martin didn't answer the question of Erik: He asserted that you don't need a 
PhD to use Scala's collections. What Erik asked was whether you needed a PhD to 
understand them.

Personally, I don't think you quite need a PhD, but you need to spend a lot more time 
than you'd necessarily want learning about types, subtyping, and co and contravariance. 
You also have to deal with Scala's sort of nutty type level syntax.

There's also the issue that the Scala collections library has gone for the kitchen 
sink approach. Regardless of whether you have a PhD or not, you're gonna end up 
spending a lot of time figuring out what the classes you want exactly are.

結構興味深いやり取りも

2012年05月11日

■_

1250トンを吊り上げる国内最大級のキャタピラ移動式クレーン「CC8800」同人誌 - アキバBlog を買ってみた。

Amazon.co.jp: まつもとゆきひろ コードの未来: まつもと ゆきひろ: 本 を発見したので購入(本来の発売日はまだです)。

■_ What makes programming languages really powerful?

プログラミング言語を本当に強力にするもの

What makes programming languages really powerful? | sembera's coding thoughts

What makes programming languages really powerful?
Posted by Lukáš Šembera on May 9, 2012

It is quite common to hear discussions in programmers' circles about how wonderful programming
language X is because it has so cool features Y1, Y2, …, Yn and how unfortunate the
programmers in Z (Z != X) must be because their language doesn't have them. I always do my best
not to get involved because I don't find such discussions productive. Simply everyone should
use tools which suit the needs best. However, I would like to have a think about what actually
makes programming languages powerful and what only gives an impression of power.

プログラミング言語 X にはとても cool な機能 Y1, Y2,…があるのでとてもすばらしく、
そういった機能を持たない (X 以外の) Z でプログラムするプログラマーがいかに不運であるかを
プログラマー集まりで議論することはとてもよく耳にします。
わたしはそういった議論に巻き込まれないように常に注意をしています。
なぜならそういった議論は productive であるとは思えないからです。
ただ単に、誰もが必要なものに対して最も適切なツールを使うべきなのです。
しかしながらわたしは、プログラミング言語を強力にするもの、
an impression of power を与えるだけのものについて考えてみたいのです。
(略)

Copyright © 2012 sembera's coding thoughts | Powered by WordPress and zBench

■_ 火元

Why should I have written ZeroMQ in C, not C++ : programming やら Hacker news で結構盛り上がってます

Why should I have written ZeroMQ in C, not C++ - 250bpm

Why should I have written ZeroMQ in C, not C++

Just to be clear from the very beginning: This is not going to be a Torvalds-ish rant against
C++ from the point of view of die-hard C programmer.

I've been using C++ whole my professional career and it's still my language of choice when
doing most projects.

Naturally, when I started ZeroMQ project back in 2007, I've opted for C++. The main reasons were:

2007年に ZeroMQ プロジェクトを始めたときには C++ を選択していました。
その主な理由には以下のものがありました

    Library of data structures and algorithms (STL) is part of the language. With C I would
    have to either depend on a 3rd party library or had to write basic algorithms of my own in
    1970's manner.

    データ構造やアルゴリズムのライブラリ(STL) が言語の一部でした。
    C を使った場合、サードパーティのライブラリに依存するか、さもなければ
    1970年代のやり方でもって自分自身で基本的なアルゴリズムから書かなければなりませんでした。
    

    C++ enforces some basic consistency in the coding style. For example, having the implicit
    'this' parameter doesn't allow to pass pointer to the object being worked on using several
    disparate mechanisms as it often happens to be the case with C projects. Same applies to
    explicit marking of member variables as private and many other features of the language.

    C++ はコーディングスタイルにおけるいくつかの基本的な consistency を強制します。
    たとえば、
   オブジェクトへのポインターを渡すことが許されない暗黙の 'this' パラメータを持つことは


    メンバー変数を private として explicit にマーク付けすることや
    そのほかの言語機能も同様です。

    This point is actually a subset of the previous one, but it's worth of explicit mention:
    Implementing virtual functions in C is pretty complex and tends to be slightly different
    for each class which makes understanding and managing the code a pain.

    この項目は実際にはひとつ前のもののサブセットですが、はっきり言及しておく価値があるでしょう。
    C で仮想関数を実装することはとても複雑で、また、クラスごとにかなり異なるものとなる傾向があります。
    それはコードの理解と管理を苦痛なものにしてしまいます。


    And finally: Everybody loves destructors being invoked automatically at the end of the block.
    最後に: ブロックの最後で自動的にデストラクターが起動されるのがみんな好きだった

Now, almost 5 years later, I would like to publicly admit that using C++ was a poor choice and
explain why I believe it is so.

5年経った今、C++ を使うという publicly admit は poor choice だったと考えています。
そこでなぜそのように考えているのかを説明します。


First, it's important to take into account that ZeroMQ was intended to be a piece of 
infrastructure with continuous uptime. If should never fail and never exhibit undefined
behaviour. Thus, the error handling was of utmost importance. It had to be very explicit
and unforgiving.


C++ exceptions just didn't fill the bill. They are great for guaranteeing that program 
doesn't fail — just wrap the main function in try/catch block and you can handle all the
errors in a single place.

C++ の例外は単に fill the bill しません。
C++ の例外はプログラムが失敗しないということを満足するにはとても great です。
単に main 関数を try/catch ブロックでラップしてしまえば
すべてのエラーを一箇所でハンドリングできます。

However, what's great for avoiding straightforward failures becomes a nightmare when your
goal is to guarantee that no undefined behaviour happens. The decoupling between raising of
the exception and handling it, that makes avoiding failures so easy in C++, makes it
virtually impossible to guarantee that the program never runs info undefined behaviour.

けれども、failures を straightforward に除去するのに great なそれは
(ソフトウェアの)目標が未定義動作が生じることをなくすことである場合には悪夢となります。
例外の発生 (raising of the exception) とその処理を分離することは
C++ で failures の除去をとても簡単にしてしまっています。
そして、プログラムが決して未定義動作に落ち込まないことを保証するのを
事実上不可能にしています。

(略)

To summarise the above, I believe that requirement for fully-defined behaviour breaks the
object-oriented programming model. The reasoning is not specific to C++. It applies to any
object-oriented language with constructors and destructors.

以上のことをまとめると、fully-defined behaviour がオブジェクト指向プログラミングモデルを
壊してしまうとわたしは確信しているということです。
それは C++ に限ったものではありません。
コンストラクターとデストラクターを持ったオブジェクト指向言語すべてに言えることです。


Consequently is seems that object-oriented languages are better suited for the environments
where the need for rapid development beats the requirement for no undefined behaviour.

オブジェクト指向言語は未定義動作に対する requirement を beats する
rapid development が必要とされる環境に対しては better suited なようだ
というのが結論です。

There's no silver bullet here. The systems programming will have to live on with C.

ここ(オブジェクト指向プログラミング?) には銀の弾丸はありません。
システムプログラミングは C とともになければならないでしょう。


By the way, I've started experimenting with translating Crossroads I/O, the fork of ZeroMQ
that I am working on now, into C lately. The code looks great!

Martin Sústrik, May 10th, 2012

■_


一つ前へ 2012年5月(上旬)
一つ後へ 2012年5月(下旬)

ホームへ


リンクはご自由にどうぞ

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