■_
今週も土曜日はまたいろいろ被ってるし
某球団の話は決着ついてから。
ってこのタイミングで宣言するか >むらたん
一つ前へ
2011年10月(上旬)
一つ後へ
2011年10月(下旬)
どこかで聞いた言い回しだけど
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 OverflowA 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 TipsSigns 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)
あー、もういろいろ追いつかない
ほかの人の、何かに対する 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)
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/SPARKAll 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) 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 プラグマを使います。
もんどり打ってこれに習う
私の唯一誇れる能力は、誤読力である。そのため、私がプログラミング言語の規格を読むのを好むのは、自然なことである。このたび、 Perl の規格上のバグを発見した。なかなか笑えるので紹介する。もちろん、実装者にとっては洒落にならないが。
足らぬ足らぬは工夫が足らぬ。とはいうものの、そればっか言われていると 「精神力で云々」と同じじゃねーかという気がしてきた今日この頃。
プリンターのサポートは、常に重要なWindowsのセールスポイントである。プリンタドライバのサポートは、しばしばWindowsがIBMのOS/2に勝った理由として挙げられる。
わたしが 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.)
おお、今回はこれか。 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 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 ってあれか。
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
観てきた。
いや面白かった。
遊び(という言い方がいいのかどうか)がちょっと鼻についたかなというのはあったけれど、
深読みができる演出もあったし、なによりザボーガーがかっこいい!
終盤の空中戦は何度でも見返したい :)
お子様連れのお父さんがそこそこいらしたけど、子供のほうは楽しめたのかなあ。あれ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 売り場で検索機使って探したんだけど結果見て絶望した ○| ̄|_ にしても予定なしって…
本文はどうでも良くて
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 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.
NeXT 時代にジョブズがインタビュー受けてた記事の載った Wired もう一度読みたいんだけど 何年の何月号だったかなあ。 自分で買ったのはどうしたのか記憶にない(捨てちゃったかなあ)。
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 使うのか…
「伝えたいことがある」ならプレゼンした方がいい
LT とかやるときは、友達とか同僚とかに一度みせてからああいう大舞台で発表すれば失敗がすくないです
このトークに出てきた話と圏論の言葉の対応表を与えておきます。
王義之の蘭亭序によく似た行書体の毛筆フォントはありますか?
"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/
何日か前に CASL で FizzBuzz書いてみてというツイートを見かけたのだけど、 なんか面白いやり方ないかなあ。 乗除算命令がないのでそのためのサブルーチン書いて呼び出すなんてのは一番面白くない :)
二日目 :) 今日はYAPC::Asia Tokyo 2011の2日目です - a geek born in Tomakomai YAPC::Asia Tokyo 2011 スペシャルレポート:2日目レポート[随時更新]|gihyo.jp … 技術評論社
ボツ。
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 とリンクして 利用可能なものになっていなければならない。
あなたのお好きな 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 wellFun 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, returnI 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! xDC99 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 効果で気がつきました :)
内容はどうでもいいのですが、
Á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 を理解しましょう。
かなりチョーヤク。
John watched a TV. と言うべきところを John saw a TV. と間違えてしまうような英語学習者の動詞選択の誤りは、 中国人の英語学習者 (English as a Second Language: ESL) の誤りの30%を占めるそうだが、こういう誤りの訂正に意味役割付与 (Semantic Role Labeling: SRL) を用いると効果がある、という話。
この本のように硬派でわかりやすい数学解説本は、日本語の本はもちろんのこと、英語で書かれた本でもあまり類書がないだけに、絶賛オススメするしかない。
Lisp Scheme Part33 47 デフォルトの名無しさん [sage] 2011/10/15(土) 21:42:48.51 ID: Be: 多値についてたちが悪い議論はもうやめようよ。
YAPC::Asia Tokyo 2011
一日目行ってきました。
まとめなどはもう他の方にお任せw
今日はYAPC::Asia Tokyo 2011の1日目です - a geek born in Tomakomai
結構求人のお知らせしている企業が多かった気が。
そう、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 に行くか
いろいろ記事が出ていますが、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.”
今日、C言語は依然として2番目にポピュラーな言語として世界中で使われている(ないし、これまでに記述されたコード量としては第2位につけている)。一番ポピュラーな言語ってなんだろう? コード量のほうはCOBOLな気がするけど。
さぁ、みんなで一緒に恐怖を抱擁しようではないか! そうすれば、きっと変化は訪れる。
二日目は午後から出向くかも>YAPC
ゼロが最終回ってんで、スーパージャンプを買ってみた (雑誌自体も最終号だったけど)。
C言語逆引きハンドブックという本を見かけたのでちょっと読んでみたのですが、 すぐにわかるような気になる記述がいくつも。 が、結局その本を買ってはいないので詳しい説明を書いたりはしません(できません)。 そういうのは自腹を切って買ったものでないと思い切り書けないし :)
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/
ぽつぽつ否定的な意見も。
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 が $_ にアクセスしたならば 自動的にユーザーが望むことを行うことを意味します。 (略)
ということで明日は多分更新なしです。
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.ebnfAnd...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
実は、交野市役所にはそれより2年前の2007年、OpenOffice.orgを導入して失敗した過去があった。
長年、企業情報システム開発のプログラムをC#で手掛けてきた著者が、百戦錬磨の経験をもとに、 これから職業プログラマとしてC#を使うことになった人に向け、実際の開発現場で必要とされる真の C#プログラミングスキルを身につけるための知識を、やさしくレクチャーします。 とかく、無味乾燥になりがちなコードの説明や、難解とされるオブジェクト指向プログラミングの 概念を、 身近な話題に置き換え、ユーモアを交えて分かりやすく説明する、読み物系技術解説書です。
スマートフォンの進化は、実は、NANDが牽引した。
一つ前へ
2011年10月(上旬)
一つ後へ
2011年10月(下旬)
リンクはご自由にどうぞ
メールの宛先はこちら