ときどきの雑記帖 濫觴編

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

一つ前へ 2011年10月(上旬)
一つ後へ 2011年10月(下旬)

ホームへ

2011年10月20日

■_

今週も土曜日はまたいろいろ被ってるし

某球団の話は決着ついてから。

ってこのタイミングで宣言するか >むらたん

■_ Monad とは

どこかで聞いた言い回しだけど A monad is just a monoid in the category of endofunctors, what's the problem?

……endofunctor ってナニ?

http://wpedia.goo.ne.jp/enwiki/Endofunctor

Endofunctor: A functor that maps a category to itself.
  

あー。

haskell - A monad is just a monoid in the category of endofunctors, what's the problem? - Stack Overflow

    A monad is just a monoid in the category of endofunctors, what's the problem?

and on a less important note is this true and if so could you give an explanation (hopefully
one that can be understood by someone who doesn't have much haskell experience).

See "Categories for the Working Mathematician" 


You don't need to understand this to use monads in Haskell. From a practical perspective
they are just a clever way to pass around "state" through some underground plumbing.


That particularly phrasing is by James Iry, from his highly entertaining Brief, 
Incomplete and Mostly Wrong History of Programming Languages, in which he fictionally 
attributes it to Philip Wadler.

The original quote is from Saunders Mac Lane in Categories for the Working Mathematician,
one of the foundational texts of Category Theory. Here it is in context, which is probably
the best place to learn exactly what it means.

But, I'll take a stab. The original sentence is this:

    All told, a monad in X is just a monoid in the category of endofunctors of X, with 
    product × replaced by composition of endofunctors and unit set by the identity endofunctor.

X here is a category. Endofunctors are functors from a category to itself (which is usually
all Functors as far as functional programmers are concerned, since they're mostly dealing
with just one category; the category of types--but I digress). But you could imagine another
category which is the category of "endofunctors on X". This is a category in which
the objects are endofunctors and the morphisms are natural transformations.

And of those endofunctors, some of them might be monads. Which ones are monads? Just exactly
the ones which are monoidal in a particular sense. Instead of spelling out the exact mapping
from monads to monoids (since Mac Lane does that far better than I could hope to), I'll just
put their respective definitions side by side and let you compare:

A monoid is...

    * A set, S
    * An operation, • : S × S -> S
    * An element of S, e : 1 -> S

...satisfying these laws:

    * (a • b) • c = a • (b • c), for all a, b and c in S
    * e • a = a = a • e, for all a in S

A monad is...

    * An endofunctor, T : X -> X
    * A natural transformation, μ : T × T -> T, where × means functor composition
    * A natural transformation, η : I -> T, where I is the identity endofunctor on X

...satisfying these laws:

    * μ(μ(T × T) × T)) = μ(T × μ(T × T))
    * μ(η(T)) = T = μ(T(η))

With a bit of squinting you can probably see that both of these definitions are instances
of the same abstract concept (I think category theorists would say "monoid" is
the abstract term, and my definition of "monoid" above is overly specific since
it mentions sets and elements).

thanks for the explanation and thanks for the Brief, Incomplete and Mostly Wrong 
History of Programming Languages article. I thought it might be from there. Truly one 
of the greatest pieces of programming humor.


Intuitively, I think that what the fancy math vocabulary is saying is that:

Monoid

A monoid is a set of objects, and a method of combining them. Well known monoids are:

    * numbers you can add
    * lists you can concatenate
    * sets you can union"

      There are more complex examples also.

Further, Every monoid has an identity, which is that "no-op" element that has no
effect when you combine it with something else:

    * 0 + 7 == 7 + 0 == 7
    * [] ++ [1,2,3] == [1,2,3] ++ [] == [1,2,3]
    * {} union {apple} == {apple} union {} == {apple}

Finally, a monoid must be associative. (you can reduce a long string of combinations anyway
you want, as long as you don't change the left-to-right-order of objects) Addition is OK
((5+3)+1 == 5+(3+1)), but subtraction isn't ((5-3)-1 != 5-(3-1)).

Monad

Now, let's consider a special kind of set and a special way of combining objects.

Objects

Suppose your set contains objects of a special kind: functions. And these functions have
an interesting signature: They don't carry numbers to numbers, or strings strings. Each
function carries a number to a list of numbers, in a two-step process.

   1. Compute 0 or more results
   2. Combine those results unto a single answer somehow.

Examples:

    * 1 -> [1] (just wrap the input)
    * 1 -> [] (discard the input ,wrap the nothingness in a list)
    * 1 -> [2] (add 1 to the input, and wrap the result)
    * 3 -> [4, 6] (add 1, and mutiply by 2, and wrap the multiple results)

Combining Objects

Also, our way of combining functions is special. A simple way to combine function is
composition: Let's take our examples above, and compose each function with itself:

    * 1 -> [1] -> [[1]] (wrap the input, twice)
    * 1 -> [] -> [] (discard the input, wrap the nothingness in a list, twice)
    * 1 -> [2] -> [ UH-OH! ] (we can't "add 1" to a list!")
    * 3 -> [4, 6] -> [ UH-OH! ] (we can't add 1 a list!)

Without getting to much into type theory, the point is that you can combine two integers
to get an integer, but you can't always compose two functions and get a function of the
same type. (Function with type a -> a will compose, but a-> [a] won't.)

So, let's define a different way of combining functions. When we combine two of these 
functions, we don't want to "double-wrap" the results.

Here is what we do. When we want to combine two functions F and G, we follow this 
process (called binding):

   1. Compute the "results" from F, but don't combine them.
   2. Compute the results from applying G to each of F's results separately, yielding a
      collection of collection of results.
   3. Flatten the 2-level collection, and combine all the results.

Back to our examples, let's combine (bind) a function with itself, using this new way 
of "binding" function:

    * 1 -> [1] -> [1] (wrap the input, twice)
    * 1 -> [] -> [] (discard the input, wrap the nothingness in a list, twice)
    * 1 -> [2] -> [ 3 ] (add 1, then add 1 again, and wrap the result.)
    * 3 -> [4,6] -> [ 5,10, 7,14] (add 1 and multiply by 2, keeping both results,
      then do it all again to both results, and the wrap the final results in a list.)

This more sophisticated way of combining functions is associative (following from how 
function composition is associative when you aren't doing the fancy wrapping stuff).

Tying it all together,

    * a monad is a structure that defines a way to combine functions,
    * analogously to how a monoid is a structure that defines a way to combine objects,
    * where the method of combination is associative,
    * and where there is a special 'No-op' that can be combined with any Something to
      result in Something unchanged.

Notes

There are lots of ways to "wrap" results. You can make a list, or a set, or 
discard all but the first result while noting if there are no results, attach a sidecar
of state, print a log message, etc, etc.

I've played a bit loose with the definitions, in hopes of getting the essential idea 
across intuitively.

I've simplified things a bit by insisting that our monad operate on functions of type
a -> [a]. In fact, monads work on functions of type a -> m b , but the generalization
is kind of a technical detail that isn't the main insight.

Best explanation I've read. I finally think I'm starting to get this, after 3 years 
pottering with Haskell every few months. 


site design / logo © 2011 stack exchange inc; user contributions licensed under cc-wiki with attribution required

なんかこう、わかったようなわからないような(ということはわかってない)…

■_

reddit に飛び火

A monad is just a monoid in the category of endofunctors, what's the problem? (StackOverflow) : programming

A monad is just a monoid in the category of endofunctors, what's the problem? (StackOverflow) (stackoverflow.com)


The only thing you have to remember about monads is that monads are like burritos.


Actually, there is a category where the objects are categories and the arrows are functors.


And even more, there's a category where the objects are functors, and the arrows are 
natural transformations.

    why do functors have to be defined as a different kind of thing than the objects themselves?

They are not. A functor is an "arrow" in a category where "objects" 
are categories themselves. It is just a special case.


The monad and monoid abstractions are nothing to do with the optimizations done by 
compilers for languages like Haskell. In fact, I know that GHC does no optimizations 
specific to these things. Side effect free programming (i.e immutable data) typically 
only adds a log cost to most operations (depending on data structure), and the real 
benefit of such programming models is concurrency. Are you sure you know what you're 
talking about?


Now I'm scared of Haskell. :(


Don't be - it's a joke (albeit a fine definition too).

Monads are just a design pattern, like the ones you find in object oriented 
programming, albeit a very general one with strong theoretical backing. You can think 
of it as a programmable semicolon.

There are plenty more of these concepts in Haskell (monoids, functors, etc.), and they 
are really quite simple. The only scary part is that they lend their name from 
category theory.

Everyone knows Haskell was a typo, it was meant to be called AskHell.


FWIW, I actually think category theory is a great tool to teach program design. Most 
algebra usually deals with fairly simple structures, whereas category theory is the 
mathematics of abstraction. In my anecdotal experience, learning some category theory 
actually made me design my programs better, even (or especially) in OO languages. 
There is even some overlap with popular design patterns and algebraic or category 
theory concepts (composite pattern being the most obvious, throw higher order 
functions into the mix and you can find many more).

海の向こうでもこのネタで盛り上がるのねえ

■_


Programming Languages: What tool is right for which job?
http://therighttool.hammerprinciple.com/

C++ Language Tutorial (pdf). These tutorials explain the C++ language from its basics up to the newest features of ANSI-C++, including basic concepts such as arrays or classes and advanced concepts such as polymorphism or templates. : programming
http://www.reddit.com/r/programming/comments/lh8n8/c_language_tutorial_pdf_these_tutorials_explain/
http://www.cplusplus.com/files/tutorial.pdf

InfoQ: The Story of Read-Only Collection Interfaces in .NET
http://www.infoq.com/news/2011/10/ReadOnly-WInRT

人材育成と事例研究は悪党の隠れ家 - 記者の眼:ITpro
http://itpro.nikkeibp.co.jp/article/Watcher/20111018/370971/

■_ あなたが悪いプログラマーであることの兆候

結構ボリュームがあった(ので訳してる余裕がががが)

Signs that you're a bad programmer - Software Engineering Tips
Signs that you're a bad programmer

1. Inability to reason about code

Reasoning about code means being able to follow the execution path ("running the 
program in your head") while knowing what the goal of the code is.

Symptoms

  The presence of "voodoo code", or code that has no effect on the goal of the
  program but is diligently maintained anyway (such as initializing variables that are
  never used, calling functions that are irrelevant to the goal, producing output that is
  not used, etc.)

  Executing idempotent functions multiple times (eg: calling the save() function multiple
  times "just to be sure")

  Fixing bugs by writing code that overwrites the result of the faulty code

  "Yo-Yo code" that converts a value into a different representation, then 
  converts it back to where it started (eg: converting a decimal into a string and then 
  back into a decimal, or padding a string and then trimming it)

  "Bulldozer code" that gives the appearance of refactoring by breaking out chunks
  into subroutines, but that are impossible to reuse in another context (very high cohesion)

■_

あー、もういろいろ追いつかない

2011年10月19日

■_

ほかの人の、何かに対する dis りを見て自分のやり方を振り返ってみたり。

■_

また別の言語リスト。

fogus: Programming language development: the past 5 years

Programming language development: the past 5 years

Oct 18, 2011

I recently compiled a list of Perlis Languages that were meant to illustrate varying 
paradigms not typically found in mainstream programming languages. Those languages 
were meant to stretch your mind and are not necessarily representative of the state of 
the art in language design and implementation. In this post I will provide a list of 
fairly new languages (let's say 5 years with a little flex) that display1 interesting 
features and display higher-order thinking in the way that they tend toward an 
evolution of past learnings in programming language thinking. Not all of these 
languages enjoy active development, but the more important point is that they 
represent in some way “new language thinking”. Remember that this goal does not 
necessarily mean “innovative”.

Unlike my Perlis post, I have not fully explored all of the languages below, so caveat 
emptor. Please correct me if I misrepresent something. No meaning behind the ordering 
implied.

take the associated poll!

Shen

released: 2011, author: Dr. Mark Tarver

I included the fantastic language Qi in my Perlis Languages post, so it may seem gratuitous
to include its successor Shen here. In fact Shen and Qi offer most of (all of?) the same
high-level features:

    * A Lisp
    * Optional static typing
    * Pattern matching with guards
    * Macros
    * Partial application
    * Function backtracking
    * Builtin Prolog
    * Builtin compiler compiler

However, Shen is indeed the next evolutionary step after Qi. Shen builds on the ideas in Qi
in various ways, but the primary motivating force is targetability. What exactly does that
mean? The precursor Qi was built to target Common Lisp as its host language and did so to
maximum effect. However, Qi was found to target a very small subset of Common Lisp.
Therefore, Dr. Tarver devised the idea that the predecessor Shen should be defined in terms
of a minimal kernel Lisp language called Kl which would, in theory, provide an easier port
target across various runtime hosts, including, but not limited to: JavaScript, Python,
Clojure, and Common Lisp. I have been thinking of “kernel Lisps” a lot and so Shen is ripe
with ideas.

An example of a member function using the embedded Prolog:

組み込み Prolog を使ったメンバー関数の例:

  (defprolog member
    X [X | _] <--;
    X [_ | Y] <-- (member X Y);)

  (prolog? (member 1 [1 2 3]))
  /*=> true */

Partial application is automatic (simplified below):

  (* 2)
  /*=> #<FUNCTION LAMBDA (x) (* 2 x)>

  ((* 2) 54)
  /*=> 108 */

Here is a function that calculates the nth triangle number:

  (define triangle
    0 -> 0
    N -> (+ N (triangle (- N 1))))

  (triangle 100)
  /*=> 5050 */

And a typed version of the same:

  (tc +)  /* turn on type-checking */

  (define triangle
    {number --> number}
    0 -> 0
    N -> (+ N (triangle (- N 1))))

  (triangle 5)
  /*=> 15 : number */

  (triangle a)    
  /* type error */

Shen is a natural evolutionary step along the long, winding path that is Lisp history. 
Many modern programming languages are absorbing features that Lisp innovated long ago, 
but still the most exciting languages are Lisps.

Agda 2

released: 2009, author: Ulf Norel

I've yet to truly wrap my head around Agda (any year now), but I can say a few things 
about it. First, Agda is a purely functional, pattern matching, dependently typed 
programming language that walks the thin border adjacent to proof assistants. In 
dependently typed languages, type expressions can contain (depend on) a program 
expression. Therefore, the resolution of type constraints is a function of code or 
predicated on values. It's like a kick in the face. As an added bonus, the Agda type 
language is the same as the value language (i.e. the programming language itself). 
What this means is that type invariants in Agda can express a much wider spectrum of 
constraints than typically attributed to static type systems; for example, a list type 
that statically guarantees sorted order (PDF). There's a drop-kick for you.

Here is an encoding of even and odd numbers in the Agda type system:

Agda の型システムにおける偶数と奇数の encoding の例です:

  data Nat : Set where
    zero : Nat
    suc  : Nat -> Nat
  
  fortyTwo : Nat
  fortyTwo = 42
  
  plus : Nat -> Nat -> Nat
  plus  zero   m = m
  plus (suc n) m = suc (plus n m)
  
  mutual
    even : Nat -> Bool
    even zero    = true
    even (suc n) = odd n
  
    odd : Nat -> Bool
    odd zero    = false
    odd (suc n) = even n
  
The previous code defines two datatypes: 1) the natural numbers and 2) the even 
natural numbers. You can also define type functions as infix operators:

上記のコードは二つのデータ型を定義しています:
1) 自然数
2) 偶数である自然数
同様に中置演算子として関数を定義できます:


  _+_ : Nat -> Nat -> Nat
  zero  + m = m
  suc n + m = suc (n + m)
  
This represents the extent of my understanding about Agda so far. While it would be 
nice to know more, what I've seen is amazing enough to warrant inclusion.


Ioke

released: 2008, author: Ola Bini

Ola Bini's Ioke is based on a simple question: what kind of language can you build if 
you completely disregard performance and instead focus on expressivity? As it turns 
out you gain incredible expressiveness as shown in Bini's presentation series (links 
below). One of the more interesting aspects of Ioke is that it is a homoiconic 
language providing macros.

  myfor = dsyntax(
  "takes a name, an enumerable, and a transforming expr
  and returns the result of transforming each entry in 
  expression, with the current value of the enumerable
  bound to the name given as the first argument",

    [argName, enumerable, argCode]

    ''(`enumerable map(`argName, `argCode))
  )

  myfor(x, 1..5, x*2) 
  ;=> [2,4,6,8,10]

Another advantage in studying Ioke is my own personal first axiom:

    When brilliant people create things, study them.

As programmers the onus is on us to push our skills to the point of uncomfortableness. 
Studying the works of great minds is a highly effective way to do this.

More resources

    * Ioke
    * Ioke: a Folding Language (video)
    * Ioke Wiki
    * Announcement
    * Source
    * Macro types in Ioke – or: What is a dmacro?

Pure

released: 2008, author: Albert Gräf

Pure is a functional language built around term rewriting. Term rewriting is very 
similar to what we did in high-school algebra using the FOIL method:

Pure は項の書き換え (term rewriting) を中心とした関数型の言語です。
項の書き換えはわたしたちが高校の代数で FOIL method を使って
行っていたことと非常に似ています。

  (x1 + y1) * (x2 + y2) = 
    (x1 * x2) +            // First
    (x1 * y2) +            // Outer 
    (y1 * x2) +            // Inner 
    (y1 * y2);             // Last

The code above defines the steps needles to transform the multiplication of two 
binomials into the FOIL steps. Testing this rewrite rule yields:

  (x + 3) * (x + 5);
  //=> x*x+x*5+3*x+15

Now you might expect that the answer would be x^2 + 8*x + 15, but there are missing 
reductions in the definition:

  x*x = x^2;

  (x + 3) * (x + 5);
  //=> x^2+x*5+3*x+15

That is close enough for me. :-)

A more complex example would be a function to reduce a number to its prime factors:

  factor n = factor 2 n with
    factor k n = k : factor k (n div k) if n mod k == 0;
           = if n>1 then [n] else [] if k*k>n;
           = factor (k+1) n if k==2;
           = factor (k+2) n otherwise;
  end;

  factor 138;
  //=> [2,3,23]

Of the languages listed in this post, I am most blown away lately by Pure.

More resources

    * Pure wiki
    * Interview With Albert Gräf
    * Term Rewriting and All That
    * Source

Go

released: 2009, authors: Robert Griesemer, Rob Pike, and Ken Thompson

ざくっと略

What's next?

There have been even more recent developments in programming language design and 
development, but in most cases I've only tweet-sized impressions to offer.

    * Dart
          o Remember the first axiom
          o Seems poised for maximal adoption
    * Rust
          o Seems in the vein of D
          o Remember the first axiom
    * Ceylon
          o Not sure what this provides for a Java team with solid conventions
    * Kotlin
          o Built from the IDE down
    * Newspeak
          o smalltalk plus: FloatD epsilon.
    * Perl6
          o Since I'm not a Perl programmer I don't mind waiting
    * Magpie
          o Best langdev “blog” ever
          o Sadly have not had a chance to explore the source
          o By one of the Dart devs
          o thanks to Tracy Harms for the reminder

略


Copyright © 2002 - 2011 by Fogus (license information)

■_ Ada

how is Ada a 'safety critical' language? - Stack Overflow

I tried googling and read some snippets online. Why is ada a "safety critical" language?
Some things i notice are

    * No pointers
      ポインターがない

    * Specify a range (this type is an int but can only be 1-12)
      範囲の指定 (型がintだけど1-12に限るとか)

    * Explicitly state if a func member is out or in/out
      

    * Foreach loops (To avoid bound errors or bound checking)
      (範囲エラーや範囲チェックを取り除くための) foreach ループ

The rest of the syntax i either didnt understand or didnt see how it help to be 'safety critical'.
These are some points but i dont see the big picture. Does it have design by contract that i
am not seeing? Does it have rules that make it harder for code to compile (and if so what are
some?) Why is it a 'safety critical' language?


I think it has to be looked at in comparative fashion to answer that question. Compare it
to C (less restrictive all about) and then to Haskell (more restrictive in some cases, less
in others [without becoming complicated ;-]), for instance.


Because a government committee said so. 

政府の委員会がそう言ったから。


Ada does have pointers; it calls them "access types". 

Ada にもポインターはあって、それは“access types”と呼ばれています。

For even more safety critical systems, use SPARK. It's a subset of Ada with annotations
for additional checks: en.wikipedia.org/wiki/SPARK


All of those are good for safety-critical application; but consider also the ability 
to assign a layout (down to the bits) and the ability to [optionally] specify that 
such a record can ONLY be at a certain location (useful for things like video-memory 
mappings).

Consider that a lot of safety-critical applications are also without standard (in the 
senses both of "wide-spread" and of forward-comparability) interfaces; 
example: nuclear reactors, rocket engines (the engineering itself differs from 
generation to generation*), models-of-aircraft.

The upcoming Ada 2012 standard DOES have actual contracts, in the form of pre- and 
post-conditions; example (taken from 
http://www2.adacore.com/wp-content/uploads/2006/03/Ada2012_Rational_Introducion.pdf ):

将来の Ada 2012 standard には actual contracts があります。
これは事前条件と事後条件の form で、例を挙げると

  generic
     type Item is private;
  package Stacks is
  
  type Stack is private;
  
  function Is_Empty(S: Stack) return Boolean;
  function Is_Full(S: Stack) return Boolean;
  
  procedure Push(S: in out Stack; X: in Item)
  with
      Pre => not Is_Full(S),
      Post => not Is_Empty(S);
  
  procedure Pop(S: in out Stack; X: out Item)
  with
      Pre => not Is_Empty(S),
      Post => not Is_Full(S);
  
  Stack_Error: exception;
  
  private
   -- Private portion.
  end Stacks;
  
Also, another thing that gets glossed over, is the ability to exclude Null from your 
Access/pointer types; this is useful in that you can a) specify that exclusion in your 
subprogram parameters, and b) to streamline your algorithm [since you don't have to 
check for null at every instance-of-use], and c) letting your exception handler handle 
the (I assume) exceptional circumstance of a Null.

* The Arianne 5 disaster occurred precisely because the management disregarded this 
fact and had the programmers use the incorrect specifications: that of the Arianne 4.

site design / logo © 2011 stack exchange inc; user contributions licensed under cc-wiki with attribution required

■_ Why A + B != A - (-B)

Why A + B != A - (-B)
 
Why A + B != A - (-B)

21.12.2009 Andrey Karpov

While developing Viva64 analyzer intended for detecting 64-bit errors, I sometimes 
encounter interesting ways of code behavior. I would like to show you one example that 
is not very interesting practically but might be helpful in understanding more 
complicated cases.

  char *A = "123456789";
  unsigned B = 1;
  char *X = A + B; // X: "23456789"
  char *Y = A - (-B); // Y: <Bad Ptr>

If we compile the 32-bit version of the code, the expressions "A + B" and 
"A - (-B)" will be equivalent. In the 32-bit code, the pointers X and Y 
point to the second item of the array A. To understand it better look at the Figure 1 
showing the process of calculating "A - (-B)".

このコードの32ビットバージョンをコンパイルした場合には、式 “A + B” と
“A - (-B)”は等しくなります。32ビットコードでは、ポインター X とポインター Y が
指しているものは配列 A の二番目の要素です。

解説部分は略

Conclusion:
結論

You should avoid using unsigned data types to store negative values. If the variables 
used to access array items can take negative values, use only signed data types, for 
example "int". Or rather use the types size_t and ptrdfiff_t.

負の値を格納するために無符号のデータ型を使うのは避けるべきです。
配列要素にアクセスするのに使われる変数が負の値になる可能性があるのなら、
int のような符号つきデータ型だけを使いましょう。あるいは、
size_t や ptrdiff_t を使いましょう。

© 2008 - 2011, OOO "Program Verification Systems"

■_

Perl traps for Python Programmers | brian d foy [blogs.perl.org]

Perl traps for Python Programmers
Python プログラマーに対する Perl のわな

By brian d foy on October 18, 2011 3:00 AM

I'm updating the Camel. Chapter 24 has short sections for people moving from one 
language to the next. Right now I'm working on the Python section. My Python is rusty. 
If you started in Python and moved to Perl, I'd like to hear about the gotchas that 
you didn't expect.

This is absolutely not a platform for bashing another language. I don't care about any 
of that. I don't care why the readers want to use Perl or why they want to use Python. 
I care about people who are used to doing something one way in Python and might be 
surprised why that's not obvious or apparent in Perl.

Here's some things I have so far, which I just cut from our own pseudopod:

=head1 Python Traps XXX: Still might not be in the book

Perl and Python come from common roots, and even came out at the same time
(1987 and 1991), and Perl even stole Python's object system.


=for TODO
http://wiki.python.org/moin/PerlPhrasebook

X<variables;Perl vs. Python, names of>
Variables begin with C<$>, C<@>, or C<%> in Perl.

Perl では変数は $, @, % のいずれかかで始まります。


=item *


Many functions take default arguments or have default behavior. See A<29>.

(Perl では)多くの関数がデフォルト引数を取っていたり、デフォルトの振る舞いが決まっています。


=item *


The last-evaluated expression is the return value.
最後に評価された式は戻り値です。


=item *


Perl's


=item *


Use C<say> if you want an implicit newline on the end of each output.

各出力の末尾で暗黙のうちに改行したいのなら、“say” を使います。


=item *


Perl has object features, but it is not an object-oriented language
where everything has methods.

Perl はオブジェクトの機構を備えていますが、それはすべてがメソッドを持っている
ようなオブジェクト指向言語のそれではありません。


In Perl, you call a function with arguments:


  my $string = join('|', qw(Python Perl Ruby) );


In Python, there's likely a main argument with a method to do it:


  new = '|'.join(['Python', 'Perl', 'Ruby'])


=item *


Perl's match operator floats unless you anchor your patten. Python's
C<re.match()> only matches at the beginning of a line, although
C<re.search()> has an implicit C<.*> at the beginning of the pattern.

Perl のマッチ演算子は、パターンでアンカーを使わない限りは float です。
Python の re.match() は行の先頭にしかマッチしません。
一方 re.search() はパターンの先頭に暗黙の ".*" を持っています。

=item *


XXX: Python's dictionaries are Perl's hashes


=item *


In most cases, Perl does not implicitly dereference things (although
Perl 5.12 does for some uses of the array and hash operators).


=item *


Perl can interpolate variable directly into double-quoted strings,
but you can use C<sprintf>

Perl はダブルクォートでくくられた文字列で直接変数を interpolate できますが、
sprintf を使うこともできます


=item *


Perl's strings aren't arrays of characters, so you can't use array
operators on them.

Perl の文字列は文字の配列ではありません。そのため文字列に対して
配列演算子を使うことはできません。


=item *


Perl's system calls don't automatically throw exceptions, but you
can use M<autodie> to do that.

Perl のシステムコールは自動的に例外を送出しませんが、autodie を使って
例外を送出するようにできます。


=item *


Python lets you name your arguments in the function signature. In
Perl you have to do that yourself:

Python は関数の signature で引数に名前をつけます。
Pelr では自分でそれを行わなければなりません


  sub R<METHOD> {
    my ($self, @args) = @_;
  }


=item *


Perl doesn't have lists of lists, but it can have a list of array references.

Perl にはリストのリストはありませんが、配列リファレンスのリストを持てます。


=item *


Perl's range operator is inclusive on both sides, so C<0..9> includes C<0> and C<9>.

Perl の範囲演算子はその両端で inclusive です。
したがって 0..9 は 0 も 9 も含みます

=item *


To overload operators for your objects, use the M<overload> pragma.

自分のオブジェクトに対して演算子をオーバーロードするには
overload プラグマを使います。

■_

2011年10月18日

■_

足らぬ足らぬは工夫が足らぬ。とはいうものの、そればっか言われていると 「精神力で云々」と同じじゃねーかという気がしてきた今日この頃。

■_

■_ Why not Haskell?

Tech Notes: Why not Haskell?

■_ Your First C Program

わたしが C で一番最初に書いたプログラムは (hello, world なんかを除けば) タブコードを適切なスペースに置き換えるやつだったなあ。 detab って名前。

Your First C Program « Sutter's Mill

Your First C Program

2011-10-16 by Herb Sutter

As a tribute in honor of Dennis Ritchie's passing, I'd like to invite you to share 
your thoughts in this post's comments about your first C program – either the code if 
you remember it approximately, or a story about when you wrote it.

Here's mine.

I wrote my first C program in 1988 as a lab assignment for a fourth-year course in 
computer graphics at the University of Waterloo.
In the first day or two of the course, 
our prof gave us our first assignment: Write a program that displays and controls a 3D 
animated robot with moving head, arms, and legs. Successive assignments would let us 
swoop around him, controlling point of view and zoom with a mouse, and other nifty 
features, but the first assignment was just to get him on-screen and capable of a 
little basic motion.

わたしは自分の最初の C プログラムを、1988年の University of Waterloo における
lab assignment for a fourth-year course in computer graphics として書きました。
そのコースの一日目か二日目に、教授が最初のassignment を
わたしたちに出しました:
プログラムを書け
3D 


Oh, and the program was to be written:

    * to run on one of the lab's four brand-new SGI IRIS workstations (oh, here's the manual);

    * using a custom UofW internal library (oh, here's the manual);

    * in C (we assume you know it, use man to learn this compiler's command line switches if you need to);
      C で

and it's due in a few days. I can't remember exactly now, but I think we had something 
like five days. After all, this was just a warm-up initial exercise for the course.

今となっては正確なところは思い出せないのですが、五日間ほどではなかったかと思います。
結局のところ、これはこのコースにおける単なるウォームアップの initial exercise に過ぎませんでした。


Here's the thing: I had never used C. Never even seen it.

わたしはそれまでCを使ったことなどなかったし、見たことすらありませんでした。

Oh, I'd used many different languages in my undergrad career, from Cobol to Pascal to 
Prolog to 6809 assembler and many points between, but just never C. Don't get the 
wrong impression, C was already used widely at UofW at the time and most of the other 
undergrads in the class knew it, but by some freak of course selection combined with 
professor allocation I somehow had managed to come across pretty much everything but C 
so far for the first three years.

わたしの unddergrad career のいて多くの異なる言語を使ってはいました。
COBOL に始まり、Pascal、Prolog、6809 アセンブラー、等々。
しかし C は使ったことがありませんでした。



Fortunately, there was K&R.

幸運にも、手元には K & R がありました。

Armed with K&R and a printed-out C tutorial, I had a few days to learn a new 
language (huh? whaddayamean #include? oh, okay…), an unfamiliar compiler, an 
unfamiliar graphics library, and the quirks of this particular flavor of Unix – to 
produce a working program in an unfamiliar domain with unfamiliar concepts (graphics). 
And only that last bit was the actual topic material for the course. The language, 
compiler, library, etc. was just uninteresting scaffolding you were expected to know 
or just pick up on the fly, don't bother the professor with questions about those when 
you can look it all up yourself.

慣れないコンセプトと領域で working program を作るために、
K &R と印刷されたチュートリアルを手に、わたしは新しい言語、なじみのないコンパイラーと
グラフィクスライブラリ、そして quirks of this particular flavor of Unix を数日間勉強しました。
And only that last bit was the actual topic material for the course.
The language, compiler, library, etc. was just uninteresting scaffolding you were
expected to know or just pick up on the fly, don't bother the professor with questions
about those when you can look it all up yourself.


I don't remember what mark I got on the assignment, but the code worked.

その assignment でわたしが得た mark を思い出すことはできませんが、コードは動きました。

I was glad that C was easy to learn, and that its manual in the form of K&R was so 
clear to read and understand.

わたしは C がとても学びやすく、また、K&R がマニュアルとして読んで理解するのに
とても明快なものであることが嬉しかったのです。

Thanks again, Dennis.

もう一度ありがとう、Dennis。

■_

2000 Interview: Dennis Ritchie, Bjarne Stroustrup, and James Gosling « Sutter's Mill

2000 Interview: Dennis Ritchie, Bjarne Stroustrup, and James Gosling

2011-10-13 by Herb Sutter

Ritchie, Stroustrup, and Gosling

Dennis Ritchie gave very few interviews, but I was lucky enough to be able to get one of them.

Denis Ritchie はめったにインタビューに応じなかったのですが、幸運にもインタビューのひとつを
目にすることができました。

Back in 2000, when I was editor of C++ Report, I interviewed the creators of C, C++, 
and Java all together:

2000年にわたしが C++ Report の編集者であった頃、わたしは C、C++、Java の creator たちが
一堂に会した場でインタビューしたのです


    The C Family of Languages: Interview with Dennis Ritchie, Bjarne Stroustrup, and James Gosling

    This article appeared in Java Report, 5(7), July 2000 and C++ Report, 12(7), July/August 2000.

Their extensive comments — on everything from language history and design (of course) 
and industry context and crystal-ball prognostication, to personal preferences and war 
stories and the first code they ever wrote — are well worth re-reading and remarkably 
current now, some 11 years on.

As far as I know, it's the only time these three have spoken together. It's also the 
only time a feature article ran simultaneously in both C++ Report and Java Report.

わたしの知る限りではこれは、この三人が集まって話をした唯一の機会です。
そしてまた、

Grab a cup of coffee, fire up your tablet, and enjoy.

このインタビューって日本語訳がなかったっけ?

■_

■_ おや

ここにも APL の名が

prog21: Papers from the Lost Culture of Array Languages

Papers from the Lost Culture of Array Languages

2012 is the 50th anniversary of Ken Iverson's A Programming Language, which described 
the notation that became APL (even though a machine executable version of APL didn't 
exist yet). Since then there's been APL2, Nial, A+, K, Q, and other array-oriented 
languages. Iverson (1920-2004) teamed with Roger Hui to create a modern successor to 
APL, tersely named J, in the late 1980s.

2012 年は、APL となった記法を説明した
Ken Iverson の A Programming Lanaguage の50周年です。
(その時点では APL の機会実行可能なバージョンは存在していませんでした)
以来、APL2、Nial、A+、K、Q などといった配列指向言語が現れました。
Iverson (1920ー2004) は Roger Hui とチームを組んで
APL の modern successor を作り、それは J と名づけられて 1980年代終盤に登場しました。

The culture of array languages is a curious one. Though largely functional, array languages
represent a separate evolutionary timeline from the lambda calculus languages like Miranda
and Haskell. (Trivia: The world monad is an important term in both Haskell and J, but has
completely different meanings.) Most strikingly, while Haskell was more of a testbed for
functional language theorists that eventually became viable for commercial products, array
languages found favor as serious development tools early on. Even today, K is used to
analyze large data sets, such as from the stock market. J is used in actuarial work.

配列言語の文化というものは curious なものです。
概ね関数的であるにも関わらず、
配列言語はλ算法言語とは
Miranda や Haskell のような

今日においてさえ、K は株式市場のデータのような大規模なデータセットの解析に用いられています
J は acturial work で使われています。

Notation as a Tool of Thought, Ken Iverson's 1979 Turing Award Lecture, is the most 
widely read paper on APL. Donald McIntyre (1923-2009) explored similar ideas in 
Language as an Intellectual Tool: From Hieroglyphics to APL. When I first learned of 
McIntyre's paper roughly ten years ago, it wasn't available on the web. I inquired 
about it via email, and he said he'd see if he or one of his acquaintances had a copy 
they could send to me. A week later I received an envelope from Ken Iverson (!) 
containing non-photocopied reprints of Hieroglyphics and his own A Personal View of 
APL. I still have both papers in the original envelope.

思考の道具としての記法はAPLに関して最も広く読まれた論文で、これは
Ken Iversion の 1979年度チューリング賞の Lecture です。
Donald McIntyre は同様のアイデアを 
Language as an Intellectual Tool: From Hieroglyphics to APL.
で展開しています。
わたしが初めて McIntyre の論文を十年ほど前に読んだときには web にはありませんでした。
わたしはそれを eメールで送ってもらうようお願いしたところ、
彼自身か、彼の acquaintaces の誰かがコピーを持っていたらわたしに送ってくれると
彼は返事をしてくれました。
一週間の後、わたしは Ken Iverson (!) からの封筒を受け取りました。
そこには Hieroglyphics と his own A Personal View of APL の reprint が収められていました。
わたしはその両方の論文を今でもそのときの封筒に入れて持っています。

Donald McIntyre also wrote The Role of Composition in Computer Programming, which is 
mind-melting. (Note that it uses an earlier version of J, so you can't always just cut 
and paste into the J interpreter.)

There's a touch of melancholy to this huge body- -fifty years' worth- -of ideas and 
thought. Fifty years of a culture surrounding a paradigm that's seen as an oddity in 
the history of computing. Even if you found the other papers I've mentioned to be so 
many unintelligible squiggles, read Keith Smillie's My Life with Array Languages. It 
covers a thirty-seven year span of programming in APL, Nial, and J that started in 
1968.

(If you liked this, you might enjoy Want to Write a Compiler? Just Read These Two Papers.)


■_

2011年10月17日

■_

おお、今回はこれか。 ASCII.jp:CPU黒歴史 対Pentiumのために放棄されたAm29000|ロードマップでわかる!当世プロセッサー事情

いじってて結構面白い石でしたよ。うん。 メーカーのサポートは(ぴー)だったけど。

■_

It's Not Too Late to Learn How to Code | [Jean Hsu]

It's Not Too Late to Learn How to Code
コーディングの仕方を学ぶのに遅すぎではない

Coding is sort of like a superpower; with it you can create things that millions of people
see. You can change the way people behave, the way they think, and the way they interact
with others. This is beyond awesome, but I've also met a lot of people that think that
this ability is inaccessible to them. I've met a lot of “non-technical” people who seem
to think that this superpower is only bestowed on those fortunate enough to have it come
easily to them at a very early age.

I took two Computer Science courses in high school, and I'm fairly confident that had it
not been for those classes, I would have been way way too intimidated to major in it in
college. Those who major in CS with no pre-college programming experience get my greatest
respect, because even with a few classes under your belt, it can feel extremely daunting.

わたしは高校でコンピューター科学のコースを二つ履修し、


Beyond college, I've spoken to several friends who have expressed the same sentiment to me.
They wish they had known how important it was, how many opportunities being “technical”
opens up, and wished they had learned to code. They always say this with a wistful
attitude that implies that they assume it's too late. They are around my age, 24 to 25.

It's easy to think that it's too late, because look at those people who spent four years
in college learning to code! But those four years I spent in college learning CS? The
first two I spent trying to figure out what to major in. Over the next two years I took
eight courses in the department, but many have no direct relation to applications-focused
programming, which I assume is what most people want to do. In my entire four years at
college, I took only one class that was applications-focused. Going into it, I had no
practical knowledge of HTML or CSS, but worked with two other similarly inexperienced
students to build a webapp with MySQL, PHP and HTML/CSS.


It's easy to think that it's too late. There will almost always be people who have more
experience, but it's important to remember that every one of those people started off as
a complete beginner.

遅すぎたと考えるのは簡単なことです。
何をするにしても、ほとんどのことにはより経験をつんだ人たちがいます。
しかし重要なのは、そういった人であっても一人の例外もなく完全な初心者から
始めたのだということを忘れないことです。

So if you've been thinking to yourself “I wish I had learned to code,” why not do it? 
When you do, please keep some things in mind:

ですからもし、あなたが“もっとコーディングを学んでおけば良かった”と考えたことがあるのなら、
なぜそうしないのでしょうか? コーディングの勉強をするのなら、いくつか心に留めておいてほしいことがあります:


    * It is difficult! Things that take awhile at first will come naturally to you later
      on. Of course some people are more naturally disposed toward the type of logical 
      thinking that programming demands, but I believe that in the majority of cases,
      people assume they aren't cut out for it before giving it a fair shot. Though of
      course, having people believe that programming is “too difficult” and that the
      average person is “not smart enough” strokes our egos and makes us feel like
      we're part of some super-elite hyper-intelligent group.

    * Mentally prepare yourself for roadblocks. I used to think I was cursed, because 
      every time I tried to setup something new (new development environment, tool,
      library, etc), something would always go wrong. It took many years for me to
      realize that with all the different combinations of user operating systems,
      software versions, etc, the documentation was often outdated or not comprehensive.

    * Do you like it? Forget about if you think it's too hard; do you think it's fun? 
      When you struggle for hours debugging something, and finally, it runs as expected, do 
      you feel a rush of excitement? Do you look forward to having a few hours to figure 
      something out? Those are the things that attracted to me to software–I just didn't 
      worry too much about if I could make it or not.

There are plenty of great resources out there to get you started, but I'll stick with 
one to avoid option overload. Stanford provides free online access to a good number of 
CS courses, including three introductory classes. Click here to get started!

■_ Shen

新言語。

Shen

Shen is a portable functional programming language that offers
Shen とは portable な関数型のプログラミング言語であり、以下のものを提供します

    * pattern matching,
      パターンマッチング

    * λ calculus consistency,
      
    * macros,
      マクロ

    * optional lazy evaluation,
      optional な遅延評価

    * static type checking,.
      静的な型検査

    * an integrated fully functional Prolog,
      統合された fully functional な Prolog

    * and an inbuilt compiler-compiler

Shen has one of the most powerful type systems within functional programming. Shen runs
under a reduced instruction Lisp and is intended for a wide variety of platforms. Hence
our goal and our motto; 'write once, run anywhere'.

Shen includes sources and is absolutely free for commercial use. It currently runs 
under CLisp with SBCL, Scheme and Javascript to follow.
motivation

動機

Shen began many years ago in 1989 when Dr Mark Tarver was working at the Laboratory 
for the Foundations of Computer Science at Edinburgh. The original idea was to bring 
to the Lisp environment many of the advantages of ML; specifically pattern-matching 
and later type checking. The result of this work was the language Qi which won the 
author the Promising Inventor Award from Stony Brook University in 2003.

Qi was a ground-breaking langage that went far beyond ML and Haskell in providing type 
definitions through sequent calculus; a Turing-equivalent notation for defining formal 
reasoning system of all kinds. Qi linked this notation to an inbuilt Prolog for compiling
sequent calculus and threw in lazy evaluation on demand, s-expr metaprogramming, a TDPL
compiler-compiler and a macro system. The result was an extremely elegant and powerful
programming environment.

However Qi was limited by its restrictive license and the dependence on Common Lisp in
which it was coded. In his invited talk to ESL 2009, Dr Tarver argued that by reducing 
the instruction set in which Qi was coded, from 118 functions to 50 or less, it would 
be possible to create a version of Qi that could be easily ported to other platforms. 
The production of type-secure Python, Clojure, Javascript etc. could be done from one 
single platform.

Qi はその restrictive なライセンスと (Qiを記述している) Common Lisp への依存性によって
制限されています。 ESL 2009 の invited talkにおいて Dr Tarver は Qi でコーディングして
いた命令セットを118関数から50以下へと縮小することによって 他のプラットフォームへの
移植が容易になった Qi を作れるようになったと主張しています。
type-secure Python, Clojure, Javascript などの production は単一のプラットフォーム
から行えました。


The reduced instruction set defined a very restricted Lisp which was then called Kernel
Lisp and later Kl. This super-portable version of Qi was called Shen - the Chinese word
for spirit.

この縮小命令セットは Kernel Lisp という名前(のちに Klとなりました)
の非常に制限された Lisp によって定義されています。
この Qi の super-portable バージョンは Shen と呼ばれました。
Shen とは sprit を表す中国語です。

This project received funding in December 2010. In September 2011, Shen was delivered 
under a $free license.

Shen runs under 45 primitive instructions but is even more powerful than Qi. Shen 
added to Qi all of the following;

    * an improved macro system,
    * packages,
    * pattern-directed handling of strings and vectors,
    * and the capacity to process binary files.

Following its release under CLisp, Shen is being rapidly ported to SBCL, Scheme and 
Javascript. Soon you will be able to enjoy the benefits of this award-winning language 
under your favourite platform.

Qi ってあれか。

■_ The Revolution is Personal

prog21: The Revolution is Personal

The Revolution is Personal

If you were going to reinvent the music / film / video game industry, what would you do?

もしあなたが、音楽や映画、ビデオゲームの産業を再発明するとしたら、なにをしますか?

(以下略)

■_

結構入れ替えあるんだなあ。

Core Modules add/remove quick reference | Kirk Kimmel [blogs.perl.org]

Core Modules add/remove quick reference

By Kimmel on October 14, 2011 4:24 PM

When designing a Perl application that needs to run on many different versions I end 
up using 'corelist' a good deal. Most of the time I just needed a list of the 
additions or removals of core modules from different stable series of Perl releases. I 
kept all this information in a text file for reference. While searching for something 
Perl related it dawned on me that I should post this as it could be useful for other 
Perl developers as well.

I used 'corelist -r' and 'corelist -v ' to gather this data together. The release data 
is from 'perldoc perlhist'.


2008-12-14 Perl v5.8.9 released Pumpking: Nicholas Clark
2007-12-18 Perl v5.10.0 released Pumpking: Rafael Garcia-Suarez
2010-04-12 Perl v5.12.0 released Pumpking: Jesse Vincent
2011-05-14 Perl v5.14.0 released Pumpking: Jesse Vincent


Modules removed in 5.10.0:
====
B::Asmdata
B::Assembler
B::Bblock
B::Bytecode
B::C
B::CC
B::Disassembler
B::Lint::Debug
B::Stackobj
B::Stash
ByteLoader
CPAN::Distroprefs
ExtUtils::MM_Darwin
IPC::SharedMem
Thread::Signal
Thread::Specific


Modules added in 5.10.0:
====
(略)

Module name fix in 5.12.0
====
CPAN::DeferedCode -> CPAN::DeferredCode

Modules removed in 5.12.0:
====
CPAN::API::HOWTO
CPANPLUS::inc
ExtUtils::MakeMaker::bytes
ExtUtils::MakeMaker::vmsish
Test::Harness::Assert
Test::Harness::Iterator
Test::Harness::Point
Test::Harness::Results
Test::Harness::Straps
Test::Harness::Util
attrs

Modules added in 5.12.0
====
(略)

Modules removed in 5.14.0:
====
Class::ISA
Pod::Plainer
Switch
TAP::Parser::Source::Perl
XS::APItest::KeywordRPN

Modules added in 5.14.0
====
CPAN::HTTP::Client
CPAN::HTTP::Credentials
CPAN::Meta
CPAN::Meta::Converter
CPAN::Meta::Feature
CPAN::Meta::History
CPAN::Meta::Prereqs
CPAN::Meta::Spec
CPAN::Meta::Validator
CPAN::Meta::YAML
ExtUtils::MakeMaker::YAML
HTTP::Tiny
JSON::PP
JSON::PP::Boolean
Locale::Codes
Locale::Codes::Country
Locale::Codes::Currency
Locale::Codes::Language
Locale::Codes::Script
Module::Metadata
Perl::OSType
TAP::Parser::SourceHandler
TAP::Parser::SourceHandler::Executable
TAP::Parser::SourceHandler::File
TAP::Parser::SourceHandler::Handle
TAP::Parser::SourceHandler::Perl
TAP::Parser::SourceHandler::RawTAP
Unicode::Collate::CJK::Big5
Unicode::Collate::CJK::GB2312
Unicode::Collate::CJK::JISX0208
Unicode::Collate::CJK::Korean
Unicode::Collate::CJK::Pinyin
Unicode::Collate::CJK::Stroke
Unicode::Collate::Locale
Version::Requirements

■_

2011年10月16日

■_


観てきた。 いや面白かった。 遊び(という言い方がいいのかどうか)がちょっと鼻についたかなというのはあったけれど、 深読みができる演出もあったし、なによりザボーガーがかっこいい! 終盤の空中戦は何度でも見返したい :)

お子様連れのお父さんがそこそこいらしたけど、子供のほうは楽しめたのかなあ。あれw (ひとつ前の列に座っていた男の子はアクションシーンでは身を乗り出していたなあ) かなり好き嫌いが分かれるものだと思うのでオススメするのはちと難しいのだけれど、 観れば元気になれる! かもしれない。

Amazon.co.jp: RAH ストロングザボーガー 【Amazon.co.jp限定販売】(※予約期間:~2011年11月30日まで): ホビー Amazon.co.jp: RAH 電人ザボーガー: ホビー
うーむ。値段もそうだけど 30cm か。飾る場所がねえw

しかし

【俺とお前は】電人ザボーガーVol.3【兄弟なのさ】
828 どこの誰かは知らないけれど [sage] 2011/10/15(土) 21:40:26.07 ID:Lf4l+izW Be:
    子門バージョンの主題歌だけでなく、映画バージョンも良かった
    ハリのある声で、新作だけと何か懐かしい感じ

    BGMもオリジナルアレンジで菊池節前回で懐かしかった

833 どこの誰かは知らないけれど [sage] 2011/10/15(土) 22:36:25.33 ID:amnPhz+J Be:
    映画のED映像と劇中挿入歌は良いねぇ!
    しつこい位のSEとBGMがまたタマランわー音って大事だわ

    しかし横浜舞台挨拶は凄かった・・・
    3大大門豊揃い踏みと、オリジナル大門豊の血を引く家族の方の登壇
    きくち英一さんの「胸がいっぱいです・・・」と泣きそうな声と
    故山口暁さんの孫娘さんらしき小さなお嬢さんが平成のザボーガーと
    握手したり触れ合ったりしてる姿は、昭和のおっさんの涙腺に来たぜ!
    板尾も「V3や忍者部隊月光を観てたので・・・」と言ってた

    何よりも、この2011年にザボーガーが復活した事自体が奇跡だぜ 

840 どこの誰かは知らないけれど [sage] 2011/10/16(日) 00:10:27.10 ID:pOhHPQFP Be:
    俺も見てきたよ
    まぁ現代にザボーガーをシリアスにリメイクしても邦画の予算じゃデビルマンみたいになりかねないから
    思い切ってコメディタッチな要素も盛り込むというのはむしろ良かったんじゃないかな
    内容も面白かったし、秋月の声がやたらよかったのとAkikoは昔のサエコみたいだった 

864 どこの誰かは知らないけれど [sage] 2011/10/16(日) 16:09:01.40 ID:8v0TqDPw Be:
    堪能してきた。

    子門の歌が聴けるとは思わなかった。 

865 どこの誰かは知らないけれど [sage] 2011/10/16(日) 16:43:15.30 ID:KW9SeQMW Be:
    劇場版観た興奮冷めやらぬうちにカラオケでOP歌ってきた

    ♪でんじん でんじん の後の「でーーんじーーん」の音取りが難しい 

866 どこの誰かは知らないけれど [sage] 2011/10/16(日) 17:28:49.04 ID:cXGNfr5X Be:
    このスレでの評判は上々って感じだな

    俺は頭が固いからあの作りは好きにはなれないが 

867 どこの誰かは知らないけれど [sage] 2011/10/16(日) 17:48:41.80 ID:8MwRsP3o Be:
    >>865
    そこの部分のことかどうかはわからんが、
    子門さんはあの歌のサビの一部では、
    意識的に十二音階(いわゆるドレミ、ピアノの鍵盤)から
    外れた音を加えて歌ってるらしい
    詳しくは「微分音」でwiki参照 

868 どこの誰かは知らないけれど [sage] 2011/10/16(日) 18:08:08.92 ID:ampft3tN Be:
    主題歌CDやサントラって発売未定なのかな? 

869 どこの誰かは知らないけれど [sage] 2011/10/16(日) 18:08:41.08 ID:QyhkWb8x Be:
    「でえ~ん、じい~ん」と発音するつもりで歌うと歯切れが良くなる 

870 どこの誰かは知らないけれど [sage] 2011/10/16(日) 19:05:17.65 ID:U5LYTImc Be:
    >>868
    75 名前:名無しより愛をこめて 投稿日:2011/10/16(日) 18:34:07.34 ID:V1ivndgi0
    >>19
    これのCDが欲しすぎるのだがサントラ発売予定って無いの?
    76 名前:名無しより愛をこめて 投稿日:2011/10/16(日) 18:50:39.21 ID:OCDpzwOL0
    >>75
    俺も俺も! あのカッコイイ主題歌、欲しすぎる。声の伸びがいいよね。
    ツイッターで高野二郎氏に直接、CD化の予定は無いのかを聞いていた人がいたが、
    「CD化の予定は今のところないから、ライブで歌って行きたいと思います」って
    返事かえしていたよ>高野氏

    ・・・だそうだ 

871 どこの誰かは知らないけれど [sage] 2011/10/16(日) 19:13:15.19 ID:YyfpUVXd Be:
    今はCDが売れない時代だからねえ
    ダウンロード販売という手もあると思うけど・・・ 

CD 出して欲しいなあ。 てっきりサントラでてるものと思って、劇場でたあとで近くのTSUTAYAに行って CD 売り場で検索機使って探したんだけど結果見て絶望した ○| ̄|_ にしても予定なしって…

■_ main() unless caller;

本文はどうでも良くて

Perl, C and Dr. Dennis Ritchie | Kirk Kimmel [blogs.perl.org]

(略)

dmr your amazing presence will be missed. Here are some "Hello World" 
programs in honor of dmr.

    * www.muppetlabs.com/~breadbox/rip-dmr.html
    * lwn.net/Articles/462859/

I decided to add a few in Perl.
Perl:

  #!/usr/bin/perl

  print "Hello World\n";

Modern Perl (C-ish):

  #!/usr/bin/perl

  use v5.12;

  sub main {
      say 'Hello World';
      return;
  }
 
  main() unless caller;

  1;

The one liner:

  perl -E 'say "Hello World"'

main() unless caller; なるほどこうやると Ruby の if $0 == __FILE__ ... end とか Python の if __name__ == '__main__' みたいなことができると。 でぃべろっぱーってへてむる: if __name__ == '__main__'をRuby PHP Python Perlで には if($0 eq __FILE__) なんてのがあるな。こっちのが主流?

■_ Google Code Search

あまり使ってはいなかったけど、なくなるとは

Google killing off Code Search :( : programming


Ugh, that makes me sad. I use it a lot.


Right, Code Search was obviously impossible to productize, but it was really good PR for programmers.


FWIW, I and others argued for the "good PR for programmers" angle. But by 
the time I heard it was probably too late and the decision had been made. :-/


Well show them this thread. I use it a lot. You know how hard it is to find examples 
of how to use obscure libraries in obscure languages? Well without codesearch it is 
very difficult.

too late.. i've never seen google reverse a decision like this.

Google cannot expect developers to invest significant time into developing for 
platforms if they have no guarantee that Google won't arbitrarily pull the rug out 
from under them. You cannot effectively determine the ROI from goodwill.

Look at it this way: every time I hear about Google yanking a service, I am that much 
less inclined to develop for their remaining platforms. If I was nearly finished 
writing a Notebook app for the Android platform, for instance, I'd be royally pissed 
right now, and would probably start seriously considering the iPhone platform.

tl;dr: It takes years to win developer goodwill and only seconds to lose it.

■_ Wired

NeXT 時代にジョブズがインタビュー受けてた記事の載った Wired もう一度読みたいんだけど 何年の何月号だったかなあ。 自分で買ったのはどうしたのか記憶にない(捨てちゃったかなあ)。

■_ OCmal

while it's a bit tricky under Windows, because OCaml still lacks a self-contained Windows installer. …ですよねえ ○| ̄|_

Paolo Donadeo — LifeLOG › Installing OCaml Batteries


Installing OCaml Batteries

In this post I want to help OCaml newcomers to install Batteries. The task is trivial 
under Linux, while it's a bit tricky under Windows, because OCaml still lacks a 
self-contained Windows installer.

(略)

Windows

As said, this OS still lacks a self contained installer which is in progress, at least for
installing OCaml. Since many OCaml versions are available for Windows, with different pros
and cons, I had to decide which one to use, and I decided to follow the simplest path to
reach the goal of installing all the stuff we need. The Cygwin port is by far the simplest
way.

   1. Download Cygwin setup and double click the executable. In Windows Vista/7 (I made my
      test on a Windows 7 64bit box) you will be required to allow the program to be run a
      couple of times, as usual ;-) …

   2. when the list of available packages appears, select: each and every package containing
      "caml" (see the screenshot below), and also make, m4, libncurses-devel, git,
      wget and rlwrap;

   3. open the Cygwin shell;

   4. download the Findlib library, version 1.2.6:
      $ wget http://download.camlcity.org/download/findlib-1.2.6.tar.gz

   5. unpack, compile and install Findlib:
      $ tar -xpzf findlib-1.2.6.tar.gz
      $ cd findlib-1.2.6/
      $ ./configure
      $ make
      $ make install

   6. download, unpack, compile and install Camomile 0.8.1:
      $ wget http://prdownloads.sourceforge.net/camomile/camomile-0.8.1.tar.bz2
      $ tar -xpjf camomile-0.8.1.tar.bz2
      $ cd camomile-0.8.1/
      $ ./configure
      $ make
      $ make install

   7. the last step is to download compile and install Batteries itself. I wasn't able to
      compile the latest stable release (1.2.2), for an obscure preprocessor error, but 
      using the latest GIT branch everything went smoothly. So here are the steps:
      $ git clone git://github.com/ocaml-batteries-team/batteries-included.git
      $ cd batteries-included/
      $ make camomile82
      $ make all doc
      $ make install install-doc

(略)

m4 使うのか…

■_

"the-emacs-problem - steveyegge2" 
https://sites.google.com/site/steveyegge2/the-emacs-problem
Well then, why don't they just convert Emacs to Common Lisp?

"Interview with Dennis Ritchie, Bjarne Stroustrup, James Gosling" 
http://www.gotw.ca/publications/c_family_interview.htm

Shen
http://www.shenlanguage.org/

■_ FizzBuzz

何日か前に CASL で FizzBuzz書いてみてというツイートを見かけたのだけど、 なんか面白いやり方ないかなあ。 乗除算命令がないのでそのためのサブルーチン書いて呼び出すなんてのは一番面白くない :)

2011年10月15日

■_

二日目 :) 今日はYAPC::Asia Tokyo 2011の2日目です - a geek born in Tomakomai YAPC::Asia Tokyo 2011 スペシャルレポート:2日目レポート[随時更新]|gihyo.jp … 技術評論社

■_

ボツ。

■_ Science Code Manifesto

Science Code Manifesto

Software is a cornerstone of science. Without software, twenty-first century science would
be impossible. Without better software, science cannot progress.

ソフトウェアは科学の conerstone です。ソフトウェアがなくては、21世紀の科学はありえないでしょう。
より優れたソフトウェアなくして科学は進歩できないでしょう。

But the culture and institutions of science have not yet adjusted to this reality. We need
to reform them to address this challenge, by adopting these five principles:

Code
    All source code written specifically to process data for a published paper must be
    available to the reviewers and readers of the paper.

    公開された論文のためのデータを処理するために書かれたすべてのソースコードは
    レビュアーおよび論文の読者が利用可能になっていなければならない。

Copyright
    The copyright ownership and license of any released source code must be clearly stated.

    リリースされたソースコードすべての著作権とライセンスは明確な状態になければならない。

Citation
    Researchers who use or adapt science source code in their research must credit the code's
    creators in resulting publications.

    自分の研究で science source code を使ったり adapt した研究者は
    そのコードの作者を resulting publications において credit しなければならない。

Credit
    Software contributions must be included in systems of scientific assessment, credit, and recognition.

    ソフトウェアの貢献は systems of scientific assessment, credit, and recognition
    に含まれねばならない。

Curation
    Source code must remain available, linked to related materials, for the useful
    lifetime of the publication.

     ソースコードはその useful lifetime of the publication の間、
     関連の materials とリンクして
     利用可能なものになっていなければならない。

■_ What is your favorite C programming trick?

あなたのお好きな C プログラミングでのトリック

プリプロセッサーを活用(悪用)したのが目立つような気がしますね。どうしても。 COLUMNS マクロなどは便利(な局面がある)とは思いますが、 あまりお目にかかりたくはないようなw

What is your favorite C programming trick? - Stack Overflow

What is your favorite C programming trick?

For example, I recently came across this in the linux kernel:

  /* Force a compilation error if condition is true */
  #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))

So, in your code, if you have some structure which must be, say a multiple of 8 bytes in
size, maybe because of some hardware constraints, you can do:

  BUILD_BUG_ON((sizeof(struct mystruct) % 8) != 0);

and it won't compile unless the size of struct mystruct is a multiple of 8, and if it is
a multiple of 8, no runtime code is generated at all.

Another trick I know is from the book "Graphics Gems" which allows a single header
file to both declare and initialize variables in one module while in other modules using
that module, merely declare them as externs.

  #ifdef DEFINE_MYHEADER_GLOBALS
  #define GLOBAL
  #define INIT(x, y) (x) = (y)
  #else
  #define GLOBAL extern
  #define INIT(x, y)
  #endif

  GLOBAL int INIT(x, 0);
  GLOBAL int somefunc(int a, int b);

With that, the code which defines x and somefunc does:

  #define DEFINE_MYHEADER_GLOBALS
  #include "the_above_header_file.h"

while code that's merely using x and somefunc() does:

  #include "the_above_header_file.h"

So you get one header file that declares both instances of globals and function prototypes
where they are needed, and the corresponding extern declarations.

So, what are your favorite C programming tricks along those lines?

This seems more like C preprocessor tricks. 

This one comes from the book 'Enough rope to shoot yourself in the foot':

In the header declare

  #ifndef RELEASE
  #  define D(x) do { x; } while (0)
  #else
  #  define D(x)
  #endif

In your code place testing statements eg:

  D(printf("Test statement\n"));

The do/while helps in case the contents of the macro expand to multiple statements.

The statement will only be printed if '-D RELEASE' flag for compiler is not used.

You can then eg. pass the flag to your makefile etc.

Not sure how this works in windows but in *nix it works well
Fun with macros:

  #define SOME_ENUMS(F) \
      F(ZERO, zero) \
      F(ONE, one) \
      F(TWO, two)
  
  /* Now define the constant values.  See how succinct this is. */
  
  enum Constants {
  #define DEFINE_ENUM(A, B) A,
      SOME_ENUMS(DEFINE_ENUMS)
  #undef DEFINE_ENUM
  };
  
  /* Now a function to return the name of an enum: */
  
  const char *ToString(int c) {
      switch (c) {
      default: return NULL; /* Or whatever. */
  #define CASE_MACRO(A, B) case A: return #b;
       SOME_ENUMS(CASE_MACRO)
  #undef CASE_MACRO
       }
  }
  

Once a mate of mine and I redefined return to find a tricky stack corruption bug.

Something like:

  #define return DoSomeStackCheckStuff, return

I always liked dumb preprocessor tricks to make generic container types:

  /* list.h */
  #ifndef CONTAINER_TYPE
  #define CONTAINER_TYPE VALUE_TYPE ## List
  #endif
  typedef struct CONTAINER_TYPE {
      CONTAINER_TYPE *next;
      VALUE_TYPE v;
  } CONTAINER_TYPE;
  /* Possibly Lots of functions for manipulating Lists
  */
  #undef VALUE_TYPE
  #undef CONTAINER_TYPE

Then you can do e.g.:

  #define VALUE_TYPE int
  #include "list.h"
  typedef struct myFancyStructure *myFancyStructureP;
  #define VALUE_TYPE myFancyStructureP
  #define CONTAINER_TYPE mfs
  #include "list.h"

And never write a linked list again. If VALUE_TYPE is always going to be a pointer, then
this is an overkill, since a void * would work just as well. But there are often very small
structures for which the overhead of indirection often doesn't make sense. Also, you gain
type checking (i.e. you might not want to concatenate a linked list of strings with a linked
list of doubles, even though both would work in a void * linked list).

I'm a fan of xor hacks:

Swap 2 pointers without third temp pointer:

  int * a;
  int * b;
  a ^= b;
  b ^= a;
  a ^= b;

Or I really like the xor linked list with only one pointer.
( http://en.wikipedia.org/wiki/XOR_linked_list )

Each node in the linked list is the Xor of the previous node and the next node. To traverse
forward, the address of the nodes are found in the following manner :

  LLNode * first = head;
  LLNode * second = first.linked_nodes;
  LLNode * third = second.linked_nodes ^ first;
  LLNode * fourth = third.linked_nodes ^ second;

etc.

or to traverse backwards:

  LLNode * last = tail;
  LLNode * second_to_last = last.linked_nodes;
  LLNode * third_to_last = second_to_last.linked_nodes ^ last;
  LLNode * fourth_to_last = third_to_last.linked_nodes ^ second_to_last;

etc.

While not terribly useful (you can't start traversing from an arbitrary node) I find 
it to be very cool.
Adding two numbers (a and b) without using any operators:

  printf("%d", printf("%*s%*s",a,"\r",b,"\r") );

it prints a+b.
While reading Quake 2 source code I came up with something like this:

  double normals[][] = {
    #include "normals.txt"
  };

(more or less, I don't have the code handy to check it now).

Since then, a new world of creative use of the preprocessor opened in front of my eyes. I
no longer include just headers, but entire chunks of code now and then (it improves
reusability a lot) :-p

Thanks John Carmack! xD

C99 offers some really cool stuff using anonymous arrays:

Removing pointless variables

  {
      int yes=1;
      setsockopt(yourSocket, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(int));
  }

becomes

   setsockopt(yourSocket, SOL_SOCKET, SO_REUSEADDR, (int[]){1}, sizeof(int));

Passing a Variable Amount of Arguments

  void func(type* values) {
      while(*values) {
          x = *values++;
          /* do whatever with x */
      }
  }

  func((type[]){val1,val2,val3,val4,0});

Static linked lists

  int main() {
      struct llist { int a; struct llist* next;};
      #define cons(x,y) (struct llist[]){{x,y}}
      struct llist *list=cons(1, cons(2, cons(3, cons(4, NULL))));
      struct llist *p = list;
      while(p != 0) {
          printf("%d\n", p->a);
          p = p->next;
      }
  }

Any I'm sure many other cool techniques I haven't thought of.

I'm fond of using = {0}; to initialize structures without needing to call memset.

  struct something X = {0};

This will initialize all of the members of the struct (or array) to zero (but not any 
padding bytes - use memset if you need to zero those as well).

But you should be aware there are some issues with this for large, dynamically allocated
structures.

If we are talking about c tricks my favourite has to be Duff's Device for loop unrolling!
I'm just waiting for the right opportunity to come along for me to actually use it in anger...

Here is an example how to make C code completly unaware about what is actually used of HW
for running the app. The main.c does the setup and then the free layer can be implemented
on any compiler/arch. I think it is quite neat for abstracting C code a bit, so it does
not get to be to spesific.

以下にあげた例は、C のコードをアプリケーション実行時に使用するハードウェアに関して
気にしないですむようにするものです。main.c のコードはセットアップを行ってから
layer can be implemented on any compiler/arch を解放します。
わたしはこれが C のコードを抽象化して specific にならないようにするための
とてもすばらしい手段だと思っています。


Adding a complete compilable example here.

  /* free.h */
  #ifndef _FREE_H_
  #define _FREE_H_
  #include <stdio.h>
  #include <string.h>
  typedef unsigned char ubyte;
  
  typedef void (*F_ParameterlessFunction)() ;
  typedef void (*F_CommandFunction)(ubyte byte) ;
  
  void F_SetupLowerLayer (
  F_ParameterlessFunction initRequest,
  F_CommandFunction sending_command,
  F_CommandFunction *receiving_command);
  #endif
  
  /* free.c */
  static F_ParameterlessFunction Init_Lower_Layer = NULL;
  static F_CommandFunction Send_Command = NULL;
  static ubyte init = 0;
  void recieve_value(ubyte my_input)
  {
      if(init == 0)
      {
          Init_Lower_Layer();
          init = 1;
      }
      printf("Receiving 0x%02x\n",my_input);
      Send_Command(++my_input);
  }
  
  void F_SetupLowerLayer (
      F_ParameterlessFunction initRequest,
      F_CommandFunction sending_command,
      F_CommandFunction *receiving_command)
  {
      Init_Lower_Layer = initRequest;
      Send_Command = sending_command;
      *receiving_command = &recieve_value;
  }
  
  /* main.c */
  int my_hw_do_init()
  {
      printf("Doing HW init\n");
      return 0;
  }
  int my_hw_do_sending(ubyte send_this)
  {
      printf("doing HW sending 0x%02x\n",send_this);
      return 0;
  }
  F_CommandFunction my_hw_send_to_read = NULL;
  
  int main (void)
  {
      ubyte rx = 0x40;
      F_SetupLowerLayer(my_hw_do_init,my_hw_do_sending,&my_hw_send_to_read);
  
      my_hw_send_to_read(rx);
      getchar();
      return 0;
  }
  

Using a stupid macro trick to make record definitions easier to maintain.

  #define COLUMNS(S,E) [(E) - (S) + 1]

  typedef struct
  {
      char studentNumber COLUMNS( 1,  9);
      char firstName     COLUMNS(10, 30);
      char lastName      COLUMNS(31, 51);

  } StudentRecord;

Declaring array's of pointer to functions for implementing finite state machines.

  int (* fsm[])(void) = { ... }

The most pleasing advantage is that it is simple to force each stimulus/state to check all code paths.

In an embedded system, I'll often map an ISR to point to such a table and revector it as needed (outside the ISR).

In C99

  typedef struct{
      int value;
      int otherValue;
  } s;

  s test = {.value = 15, .otherValue = 16};

  /* or */
  int a[100] = {1,2,[50]=3,4,5,[23]=6,7};


Another nice pre-processor "trick" is to use the "#" character to print
debugging expressions. For example:

  #define MY_ASSERT(cond) \
    do { \
      if( !(cond) ) { \
        printf("MY_ASSERT(%s) failed\n", #cond); \
        exit(-1); \
      } \
    } while( 0 )

edit: the code below only works on C++. Thanks to smcameron and Evan Teran.

Yes, the compile time assert is always great. It can also be written as:

  #define COMPILE_ASSERT(cond)\
       typedef char __compile_time_assert[ (cond) ? 0 : -1]

reddit での反応。 What is your favorite C programming trick? : programming

■_

_s な関数についてひとくさり。

Ban programmers, not functions | SIGTTOU

Ban programmers, not functions
関数ではなくプログラマーを Ban しよう

Posted on July 7, 2009 by Bob Somers

So my daily travels around the intertubes landed me on a very interesting blog post by 
Microsoft's Security Development Lifecycle team (which they call SDL, not to be confused
with the arguably more useful Simple DirectMedia Layer library). The post centered around
them adding memcpy() to the banned functions list in favor of their more “secure”
variant, memcpy_s(), which takes and checks the size of the destination buffer.

そのポストでは bannend functions list に memcpy() を追加するための
彼らの「より安全な」バリエーションであるところの
desitination buffer のサイズを引数に取り検査を行う memcpy_s に


Before I explain why I think this is another example of Microsoft spending their time 
doing something incredibly useless instead of innovating, let me explain that all 
these blasted _s functions are one of the reasons I detest the Windows API so much.

このことが、Microsoft が何かを発明するのではなく信じがたいほど無用なことを行って
彼らの時間を浪費しているもうひとつの例であるとわたしがなぜ考えているかを説明する前に
こういった blasted_s 関数群すべてが、Windows API をわたしがとても detest する理由の
ひとつであることを説明しましょう。

I had the unfortunate “pleasure” of digging rather deep into the Windows API for a project
I was working on this past spring quarter. For those of you who haven't ventured into the
Windows API, let me say this: It's so incredibly confusing that it doesn't even look like
C anymore.

直近の spring quater でわたしが働いていたプロジェクトのために
わたしは Windows API の奥底に潜り込むという  unfortunate “pleasure” を過ごしていました。
Windows API に venture したことのないあなたのためにこう言わせてください:
It's so incredibly confusing that it doesn't even look like C anymore.


Almost everything uses custom types, even when there's no logical reason to do so. The 
Linux API does this to some extent, but not nearly as bad as Microsoft.

カスタムタイプを使うほぼすべてのものはそうする logoical reason がないときでさえ
カスタムタイプを使っています。Linux の API は一部の拡張のためにこれを行っていますが
Microsoft のそれほどひどいものではありません。


Secondly, there seems to be no rhyme or reason as to what these types are named. Some 
are named as ALL_CAPITALS_TYPE, others _use_this_strange_underscore_prefix, and some 
use the standard type_t. If you start to use almost any standard library C function, 
you'll inevitably be told by the compiler that you're doing it wrong, and should use 
strcpy_s(), or _strcpy_s(), or _s_t_r_c_p_y_s_(). Seriously, their API has got more 
underscores than Bill Gates has dollar bills.

第二に、これらの型が名前につけられる根拠も理由もないように思われます。
あるものは ALL_CAPITALS_TYPE のように命名され、あるものは
_use_this_strange_underscore_prefix
のように命名され、中には標準の type_t を使っているものもあります。
もしあなたがほとんどすべての標準ライブラリの関数を使おうとすれば、
コンパイラーからその使い方は間違っていて、
strcpy_s() か _strcpy_s() もしくは _s_t_r_c_p_y_s_() を使うべきだと諭されることになるでしょう。
まじめな話、Microsoft の API はビル・ゲイツが持っているドル紙幣よりも多くの
アンダースコアがあります。

What this gives you is this strange, alien language that vaguely resembles C, but is 
so ugly and hideous that you're afraid to touch it. Apple has Objective-C. Microsoft 
has Franken-C.

これがあなたにもたらすのは、C に似ている奇妙な言語であり、
触れることさえ恐ろしい ugly で hideous なものです。
Apple には Objective-C があり、Microsoft には Franken-C があります。

So let me back up and explain this blog post I mentioned earlier. I'm a bit behind on 
this one (I'll admit I'm not often found venturing into the MSDN blogs) but back in 
May the SDL announced that they were adding memcpy() to their banned functions list, 
to join strcpy(), strcat(), strncpy(), strncat(), gets(), and others.

They announced it's replacement, memcpy_s() (soon to be replaced by _memcpy_s() and 
_m_e_m_c_p_y_s_() I'm sure), which takes one additional argument: the size of the 
destination buffer.

彼らはその代替である memcpy_s() をアナウンスしました (これはすぐに _memppy_s() だとか
_m_e_m_c_p_y_s() に置き換えられるだろうとわたしは確信しています)。
memcpy_s() は destination buffer の大きさを示す追加の引数を取ります。

This is aimed make usages of memcpy() more secure, by only copying up to the size of 
the destination buffer bytes, even if that's less than the length of the bytes you 
want to copy. You go from using this:

この関数は、あなたがコピーしたいと考えているバイト長よりも短いものであったとしても
destination buffer バイトだけコピーすることによって、
memcpy() の使い方をより安全なものにすることを目指したものです。


      memcpy(dst, src, len);

to using this:
といった使い方は

      memcpy_s(dst, sizeof(dst), src, len);

のようになります。

This sounds reasonable, except most Windows programmers will just do this:
これは一見合理的なように思えますが、
大部分のWindowsプログラマーは次のようにしてしまうであろうことは違います

      memcpy_s(dst, len, src, len);

which makes your “secure” version useless.

これはせっかくの「安全な」バージョンを台無しにしてしまう使い方です。


The problem here is not that memcpy() doesn't check the size of the destination buffer, 
but rather that some programmers are using it without thinking. A 50 caliber sniper 
rifle is a very powerful tool in the hands of a marksman, but in a cage full of 
chimpanzees, the results could be disastrous.

ここで問題になっているのは memcpy() が destination buffer の大きさをチェックしない
ことではなくて、一部のプログラマーが考えなしに memcpy() を使ってしまうことにあるのです。
A 50 caliber sniper rifle is a very powerful tool in the hands of a marksman, but in a cage
full of chimpanzees, the results could be disastrous.
#なんだこの文 (^^;

    If nothing else, memcpy_s() makes you think about the size of the target buffer.

I suppose, unless you're one of the mindless programmers using memcpy() unsafely before,
in which case you'll learn the new and improved mindless version memcpy_s(dst, len, src, len)
and continue on your merry way.

My point here is that banning functions that are the common source of security vulnerabilities
doesn't fix the problem, because the problem isn't with the functions. These functions are well
documented and we know exactly how they work and what their dangers are. The problem is with
the programmers.

わたしの主張は、セキュリティの脆弱性の common source となるような関数を ban することは
問題の解決にはならないということです。なぜなら、その問題はそういった関数に伴うものでは
ないからです。(脆弱性の common source とされた) 関数はきちんとドキュメントが書かれていて、
それがどのように動作して危険なことはなんであるかをわたしたちは理解しています。
問題はプログラマーにあるのです。

You've got to teach your programmers how to use these functions securely, or at least evaluate
when they should ask for someone to review their code. If training isn't an option, there's a
better option than banning these functions.

あなたのプログラマーたちにこれらの関数を安全に使う方法を教え込むか、さもなければ
最低でも彼らが誰かに自分のコードのレビューを依頼すべきときを評価しましょう。
トレーニングが選択肢になかったとしても、槍玉に挙げられている関数を ban するよりも
ましな選択肢はあります。

Ban programmers who use them wrong. Yes, banish them to the land of C# and other fluffy
dynamic languages with garbage collectors and infinite buffers. They'll do far less harm
there.

関数を正しく使わないプログラマーを ban しましょう。
そう、彼らを C# やガベージコレクションと無限の長さを持つバッファを備えた
fully dinamic な言語の世界へと追いやるのです。
彼らはそこでは far less harm なことをするでしょう。

The key to doing memory management correctly (which includes using memcpy(), strcpy(), 
etc. in safe ways) is to completely engage your brain when you're doing it. You cannot 
zone out when writing memory managing code. Although given the quality of code coming 
out of Redmond, I would not be surprised if most of the programmers have their brains 
permanently switched off.

メモリー管理を正しく行うこと (memcpy() や strcpy() などの使用も含みます) の鍵は
それを行うときに to completely engage your brain  することです。
メモリー管理をするコードを書くときにあなたは zone out できません。
Although given the quality of code coming 
out of Redmond, I would not be surprised if most of the programmers have their brains permanently switched off.


As classic-Microsoft as this blog post was, the best line was last one.

    I wonder when Larry, Steve and Linus will start banning strcpy() in their products?

Words cannot express the hilarity that ensued when I read this line. Maybe, just maybe, 
the reason they haven't found the need to ban them is because they're using them correctly.
Perhaps if Microsoft tried that every once in a while, they would churn out more secure
products themselves without having to resort to Franken-C.


This entry was posted in Code, Microsoft, Security by Bob Somers.

例によって、reddit 効果で気がつきました :)

■_ From C to C++: A quick reference for aging programmers

内容はどうでもいいのですが、

Ángel Ortega: From C to C++: A quick reference for aging programmers

From C to C++: A quick reference for aging programmers
C から C++ へ。年配プログラマーのためのクイックリファレンス

So you were a great system programmer, back in the old days; your low level programs were
celebrated by clever people, you loved C pointers and some days even considered Assembler
as an option. You were happy and self-confident. But somehow you screwed something, got
trapped in a time vortex and you ended today, trying to maintain or develop a program using
that pesky Object Oriented Programming model in something called C++. I understand you;
follow this guide and learn a bunch of things that will put you out of your misery and
understand this brave new world. 

あなたが偉大なシステムプログラマーであった過ぎ去った日々。
あなたの low level プログラムは clever な人たちからの賞賛を受けていました。
あなたは C のポインターを愛し、選択肢としてアセンブラーを考えた日もありました。
あなたは幸福で、自信を持っていました。
けれどもどうしたことかあなたはとあるなにかに混乱して時間の渦に嵌ってしまい、
そういった日々の終わりを迎えました。
そして C++ と呼ばれる代物で書かれた pesky なオブジェクト指向プログラミングモデル
を使ったプログラムの保守や開発に挑戦することになったのです。
I understand you;
このガイドに従ってあなたを混乱に陥らせた諸々を学び、
そしてこの brave new world を理解しましょう。

かなりチョーヤク。

■_

■_

Lisp Scheme Part33

47 デフォルトの名無しさん [sage] 2011/10/15(土) 21:42:48.51 ID: Be:
    多値についてたちが悪い議論はもうやめようよ。 

2011年10月14日

■_

YAPC::Asia Tokyo 2011
一日目行ってきました。 まとめなどはもう他の方にお任せw 今日はYAPC::Asia Tokyo 2011の1日目です - a geek born in Tomakomai

結構求人のお知らせしている企業が多かった気が。

■_ APL

そう、APLなんですよAPL。

Colorful Pieces of Game::言葉がいっぱい

2011-10-13 Thu  [ 転載物::商業誌 ]
言葉がいっぱい
by Hiromasa Iwasaki

これは『電撃王』や『電撃プレイステーション』に載せていたコラムの中で思い入れが深いもの
を、細かくアップトゥデートして載せていくシリーズ。

(略)

ヒマはあるけど、金がない場合にコンピュータでやることはたったの一つ。ソフトを自分で作る
こと‥ってワケで、まさに山のように言語が出てきたワケ。

その中で、代表的なモノを紹介しよう。

(略)


日本でもの凄く流行したのが"GAME"。"GAME"と言ってもゲームじゃなくて
"General Algorithmic Micro Expressions"の略で、BASICの英語の部分を全部記号に
置き換えたような代物。これはVTLの拡張形みたいな言語なんだけど、たったの1.5キロバイト
(つまり原稿用紙2枚分だ)のメモリで動いて、おまけに凄く速度が速かったので、もの凄く流
行った。

この言語に至っては、コンパイラまで登場して、その名前の通り、本当に沢山のゲームが書かれ、
また本当に沢山のマシンに移植された。(実際、日本であった有名なマイコンのほとんどの上で
動くようになっていたと思う)

あと、あまり流行らなかったけれど、FORM(フォーム)っていう大型コンピュータの上で動いて
いたFortran(フォートラン)の簡易版とか、ALGOL/PASCAL系の言語TL/1(Tiny Language/1)、
Micro Pascal(マイクロパスカル)、全然流行らなかったけど高性能だったBASIC/09とか、APL
(A Programming Language)とか、BASE(ベース)とかWICS(ウイックス)とか有象無象を合わせ
ると、もういくつあったのやら想像もつかないほどの数の言語があった。

(以下略)

APL についてはなんどかここでも触れていますが、ASCII の創刊直後の数号でも取り上げられて いたりして妙に存在感を感じさせます(というかわたしが感じている)。 当時の「マイコン」でどの程度のものが動かせたのか(動いたのか)良くわからないのですが、 なんらかの「サブセット」であろうことは間違いないと思います。

先日国会図書館に行ったときに見かけた 国立国会図書館 NDL-OPAC(書誌 全項目表示 ) には、1980年代終盤辺りでMS-DOSパソコンやMSX、APLの一実装を移植するとかいう話がありました。 また、X68000への移植を行った(当時)高校生も紹介されていました。 仙台のあたりにある高専で数学の授業などにAPLを積極的に使っていたという記述もあったように思います (あまり自信ない)。 現在はどうなのだろうと気になって検索したことがあるのですが、 選択した検索後が良くなかったのかそれっぽいものはひっかかりませんでした。 んー、学校名控えてくるべきだった(他のが本命だったのでスルーしたのよね)。

■_ ザボーガー

ようやく上映スケジュールがわかったけど、渋谷は一日二回なのか…

渋谷TOEI 上映中作品

上映時間 【10月15日(土)※本編より上映】
11:05/13:50 TOEI②にて
※11:05の回は上映終了後舞台挨拶がございます。
【10月16日(日)〜21日(金)】
11:20/13:45 TOEI②にて
上映期間
10/15 ~ 10/21 まで

バルト9 に行くか

新宿バルト9|上映スケジュール

■_ dmr

いろいろ記事が出ていますが、NYTimes にもあるとは思わなかった。

Dennis Ritchie, 70, Dies, Programming Trailblazer - NYTimes.com

(略)

Colleagues who worked with Mr. Ritchie were struck by his code — meticulous, clean and concise.
His writing, according to Mr. Kernighan, was similar. “There was a remarkable precision to
his writing,” Mr. Kernighan said, “no extra words, elegant and spare, much like his code.” 

■_

■_

二日目は午後から出向くかも>YAPC

2011年10月13日

■_

2011年10月12日

■_

ゼロが最終回ってんで、スーパージャンプを買ってみた (雑誌自体も最終号だったけど)。

C言語逆引きハンドブックという本を見かけたのでちょっと読んでみたのですが、 すぐにわかるような気になる記述がいくつも。 が、結局その本を買ってはいないので詳しい説明を書いたりはしません(できません)。 そういうのは自腹を切って買ったものでないと思い切り書けないし :)

■_

■_ Why learn Haskell?

reddit で訊け

Why learn Haskell? : haskell

Why learn Haskell? (self.haskell)

I am a third year electrical and computer engineering undergraduate student at a tier 
one university. I was just curious as to redditors' responses to this question. My 
focus is much more on power systems and semiconductors, so I hope it is not surprising 
that yesterday was the first time that I have ever heard of this programming language.


Building on cdsmith's general posts, you'd probably be looking for something like Atom. 
While the world you're living in may never directly run Haskell programs, it is 
possible to leverage the guarantees given by type systems into other environments with 
DSL embeds like that.

Speaking as a software guy, I would have to say that in general, EEs and hardware guys 
on average work with downright suicidal software engineering practices, which hurt 
them immensely in ways they are hardly even capable of perceiving because they don't 
even know that there are entire classes of advances in software engineering that they 
don't know about. (Yes, I phrased it that way on purpose, they are "unknown 
unknowns".) Learning about the concepts in Haskell and learning how to leverage 
them could give you a powerful leg up on tackling the hardest sorts of problems in the 
field. Never miss the opportunity to let your development environment eliminate as 
many wrong answers as possible, as early as possible.


    Never miss the opportunity to let your development environment eliminate as many 
    wrong answers as possible, as early as possible.

Yes!


Here are a few things worth reading on the subject:

    * http://broadcast.oreilly.com/2009/01/why-you-should-learn-haskell.html
    * http://scienceblogs.com/goodmath/2006/11/why_haskell.php
    * http://www.inf.ed.ac.uk/teaching/courses/inf1/fp/2009/lectures/lect00.pdf
    * http://cdsmith.wordpress.com/2011/03/13/haskells-niche-hard-problems/

ぽつぽつ否定的な意見も。

■_ The Three-Fold Function of the Smart Match Operator

blog | Perlgeek.de :: The Three-Fold Function of the Smart Match Operator

Wed, 12 Oct 2011

The Three-Fold Function of the Smart Match Operator

In Perl 5, if you want to match a regex against a particular string, you write $string =~ $regex.

In the design process of Perl 6, people have realized that you cannot only match 
against regexes, but lots of other things can act as patterns too: types (checking 
type conformance), numbers, strings, junctions (composites of values), subroutine 
signatures and so on. So smart matching was born, and it's now written as
$topic ~~ $pattern.
Being a general comparison mechanism is the first function of the smart 
match operator.

Perl 6 の設計プロセスの中で、正規表現に対してのみマッチできるのではなく
そのほかの多くのものがパターンとしても振舞えるということがわかりました。
それには型や数値、文字列、ジャンクション、シグネチャ等々といったものです。
そこでスマートマッチングが生まれました。それは現在 $topic ~~ $pattern
のように記述します。
Being a general comparison mechanism is the first function of the smart match operator.


But behold, there were problems. One of them was the perceived need for special syntactic
forms on the right hand side of the smart match operator to cover some cases. Those were
limited and hard to implement. There was also the fact that now we had two different ways
to invoke regexes: smart matching, and direct invocation as m/.../, which matches against
the topic variable $_. That wasn't really a problem as such, but it was an indicator of
design smell.

しかし、複数の問題があることに注意してください。
そのうちのひとつが、いくつかのケースをカバーするために
スマートマッチ演算子の右辺に特殊な構文形式が必要になるというものです。
それら限定されていて、かつ、実装が難しいものです。


And that's where the second function of the smart match operator originated: 
topicalization. Previously, $a ~~ $b mostly turned into a method call, $b.ACCEPTS($a). 
The new idea was to set the topic variable to $a in a small scope, which allowed many 
special cases to go away. It also nicely unified with given $topic { when $matcher { ... } },
which was already specified as being a topicalizer.



In the new model, MATCH ~~ PAT becomes something like do { $_ = MATCH; PAT.ACCEPTS($_) }
-- which means that if MATCH accesses $_, it automatically does what the user wants.

この新モデルでは、MATCH ~~ PAT は do { $_ = MATCH; PAT.ACCEPTS($_) }
のようなことを行います。これは MATCH が $_ にアクセスしたならば
自動的にユーザーが望むことを行うことを意味します。

(略)

■_

ということで明日は多分更新なしです。

2011年10月11日

■_

しばちゅーさん、今月単行本かあ 【とらのあなWebSite】・漢晋春秋司馬仲達伝三国志 しばちゅうさん 1巻 (イブニングKC)

Dart については様子見 :)

■_ reboot

phpreboot - A reboot of PHP: keep the philosophy, improve the syntax - Google Project Hosting

    I've written that language to make you awesome.

        -- the author 

PHP.reboot is a reboot of PHP, each Hollywood movie has its own reboot, why not doing the
same for one of the most popular programming language. The aim is to keep the philosophy of
PHP but adapt it to be more in sync with the Web of 2010.

(略)

Highlights:

    * less $, less ';' like in javascript
      JavaScirpt のように、より少ない $、より少ない ';'

    * secure by default: no eval, no magic quotes/string interpolation
      デフォルトで secure。eval なし、magic quoates なし、string interpolation なし

    * full unicode support
      Unicode の振るサポート

    * no from/to string auto-conversion
      文字列からの、文字列への自動変換なし

    * XML literal

    * JSON literal

    * a SQL compatible syntax
      SQL 互換の構文

    * XPath/XQuery compatible syntax
      XPath/XQuery 互換の構文

    * Perl 5 regex literal
      Perl 5 の正規表現リテラル

    * URI/file literal

    * a dynamic language with duck typing and a gradual type system
      ダックタイピングと gradual type system を備えた動的言語

    * fast as Java thanks to a runtime profiler/optimizer and JSR 292 API

    * provide an embedded database derby and a standalone web server grizzly by default

    * can run on top of any JEE stacks, or android, it's a JVM language !
      任意の JEE スタック上や Android で実行可能、これは JVM 言語!

PHP.reboot works this latest beta release of jdk7. Or with any java6 jdks thanks to 
the jsr292-backport.

But because some samples are better than long a speech:

(略)

    * XML and SQL can be mixed together

      <html>
       <body>
        <ol>
         {
           resultset = select * from foo where name = 'bar'
           foreach(resultset as value)
           {
             echo <li>$(value.name)</li>
           }
         }
        </ol>
       </body>
      </html>

    * native JSON syntax

      persons = [
       {
        "name": "Smith",
        "age": 20,
        "color": "blue" 
       },
       {
        "name": "Wesson",
        "age": 17,
        "color": "red" 
       }
      ]
       
      foreach(persons as person) {
        echo "Name:" + person.name
        echo "Color:" + person.color
      }

(略)

■_

で、↑に対する反応

A reboot of PHP: keep the philosophy, improve the syntax in the jvm : PHP

So its a language developed to be like PHP but not like PHP and more like Javascript, and
its interpreted by Java? Or did I miss the picture...


Sounds about right.


not by java but in java bytecode of the Java Virtual Machine v7:
http://en.wikipedia.org/wiki/Java_Virtual_Machine

oops: http://www.caucho.com/resin-3.0/quercus/


Oh boy.


This is a great illustration of what happens when someone who's been programming for a 
few years gets it in their head that they know what they're doing and should write 
their own shitty, terrible language.

PS - If your JavaScript doesn't have semicolons, your JavaScript is bad. Use more jslint.


Agreed. JavaScript semicolon insertion is a bitch.

Hey now, Rasmus is a nice guy, there's no need for this.


Oh, I don't know. I might be willing to give up my semicolons for a language that was 
'secure by default'.



I'm not saying semicolons are inherently good or bad as part of language syntax; I'm 
saying that if you're writing JavaScript without them (as the author of 
"php.reboot" indicates he does) then you're writing bad JavaScript.


I'm not sure what language you're talking about, but with regards to Java, that's all 
100% false.

   1. String is an object in Java, always. Maybe you're thinking of boxing for actual 
      primitive types? String isn't primitive in Java though.
   2. Strings are not byte arrays in languages that support unicode, like Java.
   3. You can't subclass String in Java. It's a final class.
   4. Java does do type erasure. The lack of reification is actually a sore point for a lot
      of people that write Java on a daily basis.
   5. All of Java is pass-by-value, so I'm not sure what you mean by this pass-by-reference
      business.

tl;dr: you pulled a bunch of shit out of your ass that wasn't true and a first-semester CS
student in 2 weeks into a Java course would be able to point this 
out.


YES YES YES. Worst part about PHP by far is the lack of consistency.


You realise that SQL, as used by databases, is not really standardised? That is, 
there's a set of core functionality (that nothing implements /entirely/), but for the 
most part it's database-dependent. Therefore, you cannot really have a SQL datatype, 
unless you're restricting yourself to a tiny subset of SQL (creating tables and the 
like is out).

He's using a custom SQL-like DSL: 
http://code.google.com/p/phpreboot/source/browse/trunk/phpreboot/sql.ebnf

And...this is converted to DB-specific SQL how? In addition, how would I access 
DB-specific SQL features?

I wish I had an answer for you... my conjecture is that his first-class SQL support is 
a lot like using a ORM with its own language (e.g. Doctrine has DQL I believe it's 
called) - which is to say, it gets translated to supported SQL databases and you don't 
use DB-specific features.


I think we need to discuss the definition of 'best.'

PHP has:

    * Ubiquity
    * Community support
    * Documentation
    * Ease of use

What can language developers do? Work around this. Currently the language is at a 
stand-still and regressions are absolutely out of the question, perhaps something like 
what Coffeescript has done for JS can be done for PHP? :)

Python is awesome, and that has no semis.


Give me semicolons over magic invisible whitespace any day of the week.

■_

My paradigm is better than your paradigm « Luke Palmer

My paradigm is better than your paradigm

September 15, 2011

On twitter I participated in the short snarky exchange:

    @stevedekorte – Threads sharing state by default is like variables being global by default.

    @luqui – state is like globals :-)

    @stevedekorte – @luqui only shared state – which is why FP ultimately fails – it trades comprehensibility for shared state optimizations

    @luqui – @stevedekorte, wow, sneaking “FP ultimately fails” as if an obvious truth in a reply to a Haskell programmer

    @stevedekorte – @luqui, a bit like sneaking in “[all] state is like globals” to an OO programmer? :-)

    @stevedekorte – @psnively @luqui my only issue with FP is the decision to trade expressivity and reusability for less state while calling it progress


The conversation goes on (and on) between many twitterites, having a fun but serious argument
about this and that benefit of this and that style. Dynamic/static types come up, OO vs.
functional, usefulness, mathematical foundation, learning curves; none of the standard
artillery is spared. What irritates me about this style of argument is all the sweeping
adjectives (1) used with no definition, thus impossible to support with evidence, and (2)
synonymized with better.

In this post, I will draw attention to this irritating vocabulary, so that the next time you
use it you can realize how little you are saying.


(Disclaimer: this post is not intended to criticize stevedekorte specifically, even though I
identify two of the terms he used below. It was a long, typical programming zealot argument,
and all parties involved were being equally dumb :-)

おことわり:
この post では

Expressive
表現力がある

A person is expressive if he expresses himself — he has an idea and wants to write it down.
So I would say a language is expressive if it allows or enables the programmer to be
expressive. Languages that restrict expression are not expressive. So we have the following
facts:

自分自身の持っているアイデアだとか書きたいことを express できるのであればその人は expressive
です。ですからわたしは、プログラマーが expressive であることを許したり可能にするのであれば
その言語は expressive であるというでしょう。expression が限定される言語は expressive では
ありません。そして以下のような事実があります:

    * Dynamically typed languages are more expressive than corresponding statically typed ones,
      because statically typed languages forbid you from expressing some ideas.

      動的型付けを行う言語は静的に型付けを行う言語よりも expressive です。
      なぜなら静的に型付けを行う言語は一部のアイデアの表現を禁じているからです。

    * Multiparadigmatic languages are more expressive than languages which are paradigmatically
      pure, because the former allow you to express yourself if you are not thinking within the
      framework.

      マルチパラダイム的な言語はパラダイム的に pure な言語よりも expressive です。
      なぜなら前者は、そのフレームワークの枠内で思考していない場合にあなた自身を
      express するのを許すからです。


    * A language which you are fluent in is more expressive than a language you do not know very well.

      あなたがすらすらと書ける言語はあまりよく知らない言語よりも expressive です。


By these observations, we might guess that Perl is the most expressive language, Haskell is the least.

これらの observations (観測、観察) によって、わたしたちは Perl が最も expressive な言語で
あり、Haskell が最も expressive でない言語であると考えてしまうかもしれません。


Do you notice yourself already equating expressive with good, and thus perhaps feeling 
offended? Everyone wants an expressive language, right? Here are some reasons some 
programmers might not want an expressive language:

すでにあなた自身が expressive が良いものだと考えていて
そのためにイライラを感じている可能性を認識していますか?
誰もが expressive な言語を求めている。本当に?
以下に一部のプログラマーが expressive な言語を望まないかもしれないいくつかの理由を挙げます:


    * Most of my ideas are made of bullshit. Have you ever had a great idea, gone to write
      it in your blog, and realized it was nonsense because you were unable to write it?
      So writing is less expressive than thinking. Is thinking better than writing?

      わたしのアイデアの大部分はろくでもないものです。ブログに書いて、それが自分では
      記述できないいので nonsense であったと認識したような great idea をこれまでに思
      いついたことがありますか? ですから、書くことは考えることよりも expressive では
      ありません。考えることは書くことよりも better なのでしょうか?

    * Every programmer has a different way of structuring their thoughts. An expressive
      language will bring out the differences in thought structure between programmers, and
      introduce impedance mismatches between programmers on a shared project.

      すべてのプログラマーは自分の思考を structuring する異なるやり方を持っています。
      ある exoressive な言語はプログラマー間の structure の思考の違いを bring out し、
      共有されたプロジェクトにおけるプログラマー間の impedance mismatches を
      持ち込みます。

I'm not arguing that expressiveness is bad. I'm just arguing that it doesn't mean good, it means expressive.

expressiveness が悪いものであるとは主張しません。それが良いものであることを
意味するわけではなく、expressive であることを意味すると主張します。
#わかんね


Reusable
再利用できる

A language “is reusable” (to abuse language a bit) if code written in that language can be easily reused.

ある言語で書かれたコードが簡単に再利用できるのであれば、その言語は“再利用可能”です
(to abuse language a bit)

This “obvious” statement is hiding something very important; namely, reused how? For what?
We are in an unfortunate situation in programming: code is designed to be reused in a
particular way, and if you want to reuse it in a different way you are pretty much out of
luck. An OO widget library is designed for the addition of new types of widgets, but if you
want to reuse a program written in the library on a new platform you are in for a lot of work.
A functional drawing library is designed so that you can transform and export your drawings
in an open-ended variety of ways, composing new ways out of old ones; but if you need to draw
a circle you have to build it out of lines, even if there is a much better way to draw a
circle on your target. (This is essentially the expression problem).

この “はっきりとした”主張は非常に重要なことを隠しています。それはどのように再利用す
るのかということです。では、なんのために再利用するのでしょうか?わたしたちはプログラミ
ングにおいて unfortunate situation に置かれています。コードは特定のやり方における再利
用のために設計されていて、もしそれと異なる方法でそれを再利用したいのなら
you are pretty much out of luck.
ある OO widget ライブラリは新しいタイプの widget の追加のために設計されていますが、し
かしもしそのライブラリを使って書かれたプログラムを再利用したいのなら、新しいプラットフ
ォームで大きな労力が必要となります。ある functional な描画ライブラリは transform 可能
なように設計されているのであなたの描画したものを open-ended な variety of ways から古
いものを新しい方法で組み合わせて export できます。しかしもし円を描画する必要があるのな
ら、たとえターゲット上で円を描画するためのもっと優れた方法が存在したとしてもそれを線分
から構築しなければなりません (This is essentially the expression problem)。


An abstraction will always expose some things and conceal others. Different languages enable
abstraction in different ways, which makes exposing certain things easier and others harder.
The zealot will reply, “but in my experience, real-world programs are naturally organized
around <insert preferred paradigm>, and <insert uncomfortable paradigm> doesn't
support that style as easily.” I would suggest to this zealot to look deeper into the
definition of “real-world” to discover its many facets of subjectivity. (What domain do you
work in? Who architected the real-world software you have worked on, and what was their
background? What kinds of programs do you consider not to exist in the real world, and what
values are you using to minimize them?)

ある抽象はいつでもなにか (some things) を expose し、同時にそのほかのことを conceal します。
異なる言語は特定の事柄の exposing を簡単にしたり他のことを難しくしたりするような
別のやり方で抽象化が可能です。zealot (狂信者) はこう答えるでしょう。
「しかしわたしの経験から言えば、現実世界のプログラムは
<insert preferred paradigm> に対して naturally に orgnaize されていて
<insert uncomfortable paradigm> のスタイルを簡単にサポートできないのだ」と。
そういった zealot にわたしは
many facets of subjectivity を発見するために
“現実世界"の定義をもっと深く考えろと suggest します
(あなたが作業している領域はなんですか?
あなたの使っている現実世界のソフトウェアを誰が architect していて、
そしてそのバックグラウンドはなんだったのでしょうか?
What kinds of programs do you consider not to exist in the real world,
and what values are you using to minimize them?)


Easy to learn
学びやすい

A language is easier to learn than another language if it takes less time to become 
competent/fluent programming in that language.

ある言語はその言語を使ったプログラミングで competent/fluent になるのに
時間がかからなければそのほかの言語よりも学ぶのが簡単です。


I don't think this one is as automatically synonymized with “good”. Haskell programmers
are aware how much relative effort was required to learn Haskell, and are usually grateful
that they put in the effort. But all other things being equal, a language easier to learn
ought to be better than one harder to learn.

わたしはこれが自動的に “good”と synonymize されるものとは考えません。Haskell プログ
ラマーたちは Haskell を学ぶのに必要とされる relative effortがどれほどであったのかを気
にしますし、彼らがかけた労力は一般的に grateful なものです。しかし他のことがらがすべて
等しかったとき、学ぶのが簡単な言語は学ぶのが難しい言語よりも良いものであるとみなされる
傾向があります。

The deadly omission in the above definition is that people are doing the learning. A 
language is easier or harder to learn to a single person, and that is entangled with 
their background, their approach, and their ambitions. When arguing “X is easier to 
learn than Y”, I encourage you to add one of the following phrases to the end:

上述の定義における deadly omission は、どういった人たちが学ぶのかということです。
ある言語がある一人の人物にとって学ぶのが簡単であったりあるいは難しいものであり、
それはその人物の background やアプローチ、あるいは ambitions に entangle されるものです。
あなたが “X が Y よりも簡単”であると主張するときには、以下のフレーズの一つを末尾に
付け加えることをわたしはお勧めします:


    * for programmers who already know Z.
      すでに Z を知っているプログラマーにとって

    * for people with a mathematical background.
      数学的な素養を持った人にとって

    * for people with a non-mathematical background.
      数学的な素養を持っていない人にとって

    * for children.
      子供たちにとって

    * for me.
      わたしにとって

Or something similar. The following phrases do not count.

以下に挙げたフレーズを続けないでください。

    * for almost everyone.
      ほぼすべての人にとって

    * for people with a typical background.
      一般的な background 持った人にとって

    * for people who want to do useful things.
      有用なことを行いたいと望んでいる人にとって

I'll close this section with this remark:
Haskell is the easiest language to learn, because I already know it.

このセクションを次の言葉で締めくくります:
Haskell は最も学ぶのが簡単な言語です。なぜならすでにわたしが知っているからです。

Conclusion
結論

I know I am frequently irritated by many of these kinds of words, and I've only mentioned
three here. But you see where I am going. Respect the values of your fellow engineers. If
you are a polyglot and like a paradigm, it probably comes from a set of values you have —
a set of things you consider important, and that differ from the values of others.
Concentrate on that; communicate your values, and try to understand the values of others.
If you have toyed with a paradigm and quickly lost interest because of some surface feature
(I have — e.g. I will throw out a language without support for closures) or impression,
consider the possibility that you like what you like because simply because it is familiar
(other equivalent notions: easy, natural). Which is fine, some people like to tinker with
their thinking patterns more than others, but remember that you have trained yourself to
think in a particular way, so consider that your “objective” judgements about these
ultimately human languages could be biased.

I know I am frequently irritated by many of these kinds of words,
ですからここでは三つだけのことに言及しました。
But you see where I am going.
あなたの fellow engineers の価値観を respect しましょう。
もしあなたが polyglot であり、あるパラダイムを好きであるのなら、それはおそらくあなたの
持つ価値観 (set of values) からきたものです。
それはあなたが重要だと考えていることの集まりであり、
そして他者の価値観とは異なるものです。
Concentrate on that;
あなたの価値観を伝え、そして他者の価値観を理解することに努めてください。
もしあなたがあるパラダイムにちょっと手を出してみたけれども
なにか表面的な機能 (some surface feature) や印象が理由で即座に興味を失ってしまったら
(わたしはあります。たとえば、クロージャをサポートしていなかったある言語を投げだしました)、
あなたが好きなものが、単純だから好きであるとか
それに慣れ親しんでいる(あるいは簡単であったり、自然である)から好きだという
可能性について考えてみましょう
Which is fine,
some people like to tinker with their thinking patterns more than others,
but remember that you have trained yourself to think in a particular way,
so consider that your “objective” judgements
about these ultimately human languages could be biased.


(For the record, that last phrase originally read: “all of your ‘objective' judgements
about one of these ultimately human languages are biased”, which is quite a bit stronger
than what I had intended)


Copyright © 2003-2011 Luke Palmer


■_


一つ前へ 2011年10月(上旬)
一つ後へ 2011年10月(下旬)

ホームへ

ホームへ


リンクはご自由にどうぞ

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